snmp-mibs-downloader-1.1/0000755000000000000000000000000011402176075012305 5ustar snmp-mibs-downloader-1.1/rfclist0000644000000000000000000001321611402176070013674 0ustar # updated 2010-06-05 1155 RFC1155-SMI 1213 RFC1213-MIB 1227 SMUX-MIB 1238 CLNS-MIB 1381 RFC1381-MIB 1382 RFC1382-MIB 1414 RFC1414-MIB 1447 SNMPv2-PARTY-MIB 1451 SNMPv2-M2M-MIB 1461 MIOX25-MIB 1471 PPP-LCP-MIB 1472 PPP-SEC-MIB 1473 PPP-IP-NCP-MIB 1474 PPP-BRIDGE-NCP-MIB 1512 FDDI-SMT73-MIB 1513 TOKEN-RING-RMON-MIB 1525 SOURCE-ROUTING-MIB 1559 DECNET-PHIV-MIB 1567 DSA-MIB 1592 DPI20-MIB 1593 IBM-6611-APPN-MIB 1611 DNS-SERVER-MIB 1612 DNS-RESOLVER-MIB 1628 UPS-MIB 1658 CHARACTER-MIB 1659 RS-232-MIB 1660 PARALLEL-MIB 1666 SNA-NAU-MIB 1694 SIP-MIB 1696 Modem-MIB 1697 RDBMS-MIB 1724 RIPv2-MIB 1742 APPLETALK-MIB 1747 SNA-SDLC-MIB 1748 TOKENRING-MIB 1749 TOKENRING-STATION-SR-MIB 1792 TCPIPX-MIB 1910 SNMPv2-USEC-MIB 2006 MIP-MIB 2020 DOT12-IF-MIB 2024 DLSW-MIB 2051 APPC-MIB 2108 SNMP-REPEATER-MIB 2115 FRAME-RELAY-DTE-MIB 2127 ISDN-MIB 2128 DIAL-CONTROL-MIB 2206 RSVP-MIB 2213 INTEGRATED-SERVICES-MIB 2214 INTEGRATED-SERVICES-GUARANTEED-MIB 2232 APPN-DLUR-MIB 2238 HPR-MIB 2266 DOT12-RPTR-MIB 2287 SYSAPPL-MIB 2320 IPOA-MIB 2417 IPATM-IPMC-MIB 2452 IPV6-TCP-MIB 2454 IPV6-UDP-MIB 2455 APPN-MIB 2456 APPN-TRAP-MIB 2457 EBN-MIB 2465 IPV6-MIB:IPV6-TC 2466 IPV6-ICMP-MIB 2494 DS0-MIB:DS0BUNDLE-MIB 2512 ATM-ACCOUNTING-INFORMATION-MIB 2513 ACCOUNTING-CONTROL-MIB 2514 ATM-TC-MIB 2515 ATM-MIB 2561 TN3270E-MIB 2562 TN3270E-RT-MIB 2564 APPLICATION-MIB 2578 SNMPv2-SMI 2579 SNMPv2-TC 2580 SNMPv2-CONF 2584 HPR-IP-MIB 2594 WWW-MIB 2605 DIRECTORY-SERVER-MIB 2613 SMON-MIB 2662 ADSL-LINE-MIB:ADSL-TC-MIB 2666 ETHER-CHIPSET-MIB 2677 NHRP-MIB 2707 Job-Monitoring-MIB 2720 FLOW-METER-MIB 2742 AGENTX-MIB 2758 SLAPM-MIB 2786 SNMP-USM-DH-OBJECTS-MIB 2787 VRRP-MIB 2788 NETWORK-SERVICES-MIB 2789 MTA-MIB 2790 HOST-RESOURCES-MIB:HOST-RESOURCES-TYPES 2819 RMON-MIB 2837 FIBRE-CHANNEL-FE-MIB 2856 HCNUM-TC 2863 IF-MIB 2864 IF-INVERTED-STACK-MIB 2922 PTOPO-MIB 2932 IPMROUTE-STD-MIB 2933 IGMP-STD-MIB 2934 PIM-MIB 2940 COPS-CLIENT-MIB 2954 FRNETSERV-MIB 2955 FR-ATM-PVC-SERVICE-IWF-MIB 2959 RTP-MIB 2981 DISMAN-EVENT-MIB 2982 DISMAN-EXPRESSION-MIB 3014 NOTIFICATION-LOG-MIB 3019 IPV6-MLD-MIB 3020 FR-MFR-MIB 3055 PINT-MIB 3083 DOCS-BPI-MIB 3144 INTERFACETOPN-MIB 3165 DISMAN-SCRIPT-MIB 3176 SFLOW-MIB 3201 CIRCUIT-IF-MIB 3202 FRSLD-MIB 3231 DISMAN-SCHEDULE-MIB 3273 HC-RMON-MIB 3287 DSMON-MIB 3289 DIFFSERV-DSCP-TC:DIFFSERV-MIB 3295 GSMP-MIB 3371 L2TP-MIB 3411 SNMP-FRAMEWORK-MIB 3412 SNMP-MPD-MIB 3413 SNMP-NOTIFICATION-MIB:SNMP-PROXY-MIB:SNMP-TARGET-MIB 3414 SNMP-USER-BASED-SM-MIB 3415 SNMP-VIEW-BASED-ACM-MIB 3416 SNMPv2-PDU 3417 SNMPv2-TM 3418 SNMPv2-MIB 3419 TRANSPORT-ADDRESS-MIB 3433 ENTITY-SENSOR-MIB 3434 HC-ALARM-MIB 3440 ADSL-LINE-EXT-MIB 3498 APS-MIB 3559 MALLOC-MIB 3584 SNMP-COMMUNITY-MIB 3591 OPT-IF-MIB 3592 SONET-MIB 3593 PerfHist-TC-MIB 3595 IPV6-FLOW-LABEL-MIB 3606 ATM2-MIB 3621 POWER-ETHERNET-MIB 3635 EtherLike-MIB 3705 HC-PerfHist-TC-MIB 3728 VDSL-LINE-MIB 3729 APM-MIB 3747 DIFFSERV-CONFIG-MIB 3805 Printer-MIB 3806 Finisher-MIB 3811 MPLS-TC-STD-MIB 3812 MPLS-TE-STD-MIB 3813 MPLS-LSR-STD-MIB 3814 MPLS-FTN-STD-MIB 3815 MPLS-LDP-ATM-STD-MIB:MPLS-LDP-FRAME-RELAY-STD-MIB:MPLS-LDP-GENERIC-STD-MIB:MPLS-LDP-STD-MIB 3816 ROHC-MIB:ROHC-RTP-MIB:ROHC-UNCOMPRESSED-MIB 3826 SNMP-USM-AES-MIB 3872 TRIP-MIB:TRIP-TC-MIB 3873 SCTP-MIB 3877 ALARM-MIB:ITU-ALARM-MIB:ITU-ALARM-TC-MIB 3878 ARC-MIB 3896 DS3-MIB 3970 TE-MIB 4001 INET-ADDRESS-MIB 4008 NAT-MIB 4011 POLICY-BASED-MANAGEMENT-MIB 4022 TCP-MIB 4036 DOCS-IETF-SUBMGT-MIB 4044 FC-MGMT-MIB 4069 VDSL-LINE-EXT-SCM-MIB 4070 VDSL-LINE-EXT-MCM-MIB 4087 TUNNEL-MIB 4113 UDP-MIB 4131 DOCS-IETF-BPI2-MIB 4133 ENTITY-MIB 4149 SSPM-MIB 4150 TPM-MIB 4188 BRIDGE-MIB 4220 TE-LINK-STD-MIB 4265 VPN-TC-STD-MIB 4268 ENTITY-STATE-MIB:ENTITY-STATE-TC-MIB 4273 BGP4-MIB 4292 IP-FORWARD-MIB 4293 IP-MIB 4295 MOBILEIPV6-MIB 4318 RSTP-MIB 4319 HDSL2-SHDSL-LINE-MIB 4323 DOCS-IETF-QOS-MIB 4363 P-BRIDGE-MIB:Q-BRIDGE-MIB 4368 MPLS-LC-ATM-STD-MIB:MPLS-LC-FR-STD-MIB 4369 IFCP-MGMT-MIB 4382 MPLS-L3VPN-STD-MIB 4404 FCIP-MGMT-MIB 4438 T11-FC-NAME-SERVER-MIB 4439 T11-FC-FABRIC-ADDR-MGR-MIB:T11-TC-MIB 4444 ISIS-MIB 4455 SCSI-MIB 4498 AGGREGATE-MIB:TIME-AGGREGATE-MIB 4502 RMON2-MIB 4544 ISCSI-MIB 4545 IPS-AUTH-MIB 4546 DOCS-IF-MIB 4547 DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB 4560 DISMAN-NSLOOKUP-MIB:DISMAN-PING-MIB:DISMAN-TRACEROUTE-MIB 4624 MSDP-MIB 4625 T11-FC-ROUTE-MIB 4626 T11-FC-FSPF-MIB 4631 LMP-MIB 4639 DOCS-CABLE-DEVICE-MIB 4668 RADIUS-AUTH-CLIENT-MIB 4669 RADIUS-AUTH-SERVER-MIB 4670 RADIUS-ACC-CLIENT-MIB 4671 RADIUS-ACC-SERVER-MIB 4672 RADIUS-DYNAUTH-CLIENT-MIB 4673 RADIUS-DYNAUTH-SERVER-MIB 4682 PKTC-IETF-MTA-MIB 4706 ADSL2-LINE-MIB:ADSL2-LINE-TC-MIB 4711 RAQMON-MIB 4712 RAQMON-RDS-MIB 4747 T11-FC-VIRTUAL-FABRIC-MIB 4750 OSPF-MIB:OSPF-TRAP-MIB 4780 SIP-COMMON-MIB:SIP-SERVER-MIB:SIP-TC-MIB:SIP-UA-MIB 4789 SNMP-IEEE802-TM-MIB 4801 GMPLS-TC-STD-MIB 4802 GMPLS-TE-STD-MIB 4803 GMPLS-LABEL-STD-MIB:GMPLS-LSR-STD-MIB 4805 DS1-MIB 4807 IPSEC-SPD-MIB 4836 MAU-MIB 4837 DOT3-EPON-MIB 4878 DOT3-OAM-MIB 4898 TCP-ESTATS-MIB 4935 T11-FC-FABRIC-CONFIG-SERVER-MIB 4936 T11-FC-FABRIC-LOCK-MIB:T11-FC-ZONE-SERVER-MIB 4939 ISNS-MIB 4983 T11-FC-RSCN-MIB 5017 URI-TC-MIB 5060 PIM-STD-MIB 5066 EFM-CU-MIB:IF-CAP-STACK-MIB 5097 UDPLITE-MIB 5098 PKTC-IETF-SIG-MIB 5131 LANGTAG-TC-MIB 5132 IPMCAST-MIB 5190 MIDCOM-MIB 5240 PIM-BSR-MIB 5324 T11-FC-SP-AUTHENTICATION-MIB:T11-FC-SP-POLICY-MIB:T11-FC-SP-SA-MIB:T11-FC-SP-TC-MIB:T11-FC-SP-ZONING-MIB 5427 SYSLOG-TC-MIB 5428 PKTC-IETF-EVENT-MIB 5488 NEMO-MIB 5519 MGMD-STD-MIB 5525 RSERPOOL-MIB 5542 PW-TC-STD-MIB 5591 SNMP-TSM-MIB 5592 SNMP-SSH-TM-MIB 5601 PW-STD-MIB 5602 PW-MPLS-STD-MIB 5603 PW-ENET-STD-MIB 5604 PW-TDM-MIB 5605 PW-ATM-MIB 5643 OSPFV3-MIB 5650 VDSL2-LINE-MIB:VDSL2-LINE-TC-MIB 5676 SYSLOG-MSG-MIB 5728 DVB-RCS-MIB 5813 FORCES-MIB 5815 IPFIX-MIB 5833 CAPWAP-BASE-MIB 5834 CAPWAP-DOT11-MIB snmp-mibs-downloader-1.1/ianalist0000644000000000000000000000107611402176070014033 0ustar # updated 2009-11-24 ianaiftype-mib IANAifType-MIB ianalanguage-mib IANA-LANGUAGE-MIB ianaaddressfamilynumbers-mib IANA-ADDRESS-FAMILY-NUMBERS-MIB ianaiprouteprotocol-mib IANA-RTPROTO-MIB ianatn3270etc-mib IANATn3270eTC-MIB ianamalloc-mib IANA-MALLOC-MIB ianacharset-mib IANA-CHARSET-MIB ianaprinter-mib IANA-PRINTER-MIB ianafinisher-mib IANA-FINISHER-MIB ianaitualarmtc-mib IANA-ITU-ALARM-TC-MIB ianagmplstc-mib IANA-GMPLS-TC-MIB ianaippmmetricsregistry-mib IANA-IPPM-METRICS-REGISTRY-MIB ianamau-mib IANA-MAU-MIB ianaipfixselector-mib IPFIX-SELECTOR-MIB snmp-mibs-downloader-1.1/debian/0000755000000000000000000000000011402201103013504 5ustar snmp-mibs-downloader-1.1/debian/control0000755000000000000000000000172111402176070015131 0ustar Source: snmp-mibs-downloader Section: non-free/net Priority: optional Maintainer: Jochen Friedrich Standards-Version: 3.8.4 Build-Depends: debhelper (>=7) Homepage: https://alioth.debian.org/projects/pkg-net-snmp Vcs-Git: git://git.debian.org/git/collab-maint/snmp-mibs-downloader.git Vcs-Browser: http://git.debian.org/?p=collab-maint/snmp-mibs-downloader.git Package: snmp-mibs-downloader Section: non-free/net Architecture: all Depends: ${misc:Depends}, wget, smistrip, patch Suggests: unzip Description: Install and manage Management Information Base (MIB) files This package ships the IETF RFCs containing MIB files and a script which extracts them to be used by Simple Network Management libraries. The script can be used to update some MIBs to the latest version or to download extra vendor MIBs. . These MIBs can be useful for programs like wireshark or snmpget to enable them to translating the received information into human readable text. snmp-mibs-downloader-1.1/debian/rules0000755000000000000000000000037711402176070014611 0ustar #!/usr/bin/make -f %: dh $@ .phony: update_rfcs update_rfcs: rm -f mibrfcs/* cat rfclist ianarfclist | while read rfc mib; do \ if [ "$$rfc" != "#" ]; then \ wget -O mibrfcs/rfc$$rfc.txt http://www.rfc-editor.org/rfc/rfc$$rfc.txt; \ fi; \ done; snmp-mibs-downloader-1.1/debian/copyright0000644000000000000000000004561011402176070015463 0ustar This Debian package is currently maintained by Jochen Friedrich . Copyright: mibrfcs/* Copyright (C) The Internet Society (1997-2006) and the persons identified as the document authors. Copyright (C) The IETF Trust (2006-2009) and the persons identified as the document authors. The license of the RFC documents have been changed on November 10, 2008. Most importantly, any RFC before this date may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English end other than to extract the MIB as-is for separate use. MIBs contained in RFCs published after this date, however, my be used under the BSD license below. License of mibrfcs/rfc1155-5324.txt (published before November 10, 2008): This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. RFC 3978 clarifies the use of MIBs contained in these RFCs: In the cases of MIB or PIB modules and in other cases where the Contribution includes material that is meant to be extracted in order to be used, the following should be appended to statement 5.2 (a) or 5.2 (b): "other than to extract section XX as-is for separate use." License of mibrfcs/rfc5427-5676.txt (published after November 10, 2008): IETF TRUST Legal Provisions Relating to IETF Documents Approved November 6, 2008 Effective Date: November 10, 2008 1. Background The IETF Trust was formed on December 15, 2005, for, among other things, the purpose of acquiring, holding, maintaining and licensing certain existing and future intellectual property used in connection with the Internet standards process and its administration, for the advancement of science and technology associated with the Internet and related technology. Accordingly, pursuant to RFC 5378, Contributors to the IETF Standards Process grant the IETF Trust certain licenses with respect to their IETF Contributions. In RFC 5377, the IETF Community has provided the IETF Trust with guidance regarding licenses that the IETF Trust should grant to others with respect to such IETF Contributions and IETF Documents. These Legal Provisions describe the rights and licenses that the IETF Trust grants to others with respect to such IETF Contributions and IETF Documents; as well as certain restrictions, limitations and notices relating to IETF Documents. Capitalized terms used in these Legal Provisions that are not otherwise defined have the meanings set forth in RFC 5378. 2. Applicability of these Legal Provisions. a. These Legal Provisions are effective as of November 10, 2008 (the “Effective Date”). b. The licenses granted by the IETF Trust pursuant to these Legal Provisions apply only with respect to (i) IETF Contributions (including Internet-Drafts) that are submitted to the IETF following the Effective Date, and (ii) IETF RFCs and other IETF Documents that are published after the Effective Date. c. IETF Contributions made, and IETF Documents published, prior to the Effective Date (“Pre-Existing IETF Documents”) remain subject to the licensing provisions of the IETF copyright policy document in effect at the time of their publication, including RFCs 1310, 1602, 2026, 3978 and 4748. d. In most cases, rights to Pre-Existing IETF Documents that are not expressly granted under these RFCs can only be obtained by requesting such rights directly from the document authors. The IETF Trust and the Internet Society do not become involved in making such requests to document authors. e. These Legal Provisions may be amended from time to time by the IETF Trust in a manner consistent with the guidance provided by the IETF community and its own operating procedures. Any amendment to these Legal Provisions shall be posted for review at http://trustee.ietf.org/policyandprocedures.html and shall become effective on a date specified by the IETF Trust, but no earlier than thirty (30) days following its posting. Such amendment shall apply with respect to all IETF Contributions made and IETF Documents published following the effective date of such amendment. All prior versions of these Legal Provisions shall continue to be posted at http://trustee.ietf.org/policyandprocedures.html for reference with respect to IETF Contributions and IETF Documents as to which they may apply. 3. Licenses to IETF Documents and IETF Contributions. a. License For Use Within the IETF Standards Process. The IETF Trust hereby grants to each participant in the IETF Standards Process, to the greatest extent that it is permitted to do so, a non-exclusive, royalty-free, worldwide right and license under all copyrights and rights of authors: i. to copy, publish, display and distribute IETF Contributions and IETF Documents, in whole or in part, as part of the IETF Standards Process, and ii. to translate IETF Contributions and IETF Documents, in whole or part, into languages other than English as part of the IETF Standards Process, and iii. unless explicitly disallowed in the notices contained in an IETF Contribution or IETF Document (as specified in Section 6.b below), to modify or prepare derivative works of such IETF Contributions or IETF Documents, in whole or in part, as part of the IETF Standards Process. b. IETF Standards Process. The term IETF Standards Process has the meaning assigned to it in RFC 5378. In addition, the IETF Trust interprets the IETF Standards Process to include the archiving of IETF Documents in perpetuity for reference in support of IETF activities and the implementation of IETF standards and specifications. c. Licenses For Use Outside the IETF Standards Process. In addition to the rights granted with respect to Code Components described in Section 4 below, the IETF Trust hereby grants to each person who wishes to exercise such rights, to the greatest extent that it is permitted to do so, a non-exclusive, royalty-free, worldwide right and license under all copyrights and rights of authors: i. to copy, publish, display and distribute IETF Contributions and IETF Documents in full and without modification, ii. to translate IETF Contributions and IETF Documents into languages other than English, and to copy, publish, display and distribute such translated IETF Contributions and IETF Documents in full and without modification, iii. to copy, publish, display and distribute unmodified portions of IETF Contributions and IETF Documents and translations thereof, provided that: (x) each such portion is clearly attributed to IETF and identifies the RFC or other IETF Document or IETF Contribution from which it is taken, (y) all IETF legends, legal notices and indications of authorship contained in the original IETF RFC must also be included where any substantial portion of the text of an IETF RFC, and in any event where more than one-fifth of such text, is reproduced in a single document or series of related documents. d. Licenses that are not Granted. The following licenses are not granted pursuant to these Legal Provisions: i. any license to modify IETF Contributions or IETF Documents, or portions thereof (other than to make translations or to extract, use and modify Code Components as permitted under the licenses granted under Section 4 of these Legal Provisions) in any context outside the IETF Standards Process, or ii. any license to publish, display or distribute IETF Contributions or IETF Documents, or portions thereof, without the required legends and notices described in these Legal Provisions. e. Requesting Additional Rights. Anyone who wishes to request license rights from the IETF Trust in addition to those granted under these Legal Provisions may submit such request to trustees@ietf.org. Such request will be considered by the IETF Trust, which will make a decision regarding the request in its sole discretion and inform the requester of its disposition. In addition, individual Contributors may be contacted regarding licenses to their IETF Contributions. The IETF Trust does not limit the ability of IETF Contributors to license their Contributions, so long as those licenses do not affect the rights granted to the IETF Trust under RFC 5378. 4. License to Code Components. a. Definition. IETF Contributions and IETF Documents often include components intended to be directly processed by a computer (“Code Components”). A list of common Code Components can be found at http://trustee.ietf.org/policyandprocedures.html . b. Identification. Text in IETF Contributions and IETF Documents of the types identified in Section 4.a above shall constitute “Code Components”. In addition, any text found between the markers and , or otherwise clearly labeled as a Code Component, shall be considered a “Code Component”. c. License. In addition to the licenses granted under Section 3, Code Components are also licensed to each person who wishes to receive such a license on the terms of the "BSD License", as described below. If a licensee elects to apply the BSD License to a Code Component, then the additional licenses and restrictions set forth in Section 3 and elsewhere in these Legal Provisions shall not apply thereto. BSD License: Copyright (c) [insert year] IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. • Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The above BSD License is intended to be compatible with the BSD License template published at http://opensource.org/licenses/bsd-license.php . d. Attribution. Those who use Code Components under the license granted under Section 4.c above are requested to attribute each such Code Component to IETF and identify the RFC or other IETF Document or IETF Contribution from which it is taken. Such attribution may be placed in the code itself (e.g., “This code was derived from IETF RFC [insert RFC number]. Please reproduce this note if possible.”) or any other reasonable location. 5. License Limitations. a. No Patent License. The licenses granted under these Legal Provisions shall not be deemed to grant any right under any patent, patent application or similar intellectual property right. b. Supersedure. The terms of any license granted under these Legal Provisions may be superseded by a written agreement between the IETF Trust and the licensee that specifically references and supersedes the relevant provisions of these Legal Provisions, except that (i) the IETF Trust shall in no event be authorized to grant rights with respect to any Contribution in excess of those which it has been granted by the Contributor, and (ii) the rights granted shall not be less than those otherwise granted under these Legal Provisions. 6. Text To Be Included in IETF Documents. The following text must be included on the first page of each IETF Document as specified below: a. Submission Compliance for Internet-Drafts. In each Internet-Draft: This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. b. Copyright and License Notice. In each IETF Document (including RFCs and Internet-Drafts): Copyright (c) [insert year] IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. c. Derivative Works and Publication Limitations. If a Contributor desires to limit the right to make modifications and derivative works of an IETF Contribution, or to limit its publication, one of the following notices must be included. These notices may not be used with any standards-track document, nor with most working group documents. i. If the Contributor does not wish to allow modifications, but does wish to allow publication as an RFC: This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC and to translate it into languages other than English. ii. If the Contributor does not wish to allow modifications nor to allow publication as an RFC: This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 7. Terms Applicable to All IETF Documents. The following legal terms apply to all IETF Documents: a. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. b. The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. c. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. d. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. e. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. f. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. The rest: Copyright (c) 2009 Jochen Friedrich The following terms apply to all files associated with the software unless explicitly disclaimed in individual files. The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this software may be copyrighted by their authors and need not follow the licensing terms described here, provided that the new terms are clearly indicated on the first page of each file where they apply. IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. snmp-mibs-downloader-1.1/debian/manpages0000644000000000000000000000002011402176070015230 0ustar download-mibs.1 snmp-mibs-downloader-1.1/debian/changelog0000644000000000000000000000106411402176070015375 0ustar snmp-mibs-downloader (1.1) unstable; urgency=low * Ship IANA resources directly rather than extracting them from the RFC. Not all resources are shipped as RFC and sometimes even the RFC listed in the history is plain wrong. (Closes: #574608) * Update policy to 3.8.4. * Add recently submitted RFCs to repository. -- Jochen Friedrich Fri, 04 Jun 2010 14:34:12 +0200 snmp-mibs-downloader (1.0) unstable; urgency=low * Initial release. (Closes: #559039) -- Jochen Friedrich Thu, 07 Jan 2010 16:30:13 +0100 snmp-mibs-downloader-1.1/debian/compat0000644000000000000000000000000211402176070014720 0ustar 7 snmp-mibs-downloader-1.1/debian/dirs0000644000000000000000000000015111402176070014403 0ustar usr/bin etc/snmp-mibs-downloader usr/share/mibs usr/share/doc/mibrfcs usr/share/doc/mibiana var/lib/mibs snmp-mibs-downloader-1.1/debian/examples0000644000000000000000000000010511402176070015257 0ustar cisco.conf ciscolist screenos.conf screenoslist junos.conf junoslist snmp-mibs-downloader-1.1/debian/postinst0000644000000000000000000000043511402176070015332 0ustar #!/bin/sh set -e if [ ! -d /usr/share/mibs/iana -o ! -d /usr/share/mibs/ietf ]; then if ! /usr/bin/download-mibs; then echo "Downloading the MIBs failed." echo "" echo "Please check your Internet connection and run download-mibs again." echo "" exit 1 fi fi #DEBHELPER# snmp-mibs-downloader-1.1/debian/source/0000755000000000000000000000000011402176070015022 5ustar snmp-mibs-downloader-1.1/debian/source/format0000644000000000000000000000001511402176070016231 0ustar 3.0 (native) snmp-mibs-downloader-1.1/mibiana/0000755000000000000000000000000011402176070013700 5ustar snmp-mibs-downloader-1.1/mibiana/ianaiftype-mib0000644000000000000000000007277711402176070016545 0ustar IANAifType-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaifType MODULE-IDENTITY LAST-UPDATED "201002110000Z" -- February 11, 2010 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" DESCRIPTION "This MIB module defines the IANAifType Textual Convention, and thus the enumerated values of the ifType object defined in MIB-II's ifTable." REVISION "201002110000Z" -- February 11, 2010 DESCRIPTION "Registration of new IANAifType 254." REVISION "201002080000Z" -- February 08, 2010 DESCRIPTION "Registration of new IANAifTypes 252 and 253." REVISION "200905060000Z" -- May 06, 2009 DESCRIPTION "Registration of new IANAifType 251." REVISION "200902060000Z" -- February 06, 2009 DESCRIPTION "Registration of new IANAtunnelType 15." REVISION "200810090000Z" -- October 09, 2008 DESCRIPTION "Registration of new IANAifType 250." REVISION "200808120000Z" -- August 12, 2008 DESCRIPTION "Registration of new IANAifType 249." REVISION "200807220000Z" -- July 22, 2008 DESCRIPTION "Registration of new IANAifTypes 247 and 248." REVISION "200806240000Z" -- June 24, 2008 DESCRIPTION "Registration of new IANAifType 246." REVISION "200805290000Z" -- May 29, 2008 DESCRIPTION "Registration of new IANAifType 245." REVISION "200709130000Z" -- September 13, 2007 DESCRIPTION "Registration of new IANAifTypes 243 and 244." REVISION "200705290000Z" -- May 29, 2007 DESCRIPTION "Changed the description for IANAifType 228." REVISION "200703080000Z" -- March 08, 2007 DESCRIPTION "Registration of new IANAifType 242." REVISION "200701230000Z" -- January 23, 2007 DESCRIPTION "Registration of new IANAifTypes 239, 240, and 241." REVISION "200610170000Z" -- October 17, 2006 DESCRIPTION "Deprecated/Obsoleted IANAifType 230. Registration of IANAifType 238." REVISION "200609250000Z" -- September 25, 2006 DESCRIPTION "Changed the description for IANA ifType 184 and added new IANA ifType 237." REVISION "200608170000Z" -- August 17, 2006 DESCRIPTION "Changed the descriptions for IANAifTypes 20 and 21." REVISION "200608110000Z" -- August 11, 2006 DESCRIPTION "Changed the descriptions for IANAifTypes 7, 11, 62, 69, and 117." REVISION "200607250000Z" -- July 25, 2006 DESCRIPTION "Registration of new IANA ifType 236." REVISION "200606140000Z" -- June 14, 2006 DESCRIPTION "Registration of new IANA ifType 235." REVISION "200603310000Z" -- March 31, 2006 DESCRIPTION "Registration of new IANA ifType 234." REVISION "200603300000Z" -- March 30, 2006 DESCRIPTION "Registration of new IANA ifType 233." REVISION "200512220000Z" -- December 22, 2005 DESCRIPTION "Registration of new IANA ifTypes 231 and 232." REVISION "200510100000Z" -- October 10, 2005 DESCRIPTION "Registration of new IANA ifType 230." REVISION "200509090000Z" -- September 09, 2005 DESCRIPTION "Registration of new IANA ifType 229." REVISION "200505270000Z" -- May 27, 2005 DESCRIPTION "Registration of new IANA ifType 228." REVISION "200503030000Z" -- March 3, 2005 DESCRIPTION "Added the IANAtunnelType TC and deprecated IANAifType sixToFour (215) per RFC4087." REVISION "200411220000Z" -- November 22, 2004 DESCRIPTION "Registration of new IANA ifType 227 per RFC4631." REVISION "200406170000Z" -- June 17, 2004 DESCRIPTION "Registration of new IANA ifType 226." REVISION "200405120000Z" -- May 12, 2004 DESCRIPTION "Added description for IANAifType 6, and changed the descriptions for IANAifTypes 180, 181, and 182." REVISION "200405070000Z" -- May 7, 2004 DESCRIPTION "Registration of new IANAifType 225." REVISION "200308250000Z" -- Aug 25, 2003 DESCRIPTION "Deprecated IANAifTypes 7 and 11. Obsoleted IANAifTypes 62, 69, and 117. ethernetCsmacd (6) should be used instead of these values" REVISION "200308180000Z" -- Aug 18, 2003 DESCRIPTION "Registration of new IANAifType 224." REVISION "200308070000Z" -- Aug 7, 2003 DESCRIPTION "Registration of new IANAifTypes 222 and 223." REVISION "200303180000Z" -- Mar 18, 2003 DESCRIPTION "Registration of new IANAifType 221." REVISION "200301130000Z" -- Jan 13, 2003 DESCRIPTION "Registration of new IANAifType 220." REVISION "200210170000Z" -- Oct 17, 2002 DESCRIPTION "Registration of new IANAifType 219." REVISION "200207160000Z" -- Jul 16, 2002 DESCRIPTION "Registration of new IANAifTypes 217 and 218." REVISION "200207100000Z" -- Jul 10, 2002 DESCRIPTION "Registration of new IANAifTypes 215 and 216." REVISION "200206190000Z" -- Jun 19, 2002 DESCRIPTION "Registration of new IANAifType 214." REVISION "200201040000Z" -- Jan 4, 2002 DESCRIPTION "Registration of new IANAifTypes 211, 212 and 213." REVISION "200112200000Z" -- Dec 20, 2001 DESCRIPTION "Registration of new IANAifTypes 209 and 210." REVISION "200111150000Z" -- Nov 15, 2001 DESCRIPTION "Registration of new IANAifTypes 207 and 208." REVISION "200111060000Z" -- Nov 6, 2001 DESCRIPTION "Registration of new IANAifType 206." REVISION "200111020000Z" -- Nov 2, 2001 DESCRIPTION "Registration of new IANAifType 205." REVISION "200110160000Z" -- Oct 16, 2001 DESCRIPTION "Registration of new IANAifTypes 199, 200, 201, 202, 203, and 204." REVISION "200109190000Z" -- Sept 19, 2001 DESCRIPTION "Registration of new IANAifType 198." REVISION "200105110000Z" -- May 11, 2001 DESCRIPTION "Registration of new IANAifType 197." REVISION "200101120000Z" -- Jan 12, 2001 DESCRIPTION "Registration of new IANAifTypes 195 and 196." REVISION "200012190000Z" -- Dec 19, 2000 DESCRIPTION "Registration of new IANAifTypes 193 and 194." REVISION "200012070000Z" -- Dec 07, 2000 DESCRIPTION "Registration of new IANAifTypes 191 and 192." REVISION "200012040000Z" -- Dec 04, 2000 DESCRIPTION "Registration of new IANAifType 190." REVISION "200010170000Z" -- Oct 17, 2000 DESCRIPTION "Registration of new IANAifTypes 188 and 189." REVISION "200010020000Z" -- Oct 02, 2000 DESCRIPTION "Registration of new IANAifType 187." REVISION "200009010000Z" -- Sept 01, 2000 DESCRIPTION "Registration of new IANAifTypes 184, 185, and 186." REVISION "200008240000Z" -- Aug 24, 2000 DESCRIPTION "Registration of new IANAifType 183." REVISION "200008230000Z" -- Aug 23, 2000 DESCRIPTION "Registration of new IANAifTypes 174-182." REVISION "200008220000Z" -- Aug 22, 2000 DESCRIPTION "Registration of new IANAifTypes 170, 171, 172 and 173." REVISION "200004250000Z" -- Apr 25, 2000 DESCRIPTION "Registration of new IANAifTypes 168 and 169." REVISION "200003060000Z" -- Mar 6, 2000 DESCRIPTION "Fixed a missing semi-colon in the IMPORT. Also cleaned up the REVISION log a bit. It is not complete, but from now on it will be maintained and kept up to date with each change to this MIB module." REVISION "199910081430Z" -- Oct 08, 1999 DESCRIPTION "Include new name assignments up to cnr(85). This is the first version available via the WWW at: ftp://ftp.isi.edu/mib/ianaiftype.mib" REVISION "199401310000Z" -- Jan 31, 1994 DESCRIPTION "Initial version of this MIB as published in RFC 1573." ::= { mib-2 30 } IANAifType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifType object in the (updated) definition of MIB-II's ifTable. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana&iana.org). The relationship between the assignment of ifType values and of OIDs to particular media-specific MIBs is solely the purview of IANA and is subject to change without notice. Quite often, a media-specific MIB's OID-subtree assignment within MIB-II's 'transmission' subtree will be the same as its ifType value. However, in some circumstances this will not be the case, and implementors must not pre-assume any specific relationship between ifType values and transmission subtree OIDs." SYNTAX INTEGER { other(1), -- none of the following regular1822(2), hdh1822(3), ddnX25(4), rfc877x25(5), ethernetCsmacd(6), -- for all ethernet-like interfaces, -- regardless of speed, as per RFC3635 iso88023Csmacd(7), -- Deprecated via RFC3635 -- ethernetCsmacd (6) should be used instead iso88024TokenBus(8), iso88025TokenRing(9), iso88026Man(10), starLan(11), -- Deprecated via RFC3635 -- ethernetCsmacd (6) should be used instead proteon10Mbit(12), proteon80Mbit(13), hyperchannel(14), fddi(15), lapb(16), sdlc(17), ds1(18), -- DS1-MIB e1(19), -- Obsolete see DS1-MIB basicISDN(20), -- no longer used -- see also RFC2127 primaryISDN(21), -- no longer used -- see also RFC2127 propPointToPointSerial(22), -- proprietary serial ppp(23), softwareLoopback(24), eon(25), -- CLNP over IP ethernet3Mbit(26), nsip(27), -- XNS over IP slip(28), -- generic SLIP ultra(29), -- ULTRA technologies ds3(30), -- DS3-MIB sip(31), -- SMDS, coffee frameRelay(32), -- DTE only. rs232(33), para(34), -- parallel-port arcnet(35), -- arcnet arcnetPlus(36), -- arcnet plus atm(37), -- ATM cells miox25(38), sonet(39), -- SONET or SDH x25ple(40), iso88022llc(41), localTalk(42), smdsDxi(43), frameRelayService(44), -- FRNETSERV-MIB v35(45), hssi(46), hippi(47), modem(48), -- Generic modem aal5(49), -- AAL5 over ATM sonetPath(50), sonetVT(51), smdsIcip(52), -- SMDS InterCarrier Interface propVirtual(53), -- proprietary virtual/internal propMultiplexor(54),-- proprietary multiplexing ieee80212(55), -- 100BaseVG fibreChannel(56), -- Fibre Channel hippiInterface(57), -- HIPPI interfaces frameRelayInterconnect(58), -- Obsolete use either -- frameRelay(32) or -- frameRelayService(44). aflane8023(59), -- ATM Emulated LAN for 802.3 aflane8025(60), -- ATM Emulated LAN for 802.5 cctEmul(61), -- ATM Emulated circuit fastEther(62), -- Obsoleted via RFC3635 -- ethernetCsmacd (6) should be used instead isdn(63), -- ISDN and X.25 v11(64), -- CCITT V.11/X.21 v36(65), -- CCITT V.36 g703at64k(66), -- CCITT G703 at 64Kbps g703at2mb(67), -- Obsolete see DS1-MIB qllc(68), -- SNA QLLC fastEtherFX(69), -- Obsoleted via RFC3635 -- ethernetCsmacd (6) should be used instead channel(70), -- channel ieee80211(71), -- radio spread spectrum ibm370parChan(72), -- IBM System 360/370 OEMI Channel escon(73), -- IBM Enterprise Systems Connection dlsw(74), -- Data Link Switching isdns(75), -- ISDN S/T interface isdnu(76), -- ISDN U interface lapd(77), -- Link Access Protocol D ipSwitch(78), -- IP Switching Objects rsrb(79), -- Remote Source Route Bridging atmLogical(80), -- ATM Logical Port ds0(81), -- Digital Signal Level 0 ds0Bundle(82), -- group of ds0s on the same ds1 bsc(83), -- Bisynchronous Protocol async(84), -- Asynchronous Protocol cnr(85), -- Combat Net Radio iso88025Dtr(86), -- ISO 802.5r DTR eplrs(87), -- Ext Pos Loc Report Sys arap(88), -- Appletalk Remote Access Protocol propCnls(89), -- Proprietary Connectionless Protocol hostPad(90), -- CCITT-ITU X.29 PAD Protocol termPad(91), -- CCITT-ITU X.3 PAD Facility frameRelayMPI(92), -- Multiproto Interconnect over FR x213(93), -- CCITT-ITU X213 adsl(94), -- Asymmetric Digital Subscriber Loop radsl(95), -- Rate-Adapt. Digital Subscriber Loop sdsl(96), -- Symmetric Digital Subscriber Loop vdsl(97), -- Very H-Speed Digital Subscrib. Loop iso88025CRFPInt(98), -- ISO 802.5 CRFP myrinet(99), -- Myricom Myrinet voiceEM(100), -- voice recEive and transMit voiceFXO(101), -- voice Foreign Exchange Office voiceFXS(102), -- voice Foreign Exchange Station voiceEncap(103), -- voice encapsulation voiceOverIp(104), -- voice over IP encapsulation atmDxi(105), -- ATM DXI atmFuni(106), -- ATM FUNI atmIma (107), -- ATM IMA pppMultilinkBundle(108), -- PPP Multilink Bundle ipOverCdlc (109), -- IBM ipOverCdlc ipOverClaw (110), -- IBM Common Link Access to Workstn stackToStack (111), -- IBM stackToStack virtualIpAddress (112), -- IBM VIPA mpc (113), -- IBM multi-protocol channel support ipOverAtm (114), -- IBM ipOverAtm iso88025Fiber (115), -- ISO 802.5j Fiber Token Ring tdlc (116), -- IBM twinaxial data link control gigabitEthernet (117), -- Obsoleted via RFC3635 -- ethernetCsmacd (6) should be used instead hdlc (118), -- HDLC lapf (119), -- LAP F v37 (120), -- V.37 x25mlp (121), -- Multi-Link Protocol x25huntGroup (122), -- X25 Hunt Group transpHdlc (123), -- Transp HDLC interleave (124), -- Interleave channel fast (125), -- Fast channel ip (126), -- IP (for APPN HPR in IP networks) docsCableMaclayer (127), -- CATV Mac Layer docsCableDownstream (128), -- CATV Downstream interface docsCableUpstream (129), -- CATV Upstream interface a12MppSwitch (130), -- Avalon Parallel Processor tunnel (131), -- Encapsulation interface coffee (132), -- coffee pot ces (133), -- Circuit Emulation Service atmSubInterface (134), -- ATM Sub Interface l2vlan (135), -- Layer 2 Virtual LAN using 802.1Q l3ipvlan (136), -- Layer 3 Virtual LAN using IP l3ipxvlan (137), -- Layer 3 Virtual LAN using IPX digitalPowerline (138), -- IP over Power Lines mediaMailOverIp (139), -- Multimedia Mail over IP dtm (140), -- Dynamic syncronous Transfer Mode dcn (141), -- Data Communications Network ipForward (142), -- IP Forwarding Interface msdsl (143), -- Multi-rate Symmetric DSL ieee1394 (144), -- IEEE1394 High Performance Serial Bus if-gsn (145), -- HIPPI-6400 dvbRccMacLayer (146), -- DVB-RCC MAC Layer dvbRccDownstream (147), -- DVB-RCC Downstream Channel dvbRccUpstream (148), -- DVB-RCC Upstream Channel atmVirtual (149), -- ATM Virtual Interface mplsTunnel (150), -- MPLS Tunnel Virtual Interface srp (151), -- Spatial Reuse Protocol voiceOverAtm (152), -- Voice Over ATM voiceOverFrameRelay (153), -- Voice Over Frame Relay idsl (154), -- Digital Subscriber Loop over ISDN compositeLink (155), -- Avici Composite Link Interface ss7SigLink (156), -- SS7 Signaling Link propWirelessP2P (157), -- Prop. P2P wireless interface frForward (158), -- Frame Forward Interface rfc1483 (159), -- Multiprotocol over ATM AAL5 usb (160), -- USB Interface ieee8023adLag (161), -- IEEE 802.3ad Link Aggregate bgppolicyaccounting (162), -- BGP Policy Accounting frf16MfrBundle (163), -- FRF .16 Multilink Frame Relay h323Gatekeeper (164), -- H323 Gatekeeper h323Proxy (165), -- H323 Voice and Video Proxy mpls (166), -- MPLS mfSigLink (167), -- Multi-frequency signaling link hdsl2 (168), -- High Bit-Rate DSL - 2nd generation shdsl (169), -- Multirate HDSL2 ds1FDL (170), -- Facility Data Link 4Kbps on a DS1 pos (171), -- Packet over SONET/SDH Interface dvbAsiIn (172), -- DVB-ASI Input dvbAsiOut (173), -- DVB-ASI Output plc (174), -- Power Line Communtications nfas (175), -- Non Facility Associated Signaling tr008 (176), -- TR008 gr303RDT (177), -- Remote Digital Terminal gr303IDT (178), -- Integrated Digital Terminal isup (179), -- ISUP propDocsWirelessMaclayer (180), -- Cisco proprietary Maclayer propDocsWirelessDownstream (181), -- Cisco proprietary Downstream propDocsWirelessUpstream (182), -- Cisco proprietary Upstream hiperlan2 (183), -- HIPERLAN Type 2 Radio Interface propBWAp2Mp (184), -- PropBroadbandWirelessAccesspt2multipt -- use of this iftype for IEEE 802.16 WMAN -- interfaces as per IEEE Std 802.16f is -- deprecated and ifType 237 should be used instead. sonetOverheadChannel (185), -- SONET Overhead Channel digitalWrapperOverheadChannel (186), -- Digital Wrapper aal2 (187), -- ATM adaptation layer 2 radioMAC (188), -- MAC layer over radio links atmRadio (189), -- ATM over radio links imt (190), -- Inter Machine Trunks mvl (191), -- Multiple Virtual Lines DSL reachDSL (192), -- Long Reach DSL frDlciEndPt (193), -- Frame Relay DLCI End Point atmVciEndPt (194), -- ATM VCI End Point opticalChannel (195), -- Optical Channel opticalTransport (196), -- Optical Transport propAtm (197), -- Proprietary ATM voiceOverCable (198), -- Voice Over Cable Interface infiniband (199), -- Infiniband teLink (200), -- TE Link q2931 (201), -- Q.2931 virtualTg (202), -- Virtual Trunk Group sipTg (203), -- SIP Trunk Group sipSig (204), -- SIP Signaling docsCableUpstreamChannel (205), -- CATV Upstream Channel econet (206), -- Acorn Econet pon155 (207), -- FSAN 155Mb Symetrical PON interface pon622 (208), -- FSAN622Mb Symetrical PON interface bridge (209), -- Transparent bridge interface linegroup (210), -- Interface common to multiple lines voiceEMFGD (211), -- voice E&M Feature Group D voiceFGDEANA (212), -- voice FGD Exchange Access North American voiceDID (213), -- voice Direct Inward Dialing mpegTransport (214), -- MPEG transport interface sixToFour (215), -- 6to4 interface (DEPRECATED) gtp (216), -- GTP (GPRS Tunneling Protocol) pdnEtherLoop1 (217), -- Paradyne EtherLoop 1 pdnEtherLoop2 (218), -- Paradyne EtherLoop 2 opticalChannelGroup (219), -- Optical Channel Group homepna (220), -- HomePNA ITU-T G.989 gfp (221), -- Generic Framing Procedure (GFP) ciscoISLvlan (222), -- Layer 2 Virtual LAN using Cisco ISL actelisMetaLOOP (223), -- Acteleis proprietary MetaLOOP High Speed Link fcipLink (224), -- FCIP Link rpr (225), -- Resilient Packet Ring Interface Type qam (226), -- RF Qam Interface lmp (227), -- Link Management Protocol cblVectaStar (228), -- Cambridge Broadband Networks Limited VectaStar docsCableMCmtsDownstream (229), -- CATV Modular CMTS Downstream Interface adsl2 (230), -- Asymmetric Digital Subscriber Loop Version 2 -- (DEPRECATED/OBSOLETED - please use adsl2plus 238 instead) macSecControlledIF (231), -- MACSecControlled macSecUncontrolledIF (232), -- MACSecUncontrolled aviciOpticalEther (233), -- Avici Optical Ethernet Aggregate atmbond (234), -- atmbond voiceFGDOS (235), -- voice FGD Operator Services mocaVersion1 (236), -- MultiMedia over Coax Alliance (MoCA) Interface -- as documented in information provided privately to IANA ieee80216WMAN (237), -- IEEE 802.16 WMAN interface adsl2plus (238), -- Asymmetric Digital Subscriber Loop Version 2, -- Version 2 Plus and all variants dvbRcsMacLayer (239), -- DVB-RCS MAC Layer dvbTdm (240), -- DVB Satellite TDM dvbRcsTdma (241), -- DVB-RCS TDMA x86Laps (242), -- LAPS based on ITU-T X.86/Y.1323 wwanPP (243), -- 3GPP WWAN wwanPP2 (244), -- 3GPP2 WWAN voiceEBS (245), -- voice P-phone EBS physical interface ifPwType (246), -- Pseudowire interface type ilan (247), -- Internal LAN on a bridge per IEEE 802.1ap pip (248), -- Provider Instance Port on a bridge per IEEE 802.1ah PBB aluELP (249), -- Alcatel-Lucent Ethernet Link Protection gpon (250), -- Gigabit-capable passive optical networks (G-PON) as per ITU-T G.948 vdsl2 (251), -- Very high speed digital subscriber line Version 2 (as per ITU-T Recommendation G.993.2) capwapDot11Profile (252), -- WLAN Profile Interface capwapDot11Bss (253), -- WLAN BSS Interface capwapWtpVirtualRadio (254) -- WTP Virtual Radio Interface } IANAtunnelType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The encapsulation method used by a tunnel. The value direct indicates that a packet is encapsulated directly within a normal IP header, with no intermediate header, and unicast to the remote tunnel endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC 1933 IPv6-in-IPv4 tunnel). The value minimal indicates that a Minimal Forwarding Header (RFC 2004) is inserted between the outer header and the payload packet. The value UDP indicates that the payload packet is encapsulated within a normal UDP packet (e.g., RFC 1234). The values sixToFour, sixOverFour, and isatap indicates that an IPv6 packet is encapsulated directly within an IPv4 header, with no intermediate header, and unicast to the destination determined by the 6to4, 6over4, or ISATAP protocol. The remaining protocol-specific values indicate that a header of the protocol of that name is inserted between the outer header and the payload header. The assignment policy for IANAtunnelType values is identical to the policy for assigning IANAifType values." SYNTAX INTEGER { other(1), -- none of the following direct(2), -- no intermediate header gre(3), -- GRE encapsulation minimal(4), -- Minimal encapsulation l2tp(5), -- L2TP encapsulation pptp(6), -- PPTP encapsulation l2f(7), -- L2F encapsulation udp(8), -- UDP encapsulation atmp(9), -- ATMP encapsulation msdp(10), -- MSDP encapsulation sixToFour(11), -- 6to4 encapsulation sixOverFour(12), -- 6over4 encapsulation isatap(13), -- ISATAP encapsulation teredo(14), -- Teredo encapsulation ipHttps(15) -- IPHTTPS } END snmp-mibs-downloader-1.1/mibiana/ianaipfixselector-mib0000644000000000000000000001411511402176070020103 0ustar IPFIX-SELECTOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI -- RFC2578 TruthValue FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- RFC2580 ipfixSelectorMIB MODULE-IDENTITY LAST-UPDATED "201004190000Z" -- 19 April 2010 ORGANIZATION "IETF IPFIX Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/ipfix-charter.html Mailing Lists: General Discussion: ipfix&ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix Archive: http://www1.ietf.org/mail-archive/web/ipfix/current/index.html Editor: Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-128 Email: Thomas.Dietz&nw.neclab.eu Atsushi Kobayashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi 180-8585 Japan Phone: +81-422-59-3978 Email: akoba&nttv6.net Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise&cisco.com Gerhard Muenz Technische Universitaet Muenchen Department of Informatics Chair for Network Architectures and Services (I8) Boltzmannstr. 3 85748 Garching Germany Phone: +49 89 289-18008 Email: muenz&net.in.tum.de URI: http://www.net.in.tum.de/~muenz" DESCRIPTION "The IPFIX SELECTOR MIB module defines the standard filtering and sampling functions that can be referenced in the ipfixSelectorTable of the IPFIX MIB. The subtree ipfixSelectorFunctions is a placeholder where all standard filtering and sampling functions should be located. The IPFIX SELECTOR MIB module is maintained by IANA and can be extended through Expert Review [RFC5226], i.e. review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OID SHOULD be assigned to a new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in [RFC5815] and MUST be published using a well-established and persistent publication medium. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This version of this MIB module is part of [RFC5815]; see the RFC itself for full legal notices." -- Revision history REVISION "200906020900Z" -- 02 June 2009 DESCRIPTION "Initial version, published as [RFC5815]." ::= { mib-2 194 } --****************************************************************** -- Top Level Structure of the MIB --****************************************************************** ipfixSelectorObjects OBJECT IDENTIFIER ::= { ipfixSelectorMIB 1 } ipfixSelectorConformance OBJECT IDENTIFIER ::= { ipfixSelectorMIB 2 } --================================================================== -- 1: Objects used by all IPFIX implementations --================================================================== -------------------------------------------------------------------- -- 1.1: Packet Selector Functions for IPFIX -------------------------------------------------------------------- ipfixSelectorFunctions OBJECT IDENTIFIER ::= { ipfixSelectorObjects 1 } -------------------------------------------------------------------- -- 1.1.1: Function 1: Selecting All Packets -------------------------------------------------------------------- ipfixFuncSelectAll OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 1 } ipfixFuncSelectAllAvail OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the availability of the trivial function of selecting all packets. This function is always available." ::= { ipfixFuncSelectAll 1 } --================================================================== -- 2: Conformance Information --================================================================== ipfixSelectorCompliances OBJECT IDENTIFIER ::= { ipfixSelectorConformance 1 } ipfixSelectorGroups OBJECT IDENTIFIER ::= { ipfixSelectorConformance 2 } -------------------------------------------------------------------- -- 2.1: Compliance Statements -------------------------------------------------------------------- ipfixSelectorBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "An implementation that builds an IPFIX Exporter that complies to this module MUST implement the objects defined in the mandatory group ipfixBasicGroup. The implementation of all other objects depends on the implementation of the corresponding functionality in the equipment." MODULE -- this module MANDATORY-GROUPS { ipfixSelectorBasicGroup } ::= { ipfixSelectorCompliances 1 } -------------------------------------------------------------------- -- 2.2: MIB Grouping -------------------------------------------------------------------- ipfixSelectorBasicGroup OBJECT-GROUP OBJECTS { ipfixFuncSelectAllAvail } STATUS current DESCRIPTION "The main IPFIX objects." ::= { ipfixSelectorGroups 1 } END snmp-mibs-downloader-1.1/mibiana/ianalanguage-mib0000644000000000000000000001101511402176070017002 0ustar IANA-LANGUAGE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI; ianaLanguages MODULE-IDENTITY LAST-UPDATED "200005100000Z" -- May 10, 2000 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority (IANA) Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 x20 E-Mail: iana&iana.org" DESCRIPTION "The MIB module registers object identifier values for well-known programming and scripting languages. Every language registration MUST describe the format used when transferring scripts written in this language. Any additions or changes to the contents of this MIB module require Designated Expert Review as defined in the Guidelines for Writing IANA Considerations Section document. The Designated Expert will be selected by the IESG Area Director of the OPS Area. Note, this module does not have to register all possible languages since languages are identified by object identifier values. It is therefore possible to registered languages in private OID trees. The references given below are not normative with regard to the language version. Other references might be better suited to describe some newer versions of this language. The references are only provided as `a pointer into the right direction'." -- Revision log, in reverse chronological order REVISION "200005100000Z" -- May 10, 2000 DESCRIPTION "Import mib-2 instead of experimental, so that this module compiles" REVISION "199909090900Z" -- September 9, 1999 DESCRIPTION "Initial version as published at time of publication of RFC 2591." ::= { mib-2 73 } ianaLangJavaByteCode OBJECT-IDENTITY STATUS current DESCRIPTION "Java byte code to be processed by a Java virtual machine. A script written in Java byte code is transferred by using the Java archive file format (JAR)." REFERENCE "The Java Virtual Machine Specification. ISBN 0-201-63452-X" ::= { ianaLanguages 1 } ianaLangTcl OBJECT-IDENTITY STATUS current DESCRIPTION "The Tool Command Language (Tcl). A script written in the Tcl language is transferred in Tcl source code format." REFERENCE "Tcl and the Tk Toolkit. ISBN 0-201-63337-X" ::= { ianaLanguages 2 } ianaLangPerl OBJECT-IDENTITY STATUS current DESCRIPTION "The Perl language. A script written in the Perl language is transferred in Perl source code format." REFERENCE "Programming Perl. ISBN 1-56592-149-6" ::= { ianaLanguages 3 } ianaLangScheme OBJECT-IDENTITY STATUS current DESCRIPTION "The Scheme language. A script written in the Scheme language is transferred in Scheme source code format." REFERENCE "The Revised^4 Report on the Algorithmic Language Scheme. MIT Press" ::= { ianaLanguages 4 } ianaLangSRSL OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP Script Language defined by SNMP Research. A script written in the SNMP Script Language is transferred in the SNMP Script Language source code format." ::= { ianaLanguages 5 } ianaLangPSL OBJECT-IDENTITY STATUS current DESCRIPTION "The Patrol Script Language defined by BMC Software. A script written in the Patrol Script Language is transferred in the Patrol Script Language source code format." REFERENCE "PATROL Script Language Reference Manual, Version 3.0, November 30, 1995. BMC Software, Inc. 2101 City West Blvd., Houston, Texas 77042." ::= { ianaLanguages 6 } ianaLangSMSL OBJECT-IDENTITY STATUS current DESCRIPTION "The Systems Management Scripting Language. A script written in the SMSL language is transferred in the SMSL source code format." REFERENCE "ISO/ITU Command Sequencer. ISO 10164-21 or ITU X.753" ::= { ianaLanguages 7 } END snmp-mibs-downloader-1.1/mibiana/ianaaddressfamilynumbers-mib0000644000000000000000000001153611402176070021452 0ustar IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaAddressFamilyNumbers MODULE-IDENTITY LAST-UPDATED "200203140000Z" -- March 14, 2002 ORGANIZATION "IANA" CONTACT-INFO "Postal: Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6601 USA Tel: +1 310-823-9358 E-Mail: iana&iana.org" DESCRIPTION "The MIB module defines the AddressFamilyNumbers textual convention." -- revision history REVISION "200203140000Z" -- March 14, 2002 DESCRIPTION "AddressFamilyNumbers assignment 22 to fibreChannelWWPN. AddressFamilyNumbers assignment 23 to fibreChannelWWNN. AddressFamilyNumers assignment 24 to gwid." REVISION "200009080000Z" -- September 8, 2000 DESCRIPTION "AddressFamilyNumbers assignment 19 to xtpOverIpv4. AddressFamilyNumbers assignment 20 to xtpOverIpv6. AddressFamilyNumbers assignment 21 to xtpNativeModeXTP." REVISION "200003010000Z" -- March 1, 2000 DESCRIPTION "AddressFamilyNumbers assignment 17 to distinguishedName. AddressFamilyNumbers assignment 18 to asNumber." REVISION "200002040000Z" -- February 4, 2000 DESCRIPTION "AddressFamilyNumbers assignment 16 to dns." REVISION "9908260000Z" -- August 26, 1999 DESCRIPTION "Initial version, published as RFC 2677." ::= { mib-2 72 } AddressFamilyNumbers ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) The enumerations are described as: other(0), -- none of the following ipV4(1), -- IP Version 4 ipV6(2), -- IP Version 6 nsap(3), -- NSAP hdlc(4), -- (8-bit multidrop) bbn1822(5), all802(6), -- (includes all 802 media -- plus Ethernet 'canonical format') e163(7), e164(8), -- (SMDS, Frame Relay, ATM) f69(9), -- (Telex) x121(10), -- (X.25, Frame Relay) ipx(11), -- IPX (Internet Protocol Exchange) appleTalk(12), -- Apple Talk decnetIV(13), -- DEC Net Phase IV banyanVines(14), -- Banyan Vines e164withNsap(15), -- (E.164 with NSAP format subaddress) dns(16), -- (Domain Name System) distinguishedName(17), -- (Distinguished Name, per X.500) asNumber(18), -- (16-bit quantity, per the AS number space) xtpOverIpv4(19), -- XTP over IP version 4 xtpOverIpv6(20), -- XTP over IP version 6 xtpNativeModeXTP(21), -- XTP native mode XTP fibreChannelWWPN(22), -- Fibre Channel World-Wide Port Name fibreChannelWWNN(23), -- Fibre Channel World-Wide Node Name gwid(24), -- Gateway Identifier afi(25), -- AFI for L2VPN information reserved(65535) Requests for new values should be made to IANA via email (iana&iana.org)." SYNTAX INTEGER { other(0), ipV4(1), ipV6(2), nsap(3), hdlc(4), bbn1822(5), all802(6), e163(7), e164(8), f69(9), x121(10), ipx(11), appleTalk(12), decnetIV(13), banyanVines(14), e164withNsap(15), dns(16), distinguishedName(17), -- (Distinguished Name, per X.500) asNumber(18), -- (16-bit quantity, per the AS number space) xtpOverIpv4(19), xtpOverIpv6(20), xtpNativeModeXTP(21), fibreChannelWWPN(22), fibreChannelWWNN(23), gwid(24), afi(25), reserved(65535) } END snmp-mibs-downloader-1.1/mibiana/ianaiprouteprotocol-mib0000644000000000000000000000667611402176070020511 0ustar IANA-RTPROTO-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaRtProtoMIB MODULE-IDENTITY LAST-UPDATED "200009260000Z" -- September 26, 2000 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6601 Phone: +1 310 823 9358 EMail: iana&iana.org" DESCRIPTION "This MIB module defines the IANAipRouteProtocol and IANAipMRouteProtocol textual conventions for use in MIBs which need to identify unicast or multicast routing mechanisms. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Routing Area." REVISION "200009260000Z" -- September 26, 2000 DESCRIPTION "Original version, published in coordination with RFC 2932." ::= { mib-2 84 } IANAipRouteProtocol ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A mechanism for learning routes. Inclusion of values for routing protocols is not intended to imply that those protocols need be supported." SYNTAX INTEGER { other (1), -- not specified local (2), -- local interface netmgmt (3), -- static route icmp (4), -- result of ICMP Redirect -- the following are all dynamic -- routing protocols egp (5), -- Exterior Gateway Protocol ggp (6), -- Gateway-Gateway Protocol hello (7), -- FuzzBall HelloSpeak rip (8), -- Berkeley RIP or RIP-II isIs (9), -- Dual IS-IS esIs (10), -- ISO 9542 ciscoIgrp (11), -- Cisco IGRP bbnSpfIgp (12), -- BBN SPF IGP ospf (13), -- Open Shortest Path First bgp (14), -- Border Gateway Protocol idpr (15), -- InterDomain Policy Routing ciscoEigrp (16), -- Cisco EIGRP dvmrp (17) -- DVMRP } IANAipMRouteProtocol ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The multicast routing protocol. Inclusion of values for multicast routing protocols is not intended to imply that those protocols need be supported." SYNTAX INTEGER { other(1), -- none of the following local(2), -- e.g., manually configured netmgmt(3), -- set via net.mgmt protocol dvmrp(4), mospf(5), pimSparseDense(6), -- PIMv1, both DM and SM cbt(7), pimSparseMode(8), -- PIM-SM pimDenseMode(9), -- PIM-DM igmpOnly(10), bgmp(11), msdp(12) } END snmp-mibs-downloader-1.1/mibiana/ianatn3270etc-mib0000644000000000000000000003014111402176070016651 0ustar IANATn3270eTC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaTn3270eTcMib MODULE-IDENTITY LAST-UPDATED "200005100000Z" -- May 10, 2000 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 x20 E-Mail: iana&iana.org" DESCRIPTION "This module defines a set of textual conventions for use by the TN3270E-MIB and the TN3270E-RT-MIB. Any additions or changes to the contents of this MIB module must first be discussed on the tn3270e working group list at: tn3270e&list.nih.gov and approved by one of the following TN3270E working group contacts: Ed Bailey (co-chair) - elbailey&us.ibm.com Michael Boe (co-chair) - mboe&cisco.com Ken White - kennethw&vnet.ibm.com Robert Moore - remoore&us.ibm.com The above list of contacts can be altered with the approval of the two co-chairs. The Textual Conventions defined within this MIB have no security issues associated with them unless explicitly stated in their corresponding DESCRIPTION clause." -- revision log, in reverse chronological order REVISION "200005100000Z" -- May 10, 2000 DESCRIPTION "Fix to import mib-2 instead of experimental." REVISION "199909011000Z" -- September 1, 1999 DESCRIPTION "Initial version transferred from the TN3270E working group to IANA." ::= { mib-2 61 } -- Textual Conventions IANATn3270eAddrType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for defining the type of a client address. The enumeration value unknown(0) is also used to indicate that no actual address is present." SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } IANATn3270eAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a client address. The type of client address is determined by use of the IANATn3270eAddrType textual convention. The length in octets of a IANATn3270eAddress object is: IANATn3270eAddrType Address Length +++++++++++++++++++ ++++++++++++++ unknown(0) not specified or unknown; the actual length of the IANATn3270eAddress octet string indicates if an address is present ipv4(1) 4 OCTETS ipv6(2) 16 OCTETS This textual convention is similar to the TAddress TC defined by RFC1903 except that it allows a zero-length octet string and is not a full transport layer address." SYNTAX OCTET STRING (SIZE (0..255)) IANATn3270eClientType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for defining the set of enumerations used by tn3270eTcpConnClientIdFormat in the TN3270E-MIB: ENUMERATION OCTETs DESCRIPTION none(1) 0 Not specified other(2) 1..512 Implementation specific ipv4(3) 6 4-octet IP Address plus 2-octet TCP Port ipv6(4) 18 16-octet IPv6 Address plus 2-octet TCP Port domainName(5) 1..512 The DNS name of a client. truncDomainName(6) 1..512 The (truncated) DNS name of a client. string(7) 1..512 Unknown Utf8String certificate(8) 1..512 certificate userId(9) 1..8 Client's userid x509dn(10) 1..512 X.509 Distinguished Name Representation of a certificate(8) may be lead to a security exposure and is NOT RECOMMENDED without adequate security." SYNTAX INTEGER { none(1), other(2), ipv4(3), ipv6(4), domainName(5), truncDomainName(6), string(7), certificate(8), userId(9), x509dn(10) } IANATn3270Functions ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention reflects the current set of TN3270 and TN3270E functions that can be negotiated between a server and its client: RFC856 transmitBinary The sender of this command REQUESTS permission to begin transmitting, or confirms that it will now begin transmitting characters which are to be interpreted as 8 bits of binary data by the receiver of the data. RFC860 timingMark The sender of this command REQUESTS that the receiver of this command return a WILL TIMING-MARK in the data stream at the 'appropriate place'. RFC885 endOfRecord The sender of this command requests permission to begin transmission of the Telnet END-OF-RECORD (EOR) code when transmitting data characters, or the sender of this command confirms it will now begin transmission of EORs with transmitted data characters. RFC1091 terminalType Sender is willing to send terminal type information in a subsequent sub-negotiation. RFC1041 tn3270Regime Sender is willing to send list of supported 3270 Regimes in a subsequent sub-negotiation. RFC2355 scsCtlCodes (Printer sessions only). Allows the use of the SNA Character Stream (SCS) and SCS control codes on the session. SCS is used with LU type 1 SNA sessions. dataStreamCtl (Printer sessions only). Allows the use of the standard 3270 data stream. This corresponds to LU type 3 SNA sessions. responses Provides support for positive and negative response handling. Allows the server to reflect to the client any and all definite, exception, and no response requests sent by the host application. bindImage Allows the server to send the SNA Bind image and Unbind notification to the client. sysreq Allows the client and server to emulate some (or all, depending on the server) of the functions of the SYSREQ key in an SNA environment." SYNTAX BITS { transmitBinary(0),-- rfc856 timemark(1), -- rfc860 endOfRecord(2), -- rfc885 terminalType(3), -- rfc1091 tn3270Regime(4), -- rfc1041 scsCtlCodes(5), -- rfc2355 dataStreamCtl(6), -- rfc2355 responses(7), -- rfc2355 bindImage(8), -- rfc2355 sysreq(9) -- rfc2355 } IANATn3270ResourceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of resource defined by a resource pool. Refer to tn3270eResPoolTable." SYNTAX INTEGER { other(1), terminal(2), printer(3), terminalOrPrinter(4) } IANATn3270DeviceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention defines the list of device types that can be set, as defined by RFC 2355." SYNTAX INTEGER { -- terminals ibm3278d2(1), -- (24 row x 80 col display) ibm3278d2E(2), -- (24 row x 80 col display) ibm3278d3(3), -- (32 row x 80 col display) ibm3278d3E(4), -- (32 row x 80 col display) ibm3278d4(5), -- (43 row x 80 col display) ibm3278d4E(6), -- (43 row x 80 col display) ibm3278d5(7), -- (27 row x 132 col display) ibm3278d5E(8), -- (27 row x 132 col display) ibmDynamic(9), -- (no pre-defined display size) -- printers ibm3287d1(10), unknown(100) } IANATn3270eLogData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An octet string representing log data as pertaining to either a TN3270 or TN3270E Session as reported from a TN3270E Server. Log data is stored in an octet string in time order (from earliest to latest). Each log element has the following form: +------+----+---------+------------+ !length!type!TimeStamp! data ! +------+----+---------+------------+ where length = one-octet length of the data portion of the trace element, not including the length, type, and TimeStamp fields type = one-octet code point characterizing the data. TimeStamp = A 4-octet field representing the number of TimeTicks since the TN3270E server was last activated. The server's last activation time is available in the tn3270eSrvrConfLastActTime object in the TN3270E MIB, which has the syntax DateAndTime. data = initial part of a PDU. length type 0-255 x'00' - unknown 0 x'01' - inactivity timer expired 0 x'02' - dynamic timer expired 0 x'03' - actlu req 0 x'04' - bind req 0 x'05' - clear req 0 x'06' - dactlu req 0 x'07' - warm actpu req 0 x'08' - sdt req 0 x'09' - unbind req 0 x'0A' - notify resp 0 x'0B' - reply PSID neg rsp 0 x'0C' - reply PSID pos rsp 0 x'0D' - unbind rsp 0 x'0E' - hierarchical reset 0 x'0F' - client connect req 0 x'10' - client disconnect req 0 x'11' - timingmark received 0 x'12' - flowControl timer expired 0 x'13' - neg rsp to host 0 x'14' - neg rsp from host 0 x'15' - data contention 0 x'16' - no buffer to send SNA data 0 x'17' - receive response while inbound 0 x'18' - client protocol error 0 x'19' - badClientSequenceReceived 1-255 x'1A' - utf8String 2 x'1B' - hexCode, implementation dependent Log element entries have a minimum length of 6 octets. The zero-length string indicates that no log data is available." SYNTAX OCTET STRING (SIZE (0 | 6..2048)) END snmp-mibs-downloader-1.1/mibiana/ianamalloc-mib0000644000000000000000000000446111402176070016475 0ustar IANA-MALLOC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaMallocMIB MODULE-IDENTITY LAST-UPDATED "200301271200Z" -- January 27, 2003 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6601 Phone: +1 310 823 9358 EMail: iana&iana.org" DESCRIPTION "This MIB module defines the IANAscopeSource and IANAmallocRangeSource textual conventions for use in MIBs which need to identify ways of learning multicast scope and range information. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in the Guidelines for Writing IANA Considerations Section document. The Designated Expert will be selected by the IESG Area Director(s) of the Transport Area." -- revision log REVISION "200301271200Z" -- January 27, 2003 DESCRIPTION "Initial version." ::= { mib-2 102 } IANAscopeSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The source of multicast scope information." SYNTAX INTEGER { other(1), -- none of the following manual(2), -- statically configured local(3), -- automatically added by the system, -- such as a Source-Specific Multicast -- scope mzap(4), -- MZAP madcap(5) -- MADCAP } IANAmallocRangeSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The source of multicast address allocation range information." SYNTAX INTEGER { other(1), -- none of the following manual(2), -- statically configured local(3) -- automatically added by the system, -- such as a Source-Specific Multicast -- range } END snmp-mibs-downloader-1.1/mibiana/ianacharset-mib0000644000000000000000000002451011402176070016654 0ustar IANA-CHARSET-MIB DEFINITIONS ::= BEGIN -- http://www.iana.org/assignments/ianacharset-mib IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ianaCharsetMIB MODULE-IDENTITY LAST-UPDATED "200705140000Z" ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" DESCRIPTION "This MIB module defines the IANACharset TEXTUAL-CONVENTION. The IANACharset TC is used to specify the encoding of string objects defined in a MIB. Each version of this MIB will be released based on the IANA Charset Registry file (see RFC 2978) at http://www.iana.org/assignments/character-sets. Note: The IANACharset TC, originally defined in RFC 1759, was inaccurately named CodedCharSet. Note: Best practice is to define new MIB string objects with invariant UTF-8 (RFC 3629) syntax using the SnmpAdminString TC (defined in RFC 3411) in accordance with IETF Policy on Character Sets and Languages (RFC 2277). Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3808; for full legal notices see the RFC itself. Supplementary information may be available on http://www.ietf.org/copyrights/ianamib.html." -- revision history REVISION "200705140000Z" DESCRIPTION "Registration of new charset 2107." REVISION "200612070000Z" DESCRIPTION "Registration of new charsets numbered 118, 119, and 2106." REVISION "200406080000Z" DESCRIPTION "Original version transferred from Printer MIB, generated from the IANA maintained assignments http://www.iana.org/assignments/character-sets." ::= { mib-2 106 } IANACharset ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies an IANA registered 'charset' - coded character set (CCS) plus optional character encoding scheme (CES) - terms defined in 'IANA Charset Registration Procedures' (RFC 2978). Objects of this syntax are used to specify the encoding for string objects defined in one or more MIBs. For example, the prtLocalizationCharacterSet, prtInterpreterDefaultCharSetIn, and prtInterpreterDefaultCharSetOut objects defined in Printer MIB. The current list of 'charset' names and enumerated values is contained in the IANA Character Set Registry at: http://www.iana.org/assignments/character-sets Enum names are derived from the IANA Charset Registry 'Alias' fields that begin with 'cs' (for character set). Enum values are derived from the parallel 'MIBenum' fields." SYNTAX INTEGER { other(1), -- used if the designated -- character set is not currently -- registered by IANA unknown(2), -- used as a default value csASCII(3), csISOLatin1(4), csISOLatin2(5), csISOLatin3(6), csISOLatin4(7), csISOLatinCyrillic(8), csISOLatinArabic(9), csISOLatinGreek(10), csISOLatinHebrew(11), csISOLatin5(12), csISOLatin6(13), csISOTextComm(14), csHalfWidthKatakana(15), csJISEncoding(16), csShiftJIS(17), csEUCPkdFmtJapanese(18), csEUCFixWidJapanese(19), csISO4UnitedKingdom(20), csISO11SwedishForNames(21), csISO15Italian(22), csISO17Spanish(23), csISO21German(24), csISO60DanishNorwegian(25), csISO69French(26), csISO10646UTF1(27), csISO646basic1983(28), csINVARIANT(29), csISO2IntlRefVersion(30), csNATSSEFI(31), csNATSSEFIADD(32), csNATSDANO(33), csNATSDANOADD(34), csISO10Swedish(35), csKSC56011987(36), csISO2022KR(37), csEUCKR(38), csISO2022JP(39), csISO2022JP2(40), csISO13JISC6220jp(41), csISO14JISC6220ro(42), csISO16Portuguese(43), csISO18Greek7Old(44), csISO19LatinGreek(45), csISO25French(46), csISO27LatinGreek1(47), csISO5427Cyrillic(48), csISO42JISC62261978(49), csISO47BSViewdata(50), csISO49INIS(51), csISO50INIS8(52), csISO51INISCyrillic(53), csISO54271981(54), csISO5428Greek(55), csISO57GB1988(56), csISO58GB231280(57), csISO61Norwegian2(58), csISO70VideotexSupp1(59), csISO84Portuguese2(60), csISO85Spanish2(61), csISO86Hungarian(62), csISO87JISX0208(63), csISO88Greek7(64), csISO89ASMO449(65), csISO90(66), csISO91JISC62291984a(67), csISO92JISC62991984b(68), csISO93JIS62291984badd(69), csISO94JIS62291984hand(70), csISO95JIS62291984handadd(71), csISO96JISC62291984kana(72), csISO2033(73), csISO99NAPLPS(74), csISO102T617bit(75), csISO103T618bit(76), csISO111ECMACyrillic(77), csa71(78), csa72(79), csISO123CSAZ24341985gr(80), csISO88596E(81), csISO88596I(82), csISO128T101G2(83), csISO88598E(84), csISO88598I(85), csISO139CSN369103(86), csISO141JUSIB1002(87), csISO143IECP271(88), csISO146Serbian(89), csISO147Macedonian(90), csISO150(91), csISO151Cuba(92), csISO6937Add(93), csISO153GOST1976874(94), csISO8859Supp(95), csISO10367Box(96), csISO158Lap(97), csISO159JISX02121990(98), csISO646Danish(99), csUSDK(100), csDKUS(101), csKSC5636(102), csUnicode11UTF7(103), csISO2022CN(104), csISO2022CNEXT(105), csUTF8(106), csISO885913(109), csISO885914(110), csISO885915(111), csISO885916(112), csGBK(113), csGB18030(114), csOSDEBCDICDF0415(115), csOSDEBCDICDF03IRV(116), csOSDEBCDICDF041(117), csISO115481(118), csKZ1048(119), csUnicode(1000), csUCS4(1001), csUnicodeASCII(1002), csUnicodeLatin1(1003), csUnicodeIBM1261(1005), csUnicodeIBM1268(1006), csUnicodeIBM1276(1007), csUnicodeIBM1264(1008), csUnicodeIBM1265(1009), csUnicode11(1010), csSCSU(1011), csUTF7(1012), csUTF16BE(1013), csUTF16LE(1014), csUTF16(1015), csCESU8(1016), csUTF32(1017), csUTF32BE(1018), csUTF32LE(1019), csBOCU1(1020), csWindows30Latin1(2000), csWindows31Latin1(2001), csWindows31Latin2(2002), csWindows31Latin5(2003), csHPRoman8(2004), csAdobeStandardEncoding(2005), csVenturaUS(2006), csVenturaInternational(2007), csDECMCS(2008), csPC850Multilingual(2009), csPCp852(2010), csPC8CodePage437(2011), csPC8DanishNorwegian(2012), csPC862LatinHebrew(2013), csPC8Turkish(2014), csIBMSymbols(2015), csIBMThai(2016), csHPLegal(2017), csHPPiFont(2018), csHPMath8(2019), csHPPSMath(2020), csHPDesktop(2021), csVenturaMath(2022), csMicrosoftPublishing(2023), csWindows31J(2024), csGB2312(2025), csBig5(2026), csMacintosh(2027), csIBM037(2028), csIBM038(2029), csIBM273(2030), csIBM274(2031), csIBM275(2032), csIBM277(2033), csIBM278(2034), csIBM280(2035), csIBM281(2036), csIBM284(2037), csIBM285(2038), csIBM290(2039), csIBM297(2040), csIBM420(2041), csIBM423(2042), csIBM424(2043), csIBM500(2044), csIBM851(2045), csIBM855(2046), csIBM857(2047), csIBM860(2048), csIBM861(2049), csIBM863(2050), csIBM864(2051), csIBM865(2052), csIBM868(2053), csIBM869(2054), csIBM870(2055), csIBM871(2056), csIBM880(2057), csIBM891(2058), csIBM903(2059), csIBBM904(2060), csIBM905(2061), csIBM918(2062), csIBM1026(2063), csIBMEBCDICATDE(2064), csEBCDICATDEA(2065), csEBCDICCAFR(2066), csEBCDICDKNO(2067), csEBCDICDKNOA(2068), csEBCDICFISE(2069), csEBCDICFISEA(2070), csEBCDICFR(2071), csEBCDICIT(2072), csEBCDICPT(2073), csEBCDICES(2074), csEBCDICESA(2075), csEBCDICESS(2076), csEBCDICUK(2077), csEBCDICUS(2078), csUnknown8BiT(2079), csMnemonic(2080), csMnem(2081), csVISCII(2082), csVIQR(2083), csKOI8R(2084), csHZGB2312(2085), csIBM866(2086), csPC775Baltic(2087), csKOI8U(2088), csIBM00858(2089), csIBM00924(2090), csIBM01140(2091), csIBM01141(2092), csIBM01142(2093), csIBM01143(2094), csIBM01144(2095), csIBM01145(2096), csIBM01146(2097), csIBM01147(2098), csIBM01148(2099), csIBM01149(2100), csBig5HKSCS(2101), csIBM1047(2102), csPTCP154(2103), csAmiga1251(2104), csKOI7switched(2105), csBRF(2106), csTSCII(2107), cswindows1250(2250), cswindows1251(2251), cswindows1252(2252), cswindows1253(2253), cswindows1254(2254), cswindows1255(2255), cswindows1256(2256), cswindows1257(2257), cswindows1258(2258), csTIS620(2259), reserved(3000) } END snmp-mibs-downloader-1.1/mibiana/ianaprinter-mib0000644000000000000000000030367711402176070016724 0ustar IANA-PRINTER-MIB DEFINITIONS ::= BEGIN -- http://www.iana.org/assignments/ianaprinter-mib IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ianaPrinterMIB MODULE-IDENTITY LAST-UPDATED "201005150000Z" -- May 17, 2010 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" DESCRIPTION "This MIB module defines a set of printing-related TEXTUAL-CONVENTIONs for use in Printer MIB (RFC 3805), Finisher MIB (RFC 3806), and other MIBs which need to specify printing mechanism details. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Applications Area. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3805. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" REVISION "201005170000Z" -- May 17, 2010 DESCRIPTION "Added 72-83 in PrtInterpreterLangFamilyTC, 600+ lines from 30203-31838 in PrtAlertCodeTC." REVISION "201004070000Z" -- April 7, 2010 DESCRIPTION "Added langJDF(68), langJMF(69), langPPML(70), and langXHTMLPrint(71)." REVISION "200911230000Z" -- November 23, 2009 DESCRIPTION "Added langXPS(66) and langOpenXPS(67)." REVISION "200910140000Z" -- October 14, 2009 DESCRIPTION "Added references for langPCLXL(47), langART(48), and langTIPSI(49)." REVISION "200902060000Z" -- February 6, 2009 DESCRIPTION "Added chWSPrint(46) 'Channel Type' for Web Services based printing." REVISION "200509140000Z" -- September 14, 2005 DESCRIPTION "Updates to include missing 'unknown' values for PrtCoverStatusTC, PrtChannelTypeTC, PrtAlertGroupTC and removal of comment for for PrtAlertGroupTC." REVISION "200406020000Z" -- June 2, 2004 DESCRIPTION "Original version, published in coordination with Printer MIB (RFC 3805)." ::= { mib-2 109 } -- -- Generic TEXTUAL-CONVENTIONs -- PrtCoverStatusTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtCoverStatus in RFC 1759. STATUS current DESCRIPTION "Values for encoding the state of a particular cover or access panel on the printer case or enclosure." SYNTAX INTEGER { other(1), unknown(2), coverOpen(3), coverClosed(4), interlockOpen(5), interlockClosed(6) } -- -- General Group TEXTUAL-CONVENTIONs -- PrtGeneralResetTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtGeneralReset in RFC 1759. STATUS current DESCRIPTION "Values for reading and writing the prtGeneralReset object. If a device does not have NVRAM, the device shall none the less respond to a SET with the value resetToNVRAM(5) with a sort of warm reset that resets the device to implementation- defined state that is preferably under control of the system administrator by some means outside the scope of the Printer MIB specification." SYNTAX INTEGER { notResetting(3), powerCycleReset(4), -- Cold Start resetToNVRAM(5), -- Warm Start resetToFactoryDefaults(6) -- Reset contents of -- NVRAM to factory -- defaults } -- -- Channel Group TEXTUAL-CONVENTIONs -- PrtChannelTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtChannelType in RFC 1759. STATUS current DESCRIPTION "This enumeration indicates the type of channel that is receiving jobs." SYNTAX INTEGER { other(1), unknown(2), chSerialPort(3), chParallelPort(4), chIEEE1284Port(5), chSCSIPort(6), chAppleTalkPAP(7), -- AppleTalk Printer -- Access Protocol (PAP) -- -- prtChannelInformation entry: -- -- Printer Name -- Keyword: Name -- Syntax: Name -- Status: Optional -- Multiplicity: Single -- Description: The name of the printer -- within the AppleTalk naming scope chLPDServer(8), -- prtChannelInformation entry: -- -- Printer queue name -- Keyword: Queue -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: queue name as -- defined in [RFC1179]. chNetwareRPrinter(9), -- Novell, Inc. -- For each entry of this type, the -- prtChannelInformation must have a pair of -- keywords. For Netware 3.x channels this must -- be a (PServer, Printer) pair. For Netware -- 4.x channels and for IntranetWare channels -- this must be a (NDSTree, NDSPrinter) pair. -- -- prtChannelInformation entries: -- Print Server Name -- Keyword: PServer -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The Pserver's SAP name -- -- Printer Number -- Keyword: Printer -- Syntax: Integer -- Status: Mandatory -- Multiplicity: Single -- Description: The printer number -- -- NDSTree -- Keyword: NDSTree -- Syntax: Name -- Multiplicity: Single -- Description: The tree's SAP name -- -- NDS Printer object -- Keyword: NDSPrinter -- Syntax: Text (Unicode) -- Status: Mandatory -- Multiplicity: Single -- Description: The fully qualified -- name of the Printer -- -- In the Netware 3.x environment, the -- client checks the Bindery object -- representing the named PServer. The -- client then checks for queues which -- are associated with the numbered -- printer. In the 4.x and IntraNetware -- environment, the client looks up the -- queues which are associated with the -- NDS Printer Object in the named Tree. -- Depending on client access rights to -- those queues, the client submits jobs -- to the appropriate queue. chNetwarePServer(10), -- Novell,Inc. -- For each entry of this type, the -- prtChannelInformation must have a pair -- of keywords. For Netware 3.x channels -- this must be a (Server, PServer) pair. -- For Netware 4.x and IntranetWare -- channels, this must be a -- (NDSTree, NDSPServer) pair. -- -- prtChannelInformation entries: -- -- Server Name -- Keyword: Server -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The SAP name of the -- server for which the PServer is defined. -- -- PServer -- Keyword: PServer -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The bindery name of -- the PServer -- -- NDS Tree -- Keyword: NDSTree -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The NDS Tree name -- -- PServer -- Keyword: NDSPServer -- Syntax: Text (Unicode) -- Status: Mandatory -- Multiplicity: Single -- Description: The fully qualified -- name of the PServer object in the tree. -- -- In the 3.x environment, the client -- checks the bindery object -- representing the named PServer on the -- named Server. In the 4.x and -- IntranetWare environment, -- the client checks the NDS object -- representing the named PServer in the -- named Tree. In either case, the -- client then checks for all queues -- associated with the Pserver object. -- Depending on client access rights -- to those queues, the client submits -- jobs to the appropriate queue. chPort9100(11), -- DEPRECATED -- (see chPortTCP - 37; chBidirPortTCP - 38) chAppSocket(12), -- A bi-directional, LPD-like, protocol using -- 9101 for control and 9100 for data. -- Adobe Systems, Inc. chFTP(13), -- [RFC959] chTFTP(14), -- [RFC1350] chDLCLLCPort(15), chIBM3270(16), -- IBM Coax chIBM5250(17), -- IBM Twinax chFax(18), chIEEE1394(19), chTransport1(20), -- TCP port 35, for reserved TCP port list see -- [RFC3232]. This RFC should also be -- referenced for other channel -- enumerations utilizing TCP port -- numbers 0 through 1024. chCPAP(21), -- TCP port 170 -- Digital Equipment Corp. chDCERemoteProcCall(22), -- OSF -- DEPRECATED chONCRemoteProcCall(23), -- SUN Microsystems -- DEPRECATED chOLE(24), -- Microsoft -- DEPRECATED chNamedPipe(25), chPCPrint(26), -- Banyan chServerMessageBlock(27), -- File/Print sharing protocol used by -- various network operating systems -- from IBM 3Com, Microsoft and others -- -- prtChannelInformation entry: -- -- Service Name -- Keyword: Name -- Syntax: Name -- Status: Optional -- Multiplicity: Single -- Description: The service name of -- the printer chDPMF(28), -- IBM Infoprint chDLLAPI(29), -- Microsoft -- DEPRECATED chVxDAPI(30), -- Microsoft -- DEPRECATED chSystemObjectManager(31), -- IBM chDECLAT(32), -- Digital Equipment Corp. -- -- prtChannelInformation entries: -- -- Port Name -- Keyword: Port -- Syntax: Name -- Status: Conditionally -- Mandatory -- (see note below) -- Multiplicity: Single -- Description: LAT port name -- -- Service Name -- Keyword: Service -- Syntax: Name -- Status: Conditionally -- Mandatory -- Multiplicity: Single -- Description: LAT service name -- -- The LAT channel may be -- identified by either a port or -- service, so either a -- Port or Service entry must be -- specified, but not both. chNPAP(33), chUSB(34), -- Not in RFC 1759 -- Universal Serial Bus chIRDA(35), -- Not in RFC 1759 -- Infrared Data Assoc. Prot. chPrintXChange(36), -- Not in RFC 1759 -- PrintXChange Protocol chPortTCP(37), -- Not in RFC 1759 -- A unidirectional "raw" TCP -- channel that uses an administratively -- assigned TCP port address. -- -- prtChannelInformation entry: -- -- Port Number -- Keyword: Port -- Syntax: decimal number -- Status: Mandatory -- Multiplicity: Single -- Description: TCP port number chBidirPortTCP(38), -- Not in RFC 1759 -- A bi-directional version of chPortTCP -- -- prtChannelInformation entries: -- (See chPortTCP) chUNPP(39), -- Not in RFC 1759 -- Universal Network Printing -- Protocol(UNPP). A bi-directional, -- multiport network printing -- application protocol available on -- multiple transport protocols. -- Underscore, Inc. -- Contact: info&underscore.com chAppleTalkADSP(40), -- Not in RFC 1759 -- AppleTalk Data Stream Protocol. -- ADSP is part of the AppleTalk -- suite of protocols. -- It is a symmetric, connection- -- oriented protocol that makes -- possible the establishment -- and maintenance of full-duplex -- streams of data bytes between -- two sockets in an AppleTalk -- internet. -- See [APPLEMAC]. chPortSPX(41), -- Not in RFC 1759 -- Sequenced Packet Exchange (SPX) -- socket. -- Novell, Inc. Similar to TCP, a -- bi-directional data pipe using -- Novell SPX as a transport. -- -- prtChannelInformation entries: -- -- Network Number -- Keyword: Net -- Syntax: HexString -- Status: Mandatory -- Multiplicity: Single -- Description: The network number -- -- Node Number -- Keyword: Node -- Syntax: HexString -- Status: Mandatory -- Multiplicity: Single -- Description: The node number -- -- Socket Number -- Keyword: Socket -- Syntax: HexString -- Status: Mandatory -- Multiplicity: Single -- Description: The SPX socket number -- -- There must be exactly one "Net" and -- one "Node" and one "Socket" entry. A -- HexString is a binary value -- represented as a string of -- ASCII characters using hexadecimal -- notation. chPortHTTP(42), -- Not in RFC 1759 -- Hypertext Transfer Protocol. See [RFC1945] -- and [RFC2616]. chNDPS(43), -- Not in RFC 1759 -- Novell, Inc. -- -- prtChannelInformation entry: -- -- Printer Agent Name -- Keyword: PA -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The NDPS Printer -- Agent Name chIPP(44), -- Not in RFC 1759 -- Internet Printing Protocol (IPP), -- (IPP/1.1 - see [RFC2910] and [RFC2911]) -- also applies to all future versions of IPP. -- -- IPP Printer URI -- Keyword: URI -- Syntax: URI (Unicode UTF-8 per -- [RFC2396]) -- Status: Mandatory -- Multiplicity: Single -- Default: not applicable -- Description: URI of this IPP Printer -- within Internet naming scope. Unicode -- UTF-8 [RFC3629] string with -- hexadecimal escapes for any non-ASCII -- characters (per [RFC2396]). -- Conformance: An IPP Printer shall list all -- IPP URI it supports (one per IPP Channel -- entry). If a URI contains the 'http:' -- scheme it must have an explicit port. -- See: [RFC3629], [RFC2396], [RFC2910], -- [RFC2911]. -- -- IPP Printer Client Authentication -- Keyword: Auth -- Syntax: Keyword -- Status: Optional -- Multiplicity: Single -- Default: 'none' -- Description: A client authentication -- mechanism supported for this IPP Printer -- URI: -- 'none' -- no client authentication mechanism -- 'requesting-user-name' -- authenticated user in 'requesting- -- user-name' -- 'basic' -- authenticated user via HTTP Basic -- mechanism -- 'digest' -- authenticated user via HTTP Digest -- mechanism -- 'certificate' -- authenticated user via certificate -- mechanism -- Conformance: An IPP Printer should list -- all IPP client authentication mechanisms -- it supports (one per IPP Channel entry). -- See: [RFC2911] and [RFC2910]. -- -- IPP Printer Security -- Keyword: Security -- Syntax: Keyword -- Status: Optional -- Multiplicity: Single -- Default: 'none' -- Description: A security mechanism -- supported for this IPP Printer URI: -- 'none' -- no security mechanism -- 'ssl3' -- SSL3 secure communications channel -- protocol -- 'tls' -- TLS secure communications channel -- protocol -- Conformance: An IPP Printer should list -- all IPP security mechanisms it supports -- (one per IPP Channel entry). -- See: [RFC2246], [RFC2911]. -- -- IPP Printer Protocol Version -- Keyword: Version -- Syntax: Keyword -- Status: Optional -- Multiplicity: Multiple -- Default: '1.1' -- Description: All of the IPP protocol -- versions (major.minor) supported for -- this IPP Printer URI: -- '1.0' -- IPP/1.0 conforming Printer -- '1.1' -- IPP/1.1 conforming Printer -- Conformance: An IPP Printer should list -- all IPP versions it supports (all listed -- in each IPP Channel entry). An IPP -- Client should select the highest -- numbered version the IPP Client supports -- for use in all IPP Requests (for optimum -- interworking). -- See: [RFC2911]. chSMTP(45), -- Print Job submission via Simple Mail -- Transfer Protocol (SMTP) - see [RFC2821] -- -- prtChannelInformation entry: -- -- Keyword: Mailto -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Default: not applicable -- Description: The SMTP URL of the printer. chWSPrint(46) -- Not in RFC 3805 -- Web Services on Devices Printer (WS-Print), -- (WS-Print 1.0 - see [WS-Print]) -- -- WS-Print Service URL -- Keyword: ServiceURL -- Syntax: URI (Unicode UTF-8 per -- [RFC3986]) -- Status: Mandatory -- Multiplicity: Multiple -- Default: not applicable -- Description: URL of this WS-Print Printer -- within Internet naming scope. Unicode -- UTF-8 [RFC3629] string with -- hexadecimal escapes for any non-ASCII -- characters (per [RFC3986]). -- Conformance: A WS-Print Printer shall list -- all URLs it -- -- WS-Print Web Services Target Namespace -- Keyword: Namespace -- Syntax: 'URI (Unicode UTF-8 per RFC 3986) -- Status: Optional -- Multiplicity: Multiple -- Default: http://schemas.microsoft.com/windows/2006/08/wdp/print -- Description: XML Namespace for the Service -- and associated print service model. Unicode -- UTF-8 [RFC3629] string with -- hexadecimal escapes for any non-ASCII -- characters (per [RFC3986]). -- Conformance: A WS-Print Printer shall list -- all interoperable WS-Print namespaces it -- supports. } -- -- Interpreter Group TEXTUAL-CONVENTIONs -- PrtInterpreterLangFamilyTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtInterpreterLangFamily in RFC 1759. STATUS current DESCRIPTION "This enumeration indicates the type of interpreter that is receiving jobs." SYNTAX INTEGER { other(1), unknown(2), -- Not in RFC 1759 langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. langPPDS(8), -- IBM Personal Printer Data Stream. -- Originally called IBM ASCII, the name -- was changed to PPDS when the Laser -- Printer was introduced in 1989. -- Lexmark International, Inc. langEscapeP(9), -- Epson Corp. langEpson(10), langDDIF(11), -- Digital Document Interchange Format -- Digital Equipment Corp., Maynard MA langInterpress(12), -- Xerox Corp. langISO6429(13), -- ISO 6429. Control functions for -- Coded Character Sets (has ASCII -- control characters, plus additional -- controls for -- character imaging devices.) langLineData(14), -- line-data: Lines of data as -- separate ASCII or EBCDIC records -- and containing no control functions -- (no CR, LF, HT, FF, etc.) -- For use with traditional line -- printers. May use CR and/or LF to -- delimit lines, instead of records. -- See ISO 10175 Document Printing -- Application (DPA) [ISO10175]. langMODCA(15), -- Mixed Object Document Content -- Architecture -- Definitions that allow the -- composition, interchange, and -- presentation of final form -- documents as a collection of data -- objects (text, image, graphics, bar -- codes), resources (fonts, overlays) -- and page, form and finishing -- instructions. -- IBM Corporation. langREGIS(16), -- Remote Graphics Instruction Set, -- Digital Equipment Corp., Maynard MA langSCS(17), -- SNA Character String -- Bi-directional print data stream for -- SNA LU-1 mode of communication. -- IBM langSPDL(18), -- ISO 10180 Standard Page Description -- Language -- ISO Standard langTEK4014(19), -- Tektronix Corp. langPDS(20), langIGP(21), -- Printronix Corp. langCodeV(22), -- Magnum Code-V, Image and printer -- control language used to control -- impact/dot-matrix printers. -- QMS, Inc., Mobile AL langDSCDSE(23), -- DSC-DSE: Data Stream Compatible and -- Emulation Bi-directional print data -- stream for non-SNA (DSC) and SNA LU-3 -- 3270 controller (DSE) communications -- IBM langWPS(24), -- Windows Printing System, Resource -- based command/data stream used by -- Microsoft At Work Peripherals. -- Developed by the Microsoft -- Corporation. langLN03(25), -- Early DEC-PPL3, Digital Equipment -- Corp. langCCITT(26), langQUIC(27), -- QUIC (Quality Information Code), Page -- Description Language for laser -- printers. Included graphics, printer -- control capability and emulation of -- other well-known printer. -- QMS, Inc. langCPAP(28), -- Common Printer Access Protocol -- Digital Equipment Corp. langDecPPL(29), -- Digital ANSI-Compliant Printing -- Protocol -- (DEC-PPL) -- Digital Equipment Corp. langSimpleText(30), -- simple-text: character coded data, -- including NUL, CR , LF, HT, and FF -- control characters. See ISO 10175 -- Document Printing Application (DPA) -- [ISO10175]. langNPAP(31), -- Network Printer Alliance Protocol -- (NPAP). This protocol has been -- superseded by the IEEE 1284.1 TIPSI -- Std (ref. LangTIPSI(49)). langDOC(32), -- Document Option Commands, Appears in -- the data stream between data -- intended for a page description. -- QMS, Inc. langimPress(33), -- imPRESS, Page description language -- originally developed for the -- ImageServer product line. A binary -- language providing representations -- of text, simple graphics, and some -- large forms (simple -- bit-map and CCITT group 3/4 -- encoded).The -- language was intended to be sent over -- an 8-bit channel and supported early -- document preparation languages (e.g., -- TeX and TROFF). -- QMS, Inc. langPinwriter(34), -- 24 wire dot matrix printer for -- USA, Europe, and Asia except -- Japan. -- More widely used in Germany, and -- some Asian countries than in US. -- NEC langNPDL(35), -- Page printer for Japanese market. -- NEC langNEC201PL(36), -- Serial printer language used in -- the Japanese market. -- NEC langAutomatic(37), -- Automatic PDL sensing. Automatic -- sensing of the interpreter -- language family by the printer -- examining the document content. -- Which actual interpreter language -- families are sensed depends on -- the printer implementation. langPages(38), -- Page printer Advanced Graphic -- Escape Set -- IBM Japan langLIPS(39), -- LBP Image Processing System langTIFF(40), -- Tagged Image File Format (Aldus) langDiagnostic(41), -- A hex dump of the input to the -- interpreter langPSPrinter(42), -- The PostScript Language used for -- control (with any PDLs) -- Adobe Systems Incorporated langCaPSL(43), -- Canon Print Systems Language langEXCL(44), -- Extended Command Language -- Talaris Systems Inc. langLCDS(45), -- Line Conditioned Data Stream -- Xerox Corporation langXES(46), -- Xerox Escape Sequences -- Xerox Corporation langPCLXL(47), -- Not in RFC 1759 -- Printer Control Language. Extended -- language features for printing, and -- printer control. -- Tammy Ferguson (HP) -- and Binnur Al-Kazily (HP) -- Technical reference manual: None -- Hewlett-Packard Co. langART(48), -- Not in RFC 1759 -- Advanced Rendering Tools (ART). -- Page Description language -- originally developed for the Laser -- Press printers. -- Norio Iwamoto (Fuji Xerox) -- and Tom Hastings (Xerox) -- Technical reference manual: "ART IV -- Reference Manual", No F33M. -- Fuji Xerox Co., Ltd. langTIPSI(49), -- Not in RFC 1759 -- Transport Independent Printer -- System Interface -- Don Wright (Lexmark) -- Technical reference manual: "IEEE -- 1284.1" langPrescribe(50), -- Not in RFC 1759 -- Page description and printer -- control language. It can be -- described with ordinary ASCII -- Technical reference manual: -- "PRESCRIBE II Programming Manual" langLinePrinter(51), -- Not in RFC 1759 -- A simple-text character stream which -- supports the control codes LF, VT, -- FF, and plus Centronics or -- Dataproducts Vertical Format Unit -- (VFU) language is commonly used on -- many older model line and matrix -- printers. langIDP(52), -- Not in RFC 1759 -- Imaging Device Protocol -- Apple Computer. langXJCL(53), -- Not in RFC 1759 -- Xerox Job Control Language (JCL). -- A Job Control language originally -- developed for the LaserPress printers -- and is capable of switching PDLs. -- Technical reference manual: -- "ART IV Reference Manual", No F33M. -- Fuji Xerox Co., Ltd. langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65), -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langXPS(66), -- Not in RFC 3805 -- Microsoft XML Paper Specification -- http://www.microsoft.com/whdc/xps/xpsspec langOpenXPS(67), -- Not in RFC 3805 -- ECMA OpenXPS -- http://www.ecma-international.org/ -- publications/standards/Ecma-388.htm langJDF(68), -- Not in RFC 3805 -- CIP4 Job Definition Format -- http://www.cip4.org/documents/ -- jdf_specifications/JDF1.4a.pdf langJMF(69), -- Not in RFC 3805 -- CIP4 Job Messaging Format -- also defined in CIP4 JDF specification -- http://www.cip4.org/documents/ -- jdf_specifications/JDF1.4a.pdf langPPML(70), -- Not in RFC 3805 -- PODI Personalized Print Markup Language -- http://ppml.podi.org/ppml-docs/ -- ppml-specifications.php langXHTMLPrint(71), -- Not in RFC 3805 -- W3C XHTML-Print -- http://www.w3.org/TR/xhtml-print/ langPDFis(72), -- Not in RFC 3805 -- PWG PDF Image-Streamable (PWG 5102.3) -- ftp://pwg.org/pub/pwg/candidates/ -- cs-ifxpdfis10-20040315-5102.3.pdf -- See also 'langPDF' langPDF13(73), -- Not in RFC 3805 -- Adobe Portable Document Format v1.3 -- http://www.adobe.com/devnet/ -- pdf/pdfs/PDFReference13.pdf -- See also 'langPDF' langPDF14(74), -- Not in RFC 3805 -- Adobe Portable Document Format v1.4 -- http://www.adobe.com/devnet/ -- pdf/pdfs/PDFReference.pdf -- See also 'langPDF' langPDF15(75), -- Not in RFC 3805 -- Adobe Portable Document Format v1.5 -- http://www.adobe.com/devnet/ -- pdf/pdfs/PDFReference15_v5.pdf -- See also 'langPDF' langPDF16(76), -- Not in RFC 3805 -- Adobe Portable Document Format v1.6 -- http://www.adobe.com/devnet/ -- pdf/pdfs/PDFReference16.pdf -- See also 'langPDF' langPDF17(77), -- Not in RFC 3805 -- Adobe Portable Document Format v1.7 -- http://www.adobe.com/devnet/ -- acrobat/pdfs/pdf_reference_1-7.pdf -- Equivalent to ISO 32000-1:2008 -- See also 'langPDF' langPS2(78), -- Not in RFC 3805 -- Adobe PostScript Second Edition -- http://partners.adobe.com/public/ -- developer/en/ps/psrefman.pdf -- See also 'langPS' langPS3(79), -- Not in RFC 3805 -- Adobe PostScript Third Edition -- http://www.adobe.com/products/ -- postscript/pdfs/PLRM.pdf -- See also 'langPS' langPCL3(80), -- Not in RFC 3805 -- HP Printer Command Language 3 -- No technical reference manual online -- See also 'langPCL' langPCL3GUI(81), -- Not in RFC 3805 -- HP Printer Command Language 3 GUI -- No technical reference manual online -- See also 'langPCL' langPCL5e(82), -- Not in RFC 3805 -- HP Printer Command Language 5 Enhanced -- http://h20000.www2.hp.com/bc/docs/ -- support/SupportManual/bpl13210/ -- bpl13210.pdf -- See also 'langPCL' langPCL5c(83) -- Not in RFC 3805 -- HP Printer Command Language 5 Color -- http://h20000.www2.hp.com/bc/docs/ -- support/SupportManual/bpl13212/ -- bpl13212.pdf -- See also 'langPCL' } -- -- Input/Output Group TEXTUAL-CONVENTIONs -- PrtInputTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtInputType in RFC 1759. STATUS current DESCRIPTION "The type of technology (discriminated primarily according to feeder mechanism type) employed by a specific component or components." SYNTAX INTEGER { other(1), unknown(2), sheetFeedAutoRemovableTray(3), sheetFeedAutoNonRemovableTray(4), sheetFeedManual(5), continuousRoll(6), continuousFanFold(7) } PrtOutputTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtOutputType in RFC 1759. STATUS current DESCRIPTION "The Type of technology supported by this output subunit." SYNTAX INTEGER { other(1), unknown(2), removableBin(3), unRemovableBin(4), continuousRollDevice(5), mailBox(6), continuousFanFold(7) } -- -- Marker Group TEXTUAL-CONVENTIONs -- PrtMarkerMarkTechTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerMarkTech in RFC 1759. STATUS current DESCRIPTION "The type of marking technology used for this marking subunit." SYNTAX INTEGER { other(1), unknown(2), electrophotographicLED(3), electrophotographicLaser(4), electrophotographicOther(5), impactMovingHeadDotMatrix9pin(6), impactMovingHeadDotMatrix24pin(7), impactMovingHeadDotMatrixOther(8), impactMovingHeadFullyFormed(9), impactBand(10), impactOther(11), inkjetAqueous(12), inkjetSolid(13), inkjetOther(14), pen(15), thermalTransfer(16), thermalSensitive(17), thermalDiffusion(18), thermalOther(19), electroerosion(20), electrostatic(21), photographicMicrofiche(22), photographicImagesetter(23), photographicOther(24), ionDeposition(25), eBeam(26), typesetter(27) } PrtMarkerSuppliesTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerSuppliesType in RFC 1759. STATUS current DESCRIPTION "The type of this supply." SYNTAX INTEGER { other(1), unknown(2), -- Values for Printer MIB toner(3), wasteToner(4), ink(5), inkCartridge(6), inkRibbon(7), wasteInk(8), opc(9), -- photo conductor developer(10), fuserOil(11), solidWax(12), ribbonWax(13), wasteWax(14), fuser(15), -- Not in RFC 1759 coronaWire(16), -- Not in RFC 1759 fuserOilWick(17), -- Not in RFC 1759 cleanerUnit(18), -- Not in RFC 1759 fuserCleaningPad(19), -- Not in RFC 1759 transferUnit(20), -- Not in RFC 1759 tonerCartridge(21), -- Not in RFC 1759 fuserOiler(22), -- Not in RFC 1759 -- End of values for Printer MIB -- Values for Finisher MIB water(23), -- Not in RFC 1759 wasteWater(24), -- Not in RFC 1759 glueWaterAdditive(25),-- Not in RFC 1759 wastePaper(26), -- Not in RFC 1759 bindingSupply(27), -- Not in RFC 1759 bandingSupply(28), -- Not in RFC 1759 stitchingWire(29), -- Not in RFC 1759 shrinkWrap(30), -- Not in RFC 1759 paperWrap(31), -- Not in RFC 1759 staples(32), -- Not in RFC 1759 inserts(33), -- Not in RFC 1759 covers(34) -- Not in RFC 1759 -- End of values for Finisher MIB } -- -- Media Path TEXTUAL-CONVENTIONs -- PrtMediaPathTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMediaPathType in RFC 1759. STATUS current DESCRIPTION "The type of the media path for this media path." SYNTAX INTEGER { other(1), unknown(2), longEdgeBindingDuplex(3), shortEdgeBindingDuplex(4), simplex(5) } -- -- Console Group TEXTUAL-CONVENTIONs -- PrtConsoleColorTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtConsoleColor in RFC 1759. STATUS current DESCRIPTION "The color of this light." SYNTAX INTEGER { other(1), unknown(2), white(3), red(4), green(5), blue(6), cyan(7), magenta(8), yellow(9), orange(10) -- Not in RFC 1759 } PrtConsoleDisableTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtConsoleDisable in RFC 1759. STATUS current DESCRIPTION "This value indicates whether or not input is accepted from the operator console. A value of 'enabled' indicates that input is accepted from the console, and a value of 'disabled' indicates that input is not accepted from the console. " SYNTAX INTEGER { enabled(3), disabled(4) } -- -- Alert Group TEXTUAL-CONVENTIONs -- PrtAlertTrainingLevelTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtAlertTrainingLevel in RFC 1759. STATUS current DESCRIPTION "The level of training required to handle this alert, if human intervention is required. The noInterventionRequired value should be used if the event does not require any human intervention. The training level is an enumeration that is determined and assigned by the printer manufacturer based on the information or training required to handle this alert. The printer will break alerts into these different training levels. It is the responsibility of a management application in the system to determine how a particular alert is handled and how and to whom that alert is routed. The following are the four training levels of alerts: Field Service - Alerts that typically require advanced training and technical knowledge of the printer and its subunits. An example of a technical person would be a manufacturer's Field Service representative, or other person formally trained by the manufacturer or similar representative. Trained - Alerts that require an intermediate or moderate knowledge of the printer and its subunits. A typical example of such an alert is replacing a toner cartridge. Untrained - Alerts that can be fixed without prior training either because the action to correct the alert is obvious or the printer can help the untrained person fix the problem. A typical example of such an alert is reloading paper trays or emptying output bins on a low end printer. Management - Alerts that have to do with overall operation of and configuration of the printer. Examples of such management events are configuration change of subunits." SYNTAX INTEGER { other(1), unknown(2), untrained(3), trained(4), fieldService(5), management(6), noInterventionRequired(7) -- Not in RFC 1759 } PrtAlertGroupTC ::= TEXTUAL-CONVENTION -- Values in the range 1 to 29 must not be IANA-assigned without -- re-publishing Printer MIB. -- Values of 30 and greater are for use in MIBs that augment -- the Printer MIB, such as the Finisher MIB. -- This TC extracted from prtAlertGroup in RFC 1759. STATUS current DESCRIPTION "The type of subunit within the printer model that this alert is related. Input, output, and markers are examples of printer model groups, i.e., examples of types of subunits. Wherever possible, the enumerations match the sub-identifier that identifies the relevant table in the Printer MIB. NOTE: Alert type codes have been added for the Host Resources MIB storage table and device table. These additional types are for situations in which the printer's storage and device objects must generate alerts (and possibly traps for critical alerts)." SYNTAX INTEGER { other(1), unknown(2), -- Values for Host Resources MIB hostResourcesMIBStorageTable(3), hostResourcesMIBDeviceTable(4), -- Values for Printer MIB generalPrinter(5), cover(6), localization(7), input(8), output(9), marker(10), markerSupplies(11), markerColorant(12), mediaPath(13), channel(14), interpreter(15), consoleDisplayBuffer(16), consoleLights(17), alert(18), -- Not in RFC 1759 -- Values (5) to (29) reserved for Printer MIB -- Values for Finisher MIB finDevice(30), -- Not in RFC 1759 finSupply(31), -- Not in RFC 1759 finSupplyMediaInput(32), -- Not in RFC 1759 finAttribute(33) -- Not in RFC 1759 -- Values (30) to (39) reserved for Finisher MIB } PrtAlertCodeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtAlertCode in RFC 1759. STATUS current DESCRIPTION "The code that describes the type of alert for this entry in the table. Binary change event alerts describe states of the subunit while unary change event alerts describe a single event. The same alert code can be used for a binary change event or a unary change event, depending on implementation. Also, the same alert code can be used to indicate a critical or non-critical (warning) alert, depending on implementation. The value of prtAlertSeverityLevel specifies binary vs. unary and critical vs. non-critical for each event for the implementation. While there are some specific codes for many subunits, the generic codes should be used for most subunit alerts. The network management station can then query the subunit specified by prtAlertGroup to determine further subunit status and other subunit information. An agent shall not add two entries to the alert table for the same event, one containing a generic event code and the other containing a specific event code; the agent shall add only one entry in the alert table for each event; either generic (preferred) or specific, not both. Implementation of the unary change event alertRemovalOfBinaryChangeEntry(1801) is optional. When implemented, this alert code shall indicate to network management stations that the trailing edge of a binary change event has occurred and the corresponding alert entry has been removed from the alert table. As with all events, the alertRemovalOfBinaryChangeEntry(1801) alert shall be placed at the end of the alert table. Such an alert table entry shall specify the following information: prtAlertSeverityLevel warningUnaryChangeEvent(4) prtAlertTrainingLevel noInterventionRequired(7) prtAlertGroup alert(18) prtAlertGroupIndex the index of the row in the alert table of the binary change event that this event has removed. prtAlertLocation unknown (-2) prtAlertCode alertRemovalOfBinaryChangeEntry(1801) prtAlertDescription prtAlertTime the value of sysUpTime at the time of the removal of the binary change event from the alert table. Optionally, the agent may generate a trap coincident with removing the binary change event and placing the unary change event alertRemovalOfBinaryChangeEntry(1801) in the alert table. For such a trap, the prtAlertIndex sent with the above trap parameters shall be the index of the alertRemovalOfBinaryChangeEvent row that was added to the prtAlertTable; not the index of the row that was removed from the prtAlertTable." SYNTAX INTEGER { other(1), -- an event that is not represented -- by one of the alert codes -- specified below. unknown(2), -- The following generic codes are common to -- multiple groups. The NMS may examine the -- prtAlertGroup object to determine what group -- to query for further information. coverOpen(3), coverClosed(4), interlockOpen(5), interlockClosed(6), configurationChange(7), jam(8), subunitMissing(9), -- Not in RFC 1759 -- The subunit tray, bin, etc. -- has been removed. subunitLifeAlmostOver(10), -- Not in RFC 1759 subunitLifeOver(11), -- Not in RFC 1759 subunitAlmostEmpty(12), -- Not in RFC 1759 subunitEmpty(13), -- Not in RFC 1759 subunitAlmostFull(14), -- Not in RFC 1759 subunitFull(15), -- Not in RFC 1759 subunitNearLimit(16), -- Not in RFC 1759 subunitAtLimit(17), -- Not in RFC 1759 subunitOpened(18), -- Not in RFC 1759 subunitClosed(19), -- Not in RFC 1759 subunitTurnedOn(20), -- Not in RFC 1759 subunitTurnedOff(21), -- Not in RFC 1759 subunitOffline(22), -- Not in RFC 1759 subunitPowerSaver(23), -- Not in RFC 1759 subunitWarmingUp(24), -- Not in RFC 1759 subunitAdded(25), -- Not in RFC 1759 subunitRemoved(26), -- Not in RFC 1759 subunitResourceAdded(27), -- Not in RFC 1759 subunitResourceRemoved(28), -- Not in RFC 1759 subunitRecoverableFailure(29), -- Not in RFC 1759 subunitUnrecoverableFailure(30), -- Not in RFC 1759 subunitRecoverableStorageError(31), -- Not in RFC 1759 subunitUnrecoverableStorageError(32), -- Not in RFC 1759 subunitMotorFailure(33), -- Not in RFC 1759 subunitMemoryExhausted(34), -- Not in RFC 1759 subunitUnderTemperature(35), -- Not in RFC 1759 subunitOverTemperature(36), -- Not in RFC 1759 subunitTimingFailure(37), -- Not in RFC 1759 subunitThermistorFailure(38), -- Not in RFC 1759 -- General Printer group doorOpen(501), -- DEPRECATED -- Use coverOpened(3) doorClosed(502), -- DEPRECATED -- Use coverClosed(4) powerUp(503), powerDown(504), printerNMSReset(505), -- Not in RFC 1759 -- The printer has been reset by some -- network management station(NMS) -- writing into 'prtGeneralReset'. printerManualReset(506), -- Not in RFC 1759 -- The printer has been reset manually. printerReadyToPrint(507), -- Not in RFC 1759 -- The printer is ready to print. (i.e., -- not warming up, not in power save -- state, not adjusting print quality, -- etc.). -- Input Group inputMediaTrayMissing(801), inputMediaSizeChange(802), inputMediaWeightChange(803), inputMediaTypeChange(804), inputMediaColorChange(805), inputMediaFormPartsChange(806), inputMediaSupplyLow(807), inputMediaSupplyEmpty(808), inputMediaChangeRequest(809), -- Not in RFC 1759 -- An interpreter has detected that a -- different medium is need in this input -- tray subunit. The prtAlertDescription may -- be used to convey a human readable -- description of the medium required to -- satisfy the request. inputManualInputRequest(810), -- Not in RFC 1759 -- An interpreter has detected that manual -- input is required in this subunit. The -- prtAlertDescription may be used to convey -- a human readable description of the medium -- required to satisfy the request. inputTrayPositionFailure(811), -- Not in RFC 1759 -- The input tray failed to position correctly. inputTrayElevationFailure(812), -- Not in RFC 1759 inputCannotFeedSizeSelected(813), -- Not in RFC 1759 -- Output Group outputMediaTrayMissing(901), outputMediaTrayAlmostFull(902), outputMediaTrayFull(903), outputMailboxSelectFailure(904), -- Not in RFC 1759 -- Marker group markerFuserUnderTemperature(1001), markerFuserOverTemperature(1002), markerFuserTimingFailure(1003), -- Not in RFC 1759 markerFuserThermistorFailure(1004), -- Not in RFC 1759 markerAdjustingPrintQuality(1005), -- Not in RFC 1759 -- Marker Supplies group markerTonerEmpty(1101), markerInkEmpty(1102), markerPrintRibbonEmpty(1103), markerTonerAlmostEmpty(1104), markerInkAlmostEmpty(1105), markerPrintRibbonAlmostEmpty(1106), markerWasteTonerReceptacleAlmostFull(1107), markerWasteInkReceptacleAlmostFull(1108), markerWasteTonerReceptacleFull(1109), markerWasteInkReceptacleFull(1110), markerOpcLifeAlmostOver(1111), markerOpcLifeOver(1112), markerDeveloperAlmostEmpty(1113), markerDeveloperEmpty(1114), markerTonerCartridgeMissing(1115), -- Not in RFC 1759 -- Media Path Device Group mediaPathMediaTrayMissing(1301), mediaPathMediaTrayAlmostFull(1302), mediaPathMediaTrayFull(1303), mediaPathCannotDuplexMediaSelected(1304), -- Not in RFC 1759 -- Interpreter Group interpreterMemoryIncrease(1501), interpreterMemoryDecrease(1502), interpreterCartridgeAdded(1503), interpreterCartridgeDeleted(1504), interpreterResourceAdded(1505), interpreterResourceDeleted(1506), interpreterResourceUnavailable(1507), interpreterComplexPageEncountered(1509), -- Not in RFC 1759 -- The interpreter has encountered a page -- that is too complex for the resources that -- are available. -- Alert Group alertRemovalOfBinaryChangeEntry(1801), -- Not in RFC 1759 -- A binary change event entry has been -- removed from the alert table. This unary -- change alert table entry is added to the -- end of the alert table. -- FinDeviceTypeTC = stitcher(3) -> stapler -- FinStitchingTypeTC = staple... (4,5,6,7, or 10) staplerCoverOpen(30203), staplerCoverClosed(30204), staplerInterlockOpen(30205), staplerInterlockClosed(30206), staplerConfigurationChange(30207), staplerJam(30208), staplerMissing(30209), staplerLifeAlmostOver(30210), staplerLifeOver(30211), staplerAlmostEmpty(30212), staplerEmpty(30213), staplerAlmostFull(30214), staplerFull(30215), staplerNearLimit(30216), staplerAtLimit(30217), staplerOpened(30218), staplerClosed(30219), staplerTurnedOn(30220), staplerTurnedOff(30221), staplerOffline(30222), staplerPowerSaver(30223), staplerWarmingUp(30224), staplerAdded(30225), staplerRemoved(30226), staplerResourceAdded(30227), staplerResourceRemoved(30228), staplerRecoverableFailure(30229), staplerUnrecoverableFailure(30230), staplerRecoverableStorageError(30231), staplerUnrecoverableStorageError(30232), staplerMotorFailure(30233), staplerMemoryExhausted(30234), staplerUnderTemperature(30235), staplerOverTemperature(30236), staplerTimingFailure(30237), staplerThermistorFailure(30238), -- FinDeviceTypeTC = stitcher(3) -> stitcher -- FinStitchingTypeTC = saddleStitch(8) or edgeStitch(9) stitcherCoverOpen(30303), stitcherCoverClosed(30304), stitcherInterlockOpen(30305), stitcherInterlockClosed(30306), stitcherConfigurationChange(30307), stitcherJam(30308), stitcherMissing(30309), stitcherLifeAlmostOver(30310), stitcherLifeOver(30311), stitcherAlmostEmpty(30312), stitcherEmpty(30313), stitcherAlmostFull(30314), stitcherFull(30315), stitcherNearLimit(30316), stitcherAtLimit(30317), stitcherOpened(30318), stitcherClosed(30319), stitcherTurnedOn(30320), stitcherTurnedOff(30321), stitcherOffline(30322), stitcherPowerSaver(30323), stitcherWarmingUp(30324), stitcherAdded(30325), stitcherRemoved(30326), stitcherResourceAdded(30327), stitcherResourceRemoved(30328), stitcherRecoverableFailure(30329), stitcherUnrecoverableFailure(30330), stitcherRecoverableStorageError(30331), stitcherUnrecoverableStorageError(30332), stitcherMotorFailure(30333), stitcherMemoryExhausted(30334), stitcherUnderTemperature(30335), stitcherOverTemperature(30336), stitcherTimingFailure(30337), stitcherThermistorFailure(30338), -- FinDeviceTypeTC = folder(4) folderCoverOpen(30403), folderCoverClosed(30404), folderInterlockOpen(30405), folderInterlockClosed(30406), folderConfigurationChange(30407), folderJam(30408), folderMissing(30409), folderLifeAlmostOver(30410), folderLifeOver(30411), folderAlmostEmpty(30412), folderEmpty(30413), folderAlmostFull(30414), folderFull(30415), folderNearLimit(30416), folderAtLimit(30417), folderOpened(30418), folderClosed(30419), folderTurnedOn(30420), folderTurnedOff(30421), folderOffline(30422), folderPowerSaver(30423), folderWarmingUp(30424), folderAdded(30425), folderRemoved(30426), folderResourceAdded(30427), folderResourceRemoved(30428), folderRecoverableFailure(30429), folderUnrecoverableFailure(30430), folderRecoverableStorageError(30431), folderUnrecoverableStorageError(30432), folderMotorFailure(30433), folderMemoryExhausted(30434), folderUnderTemperature(30435), folderOverTemperature(30436), folderTimingFailure(30437), folderThermistorFailure(30438), -- FinDeviceTypeTC = binder(5) binderCoverOpen(30503), binderCoverClosed(30504), binderInterlockOpen(30505), binderInterlockClosed(30506), binderConfigurationChange(30507), binderJam(30508), binderMissing(30509), binderLifeAlmostOver(30510), binderLifeOver(30511), binderAlmostEmpty(30512), binderEmpty(30513), binderAlmostFull(30514), binderFull(30515), binderNearLimit(30516), binderAtLimit(30517), binderOpened(30518), binderClosed(30519), binderTurnedOn(30520), binderTurnedOff(30521), binderOffline(30522), binderPowerSaver(30523), binderWarmingUp(30524), binderAdded(30525), binderRemoved(30526), binderResourceAdded(30527), binderResourceRemoved(30528), binderRecoverableFailure(30529), binderUnrecoverableFailure(30530), binderRecoverableStorageError(30531), binderUnrecoverableStorageError(30532), binderMotorFailure(30533), binderMemoryExhausted(30534), binderUnderTemperature(30535), binderOverTemperature(30536), binderTimingFailure(30537), binderThermistorFailure(30538), -- FinDeviceTypeTC = trimmer(6) trimmerCoverOpen(30603), trimmerCoverClosed(30604), trimmerInterlockOpen(30605), trimmerInterlockClosed(30606), trimmerConfigurationChange(30607), trimmerJam(30608), trimmerMissing(30609), trimmerLifeAlmostOver(30610), trimmerLifeOver(30611), trimmerAlmostEmpty(30612), trimmerEmpty(30613), trimmerAlmostFull(30614), trimmerFull(30615), trimmerNearLimit(30616), trimmerAtLimit(30617), trimmerOpened(30618), trimmerClosed(30619), trimmerTurnedOn(30620), trimmerTurnedOff(30621), trimmerOffline(30622), trimmerPowerSaver(30623), trimmerWarmingUp(30624), trimmerAdded(30625), trimmerRemoved(30626), trimmerResourceAdded(30627), trimmerResourceRemoved(30628), trimmerRecoverableFailure(30629), trimmerUnrecoverableFailure(30630), trimmerRecoverableStorageError(30631), trimmerUnrecoverableStorageError(30632), trimmerMotorFailure(30633), trimmerMemoryExhausted(30634), trimmerUnderTemperature(30635), trimmerOverTemperature(30636), trimmerTimingFailure(30637), trimmerThermistorFailure(30638), -- FinDeviceTypeTC = dieCutter(7) dieCutterCoverOpen(30703), dieCutterCoverClosed(30704), dieCutterInterlockOpen(30705), dieCutterInterlockClosed(30706), dieCutterConfigurationChange(30707), dieCutterJam(30708), dieCutterMissing(30709), dieCutterLifeAlmostOver(30710), dieCutterLifeOver(30711), dieCutterAlmostEmpty(30712), dieCutterEmpty(30713), dieCutterAlmostFull(30714), dieCutterFull(30715), dieCutterNearLimit(30716), dieCutterAtLimit(30717), dieCutterOpened(30718), dieCutterClosed(30719), dieCutterTurnedOn(30720), dieCutterTurnedOff(30721), dieCutterOffline(30722), dieCutterPowerSaver(30723), dieCutterWarmingUp(30724), dieCutterAdded(30725), dieCutterRemoved(30726), dieCutterResourceAdded(30727), dieCutterResourceRemoved(30728), dieCutterRecoverableFailure(30729), dieCutterUnrecoverableFailure(30730), dieCutterRecoverableStorageError(30731), dieCutterUnrecoverableStorageError(30732), dieCutterMotorFailure(30733), dieCutterMemoryExhausted(30734), dieCutterUnderTemperature(30735), dieCutterOverTemperature(30736), dieCutterTimingFailure(30737), dieCutterThermistorFailure(30738), -- FinDeviceTypeTC = puncher(8) puncherCoverOpen(30803), puncherCoverClosed(30804), puncherInterlockOpen(30805), puncherInterlockClosed(30806), puncherConfigurationChange(30807), puncherJam(30808), puncherMissing(30809), puncherLifeAlmostOver(30810), puncherLifeOver(30811), puncherAlmostEmpty(30812), puncherEmpty(30813), puncherAlmostFull(30814), puncherFull(30815), puncherNearLimit(30816), puncherAtLimit(30817), puncherOpened(30818), puncherClosed(30819), puncherTurnedOn(30820), puncherTurnedOff(30821), puncherOffline(30822), puncherPowerSaver(30823), puncherWarmingUp(30824), puncherAdded(30825), puncherRemoved(30826), puncherResourceAdded(30827), puncherResourceRemoved(30828), puncherRecoverableFailure(30829), puncherUnrecoverableFailure(30830), puncherRecoverableStorageError(30831), puncherUnrecoverableStorageError(30832), puncherMotorFailure(30833), puncherMemoryExhausted(30834), puncherUnderTemperature(30835), puncherOverTemperature(30836), puncherTimingFailure(30837), puncherThermistorFailure(30838), -- FinDeviceTypeTC = perforater(9) perforaterCoverOpen(30903), perforaterCoverClosed(30904), perforaterInterlockOpen(30905), perforaterInterlockClosed(30906), perforaterConfigurationChange(30907), perforaterJam(30908), perforaterMissing(30909), perforaterLifeAlmostOver(30910), perforaterLifeOver(30911), perforaterAlmostEmpty(30912), perforaterEmpty(30913), perforaterAlmostFull(30914), perforaterFull(30915), perforaterNearLimit(30916), perforaterAtLimit(30917), perforaterOpened(30918), perforaterClosed(30919), perforaterTurnedOn(30920), perforaterTurnedOff(30921), perforaterOffline(30922), perforaterPowerSaver(30923), perforaterWarmingUp(30924), perforaterAdded(30925), perforaterRemoved(30926), perforaterResourceAdded(30927), perforaterResourceRemoved(30928), perforaterRecoverableFailure(30929), perforaterUnrecoverableFailure(30930), perforaterRecoverableStorageError(30931), perforaterUnrecoverableStorageError(30932), perforaterMotorFailure(30933), perforaterMemoryExhausted(30934), perforaterUnderTemperature(30935), perforaterOverTemperature(30936), perforaterTimingFailure(30937), perforaterThermistorFailure(30938), -- FinDeviceTypeTC = slitter(10) slitterCoverOpen(31003), slitterCoverClosed(31004), slitterInterlockOpen(31005), slitterInterlockClosed(31006), slitterConfigurationChange(31007), slitterJam(31008), slitterMissing(31009), slitterLifeAlmostOver(31010), slitterLifeOver(31011), slitterAlmostEmpty(31012), slitterEmpty(31013), slitterAlmostFull(31014), slitterFull(31015), slitterNearLimit(31016), slitterAtLimit(31017), slitterOpened(31018), slitterClosed(31019), slitterTurnedOn(31020), slitterTurnedOff(31021), slitterOffline(31022), slitterPowerSaver(31023), slitterWarmingUp(31024), slitterAdded(31025), slitterRemoved(31026), slitterResourceAdded(31027), slitterResourceRemoved(31028), slitterRecoverableFailure(31029), slitterUnrecoverableFailure(31030), slitterRecoverableStorageError(31031), slitterUnrecoverableStorageError(31032), slitterMotorFailure(31033), slitterMemoryExhausted(31034), slitterUnderTemperature(31035), slitterOverTemperature(31036), slitterTimingFailure(31037), slitterThermistorFailure(31038), -- FinDeviceTypeTC = separationCutter(11) separationCutterCoverOpen(31103), separationCutterCoverClosed(31104), separationCutterInterlockOpen(31105), separationCutterInterlockClosed(31106), separationCutterConfigurationChange(31107), separationCutterJam(31108), separationCutterMissing(31109), separationCutterLifeAlmostOver(31110), separationCutterLifeOver(31111), separationCutterAlmostEmpty(31112), separationCutterEmpty(31113), separationCutterAlmostFull(31114), separationCutterFull(31115), separationCutterNearLimit(31116), separationCutterAtLimit(31117), separationCutterOpened(31118), separationCutterClosed(31119), separationCutterTurnedOn(31120), separationCutterTurnedOff(31121), separationCutterOffline(31122), separationCutterPowerSaver(31123), separationCutterWarmingUp(31124), separationCutterAdded(31125), separationCutterRemoved(31126), separationCutterResourceAdded(31127), separationCutterResourceRemoved(31128), separationCutterRecoverableFailure(31129), separationCutterUnrecoverableFailure(31130), separationCutterRecoverableStorageError(31131), separationCutterUnrecoverableStorageError(31132), separationCutterMotorFailure(31133), separationCutterMemoryExhausted(31134), separationCutterUnderTemperature(31135), separationCutterOverTemperature(31136), separationCutterTimingFailure(31137), separationCutterThermistorFailure(31138), -- FinDeviceTypeTC = imprinter(12) imprinterCoverOpen(31203), imprinterCoverClosed(31204), imprinterInterlockOpen(31205), imprinterInterlockClosed(31206), imprinterConfigurationChange(31207), imprinterJam(31208), imprinterMissing(31209), imprinterLifeAlmostOver(31210), imprinterLifeOver(31211), imprinterAlmostEmpty(31212), imprinterEmpty(31213), imprinterAlmostFull(31214), imprinterFull(31215), imprinterNearLimit(31216), imprinterAtLimit(31217), imprinterOpened(31218), imprinterClosed(31219), imprinterTurnedOn(31220), imprinterTurnedOff(31221), imprinterOffline(31222), imprinterPowerSaver(31223), imprinterWarmingUp(31224), imprinterAdded(31225), imprinterRemoved(31226), imprinterResourceAdded(31227), imprinterResourceRemoved(31228), imprinterRecoverableFailure(31229), imprinterUnrecoverableFailure(31230), imprinterRecoverableStorageError(31231), imprinterUnrecoverableStorageError(31232), imprinterMotorFailure(31233), imprinterMemoryExhausted(31234), imprinterUnderTemperature(31235), imprinterOverTemperature(31236), imprinterTimingFailure(31237), imprinterThermistorFailure(31238), -- FinDeviceTypeTC = wrapper(13) wrapperCoverOpen(31303), wrapperCoverClosed(31304), wrapperInterlockOpen(31305), wrapperInterlockClosed(31306), wrapperConfigurationChange(31307), wrapperJam(31308), wrapperMissing(31309), wrapperLifeAlmostOver(31310), wrapperLifeOver(31311), wrapperAlmostEmpty(31312), wrapperEmpty(31313), wrapperAlmostFull(31314), wrapperFull(31315), wrapperNearLimit(31316), wrapperAtLimit(31317), wrapperOpened(31318), wrapperClosed(31319), wrapperTurnedOn(31320), wrapperTurnedOff(31321), wrapperOffline(31322), wrapperPowerSaver(31323), wrapperWarmingUp(31324), wrapperAdded(31325), wrapperRemoved(31326), wrapperResourceAdded(31327), wrapperResourceRemoved(31328), wrapperRecoverableFailure(31329), wrapperUnrecoverableFailure(31330), wrapperRecoverableStorageError(31331), wrapperUnrecoverableStorageError(31332), wrapperMotorFailure(31333), wrapperMemoryExhausted(31334), wrapperUnderTemperature(31335), wrapperOverTemperature(31336), wrapperTimingFailure(31337), wrapperThermistorFailure(31338), -- FinDeviceTypeTC = bander(14) banderCoverOpen(31403), banderCoverClosed(31404), banderInterlockOpen(31405), banderInterlockClosed(31406), banderConfigurationChange(31407), banderJam(31408), banderMissing(31409), banderLifeAlmostOver(31410), banderLifeOver(31411), banderAlmostEmpty(31412), banderEmpty(31413), banderAlmostFull(31414), banderFull(31415), banderNearLimit(31416), banderAtLimit(31417), banderOpened(31418), banderClosed(31419), banderTurnedOn(31420), banderTurnedOff(31421), banderOffline(31422), banderPowerSaver(31423), banderWarmingUp(31424), banderAdded(31425), banderRemoved(31426), banderResourceAdded(31427), banderResourceRemoved(31428), banderRecoverableFailure(31429), banderUnrecoverableFailure(31430), banderRecoverableStorageError(31431), banderUnrecoverableStorageError(31432), banderMotorFailure(31433), banderMemoryExhausted(31434), banderUnderTemperature(31435), banderOverTemperature(31436), banderTimingFailure(31437), banderThermistorFailure(31438), -- FinDeviceTypeTC = makeEnvelope(15) makeEnvelopeCoverOpen(31503), makeEnvelopeCoverClosed(31504), makeEnvelopeInterlockOpen(31505), makeEnvelopeInterlockClosed(31506), makeEnvelopeConfigurationChange(31507), makeEnvelopeJam(31508), makeEnvelopeMissing(31509), makeEnvelopeLifeAlmostOver(31510), makeEnvelopeLifeOver(31511), makeEnvelopeAlmostEmpty(31512), makeEnvelopeEmpty(31513), makeEnvelopeAlmostFull(31514), makeEnvelopeFull(31515), makeEnvelopeNearLimit(31516), makeEnvelopeAtLimit(31517), makeEnvelopeOpened(31518), makeEnvelopeClosed(31519), makeEnvelopeTurnedOn(31520), makeEnvelopeTurnedOff(31521), makeEnvelopeOffline(31522), makeEnvelopePowerSaver(31523), makeEnvelopeWarmingUp(31524), makeEnvelopeAdded(31525), makeEnvelopeRemoved(31526), makeEnvelopeResourceAdded(31527), makeEnvelopeResourceRemoved(31528), makeEnvelopeRecoverableFailure(31529), makeEnvelopeUnrecoverableFailure(31530), makeEnvelopeRecoverableStorageError(31531), makeEnvelopeUnrecoverableStorageError(31532), makeEnvelopeMotorFailure(31533), makeEnvelopeMemoryExhausted(31534), makeEnvelopeUnderTemperature(31535), makeEnvelopeOverTemperature(31536), makeEnvelopeTimingFailure(31537), makeEnvelopeThermistorFailure(31538), -- FinDeviceTypeTC = stacker(16) stackerCoverOpen(31603), stackerCoverClosed(31604), stackerInterlockOpen(31605), stackerInterlockClosed(31606), stackerConfigurationChange(31607), stackerJam(31608), stackerMissing(31609), stackerLifeAlmostOver(31610), stackerLifeOver(31611), stackerAlmostEmpty(31612), stackerEmpty(31613), stackerAlmostFull(31614), stackerFull(31615), stackerNearLimit(31616), stackerAtLimit(31617), stackerOpened(31618), stackerClosed(31619), stackerTurnedOn(31620), stackerTurnedOff(31621), stackerOffline(31622), stackerPowerSaver(31623), stackerWarmingUp(31624), stackerAdded(31625), stackerRemoved(31626), stackerResourceAdded(31627), stackerResourceRemoved(31628), stackerRecoverableFailure(31629), stackerUnrecoverableFailure(31630), stackerRecoverableStorageError(31631), stackerUnrecoverableStorageError(31632), stackerMotorFailure(31633), stackerMemoryExhausted(31634), stackerUnderTemperature(31635), stackerOverTemperature(31636), stackerTimingFailure(31637), stackerThermistorFailure(31638), -- FinDeviceTypeTC = sheetRotator(17) sheetRotatorCoverOpen(31703), sheetRotatorCoverClosed(31704), sheetRotatorInterlockOpen(31705), sheetRotatorInterlockClosed(31706), sheetRotatorConfigurationChange(31707), sheetRotatorJam(31708), sheetRotatorMissing(31709), sheetRotatorLifeAlmostOver(31710), sheetRotatorLifeOver(31711), sheetRotatorAlmostEmpty(31712), sheetRotatorEmpty(31713), sheetRotatorAlmostFull(31714), sheetRotatorFull(31715), sheetRotatorNearLimit(31716), sheetRotatorAtLimit(31717), sheetRotatorOpened(31718), sheetRotatorClosed(31719), sheetRotatorTurnedOn(31720), sheetRotatorTurnedOff(31721), sheetRotatorOffline(31722), sheetRotatorPowerSaver(31723), sheetRotatorWarmingUp(31724), sheetRotatorAdded(31725), sheetRotatorRemoved(31726), sheetRotatorResourceAdded(31727), sheetRotatorResourceRemoved(31728), sheetRotatorRecoverableFailure(31729), sheetRotatorUnrecoverableFailure(31730), sheetRotatorRecoverableStorageError(31731), sheetRotatorUnrecoverableStorageError(31732), sheetRotatorMotorFailure(31733), sheetRotatorMemoryExhausted(31734), sheetRotatorUnderTemperature(31735), sheetRotatorOverTemperature(31736), sheetRotatorTimingFailure(31737), sheetRotatorThermistorFailure(31738), -- FinDeviceTypeTC = inserter(18) inserterCoverOpen(31803), inserterCoverClosed(31804), inserterInterlockOpen(31805), inserterInterlockClosed(31806), inserterConfigurationChange(31807), inserterJam(31808), inserterMissing(31809), inserterLifeAlmostOver(31810), inserterLifeOver(31811), inserterAlmostEmpty(31812), inserterEmpty(31813), inserterAlmostFull(31814), inserterFull(31815), inserterNearLimit(31816), inserterAtLimit(31817), inserterOpened(31818), inserterClosed(31819), inserterTurnedOn(31820), inserterTurnedOff(31821), inserterOffline(31822), inserterPowerSaver(31823), inserterWarmingUp(31824), inserterAdded(31825), inserterRemoved(31826), inserterResourceAdded(31827), inserterResourceRemoved(31828), inserterRecoverableFailure(31829), inserterUnrecoverableFailure(31830), inserterRecoverableStorageError(31831), inserterUnrecoverableStorageError(31832), inserterMotorFailure(31833), inserterMemoryExhausted(31834), inserterUnderTemperature(31835), inserterOverTemperature(31836), inserterTimingFailure(31837), inserterThermistorFailure(31838) } END snmp-mibs-downloader-1.1/mibiana/ianafinisher-mib0000644000000000000000000002174711402176070017043 0ustar IANA-FINISHER-MIB DEFINITIONS ::= BEGIN -- http://www.iana.org/assignments/ianafinisher-mib IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ianafinisherMIB MODULE-IDENTITY LAST-UPDATED "200911030000Z" -- November 3, 2009 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" DESCRIPTION "This MIB module defines a set of finishing-related TEXTUAL-CONVENTIONs for use in Finisher MIB (RFC 3806) and other MIBs which need to specify finishing mechanism details. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Applications Area. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3806. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" REVISION "200911030000Z" -- November 3, 2009 DESCRIPTION "Added plasticMultiRing(12)." REVISION "200406020000Z" -- June 2, 2004 DESCRIPTION "Original version, published in coordination with Finisher MIB (RFC 3806)." ::= { mib-2 110 } -- TEXTUAL-CONVENTIONs for this MIB module FinDeviceTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined finishing device subunit process enumerations." SYNTAX INTEGER { other(1), unknown(2), stitcher(3), folder(4), binder(5), trimmer(6), dieCutter(7), puncher(8), perforater(9), slitter(10), separationCutter(11), imprinter(12), wrapper(13), bander(14), makeEnvelope(15), stacker(16), sheetRotator(17), inserter(18) } FinAttributeTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TEXTUAL-CONVENTION defines the set of enums for use in the finDeviceAttributeTable. See section 5.7 for the complete specification of each attribute." SYNTAX INTEGER { other(1), deviceName(3), deviceVendorName(4), deviceModel(5), deviceVersion(6), deviceSerialNumber(7), maximumSheets(8), finProcessOffsetUnits(9), finReferenceEdge(10), finAxisOffset(11), finJogEdge(12), finHeadLocation(13), finOperationRestrictions(14), finNumberOfPositions(15), namedConfiguration(16), finMediaTypeRestriction(17), finPrinterInputTraySupported(18), finPreviousFinishingOperation(19), finNextFinishingOperation(20), stitchingType(30), stitchingDirection(31), foldingType(40), bindingType(50), punchHoleType(80), punchHoleSizeLongDim(81), punchHoleSizeShortDim(82), punchPattern(83), slittingType(100), wrappingType(130), stackOutputType(160), stackOffset(161), stackRotation(162) } FinEdgeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies an edge for a Finishing Process." SYNTAX INTEGER { topEdge(3), bottomEdge(4), leftEdge(5), rightEdge(6) } FinStitchingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined stitching type enumerations. For the edgeStitch and stapleDual enums, the finReferenceEdge attribute is recommended to define the edge to which the operation applies." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), stapleTopLeft(4), stapleBottomLeft(5), stapleTopRight(6), stapleBottomRight(7), saddleStitch(8), edgeStitch(9), stapleDual(10) } FinStitchingDirTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Defines the direction, relative to the top sheet in the output subunit, that the stitching operation was performed. For a topDown(3) process, the staple will be clinched on the bottom of the stack. This parameter can be used to determine what order the pages of a booklet are to be printed such that the staple clinch will be on the inside of the resulting booklet." SYNTAX INTEGER { unknown(2), topDown(3), bottomUp(4) } FinStitchingAngleTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This enumeration provides a description of the angular orientation of each stitch in a single or multiple stitching operation, relative to the 'X' axis. As with all finishing operations, the 'X' axis is always relative to the portrait orientation of the document regardless of the orientation of the printed image. This enum is primarily applicable to corner stitching operations." SYNTAX INTEGER { unknown(2), horizontal(3), vertical(4), slanted(5) } FinFoldingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined folding device process enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), zFold(3), halfFold(4), letterFold(5) } FinBindingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined binding type enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), tape(4), plastic(5), velo(6), perfect(7), spiral(8), adhesive(9), comb(10), padding(11), plasticMultiRing(12) } FinPunchHoleTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined hole type punch process enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), round(3), oblong(4), square(5), rectangular(6), star(7) } FinPunchPatternTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined hole pattern punch process enumerations." SYNTAX INTEGER { other(1), --Pattern to be defined in other attributes unknown(2), twoHoleUSTop(4), --Letter/legal, 8.5 inch edge threeHoleUS(5), --Letter/ledger, 11 inch edge twoHoleDIN(6), --A4/A3, 297 mm edge fourHoleDIN(7), --A4/A3, 297 mm edge twentyTwoHoleUS(8), --Letter/ledger, 11 inch edge nineteenHoleUS(9), --Letter/ledger, 11 inch edge twoHoleMetric(10), --B5/B4, 257 mm edge swedish4Hole(11), --A4/A3, 297 mm edge twoHoleUSSide(12), --Letter/ledger, 11 inch edge fiveHoleUS(13), --Letter/ledger, 11 inch edge sevenHoleUS(14), --Letter/ledger, 11 inch edge mixed7H4S(15), --A4/A3, 297 mm edge norweg6Hole(16), --A4/A3, 297 mm edge metric26Hole(17), --B5/B4, 257 mm edge metric30Hole(18) --A4/A3, 297 mm edge } FinSlittingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined slitting type enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), slitAndSeparate(4), slitAndMerge(5) } FinWrappingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined wrapping device process enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), shrinkWrap(4), paperWrap(5) } FinStackOutputTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined stack output type enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), straight(4), -- No offset, one on top of another offset(5), crissCross(6) -- Rotated } END snmp-mibs-downloader-1.1/mibiana/ianaitualarmtc-mib0000644000000000000000000003356711402176070017404 0ustar IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaItuAlarmNumbers MODULE-IDENTITY LAST-UPDATED "200409090000Z" -- September 09, 2004 ORGANIZATION "IANA" CONTACT-INFO "Postal: Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6601 USA Tel: +1 310-823-9358 E-Mail: iana&iana.org" DESCRIPTION "The MIB module defines the ITU Alarm textual convention for objects expected to require regular extension. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3877. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html" REVISION "200409090000Z" DESCRIPTION "Initial version, published as RFC 3877." ::= { mib-2 119 } IANAItuProbableCause ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in this TC. IANAItuProbableCause value of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the OPS Area Director will appoint one or more experts to help review requests. See http://www.iana.org" REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992 ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" SYNTAX INTEGER { -- The following probable causes were defined in M.3100 aIS (1), callSetUpFailure (2), degradedSignal (3), farEndReceiverFailure (4), framingError (5), lossOfFrame (6), lossOfPointer (7), lossOfSignal (8), payloadTypeMismatch (9), transmissionError (10), remoteAlarmInterface (11), excessiveBER (12), pathTraceMismatch (13), unavailable (14), signalLabelMismatch (15), lossOfMultiFrame (16), receiveFailure (17), transmitFailure (18), modulationFailure (19), demodulationFailure (20), broadcastChannelFailure (21), connectionEstablishmentError (22), invalidMessageReceived (23), localNodeTransmissionError (24), remoteNodeTransmissionError (25), routingFailure (26), --Values 27-50 are reserved for communications alarm related --probable causes -- The following are used with equipment alarm. backplaneFailure (51), dataSetProblem (52), equipmentIdentifierDuplication (53), externalIFDeviceProblem (54), lineCardProblem (55), multiplexerProblem (56), nEIdentifierDuplication (57), powerProblem (58), processorProblem (59), protectionPathFailure (60), receiverFailure (61), replaceableUnitMissing (62), replaceableUnitTypeMismatch (63), synchronizationSourceMismatch (64), terminalProblem (65), timingProblem (66), transmitterFailure (67), trunkCardProblem (68), replaceableUnitProblem (69), realTimeClockFailure (70), --An equipment alarm to be issued if the system detects that the --real time clock has failed antennaFailure (71), batteryChargingFailure (72), diskFailure (73), frequencyHoppingFailure (74), iODeviceError (75), lossOfSynchronisation (76), lossOfRedundancy (77), powerSupplyFailure (78), signalQualityEvaluationFailure (79), tranceiverFailure (80), protectionMechanismFailure (81), protectingResourceFailure (82), -- Values 83-100 are reserved for equipment alarm related probable -- causes -- The following are used with environmental alarm. airCompressorFailure (101), airConditioningFailure (102), airDryerFailure (103), batteryDischarging (104), batteryFailure (105), commercialPowerFailure (106), coolingFanFailure (107), engineFailure (108), fireDetectorFailure (109), fuseFailure (110), generatorFailure (111), lowBatteryThreshold (112), pumpFailure (113), rectifierFailure (114), rectifierHighVoltage (115), rectifierLowFVoltage (116), ventilationsSystemFailure (117), enclosureDoorOpen (118), explosiveGas (119), fire (120), flood (121), highHumidity (122), highTemperature (123), highWind (124), iceBuildUp (125), intrusionDetection (126), lowFuel (127), lowHumidity (128), lowCablePressure (129), lowTemperatue (130), lowWater (131), smoke (132), toxicGas (133), coolingSystemFailure (134), externalEquipmentFailure (135), externalPointFailure (136), -- Values 137-150 are reserved for environmental alarm related -- probable causes -- The following are used with Processing error alarm. storageCapacityProblem (151), memoryMismatch (152), corruptData (153), outOfCPUCycles (154), sfwrEnvironmentProblem (155), sfwrDownloadFailure (156), lossOfRealTimel (157), --A processing error alarm to be issued after the system has --reinitialised. This will indicate --to the management systems that the view they have of the managed --system may no longer --be valid. Usage example: The managed --system issues this alarm after a reinitialization with severity --warning to inform the --management system about the event. No clearing notification will --be sent. applicationSubsystemFailure (158), configurationOrCustomisationError (159), databaseInconsistency (160), fileError (161), outOfMemory (162), softwareError (163), timeoutExpired (164), underlayingResourceUnavailable (165), versionMismatch (166), --Values 168-200 are reserved for processing error alarm related -- probable causes. bandwidthReduced (201), congestion (202), excessiveErrorRate (203), excessiveResponseTime (204), excessiveRetransmissionRate (205), reducedLoggingCapability (206), systemResourcesOverload (207 ), -- The following were defined X.733 adapterError (500), applicationSubsystemFailture (501), bandwidthReducedX733 (502), callEstablishmentError (503), communicationsProtocolError (504), communicationsSubsystemFailure (505), configurationOrCustomizationError (506), congestionX733 (507), coruptData (508), cpuCyclesLimitExceeded (509), dataSetOrModemError (510), degradedSignalX733 (511), dteDceInterfaceError (512), enclosureDoorOpenX733 (513), equipmentMalfunction (514), excessiveVibration (515), fileErrorX733 (516), fireDetected (517), framingErrorX733 (518), heatingVentCoolingSystemProblem (519), humidityUnacceptable (520), inputOutputDeviceError (521), inputDeviceError (522), lanError (523), leakDetected (524), localNodeTransmissionErrorX733 (525), lossOfFrameX733 (526), lossOfSignalX733 (527), materialSupplyExhausted (528), multiplexerProblemX733 (529), outOfMemoryX733 (530), ouputDeviceError (531), performanceDegraded (532), powerProblems (533), pressureUnacceptable (534), processorProblems (535), pumpFailureX733 (536), queueSizeExceeded (537), receiveFailureX733 (538), receiverFailureX733 (539), remoteNodeTransmissionErrorX733 (540), resourceAtOrNearingCapacity (541), responseTimeExecessive (542), retransmissionRateExcessive (543), softwareErrorX733 (544), softwareProgramAbnormallyTerminated (545), softwareProgramError (546), storageCapacityProblemX733 (547), temperatureUnacceptable (548), thresholdCrossed (549), timingProblemX733 (550), toxicLeakDetected (551), transmitFailureX733 (552), transmiterFailure (553), underlyingResourceUnavailable (554), versionMismatchX733 (555), -- The following are defined in X.736 authenticationFailure (600), breachOfConfidentiality (601), cableTamper (602), delayedInformation (603), denialOfService (604), duplicateInformation (605), informationMissing (606), informationModificationDetected (607), informationOutOfSequence (608), keyExpired (609), nonRepudiationFailure (610), outOfHoursActivity (611), outOfService (612), proceduralError (613), unauthorizedAccessAttempt (614), unexpectedInformation (615), other (1024) } IANAItuEventType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ITU event Type values. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in this TC. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. See http://www.iana.org " REFERENCE "ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" SYNTAX INTEGER { other (1), communicationsAlarm (2), qualityOfServiceAlarm (3), processingErrorAlarm (4), equipmentAlarm (5), environmentalAlarm (6), integrityViolation (7), operationalViolation (8), physicalViolation (9), securityServiceOrMechanismViolation (10), timeDomainViolation (11) } END snmp-mibs-downloader-1.1/mibiana/ianagmplstc-mib0000644000000000000000000003262211402176070016677 0ustar IANA-GMPLS-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC; -- RFC 2579 ianaGmpls MODULE-IDENTITY LAST-UPDATED "201004310000Z" -- 13 April 2010 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" DESCRIPTION "Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC 4802. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html" REVISION "201004130000Z" -- 13 April 2010 DESCRIPTION "Added LSP Encoding Type tunnelLine(14), Switching Type evpl(30)." REVISION "201002220000Z" -- 22 February 2010 DESCRIPTION "Added missing Administrative Status Information Flags 25, 26, and 28." REVISION "201002190000Z" -- 19 February 2010 DESCRIPTION "Added dcsc(125)." REVISION "200702270000Z" -- 27 February 2007 00:00:00 GMT DESCRIPTION "Initial version issued as part of RFC 4802." ::= { mib-2 152 } IANAGmplsLSPEncodingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to represent and control the LSP encoding type of an LSP signaled by a GMPLS signaling protocol. This textual convention is strongly tied to the LSP Encoding Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the LSP Encoding Types sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the LSP Encoding Types sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana&iana.org)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.1.1. 2. Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, RFC 4328, section 3.1.1." SYNTAX INTEGER { tunnelLspNotGmpls(0), -- GMPLS is not in use tunnelLspPacket(1), -- Packet tunnelLspEthernet(2), -- Ethernet tunnelLspAnsiEtsiPdh(3), -- PDH -- the value 4 is deprecated tunnelLspSdhSonet(5), -- SDH or SONET -- the value 6 is deprecated tunnelLspDigitalWrapper(7), -- Digital Wrapper tunnelLspLambda(8), -- Lambda tunnelLspFiber(9), -- Fiber -- the value 10 is deprecated tunnelLspFiberChannel(11), -- Fiber Channel tunnelDigitalPath(12), -- Digital Path tunnelOpticalChannel(13), -- Optical Channel tunnelLine(14) -- Line } IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to represent and control the LSP switching type of an LSP signaled by a GMPLS signaling protocol. This textual convention is strongly tied to the Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Switching Types sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the Switching Types sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana&iana.org)." REFERENCE "1. Routing Extensions in Support of Generalized Multi-Protocol Label Switching, RFC 4202, section 2.4. 2. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.1.1." SYNTAX INTEGER { unknown(0), -- none of the following, or not known psc1(1), -- Packet-Switch-Capable 1 psc2(2), -- Packet-Switch-Capable 2 psc3(3), -- Packet-Switch-Capable 3 psc4(4), -- Packet-Switch-Capable 4 evpl(30), -- Ethernet Virtual Private Line l2sc(51), -- Layer-2-Switch-Capable tdm(100), -- Time-Division-Multiplex dcsc(125), -- Data Channel Switching Capable lsc(150), -- Lambda-Switch-Capable fsc(200) -- Fiber-Switch-Capable } IANAGmplsGeneralizedPidTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to represent and control the LSP Generalized Protocol Identifier (G-PID) of an LSP signaled by a GMPLS signaling protocol. This textual convention is strongly tied to the Generalized PIDs (G-PID) sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Generalized PIDs (G-PID) sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the Generalized PIDs (G-PID) sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana&iana.org)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.1.1. 2. Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, RFC 4328, section 3.1.3." SYNTAX INTEGER { unknown(0), -- unknown or none of the following -- the values 1, 2, 3 and 4 are reserved in RFC 3471 asynchE4(5), asynchDS3T3(6), asynchE3(7), bitsynchE3(8), bytesynchE3(9), asynchDS2T2(10), bitsynchDS2T2(11), reservedByRFC3471first(12), asynchE1(13), bytesynchE1(14), bytesynch31ByDS0(15), asynchDS1T1(16), bitsynchDS1T1(17), bytesynchDS1T1(18), vc1vc12(19), reservedByRFC3471second(20), reservedByRFC3471third(21), ds1SFAsynch(22), ds1ESFAsynch(23), ds3M23Asynch(24), ds3CBitParityAsynch(25), vtLovc(26), stsSpeHovc(27), posNoScramble16BitCrc(28), posNoScramble32BitCrc(29), posScramble16BitCrc(30), posScramble32BitCrc(31), atm(32), ethernet(33), sdhSonet(34), digitalwrapper(36), lambda(37), ansiEtsiPdh(38), lapsSdh(40), fddi(41), dqdb(42), fiberChannel3(43), hdlc(44), ethernetV2DixOnly(45), ethernet802dot3Only(46), g709ODUj(47), g709OTUk(48), g709CBRorCBRa(49), g709CBRb(50), g709BSOT(51), g709BSNT(52), gfpIPorPPP(53), gfpEthernetMAC(54), gfpEthernetPHY(55), g709ESCON(56), g709FICON(57), g709FiberChannel(58) } IANAGmplsAdminStatusInformationTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type determines the setting of the Admin Status flags in the Admin Status object or TLV, as described in RFC 3471. Setting this object to a non-zero value will result in the inclusion of the Admin Status object or TLV on signaling messages. This textual convention is strongly tied to the Administrative Status Information Flags sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Administrative Status Flags sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the Administrative Status Information Flags sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana&iana.org)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 8. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 7. 3. GMPLS - Communication of Alarm Information, RFC 4783, section 3.2.1." SYNTAX BITS { reflect(0), -- Reflect bit (RFC 3471) reserved1(1), -- reserved reserved2(2), -- reserved reserved3(3), -- reserved reserved4(4), -- reserved reserved5(5), -- reserved reserved6(6), -- reserved reserved7(7), -- reserved reserved8(8), -- reserved reserved9(9), -- reserved reserved10(10), -- reserved reserved11(11), -- reserved reserved12(12), -- reserved reserved13(13), -- reserved reserved14(14), -- reserved reserved15(15), -- reserved reserved16(16), -- reserved reserved17(17), -- reserved reserved18(18), -- reserved reserved19(19), -- reserved reserved20(20), -- reserved reserved21(21), -- reserved reserved22(22), -- reserved reserved23(23), -- reserved reserved24(24), -- reserved handover(25), -- Handover bit (RFC 5852) lockout(26), -- Lockout bit (RFC 4872) inhibitAlarmCommunication(27), -- Inhibit Alarm bit (RFC 4783) callControl(28), -- Call control bit (RFC 4974) testing(29), -- Testing bit (RFC 3473) administrativelyDown(30), -- Admin down (RFC 3473) deleteInProgress(31) -- Delete bit (RFC 3473) } END snmp-mibs-downloader-1.1/mibiana/ianaippmmetricsregistry-mib0000644000000000000000000004553511402176070021362 0ustar IANA-IPPM-METRICS-REGISTRY-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI; ianaIppmMetricsRegistry MODULE-IDENTITY LAST-UPDATED "200910260000Z" -- September 2, 2009 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana&iana.org" DESCRIPTION "This module defines a registry for IP Performance Metrics. Registrations are done sequentially by IANA in the ianaIppmMetrics subtree on the bases of 'Specification Required' as defined in [RFC2434]. The reference of the specification must point to a stable document including a title, a revision and a date. The name always starts with the name of the organization and must respect the SMIv2 rules for descriptors defined in the section 3.1 of [RFC2578]; A document that creates new metrics would have an IANA considerations section in which it would describe new metrics to register. An OBJECT IDENTITY assigned to a metric is definitive and cannot be reused. If a new version of a metric is produced then it is assigned with a new name and a new identifier. Copyright (C) The Internet Society (2005). The initial version of this MIB module was published in RFC 4148; for full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html. " REVISION "200909020000Z" -- September 2, 2009 DESCRIPTION "Added values 52-70 as published in RFC5644." REVISION "200904200000Z" -- April 20, 2009 DESCRIPTION "Added values 46-51 as published in RFC5560." REVISION "200612040000Z" -- September 27, 2006 DESCRIPTION "Added values 34-45 as published in RFC4737." REVISION "200504120000Z" -- April 12th, 2005 DESCRIPTION "Initial version of the IPPM metrics registry module. This version published as RFC 4148." ::= { mib-2 128 } ianaIppmMetrics OBJECT-IDENTITY STATUS current DESCRIPTION "Registration point for IP Performance Metrics." ::= { ianaIppmMetricsRegistry 1 } -- -- Registry of the metrics of the IPPM WG RFCs -- -- -- RFC 2678 " IPPM Metrics for Measuring Connectivity" -- ietfInstantUnidirConnectivity OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Instantaneous-Unidirectional-Connectivity" REFERENCE "RFC2678, section 2." ::= { ianaIppmMetrics 1} ietfInstantBidirConnectivity OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Instantaneous-Bidirectional-Connectivity" REFERENCE "RFC2678, section 3." ::= { ianaIppmMetrics 2} ietfIntervalUnidirConnectivity OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Interval-Unidirectional-Connectivity" REFERENCE "RFC2678, section 4." ::= { ianaIppmMetrics 3 } ietfIntervalBidirConnectivity OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Interval-Bidirectional-Connectivity" REFERENCE "RFC2678, section 5." ::= { ianaIppmMetrics 4 } ietfIntervalTemporalConnectivity OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P1-P2-Interval-Temporal-Connectivity" REFERENCE "RFC2678, section 6." ::= { ianaIppmMetrics 5 } -- -- RFC 2679 "A One-way Delay Metric for IPPM" -- ietfOneWayDelay OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Delay" REFERENCE "RFC2679, section 3." ::= { ianaIppmMetrics 6 } ietfOneWayDelayPoissonStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Delay-Poisson-Stream" REFERENCE "RFC2679, section 4." ::= { ianaIppmMetrics 7 } ietfOneWayDelayPercentile OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Delay-Percentile" REFERENCE "RFC2679, section 5.1." ::= { ianaIppmMetrics 8 } ietfOneWayDelayMedian OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Delay-Median" REFERENCE "RFC2679, section 5.2." ::= { ianaIppmMetrics 9 } ietfOneWayDelayMinimum OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Delay-Minimum" REFERENCE "RFC2679, section 5.3." ::= { ianaIppmMetrics 10 } ietfOneWayDelayInversePercentile OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Delay-Inverse-Percentile" REFERENCE "RFC2679, section 5.4." ::= { ianaIppmMetrics 11 } -- -- RFC 2680 "One Way Packet Loss Metric for IPPM" -- ietfOneWayPktLoss OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Packet-Loss" REFERENCE "RFC2680, section 2." ::= { ianaIppmMetrics 12 } ietfOneWayPktLossPoissonStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Packet-Loss-Poisson-Stream" REFERENCE "RFC2680, section 3." ::= { ianaIppmMetrics 13 } ietfOneWayPktLossAverage OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Packet-Loss-Average" REFERENCE "RFC2680, section 4." ::= { ianaIppmMetrics 14 } -- -- RFC2681 "A Round-trip Delay Metric for IPPM" -- ietfRoundTripDelay OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Round-trip-Delay" REFERENCE " section 2 of the rfc2681." ::= { ianaIppmMetrics 15 } ietfRoundTripDelayPoissonStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Round-trip-Delay-Poisson-Stream" REFERENCE "RFC2681, section 4." ::= { ianaIppmMetrics 16 } ietfRoundTripDelayPercentile OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Round-trip-Delay-Percentile" REFERENCE "RFC2681, section 4.1." ::= { ianaIppmMetrics 17 } ietfRoundTripDelayMedian OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Round-trip-Delay-Median" REFERENCE "RFC2681, section 4.2." ::= { ianaIppmMetrics 18 } ietfRoundTripDelayMinimum OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Round-trip-Delay-Minimum" REFERENCE "RFC2681, section 4.3." ::= { ianaIppmMetrics 19 } ietfRoundTripDelayInvPercentile OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Round-trip-Inverse-Percentile" REFERENCE "RFC2681, section 4.4." ::= { ianaIppmMetrics 20 } -- -- RFC3357: "One-way Loss Pattern Sample Metrics" -- ietfOneWayLossDistanceStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-Way-Loss-Distance-Stream" REFERENCE " RFC3357, section 5.4.1." ::={ ianaIppmMetrics 21} ietfOneWayLossPeriodStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-Way-Loss-Period-Stream" REFERENCE " RFC3357, section 5.4.2." ::={ ianaIppmMetrics 22} ietfOneWayLossNoticeableRate OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-Way-Loss-Noticeable-Rate" REFERENCE " RFC3357, section 6.1." ::= { ianaIppmMetrics 23 } ietfOneWayLossPeriodTotal OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-Way-Loss-Period-Total" REFERENCE " RFC3357, section 6.2." ::= { ianaIppmMetrics 24 } ietfOneWayLossPeriodLengths OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-Way-Loss-Period-Lengths" REFERENCE " RFC3357, section 6.3." ::= { ianaIppmMetrics 25 } ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-Way-Inter-Loss-Period-Lengths" REFERENCE " RFC3357, section 6.4." ::= { ianaIppmMetrics 26 } -- -- RFC3393: -- IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) ietfOneWayIpdv OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-ipdv" REFERENCE " RFC3393, section 2." ::= { ianaIppmMetrics 27 } ietfOneWayIpdvPoissonStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-ipdv-Poisson-stream" REFERENCE " RFC3393, section 3." ::= { ianaIppmMetrics 28 } ietfOneWayIpdvPercentile OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-ipdv-percentile" REFERENCE " RFC3393, section 4.3." ::= { ianaIppmMetrics 29 } ietfOneWayIpdvInversePercentile OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-ipdv-inverse-percentile" REFERENCE " RFC3393, section 4.4." ::= { ianaIppmMetrics 30 } ietfOneWayIpdvJitter OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-ipdv-jitter" REFERENCE " RFC3393, section 4.5." ::= { ianaIppmMetrics 31 } ietfOneWayPeakToPeakIpdv OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-peak-to-peak-ipdv" REFERENCE " RFC3393, section 4.6." ::= { ianaIppmMetrics 32 } -- -- RFC3432: "Network performance measurement with periodic streams" -- ietfOneWayDelayPeriodicStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-way-Delay-Periodic-Stream" REFERENCE " RFC3432, section 4." ::= { ianaIppmMetrics 33 } -- -- RFC4737 "Packet Reordering Metric for IPPM" -- ietfReorderedSingleton OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Reordered" REFERENCE "Reference RFC4737, section 3" ::= { ianaIppmMetrics 34 } ietfReorderedPacketRatio OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Reordered-Ratio-Stream" REFERENCE "Reference RFC4737, section 4.1" ::= { ianaIppmMetrics 35 } ietfReorderingExtent OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Reordering-Extent-Stream" REFERENCE "Reference RFC4737, section 4.2" ::= { ianaIppmMetrics 36 } ietfReorderingLateTimeOffset OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Late-Time-Stream" REFERENCE "Reference RFC4737, section 4.3" ::= { ianaIppmMetrics 37 } ietfReorderingByteOffset OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Byte-Offset-Stream" REFERENCE "Reference RFC4737, section 4.4" ::= { ianaIppmMetrics 38 } ietfReorderingGap OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Reordering-Gap-Stream" REFERENCE "Reference RFC4737, section 4.5" ::= { ianaIppmMetrics 39 } ietfReorderingGapTime OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Reordering-GapTime-Stream" REFERENCE "Reference RFC4737, section 4.5" ::= { ianaIppmMetrics 40 } ietfReorderingFreeRunx OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Reordering-Free-Run-x-numruns-Stream" REFERENCE "Reference RFC4737, section 4.6" ::= { ianaIppmMetrics 41 } ietfReorderingFreeRunq OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Reordering-Free-Run-q-squruns-Stream" REFERENCE "Reference RFC4737, section 4.6" ::= { ianaIppmMetrics 42 } ietfReorderingFreeRunp OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream" REFERENCE "Reference RFC4737, section 4.6" ::= { ianaIppmMetrics 43 } ietfReorderingFreeRuna OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream" REFERENCE "Reference RFC4737, section 4.6" ::= { ianaIppmMetrics 44 } ietfnReordering OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Packet-n-Reordering-Stream" REFERENCE "Reference RFC4737, section 5" ::= { ianaIppmMetrics 45 } -- -- RFC5560: -- A One-Way Packet Duplication Metric ietfOneWayPacketArrivalCount OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-one-way-packet-arrival-count" REFERENCE "Reference RFC5560, section 2" ::= { ianaIppmMetrics 46 } ietfOneWayPacketDuplication OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-one-way-packet-duplication" REFERENCE "Reference RFC5560, section 3" ::= { ianaIppmMetrics 47 } ietfOneWayPacketDuplicationPoissonStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-one-way-Packet-Duplication-Poisson-Stream" REFERENCE "Reference RFC5560, section 4.1" ::= { ianaIppmMetrics 48 } ietfOneWayPacketDuplicationPeriodicStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-one-way-Duplication-Periodic-Stream" REFERENCE "Reference RFC5560, section 4.2" ::= { ianaIppmMetrics 49 } ietfOneWayPacketDuplicationFraction OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-one-way-packet-duplication-fraction" REFERENCE "Reference RFC5560, section 5.1" ::= { ianaIppmMetrics 50 } ietfOneWayReplicatedPacketRate OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-one-way-replicated-packet-rate" REFERENCE "Reference RFC5560, section 5.2" ::= { ianaIppmMetrics 51 } -- -- RFC5644: -- IP Performance Metrics (IPPM) for spatial and multicast ietfSpatialOneWayDelayVector OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Spatial-One-way-Delay-Vector" REFERENCE "Reference "RFC5644, section 5.1." := { ianaIppmMetrics 52 } ietfSpatialPacketLossVector OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Spatial-Packet-Loss-Vector" REFERENCE "Reference "RFC5644, section 5.2." := { ianaIppmMetrics 53 } ietfSpatialOneWayIpdvVector OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Spatial-One-way-ipdv-Vector" REFERENCE "Reference "RFC5644, section 5.3." := { ianaIppmMetrics 54 } ietfSegmentOneWayDelayStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Segment-One-way-Delay-Stream" REFERENCE "Reference "RFC5644, section 6.1." := { ianaIppmMetrics 55 } ietfSegmentPacketLossStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Segment-Packet-Loss-Stream" REFERENCE "Reference "RFC5644, section 6.2." := { ianaIppmMetrics 56 } ietfSegmentIpdvPrevStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Segment-ipdv-prev-Stream" REFERENCE "Reference "RFC5644, section 6.3." := { ianaIppmMetrics 57 } ietfSegmentIpdvMinStream OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-Segment-ipdv-min-Stream" REFERENCE "Reference "RFC5644, section 6.4." := { ianaIppmMetrics 58 } -- One-to-group metrics ietfOneToGroupDelayVector OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Delay-Vector" REFERENCE "Reference "RFC5644, section 7.1." := { ianaIppmMetrics 59 } ietfOneToGroupPacketLossVector OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Packet-Loss-Vector" REFERENCE "Reference "RFC5644, section 7.2." := { ianaIppmMetrics 60 } ietfOneToGroupIpdvVector OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-ipdv-Vector" REFERENCE "Reference "RFC5644, section 7.3." := { ianaIppmMetrics 61 } -- One to group statistics -- ietfOnetoGroupReceiverNMeanDelay OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Receiver-n-Mean-Delay" REFERENCE "Reference "RFC5644, section 8.3.1." := { ianaIppmMetrics 62 } ietfOneToGroupMeanDelay OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Mean-Delay" REFERENCE "Reference "RFC5644, section 8.3.2." := { ianaIppmMetrics 63 } ietfOneToGroupRangeMeanDelay OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Range-Mean-Delay" REFERENCE "Reference "RFC5644, section 8.3.3." := { ianaIppmMetrics 64 } ietfOneToGroupMaxMeanDelay OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Max-Mean-Delay" REFERENCE "Reference "RFC5644, section 8.3.4." := { ianaIppmMetrics 65 } ietfOneToGroupReceiverNLossRatio OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Receiver-n-Loss-Ratio" REFERENCE "Reference "RFC5644, section 8.4.1." := { ianaIppmMetrics 66 } -- ietfOneToGroupReceiverNCompLossRatio OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Receiver-n-Comp-Loss-Ratio" REFERENCE "Reference "RFC5644, section 8.4.2." := { ianaIppmMetrics 67 } ietfOneToGroupLossRatio OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Loss-Ratio" REFERENCE "Reference "RFC5644, section 8.4.3." := { ianaIppmMetrics 68 } -- ietfOneToGroupRangeLossRatio OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Range-Loss-Ratio" REFERENCE "Reference "RFC5644, section 8.4.4." := { ianaIppmMetrics 69 } ietfOneToGroupRangeDelayVariation OBJECT-IDENTITY STATUS current DESCRIPTION "Type-P-One-to-group-Range-Delay-Variation" REFERENCE "Reference "RFC5644, section 8.5.1." := { ianaIppmMetrics 70 } -- END snmp-mibs-downloader-1.1/mibiana/ianamau-mib0000644000000000000000000010772011402176070016012 0ustar IANA-MAU-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC ; ianaMauMIB MODULE-IDENTITY LAST-UPDATED "201002230000Z" -- February 23, 2010 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1-310-823-9358 EMail: iana&iana.org" DESCRIPTION "This MIB module defines dot3MauType OBJECT-IDENTITIES and IANAifMauListBits, IANAifMauMediaAvailable, IANAifMauAutoNegCapBits, and IANAifJackType TEXTUAL-CONVENTIONs, specifying enumerated values of the ifMauTypeListBits, ifMauMediaAvailable / rpMauMediaAvailable, ifMauAutoNegCapabilityBits / ifMauAutoNegCapAdvertisedBits / ifMauAutoNegCapReceivedBits and ifJackType / rpJackType objects respectively, defined in the MAU-MIB. It is intended that each new MAU type, Media Availability state, Auto Negotiation capability and/or Jack type defined by the IEEE 802.3 working group and approved for publication in a revision of IEEE Std 802.3 will be added to this MIB module, provided that it is suitable for being managed by the base objects in the MAU-MIB. An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for such additions. The following reference is used throughout this MIB module: [IEEE802.3] refers to: IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications'. This reference should be updated as appropriate when new MAU types, Media Availability states, Auto Negotiation capabilities, and/or Jack types are added to this MIB module. Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC 4836; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html" REVISION "201002230000Z" -- February 23, 2010 DESCRIPTION "Added assignments that will be included in Clause 14 of IEEE P802.3.1." REVISION "200704210000Z" -- April 21, 2007 DESCRIPTION "Initial version of this MIB as published in RFC 4836." ::= { mib-2 154 } -- Textual Conventions IANAifMauTypeListBits ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauTypeListBits object in the (updated) definition of MAU-MIB's ifMauTable. The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana&iana.org). Note that changes in this textual convention SHALL be synchronized with relevant changes in the dot3MauType OBJECT-IDENTITIES." REFERENCE "[IEEE802.3], Section 30.5.1.1.2" SYNTAX BITS { bOther(0), -- other or unknown bAUI(1), -- AUI b10base5(2), -- 10BASE-5 bFoirl(3), -- FOIRL b10base2(4), -- 10BASE-2 b10baseT(5), -- 10BASE-T duplex mode unknown b10baseFP(6), -- 10BASE-FP b10baseFB(7), -- 10BASE-FB b10baseFL(8), -- 10BASE-FL duplex mode unknown b10broad36(9), -- 10BROAD36 b10baseTHD(10), -- 10BASE-T half duplex mode b10baseTFD(11), -- 10BASE-T full duplex mode b10baseFLHD(12), -- 10BASE-FL half duplex mode b10baseFLFD(13), -- 10BASE-FL full duplex mode b100baseT4(14), -- 100BASE-T4 b100baseTXHD(15), -- 100BASE-TX half duplex mode b100baseTXFD(16), -- 100BASE-TX full duplex mode b100baseFXHD(17), -- 100BASE-FX half duplex mode b100baseFXFD(18), -- 100BASE-FX full duplex mode b100baseT2HD(19), -- 100BASE-T2 half duplex mode b100baseT2FD(20), -- 100BASE-T2 full duplex mode b1000baseXHD(21), -- 1000BASE-X half duplex mode b1000baseXFD(22), -- 1000BASE-X full duplex mode b1000baseLXHD(23), -- 1000BASE-LX half duplex mode b1000baseLXFD(24), -- 1000BASE-LX full duplex mode b1000baseSXHD(25), -- 1000BASE-SX half duplex mode b1000baseSXFD(26), -- 1000BASE-SX full duplex mode b1000baseCXHD(27), -- 1000BASE-CX half duplex mode b1000baseCXFD(28), -- 1000BASE-CX full duplex mode b1000baseTHD(29), -- 1000BASE-T half duplex mode b1000baseTFD(30), -- 1000BASE-T full duplex mode b10GbaseX(31), -- 10GBASE-X b10GbaseLX4(32), -- 10GBASE-LX4 b10GbaseR(33), -- 10GBASE-R b10GbaseER(34), -- 10GBASE-ER b10GbaseLR(35), -- 10GBASE-LR b10GbaseSR(36), -- 10GBASE-SR b10GbaseW(37), -- 10GBASE-W b10GbaseEW(38), -- 10GBASE-EW b10GbaseLW(39), -- 10GBASE-LW b10GbaseSW(40), -- 10GBASE-SW -- new since RFC 3636 b10GbaseCX4(41), -- 10GBASE-CX4 b2BaseTL(42), -- 2BASE-TL b10PassTS(43), -- 10PASS-TS b100BaseBX10D(44), -- 100BASE-BX10D b100BaseBX10U(45), -- 100BASE-BX10U b100BaseLX10(46), -- 100BASE-LX10 b1000BaseBX10D(47), -- 1000BASE-BX10D b1000BaseBX10U(48), -- 1000BASE-BX10U b1000BaseLX10(49), -- 1000BASE-LX10 b1000BasePX10D(50), -- 1000BASE-PX10D b1000BasePX10U(51), -- 1000BASE-PX10U b1000BasePX20D(52), -- 1000BASE-PX20D b1000BasePX20U(53), -- 1000BASE-PX20U b10GbaseT(54), -- 10GBASE-T b10GbaseLRM(55), -- 10GBASE-LRM b1000baseKX(56), -- 1000BASE-KX b10GbaseKX4(57), -- 10GBASE-KX4 b10GbaseKR(58), -- 10GBASE-KR b10G1GbasePRXD1(59),-- 10/1GBASE-PRX-D1 b10G1GbasePRXD2(60),-- 10/1GBASE-PRX-D2 b10G1GbasePRXD3(61),-- 10/1GBASE-PRX-D3 b10G1GbasePRXU1(62),-- 10/1GBASE-PRX-U1 b10G1GbasePRXU2(63),-- 10/1GBASE-PRX-U2 b10G1GbasePRXU3(64),-- 10/1GBASE-PRX-U3 b10GbasePRD1(65), -- 10GBASE-PR-D1 b10GbasePRD2(66), -- 10GBASE-PR-D2 b10GbasePRD3(67), -- 10GBASE-PR-D3 b10GbasePRU1(68), -- 10GBASE-PR-U1 b10GbasePRU3(69) -- 10GBASE-PR-U3 } IANAifMauMediaAvailable ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauMediaAvailable and rpMauMediaAvailable objects in the (updated) definition of MAU-MIB's ifMauTable and rpMauTable respectively. Possible values are: other(1) - undefined (not listed below) unknown(2) - MAU's true state is unknown; e.g., during initialization available(3) - link, light, or loopback is normal notAvailable(4) - link loss, low light, or no loopback remoteFault(5) - a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation invalidSignal(6) - invalid signal has been received from the other end of the link, 10BASE-FB only remoteJabber(7) - remote fault, due to jabber remoteLinkLoss(8) - remote fault, due to link loss remoteTest(9) - remote fault, due to test offline(10) - offline, Clause 37 Auto-Negotiation only autoNegError(11) - Auto-Negotiation Error, Clause 37 Auto-Negotiation only pmdLinkFault(12) - PMA/PMD receive link fault. In case of PAF (2BASE-TL / 10PASS-TS PHYs), all PMEs in the aggregation group have detected a link fault wisFrameLoss(13) - WIS loss of frame, 10GBASE-W only wisSignalLoss(14) - WIS loss of signal, 10GBASE-W only pcsLinkFault(15) - PCS receive link fault excessiveBER(16) - PCS Bit Error Ratio monitor reporting excessive error ratio dxsLinkFault(17) - DTE XGXS receive link fault, XAUI only pxsLinkFault(18) - PHY XGXS receive link fault, XAUI only availableReduced(19) - link normal, reduced bandwidth, 2BASE-TL / 10PASS-TS only ready(20) - at least one PME in the aggregation group is detecting handshake tones, 2BASE-TL / 10PASS-TS only If the MAU is a 10M b/s link or fiber type (FOIRL, 10BASE-T, 10BASE-F), then this is equivalent to the link test fail state/low light function. For an AUI, 10BASE2, 10BASE5, or 10BROAD36 MAU, this indicates whether loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASEFP. At power-up or following a reset, the Media Available state will be unknown(2) for AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission, then loopback will be detected. The Media Available state will only change during noncollided transmissions for AUI, 10BASE2, 10BASE5, 10BROAD36, and 10BASE-FP MAUs. For 100BASE-T2, 100BASE-T4, 100BASE-TX, 100BASE-FX, 100BASE-LX10, and 100BASE-BX10 PHYs the enumerations match the states within the link integrity state diagram. Any MAU that implements management of [IEEE802.3] Clause 28 Auto-Negotiation, will map remote fault indication to remoteFault(5). Any MAU that implements management of Clause 37 Auto-Negotiation, will map the received RF1 and RF2 bits as follows: Offline maps to offline(10), Link_Failure maps to remoteFault(5), and Auto-Negotiation Error maps to autoNegError(11). The value remoteFault(5) applies to 10BASE-FB remote fault indication, the 100BASE-X far-end fault indication, and nonspecified remote faults from a system running Clause 28 Auto-Negotiation. The value remoteJabber(7), remoteLink loss(8), or remoteTest(9) SHOULD be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. Where a Clause 22 MII or Clause 35 GMII is present, a logic one in the remote fault bit maps to the value remoteFault(5), a logic zero in the link status bit maps to the enumeration notAvailable(4). The value notAvailable(4) takes precedence over remoteFault(5). For 2BASE-TL and 10PASS-TS PHYs, the value unknown(2) maps to the condition where the PHY (PCS with connected PMEs) is initializing, the value ready(20) maps to the condition where the interface is down and at least one PME in the aggregation group is ready for handshake, the value available(3) maps to the condition where all the PMEs in the aggregation group are up, the value notAvailable(4) maps to the condition where all the PMEs in the aggregation group are down and no handshake tones are detected, the value availableReduced(19) maps to the condition where the interface is up, a link fault is detected at the receive direction by one or more PMEs in the aggregation group, but at least one PME is up and the enumeration pmdLinkFault(12) maps to the condition where a link fault is detected at the receive direction by all of the PMEs in the aggregation group. For 10 Gb/s the enumerations map to value of the link_fault variable within the Link Fault Signaling state diagram as follows: the value OK maps to the value available(3), the value Local Fault maps to the value notAvailable(4), and the value Remote Fault maps to the value remoteFault(5). The value pmdLinkFault(12), wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), excessiveBER(16), or dxsLinkFault(17) SHOULD be used instead of the value notAvailable(4), where the reason for the Local Fault state can be identified through the use of the Clause 45 MDIO Interface. Where multiple reasons for the Local Fault state can be identified, only the highest precedence error SHOULD be reported. This precedence in descending order is as follows: pxsLinkFault pmdLinkFault wisFrameLoss wisSignalLoss pcsLinkFault excessiveBER dxsLinkFault. Where a Clause 45 MDIO interface is present a logic zero in the PMA/PMD Receive link status bit ([IEEE802.3] Section 45.2.1.2.2) maps to the value pmdLinkFault(12), logic one in the LOF status bit (Section 45.2.2.10.4) maps to the value wisFrameLoss(13), a logic one in the LOS status bit (Section 45.2.2.10.5) maps to the value wisSignalLoss, a logic zero in the PCS Receive link status bit (Section 45.2.3.2.2) maps to the value pcsLinkFault(15), a logic one in the 10GBASE-R PCS Latched high BER status bit (Section 45.2.3.12.2) maps to the value excessiveBER, a logic zero in the DTE XS receive link status bit (Section 45.2.5.2.2) maps to the value dxsLinkFault(17) and a logic zero in the PHY XS transmit link status bit (Section 45.2.4.2.2) maps to the value pxsLinkFault(18). The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana&iana.org)." REFERENCE "[IEEE802.3], Section 30.5.1.1.4" SYNTAX INTEGER { other(1), unknown(2), available(3), notAvailable(4), remoteFault(5), invalidSignal(6), remoteJabber(7), remoteLinkLoss(8), remoteTest(9), offline(10), autoNegError(11), pmdLinkFault(12), wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), excessiveBER(16), dxsLinkFault(17), pxsLinkFault(18), availableReduced(19), ready(20) } IANAifMauAutoNegCapBits ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits, and ifMauAutoNegCapReceivedBits objects in the (updated) definition of MAU-MIB's ifMauAutoNegTable. The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana&iana.org)." REFERENCE "[IEEE802.3], Section 30.6.1.1.5" SYNTAX BITS { bOther(0), -- other or unknown b10baseT(1), -- 10BASE-T half duplex mode b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 b100baseTX(4), -- 100BASE-TX half duplex mode b100baseTXFD(5), -- 100BASE-TX full duplex mode b100baseT2(6), -- 100BASE-T2 half duplex mode b100baseT2FD(7), -- 100BASE-T2 full duplex mode bFdxPause(8), -- PAUSE for full-duplex links bFdxAPause(9), -- Asymmetric PAUSE for full-duplex -- links bFdxSPause(10), -- Symmetric PAUSE for full-duplex -- links bFdxBPause(11), -- Asymmetric and Symmetric PAUSE for -- full-duplex links b1000baseX(12), -- 1000BASE-X, -LX, -SX, -CX half -- duplex mode b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full -- duplex mode b1000baseT(14), -- 1000BASE-T half duplex mode b1000baseTFD(15), -- 1000BASE-T full duplex mode b10GbaseT(16), -- 10GBASE-T b1000baseKX(17), -- 1000BASE-KX b10GbaseKX4(18), -- 10GBASE-KX4 b10GbaseKR(19) -- 10GBASE-KR } IANAifJackType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Common enumeration values for repeater and interface MAU jack types. This data type is used as the syntax of the ifJackType and rpJackType objects in the (updated) definition of MAU-MIB's ifJackTable and rpJackTable respectively. Possible values are: other(1) - undefined or unknown rj45(2) - RJ45 rj45S(3) - RJ45 shielded db9(4) - DB9 bnc(5) - BNC fAUI(6) - AUI female mAUI(7) - AUI male fiberSC(8) - SC fiber fiberMIC(9) - MIC fiber fiberST(10) - ST fiber telco(11) - Telco mtrj(12) - MT-RJ fiber hssdc(13) - fiber channel style-2 fiberLC(14) - LC fiber cx4(15) - IB4X for 10GBASE-CX4 The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana&iana.org)." SYNTAX INTEGER { other(1), rj45(2), rj45S(3), db9(4), bnc(5), fAUI(6), mAUI(7), fiberSC(8), fiberMIC(9), fiberST(10), telco(11), mtrj(12), hssdc(13), fiberLC(14), -- new since RFC 3636 cx4(15) } -- OBJECT IDENTITIES for MAU types -- (see rpMauType and ifMauType of MAU-MIB for usage) -- The following definitions has been moved from RFC 3636 and -- no longer appear in its revision. dot3MauType OBJECT IDENTIFIER ::= { mib-2 snmpDot3MauMgt(26) 4 } dot3MauTypeAUI OBJECT-IDENTITY STATUS current DESCRIPTION "no internal MAU, view from AUI" REFERENCE "[IEEE802.3], Section 7" ::= { dot3MauType 1 } dot3MauType10Base5 OBJECT-IDENTITY STATUS current DESCRIPTION "thick coax MAU" REFERENCE "[IEEE802.3], Section 7" ::= { dot3MauType 2 } dot3MauTypeFoirl OBJECT-IDENTITY STATUS current DESCRIPTION "FOIRL MAU" REFERENCE "[IEEE802.3], Section 9.9" ::= { dot3MauType 3 } dot3MauType10Base2 OBJECT-IDENTITY STATUS current DESCRIPTION "thin coax MAU" REFERENCE "[IEEE802.3], Section 10" ::= { dot3MauType 4 } dot3MauType10BaseT OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU. Note that it is strongly recommended that agents return either dot3MauType10BaseTHD or dot3MauType10BaseTFD if the duplex mode is known. However, management applications should be prepared to receive this MAU type value from older agent implementations." REFERENCE "[IEEE802.3], Section 14" ::= { dot3MauType 5 } dot3MauType10BaseFP OBJECT-IDENTITY STATUS current DESCRIPTION "passive fiber MAU" REFERENCE "[IEEE802.3], Section 16" ::= { dot3MauType 6 } dot3MauType10BaseFB OBJECT-IDENTITY STATUS current DESCRIPTION "sync fiber MAU" REFERENCE "[IEEE802.3], Section 17" ::= { dot3MauType 7 } dot3MauType10BaseFL OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU. Note that it is strongly recommended that agents return either dot3MauType10BaseFLHD or dot3MauType10BaseFLFD if the duplex mode is known. However, management applications should be prepared to receive this MAU type value from older agent implementations." REFERENCE "[IEEE802.3], Section 18" ::= { dot3MauType 8 } dot3MauType10Broad36 OBJECT-IDENTITY STATUS current DESCRIPTION "broadband DTE MAU. Note that 10BROAD36 MAUs can be attached to interfaces but not to repeaters." REFERENCE "[IEEE802.3], Section 11" ::= { dot3MauType 9 } ------ new since RFC 1515: dot3MauType10BaseTHD OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU, half duplex mode" REFERENCE "[IEEE802.3], Section 14" ::= { dot3MauType 10 } dot3MauType10BaseTFD OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU, full duplex mode" REFERENCE "[IEEE802.3], Section 14" ::= { dot3MauType 11 } dot3MauType10BaseFLHD OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU, half duplex mode" REFERENCE "[IEEE802.3], Section 18" ::= { dot3MauType 12 } dot3MauType10BaseFLFD OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU, full duplex mode" REFERENCE "[IEEE802.3], Section 18" ::= { dot3MauType 13 } dot3MauType100BaseT4 OBJECT-IDENTITY STATUS current DESCRIPTION "4 pair category 3 UTP" REFERENCE "[IEEE802.3], Section 23" ::= { dot3MauType 14 } dot3MauType100BaseTXHD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 5 UTP, half duplex mode" REFERENCE "[IEEE802.3], Section 25" ::= { dot3MauType 15 } dot3MauType100BaseTXFD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 5 UTP, full duplex mode" REFERENCE "[IEEE802.3], Section 25" ::= { dot3MauType 16 } dot3MauType100BaseFXHD OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over PMT, half duplex mode" REFERENCE "[IEEE802.3], Section 26" ::= { dot3MauType 17 } dot3MauType100BaseFXFD OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over PMT, full duplex mode" REFERENCE "[IEEE802.3], Section 26" ::= { dot3MauType 18 } dot3MauType100BaseT2HD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 3 UTP, half duplex mode" REFERENCE "[IEEE802.3], Section 32" ::= { dot3MauType 19 } dot3MauType100BaseT2FD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 3 UTP, full duplex mode" REFERENCE "[IEEE802.3], Section 32" ::= { dot3MauType 20 } ------ new since RFC 2239: dot3MauType1000BaseXHD OBJECT-IDENTITY STATUS current DESCRIPTION "PCS/PMA, unknown PMD, half duplex mode" REFERENCE "[IEEE802.3], Section 36" ::= { dot3MauType 21 } dot3MauType1000BaseXFD OBJECT-IDENTITY STATUS current DESCRIPTION "PCS/PMA, unknown PMD, full duplex mode" REFERENCE "[IEEE802.3], Section 36" ::= { dot3MauType 22 } dot3MauType1000BaseLXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over long-wavelength laser, half duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 23 } dot3MauType1000BaseLXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over long-wavelength laser, full duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 24 } dot3MauType1000BaseSXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over short-wavelength laser, half duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 25 } dot3MauType1000BaseSXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over short-wavelength laser, full duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 26 } dot3MauType1000BaseCXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Copper over 150-Ohm balanced cable, half duplex mode" REFERENCE "[IEEE802.3], Section 39" ::= { dot3MauType 27 } dot3MauType1000BaseCXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Copper over 150-Ohm balanced cable, full duplex mode" REFERENCE "[IEEE802.3], Section 39" ::= { dot3MauType 28 } dot3MauType1000BaseTHD OBJECT-IDENTITY STATUS current DESCRIPTION "Four-pair Category 5 UTP, half duplex mode" REFERENCE "[IEEE802.3], Section 40" ::= { dot3MauType 29 } dot3MauType1000BaseTFD OBJECT-IDENTITY STATUS current DESCRIPTION "Four-pair Category 5 UTP, full duplex mode" REFERENCE "[IEEE802.3], Section 40" ::= { dot3MauType 30 } ------ new since RFC 2668: dot3MauType10GigBaseX OBJECT-IDENTITY STATUS current DESCRIPTION "X PCS/PMA, unknown PMD." REFERENCE "[IEEE802.3], Section 48" ::= { dot3MauType 31 } dot3MauType10GigBaseLX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over WWDM optics" REFERENCE "[IEEE802.3], Section 53" ::= { dot3MauType 32 } dot3MauType10GigBaseR OBJECT-IDENTITY STATUS current DESCRIPTION "R PCS/PMA, unknown PMD." REFERENCE "[IEEE802.3], Section 49" ::= { dot3MauType 33 } dot3MauType10GigBaseER OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 1550 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 34 } dot3MauType10GigBaseLR OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 1310 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 35 } dot3MauType10GigBaseSR OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 850 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 36 } dot3MauType10GigBaseW OBJECT-IDENTITY STATUS current DESCRIPTION "W PCS/PMA, unknown PMD." REFERENCE "[IEEE802.3], Section 49 and 50" ::= { dot3MauType 37 } dot3MauType10GigBaseEW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 1550 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 38 } dot3MauType10GigBaseLW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 1310 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 39 } dot3MauType10GigBaseSW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 850 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 40 } ------ new since RFC 3636: dot3MauType10GigBaseCX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X copper over 8 pair 100-Ohm balanced cable" REFERENCE "[IEEE802.3], Section 54" ::= { dot3MauType 41 } dot3MauType2BaseTL OBJECT-IDENTITY STATUS current DESCRIPTION "Voice grade UTP copper, up to 2700m, optional PAF" REFERENCE "[IEEE802.3], Sections 61 and 63" ::= { dot3MauType 42 } dot3MauType10PassTS OBJECT-IDENTITY STATUS current DESCRIPTION "Voice grade UTP copper, up to 750m, optional PAF" REFERENCE "[IEEE802.3], Sections 61 and 62" ::= { dot3MauType 43 } dot3MauType100BaseBX10D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber OLT, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 58" ::= { dot3MauType 44 } dot3MauType100BaseBX10U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber ONU, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 58" ::= { dot3MauType 45 } dot3MauType100BaseLX10 OBJECT-IDENTITY STATUS current DESCRIPTION "Two single-mode fibers, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 58" ::= { dot3MauType 46 } dot3MauType1000BaseBX10D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber OLT, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 59" ::= { dot3MauType 47 } dot3MauType1000BaseBX10U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber ONU, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 59" ::= { dot3MauType 48 } dot3MauType1000BaseLX10 OBJECT-IDENTITY STATUS current DESCRIPTION "Two sigle-mode fiber, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 59" ::= { dot3MauType 49 } dot3MauType1000BasePX10D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON OLT, 10km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 50 } dot3MauType1000BasePX10U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON ONU, 10km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 51 } dot3MauType1000BasePX20D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON OLT, 20km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 52 } dot3MauType1000BasePX20U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON ONU, 20km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 53 } dot3MauType10GbaseT OBJECT-IDENTITY STATUS current DESCRIPTION "Four-pair Category 6A or better, full duplex mode only" REFERENCE "IEEE Std 802.3, Clause 55" ::= { dot3MauType 54 } dot3MauType10GbaseLRM OBJECT-IDENTITY STATUS current DESCRIPTION "R multimode fiber over 1310 nm optics" REFERENCE "IEEE Std 802.3, Clause 68" ::= { dot3MauType 55 } dot3MauType1000baseKX OBJECT-IDENTITY STATUS current DESCRIPTION "X backplane, full duplex mode only" REFERENCE "IEEE Std 802.3, Clause 70" ::= { dot3MauType 56 } dot3MauType10GbaseKX4 OBJECT-IDENTITY STATUS current DESCRIPTION "4 lane X backplane, full duplex mode only" REFERENCE "IEEE Std 802.3, Clause 71" ::= { dot3MauType 57 } dot3MauType10GbaseKR OBJECT-IDENTITY STATUS current DESCRIPTION "R backplane, full duplex mode only" REFERENCE "IEEE Std 802.3, Clause 72" ::= { dot3MauType 58 } dot3MauType10G1GbasePRXD1 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber asymmetric-rate EPON OLT, supporting low power budget (PRX10)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 59 } dot3MauType10G1GbasePRXD2 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber asymmetric-rate EPON OLT, supporting medium power budget (PRX20)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 60 } dot3MauType10G1GbasePRXD3 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber asymmetric-rate EPON OLT, supporting high power budget (PRX30)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 61 } dot3MauType10G1GbasePRXU1 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber asymmetric-rate EPON ONU, supporting low power budget (PRX10)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 62 } dot3MauType10G1GbasePRXU2 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber asymmetric-rate EPON ONU, supporting medium power budget (PRX20)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 63 } dot3MauType10G1GbasePRXU3 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber asymmetric-rate EPON ONU, supporting high power budget (PRX30)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 64 } dot3MauType10GbasePRD1 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber symmetric-rate EPON OLT, supporting low power budget (PR10)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 65 } dot3MauType10GbasePRD2 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber symmetric-rate EPON OLT, supporting medium power budget (PR20)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 66 } dot3MauType10GbasePRD3 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber symmetric-rate EPON OLT, supporting high power budget (PR30)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 67 } dot3MauType10GbasePRU1 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber symmetric-rate EPON ONU, supporting low and medium power budget (PR10 and PR20)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 68 } dot3MauType10GbasePRU3 OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber symmetric-rate EPON ONU, supporting high power budget (PR30)" REFERENCE "IEEE Std 802.3, Clause 75" ::= { dot3MauType 69 } END snmp-mibs-downloader-1.1/Makefile0000644000000000000000000000122711402176070013742 0ustar # Makefile for mib-downloader # CONFFILES= snmp-mibs-downloader.conf \ iana.conf ianalist \ rfc.conf rfclist rfcmibs.diff \ simpleweb.conf simplelist \ ianarfc.conf ianarfclist BINFILES= download-mibs INSTALL= /usr/bin/install all: install: $(INSTALL) -m 755 $(BINFILES) $(DESTDIR)/usr/bin $(INSTALL) -m 644 $(CONFFILES) $(DESTDIR)/etc/snmp-mibs-downloader cp mibrfcs/* $(DESTDIR)/usr/share/doc/mibrfcs cp mibiana/* $(DESTDIR)/usr/share/doc/mibiana ln -s /var/lib/mibs/ietf $(DESTDIR)/usr/share/mibs/ietf ln -s /var/lib/mibs/iana $(DESTDIR)/usr/share/mibs/iana snmp-mibs-downloader-1.1/download-mibs0000755000000000000000000000410611402176070014766 0ustar #!/bin/bash set -e set -o pipefail SMISTRIP=/usr/bin/smistrip CONFDIR=/etc/snmp-mibs-downloader echo "" echo "Downloading documents and extracting MIB files." echo "This will take some minutes." echo "" echo "In case this process fails, it can always be repeated later by executing" echo "$0 again." echo "" . $CONFDIR/snmp-mibs-downloader.conf download_mibs() { TMP=`mktemp -d` if [ ! -z "$ARCHIVE" ] then ARCHTMP=`mktemp -d` if [ "$ARCHTYPE" == "dirgz" ] then if [ ! -z "$HOST" ] then echo "Downloading a whole directory with compressed content" echo "is not supported." exit 1 else cp $DIR/$ARCHIVE/* $ARCHTMP/ gzip -d $ARCHTMP/* || /bin/true fi else if [ ! -z "$HOST" ] then wget -O $ARCHTMP/$ARCHIVE -q -nv $HOST/$DIR/$ARCHIVE else cp $DIR/$ARCHIVE $ARCHTMP/$ARCHIVE fi if [ "$ARCHTYPE" == "tar" ] then tar -C $ARCHTMP -xf $ARCHTMP/$ARCHIVE fi if [ "$ARCHTYPE" == "tgz" ] then tar -C $ARCHTMP -xzf $ARCHTMP/$ARCHIVE fi if [ "$ARCHTYPE" == "zip" ] then unzip -d $ARCHTMP $ARCHTMP/$ARCHIVE fi fi fi cat $CONFDIR/$CONF | while read file mibs; do if [ "$file" != "#" ] then if [ ! -z "$PREFIX" ] then file=$PREFIX$file fi if [ ! -z "$SUFFIX" ] then file=$file$SUFFIX fi if [ -z "$ARCHIVE" ] then wget -O - -q -nv $HOST/$DIR/$file | tr -d \\r | $SMISTRIP -v -a -d $TMP -m $mibs - else cat $ARCHTMP/$ARCHDIR/$file | tr -d \\r | $SMISTRIP -v -a -d $TMP -m $mibs - fi fi done if [ ! -z "$DIFF" ] then patch -d $TMP < $CONFDIR/$DIFF fi if [ ! -d $BASEDIR/$DEST ] then mkdir -p $BASEDIR/$DEST fi cp $TMP/* $BASEDIR/$DEST rm -f $BASEDIR/$DEST/.index rm -fr $TMP if [ ! -z "$ARCHTMP" ] then rm -rf $ARCHTMP fi } sources=$1 if [ -z "$sources" ] then sources=$AUTOLOAD fi for i in $sources do TMP= ARCHTMP= HOST= DIR= CONF= DEST= DIFF= PREFIX= SUFFIX= ARCHIVE= ARCHTYPE= ARCHDIR= . $CONFDIR/$i.conf download_mibs done snmp-mibs-downloader-1.1/rfcmibs.diff0000644000000000000000000005041211402176070014561 0ustar diff -ru /usr/local/share/snmp/rfc.orig/ADSL-LINE-MIB /usr/local/share/snmp/rfc/ADSL-LINE-MIB --- /usr/local/share/snmp/rfc.orig/ADSL-LINE-MIB Sat Mar 3 17:27:00 2001 +++ /usr/local/share/snmp/rfc/ADSL-LINE-MIB Tue Jan 23 00:42:41 2001 @@ -3379,7 +3379,6 @@ static profiles are implemented." OBJECT adslAtucConfMinSnrMgn - MIN-ACCESS read-wr MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when diff -ru /usr/local/share/snmp/rfc.orig/DLSW-MIB /usr/local/share/snmp/rfc/DLSW-MIB --- /usr/local/share/snmp/rfc.orig/DLSW-MIB Sat Mar 3 17:18:28 2001 +++ /usr/local/share/snmp/rfc/DLSW-MIB Tue Jan 23 00:13:40 2001 @@ -7,7 +7,7 @@ Counter32, Gauge32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY, - NOTIFICATION-TYPE FROM SNMPv2-SMI + NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB @@ -150,12 +150,12 @@ -- The DLSw MIB module contains an object part and a conformance part. -- Object part is organized in the following groups: --- (1) dlswNode -- information about this DLSw --- (2) dlswTConn -- about adjacent DLSw partners --- (3) dlswInterface -- about which interfaces DLSw is active on --- (4) dlswDirectory -- about any directory of local/remote resources --- (5) dlswCircuit -- about established circuits. --- (6) dlswSdlc -- about SDLC data link switched devices +-- (1) dlswNode - information about this DLSw +-- (2) dlswTConn - about adjacent DLSw partners +-- (3) dlswInterface - about which interfaces DLSw is active on +-- (4) dlswDirectory - about any directory of local/remote resources +-- (5) dlswCircuit - about established circuits. +-- (6) dlswSdlc - about SDLC data link switched devices dlswNode OBJECT IDENTIFIER ::= { dlswMIB 1 } dlswTConn OBJECT IDENTIFIER ::= { dlswMIB 2 } @@ -168,9 +168,9 @@ -- THE NODE GROUP -- ******************************************************************* --- ------------------------------------------------------------------- +-- =================================================================== -- DLSw Node Identity --- ------------------------------------------------------------------- +-- =================================================================== dlswNodeVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only @@ -211,9 +211,9 @@ "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswNode 3 } --- ------------------------------------------------------------------- +-- =================================================================== -- DLSw Code Capability --- ------------------------------------------------------------------- +-- =================================================================== dlswNodeStdPacingSupport OBJECT-TYPE SYNTAX INTEGER { none (1), -- does not support DLSw @@ -238,9 +238,9 @@ scheme but never varies its receive window size." ::= { dlswNode 4 } --- ------------------------------------------------------------------- +-- =================================================================== -- DLSw Node Operational Objects --- ------------------------------------------------------------------- +--==================================================================== dlswNodeStatus OBJECT-TYPE SYNTAX INTEGER { active (1), @@ -339,10 +339,10 @@ -- TRANSPORT CONNECTION (aka: PARTNER DLSW) -- ******************************************************************* --- ------------------------------------------------------------------- +-- =================================================================== -- Transport Connection Statistics Objects --- ------------------------------------------------------------------- +-- =================================================================== dlswTConnStat OBJECT IDENTIFIER ::= { dlswTConn 1 } dlswTConnStatActiveConnections OBJECT-TYPE @@ -375,9 +375,9 @@ this means the transport connection failed unexpectedly." ::= { dlswTConnStat 3 } --- ------------------------------------------------------------------- +-- =================================================================== -- Transport Connection Configuration Table --- ------------------------------------------------------------------- +-- =================================================================== dlswTConnConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnConfigEntry MAX-ACCESS not-accessible @@ -651,15 +651,15 @@ row definition out of use." ::= { dlswTConnConfigEntry 13 } --- ------------------------------------------------------------------- +-- =================================================================== -- Transport Connection Operation Table --- ------------------------------------------------------------------- +-- =================================================================== -- (1) At most one transport connection can be connected between -- this DLSw and one of its DLSw partners at a given time. -- (2) Multiple transport types are supported. -- (3) Since the entries may be reused, dlswTConnOperEntryTime -- needs to be consulted for the possibility of counter reset. --- ------------------------------------------------------------------- +-- =================================================================== dlswTConnOperTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnOperEntry @@ -1254,14 +1254,14 @@ connection, where `active' means not in `disconnected' state." ::= { dlswTConnOperEntry 36 } --- ------------------------------------------------------------------- +-- =================================================================== -- Transport Connection Specific --- ------------------------------------------------------------------- +-- =================================================================== dlswTConnSpecific OBJECT IDENTIFIER ::= { dlswTConn 4 } dlswTConnTcp OBJECT IDENTIFIER ::= { dlswTConnSpecific 1 } -- ................................................................... --- TCP Transport Connection Specific -- Configuration +-- TCP Transport Connection Specific - Configuration -- ................................................................... dlswTConnTcpConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnTcpConfigEntry @@ -1328,7 +1328,7 @@ ::= { dlswTConnTcpConfigEntry 3 } -- ................................................................... --- TCP Transport Connection Specific -- Operation +-- TCP Transport Connection Specific - Operation -- ................................................................... dlswTConnTcpOperTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnTcpOperEntry @@ -1472,9 +1472,9 @@ -- transport address of the DLSw partner is cached. -- ******************************************************************* --- ------------------------------------------------------------------- +-- =================================================================== -- Directory Related Statistical Objects --- ------------------------------------------------------------------- +-- =================================================================== dlswDirStat OBJECT IDENTIFIER ::= { dlswDirectory 1 } dlswDirMacEntries OBJECT-TYPE @@ -1556,9 +1556,9 @@ create new rows." ::= { dlswDirStat 8 } --- ------------------------------------------------------------------- +-- =================================================================== -- Directory Cache --- ------------------------------------------------------------------- +-- =================================================================== dlswDirCache OBJECT IDENTIFIER ::= { dlswDirectory 2 } -- ................................................................... @@ -1566,7 +1566,7 @@ -- All Possible combinations of values of these objects. -- -- EntryType LocationType Location Status --- -------------- ------------ ------------------ -------------- +-- ============== ============ ================== ============== -- userConfigured local ifEntry or 0.0 reachable, or -- notReachable, or -- unknown @@ -1743,7 +1743,7 @@ -- All Possible combinations of values of these objects. -- -- EntryType LocationType Location Status --- -------------- ------------ ------------------ -------------- +-- ============== ============ ================== ============== -- userConfigured local ifEntry or 0.0 reachable, or -- notReachable, or -- unknown @@ -1918,9 +1918,9 @@ following the RowStatus textual convention." ::= { dlswDirNBEntry 9 } --- ------------------------------------------------------------------- +-- =================================================================== -- Resource Locations --- ------------------------------------------------------------------- +-- =================================================================== dlswDirLocate OBJECT IDENTIFIER ::= { dlswDirectory 3 } @@ -2056,9 +2056,9 @@ -- station that receives the initiation. -- ******************************************************************* --- ------------------------------------------------------------------- +-- =================================================================== -- Statistics Related to Circuits --- ------------------------------------------------------------------- +-- =================================================================== dlswCircuitStat OBJECT IDENTIFIER ::= { dlswCircuit 1 } dlswCircuitStatActives OBJECT-TYPE @@ -2079,7 +2079,7 @@ or reactivated upon exiting `disconnected' state." ::= { dlswCircuitStat 2 } --- ------------------------------------------------------------------- +-- =================================================================== -- Circuit Table -- -- This table is the DLSw entity's view of circuits. There will be @@ -2090,9 +2090,9 @@ -- this Circuit Table: -- -- number of | Origin End Station Location --- entries in the |-------------------------------------- +-- entries in the |====================================== -- Circuit Table | internal local remote --- -----------------------|-------------------------------------- +-- =======================|====================================== -- Target | internal | NA 2 1 -- End | local | 2 2 1 -- Station | remote | 1 1 NA @@ -2106,7 +2106,7 @@ -- -- Most of statistics related to circuits can be collected -- from LLC-2 Link Station Table. --- ------------------------------------------------------------------- +-- =================================================================== dlswCircuitTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswCircuitEntry MAX-ACCESS not-accessible @@ -2814,7 +2814,7 @@ -- ******************************************************************* dlswTraps OBJECT IDENTIFIER ::= { dlswMIB 0 } --- ------------------------------------------------------------------- +-- =================================================================== -- This section defines the well-known notifications sent by -- DLSW agents. -- Care must be taken to insure that no particular notification @@ -2827,7 +2827,7 @@ -- (3) Transport connection up/down -- (4) Circuit up/down --- ------------------------------------------------------------------- +-- =================================================================== -- dlswTrapTConnPartnerReject NOTIFICATION-TYPE @@ -2902,9 +2902,9 @@ dlswCompliances OBJECT IDENTIFIER ::= { dlswConformance 1 } dlswGroups OBJECT IDENTIFIER ::= { dlswConformance 2 } --- ------------------------------------------------------------------- +-- =================================================================== -- COMPLIANCE STATEMENTS --- ------------------------------------------------------------------- +-- =================================================================== -- ................................................................... -- Core compliance for all DLSw entities @@ -3245,9 +3245,9 @@ "Write access is not required." ::= { dlswCompliances 5 } --- ------------------------------------------------------------------- +-- =================================================================== -- CONFORMANCE GROUPS --- ------------------------------------------------------------------- +-- =================================================================== -- ................................................................... -- Node Conformance Group diff -ru /usr/local/share/snmp/rfc.orig/DSA-MIB /usr/local/share/snmp/rfc/DSA-MIB --- /usr/local/share/snmp/rfc.orig/DSA-MIB Sat Mar 3 17:15:36 2001 +++ /usr/local/share/snmp/rfc/DSA-MIB Thu Feb 22 00:33:45 2001 @@ -10,7 +10,7 @@ mib-2 FROM RFC1213-MIB applIndex, DistinguishedName - FROM APPLICATION-MIB; + FROM NETWORK-SERVICES-MIB; dsaMIB MODULE-IDENTITY LAST-UPDATED "9311250000Z" diff -ru /usr/local/share/snmp/rfc.orig/FDDI-SMT73-MIB /usr/local/share/snmp/rfc/FDDI-SMT73-MIB --- /usr/local/share/snmp/rfc.orig/FDDI-SMT73-MIB Sat Mar 3 17:15:09 2001 +++ /usr/local/share/snmp/rfc/FDDI-SMT73-MIB Tue Jan 23 00:11:46 2001 @@ -3,6 +3,8 @@ IMPORTS Counter FROM RFC1155-SMI + transmission + FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; diff -ru /usr/local/share/snmp/rfc.orig/HPR-MIB /usr/local/share/snmp/rfc/HPR-MIB --- /usr/local/share/snmp/rfc.orig/HPR-MIB Sat Mar 3 17:19:54 2001 +++ /usr/local/share/snmp/rfc/HPR-MIB Tue Jan 23 00:25:54 2001 @@ -18,7 +18,7 @@ FROM APPN-MIB; hprMIB MODULE-IDENTITY - LAST-UPDATED "970514000000Z" + LAST-UPDATED "9705140000Z" ORGANIZATION "AIW APPN / HPR MIB SIG" CONTACT-INFO " diff -ru /usr/local/share/snmp/rfc.orig/MIP-MIB /usr/local/share/snmp/rfc/MIP-MIB --- /usr/local/share/snmp/rfc.orig/MIP-MIB Sat Mar 3 17:17:42 2001 +++ /usr/local/share/snmp/rfc/MIP-MIB Tue Jan 23 00:25:27 2001 @@ -1,7 +1,7 @@ MIP-MIB DEFINITIONS ::= BEGIN IMPORTS - Counter32, Gauge32, Integer32, IpAddress, experimental, + Counter32, Gauge32, Integer32, IpAddress, mib-2, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp, @@ -2117,7 +2117,7 @@ function within a home agent." ::= { mipGroups 12 } - mipSecNotifcationsGroup NOTIFICATION-GROUP + mipSecNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { mipAuthFailure } STATUS current DESCRIPTION diff -ru /usr/local/share/snmp/rfc.orig/Modem-MIB /usr/local/share/snmp/rfc/Modem-MIB --- /usr/local/share/snmp/rfc.orig/Modem-MIB Sat Mar 3 17:16:35 2001 +++ /usr/local/share/snmp/rfc/Modem-MIB Mon Jan 22 23:53:08 2001 @@ -23,7 +23,7 @@ E-mail: waldbusser@cmu.edu" DESCRIPTION "The MIB module for management of dial-up modems." - ::= { mdmMIB 1 } + ::= { mdmMib 1 } mdmMib OBJECT IDENTIFIER ::= { mib-2 38 } diff -ru /usr/local/share/snmp/rfc.orig/PPP-LCP-MIB /usr/local/share/snmp/rfc/PPP-LCP-MIB --- /usr/local/share/snmp/rfc.orig/PPP-LCP-MIB Sat Mar 3 17:14:46 2001 +++ /usr/local/share/snmp/rfc/PPP-LCP-MIB Sat Mar 3 23:13:27 2001 @@ -182,7 +182,7 @@ ::= { pppLinkStatusEntry 5 } pppLinkStatusLocalMRU OBJECT-TYPE - SYNTAX INTEGER(1..2147483648) + SYNTAX INTEGER(1..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION @@ -195,7 +195,7 @@ ::= { pppLinkStatusEntry 6 } pppLinkStatusRemoteMRU OBJECT-TYPE - SYNTAX INTEGER(1..2147483648) + SYNTAX INTEGER(1..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION @@ -535,7 +535,7 @@ ::= { pppLqrEntry 2 } pppLqrLocalPeriod OBJECT-TYPE - SYNTAX INTEGER(1..2147483648) + SYNTAX INTEGER(1..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION @@ -548,7 +548,7 @@ ::= { pppLqrEntry 3 } pppLqrRemotePeriod OBJECT-TYPE - SYNTAX INTEGER(1..2147483648) + SYNTAX INTEGER(1..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION diff -ru /usr/local/share/snmp/rfc.orig/RDBMS-MIB /usr/local/share/snmp/rfc/RDBMS-MIB --- /usr/local/share/snmp/rfc.orig/RDBMS-MIB Sat Mar 3 17:16:41 2001 +++ /usr/local/share/snmp/rfc/RDBMS-MIB Tue Jan 23 00:24:04 2001 @@ -6,8 +6,8 @@ FROM SNMPv2-SMI DisplayString, DateAndTime, AutonomousType FROM SNMPv2-TC - applIndex, applGroup - FROM APPLICATION-MIB + applIndex, applGroups + FROM NETWORK-SERVICES-MIB mib-2 FROM RFC1213-MIB; @@ -1263,8 +1263,8 @@ implement the RDBMS MIB" MODULE HOST-RESOURCES-MIB MANDATORY-GROUPS { hrSystem } - MODULE APPLICATION-MIB - MANDATORY-GROUPS { applGroup } + MODULE NETWORK-SERVICES-MIB + MANDATORY-GROUPS { applGroups } MODULE RDBMS-MIB MANDATORY-GROUPS { rdbmsGroup } Only in /usr/local/share/snmp/rfc: RFC-1215 diff -ru /usr/local/share/snmp/rfc.orig/RFC1414-MIB /usr/local/share/snmp/rfc/RFC1414-MIB --- /usr/local/share/snmp/rfc.orig/RFC1414-MIB Sat Mar 3 17:14:37 2001 +++ /usr/local/share/snmp/rfc/RFC1414-MIB Tue Feb 20 00:25:21 2001 @@ -3,6 +3,7 @@ IMPORTS OBJECT-TYPE FROM RFC-1212 + mib-2, tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort FROM RFC1213-MIB; diff -ru /usr/local/share/snmp/rfc.orig/SNA-NAU-MIB /usr/local/share/snmp/rfc/SNA-NAU-MIB --- /usr/local/share/snmp/rfc.orig/SNA-NAU-MIB Sat Mar 3 17:16:24 2001 +++ /usr/local/share/snmp/rfc/SNA-NAU-MIB Mon Jan 22 23:57:44 2001 @@ -17,7 +17,7 @@ DisplayString, RowStatus, TimeStamp, InstancePointer FROM SNMPv2-TC - Counter32, Gauge32, Integer32, + Counter32, Gauge32, Integer32, mib-2, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI diff -ru /usr/local/share/snmp/rfc.orig/TCPIPX-MIB /usr/local/share/snmp/rfc/TCPIPX-MIB --- /usr/local/share/snmp/rfc.orig/TCPIPX-MIB Sat Mar 3 17:17:17 2001 +++ /usr/local/share/snmp/rfc/TCPIPX-MIB Sat Mar 3 16:51:11 2001 @@ -1,6 +1,8 @@ TCPIPX-MIB DEFINITIONS ::= BEGIN IMPORTS + enterprises + FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; @@ -10,7 +12,7 @@ -- as hex digits, as in: nnnnnnnn:mmmmmmmmmmmm -IpxAddress ::= OCTET STRING (size (10)) +IpxAddress ::= OCTET STRING (SIZE (10)) -- TCP/IPX MIB object idenfifiers diff -ru /usr/local/share/snmp/rfc.orig/UPS-MIB /usr/local/share/snmp/rfc/UPS-MIB --- /usr/local/share/snmp/rfc.orig/UPS-MIB Sat Mar 3 17:16:01 2001 +++ /usr/local/share/snmp/rfc/UPS-MIB Mon Jan 22 23:55:45 2001 @@ -2,7 +2,7 @@ IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, - OBJECT-IDENTITY, Counter32, Gauge32, Integer32 + OBJECT-IDENTITY, Counter32, Gauge32, Integer32, mib-2 FROM SNMPv2-SMI DisplayString, TimeStamp, TimeInterval, TestAndIncr, AutonomousType diff -ru /usr/local/share/snmp/rfc.orig/SMUX-MIB /usr/local/share/snmp/rfc/SMUX-MIB --- /usr/local/share/snmp/rfc.orig/SMUX-MIB 2002-06-15 15:31:22.000000000 +0200 +++ /usr/local/share/snmp/rfc/SMUX-MIB 2002-06-15 15:31:22.000000000 +0200 @@ -3,6 +3,8 @@ IMPORTS enterprises FROM RFC1155-SMI + DisplayString + FROM RFC1213-MIB OBJECT-TYPE FROM RFC1212; @@ -120,7 +122,7 @@ ::= { smuxTreeEntry 1 } smuxTpriority OBJECT-TYPE - SYNTAX INTEGER (0..'07fffffff'h) + SYNTAX INTEGER (0..'7fffffff'h) ACCESS read-only STATUS mandatory DESCRIPTION snmp-mibs-downloader-1.1/iana.conf0000644000000000000000000000025511402176071014062 0ustar # Configuarions for IANA MIBs download from iana.org # #HOST=http://www.iana.org #DIR=assignments DIR=/usr/share/doc ARCHIVE=mibiana ARCHTYPE=dirgz CONF=ianalist DEST=iana snmp-mibs-downloader-1.1/rfc.conf0000644000000000000000000000033111402176071013717 0ustar # Configuarions for IETF MIBs download from rfc-editor.org # #HOST=http://www.rfc-editor.org #DIR=rfc DIR=/usr/share/doc ARCHIVE=mibrfcs ARCHTYPE=dirgz CONF=rfclist DEST=ietf DIFF=rfcmibs.diff PREFIX=rfc SUFFIX=.txt snmp-mibs-downloader-1.1/simpleweb.conf0000644000000000000000000000024511402176071015140 0ustar # Configuarions for RFC-1212 and RFC-1215 MIBs download from simpleweb.org # HOST=http://www.simpleweb.org DIR=ietf/mibs/modules/IETF/txt CONF=simplelist DEST=ietf snmp-mibs-downloader-1.1/simplelist0000644000000000000000000000004411402176071014407 0ustar RFC-1212 RFC-1212 RFC-1215 RFC-1215 snmp-mibs-downloader-1.1/download-mibs.10000644000000000000000000000203111402176071015116 0ustar .\" /*********************************************************** .\" Copyright 2009 Jochen Friedrich .\" .\" All Rights Reserved .\" .\" Permission to use, copy, modify, and distribute this software and its .\" documentation for any purpose and without fee is hereby granted, .\" provided that the above copyright notice appear in all copies and that .\" both that copyright notice and this permission notice appear in .\" supporting documentation. .\" ******************************************************************/ .TH DOWNLOAD-MIBS 1 "download-mibs 1.0" .SH NAME download-mibs \- download and extract SNMP MIBs .SH SYNOPSIS .B download-mibs [config] .SH DESCRIPTION .I download-mibs Downloads SNMP MIBs from IETF, IANA and other sites in the Internet. Strips the MIBs from the documents or archives and sort them into the libsmi directory structure. .SH OPTIONS .TP 8 .B \fI[config]\fB Use particular configuration(s) rather than the included default. .SH AUTHOR Jochen Friedrich snmp-mibs-downloader-1.1/ianarfclist0000644000000000000000000000011211402176071014515 0ustar # IANA maintained MIBs from RFCs. # Updated 2010-06-04 5601 IANA-PWE3-MIB snmp-mibs-downloader-1.1/ianarfc.conf0000644000000000000000000000024211402176071014551 0ustar # Configuarions for IANA MIBs download from rfc-editor.org # DIR=/usr/share/doc ARCHIVE=mibrfcs ARCHTYPE=dirgz CONF=ianarfclist DEST=iana PREFIX=rfc SUFFIX=.txt snmp-mibs-downloader-1.1/cisco.conf0000644000000000000000000000024011402176071014244 0ustar # Configuarions for Cisco v2 MIBs download from cisco.com # HOST=ftp://ftp.cisco.com ARCHIVE=v2.tar.gz ARCHTYPE=tgz DIR=pub/mibs/v2/ CONF=ciscolist DEST=cisco snmp-mibs-downloader-1.1/ciscolist0000644000000000000000000014067011402176071014230 0ustar ADMIN-AUTH-STATS-MIB.my ADMIN-AUTH-STATS-MIB ADSL-DMT-LINE-MIB.my ADSL-DMT-LINE-MIB AIRESPACE-REF-MIB.my AIRESPACE-REF-MIB AIRESPACE-SWITCHING-MIB.my AIRESPACE-SWITCHING-MIB AIRESPACE-WIRELESS-MIB.my AIRESPACE-WIRELESS-MIB ALTIGA-ADDRESS-STATS-MIB.my ALTIGA-ADDRESS-STATS-MIB ALTIGA-BMGT-STATS-MIB.my ALTIGA-BMGT-STATS-MIB ALTIGA-CAP.my ALTIGA-CAP ALTIGA-CERT-STATS-MIB.my ALTIGA-CERT-STATS-MIB ALTIGA-DHCP-SERVER-STATS-MIB.my ALTIGA-DHCP-SERVER-STATS-MIB ALTIGA-DHCP-STATS-MIB.my ALTIGA-DHCP-STATS-MIB ALTIGA-DNS-STATS-MIB.my ALTIGA-DNS-STATS-MIB ALTIGA-EVENT-STATS-MIB.my ALTIGA-EVENT-STATS-MIB ALTIGA-FILTER-STATS-MIB.my ALTIGA-FILTER-STATS-MIB ALTIGA-FTP-STATS-MIB.my ALTIGA-FTP-STATS-MIB ALTIGA-GENERAL-STATS-MIB.my ALTIGA-GENERAL-STATS-MIB ALTIGA-GLOBAL-REG.my ALTIGA-GLOBAL-REG ALTIGA-HARDWARE-STATS-MIB.my ALTIGA-HARDWARE-STATS-MIB ALTIGA-HTTP-STATS-MIB.my ALTIGA-HTTP-STATS-MIB ALTIGA-IP-STATS-MIB.my ALTIGA-IP-STATS-MIB ALTIGA-L2TP-STATS-MIB.my ALTIGA-L2TP-STATS-MIB ALTIGA-LBSSF-STATS-MIB.my ALTIGA-LBSSF-STATS-MIB ALTIGA-MIB.my ALTIGA-MIB ALTIGA-MULTILINK-STATS-MIB.my ALTIGA-MULTILINK-STATS-MIB ALTIGA-NAT-STATS-MIB.my ALTIGA-NAT-STATS-MIB ALTIGA-PPPOE-STATS-MIB.my ALTIGA-PPPOE-STATS-MIB ALTIGA-PPP-STATS-MIB.my ALTIGA-PPP-STATS-MIB ALTIGA-PPTP-STATS-MIB.my ALTIGA-PPTP-STATS-MIB ALTIGA-SDI-ACE-STATS-MIB.my ALTIGA-SDI-ACE-STATS-MIB ALTIGA-SEP-STATS-MIB.my ALTIGA-SEP-STATS-MIB ALTIGA-SESSION-STATS-MIB.my ALTIGA-SESSION-STATS-MIB ALTIGA-SSH-STATS-MIB.my ALTIGA-SSH-STATS-MIB ALTIGA-SSL-STATS-MIB.my ALTIGA-SSL-STATS-MIB ALTIGA-SYNC-STATS-MIB.my ALTIGA-SYNC-STATS-MIB ALTIGA-T1E1-STATS-MIB.my ALTIGA-T1E1-STATS-MIB ALTIGA-TELNET-STATS-MIB.my ALTIGA-TELNET-STATS-MIB ALTIGA-VERSION-STATS-MIB.my ALTIGA-VERSION-STATS-MIB ATM-FORUM-MIB.my ATM-FORUM-MIB ATM-FORUM-TC-MIB.my ATM-FORUM-TC-MIB ATM-RMON-MIB.my ATM-RMON-MIB ATM-SOFT-PVC-MIB.my ATM-SOFT-PVC-MIB AWC-VLAN-CFG-MIB.my AWC-VLAN-CFG-MIB BASIS-GENERIC-MIB.my BASIS-GENERIC-MIB BASIS-MIB.my BASIS-MIB BASIS-ONLINE-DIAG-MIB.my BASIS-ONLINE-DIAG-MIB BASIS-RAS-DISK-MIB.my BASIS-RAS-DISK-MIB BASIS-SERIAL-MIB.my BASIS-SERIAL-MIB BASIS-SHELF-MIB.my BASIS-SHELF-MIB CALISTA-DPA-MIB.my CALISTA-DPA-MIB CISCO-5800-HEALTH-MON-MIB.my CISCO-5800-HEALTH-MON-MIB CISCO-6400-CHASSIS-MIB.my CISCO-6400-CHASSIS-MIB CISCO-802-TAP-MIB.my CISCO-802-TAP-MIB CISCO-90-MIB.my Cisco90Series-MIB CISCO-AAA-CLIENT-CAPABILITY.my CISCO-AAA-CLIENT-CAPABILITY CISCO-AAA-CLIENT-MIB.my CISCO-AAA-CLIENT-MIB CISCO-AAA-SERVER-CAPABILITY.my CISCO-AAA-SERVER-CAPABILITY CISCO-AAA-SERVER-EXT-CAPABILITY.my CISCO-AAA-SERVER-EXT-CAPABILITY CISCO-AAA-SERVER-EXT-MIB.my CISCO-AAA-SERVER-EXT-MIB CISCO-AAA-SERVER-MIB.my CISCO-AAA-SERVER-MIB CISCO-AAA-SESSION-MIB.my CISCO-AAA-SESSION-MIB CISCO-AAL5-EXT-MIB.my CISCO-AAL5-EXT-MIB CISCO-AAL5-MIB.my CISCO-AAL5-MIB CISCO-ACCESS-ENVMON-MIB.my CISCO-ACCESS-ENVMON-MIB CISCO-ADSL-CAP-LINE-MIB.my CISCO-ADSL-CAP-LINE-MIB CISCO-ADSL-DMT-LINE-MIB.my CISCO-ADSL-DMT-LINE-MIB CISCO-ALPS-MIB.my CISCO-ALPS-MIB CISCO-ANNOUNCEMENT-MIB.my CISCO-ANNOUNCEMENT-MIB CISCO-AON-STATUS-MIB.my CISCO-AON-STATUS-MIB CISCO-APPLIANCE-REDUNDANCY-MIB.my CISCO-APPLIANCE-REDUNDANCY-MIB CISCO-APS-EXT-MIB.my CISCO-APS-EXT-MIB CISCO-APS-MIB.my CISCO-APS-MIB CISCO-ASPP-MIB.my CISCO-ASPP-MIB CISCO-ATM2-MIB.my CISCO-ATM2-MIB CISCO-ATM-ACCESS-LIST-MIB.my CISCO-ATM-ACCESS-LIST-MIB CISCO-ATM-ADDR-MIB.my CISCO-ATM-ADDR-MIB CISCO-ATM-CAPABILITY.my CISCO-ATM-CAPABILITY CISCO-ATM-CELL-LAYER-CAPABILITY.my CISCO-ATM-CELL-LAYER-CAPABILITY CISCO-ATM-CELL-LAYER-MIB.my CISCO-ATM-CELL-LAYER-MIB CISCO-ATM-CONN-INFO-MIB.my CISCO-ATM-CONN-INFO-MIB CISCO-ATM-CONN-MIB.my CISCO-ATM-CONN-MIB CISCO-ATM-DUAL-PHY-MIB.my CISCO-ATM-DUAL-PHY-MIB CISCO-ATM-EXT-MIB.my CISCO-ATM-EXT-MIB CISCO-ATM-IF-MIB.my CISCO-ATM-IF-MIB CISCO-ATM-IF-PHYS-MIB.my CISCO-ATM-IF-PHYS-MIB CISCO-ATM-NETWORK-CLOCK-MIB.my CISCO-ATM-NETWORK-CLOCK-MIB CISCO-ATM-PVC-MIB.my CISCO-ATM-PVC-MIB CISCO-ATM-PVCTRAP-EXTN-MIB.my CISCO-ATM-PVCTRAP-EXTN-MIB CISCO-ATM-QOS-MIB.my CISCO-ATM-QOS-MIB CISCO-ATM-RM-MIB.my CISCO-ATM-RM-MIB CISCO-ATM-SERVICE-REGISTRY-MIB.my CISCO-ATM-SERVICE-REGISTRY-MIB CISCO-ATM-SWITCH-ADDR-MIB.my CISCO-ATM-SWITCH-ADDR-MIB CISCO-ATM-SWITCH-CUG-MIB.my CISCO-ATM-SWITCH-CUG-MIB CISCO-ATM-SWITCH-FR-IWF-MIB.my CISCO-ATM-SWITCH-FR-IWF-MIB CISCO-ATM-SWITCH-FR-RM-MIB.my CISCO-ATM-SWITCH-FR-RM-MIB CISCO-ATM-TRAFFIC-MIB.my CISCO-ATM-TRAFFIC-MIB CISCO-ATM-TRUNK-MIB.my CISCO-ATM-TRUNK-MIB CISCO-ATM-TRUNK-STAT-CAPABILITY.my CISCO-ATM-TRUNK-STAT-CAPABILITY CISCO-ATM-TRUNK-STAT-MIB.my CISCO-ATM-TRUNK-STAT-MIB CISCO-ATM-VIRTUAL-IF-CAPABILITY.my CISCO-ATM-VIRTUAL-IF-CAPABILITY CISCO-ATM-VIRTUAL-IF-MIB.my CISCO-ATM-VIRTUAL-IF-MIB CISCO-AUTHORIZATION-STATS-MIB.my CISCO-AUTHORIZATION-STATS-MIB CISCO-BBSM-MIB.my CISCO-BBSM-MIB CISCO-BCP-MIB.my CISCO-BCP-MIB CISCO-BERT-CAPABILITY.my CISCO-BERT-CAPABILITY CISCO-BERT-MIB.my CISCO-BERT-MIB CISCO-BGP-POLICY-ACCOUNTING-MIB-CAPABILITY.my CISCO-BGP-POLICY-ACCOUNTING-MIB-CAPABILITY CISCO-BGP-POLICY-ACCOUNTING-MIB.my CISCO-BGP-POLICY-ACCOUNTING-MIB CISCO-BITS-CLOCK-CAPABILITY.my CISCO-BITS-CLOCK-CAPABILITY CISCO-BITS-CLOCK-MIB.my CISCO-BITS-CLOCK-MIB CISCO-BRIDGE-CAPABILITY.my CISCO-BRIDGE-CAPABILITY CISCO-BRIDGE-EXT-CAPABILITY.my CISCO-BRIDGE-EXT-CAPABILITY CISCO-BRIDGE-EXT-MIB.my CISCO-BRIDGE-EXT-MIB CISCO-BSC-MIB.my CISCO-BSC-MIB CISCO-BSTUN-MIB.my CISCO-BSTUN-MIB CISCO-BULK-FILE-CAPABILITY.my CISCO-BULK-FILE-CAPABILITY CISCO-BULK-FILE-MIB.my CISCO-BULK-FILE-MIB CISCO-BUS-MIB.my CISCO-BUS-MIB CISCO-C12000-IF-HC-COUNTERS-MIB.my CISCO-C12000-IF-HC-COUNTERS-MIB CISCO-C2900-MIB.my CISCO-C2900-MIB CISCO-C6200-MIB.my CISCO-6200-MIB CISCO-C8500-REDUNDANCY-MIB.my CISCO-C8500-REDUNDANCY-MIB CISCO-CABLE-ADM-C-CAPABILITY.my CISCO-CABLE-ADM-C-CAPABILITY CISCO-CABLE-ADMISSION-CTRL-MIB.my CISCO-CABLE-ADMISSION-CTRL-MIB CISCO-CABLE-AVAILABILITY-MIB.my CISCO-CABLE-AVAILABILITY-MIB CISCO-CABLE-DIAG-CAPABILITY.my CISCO-CABLE-DIAG-CAPABILITY CISCO-CABLE-DIAG-MIB.my CISCO-CABLE-DIAG-MIB CISCO-CABLE-METERING-MIB.my CISCO-CABLE-METERING-MIB CISCO-CABLE-QOS-MONITOR-MIB.my CISCO-CABLE-QOS-MONITOR-MIB CISCO-CABLE-SPECTRUM-MIB.my CISCO-CABLE-SPECTRUM-MIB CISCO-CABLE-WIDEBAND-CAPABILITY.my CISCO-CABLE-WIDEBAND-CAPABILITY CISCO-CABLE-WIDEBAND-MIB.my CISCO-CABLE-WIDEBAND-MIB CISCO-CAC-SYSTEM-MIB.my CISCO-CAC-SYSTEM-MIB CISCO-CALL-APPLICATION-MIB.my CISCO-CALL-APPLICATION-MIB CISCO-CALL-HISTORY-MIB.my CISCO-CALL-HISTORY-MIB CISCO-CALLHOME-CAPABILITY.my CISCO-CALLHOME-CAPABILITY CISCO-CALLHOME-MIB.my CISCO-CALLHOME-MIB CISCO-CALL-RESOURCE-POOL-MIB.my CISCO-CALL-RESOURCE-POOL-MIB CISCO-CALL-TRACKER-MIB.my CISCO-CALL-TRACKER-MIB CISCO-CALL-TRACKER-MODEM-MIB.my CISCO-CALL-TRACKER-MODEM-MIB CISCO-CALL-TRACKER-TCP-MIB.my CISCO-CALL-TRACKER-TCP-MIB CISCO-CAR-MIB.my CISCO-CAR-MIB CISCO-CASA-FA-CAPABILITY.my CISCO-CASA-FA-CAPABILITY CISCO-CASA-FA-MIB.my CISCO-CASA-FA-MIB CISCO-CASA-MIB.my CISCO-CASA-MIB CISCO-CAS-IF-EXT-CAPABILITY.my CISCO-CAS-IF-EXT-CAPABILITY CISCO-CAS-IF-EXT-MIB.my CISCO-CAS-IF-EXT-MIB CISCO-CAS-IF-MIB.my CISCO-CAS-IF-MIB CISCO-CAT6K-CROSSBAR-CAPABILITY.my CISCO-CAT6K-CROSSBAR-CAPABILITY CISCO-CAT6K-CROSSBAR-MIB.my CISCO-CAT6K-CROSSBAR-MIB CISCO-CATOS-ACL-QOS-CAPABILITY.my CISCO-CATOS-ACL-QOS-CAPABILITY CISCO-CATOS-ACL-QOS-MIB.my CISCO-CATOS-ACL-QOS-MIB CISCO-CBP-TARGET-MIB.my CISCO-CBP-TARGET-MIB CISCO-CBP-TARGET-TC-MIB.my CISCO-CBP-TARGET-TC-MIB CISCO-CCM-CAPABILITY.my CISCO-CCM-CAPABILITY CISCO-CCME-MIB.my CISCO-CCME-MIB CISCO-CCM-MIB.my CISCO-CCM-MIB CISCO-CDL-MIB.my CISCO-CDL-MIB CISCO-CDMA-AHDLC-MIB.my CISCO-CDMA-AHDLC-MIB CISCO-CDMA-PDSN-MIB.my CISCO-CDMA-PDSN-MIB CISCO-CDP-CAPABILITY.my CISCO-CDP-CAPABILITY CISCO-CDP-MIB.my CISCO-CDP-MIB CISCO-CEF-MIB.my CISCO-CEF-MIB CISCO-CEF-TC.my CISCO-CEF-TC CISCO-CFS-MIB.my CISCO-CFS-MIB CISCO-CHANNEL-MIB.my CISCO-CHANNEL-MIB CISCO-CIDS-MIB.my CISCO-CIDS-MIB CISCO-CIPCMPC-MIB.my CISCO-CIPCMPC-MIB CISCO-CIPCSNA-MIB.my CISCO-CIPCSNA-MIB CISCO-CIPLAN-MIB.my CISCO-CIPLAN-MIB CISCO-CIPTCPIP-MIB.my CISCO-CIPTCPIP-MIB CISCO-CIPTG-MIB.my CISCO-CIPTG-MIB CISCO-CIRCUIT-INTERFACE-MIB.my CISCO-CIRCUIT-INTERFACE-MIB CISCO-CLASS-BASED-QOS-MIB-CAPABILITY.my CISCO-CLASS-BASED-QOS-MIB-CAPABILITY CISCO-CLASS-BASED-QOS-MIB.my CISCO-CLASS-BASED-QOS-MIB CISCO-CLUSTER-MIB.my CISCO-CLUSTER-MIB CISCO-CNO-SWITCH-MIB.my CISCO-CNO-SWITCH-MIB CISCO-COMMON-MGMT-CAPABILITY.my CISCO-COMMON-MGMT-CAPABILITY CISCO-COMMON-MGMT-MIB.my CISCO-COMMON-MGMT-MIB CISCO-COMMON-ROLES-MIB.my CISCO-COMMON-ROLES-MIB CISCO-COMPRESSION-SERVICE-ADAPTER-MIB.my CISCO-COMPRESSION-SERVICE-ADAPTER-MIB CISCO-CONFIG-COPY-CAPABILITY.my CISCO-CONFIG-COPY-CAPABILITY CISCO-CONFIG-COPY-MIB.my CISCO-CONFIG-COPY-MIB CISCO-CONFIG-MAN-CAPABILITY.my CISCO-CONFIG-MAN-CAPABILITY CISCO-CONFIG-MAN-MIB.my CISCO-CONFIG-MAN-MIB CISCO-CONTENT-ENGINE-MIB.my CISCO-CONTENT-ENGINE-MIB CISCO-CONTENT-NETWORK-MIB.my CISCO-CONTENT-NETWORK-MIB CISCO-CONTENT-SERVICES-MIB.my CISCO-CONTENT-SERVICES-MIB CISCO-COPS-CLIENT-CAPABILITY.my CISCO-COPS-CLIENT-CAPABILITY CISCO-COPS-CLIENT-MIB.my CISCO-COPS-CLIENT-MIB CISCO-CRYPTO-ACCELERATOR-MIB.my CISCO-CRYPTO-ACCELERATOR-MIB CISCO-CSG-MIB.my CISCO-CSG-MIB CISCO-DATA-COLLECTION-CAPABILITY.my CISCO-DATA-COLLECTION-CAPABILITY CISCO-DATA-COLLECTION-MIB.my CISCO-DATA-COLLECTION-MIB CISCO-DDP-IAPP-MIB.my CISCO-DDP-IAPP-MIB CISCO-DEVICE-EXCEPTION-REPORTING-MIB.my CISCO-DEVICE-EXCEPTION-REPORTING-MIB CISCO-DHCP-SNOOPING-CAPABILITY.my CISCO-DHCP-SNOOPING-CAPABILITY CISCO-DHCP-SNOOPING-MIB.my CISCO-DHCP-SNOOPING-MIB CISCO-DIAL-CONTROL-MIB.my CISCO-DIAL-CONTROL-MIB CISCO-DIFFSERV-EXT-MIB.my CISCO-DIFFSERV-EXT-MIB CISCO-DISMAN-EVENT-CAPABILITY.my CISCO-DISMAN-EVENT-CAPABILITY CISCO-DISMAN-EXPRESSION-CAPABILITY.my CISCO-DISMAN-EXPRESSION-CAPABILITY CISCO-DIST-DIRECTOR-CAPABILITY.my CISCO-DIST-DIRECTOR-CAPABILITY CISCO-DIST-DIRECTOR-MIB.my CISCO-DIST-DIRECTOR-MIB CISCO-DLCSW-MIB.my CISCO-DLC-SWITCH-MIB CISCO-DLSW-EXT-MIB.my CISCO-DLSW-EXT-MIB CISCO-DM-MIB.my CISCO-DM-MIB CISCO-DNS-CLIENT-MIB.my CISCO-DNS-CLIENT-MIB CISCO-DNS-SERVER-MIB.my CISCO-DNS-SERVER-MIB CISCO-DOCS-EXT-MIB.my CISCO-DOCS-EXT-MIB CISCO-DOCS-REMOTE-QUERY-MIB.my CISCO-DOCS-REMOTE-QUERY-MIB CISCO-DOT11-ASSOCIATION-MIB.my CISCO-DOT11-ASSOCIATION-MIB CISCO-DOT11-CONTEXT-SERVICES-CAPABILITY.my CISCO-DOT11-CONTEXT-SERVICES-CAPABILITY CISCO-DOT11-CONTEXT-SERVICES-CLIENT-CAPABILITY.my CISCO-DOT11-CONTEXT-SERVICES-CLIENT-CAPABILITY CISCO-DOT11-CONTEXT-SERVICES-CLIENT-MIB.my CISCO-DOT11-CONTEXT-SERVICES-CLIENT-MIB CISCO-DOT11-CONTEXT-SERVICES-MIB.my CISCO-DOT11-CONTEXT-SERVICES-MIB CISCO-DOT11-HT-MAC-CAPABILITY.my CISCO-DOT11-HT-MAC-CAPABILITY CISCO-DOT11-HT-MAC-MIB.my CISCO-DOT11-HT-MAC-MIB CISCO-DOT11-HT-PHY-CAPABILITY.my CISCO-DOT11-HT-PHY-CAPABILITY CISCO-DOT11-HT-PHY-MIB.my CISCO-DOT11-HT-PHY-MIB CISCO-DOT11-IF-MIB.my CISCO-DOT11-IF-MIB CISCO-DOT11-LBS-MIB.my CISCO-DOT11-LBS-MIB CISCO-DOT11-QOS-MIB.my CISCO-DOT11-QOS-MIB CISCO-DOT11-RADAR-MIB.my CISCO-DOT11-RADAR-MIB CISCO-DOT11-RADIO-DIAGNOSTIC-CAPABILITY.my CISCO-DOT11-RADIO-DIAGNOSTIC-CAPABILITY CISCO-DOT11-RADIO-DIAGNOSTIC-MIB.my CISCO-DOT11-RADIO-DIAGNOSTIC-MIB CISCO-DOT11-SSID-SECURITY-MIB.my CISCO-DOT11-SSID-SECURITY-MIB CISCO-DOT11-WIDS-CAPABILITY.my CISCO-DOT11-WIDS-CAPABILITY CISCO-DOT11-WIDS-MIB.my CISCO-DOT11-WIDS-MIB CISCO-DS0BUNDLE-EXT-MIB.my CISCO-DS0BUNDLE-EXT-MIB CISCO-DS0BUNDLE-MIB.my CISCO-DS0BUNDLE-MIB CISCO-DS0-CROSS-CONNECT-MIB.my CISCO-DS0-CROSS-CONNECT-MIB CISCO-DS1-CAPABILITY.my CISCO-DS1-CAPABILITY CISCO-DS1-EXT-MIB.my CISCO-DS1-EXT-MIB CISCO-DS3-CAPABILITY.my CISCO-DS3-CAPABILITY CISCO-DS3-EXT-CAPABILITY.my CISCO-DS3-EXT-CAPABILITY CISCO-DS3-MIB.my CISCO-DS3-MIB CISCO-DSL-PROVISION-MIB.my CISCO-DSL-PROVISION-MIB CISCO-DSP-MGMT-CAPABILITY.my CISCO-DSP-MGMT-CAPABILITY CISCO-DSP-MGMT-MIB.my CISCO-DSP-MGMT-MIB CISCO-DSPU-MIB.my CISCO-DSPU-MIB CISCO-DYNAMIC-ARP-INSPECTION-CAPABILITY.my CISCO-DYNAMIC-ARP-INSPECTION-CAPABILITY CISCO-DYNAMIC-ARP-INSPECTION-MIB.my CISCO-DYNAMIC-ARP-INSPECTION-MIB CISCO-DYNAMIC-PORT-VSAN-MIB.my CISCO-DYNAMIC-PORT-VSAN-MIB CISCO-EIGRP-MIB.my CISCO-EIGRP-MIB CISCO-EMBEDDED-EVENT-MGR-MIB.my CISCO-EMBEDDED-EVENT-MGR-MIB CISCO-ENHANCED-IMAGE-CAPABILITY.my CISCO-ENHANCED-IMAGE-CAPABILITY CISCO-ENHANCED-IMAGE-MIB.my CISCO-ENHANCED-IMAGE-MIB CISCO-ENHANCED-IPSEC-FLOW-MIB.my CISCO-ENHANCED-IPSEC-FLOW-MIB CISCO-ENHANCED-MEMPOOL-CAPABILITY.my CISCO-ENHANCED-MEMPOOL-CAPABILITY CISCO-ENHANCED-MEMPOOL-MIB.my CISCO-ENHANCED-MEMPOOL-MIB CISCO-ENHANCED-SLB-CAPABILITY.my CISCO-ENHANCED-SLB-CAPABILITY CISCO-ENHANCED-SLB-MIB.my CISCO-ENHANCED-SLB-MIB CISCO-ENHANCED-WRED-MIB.my CISCO-ENHANCED-WRED-MIB CISCO-ENH-IPSEC-FLOW-CAPABILITY.my CISCO-ENH-IPSEC-FLOW-CAPABILITY CISCO-ENTITY-ALARM-MIB.my CISCO-ENTITY-ALARM-MIB CISCO-ENTITY-ASSET-CAPABILITY.my CISCO-ENTITY-ASSET-CAPABILITY CISCO-ENTITY-ASSET-MIB.my CISCO-ENTITY-ASSET-MIB CISCO-ENTITY-CAPABILITY.my CISCO-ENTITY-CAPABILITY CISCO-ENTITY-DIAG-CAPABILITY.my CISCO-ENTITY-DIAG-CAPABILITY CISCO-ENTITY-DIAG-MIB.my CISCO-ENTITY-DIAG-MIB CISCO-ENTITY-DIAG-TC-MIB.my CISCO-ENTITY-DIAG-TC-MIB CISCO-ENTITY-DISPLAY-CAPABILITY.my CISCO-ENTITY-DISPLAY-CAPABILITY CISCO-ENTITY-DISPLAY-MIB.my CISCO-ENTITY-DISPLAY-MIB CISCO-ENTITY-EXT-CAPABILITY.my CISCO-ENTITY-EXT-CAPABILITY CISCO-ENTITY-EXT-MIB.my CISCO-ENTITY-EXT-MIB CISCO-ENTITY-FRU-CONTROL-CAPABILITY.my CISCO-ENTITY-FRU-CONTROL-CAPABILITY CISCO-ENTITY-FRU-CONTROL-MIB.my CISCO-ENTITY-FRU-CONTROL-MIB CISCO-ENTITY-PFE-MIB.my CISCO-ENTITY-PFE-MIB CISCO-ENTITY-PROVISIONING-MIB.my CISCO-ENTITY-PROVISIONING-MIB CISCO-ENTITY-REDUNDANCY-MIB.my CISCO-ENTITY-REDUNDANCY-MIB CISCO-ENTITY-REDUNDANCY-TC-MIB.my CISCO-ENTITY-REDUNDANCY-TC-MIB CISCO-ENTITY-SENSOR-CAPABILITY.my CISCO-ENTITY-SENSOR-CAPABILITY CISCO-ENTITY-SENSOR-MIB.my CISCO-ENTITY-SENSOR-MIB CISCO-ENTITY-SENSOR-RFC-CAPABILITY.my CISCO-ENTITY-SENSOR-RFC-CAPABILITY CISCO-ENTITY-VENDORTYPE-OID-MIB.my CISCO-ENTITY-VENDORTYPE-OID-MIB CISCO-ENVMON-CAPABILITY.my CISCO-ENVMON-CAPABILITY CISCO-ENVMON-MIB.my CISCO-ENVMON-MIB CISCO-EPM-NOTIFICATION-MIB.my CISCO-EPM-NOTIFICATION-MIB CISCO-ERR-DISABLE-MIB.my CISCO-ERR-DISABLE-MIB CISCO-ETHER-CFM-CAPABILITY.my CISCO-ETHER-CFM-CAPABILITY CISCO-ETHER-CFM-MIB.my CISCO-ETHER-CFM-MIB CISCO-ETHERLIKE-CAPABILITY.my CISCO-ETHERLIKE-CAPABILITY CISCO-ETHERNET-ACCESS-MIB.my CISCO-ETHERNET-ACCESS-MIB CISCO-EXT-SCSI-MIB.my CISCO-EXT-SCSI-MIB CISCO-FABRIC-C12K-MIB.my CISCO-FABRIC-C12K-MIB CISCO-FABRIC-HFR-MIB-CAPABILITY.my CISCO-FABRIC-HFR-MIB-CAPABILITY CISCO-FABRIC-HFR-MIB.my CISCO-FABRIC-HFR-MIB CISCO-FABRIC-MCAST-APPL-MIB-CAPABILITY.my CISCO-FABRIC-MCAST-APPL-MIB-CAPABILITY CISCO-FABRIC-MCAST-APPL-MIB.my CISCO-FABRIC-MCAST-APPL-MIB CISCO-FABRIC-MCAST-MIB-CAPABILITY.my CISCO-FABRIC-MCAST-MIB-CAPABILITY CISCO-FABRIC-MCAST-MIB.my CISCO-FABRIC-MCAST-MIB CISCO-FCC-MIB.my CISCO-FCC-MIB CISCO-FC-DEVICE-ALIAS-MIB.my CISCO-FC-DEVICE-ALIAS-MIB CISCO-FC-FE-MIB.my CISCO-FC-FE-MIB CISCO-FCIP-MGMT-EXT-MIB.my CISCO-FCIP-MGMT-EXT-MIB CISCO-FCIP-MGMT-MIB.my CISCO-FCIP-MGMT-MIB CISCO-FC-MULTICAST-MIB.my CISCO-FC-MULTICAST-MIB CISCO-FCPING-MIB.my CISCO-FCPING-MIB CISCO-FC-ROUTE-MIB.my CISCO-FC-ROUTE-MIB CISCO-FC-SDV-MIB.my CISCO-FC-SDV-MIB CISCO-FCS-MIB.my CISCO-FCS-MIB CISCO-FC-SPAN-MIB.my CISCO-FC-SPAN-MIB CISCO-FCSP-MIB.my CISCO-FCSP-MIB CISCO-FCTRACEROUTE-MIB.my CISCO-FCTRACEROUTE-MIB CISCO-FDMI-MIB.my CISCO-FDMI-MIB CISCO-FEATURE-CONTROL-MIB.my CISCO-FEATURE-CONTROL-MIB CISCO-FICON-MIB.my CISCO-FICON-MIB CISCO-FILTER-GROUP-MIB.my CISCO-FILTER-GROUP-MIB CISCO-FIPS-STATS-MIB.my CISCO-FIPS-STATS-MIB CISCO-FIREWALL-MIB.my CISCO-FIREWALL-MIB CISCO-FIREWALL-TC.my CISCO-FIREWALL-TC CISCO-FLASH-CAPABILITY.my CISCO-FLASH-CAPABILITY CISCO-FLASH-MIB.my CISCO-FLASH-MIB CISCO-FLEX-LINKS-CAPABILITY.my CISCO-FLEX-LINKS-CAPABILITY CISCO-FLEX-LINKS-MIB.my CISCO-FLEX-LINKS-MIB CISCO-FRAME-RELAY-MIB.my CISCO-FRAME-RELAY-MIB CISCO-FSPF-MIB.my CISCO-FSPF-MIB CISCO-FTP-CLIENT-CAPABILITY.my CISCO-FTP-CLIENT-CAPABILITY CISCO-FTP-CLIENT-MIB.my CISCO-FTP-CLIENT-MIB CISCO-GATEKEEPER-MIB.my CISCO-GATEKEEPER-MIB CISCO-GGSN-CAPABILITY.my CISCO-GGSN-CAPABILITY CISCO-GGSN-EXT-MIB.my CISCO-GGSN-EXT-MIB CISCO-GGSN-MIB.my CISCO-GGSN-MIB CISCO-GGSN-QOS-CAPABILITY.my CISCO-GGSN-QOS-CAPABILITY CISCO-GGSN-QOS-MIB.my CISCO-GGSN-QOS-MIB CISCO-GGSN-SERVICE-AWARE-MIB.my CISCO-GGSN-SERVICE-AWARE-MIB CISCO-GPRS-ACC-PT-CAPABILITY.my CISCO-GPRS-ACC-PT-CAPABILITY CISCO-GPRS-ACC-PT-MIB.my CISCO-GPRS-ACC-PT-MIB CISCO-GPRS-CHARGING-CAPABILITY.my CISCO-GPRS-CHARGING-CAPABILITY CISCO-GPRS-CHARGING-MIB.my CISCO-GPRS-CHARGING-MIB CISCO-GPRS-GTP-CAPABILITY.my CISCO-GPRS-GTP-CAPABILITY CISCO-GPRS-GTP-MIB.my CISCO-GPRS-GTP-MIB CISCO-GSLB-DNS-CAPABILITY.my CISCO-GSLB-DNS-CAPABILITY CISCO-GSLB-DNS-MIB.my CISCO-GSLB-DNS-MIB CISCO-GSLB-HEALTH-MON-CAPABILITY.my CISCO-GSLB-HEALTH-MON-CAPABILITY CISCO-GSLB-HEALTH-MON-MIB.my CISCO-GSLB-HEALTH-MON-MIB CISCO-GSLB-SYSTEM-CAPABILITY.my CISCO-GSLB-SYSTEM-CAPABILITY CISCO-GSLB-SYSTEM-MIB.my CISCO-GSLB-SYSTEM-MIB CISCO-GSLB-TC-MIB.my CISCO-GSLB-TC-MIB CISCO-GTP-CAPABILITY.my CISCO-GTP-CAPABILITY CISCO-GTP-DIRECTOR-MIB.my CISCO-GTP-DIRECTOR-MIB CISCO-GTP-MIB.my CISCO-GTP-MIB CISCO-H323-TC-MIB.my CISCO-H323-TC-MIB CISCO-HC-ALARM-CAPABILITY.my CISCO-HC-ALARM-CAPABILITY CISCO-HC-ALARM-MIB.my CISCO-HC-ALARM-MIB CISCO-HC-RMON-CAPABILITY.my CISCO-HC-RMON-CAPABILITY CISCO-HEALTH-MONITOR-MIB.my CISCO-HEALTH-MONITOR-MIB CISCO-HOST-RESOURCES-CAPABILITY.my CISCO-HOST-RESOURCES-CAPABILITY CISCO-HSRP-CAPABILITY.my CISCO-HSRP-CAPABILITY CISCO-HSRP-EXT-CAPABILITY.my CISCO-HSRP-EXT-CAPABILITY CISCO-HSRP-EXT-MIB.my CISCO-HSRP-EXT-MIB CISCO-HSRP-MIB.my CISCO-HSRP-MIB CISCO-ICSUDSU-MIB.my CISCO-ICSUDSU-MIB CISCO-IDSL-LINE-MIB.my CISCO-IDSL-LINE-MIB CISCO-IEEE8021-PAE-CAPABILITY.my CISCO-IEEE8021-PAE-CAPABILITY CISCO-IEEE8023-LAG-CAPABILITY.my CISCO-IEEE8023-LAG-CAPABILITY CISCO-IETF-ATM2-PVCTRAP-MIB.my CISCO-IETF-ATM2-PVCTRAP-MIB CISCO-IETF-DHCP-SERVER-CAPABILITY.my CISCO-IETF-DHCP-SERVER-CAPABILITY CISCO-IETF-DHCP-SERVER-EXT-CAPABILITY.my CISCO-IETF-DHCP-SERVER-EXT-CAPABILITY CISCO-IETF-DHCP-SERVER-EXT-MIB.my CISCO-IETF-DHCP-SERVER-EXT-MIB CISCO-IETF-DHCP-SERVER-MIB.my CISCO-IETF-DHCP-SERVER-MIB CISCO-IETF-DOT11-QOS-EXT-MIB.my CISCO-IETF-DOT11-QOS-EXT-MIB CISCO-IETF-DOT11-QOS-MIB.my CISCO-IETF-DOT11-QOS-MIB CISCO-IETF-FRR-CAPABILITY.my CISCO-IETF-FRR-CAPABILITY CISCO-IETF-FRR-MIB.my CISCO-IETF-FRR-MIB CISCO-IETF-IP-FORWARD-MIB.my CISCO-IETF-IP-FORWARD-MIB CISCO-IETF-IP-MIB.my CISCO-IETF-IP-MIB CISCO-IETF-IPMROUTE-CAPABILITY.my CISCO-IETF-IPMROUTE-CAPABILITY CISCO-IETF-IPMROUTE-MIB.my CISCO-IETF-IPMROUTE-MIB CISCO-IETF-ISIS-MIB.my CISCO-IETF-ISIS-MIB CISCO-IETF-ISNS-MGMT-MIB.my CISCO-IETF-ISNS-MGMT-MIB CISCO-IETF-MEGACO-MIB.my CISCO-IETF-MEGACO-MIB CISCO-IETF-MPLS-VPN-CAPABILITY.my CISCO-IETF-MPLS-VPN-CAPABILITY CISCO-IETF-MSDP-MIB.my CISCO-IETF-MSDP-MIB CISCO-IETF-NAT-MIB.my CISCO-IETF-NAT-MIB CISCO-IETF-PIM-CAPABILITY.my CISCO-IETF-PIM-CAPABILITY CISCO-IETF-PIM-EXT-CAPABILITY.my CISCO-IETF-PIM-EXT-CAPABILITY CISCO-IETF-PIM-EXT-MIB.my CISCO-IETF-PIM-EXT-MIB CISCO-IETF-PIM-MIB.my CISCO-IETF-PIM-MIB CISCO-IETF-PW-CAPABILITY.my CISCO-IETF-PW-CAPABILITY CISCO-IETF-PW-ENET-CAPABILITY.my CISCO-IETF-PW-ENET-CAPABILITY CISCO-IETF-PW-ENET-MIB.my CISCO-IETF-PW-ENET-MIB CISCO-IETF-PW-FR-MIB.my CISCO-IETF-PW-FR-MIB CISCO-IETF-PW-MIB.my CISCO-IETF-PW-MIB CISCO-IETF-PW-MPLS-CAPABILITY.my CISCO-IETF-PW-MPLS-CAPABILITY CISCO-IETF-PW-MPLS-MIB.my CISCO-IETF-PW-MPLS-MIB CISCO-IETF-PW-TC-MIB.my CISCO-IETF-PW-TC-MIB CISCO-IETF-SCTP-CAPABILITY.my CISCO-IETF-SCTP-CAPABILITY CISCO-IETF-SCTP-EXT-CAPABILITY.my CISCO-IETF-SCTP-EXT-CAPABILITY CISCO-IETF-SCTP-EXT-MIB.my CISCO-IETF-SCTP-EXT-MIB CISCO-IETF-SCTP-MIB.my CISCO-IETF-SCTP-MIB CISCO-IETF-VDSL-LINE-MIB.my CISCO-IETF-VDSL-LINE-MIB CISCO-IETF-VRRP-MIB.my CISCO-IETF-VRRP-MIB CISCO-IF-CALL-SERVICE-MIB.my CISCO-IF-CALL-SERVICE-MIB CISCO-IF-CAPABILITY.my CISCO-IF-CAPABILITY CISCO-IF-EXTENSION-CAPABILITY.my CISCO-IF-EXTENSION-CAPABILITY CISCO-IF-EXTENSION-MIB.my CISCO-IF-EXTENSION-MIB CISCO-IF-LINK-CONFIG-MIB.my CISCO-IF-LINK-CONFIG-MIB CISCO-IF-LOOPBACK-MIB.my CISCO-IF-LOOPBACK-MIB CISCO-IF-THRESHOLD-MIB.my CISCO-IF-THRESHOLD-MIB CISCO-IGMP-FILTER-CAPABILITY.my CISCO-IGMP-FILTER-CAPABILITY CISCO-IGMP-FILTER-MIB.my CISCO-IGMP-FILTER-MIB CISCO-IGMP-SNOOPING-CAPABILITY.my CISCO-IGMP-SNOOPING-CAPABILITY CISCO-IGMP-SNOOPING-MIB.my CISCO-IGMP-SNOOPING-MIB CISCO-IKE-CONF-CAPABILITY.my CISCO-IKE-CONF-CAPABILITY CISCO-IKE-CONFIGURATION-MIB.my CISCO-IKE-CONFIGURATION-MIB CISCO-IKE-FLOW-CAPABILITY.my CISCO-IKE-FLOW-CAPABILITY CISCO-IKE-FLOW-EXT-CAPABILITY.my CISCO-IKE-FLOW-EXT-CAPABILITY CISCO-IKE-FLOW-EXT-MIB.my CISCO-IKE-FLOW-EXT-MIB CISCO-IKE-FLOW-MIB.my CISCO-IKE-FLOW-MIB CISCO-IMA-CAPABILITY.my CISCO-IMA-CAPABILITY CISCO-IMA-EXT-CAPABILITY.my CISCO-IMA-EXT-CAPABILITY CISCO-IMAGE-CAPABILITY.my CISCO-IMAGE-CAPABILITY CISCO-IMAGE-CHECK-MIB.my CISCO-IMAGE-CHECK-MIB CISCO-IMAGE-MIB.my CISCO-IMAGE-MIB CISCO-IMAGE-TC.my CISCO-IMAGE-TC CISCO-IMAGE-UPGRADE-MIB.my CISCO-IMAGE-UPGRADE-MIB CISCO-IMA-MIB.my CISCO-IMA-MIB CISCO-INTERFACETOPN-CAPABILITY.my CISCO-INTERFACETOPN-CAPABILITY CISCO-INTERFACETOPN-EXT-CAPABILITY.my CISCO-INTERFACETOPN-EXT-CAPABILITY CISCO-INTERFACETOPN-EXT-MIB.my CISCO-INTERFACETOPN-EXT-MIB CISCO-IP-CAPABILITY.my CISCO-IP-CAPABILITY CISCO-IP-ENCRYPTION-MIB.my CISCO-IP-ENCRYPTION-MIB CISCO-IP-IF-CAPABILITY.my CISCO-IP-IF-CAPABILITY CISCO-IP-IF-MIB.my CISCO-IP-IF-MIB CISCO-IP-LOCAL-POOL-MIB.my CISCO-IP-LOCAL-POOL-MIB CISCO-IPMCAST-MIB.my CISCO-IPMCAST-MIB CISCO-IPMROUTE-MIB.my CISCO-IPMROUTE-MIB CISCO-IP-NW-DISCOVERY-CAPABILITY.my CISCO-IP-NW-DISCOVERY-CAPABILITY CISCO-IP-NW-DISCOVERY-MIB.my CISCO-IP-NW-DISCOVERY-MIB CISCO-IP-PROTOCOL-FILTER-CAPABILITY.my CISCO-IP-PROTOCOL-FILTER-CAPABILITY CISCO-IP-PROTOCOL-FILTER-MIB.my CISCO-IP-PROTOCOL-FILTER-MIB CISCO-IP-RAN-BACKHAUL-CAPABILITY.my CISCO-IP-RAN-BACKHAUL-CAPABILITY CISCO-IP-RAN-BACKHAUL-MIB.my CISCO-IP-RAN-BACKHAUL-MIB CISCO-IPSEC-FLOW-MONITOR-MIB.my CISCO-IPSEC-FLOW-MONITOR-MIB CISCO-IPSEC-MIB.my CISCO-IPSEC-MIB CISCO-IPSEC-POLICY-MAP-MIB.my CISCO-IPSEC-POLICY-MAP-MIB CISCO-IPSEC-PROV-CAPABILITY.my CISCO-IPSEC-PROV-CAPABILITY CISCO-IPSEC-PROVISIONING-MIB.my CISCO-IPSEC-PROVISIONING-MIB CISCO-IPSEC-SIGNALING-CAPABILITY.my CISCO-IPSEC-SIGNALING-CAPABILITY CISCO-IPSEC-SIGNALING-MIB.my CISCO-IPSEC-SIGNALING-MIB CISCO-IPSEC-TC.my CISCO-IPSEC-TC CISCO-IPSLA-ETHERNET-MIB.my CISCO-IPSLA-ETHERNET-MIB CISCO-IP-STAT-MIB.my CISCO-IP-STAT-MIB CISCO-IP-TAP-CAPABILITY.my CISCO-IP-TAP-CAPABILITY CISCO-IP-TAP-MIB.my CISCO-IP-TAP-MIB CISCO-IP-UPLINK-REDIRECT-MIB.my CISCO-IP-UPLINK-REDIRECT-MIB CISCO-IP-URPF-MIB.my CISCO-IP-URPF-MIB CISCO-IPV6-CAPABILITY.my CISCO-IPV6-CAPABILITY CISCO-IPV6-MLD-CAPABILITY.my CISCO-IPV6-MLD-CAPABILITY CISCO-ISCSI-GW-MIB.my CISCO-ISCSI-GW-MIB CISCO-ISDN-MIB.my CISCO-ISDN-MIB CISCO-ISDNU-IF-MIB.my CISCO-ISDNU-IF-MIB CISCO-ISNS-CLIENT-MIB.my CISCO-ISNS-CLIENT-MIB CISCO-ITP-ACL-CAPABILITY.my CISCO-ITP-ACL-CAPABILITY CISCO-ITP-ACL-MIB.my CISCO-ITP-ACL-MIB CISCO-ITP-ACT-CAPABILITY.my CISCO-ITP-ACT-CAPABILITY CISCO-ITP-ACT-MIB.my CISCO-ITP-ACT-MIB CISCO-ITP-GACT-CAPABILITY.my CISCO-ITP-GACT-CAPABILITY CISCO-ITP-GACT-MIB.my CISCO-ITP-GACT-MIB CISCO-ITP-GRT-CAPABILITY.my CISCO-ITP-GRT-CAPABILITY CISCO-ITP-GRT-MIB.my CISCO-ITP-GRT-MIB CISCO-ITP-GSCCP-CAPABILITY.my CISCO-ITP-GSCCP-CAPABILITY CISCO-ITP-GSCCP-MIB.my CISCO-ITP-GSCCP-MIB CISCO-ITP-GSP2-CAPABILITY.my CISCO-ITP-GSP2-CAPABILITY CISCO-ITP-GSP2-MIB.my CISCO-ITP-GSP2-MIB CISCO-ITP-GSP-CAPABILITY.my CISCO-ITP-GSP-CAPABILITY CISCO-ITP-GSP-MIB.my CISCO-ITP-GSP-MIB CISCO-ITP-MLR-CAPABILITY.my CISCO-ITP-MLR-CAPABILITY CISCO-ITP-MLR-MIB.my CISCO-ITP-MLR-MIB CISCO-ITP-MONITOR-CAPABILITY.my CISCO-ITP-MONITOR-CAPABILITY CISCO-ITP-MONITOR-MIB.my CISCO-ITP-MONITOR-MIB CISCO-ITP-MSU-RATES-CAPABILITY.my CISCO-ITP-MSU-RATES-CAPABILITY CISCO-ITP-MSU-RATES-MIB.my CISCO-ITP-MSU-RATES-MIB CISCO-ITP-RT-CAPABILITY.my CISCO-ITP-RT-CAPABILITY CISCO-ITP-RT-MIB.my CISCO-ITP-RT-MIB CISCO-ITP-SCCP-CAPABILITY.my CISCO-ITP-SCCP-CAPABILITY CISCO-ITP-SCCP-MIB.my CISCO-ITP-SCCP-MIB CISCO-ITP-SP2-CAPABILITY.my CISCO-ITP-SP2-CAPABILITY CISCO-ITP-SP2-MIB.my CISCO-ITP-SP2-MIB CISCO-ITP-SP-CAPABILITY.my CISCO-ITP-SP-CAPABILITY CISCO-ITP-SP-MIB.my CISCO-ITP-SP-MIB CISCO-ITP-TC-MIB.my CISCO-ITP-TC-MIB CISCO-ITP-XUA-CAPABILITY.my CISCO-ITP-XUA-CAPABILITY CISCO-ITP-XUA-MIB.my CISCO-ITP-XUA-MIB CISCO-IVR-CAPABILITY.my CISCO-IVR-CAPABILITY CISCO-IVR-MIB.my CISCO-IVR-MIB CISCO-L2-CONTROL-CAPABILITY.my CISCO-L2-CONTROL-CAPABILITY CISCO-L2-CONTROL-MIB.my CISCO-L2-CONTROL-MIB CISCO-L2-DEV-MONITORING-MIB.my CISCO-L2-DEV-MONITORING-MIB CISCO-L2L3-INTERFACE-CONFIG-CAPABILITY.my CISCO-L2L3-INTERFACE-CONFIG-CAPABILITY CISCO-L2L3-INTERFACE-CONFIG-MIB.my CISCO-L2L3-INTERFACE-CONFIG-MIB CISCO-L2-TUNNEL-CONFIG-CAPABILITY.my CISCO-L2-TUNNEL-CONFIG-CAPABILITY CISCO-L2-TUNNEL-CONFIG-MIB.my CISCO-L2-TUNNEL-CONFIG-MIB CISCO-L4L7MODULE-RESOURCE-LIMIT-CAPABILITY.my CISCO-L4L7MODULE-RESOURCE-LIMIT-CAPABILITY CISCO-L4L7MODULE-RESOURCE-LIMIT-MIB.my CISCO-L4L7MODULE-RESOURCE-LIMIT-MIB CISCO-LAG-CAPABILITY.my CISCO-LAG-CAPABILITY CISCO-LAG-MIB.my CISCO-LAG-MIB CISCO-LATITUDE-MIB.my CISCO-LATITUDE-MIB CISCO-LEC-DATA-VCC-MIB.my CISCO-LEC-DATA-VCC-MIB CISCO-LEC-EXT-MIB.my CISCO-LEC-EXT-MIB CISCO-LECS-MIB.my CISCO-LECS-MIB CISCO-LES-MIB.my CISCO-LES-MIB CISCO-LICENSE-MGMT-MIB.my CISCO-LICENSE-MGMT-MIB CISCO-LICENSE-MGR-CAPABILITY.my CISCO-LICENSE-MGR-CAPABILITY CISCO-LICENSE-MGR-MIB.my CISCO-LICENSE-MGR-MIB CISCO-LICENSE-MIB.my CISCO-LICENSE-MIB CISCO-LINK-ERROR-MONITOR-CAPABILITY.my CISCO-LINK-ERROR-MONITOR-CAPABILITY CISCO-LINK-ERROR-MONITOR-MIB.my CISCO-LINK-ERROR-MONITOR-MIB CISCO-LOCAL-DIRECTOR-MIB.my CISCO-LOCAL-DIRECTOR-MIB CISCO-LRE-CPE-MIB.my CISCO-LRE-CPE-MIB CISCO-LWAPP-AAA-MIB.my CISCO-LWAPP-AAA-MIB CISCO-LWAPP-ACL-MIB.my CISCO-LWAPP-ACL-MIB CISCO-LWAPP-AP-MIB.my CISCO-LWAPP-AP-MIB CISCO-LWAPP-CCX-RM-MIB.my CISCO-LWAPP-CCX-RM-MIB CISCO-LWAPP-CDP-MIB.my CISCO-LWAPP-CDP-MIB CISCO-LWAPP-CLIENT-ROAMING-CAPABILITY.my CISCO-LWAPP-CLIENT-ROAMING-CAPABILITY CISCO-LWAPP-CLIENT-ROAMING-MIB.my CISCO-LWAPP-CLIENT-ROAMING-MIB CISCO-LWAPP-DOT11-CLIENT-CALIB-CAPABILITY.my CISCO-LWAPP-DOT11-CLIENT-CALIB-CAPABILITY CISCO-LWAPP-DOT11-CLIENT-CALIB-MIB.my CISCO-LWAPP-DOT11-CLIENT-CALIB-MIB CISCO-LWAPP-DOT11-CLIENT-CCX-TC-MIB.my CISCO-LWAPP-DOT11-CLIENT-CCX-TC-MIB CISCO-LWAPP-DOT11-CLIENT-MIB.my CISCO-LWAPP-DOT11-CLIENT-MIB CISCO-LWAPP-DOT11-LDAP-MIB.my CISCO-LWAPP-DOT11-LDAP-MIB CISCO-LWAPP-DOT11-MIB.my CISCO-LWAPP-DOT11-MIB CISCO-LWAPP-IDS-MIB.my CISCO-LWAPP-IDS-MIB CISCO-LWAPP-LINKTEST-MIB.my CISCO-LWAPP-LINKTEST-MIB CISCO-LWAPP-LOCAL-AUTH-MIB.my CISCO-LWAPP-LOCAL-AUTH-MIB CISCO-LWAPP-MESH-BATTERY-MIB.my CISCO-LWAPP-MESH-BATTERY-MIB CISCO-LWAPP-MESH-MIB.my CISCO-LWAPP-MESH-MIB CISCO-LWAPP-MESH-STATS-MIB.my CISCO-LWAPP-MESH-STATS-MIB CISCO-LWAPP-MFP-CAPABILITY.my CISCO-LWAPP-MFP-CAPABILITY CISCO-LWAPP-MFP-MIB.my CISCO-LWAPP-MFP-MIB CISCO-LWAPP-MOBILITY-MIB.my CISCO-LWAPP-MOBILITY-MIB CISCO-LWAPP-QOS-CAPABILITY.my CISCO-LWAPP-QOS-CAPABILITY CISCO-LWAPP-QOS-MIB.my CISCO-LWAPP-QOS-MIB CISCO-LWAPP-REAP-MIB.my CISCO-LWAPP-REAP-MIB CISCO-LWAPP-ROGUE-MIB.my CISCO-LWAPP-ROGUE-MIB CISCO-LWAPP-RRM-MIB.my CISCO-LWAPP-RRM-MIB CISCO-LWAPP-SYS-MIB.my CISCO-LWAPP-SYS-MIB CISCO-LWAPP-TC-MIB.my CISCO-LWAPP-TC-MIB CISCO-LWAPP-TSM-CAPABILITY.my CISCO-LWAPP-TSM-CAPABILITY CISCO-LWAPP-TSM-MIB.my CISCO-LWAPP-TSM-MIB CISCO-LWAPP-WEBAUTH-MIB.my CISCO-LWAPP-WEBAUTH-MIB CISCO-LWAPP-WLAN-MIB.my CISCO-LWAPP-WLAN-MIB CISCO-LWAPP-WLAN-SECURITY-MIB.my CISCO-LWAPP-WLAN-SECURITY-MIB CISCO-MAC-NOTIFICATION-CAPABILITY.my CISCO-MAC-NOTIFICATION-CAPABILITY CISCO-MAC-NOTIFICATION-MIB.my CISCO-MAC-NOTIFICATION-MIB CISCO-MAU-CAPABILITY.my CISCO-MAU-CAPABILITY CISCO-MAU-EXT-CAPABILITY.my CISCO-MAU-EXT-CAPABILITY CISCO-MAU-EXT-MIB.my CISCO-MAU-EXT-MIB CISCO-MEDIA-GATEWAY-CAPABILITY.my CISCO-MEDIA-GATEWAY-CAPABILITY CISCO-MEDIA-GATEWAY-MIB.my CISCO-MEDIA-GATEWAY-MIB CISCO-MEGACO-EXT-CAPABILITY.my CISCO-MEGACO-EXT-CAPABILITY CISCO-MEGACO-EXT-MIB.my CISCO-MEGACO-EXT-MIB CISCO-MEMORY-POOL-CAPABILITY.my CISCO-MEMORY-POOL-CAPABILITY CISCO-MEMORY-POOL-MIB.my CISCO-MEMORY-POOL-MIB CISCO-METRO-PHY-MIB.my CISCO-METRO-PHY-MIB CISCO-MGC-CAPABILITY.my CISCO-MGC-CAPABILITY CISCO-MGC-MIB.my CISCO-MGC-MIB CISCO-MGX82XX-ATM-UNI-PORT-MIB.my CISCO-MGX82XX-ATM-UNI-PORT-MIB CISCO-MGX82XX-CARD-FEATURE-MIB.my CISCO-MGX82XX-CARD-FEATURE-MIB CISCO-MGX82XX-DSX1-MIB.my CISCO-MGX82XX-DSX1-MIB CISCO-MGX82XX-DSX3-BERT-MIB.my CISCO-MGX82XX-DSX3-BERT-MIB CISCO-MGX82XX-DSX3-MIB.my CISCO-MGX82XX-DSX3-MIB CISCO-MGX82XX-ENVMON-MIB.my CISCO-MGX82XX-ENVMON-MIB CISCO-MGX82XX-MODULE-RSRC-PART-MIB.my CISCO-MGX82XX-MODULE-RSRC-PART-MIB CISCO-MGX82XX-PXM-CLOCK-MIB.my CISCO-MGX82XX-PXM-CLOCK-MIB CISCO-MGX82XX-RPM-CONN-MIB.my CISCO-MGX82XX-RPM-CONN-MIB CISCO-MGX82XX-RPM-RSRC-PART-MIB.my CISCO-MGX82XX-RPM-RSRC-PART-MIB CISCO-MGX82XX-RPM-SUBIF-MIB.my CISCO-MGX82XX-RPM-SUBIF-MIB CISCO-MGX82XX-VIRTUAL-PORT-MIB.my CISCO-MGX82XX-VIRTUAL-PORT-MIB CISCO-MGX8800-IF-MAPPING-CAPABILITY.my CISCO-MGX8800-IF-MAPPING-CAPABILITY CISCO-MGX8800-IF-MAPPING-MIB.my CISCO-MGX8800-IF-MAPPING-MIB CISCO-MIP-CAPABILITY.my CISCO-MIP-CAPABILITY CISCO-MMAIL-DIAL-CONTROL-MIB.my CISCO-MMAIL-DIAL-CONTROL-MIB CISCO-MOBILE-IP-CAPABILITY.my CISCO-MOBILE-IP-CAPABILITY CISCO-MOBILE-IP-MIB.my CISCO-MOBILE-IP-MIB CISCO-MODEM-MGMT-MIB.my CISCO-MODEM-MGMT-MIB CISCO-MODULE-AUTO-SHUTDOWN-CAPABILITY.my CISCO-MODULE-AUTO-SHUTDOWN-CAPABILITY CISCO-MODULE-AUTO-SHUTDOWN-MIB.my CISCO-MODULE-AUTO-SHUTDOWN-MIB CISCO-MODULE-VIRTUALIZATION-CAPABILITY.my CISCO-MODULE-VIRTUALIZATION-CAPABILITY CISCO-MODULE-VIRTUALIZATION-MIB.my CISCO-MODULE-VIRTUALIZATION-MIB CISCO-MVPN-MIB.my CISCO-MVPN-MIB CISCO-NAC-NAD-CAPABILITY.my CISCO-NAC-NAD-CAPABILITY CISCO-NAC-NAD-MIB.my CISCO-NAC-NAD-MIB CISCO-NAC-TC-MIB.my CISCO-NAC-TC-MIB CISCO-NAT-EXT-MIB.my CISCO-NAT-EXT-MIB CISCO-NBAR-PROTOCOL-DISCOVERY-MIB.my CISCO-NBAR-PROTOCOL-DISCOVERY-MIB CISCO-NDE-CAPABILITY.my CISCO-NDE-CAPABILITY CISCO-NDE-MIB.my CISCO-NDE-MIB CISCO-NETFLOW-CAPABILITY.my CISCO-NETFLOW-CAPABILITY CISCO-NETFLOW-MIB.my CISCO-NETFLOW-MIB CISCO-NETINT-CAPABILITY.my CISCO-NETINT-CAPABILITY CISCO-NETINT-MIB.my CISCO-NETINT-MIB CISCO-NETWORK-REGISTRAR-MIB.my CISCO-NETWORK-REGISTRAR-MIB CISCO-NMS-APPL-HEALTH-MIB.my CISCO-NMS-APPL-HEALTH-MIB CISCO-NOTIFICATION-LOG-CAPABILITY.my CISCO-NOTIFICATION-LOG-CAPABILITY CISCO-NS-MIB.my CISCO-NS-MIB CISCO-NTP-CAPABILITY.my CISCO-NTP-CAPABILITY CISCO-NTP-MIB.my CISCO-NTP-MIB CISCO-OAM-MIB.my CISCO-OAM-MIB CISCO-OPTICAL-IF-CROSS-CONNECT-MIB.my CISCO-OPTICAL-IF-CROSS-CONNECT-MIB CISCO-OPTICAL-IF-EXTN-MIB.my CISCO-OPTICAL-IF-EXTN-MIB CISCO-OPTICAL-MONITOR-CAPABILITY.my CISCO-OPTICAL-MONITOR-CAPABILITY CISCO-OPTICAL-MONITORING-MIB.my CISCO-OPTICAL-MONITORING-MIB CISCO-OPTICAL-MONITOR-MIB.my CISCO-OPTICAL-MONITOR-MIB CISCO-OPTICAL-PATCH-MIB.my CISCO-OPTICAL-PATCH-MIB CISCO-OSCP-MIB.my CISCO-OSCP-MIB CISCO-OSPF-CAPABILITY.my CISCO-OSPF-CAPABILITY CISCO-OSPF-MIB.my CISCO-OSPF-MIB CISCO-OSPF-TRAP-CAPABILITY.my CISCO-OSPF-TRAP-CAPABILITY CISCO-OSPF-TRAP-MIB.my CISCO-OSPF-TRAP-MIB CISCO-OTN-IF-CAPABILITY.my CISCO-OTN-IF-CAPABILITY CISCO-OTN-IF-MIB.my CISCO-OTN-IF-MIB CISCO-OUTAGE-MONITOR-MIB.my CISCO-OUTAGE-MONITOR-MIB CISCO-PACKET-CAPTURE-CAPABILITY.my CISCO-PACKET-CAPTURE-CAPABILITY CISCO-PACKET-CAPTURE-MIB.my CISCO-PACKET-CAPTURE-MIB CISCO-PAE-CAPABILITY.my CISCO-PAE-CAPABILITY CISCO-PAE-MIB.my CISCO-PAE-MIB CISCO-PAGP-MIB.my CISCO-PAGP-MIB CISCO-P-BRIDGE-CAPABILITY.my CISCO-P-BRIDGE-CAPABILITY CISCO-PIM-MIB.my CISCO-PIM-MIB CISCO-PING-CAPABILITY.my CISCO-PING-CAPABILITY CISCO-PING-MIB.my CISCO-PING-MIB CISCO-PKI-PARTICIPATION-MIB.my CISCO-PKI-PARTICIPATION-MIB CISCO-PNNI-CAPABILITY.my CISCO-PNNI-CAPABILITY CISCO-PNNI-MIB.my CISCO-PNNI-MIB CISCO-POE-PD-MIB.my CISCO-POE-PD-MIB CISCO-POLICY-GROUP-CAPABILITY.my CISCO-POLICY-GROUP-CAPABILITY CISCO-POLICY-GROUP-MIB.my CISCO-POLICY-GROUP-MIB CISCO-POP-MGMT-CAPABILITY.my CISCO-POP-MGMT-CAPABILITY CISCO-POP-MGMT-MIB.my CISCO-POP-MGMT-MIB CISCO-PORT-CHANNEL-MIB.my CISCO-PORT-CHANNEL-MIB CISCO-PORT-QOS-MIB.my CISCO-PORT-QOS-MIB CISCO-PORT-SECURITY-CAPABILITY.my CISCO-PORT-SECURITY-CAPABILITY CISCO-PORT-SECURITY-MIB.my CISCO-PORT-SECURITY-MIB CISCO-PORT-STORM-CONTROL-CAPABILITY.my CISCO-PORT-STORM-CONTROL-CAPABILITY CISCO-PORT-STORM-CONTROL-MIB.my CISCO-PORT-STORM-CONTROL-MIB CISCO-PORT-TRACK-MIB.my CISCO-PORT-TRACK-MIB CISCO-POWER-ETHERNET-CAPABILITY.my CISCO-POWER-ETHERNET-CAPABILITY CISCO-POWER-ETHERNET-EXT-CAPABILITY.my CISCO-POWER-ETHERNET-EXT-CAPABILITY CISCO-POWER-ETHERNET-EXT-MIB.my CISCO-POWER-ETHERNET-EXT-MIB CISCO-PPPOE-MIB.my CISCO-PPPOE-MIB CISCO-PREFERRED-PATH-MIB.my CISCO-PREFERRED-PATH-MIB CISCO-PRIVATE-VLAN-CAPABILITY.my CISCO-PRIVATE-VLAN-CAPABILITY CISCO-PRIVATE-VLAN-MIB.my CISCO-PRIVATE-VLAN-MIB CISCO-PROCESS-CAPABILITY.my CISCO-PROCESS-CAPABILITY CISCO-PROCESS-MIB.my CISCO-PROCESS-MIB CISCO-PRODUCTS-MIB.my CISCO-PRODUCTS-MIB CISCO-PROP-ATM-IF-MIB.my CISCO-PROP-ATM-IF-MIB CISCO-PROXY-CONTROL-MIB.my CISCO-PROXY-CONTROL-MIB CISCO-PSA-MICROCODE-MIB.my CISCO-PSA-MICROCODE-MIB CISCO-PSD-CLIENT-MIB.my CISCO-PSD-CLIENT-MIB CISCO-PSM-MIB-CAPABILITY.my CISCO-PSM-MIB-CAPABILITY CISCO-PSM-MIB.my CISCO-PSM-MIB CISCO-PTOPO-EXTN-MIB.my CISCO-PTOPO-EXTN-MIB CISCO-Q-BRIDGE-CAPABILITY.my CISCO-Q-BRIDGE-CAPABILITY CISCO-QINQ-VLAN-MIB.my CISCO-QINQ-VLAN-MIB CISCO-QLLC01-MIB.my CISCO-QLLC01-MIB CISCO-QOS-PIB-CAPABILITY.my CISCO-QOS-PIB-CAPABILITY CISCO-QOS-PIB-MIB.my CISCO-QOS-PIB-MIB CISCO-QOS-POLICY-CONFIG-CAPABILITY.my CISCO-QOS-POLICY-CONFIG-CAPABILITY CISCO-QOS-POLICY-CONFIG-MIB.my CISCO-QOS-POLICY-CONFIG-MIB CISCO-QOS-TC-MIB.my CISCO-QOS-TC-MIB CISCO-QUEUE-MIB.my CISCO-QUEUE-MIB CISCO-RADIUS-ACC-CLIENT-CAPABILITY.my CISCO-RADIUS-ACC-CLIENT-CAPABILITY CISCO-RADIUS-AUTH-CLIENT-CAPABILITY.my CISCO-RADIUS-AUTH-CLIENT-CAPABILITY CISCO-RADIUS-CAPABILITY.my CISCO-RADIUS-CAPABILITY CISCO-RADIUS-MIB.my CISCO-RADIUS-MIB CISCO-REPEATER-MIB.my CISCO-REPEATER-MIB CISCO-RESILIENT-ETHERNET-PROTOCOL-MIB.my CISCO-RESILIENT-ETHERNET-PROTOCOL-MIB CISCO-RFC1213-CAPABILITY.my CISCO-RFC1213-CAPABILITY CISCO-RFC1406-CAPABILITY.my CISCO-RFC1406-CAPABILITY CISCO-RF-CAPABILITY.my CISCO-RF-CAPABILITY CISCO-RF-MIB.my CISCO-RF-MIB CISCO-RF-SUPPLEMENTAL-MIB.my CISCO-RF-SUPPLEMENTAL-MIB CISCO-RHINO-MIB.my CISCO-RHINO-MIB CISCO-RMON2-CAPABILITY.my CISCO-RMON2-CAPABILITY CISCO-RMON-CAPABILITY.my CISCO-RMON-CAPABILITY CISCO-RMON-CONFIG-CAPABILITY.my CISCO-RMON-CONFIG-CAPABILITY CISCO-RMON-CONFIG-MIB.my CISCO-RMON-CONFIG-MIB CISCO-RPMS-MIB.my CISCO-RPMS-MIB CISCO-RS-232-CAPABILITY.my CISCO-RS-232-CAPABILITY CISCO-RSCN-MIB.my CISCO-RSCN-MIB CISCO-RSRB-MIB.my CISCO-RSRB-MIB CISCO-RTTMON-CAPABILITY.my CISCO-RTTMON-CAPABILITY CISCO-RTTMON-ICMP-MIB.my CISCO-RTTMON-ICMP-MIB CISCO-RTTMON-MIB.my CISCO-RTTMON-MIB CISCO-RTTMON-RTP-MIB.my CISCO-RTTMON-RTP-MIB CISCO-RTTMON-TC-MIB.my CISCO-RTTMON-TC-MIB CISCO-SAA-APM-MIB.my CISCO-SAA-APM-MIB CISCO-SANTAP-MIB.my CISCO-SANTAP-MIB CISCO-SCSI-FLOW-MIB.my CISCO-SCSI-FLOW-MIB CISCO-SCSI-MIB.my CISCO-SCSI-MIB CISCO-SCTP-CAPABILITY.my CISCO-SCTP-CAPABILITY CISCO-SCTP-MIB.my CISCO-SCTP-MIB CISCO-SDLLC-MIB.my CISCO-SDLLC-MIB CISCO-SDSL-LINE-MIB.my CISCO-SDSL-LINE-MIB CISCO-SECURE-SHELL-CAPABILITY.my CISCO-SECURE-SHELL-CAPABILITY CISCO-SECURE-SHELL-MIB.my CISCO-SECURE-SHELL-MIB CISCO-SIBU-FLASH-MIB.my CISCO-SIBU-FLASH-MIB CISCO-SIBU-MANAGERS-MIB.my CISCO-SIBU-MANAGERS-MIB CISCO-SIBU-STACKABLE-DUAL-SPEED-HUB-MIB.my CISCO-SIBU-STACKABLE-DUAL-SPEED-HUB-MIB CISCO-SIP-UA-CAPABILITY.my CISCO-SIP-UA-CAPABILITY CISCO-SIP-UA-MIB.my CISCO-SIP-UA-MIB CISCO-SLB-CAPABILITY.my CISCO-SLB-CAPABILITY CISCO-SLB-EXT-CAPABILITY.my CISCO-SLB-EXT-CAPABILITY CISCO-SLB-EXT-MIB.my CISCO-SLB-EXT-MIB CISCO-SLB-HEALTH-MON-MIB.my CISCO-SLB-HEALTH-MON-MIB CISCO-SLB-MIB.my CISCO-SLB-MIB CISCO-SM-FILE-DOWNLOAD-MIB.my CISCO-SM-FILE-DOWNLOAD-MIB CISCO-SMI.my CISCO-SMI CISCO-SMON-CAPABILITY.my CISCO-SMON-CAPABILITY CISCO-SNA-LLC-MIB.my CISCO-SNA-LLC-MIB CISCO-SNAPSHOT-MIB.my CISCO-SNAPSHOT-MIB CISCO-SNMP-COMMUNITY-CAPABILITY.my CISCO-SNMP-COMMUNITY-CAPABILITY CISCO-SNMP-FRAMEWORK-CAPABILITY.my CISCO-SNMP-FRAMEWORK-CAPABILITY CISCO-SNMP-MPD-CAPABILITY.my CISCO-SNMP-MPD-CAPABILITY CISCO-SNMP-NOTIFICATION-CAPABILITY.my CISCO-SNMP-NOTIFICATION-CAPABILITY CISCO-SNMP-NOTIFICATION-EXT-MIB.my CISCO-SNMP-NOTIFICATION-EXT-MIB CISCO-SNMP-TARGET-CAPABILITY.my CISCO-SNMP-TARGET-CAPABILITY CISCO-SNMP-TARGET-EXT-MIB.my CISCO-SNMP-TARGET-EXT-MIB CISCO-SNMP-USM-CAPABILITY.my CISCO-SNMP-USM-CAPABILITY CISCO-SNMP-USM-OIDS-MIB.my CISCO-SNMP-USM-OIDS-MIB CISCO-SNMPv2-CAPABILITY.my CISCO-SNMPv2-CAPABILITY CISCO-SNMP-VACM-CAPABILITY.my CISCO-SNMP-VACM-CAPABILITY CISCO-SNMP-VACM-EXT-MIB.my CISCO-SNMP-VACM-EXT-MIB CISCO-SONET-CAPABILITY.my CISCO-SONET-CAPABILITY CISCO-SONET-EXT-CAPABILITY.my CISCO-SONET-EXT-CAPABILITY CISCO-SONET-MIB.my CISCO-SONET-MIB CISCO-SP-CAPABILITY.my CISCO-SP-CAPABILITY CISCO-SP-MIB.my CISCO-SP-MIB CISCO-SRP-MIB.my CISCO-SRP-MIB CISCO-SRST-MIB.my CISCO-SRST-MIB CISCO-SSG-MIB.my CISCO-SSG-MIB CISCO-SSL-PROXY-CAPABILITY.my CISCO-SSL-PROXY-CAPABILITY CISCO-SSL-PROXY-MIB.my CISCO-SSL-PROXY-MIB CISCO-SSM-PROV-MIB.my CISCO-SSM-PROV-MIB CISCO-STACK-CAPABILITY.my CISCO-STACK-CAPABILITY CISCO-STACKMAKER-MIB.my CISCO-STACKMAKER-MIB CISCO-STACK-MIB.my CISCO-STACK-MIB CISCO-STACKWISE-MIB.my CISCO-STACKWISE-MIB CISCO-STP-EXTENSIONS-CAPABILITY.my CISCO-STP-EXTENSIONS-CAPABILITY CISCO-STP-EXTENSIONS-MIB.my CISCO-STP-EXTENSIONS-MIB CISCO-ST-TC.my CISCO-ST-TC CISCO-STUN-MIB.my CISCO-STUN-MIB CISCO-SVC-INTERFACE-MIB.my CISCO-SVC-INTERFACE-MIB CISCO-SVI-AUTOSTATE-CAPABILITY.my CISCO-SVI-AUTOSTATE-CAPABILITY CISCO-SVI-AUTOSTATE-MIB.my CISCO-SVI-AUTOSTATE-MIB CISCO-SWITCH-CGMP-MIB.my CISCO-SWITCH-CGMP-MIB CISCO-SWITCH-ENGINE-CAPABILITY.my CISCO-SWITCH-ENGINE-CAPABILITY CISCO-SWITCH-ENGINE-MIB.my CISCO-SWITCH-ENGINE-MIB CISCO-SWITCH-MULTICAST-CAPABILITY.my CISCO-SWITCH-MULTICAST-CAPABILITY CISCO-SWITCH-MULTICAST-MIB.my CISCO-SWITCH-MULTICAST-MIB CISCO-SWITCH-QOS-CAPABILITY.my CISCO-SWITCH-QOS-CAPABILITY CISCO-SWITCH-QOS-MIB.my CISCO-SWITCH-QOS-MIB CISCO-SWITCH-USAGE-MIB.my CISCO-SWITCH-USAGE-MIB CISCO-SYSAPPL-CAPABILITY.my CISCO-SYSAPPL-CAPABILITY CISCO-SYS-INFO-LOG-CAPABILITY.my CISCO-SYS-INFO-LOG-CAPABILITY CISCO-SYS-INFO-LOG-MIB.myi CISCO-SYS-INFO-LOG-MIB CISCO-SYSLOG-CAPABILITY.my CISCO-SYSLOG-CAPABILITY CISCO-SYSLOG-EVENT-EXT-MIB.my CISCO-SYSLOG-EVENT-EXT-MIB CISCO-SYSLOG-EXT-CAPABILITY.my CISCO-SYSLOG-EXT-CAPABILITY CISCO-SYSLOG-EXT-MIB.my CISCO-SYSLOG-EXT-MIB CISCO-SYSLOG-MIB.my CISCO-SYSLOG-MIB CISCO-SYSTEM-CAPABILITY.my CISCO-SYSTEM-CAPABILITY CISCO-SYSTEM-EXT-MIB.my CISCO-SYSTEM-EXT-MIB CISCO-SYSTEM-MIB.my CISCO-SYSTEM-MIB CISCO-TAP2-CAPABILITY.my CISCO-TAP2-CAPABILITY CISCO-TAP2-MIB.my CISCO-TAP2-MIB CISCO-TAP-MIB.my CISCO-TAP-MIB CISCO-TBRIDGE-DEV-IF-MIB.my CISCO-TBRIDGE-DEV-IF-MIB CISCO-TC.my CISCO-TC CISCO-TC-NO-U32.my CISCO-TC-NO-U32 CISCO-TCP-CAPABILITY.my CISCO-TCP-CAPABILITY CISCO-TCP-MIB.my CISCO-TCP-MIB CISCO-TCPOFFLOAD-MIB.my CISCO-TCPOFFLOAD-MIB CISCO-TCP-STD-CAPABILITY.my CISCO-TCP-STD-CAPABILITY CISCO-TN3270SERVER-MIB.my CISCO-TN3270SERVER-MIB CISCO-TPC-MIB.my CISCO-TPC-MIB CISCO-TRANSACTION-CONNECTION-MIB.my CISCO-TRANSACTION-CONNECTION-MIB CISCO-UDLDP-CAPABILITY.my CISCO-UDLDP-CAPABILITY CISCO-UDLDP-MIB.my CISCO-UDLDP-MIB CISCO-UDP-STD-CAPABILITY.my CISCO-UDP-STD-CAPABILITY CISCO-UNIFIED-FIREWALL-MIB.my CISCO-UNIFIED-FIREWALL-MIB CISCO-UNITY-EXPRESS-MIB.my CISCO-UNITY-EXPRESS-MIB CISCO-USER-CONNECTION-TAP-MIB.my CISCO-USER-CONNECTION-TAP-MIB CISCO-VINES-MIB.my CISCO-VINES-MIB CISCO-VIRTUAL-NW-IF-MIB.my CISCO-VIRTUAL-NW-IF-MIB CISCO-VIRTUAL-SWITCH-CAPABILITY.my CISCO-VIRTUAL-SWITCH-CAPABILITY CISCO-VIRTUAL-SWITCH-MIB.my CISCO-VIRTUAL-SWITCH-MIB CISCO-VISM-ATM-TRUNK-MIB.my CISCO-VISM-ATM-TRUNK-MIB CISCO-VISM-CAC-MIB.my CISCO-VISM-CAC-MIB CISCO-VISM-CAS-MIB.my CISCO-VISM-CAS-MIB CISCO-VISM-CODEC-MIB.my CISCO-VISM-CODEC-MIB CISCO-VISM-CONN-CAPABILITY.my CISCO-VISM-CONN-CAPABILITY CISCO-VISM-CONN-MIB.my CISCO-VISM-CONN-MIB CISCO-VISM-CONN-STAT-MIB.my CISCO-VISM-CONN-STAT-MIB CISCO-VISM-DSX0-MIB.my CISCO-VISM-DSX0-MIB CISCO-VISM-DSX1-CAPABILITY.my CISCO-VISM-DSX1-CAPABILITY CISCO-VISM-DSX1-MIB.my CISCO-VISM-DSX1-MIB CISCO-VISM-HDLC-MIB.my CISCO-VISM-HDLC-MIB CISCO-VISM-MODULE-CAPABILITY.my CISCO-VISM-MODULE-CAPABILITY CISCO-VISM-MODULE-MIB.my CISCO-VISM-MODULE-MIB CISCO-VISM-PORT-MIB.my CISCO-VISM-PORT-MIB CISCO-VISM-RSRC-PART-MIB.my CISCO-VISM-RSRC-PART-MIB CISCO-VISM-SESSION-CAPABILITY.my CISCO-VISM-SESSION-CAPABILITY CISCO-VISM-SESSION-MIB.my CISCO-VISM-SESSION-MIB CISCO-VISM-SVC-MIB.my CISCO-VISM-SVC-MIB CISCO-VISM-TRAPS-MIB.my CISCO-VISM-TRAPS-MIB CISCO-VISM-XGCP-EXT.my CISCO-VISM-XGCP-EXT CISCO-VLAN-BRIDGE-MIB.my CISCO-VLAN-BRIDGING-MIB CISCO-VLAN-BRIDGING-CAPABILITY.my CISCO-VLAN-BRIDGING-CAPABILITY CISCO-VLAN-BRIDGING-MIB.my CISCO-VLAN-BRIDGING-MIB CISCO-VLAN-IFTABLE-RELATIONSHIP-CAPABILITY.my CISCO-VLAN-IFTABLE-RELATIONSHIP-CAPABILITY CISCO-VLAN-IFTABLE-RELATIONSHIP-MIB.my CISCO-VLAN-IFTABLE-RELATIONSHIP-MIB CISCO-VLAN-MEMBERSHIP-CAPABILITY.my CISCO-VLAN-MEMBERSHIP-CAPABILITY CISCO-VLAN-MEMBERSHIP-MIB.my CISCO-VLAN-MEMBERSHIP-MIB CISCO-VLAN-TRANSLATION-CAPABILITY.my CISCO-VLAN-TRANSLATION-CAPABILITY CISCO-VLAN-TRANSLATION-MIB.my CISCO-VLAN-TRANSLATION-MIB CISCO-VMPS-CAPABILITY.my CISCO-VMPS-CAPABILITY CISCO-VMPS-MIB.my CISCO-VMPS-MIB CISCO-VOA-MIB.my CISCO-VOA-MIB CISCO-VOICE-AALX-PROFILE-CAPABILITY.my CISCO-VOICE-AALX-PROFILE-CAPABILITY CISCO-VOICE-AALX-PROFILE-MIB.my CISCO-VOICE-AALX-PROFILE-MIB CISCO-VOICE-ANALOG-IF-MIB.my CISCO-VOICE-ANALOG-IF-MIB CISCO-VOICE-APPLICATIONS-OID-MIB.my CISCO-VOICE-APPLICATIONS-OID-MIB CISCO-VOICE-APPS-MIB.my CISCO-VOICE-APPS-MIB CISCO-VOICE-ATM-DIAL-CONTROL-MIB.my CISCO-VOICE-ATM-DIAL-CONTROL-MIB CISCO-VOICE-CAS-MODULE-CAPABILITY.my CISCO-VOICE-CAS-MODULE-CAPABILITY CISCO-VOICE-CAS-MODULE-MIB.my CISCO-VOICE-CAS-MODULE-MIB CISCO-VOICE-COMMON-DIAL-CONTROL-MIB.my CISCO-VOICE-COMMON-DIAL-CONTROL-MIB CISCO-VOICE-CONNECTIVITY-MIB.my CISCO-VOICE-CONNECTIVITY-MIB CISCO-VOICE-DIAL-CONTROL-MIB.my CISCO-VOICE-DIAL-CONTROL-MIB CISCO-VOICE-DNIS-MIB.my CISCO-VOICE-DNIS-MIB CISCO-VOICE-ENABLED-LINK-MIB.my CISCO-VOICE-ENABLED-LINK-MIB CISCO-VOICE-FR-DIAL-CONTROL-MIB.my CISCO-VOICE-FR-DIAL-CONTROL-MIB CISCO-VOICE-HDLC-DIAL-CONTROL-MIB.my CISCO-VOICE-HDLC-DIAL-CONTROL-MIB CISCO-VOICE-IF-MIB.my CISCO-VOICE-IF-MIB CISCO-VOICE-TONE-CADENCE-CAPABILITY.my CISCO-VOICE-TONE-CADENCE-CAPABILITY CISCO-VOICE-TONE-CADENCE-MIB.my CISCO-VOICE-TONE-CADENCE-MIB CISCO-VPDN-MGMT-EXT-MIB.my CISCO-VPDN-MGMT-EXT-MIB CISCO-VPDN-MGMT-MIB.my CISCO-VPDN-MGMT-MIB CISCO-VSAN-MIB.my CISCO-VSAN-MIB CISCO-VSI-CONTROLLER-CAPABILITY.my CISCO-VSI-CONTROLLER-CAPABILITY CISCO-VSI-CONTROLLER-MIB.my CISCO-VSI-CONTROLLER-MIB CISCO-VSIMASTER-MIB.my CISCO-VSI-MASTER-MIB CISCO-VTP-CAPABILITY.my CISCO-VTP-CAPABILITY CISCO-VTP-MIB.my CISCO-VTP-MIB CISCO-WAN-AAL2-PROFILES-MIB.my CISCO-WAN-AAL2-PROFILES-MIB CISCO-WAN-ANNOUNCEMENT-MIB.my CISCO-WAN-ANNOUNCEMENT-MIB CISCO-WAN-ATM-CONN-CAPABILITY.my CISCO-WAN-ATM-CONN-CAPABILITY CISCO-WAN-ATM-CONN-MIB.my CISCO-WAN-ATM-CONN-MIB CISCO-WAN-ATM-CONN-STAT-CAPABILITY.my CISCO-WAN-ATM-CONN-STAT-CAPABILITY CISCO-WAN-ATM-CONN-STAT-MIB.my CISCO-WAN-ATM-CONN-STAT-MIB CISCO-WAN-ATM-COSB-MIB.my CISCO-WAN-ATM-COSB-MIB CISCO-WAN-ATM-CUG-MIB.my CISCO-WAN-ATM-CUG-MIB CISCO-WAN-ATM-PARTY-MIB.my CISCO-WAN-ATM-PARTY-MIB CISCO-WAN-ATM-PREF-ROUTE-MIB.my CISCO-WAN-ATM-PREF-ROUTE-MIB CISCO-WAN-BBIF-ATM-CONN-MIB.my CISCO-WAN-BBIF-ATM-CONN-MIB CISCO-WAN-BBIF-ATM-CONN-STAT-MIB.my CISCO-WAN-BBIF-ATM-CONN-STAT-MIB CISCO-WAN-BBIF-ILMI-MIB.my CISCO-WAN-BBIF-ILMI-MIB CISCO-WAN-BBIF-PORT-MIB.my CISCO-WAN-BBIF-PORT-MIB CISCO-WAN-CES-CONN-MIB.my CISCO-WAN-CES-CONN-MIB CISCO-WAN-CES-CONN-STAT-MIB.my CISCO-WAN-CES-CONN-STAT-MIB CISCO-WAN-CES-PORT-MIB.my CISCO-WAN-CES-PORT-MIB CISCO-WAN-CES-RSRC-PART-MIB.my CISCO-WAN-CES-RSRC-PART-MIB CISCO-WAN-CODEC-GEN-PARM-MIB.my CISCO-WAN-CODEC-GEN-PARM-MIB CISCO-WAN-FEEDER-MIB.my CISCO-WAN-FEEDER-MIB CISCO-WAN-FR-CONN-MIB.my CISCO-WAN-FR-CONN-MIB CISCO-WAN-FR-CONN-STAT-MIB.my CISCO-WAN-FR-CONN-STAT-MIB CISCO-WAN-FR-PORT-MIB.my CISCO-WAN-FR-PORT-MIB CISCO-WAN-FR-RSRC-PART-MIB.my CISCO-WAN-FR-RSRC-PART-MIB CISCO-WAN-FR-SIGNALING-MIB.my CISCO-WAN-FR-SIGNALING-MIB CISCO-WAN-FR-X21-MIB.my CISCO-WAN-FR-X21-MIB CISCO-WAN-LAPD-TRUNK-MIB.my CISCO-WAN-LAPD-TRUNK-MIB CISCO-WAN-MGC-REDUN-MIB.my CISCO-WAN-MGC-REDUN-MIB CISCO-WAN-MG-MIB.my CISCO-WAN-MG-MIB CISCO-WAN-MODULE-CAPABILITY.my CISCO-WAN-MODULE-CAPABILITY CISCO-WAN-MODULE-MIB.my CISCO-WAN-MODULE-MIB CISCO-WAN-NCDP-CAPABILITY.my CISCO-WAN-NCDP-CAPABILITY CISCO-WAN-NCDP-MIB.my CISCO-WAN-NCDP-MIB CISCO-WAN-PAR-MIB.my CISCO-WAN-PAR-MIB CISCO-WAN-PERSISTENT-XGCP-EVENTS-MIB.my CISCO-WAN-PERSISTENT-XGCP-EVENTS-MIB CISCO-WAN-RPM-CONN-EXT-MIB.my CISCO-WAN-RPM-CONN-EXT-MIB CISCO-WAN-RSRC-PART-CAPABILITY.my CISCO-WAN-RSRC-PART-CAPABILITY CISCO-WAN-RSRC-PART-MIB.my CISCO-WAN-RSRC-PART-MIB CISCO-WAN-RTP-CONN-MIB.my CISCO-WAN-RTP-CONN-MIB CISCO-WAN-SCT-MGMT-MIB.my CISCO-WAN-SCT-MGMT-MIB CISCOWAN-SMI.my CISCOWAN-SMI CISCO-WAN-SONET-MIB.my CISCO-WAN-SONET-MIB CISCO-WAN-SRCP-MIB.my CISCO-WAN-SRCP-MIB CISCO-WAN-SRM-BERT-MIB.my CISCO-WAN-SRM-BERT-MIB CISCO-WAN-SRM-MIB.my CISCO-WAN-SRM-MIB CISCO-WAN-SVC-MIB.my CISCO-WAN-SVC-MIB CISCO-WAN-T38-FAXRELAY-MIB.my CISCO-WAN-T38-FAXRELAY-MIB CISCO-WAN-TOPOLOGY-CAPABILITY.my CISCO-WAN-TOPOLOGY-CAPABILITY CISCO-WAN-TOPOLOGY-MIB.my CISCO-WAN-TOPOLOGY-MIB CISCO-WAN-TRAP-VARS-MIB.my CISCO-WAN-TRAP-VARS-MIB CISCO-WAN-VISM-TONE-PLAN-MIB.my CISCO-WAN-VISM-TONE-PLAN-MIB CISCO-WDS-IDS-CAPABILITY.my CISCO-WDS-IDS-CAPABILITY CISCO-WDS-IDS-MIB.my CISCO-WDS-IDS-MIB CISCO-WDS-INFO-MIB.my CISCO-WDS-INFO-MIB CISCO-WIRELESS-DOCS-EXT-MIB.my CISCO-WIRELESS-DOCS-EXT-MIB CISCO-WIRELESS-DOCS-IF-MIB.my CISCO-WIRELESS-DOCS-IF-MIB CISCO-WIRELESS-EXP-MIB.my CISCO-WIRELESS-EXP-MIB CISCO-WIRELESS-IF-MIB.my CISCO-WIRELESS-IF-MIB CISCO-WIRELESS-P2MP-LINK-METRICS-MIB.my CISCO-WIRELESS-P2MP-LINK-METRICS-MIB CISCO-WIRELESS-P2MP-PHY-MIB.my CISCO-WIRELESS-P2MP-PHY-MIB CISCO-WIRELESS-P2MP-RF-METRICS-MIB.my CISCO-WIRELESS-P2MP-RF-METRICS-MIB CISCO-WIRELESS-P2P-BPI-MIB.my CISCO-WIRELESS-P2P-BPI-MIB CISCO-WIRELESS-TC-MIB.my CISCO-WIRELESS-TC-MIB CISCO-WLAN-MAN-MIB.my CISCO-WLAN-MAN-MIB CISCO-WLAN-VLAN-MIB.my CISCO-WLAN-VLAN-MIB CISCOWORKS-MIB.my CISCOWORKS-MIB CISCO-WRED-MIB.my CISCO-WRED-MIB CISCO-WWNMGR-MIB.my CISCO-WWNMGR-MIB CISCO-XDSL-LINE-MIB.my CISCO-XDSL-LINE-MIB CISCO-XGCP-CAPABILITY.my CISCO-XGCP-CAPABILITY CISCO-XGCP-MIB.my CISCO-XGCP-MIB CISCO-ZS-EXT-MIB.my CISCO-ZS-EXT-MIB CISCO-ZS-MIB.my CISCO-ZS-MIB CLAB-DEF-MIB.my CLAB-DEF-MIB COMPAT-MIB.my COMPAT-MIB DIFFSERV-MIB-CAPABILITY.my DIFFSERV-MIB-CAPABILITY DOCS-CABLE-DEVICE-TRAP-MIB.my DOCS-CABLE-DEVICE-TRAP-MIB DOCS-DSG-IF-MIB.my DSG-IF-MIB DOCS-IF-EXT-MIB.my DOCS-IF-EXT-MIB DOCS-QOS-MIB.my DOCS-QOS-MIB DOCS-SUBMGT-MIB.my DOCS-SUBMGT-MIB EXPRESSION-MIB.my EXPRESSION-MIB GENERICOBJECT-MIB.my GENERICOBJECT-MIB IEEE8021-CFM-MIB.my IEEE8021-CFM-MIB IEEE8021-PAE-MIB.my IEEE8021-PAE-MIB IEEE8023-LAG-MIB.my IEEE8023-LAG-MIB IEEE802dot11-MIB.my IEEE802dot11-MIB IEEE-802DOT17-RPR-MIB.my IEEE-802DOT17-RPR-MIB IGMP-MIB.my IGMP-MIB IMA-MIB.my IMA-MIB INT-SERV-GUARANTEED-MIB.my INT-SERV-GUARANTEED-MIB INT-SERV-MIB.my INT-SERV-MIB IPMROUTE-MIB.my IPMROUTE-MIB LAN-EMULATION-CLIENT-MIB.my LAN-EMULATION-CLIENT-MIB LANOPTICS-ALERTS-MIB.my LANOPTICS-ALERTS-MIB LANOPTICS-BRIDGE-OPTION-MIB.my LANOPTICS-BRIDGE-OPTION-MIB LANOPTICS-ETHERNET-OPTION-MIB.my LANOPTICS-ETHERNET-OPTION-MIB LANOPTICS-HUB-MIB.my LANOPTICS-HUB-MIB LANOPTICS-RING-MANAGER-MIB.my LANOPTICS-RING-MANAGER-MIB LANOPTICS-SYSTEM-MIB.my LANOPTICS-SYSTEM-MIB LLDP-MIB.my LLDP-MIB MPLS-LDP-CAPABILITY.my MPLS-LDP-CAPABILITY MPLS-LSR-MIB-CAPABILITY.my MPLS-LSR-MIB-CAPABILITY MPLS-LSR-MIB.my MPLS-LSR-MIB MPLS-TE-CAPABILITY.my MPLS-TE-CAPABILITY MPLS-TE-MIB.my MPLS-TE-MIB MPLS-VPN-MIB.my MPLS-VPN-MIB NETRANGER.my NETRANGER OLD-CISCO-CHASSIS-MIB.my OLD-CISCO-CHASSIS-MIB ONS15501-CAPABILITY.my ONS15501-CAPABILITY ONS15501-MIB.my ONS15501-MIB P-BRIDGE.my P-BRIDGE-MIB PCUBE-CONFIG-COPY.my PCUBE-CONFIG-COPY-MIB PCUBE-ENGAGE-MIB.my CISCO-SCAS-BB-MIB PCUBE-PRODUCTS.my PCUBE-PRODUCTS-MIB PCUBE-SE-MIB.my PCUBE-SE-MIB PCUBE-SMI.my PCUBE-SMI PNNI-MIB.my PNNI-MIB Q-BRIDGE.my Q-BRIDGE-MIB RTM-MIB.my RTM-MIB SNMP-USM-MIB.my SNMP-USER-BASED-SM-MIB SNMP-VACM-MIB.my SNMP-VIEW-BASED-ACM-MIB XGCP-MIB.my XGCP-MIB snmp-mibs-downloader-1.1/screenos.conf0000644000000000000000000000034511402176071014773 0ustar # Configuarions for Juniper ScreenOS SNMPv2 MIBs download from juniper.net # HOST=http://www.juniper.net ARCHIVE=6.3mib.zip ARCHTYPE=zip ARCHDIR=snmpv2 DIR=techpubs/software/screenos/screenos6.3.0 CONF=screenoslist DEST=juniper snmp-mibs-downloader-1.1/screenoslist0000644000000000000000000000334311402176071014744 0ustar NS-ADDR.mib NETSCREEN-ADDR-MIB NS-BGP4.mib NETSCREEN-BGP4-MIB NS-CHASSIS.mib NETSCREEN-CHASSIS-MIB NS-IDS.mib NETSCREEN-IDS-MIB NS-INTERFACE.mib NETSCREEN-INTERFACE-MIB NS-IP-ARP.mib NETSCREEN-IP-ARP-MIB NS-NAT.mib NETSCREEN-NAT-MIB NS-NSRP.mib NETSCREEN-NSRP-MIB NS-OSPF.mib NETSCREEN-OSPF-MIB NS-OSPF-TRAP.mib NETSCREEN-OSPF-TRAP-MIB NS-POLICY.mib NETSCREEN-POLICY-MIB NS-PRODUCTS.mib NETSCREEN-PRODUCTS-MIB NS-QOS.mib NETSCREEN-QOS-MIB NS-RES.mib NETSCREEN-RESOURCE-MIB NS-RIP.mib NETSCREEN-RIPv2-MIB NS-SCHEDULE.mib NETSCREEN-SCHEDULE-MIB NS-SERVICE.mib NETSCREEN-SERVICE-MIB NS-SET-ADMIN-USR.mib NETSCREEN-SET-ADMIN-USR-MIB NS-SET-AUTH.mib NETSCREEN-SET-AUTH-MIB NS-SET-DHCP.mib NETSCREEN-SET-DHCP-MIB NS-SET-DNS.mib NETSCREEN-SET-DNS-MIB NS-SET-EMAIL.mib NETSCREEN-SET-EMAIL-MIB NS-SET-GEN.mib NETSCREEN-SET-GEN-MIB NS-SET-GLB.mib NETSCREEN-SET-GLB-MIB NS-SET-LOG.mib NETSCREEN-SET-LOG-MIB NS-SET-SNMP.mib NETSCREEN-SET-SNMP-MIB NS-SET-SYSTIME.mib NETSCREEN-SET-SYSTIME-MIB NS-SET-URL-FILTER.mib NETSCREEN-SET-URL-FILTER-MIB NS-SET-WEB.mib NETSCREEN-SET-WEB-MIB NS-SMI.mib NETSCREEN-SMI NS-TRAPS.mib NETSCREEN-TRAP-MIB NS-VPN-CERT.mib NETSCREEN-CERTIFICATE-MIB NS-VPN-GW.mib NETSCREEN-VPN-GATEWAY-MIB NS-VPN-IKE.mib NETSCREEN-VPN-IKE-MIB NS-VPN-IPPOOL.mib NETSCREEN-IPPOOL-MIB NS-VPN-L2TP.mib NETSCREEN-VPN-L2TP-MIB NS-VPN-MANUAL.mib NETSCREEN-VPN-MANUAL-MIB NS-VPN-MON.mib NETSCREEN-VPN-MON-MIB NS-VPN-PH1.mib NETSCREEN-VPN-PHASEONE-MIB NS-VPN-PH2.mib NETSCREEN-VPN-PHASETWO-MIB NS-VPN-USR.mib NETSCREEN-VPN-USER-MIB NS-VR-BGP4.mib NETSCREEN-VR-BGP4-MIB NS-VR.mib NETSCREEN-VR-MIB NS-VR-OSPF.mib NETSCREEN-VR-OSPF-MIB NS-VR-RIP.mib NETSCREEN-VR-RIPv2-MIB NS-VSYS.mib NETSCREEN-VSYS-MIB NS-ZONE.mib NETSCREEN-ZONE-MIB snmp-mibs-downloader-1.1/junoslist0000644000000000000000000000570611402176071014266 0ustar mib-jnx-analyzer.txt JUNIPER-ANALYZER-MIB mib-jnx-atm-cos.txt JUNIPER-ATM-COS-MIB mib-jnx-atm.txt JUNIPER-ATM-MIB mib-jnx-bfd-exp.txt BFD-STD-MIB mib-jnx-bfd.txt JUNIPER-BFD-MIB mib-jnx-bgpmib2.txt BGP4-V2-MIB-JUNIPER mib-jnx-cfgmgmt.txt JUNIPER-CFGMGMT-MIB mib-jnx-chas-defines.txt JUNIPER-CHASSIS-DEFINES-MIB mib-jnx-chassis-alarm.txt JUNIPER-ALARM-MIB mib-jnx-chassis-fwdd.txt JUNIPER-CHASSIS-FWDD-MIB mib-jnx-chassis.txt JUNIPER-MIB mib-jnx-coll.txt JUNIPER-COLLECTOR-MIB mib-jnx-cos.txt JUNIPER-COS-MIB mib-jnx-dcu.txt JUNIPER-DCU-MIB mib-jnx-dfc.txt JUNIPER-DFC-MIB mib-jnx-event.txt JUNIPER-EVENT-MIB mib-jnx-ex-mac-notification.txt JUNIPER-EX-MAC-NOTIFICATION-MIB mib-jnx-exp.txt JUNIPER-EXPERIMENT-MIB mib-jnx-ex-smi.txt JUNIPER-EX-SMI mib-jnx-firewall.txt JUNIPER-FIREWALL-MIB mib-jnx-hostresources.txt JUNIPER-HOSTRESOURCES-MIB mib-jnx-if-extensions.txt JUNIPER-IF-MIB mib-jnx-ipforward.txt JUNIPER-IPFORWARD-MIB mib-jnx-ipsec-flow-mon.txt JUNIPER-IPSEC-FLOW-MON-MIB mib-jnx-ipsec-monitor-asp.txt JNX-IPSEC-MONITOR-MIB mib-jnx-ipv4.txt JUNIPER-IPv4-MIB mib-jnx-ipv6.txt JUNIPER-IPv6-MIB mib-jnx-js-auth.txt JUNIPER-JS-AUTH-MIB mib-jnx-js-cert.txt JUNIPER-JS-CERT-MIB mib-jnx-js-dns.txt JUNIPER-JS-DNS-MIB mib-jnx-js-idp.txt JUNIPER-JS-IDP-MIB mib-jnx-js-if-ext.txt JUNIPER-JS-IF-EXT-MIB mib-jnx-js-ipsec-vpn.txt JUNIPER-JS-IPSEC-VPN-MIB mib-jnx-js-nat.txt JUNIPER-JS-NAT-MIB mib-jnx-js-policy.txt JUNIPER-JS-POLICY-MIB mib-jnx-jsrpd.txt JUNIPER-CHASSIS-CLUSTER-MIB mib-jnx-js-screening.txt JUNIPER-JS-SCREENING-MIB mib-jnx-js-smi.txt JUNIPER-JS-SMI mib-jnx-js-spu-monitoring.txt JUNIPER-SRX5000-SPU-MONITORING-MIB mib-jnx-js-utm-av.txt JUNIPER-JS-UTM-AV-MIB mib-jnx-l2ald.txt JUNIPER-L2ALD-MIB mib-jnx-l2cp-features.txt JUNIPER-L2CP-FEATURES-MIB mib-jnx-l2tp.txt JNX-L2TP-MIB mib-jnx-ldp.txt JUNIPER-LDP-MIB mib-jnx-mac.txt JUNIPER-MAC-MIB mib-jnx-mimstp.txt JUNIPER-MIMSTP-MIB mib-jnx-mpls-ldp.txt JUNIPER-MPLS-LDP-MIB mib-jnx-ospfv3mib.txt OSPFV3-MIB-JUNIPER mib-jnx-otn.txt JUNIPER-OTN-MIB mib-jnx-pae-extension.txt JUNIPER-PAE-EXTENSION-MIB mib-jnx-pfe.txt JUNIPER-PFE-MIB mib-jnx-ping.txt JUNIPER-PING-MIB mib-jnx-pmon.txt JUNIPER-PMon-MIB mib-jnx-pwtdm.txt JUNIPER-PW-TDM-MIB mib-jnx-rmon.txt JUNIPER-RMON-MIB mib-jnx-rpf.txt JUNIPER-RPF-MIB mib-jnx-rpm.txt JUNIPER-RPM-MIB mib-jnx-rps.txt JUNIPER-RPS-MIB mib-jnx-rsvp.txt JUNIPER-RSVP-MIB mib-jnx-rtm.txt JUNIPER-RTM-MIB mib-jnx-scu.txt JUNIPER-SCU-MIB mib-jnx-secure-access-port.txt JUNIPER-SECURE-ACCESS-PORT-MIB mib-jnx-sipcommon.txt JUNIPER-SIP-COMMON-MIB mib-jnx-smi.txt JUNIPER-SMI mib-jnx-sonetaps.txt APS-MIB mib-jnx-sonet.txt JUNIPER-SONET-MIB mib-jnx-sp.txt JUNIPER-SP-MIB mib-jnx-syslog.txt JUNIPER-SYSLOG-MIB mib-jnx-traceroute.txt JUNIPER-TRACEROUTE-MIB mib-jnx-user-aaa.txt JUNIPER-USER-AAA-MIB mib-jnx-util.txt JUNIPER-UTIL-MIB mib-jnx-virtualchassis.txt JUNIPER-VIRTUALCHASSIS-MIB mib-jnx-vlan.txt JUNIPER-VLAN-MIB mib-jnx-vpn.txt JUNIPER-VPN-MIB snmp-mibs-downloader-1.1/junos.conf0000644000000000000000000000035311402176071014307 0ustar # Configuarions for Juniper JUNOS SNMPv2 MIBs download from juniper.net # HOST=http://www.juniper.net ARCHIVE=juniper-mibs-10.0R1.8.zip ARCHTYPE=zip ARCHDIR=JuniperMibs DIR=techpubs/software/junos/junos100 CONF=junoslist DEST=juniper snmp-mibs-downloader-1.1/snmp-mibs-downloader.conf0000644000000000000000000000013511402176071017210 0ustar # Master configuarion for mib-downloader # BASEDIR=/var/lib/mibs AUTOLOAD="rfc ianarfc iana" snmp-mibs-downloader-1.1/mibrfcs/0000755000000000000000000000000011402176072013727 5ustar snmp-mibs-downloader-1.1/mibrfcs/rfc1155.txt0000644000000000000000000011541511402176071015564 0ustar Network Working Group M. Rose Request for Comments: 1155 Performance Systems International Obsoletes: RFC 1065 K. McCloghrie Hughes LAN Systems May 1990 Structure and Identification of Management Information for TCP/IP-based Internets Table of Contents 1. Status of this Memo ............................................. 1 2. Introduction .................................................... 2 3. Structure and Identification of Management Information........... 4 3.1 Names .......................................................... 4 3.1.1 Directory .................................................... 5 3.1.2 Mgmt ......................................................... 6 3.1.3 Experimental ................................................. 6 3.1.4 Private ...................................................... 7 3.2 Syntax ......................................................... 7 3.2.1 Primitive Types .............................................. 7 3.2.1.1 Guidelines for Enumerated INTEGERs ......................... 7 3.2.2 Constructor Types ............................................ 8 3.2.3 Defined Types ................................................ 8 3.2.3.1 NetworkAddress ............................................. 8 3.2.3.2 IpAddress .................................................. 8 3.2.3.3 Counter .................................................... 8 3.2.3.4 Gauge ...................................................... 9 3.2.3.5 TimeTicks .................................................. 9 3.2.3.6 Opaque ..................................................... 9 3.3 Encodings ...................................................... 9 4. Managed Objects ................................................. 10 4.1 Guidelines for Object Names .................................... 10 4.2 Object Types and Instances ..................................... 10 4.3 Macros for Managed Objects ..................................... 14 5. Extensions to the MIB ........................................... 16 6. Definitions ..................................................... 17 7. Acknowledgements ................................................ 20 8. References ...................................................... 21 9. Security Considerations.......................................... 21 10. Authors' Addresses.............................................. 22 1. Status of this Memo This RFC is a re-release of RFC 1065, with a changed "Status of this Memo", plus a few minor typographical corrections. The technical Rose & McCloghrie [Page 1] RFC 1155 SMI May 1990 content of the document is unchanged from RFC 1065. This memo provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos which describe the management information base along with the network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a Standard Protocol for the Internet community. Its status is "Recommended". TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. The Internet Activities Board recommends that all IP and TCP implementations be network manageable. This implies implementation of the Internet MIB (RFC-1156) and at least one of the two recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095). It should be noted that, at this time, SNMP is a full Internet standard and CMOT is a draft standard. See also the Host and Gateway Requirements RFCs for more specific information on the applicability of this standard. Please refer to the latest edition of the "IAB Official Protocol Standards" RFC for current information on the state and status of standard Internet protocols. Distribution of this memo is unlimited. 2. Introduction This memo describes the common structures and identification scheme for the definition of management information used in managing TCP/IP-based internets. Included are descriptions of an object information model for network management along with a set of generic types used to describe management information. Formal descriptions of the structure are given using Abstract Syntax Notation One (ASN.1) [1]. This memo is largely concerned with organizational concerns and administrative policy: it neither specifies the objects which are managed, nor the protocols used to manage those objects. These concerns are addressed by two companion memos: one describing the Management Information Base (MIB) [2], and the other describing the Simple Network Management Protocol (SNMP) [3]. This memo is based in part on the work of the Internet Engineering Rose & McCloghrie [Page 2] RFC 1155 SMI May 1990 Task Force, particularly the working note titled "Structure and Identification of Management Information for the Internet" [4]. This memo uses a skeletal structure derived from that note, but differs in one very significant way: that note focuses entirely on the use of OSI-style network management. As such, it is not suitable for use with SNMP. This memo attempts to achieve two goals: simplicity and extensibility. Both are motivated by a common concern: although the management of TCP/IP-based internets has been a topic of study for some time, the authors do not feel that the depth and breadth of such understanding is complete. More bluntly, we feel that previous experiences, while giving the community insight, are hardly conclusive. By fostering a simple SMI, the minimal number of constraints are imposed on future potential approaches; further, by fostering an extensible SMI, the maximal number of potential approaches are available for experimentation. It is believed that this memo and its two companions comply with the guidelines set forth in RFC 1052, "IAB Recommendations for the Development of Internet Network Management Standards" [5] and RFC 1109, "Report of the Second Ad Hoc Network Management Review Group" [6]. In particular, we feel that this memo, along with the memo describing the management information base, provide a solid basis for network management of the Internet. Rose & McCloghrie [Page 3] RFC 1155 SMI May 1990 3. Structure and Identification of Management Information Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using Abstract Syntax Notation One (ASN.1) [1]. Each type of object (termed an object type) has a name, a syntax, and an encoding. The name is represented uniquely as an OBJECT IDENTIFIER. An OBJECT IDENTIFIER is an administratively assigned name. The administrative policies used for assigning names are discussed later in this memo. The syntax for an object type defines the abstract data structure corresponding to that object type. For example, the structure of a given object type might be an INTEGER or OCTET STRING. Although in general, we should permit any ASN.1 construct to be available for use in defining the syntax of an object type, this memo purposely restricts the ASN.1 constructs which may be used. These restrictions are made solely for the sake of simplicity. The encoding of an object type is simply how instances of that object type are represented using the object's type syntax. Implicitly tied to the notion of an object's syntax and encoding is how the object is represented when being transmitted on the network. This memo specifies the use of the basic encoding rules of ASN.1 [7]. It is beyond the scope of this memo to define either the MIB used for network management or the network management protocol. As mentioned earlier, these tasks are left to companion memos. This memo attempts to minimize the restrictions placed upon its companions so as to maximize generality. However, in some cases, restrictions have been made (e.g., the syntax which may be used when defining object types in the MIB) in order to encourage a particular style of management. Future editions of this memo may remove these restrictions. 3.1. Names Names are used to identify managed objects. This memo specifies names which are hierarchical in nature. The OBJECT IDENTIFIER concept is used to model this notion. An OBJECT IDENTIFIER can be used for purposes other than naming managed object types; for example, each international standard has an OBJECT IDENTIFIER assigned to it for the purposes of identification. In short, OBJECT IDENTIFIERs are a means for identifying some object, regardless of the semantics associated with the object (e.g., a network object, a standards document, etc.) An OBJECT IDENTIFIER is a sequence of integers which traverse a Rose & McCloghrie [Page 4] RFC 1155 SMI May 1990 global tree. The tree consists of a root connected to a number of labeled nodes via edges. Each node may, in turn, have children of its own which are labeled. In this case, we may term the node a subtree. This process may continue to an arbitrary level of depth. Central to the notion of the OBJECT IDENTIFIER is the understanding that administrative control of the meanings assigned to the nodes may be delegated as one traverses the tree. A label is a pairing of a brief textual description and an integer. The root node itself is unlabeled, but has at least three children directly under it: one node is administered by the International Organization for Standardization, with label iso(1); another is administrated by the International Telegraph and Telephone Consultative Committee, with label ccitt(0); and the third is jointly administered by the ISO and the CCITT, joint-iso-ccitt(2). Under the iso(1) node, the ISO has designated one subtree for use by other (inter)national organizations, org(3). Of the children nodes present, two have been assigned to the U.S. National Institutes of Standards and Technology. One of these subtrees has been transferred by the NIST to the U.S. Department of Defense, dod(6). As of this writing, the DoD has not indicated how it will manage its subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will allocate a node to the Internet community, to be administered by the Internet Activities Board (IAB) as follows: internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1. This memo, as a standard approved by the IAB, now specifies the policy under which this subtree of OBJECT IDENTIFIERs is administered. Initially, four nodes are present: directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } 3.1.1. Directory The directory(1) subtree is reserved for use with a future memo that discusses how the OSI Directory may be used in the Internet. Rose & McCloghrie [Page 5] RFC 1155 SMI May 1990 3.1.2. Mgmt The mgmt(2) subtree is used to identify objects which are defined in IAB-approved documents. Administration of the mgmt(2) subtree is delegated by the IAB to the Internet Assigned Numbers Authority for the Internet. As RFCs which define new versions of the Internet- standard Management Information Base are approved, they are assigned an OBJECT IDENTIFIER by the Internet Assigned Numbers Authority for identifying the objects defined by that memo. For example, the RFC which defines the initial Internet standard MIB would be assigned management document number 1. This RFC would use the OBJECT IDENTIFIER { mgmt 1 } or 1.3.6.1.2.1 in defining the Internet-standard MIB. The generation of new versions of the Internet-standard MIB is a rigorous process. Section 5 of this memo describes the rules used when a new version is defined. 3.1.3. Experimental The experimental(3) subtree is used to identify objects used in Internet experiments. Administration of the experimental(3) subtree is delegated by the IAB to the Internet Assigned Numbers Authority of the Internet. For example, an experimenter might received number 17, and would have available the OBJECT IDENTIFIER { experimental 17 } or 1.3.6.1.3.17 for use. As a part of the assignment process, the Internet Assigned Numbers Authority may make requirements as to how that subtree is used. Rose & McCloghrie [Page 6] RFC 1155 SMI May 1990 3.1.4. Private The private(4) subtree is used to identify objects defined unilaterally. Administration of the private(4) subtree is delegated by the IAB to the Internet Assigned Numbers Authority for the Internet. Initially, this subtree has at least one child: enterprises OBJECT IDENTIFIER ::= { private 1 } The enterprises(1) subtree is used, among other things, to permit parties providing networking subsystems to register models of their products. Upon receiving a subtree, the enterprise may, for example, define new MIB objects in this subtree. In addition, it is strongly recommended that the enterprise will also register its networking subsystems under this subtree, in order to provide an unambiguous identification mechanism for use in management protocols. For example, if the "Flintstones, Inc." enterprise produced networking subsystems, then they could request a node under the enterprises subtree from the Internet Assigned Numbers Authority. Such a node might be numbered: 1.3.6.1.4.1.42 The "Flintstones, Inc." enterprise might then register their "Fred Router" under the name of: 1.3.6.1.4.1.42.1.1 3.2. Syntax Syntax is used to define the structure corresponding to object types. ASN.1 constructs are used to define this structure, although the full generality of ASN.1 is not permitted. The ASN.1 type ObjectSyntax defines the different syntaxes which may be used in defining an object type. 3.2.1. Primitive Types Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT IDENTIFIER, and NULL are permitted. These are sometimes referred to as non-aggregate types. 3.2.1.1. Guidelines for Enumerated INTEGERs If an enumerated INTEGER is listed as an object type, then a named- number having the value 0 shall not be present in the list of Rose & McCloghrie [Page 7] RFC 1155 SMI May 1990 enumerations. Use of this value is prohibited. 3.2.2. Constructor Types The ASN.1 constructor type SEQUENCE is permitted, providing that it is used to generate either lists or tables. For lists, the syntax takes the form: SEQUENCE { , ..., } where each resolves to one of the ASN.1 primitive types listed above. Further, these ASN.1 types are always present (the DEFAULT and OPTIONAL clauses do not appear in the SEQUENCE definition). For tables, the syntax takes the form: SEQUENCE OF where resolves to a list constructor. Lists and tables are sometimes referred to as aggregate types. 3.2.3. Defined Types In addition, new application-wide types may be defined, so long as they resolve into an IMPLICITly defined ASN.1 primitive type, list, table, or some other application-wide type. Initially, few application-wide types are defined. Future memos will no doubt define others once a consensus is reached. 3.2.3.1. NetworkAddress This CHOICE represents an address from one of possibly several protocol families. Currently, only one protocol family, the Internet family, is present in this CHOICE. 3.2.3.2. IpAddress This application-wide type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order. When this ASN.1 type is encoded using the ASN.1 basic encoding rules, only the primitive encoding form shall be used. 3.2.3.3. Counter This application-wide type represents a non-negative integer which Rose & McCloghrie [Page 8] RFC 1155 SMI May 1990 monotonically increases until it reaches a maximum value, when it wraps around and starts increasing again from zero. This memo specifies a maximum value of 2^32-1 (4294967295 decimal) for counters. 3.2.3.4. Gauge This application-wide type represents a non-negative integer, which may increase or decrease, but which latches at a maximum value. This memo specifies a maximum value of 2^32-1 (4294967295 decimal) for gauges. 3.2.3.5. TimeTicks This application-wide type represents a non-negative integer which counts the time in hundredths of a second since some epoch. When object types are defined in the MIB which use this ASN.1 type, the description of the object type identifies the reference epoch. 3.2.3.6. Opaque This application-wide type supports the capability to pass arbitrary ASN.1 syntax. A value is encoded using the ASN.1 basic rules into a string of octets. This, in turn, is encoded as an OCTET STRING, in effect "double-wrapping" the original ASN.1 value. Note that a conforming implementation need only be able to accept and recognize opaquely-encoded data. It need not be able to unwrap the data and then interpret its contents. Further note that by use of the ASN.1 EXTERNAL type, encodings other than ASN.1 may be used in opaquely-encoded data. 3.3. Encodings Once an instance of an object type has been identified, its value may be transmitted by applying the basic encoding rules of ASN.1 to the syntax for the object type. Rose & McCloghrie [Page 9] RFC 1155 SMI May 1990 4. Managed Objects Although it is not the purpose of this memo to define objects in the MIB, this memo specifies a format to be used by other memos which define these objects. An object type definition consists of five fields: OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER. Syntax: The abstract syntax for the object type. This must resolve to an instance of the ASN.1 type ObjectSyntax (defined below). Definition: A textual description of the semantics of the object type. Implementations should ensure that their instance of the object fulfills this definition since this MIB is intended for use in multi-vendor environments. As such it is vital that objects have consistent meaning across all machines. Access: One of read-only, read-write, write-only, or not-accessible. Status: One of mandatory, optional, or obsolete. Future memos may also specify other fields for the objects which they define. 4.1. Guidelines for Object Names No object type in the Internet-Standard MIB shall use a sub- identifier of 0 in its name. This value is reserved for use with future extensions. Each OBJECT DESCRIPTOR corresponding to an object type in the internet-standard MIB shall be a unique, but mnemonic, printable string. This promotes a common language for humans to use when discussing the MIB and also facilitates simple table mappings for user interfaces. 4.2. Object Types and Instances An object type is a definition of a kind of managed object; it is Rose & McCloghrie [Page 10] RFC 1155 SMI May 1990 declarative in nature. In contrast, an object instance is an instantiation of an object type which has been bound to a value. For example, the notion of an entry in a routing table might be defined in the MIB. Such a notion corresponds to an object type; individual entries in a particular routing table which exist at some time are object instances of that object type. A collection of object types is defined in the MIB. Each such subject type is uniquely named by its OBJECT IDENTIFIER and also has a textual name, which is its OBJECT DESCRIPTOR. The means whereby object instances are referenced is not defined in the MIB. Reference to object instances is achieved by a protocol-specific mechanism: it is the responsibility of each management protocol adhering to the SMI to define this mechanism. An object type may be defined in the MIB such that an instance of that object type represents an aggregation of information also represented by instances of some number of "subordinate" object types. For example, suppose the following object types are defined in the MIB: OBJECT: ------- atIndex { atEntry 1 } Syntax: INTEGER Definition: The interface number for the physical address. Access: read-write. Status: mandatory. OBJECT: ------- atPhysAddress { atEntry 2 } Syntax: OCTET STRING Definition: The media-dependent physical address. Rose & McCloghrie [Page 11] RFC 1155 SMI May 1990 Access: read-write. Status: mandatory. OBJECT: ------- atNetAddress { atEntry 3 } Syntax: NetworkAddress Definition: The network address corresponding to the media-dependent physical address. Access: read-write. Status: mandatory. Then, a fourth object type might also be defined in the MIB: OBJECT: ------- atEntry { atTable 1 } Syntax: AtEntry ::= SEQUENCE { atIndex INTEGER, atPhysAddress OCTET STRING, atNetAddress NetworkAddress } Definition: An entry in the address translation table. Access: read-write. Rose & McCloghrie [Page 12] RFC 1155 SMI May 1990 Status: mandatory. Each instance of this object type comprises information represented by instances of the former three object types. An object type defined in this way is called a list. Similarly, tables can be formed by aggregations of a list type. For example, a fifth object type might also be defined in the MIB: OBJECT: ------ atTable { at 1 } Syntax: SEQUENCE OF AtEntry Definition: The address translation table. Access: read-write. Status: mandatory. such that each instance of the atTable object comprises information represented by the set of atEntry object types that collectively constitute a given atTable object instance, that is, a given address translation table. Consider how one might refer to a simple object within a table. Continuing with the previous example, one might name the object type { atPhysAddress } and specify, using a protocol-specific mechanism, the object instance { atNetAddress } = { internet "10.0.0.52" } This pairing of object type and object instance would refer to all instances of atPhysAddress which are part of any entry in some address translation table for which the associated atNetAddress value is { internet "10.0.0.52" }. To continue with this example, consider how one might refer to an aggregate object (list) within a table. Naming the object type Rose & McCloghrie [Page 13] RFC 1155 SMI May 1990 { atEntry } and specifying, using a protocol-specific mechanism, the object instance { atNetAddress } = { internet "10.0.0.52" } refers to all instances of entries in the table for which the associated atNetAddress value is { internet "10.0.0.52" }. Each management protocol must provide a mechanism for accessing simple (non-aggregate) object types. Each management protocol specifies whether or not it supports access to aggregate object types. Further, the protocol must specify which instances are "returned" when an object type/instance pairing refers to more than one instance of a type. To afford support for a variety of management protocols, all information by which instances of a given object type may be usefully distinguished, one from another, is represented by instances of object types defined in the MIB. 4.3. Macros for Managed Objects In order to facilitate the use of tools for processing the definition of the MIB, the OBJECT-TYPE macro may be used. This macro permits the key aspects of an object type to be represented in a formal way. OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax) "ACCESS" Access "STATUS" Status VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read-write" | "write-only" | "not-accessible" Status ::= "mandatory" | "optional" | "obsolete" END Given the object types defined earlier, we might imagine the following definitions being present in the MIB: atIndex OBJECT-TYPE Rose & McCloghrie [Page 14] RFC 1155 SMI May 1990 SYNTAX INTEGER ACCESS read-write STATUS mandatory ::= { atEntry 1 } atPhysAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory ::= { atEntry 2 } atNetAddress OBJECT-TYPE SYNTAX NetworkAddress ACCESS read-write STATUS mandatory ::= { atEntry 3 } atEntry OBJECT-TYPE SYNTAX AtEntry ACCESS read-write STATUS mandatory ::= { atTable 1 } atTable OBJECT-TYPE SYNTAX SEQUENCE OF AtEntry ACCESS read-write STATUS mandatory ::= { at 1 } AtEntry ::= SEQUENCE { atIndex INTEGER, atPhysAddress OCTET STRING, atNetAddress NetworkAddress } The first five definitions describe object types, relating, for example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER { atEntry 1 }. In addition, the syntax of this object is defined (INTEGER) along with the access permitted (read-write) and status (mandatory). The sixth definition describes an ASN.1 type called AtEntry. Rose & McCloghrie [Page 15] RFC 1155 SMI May 1990 5. Extensions to the MIB Every Internet-standard MIB document obsoletes all previous such documents. The portion of a name, termed the tail, following the OBJECT IDENTIFIER { mgmt version-number } used to name objects shall remain unchanged between versions. New versions may: (1) declare old object types obsolete (if necessary), but not delete their names; (2) augment the definition of an object type corresponding to a list by appending non-aggregate object types to the object types in the list; or, (3) define entirely new object types. New versions may not: (1) change the semantics of any previously defined object without changing the name of that object. These rules are important because they admit easier support for multiple versions of the Internet-standard MIB. In particular, the semantics associated with the tail of a name remain constant throughout different versions of the MIB. Because multiple versions of the MIB may thus coincide in "tail-space," implementations supporting multiple versions of the MIB can be vastly simplified. However, as a consequence, a management agent might return an instance corresponding to a superset of the expected object type. Following the principle of robustness, in this exceptional case, a manager should ignore any additional information beyond the definition of the expected object type. However, the robustness principle requires that one exercise care with respect to control actions: if an instance does not have the same syntax as its expected object type, then those control actions must fail. In both the monitoring and control cases, the name of an object returned by an operation must be identical to the name requested by an operation. Rose & McCloghrie [Page 16] RFC 1155 SMI May 1990 6. Definitions RFC1155-SMI DEFINITIONS ::= BEGIN EXPORTS -- EVERYTHING internet, directory, mgmt, experimental, private, enterprises, OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax, ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, Opaque; -- the path to the root internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } -- definition of object types OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax) "ACCESS" Access "STATUS" Status VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read-write" | "write-only" | "not-accessible" Status ::= "mandatory" | "optional" | "obsolete" END -- names of objects in the MIB ObjectName ::= OBJECT IDENTIFIER Rose & McCloghrie [Page 17] RFC 1155 SMI May 1990 -- syntax of objects in the MIB ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that simple SEQUENCEs are not directly -- mentioned here to keep things simple (i.e., -- prevent mis-use). However, application-wide -- types which are IMPLICITly encoded simple -- SEQUENCEs may appear in the following CHOICE application-wide ApplicationSyntax } SimpleSyntax ::= CHOICE { number INTEGER, string OCTET STRING, object OBJECT IDENTIFIER, empty NULL } ApplicationSyntax ::= CHOICE { address NetworkAddress, counter Counter, gauge Gauge, ticks TimeTicks, arbitrary Opaque Rose & McCloghrie [Page 18] RFC 1155 SMI May 1990 -- other application-wide types, as they are -- defined, will be added here } -- application-wide types NetworkAddress ::= CHOICE { internet IpAddress } IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value, IMPLICIT OCTET STRING -- "double-wrapped" END Rose & McCloghrie [Page 19] RFC 1155 SMI May 1990 7. Acknowledgements This memo was influenced by three sets of contributors to earlier drafts: First, Lee Labarre of the MITRE Corporation, who as author of the NETMAN SMI [4], presented the basic roadmap for the SMI. Second, several individuals who provided valuable comments on this memo prior to its initial distribution: James R. Davin, Proteon Mark S. Fedor, NYSERNet Craig Partridge, BBN Laboratories Martin Lee Schoffstall, Rensselaer Polytechnic Institute Wengyik Yeong, NYSERNet Third, the IETF MIB working group: Karl Auerbach, Epilogue Technology K. Ramesh Babu, Excelan Lawrence Besaw, Hewlett-Packard Jeffrey D. Case, University of Tennessee at Knoxville James R. Davin, Proteon Mark S. Fedor, NYSERNet Robb Foster, BBN Phill Gross, The MITRE Corporation Bent Torp Jensen, Convergent Technology Lee Labarre, The MITRE Corporation Dan Lynch, Advanced Computing Environments Keith McCloghrie, The Wollongong Group Dave Mackie, 3Com/Bridge Craig Partridge, BBN (chair) Jim Robertson, 3Com/Bridge Marshall T. Rose, The Wollongong Group Greg Satz, cisco Martin Lee Schoffstall, Rensselaer Polytechnic Institute Lou Steinberg, IBM Dean Throop, Data General Unni Warrier, Unisys Rose & McCloghrie [Page 20] RFC 1155 SMI May 1990 8. References [1] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987. [2] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Performance Systems International and Hughes LAN Systems, May 1990. [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance Systems International, and the MIT Laboratory for Computer Science, May 1990. [4] LaBarre, L., "Structure and Identification of Management Information for the Internet", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, April 1988. [5] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988. [6] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989. [7] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987. Security Considerations Security issues are not discussed in this memo. Rose & McCloghrie [Page 21] RFC 1155 SMI May 1990 Authors' Addresses Marshall T. Rose PSI, Inc. PSI California Office P.O. Box 391776 Mountain View, CA 94039 Phone: (415) 961-3380 EMail: mrose@PSI.COM Keith McCloghrie The Wollongong Group 1129 San Antonio Road Palo Alto, CA 04303 Phone: (415) 962-7160 EMail: sytek!kzm@HPLABS.HP.COM Rose & McCloghrie [Page 22] snmp-mibs-downloader-1.1/mibrfcs/rfc1213.txt0000644000000000000000000042551611402176071015565 0ustar Network Working Group K. McCloghrie Request for Comments: 1213 Hughes LAN Systems, Inc. Obsoletes: RFC 1158 M. Rose Performance Systems International Editors March 1991 Management Information Base for Network Management of TCP/IP-based internets: MIB-II Status of this Memo This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Table of Contents 1. Abstract............................................... 2 2. Introduction .......................................... 2 3. Changes from RFC 1156 ................................. 3 3.1 Deprecated Objects ................................... 3 3.2 Display Strings ...................................... 4 3.3 Physical Addresses ................................... 4 3.4 The System Group ..................................... 5 3.5 The Interfaces Group ................................. 5 3.6 The Address Translation Group ........................ 6 3.7 The IP Group ......................................... 6 3.8 The ICMP Group ....................................... 7 3.9 The TCP Group ........................................ 7 3.10 The UDP Group ....................................... 7 3.11 The EGP Group ....................................... 7 3.12 The Transmission Group .............................. 8 3.13 The SNMP Group ...................................... 8 3.14 Changes from RFC 1158 ................. ............. 9 4. Objects ............................................... 10 4.1 Format of Definitions ................................ 10 5. Overview .............................................. 10 6. Definitions ........................................... 12 6.1 Textual Conventions .................................. 12 6.2 Groups in MIB-II ..................................... 13 6.3 The System Group ..................................... 13 SNMP Working Group [Page 1] RFC 1213 MIB-II March 1991 6.4 The Interfaces Group ................................. 16 6.5 The Address Translation Group ........................ 23 6.6 The IP Group ......................................... 26 6.7 The ICMP Group ....................................... 41 6.8 The TCP Group ........................................ 46 6.9 The UDP Group ........................................ 52 6.10 The EGP Group ....................................... 54 6.11 The Transmission Group .............................. 60 6.12 The SNMP Group ...................................... 60 7. Acknowledgements ...................................... 67 8. References ............................................ 69 9. Security Considerations ............................... 70 10. Authors' Addresses ................................... 70 1. Abstract This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. 2. Introduction As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP) was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI) [2], and RFC 1066, which defined the Management Information Base (MIB) [3]. Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework. This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion. As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [4], the requirements of the SNMP and the OSI SNMP Working Group [Page 2] RFC 1213 MIB-II March 1991 network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, the SNMP, to respond to new operational needs in the Internet community by producing this document. As such, the current network management framework for TCP/IP- based internets consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [12], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets: MIB-II, this memo, which describes the managed objects contained in the MIB (and supercedes RFC 1156 [13]); and, the Simple Network Management Protocol, RFC 1098 [5], which defines the protocol used to manage these objects. 3. Changes from RFC 1156 Features of this MIB include: (1) incremental additions to reflect new operational requirements; (2) upwards compatibility with the SMI/MIB and the SNMP; (3) improved support for multi-protocol entities; and, (4) textual clean-up of the MIB to improve clarity and readability. The objects defined in MIB-II have the OBJECT IDENTIFIER prefix: mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } which is identical to the prefix used in MIB-I. 3.1. Deprecated Objects In order to better prepare implementors for future changes in the MIB, a new term "deprecated" may be used when describing an object. A deprecated object in the MIB is one which must be supported, but one which will most likely be removed from the next version of the MIB (e.g., MIB-III). MIB-II marks one object as being deprecated: atTable SNMP Working Group [Page 3] RFC 1213 MIB-II March 1991 As a result of deprecating the atTable object, the entire Address Translation group is deprecated. Note that no functionality is lost with the deprecation of these objects: new objects providing equivalent or superior functionality are defined in MIB-II. 3.2. Display Strings In the past, there have been misinterpretations of the MIB as to when a string of octets should contain printable characters, meant to be displayed to a human. As a textual convention in the MIB, the datatype DisplayString ::= OCTET STRING is introduced. A DisplayString is restricted to the NVT ASCII character set, as defined in pages 10-11 of [6]. The following objects are now defined in terms of DisplayString: sysDescr ifDescr It should be noted that this change has no effect on either the syntax nor semantics of these objects. The use of the DisplayString notation is merely an artifact of the explanatory method used in MIB-II and future MIBs. Further it should be noted that any object defined in terms of OCTET STRING may contain arbitrary binary data, in which each octet may take any value from 0 to 255 (decimal). 3.3. Physical Addresses As a further, textual convention in the MIB, the datatype PhysAddress ::= OCTET STRING is introduced to represent media- or physical-level addresses. The following objects are now defined in terms of PhysAddress: ifPhysAddress atPhysAddress ipNetToMediaPhysAddress SNMP Working Group [Page 4] RFC 1213 MIB-II March 1991 It should be noted that this change has no effect on either the syntax nor semantics of these objects. The use of the PhysAddress notation is merely an artifact of the explanatory method used in MIB-II and future MIBs. 3.4. The System Group Four new objects are added to this group: sysContact sysName sysLocation sysServices These provide contact, administrative, location, and service information regarding the managed node. 3.5. The Interfaces Group The definition of the ifNumber object was incorrect, as it required all interfaces to support IP. (For example, devices without IP, such as MAC-layer bridges, could not be managed if this definition was strictly followed.) The description of the ifNumber object is changed accordingly. The ifTable object was mistaken marked as read-write, it has been (correctly) re-designated as not-accessible. In addition, several new values have been added to the ifType column in the ifTable object: ppp(23) softwareLoopback(24) eon(25) ethernet-3Mbit(26) nsip(27) slip(28) ultra(29) ds3(30) sip(31) frame-relay(32) Finally, a new column has been added to the ifTable object: ifSpecific which provides information about information specific to the media being used to realize the interface. SNMP Working Group [Page 5] RFC 1213 MIB-II March 1991 3.6. The Address Translation Group In MIB-I this group contained a table which permitted mappings from network addresses (e.g., IP addresses) to physical addresses (e.g., MAC addresses). Experience has shown that efficient implementations of this table make two assumptions: a single network protocol environment, and mappings occur only from network address to physical address. The need to support multi-protocol nodes (e.g., those with both the IP and CLNP active), and the need to support the inverse mapping (e.g., for ES-IS), have invalidated both of these assumptions. As such, the atTable object is declared deprecated. In order to meet both the multi-protocol and inverse mapping requirements, MIB-II and its successors will allocate up to two address translation tables inside each network protocol group. That is, the IP group will contain one address translation table, for going from IP addresses to physical addresses. Similarly, when a document defining MIB objects for the CLNP is produced (e.g., [7]), it will contain two tables, for mappings in both directions, as this is required for full functionality. It should be noted that the choice of two tables (one for each direction of mapping) provides for ease of implementation in many cases, and does not introduce undue burden on implementations which realize the address translation abstraction through a single internal table. 3.7. The IP Group The access attribute of the variable ipForwarding has been changed from read-only to read-write. In addition, there is a new column to the ipAddrTable object, ipAdEntReasmMaxSize which keeps track of the largest IP datagram that can be re-assembled on a particular interface. The descriptor of the ipRoutingTable object has been changed to ipRouteTable for consistency with the other IP routing objects. There are also three new columns in the ipRouteTable object, ipRouteMask ipRouteMetric5 ipRouteInfo SNMP Working Group [Page 6] RFC 1213 MIB-II March 1991 the first is used for IP routing subsystems that support arbitrary subnet masks, and the latter two are IP routing protocol-specific. Two new objects are added to the IP group: ipNetToMediaTable ipRoutingDiscards the first is the address translation table for the IP group (providing identical functionality to the now deprecated atTable in the address translation group), and the latter provides information when routes are lost due to a lack of buffer space. 3.8. The ICMP Group There are no changes to this group. 3.9. The TCP Group Two new variables are added: tcpInErrs tcpOutRsts which keep track of the number of incoming TCP segments in error and the number of resets generated by a TCP. 3.10. The UDP Group A new table: udpTable is added. 3.11. The EGP Group Experience has indicated a need for additional objects that are useful in EGP monitoring. In addition to making several additions to the egpNeighborTable object, i.e., egpNeighAs egpNeighInMsgs egpNeighInErrs egpNeighOutMsgs egpNeighOutErrs egpNeighInErrMsgs egpNeighOutErrMsgs SNMP Working Group [Page 7] RFC 1213 MIB-II March 1991 egpNeighStateUps egpNeighStateDowns egpNeighIntervalHello egpNeighIntervalPoll egpNeighMode egpNeighEventTrigger a new variable is added: egpAs which gives the autonomous system associated with this EGP entity. 3.12. The Transmission Group MIB-I was lacking in that it did not distinguish between different types of transmission media. A new group, the Transmission group, is allocated for this purpose: transmission OBJECT IDENTIFIER ::= { mib-2 10 } When Internet-standard definitions for managing transmission media are defined, the transmission group is used to provide a prefix for the names of those objects. Typically, such definitions reside in the experimental portion of the MIB until they are "proven", then as a part of the Internet standardization process, the definitions are accordingly elevated and a new object identifier, under the transmission group is defined. By convention, the name assigned is: type OBJECT IDENTIFIER ::= { transmission number } where "type" is the symbolic value used for the media in the ifType column of the ifTable object, and "number" is the actual integer value corresponding to the symbol. 3.13. The SNMP Group The application-oriented working groups of the IETF have been tasked to be receptive towards defining MIB variables specific to their respective applications. For the SNMP, it is useful to have statistical information. A new group, the SNMP group, is allocated for this purpose: snmp OBJECT IDENTIFIER ::= { mib-2 11 } SNMP Working Group [Page 8] RFC 1213 MIB-II March 1991 3.14. Changes from RFC 1158 Features of this MIB include: (1) The managed objects in this document have been defined using the conventions defined in the Internet-standard SMI, as amended by the extensions specified in [14]. It must be emphasized that definitions made using these extensions are semantically identically to those in RFC 1158. (2) The PhysAddress textual convention has been introduced to represent media addresses. (3) The ACCESS clause of sysLocation is now read-write. (4) The definition of sysServices has been clarified. (5) New ifType values (29-32) have been defined. In addition, the textual-descriptor for the DS1 and E1 interface types has been corrected. (6) The definition of ipForwarding has been clarified. (7) The definition of ipRouteType has been clarified. (8) The ipRouteMetric5 and ipRouteInfo objects have been defined. (9) The ACCESS clause of tcpConnState is now read-write, to support deletion of the TCB associated with a TCP connection. The definition of this object has been clarified to explain this usage. (10) The definition of egpNeighEventTrigger has been clarified. (11) The definition of several of the variables in the new snmp group have been clarified. In addition, the snmpInBadTypes and snmpOutReadOnlys objects are no longer present. (However, the object identifiers associated with those objects are reserved to prevent future use.) (12) The definition of snmpInReadOnlys has been clarified. (13) The textual descriptor of the snmpEnableAuthTraps has been changed to snmpEnableAuthenTraps, and the definition has been clarified. SNMP Working Group [Page 9] RFC 1213 MIB-II March 1991 (14) The ipRoutingDiscards object was added. (15) The optional use of an implementation-dependent, small positive integer was disallowed when identifying instances of the IP address and routing tables. 4. Objects 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) [8] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [12] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [9], subject to the additional requirements imposed by the SNMP. 4.1. Format of Definitions Section 6 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [14]. 5. Overview Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined here, has been derived by taking only those elements which are considered essential. This approach of taking only the essential objects is NOT restrictive, since the SMI defined in the companion memo provides SNMP Working Group [Page 10] RFC 1213 MIB-II March 1991 three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non-standard objects through the experimental subtree; and three, the addition of private objects through the enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential. The design of MIB-II is heavily influenced by the first extensibility mechanism. Several new variables have been added based on operational experience and need. Based on this, the criteria for including an object in MIB-II are remarkably similar to the MIB-I criteria: (1) An object needed to be essential for either fault or configuration management. (2) Only weak control objects were permitted (by weak, it is meant that tampering with them can do only limited damage). This criterion reflects the fact that the current management protocols are not sufficiently secure to do more powerful control operations. (3) Evidence of current use and utility was required. (4) In MIB-I, an attempt was made to limit the number of objects to about 100 to make it easier for vendors to fully instrument their software. In MIB-II, this limit was raised given the wide technological base now implementing MIB-I. (5) To avoid redundant variables, it was required that no object be included that can be derived from others in the MIB. (6) Implementation specific objects (e.g., for BSD UNIX) were excluded. (7) It was agreed to avoid heavily instrumenting critical sections of code. The general guideline was one counter per critical section per layer. MIB-II, like its predecessor, the Internet-standard MIB, contains only essential elements. There is no need to allow individual objects to be optional. Rather, the objects are arranged into the following groups: SNMP Working Group [Page 11] RFC 1213 MIB-II March 1991 - System - Interfaces - Address Translation (deprecated) - IP - ICMP - TCP - UDP - EGP - Transmission - SNMP These groups are the basic unit of conformance: This method is as follows: if the semantics of a group is applicable to an implementation, then it must implement all objects in that group. For example, an implementation must implement the EGP group if and only if it implements the EGP. There are two reasons for defining these groups: to provide a means of assigning object identifiers; and, to provide a method for implementations of managed agents to know which objects they must implement. 6. Definitions RFC1213-MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [14]; -- MIB-II (same prefix as MIB-I) mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- textual conventions DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having SNMP Working Group [Page 12] RFC 1213 MIB-II March 1991 -- -- SIZE (0..255) PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets. -- groups in MIB-II system OBJECT IDENTIFIER ::= { mib-2 1 } interfaces OBJECT IDENTIFIER ::= { mib-2 2 } at OBJECT IDENTIFIER ::= { mib-2 3 } ip OBJECT IDENTIFIER ::= { mib-2 4 } icmp OBJECT IDENTIFIER ::= { mib-2 5 } tcp OBJECT IDENTIFIER ::= { mib-2 6 } udp OBJECT IDENTIFIER ::= { mib-2 7 } egp OBJECT IDENTIFIER ::= { mib-2 8 } -- historical (some say hysterical) -- cmot OBJECT IDENTIFIER ::= { mib-2 9 } transmission OBJECT IDENTIFIER ::= { mib-2 10 } snmp OBJECT IDENTIFIER ::= { mib-2 11 } -- the System group -- Implementation of the System group is mandatory for all -- systems. If an agent is not configured to have a value -- for any of these variables, a string of length 0 is -- returned. sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory SNMP Working Group [Page 13] RFC 1213 MIB-II March 1991 DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 } sysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'." ::= { system 2 } sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } sysContact OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The textual identification of the contact person for this managed node, together with information on how to contact this person." ::= { system 4 } sysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) SNMP Working Group [Page 14] RFC 1213 MIB-II March 1991 ACCESS read-write STATUS mandatory DESCRIPTION "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name." ::= { system 5 } sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The physical location of this node (e.g., `telephone closet, 3rd floor')." ::= { system 6 } sysServices OBJECT-TYPE SYNTAX INTEGER (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "A value which indicates the set of services that this entity primarily offers. The value is a sum. This sum initially takes the value zero, Then, for each layer, L, in the range 1 through 7, that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs primarily routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values should be calculated accordingly: layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 internet (e.g., IP gateways) 4 end-to-end (e.g., IP hosts) 7 applications (e.g., mail relays) For systems including OSI protocols, layers 5 and 6 may also be counted." ::= { system 7 } SNMP Working Group [Page 15] RFC 1213 MIB-II March 1991 -- the Interfaces group -- Implementation of the Interfaces group is mandatory for -- all systems. ifNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of network interfaces (regardless of their current state) present on this system." ::= { interfaces 1 } -- the Interfaces table -- The Interfaces table contains information on the entity's -- interfaces. Each interface is thought of as being -- attached to a `subnetwork'. Note that this term should -- not be confused with `subnet' which refers to an -- addressing partitioning scheme used in the Internet suite -- of protocols. ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifNumber." ::= { interfaces 2 } ifEntry OBJECT-TYPE SYNTAX IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An interface entry containing objects at the subnetwork layer and below for a particular interface." INDEX { ifIndex } ::= { ifTable 1 } IfEntry ::= SEQUENCE { ifIndex INTEGER, SNMP Working Group [Page 16] RFC 1213 MIB-II March 1991 ifDescr DisplayString, ifType INTEGER, ifMtu INTEGER, ifSpeed Gauge, ifPhysAddress PhysAddress, ifAdminStatus INTEGER, ifOperStatus INTEGER, ifLastChange TimeTicks, ifInOctets Counter, ifInUcastPkts Counter, ifInNUcastPkts Counter, ifInDiscards Counter, ifInErrors Counter, ifInUnknownProtos Counter, ifOutOctets Counter, ifOutUcastPkts Counter, ifOutNUcastPkts Counter, ifOutDiscards Counter, ifOutErrors Counter, ifOutQLen Gauge, ifSpecific OBJECT IDENTIFIER } ifIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory SNMP Working Group [Page 17] RFC 1213 MIB-II March 1991 DESCRIPTION "A unique value for each interface. Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { ifEntry 1 } ifDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface." ::= { ifEntry 2 } ifType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following regular1822(2), hdh1822(3), ddn-x25(4), rfc877-x25(5), ethernet-csmacd(6), iso88023-csmacd(7), iso88024-tokenBus(8), iso88025-tokenRing(9), iso88026-man(10), starLan(11), proteon-10Mbit(12), proteon-80Mbit(13), hyperchannel(14), fddi(15), lapb(16), sdlc(17), ds1(18), -- T-1 e1(19), -- european equiv. of T-1 basicISDN(20), primaryISDN(21), -- proprietary serial propPointToPointSerial(22), ppp(23), softwareLoopback(24), eon(25), -- CLNP over IP [11] ethernet-3Mbit(26), SNMP Working Group [Page 18] RFC 1213 MIB-II March 1991 nsip(27), -- XNS over IP slip(28), -- generic SLIP ultra(29), -- ULTRA technologies ds3(30), -- T-3 sip(31), -- SMDS frame-relay(32) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of interface, distinguished according to the physical/link protocol(s) immediately `below' the network layer in the protocol stack." ::= { ifEntry 3 } ifMtu OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The size of the largest datagram which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface." ::= { ifEntry 4 } ifSpeed OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth." ::= { ifEntry 5 } ifPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-only STATUS mandatory DESCRIPTION "The interface's address at the protocol layer immediately `below' the network layer in the protocol stack. For interfaces which do not have SNMP Working Group [Page 19] RFC 1213 MIB-II March 1991 such an address (e.g., a serial line), this object should contain an octet string of zero length." ::= { ifEntry 6 } ifAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } ACCESS read-write STATUS mandatory DESCRIPTION "The desired state of the interface. The testing(3) state indicates that no operational packets can be passed." ::= { ifEntry 7 } ifOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } ACCESS read-only STATUS mandatory DESCRIPTION "The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed." ::= { ifEntry 8 } ifLastChange OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re- initialization of the local network management subsystem, then this object contains a zero value." ::= { ifEntry 9 } ifInOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only SNMP Working Group [Page 20] RFC 1213 MIB-II March 1991 STATUS mandatory DESCRIPTION "The total number of octets received on the interface, including framing characters." ::= { ifEntry 10 } ifInUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of subnetwork-unicast packets delivered to a higher-layer protocol." ::= { ifEntry 11 } ifInNUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of non-unicast (i.e., subnetwork- broadcast or subnetwork-multicast) packets delivered to a higher-layer protocol." ::= { ifEntry 12 } ifInDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space." ::= { ifEntry 13 } ifInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol." ::= { ifEntry 14 } SNMP Working Group [Page 21] RFC 1213 MIB-II March 1991 ifInUnknownProtos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received via the interface which were discarded because of an unknown or unsupported protocol." ::= { ifEntry 15 } ifOutOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of octets transmitted out of the interface, including framing characters." ::= { ifEntry 16 } ifOutUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted to a subnetwork-unicast address, including those that were discarded or not sent." ::= { ifEntry 17 } ifOutNUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted to a non- unicast (i.e., a subnetwork-broadcast or subnetwork-multicast) address, including those that were discarded or not sent." ::= { ifEntry 18 } ifOutDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of outbound packets which were chosen SNMP Working Group [Page 22] RFC 1213 MIB-II March 1991 to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space." ::= { ifEntry 19 } ifOutErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of outbound packets that could not be transmitted because of errors." ::= { ifEntry 20 } ifOutQLen OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The length of the output packet queue (in packets)." ::= { ifEntry 21 } ifSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "A reference to MIB definitions specific to the particular media being used to realize the interface. For example, if the interface is realized by an ethernet, then the value of this object refers to a document defining objects specific to ethernet. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntatically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value." ::= { ifEntry 22 } -- the Address Translation group -- Implementation of the Address Translation group is -- mandatory for all systems. Note however that this group -- is deprecated by MIB-II. That is, it is being included SNMP Working Group [Page 23] RFC 1213 MIB-II March 1991 -- solely for compatibility with MIB-I nodes, and will most -- likely be excluded from MIB-III nodes. From MIB-II and -- onwards, each network protocol group contains its own -- address translation tables. -- The Address Translation group contains one table which is -- the union across all interfaces of the translation tables -- for converting a NetworkAddress (e.g., an IP address) into -- a subnetwork-specific address. For lack of a better term, -- this document refers to such a subnetwork-specific address -- as a `physical' address. -- Examples of such translation tables are: for broadcast -- media where ARP is in use, the translation table is -- equivalent to the ARP cache; or, on an X.25 network where -- non-algorithmic translation to X.121 addresses is -- required, the translation table contains the -- NetworkAddress to X.121 address equivalences. atTable OBJECT-TYPE SYNTAX SEQUENCE OF AtEntry ACCESS not-accessible STATUS deprecated DESCRIPTION "The Address Translation tables contain the NetworkAddress to `physical' address equivalences. Some interfaces do not use translation tables for determining address equivalences (e.g., DDN-X.25 has an algorithmic method); if all interfaces are of this type, then the Address Translation table is empty, i.e., has zero entries." ::= { at 1 } atEntry OBJECT-TYPE SYNTAX AtEntry ACCESS not-accessible STATUS deprecated DESCRIPTION "Each entry contains one NetworkAddress to `physical' address equivalence." INDEX { atIfIndex, atNetAddress } ::= { atTable 1 } AtEntry ::= SEQUENCE { atIfIndex INTEGER, SNMP Working Group [Page 24] RFC 1213 MIB-II March 1991 atPhysAddress PhysAddress, atNetAddress NetworkAddress } atIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS deprecated DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { atEntry 1 } atPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-write STATUS deprecated DESCRIPTION "The media-dependent `physical' address. Setting this object to a null string (one of zero length) has the effect of invaliding the corresponding entry in the atTable object. That is, it effectively dissasociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant atPhysAddress object." ::= { atEntry 2 } atNetAddress OBJECT-TYPE SYNTAX NetworkAddress ACCESS read-write STATUS deprecated DESCRIPTION "The NetworkAddress (e.g., the IP address) corresponding to the media-dependent `physical' address." SNMP Working Group [Page 25] RFC 1213 MIB-II March 1991 ::= { atEntry 3 } -- the IP group -- Implementation of the IP group is mandatory for all -- systems. ipForwarding OBJECT-TYPE SYNTAX INTEGER { forwarding(1), -- acting as a gateway not-forwarding(2) -- NOT acting as a gateway } ACCESS read-write STATUS mandatory DESCRIPTION "The indication of whether this entity is acting as an IP gateway in respect to the forwarding of datagrams received by, but not addressed to, this entity. IP gateways forward datagrams. IP hosts do not (except those source-routed via the host). Note that for some managed nodes, this object may take on only a subset of the values possible. Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to change this object to an inappropriate value." ::= { ip 1 } ipDefaultTTL OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The default value inserted into the Time-To-Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol." ::= { ip 2 } ipInReceives OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input datagrams received from interfaces, including those received in error." SNMP Working Group [Page 26] RFC 1213 MIB-II March 1991 ::= { ip 3 } ipInHdrErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc." ::= { ip 4 } ipInAddrErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP Gateways and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address." ::= { ip 5 } ipForwDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IP Gateways, this counter will include only those packets which were Source-Routed via this entity, and the Source- Route option processing was successful." ::= { ip 6 } ipInUnknownProtos OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 27] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol." ::= { ip 7 } ipInDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly." ::= { ip 8 } ipInDelivers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input datagrams successfully delivered to IP user-protocols (including ICMP)." ::= { ip 9 } ipOutRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams." ::= { ip 10 } ipOutDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of output IP datagrams for which no SNMP Working Group [Page 28] RFC 1213 MIB-II March 1991 problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion." ::= { ip 11 } ipOutNoRoutes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route' criterion. Note that this includes any datagarms which a host cannot route because all of its default gateways are down." ::= { ip 12 } ipReasmTimeout OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity." ::= { ip 13 } ipReasmReqds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP fragments received which needed to be reassembled at this entity." ::= { ip 14 } ipReasmOKs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams successfully re- assembled." SNMP Working Group [Page 29] RFC 1213 MIB-II March 1991 ::= { ip 15 } ipReasmFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of failures detected by the IP re- assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received." ::= { ip 16 } ipFragOKs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams that have been successfully fragmented at this entity." ::= { ip 17 } ipFragFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set." ::= { ip 18 } ipFragCreates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagram fragments that have been generated as a result of fragmentation at this entity." ::= { ip 19 } SNMP Working Group [Page 30] RFC 1213 MIB-II March 1991 -- the IP address table -- The IP address table contains this entity's IP addressing -- information. ipAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of addressing information relevant to this entity's IP addresses." ::= { ip 20 } ipAddrEntry OBJECT-TYPE SYNTAX IpAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The addressing information for one of this entity's IP addresses." INDEX { ipAdEntAddr } ::= { ipAddrTable 1 } IpAddrEntry ::= SEQUENCE { ipAdEntAddr IpAddress, ipAdEntIfIndex INTEGER, ipAdEntNetMask IpAddress, ipAdEntBcastAddr INTEGER, ipAdEntReasmMaxSize INTEGER (0..65535) } ipAdEntAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The IP address to which this entry's addressing information pertains." ::= { ipAddrEntry 1 } SNMP Working Group [Page 31] RFC 1213 MIB-II March 1991 ipAdEntIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { ipAddrEntry 2 } ipAdEntNetMask OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The subnet mask associated with the IP address of this entry. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0." ::= { ipAddrEntry 3 } ipAdEntBcastAddr OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of the least-significant bit in the IP broadcast address used for sending datagrams on the (logical) interface associated with the IP address of this entry. For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcasts addresses used by the entity on this (logical) interface." ::= { ipAddrEntry 4 } ipAdEntReasmMaxSize OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface." ::= { ipAddrEntry 5 } SNMP Working Group [Page 32] RFC 1213 MIB-II March 1991 -- the IP routing table -- The IP routing table contains an entry for each route -- presently known to this entity. ipRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This entity's IP Routing table." ::= { ip 21 } ipRouteEntry OBJECT-TYPE SYNTAX IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A route to a particular destination." INDEX { ipRouteDest } ::= { ipRouteTable 1 } IpRouteEntry ::= SEQUENCE { ipRouteDest IpAddress, ipRouteIfIndex INTEGER, ipRouteMetric1 INTEGER, ipRouteMetric2 INTEGER, ipRouteMetric3 INTEGER, ipRouteMetric4 INTEGER, ipRouteNextHop IpAddress, ipRouteType INTEGER, ipRouteProto INTEGER, ipRouteAge INTEGER, ipRouteMask IpAddress, ipRouteMetric5 INTEGER, SNMP Working Group [Page 33] RFC 1213 MIB-II March 1991 ipRouteInfo OBJECT IDENTIFIER } ipRouteDest OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The destination IP address of this route. An entry with a value of 0.0.0.0 is considered a default route. Multiple routes to a single destination can appear in the table, but access to such multiple entries is dependent on the table- access mechanisms defined by the network management protocol in use." ::= { ipRouteEntry 1 } ipRouteIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { ipRouteEntry 2 } ipRouteMetric1 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The primary routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." ::= { ipRouteEntry 3 } ipRouteMetric2 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION SNMP Working Group [Page 34] RFC 1213 MIB-II March 1991 "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." ::= { ipRouteEntry 4 } ipRouteMetric3 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." ::= { ipRouteEntry 5 } ipRouteMetric4 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." ::= { ipRouteEntry 6 } ipRouteNextHop OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The IP address of the next hop of this route. (In the case of a route bound to an interface which is realized via a broadcast media, the value of this field is the agent's IP address on that interface.)" ::= { ipRouteEntry 7 } ipRouteType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated route SNMP Working Group [Page 35] RFC 1213 MIB-II March 1991 -- route to directly direct(3), -- connected (sub-)network -- route to a non-local indirect(4) -- host/network/sub-network } ACCESS read-write STATUS mandatory DESCRIPTION "The type of route. Note that the values direct(3) and indirect(4) refer to the notion of direct and indirect routing in the IP architecture. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipRouteTable object. That is, it effectively dissasociates the destination identified with said entry from the route identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipRouteType object." ::= { ipRouteEntry 8 } ipRouteProto OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following -- non-protocol information, -- e.g., manually configured local(2), -- entries -- set via a network netmgmt(3), -- management protocol -- obtained via ICMP, icmp(4), -- e.g., Redirect -- the remaining values are -- all gateway routing -- protocols egp(5), ggp(6), SNMP Working Group [Page 36] RFC 1213 MIB-II March 1991 hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13), bgp(14) } ACCESS read-only STATUS mandatory DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { ipRouteEntry 9 } ipRouteAge OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned." ::= { ipRouteEntry 10 } ipRouteMask OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "Indicate the mask to be logical-ANDed with the destination address before being compared to the value in the ipRouteDest field. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the ipRouteMask by determining whether the value of the correspondent ipRouteDest field belong to a class-A, B, or C network, and then using one of: mask network 255.0.0.0 class-A 255.255.0.0 class-B 255.255.255.0 class-C SNMP Working Group [Page 37] RFC 1213 MIB-II March 1991 If the value of the ipRouteDest is 0.0.0.0 (a default route), then the mask value is also 0.0.0.0. It should be noted that all IP routing subsystems implicitly use this mechanism." ::= { ipRouteEntry 11 } ipRouteMetric5 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." ::= { ipRouteEntry 12 } ipRouteInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route's ipRouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntatically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value." ::= { ipRouteEntry 13 } -- the IP Address Translation table -- The IP address translation table contain the IpAddress to -- `physical' address equivalences. Some interfaces do not -- use translation tables for determining address -- equivalences (e.g., DDN-X.25 has an algorithmic method); -- if all interfaces are of this type, then the Address -- Translation table is empty, i.e., has zero entries. ipNetToMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF IpNetToMediaEntry ACCESS not-accessible STATUS mandatory SNMP Working Group [Page 38] RFC 1213 MIB-II March 1991 DESCRIPTION "The IP Address Translation table used for mapping from IP addresses to physical addresses." ::= { ip 22 } ipNetToMediaEntry OBJECT-TYPE SYNTAX IpNetToMediaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry contains one IpAddress to `physical' address equivalence." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress } ::= { ipNetToMediaTable 1 } IpNetToMediaEntry ::= SEQUENCE { ipNetToMediaIfIndex INTEGER, ipNetToMediaPhysAddress PhysAddress, ipNetToMediaNetAddress IpAddress, ipNetToMediaType INTEGER } ipNetToMediaIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { ipNetToMediaEntry 1 } ipNetToMediaPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-write STATUS mandatory DESCRIPTION "The media-dependent `physical' address." ::= { ipNetToMediaEntry 2 } SNMP Working Group [Page 39] RFC 1213 MIB-II March 1991 ipNetToMediaNetAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The IpAddress corresponding to the media- dependent `physical' address." ::= { ipNetToMediaEntry 3 } ipNetToMediaType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4) } ACCESS read-write STATUS mandatory DESCRIPTION "The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively dissasociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object." ::= { ipNetToMediaEntry 4 } -- additional IP objects ipRoutingDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing SNMP Working Group [Page 40] RFC 1213 MIB-II March 1991 entries." ::= { ip 23 } -- the ICMP group -- Implementation of the ICMP group is mandatory for all -- systems. icmpInMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors." ::= { icmp 1 } icmpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP messages which the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.)." ::= { icmp 2 } icmpInDestUnreachs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Destination Unreachable messages received." ::= { icmp 3 } icmpInTimeExcds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Time Exceeded messages received." ::= { icmp 4 } SNMP Working Group [Page 41] RFC 1213 MIB-II March 1991 icmpInParmProbs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Parameter Problem messages received." ::= { icmp 5 } icmpInSrcQuenchs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Source Quench messages received." ::= { icmp 6 } icmpInRedirects OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Redirect messages received." ::= { icmp 7 } icmpInEchos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo (request) messages received." ::= { icmp 8 } icmpInEchoReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo Reply messages received." ::= { icmp 9 } icmpInTimestamps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION SNMP Working Group [Page 42] RFC 1213 MIB-II March 1991 "The number of ICMP Timestamp (request) messages received." ::= { icmp 10 } icmpInTimestampReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Timestamp Reply messages received." ::= { icmp 11 } icmpInAddrMasks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Request messages received." ::= { icmp 12 } icmpInAddrMaskReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Reply messages received." ::= { icmp 13 } icmpOutMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors." ::= { icmp 14 } icmpOutErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP messages which this entity did not send due to problems discovered within ICMP SNMP Working Group [Page 43] RFC 1213 MIB-II March 1991 such as a lack of buffers. This value should not include errors discovered outside the ICMP layer such as the inability of IP to route the resultant datagram. In some implementations there may be no types of error which contribute to this counter's value." ::= { icmp 15 } icmpOutDestUnreachs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Destination Unreachable messages sent." ::= { icmp 16 } icmpOutTimeExcds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Time Exceeded messages sent." ::= { icmp 17 } icmpOutParmProbs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Parameter Problem messages sent." ::= { icmp 18 } icmpOutSrcQuenchs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Source Quench messages sent." ::= { icmp 19 } icmpOutRedirects OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Redirect messages sent. For a SNMP Working Group [Page 44] RFC 1213 MIB-II March 1991 host, this object will always be zero, since hosts do not send redirects." ::= { icmp 20 } icmpOutEchos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo (request) messages sent." ::= { icmp 21 } icmpOutEchoReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo Reply messages sent." ::= { icmp 22 } icmpOutTimestamps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Timestamp (request) messages sent." ::= { icmp 23 } icmpOutTimestampReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Timestamp Reply messages sent." ::= { icmp 24 } icmpOutAddrMasks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Request messages sent." ::= { icmp 25 } SNMP Working Group [Page 45] RFC 1213 MIB-II March 1991 icmpOutAddrMaskReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Reply messages sent." ::= { icmp 26 } -- the TCP group -- Implementation of the TCP group is mandatory for all -- systems that implement the TCP. -- Note that instances of object types that represent -- information about a particular TCP connection are -- transient; they persist only as long as the connection -- in question. tcpRtoAlgorithm OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following constant(2), -- a constant rto rsre(3), -- MIL-STD-1778, Appendix B vanj(4) -- Van Jacobson's algorithm [10] } ACCESS read-only STATUS mandatory DESCRIPTION "The algorithm used to determine the timeout value used for retransmitting unacknowledged octets." ::= { tcp 1 } tcpRtoMin OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The minimum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is rsre(3), an object of this type has the semantics of the LBOUND quantity described in RFC 793." SNMP Working Group [Page 46] RFC 1213 MIB-II March 1991 ::= { tcp 2 } tcpRtoMax OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The maximum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is rsre(3), an object of this type has the semantics of the UBOUND quantity described in RFC 793." ::= { tcp 3 } tcpMaxConn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The limit on the total number of TCP connections the entity can support. In entities where the maximum number of connections is dynamic, this object should contain the value -1." ::= { tcp 4 } tcpActiveOpens OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state." ::= { tcp 5 } tcpPassiveOpens OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state." ::= { tcp 6 } SNMP Working Group [Page 47] RFC 1213 MIB-II March 1991 tcpAttemptFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state." ::= { tcp 7 } tcpEstabResets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state." ::= { tcp 8 } tcpCurrEstab OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The number of TCP connections for which the current state is either ESTABLISHED or CLOSE- WAIT." ::= { tcp 9 } tcpInSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of segments received, including those received in error. This count includes segments received on currently established connections." ::= { tcp 10 } tcpOutSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 48] RFC 1213 MIB-II March 1991 DESCRIPTION "The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets." ::= { tcp 11 } tcpRetransSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of segments retransmitted - that is, the number of TCP segments transmitted containing one or more previously transmitted octets." ::= { tcp 12 } -- the TCP Connection table -- The TCP connection table contains information about this -- entity's existing TCP connections. tcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing TCP connection-specific information." ::= { tcp 13 } tcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state." INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 } SNMP Working Group [Page 49] RFC 1213 MIB-II March 1991 TcpConnEntry ::= SEQUENCE { tcpConnState INTEGER, tcpConnLocalAddress IpAddress, tcpConnLocalPort INTEGER (0..65535), tcpConnRemAddress IpAddress, tcpConnRemPort INTEGER (0..65535) } tcpConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this TCP connection. The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. As an implementation-specific option, a RST SNMP Working Group [Page 50] RFC 1213 MIB-II March 1991 segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably)." ::= { tcpConnEntry 1 } tcpConnLocalAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The local IP address for this TCP connection. In the case of a connection in the listen state which is willing to accept connections for any IP interface associated with the node, the value 0.0.0.0 is used." ::= { tcpConnEntry 2 } tcpConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this TCP connection." ::= { tcpConnEntry 3 } tcpConnRemAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The remote IP address for this TCP connection." ::= { tcpConnEntry 4 } tcpConnRemPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The remote port number for this TCP connection." ::= { tcpConnEntry 5 } -- additional TCP objects tcpInErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 51] RFC 1213 MIB-II March 1991 DESCRIPTION "The total number of segments received in error (e.g., bad TCP checksums)." ::= { tcp 14 } tcpOutRsts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of TCP segments sent containing the RST flag." ::= { tcp 15 } -- the UDP group -- Implementation of the UDP group is mandatory for all -- systems which implement the UDP. udpInDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of UDP datagrams delivered to UDP users." ::= { udp 1 } udpNoPorts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of received UDP datagrams for which there was no application at the destination port." ::= { udp 2 } udpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port." ::= { udp 3 } SNMP Working Group [Page 52] RFC 1213 MIB-II March 1991 udpOutDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of UDP datagrams sent from this entity." ::= { udp 4 } -- the UDP Listener table -- The UDP listener table contains information about this -- entity's UDP end-points on which a local application is -- currently accepting datagrams. udpTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing UDP listener information." ::= { udp 5 } udpEntry OBJECT-TYPE SYNTAX UdpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current UDP listener." INDEX { udpLocalAddress, udpLocalPort } ::= { udpTable 1 } UdpEntry ::= SEQUENCE { udpLocalAddress IpAddress, udpLocalPort INTEGER (0..65535) } udpLocalAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The local IP address for this UDP listener. In SNMP Working Group [Page 53] RFC 1213 MIB-II March 1991 the case of a UDP listener which is willing to accept datagrams for any IP interface associated with the node, the value 0.0.0.0 is used." ::= { udpEntry 1 } udpLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this UDP listener." ::= { udpEntry 2 } -- the EGP group -- Implementation of the EGP group is mandatory for all -- systems which implement the EGP. egpInMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received without error." ::= { egp 1 } egpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received that proved to be in error." ::= { egp 2 } egpOutMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of locally generated EGP messages." ::= { egp 3 } egpOutErrors OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 54] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally generated EGP messages not sent due to resource limitations within an EGP entity." ::= { egp 4 } -- the EGP Neighbor table -- The EGP neighbor table contains information about this -- entity's EGP neighbors. egpNeighTable OBJECT-TYPE SYNTAX SEQUENCE OF EgpNeighEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The EGP neighbor table." ::= { egp 5 } egpNeighEntry OBJECT-TYPE SYNTAX EgpNeighEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about this entity's relationship with a particular EGP neighbor." INDEX { egpNeighAddr } ::= { egpNeighTable 1 } EgpNeighEntry ::= SEQUENCE { egpNeighState INTEGER, egpNeighAddr IpAddress, egpNeighAs INTEGER, egpNeighInMsgs Counter, egpNeighInErrs Counter, egpNeighOutMsgs Counter, egpNeighOutErrs Counter, SNMP Working Group [Page 55] RFC 1213 MIB-II March 1991 egpNeighInErrMsgs Counter, egpNeighOutErrMsgs Counter, egpNeighStateUps Counter, egpNeighStateDowns Counter, egpNeighIntervalHello INTEGER, egpNeighIntervalPoll INTEGER, egpNeighMode INTEGER, egpNeighEventTrigger INTEGER } egpNeighState OBJECT-TYPE SYNTAX INTEGER { idle(1), acquisition(2), down(3), up(4), cease(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The EGP state of the local system with respect to this entry's EGP neighbor. Each EGP state is represented by a value that is one greater than the numerical value associated with said state in RFC 904." ::= { egpNeighEntry 1 } egpNeighAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The IP address of this entry's EGP neighbor." ::= { egpNeighEntry 2 } egpNeighAs OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory SNMP Working Group [Page 56] RFC 1213 MIB-II March 1991 DESCRIPTION "The autonomous system of this EGP peer. Zero should be specified if the autonomous system number of the neighbor is not yet known." ::= { egpNeighEntry 3 } egpNeighInMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received without error from this EGP peer." ::= { egpNeighEntry 4 } egpNeighInErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received from this EGP peer that proved to be in error (e.g., bad EGP checksum)." ::= { egpNeighEntry 5 } egpNeighOutMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally generated EGP messages to this EGP peer." ::= { egpNeighEntry 6 } egpNeighOutErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally generated EGP messages not sent to this EGP peer due to resource limitations within an EGP entity." ::= { egpNeighEntry 7 } egpNeighInErrMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 57] RFC 1213 MIB-II March 1991 DESCRIPTION "The number of EGP-defined error messages received from this EGP peer." ::= { egpNeighEntry 8 } egpNeighOutErrMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP-defined error messages sent to this EGP peer." ::= { egpNeighEntry 9 } egpNeighStateUps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP state transitions to the UP state with this EGP peer." ::= { egpNeighEntry 10 } egpNeighStateDowns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP state transitions from the UP state to any other state with this EGP peer." ::= { egpNeighEntry 11 } egpNeighIntervalHello OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The interval between EGP Hello command retransmissions (in hundredths of a second). This represents the t1 timer as defined in RFC 904." ::= { egpNeighEntry 12 } egpNeighIntervalPoll OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The interval between EGP poll command SNMP Working Group [Page 58] RFC 1213 MIB-II March 1991 retransmissions (in hundredths of a second). This represents the t3 timer as defined in RFC 904." ::= { egpNeighEntry 13 } egpNeighMode OBJECT-TYPE SYNTAX INTEGER { active(1), passive(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The polling mode of this EGP entity, either passive or active." ::= { egpNeighEntry 14 } egpNeighEventTrigger OBJECT-TYPE SYNTAX INTEGER { start(1), stop(2) } ACCESS read-write STATUS mandatory DESCRIPTION "A control variable used to trigger operator- initiated Start and Stop events. When read, this variable always returns the most recent value that egpNeighEventTrigger was set to. If it has not been set since the last initialization of the network management subsystem on the node, it returns a value of `stop'. When set, this variable causes a Start or Stop event on the specified neighbor, as specified on pages 8-10 of RFC 904. Briefly, a Start event causes an Idle peer to begin neighbor acquisition and a non-Idle peer to reinitiate neighbor acquisition. A stop event causes a non-Idle peer to return to the Idle state until a Start event occurs, either via egpNeighEventTrigger or otherwise." ::= { egpNeighEntry 15 } -- additional EGP objects egpAs OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The autonomous system number of this EGP entity." ::= { egp 6 } SNMP Working Group [Page 59] RFC 1213 MIB-II March 1991 -- the Transmission group -- Based on the transmission media underlying each interface -- on a system, the corresponding portion of the Transmission -- group is mandatory for that system. -- When Internet-standard definitions for managing -- transmission media are defined, the transmission group is -- used to provide a prefix for the names of those objects. -- Typically, such definitions reside in the experimental -- portion of the MIB until they are "proven", then as a -- part of the Internet standardization process, the -- definitions are accordingly elevated and a new object -- identifier, under the transmission group is defined. By -- convention, the name assigned is: -- -- type OBJECT IDENTIFIER ::= { transmission number } -- -- where "type" is the symbolic value used for the media in -- the ifType column of the ifTable object, and "number" is -- the actual integer value corresponding to the symbol. -- the SNMP group -- Implementation of the SNMP group is mandatory for all -- systems which support an SNMP protocol entity. Some of -- the objects defined below will be zero-valued in those -- SNMP implementations that are optimized to support only -- those functions specific to either a management agent or -- a management station. In particular, it should be -- observed that the objects below refer to an SNMP entity, -- and there may be several SNMP entities residing on a -- managed node (e.g., if the node is hosting acting as -- a management station). snmpInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of Messages delivered to the SNMP entity from the transport service." ::= { snmp 1 } snmpOutPkts OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 60] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages which were passed from the SNMP protocol entity to the transport service." ::= { snmp 2 } snmpInBadVersions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages which were delivered to the SNMP protocol entity and were for an unsupported SNMP version." ::= { snmp 3 } snmpInBadCommunityNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages delivered to the SNMP protocol entity which used a SNMP community name not known to said entity." ::= { snmp 4 } snmpInBadCommunityUses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages delivered to the SNMP protocol entity which represented an SNMP operation which was not allowed by the SNMP community named in the Message." ::= { snmp 5 } snmpInASNParseErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ASN.1 or BER errors encountered by the SNMP protocol entity when decoding received SNMP Messages." ::= { snmp 6 } SNMP Working Group [Page 61] RFC 1213 MIB-II March 1991 -- { snmp 7 } is not used snmpInTooBigs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `tooBig'." ::= { snmp 8 } snmpInNoSuchNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `noSuchName'." ::= { snmp 9 } snmpInBadValues OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `badValue'." ::= { snmp 10 } snmpInReadOnlys OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number valid SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `readOnly'. It should be noted that it is a protocol error to generate an SNMP PDU which contains the value `readOnly' in the error-status field, as such this object is provided as a means of detecting incorrect implementations of the SNMP Working Group [Page 62] RFC 1213 MIB-II March 1991 SNMP." ::= { snmp 11 } snmpInGenErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `genErr'." ::= { snmp 12 } snmpInTotalReqVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of MIB objects which have been retrieved successfully by the SNMP protocol entity as the result of receiving valid SNMP Get-Request and Get-Next PDUs." ::= { snmp 13 } snmpInTotalSetVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of MIB objects which have been altered successfully by the SNMP protocol entity as the result of receiving valid SNMP Set-Request PDUs." ::= { snmp 14 } snmpInGetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Request PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 15 } snmpInGetNexts OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 63] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Next PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 16 } snmpInSetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Set-Request PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 17 } snmpInGetResponses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Response PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 18 } snmpInTraps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Trap PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 19 } snmpOutTooBigs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `tooBig.'" ::= { snmp 20 } SNMP Working Group [Page 64] RFC 1213 MIB-II March 1991 snmpOutNoSuchNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status is `noSuchName'." ::= { snmp 21 } snmpOutBadValues OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `badValue'." ::= { snmp 22 } -- { snmp 23 } is not used snmpOutGenErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `genErr'." ::= { snmp 24 } snmpOutGetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Request PDUs which have been generated by the SNMP protocol entity." ::= { snmp 25 } snmpOutGetNexts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 65] RFC 1213 MIB-II March 1991 DESCRIPTION "The total number of SNMP Get-Next PDUs which have been generated by the SNMP protocol entity." ::= { snmp 26 } snmpOutSetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Set-Request PDUs which have been generated by the SNMP protocol entity." ::= { snmp 27 } snmpOutGetResponses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Response PDUs which have been generated by the SNMP protocol entity." ::= { snmp 28 } snmpOutTraps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Trap PDUs which have been generated by the SNMP protocol entity." ::= { snmp 29 } snmpEnableAuthenTraps OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Indicates whether the SNMP agent process is permitted to generate authentication-failure traps. The value of this object overrides any configuration information; as such, it provides a means whereby all authentication-failure traps may be disabled. Note that it is strongly recommended that this object be stored in non-volatile memory so that it remains constant between re-initializations of the network management system." SNMP Working Group [Page 66] RFC 1213 MIB-II March 1991 ::= { snmp 30 } END 7. Acknowledgements This document was produced by the SNMP Working Group: Anne Ambler, Spider Karl Auerbach, Sun Fred Baker, ACC David Bridgham, Epilogue Technology Ken Brinkerhoff Ron Broersma, NOSC Brian Brown, Synoptics Jack Brown, US Army Theodore Brunner, Bellcore Jeff Buffum, HP Jeffrey Buffum, HP John Burress, Wellfleet Jeffrey D. Case, University of Tennessee at Knoxville Chris Chiptasso, Spartacus Paul Ciarfella, DEC Bob Collet John Cook, Chipcom Tracy Cox, Bellcore James R. Davin, MIT-LCS Eric Decker, cisco Kurt Dobbins, Cabletron Nadya El-Afandi, Network Systems Gary Ellis, HP Fred Engle Mike Erlinger Mark S. Fedor, PSI Richard Fox, Synoptics Karen Frisa, CMU Stan Froyd, ACC Chris Gunner, DEC Fred Harris, University of Tennessee at Knoxville Ken Hibbard, Xylogics Ole Jacobsen, Interop Ken Jones Satish Joshi, Synoptics Frank Kastenholz, Racal-Interlan Shimshon Kaufman, Spartacus Ken Key, University of Tennessee at Knoxville Jim Kinder, Fibercom Alex Koifman, BBN SNMP Working Group [Page 67] RFC 1213 MIB-II March 1991 Christopher Kolb, PSI Cheryl Krupczak, NCR Paul Langille, DEC Martin Lee Schoffstall, PSI Peter Lin, Vitalink John Lunny, TWG Carl Malamud Gary Malkin, FTP Software, Inc. Randy Mayhew, University of Tennessee at Knoxville Keith McCloghrie, Hughes LAN Systems Donna McMaster, David Systems Lynn Monsanto, Sun Dave Perkins, 3COM Jim Reinstedler, Ungerman Bass Anil Rijsinghani, DEC Kathy Rinehart, Arnold AFB Kary Robertson Marshall T. Rose, PSI (chair) L. Michael Sabo, NCSC Jon Saperia, DEC Greg Satz, cisco Martin Schoffstall, PSI John Seligson Steve Sherry, Xyplex Fei Shu, NEC Sam Sjogren, TGV Mark Sleeper, Sparta Lance Sprung Mike St.Johns Bob Stewart, Xyplex Emil Sturniold Kaj Tesink, Bellcore Geoff Thompson, Synoptics Dean Throop, Data General Bill Townsend, Xylogics Maurice Turcotte, Racal-Milgo Kannan Varadhou Sudhanshu Verma, HP Bill Versteeg, Network Research Corporation Warren Vik, Interactive Systems David Waitzman, BBN Steve Waldbusser, CMU Dan Wintringhan David Wood Wengyik Yeong, PSI Jeff Young, Cray Research SNMP Working Group [Page 68] RFC 1213 MIB-II March 1991 In addition, the comments of the following individuals are also acknolwedged: Craig A. Finseth, Minnesota Supercomputer Center, Inc. Jeffrey C. Honig, Cornell University Theory Center Philip R. Karn, Bellcore 8. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988. [2] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets," RFC 1065, TWG, August 1988. [3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets, RFC 1066, TWG, August 1988. [4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1098, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, April 1989. [6] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC 854, USC/Information Sciences Institute, May 1983. [7] Satz, G., "Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base", RFC 1162, cisco Systems, Inc., June 1990. [8] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [9] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [10] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988, Stanford, California. SNMP Working Group [Page 69] RFC 1213 MIB-II March 1991 [11] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer", RFC 1070, U of Wiscsonsin - Madison, U of Wiscsonsin - Madison, The Wollongong Group, February 1989. [12] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [13] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [14] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. 9. Security Considerations Security issues are not discussed in this memo. 10. Authors' Addresses Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 1225 Charleston Road Mountain View, CA 94043 Phone: (415) 966-7934 EMail: kzm@hls.com Marshall T. Rose Performance Systems International 5201 Great America Parkway Suite 3106 Santa Clara, CA 95054 Phone: +1 408 562 6222 EMail: mrose@psi.com X.500: rose, psi, us SNMP Working Group [Page 70] snmp-mibs-downloader-1.1/mibrfcs/rfc1227.txt0000644000000000000000000006106211402176071015562 0ustar Network Working Group M. Rose Request for Comments: 1227 Performance Systems International, Inc. May 1991 SNMP MUX Protocol and MIB Status of this Memo This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host. This is an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Table of Contents 1. Introduction .......................................... 1 2. Architecture .......................................... 2 3. Protocol .............................................. 3 3.1 Tricky Things ........................................ 3 3.1.1 Registration ....................................... 4 3.1.2 Removing Registration .............................. 4 3.1.3 Atomic Sets ........................................ 4 3.1.4 Variables in Requests .............................. 5 3.1.5 Request-ID ......................................... 5 3.1.6 The powerful get-next operator ..................... 5 3.2 Protocol Data Units .................................. 6 3.3 Mappings on Transport Service ........................ 8 3.3.1 Mapping onto the TCP ............................... 8 4. MIB for the SMUX ...................................... 9 5. Acknowledgements ...................................... 12 6. References ............................................ 12 7. Security Considerations................................ 13 8. Author's Address....................................... 13 1. Introduction On typical kernel/user systems, an agent speaking the SNMP [1] is often implemented as a user-process, that reads kernel variables in order to realize the Internet-standard MIB [2]. This approach works fine as long as all of the information needed by the SNMP agent resides in either the kernel or in stable storage (i.e., files). However, when other user-processes are employed to implement other Rose [Page 1] RFC 1227 SMUX May 1991 network services, such as routing protocols, communication between the SNMP agent and other processes is problematic. In order to solve this problem, a new protocol, the SNMP multiplexing (SMUX) protocol is introduced. When a user-process, termed a SMUX peer, wishes to export a MIB module, it initiates a SMUX association to the local SNMP agent, registers itself, and (later) fields management operations for objects in the MIB module. Carrying this approach to its fullest, it is possible to generalize the SNMP agent so that it knows about only the SNMP group of the Internet-standard MIB. All other portions of the Internet-standard MIB can be implemented by another process. This is quite useful, for example, when a computer manufacturer wishes to provide SNMP access for its operating system in binary form. In addition to defining the SMUX protocol, this document defines a MIB for the SMUX. Obviously, this MIB module must also be implemented in the local SNMP agent. 2. Architecture There are two approaches that can be taken when trying to integrate arbitrary MIB modules with the SNMP agent: request-response and cache-ahead. The request-response model simply propagates the SNMP requests received by the SNMP agent to the user process which exported the MIB module. The SMUX peer then performs the operation and returns a response. In turn, the SNMP agent propagates this response back to the network management station. The request-response model is said to be agent-driven since, after registration, the SNMP agent initiates all transactions. The cache-ahead model requires that the SMUX peer, after registration, periodically updates the SNMP agent with the subtree for the MIB module which has been registered. The SNMP agent, upon receiving an SNMP request for information retrieval, locally performs the operation, and returns a response to the network management station. (SNMP set requests are given immediately to the SMUX peer.) The cache-ahead model is said to be peer-driven since, after registration, the SMUX peer initiates all transactions. There are advantages and disadvantages to both approaches. As such, the architecture envisioned supports both models in the following fashion: the protocol between the SNMP agent and the SMUX peer is based on the request-response model. However, the SMUX peer, may itself be a user-process which employs the cache-ahead model with Rose [Page 2] RFC 1227 SMUX May 1991 other user-processes. Obviously, the SMUX peer which employs the cache-ahead model acts as a "firewall" for those user-processes which actually implement the managed objects in the given MIB module. Note that this document describes only the SMUX protocol, for the request-response model. Each SMUX peer is free to define a cache- ahead protocol specific for the application at hand. 3. Protocol The SMUX protocol is simple: the SNMP agent listens for incoming connections. Upon establishing a connection, the SMUX peer issues an OpenPDU to initialize the SMUX association. If the SNMP agent declines the association, it issues a closePDU and closes the connection. If the SNMP agent accepts the association, no response is issued by the SNMP agent. For each subtree defined in a MIB module that the SMUX peer wishes to register (or unregister), the SMUX peer issues a RReqPDU. When the SNMP agent receives such a PDU, it issues a corresponding RRspPDU. The SNMP agent returns RRspPDUs in the same order as the RReqPDUs were received. When the SMUX peer wishes to issue a trap, it issues an SNMP Trap- PDU. When the SNMP agent receives such a PDU, it propagates this to the network management stations that it is configured to send traps to. When the SNMP agent receives an SNMP GetRequest-PDU, GetNextRequest- PDU, or SetRequest-PDU which includes one or more variable-bindings within a subtree registered by a SMUX peer, the SNMP agent sends an equivalent SNMP PDU containing only those variables within the subtree registered by that SMUX peer. When the SMUX peer receives such a PDU, it applies the indicated operation and issues a corresponding SNMP GetResponse-PDU. The SNMP agent then correlates this result and propagates the resulting GetResponse-PDU to the network management station. When either the SNMP agent or the SMUX peer wishes to release the SMUX association, the ClosePDU is issued, the connection is closed, and all subtree registrations for that association are released. 3.1. Tricky Things Although straight-forward, there are a few nuances. Rose [Page 3] RFC 1227 SMUX May 1991 3.1.1. Registration Associated with each registration is an integer priority, from 0 to (2^31)-1. The lower the value, the higher the priority. Multiple SMUX peers may register the same subtree. However, they must do so at different priorities (i.e., a subtree and a priority uniquely identifies a SMUX peer). As such, if a SMUX peer wishes to register a subtree at a priority which is already taken, the SNMP agent repeatedly increments the integer value until an unused priority is found. When registering a subtree, the special priority -1 may be used, which selects the highest available priority. Of course, the SNMP agent may select an arbitrarily worse priority for a SMUX peer, based on local (configuration) information. Note that when a subtree is registered, the SMUX peer with the highest registration priority is exclusively consulted for all operations on that subtree. Further note that SNMP agents must enforce the "subtree mounting effect", which hides the registrations by other SMUX peers of objects within the subtree. For example, if a SMUX peer registered "sysDescr", and later another SMUX peer registered "system" (which scopes "sysDescr"), then all requests for "sysDescr" would be given to the latter SMUX peer. An SNMP agent should disallow any attempt to register above, at, or below, the SNMP and SMUX subtrees of the MIB. Other subtrees may be disallowed as an implementation-specific option. 3.1.2. Removing Registration A SMUX peer may remove registrations for only those subtrees which it has registered. If the priority given in the RReqPDU is -1, then the registration of highest priority is selected for deletion. Otherwise, only that registration with the precise priority is selected. 3.1.3. Atomic Sets A simple two-phase commit protocol is used between the SNMP agent and the SMUX peers. When an SNMP SetRequest-PDU is received, the SNMP agent determines which SMUX peers will participate in the transaction. For each of these peers, at least one SNMP SetRequest- PDU is sent, with only those variables of interest to that peer. Each SMUX peer must either accept or refuse the set operation, Rose [Page 4] RFC 1227 SMUX May 1991 without actually performing the operation. If the peer opts to accept, it sends back an SNMP GetResponse-PDU with an error-status of noError(0); otherwise, if the peer refuses to perform the operation, then an SNMP GetResponse-PDU is returned with a non-zero error- status. The SNMP agent examines all of the responses. If at least one SMUX peer refused the operation, then a SMUX SOutPDU is sent to each SMUX peer, with value rollback, telling the SMUX peer to discard any knowledge of the requested operation. Otherwise if all SMUX peers accepted the operation, then a SMUX SOutPDU is sent to each SMUX peer, with value commit, telling the SMUX peer to perform the operation. In either case, the SMUX peer does not generate a response to the SMUX SOutPDU. 3.1.4. Variables in Requests When constructing an SNMP GetRequest-PDU or GetNextRequest-PDU for a SMUX peer, the SNMP agent may send one, or more than one variable in a single request. In all cases, the SNMP agent should process each variable sequentially, and block accordingly when a SMUX peer is contacted. 3.1.5. Request-ID When the SNMP agent constructs an SNMP GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU, for a SMUX peer, the request_id field of the SNMP takes a special meaning: if an SNMP agent generates multiple PDUs for a SMUX peer, upon receipt of a single PDU from the network management station, then the request_id field of the PDUs sent to the SMUX peer must take the same value (which need bear no relationship to the value of the request_id field of the PDU originally received by the SNMP agent.) 3.1.6. The powerful get-next operator Each SMUX peer acts as though it contains the entire MIB when processing a SNMP GetNext-PDU from the SNMP agent. This means that the SNMP agent must check each variable returned in the SNMP GetResponse-PDU generated by the SMUX peer to ensure that each variable is still within the same registered subtree as caused the SNMP GetNext-PDU to be sent to that peer. For each variable which is not, the SNMP agent must include it in a SNMP GetNext-PDU to the peer for the succeeding registered subtree, until responses are available for all variables within their expected registered subtree. Rose [Page 5] RFC 1227 SMUX May 1991 3.2. Protocol Data Units The SMUX protocol data units are defined using Abstract Syntax Notation One (ASN.1) [3]: SMUX DEFINITIONS ::= BEGIN IMPORTS DisplayString, ObjectName FROM RFC1155-SMI PDUs FROM RFC1157-SNMP; -- tags for SMUX-specific PDUs are application-wide to -- avoid conflict with tags for current (and future) -- SNMP-generic PDUs SMUX-PDUs ::= CHOICE { open -- SMUX peer uses OpenPDU, -- immediately after TCP open close -- either uses immediately before TCP close ClosePDU, registerRequest -- SMUX peer uses RReqPDU, registerResponse -- SNMP agent uses RRspPDU, PDUs, -- note that roles are reversed: -- SNMP agent does get/get-next/set -- SMUX peer does get-response/trap commitOrRollback -- SNMP agent uses SOutPDU } -- open PDU -- currently only simple authentication OpenPDU ::= CHOICE { simple Rose [Page 6] RFC 1227 SMUX May 1991 SimpleOpen } SimpleOpen ::= [APPLICATION 0] IMPLICIT SEQUENCE { version -- of SMUX protocol INTEGER { version-1(0) }, identity -- of SMUX peer, authoritative OBJECT IDENTIFIER, description -- of SMUX peer, implementation-specific DisplayString, password -- zero length indicates no authentication OCTET STRING } -- close PDU ClosePDU ::= [APPLICATION 1] IMPLICIT INTEGER { goingDown(0), unsupportedVersion(1), packetFormat(2), protocolError(3), internalError(4), authenticationFailure(5) } -- insert PDU RReqPDU ::= [APPLICATION 2] IMPLICIT SEQUENCE { subtree ObjectName, priority -- the lower the better, "-1" means default INTEGER (-1..2147483647), operation Rose [Page 7] RFC 1227 SMUX May 1991 INTEGER { delete(0), -- remove registration readOnly(1), -- add registration, objects are RO readWrite(2) -- .., objects are RW } } RRspPDU ::= [APPLICATION 3] IMPLICIT INTEGER { failure(-1) -- on success the non-negative priority is returned } SOutPDU ::= [APPLICATION 4] IMPLICIT INTEGER { commit(0), rollback(1) } END 3.3. Mappings on Transport Service The SMUX protocol may be mapped onto any CO-mode transport service. At present, only one such mapping is defined. 3.3.1. Mapping onto the TCP When using the TCP to provide the transport-backing for the SMUX protocol, the SNMP agent listens on TCP port 199. Each SMUX PDU is serialized using the Basic Encoding Rules [4] and sent on the TCP. As ASN.1 objects are self-delimiting when encoding using the BER, no packetization protocol is required. Rose [Page 8] RFC 1227 SMUX May 1991 4. MIB for the SMUX The MIB objects for the SMUX are implemented by the local SNMP agent: SMUX-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises FROM RFC1155-SMI OBJECT-TYPE FROM RFC1212; unix OBJECT IDENTIFIER ::= { enterprises 4 } smux OBJECT IDENTIFIER ::= { unix 4 } smuxPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF SmuxPeerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The SMUX peer table." ::= { smux 1 } smuxPeerEntry OBJECT-TYPE SYNTAX SmuxPeerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the SMUX peer table." INDEX { smuxPindex } ::= { smuxPeerTable 1} SmuxPeerEntry ::= SEQUENCE { smuxPindex INTEGER, smuxPidentity OBJECT IDENTIFIER, smuxPdescription DisplayString, smuxPstatus INTEGER } smuxPindex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only Rose [Page 9] RFC 1227 SMUX May 1991 STATUS mandatory DESCRIPTION "An index which uniquely identifies a SMUX peer." ::= { smuxPeerEntry 1 } smuxPidentity OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The authoritative designation for a SMUX peer." ::= { smuxPeerEntry 2 } smuxPdescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A human-readable description of a SMUX peer." ::= { smuxPeerEntry 3 } smuxPstatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2), connecting(3) } ACCESS read-write STATUS mandatory DESCRIPTION "The type of SMUX peer. Setting this object to the value invalid(2) has the effect of invaliding the corresponding entry in the smuxPeerTable. It is an implementation- specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that correspond to entries not currently in use. Proper interpretation of such entries requires examination of the relative smuxPstatus object." ::= { smuxPeerEntry 4 } smuxTreeTable OBJECT-TYPE SYNTAX SEQUENCE OF SmuxTreeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The SMUX tree table." ::= { smux 2 } Rose [Page 10] RFC 1227 SMUX May 1991 smuxTreeEntry OBJECT-TYPE SYNTAX SmuxTreeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the SMUX tree table." INDEX { smuxTsubtree, smuxTpriority } ::= { smuxTreeTable 1} SmuxTreeEntry ::= SEQUENCE { smuxTsubtree OBJECT IDENTIFIER, smuxTpriority INTEGER, smuxTindex INTEGER, smuxTstatus INTEGER } smuxTsubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The MIB subtree being exported by a SMUX peer." ::= { smuxTreeEntry 1 } smuxTpriority OBJECT-TYPE SYNTAX INTEGER (0..'07fffffff'h) ACCESS read-only STATUS mandatory DESCRIPTION "The SMUX peer's priority when exporting the MIB subtree." ::= { smuxTreeEntry 2 } smuxTindex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The SMUX peer's identity." ::= { smuxTreeEntry 3 } smuxTstatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } Rose [Page 11] RFC 1227 SMUX May 1991 ACCESS read-write STATUS mandatory DESCRIPTION "The type of SMUX tree. Setting this object to the value invalid(2) has the effect of invaliding the corresponding entry in the smuxTreeTable. It is an implementation- specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that correspond to entries not currently in use. Proper interpretation of such entries requires examination of the relative smuxTstatus object." ::= { smuxTreeEntry 4 } END 5. Acknowledgements SMUX was designed one afternoon by these people: Jeffrey S. Case, UTK-CS James R. Davin, MIT-LCS Mark S. Fedor, PSI Jeffrey C. Honig, Cornell Louie A. Mamakos, UMD Michael G. Petry, UMD Yakov Rekhter, IBM Marshall T. Rose, PSI 6. References [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [2] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Performance Systems International and Hughes LAN Systems, May 1990. [3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. Rose [Page 12] RFC 1227 SMUX May 1991 [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990. 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Marshall T. Rose Performance Systems International, Inc. 5201 Great America Parkway Suite 3106 Santa Clara, CA 95054 Phone: +1 408 562 6222 EMail: mrose@psi.com X.500: rose, psi, us Rose [Page 13] snmp-mibs-downloader-1.1/mibrfcs/rfc1238.txt0000644000000000000000000017360511402176071015573 0ustar Network Working Group G. Satz Request for Comments: 1238 cisco Systems, Inc. Obsoletes: RFC 1162 June 1991 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Status of this Memo This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Table of Contents 1. The Network Management Framework....................... 1 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 2 3. Overview .............................................. 2 3.1 Textual Conventions .................................. 3 3.2 Changes from RFC 1162 ................................ 3 4. Definitions ........................................... 4 4.1 Textual Conventions .................................. 4 4.2 Groups in the CLNS MIB ............................... 4 4.3 The CLNP Group ....................................... 4 4.4 The CLNP Error Group ................................. 21 4.5 The ES-IS Group ...................................... 30 5. References ............................................ 31 6. Security Considerations ............................... 32 7. Author's Address....................................... 32 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. Satz [Page 1] RFC 1238 CLNS MIB June 1991 RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213, defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements. RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects 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) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 2.1. Format of Definitions Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [9]. 3. Overview The objects defined in this MIB module are be used when the ISO Connectionless-mode Network Protocol [10] and End System to Satz [Page 2] RFC 1238 CLNS MIB June 1991 Intermediate System [11] protocols are present. No assumptions are made as to what underlying protocol is being used to carry the SNMP. This memo uses the string encoding of [12] to textually describe OSI addresses. 3.1. Textual Conventions A new data type is introduced as a textual convention in this MIB document. This textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of this textual convention has no effect on either the syntax nor the semantics of any managed objects. The use of this is merely an artifact of the explanatory method used. Objects defined in terms of this methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate this textual convention which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. The ASN.1 type ClnpAddress is used to denote an OSI address. This consists of a string of octets. The first octet of the string contains a binary value in the range of 0..20, and indicates the the length in octets of the NSAP. Following the first octet, is the NSAP, expressed in concrete binary notation, starting with the most significant octet. A zero- length NSAP is used as a "special" address meaning "the default NSAP" (analogous to the IP address of 0.0.0.0). Such an NSAP is encoded as a single octet, containing the value 0. All other NSAPs are encoded in at least 4 octets. 3.2. Changes from RFC 1162 Features of this MIB include: (1) The managed objects in this document have been defined using the conventions defined in the Internet-standard SMI, as amended by the extensions specified in [9]. It must be emphasized that definitions made using these extensions are semantically identically to those in RFC 1162. (2) The PhysAddress textual convention from MIB-II has been introduced to represent media addresses. (3) The clnpRoutingDiscards, clnpRouteMetric5, and clnpRouteInfo objects have been defined. Satz [Page 3] RFC 1238 CLNS MIB June 1991 (4) The ClnpAddress type was mistakenly given a tag in RFC 1162. This error has been corrected. 4. Definitions CLNS-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, Counter FROM RFC1155-SMI PhysAddress FROM RFC-1213 OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [9] -- the CLNS MIB module clns OBJECT IDENTIFIER ::= { experimental 1 } -- textual conventions ClnpAddress ::= OCTET STRING (SIZE (1..21)) -- This data type is used to model NSAP addresses. -- groups in the CLNS MIB clnp OBJECT IDENTIFIER ::= { clns 1 } error OBJECT IDENTIFIER ::= { clns 2 } echo OBJECT IDENTIFIER ::= { clns 3 } es-is OBJECT IDENTIFIER ::= { clns 4 } -- the CLNP group -- Implementation of this group is recommended for all -- systems which implement the CLNP. Satz [Page 4] RFC 1238 CLNS MIB June 1991 clnpForwarding OBJECT-TYPE SYNTAX INTEGER { is(1), -- entity is an intermediate system -- entity is an end system and does es(2) -- not forward PDUs } ACCESS read-write STATUS mandatory DESCRIPTION "The indication of whether this entity is active as an intermediate or end system. Only intermediate systems will forward PDUs onward that are not addressed to them." ::= { clnp 1 } clnpDefaultLifeTime OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The default value inserted into the Lifetime field of the CLNP PDU header of PDUs sourced by this entity." ::= { clnp 2 } clnpInReceives OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input PDUs received from all connected network interfaces running CLNP, including errors." ::= { clnp 3 } clnpInHdrErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input PDUs discarded due to errors in the CLNP header, including bad checksums, version mismatch, lifetime exceeded, errors discovered in processing options, etc." ::= { clnp 4 } Satz [Page 5] RFC 1238 CLNS MIB June 1991 clnpInAddrErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input PDUs discarded because the NSAP address in the CLNP header's destination field was not a valid NSAP to be received at this entity. This count includes addresses not understood. For end systems, this is a count of PDUs which arrived with a destination NSAP which was not local." ::= { clnp 5 } clnpForwPDUs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input PDUs for which this entity was not the final destination and which an attempt was made to forward them onward." ::= { clnp 6 } clnpInUnknownNLPs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally-addressed PDUs successfully received but discarded because the network layer protocol was unknown or unsupported (e.g., not CLNP or ES-IS)." ::= { clnp 7 } clnpInUnknownULPs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally-addressed PDUs successfully received but discarded because the upper layer protocol was unknown or unsupported (e.g., not TP4)." ::= { clnp 8 } clnpInDiscards OBJECT-TYPE SYNTAX Counter Satz [Page 6] RFC 1238 CLNS MIB June 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The number of input CLNP PDUs for which no problems were encountered to prevent their continued processing, but were discarded (e.g., for lack of buffer space). Note that this counter does not include any PDUs discarded while awaiting re-assembly." ::= { clnp 9 } clnpInDelivers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input PDUs successfully delivered to the CLNS transport user." ::= { clnp 10 } clnpOutRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of CLNP PDUs which local CLNS user protocols supplied to CLNP for transmission requests. This counter does not include any PDUs counted in clnpForwPDUs." ::= { clnp 11 } clnpOutDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of output CLNP PDUs for which no other problem was encountered to prevent their transmission but were discarded (e.g., for lack of buffer space). Note this counter includes PDUs counted in clnpForwPDUs." ::= { clnp 12 } clnpOutNoRoutes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Satz [Page 7] RFC 1238 CLNS MIB June 1991 "The number of CLNP PDUs discarded because no route could be found to transmit them to their destination. This counter includes any PDUs counted in clnpForwPDUs." ::= { clnp 13 } clnpReasmTimeout OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The maximum number of seconds which received segments are held while they are awaiting reassembly at this entity." ::= { clnp 14 } clnpReasmReqds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP segments received which needed to be reassembled at this entity." ::= { clnp 15 } clnpReasmOKs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP PDUs successfully re-assembled at this entity." ::= { clnp 16 } clnpReasmFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of failures detected by the CLNP reassembly algorithm (for any reason: timed out, buffer size, etc)." ::= { clnp 17 } clnpSegOKs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Satz [Page 8] RFC 1238 CLNS MIB June 1991 DESCRIPTION "The number of CLNP PDUs that have been successfully segmented at this entity." ::= { clnp 18 } clnpSegFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP PDUs that have been discarded because they needed to be fragmented at this entity but could not." ::= { clnp 19 } clnpSegCreates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP PDU segments that have been generated as a result of segmentation at this entity." ::= { clnp 20 } clnpInOpts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP PDU segments that have been input with options at this entity." ::= { clnp 25 } clnpOutOpts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP PDU segments that have been generated with options by this entity." ::= { clnp 26 } clnpRoutingDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Satz [Page 9] RFC 1238 CLNS MIB June 1991 "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries." ::= { clnp 27 } -- the CLNP Interfaces table -- The CLNP interfaces table contains information on the -- entity's interfaces which are running the CLNP. clnpAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF ClnpAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of addressing information relevant to this entity's CLNP addresses. " ::= { clnp 21 } clnpAddrEntry OBJECT-TYPE SYNTAX ClnpAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The addressing information for one of this entity's CLNP addresses." INDEX { clnpAdEntAddr } ::= { clnpAddrTable 1 } ClnpAddrEntry ::= SEQUENCE { clnpAdEntAddr ClnpAddress, clnpAdEntIfIndex INTEGER, clnpAdEntReasmMaxSize INTEGER (0..65535) } clnpAdEntAddr OBJECT-TYPE SYNTAX ClnpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The CLNP address to which this entry's addressing Satz [Page 10] RFC 1238 CLNS MIB June 1991 information pertains." ::= { clnpAddrEntry 1 } clnpAdEntIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { clnpAddrEntry 2 } clnpAdEntReasmMaxSize OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The size of the largest CLNP PDU which this entity can re-assemble from incoming CLNP segmented PDUs received on this interface." ::= { clnpAddrEntry 3 } -- The CLNP Routing table -- The CLNP routing table contains an entry for each route -- known to the entity. clnpRoutingTable OBJECT-TYPE SYNTAX SEQUENCE OF ClnpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This entity's CLNP routing table." ::= { clnp 22 } clnpRouteEntry OBJECT-TYPE SYNTAX ClnpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A route to a particular destination." INDEX { clnpRouteDest } ::= { clnpRoutingTable 1 } Satz [Page 11] RFC 1238 CLNS MIB June 1991 ClnpRouteEntry ::= SEQUENCE { clnpRouteDest ClnpAddress, clnpRouteIfIndex INTEGER, clnpRouteMetric1 INTEGER, clnpRouteMetric2 INTEGER, clnpRouteMetric3 INTEGER, clnpRouteMetric4 INTEGER, clnpRouteNextHop ClnpAddress, clnpRouteType INTEGER, clnpRouteProto INTEGER, clnpRouteAge INTEGER, clnpRouteMetric5 INTEGER, clnpRouteInfo OBJECT IDENTIFIER } clnpRouteDest OBJECT-TYPE SYNTAX ClnpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The destination CLNP address of this route." ::= { clnpRouteEntry 1 } clnpRouteIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same as identified by the same value of ifIndex." ::= { clnpRouteEntry 2 } Satz [Page 12] RFC 1238 CLNS MIB June 1991 clnpRouteMetric1 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The primary routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1." ::= { clnpRouteEntry 3 } clnpRouteMetric2 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1." ::= { clnpRouteEntry 4 } clnpRouteMetric3 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1." ::= { clnpRouteEntry 5 } clnpRouteMetric4 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1." ::= { clnpRouteEntry 6 } Satz [Page 13] RFC 1238 CLNS MIB June 1991 clnpRouteNextHop OBJECT-TYPE SYNTAX ClnpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The CLNP address of the next hop of this route." ::= { clnpRouteEntry 7 } clnpRouteType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated route -- route to directly direct(3), -- connected (sub-)network -- route to a non-local remote(4) -- host/network/sub-network } ACCESS read-write STATUS mandatory DESCRIPTION "The type of route. Setting this object to the value invalid(2) has the effect of invaliding the corresponding entry in the clnpRoutingTable. That is, it effectively dissasociates the destination identified with said entry from the route identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant clnpRouteType object." ::= { clnpRouteEntry 8 } clnpRouteProto OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following -- non-protocol information -- e.g., manually local(2), -- configured entries Satz [Page 14] RFC 1238 CLNS MIB June 1991 -- set via a network netmgmt(3), -- management protocol -- similar to ipRouteProto but -- omits several IP-specific -- protocols is-is(9), ciscoIgrp(11), bbnSpfIgp(12), ospf(13), bgp(14) } ACCESS read-only STATUS mandatory DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { clnpRouteEntry 9 } clnpRouteAge OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned." ::= { clnpRouteEntry 10 } clnpRouteMetric5 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's clnpRouteProto value. If this metric is not used, its value should be set to -1." ::= { clnpRouteEntry 11 } clnpRouteInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER Satz [Page 15] RFC 1238 CLNS MIB June 1991 ACCESS read-only STATUS mandatory DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route's clnpRouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntatically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value." ::= { clnpRouteEntry 12 } -- the CLNP Address Translation table -- The Address Translation tables contain the CLNP address -- to physical address equivalences. Some interfaces do not -- use translation tables for determining address -- equivalences; if all interfaces are of this type, then the -- Address Translation table is empty, i.e., has zero -- entries. clnpNetToMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF ClnpNetToMediaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The CLNP Address Translation table used for mapping from CLNP addresses to physical addresses." ::= { clnp 23 } clnpNetToMediaEntry OBJECT-TYPE SYNTAX ClnpNetToMediaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry contains one CLNP address to `physical' address equivalence." INDEX { clnpNetToMediaIfIndex, clnpNetToMediaNetAddress } ::= { clnpNetToMediaTable 1 } ClnpNetToMediaEntry ::= SEQUENCE { clnpNetToMediaIfIndex INTEGER, Satz [Page 16] RFC 1238 CLNS MIB June 1991 clnpNetToMediaPhysAddress PhysAddress, clnpNetToMediaNetAddress ClnpAddress, clnpNetToMediaType INTEGER, clnpNetToMediaAge INTEGER, clnpNetToMediaHoldTime INTEGER } clnpNetToMediaIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { clnpNetToMediaEntry 1 } clnpNetToMediaPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-write STATUS mandatory DESCRIPTION "The media-dependent `physical' address." ::= { clnpNetToMediaEntry 2 } clnpNetToMediaNetAddress OBJECT-TYPE SYNTAX ClnpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The CLNP address corresponding to the media- dependent `physical' address." ::= { clnpNetToMediaEntry 3 } clnpNetToMediaType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4) } Satz [Page 17] RFC 1238 CLNS MIB June 1991 ACCESS read-write STATUS mandatory DESCRIPTION "The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the clnpNetToMediaTable. That is, it effectively dissassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant clnpNetToMediaType object." ::= { clnpNetToMediaEntry 4 } clnpNetToMediaAge OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The number of seconds since this entry was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the type of entry." ::= { clnpNetToMediaEntry 5 } clnpNetToMediaHoldTime OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The time in seconds this entry will be valid. Static entries should always report this field as -1." ::= { clnpNetToMediaEntry 6 } clnpMediaToNetTable OBJECT-TYPE SYNTAX SEQUENCE OF ClnpMediaToNetEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The CLNP Address Translation table used for Satz [Page 18] RFC 1238 CLNS MIB June 1991 mapping from physical addresses to CLNP addresses." ::= { clnp 24 } clnpMediaToNetEntry OBJECT-TYPE SYNTAX ClnpMediaToNetEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry contains on ClnpAddress to `physical' address equivalence." INDEX { clnpMediaToNetIfIndex, clnpMediaToNetPhysAddress } ::= { clnpMediaToNetTable 1 } ClnpMediaToNetEntry ::= SEQUENCE { clnpMediaToNetIfIndex INTEGER, clnpMediaToNetNetAddress ClnpAddress, clnpMediaToNetPhysAddress PhysAddress, clnpMediaToNetType INTEGER, clnpMediaToNetAge INTEGER, clnpMediaToNetHoldTime INTEGER } clnpMediaToNetIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { clnpMediaToNetEntry 1 } clnpMediaToNetAddress OBJECT-TYPE SYNTAX ClnpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The ClnpAddress corresponding to the media- Satz [Page 19] RFC 1238 CLNS MIB June 1991 dependent `physical' address." ::= { clnpMediaToNetEntry 2 } clnpMediaToNetPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-write STATUS mandatory DESCRIPTION "The media-dependent `physical' address." ::= { clnpMediaToNetEntry 3 } clnpMediaToNetType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4) } ACCESS read-write STATUS mandatory DESCRIPTION "The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the clnpMediaToNetTable. That is, it effectively dissassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant clnpMediaToNetType object." ::= { clnpMediaToNetEntry 4 } clnpMediaToNetAge OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The number of seconds since this entry was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the type of entry." Satz [Page 20] RFC 1238 CLNS MIB June 1991 ::= { clnpMediaToNetEntry 5 } clnpMediaToNetHoldTime OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The time in seconds this entry will be valid. Static entries should always report this field as -1." ::= { clnpMediaToNetEntry 6 } -- the CLNP Error group -- Implementation of this group is recommended for all -- systems which implement the CLNP Error protocol. clnpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP Error PDUs received by this entity." ::= { error 1 } clnpOutErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of CLNP Error PDUs sent by this entity." ::= { error 2 } clnpInErrUnspecs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unspecified CLNP Error PDUs received by this entity." ::= { error 3 } clnpInErrProcs OBJECT-TYPE SYNTAX Counter ACCESS read-only Satz [Page 21] RFC 1238 CLNS MIB June 1991 STATUS mandatory DESCRIPTION "The number of protocol procedure CLNP Error PDUs received by this entity." ::= { error 4 } clnpInErrCksums OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of checksum CLNP Error PDUs received by this entity." ::= { error 5 } clnpInErrCongests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of congestion drop CLNP Error PDUs received by this entity." ::= { error 6 } clnpInErrHdrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of header syntax CLNP Error PDUs received by this entity." ::= { error 7 } clnpInErrSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of segmentation disallowed CLNP Error PDUs received by this entity." ::= { error 8 } clnpInErrIncomps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of incomplete PDU CLNP Error PDUs Satz [Page 22] RFC 1238 CLNS MIB June 1991 received by this entity." ::= { error 9 } clnpInErrDups OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of duplicate option CLNP Error PDUs received by this entity." ::= { error 10 } clnpInErrUnreachDsts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unreachable destination CLNP Error PDUs received by this entity." ::= { error 11 } clnpInErrUnknownDsts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unknown destination CLNP Error PDUs received by this entity." ::= { error 12 } clnpInErrSRUnspecs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unspecified source route CLNP Error PDUs received by this entity." ::= { error 13 } clnpInErrSRSyntaxes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of source route syntax CLNP Error PDUs received by this entity." ::= { error 14 } Satz [Page 23] RFC 1238 CLNS MIB June 1991 clnpInErrSRUnkAddrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of source route unknown address CLNP Error PDUs received by this entity." ::= { error 15 } clnpInErrSRBadPaths OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of source route bad path CLNP Error PDUs received by this entity." ::= { error 16 } clnpInErrHops OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of hop count exceeded CLNP Error PDUs received by this entity." ::= { error 17 } clnpInErrHopReassms OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of hop count exceeded while reassembling CLNP Error PDUs received by this entity." ::= { error 18 } clnpInErrUnsOptions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported option CLNP Error PDUs received by this entity." ::= { error 19 } clnpInErrUnsVersions OBJECT-TYPE SYNTAX Counter Satz [Page 24] RFC 1238 CLNS MIB June 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The number of version mismatch CLNP Error PDUs received by this entity." ::= { error 20 } clnpInErrUnsSecurities OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported security option CLNP Error PDUs received by this entity." ::= { error 21 } clnpInErrUnsSRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported source route option CLNP Error PDUs received by this entity." ::= { error 22 } clnpInErrUnsRRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported record route option CLNP Error PDUs received by this entity." ::= { error 23 } clnpInErrInterferences OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of reassembly interference CLNP Error PDUs received by this entity." ::= { error 24 } clnpOutErrUnspecs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Satz [Page 25] RFC 1238 CLNS MIB June 1991 "The number of unspecified CLNP Error PDUs sent by this entity." ::= { error 25 } clnpOutErrProcs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of protocol procedure CLNP Error PDUs sent by this entity." ::= { error 26 } clnpOutErrCksums OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of checksum CLNP Error PDUs sent by this entity." ::= { error 27 } clnpOutErrCongests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of congestion drop CLNP Error PDUs sent by this entity." ::= { error 28 } clnpOutErrHdrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of header syntax CLNP Error PDUs sent by this entity." ::= { error 29 } clnpOutErrSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of segmentation disallowed CLNP Error PDUs sent by this entity." ::= { error 30 } Satz [Page 26] RFC 1238 CLNS MIB June 1991 clnpOutErrIncomps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of incomplete PDU CLNP Error PDUs sent by this entity." ::= { error 31 } clnpOutErrDups OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of duplicate option CLNP Error PDUs sent by this entity." ::= { error 32 } clnpOutErrUnreachDsts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unreachable destination CLNP Error PDUs sent by this entity." ::= { error 33 } clnpOutErrUnknownDsts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unknown destination CLNP Error PDUs sent by this entity." ::= { error 34 } clnpOutErrSRUnspecs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unspecified source route CLNP Error PDUs sent by this entity." ::= { error 35 } clnpOutErrSRSyntaxes OBJECT-TYPE SYNTAX Counter ACCESS read-only Satz [Page 27] RFC 1238 CLNS MIB June 1991 STATUS mandatory DESCRIPTION "The number of source route syntax CLNP Error PDUs sent by this entity." ::= { error 36 } clnpOutErrSRUnkAddrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of source route unknown address CLNP Error PDUs sent by this entity." ::= { error 37 } clnpOutErrSRBadPaths OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of source route bad path CLNP Error PDUs sent by this entity." ::= { error 38 } clnpOutErrHops OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of hop count exceeded CLNP Error PDUs sent by this entity." ::= { error 39 } clnpOutErrHopReassms OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of hop count exceeded while reassembling CLNP Error PDUs sent by this entity." ::= { error 40 } clnpOutErrUnsOptions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported option CLNP Error PDUs Satz [Page 28] RFC 1238 CLNS MIB June 1991 sent by this entity." ::= { error 41 } clnpOutErrUnsVersions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of version mismatch CLNP Error PDUs sent by this entity." ::= { error 42 } clnpOutErrUnsSecurities OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported security option CLNP Error PDUs sent by this entity." ::= { error 43 } clnpOutErrUnsSRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported source route option CLNP Error PDUs sent by this entity." ::= { error 44 } clnpOutErrUnsRRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of unsupported record route option CLNP Error PDUs sent by this entity." ::= { error 45 } clnpOutErrInterferences OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of reassembly interference CLNP Error PDUs sent by this entity." ::= { error 46 } Satz [Page 29] RFC 1238 CLNS MIB June 1991 -- the ES-IS group -- Implementation of this group is recommended for all -- systems which implement the End-System to Intermediate -- System protocol. esisESHins OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ESH PDUs received by this entity." ::= { es-is 1 } esisESHouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ESH PDUs sent by this entity." ::= { es-is 2 } esisISHins OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ISH PDUs received by this entity." ::= { es-is 3 } esisISHouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ISH PDUs sent by this entity." ::= { es-is 4 } esisRDUins OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of RDU PDUs received by this entity." ::= { es-is 5 } esisRDUouts OBJECT-TYPE SYNTAX Counter Satz [Page 30] RFC 1238 CLNS MIB June 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The number of RDU PDUs sent by this entity." ::= { es-is 6 } END 5. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988. [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989. [3] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990. [4] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990. [5] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance Systems International, and the MIT Laboratory for Computer Science, May 1990. [6] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, Hughes LAN Systems, Inc., Performance Systems International, March 1991. [7] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987. [8] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987. [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions, RFC 1212, Performance Systems International, Hughes LAN Systems, Satz [Page 31] RFC 1238 CLNS MIB June 1991 Inc., March 1991. [10] Information processing systems - Data Communications - Protocol for providing the Connectionless-mode Network Service and Provision of Underlying Service, International Organization for Standardization, International Standard 8473, May 1987. [11] End System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service (ISO 8473), International Draft Proposal 9542. [12] Kille, S., "A String Encoding of Presentation Address", Research Note RN/89/14, Department of Computer Science, University College London, February 1989. 6. Security Considerations Security issues are not discussed in this memo. 7. Author's Address: Greg Satz cisco Systems, Inc. 1350 Willow Road Menlo Park, CA 94025 Phone: (415) 326-1941 Email: Satz@CISCO.COM Satz [Page 32] snmp-mibs-downloader-1.1/mibrfcs/rfc1381.txt0000644000000000000000000021312511402176071015562 0ustar Network Working Group D. Throop Request for Comments: 1381 Data General Corporation F. Baker Advanced Computer Communications November 1992 SNMP MIB Extension for X.25 LAPB Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Link Layer of X.25, LAPB. The objects defined here, along with the objects in the "SNMP MIB Extension for the Packet Layer of X.25" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8], combine to allow management of an X.25 protocol stack. Table of Contents 1. The Network Management Framework ....................... 2 2. Objects ................................................ 2 2.1 Format of Definitions ................................. 3 3. Overview ............................................... 3 3.1 Informal overview ..................................... 3 3.2 Textual Conventions ................................... 4 3.3 Formal overview ....................................... 4 3.4 Tables ................................................ 5 3.5 Traps ................................................. 6 4. Object Definitions ..................................... 6 5. Appendix: Revision History ............................. 27 July 30, 1992 .......................................... 27 June 12, 1992 .......................................... 27 May 18, 1992 ........................................... 28 April 8, 1992 .......................................... 28 February 1992 .......................................... 28 October 1991 ........................................... 29 June 1991 .............................................. 30 April 1991 ............................................. 30 Throop & Baker [Page 1] RFC 1381 X.25 LAPB MIB November 1992 6. Acknowledgements ....................................... 30 7. References ............................................. 31 8. Security Considerations ................................ 33 9. Authors' Addresses ..................................... 33 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. These components give the rules for defining objects, the definitions of objects, and the protocol for manipulating objects. The network management framework structures objects in an abstract information tree. The branches of the tree name objects and the leaves of the tree contain the values manipulated to effect management. This tree is called the Management Information Base or MIB. The concepts of this tree are given in STD 16/RFC 1155 "The Structure of Management Information" or SMI [1]. The SMI defines the trunk of the tree and the types of objects used when defining the leaves. STD 16/RFC 1212, "Towards Concise MIB Definitions" [4], defines a more concise description mechanism that preserves all the principals of the SMI. The core MIB definitions for the Internet suite of protocols can be found in RFC 1156 [2] "Management Information Base for Network Management of TCP/IP-based internets". STD 17/RFC 1213 [5] defines MIB-II, an evolution of MIB-I with changes to incorporate implementation experience and new operational requirements. STD 15/RFC 1157 [3] defines the SNMP protocol itself. The protocol defines how to manipulate the objects in a remote MIB. The tree structure of the MIB allows new objects to be defined for the purpose of experimentation and evaluation. 2. Objects The definition of an object in the MIB requires an object name and type. Object names and types are defined using the subset of the Abstract Syntax Notation One (ASN.1) [6] defined in the SMI [1]. Objects are named using ASN.1 object identifiers, administratively assigned names, to specify object types. The object name, together with an optional object instance, uniquely identifies a specific instance of an object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to objects. Objects also have a syntax that defines the abstract data structure corresponding to that object type. The ASN.1 language [6] provides Throop & Baker [Page 2] RFC 1381 X.25 LAPB MIB November 1992 the primitives used for this purpose. The SMI [1] purposely restricts the ASN.1 constructs which may be used for simplicity and ease of implementation. The encoding of an object type simply describes how to represent an object using ASN.1 encoding rules [7], for purposes of dealing with the SNMP protocol. 2.1. Format of Definitions Section 4 contains the specification of all object types defined in this MIB module. The object definitions use the conventions given in the SMI [1] as amended by the concise MIB definitions [4]. 3. Overview 3.1. Informal overview This section describes how the objects defined below relate with other MIBs. This section is only informational to help understand how the pieces fit together. The objects defined below are to be used in conjunction with MIB-II and other MIBs such as the X.25 packet level MIB [9]. A system with a complete X.25 stack running over a synchronous line will have at least two interfaces in the ifTable defined in MIB-II. There will be an interface for LAPB and another interface for the packet layer of X.25. There will also be objects defined in the RS-232-like MIB for the physical sync line. Each software interface identifies the layer below it used to send and receive packets. The X.25 MIB object, x25InfoDataLinkId, specifies an instance of lapbAdmnIndex for the LAPB interface under that X.25. The LAPB object, lapbOperPortId, defined below, identifies an instance of the rs232PortIndex for the the Sync line used by LAPB. For X.25 running over LAPB over Ethernet, the lapbAdmnPortId would identify the instance of ifIndex for the Ethernet interface. Each X.25 subnetwork will have separate entries in the ifTable. Thus a system with two X.25 lines would have two ifTable entries for the two X.25 packet layers and two other entries for the two LAPB interfaces. Each X.25 Packet Layer MIB would identify the instance of the LAPB MIB below it. Each LAPB MIB would identify the Sync line below it. The system would also have two entries for rs232PortTable and rs232SyncPortTable for the two physical lines. Since the ifTable as defined in MIB-II is device independent, it doesn't have anything specific for any type of interface. The objects below define the LAPB specific information for an interface Throop & Baker [Page 3] RFC 1381 X.25 LAPB MIB November 1992 of type LAPB. Different LAPB interfaces can also be differentiated by matching the values of ifIndex with lapbAdmnIndex. 3.2. Textual Conventions Two new data types are introduced as a textual conventions in this MIB document. These textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of these textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. This MIB introduces the data types of: PositiveInteger ifIndexType 3.3. Formal overview Instances of the objects defined below represent attributes of a LAPB interface. LAPB interfaces are identified by an ifType object in the Internet-standard MIB [5] of lapb(16). For these interfaces, the value of the ifSpecific variable in the MIB-II [5] has the OBJECT IDENTIFIER value: lapb OBJECT IDENTIFIER ::= { transmission 16 } The relationship between a LAPB interface and an interface in the context of the Internet-standard MIB [5] is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined below. The objects defined below are defined in the context of ISO 7776 [10] and ISO 8885 [11]. Access to those documents maybe useful (but isn't essential) to understand the names and semantics of some objects. Where possible the object descriptions use the terminology of ISO 7776; for example, one commonly used term refers to the peer LAPB as the DCE/remote DTE. This terminology does not restrict the instrumented LAPB to function only as a DTE. This MIB maybe applied Throop & Baker [Page 4] RFC 1381 X.25 LAPB MIB November 1992 to a LAPB configured as either a DCE or a DTE. To the extent that some attributes defined in the Internet standard MIB [5] are applicable to LAPB, those objects have not been duplicated here. In some instances some clarification of how to apply those objects to LAPB has been given. Some objects defined below include a DEFVAL clause. This clause provides reasonable (but not mandatory) default values to use when creating these objects. This does not imply this MIB defines any mechanism for creating or deleting LAPB interfaces. The creation and deletion of the objects of this MIB depend on the implementation method for creating and deleting LAPB interfaces. The DEFVAL clause provides reasonable defaults to allow further extension of the MIB to define methods for creating and deleting LAPB interfaces without having to deprecate these objects for the lack of a DEFVAL clause. 3.4. Tables This extension adds four tables to the MIB. These tables are: lapbAdmnTable, lapbOperTable, lapbFlowTable, and lapbXidTable. The lapbAdmnTable provides objects for common parameters used by LAPB such as the T1 retransmission timer or the N2 retransmission counter. Changes to objects in this table need not affect a running interface but provides access to the values used to initialize an interface. These values are read-write. The lapbOperTable provides objects to determine the parameters actually in use by an interface. These objects are read only. The values currently in use maybe different from the lapbAdmnTable values if the lapbAdmnTable was changed after interface initialization or if XID negotiation selected different values. The lapbFlowTable provides objects that report how the LAPB interface performs. These are read-only objects used to monitor operation. The lapbXidTable is not required for systems that do not transmit XID frames. For systems that do transmit XID frames, this table provides the values for the fields of the XID frame that are not already present in the lapbAdmnTable. The objects in this table are read- write. Throop & Baker [Page 5] RFC 1381 X.25 LAPB MIB November 1992 3.5. Traps Since all LAPB interfaces have entries in the ifTable, significant changes in the state of the interface should send a linkUp or linkDown trap. Thus an interface that receives or sends a Frame Reject frame should send a linkDown trap. If the interface later comes back up, it should then send a linkUP trap. 4. Object Definitions RFC1381-MIB DEFINITIONS ::= BEGIN IMPORTS Counter FROM RFC1155-SMI transmission FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; -- LAPB MIB lapb OBJECT IDENTIFIER ::= { transmission 16 } PositiveInteger ::= INTEGER (0..2147483647) IfIndexType ::= INTEGER (1..2147483647) -- IfIndexType specifies an index object for a table -- with entries that match entries in the MIB-II ifTable. -- The value of the index for the table will match the -- ifIndex entry for same interface in the ifTable. -- The values of this object range from 1 to ifNumber -- inclusive. -- ########################################################### -- LAPB Admn Table -- ########################################################### -- Support of the lapbAdmnTable is mandatory for all -- agents of systems that implement LAPB. lapbAdmnTable OBJECT-TYPE SYNTAX SEQUENCE OF LapbAdmnEntry ACCESS not-accessible STATUS mandatory Throop & Baker [Page 6] RFC 1381 X.25 LAPB MIB November 1992 DESCRIPTION "This table contains objects that can be changed to manage a LAPB interface. Changing one of these parameters may take effect in the operating LAPB immediately or may wait until the interface is restarted depending on the details of the implementation. Most of the objects in this read-write table have corresponding read-only objects in the lapbOperTable that return the current operating value. The operating values may be different from these configured values if changed by XID negotiation or if a configured parameter was changed after the interface was started." ::= { lapb 1 } lapbAdmnEntry OBJECT-TYPE SYNTAX LapbAdmnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Configured parameter values for a specific LAPB." INDEX { lapbAdmnIndex } ::= { lapbAdmnTable 1 } LapbAdmnEntry ::= SEQUENCE { lapbAdmnIndex IfIndexType, lapbAdmnStationType INTEGER, lapbAdmnControlField INTEGER, lapbAdmnTransmitN1FrameSize PositiveInteger, lapbAdmnReceiveN1FrameSize PositiveInteger, lapbAdmnTransmitKWindowSize INTEGER, lapbAdmnReceiveKWindowSize INTEGER, lapbAdmnN2RxmitCount INTEGER, lapbAdmnT1AckTimer Throop & Baker [Page 7] RFC 1381 X.25 LAPB MIB November 1992 PositiveInteger, lapbAdmnT2AckDelayTimer PositiveInteger, lapbAdmnT3DisconnectTimer PositiveInteger, lapbAdmnT4IdleTimer PositiveInteger, lapbAdmnActionInitiate INTEGER, lapbAdmnActionRecvDM INTEGER } lapbAdmnIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the LAPB interface." ::= { lapbAdmnEntry 1 } lapbAdmnStationType OBJECT-TYPE SYNTAX INTEGER { dte (1), dce (2), dxe (3) } ACCESS read-write STATUS mandatory DESCRIPTION "Identifies the desired station type of this interface." REFERENCE "ISO 7776 section 3.1" DEFVAL { dte } ::= { lapbAdmnEntry 2 } lapbAdmnControlField OBJECT-TYPE SYNTAX INTEGER { modulo8 (1), modulo128 (2) } ACCESS read-write STATUS mandatory DESCRIPTION "The desired size of the sequence numbers used to number frames." REFERENCE "ISO 8885 Table 3, Name: HDLC Option - 10" DEFVAL { modulo8 } Throop & Baker [Page 8] RFC 1381 X.25 LAPB MIB November 1992 ::= { lapbAdmnEntry 3 } lapbAdmnTransmitN1FrameSize OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The default maximum N1 frame size desired in number of bits for a frame transmitted by this DTE. This excludes flags and 0 bits inserted for transparency." REFERENCE "ISO 8885 Table 3, Name: Information Field length" DEFVAL { 36000 } -- 4500 * 8; 802.5 Frame size ::= { lapbAdmnEntry 4 } lapbAdmnReceiveN1FrameSize OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The default maximum N1 frame size desired in number of bits for a frame the DCE/remote DTE transmits to this DTE. This excludes flags and 0 bits inserted for transparency." DEFVAL { 36000 } -- 4500 * 8; 802.5 Frame size ::= { lapbAdmnEntry 5 } lapbAdmnTransmitKWindowSize OBJECT-TYPE SYNTAX INTEGER (1..127) ACCESS read-write STATUS mandatory DESCRIPTION "The default transmit window size for this Interface. This is the maximum number of unacknowledged sequenced PDUs that may be outstanding from this DTE at any one time." REFERENCE "ISO 8885 Table 3, Name: Window size" DEFVAL { 7 } ::= { lapbAdmnEntry 6 } lapbAdmnReceiveKWindowSize OBJECT-TYPE SYNTAX INTEGER (1..127) ACCESS read-write STATUS mandatory DESCRIPTION "The default receive window size for this Interface. This is the maximum number of Throop & Baker [Page 9] RFC 1381 X.25 LAPB MIB November 1992 unacknowledged sequenced PDUs that may be outstanding from the DCE/remote DTE at any one time." REFERENCE "ISO 8885 Table 3, Name: Window size" DEFVAL { 7 } ::= { lapbAdmnEntry 7 } lapbAdmnN2RxmitCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The default N2 retry counter for this interface. This specifies the number of times a PDU will be resent after the T1 timer expires without an acknowledgement for the PDU." REFERENCE "ISO 8885 Table 3, Name: Retransmission Attempts" DEFVAL { 20 } ::= { lapbAdmnEntry 8 } lapbAdmnT1AckTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The default T1 timer for this interface. This specifies the maximum time in Milliseconds to wait for acknowledgment of a PDU." REFERENCE "ISO 8885 Table 3, Name: Acknowledgement timer" DEFVAL { 3000 } ::= { lapbAdmnEntry 9 } lapbAdmnT2AckDelayTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The default T2 timer for this interface. This specifies the maximum time in Milliseconds to wait before sending an acknowledgment for a sequenced PDU. A value of zero means there will be no delay in acknowledgement generation." REFERENCE "ISO 8885 Table 3, Throop & Baker [Page 10] RFC 1381 X.25 LAPB MIB November 1992 Name: Reply delay timer" DEFVAL { 0 } ::= { lapbAdmnEntry 10 } lapbAdmnT3DisconnectTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T3 timer for this interface. This specifies the time in Milliseconds to wait before considering the link disconnected. A value of zero indicates the link will be considered disconnected upon completion of the frame exchange to disconnect the link." REFERENCE "ISO 7776 section 5.7.1.3" DEFVAL { 60000 } ::= { lapbAdmnEntry 11 } lapbAdmnT4IdleTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T4 timer for this interface. This specifies the maximum time in Milliseconds to allow without frames being exchanged on the data link. A value of 2147483647 indicates no idle timer is being kept." REFERENCE "ISO 7776 section 5.7.1.4" DEFVAL { 2147483647 } ::= { lapbAdmnEntry 12 } lapbAdmnActionInitiate OBJECT-TYPE SYNTAX INTEGER { sendSABM (1), sendDISC (2), sendDM (3), none (4), other (5) } ACCESS read-write STATUS mandatory DESCRIPTION "This identifies the action LAPB will take to initiate link set-up." DEFVAL { sendSABM } ::= { lapbAdmnEntry 13 } Throop & Baker [Page 11] RFC 1381 X.25 LAPB MIB November 1992 lapbAdmnActionRecvDM OBJECT-TYPE SYNTAX INTEGER { sendSABM (1), sendDISC (2), other (3) } ACCESS read-write STATUS mandatory DESCRIPTION "This identifies the action LAPB will take when it receives a DM response." DEFVAL { sendSABM } ::= { lapbAdmnEntry 14 } -- ########################################################### -- LAPB operating parameters. -- ########################################################### -- Support of the lapbOperTable is mandatory for all -- agents of systems that implement LAPB. lapbOperTable OBJECT-TYPE SYNTAX SEQUENCE OF LapbOperEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains configuration information about interface parameters currently set in the interface. Many of these objects have corresponding objects in the lapbAdmnTable." ::= { lapb 2 } lapbOperEntry OBJECT-TYPE SYNTAX LapbOperEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Currently set parameter values for a specific LAPB." INDEX { lapbOperIndex } ::= { lapbOperTable 1 } LapbOperEntry ::= SEQUENCE { lapbOperIndex IfIndexType, lapbOperStationType Throop & Baker [Page 12] RFC 1381 X.25 LAPB MIB November 1992 INTEGER, lapbOperControlField INTEGER, lapbOperTransmitN1FrameSize PositiveInteger, lapbOperReceiveN1FrameSize PositiveInteger, lapbOperTransmitKWindowSize INTEGER, lapbOperReceiveKWindowSize INTEGER, lapbOperN2RxmitCount INTEGER, lapbOperT1AckTimer PositiveInteger, lapbOperT2AckDelayTimer PositiveInteger, lapbOperT3DisconnectTimer PositiveInteger, lapbOperT4IdleTimer PositiveInteger, lapbOperPortId OBJECT IDENTIFIER, lapbOperProtocolVersionId OBJECT IDENTIFIER } lapbOperIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the LAPB interface." ::= { lapbOperEntry 1 } lapbOperStationType OBJECT-TYPE SYNTAX INTEGER { dte (1), dce (2), dxe (3) } ACCESS read-only STATUS mandatory DESCRIPTION "Identifies the current operating station type of this interface. A value of dxe (3) indicates XID negotiation has not yet taken place." Throop & Baker [Page 13] RFC 1381 X.25 LAPB MIB November 1992 REFERENCE "ISO 7776 section 3.1" ::= { lapbOperEntry 2 } lapbOperControlField OBJECT-TYPE SYNTAX INTEGER { modulo8 (1), modulo128 (2) } ACCESS read-only STATUS mandatory DESCRIPTION "The current operating size of the sequence numbers used to number frames." REFERENCE "ISO 7776 section 3.3" ::= { lapbOperEntry 3 } lapbOperTransmitN1FrameSize OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The current operating N1 frame size used for the maximum number of bits in a frame this DTE can transmit. This excludes flags and 0 bits inserted for transparency." REFERENCE "ISO 7776 section 5.7.3" ::= { lapbOperEntry 4 } lapbOperReceiveN1FrameSize OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory -- See lapbOperTransmitN1FrameSize above DESCRIPTION "The current operating N1 frame size used for the maximum number of bits in a frame the DCE/remote DTE can transmit. This excludes flags and 0 bits inserted for transparency." ::= { lapbOperEntry 5 } lapbOperTransmitKWindowSize OBJECT-TYPE SYNTAX INTEGER (1..127) ACCESS read-only STATUS mandatory DESCRIPTION "The current PDU window size this Interface uses to transmit. This is the maximum Throop & Baker [Page 14] RFC 1381 X.25 LAPB MIB November 1992 number of unacknowledged sequenced PDUs that may be outstanding from this DTE at any one time." REFERENCE "ISO 7776 section 5.7.4" ::= { lapbOperEntry 6 } lapbOperReceiveKWindowSize OBJECT-TYPE SYNTAX INTEGER (1..127) ACCESS read-only STATUS mandatory DESCRIPTION "The current receive PDU window size for this Interface. This is the maximum number of unacknowledged sequenced PDUs that may be outstanding from the DCE/remote DTE at any one time." REFERENCE "ISO 7776 section 5.7.4" ::= { lapbOperEntry 7 } lapbOperN2RxmitCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The current N2 retry counter used for this interface. This specifies the number of times a PDU will be resent after the T1 timer expires without an acknowledgement for the PDU." REFERENCE "ISO 7776 section 5.7.2" ::= { lapbOperEntry 8 } lapbOperT1AckTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The current T1 timer for this interface. This specifies the maximum time in Milliseconds to wait for acknowledgment of a PDU." REFERENCE "ISO 7776 section 5.7.1.1" ::= { lapbOperEntry 9 } lapbOperT2AckDelayTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory Throop & Baker [Page 15] RFC 1381 X.25 LAPB MIB November 1992 DESCRIPTION "The current T2 timer for this interface. This specifies the maximum time in Milliseconds to wait before sending an acknowledgment for a sequenced PDU. A value of zero means there will be no delay in acknowledgement generation." REFERENCE "ISO 7776 section 5.7.1.2" ::= { lapbOperEntry 10 } lapbOperT3DisconnectTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The current T3 timer for this interface. This specifies the time in Milliseconds to wait before considering the link disconnected. A value of zero indicates the link will be considered disconnected upon completion of the frame exchange to disconnect the link." REFERENCE "ISO 7776 section 5.7.1.3" ::= { lapbOperEntry 11 } lapbOperT4IdleTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The current T4 timer for this interface. This specifies the maximum time in Milliseconds to allow without frames being exchanged on the data link. A value of 2147483647 indicates no idle timer is being kept." REFERENCE "ISO 7776 section 5.7.1.4" ::= { lapbOperEntry 12 } lapbOperPortId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "This object identifies an instance of the index object in the first group of objects in the MIB specific to the physical device or interface used to send and receive Throop & Baker [Page 16] RFC 1381 X.25 LAPB MIB November 1992 frames. If an agent does not support any such objects, it should return nullSpec OBJECT IDENTIFIER {0 0}." ::= { lapbOperEntry 13 } lapbOperProtocolVersionId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "This object identifies the version of the lapb protocol implemented by this interface." ::= { lapbOperEntry 14 } -- ########################################################### -- LAPB Flow Table -- ########################################################### -- Support of the lapbFlowTable is mandatory for all -- agents of systems that implement LAPB. lapbFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF LapbFlowEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table defines the objects recorded by LAPB to provide information about the traffic flow through the interface." ::= { lapb 3 } lapbFlowEntry OBJECT-TYPE SYNTAX LapbFlowEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The information regarding the effects of flow controls in LAPB." INDEX { lapbFlowIfIndex } ::= { lapbFlowTable 1 } LapbFlowEntry ::= SEQUENCE { lapbFlowIfIndex IfIndexType, lapbFlowStateChanges Counter, Throop & Baker [Page 17] RFC 1381 X.25 LAPB MIB November 1992 lapbFlowChangeReason INTEGER, lapbFlowCurrentMode INTEGER, lapbFlowBusyDefers Counter, lapbFlowRejOutPkts Counter, lapbFlowRejInPkts Counter, lapbFlowT1Timeouts Counter, lapbFlowFrmrSent OCTET STRING, lapbFlowFrmrReceived OCTET STRING, lapbFlowXidReceived OCTET STRING } lapbFlowIfIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the LAPB Interface." ::= { lapbFlowEntry 1 } lapbFlowStateChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of LAPB State Changes, including resets." ::= { lapbFlowEntry 2 } lapbFlowChangeReason OBJECT-TYPE SYNTAX INTEGER { notStarted (1), -- Initial state abmEntered (2), -- SABM or UA abmeEntered (3), -- SABME or UA abmReset (4), -- SABM in ABM abmeReset (5), -- SABME in ABME dmReceived (6), -- DM Response dmSent (7), -- DM sent discReceived (8), -- DISC Response discSent (9), -- DISC Sent Throop & Baker [Page 18] RFC 1381 X.25 LAPB MIB November 1992 frmrReceived (10), -- FRMR Received frmrSent (11), -- FRMR Sent n2Timeout (12), -- N2 Timer Expired other (13) } ACCESS read-only STATUS mandatory DESCRIPTION "The reason for the most recent incrementing of lapbFlowStateChanges. A DM or DISC frame generated to initiate link set-up does not alter this object. When the MIB-II object ifOperStatus does not have a value of testing, there exists a correlation between this object and ifOperStatus. IfOperStatus will have a value of up when this object contains: abmEntered, abmeEntered, abmReset, or abmeReset. IfOperStatus will have a value of down when this object has a value of notStarted, or dmReceived through n2Timeout. There is no correlation when this object has the value other." ::= { lapbFlowEntry 3 } lapbFlowCurrentMode OBJECT-TYPE SYNTAX INTEGER { disconnected (1), -- initial state or DISC received linkSetup (2), -- SABM sent frameReject (3), -- Invalid frame received and -- FRMR sent disconnectRequest (4), -- DISC sent informationTransfer (5), -- normal information transfer state -- SABM(E) sent and UA received, or -- SABM(E) received and UA sent rejFrameSent (6), -- invalid NS received and REJ sent waitingAcknowledgement (7), Throop & Baker [Page 19] RFC 1381 X.25 LAPB MIB November 1992 -- T1 expired and RR sent stationBusy (8), -- RNR sent remoteStationBusy (9), -- RNR received bothStationsBusy (10), -- RNR received and RNR sent waitingAckStationBusy (11), -- T1 expired, RNR sent waitingAckRemoteBusy (12), -- T1 expired, RNR received waitingAckBothBusy (13), -- T1 expired, RNR sent, -- and RNR received rejFrameSentRemoteBusy (14), -- REJ sent and RNR received xidFrameSent (15), -- XID frame sent error (16), -- An error state other than -- a one defined above other (17) -- A state not listed above } ACCESS read-only STATUS mandatory DESCRIPTION "The current condition of the conversation." ::= { lapbFlowEntry 4 } lapbFlowBusyDefers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this device was unable to transmit a frame due to a perceived remote busy condition. Busy conditions can Throop & Baker [Page 20] RFC 1381 X.25 LAPB MIB November 1992 result from the receipt of an RNR from the remote device, the lack of valid sequence number space (window saturation), or other conditions." ::= { lapbFlowEntry 5 } lapbFlowRejOutPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of REJ or SREJ frames sent by this station." ::= { lapbFlowEntry 6 } lapbFlowRejInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of REJ or SREJ frames received by this station." ::= { lapbFlowEntry 7 } lapbFlowT1Timeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times a re-transmission was effected by the T1 Timer expiring." ::= { lapbFlowEntry 8 } lapbFlowFrmrSent OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..7)) ACCESS read-only STATUS mandatory DESCRIPTION "The Information Field of the FRMR most recently sent. If no FRMR has been sent (the normal case) or the information isn't available, this will be an OCTET STRING of zero length." REFERENCE "ISO 7776 Section 4.3.9, tables 7 and 8" ::= { lapbFlowEntry 9 } lapbFlowFrmrReceived OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..7)) Throop & Baker [Page 21] RFC 1381 X.25 LAPB MIB November 1992 ACCESS read-only STATUS mandatory DESCRIPTION "The Information Field of the FRMR most recently received. If no FRMR has been received (the normal case) or the information isn't available, this will be an OCTET STRING of zero length." REFERENCE "ISO 7776 Section 4.3.9, tables 7 and 8" ::= { lapbFlowEntry 10 } lapbFlowXidReceived OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8206)) ACCESS read-only STATUS mandatory DESCRIPTION "The Information Field of the XID frame most recently received. If no XID frame has been received, this will be an OCTET STRING of zero length." REFERENCE "ISO 8885" ::= { lapbFlowEntry 11 } -- ########################################################### -- LAPB XID Table -- ########################################################### -- Support for the lapbXidTable is mandatory for all agents -- of systems that have a LAPB implementation using XID -- negotiation. Agents of systems without XID negotiation -- support should not implement this table. lapbXidTable OBJECT-TYPE SYNTAX SEQUENCE OF LapbXidEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table defines values to use for XID negotiation that are not found in the lapbAdmnTable. This table is optional for implementations that don't support XID and mandatory for implementations that do initiate XID negotiation." ::= { lapb 4 } lapbXidEntry OBJECT-TYPE SYNTAX LapbXidEntry Throop & Baker [Page 22] RFC 1381 X.25 LAPB MIB November 1992 ACCESS not-accessible STATUS mandatory DESCRIPTION "XId negotiation parameter values for a specific LAPB." INDEX { lapbXidIndex } ::= { lapbXidTable 1 } LapbXidEntry ::= SEQUENCE { lapbXidIndex IfIndexType, lapbXidAdRIdentifier OCTET STRING, lapbXidAdRAddress OCTET STRING, lapbXidParameterUniqueIdentifier OCTET STRING, lapbXidGroupAddress OCTET STRING, lapbXidPortNumber OCTET STRING, lapbXidUserDataSubfield OCTET STRING } lapbXidIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the LAPB interface." ::= { lapbXidEntry 1 } lapbXidAdRIdentifier OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the Address Resolution Identifier. A zero length string indicates no Identifier value has been assigned." REFERENCE "ISO 8885 Table 2, Name: Identifier" DEFVAL { ''h } ::= { lapbXidEntry 2 } lapbXidAdRAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) Throop & Baker [Page 23] RFC 1381 X.25 LAPB MIB November 1992 ACCESS read-write STATUS mandatory DESCRIPTION "The value of the Address Resolution Address. A zero length string indicates no Address value has been assigned." REFERENCE "ISO 8885 Table 2, Name: Address" DEFVAL { ''h } ::= { lapbXidEntry 3 } lapbXidParameterUniqueIdentifier OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the parameter unique Identifier. A zero length string indicates no Unique identifier value has been assigned." REFERENCE "ISO 8885 Table 3, Name: Identifier" DEFVAL { ''h } ::= { lapbXidEntry 4 } lapbXidGroupAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the parameter Group address. A zero length string indicates no Group address value has been assigned." REFERENCE "ISO 8885 Table 3, Name: Group address" DEFVAL { ''h } ::= { lapbXidEntry 5 } lapbXidPortNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The port number assigned for this link. A zero length string indicates no local port number identifier has been assigned." REFERENCE "ISO 8885 Table 3, Name: Port number" DEFVAL { ''h } ::= { lapbXidEntry 6 } lapbXidUserDataSubfield OBJECT-TYPE Throop & Baker [Page 24] RFC 1381 X.25 LAPB MIB November 1992 SYNTAX OCTET STRING (SIZE (0..8206)) ACCESS read-write STATUS mandatory DESCRIPTION "A user data subfield, if any, to be transmitted in an XID frame. A zero length frame indicates no user data subfield has been assigned. The octet string should include both the User data identifier and User data field as shown in Figures 1 and 4." REFERENCE "ISO 8885 section 4.3" DEFVAL { ''h } ::= { lapbXidEntry 7 } -- ########################################################### -- LAPB protocol versions -- ########################################################### lapbProtocolVersion OBJECT IDENTIFIER ::= { lapb 5 } lapbProtocolIso7776v1986 OBJECT IDENTIFIER ::= { lapbProtocolVersion 1 } lapbProtocolCcittV1980 OBJECT IDENTIFIER ::= { lapbProtocolVersion 2 } lapbProtocolCcittV1984 OBJECT IDENTIFIER ::= { lapbProtocolVersion 3 } -- The following describes some of the MIB-II interface -- objects and their relationship with the objects in this -- MIB extension. -- ifDescr: describes the interface. It should include -- identification information for the physical line and a -- description of the network. For connections to PDNs, -- it should name the PDN. -- ifMtu: the maximum number of octets an upper layer can -- pass to this interface as a single frame. -- ifSpeed: Throop & Baker [Page 25] RFC 1381 X.25 LAPB MIB November 1992 -- ifAdminStatus: -- ifOperStatus: -- ifLastChange: the last time the state of the interface -- changed. A reset is considered an instantaneous change to -- the ndm state and back to abm or abme. This will be the -- last time that lapbFlowChangeReason and lapbFlowChanges -- changed. -- ifInOctets: contains the number of octets -- received from the peer LAPB including FCS. -- ifInUcastPkts: contains the number of I-frames delivered -- by this interface to a higher layer interface. -- ifInDiscards: contains the number of received -- frames discarded because of internal conditions -- (such as lack of buffering). -- ifInErrors: contains the number of Invalid frames received. -- This does not have any relationship with the number REJ, -- or RNR frames sent or received. -- ifInUnknownProtos: contains the number of frames -- that were correct but were dropped because they -- were inappropriate for the current state. This -- includes an invalid Poll bit, an unknown address, -- or other condition such as an RNR when connection -- not established. This also includes the number of -- DISC or other frames that were ignored because the -- link was not established and this interface was not -- configured to perform link setup on that type frame. -- ifOutOctets: number of octets sent to peer including -- FCS octets. -- ifOutUcastPkts: number of I-frames received from -- a higher layer for transmission to peer. -- ifOutDiscards: number of frames to be sent that were -- dropped due to internal conditions such as buffering etc. -- ifOutErrors: number of transmissions that failed -- due to errors or were considered invalid by the receiver. -- This does not have any relationship with the number REJ, -- or RNR frames sent or received. Throop & Baker [Page 26] RFC 1381 X.25 LAPB MIB November 1992 -- ifOutQLen: number of frames waiting to be transmitted. -- This MIB does not provide any support for: -- Multilink procedure (MLP) in ISO 7776 section 6 -- LLC Pbit timer -- LLC REJ timer -- LLC Busy State Timer 7.8.1.4 -- ########################################################### END 5. Appendix: Revision History July 30, 1992 The July revision of this document (Editor's Internal Reference 2.10) incorporated the comments of the SNMP directorate. The ifIndexType textual convention was added and used as the type for all index objects. The enumeration xidDetection of the lapbAdmnStationType was changed to dxe to be consistent with other similar enumerations. Conformance statements were added at before every table as ASN.1 comments. June 12, 1992 The June 12, 1992 revision of this document (Editor's Internal Reference 2.9) incorporated some clarifications and updated the status. The range on PositiveInteger was changed to start at 0 rather than 1. The syntax of lapbXidIndex was changed to PositiveInteger. A value of dxe was added to lapbOperStationType. The range of lapbAdmnN2RxmitCount was change to (0..65535). The definition of ifInOctets, ifInUcastPkts, ifInErrors, ifInUnknownProtos, ifOutOctets, and ifoutUcastPkts was clarified. Throop & Baker [Page 27] RFC 1381 X.25 LAPB MIB November 1992 May 18, 1992 The May 18, 1992 revision of this document (Editor's Internal Reference 2.8) incorporated the following changes: The states of lapbFlowCurrentMode were redefined. The default value for lapbAdmnControlField was changed from module8 to modulo8. April 8, 1992 The April 8, 1992 revision of this document (Editor's Internal Reference 2.4) incorporated the following changes: All reference comments in the MIB were moved to the REFERENCE field of the OBJECT-TYPE macro. A type of PositiveInteger was introduced and used for common integer values including all timers. This effectively made the maximum value for timers 2147483646 milliseconds. The type of the frame size was changed to positiveInteger. The reference to ISO 7776 has been broadened to say the MIB descriptions use the terminology of ISO 7776. A comment was added to the overview section discussing creation and deletion of tables. The objects in the lapbParmTable and lapbDefTable were redistributed to create a lapbOperTable, a lapbAdmnTable, and a lapbXidTable. The lapbParmTable and lapbDefTable were deleted. Objects were included in the Admn table for t3 and t4. An object identifier was added to identify the protocol version. A DEFVAL clause was added for all writable objects. Some more overview text was included. February 1992 The February 1992 revision of this document (Editor's Internal Reference 1.17) incorporated the following changes: The name was changed from HDLC to LAPB. This change was made because other flavors of HDLC such as LAPD, SDLC, and raw HDLC framing, are different enough that this MIB will not adequately Throop & Baker [Page 28] RFC 1381 X.25 LAPB MIB November 1992 manage them. The Historical Perspective section at the beginning of the document has been replaced with a more concise Network Management Framework section. The name lapbParmKWindowSize was changed to lapbParmTransmitKWindowSize and the object lapbParmReceiveKWindowSize was added. This change was made because section 5.7.4 of ISO 7776 and Table 3 of ISO 8885 have provisions for different values for the transmit and receive window size. The name lapbParmN1FrameSize was changed to lapbParmTransmitN1FrameSize and the object lapbParmReceiveN1FrameSize was added. This change was made because section 5.7.3 of ISO 7776 and Table 3 of ISO 8886 have provisions for different values for the transmit and receive maximum frame size. The object lapbParmPortIndex was deleted and the description of lapbParmPortId was changed. The object lapbParmPortId now identifies an instance of the index object for the MIB of the physical device or interface below LAPB. The units for the timers were changed to Milliseconds to be consistent with ISO 8885; see table 3. The objects lapbParamT2AckDelayTimer and lapbParamT3DisconnectTimer both allow values of 0 to indicate the timer is not being used. The object lapbParamT4IdleTimer has a value to indicate timer not in use. The object lapbFlowXidReceived was added to the flow table. The lapbDefTable was added. Ranges and sizes were added for all INTEGERs and OCTET STRINGs that didn't have them. October 1991 The October 1991 revision of this document basically changed the name from LAPB to HDLC to make the objects more appropriate for a broader range of uses. A number of minor changes were made to bring the objects in line with established conventions. These changes are as follows. Throop & Baker [Page 29] RFC 1381 X.25 LAPB MIB November 1992 The enumerated values of hdlcParmStationType were renumbered from 0 and 1 to 1 and 2. The object hdlcFlowBusyDefer was renamed hdlcFlowBusyDefers. The object hdlcFlowRejSent was rename hdlcFlowRejOutPkts. The object hdlcFlowRejReceived was renamed hdlcFlowRejInPkts. June 1991 The June revision of this document incorporated much of the E-mail discussion of the first draft. In particular it replaced the lapbStatTable (and all contents) with the lapbFlowTable. April 1991 The April 24 version of this document was the first release. At that time this document was basically a bunch of objects synthesized from various vendor MIBs and a quick reading of ISO 7776 [10]. On first reading it appeared to instrument too many LAPB normal functions and too few exceptional conditions. The lapbStatTable was too long and needed to be redone. 6. Acknowledgements This document was produced by the x25mib working group: Fred Baker, ACC Art Berggreen, ACC Frank Bieser Gary Bjerke, Tandem Bill Bowman, HP Christopher Bucci, Datability Charles Carvalho, ACC Jeff Case, Snmp Research Angela Chen, HP Carson Cheung, BNR Tom Daniel, Spider Systems Chuck Davin, MIT Billy Durham, Honeywell Richard Fox, Synoptics Doug Geller, Data General Herve Goguely, LIR Corp Andy Goldthorpe, british-telecom Walter D. Guilarte David Gurevich Steve Huston, Process Software Corporation Throop & Baker [Page 30] RFC 1381 X.25 LAPB MIB November 1992 Jon Infante, ICL Frank Kastenholz, Clearpoint Zbigniew Kielczewski, Eicon Cheryl Krupezak, Georgia Tech Mats Lindstrom, Diab Data AB Andrew Malis, BBN Evan McGinnis, 3Com Gary (G.P.)Mussar, BNR Chandy Nilakantan, 3Com Randy Pafford, Data General Ragnar Paulson, The Software Group Limited Dave Perkins, Synoptics Walter Pinkarschewsky, DEC Karen Quidley, Data General Chris Ranch, Novell Paul S. Rarey, DHL Systems Inc. Jim Roche, Newbridge Research Philippe Roger, LIR Corp. Timon Sloane Mike Shand, DEC Brad Steina, Microcom Bob Stewart, Xyplex Tom Sullivan, Data General Rodney Thayer, Sable Technology Corporation Mark Therieau, Microcom Jane Thorn, Data General Dean Throop, Data General Maurice Turcotte, Racal Datacom Mike Zendels, Data General In addition, the comments of the following individuals are also acknowledged: Keith McCloghrie 7. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Throop & Baker [Page 31] RFC 1381 X.25 LAPB MIB November 1992 Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [5] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Performance Systems International, March 1991. [6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [7] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [8] Stewart, B., Editor, "Definitions of Managed Objects for RS-232- like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992. [9] Throop, D., Editor, "SNMP MIB extension for the Packet Layer of X.25", RFC 1382, Data General Corporation, November 1992. [10] "Information processing systems - Data communication - High-level data link control procedure - Description of the X.25 LAPB- compatible DTE data link procedures", International Organization for Standardization, International Standard 7776, December 1986. [11] "Information technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - General purpose XID frame information field contents and format", International Organization for Standardization, International Standard 8885. Throop & Baker [Page 32] RFC 1381 X.25 LAPB MIB November 1992 8. Security Considerations Security issues are not discussed in this memo. 9. Authors' Addresses Dean D. Throop Data General Corporation 62 Alexander Dr. Research Triangle Park, NC 27709 Phone: (919)248-8421 EMail: throop@dg-rtp.dg.com Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, CA 93101 Phone: (805) 685-4455 EMail: fbaker@acc.com While the working group has completed discussion of this document, comments are still welcome. Please send comments to the x25mib working group at: x25mib@dg-rtp.dg.com Throop & Baker [Page 33] snmp-mibs-downloader-1.1/mibrfcs/rfc1382.txt0000644000000000000000000045442511402176071015575 0ustar Network Working Group D. Throop, Editor Request for Comments: 1382 Data General Corporation November 1992 SNMP MIB Extension for the X.25 Packet Layer Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Packet Layer of X.25. The objects defined here, along with the objects in the "SNMP MIB Extension for LAPB" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8], combine to allow management of an X.25 protocol stack. Table of Contents 1. The Network Management Framework ....................... 2 2. Objects ................................................ 2 2.1 Format of Definitions ................................. 3 3. Overview ............................................... 3 3.1 Informal Overview ..................................... 3 3.2 Textual Conventions ................................... 4 3.3 Structure of MIB ...................................... 4 3.4 Tables ................................................ 5 3.5 Table Usage ........................................... 6 3.6 Conformance ........................................... 6 4. Object Definitions ..................................... 7 5. Appendix: Revision History ............................. 62 July 30 1992 ........................................... 62 June 26 1992 ........................................... 62 June 1992 .............................................. 63 April 1992 ............................................. 63 February 1992 .......................................... 65 October 1991 ........................................... 65 June 1991 .............................................. 66 April 1991 ............................................. 66 6. Acknowledgements ....................................... 66 Throop [Page 1] RFC 1382 X.25 Packet Layer MIB November 1992 7. References ............................................. 67 8. Security Considerations ................................ 68 9. Author's Address ....................................... 69 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. These components give the rules for defining objects, the definitions of objects, and the protocol for manipulating objects. The network management framework structures objects in an abstract information tree. The branches of the tree name objects and the leaves of the tree contain the values manipulated to effect management. This tree is called the Management Information Base or MIB. The concepts of this tree are given in STD 16/RFC 1155, "The Structure of Management Information" or SMI [1]. The SMI defines the trunk of the tree and the types of objects used when defining the leaves. STD 16/RFC 1212, "Towards Concise MIB Definitions" [4], defines a more concise description mechanism that preserves all the principals of the SMI. The core MIB definitions for the Internet suite of protocols can be found in RFC 1156 [2] "Management Information Base for Network Management of TCP/IP-based internets". STD 17/RFC 1213 [5] defines MIB-II, an evolution of MIB-I with changes to incorporate implementation experience and new operational requirements. STD 15/RFC 1157 [3] defines the SNMP protocol itself. The protocol defines how to manipulate the objects in a remote MIB. The tree structure of the MIB allows new objects to be defined for the purpose of experimentation and evaluation. 2. Objects The definition of an object in the MIB requires an object name and type. Object names and types are defined using the subset of Abstract Syntax Notation One (ASN.1) [6] defined in the SMI [1]. Objects are named using ASN.1 object identifiers, administratively assigned names, to specify object types. The object name, together with an optional object instance, uniquely identifies a specific instance of an object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to objects. Objects also have a syntax that defines the abstract data structure corresponding to that object type. The ASN.1 language [6] provides the primitives used for this purpose. The SMI [1] purposely Throop [Page 2] RFC 1382 X.25 Packet Layer MIB November 1992 restricts the ASN.1 constructs which may be used for simplicity and ease of implementation. The encoding of an object type simply describes how to represent an object using ASN.1 encoding rules [7], for purposes of dealing with the SNMP protocol. 2.1. Format of Definitions Section 4 contains the specification of all object types defined in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in "Towards Concise MIB Definitions" [4]. 3. Overview 3.1. Informal Overview This section describes how the objects defined below relate with other MIBs. This section is only informational to help understand how the pieces fit together. The objects defined below are used in conjunction with MIB-II and other MIBs such as the LAPB MIB [9]. A system with a complete X.25 stack running over a synchronous line will have at least two interfaces in the ifTable defined in MIB-II. There will be an interface for LAPB and another interface for the packet layer of X.25. There will also be objects defined in the RS-232-like MIB for the physical sync line. Each software interface identifies the layer below it used to send and receive packets. The X.25 MIB object, defined below, x25OperDataLinkId, specifies an instance of lapbAdmnIndex for the LAPB interface under that X.25. The LAPB object, lapbOperPortId, identifies an instance of the rs232PortIndex for the the Sync line used by LAPB. For X.25 running over LAPB over Ethernet, the lapbOperPortId would identify the instance of ifIndex for the Ethernet interface. Each X.25 subnetwork will have separate entries in the ifTable. Thus a system with two X.25 lines would have two ifTable entries for the two X.25 packet layers and two other entries for the two LAPB interfaces. Each X.25 Packet Layer MIB would identify the instance of the LAPB MIB for the interface below it. Each LAPB MIB would identify the Sync line below it. The system would also have two entries in the rs232PortTable and rs232SyncPortTable for the two physical lines. Since the ifTable as defined in MIB-II is device independent, it doesn't have anything specific for any type of interface. The Throop [Page 3] RFC 1382 X.25 Packet Layer MIB November 1992 objects below define the X.25 packet layer specific information for an interface of type X.25. Different X.25 interfaces can also be differentiated by matching the values of ifIndex with x25AdmnIndex. 3.2. Textual Conventions This MIB introduces a new data type as a textual convention for use with X.25. This textual convention enhances the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of such textual conventions has no effect on either the syntax nor the semantics of any managed objects. These conventions are merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. This MIB introduces the data type of: X121Address 3.3. Structure of MIB Instances of the objects defined below represent attributes of an X.25 Packet Layer interface. At present these interfaces are identified by an ifType object in the Internet-standard MIB-II [5] of: ddn-x25(4), and rfc887-x25(5). For these interfaces, the value of the ifSpecific variable in the MIB-II [5] has the OBJECT IDENTIFIER value: x25 OBJECT IDENTIFIER ::= { transmission 5 } The objects defined below are similar to those defined in a draft ISO document for X.25 management [11]. Some object definitions also reference the ISO specification for X.25 [10] to specify the section that will give the reader additional information about the object. Access to those documents maybe useful (but isn't essential) to understand the names and semantics of some objects. The similarity of these objects with the ISO objects minimizes the instrumentation required by those systems that support both OSI and TCP/IP management protocols. Throop [Page 4] RFC 1382 X.25 Packet Layer MIB November 1992 Since the objects defined here are extensions to the Internet Standard MIB [2] and thus also an extension of the second version, MIB-II [5], the objects defined here explicitly do not duplicate objects defined in existing standards. In some instances clarification of how to apply those objects has been given. The relationship between an X.25 Packet Layer interface and an interface in the context of the Internet-standard MIB [5] is one-to- one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined below. 3.4. Tables The objects below form several tables. These tables are: x25AdmnTable x25OperTable x25StatTable x25ChannelTable x25CircuitTable x25ClearedCircuitTable x25CallParmTable The x25AdmnTable defines objects for the parameters of an X.25 interface which the administrator can read and set. These objects are used at interface initialization time to start the interface. Once the interface has started, changes to the objects in the Administration table may not take affect until the interface is re- initialized. The x25OperTable defines objects that report the current parameters used by a running interface. These objects are read-only. The x25StatTable defines objects that report operational statistics for an X.25 interface. These are read-only counters of events that occurred at the interface. The x25ChannelTable defines objects to allow the administrator to manage the division of channel numbers. The x25CircuitTable defines objects that return information about existing X.25 circuits. These entries result from calls placed or answered by the PLE or from PVCs. The x25ClearedCircuitTable contains objects for recording the termination information from circuits that cleared abnormally. Throop [Page 5] RFC 1382 X.25 Packet Layer MIB November 1992 The x25CallParmTable defines the call parameters used to call other systems. This table contains call parameter entries which are referenced by other tables. For example, the x25AdmnTable has one object that identifies the entry in the table for the default PLE parameters. The x25CircuitTable has one object that identifies the entry in the x25CallParmTable for the parameters in use by that circuit. Other MIBs may also reference entries to identify call parameters to use to make X.25 calls. 3.5. Table Usage Different tables provide different functions. The administrator sets the starting X.25 parameters in the x25AdmnTable for the X.25 PLE; these objects include a reference to the x25CallParmTable entry to identify the default call parameters for the PLE. Once all the parameters are set, the administrator initializes the interface. As part of initializing the interface, the operating parameters are copied into the interface from the x25AdmnTable; these parameters are viewable by getting the objects in the x25OperTable. (The interface maybe started by setting the value of ifAdminStatus to up.) If any PVCs are configured, their parameters can be set in the the x25CircuitTable before initializing the interface; this should be done in conjunction with configuring higher layer entities to use the PVCs via the MIBs for those entities. Once the PLE completes initialization, it makes additional entries in the x25circuitTable for calls placed or answered. When a circuit is cleared, the status of the entry for the circuit is set to closed and, if the clear is abnormal, an entry will also be made in the x25ClearedCircuitTable. An entry in the x25CircuitTable with a status of closed maybe deleted by the agent at its convenience. A closed entry will always be reused at the time the PLE re-allocates the channel number of the entry for another call. The call parameters used for a circuit can be found by looking in the x25CircuitTable and following the x25CircuitCallParamId pointer to the entry in the x25CallParmTable that contains the parameters. There are no mechanisms in the X.25 MIB for telling the PLE to place an X.25 call. Such mechanisms belong in the MIBs for the higher layer entities that use the X.25 circuits. 3.6. Conformance All the objects defined here are mandatory. To claim conformance with this MIB an implementation must support all objects. However some objects pertain to features that are optional. There are values defined for those objects that indicate the implementation does not support the optional feature. The agent for such an implementation Throop [Page 6] RFC 1382 X.25 Packet Layer MIB November 1992 must support reading the object and return the value that indicates the optional feature isn't supported and reject set requests to change the object. Some optional features have more than one object that pertain to it (window rotation has a timer, a count, and a counter for timer runouts). In such case, any object which indicates the optional feature isn't supported is sufficient to indicate the feature isn't supported and the values of the other objects relative to that feature are undefined. 4. Object Definitions RFC1382-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 DisplayString, transmission FROM RFC1213-MIB TRAP-TYPE FROM RFC-1215 EntryStatus FROM RFC1271-MIB PositiveInteger, IfIndexType FROM RFC1381-MIB; x25 OBJECT IDENTIFIER ::= { transmission 5 } -- Support of the X25 subtree and all subtrees under it -- is mandatory for all agents of system that implement X.25. X121Address ::= OCTET STRING (SIZE(0..17)) -- 0 to 17 bytes in length containing the ASCII -- characters [0-9], each octet contains one digit -- of the address. -- ########################################################### -- X.25 Administration Table -- ########################################################### x25AdmnTable OBJECT-TYPE Throop [Page 7] RFC 1382 X.25 Packet Layer MIB November 1992 SYNTAX SEQUENCE OF X25AdmnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains the administratively set configuration parameters for an X.25 Packet Level Entity (PLE). Most of the objects in this table have corresponding objects in the x25OperTable. This table contains the values as last set by the administrator. The x25OperTable contains the values actually in use by an X.25 PLE. Changing an administrative value may or may not change a current operating value. The operating value may not change until the interface is restarted. Some implementations may change the values immediately upon changing the administrative table. All implementations are required to load the values from the administrative table when initializing a PLE." ::= { x25 1 } x25AdmnEntry OBJECT-TYPE SYNTAX X25AdmnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entries of x25AdmnTable." INDEX { x25AdmnIndex } ::= { x25AdmnTable 1 } X25AdmnEntry ::= SEQUENCE { x25AdmnIndex IfIndexType, x25AdmnInterfaceMode INTEGER, x25AdmnMaxActiveCircuits INTEGER, x25AdmnPacketSequencing INTEGER, x25AdmnRestartTimer PositiveInteger, x25AdmnCallTimer PositiveInteger, Throop [Page 8] RFC 1382 X.25 Packet Layer MIB November 1992 x25AdmnResetTimer PositiveInteger, x25AdmnClearTimer PositiveInteger, x25AdmnWindowTimer PositiveInteger, x25AdmnDataRxmtTimer PositiveInteger, x25AdmnInterruptTimer PositiveInteger, x25AdmnRejectTimer PositiveInteger, x25AdmnRegistrationRequestTimer PositiveInteger, x25AdmnMinimumRecallTimer PositiveInteger, x25AdmnRestartCount INTEGER, x25AdmnResetCount INTEGER, x25AdmnClearCount INTEGER, x25AdmnDataRxmtCount INTEGER, x25AdmnRejectCount INTEGER, x25AdmnRegistrationRequestCount INTEGER, x25AdmnNumberPVCs INTEGER, x25AdmnDefCallParamId OBJECT IDENTIFIER, x25AdmnLocalAddress X121Address, x25AdmnProtocolVersionSupported OBJECT IDENTIFIER } x25AdmnIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the X.25 Interface." ::= { x25AdmnEntry 1 } x25AdmnInterfaceMode OBJECT-TYPE SYNTAX INTEGER { Throop [Page 9] RFC 1382 X.25 Packet Layer MIB November 1992 dte (1), dce (2), dxe (3) } ACCESS read-write STATUS mandatory DESCRIPTION "Identifies DCE/DTE mode in which the interface operates. A value of dxe indicates the mode will be determined by XID negotiation." REFERENCE "10733 5.9 interfaceMode" ::= { x25AdmnEntry 2 } x25AdmnMaxActiveCircuits OBJECT-TYPE SYNTAX INTEGER (0..4096) ACCESS read-write STATUS mandatory DESCRIPTION "The maximum number of circuits this PLE can support; including PVCs." REFERENCE "10733 5.9 maxActiveCircuits; See ISO 8208, Section 3.7" ::= { x25AdmnEntry 3 } x25AdmnPacketSequencing OBJECT-TYPE SYNTAX INTEGER { modulo8 (1), modulo128 (2) } ACCESS read-write STATUS mandatory DESCRIPTION "The modulus of the packet sequence number space." REFERENCE "10733 extendedPacketSequencing; See ISO 8208 Section 7.1.1" ::= { x25AdmnEntry 4 } x25AdmnRestartTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T20 restart timer in milliseconds." REFERENCE "10733 5.9 restartTime See ISO 8208 Section 4.1, table 26" ::= { x25AdmnEntry 5 } Throop [Page 10] RFC 1382 X.25 Packet Layer MIB November 1992 x25AdmnCallTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T21 Call timer in milliseconds." REFERENCE "10733 callTime; See ISO 8208 Section 5.2.1, table 26" ::= { x25AdmnEntry 6 } x25AdmnResetTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T22 Reset timer in milliseconds." REFERENCE "10733 resetTime; See ISO 8208 Section 8.1, table 26" ::= { x25AdmnEntry 7 } x25AdmnClearTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T23 Clear timer in milliseconds." REFERENCE "10733 clearTime; See ISO 8208 Section 5.5.1, table 26" ::= { x25AdmnEntry 8 } x25AdmnWindowTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T24 window status transmission timer in milliseconds. A value of 2147483647 indicates no window timer in use." REFERENCE "10733 5.10.1 windowTime (opt); See ISO 8208 Section 11.2.2, table 26" ::= { x25AdmnEntry 9 } x25AdmnDataRxmtTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T25 data retransmission timer in Throop [Page 11] RFC 1382 X.25 Packet Layer MIB November 1992 milliseconds. A value of 2147483647 indicates no data retransmission timer in use." REFERENCE "10733 5.10.1 dataRetransmissionTime (opt); See ISO 8208 Section 11.2.1, table 26" ::= { x25AdmnEntry 10 } x25AdmnInterruptTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T26 interrupt timer in milliseconds. A value of 2147483647 indicates no interrupt timer in use." REFERENCE "10733 interruptTime; See ISO 8208 Section 6.8.1, table 26" ::= { x25AdmnEntry 11 } x25AdmnRejectTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T27 Reject retransmission timer in milliseconds. A value of 2147483647 indicates no reject timer in use." REFERENCE "10733 5.10.1 dataRejectTime (opt); See ISO 8208 Section 13.4.1, table 26" ::= { x25AdmnEntry 12 } x25AdmnRegistrationRequestTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The T28 registration timer in milliseconds. A value of 2147483647 indicates no registration timer in use." REFERENCE "10733 5.8.1 registrationRequestTime (opt) See ISO 8208 Section 13.1.1.1, table 26" ::= { x25AdmnEntry 13 } x25AdmnMinimumRecallTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION Throop [Page 12] RFC 1382 X.25 Packet Layer MIB November 1992 "Minimum time interval between unsuccessful call attempts in milliseconds." REFERENCE "10733 5.9 minimum RecallTimer" ::= { x25AdmnEntry 14 } x25AdmnRestartCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The R20 restart retransmission count." REFERENCE "10733 5.9 restartCount; See ISO 8208 Section 4.1, table 27" ::= { x25AdmnEntry 15 } x25AdmnResetCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The r22 Reset retransmission count." REFERENCE "10733 resetCount; See section ISO 8208 8.1, table 27" ::= { x25AdmnEntry 16 } x25AdmnClearCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The r23 Clear retransmission count." REFERENCE "10733 clearCount; See ISO 8208 Section 5.5.1, table 27" ::= { x25AdmnEntry 17 } x25AdmnDataRxmtCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The R25 Data retransmission count. This value is irrelevant if the x25AdmnDataRxmtTimer indicates no timer in use." REFERENCE "10733 5.10.1 dataRetransmissionCount (opt) See ISO 8208 Section 11.2.1, table 27" ::= { x25AdmnEntry 18 } Throop [Page 13] RFC 1382 X.25 Packet Layer MIB November 1992 x25AdmnRejectCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The R27 reject retransmission count. This value is irrelevant if the x25AdmnRejectTimer indicates no timer in use." REFERENCE "10733 5.10.1 dataRejectCount (opt)" ::= { x25AdmnEntry 19 } x25AdmnRegistrationRequestCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The R28 Registration retransmission Count. This value is irrelevant if the x25AdmnRegistrationRequestTimer indicates no timer in use." REFERENCE "10733 5.8.1 registrationRequestCount (opt); See ISO 8208 Section 13.1.1.1, table 27" ::= { x25AdmnEntry 20 } x25AdmnNumberPVCs OBJECT-TYPE SYNTAX INTEGER (0..4096) ACCESS read-write STATUS mandatory DESCRIPTION "The number of PVC configured for this PLE. The PVCs use channel numbers from 1 to this number." ::= { x25AdmnEntry 21 } x25AdmnDefCallParamId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "This identifies the instance of the x25CallParmIndex for the entry in the x25CallParmTable which contains the default call parameters for this PLE." ::= { x25AdmnEntry 22 } x25AdmnLocalAddress OBJECT-TYPE SYNTAX X121Address Throop [Page 14] RFC 1382 X.25 Packet Layer MIB November 1992 ACCESS read-write STATUS mandatory DESCRIPTION "The local address for this PLE subnetwork. A zero length address maybe returned by PLEs that only support PVCs." REFERENCE "10733 5.9 localDTEAddress" ::= { x25AdmnEntry 23 } x25AdmnProtocolVersionSupported OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "Identifies the version of the X.25 protocol this interface should support. Object identifiers for common versions are defined below in the x25ProtocolVersion subtree." REFERENCE "10733 5.9 protocolVersionSupported" ::= { x25AdmnEntry 24 } -- ########################################################### -- X.25 Operational Table -- ########################################################### x25OperTable OBJECT-TYPE SYNTAX SEQUENCE OF X25OperEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The operation parameters in use by the X.25 PLE." ::= { x25 2 } x25OperEntry OBJECT-TYPE SYNTAX X25OperEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entries of x25OperTable." INDEX { x25OperIndex } ::= { x25OperTable 1 } X25OperEntry ::= SEQUENCE { x25OperIndex IfIndexType, x25OperInterfaceMode Throop [Page 15] RFC 1382 X.25 Packet Layer MIB November 1992 INTEGER, x25OperMaxActiveCircuits INTEGER, x25OperPacketSequencing INTEGER, x25OperRestartTimer PositiveInteger, x25OperCallTimer PositiveInteger, x25OperResetTimer PositiveInteger, x25OperClearTimer PositiveInteger, x25OperWindowTimer PositiveInteger, x25OperDataRxmtTimer PositiveInteger, x25OperInterruptTimer PositiveInteger, x25OperRejectTimer PositiveInteger, x25OperRegistrationRequestTimer PositiveInteger, x25OperMinimumRecallTimer PositiveInteger, x25OperRestartCount INTEGER, x25OperResetCount INTEGER, x25OperClearCount INTEGER, x25OperDataRxmtCount INTEGER, x25OperRejectCount INTEGER, x25OperRegistrationRequestCount INTEGER, x25OperNumberPVCs INTEGER, x25OperDefCallParamId OBJECT IDENTIFIER, x25OperLocalAddress X121Address, x25OperDataLinkId OBJECT IDENTIFIER, x25OperProtocolVersionSupported OBJECT IDENTIFIER } Throop [Page 16] RFC 1382 X.25 Packet Layer MIB November 1992 x25OperIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the X.25 interface." ::= { x25OperEntry 1 } x25OperInterfaceMode OBJECT-TYPE SYNTAX INTEGER { dte (1), dce (2), dxe (3) } ACCESS read-only STATUS mandatory DESCRIPTION "Identifies DCE/DTE mode in which the interface operates. A value of dxe indicates the role will be determined by XID negotiation at the Link Layer and that negotiation has not yet taken place." REFERENCE "10733 5.9 interfaceMode" ::= { x25OperEntry 2 } x25OperMaxActiveCircuits OBJECT-TYPE SYNTAX INTEGER (0..4096) ACCESS read-only STATUS mandatory DESCRIPTION "Maximum number of circuits this PLE can support." REFERENCE "10733 5.9 maxActiveCircuits See ISO 8208, Section 3.7" ::= { x25OperEntry 3 } x25OperPacketSequencing OBJECT-TYPE SYNTAX INTEGER { modulo8 (1), modulo128 (2) } ACCESS read-only STATUS mandatory DESCRIPTION "The modulus of the packet sequence number space." REFERENCE "10733 extendedPacketSequencing; See ISO 8208 Section 7.1.1" Throop [Page 17] RFC 1382 X.25 Packet Layer MIB November 1992 ::= { x25OperEntry 4 } x25OperRestartTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T20 restart timer in milliseconds." REFERENCE "10733 5.9 restartTime; See ISO 8208 Section 4.1, table 26" ::= { x25OperEntry 5 } x25OperCallTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T21 Call timer in milliseconds." REFERENCE "10733 callTime; See ISO 8208 Section 5.2.1, table 26" ::= { x25OperEntry 6 } x25OperResetTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T22 Reset timer in milliseconds." REFERENCE "10733 resetTime; See ISO 8208 Section 8.1, table 26" ::= { x25OperEntry 7 } x25OperClearTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T23 Clear timer in milliseconds." REFERENCE "10733 clearTime; See ISO 8208 Section 5.5.1, table 26" ::= { x25OperEntry 8 } x25OperWindowTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T24 window status transmission timer Throop [Page 18] RFC 1382 X.25 Packet Layer MIB November 1992 milliseconds. A value of 2147483647 indicates no window timer in use." REFERENCE "10733 5.10.1 windowTime (opt); See ISO 8208 Section 11.2.2, table 26" ::= { x25OperEntry 9 } x25OperDataRxmtTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T25 Data Retransmission timer in milliseconds. A value of 2147483647 indicates no data retransmission timer in use." REFERENCE "10733 5.10.1 dataRetransmissionTime (opt); See ISO 8208 Section 11.2.1, table 26" ::= { x25OperEntry 10 } x25OperInterruptTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T26 Interrupt timer in milliseconds. A value of 2147483647 indicates interrupts are not being used." REFERENCE "10733 interruptTime; See ISO 8208 Section 6.8.1, table 26" ::= { x25OperEntry 11 } x25OperRejectTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The T27 Reject retransmission timer in milliseconds. A value of 2147483647 indicates no reject timer in use." REFERENCE "10733 5.10.1 dataRejectTime (opt); See ISO 8208 Section 13.4.1, table 26" ::= { x25OperEntry 12 } x25OperRegistrationRequestTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION Throop [Page 19] RFC 1382 X.25 Packet Layer MIB November 1992 "The T28 registration timer in milliseconds. A value of 2147483647 indicates no registration timer in use." REFERENCE "10733 5.8.1 registrationRequestTime (opt); See ISO 8208 Section 13.1.1.1, table 26" ::= { x25OperEntry 13 } x25OperMinimumRecallTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "Minimum time interval between unsuccessful call attempts in milliseconds." REFERENCE "10733 5.9 minimum RecallTimer" ::= { x25OperEntry 14 } x25OperRestartCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The R20 restart retransmission count." REFERENCE "10733 5.9 restartCount See ISO 8208 Section 4.1, table 27" ::= { x25OperEntry 15 } x25OperResetCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The r22 Reset retransmission count." REFERENCE "10733 resetCount; See section ISO 8208 8.1, table 27" ::= { x25OperEntry 16 } x25OperClearCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The r23 Clear retransmission count." REFERENCE "10733 clearCount; See ISO 8208 Section 5.5.1, table 27" ::= { x25OperEntry 17 } x25OperDataRxmtCount OBJECT-TYPE Throop [Page 20] RFC 1382 X.25 Packet Layer MIB November 1992 SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The R25 Data retransmission count. This value is undefined if the x25OperDataRxmtTimer indicates no timer in use." REFERENCE "10733 5.10.1 dataRetransmissionCount (opt); See ISO 8208 Section 11.2.1, table 27" ::= { x25OperEntry 18 } x25OperRejectCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The R27 reject retransmission count. This value is undefined if the x25OperRejectTimer indicates no timer in use." REFERENCE "10733 5.10.1 dataRejectCount (opt)" ::= { x25OperEntry 19 } x25OperRegistrationRequestCount OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The R28 Registration retransmission Count. This value is undefined if the x25OperREgistrationRequestTimer indicates no timer in use." REFERENCE "10733 5.8.1 registrationRequestCount (opt); See ISO 8208 Section 13.1.1.1, table 27" ::= { x25OperEntry 20 } x25OperNumberPVCs OBJECT-TYPE SYNTAX INTEGER (0..4096) ACCESS read-only STATUS mandatory DESCRIPTION "The number of PVC configured for this PLE. The PVCs use channel numbers from 1 to this number." ::= { x25OperEntry 21 } x25OperDefCallParamId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER Throop [Page 21] RFC 1382 X.25 Packet Layer MIB November 1992 ACCESS read-only STATUS mandatory DESCRIPTION "This identifies the instance of the x25CallParmIndex for the entry in the x25CallParmTable that contains the default call parameters for this PLE." ::= { x25OperEntry 22 } x25OperLocalAddress OBJECT-TYPE SYNTAX X121Address ACCESS read-only STATUS mandatory DESCRIPTION "The local address for this PLE subnetwork. A zero length address maybe returned by PLEs that only support PVCs." REFERENCE "10733 5.9 localDTEAddress" ::= { x25OperEntry 23 } x25OperDataLinkId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "This identifies the instance of the index object in the first table of the most device specific MIB for the interface used by this PLE." ::= { x25OperEntry 24 } x25OperProtocolVersionSupported OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "Identifies the version of the X.25 protocol this interface supports. Object identifiers for common versions are defined below in the x25ProtocolVersion subtree." REFERENCE "10733 5.9 protocolVersionSupported" ::= { x25OperEntry 25 } -- MIB-II also provides: -- ifDescr: -- On an X.25 interface this must include sufficient Throop [Page 22] RFC 1382 X.25 Packet Layer MIB November 1992 -- information to enable the system's administrator -- to determine the appropriate configuration -- information on a system having multiple X.25 -- subnetworks. -- ifType: ddn-x25 or rfc877-x25 -- an interface of type ddn-x25 will use an algorithm to -- translate between X.121 address and IP addresses. -- An interface of type rfc877-x25 will use a -- configuration table to translate between X.121 -- addresses and IP addresses. -- ifMtu: the maximum PDU a higher layer can pass to X.25 or -- receive from X.25 -- ifSpeed: -- This will be the value of the local clock for this line. -- A value of zero indicates external clocking. -- ifAdminStatus: -- ifOperStatus -- ifLastChange -- ########################################################### -- X.25 Statistics Table -- ########################################################### x25StatTable OBJECT-TYPE SYNTAX SEQUENCE OF X25StatEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Statistics information about this X.25 PLE." ::= { x25 3 } x25StatEntry OBJECT-TYPE SYNTAX X25StatEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entries of the x25StatTable." INDEX { x25StatIndex } ::= { x25StatTable 1 } Throop [Page 23] RFC 1382 X.25 Packet Layer MIB November 1992 X25StatEntry ::= SEQUENCE { x25StatIndex IfIndexType, x25StatInCalls Counter, x25StatInCallRefusals Counter, x25StatInProviderInitiatedClears Counter, x25StatInRemotelyInitiatedResets Counter, x25StatInProviderInitiatedResets Counter, x25StatInRestarts Counter, x25StatInDataPackets Counter, x25StatInAccusedOfProtocolErrors Counter, x25StatInInterrupts Counter, x25StatOutCallAttempts Counter, x25StatOutCallFailures Counter, x25StatOutInterrupts Counter, x25StatOutDataPackets Counter, x25StatOutgoingCircuits Gauge, x25StatIncomingCircuits Gauge, x25StatTwowayCircuits Gauge, x25StatRestartTimeouts Counter, x25StatCallTimeouts Counter, x25StatResetTimeouts Counter, x25StatClearTimeouts Counter, x25StatDataRxmtTimeouts Counter, x25StatInterruptTimeouts Counter, x25StatRetryCountExceededs Throop [Page 24] RFC 1382 X.25 Packet Layer MIB November 1992 Counter, x25StatClearCountExceededs Counter } x25StatIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the X.25 interface." ::= { x25StatEntry 1 } x25StatInCalls OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of incoming calls received." ::= { x25StatEntry 2 } x25StatInCallRefusals OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of incoming calls refused. This includes calls refused by the PLE and by higher layers. This also includes calls cleared because of restricted fast select." ::= { x25StatEntry 3 } x25StatInProviderInitiatedClears OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of clear requests with a cause code other than DTE initiated." REFERENCE "10733 providerInitiatedDisconnect" ::= { x25StatEntry 4 } x25StatInRemotelyInitiatedResets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of reset requests received with Throop [Page 25] RFC 1382 X.25 Packet Layer MIB November 1992 cause code DTE initiated." REFERENCE "10733 remotelyInitiatedResets" ::= { x25StatEntry 5 } x25StatInProviderInitiatedResets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of reset requests received with cause code other than DTE initiated." REFERENCE "10733 ProviderInitiatedResets" ::= { x25StatEntry 6 } x25StatInRestarts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of remotely initiated (including provider initiated) restarts experienced by the PLE excluding the restart associated with bringing up the PLE interface. This only counts restarts received when the PLE already has an established connection with the remove PLE." REFERENCE "10733 5.9 remotelyInitiatedRestarts" ::= { x25StatEntry 7 } x25StatInDataPackets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of data packets received." REFERENCE "10733 5.9 dataPacketsReceived." ::= { x25StatEntry 8 } x25StatInAccusedOfProtocolErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received containing a procedure error cause code. These include clear, reset, restart, or diagnostic packets." REFERENCE "CD 10733 5.9 accusedOfProtocolError" Throop [Page 26] RFC 1382 X.25 Packet Layer MIB November 1992 ::= { x25StatEntry 9 } x25StatInInterrupts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of interrupt packets received by the PLE or over the PVC/VC." REFERENCE "10733 interruptPacketsReceived" ::= { x25StatEntry 10 } x25StatOutCallAttempts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of calls attempted." REFERENCE "10733 5.9 callAttempts" ::= { x25StatEntry 11 } x25StatOutCallFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of call attempts which failed. This includes calls that were cleared because of restrictive fast select." ::= { x25StatEntry 12 } x25StatOutInterrupts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of interrupt packets send by the PLE or over the PVC/VC." REFERENCE "10733 InterruptPacketsSent" ::= { x25StatEntry 13 } x25StatOutDataPackets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of data packets sent by this PLE." Throop [Page 27] RFC 1382 X.25 Packet Layer MIB November 1992 REFERENCE "10733 dataPacketSent" ::= { x25StatEntry 14 } x25StatOutgoingCircuits OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The number of active outgoing circuits. This includes call requests sent but not yet confirmed. This does not count PVCs." ::= { x25StatEntry 15 } x25StatIncomingCircuits OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The number of active Incoming Circuits. This includes call indications received but not yet acknowledged. This does not count PVCs." ::= { x25StatEntry 16 } x25StatTwowayCircuits OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The number of active two-way Circuits. This includes call requests sent but not yet confirmed. This does not count PVCs." ::= { x25StatEntry 17 } x25StatRestartTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T20 restart timer expired." REFERENCE "10733 5.9 restartTimeouts" ::= { x25StatEntry 18 } x25StatCallTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Throop [Page 28] RFC 1382 X.25 Packet Layer MIB November 1992 DESCRIPTION "The number of times the T21 call timer expired." REFERENCE "10733 5.9 callTimeouts" ::= { x25StatEntry 19 } x25StatResetTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T22 reset timer expired." REFERENCE "10733 5.9 resetTimeouts" ::= { x25StatEntry 20 } x25StatClearTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T23 clear timer expired." REFERENCE "10733 5.9 clearTimeouts" ::= { x25StatEntry 21 } x25StatDataRxmtTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T25 data timer expired." REFERENCE "10733 5.9 dataRetransmissionsTimerExpiries" ::= { x25StatEntry 22 } x25StatInterruptTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T26 interrupt timer expired." REFERENCE "10733 5.9 interruptTimerExpires" ::= { x25StatEntry 23 } x25StatRetryCountExceededs OBJECT-TYPE SYNTAX Counter Throop [Page 29] RFC 1382 X.25 Packet Layer MIB November 1992 ACCESS read-only STATUS mandatory DESCRIPTION "The number of times a retry counter was exhausted." REFERENCE "10733 5.9 retryCountsExceeded" ::= { x25StatEntry 24 } x25StatClearCountExceededs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the R23 clear count was exceeded." REFERENCE "10733 5.9 clearCountsExceeded" ::= { x25StatEntry 25 } -- MIB-II also contains: -- ifInOctets: Number of data octets delivered to upper -- layer entities. -- ifInUcastPkts: Number of packets with a clear M-bit -- delivered to higher layer entities. -- ifDiscards: Number of packets dropped for lack of buffering -- ifInErrors: Number of packets received containing errors -- REFERENCE ProtocolErrorsDetectedLocally -- ifInUnknownProtos: Number of packets with unknown circuit -- identifier. -- ifOutOctets: Number of data octets delivered by -- X.25 to upper layers. -- ifOutUcastPkts: Number of packets with a clear M-bit -- received from higher layer entities. -- ########################################################### -- X.25 Channel Table -- ########################################################### x25ChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF X25ChannelEntry Throop [Page 30] RFC 1382 X.25 Packet Layer MIB November 1992 ACCESS not-accessible STATUS mandatory DESCRIPTION "These objects contain information about the channel number configuration in an X.25 PLE. These values are the configured values. changes in these values after the interfaces has started may not be reflected in the operating PLE." REFERENCE "See ISO 8208, Section 3.7" ::= { x25 4 } x25ChannelEntry OBJECT-TYPE SYNTAX X25ChannelEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entries of x25ChannelTable." REFERENCE "This provides the information available in 10733 logicalChannelAssignments." INDEX { x25ChannelIndex } ::= { x25ChannelTable 1 } X25ChannelEntry ::= SEQUENCE { x25ChannelIndex IfIndexType, x25ChannelLIC INTEGER, x25ChannelHIC INTEGER, x25ChannelLTC INTEGER, x25ChannelHTC INTEGER, x25ChannelLOC INTEGER, x25ChannelHOC INTEGER } x25ChannelIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the X.25 Interface." ::= { x25ChannelEntry 1 } Throop [Page 31] RFC 1382 X.25 Packet Layer MIB November 1992 x25ChannelLIC OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-write STATUS mandatory DESCRIPTION "Lowest Incoming channel." ::= { x25ChannelEntry 2 } x25ChannelHIC OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-write STATUS mandatory DESCRIPTION "Highest Incoming channel. A value of zero indicates no channels in this range." ::= { x25ChannelEntry 3 } x25ChannelLTC OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-write STATUS mandatory DESCRIPTION "Lowest Two-way channel." ::= { x25ChannelEntry 4 } x25ChannelHTC OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-write STATUS mandatory DESCRIPTION "Highest Two-way channel. A value of zero indicates no channels in this range." ::= { x25ChannelEntry 5 } x25ChannelLOC OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-write STATUS mandatory DESCRIPTION "Lowest outgoing channel." ::= { x25ChannelEntry 6 } x25ChannelHOC OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-write STATUS mandatory DESCRIPTION "Highest outgoing channel. A value of zero Throop [Page 32] RFC 1382 X.25 Packet Layer MIB November 1992 indicates no channels in this range." ::= { x25ChannelEntry 7 } -- ########################################################### -- X25 Per Circuits Information Table -- ########################################################### x25CircuitTable OBJECT-TYPE SYNTAX SEQUENCE OF X25CircuitEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "These objects contain general information about a specific circuit of an X.25 PLE." ::= { x25 5 } x25CircuitEntry OBJECT-TYPE SYNTAX X25CircuitEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entries of x25CircuitTable." INDEX { x25CircuitIndex, x25CircuitChannel } ::= { x25CircuitTable 1 } X25CircuitEntry ::= SEQUENCE { x25CircuitIndex IfIndexType, x25CircuitChannel INTEGER, x25CircuitStatus INTEGER, x25CircuitEstablishTime TimeTicks, x25CircuitDirection INTEGER, x25CircuitInOctets Counter, x25CircuitInPdus Counter, x25CircuitInRemotelyInitiatedResets Counter, x25CircuitInProviderInitiatedResets Counter, Throop [Page 33] RFC 1382 X.25 Packet Layer MIB November 1992 x25CircuitInInterrupts Counter, x25CircuitOutOctets Counter, x25CircuitOutPdus Counter, x25CircuitOutInterrupts Counter, x25CircuitDataRetransmissionTimeouts Counter, x25CircuitResetTimeouts Counter, x25CircuitInterruptTimeouts Counter, x25CircuitCallParamId OBJECT IDENTIFIER, x25CircuitCalledDteAddress X121Address, x25CircuitCallingDteAddress X121Address, x25CircuitOriginallyCalledAddress X121Address, x25CircuitDescr DisplayString } x25CircuitIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The ifIndex value for the X.25 Interface." ::= { x25CircuitEntry 1 } x25CircuitChannel OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-only STATUS mandatory DESCRIPTION "The channel number for this circuit." ::= { x25CircuitEntry 2 } x25CircuitStatus OBJECT-TYPE SYNTAX INTEGER { -- state table states invalid (1), closed (2), -- (p1) calling (3), -- (p2,p3,p5) open (4), -- (p4) Throop [Page 34] RFC 1382 X.25 Packet Layer MIB November 1992 clearing (5), -- (p6,p7) pvc (6), pvcResetting (7), startClear (8), -- Close cmd startPvcResetting (9), -- Reset cmd other (10) } ACCESS read-write STATUS mandatory DESCRIPTION "This object reports the current status of the circuit. An existing instance of this object can only be set to startClear, startPvcResetting, or invalid. An instance with the value calling or open can only be set to startClear and that action will start clearing the circuit. An instance with the value PVC can only be set to startPvcResetting or invalid and that action resets the PVC or deletes the circuit respectively. The values startClear or startPvcResetting will never be returned by an agent. An attempt to set the status of an existing instance to a value other than one of these values will result in an error. A non-existing instance can be set to PVC to create a PVC if the implementation supports dynamic creation of PVCs. Some implementations may only allow creation and deletion of PVCs if the interface is down. Since the instance identifier will supply the PLE index and the channel number, setting this object alone supplies sufficient information to create the instance. All the DEFVAL clauses for the other objects of this table are appropriate for creating a PVC; PLEs creating entries for placed or accepted calls will use values appropriate for the call rather than the value of the DEFVAL clause. Two managers trying to create the same PVC can determine from the return code which manager succeeded and which failed (the failing manager fails because it can not set a value of PVC for an existing object). Throop [Page 35] RFC 1382 X.25 Packet Layer MIB November 1992 An entry in the closed or invalid state may be deleted or reused at the agent's convence. If the entry is kept in the closed state, the values of the parameters associated with the entry must be correct. Closed implies the values in the circuit table are correct. The value of invalid indicates the other values in the table are invalid. Many agents may never return a value of invalid because they dynamically allocate and free unused table entries. An agent for a statically configured systems can return invalid to indicate the entry has not yet been used so the counters contain no information." REFERENCE "See ISO 8208, table 33 for (p) state table" ::= { x25CircuitEntry 3 } x25CircuitEstablishTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime when the channel was associated with this circuit. For outgoing SVCs, this is the time the first call packet was sent. For incoming SVCs, this is the time the call indication was received. For PVCs this is the time the PVC was able to pass data to a higher layer entity without loss of data." ::= { x25CircuitEntry 4 } x25CircuitDirection OBJECT-TYPE SYNTAX INTEGER { incoming (1), outgoing (2), pvc (3) } ACCESS read-write STATUS mandatory DESCRIPTION "The direction of the call that established this circuit." REFERENCE "10733 direction" Throop [Page 36] RFC 1382 X.25 Packet Layer MIB November 1992 DEFVAL { pvc } ::= { x25CircuitEntry 5 } -- X25 Circuit data flow statistics x25CircuitInOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of octets of user data delivered to upper layer." REFERENCE "5.11 octetsReceivedCounter" ::= { x25CircuitEntry 6 } x25CircuitInPdus OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PDUs received for this circuit." REFERENCE "10733 5.11 dataPacketsReceived" ::= { x25CircuitEntry 7 } x25CircuitInRemotelyInitiatedResets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of Resets received for this circuit with cause code of DTE initiated." REFERENCE "10733 remotelyInitiatedResets" ::= { x25CircuitEntry 8 } x25CircuitInProviderInitiatedResets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of Resets received for this circuit with cause code other than DTE initiated." REFERENCE "10733 ProviderInitiatedResets" ::= { x25CircuitEntry 9 } x25CircuitInInterrupts OBJECT-TYPE SYNTAX Counter Throop [Page 37] RFC 1382 X.25 Packet Layer MIB November 1992 ACCESS read-only STATUS mandatory DESCRIPTION "The number of interrupt packets received for this circuit." REFERENCE "10733 interruptPacketsReceived" ::= { x25CircuitEntry 10 } x25CircuitOutOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of octets of user data sent for this circuit." REFERENCE "10733 5.11 octetsSentCounter" ::= { x25CircuitEntry 11 } x25CircuitOutPdus OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PDUs sent for this circuit." REFERENCE "10733 5.11 dataPacketsSent" ::= { x25CircuitEntry 12 } x25CircuitOutInterrupts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of interrupt packets sent on this circuit." REFERENCE "10733 interruptPacketsSent" ::= { x25CircuitEntry 13 } -- X25 circuit timer statistics x25CircuitDataRetransmissionTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T25 data retransmission timer expired for this circuit." Throop [Page 38] RFC 1382 X.25 Packet Layer MIB November 1992 REFERENCE "10733 5.11 dataRetransmissionTimerExpiries" ::= { x25CircuitEntry 14 } x25CircuitResetTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T22 reset timer expired for this circuit." REFERENCE "10733 5.11 resetTimeouts" ::= { x25CircuitEntry 15 } x25CircuitInterruptTimeouts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the T26 Interrupt timer expired for this circuit." REFERENCE "10733 interruptTimerExpiries" ::= { x25CircuitEntry 16 } x25CircuitCallParamId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "This identifies the instance of the x25CallParmIndex for the entry in the x25CallParmTable which contains the call parameters in use with this circuit. The entry referenced must contain the values that are currently in use by the circuit rather than proposed values. A value of NULL indicates the circuit is a PVC or is using all the default parameters." DEFVAL { {0 0} } ::= { x25CircuitEntry 17 } x25CircuitCalledDteAddress OBJECT-TYPE SYNTAX X121Address ACCESS read-write STATUS mandatory DESCRIPTION "For incoming calls, this is the called address from the call indication packet. For outgoing calls, this is the called Throop [Page 39] RFC 1382 X.25 Packet Layer MIB November 1992 address from the call confirmation packet. This will be zero length for PVCs." REFERENCE "10733 calledDTEAddress" DEFVAL { ''h } ::= { x25CircuitEntry 18 } x25CircuitCallingDteAddress OBJECT-TYPE SYNTAX X121Address ACCESS read-write STATUS mandatory DESCRIPTION "For incoming calls, this is the calling address from the call indication packet. For outgoing calls, this is the calling address from the call confirmation packet. This will be zero length for PVCs." REFERENCE "10733 callingDTEAddress" DEFVAL { ''h } ::= { x25CircuitEntry 19 } x25CircuitOriginallyCalledAddress OBJECT-TYPE SYNTAX X121Address ACCESS read-write STATUS mandatory DESCRIPTION "For incoming calls, this is the address in the call Redirection or Call Deflection Notification facility if the call was deflected or redirected, otherwise it will be called address from the call indication packet. For outgoing calls, this is the address from the call request packet. This will be zero length for PVCs." REFERENCE "10733 originallyCalledAddress" DEFVAL { ''h } ::= { x25CircuitEntry 20 } x25CircuitDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "A descriptive string associated with this circuit. This provides a place for the agent to supply any descriptive information it knows about the use or owner of the circuit. The agent may return the process identifier and user name for the process Throop [Page 40] RFC 1382 X.25 Packet Layer MIB November 1992 using the circuit. Alternative the agent may return the name of the configuration entry that caused a bridge to establish the circuit. A zero length value indicates the agent doesn't have any additional information." DEFVAL { ''h } ::= { x25CircuitEntry 21 } -- ########################################################### -- The Cleared Circuit Table -- ########################################################### x25ClearedCircuitEntriesRequested OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The requested number of entries for the agent to keep in the x25ClearedCircuit table." ::= { x25 6 } x25ClearedCircuitEntriesGranted OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The actual number of entries the agent will keep in the x25ClearedCircuit Table." ::= { x25 7 } x25ClearedCircuitTable OBJECT-TYPE SYNTAX SEQUENCE OF X25ClearedCircuitEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table of entries about closed circuits. Entries must be made in this table whenever circuits are closed and the close request or close indication packet contains a clearing cause other than DTE Originated or a Diagnostic code field other than Higher Layer Initiated disconnection-normal. An agent may optionally make entries for normal closes (to record closing facilities or Throop [Page 41] RFC 1382 X.25 Packet Layer MIB November 1992 other information). Agents will delete the oldest entry in the table when adding a new entry would exceed agent resources. Agents are required to keep the last entry put in the table and may keep more entries. The object x25OperClearEntriesGranted returns the maximum number of entries kept in the table." REFERENCE "See ISO 8208 Section 12.2.3.1.1 and 12.2.3.1.2" ::= { x25 8 } x25ClearedCircuitEntry OBJECT-TYPE SYNTAX X25ClearedCircuitEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a cleared circuit." INDEX { x25ClearedCircuitIndex } ::= { x25ClearedCircuitTable 1 } X25ClearedCircuitEntry ::= SEQUENCE { x25ClearedCircuitIndex PositiveInteger, x25ClearedCircuitPleIndex IfIndexType, x25ClearedCircuitTimeEstablished TimeTicks, x25ClearedCircuitTimeCleared TimeTicks, x25ClearedCircuitChannel INTEGER, x25ClearedCircuitClearingCause INTEGER, x25ClearedCircuitDiagnosticCode INTEGER, x25ClearedCircuitInPdus Counter, x25ClearedCircuitOutPdus Counter, x25ClearedCircuitCalledAddress X121Address, x25ClearedCircuitCallingAddress X121Address, x25ClearedCircuitClearFacilities OCTET STRING Throop [Page 42] RFC 1382 X.25 Packet Layer MIB November 1992 } x25ClearedCircuitIndex OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "An index that uniquely distinguishes one entry in the clearedCircuitTable from another. This index will start at 2147483647 and will decrease by one for each new entry added to the table. Upon reaching one, the index will reset to 2147483647. Because the index starts at 2147483647 and decreases, a manager may do a getnext on entry zero and obtain the most recent entry. When the index has the value of 1, the next entry will delete all entries in the table and that entry will be numbered 2147483647." ::= { x25ClearedCircuitEntry 1 } x25ClearedCircuitPleIndex OBJECT-TYPE SYNTAX IfIndexType ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex for the PLE which cleared the circuit that created the entry." ::= { x25ClearedCircuitEntry 2 } x25ClearedCircuitTimeEstablished OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime when the circuit was established. This will be the same value that was in the x25CircuitEstablishTime for the circuit." ::= { x25ClearedCircuitEntry 3 } x25ClearedCircuitTimeCleared OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime when the circuit was cleared. For locally initiated clears, this Throop [Page 43] RFC 1382 X.25 Packet Layer MIB November 1992 will be the time when the clear confirmation was received. For remotely initiated clears, this will be the time when the clear indication was received." ::= { x25ClearedCircuitEntry 4 } x25ClearedCircuitChannel OBJECT-TYPE SYNTAX INTEGER (0..4095) ACCESS read-only STATUS mandatory DESCRIPTION "The channel number for the circuit that was cleared." ::= { x25ClearedCircuitEntry 5 } x25ClearedCircuitClearingCause OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The Clearing Cause from the clear request or clear indication packet that cleared the circuit." REFERENCE "See ISO 8208 Section 12.2.3.1.1" ::= { x25ClearedCircuitEntry 6 } x25ClearedCircuitDiagnosticCode OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The Diagnostic Code from the clear request or clear indication packet that cleared the circuit." REFERENCE "See ISO 8208 Section 12.2.3.1.2" ::= { x25ClearedCircuitEntry 7 } x25ClearedCircuitInPdus OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PDUs received on the circuit." ::= { x25ClearedCircuitEntry 8 } x25ClearedCircuitOutPdus OBJECT-TYPE SYNTAX Counter Throop [Page 44] RFC 1382 X.25 Packet Layer MIB November 1992 ACCESS read-only STATUS mandatory DESCRIPTION "The number of PDUs transmitted on the circuit." ::= { x25ClearedCircuitEntry 9 } x25ClearedCircuitCalledAddress OBJECT-TYPE SYNTAX X121Address ACCESS read-only STATUS mandatory DESCRIPTION "The called address from the cleared circuit." ::= { x25ClearedCircuitEntry 10 } x25ClearedCircuitCallingAddress OBJECT-TYPE SYNTAX X121Address ACCESS read-only STATUS mandatory DESCRIPTION "The calling address from the cleared circuit." ::= { x25ClearedCircuitEntry 11 } x25ClearedCircuitClearFacilities OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..109)) ACCESS read-only STATUS mandatory DESCRIPTION "The facilities field from the clear request or clear indication packet that cleared the circuit. A size of zero indicates no facilities were present." ::= { x25ClearedCircuitEntry 12 } -- ########################################################### -- The Call Parameter Table -- ########################################################### x25CallParmTable OBJECT-TYPE SYNTAX SEQUENCE OF X25CallParmEntry ACCESS not-accessible STATUS mandatory DESCRIPTION Throop [Page 45] RFC 1382 X.25 Packet Layer MIB November 1992 "These objects contain the parameters that can be varied between X.25 calls. The entries in this table are independent of the PLE. There exists only one of these tables for the entire system. The indexes for the entries are independent of any PLE or any circuit. Other tables reference entries in this table. Entries in this table can be used for default PLE parameters, for parameters to use to place/answer a call, for the parameters currently in use for a circuit, or parameters that were used by a circuit. The number of references to a given set of parameters can be found in the x25CallParmRefCount object sharing the same instance identifier with the parameters. The value of this reference count also affects the access of the objects in this table. An object in this table with the same instance identifier as the instance identifier of an x25CallParmRefCount must be consider associated with that reference count. An object with an associated reference count of zero can be written (if its ACCESS clause allows it). An object with an associated reference count greater than zero can not be written (regardless of the ACCESS clause). This ensures that a set of call parameters being referenced from another table can not be modified or changed in a ways inappropriate for continued use by that table." ::= { x25 9 } x25CallParmEntry OBJECT-TYPE SYNTAX X25CallParmEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entries of x25CallParmTable." INDEX { x25CallParmIndex } ::= { x25CallParmTable 1 } X25CallParmEntry ::= SEQUENCE { x25CallParmIndex PositiveInteger, Throop [Page 46] RFC 1382 X.25 Packet Layer MIB November 1992 x25CallParmStatus EntryStatus, x25CallParmRefCount PositiveInteger, x25CallParmInPacketSize INTEGER, x25CallParmOutPacketSize INTEGER, x25CallParmInWindowSize INTEGER, x25CallParmOutWindowSize INTEGER, x25CallParmAcceptReverseCharging INTEGER, x25CallParmProposeReverseCharging INTEGER, x25CallParmFastSelect INTEGER, x25CallParmInThruPutClasSize INTEGER, x25CallParmOutThruPutClasSize INTEGER, x25CallParmCug DisplayString, x25CallParmCugoa DisplayString, x25CallParmBcug DisplayString, x25CallParmNui OCTET STRING, x25CallParmChargingInfo INTEGER, x25CallParmRpoa DisplayString, x25CallParmTrnstDly INTEGER, x25CallParmCallingExt DisplayString, x25CallParmCalledExt DisplayString, x25CallParmInMinThuPutCls INTEGER, x25CallParmOutMinThuPutCls INTEGER, x25CallParmEndTrnsDly OCTET STRING, x25CallParmPriority OCTET STRING, Throop [Page 47] RFC 1382 X.25 Packet Layer MIB November 1992 x25CallParmProtection DisplayString, x25CallParmExptData INTEGER, x25CallParmUserData OCTET STRING, x25CallParmCallingNetworkFacilities OCTET STRING, x25CallParmCalledNetworkFacilities OCTET STRING } x25CallParmIndex OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "A value that distinguishes this entry from another entry. Entries in this table are referenced from other objects which identify call parameters. It is impossible to know which other objects in the MIB reference entries in the table by looking at this table. Because of this, changes to parameters must be accomplished by creating a new entry in this table and then changing the referencing table to identify the new entry. Note that an agent will only use the values in this table when another table is changed to reference those values. The number of other tables that reference an index object in this table can be found in x25CallParmRefCount. The value of the reference count will affect the writability of the objects as explained above. Entries in this table which have a reference count of zero maybe deleted at the convence of the agent. Care should be taken by the agent to give the NMS sufficient time to create a reference to newly created entries. Should a Management Station not find a free index with which to create a new entry, it may feel free to delete entries with a Throop [Page 48] RFC 1382 X.25 Packet Layer MIB November 1992 reference count of zero. However in doing so the Management Station much realize it may impact other Management Stations." ::= { x25CallParmEntry 1 } x25CallParmStatus OBJECT-TYPE SYNTAX EntryStatus ACCESS read-write STATUS mandatory DESCRIPTION "The status of this call parameter entry. See RFC 1271 for details of usage." ::= { x25CallParmEntry 2 } x25CallParmRefCount OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The number of references know by a management station to exist to this set of call parameters. This is the number of other objects that have returned a value of, and will return a value of, the index for this set of call parameters. Examples of such objects are the x25AdmnDefCallParamId, x25OperDataLinkId, or x25AdmnDefCallParamId objects defined above." ::= { x25CallParmEntry 3 } x25CallParmInPacketSize OBJECT-TYPE SYNTAX INTEGER (0..4096) ACCESS read-write STATUS mandatory DESCRIPTION "The maximum receive packet size in octets for a circuit. A size of zero for a circuit means use the PLE default size. A size of zero for the PLE means use a default size of 128." REFERENCE "10733 proposedPacketSize; See ISO 8208 Section 15.2.2.1.1" DEFVAL { 128 } ::= { x25CallParmEntry 4 } x25CallParmOutPacketSize OBJECT-TYPE SYNTAX INTEGER (0..4096) ACCESS read-write Throop [Page 49] RFC 1382 X.25 Packet Layer MIB November 1992 STATUS mandatory DESCRIPTION "The maximum transmit packet size in octets for a circuit. A size of zero for a circuit means use the PLE default size. A size of zero for the PLE default means use a default size of 128." REFERENCE "10733 proposedPacketSize; See ISO 8208 Section 15.2.2.1.1" DEFVAL { 128 } ::= { x25CallParmEntry 5 } x25CallParmInWindowSize OBJECT-TYPE SYNTAX INTEGER (0..127) ACCESS read-write STATUS mandatory DESCRIPTION "The receive window size for a circuit. A size of zero for a circuit means use the PLE default size. A size of zero for the PLE default means use 2." REFERENCE "10733 proposedWindowSize; See ISO 8208 Section 15.2.2.1.2" DEFVAL { 2 } ::= { x25CallParmEntry 6 } x25CallParmOutWindowSize OBJECT-TYPE SYNTAX INTEGER (0..127) ACCESS read-write STATUS mandatory DESCRIPTION "The transmit window size for a circuit. A size of zero for a circuit means use the PLE default size. A size of zero for the PLE default means use 2." REFERENCE "10733 proposedWindowSize; See ISO 8208 Section 15.2.2.1.2" DEFVAL { 2 } ::= { x25CallParmEntry 7 } x25CallParmAcceptReverseCharging OBJECT-TYPE SYNTAX INTEGER { default (1), accept (2), refuse (3), neverAccept (4) } ACCESS read-write Throop [Page 50] RFC 1382 X.25 Packet Layer MIB November 1992 STATUS mandatory DESCRIPTION "An enumeration defining if the PLE will accept or refuse charges. A value of default for a circuit means use the PLE default value. A value of neverAccept is only used for the PLE default and indicates the PLE will never accept reverse charging. A value of default for a PLE default means refuse." REFERENCE "10733 acceptReverseCharging" DEFVAL { refuse } ::= { x25CallParmEntry 8 } x25CallParmProposeReverseCharging OBJECT-TYPE SYNTAX INTEGER { default (1), reverse (2), local (3) } ACCESS read-write STATUS mandatory DESCRIPTION "An enumeration defining if the PLE should propose reverse or local charging. The value of default for a circuit means use the PLE default. The value of default for the PLE default means use local." REFERENCE "10733 proposedPacketSize; See ISO 8208 Section 15.2.2.6" DEFVAL { local } ::= { x25CallParmEntry 9 } x25CallParmFastSelect OBJECT-TYPE SYNTAX INTEGER { default (1), notSpecified (2), fastSelect (3), restrictedFastResponse (4), noFastSelect (5), noRestrictedFastResponse (6) } ACCESS read-write STATUS mandatory DESCRIPTION "Expresses preference for use of fast select facility. The value of default for a circuit is the PLE default. A value of Throop [Page 51] RFC 1382 X.25 Packet Layer MIB November 1992 default for the PLE means noFastSelect. A value of noFastSelect or noRestrictedFastResponse indicates a circuit may not use fast select or restricted fast response." REFERENCE "10733 fastSelect; Sec ISO 8208 Section 15.2.2.6" DEFVAL { noFastSelect } ::= { x25CallParmEntry 10 } x25CallParmInThruPutClasSize OBJECT-TYPE SYNTAX INTEGER { tcReserved1 (1), tcReserved2 (2), tc75 (3), tc150 (4), tc300 (5), tc600 (6), tc1200 (7), tc2400 (8), tc4800 (9), tc9600 (10), tc19200 (11), tc48000 (12), tc64000 (13), tcReserved14 (14), tcReserved15 (15), tcReserved0 (16), tcNone (17), tcDefault (18) } ACCESS read-write STATUS mandatory DESCRIPTION "The incoming throughput class to negotiate. A value of tcDefault for a circuit means use the PLE default. A value of tcDefault for the PLE default means tcNone. A value of tcNone means do not negotiate throughtput class." REFERENCE "See ISO 8208 Section 15.2.2.2, table 18" DEFVAL { tcNone } ::= { x25CallParmEntry 11 } x25CallParmOutThruPutClasSize OBJECT-TYPE SYNTAX INTEGER { tcReserved1 (1), tcReserved2 (2), Throop [Page 52] RFC 1382 X.25 Packet Layer MIB November 1992 tc75 (3), tc150 (4), tc300 (5), tc600 (6), tc1200 (7), tc2400 (8), tc4800 (9), tc9600 (10), tc19200 (11), tc48000 (12), tc64000 (13), tcReserved14 (14), tcReserved15 (15), tcReserved0 (16), tcNone (17), tcDefault (18) } ACCESS read-write STATUS mandatory DESCRIPTION "The outgoing throughput class to negotiate. A value of tcDefault for a circuit means use the PLE default. A value of tcDefault for the PLE default means use tcNone. A value of tcNone means do not negotiate throughtput class." REFERENCE "See ISO 8208 Section 15.2.2.2, table 18" DEFVAL { tcNone } ::= { x25CallParmEntry 12 } x25CallParmCug OBJECT-TYPE SYNTAX DisplayString (SIZE(0..4)) ACCESS read-write STATUS mandatory DESCRIPTION "The Closed User Group to specify. This consists of two or four octets containing the characters 0 through 9. A zero length string indicates no facility requested. A string length of three containing the characters DEF for a circuit means use the PLE default, (the PLE default parameter may not reference an entry of DEF.)" REFERENCE "See ISO 8208 Section 15.2.2.3" DEFVAL { ''h } ::= { x25CallParmEntry 13 } x25CallParmCugoa OBJECT-TYPE Throop [Page 53] RFC 1382 X.25 Packet Layer MIB November 1992 SYNTAX DisplayString (SIZE(0..4)) ACCESS read-write STATUS mandatory DESCRIPTION "The Closed User Group with Outgoing Access to specify. This consists of two or four octets containing the characters 0 through 9. A string length of three containing the characters DEF for a circuit means use the PLE default (the PLE default parameters may not reference an entry of DEF). A zero length string indicates no facility requested." REFERENCE "See ISO 8208 Section 15.2.2.4" DEFVAL { ''h } ::= { x25CallParmEntry 14 } x25CallParmBcug OBJECT-TYPE SYNTAX DisplayString (SIZE(0..3)) ACCESS read-write STATUS mandatory DESCRIPTION "The Bilateral Closed User Group to specify. This consists of two octets containing the characters 0 through 9. A string length of three containing the characters DEF for a circuit means use the PLE default (the PLE default parameter may not reference an entry of DEF). A zero length string indicates no facility requested." REFERENCE "See ISO 8208 Section 15.2.2.5" DEFVAL { ''h } ::= { x25CallParmEntry 15 } x25CallParmNui OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..108)) ACCESS read-write STATUS mandatory DESCRIPTION "The Network User Identifier facility. This is binary value to be included immediately after the length field. The PLE will supply the length octet. A zero length string indicates no facility requested. This value is ignored for the PLE default parameters entry." REFERENCE "See ISO 8208 Section 15.2.2.7" DEFVAL { ''h } Throop [Page 54] RFC 1382 X.25 Packet Layer MIB November 1992 ::= { x25CallParmEntry 16 } x25CallParmChargingInfo OBJECT-TYPE SYNTAX INTEGER { default (1), noFacility (2), noChargingInfo (3), chargingInfo (4) } ACCESS read-write STATUS mandatory DESCRIPTION "The charging Information facility. A value of default for a circuit means use the PLE default. The value of default for the default PLE parameters means use noFacility. The value of noFacility means do not include a facility." REFERENCE "See ISO 8208 Section 15.2.2.8" DEFVAL { noFacility } ::= { x25CallParmEntry 17 } x25CallParmRpoa OBJECT-TYPE SYNTAX DisplayString (SIZE(0..108)) ACCESS read-write STATUS mandatory DESCRIPTION "The RPOA facility. The octet string contains n * 4 sequences of the characters 0-9 to specify a facility with n entries. The octet string containing the 3 characters DEF for a circuit specifies use of the PLE default (the entry for the PLE default may not contain DEF). A zero length string indicates no facility requested." REFERENCE "See ISO 8208, section 15.2.2.9" DEFVAL { ''h } ::= { x25CallParmEntry 18 } x25CallParmTrnstDly OBJECT-TYPE SYNTAX INTEGER (0..65537) ACCESS read-write STATUS mandatory DESCRIPTION "The Transit Delay Selection and Indication value. A value of 65536 indicates no facility requested. A value of 65537 for a circuit means use the PLE default (the PLE Throop [Page 55] RFC 1382 X.25 Packet Layer MIB November 1992 default parameters entry may not use the value 65537). The value 65535 may only be used to indicate the value in use by a circuit." REFERENCE "See ISO 8208, Section 15.2.2.13" DEFVAL { 65536 } ::= { x25CallParmEntry 19 } -- The following parameters are for CCITT facilities. x25CallParmCallingExt OBJECT-TYPE SYNTAX DisplayString (SIZE(0..40)) ACCESS read-write STATUS mandatory DESCRIPTION "The Calling Extension facility. This contains one of the following: A sequence of hex digits with the value to be put in the facility. These digits will be converted to binary by the agent and put in the facility. These octets do not include the length octet. A value containing the three character DEF for a circuit means use the PLE default, (the entry for the PLE default parameters may not use the value DEF). A zero length string indicates no facility requested." REFERENCE "See ISO 8208 Section 15.3.2.1" DEFVAL { ''h } ::= { x25CallParmEntry 20 } x25CallParmCalledExt OBJECT-TYPE SYNTAX DisplayString (SIZE(0..40)) ACCESS read-write STATUS mandatory DESCRIPTION "The Called Extension facility. This contains one of the following: A sequence of hex digits with the value to be put in the facility. These digits will be converted to binary by the agent and put in the facility. These octets do not include Throop [Page 56] RFC 1382 X.25 Packet Layer MIB November 1992 the length octet. A value containing the three character DEF for a circuit means use the PLE default, (the entry for the PLE default parameters may not use the value DEF). A zero length string indicates no facility requested." REFERENCE "See ISO 8208 Section 15.3.2.2" DEFVAL { ''h } ::= { x25CallParmEntry 21 } x25CallParmInMinThuPutCls OBJECT-TYPE SYNTAX INTEGER (0..17) ACCESS read-write STATUS mandatory DESCRIPTION "The minimum input throughput Class. A value of 16 for a circuit means use the PLE default (the PLE parameters entry may not use this value). A value of 17 indicates no facility requested." REFERENCE "See ISO 8208 Section 15.3.2.3" DEFVAL { 17 } ::= { x25CallParmEntry 22 } x25CallParmOutMinThuPutCls OBJECT-TYPE SYNTAX INTEGER (0..17) ACCESS read-write STATUS mandatory DESCRIPTION "The minimum output throughput Class. A value of 16 for a circuit means use the PLE default (the PLE parameters entry may not use this value). A value of 17 indicates no facility requested." REFERENCE "See ISO 8208 Section 15.3.2.3" DEFVAL { 17 } ::= { x25CallParmEntry 23 } x25CallParmEndTrnsDly OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..6)) ACCESS read-write STATUS mandatory DESCRIPTION "The End-to-End Transit Delay to negotiate. An octet string of length 2, 4, or 6 Throop [Page 57] RFC 1382 X.25 Packet Layer MIB November 1992 contains the facility encoded as specified in ISO/IEC 8208 section 15.3.2.4. An octet string of length 3 containing the three character DEF for a circuit means use the PLE default (the entry for the PLE default can not contain the characters DEF). A zero length string indicates no facility requested." REFERENCE "See ISO 8208 Section 15.3.2.4" DEFVAL { ''h } ::= { x25CallParmEntry 24 } x25CallParmPriority OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..6)) ACCESS read-write STATUS mandatory DESCRIPTION "The priority facility to negotiate. The octet string encoded as specified in ISO/IEC 8208 section 15.3.2.5. A zero length string indicates no facility requested. The entry for the PLE default parameters must be zero length." REFERENCE "See ISO 8208 Section 15.3.2.5" DEFVAL { ''h } ::= { x25CallParmEntry 25 } x25CallParmProtection OBJECT-TYPE SYNTAX DisplayString (SIZE(0..108)) ACCESS read-write STATUS mandatory DESCRIPTION "A string contains the following: A hex string containing the value for the protection facility. This will be converted from hex to the octets actually in the packet by the agent. The agent will supply the length field and the length octet is not contained in this string. An string containing the 3 characters DEF for a circuit means use the PLE default (the entry for the PLE default parameters may not use the value DEF). A zero length string mean no facility requested." REFERENCE "See ISO 8208 Section 15.3.2.5" Throop [Page 58] RFC 1382 X.25 Packet Layer MIB November 1992 DEFVAL { ''h } ::= { x25CallParmEntry 26 } x25CallParmExptData OBJECT-TYPE SYNTAX INTEGER { default (1), noExpeditedData (2), expeditedData (3) } ACCESS read-write STATUS mandatory DESCRIPTION "The Expedited Data facility to negotiate. A value of default for a circuit means use the PLE default value. The entry for the PLE default parameters may not have the value default." REFERENCE "See ISO 8208 Section 15.3.2.7" DEFVAL { noExpeditedData } ::= { x25CallParmEntry 27 } x25CallParmUserData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..128)) ACCESS read-write STATUS mandatory DESCRIPTION "The call user data as placed in the packet. A zero length string indicates no call user data. If both the circuit call parameters and the PLE default have call user data defined, the data from the circuit call parameters will be used. If only the PLE has data defined, the PLE entry will be used. If neither the circuit call parameters or the PLE default entry has a value, no call user data will be sent." REFERENCE "See ISO 8208 Section 12.2.1.1.6, 12.2.1.2" DEFVAL { ''h } ::= { x25CallParmEntry 28 } x25CallParmCallingNetworkFacilities OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..108)) ACCESS read-write STATUS mandatory DESCRIPTION "The calling network facilities. The facilities are encoded here exactly as encoded in the call packet. These Throop [Page 59] RFC 1382 X.25 Packet Layer MIB November 1992 facilities do not include the marker facility code. A zero length string in the entry for the parameter to use when establishing a circuit means use the PLE default. A zero length string in the entry for PLE default parameters indicates no default facilities." REFERENCE "See ISO 8206 Section 15.1, category b" DEFVAL { ''h } ::= { x25CallParmEntry 29 } x25CallParmCalledNetworkFacilities OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..108)) ACCESS read-write STATUS mandatory DESCRIPTION "The called network facilities. The facilities are encoded here exactly as encoded in the call packet. These facilities do not include the marker facility code. A zero length string in the entry for the parameter to use when establishing a circuit means use the PLE default. A zero length string in the entry for PLE default parameters indicates no default facilities." REFERENCE "See ISO 8206 Section 15.1, category c" DEFVAL { ''h } ::= { x25CallParmEntry 30 } -- ########################################################### -- X.25 Traps -- ########################################################### x25Restart TRAP-TYPE ENTERPRISE x25 VARIABLES { x25OperIndex } DESCRIPTION "This trap means the X.25 PLE sent or received a restart packet. The restart that brings up the link should not send a x25Restart trap so the interface should send a linkUp trap. Sending this trap means the agent does not send a linkDown and linkUp trap." ::= 1 Throop [Page 60] RFC 1382 X.25 Packet Layer MIB November 1992 x25Reset TRAP-TYPE ENTERPRISE x25 VARIABLES { x25CircuitIndex, x25CircuitChannel } DESCRIPTION "If the PLE sends or receives a reset, the agent should send an x25Reset trap." ::= 2 -- ########################################################### -- X.25 Protocol Version Identifiers -- ########################################################### x25ProtocolVersion OBJECT IDENTIFIER ::= { x25 10 } -- X.25 CCITT 1976 version. x25protocolCcittV1976 OBJECT IDENTIFIER ::= { x25ProtocolVersion 1 } -- X.25 CCITT 1980 version. x25protocolCcittV1980 OBJECT IDENTIFIER ::= { x25ProtocolVersion 2 } -- X.25 CCITT 1984 version. x25protocolCcittV1984 OBJECT IDENTIFIER ::= { x25ProtocolVersion 3 } -- X.25 CCITT 1988 version. x25protocolCcittV1988 OBJECT IDENTIFIER ::= { x25ProtocolVersion 4 } -- X.25 1987 version of ISO 8208. x25protocolIso8208V1987 OBJECT IDENTIFIER ::= { x25ProtocolVersion 5 } -- X.25 1989 version of ISO 8208. x25protocolIso8208V1989 OBJECT IDENTIFIER ::= { x25ProtocolVersion 6 } -- ########################################################### END Throop [Page 61] RFC 1382 X.25 Packet Layer MIB November 1992 5. Appendix: Revision History July 30 1992 The July, 1992 release (Editor's Internal Reference Number 2.14) made the following changes: The syntax of the index objects for tables that are congruent with the MIB-II ifTable were changed to ifIndexType. The x25CallParmRefCount object was added to the x25CallParmTable. The description of the x25CallParmTable and x25CallParmIndex objects were changed to only allow writing an entry with a zero reference count. A requirement for conformance was added after the definition of x25 in the ASN.1 definition. June 26 1992 The June 29, 1992 release (Editor's Internal Reference Number 2.12) made the following changes: The range of x25ChannelLIC was changed from (0..4096) to (0..4095). The range of x25ChannelHIC was changed from (0..4096) to (0..4095). The range of x25ChannelLTC was changed from (0..4096) to (0..4095). The range of x25ChannelHTC was changed from (0..4096) to (0..4095). The range of x25ChannelLOC was changed from (0..4096) to (0..4095). The range of x25ChannelHOC was changed from (0..4096) to (0..4095). The range of x25CircuitChannel was changed from (1..4096) to (0..4095). The range of x25ClearedCircuitChannel was changed from Throop [Page 62] RFC 1382 X.25 Packet Layer MIB November 1992 (1..4096) to (0..4095). June 1992 The June 92 release (Editor's Internal Reference Number 2.11) made the following changes: A value of dxe was defined for x25AdmnInterfaceMode and x25OperInterfaceMode. The objects in the x25ChannelTable can now have a value of zero to indicate no channels configured in the range. The length of an X121Address was extended to 17 to accommodate the 1988 CCITT X.25 standard. Some object descriptions have been expanded and simplified, these include: all the channel table objects except the index, x25AdmnDataRxmtCount, x25AdmnRejectCount, x25AdmnRegistrationRequestCount, x25OperDataRxmtCount, x25OperRejectCount, x25OperRegistrationRequestCount, x25CircuitEstablishTime, x25ClearedCircuitTimeEstablished, x25ClearedCircuitTimeCleared, x25CallParmIndex, x25CallParmInPacketSize, x25CircuitCalledAddress, x25CircuitOriginallCalledAddress, x25CircuitCallingAddress, x25CallParmFastSelect, x25CallParmCug, x25CallParmCugoa, x25CallParmBcug, x25CallParmNui, x25CallParmRpoa, x25CallParmCallingExt, x25CallParmCalledExt, x25CallParmProtection, x25StatInCallRefusals and x25CallParmOutPacketSize. The x25StatNumberPvcs object was deleted and x25AdmnNumberPVCs and x25OperNumberPVCs objects added. The object x25StatOutDataPackets was added. The object x25AdmnProtocolVersionSupported as added. The x25CircuitRemoteDteAddress was deleted. Some ASN.1 errors were corrected. April 1992 The April release (Editor's Internal Reference Number 2.8) made many changes to incorporate the comments of the working group meeting in March 1992. Throop [Page 63] RFC 1382 X.25 Packet Layer MIB November 1992 All reference comments were changed to reference fields. The type PositiveInteger was imported from the RFC1381- MIB and used for all index and timer values. The x25PleTable was split into the x25AdmnTable, x25OperTable, and x25StatTable. The timer and counter objects from the x25CircuitTable were moved to the x25AdmnTable and replicated in the x25OperTable The objects in the x25CircuitTable were reordered to put the non-integer objects at the end of the table for easier implementation. The called and calling extension character set was extended to include a-f, and A-F. Additional states were added to the x25CircuitStatus object. Additional values were added to x25CircuitDirection x25CircuitCallParamId, and the addresses in the Circuit Table for PVCs. The length of the X25Address was changed to 0..15. The objects x25ClearedCircuitTimeEstablished, x25ClearedCircuitInPdus, and x25ClearedCircuitOutPdus were added to the x25ClearedCircuitTable. The name of the x25CircuitName was changed to x25CircuitDescr and the description was expanded. The access of the x25CircuitCallParamId was changed to read-only. The x25ClearedCircuitCodes object was split into the x25ClearedCircuitClearingCause and x25ClearedCircuitDiagnosticCode objects. The semantics of the x25ClearedCircuitIndex was redefined. Some of the description clauses were changed in an attempt to add clarity. Throop [Page 64] RFC 1382 X.25 Packet Layer MIB November 1992 DEFVAL clauses were added to most objects in the x25CallParmTable. Additional text was added to the description section to provide an overview of the tables of the MIB. The minimum allowable value for maximum active circuits was changed from one to zero. February 1992 The February release (Editor's Internal Reference Number 1.14) made many changes. Many of the tables were combined. For example, the x25InfoTable, x25PktStatTable, and x25TmrStatTable were combined into the x25PleTable. The x25ConInfoTable, x25ConStatTable, and x25ConTimrTable were combined into the x25CircuitTable. The objects for call parameters were drastically reworked. All call parameters were combined in the x25CallParmTable. Any table, such as the x25PleTable or x25CircuitTable, that needs to reference call parameters identifies an entry in the new table. As part of this the x25ConDefTable was deleted and replaced with the x25PleDefCallParamId. The x25PvcTable was deleted; the x25CircuitStatus object provides similar information about PVCs. The x25ClearedCircuitTable was added to record the status code of cleared circuits. Many object definitions were restructured. For example, the time units for timers was changed from 1/100ths of a second to milliseconds. Some indexes into tables were replaced with object identifiers. Much of the introductory text was changed and the references were changed to match. October 1991 The October release (Editor Internal Reference Number 1.10) made the following changes: Changed x25ConInfoStatus to clarify the description and Throop [Page 65] RFC 1382 X.25 Packet Layer MIB November 1992 the pvcResetting(5) value was changed to pvcResetting(6) to avoid a conflict with a previous use of the number 5. The name of the counter object x25TmrStatRetryCountsExceeded was changed to x25TmrStatRetryCountExceededs. The name of the counter object x25TmrStatClearCountsExceeded was changed to x25TmrStatClearCountExceededs. All occurrence of Guage was changed to Gauge. Added the x25CallFcltyTable, x25CallFcltyCcittTable, and x25CallParamTable. June 1991 The June release corrected some syntax errors and cleaned up some other minor things. April 1991 The April 26 release of this document was the first release. That version was derived from the ISO work on network layer management as presented in ISO/IEC 10733 [11] 6. Acknowledgements This document was produced by the x25mib working group: Fred Baker, ACC Art Berggreen, ACC Frank Bieser Gary Bjerke, Tandem Bill Bowman, HP Christopher Bucci, Datability Charles Carvalho, ACC Jeff Case, Snmp Research Angela Chen, HP Carson Cheung, BNR Tom Daniel, Spider Systems Chuck Davin, MIT Billy Durham, Honeywell Richard Fox, Synoptics Doug Geller, Data General Herve Goguely, LIR Corp Andy Goldthorpe, british-telecom Throop [Page 66] RFC 1382 X.25 Packet Layer MIB November 1992 Walter D. Guilarte David Gurevich Steve Huston, Process Software Corporation Jon Infante, ICL Frank Kastenholz, Clearpoint Zbigniew Kielczewski, Eicon Cheryl Krupezak, Georgia Tech Mats Lindstrom, Diab Data AB Andrew Malis, BBN Evan McGinnis, 3Com Gary (G.P.)Mussar, BNR Chandy Nilakantan, 3Com Randy Pafford, Data General Ragnar Paulson, The Software Group Limited Dave Perkins, Synoptics Walter Pinkarschewsky, DEC Karen Quidley, Data General Chris Ranch, Novell Paul S. Rarey, DHL Systems Inc. Jim Roche, Newbridge Research Philippe Roger, LIR Corp. Timon Sloane Mike Shand, DEC Brad Steina, Microcom Bob Stewart, Xyplex Tom Sullivan, Data General Rodney Thayer, Sable Technology Corporation Mark Therieau, Microcom Jane Thorn, Data General Dean Throop, Data General Maurice Turcotte, Racal Datacom Mike Zendels, Data General In addition, the contributions of the following individuals are also acknowledged: John Harper, DEC Chairman of the ISO committee for Network Level Management Information 7. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, "Management Information Base for Throop [Page 67] RFC 1382 X.25 Packet Layer MIB November 1992 Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [5] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Performance Systems International, March 1991. [6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [7] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [8] Stewart, B., Editor, "Definitions of Managed Objects for RS-232- like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992. [9] Throop, D., Editor, "SNMP MIB extension for LAPB", RFC 1381, Data General Corporation, November 1992. [10] "Information technology - - Data communication - X.25 Packet layer Protocol for Data Terminal Equipment", International Organization for Standardization, International Standard 8208, March 1990. [11] "Information Technology - Telecommunications and information exchange between systems - Elements of Management Information Related to OSI network Layer Standards", Committee Draft International Standard 10733, November 1990. 8. Security Considerations Security issues are not discussed in this memo. Throop [Page 68] RFC 1382 X.25 Packet Layer MIB November 1992 9. Authors' Addresses Dean D. Throop Data General Corporation 62 Alexander Dr. Research Triangle Park, NC 27709 Phone: (919)248-8421 EMail: throop@dg-rtp.dg.com Throop [Page 69] snmp-mibs-downloader-1.1/mibrfcs/rfc1414.txt0000644000000000000000000003352511402176071015563 0ustar Network Working Group M. St. Johns Request for Comments: 1414 US Department of Defense M. Rose Dover Beach Consulting, Inc. February 1993 Identification MIB Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. This document is a product of the TCP Client Identity Protocol Working Group of the Internet Engineering Task Force (IETF). Table of Contents 1. The Network Management Framework ....................... 2 2. Identification MIB ..................................... 3 3. Definitions ............................................ 3 3.1 Conformance Groups .................................... 3 3.2 Textual Conventions ................................... 3 3.3 The Ident information Group ........................... 3 4. Security Considerations ................................ 6 5. References ............................................. 6 6. Authors' Addresses ..................................... 7 St. Johns & Rose [Page 1] RFC 1414 Identification MIB February 1993 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 [2] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 [3] defines a more concise description mechanism, which is wholly consistent with the SMI. STD 17/RFC 1213 [4] which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15/RFC 1157 [5] which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using RFC 1212's OBJECT-TYPE macro. At a minimum, each object has a name, a syntax, an access-level, and an implementation-status. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 object descriptor, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 [6] language is used for this purpose. However, RFC 1155 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The access-level of an object type defines whether it makes "protocol sense" to read and/or write the value of an instance of the object type. (This access-level is independent of any administrative authorization policy.) The implementation-status of an object type indicates whether the object is mandatory, optional, obsolete, or deprecated. St. Johns & Rose [Page 2] RFC 1414 Identification MIB February 1993 2. Identification MIB The Identification MIB defines a uniform set of objects useful for identifying users associated with TCP connections. End-systems which support TCP may, at their option, implement this MIB. However, administrators should read Section 4 ("Security Considerations") before enabling these MIB objects. 3. Definitions RFC1414-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort FROM RFC1213-MIB; ident OBJECT IDENTIFIER ::= { mib-2 24 } -- conformance groups identInfo OBJECT IDENTIFIER ::= { ident 1 } -- textual conventions -- none -- the ident information system group -- -- implementation of this group is mandatory identTable OBJECT-TYPE SYNTAX SEQUENCE OF IdentEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing user information for TCP connections. Note that this table contains entries for all TCP connections on a managed system. The corresponding instance of tcpConnState (defined in MIB-II) indicates the state of a particular St. Johns & Rose [Page 3] RFC 1414 Identification MIB February 1993 connection." ::= { identInfo 1 } identEntry OBJECT-TYPE SYNTAX IdentEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "User information about a particular TCP connection." INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { identTable 1 } IdentEntry ::= SEQUENCE { identStatus INTEGER, identOpSys OCTET STRING, identCharset OCTET STRING, identUserid OCTET STRING, identMisc OCTET STRING } identStatus OBJECT-TYPE SYNTAX INTEGER { noError(1), unknownError(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether user information for the associated TCP connection can be determined. A value of `noError(1)' indicates that user information is available. A value of `unknownError(2)' indicates that user information is not available." ::= { identEntry 1 } identOpSys OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..40)) ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the type of operating system in use. In addition to identifying an operating system, each assignment made for this purpose also (implicitly) identifies the textual format and St. Johns & Rose [Page 4] RFC 1414 Identification MIB February 1993 maximum size of the corresponding identUserid and identMisc objects. The legal values for the `indentOpSys' strings are those listed in the SYSTEM NAMES section of the most recent edition of the ASSIGNED NUMBERS RFC [8]." ::= { identEntry 2 } identCharset OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..40)) ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the repertoire of the corresponding identUserid and identMisc objects. The legal values for the `identCharset' strings are those listed in the CHARACTER SET section of the most recent edition of the ASSIGNED NUMBERS RFC [8]." ::= { identEntry 3 } identUserid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the user's identity. Interpretation of this object requires examination of the corresponding value of the identOpSys and identCharset objects." ::= { identEntry 4 } identMisc OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Indicates miscellaneous information about the user. Interpretation of this object requires examination of the corresponding value of the identOpSys and identCharset objects." ::= { identEntry 5 } END St. Johns & Rose [Page 5] RFC 1414 Identification MIB February 1993 4. Security Considerations The information available through this MIB is at most as trustworthy as the host providing it OR the organization operating the host. For example, a PC in an open lab has few if any controls on it to prevent a user from having an SNMP query return any identifier the user wants. Likewise, if the host has been compromised the information returned may be completely erroneous and misleading. This portion of the MIB space should only be used to gain hints as to who "owns" a particular TCP connection -- information returned should NOT be considered authoritative for at least the reasons described above. At best, this MIB provides some additional auditing information with respect to TCP connections. At worse it can provide misleading, incorrect or maliciously incorrect information. The use of the information contained in this MIB for other than auditing or normal network management functions is strongly discouraged. Specifically, using information from this MIB space to make access control decisions - either as the primary method (i.e., no other checks) or as an adjunct to other methods may result in a weakening of normal system security. This MIB provides access to information about users, entities, objects or processes which some systems might normally consider private. The information accessible through this MIB is a rough analog of the CallerID services provided by some phone companies and many of the same privacy consideration and arguments that apply to CallerID service apply to this MIB space. If you wouldn't run a "finger" server [7] due to privacy considerations, you might not want to provide access to this MIB space on a general basis. Access to this portion of the MIB tree may be controlled under the normal methods available through SNMP agent implementations. 7. References [1] St. Johns, M., "Identification Protocol", RFC 1413, US Department of Defense, February 1993. [2] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [3] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. St. Johns & Rose [Page 6] RFC 1414 Identification MIB February 1993 [4] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [7] Zimmerman, D., "The Finger User Information Protocol", RFC 1288, Center for Discrete Mathematics and Theoretical Computer Science, December 1991. [8] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. 8. Authors' Addresses Michael C. St. Johns U.S. Department of Defense DARPA/CSTO 3701 N. Fairfax Dr Arlington, VA 22203 Phone: (703) 696-2271 EMail: stjohns@DARPA.MIL Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 Phone: (415) 968-1052 EMail: mrose@dbc.mtview.ca.us St. Johns & Rose [Page 7] snmp-mibs-downloader-1.1/mibrfcs/rfc1447.txt0000644000000000000000000023557211402176071015577 0ustar Network Working Group K. McCloghrie Request for Comments: 1447 Hughes LAN Systems J. Galvin Trusted Information Systems April 1993 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) Status of this Memo This RFC specifes an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Table of Contents 1 Introduction .......................................... 2 1.1 A Note on Terminology ............................... 2 2 Definitions ........................................... 3 3.1 Textual Conventions ................................. 4 3.2 Administrative Assignments .......................... 7 3.2.1 Initial Party and Context Identifiers ............. 8 3.3 Object Assignments .................................. 16 3.4 The SNMPv2 Party Database Group ..................... 16 3.5 The SNMPv2 Contexts Database Group .................. 29 3.5 The SNMPv2 Access Privileges Database Group ......... 36 3.6 The MIB View Database Group ......................... 40 3.7 Conformance Information ............................. 45 3.7.1 Compliance Statements ............................. 45 3.7.2 Units of Conformance .............................. 47 3 Acknowledgments ....................................... 48 4 References ............................................ 49 5 Security Considerations ............................... 50 6 Authors' Addresses .................................... 50 Galvin & McCloghrie [Page 1] RFC 1447 Party MIB for SNMPv2 April 1993 1. Introduction A network management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines both authentication and authorization policies. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled through access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. 1.1. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). Galvin & McCloghrie [Page 2] RFC 1447 Party MIB for SNMPv2 April 1993 2. Definitions SNMPv2-PARTY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, snmpModules, UInteger32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; partyMIB MODULE-IDENTITY LAST-UPDATED "9304010000Z" ORGANIZATION "IETF SNMP Security Working Group" CONTACT-INFO " Keith McCloghrie Postal: Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 US Tel: +1 415 966 7934 Fax: +1 415 960 3738 E-mail: kzm@hls.com" DESCRIPTION "The MIB module describing SNMPv2 parties." ::= { snmpModules 3 } Galvin & McCloghrie [Page 3] RFC 1447 Party MIB for SNMPv2 April 1993 -- textual conventions Party ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a SNMPv2 party identifier. Note that agents may impose implementation limitations on the length of OIDs used to identify Parties. As such, management stations creating new parties should be aware that using an excessively long OID may result in the agent refusing to perform the set operation and instead returning the appropriate error response, e.g., noCreation." SYNTAX OBJECT IDENTIFIER TAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. For snmpUDPDomain, a TAddress is 6 octets long, the initial 4 octets containing the IP-address in network-byte order and the last 2 containing the UDP port in network-byte order. Consult [5] for further information on snmpUDPDomain." SYNTAX OCTET STRING Galvin & McCloghrie [Page 4] RFC 1447 Party MIB for SNMPv2 April 1993 Clock ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A party's authentication clock - a non-negative integer which is incremented as specified/allowed by the party's Authentication Protocol. For noAuth, a party's authentication clock is unused and its value is undefined. For v2md5AuthProtocol, a party's authentication clock is a relative clock with 1-second granularity." SYNTAX UInteger32 Context ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a SNMPv2 context identifier. Note that agents may impose implementation limitations on the length of OIDs used to identify Contexts. As such, management stations creating new contexts should be aware that using an excessively long OID may result in the agent refusing to perform the set operation and instead returning the appropriate error response, e.g., noCreation." SYNTAX OBJECT IDENTIFIER Galvin & McCloghrie [Page 5] RFC 1447 Party MIB for SNMPv2 April 1993 StorageType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Describes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is nonVolatile(3) is backed up by stable storage. A row which is permanent(4) cannot be changed nor deleted." SYNTAX INTEGER { other(1), -- eh? volatile(2), -- e.g., in RAM nonVolatile(3), -- e.g., in NVRAM permanent(4) -- e.g., in ROM } Galvin & McCloghrie [Page 6] RFC 1447 Party MIB for SNMPv2 April 1993 -- administrative assignments partyAdmin OBJECT IDENTIFIER ::= { partyMIB 1 } -- definitions of security protocols partyProtocols OBJECT IDENTIFIER ::= { partyAdmin 1 } -- the protocol without authentication noAuth OBJECT IDENTIFIER ::= { partyProtocols 1 } -- the protocol without privacy noPriv OBJECT IDENTIFIER ::= { partyProtocols 2 } -- the DES Privacy Protocol [4] desPrivProtocol OBJECT IDENTIFIER ::= { partyProtocols 3 } -- the MD5 Authentication Protocol [4] v2md5AuthProtocol OBJECT IDENTIFIER ::= { partyProtocols 4 } -- definitions of temporal domains temporalDomains OBJECT IDENTIFIER ::= { partyAdmin 2 } -- this temporal domain refers to management information -- at the current time currentTime OBJECT IDENTIFIER ::= { temporalDomains 1 } -- this temporal domain refers to management information -- upon the next re-initialization of the managed device restartTime OBJECT IDENTIFIER ::= { temporalDomains 2 } -- the temporal domain { cacheTime N } refers to management -- information that is cached and guaranteed to be at most -- N seconds old cacheTime OBJECT IDENTIFIER ::= { temporalDomains 3 } Galvin & McCloghrie [Page 7] RFC 1447 Party MIB for SNMPv2 April 1993 -- Definition of Initial Party and Context Identifiers -- When devices are installed, they need to be configured -- with an initial set of SNMPv2 parties and contexts. The -- configuration of SNMPv2 parties and contexts requires (among -- other things) the assignment of several OBJECT IDENTIFIERs. -- Any local network administration can obtain the delegated -- authority necessary to assign its own OBJECT IDENTIFIERs. -- However, to provide for those administrations who have not -- obtained the necessary authority, this document allocates a -- branch of the naming tree for use with the following -- conventions. initialPartyId OBJECT IDENTIFIER ::= { partyAdmin 3 } initialContextId OBJECT IDENTIFIER ::= { partyAdmin 4 } -- Note these are identified as "initial" party and context -- identifiers since these allow secure SNMPv2 communication -- to proceed, thereby allowing further SNMPv2 parties to be -- configured through use of the SNMPv2 itself. -- The following definitions identify a party identifier, and -- specify the initial values of various object instances -- indexed by that identifier. In addition, the SNMPv2 -- context, access control policy, and MIB view information -- assigned, by convention, are identified. Galvin & McCloghrie [Page 8] RFC 1447 Party MIB for SNMPv2 April 1993 -- Party Identifiers for use as initial SNMPv2 parties -- at IP address a.b.c.d -- Note that for all OBJECT IDENTIFIERs assigned under -- initialPartyId, the four sub-identifiers immediately -- following initialPartyId represent the four octets of -- an IP address. Initial party identifiers for other address -- families are assigned under a different OBJECT IDENTIFIER, -- as defined elsewhere. -- Devices which support SNMPv2 as entities acting in an -- agent role, and accessed via the snmpUDPDomain transport -- domain, are required to be configured with the appropriate -- set of the following as implicit assignments as and when -- they are configured with an IP address. The appropriate -- set is all those applicable to the authentication and -- privacy protocols supported by the device. Galvin & McCloghrie [Page 9] RFC 1447 Party MIB for SNMPv2 April 1993 -- a noAuth/noPriv party which executes at the agent -- partyIdentity = { initialPartyId a b c d 1 } -- partyIndex = 1 -- partyTDomain = snmpUDPDomain -- partyTAddress = a.b.c.d, 161 -- partyLocal = true (in agent's database) -- partyAuthProtocol = noAuth -- partyAuthClock = 0 -- partyAuthPrivate = ''H (the empty string) -- partyAuthPublic = ''H (the empty string) -- partyAuthLifetime = 0 -- partyPrivProtocol = noPriv -- partyPrivPrivate = ''H (the empty string) -- partyPrivPublic = ''H (the empty string) -- a noAuth/noPriv party which executes at a manager -- partyIdentity = { initialPartyId a b c d 2 } -- partyIndex = 2 -- partyTDomain = snmpUDPDomain -- partyTAddress = assigned by local administration -- partyLocal = false (in agent's database) -- partyAuthProtocol = noAuth -- partyAuthClock = 0 -- partyAuthPrivate = ''H (the empty string) -- partyAuthPublic = ''H (the empty string) -- partyAuthLifetime = 0 -- partyPrivProtocol = noPriv -- partyPrivPrivate = ''H (the empty string) -- partyPrivPublic = ''H (the empty string) Galvin & McCloghrie [Page 10] RFC 1447 Party MIB for SNMPv2 April 1993 -- a md5Auth/noPriv party which executes at the agent -- partyIdentity = { initialPartyId a b c d 3 } -- partyIndex = 3 -- partyTDomain = snmpUDPDomain -- partyTAddress = a.b.c.d, 161 -- partyLocal = true (in agent's database) -- partyAuthProtocol = v2md5AuthProtocol -- partyAuthClock = 0 -- partyAuthPrivate = assigned by local administration -- partyAuthPublic = ''H (the empty string) -- partyAuthLifetime = 300 -- partyPrivProtocol = noPriv -- partyPrivPrivate = ''H (the empty string) -- partyPrivPublic = ''H (the empty string) -- a md5Auth/noPriv party which executes at a manager -- partyIdentity = { initialPartyId a b c d 4 } -- partyIndex = 4 -- partyTDomain = snmpUDPDomain -- partyTAddress = assigned by local administration -- partyLocal = false (in agent's database) -- partyAuthProtocol = v2md5AuthProtocol -- partyAuthClock = 0 -- partyAuthPrivate = assigned by local administration -- partyAuthPublic = ''H (the empty string) -- partyAuthLifetime = 300 -- partyPrivProtocol = noPriv -- partyPrivPrivate = ''H (the empty string) -- partyPrivPublic = ''H (the empty string) Galvin & McCloghrie [Page 11] RFC 1447 Party MIB for SNMPv2 April 1993 -- a md5Auth/desPriv party which executes at the agent -- partyIdentity = { initialPartyId a b c d 5 } -- partyIndex = 5 -- partyTDomain = snmpUDPDomain -- partyTAddress = a.b.c.d, 161 -- partyLocal = true (in agent's database) -- partyAuthProtocol = v2md5AuthProtocol -- partyAuthClock = 0 -- partyAuthPrivate = assigned by local administration -- partyAuthPublic = ''H (the empty string) -- partyAuthLifetime = 300 -- partyPrivProtocol = desPrivProtocol -- partyPrivPrivate = assigned by local administration -- partyPrivPublic = ''H (the empty string) -- a md5Auth/desPriv party which executes at a manager -- partyIdentity = { initialPartyId a b c d 6 } -- partyIndex = 6 -- partyTDomain = snmpUDPDomain -- partyTAddress = assigned by local administration -- partyLocal = false (in agent's database) -- partyAuthProtocol = v2md5AuthProtocol -- partyAuthClock = 0 -- partyAuthPrivate = assigned by local administration -- partyAuthPublic = ''H (the empty string) -- partyAuthLifetime = 300 -- partyPrivProtocol = desPrivProtocol -- partyPrivPrivate = assigned by local administration -- partyPrivPublic = ''H (the empty string) Galvin & McCloghrie [Page 12] RFC 1447 Party MIB for SNMPv2 April 1993 -- the initial SNMPv2 contexts assigned, by convention, are: -- contextIdentity = { initialContextId a b c d 1 } -- contextIndex = 1 -- contextLocal = true (in agent's database) -- contextViewIndex = 1 -- contextLocalEntity = ''H (the empty string) -- contextLocalTime = currentTime -- contextProxyDstParty = { 0 0 } -- contextProxySrcParty = { 0 0 } -- contextProxyContext = { 0 0 } -- contextIdentity = { initialContextId a b c d 2 } -- contextIndex = 2 -- contextLocal = true (in agent's database) -- contextViewIndex = 2 -- contextLocalEntity = ''H (the empty string) -- contextLocalTime = currentTime -- contextProxyDstParty = { 0 0 } -- contextProxySrcParty = { 0 0 } -- contextProxyContext = { 0 0 } Galvin & McCloghrie [Page 13] RFC 1447 Party MIB for SNMPv2 April 1993 -- The initial access control policy assigned, by -- convention, is: -- aclTarget = 1 -- aclSubject = 2 -- aclResources = 1 -- aclPrivileges = 35 (Get, Get-Next & Get-Bulk) -- aclTarget = 2 -- aclSubject = 1 -- aclResources = 1 -- aclPrivileges = 132 (Response & SNMPv2-Trap) -- aclTarget = 3 -- aclSubject = 4 -- aclResources = 2 -- aclPrivileges = 43 (Get, Get-Next, Set & Get-Bulk) -- aclTarget = 4 -- aclSubject = 3 -- aclResources = 2 -- aclPrivileges = 4 (Response) -- aclTarget = 5 -- aclSubject = 6 -- aclResources = 2 -- aclPrivileges = 43 (Get, Get-Next, Set & Get-Bulk) -- aclTarget = 6 -- aclSubject = 5 -- aclResources = 2 -- aclPrivileges = 4 (Response) -- Note that the initial context and access control -- information assigned above, by default, to the -- md5Auth/desPriv parties are identical to those assigned to -- the md5Auth/noPriv parties. However, each administration -- may choose to have different authorization policies, -- depending on whether privacy is used. Galvin & McCloghrie [Page 14] RFC 1447 Party MIB for SNMPv2 April 1993 -- The initial MIB views assigned, by convention, are: -- viewIndex = 1 -- viewSubtree = system -- viewMask = ''H -- viewType = included -- viewIndex = 1 -- viewSubtree = snmpStats -- viewMask = ''H -- viewType = included -- viewIndex = 1 -- viewSubtree = snmpParties -- viewMask = ''H -- viewType = included -- viewIndex = 2 -- viewSubtree = internet -- viewMask = ''H -- viewType = included -- Note that full access to the partyTable, contextTable, -- aclTable, and viewTable gives a manager the ability to -- configure any parties with any/all capabilities (the -- equivalent of "root" access). A lesser manager can be -- given access only to the partyTable so that it can -- maintain its own parties, but not increase/decrease -- their capabilities. Such a lesser manager can also -- create new parties but they are of no use to it. Galvin & McCloghrie [Page 15] RFC 1447 Party MIB for SNMPv2 April 1993 -- object assignments partyMIBObjects OBJECT IDENTIFIER ::= { partyMIB 2 } -- the SNMPv2 party database group snmpParties OBJECT IDENTIFIER ::= { partyMIBObjects 1 } partyTable OBJECT-TYPE SYNTAX SEQUENCE OF PartyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNMPv2 Party database." ::= { snmpParties 1 } partyEntry OBJECT-TYPE SYNTAX PartyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about a particular SNMPv2 party." INDEX { IMPLIED partyIdentity } ::= { partyTable 1 } Galvin & McCloghrie [Page 16] RFC 1447 Party MIB for SNMPv2 April 1993 PartyEntry ::= SEQUENCE { partyIdentity Party, partyIndex INTEGER, partyTDomain OBJECT IDENTIFIER, partyTAddress TAddress, partyMaxMessageSize INTEGER, partyLocal TruthValue, partyAuthProtocol OBJECT IDENTIFIER, partyAuthClock Clock, partyAuthPrivate OCTET STRING, partyAuthPublic OCTET STRING, partyAuthLifetime INTEGER, partyPrivProtocol OBJECT IDENTIFIER, partyPrivPrivate OCTET STRING, partyPrivPublic OCTET STRING, partyCloneFrom Party, partyStorageType StorageType, partyStatus RowStatus } partyIdentity OBJECT-TYPE SYNTAX Party MAX-ACCESS not-accessible STATUS current DESCRIPTION "A party identifier uniquely identifying a particular SNMPv2 party." ::= { partyEntry 1 } partyIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each SNMPv2 party. The value for each SNMPv2 party must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { partyEntry 2 } Galvin & McCloghrie [Page 17] RFC 1447 Party MIB for SNMPv2 April 1993 partyTDomain OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the kind of transport service by which the party receives network management traffic." DEFVAL { snmpUDPDomain } ::= { partyEntry 3 } partyTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The transport service address by which the party receives network management traffic, formatted according to the corresponding value of partyTDomain. For snmpUDPDomain, partyTAddress is formatted as a 4-octet IP Address concatenated with a 2-octet UDP port number." DEFVAL { '000000000000'H } ::= { partyEntry 4 } partyMaxMessageSize OBJECT-TYPE SYNTAX INTEGER (484..65507) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum length in octets of a SNMPv2 message which this party will accept. For parties which execute at an agent, the agent initializes this object to the maximum length supported by the agent, and does not let the object be set to any larger value. For parties which do not execute at the agent, the agent must allow the manager to set this object to any legal value, even if it is larger than the agent can generate." DEFVAL { 484 } ::= { partyEntry 5 } Galvin & McCloghrie [Page 18] RFC 1447 Party MIB for SNMPv2 April 1993 partyLocal OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether this party executes at this SNMPv2 entity. If this object has a value of true(1), then the SNMPv2 entity will listen for SNMPv2 messages on the partyTAddress associated with this party. If this object has the value false(2), then the SNMPv2 entity will not listen for SNMPv2 messages on the partyTAddress associated with this party." DEFVAL { false } ::= { partyEntry 6 } partyAuthProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The authentication protocol by which all messages generated by the party are authenticated as to origin and integrity. The value noAuth signifies that messages generated by the party are not authenticated. Once an instance of this object is created, its value can not be changed." DEFVAL { v2md5AuthProtocol } ::= { partyEntry 7 } Galvin & McCloghrie [Page 19] RFC 1447 Party MIB for SNMPv2 April 1993 partyAuthClock OBJECT-TYPE SYNTAX Clock MAX-ACCESS read-create STATUS current DESCRIPTION "The authentication clock which represents the local notion of the current time specific to the party. This value must not be decremented unless the party's private authentication key is changed simultaneously." DEFVAL { 0 } ::= { partyEntry 8 } Galvin & McCloghrie [Page 20] RFC 1447 Party MIB for SNMPv2 April 1993 partyAuthPrivate OBJECT-TYPE SYNTAX OCTET STRING -- for v2md5AuthProtocol: (SIZE (16)) MAX-ACCESS read-create STATUS current DESCRIPTION "An encoding of the party's private authentication key which may be needed to support the authentication protocol. Although the value of this variable may be altered by a management operation (e.g., a SNMPv2 Set-Request), its value can never be retrieved by a management operation: when read, the value of this variable is the zero length OCTET STRING. The private authentication key is NOT directly represented by the value of this variable, but rather it is represented according to an encoding. This encoding is the bitwise exclusive-OR of the old key with the new key, i.e., of the old private authentication key (prior to the alteration) with the new private authentication key (after the alteration). Thus, when processing a received protocol Set operation, the new private authentication key is obtained from the value of this variable as the result of a bitwise exclusive-OR of the variable's value and the old private authentication key. In calculating the exclusive-OR, if the old key is shorter than the new key, zero-valued padding is appended to the old key. If no value for the old key exists, a zero-length OCTET STRING is used in the calculation." DEFVAL { ''H } -- the empty string ::= { partyEntry 9 } Galvin & McCloghrie [Page 21] RFC 1447 Party MIB for SNMPv2 April 1993 partyAuthPublic OBJECT-TYPE SYNTAX OCTET STRING -- for v2md5AuthProtocol: (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "A publically-readable value for the party. Depending on the party's authentication protocol, this value may be needed to support the party's authentication protocol. Alternatively, it may be used by a manager during the procedure for altering secret information about a party. (For example, by altering the value of an instance of this object in the same SNMPv2 Set-Request used to update an instance of partyAuthPrivate, a subsequent Get-Request can determine if the Set- Request was successful in the event that no response to the Set-Request is received, see [4].) The length of the value is dependent on the party's authentication protocol. If not used by the authentication protocol, it is recommended that agents support values of any length up to and including the length of the corresponding partyAuthPrivate object." DEFVAL { ''H } -- the empty string ::= { partyEntry 10 } Galvin & McCloghrie [Page 22] RFC 1447 Party MIB for SNMPv2 April 1993 partyAuthLifetime OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The lifetime (in units of seconds) which represents an administrative upper bound on acceptable delivery delay for protocol messages generated by the party. Once an instance of this object is created, its value can not be changed." DEFVAL { 300 } ::= { partyEntry 11 } partyPrivProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The privacy protocol by which all protocol messages received by the party are protected from disclosure. The value noPriv signifies that messages received by the party are not protected. Once an instance of this object is created, its value can not be changed." DEFVAL { noPriv } ::= { partyEntry 12 } Galvin & McCloghrie [Page 23] RFC 1447 Party MIB for SNMPv2 April 1993 partyPrivPrivate OBJECT-TYPE SYNTAX OCTET STRING -- for desPrivProtocol: (SIZE (16)) MAX-ACCESS read-create STATUS current DESCRIPTION "An encoding of the party's private encryption key which may be needed to support the privacy protocol. Although the value of this variable may be altered by a management operation (e.g., a SNMPv2 Set-Request), its value can never be retrieved by a management operation: when read, the value of this variable is the zero length OCTET STRING. The private encryption key is NOT directly represented by the value of this variable, but rather it is represented according to an encoding. This encoding is the bitwise exclusive-OR of the old key with the new key, i.e., of the old private encryption key (prior to the alteration) with the new private encryption key (after the alteration). Thus, when processing a received protocol Set operation, the new private encryption key is obtained from the value of this variable as the result of a bitwise exclusive-OR of the variable's value and the old private encryption key. In calculating the exclusive-OR, if the old key is shorter than the new key, zero-valued padding is appended to the old key. If no value for the old key exists, a zero-length OCTET STRING is used in the calculation." DEFVAL { ''H } -- the empty string ::= { partyEntry 13 } Galvin & McCloghrie [Page 24] RFC 1447 Party MIB for SNMPv2 April 1993 partyPrivPublic OBJECT-TYPE SYNTAX OCTET STRING -- for desPrivProtocol: (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "A publically-readable value for the party. Depending on the party's privacy protocol, this value may be needed to support the party's privacy protocol. Alternatively, it may be used by a manager as a part of its procedure for altering secret information about a party. (For example, by altering the value of an instance of this object in the same SNMPv2 Set-Request used to update an instance of partyPrivPrivate, a subsequent Get-Request can determine if the Set- Request was successful in the event that no response to the Set-Request is received, see [4].) The length of the value is dependent on the party's privacy protocol. If not used by the privacy protocol, it is recommended that agents support values of any length up to and including the length of the corresponding partyPrivPrivate object." DEFVAL { ''H } -- the empty string ::= { partyEntry 14 } Galvin & McCloghrie [Page 25] RFC 1447 Party MIB for SNMPv2 April 1993 partyCloneFrom OBJECT-TYPE SYNTAX Party MAX-ACCESS read-create STATUS current DESCRIPTION "The identity of a party to clone authentication and privacy parameters from. When read, the value { 0 0 } is returned. This value must be written exactly once, when the associated instance of partyStatus either does not exist or has the value `notReady'. When written, the value identifies a party, the cloning party, whose status column has the value `active'. The cloning party is used in two ways. One, if instances of the following objects do not exist for the party being created, then they are created with values identical to those of the corresponding objects for the cloning party: partyAuthProtocol partyAuthPublic partyAuthLifetime partyPrivProtocol partyPrivPublic Two, instances of the following objects are updated using the corresponding values of the cloning party: partyAuthPrivate partyPrivPrivate (e.g., the value of the cloning party's instance of the partyAuthPrivate object is XOR'd with the value of the partyAuthPrivate instances of the party being created.)" ::= { partyEntry 15 } Galvin & McCloghrie [Page 26] RFC 1447 Party MIB for SNMPv2 April 1993 partyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the partyTable." DEFVAL { nonVolatile } ::= { partyEntry 16 } partyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the partyTable. A party is not qualified for activation until instances of all columns of its partyEntry row have an appropriate value. In particular: A value must be written to the Party's partyCloneFrom object. If the Party's partyAuthProtocol object has the value md5AuthProtocol, then the corresponding instance of partyAuthPrivate must contain a secret of the appropriate length. Further, at least one management protocol set operation updating the value of the party's partyAuthPrivate object must be successfully processed, before the partyAuthPrivate column is considered appropriately configured. If the Party's partyPrivProtocol object has the value desPrivProtocol, then the corresponding instance of partyPrivPrivate must contain a secret of the appropriate length. Further, at least one management protocol set operation updating the value of the party's partyPrivPrivate object must be successfully processed, before the partyPrivPrivate column is considered appropriately configured. Galvin & McCloghrie [Page 27] RFC 1447 Party MIB for SNMPv2 April 1993 Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the partyStatus column is `notReady'." ::= { partyEntry 17 } Galvin & McCloghrie [Page 28] RFC 1447 Party MIB for SNMPv2 April 1993 -- the SNMPv2 contexts database group snmpContexts OBJECT IDENTIFIER ::= { partyMIBObjects 2 } contextTable OBJECT-TYPE SYNTAX SEQUENCE OF ContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNMPv2 Context database." ::= { snmpContexts 1 } contextEntry OBJECT-TYPE SYNTAX ContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about a particular SNMPv2 context." INDEX { IMPLIED contextIdentity } ::= { contextTable 1 } ContextEntry ::= SEQUENCE { contextIdentity Context, contextIndex INTEGER, contextLocal TruthValue, contextViewIndex INTEGER, contextLocalEntity OCTET STRING, contextLocalTime OBJECT IDENTIFIER, contextProxyDstParty Party, contextProxySrcParty Party, contextProxyContext OBJECT IDENTIFIER, contextStorageType StorageType, contextStatus RowStatus } Galvin & McCloghrie [Page 29] RFC 1447 Party MIB for SNMPv2 April 1993 contextIdentity OBJECT-TYPE SYNTAX Context MAX-ACCESS not-accessible STATUS current DESCRIPTION "A context identifier uniquely identifying a particular SNMPv2 context." ::= { contextEntry 1 } contextIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each SNMPv2 context. The value for each SNMPv2 context must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { contextEntry 2 } contextLocal OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether this context is realized by this SNMPv2 entity." DEFVAL { true } ::= { contextEntry 3 } Galvin & McCloghrie [Page 30] RFC 1447 Party MIB for SNMPv2 April 1993 contextViewIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of an instance of this object is zero, then this corresponding conceptual row in the contextTable refers to a SNMPv2 context which identifies a proxy relationship; the values of the corresponding instances of the contextProxyDstParty, contextProxySrcParty, and contextProxyContext objects provide further information on the proxy relationship. Otherwise, if the value of an instance of this object is greater than zero, then this corresponding conceptual row in the contextTable refers to a SNMPv2 context which identifies a MIB view of a locally accessible entity; the value of the instance identifies the particular MIB view which has the same value of viewIndex; and the value of the corresponding instances of the contextLocalEntity and contextLocalTime objects provide further information on the local entity and its temporal domain." ::= { contextEntry 4 } Galvin & McCloghrie [Page 31] RFC 1447 Party MIB for SNMPv2 April 1993 contextLocalEntity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object identifies the local entity whose management information is in the SNMPv2 context's MIB view. The empty string indicates that the MIB view contains the SNMPv2 entity's own local management information; otherwise, a non-empty string indicates that the MIB view contains management information of some other local entity, e.g., 'Repeater1'." DEFVAL { ''H } -- the empty string ::= { contextEntry 5 } contextLocalTime OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object identifies the temporal context of the management information in the MIB view." DEFVAL { currentTime } ::= { contextEntry 6 } Galvin & McCloghrie [Page 32] RFC 1447 Party MIB for SNMPv2 April 1993 contextProxyDstParty OBJECT-TYPE SYNTAX Party MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the corresponding instance of the contextViewIndex is equal to zero, then the value of an instance of this object identifies a SNMPv2 party which is the proxy destination of a proxy relationship. If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object is { 0 0 }." ::= { contextEntry 7 } contextProxySrcParty OBJECT-TYPE SYNTAX Party MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the corresponding instance of the contextViewIndex is equal to zero, then the value of an instance of this object identifies a SNMPv2 party which is the proxy source of a proxy relationship. Interpretation of an instance of this object depends upon the value of the transport domain associated with the SNMPv2 party used as the proxy destination in this proxy relationship. If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object is { 0 0 }." ::= { contextEntry 8 } Galvin & McCloghrie [Page 33] RFC 1447 Party MIB for SNMPv2 April 1993 contextProxyContext OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the corresponding instance of the contextViewIndex is equal to zero, then the value of an instance of this object identifies the context of a proxy relationship. Interpretation of an instance of this object depends upon the value of the transport domain associated with the SNMPv2 party used as the proxy destination in this proxy relationship. If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object is { 0 0 }." ::= { contextEntry 9 } contextStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the contextTable." DEFVAL { nonVolatile } ::= { contextEntry 10 } Galvin & McCloghrie [Page 34] RFC 1447 Party MIB for SNMPv2 April 1993 contextStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the contextTable. A context is not qualified for activation until instances of all corresponding columns have the appropriate value. In particular, if the context's contextViewIndex is greater than zero, then the viewStatus column of the associated conceptual row(s) in the viewTable must have the value `active'. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the contextStatus column is `notReady'." ::= { contextEntry 11 } Galvin & McCloghrie [Page 35] RFC 1447 Party MIB for SNMPv2 April 1993 -- the SNMPv2 access privileges database group snmpAccess OBJECT IDENTIFIER ::= { partyMIBObjects 3 } aclTable OBJECT-TYPE SYNTAX SEQUENCE OF AclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The access privileges database." ::= { snmpAccess 1 } aclEntry OBJECT-TYPE SYNTAX AclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The access privileges for a particular subject SNMPv2 party when asking a particular target SNMPv2 party to access a particular SNMPv2 context." INDEX { aclTarget, aclSubject, aclResources } ::= { aclTable 1 } AclEntry ::= SEQUENCE { aclTarget INTEGER, aclSubject INTEGER, aclResources INTEGER, aclPrivileges INTEGER, aclStorageType StorageType, aclStatus RowStatus } Galvin & McCloghrie [Page 36] RFC 1447 Party MIB for SNMPv2 April 1993 aclTarget OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of an instance of this object identifies a SNMPv2 party which is the target of an access control policy, and has the same value as the instance of the partyIndex object for that party." ::= { aclEntry 1 } aclSubject OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of an instance of this object identifies a SNMPv2 party which is the subject of an access control policy, and has the same value as the instance of the partyIndex object for that SNMPv2 party." ::= { aclEntry 2 } aclResources OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of an instance of this object identifies a SNMPv2 context in an access control policy, and has the same value as the instance of the contextIndex object for that SNMPv2 context." ::= { aclEntry 3 } Galvin & McCloghrie [Page 37] RFC 1447 Party MIB for SNMPv2 April 1993 aclPrivileges OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The access privileges which govern what management operations a particular target party may perform with respect to a particular SNMPv2 context when requested by a particular subject party. These privileges are specified as a sum of values, where each value specifies a SNMPv2 PDU type by which the subject party may request a permitted operation. The value for a particular PDU type is computed as 2 raised to the value of the ASN.1 context-specific tag for the appropriate SNMPv2 PDU type. The values (for the tags defined in [5]) are defined in [3] as: Get : 1 GetNext : 2 Response : 4 Set : 8 unused : 16 GetBulk : 32 Inform : 64 SNMPv2-Trap : 128 The null set is represented by the value zero." DEFVAL { 35 } -- Get, Get-Next & Get-Bulk ::= { aclEntry 4 } aclStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the aclTable." DEFVAL { nonVolatile } ::= { aclEntry 5 } Galvin & McCloghrie [Page 38] RFC 1447 Party MIB for SNMPv2 April 1993 aclStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the aclTable." ::= { aclEntry 6 } Galvin & McCloghrie [Page 39] RFC 1447 Party MIB for SNMPv2 April 1993 -- the MIB view database group snmpViews OBJECT IDENTIFIER ::= { partyMIBObjects 4 } viewTable OBJECT-TYPE SYNTAX SEQUENCE OF ViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about the MIB views known to this SNMPv2 entity. Each SNMPv2 context which is locally accessible has a single MIB view which is defined by two collections of view subtrees: the included view subtrees, and the excluded view subtrees. Every such subtree, both included and excluded, is defined in this table. To determine if a particular object instance is in a particular MIB view, compare the object instance's OBJECT IDENTIFIER with each of the MIB view's entries in this table. If none match, then the object instance is not in the MIB view. If one or more match, then the object instance is included in, or excluded from, the MIB view according to the value of viewType in the entry whose value of viewSubtree has the most sub- identifiers. If multiple entries match and have the same number of sub-identifiers, then the lexicographically greatest instance of viewType determines the inclusion or exclusion. An object instance's OBJECT IDENTIFIER X matches an entry in this table when the number of sub- identifiers in X is at least as many as in the value of viewSubtree for the entry, and each sub- identifier in the value of viewSubtree matches its corresponding sub-identifier in X. Two sub- identifiers match either if the corresponding bit of viewMask is zero (the 'wild card' value), or if they are equal. Due to this 'wild card' capability, we introduce Galvin & McCloghrie [Page 40] RFC 1447 Party MIB for SNMPv2 April 1993 the term, a 'family' of view subtrees, to refer to the set of subtrees defined by a particular combination of values of viewSubtree and viewMask. In the case where no 'wild card' is defined in viewMask, the family of view subtrees reduces to a single view subtree." ::= { snmpViews 1 } viewEntry OBJECT-TYPE SYNTAX ViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular family of view subtrees included in or excluded from a particular SNMPv2 context's MIB view. Implementations must not restrict the number of families of view subtrees for a given MIB view, except as dictated by resource constraints on the overall number of entries in the viewTable." INDEX { viewIndex, IMPLIED viewSubtree } ::= { viewTable 1 } ViewEntry ::= SEQUENCE { viewIndex INTEGER, viewSubtree OBJECT IDENTIFIER, viewMask OCTET STRING, viewType INTEGER, viewStorageType StorageType, viewStatus RowStatus } Galvin & McCloghrie [Page 41] RFC 1447 Party MIB for SNMPv2 April 1993 viewIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for each MIB view. The value for each MIB view must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { viewEntry 1 } viewSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "A MIB subtree." ::= { viewEntry 2 } viewMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The bit mask which, in combination with the corresponding instance of viewSubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub- identifier of viewSubtree, with the most significant bit of the i-th octet of this octet string value (extended if necessary, see below) corresponding to the (8*i - 7)-th sub-identifier, and the least significant bit of the i-th octet of this octet string corresponding to the (8*i)-th sub-identifier, where i is in the range 1 through 16. Each bit of this bit mask specifies whether or not the corresponding sub-identifiers must match when determining if an OBJECT IDENTIFIER is in this family of view subtrees; a '1' indicates that an exact match must occur; a '0' indicates 'wild card', i.e., any sub-identifier value matches. Galvin & McCloghrie [Page 42] RFC 1447 Party MIB for SNMPv2 April 1993 Thus, the OBJECT IDENTIFIER X of an object instance is contained in a family of view subtrees if the following criteria are met: for each sub-identifier of the value of viewSubtree, either: the i-th bit of viewMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of viewSubtree. If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of viewSubtree, then the bit mask is extended with 1's to be the required length. Note that when the value of this object is the zero-length string, this extension rule results in a mask of all-1's being used (i.e., no 'wild card'), and the family of view subtrees is the one view subtree uniquely identified by the corresponding instance of viewSubtree." DEFVAL { ''H } ::= { viewEntry 3 } Galvin & McCloghrie [Page 43] RFC 1447 Party MIB for SNMPv2 April 1993 viewType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The status of a particular family of view subtrees within the particular SNMPv2 context's MIB view. The value 'included(1)' indicates that the corresponding instances of viewSubtree and viewMask define a family of view subtrees included in the MIB view. The value 'excluded(2)' indicates that the corresponding instances of viewSubtree and viewMask define a family of view subtrees excluded from the MIB view." DEFVAL { included } ::= { viewEntry 4 } viewStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the viewTable." DEFVAL { nonVolatile } ::= { viewEntry 5 } viewStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the viewTable." ::= { viewEntry 6 } Galvin & McCloghrie [Page 44] RFC 1447 Party MIB for SNMPv2 April 1993 -- conformance information partyMIBConformance OBJECT IDENTIFIER ::= { partyMIB 3 } partyMIBCompliances OBJECT IDENTIFIER ::= { partyMIBConformance 1 } partyMIBGroups OBJECT IDENTIFIER ::= { partyMIBConformance 2 } -- compliance statements unSecurableCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Party MIB, but do not support any authentication or privacy protocols (i.e., only the noAuth and noPriv protocols are supported)." MODULE -- this module MANDATORY-GROUPS { partyMIBGroup } ::= { partyMIBCompliances 1 } partyNoPrivacyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Party MIB, and support an authentication protocol, but do not support any privacy protocols (i.e., only the noAuth, v2md5AuthProtocol, and noPriv protocols are supported)." MODULE -- this module MANDATORY-GROUPS { partyMIBGroup } ::= { partyMIBCompliances 2 } Galvin & McCloghrie [Page 45] RFC 1447 Party MIB for SNMPv2 April 1993 partyPrivacyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Party MIB, support an authentication protocol, and support a privacy protocol ONLY for the purpose of accessing security parameters. For all aclTable entries authorizing a subject and/or target SNMPv2 party whose privacy protocol is desPrivProtocol, to be used in accessing a SNMPv2 context, the MIB view for that SNMPv2 context shall include only those objects subordinate to partyMIBObjects, or a subset thereof, e.g., viewSubtree = { partyMIBObjects } viewMask = ''H viewType = { included } Any attempt to configure an entry in the partyTable, the contextTable, the aclTable or the viewTable such that a party using the desPrivProtocol would be authorized for use in accessing objects outside of the partyMIBObjects subtree shall result in the appropriate error response (e.g., wrongValue or inconsistentValue)." MODULE -- this module MANDATORY-GROUPS { partyMIBGroup } ::= { partyMIBCompliances 3 } Galvin & McCloghrie [Page 46] RFC 1447 Party MIB for SNMPv2 April 1993 fullPrivacyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Party MIB, support an authentication protocol, and support a privacy protocol without restrictions on its use." MODULE -- this module MANDATORY-GROUPS { partyMIBGroup } ::= { partyMIBCompliances 4 } -- units of conformance partyMIBGroup OBJECT-GROUP OBJECTS { partyIndex, partyTDomain, partyTAddress, partyMaxMessageSize, partyLocal, partyAuthProtocol, partyAuthClock, partyAuthPrivate, partyAuthPublic, partyAuthLifetime, partyPrivProtocol, partyPrivPrivate, partyPrivPublic, partyStorageType, partyStatus, partyCloneFrom, contextIndex, contextLocal, contextViewIndex, contextLocalEntity, contextLocalTime, contextStorageType, contextStatus, aclTarget, aclSubject, aclPrivileges, aclStorageType, aclStatus, viewMask, viewType, viewStorageType, viewStatus } STATUS current DESCRIPTION "The collection of objects allowing the description and configuration of SNMPv2 parties. Note that objects which support proxy relationships are not included in this conformance group." ::= { partyMIBGroups 1 } END Galvin & McCloghrie [Page 47] RFC 1447 Party MIB for SNMPv2 April 1993 3. Acknowledgments This document is based, almost entirely, on RFC 1353. Galvin & McCloghrie [Page 48] RFC 1447 Party MIB for SNMPv2 April 1993 4. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [3] Galvin, J., and McCloghrie, K., "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Galvin, J., and McCloghrie, K., "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1449, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. Galvin & McCloghrie [Page 49] RFC 1447 Party MIB for SNMPv2 April 1993 5. Security Considerations Security issues are not discussed in this memo. 6. Authors' Addresses Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 US Phone: +1 415 966 7934 Email: kzm@hls.com James M. Galvin Trusted Information Systems, Inc. 3060 Washington Road, Route 97 Glenwood, MD 21738 Phone: +1 301 854-6889 EMail: galvin@tis.com Galvin & McCloghrie [Page 50] snmp-mibs-downloader-1.1/mibrfcs/rfc1451.txt0000644000000000000000000017272711402176071015574 0ustar Network Working Group J. Case Request for Comments: 1451 SNMP Research, Inc. K. McCloghrie Hughes LAN Systems M. Rose Dover Beach Consulting, Inc. S. Waldbusser Carnegie Mellon University April 1993 Manager-to-Manager Management Information Base Status of this Memo This RFC specifes an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Table of Contents 1 Introduction .......................................... 2 1.1 A Note on Terminology ............................... 2 2 Overview .............................................. 3 2.1 A SNMPv2 Entity Acting in a Dual Role ............... 3 2.2 Alarms, Events, and Notifications ................... 3 2.3 Access Control ...................................... 4 3 Definitions ........................................... 6 3.1 The Alarm Group ..................................... 7 3.1.1 Alarm-Related Notifications ....................... 20 3.2 The Event Group ..................................... 21 3.3 Conformance Information ............................. 29 3.3.1 Compliance Statements ............................. 29 3.3.2 Units of Conformance .............................. 29 4 Acknowledgements ...................................... 31 5 References ............................................ 35 6 Security Considerations ............................... 36 7 Authors' Addresses .................................... 36 Case, McCloghrie, Rose & Waldbusser [Page 1] RFC 1451 Manager-to-Manager MIB April 1993 1. Introduction A network management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines both authentication and authorization policies. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled through access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. The management protocol, version 2 of the Simple Network Management Protocol [3], provides for the exchange of messages which convey management information between the agents and the management stations, including between management stations. It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. 1.1. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). Case, McCloghrie, Rose & Waldbusser [Page 2] RFC 1451 Manager-to-Manager MIB April 1993 2. Overview The purpose of this MIB is to provide the means for coordination between multiple management stations. That is, the means by which the controlling and monitoring functions of network management can be distributed amongst multiple management stations. Such distribution facilitates the scaling of network management solutions based on the SNMPv2 to meet the needs of very large networks, or of networks composed of multiple interconnected administrations. Specifically, this MIB provides the means for one management station to request management services from another management station. 2.1. A SNMPv2 Entity Acting in a Dual Role A management station providing services to other management station(s), is a SNMPv2 entity which acts in the dual role of both manager and agent; the requests for service are received through acting in an agent role (with respect to the managed objects defined in this MIB), and the requested services are performed through acting in a manager role. 2.2. Alarms, Events, and Notifications In this initial version, this MIB defines the concepts of "alarms", "events", and "notifications". Each alarm is a specific condition detected through the periodic (at a configured sampling interval) monitoring of the value of a specific management information variable. An example of an alarm condition is when the monitored variable falls outside a configured range. Each alarm condition triggers an event, and each event can cause (one or more) notifications to be reported to other management stations using the Inform-Request PDU. Specifically, this MIB defines three MIB tables and a number of scalar objects. The three tables are: the Alarm Table, the Event Table, and the Notification Table. Case, McCloghrie, Rose & Waldbusser [Page 3] RFC 1451 Manager-to-Manager MIB April 1993 2.3. Access Control The Administrative Model for SNMPv2 document [4] includes an access control model, which must not be subverted by allowing access to management information variables via the Alarm table. That is, access to a monitored variable via the Alarm table must be controlled according to the identity of the management station accessing the particular entry in the Alarm table. An entry in the Alarm table provides the means to configure the sampling of the value of a MIB variable in the MIB view associated with the specified context (which can refer to object resources that are either local or remote). The sampling is done by (conceptually or actually) issuing a SNMPv2 request to retrieve the variable's value. This request is authenticated and/or protected from disclosure according to a source party and a destination party pair which has access to the indicated context. Thus, to provide the required access control, the initial MIB view assigned, by convention, to parties on SNMPv2 entities that implement the snmpAlarmTable, must include the component: viewSubtree = { snmpAlarm } viewStatus = { excluded } viewMask = { ''H } Then, the MIB view associated with the context, requestContext, accessible by a requesting management station, can be configured to include specific Alarm table entries -- the ones associated with those contexts to which the requesting management station has access. In particular, to provide a requestContext with access to the sampling context sampleContext, the following family of view subtrees would be included for the requestContext on the SNMPv2 entity acting in a dual role: { snmpAlarmEntry WILDCARD sampleContext } Which would be configured in the party MIB [5] as: contextIdentity = { requestContext } contextViewIndex = { ViewIndex } Case, McCloghrie, Rose & Waldbusser [Page 4] RFC 1451 Manager-to-Manager MIB April 1993 viewIndex = { ViewIndex } viewSubtree = { snmpAlarmEntry 0 sampleContext } viewStatus = { included } viewMask = { 'FFEF'H } -- specifies wildcard for column Case, McCloghrie, Rose & Waldbusser [Page 5] RFC 1451 Manager-to-Manager MIB April 1993 3. Definitions SNMPv2-M2M-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Counter32, snmpModules FROM SNMPv2-SMI DisplayString, InstancePointer, RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF contextIdentity FROM SNMPv2-PARTY-MIB; snmpM2M MODULE-IDENTITY LAST-UPDATED "9304010000Z" ORGANIZATION "IETF SNMPv2 Working Group" CONTACT-INFO " Steven Waldbusser Postal: Carnegie Mellon University 4910 Forbes Ave Pittsburgh, PA 15213 Tel: +1 412 268 6628 Fax: +1 412 268 4987 E-mail: waldbusser@cmu.edu" DESCRIPTION "The Manager-to-Manager MIB module." ::= { snmpModules 2 } snmpM2MObjects OBJECT IDENTIFIER ::= { snmpM2M 1 } Case, McCloghrie, Rose & Waldbusser [Page 6] RFC 1451 Manager-to-Manager MIB April 1993 -- the alarm group -- -- a collection of objects allowing the description and -- configuration of threshold alarms from a SNMPv2 entity -- acting in a dual role. snmpAlarm OBJECT IDENTIFIER ::= { snmpM2MObjects 1 } -- This Alarm mechanism periodically takes statistical samples -- from variables available via SNMPv2 and compares them to -- thresholds that have been configured. The alarm table -- stores configuration entries that each define a variable, -- polling period, and threshold parameters. If a sample is -- found to cross the threshold values, an event is generated. -- Only variables that resolve to an ASN.1 primitive type of -- INTEGER (Integer32, Counter32, Gauge32, TimeTicks, -- Counter64, or UInteger32) may be monitored in this way. -- -- This function has a hysteresis mechanism to limit the -- generation of events. This mechanism generates one event -- as a threshold is crossed in the appropriate direction. No -- more events are generated for that threshold until the -- opposite threshold is crossed. -- -- In the case of sampling a deltaValue, an entity may -- implement this mechanism with more precision if it takes a -- delta sample twice per period, each time comparing the sum -- of the latest two samples to the threshold. This allows -- the detection of threshold crossings that span the sampling -- boundary. Note that this does not require any special -- configuration of the threshold value. It is suggested that -- entities implement this more precise algorithm. -- Case, McCloghrie, Rose & Waldbusser [Page 7] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmNextIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The index number of the next appropriate unassigned entry in the snmpAlarmTable. The value 0 indicates that no unassigned entries are available. A management station should create new entries in the snmpAlarmTable using this algorithm: first, issue a management protocol retrieval operation to determine the value of snmpAlarmNextIndex; and, second, issue a management protocol set operation to create an instance of the snmpAlarmStatus object setting its value to `createAndGo' or `createAndWait' (as specified in the description of the RowStatus textual convention)." ::= { snmpAlarm 1 } snmpAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of snmpAlarm entries." ::= { snmpAlarm 2 } snmpAlarmEntry OBJECT-TYPE SYNTAX SnmpAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of parameters that set up a periodic sampling query to check for alarm conditions. The contextIdentity included in the INDEX clause is the context to which the sampling queries are directed." INDEX { contextIdentity, snmpAlarmIndex } ::= { snmpAlarmTable 1 } Case, McCloghrie, Rose & Waldbusser [Page 8] RFC 1451 Manager-to-Manager MIB April 1993 SnmpAlarmEntry ::= SEQUENCE { snmpAlarmIndex INTEGER, snmpAlarmVariable InstancePointer, snmpAlarmInterval Integer32, snmpAlarmSampleType INTEGER, snmpAlarmValue Integer32, snmpAlarmStartupAlarm INTEGER, snmpAlarmRisingThreshold Integer32, snmpAlarmFallingThreshold Integer32, snmpAlarmRisingEventIndex INTEGER, snmpAlarmFallingEventIndex INTEGER, snmpAlarmUnavailableEventIndex INTEGER, snmpAlarmStatus RowStatus } snmpAlarmIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the snmpAlarm table for a particular sampling context. Each such entry defines a diagnostic sample at a particular interval for a variable in the particular context's object resources." ::= { snmpAlarmEntry 1 } Case, McCloghrie, Rose & Waldbusser [Page 9] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmVariable OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the particular variable to be sampled. Only variables that resolve to an ASN.1 primitive type of INTEGER (Integer32, Counter32, Gauge32, TimeTicks, Counter64, or UInteger32) may be sampled. If it is detected by an error response of authorizationError, noSuchObject, or noSuchInstance that the variable name of an established snmpAlarmEntry is no longer available in the sampling context, a single snmpObjectUnavailableAlarm event is generated and the status of this snmpAlarmEntry is set to `destroy'. Likewise, if the syntax of the variable retrieved by the query is not Integer32, Counter32, Gauge32, TimeTicks, Counter64, or UInteger32, the same actions will be taken. If the SNMPv2 entity acting in a dual role detects that the sampled value can not be obtained due to lack of response to management queries, it should either: 1) Set the status of this snmpAlarmEntry to `destroy', if it is determined that further communication is not possible; or, 2) Delete the associated snmpAlarmValue instance (but not the entire conceptual row), and continue to attempt to sample the variable and recreate the associated snmpAlarmValue instance should communication be reestablished. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." Case, McCloghrie, Rose & Waldbusser [Page 10] RFC 1451 Manager-to-Manager MIB April 1993 ::= { snmpAlarmEntry 2 } snmpAlarmInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval in seconds over which the data is sampled and compared with the rising and falling thresholds. When setting this object and the sampling type is `deltaValue', care should be taken to ensure that the change during this interval of the variable being sampled will not exceed the (-2^31...2^31-1) range of the snmpAlarmValue. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." ::= { snmpAlarmEntry 3 } Case, McCloghrie, Rose & Waldbusser [Page 11] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable and calculating the value to be compared against the thresholds. If the value of this object is `absoluteValue', the value of the selected variable at the end of the sampling interval will be compared directly with both the snmpAlarmRisingThreshold and the snmpAlarmFallingThreshold values. If the value of this object is `deltaValue', the value of the selected variable at the end of the sampling interval will be subtracted from its value at the end of the previous sampling interval, and the difference compared with both the snmpAlarmRisingThreshold and the snmpAlarmFallingThreshold values. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." DEFVAL { deltaValue } ::= { snmpAlarmEntry 4 } Case, McCloghrie, Rose & Waldbusser [Page 12] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the statistic during the last sampling period. The value during the current sampling period is not made available until the period is completed. If the value of the statistic does not fit in the signed 32 bit representation of this object, it should be truncated in an implementation specific manner. Note that if the associated snmpAlarmSampleType is set to `deltaValue', the value of this object is the difference in the sampled variable since the last sample. This object will be created by the SNMPv2 entity acting in a dual role when this entry is set to `active', and the first sampling period has completed. It may be created and deleted at other times by the SNMPv2 entity acting in a dual role when the sampled value can not be obtained, as specified in the snmpAlarmVariable object." ::= { snmpAlarmEntry 5 } Case, McCloghrie, Rose & Waldbusser [Page 13] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmStartupAlarm OBJECT-TYPE SYNTAX INTEGER { risingAlarm(1), fallingAlarm(2), risingOrFallingAlarm(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The alarm that may be sent when this entry is first set to `active'. If the first sample after this entry becomes active is greater than or equal to the risingThreshold and snmpAlarmStartupAlarm is equal to `risingAlarm' or `risingOrFallingAlarm', then a single rising alarm will be generated. If the first sample after this entry becomes active is less than or equal to the fallingThreshold and snmpAlarmStartupAlarm is equal to `fallingAlarm' or `risingOrFallingAlarm', then a single falling alarm will be generated. Note that a snmpObjectUnavailableAlarm is sent upon startup whenever it is applicable, independent of the setting of snmpAlarmStartupAlarm. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." DEFVAL { risingOrFallingAlarm } ::= { snmpAlarmEntry 6 } Case, McCloghrie, Rose & Waldbusser [Page 14] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmRisingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the sampled statistic. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes active is greater than or equal to this threshold and the associated snmpAlarmStartupAlarm is equal to `risingAlarm' or `risingOrFallingAlarm'. After a rising event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches the snmpAlarmFallingThreshold. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." ::= { snmpAlarmEntry 7 } Case, McCloghrie, Rose & Waldbusser [Page 15] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmFallingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the sampled statistic. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes active is less than or equal to this threshold and the associated snmpAlarmStartupAlarm is equal to `fallingAlarm' or `risingOrFallingAlarm'. After a falling event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches the snmpAlarmRisingThreshold. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." ::= { snmpAlarmEntry 8 } Case, McCloghrie, Rose & Waldbusser [Page 16] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmRisingEventIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the snmpEventEntry that is used when a rising threshold is crossed. The snmpEventEntry identified by a particular value of this index is the same as identified by the same value of the snmpEventIndex object. If there is no corresponding entry in the snmpEventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid snmpEventIndex. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." ::= { snmpAlarmEntry 9 } Case, McCloghrie, Rose & Waldbusser [Page 17] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmFallingEventIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the snmpEventEntry that is used when a falling threshold is crossed. The snmpEventEntry identified by a particular value of this index is the same as identified by the same value of the snmpEventIndex object. If there is no corresponding entry in the snmpEventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid snmpEventIndex. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." ::= { snmpAlarmEntry 10 } snmpAlarmUnavailableEventIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the snmpEventEntry that is used when a variable becomes unavailable. The snmpEventEntry identified by a particular value of this index is the same as identified by the same value of the snmpEventIndex object. If there is no corresponding entry in the snmpEventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid snmpEventIndex. An attempt to modify this object will fail with an `inconsistentValue' error if the associated snmpAlarmStatus object would be equal to `active' both before and after the modification attempt." ::= { snmpAlarmEntry 11 } Case, McCloghrie, Rose & Waldbusser [Page 18] RFC 1451 Manager-to-Manager MIB April 1993 snmpAlarmStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this snmpAlarm entry. This object may not be set to `active' unless the following columnar objects exist in this row: snmpAlarmVariable, snmpAlarmInterval, snmpAlarmSampleType, snmpAlarmStartupAlarm, snmpAlarmRisingThreshold, snmpAlarmFallingThreshold, snmpAlarmRisingEventIndex, snmpAlarmFallingEventIndex, and snmpAlarmUnavailableEventIndex." ::= { snmpAlarmEntry 12 } Case, McCloghrie, Rose & Waldbusser [Page 19] RFC 1451 Manager-to-Manager MIB April 1993 -- alarm-related notifications snmpAlarmNotifications OBJECT IDENTIFIER ::= { snmpAlarm 3 } snmpRisingAlarm NOTIFICATION-TYPE OBJECTS { snmpAlarmVariable, snmpAlarmSampleType, snmpAlarmValue, snmpAlarmRisingThreshold } STATUS current DESCRIPTION "An event that is generated when an alarm entry crosses its rising threshold. The instances of those objects contained within the varbind list are those of the alarm entry which generated this event." ::= { snmpAlarmNotifications 1 } snmpFallingAlarm NOTIFICATION-TYPE OBJECTS { snmpAlarmVariable, snmpAlarmSampleType, snmpAlarmValue, snmpAlarmFallingThreshold } STATUS current DESCRIPTION "An event that is generated when an alarm entry crosses its falling threshold. The instances of those objects contained within the varbind list are those of the alarm entry which generated this event." ::= { snmpAlarmNotifications 2 } snmpObjectUnavailableAlarm NOTIFICATION-TYPE OBJECTS { snmpAlarmVariable } STATUS current DESCRIPTION "An event that is generated when a variable monitored by an alarm entry becomes unavailable. The instance of snmpAlarmVariable contained within the varbind list is the one associated with the alarm entry which generated this event." ::= { snmpAlarmNotifications 3 } Case, McCloghrie, Rose & Waldbusser [Page 20] RFC 1451 Manager-to-Manager MIB April 1993 -- the event group -- -- a collection of objects allowing the description and -- configuration of events from a SNMPv2 entity acting -- in a dual role. snmpEvent OBJECT IDENTIFIER ::= { snmpM2MObjects 2 } -- The snmpEvent table defines the set of events generated on -- a SNMPv2 entity acting in a dual role. Each entry in the -- snmpEventTable associates an event type with the -- notification method and associated parameters. Some -- snmpEvent entries are fired by an associated condition in -- the snmpAlarmTable. Others are fired on behalf of -- conditions defined in the NOTIFICATION-TYPE macro. The -- snmpNotificationTable defines notifications that should -- occur when an associated event is fired. snmpEventNextIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The index number of the next appropriate unassigned entry in the snmpEventTable. The value 0 indicates that no unassigned entries are available. A management station should create new entries in the snmpEventTable using this algorithm: first, issue a management protocol retrieval operation to determine the value of snmpEventNextIndex; and, second, issue a management protocol set operation to create an instance of the snmpEventStatus object setting its value to `createAndWait' or 'createAndGo'." ::= { snmpEvent 1 } Case, McCloghrie, Rose & Waldbusser [Page 21] RFC 1451 Manager-to-Manager MIB April 1993 snmpEventTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of events." ::= { snmpEvent 2 } snmpEventEntry OBJECT-TYPE SYNTAX SnmpEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that describe an event that is generated when certain conditions are met." INDEX { snmpEventIndex } ::= { snmpEventTable 1 } SnmpEventEntry ::= SEQUENCE { snmpEventIndex INTEGER, snmpEventID OBJECT IDENTIFIER, snmpEventDescription DisplayString, snmpEventEvents Counter32, snmpEventLastTimeSent TimeStamp, snmpEventStatus RowStatus } snmpEventIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the snmpEvent table. Each such entry defines an event generated when the appropriate conditions occur." ::= { snmpEventEntry 1 } Case, McCloghrie, Rose & Waldbusser [Page 22] RFC 1451 Manager-to-Manager MIB April 1993 snmpEventID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The authoritative identification of the event type generated by this entry. This variable occurs as the second varbind of an InformRequest- PDU. If this OBJECT IDENTIFIER maps to a NOTIFICATION-TYPE the sender will place the objects listed in the NOTIFICATION-TYPE in the varbind list." ::= { snmpEventEntry 2 } snmpEventDescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..127)) MAX-ACCESS read-create STATUS current DESCRIPTION "A comment describing this snmpEvent entry." ::= { snmpEventEntry 3 } snmpEventEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of events caused by event generators associated with this snmpEvent entry." ::= { snmpEventEntry 4 } Case, McCloghrie, Rose & Waldbusser [Page 23] RFC 1451 Manager-to-Manager MIB April 1993 snmpEventLastTimeSent OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this snmpEvent entry last generated an event. If this entry has not generated any events, this value will be zero." DEFVAL { 0 } ::= { snmpEventEntry 5 } snmpEventStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this snmpEvent entry. This object may not be set to `active' unless the following columnar objects exist in this row: snmpEventID, snmpEventDescription, snmpEventEvents, and snmpEventLastTimeSent. Setting an instance of this object to the value 'destroy' has the effect of invalidating any/all entries in the snmpEventTable, and the snmpEventNotifyTable which reference the corresponding snmpEventEntry." ::= { snmpEventEntry 6 } Case, McCloghrie, Rose & Waldbusser [Page 24] RFC 1451 Manager-to-Manager MIB April 1993 snmpEventNotifyMinInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum interval that the SNMPv2 entity acting in a dual role will wait before retransmitting an InformRequest-PDU. This object specifies the minimal value supported by the SNMPv2 entity acting in a dual role, based on resource or implementation constraints. For a particular entry in the snmpEventNotifyTable, if the associated snmpEventNotifyIntervalRequested variable is greater than this object, the snmpEventNotifyIntervalRequested value shall be used as the minimum interval for retransmissions of InformRequest-PDUs sent on behalf of that entry." ::= { snmpEvent 3 } snmpEventNotifyMaxRetransmissions OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of time that the SNMPv2 entity acting in a dual role will retransmit an InformRequest-PDU. This object specifies the maximal value supported by the SNMPv2 entity acting in a dual role, based on resource or implementation constraints. For a particular entry in the snmpEventNotifyTable, if the associated snmpEventNotifyRetransmissionsRequested variable is less than this object, the snmpEventNotifyRetransmissionsRequested value shall be used as the retransmission count for InformRequest-PDUs sent on behalf of that entry." ::= { snmpEvent 4 } -- The snmpEventNotifyTable is used to configure the Case, McCloghrie, Rose & Waldbusser [Page 25] RFC 1451 Manager-to-Manager MIB April 1993 -- destination and type of notifications sent by a SNMPv2 -- entity acting in a manager role when a particular event -- is triggered. snmpEventNotifyTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpEventNotifyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of protocol configuration entries for event notifications from this entity." ::= { snmpEvent 5 } snmpEventNotifyEntry OBJECT-TYPE SYNTAX SnmpEventNotifyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that describe the type and destination of InformRequest-PDUs sent for a particular event. The snmpEventIndex in this entry's INDEX clause identifies the snmpEventEntry which, when triggered, will generate a notification as configured in this entry. The contextIdentity in this entry's INDEX clause identifies the context to which a notification will be sent." INDEX { snmpEventIndex, contextIdentity } ::= { snmpEventNotifyTable 1 } SnmpEventNotifyEntry ::= SEQUENCE { snmpEventNotifyIntervalRequested Integer32, snmpEventNotifyRetransmissionsRequested Integer32, snmpEventNotifyLifetime Integer32, snmpEventNotifyStatus RowStatus } Case, McCloghrie, Rose & Waldbusser [Page 26] RFC 1451 Manager-to-Manager MIB April 1993 snmpEventNotifyIntervalRequested OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The requested interval for retransmission of Inform PDUs generated on the behalf of this entry. This variable will be the actual interval used unless the snmpEventNotifyMinInterval is greater than this object, in which case the interval shall be equal to snmpEventNotifyMinInterval." DEFVAL { 30 } ::= { snmpEventNotifyEntry 1 } snmpEventNotifyRetransmissionsRequested OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The requested number of retransmissions of an InformRequest-PDU generated on behalf of this entry. This variable will be the actual number of retransmissions used unless the snmpEventNotifyMaxRetransmissions is less than this object, in which case the retransmission count shall be equal to snmpEventNotifyMaxRetransmissions." DEFVAL { 5 } ::= { snmpEventNotifyEntry 2 } Case, McCloghrie, Rose & Waldbusser [Page 27] RFC 1451 Manager-to-Manager MIB April 1993 snmpEventNotifyLifetime OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds this entry shall live until the corresponding instance of snmpEventNotifyStatus is set to 'destroy'. This value shall count down to zero, at which time the corresponding instance of snmpEventNotifyStatus will be set to 'destroy'. Any management station that is using this entry must periodically refresh this value to ensure the continued delivery of events." DEFVAL { 86400 } ::= { snmpEventNotifyEntry 3 } snmpEventNotifyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of this snmpEventNotifyEntry. This object may not be set to `active' unless the following columnar objects exist in this row: snmpEventNotifyIntervalRequested, snmpEventNotifyRetransmissionsRequested, and snmpEventNotifyLifetime." ::= { snmpEventNotifyEntry 4 } Case, McCloghrie, Rose & Waldbusser [Page 28] RFC 1451 Manager-to-Manager MIB April 1993 -- conformance information snmpM2MConformance OBJECT IDENTIFIER ::= { snmpM2M 2 } snmpM2MCompliances OBJECT IDENTIFIER ::= { snmpM2MConformance 1 } snmpM2MGroups OBJECT IDENTIFIER ::= { snmpM2MConformance 2 } -- compliance statements snmpM2MCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Manager-to-Manager MIB." MODULE -- this module MANDATORY-GROUPS { snmpAlarmGroup, snmpEventGroup } ::= { snmpM2MCompliances 1 } -- units of conformance snmpAlarmGroup OBJECT-GROUP OBJECTS { snmpAlarmNextIndex, snmpAlarmVariable, snmpAlarmInterval, snmpAlarmSampleType, snmpAlarmValue, snmpAlarmStartupAlarm, snmpAlarmRisingThreshold, snmpAlarmFallingThreshold, snmpAlarmRisingEventIndex, snmpAlarmFallingEventIndex, snmpAlarmUnavailableEventIndex, snmpAlarmStatus } STATUS current DESCRIPTION "A collection of objects allowing the description and configuration of threshold alarms from a SNMPv2 entity acting in a dual role." ::= { snmpM2MGroups 1 } Case, McCloghrie, Rose & Waldbusser [Page 29] RFC 1451 Manager-to-Manager MIB April 1993 snmpEventGroup OBJECT-GROUP OBJECTS { snmpEventNextIndex, snmpEventID, snmpEventDescription, snmpEventEvents, snmpEventLastTimeSent, snmpEventStatus, snmpEventNotifyMinInterval, snmpEventNotifyMaxRetransmissions, snmpEventNotifyIntervalRequested, snmpEventNotifyRetransmissionsRequested, snmpEventNotifyLifetime, snmpEventNotifyStatus } STATUS current DESCRIPTION "A collection of objects allowing the description and configuration of events from a SNMPv2 entity acting in a dual role." ::= { snmpM2MGroups 2 } END Case, McCloghrie, Rose & Waldbusser [Page 30] RFC 1451 Manager-to-Manager MIB April 1993 4. Acknowledgements The comments of the SNMP version 2 working group are gratefully acknowledged: Beth Adams, Network Management Forum Steve Alexander, INTERACTIVE Systems Corporation David Arneson, Cabletron Systems Toshiya Asaba Fred Baker, ACC Jim Barnes, Xylogics, Inc. Brian Bataille Andy Bierman, SynOptics Communications, Inc. Uri Blumenthal, IBM Corporation Fred Bohle, Interlink Jack Brown Theodore Brunner, Bellcore Stephen F. Bush, GE Information Services Jeffrey D. Case, University of Tennessee, Knoxville John Chang, IBM Corporation Szusin Chen, Sun Microsystems Robert Ching Chris Chiotasso, Ungermann-Bass Bobby A. Clay, NASA/Boeing John Cooke, Chipcom Tracy Cox, Bellcore Juan Cruz, Datability, Inc. David Cullerot, Cabletron Systems Cathy Cunningham, Microcom James R. (Chuck) Davin, Bellcore Michael Davis, Clearpoint Mike Davison, FiberCom Cynthia DellaTorre, MITRE Taso N. Devetzis, Bellcore Manual Diaz, DAVID Systems, Inc. Jon Dreyer, Sun Microsystems David Engel, Optical Data Systems Mike Erlinger, Lexcel Roger Fajman, NIH Daniel Fauvarque, Sun Microsystems Karen Frisa, CMU Shari Galitzer, MITRE Shawn Gallagher, Digital Equipment Corporation Richard Graveman, Bellcore Maria Greene, Xyplex, Inc. Case, McCloghrie, Rose & Waldbusser [Page 31] RFC 1451 Manager-to-Manager MIB April 1993 Michel Guittet, Apple Robert Gutierrez, NASA Bill Hagerty, Cabletron Systems Gary W. Haney, Martin Marietta Energy Systems Patrick Hanil, Nokia Telecommunications Matt Hecht, SNMP Research, Inc. Edward A. Heiner, Jr., Synernetics Inc. Susan E. Hicks, Martin Marietta Energy Systems Geral Holzhauer, Apple John Hopprich, DAVID Systems, Inc. Jeff Hughes, Hewlett-Packard Robin Iddon, Axon Networks, Inc. David Itusak Kevin M. Jackson, Concord Communications, Inc. Ole J. Jacobsen, Interop Company Ronald Jacoby, Silicon Graphics, Inc. Satish Joshi, SynOptics Communications, Inc. Frank Kastenholz, FTP Software Mark Kepke, Hewlett-Packard Ken Key, SNMP Research, Inc. Zbiginew Kielczewski, Eicon Jongyeoi Kim Andrew Knutsen, The Santa Cruz Operation Michael L. Kornegay, VisiSoft Deirdre C. Kostik, Bellcore Cheryl Krupczak, Georgia Tech Mark S. Lewis, Telebit David Lin David Lindemulder, AT&T/NCR Ben Lisowski, Sprint David Liu, Bell-Northern Research John Lunny, The Wollongong Group Robert C. Lushbaugh Martin, Marietta Energy Systems Michael Luufer, BBN Carl Madison, Star-Tek, Inc. Keith McCloghrie, Hughes LAN Systems Evan McGinnis, 3Com Corporation Bill McKenzie, IBM Corporation Donna McMaster, SynOptics Communications, Inc. John Medicke, IBM Corporation Doug Miller, Telebit Dave Minnich, FiberCom Mohammad Mirhakkak, MITRE Rohit Mital, Protools George Mouradian, AT&T Bell Labs Case, McCloghrie, Rose & Waldbusser [Page 32] RFC 1451 Manager-to-Manager MIB April 1993 Patrick Mullaney, Cabletron Systems Dan Myers, 3Com Corporation Rina Nathaniel, Rad Network Devices Ltd. Hien V. Nguyen, Sprint Mo Nikain Tom Nisbet William B. Norton, MERIT Steve Onishi, Wellfleet Communications, Inc. David T. Perkins, SynOptics Communications, Inc. Carl Powell, BBN Ilan Raab, SynOptics Communications, Inc. Richard Ramons, AT&T Venkat D. Rangan, Metric Network Systems, Inc. Louise Reingold, Sprint Sam Roberts, Farallon Computing, Inc. Kary Robertson, Concord Communications, Inc. Dan Romascanu, Lannet Data Communications Ltd. Marshall T. Rose, Dover Beach Consulting, Inc. Shawn A. Routhier, Epilogue Technology Corporation Chris Rozman Asaf Rubissa, Fibronics Jon Saperia, Digital Equipment Corporation Michael Sapich Mike Scanlon, Interlan Sam Schaen, MITRE John Seligson, Ultra Network Technologies Paul A. Serice, Corporation for Open Systems Chris Shaw, Banyan Systems Timon Sloane Robert Snyder, Cisco Systems Joo Young Song Roy Spitier, Sprint Einar Stefferud, Network Management Associates John Stephens, Cayman Systems, Inc. Robert L. Stewart, Xyplex, Inc. (chair) Kaj Tesink, Bellcore Dean Throop, Data General Ahmet Tuncay, France Telecom-CNET Maurice Turcotte, Racal Datacom Warren Vik, INTERACTIVE Systems Corporation Yannis Viniotis Steven L. Waldbusser, Carnegie Mellon Universitty Timothy M. Walden, ACC Alice Wang, Sun Microsystems James Watt, Newbridge Case, McCloghrie, Rose & Waldbusser [Page 33] RFC 1451 Manager-to-Manager MIB April 1993 Luanne Waul, Timeplex Donald E. Westlake III, Digital Equipment Corporation Gerry White Bert Wijnen, IBM Corporation Peter Wilson, 3Com Corporation Steven Wong, Digital Equipment Corporation Randy Worzella, IBM Corporation Daniel Woycke, MITRE Honda Wu Jeff Yarnell, Protools Chris Young, Cabletron Kiho Yum, 3Com Corporation Case, McCloghrie, Rose & Waldbusser [Page 34] RFC 1451 Manager-to-Manager MIB April 1993 5. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [4] Galvin, J., and McCloghrie, K., "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [5] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN Systems, Trusted Information Systems, April 1993. Case, McCloghrie, Rose & Waldbusser [Page 35] RFC 1451 Manager-to-Manager MIB April 1993 6. Security Considerations Security issues are not discussed in this memo. 7. Authors' Addresses Jeffrey D. Case SNMP Research, Inc. 3001 Kimberlin Heights Rd. Knoxville, TN 37920-9716 US Phone: +1 615 573 1434 Email: case@snmp.com Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 US Phone: +1 415 966 7934 Email: kzm@hls.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US Phone: +1 415 968 1052 Email: mrose@dbc.mtview.ca.us Steven Waldbusser Carnegie Mellon University 4910 Forbes Ave Pittsburgh, PA 15213 US Phone: +1 412 268 6628 Email: waldbusser@cmu.edu Case, McCloghrie, Rose & Waldbusser [Page 36] snmp-mibs-downloader-1.1/mibrfcs/rfc1461.txt0000644000000000000000000013551111402176071015563 0ustar Network Working Group D. Throop Request for Comments: 1461 Data General Corporation May 1993 SNMP MIB extension for Multiprotocol Interconnect over X.25 Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Multiprotocol Interconnect (including IP) traffic carried over X.25. The objects defined here, along with the objects in the "SNMP MIB extension for the Packet Layer of X.25"[8], "SNMP MIB extension for LAPB"[7], and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [6], combine to allow management of the traffic over an X.25 protocol stack. Table of Contents 1. The Network Management Framework ......................... 1 2. Objects .................................................. 2 2.1 Format of Definitions ................................... 2 3. Overview ................................................. 3 3.1 Scope ................................................... 3 3.2 Structure of MIB objects ................................ 3 4. Definitions .............................................. 4 5. Acknowledgements ......................................... 19 6. References ............................................... 20 7. Security Considerations ................................... 21 8. Author's Address ......................................... 21 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. These components give the rules for defining objects, the definitions of objects, and the protocol for manipulating objects. Throop [Page 1] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 The network management framework structures objects in an abstract information tree. The branches of the tree name objects and the leaves of the tree contain the values manipulated to effect management. This tree is called the Management Information Base or MIB. The concepts of this tree are given in STD 16, RFC 1155, "The Structure of Management Information" or SMI [1]. The SMI defines the trunk of the tree and the types of objects used when defining the leaves. STD 16, RFC 1212, "Towards Concise MIB Definitions" [3], defines a more concise description mechanism that preserves all the principals of the SMI. The core MIB definitions for the Internet suite of protocols can be found in STD 17, RFC 1213 [4], "Management Information Base for Network Management of TCP/IP-based internets". STD 15, RFC 1157 [2] defines the SNMP protocol itself. The protocol defines how to manipulate the objects in a remote MIB. The tree structure of the MIB allows new objects to be defined for the purpose of experimentation and evaluation. 2. Objects The definition of an object in the MIB requires an object name and type. Object names and types are defined using the subset of Abstract Syntax Notation One (ASN.1) [5] defined in the SMI [1]. Objects are named using ASN.1 object identifiers, administratively assigned names, to specify object types. The object name, together with an optional object instance, uniquely identifies a specific instance of an object. For human convenience, we often use a textual string, termed the descriptor, to refer to objects. Objects also have a syntax that defines the abstract data structure corresponding to that object type. The ASN.1 language [5] provides the primitives used for this purpose. The SMI [1] purposely restricts the ASN.1 constructs which may be used for simplicity and ease of implementation. 2.1. Format of Definitions Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in "Towards Concise MIB Definitions" [3]. Throop [Page 2] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 3. Overview 3.1. Scope Instances of the objects defined below provide management information for Multiprotocol Interconnect traffic on X.25 as defined in RFC 1356 [9]. That RFC describes how X.25 can be used to exchange IP or network level protocols. The multiprotocol packets (IP, CLNP, ES-IS, or SNAP) are encapsulated in X.25 frames for transmission between nodes. All nodes that implement RFC 1356 must implement this MIB. The objects in this MIB apply to the software in the node that manages X.25 connections and performs the protocol encapsulation. A node in this usage maybe the end node source or destination host for the packet, or it may be a router or bridge responsible for forwarding the packet. Since RFC 1356 requires X.25, nodes that implement RFC 1356 must also implement the X.25 MIB, RFC 1382. This MIB only applies to Multiprotocol Interconnect over X.25 service. It does not apply to other software that may also use X.25 (for example PAD). Thus the presence, absence, or operation of such software will not directly affect any of these objects. (However connections in use by that software will appear in the X.25 MIB). 3.2. Structure of MIB objects The objects of this MIB are organized into three tables: the mioxPleTable, the mioxPeerTable, and the mioxPeerEncTable. All objects in all tables are mandatory for conformance with this MIB. The mioxPleTable defines information relative to an interface used to carry Multiprotocol Interconnect traffic over X.25. Such interfaces are identified by an ifType object in the Internet-standard MIB [4] of ddn-x25 or rfc877-x25. Interfaces of type ddn-x25 have a self contained algorithm for translating between IP addresses and X.121 addresses. Interfaces of type rfc877-x25 do not have such an algorithm. Note that not all X.25 Interfaces will be used to carry Multiprotocol Interconnect traffic. Those interfaces not carrying such traffic will not have entries in the mioxPleTable. The entries in the mioxPleTable are only for interfaces that do carry Multiprotocol Interconnect traffic over X.25. Entries in the mioxPleTable are indexed by ifIndex to make it easy to find the mioxPleTable entry for an interface. The mioxPeerTable contains information needed to contact an X.25 Peer to exchange packets. This includes information such as the X.121 address of the peer and a pointer to the X.25 call parameters needed to place the call. The instance identifiers used for the objects in Throop [Page 3] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 this table are independent of any interface or other tables defined outside this MIB. This table contains the ifIndex value of the X.25 interface to use to call a peer. The mioxPeerEncTable contains information about the encapsulation type used to communicate with a peer. This table is an extension of the mioxPeerTable in its instance identification. Each entry in the mioxPeerTable may have zero or more entries in this table. This table will not have any entries that do not have correspondent entries in mioxPeerTable. 4. Definitions MIOX25-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 DisplayString, transmission, ifIndex FROM RFC1213-MIB InstancePointer FROM RFC1316-MIB X121Address FROM RFC1382-MIB PositiveInteger FROM RFC1381-MIB; -- IP over X.25 MIB miox OBJECT IDENTIFIER ::= { transmission 38 } mioxPle OBJECT IDENTIFIER ::= { miox 1 } mioxPeer OBJECT IDENTIFIER ::= { miox 2 } -- ########################################################### -- Ple Table -- ########################################################### -- Systems that implement RFC 1356 must also implement -- all objects in this group. mioxPleTable OBJECT-TYPE SYNTAX SEQUENCE OF MioxPleEntry Throop [Page 4] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains information relative to an interface to an X.25 Packet Level Entity (PLE)." ::= { mioxPle 1 } mioxPleEntry OBJECT-TYPE SYNTAX MioxPleEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "These objects manage the encapsulation of other protocols within X.25." INDEX { ifIndex } ::= { mioxPleTable 1 } MioxPleEntry ::= SEQUENCE { mioxPleMaxCircuits INTEGER, mioxPleRefusedConnections Counter, mioxPleEnAddrToX121LkupFlrs Counter, mioxPleLastFailedEnAddr OCTET STRING, mioxPleEnAddrToX121LkupFlrTime TimeTicks, mioxPleX121ToEnAddrLkupFlrs Counter, mioxPleLastFailedX121Address X121Address, mioxPleX121ToEnAddrLkupFlrTime TimeTicks, mioxPleQbitFailures Counter, mioxPleQbitFailureRemoteAddress X121Address, mioxPleQbitFailureTime TimeTicks, mioxPleMinimumOpenTimer PositiveInteger, mioxPleInactivityTimer PositiveInteger, mioxPleHoldDownTimer PositiveInteger, mioxPleCollisionRetryTimer Throop [Page 5] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 PositiveInteger, mioxPleDefaultPeerId InstancePointer } mioxPleMaxCircuits OBJECT-TYPE SYNTAX INTEGER (0..2147483647) ACCESS read-write STATUS mandatory DESCRIPTION "The maximum number of X.25 circuits that can be open at one time for this interface. A value of zero indicates the interface will not allow any additional circuits (as it may soon be shutdown). A value of 2147483647 allows an unlimited number of circuits." ::= { mioxPleEntry 1 } mioxPleRefusedConnections OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of X.25 calls from a remote systems to this system that were cleared by this system. The interface instance should identify the X.25 interface the call came in on." ::= { mioxPleEntry 2 } mioxPleEnAddrToX121LkupFlrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times a translation from an Encapsulated Address to an X.121 address failed to find a corresponding X.121 address. Encapsulated addresses can be looked up in the mioxPeerTable or translated via an algorithm as for the DDN. Addresses that are successfully recognized do not increment this counter. Addresses that are not recognized (reflecting an abnormal packet delivery condition) increment this counter. If an address translation fails, it may be Throop [Page 6] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 difficult to determine which PLE entry should count the failure. In such cases the first likely entry in this table should be selected. Agents should record the failure even if they are unsure which PLE should be associated with the failure." ::= { mioxPleEntry 3 } mioxPleLastFailedEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2..128)) ACCESS read-only STATUS mandatory DESCRIPTION "The last Encapsulated address that failed to find a corresponding X.121 address and caused mioxPleEnAddrToX121LkupFlrs to be incremented. The first octet of this object contains the encapsulation type, the remaining octets contain the address of that type that failed. Thus for an IP address, the length will be five octets, the first octet will contain 204 (hex CC), and the last four octets will contain the IP address. For a snap encapsulation, the first byte would be 128 (hex 80) and the rest of the octet string would have the snap header." ::= { mioxPleEntry 4 } mioxPleEnAddrToX121LkupFlrTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The most recent value of sysUpTime when the translation from an Encapsulated Address to X.121 address failed to find a corresponding X.121 address." ::= { mioxPleEntry 5 } mioxPleX121ToEnAddrLkupFlrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the translation from an X.121 address to an Encapsulated Address Throop [Page 7] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 failed to find a corresponding Encapsulated Address. Addresses successfully recognized by an algorithm do not increment this counter. This counter reflects the number of times call acceptance encountered the abnormal condition of not recognizing the peer." ::= { mioxPleEntry 6 } mioxPleLastFailedX121Address OBJECT-TYPE SYNTAX X121Address ACCESS read-only STATUS mandatory DESCRIPTION "The last X.121 address that caused mioxPleX121ToEnAddrLkupFlrs to increase." ::= { mioxPleEntry 7 } mioxPleX121ToEnAddrLkupFlrTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The most recent value of sysUpTime when the translation from an X.121 address to an Encapsulated Address failed to find a corresponding Encapsulated Address." ::= { mioxPleEntry 8 } mioxPleQbitFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times a connection was closed because of a Q-bit failure." ::= { mioxPleEntry 9 } mioxPleQbitFailureRemoteAddress OBJECT-TYPE SYNTAX X121Address ACCESS read-only STATUS mandatory DESCRIPTION "The remote address of the most recent (last) connection that was closed because of a Q-bit failure." ::= { mioxPleEntry 10 } Throop [Page 8] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 mioxPleQbitFailureTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The most recent value of sysUpTime when a connection was closed because of a Q-bit failure. This will also be the last time that mioxPleQbitFailures was incremented." ::= { mioxPleEntry 11 } mioxPleMinimumOpenTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The minimum time in milliseconds this interface will keep a connection open before allowing it to be closed. A value of zero indicates no timer." DEFVAL { 0 } ::= { mioxPleEntry 12 } mioxPleInactivityTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The amount of time time in milliseconds this interface will keep an idle connection open before closing it. A value of 2147483647 indicates no timer." DEFVAL { 10000 } ::= { mioxPleEntry 13 } mioxPleHoldDownTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The hold down timer in milliseconds. This is the minimum amount of time to wait before trying another call to a host that was previously unsuccessful. A value of 2147483647 indicates the host will not be retried." DEFVAL { 0 } ::= { mioxPleEntry 14 } Throop [Page 9] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 mioxPleCollisionRetryTimer OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The Collision Retry Timer in milliseconds. The time to delay between call attempts when the maximum number of circuits is exceeded in a call attempt." DEFVAL { 0 } ::= { mioxPleEntry 15 } mioxPleDefaultPeerId OBJECT-TYPE SYNTAX InstancePointer ACCESS read-write STATUS mandatory DESCRIPTION "This identifies the instance of the index in the mioxPeerTable for the default parameters to use with this interface. The entry identified by this object may have a zero length Encapsulation address and a zero length X.121 address. These default parameters are used with connections to hosts that do not have entries in the mioxPeerTable. Such connections occur when using ddn-x25 IP-X.25 address mapping or when accepting connections from other hosts not in the mioxPeerTable. The mioxPeerEncTable entry with the same index as the mioxPeerTable entry specifies the call encapsulation types this PLE will accept for peers not in the mioxPeerTable. If the mioxPeerEncTable doesn't contain any entries, this PLE will not accept calls from entries not in the mioxPeerTable." ::= { mioxPleEntry 16 } -- ########################################################### -- Peer Table -- ########################################################### Throop [Page 10] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 -- Systems that implement RFC 1356 must also implement -- all objects in this group. mioxPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF MioxPeerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains information about the possible peers this machine may exchange packets with." ::= { mioxPeer 1 } mioxPeerEntry OBJECT-TYPE SYNTAX MioxPeerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Per peer information." INDEX { mioxPeerIndex } ::= { mioxPeerTable 1 } MioxPeerEntry ::= SEQUENCE { mioxPeerIndex PositiveInteger, mioxPeerStatus INTEGER, mioxPeerMaxCircuits PositiveInteger, mioxPeerIfIndex PositiveInteger, mioxPeerConnectSeconds Counter, mioxPeerX25CallParamId InstancePointer, mioxPeerEnAddr OCTET STRING, mioxPeerX121Address X121Address, mioxPeerX25CircuitId InstancePointer, mioxPeerDescr DisplayString } mioxPeerIndex OBJECT-TYPE SYNTAX PositiveInteger Throop [Page 11] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 ACCESS read-only STATUS mandatory DESCRIPTION "An index value that distinguished one entry from another. This index is independent of any other index." ::= { mioxPeerEntry 1 } -- Systems can claim conformance with this MIB without -- implementing sets to mioxPeerStatus with a value of -- clearCall or makeCall. -- All other defined values must be accepted. -- Implementors should realize that allowing these values -- provides richer management, and implementations -- are encouraged to accept these values. mioxPeerStatus OBJECT-TYPE SYNTAX INTEGER { valid (1), createRequest (2), underCreation (3), invalid (4), clearCall (5), makeCall (6) } ACCESS read-write STATUS mandatory DESCRIPTION "This reports the status of a peer entry. A value of valid indicates a normal entry that is in use by the agent. A value of underCreation indicates a newly created entry which isn't yet in use because the creating management station is still setting values. The value of invalid indicates the entry is no longer in use and the agent is free to delete the entry at any time. A management station is also free to use an entry in the invalid state. Entries are created by setting a value of createRequest. Only non-existent or invalid entries can be set to createRequest. Upon receiving a valid createRequest, the agent will create an entry in the underCreation state. This object can not be set to a value of underCreation directly, entries can Throop [Page 12] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 only be created by setting a value of createRequest. Entries that exist in other than the invalid state can not be set to createRequest. Entries with a value of underCreation are not used by the system and the management station can change the values of other objects in the table entry. Management stations should also remember to configure values in the mioxPeerEncTable with the same peer index value as this peer entry. An entry in the underCreation state can be set to valid or invalid. Entries in the underCreation state will stay in that state until 1) the agent times them out, 2) they are set to valid, 3) they are set to invalid. If an agent notices an entry has been in the underCreation state for an abnormally long time, it may decide the management station has failed and invalidate the entry. A prudent agent will understand that the management station may need to wait for human input and will allow for that possibility in its determination of this abnormally long period. Once a management station has completed all fields of an entry, it will set a value of valid. This causes the entry to be activated. Entries in the valid state may also be set to makeCall or clearCall to make or clear X.25 calls to the peer. After such a set request the entry will still be in the valid state. Setting a value of makeCall causes the agent to initiate an X.25 call request to the peer specified by the entry. Setting a value of clearCall causes the agent to initiate clearing one X.25 call present to the peer. Each set request will initiate another call or clear request (up to the maximum allowed); this means that management stations that fail to get a response to a set request should query to see if a call was in fact placed or cleared before Throop [Page 13] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 retrying the request. Entries not in the valid state can not be set to makeCall or clearCall. The values of makeCall and clearCall provide for circuit control on devices which perform Ethernet Bridging using static circuit assignment without address recognition; other devices which dynamically place calls based on destination addresses may reject such requests. An agent that (re)creates a new entry because of a set with createRequest, should also (re)create a mioxPeerEncTable entry with a mioxPeerEncIndex of 1, and a mioxPeerEncType of 204 (hex CC)." ::= { mioxPeerEntry 2 } mioxPeerMaxCircuits OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The maximum number of X.25 circuits allowed to this peer." DEFVAL { 1 } ::= { mioxPeerEntry 3 } mioxPeerIfIndex OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-write STATUS mandatory DESCRIPTION "The value of the ifIndex object for the interface to X.25 to use to call the peer." DEFVAL { 1 } ::= { mioxPeerEntry 4 } mioxPeerConnectSeconds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of seconds a call to this peer was active. This counter will be incremented by one for every second a connection to a peer was open. If two calls Throop [Page 14] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 are open at the same time, one second of elapsed real time will results in two seconds of connect time." ::= { mioxPeerEntry 5 } mioxPeerX25CallParamId OBJECT-TYPE SYNTAX InstancePointer ACCESS read-write STATUS mandatory DESCRIPTION "The instance of the index object in the x25CallParmTable from RFC 1382 for the X.25 call parameters used to communicate with the remote host. The well known value {0 0} indicates no call parameters specified." DEFVAL { {0 0} } ::= { mioxPeerEntry 6 } mioxPeerEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..128)) ACCESS read-write STATUS mandatory DESCRIPTION "The Encapsulation address of the remote host mapped by this table entry. A length of zero indicates the remote IP address is unknown or unspecified for use as a PLE default. The first octet of this object contains the encapsulation type, the remaining octets contain an address of that type. Thus for an IP address, the length will be five octets, the first octet will contain 204 (hex CC), and the last four octets will contain the IP address. For a snap encapsulation, the first byte would be 128 (hex 80) and the rest of the octet string would have the snap header." DEFVAL { ''h } ::= { mioxPeerEntry 7 } mioxPeerX121Address OBJECT-TYPE SYNTAX X121Address ACCESS read-write STATUS mandatory DESCRIPTION "The X.25 address of the remote host mapped Throop [Page 15] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 by this table entry. A zero length string indicates the X.25 address is unspecified for use as the PLE default." DEFVAL { ''h } ::= { mioxPeerEntry 8 } -- Systems can claim conformance to this MIB without -- implementing sets to mioxPeerX25CircuitId. -- However systems that use PVCs with RFC1356 -- are encouraged to implement sets. mioxPeerX25CircuitId OBJECT-TYPE SYNTAX InstancePointer ACCESS read-write STATUS mandatory DESCRIPTION "This object identifies the instance of the index for the X.25 circuit open to the peer mapped by this table entry. The well known value {0 0} indicates no connection currently active. For multiple connections, this identifies the index of a multiplexing table entry for the connections. This can only be written to configure use of PVCs which means the identified circuit table entry for a write must be a PVC." DEFVAL { {0 0} } ::= { mioxPeerEntry 9 } mioxPeerDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "This object returns any identification information about the peer. An agent may supply the comment information found in the configuration file entry for this peer. A zero length string indicates no information available." DEFVAL { ''h } ::= { mioxPeerEntry 10 } -- ########################################################### -- Peer Encapsulation Table -- ########################################################### Throop [Page 16] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 mioxPeerEncTable OBJECT-TYPE SYNTAX SEQUENCE OF MioxPeerEncEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains the list of encapsulations used to communicate with a peer. This table has two indexes, the first identifies the peer, the second distinguishes encapsulation types. The first index identifies the corresponding entry in the mioxPeerTable. The second index gives the priority of the different encapsulations. The encapsulation types are ordered in priority order. For calling a peer, the first entry (mioxPeerEncIndex of 1) is tried first. If the call doesn't succeed because the remote host clears the call due to incompatible call user data, the next entry in the list is tried. Each entry is tried until the list is exhausted. For answering a call, the encapsulation type requested by the peer must be found the list or the call will be refused. If there are no entries in this table for a peer, all call requests from the peer will be refused. Objects in this table can only be set when the mioxPeerStatus object with the same index has a value of underCreation. When that status object is set to invalid and deleted, the entry in this table with that peer index must also be deleted." ::= { mioxPeer 2 } mioxPeerEncEntry OBJECT-TYPE SYNTAX MioxPeerEncEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Per connection information." INDEX { mioxPeerIndex, mioxPeerEncIndex} ::= { mioxPeerEncTable 1 } Throop [Page 17] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 MioxPeerEncEntry ::= SEQUENCE { mioxPeerEncIndex PositiveInteger, mioxPeerEncType INTEGER } mioxPeerEncIndex OBJECT-TYPE SYNTAX PositiveInteger ACCESS read-only STATUS mandatory DESCRIPTION "The second index in the table which distinguishes different encapsulation types." ::= { mioxPeerEncEntry 1 } mioxPeerEncType OBJECT-TYPE SYNTAX INTEGER (0..256) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the encapsulation type. For IP encapsulation this will have a value of 204 (hex CC). For SNAP encapsulated packets, this will have a value of 128 (hex 80). For CLNP, ISO 8473, this will have a value of 129 (hex 81). For ES-ES, ISO 9542, this will have a value of 130 (hex 82). A value of 197 (hex C5) identifies the Blacker X.25 encapsulation. A value of 0, identifies the Null encapsulation. This value can only be written when the mioxPeerStatus object with the same mioxPeerIndex has a value of underCreation. Setting this object to a value of 256 deletes the entry. When deleting an entry, all other entries in the mioxPeerEncTable with the same mioxPeerIndex and with an mioxPeerEncIndex higher then the deleted entry, will all have their mioxPeerEncIndex values decremented by one." ::= { mioxPeerEncEntry 2 } -- ########################################################### END Throop [Page 18] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 5. Acknowledgements This document was produced by the x25mib working group: Fred Baker, ACC Art Berggreen, ACC Frank Bieser Gary Bjerke, Tandem Bill Bowman, HP Christopher Bucci, Datability Charles Carvalho, ACC Jeff Case, University of Tennessee at Knoxville Angela Chen, HP Carson Cheung, BNR Tom Daniel, Spider Systems Chuck Davin, MIT Billy Durham, Honeywell Richard Fox, Synoptics Doug Geller, Data General Herve Goguely, LIR Corp Andy Goldthorpe, British-Telecom Walter D. Guilarte David Gurevich Steve Huston, Consultant Jon Infante, ICL Frank Kastenholz, FTP Software Zbigniew Kielczewski, Eicon Cheryl Krupezak, Georgia Tech Mats Lindstrom, Diab Data AB Andrew Malis, BBN Evan McGinnis, 3Com Gary (G.P.)Mussar, BNR Chandy Nilakantan, 3Com Randy Pafford, Data General Ragnar Paulson, The Software Group Limited Dave Perkins, Synoptics Walter Pinkarschewsky, DEC Karen Quidley, Data General Chris Ranch, Novell Paul S. Rarey, DHL Systems Inc. Jim Roche, Newbridge Research Philippe Roger, LIR Corp. Timon Sloane Mike Shand, DEC Brad Steina, Microcom Bob Stewart, Xyplex Tom Sullivan, Data General Rodney Thayer, Sable Technology Corporation Throop [Page 19] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 Mark Therieau, Microcom Jane Thorn, Data General Dean Throop, Data General Maurice Turcotte, Racal Datacom Mike Zendels, Data General 6. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [3] Rose, M. and K. McCloghrie, Editors, "Towards Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [4] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213. Performance Systems International, March 1991. [5] "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization. International Standard 8824, December, 1987. [6] Stewart, B., Editor, "Definitions of Managed Objects for RS-232- like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992. [7] Throop, D., and F. Baker, "SNMP MIB extension for X.25 LAPB", RFC 1381, Data General Corporation, Advanced Computer Communications, November 1992. [8] Throop, D., Editor, "SNMP MIB extension for the X.25 Packet Layer", RFC 1382, Data General Corporation, November 1991. [9] Malis, A., Robinson, D., and R. Ullmann "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN Communications, Computervision Systems Integration, Process Software Corporation, August 1992. Throop [Page 20] RFC 1461 Multiprotocol Interconnect on X.25 MIB May 1993 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Dean D. Throop Data General Corporation 62 Alexander Dr. Research Triangle Park, NC 27709 Phone: (919) 248-6081 EMail: throop@dg-rtp.dg.com Throop [Page 21] snmp-mibs-downloader-1.1/mibrfcs/rfc1471.txt0000644000000000000000000015046611402176071015572 0ustar Network Working Group F. Kastenholz Request for Comments: 1471 FTP Software, Inc. June 1993 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. Table of Contents 1. The Network Management Framework ...................... 2 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 2 3. Overview .............................................. 2 3.1 Object Selection Criteria ............................ 2 3.2 Structure of the PPP ................................. 3 3.3 MIB Groups ........................................... 4 3.4 Relationship to Interface and Interface Extensions Groups ............................................... 5 4. Definitions ........................................... 6 4.1 PPP Link Group ....................................... 7 4.2 PPP LQR Group ........................................ 16 4.3 PPP LQR Extensions Group ............................. 21 4.4 PPP Tests ............................................ 22 4.4.1 PPP Echo Test ...................................... 22 4.4.2 PPP Discard Test ................................... 23 5. Acknowledgements ...................................... 23 6. Security Considerations ............................... 23 7. References ............................................ 24 8. Author's Address ...................................... 25 Kastenholz [Page 1] RFC 1471 PPP/LCP MIB June 1993 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. STD 17/RFC 1213 which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects 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) [3] 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. 2.1. Format of Definitions Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [5,6]. 3. Overview 3.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, an explicit attempt was made to keep this MIB as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: (1) Require objects be essential for either fault or configuration management. In particular, objects for Kastenholz [Page 2] RFC 1471 PPP/LCP MIB June 1993 which the sole purpose was to debug implementations were explicitly excluded from the MIB. (2) Consider evidence of current use and/or utility. (3) Limit the total number of objects. (4) Exclude objects which are simply derivable from others in this or other MIBs. 3.2. Structure of the PPP This section describes the basic model of PPP used in developing the PPP MIB. This information should be useful to the implementor in understanding some of the basic design decisions of the MIB. The PPP is not one single protocol but a large family of protocols. Each of these is, in itself, a fairly complex protocol. The PPP protocols may be divided into three rough categories: Control Protocols The Control Protocols are used to control the operation of the PPP. The Control Protocols include the Link Control Protocol (LCP), the Password Authentication Protocol (PAP), the Link Quality Report (LQR), and the Challenge Handshake Authentication Protocol (CHAP). Network Protocols The Network Protocols are used to move the network traffic over the PPP interface. A Network Protocol encapsulates the datagrams of a specific higher-layer protocol that is using the PPP as a data link. Note that within the context of PPP, the term "Network Protocol" does not imply an OSI Layer-3 protocol; for instance, there is a Bridging network protocol. Network Control Protocols (NCPs) The NCPs are used to control the operation of the Network Protocols. Generally, each Network Protocol has its own Network Control Protocol; thus, the IP Network Protocol has its IP Control Protocol, the Bridging Network Protocol has its Bridging Network Control Protocol and so on. This document specifies the objects used in managing one of these protocols, namely the Link Control Protocol and Link Quality Monitoring Protocol. Kastenholz [Page 3] RFC 1471 PPP/LCP MIB June 1993 3.3. MIB Groups Objects in this MIB are arranged into several MIB groups. Each group is organized as a set of related objects. These groups are the basic unit of conformance: if the semantics of a group are applicable to an implementation then all objects in the group must be implemented. The PPP MIB is organized into several MIB Groups, including, but not limited to, the following groups: o The PPP Link Group o The PPP LQR Group o The PPP LQR Extensions Group o The PPP IP Group o The PPP Bridge Group o The PPP Security Group This document specifies the following groups: The PPP Link Group This group represents the lowest "level" of the PPP protocol. This group contains two tables, one containing status information and the other configuration information. The configuration table is split off of the status so that it may be placed in a separate MIB View for security purposes. Implementation of this group is mandatory for all PPP implementations. The PPP LQR Group This group provides the basic MIB variables that apply to the PPP LQR Protocol. This group provides MIB access to the information required for LQR processing. This group contains two tables, one containing status information and the other configuration information. The configuration table is split off of the status so that it may be placed in a separate MIB View for security purposes. Implementation of the PPP LQR Group is mandatory for all PPP implementations that implement LQR. The PPP LQR Extensions Group The PPP LQR Extensions group contains the most recently received LQR packet, as well as the "save" fields that are "logically appended" [12] to received LQR packets. This is done in order to Kastenholz [Page 4] RFC 1471 PPP/LCP MIB June 1993 facilitate external implementations of the Link Quality Monitoring policies. It is not practical to examine the relevant MIB objects which are used to generate LQR packets since LQR policies may require synchronization of the values of all data used to determine Link Quality; i.e., the values of the relevant counters must all be taken at the same instant in time. Thus, by recording the last received LQR packet, a synchronized record of the relevant data is available. As this information may not be efficiently maintained on all PPP implementations, implementation of this group is optional. 3.4. Relationship to Interface and Interface Extensions Groups The PPP Mib is a medium-specific extension to the standard MIB-2 interface group [2] and to the Interface Extensions MIB [7]. This section discusses certain components of these groups when the interface is a PPP interface. The PPP interface represents a single interface in the sense used in [2] and thus has a single entry in the ifTable. Furthermore, the PPP interface may be operating over a lower layer hardware interface (such as an RS-232 port). It is important to capture the relationship between the PPP interface and the lower- layer interface over which it operates. This MIB presumes that the lower-layer interface has an ifEntry associated with it. The lower- layer ifEntry is identified via the pppLinkStatusPhysicalIndex object, which contains the value of ifIndex for the lower-layer ifEntry. For example, suppose that you run PPP over a RS-232 port. This would use two entries in the ifTable. Let's suppose that entry number 123 is for the PPP "interface" and entry number 987 is for the RS-232 port. So, ifSpecific.123 would contain the ppp OBJECT IDENTIFIER, pppLinkStatusPhysicalIndex.123 would contain 987, and ifSpecific.987 would contain the rs_232 OBJECT IDENTIFIER (or whatever it is). All PPP packets are defined in [8] as being broadcast packets. Thus, the packets are counted as non-unicast packets in the ifTable (ifInNUcastPkts and ifOutNUCastPkts) and as broadcasts in the ifExtnsTable (ifExtnsBroadcastsReceivedOks and ifExtnsBroadcastsTransmittedOks). Kastenholz [Page 5] RFC 1471 PPP/LCP MIB June 1993 ifSpecific Contains the OBJECT IDENTIFIER ppp. ifAdminStatus Setting this object to up will inject an administrative open event into the LCP's finite state machine. Setting this object to down will inject an administrative close event into the LCP's finite state machine. The use of the testing value is beyond the scope of this document. ifOperStatus Represents the state of the LCP Finite State Machine. If the Finite State Machine is in the Opened state then the value of ifOperStatus is up, otherwise the value of ifOperStatus is down. The meaning of the testing value is beyond the scope of this document. Per the SNMP Protocol Specification [13], the linkUp and linkDown traps apply to the PPP Protocol entity. When the LCP's Finite State Machine attains the Opened state, a linkUp trap should be sent. When the Finite State Machine leaves the Opened state, a linkDown trap should be sent. Some tests for the link are defined in this document. Execution of these tests does not place the link's ifOperStatus in the testing state as these tests do not prevent normal data transmission from occuring over the link. 4. Definitions PPP-LCP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter FROM RFC1155-SMI ifIndex, transmission FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; -- PPP MIB ppp OBJECT IDENTIFIER ::= { transmission 23 } pppLcp OBJECT IDENTIFIER ::= { ppp 1 } Kastenholz [Page 6] RFC 1471 PPP/LCP MIB June 1993 -- The individual groups within the PPP-LCP-MIB pppLink OBJECT IDENTIFIER ::= { pppLcp 1 } pppLqr OBJECT IDENTIFIER ::= { pppLcp 2 } pppTests OBJECT IDENTIFIER ::= { pppLcp 3 } -- 4.1. PPP Link Group -- -- The PPP Link Group. Implementation of this -- group is mandatory for all PPP entities. -- -- The following object reflect the values of the option -- parameters used in the PPP Link Control Protocol -- pppLinkStatusLocalMRU -- pppLinkStatusRemoteMRU -- pppLinkStatusLocalToPeerACCMap -- pppLinkStatusPeerToLocalACCMap -- pppLinkStatusLocalToRemoteProtocolCompression -- pppLinkStatusRemoteToLocalProtocolCompression -- pppLinkStatusLocalToRemoteACCompression -- pppLinkStatusRemoteToLocalACCompression -- pppLinkStatusTransmitFcsSize -- pppLinkStatusReceiveFcsSize -- -- These values are not available until after the PPP Option -- negotiation has completed, which is indicated by the link -- reaching the open state (i.e., ifOperStatus is set to -- up). -- -- Therefore, when ifOperStatus is not up -- the contents of these objects is undefined. The value -- returned when accessing the objects is an implementation -- dependent issue. pppLinkStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLinkStatusEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing PPP-link specific variables for this PPP implementation." ::= { pppLink 1 } Kastenholz [Page 7] RFC 1471 PPP/LCP MIB June 1993 pppLinkStatusEntry OBJECT-TYPE SYNTAX PppLinkStatusEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Management information about a particular PPP Link." INDEX { ifIndex } ::= { pppLinkStatusTable 1 } PppLinkStatusEntry ::= SEQUENCE { pppLinkStatusPhysicalIndex INTEGER, pppLinkStatusBadAddresses Counter, pppLinkStatusBadControls Counter, pppLinkStatusPacketTooLongs Counter, pppLinkStatusBadFCSs Counter, pppLinkStatusLocalMRU INTEGER, pppLinkStatusRemoteMRU INTEGER, pppLinkStatusLocalToPeerACCMap OCTET STRING, pppLinkStatusPeerToLocalACCMap OCTET STRING, pppLinkStatusLocalToRemoteProtocolCompression INTEGER, pppLinkStatusRemoteToLocalProtocolCompression INTEGER, pppLinkStatusLocalToRemoteACCompression INTEGER, pppLinkStatusRemoteToLocalACCompression INTEGER, pppLinkStatusTransmitFcsSize INTEGER, pppLinkStatusReceiveFcsSize INTEGER } pppLinkStatusPhysicalIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION Kastenholz [Page 8] RFC 1471 PPP/LCP MIB June 1993 "The value of ifIndex that identifies the lower-level interface over which this PPP Link is operating. This interface would usually be an HDLC or RS-232 type of interface. If there is no lower-layer interface element, or there is no ifEntry for the element, or the element can not be identified, then the value of this object is 0. For example, suppose that PPP is operating over a serial port. This would use two entries in the ifTable. The PPP could be running over `interface' number 123 and the serial port could be running over `interface' number 987. Therefore, ifSpecific.123 would contain the OBJECT IDENTIFIER ppp pppLinkStatusPhysicalIndex.123 would contain 987, and ifSpecific.987 would contain the OBJECT IDENTIFIER for the serial-port's media- specific MIB." ::= { pppLinkStatusEntry 1 } pppLinkStatusBadAddresses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received with an incorrect Address Field. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link." REFERENCE "Section 3.1, Address Field, of RFC1331." ::= { pppLinkStatusEntry 2 } pppLinkStatusBadControls OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received on this link with an incorrect Control Field. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link." REFERENCE "Section 3.1, Control Field, of RFC1331." Kastenholz [Page 9] RFC 1471 PPP/LCP MIB June 1993 ::= { pppLinkStatusEntry 3 } pppLinkStatusPacketTooLongs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of received packets that have been discarded because their length exceeded the MRU. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link. NOTE, packets which are longer than the MRU but which are successfully received and processed are NOT included in this count." ::= { pppLinkStatusEntry 4 } pppLinkStatusBadFCSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of received packets that have been discarded due to having an incorrect FCS. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link." ::= { pppLinkStatusEntry 5 } pppLinkStatusLocalMRU OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The current value of the MRU for the local PPP Entity. This value is the MRU that the remote entity is using when sending packets to the local PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 6 } pppLinkStatusRemoteMRU OBJECT-TYPE SYNTAX INTEGER(1..2147483648) Kastenholz [Page 10] RFC 1471 PPP/LCP MIB June 1993 ACCESS read-only STATUS mandatory DESCRIPTION "The current value of the MRU for the remote PPP Entity. This value is the MRU that the local entity is using when sending packets to the remote PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 7 } pppLinkStatusLocalToPeerACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-only STATUS mandatory DESCRIPTION "The current value of the ACC Map used for sending packets from the local PPP entity to the remote PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 8 } pppLinkStatusPeerToLocalACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-only STATUS mandatory DESCRIPTION "The ACC Map used by the remote PPP entity when transmitting packets to the local PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 9 } pppLinkStatusLocalToRemoteProtocolCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local PPP entity will Kastenholz [Page 11] RFC 1471 PPP/LCP MIB June 1993 use Protocol Compression when transmitting packets to the remote PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 10 } pppLinkStatusRemoteToLocalProtocolCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the remote PPP entity will use Protocol Compression when transmitting packets to the local PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 11 } pppLinkStatusLocalToRemoteACCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local PPP entity will use Address and Control Compression when transmitting packets to the remote PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 12 } pppLinkStatusRemoteToLocalACCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } Kastenholz [Page 12] RFC 1471 PPP/LCP MIB June 1993 ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the remote PPP entity will use Address and Control Compression when transmitting packets to the local PPP entity. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 13 } pppLinkStatusTransmitFcsSize OBJECT-TYPE SYNTAX INTEGER (0..128) ACCESS read-only STATUS mandatory DESCRIPTION "The size of the Frame Check Sequence (FCS) in bits that the local node will generate when sending packets to the remote node. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 14 } pppLinkStatusReceiveFcsSize OBJECT-TYPE SYNTAX INTEGER (0..128) ACCESS read-only STATUS mandatory DESCRIPTION "The size of the Frame Check Sequence (FCS) in bits that the remote node will generate when sending packets to the local node. The value of this object is meaningful only when the link has reached the open state (ifOperStatus is up)." ::= { pppLinkStatusEntry 15 } pppLinkConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLinkConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing the LCP configuration parameters for this PPP Link. These variables represent the initial configuration of the PPP Kastenholz [Page 13] RFC 1471 PPP/LCP MIB June 1993 Link. The actual values of the parameters may be changed when the link is brought up via the LCP options negotiation mechanism." ::= { pppLink 2 } pppLinkConfigEntry OBJECT-TYPE SYNTAX PppLinkConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Configuration information about a particular PPP Link." INDEX { ifIndex } ::= { pppLinkConfigTable 1 } PppLinkConfigEntry ::= SEQUENCE { pppLinkConfigInitialMRU INTEGER, pppLinkConfigReceiveACCMap OCTET STRING, pppLinkConfigTransmitACCMap OCTET STRING, pppLinkConfigMagicNumber INTEGER, pppLinkConfigFcsSize INTEGER } pppLinkConfigInitialMRU OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-write STATUS mandatory DESCRIPTION "The initial Maximum Receive Unit (MRU) that the local PPP entity will advertise to the remote entity. If the value of this variable is 0 then the local PPP entity will not advertise any MRU to the remote entity and the default MRU will be assumed. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.2, Maximum Receive Unit of RFC1331." DEFVAL { 1500 } ::= { pppLinkConfigEntry 1 } Kastenholz [Page 14] RFC 1471 PPP/LCP MIB June 1993 pppLinkConfigReceiveACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-write STATUS mandatory DESCRIPTION "The Asynchronous-Control-Character-Map (ACC) that the local PPP entity requires for use on its receive side. In effect, this is the ACC Map that is required in order to ensure that the local modem will successfully receive all characters. The actual ACC map used on the receive side of the link will be a combination of the local node's pppLinkConfigReceiveACCMap and the remote node's pppLinkConfigTransmitACCMap. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.3, page 4, Async-Control-Character- Map of RFC1331." DEFVAL { 'ffffffff'h } ::= { pppLinkConfigEntry 2 } pppLinkConfigTransmitACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-write STATUS mandatory DESCRIPTION "The Asynchronous-Control-Character-Map (ACC) that the local PPP entity requires for use on its transmit side. In effect, this is the ACC Map that is required in order to ensure that all characters can be successfully transmitted through the local modem. The actual ACC map used on the transmit side of the link will be a combination of the local node's pppLinkConfigTransmitACCMap and the remote node's pppLinkConfigReceiveACCMap. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.3, page 4, Async-Control-Character- Map of RFC1331." DEFVAL { 'ffffffff'h } ::= { pppLinkConfigEntry 3 } Kastenholz [Page 15] RFC 1471 PPP/LCP MIB June 1993 pppLinkConfigMagicNumber OBJECT-TYPE SYNTAX INTEGER {false (1), true (2)} ACCESS read-write STATUS mandatory DESCRIPTION "If true(2) then the local node will attempt to perform Magic Number negotiation with the remote node. If false(1) then this negotiation is not performed. In any event, the local node will comply with any magic number negotiations attempted by the remote node, per the PPP specification. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.6, Magic Number, of RFC1331." DEFVAL { false } ::= { pppLinkConfigEntry 4 } pppLinkConfigFcsSize OBJECT-TYPE SYNTAX INTEGER (0..128) ACCESS read-write STATUS mandatory DESCRIPTION "The size of the FCS, in bits, the local node will attempt to negotiate for use with the remote node. Regardless of the value of this object, the local node will comply with any FCS size negotiations initiated by the remote node, per the PPP specification. Changing this object will have effect when the link is next restarted." DEFVAL { 16 } ::= { pppLinkConfigEntry 5 } -- 4.2. PPP LQR Group -- -- The PPP LQR Group. -- Implementation of this group is mandatory for all -- PPP implementations that implement LQR. -- pppLqrTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLqrEntry ACCESS not-accessible Kastenholz [Page 16] RFC 1471 PPP/LCP MIB June 1993 STATUS mandatory DESCRIPTION "Table containing the LQR parameters and statistics for the local PPP entity." ::= { pppLqr 1 } pppLqrEntry OBJECT-TYPE SYNTAX PppLqrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "LQR information for a particular PPP link. A PPP link will have an entry in this table if and only if LQR Quality Monitoring has been successfully negotiated for said link." INDEX { ifIndex } ::= { pppLqrTable 1 } PppLqrEntry ::= SEQUENCE { pppLqrQuality INTEGER, pppLqrInGoodOctets Counter, pppLqrLocalPeriod INTEGER, pppLqrRemotePeriod INTEGER, pppLqrOutLQRs Counter, pppLqrInLQRs Counter } pppLqrQuality OBJECT-TYPE SYNTAX INTEGER { good(1), bad(2), not-determined(3) } ACCESS read-only STATUS mandatory DESCRIPTION "The current quality of the link as declared by the local PPP entity's Link-Quality Management modules. No effort is made to define good or bad, nor the policy used to determine it. The Kastenholz [Page 17] RFC 1471 PPP/LCP MIB June 1993 not-determined value indicates that the entity does not actually evaluate the link's quality. This value is used to disambiguate the `determined to be good' case from the `no determination made and presumed to be good' case." ::= { pppLqrEntry 1 } pppLqrInGoodOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The LQR InGoodOctets counter for this link." REFERENCE "Section 2.2, Counters, of RFC1333." ::= { pppLqrEntry 2 } pppLqrLocalPeriod OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The LQR reporting period, in hundredths of a second that is in effect for the local PPP entity." REFERENCE "Section 2.5, Configuration Option Format, of RFC1333." ::= { pppLqrEntry 3 } pppLqrRemotePeriod OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The LQR reporting period, in hundredths of a second, that is in effect for the remote PPP entity." REFERENCE "Section 2.5, Configuration Option Format, of RFC1333." ::= { pppLqrEntry 4 } Kastenholz [Page 18] RFC 1471 PPP/LCP MIB June 1993 pppLqrOutLQRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The value of the OutLQRs counter on the local node for the link identified by ifIndex." REFERENCE "Section 2.2, Counters, of RFC1333." ::= { pppLqrEntry 5 } pppLqrInLQRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The value of the InLQRs counter on the local node for the link identified by ifIndex." REFERENCE "Section 2.2, Counters, of RFC1333." ::= { pppLqrEntry 6 } -- -- The PPP LQR Configuration table. -- pppLqrConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLqrConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the LQR Configuration parameters for the local PPP entity." ::= { pppLqr 2 } pppLqrConfigEntry OBJECT-TYPE SYNTAX PppLqrConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "LQR configuration information for a particular PPP link." INDEX { ifIndex } ::= { pppLqrConfigTable 1 } Kastenholz [Page 19] RFC 1471 PPP/LCP MIB June 1993 PppLqrConfigEntry ::= SEQUENCE { pppLqrConfigPeriod INTEGER, pppLqrConfigStatus INTEGER } pppLqrConfigPeriod OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-write STATUS mandatory DESCRIPTION "The LQR Reporting Period that the local PPP entity will attempt to negotiate with the remote entity, in units of hundredths of a second. Changing this object will have effect when the link is next restarted." REFERENCE "Section 2.5, Configuration Option Format, of RFC1333." DEFVAL { 0 } ::= { pppLqrConfigEntry 1 } pppLqrConfigStatus OBJECT-TYPE SYNTAX INTEGER {disabled (1), enabled (2)} ACCESS read-write STATUS mandatory DESCRIPTION "If enabled(2) then the local node will attempt to perform LQR negotiation with the remote node. If disabled(1) then this negotiation is not performed. In any event, the local node will comply with any magic number negotiations attempted by the remote node, per the PPP specification. Changing this object will have effect when the link is next restarted. Setting this object to the value disabled(1) has the effect of invalidating the corresponding entry in the pppLqrConfigTable object. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use." REFERENCE "Section 7.6, Magic Number, of RFC1331." Kastenholz [Page 20] RFC 1471 PPP/LCP MIB June 1993 DEFVAL { enabled } ::= { pppLqrConfigEntry 2 } -- 4.3. PPP LQR Extensions Group -- -- The PPP LQR Extensions Group. -- Implementation of this group is optional. -- -- The intent of this group is to allow external -- implementation of the policy mechanisms that -- are used to declare a link to be "bad" or not. -- -- It is not practical to examine the MIB objects -- which are used to generate LQR packets since -- LQR policies tend to require synchronization of -- the values of all data used to determine Link -- Quality; i.e. the values of the relevant counters -- must all be taken at the same instant in time. -- pppLqrExtnsTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLqrExtnsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing additional LQR information for the local PPP entity." ::= { pppLqr 3 } pppLqrExtnsEntry OBJECT-TYPE SYNTAX PppLqrExtnsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Extended LQR information for a particular PPP link. Assuming that this group has been implemented, a PPP link will have an entry in this table if and only if LQR Quality Monitoring has been successfully negotiated for said link." INDEX { ifIndex } ::= { pppLqrExtnsTable 1 } PppLqrExtnsEntry ::= SEQUENCE { Kastenholz [Page 21] RFC 1471 PPP/LCP MIB June 1993 pppLqrExtnsLastReceivedLqrPacket OCTET STRING(SIZE(68)) } pppLqrExtnsLastReceivedLqrPacket OBJECT-TYPE SYNTAX OCTET STRING(SIZE(68)) ACCESS read-only STATUS mandatory DESCRIPTION "This object contains the most recently received LQR packet. The format of the packet is as described in the LQM Protocol specificiation. All fields of the packet, including the `save' fields, are stored in this object. The LQR packet is stored in network byte order. The LAP-B and PPP headers are not stored in this object; the first four octets of this variable contain the Magic-Number field, the second four octets contain the LastOutLQRs field and so on. The last four octets of this object contain the SaveInOctets field of the LQR packet." REFERENCE "Section 2.6, Packet Format, of RFC1333" ::= { pppLqrExtnsEntry 1 } -- 4.4. PPP Tests -- The extensions to the interface table in RFC1229 define a -- table through which the network manager can instruct the -- managed object to perform various tests of the interface. This -- is the ifExtnsTestTable. -- The PPP MIB defines two such tests. -- 4.4.1. PPP Echo Test -- The PPP Echo Test is defined as pppEchoTest OBJECT IDENTIFIER ::= { pppTests 1 } -- Invoking this test causes a PPP Echo Packet to be sent on the -- line. ifExtnsTestResult returns success(2) if the echo -- response came back properly. It returns failed(7) if the -- response did not properly return. The definition of "proper" Kastenholz [Page 22] RFC 1471 PPP/LCP MIB June 1993 -- in this context is left to the discretion of the implementor. -- 4.4.2. PPP Discard Test -- The PPP Discard Test is defined as pppDiscardTest OBJECT IDENTIFIER ::= { pppTests 2 } -- Invoking this test causes a PPP Discard Packet to be sent on -- the line. ifExtnsTestResult returns success(2) if the discard -- packet was successfully transmitted and failed(7) if an error -- was detected on transmission. The definition of "transmission -- error" in this context is left to the discretion of the -- implementor. END 5. Acknowledgements This document was produced by the PPP working group. In addition to the working group, the author wishes to thank the following individuals for their comments and contributions: Bill Simpson -- Daydreamer Glenn McGregor -- Merit Jesse Walker -- DEC Chris Gunner -- DEC 6. Security Considerations The PPP MIB affords the network operator the ability to configure and control the PPP links of a particular system. This represents a security risk. These risks are addressed in the following manners: (1) All variables which represent a significant security risk are placed in separate, optional, MIB Groups. As the MIB Group is the quantum of implementation within a MIB, the implementor of the MIB may elect not to implement these groups. (2) The implementor may choose to implement the variables which present a security risk so that they may not be written, i.e., the variables are READ-ONLY. This method still presents a security risk, and is not recommended, in that the variables, specifically the PPP Authentication Protocols' variables, may be easily read. Kastenholz [Page 23] RFC 1471 PPP/LCP MIB June 1993 (3) Using SNMPv2, the operator can place the variables into MIB views which are protected in that the parties which have access to those MIB views use authentication and privacy protocols, or the operator may elect to make these views not accessible to any party. In order to facilitate this placement, all security-related variables are placed in separate MIB Tables. This eases the identification of the necessary MIB View Subtree. 7. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [6] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991. [8] Simpson, W., "The Point-to-Point Protocol for the Transmission of Multi-protocol Datagrams over Point-to-Point Links, RFC 1331, Daydreamer, May 1992. [9] McGregor, G., "The PPP Internet Protocol Control Protocol", RFC 1332, Merit, May 1992. Kastenholz [Page 24] RFC 1471 PPP/LCP MIB June 1993 [10] Baker, F., "Point-to-Point Protocol Extensions for Bridging", RFC 1220, ACC, April 1991. [11] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, L&A, Daydreamer, October 1992. [12] Simpson, W., "PPP Link Quality Monitoring", RFC 1333, Daydreamer, May 1992. [13] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. 8. Author's Address Frank Kastenholz FTP Software, Inc. 2 High Street North Andover, Mass 01845 USA Phone: (508) 685-4000 EMail: kasten@ftp.com Kastenholz [Page 25] snmp-mibs-downloader-1.1/mibrfcs/rfc1472.txt0000644000000000000000000006522111402176071015565 0ustar Network Working Group F. Kastenholz Request for Comments: 1472 FTP Software, Inc. June 1993 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. Table of Contents 1. The Network Management Framework ...................... 1 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 2 3. Overview .............................................. 2 3.1 Object Selection Criteria ............................ 2 3.2 Structure of the PPP ................................. 2 3.3 MIB Groups ........................................... 3 4. Definitions ........................................... 4 5. Acknowledgements ...................................... 9 6. Security Considerations ............................... 10 7. References ............................................ 11 8. Author's Address ...................................... 12 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is Kastenholz [Page 1] RFC 1472 PPP/Security MIB June 1993 wholly consistent with the SMI. STD 17/RFC 1213 which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects 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) [3] 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. 2.1. Format of Definitions Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [5,6]. 3. Overview 3.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, an explicit attempt was made to keep this MIB as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: (1) Require objects be essential for either fault or configuration management. In particular, objects for which the sole purpose was to debug implementations were explicitly excluded from the MIB. (2) Consider evidence of current use and/or utility. (3) Limit the total number of objects. (4) Exclude objects which are simply derivable from others in Kastenholz [Page 2] RFC 1472 PPP/Security MIB June 1993 this or other MIBs. 3.2. Structure of the PPP This section describes the basic model of PPP used in developing the PPP MIB. This information should be useful to the implementor in understanding some of the basic design decisions of the MIB. The PPP is not one single protocol but a large family of protocols. Each of these is, in itself, a fairly complex protocol. The PPP protocols may be divided into three rough categories: Control Protocols The Control Protocols are used to control the operation of the PPP. The Control Protocols include the Link Control Protocol (LCP), the Password Authentication Protocol (PAP), the Link Quality Report (LQR), and the Challenge Handshake Authentication Protocol (CHAP). Network Protocols The Network Protocols are used to move the network traffic over the PPP interface. A Network Protocol encapsulates the datagrams of a specific higher-layer protocol that is using the PPP as a data link. Note that within the context of PPP, the term "Network Protocol" does not imply an OSI Layer-3 protocol; for instance, there is a Bridging network protocol. Network Control Protocols (NCPs) The NCPs are used to control the operation of the Network Protocols. Generally, each Network Protocol has its own Network Control Protocol; thus, the IP Network Protocol has its IP Control Protocol, the Bridging Network Protocol has its Bridging Network Control Protocol and so on. This document specifies the objects used in managing one of these protocols, namely the PPP Authentication Protocols. 3.3. MIB Groups Objects in this MIB are arranged into several MIB groups. Each group is organized as a set of related objects. These groups are the basic unit of conformance: if the semantics of a group are applicable to an implementation then all objects in the group must be implemented. The PPP MIB is organized into several MIB Groups, including, but not limited to, the following groups: Kastenholz [Page 3] RFC 1472 PPP/Security MIB June 1993 o The PPP Link Group o The PPP LQR Group o The PPP LQR Extensions Group o The PPP IP Group o The PPP Bridge Group o The PPP Security Group This document specifies the following group: PPP Security Group The PPP Security Group contains all configuration and control variables that apply to PPP security. Implementation of this group is optional. Implementation is optional since the variables in this group provide configuration and control for the PPP Security functions. Thus, these variables should be protected by SNMPv2 security. If an agent does not support SNMPv2 with privacy it is strongly advised that this group not be implemented. See the section on "Security Considerations" at the end of this document. 4. Definitions PPP-SEC-MIB DEFINITIONS ::= BEGIN IMPORTS Counter FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 ppp FROM PPP-LCP-MIB; pppSecurity OBJECT IDENTIFIER ::= { ppp 2 } pppSecurityProtocols OBJECT IDENTIFIER ::= { pppSecurity 1 } -- The following uniquely identify the various protocols -- used by PPP security. These OBJECT IDENTIFIERS are -- used in the pppSecurityConfigProtocol and -- pppSecuritySecretsProtocol objects to identify to which -- protocols the table entries apply. pppSecurityPapProtocol OBJECT IDENTIFIER ::= { pppSecurityProtocols 1 } pppSecurityChapMD5Protocol OBJECT IDENTIFIER ::= { pppSecurityProtocols 2 } Kastenholz [Page 4] RFC 1472 PPP/Security MIB June 1993 -- PPP Security Group -- Implementation of this group is optional. -- This table allows the network manager to configure -- which security protocols are to be used on which -- link and in what order of preference each is to be tried pppSecurityConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppSecurityConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the configuration and preference parameters for PPP Security." ::= { pppSecurity 2 } pppSecurityConfigEntry OBJECT-TYPE SYNTAX PppSecurityConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Security configuration information for a particular PPP link." INDEX { pppSecurityConfigLink, pppSecurityConfigPreference } ::= { pppSecurityConfigTable 1 } PppSecurityConfigEntry ::= SEQUENCE { pppSecurityConfigLink INTEGER, pppSecurityConfigPreference INTEGER, pppSecurityConfigProtocol OBJECT IDENTIFIER, pppSecurityConfigStatus INTEGER } pppSecurityConfigLink OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-write STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry Kastenholz [Page 5] RFC 1472 PPP/Security MIB June 1993 in the interface table that is associated with the local PPP entity's link for which this particular security algorithm shall be attempted. A value of 0 indicates the default algorithm - i.e., this entry applies to all links for which explicit entries in the table do not exist." ::= { pppSecurityConfigEntry 1 } pppSecurityConfigPreference OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-write STATUS mandatory DESCRIPTION "The relative preference of the security protocol identified by pppSecurityConfigProtocol. Security protocols with lower values of pppSecurityConfigPreference are tried before protocols with higher values of pppSecurityConfigPreference." ::= { pppSecurityConfigEntry 2 } pppSecurityConfigProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "Identifies the security protocol to be attempted on the link identified by pppSecurityConfigLink at the preference level identified by pppSecurityConfigPreference. " ::= { pppSecurityConfigEntry 3 } pppSecurityConfigStatus OBJECT-TYPE SYNTAX INTEGER { invalid(1), valid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Setting this object to the value invalid(1) has the effect of invalidating the corresponding entry in the Kastenholz [Page 6] RFC 1472 PPP/Security MIB June 1993 pppSecurityConfigTable. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant pppSecurityConfigStatus object." DEFVAL { valid } ::= { pppSecurityConfigEntry 4 } -- This table contains all of the ID/Secret pair information. pppSecuritySecretsTable OBJECT-TYPE SYNTAX SEQUENCE OF PppSecuritySecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the identities and secrets used by the PPP authentication protocols. As this table contains secret information, it is expected that access to this table be limited to those SNMP Party-Pairs for which a privacy protocol is in use for all SNMP messages that the parties exchange. This table contains both the ID and secret pair(s) that the local PPP entity will advertise to the remote entity and the pair(s) that the local entity will expect from the remote entity. This table allows for multiple id/secret password pairs to be specified for a particular link by using the pppSecuritySecretsIdIndex object." ::= { pppSecurity 3 } pppSecuritySecretsEntry OBJECT-TYPE SYNTAX PppSecuritySecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Secret information." INDEX { pppSecuritySecretsLink, pppSecuritySecretsIdIndex } ::= { pppSecuritySecretsTable 1 } Kastenholz [Page 7] RFC 1472 PPP/Security MIB June 1993 PppSecuritySecretsEntry ::= SEQUENCE { pppSecuritySecretsLink INTEGER, pppSecuritySecretsIdIndex INTEGER, pppSecuritySecretsDirection INTEGER, pppSecuritySecretsProtocol OBJECT IDENTIFIER, pppSecuritySecretsIdentity OCTET STRING, pppSecuritySecretsSecret OCTET STRING, pppSecuritySecretsStatus INTEGER } pppSecuritySecretsLink OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "The link to which this ID/Secret pair applies. By convention, if the value of this object is 0 then the ID/Secret pair applies to all links." ::= { pppSecuritySecretsEntry 1 } pppSecuritySecretsIdIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each ID/Secret pair that has been defined for use on this link. This allows multiple ID/Secret pairs to be defined for each link. How the local entity selects which pair to use is a local implementation decision." ::= { pppSecuritySecretsEntry 2 } pppSecuritySecretsDirection OBJECT-TYPE SYNTAX INTEGER { local-to-remote(1), remote-to-local(2) } ACCESS read-write Kastenholz [Page 8] RFC 1472 PPP/Security MIB June 1993 STATUS mandatory DESCRIPTION "This object defines the direction in which a particular ID/Secret pair is valid. If this object is local-to-remote then the local PPP entity will use the ID/Secret pair when attempting to authenticate the local PPP entity to the remote PPP entity. If this object is remote-to-local then the local PPP entity will expect the ID/Secret pair to be used by the remote PPP entity when the remote PPP entity attempts to authenticate itself to the local PPP entity." ::= { pppSecuritySecretsEntry 3 } pppSecuritySecretsProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "The security protocol (e.g. CHAP or PAP) to which this ID/Secret pair applies." ::= { pppSecuritySecretsEntry 4 } pppSecuritySecretsIdentity OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The Identity of the ID/Secret pair. The actual format, semantics, and use of pppSecuritySecretsIdentity depends on the actual security protocol used. For example, if pppSecuritySecretsProtocol is pppSecurityPapProtocol then this object will contain a PAP Peer-ID. If pppSecuritySecretsProtocol is pppSecurityChapMD5Protocol then this object would contain the CHAP NAME parameter." ::= { pppSecuritySecretsEntry 5 } pppSecuritySecretsSecret OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory Kastenholz [Page 9] RFC 1472 PPP/Security MIB June 1993 DESCRIPTION "The secret of the ID/Secret pair. The actual format, semantics, and use of pppSecuritySecretsSecret depends on the actual security protocol used. For example, if pppSecuritySecretsProtocol is pppSecurityPapProtocol then this object will contain a PAP Password. If pppSecuritySecretsProtocol is pppSecurityChapMD5Protocol then this object would contain the CHAP MD5 Secret." ::= { pppSecuritySecretsEntry 6 } pppSecuritySecretsStatus OBJECT-TYPE SYNTAX INTEGER { invalid(1), valid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Setting this object to the value invalid(1) has the effect of invalidating the corresponding entry in the pppSecuritySecretsTable. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant pppSecuritySecretsStatus object." DEFVAL { valid } ::= { pppSecuritySecretsEntry 7 } END 5. Acknowledgements This document was produced by the PPP working group. In addition to the working group, the author wishes to thank the following individuals for their comments and contributions: Bill Simpson -- Daydreamer Glenn McGregor -- Merit Kastenholz [Page 10] RFC 1472 PPP/Security MIB June 1993 Jesse Walker -- DEC Chris Gunner -- DEC 6. Security Considerations The PPP MIB affords the network operator the ability to configure and control the PPP links of a particular system, including the PPP authentication protocols. This represents a security risk. These risks are addressed in the following manners: (1) All variables which represent a significant security risk are placed in separate, optional, MIB Groups. As the MIB Group is the quantum of implementation within a MIB, the implementor of the MIB may elect not to implement these groups. (2) The implementor may choose to implement the variables which present a security risk so that they may not be written, i.e., the variables are READ-ONLY. This method still presents a security risk, and is not recommended, in that the variables, specifically the PPP Authentication Protocols' variables, may be easily read. (3) Using SNMPv2, the operator can place the variables into MIB views which are protected in that the parties which have access to those MIB views use authentication and privacy protocols, or the operator may elect to make these views not accessible to any party. In order to facilitate this placement, all security-related variables are placed in separate MIB Tables. This eases the identification of the necessary MIB View Subtree. (4) The PPP Security Protocols MIB (this document) contains several objects which are very sensitive from a security point of view. Specifically, this MIB contains objects that define the PPP Peer Identities (which can be viewed as "userids") and the secrets used to authenticate those Peer Identities (similar to a "password" for the "userid"). Also, this MIB contains variables which would allow a network manager to control the operation of the security features of PPP. An intruder could disable PPP security if these variables were not properly protected. Thus, in order to preserve the integrity, security and privacy of the Kastenholz [Page 11] RFC 1472 PPP/Security MIB June 1993 PPP security features, an implementation will allow access to this MIB only via SNMPv2 and then only for parties which are privacy enhanced. Other access modes, e.g., SNMPv1 or SNMPv2 without privacy- enhancement, are very dangerous and the security of the PPP service may be compromised. 7. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [6] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991. [8] Simpson, W., "The Point-to-Point Protocol for the Transmission of Multi-protocol Datagrams over Point-to-Point Links, RFC 1331, Daydreamer, May 1992. [9] McGregor, G., "The PPP Internet Protocol Control Protocol", RFC 1332, Merit, May 1992. [10] Baker, F., "Point-to-Point Protocol Extensions for Bridging", RFC 1220, ACC, April 1991. Kastenholz [Page 12] RFC 1472 PPP/Security MIB June 1993 [11] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, L&A, Daydreamer, October 1992. [12] Simpson, W., "PPP Link Quality Monitoring", RFC 1333, Daydreamer, May 1992. 8. Author's Address Frank Kastenholz FTP Software, Inc. 2 High Street North Andover, Mass 01845 USA Phone: (508) 685-4000 EMail: kasten@ftp.com Kastenholz [Page 13] snmp-mibs-downloader-1.1/mibrfcs/rfc1473.txt0000644000000000000000000005022711402176071015566 0ustar Network Working Group F. Kastenholz Request for Comments: 1473 FTP Software, Inc. June 1993 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. Table of Contents 1. The Network Management Framework ...................... 1 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 2 3. Overview .............................................. 2 3.1 Object Selection Criteria ............................ 2 3.2 Structure of the PPP ................................. 2 3.3 MIB Groups ........................................... 3 4. Definitions ........................................... 4 5. Acknowledgements ...................................... 8 6. Security Considerations ............................... 8 7. References ............................................ 8 8. Author's Address ...................................... 9 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is Kastenholz [Page 1] RFC 1473 PPP/IP MIB June 1993 wholly consistent with the SMI. STD 17/RFC 1213 which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects 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) [3] 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. 2.1. Format of Definitions Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [5,6]. 3. Overview 3.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, an explicit attempt was made to keep this MIB as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: (1) Require objects be essential for either fault or configuration management. In particular, objects for which the sole purpose was to debug implementations were explicitly excluded from the MIB. (2) Consider evidence of current use and/or utility. (3) Limit the total number of objects. (4) Exclude objects which are simply derivable from others in Kastenholz [Page 2] RFC 1473 PPP/IP MIB June 1993 this or other MIBs. 3.2. Structure of the PPP This section describes the basic model of PPP used in developing the PPP MIB. This information should be useful to the implementor in understanding some of the basic design decisions of the MIB. The PPP is not one single protocol but a large family of protocols. Each of these is, in itself, a fairly complex protocol. The PPP protocols may be divided into three rough categories: Control Protocols The Control Protocols are used to control the operation of the PPP. The Control Protocols include the Link Control Protocol (LCP), the Password Authentication Protocol (PAP), the Link Quality Report (LQR), and the Challenge Handshake Authentication Protocol (CHAP). Network Protocols The Network Protocols are used to move the network traffic over the PPP interface. A Network Protocol encapsulates the datagrams of a specific higher-layer protocol that is using the PPP as a data link. Note that within the context of PPP, the term "Network Protocol" does not imply an OSI Layer-3 protocol; for instance, there is a Bridging network protocol. Network Control Protocols (NCPs) The NCPs are used to control the operation of the Network Protocols. Generally, each Network Protocol has its own Network Control Protocol; thus, the IP Network Protocol has its IP Control Protocol, the Bridging Network Protocol has its Bridging Network Control Protocol and so on. This document specifies the objects used in managing one of these protocols, namely the IP Network Control Protocol. 3.3. MIB Groups Objects in this MIB are arranged into several MIB groups. Each group is organized as a set of related objects. These groups are the basic unit of conformance: if the semantics of a group are applicable to an implementation then all objects in the group must be implemented. The PPP MIB is organized into several MIB Groups, including, but not limited to, the following groups: Kastenholz [Page 3] RFC 1473 PPP/IP MIB June 1993 o The PPP Link Group o The PPP LQR Group o The PPP LQR Extensions Group o The PPP IP Group o The PPP Bridge Group o The PPP Security Group This document specifies the following group: The PPP IP Group The PPP IP Group contains configuration, status, and control variables that apply to the operation of IP over PPP. Implementation of this group is mandatory for all implementations of PPP that support IP over PPP. 4. Definitions PPP-IP-NCP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter FROM RFC1155-SMI ifIndex FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212 ppp FROM PPP-LCP-MIB; -- The PPP IP Group. -- Implementation of this group is mandatory for all -- PPP implementations that support operating IP over PPP. pppIp OBJECT IDENTIFIER ::= { ppp 3 } pppIpTable OBJECT-TYPE SYNTAX SEQUENCE OF PppIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the IP parameters and statistics for the local PPP entity." ::= { pppIp 1 } pppIpEntry OBJECT-TYPE Kastenholz [Page 4] RFC 1473 PPP/IP MIB June 1993 SYNTAX PppIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "IPCP status information for a particular PPP link." INDEX { ifIndex } ::= { pppIpTable 1 } PppIpEntry ::= SEQUENCE { pppIpOperStatus INTEGER, pppIpLocalToRemoteCompressionProtocol INTEGER, pppIpRemoteToLocalCompressionProtocol INTEGER, pppIpRemoteMaxSlotId INTEGER, pppIpLocalMaxSlotId INTEGER } -- The following object reflect the values of the option -- parameters used in the PPP IP Control Protocol -- pppIpLocalToRemoteCompressionProtocol -- pppIpRemoteToLocalCompressionProtocol -- pppIpRemoteMaxSlotId -- pppIpLocalMaxSlotId -- These values are not available until after the PPP Option -- negotiation has completed, which is indicated by the link -- reaching the open state (i.e., pppIpOperStatus is set to -- opened). -- -- Therefore, when pppIpOperStatus is not opened -- the contents of these objects is undefined. The value -- returned when accessing the objects is an implementation -- dependent issue. pppIpOperStatus OBJECT-TYPE SYNTAX INTEGER {opened(1), not-opened(2)} ACCESS read-only STATUS mandatory DESCRIPTION "The operational status of the IP network protocol. If the value of this object is up then the finite state machine for the IP Kastenholz [Page 5] RFC 1473 PPP/IP MIB June 1993 network protocol has reached the Opened state." ::= { pppIpEntry 1 } pppIpLocalToRemoteCompressionProtocol OBJECT-TYPE SYNTAX INTEGER { none(1), vj-tcp(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The IP compression protocol that the local PPP-IP entity uses when sending packets to the remote PPP-IP entity. The value of this object is meaningful only when the link has reached the open state (pppIpOperStatus is opened)." ::= { pppIpEntry 2 } pppIpRemoteToLocalCompressionProtocol OBJECT-TYPE SYNTAX INTEGER { none(1), vj-tcp(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The IP compression protocol that the remote PPP-IP entity uses when sending packets to the local PPP-IP entity. The value of this object is meaningful only when the link has reached the open state (pppIpOperStatus is opened)." ::= { pppIpEntry 3 } pppIpRemoteMaxSlotId OBJECT-TYPE SYNTAX INTEGER(0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The Max-Slot-Id parameter that the remote node has advertised and that is in use on the link. If vj-tcp header compression is not in use on the link then the value of this object shall be 0. The value of this object is meaningful only when the link has reached the open state (pppIpOperStatus is opened)." Kastenholz [Page 6] RFC 1473 PPP/IP MIB June 1993 ::= { pppIpEntry 4 } pppIpLocalMaxSlotId OBJECT-TYPE SYNTAX INTEGER(0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The Max-Slot-Id parameter that the local node has advertised and that is in use on the link. If vj-tcp header compression is not in use on the link then the value of this object shall be 0. The value of this object is meaningful only when the link has reached the open state (pppIpOperStatus is opened)." ::= { pppIpEntry 5 } -- -- The PPP IP Configuration table. -- This is a separate table in order to facilitate -- placing these variables in a separate MIB view. -- pppIpConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppIpConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing configuration variables for the IPCP for the local PPP entity." ::= { pppIp 2 } pppIpConfigEntry OBJECT-TYPE SYNTAX PppIpConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "IPCP information for a particular PPP link." INDEX { ifIndex } ::= { pppIpConfigTable 1 } PppIpConfigEntry ::= SEQUENCE { pppIpConfigAdminStatus INTEGER, pppIpConfigCompression Kastenholz [Page 7] RFC 1473 PPP/IP MIB June 1993 INTEGER } pppIpConfigAdminStatus OBJECT-TYPE SYNTAX INTEGER {open(1), close(2)} ACCESS read-write STATUS mandatory DESCRIPTION "The immediate desired status of the IP network protocol. Setting this object to open will inject an administrative open event into the IP network protocol's finite state machine. Setting this object to close will inject an administrative close event into the IP network protocol's finite state machine." ::= { pppIpConfigEntry 1 } pppIpConfigCompression OBJECT-TYPE SYNTAX INTEGER { none(1), vj-tcp(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If none(1) then the local node will not attempt to negotiate any IP Compression option. Otherwise, the local node will attempt to negotiate compression mode indicated by the enumerated value. Changing this object will have effect when the link is next restarted." REFERENCE "Section 4.0, Van Jacobson TCP/IP Header Compression of RFC1332." DEFVAL { none } ::= { pppIpConfigEntry 2 } END 5. Acknowledgements This document was produced by the PPP working group. In addition to the working group, the author wishes to thank the following individuals for their comments and contributions: Bill Simpson -- Daydreamer Kastenholz [Page 8] RFC 1473 PPP/IP MIB June 1993 Glenn McGregor -- Merit Jesse Walker -- DEC Chris Gunner -- DEC 6. Security Considerations The PPP MIB affords the network operator the ability to configure and control the PPP links of a particular system, including the PPP authentication protocols. This represents a security risk. These risks are addressed in the following manners: (1) All variables which represent a significant security risk are placed in separate, optional, MIB Groups. As the MIB Group is the quantum of implementation within a MIB, the implementor of the MIB may elect not to implement these groups. (2) The implementor may choose to implement the variables which present a security risk so that they may not be written, i.e., the variables are READ-ONLY. This method still presents a security risk, and is not recommended, in that the variables, specifically the PPP Authentication Protocols' variables, may be easily read. (3) Using SNMPv2, the operator can place the variables into MIB views which are protected in that the parties which have access to those MIB views use authentication and privacy protocols, or the operator may elect to make these views not accessible to any party. In order to facilitate this placement, all security-related variables are placed in separate MIB Tables. This eases the identification of the necessary MIB View Subtree. 7. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Kastenholz [Page 9] RFC 1473 PPP/IP MIB June 1993 Standard 8824, December 1987. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [6] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991. [8] Simpson, W., "The Point-to-Point Protocol for the Transmission of Multi-protocol Datagrams over Point-to-Point Links, RFC 1331, Daydreamer, May 1992. [9] McGregor, G., "The PPP Internet Protocol Control Protocol", RFC 1332, Merit, May 1992. [10] Baker, F., "Point-to-Point Protocol Extensions for Bridging", RFC 1220, ACC, April 1991. [11] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, L&A, Daydreamer, October 1992. [12] Simpson, W., "PPP Link Quality Monitoring", RFC 1333, Daydreamer, May 1992. 8. Author's Address Frank Kastenholz FTP Software, Inc. 2 High Street North Andover, Mass 01845 USA Phone: (508) 685-4000 EMail: kasten@ftp.com Kastenholz [Page 10] snmp-mibs-downloader-1.1/mibrfcs/rfc1474.txt0000644000000000000000000007614611402176071015577 0ustar Network Working Group F. Kastenholz Request for Comments: 1474 FTP Software, Inc. June 1993 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. Table of Contents 1. The Network Management Framework ...................... 1 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 2 3. Overview .............................................. 2 3.1 Object Selection Criteria ............................ 2 3.2 Structure of the PPP ................................. 3 3.3 MIB Groups ........................................... 3 4. Definitions ........................................... 4 5. Acknowledgements ...................................... 13 6. Security Considerations ............................... 14 7. References ............................................ 14 8. Author's Address ...................................... 15 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is Kastenholz [Page 1] RFC 1474 PPP/Bridge MIB June 1993 wholly consistent with the SMI. STD 17/RFC 1213 which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects 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) [3] 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. 2.1. Format of Definitions Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [5,6]. 3. Overview 3.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, an explicit attempt was made to keep this MIB as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: (1) Require objects be essential for either fault or configuration management. In particular, objects for which the sole purpose was to debug implementations were explicitly excluded from the MIB. (2) Consider evidence of current use and/or utility. (3) Limit the total number of objects. (4) Exclude objects which are simply derivable from others in Kastenholz [Page 2] RFC 1474 PPP/Bridge MIB June 1993 this or other MIBs. 3.2. Structure of the PPP This section describes the basic model of PPP used in developing the PPP MIB. This information should be useful to the implementor in understanding some of the basic design decisions of the MIB. The PPP is not one single protocol but a large family of protocols. Each of these is, in itself, a fairly complex protocol. The PPP protocols may be divided into three rough categories: Control Protocols The Control Protocols are used to control the operation of the PPP. The Control Protocols include the Link Control Protocol (LCP), the Password Authentication Protocol (PAP), the Link Quality Report (LQR), and the Challenge Handshake Authentication Protocol (CHAP). Network Protocols The Network Protocols are used to move the network traffic over the PPP interface. A Network Protocol encapsulates the datagrams of a specific higher-layer protocol that is using the PPP as a data link. Note that within the context of PPP, the term "Network Protocol" does not imply an OSI Layer-3 protocol; for instance, there is a Bridging network protocol. Network Control Protocols (NCPs) The NCPs are used to control the operation of the Network Protocols. Generally, each Network Protocol has its own Network Control Protocol; thus, the IP Network Protocol has its IP Control Protocol, the Bridging Network Protocol has its Bridging Network Control Protocol and so on. This document specifies the objects used in managing one of these protocols, namely the Bridge Network Control Protocol. 3.3. MIB Groups Objects in this MIB are arranged into several MIB groups. Each group is organized as a set of related objects. These groups are the basic unit of conformance: if the semantics of a group are applicable to an implementation then all objects in the group must be implemented. The PPP MIB is organized into several MIB Groups, including, but not limited to, the following groups: Kastenholz [Page 3] RFC 1474 PPP/Bridge MIB June 1993 o The PPP Link Group o The PPP LQR Group o The PPP LQR Extensions Group o The PPP IP Group o The PPP Bridge Group o The PPP Security Group This document specifies the following group: The PPP Bridge Group The PPP Bridge Group contains configuration, status, and control variables that apply to the operation of Bridging over PPP. Implementation of this group is mandatory for all implementations of PPP that support the Bridging over PPP. 4. Definitions PPP-BRIDGE-NCP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter FROM RFC1155-SMI ifIndex FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212 ppp FROM PPP-LCP-MIB; pppBridge OBJECT IDENTIFIER ::= { ppp 4 } -- -- The PPP Bridge NCP Group. -- Implementation of this group is mandatory for all -- PPP implementations that support MAC Bridging over -- PPP (RFC1220). -- -- The following object reflect the values of the option -- parameters used in the PPP Link Control Protocol -- pppBridgeLocalToRemoteTinygramCompression -- pppBridgeRemoteToLocalTinygramCompression -- pppBridgeLocalToRemoteLanId -- pppBridgeRemoteToLocalLanId -- -- These values are not available until after the PPP Option Kastenholz [Page 4] RFC 1474 PPP/Bridge MIB June 1993 -- negotiation has completed, which is indicated by the link -- reaching the open state (i.e. pppBridgeOperStatus is set to -- opened). -- -- Therefore, when pppBridgeOperStatus is not opened -- the contents of these objects is undefined. The value -- returned when accessing the objects is an implementation -- dependent issue. pppBridgeTable OBJECT-TYPE SYNTAX SEQUENCE OF PppBridgeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the parameters and statistics for the local PPP entity that are related to the operation of Bridging over the PPP." ::= { pppBridge 1 } pppBridgeEntry OBJECT-TYPE SYNTAX PppBridgeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Bridging information for a particular PPP link." INDEX { ifIndex } ::= { pppBridgeTable 1 } PppBridgeEntry ::= SEQUENCE { pppBridgeOperStatus INTEGER, pppBridgeLocalToRemoteTinygramCompression INTEGER, pppBridgeRemoteToLocalTinygramCompression INTEGER, pppBridgeLocalToRemoteLanId INTEGER, pppBridgeRemoteToLocalLanId INTEGER } pppBridgeOperStatus OBJECT-TYPE SYNTAX INTEGER {opened(1), not-opened(2)} ACCESS read-only Kastenholz [Page 5] RFC 1474 PPP/Bridge MIB June 1993 STATUS mandatory DESCRIPTION "The operational status of the Bridge network protocol. If the value of this object is up then the finite state machine for the Bridge network protocol has reached the Opened state." ::= { pppBridgeEntry 1 } pppBridgeLocalToRemoteTinygramCompression OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local node will perform Tinygram Compression when sending packets to the remote entity. If false then the local entity will not perform Tinygram Compression. If true then the local entity will perform Tinygram Compression. The value of this object is meaningful only when the link has reached the open state (pppBridgeOperStatus is opened)." REFERENCE "Section 6.7, Tinygram Compression Option, of RFC1220" ::= { pppBridgeEntry 2 } pppBridgeRemoteToLocalTinygramCompression OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "If false(1) then the remote entity is not expected to perform Tinygram Compression. If true then the remote entity is expected to perform Tinygram Compression. The value of this object is meaningful only when the link has reached the open state (pppBridgeOperStatus is opened)." REFERENCE "Section 6.7, Tinygram Compression Option, of RFC1220" ::= { pppBridgeEntry 3 } Kastenholz [Page 6] RFC 1474 PPP/Bridge MIB June 1993 pppBridgeLocalToRemoteLanId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local node will include the LAN Identification field in transmitted packets or not. If false(1) then the local node will not transmit this field, true(2) means that the field will be transmitted. The value of this object is meaningful only when the link has reached the open state (pppBridgeOperStatus is opened)." REFERENCE "Section 6.8, LAN Identification Option, of RFC1220" ::= { pppBridgeEntry 4 } pppBridgeRemoteToLocalLanId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the remote node has indicated that it will include the LAN Identification field in transmitted packets or not. If false(1) then the field will not be transmitted, if true(2) then the field will be transmitted. The value of this object is meaningful only when the link has reached the open state (pppBridgeOperStatus is opened)." REFERENCE "Section 6.8, LAN Identification Option, of RFC1220" ::= { pppBridgeEntry 5 } -- -- The PPP Bridge Configuration table -- pppBridgeConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppBridgeConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the parameters and statistics Kastenholz [Page 7] RFC 1474 PPP/Bridge MIB June 1993 for the local PPP entity that are related to the operation of Bridging over the PPP." ::= { pppBridge 2 } pppBridgeConfigEntry OBJECT-TYPE SYNTAX PppBridgeConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Bridging Configuration information for a particular PPP link." INDEX { ifIndex } ::= { pppBridgeConfigTable 1 } PppBridgeConfigEntry ::= SEQUENCE { pppBridgeConfigAdminStatus INTEGER, pppBridgeConfigTinygram INTEGER, pppBridgeConfigRingId INTEGER, pppBridgeConfigLineId INTEGER, pppBridgeConfigLanId INTEGER } pppBridgeConfigAdminStatus OBJECT-TYPE SYNTAX INTEGER { open(1), close(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The immediate desired status of the Bridging network protocol. Setting this object to open will inject an administrative open event into the Bridging network protocol's finite state machine. Setting this object to close will inject an administrative close event into the Bridging network protocol's finite state machine." ::= { pppBridgeConfigEntry 1 } pppBridgeConfigTinygram OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } Kastenholz [Page 8] RFC 1474 PPP/Bridge MIB June 1993 ACCESS read-write STATUS mandatory DESCRIPTION "If false then the local BNCP entity will not initiate the Tinygram Compression Option Negotiation. If true then the local BNCP entity will initiate negotiation of this option." REFERENCE "Section 6.7, Tinygram Compression Option, of RFC1220" DEFVAL { true } ::= { pppBridgeConfigEntry 2 } pppBridgeConfigRingId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If false then the local PPP Entity will not initiate a Remote Ring Identification Option negotiation. If true then the local PPP entity will intiate this negotiation. This MIB object is relevant only if the interface is for 802.5 Token Ring bridging." REFERENCE "Section 6.4, IEEE 802.5 Remote Ring Identification Option, of RFC1220" DEFVAL { false } ::= { pppBridgeConfigEntry 3 } pppBridgeConfigLineId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If false then the local PPP Entity is not to initiate a Line Identification Option negotiation. If true then the local PPP entity will intiate this negotiation. This MIB object is relevant only if the interface is for 802.5 Token Ring bridging." REFERENCE "Section 6.5, IEEE 802.5 Line Identification Option, of RFC1220" DEFVAL { false } ::= { pppBridgeConfigEntry 4 } Kastenholz [Page 9] RFC 1474 PPP/Bridge MIB June 1993 pppBridgeConfigLanId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If false then the local BNCP entity will not initiate the LAN Identification Option Negotiation. If true then the local BNCP entity will initiate negotiation of this option." REFERENCE "Section 6.8, LAN Identification Option, of RFC1220" DEFVAL { false } ::= { pppBridgeConfigEntry 5 } -- -- The PPP Bridge Media Status Table -- pppBridgeMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF PppBridgeMediaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table identifying which MAC media types are enabled for the Bridging NCPs." ::= { pppBridge 3 } pppBridgeMediaEntry OBJECT-TYPE SYNTAX PppBridgeMediaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Status of a specific MAC Type for a specific PPP Link." INDEX { ifIndex, pppBridgeMediaMacType } ::= { pppBridgeMediaTable 1 } PppBridgeMediaEntry ::= SEQUENCE { pppBridgeMediaMacType INTEGER, pppBridgeMediaLocalStatus INTEGER, pppBridgeMediaRemoteStatus INTEGER Kastenholz [Page 10] RFC 1474 PPP/Bridge MIB June 1993 } pppBridgeMediaMacType OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "The MAC type for which this entry in the pppBridgeMediaTable is providing status information. Valid values for this object are defined in Section 6.6 MAC Type Support Selection of RFC1220 (Bridging Point-to-Point Protocol)." REFERENCE "Section 6.6, MAC Type Support Selection, of RFC1212." ::= { pppBridgeMediaEntry 1 } pppBridgeMediaLocalStatus OBJECT-TYPE SYNTAX INTEGER { accept(1), dont-accept(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local PPP Bridging Entity will accept packets of the protocol type identified in pppBridgeMediaMacType on the PPP link identified by ifIndex or not. If this object is accept then any packets of the indicated MAC type will be received and properly processed. If this object is dont- accept then received packets of the indicated MAC type will not be properly processed." REFERENCE "Section 6.6, MAC Type Support Selection, of RFC1212." ::= { pppBridgeMediaEntry 2 } pppBridgeMediaRemoteStatus OBJECT-TYPE SYNTAX INTEGER { accept(1), dont-accept(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local PPP Bridging Entity believes that the remote PPP Bridging Entity will accept packets of the protocol type identified in pppBridgeMediaMacType on the PPP Kastenholz [Page 11] RFC 1474 PPP/Bridge MIB June 1993 link identified by ifIndex or not." REFERENCE "Section 6.6, MAC Type Support Selection, of RFC1212." ::= { pppBridgeMediaEntry 3 } -- -- The PPP Bridge Media Configuration Table -- pppBridgeMediaConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppBridgeMediaConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table identifying which MAC media types are enabled for the Bridging NCPs." ::= { pppBridge 4 } pppBridgeMediaConfigEntry OBJECT-TYPE SYNTAX PppBridgeMediaConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Status of a specific MAC Type for a specific PPP Link." INDEX { ifIndex, pppBridgeMediaConfigMacType } ::= { pppBridgeMediaConfigTable 1 } PppBridgeMediaConfigEntry ::= SEQUENCE { pppBridgeMediaConfigMacType INTEGER, pppBridgeMediaConfigLocalStatus INTEGER } pppBridgeMediaConfigMacType OBJECT-TYPE SYNTAX INTEGER(0..2147483647) ACCESS read-write STATUS mandatory DESCRIPTION "The MAC type for which this entry in the pppBridgeMediaConfigTable is providing status information. Valid values for this object are Kastenholz [Page 12] RFC 1474 PPP/Bridge MIB June 1993 defined in Section 6.6 MAC Type Support Selection of RFC1220 (Bridging Point-to-Point Protocol)." REFERENCE "Section 6.6, MAC Type Support Selection, of RFC1212." ::= { pppBridgeMediaConfigEntry 1 } pppBridgeMediaConfigLocalStatus OBJECT-TYPE SYNTAX INTEGER { accept(1), dont-accept(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Indicates whether the local PPP Bridging Entity should accept packets of the protocol type identified in pppBridgeMediaConfigMacType on the PPP link identified by ifIndex or not. Setting this object to the value dont-accept has the affect of invalidating the corresponding entry in the pppBridgeMediaConfigTable object. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Changing this object will have effect when the link is next restarted." REFERENCE "Section 6.6, MAC Type Support Selection, of RFC1212." ::= { pppBridgeMediaConfigEntry 2 } END 6. Acknowledgements This document was produced by the PPP working group. In addition to the working group, the author wishes to thank the following individuals for their comments and contributions: Bill Simpson -- Daydreamer Glenn McGregor -- Merit Jesse Walker -- DEC Chris Gunner -- DEC Kastenholz [Page 13] RFC 1474 PPP/Bridge MIB June 1993 6. Security Considerations The PPP MIB affords the network operator the ability to configure and control the PPP links of a particular system, including the PPP authentication protocols. This represents a security risk. These risks are addressed in the following manners: (1) All variables which represent a significant security risk are placed in separate, optional, MIB Groups. As the MIB Group is the quantum of implementation within a MIB, the implementor of the MIB may elect not to implement these groups. (2) The implementor may choose to implement the variables which present a security risk so that they may not be written, i.e., the variables are READ-ONLY. This method still presents a security risk, and is not recommended, in that the variables, specifically the PPP Authentication Protocols' variables, may be easily read. (3) Using SNMPv2, the operator can place the variables into MIB views which are protected in that the parties which have access to those MIB views use authentication and privacy protocols, or the operator may elect to make these views not accessible to any party. In order to facilitate this placement, all security-related variables are placed in separate MIB Tables. This eases the identification of the necessary MIB View Subtree. 7. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One Kastenholz [Page 14] RFC 1474 PPP/Bridge MIB June 1993 (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [6] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991. [8] Simpson, W., "The Point-to-Point Protocol for the Transmission of Multi-protocol Datagrams over Point-to-Point Links, RFC 1331, Daydreamer, May 1992. [9] McGregor, G., "The PPP Internet Protocol Control Protocol", RFC 1332, Merit, May 1992. [10] Baker, F., "Point-to-Point Protocol Extensions for Bridging", RFC 1220, ACC, April 1991. [11] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, L&A, Daydreamer, October 1992. [12] Simpson, W., "PPP Link Quality Monitoring", RFC 1333, Daydreamer, May 1992. 8. Author's Address Frank Kastenholz FTP Software, Inc. 2 High Street North Andover, Mass 01845 USA Phone: (508) 685-4000 EMail: kasten@ftp.com Kastenholz [Page 15] snmp-mibs-downloader-1.1/mibrfcs/rfc1512.txt0000644000000000000000000032405511402176071015563 0ustar Network Working Group J. Case Request for Comments: 1512 The University of Tennesse and Updates: 1285 SNMP Research, Incorporated A. Rijsinghani Digital Equipment Corporation September 1993 FDDI Management Information Base Status of this Memo This RFC 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" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard [8], which has been forwarded for publication by the X3T9.5 committee. Table of Contents 1. The Network Management Framework ...................... 2 1.1 Object Definitions ................................... 2 1.2 Format of Definitions ................................ 2 2. Overview .............................................. 2 2.1 Textual Conventions .................................. 3 3. Changes from RFC 1285 ................................. 3 4. Object Definitions .................................... 4 4.1 The SMT Group ........................................ 6 4.2 The MAC Group ........................................ 17 4.3 The Enhanced MAC Counters Group ...................... 29 4.4 The PATH Group ....................................... 32 4.5 The PORT Group ....................................... 38 5. Acknowledgements ...................................... 48 6. References ............................................ 50 7. Security Considerations ............................... 51 8. Authors' Addresses .................................... 51 Case & Rijsinghani [Page 1] RFC 1512 FDDI MIB September 1993 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: o STD 16, RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16, RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o STD 15, RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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 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. 1.2. Format of Definitions Section 4 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [7]. 2. Overview This document defines the managed objects for FDDI devices which are to be accessible via the Simple Network Management Protocol (SNMP). At present, this applies to these values of the ifType variable in the Internet-standard MIB: fddi(15) For these interfaces, the value of the ifSpecific variable in the Case & Rijsinghani [Page 2] RFC 1512 FDDI MIB September 1993 MIB-II [4] has the OBJECT IDENTIFIER value: fddimib OBJECT IDENTIFIER ::= { fddi 73 } The definitions of the objects presented here draws heavily from related work in the ANSI X3T9.5 committee and the SMT subcommittee of that committee [8]. In fact, the definitions of the managed objects in this document are, to the maximum extent possible, identical to those identified by the ANSI committee. The semantics of each managed object should be the same with syntactic changes made as necessary to recast the objects in terms of the Internet-standard SMI and MIB so as to be compatible with the SNMP. Examples of these syntactic changes include remapping booleans to enumerated integers, remapping bit strings to octet strings, and the like. In addition, the naming of the objects was changed to achieve compatibility. These minimal syntactic changes with no semantic changes should allow implementations of SNMP manageable FDDI systems to share instrumentation with other network management schemes and thereby minimize implementation cost. In addition, the translation of information conveyed by managed objects from one network management scheme to another is eased by these shared definitions. Only the essential variables, as indicated by their mandatory status in the ANSI specification, were retained in this document. The importance of variables which have an optional status in the ANSI specification were perceived as being less widely accepted. 2.1. Textual Conventions Several new datatypes are introduced as a textual convention in this MIB document. These textual conventions enhance the readability of the document and ease comparisons with its ANSI counterpart. It should be noted that the introduction of these textual conventions has no effect on either the syntax or the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. 3. Changes from RFC 1285 The changes from RFC 1285 [2] to this document, based on changes from ANSI SMT 6.2 to SMT 7.3, were so numerous that the objects in this MIB module are located on a different branch of the MIB tree. No Case & Rijsinghani [Page 3] RFC 1512 FDDI MIB September 1993 assumptions should be made about compatibility with RFC 1285. 4. Object Definitions FDDI-SMT73-MIB DEFINITIONS ::= BEGIN IMPORTS Counter FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [7]. -- this is the FDDI MIB module fddi OBJECT IDENTIFIER ::= { transmission 15 } fddimib OBJECT IDENTIFIER ::= { fddi 73 } -- textual conventions FddiTimeNano ::= INTEGER (0..2147483647) -- This data type specifies 1 nanosecond units as -- an integer value. -- -- NOTE: The encoding is normal integer representation, not -- two's complement. Since this type is used for variables -- which are encoded as TimerTwosComplement in the ANSI -- specification, two operations need to be performed on such -- variables to convert from ANSI form to SNMP form: -- -- 1) Convert from two's complement to normal integer -- representation -- 2) Multiply by 80 to convert from 80 nsec to 1 nsec units -- -- No resolution is lost. Moreover, the objects for which -- this data type is used effectively do not lose any range -- due to the lower maximum value since they do not require -- the full range. -- -- Example: If fddimibMACTReq had a value of 8 ms, it would -- be stored in ANSI TimerTwosComplement format as 0xFFFE7960 -- [8 ms is 100000 in 80 nsec units, which is then converted -- to two's complement] but be reported as 8000000 in SNMP -- since it is encoded here as FddiTimeNano. Case & Rijsinghani [Page 4] RFC 1512 FDDI MIB September 1993 FddiTimeMilli ::= INTEGER (0..2147483647) -- This data type is used for some FDDI timers. It specifies -- time in 1 millisecond units, in normal integer -- representation. FddiResourceId ::= INTEGER (0..65535) -- This data type is used to refer to an instance of a MAC, -- PORT, or PATH Resource ID. Indexing begins -- at 1. Zero is used to indicate the absence of a resource. FddiSMTStationIdType ::= OCTET STRING (SIZE (8)) -- The unique identifier for the FDDI station. This is a -- string of 8 octets, represented as X' yy yy xx xx xx xx -- xx xx' with the low order 6 octet (xx) from a unique IEEE -- assigned address. The high order two bits of the IEEE -- address, the group address bit and the administration bit -- (Universal/Local) bit should both be zero. The first two -- octets, the yy octets, are implementor-defined. -- -- The representation of the address portion of the station id -- is in the IEEE (ANSI/IEEE P802.1A) canonical notation for -- 48 bit addresses. The canonical form is a 6-octet string -- where the first octet contains the first 8 bits of the -- address, with the I/G(Individual/Group) address bit as the -- least significant bit and the U/L (Universal/Local) bit -- as the next more significant bit, and so on. Note that -- addresses in the ANSI FDDI standard SMT frames are -- represented in FDDI MAC order. FddiMACLongAddressType ::= OCTET STRING (SIZE (6)) -- The representation of long MAC addresses as management -- values is in the IEEE (ANSI/IEEE P802.1A) canonical -- notation for 48 bit addresses. The canonical form is a -- 6-octet string where the first octet contains the first 8 -- bits of the address, with the I/G (Individual/Group) -- address bit as the least significant bit and the U/L -- (Universal/Local) bit as the next more significant bit, -- and so on. Note that the addresses in the SMT frames are -- represented in FDDI MAC order. -- groups in the FDDI MIB module fddimibSMT OBJECT IDENTIFIER ::= { fddimib 1 } fddimibMAC OBJECT IDENTIFIER ::= { fddimib 2 } fddimibMACCounters OBJECT IDENTIFIER ::= { fddimib 3 } Case & Rijsinghani [Page 5] RFC 1512 FDDI MIB September 1993 fddimibPATH OBJECT IDENTIFIER ::= { fddimib 4 } fddimibPORT OBJECT IDENTIFIER ::= { fddimib 5 } -- the SMT group -- Implementation of the SMT group is mandatory for all -- systems which implement manageable FDDI subsystems. fddimibSMTNumber OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The number of SMT implementations (regardless of their current state) on this network management application entity. The value for this variable must remain constant at least from one re- initialization of the entity's network management system to the next re-initialization." ::= { fddimibSMT 1 } -- the SMT table fddimibSMTTable OBJECT-TYPE SYNTAX SEQUENCE OF FddimibSMTEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of SMT entries. The number of entries shall not exceed the value of fddimibSMTNumber." ::= { fddimibSMT 2 } fddimibSMTEntry OBJECT-TYPE SYNTAX FddimibSMTEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An SMT entry containing information common to a given SMT." INDEX { fddimibSMTIndex } ::= { fddimibSMTTable 1 } FddimibSMTEntry ::= SEQUENCE { fddimibSMTIndex INTEGER, Case & Rijsinghani [Page 6] RFC 1512 FDDI MIB September 1993 fddimibSMTStationId FddiSMTStationIdType, fddimibSMTOpVersionId INTEGER, fddimibSMTHiVersionId INTEGER, fddimibSMTLoVersionId INTEGER, fddimibSMTUserData OCTET STRING, fddimibSMTMIBVersionId INTEGER, fddimibSMTMACCts INTEGER, fddimibSMTNonMasterCts INTEGER, fddimibSMTMasterCts INTEGER, fddimibSMTAvailablePaths INTEGER, fddimibSMTConfigCapabilities INTEGER, fddimibSMTConfigPolicy INTEGER, fddimibSMTConnectionPolicy INTEGER, fddimibSMTTNotify INTEGER, fddimibSMTStatRptPolicy INTEGER, fddimibSMTTraceMaxExpiration FddiTimeMilli, fddimibSMTBypassPresent INTEGER, fddimibSMTECMState INTEGER, fddimibSMTCFState INTEGER, fddimibSMTRemoteDisconnectFlag INTEGER, fddimibSMTStationStatus INTEGER, fddimibSMTPeerWrapFlag INTEGER, fddimibSMTTimeStamp FddiTimeMilli, fddimibSMTTransitionTimeStamp FddiTimeMilli, Case & Rijsinghani [Page 7] RFC 1512 FDDI MIB September 1993 fddimibSMTStationAction INTEGER } fddimibSMTIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each SMT. The value for each SMT must remain constant at least from one re- initialization of the entity's network management system to the next re-initialization." ::= { fddimibSMTEntry 1 } fddimibSMTStationId OBJECT-TYPE SYNTAX FddiSMTStationIdType -- OCTET STRING (SIZE (8)) ACCESS read-only STATUS mandatory DESCRIPTION "Used to uniquely identify an FDDI station." REFERENCE "ANSI { fddiSMT 11 }" ::= { fddimibSMTEntry 2 } fddimibSMTOpVersionId OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The version that this station is using for its operation (refer to ANSI 7.1.2.2). The value of this variable is 2 for this SMT revision." REFERENCE "ANSI { fddiSMT 13 }" ::= { fddimibSMTEntry 3 } fddimibSMTHiVersionId OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The highest version of SMT that this station supports (refer to ANSI 7.1.2.2)." REFERENCE "ANSI { fddiSMT 14 }" ::= { fddimibSMTEntry 4 } Case & Rijsinghani [Page 8] RFC 1512 FDDI MIB September 1993 fddimibSMTLoVersionId OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The lowest version of SMT that this station supports (refer to ANSI 7.1.2.2)." REFERENCE "ANSI { fddiSMT 15 }" ::= { fddimibSMTEntry 5 } fddimibSMTUserData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (32)) ACCESS read-write STATUS mandatory DESCRIPTION "This variable contains 32 octets of user defined information. The information shall be an ASCII string." REFERENCE "ANSI { fddiSMT 17 }" ::= { fddimibSMTEntry 6 } fddimibSMTMIBVersionId OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The version of the FDDI MIB of this station. The value of this variable is 1 for this SMT revision." REFERENCE "ANSI { fddiSMT 18 }" ::= { fddimibSMTEntry 7 } fddimibSMTMACCts OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The number of MACs in this station or concentrator." REFERENCE "ANSI { fddiSMT 21 }" ::= { fddimibSMTEntry 8 } fddimibSMTNonMasterCts OBJECT-TYPE SYNTAX INTEGER (0..2) Case & Rijsinghani [Page 9] RFC 1512 FDDI MIB September 1993 ACCESS read-only STATUS mandatory DESCRIPTION "The value of this variable is the number of A, B, and S ports in this station or concentrator." REFERENCE "ANSI { fddiSMT 22 }" ::= { fddimibSMTEntry 9 } fddimibSMTMasterCts OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The number of M Ports in a node. If the node is not a concentrator, the value of the variable is zero." REFERENCE "ANSI { fddiSMT 23 }" ::= { fddimibSMTEntry 10 } fddimibSMTAvailablePaths OBJECT-TYPE SYNTAX INTEGER (0..7) ACCESS read-only STATUS mandatory DESCRIPTION "A value that indicates the PATH types available in the station. The value is a sum. This value initially takes the value zero, then for each type of PATH that this node has available, 2 raised to a power is added to the sum. The powers are according to the following table: Path Power Primary 0 Secondary 1 Local 2 For example, a station having Primary and Local PATHs available would have a value of 5 (2**0 + 2**2)." REFERENCE "ANSI { fddiSMT 24 }" ::= { fddimibSMTEntry 11 } fddimibSMTConfigCapabilities OBJECT-TYPE Case & Rijsinghani [Page 10] RFC 1512 FDDI MIB September 1993 SYNTAX INTEGER (0..3) ACCESS read-only STATUS mandatory DESCRIPTION "A value that indicates the configuration capabilities of a node. The 'Hold Available' bit indicates the support of the optional Hold Function, which is controlled by fddiSMTConfigPolicy. The 'CF-Wrap-AB' bit indicates that the station has the capability of performing a wrap_ab (refer to ANSI SMT 9.7.2.2). The value is a sum. This value initially takes the value zero, then for each of the configuration policies currently enforced on the node, 2 raised to a power is added to the sum. The powers are according to the following table: Policy Power holdAvailable 0 CF-Wrap-AB 1 " REFERENCE "ANSI { fddiSMT 25 }" ::= { fddimibSMTEntry 12 } fddimibSMTConfigPolicy OBJECT-TYPE SYNTAX INTEGER (0..1) ACCESS read-write STATUS mandatory DESCRIPTION "A value that indicates the configuration policies currently desired in a node. 'Hold' is one of the terms used for the Hold Flag, an optional ECM flag used to enable the optional Hold policy. The value is a sum. This value initially takes the value zero, then for each of the configuration policies currently enforced on the node, 2 raised to a power is added to the sum. The powers are according to the following table: Policy Power configurationhold 0 " REFERENCE "ANSI { fddiSMT 26 }" ::= { fddimibSMTEntry 13 } fddimibSMTConnectionPolicy OBJECT-TYPE Case & Rijsinghani [Page 11] RFC 1512 FDDI MIB September 1993 SYNTAX INTEGER (32768..65535) ACCESS read-write STATUS mandatory DESCRIPTION "A value representing the connection policies in effect in a node. A station sets the corresponding bit for each of the connection types that it rejects. The letter designations, X and Y, in the 'rejectX-Y' names have the following significance: X represents the PC-Type of the local PORT and Y represents the PC_Type of the adjacent PORT (PC_Neighbor). The evaluation of Connection- Policy (PC-Type, PC-Neighbor) is done to determine the setting of T- Val(3) in the PC-Signalling sequence (refer to ANSI 9.6.3). Note that Bit 15, (rejectM-M), is always set and cannot be cleared. The value is a sum. This value initially takes the value zero, then for each of the connection policies currently enforced on the node, 2 raised to a power is added to the sum. The powers are according to the following table: Policy Power rejectA-A 0 rejectA-B 1 rejectA-S 2 rejectA-M 3 rejectB-A 4 rejectB-B 5 rejectB-S 6 rejectB-M 7 rejectS-A 8 rejectS-B 9 rejectS-S 10 rejectS-M 11 rejectM-A 12 rejectM-B 13 rejectM-S 14 rejectM-M 15 " REFERENCE "ANSI { fddiSMT 27 }" ::= { fddimibSMTEntry 14 } fddimibSMTTNotify OBJECT-TYPE SYNTAX INTEGER (2..30) ACCESS read-write STATUS mandatory Case & Rijsinghani [Page 12] RFC 1512 FDDI MIB September 1993 DESCRIPTION "The timer, expressed in seconds, used in the Neighbor Notification protocol. It has a range of 2 seconds to 30 seconds, and its default value is 30 seconds (refer to ANSI SMT 8.2)." REFERENCE "ANSI { fddiSMT 29 }" ::= { fddimibSMTEntry 15 } fddimibSMTStatRptPolicy OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If true, indicates that the node will generate Status Reporting Frames for its implemented events and conditions. It has an initial value of true. This variable determines the value of the SR_Enable Flag (refer to ANSI SMT 8.3.2.1)." REFERENCE "ANSI { fddiSMT 30 }" ::= { fddimibSMTEntry 16 } fddimibSMTTraceMaxExpiration OBJECT-TYPE SYNTAX FddiTimeMilli ACCESS read-write STATUS mandatory DESCRIPTION "Reference Trace_Max (refer to ANSI SMT 9.4.4.2.2)." REFERENCE "ANSI { fddiSMT 31 }" ::= { fddimibSMTEntry 17 } fddimibSMTBypassPresent OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "A flag indicating if the station has a bypass on its AB port pair." REFERENCE "ANSI { fddiSMT 34 }" ::= { fddimibSMTEntry 18 } fddimibSMTECMState OBJECT-TYPE SYNTAX INTEGER { ec0(1), -- Out Case & Rijsinghani [Page 13] RFC 1512 FDDI MIB September 1993 ec1(2), -- In ec2(3), -- Trace ec3(4), -- Leave ec4(5), -- Path_Test ec5(6), -- Insert ec6(7), -- Check ec7(8) -- Deinsert } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the current state of the ECM state machine (refer to ANSI SMT 9.5.2)." REFERENCE "ANSI { fddiSMT 41 }" ::= { fddimibSMTEntry 19 } fddimibSMTCFState OBJECT-TYPE SYNTAX INTEGER { cf0(1), -- isolated cf1(2), -- local_a cf2(3), -- local_b cf3(4), -- local_ab cf4(5), -- local_s cf5(6), -- wrap_a cf6(7), -- wrap_b cf7(8), -- wrap_ab cf8(9), -- wrap_s cf9(10), -- c_wrap_a cf10(11), -- c_wrap_b cf11(12), -- c_wrap_s cf12(13) -- thru } ACCESS read-only STATUS mandatory DESCRIPTION "The attachment configuration for the station or concentrator (refer to ANSI SMT 9.7.2.2)." REFERENCE "ANSI { fddiSMT 42 }" ::= { fddimibSMTEntry 20 } fddimibSMTRemoteDisconnectFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "A flag indicating that the station was remotely Case & Rijsinghani [Page 14] RFC 1512 FDDI MIB September 1993 disconnected from the network as a result of receiving an fddiSMTAction, disconnect (refer to ANSI SMT 6.4.5.3) in a Parameter Management Frame. A station requires a Connect Action to rejoin and clear the flag (refer to ANSI SMT 6.4.5.2)." REFERENCE "ANSI { fddiSMT 44 }" ::= { fddimibSMTEntry 21 } fddimibSMTStationStatus OBJECT-TYPE SYNTAX INTEGER { concatenated(1), separated(2), thru(3) } ACCESS read-only STATUS mandatory DESCRIPTION "The current status of the primary and secondary paths within this station." REFERENCE "ANSI { fddiSMT 45 }" ::= { fddimibSMTEntry 22 } fddimibSMTPeerWrapFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable assumes the value of the PeerWrapFlag in CFM (refer to ANSI SMT 9.7.2.4.4)." REFERENCE "ANSI { fddiSMT 46 }" ::= { fddimibSMTEntry 23 } fddimibSMTTimeStamp OBJECT-TYPE SYNTAX FddiTimeMilli ACCESS read-only STATUS mandatory DESCRIPTION "This variable assumes the value of TimeStamp (refer to ANSI SMT 8.3.2.1)." REFERENCE "ANSI { fddiSMT 51 }" ::= { fddimibSMTEntry 24 } fddimibSMTTransitionTimeStamp OBJECT-TYPE SYNTAX FddiTimeMilli ACCESS read-only STATUS mandatory DESCRIPTION Case & Rijsinghani [Page 15] RFC 1512 FDDI MIB September 1993 "This variable assumes the value of TransitionTimeStamp (refer to ANSI SMT 8.3.2.1)." REFERENCE "ANSI { fddiSMT 52 }" ::= { fddimibSMTEntry 25 } fddimibSMTStationAction OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following connect(2), disconnect(3), path-Test(4), self-Test(5), disable-a(6), disable-b(7), disable-m(8) } ACCESS read-write STATUS mandatory DESCRIPTION "This object, when read, always returns a value of other(1). The behavior of setting this variable to each of the acceptable values is as follows: other(1): Results in an appropriate error. connect(2): Generates a Connect signal to ECM to begin a connection sequence. See ANSI Ref 9.4.2. disconnect(3): Generates a Disconnect signal to ECM. see ANSI Ref 9.4.2. path-Test(4): Initiates a station Path_Test. The Path_Test variable (see ANSI Ref 9.4.1) is set to 'Testing'. The results of this action are not specified in this standard. self-Test(5): Initiates a station Self_Test. The results of this action are not specified in this standard. disable-a(6): Causes a PC_Disable on the A port if the A port mode is peer. disable-b(7): Causes a PC_Disable on the B port if the B port mode is peer. disable-m(8): Causes a PC_Disable on all M ports. Attempts to set this object to all other values results in an appropriate error. The result of setting this variable to path-Test(4) or self- Case & Rijsinghani [Page 16] RFC 1512 FDDI MIB September 1993 Test(5) is implementation-specific." REFERENCE "ANSI { fddiSMT 60 }" ::= { fddimibSMTEntry 26 } -- the MAC group -- Implementation of the MAC Group is mandatory for all -- systems which implement manageable FDDI subsystems. fddimibMACNumber OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The total number of MAC implementations (across all SMTs) on this network management application entity. The value for this variable must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { fddimibMAC 1 } -- the MAC table fddimibMACTable OBJECT-TYPE SYNTAX SEQUENCE OF FddimibMACEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of MAC entries. The number of entries shall not exceed the value of fddimibMACNumber." ::= { fddimibMAC 2 } fddimibMACEntry OBJECT-TYPE SYNTAX FddimibMACEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A MAC entry containing information common to a given MAC." INDEX { fddimibMACSMTIndex, fddimibMACIndex } ::= { fddimibMACTable 1 } FddimibMACEntry ::= SEQUENCE { fddimibMACSMTIndex Case & Rijsinghani [Page 17] RFC 1512 FDDI MIB September 1993 INTEGER, fddimibMACIndex INTEGER, fddimibMACIfIndex INTEGER, fddimibMACFrameStatusFunctions INTEGER, fddimibMACTMaxCapability FddiTimeNano, fddimibMACTVXCapability FddiTimeNano, fddimibMACAvailablePaths INTEGER, fddimibMACCurrentPath INTEGER, fddimibMACUpstreamNbr FddiMACLongAddressType, fddimibMACDownstreamNbr FddiMACLongAddressType, fddimibMACOldUpstreamNbr FddiMACLongAddressType, fddimibMACOldDownstreamNbr FddiMACLongAddressType, fddimibMACDupAddressTest INTEGER, fddimibMACRequestedPaths INTEGER, fddimibMACDownstreamPORTType INTEGER, fddimibMACSMTAddress FddiMACLongAddressType, fddimibMACTReq FddiTimeNano, fddimibMACTNeg FddiTimeNano, fddimibMACTMax FddiTimeNano, fddimibMACTvxValue FddiTimeNano, fddimibMACFrameCts Counter, fddimibMACCopiedCts Counter, fddimibMACTransmitCts Counter, fddimibMACErrorCts Counter, fddimibMACLostCts Case & Rijsinghani [Page 18] RFC 1512 FDDI MIB September 1993 Counter, fddimibMACFrameErrorThreshold INTEGER, fddimibMACFrameErrorRatio INTEGER, fddimibMACRMTState INTEGER, fddimibMACDaFlag INTEGER, fddimibMACUnaDaFlag INTEGER, fddimibMACFrameErrorFlag INTEGER, fddimibMACMAUnitdataAvailable INTEGER, fddimibMACHardwarePresent INTEGER, fddimibMACMAUnitdataEnable INTEGER } fddimibMACSMTIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of the SMT index associated with this MAC." ::= { fddimibMACEntry 1 } fddimibMACIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Index variable for uniquely identifying the MAC object instances, which is the same as the corresponding resource index in SMT." REFERENCE "ANSI { fddiMAC 34 }" ::= { fddimibMACEntry 2 } fddimibMACIfIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION Case & Rijsinghani [Page 19] RFC 1512 FDDI MIB September 1993 "The value of the MIB-II ifIndex corresponding to this MAC. If none is applicable, 0 is returned." REFERENCE "MIB-II" ::= { fddimibMACEntry 3 } fddimibMACFrameStatusFunctions OBJECT-TYPE SYNTAX INTEGER (0..7) ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the MAC's optional Frame Status processing functions. The value is a sum. This value initially takes the value zero, then for each function present, 2 raised to a power is added to the sum. The powers are according to the following table: function Power fs-repeating 0 fs-setting 1 fs-clearing 2 " REFERENCE "ANSI { fddiMAC 11 }" ::= { fddimibMACEntry 4 } fddimibMACTMaxCapability OBJECT-TYPE SYNTAX FddiTimeNano ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the maximum time value of fddiMACTMax that this MAC can support." REFERENCE "ANSI { fddiMAC 13 }" ::= { fddimibMACEntry 5 } fddimibMACTVXCapability OBJECT-TYPE SYNTAX FddiTimeNano ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the maximum time value of fddiMACTvxValue that this MAC can support." REFERENCE "ANSI { fddiMAC 14 }" ::= { fddimibMACEntry 6 } Case & Rijsinghani [Page 20] RFC 1512 FDDI MIB September 1993 fddimibMACAvailablePaths OBJECT-TYPE SYNTAX INTEGER (0..7) ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the paths available for this MAC (refer to ANSI SMT 9.7.7). The value is a sum. This value initially takes the value zero, then for each type of PATH that this MAC has available, 2 raised to a power is added to the sum. The powers are according to the following table: Path Power Primary 0 Secondary 1 Local 2 " REFERENCE "ANSI { fddiMAC 22 }" ::= { fddimibMACEntry 7 } fddimibMACCurrentPath OBJECT-TYPE SYNTAX INTEGER { isolated(1), local(2), secondary(3), primary(4), concatenated(5), thru(6) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the Path into which this MAC is currently inserted (refer to ANSI 9.7.7)." REFERENCE "ANSI { fddiMAC 23 }" ::= { fddimibMACEntry 8 } fddimibMACUpstreamNbr OBJECT-TYPE SYNTAX FddiMACLongAddressType -- OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "The MAC's upstream neighbor's long individual MAC address. It has an initial value of the SMT- Unknown-MAC Address and is only modified as Case & Rijsinghani [Page 21] RFC 1512 FDDI MIB September 1993 specified by the Neighbor Information Frame protocol (refer to ANSI SMT 7.2.1 and 8.2)." REFERENCE "ANSI { fddiMAC 24 }" ::= { fddimibMACEntry 9 } fddimibMACDownstreamNbr OBJECT-TYPE SYNTAX FddiMACLongAddressType -- OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "The MAC's downstream neighbor's long individual MAC address. It has an initial value of the SMT- Unknown-MAC Address and is only modified as specified by the Neighbor Information Frame protocol (refer to ANSI SMT 7.2.1 and 8.2)." REFERENCE "ANSI { fddiMAC 25 }" ::= { fddimibMACEntry 10 } fddimibMACOldUpstreamNbr OBJECT-TYPE SYNTAX FddiMACLongAddressType -- OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "The previous value of the MAC's upstream neighbor's long individual MAC address. It has an initial value of the SMT-Unknown- MAC Address and is only modified as specified by the Neighbor Information Frame protocol (refer to ANSI SMT 7.2.1 and 8.2)." REFERENCE "ANSI { fddiMAC 26 }" ::= { fddimibMACEntry 11 } fddimibMACOldDownstreamNbr OBJECT-TYPE SYNTAX FddiMACLongAddressType -- OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "The previous value of the MAC's downstream neighbor's long individual MAC address. It has an initial value of the SMT- Unknown-MAC Address and is only modified as specified by the Neighbor Information Frame protocol (refer to ANSI SMT 7.2.1 and 8.2)." REFERENCE "ANSI { fddiMAC 27 }" Case & Rijsinghani [Page 22] RFC 1512 FDDI MIB September 1993 ::= { fddimibMACEntry 12 } fddimibMACDupAddressTest OBJECT-TYPE SYNTAX INTEGER { none(1), pass(2), fail(3) } ACCESS read-only STATUS mandatory DESCRIPTION "The Duplicate Address Test flag, Dup_Addr_Test (refer to ANSI 8.2)." REFERENCE "ANSI { fddiMAC 29 }" ::= { fddimibMACEntry 13 } fddimibMACRequestedPaths OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-write STATUS mandatory DESCRIPTION "List of permitted Paths which specifies the Path(s) into which the MAC may be inserted (refer to ansi SMT 9.7). The value is a sum which represents the individual paths that are desired. This value initially takes the value zero, then for each type of PATH that this node is, 2 raised to a power is added to the sum. The powers are according to the following table: Path Power local 0 secondary-alternate 1 primary-alternate 2 concatenated-alternate 3 secondary-preferred 4 primary-preferred 5 concatenated-preferred 6 thru 7 " REFERENCE "ANSI { fddiMAC 32 }" ::= { fddimibMACEntry 14 } fddimibMACDownstreamPORTType OBJECT-TYPE SYNTAX INTEGER { a(1), b(2), s(3), m(4), none(5) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the PC-Type of the first port that is Case & Rijsinghani [Page 23] RFC 1512 FDDI MIB September 1993 downstream of this MAC (the exit port)." REFERENCE "ANSI { fddiMAC 33 }" ::= { fddimibMACEntry 15 } fddimibMACSMTAddress OBJECT-TYPE SYNTAX FddiMACLongAddressType -- OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "The 48-bit individual address of the MAC used for SMT frames." REFERENCE "ANSI { fddiMAC 41 }" ::= { fddimibMACEntry 16 } fddimibMACTReq OBJECT-TYPE SYNTAX FddiTimeNano ACCESS read-only STATUS mandatory DESCRIPTION "This variable is the T_Req_value passed to the MAC. Without having detected a duplicate, the time value of this variable shall assume the maximum supported time value which is less than or equal to the time value of fddiPATHMaxT-Req. When a MAC has an address detected as a duplicate, it may use a time value for this variable greater than the time value of fddiPATHTMaxLowerBound. A station shall cause claim when the new T_Req may cause the value of T_Neg to change in the claim process, (i.e., time value new T_Req < T_Neg, or old T_Req = T_Neg)." REFERENCE "ANSI { fddiMAC 51 }" ::= { fddimibMACEntry 17 } fddimibMACTNeg OBJECT-TYPE SYNTAX FddiTimeNano ACCESS read-only STATUS mandatory DESCRIPTION "It is reported as a FddiTimeNano number." REFERENCE "ANSI { fddiMAC 52 }" ::= { fddimibMACEntry 18 } fddimibMACTMax OBJECT-TYPE Case & Rijsinghani [Page 24] RFC 1512 FDDI MIB September 1993 SYNTAX FddiTimeNano ACCESS read-only STATUS mandatory DESCRIPTION "This variable is the T_Max_value passed to the MAC. The time value of this variable shall assume the minimum suported time value which is greater than or equal to the time value of fddiPATHT- MaxLowerBound" REFERENCE "ANSI { fddiMAC 53 }" ::= { fddimibMACEntry 19 } fddimibMACTvxValue OBJECT-TYPE SYNTAX FddiTimeNano ACCESS read-only STATUS mandatory DESCRIPTION "This variable is the TVX_value passed to the MAC. The time value of this variable shall assume the minimum suported time value which is greater than or equal to the time value of fddiPATHTVXLowerBound." REFERENCE "ANSI { fddiMAC 54 }" ::= { fddimibMACEntry 20 } fddimibMACFrameCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of frames received by this MAC (refer to ANSI MAC 7.5.1)." REFERENCE "ANSI { fddiMAC 71 }" ::= { fddimibMACEntry 21 } fddimibMACCopiedCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count that should as closely as possible match the number of frames addressed to (A bit set) and successfully copied into the station's receive buffers (C bit set) by this MAC (refer to ANSI MAC 7.5). Note that this count does not include MAC Case & Rijsinghani [Page 25] RFC 1512 FDDI MIB September 1993 frames." REFERENCE "ANSI { fddiMAC 72 }" ::= { fddimibMACEntry 22 } fddimibMACTransmitCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count that should as closely as possible match the number of frames transmitted by this MAC (refer to ANSI MAC 7.5). Note that this count does not include MAC frames." REFERENCE "ANSI { fddiMAC 73 }" ::= { fddimibMACEntry 23 } fddimibMACErrorCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of frames that were detected in error by this MAC that had not been detected in error by another MAC (refer to ANSI MAC 7.5.2)." REFERENCE "ANSI { fddiMAC 81 }" ::= { fddimibMACEntry 24 } fddimibMACLostCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of instances that this MAC detected a format error during frame reception such that the frame was stripped (refer to ANSI MAC 7.5.3)." REFERENCE "ANSI { fddiMAC 82 }" ::= { fddimibMACEntry 25 } fddimibMACFrameErrorThreshold OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory Case & Rijsinghani [Page 26] RFC 1512 FDDI MIB September 1993 DESCRIPTION "A threshold for determining when a MAC Condition report (see ANSI 8.3.1.1) shall be generated. Stations not supporting variable thresholds shall have a value of 0 and a range of (0..0)." REFERENCE "ANSI { fddiMAC 95 }" ::= { fddimibMACEntry 26 } fddimibMACFrameErrorRatio OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This variable is the value of the ratio, ((delta fddiMACLostCts + delta fddiMACErrorCts) / (delta fddiMACFrameCts + delta fddiMACLostCts )) * 2**16 " REFERENCE "ANSI { fddiMAC 96 }" ::= { fddimibMACEntry 27 } fddimibMACRMTState OBJECT-TYPE SYNTAX INTEGER { rm0(1), -- Isolated rm1(2), -- Non_Op rm2(3), -- Ring_Op rm3(4), -- Detect rm4(5), -- Non_Op_Dup rm5(6), -- Ring_Op_Dup rm6(7), -- Directed rm7(8) -- Trace } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the current state of the RMT State Machine (refer to ANSI 10.3.2)." REFERENCE "ANSI { fddiMAC 111 }" ::= { fddimibMACEntry 28 } fddimibMACDaFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION Case & Rijsinghani [Page 27] RFC 1512 FDDI MIB September 1993 "The RMT flag Duplicate Address Flag, DA_Flag (refer to ANSI 10.2.1.2)." REFERENCE "ANSI { fddiMAC 112 }" ::= { fddimibMACEntry 29 } fddimibMACUnaDaFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "A flag, UNDA_Flag (refer to ANSI 8.2.2.1), set when the upstream neighbor reports a duplicate address condition. Cleared when the condition clears." REFERENCE "ANSI { fddiMAC 113 }" ::= { fddimibMACEntry 30 } fddimibMACFrameErrorFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the MAC Frame Error Condition is present when set. Cleared when the condition clears and on station initialization." REFERENCE "ANSI { fddiMAC 114 }" ::= { fddimibMACEntry 31 } fddimibMACMAUnitdataAvailable OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable shall take on the value of the MAC_Avail flag defined in RMT." REFERENCE "ANSI { fddiMAC 116 }" ::= { fddimibMACEntry 32 } fddimibMACHardwarePresent OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates the presence of Case & Rijsinghani [Page 28] RFC 1512 FDDI MIB September 1993 underlying hardware support for this MAC object. If the value of this object is false(2), the reporting of the objects in this entry may be handled in an implementation-specific manner." REFERENCE "ANSI { fddiMAC 117 }" ::= { fddimibMACEntry 33 } fddimibMACMAUnitdataEnable OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-write STATUS mandatory DESCRIPTION "This variable determines the value of the MA_UNITDATA_Enable flag in RMT. The default and initial value of this flag is true(1)." REFERENCE "ANSI { fddiMAC 118 }" ::= { fddimibMACEntry 34 } -- the Enhanced MAC Counters group -- Implementation of this Group is optional, but systems -- claiming support must implement all variables in this -- group -- the MAC Counters table fddimibMACCountersTable OBJECT-TYPE SYNTAX SEQUENCE OF FddimibMACCountersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of MAC Counters entries. The number of entries shall not exceed the value of fddimibMACNumber." ::= { fddimibMACCounters 1 } fddimibMACCountersEntry OBJECT-TYPE SYNTAX FddimibMACCountersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A MAC Counters entry containing information common to a given MAC." INDEX { fddimibMACSMTIndex, fddimibMACIndex } ::= { fddimibMACCountersTable 1 } Case & Rijsinghani [Page 29] RFC 1512 FDDI MIB September 1993 FddimibMACCountersEntry ::= SEQUENCE { fddimibMACTokenCts Counter, fddimibMACTvxExpiredCts Counter, fddimibMACNotCopiedCts Counter, fddimibMACLateCts Counter, fddimibMACRingOpCts Counter, fddimibMACNotCopiedRatio INTEGER, fddimibMACNotCopiedFlag INTEGER, fddimibMACNotCopiedThreshold INTEGER } fddimibMACTokenCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count that should as closely as possible match the number of times the station has received a token (total of non-restricted and restricted) on this MAC (see ANSI MAC 7.4). This count is valuable for determination of network load." REFERENCE "ANSI { fddiMAC 74 }" ::= { fddimibMACCountersEntry 1 } fddimibMACTvxExpiredCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count that should as closely as possible match the number of times that TVX has expired." REFERENCE "ANSI { fddiMAC 83 }" ::= { fddimibMACCountersEntry 2 } fddimibMACNotCopiedCts OBJECT-TYPE SYNTAX Counter ACCESS read-only Case & Rijsinghani [Page 30] RFC 1512 FDDI MIB September 1993 STATUS mandatory DESCRIPTION "A count that should as closely as possible match the number of frames that were addressed to this MAC but were not copied into its receive buffers (see ANSI MAC 7.5). For example, this might occur due to local buffer congestion. Because of implementation considerations, this count may not match the actual number of frames not copied. It is not a requirement that this count be exact. Note that this count does not include MAC frames." REFERENCE "ANSI { fddiMAC 84 }" ::= { fddimibMACCountersEntry 3 } fddimibMACLateCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count that should as closely as possible match the number of TRT expirations since this MAC was reset or a token was received (refer to ANSI MAC 7.4.5)." REFERENCE "ANSI { fddiMAC 85 }" ::= { fddimibMACCountersEntry 4 } fddimibMACRingOpCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of the number of times the ring has entered the 'Ring_Operational' state from the 'Ring Not Operational' state. This count is updated when a SM_MA_STATUS.Indication of a change in the Ring_Operational status occurs (refer to ANSI 6.1.4). Because of implementation considerations, this count may be less than the actual RingOp_Ct. It is not a requirement that this count be exact." REFERENCE "ANSI { fddiMAC 86 }" ::= { fddimibMACCountersEntry 5 } fddimibMACNotCopiedRatio OBJECT-TYPE SYNTAX INTEGER (0..65535) Case & Rijsinghani [Page 31] RFC 1512 FDDI MIB September 1993 ACCESS read-only STATUS mandatory DESCRIPTION "This variable is the value of the ratio: (delta fddiMACNotCopiedCts / (delta fddiMACCopiedCts + delta fddiMACNotCopiedCts )) * 2**16 " REFERENCE "ANSI { fddiMAC 105 }" ::= { fddimibMACCountersEntry 6 } fddimibMACNotCopiedFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates that the Not Copied condition is present when read as true(1). Set to false(2) when the condition clears and on station initialization." REFERENCE "ANSI { fddiMAC 115 }" ::= { fddimibMACCountersEntry 7 } fddimibMACNotCopiedThreshold OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "A threshold for determining when a MAC condition report shall be generated. Stations not supporting variable thresholds shall have a value of 0 and a range of (0..0)." REFERENCE "ANSI { fddiMAC 103 }" ::= { fddimibMACCountersEntry 8 } -- the PATH group -- Implementation of the PATH group is mandatory for all -- systems which implement manageable FDDI subsystems. fddimibPATHNumber OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION Case & Rijsinghani [Page 32] RFC 1512 FDDI MIB September 1993 "The total number of PATHs possible (across all SMTs) on this network management application entity. The value for this variable must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { fddimibPATH 1 } -- the PATH table fddimibPATHTable OBJECT-TYPE SYNTAX SEQUENCE OF FddimibPATHEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of PATH entries. The number of entries shall not exceed the value of fddimibPATHNumber." ::= { fddimibPATH 2 } fddimibPATHEntry OBJECT-TYPE SYNTAX FddimibPATHEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A PATH entry containing information common to a given PATH." INDEX { fddimibPATHSMTIndex, fddimibPATHIndex } ::= { fddimibPATHTable 1 } FddimibPATHEntry ::= SEQUENCE { fddimibPATHSMTIndex INTEGER, fddimibPATHIndex INTEGER, fddimibPATHTVXLowerBound FddiTimeNano, fddimibPATHTMaxLowerBound FddiTimeNano, fddimibPATHMaxTReq FddiTimeNano } fddimibPATHSMTIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory Case & Rijsinghani [Page 33] RFC 1512 FDDI MIB September 1993 DESCRIPTION "The value of the SMT index associated with this PATH." ::= { fddimibPATHEntry 1 } fddimibPATHIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Index variable for uniquely identifying the primary, secondary and local PATH object instances. Local PATH object instances are represented with integer values 3 to 255." REFERENCE "ANSI { fddiPATH 11 }" ::= { fddimibPATHEntry 2 } fddimibPATHTVXLowerBound OBJECT-TYPE SYNTAX FddiTimeNano ACCESS read-write STATUS mandatory DESCRIPTION "Specifies the minimum time value of fddiMACTvxValue that shall be used by any MAC that is configured in this path. The operational value of fddiMACTvxValue is managed by settting this variable. This variable has the time value range of: 0 < fddimibPATHTVXLowerBound < fddimibPATHMaxTReq Changes to this variable shall either satisfy the time value relationship: fddimibPATHTVXLowerBound <= fddimibMACTVXCapability of each of the MACs currently on the path, or be considered out of range. The initial value of fddimibPATHTVXLowerBound shall be 2500 nsec (2.5 ms)." REFERENCE "ANSI { fddiPATH 21 }" ::= { fddimibPATHEntry 3 } fddimibPATHTMaxLowerBound OBJECT-TYPE SYNTAX FddiTimeNano Case & Rijsinghani [Page 34] RFC 1512 FDDI MIB September 1993 ACCESS read-write STATUS mandatory DESCRIPTION "Specifies the minimum time value of fddiMACTMax that shall be used by any MAC that is configured in this path. The operational value of fddiMACTMax is managed by setting this variable. This variable has the time value range of: fddimibPATHMaxTReq <= fddimibPATHTMaxLowerBound and an absolute time value range of: 10000nsec (10 msec) <= fddimibPATHTMaxLowerBound Changes to this variable shall either satisfy the time value relationship: fddimibPATHTMaxLowerBound < fddimibMACTMaxCapability of each of the MACs currently on the path, or be considered out of range. The initial value of fddimibPATHTMaxLowerBound shall be 165000 nsec (165 msec)." REFERENCE "ANSI { fddiPATH 22 }" ::= { fddimibPATHEntry 4 } fddimibPATHMaxTReq OBJECT-TYPE SYNTAX FddiTimeNano ACCESS read-write STATUS mandatory DESCRIPTION "Specifies the maximum time value of fddiMACT-Req that shall be used by any MAC that is configured in this path. The operational value of fddiMACT- Req is managed by setting this variable. This variable has the time value range of: fddimibPATHTVXLowerBound < fddimibPATHMaxTReq <= fddimibPATHTMaxLowerBound. The default value of fddimibPATHMaxTReq is 165000 nsec (165 msec)." REFERENCE "ANSI { fddiPATH 23 }" ::= { fddimibPATHEntry 5 } Case & Rijsinghani [Page 35] RFC 1512 FDDI MIB September 1993 -- the PATH Configuration table fddimibPATHConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF FddimibPATHConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table of Path configuration entries. This table lists all the resources that may be in this Path." REFERENCE "ANSI { fddiPATH 18 }" ::= { fddimibPATH 3 } fddimibPATHConfigEntry OBJECT-TYPE SYNTAX FddimibPATHConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of objects containing information for a given PATH Configuration entry." INDEX { fddimibPATHConfigSMTIndex, fddimibPATHConfigPATHIndex, fddimibPATHConfigTokenOrder } ::= { fddimibPATHConfigTable 1 } FddimibPATHConfigEntry ::= SEQUENCE { fddimibPATHConfigSMTIndex INTEGER, fddimibPATHConfigPATHIndex INTEGER, fddimibPATHConfigTokenOrder INTEGER, fddimibPATHConfigResourceType INTEGER, fddimibPATHConfigResourceIndex INTEGER, fddimibPATHConfigCurrentPath INTEGER } fddimibPATHConfigSMTIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of the SMT index associated with this Case & Rijsinghani [Page 36] RFC 1512 FDDI MIB September 1993 configuration entry." ::= { fddimibPATHConfigEntry 1 } fddimibPATHConfigPATHIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of the PATH resource index associated with this configuration entry." ::= { fddimibPATHConfigEntry 2 } fddimibPATHConfigTokenOrder OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "An object associated with Token order for this entry. Thus if the token passes resources a, b, c and d, in that order, then the value of this object for these resources would be 1, 2, 3 and 4 respectively." ::= { fddimibPATHConfigEntry 3 } fddimibPATHConfigResourceType OBJECT-TYPE SYNTAX INTEGER { mac(2), port(4) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of resource associated with this configuration entry." ::= { fddimibPATHConfigEntry 4 } fddimibPATHConfigResourceIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of the SMT resource index used to refer to the instance of this MAC or Port resource." ::= { fddimibPATHConfigEntry 5 } fddimibPATHConfigCurrentPath OBJECT-TYPE SYNTAX INTEGER { isolated(1), local(2), secondary(3), primary(4), concatenated(5), thru(6) } ACCESS read-only Case & Rijsinghani [Page 37] RFC 1512 FDDI MIB September 1993 STATUS mandatory DESCRIPTION "The current insertion status for this resource on this Path." ::= { fddimibPATHConfigEntry 6 } -- the PORT group -- Implementation of the PORT group is mandatory for all -- systems which implement manageable FDDI subsystems. fddimibPORTNumber OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The total number of PORT implementations (across all SMTs) on this network management application entity. The value for this variable must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { fddimibPORT 1 } -- the PORT table fddimibPORTTable OBJECT-TYPE SYNTAX SEQUENCE OF FddimibPORTEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of PORT entries. The number of entries shall not exceed the value of fddimibPORTNumber." ::= { fddimibPORT 2 } fddimibPORTEntry OBJECT-TYPE SYNTAX FddimibPORTEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A PORT entry containing information common to a given PORT." INDEX { fddimibPORTSMTIndex, fddimibPORTIndex } ::= { fddimibPORTTable 1 } FddimibPORTEntry ::= SEQUENCE { Case & Rijsinghani [Page 38] RFC 1512 FDDI MIB September 1993 fddimibPORTSMTIndex INTEGER, fddimibPORTIndex INTEGER, fddimibPORTMyType INTEGER, fddimibPORTNeighborType INTEGER, fddimibPORTConnectionPolicies INTEGER, fddimibPORTMACIndicated INTEGER, fddimibPORTCurrentPath INTEGER, fddimibPORTRequestedPaths OCTET STRING, fddimibPORTMACPlacement FddiResourceId, fddimibPORTAvailablePaths INTEGER, fddimibPORTPMDClass INTEGER, fddimibPORTConnectionCapabilities INTEGER, fddimibPORTBSFlag INTEGER, fddimibPORTLCTFailCts Counter, fddimibPORTLerEstimate INTEGER, fddimibPORTLemRejectCts Counter, fddimibPORTLemCts Counter, fddimibPORTLerCutoff INTEGER, fddimibPORTLerAlarm INTEGER, fddimibPORTConnectState INTEGER, fddimibPORTPCMState INTEGER, fddimibPORTPCWithhold INTEGER, fddimibPORTLerFlag INTEGER, fddimibPORTHardwarePresent INTEGER, Case & Rijsinghani [Page 39] RFC 1512 FDDI MIB September 1993 fddimibPORTAction INTEGER } fddimibPORTSMTIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of the SMT index associated with this PORT." ::= { fddimibPORTEntry 1 } fddimibPORTIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each PORT within a given SMT, which is the same as the corresponding resource index in SMT. The value for each PORT must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." REFERENCE "ANSI { fddiPORT 29 }" ::= { fddimibPORTEntry 2 } fddimibPORTMyType OBJECT-TYPE SYNTAX INTEGER { a(1), b(2), s(3), m(4), none(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of the PORT's PC_Type (refer to ANSI 9.4.1, and 9.6.3.2)." REFERENCE "ANSI { fddiPORT 12 }" ::= { fddimibPORTEntry 3 } fddimibPORTNeighborType OBJECT-TYPE SYNTAX INTEGER { a(1), b(2), s(3), m(4), none(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of the remote PORT as determined in PCM. This variable has an initial value of none, and is only modified in PC_RCode(3)_Actions (refer to ANSI SMT 9.6.3.2)." Case & Rijsinghani [Page 40] RFC 1512 FDDI MIB September 1993 REFERENCE "ANSI { fddiPORT 13 }" ::= { fddimibPORTEntry 4 } fddimibPORTConnectionPolicies OBJECT-TYPE SYNTAX INTEGER (0..3) ACCESS read-write STATUS mandatory DESCRIPTION "A value representing the PORT's connection policies desired in the node. The value of pc- mac-lct is a term used in the PC_MAC_LCT Flag (see 9.4.3.2). The value of pc-mac-loop is a term used in the PC_MAC_Loop Flag. The value is a sum. This value initially takes the value zero, then for each PORT policy, 2 raised to a power is added to the sum. The powers are according to the following table: Policy Power pc-mac-lct 0 pc-mac-loop 1 " REFERENCE "ANSI { fddiPORT 14 }" ::= { fddimibPORTEntry 5 } fddimibPORTMACIndicated OBJECT-TYPE SYNTAX INTEGER { tVal9FalseRVal9False(1), tVal9FalseRVal9True(2), tVal9TrueRVal9False(3), tVal9TrueRVal9True(4) } ACCESS read-only STATUS mandatory DESCRIPTION "The indications (T_Val(9), R_Val(9)) in PC- Signalling, of the intent to place a MAC in the output token path to a PORT (refer to ANSI SMT 9.6.3.2.)." REFERENCE "ANSI { fddiPORT 15 }" ::= { fddimibPORTEntry 6 } fddimibPORTCurrentPath OBJECT-TYPE SYNTAX INTEGER { ce0(1), -- isolated Case & Rijsinghani [Page 41] RFC 1512 FDDI MIB September 1993 ce1(2), -- local ce2(3), -- secondary ce3(4), -- primary ce4(5), -- concatenated ce5(6) -- thru } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the Path(s) into which this PORT is currently inserted." REFERENCE "ANSI { fddiPORT 16 }" ::= { fddimibPORTEntry 7 } fddimibPORTRequestedPaths OBJECT-TYPE SYNTAX OCTET STRING (SIZE (3)) ACCESS read-write STATUS mandatory DESCRIPTION "This variable is a list of permitted Paths where each list element defines the Port's permitted Paths. The first octet corresponds to 'none', the second octet to 'tree', and the third octet to 'peer'." REFERENCE "ANSI { fddiPORT 17 }" ::= { fddimibPORTEntry 8 } fddimibPORTMACPlacement OBJECT-TYPE SYNTAX FddiResourceId -- INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the MAC, if any, whose transmit path exits the station via this PORT. The value shall be zero if there is no MAC associated with the PORT. Otherwise, the MACIndex of the MAC will be the value of the variable." REFERENCE "ANSI { fddiPORT 18 }" ::= { fddimibPORTEntry 9 } fddimibPORTAvailablePaths OBJECT-TYPE SYNTAX INTEGER (0..7) ACCESS read-only STATUS mandatory DESCRIPTION Case & Rijsinghani [Page 42] RFC 1512 FDDI MIB September 1993 "Indicates the Paths which are available to this Port. In the absence of faults, the A and B Ports will always have both the Primary and Secondary Paths available. The value is a sum. This value initially takes the value zero, then for each type of PATH that this port has available, 2 raised to a power is added to the sum. The powers are according to the following table: Path Power Primary 0 Secondary 1 Local 2 " REFERENCE "ANSI { fddiPORT 19 }" ::= { fddimibPORTEntry 10 } fddimibPORTPMDClass OBJECT-TYPE SYNTAX INTEGER { multimode(1), single-mode1(2), single-mode2(3), sonet(4), low-cost-fiber(5), twisted-pair(6), unknown(7), unspecified(8) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates the type of PMD entity associated with this port." REFERENCE "ANSI { fddiPORT 22 }" ::= { fddimibPORTEntry 11 } fddimibPORTConnectionCapabilities OBJECT-TYPE SYNTAX INTEGER (0..3) ACCESS read-only STATUS mandatory DESCRIPTION "A value that indicates the connection capabilities of the port. The pc-mac-lct bit indicates that the station has the capability of setting the PC_MAC_LCT Flag. The pc-mac-loop bit Case & Rijsinghani [Page 43] RFC 1512 FDDI MIB September 1993 indicates that the station has the capability of setting the PC_MAC_Loop Flag (refer to ANSI 9.4.3.2). The value is a sum. This value initially takes the value zero, then for each capability that this port has, 2 raised to a power is added to the sum. The powers are according to the following table: capability Power pc-mac-lct 0 pc-mac-loop 1 " REFERENCE "ANSI { fddiPORT 23 }" ::= { fddimibPORTEntry 12 } fddimibPORTBSFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable assumes the value of the BS_Flag (refer to ANSI SMT 9.4.3.3)." REFERENCE "ANSI { fddiPORT 33 }" ::= { fddimibPORTEntry 13 } fddimibPORTLCTFailCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of the consecutive times the link confidence test (LCT) has failed during connection management (refer to ANSI 9.4.1)." REFERENCE "ANSI { fddiPORT 42 }" ::= { fddimibPORTEntry 14 } fddimibPORTLerEstimate OBJECT-TYPE SYNTAX INTEGER (4..15) ACCESS read-only STATUS mandatory DESCRIPTION "A long term average link error rate. It ranges from 10**-4 to 10**-15 and is reported as the absolute value of the base 10 logarithm (refer to ANSI SMT 9.4.7.5.)." Case & Rijsinghani [Page 44] RFC 1512 FDDI MIB September 1993 REFERENCE "ANSI { fddiPORT 51 }" ::= { fddimibPORTEntry 15 } fddimibPORTLemRejectCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A link error monitoring count of the times that a link has been rejected." REFERENCE "ANSI { fddiPORT 52 }" ::= { fddimibPORTEntry 16 } fddimibPORTLemCts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The aggregate link error monitor error count, set to zero only on station initialization." REFERENCE "ANSI { fddiPORT 53 }" ::= { fddimibPORTEntry 17 } fddimibPORTLerCutoff OBJECT-TYPE SYNTAX INTEGER (4..15) ACCESS read-write STATUS mandatory DESCRIPTION "The link error rate estimate at which a link connection will be broken. It ranges from 10**-4 to 10**-15 and is reported as the absolute value of the base 10 logarithm (default of 7)." REFERENCE "ANSI { fddiPORT 58 }" ::= { fddimibPORTEntry 18 } fddimibPORTLerAlarm OBJECT-TYPE SYNTAX INTEGER (4..15) ACCESS read-write STATUS mandatory DESCRIPTION "The link error rate estimate at which a link connection will generate an alarm. It ranges from 10**-4 to 10**-15 and is reported as the absolute value of the base 10 logarithm of the estimate Case & Rijsinghani [Page 45] RFC 1512 FDDI MIB September 1993 (default of 8)." REFERENCE "ANSI { fddiPORT 59 }" ::= { fddimibPORTEntry 19 } fddimibPORTConnectState OBJECT-TYPE SYNTAX INTEGER { disabled(1), connecting(2), standby(3), active(4) } ACCESS read-only STATUS mandatory DESCRIPTION "An indication of the connect state of this PORT and is equal to the value of Connect_State (refer to ANSI 9.4.1)" REFERENCE "ANSI { fddiPORT 61 }" ::= { fddimibPORTEntry 20 } fddimibPORTPCMState OBJECT-TYPE SYNTAX INTEGER { pc0(1), -- Off pc1(2), -- Break pc2(3), -- Trace pc3(4), -- Connect pc4(5), -- Next pc5(6), -- Signal pc6(7), -- Join pc7(8), -- Verify pc8(9), -- Active pc9(10) -- Maint } ACCESS read-only STATUS mandatory DESCRIPTION "The state of this Port's PCM state machine refer to ANSI SMT 9.6.2)." REFERENCE "ANSI { fddiPORT 62 }" ::= { fddimibPORTEntry 21 } fddimibPORTPCWithhold OBJECT-TYPE SYNTAX INTEGER { none(1), m-m(2), Case & Rijsinghani [Page 46] RFC 1512 FDDI MIB September 1993 otherincompatible(3), pathnotavailable(4) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of PC_Withhold (refer to ANSI SMT 9.4.1)." REFERENCE "ANSI { fddiPORT 63 }" ::= { fddimibPORTEntry 22 } fddimibPORTLerFlag OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The condition becomes active when the value of fddiPORTLerEstimate is less than or equal to fddiPORTLerAlarm. This will be reported with the Status Report Frames (SRF) (refer to ANSI SMT 7.2.7 and 8.3)." REFERENCE "ANSI { fddiPORT 64 }" ::= { fddimibPORTEntry 23 } fddimibPORTHardwarePresent OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates the presence of underlying hardware support for this Port object. If the value of this object is false(2), the reporting of the objects in this entry may be handled in an implementation-specific manner." REFERENCE "ANSI { fddiPORT 65 }" ::= { fddimibPORTEntry 24 } fddimibPORTAction OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following maintPORT(2), enablePORT(3), disablePORT(4), startPORT(5), stopPORT(6) Case & Rijsinghani [Page 47] RFC 1512 FDDI MIB September 1993 } ACCESS read-write STATUS mandatory DESCRIPTION "Causes a Control signal to be generated with a control_action of 'Signal' and the 'variable' parameter set with the appropriate value (i.e., PC_Maint, PC_Enable, PC_Disable, PC_Start, or PC_Stop) (refer to ANSI 9.4.2)." REFERENCE "ANSI { fddiPORT 70 }" ::= { fddimibPORTEntry 25 } END 5. Acknowledgements This document was produced by the IETF FDDI MIB working group: Hossein Alaee, 3Com Corporation Haggar Alsaleh, Bell Northern Research William Anderson, Mitre Corporation Alan Apt, Addison-Wesley Mary Artibee, Silicon Graphics Karen Auerbach, Epilogue Technologies Doug Bagnall, Apollo/Hewlett Packard Chet Birger, Coral Network Corporation Pablo Brenner, Fibronics Howard Brown, Cabletron Jack Brown, US Army Computer Engineering Center Eric Brunner Jeff Case, The University of Tennessee Tammy Chan, Fibercom Asheem Chandna, AT&T Cho Y. Chang, Apollo/Hewlett Packard Chris Chiotasso, Fibronics Paul Ciarfella, Digital Equipment Corporation John Cook, Chipcom Don Coolidge, Silicon Graphics Burt Cyr, Unisys James R. Davin, Massachusetts Institute of Technology Nabil Damouny Nadya El-Afandi, Network Systems Corporation Hunaid Engineer, Cray Research Jeff Fitzgerald, Fibercom Richard Fox, Synoptics Stan Froyd, ACC Case & Rijsinghani [Page 48] RFC 1512 FDDI MIB September 1993 Debbie Futcher, U.S. Naval Surface Warfare Center Joseph Golio, Cray Research Jeremy Greene, Coral Peter Hayden, Digital Equipment Corporation Scott Hiles, U.S. Naval Surface Warfare Center Greg Jones, Data General Satish Joshi, SynOptics Communications Jayant Kadambi, AT&T Bell Labs Joanna Karwowska, Data General Frank Kastenholz, Interlan Jim Kinder, Fibercom Christopher Kolb, PSI Cheryl Krupczak, NCR Peter Lin, Vitalink Then Liu John R. LoVerso, Concurrent Computer Corporation Ron Mackey, Distributed Systems International, Inc. Gary Malkin, Proteon Bruce McClure, Synernetics Keith McCloghrie, Hughes Lan Systems Donna McMaster, SynOptics John O'Hara, Massachusetts Institute of Technology Luc Pariseau, Digital Equipment Corporation Dave Perkins, SynOptics Communications James E. Reeves, SynOptics Communications Jim Reinstedler, Ungermann-Bass Radhi Renous, Fibronics Sal Ricci, AT&T/NCR Anil Rijsinghani, Digital Equipment Corporation Bob Rolla, Synernetics Nelson Ronkin, Synernetics Marshall T. Rose, Performance Systems International, Inc. Milt Roselinsky, CMC Jon Saperia, Digital Equipment Corporation Greg Satz, cisco Systems Steven Senum, Network Systems Corporation Jim Sheridan, IBM Corporation Jeffrey Schiller, MIT Dror Shindelman, Fibronics Mark Sleeper, Sparta Lou Steinberg, IBM Corporation Larry Stefani, Digital Equipment Corporation Mary Jane Strohl, Apollo/Hewlett Packard Sally Tarquinio, Mitre Corporation Kaj Tesink, Bellcore Ian Thomas, Chipcom Dean Throop, Data General Bill Townsend, Xylogics Case & Rijsinghani [Page 49] RFC 1512 FDDI MIB September 1993 Ahmet H. Tuncay, SynOptics Communications Mike Turico, Motorola Chris VandenBerg, ACC Sudhanshu Verma, Hewlett Packard Joe Vermeulen, UNISYS David Waiteman, BBN Bert Williams, Synernetics Mark Wood, Distributed Systems International, Inc. Y. C. Yang Denis Yaro, Sun Microsystems Jeff Young, Cray Research The author gratefully acknowledges the labors of Judi Talley and David Reid of SNMP Research, Inc. for their editorial assistance in the preparation of this document. 6. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] Case, J., "FDDI Management Information Base", RFC 1285, SNMP Research, Incorporated, January 1992. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [5] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [6] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. Case & Rijsinghani [Page 50] RFC 1512 FDDI MIB September 1993 [8] American National Standards Institute, FDDI Station Management (SMT), Draft Proposed American National Standard, American National Standards Institute, X3T9.5/84-49 REV 7.3. 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Jeffrey D. Case The University of Tennessee Department of Computer Science 107 Ayres Hall Knoxville, Tennessee 37996 and SNMP Research, Incorporated 3001 Kimberlin Heights Road Knoxville, Tennessee 37920 Phone: (615) 974-5067 or (615) 573-1434 EMail: case@CS.UTK.EDU Anil Rijsinghani Digital Equipment Corporation 295 Foster Street Littleton, MA 01460-1123 Phone: (508) 952-3520 EMail: anil@levers.enet.dec.com Case & Rijsinghani [Page 51] snmp-mibs-downloader-1.1/mibrfcs/rfc1513.txt0000644000000000000000000035616611402176071015574 0ustar Network Working Group S. Waldbusser Request for Comments: 1513 Carnegie Mellon University Updates: 1271 September 1993 Token Ring Extensions to the Remote Network Monitoring MIB Status of this Memo This RFC 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" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe. That MIB defines objects broken down into nine functional groups. Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type. RFC 1271 defined those specific objects necessary for Ethernet. This companion memo defines those specific objects necessary for Token Ring LANs. In addition, this memo defines some additional monitoring functions specifically for Token Ring. These are defined in the Ring Station Group, the Ring Station Order Group, the Ring Station Configuration Group, and the Source Routing Statistics Group. Table of Contents 1. The Network Management Framework ...................... 2 2. Guidelines for implementing RFC1271 objects on a Token Ring network .................................... 3 2.1 Host Group ........................................... 3 2.2 Matrix Group ......................................... 3 2.3 Filter Group ......................................... 3 2.4 Other comments ....................................... 4 3. Overview of the RMON Token Ring Extensions MIB ........ 4 3.1 The Token Ring Statistics Groups ..................... 4 3.2 The Token Ring History Groups ........................ 5 3.3 The Token Ring Ring Station Group .................... 5 Waldbusser [Page 1] RFC 1513 Token Ring Extensions to RMON MIB September 1993 3.4 The Token Ring Ring Station Order Group .............. 5 3.5 The Token Ring Ring Station Config Group ............. 5 3.6 The Token Ring Source Routing Group .................. 5 4. Terminology ........................................... 5 5. Definitions ........................................... 6 5.1 The Token Ring Mac-Layer Statistics Group ............ 6 5.2 The Token Ring Promiscuous Statistics Group .......... 14 5.3 The Token Ring Mac-Layer History Group ............... 19 5.4 The Token Ring Promiscuous History Group ............. 27 5.5 The Token Ring Ring Station Group .................... 32 5.6 The Token Ring Ring Station Order Group .............. 41 5.7 The Token Ring Ring Station Config Group ............. 43 5.8 The Token Ring Source Routing Group .................. 47 6. References ............................................ 54 7. Acknowledgments ....................................... 55 8. Security Considerations ............................... 55 9. Author's Address ...................................... 55 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16, RFC 1155 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16, RFC 1212 [2] defines a more concise description mechanism, which is wholly consistent with the SMI. STD 17, RFC 1213 [3] which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15, RFC 1157 [4] which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using STD 16, RFC 1212's OBJECT-TYPE macro. At a minimum, each object has a name, a syntax, an access-level, and an implementation-status. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 object descriptor, to also refer to the object type. Waldbusser [Page 2] RFC 1513 Token Ring Extensions to RMON MIB September 1993 The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1[5] language is used for this purpose. However, STD 16, RFC 1155 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The access-level of an object type defines whether it makes "protocol sense" to read and/or write the value of an instance of the object type. (This access-level is independent of any administrative authorization policy.) The implementation-status of an object type indicates whether the object is mandatory, optional, obsolete, or deprecated. 2. Guidelines for implementing RFC1271 objects on a Token Ring network Wherever a MacAddress is to be used in this MIB the source routing bit is stripped off. The resulting address will be consistently valid for all packets sent by a particular node. 2.1. Host Group Only Token Ring isolating errors will increment the error counter for a particular hostEntry. The isolating errors are: LineErrors, BurstErrors, ACErrors, InternalErrors, and AbortErrors. ACErrors will increment the error counter only for the nearest upstream neighbor of the station reporting the error. LineErrors and BurstErrors will increment the error counters for the station reporting the error and its neighbor upstream neighbor. InternalErrors and AbortErrors will increment the error counter for the station reporting the error only. In addition, congestionErrors will also be counted for each hostEntry. These errors will be incremented in the host entry of the station that reports the errors in an error report frame. The hostOutPkts and hostOutOctets counters shall not be incremented for packets with errors. 2.2. Matrix Group Error counters are never incremented. 2.3. Filter Group The following conditions make up the status bitmask for token ring networks: Waldbusser [Page 3] RFC 1513 Token Ring Extensions to RMON MIB September 1993 bit # Error 3 First packet after some packets were dropped 4 Packet with the Frame Copied Bit set 5 Packet with the Address Recognized Bit set For the purpose of the packet match algorithm, the filters assume a 32 byte RIF field. Thus, when matching, the filter is compared to the packet starting at the AC byte of the packet, until the end of the RIF field; then the unused RIF bytes in the filter are skipped and matching proceeds from that point. Any filter "care" bits in the RIF that don't correspond to bytes in the input packet will cause the filter to fail. 2.4. Other comments Because soft error report packets may be sent with assured delivery, some errors may be accidently reported twice on devices that perform the RMON function promiscuously. 3. Overview of the RMON Token Ring Extensions MIB The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe. That MIB defines objects broken down into nine functional groups. Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type. RFC 1271 defined those specific objects necessary for Ethernet. This MIB defines contains four groups that define those specific objects necessary for Token Ring LANs. In addition, this memo defines some additional monitoring functions specifically for Token Ring. These are defined in the Ring Station Group, the Ring Station Order Group, the Ring Station Configuration Group, and the Source Routing Statistics Group. 3.1. The Token Ring Statistics Groups The Token Ring statistics groups contain current utilization and error statistics. The statistics are broken down into two groups, the Token Ring Mac-Layer Statistics Group and the Token Ring Promiscuous Statistics Group. The Token Ring Mac-Layer Statistics Group collects information from Mac Layer, including error reports for the ring and ring utilization of the Mac Layer. The Token Ring Promiscuous Statistics Group collects utilization statistics from data packets collected promiscuously. Waldbusser [Page 4] RFC 1513 Token Ring Extensions to RMON MIB September 1993 3.2. The Token Ring History Groups The Token Ring History Groups contain historical utilization and error statistics. The statistics are broken down into two groups, the Token Ring Mac-Layer History Group and the Token Ring Promiscuous History Group. The Token Ring Mac-Layer History Group collects information from Mac Layer, including error reports for the ring and ring utilization of the Mac Layer. The Token Ring Promiscuous History Group collects utilization statistics from data packets collected promiscuously. 3.3. The Token Ring Ring Station Group The Token Ring Ring Station Group contains statistics and status information associated with each Token Ring station on the local ring. In addition, this group provides status information for each ring being monitored. 3.4. The Token Ring Ring Station Order Group The Token Ring Ring Station Order Group provides the order of the stations on monitored rings. 3.5. The Token Ring Ring Station Config Group The Token Ring Ring Station Config Group manages token ring stations through active means. Any station on a monitored ring may be removed or have configuration information downloaded from it. 3.6. The Token Ring Source Routing Group The Token Ring Source Routing Group contains utilization statistics derived from source routing information optionally present in token ring packets. 4. Terminology The 802.5 specification [7] defines the term "good frame" as a frame that is bounded by a valid SD and ED, is an integral number of octets in length, is composed of only 0 and 1 bits between the SD and the ED, has the FF bits of the GC field equal to 00 or 01, has a valid FCS, and has a minimum of 18 octets between the SD and the ED. This document will use the term "good frame" in the same manner. Waldbusser [Page 5] RFC 1513 Token Ring Extensions to RMON MIB September 1993 5. Definitions TOKEN-RING-RMON-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 OwnerString, EntryStatus, -- Textual Conventions rmon, statistics, history FROM RFC1271-MIB; -- All representations of MAC addresses in this MIB -- Module use, as a textual convention (i.e. this -- convention does not affect their encoding), the -- data type: MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet -- address in -- the "canonical" -- order -- defined by IEEE 802.1a, i.e., as if it were -- transmitted least significant bit first, even though -- 802.5 (in contrast to other 802.x protocols) requires -- MAC addresses to be transmitted most significant bit -- first. TimeInterval ::= INTEGER -- A period of time, measured in units of 0.01 seconds. -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [2]. -- Token Ring Remote Network Monitoring MIB tokenRing OBJECT IDENTIFIER ::= { rmon 10 } -- The Token Ring Mac-Layer Statistics Group -- -- Implementation of this group is optional tokenRingMLStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF TokenRingMLStatsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of Mac-Layer Token Ring statistics Waldbusser [Page 6] RFC 1513 Token Ring Extensions to RMON MIB September 1993 entries." ::= { statistics 2 } tokenRingMLStatsEntry OBJECT-TYPE SYNTAX TokenRingMLStatsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of Mac-Layer statistics kept for a particular Token Ring interface." INDEX { tokenRingMLStatsIndex } ::= { tokenRingMLStatsTable 1 } -- As an example, an instance of the -- tokenRingMLStatsMacOctets object -- might be named tokenRingMLStatsMacOctets.1 TokenRingMLStatsEntry ::= SEQUENCE { tokenRingMLStatsIndex INTEGER, tokenRingMLStatsDataSource OBJECT IDENTIFIER, tokenRingMLStatsDropEvents Counter, tokenRingMLStatsMacOctets Counter, tokenRingMLStatsMacPkts Counter, tokenRingMLStatsRingPurgeEvents Counter, tokenRingMLStatsRingPurgePkts Counter, tokenRingMLStatsBeaconEvents Counter, tokenRingMLStatsBeaconTime TimeInterval, tokenRingMLStatsBeaconPkts Counter, tokenRingMLStatsClaimTokenEvents Counter, tokenRingMLStatsClaimTokenPkts Counter, tokenRingMLStatsNAUNChanges Counter, tokenRingMLStatsLineErrors Counter, tokenRingMLStatsInternalErrors Counter, tokenRingMLStatsBurstErrors Counter, tokenRingMLStatsACErrors Counter, tokenRingMLStatsAbortErrors Counter, tokenRingMLStatsLostFrameErrors Counter, tokenRingMLStatsCongestionErrors Counter, tokenRingMLStatsFrameCopiedErrors Counter, tokenRingMLStatsFrequencyErrors Counter, tokenRingMLStatsTokenErrors Counter, tokenRingMLStatsSoftErrorReports Counter, tokenRingMLStatsRingPollEvents Counter, tokenRingMLStatsOwner OwnerString, tokenRingMLStatsStatus EntryStatus } Waldbusser [Page 7] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLStatsIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object uniquely identifies this tokenRingMLStats entry." ::= { tokenRingMLStatsEntry 1 } tokenRingMLStatsDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "This object identifies the source of the data that this tokenRingMLStats entry is configured to analyze. This source can be any tokenRing interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in MIB-II [3], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. The statistics in this group reflect all error reports on the local network segment attached to the identified interface. This object may not be modified if the associated tokenRingMLStatsStatus object is equal to valid(1)." ::= { tokenRingMLStatsEntry 2 } tokenRingMLStatsDropEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of events in which packets were dropped by the probe due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is just the number of times this condition has been detected. This value is the same as the corresponding tokenRingPStatsDropEvents." ::= { tokenRingMLStatsEntry 3 } Waldbusser [Page 8] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLStatsMacOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of octets of data in MAC packets (excluding those that were not good frames) received on the network (excluding framing bits but including FCS octets)." ::= { tokenRingMLStatsEntry 4 } tokenRingMLStatsMacPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of MAC packets (excluding packets that were not good frames) received." ::= { tokenRingMLStatsEntry 5 } tokenRingMLStatsRingPurgeEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times that the ring enters the ring purge state from normal ring state. The ring purge state that comes in response to the claim token or beacon state is not counted." ::= { tokenRingMLStatsEntry 6 } tokenRingMLStatsRingPurgePkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ring purge MAC packets detected by probe." ::= { tokenRingMLStatsEntry 7 } tokenRingMLStatsBeaconEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times that the ring enters a beaconing state (beaconFrameStreamingState, beaconBitStreamingState, Waldbusser [Page 9] RFC 1513 Token Ring Extensions to RMON MIB September 1993 beaconSetRecoveryModeState, or beaconRingSignalLossState) from a non-beaconing state. Note that a change of the source address of the beacon packet does not constitute a new beacon event." ::= { tokenRingMLStatsEntry 8 } tokenRingMLStatsBeaconTime OBJECT-TYPE SYNTAX TimeInterval ACCESS read-only STATUS mandatory DESCRIPTION "The total amount of time that the ring has been in the beaconing state." ::= { tokenRingMLStatsEntry 9 } tokenRingMLStatsBeaconPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of beacon MAC packets detected by the probe." ::= { tokenRingMLStatsEntry 10 } tokenRingMLStatsClaimTokenEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times that the ring enters the claim token state from normal ring state or ring purge state. The claim token state that comes in response to a beacon state is not counted." ::= { tokenRingMLStatsEntry 11 } tokenRingMLStatsClaimTokenPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of claim token MAC packets detected by the probe." ::= { tokenRingMLStatsEntry 12 } Waldbusser [Page 10] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLStatsNAUNChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of NAUN changes detected by the probe." ::= { tokenRingMLStatsEntry 13 } tokenRingMLStatsLineErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of line errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 14 } tokenRingMLStatsInternalErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of adapter internal errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 15 } tokenRingMLStatsBurstErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of burst errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 16 } tokenRingMLStatsACErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AC (Address Copied) errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 17 } Waldbusser [Page 11] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLStatsAbortErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of abort delimiters reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 18 } tokenRingMLStatsLostFrameErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of lost frame errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 19 } tokenRingMLStatsCongestionErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of receive congestion errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 20 } tokenRingMLStatsFrameCopiedErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frame copied errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 21 } tokenRingMLStatsFrequencyErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frequency errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 22 } Waldbusser [Page 12] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLStatsTokenErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of token errors reported in error reporting packets detected by the probe." ::= { tokenRingMLStatsEntry 23 } tokenRingMLStatsSoftErrorReports OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of soft error report frames detected by the probe." ::= { tokenRingMLStatsEntry 24 } tokenRingMLStatsRingPollEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ring poll events detected by the probe (i.e. the number of ring polls initiated by the active monitor that were detected)." ::= { tokenRingMLStatsEntry 25 } tokenRingMLStatsOwner OBJECT-TYPE SYNTAX OwnerString ACCESS read-write STATUS mandatory DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { tokenRingMLStatsEntry 26 } tokenRingMLStatsStatus OBJECT-TYPE SYNTAX EntryStatus ACCESS read-write STATUS mandatory DESCRIPTION "The status of this tokenRingMLStats entry." ::= { tokenRingMLStatsEntry 27 } Waldbusser [Page 13] RFC 1513 Token Ring Extensions to RMON MIB September 1993 -- The Token Ring Promiscuous Statistics Group -- -- Implementation of this group is optional tokenRingPStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF TokenRingPStatsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of promiscuous Token Ring statistics entries." ::= { statistics 3 } tokenRingPStatsEntry OBJECT-TYPE SYNTAX TokenRingPStatsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of promiscuous statistics kept for non-MAC packets on a particular Token Ring interface." INDEX { tokenRingPStatsIndex } ::= { tokenRingPStatsTable 1 } -- As an example, an instance of the -- tokenRingPStatsDataOctets object -- might be named tokenRingPStatsDataOctets.1 TokenRingPStatsEntry ::= SEQUENCE { tokenRingPStatsIndex INTEGER, tokenRingPStatsDataSource OBJECT IDENTIFIER, tokenRingPStatsDropEvents Counter, tokenRingPStatsDataOctets Counter, tokenRingPStatsDataPkts Counter, tokenRingPStatsDataBroadcastPkts Counter, tokenRingPStatsDataMulticastPkts Counter, tokenRingPStatsDataPkts18to63Octets Counter, tokenRingPStatsDataPkts64to127Octets Counter, tokenRingPStatsDataPkts128to255Octets Counter, tokenRingPStatsDataPkts256to511Octets Counter, tokenRingPStatsDataPkts512to1023Octets Counter, tokenRingPStatsDataPkts1024to2047Octets Counter, tokenRingPStatsDataPkts2048to4095Octets Counter, tokenRingPStatsDataPkts4096to8191Octets Counter, tokenRingPStatsDataPkts8192to18000Octets Counter, tokenRingPStatsDataPktsGreaterThan18000Octets Counter, tokenRingPStatsOwner OwnerString, tokenRingPStatsStatus EntryStatus Waldbusser [Page 14] RFC 1513 Token Ring Extensions to RMON MIB September 1993 } tokenRingPStatsIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object uniquely identifies this tokenRingPStats entry." ::= { tokenRingPStatsEntry 1 } tokenRingPStatsDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "This object identifies the source of the data that this tokenRingPStats entry is configured to analyze. This source can be any tokenRing interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in MIB-II [3], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. The statistics in this group reflect all non-MAC packets on the local network segment attached to the identified interface. This object may not be modified if the associated tokenRingPStatsStatus object is equal to valid(1)." ::= { tokenRingPStatsEntry 2 } tokenRingPStatsDropEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of events in which packets were dropped by the probe due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is just the number of times this condition has been detected. This value is the same as the corresponding tokenRingMLStatsDropEvents" Waldbusser [Page 15] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ::= { tokenRingPStatsEntry 3 } tokenRingPStatsDataOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of octets of data in good frames received on the network (excluding framing bits but including FCS octets) in non-MAC packets." ::= { tokenRingPStatsEntry 4 } tokenRingPStatsDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of non-MAC packets in good frames. received." ::= { tokenRingPStatsEntry 5 } tokenRingPStatsDataBroadcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were directed to an LLC broadcast address (0xFFFFFFFFFFFF or 0xC000FFFFFFFF)." ::= { tokenRingPStatsEntry 6 } tokenRingPStatsDataMulticastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were directed to a local or global multicast or functional address. Note that this number does not include packets directed to the broadcast address." ::= { tokenRingPStatsEntry 7 } tokenRingPStatsDataPkts18to63Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Waldbusser [Page 16] RFC 1513 Token Ring Extensions to RMON MIB September 1993 "The total number of good non-MAC frames received that were between 18 and 63 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 8 } tokenRingPStatsDataPkts64to127Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 64 and 127 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 9 } tokenRingPStatsDataPkts128to255Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 128 and 255 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 10 } tokenRingPStatsDataPkts256to511Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 256 and 511 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 11 } tokenRingPStatsDataPkts512to1023Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 512 and 1023 octets in length inclusive, excluding framing bits but including FCS octets." Waldbusser [Page 17] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ::= { tokenRingPStatsEntry 12 } tokenRingPStatsDataPkts1024to2047Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 1024 and 2047 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 13 } tokenRingPStatsDataPkts2048to4095Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 2048 and 4095 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 14 } tokenRingPStatsDataPkts4096to8191Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 4096 and 8191 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 15 } tokenRingPStatsDataPkts8192to18000Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were between 8192 and 18000 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 16 } tokenRingPStatsDataPktsGreaterThan18000Octets OBJECT-TYPE SYNTAX Counter Waldbusser [Page 18] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received that were greater than 18000 octets in length, excluding framing bits but including FCS octets." ::= { tokenRingPStatsEntry 17 } tokenRingPStatsOwner OBJECT-TYPE SYNTAX OwnerString ACCESS read-write STATUS mandatory DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { tokenRingPStatsEntry 18 } tokenRingPStatsStatus OBJECT-TYPE SYNTAX EntryStatus ACCESS read-write STATUS mandatory DESCRIPTION "The status of this tokenRingPStats entry." ::= { tokenRingPStatsEntry 19 } -- The Token Ring History Groups -- When an entry in the historyControlTable is created that -- identifies a token ring interface as its -- historyControlDataSource, the probe shall create -- corresponding entries in the tokenRingMLHistoryTable -- and/or the tokenRingPHistoryTable, depending on which -- groups it supports. -- The Token Ring Mac-Layer History Group -- -- Implementation of this group is optional. -- Implementation of this group requires implementation of -- the historyControl group from RFC1271. tokenRingMLHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF TokenRingMLHistoryEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of Mac-Layer Token Ring statistics Waldbusser [Page 19] RFC 1513 Token Ring Extensions to RMON MIB September 1993 entries." ::= { history 3 } tokenRingMLHistoryEntry OBJECT-TYPE SYNTAX TokenRingMLHistoryEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of Mac-Layer statistics kept for a particular Token Ring interface." INDEX { tokenRingMLHistoryIndex, tokenRingMLHistorySampleIndex } ::= { tokenRingMLHistoryTable 1 } -- As an example, an instance of the -- tokenRingMLHistoryMacOctets -- object might be named tokenRingMLHistoryMacOctets.1.27 TokenRingMLHistoryEntry ::= SEQUENCE { tokenRingMLHistoryIndex INTEGER, tokenRingMLHistorySampleIndex INTEGER, tokenRingMLHistoryIntervalStart TimeTicks, tokenRingMLHistoryDropEvents Counter, tokenRingMLHistoryMacOctets Counter, tokenRingMLHistoryMacPkts Counter, tokenRingMLHistoryRingPurgeEvents Counter, tokenRingMLHistoryRingPurgePkts Counter, tokenRingMLHistoryBeaconEvents Counter, tokenRingMLHistoryBeaconTime TimeInterval, tokenRingMLHistoryBeaconPkts Counter, tokenRingMLHistoryClaimTokenEvents Counter, tokenRingMLHistoryClaimTokenPkts Counter, tokenRingMLHistoryNAUNChanges Counter, tokenRingMLHistoryLineErrors Counter, tokenRingMLHistoryInternalErrors Counter, tokenRingMLHistoryBurstErrors Counter, tokenRingMLHistoryACErrors Counter, tokenRingMLHistoryAbortErrors Counter, tokenRingMLHistoryLostFrameErrors Counter, tokenRingMLHistoryCongestionErrors Counter, tokenRingMLHistoryFrameCopiedErrors Counter, tokenRingMLHistoryFrequencyErrors Counter, tokenRingMLHistoryTokenErrors Counter, tokenRingMLHistorySoftErrorReports Counter, tokenRingMLHistoryRingPollEvents Counter, tokenRingMLHistoryActiveStations INTEGER } Waldbusser [Page 20] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLHistoryIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The history of which this entry is a part. The history identified by a particular value of this index is the same history as identified by the same value of historyControlIndex." ::= { tokenRingMLHistoryEntry 1 } tokenRingMLHistorySampleIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An index that uniquely identifies the particular Mac-Layer sample this entry represents among all Mac-Layer samples associated with the same historyControlEntry. This index starts at 1 and increases by one as each new sample is taken." ::= { tokenRingMLHistoryEntry 2 } tokenRingMLHistoryIntervalStart OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the start of the interval over which this sample was measured. If the probe keeps track of the time of day, it should start the first sample of the history at a time such that when the next hour of the day begins, a sample is started at that instant. Note that following this rule may require the probe to delay collecting the first sample of the history, as each sample must be of the same interval. Also note that the sample which is currently being collected is not accessible in this table until the end of its interval." ::= { tokenRingMLHistoryEntry 3 } tokenRingMLHistoryDropEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of events in which packets were Waldbusser [Page 21] RFC 1513 Token Ring Extensions to RMON MIB September 1993 dropped by the probe due to lack of resources during this sampling interval. Note that this number is not necessarily the number of packets dropped, it is just the number of times this condition has been detected." ::= { tokenRingMLHistoryEntry 4 } tokenRingMLHistoryMacOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of octets of data in MAC packets (excluding those that were not good frames) received on the network during this sampling interval (excluding framing bits but including FCS octets)." ::= { tokenRingMLHistoryEntry 5 } tokenRingMLHistoryMacPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of MAC packets (excluding those that were not good frames) received during this sampling interval." ::= { tokenRingMLHistoryEntry 6 } tokenRingMLHistoryRingPurgeEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times that the ring entered the ring purge state from normal ring state during this sampling interval. The ring purge state that comes from the claim token or beacon state is not counted." ::= { tokenRingMLHistoryEntry 7 } tokenRingMLHistoryRingPurgePkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of Ring Purge MAC packets detected by the probe during this sampling Waldbusser [Page 22] RFC 1513 Token Ring Extensions to RMON MIB September 1993 interval." ::= { tokenRingMLHistoryEntry 8 } tokenRingMLHistoryBeaconEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times that the ring enters a beaconing state (beaconFrameStreamingState, beaconBitStreamingState, beaconSetRecoveryModeState, or beaconRingSignalLossState) during this sampling interval. Note that a change of the source address of the beacon packet does not constitute a new beacon event." ::= { tokenRingMLHistoryEntry 9 } tokenRingMLHistoryBeaconTime OBJECT-TYPE SYNTAX TimeInterval ACCESS read-only STATUS mandatory DESCRIPTION "The amount of time that the ring has been in the beaconing state during this sampling interval." ::= { tokenRingMLHistoryEntry 10 } tokenRingMLHistoryBeaconPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of beacon MAC packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 11 } tokenRingMLHistoryClaimTokenEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times that the ring enters the claim token state from normal ring state or ring purge state during this sampling interval. The claim token state that comes from the beacon state is not counted." ::= { tokenRingMLHistoryEntry 12 } Waldbusser [Page 23] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLHistoryClaimTokenPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of claim token MAC packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 13 } tokenRingMLHistoryNAUNChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of NAUN changes detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 14 } tokenRingMLHistoryLineErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of line errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 15 } tokenRingMLHistoryInternalErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of adapter internal errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 16 } tokenRingMLHistoryBurstErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of burst errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 17 } Waldbusser [Page 24] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingMLHistoryACErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AC (Address Copied) errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 18 } tokenRingMLHistoryAbortErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of abort delimiters reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 19 } tokenRingMLHistoryLostFrameErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of lost frame errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 20 } tokenRingMLHistoryCongestionErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of receive congestion errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 21 } tokenRingMLHistoryFrameCopiedErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frame copied errors reported in error reporting packets detected by the probe during this sampling interval." Waldbusser [Page 25] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ::= { tokenRingMLHistoryEntry 22 } tokenRingMLHistoryFrequencyErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frequency errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 23 } tokenRingMLHistoryTokenErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of token errors reported in error reporting packets detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 24 } tokenRingMLHistorySoftErrorReports OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of soft error report frames detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 25 } tokenRingMLHistoryRingPollEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ring poll events detected by the probe during this sampling interval." ::= { tokenRingMLHistoryEntry 26 } tokenRingMLHistoryActiveStations OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The maximum number of active stations on the ring detected by the probe during this sampling Waldbusser [Page 26] RFC 1513 Token Ring Extensions to RMON MIB September 1993 interval." ::= { tokenRingMLHistoryEntry 27} -- The Token Ring Promiscuous History Group -- -- Implementation of this group is optional. -- Implementation of this group requires the implementation -- of the historyControl group from RFC1271. tokenRingPHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF TokenRingPHistoryEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of promiscuous Token Ring statistics entries." ::= { history 4 } tokenRingPHistoryEntry OBJECT-TYPE SYNTAX TokenRingPHistoryEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of promiscuous statistics kept for a particular Token Ring interface." INDEX { tokenRingPHistoryIndex, tokenRingPHistorySampleIndex } ::= { tokenRingPHistoryTable 1 } -- As an example, an instance of the -- tokenRingPHistoryDataPkts object -- might be named tokenRingPHistoryDataPkts.1.27 TokenRingPHistoryEntry ::= SEQUENCE { tokenRingPHistoryIndex INTEGER, tokenRingPHistorySampleIndex INTEGER, tokenRingPHistoryIntervalStart TimeTicks, tokenRingPHistoryDropEvents Counter, tokenRingPHistoryDataOctets Counter, tokenRingPHistoryDataPkts Counter, tokenRingPHistoryDataBroadcastPkts Counter, tokenRingPHistoryDataMulticastPkts Counter, tokenRingPHistoryDataPkts18to63Octets Counter, tokenRingPHistoryDataPkts64to127Octets Counter, tokenRingPHistoryDataPkts128to255Octets Counter, tokenRingPHistoryDataPkts256to511Octets Counter, tokenRingPHistoryDataPkts512to1023Octets Counter, Waldbusser [Page 27] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingPHistoryDataPkts1024to2047Octets Counter, tokenRingPHistoryDataPkts2048to4095Octets Counter, tokenRingPHistoryDataPkts4096to8191Octets Counter, tokenRingPHistoryDataPkts8192to18000Octets Counter, tokenRingPHistoryDataPktsGreaterThan18000Octets Counter } tokenRingPHistoryIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The history of which this entry is a part. The history identified by a particular value of this index is the same history as identified by the same value of historyControlIndex." ::= { tokenRingPHistoryEntry 1 } tokenRingPHistorySampleIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An index that uniquely identifies the particular sample this entry represents among all samples associated with the same historyControlEntry. This index starts at 1 and increases by one as each new sample is taken." ::= { tokenRingPHistoryEntry 2 } tokenRingPHistoryIntervalStart OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the start of the interval over which this sample was measured. If the probe keeps track of the time of day, it should start the first sample of the history at a time such that when the next hour of the day begins, a sample is started at that instant. Note that following this rule may require the probe to delay collecting the first sample of the history, as each sample must be of the same interval. Also note that the sample which is currently being collected is not accessible in this table until the end of its interval." ::= { tokenRingPHistoryEntry 3 } Waldbusser [Page 28] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingPHistoryDropEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of events in which packets were dropped by the probe due to lack of resources during this sampling interval. Note that this number is not necessarily the number of packets dropped, it is just the number of times this condition has been detected." ::= { tokenRingPHistoryEntry 4 } tokenRingPHistoryDataOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of octets of data in good frames received on the network (excluding framing bits but including FCS octets) in non-MAC packets during this sampling interval." ::= { tokenRingPHistoryEntry 5 } tokenRingPHistoryDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval." ::= { tokenRingPHistoryEntry 6 } tokenRingPHistoryDataBroadcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were directed to an LLC broadcast address (0xFFFFFFFFFFFF or 0xC000FFFFFFFF)." ::= { tokenRingPHistoryEntry 7 } tokenRingPHistoryDataMulticastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Waldbusser [Page 29] RFC 1513 Token Ring Extensions to RMON MIB September 1993 DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were directed to a local or global multicast or functional address. Note that this number does not include packets directed to the broadcast address." ::= { tokenRingPHistoryEntry 8 } tokenRingPHistoryDataPkts18to63Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 18 and 63 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 9 } tokenRingPHistoryDataPkts64to127Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 64 and 127 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 10 } tokenRingPHistoryDataPkts128to255Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 128 and 255 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 11 } tokenRingPHistoryDataPkts256to511Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between Waldbusser [Page 30] RFC 1513 Token Ring Extensions to RMON MIB September 1993 256 and 511 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 12 } tokenRingPHistoryDataPkts512to1023Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 512 and 1023 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 13 } tokenRingPHistoryDataPkts1024to2047Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 1024 and 2047 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 14 } tokenRingPHistoryDataPkts2048to4095Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 2048 and 4095 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 15 } tokenRingPHistoryDataPkts4096to8191Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 4096 and 8191 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 16 } Waldbusser [Page 31] RFC 1513 Token Ring Extensions to RMON MIB September 1993 tokenRingPHistoryDataPkts8192to18000Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were between 8192 and 18000 octets in length inclusive, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 17 } tokenRingPHistoryDataPktsGreaterThan18000Octets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good non-MAC frames received during this sampling interval that were greater than 18000 octets in length, excluding framing bits but including FCS octets." ::= { tokenRingPHistoryEntry 18 } -- The Token Ring Ring Station Group -- -- Implementation of this group is optional -- -- Although the ringStationTable stores entries only for -- those stations physically attached to the local ring and -- the number of stations attached to a ring is limited, a -- probe may still need to free resources when resources -- grow tight. In such a situation, it is suggested that -- the probe free only inactive stations, and to -- first free the stations that have been inactive for the -- longest time. ringStationControlTable OBJECT-TYPE SYNTAX SEQUENCE OF RingStationControlEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of ringStation table control entries." ::= { tokenRing 1 } ringStationControlEntry OBJECT-TYPE SYNTAX RingStationControlEntry ACCESS not-accessible STATUS mandatory Waldbusser [Page 32] RFC 1513 Token Ring Extensions to RMON MIB September 1993 DESCRIPTION "A list of parameters that set up the discovery of stations on a particular interface and the collection of statistics about these stations." INDEX { ringStationControlIfIndex } ::= { ringStationControlTable 1 } -- As an example, an instance of the -- ringStationControlIfIndex object -- might be named ringStationControlIfIndex.1 RingStationControlEntry ::= SEQUENCE { ringStationControlIfIndex INTEGER, ringStationControlTableSize INTEGER, ringStationControlActiveStations INTEGER, ringStationControlRingState INTEGER, ringStationControlBeaconSender MacAddress, ringStationControlBeaconNAUN MacAddress, ringStationControlActiveMonitor MacAddress, ringStationControlOrderChanges Counter, ringStationControlOwner OwnerString, ringStationControlStatus EntryStatus } ringStationControlIfIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object uniquely identifies the interface on this remote network monitoring device from which ringStation data is collected. The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object, defined in MIB- II [3]." ::= { ringStationControlEntry 1 } ringStationControlTableSize OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of ringStationEntries in the ringStationTable associated with this ringStationControlEntry." ::= { ringStationControlEntry 2 } Waldbusser [Page 33] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ringStationControlActiveStations OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of active ringStationEntries in the ringStationTable associated with this ringStationControlEntry." ::= { ringStationControlEntry 3 } ringStationControlRingState OBJECT-TYPE SYNTAX INTEGER { normalOperation(1), ringPurgeState(2), claimTokenState(3), beaconFrameStreamingState(4), beaconBitStreamingState(5), beaconRingSignalLossState(6), beaconSetRecoveryModeState(7) } ACCESS read-only STATUS mandatory DESCRIPTION "The current status of this ring." ::= { ringStationControlEntry 4 } ringStationControlBeaconSender OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "The address of the sender of the last beacon frame received by the probe on this ring. If no beacon frames have been received, this object shall be equal to six octets of zero." ::= { ringStationControlEntry 5 } ringStationControlBeaconNAUN OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "The address of the NAUN in the last beacon frame received by the probe on this ring. If no beacon frames have been received, this object shall be equal to six octets of zero." ::= { ringStationControlEntry 6 } Waldbusser [Page 34] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ringStationControlActiveMonitor OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "The address of the Active Monitor on this segment. If this address is unknown, this object shall be equal to six octets of zero." ::= { ringStationControlEntry 7 } ringStationControlOrderChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of add and delete events in the ringStationOrderTable optionally associated with this ringStationControlEntry." ::= { ringStationControlEntry 8 } ringStationControlOwner OBJECT-TYPE SYNTAX OwnerString ACCESS read-write STATUS mandatory DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { ringStationControlEntry 9 } ringStationControlStatus OBJECT-TYPE SYNTAX EntryStatus ACCESS read-write STATUS mandatory DESCRIPTION "The status of this ringStationControl entry. If this object is not equal to valid(1), all associated entries in the ringStationTable shall be deleted by the agent." ::= { ringStationControlEntry 10 } ringStationTable OBJECT-TYPE SYNTAX SEQUENCE OF RingStationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of ring station entries. An entry will exist for each station that is now or has Waldbusser [Page 35] RFC 1513 Token Ring Extensions to RMON MIB September 1993 previously been detected as physically present on this ring." ::= { tokenRing 2 } ringStationEntry OBJECT-TYPE SYNTAX RingStationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of statistics for a particular station that has been discovered on a ring monitored by this device." INDEX { ringStationIfIndex, ringStationMacAddress } ::= { ringStationTable 1 } -- As an example, an instance of the -- ringStationStationStatus object might be named -- ringStationStationStatus.1.16.0.90.0.64.131 RingStationEntry ::= SEQUENCE { ringStationIfIndex INTEGER, ringStationMacAddress MacAddress, ringStationLastNAUN MacAddress, ringStationStationStatus INTEGER, ringStationLastEnterTime TimeTicks, ringStationLastExitTime TimeTicks, ringStationDuplicateAddresses Counter, ringStationInLineErrors Counter, ringStationOutLineErrors Counter, ringStationInternalErrors Counter, ringStationInBurstErrors Counter, ringStationOutBurstErrors Counter, ringStationACErrors Counter, ringStationAbortErrors Counter, ringStationLostFrameErrors Counter, ringStationCongestionErrors Counter, ringStationFrameCopiedErrors Counter, ringStationFrequencyErrors Counter, ringStationTokenErrors Counter, ringStationInBeaconErrors Counter, ringStationOutBeaconErrors Counter, ringStationInsertions Counter } ringStationIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory Waldbusser [Page 36] RFC 1513 Token Ring Extensions to RMON MIB September 1993 DESCRIPTION "The value of this object uniquely identifies the interface on this remote network monitoring device on which this station was detected. The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object, defined in MIB-II [3]." ::= { ringStationEntry 1 } ringStationMacAddress OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "The physical address of this station." ::= { ringStationEntry 2 } ringStationLastNAUN OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "The physical address of last known NAUN of this station." ::= { ringStationEntry 3 } ringStationStationStatus OBJECT-TYPE SYNTAX INTEGER { active(1), -- actively participating in ring poll. inactive(2), -- Not participating in ring poll forcedRemoval(3) -- Forced off ring by network -- management. } ACCESS read-only STATUS mandatory DESCRIPTION "The status of this station on the ring." ::= { ringStationEntry 4 } ringStationLastEnterTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the time this station last entered the ring. If the time is unknown, this value shall be zero." ::= { ringStationEntry 5 } Waldbusser [Page 37] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ringStationLastExitTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the time the probe detected that this station last exited the ring. If the time is unknown, this value shall be zero." ::= { ringStationEntry 6 } ringStationDuplicateAddresses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this station experienced a duplicate address error." ::= { ringStationEntry 7 } ringStationInLineErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of line errors reported by this station in error reporting packets detected by the probe." ::= { ringStationEntry 8 } ringStationOutLineErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of line errors reported in error reporting packets sent by the nearest active downstream neighbor of this station and detected by the probe." ::= { ringStationEntry 9 } ringStationInternalErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of adapter internal errors reported by this station in error reporting packets detected by the probe." Waldbusser [Page 38] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ::= { ringStationEntry 10 } ringStationInBurstErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of burst errors reported by this station in error reporting packets detected by the probe." ::= { ringStationEntry 11 } ringStationOutBurstErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of burst errors reported in error reporting packets sent by the nearest active downstream neighbor of this station and detected by the probe." ::= { ringStationEntry 12 } ringStationACErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AC (Address Copied) errors reported in error reporting packets sent by the nearest active downstream neighbor of this station and detected by the probe." ::= { ringStationEntry 13 } ringStationAbortErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of abort delimiters reported by this station in error reporting packets detected by the probe." ::= { ringStationEntry 14 } ringStationLostFrameErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Waldbusser [Page 39] RFC 1513 Token Ring Extensions to RMON MIB September 1993 DESCRIPTION "The total number of lost frame errors reported by this station in error reporting packets detected by the probe." ::= { ringStationEntry 15 } ringStationCongestionErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of receive congestion errors reported by this station in error reporting packets detected by the probe." ::= { ringStationEntry 16 } ringStationFrameCopiedErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frame copied errors reported by this station in error reporting packets detected by the probe." ::= { ringStationEntry 17 } ringStationFrequencyErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frequency errors reported by this station in error reporting packets detected by the probe." ::= { ringStationEntry 18 } ringStationTokenErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of token errors reported by this station in error reporting frames detected by the probe." ::= { ringStationEntry 19 } ringStationInBeaconErrors OBJECT-TYPE SYNTAX Counter Waldbusser [Page 40] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ACCESS read-only STATUS mandatory DESCRIPTION "The total number of beacon frames sent by this station and detected by the probe." ::= { ringStationEntry 20 } ringStationOutBeaconErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of beacon frames detected by the probe that name this station as the NAUN." ::= { ringStationEntry 21 } ringStationInsertions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the probe detected this station inserting onto the ring." ::= { ringStationEntry 22 } -- The Token Ring Ring Station Order Group -- -- Implementation of this group is optional -- -- The ringStationOrderTable ringStationOrderTable OBJECT-TYPE SYNTAX SEQUENCE OF RingStationOrderEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of ring station entries for stations in the ring poll, ordered by their ring-order." ::= { tokenRing 3 } ringStationOrderEntry OBJECT-TYPE SYNTAX RingStationOrderEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of statistics for a particular Waldbusser [Page 41] RFC 1513 Token Ring Extensions to RMON MIB September 1993 station that is active on a ring monitored by this device. This table will contain information for every interface that has a ringStationControlStatus equal to valid." INDEX { ringStationOrderIfIndex, ringStationOrderOrderIndex } ::= { ringStationOrderTable 1 } -- As an example, an instance of the -- ringStationOrderMacAddress object might be named -- ringStationOrderMacAddress.1.14 RingStationOrderEntry ::= SEQUENCE { ringStationOrderIfIndex INTEGER, ringStationOrderOrderIndex INTEGER, ringStationOrderMacAddress MacAddress } ringStationOrderIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object uniquely identifies the interface on this remote network monitoring device on which this station was detected. The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object, defined in MIB-II [3]." ::= { ringStationOrderEntry 1 } ringStationOrderOrderIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This index denotes the location of this station with respect to other stations on the ring. This index is one more than the number of hops downstream that this station is from the rmon probe. The rmon probe itself gets the value one." ::= { ringStationOrderEntry 2 } ringStationOrderMacAddress OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION Waldbusser [Page 42] RFC 1513 Token Ring Extensions to RMON MIB September 1993 "The physical address of this station." ::= { ringStationOrderEntry 3 } -- The Token Ring Ring Station Config Group -- -- Implementation of this group is optional. -- The ring station config group manages token ring nodes -- through active means. ringStationConfigControlTable OBJECT-TYPE SYNTAX SEQUENCE OF RingStationConfigControlEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of ring station configuration control entries." ::= { tokenRing 4 } ringStationConfigControlEntry OBJECT-TYPE SYNTAX RingStationConfigControlEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This entry controls active management of stations by the probe. One entry exists in this table for each active station in the ringStationTable." INDEX { ringStationConfigControlIfIndex, ringStationConfigControlMacAddress } ::= { ringStationConfigControlTable 1 } -- As an example, an instance of the -- ringStationConfigControlRemove object might be named -- ringStationConfigControlRemove.1.16.0.90.0.64.131 RingStationConfigControlEntry ::= SEQUENCE { ringStationConfigControlIfIndex INTEGER, ringStationConfigControlMacAddress MacAddress, ringStationConfigControlRemove INTEGER, ringStationConfigControlUpdateStats INTEGER } ringStationConfigControlIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object uniquely identifies the Waldbusser [Page 43] RFC 1513 Token Ring Extensions to RMON MIB September 1993 interface on this remote network monitoring device on which this station was detected. The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object, defined in MIB-II [3]." ::= { ringStationConfigControlEntry 1 } ringStationConfigControlMacAddress OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "The physical address of this station." ::= { ringStationConfigControlEntry 2 } ringStationConfigControlRemove OBJECT-TYPE SYNTAX INTEGER { stable(1), removing(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Setting this object to `removing(2)' causes a Remove Station MAC frame to be sent. The agent will set this object to `stable(1)' after processing the request." ::= { ringStationConfigControlEntry 3 } ringStationConfigControlUpdateStats OBJECT-TYPE SYNTAX INTEGER { stable(1), updating(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Setting this object to `updating(2)' causes the configuration information associate with this entry to be updated. The agent will set this object to `stable(1)' after processing the request." ::= { ringStationConfigControlEntry 4 } Waldbusser [Page 44] RFC 1513 Token Ring Extensions to RMON MIB September 1993 -- The ringStationConfig Table -- -- Entries exist in this table after an active -- configuration query has completed successfully for -- a station. This query is initiated by the associated -- ringStationConfigControlUpdateStats variable. ringStationConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF RingStationConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of configuration entries for stations on a ring monitored by this probe." ::= { tokenRing 5 } ringStationConfigEntry OBJECT-TYPE SYNTAX RingStationConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of statistics for a particular station that has been discovered on a ring monitored by this probe." INDEX { ringStationConfigIfIndex, ringStationConfigMacAddress } ::= { ringStationConfigTable 1 } -- As an example, an instance of the -- ringStationConfigLocation object might be named -- ringStationConfigLocation.1.16.0.90.0.64.131 RingStationConfigEntry ::= SEQUENCE { ringStationConfigIfIndex INTEGER, ringStationConfigMacAddress MacAddress, ringStationConfigUpdateTime TimeTicks, ringStationConfigLocation OCTET STRING, ringStationConfigMicrocode OCTET STRING, ringStationConfigGroupAddress OCTET STRING, ringStationConfigFunctionalAddress OCTET STRING } ringStationConfigIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object uniquely identifies the Waldbusser [Page 45] RFC 1513 Token Ring Extensions to RMON MIB September 1993 interface on this remote network monitoring device on which this station was detected. The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object, defined in MIB-II [3]." ::= { ringStationConfigEntry 1 } ringStationConfigMacAddress OBJECT-TYPE SYNTAX MacAddress ACCESS read-only STATUS mandatory DESCRIPTION "The physical address of this station." ::= { ringStationConfigEntry 2 } ringStationConfigUpdateTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the time this configuration information was last updated (completely)." ::= { ringStationConfigEntry 3 } ringStationConfigLocation OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) ACCESS read-only STATUS mandatory DESCRIPTION "The assigned physical location of this station." ::= { ringStationConfigEntry 4 } ringStationConfigMicrocode OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) ACCESS read-only STATUS mandatory DESCRIPTION "The microcode EC level of this station." ::= { ringStationConfigEntry 5 } ringStationConfigGroupAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) ACCESS read-only STATUS mandatory DESCRIPTION "The low-order 4 octets of the group address recognized by this station." Waldbusser [Page 46] RFC 1513 Token Ring Extensions to RMON MIB September 1993 ::= { ringStationConfigEntry 6 } ringStationConfigFunctionalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) ACCESS read-only STATUS mandatory DESCRIPTION "the functional addresses recognized by this station." ::= { ringStationConfigEntry 7 } -- The Token Ring Source Routing group -- -- Implementation of this group is optional. -- The data in this group is collected from the source -- routing information potentially present in any token ring -- packet. This information will be valid only in a pure -- source route bridging environment. In a transparent -- bridging or a mixed bridging environment, this -- information may not be accurate. sourceRoutingStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SourceRoutingStatsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of source routing statistics entries." ::= { tokenRing 6 } sourceRoutingStatsEntry OBJECT-TYPE SYNTAX SourceRoutingStatsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A collection of source routing statistics kept for a particular Token Ring interface." INDEX { sourceRoutingStatsIfIndex } ::= { sourceRoutingStatsTable 1 } -- As an example, an instance of the -- sourceRoutingStatsInFrames object might be named -- sourceRoutingStatsInFrames.1 SourceRoutingStatsEntry ::= SEQUENCE { sourceRoutingStatsIfIndex INTEGER, sourceRoutingStatsRingNumber INTEGER, sourceRoutingStatsInFrames Counter, Waldbusser [Page 47] RFC 1513 Token Ring Extensions to RMON MIB September 1993 -- in to our net sourceRoutingStatsOutFrames Counter, -- out from our net sourceRoutingStatsThroughFrames Counter, -- through our net sourceRoutingStatsAllRoutesBroadcastFrames Counter, sourceRoutingStatsSingleRouteBroadcastFrames Counter, sourceRoutingStatsInOctets Counter, sourceRoutingStatsOutOctets Counter, sourceRoutingStatsThroughOctets Counter, sourceRoutingStatsAllRoutesBroadcastOctets Counter, sourceRoutingStatsSingleRoutesBroadcastOctets Counter, sourceRoutingStatsLocalLLCFrames Counter, sourceRoutingStats1HopFrames Counter, sourceRoutingStats2HopsFrames Counter, sourceRoutingStats3HopsFrames Counter, sourceRoutingStats4HopsFrames Counter, sourceRoutingStats5HopsFrames Counter, sourceRoutingStats6HopsFrames Counter, sourceRoutingStats7HopsFrames Counter, sourceRoutingStats8HopsFrames Counter, sourceRoutingStatsMoreThan8HopsFrames Counter, sourceRoutingStatsOwner OwnerString, sourceRoutingStatsStatus EntryStatus } sourceRoutingStatsIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object uniquely identifies the interface on this remote network monitoring device on which source routing statistics will be detected. The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object, defined in MIB-II [3]." ::= { sourceRoutingStatsEntry 1 } sourceRoutingStatsRingNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION Waldbusser [Page 48] RFC 1513 Token Ring Extensions to RMON MIB September 1993 "The ring number of the ring monitored by this entry. When any object in this entry is created, the probe will attempt to discover the ring number. Only after the ring number is discovered will this object be created. After creating an object in this entry, the management station should poll this object to detect when it is created. Only after this object is created can the management station set the sourceRoutingStatsStatus entry to valid(1)." ::= { sourceRoutingStatsEntry 2 } sourceRoutingStatsInFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of frames sent into this ring from another ring." ::= { sourceRoutingStatsEntry 3 } sourceRoutingStatsOutFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of frames sent from this ring to another ring." ::= { sourceRoutingStatsEntry 4 } sourceRoutingStatsThroughFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of frames sent from another ring, through this ring, to another ring." ::= { sourceRoutingStatsEntry 5 } sourceRoutingStatsAllRoutesBroadcastFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good frames received that were All Routes Broadcast." ::= { sourceRoutingStatsEntry 6 } Waldbusser [Page 49] RFC 1513 Token Ring Extensions to RMON MIB September 1993 sourceRoutingStatsSingleRouteBroadcastFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of good frames received that were Single Route Broadcast." ::= { sourceRoutingStatsEntry 7 } sourceRoutingStatsInOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of octets in good frames sent into this ring from another ring." ::= { sourceRoutingStatsEntry 8 } sourceRoutingStatsOutOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of octets in good frames sent from this ring to another ring." ::= { sourceRoutingStatsEntry 9 } sourceRoutingStatsThroughOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of octets in good frames sent another ring, through this ring, to another ring." ::= { sourceRoutingStatsEntry 10 } sourceRoutingStatsAllRoutesBroadcastOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of octets in good frames received that were All Routes Broadcast." ::= { sourceRoutingStatsEntry 11 } sourceRoutingStatsSingleRoutesBroadcastOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only Waldbusser [Page 50] RFC 1513 Token Ring Extensions to RMON MIB September 1993 STATUS mandatory DESCRIPTION "The total number of octets in good frames received that were Single Route Broadcast." ::= { sourceRoutingStatsEntry 12 } sourceRoutingStatsLocalLLCFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received who had no RIF field (or had a RIF field that only included the local ring's number) and were not All Route Broadcast Frames." ::= { sourceRoutingStatsEntry 13 } sourceRoutingStats1HopFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had 1 hop, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 14 } sourceRoutingStats2HopsFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had 2 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 15 } sourceRoutingStats3HopsFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Waldbusser [Page 51] RFC 1513 Token Ring Extensions to RMON MIB September 1993 "The total number of frames received whose route had 3 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 16 } sourceRoutingStats4HopsFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had 4 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 17 } sourceRoutingStats5HopsFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had 5 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 18 } sourceRoutingStats6HopsFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had 6 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 19 } sourceRoutingStats7HopsFrames OBJECT-TYPE Waldbusser [Page 52] RFC 1513 Token Ring Extensions to RMON MIB September 1993 SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had 7 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 20 } sourceRoutingStats8HopsFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had 8 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 21 } sourceRoutingStatsMoreThan8HopsFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of frames received whose route had more than 8 hops, were not All Route Broadcast Frames, and whose source or destination were on this ring (i.e. frames that had a RIF field and had this ring number in the first or last entry of the RIF field)." ::= { sourceRoutingStatsEntry 22 } sourceRoutingStatsOwner OBJECT-TYPE SYNTAX OwnerString ACCESS read-write STATUS mandatory DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { sourceRoutingStatsEntry 23 } sourceRoutingStatsStatus OBJECT-TYPE Waldbusser [Page 53] RFC 1513 Token Ring Extensions to RMON MIB September 1993 SYNTAX EntryStatus ACCESS read-write STATUS mandatory DESCRIPTION "The status of this sourceRoutingStats entry." ::= { sourceRoutingStatsEntry 24 } END 6. References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [3] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [5] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December, 1987. [6] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1271, CMU, November 1991. [7] Token Ring Access Method and Physical Layer Specifications, Institute of Electrical and Electronic Engineers, IEEE Standard 802.5-1989, 1989. Waldbusser [Page 54] RFC 1513 Token Ring Extensions to RMON MIB September 1993 7. Acknowledgments This document was produced by the Token Ring RMON MIB working group. In addition, the author gratefully acknowledges the comments of the following individuals: Andrew Bierman Synoptics Steve Bostock Novell Gary Ellis Hewlett-Packard Mike Erlinger Aerospace Corporation Robert Graham Protools Stephen Grau Novell Carl Hayssen Ungermann-Bass Jeff Hughes Hewlett-Packard Robin Iddon AXON Networks Ken Kutzler Synoptics To-Choi Lau Novell Carl Madison Startek Keith McCloghrie Hughes Lan Systems Rohit Mital Protools Keith Schomburg IBM Marshall Rose Dover Beach Consulting Mark Therieau Microcom Mark van der Pol Hughes Lan Systems Brian Wyld Consultant 8. Security Considerations Security issues are not discussed in this memo. 9. Author's Address Steven Waldbusser Carnegie Mellon University 4910 Forbes Ave. Pittsburgh, PA 15213 Phone: (412) 268-6628 EMail: waldbusser@cmu.edu Waldbusser [Page 55] snmp-mibs-downloader-1.1/mibrfcs/rfc1525.txt0000644000000000000000000011232411402176071015561 0ustar Network Working Group E. Decker Request for Comments: 1525 cisco Systems, Inc. Obsoletes: 1286 K. McCloghrie Category: Standards Track Hughes LAN Systems, Inc. P. Langille DEC A. Rijsinghani DEC September 1993 Definitions of Managed Objects for Source Routing Bridges Status of this Memo This RFC 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" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Table of Contents 1. Introduction ......................................... 2 2. The Network Management Framework ..................... 2 2.1 Object Definitions .................................. 2 3. Overview ............................................. 2 3.1 Structure of MIB .................................... 3 3.1.1 The dot1dSr Group ................................. 4 3.1.2 The dot1dPortPair Group ........................... 4 3.2 Relationship to Other MIBs .......................... 5 3.2.1 Relationship to the Bridge MIB .................... 5 3.2.2 Relationship to the 'system' group ................ 5 3.2.3 Relationship to the 'interfaces' group ............ 5 4. Changes from RFC 1286 ................................ 6 5. Definitions .......................................... 7 5.1 Groups in the SR MIB ................................ 7 5.2 The dot1dSr Group Definitions ....................... 7 5.3 The dot1dPortPair Group Definitions ................. 14 6. Acknowledgments ...................................... 16 7. References ........................................... 16 8. Security Considerations .............................. 18 9. Authors' Addresses ................................... 18 Decker, McCloghrie, Langille & Rijsinghani [Page 1] RFC 1525 Source Routing Bridge MIB September 1993 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB [6]. This MIB supersedes the dot1dSr group of objects published in an earlier version of the Bridge MIB, RFC 1286. Changes have primarily been made to track changes in the IEEE 802.5M SRT Addendum to the IEEE 802.1D Standard for MAC Bridges. 2. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: o STD 16, RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16, RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o STD 15, RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. 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 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 A common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the network Decker, McCloghrie, Langille & Rijsinghani [Page 2] RFC 1525 Source Routing Bridge MIB September 1993 layer. There are two major modes defined for this bridging; transparent and source route. The transparent method of bridging is defined in the IEEE 802.1d MAC Bridge specification [11]. Source route bridging has been defined by I.B.M. and is described in the Token Ring Architecture Reference [12], as well as the IEEE 802.5M SRT Bridge Operations Addendum [14] to 802.1d. This memo defines objects needed for management of a source routing bridge, and is an extension to the SNMP Bridge MIB [6]. An explicit attempt was made to keep this MIB as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: (1) Start with a small set of essential objects and add only as further objects are needed. (2) Require objects be essential for either fault or configuration management. (3) Consider evidence of current use and/or utility. (4) Limit the total of objects. (5) Exclude objects which are simply derivable from others in this or other MIBs. (6) Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. 3.1. Structure of MIB Objects in this MIB are arranged into groups. Each group is organized as a set of related objects. The overall structure and assignment of objects to their groups is shown below. Where appropriate, the corresponding management object name found in IEEE 802.1d [11] and IEEE 802.5M [14] is also included. SR Bridge MIB Name IEEE Name dot1dSr PortTable Port HopCount SourceRoutingPort .PortHopCount LocalSegment .SegmentNumber BridgeNum .BridgeNumber TargetSegment Decker, McCloghrie, Langille & Rijsinghani [Page 3] RFC 1525 Source Routing Bridge MIB September 1993 LargestFrame .LargestFrameSize STESpanMode .LimitedBroadcastMode SpecInFrames BridgePort .ValidSRFramesReceived SpecOutFrames .ValidSRForwardedOutbound ApeInFrames ApeOutFrames .BroadcastFramesForwarded SteInFrames SteOutFrames .BroadcastFramesForwarded SegmentMismatchDiscards .DiscardInvalidRI DuplicateSegmentDiscards .LanIdMismatch HopCountExceededDiscards .FramesDiscardedHopCountExceeded The following IEEE management objects have not been included in the SR Bridge MIB for the indicated reasons. IEEE Object Disposition SourceRoutingPort The following objects were NOT included in this MIB because they are redundant or not considered useful. .LimitedBroadcastEnable .DiscardLackOfBuffers .DiscardErrorDetails .DiscardTargetLANInoperable .ValidSRDiscardedInbound .BroadcastBytesForwarded .NonBroadcastBytesForwarded .FramesNotReceivedDueToCongestion .FramesDiscardedDueToInternalError 3.1.1. The dot1dSr Group This group contains the objects that describe the entity's state with respect to source route bridging. If source routing is not supported, this group will not be implemented. This group is applicable to source route only, and SRT bridges. 3.1.2. The dot1dPortPair Group Implementation of this group is optional. This group is implemented by those bridges that support the port-pair multiport model of the source route bridging mode as defined in the IEEE 802.5M SRT Addendum to 802.1d. Decker, McCloghrie, Langille & Rijsinghani [Page 4] RFC 1525 Source Routing Bridge MIB September 1993 3.2. Relationship to Other MIBs As described above, some IEEE 802.1d management objects have not been included in this MIB because they overlap with objects in other MIBs applicable to a bridge implementing this MIB. In particular, it is assumed that a bridge implementing this MIB will also implement (at least) the Bridge MIB and the 'system' group and the 'interfaces' group defined in MIB-II [4]. 3.2.1. Relationship to the Bridge MIB The Bridge MIB [6] must be implemented by all bridges, including transparent, SR and SRT bridges. The SR bridge MIB is an extension to the Bridge MIB. 3.2.2. Relationship to the 'system' group In MIB-II, the 'system' group is defined as being mandatory for all systems such that each managed entity contains one instance of each object in the 'system' group. Thus, those objects apply to the entity as a whole irrespective of whether the entity's sole functionality is bridging, or whether bridging is only a subset of the entity's functionality. 3.2.3. Relationship to the 'interfaces' group In MIB-II, the 'interfaces' group is defined as being mandatory for all systems and contains information on an entity's interfaces, where each interface is thought of as being attached to a `subnetwork'. (Note that this term is not to be confused with `subnet' which refers to an addressing partitioning scheme used in the Internet suite of protocols.) The term 'segment' is used in this memo to refer to such a subnetwork. Implicit in this MIB is the notion of ports on a bridge. Each of these ports is associated with one interface of the 'interfaces' group, and in most situations, each port is associated with a different interface. However, there are situations in which multiple ports are associated with the same interface. An example of such a situation would be several ports, each corresponding one-to-one with several X.25 virtual circuits, but all on the same interface. Each port is uniquely identified by a port number. A port number has no mandatory relationship to an interface number, but in the simple case, a port number will have the same value as the corresponding interface's interface number. Decker, McCloghrie, Langille & Rijsinghani [Page 5] RFC 1525 Source Routing Bridge MIB September 1993 Some entities provide other services in addition to bridging with respect to the data sent and received by their interfaces. In such situations, only a subset of the data sent/received on an interface is within the domain of the entity's bridging functionality. This subset is considered to be delineated according to a set of protocols, with some protocols being bridged, and other protocols not being bridged. For example, in an entity which exclusively performed bridging, all protocols would be considered as being bridged, whereas in an entity which performed IP routing on IP datagrams and only bridged other protocols, only the non-IP data would be considered as being bridged. Thus, this MIB (and in particular, its counters) are applicable only to that subset of the data on an entity's interfaces which is sent/received for a protocol being bridged. All such data is sent/received via the ports of the bridge. 4. Changes from RFC 1286 In addition to being separated from the Bridge MIB into a separate document, the following changes were implemented as a result of feedback from IEEE 802.5M: (1) Changed syntax of dot1dSrPortLargestFrame to INTEGER in order to allow for having 64 possible values as described in draft 7 of the SR Addendum. Listed all legal values in description. (2) Updated syntax of dot1dSrPort, used to index into dot1dSrPortTable, to use the range (1..65535). (3) Added a counter to dot1dSrPortTable to count occurrences of duplicate LAN IDs or Tree errors. (4) Added a counter to dot1dSrPortTable to count LAN ID mismatches. (5) Added text to dot1dSrPortSpecInFrames and dot1dSrPortSpecOutFrames clarifying that they are also referred to as Source Routed Frames. (6) Added text to dot1dSrPortApeInFrames and dot1dSrPortApeOutFrames clarifying that they are also referred to as All Routes Explorer frames. (7) Added a scalar variable to the dot1dSr group to indicate whether the bridge uses 3 bit or 6 bit length negotiation fields. Decker, McCloghrie, Langille & Rijsinghani [Page 6] RFC 1525 Source Routing Bridge MIB September 1993 (8) Added dot1dPortPairGroup to allow representation of port pairs as defined in the IEEE 802.5M SRT Addendum. 5. Definitions SOURCE-ROUTING-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, Gauge FROM RFC1155-SMI dot1dBridge, dot1dSr FROM BRIDGE-MIB OBJECT-TYPE FROM RFC-1212; -- groups in the SR MIB -- dot1dSr is imported from the Bridge MIB dot1dPortPair OBJECT IDENTIFIER ::= { dot1dBridge 10 } -- the dot1dSr group -- this group is implemented by those bridges that -- support the source route bridging mode, including Source -- Routing and SRT bridges. dot1dSrPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dSrPortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains information about every port that is associated with this source route bridge." ::= { dot1dSr 1 } dot1dSrPortEntry OBJECT-TYPE SYNTAX Dot1dSrPortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of information for each port of a source route bridge." INDEX { dot1dSrPort } Decker, McCloghrie, Langille & Rijsinghani [Page 7] RFC 1525 Source Routing Bridge MIB September 1993 ::= { dot1dSrPortTable 1 } Dot1dSrPortEntry ::= SEQUENCE { dot1dSrPort INTEGER, dot1dSrPortHopCount INTEGER, dot1dSrPortLocalSegment INTEGER, dot1dSrPortBridgeNum INTEGER, dot1dSrPortTargetSegment INTEGER, dot1dSrPortLargestFrame INTEGER, dot1dSrPortSTESpanMode INTEGER, dot1dSrPortSpecInFrames Counter, dot1dSrPortSpecOutFrames Counter, dot1dSrPortApeInFrames Counter, dot1dSrPortApeOutFrames Counter, dot1dSrPortSteInFrames Counter, dot1dSrPortSteOutFrames Counter, dot1dSrPortSegmentMismatchDiscards Counter, dot1dSrPortDuplicateSegmentDiscards Counter, dot1dSrPortHopCountExceededDiscards Counter, dot1dSrPortDupLanIdOrTreeErrors Counter, dot1dSrPortLanIdMismatches Counter } dot1dSrPort OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The port number of the port for which this entry Decker, McCloghrie, Langille & Rijsinghani [Page 8] RFC 1525 Source Routing Bridge MIB September 1993 contains Source Route management information." ::= { dot1dSrPortEntry 1 } dot1dSrPortHopCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The maximum number of routing descriptors allowed in an All Paths or Spanning Tree Explorer frames." ::= { dot1dSrPortEntry 2 } dot1dSrPortLocalSegment OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The segment number that uniquely identifies the segment to which this port is connected. Current source routing protocols limit this value to the range: 0 through 4095. (The value 0 is used by some management applications for special test cases.) A value of 65535 signifies that no segment number is assigned to this port." ::= { dot1dSrPortEntry 3 } dot1dSrPortBridgeNum OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "A bridge number uniquely identifies a bridge when more than one bridge is used to span the same two segments. Current source routing protocols limit this value to the range: 0 through 15. A value of 65535 signifies that no bridge number is assigned to this bridge." ::= { dot1dSrPortEntry 4 } dot1dSrPortTargetSegment OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The segment number that corresponds to the target segment this port is considered to be connected to by the bridge. Current source routing protocols limit this value to the range: 0 through 4095. Decker, McCloghrie, Langille & Rijsinghani [Page 9] RFC 1525 Source Routing Bridge MIB September 1993 (The value 0 is used by some management applications for special test cases.) A value of 65535 signifies that no target segment is assigned to this port." ::= { dot1dSrPortEntry 5 } -- It would be nice if we could use ifMtu as the size of the -- largest frame, but we can't because ifMtu is defined to be -- the size that the (inter-)network layer can use which can -- differ from the MAC layer (especially if several layers of -- encapsulation are used). dot1dSrPortLargestFrame OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The maximum size of the INFO field (LLC and above) that this port can send/receive. It does not include any MAC level (framing) octets. The value of this object is used by this bridge to determine whether a modification of the LargestFrame (LF, see [14]) field of the Routing Control field of the Routing Information Field is necessary. 64 valid values are defined by the IEEE 802.5M SRT Addendum: 516, 635, 754, 873, 993, 1112, 1231, 1350, 1470, 1542, 1615, 1688, 1761, 1833, 1906, 1979, 2052, 2345, 2638, 2932, 3225, 3518, 3812, 4105, 4399, 4865, 5331, 5798, 6264, 6730, 7197, 7663, 8130, 8539, 8949, 9358, 9768, 10178, 10587, 10997, 11407, 12199, 12992, 13785, 14578, 15370, 16163, 16956, 17749, 20730, 23711, 26693, 29674, 32655, 35637, 38618, 41600, 44591, 47583, 50575, 53567, 56559, 59551, and 65535. An illegal value will not be accepted by the bridge." ::= { dot1dSrPortEntry 6 } dot1dSrPortSTESpanMode OBJECT-TYPE SYNTAX INTEGER { auto-span(1), disabled(2), forced(3) } ACCESS read-write Decker, McCloghrie, Langille & Rijsinghani [Page 10] RFC 1525 Source Routing Bridge MIB September 1993 STATUS mandatory DESCRIPTION "Determines how this port behaves when presented with a Spanning Tree Explorer frame. The value 'disabled(2)' indicates that the port will not accept or send Spanning Tree Explorer packets; any STE packets received will be silently discarded. The value 'forced(3)' indicates the port will always accept and propagate Spanning Tree Explorer frames. This allows a manually configured Spanning Tree for this class of packet to be configured. Note that unlike transparent bridging, this is not catastrophic to the network if there are loops. The value 'auto-span(1)' can only be returned by a bridge that both implements the Spanning Tree Protocol and has use of the protocol enabled on this port. The behavior of the port for Spanning Tree Explorer frames is determined by the state of dot1dStpPortState. If the port is in the 'forwarding' state, the frame will be accepted or propagated. Otherwise, it will be silently discarded." ::= { dot1dSrPortEntry 7 } dot1dSrPortSpecInFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of Specifically Routed frames, also referred to as Source Routed Frames, that have been received from this port's segment." ::= { dot1dSrPortEntry 8 } dot1dSrPortSpecOutFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of Specifically Routed frames, also referred to as Source Routed Frames, that this port has transmitted on its segment." ::= { dot1dSrPortEntry 9 } dot1dSrPortApeInFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Decker, McCloghrie, Langille & Rijsinghani [Page 11] RFC 1525 Source Routing Bridge MIB September 1993 DESCRIPTION "The number of All Paths Explorer frames, also referred to as All Routes Explorer frames, that have been received by this port from its segment." ::= { dot1dSrPortEntry 10 } dot1dSrPortApeOutFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of all Paths Explorer Frames, also referred to as All Routes Explorer frames, that have been transmitted by this port on its segment." ::= { dot1dSrPortEntry 11 } dot1dSrPortSteInFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of spanning tree explorer frames that have been received by this port from its segment." ::= { dot1dSrPortEntry 12 } dot1dSrPortSteOutFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of spanning tree explorer frames that have been transmitted by this port on its segment." ::= { dot1dSrPortEntry 13 } dot1dSrPortSegmentMismatchDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of explorer frames that have been discarded by this port because the routing descriptor field contained an invalid adjacent segment value." ::= { dot1dSrPortEntry 14 } dot1dSrPortDuplicateSegmentDiscards OBJECT-TYPE Decker, McCloghrie, Langille & Rijsinghani [Page 12] RFC 1525 Source Routing Bridge MIB September 1993 SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of frames that have been discarded by this port because the routing descriptor field contained a duplicate segment identifier." ::= { dot1dSrPortEntry 15 } dot1dSrPortHopCountExceededDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of explorer frames that have been discarded by this port because the Routing Information Field has exceeded the maximum route descriptor length." ::= { dot1dSrPortEntry 16 } dot1dSrPortDupLanIdOrTreeErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of duplicate LAN IDs or Tree errors. This helps in detection of problems in networks containing older IBM Source Routing Bridges." ::= { dot1dSrPortEntry 17 } dot1dSrPortLanIdMismatches OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ARE and STE frames that were discarded because the last LAN ID in the routing information field did not equal the LAN-in ID. This error can occur in implementations which do only a LAN-in ID and Bridge Number check instead of a LAN-in ID, Bridge Number, and LAN-out ID check before they forward broadcast frames." ::= { dot1dSrPortEntry 18 } -- scalar object in dot1dSr dot1dSrBridgeLfMode OBJECT-TYPE Decker, McCloghrie, Langille & Rijsinghani [Page 13] RFC 1525 Source Routing Bridge MIB September 1993 SYNTAX INTEGER { mode3(1), mode6(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Indicates whether the bridge operates using older 3 bit length negotiation fields or the newer 6 bit length field in its RIF." ::= { dot1dSr 2 } -- The Port-Pair Database -- Implementation of this group is optional. -- This group is implemented by those bridges that support -- the direct multiport model of the source route bridging -- mode as defined in the IEEE 802.5 SRT Addendum to -- 802.1d. -- Bridges implementing this group may report 65535 for -- dot1dSrPortBridgeNumber and dot1dSrPortTargetSegment, -- indicating that those objects are not applicable. dot1dPortPairTableSize OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The total number of entries in the Bridge Port Pair Database." ::= { dot1dPortPair 1 } -- the Bridge Port-Pair table -- this table represents port pairs within a bridge forming -- a unique bridge path, as defined in the IEEE 802.5M SRT -- Addendum. dot1dPortPairTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dPortPairEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains information about every Decker, McCloghrie, Langille & Rijsinghani [Page 14] RFC 1525 Source Routing Bridge MIB September 1993 port pair database entity associated with this source routing bridge." ::= { dot1dPortPair 2 } dot1dPortPairEntry OBJECT-TYPE SYNTAX Dot1dPortPairEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of information for each port pair entity of a bridge." INDEX { dot1dPortPairLowPort, dot1dPortPairHighPort } ::= { dot1dPortPairTable 1 } Dot1dPortPairEntry ::= SEQUENCE { dot1dPortPairLowPort INTEGER, dot1dPortPairHighPort INTEGER, dot1dPortPairBridgeNum INTEGER, dot1dPortPairBridgeState INTEGER } dot1dPortPairLowPort OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The port number of the lower numbered port for which this entry contains port pair database information." ::= { dot1dPortPairEntry 1 } dot1dPortPairHighPort OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The port number of the higher numbered port for which this entry contains port pair database information." ::= { dot1dPortPairEntry 2 } dot1dPortPairBridgeNum OBJECT-TYPE SYNTAX INTEGER Decker, McCloghrie, Langille & Rijsinghani [Page 15] RFC 1525 Source Routing Bridge MIB September 1993 ACCESS read-write STATUS mandatory DESCRIPTION "A bridge number that uniquely identifies the path provided by this source routing bridge between the segments connected to dot1dPortPairLowPort and dot1dPortPairHighPort. The purpose of bridge number is to disambiguate between multiple paths connecting the same two LANs." ::= { dot1dPortPairEntry 3 } dot1dPortPairBridgeState OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), invalid(3) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of dot1dPortPairBridgeNum. Writing 'invalid(3)' to this object removes the corresponding entry." ::= { dot1dPortPairEntry 4 } END 6. Acknowledgments This document was produced on behalf of the Bridge MIB Working Group in the NM area of the Internet Engineering Task Force. The authors wish to thank the members of the Bridge MIB Working Group for their many comments and suggestions which improved this effort. 7. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988. [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989. [3] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC Decker, McCloghrie, Langille & Rijsinghani [Page 16] RFC 1525 Source Routing Bridge MIB September 1993 1155, Performance Systems International, Hughes LAN Systems, May 1990. [4] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, Performance Systems International, March 1991. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] Decker, E., Langille, P., Rijsinghani, A., and McCloghrie, K., "Definitions of Managed Objects for Bridges", RFC 1493, cisco Systems, Digital Equipment Corporation, Digital Equipment Corporation, Hughes LAN Systems, July 1993. [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [10] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [11] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project 802 Local and Metropolitan Area Networks, (March 8, 1991). [12] I.B.M. Token Ring Architecture Reference. [13] ISO DIS 10038 MAC Bridges. [14] ANSI/IEEE P802.5M-Draft 7, "Source Routing Transparent Bridge Operation", IEEE Project 802 (1991). [15] ANSI/IEEE 802.1y, "Source Routing Tutorial for End System Operation", (September, 1990). Decker, McCloghrie, Langille & Rijsinghani [Page 17] RFC 1525 Source Routing Bridge MIB September 1993 Security Considerations Security issues are not discussed in this memo. Authors' Addresses Eric B. Decker cisco Systems, Inc. 1525 O'Brien Dr. Menlo Park, CA 94025 Phone: (415) 326-1941 Email: cire@cisco.com Keith McCloghrie Hughes LAN Systems, Inc. 1225 Charleston Road Mountain View, CA 94043 Phone: (415) 966-7934 EMail: kzm@hls.com Paul Langille Digital Equipment Corporation Digital Drive, MK02-2/K03 Merrimack, NH 03054 Phone: (603) 884-4045 EMail: langille@edwin.enet.dec.com Anil Rijsinghani Digital Equipment Corporation 550 King Street Littleton, MA 01460 Phone: (508) 486-6786 EMail: anil@levers.enet.dec.com Decker, McCloghrie, Langille & Rijsinghani [Page 18] snmp-mibs-downloader-1.1/mibrfcs/rfc1559.txt0000644000000000000000000036476311402176071015610 0ustar Network Working Group J. Saperia Request for Comments: 1559 Digital Equipment Corporation Obsoletes: 1289 December 1993 Category: Standards Track DECnet Phase IV MIB Extensions 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 ................................................ 1 2. The Network Management Framework ............................ 2 2.1 Object Definitions ......................................... 2 3. Selected Objects ............................................ 3 4. Textual Conventions ......................................... 4 5. Definitions ................................................. 4 6. Changes from RFC 1289 ....................................... 67 7. Acknowledgements ........................................... 68 8. References ................................................. 68 9. Security Considerations .................................... 69 10. Author's Address .......................................... 69 1. Introduction This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. When used in conjunction with the structure of management information (STD 16, RFC 1155), the management information base for network management of TCP/IP-based internets (STD 17, RFC 1213) and the Simple Network Management Protocol (STD 15, RFC 1157), it will be possible to provide integrated network management of combined TCP/IP and DECnet Phase IV based internets. This document was produced by the DECnet Phase IV MIB working group of the Internet Engineering Task Force (IETF). With the adoption of The Simple Network Management Protocol (STD 15, RFC 1157), the management information base for network management of TCP/IP-based internets (STD 17, RFC 1213), and the structure of DECnet Phase IV MIB Working Group [Page 1] RFC 1559 DECnet Phase IV MIB December 1993 management information (STD 16, RFC 1155), by the Internet, and a large number of vendor implementations of these standards in commercially available products, it became possible to provide a higher level of effective network management in TCP/IP-based internets than previously available. With the growth in the use of these standards, network managers desired to use this environment as a base for providing integrated network management of multi-protocol networks. DECnet Phase IV is one widely used protocol which often coexists in IP-based internets. This memo provides the mechanisms by which IP- based management stations can effectively manage DECnet Phase IV based systems (especially router products) in an integrated fashion through the use of the standard Internet SMI, MIB and Simple Network Management Protocol. DECnet Phase IV objects have been defined to be used in conjunction with the Internet MIB to allow access and control of these new objects by the Internet community. Additional support for other DECnet-based protocols such as RBMS (Remote Bridge Management Software) or other Digital Equipment Corporation specific hardware platforms is not included in this document. 2. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: o STD 16, RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16, RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o STD 15, RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. 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 DECnet Phase IV MIB Working Group [Page 2] RFC 1559 DECnet Phase IV MIB December 1993 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. Selected Objects The objects included in this memo have been created from the DIGITAL Network Architecture Network Management Functional Specification Version 4.0.0, dated July 1983. An attempt has been made to provide a reasonable ordering of these variables into groups. These groups are: System Group Network Management Group Session Group End Group Routing Group Circuit Group DDCMP Group DDCMP Multipoint Control Group Ethernet Group Counters Group Adjacency Group Line Group Non Broadcast Line Group Area Group An effort has also been made to preserve the original syntax of each object wherever possible, for example, a DECnet Phase IV object is Executor State. This was originally coded as a NICE (Network Information and Control Exchange) data type which is a coded single field object of 1 byte in length. When converted for inclusion into the Internet MIB using the Internet SMI, it became an enumerated integer. All objects in this memo are described using the standard Internet SMI and BER of STD 16, RFC 1155. A complete description of an object will include the name, syntax and encoding. Just as with objects supported in the MIB (STD 17, RFC 1213), an object name is identified with an object identifier which has been administratively assigned. This identifies an Object Type. When an object type is combined with a specific instance, the particular object is uniquely identified. The use of Object Descriptors in this memo is consistent with that of STD 17, RFC 1213 - they are text strings meant to be read by humans. The descriptors have been taken from the original DIGITAL Network Architecture Network Management Functional Specification Version 4.0.0 Dated July 1983 which defined DECnet Phase IV objects. These DECnet Phase IV MIB Working Group [Page 3] RFC 1559 DECnet Phase IV MIB December 1993 names were then massaged to put them in a form as consistent as possible with object type names listed in the standard Internet MIB. Object defintion information is also taken directly from the Network Architecture Network Managment Functional Specification cited above wherever possible. In this document, EXECUTOR is intended to reference only the DECnet software and is not intended to effect any other protocols which may be running on the system. 4. Textual Conventions New datatypes have been introduced as a textual conventions in this DECnet Phase IV MIB document. The purpose of these additions is to facilitate understanding of new objects in this MIB. No changes to the SMI or the SNMP are necessary to support these conventions which are described in 5 (Definitions). 5. Definitions DECNET-PHIV-MIB DEFINITIONS ::= BEGIN IMPORTS Gauge FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 mib-2, DisplayString FROM RFC1213-MIB; -- DECNet Phase-IV MIB phiv OBJECT IDENTIFIER ::= { mib-2 18 } -- textual conventions PhivAddr ::= OCTET STRING (SIZE (2)) -- This data type is intended as a short word representation of -- standard DECnet Phase IV addresses. DECnet addresses are -- hierarchically structured numbers assigned to a particular -- DECnet node. The address is structured so that the area -- number is contained in the most significant 6 bits of the -- first octet. The next 2 bits of the first octet contain -- the first two bits of the host address. The remainder of -- the host address is contained in the second octet. PhivCounter ::= INTEGER -- This data type has been created for DECnet counters. These -- counters latch at their maximum specified value until either -- the system is restarted, or they are reset to zero by the user DECnet Phase IV MIB Working Group [Page 4] RFC 1559 DECnet Phase IV MIB December 1993 -- or management software. InterfaceIndex ::= INTEGER -- The range of ifIndex, i.e., (1..2147483647) -- groups in the decnetiv mib phivSystem OBJECT IDENTIFIER ::= { phiv 1 } phivManagement OBJECT IDENTIFIER ::= { phiv 2 } session OBJECT IDENTIFIER ::= { phiv 3 } end OBJECT IDENTIFIER ::= { phiv 4 } routing OBJECT IDENTIFIER ::= { phiv 5 } circuit OBJECT IDENTIFIER ::= { phiv 6 } ddcmp OBJECT IDENTIFIER ::= { phiv 7 } control OBJECT IDENTIFIER ::= { phiv 8 } ethernet OBJECT IDENTIFIER ::= { phiv 9 } counters OBJECT IDENTIFIER ::= { phiv 10 } adjacency OBJECT IDENTIFIER ::= { phiv 11 } line OBJECT IDENTIFIER ::= { phiv 12 } nonBroadcastLine OBJECT IDENTIFIER ::= { phiv 14 } area OBJECT IDENTIFIER ::= { phiv 15 } -- System Group -- The implementation of the System Group is mandatory for -- all systems. phivSystemState OBJECT-TYPE SYNTAX INTEGER { on (1), off (2), shut (3), restricted (4) } ACCESS read-write STATUS mandatory DESCRIPTION "This represents the operational state of the executor node. The possible states are: ON Allows logical links. OFF Allows no new links, terminates existing links, and stops routing traffic through. SHUT Allows no new logical links, does not destroy existing logical links, and goes to the OFF state when all logical links are gone. DECnet Phase IV MIB Working Group [Page 5] RFC 1559 DECnet Phase IV MIB December 1993 RESTRICTED Allows no new incoming logical links from other nodes. NOTE: These values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155)." ::= { phivSystem 1 } phivExecIdent OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-write STATUS mandatory DESCRIPTION "This is a text string that describes the executor node (for example, 'Research Lab'). The string is up to 32 characters of any type." ::= { phivSystem 2 } -- Network Management Group -- The implementation of the Network Management Group is -- mandatory for all systems which contain a DECnet-style -- management version. phivMgmtMgmtVers OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "This is the read-only Network Management Version, consisting of the version number, the Engineering Change Order (ECO) number, and the user ECO number (for example, 3.0.0). This parameter applies to the executor node only." ::= { phivManagement 1 } -- Session Layer Group -- The implementation of the Session Layer Group is optional. -- A system can be said to implement this group if and only if -- all objects in this group are implemented. phivSessionSystemName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..6)) ACCESS read-only STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 6] RFC 1559 DECnet Phase IV MIB December 1993 "Name to be associated with the node identification. Only one name can be assigned to a node address or a circuit identification. No name should be used more than once in a DECnet network. Node-name is one to six upper case alphanumeric characters with at least one alpha character. A length of 0 indicates no name." ::= { session 1 } phivSessionInTimer OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum duration between the time a connect is received for a process at the executor node and the time that process accepts or rejects it. If the connect is not accepted or rejected by the user within the number of seconds specified, Session Control rejects it for the user. A value of 0 indicates no timer is running." ::= { session 2 } phivSessionOutTimer OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the duration between the time the executor requests a connect and the time that connect is acknowledged by the destination node. If the connect is not acknowledged within the number of seconds specified, Session Control returns an error. A value of 0 indicates no timer is running." ::= { session 3 } -- End Communication Layer Group -- The implementation of the End Communication Layer Group is optional. -- A system can be said to implement this group if and only if -- all objects in this group are implemented. -- Remote State Table phivEndRemoteTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivEndRemoteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 7] RFC 1559 DECnet Phase IV MIB December 1993 "Information about the state of sessions between the node under study and the nodes found in the table." ::= { end 1 } phivEndRemoteEntry OBJECT-TYPE SYNTAX PhivEndRemoteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular remote node as seen from the end communication layer." INDEX { phivEndRemoteHostNodeID } ::= { phivEndRemoteTable 1 } PhivEndRemoteEntry ::= SEQUENCE { phivEndRemoteHostNodeID PhivAddr, phivEndRemoteState INTEGER, phivEndCircuitIndex INTEGER, phivEndActiveLinks INTEGER, phivEndDelay INTEGER } phivEndRemoteHostNodeID OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "This value is the address of the remote node to be evaluated." ::= { phivEndRemoteEntry 1 } phivEndRemoteState OBJECT-TYPE SYNTAX INTEGER { on (1), off (2), shut (3), restricted (4) } ACCESS read-write STATUS mandatory DESCRIPTION "This represents the operational state of the remote node DECnet Phase IV MIB Working Group [Page 8] RFC 1559 DECnet Phase IV MIB December 1993 being evaluated. The possible states are: ON Allows logical links. OFF Allows no new links, terminates existing links, and stops routing traffic through. SHUT Allows no new logical links, does not destroy existing logical links, and goes to the OFF state when all logical links are gone. RESTRICTED Allows no new incoming logical links from other nodes. NOTE: These values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155." ::= { phivEndRemoteEntry 2 } phivEndCircuitIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index value for each known circuit used to communicate with the remote node. This is the same value as phivCircuitIndex." ::= { phivEndRemoteEntry 3 } phivEndActiveLinks OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter represents the number of active logical links from the executor to the destination node." ::= { phivEndRemoteEntry 4 } phivEndDelay OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter is the average round trip delay in seconds to the destination node. This parameter is kept on a remote node basis." ::= { phivEndRemoteEntry 5 } -- End System Counter Table DECnet Phase IV MIB Working Group [Page 9] RFC 1559 DECnet Phase IV MIB December 1993 phivEndCountTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivEndCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about the counters associated with each end system that is known to the entity. These counters reflect totals from the perspective of the executor node." ::= { end 2 } phivEndCountEntry OBJECT-TYPE SYNTAX PhivEndCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular session between two end systems." INDEX { phivEndCountHostNodeID } ::= { phivEndCountTable 1 } PhivEndCountEntry ::= SEQUENCE { phivEndCountHostNodeID PhivAddr, phivEndCountSecsLastZeroed PhivCounter, phivEndCountUsrBytesRec PhivCounter, phivEndCountUsrBytesSent PhivCounter, phivEndUCountUsrMessRec PhivCounter, phivEndCountUsrMessSent PhivCounter, phivEndCountTotalBytesRec PhivCounter, phivEndCountTotalBytesSent PhivCounter, phivEndCountTotalMessRec PhivCounter, phivEndCountTotalMessSent PhivCounter, phivEndCountConnectsRecd PhivCounter, phivEndCountConnectsSent PhivCounter, DECnet Phase IV MIB Working Group [Page 10] RFC 1559 DECnet Phase IV MIB December 1993 phivEndCountReponseTimeouts PhivCounter, phivEndCountRecdConnectResErrs PhivCounter } phivEndCountHostNodeID OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "This value is the address of the remote node to be evaluated." ::= { phivEndCountEntry 1 } phivEndCountSecsLastZeroed OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value is the number of seconds that have elapsed since the counters for the node in this table row were last set to zero. This counter is located in the network management layer, but is returned with the end system information which follows." ::= { phivEndCountEntry 2 } phivEndCountUsrBytesRec OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of user bytes received from the target host." ::= { phivEndCountEntry 3 } phivEndCountUsrBytesSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of user bytes sent to the target host." ::= { phivEndCountEntry 4 } phivEndUCountUsrMessRec OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 11] RFC 1559 DECnet Phase IV MIB December 1993 "Number of user messages received from the target host." ::= { phivEndCountEntry 5 } phivEndCountUsrMessSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of user messages sent to the target host." ::= { phivEndCountEntry 6 } phivEndCountTotalBytesRec OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of bytes received from the target host." ::= { phivEndCountEntry 7 } phivEndCountTotalBytesSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of bytes sent to the target host." ::= { phivEndCountEntry 8 } phivEndCountTotalMessRec OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of messages received from the target host." ::= { phivEndCountEntry 9 } phivEndCountTotalMessSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of messages sent to the target host." ::= { phivEndCountEntry 10 } phivEndCountConnectsRecd OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 12] RFC 1559 DECnet Phase IV MIB December 1993 "Number of connects received from the target host." ::= { phivEndCountEntry 11 } phivEndCountConnectsSent OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of connects sent to the target host." ::= {phivEndCountEntry 12 } phivEndCountReponseTimeouts OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of response timeouts." ::= { phivEndCountEntry 13 } phivEndCountRecdConnectResErrs OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of received connect resource errors." ::= {phivEndCountEntry 14 } -- additional End System objects phivEndMaxLinks OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum active logical link count allowed for the executor." ::= { end 3 } phivEndNSPVers OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter represents the version number of the node End Communication S/W. The format is version number, ECO, and user ECO, e.g., 4.1.0" ::= { end 4 } DECnet Phase IV MIB Working Group [Page 13] RFC 1559 DECnet Phase IV MIB December 1993 phivEndRetransmitFactor OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum number of times the source End Communication at the executor node will restart the retransmission timer when it expires. If the number is exceeded, Session Control disconnects the logical link for the user." ::= { end 5 } phivEndDelayFact OBJECT-TYPE SYNTAX INTEGER (1..255) ACCESS read-write STATUS mandatory DESCRIPTION "This is the number by which to multiply one sixteenth of the estimated round trip delay to a node to set the retransmission timer to that node." ::= { end 6 } phivEndDelayWeight OBJECT-TYPE SYNTAX INTEGER (1..255) ACCESS read-write STATUS mandatory DESCRIPTION "This number represents the weight to apply to a current round trip delay estimate to a remote node when updating the estimated round trip delay to a node. On some systems the number must be 1 less than a power of 2 for computational efficiency." ::= { end 7 } phivEndInactivityTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum duration of inactivity (no data in either direction) on a logical link before the node checks to see if the logical link still works. If no activity occurs within the minimum number of seconds, End Communication generates artificial traffic to test the link (End Communication specification)." ::= { end 8 } DECnet Phase IV MIB Working Group [Page 14] RFC 1559 DECnet Phase IV MIB December 1993 phivEndCountZeroCount OBJECT-TYPE SYNTAX INTEGER { other (1), reset (2) } ACCESS read-write STATUS mandatory DESCRIPTION "When this value is set to 2, all of the counters in the End System Counter Table are set to zero." ::= { end 9 } phivEndMaxLinksActive OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the high water mark for the number of links that were active at any one time." ::= { end 10 } -- Routing Layer Group -- The implementation of the Routing Layer Group is mandatory for -- all systems that implement level 1 routing layer -- communications. phivRouteBroadcastRouteTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value determines the maximum time in seconds allowed between Routing updates on Ethernet circuits. When this timer expired before a routing update occurs, a routing update is forced. With a standard calculation, Routing also uses this timer to enforce a minimum delay between routing updates." ::= { routing 1 } phivRouteBuffSize OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This parameter value determines the maximum size of a Routing message. It therefore determines the maximum size message that can be forwarded. This size includes DECnet Phase IV MIB Working Group [Page 15] RFC 1559 DECnet Phase IV MIB December 1993 protocol overhead down to and including the End Communication layer, plus a constant value of 6. (This value of 6 is included to provide compatibility with the parameter definition in Phase III, which included the Routing overhead.) It does not include Routing or Data link overhead (except for the constant value of 6). There is one buffer size for all circuits. NOTE: The BUFFER SIZE defines the maximum size messages that the Routing layer can forward. The SEGMENT BUFFER SIZE (defined below) defines the maximum size messages that the End Communication layer can transmit or receive. The SEGMENT BUFFER SIZE is always less than or equal to the BUFFER SIZE. Normally the two parameters will be equal. They may be different to allow the network manager to alter buffer sizes on all nodes without interruption of service. They both include an extra 6 bytes for compatibility with Phase III." ::= { routing 2 } phivRouteRoutingVers OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter identifies the executor node's Routing version number. The format is version number, ECO, and user ECO, e.g., 4.1.0" ::= { routing 3 } phivRouteMaxAddr OBJECT-TYPE SYNTAX INTEGER (1..1023) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the largest node number and, therefore, number of nodes that can be known about by the executor node's home area." ::= { routing 4 } phivRouteMaxBdcastNonRouters OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum total number of nonrouters the executor node can have on its Ethernet DECnet Phase IV MIB Working Group [Page 16] RFC 1559 DECnet Phase IV MIB December 1993 circuits." ::= { routing 5 } phivRouteMaxBdcastRouters OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum total number of routers the executor node can have on its Ethernet circuits." ::= { routing 6 } phivRouteMaxBuffs OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum number of transmit buffers that Routing may use for all circuits." ::= { routing 7 } phivRouteMaxCircuits OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum number of Routing circuits that the executor node can know about." ::= { routing 8 } phivRouteMaxCost OBJECT-TYPE SYNTAX INTEGER (1..1022) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum total path cost allowed from the executor to any node within an area. The path cost is the sum of the circuit costs along a path between two nodes. This parameter defines the point where the executor node's Routing routing decision algorithm declares another node unreachable because the cost of the least costly path to the other node is excessive. For correct operation, this parameter must not be less than the maximum path cost of the network." ::= { routing 9 } DECnet Phase IV MIB Working Group [Page 17] RFC 1559 DECnet Phase IV MIB December 1993 phivRouteMaxHops OBJECT-TYPE SYNTAX INTEGER (1..30) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum number of routing hops allowable from the executor to any other reachable node within an area. (A hop is the logical distance over a circuit between two adjacent nodes.) This parameter defines the point where the executor node's Routing routing decision algorithm declares another node unreachable because the length of the shortest path between the two nodes is too long. For correct operation, this parameter must not be less than the network diameter. (The network diameter is the reachability distance between the two nodes of the network having the greatest reachability distance, where reachability distance is the length the shortest path between a given pair of nodes.)" ::= { routing 10 } phivRouteMaxVisits OBJECT-TYPE SYNTAX INTEGER (1..63) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum number of nodes a message coming into the executor node can have visited. If the message is not for this node and the MAXIMUM VISITS number is exceeded, the message is discarded. The MAXIMUM VISITS parameter defines the point where the packet lifetime control algorithm discards a packet that has traversed too many nodes. For correct operation, this parameter must not be less than the maximum path length of the network. (The maximum path length is the routing distance between the two nodes of the network having the greatest routing distance, where routing distance is the length of the least costly path between a given pair of nodes.)" ::= { routing 11 } phivRouteRoutingTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value determines the maximum time in seconds allowed between Routing updates on non-Ethernet DECnet Phase IV MIB Working Group [Page 18] RFC 1559 DECnet Phase IV MIB December 1993 circuits. When this timer expires before a routing update occurs, a routing update is forced." ::= { routing 12 } phivRouteSegBuffSize OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This parameter value determines the maximum size of an end-to-end segment. The size is a decimal integer in the range 1-65535. This size is in bytes. This size includes protocol overhead down to and including the End Communication layer, plus a constant value of 6. (This value of 6 is included to provide compatibility with the BUFFER SIZE parameter definition.) It does not include Routing or Data link overhead (except for the constant value of 6)." ::= { routing 13 } phivRouteType OBJECT-TYPE SYNTAX INTEGER { routing-III (1), nonrouting-III (2), area (3), routing-IV (4), nonrouting-IV (5) } ACCESS read-only STATUS obsolete DESCRIPTION "This parameter indicates the type of the executor node. The node-type is one of the following: routing-III nonrouting-III routing-IV ronrouting-IV area A routing node has full routing capability. A nonrouting node contains a subset of the Routing routing modules. The III and IV indicate the DNA phase of the node. Nonrouting nodes can deliver and receive packets to and from any node, but cannot route packets from other nodes through to other nodes. An area node routes between areas. Refer to the Routing specification for details. DECnet Phase IV MIB Working Group [Page 19] RFC 1559 DECnet Phase IV MIB December 1993 For adjacent nodes, this is a read-only parameter that indicates the type of the reachable adjacent node. NOTE: The ROUTING-III and NONROUTING-III values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155)" ::= { routing 14 } phivRouteCountAgedPktLoss OBJECT-TYPE SYNTAX PhivCounter (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "Number of aged packet losses." ::= { routing 15 } phivRouteCountNodeUnrPktLoss OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of node unreachable packet losses." ::= { routing 16 } phivRouteCountOutRngePktLoss OBJECT-TYPE SYNTAX PhivCounter (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "Number of node out-of-range packet losses." ::= { routing 17 } phivRouteCountOverSzePktLoss OBJECT-TYPE SYNTAX PhivCounter (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "Number of Oversized packet losses." ::= { routing 18 } phivRouteCountPacketFmtErr OBJECT-TYPE SYNTAX PhivCounter (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "Number of packet format errors." ::= { routing 19 } DECnet Phase IV MIB Working Group [Page 20] RFC 1559 DECnet Phase IV MIB December 1993 phivRouteCountPtlRteUpdtLoss OBJECT-TYPE SYNTAX PhivCounter (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "Number of partial routing update losses." ::= { routing 20 } phivRouteCountVerifReject OBJECT-TYPE SYNTAX PhivCounter (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "Number of verification rejects." ::= { routing 21 } -- Level 1 Routing Table phivLevel1RouteTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivLevel1RouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about the currently known DECnet Phase IV Routes." ::= { routing 22 } phivLevel1RouteEntry OBJECT-TYPE SYNTAX PhivLevel1RouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about the currently known DECnet Phase IV Routes." INDEX { phivLevel1RouteNodeAddr } ::= { phivLevel1RouteTable 1 } PhivLevel1RouteEntry ::= SEQUENCE { phivLevel1RouteNodeAddr PhivAddr, phivLevel1RouteCircuitIndex INTEGER, phivLevel1RouteCost INTEGER, phivLevel1RouteHops INTEGER, phivLevel1RouteNextNode DECnet Phase IV MIB Working Group [Page 21] RFC 1559 DECnet Phase IV MIB December 1993 PhivAddr } phivLevel1RouteNodeAddr OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "This value is the address of the node about which routing information is contained in this level 1 routing table." ::= { phivLevel1RouteEntry 1 } phivLevel1RouteCircuitIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index value for each known circuit. This is the index to the circuit state table and is the same value as phivCircuitIndex." ::= { phivLevel1RouteEntry 2 } phivLevel1RouteCost OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter represents the total cost over the current path to the destination node. Cost is a positive integer value associated with using a circuit. Routing routes messages (data) along the path between two nodes with the smallest cost. COST is kept on a remote node basis." ::= { phivLevel1RouteEntry 3 } phivLevel1RouteHops OBJECT-TYPE SYNTAX INTEGER (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter represents the number of hops over to a destination node. A hop is Routing value representing the logical distance between two nodes in a network. HOPS is kept on a remote node basis." ::= { phivLevel1RouteEntry 4 } phivLevel1RouteNextNode OBJECT-TYPE DECnet Phase IV MIB Working Group [Page 22] RFC 1559 DECnet Phase IV MIB December 1993 SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only value indicates the next node on the circuit used to get to the node under scrutiny (next hop)." ::= { phivLevel1RouteEntry 5 } -- Additional routing parameters phivRouteCountZeroCount OBJECT-TYPE SYNTAX INTEGER { other (1), reset (2) } ACCESS read-write STATUS mandatory DESCRIPTION "When this value is set to 2, the following objects are set to Zero: phivRouteCountAgedPktLoss, phivRouteCountNodeUnrPktLoss, phivRouteCountOutRngePktLoss, phivRouteCountOverSzePktLoss, phivRouteCountPacketFmtErr, phivRouteCountPtlRteUpdtLoss, and phivRouteCountVerifReject." ::= { routing 23 } phivRouteSystemAddr OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS obsolete DESCRIPTION "DECnet Phase IV node address." ::= { routing 24 } phivRouteRoutingType OBJECT-TYPE SYNTAX INTEGER { routing-III (1), nonrouting-III (2), area (3), routing-IV (4), nonrouting-IV (5) } ACCESS read-write STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 23] RFC 1559 DECnet Phase IV MIB December 1993 "This read-write parameter indicates the type of the executor node. The node-type is one of the following: routing-III nonrouting-III routing-IV ronrouting-IV area A routing node has full routing capability. A nonrouting node contains a subset of the Routing routing modules. The III and IV indicate the DNA phase of the node. Nonrouting nodes can deliver and receive packets to and from any node, but cannot route packets from other nodes through to other nodes. An area node routes between areas. Refer to the Routing specification for details. For adjacent nodes, this is a read-only parameter that indicates the type of the reachable adjacent node. NOTE: The ROUTING-III and NONROUTING-III values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155)" ::= { routing 25 } phivRouteSystemAddress OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-write STATUS mandatory DESCRIPTION "DECnet Phase IV node address." ::= { routing 26 } -- Circuit Group -- The implementation of the Circuit Group is mandatory for -- all systems. -- Circuit Parameters Table phivCircuitParametersTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivCircuitParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about the parameters associated with all circuits currently known." ::= {circuit 1 } DECnet Phase IV MIB Working Group [Page 24] RFC 1559 DECnet Phase IV MIB December 1993 phivCircuitParametersEntry OBJECT-TYPE SYNTAX PhivCircuitParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Parameters information about all circuits currently known." INDEX { phivCircuitIndex } ::= { phivCircuitParametersTable 1 } PhivCircuitParametersEntry ::= SEQUENCE { phivCircuitIndex INTEGER, phivCircuitLineIndex INTEGER, phivCircuitCommonState INTEGER, phivCircuitCommonSubState INTEGER, phivCircuitCommonName DisplayString, phivCircuitExecRecallTimer INTEGER, phivCircuitCommonType INTEGER, phivCircuitService INTEGER, phivCircuitExecCost INTEGER, phivCircuitExecHelloTimer INTEGER } phivCircuitIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index value for each known circuit." ::= { phivCircuitParametersEntry 1 } phivCircuitLineIndex OBJECT-TYPE SYNTAX InterfaceIndex ACCESS read-only STATUS mandatory DESCRIPTION "The line on which this circuit is active. This is DECnet Phase IV MIB Working Group [Page 25] RFC 1559 DECnet Phase IV MIB December 1993 the same as the ifIndex." ::= { phivCircuitParametersEntry 2 } phivCircuitCommonState OBJECT-TYPE SYNTAX INTEGER { on (1), off (2), service (3), cleared (4) } ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the circuit's Network Management operational state. NOTE: These values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155." ::= { phivCircuitParametersEntry 3 } phivCircuitCommonSubState OBJECT-TYPE SYNTAX INTEGER { starting (1), reflecting (2), looping (3), loading (4), dumping (5), triggering (6), autoservice (7), autoloading (8), autodumping (9), autotriggering (10), synchronizing (11), failed (12), running (13) } ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the circuit's Network Management operational and service substate. NOTE: These values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155." ::= { phivCircuitParametersEntry 4 } phivCircuitCommonName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..16)) ACCESS read-only STATUS mandatory DECnet Phase IV MIB Working Group [Page 26] RFC 1559 DECnet Phase IV MIB December 1993 DESCRIPTION "The name of the circuit entry in the table, for example, SVA-0 or in a level 2 router ASYNC-8 or ETHER-1)." ::= { phivCircuitParametersEntry 5 } phivCircuitExecRecallTimer OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This parameter represents the minimum number of seconds to wait before restarting the circuit. A value of 0 indicates not timer is running." ::= { phivCircuitParametersEntry 6 } phivCircuitCommonType OBJECT-TYPE SYNTAX INTEGER { ddcmp-point (1), ddcmp-control (2), ddcmp-tributary (3), x25 (4), ddcmp-dmc (5), ethernet (6), ci (7), qp2-dte20 (8), bisync (9), other (14), fddi (15) } ACCESS read-only STATUS mandatory DESCRIPTION "Represents the type of the circuit. For X.25 circuits, the value must be set to X25. For DDCMP and Ethernet circuits it is read only and is the same value as the protocol of the associated line. NOTE: Values 1 - 5 are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155." ::= { phivCircuitParametersEntry 7 } phivCircuitService OBJECT-TYPE SYNTAX INTEGER { enabled (1), disabled (2) } ACCESS read-write STATUS mandatory DECnet Phase IV MIB Working Group [Page 27] RFC 1559 DECnet Phase IV MIB December 1993 DESCRIPTION "This value indicates whether or not Network Management allows service operations on a circuit. The values for service-control are as follows: ENABLED SERVICE state and/or service functions are allowed. DISABLED SERVICE state and/or service functions are not allowed. NOTE: These values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155." ::= { phivCircuitParametersEntry 8 } phivCircuitExecCost OBJECT-TYPE SYNTAX INTEGER (1..25) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the routing cost of the circuit. Routing sends messages along the path between two nodes having the smallest cost." ::= { phivCircuitParametersEntry 9 } phivCircuitExecHelloTimer OBJECT-TYPE SYNTAX INTEGER (1..8191) ACCESS read-write STATUS mandatory DESCRIPTION "This value determines the frequency of Routing Hello messages sent to the adjacent node on the circuit." ::= { phivCircuitParametersEntry 10 } -- Circuit Counters Table phivCircuitCountTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivCircuitCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about the counters associated with all circuits currently known." ::= { circuit 2 } phivCircuitCountEntry OBJECT-TYPE SYNTAX PhivCircuitCountEntry DECnet Phase IV MIB Working Group [Page 28] RFC 1559 DECnet Phase IV MIB December 1993 ACCESS not-accessible STATUS mandatory DESCRIPTION "Counter information about all circuits currently known" INDEX { phivCircuitIndex } ::= { phivCircuitCountTable 1 } PhivCircuitCountEntry ::= SEQUENCE { phivCircuitCountSecLastZeroed PhivCounter, phivCircuitCountTermPacketsRecd PhivCounter, phivCircuitCountOriginPackSent PhivCounter, phivCircuitCountTermCongLoss PhivCounter, phivCircuitCountCorruptLoss PhivCounter, phivCircuitCountTransitPksRecd PhivCounter, phivCircuitCountTransitPkSent PhivCounter, phivCircuitCountTransitCongestLoss PhivCounter, phivCircuitCountCircuitDown PhivCounter, phivCircuitCountInitFailure PhivCounter, phivCircuitCountAdjDown PhivCounter, phivCircuitCountPeakAdj PhivCounter, phivCircuitCountBytesRecd PhivCounter, phivCircuitCountBytesSent PhivCounter, phivCircuitCountDataBlocksRecd PhivCounter, phivCircuitCountDataBlocksSent PhivCounter, phivCircuitCountUsrBuffUnav PhivCounter } phivCircuitCountSecLastZeroed OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only DECnet Phase IV MIB Working Group [Page 29] RFC 1559 DECnet Phase IV MIB December 1993 STATUS mandatory DESCRIPTION "Number of seconds since the circuit counters for this circuit were last zeroed." ::= { phivCircuitCountEntry 1 } phivCircuitCountTermPacketsRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of terminating packets received on this circuit." ::= { phivCircuitCountEntry 2 } phivCircuitCountOriginPackSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of originating packets sent on this circuit." ::= { phivCircuitCountEntry 3 } phivCircuitCountTermCongLoss OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of terminating congestion losses on this circuit." ::= { phivCircuitCountEntry 4 } phivCircuitCountCorruptLoss OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of corruption losses on this circuit." ::= { phivCircuitCountEntry 5 } phivCircuitCountTransitPksRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of Transit packets received on this circuit." ::= { phivCircuitCountEntry 6 } phivCircuitCountTransitPkSent OBJECT-TYPE DECnet Phase IV MIB Working Group [Page 30] RFC 1559 DECnet Phase IV MIB December 1993 SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of transit packets sent on this circuit." ::= { phivCircuitCountEntry 7 } phivCircuitCountTransitCongestLoss OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of transit congestion losses on this circuit." ::= { phivCircuitCountEntry 8 } phivCircuitCountCircuitDown OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of circuit downs on this circuit." ::= { phivCircuitCountEntry 9 } phivCircuitCountInitFailure OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of Initialization failures on this circuit." ::= { phivCircuitCountEntry 10 } phivCircuitCountAdjDown OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "This counter indicates the number of adjacency losses that result from any of the following: Node listener timeout Invalid data received at node listener Unexpected control (initialization or verification) message received Routing message received with a checksum error Node identification from a routing message or a Hello message that is not the one expected Hello message received indicating that connectivity became one-way Adjacency idled." DECnet Phase IV MIB Working Group [Page 31] RFC 1559 DECnet Phase IV MIB December 1993 ::= { phivCircuitCountEntry 11 } phivCircuitCountPeakAdj OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This counter indicates the maximum number of nodes that are up on the circuit." ::= { phivCircuitCountEntry 12 } phivCircuitCountBytesRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of bytes received on this circuit." ::= { phivCircuitCountEntry 13 } phivCircuitCountBytesSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of bytes sent on this circuit." ::= { phivCircuitCountEntry 14 } phivCircuitCountDataBlocksRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of data blocks received on this circuit." ::= { phivCircuitCountEntry 15 } phivCircuitCountDataBlocksSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of data blocks sent on this circuit." ::= { phivCircuitCountEntry 16 } phivCircuitCountUsrBuffUnav OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 32] RFC 1559 DECnet Phase IV MIB December 1993 "Number of user buffer unavailable errors." ::= { phivCircuitCountEntry 17 } -- Additional Circuit Parameters phivCircuitOrigQueueLimit OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "This parameter indicates the maximum number of originating packets that may be outstanding on this circuit. This does not include route-thru traffic." ::= { circuit 3 } phivCircuitCountZeroCount OBJECT-TYPE SYNTAX INTEGER { other (1), reset (2) } ACCESS read-write STATUS mandatory DESCRIPTION "When this value is set to 2, all of the counters in the Circuit Counter Table are set to zero." ::= { circuit 4 } -- DDCMP Circuit Group -- The implementation of the DDCMP Circuit Group is optional. -- A system can be said to implement this group if and only if -- all objects in this group are implemented. -- DDCMP Parameters Table phivDDCMPCircuitParametersTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivDDCMPCircuitParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about DDCMP circuit parameters." ::= { ddcmp 1} phivDDCMPCircuitParametersEntry OBJECT-TYPE SYNTAX PhivDDCMPCircuitParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 33] RFC 1559 DECnet Phase IV MIB December 1993 "Parameters information about DDCMP circuits currently known." INDEX { phivDDCMPCircuitIndex } ::= { phivDDCMPCircuitParametersTable 1 } PhivDDCMPCircuitParametersEntry ::= SEQUENCE { phivDDCMPCircuitIndex INTEGER, phivDDCMPCircuitAdjNodeAddr INTEGER, phivDDCMPCircuitTributary INTEGER } phivDDCMPCircuitIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index value for each known DDCMP circuit. This is the same value as phivCircuitIndex." ::= { phivDDCMPCircuitParametersEntry 1 } phivDDCMPCircuitAdjNodeAddr OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "The address of the adjacent node." ::= { phivDDCMPCircuitParametersEntry 2 } phivDDCMPCircuitTributary OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the Data Link physical tributary address of the circuit." ::= { phivDDCMPCircuitParametersEntry 3 } -- DDCMP Circuit Counter Table phivDDCMPCircuitCountTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivDDCMPCircuitCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 34] RFC 1559 DECnet Phase IV MIB December 1993 "Information about the DDCMP counters associated with all circuits currently known." ::= { ddcmp 2 } phivDDCMPCircuitCountEntry OBJECT-TYPE SYNTAX PhivDDCMPCircuitCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Counter information about DDCMP circuits now known" INDEX { phivCircuitIndex } ::= { phivDDCMPCircuitCountTable 1 } PhivDDCMPCircuitCountEntry ::= SEQUENCE { phivDDCMPCircuitErrorsInbd PhivCounter, phivDDCMPCircuitErrorsOutbd PhivCounter, phivDDCMPCircuitRmteReplyTimeouts PhivCounter, phivDDCMPCircuitLocalReplyTimeouts PhivCounter, phivDDCMPCircuitRmteBuffErrors PhivCounter, phivDDCMPCircuitLocalBuffErrors PhivCounter, phivDDCMPCircuitSelectIntervalsElap PhivCounter, phivDDCMPCircuitSelectTimeouts PhivCounter } phivDDCMPCircuitErrorsInbd OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of Data errors inbound." ::= { phivDDCMPCircuitCountEntry 1 } phivDDCMPCircuitErrorsOutbd OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of outbound data errors." ::= { phivDDCMPCircuitCountEntry 2 } DECnet Phase IV MIB Working Group [Page 35] RFC 1559 DECnet Phase IV MIB December 1993 phivDDCMPCircuitRmteReplyTimeouts OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of remote reply timeouts." ::= { phivDDCMPCircuitCountEntry 3 } phivDDCMPCircuitLocalReplyTimeouts OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of local Reply timeouts." ::= { phivDDCMPCircuitCountEntry 4 } phivDDCMPCircuitRmteBuffErrors OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of remote reply time out errors." ::= { phivDDCMPCircuitCountEntry 5 } phivDDCMPCircuitLocalBuffErrors OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of local buffer errors." ::= { phivDDCMPCircuitCountEntry 6 } phivDDCMPCircuitSelectIntervalsElap OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Selection intervals that have elapsed." ::= {phivDDCMPCircuitCountEntry 7 } phivDDCMPCircuitSelectTimeouts OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of selection timeouts." ::= {phivDDCMPCircuitCountEntry 8 } DECnet Phase IV MIB Working Group [Page 36] RFC 1559 DECnet Phase IV MIB December 1993 -- DDCMP Line Count Table phivDDCMPLineCountTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivDDCMPLineCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The DDCMP Line Count Table." ::= { ddcmp 3 } phivDDCMPLineCountEntry OBJECT-TYPE SYNTAX PhivDDCMPLineCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "There is one entry in the table for each line." INDEX { phivDDCMPLineCountIndex } ::= { phivDDCMPLineCountTable 1 } PhivDDCMPLineCountEntry ::= SEQUENCE { phivDDCMPLineCountIndex InterfaceIndex, phivDDCMPLineCountDataErrsIn PhivCounter, phivDDCMPLineCountRmteStationErrs PhivCounter, phivDDCMPLineCountLocalStationErrs PhivCounter } phivDDCMPLineCountIndex OBJECT-TYPE SYNTAX InterfaceIndex ACCESS read-only STATUS mandatory DESCRIPTION "The line on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of phivLineIndex. This value is the ifIndex." ::= { phivDDCMPLineCountEntry 1 } phivDDCMPLineCountDataErrsIn OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DECnet Phase IV MIB Working Group [Page 37] RFC 1559 DECnet Phase IV MIB December 1993 DESCRIPTION "Number of data errors inbound." ::= { phivDDCMPLineCountEntry 2 } phivDDCMPLineCountRmteStationErrs OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of remote station errors." ::= { phivDDCMPLineCountEntry 3 } phivDDCMPLineCountLocalStationErrs OBJECT-TYPE SYNTAX PhivCounter (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number of local station errors." ::= { phivDDCMPLineCountEntry 4 } -- DDCMP Multipoint Circuit Control Group -- The implementation of the DDCMP Multipoint Circuit Control -- Group is optional. A system can be said to implement this group -- if and only if all objects in this group are implemented. phivControlSchedTimer OBJECT-TYPE SYNTAX INTEGER (50..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the number of milliseconds between recalculation of tributary polling priorities." DEFVAL { 200 } ::= { control 1 } phivControlDeadTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the number of milliseconds between polls of one of the set of dead tributaries." DEFVAL { 10000 } ::= { control 2 } phivControlDelayTimer OBJECT-TYPE DECnet Phase IV MIB Working Group [Page 38] RFC 1559 DECnet Phase IV MIB December 1993 SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the minimum number of milliseconds to delay between polls. The delay timer limits the effect of a very fast control station on slow tributaries." ::= { control 3 } phivControlStreamTimer OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the number of milliseconds a tributary or a half duplex remote station is allowed to hold the line. NOTE: This parameter can also be applied to half-duplex lines of type DDCMP POINT." DEFVAL { 6000 } ::= { control 4 } -- DDCMP Multipoint Circuit Control Parameters Table phivControlParametersTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivControlParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about control circuit parameters." ::= { control 5 } phivControlParametersEntry OBJECT-TYPE SYNTAX PhivControlParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Parameters information about control circuits currently known." INDEX { phivControlCircuitIndex } ::= { phivControlParametersTable 1 } PhivControlParametersEntry ::= SEQUENCE { phivControlCircuitIndex INTEGER, DECnet Phase IV MIB Working Group [Page 39] RFC 1559 DECnet Phase IV MIB December 1993 phivControlBabbleTimer INTEGER, phivControlMaxBuffs INTEGER, phivControlMaxTransmits INTEGER, phivControlDyingBase INTEGER, phivControlDyingIncrement INTEGER, phivControlDeadThreshold INTEGER, phivControlDyingThreshold INTEGER, phivControlInactTreshold INTEGER, phivControlPollingState INTEGER, phivControlPollingSubState INTEGER, phivControlTransTimer INTEGER } phivControlCircuitIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index value for each known multipoint control circuit. This is the same value as phivCircuitIndex." ::= { phivControlParametersEntry 1 } phivControlBabbleTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the number of milliseconds that a selected tributary or remote half-duplex station is allowed to transmit." DEFVAL { 6000 } ::= { phivControlParametersEntry 2 } phivControlMaxBuffs OBJECT-TYPE SYNTAX INTEGER (1..254) ACCESS read-write DECnet Phase IV MIB Working Group [Page 40] RFC 1559 DECnet Phase IV MIB December 1993 STATUS mandatory DESCRIPTION "This value represents the maximum number of buffers the tributary can use from a common buffer pool. If not set, there is no common buffer pool and buffers are explicitly supplied by the higher level. Count is a decimal integer in the range 1-254." ::= { phivControlParametersEntry 3 } phivControlMaxTransmits OBJECT-TYPE SYNTAX INTEGER (1..255) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum number of data messages that can be transmitted at one time. Count is a decimal integer in the range 1-255." DEFVAL { 4 } ::= { phivControlParametersEntry 4 } phivControlDyingBase OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the base priority to which a tributary is reset each time it has been polled. A separate base can be set for each of the indicated polling states. Base is a decimal integer in the range 0-255. If not set, the defaults are: active, 255; inactive, 0; and dying, 0." ::= { phivControlParametersEntry 5 } phivControlDyingIncrement OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the increment added to the tributary priority each time the scheduling timer expires. If not set, the defaults are: active, 0; inactive, 64; and dying, 16." ::= { phivControlParametersEntry 6 } phivControlDeadThreshold OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-write STATUS mandatory DECnet Phase IV MIB Working Group [Page 41] RFC 1559 DECnet Phase IV MIB December 1993 DESCRIPTION "This value represents the number of times to poll the active, inactive, or dying tributary before changing its polling state to dead because of receive timeouts. Count is a decimal integer in the range 0-255." DEFVAL { 8 } ::= { phivControlParametersEntry 7 } phivControlDyingThreshold OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the number of times to poll the active or inactive tributary before changing its polling state to dying because of receive timeouts. Count is a decimal integer in the range 0-255." DEFVAL { 2 } ::= { phivControlParametersEntry 8 } phivControlInactTreshold OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the number of times to poll the active tributary before changing its polling state to inactive because of no data response. Count is a decimal integer in the range 0-255." DEFVAL { 8 } ::= { phivControlParametersEntry 9 } phivControlPollingState OBJECT-TYPE SYNTAX INTEGER { automatic (1), active (2), inactive (3), dying (4), dead (5) } ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the state of the tributary relative to the multipoint polling algorithm. If not set the default is AUTOMATIC. The possible states are: DECnet Phase IV MIB Working Group [Page 42] RFC 1559 DECnet Phase IV MIB December 1993 AUTOMATIC The tributary's state is allowed to vary according to the operation of the polling algorithm. ACTIVE/INACTIVE/DYING/DEAD The tributary is locked in the specified state. NOTE: These values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155." ::= { phivControlParametersEntry 10 } phivControlPollingSubState OBJECT-TYPE SYNTAX INTEGER { active (1), inactive (2), dying (3), dead (4) } ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the tributary's state as determined by the polling algorithm. This applies only when the polling state is AUTOMATIC and is read-only to Network Management. Polling-substate is one of ACTIVE, INACTIVE, DYING, or DEAD. It is displayed as a tag on the polling state, for example: AUTOMATIC-INACTIVE." ::= { phivControlParametersEntry 11 } phivControlTransTimer OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the number of milliseconds to delay between data message transmits. Milliseconds is a decimal integer in the range 0-65535." DEFVAL { 0 } ::= { phivControlParametersEntry 12 } -- Ethernet Group -- The implementation of the Ethernet Group is mandatory -- for all systems which support ethernet links. DECnet Phase IV MIB Working Group [Page 43] RFC 1559 DECnet Phase IV MIB December 1993 -- Ethernet Parameters Table phivEthLinkParametersTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivEthLinkParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about ethernet link parameters." ::= { ethernet 1} phivEthLinkParametersEntry OBJECT-TYPE SYNTAX PhivEthLinkParametersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Parameter information about ethernet links currently known." INDEX { phivEthLinkIndex } ::= { phivEthLinkParametersTable 1 } PhivEthLinkParametersEntry ::= SEQUENCE { phivEthLinkIndex INTEGER, phivEthDesigRouterNodeAddr PhivAddr, phivEthMaxRouters INTEGER, phivEthRouterPri INTEGER, phivEthHardwareAddr OCTET STRING } phivEthLinkIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The circuit over which this links information is collected. This is the same as phivCircuitIndex." ::= { phivEthLinkParametersEntry 1 } phivEthDesigRouterNodeAddr OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DECnet Phase IV MIB Working Group [Page 44] RFC 1559 DECnet Phase IV MIB December 1993 DESCRIPTION "This value is the address of the designated router." ::= { phivEthLinkParametersEntry 2 } phivEthMaxRouters OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-write STATUS mandatory DESCRIPTION "This parameter is the maximum number of routers (other than the executor itself) allowed on the circuit by Routing for circuits that are owned by the executor node." ::= { phivEthLinkParametersEntry 3 } phivEthRouterPri OBJECT-TYPE SYNTAX INTEGER (0..127) ACCESS read-write STATUS mandatory DESCRIPTION "This parameter is the priority that this router is to have in the selection of designated router for the circuit on circuits that are owned by the executor node." DEFVAL { 64 } ::= { phivEthLinkParametersEntry 4 } phivEthHardwareAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter is the address that is associated with the line device hardware as seen by the DECnet Software. This value is not the same as ifPhysAddress." ::= { phivEthLinkParametersEntry 5 } -- Counters Group -- The implementation of the Counters Group is optional. -- A system can be said to implement this group if and only if -- all objects in this group are implemented. -- Counters Table phivCountersCountTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivCountersCountEntry DECnet Phase IV MIB Working Group [Page 45] RFC 1559 DECnet Phase IV MIB December 1993 ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about ethernet link counters." ::= { counters 1 } phivCountersCountEntry OBJECT-TYPE SYNTAX PhivCountersCountEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Counter information about ethernet links currently known." INDEX { phivCountersIndex } ::= { phivCountersCountTable 1 } PhivCountersCountEntry ::= SEQUENCE { phivCountersIndex InterfaceIndex, phivCountersCountBytesRecd PhivCounter, phivCountersCountBytesSent PhivCounter, phivCountersCountDataBlocksRecd PhivCounter, phivCountersCountDataBlocksSent PhivCounter, phivCountersCountEthUsrBuffUnav PhivCounter, phivCountersCountMcastBytesRecd PhivCounter, phivCountersCountDataBlksRecd PhivCounter, phivCountersCountDataBlksSent PhivCounter, phivCountersCountMcastBlksRecd PhivCounter, phivCountersCountBlksSentDef PhivCounter, phivCountersCountBlksSentSingleCol PhivCounter, phivCountersCountBlksSentMultCol PhivCounter, phivCountersCountSendFailure PhivCounter, phivCountersCountCollDetectFailure PhivCounter, DECnet Phase IV MIB Working Group [Page 46] RFC 1559 DECnet Phase IV MIB December 1993 phivCountersCountReceiveFailure PhivCounter, phivCountersCountUnrecFrameDest PhivCounter, phivCountersCountDataOver PhivCounter, phivCountersCountSysBuffUnav PhivCounter, phivCountersCountUsrBuffUnav PhivCounter } phivCountersIndex OBJECT-TYPE SYNTAX InterfaceIndex ACCESS read-only STATUS mandatory DESCRIPTION "The interface to which these counters apply. This is the same interface as identified by the same value of phivLineIndex. This value is the ifIndex." ::= { phivCountersCountEntry 1 } phivCountersCountBytesRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of bytes received over this link." ::= { phivCountersCountEntry 2 } phivCountersCountBytesSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of bytes sent over this link." ::= { phivCountersCountEntry 3 } phivCountersCountDataBlocksRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS obsolete DESCRIPTION "Number of data blocks received over this link." ::= { phivCountersCountEntry 4 } phivCountersCountDataBlocksSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) DECnet Phase IV MIB Working Group [Page 47] RFC 1559 DECnet Phase IV MIB December 1993 ACCESS read-only STATUS obsolete DESCRIPTION "Number of data blocks sent over this link." ::= { phivCountersCountEntry 5 } phivCountersCountEthUsrBuffUnav OBJECT-TYPE SYNTAX PhivCounter (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of user buffer unavailable errors over this link." ::= { phivCountersCountEntry 6 } phivCountersCountMcastBytesRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of multicast bytes received over this link." ::= { phivCountersCountEntry 7 } phivCountersCountDataBlksRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of data blocks received over this link." ::= { phivCountersCountEntry 8 } phivCountersCountDataBlksSent OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of data blocks sent over this link." ::= { phivCountersCountEntry 9 } phivCountersCountMcastBlksRecd OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of multicast blocks received over this link." ::= { phivCountersCountEntry 10 } phivCountersCountBlksSentDef OBJECT-TYPE DECnet Phase IV MIB Working Group [Page 48] RFC 1559 DECnet Phase IV MIB December 1993 SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of blocks sent, initially deferred over this link." ::= { phivCountersCountEntry 11 } phivCountersCountBlksSentSingleCol OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of blocks sent, single collision over this link." ::= { phivCountersCountEntry 12 } phivCountersCountBlksSentMultCol OBJECT-TYPE SYNTAX PhivCounter (0..2147483647) ACCESS read-only STATUS mandatory DESCRIPTION "Number of blocks sent, multiple collisions over this link." ::= { phivCountersCountEntry 13 } phivCountersCountSendFailure OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of send failures over this link." ::= { phivCountersCountEntry 14 } phivCountersCountCollDetectFailure OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of collision detect check failures over this link." ::= { phivCountersCountEntry 15 } phivCountersCountReceiveFailure OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of receive failures over this link." DECnet Phase IV MIB Working Group [Page 49] RFC 1559 DECnet Phase IV MIB December 1993 ::= { phivCountersCountEntry 16 } phivCountersCountUnrecFrameDest OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of unrecognized frame destinations over this link." ::= { phivCountersCountEntry 17 } phivCountersCountDataOver OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of data overruns over this link." ::= { phivCountersCountEntry 18 } phivCountersCountSysBuffUnav OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of system buffer unavailables over this link." ::= { phivCountersCountEntry 19 } phivCountersCountUsrBuffUnav OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of user buffer unavailables." ::= { phivCountersCountEntry 20 } -- Adjacency Group -- The implementation of the Adjacency Group is mandatory for all -- conformant implementations of this memo. -- The phivAdjTable has been made obsolete it has been replaced with -- the phivAdjNodeTable. phivAdjTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivAdjEntry ACCESS not-accessible STATUS obsolete DESCRIPTION DECnet Phase IV MIB Working Group [Page 50] RFC 1559 DECnet Phase IV MIB December 1993 "The Adjacency Table." ::= { adjacency 1 } phivAdjEntry OBJECT-TYPE SYNTAX PhivAdjEntry ACCESS not-accessible STATUS obsolete DESCRIPTION "There is one entry in the table for each adjacency." INDEX { phivAdjCircuitIndex } ::= { phivAdjTable 1 } PhivAdjEntry ::= SEQUENCE { phivAdjCircuitIndex INTEGER, phivAdjNodeAddr PhivAddr, phivAdjBlockSize INTEGER, phivAdjListenTimer INTEGER (1..65535), phivAdjCircuitEtherServPhysAddr OCTET STRING, phivAdjType INTEGER, phivAdjState INTEGER, phivAdjPriority INTEGER, phivAdjExecListenTimer INTEGER (1..65535) } phivAdjCircuitIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS obsolete DESCRIPTION "A unique index value for each known circuit." ::= { phivAdjEntry 1 } phivAdjNodeAddr OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS obsolete DESCRIPTION "The address of the adjacent node." ::= { phivAdjEntry 2 } DECnet Phase IV MIB Working Group [Page 51] RFC 1559 DECnet Phase IV MIB December 1993 phivAdjBlockSize OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS obsolete DESCRIPTION "This read-only parameter is the block size that was negotiated with the adjacent Routing layer during Routing initialization over a particular circuit. It includes the routing header, but excludes the data link header. This parameter is qualified by ADJACENT NODE." ::= { phivAdjEntry 3 } phivAdjListenTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS obsolete DESCRIPTION "This value determines the maximum number of seconds allowed to elapse before Routing receives some message (either a Hello message or a user message) from the adjacent node on the circuit. It was agreed during Routing initialization with the adjacent Routing layer. This parameter is qualified by ADJACENT NODE." ::= { phivAdjEntry 4 } phivAdjCircuitEtherServPhysAddr OBJECT-TYPE SYNTAX OCTET STRING ( SIZE (6) ) ACCESS read-only STATUS obsolete DESCRIPTION "This parameter indicates the Ethernet physical address of an adjacent node that is being serviced on this circuit. This parameter is a qualifier for SERVICE SUBSTATE." ::= { phivAdjEntry 5 } phivAdjType OBJECT-TYPE SYNTAX INTEGER { routing-III (1), nonrouting-III (2), area (3), routing-IV (4), nonrouting-IV (5) } ACCESS read-only STATUS obsolete DESCRIPTION DECnet Phase IV MIB Working Group [Page 52] RFC 1559 DECnet Phase IV MIB December 1993 "This parameter indicates the type of adjacency. For adjacent nodes, this is a read-only parameter that indicates the type of the reachable adjacent node. NOTE: The routing-III and nonrouting-III values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155)" ::= { phivAdjEntry 6 } phivAdjState OBJECT-TYPE SYNTAX INTEGER { initializing (1), -- Ethernet one-way up (2), -- Ethernet two-way run (3), -- The eight DDCMP/X.25 states circuit-rejected (4), data-link-start (5), routing-layer-initialize (6), routing-layer-verify (7), routing-layer-complete (8), off (9), halt (10) } ACCESS read-only STATUS obsolete DESCRIPTION "This value indicates the state of a router adjacency. On adjacencies over a circuit of type (phivCircuitCommonType) Ethernet, CI, or FDDI, with an adjacent node of type (phivAdjType) ROUTING IV or AREA, this variable is the state of the Ethernet Initialization Layer for this adjacency, and can have values INITIALIZING or UP. (See Section 9.1.1 of DECnet Phase IV Routing Layer Functional Specification.) On adjacencies over a circuit of type (phivCircuitCommonType) Ethernet, CI, or FDDI, with an adjacent node of type (phivAdjType) NONROUTING IV, this variable will always take on the value UP. On adjacencies over a circuit of type (phivCircuitCommonType) DDCMP POINT, DDCMP CONTROL, DDCMP TRIBUTARY, DDCMP DMC, or X.25, this variable is the state of the Routing Layer Initialization Circuit State. (See section 7.3, ibid.) It can have values between RUN and HALT. On adjacencies over a circuit of type (phivCircuitCommonType) OTHER, this variable may be DECnet Phase IV MIB Working Group [Page 53] RFC 1559 DECnet Phase IV MIB December 1993 used in a manner consistent with the Initialization Layer used on that circuit." ::= { phivAdjEntry 7 } phivAdjPriority OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS obsolete DESCRIPTION "Priority assigned by the adjacent node for this circuit." ::= { phivAdjEntry 8 } phivAdjExecListenTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS obsolete DESCRIPTION "This read-only value determines the maximum number of seconds allowed to elapse before Routing receives some message (either a Hello message or a user message) from the adjacent node on the circuit. It was agreed during Routing initialization with the adjacent Routing layer." ::= { phivAdjEntry 9 } -- New Adjacency Table this replaces the phivAdjTable. phivAdjNodeTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivAdjNodeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Adjacent Node Table." ::= { adjacency 2 } phivAdjNodeEntry OBJECT-TYPE SYNTAX PhivAdjNodeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "There is one entry in the table for each adjacency." INDEX { phivAdjNodeCircuitIndex, phivAdjAddr } ::= { phivAdjNodeTable 1 } PhivAdjNodeEntry ::= SEQUENCE { phivAdjNodeCircuitIndex INTEGER, DECnet Phase IV MIB Working Group [Page 54] RFC 1559 DECnet Phase IV MIB December 1993 phivAdjAddr PhivAddr, phivAdjNodeBlockSize INTEGER, phivAdjNodeListenTimer INTEGER, phivAdjNodeCircuitEtherServPhysAddr OCTET STRING, phivAdjNodeType INTEGER, phivAdjNodeState INTEGER, phivAdjNodePriority INTEGER } phivAdjNodeCircuitIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index value for each known circuit. This value is the same as phivCircuitIndex and identifies the circuit over which the adjacency is realized." ::= { phivAdjNodeEntry 1 } phivAdjAddr OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "The address of the adjacent node." ::= { phivAdjNodeEntry 2 } phivAdjNodeBlockSize OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This read-only parameter is the block size that was negotiated with the adjacent Routing layer during Routing initialization over a particular circuit. It includes the routing header, but excludes the data link header. This parameter is qualified by ADJACENT NODE." ::= { phivAdjNodeEntry 3 } phivAdjNodeListenTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) DECnet Phase IV MIB Working Group [Page 55] RFC 1559 DECnet Phase IV MIB December 1993 ACCESS read-only STATUS mandatory DESCRIPTION "This value determines the maximum number of seconds allowed to elapse before Routing receives some message (either a Hello message or a user message) from the adjacent node on the circuit. It was agreed during Routing initialization with the adjacent Routing layer. This parameter is qualified by ADJACENT NODE." ::= { phivAdjNodeEntry 4 } phivAdjNodeCircuitEtherServPhysAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "This parameter indicates the Ethernet physical address of an adjacent node that is being serviced on this circuit. This parameter is a qualifier for SERVICE SUBSTATE." ::= { phivAdjNodeEntry 5 } phivAdjNodeType OBJECT-TYPE SYNTAX INTEGER { routing-III (1), nonrouting-III (2), area (3), routing-IV (4), nonrouting-IV (5) } ACCESS read-only STATUS mandatory DESCRIPTION "This parameter indicates the type of adjacency. For adjacent nodes, this is a read-only parameter that indicates the type of the reachable adjacent node. NOTE: The routing-III and nonrouting-III values are incremented by one compared to the standard DECnet values in order to maintain compliance with RFC 1155)" ::= { phivAdjNodeEntry 6 } phivAdjNodeState OBJECT-TYPE SYNTAX INTEGER { initializing (1), -- Ethernet one-way up (2), -- Ethernet two-way run (3), -- The eight DDCMP/X.25 states circuit-rejected (4), DECnet Phase IV MIB Working Group [Page 56] RFC 1559 DECnet Phase IV MIB December 1993 data-link-start (5), routing-layer-initialize (6), routing-layer-verify (7), routing-layer-complete (8), off (9), halt (10) } ACCESS read-only STATUS mandatory DESCRIPTION "This value indicates the state of a router adjacency. On adjacencies over a circuit of type (phivCircuitCommonType) Ethernet, CI, or FDDI, with an adjacent node of type (phivAdjNodeType) ROUTING IV or AREA, this variable is the state of the Ethernet Initialization Layer for this adjacency, and can have values INITIALIZING or UP. (See Section 9.1.1 of DECnet Phase IV Routing Layer Functional Specification.) On adjacencies over a circuit of type (phivCircuitCommonType) Ethernet, CI, or FDDI, with an adjacent node of type (phivAdjNodeType) NONROUTING IV, this variable will always take on the value UP. On adjacencies over a circuit of type (phivCircuitCommonType) DDCMP POINT, DDCMP CONTROL, DDCMP TRIBUTARY, DDCMP DMC, or X.25, this variable is the state of the Routing Layer Initialization Circuit State. (See section 7.3, ibid.) It can have values between RUN and HALT. On adjacencies over a circuit of type (phivCircuitCommonType) OTHER, this variable may be used in a manner consistent with the Initialization Layer used on that circuit." ::= { phivAdjNodeEntry 7 } phivAdjNodePriority OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Priority assigned by the adjacent node for this circuit." ::= { phivAdjNodeEntry 8 } DECnet Phase IV MIB Working Group [Page 57] RFC 1559 DECnet Phase IV MIB December 1993 -- Line Group -- The implementation of the Line Group is mandatory for all -- conformant implementations of this memo. phivLineTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivLineEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Line Table." ::= { line 1 } phivLineEntry OBJECT-TYPE SYNTAX PhivLineEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "There is one entry in the table for each line." INDEX { phivLineIndex } ::= { phivLineTable 1 } PhivLineEntry ::= SEQUENCE { phivLineIndex InterfaceIndex, phivLineName DisplayString, phivLineState INTEGER, phivLineSubstate INTEGER, phivLineService INTEGER, phivLineDevice DisplayString, phivLineReceiveBuffs INTEGER, phivLineProtocol INTEGER, phivLineServiceTimer INTEGER, phivLineMaxBlock INTEGER } phivLineIndex OBJECT-TYPE SYNTAX InterfaceIndex DECnet Phase IV MIB Working Group [Page 58] RFC 1559 DECnet Phase IV MIB December 1993 ACCESS read-only STATUS mandatory DESCRIPTION "The line on which this entry's equivalence is effective. This is the same as the ifIndex." ::= { phivLineEntry 1 } phivLineName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..16)) ACCESS read-only STATUS mandatory DESCRIPTION "The name of the line on this row of the table." ::= { phivLineEntry 2 } phivLineState OBJECT-TYPE SYNTAX INTEGER { on (1), off (2), service (3), cleared (4) } ACCESS read-only STATUS mandatory DESCRIPTION "This value represents Network Management operational state. NOTE that these values are incremented by one compared to the standard DECnet values." ::= { phivLineEntry 3 } phivLineSubstate OBJECT-TYPE SYNTAX INTEGER { starting (1), reflecting (2), looping (3), loading (4), dumping (5), triggering (6), auto-service (7), auto-loading (8), auto-dumping (9), auto-triggering (10), synchronizing (11), failed (12), running (13) } ACCESS read-only DECnet Phase IV MIB Working Group [Page 59] RFC 1559 DECnet Phase IV MIB December 1993 STATUS mandatory DESCRIPTION "This value represents the line's read-only Network Management substate. NOTE that these values are incremented by one compared to the standard DECnet values." ::= { phivLineEntry 4 } phivLineService OBJECT-TYPE SYNTAX INTEGER { starting (1), reflecting (2), looping (3), other (4) } ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the line's read-only Network Management service. NOTE that these values are incremented by one compared to the standard DECnet values and OTHER is a new addition." ::= { phivLineEntry 5 } phivLineDevice OBJECT-TYPE SYNTAX DisplayString (SIZE (0..16)) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the Physical Link device to be used on the line." ::= { phivLineEntry 6 } phivLineReceiveBuffs OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the number of receive buffers reserved for the line. It is a decimal number in the range 0-65535. 0 is supported for those vendors that do not reserve buffers on a per line basis and use a pool of buffers that can be used by any line." ::= { phivLineEntry 7 } phivLineProtocol OBJECT-TYPE SYNTAX INTEGER { ddcmp-point (1), DECnet Phase IV MIB Working Group [Page 60] RFC 1559 DECnet Phase IV MIB December 1993 ddcmp-control (2), ddcmp-tributary (3), reserved (4), ddcmp-dmc (5), olapb (6), ethernet (7), ci (8), qp2 (9), other (14), fddi (15) } ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the protocol used on the line device. Note that these values are incremented by one compared to the standard DECnet values." ::= { phivLineEntry 8 } phivLineServiceTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the amount of time in milliseconds allowed to elapse before a Data Link receive request completes while doing service operations." ::= { phivLineEntry 9 } phivLineMaxBlock OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the Data Link maximum block size on the line." ::= { phivLineEntry 10 } -- Non Broadcast Line Group -- The implementation of the Non Broadcast Line Group is optional. -- A system can be said to implement this group if and only if -- all objects in this group are implemented. phivNonBroadcastTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivNonBroadcastEntry ACCESS not-accessible DECnet Phase IV MIB Working Group [Page 61] RFC 1559 DECnet Phase IV MIB December 1993 STATUS mandatory DESCRIPTION "The Non Broadcast Table." ::= { nonBroadcastLine 1 } phivNonBroadcastEntry OBJECT-TYPE SYNTAX PhivNonBroadcastEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "There is one entry in the table for each Non Broadcast line." INDEX { phivNonBroadcastIndex } ::= { phivNonBroadcastTable 1 } PhivNonBroadcastEntry ::= SEQUENCE { phivNonBroadcastIndex InterfaceIndex, phivNonBroadcastController INTEGER, phivNonBroadcastDuplex INTEGER, phivNonBroadcastClock INTEGER, phivNonBroadcastRetransmitTimer INTEGER } phivNonBroadcastIndex OBJECT-TYPE SYNTAX InterfaceIndex ACCESS read-only STATUS mandatory DESCRIPTION "The Non Broadcast line on which this entry's equivalence is effective. This is the same value as the ifIndex." ::= { phivNonBroadcastEntry 1 } phivNonBroadcastController OBJECT-TYPE SYNTAX INTEGER { normal (1), loopback (2), other (3) } ACCESS read-only STATUS mandatory DESCRIPTION DECnet Phase IV MIB Working Group [Page 62] RFC 1559 DECnet Phase IV MIB December 1993 "This value represents the Physical Link hardware controller mode for the line device. The values for controller-mode are: NORMAL For normal controller operating mode. LOOPBACK For software controllable loopback of the controller. On those devices that can support this mode, it causes all transmitted messages to be looped back from within the controller itself. This is accomplished without any manual intervention other than the setting of this parameter value. OTHER indicates function is not supported Note that these values are incremented by one compared to the standard DECnet values." ::= { phivNonBroadcastEntry 2 } phivNonBroadcastDuplex OBJECT-TYPE SYNTAX INTEGER { full (1), half (2) } ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the Physical Link hardware duplex mode of the line device. The possible modes are: FULL Full-duplex HALF Half-duplex Note that these values are incremented by one compared to the standard DECnet values." ::= { phivNonBroadcastEntry 3 } phivNonBroadcastClock OBJECT-TYPE SYNTAX INTEGER { external (1), internal (2), other (3) } ACCESS read-only STATUS mandatory DESCRIPTION "This value represents the Physical Link hardware clock mode for the line device. The values for clock-mode are: DECnet Phase IV MIB Working Group [Page 63] RFC 1559 DECnet Phase IV MIB December 1993 INTERNAL For software controllable loopback use of the clock. On those devices that can support this mode, it causes the device to supply a clock signal such that a transmitted messages can be looped back from outside the device. This may require manual intervention other than the setting of this parameter value. For example, the operator may have to connect a loopback plug in place of the normal line. EXTERNAL For normal clock operating mode, where the clock signal is supplied externally to the controller. Note that these values are incremented by one compared to the standard DECnet values." ::= { phivNonBroadcastEntry 4 } phivNonBroadcastRetransmitTimer OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents number of milliseconds before the Data Link retransmits a block on the line. On half-duplex lines, this parameter is the select timer." DEFVAL { 3000 } ::= { phivNonBroadcastEntry 5 } -- Area Parameters Group -- The implementation of the Area Parameters Group is mandatory -- for all systems which implement level 2 routing. phivAreaTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivAreaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table of information kept on all areas known to this unit." ::= { area 1 } phivAreaEntry OBJECT-TYPE SYNTAX PhivAreaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The area routing information." INDEX { phivAreaNum } DECnet Phase IV MIB Working Group [Page 64] RFC 1559 DECnet Phase IV MIB December 1993 ::= { phivAreaTable 1 } PhivAreaEntry ::= SEQUENCE { phivAreaNum INTEGER, phivAreaState INTEGER, phivAreaCost Gauge, phivAreaHops INTEGER, phivAreaNextNode PhivAddr, phivAreaCircuitIndex INTEGER } phivAreaNum OBJECT-TYPE SYNTAX INTEGER (0..64) ACCESS read-only STATUS mandatory DESCRIPTION "This value indicates the area number of this entry." ::= { phivAreaEntry 1 } phivAreaState OBJECT-TYPE SYNTAX INTEGER { reachable (4), unreachable (5) } ACCESS read-only STATUS mandatory DESCRIPTION "This value indicates the state of the area" ::= { phivAreaEntry 2 } phivAreaCost OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The total cost over the current path to the destination area. Cost is a value associated with using a circuit. Routing routes messages (data) along the path between 2 areas with the smallest cost." ::= { phivAreaEntry 3 } DECnet Phase IV MIB Working Group [Page 65] RFC 1559 DECnet Phase IV MIB December 1993 phivAreaHops OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The number of hops to a destination area. A hop is the routing value representing the logical distance between two areas in network." ::= { phivAreaEntry 4 } phivAreaNextNode OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "The next node on the circuit used to get to the area under scrutiny." ::= { phivAreaEntry 5 } phivAreaCircuitIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index value for each known circuit." ::= { phivAreaEntry 6 } -- Additional Area Parameters phivAreaMaxCost OBJECT-TYPE SYNTAX INTEGER (1..1022) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum total path cost allowed from the executor to any other level 2 routing node. The AREA MAXIMUM COST number is decimal in the range 1-1022. This parameter is only applicable if the executor node is of type AREA." ::= { area 2 } phivAreaMaxHops OBJECT-TYPE SYNTAX INTEGER (1..30) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the maximum number of routing hops DECnet Phase IV MIB Working Group [Page 66] RFC 1559 DECnet Phase IV MIB December 1993 allowable from the executor to any other level 2 routing node. This parameter is only applicable if the executor node is of type AREA." ::= { area 3 } phivRouteMaxArea OBJECT-TYPE SYNTAX INTEGER (1..63) ACCESS read-write STATUS mandatory DESCRIPTION "This value represents the largest area number and, therefore, number of areas that can be known about by the executor node's Routing. This parameter is only applicable if the executor node is of type AREA." ::= { area 4 } END 6. Changes from RFC 1289 Several changes have been made to this document. These changes include: (1) Ranges have been added on all PhivCounter types to remove ambiguity which might otherwise have occurred. (2) Made clear that all indexes start with 1 and count up. (3) Spelling and typographic changes. (4) Changes to improve consistency with other documents including the removal of subranging within definitions of sequences defining table entries. (5) Updated compliance text to conform to current practice. (6) Fixed discrepancy between description and range clause for phivControlMaxBuffs. (7) Added a space that was missing between SYNTAX and INTEGER in the phivRouteType object. (8) Both phivRouteType and phivRouteSystemAddr have been made obsolete. They have been replaced with phivRouteRoutingType and phivRouteSystemAddress which are both read-write objects. DECnet Phase IV MIB Working Group [Page 67] RFC 1559 DECnet Phase IV MIB December 1993 (9) A new Adjacency table has been added as adjacency 2. This table is identical to the original except that phivAdjExecListenTimer was not carried into the new version. The existing Adjacency table and all objects in it have been made obsolete. The index to the new table is phivAdjNodeCircuitIndex and phivAdjAddr. (10) Objects phivCountersCountDataBlocksRecd and phivCountersCountDataBlocksSent have both been made obsolete since the DESCRIPTION information overlapped with the phivCountersCountDataBlksRecd and phivCountersCountDataBlksSent objects which have been retained. (11) The following groups have been moved from mandatory to optional status: Session, End, DDCMP, DDCMP Multipoint Circuit Control, Counters, and Non Broadcast Line. 7. Acknowledgements This document is the result of work undertaken the by DECnet Phase IV MIB working group. In addition, the special contributions and comments of the following members are also acknowledged: Chris Chiotasso, Sparticus Steven Hunter, National Energy Research Supercomputer Center, Lawrence Livermore National Laboratory 8. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988. [2] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [3] 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. [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. DECnet Phase IV MIB Working Group [Page 68] RFC 1559 DECnet Phase IV MIB December 1993 [5] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [6] Cook, J., Editor, "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 1284, Chipcom Corporation, December 1991. [7] Digital Equipment Corporation, "DECnet-ULTRIX NCP Command Reference", Digital Equipment Corporation, Maynard, Massachusetts. [8] Digital Equipment Corporation, "DECnet-ULTRIX USE Guide", Digital Equipment Corporation, Maynard, Massachusetts. [9] Digital Equipment Corporation, "DECnet DIGITAL Network Architecture, Network Management Functional Specification", Version 4.0.0. Digital Equipment Corporation, Maynard, Massachusetts, July 1983. [10] Digital Equipment Corporation, "DECnet DIGITAL Network Architecture, Routing Layer Functional Specification", Version 2.0.0. Digital Equipment Corporation, Maynard, Massachusetts, May 1983. 9. Security Considerations Security issues are not discussed in this memo. 10. Author's Address Jon Saperia Digital Equipment Corporation 153 Taylor Street M/S TAY2-2/B5 Littleton, MA 01460 Phone: +1 508-952-3171 EMail: saperia@tay.dec.com DECnet Phase IV MIB Working Group [Page 69] snmp-mibs-downloader-1.1/mibrfcs/rfc1567.txt0000644000000000000000000010136711402176071015574 0ustar Network Working Group G. Mansfield Request for Comments: 1567 AIC Systems Laboratory Category: Standards Track S. Kille ISODE Consortium January 1994 X.500 Directory Monitoring MIB 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. Abstract This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. Table of Contents 1. The SNMPv2 Network Management Framework ....................... 1 2. MIB Model for DSA Management ................................. 2 3. The DSA functions and operations .............................. 2 4. MIB design .................................................... 3 5. The Directory Monitoring MIB .................................. 3 6. Acknowledgements ..............................................17 7. References ....................................................17 Security Considerations ...........................................18 Authors' Addresses ................................................18 1. The SNMPv2 Network Management Framework The major components of the SNMPv2 Network Management framework are described in the documents listed below. o RFC 1442 [1] defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects (MO) for the Internet suite of protocols. Mansfield & Kille [Page 1] RFC 1567 X.500 Directory Monitoring MIB January 1994 o RFC 1445 [3] defines the administrative and other architectural aspects of the management framework. o RFC 1448 [4] defines the protocol used for network access to managed objects. The framework is adaptable/extensible by defining new MIBs to suit the requirements of specific applications/protocols/situations. Managed objects are accessed via a virtual information store, the 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, which is 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, often a textual string, termed the descriptor, is used to refer to the object type. 2. MIB Model for DSA Management A DSA-manager may wish to monitor several aspects of the operational DSA. He/she may want to know the process related aspects-the resource utilization of the operational DSA; the network service related aspects e.g., inbound-associations, outbound-associations, operational status, and finally the information specific to the DSA application - its operations and performance. The MIB defined in this document covers the portion which is specific to the DSA-application. The network service related part of the MIB, and the host-resources related part of the MIB, as well other parts of interest to a Manager monitoring the DSA-application, are covered in separate documents [6] [7]. 3. The DSA functions and operations The Directory System Agent [DSA], a component of the OSI-Directory [5] [9], is an application process. It provides access to the Directory Information Base [DIB] to Directory User Agents [DUA] and/or other DSAs. Functionally , a User [DUA] and the Directory are bound together for a period of time at an access point to the Directory [DSA]. A DSA may use information stored in its local database or interact with (chain the request to) other DSAs to service requirements. Alternatively, a DSA may return a reference to another DSA. The local database of a DSA consists of the part of the DIT that is mastered by the DSA, the part of the DIT for which it keeps slave copies and cached information that is gathered during the operation Mansfield & Kille [Page 2] RFC 1567 X.500 Directory Monitoring MIB January 1994 of the DSA. The specific operations carried out by the DSA are: Read, Compare, AddEntry, ModifyEntry, ModifyRDN, RemoveEntry, List, Search. There is also the special operation Abandon. In response to requests results and/or errors are returned by the DSA. 4. MIB design The basic principle has been to keep the MIB as simple as possible. The Managed objects included in the MIB are divided into three tables - dsaOpsTable, dsaEntryTable and dsaIntTable. - The dsaOpsTable provides summary statistics on the accesses, operations and errors. - The dsaEntriesTable provides summary statistics on the entries held by the DSA and on cache performance. - The dsaIntTable provides some useful information on the interaction of the monitored DSA with peer DSAs. There are references to the Directory itself for static information pertaining to the DSA. These references are in the form of "Directory Distinguished Name" [8] of the corresponding object. It is intended that DSA management applications will use these references to obtain further related information on the objects of interest. 5. The Directory Monitoring MIB DSA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI DisplayString, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC mib-2 FROM RFC1213-MIB applIndex, DistinguishedName FROM APPLICATION-MIB; dsaMIB MODULE-IDENTITY LAST-UPDATED "9311250000Z" ORGANIZATION "IETF Mail and Directory Management Working Group" Mansfield & Kille [Page 3] RFC 1567 X.500 Directory Monitoring MIB January 1994 CONTACT-INFO " Glenn Mansfield Postal: AIC Systems Laboratory 6-6-3, Minami Yoshinari Aoba-ku, Sendai, 989-32 JP Tel: +81 22 279 3310 Fax: +81 22 279 3640 E-Mail: glenn@aic.co.jp" DESCRIPTION " The MIB module for monitoring Directory System Agents." ::= { mib-2 29 } dsaOpsTable OBJECT-TYPE SYNTAX SEQUENCE OF DsaOpsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The table holding information related to the DSA operations." ::= {dsaMIB 1} dsaOpsEntry OBJECT-TYPE SYNTAX DsaOpsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entry containing operations related statistics for a DSA." INDEX { applIndex } ::= {dsaOpsTable 1} DsaOpsEntry ::= SEQUENCE { -- Bindings dsaAnonymousBinds Counter32, dsaUnauthBinds Counter32, dsaSimpleAuthBinds Counter32, dsaStrongAuthBinds Counter32, dsaBindSecurityErrors Counter32, Mansfield & Kille [Page 4] RFC 1567 X.500 Directory Monitoring MIB January 1994 -- In-coming operations dsaInOps Counter32, dsaReadOps Counter32, dsaCompareOps Counter32, dsaAddEntryOps Counter32, dsaRemoveEntryOps Counter32, dsaModifyEntryOps Counter32, dsaModifyRDNOps Counter32, dsaListOps Counter32, dsaSearchOps Counter32, dsaOneLevelSearchOps Counter32, dsaWholeTreeSearchOps Counter32, -- Out going operations dsaReferrals Counter32, dsaChainings Counter32, -- Errors dsaSecurityErrors Counter32, dsaErrors Counter32 } dsaAnonymousBinds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of anonymous binds to this DSA from DUAs since application start." ::= {dsaOpsEntry 1} Mansfield & Kille [Page 5] RFC 1567 X.500 Directory Monitoring MIB January 1994 dsaUnauthBinds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of un-authenticated binds to this DSA since application start." ::= {dsaOpsEntry 2} dsaSimpleAuthBinds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of binds to this DSA that were authenticated using simple authentication procedures since application start." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 8.1.2.1.1." ::= {dsaOpsEntry 3} dsaStrongAuthBinds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of binds to this DSA that were authenticated using the strong authentication procedures since application start. This includes the binds that were authenticated using external authentication procedures." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Sections 8.1.2.1.2 & 8.1.2.1.3." ::= {dsaOpsEntry 4} dsaBindSecurityErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of bind operations that have been rejected by this DSA due to inappropriateAuthentication or invalidCredentials." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 12.7.2" Mansfield & Kille [Page 6] RFC 1567 X.500 Directory Monitoring MIB January 1994 ::= {dsaOpsEntry 5} dsaInOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations forwarded to this DSA from DUAs or other DSAs since application start up." ::= {dsaOpsEntry 6} dsaReadOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of read operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 9.1." ::= {dsaOpsEntry 7} dsaCompareOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of compare operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 9.2." ::= {dsaOpsEntry 8} dsaAddEntryOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of addEntry operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 11.1." ::= {dsaOpsEntry 9} Mansfield & Kille [Page 7] RFC 1567 X.500 Directory Monitoring MIB January 1994 dsaRemoveEntryOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of removeEntry operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 11.2." ::= {dsaOpsEntry 10} dsaModifyEntryOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of modifyEntry operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 11.3." ::= {dsaOpsEntry 11} dsaModifyRDNOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of modifyRDN operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 11.4." ::= {dsaOpsEntry 12} dsaListOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of list operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 10.1." ::= {dsaOpsEntry 13} Mansfield & Kille [Page 8] RFC 1567 X.500 Directory Monitoring MIB January 1994 dsaSearchOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of search operations- baseObjectSearches, oneLevelSearches and subTreeSearches, serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 10.2." ::= {dsaOpsEntry 14} dsaOneLevelSearchOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of oneLevelSearch operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 10.2.2.2." ::= {dsaOpsEntry 15} dsaWholeTreeSearchOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of wholeTreeSearch operations serviced by this DSA since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 10.2.2.2." ::= {dsaOpsEntry 16} dsaReferrals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of referrals returned by this DSA in response to requests for operations since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 12.6." ::= {dsaOpsEntry 17} Mansfield & Kille [Page 9] RFC 1567 X.500 Directory Monitoring MIB January 1994 dsaChainings OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations forwarded by this DSA to other DSAs since application startup." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.518, 1988: Section 14." ::= {dsaOpsEntry 18} dsaSecurityErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations forwarded to this DSA which did not meet the security requirements. " REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Section 12.7." ::= {dsaOpsEntry 19} dsaErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that could not be serviced due to errors other than security errors, and referrals. A partially serviced operation will not be counted as an error. The errors include NameErrors, UpdateErrors, Attribute errors and ServiceErrors." REFERENCE " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988: Sections 12.4, 12.5, 12.8 & 12.9." ::= {dsaOpsEntry 20} -- Entry statistics/Cache performance dsaEntriesTable OBJECT-TYPE SYNTAX SEQUENCE OF DsaEntriesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The table holding information related to the Mansfield & Kille [Page 10] RFC 1567 X.500 Directory Monitoring MIB January 1994 entry statistics and cache performance of the DSAs." ::= {dsaMIB 2} dsaEntriesEntry OBJECT-TYPE SYNTAX DsaEntriesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entry containing statistics pertaining to entries held by a DSA." INDEX { applIndex } ::= {dsaEntriesTable 1} DsaEntriesEntry ::= SEQUENCE { dsaMasterEntries Gauge32, dsaCopyEntries Gauge32, dsaCacheEntries Gauge32, dsaCacheHits Counter32, dsaSlaveHits Counter32 } dsaMasterEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of entries mastered in the DSA." ::= {dsaEntriesEntry 1} dsaCopyEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of entries for which systematic (slave) copies are maintained in the DSA." ::= {dsaEntriesEntry 2} dsaCacheEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION Mansfield & Kille [Page 11] RFC 1567 X.500 Directory Monitoring MIB January 1994 " Number of entries cached (non-systematic copies) in the DSA. This will include the entries that are cached partially. The negative cache is not counted." ::= {dsaEntriesEntry 3} dsaCacheHits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that were serviced from the locally held cache since application startup." ::= {dsaEntriesEntry 4} dsaSlaveHits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that were serviced from the locally held object replications [ shadow entries] since application startup." ::= {dsaEntriesEntry 5} -- The dsaIntTable contains statistical data on the peer DSAs -- with which the monitored DSAs [attempt to] interact. This -- table will provide a useful insight into the effect of -- neighbours on the DSA performance. -- The table keeps track of the last "N" DSAs with which the -- monitored DSAs has interacted [attempted to interact], -- where "N" is a locally-defined constant. dsaIntTable OBJECT-TYPE SYNTAX SEQUENCE OF DsaIntEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Each row of this table contains some details related to the history of the interaction of the monitored DSAs with their respective peer DSAs." ::= { dsaMIB 3 } dsaIntEntry OBJECT-TYPE SYNTAX DsaIntEntry MAX-ACCESS not-accessible Mansfield & Kille [Page 12] RFC 1567 X.500 Directory Monitoring MIB January 1994 STATUS current DESCRIPTION " Entry containing interaction details of a DSA with a peer DSA." INDEX { applIndex,dsaIntIndex } ::= { dsaIntTable 1 } DsaIntEntry ::= SEQUENCE { dsaIntIndex INTEGER, dsaName DistinguishedName, dsaTimeOfCreation TimeStamp, dsaTimeOfLastAttempt TimeStamp, dsaTimeOfLastSuccess TimeStamp, dsaFailuresSinceLastSuccess Counter32, dsaFailures Counter32, dsaSuccesses Counter32 } dsaIntIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION " Together with applIndex it forms the unique key to identify the conceptual row which contains useful info on the (attempted) interaction between the DSA (referred to by applIndex) and a peer DSA." ::= {dsaIntEntry 1} dsaName OBJECT-TYPE SYNTAX DistinguishedName MAX-ACCESS read-only STATUS current DESCRIPTION " Distinguished Name of the peer DSA to which this entry pertains." ::= {dsaIntEntry 2} dsaTimeOfCreation OBJECT-TYPE SYNTAX TimeStamp Mansfield & Kille [Page 13] RFC 1567 X.500 Directory Monitoring MIB January 1994 MAX-ACCESS read-only STATUS current DESCRIPTION " The value of sysUpTime when this row was created. If the entry was created before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaIntEntry 3} dsaTimeOfLastAttempt OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION " The value of sysUpTime when the last attempt was made to contact this DSA. If the last attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaIntEntry 4} dsaTimeOfLastSuccess OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION " The value of sysUpTime when the last attempt made to contact this DSA was successful. If there have been no successful attempts this entry will have a value of zero. If the last successful attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaIntEntry 5} dsaFailuresSinceLastSuccess OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " The number of failures since the last time an attempt to contact this DSA was successful. If there has been no successful attempts, this counter will contain the number of failures since this entry was created." ::= {dsaIntEntry 6} dsaFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Mansfield & Kille [Page 14] RFC 1567 X.500 Directory Monitoring MIB January 1994 STATUS current DESCRIPTION " Cumulative failures since the creation of this entry." ::= {dsaIntEntry 7} dsaSuccesses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Cumulative successes since the creation of this entry." ::= {dsaIntEntry 8} -- Conformance information dsaConformance OBJECT IDENTIFIER ::= { dsaMIB 4 } dsaGroups OBJECT IDENTIFIER ::= { dsaConformance 1 } dsaCompliances OBJECT IDENTIFIER ::= { dsaConformance 2 } -- Compliance statements dsaOpsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the DSA-MIB for monitoring DSA operations." MODULE -- this module MANDATORY-GROUPS { dsaOpsGroup } ::= { dsaCompliances 1 } dsaEntryCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the DSA-MIB for monitoring DSA operations, entry statistics and cache performance." MODULE -- this module MANDATORY-GROUPS { dsaOpsGroup,dsaEntryGroup } Mansfield & Kille [Page 15] RFC 1567 X.500 Directory Monitoring MIB January 1994 ::= { dsaCompliances 2 } dsaIntCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION " The compliance statement for SNMPv2 entities which implement the DSA-MIB for monitoring DSA operations and the interaction of the DSA with peer DSAs." MODULE -- this module MANDATORY-GROUPS { dsaOpsGroup, dsaIntGroup } ::= { dsaCompliances 3 } -- Units of conformance dsaOpsGroup OBJECT-GROUP OBJECTS { dsaAnonymousBinds, dsaUnauthBinds, dsaSimpleAuthBinds, dsaStrongAuthBinds, dsaBindSecurityErrors,dsaInOps, dsaReadOps, dsaCompareOps, dsaAddEntryOps, dsaRemoveEntryOps, dsaModifyEntryOps, dsaModifyRDNOps, dsaListOps, dsaSearchOps, dsaOneLevelSearchOps, dsaWholeTreeSearchOps,dsaReferrals, dsaChainings, dsaSecurityErrors, dsaErrors} STATUS current DESCRIPTION " A collection of objects for monitoring the DSA operations." ::= { dsaGroups 1 } dsaEntryGroup OBJECT-GROUP OBJECTS {dsaMasterEntries, dsaCopyEntries, dsaCacheEntries, dsaCacheHits, dsaSlaveHits} STATUS current DESCRIPTION " A collection of objects for monitoring the DSA entry statistics and cache performance." ::= { dsaGroups 2 } dsaIntGroup OBJECT-GROUP OBJECTS { dsaName, dsaTimeOfCreation, dsaTimeOfLastAttempt, dsaTimeOfLastSuccess,dsaFailuresSinceLastSuccess,dsaFailures, dsaSuccesses} STATUS current Mansfield & Kille [Page 16] RFC 1567 X.500 Directory Monitoring MIB January 1994 DESCRIPTION " A collection of objects for monitoring the DSA's interaction with peer DSAs." ::= { dsaGroups 3 } END 6. Acknowledgements This draft is the product of discussions and deliberations carried out in the following working groups: ietf-madman-wg ietf-madman@innosoft.com wide-isode-wg isode-wg@wide.ad.jp wide-netman-wg netman-wg@wide.ad.jp 7. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] 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. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S, Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] CCITT Blue Book, "Data Communication Networks: Directory", Recommendations X.500-X.521, December 1988. [6] Kille, S., WG Chair, and N. Freed, Editor, "The Network Services Monitoring MIB", RFC 1565, ISODE Consortium, Innosoft, January 1994. Mansfield & Kille [Page 17] RFC 1567 X.500 Directory Monitoring MIB January 1994 [7] Grillo, P., and S. Waldbusser, "Host Resources MIB", RFC 1514, Network Innovations, Intel Corporation, Carnegie Mellon University, September 1993. [8] Kille, S., "A String Representation of Distinguished Names (OSI- DS 23 (v5))", RFC 1485, ISODE Consortium, July 1993. [9] Kille, S., Huizer, E., Cerf, V., Hobby, R., and S. Kent, "A Strategic Plan for Deploying an Internet X.500 Directory Service", RFC 1430, ISODE Consortium, SURFnet bv, Corporation for National Research Initiatives, University of California, Davis, Bolt, Beranek and Newman, February 1993. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Glenn Mansfield AIC Systems Laboratories 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-32 Japan Phone: +81-22-279-3310 EMail: glenn@aic.co.jp Steve E. Kille ISODE Consortium The Dome, The Square Richmond TW9 1DT UK Phone: +44-81-332-9091 EMail: S.Kille@isode.com Mansfield & Kille [Page 18] snmp-mibs-downloader-1.1/mibrfcs/rfc1592.txt0000644000000000000000000041013311402176071015564 0ustar Network Working Group B. Wijnen Request for Comments: 1592 G. Carpenter Obsoletes: 1228 T.J. Watson Research Center, IBM Corp. Category: Experimental K. Curran A. Sehgal G. Waters Bell Northern Research, Ltd. March 1994 Simple Network Management Protocol Distributed Protocol Interface Version 2.0 Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Summary of Changes . . . . . . . . . . . . . . . . . . . . 4 2. THEORY OF OPERATION . . . . . . . . . . . . . . . . . . . . . 5 2.1 Connection Establishment and Termination . . . . . . . . . 5 2.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Normal Operation . . . . . . . . . . . . . . . . . . . . . 6 2.4 DPI Architecture . . . . . . . . . . . . . . . . . . . . . 6 3. SNMP DPI PROTOCOL . . . . . . . . . . . . . . . . . . . . . 10 3.1 Connection Establishment . . . . . . . . . . . . . . . . 10 3.1.1 SNMP PDU to GET the Agent's DPI port . . . . . . . . . 11 3.1.2 SNMP PDU Containing the RESPONSE to the GET . . . . . 13 3.2 SNMP DPI Packet Formats . . . . . . . . . . . . . . . . 15 3.2.1 DPI Packet Header . . . . . . . . . . . . . . . . . . 15 3.2.2 OPEN . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 CLOSE . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.4 ARE_YOU_THERE . . . . . . . . . . . . . . . . . . . . 19 3.2.5 REGISTER . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.6 UNREGISTER . . . . . . . . . . . . . . . . . . . . . . 22 3.2.7 GET . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.8 GETNEXT . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.9 GETBULK . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.10 SET, COMMIT and UNDO . . . . . . . . . . . . . . . . 26 3.2.11 RESPONSE . . . . . . . . . . . . . . . . . . . . . . 29 3.2.12 TRAP . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3 Constants and Values . . . . . . . . . . . . . . . . . . 33 Wijnen, Carpenter, Curran, Sehgal & Waters [Page 1] RFC 1592 SNMP-DPI March 1994 3.3.1 Protocol Version and Release Values . . . . . . . . . 33 3.3.2 Packet Type Values . . . . . . . . . . . . . . . . . . 34 3.3.3 Variable Type Values . . . . . . . . . . . . . . . . . 35 3.3.4 Value Representation . . . . . . . . . . . . . . . . . 36 3.3.5 Character set selection . . . . . . . . . . . . . . . 36 3.3.6 Error Code Values for SNMP DPI RESPONSE packets . . . 37 3.3.7 UNREGISTER Reason Codes . . . . . . . . . . . . . . . 40 3.3.8 CLOSE Reason Codes . . . . . . . . . . . . . . . . . . 41 4. DPI 2.0 MIB DEFINITION . . . . . . . . . . . . . . . . . . 41 5. SUBAGENT CONSIDERATIONS . . . . . . . . . . . . . . . . . . 42 5.1 DPI API . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Overview of Request Processing . . . . . . . . . . . . . 44 5.2.1 GET Processing . . . . . . . . . . . . . . . . . . . . 44 5.2.2 SET Processing . . . . . . . . . . . . . . . . . . . . 44 5.2.3 GETNEXT Processing . . . . . . . . . . . . . . . . . . 46 5.2.4 GETBULK Processing . . . . . . . . . . . . . . . . . . 47 5.2.5 OPEN Request . . . . . . . . . . . . . . . . . . . . . 48 5.2.6 CLOSE Request . . . . . . . . . . . . . . . . . . . . 49 5.2.7 REGISTER Request . . . . . . . . . . . . . . . . . . . 49 5.2.8 UNREGISTER Request . . . . . . . . . . . . . . . . . . 50 5.2.9 TRAP Request . . . . . . . . . . . . . . . . . . . . . 51 5.2.10 ARE_YOU_THERE request . . . . . . . . . . . . . . . . 51 5.2.11 How to query the DPI port. . . . . . . . . . . . . . 51 6. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . 51 7. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 52 8. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . 53 9. SAMPLE SOURCES FOR ANONYMOUS FTP . . . . . . . . . . . . . 54 1. INTRODUCTION This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. Bell Northern Research (BNR) has also implemented a version of this protocol in some of its SNMP agents for the same reason. The Simple Network Management Protocol (SNMP [1]) Distributed Protocol Interface (DPI) is an extension to SNMP agents that permits end-users to dynamically add, delete or replace management variables in the local Management Information Base without requiring recompilation of the SNMP agent. This is achieved by writing a so- called sub-agent that communicates with the agent via the SNMP-DPI. For the author of a sub-agent, the SNMP-DPI eliminates the need to know the details of ASN.1 [2] or SNMP PDU (Protocol Data Unit) encoding/decoding [1, 3]. Versions 1.0 and 1.1 of this protocol have been in use within IBM Wijnen, Carpenter, Curran, Sehgal & Waters [Page 2] RFC 1592 SNMP-DPI March 1994 since 1989 and is included in the SNMP agents for VM, MVS and OS/2. Version 1.2 of this protocol has been in use within BNR since 1992. 1.1 MOTIVATION The Simple Network Management Protocol [1] defines a protocol that permits operations on a collection of variables. This set of variables is called the Management Information Base (MIB) and a core set of variables has previously been defined [4, 5]; however, the design of the MIB makes provision for extension of this core set. Thus, an enterprise or individual can define variables of their own which represent information of use to them. An example of a potentially interesting variable which is not in the core MIB would be CPU utilization (percent busy). Unfortunately, conventional SNMP agent implementations provide no means for an end-user to make available new variables. Besides this, today there are many MIBs that people want to implement on a system. Without a capability for sub-agents, this requires all the MIBs to be implemented in one big monolithic agent, which is in many cases undesirable. The SNMP DPI addresses these issues by providing a light-weight mechanism by which a process can register the existence of a MIB variable or a MIB sub-tree with the SNMP agent. Requests for the variable(s) that are received by the SNMP agent are passed to the process acting as a sub-agent. The sub-agent then returns an appropriate answer to the SNMP agent. The SNMP agent eventually packages an SNMP response packet and sends the answer back to the remote network management station that initiated the request. Remote network management stations have no knowledge that the SNMP agent calls on other processes to obtain an answer. As far as they can tell, there is only one network management application (agent) running on the host. At the San Diego IETF (March 1992) a BOF was held on multiplexing SNMP agent's requirements. Both the SMUX [6] and DPI [7] protocols were discussed, as well as other unpublished approaches. There was also discussion regarding a need for a standard for multiplexing SNMP agents or sub-agent support. At the end of the BOF, however, there was not enough support for defining a standard. This was due, at least partially, to a few well known SNMP authors who stated that the proxy and party support for SNMPv2 (SMP at the time) would solve the problem. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 3] RFC 1592 SNMP-DPI March 1994 Nevertheless, questions continue to be raised about sub-agent support (both in SNMP and SNMP2 mail lists) in spite of both SNMPv2 [8] being on the standard's track and SMUX being changed to a historic RFC. Furthermore, within IBM and BNR we continue to see a substantial and expanding use of the DPI protocol. with positive results. Therefore, we believe that there is a place for a sub-agent protocol and we again offer this new version as an experimental protocol. We encourage people to try it and send us feedback. Depending on that feedback, we may decide to try to get onto the standards track at a later time. During discussions about sub-agent interfaces at the San Diego BOF it also became clear that we should reduce the focus on the API for the sub-agent programmers. This RFC, therefore, specifies only the protocol to distribute SNMP requests from the main SNMP agent to the sub-agents. Programmers can build one or more Programming APIs on top of that protocol as needed, and sample API code is available from the authors of this document. 1.2 SUMMARY OF CHANGES The following changes have been made since the initial definition of SNMP-DPI [7]. Some of these resulted from comparing the SMUX [6] and DPI [7] protocols. o Documentation changes to cleanup and be more specific in some areas. Among other things, this includes: - Defining that integers are in network byte order - Defining the character set used for strings - Defining how DisplayStrings are handled. - Including DPI20 MIB definition. o Removal of the Programming API from the document. o Addition of new DPI packet types: - SNMP_DPI_OPEN for a sub-agent to open a "connection" with the DPI SNMP capable agent. The sub-agent must now identify itself and optionally provide a "password" for the connection. - SNMP_DPI_CLOSE for the agent or sub-agent to close the connection in a graceful way. - SNMP_DPI_ARE_YOU_THERE for the sub-agent to verify that the agent still knows about the sub-agent. - SNMP_DPI_UNREGISTER for the agent or sub-agent to terminate the registration of a MIB variable or MIB sub-tree. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 4] RFC 1592 SNMP-DPI March 1994 - SNMP_DPI_COMMIT which instructs the sub-agent to actually commit a previous SNMP_DPI_SET request. This, together with the UNDO, allows DPI sub-agents to be compliant with SNMP in the sense that we can now handle the "as if simultaneous" requirement. - SNMP_DPI_UNDO which instructs the sub-agent to UNDO a SET or COMMIT if such is needed. o Changes to DPI packets: - Multiple varBinds can now be exchanged in one DPI packet (for GET, GETNEXT, SET, TRAP). The sub-agent can specify the maximum it wants to handle per packet. - The packet headers now contain a packet-ID (similar to SNMP request ID in SNMP PDU). This allows to match RESPONSE packets to REQUESTS, which is important for UDP based DPI-connections. - The SNMP_DPI_REGISTER packet has new fields for time_out and for requested priority. - The SNMP_DPI_TRAP packet allows to specify an enterprise OID. In addition, the generic and specific trap types are now 4 octets, so that we can pass the types correctly. - In general, the packets have a more consistent layout. o The agent now sends a RESPONSE to a REGISTER request o Addition of SNMPv2 error codes and value types. 2. THEORY OF OPERATION 2.1 CONNECTION ESTABLISHMENT AND TERMINATION Communication between the SNMP Agent and its clients (sub-agents) takes place via a communication mechanism. The communication type can be either a logical stream connection (via TCP, for instance) or an unreliable datagram connection (UDP, for instance). It should be noted that other stream oriented transport communication mechanisms can also be used. For example, the VM SNMP agent allows DPI connections over IUCV (Inter-User Communications Vehicle) [9, 10]. Other than the connection establishment procedure, the protocol used is identical in these environments. In Unix the number of processes is limited by the number of file- descriptors that can be opened. Since each TCP socket represents a file-descriptor, restricting SNMP-DPI protocol to TCP only connections would limit the number of sub-agents an agent could support. As a result, the some SNMP-DPI agents support both TCP and UDP socket type communication mechanisms for the SNMP-DPI protocol. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 5] RFC 1592 SNMP-DPI March 1994 Please note that in the following portion of this text the SNMP-DPI agent is referred simply as the agent. Once the transport connection has been set up, the sub-agent must also initialize the logical connection with the agent. To do so it issues an OPEN request to the agent in which the sub-agent uniquely identifies itself and passes some other parameters to the agent, such as, the maximum number of varBinds per interaction it is prepared to handle, and the timeout the agent should use when waiting for a response from the sub-agent. When the sub-agent prepares to stop or cease operations, it first issues a CLOSE to shut down the logical connection with the agent, and then closes the transport connection. 2.2 REGISTRATION A sub-agent supports a collection of MIB variables or object identifiers (object IDs) that constitute its MIB (sub)tree. Each of these object IDs consists of a group ID and an instance ID. The group ID is the root of the sub-agent's MIB tree that it supports and the point of registration to the agent's MIB tree. The instance ID is the piece of the Object Identifier that follows the group ID (registration point), so it is not an instance in the terms of the SNMP definition of an instance. Regardless of the transport mechanism used, after establishing a connection to the agent, the sub-agent registers a branch (group ID) to the Agent's MIB tree. With the registration request, the sub- agent passes some parameters, such as, requested priority and a timeout value for this specific sub-tree. The agent sends back a response to indicate success or failure of the registration request. 2.3 NORMAL OPERATION Once the sub-agent has set up both the physical and logical connection to the agent, and once it has successfully registered the sub-tree(s) of the MIB(s) that it supports, it waits for requests from the SNMP agent or generates traps as required. 2.4 DPI ARCHITECTURE These are the requests that can be initiated by the SNMP agent: GET, GETNEXT, GETBULK, SET, COMMIT, UNDO, UNREGISTER, and CLOSE. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 6] RFC 1592 SNMP-DPI March 1994 The first four of these correspond directly to SNMP requests that a network management station can make (By default a GETBULK request will be translated into multiple GETNEXT requests by the agent, but a sub-agent may request that the GETBULK be passed to it). The COMMIT, UNDO, UNREGISTER, ARE_YOU_THERE and CLOSE requests are specific SNMP-DPI requests. The sub-agent normally responds to a request with a RESPONSE packet. The CLOSE request is an exception for which the sub-agent only closes the physical connection. These are the requests that can be initiated by a sub-agent: OPEN, REGISTER, TRAP, UNREGISTER, ARE_YOU_THERE and CLOSE. The agent responds to OPEN, REGISTER, UNREGISTER and ARE_YOU_THERE with a RESPONSE packet. The TRAP packet is just accepted and forwarded by the agent without returning any information to the sub- agent. The CLOSE packet is also just accepted by the agent upon which it closes the physical connection. See Figure 1 for an overview of the DPI packet flow. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 7] RFC 1592 SNMP-DPI March 1994 ------------------------------------------------------------------- *---------------------------------* | | | SNMP Network | | Management Station | | | |---------------------------------| | SNMP Protocol | *---------------------------------* A | Get A | | GetNext | GetResponse Trap | | GetBulk | | | Set | | V | *------------------------------* *-------------------* | SNMP Protocol | | DPI Interface | |------------------------------| Response | *--------------| | | |<----------->| | | | | | | | | | SNMP Agent | | | | | | | | Get,GetNext | | | | | | (GetBulk) | | Client | | | | Set,Commit | | | | A *-----------+-> | Undo | | | | | | Get/Set | |------------>| | or | | Trap| | info | | | | | | | | | SNMP | | | | |-----+-----+-------* | | trap | | SNMP | | | V | | DPI |<------------| | Sub-Agent | | | | | | | | | Statically Linked | | | | | | | Instrumentation | | | | | | | (like MIB II) | | | | | | | | | | close | | | | A | | | unregister | | | |-------+-----------| | |<----------->| | | | V | | | | | | | | | | | | | | | | | AreYouThere | | | | TCP/IP layers | | | open | | | | Kernel | | | register | | | | | | |<------------| | | *------------------------------* *-------------------* ------------------------------------------------------------------- Figure 1. SNMP DPI overview Wijnen, Carpenter, Curran, Sehgal & Waters [Page 8] RFC 1592 SNMP-DPI March 1994 Remarks for Figure 1: o The SNMP agent communicates with the SNMP manager via the standard SNMP protocol. o The SNMP agent communicates with some statically linked-in instrumentation (potentially for the MIB II), which in turn talks to the TCP/IP layers and kernel (operating system) in an implementation-dependent manner. o An SNMP sub-agent, running as a separate process (potentially on another machine), can set up a connection with the agent. The sub-agent has an option to communicate with the SNMP agent through UDP or TCP sockets, or even through other mechanisms. o Once the connection is established, the sub-agent issues a DPI OPEN and one or more REGISTER requests to register one or more MIB sub-trees with the SNMP agent. o The SNMP agent responds to DPI OPEN and REGISTER requests with a RESPONSE packet, indicating success or failure. o The SNMP agent will decode SNMP packets. If such a packet contains a Get or GetNext request for an object in a sub-tree registered by a sub-agent, it sends a corresponding DPI packet to the sub-agent. If the request is for a GetBulk, then the agent translates it into multiple DPI GETNEXT packets and sends those to the sub-agent. However, the sub-agent can request (in the REGISTER packet) that a GETBULK be passed to the sub-agent. If the request is for a Set, then the agent uses a 2-phase commit scheme and sends the sub-agent a sequence of SET/COMMIT, SET/UNDO or SET/COMMIT/UNDO DPI packets. o The SNMP sub-agent sends responses back via a RESPONSE packet. o The SNMP agent then encodes the reply into an SNMP packet and sends it back to the requesting SNMP manager. o If the sub-agent wants to report an important state change, it sends a DPI TRAP packet to the SNMP agent which will encode it into an SNMP trap packet and send it to the manager(s). o If the sub-agent wants to stop operations, it sends a DPI UNREGISTER and a DPI CLOSE packet to the agent. The agent sends a response to an UNREGISTER request. o There is no RESPONSE to a CLOSE, the agent just closes the DPI connection. A CLOSE implies an UNREGISTER for all registrations that exist for the DPI connection being CLOSED. o An agent can send DPI UNREGISTER (if a higher priority registration comes in or for other reasons) to the sub-agent, the sub-agent then responds with a DPI RESPONSE packet. o An agent can also (for whatever reason) send a DPI CLOSE to indicate it is terminating the DPI connection. o A sub-agent can send an ARE_YOU_THERE to verify that the "connection" is still open. If so, the agent sends a RESPONSE with no error, otherwise, it may send a RESPONSE with an error Wijnen, Carpenter, Curran, Sehgal & Waters [Page 9] RFC 1592 SNMP-DPI March 1994 indication, or not react at all. 3. SNMP DPI PROTOCOL This section describes the actual protocol used between the SNMP agent and sub-agents. 3.1 CONNECTION ESTABLISHMENT In a TCP/IP environment, the SNMP agent listens on an arbitrary TCP/UDP port for a connection request from a sub-agent. It is important to realize that a well-known port is not used: every invocation of the SNMP agent will potentially result in a different TCP/UDP port being used. A sub-agent needs to determine this port number to establish a connection. The sub-agent learns the port number from the agent by sending it one conventional SNMP get-request PDU. The port numbers are maintained by the SNMP agent as the objects whose identifiers are: 1.3.6.1.4.1.2.2.1.1.0 dpiPort.0 (old DPI 1.x form) 1.3.6.1.4.1.2.2.1.1.1.0 dpiPortForTCP.0 1.3.6.1.4.1.2.2.1.1.2.0 dpiPortForUDP.0 These variables are registered under the IBM enterprise-specific tree. See 4, "DPI 2.0 MIB definition" for more information. The SNMP agent replies with a conventional SNMP response PDU that contains the port number to be used. This response is examined by the sub-agent and the port number is extracted. The sub-agent then establishes the connection to the specified port. On the surface, this procedure appears to mean that the sub-agent must be able to create and parse SNMP packets, but this is not the case. A DPI Application Programming Interface (API) normally provides a library routine, query_DPI_port(), which can be used to generate and parse the required SNMP packets. This very small routine (under 100 lines of C), does not greatly increase the size of any sub-agent. NOTE: Since this RFC does not define an API, the actual code of and interface to a query_DPI_port() type of function depends on the implementation. For completeness, byte-by-byte descriptions of the packets to be generated by an SNMP DPI API routine query_DPI_port() are provided below. This is probably of little interest to most readers and reading the source of a query_DPI_port() function provides much of Wijnen, Carpenter, Curran, Sehgal & Waters [Page 10] RFC 1592 SNMP-DPI March 1994 the same information. 3.1.1 SNMP PDU TO GET THE AGENT'S DPI PORT As noted, before a TCP/UDP connection to the SNMP agent can be made, the sub-agent must learn which port that the agent is listening on. To do so, it can issue an SNMP GET for the variable dpiPortForTCP.0 (1.3.6.1.4.1.2.2.1.1.1.0) or variable dpiPortForUDP.0 (1.3.6.1.4.1.2.2.1.1.2.0). The SNMP PDU can be constructed as shown below. This PDU must be sent to UDP port 161 on the host where the agent runs (probably the same host where the sub-agent runs). The (SNMPv1) packet shown below is for the TCP port. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 11] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 1 (Page 1 of 2). SNMP GET PDU for dpiPortForTCP.0 | +---------------+----------------+--------------------------------+ | OFFSET | VALUE | FIELD | +---------------+----------------+--------------------------------+ | 0 | 0x30 | ASN.1 header | +---------------+----------------+--------------------------------+ | 1 | 37 + len | PDU_length, see formula below | +---------------+----------------+--------------------------------+ | 2 | 0x02 0x01 0x00 | SNMP version: | | | | (integer,length=1,value=0) | +---------------+----------------+--------------------------------+ | 5 | 0x04 | community name (string) | +---------------+----------------+--------------------------------+ | 6 | len | length of community name | +---------------+----------------+--------------------------------+ | 7 | community name | varies | +---------------+----------------+--------------------------------+ | 7 + len | 0xa0 0x1c | SNMP GET request: | | | | request_type=0xa0,length=0x1c | +---------------+----------------+--------------------------------+ | 7 + len + 2 | 0x02 0x01 0x01 | SNMP request ID: | | | | integer,length=1,ID=1 | +---------------+----------------+--------------------------------+ | 7 + len + 5 | 0x02 0x01 0x00 | SNMP error status: | | | | integer,length=1,error=0 | +---------------+----------------+--------------------------------+ | 7 + len + 8 | 0x02 0x01 0x00 | SNMP index: | | | | integer,length=1,index=0 | +---------------+----------------+--------------------------------+ | 7 + len + 11 | 0x30 0x11 | varBind list, length=0x11 | +---------------+----------------+--------------------------------+ | 7 + len + 13 | 0x30 0x0f | varBind, length=0x0f | +---------------+----------------+--------------------------------+ | 7 + len + 15 | 0x06 0x0b | Object ID, length=0x0b | +---------------+----------------+--------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 12] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 1 (Page 2 of 2). SNMP GET PDU for dpiPortForTCP.0 | +---------------+----------------+--------------------------------+ | OFFSET | VALUE | FIELD | +---------------+----------------+--------------------------------+ | 7 + len + 17 | 0x2b 0x06 0x01 | Object-ID: | | | 0x04 0x01 0x02 | 1.3.6.1.4.1.2.2.1.1.1 | | | 0x02 0x01 0x01 | Object-instance: 0 | | | 0x01 0x00 | | +---------------+----------------+--------------------------------+ | 7 + len + 28 | 0x05 0x00 | null value, length=0 | +---------------+----------------+--------------------------------+ | NOTE: Formula to calculate "PDU_length": | | | | PDU_length = length of version field and string tag (4 bytes)| | + length of community length field (1 byte) | | + length of community name (depends...) | | + length of SNMP GET request (32 bytes) | | | | = 37 + length of community name | +-----------------------------------------------------------------+ 3.1.2 SNMP PDU CONTAINING THE RESPONSE TO THE GET Assuming that no errors occurred, the port is returned in the last few octets of the received packet. In the simple case, where the port number will be between 1024 and 16,385, the format of the packet is shown below. Note: In practice, the port number can be any positive number in the range from 1 through 65,535. A port number of 0 means that the agent does not have a dpiPort defined for the requested protocol. So the actual port value maybe in the last 1, 2 or 3 octets. The sample implementation code shows how to handle the response to cover all those cases, including error conditions. Note: The (SNMPv1) packet shown below is for the TCP port. +-----------------------------------------------------------------+ | Table 2 (Page 1 of 3). SNMP RESPONSE PDU for dpiPortForTCP.0 | +---------------+----------------+--------------------------------+ | OFFSET | VALUE | FIELD | +---------------+----------------+--------------------------------+ | 0 | 0x30 | ASN.1 header | +---------------+----------------+--------------------------------+ | 1 | 39 + len | length, see formula below | +---------------+----------------+--------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 13] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 2 (Page 2 of 3). SNMP RESPONSE PDU for dpiPortForTCP.0 | +---------------+----------------+--------------------------------+ | OFFSET | VALUE | FIELD | +---------------+----------------+--------------------------------+ | 2 | 0x02 0x01 0x00 | version | | | | (integer,length=1,value=0) | +---------------+----------------+--------------------------------+ | 5 | 0x04 | community name (string) | +---------------+----------------+--------------------------------+ | 6 | len | length of community name | +---------------+----------------+--------------------------------+ | 7 | community name | | +---------------+----------------+--------------------------------+ | 7 + len | 0xa2 0x1e | SNMP RESPONSE: | | | | request_type=0xa2,length=0x1e | +---------------+----------------+--------------------------------+ | 7 + len + 2 | 0x02 0x01 0x01 | SNMP request ID: | | | | integer,length=1,ID=1 | +---------------+----------------+--------------------------------+ | 7 + len + 5 | 0x02 0x01 0x00 | SNMP error status: | | | | integer,length=1,error=0 | +---------------+----------------+--------------------------------+ | 7 + len + 8 | 0x02 0x01 0x00 | SNMP index: | | | | integer,length=1,index=0 | +---------------+----------------+--------------------------------+ | 7 + len + 11 | 0x30 0x13 | varBind list, length=0x13 | +---------------+----------------+--------------------------------+ | 7 + len + 13 | 0x30 0x11 | varBind, length=0x11 | +---------------+----------------+--------------------------------+ | 7 + len + 15 | 0x06 0x0b | Object ID, length=0x0b | +---------------+----------------+--------------------------------+ | 7 + len + 17 | 0x2b 0x06 0x01 | Object-ID: | | | 0x04 0x01 0x02 | 1.3.6.1.4.1.2.2.1.1.1 | | | 0x02 0x01 0x01 | Object-instance: 0 | | | 0x01 0x00 | | +---------------+----------------+--------------------------------+ | 7 + len + 28 | 0x02 0x02 | integer, length=2 | +---------------+----------------+--------------------------------+ | 7 + len + 30 | MSB LSB | port number (MSB, LSB) | +---------------+----------------+--------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 14] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 2 (Page 3 of 3). SNMP RESPONSE PDU for dpiPortForTCP.0 | +---------------+----------------+--------------------------------+ | NOTE: Formula to calculate "PDU_length": | | | | PDU_length = length of version field and string tag (4 bytes)| | + length of community length field (1 byte) | | + length of community name (depends...) | | + length of SNMP RESPONSE (34 bytes) | | | | = 39 + length of community name | +-----------------------------------------------------------------+ 3.2 SNMP DPI PACKET FORMATS Each request to, or response from, the agent or sub-agent is constructed as a "packet" and is written to the stream. Each packet is prefaced with the length of the data remaining in the packet. The length is stored in network byte order, the most significant byte (MSB) first, least significant byte (LSB) last. If we consider a stream connection (like TCP), the receiving side will read the packet by doing something similar to: unsigned char len_bfr[2]; unsigned char *bfr; int len; read(fd,len_bfr,2); len = len_bfr[0] * 256 + len_bfr[1]; bfr = malloc(len); read(fd,bfr,len); Note: The above example makes no provisions for error handling or a read returning less than the requested amount of data,and it is not intended to be used literally. 3.2.1 DPI PACKET HEADER The first part of every packet identifies the application protocol being used as well as some version information. The protocol major version is intended to indicate, in broad terms, what version of the protocol is used. The protocol minor version is intended to identify major incompatible versions of the protocol. The protocol release is intended to indicate incremental modifications to the protocol. The constants that are valid for these fields are defined in Table 15. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 15] RFC 1592 SNMP-DPI March 1994 The next field, present in all packets, is the packet ID. It contains packet identification that can help an agent or sub-agent match responses with request. This is useful with UDP connections over which packets can be lost. The packet ID is a monotonically increasing unsigned 16-bit integer which wraps at its maximum value. The next field, present in all packets, is the packet type. It indicates what kind of packet we're dealing with (OPEN, REGISTER, GET, GETNEXT, GETBULK, SET, COMMIT, UNDO, TRAP, RESPONSE, UNREGISTER, or CLOSE). The permitted values for this field are defined in Table 16. +-----------------------------------------------------------------+ | Table 3. SNMP DPI packet header. Present in all packets. | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type | +------------+----------------------------------------------------+ From this point onwards, the contents of the packet are defined by the protocol being used. The remainder of this section describes: o Layout of packets for the SNMP DPI protocol, version 2.0. o Constants as defined with this version of the protocol. 3.2.2 OPEN In order for a sub-agent to communicate with a DPI capable SNMP agent, it must first send an SNMP DPI OPEN request to the agent to setup the "connection" with that agent. Such a packet contains the standard SNMP DPI header plus OPEN specific data. This data consists of: Wijnen, Carpenter, Curran, Sehgal & Waters [Page 16] RFC 1592 SNMP-DPI March 1994 o a timeout value (in seconds). This is a requested timeout value to be used for all requests for objects for which there is no timeout value specified for the sub-tree under which the object is registered. If you specify a zero timeout value, then the agent will use its own default timeout value. If you want a larger value than the default value, then you can specify it here. However, the agent may have a maximum value that you can never exceed. If you do ask for a larger timeout than that maximum, the agent will set it at the maximum it accepts. o the maximum number of varBinds per DPI packet that the sub-agent is prepared to handle. o Selected character set to be used for the representation of the OBJECT ID strings and DisplayStrings. The choices are the native character set (0) or the ASCII character set (1). See 3.3.5, "Character set selection" for more information in character set selection. An agent may choose to support only the native character set. o null terminated sub-agent ID, which is a unique ASN.1 OBJECT identifier, so in dotted ASN.1 notation. This string is represented in the selected character set. o null terminated sub-agent description, which is a DisplayString describing the sub-agent. This string is represented in the selected character set. This may be the null-string if there is no description. o optionally a password that the agent uses to validate the sub-agent. It depends on the agent implementation if a password is required. If no password is passed, the length must be specified as zero. The sub-agent must expect a response indicating success or failure. See Table 19 for the valid codes in a DPI RESPONSE to a DPI OPEN request. If the error_code in the RESPONSE is not SNMP_ERROR_DPI_noError, then the agent closes the connection. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 17] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 4. Layout SNMP DPI OPEN packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_OPEN | +------------+----------------------------------------------------+ | 8 | requested overall timeout (seconds, MSB to LSB) | +------------+----------------------------------------------------+ | 10 | max varBinds per DPI packet (MSB to LSB) | +------------+----------------------------------------------------+ | 12 | Selected character set (0=Native, 1=ASCII) | +------------+----------------------------------------------------+ | 13 | null terminated sub-agent ID (OID) | +------------+----------------------------------------------------+ | 13+L1 | null terminated sub-agent Description | +------------+----------------------------------------------------+ | 13+L2 | password length (zero if no password, MSB to LSB) | +------------+----------------------------------------------------+ | 15+L2 | password (if any) | +------------+----------------------------------------------------+ | NOTE: | | | | o L1 = strlen(sub-agent ID) + 1 | | o L2 = L1 + strlen(sub-agent Description) + 1 | | o OID and Description strings use selected character set | +-----------------------------------------------------------------+ 3.2.3 CLOSE In order for a sub-agent to close the "connection" with the DPI capable SNMP agent, it must send an SNMP DPI CLOSE request to the agent. The agent will not send a response, but closes the physical connection and implicitly unregisters any sub-trees related to the connection. An agent may also send to the sub-agent an SNMP DPI CLOSE packet that contains the standard SNMP DPI header plus CLOSE specific data. This Wijnen, Carpenter, Curran, Sehgal & Waters [Page 18] RFC 1592 SNMP-DPI March 1994 data consists of: o a reason code for closing. See Table 21 for a list of valid reason codes. +-----------------------------------------------------------------+ | Table 5. Layout SNMP DPI CLOSE packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_CLOSE | +------------+----------------------------------------------------+ | 8 | reason code (1 octet) | +------------+----------------------------------------------------+ 3.2.4 ARE_YOU_THERE An ARE_YOU_THERE packet allows a sub-agent to determine if it still has a DPI connection with the agent. This packet is necessary because a sub-agent passively awaits requests from an agent and normally will not detect problems with an agent connection in a timely manner. (In contrast, an agent becomes aware of any sub-agent connection problem in a timely manner because it sets a timeout when sending request). A sub-agent can send a SNMP DPI ARE_YOU_THERE packet to an agent which will then return a RESPONSE with a zero error code and a a zero error index if the connection is healthy. Otherwise, the agent may return a RESPONSE with an error indication. If the connection is broken, the sub-agent will see no response at all. An ARE_YOU_THERE packet contains the standard SNMP DPI header with no additional data. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 19] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 6. Layout SNMP DPI ARE_YOU_THERE packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_ARE_YOU_THERE | +------------+----------------------------------------------------+ 3.2.5 REGISTER In order to register a branch in the MIB tree, an SNMP sub-agent sends an SNMP DPI REGISTER packet to the agent. Such a packet contains the standard SNMP DPI header plus REGISTER specific data. This data consists of: o a requested priority. There are 2 special values, namely minus one (-1, requests best available priority) and zero (0, requests next better priority than the highest priority in use). Any other value requests a specific priority or the next best priority if already in use). The lower the number, the better the priority. An agent will send requests to only the one sub-agent that has registered with the best priority. The agent returns the actual priority assigned in the RESPONSE packet in the error_index field. o a requested timeout. If a zero value is specified, then the agent uses the timeout value specified in the DPI OPEN request. If you want a shorter or longer timeout value for this specific sub-tree, then you specify it here. The agent has a maximum timeout it will allow in this field. The agent will use this value (or its maximum) to await a response to requests for this sub-tree. o an indication as to whether the sub-agent wishes to handle MIB view selection (SNMPv1 community string authentication) in subsequent GET, GETNEXT or SET, COMMIT, UNDO requests. Not all DPI capable agents need to support this feature, but they must at least recognize this indication and give an appropriate Wijnen, Carpenter, Curran, Sehgal & Waters [Page 20] RFC 1592 SNMP-DPI March 1994 response if they do not support it. o an indication as to whether the sub-agent wishes to handle the GETBULK itself. If not, then the agent will translate a GETBULK into multiple GETNEXT requests. Not all DPI capable agents need to support this feature. They may opt to always translate a GETBULK into multiple GETNEXT requests. In this case the agent will send the appropriate RESPONSE to indicate this. o the group ID (sub-tree) to be registered (with trailing dot). The group ID is represented in the selected character set as specified in DPI OPEN packet. The agent will respond with an SNMP DPI RESPONSE packet indicating registration error or success. The packet ID of the response will be the same as that for the REGISTER request to which this is a response. The group ID will be the same as that specified in the REGISTER request. There will be no instance returned (e.g. NULL string for instance ID). The value will be an SNMP_TYPE_NULL value with a zero length. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 21] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 7. Layout SNMP DPI REGISTER packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_REGISTER | +------------+----------------------------------------------------+ | 8 | requested priority (MSB to LSB) | +------------+----------------------------------------------------+ | 12 | timeout in seconds (MSB to LSB) | +------------+----------------------------------------------------+ | 14 | view selection (0 = you (agent) do, 1 = I do) | +------------+----------------------------------------------------+ | 15 | getbulk selection (0=use GetNext, 1=use GetBulk) | +------------+----------------------------------------------------+ | 16 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | NOTE: | | | | o group ID string uses selected character set | +-----------------------------------------------------------------+ 3.2.6 UNREGISTER In order to unregister a branch in the MIB tree, an SNMP sub-agent sends an SNMP DPI UNREGISTER packet to the agent. Such a packet contains the standard SNMP DPI header plus UNREGISTER specific data: a null terminated string (represented in the selected character set) representing the group ID in ASN.1 dotted notation and an indication as to the reason for the unregister (see table 14). The agent will respond with an SNMP DPI RESPONSE packet indicating error or success. The packet ID of the response will be the same as that for the UNREGISTER request to which this is a response. The group ID will be the same as that specified in the UNREGISTER request. There will be no instance returned (e.g. NULL string for Wijnen, Carpenter, Curran, Sehgal & Waters [Page 22] RFC 1592 SNMP-DPI March 1994 instance ID). The value will be an SNMP_TYPE_NULL value with a zero length. +-----------------------------------------------------------------+ | Table 8. Layout SNMP DPI UNREGISTER packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_UNREGISTER | +------------+----------------------------------------------------+ | 8 | reason code | +------------+----------------------------------------------------+ | 9 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | NOTE: | | | | o group ID string uses selected character set | +-----------------------------------------------------------------+ 3.2.7 GET When the SNMP agent receives a PDU containing an SNMP GET request for a variable that resides in a sub-tree registered by a sub-agent, it passes an SNMP DPI GET packet to the sub-agent. Such a packet contains the standard SNMP DPI header plus GET specific data: o the community name used in the SNMP PDU. The length is zero unless view handling was selected by the sub-agent. The length is also zero if the SNMP PDU was not in SNMPv1 format. o per varBind two null terminated strings (in the selected character set) representing the group and instance ID in ASN.1 dotted notation. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 23] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 9. Layout SNMP DPI GET packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_GET | +------------+----------------------------------------------------+ | 8 | community name length (MSB to LSB) | +------------+----------------------------------------------------+ | 10 | community name (if any) | +------------+----------------------------------------------------+ | 10+L1 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | 10+L2 | null terminated instance ID (no trailing dot) | +------------+----------------------------------------------------+ | 10+L3 | optionally more varBinds (group/instance ID pairs) | +------------+----------------------------------------------------+ | NOTE: | | | | o L1 = length of community name | | o L2 = L1 + strlen(group ID) + 1 | | o L3 = L2 + strlen(instance ID) + 1 | | o group and instance ID strings use selected character set | +-----------------------------------------------------------------+ 3.2.8 GETNEXT When the SNMP agent receives a PDU containing an SNMP GETNEXT request for a variable for which a sub-agent may be authoritative, it passes an SNMP DPI GETNEXT packet to the sub-agent. Such a packet contains the standard SNMP DPI header plus GETNEXT specific data: o the community name used in the SNMP PDU. The length is zero unless view handling was selected by the sub-agent. The length is also zero if the SNMP PDU was not in SNMPv1 format. o per varBind two null terminated strings (in the selected Wijnen, Carpenter, Curran, Sehgal & Waters [Page 24] RFC 1592 SNMP-DPI March 1994 character set) representing the group and instance ID in ASN.1 dotted notation. +-----------------------------------------------------------------+ | Table 10. Layout SNMP DPI GETNEXT packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_GETNEXT | +------------+----------------------------------------------------+ | 8 | community name length (MSB to LSB) | +------------+----------------------------------------------------+ | 10 | community name | +------------+----------------------------------------------------+ | 10+L1 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | 10+L2 | null terminated instance ID (no trailing dot) | +------------+----------------------------------------------------+ | 10+L3 | optionally more varBinds (group/instance ID pairs) | +------------+----------------------------------------------------+ | NOTE: | | | | o L1 = length of community name | | o L2 = L1 + strlen(group ID) + 1 | | o L3 = L2 + strlen(instance ID) + 1 | | o group and instance ID strings use selected character set | +-----------------------------------------------------------------+ 3.2.9 GETBULK When the SNMP agent receives a PDU containing an SNMP GETBULK request that includes variables for which a sub-agent may be authoritative, it checks if the sub-agent wants to handle the GETBULK itself (as specified at registration time). If so, it sends an SNMP DPI GETBULK packet to the sub-agent. Such a packet contains the standard SNMP DPI header plus GETBULK specific data: Wijnen, Carpenter, Curran, Sehgal & Waters [Page 25] RFC 1592 SNMP-DPI March 1994 o non-repeaters o max repetitions o per varBind two null terminated strings (in the selected character set) representing the group and instance ID in ASN.1 dotted notation. +-----------------------------------------------------------------+ | Table 11. Layout SNMP DPI GETBULK packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_GETBULK | +------------+----------------------------------------------------+ | 8 | non-repeaters (4 octets, MSB to LSB) | +------------+----------------------------------------------------+ | 12 | max-repetitions (4 octets, MSB to LSB) | +------------+----------------------------------------------------+ | 16 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | 16+L1 | null terminated instance ID (no trailing dot) | +------------+----------------------------------------------------+ | 16+L2 | optionally more varBinds (group/instance ID pairs) | +------------+----------------------------------------------------+ | NOTE: | | | | o L1 = strlen(group ID) + 1 | | o L2 = L1 + strlen(instance ID) + 1 | | o group and instance ID strings use selected character set | +-----------------------------------------------------------------+ 3.2.10 SET, COMMIT AND UNDO When the SNMP agent receives a PDU containing an SNMP SET request for a variable that is in a sub-tree registered by a sub-agent, it passes one of 3 sequences of SNMP DPI packets to the sub-agent: Wijnen, Carpenter, Curran, Sehgal & Waters [Page 26] RFC 1592 SNMP-DPI March 1994 o SET, COMMIT This is the normal sequence. The SET request is the first phase. The sub-agent must verify that the SET request is valid and that the resources needed are available. The COMMIT request comes next. The sub-agent must now effectuate the SET request. o SET, UNDO If an SNMP packet has a SET request for multiple varBinds that reside in different sub-trees, then the agent first sends a SET to all sub-agents. If any sub-agent returns an error on the SET, then the agent sends UNDO to those sub-agents that returned no error on the SET, meaning the SET is being canceled. o SET, COMMIT, UNDO In the very rare circumstance where all sub-agents have responded error-free to a SET and where one of them fails to perform the COMMIT, then the agent sends an UNDO to all involved sub-agents (also those who completed COMMIT). Sub-agents should try, to the best of their ability, to never let a commit fail and to undo an already committed set if asked to do so. Such packets contain the standard SNMP DPI header plus SET specific data: o the community name used in the SNMP PDU. The length is zero unless view handling was selected by the sub-agent. The length is also zero if the SNMP PDU was not in SNMPv1 format. o per varBind: - two null terminated strings (in the selected character set) representing the group and instance ID in ASN.1 dotted notation. - the type, value length and value to be set. The permitted types for the type field are defined in Table 17. See 3.3.4, "Value Representation" for information on how the value data is represented in the packet value field. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 27] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 12. Layout SNMP DPI SET, COMMIT, UNDO packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_SET/COMMIT/UNDO | +------------+----------------------------------------------------+ | 8 | community name length (MSB to LSB) | +------------+----------------------------------------------------+ | 10 | community name | +------------+----------------------------------------------------+ | 10+L1 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | 10+L2 | null terminated instance ID (no trailing dot) | +------------+----------------------------------------------------+ | 10+L3 | SNMP Variable Type Value | +------------+----------------------------------------------------+ | 10+L3+1 | Length of value (2 octets, MSB to LSB) | +------------+----------------------------------------------------+ | 10+L3+3 | Value | +------------+----------------------------------------------------+ | 10+L4 | optionally more varBinds (sequences of group ID, | | | instance ID, Type, Length and Value) | +------------+----------------------------------------------------+ | NOTE: | | | | o L1 = length of community name | | o L2 = L1 + strlen(group ID) + 1 | | o L3 = L2 + strlen(instance ID) + 1 | | o L4 = L3 + 3 + length of value | | o group and instance ID strings use selected character set | | o OID and DisplayString values use selected character set | | o Integer values are in network byte order | +-----------------------------------------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 28] RFC 1592 SNMP-DPI March 1994 3.2.11 RESPONSE An SNMP sub-agent must respond to a GET, GETNEXT, GETBULK, SET, COMMIT, UNDO or UNREGISTER request that it has received from the agent (unless it fails or has a bug ;-)). To do so, it sends an SNMP DPI RESPONSE packet to the agent. Such a packet contains the standard SNMP DPI header plus RESPONSE specific data: o an error_code, o an error_index, o plus for a successful GET, GETNEXT, or GETBULK, the name/type/length/value tuple(s) representing the returned object(s). For each varBind this is described as: - two null terminated strings (in the selected character set) representing the group and instance ID in ASN.1 dotted notation. - the type, value length and value of the object that is returned. The permitted types for the type field are defined in Table 17. See 3.3.4, "Value Representation" for information on how the value data is represented in the packet value field. For an unsuccessful GET, GETNEXT or GETBULK, the sub-agent does not need to return any name/type/length/value tuple(s), because by definition, the varBind information is the same as in the request to which this is a response, and the agent still has that information. The group ID and the packet ID must always be the same as the corresponding fields in request PDU which has prompted the RESPONSE. If the response is to a SET, COMMIT or UNDO request, there is no need to return any varBind information, because by definition, the varBind information is the same as in the request to which this is a response, and the agent still has that information. If the response is to a REGISTER or UNREGISTER, no variable (instance) is being returned, so the instance ID is the NULL string (one 0x00 byte). In the response to a REGISTER request indicating success, the error index contains the priority assigned by the agent. If the response is to an OPEN, ARE_YOU_THERE or CLOSE, no varBind data will be passed, so no group ID, instance ID or value data. The packet will only include the header, the error code and the error Wijnen, Carpenter, Curran, Sehgal & Waters [Page 29] RFC 1592 SNMP-DPI March 1994 index. +-----------------------------------------------------------------+ | Table 13. Layout SNMP DPI RESPONSE packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type = SNMP_DPI_RESPONSE | +------------+----------------------------------------------------+ | 8 | error code (1 octet) | +------------+----------------------------------------------------+ | 9 | error index (4 octets, MSB to LSB) | +------------+----------------------------------------------------+ | 15 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | 15+L1 | null terminated instance ID (no trailing dot) | +------------+----------------------------------------------------+ | 15+L2 | SNMP Variable Type Value | +------------+----------------------------------------------------+ | 15+L2+1 | Length of value (MSB to LSB) | +------------+----------------------------------------------------+ | 15+L2+3 | Value | +------------+----------------------------------------------------+ | 15+L3 | optionally more varBinds (sequences of group ID, | | | instance ID, Type, Length and Value) | +------------+----------------------------------------------------+ | NOTE: | | | | o L1 = strlen(group ID) + 1 | | o L2 = L1 + strlen(instance ID) + 1 | | o L3 = L2 + 3 + length of value | | o group and instance ID strings use selected character set | | o OID and DisplayString values use selected character set | | o Integer values are in network byte order | +-----------------------------------------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 30] RFC 1592 SNMP-DPI March 1994 3.2.12 TRAP An SNMP sub-agent can request the agent to generate an SNMPv1 or SNMPv2 TRAP (depending on the trap destinations defined at the agent) by sending an SNMP DPI TRAP packet to the agent. Such a packet contains the standard SNMP DPI header plus TRAP specific data: o the generic and specific trap codes o optionally a null terminated string (in the selected character set) representing the enterprise ID in ASN.1 dotted notation. This enterprise ID will be sent with the TRAP. If the null string is passed, then the agent uses the sub-agent Identifier (OID as passed with the DPI OPEN packet) as the Enterprise ID. o optionally a set of one or more name/type/length/value tuples. representing varBinds to be sent with the trap. Each varBind consists of: - two null terminated strings (in the selected character set) representing the group and instance ID in ASN.1 dotted notation. - the type, value length and value of the object that is returned. The permitted types for the type field are defined in Table 17. See 3.3.4, "Value Representation" for information on how the value data is represented in the packet value field. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 31] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 14. Layout SNMP DPI TRAP packet | +------------+----------------------------------------------------+ | OFFSET | FIELD | +------------+----------------------------------------------------+ | 0 | packet length to follow (MSB to LSB) | +------------+----------------------------------------------------+ | 2 | protocol major version | +------------+----------------------------------------------------+ | 3 | protocol minor version | +------------+----------------------------------------------------+ | 4 | protocol release | +------------+----------------------------------------------------+ | 5 | packet id (MSB to LSB) | +------------+----------------------------------------------------+ | 7 | packet type - SNMP_DPI_TRAP | +------------+----------------------------------------------------+ | 8 | SNMP generic trap code | +------------+----------------------------------------------------+ | 12 | SNMP specific trap code | +------------+----------------------------------------------------+ | 14 | null terminated enterprise ID (no trailing dot) | +------------+----------------------------------------------------+ | 14+L1 | null terminated group ID (with trailing dot) | +------------+----------------------------------------------------+ | 14+L2 | null terminated instance ID (no trailing dot) | +------------+----------------------------------------------------+ | 14+L3 | SNMP Variable Type Value | +------------+----------------------------------------------------+ | 14+L3+1 | Length of value (MSB to LSB) | +------------+----------------------------------------------------+ | 14+L3+3 | Value | +------------+----------------------------------------------------+ | 14+L4 | optionally more varBinds (sequences of group ID, | | | instance ID, Type, Length and Value) | +------------+----------------------------------------------------+ | NOTE: | | | | o L1 = strlen(enterprise ID) + 1 | | o L2 = L1 + strlen(group ID) + 1 | | o L3 = L1 + L2 + strlen(instance ID) + 1 | | o L4 = L1 + L2 + L3 + 3 + length of Value | | o enterprise, group and instance ID strings use selected | | character set | | o OID and DisplayString values use selected character set | | o Integer values are in network byte order | +-----------------------------------------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 32] RFC 1592 SNMP-DPI March 1994 3.3 CONSTANTS AND VALUES This section describes the constants that have been defined for this version of the SNMP DPI Protocol. 3.3.1 PROTOCOL VERSION AND RELEASE VALUES +-----------------------------------------------------------------+ | Table 15. Protocol version and release values | +--------------------------------+--------------------------------+ | FIELD | VALUE | +--------------------------------+--------------------------------+ | protocol major version | 2 (SNMP DPI protocol) | +--------------------------------+--------------------------------+ | protocol minor version | 2 (version 2) | +--------------------------------+--------------------------------+ | protocol release | 0 (release 0) | +--------------------------------+--------------------------------+ Previous versions of this protocol exist and should preferably be supported by an agent: o version 1, release 0, described in [7] Previous internal versions of this protocol exist and may or may not be supported by an agent: o version 1, release 1, experimental within IBM. o version 1, release 2, experimental within BNR. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 33] RFC 1592 SNMP-DPI March 1994 3.3.2 PACKET TYPE VALUES +-----------------------------------------------------------------+ | Table 16. Valid values for the packet type field | +-------+---------------------------------------------------------+ | VALUE | PACKET TYPE | +-------+---------------------------------------------------------+ | 1 | SNMP_DPI_GET | +-------+---------------------------------------------------------+ | 2 | SNMP_DPI_GETNEXT | +-------+---------------------------------------------------------+ | 3 | SNMP_DPI_SET | +-------+---------------------------------------------------------+ | 4 | SNMP_DPI_TRAP | +-------+---------------------------------------------------------+ | 5 | SNMP_DPI_RESPONSE | +-------+---------------------------------------------------------+ | 6 | SNMP_DPI_REGISTER | +-------+---------------------------------------------------------+ | 7 | SNMP_DPI_UNREGISTER | +-------+---------------------------------------------------------+ | 8 | SNMP_DPI_OPEN | +-------+---------------------------------------------------------+ | 9 | SNMP_DPI_CLOSE | +-------+---------------------------------------------------------+ | 10 | SNMP_DPI_COMMIT | +-------+---------------------------------------------------------+ | 11 | SNMP_DPI_UNDO | +-------+---------------------------------------------------------+ | 12 | SNMP_DPI_GETBULK | +-------+---------------------------------------------------------+ | 13 | SNMP_DPI_TRAPV2 (not yet used) | +-------+---------------------------------------------------------+ | 14 | SNMP_DPI_INFORM (not yet used) | +-------+---------------------------------------------------------+ | 15 | SNMP_DPI_ARE_YOU_THERE | +-------+---------------------------------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 34] RFC 1592 SNMP-DPI March 1994 3.3.3 VARIABLE TYPE VALUES +-----------------------------------------------------------------+ | Table 17. Valid values for the Value Type field | +-------+---------------------------------------------------------+ | VALUE | VALUE TYPE | +-------+---------------------------------------------------------+ | 129 | SNMP_TYPE_Integer32 | +-------+---------------------------------------------------------+ | 2 | SNMP_TYPE_OCTET_STRING | +-------+---------------------------------------------------------+ | 3 | SNMP_TYPE_OBJECT_IDENTIFIER | +-------+---------------------------------------------------------+ | 4 | SNMP_TYPE_NULL (empty, no value) | +-------+---------------------------------------------------------+ | 5 | SNMP_TYPE_IpAddress | +-------+---------------------------------------------------------+ | 134 | SNMP_TYPE_Counter32 | +-------+---------------------------------------------------------+ | 135 | SNMP_TYPE_Gauge32 | +-------+---------------------------------------------------------+ | 136 | SNMP_TYPE_TimeTicks (1/100ths seconds) | +-------+---------------------------------------------------------+ | 9 | SNMP_TYPE_DisplayString | +-------+---------------------------------------------------------+ | 10 | SNMP_TYPE_BIT_STRING | +-------+---------------------------------------------------------+ | 11 | SNMP_TYPE_NsapAddress | +-------+---------------------------------------------------------+ | 140 | SNMP_TYPE_UInteger32 | +-------+---------------------------------------------------------+ | 13 | SNMP_TYPE_Counter64 | +-------+---------------------------------------------------------+ | 14 | SNMP_TYPE_Opaque | +-------+---------------------------------------------------------+ | 15 | SNMP_TYPE_noSuchObject | +-------+---------------------------------------------------------+ | 16 | SNMP_TYPE_noSuchInstance | +-------+---------------------------------------------------------+ | 17 | SNMP_TYPE_endOfMibView | +-------+---------------------------------------------------------+ Notes: 1. A 32-bit integer value has its base base type ORed with 128. 2. DisplayString is a textual convention. An SNMP PDU shows a type of OCTET_STRING for the value. An agent can handle such an object as DisplayString if the object is included in some Wijnen, Carpenter, Curran, Sehgal & Waters [Page 35] RFC 1592 SNMP-DPI March 1994 form of a compiled MIB for the agent. If not, the agent passes the value as an OCTET_STRING. 3.3.4 VALUE REPRESENTATION Values in the DPI packets are represented as follows: o 32-bit integers are 4-byte elements in network byte order, MSB (most significant byte) first, LSB (least significant byte) last. Example: '00000001'h represents 1. o 64-bit integers are 8-byte elements in network byte order, MSB first, LSB last. Example: '0000000100000001'h represents 4,294,967,297. o Object Identifiers are NULL terminated strings in the selected character set, representing the OID in ASN.1 dotted notation. The length includes the terminating NULL. Example ASCII: '312e332e362e312e322e312e312e312e3000'h represents "1.3.6.1.2.1.1.1.0" which is sysDescr.0. Example EBCDIC: 'f14bf34bf64bf14bf24bf14bf14bf14bf000'h represents "1.3.6.1.2.1.1.1.0" which is sysDescr.0. o DisplayStrings are in the selected character set. The length specifies the length of the string. Example ASCII: '6162630d0a'h represents "abc\r\n", no NULL. Example EBCDIC: '8182830d25'h represents "abc\r\n", no NULL. o IpAddress, NsapAddress and Opaque are implicit OCTET_STRING, so they are octets (e.g. IpAddress in network byte order). o NULL has a zero length for the value, no value data. o noSuchObject, noSuchInstance and endOfMibView are implicit NULL and represented as such. o BIT_STRING is an OCTET_STRING of the form uubbbb...bb, where the first octet (uu) is 0x00-0x07 and indicates the number of unused bits in the last octet (bb). The bb octets represent the bit string itself, where bit zero (0) comes first and so on. 3.3.5 CHARACTER SET SELECTION In the DPI OPEN packet, the sub-agent can specify the character set to be used for the representation of: o group and instance ID in the DPI REGISTER, UNREGISTER, GET, GETNEXT, GETBULK, SET, UNDO, COMMIT, RESPONSE and TRAP packets. o sub-agent ID and sub-agent Description in DPI OPEN packet. o Object Identifiers in the value field for a value of type SNMP_TYPE_OBJECT_IDENTIFIER. o DisplayString in the value field for a value of type SNMP_TYPE_DPI_DisplayString. The choice is the native character set or the ASCII character set. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 36] RFC 1592 SNMP-DPI March 1994 The native set is the set native to the platform where the agent runs. If the native set is ASCII, then character set selection is a moot point. On non-ASCII based platforms, the agent must convert between native and ASCII if the native character set is chosen. 3.3.6 ERROR CODE VALUES FOR SNMP DPI RESPONSE PACKETS When the RESPONSE packet is a response to a GET, GETNEXT, GETBULK, SET, COMMIT, or UNDO, then the error code can have one of the following values: Wijnen, Carpenter, Curran, Sehgal & Waters [Page 37] RFC 1592 SNMP-DPI March 1994 +-----------------------------------------------------------------+ | Table 18. Valid SNMP_ERROR values for RESPONSE error code | +-------+---------------------------------------------------------+ | VALUE | ERROR CODE | +-------+---------------------------------------------------------+ | 0 | SNMP_ERROR_noError | +-------+---------------------------------------------------------+ | 1 | SNMP_ERROR_tooBig | +-------+---------------------------------------------------------+ | 2 | SNMP_ERROR_noSuchName (SNMPv1, do not use) | +-------+---------------------------------------------------------+ | 3 | SNMP_ERROR_badValue (SNMPv1, do not use) | +-------+---------------------------------------------------------+ | 4 | SNMP_ERROR_readOnly (SNMPv1 do not use) | +-------+---------------------------------------------------------+ | 5 | SNMP_ERROR_genErr | +-------+---------------------------------------------------------+ | 6 | SNMP_ERROR_noAccess | +-------+---------------------------------------------------------+ | 7 | SNMP_ERROR_wrongType | +-------+---------------------------------------------------------+ | 8 | SNMP_ERROR_wrongLength | +-------+---------------------------------------------------------+ | 9 | SNMP_ERROR_wrongEncoding | +-------+---------------------------------------------------------+ | 10 | SNMP_ERROR_wrongValue | +-------+---------------------------------------------------------+ | 11 | SNMP_ERROR_noCreation | +-------+---------------------------------------------------------+ | 12 | SNMP_ERROR_inconsistentValue | +-------+---------------------------------------------------------+ | 13 | SNMP_ERROR_resourceUnavailable | +-------+---------------------------------------------------------+ | 14 | SNMP_ERROR_commitFailed | +-------+---------------------------------------------------------+ | 15 | SNMP_ERROR_undoFailed | +-------+---------------------------------------------------------+ | 16 | SNMP_ERROR_authorizationError | +-------+---------------------------------------------------------+ | 17 | SNMP_ERROR_notWritable | +-------+---------------------------------------------------------+ | 18 | SNMP_ERROR_inconsistentName | +-------+---------------------------------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 38] RFC 1592 SNMP-DPI March 1994 When the RESPONSE packet is a response to an OPEN, REGISTER or UNREGISTER, then the error code can have one of the following values: +-----------------------------------------------------------------+ | Table 19. Valid SNMP_ERROR_DPI values for RESPONSE error code | +-------+---------------------------------------------------------+ | VALUE | ERROR CODE | +-------+---------------------------------------------------------+ | 0 | SNMP_ERROR_DPI_noError | +-------+---------------------------------------------------------+ | 101 | SNMP_ERROR_DPI_otherError | +-------+---------------------------------------------------------+ | 102 | SNMP_ERROR_DPI_notFound | +-------+---------------------------------------------------------+ | 103 | SNMP_ERROR_DPI_alreadyRegistered | +-------+---------------------------------------------------------+ | 104 | SNMP_ERROR_DPI_higherPriorityRegistered | +-------+---------------------------------------------------------+ | 105 | SNMP_ERROR_DPI_mustOpenFirst | +-------+---------------------------------------------------------+ | 106 | SNMP_ERROR_DPI_notAuthorized | +-------+---------------------------------------------------------+ | 107 | SNMP_ERROR_DPI_viewSelectionNotSupported | +-------+---------------------------------------------------------+ | 108 | SNMP_ERROR_DPI_getBulkSelectionNotSupported | +-------+---------------------------------------------------------+ | 109 | SNMP_ERROR_DPI_duplicateSubAgentIdentifier | +-------+---------------------------------------------------------+ | 110 | SNMP_ERROR_DPI_invalidDisplayString | +-------+---------------------------------------------------------+ | 111 | SNMP_ERROR_DPI_characterSetSelectionNotSupported | +-------+---------------------------------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 39] RFC 1592 SNMP-DPI March 1994 3.3.7 UNREGISTER REASON CODES The following are valid reason codes in an UNREGISTER packet. +-----------------------------------------------------------------+ | Table 20. Valid UNREGISTER reason codes | +-------+---------------------------------------------------------+ | VALUE | REASON CODE | +-------+---------------------------------------------------------+ | 1 | SNMP_UNREGISTER_otherReason | +-------+---------------------------------------------------------+ | 2 | SNMP_UNREGISTER_goingDown | +-------+---------------------------------------------------------+ | 3 | SNMP_UNREGISTER_justUnregister | +-------+---------------------------------------------------------+ | 4 | SNMP_UNREGISTER_newRegistration | +-------+---------------------------------------------------------+ | 5 | SNMP_UNREGISTER_higherPriorityRegistered | +-------+---------------------------------------------------------+ | 6 | SNMP_UNREGISTER_byManager | +-------+---------------------------------------------------------+ | 7 | SNMP_UNREGISTER_timeout | +-------+---------------------------------------------------------+ Wijnen, Carpenter, Curran, Sehgal & Waters [Page 40] RFC 1592 SNMP-DPI March 1994 3.3.8 CLOSE REASON CODES The following are valid reason codes in a CLOSE packet. +-----------------------------------------------------------------+ | Table 21. Valid CLOSE reason codes | +-------+---------------------------------------------------------+ | VALUE | REASON CODE | +-------+---------------------------------------------------------+ | 1 | SNMP_CLOSE_otherReason | +-------+---------------------------------------------------------+ | 2 | SNMP_CLOSE_goingDown | +-------+---------------------------------------------------------+ | 3 | SNMP_CLOSE_unsupportedVersion | +-------+---------------------------------------------------------+ | 4 | SNMP_CLOSE_protocolError | +-------+---------------------------------------------------------+ | 5 | SNMP_CLOSE_authenticationFailure | +-------+---------------------------------------------------------+ | 6 | SNMP_CLOSE_byManager | +-------+---------------------------------------------------------+ | 7 | SNMP_CLOSE_timeout | +-------+---------------------------------------------------------+ | 8 | SNMP_CLOSE_openError | +-------+---------------------------------------------------------+ 4. DPI 2.0 MIB DEFINITION DPI20-MIB DEFINITIONS ::= BEGIN -- Objects in this MIB are implemented in the local SNMP agent. IMPORTS MODULE-IDENTITY, OBJECT-TYPE, snmpModules, enterprises FROM SNMPv2-SMI ibm OBJECT IDENTIFIER ::= { enterprises 2 } ibmDPI OBJECT IDENTIFIER ::= { ibm 2 } dpi20MIB OBJECT IDENTIFIER ::= { ibmDPI 1 } -- dpi20MIB MODULE-IDENTITY -- LAST-UPDATED "9401210000Z" -- ORGANIZATION "IBM Research - T.J. Watson Research Center" -- CONTACT-INFO " Bert Wijnen -- Postal: IBM International Operations -- Watsonweg 2 -- 1423 ND Uithoorn -- The Netherlands Wijnen, Carpenter, Curran, Sehgal & Waters [Page 41] RFC 1592 SNMP-DPI March 1994 -- Tel: +31 2975 53316 -- Fax: +31 2975 62468 -- E-mail: wijnen@vnet.ibm.com" -- DESCRIPTION "MIB module describing DPI objects." -- ::= { snmpModules x } dpiPort OBJECT IDENTIFIER ::= { dpi20MIB 1 } dpiPortForTCP OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The TCP port number on which the agent listens for DPI connections. A zero value means the agent has no DPI TCP port." ::= { dpiPort 1 } dpiPortForUDP OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The UDP port number on which the agent listens for DPI packets. A zero value means the agent has no DPI UDP port." ::= { dpiPort 2 } END 5. SUBAGENT CONSIDERATIONS When implementing a sub-agent, it is strongly recommended to use the DPI version 2 approach (SNMPv2 based). This means: o Use SNMPv2 error codes only (even though we have definitions for the old SNMPv1 error codes). o Do implement SET, COMMIT, UNDO processing properly. o For GET requests, use the SNMPv2 approach and pass back noSuchInstance or noSuchObject value if such is the case. Continue to process all remaining varBinds in this case. o For GETNEXT, use the SNMPv2 approach and pass back endOfMibView value if such is the case. Continue to process all remaining varBinds in this case. o When you are processing a request from the agent (GET, GETNEXT, GETBULK, SET, COMMIT, UNDO) you are supposed to respond within the timeout period (which you can specify in the OPEN and REGISTER packets). If you fail to respond within that timeout period, the agent will most probably close your DPI connection and then discard your RESPONSE packet if it comes in later. If you can detect that the response is not going to make it in Wijnen, Carpenter, Curran, Sehgal & Waters [Page 42] RFC 1592 SNMP-DPI March 1994 time, then you might decide to abort the request and return an SNMP_ERROR_genErr in the RESPONSE. o If you have a UDP "connected" sub-agent, or one that uses another unreliable protocol, you may want to issue an SNMP DPI ARE_YOU_THERE request once in a while to ensure that the agent is still alive and still knows about you. o When you are running on an EBCDIC based machine, and you use the (default) native character set, then all OID strings (as used for things like group ID, instance ID, Enterprise ID, sub-agent ID) and also all variable values of type OBJECT_IDENTIFIER or DisplayString will be passed to you in EBCDIC format. When you return a response, you should then also use EBCDIC FORMAT. o When you are running on an EBCDIC based machine, and you use the ASCII character set (specified in DPI OPEN), then all OID strings (as used for things like group ID, instance ID, Enterprise ID, sub-agent ID) and also all variable values of type OBJECT_IDENTIFIER or DisplayString will be passed to you in ASCII format. When you return a response, you should then also use ASCII FORMAT. o When you are running on an ASCII machine, then the character set selection for you basically is moot. Except maybe when you connect to an EBCDIC based agent, in which case you may want to specify in the DPI OPEN packet that you want to use ASCII character set. After that, all this is transparent to you and the burden of conversion is on the EBCDIC based agent. o Please realize that DisplayString is only a textual convention. In the SNMP PDU (SNMP packet), the type is just an OCTET_STRING, and from that it is not clear if this is a DisplayString or any arbitrary data. This means that the agent can only know about an object being a DisplayString if the object is included in some sort of a compiled MIB. If it is, then the agent will use SNMP_TYPE_DisplayString in the type field of the varBind in a DPI SET packet. When you send a DisplayString in a RESPONSE packet, the agent will handle it as such (e.g. translate EBCDIC to ASCII if needed). 5.1 DPI API The primary goal of this document is to specify the SNMP DPI, a protocol by which sub-agents can exchange SNMP related information with an agent. On top of this protocol, one can imagine one or possibly many Application Programming Interfaces, but those are not addressed in this document. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 43] RFC 1592 SNMP-DPI March 1994 However, in order to provide an environment that is more or less platform independent, we strongly suggest to also define a DPI API. We have a sample DPI API available, see 9, "Sample Sources for Anonymous FTP" for a place to obtain that sample DPI API. 5.2 OVERVIEW OF REQUEST PROCESSING 5.2.1 GET PROCESSING A GET request is the easiest to process. The DPI GET packet holds one or more varBinds that the sub-agent has taken responsibility for. If the sub-agent encounters an error while processing the request, it creates a DPI RESPONSE packet with an appropriate error indication in the error_code field and sets the error_index to the position of the varBind at which the error occurs (first varBind is index 1, second varBind is index 2, and so on). No name/type/length/value information needs to be provided in the packet, because by definition, the varBind information is the same as in the request to which this is a response, and the agent still has that information. If there are no errors, then the sub-agent creates a DPI RESPONSE packet in which the error_code is set to SNMP_ERROR_noError (zero) and error_index is set to zero. The packet must also include the name/type/length/value of each varBind requested. When you get a request for a non-existing object or a non-existing instance of an object, then you must return a NULL value with a type of SNMP_TYPE_noSuchObject or SNMP_TYPE_noSuchInstance respectively. These two values are not considered errors, so the error_code and error_index should be zero. The DPI RESPONSE packet is then sent back to the agent. 5.2.2 SET PROCESSING Processing a DPI SET request is more difficult than a DPI GET request. In the case of a DPI SET packet, additional information is available in the packet, namely the value type, value length and value to be set. If the sub-agent encounters an error while processing the request, it creates a DPI RESPONSE packet with an appropriate error indication in the error_code field and an error_index listing the position of the varBind at which the error occurs (first varBind is index 1, second varBind is index 2, and so on). No name/type/length/value information needs to provided in the packet, because by definition, the varBind information is the same as in the request to which this Wijnen, Carpenter, Curran, Sehgal & Waters [Page 44] RFC 1592 SNMP-DPI March 1994 is a response, and the agent still has that information. If there are no errors, then the sub-agent creates a DPI RESPONSE packet in which the error_code is set to SNMP_ERROR_noError (zero) and error_index is set to zero. No name/type/length/value information is needed; by definition the RESPONSE to a SET should contain exactly the same varBind data as the data present in the request, so the agent can use the values it already has. (This suggests that the agent must keep state information, and that is indeed the case. It needs to do that anyway in order to be able to later pass the data with a DPI COMMIT or DPI UNDO packet). The sub- agent must have allocated the required resources and prepared itself for the SET. It does not yet effectuate the set, that will be done at COMMIT time. The sub-agent sends a DPI RESPONSE packet (indicating success or failure for the preparation phase) back to the agent. The agent will then issue a SET request for all other varBinds in the same original SNMP request it received. This may be to the same or to one or more different sub-agents. Once all SET requests have returned a "no error" condition, the agent starts sending DPI COMMIT packets to the sub-agent(s). If any SET request returns an error, then the agent sends DPI UNDO packets to those sub-agents that indicated successful processing of the SET preparation phase. When the sub-agent receives the DPI COMMIT packet, again all the varBind information will be available in the packet. The sub-agent can now effectuate the SET request. If the sub-agent encounters an error while processing the COMMIT request, it creates a DPI RESPONSE packet with value SNMP_ERROR_commitFailed in the error_code field and an error_index that lists at which varBind the error occurs (first varBind is index 1 and so on). No name/type/length/value information is needed. The fact that a commitFailed error exists does not mean that this error should be returned easily. A sub-agent should do all that is possible to make a COMMIT succeed. If there are no errors, and the SET/COMMIT has been effectuated with success, then the sub-agent creates a DPI RESPONSE packet in which the error_code is set to SNMP_ERROR_noError (zero) and error_index is set to zero. No name/type/length/value information is needed. So far we have discussed a SET, COMMIT sequence. That happens if all goes well. However, after a successful SET, the sub-agent may receive a DPI UNDO packet. The sub-agent must now undo any preparations it made during the SET processing (like free allocated Wijnen, Carpenter, Curran, Sehgal & Waters [Page 45] RFC 1592 SNMP-DPI March 1994 memory and such). Even after a COMMIT, a sub-agent may still receive a DPI UNDO packet. This is the case if some other sub-agent could not complete a COMMIT request. Because of the SNMP-requirement that all varBinds in a single SNMP SET request must be changed "as if simultaneous", all committed changes must be undone if any of the COMMIT requests fail. In this case the sub-agent must try and undo the committed SET operation. If the sub-agent encounters an error while processing the UNDO request, it creates a DPI RESPONSE packet with value SNMP_ERROR_undoFailed in the error_code field and an error_index that lists at which varBind the error occurs (first varBind is index 1 and so on). No name/type/length/value information is needed. The fact that an undoFailed error exists does not mean that this error should be returned easily. A sub-agent should do all that is possible to make an UNDO succeed. If there are no errors, and the UNDO has been effectuated with success, then the sub-agent creates a DPI RESPONSE packet in which the error_code is set to SNMP_ERROR_noError (zero) and error_index is set to zero. No name/type/length/value information is needed. 5.2.3 GETNEXT PROCESSING GETNEXT requests are a bit more complicated to process than a GET. The DPI GETNEXT packet contains the object(s) on which the GETNEXT operation must be performed. The semantics of the operation are that the sub-agent is to return the name/type/length/value of the next variable it supports whose (ASN.1) name lexicographically follows the one passed in the group ID (sub-tree) and instance ID. In this case, the instance ID may not be present (NULL) implying that the NEXT object must be the first instance of the first object in the sub-tree that was registered. It is important to realize that a given sub-agent may support several discontiguous sections of the MIB tree. In such a situation it would be incorrect to jump from one section to another. This problem is correctly handled by examining the group ID in the DPI packet. This group ID represents the "reason" why the sub-agent is being called. It holds the prefix of the tree that the sub-agent had indicated it supported (registered). If the next variable supported by the sub-agent does not begin with that prefix, the sub-agent must return the same object instance as in the request (e.g. group ID and instance ID) with a value of SNMP_TYPE_endOfMibView (implied NULL value). This endOfMibView is not considered an error, so the error_code and error_index should be Wijnen, Carpenter, Curran, Sehgal & Waters [Page 46] RFC 1592 SNMP-DPI March 1994 zero. If required, the SNMP agent will call upon the sub-agent again, but pass it a different group ID (prefix). This is illustrated in the discussion below. Assume there are two sub-agents. The first sub-agent registers two distinct sections of the tree, A and C. In reality, the sub-agent supports variables A.1 and A.2, but it correctly registers the minimal prefix required to uniquely identify the variable class it supports. The second sub-agent registers a different section, B, which appears between the two sections registered by the first agent. If a management station begins dumping the MIB, starting from A, the following sequence of queries of the form get-next(group ID, instance ID) would be performed: Sub-agent 1 gets called: get-next(A,none) = A.1 get-next(A,1) = A.2 get-next(A,2) = endOfMibView Sub-agent 2 is then called: get-next(B,none) = B.1 get-next(B,1) = endOfMibView Sub-agent 1 gets called again: get-next(C,none) = C.1 5.2.4 GETBULK PROCESSING You can ask the agent to translate GETBULK requests into multiple GETNEXT requests. This is basically the default and it is specified in the DPI REGISTER packet. In principle, we expect the majority of DPI sub-agents to run on the same machine as the agent (or otherwise, on the same physical network), so repetitive GETNEXT requests stay local and in general should not be a problem. If experience tells us different, the sub-agent can tell the agent to pass on a DPI GETBULK packet. When a GETBULK request is received, the sub-agent must process the request and send a RESPONSE that sends back as many varBinds as requested by the request, as long as they fit with in the buffers. The GETBULK requires similar processing as a GETNEXT with regard to endOfMibView handling. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 47] RFC 1592 SNMP-DPI March 1994 5.2.5 OPEN REQUEST As the very first step, a DPI sub-agent must open a "connection" with the agent. To do so, it must send a DPI OPEN packet in which these things must be specified: o The max timeout value in seconds. The agent is requested to wait this long for a response to any request for an object being handled by this sub-agent. The agent may have an absolute maximum timeout value which will be used if the sub-agent asks for too big a timeout value. A value of zero can be used to indicate that the agent's own default timeout value should be used. A sub-agent is advised to use a reasonably short interval of a few seconds or so. If a specific sub-tree needs a (much) longer time, then a specific REGISTER can be done for that sub-tree with a longer timeout value. o The maximum number of varBinds that the sub-agent is prepared to handle per DPI packet. Specifying 1 would result in DPI version 1 behavior of one varBind per DPI packet that the agent sends to the sub-agent. o The character set you want to use. By default (value 0) this is the native character set of the machine (platform) where the agent runs. Since the sub-agent and agent normally run on the same system or platform, you want to use the native character set (which on many platforms is ASCII anyway). If your platform is EBCDIC based, then using the native character set of EBCDIC makes it easy to recognize the string representations of the fields like group ID, instance ID, etc. At the same time, the agent will translate the value from ASCII NVT to EBCDIC (and vice versa) for objects that it knows (from a compiled MIB) to have a textual convention of DisplayString. Be aware that this fact cannot be determined from the SNMP PDU encoding because in the PDU the object is only known to be an OCTET_STRING. If your sub-agent runs on an ASCII based platform and the agent runs on an EBCDIC based platform (or the other way around), then you can specify that you want to use the ASCII character set, and so you both know how to handle the string-based data. Beware that not all agents need to support other than native character set selection. See 5, "Subagent Considerations" and 3.3.5, "Character set selection" for more information on character set usage. o The sub-agent ID. This an ASN.1 Object Identifier that uniquely identifies the sub-agent. This OID is represented as a null terminated string using the selected character set. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 48] RFC 1592 SNMP-DPI March 1994 Example: "1.3.5.1.2.3.4.5". o The sub-agent Description. This is a DisplayString describing the sub-agent. This is a character string using the selected character set. Example: "DPI sample sub-agent version 2.0" Once a sub-agent has sent a DPI OPEN packet to an agent, it should expect a DPI RESPONSE packet that informs the sub-agent about the result of the request. The packet ID of the RESPONSE packet should be the same as that of the OPEN request to which the RESPONSE packet is the response. See Table 19 for a list of valid DPI RESPONSE error codes that may be expected. If you receive an error RESPONSE on the OPEN packet, then you will also receive a DPI CLOSE packet with an SNMP_CLOSE_openError code, and then the agent closes the "connection". If the OPEN is accepted, then the next step is to REGISTER one or more MIB sub-trees. 5.2.6 CLOSE REQUEST When a sub-agent is finished and wants to terminate it should first UNREGISTER its sub-trees and then close the "connection" with the agent. To do so, it must send a DPI CLOSE packet in which it specifies a reason for the closing. See Table 21 for a list of valid CLOSE reason codes. You should not expect a response to the CLOSE request. A sub-agent should also be prepared to handle an incoming DPI CLOSE packet from the agent. Again, the packet will contain a reason code for the CLOSE request. A sub-agent need not send a response to a CLOSE request. The agent just assumes that the sub-agent will handle it appropriately. The close takes place, no matter what the sub- agent does with it. 5.2.7 REGISTER REQUEST Before a sub-agent will receive any requests for MIB variables it must first register the variables or sub-tree it supports with the SNMP agent. The sub-agent must specify a number of things in the REGISTER request: o The sub-tree to be registered. This is a null terminated string in the selected character set. The sub-tree must have a trailing dot (example: "1.3.6.1.2.3.4.5."). o The requested priority for the registration, one of: -1 Request for best available priority. 0 Request for next better available priority than highest priority currently registered for this sub-tree. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 49] RFC 1592 SNMP-DPI March 1994 NNN Any other positive value requests that specific priority if available or the first worse priority that is available. o The max timeout value in seconds. The agent is requested to wait this long for a response to any request for an object in this sub-tree. The agent may have an absolute maximum timeout value which will be used if the sub-agents asks for too big a timeout value. A value of zero can be used to indicate that the DPI OPEN value should be used for timeout. o A specification if the sub-agent wants to do view selection. If it does, then the community name (from SNMPv1 packets) will be passed in the DPI GET, GETNEXT, SET packets). o A specification if the sub-agent wants to receive GETBULK packets or if it just prefers that the agent converts a GETBULK into multiple GETNEXT requests. Once a sub-agent has sent a DPI REGISTER packet to the agent, it should expect a DPI RESPONSE packet that informs the sub-agent about the result of the request. The packet ID of the RESPONSE packet should be the same as that of the REGISTER packet to which the RESPONSE packet is the response. If the response indicates success, then the error_index field in the RESPONSE packet contains the priority that the agent assigned to the sub-tree registration. See Table 19 for a list of valid DPI RESPONSE error codes that may be expected. 5.2.8 UNREGISTER REQUEST A sub-agent may unregister a previously registered sub-tree. The sub-agent must specify a few things in the UNREGISTER request: o The sub-tree to be unregistered. This is a null terminated string in the selected character set. The sub-tree must have a trailing dot (example: "1.3.6.1.2.3.4.5."). o The reason for the unregister. See Table 20 for a list of valid reason codes. Once a sub-agent has sent a DPI UNREGISTER packet to the agent, it should expect a DPI RESPONSE packet that informs the sub-agent about the result of the request. The packet ID of the RESPONSE packet should be the same as that of the REGISTER packet to which the RESPONSE packet is the response. See Table 19 for a list of valid DPI RESPONSE error codes that may be expected. A sub-agent should also be prepared to handle incoming DPI UNREGISTER packets from the agent. Again, the DPI packet will contain a reason code for the UNREGISTER. A sub-agent need not send a response to an UNREGISTER request. The agent just assumes that the sub-agent will handle it appropriately. The registration is removed, no matter what Wijnen, Carpenter, Curran, Sehgal & Waters [Page 50] RFC 1592 SNMP-DPI March 1994 the sub-agent returns. 5.2.9 TRAP REQUEST A sub-agent can request that the SNMP agent generates a trap for it. The sub-agent must provide the desired values for the generic and specific parameters of the trap. It may optionally provide a set of one or more name/type/length/value tuples that will be included in the trap packet. Also, it may optionally specify an Enterprise ID (Object Identifier) for the trap to be generated. If a NULL value is specified for the Enterprise ID, then the agent will use the sub- agent Identifier (from the DPI OPEN packet) as the Enterprise ID to be sent with the trap. 5.2.10 ARE_YOU_THERE REQUEST A sub-agent can send an ARE_YOU_THERE packet to the agent. This may be useful to do if you have a DPI "connection" over an unreliable transport protocol (like UDP). If the "connection" is in a healthy state, the agent responds with a RESPONSE packet with SNMP_ERROR_DPI_noError. If the "connection" is not in a healthy state, the agent may respond with a RESPONSE packet with an error indication, but the agent might not react at all, so you would timeout while waiting for a response. 5.2.11 HOW TO QUERY THE DPI PORT. The DPI API implementations are encouraged to provide a facility that helps DPI sub-agent programmers to dynamically find the port that the agent is using for the TCP and/or UDP DPI port(s). A suggested name for such a function is: query_DPI_port(). 6. REFERENCES [1] Case, J., Fedor, M., Schoffstall M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [2] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 51] RFC 1592 SNMP-DPI March 1994 [3] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987. [4] McCloghrie, K., and M. Rose, "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. [5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [6] Rose, M., "SNMP MUX Protocol and MIB", RFC 1227, Performance Systems International, RFC 1227, May 1991. [7] Carpenter G., and B. Wijnen, "SNMP-DPI, Simple Network Management Protocol Distributed Program Interface", RFC 1228, International Business Machines, Inc., May 1991. [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "SNMPv2 RFCs (RFC 1441 through RFC 1452)", SNMP Research Inc, Hughes LAN Systems, Dover Beach Consulting Inc, Carnegie Mellon University, Trusted Information Systems, April 1993. [9] International Business Machines, Inc., TCP/IP for VM: Programmer's Reference, SC31-6084-0, 1990. [10] International Business Machines, Inc., Virtual Machine System Facilities for Programming, Release 6, SC24-5288-01, 1988. 7. SECURITY CONSIDERATIONS Security issues are not discussed in this memo. Wijnen, Carpenter, Curran, Sehgal & Waters [Page 52] RFC 1592 SNMP-DPI March 1994 8. AUTHORS' ADDRESSES Bert Wijnen IBM International Operations Watsonweg 2 1423 ND Uithoorn The Netherlands Phone: +31-2975-53316 Fax: +31-2975-62468 EMail: wijnen@vnet.ibm.com Geoffrey C. Carpenter IBM T.J. Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598 USA Phone: +1-914-945-1970 EMail: gcc@watson.ibm.com Kim Curran Bell Northern Research Ltd. P.O. Box 3511 Station C Ottawa, Ontario K1Y 4HY Canada Phone: +1-613-763-5283 EMail: kcurran@bnr.ca Aditya Sehgal Bell Northern Research Ltd. P. O. Box 3511 Station C Ottawa, Ontario K1Y 4HY Canada Phone: +1-613-763-8821 EMail: asehgal@bnr.ca Wijnen, Carpenter, Curran, Sehgal & Waters [Page 53] RFC 1592 SNMP-DPI March 1994 Glen Waters Bell Northern Research Ltd. P.O. Box 3511 Station C Ottawa, Ontario K1Y 4HY Canada Phone: +1-613-763-3933 EMail: gwaters@bnr.ca 9. SAMPLE SOURCES FOR ANONYMOUS FTP An implementation sample of a DPI API (as used at the agent and sub- agent side) plus sample sub-agent code and documentation are available for anonymous FTP from: software.watson.ibm.com (129.34.139.5) To obtain the source, perform the following steps: ftp software.watson.ibm.com user: anonymous password: your_e-mail_address cd /public/dpi get README binary get dpi_api.tar (or compressed dpi_api.tar.Z) quit Wijnen, Carpenter, Curran, Sehgal & Waters [Page 54] snmp-mibs-downloader-1.1/mibrfcs/rfc1593.txt0000644000000000000000000062601211402176071015572 0ustar Network Working Group W. McKenzie Request for Comments: 1593 J. Cheng Category: Informational IBM Networking Systems March 1994 SNA APPN Node MIB Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 APPN Node Group . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 APPN Node General Information . . . . . . . . . . . . . 4 2.1.2 APPN Network Node Information . . . . . . . . . . . . . 6 2.1.3 APPN End Node Information . . . . . . . . . . . . . . . 8 2.1.4 APPN Port Information . . . . . . . . . . . . . . . . 10 2.1.4.1 General Port Information . . . . . . . . . . . . . 10 2.1.4.2 TCP/IP Port Information . . . . . . . . . . . . . 14 2.1.4.3 Data Link Switch Port Information . . . . . . . . 15 2.1.4.4 Token Ring Port Information . . . . . . . . . . . 16 2.1.4.5 Port DLC Trace Information . . . . . . . . . . . . 17 2.1.5 APPN Link Station Information . . . . . . . . . . . . 23 2.1.5.1 General Link Station Information . . . . . . . . . 23 2.1.5.2 TCP/IP Link Station Information . . . . . . . . . 35 2.1.5.3 Data Link Switch Link Station Information . . . . 37 2.1.5.4 Token Ring Link Station Information . . . . . . . 39 2.1.5.5 Link Station Status Information . . . . . . . . . 41 2.1.6 SNMP Performance Information for APPN Subagent . . . . 46 2.1.7 Performance Information for APPN Node . . . . . . . . 49 2.1.8 XID Statistics . . . . . . . . . . . . . . . . . . . . 50 2.2 APPN Topology Group . . . . . . . . . . . . . . . . . . . 51 2.2.1 Topology Performance Information . . . . . . . . . . . 52 2.2.1.1 Topology Route Information . . . . . . . . . . . . 58 2.2.2 Adjacent Node Table . . . . . . . . . . . . . . . . . 60 2.2.3 Network Node Topology . . . . . . . . . . . . . . . . 62 2.2.3.1 NN Topology Table (Indexed by Node Name) . . . . . 62 McKenzie & Cheng [Page 1] RFC 1593 SNA APPN Node MIB March 1994 2.2.3.2 NN TG Table (Indexed by Node Names and TG Number) 66 2.2.3.3 NN Topology Table (Indexed by FRSN and Node Name) 73 2.2.3.4 NN TG Table (Indexed by FRSN, Node Names, and TG Number) . . . . . . . . . . . . . . . . . . . . . 77 2.3 APPN Node Local Topology Group . . . . . . . . . . . . . . 83 2.3.1 Local Topology This Node . . . . . . . . . . . . . . . 84 2.3.1.1 Local General Information . . . . . . . . . . . . 84 2.3.1.2 Local NN Specific Information . . . . . . . . . . 85 2.3.1.3 Local TG Information . . . . . . . . . . . . . . . 87 2.3.2 Client End Nodes Topology Known to Serving NN . . . . 93 2.3.2.1 Client End Nodes Information . . . . . . . . . . . 93 2.3.2.2 Client End Nodes TG Information (Tail Vectors) . . 94 2.4 APPN Directory Group . . . . . . . . . . . . . . . . . . . 99 2.4.1 Directory Performance Information . . . . . . . . . . 99 2.4.2 Directory Cache Table . . . . . . . . . . . . . . . . 102 2.5 APPN Class Of Service Group . . . . . . . . . . . . . . . 105 2.5.1 COS Mode Table . . . . . . . . . . . . . . . . . . . . 108 2.5.2 COS Name Table . . . . . . . . . . . . . . . . . . . . 109 2.5.3 COS Node Row Table . . . . . . . . . . . . . . . . . . 110 2.5.4 COS TG Row Table . . . . . . . . . . . . . . . . . . . 113 3.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 119 4.0 Security Considerations . . . . . . . . . . . . . . . . . . 119 5.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 120 1.0 Introduction This module contains managed objects which describe the following: o The APPN node (either an APPN network node or an APPN end node) o The connections of the node to other SNA nodes o The APPN network topology (as reflected in the network topology database that is replicated in each APPN network node. This module does not describe the SNA logical units (LUs) served by the APPN node nor does it describe the sessions between LUs. Managed objects for that information are under development. McKenzie & Cheng [Page 2] RFC 1593 SNA APPN Node MIB March 1994 2.0 Definitions IBM-6611-APPN-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises, Counter, IpAddress, Gauge, TimeTicks FROM RFC1155-SMI DisplayString FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; -- ****************************************************************** ibm OBJECT IDENTIFIER ::= { enterprises 2 } ibmProd OBJECT IDENTIFIER ::= { ibm 6 } ibm6611 OBJECT IDENTIFIER ::= { ibmProd 2 } ibmappn OBJECT IDENTIFIER ::= { ibm6611 13 } -- ******************** The APPN Node Group ********************* ibmappnNode OBJECT IDENTIFIER ::= { ibmappn 1 } ibmappnGeneralInfoAndCaps OBJECT IDENTIFIER ::= { ibmappnNode 1 } ibmappnNnUniqueInfoAndCaps OBJECT IDENTIFIER ::= { ibmappnNode 2 } ibmappnEnUniqueCaps OBJECT IDENTIFIER ::= { ibmappnNode 3 } ibmappnPortInformation OBJECT IDENTIFIER ::= { ibmappnNode 4 } ibmappnLinkStationInformation OBJECT IDENTIFIER ::= { ibmappnNode 5 } ibmappnSnmpInformation OBJECT IDENTIFIER ::= { ibmappnNode 6 } ibmappnMemoryUse OBJECT IDENTIFIER ::= { ibmappnNode 7 } ibmappnXidInformation OBJECT IDENTIFIER ::= { ibmappnNode 8 } -- This group provides global information about the -- APPN node, which is either a network node or an end node. -- The first section applies to all APPN nodes. -- The second section applies only to network nodes. -- The third section applies only to end nodes. -- The fourth section applies to Port information. -- The fifth section applies to SNA link station Information. -- The sixth section applies to SNMP traffic for this APPN sub-agent -- The seventh section applies to APPN memory usage. -- The eighth section applies to XID activities. McKenzie & Cheng [Page 3] RFC 1593 SNA APPN Node MIB March 1994 -- APPN General Information -- This section applies to both network and end nodes. ibmappnNodeCpName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned network name for this node in the format NETID.CPNAME." ::= { ibmappnGeneralInfoAndCaps 1 } ibmappnNodeNetid OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned APPN network identification, which can be from one to eight characters. This ID is used with the control point name to create a fully-qualified control point name." ::= { ibmappnGeneralInfoAndCaps 2 } ibmappnNodeBlockNum OBJECT-TYPE SYNTAX DisplayString (SIZE (3)) ACCESS read-only STATUS mandatory DESCRIPTION "The block number is the first three digits of the node_id. These 3 hexadecimal digits identify the product and are not configurable." ::= { ibmappnGeneralInfoAndCaps 3 } ibmappnNodeIdNum OBJECT-TYPE SYNTAX DisplayString (SIZE (5)) ACCESS read-only STATUS mandatory DESCRIPTION "The ID number is the last 5 digits of the node_id. These 5 hexadecimal digits are administratively defined and combined with the 3 digit block number form the node_id. This node_id is used to identify the local node and is include in APPN alerts as well as being included in XIDs. A unique value is required for connections to SNA McKenzie & Cheng [Page 4] RFC 1593 SNA APPN Node MIB March 1994 sub-area." ::= { ibmappnGeneralInfoAndCaps 4 } ibmappnNodeType OBJECT-TYPE SYNTAX INTEGER { networkNode(1), endNode(2), len(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Type of APPN node, either network, len, or end node." ::= { ibmappnGeneralInfoAndCaps 5 } ibmappnNodeUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "Time (in hundredths of a second) since this APPN node was initialized." ::= { ibmappnGeneralInfoAndCaps 6 } ibmappnNodeNegotLs OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports negotiable link stations." ::= { ibmappnGeneralInfoAndCaps 7 } ibmappnNodeSegReasm OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports segment reassembly. This is only supported when segment generation is also supported." ::= { ibmappnGeneralInfoAndCaps 8 } McKenzie & Cheng [Page 5] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNodeBindReasm OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports Bind segment reassembly. This will only be supported when Bind segment generation is also supported." ::= { ibmappnGeneralInfoAndCaps 9 } ibmappnNodeParallelTg OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports parallel TGs." ::= { ibmappnGeneralInfoAndCaps 10 } ibmappnNodeService OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node allows call-in from nodes not defined locally." ::= { ibmappnGeneralInfoAndCaps 11 } ibmappnNodeAdaptiveBindPacing OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports adaptive bind pacing." ::= { ibmappnGeneralInfoAndCaps 12 } -- ************************************************************** -- APPN Network Node Information -- This section provides global information about the -- APPN network node. ibmappnNodeNnRcvRegChar OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} McKenzie & Cheng [Page 6] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports receiving registered characteristics." ::= { ibmappnNnUniqueInfoAndCaps 1 } ibmappnNodeNnGateway OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this is a gateway node." ::= { ibmappnNnUniqueInfoAndCaps 2 } ibmappnNodeNnCentralDirectory OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports central directory cache." ::= { ibmappnNnUniqueInfoAndCaps 3 } ibmappnNodeNnTreeCache OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports route tree cache." ::= { ibmappnNnUniqueInfoAndCaps 4 } ibmappnNodeNnTreeUpdate OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports incremental_tree_update, which is only supported when tree caching is supported." ::= { ibmappnNnUniqueInfoAndCaps 5 } ibmappnNodeNnRouteAddResist OBJECT-TYPE McKenzie & Cheng [Page 7] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Route addition resistance is a value that indicates the relative desirability of using this node for intermediate session traffic. The value, which can be any integer 0-255, is used in route computation. The lower the value, the more desirable the node is for intermediate routing." ::= { ibmappnNnUniqueInfoAndCaps 6 } ibmappnNodeNnIsr OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node supports intermediate session routing." ::= { ibmappnNnUniqueInfoAndCaps 7 } ibmappnNodeNnFrsn OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This object is the last FRSN sent in a topology update to adjacent network nodes." ::= { ibmappnNnUniqueInfoAndCaps 8 } -- ************************************************************** -- APPN End Node Information ibmappnNodeEnSegGen OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this end node supports segment generation." McKenzie & Cheng [Page 8] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnEnUniqueCaps 1 } ibmappnNodeEnModeCosMap OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this end node supports mode name to COS name mapping." ::= { ibmappnEnUniqueCaps 2 } ibmappnNodeEnLocateCdinit OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this end node supports Locate Cdinit." ::= { ibmappnEnUniqueCaps 3 } ibmappnNodeEnSendRegNames OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node will register its LUs with the adjacent serving network node: NO - do not register names YES - register names" ::= { ibmappnEnUniqueCaps 4 } ibmappnNodeEnSendRegChar OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node supports send register characteristics, which is only supported when send registered names is also supported." ::= { ibmappnEnUniqueCaps 5 } McKenzie & Cheng [Page 9] RFC 1593 SNA APPN Node MIB March 1994 -- ************************************************************** -- APPN Port information -- ibmappnNodePortTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodePortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Port table describes the configuration and current status of the ports used by APPN. The type of DLC is included in this table as a pointer to the DLC port specific tables." ::= { ibmappnPortInformation 1 } ibmappnNodePortEntry OBJECT-TYPE SYNTAX IbmappnNodePortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Port Name is used as the index to this table." INDEX { ibmappnNodePortName } ::= { ibmappnNodePortTable 1 } IbmappnNodePortEntry ::= SEQUENCE { ibmappnNodePortName DisplayString, ibmappnNodePortState INTEGER, ibmappnNodePortDlcType INTEGER, ibmappnNodePortPortType INTEGER, ibmappnNodePortSIMRIM INTEGER, ibmappnNodePortLsRole INTEGER, ibmappnNodePortMaxRcvBtuSize INTEGER, ibmappnNodePortMaxIframeWindow INTEGER, ibmappnNodePortDefLsGoodXids Counter, ibmappnNodePortDefLsBadXids Counter, ibmappnNodePortDynLsGoodXids Counter, ibmappnNodePortDynLsBadXids Counter, ibmappnNodePortSpecific OBJECT IDENTIFIER } ibmappnNodePortName OBJECT-TYPE McKenzie & Cheng [Page 10] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this APPN port. The name can be from one to eight characters." ::= { ibmappnNodePortEntry 1 } ibmappnNodePortState OBJECT-TYPE SYNTAX INTEGER { inactive(1), pendactive(2), active(3), pendinact(4) } ACCESS read-write STATUS mandatory DESCRIPTION "Indicates the current state of this port." ::= { ibmappnNodePortEntry 2 } ibmappnNodePortDlcType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following sdlc(2), dls(3), socket(4), ethernet(5), tokenRing(6) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of DLC interface, distinguished according to the protocol immediately 'below' this layer." ::= { ibmappnNodePortEntry 3 } ibmappnNodePortPortType OBJECT-TYPE SYNTAX INTEGER { leased(1), switched(2), sharedAccessFacilities(3) } ACCESS read-only STATUS mandatory McKenzie & Cheng [Page 11] RFC 1593 SNA APPN Node MIB March 1994 DESCRIPTION "Identifies the type of line used by this port." ::= { ibmappnNodePortEntry 4 } ibmappnNodePortSIMRIM OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether Set Initialization Mode (SIM) and Receive Initialization Mode (RIM) are supported." ::= { ibmappnNodePortEntry 5 } ibmappnNodePortLsRole OBJECT-TYPE SYNTAX INTEGER { primary(1), secondary(2), negotiable(3), abm(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Initial role for LSs activated through this port, where 'abm' indicates asynchronous balance mode." ::= { ibmappnNodePortEntry 6 } ibmappnNodePortMaxRcvBtuSize OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum Basic Transmission Size (BTU) that a link station on this port can receive." ::= { ibmappnNodePortEntry 7 } ibmappnNodePortMaxIframeWindow OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum number of I-frames that can be received by the XID sender before an acknowledgement is received." McKenzie & Cheng [Page 12] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNodePortEntry 8 } ibmappnNodePortDefLsGoodXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of successfull XIDs that have occurred on all defined link stations on this port since the last time this port was started." ::= { ibmappnNodePortEntry 9 } ibmappnNodePortDefLsBadXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of unsuccessfull XIDs that have occurred on all defined link stations on this port since the last time this port was started." ::= { ibmappnNodePortEntry 10 } ibmappnNodePortDynLsGoodXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of successfull XIDs that have occurred on all dynamic link stations on this port since the last time this port was started." ::= { ibmappnNodePortEntry 11 } ibmappnNodePortDynLsBadXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of unsuccessfull XIDs that have occurred on all dynamic link stations on this port since the last time this port was started." ::= { ibmappnNodePortEntry 12 } ibmappnNodePortSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER McKenzie & Cheng [Page 13] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "Identifies the port specific OBJECT IDENTIFIER that can provide additional information." ::= { ibmappnNodePortEntry 13 } -- ************************************************************** -- -- ibmappnNodePortIpTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodePortIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Port table (TCP/IP specific)." ::= { ibmappnPortInformation 2 } ibmappnNodePortIpEntry OBJECT-TYPE SYNTAX IbmappnNodePortIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The IP Name is used as the index to this table." INDEX {ibmappnNodePortIpName } ::= { ibmappnNodePortIpTable 1 } IbmappnNodePortIpEntry ::= SEQUENCE { ibmappnNodePortIpName DisplayString, ibmappnNodePortIpPortNum INTEGER } ibmappnNodePortIpName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this APPN port. The name can be from one to eight characters." McKenzie & Cheng [Page 14] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNodePortIpEntry 1 } ibmappnNodePortIpPortNum OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Local TCP/IP port number." ::= { ibmappnNodePortIpEntry 2 } -- ************************************************************** -- -- ibmappnNodePortDlsTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodePortDlsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Port table (DLS specific)." ::= { ibmappnPortInformation 3 } ibmappnNodePortDlsEntry OBJECT-TYPE SYNTAX IbmappnNodePortDlsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The DLS Name is used as the index to this table." INDEX {ibmappnNodePortDlsName } ::= { ibmappnNodePortDlsTable 1 } IbmappnNodePortDlsEntry ::= SEQUENCE { ibmappnNodePortDlsName DisplayString, ibmappnNodePortDlsMac OCTET STRING, ibmappnNodePortDlsSap OCTET STRING } ibmappnNodePortDlsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory McKenzie & Cheng [Page 15] RFC 1593 SNA APPN Node MIB March 1994 DESCRIPTION "Administratively-assigned name for this APPN DLS port. The name can be from one to eight characters." ::= { ibmappnNodePortDlsEntry 1 } ibmappnNodePortDlsMac OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "Local DLS MAC address." ::= { ibmappnNodePortDlsEntry 2 } ibmappnNodePortDlsSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) ACCESS read-only STATUS mandatory DESCRIPTION "Local DLS Sap address." ::= { ibmappnNodePortDlsEntry 3 } -- ************************************************************** -- -- ibmappnNodePortTrTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodePortTrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Port table (Token Ring specific)." ::= { ibmappnPortInformation 4 } ibmappnNodePortTrEntry OBJECT-TYPE SYNTAX IbmappnNodePortTrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The TR Name is used as the index to this table." INDEX {ibmappnNodePortTrName } McKenzie & Cheng [Page 16] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNodePortTrTable 1 } IbmappnNodePortTrEntry ::= SEQUENCE { ibmappnNodePortTrName DisplayString, ibmappnNodePortTrMac OCTET STRING, ibmappnNodePortTrSap OCTET STRING } ibmappnNodePortTrName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this APPN port. The name can be from one to eight characters." ::= { ibmappnNodePortTrEntry 1 } ibmappnNodePortTrMac OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "Local Token Ring MAC address." ::= { ibmappnNodePortTrEntry 2 } ibmappnNodePortTrSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) ACCESS read-only STATUS mandatory DESCRIPTION "Local Token Ring Sap address." ::= { ibmappnNodePortTrEntry 3 } -- ************************************************************** -- APPN generic DLC Trace -- ibmappnNodePortDlcTraceTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodePortDlcTraceEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Port table generic DLC trace table." McKenzie & Cheng [Page 17] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnPortInformation 5 } ibmappnNodePortDlcTraceEntry OBJECT-TYPE SYNTAX IbmappnNodePortDlcTraceEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Port name and a dynamic integer are the index to this table." INDEX {ibmappnNodePortDlcTracPortName, ibmappnNodePortDlcTracIndex} ::= { ibmappnNodePortDlcTraceTable 1 } IbmappnNodePortDlcTraceEntry ::= SEQUENCE { ibmappnNodePortDlcTracPortName DisplayString, ibmappnNodePortDlcTracIndex INTEGER, ibmappnNodePortDlcTracDlcType INTEGER, ibmappnNodePortDlcTracLocalAddr DisplayString, ibmappnNodePortDlcTracRemoteAddr DisplayString, ibmappnNodePortDlcTracMsgType INTEGER, ibmappnNodePortDlcTracCmdType INTEGER, ibmappnNodePortDlcTracUseWan INTEGER } ibmappnNodePortDlcTracPortName OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The Port name associated with this this trace table entry." ::= { ibmappnNodePortDlcTraceEntry 1 } ibmappnNodePortDlcTracIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This index value is updated every time a new trace entry is created which provides a means to retrieve only the updated entries and also provides a simple method of correlating the entries. The table will wrap when the table is full, which will result in previous entries being written over. The mangement station can over come this by retrieving the table using this index to McKenzie & Cheng [Page 18] RFC 1593 SNA APPN Node MIB March 1994 retrieve only the new table entries." ::= { ibmappnNodePortDlcTraceEntry 2 } ibmappnNodePortDlcTracDlcType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following sdlc(2), dls(3), socket(4), ethernet(5), tokenRing(6) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of DLC interface, distinguished according to the protocol immediately 'below' this layer." ::= { ibmappnNodePortDlcTraceEntry 3 } ibmappnNodePortDlcTracLocalAddr OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Local address in format described below: other = free form DisplayString ip = ld. ld. ld. ld / 2d tr = lx: lx: lx: lx: lx: lx . lx dlsw = lx: lx: lx: lx: lx: lx . lx ethernet = lx: lx: lx: lx: lx: lx . lx " ::= { ibmappnNodePortDlcTraceEntry 4 } ibmappnNodePortDlcTracRemoteAddr OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Remote Address in the format described below: other = free form DisplayString ip = ld. ld. ld. ld / 2d tr = lx: lx: lx: lx: lx: lx . lx dlsw = lx: lx: lx: lx: lx: lx . lx McKenzie & Cheng [Page 19] RFC 1593 SNA APPN Node MIB March 1994 ethernet = lx: lx: lx: lx: lx: lx . lx " ::= { ibmappnNodePortDlcTraceEntry 5 } ibmappnNodePortDlcTracMsgType OBJECT-TYPE SYNTAX INTEGER { -- enumeration values between 1 and 1999 are reserved -- for potential undefined message types. other(1), unknown(2), request(3), confirm(4), indication(5), response(6) -- enumeration values between 2000 and 3999 are reserved -- for IP socket traces, -- enumeration values between 4000 and 5999 are reserved -- for DLS traces, -- enumeration values between 6000 and 7999 are reserved -- for TR traces, } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the type of trace record entry" ::= { ibmappnNodePortDlcTraceEntry 6 } ibmappnNodePortDlcTracCmdType OBJECT-TYPE SYNTAX INTEGER { -- enumeration values between 1 and 1999 are reserved -- for potential undefined message types. testFrame(1), respFrame(2), curFrame(3), icrFrame(4), McKenzie & Cheng [Page 20] RFC 1593 SNA APPN Node MIB March 1994 respAck(5), dgrmFrame(6), xidFrame(7), contFrame(8), contedFrame(9), iFrame(10), enterBusy(12), exitBusy(13), haltFrame(14), lsHalted(15), restartLs(16), lsRestarted(17), netBioSnq(18), netBioSnr(19), gnetFrame(20), netdFrame(21), oobFrame(22), alterSap(23), testRsp(24), haltLsNow(25), testReq(26), -- enumeration values between 2000 and 3999 are reserved -- for IP socket traces. ipTestFrame(2001), ipRespFrame(2002), ipCurFrame(2003), ipIcrFrame(2004), ipRespAck(2005), ipDgrmFrame(2006), ipXidFrame(2007), ipContFrame(2008), ipContedFrame(2009), ipIFrame(2010), ipEnterBusy(2012), ipExitBusy(2013), ipHaltFrame(2014), ipLsHalted(2015), ipRestartLs(2016), ipLsRestarted(2017), ipNetBioSnq(2018), ipNetBioSnr(2019), ipGnetFrame(2020), ipNetdFrame(2021), ipOobFrame(2022), ipAlterSap(2023), ipTestRsp(2024), ipHaltLsNow(2025), McKenzie & Cheng [Page 21] RFC 1593 SNA APPN Node MIB March 1994 ipTestReq(2026), -- enumeration values between 4000 and 5999 are reserved -- for DLS traces. dlsIpm(4124), -- enumeration values between 6000 and 7999 are reserved for -- TR traces. trTestFrame(6001), trRespFrame(6002), trCurFrame(6003), trIcrFrame(6004), trRespAck(6005), trDgrmFrame(6006), trXidFrame(6007), trContFrame(6008), trContedFrame(6009), trIFrame(6010), trEnterBusy(6012), trExitBusy(6013), trHaltFrame(6014), trLsHalted(6015), trRestartLs(6016), trLsRestarted(6017), trNetBioSnq(6018), trNetBioSnr(6019), trGnetFrame(6020), trNetdFrame(6021), trOobFrame(6022), trAlterSap(6023), trTestRsp(6024), trHaltLsNow(6025), trTestReq(6026) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the command type of the trace entry." ::= { ibmappnNodePortDlcTraceEntry 7 } ibmappnNodePortDlcTracUseWan OBJECT-TYPE SYNTAX INTEGER { other(1), notApplicable(2), useUnknown(3), McKenzie & Cheng [Page 22] RFC 1593 SNA APPN Node MIB March 1994 useWan(4), useLan(5) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the type of connection of the trace entry. For example, token ring and ethernet ports will have useLan as connection. For the dls port, it could be either useWan if connection is across Wan via dls sessions, or useLan if connection is to a local attached LAN." ::= { ibmappnNodePortDlcTraceEntry 8 } -- ************************************************************** -- APPN Link Station Information -- ibmappnNodeLsTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodeLsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains detail information about the link station configuration and current status." ::= { ibmappnLinkStationInformation 1 } ibmappnNodeLsEntry OBJECT-TYPE SYNTAX IbmappnNodeLsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by the link station name." INDEX { ibmappnNodeLsName } ::= { ibmappnNodeLsTable 1 } IbmappnNodeLsEntry ::= SEQUENCE { ibmappnNodeLsName DisplayString, ibmappnNodeLsPortName DisplayString, ibmappnNodeLsDlcType INTEGER, McKenzie & Cheng [Page 23] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNodeLsDynamic INTEGER, ibmappnNodeLsState INTEGER, -- ls defined data / xid info ibmappnNodeLsCpName DisplayString, ibmappnNodeLsTgNum INTEGER, ibmappnNodeLsLimResource INTEGER, ibmappnNodeLsMigration INTEGER, ibmappnNodeLsBlockNum DisplayString, ibmappnNodeLsIdNum DisplayString, ibmappnNodeLsCpCpSession INTEGER, -- ls parms (common) / xid info ibmappnNodeLsTargetPacingCount INTEGER, ibmappnNodeLsMaxSendBtuSize INTEGER, -- tg characteristics ibmappnNodeLsEffCap INTEGER, ibmappnNodeLsConnCost INTEGER, ibmappnNodeLsByteCost INTEGER, ibmappnNodeLsSecurity INTEGER, ibmappnNodeLsDelay INTEGER, ibmappnNodeLsUsr1 INTEGER, ibmappnNodeLsUsr2 INTEGER, ibmappnNodeLsUsr3 INTEGER, -- ls (performance data) ibmappnNodeLsInXidBytes Counter, ibmappnNodeLsInMsgBytes Counter, ibmappnNodeLsInXidFrames Counter, ibmappnNodeLsInMsgFrames Counter, ibmappnNodeLsOutXidBytes Counter, ibmappnNodeLsOutMsgBytes Counter, ibmappnNodeLsOutXidFrames Counter, ibmappnNodeLsOutMsgFrames Counter, -- ls (propgation delay) ibmappnNodeLsEchoRsps Counter, ibmappnNodeLsCurrentDelay INTEGER, ibmappnNodeLsMaxDelay INTEGER, ibmappnNodeLsMinDelay INTEGER, ibmappnNodeLsMaxDelayTime TimeTicks, -- ls (Xid Statistics) ibmappnNodeLsGoodXids Counter, ibmappnNodeLsBadXids Counter, -- Dlc specific ibmappnNodeLsSpecific OBJECT IDENTIFIER, ibmappnNodeLsSubState INTEGER, ibmappnNodeLsStartTime TimeTicks, ibmappnNodeLsActiveTime TimeTicks, ibmappnNodeLsCurrentStateTime TimeTicks } McKenzie & Cheng [Page 24] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNodeLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for the link station. The name can be from one to eight characters." ::= { ibmappnNodeLsEntry 1 } ibmappnNodeLsPortName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for the port. The name can be from one to eight characters." ::= { ibmappnNodeLsEntry 2 } ibmappnNodeLsDlcType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following sdlc(2), dls(3), socket(4), ethernet(5), tokenRing(6) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of DLC interface, distinguished according to the protocol immediately 'below' this layer." ::= { ibmappnNodeLsEntry 3 } ibmappnNodeLsDynamic OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Identifies whether this resource is a dynamic link station. Dynamic link stations are created when adjacent nodes that have not been locally defined establish a connection with this node." McKenzie & Cheng [Page 25] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNodeLsEntry 4 } ibmappnNodeLsState OBJECT-TYPE SYNTAX INTEGER { inactive(1), pendactive(2), active(3), pendinact(4) } ACCESS read-write STATUS mandatory DESCRIPTION "State of this link station." ::= { ibmappnNodeLsEntry 5 } ibmappnNodeLsCpName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Fully-qualified name of the adjacent node for this link station. The name can be from three to seventeen characters. Format is netid.cpname." ::= { ibmappnNodeLsEntry 6 } ibmappnNodeLsTgNum OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number associated with the TG to this link station." ::= { ibmappnNodeLsEntry 7 } ibmappnNodeLsLimResource OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the link station is a limited resource. If it is, the TG is deactivated when there are no sessions." ::= { ibmappnNodeLsEntry 8 } McKenzie & Cheng [Page 26] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNodeLsMigration OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this link station will be used for connections to down-level or migration partners." ::= { ibmappnNodeLsEntry 9 } ibmappnNodeLsBlockNum OBJECT-TYPE SYNTAX DisplayString (SIZE (3)) ACCESS read-only STATUS mandatory DESCRIPTION "The block number is the first three digits of the node_id. These 3 hexideimal digits identify the product and are not configurable." ::= { ibmappnNodeLsEntry 10 } ibmappnNodeLsIdNum OBJECT-TYPE SYNTAX DisplayString (SIZE (5)) ACCESS read-only STATUS mandatory DESCRIPTION "The ID number is the last 5 digits of the node_id. These 5 hexadecimal digits are administratively defined and combined with the 3 digit block number form the node_id. This node_id is used to identify the local node and is include in APPN alerts as well as being included in XIDs. A unique value is required for connections to SNA sub-area." ::= { ibmappnNodeLsEntry 11 } ibmappnNodeLsCpCpSession OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether CP-CP sessions are supported by this link station." ::= { ibmappnNodeLsEntry 12 } ibmappnNodeLsTargetPacingCount OBJECT-TYPE SYNTAX INTEGER McKenzie & Cheng [Page 27] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "Numeric value between 0 and 32767 inclusive indicating the desired pacing window size for BINDs on this TG. The number is significant only when fixed bind pacing is being performed." ::= { ibmappnNodeLsEntry 13 } ibmappnNodeLsMaxSendBtuSize OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Numeric value between 0 and 32767 inclusive indicating the desired number of bytes in a Basic Transmission Unit (BTU) that can be sent on this TG. This is an administratively assigned value." ::= { ibmappnNodeLsEntry 14 } ibmappnNodeLsEffCap OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The effective capacity is an integer value that indicates the kilo bits per second. It is derived from the link bandwidth and maximum load factor with the range of 0 thru 603,979,776. This is an administratively assigned value associated with the TG using this link station." ::= { ibmappnNodeLsEntry 15 } ibmappnNodeLsConnCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255, which indicates maximum cost. This is an administratively assigned value associated with the TG using this link station." McKenzie & Cheng [Page 28] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNodeLsEntry 16 } ibmappnNodeLsByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Relative cost of transmitting a byte over this link. Range is from 0 (lowest cost) to 255. This is an administratively assigned value associated with the TG using this link station." ::= { ibmappnNodeLsEntry 17 } ibmappnNodeLsSecurity OBJECT-TYPE SYNTAX INTEGER { nonsecure(1), --X'01' publicSwitchedNetwork(32), --X'20' undergroundCable(64), --X'40' secureConduit(96), --X'60' guardedConduit(128), --X'80' encrypted(160), --X'A0' guardedRadiation(192) --X'C0' } ACCESS read-only STATUS mandatory DESCRIPTION "The security is represented as an integer with a range of 1 thru 255 with the most common values enumerated as defined above. This is an administratively assigned value associated with the TG using this link station." ::= { ibmappnNodeLsEntry 18 } ibmappnNodeLsDelay OBJECT-TYPE SYNTAX INTEGER { minimum(0), --X'00' negligible(384), --X'4C' terrestrial(9216), --X'71' packet(147456), --X'91' long(294912), --X'99' maximum(2013265920) --X'FF' } ACCESS read-only STATUS mandatory DESCRIPTION "Relative amount of time that it takes for a signal to McKenzie & Cheng [Page 29] RFC 1593 SNA APPN Node MIB March 1994 travel the length of the logical link. This time is represented in micro seconds, with some of the more common values enumerated. This is an administratively assigned value associated with the TG using this link station." ::= { ibmappnNodeLsEntry 19 } ibmappnNodeLsUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "First user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with the TG using this link station." ::= { ibmappnNodeLsEntry 20 } ibmappnNodeLsUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Second user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with the TG using this link station." ::= { ibmappnNodeLsEntry 21 } ibmappnNodeLsUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Third user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with the TG using this link station." ::= { ibmappnNodeLsEntry 22 } ibmappnNodeLsInXidBytes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory McKenzie & Cheng [Page 30] RFC 1593 SNA APPN Node MIB March 1994 DESCRIPTION "Number of XID bytes received." ::= { ibmappnNodeLsEntry 23 } ibmappnNodeLsInMsgBytes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of message (I-frame) bytes received." ::= { ibmappnNodeLsEntry 24 } ibmappnNodeLsInXidFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of XID frames received." ::= { ibmappnNodeLsEntry 25 } ibmappnNodeLsInMsgFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of message (I-frame) frames received." ::= { ibmappnNodeLsEntry 26 } ibmappnNodeLsOutXidBytes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of XID bytes sent." ::= { ibmappnNodeLsEntry 27 } ibmappnNodeLsOutMsgBytes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of message (I-frame) bytes sent." McKenzie & Cheng [Page 31] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNodeLsEntry 28 } ibmappnNodeLsOutXidFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of XID frames sent." ::= { ibmappnNodeLsEntry 29 } ibmappnNodeLsOutMsgFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of message (I-frame) frames sent." ::= { ibmappnNodeLsEntry 30 } ibmappnNodeLsEchoRsps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of responses returned from adjacent link station. A response should be returned for each test frame sent by this node. Test frames are sent to adjacent nodes periodically to verify connectivity and to measure that actual round trip time, that is the time the test frame is sent until the response is received." ::= { ibmappnNodeLsEntry 31 } ibmappnNodeLsCurrentDelay OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The time that it took for the last test signal to be sent and returned from this link station to the adjacent links station. This time is represented in milliseconds." ::= { ibmappnNodeLsEntry 32 } ibmappnNodeLsMaxDelay OBJECT-TYPE McKenzie & Cheng [Page 32] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The longest time it took for a test signal to be sent and returned from this link station to the adjacent links station. This time is represented in milliseconds ." ::= { ibmappnNodeLsEntry 33 } ibmappnNodeLsMinDelay OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The shortest time it took for a test signal to be sent and returned from this link station to the adjacent links station. This time is represented in milliseconds." ::= { ibmappnNodeLsEntry 34 } ibmappnNodeLsMaxDelayTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (since system up in hundredth of seconds) when the longest delay occurred. This time can be used to identify when this high water mark occurred in relation to the last initialization of the APPN node." ::= { ibmappnNodeLsEntry 35 } ibmappnNodeLsGoodXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of successful XIDs that have occurred on this link station since the time it was started." ::= { ibmappnNodeLsEntry 36 } ibmappnNodeLsBadXids OBJECT-TYPE SYNTAX Counter McKenzie & Cheng [Page 33] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "The total number of unsuccessful XIDs that have occurred on this link station since the time it was started." ::= { ibmappnNodeLsEntry 37 } ibmappnNodeLsSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "Identifies the DLC specific OBJECT IDENTIFIER that can provide additional information." ::= { ibmappnNodeLsEntry 38 } ibmappnNodeLsSubState OBJECT-TYPE SYNTAX INTEGER { inactive(1), sentReqOpnstn(2), pendXidExch(3), sentActAs(4), sentSetMode(5), active(6), sentDeactAsOrd(7), sentDiscOrd(8), sentDestroyTg(9), sentCreateTg(10), sentConnReq(11), pendRcvConnInd(12), pendSendConnRsp(13), sentConnRsp(14), pendDeact(15) } ACCESS read-only STATUS mandatory DESCRIPTION "State of this link station." ::= { ibmappnNodeLsEntry 39 } ibmappnNodeLsStartTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION McKenzie & Cheng [Page 34] RFC 1593 SNA APPN Node MIB March 1994 "The time (in hundredth of seconds) this link station has been active the last time since the time APPN was initialized." ::= { ibmappnNodeLsEntry 40 } ibmappnNodeLsActiveTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredth of seconds) this link station has been in the active state. A zero value indicates the link station has never been active." ::= { ibmappnNodeLsEntry 41 } ibmappnNodeLsCurrentStateTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredth of seconds) the link station is in the current state." ::= { ibmappnNodeLsEntry 42 } -- ************************************************************** -- Link station table (TCP/IP specific) -- ibmappnNodeLsIpTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodeLsIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Link station table (TCP/IP specific)." ::= { ibmappnLinkStationInformation 2 } ibmappnNodeLsIpEntry OBJECT-TYPE SYNTAX IbmappnNodeLsIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The IP Name is used as the index to this table." McKenzie & Cheng [Page 35] RFC 1593 SNA APPN Node MIB March 1994 INDEX {ibmappnNodeLsIpName } ::= { ibmappnNodeLsIpTable 1 } IbmappnNodeLsIpEntry ::= SEQUENCE { ibmappnNodeLsIpName DisplayString, ibmappnNodeLsIpState INTEGER, ibmappnNodeLsLocalIpAddr IpAddress, ibmappnNodeLsLocalIpPortNum INTEGER, ibmappnNodeLsRemoteIpAddr IpAddress, ibmappnNodeLsRemoteIpPortNum INTEGER } ibmappnNodeLsIpName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this link station. The name can be from one to eight characters." ::= { ibmappnNodeLsIpEntry 1 } ibmappnNodeLsIpState OBJECT-TYPE SYNTAX INTEGER { inactive(1), pendactive(2), active(3), pendinact(4) } ACCESS read-only STATUS mandatory DESCRIPTION "State of this link station." ::= { ibmappnNodeLsIpEntry 2 } ibmappnNodeLsLocalIpAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "Local IP address." ::= { ibmappnNodeLsIpEntry 3 } ibmappnNodeLsLocalIpPortNum OBJECT-TYPE McKenzie & Cheng [Page 36] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Local TCP/IP port number. The default listening port will be administratively assigned and will dynamically change if this node initiates a session with adjacent node." ::= { ibmappnNodeLsIpEntry 4 } ibmappnNodeLsRemoteIpAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "Remote IP address." ::= { ibmappnNodeLsIpEntry 5 } ibmappnNodeLsRemoteIpPortNum OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Remote TCP/IP port number." ::= { ibmappnNodeLsIpEntry 6 } -- ************************************************************** -- Ls Table (DLS specific) -- ibmappnNodeLsDlsTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodeLsDlsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Ls Table (DLS specific)." ::= { ibmappnLinkStationInformation 3 } ibmappnNodeLsDlsEntry OBJECT-TYPE SYNTAX IbmappnNodeLsDlsEntry McKenzie & Cheng [Page 37] RFC 1593 SNA APPN Node MIB March 1994 ACCESS not-accessible STATUS mandatory DESCRIPTION "The DLS Name is used as the index to this table." INDEX {ibmappnNodeLsDlsName } ::= { ibmappnNodeLsDlsTable 1 } IbmappnNodeLsDlsEntry ::= SEQUENCE { ibmappnNodeLsDlsName DisplayString, ibmappnNodeLsDlsState INTEGER, ibmappnNodeLsLocalDlsMac OCTET STRING, ibmappnNodeLsLocalDlsSap OCTET STRING, ibmappnNodeLsRemoteDlsMac OCTET STRING, ibmappnNodeLsRemoteDlsSap OCTET STRING } ibmappnNodeLsDlsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this link station. The name can be from one to eight characters." ::= { ibmappnNodeLsDlsEntry 1 } ibmappnNodeLsDlsState OBJECT-TYPE SYNTAX INTEGER { inactive(1), pendactive(2), active(3), pendinact(4) } ACCESS read-only STATUS mandatory DESCRIPTION "State of this link station." ::= { ibmappnNodeLsDlsEntry 2 } ibmappnNodeLsLocalDlsMac OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION McKenzie & Cheng [Page 38] RFC 1593 SNA APPN Node MIB March 1994 "Local MAC address." ::= { ibmappnNodeLsDlsEntry 3 } ibmappnNodeLsLocalDlsSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) ACCESS read-only STATUS mandatory DESCRIPTION "Local SAP address." ::= { ibmappnNodeLsDlsEntry 4 } ibmappnNodeLsRemoteDlsMac OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "Remote MAC address." ::= { ibmappnNodeLsDlsEntry 5 } ibmappnNodeLsRemoteDlsSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) ACCESS read-only STATUS mandatory DESCRIPTION "Remote SAP address." ::= { ibmappnNodeLsDlsEntry 6 } -- ************************************************************** -- Ls Table (Token Ring specific) -- ibmappnNodeLsTrTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodeLsTrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Ls Table (Token Ring specific)." ::= { ibmappnLinkStationInformation 4 } ibmappnNodeLsTrEntry OBJECT-TYPE SYNTAX IbmappnNodeLsTrEntry McKenzie & Cheng [Page 39] RFC 1593 SNA APPN Node MIB March 1994 ACCESS not-accessible STATUS mandatory DESCRIPTION "The TR Name is used as the index to this table." INDEX {ibmappnNodeLsTrName } ::= { ibmappnNodeLsTrTable 1 } IbmappnNodeLsTrEntry ::= SEQUENCE { ibmappnNodeLsTrName DisplayString, ibmappnNodeLsTrState INTEGER, ibmappnNodeLsLocalTrMac OCTET STRING, ibmappnNodeLsLocalTrSap OCTET STRING, ibmappnNodeLsRemoteTrMac OCTET STRING, ibmappnNodeLsRemoteTrSap OCTET STRING } ibmappnNodeLsTrName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this link station. The name can be from one to eight characters." ::= { ibmappnNodeLsTrEntry 1 } ibmappnNodeLsTrState OBJECT-TYPE SYNTAX INTEGER { inactive(1), pendactive(2), active(3), pendinact(4) } ACCESS read-only STATUS mandatory DESCRIPTION "State of this link station." ::= { ibmappnNodeLsTrEntry 2 } ibmappnNodeLsLocalTrMac OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "Local MAC address." McKenzie & Cheng [Page 40] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNodeLsTrEntry 3 } ibmappnNodeLsLocalTrSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) ACCESS read-only STATUS mandatory DESCRIPTION "Local SAP address." ::= { ibmappnNodeLsTrEntry 4 } ibmappnNodeLsRemoteTrMac OBJECT-TYPE SYNTAX OCTET STRING (SIZE (6)) ACCESS read-only STATUS mandatory DESCRIPTION "Remote MAC address." ::= { ibmappnNodeLsTrEntry 5 } ibmappnNodeLsRemoteTrSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) ACCESS read-only STATUS mandatory DESCRIPTION "Remote SAP address." ::= { ibmappnNodeLsTrEntry 6 } -- ************************************************************** -- This table provides information about errors this node encountered -- with connections to adjacent nodes. This includes all exceptional -- conditions encountered establishing connections and all exceptional -- conditions that result in terminating the connection. -- ************************************************************** ibmappnNodeLsStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNodeLsStatusEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains information related to exceptional and potential exceptional conditions that occur during the activation, XID exchange, and termination of the connection." ::= { ibmappnLinkStationInformation 5 } McKenzie & Cheng [Page 41] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNodeLsStatusEntry OBJECT-TYPE SYNTAX IbmappnNodeLsStatusEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by the LsStatusIndex, which is an integer that is continuously updated until it eventually wraps. This provides the management station the ability to retrieve only the updates to the table by using the standard GET NEXT." INDEX { ibmappnNodeLsStatusIndex } ::= { ibmappnNodeLsStatusTable 1 } IbmappnNodeLsStatusEntry ::= SEQUENCE { ibmappnNodeLsStatusIndex INTEGER, ibmappnNodeLsStatusTime TimeTicks, ibmappnNodeLsStatusLsName DisplayString, ibmappnNodeLsStatusCpName DisplayString, ibmappnNodeLsStatusNodeId OCTET STRING, ibmappnNodeLsStatusTgNum INTEGER, ibmappnNodeLsStatusGeneralSense OCTET STRING, ibmappnNodeLsStatusNofRetry INTEGER, ibmappnNodeLsStatusEndSense OCTET STRING, ibmappnNodeLsStatusXidLocalSense OCTET STRING, ibmappnNodeLsStatusXidRemoteSense OCTET STRING, ibmappnNodeLsStatusXidByteInError INTEGER, ibmappnNodeLsStatusXidBitInError INTEGER, ibmappnNodeLsStatusDlcType INTEGER, ibmappnNodeLsStatusLocalAddr DisplayString, ibmappnNodeLsStatusRemoteAddr DisplayString } ibmappnNodeLsStatusIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This index is continuous index this table." ::= { ibmappnNodeLsStatusEntry 1 } ibmappnNodeLsStatusTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only McKenzie & Cheng [Page 42] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Time (in hundreds of a second) since this node was last initialized." ::= { ibmappnNodeLsStatusEntry 2 } ibmappnNodeLsStatusLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this link station." ::= { ibmappnNodeLsStatusEntry 3 } ibmappnNodeLsStatusCpName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned fully-qualified name of the adjacent node partner. This will be provided when the adjacent node has been defined at this node or when the XID sequence has proceeded far enough to to identify the adjacent node. A blank CP name will indicate the name is unknown." ::= { ibmappnNodeLsStatusEntry 4 } ibmappnNodeLsStatusNodeId OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "Adjacent Node id" ::= { ibmappnNodeLsStatusEntry 5 } ibmappnNodeLsStatusTgNum OBJECT-TYPE SYNTAX INTEGER (0..256) ACCESS read-only STATUS mandatory DESCRIPTION "Number associated with the TG to this link station with a range from 0 to 256. A value of 256 indicates McKenzie & Cheng [Page 43] RFC 1593 SNA APPN Node MIB March 1994 the tg number has not been negotiated and is unknown at this time." ::= { ibmappnNodeLsStatusEntry 6 } ibmappnNodeLsStatusGeneralSense OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The error sense code associated with the start sequence of activation of a link up to the beginning of the XID sequence." ::= { ibmappnNodeLsStatusEntry 7 } ibmappnNodeLsStatusNofRetry OBJECT-TYPE SYNTAX INTEGER { retry(1), noretry(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether Node Operator Facility will retry the start request to activate the link." ::= { ibmappnNodeLsStatusEntry 8 } ibmappnNodeLsStatusEndSense OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The sense code associated with the termination of the link connection to adjacent node. This includes all sense information included in the disconnect recieved from the lower layer DLCs and also sense information indicating the link termination originated by upper layer APPN components." ::= { ibmappnNodeLsStatusEntry 9 } ibmappnNodeLsStatusXidLocalSense OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The error sense code associated with the rejection of the McKenzie & Cheng [Page 44] RFC 1593 SNA APPN Node MIB March 1994 XID." ::= { ibmappnNodeLsStatusEntry 10 } ibmappnNodeLsStatusXidRemoteSense OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The error sense code adjacent node returned to this node indicating the reason the XID was rejected." ::= { ibmappnNodeLsStatusEntry 11 } ibmappnNodeLsStatusXidByteInError OBJECT-TYPE SYNTAX INTEGER { na(1000) } ACCESS read-only STATUS mandatory DESCRIPTION "This identifies the actual byte in the XID that caused the error. The value of zero (0) indicates that the variable has no meaning." ::= { ibmappnNodeLsStatusEntry 12 } ibmappnNodeLsStatusXidBitInError OBJECT-TYPE SYNTAX INTEGER { na(8) -- not applicable } ACCESS read-only STATUS mandatory DESCRIPTION "This identifies the actual bit within the error byte of the XID. This only has meaning when the byte in error is greater than zero." ::= { ibmappnNodeLsStatusEntry 13 } ibmappnNodeLsStatusDlcType OBJECT-TYPE SYNTAX INTEGER { other(1), sdlc(2), dls(3), socket(4), ethernet(5), tr(6) McKenzie & Cheng [Page 45] RFC 1593 SNA APPN Node MIB March 1994 } ACCESS read-only STATUS mandatory DESCRIPTION "This identifies DLC type that was being used when error occurred. This also is used to the format of the local and remote address provided. other = free form DisplayString ip = ld. ld. ld. ld / 2d tr = lx: lx: lx: lx: lx: lx . lx dlsw = lx: lx: lx: lx: lx: lx . lx ethernet = lx: lx: lx: lx: lx: lx . lx " ::= { ibmappnNodeLsStatusEntry 14 } ibmappnNodeLsStatusLocalAddr OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "This contains a displayable string that identifies the DLC type and appropriate address. See DlcType above for details of the format." ::= { ibmappnNodeLsStatusEntry 15 } ibmappnNodeLsStatusRemoteAddr OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "This contains a displayable string that identifies the DLC type and appropriate address. See DlcType above for details of the format." ::= { ibmappnNodeLsStatusEntry 16 } -- ************************************************************** -- APPN SNMP Performance Information McKenzie & Cheng [Page 46] RFC 1593 SNA APPN Node MIB March 1994 -- ibmappnSnmpInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of messages delivered to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 1 } ibmappnSnmpInGetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of GET requests delivered to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 2 } ibmappnSnmpInGetNexts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of GETNEXT requests delivered to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 3 } ibmappnSnmpInSetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of SET requests delivered to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 4 } ibmappnSnmpInTotalVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of VARIABLES included in both GET and GETNEXT requests to the APPN SNMP sub-agent." McKenzie & Cheng [Page 47] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnSnmpInformation 5 } ibmappnSnmpInGetVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of VARIBLES included in all GET requests to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 6 } ibmappnSnmpInGetNextVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of VARIABLES included in all GETNEXT requests to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 7 } ibmappnSnmpInSetVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of VARIBLES included in all SET requests to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 8 } ibmappnSnmpOutNoSuchNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of VARIABLES that could not be found by the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 9 } ibmappnSnmpOutGenErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of undefined errors that McKenzie & Cheng [Page 48] RFC 1593 SNA APPN Node MIB March 1994 occurred processing SNMP request to the APPN SNMP sub-agent." ::= { ibmappnSnmpInformation 10 } -- ************************************************************** -- This group provides global information about the -- APPN node performance. -- The first section applies to the APPN control point -- storage utilization. ibmappnMemorySize OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Size of the shared storage segment, as obtained by storage management from the underlying operating system." ::= { ibmappnMemoryUse 1 } ibmappnMemoryUsed OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of bytes in the segment that are currently allocated to process." ::= { ibmappnMemoryUse 2 } ibmappnMemoryWarnThresh OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Allocation threshold beyond which storage management considers the storage resources to be constrained." ::= { ibmappnMemoryUse 3 } ibmappnMemoryCritThresh OBJECT-TYPE McKenzie & Cheng [Page 49] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Allocation threshold beyond which storage management considers the storage resources to be critically constrained." ::= { ibmappnMemoryUse 4 } -- ************************************************************** -- The following are Counters maintained by the APPN CS component that -- relate to total overall XID activity. ------------------------------------------------------------------------ ibmappnNodeDefLsGoodXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The current number of successfull XIDs that have occurred on all defined link stations since the last time this node was initialized." ::= { ibmappnXidInformation 1 } ibmappnNodeDefLsBadXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The current number of unsuccessfull XIDs that have occurred on all defined link stations since the last time this node was initialized." ::= { ibmappnXidInformation 2 } ibmappnNodeDynLsGoodXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The current number of successfull XIDs that have occurred on all dynamic link stations since the last time this node was initialized." ::= { ibmappnXidInformation 3 } McKenzie & Cheng [Page 50] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNodeDynLsBadXids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The current number of unsuccessfull XIDs that have occurred on all dynamic link stations since the last time this node was initialized." ::= { ibmappnXidInformation 4 } -- ************** The APPN Topology Group *********************** ibmappnNn OBJECT IDENTIFIER ::= { ibmappn 2 } ibmappnNnTopo OBJECT IDENTIFIER ::= { ibmappnNn 1 } ibmappnNnTopology OBJECT IDENTIFIER ::= { ibmappnNn 3 } -- This group will be used to represent the entire APPN network -- topology, including Network nodes, virtual nodes and -- all TGs associated with these nodes. -- -- Network nodes -- The APPN topology database consists of information about every -- APPN network node. This information is learned over time -- as each network node exchanges topology information with -- each of its adjacent network nodes. The database consists -- of information about each node and all of the transmissions -- groups used by each node. -- Virtual nodes -- Information about virtual nodes (connection networks) is treated -- the same as information about network node -- and is replicated at each network node. -- The node name is the only meaningful information. The other -- node objects use default values. Each node that has defined -- a TG with this virtual node as the destination also defines a -- TG on this virtual node. There is a TG record for each node -- that uses this virtual node. -- -- -- The APPN node table represents the APPN topology -- database with the APPN CP fully-qualified name -- being used as the index to this table. -- This entire table could be retrieved using the GET NEXT command, McKenzie & Cheng [Page 51] RFC 1593 SNA APPN Node MIB March 1994 -- however, due to the dynamics of APPN, nodes could come and -- go and status could change as the table is being -- retrieved. Although in most cases the data retrieved will be valid, -- missing and invalid status could cause problems for -- a management application that was graphically displaying -- this data. -- This potential problem can be eliminated by -- retrieving the FRSN before and after completion -- of retrieval of the APPN topology table. -- If the FRSN has changed, then repeat the -- retrieval of the entire topology table -- until the FRSN remains unchanged. -- Object 'appnNnFrsn' represents the last -- change or update to this node's topology -- database. -- -- -- The format of the actual database is as follows: -- -- Node table (entry for each node in network) -- TG table (entry for each TG owned by node) -- -- Due to SNMP ASN.1 limitations, we cannot represent -- the TG table within the node table. We define -- separate tables for nodes and TGs, adding the node -- name to each TG entry to provide a means of -- correlating each TG with its originating node. ibmappnNnTopoMaxNodes OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum number of nodes allowed in the APPN topology database. This administratively assigned value must be equal to or greater than the maximum total number of end nodes and network nodes. If the number of nodes exceeds this value, APPN will issue an Alert and the node can no longer participate as a network node." ::= { ibmappnNnTopo 1 } ibmappnNnTopoCurNumNodes OBJECT-TYPE SYNTAX Gauge ACCESS read-only McKenzie & Cheng [Page 52] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Current number of nodes in this node's topology database. If this value exceeds the maximum number of nodes allowed (NnTopoMaxNodes), APPN alert CPDB002 is issued." ::= { ibmappnNnTopo 2 } ibmappnNnTopoInTdus OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of TDUs received from all adjacent NN since last initialization." ::= { ibmappnNnTopo 3 } ibmappnNnTopoOutTdus OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of TDUs built by this node to be sent to all adjacent NN since last initialization." ::= { ibmappnNnTopo 4 } ibmappnNnTopoNodeLowRsns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology node updates received by this node with a RSN less than the current RSN. Both even and odd RSN are included in this count. These TDUs are not errors, but result when TDUs are broadcast to all adjacent network nodes. No update to this node's topology database occurs, but this node will send a TDU with it's higher RSN to the adjacent node that sent this low RSN." ::= { ibmappnNnTopo 5 } ibmappnNnTopoNodeEqualRsns OBJECT-TYPE SYNTAX Counter ACCESS read-only McKenzie & Cheng [Page 53] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Total number of topology node updates received by this node with a RSN equal to the current RSN. Both even and odd RSN are included in this count. These TDUs are not errors, but result when TDUs are broadcast to all adjacent network nodes. No update to this node's topology database occurs." ::= { ibmappnNnTopo 6 } ibmappnNnTopoNodeGoodHighRsns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology node updates received by this node with a RSN greater than the current RSN. This results in updating this nodes topology and broadcasting a TDU to all adjacent network nodes. It is not required to send a TDU to the sender of this update because that node already has the update." ::= { ibmappnNnTopo 7 } ibmappnNnTopoNodeBadHighRsns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology node updates received by this node with an odd RSN greater than the current RSN. These updates represent a topology inconsistency detected by one of the APPN network nodes. This results in updating this nodes topology and broadcasting a TDU to all adjacent network nodes." ::= { ibmappnNnTopo 8 } ibmappnNnTopoNodeStateUpdates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology Node records built as a result McKenzie & Cheng [Page 54] RFC 1593 SNA APPN Node MIB March 1994 of internally detected node state changes that affect APPN topology and routing. Updates are sent via TDUs to all adjacent network nodes." ::= { ibmappnNnTopo 9 } ibmappnNnTopoNodeErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology node records inconsistencies detected by this node. This occurs when this node attempts to update its topology database and detects a data inconsistency. This node will create a TDU with the current RSN incremented to the next odd number and broadcast it to all adjacent NNs." ::= { ibmappnNnTopo 10 } ibmappnNnTopoNodeTimerUpdates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology node records built for this node's resource due to timer updates. Updates are sent via TDUs to all adjacent network nodes. These updates insure other network nodes do not delete this node's resources from their topology database." ::= { ibmappnNnTopo 11 } ibmappnNnTopoNodePurges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology node records purged from this node's topology database. This occurs when a node has not been updated in a specified amount of time. The owning node is responsible for broadcasting updates for its resource that it wants kept in the network topology." ::= { ibmappnNnTopo 12 } ibmappnNnTopoTgLowRsns OBJECT-TYPE McKenzie & Cheng [Page 55] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG updates received by this node with a RSN less than the current RSN. Both even and odd RSN are included in this count. These TDUs are not errors, but result when TDUs are broadcast to all adjacent network nodes. No update to this node's topology database occurs, but this node will send a TDU with it's higher RSN to the sender of the low RSN." ::= { ibmappnNnTopo 13 } ibmappnNnTopoTgEqualRsns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG updates received by this node with a RSN equal to the current RSN. Both even and odd RSN are included in this count. These TDUs are not errors, but result when TDUs are broadcast to all adjacent network nodes. No update to this node's topology database occurs." ::= { ibmappnNnTopo 14 } ibmappnNnTopoTgGoodHighRsns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG updates received by this node with a RSN greater than the current RSN. This results in updating this nodes topology and broadcasting the update to all adjacent network nodes." ::= { ibmappnNnTopo 15 } ibmappnNnTopoTgBadHighRsns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG updates received by this McKenzie & Cheng [Page 56] RFC 1593 SNA APPN Node MIB March 1994 node with an odd RSN greater than the current RSN. These updates represent a topology inconsistency detected by one of the APPN network nodes. This results in updating this nodes topology and broadcasting a TDU to all adjacent network nodes." ::= { ibmappnNnTopo 16 } ibmappnNnTopoTgStateUpdates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG records built as a result of internally detected node state changes that affect APPN topology and routing. Updates are sent via TDUs to all adjacent network nodes." ::= { ibmappnNnTopo 17 } ibmappnNnTopoTgErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG records inconsistencies detected by this node. This occurs when this node attempts to update its topology database and detects a data inconsistency. This node will create a TDU with the current RSN incremented to the next odd number and broadcast it to all adjacent NNs." ::= { ibmappnNnTopo 18 } ibmappnNnTopoTgTimerUpdates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG records built for this node's resource due to timer updates. Updates are sent via TDUs to all adjacent network nodes. These updates insure other network nodes do not delete this node's resources from their topology database." ::= { ibmappnNnTopo 19 } McKenzie & Cheng [Page 57] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnTopoTgPurges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of topology TG records purged from this node's topology database. This occurs when a TG has not been updated in a specified amount of time. The owning node is responsible for broadcasting updates for its resource that it wants to keep in the network topology." ::= { ibmappnNnTopo 20 } ibmappnNnTopoTotalRouteCalcs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of routes calculated for all class of services since the last initialization." ::= { ibmappnNnTopo 21 } ibmappnNnTopoTotalRouteRejs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of route requests for all class of services that could not be calculated since last initialization." ::= { ibmappnNnTopo 22 } ibmappnNnTopoRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNnTopoRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing an entry for every Class of Service that it has calculated a route for." ::= { ibmappnNnTopo 23 } ibmappnNnTopoRouteEntry OBJECT-TYPE McKenzie & Cheng [Page 58] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX IbmappnNnTopoRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Class of Service name is the index for this table." INDEX {ibmappnNnTopoRouteCos} ::= { ibmappnNnTopoRouteTable 1 } IbmappnNnTopoRouteEntry ::= SEQUENCE { ibmappnNnTopoRouteCos DisplayString, ibmappnNnTopoRouteTrees Counter, ibmappnNnTopoRouteCalcs Counter, ibmappnNnTopoRouteRejs Counter } ibmappnNnTopoRouteCos OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The Class of Service for the route." ::= { ibmappnNnTopoRouteEntry 1 } ibmappnNnTopoRouteTrees OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of routes tree caches built for this Class of Service since the last initialization." ::= { ibmappnNnTopoRouteEntry 2 } ibmappnNnTopoRouteCalcs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of routes calculated since last initialization." ::= { ibmappnNnTopoRouteEntry 3 } McKenzie & Cheng [Page 59] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnTopoRouteRejs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of route requests that could not be calculated since last initialization." ::= { ibmappnNnTopoRouteEntry 4 } --Adjacent node table -- Node name (only applies to adjacent nodes) -- Number of out of sequence TDUs -- Status of CP-CP sessions (ConWinner/ConLoser) -- Last FRSN sent -- Last FRSN received ibmappnNnAdjNodeTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNnAdjNodeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing an entry for every node. The information kept in this table is the last FRSN sent and received, the status of the CP-CP sessions, and a gauge that indicates the number of outstanding TDUs." ::= { ibmappnNn 2 } ibmappnNnAdjNodeEntry OBJECT-TYPE SYNTAX IbmappnNnAdjNodeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The adjacent node name is the index for this table." INDEX {ibmappnNnAdjNodeAdjName} ::= { ibmappnNnAdjNodeTable 1 } IbmappnNnAdjNodeEntry ::= SEQUENCE { ibmappnNnAdjNodeAdjName DisplayString, ibmappnNnAdjNodeCpCpSessStatus INTEGER, ibmappnNnAdjNodeOutOfSeqTdus Gauge, McKenzie & Cheng [Page 60] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnAdjNodeLastFrsnSent INTEGER, ibmappnNnAdjNodeLastFrsnRcvd INTEGER } ibmappnNnAdjNodeAdjName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "An administratively-assigned fully-qualified name of this node's adjacent network node." ::= { ibmappnNnAdjNodeEntry 1 } ibmappnNnAdjNodeCpCpSessStatus OBJECT-TYPE SYNTAX INTEGER { active(1), conLoserActive(2), conWinnerActive(3), inactive(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the state of CP-CP sessions between this node and adjacent network and end nodes. Incative indicates no CP-CP sessions exists between this node and the adjacent node. Active indicates CP-CP sessons are active using both the ConWinner and ConLoser sessions. The session initiated by this node is refered to as the ConWinner session and is used by this node to send to the adjacent node. The ConLoserr session is initiated by the adjacent node and is used by this node to receive from the adjacent node." ::= { ibmappnNnAdjNodeEntry 2 } ibmappnNnAdjNodeOutOfSeqTdus OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Number of out of sequence Topology Database Updates (TDUs). In a quiesced state, this value is zero. In normal operation, the value varies depending on the network environment." ::= { ibmappnNnAdjNodeEntry 3 } McKenzie & Cheng [Page 61] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnAdjNodeLastFrsnSent OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last TDU sent to this adjacent node." ::= { ibmappnNnAdjNodeEntry 4 } ibmappnNnAdjNodeLastFrsnRcvd OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last TDU received from this adjacent node." ::= { ibmappnNnAdjNodeEntry 5 } --APPN Node Topology table -- This table describes every known APPN Network node -- and Virtual node. ibmappnNnTopologyTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNnTopologyEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Portion of the APPN routing table that describes all of the APPN network nodes and virtual nodes known to this node." ::= { ibmappnNnTopology 1 } ibmappnNnTopologyEntry OBJECT-TYPE SYNTAX IbmappnNnTopologyEntry ACCESS not-accessible STATUS mandatory McKenzie & Cheng [Page 62] RFC 1593 SNA APPN Node MIB March 1994 DESCRIPTION "The fully-qualified node name is used to index this table." INDEX {ibmappnNnNodeName} ::= { ibmappnNnTopologyTable 1 } IbmappnNnTopologyEntry ::= SEQUENCE { ibmappnNnNodeName DisplayString, ibmappnNnNodeFrsn INTEGER, ibmappnNnNodeEntryTimeLeft INTEGER, ibmappnNnNodeType INTEGER, ibmappnNnNodeRsn INTEGER, ibmappnNnNodeRouteAddResist INTEGER, ibmappnNnNodeCongested INTEGER, ibmappnNnNodeIsrDepleted INTEGER, ibmappnNnNodeEndptDepleted INTEGER, ibmappnNnNodeQuiescing INTEGER, ibmappnNnNodeGateway INTEGER, ibmappnNnNodeCentralDirectory INTEGER, ibmappnNnNodeIsr INTEGER, ibmappnNnNodeChainSupport INTEGER } ibmappnNnNodeName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned network name that is locally defined at each network node in the format NETID.CPNAME." ::= { ibmappnNnTopologyEntry 1 } ibmappnNnNodeFrsn OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last time this resource was updated at McKenzie & Cheng [Page 63] RFC 1593 SNA APPN Node MIB March 1994 this node." ::= { ibmappnNnTopologyEntry 2 } ibmappnNnNodeEntryTimeLeft OBJECT-TYPE SYNTAX INTEGER (0..31) ACCESS read-only STATUS mandatory DESCRIPTION "Number of days before deletion of this network node entry. Range is 0-31." ::= { ibmappnNnTopologyEntry 3 } ibmappnNnNodeType OBJECT-TYPE SYNTAX INTEGER { networknode(1), virtualnode(3) } ACCESS read-only STATUS mandatory DESCRIPTION "Type of APPN node." ::= { ibmappnNnTopologyEntry 4 } ibmappnNnNodeRsn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Resource sequence number that is assigned and controlled by the network node that owns this resource. This is always an even 32-bit number unless an error has occurred." ::= { ibmappnNnTopologyEntry 5 } ibmappnNnNodeRouteAddResist OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Route addition resistance indicates the relative desirability of using this node for intermediate session traffic. The value, which can be any integer 0-255, is used in route computation. The lower the value, McKenzie & Cheng [Page 64] RFC 1593 SNA APPN Node MIB March 1994 the more desirable the node is for intermediate routing." ::= { ibmappnNnTopologyEntry 6 } ibmappnNnNodeCongested OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node is congested. This node is not be included in route selection by other nodes when this congestion exists." ::= { ibmappnNnTopologyEntry 7 } ibmappnNnNodeIsrDepleted OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether intermediate session routing resources are depleted. This node is not included in intermediate route selection by other nodes when resources are depleted." ::= { ibmappnNnTopologyEntry 8 } ibmappnNnNodeEndptDepleted OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether session endpoint resources are depleted." ::= { ibmappnNnTopologyEntry 9 } ibmappnNnNodeQuiescing OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node is quiescing. This node is not included in route selection by other nodes when the node is quiescing." ::= { ibmappnNnTopologyEntry 10 } ibmappnNnNodeGateway OBJECT-TYPE McKenzie & Cheng [Page 65] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node provide gateway functions." ::= { ibmappnNnTopologyEntry 11 } ibmappnNnNodeCentralDirectory OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node is central directory." ::= { ibmappnNnTopologyEntry 12 } ibmappnNnNodeIsr OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node supports intermediate session routing (ISR)." ::= { ibmappnNnTopologyEntry 13 } ibmappnNnNodeChainSupport OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node supports chaining." ::= { ibmappnNnTopologyEntry 14 } --APPN transmission group (TG) table -- This table describes the TGs associated with -- the APPN network nodes. -- The originating node is repeated here to provide a -- means of correlating the TGs with the nodes. ibmappnNnTgTopologyTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNnTgTopologyEntry ACCESS not-accessible McKenzie & Cheng [Page 66] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Portion of the APPN topology database that describes all of the APPN transmissions groups used by the APPN network nodes." ::= { ibmappnNnTopology 2 } ibmappnNnTgTopologyEntry OBJECT-TYPE SYNTAX IbmappnNnTgTopologyEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table requires three indexes to provide a unique index. The indexes are the owning or originating CPname, the destination CPname, and the TG number." INDEX {ibmappnNnTgOwner, ibmappnNnTgDest, ibmappnNnTgNum} ::= { ibmappnNnTgTopologyTable 1 } IbmappnNnTgTopologyEntry ::= SEQUENCE { ibmappnNnTgOwner DisplayString, ibmappnNnTgDest DisplayString, ibmappnNnTgNum INTEGER, ibmappnNnTgFrsn INTEGER, ibmappnNnTgEntryTimeLeft INTEGER, ibmappnNnTgDestVirtual INTEGER, ibmappnNnTgDlcData OCTET STRING, ibmappnNnTgRsn INTEGER, ibmappnNnTgOperational INTEGER, ibmappnNnTgQuiescing INTEGER, ibmappnNnTgCpCpSession INTEGER, ibmappnNnTgEffCap INTEGER, ibmappnNnTgConnCost INTEGER, ibmappnNnTgByteCost INTEGER, ibmappnNnTgSecurity INTEGER, ibmappnNnTgDelay INTEGER, ibmappnNnTgModemClass INTEGER, ibmappnNnTgUsr1 INTEGER, ibmappnNnTgUsr2 INTEGER, ibmappnNnTgUsr3 INTEGER} McKenzie & Cheng [Page 67] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnTgOwner OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for the originating node for this TG. The format is NETID.CPNAME and is the same name specified in the node table." ::= { ibmappnNnTgTopologyEntry 1 } ibmappnNnTgDest OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned fully-qualified network name for the destination node for this TG." ::= { ibmappnNnTgTopologyEntry 2 } ibmappnNnTgNum OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number associated with this transmission group. Range is 0-255." ::= { ibmappnNnTgTopologyEntry 3 } ibmappnNnTgFrsn OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last time this resource was updated at this node." ::= { ibmappnNnTgTopologyEntry 4 } ibmappnNnTgEntryTimeLeft OBJECT-TYPE SYNTAX INTEGER (0..31) McKenzie & Cheng [Page 68] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "Number of days before deletion of this network node TG entry. Range is 0-31." ::= { ibmappnNnTgTopologyEntry 5 } ibmappnNnTgDestVirtual OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the destination node is a virtual node." ::= { ibmappnNnTgTopologyEntry 6 } ibmappnNnTgDlcData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..9)) ACCESS read-only STATUS mandatory DESCRIPTION "DLC specific data related to the link connection network. Token-Ring - MAC/SAP X.25 Switched - dial digits X.21 Switched - dial digits Circuit Swtch - dial digits" ::= { ibmappnNnTgTopologyEntry 7 } ibmappnNnTgRsn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Current owning node's resource sequence number for this resource." ::= { ibmappnNnTgTopologyEntry 8 } ibmappnNnTgOperational OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the transmission group McKenzie & Cheng [Page 69] RFC 1593 SNA APPN Node MIB March 1994 is operational." ::= { ibmappnNnTgTopologyEntry 9 } ibmappnNnTgQuiescing OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the transmission group is quiescing." ::= { ibmappnNnTgTopologyEntry 10 } ibmappnNnTgCpCpSession OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether CP-CP sessions are supported on this TG." ::= { ibmappnNnTgTopologyEntry 11 } ibmappnNnTgEffCap OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The effective capacity is an integer value that indicates the kilo bits per second. It is derived from the link bandwidth and maximum load factor with the range of 0 thru 603,979,776. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyEntry 12 } ibmappnNnTgConnCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255, which indicates maximum cost. This is an administratively assigned value associated McKenzie & Cheng [Page 70] RFC 1593 SNA APPN Node MIB March 1994 with this TG." ::= { ibmappnNnTgTopologyEntry 13 } ibmappnNnTgByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Relative cost of transmitting a byte over this link. Range is from 0 (lowest cost) to 255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyEntry 14 } ibmappnNnTgSecurity OBJECT-TYPE SYNTAX INTEGER { nonsecure(1), --X'01' publicSwitchedNetwork(32), --X'20' undergroundCable(64), --X'40' secureConduit(96), --X'60' guardedConduit(128), --X'80' encrypted(160), --X'A0' guardedRadiation(192) --X'C0' } ACCESS read-only STATUS mandatory DESCRIPTION "The security is represented as an integer with a range of 1 thru 255 with the most common values enumerated as defined above. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyEntry 15 } ibmappnNnTgDelay OBJECT-TYPE SYNTAX INTEGER { minimum(0), --X'00' negligible(384), --X'4C' terrestrial(9216), --X'71' packet(147456), --X'91' long(294912), --X'99' maximum(2013265920) --X'FF' } ACCESS read-only McKenzie & Cheng [Page 71] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Relative amount of time that it takes for a signal to travel the length of the logical link. This time is represented in micro seconds, with some of the more common values enumerated. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyEntry 16 } ibmappnNnTgModemClass OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This is used to have multiple images for a connection network. For a connection network it is the same as in the TG vector; for a non-connection network it is X'00'." ::= { ibmappnNnTgTopologyEntry 17 } ibmappnNnTgUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "First user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyEntry 18 } ibmappnNnTgUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Second user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyEntry 19 } McKenzie & Cheng [Page 72] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnTgUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Third user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyEntry 20 } --APPN Node Topology table (using FRSN as index) -- This table describes every known APPN Network node -- and Virtual node. ibmappnNnTopologyFRTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNnTopologyFREntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Portion of the APPN routing table that describes all of the APPN network nodes and virtual nodes known to this node." ::= { ibmappnNnTopology 3 } ibmappnNnTopologyFREntry OBJECT-TYPE SYNTAX IbmappnNnTopologyFREntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by two columns: FRSN, followed by fully-qualified node name." INDEX {ibmappnNnNodeFRFrsn, ibmappnNnNodeFRName} ::= { ibmappnNnTopologyFRTable 1 } IbmappnNnTopologyFREntry ::= SEQUENCE { ibmappnNnNodeFRName DisplayString, ibmappnNnNodeFRFrsn INTEGER, ibmappnNnNodeFREntryTimeLeft INTEGER, McKenzie & Cheng [Page 73] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnNodeFRType INTEGER, ibmappnNnNodeFRRsn INTEGER, ibmappnNnNodeFRRouteAddResist INTEGER, ibmappnNnNodeFRCongested INTEGER, ibmappnNnNodeFRIsrDepleted INTEGER, ibmappnNnNodeFREndptDepleted INTEGER, ibmappnNnNodeFRQuiescing INTEGER, ibmappnNnNodeFRGateway INTEGER, ibmappnNnNodeFRCentralDirectory INTEGER, ibmappnNnNodeFRIsr INTEGER, ibmappnNnNodeFRChainSupport INTEGER } ibmappnNnNodeFRName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned network name that is locally defined at each network node in the format NETID.CPNAME." ::= { ibmappnNnTopologyFREntry 1 } ibmappnNnNodeFRFrsn OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last time this resource was updated at this node." ::= { ibmappnNnTopologyFREntry 2 } ibmappnNnNodeFREntryTimeLeft OBJECT-TYPE SYNTAX INTEGER (0..31) ACCESS read-only STATUS mandatory DESCRIPTION "Number of days before deletion of this network node entry. Range is 0-31." ::= { ibmappnNnTopologyFREntry 3 } McKenzie & Cheng [Page 74] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnNodeFRType OBJECT-TYPE SYNTAX INTEGER { networknode(1), virtualnode(3) } ACCESS read-only STATUS mandatory DESCRIPTION "Type of APPN node." ::= { ibmappnNnTopologyFREntry 4 } ibmappnNnNodeFRRsn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Resource sequence number that is assigned and controlled by the network node that owns this resource. This is always an even 32-bit number unless an error has occurred." ::= { ibmappnNnTopologyFREntry 5 } ibmappnNnNodeFRRouteAddResist OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Route addition resistance indicates the relative desirability of using this node for intermediate session traffic. The value, which can be any integer 0-255, is used in route computation. The lower the value, the more desirable the node is for intermediate routing." ::= { ibmappnNnTopologyFREntry 6 } ibmappnNnNodeFRCongested OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node is congested. This node is not be included in route selection by other nodes when this congestion exists." ::= { ibmappnNnTopologyFREntry 7 } McKenzie & Cheng [Page 75] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnNodeFRIsrDepleted OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether intermediate session routing resources are depleted. This node is not included in intermediate route selection by other nodes when resources are depleted." ::= { ibmappnNnTopologyFREntry 8 } ibmappnNnNodeFREndptDepleted OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether session endpoint resources are depleted." ::= { ibmappnNnTopologyFREntry 9 } ibmappnNnNodeFRQuiescing OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node is quiescing. This node is not included in route selection by other nodes when the node is quiescing." ::= { ibmappnNnTopologyFREntry 10 } ibmappnNnNodeFRGateway OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node provide gateway functions." ::= { ibmappnNnTopologyFREntry 11 } ibmappnNnNodeFRCentralDirectory OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node is central directory." ::= { ibmappnNnTopologyFREntry 12 } McKenzie & Cheng [Page 76] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnNodeFRIsr OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node supports intermediate session routing (ISR)." ::= { ibmappnNnTopologyFREntry 13 } ibmappnNnNodeFRChainSupport OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node supports chaining." ::= { ibmappnNnTopologyFREntry 14 } --APPN transmission group (TG) table -- This table describes the TGs associated with -- the APPN network nodes. -- The originating node is repeated here to provide a -- means of correlating the TGs with the nodes. ibmappnNnTgTopologyFRTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnNnTgTopologyFREntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Portion of the APPN topology database that describes all of the APPN transmissions groups used by the APPN network nodes." ::= { ibmappnNnTopology 4 } ibmappnNnTgTopologyFREntry OBJECT-TYPE SYNTAX IbmappnNnTgTopologyFREntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by four columns: FRSN, TG owner fully-qualified node name, TG destination fully-qualified node name, and TG number." INDEX McKenzie & Cheng [Page 77] RFC 1593 SNA APPN Node MIB March 1994 {ibmappnNnTgFRFrsn, ibmappnNnTgFROwner, ibmappnNnTgFRDest, ibmappnNnTgFRNum} ::= { ibmappnNnTgTopologyFRTable 1 } IbmappnNnTgTopologyFREntry ::= SEQUENCE { ibmappnNnTgFROwner DisplayString, ibmappnNnTgFRDest DisplayString, ibmappnNnTgFRNum INTEGER, ibmappnNnTgFRFrsn INTEGER, ibmappnNnTgFREntryTimeLeft INTEGER, ibmappnNnTgFRDestVirtual INTEGER, ibmappnNnTgFRDlcData OCTET STRING, ibmappnNnTgFRRsn INTEGER, ibmappnNnTgFROperational INTEGER, ibmappnNnTgFRQuiescing INTEGER, ibmappnNnTgFRCpCpSession INTEGER, ibmappnNnTgFREffCap INTEGER, ibmappnNnTgFRConnCost INTEGER, ibmappnNnTgFRByteCost INTEGER, ibmappnNnTgFRSecurity INTEGER, ibmappnNnTgFRDelay INTEGER, ibmappnNnTgFRModemClass INTEGER, ibmappnNnTgFRUsr1 INTEGER, ibmappnNnTgFRUsr2 INTEGER, ibmappnNnTgFRUsr3 INTEGER} ibmappnNnTgFROwner OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for the originating node for this TG. The format is NETID.CPNAME and is the same name specified in the node table." ::= { ibmappnNnTgTopologyFREntry 1 } ibmappnNnTgFRDest OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only McKenzie & Cheng [Page 78] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Administratively-assigned fully-qualified network name for the destination node for this TG." ::= { ibmappnNnTgTopologyFREntry 2 } ibmappnNnTgFRNum OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Number associated with this transmission group. Range is 0-255." ::= { ibmappnNnTgTopologyFREntry 3 } ibmappnNnTgFRFrsn OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last time this resource was updated at this node." ::= { ibmappnNnTgTopologyFREntry 4 } ibmappnNnTgFREntryTimeLeft OBJECT-TYPE SYNTAX INTEGER (0..31) ACCESS read-only STATUS mandatory DESCRIPTION "Number of days before deletion of this network node TG entry. Range is 0-31." ::= { ibmappnNnTgTopologyFREntry 5 } ibmappnNnTgFRDestVirtual OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the destination node is a virtual node." McKenzie & Cheng [Page 79] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnNnTgTopologyFREntry 6 } ibmappnNnTgFRDlcData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..9)) ACCESS read-only STATUS mandatory DESCRIPTION "DLC specific data related to the link connection network. Token-Ring - MAC/SAP X.25 Switched - dial digits X.21 Switched - dial digits Circuit Swtch - dial digits" ::= { ibmappnNnTgTopologyFREntry 7 } ibmappnNnTgFRRsn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Current owning node's resource sequence number for this resource." ::= { ibmappnNnTgTopologyFREntry 8 } ibmappnNnTgFROperational OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the transmission group is operational." ::= { ibmappnNnTgTopologyFREntry 9 } ibmappnNnTgFRQuiescing OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the transmission group is quiescing." ::= { ibmappnNnTgTopologyFREntry 10 } ibmappnNnTgFRCpCpSession OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} McKenzie & Cheng [Page 80] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether CP-CP sessions are supported on this TG." ::= { ibmappnNnTgTopologyFREntry 11 } ibmappnNnTgFREffCap OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The effective capacity is an integer value that indicates the kilo bits per second. It is derived from the link bandwidth and maximum load factor with the range of 0 thru 603,979,776. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 12 } ibmappnNnTgFRConnCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255, which indicates maximum cost. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 13 } ibmappnNnTgFRByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Relative cost of transmitting a byte over this link. Range is from 0 (lowest cost) to 255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 14 } McKenzie & Cheng [Page 81] RFC 1593 SNA APPN Node MIB March 1994 ibmappnNnTgFRSecurity OBJECT-TYPE SYNTAX INTEGER { nonsecure(1), --X'01' publicSwitchedNetwork(32), --X'20' undergroundCable(64), --X'40' secureConduit(96), --X'60' guardedConduit(128), --X'80' encrypted(160), --X'A0' guardedRadiation(192) --X'C0' } ACCESS read-only STATUS mandatory DESCRIPTION "The security is represented as an integer with a range of 1 thru 255 with the most common values enumerated as defined above. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 15 } ibmappnNnTgFRDelay OBJECT-TYPE SYNTAX INTEGER { minimum(0), --X'00' negligible(384), --X'4C' terrestrial(9216), --X'71' packet(147456), --X'91' long(294912), --X'99' maximum(2013265920) --X'FF' } ACCESS read-only STATUS mandatory DESCRIPTION "Relative amount of time that it takes for a signal to travel the length of the logical link. This time is represented in micro seconds, with some of the more common values enumerated. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 16 } ibmappnNnTgFRModemClass OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This is used to have multiple images for a McKenzie & Cheng [Page 82] RFC 1593 SNA APPN Node MIB March 1994 connection network. For a connection network it is the same as in the TG vector; for a non-connection network it is X'00'." ::= { ibmappnNnTgTopologyFREntry 17 } ibmappnNnTgFRUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "First user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 18 } ibmappnNnTgFRUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Second user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 19 } ibmappnNnTgFRUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Third user-defined TG characteristic for this TG with a range of 0-255. This is an administratively assigned value associated with this TG." ::= { ibmappnNnTgTopologyFREntry 20 } -- ************** The APPN Local Topology Group ***************** ibmappnLocalTopology OBJECT IDENTIFIER ::= { ibmappn 3 } ibmappnLocalThisNode OBJECT IDENTIFIER ::= { ibmappnLocalTopology 1 } ibmappnLocalGeneral OBJECT IDENTIFIER ::= { ibmappnLocalThisNode 1} McKenzie & Cheng [Page 83] RFC 1593 SNA APPN Node MIB March 1994 ibmappnLocalNnSpecific OBJECT IDENTIFIER ::= { ibmappnLocalThisNode 2} ibmappnLocalTg OBJECT IDENTIFIER ::= { ibmappnLocalThisNode 3} ibmappnLocalEnTopology OBJECT IDENTIFIER ::= { ibmappnLocalTopology 2 } -- The LocalEnNodeTable and LocalEnTgTable will replace these OIs --ibmappnLocalEnNode OBJECT IDENTIFIER ::= { ibmappnLocalEnTopology 1} --ibmappnLocalEnTg OBJECT IDENTIFIER ::= { ibmappnLocalEnTopology 2} --This MIB Group represents the local topology --maintained in both APPN end nodes and network nodes. --Although the same control vectors are used for both network --and local topology, many of the attributes only apply to network --nodes. This MIB group defines the required objects for retrieval --of information about this node and the objects that represent --the local topology about end nodes. -- --This node could be either an network node or an end node. The --definition must address both cases. -- --1 Information about this node -- a General information about this node, both NN and ENs. -- b Information about this node that applies only to NNs. -- c TG table (repeated for each TG this node owns) -- --2 Information about the end nodes known to this network node -- (THIS SECTION ONLY APPLIES TO NETWORK NODES) -- a End node table (entry for each end node ) -- b TG table (repeated for each TG owned by the end nodes) -- -- ---- -- General information section ibmappnLocalNodeName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned fully-qualified name for this node. Format is NETID.CPNAME." ::= { ibmappnLocalGeneral 1 } ibmappnLocalNodeType OBJECT-TYPE McKenzie & Cheng [Page 84] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX INTEGER { networknode(1), endnode(2), len(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Type of APPN node." ::= { ibmappnLocalGeneral 2 } -- Network node unique information -- ibmappnLocalNnRsn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Resource sequence number is assigned and controlled by the network node that owns this resource. This is always an even unsigned number unless an error has occurred." ::= { ibmappnLocalNnSpecific 1 } ibmappnLocalNnRouteAddResist OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Route addition resistance indicates the relative desirability of using this node for intermediate session traffic. The value, which can be any integer 0-255, is used in route computation. The lower the value, the more desirable the node is for intermediate routing." ::= { ibmappnLocalNnSpecific 2 } ibmappnLocalNnCongested OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether this node is congested. McKenzie & Cheng [Page 85] RFC 1593 SNA APPN Node MIB March 1994 Other network nodes stop routing traffic to this node while this flag is on." ::= { ibmappnLocalNnSpecific 3 } ibmappnLocalNnIsrDepleted OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicate whether intermediated session routing resources are depleted. Other network nodes stop routing traffic through this node while this flag is on." ::= { ibmappnLocalNnSpecific 4 } ibmappnLocalNnEndptDepleted OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether session endpoint resources are depleted." ::= { ibmappnLocalNnSpecific 5 } ibmappnLocalNnQuiescing OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node is quiescing." ::= { ibmappnLocalNnSpecific 6 } ibmappnLocalNnGateway OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node is a gateway." ::= { ibmappnLocalNnSpecific 7 } ibmappnLocalNnCentralDirectory OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only McKenzie & Cheng [Page 86] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Indicates whether the node is a central directory." ::= { ibmappnLocalNnSpecific 8 } ibmappnLocalNnIsr OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node supports intermediate session routing." ::= { ibmappnLocalNnSpecific 9 } ibmappnLocalNnChainSupport OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the node supports chaining." ::= { ibmappnLocalNnSpecific 10 } ibmappnLocalNnFrsn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This object is the last FRSN sent in a topology update to adjacent network nodes." ::= { ibmappnLocalNnSpecific 11 } -- Local TG information -- APPN Transmission Group (TG) Table -- This table describes the TGs associated with -- this node only. ibmappnLocalTgTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnLocalTgEntry McKenzie & Cheng [Page 87] RFC 1593 SNA APPN Node MIB March 1994 ACCESS not-accessible STATUS mandatory DESCRIPTION "TG Table describes all of the TGs owned by this node. The TG destination can be a virtual node, network node, len, or end node." ::= { ibmappnLocalTg 1 } ibmappnLocalTgEntry OBJECT-TYPE SYNTAX IbmappnLocalTgEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by the destination CPname and the TG number." INDEX {ibmappnLocalTgDest, ibmappnLocalTgNum} ::= { ibmappnLocalTgTable 1 } IbmappnLocalTgEntry ::= SEQUENCE { ibmappnLocalTgDest DisplayString, ibmappnLocalTgNum INTEGER, ibmappnLocalTgDestVirtual INTEGER, ibmappnLocalTgDlcData OCTET STRING, ibmappnLocalTgRsn INTEGER, ibmappnLocalTgQuiescing INTEGER, ibmappnLocalTgOperational INTEGER, ibmappnLocalTgCpCpSession INTEGER, ibmappnLocalTgEffCap INTEGER, ibmappnLocalTgConnCost INTEGER, ibmappnLocalTgByteCost INTEGER, ibmappnLocalTgSecurity INTEGER, ibmappnLocalTgDelay INTEGER, ibmappnLocalTgModemClass INTEGER, ibmappnLocalTgUsr1 INTEGER, ibmappnLocalTgUsr2 INTEGER, ibmappnLocalTgUsr3 INTEGER } ibmappnLocalTgDest OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only McKenzie & Cheng [Page 88] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Administratively-assigned name for the destination node for this TG. This is the fully-qualified network node name." ::= { ibmappnLocalTgEntry 1 } ibmappnLocalTgNum OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number associated with this transmission group." ::= { ibmappnLocalTgEntry 2 } ibmappnLocalTgDestVirtual OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the destination node is a Virtual node." ::= { ibmappnLocalTgEntry 3 } ibmappnLocalTgDlcData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..9)) ACCESS read-only STATUS mandatory DESCRIPTION "DLC specific data related to the link connection network. Token-Ring - MAC/SAP X.25 Switched - dial digits X.21 Switched - dial digits Circuit Swtch - dial digits" ::= { ibmappnLocalTgEntry 4 } ibmappnLocalTgRsn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The resource sequence number is assigned and controlled by the network node that owns this McKenzie & Cheng [Page 89] RFC 1593 SNA APPN Node MIB March 1994 resource. This is always an even unsigned number unless an error has occurred." ::= { ibmappnLocalTgEntry 5 } ibmappnLocalTgQuiescing OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the Transmission Group is quiescing." ::= { ibmappnLocalTgEntry 6 } ibmappnLocalTgOperational OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the Transmission Group is operational." ::= { ibmappnLocalTgEntry 7 } ibmappnLocalTgCpCpSession OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the CP-CP Sessions are supported on this TG." ::= { ibmappnLocalTgEntry 8 } ibmappnLocalTgEffCap OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The effective capacity is an integer value that indicates the actual kilo bits per second. It is derived from the link bandwidth and maximum load factor with the range of 0 thru 603,979,776." ::= { ibmappnLocalTgEntry 9 } ibmappnLocalTgConnCost OBJECT-TYPE McKenzie & Cheng [Page 90] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255." ::= { ibmappnLocalTgEntry 10 } ibmappnLocalTgByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Relative cost of transmitting a byte over this link. Range is from 0 (lowest cost) to 255." ::= { ibmappnLocalTgEntry 11 } ibmappnLocalTgSecurity OBJECT-TYPE SYNTAX INTEGER { nonsecure(1), --X'01' publicSwitchedNetwork(32), --X'20' undergroundCable(64), --X'40' secureConduit(96), --X'60' guardedConduit(128), --X'80' encrypted(160), --X'A0' guardedRadiation(192) --X'C0' } ACCESS read-only STATUS mandatory DESCRIPTION "Security level for this TG." ::= { ibmappnLocalTgEntry 12 } ibmappnLocalTgDelay OBJECT-TYPE SYNTAX INTEGER { minimum(0), --X'00' negligible(384), --X'4C' terrestrial(9216), --X'71' packet(147456), --X'91' long(294912), --X'99' maximum(2013265920) --X'FF' } ACCESS read-only McKenzie & Cheng [Page 91] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Relative amount of time that it takes for a signal to travel the length of the logical link. This time is represented in micro seconds, with some of the more common values enumerated." ::= { ibmappnLocalTgEntry 13 } ibmappnLocalTgModemClass OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This is used to have multiple images for a connection network. For a connection network it is the same as in the TG vector and for a non-connection network it is zero." ::= { ibmappnLocalTgEntry 14 } ibmappnLocalTgUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Value of the first user-defined TG characteristic for this TG. Range is 0-255." ::= { ibmappnLocalTgEntry 15 } ibmappnLocalTgUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Value of the second user-defined TG characteristic for this TG. Range is 0-255." ::= { ibmappnLocalTgEntry 16 } ibmappnLocalTgUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION McKenzie & Cheng [Page 92] RFC 1593 SNA APPN Node MIB March 1994 "Value of the third user-defined TG characteristic for this TG. Range is 0-255." ::= { ibmappnLocalTgEntry 17 } -- This section applies only to network nodes. -- It contains end node topology information known to serving -- network node. -- The first table contains information about all end nodes -- known to this node. -- -- The TG table contains information about all of the TGs owned -- by these end nodes. ibmappnLocalEnTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnLocalEnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Portion of the APPN topology database that describes the end nodes known to this node." ::= { ibmappnLocalEnTopology 1 } ibmappnLocalEnEntry OBJECT-TYPE SYNTAX IbmappnLocalEnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by the end node CPname." INDEX {ibmappnLocalEnName} ::= { ibmappnLocalEnTable 1 } IbmappnLocalEnEntry ::= SEQUENCE { ibmappnLocalEnName DisplayString, ibmappnLocalEnEntryTimeLeft INTEGER, ibmappnLocalEnType INTEGER } ibmappnLocalEnName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) McKenzie & Cheng [Page 93] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned fully-qualified name of end node in the format NETID.CPNAME." ::= { ibmappnLocalEnEntry 1 } ibmappnLocalEnEntryTimeLeft OBJECT-TYPE SYNTAX INTEGER (0..31) ACCESS read-only STATUS mandatory DESCRIPTION "Number of days before deletion of this end node entry. Range is 0-31." ::= { ibmappnLocalEnEntry 2 } ibmappnLocalEnType OBJECT-TYPE SYNTAX INTEGER { endnode(2), len(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Type of APPN node (must always be a len or end node)." ::= { ibmappnLocalEnEntry 3 } --APPN Local End node Transmission Group (TG) table -- This table describes the TGs associated with -- all of the end nodes known to this node. ibmappnLocalEnTgTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnLocalEnTgEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table describing all of the TGs owned by the end nodes known to this node. The TG destination can be a virtual node, network node, or end node." ::= { ibmappnLocalEnTopology 2 } McKenzie & Cheng [Page 94] RFC 1593 SNA APPN Node MIB March 1994 ibmappnLocalEnTgEntry OBJECT-TYPE SYNTAX IbmappnLocalEnTgEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table requires multiple indexes to uniquely identify each TG. They are originating CPname, destination CPname, and the TG number." INDEX {ibmappnLocalEnTgOrigin, ibmappnLocalEnTgDest, ibmappnLocalEnTgNum} ::= { ibmappnLocalEnTgTable 1 } IbmappnLocalEnTgEntry ::= SEQUENCE { ibmappnLocalEnTgOrigin DisplayString, ibmappnLocalEnTgDest DisplayString, ibmappnLocalEnTgNum INTEGER, ibmappnLocalEnTgEntryTimeLeft INTEGER, ibmappnLocalEnTgDestVirtual INTEGER, ibmappnLocalEnTgDlcData OCTET STRING, ibmappnLocalEnTgOperational INTEGER, ibmappnLocalEnTgCpCpSession INTEGER, ibmappnLocalEnTgEffCap INTEGER, ibmappnLocalEnTgConnCost INTEGER, ibmappnLocalEnTgByteCost INTEGER, ibmappnLocalEnTgSecurity INTEGER, ibmappnLocalEnTgDelay INTEGER, ibmappnLocalEnTgModemClass INTEGER, ibmappnLocalEnTgUsr1 INTEGER, ibmappnLocalEnTgUsr2 INTEGER, ibmappnLocalEnTgUsr3 INTEGER } ibmappnLocalEnTgOrigin OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for the origination node for this TG. This is the fully-qualified network name." ::= { ibmappnLocalEnTgEntry 1 } McKenzie & Cheng [Page 95] RFC 1593 SNA APPN Node MIB March 1994 ibmappnLocalEnTgDest OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for the destination node for this TG. This is the fully-qualified network name." ::= { ibmappnLocalEnTgEntry 2 } ibmappnLocalEnTgNum OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number associated with this transmission group." ::= { ibmappnLocalEnTgEntry 3 } ibmappnLocalEnTgEntryTimeLeft OBJECT-TYPE SYNTAX INTEGER (0..31) ACCESS read-only STATUS mandatory DESCRIPTION "Number of days before deletion of this end node TG entry. Range is 0-31." ::= { ibmappnLocalEnTgEntry 4 } ibmappnLocalEnTgDestVirtual OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the destination node is a virtual node." ::= { ibmappnLocalEnTgEntry 5 } ibmappnLocalEnTgDlcData OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "DLC specific data related to the link connection network. Token-Ring - MAC/SAP McKenzie & Cheng [Page 96] RFC 1593 SNA APPN Node MIB March 1994 X.25 Switched - dial digits X.21 Switched - dial digits Circuit Swtch - dial digits" ::= { ibmappnLocalEnTgEntry 6 } ibmappnLocalEnTgOperational OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the Transmission Group is operational." ::= { ibmappnLocalEnTgEntry 7 } ibmappnLocalEnTgCpCpSession OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether CP-CP sessions are supported on this TG." ::= { ibmappnLocalEnTgEntry 8 } ibmappnLocalEnTgEffCap OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The effective capacity is an integer value that indicates the actual kilo bits per second. It is derived from the link bandwidth and maximum load factor with the range of 0 thru 603,979,776." ::= { ibmappnLocalEnTgEntry 9 } ibmappnLocalEnTgConnCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255." ::= { ibmappnLocalEnTgEntry 10 } McKenzie & Cheng [Page 97] RFC 1593 SNA APPN Node MIB March 1994 ibmappnLocalEnTgByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Relative cost of transmitting a byte over this link. Range is from 0, which means no cost, to 255." ::= { ibmappnLocalEnTgEntry 11 } ibmappnLocalEnTgSecurity OBJECT-TYPE SYNTAX INTEGER { nonsecure(1), --X'01' publicSwitchedNetwork(32), --X'20' undergroundCable(64), --X'40' secureConduit(96), --X'60' guardedConduit(128), --X'80' encrypted(160), --X'A0' guardedRadiation(192) --X'C0' } ACCESS read-only STATUS mandatory DESCRIPTION "Security level for this TG." ::= { ibmappnLocalEnTgEntry 12 } ibmappnLocalEnTgDelay OBJECT-TYPE SYNTAX INTEGER { minimum(0), --X'00' negligible(384), --X'4C' terrestrial(9216), --X'71' packet(147456), --X'91' long(294912), --X'99' maximum(2013265920) --X'FF' } ACCESS read-only STATUS mandatory DESCRIPTION "Relative amount of time that it takes for a signal to travel the length of the logical link. This time is represented in micro seconds, with some of the more common values enumerated." ::= { ibmappnLocalEnTgEntry 13 } ibmappnLocalEnTgModemClass OBJECT-TYPE SYNTAX INTEGER (0..65535) McKenzie & Cheng [Page 98] RFC 1593 SNA APPN Node MIB March 1994 ACCESS read-only STATUS mandatory DESCRIPTION "This is used to have multiple images for a connection network. For a connection network it is the same as in the TG vector and for a non connection network it is zero." ::= { ibmappnLocalEnTgEntry 14 } ibmappnLocalEnTgUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "First user-defined TG characteristic for this TG. Range of values is 0-255." ::= { ibmappnLocalEnTgEntry 15 } ibmappnLocalEnTgUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Second user-defined TG characteristic for this TG. Range of values is 0-255." ::= { ibmappnLocalEnTgEntry 16 } ibmappnLocalEnTgUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Third user-defined TG characteristic for this TG. Range of values is 0-255." ::= { ibmappnLocalEnTgEntry 17 } -- ************** The APPN Directory group ********************** ibmappnDir OBJECT IDENTIFIER ::= { ibmappn 5 } ibmappnDirPerf OBJECT IDENTIFIER ::= { ibmappnDir 1 } -- The APPN Directory Group -- The APPN Directory Database McKenzie & Cheng [Page 99] RFC 1593 SNA APPN Node MIB March 1994 -- Each APPN network node maintains directories containing -- information on which LUs (applications) are available and -- where they are located. LUs can be located within an APPN -- network node or in any of the attached end nodes. -- Max Cache Directory Entries -- Current Number of Cache Entries -- Current Number Home Entries -- Current Number of Registered Entries -- number of directed locates sent -- number of directed locates received -- number of broadcast locates sent -- number of broadcast locates received -- Number of locates returned with a found -- Number of locates returned with a not found -- Number of outstanding Locates -- Directory table (Repeated for each Serving NN) -- Serving Network Node Fully Qualified CP Name -- LU Groups within Directory table (one for each LU) -- Fully-qualified LU Name -- Owning fully-qualified CP Name -- TP Name -- Resource location (local/domain/cross-domain) -- Entry type (home,Register/cache) -- Wildcard (yes/no) ibmappnDirMaxCaches OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum number of cache entries allowed. This is an administratively assigned value." ::= { ibmappnDirPerf 1 } ibmappnDirCurCaches OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Current number of cache entries." ::= { ibmappnDirPerf 2 } McKenzie & Cheng [Page 100] RFC 1593 SNA APPN Node MIB March 1994 ibmappnDirCurHomeEntries OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Current number of home entries." ::= { ibmappnDirPerf 3 } ibmappnDirRegEntries OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Current number of registered entries." ::= { ibmappnDirPerf 4 } ibmappnDirInLocates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of directed locates received." ::= { ibmappnDirPerf 5 } ibmappnDirInBcastLocates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of broadcast locates received." ::= { ibmappnDirPerf 6 } ibmappnDirOutLocates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of directed locates sent." ::= { ibmappnDirPerf 7 } ibmappnDirOutBcastLocates OBJECT-TYPE SYNTAX Counter ACCESS read-only McKenzie & Cheng [Page 101] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "Number of broadcast locates sent." ::= { ibmappnDirPerf 8 } ibmappnDirNotFoundLocates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of directed locates returned with a 'not found'." ::= { ibmappnDirPerf 9 } ibmappnDirNotFoundBcastLocates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Number of broadcast locates returned with a not found." ::= { ibmappnDirPerf 10 } ibmappnDirLocateOutstands OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "Current number of outstanding locates, both directed and broadcast. This value varies. A value of zero indicates that no locates are unanswered." ::= { ibmappnDirPerf 11 } --APPN Directory table -- This table contains information about all known -- LUs and TPs. ibmappnDirTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnDirEntry ACCESS not-accessible STATUS mandatory DESCRIPTION McKenzie & Cheng [Page 102] RFC 1593 SNA APPN Node MIB March 1994 "Table containing information about all known LUs and TPs." ::= { ibmappnDir 2 } ibmappnDirEntry OBJECT-TYPE SYNTAX IbmappnDirEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by the LU name." INDEX {ibmappnDirLuName} ::= { ibmappnDirTable 1 } IbmappnDirEntry ::= SEQUENCE { ibmappnDirLuName DisplayString, ibmappnDirServerName DisplayString, ibmappnDirLuOwnerName DisplayString, ibmappnDirLuLocation INTEGER, ibmappnDirType INTEGER, ibmappnDirWildCard INTEGER } ibmappnDirLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Fully-qualified network LU name in the domain of the serving network node." ::= { ibmappnDirEntry 1 } ibmappnDirServerName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Fully-qualified control point (CP) name of the network node server. For unassociated end node entries, the end node fully-qualified name is returned." ::= { ibmappnDirEntry 2 } McKenzie & Cheng [Page 103] RFC 1593 SNA APPN Node MIB March 1994 ibmappnDirLuOwnerName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) ACCESS read-only STATUS mandatory DESCRIPTION "Fully-qualified CP name of the node at which the LU is located. This name is the same as the serving NN name when the LU is located at a network node or an unassociated end node. It is also the same as the fully-qualified LU name when this is the control point LU for this node." ::= { ibmappnDirEntry 3 } ibmappnDirLuLocation OBJECT-TYPE SYNTAX INTEGER { local(1), --Local domain(2), --Domain xdomain(3) --Cross Domain } ACCESS read-only STATUS mandatory DESCRIPTION "Specifies the location of the LU." ::= { ibmappnDirEntry 4 } ibmappnDirType OBJECT-TYPE SYNTAX INTEGER { home(1), --defined as home entry cache(2), --learned over time registered(3) --registered by end node } ACCESS read-only STATUS mandatory DESCRIPTION "Directory types are: 1 - Home The LU is in the domain of the local network node and the LU information has been configured at the local node. 2 - Cache The LU has previously been located by a broadcast search and the location information has been saved. 3 - Register McKenzie & Cheng [Page 104] RFC 1593 SNA APPN Node MIB March 1994 The LU is at an end node that is in the domain of the local network node. Registered entries are registered by the served end node." ::= { ibmappnDirEntry 5 } ibmappnDirWildCard OBJECT-TYPE SYNTAX INTEGER { other(1), explicit-entry(2), partial-wildcard(3), full-wildcard(4) } ACCESS read-only STATUS mandatory DESCRIPTION "1 - Other means unknown type of LU entry. 2 - Expliced-entry means the full LUNAME will be used for locating this LU. 3 - Partial-wildcard means only the non-blank portions of the LUNAME will be used for locating this LU. 4 - Full-wildcard means all LUNAMES will be directed to this LU." ::= { ibmappnDirEntry 6 } -- ************** The APPN Class of Service group *************** ibmappnCos OBJECT IDENTIFIER ::= { ibmappn 6 } --APPN COS -- The APPN Class of Service (COS) -- Class of Service is a means of expressing the quality of the routes -- and the transmission priority of traffic which flows on these routes. -- The quality of routes is specified by two tables, a COS weight table -- for TGs and a COS weight table for nodes. These COS tables are -- administratively assigned at each APPN node. Seven default tables -- for TGs and a COS weight table for Nodes. These COS tables are -- administratively assigned at each APPN node with seven default tables -- being provided by IBM. -- -- -- COS Name -- Unqualified name identifying the class of service. -- Transmission priority McKenzie & Cheng [Page 105] RFC 1593 SNA APPN Node MIB March 1994 -- Transmission priority associated with this class of service -- COS Node Row Table -- At least one node row must be specified. The default -- COS tables specify 8 rows. -- Node Row Weight -- Numeric value between 0 and 255 inclusive indicating -- the weight associated with this row. -- Route addition resist (min) -- Numeric value between 0 and 255 inclusive indicating -- the minimum route addition resistance for this row. -- Route addition resist (max) -- Numeric value between 0 and 255 inclusive indicating -- the maximum route addition resistance for this row. -- Congestion (min) -- Indicates whether this class of service for this row -- will accept congestion. Yes or No must be specified. -- Congestion (max) -- Indicates whether this Class of Service for this row -- will accept congestion. Yes or No must be specified. -- -- COS TG Row table -- At least one TG row must be specified with the defaults -- COS tables specify 8 rows. -- TG Row Weight -- Numeric value between 0 and 255 inclusive indicating -- the weight associated with this row. -- Effective capacity (min) -- Indicates the lowest acceptable value for this row. -- Effective capacity (max) -- Indicates the highest required value for this row. -- Cost per connect time (min) -- Indicates the lowest connect cost per unit time value -- for this row. This value is between 0 and 255 inclusive. -- Cost per connect time (max) -- Indicates the highest connect cost per unit time value -- for this row. This value is between 0 and 255 inclusive. -- Cost per byte (min) -- Indicates the lowest cost per byte value -- for this row. This value is between 0 and 255 inclusive. -- Cost per byte (max) -- Indicates the highest cost per byte value -- for this row. This value is between 0 and 255 inclusive. -- Security (min) -- Indicates the lowest acceptable value for security -- for this row. This value is one of seven values. -- Security (max) -- Indicates the highest acceptable value for security -- for this row. This value is one of seven values. McKenzie & Cheng [Page 106] RFC 1593 SNA APPN Node MIB March 1994 -- Propagation delay (min) -- Indicates the lowest acceptable propagation delay value -- for this row. -- Propagation delay (max) -- Indicates the highest acceptable propagation delay value -- for this row. -- User defined 1 (min) -- Indicates the lowest acceptable value -- for this row. This value is between 0 and 255 inclusive. -- User defined 1 (max) -- Indicates the highest acceptable value -- for this row. This value is between 0 and 255 inclusive. -- User defined 2 (min) -- Same as user defined 1 -- User defined 2 (max) -- Same as user defined 1 -- User defined 3 (min) -- Same as user defined 1 -- User defined 3 (max) -- Same as user defined 1 -- -- -- --Due to SNMP ASN.1 limitations the COS table is defined --in the following format. -- -- MODE name table -- MODE Name (index) -- COS Name -- -- COS name table -- COS Name (index) -- Transmission priority -- -- COS node row table -- COS Name (index1) -- Index2 -- Node Row Weight -- Rte addition resist (min) -- Rte addition resist (max) -- Congestion (min) -- Congestion (max) -- -- COS TG row table -- COS Name (index1) -- Index -- TG Row Weight -- Effective capacity (min) McKenzie & Cheng [Page 107] RFC 1593 SNA APPN Node MIB March 1994 -- Effective capacity (max) -- Cost per conn time (min) -- Cost per conn time (max) -- cost per byte (min) -- cost per byte (max) -- Security (min) -- Security (max) -- Propagation delay (min) -- Propagation delay (max) -- User defined 1 (min) -- User defined 1 (max) -- User defined 2 (min) -- User defined 2 (max) -- User defined 3 (min) -- User defined 3 (max) -- -- ************************************************************** ibmappnCosModeTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnCosModeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table representing all of the defined mode names for this node. The table contains the matching COS name." ::= { ibmappnCos 1 } ibmappnCosModeEntry OBJECT-TYPE SYNTAX IbmappnCosModeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table is indexed by the Mode Name." INDEX {ibmappnCosModeName} ::= { ibmappnCosModeTable 1 } IbmappnCosModeEntry ::= SEQUENCE { ibmappnCosModeName DisplayString, ibmappnCosModeCosName DisplayString } ibmappnCosModeName OBJECT-TYPE McKenzie & Cheng [Page 108] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this mode entry." ::= { ibmappnCosModeEntry 1 } ibmappnCosModeCosName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "An administratively assigned name for this Class of Service." ::= { ibmappnCosModeEntry 2 } -- ************************************************************** ibmappnCosNameTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnCosNameEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table representing all of the defined class-of-service names for this node. The COS node and TG tables are accessed using the same index, which is the COS name." ::= { ibmappnCos 2 } ibmappnCosNameEntry OBJECT-TYPE SYNTAX IbmappnCosNameEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The COS name is the index to this table." INDEX {ibmappnCosName} ::= { ibmappnCosNameTable 1 } IbmappnCosNameEntry ::= SEQUENCE { ibmappnCosName DisplayString, ibmappnCosTransPriority INTEGER McKenzie & Cheng [Page 109] RFC 1593 SNA APPN Node MIB March 1994 } ibmappnCosName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this class of service." ::= { ibmappnCosNameEntry 1 } ibmappnCosTransPriority OBJECT-TYPE SYNTAX INTEGER { low(1), --X'01' medium(2), --X'02' high(3), --X'03' network(4) --X'04' } ACCESS read-only STATUS mandatory DESCRIPTION "Transmission priority for this class of service. Values are: Low Medium High Network " ::= { ibmappnCosNameEntry 2 } ibmappnCosNodeRowTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnCosNodeRowEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains all node-row information for all class of service in this node." ::= { ibmappnCos 3 } ibmappnCosNodeRowEntry OBJECT-TYPE SYNTAX IbmappnCosNodeRowEntry ACCESS not-accessible STATUS mandatory DESCRIPTION McKenzie & Cheng [Page 110] RFC 1593 SNA APPN Node MIB March 1994 "The COS name is the first index and a integer is the second index to insure a unique index." INDEX {ibmappnCosNodeRowName, ibmappnCosNodeRowIndex} ::= { ibmappnCosNodeRowTable 1 } IbmappnCosNodeRowEntry ::= SEQUENCE { ibmappnCosNodeRowName DisplayString, ibmappnCosNodeRowIndex INTEGER, --Node Row Group ibmappnCosNodeRowWgt DisplayString, ibmappnCosNodeRowResistMin INTEGER, ibmappnCosNodeRowResistMax INTEGER, ibmappnCosNodeRowMinCongestAllow INTEGER, ibmappnCosNodeRowMaxCongestAllow INTEGER } ibmappnCosNodeRowName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this class of service." ::= { ibmappnCosNodeRowEntry 1 } ibmappnCosNodeRowIndex OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Index of COS name. This same value is used to access the node and TG COS tables. Range of values is 0-255." ::= { ibmappnCosNodeRowEntry 2 } --Node Row Group ibmappnCosNodeRowWgt OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION McKenzie & Cheng [Page 111] RFC 1593 SNA APPN Node MIB March 1994 "Weight to be associated with the nodes that fit the criteria specified by this node row." ::= { ibmappnCosNodeRowEntry 3 } ibmappnCosNodeRowResistMin OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Minimum route addition resistance value for this node. Range of values is 0-255. The lower the value, the more desirable the node is for intermediate routing." ::= { ibmappnCosNodeRowEntry 4 } ibmappnCosNodeRowResistMax OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Maximum route addition resistance value for this node. Range of values is 0-255. The lower the value, the more desirable the node is for intermediate routing." ::= { ibmappnCosNodeRowEntry 5 } ibmappnCosNodeRowMinCongestAllow OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether low congestion will be tolerated. The minimum and maximum parameters will allow specifying either low-congested, high-congested, or either to be used." ::= { ibmappnCosNodeRowEntry 6 } ibmappnCosNodeRowMaxCongestAllow OBJECT-TYPE SYNTAX INTEGER {yes(1), no(2)} ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether high congestion will be tolerated. The minimum and maximum parameters McKenzie & Cheng [Page 112] RFC 1593 SNA APPN Node MIB March 1994 will allow specifying either low-congested, high-congested, or either to be used." ::= { ibmappnCosNodeRowEntry 7 } -- COS TG row table -- Index -- TG Row Weight -- Effective capacity (min) -- Effective capacity (max) -- Cost per conn time (min) -- Cost per conn time (max) -- cost per byte (min) -- cost per byte (max) -- Security (min) -- Security (max) -- Propagation delay (min) -- Propagation delay (max) -- User defined 1 (min) -- User defined 1 (max) -- User defined 2 (min) -- User defined 2 (max) -- User defined 3 (min) -- User defined 3 (max) -- ibmappnCosTgRowTable OBJECT-TYPE SYNTAX SEQUENCE OF IbmappnCosTgRowEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing all the Tg-row information for all class of service defined in this node." ::= { ibmappnCos 4 } ibmappnCosTgRowEntry OBJECT-TYPE SYNTAX IbmappnCosTgRowEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The TgRowName and the TgRowIndex are the index for this table." INDEX {ibmappnCosTgRowName, ibmappnCosTgRowIndex} McKenzie & Cheng [Page 113] RFC 1593 SNA APPN Node MIB March 1994 ::= { ibmappnCosTgRowTable 1 } IbmappnCosTgRowEntry ::= SEQUENCE { ibmappnCosTgRowName DisplayString, ibmappnCosTgRowIndex INTEGER, --TG Row Group ibmappnCosTgRowWgt DisplayString, ibmappnCosTgRowEffCapMin INTEGER, ibmappnCosTgRowEffCapMax INTEGER, ibmappnCosTgRowConnCostMin INTEGER, ibmappnCosTgRowConnCostMax INTEGER, ibmappnCosTgRowByteCostMin INTEGER, ibmappnCosTgRowByteCostMax INTEGER, ibmappnCosTgRowSecurityMin INTEGER, ibmappnCosTgRowSecurityMax INTEGER, ibmappnCosTgRowDelayMin INTEGER, ibmappnCosTgRowDelayMax INTEGER, ibmappnCosTgRowUsr1Min INTEGER, ibmappnCosTgRowUsr1Max INTEGER, ibmappnCosTgRowUsr2Min INTEGER, ibmappnCosTgRowUsr2Max INTEGER, ibmappnCosTgRowUsr3Min INTEGER, ibmappnCosTgRowUsr3Max INTEGER } ibmappnCosTgRowName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) ACCESS read-only STATUS mandatory DESCRIPTION "Administratively-assigned name for this class of service." ::= { ibmappnCosTgRowEntry 1 } ibmappnCosTgRowIndex OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Index of COS name. This same value is used to access the node and TG COS tables." ::= { ibmappnCosTgRowEntry 2 } --TG Row ibmappnCosTgRowWgt OBJECT-TYPE McKenzie & Cheng [Page 114] RFC 1593 SNA APPN Node MIB March 1994 SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Weight to be associated with the nodes that fit the criteria specified by this tg-row." ::= { ibmappnCosTgRowEntry 3 } ibmappnCosTgRowEffCapMin OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable speed for this Class of Service. The effective capacity is an integer value that indicates the actual kilo bits per second. It is derived from the link bandwidth and maximum load factor with the range of 0 thru 603,979,776." ::= { ibmappnCosTgRowEntry 4 } ibmappnCosTgRowEffCapMax OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Maximum acceptable speed for this Class of Service. The effective capacity is an integer value that indicates the actual kilo bits per second. It is derived from the link bandwidth and maximum load factor with the range of 0 thru 603,979,776." ::= { ibmappnCosTgRowEntry 5 } ibmappnCosTgRowConnCostMin OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable cost per connect time for this Class of Service. Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255." ::= { ibmappnCosTgRowEntry 6 } McKenzie & Cheng [Page 115] RFC 1593 SNA APPN Node MIB March 1994 ibmappnCosTgRowConnCostMax OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Maximum acceptable cost per connect time for this Class of Service. Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255." ::= { ibmappnCosTgRowEntry 7 } ibmappnCosTgRowByteCostMin OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable cost per byte for this Class of Service." ::= { ibmappnCosTgRowEntry 8 } ibmappnCosTgRowByteCostMax OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Maximum acceptable cost per byte for this Class of Service." ::= { ibmappnCosTgRowEntry 9 } ibmappnCosTgRowSecurityMin OBJECT-TYPE SYNTAX INTEGER { nonsecure(1), --X'01' publicSwitchedNetwork(32), --X'20' undergroundCable(64), --X'40' secureConduit(96), --X'60' guardedConduit(128), --X'80' encrypted(160), --X'A0' guardedRadiation(192) --X'C0' } ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable security McKenzie & Cheng [Page 116] RFC 1593 SNA APPN Node MIB March 1994 for this Class of Service." ::= { ibmappnCosTgRowEntry 10 } ibmappnCosTgRowSecurityMax OBJECT-TYPE SYNTAX INTEGER { nonsecure(1), --X'01' publicSwitchedNetwork(32), --X'20' undergroundCable(64), --X'40' secureConduit(96), --X'60' guardedConduit(128), --X'80' encrypted(160), --X'A0' guardedRadiation(192) --X'C0' } ACCESS read-only STATUS mandatory DESCRIPTION "Maximum acceptable security for this Class of Service." ::= { ibmappnCosTgRowEntry 11 } ibmappnCosTgRowDelayMin OBJECT-TYPE SYNTAX INTEGER { minimum(0), --X'00' negligible(384), --X'4C' terrestrial(9216), --X'71' packet(147456), --X'91' long(294912), --X'99' maximum(2013265920) --X'FF' } ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable propagation delay for this class of service. Relative amount of time that it takes for a signal to travel the length of the logical link. This time is represented in micro seconds, with the more values enumerated." ::= { ibmappnCosTgRowEntry 12 } ibmappnCosTgRowDelayMax OBJECT-TYPE SYNTAX INTEGER { minimum(0), --X'00' negligible(384), --X'4C' terrestrial(9216), --X'71' packet(147456), --X'91' long(294912), --X'99' McKenzie & Cheng [Page 117] RFC 1593 SNA APPN Node MIB March 1994 maximum(2013265920) --X'FF' } ACCESS read-only STATUS mandatory DESCRIPTION "Maximum acceptable propagation delay for this class of service. Relative amount of time that it takes for a signal to travel the length of the logical link. This time is represented in micro seconds, with the more values enumerated." ::= { ibmappnCosTgRowEntry 13 } ibmappnCosTgRowUsr1Min OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable value for this user defined characteristic. Range of values is 0-255." ::= { ibmappnCosTgRowEntry 14 } ibmappnCosTgRowUsr1Max OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Maximum acceptable value for this user defined characteristic. Range of values is 0-255." ::= { ibmappnCosTgRowEntry 15 } ibmappnCosTgRowUsr2Min OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable value for this user defined characteristic. Range of values is 0-255." ::= { ibmappnCosTgRowEntry 16 } ibmappnCosTgRowUsr2Max OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only McKenzie & Cheng [Page 118] RFC 1593 SNA APPN Node MIB March 1994 STATUS mandatory DESCRIPTION "A Maximum acceptable value for this user defined characteristic." ::= { ibmappnCosTgRowEntry 17 } ibmappnCosTgRowUsr3Min OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Minimum acceptable value for this user defined characteristic. Range of values is 0-255." ::= { ibmappnCosTgRowEntry 18 } ibmappnCosTgRowUsr3Max OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Maximum acceptable value for this user defined characteristic. Range of values is 0-255." ::= { ibmappnCosTgRowEntry 19 } END 3.0 Acknowledgements Thanks go to David Chen, Leo Temoshenko, and Mike Allen for their contribution and support through the development process. 4.0 Security Considerations Security issues are not discussed in this memo. McKenzie & Cheng [Page 119] RFC 1593 SNA APPN Node MIB March 1994 5.0 Authors' Addresses William F. McKenzie IBM Networking Systems P. O. Box 12195 Research Triangle Park, NC 27709 US Phone: +1 919 254 5705 EMail: mckenzie@ralvma.vnet.ibm.com Jia-bing R. Cheng IBM Networking Systems P. O. Box 12195 Research Triangle Park, NC 27709 US Phone: +1 919 254 4434 EMail: cheng@ralvm6.vnet.ibm.com McKenzie & Cheng [Page 120] snmp-mibs-downloader-1.1/mibrfcs/rfc1611.txt0000644000000000000000000016251411402176071015563 0ustar Network Working Group R. Austein Request for Comments: 1611 Epilogue Technology Corporation Category: Standards Track J. Saperia Digital Equipment Corporation May 1994 DNS Server MIB Extensions 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 .............................................. 1 2. The SNMPv2 Network Management Framework ................... 2 2.1 Object Definitions ....................................... 2 3. Overview .................................................. 2 3.1 Resolvers ................................................ 3 3.2 Name Servers ............................................. 3 3.3 Selected Objects ......................................... 4 3.4 Textual Conventions ...................................... 4 4. Definitions ............................................... 5 5. Acknowledgements .......................................... 28 6. References ................................................ 28 7. Security Considerations ................................... 29 8. Authors' Addresses ........................................ 30 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. With the adoption of the Internet-standard Network Management Framework [4,5,6,7], and with a large number of vendor implementations of these standards in commercially available products, it became possible to provide a higher level of effective network management in TCP/IP-based internets than was previously available. With the growth in the use of these standards, it has become possible to consider the management of other elements of the infrastructure beyond the basic TCP/IP protocols. A key element of Austein & Saperia [Page 1] RFC 1611 DNS Server MIB Extensions May 1994 the TCP/IP infrastructure is the DNS. Up to this point there has been no mechanism to integrate the management of the DNS with SNMP-based managers. This memo provides the mechanisms by which IP-based management stations can effectively manage DNS name server software in an integrated fashion. We have defined DNS MIB objects to be used in conjunction with the Internet MIB to allow access to and control of DNS name server software via SNMP by the Internet community. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. 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 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 In theory, the DNS world is pretty simple. There are two kinds of entities: resolvers and name servers. Resolvers ask questions. Name servers answer them. The real world, however, is not so simple. Austein & Saperia [Page 2] RFC 1611 DNS Server MIB Extensions May 1994 Implementors have made widely differing choices about how to divide DNS functions between resolvers and servers. They have also constructed various sorts of exotic hybrids. The most difficult task in defining this MIB was to accommodate this wide range of entities without having to come up with a separate MIB for each. We divided up the various DNS functions into two, non-overlapping classes, called "resolver functions" and "name server functions." A DNS entity that performs what we define as resolver functions contains a resolver, and therefore must implement the MIB groups required of all resolvers which are defined in a separate MIB Module. A DNS entity which implements name server functions is considered to be a name server, and must implement the MIB groups required for name servers in this module. If the same piece of software performs both resolver and server functions, we imagine that it contains both a resolver and a server and would thus implement both the DNS Server and DNS Resolver MIBs. 3.1. Resolvers In our model, a resolver is a program (or piece thereof) which obtains resource records from servers. Normally it does so at the behest of an application, but may also do so as part of its own operation. A resolver sends DNS protocol queries and receives DNS protocol replies. A resolver neither receives queries nor sends replies. A full service resolver is one that knows how to resolve queries: it obtains the needed resource records by contacting a server authoritative for the records desired. A stub resolver does not know how to resolve queries: it sends all queries to a local name server, setting the "recursion desired" flag to indicate that it hopes that the name server will be willing to resolve the query. A resolver may (optionally) have a cache for remembering previously acquired resource records. It may also have a negative cache for remembering names or data that have been determined not to exist. 3.2. Name Servers A name server is a program (or piece thereof) that provides resource records to resolvers. All references in this document to "a name server" imply "the name server's role"; in some cases the name server's role and the resolver's role might be combined into a single program. A name server receives DNS protocol queries and sends DNS protocol replies. A name server neither sends queries nor receives replies. As a consequence, name servers do not have caches. Normally, a name server would expect to receive only those queries to which it could respond with authoritative information. However, if a name server receives a query that it cannot respond to with purely authoritative information, it may choose to try to obtain the Austein & Saperia [Page 3] RFC 1611 DNS Server MIB Extensions May 1994 necessary additional information from a resolver which may or may not be a separate process. 3.3. Selected Objects Many of the objects included in this memo have been created from information contained in the DNS specifications [1,2], as amended and clarified by subsequent host requirements documents [3]. Other objects have been created based on experience with existing DNS management tools, expected operational needs, the statistics generated by existing DNS implementations, and the configuration files used by existing DNS implementations. These objects have been ordered into groups as follows: o Server Configuration Group o Server Counter Group o Server Optional Counter Group o Server Zone Group This information has been converted into a standard form using the SNMPv2 SMI defined in [9]. For the most part, the descriptions are influenced by the DNS related RFCs noted above. For example, the descriptions for counters used for the various types of queries of DNS records are influenced by the definitions used for the various record types found in [2]. 3.4. Textual Conventions Several conceptual data types have been introduced as a textual conventions in this DNS MIB document. These additions will facilitate the common understanding of information used by the DNS. No changes to the SMI or the SNMP are necessary to support these conventions. Readers familiar with MIBs designed to manage entities in the lower layers of the Internet protocol suite may be surprised at the number of non-enumerated integers used in this MIB to represent values such as DNS RR class and type numbers. The reason for this choice is simple: the DNS itself is designed as an extensible protocol, allowing new classes and types of resource records to be added to the protocol without recoding the core DNS software. Using non- enumerated integers to represent these data types in this MIB allows the MIB to accommodate these changes as well. Austein & Saperia [Page 4] RFC 1611 DNS Server MIB Extensions May 1994 4. Definitions DNS-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS mib-2 FROM RFC-1213 MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, IpAddress, Counter32, Gauge32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; dns OBJECT-IDENTITY STATUS current DESCRIPTION "The OID assigned to DNS MIB work by the IANA." ::= { mib-2 32 } dnsServMIB MODULE-IDENTITY LAST-UPDATED "9401282251Z" ORGANIZATION "IETF DNS Working Group" CONTACT-INFO " Rob Austein Postal: Epilogue Technology Corporation 268 Main Street, Suite 283 North Reading, MA 10864 US Tel: +1 617 245 0804 Fax: +1 617 245 8122 E-Mail: sra@epilogue.com Jon Saperia Postal: Digital Equipment Corporation 110 Spit Brook Road ZKO1-3/H18 Nashua, NH 03062-2698 US Tel: +1 603 881 0480 Fax: +1 603 881 0120 Email: saperia@zko.dec.com" DESCRIPTION "The MIB module for entities implementing the server side of the Domain Name System (DNS) protocol." ::= { dns 1 } Austein & Saperia [Page 5] RFC 1611 DNS Server MIB Extensions May 1994 dnsServMIBObjects OBJECT IDENTIFIER ::= { dnsServMIB 1 } -- (Old-style) groups in the DNS server MIB. dnsServConfig OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 } dnsServCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 } dnsServOptCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 } dnsServZone OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 } -- Textual conventions DnsName ::= TEXTUAL-CONVENTION -- A DISPLAY-HINT would be nice, but difficult to express. STATUS current DESCRIPTION "A DNS name is a sequence of labels. When DNS names are displayed, the boundaries between labels are typically indicated by dots (e.g. `Acme' and `COM' are labels in the name `Acme.COM'). In the DNS protocol, however, no such separators are needed because each label is encoded as a length octet followed by the indicated number of octets of label. For example, `Acme.COM' is encoded as the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O', 'M', 0 } (the final 0 is the length of the name of the root domain, which appears implicitly at the end of any DNS name). This MIB uses the same encoding as the DNS protocol. A DnsName must always be a fully qualified name. It is an error to encode a relative domain name as a DnsName without first making it a fully qualified name." REFERENCE "RFC-1034 section 3.1." SYNTAX OCTET STRING (SIZE (0..255)) DnsNameAsIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention is like a DnsName, but is used as an index componant in tables. Alphabetic characters in names of this type are restricted to uppercase: the characters 'a' through 'z' are mapped to the characters 'A' through 'Z'. This restriction is intended to make the lexical ordering imposed by SNMP useful when applied to DNS names. Note that it is theoretically possible for a valid DNS Austein & Saperia [Page 6] RFC 1611 DNS Server MIB Extensions May 1994 name to exceed the allowed length of an SNMP object identifer, and thus be impossible to represent in tables in this MIB that are indexed by DNS name. Sampling of DNS names in current use on the Internet suggests that this limit does not pose a serious problem in practice." REFERENCE "RFC-1034 section 3.1, RFC-1448 section 4.1." SYNTAX DnsName DnsClass ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d" STATUS current DESCRIPTION "This data type is used to represent the class values which appear in Resource Records in the DNS. A 16-bit unsigned integer is used to allow room for new classes of records to be defined. Existing standard classes are listed in the DNS specifications." REFERENCE "RFC-1035 section 3.2.4." SYNTAX INTEGER (0..65535) DnsType ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d" STATUS current DESCRIPTION "This data type is used to represent the type values which appear in Resource Records in the DNS. A 16-bit unsigned integer is used to allow room for new record types to be defined. Existing standard types are listed in the DNS specifications." REFERENCE "RFC-1035 section 3.2.2." SYNTAX INTEGER (0..65535) DnsQClass ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d" STATUS current DESCRIPTION "This data type is used to represent the QClass values which appear in Resource Records in the DNS. A 16-bit unsigned integer is used to allow room for new QClass records to be defined. Existing standard QClasses are listed in the DNS specification." REFERENCE "RFC-1035 section 3.2.5." SYNTAX INTEGER (0..65535) Austein & Saperia [Page 7] RFC 1611 DNS Server MIB Extensions May 1994 DnsQType ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d" STATUS current DESCRIPTION "This data type is used to represent the QType values which appear in Resource Records in the DNS. A 16-bit unsigned integer is used to allow room for new QType records to be defined. Existing standard QTypes are listed in the DNS specification." REFERENCE "RFC-1035 section 3.2.3." SYNTAX INTEGER (0..65535) DnsTime ::= TEXTUAL-CONVENTION DISPLAY-HINT "4d" STATUS current DESCRIPTION "DnsTime values are 32-bit unsigned integers which measure time in seconds." REFERENCE "RFC-1035." SYNTAX Gauge32 DnsOpCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention is used to represent the DNS OPCODE values used in the header section of DNS messages. Existing standard OPCODE values are listed in the DNS specifications." REFERENCE "RFC-1035 section 4.1.1." SYNTAX INTEGER (0..15) DnsRespCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to represent the DNS RCODE value in DNS response messages. Existing standard RCODE values are listed in the DNS specifications." REFERENCE "RFC-1035 section 4.1.1." SYNTAX INTEGER (0..15) Austein & Saperia [Page 8] RFC 1611 DNS Server MIB Extensions May 1994 -- Server Configuration Group dnsServConfigImplementIdent OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The implementation identification string for the DNS server software in use on the system, for example; `FNS-2.1'" ::= { dnsServConfig 1 } dnsServConfigRecurs OBJECT-TYPE SYNTAX INTEGER { available(1), restricted(2), unavailable(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This represents the recursion services offered by this name server. The values that can be read or written are: available(1) - performs recursion on requests from clients. restricted(2) - recursion is performed on requests only from certain clients, for example; clients on an access control list. unavailable(3) - recursion is not available." ::= { dnsServConfig 2 } dnsServConfigUpTime OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the server has a persistent state (e.g., a process), this value will be the time elapsed since it started. For software without persistant state, this value will be zero." ::= { dnsServConfig 3 } dnsServConfigResetTime OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current Austein & Saperia [Page 9] RFC 1611 DNS Server MIB Extensions May 1994 DESCRIPTION "If the server has a persistent state (e.g., a process) and supports a `reset' operation (e.g., can be told to re-read configuration files), this value will be the time elapsed since the last time the name server was `reset.' For software that does not have persistence or does not support a `reset' operation, this value will be zero." ::= { dnsServConfig 4 } dnsServConfigReset OBJECT-TYPE SYNTAX INTEGER { other(1), reset(2), initializing(3), running(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Status/action object to reinitialize any persistant name server state. When set to reset(2), any persistant name server state (such as a process) is reinitialized as if the name server had just been started. This value will never be returned by a read operation. When read, one of the following values will be returned: other(1) - server in some unknown state; initializing(3) - server (re)initializing; running(4) - server currently running." ::= { dnsServConfig 5 } -- Server Counter Group dnsServCounterAuthAns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries which were authoritatively answered." ::= { dnsServCounter 2 } dnsServCounterAuthNoNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries for which `authoritative no such name' responses were made." ::= { dnsServCounter 3 } Austein & Saperia [Page 10] RFC 1611 DNS Server MIB Extensions May 1994 dnsServCounterAuthNoDataResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries for which `authoritative no such data' (empty answer) responses were made." ::= { dnsServCounter 4 } dnsServCounterNonAuthDatas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries which were non-authoritatively answered (cached data)." ::= { dnsServCounter 5 } dnsServCounterNonAuthNoDatas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries which were non-authoritatively answered with no data (empty answer)." ::= { dnsServCounter 6 } dnsServCounterReferrals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests that were referred to other servers." ::= { dnsServCounter 7 } dnsServCounterErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed that were answered with errors (RCODE values other than 0 and 3)." REFERENCE "RFC-1035 section 4.1.1." ::= { dnsServCounter 8 } dnsServCounterRelNames OBJECT-TYPE SYNTAX Counter32 Austein & Saperia [Page 11] RFC 1611 DNS Server MIB Extensions May 1994 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests received by the server for names that are only 1 label long (text form - no internal dots)." ::= { dnsServCounter 9 } dnsServCounterReqRefusals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of DNS requests refused by the server." ::= { dnsServCounter 10 } dnsServCounterReqUnparses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests received which were unparseable." ::= { dnsServCounter 11 } dnsServCounterOtherErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests which were aborted for other (local) server errors." ::= { dnsServCounter 12 } -- DNS Server Counter Table dnsServCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Counter information broken down by DNS class and type." ::= { dnsServCounter 13 } dnsServCounterEntry OBJECT-TYPE SYNTAX DnsServCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains count information for each DNS class Austein & Saperia [Page 12] RFC 1611 DNS Server MIB Extensions May 1994 and type value known to the server. The index allows management software to to create indices to the table to get the specific information desired, e.g., number of queries over UDP for records with type value `A' which came to this server. In order to prevent an uncontrolled expansion of rows in the table; if dnsServCounterRequests is 0 and dnsServCounterResponses is 0, then the row does not exist and `no such' is returned when the agent is queried for such instances." INDEX { dnsServCounterOpCode, dnsServCounterQClass, dnsServCounterQType, dnsServCounterTransport } ::= { dnsServCounterTable 1 } DnsServCounterEntry ::= SEQUENCE { dnsServCounterOpCode DnsOpCode, dnsServCounterQClass DnsClass, dnsServCounterQType DnsType, dnsServCounterTransport INTEGER, dnsServCounterRequests Counter32, dnsServCounterResponses Counter32 } dnsServCounterOpCode OBJECT-TYPE SYNTAX DnsOpCode MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DNS OPCODE being counted in this row of the table." ::= { dnsServCounterEntry 1 } dnsServCounterQClass OBJECT-TYPE SYNTAX DnsClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "The class of record being counted in this row of the table." ::= { dnsServCounterEntry 2 } Austein & Saperia [Page 13] RFC 1611 DNS Server MIB Extensions May 1994 dnsServCounterQType OBJECT-TYPE SYNTAX DnsType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of record which is being counted in this row in the table." ::= { dnsServCounterEntry 3 } dnsServCounterTransport OBJECT-TYPE SYNTAX INTEGER { udp(1), tcp(2), other(3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value of udp(1) indicates that the queries reported on this row were sent using UDP. A value of tcp(2) indicates that the queries reported on this row were sent using TCP. A value of other(3) indicates that the queries reported on this row were sent using a transport that was neither TCP nor UDP." ::= { dnsServCounterEntry 4 } dnsServCounterRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests (queries) that have been recorded in this row of the table." ::= { dnsServCounterEntry 5 } dnsServCounterResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses made by the server since initialization for the kind of query identified on this row of the table." ::= { dnsServCounterEntry 6 } Austein & Saperia [Page 14] RFC 1611 DNS Server MIB Extensions May 1994 -- Server Optional Counter Group -- The Server Optional Counter Group is intended for those systems -- which make distinctions between the different sources of the DNS -- queries as defined below. -- -- Objects in this group are implemented on servers which distinguish -- between queries which originate from the same host as the server, -- queries from one of an arbitrary group of hosts that are on an -- access list defined by the server, and queries from hosts that do -- not fit either of these descriptions. -- -- The objects found in the Server Counter group are totals. Thus if -- one wanted to identify, for example, the number of queries from -- `remote' hosts which have been given authoritative answers, one -- would subtract the current values of ServOptCounterFriendsAuthAns -- and ServOptCounterSelfAuthAns from servCounterAuthAns. -- -- The purpose of these distinctions is to allow for implementations -- to group queries and responses on this basis. One way in which -- servers may make these distinctions is by looking at the source IP -- address of the DNS query. If the source of the query is `your -- own' then the query should be counted as `yourself' (local host). -- If the source of the query matches an `access list,' the query -- came from a friend. What constitutes an `access list' is -- implementation dependent and could be as simple as a rule that all -- hosts on the same IP network as the DNS server are classed -- `friends.' -- -- In order to avoid double counting, the following rules apply: -- -- 1. No host is in more than one of the three groups defined above. -- -- 2. All queries from the local host are always counted in the -- `yourself' group regardless of what the access list, if any, -- says. -- -- 3. The access list should not define `your friends' in such a way -- that it includes all hosts. That is, not everybody is your -- `friend.' dnsServOptCounterSelfAuthAns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host for which Austein & Saperia [Page 15] RFC 1611 DNS Server MIB Extensions May 1994 there has been an authoritative answer." ::= { dnsServOptCounter 1 } dnsServOptCounterSelfAuthNoNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host for which there has been an authoritative no such name answer given." ::= { dnsServOptCounter 2 } dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host for which there has been an authoritative no such data answer (empty answer) made." ::= { dnsServOptCounter 3 } dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host for which a non-authoritative answer (cached data) was made." ::= { dnsServOptCounter 4 } dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host for which a `non-authoritative, no such data' response was made (empty answer)." ::= { dnsServOptCounter 5 } dnsServOptCounterSelfReferrals OBJECT-TYPE SYNTAX Counter32 Austein & Saperia [Page 16] RFC 1611 DNS Server MIB Extensions May 1994 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries the server has processed which originated from a resolver on the same host and were referred to other servers." ::= { dnsServOptCounter 6 } dnsServOptCounterSelfErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed which originated from a resolver on the same host which have been answered with errors (RCODEs other than 0 and 3)." REFERENCE "RFC-1035 section 4.1.1." ::= { dnsServOptCounter 7 } dnsServOptCounterSelfRelNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests received for names that are only 1 label long (text form - no internal dots) the server has processed which originated from a resolver on the same host." ::= { dnsServOptCounter 8 } dnsServOptCounterSelfReqRefusals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of DNS requests refused by the server which originated from a resolver on the same host." ::= { dnsServOptCounter 9 } dnsServOptCounterSelfReqUnparses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests received which were unparseable and which originated from a resolver on the same host." ::= { dnsServOptCounter 10 } Austein & Saperia [Page 17] RFC 1611 DNS Server MIB Extensions May 1994 dnsServOptCounterSelfOtherErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests which were aborted for other (local) server errors and which originated on the same host." ::= { dnsServOptCounter 11 } dnsServOptCounterFriendsAuthAns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries originating from friends which were authoritatively answered. The definition of friends is a locally defined matter." ::= { dnsServOptCounter 12 } dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries originating from friends, for which authoritative `no such name' responses were made. The definition of friends is a locally defined matter." ::= { dnsServOptCounter 13 } dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries originating from friends for which authoritative no such data (empty answer) responses were made. The definition of friends is a locally defined matter." ::= { dnsServOptCounter 14 } dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries originating from friends which were non-authoritatively answered (cached data). The definition of friends is a locally defined matter." Austein & Saperia [Page 18] RFC 1611 DNS Server MIB Extensions May 1994 ::= { dnsServOptCounter 15 } dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries originating from friends which were non-authoritatively answered with no such data (empty answer)." ::= { dnsServOptCounter 16 } dnsServOptCounterFriendsReferrals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests which originated from friends that were referred to other servers. The definition of friends is a locally defined matter." ::= { dnsServOptCounter 17 } dnsServOptCounterFriendsErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests the server has processed which originated from friends and were answered with errors (RCODE values other than 0 and 3). The definition of friends is a locally defined matter." REFERENCE "RFC-1035 section 4.1.1." ::= { dnsServOptCounter 18 } dnsServOptCounterFriendsRelNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests received for names from friends that are only 1 label long (text form - no internal dots) the server has processed." ::= { dnsServOptCounter 19 } dnsServOptCounterFriendsReqRefusals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Austein & Saperia [Page 19] RFC 1611 DNS Server MIB Extensions May 1994 STATUS current DESCRIPTION "Number of DNS requests refused by the server which were received from `friends'." ::= { dnsServOptCounter 20 } dnsServOptCounterFriendsReqUnparses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests received which were unparseable and which originated from `friends'." ::= { dnsServOptCounter 21 } dnsServOptCounterFriendsOtherErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests which were aborted for other (local) server errors and which originated from `friends'." ::= { dnsServOptCounter 22 } -- Server Zone Group -- DNS Management Zone Configuration Table -- This table contains zone configuration information. dnsServZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of zones for which this name server provides information. Each of the zones may be loaded from stable storage via an implementation-specific mechanism or may be obtained from another name server via a zone transfer. If name server doesn't load any zones, this table is empty." ::= { dnsServZone 1 } dnsServZoneEntry OBJECT-TYPE SYNTAX DnsServZoneEntry MAX-ACCESS not-accessible Austein & Saperia [Page 20] RFC 1611 DNS Server MIB Extensions May 1994 STATUS current DESCRIPTION "An entry in the name server zone table. New rows may be added either via SNMP or by the name server itself." INDEX { dnsServZoneName, dnsServZoneClass } ::= { dnsServZoneTable 1 } DnsServZoneEntry ::= SEQUENCE { dnsServZoneName DnsNameAsIndex, dnsServZoneClass DnsClass, dnsServZoneLastReloadSuccess DnsTime, dnsServZoneLastReloadAttempt DnsTime, dnsServZoneLastSourceAttempt IpAddress, dnsServZoneStatus RowStatus, dnsServZoneSerial Counter32, dnsServZoneCurrent TruthValue, dnsServZoneLastSourceSuccess IpAddress } dnsServZoneName OBJECT-TYPE SYNTAX DnsNameAsIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS name of the zone described by this row of the table. This is the owner name of the SOA RR that defines the top of the zone. This is name is in uppercase: characters 'a' through 'z' are mapped to 'A' through 'Z' in order to make the lexical ordering useful." ::= { dnsServZoneEntry 1 } dnsServZoneClass OBJECT-TYPE SYNTAX DnsClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS class of the RRs in this zone." Austein & Saperia [Page 21] RFC 1611 DNS Server MIB Extensions May 1994 ::= { dnsServZoneEntry 2 } dnsServZoneLastReloadSuccess OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "Elapsed time in seconds since last successful reload of this zone." ::= { dnsServZoneEntry 3 } dnsServZoneLastReloadAttempt OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "Elapsed time in seconds since last attempted reload of this zone." ::= { dnsServZoneEntry 4 } dnsServZoneLastSourceAttempt OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP address of host from which most recent zone transfer of this zone was attempted. This value should match the value of dnsServZoneSourceSuccess if the attempt was succcessful. If zone transfer has not been attempted within the memory of this name server, this value should be 0.0.0.0." ::= { dnsServZoneEntry 5 } dnsServZoneStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the information represented in this row of the table." ::= { dnsServZoneEntry 6 } dnsServZoneSerial OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Zone serial number (from the SOA RR) of the zone Austein & Saperia [Page 22] RFC 1611 DNS Server MIB Extensions May 1994 represented by this row of the table. If the zone has not been successfully loaded within the memory of this name server, the value of this variable is zero." ::= { dnsServZoneEntry 7 } dnsServZoneCurrent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the server's copy of the zone represented by this row of the table is currently valid. If the zone has never been successfully loaded or has expired since it was last succesfully loaded, this variable will have the value false(2), otherwise this variable will have the value true(1)." ::= { dnsServZoneEntry 8 } dnsServZoneLastSourceSuccess OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP address of host which was the source of the most recent successful zone transfer for this zone. If unknown (e.g., zone has never been successfully transfered) or irrelevant (e.g., zone was loaded from stable storage), this value should be 0.0.0.0." ::= { dnsServZoneEntry 9 } -- DNS Zone Source Table dnsServZoneSrcTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServZoneSrcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is a list of IP addresses from which the server will attempt to load zone information using DNS zone transfer operations. A reload may occur due to SNMP operations that create a row in dnsServZoneTable or a SET to object dnsServZoneReload. This table is only used when the zone is loaded via zone transfer." ::= { dnsServZone 2 } dnsServZoneSrcEntry OBJECT-TYPE SYNTAX DnsServZoneSrcEntry MAX-ACCESS not-accessible Austein & Saperia [Page 23] RFC 1611 DNS Server MIB Extensions May 1994 STATUS current DESCRIPTION "An entry in the name server zone source table." INDEX { dnsServZoneSrcName, dnsServZoneSrcClass, dnsServZoneSrcAddr } ::= { dnsServZoneSrcTable 1 } DnsServZoneSrcEntry ::= SEQUENCE { dnsServZoneSrcName DnsNameAsIndex, dnsServZoneSrcClass DnsClass, dnsServZoneSrcAddr IpAddress, dnsServZoneSrcStatus RowStatus } dnsServZoneSrcName OBJECT-TYPE SYNTAX DnsNameAsIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS name of the zone to which this entry applies." ::= { dnsServZoneSrcEntry 1 } dnsServZoneSrcClass OBJECT-TYPE SYNTAX DnsClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS class of zone to which this entry applies." ::= { dnsServZoneSrcEntry 2 } dnsServZoneSrcAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address of name server host from which this zone might be obtainable." ::= { dnsServZoneSrcEntry 3 } dnsServZoneSrcStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Austein & Saperia [Page 24] RFC 1611 DNS Server MIB Extensions May 1994 STATUS current DESCRIPTION "The status of the information represented in this row of the table." ::= { dnsServZoneSrcEntry 4 } -- SNMPv2 groups. dnsServMIBGroups OBJECT IDENTIFIER ::= { dnsServMIB 2 } dnsServConfigGroup OBJECT-GROUP OBJECTS { dnsServConfigImplementIdent, dnsServConfigRecurs, dnsServConfigUpTime, dnsServConfigResetTime, dnsServConfigReset } STATUS current DESCRIPTION "A collection of objects providing basic configuration control of a DNS name server." ::= { dnsServMIBGroups 1 } dnsServCounterGroup OBJECT-GROUP OBJECTS { dnsServCounterAuthAns, dnsServCounterAuthNoNames, dnsServCounterAuthNoDataResps, dnsServCounterNonAuthDatas, dnsServCounterNonAuthNoDatas, dnsServCounterReferrals, dnsServCounterErrors, dnsServCounterRelNames, dnsServCounterReqRefusals, dnsServCounterReqUnparses, dnsServCounterOtherErrors, dnsServCounterOpCode, dnsServCounterQClass, dnsServCounterQType, dnsServCounterTransport, dnsServCounterRequests, dnsServCounterResponses } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation of a DNS name server." ::= { dnsServMIBGroups 2 } Austein & Saperia [Page 25] RFC 1611 DNS Server MIB Extensions May 1994 dnsServOptCounterGroup OBJECT-GROUP OBJECTS { dnsServOptCounterSelfAuthAns, dnsServOptCounterSelfAuthNoNames, dnsServOptCounterSelfAuthNoDataResps, dnsServOptCounterSelfNonAuthDatas, dnsServOptCounterSelfNonAuthNoDatas, dnsServOptCounterSelfReferrals, dnsServOptCounterSelfErrors, dnsServOptCounterSelfRelNames, dnsServOptCounterSelfReqRefusals, dnsServOptCounterSelfReqUnparses, dnsServOptCounterSelfOtherErrors, dnsServOptCounterFriendsAuthAns, dnsServOptCounterFriendsAuthNoNames, dnsServOptCounterFriendsAuthNoDataResps, dnsServOptCounterFriendsNonAuthDatas, dnsServOptCounterFriendsNonAuthNoDatas, dnsServOptCounterFriendsReferrals, dnsServOptCounterFriendsErrors, dnsServOptCounterFriendsRelNames, dnsServOptCounterFriendsReqRefusals, dnsServOptCounterFriendsReqUnparses, dnsServOptCounterFriendsOtherErrors } STATUS current DESCRIPTION "A collection of objects providing extended instrumentation of a DNS name server." ::= { dnsServMIBGroups 3 } dnsServZoneGroup OBJECT-GROUP OBJECTS { dnsServZoneName, dnsServZoneClass, dnsServZoneLastReloadSuccess, dnsServZoneLastReloadAttempt, dnsServZoneLastSourceAttempt, dnsServZoneLastSourceSuccess, dnsServZoneStatus, dnsServZoneSerial, dnsServZoneCurrent, dnsServZoneSrcName, dnsServZoneSrcClass, dnsServZoneSrcAddr, dnsServZoneSrcStatus } STATUS current DESCRIPTION "A collection of objects providing configuration control of a DNS name server which loads authoritative zones." ::= { dnsServMIBGroups 4 } Austein & Saperia [Page 26] RFC 1611 DNS Server MIB Extensions May 1994 -- Compliances. dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 } dnsServMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents implementing the DNS name server MIB extensions." MODULE -- This MIB module MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup } GROUP dnsServOptCounterGroup DESCRIPTION "The server optional counter group is unconditionally optional." GROUP dnsServZoneGroup DESCRIPTION "The server zone group is mandatory for any name server that acts as an authoritative server for any DNS zone." OBJECT dnsServConfigRecurs MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsServConfigReset MIN-ACCESS read-only DESCRIPTION "This object need not be writable." ::= { dnsServMIBCompliances 1 } END Austein & Saperia [Page 27] RFC 1611 DNS Server MIB Extensions May 1994 5. Acknowledgements This document is the result of work undertaken the by DNS working group. The authors would particularly like to thank the following people for their contributions to this document: Philip Almquist, Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM). 6. References [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [2] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [3] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. [4] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [5] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [8] 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. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon Austein & Saperia [Page 28] RFC 1611 DNS Server MIB Extensions May 1994 University, April 1993. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [12] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [14] "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987. 7. Security Considerations Security issues are not discussed in this memo. Austein & Saperia [Page 29] RFC 1611 DNS Server MIB Extensions May 1994 8. Authors' Addresses Rob Austein Epilogue Technology Corporation 268 Main Street, Suite 283 North Reading, MA 01864 USA Phone: +1-617-245-0804 Fax: +1-617-245-8122 EMail: sra@epilogue.com Jon Saperia Digital Equipment Corporation 110 Spit Brook Road ZKO1-3/H18 Nashua, NH 03062-2698 USA Phone: +1-603-881-0480 Fax: +1-603-881-0120 EMail: saperia@zko.dec.com Austein & Saperia [Page 30] snmp-mibs-downloader-1.1/mibrfcs/rfc1612.txt0000644000000000000000000016770611402176071015574 0ustar Network Working Group R. Austein Request for Comments: 1612 Epilogue Technology Corporation Category: Standards Track J. Saperia Digital Equipment Corporation May 1994 DNS Resolver MIB Extensions 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 .............................................. 1 2. The SNMPv2 Network Management Framework ................... 2 2.1 Object Definitions ....................................... 2 3. Overview .................................................. 2 3.1 Resolvers ................................................ 3 3.2 Name Servers ............................................. 3 3.3 Selected Objects ......................................... 4 3.4 Textual Conventions ...................................... 4 4. Definitions ............................................... 5 5. Acknowledgements .......................................... 30 6. References ................................................ 30 7. Security Considerations ................................... 32 8. Authors' Addresses ........................................ 32 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. With the adoption of the Internet-standard Network Management Framework [4,5,6,7], and with a large number of vendor implementations of these standards in commercially available products, it became possible to provide a higher level of effective network management in TCP/IP-based internets than was previously available. With the growth in the use of these standards, it has become possible to consider the management of other elements of the infrastructure beyond the basic TCP/IP protocols. A key element of Austein & Saperia [Page 1] RFC 1612 DNS Resolver MIB May 1994 the TCP/IP infrastructure is the DNS. Up to this point there has been no mechanism to integrate the management of the DNS with SNMP-based managers. This memo provides the mechanisms by which IP-based management stations can effectively manage DNS resolver software in an integrated fashion. We have defined DNS MIB objects to be used in conjunction with the Internet MIB to allow access to and control of DNS resolver software via SNMP by the Internet community. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. 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 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 In theory, the DNS world is pretty simple. There are two kinds of entities: resolvers and name servers. Resolvers ask questions. Name servers answer them. The real world, however, is not so simple. Austein & Saperia [Page 2] RFC 1612 DNS Resolver MIB May 1994 Implementors have made widely differing choices about how to divide DNS functions between resolvers and servers. They have also constructed various sorts of exotic hybrids. The most difficult task in defining this MIB was to accommodate this wide range of entities without having to come up with a separate MIB for each. We divided up the various DNS functions into two, non-overlapping classes, called "resolver functions" and "name server functions." A DNS entity that performs what we define as resolver functions contains a resolver, and therefore must implement the MIB groups required of all resolvers which are defined in this module. Some resolvers also implement "optional" functions such as a cache, in which case they must also implement the cache group contained in this MIB. A DNS entity which implements name server functions is considered to be a name server, and must implement the MIB groups required for name servers which are defined in a separate module. If the same piece of software performs both resolver and server functions, we imagine that it contains both a resolver and a server and would thus implement both the DNS Server and DNS Resolver MIBs. 3.1. Resolvers In our model, a resolver is a program (or piece thereof) which obtains resource records from servers. Normally it does so at the behest of an application, but may also do so as part of its own operation. A resolver sends DNS protocol queries and receives DNS protocol replies. A resolver neither receives queries nor sends replies. A full service resolver is one that knows how to resolve queries: it obtains the needed resource records by contacting a server authoritative for the records desired. A stub resolver does not know how to resolve queries: it sends all queries to a local name server, setting the "recursion desired" flag to indicate that it hopes that the name server will be willing to resolve the query. A resolver may (optionally) have a cache for remembering previously acquired resource records. It may also have a negative cache for remembering names or data that have been determined not to exist. 3.2. Name Servers A name server is a program (or piece thereof) that provides resource records to resolvers. All references in this document to "a name server" imply "the name server's role"; in some cases the name server's role and the resolver's role might be combined into a single program. A name server receives DNS protocol queries and sends DNS protocol replies. A name server neither sends queries nor receives replies. As a consequence, name servers do not have caches. Normally, a name server would expect to receive only those queries to which it could respond with authoritative information. However, if a Austein & Saperia [Page 3] RFC 1612 DNS Resolver MIB May 1994 name server receives a query that it cannot respond to with purely authoritative information, it may choose to try to obtain the necessary additional information from a resolver which may or may not be a separate process. 3.3. Selected Objects Many of the objects included in this memo have been created from information contained in the DNS specifications [1,2], as amended and clarified by subsequent host requirements documents [3]. Other objects have been created based on experience with existing DNS management tools, expected operational needs, the statistics generated by existing DNS implementations, and the configuration files used by existing DNS implementations. These objects have been ordered into groups as follows: o Resolver Configuration Group o Resolver Counter Group o Resolver Lame Delegation Group o Resolver Cache Group o Resolver Negative Cache Group o Resolver Optional Counter Group This information has been converted into a standard form using the SNMPv2 SMI defined in [9]. For the most part, the descriptions are influenced by the DNS related RFCs noted above. For example, the descriptions for counters used for the various types of queries of DNS records are influenced by the definitions used for the various record types found in [2]. 3.4. Textual Conventions Several conceptual data types have been introduced as a textual conventions in the DNS Server MIB document and have been imported into this MIB module. These additions will facilitate the common understanding of information used by the DNS. No changes to the SMI or the SNMP are necessary to support these conventions. Readers familiar with MIBs designed to manage entities in the lower layers of the Internet protocol suite may be surprised at the number of non-enumerated integers used in this MIB to represent values such as DNS RR class and type numbers. The reason for this choice is simple: the DNS itself is designed as an extensible protocol, Austein & Saperia [Page 4] RFC 1612 DNS Resolver MIB May 1994 allowing new classes and types of resource records to be added to the protocol without recoding the core DNS software. Using non- enumerated integers to represent these data types in this MIB allows the MIB to accommodate these changes as well. 4. Definitions DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass, DnsQType, DnsTime, DnsOpCode, DnsRespCode FROM DNS-SERVER-MIB; -- DNS Resolver MIB dnsResMIB MODULE-IDENTITY LAST-UPDATED "9401282250Z" ORGANIZATION "IETF DNS Working Group" CONTACT-INFO " Rob Austein Postal: Epilogue Technology Corporation 268 Main Street, Suite 283 North Reading, MA 10864 US Tel: +1 617 245 0804 Fax: +1 617 245 8122 E-Mail: sra@epilogue.com Jon Saperia Postal: Digital Equipment Corporation 110 Spit Brook Road ZKO1-3/H18 Nashua, NH 03062-2698 US Tel: +1 603 881 0480 Fax: +1 603 881 0120 E-mail: saperia@zko.dec.com" DESCRIPTION "The MIB module for entities implementing the client (resolver) side of the Domain Name System (DNS) protocol." Austein & Saperia [Page 5] RFC 1612 DNS Resolver MIB May 1994 ::= { dns 2 } dnsResMIBObjects OBJECT IDENTIFIER ::= { dnsResMIB 1 } -- (Old-style) groups in the DNS resolver MIB. dnsResConfig OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 } dnsResCounter OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 } dnsResLameDelegation OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 } dnsResCache OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 } dnsResNCache OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 } dnsResOptCounter OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 } -- Resolver Configuration Group dnsResConfigImplementIdent OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The implementation identification string for the resolver software in use on the system, for example; `RES-2.1'" ::= { dnsResConfig 1 } dnsResConfigService OBJECT-TYPE SYNTAX INTEGER { recursiveOnly(1), iterativeOnly(2), recursiveAndIterative(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Kind of DNS resolution service provided: recursiveOnly(1) indicates a stub resolver. iterativeOnly(2) indicates a normal full service resolver. recursiveAndIterative(3) indicates a full-service resolver which performs a mix of recursive and iterative queries." ::= { dnsResConfig 2 } dnsResConfigMaxCnames OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-write Austein & Saperia [Page 6] RFC 1612 DNS Resolver MIB May 1994 STATUS current DESCRIPTION "Limit on how many CNAMEs the resolver should allow before deciding that there's a CNAME loop. Zero means that resolver has no explicit CNAME limit." REFERENCE "RFC-1035 section 7.1." ::= { dnsResConfig 3 } -- DNS Resolver Safety Belt Table dnsResConfigSbeltTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsResConfigSbeltEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of safety belt information used by the resolver when it hasn't got any better idea of where to send a query, such as when the resolver is booting or is a stub resolver." ::= { dnsResConfig 4 } dnsResConfigSbeltEntry OBJECT-TYPE SYNTAX DnsResConfigSbeltEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the resolver's Sbelt table. Rows may be created or deleted at any time by the DNS resolver and by SNMP SET requests. Whether the values changed via SNMP are saved in stable storage across `reset' operations is implementation-specific." INDEX { dnsResConfigSbeltAddr, dnsResConfigSbeltSubTree, dnsResConfigSbeltClass } ::= { dnsResConfigSbeltTable 1 } DnsResConfigSbeltEntry ::= SEQUENCE { dnsResConfigSbeltAddr IpAddress, dnsResConfigSbeltName DnsName, dnsResConfigSbeltRecursion INTEGER, dnsResConfigSbeltPref INTEGER, dnsResConfigSbeltSubTree Austein & Saperia [Page 7] RFC 1612 DNS Resolver MIB May 1994 DnsNameAsIndex, dnsResConfigSbeltClass DnsClass, dnsResConfigSbeltStatus RowStatus } dnsResConfigSbeltAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the Sbelt name server identified by this row of the table." ::= { dnsResConfigSbeltEntry 1 } dnsResConfigSbeltName OBJECT-TYPE SYNTAX DnsName MAX-ACCESS read-create STATUS current DESCRIPTION "The DNS name of a Sbelt nameserver identified by this row of the table. A zero-length string indicates that the name is not known by the resolver." ::= { dnsResConfigSbeltEntry 2 } dnsResConfigSbeltRecursion OBJECT-TYPE SYNTAX INTEGER { iterative(1), recursive(2), recursiveAndIterative(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Kind of queries resolver will be sending to the name server identified in this row of the table: iterative(1) indicates that resolver will be directing iterative queries to this name server (RD bit turned off). recursive(2) indicates that resolver will be directing recursive queries to this name server (RD bit turned on). recursiveAndIterative(3) indicates that the resolver will be directing both recursive and iterative queries to the server identified in this row of the table." ::= { dnsResConfigSbeltEntry 3 } Austein & Saperia [Page 8] RFC 1612 DNS Resolver MIB May 1994 dnsResConfigSbeltPref OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "This value identifies the preference for the name server identified in this row of the table. The lower the value, the more desirable the resolver considers this server." ::= { dnsResConfigSbeltEntry 4 } dnsResConfigSbeltSubTree OBJECT-TYPE SYNTAX DnsNameAsIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Queries sent to the name server identified by this row of the table are limited to those for names in the name subtree identified by this variable. If no such limitation applies, the value of this variable is the name of the root domain (a DNS name consisting of a single zero octet)." ::= { dnsResConfigSbeltEntry 5 } dnsResConfigSbeltClass OBJECT-TYPE SYNTAX DnsClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "The class of DNS queries that will be sent to the server identified by this row of the table." ::= { dnsResConfigSbeltEntry 6 } dnsResConfigSbeltStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Row status column for this row of the Sbelt table." ::= { dnsResConfigSbeltEntry 7 } dnsResConfigUpTime OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the resolver has a persistent state (e.g., a process), this value will be the time elapsed since it Austein & Saperia [Page 9] RFC 1612 DNS Resolver MIB May 1994 started. For software without persistant state, this value will be 0." ::= { dnsResConfig 5 } dnsResConfigResetTime OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the resolver has a persistent state (e.g., a process) and supports a `reset' operation (e.g., can be told to re-read configuration files), this value will be the time elapsed since the last time the resolver was `reset.' For software that does not have persistence or does not support a `reset' operation, this value will be zero." ::= { dnsResConfig 6 } dnsResConfigReset OBJECT-TYPE SYNTAX INTEGER { other(1), reset(2), initializing(3), running(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Status/action object to reinitialize any persistant resolver state. When set to reset(2), any persistant resolver state (such as a process) is reinitialized as if the resolver had just been started. This value will never be returned by a read operation. When read, one of the following values will be returned: other(1) - resolver in some unknown state; initializing(3) - resolver (re)initializing; running(4) - resolver currently running." ::= { dnsResConfig 7 } -- Resolver Counters Group -- Resolver Counter Table dnsResCounterByOpcodeTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsResCounterByOpcodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of the current count of resolver queries and Austein & Saperia [Page 10] RFC 1612 DNS Resolver MIB May 1994 answers." ::= { dnsResCounter 3 } dnsResCounterByOpcodeEntry OBJECT-TYPE SYNTAX DnsResCounterByOpcodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry in the resolver counter table. Entries are indexed by DNS OpCode." INDEX { dnsResCounterByOpcodeCode } ::= { dnsResCounterByOpcodeTable 1 } DnsResCounterByOpcodeEntry ::= SEQUENCE { dnsResCounterByOpcodeCode DnsOpCode, dnsResCounterByOpcodeQueries Counter32, dnsResCounterByOpcodeResponses Counter32 } dnsResCounterByOpcodeCode OBJECT-TYPE SYNTAX DnsOpCode MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index to this table. The OpCodes that have already been defined are found in RFC-1035." REFERENCE "RFC-1035 section 4.1.1." ::= { dnsResCounterByOpcodeEntry 1 } dnsResCounterByOpcodeQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of queries that have sent out by the resolver since initialization for the OpCode which is the index to this row of the table." ::= { dnsResCounterByOpcodeEntry 2 } dnsResCounterByOpcodeResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Austein & Saperia [Page 11] RFC 1612 DNS Resolver MIB May 1994 DESCRIPTION "Total number of responses that have been received by the resolver since initialization for the OpCode which is the index to this row of the table." ::= { dnsResCounterByOpcodeEntry 3 } -- Resolver Response Code Counter Table dnsResCounterByRcodeTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsResCounterByRcodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of the current count of responses to resolver queries." ::= { dnsResCounter 4 } dnsResCounterByRcodeEntry OBJECT-TYPE SYNTAX DnsResCounterByRcodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry in the resolver response table. Entries are indexed by DNS response code." INDEX { dnsResCounterByRcodeCode } ::= { dnsResCounterByRcodeTable 1 } DnsResCounterByRcodeEntry ::= SEQUENCE { dnsResCounterByRcodeCode DnsRespCode, dnsResCounterByRcodeResponses Counter32 } dnsResCounterByRcodeCode OBJECT-TYPE SYNTAX DnsRespCode MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index to this table. The Response Codes that have already been defined are found in RFC-1035." REFERENCE "RFC-1035 section 4.1.1." ::= { dnsResCounterByRcodeEntry 1 } Austein & Saperia [Page 12] RFC 1612 DNS Resolver MIB May 1994 dnsResCounterByRcodeResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses the resolver has received for the response code value which identifies this row of the table." ::= { dnsResCounterByRcodeEntry 2 } -- Additional DNS Resolver Counter Objects dnsResCounterNonAuthDataResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests made by the resolver for which a non-authoritative answer (cached data) was received." ::= { dnsResCounter 5 } dnsResCounterNonAuthNoDataResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests made by the resolver for which a non-authoritative answer - no such data response (empty answer) was received." ::= { dnsResCounter 6 } dnsResCounterMartians OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses received which were received from servers that the resolver does not think it asked." ::= { dnsResCounter 7 } dnsResCounterRecdResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses received to all queries." ::= { dnsResCounter 8 } Austein & Saperia [Page 13] RFC 1612 DNS Resolver MIB May 1994 dnsResCounterUnparseResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses received which were unparseable." ::= { dnsResCounter 9 } dnsResCounterFallbacks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the resolver had to fall back to its seat belt information." ::= { dnsResCounter 10 } -- Lame Delegation Group dnsResLameDelegationOverflows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the resolver attempted to add an entry to the Lame Delegation table but was unable to for some reason such as space constraints." ::= { dnsResLameDelegation 1 } -- Lame Delegation Table dnsResLameDelegationTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsResLameDelegationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of name servers returning lame delegations. A lame delegation has occured when a parent zone delegates authority for a child zone to a server that appears not to think that it is authoritative for the child zone in question." ::= { dnsResLameDelegation 2 } dnsResLameDelegationEntry OBJECT-TYPE SYNTAX DnsResLameDelegationEntry MAX-ACCESS not-accessible Austein & Saperia [Page 14] RFC 1612 DNS Resolver MIB May 1994 STATUS current DESCRIPTION "Entry in lame delegation table. Only the resolver may create rows in this table. SNMP SET requests may be used to delete rows." INDEX { dnsResLameDelegationSource, dnsResLameDelegationName, dnsResLameDelegationClass } ::= { dnsResLameDelegationTable 1 } DnsResLameDelegationEntry ::= SEQUENCE { dnsResLameDelegationSource IpAddress, dnsResLameDelegationName DnsNameAsIndex, dnsResLameDelegationClass DnsClass, dnsResLameDelegationCounts Counter32, dnsResLameDelegationStatus RowStatus } dnsResLameDelegationSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Source of lame delegation." ::= { dnsResLameDelegationEntry 1 } dnsResLameDelegationName OBJECT-TYPE SYNTAX DnsNameAsIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS name for which lame delegation was received." ::= { dnsResLameDelegationEntry 2 } dnsResLameDelegationClass OBJECT-TYPE SYNTAX DnsClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS class of received lame delegation." ::= { dnsResLameDelegationEntry 3 } Austein & Saperia [Page 15] RFC 1612 DNS Resolver MIB May 1994 dnsResLameDelegationCounts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "How many times this lame delegation has been received." ::= { dnsResLameDelegationEntry 4 } dnsResLameDelegationStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "Status column for the lame delegation table. Since only the agent (DNS resolver) creates rows in this table, the only values that a manager may write to this variable are active(1) and destroy(6)." ::= { dnsResLameDelegationEntry 5 } -- Resolver Cache Group dnsResCacheStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), clear(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Status/action for the resolver's cache. enabled(1) means that the use of the cache is allowed. Query operations can return this state. disabled(2) means that the cache is not being used. Query operations can return this state. Setting this variable to clear(3) deletes the entire contents of the resolver's cache, but does not otherwise change the resolver's state. The status will retain its previous value from before the clear operation (i.e., enabled(1) or disabled(2)). The value of clear(3) can NOT be returned by a query operation." ::= { dnsResCache 1 } dnsResCacheMaxTTL OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-write STATUS current DESCRIPTION Austein & Saperia [Page 16] RFC 1612 DNS Resolver MIB May 1994 "Maximum Time-To-Live for RRs in this cache. If the resolver does not implement a TTL ceiling, the value of this field should be zero." ::= { dnsResCache 2 } dnsResCacheGoodCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of RRs the resolver has cached successfully." ::= { dnsResCache 3 } dnsResCacheBadCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of RRs the resolver has refused to cache because they appear to be dangerous or irrelevant. E.g., RRs with suspiciously high TTLs, unsolicited root information, or that just don't appear to be relevant to the question the resolver asked." ::= { dnsResCache 4 } -- Resolver Cache Table dnsResCacheRRTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsResCacheRREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about all the resource records currently in the resolver's cache." ::= { dnsResCache 5 } dnsResCacheRREntry OBJECT-TYPE SYNTAX DnsResCacheRREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the resolvers's cache. Rows may be created only by the resolver. SNMP SET requests may be used to delete rows." INDEX { dnsResCacheRRName, dnsResCacheRRClass, dnsResCacheRRType, dnsResCacheRRIndex } Austein & Saperia [Page 17] RFC 1612 DNS Resolver MIB May 1994 ::= { dnsResCacheRRTable 1 } DnsResCacheRREntry ::= SEQUENCE { dnsResCacheRRName DnsNameAsIndex, dnsResCacheRRClass DnsClass, dnsResCacheRRType DnsType, dnsResCacheRRTTL DnsTime, dnsResCacheRRElapsedTTL DnsTime, dnsResCacheRRSource IpAddress, dnsResCacheRRData OCTET STRING, dnsResCacheRRStatus RowStatus, dnsResCacheRRIndex Integer32, dnsResCacheRRPrettyName DnsName } dnsResCacheRRName OBJECT-TYPE SYNTAX DnsNameAsIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Owner name of the Resource Record in the cache which is identified in this row of the table. As described in RFC-1034, the owner of the record is the domain name were the RR is found." REFERENCE "RFC-1034 section 3.6." ::= { dnsResCacheRREntry 1 } dnsResCacheRRClass OBJECT-TYPE SYNTAX DnsClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS class of the Resource Record in the cache which is identified in this row of the table." ::= { dnsResCacheRREntry 2 } Austein & Saperia [Page 18] RFC 1612 DNS Resolver MIB May 1994 dnsResCacheRRType OBJECT-TYPE SYNTAX DnsType MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS type of the Resource Record in the cache which is identified in this row of the table." ::= { dnsResCacheRREntry 3 } dnsResCacheRRTTL OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "Time-To-Live of RR in DNS cache. This is the initial TTL value which was received with the RR when it was originally received." ::= { dnsResCacheRREntry 4 } dnsResCacheRRElapsedTTL OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "Elapsed seconds since RR was received." ::= { dnsResCacheRREntry 5 } dnsResCacheRRSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Host from which RR was received, 0.0.0.0 if unknown." ::= { dnsResCacheRREntry 6 } dnsResCacheRRData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "RDATA portion of a cached RR. The value is in the format defined for the particular DNS class and type of the resource record." REFERENCE "RFC-1035 section 3.2.1." ::= { dnsResCacheRREntry 7 } Austein & Saperia [Page 19] RFC 1612 DNS Resolver MIB May 1994 dnsResCacheRRStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "Status column for the resolver cache table. Since only the agent (DNS resolver) creates rows in this table, the only values that a manager may write to this variable are active(1) and destroy(6)." ::= { dnsResCacheRREntry 8 } dnsResCacheRRIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value which makes entries in the table unique when the other index values (dnsResCacheRRName, dnsResCacheRRClass, and dnsResCacheRRType) do not provide a unique index." ::= { dnsResCacheRREntry 9 } dnsResCacheRRPrettyName OBJECT-TYPE SYNTAX DnsName MAX-ACCESS read-only STATUS current DESCRIPTION "Name of the RR at this row in the table. This is identical to the dnsResCacheRRName variable, except that character case is preserved in this variable, per DNS conventions." REFERENCE "RFC-1035 section 2.3.3." ::= { dnsResCacheRREntry 10 } -- Resolver Negative Cache Group dnsResNCacheStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), clear(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Status/action for the resolver's negative response cache. enabled(1) means that the use of the negative response cache is allowed. Query operations can return this state. Austein & Saperia [Page 20] RFC 1612 DNS Resolver MIB May 1994 disabled(2) means that the negative response cache is not being used. Query operations can return this state. Setting this variable to clear(3) deletes the entire contents of the resolver's negative response cache. The status will retain its previous value from before the clear operation (i.e., enabled(1) or disabled(2)). The value of clear(3) can NOT be returned by a query operation." ::= { dnsResNCache 1 } dnsResNCacheMaxTTL OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum Time-To-Live for cached authoritative errors. If the resolver does not implement a TTL ceiling, the value of this field should be zero." ::= { dnsResNCache 2 } dnsResNCacheGoodNCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of authoritative errors the resolver has cached successfully." ::= { dnsResNCache 3 } dnsResNCacheBadNCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of authoritative errors the resolver would have liked to cache but was unable to because the appropriate SOA RR was not supplied or looked suspicious." REFERENCE "RFC-1034 section 4.3.4." ::= { dnsResNCache 4 } -- Resolver Negative Cache Table dnsResNCacheErrTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsResNCacheErrEntry MAX-ACCESS not-accessible STATUS current Austein & Saperia [Page 21] RFC 1612 DNS Resolver MIB May 1994 DESCRIPTION "The resolver's negative response cache. This table contains information about authoritative errors that have been cached by the resolver." ::= { dnsResNCache 5 } dnsResNCacheErrEntry OBJECT-TYPE SYNTAX DnsResNCacheErrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the resolver's negative response cache table. Only the resolver can create rows. SNMP SET requests may be used to delete rows." INDEX { dnsResNCacheErrQName, dnsResNCacheErrQClass, dnsResNCacheErrQType, dnsResNCacheErrIndex } ::= { dnsResNCacheErrTable 1 } DnsResNCacheErrEntry ::= SEQUENCE { dnsResNCacheErrQName DnsNameAsIndex, dnsResNCacheErrQClass DnsQClass, dnsResNCacheErrQType DnsQType, dnsResNCacheErrTTL DnsTime, dnsResNCacheErrElapsedTTL DnsTime, dnsResNCacheErrSource IpAddress, dnsResNCacheErrCode INTEGER, dnsResNCacheErrStatus RowStatus, dnsResNCacheErrIndex Integer32, dnsResNCacheErrPrettyName DnsName } dnsResNCacheErrQName OBJECT-TYPE SYNTAX DnsNameAsIndex MAX-ACCESS not-accessible STATUS current Austein & Saperia [Page 22] RFC 1612 DNS Resolver MIB May 1994 DESCRIPTION "QNAME associated with a cached authoritative error." REFERENCE "RFC-1034 section 3.7.1." ::= { dnsResNCacheErrEntry 1 } dnsResNCacheErrQClass OBJECT-TYPE SYNTAX DnsQClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS QCLASS associated with a cached authoritative error." ::= { dnsResNCacheErrEntry 2 } dnsResNCacheErrQType OBJECT-TYPE SYNTAX DnsQType MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS QTYPE associated with a cached authoritative error." ::= { dnsResNCacheErrEntry 3 } dnsResNCacheErrTTL OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "Time-To-Live of a cached authoritative error at the time of the error, it should not be decremented by the number of seconds since it was received. This should be the TTL as copied from the MINIMUM field of the SOA that accompanied the authoritative error, or a smaller value if the resolver implements a ceiling on negative response cache TTLs." REFERENCE "RFC-1034 section 4.3.4." ::= { dnsResNCacheErrEntry 4 } dnsResNCacheErrElapsedTTL OBJECT-TYPE SYNTAX DnsTime MAX-ACCESS read-only STATUS current DESCRIPTION "Elapsed seconds since authoritative error was received." ::= { dnsResNCacheErrEntry 5 } Austein & Saperia [Page 23] RFC 1612 DNS Resolver MIB May 1994 dnsResNCacheErrSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Host which sent the authoritative error, 0.0.0.0 if unknown." ::= { dnsResNCacheErrEntry 6 } dnsResNCacheErrCode OBJECT-TYPE SYNTAX INTEGER { nonexistantName(1), noData(2), other(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The authoritative error that has been cached: nonexistantName(1) indicates an authoritative name error (RCODE = 3). noData(2) indicates an authoritative response with no error (RCODE = 0) and no relevant data. other(3) indicates some other cached authoritative error. At present, no such errors are known to exist." ::= { dnsResNCacheErrEntry 7 } dnsResNCacheErrStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "Status column for the resolver negative response cache table. Since only the agent (DNS resolver) creates rows in this table, the only values that a manager may write to this variable are active(1) and destroy(6)." ::= { dnsResNCacheErrEntry 8 } dnsResNCacheErrIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A value which makes entries in the table unique when the other index values (dnsResNCacheErrQName, dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not provide a unique index." ::= { dnsResNCacheErrEntry 9 } Austein & Saperia [Page 24] RFC 1612 DNS Resolver MIB May 1994 dnsResNCacheErrPrettyName OBJECT-TYPE SYNTAX DnsName MAX-ACCESS read-only STATUS current DESCRIPTION "QNAME associated with this row in the table. This is identical to the dnsResNCacheErrQName variable, except that character case is preserved in this variable, per DNS conventions." REFERENCE "RFC-1035 section 2.3.3." ::= { dnsResNCacheErrEntry 10 } -- Resolver Optional Counters Group dnsResOptCounterReferals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses which were received from servers redirecting query to another server." ::= { dnsResOptCounter 1 } dnsResOptCounterRetrans OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number requests retransmitted for all reasons." ::= { dnsResOptCounter 2 } dnsResOptCounterNoResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries that were retransmitted because of no response." ::= { dnsResOptCounter 3 } dnsResOptCounterRootRetrans OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of queries that were retransmitted that were to Austein & Saperia [Page 25] RFC 1612 DNS Resolver MIB May 1994 root servers." ::= { dnsResOptCounter 4 } dnsResOptCounterInternals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests internally generated by the resolver." ::= { dnsResOptCounter 5 } dnsResOptCounterInternalTimeOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of requests internally generated which timed out." ::= { dnsResOptCounter 6 } -- SNMPv2 groups. dnsResMIBGroups OBJECT IDENTIFIER ::= { dnsResMIB 2 } dnsResConfigGroup OBJECT-GROUP OBJECTS { dnsResConfigImplementIdent, dnsResConfigService, dnsResConfigMaxCnames, dnsResConfigSbeltAddr, dnsResConfigSbeltName, dnsResConfigSbeltRecursion, dnsResConfigSbeltPref, dnsResConfigSbeltSubTree, dnsResConfigSbeltClass, dnsResConfigSbeltStatus, dnsResConfigUpTime, dnsResConfigResetTime } STATUS current DESCRIPTION "A collection of objects providing basic configuration information for a DNS resolver implementation." ::= { dnsResMIBGroups 1 } dnsResCounterGroup OBJECT-GROUP OBJECTS { dnsResCounterByOpcodeCode, dnsResCounterByOpcodeQueries, Austein & Saperia [Page 26] RFC 1612 DNS Resolver MIB May 1994 dnsResCounterByOpcodeResponses, dnsResCounterByRcodeCode, dnsResCounterByRcodeResponses, dnsResCounterNonAuthDataResps, dnsResCounterNonAuthNoDataResps, dnsResCounterMartians, dnsResCounterRecdResponses, dnsResCounterUnparseResps, dnsResCounterFallbacks } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation of a DNS resolver implementation." ::= { dnsResMIBGroups 2 } dnsResLameDelegationGroup OBJECT-GROUP OBJECTS { dnsResLameDelegationOverflows, dnsResLameDelegationSource, dnsResLameDelegationName, dnsResLameDelegationClass, dnsResLameDelegationCounts, dnsResLameDelegationStatus } STATUS current DESCRIPTION "A collection of objects providing instrumentation of `lame delegation' failures." ::= { dnsResMIBGroups 3 } dnsResCacheGroup OBJECT-GROUP OBJECTS { dnsResCacheStatus, dnsResCacheMaxTTL, dnsResCacheGoodCaches, dnsResCacheBadCaches, dnsResCacheRRName, dnsResCacheRRClass, dnsResCacheRRType, dnsResCacheRRTTL, dnsResCacheRRElapsedTTL, dnsResCacheRRSource, dnsResCacheRRData, dnsResCacheRRStatus, dnsResCacheRRIndex, dnsResCacheRRPrettyName } STATUS current DESCRIPTION "A collection of objects providing access to and control of a DNS resolver's cache." Austein & Saperia [Page 27] RFC 1612 DNS Resolver MIB May 1994 ::= { dnsResMIBGroups 4 } dnsResNCacheGroup OBJECT-GROUP OBJECTS { dnsResNCacheStatus, dnsResNCacheMaxTTL, dnsResNCacheGoodNCaches, dnsResNCacheBadNCaches, dnsResNCacheErrQName, dnsResNCacheErrQClass, dnsResNCacheErrQType, dnsResNCacheErrTTL, dnsResNCacheErrElapsedTTL, dnsResNCacheErrSource, dnsResNCacheErrCode, dnsResNCacheErrStatus, dnsResNCacheErrIndex, dnsResNCacheErrPrettyName } STATUS current DESCRIPTION "A collection of objects providing access to and control of a DNS resolver's negative response cache." ::= { dnsResMIBGroups 5 } dnsResOptCounterGroup OBJECT-GROUP OBJECTS { dnsResOptCounterReferals, dnsResOptCounterRetrans, dnsResOptCounterNoResponses, dnsResOptCounterRootRetrans, dnsResOptCounterInternals, dnsResOptCounterInternalTimeOuts } STATUS current DESCRIPTION "A collection of objects providing further instrumentation applicable to many but not all DNS resolvers." ::= { dnsResMIBGroups 6 } -- Compliances. dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 } dnsResMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents implementing the DNS resolver MIB extensions." MODULE -- This MIB module Austein & Saperia [Page 28] RFC 1612 DNS Resolver MIB May 1994 MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup } GROUP dnsResCacheGroup DESCRIPTION "The resolver cache group is mandatory for resolvers that implement a cache." GROUP dnsResNCacheGroup DESCRIPTION "The resolver negative cache group is mandatory for resolvers that implement a negative response cache." GROUP dnsResLameDelegationGroup DESCRIPTION "The lame delegation group is unconditionally optional." GROUP dnsResOptCounterGroup DESCRIPTION "The optional counters group is unconditionally optional." OBJECT dnsResConfigMaxCnames MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsResConfigSbeltName MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsResConfigSbeltRecursion MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsResConfigSbeltPref MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsResConfigReset MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsResCacheStatus MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsResCacheMaxTTL MIN-ACCESS read-only DESCRIPTION "This object need not be writable." OBJECT dnsResNCacheStatus MIN-ACCESS read-only DESCRIPTION "This object need not be writable." Austein & Saperia [Page 29] RFC 1612 DNS Resolver MIB May 1994 OBJECT dnsResNCacheMaxTTL MIN-ACCESS read-only DESCRIPTION "This object need not be writable." ::= { dnsResMIBCompliances 1 } END 5. Acknowledgements This document is the result of work undertaken the by DNS working group. The authors would particularly like to thank the following people for their contributions to this document: Philip Almquist, Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM). 6. References [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [2] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [3] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. [4] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [5] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. Austein & Saperia [Page 30] RFC 1612 DNS Resolver MIB May 1994 [8] McCloghrie, K., and M. Rose, "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. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [12] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [14] "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987. Austein & Saperia [Page 31] RFC 1612 DNS Resolver MIB May 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Rob Austein Epilogue Technology Corporation 268 Main Street, Suite 283 North Reading, MA 01864 USA Phone: +1-617-245-0804 Fax: +1-617-245-8122 EMail: sra@epilogue.com Jon Saperia Digital Equipment Corporation 110 Spit Brook Road ZKO1-3/H18 Nashua, NH 03062-2698 USA Phone: +1-603-881-0480 Fax: +1-603-881-0120 EMail: saperia@zko.dec.com Austein & Saperia [Page 32] snmp-mibs-downloader-1.1/mibrfcs/rfc1628.txt0000644000000000000000000024275711402176071015603 0ustar Network Working Group J. Case, Editor Request for Comments: 1628 SNMP Research, Incorporated Category: Standards Track May 1994 UPS Management Information Base 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 .............................................. 1 2. The SNMPv2 Network Management Framework ................... 2 2.1 Object Definitions ....................................... 2 3. Overview .................................................. 2 4. Definitions ............................................... 3 4.1 The Device Identification Group........................... 4 4.2 The Battery Group ........................................ 5 4.3 The Input Group .......................................... 7 4.4 The Output Group ......................................... 9 4.5 The Bypass Group ......................................... 12 4.6 The Alarm Group .......................................... 13 4.7 The Test Group ........................................... 19 4.8 The Control Group ........................................ 23 4.9 The Configuration Group .................................. 26 5. Acknowledgements .......................................... 43 6. References ................................................ 44 7. Security Considerations ................................... 45 8. Author's Address .......................................... 45 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. Case [Page 1] RFC 1628 UPS MIB May 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. 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 This document defines the managed objects for Uninterruptible Power Supplies which are to be manageable via the Simple Network Management Protocol (SNMP). Case [Page 2] RFC 1628 UPS MIB May 1994 4. Definitions UPS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, OBJECT-IDENTITY, Counter32, Gauge32, Integer32 FROM SNMPv2-SMI DisplayString, TimeStamp, TimeInterval, TestAndIncr, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; upsMIB MODULE-IDENTITY LAST-UPDATED "9402230000Z" ORGANIZATION "IETF UPS MIB Working Group" CONTACT-INFO " Jeffrey D. Case Postal: SNMP Research, Incorporated 3001 Kimberlin Heights Road Knoxville, TN 37920 US Tel: +1 615 573 1434 Fax: +1 615 573 9197 E-mail: case@snmp.com" DESCRIPTION "The MIB module to describe Uninterruptible Power Supplies." ::= { mib-2 33 } PositiveInteger ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This data type is a non-zero and non-negative value." SYNTAX INTEGER (1..2147483647) NonNegativeInteger ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This data type is a non-negative value." SYNTAX INTEGER (0..2147483647) Case [Page 3] RFC 1628 UPS MIB May 1994 upsObjects OBJECT IDENTIFIER ::= { upsMIB 1 } -- -- The Device Identification group. -- All objects in this group except for upsIdentName and -- upsIdentAttachedDevices are set at device initialization -- and remain static. -- upsIdent OBJECT IDENTIFIER ::= { upsObjects 1 } upsIdentManufacturer OBJECT-TYPE SYNTAX DisplayString (SIZE (0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the UPS manufacturer." ::= { upsIdent 1 } upsIdentModel OBJECT-TYPE SYNTAX DisplayString (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The UPS Model designation." ::= { upsIdent 2 } upsIdentUPSSoftwareVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The UPS firmware/software version(s). This variable may or may not have the same value as upsIdentAgentSoftwareVersion in some implementations." ::= { upsIdent 3 } upsIdentAgentSoftwareVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The UPS agent software version. This variable may or may not have the same value as upsIdentUPSSoftwareVersion in some implementations." ::= { upsIdent 4 } Case [Page 4] RFC 1628 UPS MIB May 1994 upsIdentName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A string identifying the UPS. This object should be set by the administrator." ::= { upsIdent 5 } upsIdentAttachedDevices OBJECT-TYPE SYNTAX DisplayString (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "A string identifying the devices attached to the output(s) of the UPS. This object should be set by the administrator." ::= { upsIdent 6 } -- -- Battery Group -- upsBattery OBJECT IDENTIFIER ::= { upsObjects 2 } upsBatteryStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), batteryNormal(2), batteryLow(3), batteryDepleted(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The indication of the capacity remaining in the UPS system's batteries. A value of batteryNormal indicates that the remaining run-time is greater than upsConfigLowBattTime. A value of batteryLow indicates that the remaining battery run-time is less than or equal to upsConfigLowBattTime. A value of batteryDepleted indicates that the UPS will be unable to sustain the present load when and if the utility power is lost (including the possibility that the utility power is currently absent and the UPS is unable to sustain the output)." ::= { upsBattery 1 } Case [Page 5] RFC 1628 UPS MIB May 1994 upsSecondsOnBattery OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the unit is on battery power, the elapsed time since the UPS last switched to battery power, or the time since the network management subsystem was last restarted, whichever is less. Zero shall be returned if the unit is not on battery power." ::= { upsBattery 2 } upsEstimatedMinutesRemaining OBJECT-TYPE SYNTAX PositiveInteger UNITS "minutes" MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the time to battery charge depletion under the present load conditions if the utility power is off and remains off, or if it were to be lost and remain off." ::= { upsBattery 3 } upsEstimatedChargeRemaining OBJECT-TYPE SYNTAX INTEGER (0..100) UNITS "percent" MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the battery charge remaining expressed as a percent of full charge." ::= { upsBattery 4 } upsBatteryVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Volt DC" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present battery voltage." ::= { upsBattery 5 } upsBatteryCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 Amp DC" MAX-ACCESS read-only Case [Page 6] RFC 1628 UPS MIB May 1994 STATUS current DESCRIPTION "The present battery current." ::= { upsBattery 6 } upsBatteryTemperature OBJECT-TYPE SYNTAX Integer32 UNITS "degrees Centigrade" MAX-ACCESS read-only STATUS current DESCRIPTION "The ambient temperature at or near the UPS Battery casing." ::= { upsBattery 7 } -- -- Input Group -- upsInput OBJECT IDENTIFIER ::= { upsObjects 3 } upsInputLineBads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times the input entered an out-of-tolerance condition as defined by the manufacturer. This count is incremented by one each time the input transitions from zero out-of-tolerance lines to one or more input lines out-of-tolerance." ::= { upsInput 1 } upsInputNumLines OBJECT-TYPE SYNTAX NonNegativeInteger MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input lines utilized in this device. This variable indicates the number of rows in the input table." ::= { upsInput 2 } upsInputTable OBJECT-TYPE SYNTAX SEQUENCE OF UpsInputEntry MAX-ACCESS not-accessible Case [Page 7] RFC 1628 UPS MIB May 1994 STATUS current DESCRIPTION "A list of input table entries. The number of entries is given by the value of upsInputNumLines." ::= { upsInput 3 } upsInputEntry OBJECT-TYPE SYNTAX UpsInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular input line." INDEX { upsInputLineIndex } ::= { upsInputTable 1 } UpsInputEntry ::= SEQUENCE { upsInputLineIndex PositiveInteger, upsInputFrequency NonNegativeInteger, upsInputVoltage NonNegativeInteger, upsInputCurrent NonNegativeInteger, upsInputTruePower NonNegativeInteger } upsInputLineIndex OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The input line identifier." ::= { upsInputEntry 1 } upsInputFrequency OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "The present input frequency." ::= { upsInputEntry 2 } upsInputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present input voltage." Case [Page 8] RFC 1628 UPS MIB May 1994 ::= { upsInputEntry 3 } upsInputCurrent OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 RMS Amp" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present input current." ::= { upsInputEntry 4 } upsInputTruePower OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the present input true power." ::= { upsInputEntry 5 } -- -- The Output group. -- upsOutput OBJECT IDENTIFIER ::= { upsObjects 4 } upsOutputSource OBJECT-TYPE SYNTAX INTEGER { other(1), none(2), normal(3), bypass(4), battery(5), booster(6), reducer(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The present source of output power. The enumeration none(2) indicates that there is no source of output power (and therefore no output power), for example, the system has opened the output breaker." ::= { upsOutput 1 } upsOutputFrequency OBJECT-TYPE SYNTAX NonNegativeInteger Case [Page 9] RFC 1628 UPS MIB May 1994 UNITS "0.1 Hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output frequency." ::= { upsOutput 2 } upsOutputNumLines OBJECT-TYPE SYNTAX NonNegativeInteger MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output lines utilized in this device. This variable indicates the number of rows in the output table." ::= { upsOutput 3 } upsOutputTable OBJECT-TYPE SYNTAX SEQUENCE OF UpsOutputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of output table entries. The number of entries is given by the value of upsOutputNumLines." ::= { upsOutput 4 } upsOutputEntry OBJECT-TYPE SYNTAX UpsOutputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular output line." INDEX { upsOutputLineIndex } ::= { upsOutputTable 1 } UpsOutputEntry ::= SEQUENCE { upsOutputLineIndex PositiveInteger, upsOutputVoltage NonNegativeInteger, upsOutputCurrent NonNegativeInteger, upsOutputPower NonNegativeInteger, upsOutputPercentLoad INTEGER } upsOutputLineIndex OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current Case [Page 10] RFC 1628 UPS MIB May 1994 DESCRIPTION "The output line identifier." ::= { upsOutputEntry 1 } upsOutputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output voltage." ::= { upsOutputEntry 2 } upsOutputCurrent OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 RMS Amp" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output current." ::= { upsOutputEntry 3 } upsOutputPower OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present output true power." ::= { upsOutputEntry 4 } upsOutputPercentLoad OBJECT-TYPE SYNTAX INTEGER (0..200) UNITS "percent" MAX-ACCESS read-only STATUS current DESCRIPTION "The percentage of the UPS power capacity presently being used on this output line, i.e., the greater of the percent load of true power capacity and the percent load of VA." ::= { upsOutputEntry 5 } Case [Page 11] RFC 1628 UPS MIB May 1994 -- -- The Bypass group. -- upsBypass OBJECT IDENTIFIER ::= { upsObjects 5 } upsBypassFrequency OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "The present bypass frequency." ::= { upsBypass 1 } upsBypassNumLines OBJECT-TYPE SYNTAX NonNegativeInteger MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bypass lines utilized in this device. This entry indicates the number of rows in the bypass table." ::= { upsBypass 2 } upsBypassTable OBJECT-TYPE SYNTAX SEQUENCE OF UpsBypassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of bypass table entries. The number of entries is given by the value of upsBypassNumLines." ::= { upsBypass 3 } upsBypassEntry OBJECT-TYPE SYNTAX UpsBypassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a particular bypass input." INDEX { upsBypassLineIndex } ::= { upsBypassTable 1 } UpsBypassEntry ::= SEQUENCE { upsBypassLineIndex PositiveInteger, upsBypassVoltage NonNegativeInteger, upsBypassCurrent NonNegativeInteger, Case [Page 12] RFC 1628 UPS MIB May 1994 upsBypassPower NonNegativeInteger } upsBypassLineIndex OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The bypass line identifier." ::= { upsBypassEntry 1 } upsBypassVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present bypass voltage." ::= { upsBypassEntry 2 } upsBypassCurrent OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 RMS Amp" MAX-ACCESS read-only STATUS current DESCRIPTION "The present bypass current." ::= { upsBypassEntry 3 } upsBypassPower OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The present true power conveyed by the bypass." ::= { upsBypassEntry 4 } -- -- The Alarm group. -- upsAlarm OBJECT IDENTIFIER ::= { upsObjects 6 } upsAlarmsPresent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only Case [Page 13] RFC 1628 UPS MIB May 1994 STATUS current DESCRIPTION "The present number of active alarm conditions." ::= { upsAlarm 1 } upsAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF UpsAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of alarm table entries. The table contains zero, one, or many rows at any moment, depending upon the number of alarm conditions in effect. The table is initially empty at agent startup. The agent creates a row in the table each time a condition is detected and deletes that row when that condition no longer pertains. The agent creates the first row with upsAlarmId equal to 1, and increments the value of upsAlarmId each time a new row is created, wrapping to the first free value greater than or equal to 1 when the maximum value of upsAlarmId would otherwise be exceeded. Consequently, after multiple operations, the table may become sparse, e.g., containing entries for rows 95, 100, 101, and 203 and the entries should not be assumed to be in chronological order because upsAlarmId might have wrapped. Alarms are named by an AutonomousType (OBJECT IDENTIFIER), upsAlarmDescr, to allow a single table to reflect well known alarms plus alarms defined by a particular implementation, i.e., as documented in the private enterprise MIB definition for the device. No two rows will have the same value of upsAlarmDescr, since alarms define conditions. In order to meet this requirement, care should be taken in the definition of alarm conditions to insure that a system cannot enter the same condition multiple times simultaneously. The number of rows in the table at any given time is reflected by the value of upsAlarmsPresent." ::= { upsAlarm 2 } upsAlarmEntry OBJECT-TYPE SYNTAX UpsAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information applicable to a Case [Page 14] RFC 1628 UPS MIB May 1994 particular alarm." INDEX { upsAlarmId } ::= { upsAlarmTable 1 } UpsAlarmEntry ::= SEQUENCE { upsAlarmId PositiveInteger, upsAlarmDescr AutonomousType, upsAlarmTime TimeStamp } upsAlarmId OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for an alarm condition. This value must remain constant." ::= { upsAlarmEntry 1 } upsAlarmDescr OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to an alarm description object. The object referenced should not be accessible, but rather be used to provide a unique description of the alarm condition." ::= { upsAlarmEntry 2 } upsAlarmTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the alarm condition was detected. If the alarm condition was detected at the time of agent startup and presumably existed before agent startup, the value of upsAlarmTime shall equal 0." ::= { upsAlarmEntry 3 } -- -- Well known alarm conditions. -- upsWellKnownAlarms OBJECT IDENTIFIER ::= { upsAlarm 3 } Case [Page 15] RFC 1628 UPS MIB May 1994 upsAlarmBatteryBad OBJECT-IDENTITY STATUS current DESCRIPTION "One or more batteries have been determined to require replacement." ::= { upsWellKnownAlarms 1 } upsAlarmOnBattery OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS is drawing power from the batteries." ::= { upsWellKnownAlarms 2 } upsAlarmLowBattery OBJECT-IDENTITY STATUS current DESCRIPTION "The remaining battery run-time is less than or equal to upsConfigLowBattTime." ::= { upsWellKnownAlarms 3 } upsAlarmDepletedBattery OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS will be unable to sustain the present load when and if the utility power is lost." ::= { upsWellKnownAlarms 4 } upsAlarmTempBad OBJECT-IDENTITY STATUS current DESCRIPTION "A temperature is out of tolerance." ::= { upsWellKnownAlarms 5 } upsAlarmInputBad OBJECT-IDENTITY STATUS current DESCRIPTION "An input condition is out of tolerance." ::= { upsWellKnownAlarms 6 } upsAlarmOutputBad OBJECT-IDENTITY STATUS current DESCRIPTION "An output condition (other than OutputOverload) is out of tolerance." ::= { upsWellKnownAlarms 7 } upsAlarmOutputOverload OBJECT-IDENTITY Case [Page 16] RFC 1628 UPS MIB May 1994 STATUS current DESCRIPTION "The output load exceeds the UPS output capacity." ::= { upsWellKnownAlarms 8 } upsAlarmOnBypass OBJECT-IDENTITY STATUS current DESCRIPTION "The Bypass is presently engaged on the UPS." ::= { upsWellKnownAlarms 9 } upsAlarmBypassBad OBJECT-IDENTITY STATUS current DESCRIPTION "The Bypass is out of tolerance." ::= { upsWellKnownAlarms 10 } upsAlarmOutputOffAsRequested OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS has shutdown as requested, i.e., the output is off." ::= { upsWellKnownAlarms 11 } upsAlarmUpsOffAsRequested OBJECT-IDENTITY STATUS current DESCRIPTION "The entire UPS has shutdown as commanded." ::= { upsWellKnownAlarms 12 } upsAlarmChargerFailed OBJECT-IDENTITY STATUS current DESCRIPTION "An uncorrected problem has been detected within the UPS charger subsystem." ::= { upsWellKnownAlarms 13 } upsAlarmUpsOutputOff OBJECT-IDENTITY STATUS current DESCRIPTION "The output of the UPS is in the off state." ::= { upsWellKnownAlarms 14 } upsAlarmUpsSystemOff OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS system is in the off state." ::= { upsWellKnownAlarms 15 } Case [Page 17] RFC 1628 UPS MIB May 1994 upsAlarmFanFailure OBJECT-IDENTITY STATUS current DESCRIPTION "The failure of one or more fans in the UPS has been detected." ::= { upsWellKnownAlarms 16 } upsAlarmFuseFailure OBJECT-IDENTITY STATUS current DESCRIPTION "The failure of one or more fuses has been detected." ::= { upsWellKnownAlarms 17 } upsAlarmGeneralFault OBJECT-IDENTITY STATUS current DESCRIPTION "A general fault in the UPS has been detected." ::= { upsWellKnownAlarms 18 } upsAlarmDiagnosticTestFailed OBJECT-IDENTITY STATUS current DESCRIPTION "The result of the last diagnostic test indicates a failure." ::= { upsWellKnownAlarms 19 } upsAlarmCommunicationsLost OBJECT-IDENTITY STATUS current DESCRIPTION "A problem has been encountered in the communications between the agent and the UPS." ::= { upsWellKnownAlarms 20 } upsAlarmAwaitingPower OBJECT-IDENTITY STATUS current DESCRIPTION "The UPS output is off and the UPS is awaiting the return of input power." ::= { upsWellKnownAlarms 21 } upsAlarmShutdownPending OBJECT-IDENTITY STATUS current DESCRIPTION "A upsShutdownAfterDelay countdown is underway." ::= { upsWellKnownAlarms 22 } upsAlarmShutdownImminent OBJECT-IDENTITY STATUS current Case [Page 18] RFC 1628 UPS MIB May 1994 DESCRIPTION "The UPS will turn off power to the load in less than 5 seconds; this may be either a timed shutdown or a low battery shutdown." ::= { upsWellKnownAlarms 23 } upsAlarmTestInProgress OBJECT-IDENTITY STATUS current DESCRIPTION "A test is in progress, as initiated and indicated by the Test Group. Tests initiated via other implementation-specific mechanisms can indicate the presence of the testing in the alarm table, if desired, via a OBJECT-IDENTITY macro in the MIB document specific to that implementation and are outside the scope of this OBJECT-IDENTITY." ::= { upsWellKnownAlarms 24 } -- -- The Test Group -- upsTest OBJECT IDENTIFIER ::= { upsObjects 7 } upsTestId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The test is named by an OBJECT IDENTIFIER which allows a standard mechanism for the initiation of tests, including the well known tests identified in this document as well as those introduced by a particular implementation, i.e., as documented in the private enterprise MIB definition for the device. Setting this variable initiates the named test. Sets to this variable require the presence of upsTestSpinLock in the same SNMP message. The set request will be rejected with an appropriate error message if the requested test cannot be performed, including attempts to start a test when another test is already in progress. The status of the current or last test is maintained in upsTestResultsSummary. Tests in progress may be aborted by setting the upsTestId variable to Case [Page 19] RFC 1628 UPS MIB May 1994 upsTestAbortTestInProgress. Read operations return the value of the name of the test in progress if a test is in progress or the name of the last test performed if no test is in progress, unless no test has been run, in which case the well known value upsTestNoTestsInitiated is returned." ::= { upsTest 1 } -- see [6] for more information on the semantics of objects with -- syntax of TestAndIncr upsTestSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "A spin lock on the test subsystem. The spinlock is used as follows. Before starting a test, a manager-station should make sure that a test is not in progress as follows: try_again: get (upsTestSpinLock) while (upsTestResultsSummary == inProgress) { /* loop while a test is running for another manager */ short delay get (upsTestSpinLock) } lock_value = upsTestSpinLock /* no test in progress, start the test */ set (upsTestSpinLock = lock_value, upsTestId = requested_test) if (error_index == 1) { /* (upsTestSpinLock failed) */ /* if problem is not access control, then some other manager slipped in ahead of us */ goto try_again } if (error_index == 2) { /* (upsTestId) */ /* cannot perform the test */ give up } /* test started ok */ /* wait for test completion by polling Case [Page 20] RFC 1628 UPS MIB May 1994 upsTestResultsSummary */ get (upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail) while (upsTestResultsSummary == inProgress) { short delay get (upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail) } /* when test completes, retrieve any additional test results */ /* if upsTestSpinLock == lock_value + 1, then these are our test */ /* results (as opposed to another manager's */ The initial value of upsTestSpinLock at agent initialization shall be 1." ::= { upsTest 2 } upsTestResultsSummary OBJECT-TYPE SYNTAX INTEGER { donePass(1), doneWarning(2), doneError(3), aborted(4), inProgress(5), noTestsInitiated(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The results of the current or last UPS diagnostics test performed. The values for donePass(1), doneWarning(2), and doneError(3) indicate that the test completed either successfully, with a warning, or with an error, respectively. The value aborted(4) is returned for tests which are aborted by setting the value of upsTestId to upsTestAbortTestInProgress. Tests which have not yet concluded are indicated by inProgress(5). The value noTestsInitiated(6) indicates that no previous test results are available, such as is the case when no tests have been run since the last reinitialization of the network management subsystem and the system has no provision for non- volatile storage of test results." ::= { upsTest 3 } upsTestResultsDetail OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) Case [Page 21] RFC 1628 UPS MIB May 1994 MAX-ACCESS read-only STATUS current DESCRIPTION "Additional information about upsTestResultsSummary. If no additional information available, a zero length string is returned." ::= { upsTest 4 } upsTestStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the test in progress was initiated, or, if no test is in progress, the time the previous test was initiated. If the value of upsTestResultsSummary is noTestsInitiated(6), upsTestStartTime has the value 0." ::= { upsTest 5 } upsTestElapsedTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time, in TimeTicks, since the test in progress was initiated, or, if no test is in progress, the previous test took to complete. If the value of upsTestResultsSummary is noTestsInitiated(6), upsTestElapsedTime has the value 0." ::= { upsTest 6 } -- -- Well known tests. -- upsWellKnownTests OBJECT IDENTIFIER ::= { upsTest 7 } upsTestNoTestsInitiated OBJECT-IDENTITY STATUS current DESCRIPTION "No tests have been initiated and no test is in progress." ::= { upsWellKnownTests 1 } upsTestAbortTestInProgress OBJECT-IDENTITY STATUS current Case [Page 22] RFC 1628 UPS MIB May 1994 DESCRIPTION "The test in progress is to be aborted / the test in progress was aborted." ::= { upsWellKnownTests 2 } upsTestGeneralSystemsTest OBJECT-IDENTITY STATUS current DESCRIPTION "The manufacturer's standard test of UPS device systems." ::= { upsWellKnownTests 3 } upsTestQuickBatteryTest OBJECT-IDENTITY STATUS current DESCRIPTION "A test that is sufficient to determine if the battery needs replacement." ::= { upsWellKnownTests 4 } upsTestDeepBatteryCalibration OBJECT-IDENTITY STATUS current DESCRIPTION "The system is placed on battery to a discharge level, set by the manufacturer, sufficient to determine battery replacement and battery run-time with a high degree of confidence. WARNING: this test will leave the battery in a low charge state and will require time for recharging to a level sufficient to provide normal battery duration for the protected load." ::= { upsWellKnownTests 5 } -- -- The Control group. -- upsControl OBJECT IDENTIFIER ::= { upsObjects 8 } upsShutdownType OBJECT-TYPE SYNTAX INTEGER { output(1), system(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines the nature of the action to be taken at the time when the countdown of the Case [Page 23] RFC 1628 UPS MIB May 1994 upsShutdownAfterDelay and upsRebootWithDuration objects reaches zero. Setting this object to output(1) indicates that shutdown requests should cause only the output of the UPS to turn off. Setting this object to system(2) indicates that shutdown requests will cause the entire UPS system to turn off." ::= { upsControl 1 } upsShutdownAfterDelay OBJECT-TYPE SYNTAX INTEGER (-1..2147483648) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object will shutdown (i.e., turn off) either the UPS output or the UPS system (as determined by the value of upsShutdownType at the time of shutdown) after the indicated number of seconds, or less if the UPS batteries become depleted. Setting this object to 0 will cause the shutdown to occur immediately. Setting this object to -1 will abort the countdown. If the system is already in the desired state at the time the countdown reaches 0, then nothing will happen. That is, there is no additional action at that time if upsShutdownType = system and the system is already off. Similarly, there is no additional action at that time if upsShutdownType = output and the output is already off. When read, upsShutdownAfterDelay will return the number of seconds remaining until shutdown, or -1 if no shutdown countdown is in effect. On some systems, if the agent is restarted while a shutdown countdown is in effect, the countdown may be aborted. Sets to this object override any upsShutdownAfterDelay already in effect." ::= { upsControl 2 } upsStartupAfterDelay OBJECT-TYPE SYNTAX INTEGER (-1..2147483648) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object will start the output after the indicated number of seconds, including starting the UPS, if necessary. Setting this object to 0 will cause the startup to occur immediately. Setting this Case [Page 24] RFC 1628 UPS MIB May 1994 object to -1 will abort the countdown. If the output is already on at the time the countdown reaches 0, then nothing will happen. Sets to this object override the effect of any upsStartupAfterDelay countdown or upsRebootWithDuration countdown in progress. When read, upsStartupAfterDelay will return the number of seconds until startup, or -1 if no startup countdown is in effect. If the countdown expires during a utility failure, the startup shall not occur until the utility power is restored. On some systems, if the agent is restarted while a startup countdown is in effect, the countdown is aborted." ::= { upsControl 3 } upsRebootWithDuration OBJECT-TYPE SYNTAX INTEGER (-1..300) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object will immediately shutdown (i.e., turn off) either the UPS output or the UPS system (as determined by the value of upsShutdownType at the time of shutdown) for a period equal to the indicated number of seconds, after which time the output will be started, including starting the UPS, if necessary. If the number of seconds required to perform the request is greater than the requested duration, then the requested shutdown and startup cycle shall be performed in the minimum time possible, but in no case shall this require more than the requested duration plus 60 seconds. When read, upsRebootWithDuration shall return the number of seconds remaining in the countdown, or -1 if no countdown is in progress. If the startup should occur during a utility failure, the startup shall not occur until the utility power is restored." ::= { upsControl 4 } upsAutoRestart OBJECT-TYPE SYNTAX INTEGER { on(1), off(2) } MAX-ACCESS read-write STATUS current DESCRIPTION Case [Page 25] RFC 1628 UPS MIB May 1994 "Setting this object to 'on' will cause the UPS system to restart after a shutdown if the shutdown occurred during a power loss as a result of either a upsShutdownAfterDelay or an internal battery depleted condition. Setting this object to 'off' will prevent the UPS system from restarting after a shutdown until an operator manually or remotely explicitly restarts it. If the UPS is in a startup or reboot countdown, then the UPS will not restart until that delay has been satisfied." ::= { upsControl 5 } -- -- The Configuration group. -- upsConfig OBJECT IDENTIFIER ::= { upsObjects 9 } upsConfigInputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION "The magnitude of the nominal input voltage. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 1 } upsConfigInputFreq OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The nominal input frequency. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 2 } Case [Page 26] RFC 1628 UPS MIB May 1994 upsConfigOutputVoltage OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION "The magnitude of the nominal output voltage. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 3 } upsConfigOutputFreq OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "0.1 Hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The nominal output frequency. On those systems which support read-write access to this object, if there is an attempt to set this variable to a value that is not supported, the request must be rejected and the agent shall respond with an appropriate error message, i.e., badValue for SNMPv1, or inconsistentValue for SNMPv2." ::= { upsConfig 4 } upsConfigOutputVA OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Volt-Amps" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the nominal Volt-Amp rating." ::= { upsConfig 5 } upsConfigOutputPower OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the nominal true power rating." ::= { upsConfig 6 } upsConfigLowBattTime OBJECT-TYPE Case [Page 27] RFC 1628 UPS MIB May 1994 SYNTAX NonNegativeInteger UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of upsEstimatedMinutesRemaining at which a lowBattery condition is declared. For agents which support only discrete (discontinuous) values, then the agent shall round up to the next supported value. If the requested value is larger than the largest supported value, then the largest supported value shall be selected." ::= { upsConfig 7 } upsConfigAudibleStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabled(2), muted(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The requested state of the audible alarm. When in the disabled state, the audible alarm should never sound. The enabled state is self-describing. Setting this object to muted(3) when the audible alarm is sounding shall temporarily silence the alarm. It will remain muted until it would normally stop sounding and the value returned for read operations during this period shall equal muted(3). At the end of this period, the value shall revert to enabled(2). Writes of the value muted(3) when the audible alarm is not sounding shall be accepted but otherwise shall have no effect." ::= { upsConfig 8 } upsConfigLowVoltageTransferPoint OBJECT-TYPE SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum input line voltage allowed before the UPS system transfers to battery backup." ::= { upsConfig 9 } upsConfigHighVoltageTransferPoint OBJECT-TYPE Case [Page 28] RFC 1628 UPS MIB May 1994 SYNTAX NonNegativeInteger UNITS "RMS Volts" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum line voltage allowed before the UPS system transfers to battery backup." ::= { upsConfig 10 } -- -- notifications, i.e., traps -- upsTraps OBJECT IDENTIFIER ::= { upsMIB 2 } -- This section defines the well-known notifications sent by -- UPS agents. -- Care must be taken to insure that no particular notification -- is sent to a single receiving entity more often than once -- every five seconds. upsTrapOnBattery NOTIFICATION-TYPE OBJECTS { upsEstimatedMinutesRemaining, upsSecondsOnBattery, upsConfigLowBattTime } STATUS current DESCRIPTION "The UPS is operating on battery power. This trap is persistent and is resent at one minute intervals until the UPS either turns off or is no longer running on battery." ::= { upsTraps 1 } upsTrapTestCompleted NOTIFICATION-TYPE OBJECTS { upsTestId, upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail, upsTestStartTime, upsTestElapsedTime } STATUS current DESCRIPTION "This trap is sent upon completion of a UPS diagnostic test." ::= { upsTraps 2 } upsTrapAlarmEntryAdded NOTIFICATION-TYPE OBJECTS { upsAlarmId, upsAlarmDescr } STATUS current DESCRIPTION "This trap is sent each time an alarm is inserted into to the alarm table. It is sent on the insertion of Case [Page 29] RFC 1628 UPS MIB May 1994 all alarms except for upsAlarmOnBattery and upsAlarmTestInProgress." ::= { upsTraps 3 } upsTrapAlarmEntryRemoved NOTIFICATION-TYPE OBJECTS { upsAlarmId, upsAlarmDescr } STATUS current DESCRIPTION "This trap is sent each time an alarm is removed from the alarm table. It is sent on the removal of all alarms except for upsAlarmTestInProgress." ::= { upsTraps 4 } -- -- conformance information -- upsConformance OBJECT IDENTIFIER ::= { upsMIB 3 } upsCompliances OBJECT IDENTIFIER ::= { upsConformance 1 } -- -- compliance statements -- upsSubsetCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for UPSs that only support the two-contact communication protocol." MODULE -- this module MANDATORY-GROUPS { upsSubsetIdentGroup, upsSubsetBatteryGroup, upsSubsetInputGroup, upsSubsetOutputGroup, upsSubsetAlarmGroup, upsSubsetControlGroup, upsSubsetConfigGroup } OBJECT upsBatteryStatus SYNTAX INTEGER { batteryNormal(2), batteryLow(3) } DESCRIPTION "Support of the values unknown(1) and batteryDepleted(4) is not required." OBJECT upsAlarmDescr Case [Page 30] RFC 1628 UPS MIB May 1994 DESCRIPTION "Support of all `well known' alarm types is not required. The well known alarm types which must be supported are: upsAlarmOnBattery, upsAlarmLowBattery, upsAlarmInputBad, upsAlarmUpsOutputOff, upsAlarmUpsSystemOff, and upsAlarmTestInProgress." OBJECT upsOutputSource SYNTAX INTEGER { normal(2), battery(4) } DESCRIPTION "Support of the values other(1), none(2), bypass(4), booster(6) and reducer(7) is not required." OBJECT upsShutdownType MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one shutdown type." OBJECT upsAutoRestart MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one restart type." OBJECT upsConfigInputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigInputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." Case [Page 31] RFC 1628 UPS MIB May 1994 ::= { upsCompliances 1 } upsBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for UPSs that support full-featured functions, such as control." MODULE -- this module MANDATORY-GROUPS { upsBasicIdentGroup, upsBasicBatteryGroup, upsBasicInputGroup, upsBasicOutputGroup, upsBasicAlarmGroup, upsBasicTestGroup, upsBasicControlGroup, upsBasicConfigGroup } OBJECT upsAlarmDescr DESCRIPTION "Support of all `well known' alarm types is not required. The well known alarm types which must be supported are: upsAlarmOnBattery, upsAlarmLowBattery, upsAlarmDepletedBattery, upsAlarmTempBad, upsAlarmInputBad, upsAlarmOutputOverload, upsAlarmOnBypass, upsAlarmBypassBad, upsAlarmOutputOffAsRequested, upsAlarmUpsOffAsRequested, upsAlarmUpsOutputOff, upsAlarmUpsSystemOff, upsAlarmGeneralFault, upsAlarmDiagnosticTestFailed, upsAlarmCommunicationsLost, upsAlarmShutdownPending, and upsAlarmTestInProgress." OBJECT upsTestId DESCRIPTION "Support of all `well known' test types is not required. If no tests are supported, then the only well known test type which must be supported is upsTestNoTestsInitiated." OBJECT upsOutputSource SYNTAX INTEGER { normal(2), battery(4) } DESCRIPTION "Support of the values other(1), none(2), bypass(4), booster(6) and reducer(7) is not required." GROUP upsBasicBypassGroup Case [Page 32] RFC 1628 UPS MIB May 1994 DESCRIPTION "The upsBasicBypassGroup is only required for UPSs that have a Bypass present." OBJECT upsShutdownType MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one shutdown type." OBJECT upsAutoRestart MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one restart type." OBJECT upsConfigInputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigInputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigLowBattTime DESCRIPTION "Implementation of all possible values may be onerous for some systems. Consequently, not all possible values must be supported. However, at least two different manufacturer-selected values must be supported." ::= { upsCompliances 2 } upsFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Case [Page 33] RFC 1628 UPS MIB May 1994 "The compliance statement for UPSs that support advanced full-featured functions." MODULE -- this module MANDATORY-GROUPS { upsFullIdentGroup, upsFullBatteryGroup, upsFullInputGroup, upsFullOutputGroup, upsFullAlarmGroup, upsFullTestGroup, upsFullControlGroup, upsFullConfigGroup } OBJECT upsAlarmDescr DESCRIPTION "Support of all `well known' alarm types is not required. The well known alarm types which must be supported are: upsAlarmBatteryBad, upsAlarmOnBattery, upsAlarmLowBattery, upsAlarmDepletedBattery, upsAlarmTempBad, upsAlarmInputBad, upsAlarmOnBypass, upsAlarmBypassBad, upsAlarmOutputOffAsRequested, upsAlarmUpsOffAsRequested, upsAlarmUpsOutputOff, upsAlarmUpsSystemOff, upsAlarmGeneralFault, upsAlarmDiagnosticTestFailed, upsAlarmCommunicationsLost, upsAlarmShutdownPending, and upsAlarmTestInProgress." OBJECT upsTestId DESCRIPTION "Support of all `well known' test types is not required. The well known test types which must be supported are: upsTestNoTestsInitiated, upsTestGeneralSystemsTest, and upsTestQuickBatteryTest." OBJECT upsOutputSource SYNTAX INTEGER { normal(2), battery(4) } DESCRIPTION "Support of the values other(1), none(2), bypass(4), booster(6) and reducer(7) is not required." GROUP upsFullBypassGroup DESCRIPTION "The upsFullBypassGroup is only required for UPSs that have a Bypass present." OBJECT upsShutdownType MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant Case [Page 34] RFC 1628 UPS MIB May 1994 systems need not support more than one shutdown type." OBJECT upsAutoRestart MIN-ACCESS read-only DESCRIPTION "Read-write access is not required, i.e., compliant systems need not support more than one restart type." OBJECT upsConfigInputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigInputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputVoltage MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigOutputFreq MIN-ACCESS read-only DESCRIPTION "Read-write access is not required." OBJECT upsConfigLowBattTime DESCRIPTION "Implementation of all possible values may be onerous for some systems. Consequently, not all possible values must be supported. However, at least two different manufacturer-selected values must be supported." ::= { upsCompliances 3 } -- -- units of conformance -- -- summary at a glance: -- subset basic adv --upsIdentManufacturer x x x --upsIdentModel x x x Case [Page 35] RFC 1628 UPS MIB May 1994 --upsIdentUPSSoftwareVersion x x --upsIdentAgentSoftwareVersion x x x --upsIdentName x x x --upsIdentAttachedDevices x x -- --upsBatteryStatus x x x notes --upsSecondsOnBattery x x x --upsEstimatedMinutesRemaining x --upsEstimatedChargeRemaining x --upsBatteryVoltage --upsBatteryCurrent --upsBatteryTemperature -- --upsInputLineBads x x x --upsInputNumLines x x --upsInputFrequency x x --upsInputVoltage x x --upsInputCurrent --upsInputTruePower -- --upsOutputSource x x x notes --upsOutputFrequency x x --upsOutputNumLines x x --upsOutputVoltage x x --upsOutputCurrent x --upsOutputPower x --upsOutputPercentLoad x -- -- --upsBypassFrequency x x notes --upsBypassNumLines x x --upsBypassVoltage x x --upsBypassCurrent --upsBypassPower -- -- --upsAlarmsPresent x x x --upsAlarmDescr x x x notes --upsAlarmTime x x x -- --upsTestId x x notes --upsTestSpinLock x x --upsTestResultsSummary x x --upsTestResultsDetail x x --upsTestStartTime x x --upsTestElapsedTime x x -- --upsShutdownType x x x notes Case [Page 36] RFC 1628 UPS MIB May 1994 --upsShutdownAfterDelay x x x --upsStartupAfterDelay x x --upsRebootWithDuration x x --upsAutoRestart x x x notes -- --upsConfigInputVoltage x x x notes --upsConfigInputFreq x x x notes --upsConfigOutputVoltage x x x notes --upsConfigOutputFreq x x x notes --upsConfigOutputVA x x x --upsConfigOutputPower x x x --upsConfigLowBattTime x x notes --upsConfigAudibleStatus x x --upsConfigLowVoltageTransferPoint --upsConfigHighVoltageTransferPoint -- units of conformance upsGroups OBJECT IDENTIFIER ::= { upsConformance 2 } upsSubsetGroups OBJECT IDENTIFIER ::= { upsGroups 1 } upsSubsetIdentGroup OBJECT-GROUP OBJECTS { upsIdentManufacturer, upsIdentModel, upsIdentAgentSoftwareVersion, upsIdentName, upsIdentAttachedDevices } STATUS current DESCRIPTION "The upsSubsetIdentGroup defines objects which are common across all UPSs which meet subset compliance. Most devices which conform to the upsSubsetIdentGroup will provide access to these objects via a proxy agent. If the proxy agent is compatible with multiple UPS types, configuration of the proxy agent will require specifying some of these values, either individually, or as a group (perhaps through a table lookup mechanism based on the UPS model number)." ::= { upsSubsetGroups 1 } upsSubsetBatteryGroup OBJECT-GROUP OBJECTS { upsBatteryStatus, upsSecondsOnBattery } STATUS current DESCRIPTION "The upsSubsetBatteryGroup defines the objects that are common to battery groups of two-contact UPSs." ::= { upsSubsetGroups 2 } upsSubsetInputGroup OBJECT-GROUP Case [Page 37] RFC 1628 UPS MIB May 1994 OBJECTS { upsInputLineBads } STATUS current DESCRIPTION "The upsSubsetInputGroup defines the objects that are common to the Input groups of two-contact UPSs." ::= { upsSubsetGroups 3 } upsSubsetOutputGroup OBJECT-GROUP OBJECTS { upsOutputSource } STATUS current DESCRIPTION "The upsSubsetOutputGroup defines the objects that are common to the Output groups of two-contact UPSs." ::= { upsSubsetGroups 4 } -- { upsSubsetGroups 5 } is reserved for -- future use (upsSubsetBypassGroup) upsSubsetAlarmGroup OBJECT-GROUP OBJECTS { upsAlarmsPresent, upsAlarmDescr, upsAlarmTime } STATUS current DESCRIPTION "The upsSubsetAlarmGroup defines the objects that are common to the Alarm groups of two-contact UPSs." ::= { upsSubsetGroups 6 } -- { upsSubsetGroups 7 } is reserved for -- future use (upsSubsetTestGroup) upsSubsetControlGroup OBJECT-GROUP OBJECTS { upsShutdownType, upsShutdownAfterDelay, upsAutoRestart } STATUS current DESCRIPTION "The upsSubsetControlGroup defines the objects that are common to the Control groups of two-contact UPSs." ::= { upsSubsetGroups 8 } upsSubsetConfigGroup OBJECT-GROUP OBJECTS { upsConfigInputVoltage, upsConfigInputFreq, upsConfigOutputVoltage, upsConfigOutputFreq, upsConfigOutputVA, upsConfigOutputPower } STATUS current DESCRIPTION "The upsSubsetConfigGroup defines the objects that are common to the Config groups of two-contact UPSs." ::= { upsSubsetGroups 9 } Case [Page 38] RFC 1628 UPS MIB May 1994 upsBasicGroups OBJECT IDENTIFIER ::= { upsGroups 2 } upsBasicIdentGroup OBJECT-GROUP OBJECTS { upsIdentManufacturer, upsIdentModel, upsIdentUPSSoftwareVersion, upsIdentAgentSoftwareVersion, upsIdentName } STATUS current DESCRIPTION "The upsBasicIdentGroup defines objects which are common to the Ident group of compliant UPSs which support basic functions." ::= { upsBasicGroups 1 } upsBasicBatteryGroup OBJECT-GROUP OBJECTS { upsBatteryStatus, upsSecondsOnBattery } STATUS current DESCRIPTION "The upsBasicBatteryGroup defines the objects that are common to the battery groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 2 } upsBasicInputGroup OBJECT-GROUP OBJECTS { upsInputLineBads, upsInputNumLines, upsInputFrequency, upsInputVoltage } STATUS current DESCRIPTION "The upsBasicInputGroup defines the objects that are common to the Input groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 3 } upsBasicOutputGroup OBJECT-GROUP OBJECTS { upsOutputSource, upsOutputFrequency, upsOutputNumLines, upsOutputVoltage } STATUS current DESCRIPTION "The upsBasicOutputGroup defines the objects that are common to the Output groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 4 } upsBasicBypassGroup OBJECT-GROUP OBJECTS { upsBypassFrequency, upsBypassNumLines, upsBypassVoltage } STATUS current DESCRIPTION "The upsBasicBypassGroup defines the objects that are Case [Page 39] RFC 1628 UPS MIB May 1994 common to the Bypass groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 5 } upsBasicAlarmGroup OBJECT-GROUP OBJECTS { upsAlarmsPresent, upsAlarmDescr, upsAlarmTime } STATUS current DESCRIPTION "The upsBasicAlarmGroup defines the objects that are common to the Alarm groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 6 } upsBasicTestGroup OBJECT-GROUP OBJECTS { upsTestId, upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail, upsTestStartTime, upsTestElapsedTime } STATUS current DESCRIPTION "The upsBasicTestGroup defines the objects that are common to the Test groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 7 } upsBasicControlGroup OBJECT-GROUP OBJECTS { upsShutdownType, upsShutdownAfterDelay, upsStartupAfterDelay, upsRebootWithDuration, upsAutoRestart } STATUS current DESCRIPTION "The upsBasicControlGroup defines the objects that are common to the Control groups of compliant UPSs which support basic functions." ::= { upsBasicGroups 8 } upsBasicConfigGroup OBJECT-GROUP OBJECTS { upsConfigInputVoltage, upsConfigInputFreq, upsConfigOutputVoltage, upsConfigOutputFreq, upsConfigOutputVA, upsConfigOutputPower, upsConfigLowBattTime, upsConfigAudibleStatus } STATUS current DESCRIPTION "The upsBasicConfigGroup defines the objects that are common to the Config groups of UPSs which support basic functions." ::= { upsBasicGroups 9 } Case [Page 40] RFC 1628 UPS MIB May 1994 upsFullGroups OBJECT IDENTIFIER ::= { upsGroups 3 } upsFullIdentGroup OBJECT-GROUP OBJECTS { upsIdentManufacturer, upsIdentModel, upsIdentUPSSoftwareVersion, upsIdentAgentSoftwareVersion, upsIdentName, upsIdentAttachedDevices } STATUS current DESCRIPTION "The upsFullIdentGroup defines objects which are common to the Ident group of fully compliant UPSs." ::= { upsFullGroups 1 } upsFullBatteryGroup OBJECT-GROUP OBJECTS { upsBatteryStatus, upsSecondsOnBattery, upsEstimatedMinutesRemaining, upsEstimatedChargeRemaining } STATUS current DESCRIPTION "The upsFullBatteryGroup defines the objects that are common to the battery groups of fully compliant UPSs." ::= { upsFullGroups 2 } upsFullInputGroup OBJECT-GROUP OBJECTS { upsInputLineBads, upsInputNumLines, upsInputFrequency, upsInputVoltage } STATUS current DESCRIPTION "The upsFullInputGroup defines the objects that are common to the Input groups of fully compliant UPSs." ::= { upsFullGroups 3 } upsFullOutputGroup OBJECT-GROUP OBJECTS { upsOutputSource, upsOutputFrequency, upsOutputNumLines, upsOutputVoltage, upsOutputCurrent, upsOutputPower, upsOutputPercentLoad } STATUS current DESCRIPTION "The upsFullOutputGroup defines the objects that are common to the Output groups of fully compliant UPSs." ::= { upsFullGroups 4 } upsFullBypassGroup OBJECT-GROUP OBJECTS { upsBypassFrequency, upsBypassNumLines, upsBypassVoltage } STATUS current DESCRIPTION Case [Page 41] RFC 1628 UPS MIB May 1994 "The upsFullBypassGroup defines the objects that are common to the Bypass groups of fully compliant UPSs." ::= { upsFullGroups 5 } upsFullAlarmGroup OBJECT-GROUP OBJECTS { upsAlarmsPresent, upsAlarmDescr, upsAlarmTime } STATUS current DESCRIPTION "The upsFullAlarmGroup defines the objects that are common to the Alarm groups of fully compliant UPSs." ::= { upsFullGroups 6 } upsFullTestGroup OBJECT-GROUP OBJECTS { upsTestId, upsTestSpinLock, upsTestResultsSummary, upsTestResultsDetail, upsTestStartTime, upsTestElapsedTime } STATUS current DESCRIPTION "The upsFullTestGroup defines the objects that are common to the Test groups of fully compliant UPSs." ::= { upsFullGroups 7 } upsFullControlGroup OBJECT-GROUP OBJECTS { upsShutdownType, upsShutdownAfterDelay, upsStartupAfterDelay, upsRebootWithDuration, upsAutoRestart } STATUS current DESCRIPTION "The upsFullControlGroup defines the objects that are common to the Control groups of fully compliant UPSs." ::= { upsFullGroups 8 } upsFullConfigGroup OBJECT-GROUP OBJECTS { upsConfigInputVoltage, upsConfigInputFreq, upsConfigOutputVoltage, upsConfigOutputFreq, upsConfigOutputVA, upsConfigOutputPower, upsConfigLowBattTime, upsConfigAudibleStatus } STATUS current DESCRIPTION "The upsFullConfigGroup defines the objects that are common to the Config groups of fully compliant UPSs." ::= { upsFullGroups 9 } END Case [Page 42] RFC 1628 UPS MIB May 1994 5. Acknowledgements The UPS MIB represents the combined work of the IETF UPS MIB Working Group, with particular, substantial authorship contributions from: Mike Davison Fibercom, Inc. Ray Wasson Consultant Roger Draper Liebert Corporation Ken Key SNMP Research, Incorporated Pete Yoest American Power Conversion Doug Rademacher American Power Conversion Ron Pitt Network Security Systems, Inc Terry Zumwalt International Power Machines Lawren Markle Tripp Lite Bill Elliot ONEAC Tom Brennan Exide Electronics Brian Young Best Power Technology Case [Page 43] RFC 1628 UPS MIB May 1994 6. References [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Inc., Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [3] 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. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April, 1993. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. Case [Page 44] RFC 1628 UPS MIB May 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Jeffrey D. Case, Ph.D. SNMP Research, Incorporated 3001 Kimberlin Heights Road Knoxville, Tennessee 37920 Phone: (615) 573-1434 EMail: case@SNMP.COM Case [Page 45] snmp-mibs-downloader-1.1/mibrfcs/rfc1658.txt0000644000000000000000000007750311402176071015601 0ustar Network Working Group B. Stewart Request for Comments: 1658 Xyplex, Inc. Obsoletes: 1316 July 1994 Category: Standards Track Definitions of Managed Objects for Character Stream Devices using SMIv2 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 ................................................ 2 2. The SNMPv2 Network Management Framework ..................... 2 2.1 Object Definitions ......................................... 3 3. Overview .................................................... 3 3.1 Relationship to Interface MIB .............................. 4 4. Definitions ................................................. 4 5. Acknowledgements ............................................ 17 6. References .................................................. 17 7. Security Considerations ..................................... 18 8. Author's Address ............................................ 18 1. Introduction This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. Stewart [Page 1] RFC 1658 Character MIB July 1994 o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. 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 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 Character MIB applies to ports that carry a character stream, whether physical or virtual, serial or parallel, synchronous or asynchronous. The most common example of a character stream device is a hardware terminal port with an RS-232 interface. Another common hardware example is a parallel printer port, say with a Centronics interface. The concept also includes virtual terminal ports, such as a software connection point for a remote console. The Character MIB is mandatory for all systems that offer character stream ports. This includes, for example, terminal servers, general-purpose time-sharing hosts, and even such systems as a bridge with a (virtual) console port. It may or may not include character ports that do not support network sessions, depending on the system's needs. The Character MIB's central abstraction is a port. Physical ports have a one-to-one correspondence with hardware ports. Virtual ports are software entities analogous to physical ports, but with no hardware connector. Each port supports one or more sessions. A session represents a virtual connection that carries characters between the port and some partner. Sessions typically operate over a stack of network protocols. A typical session, for example, uses Telnet over TCP. Stewart [Page 2] RFC 1658 Character MIB July 1994 The MIB comprises one base object and two tables, detailed in the following sections. The tables contain objects for ports and sessions. The MIB intentionally contains no distinction between what is often called permanent and operational or volatile data bases. For the purposes of this MIB, handling of such distinctions is implementation specific. 3.1. Relationship to Interface MIB The Character MIB does not relate directly to the Interface MIB [1], since it is not intrinsically a network interface. On the other hand, in most implementations where it is present, it will be above a physical sublayer interface, such as the RS-232-like [2] or Parallel-printer-like [3] MIBs. Such physical interfaces typically are represented by a row in the interface table (ifTable), identified by a value of ifIndex. 4. Definitions CHARACTER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, Gauge32, TimeTicks FROM SNMPv2-SMI AutonomousType, InstancePointer FROM SNMPv2-TC InterfaceIndex FROM IF-MIB transmission, mib-2 FROM RFC1213-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; char MODULE-IDENTITY LAST-UPDATED "9405261700Z" ORGANIZATION "IETF Character MIB Working Group" CONTACT-INFO " Bob Stewart Postal: Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 Stewart [Page 3] RFC 1658 Character MIB July 1994 E-mail: rlstewart@eng.xyplex.com" DESCRIPTION "The MIB module for character stream devices." ::= { mib-2 19 } PortIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero, for each character port in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub- layer must remain constant at least from one re- initialization of the entity's network management system to the next re-initialization. In a system where the character ports are attached to hardware represented by an ifIndex, it is conventional, but not required, to make the character port index equal to the corresponding ifIndex." SYNTAX Integer32 -- Generic Character information charNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in charPortTable, regardless of their current state." ::= { char 1 } -- the Character Port table charPortTable OBJECT-TYPE SYNTAX SEQUENCE OF CharPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value of charNumber." ::= { char 2 } Stewart [Page 4] RFC 1658 Character MIB July 1994 charPortEntry OBJECT-TYPE SYNTAX CharPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a character port." INDEX { charPortIndex } ::= { charPortTable 1 } CharPortEntry ::= SEQUENCE { charPortIndex PortIndex, charPortName DisplayString, charPortType INTEGER, charPortHardware AutonomousType, charPortReset INTEGER, charPortAdminStatus INTEGER, charPortOperStatus INTEGER, charPortLastChange TimeTicks, charPortInFlowType INTEGER, charPortOutFlowType INTEGER, charPortInFlowState INTEGER, charPortOutFlowState INTEGER, charPortInCharacters Counter32, charPortOutCharacters Counter32, charPortAdminOrigin INTEGER, charPortSessionMaximum INTEGER, charPortSessionNumber Gauge32, charPortSessionIndex INTEGER, charPortInFlowTypes Stewart [Page 5] RFC 1658 Character MIB July 1994 OCTET STRING, charPortOutFlowTypes OCTET STRING, charPortLowerIfIndex InterfaceIndex } charPortIndex OBJECT-TYPE SYNTAX PortIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each character port, perhaps corresponding to the same value of ifIndex when the character port is associated with a hardware port represented by an ifIndex." ::= { charPortEntry 1 } charPortName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "An administratively assigned name for the port, typically with some local significance." ::= { charPortEntry 2 } charPortType OBJECT-TYPE SYNTAX INTEGER { physical(1), virtual(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's type, 'physical' if the port represents an external hardware connector, 'virtual' if it does not." ::= { charPortEntry 3 } charPortHardware OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to hardware MIB definitions specific to a physical port's external connector. For example, if the connector is RS-232, then the value of this object refers to a MIB sub-tree defining objects specific to RS-232. If an agent is not configured to have such values, the agent returns the object Stewart [Page 6] RFC 1658 Character MIB July 1994 identifier: nullHardware OBJECT IDENTIFIER ::= { 0 0 } " ::= { charPortEntry 4 } charPortReset OBJECT-TYPE SYNTAX INTEGER { ready(1), execute(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control to force the port into a clean, initial state, both hardware and software, disconnecting all the port's existing sessions. In response to a get-request or get-next-request, the agent always returns 'ready' as the value. Setting the value to 'execute' causes a reset." ::= { charPortEntry 5 } charPortAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), off(3), maintenance(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's desired state, independent of flow control. 'enabled' indicates that the port is allowed to pass characters and form new sessions. 'disabled' indicates that the port is allowed to pass characters but not form new sessions. 'off' indicates that the port is not allowed to pass characters or have any sessions. 'maintenance' indicates a maintenance mode, exclusive of normal operation, such as running a test. 'enabled' corresponds to ifAdminStatus 'up'. 'disabled' and 'off' correspond to ifAdminStatus 'down'. 'maintenance' corresponds to ifAdminStatus 'test'." ::= { charPortEntry 6 } charPortOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), maintenance(3), absent(4), active(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's actual, operational state, independent Stewart [Page 7] RFC 1658 Character MIB July 1994 of flow control. 'up' indicates able to function normally. 'down' indicates inability to function for administrative or operational reasons. 'maintenance' indicates a maintenance mode, exclusive of normal operation, such as running a test. 'absent' indicates that port hardware is not present. 'active' indicates up with a user present (e.g. logged in). 'up' and 'active' correspond to ifOperStatus 'up'. 'down' and 'absent' correspond to ifOperStatus 'down'. 'maintenance' corresponds to ifOperStatus 'test'." ::= { charPortEntry 7 } charPortLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the port entered its current operational state. If the current state was entered prior to the last reinitialization of the local network management subsystem, then this object contains a zero value." ::= { charPortEntry 8 } -- charPortInFlowType is deprecated in favor of -- charPortInFlowTypes charPortInFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), xonXoff(2), hardware(3), ctsRts(4), dsrDtr(5) } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The port's type of input flow control. 'none' indicates no flow control at this level or below. 'xonXoff' indicates software flow control by recognizing XON and XOFF characters. 'hardware' indicates flow control delegated to the lower level, for example a parallel port. 'ctsRts' and 'dsrDtr' are specific to RS-232-like ports. Although not architecturally pure, they are included here for simplicity's sake." ::= { charPortEntry 9 } Stewart [Page 8] RFC 1658 Character MIB July 1994 -- charPortOutFlowType is deprecated in favor of -- charPortOutFlowTypes charPortOutFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), xonXoff(2), hardware(3), ctsRts(4), dsrDtr(5) } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The port's type of output flow control. 'none' indicates no flow control at this level or below. 'xonXoff' indicates software flow control by recognizing XON and XOFF characters. 'hardware' indicates flow control delegated to the lower level, for example a parallel port. 'ctsRts' and 'dsrDtr' are specific to RS-232-like ports. Although not architecturally pure, they are included here for simplicy's sake." ::= { charPortEntry 10 } charPortInFlowState OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), stop(3), go(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of input flow control on the port. 'none' indicates not applicable. 'unknown' indicates this level does not know. 'stop' indicates flow not allowed. 'go' indicates flow allowed." ::= { charPortEntry 11 } charPortOutFlowState OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), stop(3), go(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of output flow control on the port. 'none' indicates not applicable. 'unknown' indicates this level does not know. 'stop' indicates flow not allowed. 'go' indicates flow allowed." ::= { charPortEntry 12 } charPortInCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Stewart [Page 9] RFC 1658 Character MIB July 1994 STATUS current DESCRIPTION "Total number of characters detected as input from the port since system re-initialization and while the port operational state was 'up', 'active', or 'maintenance', including, for example, framing, flow control (i.e. XON and XOFF), each occurrence of a BREAK condition, locally-processed input, and input sent to all sessions." ::= { charPortEntry 13 } charPortOutCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters detected as output to the port since system re-initialization and while the port operational state was 'up', 'active', or 'maintenance', including, for example, framing, flow control (i.e. XON and XOFF), each occurrence of a BREAK condition, locally-created output, and output received from all sessions." ::= { charPortEntry 14 } charPortAdminOrigin OBJECT-TYPE SYNTAX INTEGER { dynamic(1), network(2), local(3), none(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administratively allowed origin for establishing session on the port. 'dynamic' allows 'network' or 'local' session establishment. 'none' disallows session establishment." ::= { charPortEntry 15 } charPortSessionMaximum OBJECT-TYPE SYNTAX INTEGER (-1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent sessions allowed on the port. A value of -1 indicates no maximum. Setting the maximum to less than the current number of sessions has unspecified results." ::= { charPortEntry 16 } Stewart [Page 10] RFC 1658 Character MIB July 1994 charPortSessionNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of open sessions on the port that are in the connecting, connected, or disconnecting state." ::= { charPortEntry 17 } charPortSessionIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of charSessIndex for the port's first or only active session. If the port has no active session, the agent returns the value zero." ::= { charPortEntry 18 } charPortInFlowTypes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-write STATUS current DESCRIPTION "The port's types of input flow control at the software level. Hardware-level flow control is independently controlled by the appropriate hardware-level MIB. A value of zero indicates no flow control. Depending on the specific implementation, any or all combinations of flow control may be chosen by adding the values: 128 xonXoff, recognizing XON and XOFF characters 64 enqHost, ENQ/ACK to allow input to host 32 enqTerm, ACK to allow output to port " ::= { charPortEntry 19 } charPortOutFlowTypes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-write STATUS current DESCRIPTION "The port's types of output flow control at the software level. Hardware-level flow control is independently controlled by the appropriate Stewart [Page 11] RFC 1658 Character MIB July 1994 hardware-level MIB. A value of zero indicates no flow control. Depending on the specific implementation, any or all combinations of flow control may be chosen by adding the values: 128 xonXoff, recognizing XON and XOFF characters 64 enqHost, ENQ/ACK to allow input to host 32 enqTerm, ACK to allow output to port " ::= { charPortEntry 20 } charPortLowerIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the lower level hardware supporting this character port, zero if none." ::= { charPortEntry 21 } -- the Character Session table charSessTable OBJECT-TYPE SYNTAX SEQUENCE OF CharSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port session entries." ::= { char 3 } charSessEntry OBJECT-TYPE SYNTAX CharSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a character port session." INDEX { charSessPortIndex, charSessIndex } ::= { charSessTable 1 } CharSessEntry ::= SEQUENCE { charSessPortIndex PortIndex, charSessIndex Stewart [Page 12] RFC 1658 Character MIB July 1994 INTEGER, charSessKill INTEGER, charSessState INTEGER, charSessProtocol AutonomousType, charSessOperOrigin INTEGER, charSessInCharacters Counter32, charSessOutCharacters Counter32, charSessConnectionId InstancePointer, charSessStartTime TimeTicks } charSessPortIndex OBJECT-TYPE SYNTAX PortIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of charPortIndex for the port to which this session belongs." ::= { charSessEntry 1 } charSessIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The session index in the context of the port, a non-zero positive integer. Session indexes within a port need not be sequential. Session indexes may be reused for different ports. For example, port 1 and port 3 may both have a session 2 at the same time. Session indexes may have any valid integer value, with any meaning convenient to the agent implementation." ::= { charSessEntry 2 } charSessKill OBJECT-TYPE SYNTAX INTEGER { ready(1), execute(2) } MAX-ACCESS read-write STATUS current DESCRIPTION Stewart [Page 13] RFC 1658 Character MIB July 1994 "A control to terminate the session. In response to a get-request or get-next-request, the agent always returns 'ready' as the value. Setting the value to 'execute' causes termination." ::= { charSessEntry 3 } charSessState OBJECT-TYPE SYNTAX INTEGER { connecting(1), connected(2), disconnecting(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the session, disregarding flow control. 'connected' indicates that character data could flow on the network side of session. 'connecting' indicates moving from nonexistent toward 'connected'. 'disconnecting' indicates moving from 'connected' or 'connecting' to nonexistent." ::= { charSessEntry 4 } charSessProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The network protocol over which the session is running. Other OBJECT IDENTIFIER values may be defined elsewhere, in association with specific protocols. However, this document assigns those of known interest as of this writing." ::= { charSessEntry 5 } wellKnownProtocols OBJECT IDENTIFIER ::= { char 4 } protocolOther OBJECT IDENTIFIER ::= { wellKnownProtocols 1 } protocolTelnet OBJECT IDENTIFIER ::= { wellKnownProtocols 2 } protocolRlogin OBJECT IDENTIFIER ::= { wellKnownProtocols 3 } protocolLat OBJECT IDENTIFIER ::= { wellKnownProtocols 4 } protocolX29 OBJECT IDENTIFIER ::= { wellKnownProtocols 5 } protocolVtp OBJECT IDENTIFIER ::= { wellKnownProtocols 6 } charSessOperOrigin OBJECT-TYPE SYNTAX INTEGER { unknown(1), network(2), local(3) } MAX-ACCESS read-only STATUS current DESCRIPTION Stewart [Page 14] RFC 1658 Character MIB July 1994 "The session's source of establishment." ::= { charSessEntry 6 } charSessInCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This session's subset of charPortInCharacters." ::= { charSessEntry 7 } charSessOutCharacters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This session's subset of charPortOutCharacters." ::= { charSessEntry 8 } charSessConnectionId OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to additional local MIB information. This should be the highest available related MIB, corresponding to charSessProtocol, such as Telnet. For example, the value for a TCP connection (in the absence of a Telnet MIB) is the object identifier of tcpConnState. If an agent is not configured to have such values, the agent returns the object identifier: nullConnectionId OBJECT IDENTIFIER ::= { 0 0 } " ::= { charSessEntry 9 } charSessStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime in MIB-2 when the session entered connecting state." ::= { charSessEntry 10 } Stewart [Page 15] RFC 1658 Character MIB July 1994 -- conformance information charConformance OBJECT IDENTIFIER ::= { char 5 } charGroups OBJECT IDENTIFIER ::= { charConformance 1 } charCompliances OBJECT IDENTIFIER ::= { charConformance 2 } -- compliance statements charCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have Character hardware interfaces." MODULE -- this module MANDATORY-GROUPS { charGroup } ::= { charCompliances 1 } -- units of conformance charGroup OBJECT-GROUP OBJECTS { charNumber, charPortIndex, charPortName, charPortType, charPortHardware, charPortReset, charPortAdminStatus, charPortOperStatus, charPortLastChange, charPortInFlowState, charPortOutFlowState, charPortAdminOrigin, charPortSessionMaximum, charPortInFlowTypes, charPortOutFlowTypes, charPortInCharacters, charPortOutCharacters, charPortSessionNumber, charPortSessionIndex, charPortLowerIfIndex, charSessPortIndex, charSessIndex, charSessKill, charSessState, charSessProtocol, charSessOperOrigin, charSessInCharacters, charSessOutCharacters, charSessConnectionId, charSessStartTime } STATUS current DESCRIPTION "A collection of objects providing information applicable to all Character interfaces." ::= { charGroups 1 } END Stewart [Page 16] RFC 1658 Character MIB July 1994 5. Acknowledgements This memo was produced by the IETF Character MIB Working Group. 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] 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. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] Stewart, B., "Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2", RFC 1659, Xyplex, Inc., July 1994. [7] Stewart, B., "Definitions of Managed Objects for Parallel- printer-like Hardware Devices using SMIv2", RFC 1660, Xyplex, Inc., July 1994. Stewart [Page 17] RFC 1658 Character MIB July 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Phone: 508-952-4816 Fax: 508-952-4887 EMail: rlstewart@eng.xyplex.com Stewart [Page 18] snmp-mibs-downloader-1.1/mibrfcs/rfc1659.txt0000644000000000000000000010717711402176071015603 0ustar Network Working Group B. Stewart Request for Comments: 1659 Xyplex, Inc. Obsoletes: 1317 July 1994 Category: Standards Track Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2 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 ................................................ 1 2. The SNMPv2 Network Management Framework ..................... 1 2.1 Object Definitions ......................................... 2 3. Overview .................................................... 2 3.1 Relationship to Interface MIB .............................. 3 4. Definitions ................................................. 3 5. Acknowledgements ............................................ 20 6. References .................................................. 20 7. Security Considerations ..................................... 21 8. Author's Address ............................................ 21 1. Introduction This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. Stewart [Page 1] RFC 1659 RS-232-like MIB July 1994 o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. 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 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 RS-232-like Hardware Device MIB applies to interface ports that might logically support the Interface MIB, a Transmission MIB, or the Character MIB. The most common example is an RS-232 port with modem signals. The RS-232-like Hardware Device MIB is mandatory for all systems that have such a hardware port supporting services managed through some other MIB. The MIB includes multiple similar types of hardware, and as a result contains objects not applicable to all of those types. The compliance definitions herein thus have a general group for all implementations, and separate groups for the different types of ports, such as asynchronous and synchronous. The RS-232-like Hardware Port MIB includes RS-232, RS-422, RS-423, V.35, and other asynchronous or synchronous, serial physical links with a similar set of control signals. The MIB contains objects that relate to physical layer connections. Such connections may provide interesting hardware signals (other than for basic data transfer), such as RNG and DCD. Hardware ports also have such attributes as speed and bits per character. Stewart [Page 2] RFC 1659 RS-232-like MIB July 1994 The MIB comprises one base object and four tables, detailed in the following sections. The tables contain objects for all ports, asynchronous ports, and input and output control signals. 3.1. Relationship to Interface MIB The RS-232-like MIB is one of many MIBs designed for layered use as described in the Interface MIB [5]. In most implementations where it is present, it will be in the lowest interface sublayer, that is, the RS-232-like MIB represents the physical layer, providing service to higher layers such as the Character MIB [6] or PPP MIB [7]. The Interface MIB's ifTestTable and ifRcvAddressTable are not relevant to the RS-232-like MIB. The RS-232-like MIB is relevant for ifType values rs232(33), v35(45), and perhaps others. The RS-232-like MIB requires the conformance groups ifGeneralGroup, and ifFixedLengthGroup. The value of ifSpeed is the same as rs232PortOutSpeed. Usefulness of error counters in this MIB depends on the octet counters in ifFixedLengthGroup. 4. Definitions RS-232-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI InterfaceIndex FROM IF-MIB transmission FROM RFC1213-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; rs232 MODULE-IDENTITY LAST-UPDATED "9405261700Z" ORGANIZATION "IETF Character MIB Working Group" CONTACT-INFO " Bob Stewart Postal: Xyplex, Inc. Stewart [Page 3] RFC 1659 RS-232-like MIB July 1994 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com" DESCRIPTION "The MIB module for RS-232-like hardware devices." ::= { transmission 33 } -- Generic RS-232-like information rs232Number OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ports (regardless of their current state) in the RS-232-like general port table." ::= { rs232 1 } -- RS-232-like General Port Table rs232PortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232PortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value of rs232Number." ::= { rs232 2 } rs232PortEntry OBJECT-TYPE SYNTAX Rs232PortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a port." INDEX { rs232PortIndex } ::= { rs232PortTable 1 } Rs232PortEntry ::= SEQUENCE { rs232PortIndex InterfaceIndex, rs232PortType Stewart [Page 4] RFC 1659 RS-232-like MIB July 1994 INTEGER, rs232PortInSigNumber Integer32, rs232PortOutSigNumber Integer32, rs232PortInSpeed Integer32, rs232PortOutSpeed Integer32, rs232PortInFlowType INTEGER, rs232PortOutFlowType INTEGER } rs232PortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the port. By convention and if possible, hardware port numbers map directly to external connectors. The value for each port must remain constant at least from one re-initialization of the network management agent to the next." ::= { rs232PortEntry 1 } rs232PortType OBJECT-TYPE SYNTAX INTEGER { other(1), rs232(2), rs422(3), rs423(4), v35(5), x21(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's hardware type." ::= { rs232PortEntry 2 } rs232PortInSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input signals for the port in the input signal table (rs232PortInSigTable). The table contains entries only for those signals the software can detect and that are useful to observe." ::= { rs232PortEntry 3 } Stewart [Page 5] RFC 1659 RS-232-like MIB July 1994 rs232PortOutSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output signals for the port in the output signal table (rs232PortOutSigTable). The table contains entries only for those signals the software can assert and that are useful to observe." ::= { rs232PortEntry 4 } rs232PortInSpeed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The port's input speed in bits per second. Note that non-standard values, such as 9612, are probably not allowed on most implementations." ::= { rs232PortEntry 5 } rs232PortOutSpeed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The port's output speed in bits per second. Note that non-standard values, such as 9612, are probably not allowed on most implementations." ::= { rs232PortEntry 6 } rs232PortInFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), ctsRts(2), dsrDtr(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's type of input flow control. 'none' indicates no flow control at this level. 'ctsRts' and 'dsrDtr' indicate use of the indicated hardware signals." ::= { rs232PortEntry 7 } rs232PortOutFlowType OBJECT-TYPE SYNTAX INTEGER { none(1), ctsRts(2), dsrDtr(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's type of output flow control. 'none' Stewart [Page 6] RFC 1659 RS-232-like MIB July 1994 indicates no flow control at this level. 'ctsRts' and 'dsrDtr' indicate use of the indicated hardware signals." ::= { rs232PortEntry 8 } -- RS-232-like Asynchronous Port Table rs232AsyncPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232AsyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of asynchronous port entries. Entries need not exist for synchronous ports." ::= { rs232 3 } rs232AsyncPortEntry OBJECT-TYPE SYNTAX Rs232AsyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for an asynchronous port." INDEX { rs232AsyncPortIndex } ::= { rs232AsyncPortTable 1 } Rs232AsyncPortEntry ::= SEQUENCE { rs232AsyncPortIndex InterfaceIndex, rs232AsyncPortBits INTEGER, rs232AsyncPortStopBits INTEGER, rs232AsyncPortParity INTEGER, rs232AsyncPortAutobaud INTEGER, rs232AsyncPortParityErrs Counter32, rs232AsyncPortFramingErrs Counter32, rs232AsyncPortOverrunErrs Counter32 } Stewart [Page 7] RFC 1659 RS-232-like MIB July 1994 rs232AsyncPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each port. Its value is the same as rs232PortIndex for the port." ::= { rs232AsyncPortEntry 1 } rs232AsyncPortBits OBJECT-TYPE SYNTAX INTEGER (5..8) MAX-ACCESS read-write STATUS current DESCRIPTION "The port's number of bits in a character." ::= { rs232AsyncPortEntry 2 } rs232AsyncPortStopBits OBJECT-TYPE SYNTAX INTEGER { one(1), two(2), oneAndHalf(3), dynamic(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's number of stop bits." ::= { rs232AsyncPortEntry 3 } rs232AsyncPortParity OBJECT-TYPE SYNTAX INTEGER { none(1), odd(2), even(3), mark(4), space(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "The port's sense of a character parity bit." ::= { rs232AsyncPortEntry 4 } rs232AsyncPortAutobaud OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control for the port's ability to automatically sense input speed. When rs232PortAutoBaud is 'enabled', a port may autobaud to values different from the set values for speed, parity, and character size. As a result a network management system may temporarily observe values different from what was previously set." Stewart [Page 8] RFC 1659 RS-232-like MIB July 1994 ::= { rs232AsyncPortEntry 5 } rs232AsyncPortParityErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with a parity error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 6 } rs232AsyncPortFramingErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with a framing error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 7 } rs232AsyncPortOverrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of characters with an overrun error, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232AsyncPortEntry 8 } -- RS-232-like Synchronous Port Table rs232SyncPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232SyncPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of asynchronous port entries. Entries need not exist for synchronous ports." ::= { rs232 4 } rs232SyncPortEntry OBJECT-TYPE SYNTAX Rs232SyncPortEntry MAX-ACCESS not-accessible STATUS current Stewart [Page 9] RFC 1659 RS-232-like MIB July 1994 DESCRIPTION "Status and parameter values for a synchronous port." INDEX { rs232SyncPortIndex } ::= { rs232SyncPortTable 1 } Rs232SyncPortEntry ::= SEQUENCE { rs232SyncPortIndex InterfaceIndex, rs232SyncPortClockSource INTEGER, rs232SyncPortFrameCheckErrs Counter32, rs232SyncPortTransmitUnderrunErrs Counter32, rs232SyncPortReceiveOverrunErrs Counter32, rs232SyncPortInterruptedFrames Counter32, rs232SyncPortAbortedFrames Counter32, rs232SyncPortRole INTEGER, rs232SyncPortEncoding INTEGER, rs232SyncPortRTSControl INTEGER, rs232SyncPortRTSCTSDelay Integer32, rs232SyncPortMode INTEGER, rs232SyncPortIdlePattern INTEGER, rs232SyncPortMinFlags Integer32 } rs232SyncPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each port. Its value is the same as rs232PortIndex for the port." ::= { rs232SyncPortEntry 1 } Stewart [Page 10] RFC 1659 RS-232-like MIB July 1994 rs232SyncPortClockSource OBJECT-TYPE SYNTAX INTEGER { internal(1), external(2), split(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Source of the port's bit rate clock. 'split' means the tranmit clock is internal and the receive clock is external." ::= { rs232SyncPortEntry 2 } rs232SyncPortFrameCheckErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames with an invalid frame check sequence, input from the port since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 3 } rs232SyncPortTransmitUnderrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be transmitted on the port since system re-initialization and while the port state was 'up' or 'test' because data was not available to the transmitter in time." ::= { rs232SyncPortEntry 4 } rs232SyncPortReceiveOverrunErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames that failed to be received on the port since system re-initialization and while the port state was 'up' or 'test' because the receiver did not accept the data in time." ::= { rs232SyncPortEntry 5 } rs232SyncPortInterruptedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Stewart [Page 11] RFC 1659 RS-232-like MIB July 1994 DESCRIPTION "Total number of frames that failed to be received or transmitted on the port due to loss of modem signals since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 6 } rs232SyncPortAbortedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames aborted on the port due to receiving an abort sequence since system re-initialization and while the port state was 'up' or 'test'." ::= { rs232SyncPortEntry 7 } rs232SyncPortRole OBJECT-TYPE SYNTAX INTEGER { dte(1), dce(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The role the device is playing that is using this port. dte means the device is performing the role of data terminal equipment dce means the device is performing the role of data circuit-terminating equipment." DEFVAL { dce } ::= { rs232SyncPortEntry 8 } rs232SyncPortEncoding OBJECT-TYPE SYNTAX INTEGER { nrz(1), nrzi(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The bit stream encoding technique that is in effect for this port. nrz for Non-Return to Zero encoding nrzi for Non-Return to Zero Inverted encoding." DEFVAL { nrz } ::= { rs232SyncPortEntry 9 } rs232SyncPortRTSControl OBJECT-TYPE SYNTAX INTEGER { controlled(1), constant(2) } MAX-ACCESS read-write STATUS current DESCRIPTION Stewart [Page 12] RFC 1659 RS-232-like MIB July 1994 "The method used to control the Request To Send (RTS) signal. controlled when the DTE is asserts RTS each time data needs to be transmitted and drops RTS at some point after data transmission begins. If rs232SyncPortRole is 'dte', the RTS is an output signal. The device will issue a RTS and wait for a CTS from the DCE before starting to transmit. If rs232SyncPortRole is 'dce', the RTS is an input signal. The device will issue a CTS only after having received RTS and waiting the rs232SyncPortRTSCTSDelay interval. constant when the DTE constantly asserts RTS." DEFVAL { constant } ::= { rs232SyncPortEntry 10 } rs232SyncPortRTSCTSDelay OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The interval (in milliseconds) that the DCE must wait after it sees RTS asserted before asserting CTS. This object exists in support of older synchronous devices that cannot recognize CTS within a certain interval after it asserts RTS." DEFVAL { 0 } ::= { rs232SyncPortEntry 11 } rs232SyncPortMode OBJECT-TYPE SYNTAX INTEGER { fdx(1), hdx(2), simplex-receive(3), simplex-send(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The mode of operation of the port with respect to the direction and simultaneity of data transfer. Stewart [Page 13] RFC 1659 RS-232-like MIB July 1994 fdx when frames on the data link can be transmitted and received at the same time hdx when frames can either be received from the data link or transmitted onto the data link but not at the same time. simplex-receive when frames can only be received on this data link. simplex-send when frames can only be sent on this data link." DEFVAL { fdx } ::= { rs232SyncPortEntry 12 } rs232SyncPortIdlePattern OBJECT-TYPE SYNTAX INTEGER { mark(1), space(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The bit pattern used to indicate an idle line." DEFVAL { space } ::= { rs232SyncPortEntry 13 } rs232SyncPortMinFlags OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum number of flag patterns this port needs in order to recognize the end of one frame and the start of the next. Plausible values are 1 and 2." DEFVAL { 2 } ::= { rs232SyncPortEntry 14 } -- Input Signal Table rs232InSigTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232InSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port input control signal entries implemented and visible to the software on the port, and useful to monitor." Stewart [Page 14] RFC 1659 RS-232-like MIB July 1994 ::= { rs232 5 } rs232InSigEntry OBJECT-TYPE SYNTAX Rs232InSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Input control signal status for a hardware port." INDEX { rs232InSigPortIndex, rs232InSigName } ::= { rs232InSigTable 1 } Rs232InSigEntry ::= SEQUENCE { rs232InSigPortIndex InterfaceIndex, rs232InSigName INTEGER, rs232InSigState INTEGER, rs232InSigChanges Counter32 } rs232InSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of rs232PortIndex for the port to which this entry belongs." ::= { rs232InSigEntry 1 } rs232InSigName OBJECT-TYPE SYNTAX INTEGER { rts(1), cts(2), dsr(3), dtr(4), ri(5), dcd(6), sq(7), srs(8), srts(9), scts(10), sdcd(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal, as follows: rts Request to Send cts Clear to Send dsr Data Set Ready dtr Data Terminal Ready ri Ring Indicator dcd Received Line Signal Detector sq Signal Quality Detector Stewart [Page 15] RFC 1659 RS-232-like MIB July 1994 srs Data Signaling Rate Selector srts Secondary Request to Send scts Secondary Clear to Send sdcd Secondary Received Line Signal Detector " REFERENCE "EIA Standard RS-232-C, August 1969." ::= { rs232InSigEntry 2 } rs232InSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { rs232InSigEntry 3 } rs232InSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { rs232InSigEntry 4 } -- Output Signal Table rs232OutSigTable OBJECT-TYPE SYNTAX SEQUENCE OF Rs232OutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port output control signal entries implemented and visible to the software on the port, and useful to monitor." ::= { rs232 6 } rs232OutSigEntry OBJECT-TYPE SYNTAX Rs232OutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Output control signal status for a hardware port." INDEX { rs232OutSigPortIndex, rs232OutSigName } ::= { rs232OutSigTable 1 } Stewart [Page 16] RFC 1659 RS-232-like MIB July 1994 Rs232OutSigEntry ::= SEQUENCE { rs232OutSigPortIndex InterfaceIndex, rs232OutSigName INTEGER, rs232OutSigState INTEGER, rs232OutSigChanges Counter32 } rs232OutSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of rs232PortIndex for the port to which this entry belongs." ::= { rs232OutSigEntry 1 } rs232OutSigName OBJECT-TYPE SYNTAX INTEGER { rts(1), cts(2), dsr(3), dtr(4), ri(5), dcd(6), sq(7), srs(8), srts(9), scts(10), sdcd(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal, as follows: rts Request to Send cts Clear to Send dsr Data Set Ready dtr Data Terminal Ready ri Ring Indicator dcd Received Line Signal Detector sq Signal Quality Detector srs Data Signaling Rate Selector srts Secondary Request to Send scts Secondary Clear to Send sdcd Secondary Received Line Signal Detector " REFERENCE "EIA Standard RS-232-C, August 1969." ::= { rs232OutSigEntry 2 } rs232OutSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } Stewart [Page 17] RFC 1659 RS-232-like MIB July 1994 MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { rs232OutSigEntry 3 } rs232OutSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { rs232OutSigEntry 4 } -- conformance information rs232Conformance OBJECT IDENTIFIER ::= { rs232 7 } rs232Groups OBJECT IDENTIFIER ::= { rs232Conformance 1 } rs232Compliances OBJECT IDENTIFIER ::= { rs232Conformance 2 } -- compliance statements rs232Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have RS-232-like hardware interfaces." MODULE -- this module MANDATORY-GROUPS { rs232Group } GROUP rs232AsyncGroup DESCRIPTION "The Asynch group is mandatory only for those SNMPv2 entities which have asynchronous interfaces Rs-232-like." GROUP rs232SyncGroup DESCRIPTION "The Synch group is mandatory only for those SNMPv2 entities which have synchronous interfaces Rs-232-like." ::= { rs232Compliances 1 } Stewart [Page 18] RFC 1659 RS-232-like MIB July 1994 -- units of conformance rs232Group OBJECT-GROUP OBJECTS { rs232Number, rs232PortIndex, rs232PortType, rs232PortInSigNumber, rs232PortOutSigNumber, rs232PortInSpeed, rs232PortOutSpeed, rs232PortInFlowType, rs232PortOutFlowType, rs232InSigPortIndex, rs232InSigName, rs232InSigState, rs232InSigChanges, rs232OutSigPortIndex, rs232OutSigName, rs232OutSigState, rs232OutSigChanges } STATUS current DESCRIPTION "A collection of objects providing information applicable to all RS-232-like interfaces." ::= { rs232Groups 1 } rs232AsyncGroup OBJECT-GROUP OBJECTS { rs232AsyncPortIndex, rs232AsyncPortBits, rs232AsyncPortStopBits, rs232AsyncPortParity, rs232AsyncPortAutobaud, rs232AsyncPortParityErrs, rs232AsyncPortFramingErrs, rs232AsyncPortOverrunErrs } STATUS current DESCRIPTION "A collection of objects providing information applicable to asynchronous RS-232-like interfaces." ::= { rs232Groups 2 } rs232SyncGroup OBJECT-GROUP OBJECTS { rs232SyncPortIndex, rs232SyncPortClockSource, rs232SyncPortFrameCheckErrs, rs232SyncPortTransmitUnderrunErrs, rs232SyncPortReceiveOverrunErrs, rs232SyncPortInterruptedFrames, rs232SyncPortAbortedFrames } STATUS current DESCRIPTION "A collection of objects providing information applicable to synchronous RS-232-like interfaces." ::= { rs232Groups 3 } rs232SyncSDLCGroup OBJECT-GROUP OBJECTS { rs232SyncPortRole, rs232SyncPortEncoding, rs232SyncPortRTSControl, rs232SyncPortRTSCTSDelay, rs232SyncPortMode, rs232SyncPortIdlePattern, Stewart [Page 19] RFC 1659 RS-232-like MIB July 1994 rs232SyncPortMinFlags } STATUS current DESCRIPTION "A collection of objects providing information applicable to synchronous RS-232-like interfaces running SDLC." ::= { rs232Groups 4 } END 5. Acknowledgements This memo was produced by the IETF Character MIB Working Group. 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] 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. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] Stewart, B., "Definitions of Managed Objects for Character Stream Devices using SMIv2", RFC 1658, Xyplex, Inc., July 1994. [7] Kastenholz, F., "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, FTP Software, Inc., June 1993. Stewart [Page 20] RFC 1659 RS-232-like MIB July 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Phone: 508-952-4816 Fax: 508-952-4887 EMail: rlstewart@eng.xyplex.com Stewart [Page 21] snmp-mibs-downloader-1.1/mibrfcs/rfc1660.txt0000644000000000000000000004062011402176071015560 0ustar Network Working Group B. Stewart Request for Comments: 1660 Xyplex, Inc. Obsoletes: 1318 July 1994 Category: Standards Track Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2 Status of this Memo This document specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Table of Contents 1. Introduction ............................................... 1 2. The SNMPv2 Network Management Framework .................... 1 2.1 Object Definitions ........................................ 2 3. Overview ................................................... 2 3.1 Relationship to Interface MIB ............................. 2 4. Definitions ................................................ 3 5. Acknowledgements ........................................... 9 6. References ................................................. 9 7. Security Considerations .................................... 10 8. Author's Address ........................................... 10 1. Introduction This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer-like devices. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. Stewart [Page 1] RFC 1660 Parallel-printer-like MIB July 1994 o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. 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 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 Parallel-printer-like Hardware Device MIB applies to interface ports that would most probably support the Character MIB. The most common example is Centronics-like printer port. The Parallel-printer-like Hardware Device MIB is mandatory for all systems that have such a hardware port supporting services managed through some other MIB. The Parallel-printer-like Hardware Port MIB includes Centronics-like and Data-Products-like parallel physical links with a similar set of control signals. The MIB contains objects that relate to physical layer connections. The MIB comprises one base object and three tables, detailed in the following sections. The tables contain objects for ports and input and output control signals. 3.1. Relationship to Interface MIB The Parallel-printer-like MIB is one of many MIBs designed for layered use as described in the Interface MIB [5]. In most implementations where it is present, it will be in the lowest interface sublayer, that is, the Parallel-printer-like MIB represents the physical layer, providing service to higher layers such as the Stewart [Page 2] RFC 1660 Parallel-printer-like MIB July 1994 Character MIB [6]. Although it is unlikely that a parallel printer port will actually be used as a network interface, which is the intent of the Interface MIB, the Parallel-printer-like MIB is closely connected to the Character MIB, which can share hardware interfaces with network operation, and relate to the RS-232 MIB [7]. The Interface MIB's ifTestTable and ifRcvAddressTable are not relevant to the Parallel-printer-like MIB. The Parallel-printer-like MIB is relevant for ifType values para(34) and perhaps others. The Parallel-printer-like MIB requires the conformance groups ifGeneralGroup, and ifFixedLengthGroup. Usefulness of error counters in this MIB depends on the octet counters in ifFixedLengthGroup. 4. Definitions PARALLEL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI InterfaceIndex FROM IF-MIB transmission FROM RFC1213-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; para MODULE-IDENTITY LAST-UPDATED "9405261700Z" ORGANIZATION "IETF Character MIB Working Group" CONTACT-INFO " Bob Stewart Postal: Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Tel: 508-952-4816 Fax: 508-952-4887 E-mail: rlstewart@eng.xyplex.com" Stewart [Page 3] RFC 1660 Parallel-printer-like MIB July 1994 DESCRIPTION "The MIB module for Parallel-printer-like hardware devices." ::= { transmission 34 } -- Generic Parallel-printer-like information paraNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ports (regardless of their current state) in the Parallel-printer-like port table." ::= { para 1 } -- the Parallel-printer-like Port table paraPortTable OBJECT-TYPE SYNTAX SEQUENCE OF ParaPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value of paraNumber." ::= { para 2 } paraPortEntry OBJECT-TYPE SYNTAX ParaPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for a port." INDEX { paraPortIndex } ::= { paraPortTable 1 } ParaPortEntry ::= SEQUENCE { paraPortIndex InterfaceIndex, paraPortType INTEGER, paraPortInSigNumber Integer32, paraPortOutSigNumber Integer32 } Stewart [Page 4] RFC 1660 Parallel-printer-like MIB July 1994 paraPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the port. By convention and if possible, hardware port numbers map directly to external connectors. The value for each port must remain constant at least from one re-initialization of the network management agent to the next." ::= { paraPortEntry 1 } paraPortType OBJECT-TYPE SYNTAX INTEGER { other(1), centronics(2), dataproducts(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's hardware type." ::= { paraPortEntry 2 } paraPortInSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input signals for the port in the input signal table (paraPortInSigTable). The table contains entries only for those signals the software can detect and that are useful to observe." ::= { paraPortEntry 3 } paraPortOutSigNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output signals for the port in the output signal table (paraPortOutSigTable). The table contains entries only for those signals the software can assert and that are useful to observe." ::= { paraPortEntry 4 } Stewart [Page 5] RFC 1660 Parallel-printer-like MIB July 1994 -- Parallel-printer-like Input Signal Table paraInSigTable OBJECT-TYPE SYNTAX SEQUENCE OF ParaInSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port input control signal entries." ::= { para 3 } paraInSigEntry OBJECT-TYPE SYNTAX ParaInSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Input control signal status for a hardware port." INDEX { paraInSigPortIndex, paraInSigName } ::= { paraInSigTable 1 } ParaInSigEntry ::= SEQUENCE { paraInSigPortIndex InterfaceIndex, paraInSigName INTEGER, paraInSigState INTEGER, paraInSigChanges Counter32 } paraInSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of paraPortIndex for the port to which this entry belongs." ::= { paraInSigEntry 1 } paraInSigName OBJECT-TYPE SYNTAX INTEGER { power(1), online(2), busy(3), paperout(4), fault(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal." ::= { paraInSigEntry 2 } Stewart [Page 6] RFC 1660 Parallel-printer-like MIB July 1994 paraInSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { paraInSigEntry 3 } paraInSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { paraInSigEntry 4 } -- Output Signal Table paraOutSigTable OBJECT-TYPE SYNTAX SEQUENCE OF ParaOutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port output control signal entries." ::= { para 4 } paraOutSigEntry OBJECT-TYPE SYNTAX ParaOutSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Output control signal status for a hardware port." INDEX { paraOutSigPortIndex, paraOutSigName } ::= { paraOutSigTable 1 } ParaOutSigEntry ::= SEQUENCE { paraOutSigPortIndex InterfaceIndex, paraOutSigName INTEGER, paraOutSigState INTEGER, paraOutSigChanges Counter32 } Stewart [Page 7] RFC 1660 Parallel-printer-like MIB July 1994 paraOutSigPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of paraPortIndex for the port to which this entry belongs." ::= { paraOutSigEntry 1 } paraOutSigName OBJECT-TYPE SYNTAX INTEGER { power(1), online(2), busy(3), paperout(4), fault(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of a hardware signal." ::= { paraOutSigEntry 2 } paraOutSigState OBJECT-TYPE SYNTAX INTEGER { none(1), on(2), off(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current signal state." ::= { paraOutSigEntry 3 } paraOutSigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the signal has changed from 'on' to 'off' or from 'off' to 'on'." ::= { paraOutSigEntry 4 } -- conformance information paraConformance OBJECT IDENTIFIER ::= { para 5 } paraGroups OBJECT IDENTIFIER ::= { paraConformance 1 } paraCompliances OBJECT IDENTIFIER ::= { paraConformance 2 } Stewart [Page 8] RFC 1660 Parallel-printer-like MIB July 1994 -- compliance statements paraCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have Parallel-printer-like hardware interfaces." MODULE -- this module MANDATORY-GROUPS { paraGroup } ::= { paraCompliances 1 } -- units of conformance paraGroup OBJECT-GROUP OBJECTS { paraNumber, paraPortIndex, paraPortType, paraPortInSigNumber, paraPortOutSigNumber, paraInSigPortIndex, paraInSigName, paraInSigState, paraInSigChanges, paraOutSigPortIndex, paraOutSigName, paraOutSigState, paraOutSigChanges } STATUS current DESCRIPTION "A collection of objects providing information applicable to all Parallel-printer-like interfaces." ::= { paraGroups 1 } END 5. Acknowledgements This memo was produced by the IETF Character MIB Working Group. 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] 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. Stewart [Page 9] RFC 1660 Parallel-printer-like MIB July 1994 [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] Stewart, B., "Definitions of Managed Objects for Character Stream Devices using SMIv2", RFC 1658, Xyplex, Inc., July 1994. [7] Stewart, B., "Definitions of Managed Objects for RS-232-like Devices using SMIv2", RFC 1659, Xyplex, Inc., July 1994. 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Bob Stewart Xyplex, Inc. 295 Foster Street Littleton, MA 01460 Phone: 508-952-4816 Fax: 508-952-4887 EMail: rlstewart@eng.xyplex.com Stewart [Page 10] snmp-mibs-downloader-1.1/mibrfcs/rfc1666.txt0000644000000000000000000040636111402176071015576 0ustar Network Working Group Z. Kielczewski Request for Comments: 1666 Eicon Technology Corporation Obsoletes: 1665 D. Kostick Category: Standards Track Bell Communications Research K. Shih Novell Editors August 1994 Definitions of Managed Objects for SNA NAUs using SMIv2 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 ................................................ 2 2. The SNMPv2 Network Management Framework ..................... 2 2.1 Object Definitions ......................................... 2 3. Overview .................................................... 3 3.1 Applying MIB II to managing SNA NAUs ....................... 4 3.2 SNANAU MIB Structure ....................................... 4 3.2.1 snaNode group ............................................ 5 3.2.2 snaLu group .............................................. 6 3.2.3 snaMgtTools group ........................................ 7 3.2.4 Conformance statement .................................... 7 3.3 SNANAU MIB special feature ................................. 7 3.3.1 Row Creation mechanism ................................... 8 3.3.2 State Diagrams ........................................... 8 4. Object Definitions .......................................... 9 5. Acknowledgments ............................................. 67 6. References .................................................. 67 7. Security Considerations ..................................... 68 8. Authors' Addresses .......................................... 68 Kielczewski, Kostick & Shih [Page 1] RFC 1666 SNANAU MIB August 1994 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network. NAUs are the origination or destination points for SNA data streams. This memo identifies managed objects for PU Type 1.0, 2.0 and Type 2.1 and LU Type 0, 1, 2, 3, 4, 7. The generic objects defined here can also be used to manage LU 6.2 and any LU-LU session. The SNA terms and overall architecture are documented in [1]. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [2] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [3] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [4] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [5] which defines the protocol used for network access to managed objects. 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 (RFC 1442 [2]). 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. Kielczewski, Kostick & Shih [Page 2] RFC 1666 SNANAU MIB August 1994 3. Overview This document identifies the proposed set of objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. In this document, the name "Node" is used to describe SNA Node Type 1.0, 2.0 and Type 2.1 and the name "LU" is used to describe Logical Unit of Type 0, 1, 2, 3, 4, 7 and 6.2. Note however that only objects common to all PU and LU types are covered here and LU 6.2 specific objects are not included in this MIB module. Highlights of the management functions supported by the SNANAU MIB module include the following: o Creation/deletion of Nodes and LUs via the RowStatus objects in the snaNodeAdminTable and in the snaLuAdminTable. o Creation/deletion of table entries associating Node instances with link instances via the RowStatus object in the snaNodeLinkAdminTable o Activation/Deactivation of Nodes via the AdminState object in the snaNodeAdminTable o Deactivation of sessions via the AdminState object in the snaLuSessnTable o Monitoring and modification of parameters related to Nodes, LUs, and Node/link associations o Monitoring of session operational parameters o PU2.0 operational statistics o Session operational statistics o RTM statistics o Traps for: + Node state change + Node activation failure + LU state change + LU session BIND failure Kielczewski, Kostick & Shih [Page 3] RFC 1666 SNANAU MIB August 1994 This MIB module does not support: o creation of links, o activation or deactivation of LUs, nor o activation of sessions. 3.1. Applying MIB II to managing SNA NAUs This section identifies how MIB II objects, specifically the MIB II system group will be used in SNMP-based management of SNA NAUs. The MIB II system group applies to the SNMP Agent. The following object is from the MIB II system group: sysUpTime: clock in the SNMP Agent/proxy-Agent; expressed in TimeTicks (1/100s of a seconds). This MIB module uses the TimeStamp TEXTUAL-CONVENTION which is defined in the SNMPv2 Textual Conventions (RFC 1443 [6]) as "the value of MIB II's sysUpTime object when a specific occurrence happens." The specific occurrences related to SNA NAU management are defined in this MIB module. 3.2. SNANAU MIB Structure The SNANAU MIB module contains three groups of objects: o snaNode - objects related to Node configuration, monitoring and control. o snaLu - objects related to LU definition, monitoring and control. o snaMgtTools - objects related to specific management tools well known in SNA environment. These groups are described below in more detail. The objects related to PUs and LUs are organized into two types of tables: the Admin and Oper tables. The "Admin" table contains parameters which are used by a Management Station to affect the operation of the SNA service. Some parameters are used to initialize and configure the SNA service at the next startup, while others can take effect immediately. A Management Station can dynamically define SNA resources (PUs, LUs) by creating new entries in the Admin table. It uses a special object, AdminState, Kielczewski, Kostick & Shih [Page 4] RFC 1666 SNANAU MIB August 1994 to control the desired state of a defined PU or LU Session resource. Note that this MIB does not allow the manipulation of an LU's operational state. The "Oper" table is an extension (augment) of the corresponding Admin table. It contains objects which correspond to the values of parameters currently used by the SNA system. 3.2.1. snaNode group The snaNode group consists of the following tables: 1) snaNodeAdminTable - This table contains objects which describe the configuration parameters of an SNA Node. Link-specific configuration objects are contained in a separate MIB module (e.g., the SNA DLC MIB module) corresponding to link type. Entries in this table can be created, modified and deleted by either an Agent or a Management Station. The snaNodeAdminRowStatus object describes the status of an entry and is used to change the status of that entry. The snaNodeAdminState object describes the desired operational state of a Node and is used to change the operational state of a Node. How an Agent or a Management Station obtains the initial value of each object at creation time is an implementation specific issue not addressed in this memo. For each entry in the snaNodeAdminTable, there is a corresponding entry in the snaNodeOperTable. While the objects in this table describe the desired or configured operational values of the SNA Node, the actual runtime values are contained in snaNodeOperTable. 2) snaNodeOperTable - Each row contains runtime and operational state variables for a Node. It is an extension of snaNodeAdminTable and as such uses the same index. The rows in this table are created by an Agent as soon as the entry in the Admin Table become 'active'. The entries in this table cannot be modified by a Management Station. 3) snaPu20StatsTable - Each row contains statistics variables (counters) for a PU 2.0. The entries in this table are indexed by snaNodeAdminIndex. The rows in this table are created by an Agent as soon as the corresponding entry in the snaNodeAdminTable becomes 'active'. Kielczewski, Kostick & Shih [Page 5] RFC 1666 SNANAU MIB August 1994 4) snaNodeLinkAdminTable - This table contains all references to link- specific tables. If a Node is configured with multiple links, then it will have multiple entries in this table. The entries in this table can be generated initially, after startup of SNA service, by the Agent which uses information from Node configuration file. Subsequent modifications of parameters, creation of new Node link entries and deletion of entries is possible. The modifications to this table can be saved in the Node configuration file for the next startup (i.e., restart or next initialization) of SNA service, but the mechanism for this function is not defined in this memo. Each entry contains the configuration information that associates a Node instance to one link instance. The entries are indexed by snaNodeAdminIndex and snaNodeLinkAdminIndex. 5) snaNodeLinkOperTable - This table contains all references to link- specific tables for operational parameters. If the Node is configured for multiple links, then it will have multiple entries in this table. This table augments the snaNodeLinkAdminTable. 6) snaNodeTraps - Two traps are defined for Nodes. The snaNodeStateChangeTrap indicates that the operational state of a Node has changed. The snaNodeActFailTrap indicates the failure of ACTPU received from host. 3.2.2. snaLu group The snaLu group consists of the following tables: 1) snaLuAdminTable - Table containing LU configuration information. The rows in this table can be created and deleted by a Management Station. Only objects which are common to all types of LUs are included in this table. The entries are indexed by Node and LU indices. 2) snaLuOperTable - Table containing dynamic runtime information and control variables relating to LUs. Only objects which are common to all types of LUs are included in this table. This table augments the snaLuAdminTable. 3) snaLuSessnTable - This is a table containing objects which describe the operational state of LU-LU sessions. Only objects which are common to all types of LU-LU sessions are included in this table. When a session's snaLuSessnOperState value changes to entry in the session table is created by the Agent. When the snaLuSessionOperState value changes to will be removed from the session table by the Agent. Entries are indexed by Node, local LU, remote LU and session indices. Kielczewski, Kostick & Shih [Page 6] RFC 1666 SNANAU MIB August 1994 4) snaLuSessnStatsTable - Table containing dynamic statistics information relating to LU-LU sessions. The entries in this table augment the entries in the snaLuSessnTable and cannot be created by a Management Station. 5) snaLuTraps - Two traps are defined for LUs. The snaLuStateChangeTrap indicates that the operational state of an LU has changed. The snaLuSessnBindFailTrap indicates the failure of a BIND request. 3.2.3. snaMgtTools group This is an optional group. The snaMgtTools group consists of the following table: 1) snaLuRtmTable - Each row contains Response Time Monitor (RTM) variables for an LU. The table is indexed by Node and LU indices. Entries correspond to LU 2 entries in the snaLuAdminTable. A Management Station can read collection of RTM statistics for a given LU. 3.2.4. Conformance statement Compliance of the SNMPv2 management entity to the SNANAU MIB is defined in terms of following conformance units called groups. Unconditionally mandatory groups: snaNodeGroup, snaLuGroup, snaSessionGroup. Conditionally mandatory groups: snaPu20Group - mandatory only for those entities which implement PU type 2.0. The snaMgtToolsRtmGroup - mandatory only for those entities which implement LU type 2 and RTM. Refinement of requirements for objects access: an Agent which does not implement row creation for snaNodeAdminTable snaNodeLinkAdminTable and snaLuAdminTable must at least support object modification requests (i.e., read-write access instead of read-create). 3.3. SNANAU MIB special feature This section describes the mechanism used for row creation in the Admin tables and also presents critical state transitions for PUs, LUs and Sessions. Kielczewski, Kostick & Shih [Page 7] RFC 1666 SNANAU MIB August 1994 3.3.1. Row Creation mechanism The row creation mechanism for the Admin tables in this MIB module is based on the use of the RowStatus object. Restriction of some operations for specific tables are described in each table. In particular, before accepting the 'destroy' value for an entry, an Agent has to verify the operational state of the corresponding entry in the Oper table. 3.3.2. State Diagrams The following state diagram models the state transitions for Nodes. When a row is created by a Management Station, an Agent creates the Oper table entry for that Node with the OperState equal to 'inactive'. An Agent cannot accept any operations for that Node until the RowStatus is set to 'active'. OperState -> inactive active waiting stopping --------------I--------------I--------------I--------------I--------- AdminState: I I I I active I active I active I waiting I no I I I I inactive I inactive I stopping I inactive I stopping I or inactive I The following state diagram models state transitions for Sessions. When a session goes to the 'unbound' state [1], the corresponding entry will be removed from the Session table by the Agent. OperState -> unbound pendingBind bound pendingUnbind --------------I--------------I--------------I----------I-------------- AdminState: I I I I bound I no I no I no I no I I I I unbound I unbound I unbound I unbound I unbound Kielczewski, Kostick & Shih [Page 8] RFC 1666 SNANAU MIB August 1994 4. Object Definitions SNA-NAU-MIB DEFINITIONS ::= BEGIN -- This MIB module contains objects necessary -- for management of the following SNA devices: PU types 1.0, 2.0, 2.1 -- and LU types 0, 1, 2, 3, 4, 7. It also contains generic objects -- which can be used to manage LU 6.2. -- Naming conventions in this document: -- The following names are used in object descriptors according to -- SNA conventions. -- The name 'PU' or 'Node' is used to describe Node type 1.0, 2.0 or -- 2.1. -- The name 'LU' is used to describe Logical Unit of type 0,1,2,3, -- 4,7 or 6.2. IMPORTS DisplayString, RowStatus, TimeStamp, InstancePointer FROM SNMPv2-TC Counter32, Gauge32, Integer32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snanauMIB MODULE-IDENTITY LAST-UPDATED "9405120900Z" ORGANIZATION "IETF SNA NAU MIB Working Group" CONTACT-INFO " Zbigniew Kielczewski Eicon Technology Inc. 2196 32nd Avenue Lachine, Que H8T 3H7 Canada Tel: 1 514 631 2592 E-mail: zbig@eicon.qc.ca Deirdre Kostick Bellcore 331 Newman Springs Road Red Bank, NJ 07701 Tel: 1 908 758 2642 Kielczewski, Kostick & Shih [Page 9] RFC 1666 SNANAU MIB August 1994 E-mail: dck2@mail.bellcore.com Kitty Shih (editor) Novell 890 Ross Drive Sunnyvale, CA 94089 Tel: 1 408 747 4305 E-mail: kmshih@novell.com" DESCRIPTION "This is the MIB module for objects used to manage SNA devices." ::= { mib-2 34 } -- The SNANAU MIB module contains an objects part and a conformance part. -- Objects are organized into the following groups: -- (1)snaNode group, -- (2)snaLU group, -- (3)snaMgtTools group. snanauObjects OBJECT IDENTIFIER ::= { snanauMIB 1 } snaNode OBJECT IDENTIFIER ::= { snanauObjects 1 } snaLu OBJECT IDENTIFIER ::= { snanauObjects 2 } snaMgtTools OBJECT IDENTIFIER ::= { snanauObjects 3} -- *************************************************************** -- snaNode group -- -- It contains Managed Objects related to any type of Node and -- some specific objects for Node Type 2.0. -- *************************************************************** -- *************************************************************** -- The following table contains generic Node configuration -- parameters. -- *************************************************************** snaNodeAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects which describe the configuration parameters for an SNA Node. Link specific configuration objects are contained in a separate MIB module (e.g., SNA DLC MIB) Kielczewski, Kostick & Shih [Page 10] RFC 1666 SNANAU MIB August 1994 corresponding to the link type. The table snaNodeAdminLinkTable contains objects which identify the relationship between node instances and link instances. The entries (i.e., rows) in this table can be created by either an Agent or a Management Station. The Management Station can do this through setting the appropriate value in the snaNodeAdminRowStatus. The snaNodeAdminRowStatus object describes the status of an entry and is used to change the status of an entry. The entry is deleted by an Agent based on the value of the snaNodeAdminRowStatus. The snaNodeAdminState object describes the desired operational state of a Node and is used to change the operational state of a Node. For example, such information may be obtained from a configuration file. How an Agent or a Management Station obtains the initial value of each object at creation time is an implementation specific issue. For each entry in this table, there is a corresponding entry in the snaNodeOperTable. While the objects in this table describe the desired or configured operational values of the SNA Node, the actual runtime values are contained in snaNodeOperTable." ::= { snaNode 1 } snaNodeAdminEntry OBJECT-TYPE SYNTAX SnaNodeAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry contains the configuration parameters for one SNA Node instance. The objects in the entry have read-create access. An entry can be created, modified or deleted. The object snaNodeAdminRowStatus is used (i.e., set) to create or delete a row entry." INDEX { snaNodeAdminIndex } ::= { snaNodeAdminTable 1 } SnaNodeAdminEntry ::= SEQUENCE { snaNodeAdminIndex Kielczewski, Kostick & Shih [Page 11] RFC 1666 SNANAU MIB August 1994 Integer32, snaNodeAdminName DisplayString, snaNodeAdminType INTEGER, snaNodeAdminXidFormat INTEGER, snaNodeAdminBlockNum DisplayString, snaNodeAdminIdNum DisplayString, snaNodeAdminEnablingMethod INTEGER, snaNodeAdminLuTermDefault INTEGER, snaNodeAdminMaxLu Integer32, snaNodeAdminHostDescription DisplayString, snaNodeAdminStopMethod INTEGER, snaNodeAdminState INTEGER, snaNodeAdminRowStatus RowStatus } snaNodeAdminIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index used to uniquely identify each Node instance. If an Agent creates the entry, then it will assign this number otherwise a Management Station generates a random number when it reserves the entry for creation." ::= { snaNodeAdminEntry 1 } snaNodeAdminName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..17)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the desired name of the Node for use during Node activation. In Type 2.1 networks, this is a fully-qualified name, meaning that the Node name is preceded by the NetId (if Kielczewski, Kostick & Shih [Page 12] RFC 1666 SNANAU MIB August 1994 present) with a period as the delimiter. A write operation to this object will not change the operational value reflected in snaNodeOperName until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaNodeAdminEntry 2 } snaNodeAdminType OBJECT-TYPE SYNTAX INTEGER { other(1), pu10(2), pu20(3), t21len(4), endNode(5), networkNode(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the type of SNA Node. A write operation to this object will not change the operational value reflected in snaNodeOperType until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaNodeAdminEntry 3 } snaNodeAdminXidFormat OBJECT-TYPE SYNTAX INTEGER { format0(1), format1(2), format3(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the type of XID format used for this Node. Note that there is no format type 2. A write operation to this object will not change the operational value reflected in snaNodeOperAdminXidFormat until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaNodeAdminEntry 4 } Kielczewski, Kostick & Shih [Page 13] RFC 1666 SNANAU MIB August 1994 snaNodeAdminBlockNum OBJECT-TYPE SYNTAX DisplayString (SIZE(3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the block number for this Node instance. It is the first 3 hexadecimal digits of the SNA Node id. A write operation to this object will not change the operational value reflected in snaNodeOperBlockNum until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaNodeAdminEntry 5 } snaNodeAdminIdNum OBJECT-TYPE SYNTAX DisplayString (SIZE(5)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the ID number for this Node instance. This is the last 5 hexadecimal digits of the SNA Node id. A write operation to this object will not change the operational value reflected in snaNodeOperIdNum until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaNodeAdminEntry 6 } snaNodeAdminEnablingMethod OBJECT-TYPE SYNTAX INTEGER { other (1), startup (2), demand (3), onlyMS (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates how the Node should be activated for the first time. The values have the following meanings: other (1) - may be used for proprietary methods not listed in this enumeration, Kielczewski, Kostick & Shih [Page 14] RFC 1666 SNANAU MIB August 1994 startup (2) - at SNA services' initialization time (this is the default), demand (3) - only when LU is requested by application, or onlyMS (4) - by a Management Station only. A write operation to this object may immediately change the operational value reflected in snaNodeOperEnablingMethod depending on the Agent implementation. If the Agent implementation accepts immediate changes, then the behavior of the Node changes immediately and not only after the next system startup of the SNA services. An immediate change may only apply when the current value 'demand (3)' is changed to 'onlyMS (4)' and vice versa." ::= { snaNodeAdminEntry 7 } snaNodeAdminLuTermDefault OBJECT-TYPE SYNTAX INTEGER { unbind (1), termself (2), rshutd (3), poweroff(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the desired default method used to deactivate LUs for this Node For LU6.2s, 'unbind(1)' is the only valid value. unbind(1) - terminate the LU-LU session by sending an SNA UNBIND request. termself(2) - terminate the LU-LU session by sending an SNA TERM-SELF (Terminate Self) request on the SSCP-LU session. The SSCP will inform the remote session LU partner to send an UNBIND request to terminate the session. rshutd(3) - terminate the LU-LU session by sending an SNA RSHUTD (Request ShutDown) request to the remote session LU partner. The remote LU will then send an UNBIND request to terminate the session. poweroff(4) - terminate the LU-LU session by sending either an SNA LUSTAT (LU Status) request on the LU-LU session or an SNA NOTIFY request on the SSCP-LU session indicating that the LU has Kielczewski, Kostick & Shih [Page 15] RFC 1666 SNANAU MIB August 1994 been powered off. Sending both is also acceptable. The result should be that the remote session LU partner will send an UNBIND to terminate the session. The default behavior indicated by the value of this object may be overridden for an LU instance. The override is performed by setting the snaLuAdminTerm object instance in the snaLuAdminTable to the desired value. A write operation to this object may immediately change the operational value reflected in snaNodeOperLuTermDefault depending on the Agent implementation." ::= { snaNodeAdminEntry 8 } snaNodeAdminMaxLu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of LUs that may be activated for this Node. For PU2.1, this object refers to the number of dependent LUs. A write operation to this object will not change the operational value reflected in snaNodeOperMaxLu until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaNodeAdminEntry 9 } snaNodeAdminHostDescription OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value identifies the remote host associated with this Node. Since SSCP Id's may not be unique across hosts, the host description is required to uniquely identify the SSCP. This object is only applicable to PU2.0 type Nodes. If the remote host is unknown, then the value is the null string. A write operation to this object may immediately Kielczewski, Kostick & Shih [Page 16] RFC 1666 SNANAU MIB August 1994 change the operational value reflected in snaNodeOperHostDescription depending on the Agent implementation." ::= { snaNodeAdminEntry 10 } snaNodeAdminStopMethod OBJECT-TYPE SYNTAX INTEGER { other (1), normal (2), immed (3), force (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value indicates the desired method to be used by the Agent to stop a Node (i.e., change the Node's operational state to inactive(1) ). The values have the following meaning: other (1) - used for proprietary methods not listed in this enumeration. normal(2) - deactivate only when there is no more activity on this Node (i.e., all data flows have been completed and all sessions have been terminated). immed(3) - deactivate immediately regardless of current activities on this Node. Wait for deactivation responses (from remote Node) before changing the Node state to inactive. force(4) - deactivate immediately regardless of current activities on this Node. Do not wait for deactivation responses (from remote Node) before changing the Node state to inactive. A write operation to this object may immediately change the operational value reflected in snaNodeOperStopMethod depending on the Agent implementation." ::= { snaNodeAdminEntry 11 } snaNodeAdminState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2) } MAX-ACCESS read-create Kielczewski, Kostick & Shih [Page 17] RFC 1666 SNANAU MIB August 1994 STATUS current DESCRIPTION "The value indicates the desired operational state of the SNA Node. This object is used by the Management Station to activate or deactivate the Node. If the current value in snaNodeOperState is 'active (2)', then setting this object to 'inactive (1)' will initiate the Node shutdown process using the method indicated by snaNodeOperStopMethod. If the current value in snaNodeOperState is 'inactive (1)', then setting this object to 'active (2)' will initiate the Node's activation. A Management Station can always set this object to 'active (2)' irrespective of the value in the snaOperEnablingMethod." ::= { snaNodeAdminEntry 12 } snaNodeAdminRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by a Management Station to create or delete the row entry in the snaNodeAdminTable following the RowStatus textual convention. Upon successful creation of the row, an Agent automatically creates a corresponding entry in the snaNodeOperTable with snaNodeOperState equal to 'inactive (1)'. Row deletion can be Management Station or Agent initiated: (a) The Management Station can set the value to 'destroy (6)' only when the value of snaNodeOperState of this Node instance is 'inactive (1)'. The Agent will then delete the rows corresponding to this Node instance from the snaNodeAdminTable and the snaNodeOperTable. (b) The Agent detects that a row is in the 'notReady (3)' state for greater than a Kielczewski, Kostick & Shih [Page 18] RFC 1666 SNANAU MIB August 1994 default period of 5 minutes. (c) All rows with the snaNodeAdminRowStatus object's value of 'notReady (3)' will be removed upon the next initialization of the SNA services." ::= { snaNodeAdminEntry 13 } -- *************************************************************** -- The following object is updated when there is a change to -- the value of any object in the snaNodeAdminTable. -- *************************************************************** snaNodeAdminTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value indicates the timestamp (e.g., the Agent's sysUpTime value) of the last change made to any object in the snaNodeAdminTable, including row deletions/additions (e.g., changes to snaNodeAdminRowStatus values). This object can be used to reduce frequent retrievals of the snaNodeAdminTable by a Management Station. It is expected that a Management Station will periodically poll this object and compare its current value with the previous one. A difference indicates that some Node configuration information has been changed. Only then will the Management Station retrieve the entire table." ::= { snaNode 2 } -- *************************************************************** -- The following table contains Node operational parameters. -- *************************************************************** snaNodeOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the dynamic parameters which have read-only access. These objects reflect the actual status of the Node. The entries in this table cannot be created or modified by a Management Station. Kielczewski, Kostick & Shih [Page 19] RFC 1666 SNANAU MIB August 1994 This table augments the snaNodeAdminTable." ::= { snaNode 3 } snaNodeOperEntry OBJECT-TYPE SYNTAX SnaNodeOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry contains parameters which describe the state of one Node. The entries are created by the Agent. They have read-only access." AUGMENTS { snaNodeAdminEntry } ::= { snaNodeOperTable 1 } SnaNodeOperEntry ::= SEQUENCE { snaNodeOperName DisplayString, snaNodeOperType INTEGER, snaNodeOperXidFormat INTEGER, snaNodeOperBlockNum DisplayString, snaNodeOperIdNum DisplayString, snaNodeOperEnablingMethod INTEGER, snaNodeOperLuTermDefault INTEGER, snaNodeOperMaxLu Integer32, snaNodeOperHostDescription DisplayString, snaNodeOperStopMethod INTEGER, snaNodeOperState INTEGER, snaNodeOperHostSscpId OCTET STRING, snaNodeOperStartTime TimeStamp, snaNodeOperLastStateChange TimeStamp, snaNodeOperActFailures Counter32, snaNodeOperActFailureReason INTEGER } Kielczewski, Kostick & Shih [Page 20] RFC 1666 SNANAU MIB August 1994 snaNodeOperName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the current name of the Node. In Type 2.1 networks, this is a fully-qualified name, meaning that the Node name is preceded by the NetId (if present) with a period as the delimiter." ::= { snaNodeOperEntry 1 } snaNodeOperType OBJECT-TYPE SYNTAX INTEGER { other(1), pu10(2), pu20(3), t21LEN(4), endNode(5), networkNode(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the current type of the Node." ::= { snaNodeOperEntry 2 } snaNodeOperXidFormat OBJECT-TYPE SYNTAX INTEGER { format0 (1), format1 (2), format3 (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the type of XID format currently used for this Node. Note that there is no format type 2." ::= { snaNodeOperEntry 3 } snaNodeOperBlockNum OBJECT-TYPE SYNTAX DisplayString (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the block number for this Node instance. It is the first 3 hexadecimal digits Kielczewski, Kostick & Shih [Page 21] RFC 1666 SNANAU MIB August 1994 of the SNA Node id." ::= { snaNodeOperEntry 4 } snaNodeOperIdNum OBJECT-TYPE SYNTAX DisplayString (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the ID number for this Node instance. This is the last 5 hexadecimal digits of the SNA Node id." ::= { snaNodeOperEntry 5 } snaNodeOperEnablingMethod OBJECT-TYPE SYNTAX INTEGER { other (1), startup (2), demand (3), onlyMS (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value indicates how the Node is activated for the first time. The values have the following meanings: other (1) - not at boot time, LU activation or by a Management Station; startup (2) - at SNA services' initialization time (this is the default), demand (3) - only when LU is requested by application, onlyMS (4) - by a network Management Station only." ::= { snaNodeOperEntry 6 } snaNodeOperLuTermDefault OBJECT-TYPE SYNTAX INTEGER { unbind (1), termself (2), rshutd (3), poweroff (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the default method used to deactivate LUs for this Node. Kielczewski, Kostick & Shih [Page 22] RFC 1666 SNANAU MIB August 1994 For LU6.2s, 'unbind(1)' is the only valid value. unbind(1) - terminate the LU-LU session by sending an SNA UNBIND request. termself(2) - terminate the LU-LU session by sending an SNA TERM-SELF (Terminate Self) request on the SSCP-LU session. The SSCP will inform the remote session LU partner to send an UNBIND request to terminate the session. rshutd(3) - terminate the LU-LU session by sending an SNA RSHUTD (Request ShutDown) request to the remote session LU partner. The remote LU will then send an UNBIND request to terminate the session. poweroff(4) - terminate the LU-LU session by sending either an SNA LUSTAT (LU Status) request on the LU-LU session or an SNA NOTIFY request on the SSCP-LU session indicating that the LU has been powered off. Sending both is also acceptable. The result should be that the remote session LU partner will send an UNBIND to terminate the session. This object describes the default behavior for this Node; however, it is possible that for a specific LU the behavior indicated by the snaLuOperTerm object is different." ::= { snaNodeOperEntry 7 } snaNodeOperMaxLu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the current, maximum number of LUs that are activated for this Node. For PU2.1, this object refers to the number of dependent LUs." ::= { snaNodeOperEntry 8 } snaNodeOperHostDescription OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the remote host currently associated with this Node. Since SSCP Id's may not be unique across hosts, the host description Kielczewski, Kostick & Shih [Page 23] RFC 1666 SNANAU MIB August 1994 is required to uniquely identify the SSCP." ::= { snaNodeOperEntry 9 } snaNodeOperStopMethod OBJECT-TYPE SYNTAX INTEGER { other (1), normal (2), immed (3), force (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the current Node shutdown method to be used by the Agent to stop the Node. When the Agent changes the Node's state to 'inactive (1)', the Agent must use the shutdown method indicated by this object. The values have the following meaning: other (1) - proprietary method not listed in this enumeration normal(2) - deactivate only when there is no more activity on this Node (i.e., all data flows have been completed and all sessions have been terminated). immed(3) - deactivate immediately regardless of current activities on this Node. Wait for deactivation responses (from remote Node) before changing the Node state to inactive. force(4) - deactivate immediately regardless of current activities on this Node. Do not wait for deactivation responses (from remote Node) before changing the Node state to inactive. Note that a write operation to snaNodeAdminOperStopMethod may immediately change the value of snaNodeOperStopMethod depending on the Agent implementation." ::= { snaNodeOperEntry 10 } snaNodeOperState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2), waiting (3), stopping (4) Kielczewski, Kostick & Shih [Page 24] RFC 1666 SNANAU MIB August 1994 } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the Node. The values have the following meanings: inactive (1), a row representing the Node has been created in the AdminTable and, the Node is ready for activation -or- an active Node has been stopped -or- a waiting Node has returned to the inactive state. waiting (3), a request to have the Node activated has been issued, and the Node is pending activation. active (2), the Node is ready and operating. stopping (4), the request to stop the Node has been issued while the StopMethod normal or immediate is used." ::= { snaNodeOperEntry 11 } snaNodeOperHostSscpId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..6)) MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the current SSCP Id associated with the Node. This object is only applicable to PU 2.0s. If the Node is not a PU 2.0 type, then this object contains a zero length string." ::= { snaNodeOperEntry 12 } snaNodeOperStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp (e.g, the Agent's sysUpTime value) at the Node activation." ::= { snaNodeOperEntry 13 } snaNodeOperLastStateChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp (e.g., the Agent's sysUpTime value) Kielczewski, Kostick & Shih [Page 25] RFC 1666 SNANAU MIB August 1994 at the last state change of the Node." ::= { snaNodeOperEntry 14 } snaNodeOperActFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the number of failed Node activation attempts." ::= { snaNodeOperEntry 15 } snaNodeOperActFailureReason OBJECT-TYPE SYNTAX INTEGER { other (1), linkFailure (2), noResources (3), badConfiguration (4), internalError (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value indicates the reason for the activation failure. The value 'other (1)' indicates a reason not listed in the enumeration. This object will be sent in the trap snaNodeActFailTrap." ::= { snaNodeOperEntry 16 } -- *************************************************************** -- The following object is updated when there is a change to -- the value of snaNodeOperState in any row or a row is -- added/deleted from the snaNodeOperTable via the snaNodeAdminTable. -- *************************************************************** snaNodeOperTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp (e.g., the Agent's sysUpTime value) at the last change made to any object in the snaNodeOperTable, including row deletions/additions made as a result of changes to the snaNodeAdminRowStatus object. This object can be used to reduce frequent Kielczewski, Kostick & Shih [Page 26] RFC 1666 SNANAU MIB August 1994 retrievals of the snaNodeOperTable by a Management Station. It is expected that a Management Station will periodically poll this object and compare its current value with the previous one. A difference indicates that some Node operational information has been changed. Only then will the Management Station retrieve the entire table." ::= { snaNode 4 } -- *************************************************************** -- The following table contains PU 2.0 statistics dynamic parameters. -- *************************************************************** snaPu20StatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaPu20StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the dynamic parameters which have read-only access. The entries in this table correspond to PU 2.0 entries in the snaNodeOperTable and cannot be created by a Management Station." ::= { snaNode 5 } snaPu20StatsEntry OBJECT-TYPE SYNTAX SnaPu20StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry contains parameters which describe the statistics for one PU 2.0. They have read-only access. The counters represent traffic for all kinds of sessions: LU-LU, SSCP-PU, SSCP-LU. Each Node of PU Type 2.0 from the snaNodeAdminTable has one entry in this table and the index used here has the same value as snaNodeAdminIndex of that PU. The entry is created by the Agent." INDEX { snaNodeAdminIndex } ::= { snaPu20StatsTable 1 } SnaPu20StatsEntry ::= SEQUENCE { snaPu20StatsSentBytes Counter32, snaPu20StatsReceivedBytes Counter32, Kielczewski, Kostick & Shih [Page 27] RFC 1666 SNANAU MIB August 1994 snaPu20StatsSentPius Counter32, snaPu20StatsReceivedPius Counter32, snaPu20StatsSentNegativeResps Counter32, snaPu20StatsReceivedNegativeResps Counter32, snaPu20StatsActLus Gauge32, snaPu20StatsInActLus Gauge32, snaPu20StatsBindLus Gauge32 } snaPu20StatsSentBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes sent by this Node." ::= { snaPu20StatsEntry 1 } snaPu20StatsReceivedBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes received by this Node." ::= { snaPu20StatsEntry 2 } snaPu20StatsSentPius OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of PIUs sent by this Node." ::= { snaPu20StatsEntry 3 } snaPu20StatsReceivedPius OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of PIUs received by this Node." ::= { snaPu20StatsEntry 4 } Kielczewski, Kostick & Shih [Page 28] RFC 1666 SNANAU MIB August 1994 snaPu20StatsSentNegativeResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of negative responses sent by this Node." ::= { snaPu20StatsEntry 5 } snaPu20StatsReceivedNegativeResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of negative responses received by this Node." ::= { snaPu20StatsEntry 6 } snaPu20StatsActLus OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LUs on this PU which have received and responded to ACTLU from the host." ::= { snaPu20StatsEntry 7 } snaPu20StatsInActLus OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LUs on this PU which have not received an ACTLU from the host. This is possible if the number of configured LUs exceeds that on the host." ::= { snaPu20StatsEntry 8 } snaPu20StatsBindLus OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LUs on this PU which have received and acknowledged a BIND request from the host." ::= { snaPu20StatsEntry 9 } Kielczewski, Kostick & Shih [Page 29] RFC 1666 SNANAU MIB August 1994 -- *************************************************************** -- The following table contains the association between Nodes and -- link identifiers. -- It is used for configuration purposes. -- *************************************************************** snaNodeLinkAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeLinkAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the references to link specific tables. If a Node is configured for multiple links, then the Node will have multiple entries in this table. The entries in this table can be generated initially, after initialization of SNA service, by the Agent which uses information from Node configuration file. Subsequent modifications of parameters, creation of new Nodes link entries and deletion of entries is possible. The modification to this table can be saved in the Node configuration file for the next initialization of SNA service, but the mechanism for this function is not defined here." ::= { snaNode 6 } snaNodeLinkAdminEntry OBJECT-TYPE SYNTAX SnaNodeLinkAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry contains the configuration information that associates a Node instance to one link instance. The objects in the entry have read-create access. Entry can be created, modified or deleted. The object snaNodeLinkAdminRowStatus is used (set) to create or delete an entry. The object snaNodeLinkAdminSpecific can be set later, after the entry has been created." INDEX { snaNodeAdminIndex, snaNodeLinkAdminIndex } ::= { snaNodeLinkAdminTable 1 } SnaNodeLinkAdminEntry ::= SEQUENCE { snaNodeLinkAdminIndex Integer32, Kielczewski, Kostick & Shih [Page 30] RFC 1666 SNANAU MIB August 1994 snaNodeLinkAdminSpecific InstancePointer, snaNodeLinkAdminMaxPiu Integer32, snaNodeLinkAdminRowStatus RowStatus } snaNodeLinkAdminIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value is used to index the instances of objects. If an Agent creates the entry, then it will assign this number otherwise a Management Station generates a random number when it reserves the entry for creation." ::= { snaNodeLinkAdminEntry 1 } snaNodeLinkAdminSpecific OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-create STATUS current DESCRIPTION "This value points to the row in the table containing information on the link instance. (e.g., the sdlcLSAdminTable of the SNA DLC MIB module)." ::= { snaNodeLinkAdminEntry 2 } snaNodeLinkAdminMaxPiu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This value identifies the maximum number of octets that can be exchanged by this Node in one Path Information Unit (PIU)." ::= { snaNodeLinkAdminEntry 3 } snaNodeLinkAdminRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by a Management Station to create or delete the row entry in the Kielczewski, Kostick & Shih [Page 31] RFC 1666 SNANAU MIB August 1994 snaNodeLinkAdminTable. To activate a row, a Management Station sets the value to 'active (1)' or 'notReady (3)'. Upon successful creation of the row, the Agent automatically creates a corresponding entry in the snaNodeLinkOperTable. Row deletion can be Management Station or Agent initiated: (a) The Management Station can set the value to 'destroy (6)' only when the value of snaNodeLinkOperState of this Link instance is 'inactive (1)'. The Agent will then delete the row corresponding to this Link instance from snaNodeLinkOperTable and from snaNodeLinkAdminTable. (b) The Agent detects that a row is in the 'notReady (3)' state for greater than a default period of 5 minutes. (c) The Agent will not include a row with RowStatus= 'notReady (3)', after SNA system re-initialization (e.g., reboot)." ::= { snaNodeLinkAdminEntry 4 } -- *************************************************************** -- The following object is updated when there is a change to -- the value of any object in the snaNodeLinkAdminTable. -- *************************************************************** snaNodeLinkAdminTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp (e.g., the Agent's sysUpTime value) at the last change made to any object in the snaNodeLinkAdminTable, including row deletions/additions (i.e., changes to the snaNodeLinkAdminRowStatus object). This object can be used to reduce frequent retrievals of the snaNodeLinkAdminTable by a Management Station. It is expected that a Management Station will periodically poll this object and compare its current value with the previous one. A difference indicates that some Node operational information has been changed. Only then will the Kielczewski, Kostick & Shih [Page 32] RFC 1666 SNANAU MIB August 1994 Management Station retrieve the entire table." ::= { snaNode 7 } -- *************************************************************** -- The following table contains the association between -- Nodes and link identifiers. -- It provides the current status. -- *************************************************************** snaNodeLinkOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeLinkOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all references to link specific tables for operational parameters. If a Node is configured for multiple links, then the Node will have multiple entries in this table. This table augments the snaNodeLinkAdminTable." ::= { snaNode 8 } snaNodeLinkOperEntry OBJECT-TYPE SYNTAX SnaNodeLinkOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry contains all current parameters for one Node link. The objects in the entry have read-only access." AUGMENTS { snaNodeLinkAdminEntry } ::= { snaNodeLinkOperTable 1 } SnaNodeLinkOperEntry ::= SEQUENCE { snaNodeLinkOperSpecific InstancePointer, snaNodeLinkOperMaxPiu Integer32 } snaNodeLinkOperSpecific OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-only STATUS current DESCRIPTION "This value points to the row in the table containing information on the link instance. Kielczewski, Kostick & Shih [Page 33] RFC 1666 SNANAU MIB August 1994 (e.g., the sdlcLSOperTable of the SNA DLC MIB module)." ::= { snaNodeLinkOperEntry 1 } snaNodeLinkOperMaxPiu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum number of octets that can be exchanged by this Node in one Path Information Unit (PIU)." ::= { snaNodeLinkOperEntry 2 } -- *************************************************************** -- The following object is updated when a row is added/deleted -- from the snaNodeLinkOperTable. -- *************************************************************** snaNodeLinkOperTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp of the last change made to any object in the snaNodeLinkOperTable, including row deletions/additions. This object can be used to reduce frequent retrievals of the snaNodeLinkOperTable by a Management Station. It is expected that a Management Station will periodically poll this object and compare its current value with the previous one. A difference indicates that some Node operational information has been changed. Only then will the Management Station retrieve the entire table." ::= { snaNode 9 } Kielczewski, Kostick & Shih [Page 34] RFC 1666 SNANAU MIB August 1994 -- *************************************************************** -- Traps -- *************************************************************** snaNodeTraps OBJECT IDENTIFIER ::= { snaNode 10 } snaNodeStateChangeTrap NOTIFICATION-TYPE OBJECTS { snaNodeOperName, snaNodeOperState } STATUS current DESCRIPTION "This trap indicates that the operational state (i.e., value of the snaNodeOperState object) of a Node has changed. The following variables are returned: snaNodeOperName - current name of the Node, with the instance identifying the Node; and, snaNodeOperState - current state after the change." ::= { snaNodeTraps 1 } snaNodeActFailTrap NOTIFICATION-TYPE OBJECTS { snaNodeOperName, snaNodeOperState, snaNodeOperActFailureReason } STATUS current DESCRIPTION "This trap indicates a Node activation failure. The value of snaNodeOperState indicates the current state after the activation attempt. The value of snaNodeOperActFailureReason indicates the failure reason." ::= { snaNodeTraps 2 } -- *************************************************************** -- snaLu group -- -- It contains Managed Objects related to LUs in general and some -- specific for LUs of type 0, 1, 2, 3. -- *************************************************************** -- *************************************************************** -- The following table contains LU configuration parameters. -- *************************************************************** Kielczewski, Kostick & Shih [Page 35] RFC 1666 SNANAU MIB August 1994 snaLuAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains LU configuration information. The rows in this table can be created and deleted by a Management Station. Only objects which are common to all types of LUs are included in this table." ::= { snaLu 1 } snaLuAdminEntry OBJECT-TYPE SYNTAX SnaLuAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains configuration variables for an LU." INDEX { snaNodeAdminIndex, snaLuAdminLuIndex } ::= { snaLuAdminTable 1 } SnaLuAdminEntry ::= SEQUENCE { snaLuAdminLuIndex Integer32, snaLuAdminName DisplayString, snaLuAdminSnaName DisplayString, snaLuAdminType INTEGER, snaLuAdminDepType INTEGER, snaLuAdminLocalAddress OCTET STRING, snaLuAdminDisplayModel INTEGER, snaLuAdminTerm INTEGER, snaLuAdminRowStatus RowStatus } snaLuAdminLuIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value identifies the unique index for an Kielczewski, Kostick & Shih [Page 36] RFC 1666 SNANAU MIB August 1994 LU instance within a Node." ::= { snaLuAdminEntry 1 } snaLuAdminName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..48)) MAX-ACCESS read-create STATUS current DESCRIPTION "This value identifies the user configurable name for this LU. If a name is not assigned to the LU, then this object contains a zero length string. A write operation to this object will not change the operational value reflected in snaLuOperName until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaLuAdminEntry 2 } snaLuAdminSnaName OBJECT-TYPE SYNTAX DisplayString (SIZE(1..17)) MAX-ACCESS read-create STATUS current DESCRIPTION "This value identifies the SNA LU name used in exchange of SNA data. A write operation to this object will not change the operational value reflected in snaLuOperSnaName until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaLuAdminEntry 3 } snaLuAdminType OBJECT-TYPE SYNTAX INTEGER { other(1), lu0(2), lu1(3), lu2(4), lu3(5), lu4(6), lu62(7), lu7(8) } MAX-ACCESS read-create STATUS current DESCRIPTION Kielczewski, Kostick & Shih [Page 37] RFC 1666 SNANAU MIB August 1994 "This value identifies the LU type. A write operation to this object will not change the operational value reflected in snaLuOperAdminType until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaLuAdminEntry 4 } snaLuAdminDepType OBJECT-TYPE SYNTAX INTEGER { dependent(1), independent(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This value identifies whether the LU is dependent or independent. A write operation to this object will not change the operational value reflected in snaLuOperDepType until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaLuAdminEntry 5 } snaLuAdminLocalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "The local address for this LU is a byte with a value ranging from 0 to 254.For dependent LUs, this value ranges from 1 to 254 and for independent LUs this value is always 0. A write operation to this object will not change the operational value reflected in snaLuOperLocalAddress until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaLuAdminEntry 6 } snaLuAdminDisplayModel OBJECT-TYPE SYNTAX INTEGER { invalid(1), model2A(2), model2B(3), Kielczewski, Kostick & Shih [Page 38] RFC 1666 SNANAU MIB August 1994 model3A(4), model3B(5), model4A(6), model4B(7), model5A(8), model5B(9), dynamic(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the model type and screen size of the terminal connected to the host. This is only valid for LU Type 2. The values have the following meaning: model2A(2) - Model 2 (24 rows x 80 cols) with base attributes model2B(3) - Model 2 (24 rows x 80 cols) with extended attributes model3A(4) - Model 3 (32 rows x 80 cols) with base attributes model3B(5) - Model 3 (32 rows x 80 cols) with extended attributes model4A(6) - Model 4 (43 rows x 80 cols) with base attributes model4B(7) - Model 4 (43 rows x 80 cols) with extended attributes model5A(8) - Model 5 (27 rows x 132 cols) with base attributes model5B(9) - Model 5 (27 rows x 132 cols) with extended attributes dynamic(10) - Screen size determine with BIND and Read Partition Query. In case this LU is not Type 2, then this object should contain the invalid(1) value." ::= { snaLuAdminEntry 7 } snaLuAdminTerm OBJECT-TYPE SYNTAX INTEGER { unbind (1), termself (2), rshutd (3), poweroff (4) } MAX-ACCESS read-create STATUS current Kielczewski, Kostick & Shih [Page 39] RFC 1666 SNANAU MIB August 1994 DESCRIPTION "This value identifies the desired method for deactivation of this LU. This value overrides the default method (snaNodeOperLuTermDefault) for this Node. For LU 6.2, only the value 'unbind (1)' applies. unbind(1) - terminate the LU-LU session by sending an SNA UNBIND request. termself(2) - terminate the LU-LU session by sending an SNA TERM-SELF (Terminate Self) request on the SSCP-LU session. The SSCP will inform the remote session LU partner to send an UNBIND request to terminate the session. rshutd(3) - terminate the LU-LU session by sending an SNA RSHUTD (Request ShutDown) request to the remote session LU partner. The remote LU will then send an UNBIND request to terminate the session. poweroff(4) - terminate the LU-LU session by sending either an SNA LUSTAT (LU Status) request on the LU-LU session or an SNA NOTIFY request on the SSCP-LU session indicating that the LU has been powered off. Sending both is also acceptable. The result should be that the remote session LU partner will send an UNBIND to terminate the session. A write operation to this object may immediately change the operational value reflected in snaLuOperTerm depending on the Agent implementation." ::= { snaLuAdminEntry 8 } snaLuAdminRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by a Management Station to create or delete the row entry in the snaLuAdminTable. To activate a row, the Management Station sets the value to 'active (1)' or 'notReady (3)'. Upon successful creation of the row, the Agent automatically creates a corresponding entry in the snaLuOperTable with snaLuOperState equal to 'inactive (1)'. Kielczewski, Kostick & Shih [Page 40] RFC 1666 SNANAU MIB August 1994 Row deletion can be Management Station or Agent initiated: (a) The Management Station can set the value to 'destroy (6)' only when the value of snaLuOperState of this LU instance is 'inactive (1)'. The Agent will then delete the row corresponding to this LU instance from snaLuAdminTable and from snaLuOperTable. (b) The Agent detects that a row is in the 'notReady (3)' state for greater than a default period of 5 minutes. (c) The Agent will not create a row with RowStatus equal to 'notReady (3)', after SNA system re-initialization (e.g., reboot)." ::= { snaLuAdminEntry 9 } -- *************************************************************** -- The following table contains LU state dynamic parameters. -- *************************************************************** snaLuOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains dynamic runtime information and control variables relating to LUs. Only objects which are common to all types of LUs are included in this table. This table augments the snaLuAdminTable." ::= { snaLu 2 } snaLuOperEntry OBJECT-TYPE SYNTAX SnaLuOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains objects reflecting current information for an LU. Each entry is created by the Agent. All entries have read-only access." AUGMENTS { snaLuAdminEntry } ::= { snaLuOperTable 1 } SnaLuOperEntry ::= SEQUENCE { snaLuOperName DisplayString, Kielczewski, Kostick & Shih [Page 41] RFC 1666 SNANAU MIB August 1994 snaLuOperSnaName DisplayString, snaLuOperType INTEGER, snaLuOperDepType INTEGER, snaLuOperLocalAddress OCTET STRING, snaLuOperDisplayModel INTEGER, snaLuOperTerm INTEGER, snaLuOperState INTEGER, snaLuOperSessnCount Gauge32 } snaLuOperName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..48)) MAX-ACCESS read-only STATUS current DESCRIPTION "User configurable name for this LU. If a name is not assigned, then this object contains a zero length string." ::= { snaLuOperEntry 1 } snaLuOperSnaName OBJECT-TYPE SYNTAX DisplayString (SIZE(1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the current SNA LU name." ::= { snaLuOperEntry 2 } snaLuOperType OBJECT-TYPE SYNTAX INTEGER { other(1), lu0(2), lu1(3), lu2(4), lu3(5), lu4(6), lu62(7), lu7(8) } MAX-ACCESS read-only Kielczewski, Kostick & Shih [Page 42] RFC 1666 SNANAU MIB August 1994 STATUS current DESCRIPTION "The value identifies the current LU type." ::= { snaLuOperEntry 3 } snaLuOperDepType OBJECT-TYPE SYNTAX INTEGER { dependent(1), independent(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies whether the LU is currently dependent or independent. A write operation to this object will not change the operational value reflected in snaLuOperDepType until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaLuOperEntry 4 } snaLuOperLocalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local address for this LU is a byte with a value ranging from 0 to 254. For dependent LUs, this value ranges from 1 to 254; for independent LUs this value is always 0. A write operation to this object will not change the operational value reflected in snaLuOperLocalAddress until the Node has been re-activated (e.g., after the next initialization of the SNA services)." ::= { snaLuOperEntry 5 } snaLuOperDisplayModel OBJECT-TYPE SYNTAX INTEGER { invalid(1), model2A(2), model2B(3), model3A(4), model3B(5), model4A(6), Kielczewski, Kostick & Shih [Page 43] RFC 1666 SNANAU MIB August 1994 model4B(7), model5A(8), model5B(9), dynamic(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "The screen model type of the terminal connected to the host. If this LU is not Type 2, then this object should contain the 'invalid(1)' value." ::= { snaLuOperEntry 6 } snaLuOperTerm OBJECT-TYPE SYNTAX INTEGER { unbind (1), termself (2), rshutd (3), poweroff (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the current method for deactivation of this LU. This value overrides the default method (snaNodeOperLuTermDefault) for this Node. For LU 6.2, only the value 'unbind (1)' applies. unbind(1) - terminate the LU-LU session by sending an SNA UNBIND request. termself(2) - terminate the LU-LU session by sending an SNA TERM-SELF (Terminate Self) request on the SSCP-LU session. The SSCP will inform the remote session LU partner to send an UNBIND request to terminate the session. rshutd(3) - terminate the LU-LU session by sending an SNA RSHUTD (Request ShutDown) request to the remote session LU partner. The remote LU will then send an UNBIND request to terminate the session. poweroff(4) - terminate the LU-LU session by sending either an SNA LUSTAT (LU Status) request on the LU-LU session or an SNA NOTIFY request on the SSCP-LU session indicating that the LU has been powered off. Sending both is also acceptable. The result should be that the remote session LU partner will send an UNBIND Kielczewski, Kostick & Shih [Page 44] RFC 1666 SNANAU MIB August 1994 to terminate the session." ::= { snaLuOperEntry 7 } snaLuOperState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the current operational state of this LU. It has different meanings for dependent and independent LUs. For dependent LUs the values indicate the following: inactive (1) - LU didn't receive ACTLU, or it received DACTLU, or received ACTLU and sent negative response. active (2) - LU received ACTLU and acknowledged positively. For independent LUs the values indicate the following: active (2) - the LU is defined and is able to send and receive BIND. inactive (1) - the LU has a session count equal to 0." ::= { snaLuOperEntry 8 } snaLuOperSessnCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active LU-LU sessions of this LU. For the independent LU, if this object has value 0, it indicates that LU is inactive." ::= { snaLuOperEntry 9 } -- *************************************************************** -- The following table contains LU session status parameters. -- *************************************************************** snaLuSessnTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuSessnEntry MAX-ACCESS not-accessible Kielczewski, Kostick & Shih [Page 45] RFC 1666 SNANAU MIB August 1994 STATUS current DESCRIPTION "This is a table containing objects which describe the operational state of LU sessions. Only objects which are common to all types of LU sessions are included in this table. When a session's snaLuSessnOperState value changes to 'pendingBind (2)', then the corresponding entry in the session table is created by the Agent. When the session's snaLuSessnOperState value changes to 'unbound (1)', then the session will be removed from the session table by the Agent." ::= { snaLu 3 } snaLuSessnEntry OBJECT-TYPE SYNTAX SnaLuSessnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry contains dynamic parameters for an LU-LU session. The indices identify the Node, local LU, and remote LU for this session." INDEX { snaNodeAdminIndex, snaLuAdminLuIndex, snaLuSessnRluIndex, snaLuSessnIndex } ::= { snaLuSessnTable 1 } SnaLuSessnEntry ::= SEQUENCE { snaLuSessnRluIndex Integer32, snaLuSessnIndex Integer32, snaLuSessnLocalApplName DisplayString, snaLuSessnRemoteLuName DisplayString, snaLuSessnMaxSndRuSize INTEGER, snaLuSessnMaxRcvRuSize INTEGER, snaLuSessnSndPacingSize INTEGER, snaLuSessnRcvPacingSize INTEGER, Kielczewski, Kostick & Shih [Page 46] RFC 1666 SNANAU MIB August 1994 snaLuSessnActiveTime TimeStamp, snaLuSessnAdminState INTEGER, snaLuSessnOperState INTEGER, snaLuSessnSenseData OCTET STRING, snaLuSessnTerminationRu INTEGER, snaLuSessnUnbindType OCTET STRING, snaLuSessnLinkIndex Integer32 } snaLuSessnRluIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value may be used to identify information about the session partner LU in a table of information about remote LUs. Such a table is not defined in this document. If a table of remote LU information is not implemented, or if the table is implemented but it does not contain information about the partner LU for a particular session (as for dependent LU-LU sessions) then this object will have a value of zero." ::= { snaLuSessnEntry 1 } snaLuSessnIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the unique index of the session. It is recommended that an Agent should not reuse the index of a deactivated session for a significant period of time (e.g., one week)." ::= { snaLuSessnEntry 2 } snaLuSessnLocalApplName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..48)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the local application using this LU. Kielczewski, Kostick & Shih [Page 47] RFC 1666 SNANAU MIB August 1994 If the local application is unknown, then this object contains a zero length string." ::= { snaLuSessnEntry 3 } snaLuSessnRemoteLuName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "For dependent LUs which are indicated by the snaLuOperDepType object containing the value 'dependent (1)', this object contains the Primary LU (PLU) name. For independent LUs, this object contains the fully-qualified remote LU name of this 6.2 session. A fully qualified name is an SNA NAU entity name preceded by the NetId and a period as the delimiter." ::= { snaLuSessnEntry 4 } snaLuSessnMaxSndRuSize OBJECT-TYPE SYNTAX INTEGER (1..8192) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum RU size used on this session for sending RUs." ::= { snaLuSessnEntry 5 } snaLuSessnMaxRcvRuSize OBJECT-TYPE SYNTAX INTEGER (1..8192) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum RU size used on this session for receiving RUs." ::= { snaLuSessnEntry 6 } snaLuSessnSndPacingSize OBJECT-TYPE SYNTAX INTEGER (1..63) MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the send pacing window on this session." ::= { snaLuSessnEntry 7 } snaLuSessnRcvPacingSize OBJECT-TYPE SYNTAX INTEGER (1..63) MAX-ACCESS read-only Kielczewski, Kostick & Shih [Page 48] RFC 1666 SNANAU MIB August 1994 STATUS current DESCRIPTION "The size of the receive pacing window on this session." ::= { snaLuSessnEntry 8 } snaLuSessnActiveTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp (e.g., the Agent's sysUpTime value) when this session becomes active." ::= { snaLuSessnEntry 9 } snaLuSessnAdminState OBJECT-TYPE SYNTAX INTEGER { unbound (1), bound (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value indicates the desired operational state of the session. This object is used to change the operational state of the session. A Management Station can only change the operational state of the session to 'unbound (1)'. Session deactivation: If a session is in the operational state 'bound (3)' then setting the value of this object to 'unbound (1)' will initiate the session shutdown. If a session is in the operational state 'pendingBind (2)' then setting the value of this object to 'unbound (1)' will initiate the session shutdown. If a session is in the operational state 'pendingUnbind (4)' for an abnormally long period of time (e.g., three minutes) then setting the value of this object to 'unbound (1)' will change the session operational state to 'unbound (1)'. Note: for dependent LUs, deactivating the session is the same as deactivating the LU." ::= { snaLuSessnEntry 10 } Kielczewski, Kostick & Shih [Page 49] RFC 1666 SNANAU MIB August 1994 snaLuSessnOperState OBJECT-TYPE SYNTAX INTEGER { unbound (1), pendingBind (2), bound (3), pendingUnbind (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value indicates the current operational state of the session. 'unbound (1)' - session has been unbound; in this state it will be removed from the session table by the Agent. 'pendingBind (2)' - this state has different meanings for dependent and independent LUs; for dependent LU - waiting for BIND from the host, for independent LU - waiting for BIND response. When a session enters this state, the corresponding entry in the session table is created by the Agent. 'bound (3)' - session has been successfully bound. 'pendingUnbind (4)' - session enters this state when an UNBIND is sent and before the rsp(UNBIND) is received." ::= { snaLuSessnEntry 11 } snaLuSessnSenseData OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the sense code when there is a BIND failure. It is taken from the negative BIND response or UNBIND request. This is displayed as 8 hexadecimal digits." ::= { snaLuSessnEntry 12 } snaLuSessnTerminationRu OBJECT-TYPE SYNTAX INTEGER { other (1), bindFailure (2), unbind (3) Kielczewski, Kostick & Shih [Page 50] RFC 1666 SNANAU MIB August 1994 } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the SNA RU that terminated the session. If the session is not in the unbound state, this object has a value of 'other (1)'." ::= { snaLuSessnEntry 13 } snaLuSessnUnbindType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1)) MAX-ACCESS read-only STATUS current DESCRIPTION "If the session is in the unbound state, and it was terminated by an UNBIND, then this object contains the UNBIND type value (byte 1 of the UNBIND RU); otherwise the string is null." ::= { snaLuSessnEntry 14 } snaLuSessnLinkIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the link over which the session passes. It is an index into snaNodeLinkAdminTable. If the index value is not known, the value of this object shall be zero." ::= { snaLuSessnEntry 15 } -- *************************************************************** -- The following table contains LU sessions statistics dynamic -- parameters. -- *************************************************************** snaLuSessnStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuSessnStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains dynamic statistics information relating to LU sessions. The entries in this table augment the entries in the snaLuSessnTable and cannot be created by Kielczewski, Kostick & Shih [Page 51] RFC 1666 SNANAU MIB August 1994 a Management Station." ::= { snaLu 4 } snaLuSessnStatsEntry OBJECT-TYPE SYNTAX SnaLuSessnStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains statistics information for an LU session. Each entry is created by the Agent. Objects in this table have read-only access. Each session from snaLuSessnTable has one entry in this table." AUGMENTS { snaLuSessnEntry } ::= { snaLuSessnStatsTable 1 } SnaLuSessnStatsEntry ::= SEQUENCE { snaLuSessnStatsSentBytes Counter32, snaLuSessnStatsReceivedBytes Counter32, snaLuSessnStatsSentRus Counter32, snaLuSessnStatsReceivedRus Counter32, snaLuSessnStatsSentNegativeResps Counter32, snaLuSessnStatsReceivedNegativeResps Counter32 } snaLuSessnStatsSentBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes sent by the local LU." ::= { snaLuSessnStatsEntry 1 } snaLuSessnStatsReceivedBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes received by the local LU." ::= { snaLuSessnStatsEntry 2 } snaLuSessnStatsSentRus OBJECT-TYPE Kielczewski, Kostick & Shih [Page 52] RFC 1666 SNANAU MIB August 1994 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RUs sent by the local LU." ::= { snaLuSessnStatsEntry 3 } snaLuSessnStatsReceivedRus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RUs received by the local LU." ::= { snaLuSessnStatsEntry 4 } snaLuSessnStatsSentNegativeResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of negative responses sent by the local LU." ::= { snaLuSessnStatsEntry 5 } snaLuSessnStatsReceivedNegativeResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of negative responses received by the local LU." ::= { snaLuSessnStatsEntry 6 } -- *************************************************************** -- Traps -- *************************************************************** snaLuTraps OBJECT IDENTIFIER ::= { snaLu 5 } snaLuStateChangeTrap NOTIFICATION-TYPE OBJECTS { snaLuOperName, snaLuOperSnaName, snaLuOperState } STATUS current DESCRIPTION "This trap indicates that the operational state (i.e., snaLuOperState value) of the LU has changed. Kielczewski, Kostick & Shih [Page 53] RFC 1666 SNANAU MIB August 1994 The value of snaLuOperName indicates the name of the LU. The value of snaLuOperSnaName indicates the SNA name of LU. The value of snaLuOperState indicates the current state after change." ::= { snaLuTraps 1 } snaLuSessnBindFailTrap NOTIFICATION-TYPE OBJECTS { snaLuSessnLocalApplName, snaLuSessnRemoteLuName, snaLuSessnOperState, snaLuSessnSenseData } STATUS current DESCRIPTION "This trap indicates the failure of a BIND. The value of snaLuSessnLocalApplName indicates the local application name. The value of snaLuSessnPartnerName indicates the partner name. The value of snaLuSessnOperState indicates the current state after change. The value of snaLuSessnBindFailureReason indicates the failure reason. The Agent should not generate more than 1 trap of this type per minute to minimize the level of management traffic on the network." ::= { snaLuTraps 2 } -- *************************************************************** -- snaMgtTools group -- -- Currently this group contains only one table. -- *************************************************************** -- *************************************************************** -- The following table contains Response Time Monitoring (RTM) -- configuration information and statistics for LU Type 2s. -- RTM supports the capability to measure and report end-user -- response times for dependent LUs. When the RTM state of an LU -- is 'on', response times for each LU transaction are monitored. -- A set of ranges is defined (e.g., Range 1 includes the number of -- transactions with response times less than 1 second) using the -- "boundary" definitions (e.g., boundary #2 is defined as 3 seconds). -- A set of counters (one per range) identifies -- the number of transactions within each response time range. -- *************************************************************** Kielczewski, Kostick & Shih [Page 54] RFC 1666 SNANAU MIB August 1994 snaLuRtmTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuRtmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains Response Time Monitoring (RTM) information relating to an LU (Type 2). Each entry corresponds to an LU 2 entry in snaLuAdminTable." ::= { snaMgtTools 1 } snaLuRtmEntry OBJECT-TYPE SYNTAX SnaLuRtmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains RTM information for an LU (Type 2). Each entry is created by the Agent." INDEX { snaLuRtmPuIndex, snaLuRtmLuIndex } ::= { snaLuRtmTable 1 } SnaLuRtmEntry ::= SEQUENCE { snaLuRtmPuIndex Integer32, snaLuRtmLuIndex Integer32, snaLuRtmState INTEGER, snaLuRtmStateTime TimeStamp, snaLuRtmDef INTEGER, snaLuRtmBoundary1 Integer32, snaLuRtmBoundary2 Integer32, snaLuRtmBoundary3 Integer32, snaLuRtmBoundary4 Integer32, snaLuRtmCounter1 Counter32, snaLuRtmCounter2 Counter32, snaLuRtmCounter3 Counter32, snaLuRtmCounter4 Counter32, Kielczewski, Kostick & Shih [Page 55] RFC 1666 SNANAU MIB August 1994 snaLuRtmOverFlows Counter32, snaLuRtmObjPercent Integer32, snaLuRtmObjRange INTEGER, snaLuRtmNumTrans Integer32, snaLuRtmLastRspTime Integer32, snaLuRtmAvgRspTime Integer32 } snaLuRtmPuIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value identifies the PU 2.0 with which this LU is associated." ::= { snaLuRtmEntry 1 } snaLuRtmLuIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value uniquely identifies an LU in a PU 2.0." ::= { snaLuRtmEntry 2 } snaLuRtmState OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value indicates the current RTM state of an LU." ::= { snaLuRtmEntry 3 } snaLuRtmStateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp (e.g., the Agent's sysUpTime value) Kielczewski, Kostick & Shih [Page 56] RFC 1666 SNANAU MIB August 1994 when this session's RTM state (e.g., snaLuRtmState) changes value." ::= { snaLuRtmEntry 4 } snaLuRtmDef OBJECT-TYPE SYNTAX INTEGER { firstChar(1), kb(2), cdeb(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value indicates the mode of measurement for this RTM request. The values have following meaning: firstChar(1) - time to first character on screen kb(2) - time to keyboard usable by operator cdeb(3) - time to Change Direction/End Bracket." ::= { snaLuRtmEntry 5 } snaLuRtmBoundary1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of the first boundary in units of 1/10th of a second." ::= { snaLuRtmEntry 6 } snaLuRtmBoundary2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of the second boundary in units of 1/10th of a second." ::= { snaLuRtmEntry 7 } snaLuRtmBoundary3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of the third boundary in units of 1/10th of a second." ::= { snaLuRtmEntry 8 } snaLuRtmBoundary4 OBJECT-TYPE Kielczewski, Kostick & Shih [Page 57] RFC 1666 SNANAU MIB August 1994 SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of the fourth boundary in units of 1/10th of a second." ::= { snaLuRtmEntry 9 } snaLuRtmCounter1 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the number of transactions which fall in the range specified by the first boundary." ::= { snaLuRtmEntry 10 } snaLuRtmCounter2 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the number of transactions which fall in the range specified by the second boundary." ::= { snaLuRtmEntry 11 } snaLuRtmCounter3 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the number of transactions which fall in the range specified by the third boundary." ::= { snaLuRtmEntry 12 } snaLuRtmCounter4 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the number of transactions which fall in the range specified by the fourth boundary." ::= { snaLuRtmEntry 13 } snaLuRtmOverFlows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Kielczewski, Kostick & Shih [Page 58] RFC 1666 SNANAU MIB August 1994 DESCRIPTION "This value indicates the number of transactions which exceed the highest range specified by the boundaries." ::= { snaLuRtmEntry 14 } snaLuRtmObjPercent OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the desired percentage of transactions which should be under a designated boundary range indicated by snaLuRtmObjRange." ::= { snaLuRtmEntry 15 } snaLuRtmObjRange OBJECT-TYPE SYNTAX INTEGER { other(1), range1(2), range2(3), range3(4), range4(5), range5(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the designated boundary range to which the snaLuRtmObject refers. The values have the following meanings: other(1) - not specified range1(2) - less than boundary 1 range2(3) - between boundary 1 and 2 range3(4) - between boundary 2 and 3 range4(5) - between boundary 3 and 4 range5(6) - greater than boundary 4." ::= { snaLuRtmEntry 16 } snaLuRtmNumTrans OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the total number of transactions executed since the RTM monitoring began (i.e., snaLuRtmState changed to 'on(2)') for this LU." ::= { snaLuRtmEntry 17 } Kielczewski, Kostick & Shih [Page 59] RFC 1666 SNANAU MIB August 1994 snaLuRtmLastRspTime OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the response time for the last transaction in units of 1/10th of a second." ::= { snaLuRtmEntry 18 } snaLuRtmAvgRspTime OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the average response time for all transactions in units of 1/10th of a second." ::= { snaLuRtmEntry 19 } -- *************************************************************** -- Conformance information -- *************************************************************** snanauConformance OBJECT IDENTIFIER ::= { snanauMIB 2 } snanauCompliances OBJECT IDENTIFIER ::= {snanauConformance 1 } snanauGroups OBJECT IDENTIFIER ::= {snanauConformance 2 } -- Compliance statements snanauCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SNMPv2 entities which implement the snanau MIB." MODULE -- this module -- Unconditionally mandatory groups MANDATORY-GROUPS { snaNodeGroup, snaLuGroup, snaSessionGroup } -- Conditionally mandatory groups GROUP snaPu20Group DESCRIPTION "The snaPu20Group is mandatory only for those entities which implement PU type 2.0" GROUP snaMgtToolsRtmGroup DESCRIPTION Kielczewski, Kostick & Shih [Page 60] RFC 1666 SNANAU MIB August 1994 "The snaMgtToolsGroup is mandatory only for those entities which implement LU type 2 and RTM." -- Refinement of requirements for objects access. -- The Agent which does not implement row creation for -- snaNodeAdminTable, snaNodeLinkAdminTable and -- snaLuAdminTable must at least accept -- objects modification (read-write access instead of -- read-create). OBJECT snaNodeAdminName MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminType MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminXidFormat MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminBlockNum MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminIdNum MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminEnablingMethod MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminLuTermDefault Kielczewski, Kostick & Shih [Page 61] RFC 1666 SNANAU MIB August 1994 MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminMaxLu MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminHostDescription MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminStopMethod MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeAdminState MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeLinkAdminSpecific MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaNodeLinkAdminMaxPiu MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaLuAdminName MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaLuAdminSnaName MIN-ACCESS read-write Kielczewski, Kostick & Shih [Page 62] RFC 1666 SNANAU MIB August 1994 DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaLuAdminType MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaLuAdminDepType MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaLuAdminLocalAddress MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaLuAdminDisplayModel MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." OBJECT snaLuAdminTerm MIN-ACCESS read-write DESCRIPTION "An Agent is required to implement read-write access to this object." ::= {snanauCompliances 1 } -- Units of conformance snaNodeGroup OBJECT-GROUP OBJECTS { snaNodeAdminName, snaNodeAdminType, snaNodeAdminXidFormat, snaNodeAdminBlockNum, snaNodeAdminIdNum, snaNodeAdminEnablingMethod, snaNodeAdminLuTermDefault, snaNodeAdminMaxLu, Kielczewski, Kostick & Shih [Page 63] RFC 1666 SNANAU MIB August 1994 snaNodeAdminHostDescription, snaNodeAdminStopMethod, snaNodeAdminState, snaNodeAdminRowStatus, snaNodeAdminTableLastChange, snaNodeOperName, snaNodeOperType, snaNodeOperXidFormat, snaNodeOperBlockNum, snaNodeOperIdNum, snaNodeOperEnablingMethod, snaNodeOperLuTermDefault, snaNodeOperMaxLu, snaNodeOperHostDescription, snaNodeOperStopMethod, snaNodeOperState, snaNodeOperHostSscpId, snaNodeOperStartTime, snaNodeOperLastStateChange, snaNodeOperActFailures, snaNodeOperActFailureReason, snaNodeOperTableLastChange, snaNodeLinkAdminSpecific, snaNodeLinkAdminMaxPiu, snaNodeLinkAdminRowStatus, snaNodeLinkAdminTableLastChange, snaNodeLinkOperSpecific, snaNodeLinkOperMaxPiu, snaNodeLinkOperTableLastChange } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of SNA nodes." ::= { snanauGroups 1 } snaLuGroup OBJECT-GROUP OBJECTS { snaLuAdminName, snaLuAdminSnaName, snaLuAdminType, snaLuAdminDepType, snaLuAdminLocalAddress, snaLuAdminDisplayModel, snaLuAdminTerm, snaLuAdminRowStatus, snaLuOperName, snaLuOperSnaName, snaLuOperType, snaLuOperDepType, Kielczewski, Kostick & Shih [Page 64] RFC 1666 SNANAU MIB August 1994 snaLuOperLocalAddress, snaLuOperDisplayModel, snaLuOperTerm, snaLuOperState, snaLuOperSessnCount } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of SNA LUs." ::= { snanauGroups 2 } snaSessionGroup OBJECT-GROUP OBJECTS { snaLuSessnRluIndex, snaLuSessnIndex, snaLuSessnLocalApplName, snaLuSessnRemoteLuName, snaLuSessnMaxSndRuSize, snaLuSessnMaxRcvRuSize, snaLuSessnSndPacingSize, snaLuSessnRcvPacingSize, snaLuSessnActiveTime, snaLuSessnAdminState, snaLuSessnOperState, snaLuSessnSenseData, snaLuSessnTerminationRu, snaLuSessnUnbindType, snaLuSessnLinkIndex, snaLuSessnStatsSentBytes, snaLuSessnStatsReceivedBytes, snaLuSessnStatsSentRus, snaLuSessnStatsReceivedRus, snaLuSessnStatsSentNegativeResps, snaLuSessnStatsReceivedNegativeResps } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of SNA sessions." ::= { snanauGroups 3 } snaPu20Group OBJECT-GROUP OBJECTS { snaPu20StatsSentBytes, snaPu20StatsReceivedBytes, snaPu20StatsSentPius, snaPu20StatsReceivedPius, snaPu20StatsSentNegativeResps, snaPu20StatsReceivedNegativeResps, snaPu20StatsActLus, snaPu20StatsInActLus, Kielczewski, Kostick & Shih [Page 65] RFC 1666 SNANAU MIB August 1994 snaPu20StatsBindLus } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of PU 2.0." ::= { snanauGroups 4 } snaMgtToolsRtmGroup OBJECT-GROUP OBJECTS { snaLuRtmState, snaLuRtmStateTime, snaLuRtmDef, snaLuRtmBoundary1, snaLuRtmBoundary2, snaLuRtmBoundary3, snaLuRtmBoundary4, snaLuRtmCounter1, snaLuRtmCounter2, snaLuRtmCounter3, snaLuRtmCounter4, snaLuRtmOverFlows, snaLuRtmObjPercent, snaLuRtmObjRange, snaLuRtmNumTrans, snaLuRtmLastRspTime, snaLuRtmAvgRspTime } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of RTM for SNA LU 2.0." ::= { snanauGroups 5 } -- end of conformance statement END Kielczewski, Kostick & Shih [Page 66] RFC 1666 SNANAU MIB August 1994 5. Acknowledgments The following people greatly contributed to the work on this MIB document: Michael Allen, Robin Cheng, Bill Kwan. Special thanks goes to Dave Perkins for his assistance in reviewing this MIB proposal. 6. References [1] IBM, Systems Network Architecture Technical Overview, GC 30- 3073-3, March, 1991. [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [3] McCloghrie, K., and M. Rose, "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. [4] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. Kielczewski, Kostick & Shih [Page 67] RFC 1666 SNANAU MIB August 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Zbigniew Kielczewski Eicon Technology Corporation 2196 32nd Avenue Montreal, Quebec, Canada H8T 3H7 Phone: 1 514 631 2592 EMail: zbig@eicon.qc.ca Deirdre Kostick Bellcore 331 Newman Springs Road Red Bank, NJ 07701 Phone: 1 908 758 2642 EMail: dck2@mail.bellcore.com Kitty Shih Novell 890 Ross Drive Sunnyvale, CA 94089 Phone: 1 408 747 4305 EMail: kmshih@novell.com Kielczewski, Kostick & Shih [Page 68] snmp-mibs-downloader-1.1/mibrfcs/rfc1694.txt0000644000000000000000000021467011402176071015577 0ustar Network Working Group T. Brown Request for Comments: 1694 K. Tesink Obsoletes: 1304 Editors Category: Standards Track Bell Communications Research August 1994 Definitions of Managed Objects for SMDS Interfaces using SMIv2 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing objects for SMDS access interfaces. This includes the following access protocols: SIP [13] SIP/DXI [18] and [20] SIP/FR [19] SIP/ATM [24] This memo replaces RFC 1304 [12], and defines a MIB module which is both compliant to the SNMPv2 SMI and semantically-identical to the existing RFC 1304-based definitions. This memo also assumes application of the MIB II Interfaces group as defined in [9]. Table of Contents 1. The SNMPv2 Network Management Framework ............... 2 2. Objects ............................................... 3 2.1 Format of Definitions ................................ 3 3. Overview .............................................. 4 3.1 SIP Level 3 .......................................... 5 4. Object Definitions .................................... 9 4.1 The SIP Level 3 Group ................................ 10 4.2 The SIP Level 2 Group ................................ 14 4.3 The SIP PLCP Group ................................... 17 Brown & Tesink [Page 1] RFC 1694 SMDS Interface Objects August 1994 4.3.1 The DS1 PLCP Group ................................. 17 4.3.2 The DS3 PLCP Group ................................. 19 4.4 The SMDS Applications Group .......................... 20 4.4.1 The IP over SMDS Group ............................. 21 4.5 The SMDS Carrier Selection Group ..................... 22 4.6 The SIP Error Log Group .............................. 23 4.7 The Data eXchange Interface Group .................... 27 4.8 Conformance Information .............................. 29 5. Acknowledgments ....................................... 32 6. References ............................................ 32 7. Security Considerations ............................... 34 8. Authors' Addresses .................................... 35 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [6] defines MIB-II, the core set of managed objects for the Internet suite of protocols. Reference [12] defines the evolution of the Interfaces Group of MIB II in terms of extensions and precise applications of the objects. o RFC 1445 [4] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [5] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. This specification makes also use of: o RFC 1443 [2] which defines textual conventions for the specification of managed objects. o RFC 1444 [3] which defines conformance statements for the specification of managed objects. Brown & Tesink [Page 2] RFC 1694 SMDS Interface Objects August 1994 2. Objects 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) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI RFC 1442 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 2.1. Format of Definitions Section 4 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in the SNMPv2 SMI. Brown & Tesink [Page 3] RFC 1694 SMDS Interface Objects August 1994 3. Overview SMDS is a service that can be provided by numerous interface protocols as shown in the following figure: +-------------------+ +-------------------+ | SIP Level 3* [13] | | SIP Level 3* [13] | +-------------------+ +-------------------+ | SIP Level 2* [13] | | DXI Level 2* [20] | +-------------------+ +-------------------+ | SIP PLCP* [14] | | | +-------------------+ | DXI Level 1 [20] | | SIP Level 1 [14] | | | +-------------------+ +-------------------+ SIP based access DXI based access +-------------------+ +-------------------+ | SIP Level 3* [13] | | SIP Level 3* [13] | +-------------------+ +-------------------+ | ATM [21] | | Frame Relay [19] | +-------------------+ +-------------------+ | ATM PLCP [21] | | | +-------------------+ | Frame Relay [19] | | ATM Level 1 [21] | | Level 1 | +-------------------+ +-------------------+ ATM based access FR based access Brown & Tesink [Page 4] RFC 1694 SMDS Interface Objects August 1994 In the figure below, managed objects for the protocol levels marked with a (*) are defined in this memo. Additional managed objects that must be used to manage SMDS interfaces are defined in other MIB modules as indicated in the figure. +-------------------+ +-------------------+ | SIP Level 3* | | SIP Level 3* | +-------------------+ +-------------------+ | SIP Level 2* | | DXI Level 2* | +-------------------+ +-------------------+ | SIP PLCP* | | | +-------------------+ | DXI Level 1 | | SIP Level 1 | | | | [10] or [11] | | [10] | +-------------------+ +-------------------+ SIP based access DXI based access +-------------------+ +-------------------+ | SIP Level 3* | | SIP Level 3* | +-------------------+ +-------------------+ | ATM [22] | | Frame Relay [23] | +-------------------+ +-------------------+ | ATM PLCP/TC [22] | | | +-------------------+ | Frame Relay | | ATM Level 1 [10] | | Level 1 | | [11], or [25] | | [10] or [11] | +-------------------+ +-------------------+ ATM based access FR based access With the improved interpretation of the MIB II interfaces group [9], some objects can be represented by ifTable. This means that these objects have been deprecated from the MIB module defined in RFC 1304, and ifTable is used instead. No semantical changes have been made to these objects. Only the object identifiers and object descriptors have been changed to the objects defined in ifTable. Implementation experience has shown that the objects sipL3UnrecognizedIndividualDAs and sipL3UnrecognizedGAs were not supported. 3.1. SIP Level 3 Objects for SIP Level 3 apply to all methods to access SMDS shown in the figures above. With the improved interpretation of the MIB II interfaces group, most objects can be represented by ifTable. The appropriate mapping is defined below. Brown & Tesink [Page 5] RFC 1694 SMDS Interface Objects August 1994 This document does not specify objects for the management of subscription or configuration of Subscriber-Network Interfaces (SNIs). Those objects are defined in Definitions of Managed Objects for SMDS Subscription [17]. Bellcore requirements on these objects are specified in TR-TSV-001062 [16]. ifTable Object Use for ====================================================== ifIndex Interface index. ifDescr Interface description. For example, SIP Level 3 sublayer of a SNI. ifType Set to 31. ifMtu Set to 9232. ifSpeed Peak bandwidth in bits per second available for use as provided by the supporting Level 2 protocol. For example, 1.17 Mbps when using SIP based DS1 SNIs, and 1.536 Mbps when using DXI-based DS1 DXI-SNI. ifPhysAddress OCTET STRING of Size 8. Value is a 16-digit Binary Coded Decimal SMDS address that is assigned to this interface. ifAdminStatus The desired administrative status of the SMDS interface. ifOperStatus The current operational status of the SMDS interface. ifLastChange The elapsed time since the last re-initialization of the interface. The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value. ifInOctets Number of received octets at SIP Level 3. For SIP based SNIs, this is the number of sipL2ReceivedCounts multiplied by 44. Brown & Tesink [Page 6] RFC 1694 SMDS Interface Objects August 1994 ifInUcastPkts The total number of individually addressed SIP Level 3 PDUs received from the remote system across the SNI. The total includes only unerrored SIP Level 3 PDUs. [identical to RFC1304: sipL3ReceivedIndividualDAs] ifInDiscards The number of received SIP Level 3 PDUs discarded. For SMDS interfaces, this counter will always be zero. ifInErrors The total number of SIP Level 3 PDUs received from the remote system that were discovered to have errors (including protocol processing and bit errors but excluding addressing-related errors) and were discarded. Includes both group addressed SIP Level 3 PDUs and SIP Level 3 PDUs containing an individual destination address. [identical to RFC1304: sipL3Errors] ifInUnknownProtos The number of SIP Level 3 PDUs received from the remote system with a Source or Destination Address_Type subfields, (the four most significant bits of the 64 bit address field), not equal to the value 1100 or 1110. Also, an error is considered to have occurred if the Address_Type field for a Source Address is equal to 1110 (a group address). [identical to RFC1304: sipL3InvalidSMDSAddressTypes] ifOutOctets Number of received octets for transmission at SIP Level 3. For SIP based SNIs, this is the number of sipL2SentCounts multiplied by 44. ifOutUcastPkts The number of individually addressed SIP Level 3 PDUs that have been sent by this system across the interface. [identical to RFC1304: sipL3SentIndividualDAs] ifOutDiscards The number of SIP Level 3 PDUs discarded in the egress direction. For SMDS interfaces, this counter will always be zero. Brown & Tesink [Page 7] RFC 1694 SMDS Interface Objects August 1994 ifOutErrors The number of SIP Level 3 PDUs discarded in the egress direction, because of errors. For SMDS interfaces, this counter will always be zero. ifName The textual name of the interface. If not used, this variable contains a zero-length string. ifInMulticastPkts The total number of group addressed SIP Level 3 PDUs received from the remote system across the interface. The total includes only unerrored SIP Level 3 PDUs. [identical to RFC1304: sipL3ReceivedGAs] ifInBroadcastPkts This variable is not applicable for SMDS interfaces. Therefore, this counter is always zero. ifOutMulticastPkts The number of group addressed SIP Level 3 PDUs that have been sent by this system across the interface. [identical to RFC1304: sipL3SentGAs] ifOutBroadcastPkts This variable is not applicable for SMDS interfaces. Therefore, this counter is always zero. ifLinkUpDownTrapEnble The value of this object is disabled(2) for SIP Level 3 interfaces. ifHighSpeed Set to the user data rate of the interface in millions of bits per second. If the user data rate is less than 1 Mbps, then this value is zero. ifPromiscuousMode Set to false(2). ifConnectorPresent Set to false(2). Consult the Evolution of the Interfaces Group [9] for when to use the HC (High Capacity) counters (e.g., ifHCInOctets is a 64-bit counter). Brown & Tesink [Page 8] RFC 1694 SMDS Interface Objects August 1994 4. Object Definitions SIP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, IpAddress FROM SNMPv2-SMI TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF transmission, ifIndex, mib-2 FROM RFC1213-MIB; -- This is the MIB module for the SMDS Interface objects. sipMIB MODULE-IDENTITY LAST-UPDATED "9403311818Z" ORGANIZATION "IETF Interfaces Working Group" CONTACT-INFO " Tracy Brown Postal: Bell Communications Research 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 US Tel: +1 908 758-2107 Fax: +1 908 758-4177 E-mail: tacox@mail.bellcore.com Kaj Tesink Postal: Bell Communications Research 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 US Tel: +1 908 758 5254 Fax: +1 908 758 4177 E-mail: kaj@cc.bellcore.com." DESCRIPTION "The MIB module to describe SMDS interfaces objects." ::= { mib-2 36 } SMDSAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1h:" STATUS current DESCRIPTION "The 60-bit SMDS address, Brown & Tesink [Page 9] RFC 1694 SMDS Interface Objects August 1994 preceded by 4 bits with the following values: 1100 when representing an individual address 1110 when representing a group address." SYNTAX OCTET STRING (SIZE (8)) IfIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies the interface for which this entry contains management information. The value of this object for a particular interface has the same value as the ifIndex object, defined in RFC 1213, for the same interface." SYNTAX Integer32 sip OBJECT IDENTIFIER ::= { transmission 31 } sipMIBObjects OBJECT IDENTIFIER ::= { sipMIB 1 } -- The SIP Level 3 Group sipL3Table OBJECT-TYPE SYNTAX SEQUENCE OF SipL3Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP L3 parameters and state variables, one entry per SIPL3 interface." ::= { sip 1 } sipL3Entry OBJECT-TYPE SYNTAX SipL3Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains SIP L3 parameters and state variables." INDEX { sipL3Index } ::= { sipL3Table 1 } SipL3Entry ::= SEQUENCE { sipL3Index IfIndex, sipL3ReceivedIndividualDAs Counter32, sipL3ReceivedGAs Counter32, sipL3UnrecognizedIndividualDAs Counter32, sipL3UnrecognizedGAs Counter32, Brown & Tesink [Page 10] RFC 1694 SMDS Interface Objects August 1994 sipL3SentIndividualDAs Counter32, sipL3SentGAs Counter32, sipL3Errors Counter32, sipL3InvalidSMDSAddressTypes Counter32, sipL3VersionSupport Integer32 } sipL3Index OBJECT-TYPE SYNTAX IfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the SIP L3 interface for which this entry contains management information. " ::= { sipL3Entry 1 } sipL3ReceivedIndividualDAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated -- Moved to ifTable -- ifInUcastPkts defined in [9] must be used instead. DESCRIPTION "The total number of individually addressed SIP Level 3 PDUs received from the remote system across the SNI. The total includes only unerrored L3PDUs." ::= { sipL3Entry 2 } sipL3ReceivedGAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated -- Moved to ifTable -- ifInMulticastPkts defined in [9] must be used instead. DESCRIPTION "The total number of group addressed SIP Level 3 PDUs received from the remote system across the SNI. The total includes only unerrored L3PDUs." ::= { sipL3Entry 3 } sipL3UnrecognizedIndividualDAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of SIP Level 3 PDUs received from the Brown & Tesink [Page 11] RFC 1694 SMDS Interface Objects August 1994 remote system with invalid or unknown individual destination addresses (Destination Address Screening violations are not included). See SMDS Subscription MIB module." ::= { sipL3Entry 4 } sipL3UnrecognizedGAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of SIP Level 3 PDUs received from the remote system with invalid or unknown group addresses. (Destination Address Screening violations are not included). See SMDS Subscription MIB module." ::= { sipL3Entry 5 } sipL3SentIndividualDAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated -- Moved to ifTable -- ifOutUcastPkts defined in [9] must be used instead. DESCRIPTION "The number of individually addressed SIP Level 3 PDUs that have been sent by this system across the SNI." ::= { sipL3Entry 6 } sipL3SentGAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated -- Moved to ifTable -- ifOutMulticastPkts defined in [9] must be used instead. DESCRIPTION "The number of group addressed SIP L3PDUs that have been sent by this system across the SNI." ::= { sipL3Entry 7 } -- The total number of SIP L3PDU errors can be calculated as -- (Syntactic errors + Semantic Service errors ) -- Syntactic errors include: -- sipL3Errors -- Latest occurrences of syntactic error types are logged in -- sipL3PDUErrorTable. -- Semantic Service errors include: Brown & Tesink [Page 12] RFC 1694 SMDS Interface Objects August 1994 -- sipL3UnrecognizedIndividualDAs -- sipL3UnrecognizedGAs -- sipL3InvalidSMDSAddressTypes -- Note that public networks supporting SMDS may discard -- SIP L3PDUs due to subscription violations. Related -- managed objects are defined in Definitions of Managed -- Objects for SMDS Subscription. sipL3Errors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated -- Moved to ifTable -- ifInErrors defined in [9] must be used instead. DESCRIPTION "The total number of SIP Level 3 PDUs received from the remote system that were discovered to have errors (including protocol processing and bit errors but excluding addressing-related errors) and were discarded. Includes both group addressed L3PDUs and L3PDUs containing an individual destination address." ::= { sipL3Entry 8 } sipL3InvalidSMDSAddressTypes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated -- Moved to ifTable -- ifInUnknownProtos defined in [9] must be used instead. DESCRIPTION "The number of SIP Level 3 PDUs received from the remote system that had the Source or Destination Address_Type subfields, (the four most significant bits of the 64 bit address field), not equal to the value 1100 or 1110. Also, an error is considered to have occurred if the Address_Type field for a Source Address, the four most significant bits of the 64 bits, is equal to 1110 (a group address)." ::= { sipL3Entry 9 } sipL3VersionSupport OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A value which indicates the version(s) of SIP Brown & Tesink [Page 13] RFC 1694 SMDS Interface Objects August 1994 that this interface supports. The value is a sum. This sum initially takes the value zero. For each version, V, that this interface supports, 2 raised to (V - 1) is added to the sum. For example, a port supporting versions 1 and 2 would have a value of (2^(1-1)+2^(2-1))=3. The sipL3VersionSupport is effectively a bit mask with Version 1 equal to the least significant bit (LSB)." ::= { sipL3Entry 10 } -- The SIP Level 2 Group sipL2Table OBJECT-TYPE SYNTAX SEQUENCE OF SipL2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP L2PDU parameters and state variables, one entry per SIP L2 interface." ::= { sip 2 } sipL2Entry OBJECT-TYPE SYNTAX SipL2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains SIP L2 parameters and state variables." INDEX { sipL2Index } ::= { sipL2Table 1 } SipL2Entry ::= SEQUENCE { sipL2Index IfIndex, sipL2ReceivedCounts Counter32, sipL2SentCounts Counter32, sipL2HcsOrCRCErrors Counter32, sipL2PayloadLengthErrors Counter32, sipL2SequenceNumberErrors Counter32, sipL2MidCurrentlyActiveErrors Counter32, sipL2BomOrSSMsMIDErrors Counter32, sipL2EomsMIDErrors Counter32 } sipL2Index OBJECT-TYPE SYNTAX IfIndex MAX-ACCESS read-only Brown & Tesink [Page 14] RFC 1694 SMDS Interface Objects August 1994 STATUS current DESCRIPTION "The value of this object identifies the SIP interface for which this entry contains management information." ::= { sipL2Entry 1 } sipL2ReceivedCounts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SIP Level 2 PDUs received from the remote system across the SNI. The total includes only unerrored L2PDUs." ::= { sipL2Entry 2 } sipL2SentCounts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SIP Level 2 PDUs that have been sent by this system across the SNI." ::= { sipL2Entry 3 } -- The following error types are counted, and -- preclude sipL2ReceivedCounts to be incremented: -- sipL2HcsOrCRCErrors -- sipL2PayloadLengthErrors -- sipL2SequenceNumberErrors -- sipL2BomOrSSMsMIDErrors -- sipL2EomsMIDErrors -- The receipt of SIP Level 2 PDUs which are BOMs and -- for with a MID that is already active will cause -- sipL2MidCurrentlyActiveErrors to increment. -- Any already accumulated (correct) segmentation -- units are discarded.The sipL2ReceivedCounts -- is incremented by 1. Thus, -- sipL2ReceivedCounts defines the number of -- correct SIP Level 2 PDUs delivered to the reassembly -- process. sipL2HcsOrCRCErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Brown & Tesink [Page 15] RFC 1694 SMDS Interface Objects August 1994 "The number of received SIP Level 2 PDUs that were discovered to have either a Header Check Sequence error or a Payload CRC violation." ::= { sipL2Entry 4 } sipL2PayloadLengthErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received SIP Level 2 PDUs that had Payload Length errors that fall in the following specifications: - SSM L2_PDU payload length field value less - than 28 octets or greater than 44 octets, - BOM or COM L2_PDU payload length field not - equal to 44 octets, - EOM L2_PDU payload length field value less - than 4 octets or greater than 44 octets." ::= { sipL2Entry 5 } sipL2SequenceNumberErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received SIP Level 2 PDUs that had a sequence number within the L2PDU not equal to the expected sequence number of the SMDS SS receive process." ::= { sipL2Entry 6 } sipL2MidCurrentlyActiveErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received SIP Level 2 PDUs that are BOMs for which an active receive process is already started." ::= { sipL2Entry 7 } sipL2BomOrSSMsMIDErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Brown & Tesink [Page 16] RFC 1694 SMDS Interface Objects August 1994 "The number of received SIP Level 2 PDUs that are SSMs with a MID not equal to zero or are BOMs with MIDs equal to zero." ::= { sipL2Entry 8 } sipL2EomsMIDErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received SIP Level 2 PDUs that are EOMs for which there is no active receive process for the MID (i.e., the receipt of an EOM which does not correspond to a BOM) OR the EOM has a MID equal to zero." ::= { sipL2Entry 9 } -- The SIP PLCP Group sipPLCP OBJECT IDENTIFIER ::= { sip 3 } -- The DS1 PLCP Group sipDS1PLCPTable OBJECT-TYPE SYNTAX SEQUENCE OF SipDS1PLCPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP DS1 PLCP parameters and state variables, one entry per SIP port." ::= { sipPLCP 1 } sipDS1PLCPEntry OBJECT-TYPE SYNTAX SipDS1PLCPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains SIP DS1 PLCP parameters and state variables." INDEX { sipDS1PLCPIndex } ::= { sipDS1PLCPTable 1 } SipDS1PLCPEntry ::= SEQUENCE { sipDS1PLCPIndex IfIndex, sipDS1PLCPSEFSs Counter32, sipDS1PLCPAlarmState INTEGER, Brown & Tesink [Page 17] RFC 1694 SMDS Interface Objects August 1994 sipDS1PLCPUASs Counter32 } sipDS1PLCPIndex OBJECT-TYPE SYNTAX IfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the interface for which this entry contains management information. " ::= { sipDS1PLCPEntry 1 } sipDS1PLCPSEFSs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A DS1 Severely Errored Framing Second (SEFS) is a count of one-second intervals containing one or more SEF events. A Severely Errored Framing (SEF) event is declared when an error in the A1 octet and an error in the A2 octet of a framing octet pair (i.e., errors in both framing octets), or two consecutive invalid and/or nonsequential Path Overhead Identifier octets are detected." ::= { sipDS1PLCPEntry 2 } sipDS1PLCPAlarmState OBJECT-TYPE SYNTAX INTEGER { noAlarm (1), receivedFarEndAlarm (2), incomingLOF (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is an alarm present for the DS1 PLCP. The value receivedFarEndAlarm means that the DS1 PLCP has received an incoming Yellow Signal, the value incomingLOF means that the DS1 PLCP has declared a loss of frame (LOF) failure condition, and the value noAlarm means that there are no alarms present. See TR-TSV-000773 for a description of alarm states." ::= { sipDS1PLCPEntry 3 } Brown & Tesink [Page 18] RFC 1694 SMDS Interface Objects August 1994 sipDS1PLCPUASs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds, as defined by TR-TSV-000773, encountered by the PLCP." ::= { sipDS1PLCPEntry 4 } -- The DS3 PLCP Group sipDS3PLCPTable OBJECT-TYPE SYNTAX SEQUENCE OF SipDS3PLCPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP DS3 PLCP parameters and state variables, one entry per SIP port." ::= { sipPLCP 2 } sipDS3PLCPEntry OBJECT-TYPE SYNTAX SipDS3PLCPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains SIP DS3 PLCP parameters and state variables." INDEX { sipDS3PLCPIndex } ::= { sipDS3PLCPTable 1 } SipDS3PLCPEntry ::= SEQUENCE { sipDS3PLCPIndex IfIndex, sipDS3PLCPSEFSs Counter32, sipDS3PLCPAlarmState INTEGER, sipDS3PLCPUASs Counter32 } sipDS3PLCPIndex OBJECT-TYPE SYNTAX IfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the interface for which this entry contains management information. " ::= { sipDS3PLCPEntry 1 } Brown & Tesink [Page 19] RFC 1694 SMDS Interface Objects August 1994 sipDS3PLCPSEFSs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A DS3 Severely Errored Framing Second (SEFS) is a count of one-second intervals containing one or more SEF events. A Severely Errored Framing (SEF) event is declared when an error in the A1 octet and an error in the A2 octet of a framing octet pair (i.e., errors in both framing octets), or two consecutive invalid and/or nonsequential Path Overhead Identifier octets are detected." ::= { sipDS3PLCPEntry 2 } sipDS3PLCPAlarmState OBJECT-TYPE SYNTAX INTEGER { noAlarm (1), receivedFarEndAlarm (2), incomingLOF (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is an alarm present for the DS3 PLCP. The value receivedFarEndAlarm means that the DS3 PLCP has received an incoming Yellow Signal, the value incomingLOF means that the DS3 PLCP has declared a loss of frame (LOF) failure condition, and the value noAlarm means that there are no alarms present. See TR-TSV-000773 for a description of alarm states." ::= { sipDS3PLCPEntry 3 } sipDS3PLCPUASs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds, as defined by TR-TSV-000773, encountered by the PLCP." ::= { sipDS3PLCPEntry 4 } -- The SMDS Applications group -- Applications that have been identified for this group are: Brown & Tesink [Page 20] RFC 1694 SMDS Interface Objects August 1994 -- * IP-over-SMDS (details are specified in RFC 1209) smdsApplications OBJECT IDENTIFIER ::= { sip 4 } ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 } -- Although the objects in this group are read-only, at the -- agent's discretion they may be made read-write so that the -- management station, when appropriately authorized, may -- change the addressing information related to the -- configuration of a logical IP subnetwork implemented on -- top of SMDS. -- This table is necessary to support RFC1209 (IP-over-SMDS) -- and gives information on the Group Addresses and ARP -- Addresses used in the Logical IP subnetwork. -- One SMDS address may be associated with multiple IP -- addresses. One SNI may be associated with multiple LISs. ipOverSMDSTable OBJECT-TYPE SYNTAX SEQUENCE OF IpOverSMDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of addressing information relevant to this entity's IP addresses." ::= { ipOverSMDS 1 } ipOverSMDSEntry OBJECT-TYPE SYNTAX IpOverSMDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The addressing information for one of this entity's IP addresses." INDEX { ipOverSMDSIndex, ipOverSMDSAddress } ::= { ipOverSMDSTable 1 } IpOverSMDSEntry ::= SEQUENCE { ipOverSMDSIndex IfIndex, ipOverSMDSAddress IpAddress, ipOverSMDSHA SMDSAddress, ipOverSMDSLISGA SMDSAddress, ipOverSMDSARPReq SMDSAddress } ipOverSMDSIndex OBJECT-TYPE Brown & Tesink [Page 21] RFC 1694 SMDS Interface Objects August 1994 SYNTAX IfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the interface for which this entry contains management information. " ::= { ipOverSMDSEntry 1 } ipOverSMDSAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address to which this entry's addressing information pertains." ::= { ipOverSMDSEntry 2 } ipOverSMDSHA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SMDS Individual address of the IP station." ::= { ipOverSMDSEntry 3 } ipOverSMDSLISGA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SMDS Group Address that has been configured to identify the SMDS Subscriber-Network Interfaces (SNIs) of all members of the Logical IP Subnetwork (LIS) connected to the network supporting SMDS." ::= { ipOverSMDSEntry 4 } ipOverSMDSARPReq OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SMDS address (individual or group) to which ARP Requests are to be sent." ::= { ipOverSMDSEntry 5 } -- The SMDS Carrier Selection group Brown & Tesink [Page 22] RFC 1694 SMDS Interface Objects August 1994 -- This group is used as a place holder -- for carrier selection objects. smdsCarrierSelection OBJECT IDENTIFIER ::= { sip 5 } -- The SIP Error Log sipErrorLog OBJECT IDENTIFIER ::= { sip 6 } sipL3PDUErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF SipL3PDUErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains the latest occurrence of the following syntactical SIP L3PDU errors: - Destination Address Field Format Error, The following pertains to the 60 least significant bits of the 64 bit address field. The 60 bits contained in the address subfield can be used to represent addresses up to 15 decimal digits. Each decimal digit shall be encoded into four bits using Binary Coded Decimal (BCD), with the most significant digit occurring left-most. If not all 15 digits are required, then the remainder of this field shall be padded on the right with bits set to one. An error is considered to have occurred: a). if the first four bits of the address subfield are not BCD, OR b). if the first four bits of the address subfield are populated with the country code value 0001, AND the 40 bits which follow are not Binary Coded Decimal (BCD) encoded values of the 10 digit addresses, OR the remaining 16 least significant bits are not populated with 1's, OR c). if the address subfield is not correct according to another numbering plan which is dependent upon the carrier assigning the numbers and offering SMDS. - Source Address Field Format Error, The description of this parameter is the same as the description of the Destination Address Field Format Error. Brown & Tesink [Page 23] RFC 1694 SMDS Interface Objects August 1994 - Invalid BAsize Field Value, An error is considered to have occurred when the BAsize field of an SIP L3PDU contains a value less that 32, greater than 9220 octets without the CRC32 field present, greater than 9224 octets with the CRC32 field present, or not equal to a multiple of 4 octets, - Invalid Header Extension Length Field Value, An error is considered to have occurred when the Header Extension Length field value is not equal 3. - Invalid Header Extension - Element Length, An error is considered to have occurred when the Header Extension - Element Length is greater than 12. - Invalid Header Extension - Version Element Position, Length, or Value, An error is considered to have occurred when a Version element with Length=3, Type=0, and Value=1 does not appear first within the Header Extension, or an element Type=0 appears somewhere other than within the first three octets in the Header Extension. - Invalid Header Extension - Carrier Selection Element Position, Length, Value or Format, An error is considered to have occurred when a Carrier Selection element does not appear second within the Header Extension, if the Element Type does not equal 1, the Element Length does not equal 4, 6, or 8, the Element Value field is not four BCD encoded decimal digits used in specifying the Carrier Identification Code (CIC), or the identified CIC code is invalid. - Header Extension PAD Error An error is considered to have occurred when the Header Extension PAD is 9 octets in length, or if the Header Extension PAD is greater than zero Brown & Tesink [Page 24] RFC 1694 SMDS Interface Objects August 1994 octets in length and the Header Extension PAD does not follow all Header Extension elements or does not begin with at least one octet of all zeros. - BEtag Mismatch Error, An error is considered to have occurred when the Beginning-End Tags in the SIP L3PDU header and trailer are not equal. - BAsize Field not equal to Length Field Error, An error is considered to have occurred when the value of the BAsize Field does not equal the value of the Length Field. - Incorrect Length Error, and An error is considered to have occurred when the the Length field value is not equal to the portion of the SIP L3PDU which extends from the Destination Address field up to and including the CRC32 field (if present) or up to and including the PAD field (if the CRC32 field is not present). As an optional check, an error is considered to have occurred when the length of a partially received SIP L3PDU exceeds the BAsize value. - MRI Timeout Error. An error is considered to have occurred when the elapsed time between receipt of BOM and corresponding EOM exceeds the value of the MRI (Message Receive Interval) for a particular transport signal format. An entry is indexed by interface number and error type, and contains Source Address, Destination Address and a timestamp. All these errors are counted in the sipL3Errors counter. When sipL3PDUErrorTimeStamp is equal to zero, the SipL3PDUErrorEntry does not contain any valid information." ::= { sipErrorLog 1 } sipL3PDUErrorEntry OBJECT-TYPE SYNTAX SipL3PDUErrorEntry MAX-ACCESS not-accessible Brown & Tesink [Page 25] RFC 1694 SMDS Interface Objects August 1994 STATUS current DESCRIPTION "An entry in the service disagreement table." INDEX { sipL3PDUErrorIndex, sipL3PDUErrorType } ::= { sipL3PDUErrorTable 1 } SipL3PDUErrorEntry ::= SEQUENCE { sipL3PDUErrorIndex IfIndex, sipL3PDUErrorType INTEGER, sipL3PDUErrorSA SMDSAddress, sipL3PDUErrorDA SMDSAddress, sipL3PDUErrorTimeStamp TimeStamp } sipL3PDUErrorIndex OBJECT-TYPE SYNTAX IfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the interface for which this entry contains management information." ::= { sipL3PDUErrorEntry 1 } sipL3PDUErrorType OBJECT-TYPE SYNTAX INTEGER { erroredDAFieldFormat (1), erroredSAFieldFormat (2), invalidBAsizeFieldValue (3), invalidHdrExtLength (4), invalidHdrExtElementLength (5), invalidHdrExtVersionElementPositionLenthOrValue (6), invalidHdrExtCarSelectElementPositionLenghtValueOrFormat (7), hePADError (8), beTagMismatch (9), baSizeFieldNotEqualToLengthField (10), incorrectLength (11), mriTimeout (12) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of error." ::= { sipL3PDUErrorEntry 2 } sipL3PDUErrorSA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only Brown & Tesink [Page 26] RFC 1694 SMDS Interface Objects August 1994 STATUS current DESCRIPTION "A rejected SMDS source address." ::= { sipL3PDUErrorEntry 3 } sipL3PDUErrorDA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A rejected SMDS destination address." ::= { sipL3PDUErrorEntry 4 } sipL3PDUErrorTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp for the service disagreement. The timestamp contains the value of sysUpTime at the latest occurrence of this type of service disagreement. See textual description under sipL3PDUErrorTable for boundary conditions." ::= { sipL3PDUErrorEntry 5 } -- The DXI Group sipDxiTable OBJECT-TYPE SYNTAX SEQUENCE OF SipDxiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DXI table." ::= { sipMIBObjects 1 } sipDxiEntry OBJECT-TYPE SYNTAX SipDxiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DXI table." INDEX { ifIndex } ::= { sipDxiTable 1 } SipDxiEntry ::= SEQUENCE { sipDxiCrc Brown & Tesink [Page 27] RFC 1694 SMDS Interface Objects August 1994 INTEGER, sipDxiOutDiscards Counter32, sipDxiInErrors Counter32, sipDxiInAborts Counter32, sipDxiInTestFrames Counter32, sipDxiOutTestFrames Counter32, sipDxiHbpNoAcks Counter32 } sipDxiCrc OBJECT-TYPE SYNTAX INTEGER { crc16(1), crc32(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the type of Frame Checksum used by DXI. Current choices include CCITT CRC16 or CRC32." ::= { sipDxiEntry 1 } sipDxiOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound frames discarded because of congestion." ::= { sipDxiEntry 2 } sipDxiInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound frames discarded because of errors such as frame checksum (CRC) violations, non-integral number of octets, address and control field violations, and frame size errors." Brown & Tesink [Page 28] RFC 1694 SMDS Interface Objects August 1994 ::= { sipDxiEntry 3 } sipDxiInAborts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound frames discarded because of an abort bit sequence (1111111) received before closing flag." ::= { sipDxiEntry 4 } sipDxiInTestFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of unerrored, inbound Test frames received (generally as part of Heart Beat Poll procedure)." ::= { sipDxiEntry 5 } sipDxiOutTestFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of unerrored, outbound Test frames sent (generally as part of Heart Beat Poll procedure)." ::= { sipDxiEntry 6 } sipDxiHbpNoAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Heart Beat Poll (HBP) No Ack timeouts." ::= { sipDxiEntry 7 } -- conformance information smdsConformance OBJECT IDENTIFIER ::= { sipMIB 2 } Brown & Tesink [Page 29] RFC 1694 SMDS Interface Objects August 1994 smdsGroups OBJECT IDENTIFIER ::= { smdsConformance 1 } smdsCompliances OBJECT IDENTIFIER ::= { smdsConformance 2 } -- compliance statements smdsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SMDS interfaces." MODULE -- this module MANDATORY-GROUPS { sipLevel3Stuff } GROUP sipLevel2Stuff DESCRIPTION "This group is mandatory only for those interfaces (SNIs) which run SIP Level 2." GROUP sipDS1PLCPStuff DESCRIPTION "This group is mandatory only for those interfaces (SNIs) which run the DS1 PLCP." GROUP sipDS3PLCPStuff DESCRIPTION "This group is mandatory only for those interfaces (SNIs) which run the DS3 PLCP." GROUP sipIPApplicationsStuff DESCRIPTION "This group is mandatory only for interfaces operating IP over SMDS in accordance with RFC1209." GROUP sipDxiStuff DESCRIPTION "This group is mandatory only for those interfaces (DXI-SNI) which run the DXI protocol." ::= { smdsCompliances 1 } -- units of conformance sipLevel3Stuff OBJECT-GROUP OBJECTS { sipL3Index, sipL3VersionSupport, sipL3PDUErrorIndex, sipL3PDUErrorType, Brown & Tesink [Page 30] RFC 1694 SMDS Interface Objects August 1994 sipL3PDUErrorSA, sipL3PDUErrorDA, sipL3PDUErrorTimeStamp } STATUS current DESCRIPTION "A collection of objects providing information applicable to all SMDS interfaces." ::= { smdsGroups 1 } sipLevel2Stuff OBJECT-GROUP OBJECTS { sipL2Index, sipL2HcsOrCRCErrors, sipL2PayloadLengthErrors, sipL2SequenceNumberErrors, sipL2MidCurrentlyActiveErrors, sipL2BomOrSSMsMIDErrors, sipL2EomsMIDErrors } STATUS current DESCRIPTION "A collection of objects providing information specific to interfaces using the SIP Level 2." ::= { smdsGroups 2 } sipDS1PLCPStuff OBJECT-GROUP OBJECTS { sipDS1PLCPIndex, sipDS1PLCPSEFSs, sipDS1PLCPAlarmState, sipDS1PLCPUASs } STATUS current DESCRIPTION "A collection of objects providing information specific to interfaces using the DS1 PLCP." ::= { smdsGroups 3 } sipDS3PLCPStuff OBJECT-GROUP OBJECTS { sipDS3PLCPIndex, sipDS3PLCPSEFSs, sipDS3PLCPAlarmState, sipDS3PLCPUASs } STATUS current DESCRIPTION "A collection of objects providing information specific to interfaces using the DS3 PLCP." ::= { smdsGroups 4 } sipIPApplicationsStuff OBJECT-GROUP OBJECTS { ipOverSMDSIndex, ipOverSMDSAddress, ipOverSMDSHA, ipOverSMDSLISGA, ipOverSMDSARPReq } STATUS current DESCRIPTION "A collection of objects providing information for running IP over SMDS." ::= { smdsGroups 5 } Brown & Tesink [Page 31] RFC 1694 SMDS Interface Objects August 1994 sipDxiStuff OBJECT-GROUP OBJECTS { sipDxiCrc, sipDxiOutDiscards, sipDxiInErrors, sipDxiInAborts, sipDxiInTestFrames, sipDxiOutTestFrames, sipDxiHbpNoAcks } STATUS current DESCRIPTION "A collection of objects providing information specific to interfaces using the DXI protocol." ::= { smdsGroups 6 } END 5. Acknowledgments This specification is a product of the ifMIB Working Group. 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [4] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. Brown & Tesink [Page 32] RFC 1694 SMDS Interface Objects August 1994 [6] 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, Inc., Performance Systems International, March 1991. [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December 1987. [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, December 1987. [9] McCloghrie, K., and F. Kastenholz, "Evolution of Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [10] Cox, T., and K. Tesink, Editors, "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 1407, Bellcore, January 1993. [11] Baker, F., and J. Watt, Editors, "Definitions of Managed Objects for the DS1/E1 Interface Type", RFC 1406, Advanced Computer Communications, Newbridge Networks Corporation, January 1993. [12] Cox, T., and K. Tesink, Editors, "Definition of Managed Objects for the SMDS Interface Type", RFC 1304, Bellcore, February 1992. [13] "Generic System Requirements in Support of Switched Multi-megabit Data Service", Bellcore Technical Reference, TR-TSV-000772, Issue 1, May 1991. [14] "Local Access System Generic Requirements, Objectives, and Interfaces in Support of Switched Multi-megabit Data Service", Bellcore Technical Reference, TR-TSV-000773, Issue 1, June 1990. [15] Piscitello, D., and J. Lawrence, Editors, The Transmission of IP Datagrams over the SMDS Service", RFC 1209, Bell Communications Research, March 1991. [16] "Generic Requirements For SMDS Customer Network Management Service", Bellcore TR-TSV-001062, Issue 1, March 1993, and Supplement 1, December 1993. [17] Cox, R., and K. Tesink, "Definitions of Managed Objects for SMDS Subscription", Version 2.1, Bellcore, August 1992. Brown & Tesink [Page 33] RFC 1694 SMDS Interface Objects August 1994 [18] Frame Based Interface Protocol for SMDS Networks - Data Exchange Interface / Subscriber Network Interface Revision 1.0 - SMDS Interest Group SIG-TS-005/1993, February 2, 1993. [19] Frame Based Interface Protocol for SMDS Networks - SIP Relay Interface Revision 1.0 - SMDS Interest Group SIG-TS-006/1993, February 2, 1993. [20] "Generic Requirements For Low Speed SMDS Access", Bellcore TR- TSV-001239, Issue 1, December 1993. [21] ATM Forum, "ATM User Network Interface Specification", Version 3.0, September 1993. [22] Ahmed, M., and K. Tesink, Editors, "Definitions of Managed Objects for ATM Management", RFC 1695, Bellcore, August 1994. [23] Brown, R., Editor, "Definitions of Managed Objects for Frame Relay Service", RFC 1604, Bellcore, March 1994. [24] Specification for Implementation of SMDS over an ATM-based Public UNI - Cedric Druce, Max Figueroa, Bellcore - SIG TWG-1993/043, SMDS Interest Group Technical Working Group, Work in Progress, August 24, 1993. [25] Brown, T. and K. Tesink, Editors), "Definitions of Managed Objects for the SONET Interface Type, RFC 1595, Bellcore, March 1994. 7. Security Considerations Security issues are not discussed in this memo. Brown & Tesink [Page 34] RFC 1694 SMDS Interface Objects August 1994 8. Authors' Addresses Tracy A. Brown Bell Communications Research 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-2107 EMail: tacox@mail.bellcore.com Kaj Tesink Bell Communications Research 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Brown & Tesink [Page 35] snmp-mibs-downloader-1.1/mibrfcs/rfc1696.txt0000644000000000000000000015144611402176071015602 0ustar Network Working Group J. Barnes Request for Comments: 1696 Xylogics, Inc. Category: Standards Track L. Brown Motorola R. Royston US Robotics, Inc. S. Waldbusser Carnegie Mellon University August 1994 Modem Management Information Base (MIB) using SMIv2 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 ................................................. 1 2 The SNMPv2 Network Management Framework ...................... 2 2.1 Object Definitions ......................................... 2 3 Definitions .................................................. 2 4 Acknowledgements ............................................. 30 5. Security Considerations ..................................... 30 6. Authors' Addresses .......................................... 31 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. This MIB module provides a set of objects that are the minimum necessary to provide the ability to monitor and control those devices, and is consistent with the SNMP framework and existing SNMP standards. Barnes, Brown, Royston & Waldbusser [Page 1] RFC 1696 Modem MIB August 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. 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 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. Definitions Modem-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Counter32, Integer32 FROM SNMPv2-SMI DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2 FROM RFC1213-MIB; mdmMIB MODULE-IDENTITY LAST-UPDATED "9406120000Z" ORGANIZATION "IETF Modem Management Working Group" Barnes, Brown, Royston & Waldbusser [Page 2] RFC 1696 Modem MIB August 1994 CONTACT-INFO " Steven Waldbusser Postal: Carnegie Mellon University 5000 Forbes Ave Pittsburgh, PA, 15213 US Tel: +1 412 268 6628 Fax: +1 412 268 4987 E-mail: waldbusser@cmu.edu" DESCRIPTION "The MIB module for management of dial-up modems." ::= { mdmMIB 1 } mdmMib OBJECT IDENTIFIER ::= { mib-2 38 } mdmMIBObjects OBJECT IDENTIFIER ::= { mdmMIB 1 } -- conformance information mdmConformance OBJECT IDENTIFIER ::= { mdmMIB 2 } mdmCompliances OBJECT IDENTIFIER ::= { mdmConformance 1 } mdmGroups OBJECT IDENTIFIER ::= { mdmConformance 2 } -- units of conformance mdmIDGroup OBJECT-GROUP OBJECTS { mdmIDManufacturerOID, mdmIDProductDetails } STATUS current DESCRIPTION "A collection of objects that identify the manufacturer and model information for a modem." ::= { mdmGroups 1 } mdmLineInterfaceGroup OBJECT-GROUP OBJECTS { mdmLineCarrierLossTime, mdmLineState, mdmLineCapabilitiesID, mdmLineCapabilitiesEnableRequested, mdmLineCapabilitiesEnableGranted } STATUS current DESCRIPTION "A collection of objects that describe the configuration and state of the modem's line interface." ::= { mdmGroups 2 } mdmDTEInterfaceGroup OBJECT-GROUP Barnes, Brown, Royston & Waldbusser [Page 3] RFC 1696 Modem MIB August 1994 OBJECTS { mdmDTEActionDTROnToOff, mdmDTEActionDTROffToOn, mdmDTESyncTimingSource, mdmDTESyncAsyncMode, mdmDTEInactivityTimeout } STATUS current DESCRIPTION "A collection of objects that describe the configuration and state of the modem's DTE interface." ::= { mdmGroups 3 } mdmCallControlGroup OBJECT-GROUP OBJECTS { mdmCCRingsBeforeAnswer, mdmCCCallSetUpFailTimer, mdmCCResultCodeEnable, mdmCCEscapeAction, mdmCCCallDuration, mdmCCConnectionFailReason, mdmCCStoredDialString } STATUS current DESCRIPTION "A collection of objects that describe the configuration of call control capabilities on the modem and the status of calls placed with this modem." ::= { mdmGroups 4 } mdmErrorControlGroup OBJECT-GROUP OBJECTS { mdmECErrorControlUsed } STATUS current DESCRIPTION "A collection of objects that describe the configuration and state of error control on a modem." ::= { mdmGroups 5 } mdmDataCompressionGroup OBJECT-GROUP OBJECTS { mdmDCCompressionTypeUsed } STATUS current DESCRIPTION "A collection of objects that describe the configuration and state of data compression on a modem." ::= { mdmGroups 6 } mdmSignalConvertorGroup OBJECT-GROUP OBJECTS { mdmSCCurrentLineReceiveRate, mdmSCCurrentLineTransmitRate, mdmSCInitialLineReceiveRate, mdmSCInitialLineTransmitRate, mdmSCModulationSchemeUsed } STATUS current DESCRIPTION "A collection of objects that describe the configuration and state of error control on a modem." ::= { mdmGroups 7 } mdmStatisticsGroup OBJECT-GROUP Barnes, Brown, Royston & Waldbusser [Page 4] RFC 1696 Modem MIB August 1994 OBJECTS { mdmStatsRingNoAnswers, mdmStatsIncomingConnectionFailures, mdmStatsIncomingConnectionCompletions, mdmStatsFailedDialAttempts, mdmStatsOutgoingConnectionFailures, mdmStatsOutgoingConnectionCompletions, mdmStatsRetrains, mdmStats2400OrLessConnections, mdmStats2400To14400Connections, mdmStatsGreaterThan14400Connections, mdmStatsErrorControlledConnections, mdmStatsCompressedConnections, mdmStatsCompressionEfficiency, mdmStatsSentOctets, mdmStatsReceivedOctets, mdmStatsSentDataFrames, mdmStatsReceivedDataFrames, mdmStatsResentFrames, mdmStatsErrorFrames } STATUS current DESCRIPTION "A collection of objects that describe the state of calls on this modem." ::= { mdmGroups 8 } mdmNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of modem rows in the modem table. This value defines the maximum value of the mdmIndex object." ::= { mdmMIBObjects 1 } -- The modem ID table. mdmIDTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmIDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The base table for the modems managed by this MIB. The mdmLineTable, mdmDTEInterfaceTable, mdmCallControlTable, and mdmStatsTable all augment the rows defined in this table." ::= { mdmMIBObjects 2 } mdmIDEntry OBJECT-TYPE SYNTAX MdmIDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One Barnes, Brown, Royston & Waldbusser [Page 5] RFC 1696 Modem MIB August 1994 entry exists for each modem managed by the agent." INDEX { mdmIndex } ::= { mdmIDTable 1 } MdmIDEntry ::= SEQUENCE { mdmIndex Integer32, mdmIDManufacturerOID OBJECT IDENTIFIER, mdmIDProductDetails DisplayString } mdmIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique number for each modem that ranges from 1 to mdmNumber. The value must remain constant at least from one re-initialization of the network management agent to the next." ::= { mdmIDEntry 1 } mdmIDManufacturerOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This value is intended to identify the manufacturer, model, and version of this modem. This may be used to identify the existance of enterprise-specific functions and behaviours." REFERENCE "V.58 attribute manufacturerID subfield ManufacturerOI" ::= { mdmIDEntry 2 } mdmIDProductDetails OBJECT-TYPE SYNTAX DisplayString (SIZE (0..79)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of this device, including the manufacturer's name, modem model name, hardware revision, firmware revision, and optionally, its serial number. The exact format of this description is defined by the vendor. This description may only contain characters from the NVT ASCII character set." REFERENCE "V.58 attribute manufacturerID subfield productDetails" ::= { mdmIDEntry 3 } Barnes, Brown, Royston & Waldbusser [Page 6] RFC 1696 Modem MIB August 1994 -- The modem Line Interface Table mdmLineTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmLineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The modem Line Table augments the modem ID table." ::= { mdmMIBObjects 3 } mdmLineEntry OBJECT-TYPE SYNTAX MdmLineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One entry exists for each modem managed by the agent." AUGMENTS { mdmIDEntry } ::= { mdmLineTable 1 } MdmLineEntry ::= SEQUENCE { mdmLineCarrierLossTime Integer32, mdmLineState INTEGER } mdmLineCarrierLossTime OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "Duration in 10ths of a second the modem waits after loss of carrier before hanging up. If this value is set to `255', the modem will not hang up upon loss of carrier. This allows the modem to distinguish between a momentary lapse in line quality and a true disconnect and can be useful to tune the tolerance of the modem to lines of poor quality." REFERENCE "V.58 lineSignalFailDisconnectTimer" ::= { mdmLineEntry 1 } mdmLineState OBJECT-TYPE SYNTAX INTEGER { unknown(1), onHook(2), offHook(3), -- and not connected connected(4), busiedOut(5), reset(6) } Barnes, Brown, Royston & Waldbusser [Page 7] RFC 1696 Modem MIB August 1994 MAX-ACCESS read-write STATUS current DESCRIPTION "Allows the inspection and alteration of the state of the modem. Management commands may change the state to `on- hook', `busied-out', or `reset' from any state. No other alterations are permitted from the management protocol. When this object is set to reset, the modem shall be reset and the value will change to the modem's new, implementation dependent state." ::= { mdmLineEntry 2 } mdmLineCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmLineCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of protocol capabilities for this modem." ::= { mdmMIBObjects 4 } mdmLineCapabilitiesEntry OBJECT-TYPE SYNTAX MdmLineCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A listing of the protocol(s) that this modem is capable of. Entries in this table are created only by the agent. One entry exists for each protocol that the modem is capable of, regardless of whether that protocol is enabled or not. This table is useful for providing an inventory of the capabilities on a modem, and allowing the manager to enable or disable capabilities from the menu of available possibilities. Row creation is not required to enable or disable capabilities." INDEX { mdmIndex, mdmLineCapabilitiesIndex } ::= { mdmLineCapabilitiesTable 1 } MdmLineCapabilitiesEntry ::= SEQUENCE { mdmLineCapabilitiesIndex Integer32, mdmLineCapabilitiesID OBJECT IDENTIFIER, mdmLineCapabilitiesEnableRequested INTEGER, mdmLineCapabilitiesEnableGranted INTEGER } mdmLineCapabilitiesIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible Barnes, Brown, Royston & Waldbusser [Page 8] RFC 1696 Modem MIB August 1994 STATUS current DESCRIPTION "A unique index for this capabilities entry." ::= { mdmLineCapabilitiesEntry 1 } mdmLineCapabilitiesID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An identifier for this capability. Standard protocol capabilities will have identifiers registered in this document or other companion standards documents. Proprietary protocol capabilities will be registered by their respective organization. All capabilities, standard or vendor-specific, shall be registered in this table." ::= { mdmLineCapabilitiesEntry 2 } mdmLineCapabilitiesEnableRequested OBJECT-TYPE SYNTAX INTEGER { disabled(1), optional(2), preferred(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The requested configuration of this capability. If this value is 'disabled(1)', this is a request to disable this protocol. If this value is 'preferred(3)', this is a request to enable this protocol, and to prefer it in any negotiation over other appropriate protocols that have a value of 'optional(2)'." DEFVAL { preferred } ::= { mdmLineCapabilitiesEntry 3 } mdmLineCapabilitiesEnableGranted OBJECT-TYPE SYNTAX INTEGER { disabled(1), optional(2), preferred(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual configuration of this capability. The agent shall attempt to set this as close as possible to the associated mdmLineCapabilitiesEnableRequested value. The Barnes, Brown, Royston & Waldbusser [Page 9] RFC 1696 Modem MIB August 1994 agent shall make this determination in an implementation- specific manner that may take into account the configuration of other capabilities or other considerations. The modem will choose in an implementation-specific manner between multiple mutually-exclusive capabilities that each have the same (non-disabled) value. However, the modem must prefer all capabilities with a value of 'preferred(3)' over all capabilities with a value of 'optional(2)'. In other words, if there are one or more mutually-exclusive capabilities (e.g. V.32 and V.32bis) that are set to `preferred', the agent must choose one in an implementation-specific manner. Otherwise, if there are one or more mutually-exclusive capabilities that are set to `optional', the agent must choose one in an implementation- specific manner." ::= { mdmLineCapabilitiesEntry 4 } mdmLineCapabilities OBJECT IDENTIFIER ::= { mdmMIBObjects 5 } mdmLineCapabilitiesV21 OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.21" ::= { mdmLineCapabilities 1 } mdmLineCapabilitiesV22 OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.22" ::= { mdmLineCapabilities 2 } mdmLineCapabilitiesV22bis OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.22bis" ::= { mdmLineCapabilities 3 } mdmLineCapabilitiesV23CC OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.23CC" ::= { mdmLineCapabilities 4 } mdmLineCapabilitiesV23SC OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.23SC" Barnes, Brown, Royston & Waldbusser [Page 10] RFC 1696 Modem MIB August 1994 ::= { mdmLineCapabilities 5 } mdmLineCapabilitiesV25bis OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.25bis" ::= { mdmLineCapabilities 6 } mdmLineCapabilitiesV26bis OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.26bis" ::= { mdmLineCapabilities 7 } mdmLineCapabilitiesV26ter OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.26ter" ::= { mdmLineCapabilities 8 } mdmLineCapabilitiesV27ter OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.27ter" ::= { mdmLineCapabilities 9 } mdmLineCapabilitiesV32 OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.32" ::= { mdmLineCapabilities 10 } mdmLineCapabilitiesV32bis OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.32bis" ::= { mdmLineCapabilities 11 } mdmLineCapabilitiesV32terbo OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.32terbo" ::= { mdmLineCapabilities 12 } mdmLineCapabilitiesVFC OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.FC" Barnes, Brown, Royston & Waldbusser [Page 11] RFC 1696 Modem MIB August 1994 ::= { mdmLineCapabilities 13 } mdmLineCapabilitiesV34 OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.34" ::= { mdmLineCapabilities 14 } mdmLineCapabilitiesV42 OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.42" ::= { mdmLineCapabilities 15 } mdmLineCapabilitiesV42bis OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.42bis" ::= { mdmLineCapabilities 16 } mdmLineCapabilitiesMNP1 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP1" ::= { mdmLineCapabilities 17 } mdmLineCapabilitiesMNP2 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP2" ::= { mdmLineCapabilities 18 } mdmLineCapabilitiesMNP3 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP3" ::= { mdmLineCapabilities 19 } mdmLineCapabilitiesMNP4 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP4" ::= { mdmLineCapabilities 20 } mdmLineCapabilitiesMNP5 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP5" Barnes, Brown, Royston & Waldbusser [Page 12] RFC 1696 Modem MIB August 1994 ::= { mdmLineCapabilities 21 } mdmLineCapabilitiesMNP6 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP6" ::= { mdmLineCapabilities 22 } mdmLineCapabilitiesMNP7 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP7" ::= { mdmLineCapabilities 23 } mdmLineCapabilitiesMNP8 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP8" ::= { mdmLineCapabilities 24 } mdmLineCapabilitiesMNP9 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP9" ::= { mdmLineCapabilities 25 } mdmLineCapabilitiesMNP10 OBJECT-IDENTITY STATUS current DESCRIPTION "MNP10" ::= { mdmLineCapabilities 26 } mdmLineCapabilitiesV29 OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.29" ::= { mdmLineCapabilities 27 } mdmLineCapabilitiesV33 OBJECT-IDENTITY STATUS current DESCRIPTION "ITU V.33" ::= { mdmLineCapabilities 28 } mdmLineCapabilitiesBell208 OBJECT-IDENTITY STATUS current DESCRIPTION "Bell 208" Barnes, Brown, Royston & Waldbusser [Page 13] RFC 1696 Modem MIB August 1994 ::= { mdmLineCapabilities 29 } -- DTE Interface Table mdmDTEInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmDTEInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The modem DTE Interface Table augments the modem ID table." ::= { mdmMIBObjects 6 } mdmDTEInterfaceEntry OBJECT-TYPE SYNTAX MdmDTEInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One entry exists for each modem managed by the agent." AUGMENTS { mdmIDEntry } ::= { mdmDTEInterfaceTable 1 } MdmDTEInterfaceEntry ::= SEQUENCE { mdmDTEActionDTROnToOff INTEGER, mdmDTEActionDTROffToOn INTEGER, mdmDTESyncTimingSource INTEGER, mdmDTESyncAsyncMode INTEGER, mdmDTEInactivityTimeout Integer32 } mdmDTEActionDTROnToOff OBJECT-TYPE SYNTAX INTEGER { ignore(1), escapeToCommandMode(2), disconnectCall(3), resetModem(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Defines the action the modem will take when DTR drops. If the value is set to ignore(1), the modem takes no action when DTR drops. Typically, mdmDTEActionDTROffToOn would also be set to ignore(1) if this object is set to ignore(1). If the value is escapeToCommandMode(2), the modem remains Barnes, Brown, Royston & Waldbusser [Page 14] RFC 1696 Modem MIB August 1994 connected and enters command mode. If the value is disconnectCall(3), the current call (if any) is terminated and the modem will not auto-answer while DTR is off. If the value is resetModem(4), the current call (if any) is terminated and the modem is reset." DEFVAL { disconnectCall } ::= { mdmDTEInterfaceEntry 1 } mdmDTEActionDTROffToOn OBJECT-TYPE SYNTAX INTEGER { ignore(1), enableDial(2), autoAnswerEnable(3), establishConnection(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Defines the action the modem will take when DTR is raised. If the value is set to ignore(1), the modem takes no action when DTR is raised. Typically, mdmDTEActionDTROnToOff would also be set to ignore(1) if this object is set to ignore(1). If the value is set to enableDial(2), the modem prepares to dial an outgoing call. If the value is set to autoAnswerEnable(3), the modem will be configured to answer any incoming call. If the value is set to establishConnection(4), the modem dials an implementation specific number. Immediately after any reset or power-on of the modem, if the DTR is high, the action specified here will be executed." DEFVAL { autoAnswerEnable } ::= { mdmDTEInterfaceEntry 2 } mdmDTESyncTimingSource OBJECT-TYPE SYNTAX INTEGER { internal(1), external(2), loopback(3), network(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The clock source for synchronous transmissions. If set to internal(1), the modem is the clock source and sends the Barnes, Brown, Royston & Waldbusser [Page 15] RFC 1696 Modem MIB August 1994 clock signals to the DTE. If set to external(2), the transmit clock signals are provided by the DTE. If loopback(3), the modem receiver clock is used for the transmit clock. If network(4), the clock signals are supplied by the DCE interface. If the modem is not in synchronous mode, setting this object will have no effect on the current operations of the modem." REFERENCE "V.58 transmitClockSource" DEFVAL { internal } ::= { mdmDTEInterfaceEntry 3 } mdmDTESyncAsyncMode OBJECT-TYPE SYNTAX INTEGER { async(1), sync(2), syncAfterDial(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The operational mode of the modem. If the value is syncAfterDial(3), the modem will accept commands in asynchronous mode and change to synchronous mode to pass data after a dial sequence has been executed." DEFVAL { async } ::= { mdmDTEInterfaceEntry 4 } mdmDTEInactivityTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of idle time in minutes that the modem will wait before disconnecting a connection. When a call is connected and no data is transferred (continuous marking condition) on both circuits 103 and 104 for the specified time, the DCE disconnects the call. If the value is 0, no idle disconnect will occur. This function applies to asynchronous dial operations only and is intended for administrative control over idle connections." REFERENCE "V.58 inactivityTimerSelect" DEFVAL { 0 } ::= { mdmDTEInterfaceEntry 5 } -- The Call Control Table Barnes, Brown, Royston & Waldbusser [Page 16] RFC 1696 Modem MIB August 1994 mdmCallControlTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmCallControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The modem Call Control Table augments the modem ID table." ::= { mdmMIBObjects 7 } mdmCallControlEntry OBJECT-TYPE SYNTAX MdmCallControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One entry exists for each modem managed by the agent." AUGMENTS { mdmIDEntry } ::= { mdmCallControlTable 1 } MdmCallControlEntry ::= SEQUENCE { mdmCCRingsBeforeAnswer Integer32, mdmCCCallSetUpFailTimer Integer32, mdmCCResultCodeEnable INTEGER, mdmCCEscapeAction INTEGER, mdmCCCallDuration Integer32, mdmCCConnectionFailReason INTEGER } mdmCCRingsBeforeAnswer OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "Determines which ring the modem will wait to answer the phone on. If this value is `0', the modem will not go offhook and answer a call when a ring signal is detected." REFERENCE "V.58 ringsBeforeAnswer" DEFVAL { 1 } ::= { mdmCallControlEntry 1 } mdmCCCallSetUpFailTimer OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "This parameter specifies the amount of time, in seconds, that the modem shall allow between either answering a call (automatically or manually) or completion of dialing, and establishment of a connection with the remote modem. If no Barnes, Brown, Royston & Waldbusser [Page 17] RFC 1696 Modem MIB August 1994 connection is established during this time, the modem disconnects from the line and returns a result code indicating the cause of the disconnection. In TIA-602, this is controlled by the value in the S7 register." REFERENCE "V.58 callSetUpFailTimer" DEFVAL { 30 } ::= { mdmCallControlEntry 2 } mdmCCResultCodeEnable OBJECT-TYPE SYNTAX INTEGER { disabled(1), numericEnabled(2), verboseEnabled(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "When disabled, the DCE shall issue no 'result codes' of any kind to the DTE either in response to unsolicited events (eg. ring signal), or commands. In TIA-602, this is controlled by the ATQ command. When numericEnabled, the DCE shall issue result codes in numeric form. When verboseEnabled, the DCE shall issue result codes in a verbose, textual form." REFERENCE "V.58 responseModeSelect" DEFVAL { verboseEnabled } ::= { mdmCallControlEntry 3 } mdmCCEscapeAction OBJECT-TYPE SYNTAX INTEGER { ignoreEscape(1), hangUp(2), enterCommandMode(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The modem's action upon successfully recognizing the 'escape to command mode' character sequence." DEFVAL { ignoreEscape } ::= { mdmCallControlEntry 4 } -- Call status portion of the call control table mdmCCCallDuration OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current Barnes, Brown, Royston & Waldbusser [Page 18] RFC 1696 Modem MIB August 1994 DESCRIPTION "Present or last completed connection time in seconds. If there have been no previous connections, this value should be -1." ::= { mdmCallControlEntry 5 } mdmCCConnectionFailReason OBJECT-TYPE SYNTAX INTEGER { -- General unknown(1), other(2), managementCommand(3), inactivityTimeout(4), mnpIncompatibility(5), protocolError(6), -- DCE powerLoss(10), equipmentFailure(11), -- DTE Interface dtrDrop(20), -- Line Interface noDialTone(30), lineBusy(31), noAnswer(32), voiceDetected(33), -- Signal Converter carrierLost(40), trainingFailed(41), faxDetected(42) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the reason that the last connection or attempt failed. The meaning of each reason code is explained below. unknown: This code means the failure reason is unknown or there has been no previous call. other: This code used when no other code is applicable. Additional vendor information may be available elsewhere. managementCommand: Barnes, Brown, Royston & Waldbusser [Page 19] RFC 1696 Modem MIB August 1994 A management command terminated the call. These commands include escaping to command mode, initiating dialing, restoring lines, and disconnecting. inactivityTimeout: The call was terminated because it was inactive for at the minimum duration specified. mnpIncompatibility: The modems are unable to resolve MNP protocol differences. protocolError: An error occured in one of protocol in use. Further information is required to determine in which protocol the error occurred, and the exact nature of the error. powerLoss: The modem lost power and disconnected the call. equipmentFailure: The modem equipment failed. dtrDrop: DTR has been turned off while the modem is to disconnect on DTR drop. (Ref: V.58 cct108TurnedOff) noDialTone: If the modem is to monitor for call progress tones, but the modem has failed to detect dial tone while attempting to dial a number. lineBusy: Busy signal is detected while busy signal detection is enabled, or while the 'W' or '@' dial modifier is used. (Ref: V.58 engagedTone) noAnswer: The call was not answered. voiceDetected: A voice was detected on the call. carrierLost: Indicates that the modem has disconnected due to detection of loss of carrier. In TIA-602, the S10 register determines the time that loss of carrier Barnes, Brown, Royston & Waldbusser [Page 20] RFC 1696 Modem MIB August 1994 must be detected before the modem disconnects. trainingFailed: Indicates that the modems did not successfully train and reach data mode on the previous connection. faxDetected: A fax was detected on the call." REFERENCE "V.58 callCleared" ::= { mdmCallControlEntry 6 } -- The Stored Dial String table mdmCCStoredDialStringTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmCCStoredDialStringEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of stored dial strings." REFERENCE "V.58 telephoneNumbers" ::= { mdmMIBObjects 8 } mdmCCStoredDialStringEntry OBJECT-TYPE SYNTAX MdmCCStoredDialStringEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A stored dial string." INDEX { mdmIndex, mdmCCStoredDialStringIndex } ::= { mdmCCStoredDialStringTable 1 } MdmCCStoredDialStringEntry ::= SEQUENCE { mdmCCStoredDialStringIndex Integer32, mdmCCStoredDialString DisplayString } mdmCCStoredDialStringIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique index of a particular dial string." ::= { mdmCCStoredDialStringEntry 1 } mdmCCStoredDialString OBJECT-TYPE SYNTAX DisplayString (SIZE(0..64)) MAX-ACCESS read-write STATUS current Barnes, Brown, Royston & Waldbusser [Page 21] RFC 1696 Modem MIB August 1994 DESCRIPTION "A dial string stored in the modem." ::= { mdmCCStoredDialStringEntry 2 } -- The modem Error Correcting Group mdmECTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmECEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The modem error correcting table augments the modem ID table." ::= { mdmMIBObjects 9 } mdmECEntry OBJECT-TYPE SYNTAX MdmECEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One entry exists for each modem managed by the agent." AUGMENTS { mdmIDEntry } ::= { mdmECTable 1 } MdmECEntry ::= SEQUENCE { mdmECErrorControlUsed OBJECT IDENTIFIER } mdmECErrorControlUsed OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the error control method used during the current or previous call. This shall be one of the values for error control protocols registered in the capabilities table for this modem. If no error control protocol is in use, this object shall have the value '{0 0}'." REFERENCE "V.58 errorControlActive" ::= { mdmECEntry 1 } -- The modem Data Compression Group mdmDCTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmDCEntry MAX-ACCESS not-accessible STATUS current Barnes, Brown, Royston & Waldbusser [Page 22] RFC 1696 Modem MIB August 1994 DESCRIPTION "The modem data compression table augments the modem ID table." ::= { mdmMIBObjects 10 } mdmDCEntry OBJECT-TYPE SYNTAX MdmDCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One entry exists for each modem managed by the agent." AUGMENTS { mdmIDEntry } ::= { mdmDCTable 1 } MdmDCEntry ::= SEQUENCE { mdmDCCompressionTypeUsed OBJECT IDENTIFIER } mdmDCCompressionTypeUsed OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the data compression method used during the current or previous call. This shall be one of the values for compression protocols registered in the capabilities table for this modem. If no compression protocol is in use, this object shall have the value '{0 0}'." ::= { mdmDCEntry 1 } -- The modem Signal Convertor Group mdmSCTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmSCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The modem signal convertor table augments the modem ID table." ::= { mdmMIBObjects 11 } mdmSCEntry OBJECT-TYPE SYNTAX MdmSCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One Barnes, Brown, Royston & Waldbusser [Page 23] RFC 1696 Modem MIB August 1994 entry exists for each modem managed by the agent." AUGMENTS { mdmIDEntry } ::= { mdmSCTable 1 } MdmSCEntry ::= SEQUENCE { mdmSCCurrentLineTransmitRate Integer32, mdmSCCurrentLineReceiveRate Integer32, mdmSCInitialLineTransmitRate Integer32, mdmSCInitialLineReceiveRate Integer32, mdmSCModulationSchemeUsed OBJECT IDENTIFIER } mdmSCCurrentLineTransmitRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current link transmit rate of a connection, or the last link transmit rate of the last connection in bits per second." REFERENCE "V.58 transmissionSignallingRateActive" ::= { mdmSCEntry 1 } mdmSCCurrentLineReceiveRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current link receive rate of a connection, or the last link receive rate of the last connection in bits per second." REFERENCE "V.58 transmissionSignallingRateActive" ::= { mdmSCEntry 2 } mdmSCInitialLineTransmitRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The initial link transmit rate of the current connection, or the initial link transmit rate of the last connection in bits per second." ::= { mdmSCEntry 3 } mdmSCInitialLineReceiveRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current Barnes, Brown, Royston & Waldbusser [Page 24] RFC 1696 Modem MIB August 1994 DESCRIPTION "The initial link receive rate of the current connection, or the initial link receive rate of the last connection in bits per second." ::= { mdmSCEntry 4 } mdmSCModulationSchemeUsed OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The modulation scheme of the current or previous call. This shall be one of the values for modulation protocols registered in the capabilities table for this modem." REFERENCE "V.58 gstnModulationSchemeActive" ::= { mdmSCEntry 5 } -- The Modem Statistics Table mdmStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF MdmStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The modem statistics Table augments the modem ID table." ::= { mdmMIBObjects 12 } mdmStatsEntry OBJECT-TYPE SYNTAX MdmStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One entry exists for each modem managed by the agent." AUGMENTS { mdmIDEntry } ::= { mdmStatsTable 1 } MdmStatsEntry ::= SEQUENCE { mdmStatsRingNoAnswers Counter32, mdmStatsIncomingConnectionFailures Counter32, mdmStatsIncomingConnectionCompletions Counter32, mdmStatsFailedDialAttempts Counter32, mdmStatsOutgoingConnectionFailures Counter32, mdmStatsOutgoingConnectionCompletions Counter32, mdmStatsRetrains Counter32, mdmStats2400OrLessConnections Counter32, mdmStats2400To14400Connections Counter32, mdmStatsGreaterThan14400Connections Counter32, Barnes, Brown, Royston & Waldbusser [Page 25] RFC 1696 Modem MIB August 1994 mdmStatsErrorControlledConnections Counter32, mdmStatsCompressedConnections Counter32, mdmStatsCompressionEfficiency Integer32, mdmStatsSentOctets Counter32, mdmStatsReceivedOctets Counter32, mdmStatsSentDataFrames Counter32, mdmStatsReceivedDataFrames Counter32, mdmStatsResentFrames Counter32, mdmStatsErrorFrames Counter32 } mdmStatsRingNoAnswers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of events in which ringing was detected but the call was not answered." ::= { mdmStatsEntry 1 } mdmStatsIncomingConnectionFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming connection requests that this modem answered in which it could not train with the other DCE." ::= { mdmStatsEntry 2 } mdmStatsIncomingConnectionCompletions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming connection requests that this modem answered and successfully trained with the other DCE." ::= { mdmStatsEntry 3 } mdmStatsFailedDialAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of call attempts that failed because the modem didn't go off hook, or there was no dialtone." ::= { mdmStatsEntry 4 } mdmStatsOutgoingConnectionFailures OBJECT-TYPE Barnes, Brown, Royston & Waldbusser [Page 26] RFC 1696 Modem MIB August 1994 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outgoing calls from this modem which sucessfully went off hook and dialed, in which it could not train with the other DCE." ::= { mdmStatsEntry 5 } mdmStatsOutgoingConnectionCompletions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outgoing calls from this modem which resulted in successfully training with the other DCE." ::= { mdmStatsEntry 6 } mdmStatsRetrains OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of retrains experienced on connections on this line." ::= { mdmStatsEntry 7 } -- Utilization counters mdmStats2400OrLessConnections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of connections initially established at a modulation speed of 2400 bits per second or less." ::= { mdmStatsEntry 8 } mdmStats2400To14400Connections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of connections initially established at a modulation speed of greater than 2400 bits per second and less than 14400 bits per second." Barnes, Brown, Royston & Waldbusser [Page 27] RFC 1696 Modem MIB August 1994 ::= { mdmStatsEntry 9 } mdmStatsGreaterThan14400Connections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of connections initially established at a modulation speed of greater than 14400 bits per second." ::= { mdmStatsEntry 10 } mdmStatsErrorControlledConnections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of established connections using an error control protocol." ::= { mdmStatsEntry 11 } mdmStatsCompressedConnections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of established connections using a compression protocol." ::= { mdmStatsEntry 12 } mdmStatsCompressionEfficiency OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes transferred into the compression encoder divided by the number of bytes transferred out of the encoder, multiplied by 100 for either the current or last call. If a data compression protocol is not in use, this value shall be `100'." REFERENCE "V.58 compressionEfficiency" ::= { mdmStatsEntry 13 } mdmStatsSentOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets presented to the modem by the DTE." Barnes, Brown, Royston & Waldbusser [Page 28] RFC 1696 Modem MIB August 1994 ::= { mdmStatsEntry 14 } mdmStatsReceivedOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets presented to the DTE by the modem." ::= { mdmStatsEntry 15 } mdmStatsSentDataFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of data frames sent on the line interface. If there is no frame-oriented protocol in use on the line interface, this counter shall not increment." ::= { mdmStatsEntry 16 } mdmStatsReceivedDataFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of data frames received on the line interface. If there is no frame-oriented protocol in use on the line interface, this counter shall not increment." ::= { mdmStatsEntry 17 } mdmStatsResentFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this modem retransmits frames on the line interface. If there is no frame-oriented protocol in use on the line interface, this counter shall not increment." ::= { mdmStatsEntry 18 } mdmStatsErrorFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of block errors received on the link. If there is no frame-oriented protocol in use on the line interface, Barnes, Brown, Royston & Waldbusser [Page 29] RFC 1696 Modem MIB August 1994 this counter shall not increment." ::= { mdmStatsEntry 19 } -- compliance statements mdmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the modem MIB." MODULE -- this module MANDATORY-GROUPS { mdmIDGroup, mdmLineInterfaceGroup, mdmDTEInterfaceGroup, mdmCallControlGroup, mdmSignalConvertorGroup, mdmStatisticsGroup } GROUP mdmErrorControlGroup DESCRIPTION "This group is mandatory only for those modems that implement an error correction protocol." GROUP mdmDataCompressionGroup DESCRIPTION "This group is mandatory only for those modems that implement a data compression protocol." ::= { mdmCompliances 1 } END 4. Acknowledgements This document was produced by the Modem Management Working group. In addition, the authors gratefully acknowledge the comments of Tom Holodnik and Mark S. Lewis. 5. Security Considerations Security issues are not discussed in this memo. Barnes, Brown, Royston & Waldbusser [Page 30] RFC 1696 Modem MIB August 1994 6. Authors' Addresses Jim Barnes Xylogics, Inc. 53 Third Avenue Burlington, MA 01803 USA Phone: 617-272-8140 Fax: 617-272-2618 EMail: barnes@xylogics.com Les Brown Motorola Phone: 416-507-7200 EMail: brown_l@msm.cdx.mot.com Rick Royston US Robotics, Inc. 8100 N. McCormick Boulevard Skokie, IL 60076-2999 USA Phone: 708-933-5430 Fax: 708-982-1348 EMail: rroyston@usr.com Steven Waldbusser Carnegie Mellon University Computing and Communications Cyert Hall 130 5000 Forbes Avenue Pittsburgh, PA 15213-3890 USA Phone: 412-268-6628 Fax: 412-268-4987 EMail: swol@andrew.cmu.edu Barnes, Brown, Royston & Waldbusser [Page 31] snmp-mibs-downloader-1.1/mibrfcs/rfc1697.txt0000644000000000000000000022465211402176071015603 0ustar Network Working Group D. Brower, Editor Request for Comments: 1697 The ASK Group, INGRES DBMS Development Category: Standards Track B. Purvy, RDBMSMIB Working Group Chair Oracle Corporation A. Daniel Informix Software, Inc. M. Sinykin J. Smith Oracle Corporation August 1994 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 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 .............................................. 1 2. The SNMPv2 Network Management Framework ................... 2 2.1 Object Definitions ....................................... 2 3. Overview .................................................. 2 3.1 Terminology .............................................. 3 3.2 Structure and Features ................................... 4 3.2.1 Tables ................................................. 4 3.2.2 Writable objects ....................................... 5 3.2.3 Traps .................................................. 5 4. Definitions ............................................... 6 5. Acknowledgements .......................................... 35 6. References ................................................ 36 7. Security Considerations ................................... 37 8. Authors' Addresses ........................................ 37 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing relational database (RDBMS) implementations. Brower, Purvy, Daniel, Sinykin & Smith [Page 1] RFC 1697 RDBMS-MIB August 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. o RFC 1443 [5] which describes textual conventions for the framework. The framework permits new objects to be defined for the purpose of experimentation and evaluation. In particular, the RDBMS-MIB can be seen as an extension of o RFC 1565 [6] which defines the MIB for monitoring network service applications. 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 RDBMS-MIB contains objects that may be used to manage relational database implementations. Specifically, it contains information on installed databases, servers, and on the relation of databases and servers. The terms used in this database are described below. Brower, Purvy, Daniel, Sinykin & Smith [Page 2] RFC 1697 RDBMS-MIB August 1994 3.1. Terminology Vendors and Products are providers of database systems on a host. These vendors may have more than one database product that is manageable through this MIB. On a host, there may be systems from multiple vendors, multiple systems from a single vendor, or any other combination. There may be a private MIB for each vendor, and this may be located using the PrivateMibOID objects in some of the tables. Databases are collections of interrelated data organized according to a schema to serve one or more applications. A database is, for purposes of this MIB, a collection of tables whose organization is based on the relational model. There may be one or more databases available in each system on the host from each product. In the MIB, data about databases is captured in the rdbmsDbTable and the rdbmsDbInfoTable, each with one row per database. Relational Database Management System (RDBMS) A collection of integrated services which support database management and together support and control the creation, use and maintenance of relational databases. Servers as defined in this MIB provide the functions of the RDBMS. Servers are entities that provide access to databases. For this MIB, servers are defined to be entities that may exist independently of other servers. A server may or may not be a single process, based on its independence from other processes. In this MIB, information about servers is captured in the rdbmsSvrTable, the rdbmsSvrInfoTable, each with one row per server extending the applTable from the APPLICATION-MIB of RFC 1565. The rdbmsSvrTable and rdbmsSvrInfoTable are both indexed by the applIndex of that MIB. Associations Inbound associations are local or remote conversations, usually instances of the SQL CONNECT statement, as made visible in servers. The MIB does not currently reveal individual associations; there are association counters in the dbmsSvrInfoTable and the applTable. There are also relationships between servers and databases. All obvious relationships are possible and supported: Brower, Purvy, Daniel, Sinykin & Smith [Page 3] RFC 1697 RDBMS-MIB August 1994 o 1 database : 1 server o 1 database : many servers o many databases : 1 server o many databases : many servers 3.2. Structure and Features The information in this MIB module is organized into nine tables, twelve potentially writable objects, and two traps, as follows. 3.2.1. Tables o databases installed on a host/system (rdbmsDbTable) o actively opened databases (rdbmsDbInfoTable) o database configuration parameters (rdbmsDbParamTable) o database limited resources (rdbmsDbLimitedResourceTable) o database servers installed on a system (rdbmsSrvTable) o active database servers (rdbmsSrvInfoTable) o configuration parameters for a server (rdbmsSrvParamTable) o server limited resources (rdbmsSrvLimitedResourceTable) o relation of servers and databases on a host (rdbmsRelTable) These entities have broad applicability among database systems, and are enough for many monitoring tasks. They are far from adequate for detailed management or performance monitoring of specific database products. This gap is expected to be filled with vendor and product specific MIBs addressing the entities that have not been codified here. Brower, Purvy, Daniel, Sinykin & Smith [Page 4] RFC 1697 RDBMS-MIB August 1994 3.2.2. Writable objects The MIB requires no writable objects for conformance. There is no expectation that RDBMS systems may be actively managed through this MIB. However, the RDBMS-MIB supports the capability to modify the following objects if the implementor so chooses. o rdbmsDbContact o rdbmsDbInfoSizeAllocated o rdbmsDbParamCurrValue o rdbmsDbParamComment rdbmsDbLimitedResourceLimit o rdbmsDbLimitedResourceDescription o rdbmsSrvContact o rdbmsSrvInfoMaxInboundAssociations o rdbmsSrvParamCurrValue o rdbmsSrvParamComment o rdbmsSrvLimitedResourceLimit o rdbmsSrvLimitedResourceDescription 3.2.3. Traps The RDBMS-MIB contains two traps: o rdbmsStateChange o rdbmsOutOfSpace Brower, Purvy, Daniel, Sinykin & Smith [Page 5] RFC 1697 RDBMS-MIB August 1994 4. Definitions RDBMS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Gauge32, Integer32 FROM SNMPv2-SMI DisplayString, DateAndTime, AutonomousType FROM SNMPv2-TC applIndex, applGroup FROM APPLICATION-MIB mib-2 FROM RFC1213-MIB; rdbmsMIB MODULE-IDENTITY LAST-UPDATED "9406150655Z" ORGANIZATION "IETF RDBMSMIB Working Group" CONTACT-INFO " David Brower Postal: The ASK Group, INGRES DBMS Development 1080 Marina Village Parkway Alameda, CA 94501 US Tel: +1 510 748 3418 Fax: +1 510 748 2770 E-mail: daveb@ingres.com" DESCRIPTION "The MIB module to describe objects for generic relational databases." ::= { mib-2 39 } rdbmsObjects OBJECT IDENTIFIER ::= { rdbmsMIB 1 } ---------------------------------------------------------------- rdbmsDbTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsDbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of databases installed on a system." ::= { rdbmsObjects 1 } Brower, Purvy, Daniel, Sinykin & Smith [Page 6] RFC 1697 RDBMS-MIB August 1994 rdbmsDbEntry OBJECT-TYPE SYNTAX RdbmsDbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a single database on the host. Whether a particular database is represented by a row in rdbmsDbTable may be dependent on the activity level of that database, according to the product's implementation. An instance of rdbmsRelState having the value active, other, or restricted implies that an entry, corresponding to that instance, will be present." INDEX { rdbmsDbIndex } ::= { rdbmsDbTable 1 } RdbmsDbEntry ::= SEQUENCE { rdbmsDbIndex INTEGER, rdbmsDbPrivateMibOID OBJECT IDENTIFIER, rdbmsDbVendorName DisplayString, rdbmsDbName DisplayString, rdbmsDbContact DisplayString } rdbmsDbIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A numeric index, unique among all the databases from all products on this host. This value is a surrogate for the conceptually unique key, which is {PrivateMibOID, databasename}" ::= { rdbmsDbEntry 1 } rdbmsDbPrivateMibOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The authoritative identification for the private MIB for this database, presumably based on the vendor, e.g., { enterprises 111 } for Oracle databases, {enterprises 757 } for Ingres databases, { enterprises 897 } for Sybase databases, etc. If no OBJECT IDENTIFIER exists for the private MIB, attempts Brower, Purvy, Daniel, Sinykin & Smith [Page 7] RFC 1697 RDBMS-MIB August 1994 to access this object will return noSuchName (SNMPv1) or noSuchInstance (SNMPv2)." ::= { rdbmsDbEntry 2 } rdbmsDbVendorName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the vendor whose RDBMS manages this database, for informational purposes." ::= { rdbmsDbEntry 3 } rdbmsDbName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this database, in a product specific format. The product may need to qualify the name in some way to resolve conflicts if it is possible for a database name to be duplicated on a host. It might be necessary to construct a hierarchical name embedding the RDBMS instance/installation on the host, and/or the owner of the database. For instance, '/test-installation/database-owner/database-name'." ::= { rdbmsDbEntry 4 } rdbmsDbContact OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The textual identification of the contact person for this managed database, together with information on how to contact this person. Note: if there is no server associated with this database, an agent may need to keep this in other persistent storage, e.g., a configuration file. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsDbEntry 5 } Brower, Purvy, Daniel, Sinykin & Smith [Page 8] RFC 1697 RDBMS-MIB August 1994 ---------------------------------------------------------------- rdbmsDbInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsDbInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of additional information about databases present on the host." ::= { rdbmsObjects 2 } rdbmsDbInfoEntry OBJECT-TYPE SYNTAX RdbmsDbInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information that must be present if the database is actively opened. If the database is not actively opened, then attempts to access corresponding instances in this table may result in either noSuchName (SNMPv1) or noSuchInstance (SNMPv2). 'Actively opened' means at least one of the rdbmsRelState entries for this database in the rdbmsRelTable is active(2)." INDEX { rdbmsDbIndex } ::= { rdbmsDbInfoTable 1 } RdbmsDbInfoEntry ::= SEQUENCE { rdbmsDbInfoProductName DisplayString, rdbmsDbInfoVersion DisplayString, rdbmsDbInfoSizeUnits INTEGER, rdbmsDbInfoSizeAllocated INTEGER, rdbmsDbInfoSizeUsed INTEGER, rdbmsDbInfoLastBackup DateAndTime } rdbmsDbInfoProductName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The textual product name of the server that created or last restructured this database. The format is product specific." ::= { rdbmsDbInfoEntry 1 } rdbmsDbInfoVersion OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only Brower, Purvy, Daniel, Sinykin & Smith [Page 9] RFC 1697 RDBMS-MIB August 1994 STATUS current DESCRIPTION "The version number of the server that created or last restructured this database. The format is product specific." ::= { rdbmsDbInfoEntry 2 } rdbmsDbInfoSizeUnits OBJECT-TYPE SYNTAX INTEGER { bytes(1), kbytes(2), mbytes(3), gbytes(4), tbytes(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identification of the units used to measure the size of this database in rdbmsDbInfoSizeAllocated and rdbmsDbInfoSizeUsed. bytes(1) indicates individual bytes, kbytes(2) indicates units of kilobytes, mbytes(3) indicates units of megabytes, gbytes(4) indicates units of gigabytes, and tbytes(5) indicates units of terabytes. All are binary multiples -- 1K = 1024. If writable, changes here are reflected in the get values of the associated objects." ::= { rdbmsDbInfoEntry 3 } rdbmsDbInfoSizeAllocated OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The estimated size of this database (in rdbmsDbInfoSizeUnits), which is the disk space that has been allocated to it and is no longer available to users on this host. rdbmsDbInfoSize does not necessarily indicate the amount of space actually in use for database data. Some databases may support extending allocated size, and others may not. Note that a compliant agent does not need to allow write access to this object." -- Note: computing SizeAllocated may be expensive, and SNMP -- agents might cache the value to increase performance. ::= { rdbmsDbInfoEntry 4 } Brower, Purvy, Daniel, Sinykin & Smith [Page 10] RFC 1697 RDBMS-MIB August 1994 rdbmsDbInfoSizeUsed OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The estimated size of this database, in rdbmsDbInfoSizeUnits, which is actually in use for database data." -- Note: computing SizeUsed may be expensive, and SNMP -- agents might cache the value to increase performance. ::= { rdbmsDbInfoEntry 5 } rdbmsDbInfoLastBackup OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time that the latest complete or partial backup of the database was taken. If a database has never been backed up, then attempts to access this object will result in either noSuchName (SNMPv1) or noSuchInstance (SNMPv2)." ::= { rdbmsDbInfoEntry 6 } ---------------------------------------------------------------- rdbmsDbParamTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsDbParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of configuration parameters for a database. Entries should be populated according to the following guidelines: (1) The value should be specified through administrative (human) intervention. (2) It should be configured on a per-database basis. (3) One of the following is true: (a) The parameter has a non-numeric value; (b) The current value is numeric, but it only changes due to human intervention; (c) The current value is numeric and dynamic, but the RDBMS does not track access/allocation failures related to the parameter; (d) The current value is numeric and dynamic, the RDBMS tracks changes in access/allocation failures related to the parameter, but the failure has no significant impact on RDBMS performance or Brower, Purvy, Daniel, Sinykin & Smith [Page 11] RFC 1697 RDBMS-MIB August 1994 availability. (e) The current value is numeric and dynamic, the RDBMS tracks changes in access/allocation failures related to the parameter, the failure has significant impact on RDBMS performance or availability, and is shown in the rdbmsDbLimitedResource table." ::= { rdbmsObjects 3 } rdbmsDbParamEntry OBJECT-TYPE SYNTAX RdbmsDbParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a single configuration parameter for a database. Parameters with single values have a subindex value of one. If the parameter is naturally considered to contain a variable number of members of a class, e.g. members of the DBA user group, or files which are part of the database, then it must be presented as a set of rows. If, on the other hand, the parameter represents a set of choices from a class, e.g. the permissions on a file or the options chosen out of the set of all options allowed, AND is guaranteed to always fit in the 255 character length of a DisplayString, then it may be presented as a comma separated list with a subindex value of one. Zero may not be used as a subindex value. If the database is not actively opened, then attempts to access corresponding instances in this table may result in either noSuchName (SNMPv1) or noSuchInstance (SNMPv2). 'Actively opened' means at least one of the rdbmsRelState entries for this database in the rdbmsRelTable is active(2)." INDEX { rdbmsDbIndex, rdbmsDbParamName, rdbmsDbParamSubIndex } ::= { rdbmsDbParamTable 1 } RdbmsDbParamEntry ::= SEQUENCE { rdbmsDbParamName DisplayString, rdbmsDbParamSubIndex INTEGER, rdbmsDbParamID AutonomousType, rdbmsDbParamCurrValue DisplayString, rdbmsDbParamComment DisplayString } rdbmsDbParamName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS not-accessible Brower, Purvy, Daniel, Sinykin & Smith [Page 12] RFC 1697 RDBMS-MIB August 1994 STATUS current DESCRIPTION "The name of a configuration parameter for a database. This name is product-specific. The length is limited to 64 characters to constrain the number of sub-identifiers needed for instance identification (and to minimize network traffic)." ::= { rdbmsDbParamEntry 1 } rdbmsDbParamSubIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The subindex value for this parameter. If the parameter is naturally considered to contain a variable number of members of a class, e.g. members of the DBA user group, or files which are part of the database, then it must be presented as a set of rows. If, on the other hand, the parameter represents a set of choices from a class, e.g. the permissions on a file or the options chosen out of the set of all options allowed, AND is guaranteed to always fit in the 255 character length of a DisplayString, then it may be presented as a comma separated list with a subindex value of one. Zero may not be used as a value." ::= { rdbmsDbParamEntry 2 } rdbmsDbParamID OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the parameter which may be described in some other MIB (e.g., an enterprise-specific MIB module). If there is no ID for this rdbmsDbParamName, attempts to access this object will return noSuchName (SNMPv1) or noSuchInstance (SNMPv2)." ::= { rdbmsDbParamEntry 3 } rdbmsDbParamCurrValue OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The value for a configuration parameter now in effect, the actual setting for the database. While there may multiple values in the temporal domain of interest (for instance, the Brower, Purvy, Daniel, Sinykin & Smith [Page 13] RFC 1697 RDBMS-MIB August 1994 value to take effect at the next restart), this is the current setting. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsDbParamEntry 4 } rdbmsDbParamComment OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "Annotation which describes the purpose of a configuration parameter or the reason for a particular parameter's setting. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsDbParamEntry 5 } ---------------------------------------------------------------- rdbmsDbLimitedResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsDbLimitedResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of limited resources that are kept per-database." ::= { rdbmsObjects 4 } rdbmsDbLimitedResourceEntry OBJECT-TYPE SYNTAX RdbmsDbLimitedResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a single limited resource kept per-database. A limited resource has maximum use determined by a parameter that might or might not be changeable at run time, or visible in the rdbmsDbParamTable. Examples would be the number of available locks, or disk space on a partition. Arrays of resources are supported through an integer sub index, which should have the value of one for single-instance names. Limited resources that are shared across databases, are best put in the rdbmsSvrLimitedResourceTable instead of this one. Brower, Purvy, Daniel, Sinykin & Smith [Page 14] RFC 1697 RDBMS-MIB August 1994 If the database is not actively opened, then attempts to access corresponding instances in this table may result in either noSuchName (SNMPv1) or noSuchInstance (SNMPv2). 'Actively opened' means at least one of the rdbmsRelState entries for this database in the rdbmsRelTable is active(2)." INDEX { rdbmsDbIndex, rdbmsDbLimitedResourceName } ::= { rdbmsDbLimitedResourceTable 1 } RdbmsDbLimitedResourceEntry ::= SEQUENCE { rdbmsDbLimitedResourceName DisplayString, rdbmsDbLimitedResourceID AutonomousType, rdbmsDbLimitedResourceLimit INTEGER, rdbmsDbLimitedResourceCurrent INTEGER, rdbmsDbLimitedResourceHighwater INTEGER, rdbmsDbLimitedResourceFailures Counter32, rdbmsDbLimitedResourceDescription DisplayString } rdbmsDbLimitedResourceName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the resource, for instance 'global locks' or 'locks for the FOO database', or 'data space on /dev/rdsk/5s0 for FOO'. The length is limited to 64 characters to constrain the number of sub-identifiers needed for instance identification (and to minimize network traffic)." ::= { rdbmsDbLimitedResourceEntry 1 } rdbmsDbLimitedResourceID OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the resource which may be described in some other MIB (e.g., an enterprise-specific MIB module). If there is no ID for this rdbmsDbLimitedResourceName, attempts to access this object will return noSuchName (SNMPv1) or noSuchInstance (SNMPv2)." ::= { rdbmsDbLimitedResourceEntry 2 } rdbmsDbLimitedResourceLimit OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-write STATUS current Brower, Purvy, Daniel, Sinykin & Smith [Page 15] RFC 1697 RDBMS-MIB August 1994 DESCRIPTION "The maximum value the resource use may attain. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsDbLimitedResourceEntry 3 } rdbmsDbLimitedResourceCurrent OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current value for the resource." ::= { rdbmsDbLimitedResourceEntry 4 } rdbmsDbLimitedResourceHighwater OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of the resource seen since applUpTime was reset for the earliest server which has the database actively opened. If there are two servers with the database open, and the oldest one dies, the proper way to invalidate the value is by resetting sysUpTime." ::= { rdbmsDbLimitedResourceEntry 5 } rdbmsDbLimitedResourceFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the system wanted to exceed the limit of the resource since applUpTime was reset for the earliest server which has the database actively opened. If there are two servers with the DB open, and the oldest one dies, the proper way to invalidate the value is by resetting sysUpTime." ::= { rdbmsDbLimitedResourceEntry 6 } rdbmsDbLimitedResourceDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current Brower, Purvy, Daniel, Sinykin & Smith [Page 16] RFC 1697 RDBMS-MIB August 1994 DESCRIPTION "A description of the resource and the meaning of the integer units used for Limit, Current, and Highwater. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsDbLimitedResourceEntry 7 } ---------------------------------------------------------------- rdbmsSrvTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsSrvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of database servers running or installed on a system." ::= { rdbmsObjects 5 } rdbmsSrvEntry OBJECT-TYPE SYNTAX RdbmsSrvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a single database server. A server is an independent entity that provides access to one or more databases. Failure of one does not affect access to databases through any other servers. There might be one or more servers providing access to a database. A server may be a 'process' or collection of 'processes', as interpreted by the product." INDEX { applIndex } ::= { rdbmsSrvTable 1 } RdbmsSrvEntry ::= SEQUENCE { rdbmsSrvPrivateMibOID OBJECT IDENTIFIER, rdbmsSrvVendorName DisplayString, rdbmsSrvProductName DisplayString, rdbmsSrvContact DisplayString } rdbmsSrvPrivateMibOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION Brower, Purvy, Daniel, Sinykin & Smith [Page 17] RFC 1697 RDBMS-MIB August 1994 "The authoritative identification for the private MIB for this server, presumably based on the vendor, e.g., { enterprises 111 } for Oracle servers, { enterprises 757 } for Ingres servers, { enterprises 897 } for Sybase servers, etc. If no OBJECT IDENTIFIER exists for the private MIB, attempts to access this object will return noSuchName (SNMPv1) or noSuchInstance (SNMPv2)." ::= { rdbmsSrvEntry 1 } rdbmsSrvVendorName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the vendor whose RDBMS manages this database, for informational purposes." ::= { rdbmsSrvEntry 2 } rdbmsSrvProductName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The product name of this server. This is normally the vendor's formal name for the product, in product specific format." ::= { rdbmsSrvEntry 3 } rdbmsSrvContact OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The textual identification of the contact person for this managed server, together with information on how to contact this person. Note: if there is no active server associated with this object, an agent may need to keep this in other persistent storage, e.g., a configuration file. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsSrvEntry 4 } Brower, Purvy, Daniel, Sinykin & Smith [Page 18] RFC 1697 RDBMS-MIB August 1994 ---------------------------------------------------------------- rdbmsSrvInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsSrvInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of additional information about database servers. Entries in this table correspond to applications in the APPLICATION-MIB applTable. Some objects in that table are application-specific. When they are associated with an RDBMS server in this table, the objects have the following meanings. applName - The name of this server, i.e., the process or group of processes providing access to this database. The exact format will be product and host specific. applVersion - The version number of this server, in product specific format. applOperStatus - up(1) means operational and available for general use. down(2) means the server is not available for use, but is known to the agent. The other states have broad meaning, and may need to be supplemented by the vendor private MIB. Halted(3) implies an administrative state of unavailability. Congested(4) implies a resource or or administrative limit is prohibiting new inbound associations. The 'available soon' description of restarting(5) may include an indeterminate amount of recovery. applLastChange is the time the agent noticed the most recent change to applOperStatus. applInboundAssociation is the number of currently active local and remote conversations (usually SQL connects). applOutboundAssociations is not provided by this MIB. applAccumulatedInboundAssociations is the total number of local and remote conversations started since the server came up. applAccumulatedOutbound associations is not provided by this MIB. applLastInboundActivity is the time the most recent local or Brower, Purvy, Daniel, Sinykin & Smith [Page 19] RFC 1697 RDBMS-MIB August 1994 remote conversation was attempted or disconnected. applLastOutboundActivity is not provided by this MIB. applRejectedInboundAssociations is the number of local or remote conversations rejected by the server for administrative reasons or because of resource limitations. applFailedOutboundAssociations is not provided by this MIB." ::= { rdbmsObjects 6 } rdbmsSrvInfoEntry OBJECT-TYPE SYNTAX RdbmsSrvInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information that must be present for a single 'up' database server, with visibility determined by the value of the corresponding applOperStatus object. If an instance of applOperStatus is not up(1), then attempts to access corresponding instances in this table may result in either noSuchName (SNMPv1) or noSuchInstance (SNMPv2) being returned by the agent." INDEX { applIndex } ::= { rdbmsSrvInfoTable 1 } RdbmsSrvInfoEntry ::= SEQUENCE { rdbmsSrvInfoStartupTime DateAndTime, rdbmsSrvInfoFinishedTransactions Gauge32, rdbmsSrvInfoDiskReads Counter32, rdbmsSrvInfoDiskWrites Counter32, rdbmsSrvInfoLogicalReads Counter32, rdbmsSrvInfoLogicalWrites Counter32, rdbmsSrvInfoPageWrites Counter32, rdbmsSrvInfoPageReads Counter32, rdbmsSrvInfoDiskOutOfSpaces Counter32, rdbmsSrvInfoHandledRequests Counter32, rdbmsSrvInfoRequestRecvs Counter32, rdbmsSrvInfoRequestSends Counter32, rdbmsSrvInfoHighwaterInboundAssociations Gauge32, rdbmsSrvInfoMaxInboundAssociations Gauge32 } rdbmsSrvInfoStartupTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only Brower, Purvy, Daniel, Sinykin & Smith [Page 20] RFC 1697 RDBMS-MIB August 1994 STATUS current DESCRIPTION "The date and time at which this server was last started." ::= { rdbmsSrvInfoEntry 1 } rdbmsSrvInfoFinishedTransactions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transactions visible to this server that have been completed by either commit or abort. Some database operations, such as read-only queries, may not result in the creation of a transaction." ::= { rdbmsSrvInfoEntry 2 } rdbmsSrvInfoDiskReads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of reads of database files issued to the operating system by this server since startup. Numbers are not comparable between products. What constitutes a readand how it is accounted is product-specific." ::= { rdbmsSrvInfoEntry 3 } rdbmsSrvInfoLogicalReads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of logical reads of database files made internally by this server since startup. The values of this object and those of rdbmsSrvInfoDiskReads reveal the effect of caching on read operation. Numbers are not comparable between products, and may only be meaningful when aggregated across all servers sharing a common cache." ::= { rdbmsSrvInfoEntry 4 } rdbmsSrvInfoDiskWrites OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of writes to database files issued to the operating system by this server since startup. Numbers are not comparable between products." Brower, Purvy, Daniel, Sinykin & Smith [Page 21] RFC 1697 RDBMS-MIB August 1994 ::= { rdbmsSrvInfoEntry 5 } rdbmsSrvInfoLogicalWrites OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times parts of the database files have been marked 'dirty' and in need of writing to the disk. This value and rdbmsSrvInfoDiskWrites give some indication of the effect of 'write-behind' strategies in reducing the number of disk writes compared to database operations. Because the writes may be done by servers other than those marking the parts of the database files dirty, these values may only be meaningful when aggregated across all servers sharing a common cache. Numbers are not comparable between products." ::= { rdbmsSrvInfoEntry 6 } rdbmsSrvInfoPageReads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of pages in database files read by this server since startup. 'Pages' are product specific units of disk i/o operations. This value, along with rdbmsSrvInfoDiskReads, reveals the effect of any grouping read-ahead that may be used to enhance performance of some queries, such as scans." ::= { rdbmsSrvInfoEntry 7} rdbmsSrvInfoPageWrites OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of pages in database files written by this server since startup. Pages are product-specific units of disk I/O. This value, with rdbmsSrvInfoDiskWrites, shows the effect of write strategies that collapse logical writes of contiguous pages into single calls to the operating system." ::= { rdbmsSrvInfoEntry 8 } rdbmsSrvInfoDiskOutOfSpaces OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Brower, Purvy, Daniel, Sinykin & Smith [Page 22] RFC 1697 RDBMS-MIB August 1994 "The total number of times the server has been unable to obtain disk space that it wanted, since server startup. This would be inspected by an agent on receipt of an rdbmsOutOfSpace trap." ::= { rdbmsSrvInfoEntry 9 } rdbmsSrvInfoHandledRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of requests made to the server on inbound associations. The meaning of 'requests' is product specific, and is not comparable between products. This is intended to encapsulate high level semantic operations between clients and servers, or between peers. For instance, one request might correspond to a 'select' or an 'insert' statement. It is not intended to capture disk i/o described in rdbmsSrvInfoDiskReads and rdbmsSrvInfoDiskWrites." ::= { rdbmsSrvInfoEntry 10 } rdbmsSrvInfoRequestRecvs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of receive operations made processing any requests on inbound associations. The meaning of operations is product specific, and is not comparable between products. This is intended to capture lower-level i/o operations than shown by HandledRequests, between clients and servers, or between peers. For instance, it might roughly correspond to the amount of data given with an 'insert' statement. It is not intended to capture disk i/o described in rdbmsSrvInfoDiskReads and rdbmsSrvInfoDiskWrites." ::= { rdbmsSrvInfoEntry 11 } rdbmsSrvInfoRequestSends OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of send operations made processing requests handled on inbound associations. The meaning of operations is product specific, and is not comparable between products. Brower, Purvy, Daniel, Sinykin & Smith [Page 23] RFC 1697 RDBMS-MIB August 1994 This is intended to capture lower-level i/o operations than shown by HandledRequests, between between clients and servers, or between peers. It might roughly correspond to the number of rows returned by a 'select' statement. It is not intended to capture disk i/o described in DiskReads." ::= { rdbmsSrvInfoEntry 12 } rdbmsSrvInfoHighwaterInboundAssociations OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The greatest number of inbound associations that have been simultaneously open to this server since startup." ::= { rdbmsSrvInfoEntry 13 } rdbmsSrvInfoMaxInboundAssociations OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "The greatest number of inbound associations that can be simultaneously open with this server. If there is no limit, then the value should be zero. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsSrvInfoEntry 14 } ---------------------------------------------------------------- rdbmsSrvParamTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsSrvParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of configuration parameters for a server. Entries should be populated according to the following guidelines: (1) The value should be specified through administrative (human) intervention. (2) It should be configured on a per-server or a more global basis, with duplicate entries for each server sharing use of the parameter. (3) One of the following is true: (a) The parameter has a non-numeric value; (b) The current value is numeric, but it only changes due to human intervention; Brower, Purvy, Daniel, Sinykin & Smith [Page 24] RFC 1697 RDBMS-MIB August 1994 (c) The current value is numeric and dynamic, but the RDBMS does not track access/allocation failures related to the parameter; (d) The current value is numeric and dynamic, the RDBMS tracks changes in access/allocation failures related to the parameter, but the failure has no significant impact on RDBMS performance or availability. (e) The current value is numeric and dynamic, the RDBMS tracks changes in access/allocation failures related to the parameter, the failure has significant impact on RDBMS performance or availability, and is shown in the rdbmsSrvLimitedResource table." ::= { rdbmsObjects 7 } rdbmsSrvParamEntry OBJECT-TYPE SYNTAX RdbmsSrvParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a single configuration parameter for a server. Parameters with single values have a subindex value of one. If the parameter is naturally considered to contain a variable number of members of a class, e.g. members of the DBA user group, or tracepoints active in the server, then it must be presented as a set of rows. If, on the other hand, the parameter represents a set of choices from a class, e.g. the permissions on a file or the options chosen out of the set of all options allowed, AND is guaranteed to always fit in the 255 character length of a DisplayString, then it may be presented as a comma separated list with a subindex value of one. Zero may not be used as a subindex value. Entries for a server must be present if the value of the corresponding applOperStatus object is up(1). If an instance of applOperStatus is not up(1), then attempts to access corresponding instances in this table may result in either noSuchName (SNMPv1) or noSuchInstance (SNMPv2) being returned by the agent." INDEX { applIndex, rdbmsSrvParamName, rdbmsSrvParamSubIndex } ::= { rdbmsSrvParamTable 1 } RdbmsSrvParamEntry ::= SEQUENCE { rdbmsSrvParamName DisplayString, rdbmsSrvParamSubIndex INTEGER, rdbmsSrvParamID AutonomousType, Brower, Purvy, Daniel, Sinykin & Smith [Page 25] RFC 1697 RDBMS-MIB August 1994 rdbmsSrvParamCurrValue DisplayString, rdbmsSrvParamComment DisplayString } rdbmsSrvParamName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a configuration parameter for a server. This name is product-specific. The length is limited to 64 characters to constrain the number of sub-identifiers needed for instance identification (and to minimize network traffic)." ::= { rdbmsSrvParamEntry 1 } rdbmsSrvParamSubIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The subindex value for this parameter. If the parameter is naturally considered to contain a variable number of members of a class, e.g. members of the DBA user group, or files which are part of the database, then it must be presented as a set of rows. If, on the other hand, the parameter represents a set of choices from a class, e.g. the permissions on a file or the options chosen out of the set of all options allowed, AND is guaranteed to always fit in the 255 character length of a DisplayString, then it may be presented as a comma separated list with a subindex value of one. Zero may not be used as a value." ::= { rdbmsSrvParamEntry 2 } rdbmsSrvParamID OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the parameter which may be described in some other MIB. If there is no ID for this rdbmsSrvParamName, attempts to access this object will return noSuchName (SNMPv1) or noSuchInstance (SNMPv2)." ::= { rdbmsSrvParamEntry 3 } rdbmsSrvParamCurrValue OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write Brower, Purvy, Daniel, Sinykin & Smith [Page 26] RFC 1697 RDBMS-MIB August 1994 STATUS current DESCRIPTION "The value for a configuration parameter now in effect, the actual setting for the server. While there may multiple values in the temporal domain of interest (for instance, the value to take effect at the next restart), this is the current setting. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsSrvParamEntry 4 } rdbmsSrvParamComment OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "Annotation which describes the purpose of a configuration parameter or the reason for a particular parameter's setting. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsSrvParamEntry 5 } ---------------------------------------------------------------- rdbmsSrvLimitedResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsSrvLimitedResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of limited resources relevant to a server." ::= { rdbmsObjects 8 } rdbmsSrvLimitedResourceEntry OBJECT-TYPE SYNTAX RdbmsSrvLimitedResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a single limited resource kept by the server. A limited resource has maximum use determined by a parameter that might or might not changeable at run time, or visible in the rbmsSrvParamTable. Examples would be the number of available locks, or number of concurrent executions allowed in a server. Arrays of resources are supported through an Brower, Purvy, Daniel, Sinykin & Smith [Page 27] RFC 1697 RDBMS-MIB August 1994 integer subindex, which should have the value of one for single-instance names. Limited resources that are shared across servers or databases are best duplicated in this table across all servers accessing the resource." INDEX { applIndex, rdbmsSrvLimitedResourceName } ::= { rdbmsSrvLimitedResourceTable 1 } RdbmsSrvLimitedResourceEntry ::= SEQUENCE { rdbmsSrvLimitedResourceName DisplayString, rdbmsSrvLimitedResourceID AutonomousType, rdbmsSrvLimitedResourceLimit INTEGER, rdbmsSrvLimitedResourceCurrent INTEGER, rdbmsSrvLimitedResourceHighwater INTEGER, rdbmsSrvLimitedResourceFailures Counter32, rdbmsSrvLimitedResourceDescription DisplayString } rdbmsSrvLimitedResourceName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the resource, for instance 'threads' or 'semaphores', or 'buffer pages'" ::= { rdbmsSrvLimitedResourceEntry 1 } rdbmsSrvLimitedResourceID OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the resource which may be described in some other MIB. If there is no ID for this rdbmsSrvLimitedResourceName, attempts to access this object will return noSuchName (SNMPv1) or noSuchInstance (SNMPv2)." ::= { rdbmsSrvLimitedResourceEntry 2 } rdbmsSrvLimitedResourceLimit OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-write STATUS current Brower, Purvy, Daniel, Sinykin & Smith [Page 28] RFC 1697 RDBMS-MIB August 1994 DESCRIPTION "The maximum value the resource use may attain. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsSrvLimitedResourceEntry 3 } rdbmsSrvLimitedResourceCurrent OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current value for the resource." ::= { rdbmsSrvLimitedResourceEntry 4 } rdbmsSrvLimitedResourceHighwater OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of the resource seen since applUpTime was reset." ::= { rdbmsSrvLimitedResourceEntry 5 } rdbmsSrvLimitedResourceFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the system wanted to exceed the limit of the resource since applUpTime was reset." ::= { rdbmsSrvLimitedResourceEntry 6 } rdbmsSrvLimitedResourceDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the resource and the meaning of the integer units used for Limit, Current, and Highwater. Note that a compliant agent does not need to allow write access to this object." ::= { rdbmsSrvLimitedResourceEntry 7 } Brower, Purvy, Daniel, Sinykin & Smith [Page 29] RFC 1697 RDBMS-MIB August 1994 ---------------------------------------------------------------- rdbmsRelTable OBJECT-TYPE SYNTAX SEQUENCE OF RdbmsRelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table relating databases and servers present on a host." ::= { rdbmsObjects 9 } rdbmsRelEntry OBJECT-TYPE SYNTAX RdbmsRelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry relating a single database server to a single database to which it may provide access. The table is indexed first by the index of rdbmsDbTable, and then rdbmsSrvTable, so that all servers capable of providing access to a given database may be found by SNMP traversal operations (get-next and get-bulk). The makeup of this table depends on the product's architecture, e.g. if it is one server - many databases, then each server will appear n times, where n is the number of databases it may access, and each database will appear once. If the architecture is one database - many servers, then each server will appear once and each database will appear n times, where n is the number of servers that may be accessing it." INDEX { rdbmsDbIndex, applIndex } ::= { rdbmsRelTable 1 } RdbmsRelEntry ::= SEQUENCE { rdbmsRelState INTEGER, rdbmsRelActiveTime DateAndTime } rdbmsRelState OBJECT-TYPE SYNTAX INTEGER{ other(1), active(2), available(3), restricted(4), unavailable(5) } MAX-ACCESS read-only STATUS current DESCRIPTION Brower, Purvy, Daniel, Sinykin & Smith [Page 30] RFC 1697 RDBMS-MIB August 1994 "The state of this server's access to this database. Active(2) means the server is actively using the database. Available(3) means the server could use the database if necessary. Restricted(4) means the database is in some administratively determined state of less-than-complete availability. Unavailable(5) means the database is not available through this server. Other(1) means the database/server is in some other condition, possibly described in the vendor private MIB." ::= { rdbmsRelEntry 1 } rdbmsRelActiveTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time the database was made active by the server. If an instance of rdbmsRelState is not active(1), then attempts to access the corresponding instance of this object may result in either noSuchName (SNMPv1) or noSuchInstance (SNMPv2) being returned by the agent." ::= { rdbmsRelEntry 2 } ---------------------------------------------------------------- -- Well known resources for which limits, high water marks, -- access or allocation failures, and current levels of use -- are possibly available in either the rdbmsDbLimitedResources -- or the rdbmsSrvLimitedResources tables. rdbmsWellKnownLimitedResources OBJECT IDENTIFIER ::= { rdbmsObjects 10 } rdbmsLogSpace OBJECT-IDENTITY STATUS current DESCRIPTION "Storage allocated for redo and undo logs." ::= { rdbmsWellKnownLimitedResources 1} ---------------------------------------------------------------- rdbmsTraps OBJECT IDENTIFIER ::= { rdbmsMIB 2 } rdbmsStateChange NOTIFICATION-TYPE OBJECTS { rdbmsRelState } STATUS current DESCRIPTION Brower, Purvy, Daniel, Sinykin & Smith [Page 31] RFC 1697 RDBMS-MIB August 1994 "An rdbmsStateChange trap signifies that one of the database server/databases managed by this agent has changed its rdbmsRelState in a way that makes it less accessible for use. For these purposes, both active(2) and available(3) are considered fully accessible. The state sent with the trap is the new, less accessible state." ::= { rdbmsTraps 1 } rdbmsOutOfSpace NOTIFICATION-TYPE OBJECTS { rdbmsSrvInfoDiskOutOfSpaces } STATUS current DESCRIPTION "An rdbmsOutOfSpace trap signifies that one of the database servers managed by this agent has been unable to allocate space for one of the databases managed by this agent. Care should be taken to avoid flooding the network with these traps." ::= { rdbmsTraps 2 } ---------------------------------------------------------------- -- compliance information rdbmsConformance OBJECT IDENTIFIER ::= { rdbmsMIB 3 } rdbmsCompliances OBJECT IDENTIFIER ::= { rdbmsConformance 1 } rdbmsGroups OBJECT IDENTIFIER ::= { rdbmsConformance 2 } -- compliance statements rdbmsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the RDBMS MIB" MODULE HOST-RESOURCES-MIB MANDATORY-GROUPS { hrSystem } MODULE APPLICATION-MIB MANDATORY-GROUPS { applGroup } MODULE RDBMS-MIB MANDATORY-GROUPS { rdbmsGroup } GROUP rdbmsGroup DESCRIPTION "The rdbmsGroup is mandatory, but no write access to objects is required for compliance." OBJECT rdbmsDbContact MIN-ACCESS read-only DESCRIPTION Brower, Purvy, Daniel, Sinykin & Smith [Page 32] RFC 1697 RDBMS-MIB August 1994 "A compliant system need not allow write-access to this object." OBJECT rdbmsDbParamCurrValue MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsDbParamComment MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsDbLimitedResourceLimit MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsDbLimitedResourceDescription MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsSrvContact MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsSrvInfoMaxInboundAssociations MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsSrvParamCurrValue MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsSrvParamComment MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsSrvLimitedResourceLimit MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." OBJECT rdbmsSrvLimitedResourceDescription Brower, Purvy, Daniel, Sinykin & Smith [Page 33] RFC 1697 RDBMS-MIB August 1994 MIN-ACCESS read-only DESCRIPTION "A compliant system need not allow write-access to this object." ::= { rdbmsCompliances 1 } -- units of conformance -- rdbmsStateChange and rdbmsOutOfSpace traps are omitted -- intentionally. They are not required or part of any -- conformance group. rdbmsGroup OBJECT-GROUP OBJECTS { rdbmsDbPrivateMibOID, rdbmsDbVendorName, rdbmsDbName, rdbmsDbContact, rdbmsDbInfoProductName, rdbmsDbInfoVersion, rdbmsDbInfoSizeUnits, rdbmsDbInfoSizeAllocated, rdbmsDbInfoSizeUsed, rdbmsDbInfoLastBackup, rdbmsDbParamCurrValue, rdbmsDbParamComment, rdbmsDbLimitedResourceLimit, rdbmsDbLimitedResourceCurrent, rdbmsDbLimitedResourceHighwater, rdbmsDbLimitedResourceFailures, rdbmsDbLimitedResourceDescription, rdbmsSrvPrivateMibOID, rdbmsSrvVendorName, rdbmsSrvProductName, rdbmsSrvContact, rdbmsSrvInfoStartupTime, rdbmsSrvInfoFinishedTransactions, rdbmsSrvInfoDiskReads, rdbmsSrvInfoDiskWrites, rdbmsSrvInfoLogicalReads, rdbmsSrvInfoLogicalWrites, rdbmsSrvInfoPageReads, rdbmsSrvInfoPageWrites, rdbmsSrvInfoHandledRequests, rdbmsSrvInfoRequestRecvs, rdbmsSrvInfoRequestSends, rdbmsSrvInfoHighwaterInboundAssociations, rdbmsSrvInfoMaxInboundAssociations, rdbmsSrvParamCurrValue, rdbmsSrvParamComment, rdbmsSrvLimitedResourceLimit, rdbmsSrvLimitedResourceCurrent, rdbmsSrvLimitedResourceHighwater, Brower, Purvy, Daniel, Sinykin & Smith [Page 34] RFC 1697 RDBMS-MIB August 1994 rdbmsSrvLimitedResourceFailures, rdbmsSrvLimitedResourceDescription, rdbmsRelState, rdbmsRelActiveTime } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation of an RDBMS entity." ::= { rdbmsGroups 1 } ---------------------------------------------------------------- END 5. Acknowledgements This document was produced by the IETF RDBMSMIB working group: Mark Allyn, Boeing Virinder Batra, IBM Jonathan Bauer DEC Janice Befu, Network General Gerard Berthet, Independence Technologies Dave Brower, Ingres Barry Bruins, Network General David Campbell, Digital Equipment Corporation Stephen Campbell, European Database Consulting Jeff Case SNMP Research Dave Crocker Silicon Graphics Tony Daniel, Informix Craig DeNoce, Sybase Howard Dernehl, Ingres/Data General Mike Hartstein, Oracle Vijay Iyer, Independence Technologies Britt Johnston, Progress Bill Kehoe, Sybase Deirdre Kostick, Bellcore Cheryl Krupczak, Empire Technologies Damien Lindauer, Microsoft Ivan Lui, Informix John McCormack, Tandem Computers Inc. David Meldrum, Sybase David Morandi, Red Brick Systems Bob Natale, American Computer Diana Parr, Gupta David Perkins, Synoptics Randy Presuhn, Peer Networks Brian Promes, Novell Brower, Purvy, Daniel, Sinykin & Smith [Page 35] RFC 1697 RDBMS-MIB August 1994 Bob Purvy, Oracle Roger Reinsch, IBM Marshall T. Rose, Dover Beach Consulting Jon Saperia, DEC Marc Sinykin, Oracle Jay Smith, Oracle Mike Sorsen, Edward D. Jones & Co. Bob Taylor, Tandem Maria Valls, IBM Bert Wijnen, IBM Stan Wong, IBM 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] McCloghrie, K., and M. Rose, "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. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [6] Kille, S., WG Chair, and N. Freed, Editor, "The Network Services Monitoring MIB", RFC 1565, ISODE Consortium, Innosoft, January 1994. Brower, Purvy, Daniel, Sinykin & Smith [Page 36] RFC 1697 RDBMS-MIB August 1994 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses David Brower The ASK Group, INGRES DBMS Development 1080 Marina Village Parkway Alameda, CA, 94501 US Phone: +1 510 748 3418 EMail: daveb@ingres.com Bob Purvy Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 US Phone: +1 415 506 2972 EMail: bpurvy@us.oracle.com Anthony Daniel Informix Software, Inc. 921 S.W. Washington Street Portland, OR 97205 US Phone: +1 503 221 2638 EMail: anthony@informix.com Marc Sinykin Oracle Corporation 400 Oracle Parkway Redwood Shores, CA 94065 US Phone: +1 415 506 2477 EMail: msinykin@us.oracle.com Brower, Purvy, Daniel, Sinykin & Smith [Page 37] RFC 1697 RDBMS-MIB August 1994 Jay Smith Oracle Corporation 400 Oracle Parkway Redwood Shores, CA 94065 US Phone: +1 415 506 6239 EMail: jaysmith@us.oracle.com Brower, Purvy, Daniel, Sinykin & Smith [Page 38] snmp-mibs-downloader-1.1/mibrfcs/rfc1724.txt0000644000000000000000000007171511402176071015572 0ustar Network Working Group G. Malkin Request for Comments: 1724 Xylogics, Inc. Obsoletes: 1389 F. Baker Category: Standards Track Cisco Systems November 1994 RIP Version 2 MIB Extension 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing RIP Version 2. Acknowledgements The authors would like to thank the IETF ripv2 Working Group for their help in improving the RIP-2 MIB extension. Table of Contents 1. The Network Management Framework ...................... 2 2. Objects ............................................... 2 2.1 Format of Definitions ................................ 3 3. Overview .............................................. 3 3.1 Textual Conventions .................................. 3 3.2 Structure of MIB ..................................... 3 3.3 Modifications from RFC 1389 .......................... 3 4. Definitions ........................................... 5 4.1 Global Counters ...................................... 6 4.2 RIP Interface Tables ................................. 6 4.3 Peer Table ........................................... 12 5. References ............................................ 17 6. Security Considerations ............................... 18 7. Authors' Addresses .................................... 18 Malkin & Baker [Page 1] RFC 1724 RIP-2 MIB Extension November 1994 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. STD 17/RFC 1213 defines MIB- II, an evolution of MIB-I based on implementation experience and new operational requirements. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects 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) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. Malkin & Baker [Page 2] RFC 1724 RIP-2 MIB Extension November 1994 2.1 Format of Definitions Section 4 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [9]. 3. Overview 3.1 Textual Conventions Several new data types are introduced as a textual convention in this MIB document. These textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of the these textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. The new data type is RouteTag. The RouteTag type represents the contents of the Route Domain field in the packet header or route entry. 3.2 Structure of MIB The RIP-2 MIB contains global counters, useful for detecting the deleterious effects of RIP incompatibilities; two "interfaces" tables, which contains interface-specific statistics and configuration information; and an optional "peer" table, containing information that may be helpful in debugging neighbor relationships. Like the protocol itself, this MIB takes great care to preserve compatibility with RIP-1 systems and controls for monitoring and controlling system interactions. 3.3 Modifications from RFC 1389 The RIP-2 MIB was originally published in RFC 1389. It encoded the concept of a Routing Domain, and did not address unnumbered interfaces. In the current version of the protocol, Route Domains are deprecated; therefore, they are deprecated in the MIB as well. This means that the object rip2IfConfDomain is deprecated, and the object rip2PeerDomain (which cannot be deprecated, being an instance object) Malkin & Baker [Page 3] RFC 1724 RIP-2 MIB Extension November 1994 must always be zero. Unnumbered interfaces are supported in this version. Since the IP Address that the neighbor uses may be unknown to the system, a pseudo-address is used to identify these interfaces. The pseudo- address is in the class A network 0.0.0.0, and the host number (the least significant 24 bits of the address) are the ifIndex value of the relevant IP Interface. This is an additional new meaning of the objects rip2IfStatAddress and rip2IfConfAddress, backward compatible with the RFC 1389 usage. The object rip2IfConfSrcAddress is added, to permit the configuration of the source address on an unnumbered interface, and the meaning of the object rip2PeerAddress is broadened to remain relevant on unnumbered interfaces. rip2IfConfSend is augmented with two values for the use of Demand RIP under RIP-I and RIP-II rules. This avoids the necessity of a Demand RIP MIB. MD5 Authentication is supported. Malkin & Baker [Page 4] RFC 1724 RIP-2 MIB Extension November 1994 4. Definitions RIPv2-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, TimeTicks, IpAddress FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2 FROM RFC1213-MIB; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [9]. rip2 MODULE-IDENTITY LAST-UPDATED "9407272253Z" -- Wed Jul 27 22:53:04 PDT 1994 ORGANIZATION "IETF RIP-II Working Group" CONTACT-INFO " Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Tel: +1 805 681 0115 E-Mail: fbaker@cisco.com Postal: Gary Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803 Phone: (617) 272-8140 EMail: gmalkin@Xylogics.COM" DESCRIPTION "The MIB module to describe the RIP2 Version 2 Protocol" ::= { mib-2 23 } -- RIP-2 Management Information Base -- the RouteTag type represents the contents of the -- Route Domain field in the packet header or route entry. -- The use of the Route Domain is deprecated. RouteTag ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "the RouteTag type represents the contents of the Route Domain field in the packet header or route entry" SYNTAX OCTET STRING (SIZE (2)) Malkin & Baker [Page 5] RFC 1724 RIP-2 MIB Extension November 1994 --4.1 Global Counters -- The RIP-2 Globals Group. -- Implementation of this group is mandatory for systems -- which implement RIP-2. -- These counters are intended to facilitate debugging quickly -- changing routes or failing neighbors rip2Globals OBJECT IDENTIFIER ::= { rip2 1 } rip2GlobalRouteChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of route changes made to the IP Route Database by RIP. This does not include the refresh of a route's age." ::= { rip2Globals 1 } rip2GlobalQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of responses sent to RIP queries from other systems." ::= { rip2Globals 2 } --4.2 RIP Interface Tables -- RIP Interfaces Groups -- Implementation of these Groups is mandatory for systems -- which implement RIP-2. -- The RIP Interface Status Table. rip2IfStatTable OBJECT-TYPE SYNTAX SEQUENCE OF Rip2IfStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of subnets which require separate status monitoring in RIP." ::= { rip2 2 } rip2IfStatEntry OBJECT-TYPE Malkin & Baker [Page 6] RFC 1724 RIP-2 MIB Extension November 1994 SYNTAX Rip2IfStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Single Routing Domain in a single Subnet." INDEX { rip2IfStatAddress } ::= { rip2IfStatTable 1 } Rip2IfStatEntry ::= SEQUENCE { rip2IfStatAddress IpAddress, rip2IfStatRcvBadPackets Counter32, rip2IfStatRcvBadRoutes Counter32, rip2IfStatSentUpdates Counter32, rip2IfStatStatus RowStatus } rip2IfStatAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of this system on the indicated subnet. For unnumbered interfaces, the value 0.0.0.N, where the least significant 24 bits (N) is the ifIndex for the IP Interface in network byte order." ::= { rip2IfStatEntry 1 } rip2IfStatRcvBadPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RIP response packets received by the RIP process which were subsequently discarded for any reason (e.g. a version 0 packet, or an unknown command type)." ::= { rip2IfStatEntry 2 } rip2IfStatRcvBadRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Malkin & Baker [Page 7] RFC 1724 RIP-2 MIB Extension November 1994 DESCRIPTION "The number of routes, in valid RIP packets, which were ignored for any reason (e.g. unknown address family, or invalid metric)." ::= { rip2IfStatEntry 3 } rip2IfStatSentUpdates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of triggered RIP updates actually sent on this interface. This explicitly does NOT include full updates sent containing new information." ::= { rip2IfStatEntry 4 } rip2IfStatStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Writing invalid has the effect of deleting this interface." ::= { rip2IfStatEntry 5 } -- The RIP Interface Configuration Table. rip2IfConfTable OBJECT-TYPE SYNTAX SEQUENCE OF Rip2IfConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of subnets which require separate configuration in RIP." ::= { rip2 3 } rip2IfConfEntry OBJECT-TYPE SYNTAX Rip2IfConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Single Routing Domain in a single Subnet." INDEX { rip2IfConfAddress } ::= { rip2IfConfTable 1 } Rip2IfConfEntry ::= SEQUENCE { Malkin & Baker [Page 8] RFC 1724 RIP-2 MIB Extension November 1994 rip2IfConfAddress IpAddress, rip2IfConfDomain RouteTag, rip2IfConfAuthType INTEGER, rip2IfConfAuthKey OCTET STRING (SIZE(0..16)), rip2IfConfSend INTEGER, rip2IfConfReceive INTEGER, rip2IfConfDefaultMetric INTEGER, rip2IfConfStatus RowStatus, rip2IfConfSrcAddress IpAddress } rip2IfConfAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of this system on the indicated subnet. For unnumbered interfaces, the value 0.0.0.N, where the least significant 24 bits (N) is the ifIndex for the IP Interface in network byte order." ::= { rip2IfConfEntry 1 } rip2IfConfDomain OBJECT-TYPE SYNTAX RouteTag MAX-ACCESS read-create STATUS obsolete DESCRIPTION "Value inserted into the Routing Domain field of all RIP packets sent on this interface." DEFVAL { '0000'h } ::= { rip2IfConfEntry 2 } rip2IfConfAuthType OBJECT-TYPE SYNTAX INTEGER { noAuthentication (1), simplePassword (2), md5 (3) } MAX-ACCESS read-create Malkin & Baker [Page 9] RFC 1724 RIP-2 MIB Extension November 1994 STATUS current DESCRIPTION "The type of Authentication used on this interface." DEFVAL { noAuthentication } ::= { rip2IfConfEntry 3 } rip2IfConfAuthKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value to be used as the Authentication Key whenever the corresponding instance of rip2IfConfAuthType has a value other than noAuthentication. A modification of the corresponding instance of rip2IfConfAuthType does not modify the rip2IfConfAuthKey value. If a string shorter than 16 octets is supplied, it will be left- justified and padded to 16 octets, on the right, with nulls (0x00). Reading this object always results in an OCTET STRING of length zero; authentication may not be bypassed by reading the MIB object." DEFVAL { ''h } ::= { rip2IfConfEntry 4 } rip2IfConfSend OBJECT-TYPE SYNTAX INTEGER { doNotSend (1), ripVersion1 (2), rip1Compatible (3), ripVersion2 (4), ripV1Demand (5), ripV2Demand (6) } MAX-ACCESS read-create STATUS current DESCRIPTION "What the router sends on this interface. ripVersion1 implies sending RIP updates compliant with RFC 1058. rip1Compatible implies broadcasting RIP-2 updates using RFC 1058 route subsumption rules. ripVersion2 implies multicasting RIP-2 updates. ripV1Demand indicates the use of Demand RIP on a WAN interface under RIP Version 1 rules. ripV2Demand indicates the use of Malkin & Baker [Page 10] RFC 1724 RIP-2 MIB Extension November 1994 Demand RIP on a WAN interface under Version 2 rules." DEFVAL { rip1Compatible } ::= { rip2IfConfEntry 5 } rip2IfConfReceive OBJECT-TYPE SYNTAX INTEGER { rip1 (1), rip2 (2), rip1OrRip2 (3), doNotRecieve (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This indicates which version of RIP updates are to be accepted. Note that rip2 and rip1OrRip2 implies reception of multicast packets." DEFVAL { rip1OrRip2 } ::= { rip2IfConfEntry 6 } rip2IfConfDefaultMetric OBJECT-TYPE SYNTAX INTEGER ( 0..15 ) MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the metric that is to be used for the default route entry in RIP updates originated on this interface. A value of zero indicates that no default route should be originated; in this case, a default route via another router may be propagated." ::= { rip2IfConfEntry 7 } rip2IfConfStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Writing invalid has the effect of deleting this interface." ::= { rip2IfConfEntry 8 } rip2IfConfSrcAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION Malkin & Baker [Page 11] RFC 1724 RIP-2 MIB Extension November 1994 "The IP Address this system will use as a source address on this interface. If it is a numbered interface, this MUST be the same value as rip2IfConfAddress. On unnumbered interfaces, it must be the value of rip2IfConfAddress for some interface on the system." ::= { rip2IfConfEntry 9 } --4.3 Peer Table -- Peer Table -- The RIP Peer Group -- Implementation of this Group is Optional -- This group provides information about active peer -- relationships intended to assist in debugging. An -- active peer is a router from which a valid RIP -- updated has been heard in the last 180 seconds. rip2PeerTable OBJECT-TYPE SYNTAX SEQUENCE OF Rip2PeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of RIP Peers." ::= { rip2 4 } rip2PeerEntry OBJECT-TYPE SYNTAX Rip2PeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information regarding a single routing peer." INDEX { rip2PeerAddress, rip2PeerDomain } ::= { rip2PeerTable 1 } Rip2PeerEntry ::= SEQUENCE { rip2PeerAddress IpAddress, rip2PeerDomain RouteTag, rip2PeerLastUpdate TimeTicks, rip2PeerVersion INTEGER, rip2PeerRcvBadPackets Malkin & Baker [Page 12] RFC 1724 RIP-2 MIB Extension November 1994 Counter32, rip2PeerRcvBadRoutes Counter32 } rip2PeerAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address that the peer is using as its source address. Note that on an unnumbered link, this may not be a member of any subnet on the system." ::= { rip2PeerEntry 1 } rip2PeerDomain OBJECT-TYPE SYNTAX RouteTag MAX-ACCESS read-only STATUS current DESCRIPTION "The value in the Routing Domain field in RIP packets received from the peer. As domain suuport is deprecated, this must be zero." ::= { rip2PeerEntry 2 } rip2PeerLastUpdate OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the most recent RIP update was received from this system." ::= { rip2PeerEntry 3 } rip2PeerVersion OBJECT-TYPE SYNTAX INTEGER ( 0..255 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The RIP version number in the header of the last RIP packet received." ::= { rip2PeerEntry 4 } rip2PeerRcvBadPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Malkin & Baker [Page 13] RFC 1724 RIP-2 MIB Extension November 1994 "The number of RIP response packets from this peer discarded as invalid." ::= { rip2PeerEntry 5 } rip2PeerRcvBadRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of routes from this peer that were ignored because the entry format was invalid." ::= { rip2PeerEntry 6 } Malkin & Baker [Page 14] RFC 1724 RIP-2 MIB Extension November 1994 -- conformance information rip2Conformance OBJECT IDENTIFIER ::= { rip2 5 } rip2Groups OBJECT IDENTIFIER ::= { rip2Conformance 1 } rip2Compliances OBJECT IDENTIFIER ::= { rip2Conformance 2 } -- compliance statements rip2Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { rip2GlobalGroup, rip2IfStatGroup, rip2IfConfGroup, rip2PeerGroup } GROUP rip2GlobalGroup DESCRIPTION "This group defines global controls for RIP-II systems." GROUP rip2IfStatGroup DESCRIPTION "This group defines interface statistics for RIP-II systems." GROUP rip2IfConfGroup DESCRIPTION "This group defines interface configuration for RIP-II systems." GROUP rip2PeerGroup DESCRIPTION "This group defines peer information for RIP-II systems." ::= { rip2Compliances 1 } Malkin & Baker [Page 15] RFC 1724 RIP-2 MIB Extension November 1994 -- units of conformance rip2GlobalGroup OBJECT-GROUP OBJECTS { rip2GlobalRouteChanges, rip2GlobalQueries } STATUS current DESCRIPTION "This group defines global controls for RIP-II systems." ::= { rip2Groups 1 } rip2IfStatGroup OBJECT-GROUP OBJECTS { rip2IfStatAddress, rip2IfStatRcvBadPackets, rip2IfStatRcvBadRoutes, rip2IfStatSentUpdates, rip2IfStatStatus } STATUS current DESCRIPTION "This group defines interface statistics for RIP-II systems." ::= { rip2Groups 2 } rip2IfConfGroup OBJECT-GROUP OBJECTS { rip2IfConfAddress, rip2IfConfAuthType, rip2IfConfAuthKey, rip2IfConfSend, rip2IfConfReceive, rip2IfConfDefaultMetric, rip2IfConfStatus, rip2IfConfSrcAddress } STATUS current DESCRIPTION "This group defines interface configuration for RIP-II systems." ::= { rip2Groups 3 } rip2PeerGroup OBJECT-GROUP OBJECTS { rip2PeerAddress, rip2PeerDomain, rip2PeerLastUpdate, rip2PeerVersion, rip2PeerRcvBadPackets, rip2PeerRcvBadRoutes } STATUS current Malkin & Baker [Page 16] RFC 1724 RIP-2 MIB Extension November 1994 DESCRIPTION "This group defines peer information for RIP-II systems." ::= { rip2Groups 4 } END 5. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988. [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989. [3] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [4] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] Rose, M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1158, Performance Systems International, May 1990. [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [10] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, Xylogics, Inc., November 1994. Malkin & Baker [Page 17] RFC 1724 RIP-2 MIB Extension November 1994 [11] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721, Xylogics, Inc., November 1994. [12] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC 1722, Xylogics, Inc., November 1994. 6. Security Considerations Security issues are not discussed in this memo. 7. Authors' Addresses Gary Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803 Phone: (617) 272-8140 EMail: gmalkin@Xylogics.COM Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: 805-681-0115 EMail: fred@cisco.com Malkin & Baker [Page 18] snmp-mibs-downloader-1.1/mibrfcs/rfc1742.txt0000644000000000000000000051056211402176071015570 0ustar Network Working Group S. Waldbusser Request for Comments: 1742 Carnegie Mellon University Obsoletes: 1243 K. Frisa Category: Standards Track FORE Systems, Inc. January 1995 AppleTalk Management Information Base II 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. RFC 1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of the MIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion. Table of Contents 1. The Network Management Framework ...................... 2 2. Additions and Changes ................................. 3 2.1 New Groups ........................................... 3 2.2 Additional Variables ................................. 3 2.2.1 AARP Additions ..................................... 3 2.2.2 ATPort Additions ................................... 3 2.2.3 DDP Addition ....................................... 3 2.2.4 RTMP Additions ..................................... 4 2.2.5 KIP Addition ....................................... 4 2.2.6 ZIP Additions ...................................... 4 2.2.7 NBP Additions ...................................... 4 2.2.8 ATEcho Additions ................................... 4 2.3 Deprecations ......................................... 4 2.4 Changes .............................................. 5 3. Objects ............................................... 6 Waldbusser & Frisa [Page 1] RFC 1742 AppleTalk MIB II January 1995 3.1 Format of Definitions ................................ 6 4. Overview .............................................. 6 4.1 Structure of MIB ..................................... 7 4.2 The LocalTalk Link Access Protocol Group ............. 7 4.3 The AppleTalk Address Resolution Protocol Group ...... 7 4.4 The AppleTalk Port Group ............................. 8 4.5 The Datagram Delivery Protocol Group ................. 8 4.6 The Datagram Delivery Protocol Router Group .......... 8 4.7 The Routing Table Maintenance Protocol Group ......... 8 4.8 The Routing Table Maintenance Protocol Stub Group .... 8 4.9 The Kinetics Internet Protocol Group ................. 8 4.10 The Zone Information Protocol Router Group .......... 9 4.11 The Zone Information Protocol End Node Group ........ 9 4.12 The Name Binding Protocol Group ..................... 9 4.13 The AppleTalk Echo Protocol Group ................... 9 4.14 The AppleTalk Transaction Protocol Group ............ 9 4.15 The Printer Access Protocol Group ................... 9 4.16 The AppleTalk Session Protocol Group ................ 9 4.17 The AppleTalk Data Stream Protocol Group ............ 10 4.18 The AppleTalk Port Point to Point Group ............. 10 4.19 The Per Port Counters Group ......................... 10 4.20 Textual Conventions ................................. 10 5. Definitions ........................................... 11 6. Acknowledgmnts ........................................ 82 7. References ............................................ 83 8. Security Considerations ............................... 84 9. Authors' Addresses .................................... 84 1. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16/RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16/RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. STD 17/RFC 1213 defines MIB- II, an evolution of MIB-I based on implementation experience and new operational requirements. STD 15/RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. Waldbusser & Frisa [Page 2] RFC 1742 AppleTalk MIB II January 1995 The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Additions and Changes This MIB includes additions and changes to RFC 1243. These changes are outlined in the following sections. 2.1. New Groups The following groups are introduced in this MIB: - DDP Router - RTMP Stub - ZIP Router - ATP - PAP - ASP - ADSP - ATPortPtoP - Per Port Counters 2.2. Additional Variables Many variables, mostly counters, were added to groups that existed in RFC 1243. These variables are listed in the following sections. 2.2.1. AARP Additions aarpStatus aarpLookups aarpHits 2.2.2. ATPort Additions atportNetFrom atportZoneFrom atportInPkts atportOutPkts atportHome atportCurrentZone atportConflictPhysAddr atportZoneTable 2.2.3. DDP Addition ddpListenerTable Waldbusser & Frisa [Page 3] RFC 1742 AppleTalk MIB II January 1995 2.2.4. RTMP Additions rtmpInDataPkts rtmpOutDataPkts rtmpInRequestPkts rtmpNextIREqualChanges rtmpNextIRLessChanges rtmpRouteDeletes rtmpRoutingTableOverflows 2.2.5. KIP Addition kipFrom 2.2.6. ZIP Additions zipNetInfoTable zipInErrors 2.2.7. NBP Additions nbpAddress nbpSocket nbpEnumerator nbpInLookUpRequests nbpInLookUpReplies nbpInBroadcastRequests nbpInForwardRequests nbpOutLookUpReplies nbpRegistrationFailures nbpInErrors 2.2.8. ATEcho Additions atechoOutRequests atechoInReplies 2.3. Deprecations The following variables have been deprecated in this version of the MIB: llapInPkts llapOutPkts llapInNoHandlers llapInErrors Waldbusser & Frisa [Page 4] RFC 1742 AppleTalk MIB II January 1995 These llap variables were duplicated in the interfaces table of MIB- II. 2.4. Changes The IMPORTS list has been updated to reflect the current SNMP documents. New textual conventions have been defined. Hyphens have been removed from enumeration strings. Variables used as INDEXes to new tables have ACCESS not-accessible. This is because the values of the INDEX variables are contained in the object identifier for any of the other variables in the table; therefore, it does not need to be explicitly available as data. The atportNetConfig and atportZoneConfig variables have been changed from read-only to read-write. The atportZone variable has be renamed to atportZoneDefault, and its DESCRIPTION clause has been clarified. The atportType, atportStatus, and kipType variables have had more values added to their enumeration lists. The DDP group has been split into two groups; one includes variables that any AppleTalk node would implement and the other includes variables only a router would implement. The rtmpState variable now includes another enumeration, invalid(5), which is used when deleting rows. The variables rtmpRangeStart, rtmpRangeEnd, rtmpNextHop, rtmpType, rtmpPort, and rtmpHops have been changed from read-write to read- only. The ZIP Group has been renamed the ZIP End Node Group. The DESCRIPTION clause for zipZoneIndex has been clarified. The variables zipZoneName, zipZoneNetStart, and zipZoneNetEnd have been changed from read-write to read-only. The nbpIndex variable has been changed from read-only to read-write. The nbpObject, nbpType, and nbpZone variables now suggest that the agent reregister its service when any of these variables is changed. Waldbusser & Frisa [Page 5] RFC 1742 AppleTalk MIB II January 1995 The nbpState variable includes new enumerations. 3. Objects 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) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 3.1. Format of Definitions Section 5 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [9]. 4. Overview AppleTalk is a protocol suite which features an open peer-to-peer architecture that runs over a variety of transmission media. AppleTalk is defined in [10]. This protocol suite interoperates with the IP protocol suite through various encapsulation methods. As large AppleTalk networks are built that coexist with large IP networks, a method to manage the AppleTalk networks with SNMP becomes necessary. This MIB defines managed objects to be used for managing AppleTalk networks. Waldbusser & Frisa [Page 6] RFC 1742 AppleTalk MIB II January 1995 4.1. Structure of MIB The objects are arranged into the following groups: - LLAP - AARP - ATPort - DDP - DDP Router - RTMP - RTMP Stub - KIP - ZIP Router - ZIP End Node - NBP - ATEcho - ATP - PAP - ASP - ADSP - ATPortPtoP - Per Port Counters These groups are the basic unit of conformance. If the semantics of a group is applicable to an implementation, then it must implement all objects in that group. For example, a managed agent must implement the KIP group if and only if it implements the KIP protocol. These groups are defined to provide a method for managed agents to know which objects they must implement. 4.2. The LocalTalk Link Access Protocol Group The LocalTalk Link Access Protocol (LLAP) is a medium-speed data-link protocol designed for low cost and plug-and-play operation. The LLAP group is designed to manage all interfaces on a managed device that use this protocol. 4.3. The AppleTalk Address Resolution Protocol Group The AppleTalk Address Resolution Protocol (AARP) is used to map between AppleTalk node addresses, used by the Datagram Delivery Protocol, and the addresses of the underlying data link layer. The AARP table allows for management of the Address Mapping Table on the managed device. Waldbusser & Frisa [Page 7] RFC 1742 AppleTalk MIB II January 1995 4.4. The AppleTalk Port Group An AppleTalk Port is a logical connection to a network over which AppleTalk packets can be transmitted. The "network" could be a tunnel, backbone network, point-to-point link, etc, as well as a native AppleTalk network. This group allows the management of the configuration of these AppleTalk ports. 4.5. The Datagram Delivery Protocol Group The Datagram Delivery Protocol (DDP) is the network-layer protocol that is responsible for the socket-to-socket delivery of datagrams over the AppleTalk Internet. This group manages the DDP layer on the managed device. The DDP group contains statistical counters for the DDP protocol, and a table describing the DDP sockets that have protocol handlers registered. 4.6. The Datagram Delivery Protocol Router Group Some variables relevant to the Datagram Delivery Protocol (DDP) are only applicable to AppleTalk routers. These variables are included in this group. 4.7. The Routing Table Maintenance Protocol Group The Routing Table Maintenance Protocol (RTMP) is used by AppleTalk routers to create and maintain the routing tables that dictate the process of forwarding datagrams on the AppleTalk internet. The RTMP group manages the RTMP protocol as well as the routing tables generated by this protocol. 4.8. The Routing Table Maintenance Protocol Stub Group The RTMP Stub process is implemented by end nodes in order to maintain information about the routers on their networks. The variables in this group apply to both routers and end nodes. This group manages the RTMP stub process. 4.9. The Kinetics Internet Protocol Group The Kinetics Internet Protocol (KIP) is a protocol for encapsulating and routing AppleTalk datagrams over an IP internet. This name is historical. The KIP group manages the KIP routing protocol as well as the routing tables generated by this protocol. Waldbusser & Frisa [Page 8] RFC 1742 AppleTalk MIB II January 1995 4.10. The Zone Information Protocol Router Group The Zone Information Protocol (ZIP) is used to maintain a mapping between networks and zone names to facilitate the name lookup process performed by the Name Binding Protocol. Some variables relevant to the Zone Information Protocol (ZIP) are only applicable to AppleTalk routers. These variables are included in this group. 4.11. The Zone Information Protocol End Node Group The ZIP End Node group manages the variables relevant to the Zone Information Protocol (ZIP) that are applicable to both routers and end nodes. 4.12. The Name Binding Protocol Group The Name Binding Protocol (NBP) is a transport-level protocol that is used to convert human readable service names into the numeric AppleTalk network addresses needed for communicating across the AppleTalk network. The NBP group manages this protocol and the NBP services that exist on the managed device. 4.13. The AppleTalk Echo Protocol Group The AppleTalk Echo Protocol is a transport-level protocol used to test and verify the status of the AppleTalk internet. The AtEcho group manages this protocol. 4.14. The AppleTalk Transaction Protocol Group The AppleTalk Transaction Protocol (ATP) is a transport-level protocol that is defined to support transaction based communications. The ATP group manages this protocol. 4.15. The Printer Access Protocol Group The Printer Access Protocol (PAP) is a session-level protocol that enables communications between workstations and print servers. The PAP group manages this protocol. 4.16. The AppleTalk Session Protocol Group The AppleTalk Session Protocol (ASP) is a session-level protocol that enables sequences of communications to occur. ASP uses the services of the AppleTalk Transaction Protocol (ATP), but extends these services into the session layer. The ASP group manages this protocol. Waldbusser & Frisa [Page 9] RFC 1742 AppleTalk MIB II January 1995 4.17. The AppleTalk Data Stream Protocol Group The AppleTalk Data Stream Protocol (ADSP) is a session-level protocol that provides symmetric, connection-oriented, full-duplex communication between two sockets on the AppleTalk internet. In addition, ADSP handles flow-control and reliability. The ADSP group manages this protocol. 4.18. The AppleTalk Port Point to Point Group The AppleTalk Port Point to Point Group manages ports that have one or more associated point-to-point connections. 4.19. The Per Port Counters Group The Per Port Counters Group contains a set of counters which are deemed useful on a per port basis. 4.20. Textual Conventions New data types are introduced as textual conventions in this MIB document. These textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of these textual conventions has no effect on either the syntax or the semantics of any managed objects. The use of this is merely an artifact of the explanatory method used. Objects defined in terms of this method are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. The new data types are: ATNetworkNumber ::= -- 2 octets of network -- number in network -- byte order OCTET STRING (SIZE (2)) DdpNodeAddress ::= -- 2 octets of net number -- in network byte order, -- 1 octet of node number OCTET STRING (SIZE (3)) DdpSocketAddress ::= -- 2 octets of net number -- in network byte order, -- 1 octet of node number, Waldbusser & Frisa [Page 10] RFC 1742 AppleTalk MIB II January 1995 -- 1 octet of socket -- number (0..255) OCTET STRING (SIZE (4)) ATName ::= -- 0 to 32 octets of -- AppleTalk ASCII [10] OCTET STRING (SIZE (0..32)) 5. Definitions APPLETALK-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, IpAddress, TimeTicks FROM RFC1155-SMI DisplayString, mib-2 FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in RFC-1212. -- The following reference is used in this MIB: -- [Inside AppleTalk] -- This refers to Gursharan S. Sidhu, Richard F. Andrews, and -- Alan B. Oppenheimer, Inside AppleTalk, Second Edition, -- Addison Wesley, (1990). -- AppleTalk MIB appletalk OBJECT IDENTIFIER ::= { mib-2 13 } ATNetworkNumber ::= -- 2 octets of net number -- in network byte order OCTET STRING (SIZE (2)) DdpNodeAddress ::= -- 2 octets of net number -- in network byte order, -- 1 octet of node number OCTET STRING (SIZE (3)) DdpSocketAddress ::= -- 2 octets of net number -- in network byte order, -- 1 octet of node number, Waldbusser & Frisa [Page 11] RFC 1742 AppleTalk MIB II January 1995 -- 1 octet of socket number -- (0..255) OCTET STRING (SIZE (4)) ATName ::= -- 0 to 32 octets of AppleTalk -- ASCII [Inside AppleTalk] OCTET STRING (SIZE (0..32)) llap OBJECT IDENTIFIER ::= { appletalk 1 } aarp OBJECT IDENTIFIER ::= { appletalk 2 } atport OBJECT IDENTIFIER ::= { appletalk 3 } ddp OBJECT IDENTIFIER ::= { appletalk 4 } rtmp OBJECT IDENTIFIER ::= { appletalk 5 } kip OBJECT IDENTIFIER ::= { appletalk 6 } zipRouter OBJECT IDENTIFIER ::= { appletalk 7 } nbp OBJECT IDENTIFIER ::= { appletalk 8 } atecho OBJECT IDENTIFIER ::= { appletalk 9 } atp OBJECT IDENTIFIER ::= { appletalk 10 } pap OBJECT IDENTIFIER ::= { appletalk 11 } asp OBJECT IDENTIFIER ::= { appletalk 12 } adsp OBJECT IDENTIFIER ::= { appletalk 13 } atportptop OBJECT IDENTIFIER ::= { appletalk 14 } rtmpStub OBJECT IDENTIFIER ::= { appletalk 16 } zipEndNode OBJECT IDENTIFIER ::= { appletalk 17 } perPort OBJECT IDENTIFIER ::= { appletalk 18 } -- The LLAP Group -- -- Implementation of this group is mandatory for all -- entities that implement LLAP -- -- Notes for the interfaces group -- -- When implementing the Interfaces Group of MIB-II, it is -- suggested that the following values be used for any -- LocalTalk interfaces: -- ifMtu: 600 -- ifSpeed: 230000 -- ifPhysAddress: the one octet node number for the -- particular interface -- -- Note also that LLAP control packets should not be -- included in the Interfaces Group packet or octet -- counters. Waldbusser & Frisa [Page 12] RFC 1742 AppleTalk MIB II January 1995 llapTable OBJECT-TYPE SYNTAX SEQUENCE OF LlapEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The list of LLAP entries." ::= { llap 1 } llapEntry OBJECT-TYPE SYNTAX LlapEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An LLAP entry containing objects for the LocalTalk Link Access Protocol for a particular LocalTalk interface. As an example, an instance of the llapOutPkts object might be named llapOutPks.1" INDEX { llapIfIndex } ::= { llapTable 1 } LlapEntry ::= SEQUENCE { llapIfIndex INTEGER, llapInPkts Counter, llapOutPkts Counter, llapInNoHandlers Counter, llapInLengthErrors Counter, llapInErrors Counter, llapCollisions Counter, llapDefers Counter, llapNoDataErrors Counter, llapRandomCTSErrors Counter, llapFCSErrors Counter } llapIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The LLAP interface to which this entry pertains. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { llapEntry 1 } Waldbusser & Frisa [Page 13] RFC 1742 AppleTalk MIB II January 1995 -- this object has been deprecated because it duplicates the -- sum of the MIB-II variables ifInUcastPkts and -- ifInNUcastPkts llapInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS deprecated DESCRIPTION "The total number of good data packets received on this LocalTalk interface." ::= { llapEntry 2 } -- this object has been deprecated because it duplicates the -- sum of the MIB-II variables ifOutUcastPkts and -- ifOutNUcastPkts llapOutPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS deprecated DESCRIPTION "The total number of data packets transmitted on this LocalTalk interface." ::= { llapEntry 3 } -- this object has been deprecated because it duplicates the -- MIB-II variable ifInUnknownProtos llapInNoHandlers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS deprecated DESCRIPTION "The total number of good packets received on this LocalTalk interface for which there was no protocol handler." ::= { llapEntry 4 } llapInLengthErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of packets received on this LocalTalk interface whose actual length did not match the length in the header." ::= { llapEntry 5 } Waldbusser & Frisa [Page 14] RFC 1742 AppleTalk MIB II January 1995 -- this object has been deprecated because it duplicates the -- MIB-II variable ifInErrors llapInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS deprecated DESCRIPTION "The total number of packets containing errors received on this LocalTalk interface." ::= { llapEntry 6 } llapCollisions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of collisions assumed on this LocalTalk interface due to the lack of a lapCTS reply." ::= { llapEntry 7 } llapDefers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times this LocalTalk interface deferred to other packets." ::= { llapEntry 8 } llapNoDataErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times this LocalTalk interface received a lapRTS packet and expected a data packet, but did not receive any data packet." ::= { llapEntry 9 } llapRandomCTSErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times this LocalTalk interface received a lapCTS packet that was not solicited by a lapRTS packet." Waldbusser & Frisa [Page 15] RFC 1742 AppleTalk MIB II January 1995 ::= { llapEntry 10 } llapFCSErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times this LocalTalk interface received a packet with an FCS (Frame Check Sequence) error." ::= { llapEntry 11 } -- The AARP Group -- -- Implementation of this group is mandatory for all entities -- that implement AARP aarpTable OBJECT-TYPE SYNTAX SEQUENCE OF AarpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The AppleTalk Address Translation Table contains an equivalence of AppleTalk Network Addresses to the link layer physical address." ::= { aarp 1 } aarpEntry OBJECT-TYPE SYNTAX AarpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry contains one AppleTalk Network Address to physical address equivalence. As an example, an instance of the aarpPhysAddress object might be named aarpPhysAddress.1.0.80.234" INDEX { aarpIfIndex, aarpNetAddress } ::= { aarpTable 1 } AarpEntry ::= SEQUENCE { aarpIfIndex INTEGER, aarpPhysAddress OCTET STRING, aarpNetAddress DdpNodeAddress, aarpStatus INTEGER } Waldbusser & Frisa [Page 16] RFC 1742 AppleTalk MIB II January 1995 aarpIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." ::= { aarpEntry 1 } aarpPhysAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "The media-dependent physical address." ::= { aarpEntry 2 } aarpNetAddress OBJECT-TYPE SYNTAX DdpNodeAddress ACCESS read-only STATUS mandatory DESCRIPTION "The AppleTalk Network Address corresponding to the media-dependent physical address." ::= { aarpEntry 3 } aarpStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of this AARP entry. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the aarpTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant aarpStatus object." Waldbusser & Frisa [Page 17] RFC 1742 AppleTalk MIB II January 1995 ::= { aarpEntry 4 } aarpLookups OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the AARP cache for this entity was searched." ::= { aarp 2 } aarpHits OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times an entry was searched for and found in the AARP cache for this entity." ::= { aarp 3 } -- The ATPort Group -- -- Implementation of this group is mandatory for all entities -- that implement AppleTalk ports -- -- Note that to be compliant with this group, all variables -- that have read-write access must be implemented as -- read-write. atportTable OBJECT-TYPE SYNTAX SEQUENCE OF AtportEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of AppleTalk ports for this entity." ::= { atport 1 } atportEntry OBJECT-TYPE SYNTAX AtportEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The description of one of the AppleTalk ports on this entity. As an example, an instance of the atportNetFrom object might be named atportNetFrom.2" Waldbusser & Frisa [Page 18] RFC 1742 AppleTalk MIB II January 1995 INDEX { atportIndex } ::= { atportTable 1 } AtportEntry ::= SEQUENCE { atportIndex INTEGER, atportDescr DisplayString, atportType INTEGER, atportNetStart ATNetworkNumber, atportNetEnd ATNetworkNumber, atportNetAddress DdpNodeAddress, atportStatus INTEGER, atportNetConfig INTEGER, atportZoneConfig INTEGER, atportZoneDefault ATName, atportIfIndex INTEGER, atportNetFrom DdpNodeAddress, atportZoneFrom DdpNodeAddress, atportInPkts Counter, atportOutPkts Counter, atportHome INTEGER, atportCurrentZone ATName, atportConflictPhysAddr OCTET STRING } atportIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each AppleTalk port. Its value is between 1 and the total number of AppleTalk ports. The value for each port must remain constant at least from the re-initialization of the entity's network management system to the next re-initialization." ::= { atportEntry 1 } atportDescr OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION "A text string containing information about the port. This string is intended for presentation to a human; it must not contain anything but printable ASCII characters." ::= { atportEntry 2 } Waldbusser & Frisa [Page 19] RFC 1742 AppleTalk MIB II January 1995 -- Several objects throughout the MIB key off of atportType to -- determine the format of OCTET STRING addresses of peers. -- The address formats are as follows: -- localtalk, ethertalk1, ethertalk2, tokentalk, iptalk, -- fdditalk, smdstalk, arctalk, and virtual take the -- format of DdpNodeAddress -- serialPPP: null OCTET STRING -- serialNonstandard: vendor specific -- aurp: see AURP MIB to determine format -- frameRelay: 32 bit DLCI in network byte order -- (OCTET STRING (SIZE (4))) -- x25: X121Address (see RFC 1382) -- ip: IP address (OCTET STRING (SIZE (4))) -- osi: NSAP (OCTET STRING (SIZE (3..20))) -- decnetIV: 6 bit area, 10 bit host in network byte order -- (OCTET STRING (SIZE (2))) -- arap: ??? -- nonAppleTalk3Com: based on ifType -- ipx: 32 bit network number in network byte order -- followed by datalink address of host -- arns: 32 bit ARNS header -- hdlc: DdpNodeAddress or null OCTET STRING atportType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following localtalk(2), ethertalk1(3), ethertalk2(4), tokentalk(5), iptalk(6), serialPPP(7), serialNonstandard(8), virtual(9), -- an internal interface fdditalk(10), arctalk(11), smdstalk(12), aurp(13), frameRelay(14), x25(15), ip(16), osi(17), decnetIV(18), arap(19), isdnInThePacketMode(20), nonAppleTalk3Com(21), ipx(22), arns(23), Waldbusser & Frisa [Page 20] RFC 1742 AppleTalk MIB II January 1995 hdlc(24) } ACCESS read-write STATUS mandatory DESCRIPTION "The type of port, distinguished by the protocol immediately below DDP in the protocol stack." ::= { atportEntry 3 } atportNetStart OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-write STATUS mandatory DESCRIPTION "The first AppleTalk network address in the range configured for this port. If this port is not a native AppleTalk port, this object shall have the value of two octets of zero." ::= { atportEntry 4 } atportNetEnd OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-write STATUS mandatory DESCRIPTION "The last AppleTalk network address in the range configured for this port. If the network to which this AppleTalk port is connected is a non-extended network, or if it is not a native AppleTalk port, the value for atportNetEnd shall be two octets of zero." ::= { atportEntry 5 } atportNetAddress OBJECT-TYPE SYNTAX DdpNodeAddress ACCESS read-write STATUS mandatory DESCRIPTION "The AppleTalk network address configured for this port. In addition, this value may be used as a hint for an initial node number used during node-finding. If this port is not a native AppleTalk port, this object shall have the value of three octets of zero." ::= { atportEntry 6 } atportStatus OBJECT-TYPE SYNTAX INTEGER { routing(1), --this port is fully configured & routing Waldbusser & Frisa [Page 21] RFC 1742 AppleTalk MIB II January 1995 unconfigured(2), off(3), invalid(4), endNode(5), -- this port is acting as an end node offDueToConflict(6), -- port is off due to -- configuration conflict other(7) -- none of the states defined above } ACCESS read-write STATUS mandatory DESCRIPTION "The configuration status of this port. Setting this object to the value invalid(4) has the effect of invalidating the corresponding entry in the atportTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant atportStatus object." ::= { atportEntry 7 } atportNetConfig OBJECT-TYPE SYNTAX INTEGER { conflictOrientedSeed(1), -- use configured network -- range even if it conflicts with another -- AppleTalk device garnered(2), -- acquire from another AppleTalk device guessed(3), -- generate a "random" network range unconfigured(4), -- no other value applies conflictAverseSeed(5), -- use configured network -- range, but don't come up if it conflicts softSeed(6) -- attempt to use configured network -- range, but use network range from another -- router if our configuration conflicts } ACCESS read-write STATUS mandatory DESCRIPTION "The status of the network information for this port. If this port is not a native AppleTalk port, this object shall have the value unconfigured(4)." ::= { atportEntry 8 } Waldbusser & Frisa [Page 22] RFC 1742 AppleTalk MIB II January 1995 atportZoneConfig OBJECT-TYPE SYNTAX INTEGER { conflictOrientedSeed(1), -- use configured zone -- information even if it conflicts with -- another AppleTalk device garnered(2), -- acquire from another AppleTalk device guessed(3), -- generate "random" zone information unconfigured(4), -- no other value applies conflictAverseSeed(5), -- use configured zone -- information, but don't come up if it -- conflicts softSeed(6) -- attempt to use configured zone -- information, but use zone information -- from another router if our configuration -- conflicts } ACCESS read-write STATUS mandatory DESCRIPTION "The status of the zone information for this port. If this port is not a native AppleTalk port, this object shall have the value unconfigured(4)." ::= { atportEntry 9 } atportZoneDefault OBJECT-TYPE SYNTAX ATName ACCESS read-write STATUS mandatory DESCRIPTION "The name of the default zone for this port. If this port only has one zone, that zone is represented here. If this port is not a native AppleTalk port, this object shall contain an octet string of zero length. When this value is changed in a router, the router must send a zipNotify packet on the associated network." ::= { atportEntry 10 } atportIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The physical interface associated with this AppleTalk port. The interface identified by a particular value of this index is the same interface Waldbusser & Frisa [Page 23] RFC 1742 AppleTalk MIB II January 1995 as identified by the same value of ifIndex." ::= { atportEntry 11 } atportNetFrom OBJECT-TYPE SYNTAX DdpNodeAddress ACCESS read-only STATUS mandatory DESCRIPTION "When atportNetConfig is set to garnered(2), this variable contains the DDP address of an entity from which the AppleTalk network number was garnered. When atportNetConfig is set to conflictOrientedSeed(1), conflictAverseSeed(5), or softSeed(6), this variable contains the DDP address of an entity which confirmed or supplied our AppleTalk network number, for example by replying to a ZIP GetNetInfo request. If atportNetConfig is set to guessed(3) or unconfigured(4), or if the entity has not received any network number confirmation, this variable should be set to three octets of zero." ::= { atportEntry 12 } atportZoneFrom OBJECT-TYPE SYNTAX DdpNodeAddress ACCESS read-only STATUS mandatory DESCRIPTION "When atportZoneConfig is set to garnered(2), this variable contains the DDP address of an entity from which the AppleTalk zone list was garnered. When atportZoneConfig is set to conflictOrientedSeed(1), conflictAverseSeed(5), or softSeed(6), this variable contains the DDP address of an entity which confirmed or supplied our AppleTalk zone information, for example by replying to a ZIP GetNetInfo request or a ZIP Query. If atportZoneConfig is set to guessed(3) or unconfigured(4), or if the entity has not received any zone confirmation, this variable should be set to three octets of zero." ::= { atportEntry 13 } Waldbusser & Frisa [Page 24] RFC 1742 AppleTalk MIB II January 1995 atportInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received by this entity on this port." ::= { atportEntry 14 } atportOutPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets transmitted by this entity on this port." ::= { atportEntry 15 } atportHome OBJECT-TYPE SYNTAX INTEGER { home(1), notHome(2) } ACCESS read-only STATUS mandatory DESCRIPTION "An indication of whether or not the entity is homed on this port, that is to say, a port on which the entity could perform NBP registrations for services that it chooses to advertise." ::= { atportEntry 16 } atportCurrentZone OBJECT-TYPE SYNTAX ATName ACCESS read-write STATUS mandatory DESCRIPTION "The current zone for the port. In general, this is the zone name in which services on this port will be registered. If this port is not a native AppleTalk port, this object shall contain an octet string of zero length. Note that modifications to this object do not affect the nbpTable." ::= { atportEntry 17 } atportConflictPhysAddr OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only Waldbusser & Frisa [Page 25] RFC 1742 AppleTalk MIB II January 1995 STATUS mandatory DESCRIPTION "The link-layer address of a device which caused this entity to set atportStatus to offDueToConflict(6). If this address is not available, or if the entity has not set atportStatus to offDueToConflict, this object shall be a zero length OCTET STRING." ::= { atportEntry 18 } -- The atportZoneTable stores information about the zones -- associated with each port. The default zone for each -- port is stored in the port's atportZoneDefault variable; -- all other zones for the port are listed in this table. -- If a port only has one zone, it should be stored in the -- port's atportZoneDefault variable, and this table should -- be empty. -- -- One of the indexes for this table is atportZoneName. -- Even though AppleTalk zone name matches are -- case-insensitive, this table will store zone names -- regardless of case. SNMP Get, GetNext and Set operations -- are performed on these (potentially) mixed case strings -- according to the normal SNMP rules with the following -- caveat: in processing a SET request, the agent shall -- perform a case-insensitive search and a case-sensitive -- search. If the case-insensitive search matches and the -- case-sensitive search does not match, the "equivalent" -- zone name exists in another entry with a different -- capitalization and the SET request shall fail due -- to the name being inconsistent (SNMPv1 should return a -- genErr.) This insures that only one version of a zone -- name will appear in each agent, at the expense of forcing -- a management station to query using that exact name. atportZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF AtportZoneEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of zone information for non-default zones on ports." ::= { atport 2 } atportZoneEntry OBJECT-TYPE SYNTAX AtportZoneEntry ACCESS not-accessible STATUS mandatory Waldbusser & Frisa [Page 26] RFC 1742 AppleTalk MIB II January 1995 DESCRIPTION "An entry of zone information for a port. As an example, an instance of the atportZoneStatus object might be named atportZoneStatus.2.8.84.119.105.108.105.103.104.116" INDEX { atportZonePort, atportZoneName } ::= { atportZoneTable 1 } AtportZoneEntry ::= SEQUENCE { atportZonePort INTEGER, atportZoneName ATName (SIZE (1..32)), atportZoneStatus INTEGER } atportZonePort OBJECT-TYPE SYNTAX INTEGER ACCESS not-accessible STATUS mandatory DESCRIPTION "An integer representing the port to which this zone belongs. The port identified by a particular value of this object is the same port as identified by the same value of atportIndex." ::= { atportZoneEntry 1 } atportZoneName OBJECT-TYPE SYNTAX ATName (SIZE (1..32)) ACCESS not-accessible STATUS mandatory DESCRIPTION "A zone name configured for the AppleTalk port referred to in the corresponding entry of atportZonePort. When this value is changed in a router, the router must send a zipNotify packet on the associated network." ::= { atportZoneEntry 2 } atportZoneStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION Waldbusser & Frisa [Page 27] RFC 1742 AppleTalk MIB II January 1995 "The status of this zone entry. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the atportZoneTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant atportZoneStatus object." ::= { atportZoneEntry 3 } -- The DDP Group -- -- Implementation of this group is mandatory for all -- entities that implement DDP -- -- This group consists of DDP variables that would be -- implemented by either a router or an end node. The -- following variables are included: -- ddpOutRequests -- ddpOutShorts -- ddpOutLongs -- ddpInReceives -- ddpInLocalDatagrams -- ddpNoProtocolHandlers -- ddpTooShortErrors -- ddpTooLongErrors -- ddpShortDDPErrors -- ddpChecksumErrors -- ddpListenerTable -- -- Note that the variables in this group are not numbered -- sequentially. This was done so that it was not necessary -- to deprecate variables from RFC 1243. ddpOutRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of DDP datagrams which were supplied to DDP by local DDP clients in requests for Waldbusser & Frisa [Page 28] RFC 1742 AppleTalk MIB II January 1995 transmission. Note that this counter does not include any datagrams counted in ddpForwRequests." ::= { ddp 1 } ddpOutShorts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of short DDP datagrams which were transmitted from this entity." ::= { ddp 2 } ddpOutLongs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of long DDP datagrams which were transmitted from this entity." ::= { ddp 3 } ddpInReceives OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input datagrams received by DDP, including those received in error." ::= { ddp 4 } ddpInLocalDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams for which this entity was their final DDP destination." ::= { ddp 6 } ddpNoProtocolHandlers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of DDP datagrams addressed to this entity that were addressed to an upper layer protocol Waldbusser & Frisa [Page 29] RFC 1742 AppleTalk MIB II January 1995 for which no protocol handler existed." ::= { ddp 7 } ddpTooShortErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams dropped because the received data length was less than the data length specified in the DDP header or the received data length was less than the length of the expected DDP header." ::= { ddp 9 } ddpTooLongErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams dropped because they exceeded the maximum DDP datagram size." ::= { ddp 10 } ddpShortDDPErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams dropped because this entity was not their final destination and their type was short DDP." ::= { ddp 12 } ddpChecksumErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams for which this DDP entity was their final destination, and which were dropped because of a checksum error." ::= { ddp 14 } ddpListenerTable OBJECT-TYPE SYNTAX SEQUENCE OF DdpListenerEntry ACCESS not-accessible Waldbusser & Frisa [Page 30] RFC 1742 AppleTalk MIB II January 1995 STATUS mandatory DESCRIPTION "The ddpListenerTable stores information for each DDP socket that has a listener." ::= { ddp 15 } ddpListenerEntry OBJECT-TYPE SYNTAX DdpListenerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This ddpListenerEntry contains information about a particular socket that has a socket listener. As an example, an instance of the ddpListenerStatus object might be named ddpListenerStatus.0.80.220.1" INDEX { ddpListenerAddress } ::= { ddpListenerTable 1 } DdpListenerEntry ::= SEQUENCE { ddpListenerAddress DdpSocketAddress, ddpListenerInPkts Counter, ddpListenerStatus INTEGER } ddpListenerAddress OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS not-accessible STATUS mandatory DESCRIPTION "The DDP address that this socket listener is bound to. If this socket listener isn't bound to a particular address, for instance if it is intended for all interfaces, this object shall have the value of three octets of zero followed by one octet of socket number. The socket number must not equal zero." ::= { ddpListenerEntry 1 } ddpListenerInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received for this listener." ::= { ddpListenerEntry 2 } Waldbusser & Frisa [Page 31] RFC 1742 AppleTalk MIB II January 1995 ddpListenerStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of this socket listener. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ddpListenerTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ddpListenerStatus object." ::= { ddpListenerEntry 3 } -- The DDP Router Group -- -- Implementation of this group is required for all routers -- which implement DDP -- -- This group consists of DDP variables that only a router -- would implement. The following variables are included: -- ddpForwRequests -- ddpOutNoRoutes -- ddpBroadcastErrors -- ddpHopCountErrors -- ddpForwardingTable -- -- Note that the variables in this group are not numbered -- sequentially. This was done so that variables from -- RFC 1243 did not need to be deprecated. ddpForwRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams for which this entity was not their final DDP destination, as a result of Waldbusser & Frisa [Page 32] RFC 1742 AppleTalk MIB II January 1995 which an attempt was made to find a route to forward them to that final destination." ::= { ddp 5 } ddpOutNoRoutes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of DDP datagrams dropped because a route could not be found to their final destination." ::= { ddp 8 } ddpBroadcastErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams dropped because this entity was not their final destination and they were addressed to the link level broadcast." ::= { ddp 11 } ddpHopCountErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams dropped because this entity was not their final destination and their hop count would exceed 15." ::= { ddp 13 } -- The ddpForwardingTable is a read-only table which shows the -- next hop that a datagram will take when being routed to a -- specific network. If a manager wishes to change data in -- this table via SNMP, he must change it in the MIB for the -- routing protocol itself (by incrementing hop counts, -- etc), rather than in this table. This table is derived -- by the managed entity from the information it receives -- from the routing protocols that it supports. -- -- This table also shows the routing table from which the next -- hop was derived. When a MIB is written for an AppleTalk -- routing protocol, it should include the definition of an -- object identifier which will be used in the -- ddpForwardingProto variable defined here. (For example, -- a value for RTMP is defined as { ddp-forw-proto-oids 1 } Waldbusser & Frisa [Page 33] RFC 1742 AppleTalk MIB II January 1995 -- below.) -- -- To look for a specific net N in this table, it is suggested -- that the management station perform a get-next query for -- ddpForwardingNetEnd.(N-1). This will retrieve the correct -- row if it exists in the table. ddpForwardingTable OBJECT-TYPE SYNTAX SEQUENCE OF DdpForwardingEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table of forwarding entries for DDP. This table contains a route for each AppleTalk network currently known to the entity." ::= { ddp 16 } ddpForwardingEntry OBJECT-TYPE SYNTAX DdpForwardingEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A forwarding entry for a particular AppleTalk network. As an example, an instance of the ddpForwardingPort object might be named ddpForwardingPort.0.90" INDEX { ddpForwardingNetEnd } ::= { ddpForwardingTable 1 } DdpForwardingEntry ::= SEQUENCE { ddpForwardingNetEnd ATNetworkNumber, ddpForwardingNetStart ATNetworkNumber, ddpForwardingNextHop OCTET STRING, ddpForwardingProto OBJECT IDENTIFIER, ddpForwardingModifiedTime TimeTicks, ddpForwardingUseCounts Counter, ddpForwardingPort INTEGER } ddpForwardingNetEnd OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS not-accessible STATUS mandatory DESCRIPTION "The last network number in the network range matched by this forwarding entry. This will not be zero even if this corresponds to a non-extended Waldbusser & Frisa [Page 34] RFC 1742 AppleTalk MIB II January 1995 net." ::= { ddpForwardingEntry 1 } ddpForwardingNetStart OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-only STATUS mandatory DESCRIPTION "The first network number in the network range matched by this forwarding entry." ::= { ddpForwardingEntry 2 } ddpForwardingNextHop OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The next hop in the route to this entry's destination network. The format of this address can be determined by examinating the atportType corresponding to this entry." ::= { ddpForwardingEntry 3 } ddpForwardingProto OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The routing mechanism by which this route was learned." ::= { ddpForwardingEntry 4 } ddpForwardingModifiedTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the time of the last modification to this entry. The initial value of ddpForwardingModified time shall be the value of sysUpTime at the time the entry is created." ::= { ddpForwardingEntry 5 } ddpForwardingUseCounts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Waldbusser & Frisa [Page 35] RFC 1742 AppleTalk MIB II January 1995 "The number of times this entry has been used to route a packet to the destination network. Note that this counter is not cleared when the corresponding ddpForwardingNextHop variable changes." ::= { ddpForwardingEntry 6 } ddpForwardingPort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The AppleTalk port through which ddpForwardingNextHop is reached. The interface identified by a particular value of this variable is the same interface as identified by the same value of atportIndex." ::= { ddpForwardingEntry 7 } ddpForwProtoOids OBJECT IDENTIFIER ::= { ddp 17 } -- The value to be assigned to ddpForwardingProto when the -- routing protocol is RTMP. rtmpRoutingProto OBJECT IDENTIFIER ::= { ddpForwProtoOids 1 } -- The value to be assigned to ddpForwardingProto when the -- routing protocol is KIP. kipRoutingProto OBJECT IDENTIFIER ::= { ddpForwProtoOids 2 } ddpForwardingTableOverflows OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the entity attempted to add an entry to the forwarding table but failed due to overflow." ::= { ddp 18 } -- The RTMP Group -- -- Implementation of this group is required for all routers -- which implement RTMP rtmpTable OBJECT-TYPE SYNTAX SEQUENCE OF RtmpEntry Waldbusser & Frisa [Page 36] RFC 1742 AppleTalk MIB II January 1995 ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of Routing Table Maintenance Protocol entries for this entity." ::= { rtmp 1 } rtmpEntry OBJECT-TYPE SYNTAX RtmpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The route entry to a particular network range. As an example, an instance of the rtmpPort object might be named rtmpPort.0.80" INDEX { rtmpRangeStart } ::= { rtmpTable 1 } RtmpEntry ::= SEQUENCE { rtmpRangeStart ATNetworkNumber, rtmpRangeEnd ATNetworkNumber, rtmpNextHop OCTET STRING, rtmpType INTEGER, rtmpPort INTEGER, rtmpHops INTEGER, rtmpState INTEGER } rtmpRangeStart OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-only STATUS mandatory DESCRIPTION "The first DDP network address in the network range to which this routing entry pertains. This is a two octet DDP network address in network byte order." ::= { rtmpEntry 1 } rtmpRangeEnd OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-only STATUS mandatory DESCRIPTION "The last DDP network address in the network range to which this routing entry pertains. This is a two octet DDP network address in network byte order. If the network to which this routing entry pertains is Waldbusser & Frisa [Page 37] RFC 1742 AppleTalk MIB II January 1995 a non-extended network, the value for rtmpRangeEnd shall be two octets of zero." ::= { rtmpEntry 2 } rtmpNextHop OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The next internet router in the route to this entry's destination network. The format of this address can be determined by examinating the atportType corresponding to this entry." ::= { rtmpEntry 3 } rtmpType OBJECT-TYPE SYNTAX INTEGER { other(1), appletalk(2), serialPPP(3), serialNonstandard(4) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of network over which this route points." ::= { rtmpEntry 4 } rtmpPort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The AppleTalk port over which this route points. The interface identified by a particular value of this variable is the same interface as identified by the same value of atportIndex." ::= { rtmpEntry 5 } rtmpHops OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of hops required to reach the destination network to which this routing entry pertains." ::= { rtmpEntry 6 } Waldbusser & Frisa [Page 38] RFC 1742 AppleTalk MIB II January 1995 rtmpState OBJECT-TYPE SYNTAX INTEGER { good(1), suspect(2), badZero(3), badOne(4), invalid(5) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of the information contained in this route entry. Setting this object to the value invalid(5) has the effect of invalidating the corresponding entry in the rtmpTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant rtmpState object." ::= { rtmpEntry 7 } rtmpInDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of good RTMP data packets received by this entity." ::= { rtmp 2 } rtmpOutDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of RTMP packets sent by this entity." ::= { rtmp 3 } rtmpInRequestPkts OBJECT-TYPE SYNTAX Counter Waldbusser & Frisa [Page 39] RFC 1742 AppleTalk MIB II January 1995 ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of good RTMP Request packets received by this entity." ::= { rtmp 4 } rtmpNextIREqualChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of times RTMP changes the Next Internet Router in a routing entry because the hop count advertised in a routing tuple was equal to the current hop count for a particular network." ::= { rtmp 5 } rtmpNextIRLessChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of times RTMP changes the Next Internet Router in a routing entry because the hop count advertised in a routing tuple was less than the current hop count for a particular network." ::= { rtmp 6 } rtmpRouteDeletes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of times RTMP deletes a route because it was aged out of the table. This can help to detect routing problems." ::= { rtmp 7 } rtmpRoutingTableOverflows OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times RTMP attempted to add a route to the RTMP table but failed due to lack of space." ::= { rtmp 8 } Waldbusser & Frisa [Page 40] RFC 1742 AppleTalk MIB II January 1995 -- The RTMP Stub Group -- -- Implementation of this group is mandatory for all -- entities that implement RTMP -- -- It is intended that this group be implemented by routers -- and end nodes. rtmpOutRequestPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of RTMP Request packets sent by this entity." ::= { rtmpStub 1 } rtmpInVersionMismatches OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of RTMP packets received by this entity that were rejected due to a version mismatch." ::= { rtmpStub 2 } rtmpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of RTMP packets received by this entity that were rejected for an error other than version mismatch." ::= { rtmpStub 3 } -- The KIP Group -- -- Implementation of this group is mandatory for all -- entities that implement KIP kipTable OBJECT-TYPE SYNTAX SEQUENCE OF KipEntry ACCESS not-accessible STATUS mandatory DESCRIPTION Waldbusser & Frisa [Page 41] RFC 1742 AppleTalk MIB II January 1995 "The table of routing information for KIP networks." ::= { kip 1 } kipEntry OBJECT-TYPE SYNTAX KipEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the routing table for KIP networks. As an example, an instance of the kipCore object might be named kipCore.0.80" INDEX { kipNetStart } ::= { kipTable 1 } KipEntry ::= SEQUENCE { kipNetStart ATNetworkNumber, kipNetEnd ATNetworkNumber, kipNextHop IpAddress, kipHopCount INTEGER, kipBCastAddr IpAddress, kipCore INTEGER, kipType INTEGER, kipState INTEGER, kipShare INTEGER, kipFrom IpAddress } kipNetStart OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-only STATUS mandatory DESCRIPTION "The first AppleTalk network address in the range for this routing entry. This address is a two octet DDP network address in network byte order." ::= { kipEntry 1 } kipNetEnd OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-write STATUS mandatory DESCRIPTION "The last AppleTalk network address in the range for this routing entry. This address is a two octet DDP network address in network byte order. If the network to which this AppleTalk port is connected is a non-extended network, the value for kipNetEnd Waldbusser & Frisa [Page 42] RFC 1742 AppleTalk MIB II January 1995 shall be two octets of zero." ::= { kipEntry 2 } kipNextHop OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The IP address of the next hop in the route to this entry's destination network." ::= { kipEntry 3 } kipHopCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The number of hops required to reach the destination network to which this entry pertains." ::= { kipEntry 4 } kipBCastAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The form of the IP address used to broadcast on this network." ::= { kipEntry 5 } kipCore OBJECT-TYPE SYNTAX INTEGER { core(1), notcore(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of kipNextHop as a core gateway." ::= { kipEntry 6 } kipType OBJECT-TYPE SYNTAX INTEGER { kipRouter(1), net(2), host(3), other(4), async(5) Waldbusser & Frisa [Page 43] RFC 1742 AppleTalk MIB II January 1995 } ACCESS read-write STATUS mandatory DESCRIPTION "The type of the entity that this route points to." ::= { kipEntry 7 } kipState OBJECT-TYPE SYNTAX INTEGER { configured(1), -- this entry is not aged learned(2), invalid(3) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this network entry. Setting this object to the value invalid(3) has the effect of invalidating the corresponding entry in the kipTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant kipState object." ::= { kipEntry 8 } kipShare OBJECT-TYPE SYNTAX INTEGER { shared(1), private(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If the information in this entry is propagated to other routers as part of the AA routing protocol, the value of this variable is equal to shared(1). Otherwise its value is private(2)." ::= { kipEntry 9 } kipFrom OBJECT-TYPE SYNTAX IpAddress ACCESS read-only Waldbusser & Frisa [Page 44] RFC 1742 AppleTalk MIB II January 1995 STATUS mandatory DESCRIPTION "The IP address from which the routing entry was learned via the AA protocol. If this entry was not created via the AA protocol, it should contain IP address 0.0.0.0." ::= { kipEntry 10 } -- The ZIP Router Group -- -- Implementation of this group is required for all routers -- which implement ZIP -- -- This group consists of ZIP variables that would be -- implemented by a router. zipTable OBJECT-TYPE SYNTAX SEQUENCE OF ZipEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of zone information for reachable AppleTalk networks." ::= { zipRouter 1 } zipEntry OBJECT-TYPE SYNTAX ZipEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry of zone information for a particular zone and network combination. As an example, an instance of the zipZoneState object might be named zipZoneState.0.80.4" INDEX { zipZoneNetStart, zipZoneIndex } ::= { zipTable 1 } ZipEntry ::= SEQUENCE { zipZoneName ATName, zipZoneIndex INTEGER, zipZoneNetStart ATNetworkNumber, zipZoneNetEnd ATNetworkNumber, zipZoneState INTEGER, zipZoneFrom OCTET STRING, zipZonePort INTEGER } Waldbusser & Frisa [Page 45] RFC 1742 AppleTalk MIB II January 1995 zipZoneName OBJECT-TYPE SYNTAX ATName ACCESS read-only STATUS mandatory DESCRIPTION "The zone name of this entry. This is stored in Mac ASCII format. If the full zone list for the entry is not known, the value for zipZoneName shall be a zero length octet string." ::= { zipEntry 1 } zipZoneIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An integer that is unique to the zipZoneName that is present in this entry. For any given zone name, every zipEntry that has an equal zone name will have the same zipZoneIndex. When a zone name is discovered which is not currently in the table, it will be assigned an index greater than any previously assigned index." ::= { zipEntry 2 } zipZoneNetStart OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-only STATUS mandatory DESCRIPTION "The network that starts the range for this entry. This address is a two octet DDP network address in network byte order." ::= { zipEntry 3 } zipZoneNetEnd OBJECT-TYPE SYNTAX ATNetworkNumber ACCESS read-only STATUS mandatory DESCRIPTION "The network that ends the range for this entry. This address is a two octet DDP network address in network byte order. If the network to which this zip entry pertains is a non-extended network, the value for zipZoneNetEnd shall be two octets of zero." ::= { zipEntry 4 } Waldbusser & Frisa [Page 46] RFC 1742 AppleTalk MIB II January 1995 zipZoneState OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this zip entry. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the zipTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant zipZoneState object." ::= { zipEntry 5 } zipZoneFrom OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The address from which this zone name to network number mapping was learned. The format of this address can be determined by examining the atportType corresponding to this entry. When this mapping is learned from the entity itself, this object shall have the value of three octets of zero." ::= { zipEntry 6 } zipZonePort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The AppleTalk port through which this zone name to network number mapping was learned. The interface identified by a particular value of this variable is the same interface as identified by the same value of atportIndex." Waldbusser & Frisa [Page 47] RFC 1742 AppleTalk MIB II January 1995 ::= { zipEntry 7 } zipInZipQueries OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP Queries received by this entity." ::= { zipRouter 2 } zipInZipReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP Replies received by this entity." ::= { zipRouter 3 } zipInZipExtendedReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP Extended Replies received by this entity." ::= { zipRouter 4 } zipZoneConflictErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times a conflict has been detected between this entity's zone information and another entity's zone information." ::= { zipRouter 5 } zipInObsoletes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP Takedown or ZIP Bringup packets received by this entity. Note that as the ZIP Takedown and ZIP Bringup packets have been obsoleted, the receipt of one of these packets indicates that a node sent it in error." ::= { zipRouter 6 } Waldbusser & Frisa [Page 48] RFC 1742 AppleTalk MIB II January 1995 -- The zipRouterNetInfoTable is used to record information -- about zipGetNetInfo and zipGetNetInfo Reply packets that -- were received on each port for a router. This table -- augments the atportTable. zipRouterNetInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF ZipRouterNetInfoEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of Net Info packets received by each port on this entity." ::= { zipRouter 7 } zipRouterNetInfoEntry OBJECT-TYPE SYNTAX ZipRouterNetInfoEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The description of the Net Info packets received on a particular port on this entity. One such entry shall exist for each atport on this router entity. As an example, an instance of the zipInGetNetInfos object might be named zipInGetNetInfos.2" INDEX { atportIndex } ::= { zipRouterNetInfoTable 1 } ZipRouterNetInfoEntry ::= SEQUENCE { zipInGetNetInfos Counter, zipOutGetNetInfoReplies Counter, zipZoneOutInvalids Counter, zipAddressInvalids Counter } zipInGetNetInfos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP GetNetInfo packets received on this port by this entity." ::= { zipRouterNetInfoEntry 1 } zipOutGetNetInfoReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Waldbusser & Frisa [Page 49] RFC 1742 AppleTalk MIB II January 1995 DESCRIPTION "The number of ZIP GetNetInfo Reply packets sent out this port by this entity." ::= { zipRouterNetInfoEntry 2 } zipZoneOutInvalids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this entity has sent a ZIP GetNetInfo Reply with the zone invalid bit set in response to a GetNetInfo Request with an invalid zone name." ::= { zipRouterNetInfoEntry 3 } zipAddressInvalids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this entity had to broadcast a ZIP GetNetInfo Reply because the GetNetInfo Request had an invalid address." ::= { zipRouterNetInfoEntry 4 } -- The ZIP End Node Group -- -- Implementation of this group is mandatory for all entities -- that implement ZIP -- -- This group consists of ZIP variables that would be -- implemented by either a router or an end node. -- The zipNetInfoTable is used to record information about -- zipGetNetInfo and zipGetNetInfo Reply packets that were -- received on each port of an entity. This table augments -- the atportTable. zipNetInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF ZipNetInfoEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of Net Info packets received by each port on this entity." ::= { zipEndNode 1 } Waldbusser & Frisa [Page 50] RFC 1742 AppleTalk MIB II January 1995 zipNetInfoEntry OBJECT-TYPE SYNTAX ZipNetInfoEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The description of the Net Info packets received on a particular port on this entity. One such entry shall exist for each atport on this entity. As an example, an instance of the zipOutGetNetInfos object might be named zipOutGetNetInfos.2" INDEX { atportIndex } ::= { zipNetInfoTable 1 } ZipNetInfoEntry ::= SEQUENCE { zipOutGetNetInfos Counter, zipInGetNetInfoReplies Counter, zipZoneInInvalids Counter } zipOutGetNetInfos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP GetNetInfo packets sent out this port by this entity." ::= { zipNetInfoEntry 1 } zipInGetNetInfoReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP GetNetInfo Reply packets received on this port by this entity." ::= { zipNetInfoEntry 2 } zipZoneInInvalids OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this entity has received a ZIP GetNetInfo Reply with the zone invalid bit set because the corresponding GetNetInfo Request had an invalid zone name." ::= { zipNetInfoEntry 3 } Waldbusser & Frisa [Page 51] RFC 1742 AppleTalk MIB II January 1995 zipInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP packets received by this entity that were rejected for any error." ::= { zipEndNode 2 } -- The NBP Group -- -- Implementation of this group is mandatory for all entities -- that implement NBP nbpTable OBJECT-TYPE SYNTAX SEQUENCE OF NbpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of NBP services registered on this entity." ::= { nbp 1 } nbpEntry OBJECT-TYPE SYNTAX NbpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The description of an NBP service registered on this entity. As an example, an instance of the nbpZone object might be named nbpZone.2" INDEX { nbpIndex } ::= { nbpTable 1 } NbpEntry ::= SEQUENCE { nbpIndex INTEGER, nbpObject ATName (SIZE (1..32)), nbpType ATName (SIZE (1..32)), nbpZone ATName, nbpState INTEGER, nbpAddress DdpSocketAddress, nbpEnumerator INTEGER (0..255) } nbpIndex OBJECT-TYPE SYNTAX INTEGER Waldbusser & Frisa [Page 52] RFC 1742 AppleTalk MIB II January 1995 ACCESS read-write STATUS mandatory DESCRIPTION "The index of this NBP entry. This index is unique with respect to the indexes of all other NBP entries, and shall remain constant throughout the lifetime of this object." ::= { nbpEntry 1 } nbpObject OBJECT-TYPE SYNTAX ATName (SIZE (1..32)) ACCESS read-write STATUS mandatory DESCRIPTION "The name of the service described by this entity. When this variable is changed, the entity should perform an NBP registration using the new nbpObject." ::= { nbpEntry 2 } nbpType OBJECT-TYPE SYNTAX ATName (SIZE (1..32)) ACCESS read-write STATUS mandatory DESCRIPTION "The type of the service described by this entity. When this variable is changed, the entity should perform an NBP registration using the new nbpType." ::= { nbpEntry 3 } nbpZone OBJECT-TYPE SYNTAX ATName ACCESS read-write STATUS mandatory DESCRIPTION "The zone the service described by this entity is registered in. This must be the actual zone name, without any wildcard characters. When this variable is changed, the entity should perform an NBP registration using the new nbpZone." ::= { nbpEntry 4 } nbpState OBJECT-TYPE SYNTAX INTEGER { valid(1), registering(2), -- attempting to register the service registrationFailed(3), invalid(4) } Waldbusser & Frisa [Page 53] RFC 1742 AppleTalk MIB II January 1995 ACCESS read-write STATUS mandatory DESCRIPTION "The state of this NBP entry. When the registration for an entry in the nbpTable fails, it is an implementation-specific matter as to how long the entry will remain in the registrationFailed(3) state before moving to the invalid(4) state. Note that the entry may pass immediately from the registrationFailed state to the invalid state. Setting this object to the value invalid(4) has the effect of invalidating the corresponding entry in the nbpTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant nbpState object." ::= { nbpEntry 5 } nbpAddress OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS read-write STATUS mandatory DESCRIPTION "The DDP network, node, and socket number of this entity. If this is unspecified, for instance if the registration is on all ports of a multiport device, this object shall have the value of three octets of zero, followed by one octet of socket number." ::= { nbpEntry 6 } nbpEnumerator OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The enumerator assigned to this entity." ::= { nbpEntry 7 } nbpInLookUpRequests OBJECT-TYPE SYNTAX Counter Waldbusser & Frisa [Page 54] RFC 1742 AppleTalk MIB II January 1995 ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP LookUp Requests received." ::= { nbp 2 } nbpInLookUpReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP LookUp Replies received." ::= { nbp 3 } nbpInBroadcastRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP Broadcast Requests received." ::= { nbp 4 } nbpInForwardRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP Forward Requests received." ::= { nbp 5 } nbpOutLookUpReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP LookUp Replies sent." ::= { nbp 6 } nbpRegistrationFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this node experienced a failure in attempting to register an NBP entity." ::= { nbp 7 } Waldbusser & Frisa [Page 55] RFC 1742 AppleTalk MIB II January 1995 nbpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP packets received by this entity that were rejected for any error." ::= { nbp 8 } -- The ATEcho Group -- -- Implementation of this group is mandatory for all -- entities that implement ATEcho atechoRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of AppleTalk Echo requests received." ::= { atecho 1 } atechoReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of AppleTalk Echo replies sent." ::= { atecho 2 } atechoOutRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of AppleTalk Echo requests sent." ::= { atecho 3 } atechoInReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of AppleTalk Echo replies received." ::= { atecho 4 } Waldbusser & Frisa [Page 56] RFC 1742 AppleTalk MIB II January 1995 -- The ATP Group -- -- Implementation of this group is mandatory for all entities -- that implement ATP atpInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ATP packets received by this entity." ::= { atp 1 } atpOutPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ATP packets sent by this entity." ::= { atp 2 } atpTRequestRetransmissions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times that a timeout occurred and a Transaction Request packet needed to be retransmitted by this host." ::= { atp 3 } atpTResponseRetransmissions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times a timeout was detected and a Transaction Response packet needed to be retransmitted by this host." ::= { atp 4 } atpReleaseTimerExpiredCounts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the release timer expired, as a result of which a Request Control Block had to be Waldbusser & Frisa [Page 57] RFC 1742 AppleTalk MIB II January 1995 deleted." ::= { atp 5 } atpRetryCountExceededs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the retry count was exceeded, and an error was returned to the client of ATP." ::= { atp 6 } atpListenerTable OBJECT-TYPE SYNTAX SEQUENCE OF AtpListenerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The atpListenerTable stores information for each ATP socket that has a listener." ::= { atp 7 } atpListenerEntry OBJECT-TYPE SYNTAX AtpListenerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This atpListenerEntry contains information about a particular socket that has a socket listener. As an example, an instance of the atpListenerStatus object might be named atpListenerStatus.0.80.220.3" INDEX { atpListenerAddress } ::= { atpListenerTable 1 } AtpListenerEntry ::= SEQUENCE { atpListenerAddress DdpSocketAddress, atpListenerStatus INTEGER } atpListenerAddress OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS not-accessible STATUS mandatory DESCRIPTION "The DDP address that this socket listener is bound to. If this socket listener isn't bound to a particular address, for instance if it is intended for all interfaces, this object shall have the value Waldbusser & Frisa [Page 58] RFC 1742 AppleTalk MIB II January 1995 of three octets of zero followed by one octet of socket number." ::= { atpListenerEntry 1 } atpListenerStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of this socket. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the atpListenerTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant atpListenerStatus object." ::= { atpListenerEntry 2 } -- The PAP group -- -- Implementation of this group is mandatory for all entities -- that implement PAP papInOpenConns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PAP Open Connection requests received by this entity." ::= { pap 1 } papOutOpenConns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Waldbusser & Frisa [Page 59] RFC 1742 AppleTalk MIB II January 1995 "The number of PAP Open Connection requests sent by this entity." ::= { pap 2 } papInDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PAP Data messages received by this entity." ::= { pap 3 } papOutDatas OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PAP Data messages sent by this entity." ::= { pap 4 } papInCloseConns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PAP Close Connection requests received by this entity." ::= { pap 5 } papOutCloseConns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of PAP Close Connection requests sent by this entity." ::= { pap 6 } papTickleTimeoutCloses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the PAP entity on this node closed a connection because it didn't receive a Tickle message before its timer expired." Waldbusser & Frisa [Page 60] RFC 1742 AppleTalk MIB II January 1995 ::= { pap 7 } papServerTable OBJECT-TYPE SYNTAX SEQUENCE OF PapServerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of servers on this entity that are accessible through the Printer Access Protocol." ::= { pap 8 } papServerEntry OBJECT-TYPE SYNTAX PapServerEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A set of information about a particular PAP server's configuration and performance. As an example, an instance of the papServerStatus object might be named papServerStatus.1" INDEX { papServerIndex } ::= { papServerTable 1 } PapServerEntry ::= SEQUENCE { papServerIndex INTEGER, papServerListeningSocket DdpSocketAddress, papServerStatus DisplayString, papServerCompletedJobs Counter, papServerBusyJobs INTEGER, papServerFreeJobs INTEGER, papServerAuthenticationFailures Counter, papServerAccountingFailures Counter, papServerGeneralFailures Counter, papServerState INTEGER, papServerLastStatusMsg DisplayString } papServerIndex OBJECT-TYPE SYNTAX INTEGER ACCESS not-accessible STATUS mandatory DESCRIPTION "An unique value for each Printer Access Protocol Server." ::= { papServerEntry 1 } Waldbusser & Frisa [Page 61] RFC 1742 AppleTalk MIB II January 1995 papServerListeningSocket OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS read-write STATUS mandatory DESCRIPTION "The Server Listening Socket that this PAP server is listening on." ::= { papServerEntry 2 } papServerStatus OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The status string of this server. This is the message as it would appear in a PAP Status Reply from this server." ::= { papServerEntry 3 } papServerCompletedJobs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of jobs that have been accepted and successfully executed by this server." ::= { papServerEntry 4 } papServerBusyJobs OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of GetNextJob calls that have accepted and are currently executing a job." ::= { papServerEntry 5 } papServerFreeJobs OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The minimum number of GetNextJob calls that are currently waiting for a job." ::= { papServerEntry 6 } Waldbusser & Frisa [Page 62] RFC 1742 AppleTalk MIB II January 1995 papServerAuthenticationFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this PAP server rejected a job because the job was not correctly authenticated." ::= { papServerEntry 7 } papServerAccountingFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this PAP server rejected a job because the job did not fit some accounting rule, such as exceeding a quota." ::= { papServerEntry 8 } papServerGeneralFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this PAP server rejected a job for some reason other than authentication or accounting failures." ::= { papServerEntry 9 } papServerState OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this PAP Server entry. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the papServerTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently Waldbusser & Frisa [Page 63] RFC 1742 AppleTalk MIB II January 1995 in use. Proper interpretation of such entries requires examination of the relevant papServerState object." ::= { papServerEntry 10 } papServerLastStatusMsg OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The last status message that was transmitted by this server." ::= { papServerEntry 11 } -- The ASP Group -- -- Implementation of this group is mandatory for all entities -- that implement ASP aspInputTransactions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ASP requests and replies received by this entity. Note that this is not necessarily the number of packets containing ASP transactions." ::= { asp 1 } aspOutputTransactions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ASP requests and replies sent by this entity. Note that this is not necessarily the number of packets containing ASP transactions." ::= { asp 2 } aspInOpenSessions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ASP Open Session requests and replies received by this entity." ::= { asp 3 } Waldbusser & Frisa [Page 64] RFC 1742 AppleTalk MIB II January 1995 aspOutOpenSessions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ASP Open Session requests and replies sent by this entity." ::= { asp 4 } aspInCloseSessions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ASP Close Session requests and replies received by this entity." ::= { asp 5 } aspOutCloseSessions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ASP Close Session requests and replies sent by this entity." ::= { asp 6 } aspNoMoreSessionsErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times an error condition was returned because this server implementation could not support another session." ::= { asp 7 } aspTickleTimeOutCloses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the ASP entity on this node closed a connection because it didn't receive any messages from the remote end before its timer expired." ::= { asp 8 } Waldbusser & Frisa [Page 65] RFC 1742 AppleTalk MIB II January 1995 aspConnTable OBJECT-TYPE SYNTAX SEQUENCE OF AspConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of ASP connections on this entity." ::= { asp 9 } aspConnEntry OBJECT-TYPE SYNTAX AspConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A set of information describing an ASP connection. As an example, an instance of the aspConnState object might be named aspConnState.0.80.220.135.0.80.239.119.12" INDEX { aspConnLocalAddress, aspConnRemoteAddress, aspConnID } ::= { aspConnTable 1 } AspConnEntry ::= SEQUENCE { aspConnLocalAddress DdpSocketAddress, aspConnRemoteAddress DdpSocketAddress, aspConnID INTEGER (1..255), aspConnLastReqNum INTEGER (1..65535), aspConnServerEnd INTEGER, aspConnState INTEGER } aspConnLocalAddress OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS not-accessible STATUS mandatory DESCRIPTION "The local address of this ASP connection." ::= { aspConnEntry 1 } aspConnRemoteAddress OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS not-accessible STATUS mandatory DESCRIPTION "The remote address of this ASP connection. If this entry is in the listening mode, this object shall have a value of four octets of zero." ::= { aspConnEntry 2 } Waldbusser & Frisa [Page 66] RFC 1742 AppleTalk MIB II January 1995 aspConnID OBJECT-TYPE SYNTAX INTEGER (1..255) ACCESS not-accessible STATUS mandatory DESCRIPTION "The remote Connection ID of this ASP connection. If this entry is in the listening mode, this object shall have a value of zero." ::= { aspConnEntry 3 } aspConnLastReqNum OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The last request number on this ASP connection. If this entry is in the listening mode, this object shall have a value of zero." ::= { aspConnEntry 4 } aspConnServerEnd OBJECT-TYPE SYNTAX INTEGER { sss(1), -- Server Session Socket wss(2), -- Workstation Session Socket sls(3) -- Server Listening Socket } ACCESS read-only STATUS mandatory DESCRIPTION "Specifies what mode the local session end is in." ::= { aspConnEntry 5 } aspConnState OBJECT-TYPE SYNTAX INTEGER { open(1), closed(2), invalid(3) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this ASP connection. Setting this object to the value invalid(3) has the effect of invalidating the corresponding entry in the aspConnTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Waldbusser & Frisa [Page 67] RFC 1742 AppleTalk MIB II January 1995 Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant aspConnState object." ::= { aspConnEntry 6 } -- The ADSP Group -- -- Implementation of this group is mandatory for all entities -- that implement ADSP adspInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ADSP packets received by this entity." ::= { adsp 1 } adspOutPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ADSP packets sent by this entity." ::= { adsp 2 } adspInOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of data octets contained in ADSP packets received by this entity. Note that this does not include EOM bits." ::= { adsp 3 } adspOutOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of data octets contained in ADSP packets sent by this entity. Note that this does not include EOM bits." Waldbusser & Frisa [Page 68] RFC 1742 AppleTalk MIB II January 1995 ::= { adsp 4 } adspInDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ADSP data packets this entity has received." ::= { adsp 5 } adspOutDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ADSP data packets this entity has sent." ::= { adsp 6 } adspTimeoutErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the ADSP on this entity detected an expired connection timer." ::= { adsp 7 } adspTimeoutCloseErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the ADSP on this entity closed a connection because of too many timeouts." ::= { adsp 8 } adspConnTable OBJECT-TYPE SYNTAX SEQUENCE OF AdspConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of ADSP connections on this entity." ::= { adsp 9 } adspConnEntry OBJECT-TYPE SYNTAX AdspConnEntry Waldbusser & Frisa [Page 69] RFC 1742 AppleTalk MIB II January 1995 ACCESS not-accessible STATUS mandatory DESCRIPTION "A set of information describing an ADSP connection. As an example, an instance of the adspConnState object might be named adspConnState.0.80.220.7.0.80.239.142.31231" INDEX { adspConnLocalAddress, adspConnRemoteAddress, adspConnLocalConnID } ::= { adspConnTable 1 } AdspConnEntry ::= SEQUENCE { adspConnLocalAddress DdpSocketAddress, adspConnLocalConnID INTEGER (0..65535), adspConnRemoteAddress DdpSocketAddress, adspConnRemoteConnID INTEGER (0..65535), adspConnState INTEGER } adspConnLocalAddress OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS not-accessible STATUS mandatory DESCRIPTION "The local DDP address of this ADSP connection." ::= { adspConnEntry 1 } adspConnLocalConnID OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS not-accessible STATUS mandatory DESCRIPTION "The local Connection ID of this ADSP connection. If this entry specifies an ADSP listener, this value shall be zero." ::= { adspConnEntry 2 } adspConnRemoteAddress OBJECT-TYPE SYNTAX DdpSocketAddress ACCESS not-accessible STATUS mandatory DESCRIPTION "The remote DDP address of this ADSP connection. If this entry specifies an ADSP listener, this value shall be zero." ::= { adspConnEntry 3 } adspConnRemoteConnID OBJECT-TYPE Waldbusser & Frisa [Page 70] RFC 1742 AppleTalk MIB II January 1995 SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The remote Connection ID of this ADSP connection. If this entry specifies an ADSP listener, this value shall be zero." ::= { adspConnEntry 4 } adspConnState OBJECT-TYPE SYNTAX INTEGER { open(1), localHalfOpen(2), remoteHalfOpen(3), listening(4), closed(5), invalid(6) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this ADSP connection. The state is open if both ends are established. If only one end is established, then the state is half-open. If neither end is established, then the state is closed. If an ADSP server is listening on a socket and is not yet connected, its state is set to listening, and the adspConnRemoteAddress, adspConnRemoteSocket, adspConnRemoteConnID, and adspConnRemoteWindowSize are all set to zero. Setting this object to the value invalid(6) has the effect of invalidating the corresponding entry in the adspConnTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examination of the relevant adspConnState object." ::= { adspConnEntry 5 } Waldbusser & Frisa [Page 71] RFC 1742 AppleTalk MIB II January 1995 -- The ATPortPtoP Group -- -- Implementation of this group is mandatory for all entities -- that implement AppleTalk point-to-point links atportPtoPTable OBJECT-TYPE SYNTAX SEQUENCE OF AtportPtoPEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of AppleTalk point-to-point connections for this entity." ::= { atportptop 1 } atportPtoPEntry OBJECT-TYPE SYNTAX AtportPtoPEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The description of one of the AppleTalk point-to-point connections on this entity. As an example, an instance of the atportPtoPRemoteAddress object might be named atportPtoPRemoteAddress.2" INDEX { atportPtoPIndex } ::= { atportPtoPTable 1 } AtportPtoPEntry ::= SEQUENCE { atportPtoPIndex INTEGER, atportPtoPProtocol OBJECT IDENTIFIER, atportPtoPRemoteName DisplayString, atportPtoPRemoteAddress OCTET STRING, atportPtoPPortIndex INTEGER, atportPtoPStatus INTEGER } atportPtoPIndex OBJECT-TYPE SYNTAX INTEGER ACCESS not-accessible STATUS mandatory DESCRIPTION "A unique value for each AppleTalk point-to-point connection. Its value is between 1 and the total number of AppleTalk point-to-point connections. The value for each connection must remain constant at least from the re-initialization of the entity's network management system to the next Waldbusser & Frisa [Page 72] RFC 1742 AppleTalk MIB II January 1995 re-initialization." ::= { atportPtoPEntry 1 } atportPtoPProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "The protocol type used over the point-to-point connection." ::= { atportPtoPEntry 2 } atportPtoPRemoteName OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION "A text string containing the network node name of the entity at the other end of the point-to-point link. If the name is unknown or undefined, then this string is zero length." ::= { atportPtoPEntry 3 } atportPtoPRemoteAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "The network address of the entity at the other end of the point-to-point link in network byte order. The format of this address can be determined by examinating the atportType corresponding to this entry. If the address is unknown or undefined, then this string is zero length." ::= { atportPtoPEntry 4 } atportPtoPPortIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The AppleTalk port associated with this point-to-point connection. The interface identified by a particular value of this index is the same interface as identified by the same value of atportIndex." ::= { atportPtoPEntry 5 } Waldbusser & Frisa [Page 73] RFC 1742 AppleTalk MIB II January 1995 atportPtoPStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of this entry in the atportPtoPTable. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the atportPtoPTable. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive from agents tabular information corresponding to entries not currently in use. Proper interpretation of such entries requires examinationr of the relevant atportPtoPStatus object." ::= { atportPtoPEntry 6 } atportPtoPProtoOids OBJECT IDENTIFIER ::= { atportptop 2 } -- A list of values to be used for the atportPtoPProtocol -- variable. -- When new protocols are defined, their oids may be defined -- in separate MIB documents in different branches of the tree. pToPProtoOther OBJECT IDENTIFIER ::= { atportPtoPProtoOids 1 } pToPProtoAurp OBJECT IDENTIFIER ::= { atportPtoPProtoOids 2 } pToPProtoCaymanUdp OBJECT IDENTIFIER ::= { atportPtoPProtoOids 3 } pToPProtoAtkvmsDecnetIV OBJECT IDENTIFIER ::= { atportPtoPProtoOids 4 } pToPProtoLiaisonUdp OBJECT IDENTIFIER ::= { atportPtoPProtoOids 5 } pToPProtoIpx OBJECT IDENTIFIER ::= { atportPtoPProtoOids 6 } pToPProtoShivaIp OBJECT IDENTIFIER ::= { atportPtoPProtoOids 7 } Waldbusser & Frisa [Page 74] RFC 1742 AppleTalk MIB II January 1995 -- The Per Port Counters Group -- -- Implementation of this group is optional. perPortTable OBJECT-TYPE SYNTAX SEQUENCE OF PerPortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of per-port statistics for this entity." ::= { perPort 1 } perPortEntry OBJECT-TYPE SYNTAX PerPortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The statistics available for a particular port on this entity. As an example, an instance of the perPortAarpInProbes object might be named perPortAarpInProbes.2" INDEX { atportIndex } ::= { perPortTable 1 } PerPortEntry ::= SEQUENCE { perPortAarpInProbes Counter, perPortAarpOutProbes Counter, perPortAarpInReqs Counter, perPortAarpOutReqs Counter, perPortAarpInRsps Counter, perPortAarpOutRsps Counter, perPortDdpInReceives Counter, perPortDdpInLocalDatagrams Counter, perPortDdpNoProtocolHandlers Counter, perPortDdpTooShortErrors Counter, perPortDdpTooLongErrors Counter, perPortDdpChecksumErrors Counter, perPortDdpForwRequests Counter, perPortRtmpInDataPkts Counter, perPortRtmpOutDataPkts Counter, perPortRtmpInRequestPkts Counter, perPortRtmpRouteDeletes Counter, perPortZipInZipQueries Counter, perPortZipInZipReplies Counter, perPortZipInZipExtendedReplies Counter, perPortZipZoneConflictErrors Counter, perPortZipInErrors Counter, Waldbusser & Frisa [Page 75] RFC 1742 AppleTalk MIB II January 1995 perPortNbpInLookUpRequests Counter, perPortNbpInLookUpReplies Counter, perPortNbpInBroadcastRequests Counter, perPortNbpInForwardRequests Counter, perPortNbpOutLookUpReplies Counter, perPortNbpRegistrationFailures Counter, perPortNbpInErrors Counter, perPortEchoRequests Counter, perPortEchoReplies Counter } perPortAarpInProbes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AARP Probe packets received by this entity on this port." ::= { perPortEntry 1 } perPortAarpOutProbes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AARP Probe packets sent by this entity on this port." ::= { perPortEntry 2 } perPortAarpInReqs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AARP Request packets received by this entity on this port." ::= { perPortEntry 3 } perPortAarpOutReqs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AARP Request packets sent by this entity on this port." ::= { perPortEntry 4 } Waldbusser & Frisa [Page 76] RFC 1742 AppleTalk MIB II January 1995 perPortAarpInRsps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AARP Response packets received by this entity on this port." ::= { perPortEntry 5 } perPortAarpOutRsps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of AARP Response packets sent by this entity on this port." ::= { perPortEntry 6 } perPortDdpInReceives OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input datagrams received by DDP on this port, including those received in error." ::= { perPortEntry 7 } perPortDdpInLocalDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams on this port for which this entity was their final DDP destination." ::= { perPortEntry 8 } perPortDdpNoProtocolHandlers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of DDP datagrams addressed to this entity on this port that were addressed to an upper layer protocol for which no protocol handler existed." ::= { perPortEntry 9 } Waldbusser & Frisa [Page 77] RFC 1742 AppleTalk MIB II January 1995 perPortDdpTooShortErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams on this port dropped because the received data length was less than the data length specified in the DDP header or the received data length was less than the length of the expected DDP header." ::= { perPortEntry 10 } perPortDdpTooLongErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams on this port dropped because they exceeded the maximum DDP datagram size." ::= { perPortEntry 11 } perPortDdpChecksumErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input DDP datagrams on this port for which this DDP entity was their final destination, and which were dropped because of a checksum error." ::= { perPortEntry 12 } perPortDdpForwRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams on this port for which this entity was not their final DDP destination, as a result of which an attempt was made to find a route to forward them to that final destination." ::= { perPortEntry 13 } perPortRtmpInDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only Waldbusser & Frisa [Page 78] RFC 1742 AppleTalk MIB II January 1995 STATUS mandatory DESCRIPTION "A count of the number of good RTMP data packets received by this entity on this port." ::= { perPortEntry 14 } perPortRtmpOutDataPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of RTMP packets sent by this entity on this port." ::= { perPortEntry 15 } perPortRtmpInRequestPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of good RTMP Request packets received by this entity on this port." ::= { perPortEntry 16 } perPortRtmpRouteDeletes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of the number of times RTMP deletes a route on this port because it was aged out of the table." ::= { perPortEntry 17 } perPortZipInZipQueries OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP Queries received by this entity on this port." ::= { perPortEntry 18 } perPortZipInZipReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Waldbusser & Frisa [Page 79] RFC 1742 AppleTalk MIB II January 1995 "The number of ZIP Replies received by this entity on this port." ::= { perPortEntry 19 } perPortZipInZipExtendedReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP Extended Replies received by this entity on this port." ::= { perPortEntry 20 } perPortZipZoneConflictErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times a conflict has been detected on this port between this entity's zone information and another entity's zone information." ::= { perPortEntry 21 } perPortZipInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ZIP packets received by this entity on this port that were rejected for any error." ::= { perPortEntry 22 } perPortNbpInLookUpRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP LookUp Requests received on this port." ::= { perPortEntry 23 } perPortNbpInLookUpReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP LookUp Replies received on this Waldbusser & Frisa [Page 80] RFC 1742 AppleTalk MIB II January 1995 port." ::= { perPortEntry 24 } perPortNbpInBroadcastRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP Broadcast Requests received on this port." ::= { perPortEntry 25 } perPortNbpInForwardRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP Forward Requests received on this port." ::= { perPortEntry 26 } perPortNbpOutLookUpReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP LookUp Replies sent on this port." ::= { perPortEntry 27 } perPortNbpRegistrationFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this node experienced a failure in attempting to register an NBP entity on this port." ::= { perPortEntry 28 } perPortNbpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of NBP packets received by this entity on this port that were rejected for any error." ::= { perPortEntry 29 } Waldbusser & Frisa [Page 81] RFC 1742 AppleTalk MIB II January 1995 perPortEchoRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of AppleTalk Echo requests received on this port." ::= { perPortEntry 30 } perPortEchoReplies OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The count of AppleTalk Echo replies received on this port." ::= { perPortEntry 31 } END 6. Acknowledgments This document was produced by the IETF AppleTalk-IP Working Group. In addition, the contribution of the following individuals is also acknowledged: Greg Bruell, Wellfleet Phil Budne, Shiva Robert Jeckell, 3Com Greg Merrell, DEC Greg Minshall, Novell, Inc. Bob Morgan, Stanford University Brad Parker, FCR Marshall T. Rose, Dover Beach Consulting Wayne Tackabury, Cayman Jonathan Wenocur, Shiva Waldbusser & Frisa [Page 82] RFC 1742 AppleTalk MIB II January 1995 7. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988. [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989. [3] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [4] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] Rose, M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1158, Performance Systems International, May 1990. [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [10] Gursharan S., Andrews, R., and A. Oppenheimer, "Inside AppleTalk", Second Edition, Addison Wesley, 1990. Waldbusser & Frisa [Page 83] RFC 1742 AppleTalk MIB II January 1995 Security Considerations Security issues are not discussed in this memo. 9. Authors' Addresses Steven Waldbusser Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213 Phone: 412-268-6628 EMail: waldbusser@cmu.edu Karen Frisa FORE Systems, Inc. 174 Thorn Hill Road Warrendale, PA 15086-7535 Phone: 412-772-6541 EMail: kfrisa@fore.com Waldbusser & Frisa [Page 84] snmp-mibs-downloader-1.1/mibrfcs/rfc1747.txt0000644000000000000000000043767411402176071015611 0ustar Network Working Group J. Hilgeman, Chair Request for Comments: 1747 Apertus Technologies, Inc. Category: Standards Track S. Nix Metaplex, Inc. A. Bartky Sync Research, Inc. W. Clark, Editor cisco Systems, Inc. January 1995 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2 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. Abstract This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. This draft identifies managed objects for SNA Synchronous Data Link Control (SDLC) links only. Table of Contents 1. The SNMPv2 Network Management Framework ................. 2 1.1 Object Definitions .................................... 2 2. Overview ................................................ 2 2.1 Tables Defined in the SNADLC SDLC MIB ................. 3 2.2 Row Creation Mechanism ................................ 3 2.3 Relationship to the Interfaces Group .................. 4 3. Definitions ............................................. 7 3.1 Port Administrative Table ............................. 9 3.2 Port Operational Table ............................... 14 3.3 Port Statistics Table ................................ 20 3.4 Link Station Administrative Table .................... 26 3.5 Link Station Operational Table ....................... 35 3.6 Link Station Statistics Table ........................ 44 3.7 Trap Definitions ..................................... 56 3.8 Compliance Statements ................................ 57 Hilgeman, Nix, Bartky & Clark [Page 1] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 4. Acknowledgments ........................................ 65 5. References ............................................. 65 6. Glossary ............................................... 66 7. Security Considerations ................................ 67 8. Authors' Addresses ..................................... 67 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1441 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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 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. 2. Overview This memo identifies the proposed set of objects for configuring, monitoring, and controlling SDLC ports and link stations. Hilgeman, Nix, Bartky & Clark [Page 2] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 2.1. Tables Defined in the SNADLC SDLC MIB The SNADLC MIB is composed of two managed entities with three tables each. The two managed entities for SDLC are: o Ports: the physical connection, and o Link Stations: the logical connections on the Port. The three management tables are: o Adminstration: objects used for configuring and controlling the operation of a Port or Link Station, o Operational: objects that reflect the run-time state of the Port or Link Station, and o Statistics: objects that reflect the operating metrics of the Port or Link Station. Considering the above combinations, the following are the actual tables found in this MIB: 1) Port Administration Table, 2) Port Operation Table, 3) Port Statistics Table, 4) Link Station Administration Table, 5) Link Station Operation Table, 6) Link Station Statistics Table. All variables in this MIB relate to SDLC ports and link stations only. Any variable relating to higher-layer entities in SNA such as Physical Units (PU) and Logical Units (LU) are found in the SNA NAU MIB [4]. 2.2. Row Creation Mechanism Row creation mechanism for the sdlcLSAdminTable is based on the use of the RowStatus object. It follows the rules for the use in SNMPv1 context proposed in the memo "Row creation with SNMPv1" [5]. Before accepting the destroy value for an entry, an agent has to verify the operational state of the corresponding entry in the sdlcLSOperTable entry. Hilgeman, Nix, Bartky & Clark [Page 3] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 2.3. Relationship to the Interfaces Group This memo shall conform to the recommendations of [6]. The SDLC layer of each SDLC Port shall be modeled by a row in the ifTable with an ifType using the IANA assigned number for SDLC (17). Each SDLC port interface must comply with the following conformance groups in [6]: - ifGeneralGroup - ifStackGroup - ifPacketGroup An implementation may optionally comply with the ifTestGroup defined in that memo to execute vendor specific tests. An example of this would be to perform LPDA test functions. The SDLC port's relation with its physical, or lower-layer interface (i.e., RS-232, V.35, etc.) shall be modeled by a row in the ifStackTable with the ifStackHigherLayer pointing to the SDLC port ifTable instance and the ifStackLowerLayer pointing to the physical media-specific ifTable instance. The media-specific objects of these lower-layer interfaces will, of course, be described in their respective MIBs (i.e., [1]). The following table provides specific implementation guidelines for all the interface group objects listed in the conformance tables above. Object Use for an SDLC Port ifIndex Each SDLC port is represented by an ifEntry. All SDLC port tables shall be indexed by ifIndex. ifDescr Description of the SDLC port. ifType The IANA value reserved for SDLC - 17. ifMtu Refer to [6]. ifSpeed This object shall reflect the value of the corresponding object in the ifEntry of the associated lower-layer interface. ifPhysAddress A string denoting the physical location of the SDLC port within its node. This shall have unique significance within each implementing node. Hilgeman, Nix, Bartky & Clark [Page 4] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 ifAdminStatus This object shall reflect the value of the corresponding object in the ifEntry of the associated lower-layer interface. ifOperStatus This object shall reflect the value of the corresponding object in the ifEntry of the associated lower-layer interface. ifLastChange Refer to [6]. ifInOctets Refer to [6]. ifInUcastPkts This object shall count packets received from a specific SDLC poll address. Packets for the SDLC broadcast address of x'FF' are not counted. ifInDiscards Refer to [6]. ifInErrors Refer to [6]. Specific counters for these errors are kept in the sdlcPortStatsTable. ifInUnknownProtos This counter shall return zero for SDLC ports. ifOutOctets Refer to [6]. ifOutUcastPkts This object shall count packets transmitted to a specific SDLC poll address (not x'FF'). ifOutDiscards Refer to [6]. ifOutErrors Refer to [6]. Specific counters for these errors are kept in the sdlcPortStatsTable. ifName The textual name of the SDLC port or an octet string of zero length. ifInMulticastPkts The value is 0 (not applicable to the SDLC layer). ifInBroadcastPkts This object shall count packets received on this interface addressed to the SDLC broadcast address (x'FF'). Only point-to-point ports supporting a secondary switched station should return non-zero values. ifOutMulticastPkts The value is 0 (not applicable to the SDLC layer). ifOutBroadcastPkts This object shall count packets transmitted on this interface which were addressed to the SDLC broadcast Hilgeman, Nix, Bartky & Clark [Page 5] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 address (x'FF'). Only point-to-point ports supporting a primary switched station should return non-zero values. ifHC* Not part of the conformance group. ifLinkUpDownTrapEnable Refer to [6]. Default is disabled (2). ifHighSpeed Refer to [6]. ifPromiscuousMode Should return false if this interface receives only packets addressed to its SDLC poll address(es). However, in certain implementations, the lower-layer interface shall present all frames to the SDLC port regardless of the poll address. Such frames may be the result of a misconfigured peer or the secondary end of a multipoint connection. Such implementations should return true for this object. ifConnectorPresent Set to 'false'. ifStackHigherLayer For each SDLC port there will be an ifStackEntry with this object's value referring to the ifIndex of the SDLC port's ifEntry for the SDLC layer. ifStackLowerLayer For each SDLC port there will be an ifStackEntry with this object's value referring to the ifIndex of the physical layer interface's ifEntry for that SDLC port. ifStackStatus Refer to [6]. Hilgeman, Nix, Bartky & Clark [Page 6] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 3. Definitions SNA-SDLC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, TimeTicks FROM SNMPv2-SMI DisplayString, RowStatus, TimeInterval FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2, ifIndex, ifAdminStatus, ifOperStatus FROM RFC1213-MIB; snaDLC MODULE-IDENTITY LAST-UPDATED "9411150000Z" ORGANIZATION "IETF SNA DLC MIB Working Group" CONTACT-INFO " Wayne Clark Postal: cisco Systems, Inc. 3100 Smoketree Ct. Suite 1000 Raleigh, NC 27604 US Tel: +1 919 878 6958 E-Mail: wclark@cisco.com" DESCRIPTION "This is the MIB module for objects used to manage SDLC devices." ::= { mib-2 41 } -- -- The following data link controls are modelled in this MIB module: -- -- 1. SDLC -- sdlc OBJECT IDENTIFIER ::= { snaDLC 1 } Hilgeman, Nix, Bartky & Clark [Page 7] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 -- -- THE SDLC GROUP -- ============== -- -- The following resources are modelled in the SDLC group of this -- MIB module: -- -- 1. PORTS -- 2. LINK STATIONS sdlcPortGroup OBJECT IDENTIFIER ::= { sdlc 1 } -- Physical Ports sdlcLSGroup OBJECT IDENTIFIER ::= { sdlc 2 } -- Logical Link Stations -- -- THE SDLC PORT GROUP -- =================== -- -- The following classes of information is modelled for each SDLC port: -- -- 1. ADMINISTRATIVE ( read/write) -- 2. OPERATIONAL ( read-only) -- 3. STATISTICS ( read-only) -- Information not found in this group is found in tables described in -- the following RFCs: -- -- 1. RFC1213 - MIB-II -- -- TABLE INDEX -- ==================== ==================== -- a. ifTable ifIndex -- -- 2. RFC1659 - The RS232-like MIB -- -- TABLE INDEX -- ==================== ==================== -- a. rs232PortTable rs232PortIndex -- b. rs232SyncPortTable rs232SyncPortIndex -- c. rs232InSigTable rs232InSigPortIndex, -- rs232InSigName -- d. rs232OutSigTable rs232OutSigPortIndex, -- rs232OutSigName -- ** e. rs232AsyncPortTable rs232AsyncPortIndex -- -- ** rs232AsyncPortTable for ISO 3309.3 ( Start-Stop SDLC). Hilgeman, Nix, Bartky & Clark [Page 8] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 -- ************************************************************* -- * * -- * THE SDLC PORT ADMINISTRATIVE TABLE * -- * * -- ************************************************************* sdlcPortAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SdlcPortAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects that can be changed to manage an SDLC port. Changing one of these parameters may take effect in the operating port immediately or may wait until the interface is restarted depending on the details of the implementation. Most of the objects in this read-write table have corresponding read-only objects in the sdlcPortOperTable that return the current operating value. The operating values may be different from these configured values if a configured parameter was changed after the interface was started." ::= { sdlcPortGroup 1 } sdlcPortAdminEntry OBJECT-TYPE SYNTAX SdlcPortAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of configured values for an SDLC port." INDEX { ifIndex } ::= { sdlcPortAdminTable 1 } SdlcPortAdminEntry ::= SEQUENCE { sdlcPortAdminName DisplayString, sdlcPortAdminRole INTEGER, sdlcPortAdminType INTEGER, sdlcPortAdminTopology INTEGER, sdlcPortAdminISTATUS INTEGER, sdlcPortAdminACTIVTO TimeInterval, sdlcPortAdminPAUSE TimeInterval, sdlcPortAdminSERVLIM Integer32, Hilgeman, Nix, Bartky & Clark [Page 9] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcPortAdminSlowPollTimer TimeInterval } sdlcPortAdminName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "An octet string that defines the physical port to which this interface is assigned. It has implementation-specific significance. Its value shall be unique within the administered system. It must contain only ASCII printable characters. Should an implementation choose to accept a write operation for this object, it causes the logical port definition associated with the table instance to be moved to a different physical port. A write operation shall not take effect until the port is cycled inactive." ::= { sdlcPortAdminEntry 1 } sdlcPortAdminRole OBJECT-TYPE SYNTAX INTEGER { primary(1), secondary(2), negotiable(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object describes the role that the link station shall assume the next time a connection is established. Even though this is defined as a port object, it is a link station attribute in the sense that a role is per link station. However, it is not possible to vary link station roles on a particular port. For example, if an SDLC port is configured to primary, all link stations on that port must be primary." ::= { sdlcPortAdminEntry 2 } sdlcPortAdminType OBJECT-TYPE SYNTAX INTEGER { Hilgeman, Nix, Bartky & Clark [Page 10] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 leased(1), switched(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This parameter defines whether the SDLC port is to connect to a leased or switched line. A write operation to this administrative value shall not take effect until the SDLC port has been cycled inactive." DEFVAL { leased } ::= { sdlcPortAdminEntry 3 } sdlcPortAdminTopology OBJECT-TYPE SYNTAX INTEGER { pointToPoint(1), multipoint(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This parameter defines whether the SDLC port is capable of operating in either a point-to-point or multipoint topology. sdlcPortAdminTopology == multipoint implies the port can also operate in a point-to-point topology. sdlcPortAdminTopology == pointToPoint does not imply the port can operate in a multipoint topology. A write operation to this administrative value shall not take effect until the SDLC port has been cycled inactive." DEFVAL { pointToPoint } ::= { sdlcPortAdminEntry 4 } sdlcPortAdminISTATUS OBJECT-TYPE SYNTAX INTEGER { inactive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION Hilgeman, Nix, Bartky & Clark [Page 11] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 "This parameter controls the initial value of the administrative status, ifAdminStatus, of this SDLC port at port start-up. Depending on the implementation, a write operation to this administrative object may not take effect until the SDLC port has been cycled inactive." DEFVAL { active } ::= { sdlcPortAdminEntry 5 } sdlcPortAdminACTIVTO OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This parameter defines the period of time (in 1/100ths of a second) that the port will allow a switched line to remain inactive before disconnecting. A switched line is considered to be inactive if there are no I-Frames being transferred. A value of zero indicates no timeout. Depending on the implementation, a write operation to this administered value may not take effect until the port is cycled inactive. This object only has meaning for SDLC ports where sdlcPortAdminType == switched The object descriptor contains the name of an NCP configuration parameter, ACTIVTO. Please note that the value of this object represents 1/100ths of a second while the NCP ACTIVTO is represented in seconds." DEFVAL { 0 } ::= { sdlcPortAdminEntry 6 } sdlcPortAdminPAUSE OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the minimum elapsed time (in 1/100ths of a second) between any two traversals of the poll list for a primary SDLC port. Depending on the implementation, a write operation to this administered value may not take effect until the port is cycled inactive. Hilgeman, Nix, Bartky & Clark [Page 12] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 The object descriptor contains the name of an NCP configuration parameter, PAUSE. Please note that the value of this object represents 1/100ths of a second while the NCP PAUSE is represented in 1/10ths of a second. This object only has meaning for SDLC ports where sdlcPortAdminRole == primary " DEFVAL { 200 } ::= { sdlcPortAdminEntry 7 } sdlcPortAdminSERVLIM OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the number of times the active poll list will be traversed before polling a station on the slow poll list for a primary, multipoint SDLC port. Depending on the implementation, a write operation to this administered value may not take effect until the port is cycled inactive. This object only has meaning for SDLC ports where sdlcPortAdminRole == primary and sdlcPortAdminTopology == multipoint " DEFVAL { 20 } ::= { sdlcPortAdminEntry 8 } sdlcPortAdminSlowPollTimer OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object describes the elapsed time (in 1/100ths of a second) between polls for failed secondary link station addresses. Depending on the implementation, a write operation to this administered value may not take effect until the port is cycled inactive. This object only has meaning for SDLC ports where sdlcPortAdminRole == primary and Hilgeman, Nix, Bartky & Clark [Page 13] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcPortAdminTopology == multipoint " DEFVAL { 2000 } ::= { sdlcPortAdminEntry 9 } -- ************************************************************* -- * * -- * THE SDLC PORT OPERATIONAL TABLE * -- * * -- ************************************************************* sdlcPortOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SdlcPortOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains current SDLC port parameters. Many of these objects have corresponding objects inthe sdlcPortAdminTable." ::= { sdlcPortGroup 2 } sdlcPortOperEntry OBJECT-TYPE SYNTAX SdlcPortOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Currently set parameters for a specific SDLC port." INDEX { ifIndex } ::= { sdlcPortOperTable 1 } SdlcPortOperEntry ::= SEQUENCE { sdlcPortOperName DisplayString, sdlcPortOperRole INTEGER, sdlcPortOperType INTEGER, sdlcPortOperTopology INTEGER, sdlcPortOperISTATUS INTEGER, sdlcPortOperACTIVTO TimeInterval, sdlcPortOperPAUSE TimeInterval, sdlcPortOperSlowPollMethod INTEGER, sdlcPortOperSERVLIM Integer32, sdlcPortOperSlowPollTimer TimeInterval, sdlcPortOperLastModifyTime TimeTicks, sdlcPortOperLastFailTime TimeTicks, sdlcPortOperLastFailCause INTEGER } sdlcPortOperName OBJECT-TYPE Hilgeman, Nix, Bartky & Clark [Page 14] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "An octet string that describes the physical port to which this interface is currently attached. It has implementation-specific significance." ::= { sdlcPortOperEntry 1 } sdlcPortOperRole OBJECT-TYPE SYNTAX INTEGER { primary(1), secondary(2), undefined(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the role that the link station has assumed on this connection. Even though this is defined as a port object, it is a link station attribute in the sense that a role is per link station. However, it is not possible to vary link station roles on a particular port. For example, if an SDLC port is configured to primary, all link stations on that port must be primary. The value of sdlcPortOperRole is undefined(3) whenever the link station role has not yet been established by the mode setting command." ::= { sdlcPortOperEntry 2 } sdlcPortOperType OBJECT-TYPE SYNTAX INTEGER { leased(1), switched(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter defines whether the SDLC port is currently operating as though connected to a leased or switched line." Hilgeman, Nix, Bartky & Clark [Page 15] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 ::= { sdlcPortOperEntry 3 } sdlcPortOperTopology OBJECT-TYPE SYNTAX INTEGER { pointToPoint(1), multipoint(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter defines whether the SDLC port is currently operating in a point-to-point or multipoint topology." ::= { sdlcPortOperEntry 4 } sdlcPortOperISTATUS OBJECT-TYPE SYNTAX INTEGER { inactive(1), active(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter describes the initial value of the administrative status, ifAdminStatus, of this SDLC port at last port start-up." ::= { sdlcPortOperEntry 5 } sdlcPortOperACTIVTO OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter defines the period of time (in 100ths of a second) that the port will allow a switched line to remain inactive before disconnecting. A switched line is considered to be inactive if there are no I-Frames being transferred. The object descriptor contains the name of an NCP configuration parameter, ACTIVTO. Please note that the value of this object represents 1/100ths of a second while the NCP ACTIVTO is represented in seconds. Hilgeman, Nix, Bartky & Clark [Page 16] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 A value of zero indicates no timeout." ::= { sdlcPortOperEntry 6 } sdlcPortOperPAUSE OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the current minimum elapsed time (in 1/100ths of a second) between any two traversals of the poll list for a primary SDLC port. The object descriptor contains the name of an NCP configuration parameter, PAUSE. Please note that the value of this object represents 1/100ths of a second while the NCP PAUSE is represented in 1/10ths of a second. This object only has meaning for SDLC ports where sdlcPortAdminRole == primary " ::= { sdlcPortOperEntry 7 } sdlcPortOperSlowPollMethod OBJECT-TYPE SYNTAX INTEGER { servlim(1), pollpause(2), other(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object defines the exact method that is in effect for periodically polling failed secondary link station addresses. If sdlcPortOperSlowPollMethod == servlim, then sdlcPortOperSERVLIM defines the actual polling characteristics. If sdlcPortOperSlowPollMethod == pollpause, then sdlcPortOperSlowPollTimer defines the actual polling characteristics. If sdlcPortOperSlowPollMethod == other, then the polling characteristics are modeled in Hilgeman, Nix, Bartky & Clark [Page 17] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 vendor-specific objects. This object only has meaning for SDLC ports where sdlcPortOperRole == primary and sdlcPortOperTopology == multipoint " ::= { sdlcPortOperEntry 8 } sdlcPortOperSERVLIM OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the number of times the active poll list is currently being traversed before polling a station on the slow poll list for a primary, multipoint SDLC port. This object only has meaning for SDLC ports where sdlcPortOperRole == primary and sdlcPortOperTopology == multipoint " ::= { sdlcPortOperEntry 9 } sdlcPortOperSlowPollTimer OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the elapsed time (in 1/100ths of a second) between polls for failed secondary link station addresses. This object only has meaning for SDLC ports where sdlcPortOperRole == primary and sdlcPortOperTopology == multipoint " ::= { sdlcPortOperEntry 10 } sdlcPortOperLastModifyTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the value of sysUpTime Hilgeman, Nix, Bartky & Clark [Page 18] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 when this port definition was last modified. If the port has not been modified, then this value shall be zero." ::= { sdlcPortOperEntry 11 } sdlcPortOperLastFailTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the value of sysUpTime when this SDLC port last failed. If the port has not failed, then this value shall be zero." ::= { sdlcPortOperEntry 12 } sdlcPortOperLastFailCause OBJECT-TYPE SYNTAX INTEGER { undefined(1), physical(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This enumerated object describes the cause of the last failure of this SDLC port. If the port has not failed, then this object has a value of undefined(1)." DEFVAL { undefined } ::= { sdlcPortOperEntry 13 } Hilgeman, Nix, Bartky & Clark [Page 19] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 -- ************************************************************* -- * * -- * THE SDLC PORT STATISTICS TABLE * -- * * -- ************************************************************* sdlcPortStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SdlcPortStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table contains statistics for a specific SDLC port." ::= { sdlcPortGroup 3 } sdlcPortStatsEntry OBJECT-TYPE SYNTAX SdlcPortStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of statistics for an SDLC port." INDEX { ifIndex } ::= { sdlcPortStatsTable 1 } SdlcPortStatsEntry ::= SEQUENCE { sdlcPortStatsPhysicalFailures Counter32, sdlcPortStatsInvalidAddresses Counter32, sdlcPortStatsDwarfFrames Counter32, sdlcPortStatsPollsIn Counter32, sdlcPortStatsPollsOut Counter32, sdlcPortStatsPollRspsIn Counter32, sdlcPortStatsPollRspsOut Counter32, sdlcPortStatsLocalBusies Counter32, sdlcPortStatsRemoteBusies Counter32, sdlcPortStatsIFramesIn Counter32, sdlcPortStatsIFramesOut Counter32, sdlcPortStatsOctetsIn Counter32, sdlcPortStatsOctetsOut Counter32, sdlcPortStatsProtocolErrs Counter32, sdlcPortStatsActivityTOs Counter32, sdlcPortStatsRNRLIMITs Counter32, sdlcPortStatsRetriesExps Counter32, sdlcPortStatsRetransmitsIn Counter32, sdlcPortStatsRetransmitsOut Counter32 } sdlcPortStatsPhysicalFailures OBJECT-TYPE Hilgeman, Nix, Bartky & Clark [Page 20] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of times this port has failed due to its physical media since port startup. At port startup time, this object must be initialized to zero." ::= { sdlcPortStatsEntry 1 } sdlcPortStatsInvalidAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of frames received by this port with invalid link station addresses." ::= { sdlcPortStatsEntry 2 } sdlcPortStatsDwarfFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of frames received by this port which were delivered intact by the physical layer but were too short to be legal. Ignoring the frame check sequence (FCS), a frame is considered to be too short if it is less than 2 bytes for sdlcLSOperMODULO of eight, or if it is less than 3 bytes for sdlcLSOperMODULO of onetwentyeight." ::= { sdlcPortStatsEntry 3 } sdlcPortStatsPollsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of polls received by this port since the port was created." ::= { sdlcPortStatsEntry 4 } Hilgeman, Nix, Bartky & Clark [Page 21] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcPortStatsPollsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of polls sent by this port since the port was created." ::= { sdlcPortStatsEntry 5 } sdlcPortStatsPollRspsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of poll responses received by this port since the port was created." ::= { sdlcPortStatsEntry 6 } sdlcPortStatsPollRspsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of poll responses sent by this port since the port was created." ::= { sdlcPortStatsEntry 7 } sdlcPortStatsLocalBusies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of times that the local SDLC link stations on this port have entered a busy state (RNR). This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 8 } sdlcPortStatsRemoteBusies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Hilgeman, Nix, Bartky & Clark [Page 22] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 DESCRIPTION "This object reflects the total number of times that the adjacent (i.e., remote) SDLC link stations on this port have entered a busy state (RNR). This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 9 } sdlcPortStatsIFramesIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of I-Frames that have been received by SDLC link stations on this port. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 10 } sdlcPortStatsIFramesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of I-Frames that have been transmitted by SDLC link stations on this port. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 11 } sdlcPortStatsOctetsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total octets received from adjacent SDLC link stations on this port. This object covers the address, control, and information field of I-Frames only. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 12 } sdlcPortStatsOctetsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Hilgeman, Nix, Bartky & Clark [Page 23] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 "This object reflects the total octets transmitted to adjacent SDLC link stations on this port. This object covers the address, control, and information field of I-Frames only. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 13 } sdlcPortStatsProtocolErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of times that the SDLC link stations on this port have deactivated the link as a result of having received a protocol violation from the adjacent link station. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 14 } sdlcPortStatsActivityTOs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of times that the SDLC link stations on this port have deactivated the link as a result of no activity on the link. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 15 } sdlcPortStatsRNRLIMITs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of times that the SDLC link stations on this port have deactivated the link as a result of its RNRLIMIT timer expiring. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 16 } sdlcPortStatsRetriesExps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Hilgeman, Nix, Bartky & Clark [Page 24] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 STATUS current DESCRIPTION "This object reflects the total number of times that the SDLC link stations on this port have deactivated the link as a result of a retry sequence being exhausted. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 17 } sdlcPortStatsRetransmitsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of I-Frames retransmitted by remote link stations for all SDLC link stations on this port. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 18 } sdlcPortStatsRetransmitsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of I-Frames retransmitted by all local SDLC link stations on this port. This object is initialized to zero when the port is created." ::= { sdlcPortStatsEntry 19 } Hilgeman, Nix, Bartky & Clark [Page 25] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 -- -- THE SDLC LINK STATION GROUP -- =========================== -- -- The following classes of information is modelled for each SDLC link -- station: -- -- 1. ADMINISTRATIVE ( read-write) -- 2. OPERATIONAL ( read-only) -- 3. STATISTICS ( read-only) -- ************************************************************* -- * * -- * THE SDLC LINK STATION ADMINISTRATIVE TABLE * -- * * -- ************************************************************* sdlcLSAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SdlcLSAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects that can be changed to manage an SDLC link station. Changing one of these parameters may take effect in the operating link immediately or may wait until the link is restarted depending on the details of the implementation. The entries in sdlcLSAdminTable can be created either by an agent or a management station. The management station can create an entry in sdlcLSAdminTable by setting the appropriate value in sdlcLSAdminRowStatus. Most of the objects in this read-create table have corresponding read-only objects in the sdlcLSOperTable that reflect the current operating value. The operating values may be different from these configured values if changed by XID negotiation or if a configured parameter was changed after the link was started." ::= { sdlcLSGroup 1 } sdlcLSAdminEntry OBJECT-TYPE Hilgeman, Nix, Bartky & Clark [Page 26] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 SYNTAX SdlcLSAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of configured values for an SDLC link station." INDEX { ifIndex, sdlcLSAddress } ::= { sdlcLSAdminTable 1 } SdlcLSAdminEntry ::= SEQUENCE { sdlcLSAddress INTEGER, sdlcLSAdminName DisplayString, sdlcLSAdminState INTEGER, sdlcLSAdminISTATUS INTEGER, sdlcLSAdminMAXDATASend Integer32, sdlcLSAdminMAXDATARcv Integer32, sdlcLSAdminREPLYTO TimeInterval, sdlcLSAdminMAXIN INTEGER, sdlcLSAdminMAXOUT INTEGER, sdlcLSAdminMODULO INTEGER, sdlcLSAdminRETRIESm INTEGER, sdlcLSAdminRETRIESt TimeInterval, sdlcLSAdminRETRIESn Integer32, sdlcLSAdminRNRLIMIT TimeInterval, sdlcLSAdminDATMODE INTEGER, sdlcLSAdminGPoll INTEGER, sdlcLSAdminSimRim INTEGER, sdlcLSAdminXmitRcvCap INTEGER, sdlcLSAdminRowStatus RowStatus } sdlcLSAddress OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This value is the poll address of the secondary link station for this SDLC link. It uniquely identifies the SDLC link station within a single SDLC port." ::= { sdlcLSAdminEntry 1 } sdlcLSAdminName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS read-create STATUS current DESCRIPTION Hilgeman, Nix, Bartky & Clark [Page 27] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 "An octet string that defines the local name of the SDLC link station. This field may be sent in the XID3 control vector 0x0E, type 0xF7." ::= { sdlcLSAdminEntry 2 } sdlcLSAdminState OBJECT-TYPE SYNTAX INTEGER { inactive(1), active(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the desired state of the SDLC station. The managed system shall attempt to keep the operational state, sdlcLSOperState, consistent with this value." DEFVAL { active } ::= { sdlcLSAdminEntry 3 } sdlcLSAdminISTATUS OBJECT-TYPE SYNTAX INTEGER { inactive(1), active(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter controls the desired state, sdlcLSAdminState, of the SDLC link station at link station start-up." DEFVAL { active } ::= { sdlcLSAdminEntry 4 } sdlcLSAdminMAXDATASend OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the maximum PDU size that the local link station thinks it can send to the adjacent link station before having received any XID from the ALS. After the maximum PDU size that the ALS can receive is known (via XID exchange) that value is reflected in sdlcLSOperMAXDATASend and takes Hilgeman, Nix, Bartky & Clark [Page 28] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 precedence over this object. This value includes the Transmission Header (TH) and the Request Header (RH)." ::= { sdlcLSAdminEntry 5 } sdlcLSAdminMAXDATARcv OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the maximum PDU size that the local link station can receive from the adjacent link station. This value is sent in the XID to the ALS. This value includes the Transmission Header (TH) and the Request Header (RH)." ::= { sdlcLSAdminEntry 6 } sdlcLSAdminREPLYTO OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the reply timeout (in 1/100ths of a second) for an SDLC link station. If the link station does not receive a response to a poll or message before the specified time expires then the appropriate error recovery shall be initiated. The object descriptor contains the name of an NCP configuration parameter, REPLYTO. Please note that the value of this object represents 1/100ths of a second while the NCP REPLYTO is represented in 1/10ths of a second. Depending on the implementation, a write operation to this administered value may not change the operational value, sdlcLSOperREPLYTO, until the link station is cycled inactive. This object only has meaning for SDLC ports where sdlcPortAdminRole == primary " DEFVAL { 100 } ::= { sdlcLSAdminEntry 7 } Hilgeman, Nix, Bartky & Clark [Page 29] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSAdminMAXIN OBJECT-TYPE SYNTAX INTEGER (1..127) MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the maximum number of unacknowledged I-frames which an SDLC link station may receive. This should range from 1 to (sdlcLSAdminMODULO - 1). This value is sent in the XID to the ALS. A write operation to this administered value will not change the operational value, sdlcLSOperMAXIN, until the link station is cycled inactive." DEFVAL { 7 } ::= { sdlcLSAdminEntry 8 } sdlcLSAdminMAXOUT OBJECT-TYPE SYNTAX INTEGER (1..127) MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the maximum number of consecutive unacknowledged I-frames which an SDLC link station shall send without an acknowledgement. This shall range from 1 to (sdlcLSAdminMODULO - 1). For link stations on switched SDLC lines, certain implementions may choose to override this administered value with the value received in the XID exchange. Depending on the implementation, a write operation to this administered value may not change the operational value, sdlcLSOperMAXOUT, until the link station is cycled inactive. An implementation can support only modulo 8, only modulo 128, or both." DEFVAL { 1 } ::= { sdlcLSAdminEntry 9 } sdlcLSAdminMODULO OBJECT-TYPE SYNTAX INTEGER { Hilgeman, Nix, Bartky & Clark [Page 30] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 eight(8), onetwentyeight(128) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the modulus for an SDLC link station. This modulus determines the size of the rotating acknowledgement window used the SDLC link station pair. A write operation to this administered value will not change the operational value, sdlcLSOperMODULO, until the link station is cycled inactive. An implementation can support only modulo 8, only modulo 128, or both." DEFVAL { eight } ::= { sdlcLSAdminEntry 10 } sdlcLSAdminRETRIESm OBJECT-TYPE SYNTAX INTEGER (0..128) MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls number of retries in a retry sequence for the local SDLC link station. A retry sequence is a series of retransmitted frames ( data or control) for which no positive acknowledgement is received. The number of times that the retry sequence is to be repeated is controlled by the object: sdlcLSAdminRETRIESn. The interval between retry sequences is controlled by the object: sdlcLSAdminRETRIESt. A value of zero indicates no retries. If the value of sdlcLSAdminRETRIESm is zero, then the values of sdlcLSAdminRETRIESt and sdlcLSAdminRETRIESn should also be zero. Depending on the implementation, a write operation to this administered value may not change the operational value, sdlcLSOperRETRIESm, until the link station is cycled inactive." Hilgeman, Nix, Bartky & Clark [Page 31] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 DEFVAL { 15 } ::= { sdlcLSAdminEntry 11 } sdlcLSAdminRETRIESt OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the interval (in 1/100ths of a second) between retry sequences for the local SDLC link station if multiple retry sequences are specified . A retry sequence is a series of retransmitted frames ( data or control) for which no positive acknowledgement is received. The number of repeated retries sequences is controlled by the object: sdlcLSAdminRETRIESn. The retries per sequence is controlled by the object: sdlcLSAdminRETRIESm. The object descriptor contains the name of an NCP configuration parameter, RETRIESt. Please note that the value of this object represents 1/100ths of a second while the NCP RETRIESt is represented in seconds. Depending on the implementation, a write operation to this administered value may not change the operational value, sdlcLSOperRETRIESt, until the link station is cycled inactive." DEFVAL { 0 } ::= { sdlcLSAdminEntry 12 } sdlcLSAdminRETRIESn OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the number of times that a retry sequence is repeated for the local SDLC link station. A retry sequence is a series of retransmitted frames ( data or control) for which no positive acknowledgement is received. The interval between retry sequences is controlled by the object: sdlcLSAdminRETRIESn. Hilgeman, Nix, Bartky & Clark [Page 32] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 The retries per sequence is controlled by the object: sdlcLSAdminRETRIESm. Depending on the implementation, a write operation to this administered value may not change the operational value, sdlcLSOperRETRIESn, until the link station is cycled inactive." DEFVAL { 0 } ::= { sdlcLSAdminEntry 13 } sdlcLSAdminRNRLIMIT OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the length of time (in 1/100ths of a second) that an SDLC link station will allow its adjacent link station to remain in a busy (RNR) state before declaring it inoperative. A value of sdlcLSAdminRNRLIMIT == 0 means there is no limit. The object descriptor contains the name of an NCP configuration parameter, RNRLIMIT. Please note that the value of this object represents 1/100ths of a second while the NCP RNRLIMIT is represented in minutes. Depending on the implementation, a write operation to this administered value may not change the operational value, sdlcLSOperRNRLIMIT, until the link station is cycled inactive." DEFVAL { 18000 } ::= { sdlcLSAdminEntry 14 } sdlcLSAdminDATMODE OBJECT-TYPE SYNTAX INTEGER { half(1), full(2) } MAX-ACCESS read-create STATUS current DESCRIPTION Hilgeman, Nix, Bartky & Clark [Page 33] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 "This object controls whether communications mode with the adjacent link station is two-way-alternate (half) or two-way-simultaneous (full). A write operation to this administered value will not change the operational value, sdlcLSOperDATMODE, until the link station is cycled inactive." DEFVAL { half } ::= { sdlcLSAdminEntry 15 } sdlcLSAdminGPoll OBJECT-TYPE SYNTAX INTEGER (0..254) MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes the group poll address for this link station instance. If group poll is not in effect for this link station instance, the value for sdlcLSAdminGPoll should be zero. Depending on the implementation, a write operation to this administered value may not change the operational value, sdlcLSOperGPoll, until the link station is cycled inactive." ::= { sdlcLSAdminEntry 16 } sdlcLSAdminSimRim OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the support for transmission and receipt of SIM and RIM control frames for this link station. The value of this object controls the setting of the transmit-receive capability sent in the XID field." DEFVAL { no } ::= { sdlcLSAdminEntry 17 } sdlcLSAdminXmitRcvCap OBJECT-TYPE Hilgeman, Nix, Bartky & Clark [Page 34] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 SYNTAX INTEGER { twa(1), tws(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the transmit-receive capabilities for this SDLC link station. The value of this object establishes the value of the transmit-receive capability indicator sent in the XID image to the adjacent link station." DEFVAL { twa } ::= { sdlcLSAdminEntry 18 } sdlcLSAdminRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by a management station to create or delete the row entry in sdlcLSAdminTable following the RowStatus textual convention. Upon successful creation of the row, an agent automatically creates a corresponding entry in the sdlcLSOperTable with sdlcLSOperState equal to 'discontacted (1)'." ::= { sdlcLSAdminEntry 19 } -- ************************************************************* -- * * -- * THE SDLC LINK STATION OPERATIONAL TABLE * -- * * -- ************************************************************* sdlcLSOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SdlcLSOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains current SDLC link parameters. Many of these objects have corresponding objects in the sdlcLSAdminTable." ::= { sdlcLSGroup 2 } Hilgeman, Nix, Bartky & Clark [Page 35] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSOperEntry OBJECT-TYPE SYNTAX SdlcLSOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of status and control values for an SDLC link station." INDEX { ifIndex, sdlcLSAddress } ::= { sdlcLSOperTable 1 } SdlcLSOperEntry ::= SEQUENCE { sdlcLSOperName DisplayString, sdlcLSOperRole INTEGER, sdlcLSOperState INTEGER, sdlcLSOperMAXDATASend Integer32, sdlcLSOperREPLYTO TimeInterval, sdlcLSOperMAXIN INTEGER, sdlcLSOperMAXOUT INTEGER, sdlcLSOperMODULO INTEGER, sdlcLSOperRETRIESm INTEGER, sdlcLSOperRETRIESt TimeInterval, sdlcLSOperRETRIESn INTEGER, sdlcLSOperRNRLIMIT TimeInterval, sdlcLSOperDATMODE INTEGER, sdlcLSOperLastModifyTime TimeTicks, sdlcLSOperLastFailTime TimeTicks, sdlcLSOperLastFailCause INTEGER, sdlcLSOperLastFailCtrlIn OCTET STRING, sdlcLSOperLastFailCtrlOut OCTET STRING, sdlcLSOperLastFailFRMRInfo OCTET STRING, sdlcLSOperLastFailREPLYTOs Counter32, sdlcLSOperEcho INTEGER, sdlcLSOperGPoll INTEGER, sdlcLSOperSimRim INTEGER, sdlcLSOperXmitRcvCap INTEGER } sdlcLSOperName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "An octet string that defines the name of the remote SDLC link station. This field is received in the XID3 control vector 0x0E, type 0xF7." ::= { sdlcLSOperEntry 1 } Hilgeman, Nix, Bartky & Clark [Page 36] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSOperRole OBJECT-TYPE SYNTAX INTEGER { primary(1), secondary(2), undefined(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the current role that the link station is assuming. The value of sdlcLSOperRole is undefined(3) whenever the link station role has not yet been established by the mode setting command." ::= { sdlcLSOperEntry 2 } sdlcLSOperState OBJECT-TYPE SYNTAX INTEGER { discontacted(1), contactPending(2), contacted(3), discontactPending(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the operational state of the SDLC link station. The managed system shall attempt to keep this value consistent with the administered state, sdlcLSAdminState" ::= { sdlcLSOperEntry 3 } sdlcLSOperMAXDATASend OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the actual maximum PDU size that the local link station can send to the adjacent link station. This object is established from the value received in the XID from the adjacent link station. If no XID is received, then this value is implementation dependent (for instance, it could be the value of sdlcLSAdminMAXDATASend). Hilgeman, Nix, Bartky & Clark [Page 37] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 This value includes the Transmission Header (TH) and the Request Header (RH)." ::= { sdlcLSOperEntry 4 } sdlcLSOperREPLYTO OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the current reply timeout (in 1/100ths of a second) for an SDLC link station. If the link station does not receive a response to a poll or message before the specified time expires then the appropriate error recovery shall be initiated. The object descriptor contains the name of an NCP configuration parameter, REPLYTO. Please note that the value of this object represents 1/100ths of a second while the NCP REPLYTO is represented in 1/10ths of a second. This object only has meaning for SDLC ports where sdlcPortOperRole == primary " ::= { sdlcLSOperEntry 5 } sdlcLSOperMAXIN OBJECT-TYPE SYNTAX INTEGER (1..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the current maximum number of unacknowledged I-frames which an SDLC link station may receive. This shall range from 1 to (sdlcLSOperMODULO - 1)." ::= { sdlcLSOperEntry 6 } sdlcLSOperMAXOUT OBJECT-TYPE SYNTAX INTEGER (1..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This object controls the maximum number of consecutive unacknowledged I-frames which an SDLC link station shall send without an acknowledgement. This shall range from 1 to (sdlcLSAdminMODULO - 1). Hilgeman, Nix, Bartky & Clark [Page 38] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 This value may controlled by the administered MAXOUT, sdlcLSAdminMAXOUT, or by the MAXIN value received during the XID exchange." ::= { sdlcLSOperEntry 7 } sdlcLSOperMODULO OBJECT-TYPE SYNTAX INTEGER { eight(8), onetwentyeight(128) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the current modulus for an SDLC link station. This modulus determines the size of rotating acknowledgement window used by the SDLC link station pair." DEFVAL { eight } ::= { sdlcLSOperEntry 8 } sdlcLSOperRETRIESm OBJECT-TYPE SYNTAX INTEGER (0..128) MAX-ACCESS read-only STATUS current DESCRIPTION "This object controls number of retries in a retry sequence for an SDLC link station. A retry sequence is a series of retransmitted frames ( data or control) for which no positive acknowledgement is received. The current number of times that the retry sequence is to be repeated is reflected by the object: sdlcLSOperRETRIESn. The current interval between retry sequences is reflected by the object: sdlcLSOperRETRIESt." ::= { sdlcLSOperEntry 9 } sdlcLSOperRETRIESt OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the current interval (in 1/100ths of a second) between retry sequences for an SDLC link station if multiple retry sequences are specified. A retry sequence is a Hilgeman, Nix, Bartky & Clark [Page 39] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 series of retransmitted frames ( data or control) for which no positive acknowledgement is received. The object descriptor contains the name of an NCP configuration parameter, RETRIESt. Please note that the value of this object represents 1/100ths of a second while the NCP RETRIESt is represented in seconds. The current number of repeated retries sequences is reflected by the object: sdlcLSOperRETRIESn. The current retries per sequence is reflected by the object: sdlcLSOperRETRIESm." ::= { sdlcLSOperEntry 10 } sdlcLSOperRETRIESn OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the current number of times that a retry sequence is repeated for an SDLC link station. A retry sequence is a series of retransmitted frames ( data or control) for which no positive acknowledgement is received. The current interval between retry sequences is reflected by the object: sdlcLSOperRETRIESn. The current retries per sequence is reflected by the object: sdlcLSOperRETRIESm." ::= { sdlcLSOperEntry 11 } sdlcLSOperRNRLIMIT OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the current length of time (in 1/100ths of a second) that an SDLC link station will allow its adjacent link station to remain in a busy (RNR) state before declaring it inoperative. The object descriptor contains the name of an NCP configuration parameter, RNRLIMIT. Please Hilgeman, Nix, Bartky & Clark [Page 40] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 note that the value of this object represents 1/100ths of a second while the NCP RNRLIMIT is represented in minutes. A value of sdlcLSOperRNRLIMIT == 0 means there is no limit." ::= { sdlcLSOperEntry 12 } sdlcLSOperDATMODE OBJECT-TYPE SYNTAX INTEGER { half(1), full(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects whether the current communications mode with the adjacent link station is two-way-alternate (half) or two-way-simultaneous (full)." ::= { sdlcLSOperEntry 13 } sdlcLSOperLastModifyTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the value of sysUpTime when this link station definition was last modified. If the link station has not been modified, then this value shall be zero." ::= { sdlcLSOperEntry 14 } sdlcLSOperLastFailTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the value of sysUpTime when this SDLC link station last failed. If the link station has not failed, then this value shall be zero." ::= { sdlcLSOperEntry 15 } sdlcLSOperLastFailCause OBJECT-TYPE SYNTAX INTEGER { Hilgeman, Nix, Bartky & Clark [Page 41] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 undefined(1), rxFRMR(2), txFRMR(3), noResponse(4), protocolErr(5), noActivity(6), rnrLimit(7), retriesExpired(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "This enumerated object reflects the cause of the last failure of this SDLC link station. If the link station has not failed, then this object will have a value of undefined(1)." DEFVAL { undefined } ::= { sdlcLSOperEntry 16 } sdlcLSOperLastFailCtrlIn OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the last control octet or octets (depending on modulus) received by this SDLC link station at the time of the last failure. If the link station has not failed, then this value has no meaning." ::= { sdlcLSOperEntry 17 } sdlcLSOperLastFailCtrlOut OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the last control octet or octets (depending on modulus) sent by this SDLC link station at the time of the last failure. If the link station has not failed, then this value has no meaning." ::= { sdlcLSOperEntry 18 } sdlcLSOperLastFailFRMRInfo OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION Hilgeman, Nix, Bartky & Clark [Page 42] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 "This object reflects the information field of the FRMR frame if the last failure for this SDLC link station was as a result of an invalid frame. Otherwise, this field has no meaning." ::= { sdlcLSOperEntry 19 } sdlcLSOperLastFailREPLYTOs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the number of times that the REPLYTO timer had expired for an SDLC link station at the time of the last failure. If the link station has not failed, then this value has no meaning." ::= { sdlcLSOperEntry 20 } sdlcLSOperEcho OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether the echo bit is in effect for this particular link station." DEFVAL { no } ::= { sdlcLSOperEntry 21 } sdlcLSOperGPoll OBJECT-TYPE SYNTAX INTEGER (0..254) MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the group poll address in effect for this link station instance." DEFVAL { 0 } ::= { sdlcLSOperEntry 22 } sdlcLSOperSimRim OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } Hilgeman, Nix, Bartky & Clark [Page 43] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the support for transmission and receipt of SIM and RIM control frames for the adjacent link station. The value of this object is set from the XID field received from the adjacent link station." DEFVAL { no } ::= { sdlcLSOperEntry 23 } sdlcLSOperXmitRcvCap OBJECT-TYPE SYNTAX INTEGER { twa(1), tws(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the transmit-receive capabilities for the adjacent SDLC link station. The value of this object is the value of the transmit-receive capability indicator received in the XID image from the adjacent link station." DEFVAL { twa } ::= { sdlcLSOperEntry 24 } -- ************************************************************* -- * * -- * THE SDLC LINK STATION STATISTICS TABLE * -- * * -- ************************************************************* sdlcLSStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SdlcLSStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table contains statistics for a specific SDLC link station." ::= { sdlcLSGroup 3 } sdlcLSStatsEntry OBJECT-TYPE SYNTAX SdlcLSStatsEntry MAX-ACCESS not-accessible Hilgeman, Nix, Bartky & Clark [Page 44] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 STATUS current DESCRIPTION "A list of statistics for an SDLC link station." INDEX { ifIndex, sdlcLSAddress } ::= { sdlcLSStatsTable 1 } SdlcLSStatsEntry ::= SEQUENCE { sdlcLSStatsBLUsIn Counter32, sdlcLSStatsBLUsOut Counter32, sdlcLSStatsOctetsIn Counter32, sdlcLSStatsOctetsOut Counter32, sdlcLSStatsPollsIn Counter32, sdlcLSStatsPollsOut Counter32, sdlcLSStatsPollRspsIn Counter32, sdlcLSStatsPollRspsOut Counter32, sdlcLSStatsLocalBusies Counter32, sdlcLSStatsRemoteBusies Counter32, sdlcLSStatsIFramesIn Counter32, sdlcLSStatsIFramesOut Counter32, sdlcLSStatsUIFramesIn Counter32, sdlcLSStatsUIFramesOut Counter32, sdlcLSStatsXIDsIn Counter32, sdlcLSStatsXIDsOut Counter32, sdlcLSStatsTESTsIn Counter32, sdlcLSStatsTESTsOut Counter32, sdlcLSStatsREJsIn Counter32, sdlcLSStatsREJsOut Counter32, sdlcLSStatsFRMRsIn Counter32, sdlcLSStatsFRMRsOut Counter32, sdlcLSStatsSIMsIn Counter32, sdlcLSStatsSIMsOut Counter32, sdlcLSStatsRIMsIn Counter32, sdlcLSStatsRIMsOut Counter32, sdlcLSStatsDISCIn Counter32, sdlcLSStatsDISCOut Counter32, sdlcLSStatsUAIn Counter32, sdlcLSStatsUAOut Counter32, sdlcLSStatsDMIn Counter32, sdlcLSStatsDMOut Counter32, sdlcLSStatsSNRMIn Counter32, sdlcLSStatsSNRMOut Counter32, sdlcLSStatsProtocolErrs Counter32, sdlcLSStatsActivityTOs Counter32, sdlcLSStatsRNRLIMITs Counter32, sdlcLSStatsRetriesExps Counter32, sdlcLSStatsRetransmitsIn Counter32, sdlcLSStatsRetransmitsOut Counter32 Hilgeman, Nix, Bartky & Clark [Page 45] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 } sdlcLSStatsBLUsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total basic link units (BLUs; frames) received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 1 } sdlcLSStatsBLUsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total basic link units (BLUs; frames), transmitted to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 2 } sdlcLSStatsOctetsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total octets received from an adjacent SDLC link station since link station startup. This object covers the address, control, and information field of I-Frames only. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 3 } sdlcLSStatsOctetsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total octets transmitted to an adjacent SDLC link station since link station startup. This object covers the address, control, and information field of Hilgeman, Nix, Bartky & Clark [Page 46] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 I-Frames only. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 4 } sdlcLSStatsPollsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total polls received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 5 } sdlcLSStatsPollsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total polls sent to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 6 } sdlcLSStatsPollRspsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of poll responses sent to the adjacent SDLC link station since link station startup. This value includes I-frames that are sent in response to a poll. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 7 } sdlcLSStatsPollRspsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of poll responses received from the adjacent SDLC link Hilgeman, Nix, Bartky & Clark [Page 47] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 station since station startup. This value includes I-frames that are received in response to a poll. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 8 } sdlcLSStatsLocalBusies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of times that the local SDLC link station has entered a busy state (RNR) since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 9 } sdlcLSStatsRemoteBusies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of times that an adjacent ( remote) SDLC link station has entered a busy state (RNR) since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 10 } sdlcLSStatsIFramesIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total I-frames received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 11 } sdlcLSStatsIFramesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Hilgeman, Nix, Bartky & Clark [Page 48] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 DESCRIPTION "This object reflects the total I-frames transmitted to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 12 } sdlcLSStatsUIFramesIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total UI-frames received from an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 13 } sdlcLSStatsUIFramesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total UI-frames transmitted to an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 14 } sdlcLSStatsXIDsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total XID frames received from an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 15 } sdlcLSStatsXIDsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total XID frames transmitted to an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 16 } Hilgeman, Nix, Bartky & Clark [Page 49] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSStatsTESTsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total TEST frames, commands or responses, received from an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 17 } sdlcLSStatsTESTsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total TEST frames, commands or responses, transmitted to an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 18 } sdlcLSStatsREJsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total REJ frames received from an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 19 } sdlcLSStatsREJsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total REJ frames transmitted to an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 20 } sdlcLSStatsFRMRsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total frame reject Hilgeman, Nix, Bartky & Clark [Page 50] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 (FRMR) frames received from an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 21 } sdlcLSStatsFRMRsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total frame reject (FRMR) frames transmitted to an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 22 } sdlcLSStatsSIMsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total set initialization mode (SIM) frames received from an adjacent SDLC link station since link station startup." ::= { sdlcLSStatsEntry 23 } sdlcLSStatsSIMsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total set initialization mode (SIM) frames transmitted to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 24 } sdlcLSStatsRIMsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total request initialization mode (RIM) frames received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 25 } Hilgeman, Nix, Bartky & Clark [Page 51] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSStatsRIMsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total request initialization mode (RIM) frames transmitted to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 26 } sdlcLSStatsDISCIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of disconnect (DISC) requests received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 27 } sdlcLSStatsDISCOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of disconnect (DISC) requests transmited to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 28 } sdlcLSStatsUAIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of unnumbered acknowledgements (UA) requests received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 29 } Hilgeman, Nix, Bartky & Clark [Page 52] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSStatsUAOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of unnumbered acknowledgements (UA) requests transmited to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 30 } sdlcLSStatsDMIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of disconnect mode (DM) requests received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 31 } sdlcLSStatsDMOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of disconnect mode (DM) requests transmited to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 32 } sdlcLSStatsSNRMIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of set normal response mode (SNRM/SNRME) requests received from an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." Hilgeman, Nix, Bartky & Clark [Page 53] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 ::= { sdlcLSStatsEntry 33 } sdlcLSStatsSNRMOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of set normal response mode (SNRM/SNRME) requests transmited to an adjacent SDLC link station since link station startup. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 34 } sdlcLSStatsProtocolErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total occurrences, since link station startup, where this SDLC link station has inactivated the link as a result of receiving a frame from its adjacent link station which was in violation of the protocol. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 35 } sdlcLSStatsActivityTOs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total occurrences, since startup, where this SDLC link station has inactivated the link as a result of no activity on the link. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 36 } sdlcLSStatsRNRLIMITs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total occurrences, since startup, where this SDLC link station has Hilgeman, Nix, Bartky & Clark [Page 54] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 inactivated the link as a result of its RNRLIMIT timer expiring. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 37 } sdlcLSStatsRetriesExps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total occurrences, since startup, where this SDLC link station has inactivated the link as a result of a retry sequence being exhausted. At link station startup time, this object must be initialized to zero." ::= { sdlcLSStatsEntry 38 } sdlcLSStatsRetransmitsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of information frames retransmitted by the remote link station because the N(s) received from that link station indicated that one or more information frames sent by that station were lost. This event causes the first missing information frame of a window and all subsequent information frames to be retransmitted. At link station startup time, this object must be initialized to zero. Management: If the value of sdlcLSStatsRetransmitsIn grows over time, then the quality of the serial line is in question. You might want to look at decreasing the value for sdlcLSAdminMAXDATASend to compensate for the lower quality line." ::= { sdlcLSStatsEntry 39 } sdlcLSStatsRetransmitsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Hilgeman, Nix, Bartky & Clark [Page 55] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 DESCRIPTION "This object reflects the total number of information frames retransmitted to a remote link station because the N(r) received from that link station indicated that one or more information frames sent to that station were lost. This event causes the first missing information frame of a window and all subsequent information frames to be retransmitted. At link station startup time, this object must be initialized to zero. Management: If the value of sdlcLSStatsRetransmitsOut grows over time, then the quality of the serial line is in question. You might want to look at decreasing the value for sdlcLSAdminMAXDATASend to compensate for the lower quality line." ::= { sdlcLSStatsEntry 40 } -- -- TRAP DEFINITIONS -- -- -- Notifications -- sdlcTraps OBJECT IDENTIFIER ::= { sdlc 3 } sdlcPortStatusChange NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus, sdlcPortOperLastFailTime, sdlcPortOperLastFailCause } STATUS current DESCRIPTION "This trap indicates that the state of an SDLC port has transitioned to active or inactive." ::= { sdlcTraps 1 } sdlcLSStatusChange NOTIFICATION-TYPE OBJECTS { ifIndex, sdlcLSAddress, sdlcLSOperState, sdlcLSAdminState, Hilgeman, Nix, Bartky & Clark [Page 56] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSOperLastFailTime, sdlcLSOperLastFailCause, sdlcLSOperLastFailFRMRInfo, sdlcLSOperLastFailCtrlIn, sdlcLSOperLastFailCtrlOut, sdlcLSOperLastFailREPLYTOs } STATUS current DESCRIPTION "This trap indicates that the state of an SDLC link station has transitioned to contacted or discontacted." ::= { sdlcTraps 2 } -- -- Conformance Information -- sdlcConformance OBJECT IDENTIFIER ::= { sdlc 4 } sdlcCompliances OBJECT IDENTIFIER ::= { sdlcConformance 1 } sdlcGroups OBJECT IDENTIFIER ::= { sdlcConformance 2 } -- -- Compliance Statements -- sdlcCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The core compliance statement for all SDLC nodes." MODULE MANDATORY-GROUPS { sdlcCorePortAdminGroup, sdlcCorePortOperGroup, sdlcCorePortStatsGroup, sdlcCoreLSAdminGroup, sdlcCoreLSOperGroup, sdlcCoreLSStatsGroup } OBJECT sdlcPortAdminName MIN-ACCESS read-only DESCRIPTION "Write access is not required." Hilgeman, Nix, Bartky & Clark [Page 57] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 OBJECT sdlcPortAdminRole MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcPortAdminType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcPortAdminTopology MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcPortAdminISTATUS MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminISTATUS MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminMAXDATASend MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminMAXDATARcv MIN-ACCESS read-only DESCRIPTION Hilgeman, Nix, Bartky & Clark [Page 58] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 "Write access is not required." OBJECT sdlcLSAdminMAXIN MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminMAXOUT MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminMODULO MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminRETRIESm MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminRETRIESt MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminRETRIESn MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminRNRLIMIT MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminDATMODE MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminGPoll MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminSimRim Hilgeman, Nix, Bartky & Clark [Page 59] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { sdlcCompliances 1 } sdlcPrimaryCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for all nodes that are performing the role of a Primary link station." MODULE MANDATORY-GROUPS { sdlcPrimaryGroup } OBJECT sdlcPortAdminPAUSE MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcLSAdminREPLYTO MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { sdlcCompliances 2 } sdlcPrimaryMultipointCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for all nodes that are performing the role of a primary link station on a multipoint line." MODULE MANDATORY-GROUPS { sdlcPrimaryMultipointGroup } OBJECT sdlcPortAdminSERVLIM MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sdlcPortAdminSlowPollTimer MIN-ACCESS read-only Hilgeman, Nix, Bartky & Clark [Page 60] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 DESCRIPTION "Write access is not required." ::= { sdlcCompliances 3 } -- -- Core Conformance Groups for All Link Stations -- sdlcCoreGroups OBJECT IDENTIFIER ::= { sdlcGroups 1 } sdlcCorePortAdminGroup OBJECT-GROUP OBJECTS { sdlcPortAdminName, sdlcPortAdminRole, sdlcPortAdminType, sdlcPortAdminTopology, sdlcPortAdminISTATUS } STATUS current DESCRIPTION "The sdlcCorePortAdminGroup defines objects which are common to the PortAdmin group of all compliant link stations." ::= { sdlcCoreGroups 1 } sdlcCorePortOperGroup OBJECT-GROUP OBJECTS { sdlcPortOperName, sdlcPortOperRole, sdlcPortOperType, sdlcPortOperTopology, sdlcPortOperISTATUS, sdlcPortOperACTIVTO, sdlcPortOperLastFailTime, sdlcPortOperLastFailCause } STATUS current DESCRIPTION "The sdlcCorePortOperGroup defines objects which are common to the PortOper group of all compliant link stations." ::= { sdlcCoreGroups 2 } sdlcCorePortStatsGroup OBJECT-GROUP OBJECTS Hilgeman, Nix, Bartky & Clark [Page 61] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 { sdlcPortStatsPhysicalFailures, sdlcPortStatsInvalidAddresses, sdlcPortStatsDwarfFrames } STATUS current DESCRIPTION "The sdlcCorePortStatsGroup defines objects which are common to the PortStats group of all compliant link stations." ::= { sdlcCoreGroups 3 } sdlcCoreLSAdminGroup OBJECT-GROUP OBJECTS { sdlcLSAddress, sdlcLSAdminName, sdlcLSAdminState, sdlcLSAdminISTATUS, sdlcLSAdminMAXDATASend, sdlcLSAdminMAXDATARcv, sdlcLSAdminMAXIN, sdlcLSAdminMAXOUT, sdlcLSAdminMODULO, sdlcLSAdminRETRIESm, sdlcLSAdminRETRIESt, sdlcLSAdminRETRIESn, sdlcLSAdminRNRLIMIT, sdlcLSAdminDATMODE, sdlcLSAdminGPoll, sdlcLSAdminSimRim, sdlcLSAdminRowStatus } STATUS current DESCRIPTION "The sdlcCorePortAdminGroup defines objects which are common to the PortAdmin group of all compliant link stations." ::= { sdlcCoreGroups 4 } sdlcCoreLSOperGroup OBJECT-GROUP OBJECTS { sdlcLSOperRole, sdlcLSOperState, sdlcLSOperMAXDATASend, sdlcLSOperMAXIN, Hilgeman, Nix, Bartky & Clark [Page 62] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSOperMAXOUT, sdlcLSOperMODULO, sdlcLSOperRETRIESm, sdlcLSOperRETRIESt, sdlcLSOperRETRIESn, sdlcLSOperRNRLIMIT, sdlcLSOperDATMODE, sdlcLSOperLastFailTime, sdlcLSOperLastFailCause, sdlcLSOperLastFailCtrlIn, sdlcLSOperLastFailCtrlOut, sdlcLSOperLastFailFRMRInfo, sdlcLSOperLastFailREPLYTOs, sdlcLSOperEcho, sdlcLSOperGPoll } STATUS current DESCRIPTION "The sdlcCorePortOperGroup defines objects which are common to the PortOper group of all compliant link stations." ::= { sdlcCoreGroups 5 } sdlcCoreLSStatsGroup OBJECT-GROUP OBJECTS { sdlcLSStatsBLUsIn, sdlcLSStatsBLUsOut, sdlcLSStatsOctetsIn, sdlcLSStatsOctetsOut, sdlcLSStatsPollsIn, sdlcLSStatsPollsOut, sdlcLSStatsPollRspsIn, sdlcLSStatsPollRspsOut, sdlcLSStatsLocalBusies, sdlcLSStatsRemoteBusies, sdlcLSStatsIFramesIn, sdlcLSStatsIFramesOut, sdlcLSStatsRetransmitsIn, sdlcLSStatsRetransmitsOut, sdlcLSStatsUIFramesIn, sdlcLSStatsUIFramesOut, sdlcLSStatsXIDsIn, sdlcLSStatsXIDsOut, sdlcLSStatsTESTsIn, sdlcLSStatsTESTsOut, sdlcLSStatsREJsIn, Hilgeman, Nix, Bartky & Clark [Page 63] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 sdlcLSStatsREJsOut, sdlcLSStatsFRMRsIn, sdlcLSStatsFRMRsOut, sdlcLSStatsSIMsIn, sdlcLSStatsSIMsOut, sdlcLSStatsRIMsIn, sdlcLSStatsRIMsOut, sdlcLSStatsProtocolErrs, sdlcLSStatsRNRLIMITs, sdlcLSStatsRetriesExps } STATUS current DESCRIPTION "The sdlcCorePortStatsGroup defines objects which are common to the PortStats group of all compliant link stations." ::= { sdlcCoreGroups 6 } -- -- Conformance Groups for Primary Link Stations -- sdlcPrimaryGroups OBJECT IDENTIFIER ::= { sdlcGroups 2 } sdlcPrimaryGroup OBJECT-GROUP OBJECTS { sdlcPortAdminPAUSE, sdlcPortOperPAUSE, sdlcLSAdminREPLYTO, sdlcLSOperREPLYTO } STATUS current DESCRIPTION "The sdlcPrimaryGroup defines objects which are common to all compliant primary link stations." ::= { sdlcPrimaryGroups 1 } sdlcPrimaryMultipointGroup OBJECT-GROUP OBJECTS { sdlcPortAdminSERVLIM, sdlcPortAdminSlowPollTimer, sdlcPortOperSlowPollMethod, sdlcPortOperSERVLIM, sdlcPortOperSlowPollTimer Hilgeman, Nix, Bartky & Clark [Page 64] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 } STATUS current DESCRIPTION "The sdlcPrimaryMultipointGroup defines objects which are common to all compliant primary link stations that are in a multipoint topology." ::= { sdlcPrimaryGroups 2 } END 4. Acknowledgments Thanks goes to the SNADLC MIB working group for reviewing this MIB and for their infinite patience through the editing process. 5. References [1] Stewart, B., "Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2", RFC 1659, Xyplex, July 1994. [2] "Synchronous Data Link Control: Concepts", IBM Publication No. GA27-3093-04, 5th edition, May 1992. [3] "Vocabulary for Data Processing Telecommunications, and Office Systems", IBM Publication No. GC20-1699-6. [4] Kostick, D., Kielczewski, Z., and K. Shih, Editors, "Definitions of Managed Objects for SNA NAUs using SMIv2", RFC 1666, Eicon Technology Corporation, Bell Communications Research, Novell, August 1994. [5] Waldbusser, S., "Row Creation with SNMPv1", Work in Progress. [6] McCloghrie K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Syst, FTP Software, January 1994. Hilgeman, Nix, Bartky & Clark [Page 65] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 6. Glossary link station A link station comprises procedures and control information that coordinate the transfer of data between two nodes joined by a link connection. All traffic over the link connection is from the primary link station to one or more secondary link stations, or from a secondary link station to the primary link station. primary link station The link station instance on a link connection that is responsible for the control of the data link. There must be only one primary link station on a link connection. The primary link station issues commands to one or more secondary link stations. secondary link station The link station instance on a link connection that receives commands from the primary link station and issues responses to it. switched line A telecommunications line in which the connection is established by dialing. For switched lines, the SDLC startup sequence typically begins with a null exchange identifier (null XID). leased line A telecommunications line on which connections do not have to be established by dialing. For leased lines, the SDLC startup sequence may or may not begin with an exchange identifer (XID). While there are interface (e.g., RS.232) differences between leased and switched lines, those interface differences do not map one-to-one with differences in the SDLC startup protocol (i.e., the interface and the SDLC protocol are independent from one another). point-to-point link A link that connects the single primary link station to single secondary link station. A point-to-point link may be either switched or leased. multipoint link A link that connects the single primary link station to several secondary link stations. A multipoint link may be either switched or leased. Note: The physical interface signals for a multipoint link are different than for a point-to-point link. Hilgeman, Nix, Bartky & Clark [Page 66] RFC 1747 SNADLC SDLC MIB using SMIv2 January 1995 Synonymous with multidrop line. 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Jeff Hilgeman (chair) Apertus Technologies, Inc. 7275 Flying Cloud Dr. Eden Prarie, MN 55344 Phone: 1 612 828 0668 EMail: jeffh@apertus.com Shannon D. Nix Metaplex, Inc. 7412 Wingfoot Dr. Raleigh, NC 27615 Phone: 1 919 878 0811 EMail: snix@metaplex.com Alan Bartky Sync Research, Inc. 7 Studebaker Irvine, CA 92718 Phone: 1 714 588 2070 EMail: alan@sync.com Wayne Clark (editor) cisco Systems, Inc. 3100 Smoketree Ct. Suite 1000 Raleigh, NC 27604 Phone: 1 919 878 6958 EMail: wclark@cisco.com Hilgeman, Nix, Bartky & Clark [Page 67] snmp-mibs-downloader-1.1/mibrfcs/rfc1748.txt0000644000000000000000000012433011402176071015570 0ustar Network Working Group K. McCloghrie Request for Comments: 1748 E. Decker Obsoletes: 1743, 1231 cisco Systems, Inc. Category: Standards Track December 1994 IEEE 802.5 MIB using SMIv2 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 ............................................. 1 2. The SNMPv2 Network Management Framework .................. 2 2.1 Object Definitions ...................................... 2 3. Overview ................................................. 2 3.1 MAC Addresses ........................................... 3 3.2 Relationship to RFC 1213 ................................ 3 3.3 Relationship to RFC 1573 ................................ 3 3.3.1 Layering Model ........................................ 3 3.3.2 Virtual Circuits ...................................... 3 3.3.3 ifTestTable ........................................... 3 3.3.4 ifRcvAddressTable ..................................... 4 3.3.5 ifPhysAddress ......................................... 4 3.3.6 ifType ................................................ 4 4. Definitions .............................................. 4 5. Acknowledgements ......................................... 23 6. References ............................................... 23 Appendix A. Changes from RFC 1231 ........................... 24 Security Considerations ..................................... 24 Authors' Addresses .......................................... 25 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989 [7]. This memo is a replacement for RFC 1231. McCloghrie & Decker [Page 1] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. 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 This memo defines three tables: the 802.5 Interface Table, which contains state and parameter information which is specific to 802.5 interfaces, the 802.5 Statistics Table, which contains 802.5 interface statistics, and the 802.5 Timer Table, which contains the values of 802.5-defined timers. A managed system will have one entry in the 802.5 Interface Table and one entry in the 802.5 Statistics Table for each of its 802.5 interfaces. The 802.5 Timer Table is obsolete, but its definition has been retained in this memo for backward compatibility. This memo also defines OBJECT IDENTIFIERs, some to identify interface tests for use with the ifTestTable [6], and some to identify Token Ring interface Chip Sets. McCloghrie & Decker [Page 2] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 3.1. MAC Addresses All representations of MAC addresses in this MIB Module use the MacAddress textual convention [5] for which the address is in the "canonical" order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 requires MAC addresses to be transmitted most significant bit first. 16-bit addresses, if needed, are represented by setting their upper 4 octets to all zeros, i.e., AAFF would be represented as 00000000AAFF. 3.2. Relationship to RFC 1213 When this MIB module is used in conjunction with the "old" (i.e., pre-RFC 1573) interfaces group, the relationship between an 802.5 interface and an interface in the context of the RFC 1213 is one- to-one. That is, the value of an ifIndex object instance for an 802.5 interface can be directly used to identify corresponding instances of the objects defined in this memo. 3.3. Relationship to RFC 1573 RFC 1573, the Interface MIB Evolution, requires that any MIB module which is an adjunct of the Interface MIB, clarify specific areas within the Interface MIB. These areas were intentionally left vague in RFC 1573 to avoid over constraining the MIB module, thereby precluding management of certain media-types. Section 3.3 of RFC 1573 enumerates several areas which a media- specific MIB module must clarify. Each of these areas is addressed in a following subsection. The implementor is referred to RFC 1573 in order to understand the general intent of these areas. 3.3.1. Layering Model For the typical usage of this IEEE 802.5 MIB module, there will be no sub-layers "above" or "below" the 802.5 interface. However, this MIB module does not preclude such layering. 3.3.2. Virtual Circuits 802.5 does not support virtual circuits. 3.3.3. ifTestTable This MIB module defines two tests for 802.5 interfaces: Insertion and Loopback. Implementation of these tests is not required. McCloghrie & Decker [Page 3] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 3.3.4. ifRcvAddressTable The ifRcvAddressTable is defined to contains all MAC addresses, unicast, multicast (group) and broadcast, for which an interface will receive packets. For 802.5 interfaces, its use includes functional addresses. The format of the address, contained in ifRcvAddressAddress, is the same as for ifPhysAddress. For functional addresses on a particular 802.5 interface, only one ifRcvAddressTable entry is required. That entry is the one for the address which has the functional address bit ANDed with the bit mask of all functional addresses for which the interface will accept frames. 3.3.5. ifPhysAddress For an 802.5 interface, ifPhysAddress contains the interface's IEEE MAC address, stored as an octet string of length 6, in IEEE 802.1a "canonical" order, i.e., the Group Bit is positioned as the low-order bit (0x01) of the first octet. 3.3.6. ifType The objects defined in this memo apply to each interface for which the ifType has the value: iso88025-tokenRing(9) 4. Definitions TOKENRING-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Counter32, Integer32 FROM SNMPv2-SMI transmission FROM RFC1213-MIB MacAddress,TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; dot5 MODULE-IDENTITY LAST-UPDATED "9410231150Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO " Keith McCloghrie Postal: cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134-1706 McCloghrie & Decker [Page 4] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 US Phone: +1 408 526 5260 EMail: kzm@cisco.com" DESCRIPTION "The MIB module for IEEE Token Ring entities." ::= { transmission 9 } -- The 802.5 Interface Table -- This table contains state and parameter information which -- is specific to 802.5 interfaces. It is mandatory that -- systems having 802.5 interfaces implement this table in -- addition to the ifTable (see RFCs 1213 and 1573). dot5Table OBJECT-TYPE SYNTAX SEQUENCE OF Dot5Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains Token Ring interface parameters and state variables, one entry per 802.5 interface." ::= { dot5 1 } dot5Entry OBJECT-TYPE SYNTAX Dot5Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Token Ring status and parameter values for an 802.5 interface." INDEX { dot5IfIndex } ::= { dot5Table 1 } Dot5Entry ::= SEQUENCE { dot5IfIndex Integer32, dot5Commands INTEGER, dot5RingStatus INTEGER, dot5RingState INTEGER, dot5RingOpenStatus INTEGER, dot5RingSpeed INTEGER, dot5UpStream MacAddress, dot5ActMonParticipate INTEGER, dot5Functional MacAddress, dot5LastBeaconSent TimeStamp } McCloghrie & Decker [Page 5] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5IfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the 802.5 interface for which this entry contains management information. The value of this object for a particular interface has the same value as the ifIndex object, defined in MIB-II for the same interface." ::= { dot5Entry 1 } dot5Commands OBJECT-TYPE SYNTAX INTEGER { noop(1), open(2), reset(3), close(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "When this object is set to the value of open(2), the station should go into the open state. The progress and success of the open is given by the values of the objects dot5RingState and dot5RingOpenStatus. When this object is set to the value of reset(3), then the station should do a reset. On a reset, all MIB counters should retain their values, if possible. Other side affects are dependent on the hardware chip set. When this object is set to the value of close(4), the station should go into the stopped state by removing itself from the ring. Setting this object to a value of noop(1) has no effect. When read, this object always has a value of noop(1). The open(2) and close(4) values correspond to the up(1) and down(2) values of MIB-II's ifAdminStatus and ifOperStatus, i.e., the setting of ifAdminStatus and McCloghrie & Decker [Page 6] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5Commands affects the values of both dot5Commands and ifOperStatus." ::= { dot5Entry 2 } dot5RingStatus OBJECT-TYPE SYNTAX INTEGER (0..262143) MAX-ACCESS read-only STATUS current DESCRIPTION "The current interface status which can be used to diagnose fluctuating problems that can occur on token rings, after a station has successfully been added to the ring. Before an open is completed, this object has the value for the 'no status' condition. The dot5RingState and dot5RingOpenStatus objects provide for debugging problems when the station can not even enter the ring. The object's value is a sum of values, one for each currently applicable condition. The following values are defined for various conditions: 0 = No Problems detected 32 = Ring Recovery 64 = Single Station 256 = Remove Received 512 = reserved 1024 = Auto-Removal Error 2048 = Lobe Wire Fault 4096 = Transmit Beacon 8192 = Soft Error 16384 = Hard Error 32768 = Signal Loss 131072 = no status, open not completed." ::= { dot5Entry 3 } dot5RingState OBJECT-TYPE SYNTAX INTEGER { opened(1), closed(2), opening(3), closing(4), openFailure(5), ringFailure(6) } McCloghrie & Decker [Page 7] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 MAX-ACCESS read-only STATUS current DESCRIPTION "The current interface state with respect to entering or leaving the ring." ::= { dot5Entry 4 } dot5RingOpenStatus OBJECT-TYPE SYNTAX INTEGER { noOpen(1), -- no open attempted badParam(2), lobeFailed(3), signalLoss(4), insertionTimeout(5), ringFailed(6), beaconing(7), duplicateMAC(8), requestFailed(9), removeReceived(10), open(11) -- last open successful } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the success, or the reason for failure, of the station's most recent attempt to enter the ring." ::= { dot5Entry 5 } dot5RingSpeed OBJECT-TYPE SYNTAX INTEGER { unknown(1), oneMegabit(2), fourMegabit(3), sixteenMegabit(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The ring-speed at the next insertion into the ring. Note that this may or may not be different to the current ring-speed which is given by MIB-II's ifSpeed. For interfaces which do not support changing ring-speed, dot5RingSpeed can only be set to its current value. When dot5RingSpeed has the value unknown(1), the ring's actual ring-speed is to be used." McCloghrie & Decker [Page 8] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 ::= { dot5Entry 6 } dot5UpStream OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC-address of the up stream neighbor station in the ring." ::= { dot5Entry 7 } dot5ActMonParticipate OBJECT-TYPE SYNTAX INTEGER { true(1), false(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "If this object has a value of true(1) then this interface will participate in the active monitor selection process. If the value is false(2) then it will not. Setting this object does not take effect until the next Active Monitor election, and might not take effect until the next time the interface is opened." ::= { dot5Entry 8 } dot5Functional OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The bit mask of all Token Ring functional addresses for which this interface will accept frames." ::= { dot5Entry 9 } dot5LastBeaconSent OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of MIB-II's sysUpTime object at which the local system last transmitted a Beacon frame on this interface." ::= { dot5Entry 10 } McCloghrie & Decker [Page 9] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 -- The 802.5 Statistics Table -- This table contains statistics and error counter which are -- specific to 802.5 interfaces. It is mandatory that systems -- having 802.5 interfaces implement this table. dot5StatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot5StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Token Ring statistics, one entry per 802.5 interface. All the statistics are defined using the syntax Counter32 as 32-bit wrap around counters. Thus, if an interface's hardware maintains these statistics in 16-bit counters, then the agent must read the hardware's counters frequently enough to prevent loss of significance, in order to maintain 32-bit counters in software." ::= { dot5 2 } dot5StatsEntry OBJECT-TYPE SYNTAX Dot5StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry contains the 802.5 statistics for a particular interface." INDEX { dot5StatsIfIndex } ::= { dot5StatsTable 1 } Dot5StatsEntry ::= SEQUENCE { dot5StatsIfIndex Integer32, dot5StatsLineErrors Counter32, dot5StatsBurstErrors Counter32, dot5StatsACErrors Counter32, dot5StatsAbortTransErrors Counter32, dot5StatsInternalErrors Counter32, dot5StatsLostFrameErrors Counter32, dot5StatsReceiveCongestions Counter32, dot5StatsFrameCopiedErrors Counter32, dot5StatsTokenErrors Counter32, dot5StatsSoftErrors Counter32, dot5StatsHardErrors Counter32, dot5StatsSignalLoss Counter32, McCloghrie & Decker [Page 10] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5StatsTransmitBeacons Counter32, dot5StatsRecoverys Counter32, dot5StatsLobeWires Counter32, dot5StatsRemoves Counter32, dot5StatsSingles Counter32, dot5StatsFreqErrors Counter32 } dot5StatsIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the 802.5 interface for which this entry contains management information. The value of this object for a particular interface has the same value as MIB-II's ifIndex object for the same interface." ::= { dot5StatsEntry 1 } dot5StatsLineErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a frame or token is copied or repeated by a station, the E bit is zero in the frame or token and one of the following conditions exists: 1) there is a non-data bit (J or K bit) between the SD and the ED of the frame or token, or 2) there is an FCS error in the frame." ::= { dot5StatsEntry 2 } dot5StatsBurstErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station detects the absence of transitions for five half-bit timers (burst-five error)." ::= { dot5StatsEntry 3 } McCloghrie & Decker [Page 11] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5StatsACErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station receives an AMP or SMP frame in which A is equal to C is equal to 0, and then receives another SMP frame with A is equal to C is equal to 0 without first receiving an AMP frame. It denotes a station that cannot set the AC bits properly." ::= { dot5StatsEntry 4 } dot5StatsAbortTransErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station transmits an abort delimiter while transmitting." ::= { dot5StatsEntry 5 } dot5StatsInternalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station recognizes an internal error." ::= { dot5StatsEntry 6 } dot5StatsLostFrameErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station is transmitting and its TRR timer expires. This condition denotes a condition where a transmitting station in strip mode does not receive the trailer of the frame before the TRR timer goes off." ::= { dot5StatsEntry 7 } McCloghrie & Decker [Page 12] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5StatsReceiveCongestions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station recognizes a frame addressed to its specific address, but has no available buffer space indicating that the station is congested." ::= { dot5StatsEntry 8 } dot5StatsFrameCopiedErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station recognizes a frame addressed to its specific address and detects that the FS field A bits are set to 1 indicating a possible line hit or duplicate address." ::= { dot5StatsEntry 9 } dot5StatsTokenErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a station acting as the active monitor recognizes an error condition that needs a token transmitted." ::= { dot5StatsEntry 10 } dot5StatsSoftErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Soft Errors the interface has detected. It directly corresponds to the number of Report Error MAC frames that this interface has transmitted. Soft Errors are those which are recoverable by the MAC layer protocols." ::= { dot5StatsEntry 11 } McCloghrie & Decker [Page 13] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5StatsHardErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this interface has detected an immediately recoverable fatal error. It denotes the number of times this interface is either transmitting or receiving beacon MAC frames." ::= { dot5StatsEntry 12 } dot5StatsSignalLoss OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this interface has detected the loss of signal condition from the ring." ::= { dot5StatsEntry 13 } dot5StatsTransmitBeacons OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this interface has transmitted a beacon frame." ::= { dot5StatsEntry 14 } dot5StatsRecoverys OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Claim Token MAC frames received or transmitted after the interface has received a Ring Purge MAC frame. This counter signifies the number of times the ring has been purged and is being recovered back into a normal operating state." ::= { dot5StatsEntry 15 } dot5StatsLobeWires OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only McCloghrie & Decker [Page 14] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 STATUS current DESCRIPTION "The number of times the interface has detected an open or short circuit in the lobe data path. The adapter will be closed and dot5RingState will signify this condition." ::= { dot5StatsEntry 16 } dot5StatsRemoves OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the interface has received a Remove Ring Station MAC frame request. When this frame is received the interface will enter the close state and dot5RingState will signify this condition." ::= { dot5StatsEntry 17 } dot5StatsSingles OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the interface has sensed that it is the only station on the ring. This will happen if the interface is the first one up on a ring, or if there is a hardware problem." ::= { dot5StatsEntry 18 } dot5StatsFreqErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the interface has detected that the frequency of the incoming signal differs from the expected frequency by more than that specified by the IEEE 802.5 standard." ::= { dot5StatsEntry 19 } McCloghrie & Decker [Page 15] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 -- The Timer Table -- This group contains the values of timers for 802.5 -- interfaces. This table is obsolete, but its definition -- is retained here for backwards compatibility. dot5TimerTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot5TimerEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "This table contains Token Ring interface timer values, one entry per 802.5 interface." ::= { dot5 5 } dot5TimerEntry OBJECT-TYPE SYNTAX Dot5TimerEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "A list of Token Ring timer values for an 802.5 interface." INDEX { dot5TimerIfIndex } ::= { dot5TimerTable 1 } Dot5TimerEntry ::= SEQUENCE { dot5TimerIfIndex Integer32, dot5TimerReturnRepeat Integer32, dot5TimerHolding Integer32, dot5TimerQueuePDU Integer32, dot5TimerValidTransmit Integer32, dot5TimerNoToken Integer32, dot5TimerActiveMon Integer32, dot5TimerStandbyMon Integer32, dot5TimerErrorReport Integer32, dot5TimerBeaconTransmit Integer32, dot5TimerBeaconReceive Integer32 } dot5TimerIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The value of this object identifies the 802.5 interface for which this entry contains timer values. The value of McCloghrie & Decker [Page 16] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 this object for a particular interface has the same value as MIB-II's ifIndex object for the same interface." ::= { dot5TimerEntry 1 } dot5TimerReturnRepeat OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value used to ensure the interface will return to Repeat State, in units of 100 micro-seconds. The value should be greater than the maximum ring latency." ::= { dot5TimerEntry 2 } dot5TimerHolding OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "Maximum period of time a station is permitted to transmit frames after capturing a token, in units of 100 micro-seconds." ::= { dot5TimerEntry 3 } dot5TimerQueuePDU OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value for enqueuing of an SMP PDU after reception of an AMP or SMP frame in which the A and C bits were equal to 0, in units of 100 micro-seconds." ::= { dot5TimerEntry 4 } dot5TimerValidTransmit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value used by the active monitor to detect the absence of valid transmissions, in units of 100 micro-seconds." McCloghrie & Decker [Page 17] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 ::= { dot5TimerEntry 5 } dot5TimerNoToken OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value used to recover from various-related error situations. If N is the maximum number of stations on the ring, the value of this timer is normally: dot5TimerReturnRepeat + N*dot5TimerHolding." ::= { dot5TimerEntry 6 } dot5TimerActiveMon OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value used by the active monitor to stimulate the enqueuing of an AMP PDU for transmission, in units of 100 micro-seconds." ::= { dot5TimerEntry 7 } dot5TimerStandbyMon OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value used by the stand-by monitors to ensure that there is an active monitor on the ring and to detect a continuous stream of tokens, in units of 100 micro-seconds." ::= { dot5TimerEntry 8 } dot5TimerErrorReport OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value which determines how often a station shall send a Report Error MAC frame to report its error counters, in units of 100 micro-seconds." ::= { dot5TimerEntry 9 } McCloghrie & Decker [Page 18] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5TimerBeaconTransmit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value which determines how long a station shall remain in the state of transmitting Beacon frames before entering the Bypass state, in units of 100 micro-seconds." ::= { dot5TimerEntry 10 } dot5TimerBeaconReceive OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The time-out value which determines how long a station shall receive Beacon frames from its downstream neighbor before entering the Bypass state, in units of 100 micro-seconds." ::= { dot5TimerEntry 11 } -- 802.5 Interface Tests dot5Tests OBJECT IDENTIFIER ::= { dot5 3 } -- RFC 1573 defines the ifTestTable, through which a -- network manager can instruct an agent to test an interface -- for various faults. A test to be performed is identified -- as an OBJECT IDENTIFIER. -- The Insert Function test dot5TestInsertFunc OBJECT-IDENTITY STATUS current DESCRIPTION "Invoking this test causes the station to test the insert ring logic of the hardware if the station's lobe media cable is connected to a wiring concentrator. Note that this command inserts the station into the network, and thus, could cause problems if the station is connected to a operational network." ::= { dot5Tests 1 } McCloghrie & Decker [Page 19] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 -- The Full-Duplex Loop Back test dot5TestFullDuplexLoopBack OBJECT-IDENTITY STATUS current DESCRIPTION "Invoking this test on a 802.5 interface causes the interface to check the path from memory through the chip set's internal logic and back to memory, thus checking the proper functioning of the system's interface to the chip set." ::= { dot5Tests 2 } -- 802.5 Hardware Chip Sets -- RFC 1229 specified an object, ifExtnsChipSet, with the -- syntax of OBJECT IDENTIFIER, to identify the hardware -- chip set in use by an interface. RFC 1573 obsoletes -- the use of ifExtnsChipSet. However, the following -- definitions are retained for backwards compatibility. dot5ChipSets OBJECT IDENTIFIER ::= { dot5 4 } dot5ChipSetIBM16 OBJECT-IDENTITY STATUS current DESCRIPTION "IBM's 16/4 Mbs chip set." ::= { dot5ChipSets 1 } dot5ChipSetTItms380 OBJECT-IDENTITY STATUS current DESCRIPTION "Texas Instruments' TMS 380 4Mbs chip-set" ::= { dot5ChipSets 2 } dot5ChipSetTItms380c16 OBJECT-IDENTITY STATUS current DESCRIPTION "Texas Instruments' TMS 380C16 16/4 Mbs chip-set" ::= { dot5ChipSets 3 } McCloghrie & Decker [Page 20] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 -- conformance information dot5Conformance OBJECT IDENTIFIER ::= { dot5 6 } dot5Groups OBJECT IDENTIFIER ::= { dot5Conformance 1 } dot5Compliances OBJECT IDENTIFIER ::= { dot5Conformance 2 } -- compliance statements dot5Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the IEEE 802.5 MIB." MODULE -- this module MANDATORY-GROUPS { dot5StateGroup, dot5StatsGroup } OBJECT dot5ActMonParticipate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dot5Functional MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { dot5Compliances 1 } -- units of conformance dot5StateGroup OBJECT-GROUP OBJECTS { dot5Commands, dot5RingStatus, dot5RingState, dot5RingOpenStatus, dot5RingSpeed, dot5UpStream, dot5ActMonParticipate, dot5Functional, dot5LastBeaconSent } STATUS current DESCRIPTION "A collection of objects providing state information and parameters for IEEE 802.5 interfaces." ::= { dot5Groups 1 } dot5StatsGroup OBJECT-GROUP OBJECTS { dot5StatsLineErrors, dot5StatsBurstErrors, McCloghrie & Decker [Page 21] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 dot5StatsACErrors, dot5StatsAbortTransErrors, dot5StatsInternalErrors, dot5StatsLostFrameErrors, dot5StatsReceiveCongestions, dot5StatsFrameCopiedErrors, dot5StatsTokenErrors, dot5StatsSoftErrors, dot5StatsHardErrors, dot5StatsSignalLoss, dot5StatsTransmitBeacons, dot5StatsRecoverys, dot5StatsLobeWires, dot5StatsRemoves, dot5StatsSingles, dot5StatsFreqErrors } STATUS current DESCRIPTION "A collection of objects providing statistics for IEEE 802.5 interfaces." ::= { dot5Groups 2 } END McCloghrie & Decker [Page 22] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 5. Acknowledgements The changes from RFC 1231 are the result of discussions on the IETF's snmp mailing-list and in the Interfaces MIB Working Group. 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] 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. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [6] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, Jan 1994 [7] Institute of Electrical and Electronic Engineers, "Token Ring Access Method and Physical Layer Specifications", IEEE Standard 802.5-1989, 1989. McCloghrie & Decker [Page 23] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 APPENDIX A - Changes from RFC 1231 This memo has the following differences from RFC 1231: (1) This memo is formatted using the SNMPv2 SMI. (2) The relationship of the "open" and "close" states of dot5Commands to the value of ifAdminStatus has been clarified. In particular, the setting of one affects the value of the other. (3) The relationship dot5RingSpeed and ifSpeed has been clarified. In particular, ifSpeed indicates the current ring-speed; dot5RingSpeed indicates the ring-speed at the next insertion into the ring. If the interface doesn't support changing ring-speed, then dot5RingSpeed can only be set to its current value. When dot5RingSpeed has the value 'unknown(1)', the ring-speed is to be set to the ring's actual ring-speed. (4) Write-access to dot5ActMonParticipate is not required, and a change to the value of dot5ActMonParticipate does not take effect until the next Active Monitor election. (5) Write-access to dot5Functional is not required. (6) A new object, dot5LastBeaconSent has been defined to contain the timestamp of the last beacon frame sent. (7) The dot5TimerTable has been designated as obsolete. (8) Text has been added describing the applicability of RFC 1573 [6] to 802.5 interfaces. (9) Other minor editorial changes. Security Considerations Security issues are not discussed in this memo. McCloghrie & Decker [Page 24] RFC 1748 IEEE 802.5 MIB using SMIv2 December 1994 Authors' Addresses Keith McCloghrie cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134-1706 Phone: (408) 526-5260 EMail: kzm@cisco.com Eric B. Decker cisco Systems, Inc. 1525 O'Brien Dr. Menlo Park, CA 94025 Phone: (415) 688-8241 EMail: cire@cisco.com McCloghrie & Decker [Page 25] snmp-mibs-downloader-1.1/mibrfcs/rfc1749.txt0000644000000000000000000004223311402176071015572 0ustar Network Working Group K. McCloghrie Request for Comments: 1749 F. Baker Updates: 1748 E. Decker Category: Standards Track cisco Systems, Inc. December 1994 IEEE 802.5 Station Source Routing MIB using SMIv2 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 ............................................. 1 2. The SNMPv2 Network Management Framework .................. 2 2.1 Object Definitions ...................................... 2 3. Overview ................................................. 2 3.1 Source Routing .......................................... 2 3.2 Relationship to RFC 1748 ................................ 3 3.3 Relationship to RFC 1525 ................................ 3 3.4 Static Source Routes .................................... 4 3.5 Destinations on the Local Ring .......................... 4 4. Definitions .............................................. 4 5. Acknowledgements ......................................... 8 6. References ............................................... 8 7. Security Considerations .................................. 9 8. Authors' Addresses ....................................... 10 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end- stations for managing source routes on a Token Ring network where IEEE source-routing is in use. IEEE source-routing is described in 802.5 Token Ring Access Method and Physical Layer Specifications [8] and related ISO publications [9, 10, 11]. This memo is an incremental update to RFC 1748 [6]. It is documented separately from the RFC 1748 solely due to the latter's maturity within the Internet standardization process. McCloghrie, Baker & Decker [Page 1] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 [3] which defines the administrative and other architectural aspects of the framework. o RFC 1448 [4] which defines the protocol used for network access to managed objects. 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 This memo defines a single table: the 802.5 Station Source Routing Table, which contains the source routes known by a end-station on an IEEE 802.5 Token Ring network in which IEEE source-routing is in use. 3.1. Source Routing Source routing extends the 802.5 protocol [8] by assigning a unique ring number to each ring within the extended LAN, and a bridge number to each source routing bridge's connection to a ring. A Routing Information Field (RIF) must be included in frames which need to traverse multiple rings. The format of the RIF is: McCloghrie, Baker & Decker [Page 2] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 octets octets octets octets 1&2 3&4 5&6 17&18 +------+------+------+-------+------+ | RC | RD | RD | ... | RD | +------+------+------+-------+------+ <---- 0 to 8 RD fields ----> The format of the Routing Control (RC) field is: octet 1 octet 2 +---------------+---------------+ |b b b l l l l l|d f f f 0 0 0 0| +---------------+---------------+ ^ ^ ^ ^ | | | | Explorer indicator --+ | | +-- Max frame length* Length of RIF field --+ +-- Direction to use RDs * Note that the length of the Maximum frame length subfield has recently been extended to 6 bits. The format of each Routing Descriptor (RD) field is: octet 1 octet 2 +---------------+---------------+ |r r r r r r r r r r r r i i i i| +---------------+---------------+ <---- ring number ----> <-----> ^ | bridge number --+ 3.2. Relationship to RFC 1748 RFC 1748 [6], the IEEE 802.5 MIB, defines managed objects used for interfaces to IEEE 802.5 Token Ring subnetworks. This memo is an incremental update to RFC 1748, and is documented independently solely due to the maturity of the definitions contained within RFC 1748. 3.3. Relationship to RFC 1525 RFC 1525 [7] defines the MIB objects specific to source-routing for source-routing and SRT bridges. This memo defines the MIB objects specific to source-routing for source-routing end-stations. McCloghrie, Baker & Decker [Page 3] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 3.4. Static Source Routes It is unclear how many, if any, existing systems allow the creation or deletion of "static" 802.5 source routes by network management. However, SNMPv2 SMI defines that the MAX-ACCESS clause as specifying the maximal level of access which makes "protocol sense". Thus, this memo provides support for static source routes through the dot5SrRouteStatus object, but the conformance statements allow for stations which do not support static source routes, by requiring that compliant agents only need provide read-access to dot5SrRouteStatus. 3.5. Destinations on the Local Ring Entries should be included in the dot5SrRouteTable for destination MAC addresses which are on the same ring as the instrumented 802.5 interface. For such entries, dot5SrRouteDescr has the value of the zero-length string, and dot5SrRouteControl has the corresponding value. 4. Definitions TOKENRING-STATION-SR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, MacAddress FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2, ifIndex FROM RFC1213-MIB; dot5SrMIB MODULE-IDENTITY LAST-UPDATED "9412161000Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO " Keith McCloghrie Postal: Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US Phone: +1 408 526 5260 Email: kzm@cisco.com" DESCRIPTION "The MIB module for managing source routes in end-stations on IEEE 802.5 Token Ring networks." ::= { mib-2 42 } McCloghrie, Baker & Decker [Page 4] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 dot5SrMIBObjects OBJECT IDENTIFIER ::= { dot5SrMIB 1 } SourceRoute ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents a Source Route, containing an embedded sequence of bridge and ring ID's, as used by 802.5 Source Routing." REFERENCE "Annex C of ISO/IEC 10038: 1993, [ANSI/IEEE Std 802.1D, 1993]" SYNTAX OCTET STRING (SIZE(0..30)) -- The 802.5 Station Source Route Table -- dot5SrRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot5SrRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of source-routing routes. This represents the 802.5 RIF database." ::= { dot5SrMIBObjects 1 } dot5SrRouteEntry OBJECT-TYPE SYNTAX Dot5SrRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a specific route. An entry is created whenever a 'Single Path Explorer' or an 'All Paths Explorer' discovers a route to a neighbor not currently in the table, or whenever an 'All Paths Explorer' discovers a better (e.g., shorter) route than the route currently stored in the table. This is done on behalf of any network layer client. The ifIndex value in the INDEX clause refers to the value of MIB-II's ifIndex object for the interface on which the route is in effect." INDEX { ifIndex, dot5SrRouteDestination } ::= { dot5SrRouteTable 1 } Dot5SrRouteEntry ::= SEQUENCE { McCloghrie, Baker & Decker [Page 5] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 dot5SrRouteDestination MacAddress, dot5SrRouteControl OCTET STRING, dot5SrRouteDescr SourceRoute, dot5SrRouteStatus RowStatus } dot5SrRouteDestination OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination of this route." ::= { dot5SrRouteEntry 2 } dot5SrRouteControl OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of Routing Control field for this route." REFERENCE "Annex C of ISO/IEC 10038: 1993, [ANSI/IEEE Std 802.1D, 1993]" ::= { dot5SrRouteEntry 3 } dot5SrRouteDescr OBJECT-TYPE SYNTAX SourceRoute MAX-ACCESS read-create STATUS current DESCRIPTION "The embedded sequence of bridge and ring ID's for this route. For destinations on the local ring, the value of this object is the zero-length string." REFERENCE "Annex C of ISO/IEC 10038: 1993, [ANSI/IEEE Std 802.1D, 1993]" ::= { dot5SrRouteEntry 4 } dot5SrRouteStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of the instances of dot5SrRouteControl and dot5SrRouteDescr can be modified while the row's status is 'active." ::= { dot5SrRouteEntry 5 } McCloghrie, Baker & Decker [Page 6] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 -- conformance information dot5SrConformance OBJECT IDENTIFIER ::= { dot5SrMIB 2 } dot5SrGroups OBJECT IDENTIFIER ::= { dot5SrConformance 1 } dot5SrCompliances OBJECT IDENTIFIER ::= { dot5SrConformance 2 } -- compliance statements dot5SrCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the IEEE 802.5 Station Source Route MIB." MODULE -- this module MANDATORY-GROUPS { dot5SrRouteGroup } OBJECT dot5SrRouteStatus SYNTAX INTEGER { active(1) } -- subset of values MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only the 'active' value need be supported." OBJECT dot5SrRouteControl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dot5SrRouteDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { dot5SrCompliances 1 } -- units of conformance dot5SrRouteGroup OBJECT-GROUP OBJECTS { dot5SrRouteControl, dot5SrRouteDescr, dot5SrRouteStatus } STATUS current McCloghrie, Baker & Decker [Page 7] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 DESCRIPTION "A collection of objects providing for the management of source routes in stations on IEEE 802.5 source-routing networks." ::= { dot5SrGroups 1 } END 5. Acknowledgements The need for this MIB module was agreed upon by the members of the IETF Interfaces Working Group, and the definitions were derived from experience with enterprise-specific MIBs presented to the Working Group. 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] 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. [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [6] McCloghrie, K., and E. Decker, "IEEE 802.5 Token Ring MIB using SMIv2", RFC 1748 cisco Systems, Inc., December 1994. McCloghrie, Baker & Decker [Page 8] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 [7] McCloghrie, K., Decker, E., Langville, P., and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, Hughes LAN Systems, cisco Systems, Inc., Digital Equipment Corporation, September 1993. [8] "Token Ring Access Method and Physical Layer Specifications", IEEE Standard 802.5-1989, 1989. [9] "Information technology - Local and metropolitan area networks - Part 5: Token ring access method and physical layer specifications", ISO/IEC 8802-5, 1992. [10] "Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges", ISO/IEC 10038, 1993 [ANSI/IEEE Std 802.1D, 1993 Edition]. [11] "Source Routing Operation by End Systems", ISO/IEC 8802-2 PDAM5.3 (6N7721). 7. Security Considerations Security issues are not discussed in this memo. McCloghrie, Baker & Decker [Page 9] RFC 1749 802.5 Station Source Routing MIB using SMIv2 December 1994 8. Authors' Addresses Keith McCloghrie cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: (408) 526-5260 EMail: kzm@cisco.com Fred Baker cisco Systems, Inc. 519 Lado Drive Santa Barbara, CA 93111 Phone: (805) 681-0115 EMail: fred@cisco.com Eric B. Decker cisco Systems, Inc. 1525 O'Brien Dr. Menlo Park, California 94025 Phone: (415) 688-8241 EMail: cire@cisco.com McCloghrie, Baker & Decker [Page 10] snmp-mibs-downloader-1.1/mibrfcs/rfc1792.txt0000644000000000000000000004000511402176071015563 0ustar Network Working Group T. Sung Request for Comments: 1792 Novell, Inc. Category: Experimental April 1995 TCP/IPX Connection Mib Specification Status of this Memo This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. IESG Note: Internet Engineering Steering Group comment from the Area Director for Transport Services: Please note well that this memo is an individual product of the author. Implementation experience, particularly on the effectiveness of the protocols in dual-stack environments, is needed. 1. Introduction Traditionally, TCP and UDP runs over IP. STD 17, RFC 1213 defines TCP connection MIB object and UDP listener object assuming just that. For TCP and UDP running over IPX, tcpConnTable and udpTable objects from RFC 1213 cannot be used since they define the address to be of type IpAddress. As such, we need to define new objects that can properly describe TCP and UDP connections over IPX. New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. 2. Objects TCPIPX-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212; -- IPX address type. -- First 4 octests are the network numbers and the last 6 -- octests are the node numbers. In ascii, it is represented Sung [Page 1] RFC 1792 TCP/IPX MIB April 1995 -- as hex digits, as in: nnnnnnnn:mmmmmmmmmmmm IpxAddress ::= OCTET STRING (size (10)) -- TCP/IPX MIB object idenfifiers novell OBJECT IDENTIFIER ::= { enterprises 23 } mibDoc OBJECT IDENTIFIER ::= { novell 2 } tcpx OBJECT IDENTIFIER ::= { mibDoc 29 } tcpxTcp OBJECT IDENTIFIER ::= { tcpx 1 } tcpxUdp OBJECT IDENTIFIER ::= { tcpx 2 } -- the TCP/IPX Connection table -- The TCP/IPX connection table contains information -- about this entity's existing TCP connections over -- IPX. tcpIpxConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpIpxConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing information specific on TCP connection over IPX network layer." ::= { tcpxTcp 1 } tcpIpxConnEntry OBJECT-TYPE SYNTAX TcpIpxConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current TCP connection over IPX An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state." INDEX { tcpIpxConnLocalAddress, tcpIpxConnLocalPort, tcpIpxConnRemAddress, tcpIpxConnRemPort } ::= { tcpIpxConnTable 1 } TcpIpxConnEntry ::= SEQUENCE { Sung [Page 2] RFC 1792 TCP/IPX MIB April 1995 tcpIpxConnState INTEGER, tcpIpxConnLocalAddress IpxAddress tcpIpxConnLocalPort INTEGER (0..65535), tcpIpxConnRemAddress IpxAddress, tcpIpxConnRemPort INTEGER (0..65535) } tcpIpxConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this TCP connection. The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note however that RST Sung [Page 3] RFC 1792 TCP/IPX MIB April 1995 segments are not sent reliably)." ::= { tcpIpxConnEntry 1 } tcpIpxConnLocalAddress OBJECT-TYPE SYNTAX IpxAddress ACCESS read-only STATUS mandatory DESCRIPTION "The local IPX address for this TCP connection. In the case of a connection in the listen state which is willing to accept connections for any interface, the value 00000000:000000000000 is used. See tcpUnspecConnTable for connections in the listen state which is willing to accept connects for any IP interface associated with the node." ::= { tcpIpxConnEntry 2 } -- NetworkAddress defined in SMI only include IP currently, -- so we can't use it to represent both IP and IPX address. tcpIpxConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this TCP connection." ::= { tcpIpxConnEntry 3 } tcpIpxConnRemAddress OBJECT-TYPE SYNTAX IpxAddress ACCESS read-only STATUS mandatory DESCRIPTION "The remote IPX address for this TCP connection." ::= { tcpIpxConnEntry 4 } tcpIpxConnRemPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The remote port number for this TCP connection." ::= { tcpIpxConnEntry 5 } Sung [Page 4] RFC 1792 TCP/IPX MIB April 1995 -- the UDP Listener table -- The UDP listener table contains information about this -- entity's UDP end-points on which a local application is -- currently accepting datagrams. udpIpxTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpIpxEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing UDP listener information." ::= { tcpxUdp 1 } udpIpxEntry OBJECT-TYPE SYNTAX UdpIpxEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current UDP listener." INDEX { udpIpxLocalAddress, udpIpxLocalPort } ::= { udpIpxTable 1 } UdpIpxEntry ::= SEQUENCE { udpIpxLocalAddress IpxAddress udpIpxLocalPort INTEGER (0..65535) } udpIpxLocalAddress OBJECT-TYPE SYNTAX IpxAddress ACCESS read-only STATUS mandatory DESCRIPTION "The local IPX address for this UDP listener. In the case of a UDP listener which is willing to accept datagrams for any interface, the value 00000000:000000000000 is used. See udpUnspecTable for UDP listener which is willing to accept datagrams from any network layer." ::= { udpIpxEntry 1 } udpIpxLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) Sung [Page 5] RFC 1792 TCP/IPX MIB April 1995 ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this UDP listener." ::= { udpIpxEntry 2 } -- the TCP/UNSPEC Connection table -- The TCP/UPSPEC connection table contains information -- about this entity's existing TCP connections over -- unspecified network. -- Since the network is unspecified, the network -- address is also unspecified. Hence, this -- connection table does not include any network -- address. tcpUnspecConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpIpxConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing information specific on TCP connection over unspecified network layer." ::= { tcpxTcp 2 } tcpUnspecConnEntry OBJECT-TYPE SYNTAX TcpUnspecConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current TCP connection over unspecified network layer. An object of this type is transient, in that it ceases to exist when the connection makes transition beyond LISTEN state, or when (or soon after) the connection makes transition to the CLOSED state," INDEX { tcpUnspecConnLocalPort } ::= { tcpUnspecConnTable 1 } TcpUnspecConnEntry ::= SEQUENCE { tcpUnspecConnState INTEGER, tcpUnspecConnLocalPort Sung [Page 6] RFC 1792 TCP/IPX MIB April 1995 INTEGER (0..65535), } tcpUnspecConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), deleteTCB(12) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this TCP connection. Since the TCP connection can belong to this table only when its state is less than SYN_SENT, only closed and listen state apply. The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably)." ::= { tcpUnspecConnEntry 1 } tcpUnspecConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this TCP connection." ::= { tcpUnspecConnEntry 2 } Sung [Page 7] RFC 1792 TCP/IPX MIB April 1995 -- the UDP Listener table -- The UDP listener table contains information about this -- entity's UDP end-points over unspecified network layer, -- on which a local application is currently accepting -- datagrams. If network layer is unspecified, the network -- address is also unspecified. Hence, this table does not -- include any network address. udpUnspecTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpUnspecEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing UDP listener information." ::= { tcpxUdp 2 } udpUnspecEntry OBJECT-TYPE SYNTAX UdpUnspecEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current UDP listener." INDEX { udpUnspecLocalPort } ::= { udpUnspecTable 1 } UdpUnspecEntry ::= SEQUENCE { udpUnspecLocalPort INTEGER (0..65535) } udpUnspecLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this UDP listener." ::= { udpUnspecEntry 1 } END Sung [Page 8] RFC 1792 TCP/IPX MIB April 1995 Acknowledgement The author would like to thank following folks and others for their assitance: Greg Minshall, Dave Piscitello. Security Considerations Security issues are not discussed in this memo. Author's Address Tae Sung Novell, Inc. 2180 Fortune Drive San Jose, California, 95131 Phone: (408)577-8439 EMail: tae@novell.Com Sung [Page 9] snmp-mibs-downloader-1.1/mibrfcs/rfc1910.txt0000644000000000000000000027771411402176071015576 0ustar Network Working Group G. Waters, Editor Request for Comments: 1910 Bell-Northern Research Ltd. Category: Experimental February 1996 User-based Security Model for SNMPv2 Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Table of Contents 1. Introduction ................................................ 2 1.1 Threats .................................................... 3 1.2 Goals and Constraints ...................................... 4 1.3 Security Services .......................................... 5 1.4 Mechanisms ................................................. 5 1.4.1 Digest Authentication Protocol ........................... 7 1.4.2 Symmetric Encryption Protocol ............................ 8 2. Elements of the Model ....................................... 10 2.1 SNMPv2 Users ............................................... 10 2.2 Contexts and Context Selectors ............................. 11 2.3 Quality of Service (qoS) ................................... 13 2.4 Access Policy .............................................. 13 2.5 Replay Protection .......................................... 13 2.5.1 agentID .................................................. 14 2.5.2 agentBoots and agentTime ................................. 14 2.5.3 Time Window .............................................. 15 2.6 Error Reporting ............................................ 15 2.7 Time Synchronization ....................................... 16 2.8 Proxy Error Propagation .................................... 16 2.9 SNMPv2 Messages Using this Model ........................... 16 2.10 Local Configuration Datastore (LCD) ....................... 18 3. Elements of Procedure ....................................... 19 3.1 Generating a Request or Notification ....................... 19 3.2 Processing a Received Communication ........................ 20 3.2.1 Additional Details ....................................... 28 3.2.1.1 ASN.1 Parsing Errors ................................... 28 3.2.1.2 Incorrectly Encoded Parameters ......................... 29 3.2.1.3 Generation of a Report PDU ............................. 29 3.2.1.4 Cache Timeout .......................................... 29 3.3 Generating a Response ...................................... 30 4. Discovery ................................................... 30 5. Definitions ................................................. 31 Waters Experimental [Page 1] RFC 1910 User-based Security Model for SNMPv2 February 1996 4.1 The USEC Basic Group ....................................... 32 4.2 Conformance Information .................................... 35 4.2.1 Compliance Statements .................................... 35 4.2.2 Units of Conformance ..................................... 35 6. Security Considerations ..................................... 36 6.1 Recommended Practices ...................................... 36 6.2 Defining Users ............................................. 37 6.3 Conformance ................................................ 38 7. Editor's Address ............................................ 38 8. Acknowledgements ............................................ 39 9. References .................................................. 39 Appendix A Installation ........................................ 41 Appendix A.1 Agent Installation Parameters ..................... 41 Appendix A.2 Password to Key Algorithm ......................... 43 Appendix A.3 Password to Key Sample ............................ 44 1. Introduction A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. The Administrative Infrastructure for SNMPv2 document [1] defines an administrative framework which realizes effective management in a variety of configurations and environments. In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User- based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This administrative framework includes the provision of an access control model. The enforcement of access rights requires the means to identify the entity on whose behalf a request is generated. This SNMPv2 security model identifies an entity on whose behalf an SNMPv2 message is generated as a "user". Waters Experimental [Page 2] RFC 1910 User-based Security Model for SNMPv2 February 1996 1.1. Threats Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any SNMPv2 security model. Other threats are not applicable to the network management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which this SNMPv2 security model should provide protection are: Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMPv2 messages generated on behalf of an authorized user in such a way as to effect unauthorized management operations, including falsifying the value of an object. Masquerade The masquerade threat is the danger that management operations not authorized for some user may be attempted by assuming the identity of another user that has the appropriate authorizations. Two secondary threats are also identified. The security protocols defined in this memo do provide protection against: Message Stream Modification The SNMPv2 protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations. Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between managed agents and a management station. Protecting against this threat may be required as a matter of local policy. There are at least two threats that an SNMPv2 security protocol need not protect against. The security protocols defined in this memo do not provide protection against: Waters Experimental [Page 3] RFC 1910 User-based Security Model for SNMPv2 February 1996 Denial of Service An SNMPv2 security protocol need not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable network management protocol must cope as a matter of course. Traffic Analysis In addition, an SNMPv2 security protocol need not attempt to address traffic analysis attacks. Indeed, many traffic patterns are predictable - agents may be managed on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis. 1.2. Goals and Constraints Based on the foregoing account of threats in the SNMP network management environment, the goals of this SNMPv2 security model are as follows. (1) The protocol should provide for verification that each received SNMPv2 message has not been modified during its transmission through the network in such a way that an unauthorized management operation might result. (2) The protocol should provide for verification of the identity of the user on whose behalf a received SNMPv2 message claims to have been generated. (3) The protocol should provide for detection of received SNMPv2 messages, which request or contain management information, whose time of generation was not recent. (4) The protocol should provide, when necessary, that the contents of each received SNMPv2 message are protected from disclosure. In addition to the principal goal of supporting secure network management, the design of this SNMPv2 security model is also influenced by the following constraints: (1) When the requirements of effective management in times of network stress are inconsistent with those of security, the design should prefer the former. (2) Neither the security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or key Waters Experimental [Page 4] RFC 1910 User-based Security Model for SNMPv2 February 1996 management protocols). (3) A security mechanism should entail no changes to the basic SNMP network management philosophy. 1.3. Security Services The security services necessary to support the goals of an SNMPv2 security model are as follows. Data Integrity is the provision of the property that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non-maliciously. Data Origin Authentication is the provision of the property that the claimed identity of the user on whose behalf received data was originated is corroborated. Data Confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. For the protocols specified in this memo, it is not possible to assure the specific originator of a received SNMPv2 message; rather, it is the user on whose behalf the message was originated that is authenticated. For these protocols, it not possible to obtain data integrity without data origin authentication, nor is it possible to obtain data origin authentication without data integrity. Further, there is no provision for data confidentiality without both data integrity and data origin authentication. The security protocols used in this memo are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises. 1.4. Mechanisms The security protocols defined in this memo employ several types of mechanisms in order to realize the goals and security services described above: Waters Experimental [Page 5] RFC 1910 User-based Security Model for SNMPv2 February 1996 - In support of data integrity, a message digest algorithm is required. A digest is calculated over an appropriate portion of an SNMPv2 message and included as part of the message sent to the recipient. - In support of data origin authentication and data integrity, a secret value is both inserted into, and appended to, the SNMPv2 message prior to computing the digest; the inserted value overwritten prior to transmission, and the appended value is not transmitted. The secret value is shared by all SNMPv2 entities authorized to originate messages on behalf of the appropriate user. - To protect against the threat of message delay or replay (to an extent greater than can occur through normal operation), a set of time (at the agent) indicators and a request-id are included in each message generated. An SNMPv2 agent evaluates the time indicators to determine if a received message is recent. An SNMPv2 manager evaluates the time indicators to ensure that a received message is at least as recent as the last message it received from the same source. An SNMPv2 manager uses received authentic messages to advance its notion of time (at the agent). An SNMPv2 manager also evaluates the request-id in received Response messages and discards messages which do not correspond to outstanding requests. These mechanisms provide for the detection of messages whose time of generation was not recent in all but one circumstance; this circumstance is the delay or replay of a Report message (sent to a manager) when the manager has has not recently communicated with the source of the Report message. In this circumstance, the detection guarantees only that the Report message is more recent than the last communication between source and destination of the Report message. However, Report messages do not request or contain management information, and thus, goal #3 in Section 1.2 above is met; further, Report messages can at most cause the manager to advance its notion of time (at the agent) by less than the proper amount. This protection against the threat of message delay or replay does not imply nor provide any protection against unauthorized deletion or suppression of messages. Other mechanisms defined independently of the security protocol can also be used to detect the re- ordering, replay, deletion, or suppression of messages containing set operations (e.g., the MIB variable snmpSetSerialNo [15]). - In support of data confidentiality, an encryption algorithm is required. An appropriate portion of the message is encrypted prior to being transmitted. Waters Experimental [Page 6] RFC 1910 User-based Security Model for SNMPv2 February 1996 1.4.1. Digest Authentication Protocol The Digest Authentication Protocol defined in this memo provides for: - verifying the integrity of a received message (i.e., the message received is the message sent). The integrity of the message is protected by computing a digest over an appropriate portion of a message. The digest is computed by the originator of the message, transmitted with the message, and verified by the recipient of the message. - verifying the user on whose behalf the message was generated. A secret value known only to SNMPv2 entities authorized to generate messages on behalf of this user is both inserted into, and appended to, the message prior to the digest computation. Thus, the verification of the user is implicit with the verification of the digest. (Note that the use of two copies of the secret, one near the start and one at the end, is recommended by [14].) - verifying that a message sent to/from one SNMPv2 entity cannot be replayed to/as-if-from another SNMPv2 entity. Included in each message is an identifier unique to the SNMPv2 agent associated with the sender or intended recipient of the message. Also, each message containing a Response PDU contains a request-id which associates the message to a recently generated request. A Report message sent by one SNMPv2 agent to one SNMPv2 manager can potentially be replayed to another SNMPv2 manager. However, Report messages do not request or contain management information, and thus, goal #3 in Section 1.2 above is met; further, Report messages can at most cause the manager to advance its notion of time (at the agent) by less than the correct amount. - detecting messages which were not recently generated. A set of time indicators are included in the message, indicating the time of generation. Messages (other than those containing Report PDUs) without recent time indicators are not considered authentic. In addition, messages containing Response PDUs have a request-id; if the request-id does not match that of a recently generated request, then the message is not considered to be authentic. Waters Experimental [Page 7] RFC 1910 User-based Security Model for SNMPv2 February 1996 A Report message sent by an SNMPv2 agent can potentially be replayed at a later time to an SNMPv2 manager which has not recently communicated with that agent. However, Report messages do not request or contain management information, and thus, goal #3 in Section 1.2 above is met; further, Report messages can at most cause the manager to advance its notion of time (at the agent) by less than the correct amount. This protocol uses the MD5 [3] message digest algorithm. A 128-bit digest is calculated over the designated portion of an SNMPv2 message and included as part of the message sent to the recipient. The size of both the digest carried in a message and the private authentication key is 16 octets. This memo allows the same user to be defined on multiple SNMPv2 agents and managers. Each SNMPv2 agent maintains a value, agentID, which uniquely identifies the agent. This value is included in each message sent to/from that agent. Messages sent from a SNMPv2 dual- role entity [1] to a SNMPv2 manager include the agentID value maintained by the dual-role entity's agent. On receipt of a message, an agent checks the value to ensure it is the intended recipient, and a manager uses the value to ensure that the message is processed using the correct state information. Each SNMPv2 agent maintains two values, agentBoots and agentTime, which taken together provide an indication of time at that agent. Both of these values are included in an authenticated message sent to/received from that agent. Authenticated messages sent from a SNMPv2 dual-role entity to a SNMPv2 manager include the agentBoots and agentTime values maintained by the dual-role entity's agent. On receipt, the values are checked to ensure that the indicated time is within a time window of the current time. The time window represents an administrative upper bound on acceptable delivery delay for protocol messages. For an SNMPv2 manager to generate a message which an agent will accept as authentic, and to verify that a message received from that agent is authentic, that manager must first achieve time synchronization with that agent. Similarly, for a manger to verify that a message received from an SNMPv2 dual-role entity is authentic, that manager must first achieve time synchronization with the dual- role entity's agent. 1.4.2. Symmetric Encryption Protocol The Symmetric Encryption Protocol defined in this memo provides support for data confidentiality through the use of the Data Encryption Standard (DES) in the Cipher Block Chaining mode of Waters Experimental [Page 8] RFC 1910 User-based Security Model for SNMPv2 February 1996 operation. The designated portion of an SNMPv2 message is encrypted and included as part of the message sent to the recipient. Two organizations have published specifications defining the DES: the National Institute of Standards and Technology (NIST) [5] and the American National Standards Institute [6]. There is a companion Modes of Operation specification for each definition (see [7] and [8], respectively). The NIST has published three additional documents that implementors may find useful. - There is a document with guidelines for implementing and using the DES, including functional specifications for the DES and its modes of operation [9]. - There is a specification of a validation test suite for the DES [10]. The suite is designed to test all aspects of the DES and is useful for pinpointing specific problems. - There is a specification of a maintenance test for the DES [11]. The test utilizes a minimal amount of data and processing to test all components of the DES. It provides a simple yes-or-no indication of correct operation and is useful to run as part of an initialization step, e.g., when a computer reboots. This Symmetric Encryption Protocol specifies that the size of the privacy key is 16 octets, of which the first 8 octets are a DES key and the second 8 octets are a DES Initialization Vector. The 64-bit DES key in the first 8 octets of the private key is a 56 bit quantity used directly by the algorithm plus 8 parity bits - arranged so that one parity bit is the least significant bit of each octet. The setting of the parity bits is ignored by this protocol. The length of an octet sequence to be encrypted by the DES must be an integral multiple of 8. When encrypting, the data is padded at the end as necessary; the actual pad value is irrelevant. If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, the processing of the octet sequence is halted and an appropriate exception noted. When decrypting, the padding is ignored. Waters Experimental [Page 9] RFC 1910 User-based Security Model for SNMPv2 February 1996 2. Elements of the Model This section contains definitions required to realize the security model defined by this memo. 2.1. SNMPv2 Users Management operations using this security model make use of a defined set of user identities. For any SNMPv2 user on whose behalf management operations are authorized at a particular SNMPv2 agent, that agent must have knowledge of that user. A SNMPv2 manager that wishes to communicate with a particular agent must also have knowledge of a user known to that agent, including knowledge of the applicable attributes of that user. Similarly, a SNMPv2 manager that wishes to receive messages from a SNMPv2 dual-role entity must have knowledge of the user on whose behalf the dual-role entity sends the message. A user and its attributes are defined as follows: An octet string representing the name of the user. An indication of whether messages sent on behalf of this user can be authenticated, and if so, the type of authentication protocol which is used. One such protocol is defined in this memo: the Digest Authentication Protocol. If messages sent on behalf of this user can be authenticated, the (private) authentication key for use with the authentication protocol. Note that a user's authentication key will normally be different at different agents. An indication of whether messages sent on behalf of this user can be protected from disclosure, and if so, the type of privacy protocol which is used. One such protocol is defined in this memo: the Symmetric Encryption Protocol. If messages sent on behalf of this user can be protected from disclosure, the (private) privacy key for use with the privacy protocol. Note that a user's privacy key will normally be different at different agents. Waters Experimental [Page 10] RFC 1910 User-based Security Model for SNMPv2 February 1996 2.2. Contexts and Context Selectors An SNMPv2 context is a collection of management information accessible (locally or via proxy) by an SNMPv2 agent. An item of management information may exist in more than one context. An SNMPv2 agent potentially has access to many contexts. Each SNMPv2 message contains a context selector which unambiguously identifies an SNMPv2 context accessible by the SNMPv2 agent to which the message is directed or by the SNMPv2 agent associated with the sender of the message. For a local SNMPv2 context which is realized by an SNMPv2 entity, that SNMPv2 entity uses locally-defined mechanisms to access the management information identified by the SNMPv2 context. For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context. The term remote SNMPv2 context is used at an SNMPv2 manager to indicate a SNMPv2 context (either local or proxy) which is not realized by the local SNMPv2 entity (i.e., the local SNMPv2 entity uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context). Proxy SNMPv2 contexts are further categorized as either local-proxy contexts or remote-proxy contexts. A proxy SNMPv2 agent receives Get/GetNext/GetBulk/Set operations for a local-proxy context, and forwards them with a remote-proxy context; it receives SNMPv2-Trap and Inform operations for a remote-proxy context, and forwards them with a local-proxy context; for Response operations, a proxy SNMPv2 agent receives them with either a local-proxy or remote-proxy context, and forwards them with a remote-proxy or local-proxy context, respectively. Waters Experimental [Page 11] RFC 1910 User-based Security Model for SNMPv2 February 1996 For the non-proxy situation: context-A Manager <----------------> Agent the type of context is: +-----------------+ | context-A | +-----------------+-----------------+ | Manager | remote | +-----------------+-----------------+ | Agent | local | +-----------------+-----------------+ | agentID | of Agent | +-----------------+-----------------+ | contextSelector | locally unique | +-----------------+-----------------+ For proxy: context-B context-C Manager <----------------> Proxy <----------------> Agent Agent the type and identity of the contexts are: +-----------------+-----------------+ | context-B | context-C | +-----------------+-----------------+-----------------+ | Manager | remote | -- | +-----------------+-----------------+-----------------+ | Proxy-Agent | local-proxy | remote-proxy | +-----------------+-----------------+-----------------+ | Agent | -- | local | +-----------------+-----------------+-----------------+ | agentID | of Proxy agent | of Agent | +-----------------+-----------------+-----------------+ | contextSelector | locally unique | locally unique | +-----------------+-----------------+-----------------+ The combination of an agentID value and a context selector provides a globally-unique identification of a context. When a context is accessible by multiple agents (e.g., including by proxy SNMPv2 agents), it has multiple such globally-unique identifications, one associated with each agent which can access it. In the example above, "context-B" and "context-C" are different names for the same context. Waters Experimental [Page 12] RFC 1910 User-based Security Model for SNMPv2 February 1996 2.3. Quality of Service (qoS) Messages are generated with a particular Quality of Service (qoS), either: - without authentication and privacy, - with authentication but not privacy, - with authentication and privacy. All users are capable of having messages without authentication and privacy generated on their behalf. Users having an authentication protocol and an authentication key can have messages with authentication but not privacy generated on their behalf. Users having an authentication protocol, an authentication key, a privacy protocol and a privacy key can have messages with authentication and privacy generated on their behalf. In addition to its indications of authentication and privacy, the qoS may also indicate that the message contains an operation that may result in a report PDU being generated (see Section 2.6 below). 2.4. Access Policy An administration's access policy determines the access rights of users. For a particular SNMPv2 context to which a user has access using a particular qoS, that user's access rights are given by a list of authorized operations, and for a local context, a read-view and a write-view. The read-view is the set of object instances authorized for the user when reading objects. Reading objects occurs when processing a retrieval (get, get-next, get-bulk) operation and when sending a notification. The write-view is the set of object instances authorized for the user when writing objects. Writing objects occurs when processing a set operation. A user's access rights may be different at different agents. 2.5. Replay Protection Each SNMPv2 agent (or dual-role entity) maintains three objects: - agentID, which is an identifier unique among all agents in (at least) an administrative domain; - agentBoots, which is a count of the number of times the agent has rebooted/re-initialized since agentID was last configured; and, Waters Experimental [Page 13] RFC 1910 User-based Security Model for SNMPv2 February 1996 - agentTime, which is the number of seconds since agentBoots was last incremented. An SNMPv2 agent is always authoritative with respect to these variables. It is the responsibility of an SNMPv2 manager to synchronize with the agent, as appropriate. In the case of an SNMPv2 dual-role entity sending an Inform-Request, it is that entity acting in an agent role which is authoritative with respect to these variables for the Inform-Request. An agent is required to maintain the values of agentID and agentBoots in non-volatile storage. 2.5.1. agentID The agentID value contained in an authenticated message is used to defeat attacks in which messages from a manager are replayed to a different agent and/or messages from one agent (or dual-role entity) are replayed as if from a different agent (or dual-role entity). When an agent (or dual-role entity) is first installed, it sets its local value of agentID according to a enterprise-specific algorithm (see the definition of agentID in Section 4.1). 2.5.2. agentBoots and agentTime The agentBoots and agentTime values contained in an authenticated message are used to defeat attacks in which messages are replayed when they are no longer valid. Through use of agentBoots and agentTime, there is no requirement for an SNMPv2 agent to have a non-volatile clock which ticks (i.e., increases with the passage of time) even when the agent is powered off. Rather, each time an SNMPv2 agent reboots, it retrieves, increments, and then stores agentBoots in non-volatile storage, and resets agentTime to zero. When an agent (or dual-role entity) is first installed, it sets its local values of agentBoots and agentTime to zero. If agentTime ever reaches its maximum value (2147483647), then agentBoots is incremented as if the agent has rebooted and agentTime is reset to zero and starts incrementing again. Each time an agent (or dual-role entity) reboots, any SNMPv2 managers holding that agent's values of agentBoots and agentTime need to re- synchronize prior to sending correctly authenticated messages to that agent (see Section 2.7 for re-synchronization procedures). Note, however, that the procedures do provide for a notification to be accepted as authentic by a manager, when sent by an agent which has rebooted since the manager last re-synchronized. Waters Experimental [Page 14] RFC 1910 User-based Security Model for SNMPv2 February 1996 If an agent (or dual-role entity) is ever unable to determine its latest agentBoots value, then it must set its agentBoots value to 0xffffffff. Whenever the local value of agentBoots has the value 0xffffffff, it latches at that value and an authenticated message always causes an usecStatsNotInWindows authentication failure. In order to reset an agent whose agentBoots value has reached the value 0xffffffff, manual intervention is required. The agent must be physically visited and re-configured, either with a new agentID value, or with new secret values for the authentication and privacy keys of all users known to that agent. 2.5.3. Time Window The Time Window is a value that specifies the window of time in which a message generated on behalf of any user is valid. This memo specifies that the same value of the Time Window, 150 seconds, is used for all users. 2.6. Error Reporting While processing a received communication, an SNMPv2 entity may determine that the message is unacceptable (see Section 3.2). In this case, the appropriate counter from the snmpGroup [15] or usecStatsGroup object groups is incremented and the received message is discarded without further processing. If an SNMPv2 entity acting in the agent role makes such a determination and the qoS indicates that a report may be generated, then after incrementing the appropriate counter, it is required to generate a message containing a report PDU, with the same user and context as the received message, and to send it to the transport address which originated the received message. For all report PDUs, except those generated due to incrementing the usecStatsNotInWindows counter, the report PDU is unauthenticated. For those generated due to incrementing usecStatsNotInWindows, the report PDU is authenticated only if the received message was authenticated. The report flag in the qoS may only be set if the message contains a Get, GetNext, GetBulk, Set operation. The report flag should never be set for a message that contains a Response, Inform, SNMPv2-Trap or Report operation. Furthermore, a report PDU is never sent by an SNMPv2 entity acting in a manager role. Waters Experimental [Page 15] RFC 1910 User-based Security Model for SNMPv2 February 1996 2.7. Time Synchronization Time synchronization, required by a management entity in order to proceed with authentic communications, has occurred when the management entity has obtained local values of agentBoots and agentTime from the agent that are within the agent's time window. To remain synchronized, the local values must remain within the agent's time window and thus must be kept loosely synchronized with the values stored at the agent. In addition to keeping a local version of agentBoots and agentTime, a manager must also keep one other local variable, latestReceivedAgentTime. This value records the highest value of agentTime that was received by the manager from the agent and is used to eliminate the possibility of replaying messages that would prevent the manager's notion of the agentTime from advancing. Time synchronization occurs as part of the procedures of receiving a message (Section 3.2, step 9d). As such, no explicit time synchronization procedure is required by a management entity. Note, that whenever the local value of agentID is changed (e.g., through discovery) or when a new secret is configured, the local values of agentBoots and latestReceivedAgentTime should be set to zero. This will cause the time synchronization to occur when the next authentic message is received. 2.8. Proxy Error Propagation When a proxy SNMPv2 agent receives a report PDU from a proxied agent and it is determined that a proxy-forwarded request cannot be delivered to the proxied agent, then the snmpProxyDrops counter [15] is incremented and a report PDU is generated and transmitted to the transport address from which the original request was received. (Note that the receipt of a report PDU containing snmpProxyDrops as a VarBind, is included among the reasons why a proxy-forwarded request cannot be delivered.) 2.9. SNMPv2 Messages Using this Model The syntax of an SNMPv2 message using this security model differs from that of an SNMPv1 [2] message as follows: - The version component is changed to 2. - The data component contains either a PDU or an OCTET STRING containing an encrypted PDU. The SNMPv1 community string is now termed the "parameters" component and contains a set of administrative information for the message. Waters Experimental [Page 16] RFC 1910 User-based Security Model for SNMPv2 February 1996 Only the PDU is protected from disclosure by the privacy protocol. This exposes the administrative information to eavesdroppers. However, malicious use of this information is considered to be a Traffic Analysis attack against which protection is not provided. For an authenticated SNMPv2 message, the message digest is applied to the entire message given to the transport service. As such, message generation first privatizes the PDU, then adds the message wrapper, and then authenticates the message. An SNMPv2 message is an ASN.1 value with the following syntax: Message ::= SEQUENCE { version INTEGER { v2 (2) }, parameters OCTET STRING, -- -- -- -- data CHOICE { plaintext PDUs, encrypted OCTET STRING } } where: parameters a concatenation of the following values in network-byte order. If the first octet () is one, then = 8-bits of quality-of-service bitnumber 7654 3210 meaning ---- ---- -------------------------------- .... ..00 no authentication nor privacy .... ..01 authentication, no privacy .... ..1. authentication and privacy .... .1.. generation of report PDU allowed Waters Experimental [Page 17] RFC 1910 User-based Security Model for SNMPv2 February 1996 where bit 7 is the most significant bit. = 12 octets a unique identifier for the agent (or dual-role entity). = 32-bits an unsigned quantity (0..4294967295) in network-byte order. = 32-bits an unsigned quantity (0..2147483647) in network-byte order. = 16-bits an unsigned quantity (484..65507) in network-byte order, which identifies the maximum message size which the sender of this message can receive using the same transport domain as used for this message. = 1 octet the length of following field. = 1..16 arbitrary octets the user on whose behalf this message is sent. = 1 octet the length of following field. = 0..255 octets for authenticated messages, the authentication digest. Otherwise, the value has zero-length on transmission and is ignored on receipt. = 0..40 arbitrary octets the context selector which in combination with agentID identifies the SNMPv2 context containing the management information referenced by the SNMPv2 message. plaintext an SNMPv2 PDU as defined in [12]. encrypted the encrypted form of an SNMPv2 PDU. 2.10. Local Configuration Datastore (LCD) Each SNMPv2 entity maintains a local conceptually database, called the Local Configuration Datastore (LCD), which holds its known set of information about SNMPv2 users and other associated (e.g., access control) information. An LCD may potentially be required to hold Waters Experimental [Page 18] RFC 1910 User-based Security Model for SNMPv2 February 1996 information about multiple SNMPv2 agent entities. As such, the should be used to identify a particular agent entity in the LCD. It is a local implementation issue as to whether information in the LCD is stored information or whether it is obtained dynamically (e.g., as a part of an SNMPv2 manager's API) on an as-needed basis. 3. Elements of Procedure This section describes the procedures followed by an SNMPv2 entity in processing SNMPv2 messages. 3.1. Generating a Request or Notification This section describes the procedure followed by an SNMPv2 entity whenever it generates a message containing a management operation (either a request or a notification) on behalf of a user, for a particular context and with a particular qoS value. (1) Information concerning the user is extracted from the LCD. The transport domain and transport address to which the operation is to be sent is determined. The context is resolved into an agentID value and a contextSelector value. (2) If the qoS specifies that the message is to be protected from disclosure, but the user does not support both an authentication and a privacy protocol, or does not have configured authentication and privacy keys, then the operation cannot be sent. (3) If the qoS specifies that the message is to be authenticated, but the user does not support an authentication protocol, or does not have a configured authentication key, then the operation cannot be sent. (4) The operation is serialized (i.e., encoded) according to the conventions of [13] and [12] into a PDUs value. (5) If the operation is a Get, GetNext, GetBulk, or Set then the report flag in the qoS is set to the value 1. (6) An SNMPv2 message is constructed using the ASN.1 Message syntax: - the version component is set to the value 2. - if the qoS specifies that the message is to be protected from disclosure, then the octet sequence representing the serialized PDUs value is encrypted according to the user's privacy protocol Waters Experimental [Page 19] RFC 1910 User-based Security Model for SNMPv2 February 1996 and privacy key, and the encrypted data is encoded as an octet string and is used as the data component of the message. - if the qoS specifies that the message is not to be protected from disclosure, then the serialized PDUs value is used directly as the value of the data component. - the parameters component is constructed using: - the requested qoS, userName, agentID and context selector, - if the qoS specifies that the message is to be authenticated or the management operation is a notification, then the current values of agentBoots, and agentTime corresponding to agentID from the LCD are used. Otherwise, the and fields are set to zero-filled octets. - the field is set to the maximum message size which the local SNMPv2 entity can receive using the transport domain which will be used to send this message. - if the qoS specifies that the message is to be authenticated, then the field is temporarily set to the user's authentication key. Otherwise, the field is set to the zero-length string. (7) The constructed Message value is serialized (i.e., encoded) according to the conventions of [13] and [12]. (8) If the qoS specifies that the message is to be authenticated, then an MD5 digest value is computed over the octet sequence representing the concatenation of the serialized Message value and the user's authentication key. The field is then set to the computed digest value. (9) The serialized Message value is transmitted to the determined transport address. 3.2. Processing a Received Communication This section describes the procedure followed by an SNMPv2 entity whenever it receives an SNMPv2 message. This procedure is independent of the transport service address at which the message was received. For clarity, some of the details of this procedure are left out and are described in Section 3.2.1 and its sub-sections. (1) The snmpInPkts counter [15] is incremented. If the received message is not the serialization (according to the conventions of Waters Experimental [Page 20] RFC 1910 User-based Security Model for SNMPv2 February 1996 [13]) of a Message value, then the snmpInASNParseErrs counter [15] is incremented, and the message is discarded without further processing. (2) If the value of the version component has a value other than 2, then the message is either processed according to some other version of this protocol, or the snmpInBadVersions counter [15] is incremented, and the message is discarded without further processing. (3) The value of the field is extracted from the parameters component of the Message value. If the value of the field is not 1, then either the message is processed according to some other security model, or the usecStatsBadParameters counter is incremented, and the message is discarded without further processing. (4) The values of the rest of the fields are extracted from the parameters component of the Message value. (5) If the field contained in the parameters is unknown then: - a manager that performs discovery may optionally create a new LCD entry and continue processing; or - the usecStatsUnknownContexts counter is incremented, a report PDU is generated, and the received message is discarded without further processing. (6) The LCD is consulted for information about the SNMPv2 context identified by the combination of the and fields. If information about this SNMPv2 context is absent from the LCD, then the usecStatsUnknownContexts counter is incremented, a report PDU is generated, and the received message is discarded without further processing. (7) Information about the value of the field is extracted from the LCD. If no information is available, then the usecStatsUnknownUserNames counter is incremented, a report PDU [1] is generated, and the received message is discarded without further processing. (8) If the information about the user indicates that it does not support the quality of service indicated by the field, then the usecStatsUnsupportedQoS counter is incremented, a report PDU is generated, and the received message is discarded without further processing. Waters Experimental [Page 21] RFC 1910 User-based Security Model for SNMPv2 February 1996 (9) If the field indicates an authenticated message and the user's authentication protocol is the Digest Authentication Protocol described in this memo, then: a) the local values of agentBoots and agentTime corresponding to the value of the field are extracted from the LCD. b) the value of field is temporarily saved. A new serialized Message is constructed which differs from that received in exactly one respect: that the field within it has the value of the user's authentication key. An MD5 digest value is computed over the octet sequence representing the concatenation of the new serialized Message and the user's authentication key. c) if the LCD information indicates the SNMPv2 context is of type local (i.e., an agent), then: - if the computed digest differs from the saved authDigest value, then the usecStatsWrongDigestValues counter is incremented, a report PDU is generated, and the received message is discarded without further processing. However, if the snmpEnableAuthenTraps object [15] is enabled, then the SNMPv2 entity sends authenticationFailure traps [15] according to its configuration. - if any of the following conditions is true, then the message is considered to be outside of the Time Window: - the local value of agentBoots is 0xffffffff; - the field differs from the local value of agentBoots; or, - the value of the field differs from the local notion of agentTime by more than +/- 150 seconds. - if the message is considered to be outside of the Time Window then the usecStatsNotInWindows counter is incremented, an authenticated report PDU is generated (see section 2.7), and the received message is discarded without further processing. d) if the LCD information indicates the SNMPv2 context is not realized by the local SNMPv2 entity (i.e., a manager), then: - if the computed digest differs from the saved authDigest value, then the usecStatsWrongDigestValues counter is incremented and the received message is discarded without Waters Experimental [Page 22] RFC 1910 User-based Security Model for SNMPv2 February 1996 further processing. - if all of the following conditions are true: - if the field indicates that privacy is not in use; - the SNMPv2 operation type determined from the ASN.1 tag value associated with the PDU's component is a Report; - the Report was generated due to a usecStatsNotInWindows error condition; and, - the field is greater than the local value of agentBoots, or the field is equal to the local value of agentBoots and the field is greater than the value of latestReceivedAgentTime, then the LCD entry corresponding to the value of the field is updated, by setting the local value of agentBoots from the field, the value latestReceivedAgentTime from the field, and the local value of agentTime from the field. - if any of the following conditions is true, then the message is considered to be outside of the Time Window: - the local value of agentBoots is 0xffffffff; - the field is less than the local value of agentBoots; or, - the field is equal to the local value of agentBoots and the field is more than 150 seconds less than the local notion of agentTime. - if the message is considered to be outside of the Time Window then the usecStatsNotInWindows counter is incremented, and the received message is discarded without further processing; however, time synchronization procedures may be invoked. Note that this procedure allows for to be greater than the local value of agentBoots to allow for received messages to be accepted as authentic when received from an agent that has rebooted since the manager last re-synchronized. - if at least one of the following conditions is true: - the field is greater than the local value of agentBoots; or, Waters Experimental [Page 23] RFC 1910 User-based Security Model for SNMPv2 February 1996 - the field is equal to the local value of agentBoots and the field is greater than the value of latestReceivedAgentTime, then the LCD entry corresponding to the value of the field is updated, by setting the local value of agentBoots from the field, the local value latestReceivedAgentTime from the field, and the local value of agentTime from the field. (10) If the field indicates use of a privacy protocol, then the octet sequence representing the data component is decrypted according to the user's privacy protocol to obtain a serialized PDUs value. Otherwise the data component is assumed to directly contain the PDUs value. (11) The SNMPv2 operation type is determined from the ASN.1 tag value associated with the PDUs component. (12) If the SNMPv2 operation type is a Report, then the request-id in the PDU is correlated to an outstanding request, and if the correlation is successful, the appropriate action is taken (e.g., time synchronization, proxy error propagation, etc.); in particular, if the report PDU indicates a usecStatsNotInWindows condition, then the outstanding request may be retransmitted (since the procedure in Step 9d above should have resulted in time synchronization). (13) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or Set operation, then: a) if the LCD information indicates that the SNMPv2 context is of type remote or remote-proxy, then the usecStatsUnauthorizedOperations counter is incremented, a report PDU is generated, and the received message is discarded without further processing. b) the LCD is consulted for access rights authorized for communications using the indicated qoS, on behalf of the indicated user, and concerning management information in the indicated SNMPv2 context for the particular SNMPv2 operation type. c) if the SNMPv2 operation type is not among the authorized access rights, then the usecStatsUnauthorizedOperations counter is incremented, a report PDU is generated, and the received message is discarded without further processing. Waters Experimental [Page 24] RFC 1910 User-based Security Model for SNMPv2 February 1996 d) The information extracted from the LCD concerning the user and the SNMPv2 context, together with the sending transport address of the received message is cached for later use in generating a response message. e) if the LCD information indicates the SNMPv2 context is of type local, then the management operation represented by the PDUs value is performed by the receiving SNMPv2 entity with respect to the relevant MIB view within the SNMPv2 context according to the procedures set forth in [12], where the relevant MIB view is determined according to the user, the agentID, the contextSelector, the qoS values and the type of operation requested. f) if the LCD information indicates the SNMPv2 context is of type local-proxy, then: i. the user, qoS, agentID, contextSelector and transport address to be used to forward the request are extracted from the LCD. If insufficient information concerning the user is currently available, then snmpProxyDrops counter [15] is incremented, a report PDU is generated, and the received message is discarded. ii. if an administrative flag in the LCD indicates that the message is to be forwarded using the SNMPv1 administrative framework, then the procedures described in [4] are invoked. Otherwise, a new SNMPv2 message is constructed: its PDUs component is copied from that in the received message except that the contained request-id is replaced by a unique value (this value will enable a subsequent response message to be correlated with this request); the , , and fields are set to the values extracted from the LCD; the field is set to the minimum of the value in the received message and the local system's maximum message size for the transport domain which will be used to forward the message; and finally, the message is authenticated and/or protected from disclosure according to the qoS value. iii. the information cached in Step 13d above is augmented with the request-id of the received message as well as the request-id, agentID and contextSelector of the constructed message. iv. the constructed message is forwarded to the extracted transport address. Waters Experimental [Page 25] RFC 1910 User-based Security Model for SNMPv2 February 1996 (14) If the SNMPv2 operation type is an Inform, then: a) if the LCD information indicates the SNMPv2 context is of type local or local-proxy then the usecStatsUnauthorizedOperations counter is incremented, a report PDU is generated, and the received message is discarded without further processing. b) if the LCD information indicates the SNMPv2 context is of type remote, then the Inform operation represented by the PDUs value is performed by the receiving SNMPv2 entity according to the procedures set forth in [12]. c) if the LCD information indicates the SNMPv2 context is of type remote-proxy, then: i. a single unique request-id is selected for use by all forwarded copies of this request. This value will enable the first response message to be correlated with this request; other responses are not required and should be discarded when received, since the agent that originated the Inform only requires one response to its Inform. ii. information is extracted from the LCD concerning all combinations of userName, qoS, agentID, contextSelector and transport address with which the received message is to be forwarded. iii. for each such combination whose access rights permit Inform operations to be forwarded, a new SNMPv2 message is constructed, as follows: its PDUs component is copied from that in the received message except that the contained request-id is replaced by the value selected in Step i above; its , , and fields are set to the values extracted in Step ii above; and its field is set to the minimum of the value in the received message and the local system's maximum message size for the transport domain which will be used to forward this message. iv. for each constructed SNMPv2 message, information concerning the , , , , request-id and sending transport address of the received message, as well as the request- id, agentID and contextSelector of the constructed message, is cached for later use in generating a response message. v. each constructed message is forwarded to the appropriate transport address extracted from the LCD in step ii above. Waters Experimental [Page 26] RFC 1910 User-based Security Model for SNMPv2 February 1996 (15) If the SNMPv2 operation type is a Response, then: a) if the LCD information indicates the SNMPv2 context is of type local, then the usecStatsUnauthorizedOperations counter is incremented, a report PDU is generated, and the received message is discarded without further processing. b) if the LCD information indicates the SNMPv2 context is of type remote, then the Response operation represented by the PDUs value is performed by the receiving SNMPv2 entity according to the procedures set forth in [12]. c) if the LCD information indicates the SNMPv2 context is of type local-proxy or remote-proxy, then: i. the request-id is extracted from the PDUs component of the received message. The context's agentID and contextSelector values together with the extracted request-id are used to correlate this response message to the corresponding values for a previously forwarded request by inspecting the cache of information as augmented in Substep iii of Step 13f above or in Substep iv of 14c above. If no such correlated information is found, then the received message is discarded without further processing. ii. a new SNMPv2 message is constructed: its PDUs component is copied from that in the received message except that the contained request-id is replaced by the value saved in the correlated information from the original request; its , , and fields are set to the values saved from the received message. The field is set to the minimum of the value in the received message and the local system's maximum message size for the transport domain which will be used to forward the message. The message is authenticated and/or protected from disclosure according to the saved qoS value. iii. the constructed message is forwarded to the transport address saved in the correlated information as the sending transport address of the original request. iv. the correlated information is deleted from the cache of information. (16) If the SNMPv2 operation type is a SNMPv2-Trap, then: a) if the LCD information indicates the SNMPv2 context is of type local or local-proxy, then the usecStatsUnauthorizedOperations Waters Experimental [Page 27] RFC 1910 User-based Security Model for SNMPv2 February 1996 counter is incremented, a report PDU is generated, and the received message is discarded without further processing. b) if the LCD information indicates the SNMPv2 context is of type remote, then the SNMPv2-Trap operation represented by the PDUs value is performed by the receiving SNMPv2 entity according to the procedures set forth in [12]. c) if the LCD information indicates the SNMPv2 context is of type remote-proxy, then: i. a unique request-id is selected for use in forwarding the message. ii. information is extracted from the LCD concerning all combinations of userName, qoS, agentID, contextSelector and transport address with which the received message is to be forwarded. iii. for each such combination whose access rights permit SNMPv2-Trap operations to be forwarded, a new SNMPv2 message is constructed, as follows: its PDUs component is copied from that in the received message except that the contained request-id is replaced by the value selected in Step i above; its , , and fields are set to the values extracted in Step ii above. iv. each constructed message is forwarded to the appropriate transport address extracted from the LCD in step ii above. 3.2.1. Additional Details For the sake of clarity and to prevent the above procedure from being even longer, the following details were omitted from the above procedure. 3.2.1.1. ASN.1 Parsing Errors For ASN.1 parsing errors, the snmpInASNParseErrs counter [15] is incremented and a report PDU is generated whenever such an ASN.1 parsing error is discovered. However, if the parsing error causes the information able to be extracted from the message to be insufficient for generating a report PDU, then the report PDU is not sent. Waters Experimental [Page 28] RFC 1910 User-based Security Model for SNMPv2 February 1996 3.2.1.2. Incorrectly Encoded Parameters For an incorrectly encoded parameters component of the Message value (e.g., incorrect or inconsistent value of the or fields), the usecStatsBadParameters counter is incremented. Since the encoded parameters are in error, the report flag in the qoS cannot be reliably determined. Thus, no report PDU is generated for the incorrectly encoded parameters error condition. 3.2.1.3. Generation of a Report PDU Some steps specify that the received message is discarded without further processing whenever a report PDU is generated. However: - An SNMPv2 manager never generates a report PDU. - If the operation type can reliably be determined and it is determined to be a Report, SNMPv2-Trap, Inform, or a Response then a report PDU is not generated. - A report PDU is only generated when the report flag in the qoS is set to the value 1. A generated report PDU must always use the current values of agentID, agentBoots, and agentTime from the LCD. In addition, a generated report PDU must whenever possible contain the same request-id value as in the PDU contained in the received message. Meeting this constraint normally requires the message to be further processed just enough so as to extract its request-id. There are two situations in which the SNMPv2 request-id cannot be determined. The first situation occurs when the userName is unknown and the qoS indicates that the message is encrypted. The other situation is when there is an ASN.1 parsing error. In cases where the the request-id cannot be determined, the default request-id value 2147483647 is used. 3.2.1.4. Cache Timeout Some steps specify that information is cached so that a Response operation may be correlated to the appropriate Request operation. However, a number of situations could cause the cache to grow without bound. One such situation is when the Response operation does not arrive or arrives "late" at the entity. In order to ensure that the cache does not grow without bound, it is recommended that cache entries be deleted when they are determined to be no longer valid. It is an implementation dependent decision as to how long cache entries remain valid, however, caching entries more than 150 seconds is not useful since any use of the cache entry after that time would generate a usecStatsNotInWindows error condition. Waters Experimental [Page 29] RFC 1910 User-based Security Model for SNMPv2 February 1996 3.3. Generating a Response The procedure for generating a response to an SNMPv2 management request is identical to the procedure for transmitting a request (see Section 3.1), with these exceptions: - The response is sent on behalf of the same user and with the same value of the agentID and contextSelector as the request. - The PDUs value of the responding Message value is the response which results from performing the operation specified in the original PDUs value. - The authentication protocol and other relevant information for the user is obtained, not from the LCD, but rather from information cached (in Step 13d) when processing the original message. - The serialized Message value is transmitted using any transport address belonging to the agent for the transport domain from which the corresponding request originated - even if that is different from any transport information obtained from the LCD. - If the qoS specifies that the message is to be authenticated or the response is being generated by a SNMPv2 entity acting in an agent role, then the current values of agentBoots and agentTime from the LCD are used. Otherwise, the and fields are set to zero-filled octets. - The report flag in the qoS is set to the value 0. 4. Discovery This security model requires that a discovery process obtain sufficient information about an SNMPv2 entity's agent in order to communicate with it. Discovery requires the SNMPv2 manager to learn the agent's agentID value before communication may proceed. This may be accomplished by formulating a get-request communication with the qoS set to noAuth/noPriv, the userName set to "public", the agentID set to all zeros (binary), the contextSelector set to "", and the VarBindList left empty. The response to this message will be an reportPDU that contains the agentID within the field (and containing the usecStatsUnknownContexts counter in the VarBindList). If authenticated communication is required then the discovery process may invoke the procedure described in Section 2.7 to synchronize the clocks. Waters Experimental [Page 30] RFC 1910 User-based Security Model for SNMPv2 February 1996 5. Definitions SNMPv2-USEC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; usecMIB MODULE-IDENTITY LAST-UPDATED "9601120000Z" ORGANIZATION "IETF SNMPv2 Working Group" CONTACT-INFO " Glenn W. Waters Postal: Bell-Northern Research, Ltd. P.O. Box 3511, Station C Ottawa, ON, K1Y 4H7 Canada Tel: +1 613 763 3933 E-mail: gwaters@bnr.ca" DESCRIPTION "The MIB module for SNMPv2 entities implementing the user- based security model." ::= { snmpModules 6 } usecMIBObjects OBJECT IDENTIFIER ::= { usecMIB 1 } -- Textual Conventions AgentID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An agent's administratively-unique identifier. The value for this object may not be all zeros or all 'ff'H. The initial value for this object may be configured via an operator console entry or via an algorithmic function. In Waters Experimental [Page 31] RFC 1910 User-based Security Model for SNMPv2 February 1996 the later case, the following guidelines are recommended: 1) The first four octets are set to the binary equivalent of the agent's SNMP network management private enterprise number as assigned by the Internet Assigned Numbers Authority (IANA). For example, if Acme Networks has been assigned { enterprises 696 }, the first four octets would be assigned '000002b8'H. 2) The remaining eight octets are the cookie whose contents are determined via one or more enterprise- specific methods. Such methods must be designed so as to maximize the possibility that the value of this object will be unique in the agent's administrative domain. For example, the cookie may be the IP address of the agent, or the MAC address of one of the interfaces, with each address suitably padded with random octets. If multiple methods are defined, then it is recommended that the cookie be further divided into one octet that indicates the method being used and seven octets which are a function of the method." SYNTAX OCTET STRING (SIZE (12)) -- the USEC Basic group -- -- a collection of objects providing basic instrumentation of -- the SNMPv2 entity implementing the user-based security model usecAgent OBJECT IDENTIFIER ::= { usecMIBObjects 1 } agentID OBJECT-TYPE SYNTAX AgentID MAX-ACCESS read-only STATUS current DESCRIPTION "The agent's administratively-unique identifier." ::= { usecAgent 1 } agentBoots OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the agent has re-initialized itself since its initial configuration." ::= { usecAgent 2 } Waters Experimental [Page 32] RFC 1910 User-based Security Model for SNMPv2 February 1996 agentTime OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds since the agent last incremented the agentBoots object." ::= { usecAgent 3 } agentSize OBJECT-TYPE SYNTAX INTEGER (484..65507) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum length in octets of an SNMPv2 message which this agent will accept using any transport mapping." ::= { usecAgent 4 } -- USEC statistics -- -- a collection of objects providing basic instrumentation of -- the SNMPv2 entity implementing the user-based security model usecStats OBJECT IDENTIFIER ::= { usecMIBObjects 2 } usecStatsUnsupportedQoS OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv2 entity which were dropped because they requested a quality-of- service that was unknown to the agent or otherwise unavailable." ::= { usecStats 1 } usecStatsNotInWindows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv2 entity which were dropped because they appeared outside of the agent's window." ::= { usecStats 2 } Waters Experimental [Page 33] RFC 1910 User-based Security Model for SNMPv2 February 1996 usecStatsUnknownUserNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv2 entity which were dropped because they referenced a user that was not known to the agent." ::= { usecStats 3 } usecStatsWrongDigestValues OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv2 entity which were dropped because they didn't contain the expected digest value." ::= { usecStats 4 } usecStatsUnknownContexts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv2 entity which were dropped because they referenced a context that was not known to the agent." ::= { usecStats 5 } usecStatsBadParameters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv2 entity which were dropped because the field was improperly encoded or had invalid syntax." ::= { usecStats 6 } usecStatsUnauthorizedOperations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv2 entity which were dropped because the PDU type referred to an operation that is invalid or not authorized." Waters Experimental [Page 34] RFC 1910 User-based Security Model for SNMPv2 February 1996 ::= { usecStats 7 } -- conformance information usecMIBConformance OBJECT IDENTIFIER ::= { usecMIB 2 } usecMIBCompliances OBJECT IDENTIFIER ::= { usecMIBConformance 1 } usecMIBGroups OBJECT IDENTIFIER ::= { usecMIBConformance 2 } -- compliance statements usecMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the SNMPv2 USEC model." MODULE -- this module MANDATORY-GROUPS { usecBasicGroup, usecStatsGroup } ::= { usecMIBCompliances 1 } -- units of conformance usecBasicGroup OBJECT-GROUP OBJECTS { agentID, agentBoots, agentTime, agentSize } STATUS current DESCRIPTION "A collection of objects providing identification, clocks, and capabilities of an SNMPv2 entity which implements the SNMPv2 USEC model." ::= { usecMIBGroups 1 } usecStatsGroup OBJECT-GROUP OBJECTS { usecStatsUnsupportedQoS, usecStatsNotInWindows, usecStatsUnknownUserNames, usecStatsWrongDigestValues, usecStatsUnknownContexts, usecStatsBadParameters, usecStatsUnauthorizedOperations } Waters Experimental [Page 35] RFC 1910 User-based Security Model for SNMPv2 February 1996 STATUS current DESCRIPTION "A collection of objects providing basic error statistics of an SNMPv2 entity which implements the SNMPv2 USEC model." ::= { usecMIBGroups 2 } END 6. Security Considerations 6.1. Recommended Practices This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo. - A management station must discard SNMPv2 responses for which neither the request-id component nor the represented management information corresponds to any currently outstanding request. Although it would be typical for a management station to do this as a matter of course, when using these security protocols it is significant due to the possibility of message duplication (malicious or otherwise). - A management station must generate unpredictable request-ids in authenticated messages in order to protect against the possibility of message duplication (malicious or otherwise). - A management station should perform time synchronization using authenticated messages in order to protect against the possibility of message duplication (malicious or otherwise). - When sending state altering messages to a managed agent, a management station should delay sending successive messages to the managed agent until a positive acknowledgement is received for the previous message or until the previous message expires. No message ordering is imposed by the SNMPv2. Messages may be received in any order relative to their time of generation and each will be processed in the ordered received. Note that when an authenticated message is sent to a managed agent, it will be valid for a period of time of approximately 150 seconds under normal circumstances, and is subject to replay during this period. Indeed, a management station must cope with the loss and re- ordering of messages resulting from anomalies in the network as a matter of course. Waters Experimental [Page 36] RFC 1910 User-based Security Model for SNMPv2 February 1996 However, a managed object, snmpSetSerialNo [15], is specifically defined for use with SNMPv2 set operations in order to provide a mechanism to ensure the processing of SNMPv2 messages occurs in a specific order. - The frequency with which the secrets of an SNMPv2 user should be changed is indirectly related to the frequency of their use. Protecting the secrets from disclosure is critical to the overall security of the protocols. Frequent use of a secret provides a continued source of data that may be useful to a cryptanalyst in exploiting known or perceived weaknesses in an algorithm. Frequent changes to the secret avoid this vulnerability. Changing a secret after each use is generally regarded as the most secure practice, but a significant amount of overhead may be associated with that approach. Note, too, in a local environment the threat of disclosure may be less significant, and as such the changing of secrets may be less frequent. However, when public data networks are the communication paths, more caution is prudent. 6.2. Defining Users The mechanisms defined in this document employ the notion of "users" having access rights. How "users" are defined is subject to the security policy of the network administration. For example, users could be individuals (e.g., "joe" or "jane"), or a particular role (e.g., "operator" or "administrator"), or a combination (e.g., "joe- operator", "jane-operator" or "joe-admin"). Furthermore, a "user" may be a logical entity, such as a manager station application or set of manager station applications, acting on behalf of a individual or role, or set of individuals, or set of roles, including combinations. Appendix A describes an algorithm for mapping a user "password" to a 16 octet value for use as either a user's authentication key or privacy key (or both). Passwords are often generated, remembered, and input by a human. Human-generated passwords may be less than the 16 octets required by the authentication and privacy protocols, and brute force attacks can be quite easy on a relatively short ASCII character set. Therefore, the algorithm is Appendix A performs a transformation on the password. If the Appendix A algorithm is used, agent implementations (and agent configuration applications) must ensure that passwords are at least 8 characters in length. Because the Appendix A algorithm uses such passwords (nearly) directly, it is very important that they not be easily guessed. It Waters Experimental [Page 37] RFC 1910 User-based Security Model for SNMPv2 February 1996 is suggested that they be composed of mixed-case alphanumeric and punctuation characters that don't form words or phrases that might be found in a dictionary. Longer passwords improve the security of the system. Users may wish to input multiword phrases to make their password string longer while ensuring that it is memorable. Note that there is security risk in configuring the same "user" on multiple systems where the same password is used on each system, since the compromise of that user's secrets on one system results in the compromise of that user on all other systems having the same password. The algorithm in Appendix A avoids this problem by including the agent's agentID value as well as the user's password in the calculation of a user's secrets; this results in the user's secrets being different at different agents; however, if the password is compromised the algorithm in Appendix A is not effective. 6.3. Conformance To be termed a "Secure SNMPv2 implementation", an SNMPv2 implementation: - must implement the Digest Authentication Protocol. - must, to the maximal extent possible, prohibit access to the secret(s) of each user about which it maintains information in a LCD, under all circumstances except as required to generate and/or validate SNMPv2 messages with respect to that user. - must implement the SNMPv2 USEC MIB. In addition, an SNMPv2 agent must provide initial configuration in accordance with Appendix A.1. Implementation of the Symmetric Encryption Protocol is optional. 7. Editor's Address Glenn W. Waters Bell-Northern Research Ltd. P.O. Box 3511, Station C Ottawa, Ontario K1Y 4H7 CA Phone: +1 613 763 3933 EMail: gwaters@bnr.ca Waters Experimental [Page 38] RFC 1910 User-based Security Model for SNMPv2 February 1996 8. Acknowledgements This document is the result of significant work by three major contributors: Keith McCloghrie (Cisco Systems, kzm@cisco.com) Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca) The authors wish to acknowledge James M. Galvin of Trusted Information Systems who contributed significantly to earlier work on which this memo is based, and the general contributions of members of the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov and Steven L. Waldbusser. A special thanks is extended for the contributions of: Uri Blumenthal (IBM) Shawn Routhier (Epilogue) Barry Sheehan (IBM) Bert Wijnen (IBM) 9. References [1] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC 1909, Cisco Systems, January 1996. [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992. [4] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [5] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988). [6] Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980). Waters Experimental [Page 39] RFC 1910 User-based Security Model for SNMPv2 February 1996 [7] DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980). [8] Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106-1983, (May 1983). [9] Guidelines for Implementing and Using the NBS Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 74, (April, 1981). [10] Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-20. [11] Maintenance Testing for the Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-61, (August, 1980). [12] The 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. [13] The 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. [14] Krawczyk, H., "Keyed-MD5 for Message Authentication", Work in Progress, IBM, June 1995. [15] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 January 1996. Waters Experimental [Page 40] RFC 1910 User-based Security Model for SNMPv2 February 1996 APPENDIX A - Installation A.1. Agent Installation Parameters During installation, an agent is configured with several parameters. These include: (1) a security posture The choice of security posture determines the extent of the view configured for unauthenticated access. One of three possible choices is selected: minimum-secure, semi-secure, or very-secure. (2) one or more transport service addresses These parameters may be specified explicitly, or they may be specified implicitly as the same set of network-layer addresses configured for other uses by the device together with the well- known transport-layer "port" information for the appropriate transport domain [13]. The agent listens on each of these transport service addresses for messages sent on behalf of any user it knows about. (3) one or more secrets These are the authentication/privacy secrets for the first user to be configured. One way to accomplish this is to have the installer enter a "password" for each required secret. The password is then algorithmically converted into the required secret by: - forming a string of length 1,048,576 octets by repeating the value of the password as often as necessary, truncating accordingly, and using the resulting string as the input to the MD5 algorithm. The resulting digest, termed "digest1", is used in the next step. - a second string of length 44 octets is formed by concatenating digest1, the agent's agentID value, and digest1. This string is used as input to the MD5 algorithm. The resulting digest is the required secret (see Appendix A.2). Waters Experimental [Page 41] RFC 1910 User-based Security Model for SNMPv2 February 1996 With these configured parameters, the agent instantiates the following user, context, views and access rights. This configuration information should be readOnly (persistent). - One user: privacy not supported privacy supported --------------------- ----------------- "public" "public" Digest Auth. Protocol Digest Auth. Protocol authentication key authentication key none Symmetric Privacy Protocol -- privacy key - One local context with its as the empty-string. - One view for authenticated access: - the MIB view is the "internet" subtree. - A second view for unauthenticated access. This view is configured according to the selected security posture. For the "very-secure" posture: - the MIB view is the union of the "snmp" [15], "usecAgent" and "usecStats" subtrees. For the "semi-secure" posture: - the MIB view is the union of the "snmp" [15], "usecAgent", "usecStats" and "system" subtrees. For the "minimum-secure" posture: - the MIB view is the "internet" subtree. - Access rights to allow: - read-only access for unauthenticated messages on behalf of the user "public" to the MIB view of contextSelector "". - read-write access for authenticated but not private messages on behalf of the user "public" to the MIB view of contextSelector "". - if privacy is supported, read-write access for authenticated and private messages on behalf of the user "public" to the Waters Experimental [Page 42] RFC 1910 User-based Security Model for SNMPv2 February 1996 MIB view of contextSelector "". A.2. Password to Key Algorithm The following code fragment demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key. (The calls to MD5 are as documented in RFC 1321.) void password_to_key(password, passwordlen, agentID, key) u_char *password; /* IN */ u_int passwordlen; /* IN */ u_char *agentID; /* IN - pointer to 12 octet long agentID */ u_char *key; /* OUT - caller supplies pointer to 16 octet buffer */ { MD5_CTX MD; u_char *cp, password_buf[64]; u_long password_index = 0; u_long count = 0, i; MD5Init (&MD); /* initialize MD5 */ /* loop until we've done 1 Megabyte */ while (count < 1048576) { cp = password_buf; for(i = 0; i < 64; i++) { *cp++ = password[ password_index++ % passwordlen ]; /* * Take the next byte of the password, wrapping to the * beginning of the password as necessary. */ } MDupdate (&MD, password_buf, 64); count += 64; } MD5Final (key, &MD); /* tell MD5 we're done */ /* localize the key with the agentID and pass through MD5 to produce final key */ memcpy (password_buf, key, 16); memcpy (password_buf+16, agentID, 12); memcpy (password_buf+28, key, 16); MD5Init (&MD); MDupdate (&MD, password_buf, 44); MD5Final (key, &MD); return; } Waters Experimental [Page 43] RFC 1910 User-based Security Model for SNMPv2 February 1996 A.3. Password to Key Sample The following shows a sample output of the password to key algorithm. With a password of "maplesyrup" the output of the password to key algorithm before the key is localized with the agent's agentID is: '9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H After the intermediate key (shown above) is localized with the agentID value of: '00 00 00 00 00 00 00 00 00 00 00 02'H the final output of the password to key algorithm is: '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H Waters Experimental [Page 44] snmp-mibs-downloader-1.1/mibrfcs/rfc2006.txt0000644000000000000000000027146611402176071015571 0ustar Network Working Group D. Cong & M. Hamlen, Editors Request for Comments: 2006 Motorola Category: Standards Track C. Perkins, Editor IBM October 1996 The Definitions of Managed Objects for IP Mobility Support using SMIv2 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. Abstract This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. Table of Contents 1. The Network Management Framework ...................... 2 2. Objects ............................................... 2 2.1 Object Definitions ................................... 2 3. Overview .............................................. 2 3.1 Object Selection Criteria ............................ 2 3.2 Structure of the Mobile IP ........................... 3 3.3 MIB Groups ........................................... 4 4. Definitions ........................................... 5 5. Acknowledgements ...................................... 49 6. Security Considerations ............................... 49 7. References ............................................ 50 8. Chair's Address ....................................... 51 9. Editors' Addresses .................................... 52 Cong, Hamlen & Perkins Standards Track [Page 1] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 1. The SNMP Network Management Framework The Internet-standard Network Management Framework presently consists of three major components. They are: The SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. The MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. The protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Objects 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 3.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, the authors have applied some criteria to select managed objects for the Mobile IP Protocol. (1) Partition management functionality among the Mobile Node, Home Agent, and Foreign Agent according to the partitioning seen in the Mobile IP Protocol. (2) Require that objects be essential for either fault or configuration management. (3) Limit the total number of objects. Cong, Hamlen & Perkins Standards Track [Page 2] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 (4) Exclude objects which are simply derivable from others in this or other MIBs. 3.2. Structure of the Mobile IP This section describes the basic model of Mobile IP used in developing the Mobile IP MIB. This information should be useful to the implementor in understanding some of the basic design decisions of the MIB. The Mobile IP Protocol introduces these new funtional entities: Mobile Node A host or router that changes its point of attachment from one network or subnetwork to another. A mobile node may change its location without losing connectivity and without changing its IP address; it may continue to communicate with other Internet nodes at any location using its (constant) IP address, assuming link- layer connectivity to a point of attachment is available. Home Agent A router on a mobile node's home network which tunnels packets for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. Foreign Agent A router on a mobile node's visited network which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers packets to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. This document specifies the objects used in managing these entities; namely, the Mobile Node, the Home Agent, and the Foreign Agent. Cong, Hamlen & Perkins Standards Track [Page 3] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 3.3. MIB Groups Objects in this MIB are arranged into groups. Each group is organized as a set of related objects. The overall structure and the relationship between groups and the Mobile IP entities are shown below: Groups Mobile Node Foreign Agent Home Agent mipSystemGroup X X X mipSecAssociationGroup X X X mipSecViolationGroup X X X mnSystemGroup X mnDiscoveryGroup X mnRegistrationGroup X maAdvertisementGroup X X faSystemGroup X faAdvertisementGroup X faRegistrationGroup X haRegistrationGroup X haRegNodeCountersGroup X Cong, Hamlen & Perkins Standards Track [Page 4] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 4. Definitions MIP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Gauge32, Integer32, IpAddress, experimental, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; mipMIB MODULE-IDENTITY LAST-UPDATED "9606040000Z" ORGANIZATION "IETF Mobile IP Working Group" CONTACT-INFO " David Cong Postal: Motorola 1301 E. Algonquin Rd. Schaumburg, IL 60196 Phone: +1-847-576-1357 Email: cong@comm.mot.com" DESCRIPTION "The MIB Module for the Mobile IP." ::= { mib-2 44 } mipMIBObjects OBJECT IDENTIFIER ::= { mipMIB 1 } -- Groups under mipMIBObjects mipSystem OBJECT IDENTIFIER ::= { mipMIBObjects 1 } mipSecurity OBJECT IDENTIFIER ::= { mipMIBObjects 2 } mipMN OBJECT IDENTIFIER ::= { mipMIBObjects 3 } mipMA OBJECT IDENTIFIER ::= { mipMIBObjects 4 } mipFA OBJECT IDENTIFIER ::= { mipMIBObjects 5 } mipHA OBJECT IDENTIFIER ::= { mipMIBObjects 6 } mnSystem OBJECT IDENTIFIER ::= { mipMN 1 } mnDiscovery OBJECT IDENTIFIER ::= { mipMN 2 } mnRegistration OBJECT IDENTIFIER ::= { mipMN 3 } maAdvertisement OBJECT IDENTIFIER ::= { mipMA 2 } faSystem OBJECT IDENTIFIER ::= { mipFA 1 } faAdvertisement OBJECT IDENTIFIER ::= { mipFA 2 } faRegistration OBJECT IDENTIFIER ::= { mipFA 3 } Cong, Hamlen & Perkins Standards Track [Page 5] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 haRegistration OBJECT IDENTIFIER ::= { mipHA 3 } -- Textual convention RegistrationFlags ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to define the registration flags for Mobile IP registration extension: vjCompression -- Request to use VJ compression gre -- Request to use GRE minEnc -- Request to use minimal encapsulation decapsulationByMN -- Decapsulation by mobile node broadcastDatagram -- Request to receive broadcasts simultaneoursBindings -- Request to retain prior binding(s)." SYNTAX BITS { vjCompression(0), gre(1), minEnc(2), decapsulationbyMN(3), broadcastDatagram(4), simultaneousBindings(5) } -- mipSystem Group mipEntities OBJECT-TYPE SYNTAX BITS { mobileNode(0), foreignAgent(1), homeAgent(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes which Mobile IP entities are supported by this managed entity. The entity may support more than one Mobile IP entities. For example, the entity supports both Foreign Agent (FA) and Home Agent (HA). Therefore, bit 1 and bit 2 are set to 1 for this object." ::= { mipSystem 1 } Cong, Hamlen & Perkins Standards Track [Page 6] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 mipEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the Mobile IP protocol should be enabled for the managed entity. If it is disabled, the entity should disable both agent discovery and registration functions." ::= { mipSystem 2 } mipEncapsulationSupported OBJECT-TYPE SYNTAX BITS { ipInIp(0), gre(1), minEnc(2), other(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Encapsulation methods supported by the Mobile IP entity. The entity may support multiple encapsulation methods or none of them: ipInIp(0), -- IP Encapsulation within IP gre(1), -- Generic Routing Encapsulation, -- refers to RFC1701 minEnc(2), -- Minimal Encapsulation within IP." ::= { mipSystem 3 } -- mipSecurity Group mipSecAssocTable OBJECT-TYPE SYNTAX SEQUENCE OF MipSecAssocEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Mobility Security Associations." ::= { mipSecurity 1 } mipSecAssocEntry OBJECT-TYPE SYNTAX MipSecAssocEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One particular Mobility Security Association." INDEX { mipSecPeerAddress, mipSecSPI } ::= { mipSecAssocTable 1 } Cong, Hamlen & Perkins Standards Track [Page 7] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 MipSecAssocEntry ::= SEQUENCE { mipSecPeerAddress IpAddress, mipSecSPI Unsigned32, mipSecAlgorithmType INTEGER, mipSecAlgorithmMode INTEGER, mipSecKey OCTET STRING, mipSecReplayMethod INTEGER } mipSecPeerAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the peer entity with which this node shares the mobility security association." ::= { mipSecAssocEntry 1 } mipSecSPI OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SPI is the 4-byte opaque index within the Mobility Security Association which selects the specific security parameters to be used to authenticate the peer, i.e. the rest of the variables in this MipSecAssocEntry." ::= { mipSecAssocEntry 2 } mipSecAlgorithmType OBJECT-TYPE SYNTAX INTEGER { other(1), md5(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Type of security algorithm." ::= { mipSecAssocEntry 3 } mipSecAlgorithmMode OBJECT-TYPE SYNTAX INTEGER { other(1), prefixSuffix(2) } MAX-ACCESS read-create Cong, Hamlen & Perkins Standards Track [Page 8] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 STATUS current DESCRIPTION "Security mode used by this algorithm." ::= { mipSecAssocEntry 4 } mipSecKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The shared secret key for the security associations. Reading this object will always return zero length value." ::= { mipSecAssocEntry 5 } mipSecReplayMethod OBJECT-TYPE SYNTAX INTEGER { other(1), timestamps(2), nonces(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The replay-protection method supported for this SPI within this Mobility Security Association." ::= { mipSecAssocEntry 6 } -- Mobile IP security violation total counter mipSecTotalViolations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of security violations in the entity" ::= { mipSecurity 2 } -- Mobile IP security violation table mipSecViolationTable OBJECT-TYPE SYNTAX SEQUENCE OF MipSecViolationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about security violations." ::= { mipSecurity 3 } Cong, Hamlen & Perkins Standards Track [Page 9] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 mipSecViolationEntry OBJECT-TYPE SYNTAX MipSecViolationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one particular security violation." INDEX { mipSecViolatorAddress } ::= { mipSecViolationTable 1 } MipSecViolationEntry ::= SEQUENCE { mipSecViolatorAddress IpAddress, mipSecViolationCounter Counter32, mipSecRecentViolationSPI Integer32, mipSecRecentViolationTime TimeStamp, mipSecRecentViolationIDLow Integer32, mipSecRecentViolationIDHigh Integer32, mipSecRecentViolationReason INTEGER } mipSecViolatorAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Violator's IP address. The violator is not necessary in the mipSecAssocTable." ::= { mipSecViolationEntry 1 } mipSecViolationCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of security violations for this peer." ::= { mipSecViolationEntry 2 } mipSecRecentViolationSPI OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "SPI of the most recent security violation for this peer. If the security violation is due to an identification mismatch, then this is the SPI from the Mobile-Home Authentication Extension. If the security violation is due to an invalid authenticator, then this is the SPI from the offending authentication Cong, Hamlen & Perkins Standards Track [Page 10] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 extension. In all other cases, it should be set to zero." ::= { mipSecViolationEntry 3 } mipSecRecentViolationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Time of the most recent security violation for this peer." ::= { mipSecViolationEntry 4 } mipSecRecentViolationIDLow OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Low-order 32 bits of identification used in request or reply of the most recent security violation for this peer." ::= { mipSecViolationEntry 5 } mipSecRecentViolationIDHigh OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "High-order 32 bits of identification used in request or reply of the most recent security violation for this peer." ::= { mipSecViolationEntry 6 } mipSecRecentViolationReason OBJECT-TYPE SYNTAX INTEGER { noMobilitySecurityAssociation(1), badAuthenticator(2), badIdentifier(3), badSPI(4), missingSecurityExtension(5), other(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Reason for the most recent security violation for this peer." ::= { mipSecViolationEntry 7 } Cong, Hamlen & Perkins Standards Track [Page 11] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 -- mipMN Group -- mipSystem Group mnState OBJECT-TYPE SYNTAX INTEGER { home(1), registered(2), pending(3), isolated(4), unknown(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates mobile node's state of Mobile IP: home, -- MN is connected to home network. registered, -- MN has registered on foreign network pending, -- MN has sent registration request and is waiting for the reply isolated, -- MN is isolated from network unknown -- MN can not determine its state." ::= { mnSystem 1 } mnHomeAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An IP address that is assigned for an extended period of time to the mobile node. It remains unchanged regardless of the mobile node's current point of attachment." ::= { mnSystem 2 } -- Mobile node's home agent list mnHATable OBJECT-TYPE SYNTAX SEQUENCE OF MnHAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Cong, Hamlen & Perkins Standards Track [Page 12] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 "A table containing all of the mobile node's potential home agents." ::= { mnSystem 3 } mnHAEntry OBJECT-TYPE SYNTAX MnHAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information for a particular Home Agent." INDEX { mnHAAddress } ::= { mnHATable 1 } MnHAEntry ::= SEQUENCE { mnHAAddress IpAddress, mnCurrentHA TruthValue, mnHAStatus RowStatus } mnHAAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address of mobile node's Home Agent." ::= { mnHAEntry 1 } mnCurrentHA OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether this home agent is the current home agent for the mobile node. If it is true, the mobile node is registered with that home agent." ::= { mnHAEntry 2 } mnHAStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status for this home agent entry. If the status is set to 'createAndGo' or 'active', then the mobile node can use mnHAAddress as a valid candidate for a home agent. If the status is set to 'destroy', then the mobile node should delete this row, and deregister from that home agent." Cong, Hamlen & Perkins Standards Track [Page 13] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 ::= { mnHAEntry 3 } mnFATable OBJECT-TYPE SYNTAX SEQUENCE OF MnFAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing all foreign agents that the mobile node knows about and their corresponding COA (care-of address). This COA is an address of a foreign agent with which the mobile node is registered. The table is updated when advertisements are received by the mobile node. If an advertisement expires, its entry(s) should be deleted from the table. One foreign agent can provide more than one COA in its advertisements." ::= { mnDiscovery 1 } mnFAEntry OBJECT-TYPE SYNTAX MnFAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One pair of foreign agent IP address and COA for that foreign agent." INDEX { mnFAAddress, mnCOA } ::= { mnFATable 1 } MnFAEntry ::= SEQUENCE { mnFAAddress IpAddress, mnCOA IpAddress } mnFAAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Foreign agent's IP address." ::= { mnFAEntry 1 } mnCOA OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A care-of address being offered by this foreign agent or a co-located care-of address which the mobile node has associated with one of its own network Cong, Hamlen & Perkins Standards Track [Page 14] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 interfaces." ::= { mnFAEntry 2 } -- Mobile node could store multiple agent advertisements, however, -- only the most recently received agent advertisement information -- is required to be made available to the manager station. mnRecentAdvReceived OBJECT IDENTIFIER ::= { mnDiscovery 2 } mnAdvSourceAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The source IP address of the most recently received Agent Advertisement. This address could be the address of a home agent or a foreign agent." ::= { mnRecentAdvReceived 1 } mnAdvSequence OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number of the most recently received advertisement. The sequence number ranges from 0 to 0xffff. After the sequence number attains the value 0xffff, it will roll over to 256." ::= { mnRecentAdvReceived 2 } mnAdvFlags OBJECT-TYPE SYNTAX BITS { vjCompression(0), gre(1), minEnc(2), foreignAgent(3), homeAgent(4), busy(5), regRequired(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The flags are contained in the 7th byte in the extension of the most recently received mobility agent advertisement: vjCompression -- Agent supports Van Jacobson compression Cong, Hamlen & Perkins Standards Track [Page 15] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 gre -- Agent offers Generice Routing Encapsulation minEnc, -- Agent offers Minimal Encapsulation foreignAgent, -- Agent is a Foreign Agent homeAgent, -- Agent is a Home Agent busy, -- Foreign Agent is busy regRequired, -- FA registration is required." ::= { mnRecentAdvReceived 3 } mnAdvMaxRegLifetime OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The longest lifetime in seconds that the agent is willing to accept in any registration request." ::= { mnRecentAdvReceived 4 } mnAdvMaxAdvLifetime OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum length of time that the Advertisement is considered valid in the absence of further Advertisements." REFERENCE "AdvertisementLifeTime in RFC1256." ::= { mnRecentAdvReceived 5 } mnAdvTimeReceived OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the most recently received advertisement was received." ::= { mnRecentAdvReceived 6 } -- Mobile Node Discovery Group Counter Cong, Hamlen & Perkins Standards Track [Page 16] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 mnSolicitationsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Solicitation sent by the mobile node." ::= { mnDiscovery 3 } mnAdvertisementsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of advertisements received by the mobile node." ::= { mnDiscovery 4 } mnAdvsDroppedInvalidExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of advertisements dropped by the mobile node due to both poorly formed extensions and unrecognized extensions with extension number in the range 0-127." ::= { mnDiscovery 5 } mnAdvsIgnoredUnknownExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of unrecognized extensions in the range 128-255 that were ignored by the mobile node." ::= { mnDiscovery 6 } mnMoveFromHAToFA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times that the mobile node has decided to move from its home network to a foreign network." ::= { mnDiscovery 7 } mnMoveFromFAToFA OBJECT-TYPE Cong, Hamlen & Perkins Standards Track [Page 17] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times that the mobile node has decided to move from one foreign network to another foreign network." ::= { mnDiscovery 8 } mnMoveFromFAToHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times that the mobile node has decided to move from a foreign network to its home network." ::= { mnDiscovery 9 } mnGratuitousARPsSend OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Gratuitous ARPs sent by mobile node in order to clear out any stale ARP entries in the ARP caches of nodes on the home network." ::= { mnDiscovery 10 } mnAgentRebootsDectected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of agent reboots detected by the mobile node through sequence number of the advertisement." ::= { mnDiscovery 11 } -- Mobile Node Registration Group -- Registration table of mobile node mnRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF MnRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about the mobile node's attempted registration(s). The mobile node Cong, Hamlen & Perkins Standards Track [Page 18] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 updates this table based upon Registration Requests sent and Registration Replies received in response to these requests. Certain variables within this table are also updated if when Registration Requests are retransmitted." ::= { mnRegistration 1 } mnRegistrationEntry OBJECT-TYPE SYNTAX MnRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one registration attempt." INDEX { mnRegAgentAddress, mnRegCOA} ::= { mnRegistrationTable 1 } MnRegistrationEntry ::= SEQUENCE { mnRegAgentAddress IpAddress, mnRegCOA IpAddress, mnRegFlags RegistrationFlags, mnRegIDLow Integer32, mnRegIDHigh Integer32, mnRegTimeRequested Integer32, mnRegTimeRemaining Gauge32, mnRegTimeSent TimeStamp, mnRegIsAccepted TruthValue, mnCOAIsLocal TruthValue } mnRegAgentAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP address of the agent as used in the destination IP address of the Registration Request. The agent may be a home agent or a foreign agent." ::= { mnRegistrationEntry 1 } mnRegCOA OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Care-of address for the registration." ::= { mnRegistrationEntry 2 } mnRegFlags OBJECT-TYPE Cong, Hamlen & Perkins Standards Track [Page 19] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 SYNTAX RegistrationFlags MAX-ACCESS read-only STATUS current DESCRIPTION "Registration flags sent by the mobile node. It is the second byte in the Mobile IP Registratation Request message." ::= { mnRegistrationEntry 3 } mnRegIDLow OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Low-order 32 bits of the Identification used in that registration by the mobile node." ::= { mnRegistrationEntry 4 } mnRegIDHigh OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "High-order 32 bits of the Identification used in that registration by the mobile node." ::= { mnRegistrationEntry 5 } mnRegTimeRequested OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the registration is pending, then this is the lifetime requested by the mobile node (in seconds). If the registration has been accepted, then this is the lifetime actually granted by the home agent in the reply." ::= { mnRegistrationEntry 6 } mnRegTimeRemaining OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds remaining until this registration expires. It has the same initial value Cong, Hamlen & Perkins Standards Track [Page 20] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 as mnRegTimeRequested and is only valid if mnRegIsAccepted is TRUE." ::= { mnRegistrationEntry 7 } mnRegTimeSent OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the last (re-)transmission occured." ::= { mnRegistrationEntry 8 } mnRegIsAccepted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1) if the mobile node has received a Registration Reply indicating that service has been accepted; false(2) otherwise. false(2) implies that the registration is still pending." ::= { mnRegistrationEntry 9 } mnCOAIsLocal OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the COA is local to (dynamically acquired by) the mobile node or not. If it is false(2), the COA is an address of the foreign agent." ::= { mnRegistrationEntry 10 } -- Mobile Node Registration Group Counters mnRegRequestsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of registration requests sent by the mobile node. This does not include deregistrations (those with Lifetime equal to zero)." ::= { mnRegistration 2 } mnDeRegRequestsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Cong, Hamlen & Perkins Standards Track [Page 21] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 STATUS current DESCRIPTION "Total number of deregistration requests sent by the mobile node (those with Lifetime equal to zero)." ::= { mnRegistration 3 } mnRegRepliesRecieved OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of registration replies received by the mobile node in which the Lifetime is greater than zero." ::= { mnRegistration 4 } mnDeRegRepliesRecieved OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of (de)registration replies received by the mobile node in which the Lifetime is equal to zero." ::= { mnRegistration 5 } mnRepliesInvalidHomeAddress OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of replies with invalid home address for the mobile node." ::= { mnRegistration 6 } mnRepliesUnknownHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of replies with unknown home agents (not in home agent table)." ::= { mnRegistration 7 } mnRepliesUnknownFA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Cong, Hamlen & Perkins Standards Track [Page 22] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 DESCRIPTION "Total number of replies with unknown foreign agents if replies relayed through foreign agent." ::= { mnRegistration 8 } mnRepliesInvalidID OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of replies with invalid Identification fields." ::= { mnRegistration 9 } mnRepliesDroppedInvalidExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Replies dropped by the mobile node due to both poorly formed extensions and unrecognized extensions with extension number in the range 0-127." ::= { mnRegistration 10 } mnRepliesIgnoredUnknownExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Replies that contained one or more unrecognized extensions in the range 128-255 that were ignored by the mobile node." ::= { mnRegistration 11 } mnRepliesHAAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of replies without a valid Home Agent to Mobile Node authenticator." ::= { mnRegistration 12 } mnRepliesFAAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Cong, Hamlen & Perkins Standards Track [Page 23] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 DESCRIPTION "Total number of replies without a valid Foreign Agent to Mobile Node authenticator." ::= { mnRegistration 13 } mnRegRequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of registration requests accepted by the mobile node's home agent (Code 0 and Code 1)." ::= { mnRegistration 14 } mnRegRequestsDeniedByHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of registration requests denied by mobile node's home agent (Sum of Code 128 through Code 191)." ::= { mnRegistration 15 } mnRegRequestsDeniedByFA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of registration requests denied by the foreign agent (Sum of Codes 64 through Code 127)." ::= { mnRegistration 16 } mnRegRequestsDeniedByHADueToID OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Request denied by home agent due to identification mismatch." ::= { mnRegistration 17 } mnRegRequestsWithDirectedBroadcast OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests sent by mobile Cong, Hamlen & Perkins Standards Track [Page 24] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 node with a directed broadcast address in the home agent field." ::= { mnRegistration 18 } -- MA Advertisement Group -- Mobility agent advertisement configuration table maAdvConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF MaAdvConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing configurable advertisement parameters for all advertisement interfaces in the mobility agent." ::= { maAdvertisement 1 } maAdvConfigEntry OBJECT-TYPE SYNTAX MaAdvConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Advertisement parameters for one advertisement interface." INDEX { maInterfaceAddress } ::= { maAdvConfigTable 1 } MaAdvConfigEntry ::= SEQUENCE { maInterfaceAddress IpAddress, maAdvMaxRegLifetime Integer32, maAdvPrefixLengthInclusion TruthValue, maAdvAddress IpAddress, maAdvMaxInterval Integer32, maAdvMinInterval Integer32, maAdvMaxAdvLifetime Integer32, maAdvResponseSolicitationOnly TruthValue, maAdvStatus RowStatus } maInterfaceAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address for advertisement interface." ::= { maAdvConfigEntry 1 } Cong, Hamlen & Perkins Standards Track [Page 25] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 maAdvMaxRegLifetime OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The longest lifetime in seconds that mobility agent is willing to accept in any Registration Request." ::= { maAdvConfigEntry 2 } maAdvPrefixLengthInclusion OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Whether the advertisement should include the Prefix- Lengths Extension. If it is true, all advertisements sent over this interface should include the Prefix-Lengths Extension." ::= { maAdvConfigEntry 3 } maAdvAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP destination address to be used for advertisements sent from the interface. The only permissible values are the all-systems multicast address (224.0.0.1) or the limited-broadcast address (255.255.255.255)." REFERENCE "AdvertisementAddress in RFC1256." ::= { maAdvConfigEntry 4 } maAdvMaxInterval OBJECT-TYPE SYNTAX Integer32 (4..1800) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum time in seconds between successive transmissions of Agent Advertisements from this interface." REFERENCE "MaxAdvertisementInterval in RFC1256." ::= { maAdvConfigEntry 5 } Cong, Hamlen & Perkins Standards Track [Page 26] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 maAdvMinInterval OBJECT-TYPE SYNTAX Integer32 (3..1800) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum time in seconds between successive transmissions of Agent Advertisements from this interface." REFERENCE "MinAdvertisementInterval in RFC1256." ::= { maAdvConfigEntry 6 } maAdvMaxAdvLifetime OBJECT-TYPE SYNTAX Integer32 (4..9000) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time (in seconds) to be placed in the Lifetime field of the RFC 1256-portion of the Agent Advertisements sent over this interface." REFERENCE "AdvertisementLifetime in RFC1256." ::= { maAdvConfigEntry 7 } maAdvResponseSolicitationOnly OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The flag indicates whether the advertisement from that interface should be sent only in response to an Agent Solicitation message." DEFVAL { false } ::= { maAdvConfigEntry 8 } maAdvStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status for the agent advertisement table. If this column status is 'active', the manager should not change any column in the row." ::= { maAdvConfigEntry 9 } -- MA Advertisement Group Counters Cong, Hamlen & Perkins Standards Track [Page 27] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 maAdvertisementsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of advertisements sent by the mobility agent." ::= { maAdvertisement 2 } maAdvsSentForSolicitation OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of advertisements sent by mobility agent in response to mobile node solicitations." ::= { maAdvertisement 3 } maSolicitationsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of solicitations received by the mobility agent." ::= { maAdvertisement 4 } -- Foreign Agent Group -- Foreign Agent System Group faCOATable OBJECT-TYPE SYNTAX SEQUENCE OF FaCOAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing all of the care-of addresses (COAs) supported by the foreign agent. New entries can be added to the table. The order of entries in the faCOATAble is also the order in which the COAs are listed in the Agent Advertisement." ::= { faSystem 1 } faCOAEntry OBJECT-TYPE SYNTAX FaCOAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Cong, Hamlen & Perkins Standards Track [Page 28] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 "Entry of COA" INDEX { faSupportedCOA } ::= { faCOATable 1 } FaCOAEntry ::= SEQUENCE { faSupportedCOA IpAddress, faCOAStatus RowStatus } faSupportedCOA OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Care-of-address supported by this foreign agent." ::= { faCOAEntry 1 } faCOAStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status for COA entry." ::= { faCOAEntry 2 } -- Foreign Agent Advertisement Group -- FA needs to implement MA Advertisement Group plus that group faIsBusy OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether or not the foreign agent is too busy to accept additional registrations. If true(1), the agent is busy and any Agent advertisements sent from this agent should have the 'B' bit set to 1." ::= { faAdvertisement 1 } faRegistrationRequired OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Whether or not this foreign agent requires registration even from those mobile nodes that have acquired their own, colocated care-of address. If Cong, Hamlen & Perkins Standards Track [Page 29] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 true(1), registration is required and any Agent Advertisements sent from this agent should have the 'R' bit set to 1." ::= { faAdvertisement 2 } -- Foreign Agent Registration Group -- Foreign Agent Visitors List faVisitorTable OBJECT-TYPE SYNTAX SEQUENCE OF FaVisitorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the foreign agent's visitor list. The foreign agent updates this table in response to registration events from mobile nodes." ::= { faRegistration 1 } faVisitorEntry OBJECT-TYPE SYNTAX FaVisitorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information for one visitor." INDEX { faVisitorIPAddress } ::= { faVisitorTable 1 } FaVisitorEntry ::= SEQUENCE { faVisitorIPAddress IpAddress, faVisitorHomeAddress IpAddress, faVisitorHomeAgentAddress IpAddress, faVisitorTimeGranted Integer32, faVisitorTimeRemaining Gauge32, faVisitorRegFlags RegistrationFlags, faVisitorRegIDLow Integer32, faVisitorRegIDHigh Integer32, faVisitorRegIsAccepted TruthValue } faVisitorIPAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source IP address of visitor's Registration Request." ::= { faVisitorEntry 1 } Cong, Hamlen & Perkins Standards Track [Page 30] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 faVisitorHomeAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Home (IP) address of visiting mobile node." ::= { faVisitorEntry 2 } faVisitorHomeAgentAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Home agent IP address for that visiting mobile node." ::= { faVisitorEntry 3 } faVisitorTimeGranted OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime in seconds granted to the mobile node for this registration. Only valid if faVisitorRegIsAccepted is true(1)." ::= { faVisitorEntry 4 } faVisitorTimeRemaining OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds remaining until the registration is expired. It has the same initial value as faVisitorTimeGranted, and is counted down by the foreign agent." ::= { faVisitorEntry 5 } faVisitorRegFlags OBJECT-TYPE SYNTAX RegistrationFlags MAX-ACCESS read-only STATUS current DESCRIPTION "Registration flags sent by mobile node." ::= { faVisitorEntry 6 } faVisitorRegIDLow OBJECT-TYPE Cong, Hamlen & Perkins Standards Track [Page 31] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Low 32 bits of Identification used in that registration by the mobile node." ::= { faVisitorEntry 7 } faVisitorRegIDHigh OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "High 32 bits of Identification used in that registration by the mobile node." ::= { faVisitorEntry 8 } faVisitorRegIsAccepted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the registration has been accepted or not. If it is false(2), this registration is still pending for reply." ::= { faVisitorEntry 9 } -- Foreign Agent Registration Group Counters faRegRequestsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid Registration Requests received." ::= { faRegistration 2 } faRegRequestsRelayed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests relayed to home agent by foreign agent." ::= { faRegistration 3 } faReasonUnspecified OBJECT-TYPE Cong, Hamlen & Perkins Standards Track [Page 32] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- reason unspecified (Code 64)." ::= { faRegistration 4 } faAdmProhibited OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- administratively prohibited (Code 65)." ::= { faRegistration 5 } faInsufficientResource OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- insufficient resources (Code 66)." ::= { faRegistration 6 } faMNAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- mobile node failed authentication (Code 67)." ::= { faRegistration 7 } faRegLifetimeTooLong OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- requested lifetime too long (Code 69)." ::= { faRegistration 8 } faPoorlyFormedRequests OBJECT-TYPE Cong, Hamlen & Perkins Standards Track [Page 33] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- poorly formed request (Code 70)." ::= { faRegistration 9 } faEncapsulationUnavailable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- requested encapsulation unavailable (Code 72)." ::= { faRegistration 10 } faVJCompressionUnavailable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- requested Van Jacobson header compression unavailable (Code 73)." ::= { faRegistration 11 } faHAUnreachable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by foreign agent -- home agent unreachable (Codes 80-95)." ::= { faRegistration 12 } faRegRepliesRecieved OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of well-formed Registration Replies received by foreign agent." ::= { faRegistration 13 } faRegRepliesRelayed OBJECT-TYPE Cong, Hamlen & Perkins Standards Track [Page 34] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid Registration Replies relayed to the mobile node by foreign agent." ::= { faRegistration 14 } faHAAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Replies denied by foreign agent -- home agent failed authentication (Code 68)." ::= { faRegistration 15 } faPoorlyFormedReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Replies denied by foreign agent -- poorly formed reply (Code 71)." ::= { faRegistration 16 } -- Home Agent Group -- Home Agent Registration Group -- Home agent mobility binding list haMobilityBindingTable OBJECT-TYPE SYNTAX SEQUENCE OF HaMobilityBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the home agent's mobility binding list. The home agent updates this table in response to registration events from mobile nodes." ::= { haRegistration 1 } haMobilityBindingEntry OBJECT-TYPE SYNTAX HaMobilityBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Cong, Hamlen & Perkins Standards Track [Page 35] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 "An entry on the mobility binding list." INDEX { haMobilityBindingMN, haMobilityBindingCOA } ::= { haMobilityBindingTable 1 } HaMobilityBindingEntry ::= SEQUENCE { haMobilityBindingMN IpAddress, haMobilityBindingCOA IpAddress, haMobilityBindingSourceAddress IpAddress, haMobilityBindingRegFlags RegistrationFlags, haMobilityBindingRegIDLow Integer32, haMobilityBindingRegIDHigh Integer32, haMobilityBindingTimeGranted Integer32, haMobilityBindingTimeRemaining Gauge32 } haMobilityBindingMN OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Mobile node's home (IP) address." ::= { haMobilityBindingEntry 1 } haMobilityBindingCOA OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Mobile node's care-of-address. One mobile node can have multiple bindings with different care-of-addresses." ::= { haMobilityBindingEntry 2 } haMobilityBindingSourceAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP source address of the Registration Request as received by the home agent. Will be either a mobile node's co-located care-of address or an address of the foreign agent." ::= { haMobilityBindingEntry 3 } haMobilityBindingRegFlags OBJECT-TYPE SYNTAX RegistrationFlags MAX-ACCESS read-only STATUS current Cong, Hamlen & Perkins Standards Track [Page 36] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 DESCRIPTION "Registration flags sent by mobile node." ::= { haMobilityBindingEntry 4 } haMobilityBindingRegIDLow OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Low 32 bits of Identification used in that binding by the mobile node." ::= { haMobilityBindingEntry 5 } haMobilityBindingRegIDHigh OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "High 32 bits of Identification used in that binding by the mobile node." ::= { haMobilityBindingEntry 6 } haMobilityBindingTimeGranted OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime in seconds granted to the mobile node for this registration." ::= { haMobilityBindingEntry 7 } haMobilityBindingTimeRemaining OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds remaining until the registration is expired. It has the same initial value as haMobilityBindingTimeGranted, and is counted down by the home agent." ::= { haMobilityBindingEntry 8 } -- Home Agent Registration Group Counters -- Home agent registration Counters per node Cong, Hamlen & Perkins Standards Track [Page 37] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 haCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF HaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing registration statistics for all mobile nodes authorized to use this home agent." ::= { haRegistration 2 } haCounterEntry OBJECT-TYPE SYNTAX HaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Registration statistics for one mobile node." INDEX { haMobilityBindingMN } ::= { haCounterTable 1 } HaCounterEntry ::= SEQUENCE { haServiceRequestsAccepted Counter32, haServiceRequestsDenied Counter32, haOverallServiceTime Gauge32, haRecentServiceAcceptedTime TimeStamp, haRecentServiceDeniedTime TimeStamp, haRecentServiceDeniedCode INTEGER } haServiceRequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of service requests for the mobile node accepted by the home agent (Code 0 + Code 1)." ::= { haCounterEntry 2 } haServiceRequestsDenied OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of service requests for the mobile node denied by the home agent (sum of all registrations denied with Code 128 through Code 159)." ::= { haCounterEntry 3 } haOverallServiceTime OBJECT-TYPE SYNTAX Gauge32 Cong, Hamlen & Perkins Standards Track [Page 38] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Overall service time (in seconds) that has accumulated for the mobile node since the home agent last rebooted." ::= { haCounterEntry 4 } haRecentServiceAcceptedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the most recent Registration Request was accepted by the home agent for this mobile node." ::= { haCounterEntry 5 } haRecentServiceDeniedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the most recent Registration Request was denied by the home agent for this mobile node." ::= { haCounterEntry 6 } haRecentServiceDeniedCode OBJECT-TYPE SYNTAX INTEGER { reasonUnspecified(128), admProhibited(129), insufficientResource(130), mnAuthenticationFailure(131), faAuthenticationFailure(132), idMismatch(133), poorlyFormedRequest(134), tooManyBindings(135), unknownHA(136) } MAX-ACCESS read-only STATUS current DESCRIPTION "The Code indicating the reason why the most recent Registration Request for this mobile node was rejected by the home agent." ::= { haCounterEntry 7 } Cong, Hamlen & Perkins Standards Track [Page 39] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 -- Home agent registration Counters for all mobile nodes. haRegistrationAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests accepted by home agent (Code 0)." ::= { haRegistration 3 } haMultiBindingUnsupported OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests accepted by home agent -- simultaneous mobility bindings unsupported (Code 1)." ::= { haRegistration 4 } haReasonUnspecified OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- reason unspecified (Code 128)." ::= { haRegistration 5 } haAdmProhibited OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- administratively prohibited (Code 129)." ::= { haRegistration 6 } haInsufficientResource OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- insufficient resources (Code 130)." ::= { haRegistration 7 } Cong, Hamlen & Perkins Standards Track [Page 40] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 haMNAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- mobile node failed authentication (Code 131)." ::= { haRegistration 8 } haFAAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- foreign agent failed authentication (Code 132)." ::= { haRegistration 9 } haIDMismatch OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- Identification mismatch (Code 133)." ::= { haRegistration 10 } haPoorlyFormedRequest OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- poorly formed request (Code 134)." ::= { haRegistration 11 } haTooManyBindings OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- too many simultaneous mobility bindings (Code 135)." ::= { haRegistration 12 } Cong, Hamlen & Perkins Standards Track [Page 41] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 haUnknownHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests denied by home agent -- unknown home agent address (Code 136)." ::= { haRegistration 13 } haGratuitiousARPsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of gratuition ARPs sent by the home agent on behalf of mobile nodes." ::= { haRegistration 14 } haProxyARPsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of proxy ARPs sent by the home agent on behalf of mobile nodes." ::= { haRegistration 15 } haRegRequestsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests received by home agent." ::= { haRegistration 16 } haDeRegRequestsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Requests received by the home agent with a Lifetime of zero (requests to deregister)." ::= { haRegistration 17 } haRegRepliesSent OBJECT-TYPE SYNTAX Counter32 Cong, Hamlen & Perkins Standards Track [Page 42] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Replies sent by the home agent." ::= { haRegistration 18 } haDeRegRepliesSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Registration Replies sent by the home agent in response to requests to deregister." ::= { haRegistration 19 } mipMIBNotificationPrefix OBJECT IDENTIFIER ::= { mipMIB 2 } mipMIBNotifications OBJECT IDENTIFIER ::= { mipMIBNotificationPrefix 0 } mipAuthFailure NOTIFICATION-TYPE OBJECTS { mipSecViolatorAddress, mipSecRecentViolationSPI, mipSecRecentViolationIDLow, mipSecRecentViolationIDHigh, mipSecRecentViolationReason } STATUS current DESCRIPTION "The mipAuthFailure indicates that the Mobile IP entity has an authentication failure when it validates the mobile Registration Request or Reply. Implementation of this trap is optional." ::= { mipMIBNotifications 1 } mipMIBConformance OBJECT IDENTIFIER ::= { mipMIB 3 } mipGroups OBJECT IDENTIFIER ::= { mipMIBConformance 1 } mipCompliances OBJECT IDENTIFIER ::= { mipMIBConformance 2 } -- compliance statements mipCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Cong, Hamlen & Perkins Standards Track [Page 43] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 "The compliance statement for SNMPv2 entities which implement the Mobile IP MIB." MODULE MANDATORY-GROUPS { mipSystemGroup } GROUP mipSecAssociationGroup DESCRIPTION "This group is mandatory for Mobile IP entities (MN, FA, and HA) which support security associations. Mobile Nodes and Home Agents must implement this group. Foreign Agents must implement this group if they maintain any security associations." GROUP mipSecViolationGroup DESCRIPTION "This group is mandatory for Mobile IP entities (MN, FA, and HA) that can log security violations." GROUP mnSystemGroup DESCRIPTION "This group is mandatory for mobile node." GROUP mnDiscoveryGroup DESCRIPTION "This group is mandatory for mobile nodes which implement the Agent Discovery function." GROUP mnRegistrationGroup DESCRIPTION "This group is mandatory for mobile nodes." GROUP maAdvertisementGroup DESCRIPTION "This group is mandatory for the mobility agents (HA and FA) since they must implement Agent Advertisement." GROUP faSystemGroup DESCRIPTION "This group is mandatory for foreign agents." GROUP faAdvertisementGroup DESCRIPTION "This group is mandatory for foreign agents." GROUP faRegistrationGroup DESCRIPTION "This group is mandatory for foreign agents." Cong, Hamlen & Perkins Standards Track [Page 44] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 GROUP haRegistrationGroup DESCRIPTION "This group is mandatory for home agents." GROUP haRegNodeCountersGroup DESCRIPTION "This group is mandatory for home agents which log registration counters for each individual mobile node." GROUP mipSecNotificationsGroup DESCRIPTION "This group is mandatory for Mobile IP entities (MN, FA, and HA) that can report the security violations." ::= { mipCompliances 1 } -- Units of conformance mipSystemGroup OBJECT-GROUP OBJECTS { mipEntities, mipEnable, mipEncapsulationSupported } STATUS current DESCRIPTION "A collection of objects providing the basic Mobile IP entity's management information." ::= { mipGroups 1 } mipSecAssociationGroup OBJECT-GROUP OBJECTS { mipSecAlgorithmType, mipSecAlgorithmMode, mipSecKey, mipSecReplayMethod } STATUS current DESCRIPTION "A collection of objects providing the management information for security associations of Mobile IP entities." ::= { mipGroups 2 } mipSecViolationGroup OBJECT-GROUP OBJECTS { mipSecTotalViolations, mipSecViolationCounter, mipSecRecentViolationSPI, mipSecRecentViolationTime, mipSecRecentViolationIDLow, mipSecRecentViolationIDHigh, mipSecRecentViolationReason } STATUS current DESCRIPTION "A collection of objects providing the management Cong, Hamlen & Perkins Standards Track [Page 45] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 information for security violation logging of Mobile IP entities." ::= { mipGroups 3 } mnSystemGroup OBJECT-GROUP OBJECTS { mnState, mnCurrentHA, mnHomeAddress, mnHAStatus } STATUS current DESCRIPTION "A collection of objects providing the basic management information for mobile nodes." ::= { mipGroups 4 } mnDiscoveryGroup OBJECT-GROUP OBJECTS { mnFAAddress, mnCOA, mnAdvSourceAddress, mnAdvSequence, mnAdvFlags, mnAdvMaxRegLifetime, mnAdvMaxAdvLifetime, mnAdvTimeReceived, mnSolicitationsSent, mnAdvertisementsReceived, mnAdvsDroppedInvalidExtension, mnAdvsIgnoredUnknownExtension, mnMoveFromHAToFA, mnMoveFromFAToFA, mnMoveFromFAToHA, mnGratuitousARPsSend, mnAgentRebootsDectected } STATUS current DESCRIPTION "A collection of objects providing management information for the Agent Discovery function within a mobile node." ::= { mipGroups 5 } mnRegistrationGroup OBJECT-GROUP OBJECTS { mnRegAgentAddress, mnRegCOA, mnRegFlags, mnRegIDLow, mnRegIDHigh, mnRegTimeRequested, mnRegTimeRemaining, mnRegTimeSent, mnRegIsAccepted, mnCOAIsLocal, mnRegRequestsSent, mnRegRepliesRecieved, mnDeRegRequestsSent, mnDeRegRepliesRecieved, mnRepliesInvalidHomeAddress, mnRepliesUnknownHA, mnRepliesUnknownFA, mnRepliesInvalidID, mnRepliesDroppedInvalidExtension, mnRepliesIgnoredUnknownExtension, mnRepliesHAAuthenticationFailure, mnRepliesFAAuthenticationFailure, mnRegRequestsAccepted, mnRegRequestsDeniedByHA, mnRegRequestsDeniedByFA, mnRegRequestsDeniedByHADueToID, mnRegRequestsWithDirectedBroadcast } STATUS current DESCRIPTION "A collection of objects providing management Cong, Hamlen & Perkins Standards Track [Page 46] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 information for the registration function within a mobile node." ::= { mipGroups 6 } maAdvertisementGroup OBJECT-GROUP OBJECTS { maAdvMaxRegLifetime, maAdvPrefixLengthInclusion, maAdvAddress, maAdvMaxInterval, maAdvMinInterval, maAdvMaxAdvLifetime, maAdvResponseSolicitationOnly, maAdvStatus, maAdvertisementsSent, maAdvsSentForSolicitation, maSolicitationsReceived } STATUS current DESCRIPTION "A collection of objects providing management information for the Agent Advertisement function within mobility agents." ::= { mipGroups 7 } faSystemGroup OBJECT-GROUP OBJECTS { faCOAStatus} STATUS current DESCRIPTION "A collection of objects providing the basic management information for foreign agents." ::= { mipGroups 8 } faAdvertisementGroup OBJECT-GROUP OBJECTS { faIsBusy, faRegistrationRequired } STATUS current DESCRIPTION "A collection of objects providing supplemental management information for the Agent Advertisement function within a foreign agent." ::= { mipGroups 9 } faRegistrationGroup OBJECT-GROUP OBJECTS { faVisitorIPAddress, faVisitorHomeAddress, faVisitorHomeAgentAddress, faVisitorTimeGranted, faVisitorTimeRemaining, faVisitorRegFlags, faVisitorRegIDLow, faVisitorRegIDHigh, faVisitorRegIsAccepted, faRegRequestsReceived, faRegRequestsRelayed, faReasonUnspecified, faAdmProhibited, faInsufficientResource, faMNAuthenticationFailure, faRegLifetimeTooLong, faPoorlyFormedRequests, faEncapsulationUnavailable, faVJCompressionUnavailable, faHAUnreachable, Cong, Hamlen & Perkins Standards Track [Page 47] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 faRegRepliesRecieved, faRegRepliesRelayed, faHAAuthenticationFailure, faPoorlyFormedReplies } STATUS current DESCRIPTION "A collection of objects providing management information for the registration function within a foreign agent." ::= { mipGroups 10 } haRegistrationGroup OBJECT-GROUP OBJECTS { haMobilityBindingMN, haMobilityBindingCOA, haMobilityBindingSourceAddress, haMobilityBindingRegFlags, haMobilityBindingRegIDLow, haMobilityBindingRegIDHigh, haMobilityBindingTimeGranted, haMobilityBindingTimeRemaining, haRegistrationAccepted, haMultiBindingUnsupported, haReasonUnspecified, haAdmProhibited, haInsufficientResource, haMNAuthenticationFailure, haFAAuthenticationFailure, haIDMismatch, haPoorlyFormedRequest, haTooManyBindings, haUnknownHA, haGratuitiousARPsSent, haProxyARPsSent, haRegRequestsReceived, haDeRegRequestsReceived, haRegRepliesSent, haDeRegRepliesSent } STATUS current DESCRIPTION "A collection of objects providing management information for the registration function within a home agent." ::= { mipGroups 11 } haRegNodeCountersGroup OBJECT-GROUP OBJECTS { haServiceRequestsAccepted, haServiceRequestsDenied, haOverallServiceTime, haRecentServiceAcceptedTime, haRecentServiceDeniedTime, haRecentServiceDeniedCode } STATUS current DESCRIPTION "A collection of objects providing management information for counters related to the registration function within a home agent." ::= { mipGroups 12 } mipSecNotifcationsGroup NOTIFICATION-GROUP NOTIFICATIONS { mipAuthFailure } Cong, Hamlen & Perkins Standards Track [Page 48] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 STATUS current DESCRIPTION "The notification related to security violations." ::= { mipGroups 13 } END 5. Acknowledgments This document was produced by the Mobile IP working group. The editors wish to thank Bob Stewart (Cisco Systems), for his help in converting from SNMPv1 to SNMPv2. We also want to thank Jim Solomon, for his encouragement, patience, and help. Thanks to Fredrick Tarberg and Fredrik Broman (KTH) for their initial efforts in defining a Mobile IP MIB. Thanks to Frank Kastenholz (FTP Software) for his comments on the initial MIB from KTH. Thanks to Gerald Maguire (KTH) for his comments on the first version of this MIB. Thanks to Mike Roels (Motorola) for his help in testing this MIB. 6. Security Considerations The Mobile IP MIB affords the network operator the ability to configure and control the Mobile IP links of a particular system, including the Mobile IP authentication protocols, and shared secret key. This represents a security risk. These risks are addressed in the following manners: (1) All variables which represent a significant security risk are placed in separate MIB Groups. By providing Agent Capability Statements, the implementor of the MIB may elect not to implement these groups. (2) The MIB allows the manager station to create the security association for Mobile IP entities. However, the agent should always return 0 length octet string when the manager station retrieves the shared security key in the mipSecAssocTable. In this way, the Mobile IP entities can prevent the key leaking from SNMP GET, GET-NEXT, or GET-BULK requests. (3) The MIB defines a trap for Mobile IP entities to send a notification to the manager station if there is a security violation. In this way, the operator can notice the source of an intruder. (4) The MIB also defines a table to log the security violations in the Mobile IP entities. The manager station can retrieve this log to analyze the security violation instances in the Cong, Hamlen & Perkins Standards Track [Page 49] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 system. Thus, in order to preserve the integrity, security and privacy of the Mobile IP security features, an implementation SHOULD allow access to this MIB only via SNMPv2 and with other security enhancement such as SNMPv2Sec. The other way to access this information is in concert with the IP security protocols (IP Authentication Header and IP Encapsulating Security Payload). 7.0 References [1] 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. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [4] 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. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [6] 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. [7] Solomon J., "Mobile IP Protocol Applicability Statement", RFC 2005, October 1996. [8] Perkins C., "IP Mobility Support", RFC 2002, Octoer 1996. [9] Perkins C., "IP Encapsulation within IP", RFC 2003, October 1996. [10] Perkins C., "Minimal Encapsulation within IP", RFC 2004, October 1996. Cong, Hamlen & Perkins Standards Track [Page 50] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 [11] Hanks S. et. al., "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [12] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [13] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. [14] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995. 8. Chair's Address The working group can be contacted via the current chair: Jim Solomon Motorola, Inc. 1301 E. Algonquin Rd. Schaumburg, IL 60196 Work: +1-847-576-2753 Fax: +1-847-576-3240 EMail: solomon@comm.mot.com Cong, Hamlen & Perkins Standards Track [Page 51] RFC 2006 Mobile IP MIB Definition using SMIv2 October 1996 9. Editors' Addresses Questions about this memo can also be directed to: David Cong Room 3149 Motorola 1301 East Algonquin Rd. Schaumburg, IL 60196 Work: +1-847-576-1357 Fax: +1-847-538-3472 EMail: cong@comm.mot.com Mark Hamlen Room 4413 Motorola 1301 East Algonquin Rd. Schaumburg, IL 60196 Work: +1-847-576-0346 Fax: +1-847-538-6150 EMail: hamlen@comm.mot.com Charles Perkins Room J1-A25 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-7007 EMail: perk@watson.ibm.com Cong, Hamlen & Perkins Standards Track [Page 52] snmp-mibs-downloader-1.1/mibrfcs/rfc2020.txt0000644000000000000000000021470711402176071015560 0ustar Network Working Group J. Flick Request for Comments: 2020 Hewlett Packard Category: Standards Track October 1996 Definitions of Managed Objects for IEEE 802.12 Interfaces 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 ............................................... 1 2. Object Definitions ......................................... 2 3. Overview ................................................... 2 3.1. MAC Addresses ............................................ 3 3.2. Relation to RFC 1213 ..................................... 3 3.3. Relation to RFC 1573 ..................................... 3 3.3.1. Layering Model ......................................... 4 3.3.2. Virtual Circuits ....................................... 4 3.3.3. ifTestTable ............................................ 4 3.3.4. ifRcvAddressTable ...................................... 4 3.3.5. ifPhysAddress .......................................... 4 3.3.6. Specific Interface MIB Objects ......................... 5 3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 ............. 8 3.5. Relation to RFC 1749 ..................................... 8 3.6. Master Mode Operation .................................... 9 3.7. Normal and High Priority Counters ........................ 9 3.8. IEEE 802.12 Training Frames .............................. 10 3.9. Mapping of IEEE 802.12 Managed Objects ................... 12 4. Definitions ................................................ 14 5. Acknowledgements ........................................... 30 6. References ................................................. 30 7. Security Considerations .................................... 31 8. Author's Address ........................................... 31 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. Flick Standards Track [Page 1] RFC 2020 IEEE 802.12 Interface MIB October 1996 2. Object Definitions Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. MIB modules are written using a subset of Abstract Syntax Notation One (ASN.1) [1] termed the Structure of Management Information (SMI) [2]. 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 Instances of these object types represent attributes of an interface to an IEEE 802.12 communications medium. At present, IEEE 802.12 media are identified by one value of the ifType object in the Internet-standard MIB: ieee80212(55) For this interface, the value of the ifSpecific variable in the MIB- II [5] has the OBJECT IDENTIFIER value: dot12MIB OBJECT IDENTIFIER ::= { transmission 45 } The values for the ifType object are defined by the IANAifType textual convention. The Internet Assigned Numbers Authority (IANA) is responsible for the assignment of all Internet numbers, including new ifType values. Therefore, IANA is responsible for maintaining the definition of this textual convention. The current definition of the IANAifType textual convention is available from IANA's World Wide Web server at: http://www.iana.org/iana/ The definitions presented here are based on the IEEE Standard 802.12-1995, [6] Clause 13 "Layer management functions and services", and Annex C "GDMO Specifications for Demand Priority Managed Objects". Implementors of these MIB objects should note that the IEEE document explicitly describes (in the form of Pascal pseudocode) when, where, and how various MAC attributes are measured. The IEEE document also describes the effects of MAC actions that may be invoked by manipulating instances of the MIB objects defined here. Flick Standards Track [Page 2] RFC 2020 IEEE 802.12 Interface MIB October 1996 To the extent that some of the attributes defined in [6] are represented by previously defined objects in the Internet-standard MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7], such attributes are not redundantly represented by objects defined in this memo. Among the attributes represented by objects defined in other memos are the number of octets transmitted or received on a particular interface, the MAC address of an interface, and multicast information associated with an interface. 3.1. MAC Addresses All representations of MAC addresses in this MIB module, and in other related MIB modules (like RFC 1573), are in "canonical" order defined by 802.1a, i.e., as if it were transmitted least significant bit first. This is true even if the interface is operating in token ring framing mode, which requires MAC addresses to be transmitted most significant bit first. 3.2. Relation to RFC 1213 This section applies only when this MIB is used in conjunction with the "old" (i.e., pre-RFC 1573) interface group. The relationship between an IEEE 802.12 interface and an interface in the context of the Internet-standard MIB is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. 3.3. Relation to RFC 1573 RFC 1573, the Interface MIB Evolution, requires that any MIB which is an adjunct of the Interface MIB, clarify specific areas within the Interface MIB. These areas are intentionally left vague in RFC 1573 to avoid over constraining the MIB, thereby precluding management of certain media-types. An agent which implements this MIB module must support the ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and ifRcvAddressGroup of RFC 1573. Section 3.3 of RFC 1573 enumerates several areas which a media- specific MIB must clarify. In addition, there are some objects in RFC 1573 for which additional clarification of how to apply them to an IEEE 802.12 interface would be helpful. Each of these areas is addressed in a following subsection. The implementor is referred to RFC 1573 in order to understand the general intent of these areas. Flick Standards Track [Page 3] RFC 2020 IEEE 802.12 Interface MIB October 1996 3.3.1. Layering Model For the typical usage of this MIB module, there will be no sub-layers "above" or "below" the 802.12 Interface. However, this MIB module does not preclude such layering. 3.3.2. Virtual Circuits This medium does not support virtual circuits and this area is not applicable to this MIB. 3.3.3. ifTestTable This MIB does not define any tests for media instrumented by this MIB. Implementation of the ifTestTable is not required. An implementation may optionally implement the ifTestTable to execute vendor specific tests. 3.3.4. ifRcvAddressTable This table contains all IEEE addresses, unicast, multicast, and broadcast, for which this interface will receive packets and forward them up to a higher layer entity for consumption. In addition, when the interface is using 802.5 framing mode, the ifRcvAddressTable will contain the functional address mask. In the event that the interface is part of a MAC bridge, this table does not include unicast addresses which are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filtering mechanism. 3.3.5. ifPhysAddress This object contains the IEEE 802.12 address which is placed in the source-address field of any frames that originate at this interface. Usually this will be kept in ROM on the interface hardware. Some systems may set this address via software. In a system where there are several such addresses the designer has a tougher choice. The address chosen should be the one most likely to be of use to network management (e.g. the address placed in ARP responses for systems which are primarily IP systems). If the designer truly can not choose, use of the factory-provided ROM address is suggested. If the address can not be determined, an octet string of zero length should be returned. Flick Standards Track [Page 4] RFC 2020 IEEE 802.12 Interface MIB October 1996 The address is stored in binary in this object. The address is stored in "canonical" bit order, that is, the Group Bit is positioned as the low-order bit of the first octet. Thus, the first byte of a multicast address would have the bit 0x01 set. This is true even when the interface is using token ring framing mode, which transmits addresses high-order bit first. 3.3.6. Specific Interface MIB Objects The following table provides specific implementation guidelines for the interface group objects in the conformance groups listed above. Object Use for an 802.12 Interface ifIndex Each 802.12 interface is represented by an ifEntry. Interface tables in this MIB module are indexed by ifIndex. ifDescr Refer to [7]. ifType The IANA reserved value for 802.12 - 55. ifMtu The value of ifMtu on an 802.12 interface will depend on the type of framing that is in use on that interface. Changing the dot12DesiredFramingType may have the effect of changing ifMtu after the next time that the interface trains. When dot12CurrentFramingType is equal to frameType88023, ifMtu will be equal to 1500. When dot12CurrentFramingType is equal to frameType88025, ifMtu will be 4464. ifSpeed The speed of the interface in bits per second. For current 802.12 implementations, this will be equal to 100,000,000 (100 million). ifPhysAddress See Section 3.3.5. Flick Standards Track [Page 5] RFC 2020 IEEE 802.12 Interface MIB October 1996 ifAdminStatus Write access is not required. Support for 'testing' is not required. Setting this object to 'up' will cause dot12Commands to be set to 'open'. Setting this object to 'down' will cause dot12Commands to be set to 'close'. Setting dot12Commands to 'open' will set this object to 'up'. Setting dot12Commands to 'close' will set this object to 'down'. Setting dot12Commands to 'reset' will have no effect on this object. ifOperStatus When dot12Status is equal to 'opened', this object will be equal to 'up'. When dot12Status is equal to 'closed', 'opening', 'openFailure' or 'linkFailure', this object will be equal to 'down'. Support for 'testing' is not required, but may be used to indicate that a vendor specific test is in progress. The value 'dormant' has no meaning for an IEEE 802.12 interface. ifLastChange Refer to [7]. ifInOctets The number of octets in valid MAC frames received on this interface, including the MAC header and FCS. ifInUcastPkts Refer to [7]. ifInDiscards Refer to [7]. ifInErrors The sum for this interface of dot12InIPMErrors, dot12InOversizeFrameErrors, dot12InDataErrors, and any additional internal errors that may occur in an implementation. ifInUnknownProtos Refer to [7]. ifOutOctets The number of octets transmitted in MAC frames on this interface, including the MAC header and FCS. ifOutUcastPkts Refer to [7]. ifOutDiscards Refer to [7]. Flick Standards Track [Page 6] RFC 2020 IEEE 802.12 Interface MIB October 1996 ifOutErrors The number of implementation-specific internal transmit errors on this interface. ifName Locally-significant textual name for the interface (e.g. vg0). ifInMulticastPkts Refer to [7]. When dot12CurrentFramingType is frameType88025, this count includes packets addressed to functional addresses. ifInBroadcastPkts Refer to [7]. ifOutMulticastPkts Refer to [7]. When dot12CurrentFramingType is frameType88025, this count includes packets addressed to functional addresses. ifOutBroadcastPkts Refer to [7]. ifHCInOctets 64-bit version of ifInOctets. ifHCOutOctets 64-bit version of ifOutOctets ifHC*Pkts Not required for 100 MBit interfaces. Future IEEE 802.12 interfaces which operate at higher speeds may require implementation of these counters, but such interfaces are beyond the scope of this memo. ifLinkUpDownTrapEnable Refer to [7]. Default is 'enabled'. ifHighSpeed The speed of the interface in millions of bits per second. For current 802.12 implementations, this will be equal to 100. ifPromiscuousMode Reflects whether the interface has successfully trained and is currently operating in promiscuous mode. dot12DesiredPromiscStatus is used to select the promiscuous mode to be requested in the next training attempt. Setting ifPromiscuousMode will update dot12DesiredPromiscStatus and cause the interface to attempt to retrain using the new promiscuous mode. After the interface has retrained, ifPromiscuousMode will reflect the mode that is in use, not the mode that was requested. Flick Standards Track [Page 7] RFC 2020 IEEE 802.12 Interface MIB October 1996 ifConnectorPresent This will normally be 'true'. ifStackHigherLayer Refer to section 3.3.1 ifStackLowerLayer ifStackStatus ifRcvAddressAddress Refer to section 3.3.4. ifRcvAddressStatus ifRcvAddressType 3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 An IEEE 802.12 interface can be configured to operate in either ethernet or token ring framing mode. An IEEE 802.12 interface uses the frame format for the configured framing mode, but does not use the media access protocol for ethernet or token ring. Instead, IEEE 802.12 defines its own media access protocol, the Demand Priority Access Method (DPAM). There are existing standards-track MIB modules for instrumenting ethernet-like interfaces and token ring interfaces. At the time of this writing, they are: STD 50, RFC 1643, "Definitions of Managed Objects for Ethernet-like Interface Types" [8]; RFC 1650, "Definitions of Managed Objects for Ethernet-like Interface Types using SMIv2" [9]; and RFC 1748, "IEEE 802.5 MIB using SMIv2" [10]. These MIB modules are designed to instrument the media access protocol for these respective technologies. Since IEEE 802.12 interfaces do not implement either of these media access protocols, an agent should not implement RFC 1643, RFC 1650, or RFC 1748 for IEEE 802.12 interfaces. 3.5. Relation to RFC 1749 When an IEEE 802.12 interface is operating in token ring framing mode, and the end node supports token ring source routing, the agent should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB [11] for those interfaces. Flick Standards Track [Page 8] RFC 2020 IEEE 802.12 Interface MIB October 1996 3.6. Master Mode Operation In an IEEE 802.12 network, "master" devices act as network controllers to decide when to grant requesting end-nodes permission to transmit. These master devices may be repeaters, or other active controller devices such as switches. Devices which do not act as network controllers, such as end-nodes or passive switches, are considered to be operating in "slave" mode. The dot12ControlMode object indicates if the interface is operating in master mode or slave mode. 3.7. Normal and High Priority Counters The IEEE 802.12 interface MIB does not provide normal priority transmit counters. Standardization of normal priority transmit counters could not be justified -- ifOutUcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should suffice. More precisely, the number of normal priority frames transmitted can be calculated as: outNormPriorityFrames = ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts - dot12OutHighPriorityFrames The number of normal priority octets transmitted can be calculated as: outNormPriorityOctets = ifOutOctets - dot12OutHighPriorityOctets On the other hand, normal priority receive counters are provided. The main reason for this is that the normal priority and high priority counters include errored frames, whereas the ifIn*Pkts and ifInOctets do not include errored frames. dot12InNormPriorityFrames could be calculated, but the calculation is tedious: inNormPriorityFrames = ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + dot12InNullAddressedFrames + ifInErrors + ifInDiscards + ifInUnknownProtos - dot12InHighPriorityFrames Flick Standards Track [Page 9] RFC 2020 IEEE 802.12 Interface MIB October 1996 dot12InNormPriorityOctets includes octets in unreadable frames, which is not available elsewhere. The number of octets in unreadable frames can be calculated as: octetsInUnreadableFrames = dot12InNormPriorityOctets + dot12InHighPriorityOctets - ifInOctets Also, the total traffic at this interface can be calculated as: traffic = dot12InNormPriorityOctets + dot12InHighPriorityOctets + ifOutOctets In other words, the normal priority receive counters were deemed useful, whereas the normal priority transmit counters can be easily calculated from other available counters. 3.8. IEEE 802.12 Training Frames Training frames are special MAC frames that are used only during link initialization. Training frames are initially constructed by the device at the lower end of a link, which is the slave mode device for the link. The training frame format is as follows: +----+----+------------+--------------+----------+-----+ | DA | SA | Req Config | Allow Config | Data | FCS | +----+----+------------+--------------+----------+-----+ DA = destination address (six octets) SA = source address (six octets) Req Config = requested configuration (2 octets) Allow Config = allowed configuration (2 octets) Data = data (594 to 675 octets) FCS = frame check sequence (4 octets) Training frames are always sent with a null destination address. To pass training, an end node must use its source address in the source address field of the training frame. A repeater may use a non-null source address if it has one, or it may use a null source address. Flick Standards Track [Page 10] RFC 2020 IEEE 802.12 Interface MIB October 1996 The requested configuration field allows the slave mode device to inform the master mode device about itself and to request configuration options. The training response frame from the master mode device contains the slave mode device's requested configuration from the training request frame. The currently defined format of the requested configuration field as defined in the IEEE Standard 802.12-1995 standard is shown below. Please refer to the most current version of the IEEE document for a more up to date description of this field. In particular, the reserved bits may be used in later versions of the standard. First Octet: Second Octet: 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |v|v|v|r|r|r|r|r| |r|r|r|F|F|P|P|R| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ vvv: The version of the 802.12 training protocol with which the training initiator is compliant. The current version is 100. r: Reserved bits (set to zero) FF: 00 = frameType88023 01 = frameType88025 10 = reserved 11 = frameTypeEither PP: 00 = singleAddressMode 01 = promiscuousMode 10 = reserved 11 = reserved R: 0 = the training initiator is an end node 1 = the training initiator is a repeater The allowed configuration field allows the master mode device to respond with the allowed configuration. The slave mode device sets the contents of this field to all zero bits. The master mode device sets the allowed configuration field as follows: First Octet: Second Octet: 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |v|v|v|D|C|N|r|r| |r|r|r|F|F|P|P|R| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ vvv: The version of the 802.12 training protocol with which the training responder is compliant. The current version is 100. Flick Standards Track [Page 11] RFC 2020 IEEE 802.12 Interface MIB October 1996 D: 0 = No duplicate address has been detected. 1 = Duplicate address has been detected C: 0 = The requested configuration is compatible with the network. 1 = The requested configuration is not compatible with the network. In this case, the FF, PP, and R bits indicate the configuration that would be allowed. N: 0 = Access will be allowed, providing the configuration is compatible (C = 0). 1 = Access is not granted because of security restrictions r: Reserved bits (set to zero) FF: 00 = frameType88023 will be used 01 = frameType88025 will be used 10 = reserved 11 = reserved PP: 00 = singleAddressMode 01 = promiscuousMode 10 = reserved 11 = reserved R: 0 = Requested access as an end node is allowed 1 = Requested access as a repeater is allowed Again, note that the most recent version of the IEEE 802.12 standard should be consulted for the most up to date definition of the requested configuration and allowed configuration fields. The data field contains between 594 and 675 octets and is filled in by the training initiator. The first 55 octets may be used for vendor specific protocol information. The remaining octets are all zeros. The length of the training frame combined with the requirement that 24 consecutive training frames be received without error to complete training ensures that marginal links will not complete training. 3.9. Mapping of IEEE 802.12 Managed Objects The following table lists all the managed objects defined for oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP objects. IEEE 802.12 Managed Object Corresponding SNMP Object oEndNode .aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts .aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts .aDataErrorFramesReceived dot12InDataErrors .aDesiredFramingType dot12DesiredFramingType Flick Standards Track [Page 12] RFC 2020 IEEE 802.12 Interface MIB October 1996 .aDesiredPromiscuousStatus dot12DesiredPromiscStatus .aFramesTransmitted IF-MIB - ifOutUCastPkts + ifOutMulticastPkts + ifOutBroadcastPkts .aFramingCapability dot12FramingCapability .aFunctionalAddresses IF-MIB - ifRcvAddressTable .aHighPriorityFramesReceived dot12InHighPriorityFrames .aHighPriorityFramesTransmitted dot12OutHighPriorityFrames .aHighPriorityOctetsReceived dot12InHighPriorityOctets or dot12InHCHighPriorityOctets .aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets or dot12OutHCHighPriorityOctets .aIPMFramesReceived dot12InIPMErrors .aLastTrainingConfig dot12LastTrainingConfig .aMACID IF-MIB - ifIndex .aMACStatus dot12Status .aMACVersion dot12TrainingVersion .aMediaType Tranceiver MIB issue .aMulticastFramesReceived IF-MIB - ifInMulticastPkts .aMulticastFramesTransmitted IF-MIB - ifOutMulticastPkts .aMulticastReceiveStatus IF-MIB - ifRcvAddressTable .aNormalPriorityFramesReceived dot12InNormPriorityFrames .aNormalPriorityOctetsReceived dot12InNormPriorityOctets or dot12InHCNormPriorityOctets .aNullAddressedFramesReceived dot12InNullAddressedFrames .aOctetsTransmitted IF-MIB - ifOutOctets or ifHCOutOctets .aOversizeFramesReceived dot12InOversizeFrameErrors .aReadableFramesReceived IF-MIB - ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts .aReadableOctetsReceived IF-MIB - ifInOctets or ifHCInOctets .aReadMulticastList IF-MIB - ifRcvAddressTable .aReadWriteMACAddress IF-MIB - ifPhysAddress .aTransitionsIntoTraining dot12TransitionIntoTrainings .acAddGroupAddress IF-MIB - ifRcvAddressTable .acClose dot12Commands: 'close' .acDeleteGroupAddress IF-MIB - ifRcvAddressTable .acExecuteSelftest IF-MIB - ifAdminStatus .acInitializeMAC dot12Commands: 'reset' .acOpen dot12Commands: 'open' Flick Standards Track [Page 13] RFC 2020 IEEE 802.12 Interface MIB October 1996 4. Definitions DOT12-IF-MIB DEFINITIONS ::= BEGIN IMPORTS transmission, Counter32, Counter64, OBJECT-TYPE, MODULE-IDENTITY FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB; dot12MIB MODULE-IDENTITY LAST-UPDATED "9602220452Z" -- February 22, 1996 ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group" CONTACT-INFO " John Flick Postal: Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 Tel: +1 916 785 4018 Fax: +1 916 785 3583 E-mail: johnf@hprnd.rose.hp.com" DESCRIPTION "This MIB module describes objects for managing IEEE 802.12 interfaces." ::= { transmission 45 } dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 } dot12ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot12ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration information for a collection of 802.12 interfaces attached to a particular system." ::= { dot12MIBObjects 1 } dot12ConfigEntry OBJECT-TYPE SYNTAX Dot12ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Flick Standards Track [Page 14] RFC 2020 IEEE 802.12 Interface MIB October 1996 "Configuration for a particular interface to an 802.12 medium." INDEX { ifIndex } ::= { dot12ConfigTable 1 } Dot12ConfigEntry ::= SEQUENCE { dot12CurrentFramingType INTEGER, dot12DesiredFramingType INTEGER, dot12FramingCapability INTEGER, dot12DesiredPromiscStatus INTEGER, dot12TrainingVersion INTEGER, dot12LastTrainingConfig OCTET STRING, dot12Commands INTEGER, dot12Status INTEGER, dot12ControlMode INTEGER } dot12CurrentFramingType OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2), frameTypeUnknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "When dot12DesiredFramingType is one of 'frameType88023' or 'frameType88025', this is the type of framing asserted by the interface. When dot12DesiredFramingType is 'frameTypeEither', dot12CurrentFramingType shall be one of 'frameType88023' or 'frameType88025' when the dot12Status is 'opened'. When the dot12Status is anything other than 'opened', dot12CurrentFramingType shall take the value of 'frameTypeUnknown'." ::= { dot12ConfigEntry 1 } dot12DesiredFramingType OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2), frameTypeEither(3) } MAX-ACCESS read-write STATUS current Flick Standards Track [Page 15] RFC 2020 IEEE 802.12 Interface MIB October 1996 DESCRIPTION "The type of framing which will be requested by the interface during the next interface MAC initialization or open action. In master mode, this is the framing mode which will be granted by the interface. Note that for a master mode interface, this object must be equal to 'frameType88023' or 'frameType88025', since a master mode interface cannot grant 'frameTypeEither'." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aDesiredFramingType." ::= { dot12ConfigEntry 2 } dot12FramingCapability OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2), frameTypeEither(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of framing this interface is capable of supporting." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aFramingCapability." ::= { dot12ConfigEntry 3 } dot12DesiredPromiscStatus OBJECT-TYPE SYNTAX INTEGER { singleAddressMode(1), promiscuousMode(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to select the promiscuous mode that this interface will request in the next training packet issued on this interface. Whether the repeater grants the requested mode must be verified by examining the state of the PP bits in the corresponding instance of dot12LastTrainingConfig. Flick Standards Track [Page 16] RFC 2020 IEEE 802.12 Interface MIB October 1996 In master mode, this object controls whether or not promiscuous mode will be granted by the interface when requested by the lower level device. Note that this object indicates the desired mode for the next time the interface trains. The currently active mode will be reflected in dot12LastTrainingConfig and in ifPromiscuousMode." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aDesiredPromiscuousStatus." ::= { dot12ConfigEntry 4 } dot12TrainingVersion OBJECT-TYPE SYNTAX INTEGER (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "The value that will be used in the version bits (vvv bits) in training frames on this interface. This is the highest version number supported by this MAC." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aMACVersion." ::= { dot12ConfigEntry 5 } dot12LastTrainingConfig OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This 16 bit field contains the configuration bits from the most recent error-free training frame received during training on this interface. Training request frames are received when in master mode, while training response frames are received in slave mode. On master mode interfaces, this object contains the contents of the requested configuration field of the most recent training request frame. On slave mode interfaces, this object contains the contents of the allowed configuration field of the most recent training response frame. The format of the current version of this field is described in section 3.8. Please refer to the most recent version of the IEEE 802.12 standard for the most up-to-date definition Flick Standards Track [Page 17] RFC 2020 IEEE 802.12 Interface MIB October 1996 of the format of this object." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aLastTrainingConfig." ::= { dot12ConfigEntry 6 } dot12Commands OBJECT-TYPE SYNTAX INTEGER { noOp(1), open(2), reset(3), close(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "If the current value of dot12Status is 'closed', setting the value of this object to 'open' will change the corresponding instance of MIB-II's ifAdminStatus to 'up', cause this interface to enter the 'opening' state, and will cause training to be initiated on this interface. The progress and success of the open is given by the values of the dot12Status object. Setting this object to 'open' when dot12Status has a value other than 'closed' has no effect. Setting the corresponding instance of ifAdminStatus to 'up' when the current value of dot12Status is 'closed' will have the same effect as setting this object to 'open'. Setting ifAdminStatus to 'up' when dot12Status has a value other than 'closed' has no effect. Setting the value of this object to 'close' will move this interface into the 'closed' state and cause all transmit and receive actions to stop. This object will then have to be set to 'open' in order to reinitiate training. Setting the corresponding instance of ifAdminStatus to 'down' will have the same effect as setting this object to 'close'. Setting the value of this object to 'reset' when the current value of dot12Status has a value other than 'closed' will reset the interface. On a reset, all MIB counters should retain their values. Flick Standards Track [Page 18] RFC 2020 IEEE 802.12 Interface MIB October 1996 This will cause the MAC to initiate an acInitializeMAC action as specified in IEEE 802.12. This will cause training to be reinitiated on this interface. Setting this object to 'reset' when dot12Status has a value of 'closed' has no effect. Setting this object to 'reset' has no effect on the corresponding instance of ifAdminStatus. Setting the value of this object to 'noOp' has no effect. When read, this object will always have a value of 'noOp'." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.2, acOpen, acClose, acInitializeMAC. Also, RFC1231 IEEE802.5 Token Ring MIB, dot5Commands." ::= { dot12ConfigEntry 7 } dot12Status OBJECT-TYPE SYNTAX INTEGER { opened(1), closed(2), opening(3), openFailure(5), linkFailure(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current interface status with respect to training. One of the following values: opened - Training has completed successfully. closed - MAC has been disabled by setting dot12Commands to 'close'. opening - MAC is in training. Training signals have been received. openFailure - Passed 24 error-free packets, but there is a problem, noted in the training configuration bits (dot12LastTrainingConfig). linkFailure - Training signals not received, or could not pass 24 error-free packets. Flick Standards Track [Page 19] RFC 2020 IEEE 802.12 Interface MIB October 1996 Whenever the dot12Commands object is set to 'close' or ifAdminStatus is set to 'down', the MAC will go silent, dot12Status will be 'closed', and ifOperStatus will be 'down'. When the value of this object is equal to 'closed' and the dot12Commands object is set to 'open' or the ifAdminStatus object is set to 'up', training will be initiated on this interface. When the value of this object is not equal to 'closed' and the dot12Commands object is set to 'reset', training will be reinitiated on this interface. Note that sets of some other objects (e.g. dot12ControlMode) or external events (e.g. MAC protocol violations) may also cause training to be reinitiated on this interface. When training is initiated or reinitiated on an interface, the end node will send Training_Up to the master and initially go to the 'linkFailure' state and ifOperStatus will go to 'down'. When the master sends back Training_Down, dot12Status will change to the 'opening' state, and training packets will be transferred. After all of the training packets have been passed, dot12Status will change to 'linkFailure' if 24 consecutive error-free packets were not passed, 'opened' if 24 consecutive error-free packets were passed and the training configuration bits were OK, or 'openFailure' if there were 24 consecutive error-free packets, but there was a problem with the training configuration bits. When in the 'openFailure' state, the dot12LastTrainingConfig object will contain the configuration bits from the last training packet which can be examined to determine the exact reason for the training configuration failure. If training did not succeed (dot12Status is 'linkFailure' or 'openFailure), the entire process will be restarted after MAC_Retraining_Delay_Timer seconds. If training does succeed (dot12Status changes to Flick Standards Track [Page 20] RFC 2020 IEEE 802.12 Interface MIB October 1996 'opened'), ifOperStatus will change to 'up'. If training does not succeed (dot12Status changes to 'linkFailure' or 'openFailure'), ifOperStatus will remain 'down'." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aMACStatus." ::= { dot12ConfigEntry 8 } dot12ControlMode OBJECT-TYPE SYNTAX INTEGER { masterMode(1), slaveMode(2), learn(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to configure and report whether or not this interface is operating in master mode. In a Demand Priority network, end node interfaces typically operate in slave mode, while switch interfaces may control the Demand Priority protocol and operate in master mode. This object may be implemented as a read-only object by those agents and interfaces that do not implement software control of master mode. In particular, interfaces that cannot operate in master mode, and interfaces on which master mode is controlled by a pushbutton on the device, should implement this object read-only. Some interfaces do not require network management configuration of this feature and can autosense whether to use master mode or slave mode. The value 'learn' is used for that purpose. While autosense is taking place, the value 'learn' is returned. A network management operation which modifies the value of dot12ControlMode causes the interface to retrain." ::= { dot12ConfigEntry 9 } dot12StatTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot12StatEntry MAX-ACCESS not-accessible Flick Standards Track [Page 21] RFC 2020 IEEE 802.12 Interface MIB October 1996 STATUS current DESCRIPTION "Statistics for a collection of 802.12 interfaces attached to a particular system." ::= { dot12MIBObjects 2 } dot12StatEntry OBJECT-TYPE SYNTAX Dot12StatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for a particular interface to an 802.12 medium. The receive statistics in this table apply only to packets received by this station (i.e., packets whose destination address is either the local station address, the broadcast address, or a multicast address that this station is receiving, unless the station is in promiscuous mode)." INDEX { ifIndex } ::= { dot12StatTable 1 } Dot12StatEntry ::= SEQUENCE { dot12InHighPriorityFrames Counter32, dot12InHighPriorityOctets Counter32, dot12InNormPriorityFrames Counter32, dot12InNormPriorityOctets Counter32, dot12InIPMErrors Counter32, dot12InOversizeFrameErrors Counter32, dot12InDataErrors Counter32, dot12InNullAddressedFrames Counter32, dot12OutHighPriorityFrames Counter32, dot12OutHighPriorityOctets Counter32, dot12TransitionIntoTrainings Counter32, dot12HCInHighPriorityOctets Counter64, dot12HCInNormPriorityOctets Counter64, dot12HCOutHighPriorityOctets Counter64 } dot12InHighPriorityFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of high priority frames that have been received on this interface. Includes both good and bad high priority frames, Flick Standards Track [Page 22] RFC 2020 IEEE 802.12 Interface MIB October 1996 as well as high priority training frames. Does not include normal priority frames which were priority promoted." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aHighPriorityFramesReceived." ::= { dot12StatEntry 1 } dot12InHighPriorityOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in high priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InHighPriorityFrames. Note that this counter will roll over very quickly. It is provided for backward compatibility for Network Management protocols that do not support 64 bit counters (e.g. SNMP version 1)." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aHighPriorityOctetsReceived." ::= { dot12StatEntry 2 } dot12InNormPriorityFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of normal priority frames that have been received on this interface. Includes both good and bad normal priority frames, as well as normal priority training frames and normal priority frames which were priority promoted." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aNormalPriorityFramesReceived." ::= { dot12StatEntry 3 } dot12InNormPriorityOctets OBJECT-TYPE SYNTAX Counter32 Flick Standards Track [Page 23] RFC 2020 IEEE 802.12 Interface MIB October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in normal priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InNormPriorityFrames. Note that this counter will roll over very quickly. It is provided for backward compatibility for Network Management protocols that do not support 64 bit counters (e.g. SNMP version 1)." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aNormalPriorityOctetsReceived." ::= { dot12StatEntry 4 } dot12InIPMErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of frames that have been received on this interface with an invalid packet marker and no PMI errors. A repeater will write an invalid packet marker to the end of a frame containing errors as it is forwarded through the repeater to the other ports. This counter is incremented by one for each frame received on this interface which has had an invalid packet marker added to the end of the frame." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aIPMFramesReceived." ::= { dot12StatEntry 5 } dot12InOversizeFrameErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of oversize frames received on this interface. This counter is incremented by one for each frame received on Flick Standards Track [Page 24] RFC 2020 IEEE 802.12 Interface MIB October 1996 this interface whose OctetCount is larger than the maximum legal frame size. The frame size which causes this counter to increment is dependent on the current framing type." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aOversizeFramesReceived." ::= { dot12StatEntry 6 } dot12InDataErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of errored frames received on this interface. This counter is incremented by one for each frame received on this interface with any of the following errors: bad FCS (with no IPM), PMI errors (excluding frames with an IPM as the only PMI error), undersize, bad start of frame delimiter, or bad end of packet marker. Does not include frames counted by dot12InIPMErrors, dot12InNullAddressedFrames, or dot12InOversizeFrameErrors. This counter indicates problems with the cable directly attached to this interface, while dot12InIPMErrors indicates problems with remote cables." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aDataErrorFramesReceived." ::= { dot12StatEntry 7 } dot12InNullAddressedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of null addressed frames received on this interface. This counter is incremented by one for each frame received on this interface with a destination MAC address consisting of all zero bits. Both void and training frames are included in this counter. Note that since this station would normally not Flick Standards Track [Page 25] RFC 2020 IEEE 802.12 Interface MIB October 1996 receive null addressed frames, this counter is only incremented when this station is operating in promiscuous mode or in training." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aNullAddressedFramesReceived." ::= { dot12StatEntry 8 } dot12OutHighPriorityFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each high priority frame successfully transmitted out this interface." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aHighPriorityFramesTransmitted." ::= { dot12StatEntry 9 } dot12OutHighPriorityOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by OctetCount for each frame counted by dot12OutHighPriorityFrames. Note that this counter will roll over very quickly. It is provided for backward compatibility for Network Management protocols that do not support 64 bit counters (e.g. SNMP version 1)." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aHighPriorityOctetsTransmitted." ::= { dot12StatEntry 10 } dot12TransitionIntoTrainings OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of times this interface has entered the training state. This counter is incremented by one each time dot12Status transitions to 'linkFailure' from any Flick Standards Track [Page 26] RFC 2020 IEEE 802.12 Interface MIB October 1996 state other than 'opening' or 'openFailure'." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aTransitionsIntoTraining." ::= { dot12StatEntry 11 } dot12HCInHighPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in high priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InHighPriorityFrames. This counter is a 64 bit version of dot12InHighPriorityOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2)." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aHighPriorityOctetsReceived." ::= { dot12StatEntry 12 } dot12HCInNormPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in normal priority frames that have been received on this interface. This counter is incremented by OctetCount for each frame received on this interface which is counted by dot12InNormPriorityFrames. This counter is a 64 bit version of dot12InNormPriorityOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2)." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aNormalPriorityOctetsReceived." ::= { dot12StatEntry 13 } Flick Standards Track [Page 27] RFC 2020 IEEE 802.12 Interface MIB October 1996 dot12HCOutHighPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by OctetCount for each frame counted by dot12OutHighPriorityFrames. This counter is a 64 bit version of dot12OutHighPriorityOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2)." REFERENCE "IEEE Standard 802.12-1995, 13.2.5.2.1, aHighPriorityOctetsTransmitted." ::= { dot12StatEntry 14 } -- conformance information dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 } dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 } dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 } -- compliance statements dot12Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for managed network entities that have 802.12 interfaces." MODULE -- this module MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup } OBJECT dot12DesiredFramingType MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required." OBJECT dot12DesiredPromiscStatus MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required." OBJECT dot12Commands MIN-ACCESS read-only DESCRIPTION Flick Standards Track [Page 28] RFC 2020 IEEE 802.12 Interface MIB October 1996 "Write access to this object is not required." OBJECT dot12ControlMode MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required." ::= { dot12Compliances 1 } -- units of conformance dot12ConfigGroup OBJECT-GROUP OBJECTS { dot12DesiredFramingType, dot12FramingCapability, dot12DesiredPromiscStatus, dot12TrainingVersion, dot12LastTrainingConfig, dot12Commands, dot12Status, dot12CurrentFramingType, dot12ControlMode } STATUS current DESCRIPTION "A collection of objects for managing the status and configuration of IEEE 802.12 interfaces." ::= { dot12Groups 1 } dot12StatsGroup OBJECT-GROUP OBJECTS { dot12InHighPriorityFrames, dot12InHighPriorityOctets, dot12InNormPriorityFrames, dot12InNormPriorityOctets, dot12InIPMErrors, dot12InOversizeFrameErrors, dot12InDataErrors, dot12InNullAddressedFrames, dot12OutHighPriorityFrames, dot12OutHighPriorityOctets, dot12TransitionIntoTrainings, dot12HCInHighPriorityOctets, dot12HCInNormPriorityOctets, dot12HCOutHighPriorityOctets } STATUS current DESCRIPTION "A collection of objects providing statistics for IEEE 802.12 interfaces." ::= { dot12Groups 2 } END Flick Standards Track [Page 29] RFC 2020 IEEE 802.12 Interface MIB October 1996 5. Acknowledgements This document was produced by the IETF 100VG-AnyLAN Working Group. It is based on the work of IEEE 802.12. 6. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824 (December, 1987). [2] 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, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [3] 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, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [4] 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, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] McCloghrie, K., and M. Rose, "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. [6] IEEE, "Demand Priority Access Method, Physical Layer and Repeater Specifications for 100 Mb/s Operation", IEEE Standard 802.12-1995" [7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [8] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", STD 50, RFC 1643, FTP Software, Inc., July, 1994. Flick Standards Track [Page 30] RFC 2020 IEEE 802.12 Interface MIB October 1996 [9] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2", RFC 1650, FTP Software, Inc., August, 1994. [10] McCloghrie, K., and Decker, E., "IEEE 802.5 MIB using SMIv2", RFC 1748, Cisco Systems, Inc., December, 1994. [11] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station Source Routing MIB using SMIv2", RFC 1749, Cisco Systems, Inc., December, 1994. 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address John Flick Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 Phone: +1 916 785 4018 Email: johnf@hprnd.rose.hp.com Flick Standards Track [Page 31] snmp-mibs-downloader-1.1/mibrfcs/rfc2024.txt0000644000000000000000000052360011402176071015557 0ustar Network Working Group D. Chen, Editor Request for Comments: 2024 P. Gayek Category: Standards Track IBM S. Nix Metaplex, Inc. October 1996 Definitions of Managed Objects for Data Link Switching using SMIv2 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. Abstract This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw) [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI [2], and semantically identical to the SNMPv1 definitions [3]. Table of Contents 1.0 The SNMPv2 Network Management Framework . . . . . . . . . 2 1.1 Object Definitions . . . . . . . . . . . . . . . . . . . . 2 2.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Relation to Interface Group (RFC 1573) [8] . . . . . . . . . 2 2.2 Relation to Underlying DLC Layer . . . . . . . . . . . . . 3 2.3 Relation to SDLC MIB (RFC 1747) . . . . . . . . . . . . . 3 2.4 DLSw MIB Structure . . . . . . . . . . . . . . . . . . . . 4 2.4.1 Compliance . . . . . . . . . . . . . . . . . . . . . . 4 2.5 DLSw MIB Usage . . . . . . . . . . . . . . . . . . . . . . 5 2.5.1 Cooperative DLSw nodes . . . . . . . . . . . . . . . . 5 2.5.2 Setting capabilities exchange-related objects . . . . 5 2.5.3 Examples of Tasks Using This MIB . . . . . . . . . . . 6 3.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 4.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 89 5.0 References . . . . . . . . . . . . . . . . . . . . . . . . 89 6.0 Security Considerations . . . . . . . . . . . . . . . . . 90 Chen, et. al. Standards Track [Page 1] RFC 2024 DLSw MIB using SMIv2 October 1996 7.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 90 1.0 The SNMPv2 Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: RFC 1902 [2] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 17, RFC 1213 [4] defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15, RFC 1157 [5] and RFC 1905 [6] which define two versions of the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. 2.0 Overview This memo identifies the set of objects for configuring, monitoring, and controlling Data Link Switches. 2.1 Relation to Interface Group (RFC 1573) [8] o ifIndex is used as the index into dlswIfTable, which shows and controls the interfaces that DLSw is active on. o Local entries in the MAC address and NetBIOS (NB) name caches can point to an ifEntry to indicate the interface through which DLSw can reach that MAC address or NB name. See the objects dlswDirMacLocation and dlswDirNBLocation. o Local entries in the circuit table use ifIndex to indicate the interface through which DLSw is connected to the local end station. Chen, et. al. Standards Track [Page 2] RFC 2024 DLSw MIB using SMIv2 October 1996 See the object dlswCircuitS1Index. o ifIndex is the primary index into dlswSdlcLsTable, which lists the SDLC stations DLSw is serving. 2.2 Relation to Underlying DLC Layer The DLSw MIB does not duplicate the information in the MIBs for the DLC layer underneath it. Instead, each circuit table entry contains a pointer to a conceptual row in an underlying enterprise-specific or standard DLC MIB. Using the 802.2 LLC management as an example, the following rules should be considered when developing new DLSw related DLC MIBs, and when implementing the interactions between DLSw MIB and DLC MIBs: o The referenced row should represent the local LLC-2 (and/or LLC-1, if supported) link station that DLSw is using. In the current 802.2 LLC MIB draft, this might be a row of one of the tables llcCcAdminTable, llcCcOperTable, or llcCcStatsTable. A circuit using local LLC services will therefore have dlswCircuitS1DlcType = llc, and dlswCircuitS1Dlc = pointer to an LLC MIB table row. o Because DLSw is the user of LLC services, it is generally preferable to initiate administrative actions using the DLSw MIB and allow DLSw to control LLC directly, rather than starting with LLC MIB administrative actions. For example, a hung circuit should be disconnected by setting dlswCircuitState, as opposed to setting llcCcAdminStatus to disable the LLC part of the circuit. Similarly, setting bits in dlswIfSapList will cause row creation in llcSapOperTable as well as set the necessary DLSw-LLC relationship. 2.3 Relation to SDLC MIB (RFC 1747) The general comments stated in 2.2, "Relation to Underlying DLC Layer" apply to the SDLC MIB. The following apply if the DLSw MIB is implemented in a product that also implements RFC 1747 [9]: o The row referenced from dlswCircuitS1Dlc should represent the local SDLC link station that DLSw is using. This might be a row of one of the tables sdlcLSAdminTable, sdlcLSOperTable, or sdlcLSStatsTable. A circuit using local SDLC services will therefore have dlswCircuitS1DlcType = sdlc, and dlswCircuitS1Dlc = OID of one of these table rows. Chen, et. al. Standards Track [Page 3] RFC 2024 DLSw MIB using SMIv2 October 1996 o dlswSdlcLsTable uses the same indices that are used to index link station information in RFC 1747. This table provides a mapping between this native SDLC addressing (interface, link station address) and the addressing used in the DLSw domain (local MAC and SAP). 2.4 DLSw MIB Structure See 3 .0, "Definitions" on page 11 for a diagram outlining the DLSw MIB structure. The following groups of objects are included: dlswNode Objects related to this DLSw node's configuration, monitoring and control. dlswTConn Objects relating to transport connections to this DLSw's partner nodes. dlswInterface Objects configured for this DLSw relating to its local interfaces. dlswDirectory Objects reflecting this DLSw's view of where end-station resources (MAC addresses and NetBIOS names) are located. dlswCircuit Objects showing the end-station connections that DLSw currently has established, or that are coming up or have gone down. dlswSDLC Objects configured for this DLSw's SDLC-attached end stations. 2.4.1 Compliance The MIB provides the following compliance statements: dlswCoreCompliance Defines the minimum support required of all implementations. Note that for this and the other compliance statements, NetBIOS-related objects are grouped separately because the DLSw Version 1 Standard [1] does not require NetBIOS support. dlswTConnTCPCompliance Defines the minimum support required of implementations that use TCP as a transport protocol. dlswDirCompliance Defines the minimum support required of implementations that support some sort of Chen, et. al. Standards Track [Page 4] RFC 2024 DLSw MIB using SMIv2 October 1996 directory function. dlswDirLocateCompliance Defines the minimum support required of implementations that support a directory function and also support the ordered retrieval of the entries that match a given resource. dlswSdlcCompliance Defines the minimum support required of implementations that support SDLC-attached end stations. 2.5 DLSw MIB Usage 2.5.1 Cooperative DLSw nodes To reduce the size of the MIB, thus the amount of data that each agent needs to keep, the information that usually could be made available in two partner nodes (e.g., information exchanged between them) is only defined in the MIB as the info received. That is, there are no objects defined for the info sent. In order to form the complete picture of the state of a resource, the manager needs to retrieve info from multiple DLSw nodes. An example is that the SAP list, NETBIOS list and MAC list are kept at the receiving end of a DLSw capabilities exchange (the sender does not save what it sent to each partner). Note well: The DLSw protocol does not specify a technique for a manager to correlate the transport address of the partner managed DLSw node and the transport address that the management protocol uses. 2.5.2 Setting capabilities exchange-related objects This MIB supports changes to DLSw variables whose change should be reported to DLSw partner nodes in a "run-time" capabilities exchange. Since a DLSw node normally unicasts these capabilities messages to all its active partners, frequent changes to these variables can result in excessive network traffic. To avoid this problem, developers of network management applications using this MIB should try to group all such changes in a few SNMP SET requests, and should send them in bulk. Agent developers should implement a technique to group a number of changes into a single capabilities exchange message. One possible approach is to send a run-time capabilities message only if no capabilities-related changes have been received for a pre-defined period of time. Chen, et. al. Standards Track [Page 5] RFC 2024 DLSw MIB using SMIv2 October 1996 2.5.3 Examples of Tasks Using This MIB 2.5.3.1 Configuring DLSw to actively connect to a specific TCP/IP partner Create a conceptual row in dlswTConnConfigTable with: Index = the highest the managed station has used so far + 1; TDomain = dlswTCPDomain; LocalTAddr = this node's DLSw IP address; RemoteTAddr = the partner's DLSw IP address; EntryType = individual; SetupType = activePersistent. Note that determining the index to use may require dumping the TConnConfigTable, but this will not typically be a large table. If the DLSw node rejects the row creation due to index collision, the management station should increment its index value and try again. 2.5.3.2 Configuring DLSw to passively accept any partner Create a conceptual row in dlswTConnConfigTable as above but with: RemoteTAddr = 0; EntryType = global; SetUpType = passive. Every individual transport connection accepted as a result of this global row will inherit the configuration values from this row. To prevent a specific remote node from being passively accepted as a partner, create another row with: RemoteTAddr = that node's IP address; EntryType = individual; SetupType = excluded. 2.5.3.3 Configuring DLSw to allow or connect to a group of partners Define a conceptual row in dlswTConnConfigTable as above but with: EntryType = group; GroupDefinition = pointer to an enterprise- specific representation of a group. For example, a group definition might consist of an IP address value and mask, or a multicast IP address. Every individual transport connection accepted as a result of this group row will inherit the configuration values from this row. When a group is created that has some overlap with entries where EntryType = individual (there will always be this overlap when a global row exists), the DLSw node must use the configured rows using a "most specific match wins" rule. That is, the entry in TConnConfigTable with the remote address most nearly matching an incoming connection should be used to provide the values for the new connection. For equal matches, the choice of TConnConfigTable entry is up to the DLSw node implementation. Note that the management station should never create two TConnConfig rows with duplicate remote addressing values. Chen, et. al. Standards Track [Page 6] RFC 2024 DLSw MIB using SMIv2 October 1996 2.5.3.4 Identifying the protocol level of a partner DLSw If the partner DLSw has implemented at least the AIW Version 1 DLSw Standard [1], the AIW version and release number for the DLSw protocol is accessible from dlswTConnOperPartnerVersion. If TConnOperPartnerVersion is a string of zero length but the TConnOperState = `connected' state (i.e., is not still performing capabilities exchange), the partner DLSw can be assumed to be an RFC 1434+ node. 2.5.3.5 Recycling a transport connection Quiesce or forcibly disconnect the transport connection by setting TConnOperState to `quiescing' or `disconnecting', and monitor until it moves to the `disconnected' state or the TConnOper row disappears. The row may disappear because implementations are not required to maintain transport connection information after a transport connection has gone down. The action required to re-activate the transport connection depends on the value of TConnConfigSetupType for the relevant TConnConfig row. ActivePersistent connections will attempt to come back automatically. Passive connections must be re-established from the remote partner. ActiveOnDemand connections will be re-established by this node, but only after some end-station operation triggers a circuit setup attempt. 2.5.3.6 Investigating why a transport connection went down TConnOperDiscTime and TConnOperDiscReason provide the vital information of the time and the cause of the disconnection of a transport connection and TConnOperDiscActiveCir indicates whether end users may have been affected. This MIB does not specify the duration that an agent must make this information available after the disconnection of a transport connection occurs. Manager should try the agent of the partner DLSw, if such information is not available in one DLSw node. Additional information might come from the MIB for the transport protocol (e.g., TCP or LLC). dlswTConnStat* and dlswTConnConfigOpens give a more general picture of transport connection activity, but can't give specific reasons for problems. 2.5.3.7 Changing the configuration of an active transport connection Follow this sequence of managment protocol set operations: 1. Use TConnOperConfigIndex to locate the TConnConfig entry that governs the configuration of the transport connection. Chen, et. al. Standards Track [Page 7] RFC 2024 DLSw MIB using SMIv2 October 1996 2. Change the rowStatus of that conceptual row to notInService. This prevents the transport connection from being connected automatically if TConnConfigSetupType = activePersistent. 3. Quiesce or forcibly disconnect the transport connection by setting TConnOperState to `quiescing' or `disconnecting', and monitor until it moves to the `disconnected' state or the TConnOper row disappears. 4. Change the values of TConnConfig variables as desired. 5. Change the rowStatus of the TConnConfig conceptual row to active. TConnConfigSetupType will subsequently control whether this node will actively seek to re-establish the transport connection, or will wait. 2.5.3.8 Checking configuration validity for an active transport connection Use TConnOperConfigIndex to identify the row of TConnConfig for the transport connection. If TConnConfigLastModifyTime is greater than TConnOperConnectTime, then one or more of the variables in the TConnConfig row may not be valid for the current state of the active transport connection. This is an exception condition and will not normally be the case. 2.5.3.9 Configuring the interfaces and SAPs DLSw will use To add DLSw end-station support (not transport connection support) to an interface, create a conceptual row for that ifIndex in the dlswIfTable. For many products, you will specify the same single virtual segment number for all interfaces. Indicate the list of SAPs to be supported by that interface - this could be all 0xFFs if the product has some automatic SAP opening function. To open or close a SAP to DLSw on an existing interface, simply set or reset the appropriate bit in dlswIfSapList in the table row for that interface. 2.5.3.10 Configuring static MAC address (or NetBIOS name) cache entries It is common to configure a few static directory entries to preload in the caches of the DLSw nodes and reduce the need for broadcast searches. The following example adds entries to the MAC cache to indicate that a specific MAC address is reachable through two different remote partners: 1. The manager retrieves dlswDirMacCacheNextIndex to get an index assignment from the DLSw node. The DLSw node ensures that the retrieved index will not be reused. Chen, et. al. Standards Track [Page 8] RFC 2024 DLSw MIB using SMIv2 October 1996 2. The manager creates a conceptual row in dlswDirMacTable with: Index = the retrieved index; Mac = the MAC address; Mask = all 0xFF's; EntryType = userConfiguredPublic; LocationType = remote; Location = OID for dlswTConnConfigEntry of the 1st partner; Status = unknown (recommended for new entries). 3. The manager repeats the preceding 2 steps and creates a second row using Index = second index retrieved; Location = OID for dlswTConnConfigEntry of the 2nd partner. Note that the DLSw node is not obligated to use newly created directory entries in the order in which they were created. It is recommended that entries be used in most-specific match first order, i.e., an entry with a Mask of all 0xFFs should take precedence over one with a "partial wildcard". The relative order of static versus dynamic entries and of "equal length" matches is up to the DLSw implementation. The dlswDirStat objects can be used to get an idea of the success rate for a particular static caching scheme. 2.5.3.11 Seeing where the directory indicates a given resource is To retrieve all directory information related to a given resource (in this example, a NetBIOS name), the management station should: 1. Retrieve dlswDirLocateNBLocation in the dlswDirLocateNBTable entry where NBName = the fully-specified NetBIOS name without wildcards; NBMatch = 1. 2. Use the returned value (i.e., OID) to retrieve the contents of the dlswDirNBEntry itself. 3. Repeat the previous two steps with NBMatch = 2, 3, ..., until the end of dlswDirLocateNBTable is reached. The DLSw node conveys the precedence relationship of the different matching directory entries by the order in which it returns their OIDs. 2.5.3.12 Investigating circuit bringup failure Circuit bringup takes place in two stages: explorer flows to locate the target resource (MAC address or NetBIOS name); and establishing the circuit itself. To determine the success of explorer flows, have the origin end station initiate a link establishment to the target, and look later for cache entries for the target MAC address or NetBIOS name. The dlswTConn*ex* counters also give some visibility to which transport connections are being used to look for resources. Once circuit establishment is started, an entry of dlswCircuitTable for the two MAC/SAP addresses involved is created. Chen, et. al. Standards Track [Page 9] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswCircuitEntryTime, StateTime, and State may provide useful information about intermediate states the circuit is reaching before becoming disconnected again. 2.5.3.13 Investigating the failure of an established circuit The variables dlswCircuitDiscReason* in the dlswCircuitTable provide the key information of the cause of the disconnection of circuits. In addition, the underlying DLC MIBs may provide information at the link station level, and some clues (e.g., DISC or FRMR counters) at the SAP or interface level. 2.5.3.14 Seeing circuit-level traffic statistics Locate the relevant dlswCircuitEntry and follow dlswCircuitS1Dlc to a link station-level table entry in the underlying DLC MIB. Move to the corresponding link station's statistics table in the DLC MIB to get counters of frames, bytes, etc. for this circuit. 2.5.3.15 Cutting down the flow of DLSw-related traps Set some or all of the dlswTrapCntl* objects to the value of `disabled' or `partial'. Chen, et. al. Standards Track [Page 10] RFC 2024 DLSw MIB using SMIv2 October 1996 3.0 Definitions -- ******************************************************************* -- -- The structure of the DLSw MIB (t: indicates table): -- DLSw MIB -- |-- Node Group -- | |-- Node Identity -- | |-- Node Operational Related -- | |-- Node Resource -- | -- |-- Transport Connection Group -- | |-- Statistics -- | |t- Transport Connection Configuration -- | |t- Transport Connection Operation -- | | |-- capabilities -- | | |-- Supported SAP List -- | | |-- statistics -- | | |-- transport connection itself -- | | |-- traffic over the transport connection -- | | |-- directory search activities -- | | |-- search filtered statistics -- | | |-- circuits over the transport connection -- | |-- Transport Specific -- | |-- Tcp -- | |t- Transport Connection Config (Tcp Specific) -- | |t- Transport Connection Operation (Tcp Specific) -- | -- |-- Interface Group -- | |t- interfaces that DLSw is active on. -- | -- |-- Directory Group -- | |-- Statistics -- | |-- Directory Cache -- | | |t- Directory of MAC addresses -- | | |t- Directory of NETBIOS names -- | |-- Locate -- | |t- Directory of Locate MAC -- | |t- Directory of Locate NETBIOS -- | -- |-- Circuit Group -- | |-- Statistics -- | |t- Circuits -- | -- |-- Virtual and non-LAN end stations -- | |t- SDLC end station -- | -- ******************************************************************* Chen, et. al. Standards Track [Page 11] RFC 2024 DLSw MIB using SMIv2 October 1996 -- ******************************************************************* -- This MIB module contains objects necessary for management of Data -- Link Switches. -- -- Terminology: -- (1) DLSw: -- A device which provides data link switching function. -- Sometimes it is referred as a DLSw or DLSw node. -- Local DLSw: The DLSw that the DLSw SNMP Agent is running on. -- Partner DLSw (or DLSw partner): A DLSw node that is "transport -- connected" with the local DLSw. Sometimes the term "DLSw -- partners" is used to indicate the two ends of a transport -- connection. -- -- (2) TCP Connection: -- Full-duplex (-capable) association defined by a pair of -- (IP address, port) pairs, running the TCP protocol. The port -- addresses in RFC 1795 define two TCP connections between -- a pair of DLSw nodes, each being used to send data in a -- single direction. -- Local: This end of TCP connection -- Foreign: Remote end of TCP connection -- -- (3) Transport Connection: -- It is a generic term for a full-duplex reliable connection -- between DLSw nodes. This term is used to refer to the -- association between DLSw nodes without being concerned -- about whether TCP is the protocol or whether there are -- one or two TCP connection. -- (Note: for two TCP connections, the transport connection is -- opened if and only if both TCP connections are operational. -- Also note: sometimes race conditions will occur, but the -- condition should only be temporary.) -- -- (4) Data Link: -- An instance of OSI layer-2 procedures for exchanging information -- using either connection-oriented (e.g., LLC-2) or connectionless -- (e.g., LLC-1) services. A DLSw node or pair of partner nodes -- switches data traffic from stations of one data link to -- stations of another data link. Data link switching is -- transparent to end stations. -- Source: the end station which sends a message. -- Destination: the end station which receives a message. -- (This DLSw role is with respect to a give message) -- -- (5) Circuit: -- End-to-end association of two DLC entities through one or -- two DLSw nodes. A circuit is the concatenation of two Chen, et. al. Standards Track [Page 12] RFC 2024 DLSw MIB using SMIv2 October 1996 -- "data links", optionally with an intervening transport -- connection. -- Origin: the end station which initiates the circuit. -- Target: the end station which receives the initiation. -- -- (6) Link Station: -- It is one end of an LLC-2 connection. It performs error -- recovery procedure, retries, and various timers. -- DLSw terminates LLC-2 connection at each end of DLSw nodes, -- thus, keepAlive and error recovery on LLC-2 connections are -- kept to each side of LAN and do not flow through the WAN. -- A link station is substantiated when SABME is sent/received. -- All link stations have circuits, but not all circuits -- have link stations. -- -- Key assumptions are: -- (1) The MIB is designed to manage a single DLSw entity. -- -- (2) A DLSw may support various types of transport connections. -- - This DLSw MIB module does not restrict the possibility to -- have, at any given moment, more than one "transport -- connection" defined or active between two DLSw's. -- - However, current DLSw architecture does not provide a mechanism, -- e.g., DLSw host name, to prevent two transport connections of -- different types between the same two DLSw's. -- -- (3) This MIB assumes that interface MIB is implemented. ifIndex -- is used in this MIB module. -- -- (4) This MIB assumes that the SDLC MIB (or an equivalent enterprise -- specific MIB) is implemented, since SDLC-specific objects -- are not duplicated here. -- -- (5) This MIB assumes that the LLC-2 MIB (or an equivalent enterprise -- specific MIB) is implemented, since LLC-related objects are not -- duplicated here. -- -- (6) All MACs, SAPs, Ring numbers, ... are in non-canonical form. -- That is, the most significant bit will be transmitted first. -- -- ******************************************************************* DLSW-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString, RowStatus, RowPointer, TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC Chen, et. al. Standards Track [Page 13] RFC 2024 DLSw MIB using SMIv2 October 1996 Counter32, Gauge32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB sdlcLSAddress FROM SNA-SDLC-MIB; dlsw MODULE-IDENTITY LAST-UPDATED "9606040900Z" ORGANIZATION "AIW DLSw MIB RIGLET and IETF DLSw MIB Working Group" CONTACT-INFO "David D. Chen IBM Corporation 800 Park, Highway 54 Research Triangle Park, NC 27709-9990 Tel: 1 919 254 6182 E-mail: dchen@vnet.ibm.com" DESCRIPTION "This MIB module contains objects to manage Data Link Switches." ::= { mib-2 46 } dlswMIB OBJECT IDENTIFIER ::= { dlsw 1 } dlswDomains OBJECT IDENTIFIER ::= { dlsw 2 } -- ******************************************************************* -- Textual convention definitions -- ******************************************************************* NBName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a single qualified NetBIOS name, which can include `don't care' and `wildcard' characters to represent a number of real NetBIOS names. If an individual character position in the qualified name contains a `?', the corresponding character position in a real NetBIOS name is a `don't care'. If the qualified name ends in `*', the remainder of a real NetBIOS name is a `don't care'. `*' is only considered a wildcard if it appears at the end of a name." SYNTAX OCTET STRING (SIZE (0..16)) MacAddressNC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents an 802 MAC address represented in Chen, et. al. Standards Track [Page 14] RFC 2024 DLSw MIB using SMIv2 October 1996 non-canonical format. That is, the most significant bit will be transmitted first. If this information is not available, the value is a zero length string." SYNTAX OCTET STRING (SIZE (0 | 6)) TAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. For dlswTCPDomain, a TAddress is 4 octets long, containing the IP-address in network-byte order." SYNTAX OCTET STRING (SIZE (0..255)) EndStationLocation ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Representing the location of an end station related to the managed DLSw node." SYNTAX INTEGER { other (1), internal (2), -- local virtual MAC address remote (3), -- via DLSw partner local (4) -- locally attached } DlcType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Representing the type of DLC of an end station, if applicable." SYNTAX INTEGER { other (1), -- not assigned yet na (2), -- not applicable llc (3), -- 802.2 Logical Link Control sdlc (4), -- SDLC qllc (5) -- QLLC } LFSize ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The largest size of the INFO field (including DLC header, not including any MAC-level or framing octets). 64 valid values as defined by the IEEE 802.1D Addendum are acceptable." SYNTAX INTEGER { lfs516(516), lfs635(635), lfs754(754), lfs873(873), lfs993(993), lfs1112(1112), lfs1231(1231), Chen, et. al. Standards Track [Page 15] RFC 2024 DLSw MIB using SMIv2 October 1996 lfs1350(1350), lfs1470(1470), lfs1542(1542), lfs1615(1615), lfs1688(1688), lfs1761(1761), lfs1833(1833), lfs1906(1906), lfs1979(1979), lfs2052(2052), lfs2345(2345), lfs2638(2638), lfs2932(2932), lfs3225(3225), lfs3518(3518), lfs3812(3812), lfs4105(4105), lfs4399(4399), lfs4865(4865), lfs5331(5331), lfs5798(5798), lfs6264(6264), lfs6730(6730), lfs7197(7197), lfs7663(7663), lfs8130(8130), lfs8539(8539), lfs8949(8949), lfs9358(9358), lfs9768(9768), lfs10178(10178), lfs10587(10587), lfs10997(10997), lfs11407(11407), lfs12199(12199), lfs12992(12992), lfs13785(13785), lfs14578(14578), lfs15370(15370), lfs16163(16163), lfs16956(16956), lfs17749(17749), lfs20730(20730), lfs23711(23711), lfs26693(26693), lfs29674(29674), lfs32655(32655), lfs38618(38618), lfs41600(41600), lfs44591(44591), lfs47583(47583), lfs50575(50575), lfs53567(53567), lfs56559(56559), lfs59551(59551), lfs65535(65535) } null OBJECT IDENTIFIER ::= { 0 0 } -- ******************************************************************* -- DLSw Transport Domain definitions -- ******************************************************************* -- DLSw over TCP dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 } -- for an IP address of length 4: -- -- octets contents encoding -- 1-4 IP-address network-byte order -- DlswTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents the IP address of a DLSw which uses TCP as a transport protocol." SYNTAX OCTET STRING (SIZE (4)) -- ******************************************************************* -- DLSw MIB Definition -- ******************************************************************* Chen, et. al. Standards Track [Page 16] RFC 2024 DLSw MIB using SMIv2 October 1996 -- The DLSw MIB module contains an object part and a conformance part. -- Object part is organized in the following groups: -- (1) dlswNode -- information about this DLSw -- (2) dlswTConn -- about adjacent DLSw partners -- (3) dlswInterface -- about which interfaces DLSw is active on -- (4) dlswDirectory -- about any directory of local/remote resources -- (5) dlswCircuit -- about established circuits. -- (6) dlswSdlc -- about SDLC data link switched devices dlswNode OBJECT IDENTIFIER ::= { dlswMIB 1 } dlswTConn OBJECT IDENTIFIER ::= { dlswMIB 2 } dlswInterface OBJECT IDENTIFIER ::= { dlswMIB 3 } dlswDirectory OBJECT IDENTIFIER ::= { dlswMIB 4 } dlswCircuit OBJECT IDENTIFIER ::= { dlswMIB 5 } dlswSdlc OBJECT IDENTIFIER ::= { dlswMIB 6 } -- SDLC -- ******************************************************************* -- THE NODE GROUP -- ******************************************************************* -- ------------------------------------------------------------------- -- DLSw Node Identity -- ------------------------------------------------------------------- dlswNodeVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the particular version of the DLSw standard supported by this DLSw. The first octet is a hexadecimal value representing the DLSw standard Version number of this DLSw, and the second is a hexadecimal value representing the DLSw standard Release number. This information is reported in DLSw Capabilities Exchange." REFERENCE "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswNode 1 } dlswNodeVendorID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the manufacturer's IEEE-assigned organizationally Unique Identifier (OUI) of this DLSw. This information is reported in DLSw Capabilities Exchange." REFERENCE Chen, et. al. Standards Track [Page 17] RFC 2024 DLSw MIB using SMIv2 October 1996 "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswNode 2 } dlswNodeVersionString OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "This string gives product-specific information about this DLSw (e.g., product name, code release and fix level). This flows in Capabilities Exchange messages." REFERENCE "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswNode 3 } -- ------------------------------------------------------------------- -- DLSw Code Capability -- ------------------------------------------------------------------- dlswNodeStdPacingSupport OBJECT-TYPE SYNTAX INTEGER { none (1), -- does not support DLSw -- Standard pacing scheme adaptiveRcvWindow (2), -- the receive window size -- varies fixedRcvWindow (3) -- the receive window size -- remains constant } MAX-ACCESS read-only STATUS current DESCRIPTION "Circuit pacing, as defined in the DLSw Standard, allows each of the two DLSw nodes on a circuit to control the amount of data the other is permitted to send to them. This object reflects the level of support the DLSw node has for this protocol. (1) means the node has no support for the standard circuit pacing flows; it may use RFC 1434+ methods only, or a proprietary flow control scheme. (2) means the node supports the standard scheme and can vary the window sizes it grants as a data receiver. (3) means the node supports the standard scheme but never varies its receive window size." ::= { dlswNode 4 } -- ------------------------------------------------------------------- -- DLSw Node Operational Objects -- ------------------------------------------------------------------- dlswNodeStatus OBJECT-TYPE SYNTAX INTEGER { active (1), Chen, et. al. Standards Track [Page 18] RFC 2024 DLSw MIB using SMIv2 October 1996 inactive (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The status of the DLSw part of the system. Changing the value from active to inactive causes DLSw to take the following actions - (1) it disconnects all circuits through all DLSw partners, (2) it disconnects all transport connections to all DLSw partners, (3) it disconnects all local DLC connections, and (4) it stops processing all DLC connection set-up traffic. Since these are destructive actions, the user should query the circuit and transport connection tables in advance to understand the effect this action will have. Changing the value from inactive to active causes DLSw to come up in its initial state, i.e., transport connections established and ready to bring up circuits." ::= { dlswNode 5 } dlswNodeUpTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time (in hundredths of a second) since the DLSw portion of the system was last re-initialized. That is, if dlswState is in the active state, the time the dlswState entered the active state. It will remain zero if dlswState is in the inactive state." ::= { dlswNode 6 } dlswNodeVirtualSegmentLFSize OBJECT-TYPE SYNTAX LFSize MAX-ACCESS read-write STATUS current DESCRIPTION "The largest frame size (including DLC header and info field but not any MAC-level or framing octets) this DLSw can forward on any path through itself. This object can represent any box- level frame size forwarding restriction (e.g., from the use of fixed-size buffers). Some DLSw implementations will have no such restriction. This value will affect the LF size of circuits during circuit creation. The LF size of an existing circuit can be found in Chen, et. al. Standards Track [Page 19] RFC 2024 DLSw MIB using SMIv2 October 1996 the RIF (Routing Information Field)." DEFVAL { lfs65535 } ::= { dlswNode 7 } -- ................................................................... -- NETBIOS Resources -- ................................................................... dlswNodeResourceNBExclusivity OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The value of true indicates that the NetBIOS Names configured in dlswDirNBTable are the only ones accessible via this DLSw. If a node supports sending run-time capabilities exchange messages, changes to this object should cause that action. It is up to the implementation exactly when to start the run-time capabilities exchange." ::= { dlswNode 8 } -- ................................................................... -- MAC Address List -- ................................................................... dlswNodeResourceMacExclusivity OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The value of true indicates that the MAC addresses configured in the dlswDirMacTable are the only ones accessible via this DLSw. If a node supports sending run-time capabilities exchange messages, changes to this object should cause that action. It is up to the implementation exactly when to start the run-time capabilities exchange." ::= { dlswNode 9 } -- ******************************************************************* -- TRANSPORT CONNECTION (aka: PARTNER DLSW) -- ******************************************************************* -- ------------------------------------------------------------------- Chen, et. al. Standards Track [Page 20] RFC 2024 DLSw MIB using SMIv2 October 1996 -- Transport Connection Statistics Objects -- ------------------------------------------------------------------- dlswTConnStat OBJECT IDENTIFIER ::= { dlswTConn 1 } dlswTConnStatActiveConnections OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transport connections that are not in `disconnected' state." ::= { dlswTConnStat 1 } dlswTConnStatCloseIdles OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times transport connections in this node exited the connected state with zero active circuits on the transport connection." ::= { dlswTConnStat 2 } dlswTConnStatCloseBusys OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times transport connections in this node exited the connected state with some non-zero number of active circuits on the transport connection. Normally this means the transport connection failed unexpectedly." ::= { dlswTConnStat 3 } -- ------------------------------------------------------------------- -- Transport Connection Configuration Table -- ------------------------------------------------------------------- dlswTConnConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the transport connections that will be initiated or accepted by this DLSw. Structure of masks allows wildcard definition for a collection of transport connections by a conceptual row. For a specific transport connection, there may Chen, et. al. Standards Track [Page 21] RFC 2024 DLSw MIB using SMIv2 October 1996 be multiple of conceptual rows match the transport address. The `best' match will the one to determine the characteristics of the transport connection." ::= { dlswTConn 2 } dlswTConnConfigEntry OBJECT-TYPE SYNTAX DlswTConnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each conceptual row defines a collection of transport connections." INDEX { dlswTConnConfigIndex } ::= { dlswTConnConfigTable 1 } DlswTConnConfigEntry ::= SEQUENCE { dlswTConnConfigIndex INTEGER, dlswTConnConfigTDomain OBJECT IDENTIFIER, dlswTConnConfigLocalTAddr TAddress, dlswTConnConfigRemoteTAddr TAddress, dlswTConnConfigLastModifyTime TimeTicks, dlswTConnConfigEntryType INTEGER, dlswTConnConfigGroupDefinition RowPointer, dlswTConnConfigSetupType INTEGER, dlswTConnConfigSapList OCTET STRING, dlswTConnConfigAdvertiseMacNB TruthValue, dlswTConnConfigInitCirRecvWndw INTEGER, dlswTConnConfigOpens Counter32, dlswTConnConfigRowStatus RowStatus } dlswTConnConfigIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index to the conceptual row of the table. Negative numbers are not allowed. There are objects defined that point to conceptual rows of this table with this index value. Zero is used to denote that no corresponding row exists. Index values are assigned by the agent, and should not be reused but should continue to increase in value." ::= { dlswTConnConfigEntry 1 } Chen, et. al. Standards Track [Page 22] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswTConnConfigTDomain OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier which indicates the transport domain of this conceptual row." ::= { dlswTConnConfigEntry 2 } dlswTConnConfigLocalTAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The local transport address for this conceptual row of the transport connection definition." ::= { dlswTConnConfigEntry 3 } dlswTConnConfigRemoteTAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The remote transport address. Together with dlswTConnConfigEntryType and dlswTConnConfigGroupDefinition, the object instance of this conceptual row identifies a collection of the transport connections that will be either initiated by this DLSw or initiated by a partner DLSw and accepted by this DLSw." ::= { dlswTConnConfigEntry 4 } dlswTConnConfigLastModifyTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the value of any object in this conceptual row except for dlswTConnConfigOpens was last changed. This value may be compared to dlswTConnOperConnectTime to determine whether values in this row are completely valid for a transport connection created using this row definition." ::= { dlswTConnConfigEntry 5 } dlswTConnConfigEntryType OBJECT-TYPE SYNTAX INTEGER { Chen, et. al. Standards Track [Page 23] RFC 2024 DLSw MIB using SMIv2 October 1996 individual (1), global (2), group (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The object instance signifies the type of entry in the associated conceptual row. The value of `individual' means that the entry applies to a specific partner DLSw node as identified by dlswTConnConfigRemoteTAddr and dlswTConnConfigTDomain. The value of `global' means that the entry applies to all partner DLSw nodes of the TDomain. The value of 'group' means that the entry applies to a specific set of DLSw nodes in the TDomain. Any group definitions are enterprise-specific and are pointed to by dlswTConnConfigGroupDefinition. In the cases of `global' and `group', the value in dlswTConnConfigRemoteTAddr may not have any significance." ::= { dlswTConnConfigEntry 6 } dlswTConnConfigGroupDefinition OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "For conceptual rows of `individual' and `global' as specified in dlswTConnConfigEntryType, the instance of this object is `0.0'. For conceptual rows of `group', the instance points to the specific group definition." ::= { dlswTConnConfigEntry 7 } dlswTConnConfigSetupType OBJECT-TYPE SYNTAX INTEGER { other (1), activePersistent (2), activeOnDemand (3), passive (4), excluded (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This value of the instance of a conceptual row identifies the behavior of the collection of transport connections that this conceptual row Chen, et. al. Standards Track [Page 24] RFC 2024 DLSw MIB using SMIv2 October 1996 defines. The value of activePersistent, activeOnDemand and passive means this DLSw will accept any transport connections, initiated by partner DLSw nodes, which are defined by this conceptual row. The value of activePersistent means this DLSw will also initiate the transport connections of this conceptual row and retry periodically if necessary. The value of activeOnDemand means this DLSw will initiate a transport connection of this conceptual row, if there is a directory cache hits. The value of other is implementation specific. The value of exclude means that the specified node is not allowed to be a partner to this DLSw node. To take a certain conceptual row definition out of service, a value of notInService for dlswTConnConfigRowStatus should be used." DEFVAL { passive } ::= { dlswTConnConfigEntry 8 } dlswTConnConfigSapList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The SAP list indicates which SAPs are advertised to the transport connection defined by this conceptual row. Only SAPs with even numbers are represented, in the form of the most significant bit of the first octet representing the SAP 0, the next most significant bit representing the SAP 2, to the least significant bit of the last octet representing the SAP 254. Data link switching is allowed for those SAPs which have one in its corresponding bit, not allowed otherwise. The whole SAP list has to be changed together. Changing the SAP list affects only new circuit establishments and has no effect on established circuits. This list can be used to restrict specific partners from knowing about all the SAPs used by DLSw on all its interfaces (these are represented in dlswIfSapList for each interface). For instance, one may want to run NetBIOS with some partners but not others. If a node supports sending run-time capabilities exchange messages, changes to this object should cause that action. When to start the run-time capabilities exchange is implementation-specific. Chen, et. al. Standards Track [Page 25] RFC 2024 DLSw MIB using SMIv2 October 1996 The DEFVAL below indicates support for SAPs 0, 4, 8, and C." DEFVAL { 'AA000000000000000000000000000000'H } ::= { dlswTConnConfigEntry 9 } dlswTConnConfigAdvertiseMacNB OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The value of true indicates that any defined local MAC addresses and NetBIOS names will be advertised to a partner node via initial and (if supported) run-time capabilities exchange messages. The DLSw node should send the appropriate exclusivity control vector to accompany each list it sends, or to represent that the node is explicitly configured to have a null list. The value of false indicates that the DLSw node should not send a MAC address list or NetBIOS name list, and should also not send their corresponding exclusivity control vectors." DEFVAL { true } ::= { dlswTConnConfigEntry 10 } dlswTConnConfigInitCirRecvWndw OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "SSP messages" MAX-ACCESS read-create STATUS current DESCRIPTION "The initial circuit receive pacing window size, in the unit of SSP messages, to be used for future transport connections activated using this table row. The managed node sends this value as its initial receive pacing window in its initial capabilities exchange message. Changing this value does not affect the initial circuit receive pacing window size of currently active transport connections. If the standard window pacing scheme is not supported, the value is zero. A larger receive window value may be appropriate for partners that are reachable only via physical paths that have longer network delays." DEFVAL { 1 } ::= { dlswTConnConfigEntry 11 } dlswTConnConfigOpens OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Chen, et. al. Standards Track [Page 26] RFC 2024 DLSw MIB using SMIv2 October 1996 STATUS current DESCRIPTION "Number of times transport connections entered connected state according to the definition of this conceptual row." ::= { dlswTConnConfigEntry 12 } dlswTConnConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by the manager to create or delete the row entry in the dlswTConnConfigTable following the RowStatus textual convention. The value of notInService will be used to take a conceptual row definition out of use." ::= { dlswTConnConfigEntry 13 } -- ------------------------------------------------------------------- -- Transport Connection Operation Table -- ------------------------------------------------------------------- -- (1) At most one transport connection can be connected between -- this DLSw and one of its DLSw partners at a given time. -- (2) Multiple transport types are supported. -- (3) Since the entries may be reused, dlswTConnOperEntryTime -- needs to be consulted for the possibility of counter reset. -- ------------------------------------------------------------------- dlswTConnOperTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of transport connections. It is optional but desirable for the agent to keep an entry for some period of time after the transport connection is disconnected. This allows the manager to capture additional useful information about the connection, in particular, statistical information and the cause of the disconnection." ::= { dlswTConn 3 } dlswTConnOperEntry OBJECT-TYPE SYNTAX DlswTConnOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 27] RFC 2024 DLSw MIB using SMIv2 October 1996 "" INDEX { dlswTConnOperTDomain, dlswTConnOperRemoteTAddr } ::= { dlswTConnOperTable 1 } DlswTConnOperEntry ::= SEQUENCE { dlswTConnOperTDomain OBJECT IDENTIFIER, dlswTConnOperLocalTAddr TAddress, dlswTConnOperRemoteTAddr TAddress, dlswTConnOperEntryTime TimeTicks, dlswTConnOperConnectTime TimeTicks, dlswTConnOperState INTEGER, dlswTConnOperConfigIndex INTEGER, dlswTConnOperFlowCntlMode INTEGER, dlswTConnOperPartnerVersion OCTET STRING, dlswTConnOperPartnerVendorID OCTET STRING, dlswTConnOperPartnerVersionStr DisplayString, dlswTConnOperPartnerInitPacingWndw INTEGER, dlswTConnOperPartnerSapList OCTET STRING, dlswTConnOperPartnerNBExcl TruthValue, dlswTConnOperPartnerMacExcl TruthValue, dlswTConnOperPartnerNBInfo INTEGER, dlswTConnOperPartnerMacInfo INTEGER, dlswTConnOperDiscTime TimeTicks, dlswTConnOperDiscReason INTEGER, dlswTConnOperDiscActiveCir INTEGER, dlswTConnOperInDataPkts Counter32, dlswTConnOperOutDataPkts Counter32, dlswTConnOperInDataOctets Counter32, dlswTConnOperOutDataOctets Counter32, dlswTConnOperInCntlPkts Counter32, dlswTConnOperOutCntlPkts Counter32, dlswTConnOperCURexSents Counter32, dlswTConnOperICRexRcvds Counter32, dlswTConnOperCURexRcvds Counter32, dlswTConnOperICRexSents Counter32, dlswTConnOperNQexSents Counter32, dlswTConnOperNRexRcvds Counter32, dlswTConnOperNQexRcvds Counter32, dlswTConnOperNRexSents Counter32, Chen, et. al. Standards Track [Page 28] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswTConnOperCirCreates Counter32, dlswTConnOperCircuits Gauge32 } dlswTConnOperTDomain OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The object identifier indicates the transport domain of this transport connection." ::= { dlswTConnOperEntry 1 } dlswTConnOperLocalTAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The local transport address for this transport connection. This value could be different from dlswTConnConfigLocalAddr, if the value of the latter were changed after this transport connection was established." ::= { dlswTConnOperEntry 2 } dlswTConnOperRemoteTAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote transport address of this transport connection." ::= { dlswTConnOperEntry 3 } dlswTConnOperEntryTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time (in hundredths of a second) since this transport connection conceptual row was created." ::= { dlswTConnOperEntry 4 } -- ................................................................... -- DLSw Transport Connection Operational Objects -- ................................................................... dlswTConnOperConnectTime OBJECT-TYPE SYNTAX TimeTicks Chen, et. al. Standards Track [Page 29] RFC 2024 DLSw MIB using SMIv2 October 1996 UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time (in hundredths of a second) since this transport connection last entered the 'connected' state. A value of zero means this transport connection has never been established." ::= { dlswTConnOperEntry 5 } dlswTConnOperState OBJECT-TYPE SYNTAX INTEGER { connecting (1), initCapExchange (2), connected (3), quiescing (4), disconnecting (5), disconnected (6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The state of this transport connection. The transport connection enters `connecting' state when DLSw makes a connection request to the transport layer. Once initial Capabilities Exchange is sent, the transport connection enters enters `initCapExchange' state. When partner capabilities have been determined and the transport connection is ready for sending CanUReach (CUR) messages, it moves to the `connected' state. When DLSw is in the process of bringing down the connection, it is in the `disconnecting' state. When the transport layer indicates one of its connections is disconnected, the transport connection moves to the `disconnected' state. Whereas all of the values will be returned in response to a management protocol retrieval operation, only two values may be specified in a management protocol set operation: `quiescing' and `disconnecting'. Changing the value to `quiescing' prevents new circuits from being established, and will cause a transport disconnect when the last circuit on the connection goes away. Changing the value to `disconnecting' will force off all circuits immediately and bring the connection to `disconnected' state." ::= { dlswTConnOperEntry 6 } dlswTConnOperConfigIndex OBJECT-TYPE Chen, et. al. Standards Track [Page 30] RFC 2024 DLSw MIB using SMIv2 October 1996 SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of dlswTConnConfigIndex of the dlswTConnConfigEntry that governs the configuration information used by this dlswTConnOperEntry. The manager can therefore normally examine both configured and operational information for this transport connection. This value is zero if the corresponding dlswTConnConfigEntry was deleted after the creation of this dlswTConnOperEntry. If some fields in the former were changed but the conceptual row was not deleted, some configuration information may not be valid for this operational transport connection. The manager can compare dlswTConnOperConnectTime and dlswTConnConfigLastModifyTime to determine if this condition exists." ::= { dlswTConnOperEntry 7 } -- ................................................................... -- Transport Connection Characteristics -- ................................................................... dlswTConnOperFlowCntlMode OBJECT-TYPE SYNTAX INTEGER { undetermined (1), pacing (2), -- DLSw standard flow control other (3) -- non-DLSw standard flow control } MAX-ACCESS read-only STATUS current DESCRIPTION "The flow control mechanism in use on this transport connection. This value is undetermined (1) before the mode of flow control can be established on a new transport connection (i.e., after CapEx is sent but before Capex or other SSP control messages have been received). Pacing (2) indicates that the standard RFC 1795 pacing mechanism is in use. Other (3) may be either the RFC 1434+ xBusy mechanism operating to a back-level DLSw, or a vendor-specific flow control method. Whether it is xBusy or not can be inferred from dlswTConnOperPartnerVersion." ::= { dlswTConnOperEntry 8 } -- ................................................................... dlswTConnOperPartnerVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 2)) Chen, et. al. Standards Track [Page 31] RFC 2024 DLSw MIB using SMIv2 October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies which version (first octet) and release (second octet) of the DLSw standard is supported by this partner DLSw. This information is obtained from a DLSw capabilities exchange message received from the partner DLSw. A string of zero length is returned before a Capabilities Exchange message is received, or if one is never received. A conceptual row with a dlswTConnOperState of `connected' but a zero length partner version indicates that the partner is a non-standard DLSw partner. If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." REFERENCE "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswTConnOperEntry 9 } dlswTConnOperPartnerVendorID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the IEEE-assigned organizationally Unique Identifier (OUI) of the maker of this partner DLSw. This information is obtained from a DLSw capabilities exchange message received from the partner DLSw. A string of zero length is returned before a Capabilities Exchange message is received, or if one is never received. If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." ::= { dlswTConnOperEntry 10 } dlswTConnOperPartnerVersionStr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..253)) MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the particular product version (e.g., product name, code level, fix level) of this partner DLSw. The format of the actual version string is vendor-specific. This information is obtained from a DLSw capabilities exchange message received from the partner DLSw. A string of zero length is returned before a Capabilities Exchange message is received, if one is never received, or if one is received but it does not contain a version string. Chen, et. al. Standards Track [Page 32] RFC 2024 DLSw MIB using SMIv2 October 1996 If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." REFERENCE "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswTConnOperEntry 11 } dlswTConnOperPartnerInitPacingWndw OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the partner initial receive pacing window. This is our initial send pacing window for all new circuits on this transport connection, as modified and granted by the first flow control indication the partner sends on each circuit. This information is obtained from a DLSw capabilities exchange message received from the partner DLSw. A value of zero is returned before a Capabilities Exchange message is received, or if one is never received. If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." REFERENCE "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswTConnOperEntry 12 } -- ................................................................... dlswTConnOperPartnerSapList OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Supported SAP List received in the capabilities exchange message from the partner DLSw. This list has the same format described for dlswTConnConfigSapList. A string of zero length is returned before a Capabilities Exchange message is received, or if one is never received. If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." ::= { dlswTConnOperEntry 13 } dlswTConnOperPartnerNBExcl OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 33] RFC 2024 DLSw MIB using SMIv2 October 1996 "The value of true signifies that the NetBIOS names received from this partner in the NetBIOS name list in its capabilities exchange message are the only NetBIOS names reachable by that partner. `False' indicates that other NetBIOS names may be reachable. `False' should be returned before a Capabilities Exchange message is received, if one is never received, or if one is received without a NB Name Exclusivity CV. If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." ::= { dlswTConnOperEntry 14 } dlswTConnOperPartnerMacExcl OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of true signifies that the MAC addresses received from this partner in the MAC address list in its capabilities exchange message are the only MAC addresses reachable by that partner. `False' indicates that other MAC addresses may be reachable. `False' should be returned before a Capabilities Exchange message is received, if one is never received, or if one is received without a MAC Address Exclusivity CV. If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." ::= { dlswTConnOperEntry 15 } dlswTConnOperPartnerNBInfo OBJECT-TYPE SYNTAX INTEGER { none (1), -- none is kept partial (2), -- partial list is kept complete (3), -- complete list is kept notApplicable (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "It is up to this DSLw whether to keep either none, some, or all of the NetBIOS name list that was received in the capabilities exchange message sent by this partner DLSw. This object identifies how much information was kept by this DLSw. These names are stored as userConfigured remote entries in dlswDirNBTable. A value of (4), notApplicable, should be returned before a Capabilities Exchange message is received, or if one is never received. Chen, et. al. Standards Track [Page 34] RFC 2024 DLSw MIB using SMIv2 October 1996 If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." ::= { dlswTConnOperEntry 16 } dlswTConnOperPartnerMacInfo OBJECT-TYPE SYNTAX INTEGER { none (1), -- none is kept partial (2), -- partial list is kept complete (3), -- complete list is kept notApplicable (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "It is up to this DLSw whether to keep either none, some, or all of the MAC address list that was received in the capabilities exchange message sent by this partner DLSw. This object identifies how much information was kept by this DLSw. These names are stored as userConfigured remote entries in dlswDirMACTable. A value of (4), notApplicable, should be returned before a Capabilities Exchange message is received, or if one is never received. If an implementation chooses to keep dlswTConnOperEntrys in the `disconnected' state, this value should remain unchanged." ::= { dlswTConnOperEntry 17 } -- ................................................................... -- Information about the last disconnect of this transport connection. -- These objects make sense only for implementations that keep -- transport connection information around after disconnection. -- ................................................................... dlswTConnOperDiscTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time (in hundredths of a second) since the dlswTConnOperState last entered `disconnected' state." ::= { dlswTConnOperEntry 18 } dlswTConnOperDiscReason OBJECT-TYPE SYNTAX INTEGER { other (1), capExFailed (2), transportLayerDisc (3), Chen, et. al. Standards Track [Page 35] RFC 2024 DLSw MIB using SMIv2 October 1996 operatorCommand (4), lastCircuitDiscd (5), protocolError (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object signifies the reason that either prevented the transport connection from entering the connected state, or caused the transport connection to enter the disconnected state." ::= { dlswTConnOperEntry 19 } dlswTConnOperDiscActiveCir OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of circuits active (not in DISCONNECTED state) at the time the transport connection was last disconnected. This value is zero if the transport connection has never been connected." ::= { dlswTConnOperEntry 20 } -- ................................................................... -- Transport Connection Statistics -- (1) Traffic counts -- ................................................................... dlswTConnOperInDataPkts OBJECT-TYPE SYNTAX Counter32 UNITS "SSP messages" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Switch-to-Switch Protocol (SSP) messages of type DGRMFRAME, DATAFRAME, or INFOFRAME received on this transport connection." ::= { dlswTConnOperEntry 21 } dlswTConnOperOutDataPkts OBJECT-TYPE SYNTAX Counter32 UNITS "SSP messages" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Switch-to-Switch Protocol (SSP) messages of type DGRMFRAME, DATAFRAME, or INFOFRAME transmitted on this transport connection." Chen, et. al. Standards Track [Page 36] RFC 2024 DLSw MIB using SMIv2 October 1996 ::= { dlswTConnOperEntry 22 } dlswTConnOperInDataOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number octets in Switch-to-Switch Protocol (SSP) messages of type DGRMFRAME, DATAFRAME, or INFOFRAME received on this transport connection. Each message is counted starting with the first octet following the SSP message header." ::= { dlswTConnOperEntry 23 } dlswTConnOperOutDataOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number octets in Switch-to-Switch Protocol (SSP) messages of type DGRMFRAME, DATAFRAME, or INFOFRAME transmitted on this transport connection. Each message is counted starting with the first octet following the SSP message header." ::= { dlswTConnOperEntry 24 } dlswTConnOperInCntlPkts OBJECT-TYPE SYNTAX Counter32 UNITS "SSP messages" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Switch-to-Switch Protocol (SSP) messages received on this transport connection which were not of type DGRMFRAME, DATAFRAME, or INFOFRAME." ::= { dlswTConnOperEntry 25 } dlswTConnOperOutCntlPkts OBJECT-TYPE SYNTAX Counter32 UNITS "SSP messages" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Switch-to-Switch Protocol (SSP) messages of transmitted on this transport connection which were not of type DGRMFRAME, DATAFRAME, or INFOFRAME." ::= { dlswTConnOperEntry 26 } Chen, et. al. Standards Track [Page 37] RFC 2024 DLSw MIB using SMIv2 October 1996 -- ................................................................... -- (2) Directory activities (Explorer messages) -- ................................................................... dlswTConnOperCURexSents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CanUReach_ex messages sent on this transport connection." ::= { dlswTConnOperEntry 27 } dlswTConnOperICRexRcvds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICanReach_ex messages received on this transport connection." ::= { dlswTConnOperEntry 28 } dlswTConnOperCURexRcvds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CanUReach_ex messages received on this transport connection." ::= { dlswTConnOperEntry 29 } dlswTConnOperICRexSents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICanReach_ex messages sent on this transport connection." ::= { dlswTConnOperEntry 30 } -- ................................................................... dlswTConnOperNQexSents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NetBIOS_NQ_ex (NetBIOS Name Query-explorer) Chen, et. al. Standards Track [Page 38] RFC 2024 DLSw MIB using SMIv2 October 1996 messages sent on this transport connection." ::= { dlswTConnOperEntry 31 } dlswTConnOperNRexRcvds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NETBIOS_NR_ex (NetBIOS Name Recognized-explorer) messages received on this transport connection." ::= { dlswTConnOperEntry 32 } dlswTConnOperNQexRcvds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NETBIOS_NQ_ex messages received on this transport connection." ::= { dlswTConnOperEntry 33 } dlswTConnOperNRexSents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NETBIOS_NR_ex messages sent on this transport connection." ::= { dlswTConnOperEntry 34 } -- ................................................................... -- (3) Circuit activities on each transport connection -- ................................................................... dlswTConnOperCirCreates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that circuits entered `circuit_established' state (not counting transitions from `circuit_restart')." ::= { dlswTConnOperEntry 35 } dlswTConnOperCircuits OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active circuits on this transport Chen, et. al. Standards Track [Page 39] RFC 2024 DLSw MIB using SMIv2 October 1996 connection, where `active' means not in `disconnected' state." ::= { dlswTConnOperEntry 36 } -- ------------------------------------------------------------------- -- Transport Connection Specific -- ------------------------------------------------------------------- dlswTConnSpecific OBJECT IDENTIFIER ::= { dlswTConn 4 } dlswTConnTcp OBJECT IDENTIFIER ::= { dlswTConnSpecific 1 } -- ................................................................... -- TCP Transport Connection Specific -- Configuration -- ................................................................... dlswTConnTcpConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnTcpConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the TCP transport connections that will be either initiated by or accepted by this DSLw. It augments the entries in dlswTConnConfigTable whose domain is dlswTCPDomain." ::= { dlswTConnTcp 1 } dlswTConnTcpConfigEntry OBJECT-TYPE SYNTAX DlswTConnTcpConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each conceptual row defines parameters that are specific to dlswTCPDomain transport connections." INDEX { dlswTConnConfigIndex } ::= { dlswTConnTcpConfigTable 1 } DlswTConnTcpConfigEntry ::= SEQUENCE { dlswTConnTcpConfigKeepAliveInt INTEGER, dlswTConnTcpConfigTcpConnections INTEGER, dlswTConnTcpConfigMaxSegmentSize INTEGER } dlswTConnTcpConfigKeepAliveInt OBJECT-TYPE SYNTAX INTEGER (0..1800) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time in seconds between TCP keepAlive messages when no traffic is flowing. Zero signifies no keepAlive protocol. Chen, et. al. Standards Track [Page 40] RFC 2024 DLSw MIB using SMIv2 October 1996 Changes take effect only for new TCP connections." DEFVAL { 0 } ::= { dlswTConnTcpConfigEntry 1 } dlswTConnTcpConfigTcpConnections OBJECT-TYPE SYNTAX INTEGER (1..16) MAX-ACCESS read-create STATUS current DESCRIPTION "This is our preferred number of TCP connections within a TCP transport connection. The actual number used is negotiated at capabilities exchange time. Changes take effect only for new transport connections." DEFVAL { 2 } ::= { dlswTConnTcpConfigEntry 2 } dlswTConnTcpConfigMaxSegmentSize OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "This is the number of bytes that this node is willing to receive over the read TCP connection(s). Changes take effect for new transport connections." DEFVAL { 4096 } ::= { dlswTConnTcpConfigEntry 3 } -- ................................................................... -- TCP Transport Connection Specific -- Operation -- ................................................................... dlswTConnTcpOperTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnTcpOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of TCP transport connections. It is optional but desirable for the agent to keep an entry for some period of time after the transport connection is disconnected. This allows the manager to capture additional useful information about the connection, in particular, statistical information and the cause of the disconnection." ::= { dlswTConnTcp 2 } dlswTConnTcpOperEntry OBJECT-TYPE SYNTAX DlswTConnTcpOperEntry Chen, et. al. Standards Track [Page 41] RFC 2024 DLSw MIB using SMIv2 October 1996 MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { dlswTConnOperTDomain, dlswTConnOperRemoteTAddr } ::= { dlswTConnTcpOperTable 1 } DlswTConnTcpOperEntry ::= SEQUENCE { dlswTConnTcpOperKeepAliveInt INTEGER, dlswTConnTcpOperPrefTcpConnections INTEGER, dlswTConnTcpOperTcpConnections INTEGER } dlswTConnTcpOperKeepAliveInt OBJECT-TYPE SYNTAX INTEGER (0..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time in seconds between TCP keepAlive messages when no traffic is flowing. Zero signifies no keepAlive protocol is operating." ::= { dlswTConnTcpOperEntry 1 } dlswTConnTcpOperPrefTcpConnections OBJECT-TYPE SYNTAX INTEGER (1..16) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the number of TCP connections preferred by this DLSw partner, as received in its capabilities exchange message." ::= { dlswTConnTcpOperEntry 2 } dlswTConnTcpOperTcpConnections OBJECT-TYPE SYNTAX INTEGER (1..16) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the actual current number of TCP connections within this transport connection." ::= { dlswTConnTcpOperEntry 3 } -- ******************************************************************* -- DLSW INTERFACE GROUP -- ******************************************************************* dlswIfTable OBJECT-TYPE Chen, et. al. Standards Track [Page 42] RFC 2024 DLSw MIB using SMIv2 October 1996 SYNTAX SEQUENCE OF DlswIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The list of interfaces on which DLSw is active." ::= { dlswInterface 1 } dlswIfEntry OBJECT-TYPE SYNTAX DlswIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { ifIndex } ::= { dlswIfTable 1 } DlswIfEntry ::= SEQUENCE { dlswIfRowStatus RowStatus, dlswIfVirtualSegment INTEGER, dlswIfSapList OCTET STRING } dlswIfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by the manager to create or delete the row entry in the dlswIfTable following the RowStatus textual convention." ::= { dlswIfEntry 1 } dlswIfVirtualSegment OBJECT-TYPE SYNTAX INTEGER (0..4095 | 65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The segment number that uniquely identifies the virtual segment to which this DLSw interface is connected. Current source routing protocols limit this value to the range 0 - 4095. (The value 0 is used by some management applications for special test cases.) A value of 65535 signifies that no virtual segment is assigned to this interface. For instance, in a non-source routing environment, segment number assignment is not required." DEFVAL { 65535 } ::= { dlswIfEntry 2 } Chen, et. al. Standards Track [Page 43] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswIfSapList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The SAP list indicates which SAPs are allowed to be data link switched through this interface. This list has the same format described for dlswTConnConfigSapList. When changes to this object take effect is implementation- specific. Turning off a particular SAP can destroy active circuits that are using that SAP. An agent implementation may reject such changes until there are no active circuits if it so chooses. In this case, it is up to the manager to close the circuits first, using dlswCircuitState. The DEFVAL below indicates support for SAPs 0, 4, 8, and C." DEFVAL { 'AA000000000000000000000000000000'H } ::= { dlswIfEntry 3 } -- ******************************************************************* -- DIRECTORY -- Directory services caches the locations of MAC addresses -- and NetBIOS names. For resources which are attached via -- local interfaces, the ifIndex may be cached, and for -- resources which are reachable via a DLSw partner, the -- transport address of the DLSw partner is cached. -- ******************************************************************* -- ------------------------------------------------------------------- -- Directory Related Statistical Objects -- ------------------------------------------------------------------- dlswDirStat OBJECT IDENTIFIER ::= { dlswDirectory 1 } dlswDirMacEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of entries in the dlswDirMacTable." ::= { dlswDirStat 1 } dlswDirMacCacheHits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Chen, et. al. Standards Track [Page 44] RFC 2024 DLSw MIB using SMIv2 October 1996 DESCRIPTION "The number of times a cache search for a particular MAC address resulted in success." ::= { dlswDirStat 2 } dlswDirMacCacheMisses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a cache search for a particular MAC address resulted in failure." ::= { dlswDirStat 3 } dlswDirMacCacheNextIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The next value of dlswDirMacIndex to be assigned by the agent. A retrieval of this object atomically reserves the returned value for use by the manager to create a row in dlswDirMacTable. This makes it possible for the agent to control the index space of the MAC address cache, yet allows the manager to administratively create new rows." ::= { dlswDirStat 4 } dlswDirNBEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of entries in the dlswDirNBTable." ::= { dlswDirStat 5 } dlswDirNBCacheHits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a cache search for a particular NetBIOS name resulted in success." ::= { dlswDirStat 6 } dlswDirNBCacheMisses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Chen, et. al. Standards Track [Page 45] RFC 2024 DLSw MIB using SMIv2 October 1996 DESCRIPTION "The number of times a cache search for a particular NetBIOS name resulted in failure." ::= { dlswDirStat 7 } dlswDirNBCacheNextIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The next value of dlswDirNBIndex to be assigned by the agent. A retrieval of this object atomically reserves the returned value for use by the manager to create a row in dlswDirNBTable. This makes it possible for the agent to control the index space for the NetBIOS name cache, yet allows the manager to administratively create new rows." ::= { dlswDirStat 8 } -- ------------------------------------------------------------------- -- Directory Cache -- ------------------------------------------------------------------- dlswDirCache OBJECT IDENTIFIER ::= { dlswDirectory 2 } -- ................................................................... -- Directory for MAC Addresses. -- All Possible combinations of values of these objects. -- -- EntryType LocationType Location Status -- -------------- ------------ ------------------ -------------- -- userConfigured local ifEntry or 0.0 reachable, or -- notReachable, or -- unknown -- userConfigured remote TConnConfigEntry reachable, or -- notReachable, or -- unknown -- partnerCapExMsg remote TConnOperEntry unknown -- dynamic local ifEntry or 0.0 reachable -- dynamic remote TConnOperEntry reachable -- -- ................................................................... dlswDirMacTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswDirMacEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains locations of MAC addresses. They could be either verified or not verified, Chen, et. al. Standards Track [Page 46] RFC 2024 DLSw MIB using SMIv2 October 1996 local or remote, and configured locally or learned from either Capabilities Exchange messages or directory searches." ::= { dlswDirCache 1 } dlswDirMacEntry OBJECT-TYPE SYNTAX DlswDirMacEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indexed by dlswDirMacIndex." INDEX { dlswDirMacIndex } ::= { dlswDirMacTable 1 } DlswDirMacEntry ::= SEQUENCE { dlswDirMacIndex INTEGER, dlswDirMacMac MacAddressNC, dlswDirMacMask MacAddressNC, dlswDirMacEntryType INTEGER, dlswDirMacLocationType INTEGER, dlswDirMacLocation RowPointer, dlswDirMacStatus INTEGER, dlswDirMacLFSize LFSize, dlswDirMacRowStatus RowStatus } dlswDirMacIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies a conceptual row of this table." ::= { dlswDirMacEntry 1 } dlswDirMacMac OBJECT-TYPE SYNTAX MacAddressNC MAX-ACCESS read-create STATUS current DESCRIPTION "The MAC address, together with the dlswDirMacMask, specifies a set of MAC addresses that are defined or discovered through an interface or partner DLSw nodes." ::= { dlswDirMacEntry 2 } dlswDirMacMask OBJECT-TYPE SYNTAX MacAddressNC MAX-ACCESS read-create STATUS current Chen, et. al. Standards Track [Page 47] RFC 2024 DLSw MIB using SMIv2 October 1996 DESCRIPTION "The MAC address mask, together with the dlswDirMacMac, specifies a set of MAC addresses that are defined or discovered through an interface or partner DLSw nodes." DEFVAL { 'FFFFFFFFFFFF'H } ::= { dlswDirMacEntry 3 } dlswDirMacEntryType OBJECT-TYPE SYNTAX INTEGER { other (1), userConfiguredPublic (2), userConfiguredPrivate (3), partnerCapExMsg (4), dynamic (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The cause of the creation of this conceptual row. It could be one of the three methods: (1) user configured, including via management protocol set operations, configuration file, command line or equivalent methods; (2) learned from the partner DLSw Capabilities Exchange messages; and (3) dynamic, e.g., learned from ICanReach messages, or LAN explorer frames. Since only individual MAC addresses can be dynamically learned, dynamic entries will all have a mask of all FFs. The public versus private distinction for user- configured resources applies only to local resources (UC remote resources are private), and indicates whether that resource should be advertised in capabilities exchange messages sent by this node." DEFVAL { userConfiguredPublic } ::= { dlswDirMacEntry 4 } dlswDirMacLocationType OBJECT-TYPE SYNTAX INTEGER { other (1), local (2), remote (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The location of the resource (or a collection of resources using a mask) of this conceptual row Chen, et. al. Standards Track [Page 48] RFC 2024 DLSw MIB using SMIv2 October 1996 is either (1) local - the resource is reachable via an interface, or (2) remote - the resource is reachable via a partner DLSw node (or a set of partner DLSw nodes)." DEFVAL { local } ::= { dlswDirMacEntry 5 } dlswDirMacLocation OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Points to either the ifEntry, dlswTConnConfigEntry, dlswTConnOperEntry, 0.0, or something that is implementation specific. It identifies the location of the MAC address (or the collection of MAC addresses.)" DEFVAL { null } ::= { dlswDirMacEntry 6 } dlswDirMacStatus OBJECT-TYPE SYNTAX INTEGER { unknown (1), reachable (2), notReachable (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies whether DLSw currently believes the MAC address to be accessible at the specified location. The value `notReachable' allows a configured resource definition to be taken out of service when a search to that resource fails (avoiding a repeat of the search)." DEFVAL { unknown } ::= { dlswDirMacEntry 7 } dlswDirMacLFSize OBJECT-TYPE SYNTAX LFSize MAX-ACCESS read-create STATUS current DESCRIPTION "The largest size of the MAC INFO field (LLC header and data) that a circuit to the MAC address can carry through this path." DEFVAL { lfs65535 } ::= { dlswDirMacEntry 8 } dlswDirMacRowStatus OBJECT-TYPE SYNTAX RowStatus Chen, et. al. Standards Track [Page 49] RFC 2024 DLSw MIB using SMIv2 October 1996 MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by the manager to create or delete the row entry in the dlswDirMacTable following the RowStatus textual convention." ::= { dlswDirMacEntry 9 } -- ................................................................... -- Directory for NetBIOS Names -- All Possible combinations of values of these objects. -- -- EntryType LocationType Location Status -- -------------- ------------ ------------------ -------------- -- userConfigured local ifEntry or 0.0 reachable, or -- notReachable, or -- unknown -- userConfigured remote TConnConfigEntry reachable, or -- notReachable, or -- unknown -- partnerCapExMsg remote TConnOperEntry unknown -- dynamic local ifEntry or 0.0 reachable -- dynamic remote TConnOperEntry reachable -- -- ................................................................... dlswDirNBTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswDirNBEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains locations of NetBIOS names. They could be either verified or not verified, local or remote, and configured locally or learned from either Capabilities Exchange messages or directory searches." ::= { dlswDirCache 2 } dlswDirNBEntry OBJECT-TYPE SYNTAX DlswDirNBEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indexed by dlswDirNBIndex." INDEX { dlswDirNBIndex } ::= { dlswDirNBTable 1 } DlswDirNBEntry ::= SEQUENCE { dlswDirNBIndex INTEGER, Chen, et. al. Standards Track [Page 50] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswDirNBName NBName, dlswDirNBNameType INTEGER, dlswDirNBEntryType INTEGER, dlswDirNBLocationType INTEGER, dlswDirNBLocation RowPointer, dlswDirNBStatus INTEGER, dlswDirNBLFSize LFSize, dlswDirNBRowStatus RowStatus } dlswDirNBIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies a conceptual row of this table." ::= { dlswDirNBEntry 1 } dlswDirNBName OBJECT-TYPE SYNTAX NBName MAX-ACCESS read-create STATUS current DESCRIPTION "The NetBIOS name (including `any char' and `wildcard' characters) specifies a set of NetBIOS names that are defined or discovered through an interface or partner DLSw nodes." ::= { dlswDirNBEntry 2 } dlswDirNBNameType OBJECT-TYPE SYNTAX INTEGER { unknown (1), individual (2), group (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Whether dlswDirNBName represents an (or a set of) individual or group NetBIOS name(s)." DEFVAL { unknown } ::= { dlswDirNBEntry 3 } dlswDirNBEntryType OBJECT-TYPE SYNTAX INTEGER { other (1), userConfiguredPublic (2), userConfiguredPrivate (3), Chen, et. al. Standards Track [Page 51] RFC 2024 DLSw MIB using SMIv2 October 1996 partnerCapExMsg (4), dynamic (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The cause of the creation of this conceptual row. It could be one of the three methods: (1) user configured, including via management protocol set operations, configuration file, command line, or equivalent methods; (2) learned from the partner DLSw Capabilities Exchange messages; and (3) dynamic, e.g., learned from ICanReach messages, or test frames. Since only actual NetBIOS names can be dynamically learned, dynamic entries will not contain any char or wildcard characters. The public versus private distinction for user- configured resources applies only to local resources (UC remote resources are private), and indicates whether that resource should be advertised in capabilities exchange messages sent by this node." DEFVAL { userConfiguredPublic } ::= { dlswDirNBEntry 4 } dlswDirNBLocationType OBJECT-TYPE SYNTAX INTEGER { other (1), local (2), remote (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The location of the resource (or a collection of resources using any char/wildcard characters) of this conceptual row is either (1) local - the resource is reachable via an interface, or (2) remote - the resource is reachable via a a partner DLSw node (or a set of partner DLSw nodes)." DEFVAL { local } ::= { dlswDirNBEntry 5 } dlswDirNBLocation OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 52] RFC 2024 DLSw MIB using SMIv2 October 1996 "Points to either the ifEntry, dlswTConnConfigEntry, dlswTConnOperEntry, 0.0, or something that is implementation specific. It identifies the location of the NetBIOS name or the set of NetBIOS names." DEFVAL { null } ::= { dlswDirNBEntry 6 } dlswDirNBStatus OBJECT-TYPE SYNTAX INTEGER { unknown (1), reachable (2), notReachable (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies whether DLSw currently believes the NetBIOS name to be accessible at the specified location. The value `notReachable' allows a configured resource definition to be taken out of service when a search to that resource fails (avoiding a repeat of the search)." DEFVAL { unknown } ::= { dlswDirNBEntry 7 } dlswDirNBLFSize OBJECT-TYPE SYNTAX LFSize MAX-ACCESS read-create STATUS current DESCRIPTION "The largest size of the MAC INFO field (LLC header and data) that a circuit to the NB name can carry through this path." DEFVAL { lfs65535 } ::= { dlswDirNBEntry 8 } dlswDirNBRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by manager to create or delete the row entry in the dlswDirNBTable following the RowStatus textual convention." ::= { dlswDirNBEntry 9 } -- ------------------------------------------------------------------- -- Resource Locations -- ------------------------------------------------------------------- Chen, et. al. Standards Track [Page 53] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswDirLocate OBJECT IDENTIFIER ::= { dlswDirectory 3 } -- ................................................................... -- Locate Entries in the dlswDirMacTable for a given MAC address -- ................................................................... dlswDirLocateMacTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswDirLocateMacEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to retrieve all entries in the dlswDirMacTable that match a given MAC address, in the order of the best matched first, the second best matched second, and so on, till no more entries match the given MAC address." ::= { dlswDirLocate 1 } dlswDirLocateMacEntry OBJECT-TYPE SYNTAX DlswDirLocateMacEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indexed by dlswDirLocateMacMac and dlswDirLocateMacMatch. The first object is the MAC address of interest, and the second object is the order in the list of all entries that match the MAC address." INDEX { dlswDirLocateMacMac, dlswDirLocateMacMatch } ::= { dlswDirLocateMacTable 1 } DlswDirLocateMacEntry ::= SEQUENCE { dlswDirLocateMacMac MacAddressNC, dlswDirLocateMacMatch INTEGER, dlswDirLocateMacLocation RowPointer } dlswDirLocateMacMac OBJECT-TYPE SYNTAX MacAddressNC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MAC address to be located." ::= { dlswDirLocateMacEntry 1 } dlswDirLocateMacMatch OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 54] RFC 2024 DLSw MIB using SMIv2 October 1996 "The order of the entries of dlswDirMacTable that match dlswDirLocateMacMac. A value of one represents the entry that best matches the MAC address. A value of two represents the second best matched entry, and so on." ::= { dlswDirLocateMacEntry 2 } dlswDirLocateMacLocation OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "Points to the dlswDirMacEntry." ::= { dlswDirLocateMacEntry 3 } -- ................................................................... -- Locate Entries in the dlswDirNBTable for a given NetBIOS name -- ................................................................... dlswDirLocateNBTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswDirLocateNBEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to retrieve all entries in the dlswDirNBTable that match a given NetBIOS name, in the order of the best matched first, the second best matched second, and so on, till no more entries match the given NetBIOS name." ::= { dlswDirLocate 2 } dlswDirLocateNBEntry OBJECT-TYPE SYNTAX DlswDirLocateNBEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indexed by dlswDirLocateNBName and dlswDirLocateNBMatch. The first object is the NetBIOS name of interest, and the second object is the order in the list of all entries that match the NetBIOS name." INDEX { dlswDirLocateNBName, dlswDirLocateNBMatch } ::= { dlswDirLocateNBTable 1 } DlswDirLocateNBEntry ::= SEQUENCE { dlswDirLocateNBName NBName, dlswDirLocateNBMatch INTEGER, dlswDirLocateNBLocation RowPointer } Chen, et. al. Standards Track [Page 55] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswDirLocateNBName OBJECT-TYPE SYNTAX NBName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The NetBIOS name to be located (no any char or wildcards)." ::= { dlswDirLocateNBEntry 1 } dlswDirLocateNBMatch OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The order of the entries of dlswDirNBTable that match dlswDirLocateNBName. A value of one represents the entry that best matches the NetBIOS name. A value of two represents the second best matched entry, and so on." ::= { dlswDirLocateNBEntry 2 } dlswDirLocateNBLocation OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "Points to the dlswDirNBEntry." ::= { dlswDirLocateNBEntry 3 } -- ******************************************************************* -- CIRCUIT -- A circuit is the end-to-end association of two DLSw entities -- through one or two DLSw nodes. It is the concatenation of -- two "data links", optionally with an intervening transport -- connection. The origin of the circuit is the end station that -- initiates the circuit. The target of the circuit is the end -- station that receives the initiation. -- ******************************************************************* -- ------------------------------------------------------------------- -- Statistics Related to Circuits -- ------------------------------------------------------------------- dlswCircuitStat OBJECT IDENTIFIER ::= { dlswCircuit 1 } dlswCircuitStatActives OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Chen, et. al. Standards Track [Page 56] RFC 2024 DLSw MIB using SMIv2 October 1996 DESCRIPTION "The current number of circuits in dlswCircuitTable that are not in the disconnected state." ::= { dlswCircuitStat 1 } dlswCircuitStatCreates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of entries ever added to dlswCircuitTable, or reactivated upon exiting `disconnected' state." ::= { dlswCircuitStat 2 } -- ------------------------------------------------------------------- -- Circuit Table -- -- This table is the DLSw entity's view of circuits. There will be -- a conceptual row in the table associated with each data link. -- -- The chart below lists the various possible combinations of -- origin and target MAC locations and the number of entries in -- this Circuit Table: -- -- number of | Origin End Station Location -- entries in the |-------------------------------------- -- Circuit Table | internal local remote -- -----------------------|-------------------------------------- -- Target | internal | NA 2 1 -- End | local | 2 2 1 -- Station | remote | 1 1 NA -- Location | | -- -- NA: Not applicable -- -- Note: -- (a) IfIndex and RouteInfo are applied only if location is local. -- (b) TDomain and TAddr are applied only if location is remote. -- -- Most of statistics related to circuits can be collected -- from LLC-2 Link Station Table. -- ------------------------------------------------------------------- dlswCircuitTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswCircuitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 57] RFC 2024 DLSw MIB using SMIv2 October 1996 "This table is the circuit representation in the DLSw entity. Virtual data links are used to represent any internal end stations. There is a conceptual row associated with each data link. Thus, for circuits without an intervening transport connection, there are two conceptual rows for each circuit. The table consists of the circuits being established, established, and as an implementation option, circuits that have been disconnected. For circuits carried over transport connections, an entry is created after the CUR_cs was sent or received. For circuits between two locally attached devices, or internal virtual MAC addresses, an entry is created when the equivalent of CUR_cs sent/received status is reached. End station 1 (S1) and End station 2 (S2) are used to represent the two end stations of the circuit. S1 is always an end station which is locally attached. S2 may be locally attached or remote. If it is locally attached, the circuit will be represented by two rows indexed by (A, B) and (B, A) where A & B are the relevant MACs/SAPs. The table may be used to store the causes of disconnection of circuits. It is recommended that the oldest disconnected circuit entry be removed from this table when the memory space of disconnected circuits is needed." ::= { dlswCircuit 2 } dlswCircuitEntry OBJECT-TYPE SYNTAX DlswCircuitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { dlswCircuitS1Mac, dlswCircuitS1Sap, dlswCircuitS2Mac, dlswCircuitS2Sap } ::= { dlswCircuitTable 1 } DlswCircuitEntry ::= SEQUENCE { dlswCircuitS1Mac MacAddressNC, dlswCircuitS1Sap OCTET STRING, dlswCircuitS1IfIndex INTEGER, dlswCircuitS1DlcType DlcType, dlswCircuitS1RouteInfo OCTET STRING, dlswCircuitS1CircuitId OCTET STRING, Chen, et. al. Standards Track [Page 58] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswCircuitS1Dlc RowPointer, dlswCircuitS2Mac MacAddressNC, dlswCircuitS2Sap OCTET STRING, dlswCircuitS2Location EndStationLocation, dlswCircuitS2TDomain OBJECT IDENTIFIER, dlswCircuitS2TAddress TAddress, dlswCircuitS2CircuitId OCTET STRING, dlswCircuitOrigin INTEGER, dlswCircuitEntryTime TimeTicks, dlswCircuitStateTime TimeTicks, dlswCircuitState INTEGER, dlswCircuitPriority INTEGER, dlswCircuitFCSendGrantedUnits INTEGER, dlswCircuitFCSendCurrentWndw INTEGER, dlswCircuitFCRecvGrantedUnits INTEGER, dlswCircuitFCRecvCurrentWndw INTEGER, dlswCircuitFCLargestRecvGranted Gauge32, dlswCircuitFCLargestSendGranted Gauge32, dlswCircuitFCHalveWndwSents Counter32, dlswCircuitFCResetOpSents Counter32, dlswCircuitFCHalveWndwRcvds Counter32, dlswCircuitFCResetOpRcvds Counter32, dlswCircuitDiscReasonLocal INTEGER, dlswCircuitDiscReasonRemote INTEGER, dlswCircuitDiscReasonRemoteData OCTET STRING } -- ................................................................... -- Information related to the End Station 1 (S1). -- ................................................................... dlswCircuitS1Mac OBJECT-TYPE SYNTAX MacAddressNC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MAC Address of End Station 1 (S1) used for this circuit." ::= { dlswCircuitEntry 1 } dlswCircuitS1Sap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 59] RFC 2024 DLSw MIB using SMIv2 October 1996 "The SAP at End Station 1 (S1) used for this circuit." ::= { dlswCircuitEntry 2 } dlswCircuitS1IfIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The ifEntry index of the local interface through which S1 can be reached." ::= { dlswCircuitEntry 3 } dlswCircuitS1DlcType OBJECT-TYPE SYNTAX DlcType MAX-ACCESS read-only STATUS current DESCRIPTION "The DLC protocol in use between the DLSw node and S1." ::= { dlswCircuitEntry 4 } dlswCircuitS1RouteInfo OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..30)) MAX-ACCESS read-only STATUS current DESCRIPTION "If source-route bridging is in use between the DLSw node and S1, this is the routing information field describing the path between the two devices. Otherwise the value will be an OCTET STRING of zero length." ::= { dlswCircuitEntry 5 } dlswCircuitS1CircuitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Circuit ID assigned by this DLSw node to this circuit. The first four octets are the DLC port Id, and the second four octets are the Data Link Correlator. If the DLSw SSP was not used to establish this circuit, the value will be a string of zero length." ::= { dlswCircuitEntry 6 } dlswCircuitS1Dlc OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current Chen, et. al. Standards Track [Page 60] RFC 2024 DLSw MIB using SMIv2 October 1996 DESCRIPTION "Points to a conceptual row of the underlying DLC MIB, which could either be the standard MIBs (e.g., the SDLC), or an enterprise-specific DLC MIB." ::= { dlswCircuitEntry 7 } -- ................................................................... -- Information related to the End Station 2 (S2). -- ................................................................... dlswCircuitS2Mac OBJECT-TYPE SYNTAX MacAddressNC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MAC Address of End Station 2 (S2) used for this circuit." ::= { dlswCircuitEntry 8 } dlswCircuitS2Sap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SAP at End Station 2 (S2) used for this circuit." ::= { dlswCircuitEntry 9 } dlswCircuitS2Location OBJECT-TYPE SYNTAX EndStationLocation MAX-ACCESS read-only STATUS current DESCRIPTION "The location of End Station 2 (S2). If the location of End Station 2 is local, the interface information will be available in the conceptual row whose S1 and S2 are the S2 and the S1 of this conceptual row, respectively." ::= { dlswCircuitEntry 10 } dlswCircuitS2TDomain OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "If the location of End Station 2 is remote, this value is the transport domain of the transport protocol the circuit is running over. Otherwise, the value is 0.0." ::= { dlswCircuitEntry 11 } Chen, et. al. Standards Track [Page 61] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswCircuitS2TAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "If the location of End Station 2 is remote, this object contains the address of the partner DLSw, else it will be an OCTET STRING of zero length." ::= { dlswCircuitEntry 12 } dlswCircuitS2CircuitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Circuit ID assigned to this circuit by the partner DLSw node. The first four octets are the DLC port Id, and the second four octets are the Data Link Correlator. If the DLSw SSP was not used to establish this circuit, the value will be a string of zero length." ::= { dlswCircuitEntry 13 } -- ................................................................... dlswCircuitOrigin OBJECT-TYPE SYNTAX INTEGER { s1 (1), s2 (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies which of the two end stations initiated the establishment of this circuit." ::= { dlswCircuitEntry 14 } -- ................................................................... -- Operational information related to this circuit. -- ................................................................... dlswCircuitEntryTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time (in hundredths of a second) since this circuit table conceptual row was created." ::= { dlswCircuitEntry 15 } Chen, et. al. Standards Track [Page 62] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswCircuitStateTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time (in hundredths of a second) since this circuit entered the current state." ::= { dlswCircuitEntry 16 } dlswCircuitState OBJECT-TYPE SYNTAX INTEGER { disconnected (1), circuitStart (2), resolvePending (3), circuitPending (4), circuitEstablished (5), connectPending (6), contactPending (7), connected (8), disconnectPending (9), haltPending (10), haltPendingNoack (11), circuitRestart (12), restartPending (13) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of this circuit. The agent, implementation specific, may choose to keep entries for some period of time after circuit disconnect, so the manager can gather the time and cause of disconnection. While all of the specified values may be returned from a GET operation, the only SETable value is `disconnectPending'. When this value is set, DLSw should perform the appropriate action given its previous state (e.g., send HALT_DL if the state was `connected') to bring the circuit down to the `disconnected' state. Both the partner DLSw and local end station(s) should be notified as appropriate. This MIB provides no facility to re-establish a disconnected circuit, because in DLSw this should be an end station-driven function." ::= { dlswCircuitEntry 17 } dlswCircuitPriority OBJECT-TYPE Chen, et. al. Standards Track [Page 63] RFC 2024 DLSw MIB using SMIv2 October 1996 SYNTAX INTEGER { unsupported (1), low (2), medium (3), high (4), highest (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The transmission priority of this circuit as understood by this DLSw node. This value is determined by the two DLSw nodes at circuit startup time. If this DLSw node does not support DLSw circuit priority, the value `unsupported' should be returned." ::= { dlswCircuitEntry 18 } -- ................................................................... -- Pacing Objects: -- These objects are applicable if DLSw is using the SSP circuit -- pacing protocol to control the flow between the two data links -- in this circuit. -- ................................................................... dlswCircuitFCSendGrantedUnits OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of paced SSP messages that this DLSw is currently authorized to send on this circuit before it must stop and wait for an additional flow control indication from the partner DLSw. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 19 } dlswCircuitFCSendCurrentWndw OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The current window size that this DLSw is using in its role as a data sender. This is the value by which this DLSw would increase the number of messages it is authorized to send, if it were to receive a flow control indication with the bits specifying `repeat window'. Chen, et. al. Standards Track [Page 64] RFC 2024 DLSw MIB using SMIv2 October 1996 The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 20 } dlswCircuitFCRecvGrantedUnits OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of paced SSP messages that this DLSw has authorized the partner DLSw to send on this circuit before the partner DLSw must stop and wait for an additional flow control indication from this DLSw. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 21 } dlswCircuitFCRecvCurrentWndw OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The current window size that this DLSw is using in its role as a data receiver. This is the number of additional paced SSP messages that this DLSw would be authorizing its DLSw partner to send, if this DLSw were to send a flow control indication with the bits specifying `repeat window'. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 22 } dlswCircuitFCLargestRecvGranted OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The largest receive window size granted by this DLSw during the current activation of this circuit. This is not the largest number of messages granted at any time, but the largest window size as represented by FCIND operator bits. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 23 } dlswCircuitFCLargestSendGranted OBJECT-TYPE Chen, et. al. Standards Track [Page 65] RFC 2024 DLSw MIB using SMIv2 October 1996 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The largest send (with respect to this DLSw) window size granted by the partner DLSw during the current activation of this circuit. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 24 } dlswCircuitFCHalveWndwSents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Halve Window operations this DLSw has sent on this circuit, in its role as a data receiver. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 25 } dlswCircuitFCResetOpSents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Reset Window operations this DLSw has sent on this circuit, in its role as a data receiver. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 26 } dlswCircuitFCHalveWndwRcvds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Halve Window operations this DLSw has received on this circuit, in its role as a data sender. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 27 } Chen, et. al. Standards Track [Page 66] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswCircuitFCResetOpRcvds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Reset Window operations this DLSw has received on this circuit, in its role as a data sender. The value zero should be returned if this circuit is not running the DLSw pacing protocol." ::= { dlswCircuitEntry 28 } -- ................................................................... -- Information about the circuit disconnection -- ................................................................... dlswCircuitDiscReasonLocal OBJECT-TYPE SYNTAX INTEGER { endStationDiscRcvd (1), endStationDlcError (2), protocolError (3), operatorCommand (4), haltDlRcvd (5), haltDlNoAckRcvd (6), transportConnClosed (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The reason why this circuit was last disconnected, as seen by this DLSw node. This object is present only if the agent keeps circuit table entries around for some period after circuit disconnect." ::= { dlswCircuitEntry 29 } dlswCircuitDiscReasonRemote OBJECT-TYPE SYNTAX INTEGER { unknown (1), endStationDiscRcvd (2), endStationDlcError (3), protocolError (4), operatorCommand (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The generic reason code why this circuit was last disconnected, as reported by the DLSw partner in a HALT_DL Chen, et. al. Standards Track [Page 67] RFC 2024 DLSw MIB using SMIv2 October 1996 or HALT_DL_NOACK. If the partner does not send a reason code in these messages, or the DLSw implementation does not report receiving one, the value `unknown' is returned. This object is present only if the agent keeps circuit table entries around for some period after circuit disconnect." ::= { dlswCircuitEntry 30 } dlswCircuitDiscReasonRemoteData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 4)) MAX-ACCESS read-only STATUS current DESCRIPTION "Implementation-specific data reported by the DLSw partner in a HALT_DL or HALT_DL_NOACK, to help specify how and why this circuit was last disconnected. If the partner does not send this data in these messages, or the DLSw implementation does not report receiving it, a string of zero length is returned. This object is present only if the agent keeps circuit table entries around for some period after circuit disconnect." ::= { dlswCircuitEntry 31 } -- ................................................................... -- Statistics related to this circuit. -- All statistics are in LLC-2 Link Station Statistical Table. -- All SDLC statistics are in SDLC MIB -- ................................................................... -- ******************************************************************* -- DLSW SDLC EXTENSION -- ******************************************************************* dlswSdlcLsEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in dlswSdlcLsTable." ::= { dlswSdlc 1 } -- ................................................................... dlswSdlcLsTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswSdlcLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 68] RFC 2024 DLSw MIB using SMIv2 October 1996 "The table defines the virtual MAC addresses for those SDLC link stations that participate in data link switching." ::= { dlswSdlc 2 } dlswSdlcLsEntry OBJECT-TYPE SYNTAX DlswSdlcLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this table is the ifIndex value for the SDLC port which owns this link station and the poll address of the particular SDLC link station." INDEX { ifIndex, sdlcLSAddress } ::= { dlswSdlcLsTable 1 } DlswSdlcLsEntry ::= SEQUENCE { dlswSdlcLsLocalMac MacAddressNC, dlswSdlcLsLocalSap OCTET STRING, dlswSdlcLsLocalIdBlock DisplayString, dlswSdlcLsLocalIdNum DisplayString, dlswSdlcLsRemoteMac MacAddressNC, dlswSdlcLsRemoteSap OCTET STRING, dlswSdlcLsRowStatus RowStatus } dlswSdlcLsLocalMac OBJECT-TYPE SYNTAX MacAddressNC MAX-ACCESS read-create STATUS current DESCRIPTION "The virtual MAC address used to represent the SDLC-attached link station to the rest of the DLSw network." ::= { dlswSdlcLsEntry 1 } dlswSdlcLsLocalSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "The SAP used to represent this link station." ::= { dlswSdlcLsEntry 2 } dlswSdlcLsLocalIdBlock OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The block number is the first three digits of the node_id, Chen, et. al. Standards Track [Page 69] RFC 2024 DLSw MIB using SMIv2 October 1996 if available. These 3 hexadecimal digits identify the product." DEFVAL { ''H } ::= { dlswSdlcLsEntry 3 } dlswSdlcLsLocalIdNum OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 5)) MAX-ACCESS read-create STATUS current DESCRIPTION "The ID number is the last 5 digits of the node_id, if available. These 5 hexadecimal digits are administratively defined and combined with the 3 digit block number form the node_id. This node_id is used to identify the local node and is included in SNA XIDs." DEFVAL { ''H } ::= { dlswSdlcLsEntry 4 } dlswSdlcLsRemoteMac OBJECT-TYPE SYNTAX MacAddressNC MAX-ACCESS read-create STATUS current DESCRIPTION "The MAC address to which DLSw should attempt to connect this link station. If this information is not available, a length of zero for this object should be returned." DEFVAL { ''H } ::= { dlswSdlcLsEntry 5 } dlswSdlcLsRemoteSap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 1)) MAX-ACCESS read-create STATUS current DESCRIPTION "The SAP of the remote station to which this link station should be connected. If this information is not available, a length of zero for this object should be returned." DEFVAL { ''H } ::= { dlswSdlcLsEntry 6 } dlswSdlcLsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by the manager to create or delete the row entry in the dlswSdlcLsTable Chen, et. al. Standards Track [Page 70] RFC 2024 DLSw MIB using SMIv2 October 1996 following the RowStatus textual convention." ::= { dlswSdlcLsEntry 7 } -- ******************************************************************* -- TRAP GENERATION CONTROL -- ******************************************************************* dlswTrapControl OBJECT IDENTIFIER ::= { dlswNode 10} dlswTrapCntlTConnPartnerReject OBJECT-TYPE SYNTAX INTEGER { enabled (1), disabled (2), partial (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the DLSw is permitted to emit partner reject related traps. With the value of `enabled' the DLSw will emit all partner reject related traps. With the value of `disabled' the DLSw will not emit any partner reject related traps. With the value of `partial' the DLSw will only emits partner reject traps for CapEx reject. The changes take effect immediately." ::= { dlswTrapControl 1 } dlswTrapCntlTConnProtViolation OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the DLSw is permitted to generate protocol-violation traps on the events such as window size violation. The changes take effect immediately." ::= { dlswTrapControl 2 } dlswTrapCntlTConn OBJECT-TYPE SYNTAX INTEGER { enabled (1), disabled (2), partial (3) } MAX-ACCESS read-write STATUS current DESCRIPTION Chen, et. al. Standards Track [Page 71] RFC 2024 DLSw MIB using SMIv2 October 1996 "Indicates whether the DLSw is permitted to emit transport connection up and down traps. With the value of `enabled' the DLSw will emit traps when connections enter `connected' and `disconnected' states. With the value of `disabled' the DLSw will not emit traps when connections enter of `connected' and `disconnected' states. With the value of `partial' the DLSw will only emits transport connection down traps when the connection is closed with busy. The changes take effect immediately." ::= { dlswTrapControl 3 } dlswTrapCntlCircuit OBJECT-TYPE SYNTAX INTEGER { enabled (1), disabled (2), partial (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the DLSw is permitted to generate circuit up and down traps. With the value of `enabled' the DLSw will emit traps when circuits enter `connected' and `disconnected' states. With the value of `disabled' the DLSw will not emit traps when circuits enter of `connected' and `disconnected' states. With the value of `partial' the DLSw will emit traps only for those circuits that are initiated by this DLSw, e.g., originating the CUR_CS message. The changes take effect immediately." ::= { dlswTrapControl 4 } -- ******************************************************************* -- NOTIFICATIONS, i.e., TRAP DEFINITIONS -- ******************************************************************* dlswTraps OBJECT IDENTIFIER ::= { dlswMIB 0 } -- ------------------------------------------------------------------- -- This section defines the well-known notifications sent by -- DLSW agents. -- Care must be taken to insure that no particular notification -- is sent to a single receiving entity more often than once -- every five seconds. -- -- Traps includes: -- (1) Partner rejected (capEx rejection, not in partner list, etc.) -- (2) DLSw protocol violation (e.g., window size violation, etc.) -- (3) Transport connection up/down Chen, et. al. Standards Track [Page 72] RFC 2024 DLSw MIB using SMIv2 October 1996 -- (4) Circuit up/down -- ------------------------------------------------------------------- -- dlswTrapTConnPartnerReject NOTIFICATION-TYPE OBJECTS { dlswTConnOperTDomain, dlswTConnOperRemoteTAddr } STATUS current DESCRIPTION "This trap is sent each time a transport connection is rejected by a partner DLSw during Capabilities Exchanges. The emission of this trap is controlled by dlswTrapCntlTConnPartnerReject." ::= { dlswTraps 1 } dlswTrapTConnProtViolation NOTIFICATION-TYPE OBJECTS { dlswTConnOperTDomain, dlswTConnOperRemoteTAddr } STATUS current DESCRIPTION "This trap is sent each time a protocol violation is detected for a transport connection. The emission of this trap is controlled by dlswTrapCntlTConnProtViolation." ::= { dlswTraps 2 } dlswTrapTConnUp NOTIFICATION-TYPE OBJECTS { dlswTConnOperTDomain, dlswTConnOperRemoteTAddr } STATUS current DESCRIPTION "This trap is sent each time a transport connection enters `connected' state. The emission of this trap is controlled by dlswTrapCntlTConn." ::= { dlswTraps 3 } dlswTrapTConnDown NOTIFICATION-TYPE OBJECTS { dlswTConnOperTDomain, dlswTConnOperRemoteTAddr } STATUS current DESCRIPTION "This trap is sent each time a transport connection enters `disconnected' state. The emission of this trap is controlled by dlswTrapCntlTConn." ::= { dlswTraps 4 } dlswTrapCircuitUp NOTIFICATION-TYPE OBJECTS { dlswCircuitS1Mac, dlswCircuitS1Sap, dlswCircuitS2Mac, dlswCircuitS2Sap Chen, et. al. Standards Track [Page 73] RFC 2024 DLSw MIB using SMIv2 October 1996 } STATUS current DESCRIPTION "This trap is sent each time a circuit enters `connected' state. The emission of this trap is controlled by dlswTrapCntlCircuit." ::= { dlswTraps 5 } dlswTrapCircuitDown NOTIFICATION-TYPE OBJECTS { dlswCircuitS1Mac, dlswCircuitS1Sap, dlswCircuitS2Mac, dlswCircuitS2Sap } STATUS current DESCRIPTION "This trap is sent each time a circuit enters `disconnected' state. The emission of this trap is controlled by dlswTrapCntlCircuit." ::= { dlswTraps 6 } -- ******************************************************************* -- CONFORMANCE INFORMATION -- ******************************************************************* dlswConformance OBJECT IDENTIFIER ::= { dlsw 3 } dlswCompliances OBJECT IDENTIFIER ::= { dlswConformance 1 } dlswGroups OBJECT IDENTIFIER ::= { dlswConformance 2 } -- ------------------------------------------------------------------- -- COMPLIANCE STATEMENTS -- ------------------------------------------------------------------- -- ................................................................... -- Core compliance for all DLSw entities -- ................................................................... dlswCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The core compliance statement for all DLSw nodes." MODULE MANDATORY-GROUPS { dlswNodeGroup, dlswTConnStatGroup, dlswTConnConfigGroup, dlswTConnOperGroup, dlswInterfaceGroup, dlswCircuitGroup, dlswCircuitStatGroup, Chen, et. al. Standards Track [Page 74] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswNotificationGroup } GROUP dlswNodeNBGroup DESCRIPTION "The DLSw NetBIOS Node group is mandatory only for those DLSw entities that implement NetBIOS." GROUP dlswTConnNBGroup DESCRIPTION "The DLSw NetBIOS Transport Connection group is mandatory only for those DLSw entities that implement NetBIOS." OBJECT dlswNodeStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswNodeVirtualSegmentLFSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswNodeResourceNBExclusivity MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswNodeResourceMacExclusivity MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTrapCntlTConnPartnerReject MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTrapCntlTConnProtViolation MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTrapCntlTConn MIN-ACCESS read-only DESCRIPTION "Write access is not required." Chen, et. al. Standards Track [Page 75] RFC 2024 DLSw MIB using SMIv2 October 1996 OBJECT dlswTrapCntlCircuit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigTDomain MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigLocalTAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigRemoteTAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigEntryType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigGroupDefinition MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigSetupType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigSapList MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigAdvertiseMacNB MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnConfigInitCirRecvWndw MIN-ACCESS read-only DESCRIPTION Chen, et. al. Standards Track [Page 76] RFC 2024 DLSw MIB using SMIv2 October 1996 "Write access is not required." OBJECT dlswTConnConfigRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnOperState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswIfRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswIfVirtualSegment MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswIfSapList MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswCircuitState MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { dlswCompliances 1 } -- ................................................................... -- Compliance for all DLSw entities that provide TCP transport. -- ................................................................... dlswTConnTcpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for DLSw nodes that use TCP as a transport connection protocol." MODULE MANDATORY-GROUPS { dlswTConnTcpConfigGroup, dlswTConnTcpOperGroup } OBJECT dlswTConnTcpConfigKeepAliveInt Chen, et. al. Standards Track [Page 77] RFC 2024 DLSw MIB using SMIv2 October 1996 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnTcpConfigTcpConnections MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswTConnTcpConfigMaxSegmentSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { dlswCompliances 2 } -- ................................................................... -- Compliance for all DLSw Entities that implement a directory -- ................................................................... dlswDirCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for DLSw nodes that provide a directory function." MODULE MANDATORY-GROUPS { dlswDirGroup } GROUP dlswDirNBGroup DESCRIPTION "The DLSw NetBIOS group is mandatory only for those DLSw entities that implement NetBIOS." OBJECT dlswDirMacMac MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirMacMask MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirMacEntryType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Chen, et. al. Standards Track [Page 78] RFC 2024 DLSw MIB using SMIv2 October 1996 OBJECT dlswDirMacLocationType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirMacLocation MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirMacStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirMacLFSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirMacRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirNBName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirNBNameType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirNBEntryType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirNBLocationType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirNBLocation MIN-ACCESS read-only DESCRIPTION Chen, et. al. Standards Track [Page 79] RFC 2024 DLSw MIB using SMIv2 October 1996 "Write access is not required." OBJECT dlswDirNBStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirNBLFSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswDirNBRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { dlswCompliances 3 } -- ................................................................... -- Compliance for all DLSw entities that provide an ordered -- list of directory entries that match a resource -- ................................................................... dlswDirLocateCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for DLSw nodes that provide an ordered list of directory entries for a given resource." MODULE MANDATORY-GROUPS { dlswDirLocateGroup } GROUP dlswDirLocateNBGroup DESCRIPTION "The DLSw NetBIOS group is mandatory only for those DLSw entities that implement NetBIOS." ::= { dlswCompliances 4 } -- ................................................................... -- Compliance for all DLSw entities that support SDLC end stations -- ................................................................... dlswSdlcCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for DLSw nodes that support SDLC." MODULE MANDATORY-GROUPS { Chen, et. al. Standards Track [Page 80] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswSdlcGroup } OBJECT dlswSdlcLsLocalMac MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswSdlcLsLocalSap MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswSdlcLsLocalIdBlock MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswSdlcLsLocalIdNum MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswSdlcLsRemoteMac MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswSdlcLsRemoteSap MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dlswSdlcLsRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { dlswCompliances 5 } -- ------------------------------------------------------------------- -- CONFORMANCE GROUPS -- ------------------------------------------------------------------- -- ................................................................... -- Node Conformance Group -- ................................................................... dlswNodeGroup OBJECT-GROUP OBJECTS { Chen, et. al. Standards Track [Page 81] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswNodeVersion, dlswNodeVendorID, dlswNodeVersionString, dlswNodeStdPacingSupport, dlswNodeStatus, dlswNodeUpTime, dlswNodeVirtualSegmentLFSize, dlswNodeResourceMacExclusivity, dlswTrapCntlTConnPartnerReject, dlswTrapCntlTConnProtViolation, dlswTrapCntlTConn, dlswTrapCntlCircuit } STATUS current DESCRIPTION "Conformance group for DLSw node general information." ::= { dlswGroups 1 } -- ................................................................... dlswNodeNBGroup OBJECT-GROUP OBJECTS { dlswNodeResourceNBExclusivity } STATUS current DESCRIPTION "Conformance group for DLSw node general information specifically for nodes that support NetBIOS." ::= { dlswGroups 2 } -- ................................................................... dlswTConnStatGroup OBJECT-GROUP OBJECTS { dlswTConnStatActiveConnections, dlswTConnStatCloseIdles, dlswTConnStatCloseBusys } STATUS current DESCRIPTION "Conformance group for statistics for transport connections." ::= { dlswGroups 3 } -- ................................................................... dlswTConnConfigGroup OBJECT-GROUP OBJECTS { dlswTConnConfigTDomain, dlswTConnConfigLocalTAddr, dlswTConnConfigRemoteTAddr, Chen, et. al. Standards Track [Page 82] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswTConnConfigLastModifyTime, dlswTConnConfigEntryType, dlswTConnConfigGroupDefinition, dlswTConnConfigSetupType, dlswTConnConfigSapList, dlswTConnConfigAdvertiseMacNB, dlswTConnConfigInitCirRecvWndw, dlswTConnConfigOpens, dlswTConnConfigRowStatus } STATUS current DESCRIPTION "Conformance group for the configuration of transport connections." ::= { dlswGroups 4 } -- ................................................................... dlswTConnOperGroup OBJECT-GROUP OBJECTS { dlswTConnOperLocalTAddr, dlswTConnOperEntryTime, dlswTConnOperConnectTime, dlswTConnOperState, dlswTConnOperConfigIndex, dlswTConnOperFlowCntlMode, dlswTConnOperPartnerVersion, dlswTConnOperPartnerVendorID, dlswTConnOperPartnerVersionStr, dlswTConnOperPartnerInitPacingWndw, dlswTConnOperPartnerSapList, dlswTConnOperPartnerMacExcl, dlswTConnOperPartnerMacInfo, dlswTConnOperDiscTime, dlswTConnOperDiscReason, dlswTConnOperDiscActiveCir, dlswTConnOperInDataPkts, dlswTConnOperOutDataPkts, dlswTConnOperInDataOctets, dlswTConnOperOutDataOctets, dlswTConnOperInCntlPkts, dlswTConnOperOutCntlPkts, dlswTConnOperCURexSents, dlswTConnOperICRexRcvds, dlswTConnOperCURexRcvds, dlswTConnOperICRexSents, dlswTConnOperCirCreates, dlswTConnOperCircuits } Chen, et. al. Standards Track [Page 83] RFC 2024 DLSw MIB using SMIv2 October 1996 STATUS current DESCRIPTION "Conformance group for operation information for transport connections." ::= { dlswGroups 5 } -- ................................................................... dlswTConnNBGroup OBJECT-GROUP OBJECTS { dlswTConnOperPartnerNBExcl, dlswTConnOperPartnerNBInfo, dlswTConnOperNQexSents, dlswTConnOperNRexRcvds, dlswTConnOperNQexRcvds, dlswTConnOperNRexSents } STATUS current DESCRIPTION "Conformance group for operation information for transport connections, specifically for nodes that support NetBIOS." ::= { dlswGroups 6 } -- ................................................................... dlswTConnTcpConfigGroup OBJECT-GROUP OBJECTS { dlswTConnTcpConfigKeepAliveInt, dlswTConnTcpConfigTcpConnections, dlswTConnTcpConfigMaxSegmentSize } STATUS current DESCRIPTION "Conformance group for configuration information for transport connections using TCP." ::= { dlswGroups 7 } -- ................................................................... dlswTConnTcpOperGroup OBJECT-GROUP OBJECTS { dlswTConnTcpOperKeepAliveInt, dlswTConnTcpOperPrefTcpConnections, dlswTConnTcpOperTcpConnections } STATUS current DESCRIPTION "Conformance group for operation information for transport connections using TCP." ::= { dlswGroups 8 } Chen, et. al. Standards Track [Page 84] RFC 2024 DLSw MIB using SMIv2 October 1996 -- ................................................................... dlswInterfaceGroup OBJECT-GROUP OBJECTS { dlswIfRowStatus, dlswIfVirtualSegment, dlswIfSapList } STATUS current DESCRIPTION "Conformance group for DLSw interfaces." ::= { dlswGroups 9 } -- ................................................................... dlswDirGroup OBJECT-GROUP OBJECTS { dlswDirMacEntries, dlswDirMacCacheHits, dlswDirMacCacheMisses, dlswDirMacCacheNextIndex, dlswDirMacMac, dlswDirMacMask, dlswDirMacEntryType, dlswDirMacLocationType, dlswDirMacLocation, dlswDirMacStatus, dlswDirMacLFSize, dlswDirMacRowStatus } STATUS current DESCRIPTION "Conformance group for DLSw directory using MAC addresses." ::= { dlswGroups 10 } -- ................................................................... dlswDirNBGroup OBJECT-GROUP OBJECTS { dlswDirNBEntries, dlswDirNBCacheHits, dlswDirNBCacheMisses, dlswDirNBCacheNextIndex, dlswDirNBName, dlswDirNBNameType, dlswDirNBEntryType, dlswDirNBLocationType, dlswDirNBLocation, dlswDirNBStatus, dlswDirNBLFSize, Chen, et. al. Standards Track [Page 85] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswDirNBRowStatus } STATUS current DESCRIPTION "Conformance group for DLSw directory using NetBIOS names." ::= { dlswGroups 11 } -- ................................................................... dlswDirLocateGroup OBJECT-GROUP OBJECTS { dlswDirLocateMacLocation } STATUS current DESCRIPTION "Conformance group for a node that can return directory entry order for a given MAC address." ::= { dlswGroups 12 } -- ................................................................... dlswDirLocateNBGroup OBJECT-GROUP OBJECTS { dlswDirLocateNBLocation } STATUS current DESCRIPTION "Conformance group for a node that can return directory entry order for a given NetBIOS name." ::= { dlswGroups 13 } -- ................................................................... dlswCircuitStatGroup OBJECT-GROUP OBJECTS { dlswCircuitStatActives, dlswCircuitStatCreates } STATUS current DESCRIPTION "Conformance group for statistics about circuits." ::= { dlswGroups 14 } -- ................................................................... dlswCircuitGroup OBJECT-GROUP OBJECTS { dlswCircuitS1IfIndex, dlswCircuitS1DlcType, dlswCircuitS1RouteInfo, dlswCircuitS1CircuitId, Chen, et. al. Standards Track [Page 86] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswCircuitS1Dlc, dlswCircuitS2Location, dlswCircuitS2TDomain, dlswCircuitS2TAddress, dlswCircuitS2CircuitId, dlswCircuitOrigin, dlswCircuitEntryTime, dlswCircuitStateTime, dlswCircuitState, dlswCircuitPriority, dlswCircuitFCSendGrantedUnits, dlswCircuitFCSendCurrentWndw, dlswCircuitFCRecvGrantedUnits, dlswCircuitFCRecvCurrentWndw, dlswCircuitFCLargestRecvGranted, dlswCircuitFCLargestSendGranted, dlswCircuitFCHalveWndwSents, dlswCircuitFCResetOpSents, dlswCircuitFCHalveWndwRcvds, dlswCircuitFCResetOpRcvds, dlswCircuitDiscReasonLocal, dlswCircuitDiscReasonRemote, dlswCircuitDiscReasonRemoteData } STATUS current DESCRIPTION "Conformance group for DLSw circuits." ::= { dlswGroups 15 } -- ................................................................... dlswSdlcGroup OBJECT-GROUP OBJECTS { dlswSdlcLsEntries, dlswSdlcLsLocalMac, dlswSdlcLsLocalSap, dlswSdlcLsLocalIdBlock, dlswSdlcLsLocalIdNum, dlswSdlcLsRemoteMac, dlswSdlcLsRemoteSap, dlswSdlcLsRowStatus } STATUS current DESCRIPTION "Conformance group for DLSw SDLC support." ::= { dlswGroups 16 } -- ................................................................... dlswNotificationGroup NOTIFICATION-GROUP Chen, et. al. Standards Track [Page 87] RFC 2024 DLSw MIB using SMIv2 October 1996 NOTIFICATIONS { dlswTrapTConnPartnerReject, dlswTrapTConnProtViolation, dlswTrapTConnUp, dlswTrapTConnDown, dlswTrapCircuitUp, dlswTrapCircuitDown } STATUS current DESCRIPTION "Conformance group for DLSw notifications." ::= { dlswGroups 17 } END Chen, et. al. Standards Track [Page 88] RFC 2024 DLSw MIB using SMIv2 October 1996 4.0 Acknowledgements This memo has been produced by the AIW DLSw MIB RIGlet, which is also recognized as the IETF DLSw MIB Working Group. 5.0 References [1] Bartky, A., "Data Link Switching: Switch-to-Switch Protocol; AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1", RFC 1795, Sync Research Inc., April 1995. [2] 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. [3] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [4] McCloghrie, K., and M. Rose, "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. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] 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. [7] IEEE Project, "ANSI/IEEE P802.1D", 1993 [8] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [9] Hilgeman, J., S. Nix, A. Bartky, and W. Clark, "Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2", RFC 1747, Apertus Technologies, Inc., Metaplex, Inc., Sync Research, Inc., cisco Systems, Inc., January 1995 Chen, et. al. Standards Track [Page 89] RFC 2024 DLSw MIB using SMIv2 October 1996 6.0 Security Considerations Security issues are not discussed in this memo. 7.0 Authors' Addresses David D. Chen IBM Networking Systems P. O. Box 12195 Research Triangle Park, NC 27709 US Phone: +1 919 254 6182 EMail: dchen@vnet.ibm.com Peter W. Gayek IBM Networking Systems P. O. Box 12195 Research Triangle Park, NC 27709 US Phone: +1 919 254 1808 EMail: gayek@vnet.ibm.com Shannon Nix Metaplex, Inc. 7025 Kit Creek Road P. O. Box 14987 Research Triangle Park, NC 27709 US Phone: +1 919 472 2388 EMail: snix@metaplex.com Chen, et. al. Standards Track [Page 90] snmp-mibs-downloader-1.1/mibrfcs/rfc2051.txt0000644000000000000000000072337711402176071015574 0ustar Network Working Group M. Allen Request for Comments: 2051 Wall Data Inc. Category: Standards Track B. Clouston Z. Kielczewski Cisco Systems W. Kwan Jupiter Technology Inc. B. Moore IBM October 1996 Definitions of Managed Objects for APPC using SMIv2 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 ........................................... 1 2. The SNMP Network Management Framework .................. 1 3. Overview ............................................... 2 3.1 APPC MIB structure ...................................... 4 4. Definitions ............................................ 10 5. Acknowledgments ........................................ 123 6. References ............................................. 123 7. Security Considerations ................................ 123 8. Authors' Addresses ..................................... 124 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. 2. The SNMP Network Management Framework The SNMP Network Management Framework consists of several components. For the purpose of this specification, the applicable components of the Framework are the SMI and related documents [2, 3, 4], which define the mechanisms used for describing and naming objects for the Allen, et. al. Standards Track [Page 1] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 purpose of management. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 3. Overview This document identifies the proposed set of objects for managing the configuration, monitoring and controlling devices with APPC capabilities. APPC is the aspect of SNA which supports peer-to-peer communication, and provides the interface for applications to communicate. In this document, we will describe LU6.2 protocol- specific managed objects. This document describes both dependent and independent LU 6.2 protocols. A dependent LU requires assistance from an SSCP in order to activate an LU 6.2 session. An independent LU is able to activate an LU 6.2 session without assistance from the SSCP. If the agent supports dependent LU 6.2 only, the SNA NAU MIB, RFC 1666 [7] is used instead to represent those objects. Local LUs and partner LUs connect with each other using sessions. Multiple different sessions can be established between LUs with characteristics defined by Modes. Session limits within a defined Mode are negotiated between the local and partner LUs using a protocol called CNOS (Change Number of Sessions). Transaction Programs (TPs) are applications that use sessions to communicate with each other. Multiple TPs can use the same session, but not at the same time. A single usage of a session is called a conversation. While a session can stay active for a long time, a conversation can come up and down based on usage by the TPs. Common Programming Interface - Communications (CPI-C) is a standard API (Application Programming Interface) for APPC and OSI TP that is used by TPs for accessing conversations. Although, many of the CPI-C objects in this MIB are relevant to both APPC and OSI TP, the intention is for managing APPC products only. SNA names such as LU names, CP names, mode names, and COS names can be padded with space characters in SNA formats. These space characters are insignificant. For example, in a BIND RU a mode name of "#INTER" with a length of 6 is identical to a mode name of "#INTER " with a length of 8. However, in this MIB, insignificant space characters are not included by the agent. Using the mode name from the previous example, an agent would return a length of 6 and the Allen, et. al. Standards Track [Page 2] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 string "#INTER" with no space characters for appcModeAdminModeName, regardless of how it appears in the BIND RU or in internal storage. The lone exception is the all blank mode name, for which the agent returns a length of 8 and the string " " (8 space characterss). When an SNA name is functioning as a table index, an agent shall treat trailing space characters as significant. If a Management Station requests the objects from a row with index "#INTER ", the agent does not match this to the row with index "#INTER". Since an agent has no insignificant space characters in any of its table indices, the only reason for a Management Station to include them would be to start GetNext processing at a chosen point in a table. For example, a GetNext request with index "M " would start retrieval from a table at the first row with an 8-character index beginning with M or a letter after M. The SNA/APPC terms and overall architecture are documented in [1], [5], and [6]. Highlights of the management functions supported by the APPC MIB module include the following: o Activating and deactivating statistics keeping and counting. o Activating and deactivating tracing. o Issuing CNOS processing verbs/commands for INITIALIZE_SESSION_LIMIT, CHANGE_SESSION_LIMIT and RESET_SESSION_LIMIT. o Monitoring of parameters related to local LU, partner LU, modes, TPs and CPI-C side information. o Deactivating sessions. o Monitoring of LU6.2-specific session operational parameters and statistics, historical information about abnormally terminated sessions, and information about APPC sessions that are transported by APPN HPR. o Monitoring of conversation operational parameters, and historical information about abnormally terminated sessions. Allen, et. al. Standards Track [Page 3] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 This MIB module does not support: o Modifying APPC defaults. o Creating and deleting partner LUs, modes, TPs, and CPI-C side information tables. o Modifying parameters related to local LU, partner LU, modes, TPs, and CPI-C side information. o Activating or deactivating local LUs. o Activating or deactivating partner LUs. o Activating or deactivating conversations. o Activating or deactivating Transaction Programs. o Activating sessions. o Traps 3.1. APPC MIB Structure The APPC MIB module contains six groups of objects: o appcGlobal - objects related to global defaults and controls. In addition, CNOS processing objects are also part of this group. o appcLu - objects related to LU6.2-specific local and partner LU, mode definition, monitoring and control. o appcTp - objects related to transaction program definition, monitoring and control. o appcSession - objects related to LU6.2-specific session monitoring. o appcConversation - objects related to conversation monitoring. o appcCPIC - objects related to related CPI-C side information. These groups are described below in more detail. The objects related to LU6.2 are generally organized into two types of tables: the Admin and Oper tables. Allen, et. al. Standards Track [Page 4] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 The "Admin" table contains read-only objects which contain default or expected configuration values. This MIB does not create or modify configuration values. The "Oper" table contains objects which provide current operational values, such as state values or negotiated parameters, for dynamic or configured objects. Dynamic objects are created by the APPC system using one of the templates provided in the "Admin" table. Configured objects usually have a one-to-one relationship between "Admin" and "Oper" entries. However, some "Admin" values may have changed since the object became operational, such that the "Oper" values may no longer be based on the "Admin" values. The "Admin" entry could even be deleted. For example, some implementations may allow a mode definition (appcModeAdminEntry) to be deleted even while an active session was using this mode (appcModeOperEntry still exists). Where appropriate, the "Oper" table may include initial starting values for objects that can be reconfigured while operational. How the "Admin" values are changed or deleted is outside the scope of this MIB. 3.1.1. appcGlobal group The appcGlobal group consists of the following tables and objects: 1) appcCntrlAdminGroup This group of objects controls whether certain statistics and counters (e.g., session counters and RSCV collection) should be maintained by the Agent. In addition, the ability to activate and deactivate tracing is also supported through objects in this group. These objects are for Agent implementations that wish to provide this level of operational control and are optional. The objects in this group represent the desired state, with the actual operational values in appcCntlOperGroup. These objects can be generated initially, after startup of SNA service, by the Agent which uses information from the Node configuration file. Subsequent modifications of object values is possible by a Management station. The modifications to these objects can be saved in the Node configuration file for the next startup (i.e., restart or next initialization) of SNA service, but the mechanism for this function is not defined in this document. 2) appcCntrlOperGroup This group of objects monitors whether certain statistics and counters (e.g., session counters and RSCV collection ) are maintained by an Agent. In addition, the ability to monitor tracing activity is also supported through objects in this group. Allen, et. al. Standards Track [Page 5] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 This table represents the actual operational state. These states can be modified via objects in the appcCntrlAdminGroup. 3) appcGlobalObjects These objects describe global information such as APPC system start time, the control point name, and default LU 6.2 configuration values. The type of default configuration information includes mode name, LU, and maximum logical record size. 4) appcCnosControl These objects allows for issuing of CNOS commands relative to a local and partner LU pair and a Mode. They support the following CNOS commands: INITIALIZE_SESSION_LIMIT, CHANGE_SESSION_LIMIT and RESET_SESSION_LIMIT. The objects in this group can be modified by a Management Station. This group consists of objects that are relevant to the CNOS commands parameters, which a Management Station needs to set. After setting the parameters of a CNOS command, the Management Station will set the control object (appcCnosCommand) to request the Agent to issue the appropriate CNOS command. 3.1.2. appcLu group The appcLu group consists of the following tables: 1) appcLluAdminTable This table contains objects which describe specific LU6.2 local LU configuration information. The type of information includes the maximum number of sessions supported and compression parameters. 2) appcLluOperTable This table contains objects which describe specific LU6.2 local LU operational information. The type of information includes the maximum number of sessions supported, the number of sessions currently active, and compression parameters. 3) appcLuPairAdminTable This table contains objects which describe local LU and partner LU configuration information. The type of information includes security information and whether parallel sessions are supported. Allen, et. al. Standards Track [Page 6] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 For those implementations that have partner LU definitions associated with each local LU, multiple entries with the same appcLuPairAdminParLuName could exist with different appcLuPairAdminLocLuName. For those implementations in which partner LU definitions apply to all local LUs, the appcLuPairAdminLocLuName is set to '*ALL'. 4) appcLuPairOperTable This table contains objects which describe partner/local LU pair run- time operational information. The type of information includes security information and whether parallel sessions are supported. Although the Admin (appcLuPairAdminTable) table entries could be global to all local LUs in a Node, an entry in this Oper table is always associated with one local LU. A row in this table is created as soon as there is an active session between the local and partner LU. Two entries are present when both LUs in a pair are local. 5) appcModeAdminTable This table contains objects which describe Mode configuration information. The type of information includes the mode name and maximum session limit. For those implementations that have Mode definitions associated with each local and partner LU pair, multiple entries with the same appcModeAdminModeName could exist with different appcModeAdminLocLuName and appcModeAdminParLuName. For those implementations in which Mode definitions apply to all local and/or all partner LUs, the appcModeAdminLocLuName and/or appcModeAdminParLuName are set to '*ALL'. 6) appcModeOperTable This table contains objects which describe Mode run-time operational information for each local/partner LU pair. The type of information includes the mode name and maximum session limit. Although the Admin table entries could be global to all local and partner LUs in a Node, the Oper table entries are always associated with one local and partner LU pair. A row in this table is created as soon as there is an active session between local and partner LU for this Mode. Two entries are present when both LUs in a pair are local. Allen, et. al. Standards Track [Page 7] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 3.1.3. appcTp group The appcTp group consists of the following table: 1) appcTpAdminTable This table contains objects which describe transaction program (TP) configuration information. The type of information includes the TP name and TP operation, indicating how the TP will be started. For those implementations that have TP definitions associated with each local LU, multiple entries with the same appcTpAdminTpName could exist with different appcTpAdminLocLuName. For those implementations in which TP definition applies to all local LUs, it will have appcTpAdminLocLuName set to '*ALL'. There is no appcTpOperTable. Run-time information about TP tends to be product-specific (e.g., process Id), and much of the information can be derived from the conversation tables. 3.1.4. appcSession group The appcSession group consists of the following tables: 1) appcActSessTable This table contains objects which describe LU6.2 session information. The type of information includes the PCID and the pacing counts. 2) appcSessStatsTable This table contains statistical information about LU 6.2 sessions. The type of information includes counters of bytes and RUs sent and received. 3) appcHistSessTable This table contains historical information about APPC sessions that have terminated abnormally. The type of information includes the unbind type and sense data. 4) appcSessRtpTable This table contains information about LU 6.2 sesions that are being transported by High Performance Routing. The type of information includes the NCEID and TCID. Allen, et. al. Standards Track [Page 8] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 3.1.5. appcConversation group The appcConversation group consists of the following tables: 1) appcActiveConvTable This table contains objects which describe active conversation information. The type of information includes the state and type. An entry is created by an Agent when the conversation is started, and is removed when the conversation ends. 2) appcHistConvTable This table contains objects which describe historical conversation information about abnormally terminated conversations. The number of entries and how long they are kept depends on the Agent implementation. The type of information inclues the sense data and log data. 3.1.6. appcCPIC group The appcCPIC group consists of the following tables: 1) appcCpicAdminTable This table contains objects which describe CPI-C side information. The type of information includes the symbolic destination name and partner LU name. For those implementations that have CPI-C definition associated with each local LU, multiple entries with the same appcCpicAdminSymbDestName could exist with different appcCpicAdminLocLuName. For those implementations in which CPI-C definition applies to all local LUs, it will have appcCpicAdminLocLuName set to '*ALL'. 2) appcCpicOperTable This table contains objects which describe CPI-C run-time operational information. The type of information includes the symbolic destination name and partner LU name. Allen, et. al. Standards Track [Page 9] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 4. Definitions APPC-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString, InstancePointer, TEXTUAL-CONVENTION, DateAndTime FROM SNMPv2-TC mib-2, Counter32, Gauge32, Integer32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY FROM SNMPv2-SMI snanauMIB FROM SNA-NAU-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; appcMIB MODULE-IDENTITY LAST-UPDATED "9512150000Z" ORGANIZATION "IETF SNA NAU MIB Working Group" CONTACT-INFO " Michael Allen Wall Data Inc. P.O.Box 1120 Duval, WA 98019, USA Tel: 1 206 844 3505 E-mail: mallen@hq.walldata.com Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Tel: 1 919 472 2333 E-mail: clouston@cisco.com Zbigniew Kielczewski Cisco Systems 3100 Smoketree Court Raleigh, NC 27604, USA Tel: 1 919 871 6326 E-mail: zbig@cisco.com Allen, et. al. Standards Track [Page 10] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 William Kwan Jupiter Technology Inc. 200 Prospect Street Waltham, MA 02254, USA Tel: 1 617 894 9300, x423 E-mail: billk@jti.com Bob Moore IBM Corporation 800 Park Offices Drive CNMA/664 P.O. Box 12195 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@ralvm6.vnet.ibm.com " DESCRIPTION "This is the MIB module for objects used to manage network devices with APPC capabilities." ::= { snanauMIB 3 } appcObjects OBJECT IDENTIFIER ::= { appcMIB 1 } appcGlobal OBJECT IDENTIFIER ::= { appcObjects 1 } appcLu OBJECT IDENTIFIER ::= { appcObjects 2 } appcTp OBJECT IDENTIFIER ::= { appcObjects 3 } appcSession OBJECT IDENTIFIER ::= { appcObjects 4 } appcConversation OBJECT IDENTIFIER ::= { appcObjects 5 } appcCPIC OBJECT IDENTIFIER ::= { appcObjects 6 } -- ********************************************************************* -- Objects in this MIB are used to model an SNA device that supports -- APPC LUs. -- Following is the overall organization of the MIB. -- -- 1. APPC Global Objects - global values, defaults, -- controls (including CNOS) -- 2. APPC Defined Lu Tables - Admin and Oper -- 3. APPC Defined LU Pair Tables - Admin and Oper -- 4. APPC Mode Tables - Admin and Oper -- 5. APPC TP Tables - Admin only -- 6. APPC Session Tables - Active, Stats, History, RTP -- 7. APPC Conversation Table - Active, History -- 8. APPC CPIC side info - Admin and Oper -- ********************************************************************* -- ********************************************************************* Allen, et. al. Standards Track [Page 11] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 -- Textual Convention -- --------------------------------------------------------------------- SnaSenseData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "To facilitate their display by a Management Station, sense data objects in the MIB are represented as DisplayStrings of size 8. Eight '0' characters indicates that no sense data identifying an SNA error condition is available." SYNTAX DisplayString (SIZE (8)) -- ********************************************************************* -- APPC Control Objects -- --------------------------------------------------------------------- -- The following objects allow: -- * the collection of APPC Session information counters -- to be started and stopped -- * the collection of APPC Session RSCVs -- to be started and stopped -- * the collection of APPC tracing information to be started and -- stopped -- -- These objects are for implementations that wish to provide -- this level of operational control. This group is -- conditionally mandatory in the conformance section of the MIB. -- -- ********************************************************************* -- ********************************************************************* -- Control Admin -- These objects contain the desired states for the controls. -- The actual states are in the Oper objects. -- ********************************************************************* appcCntrlAdminGroup OBJECT IDENTIFIER ::= { appcGlobal 1 } appcCntrlAdminStat OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the desired state of statistics collection: notActive collection of counters is not active. active collection of counters is active. Allen, et. al. Standards Track [Page 12] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 When this object is set to notActive, all of the entries are removed from the appcSessStatsTable." ::= { appcCntrlAdminGroup 1 } appcCntrlAdminRscv OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the desired state of RSCV information collection: notActive collection of route selection control vectors is not active. active collection of route selection control vectors is active." ::= { appcCntrlAdminGroup 2 } appcCntrlAdminTrace OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the desired state of tracing: notActive collection of tracing information is not active active collection of tracing information is active" ::= { appcCntrlAdminGroup 3 } appcCntrlAdminTraceParm OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the parameter to be used in conjunction with activating tracing. The actual content is implementation dependent." ::= { appcCntrlAdminGroup 4 } -- ********************************************************************* Allen, et. al. Standards Track [Page 13] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 -- Control Oper -- These objects contain the actual states of the controls. -- ********************************************************************* appcCntrlOperGroup OBJECT IDENTIFIER ::= { appcGlobal 2 } appcCntrlOperStat OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current collection options in effect: notActive collection of counters is not active. active collection of counters is active. Statistical entries are present in the appcSessStatsTable only when the value of this object is 'active'." ::= { appcCntrlOperGroup 1 } appcCntrlOperStatTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Time since the appcCntrlOperStat object last changed. This time is in hundreds of a second." ::= { appcCntrlOperGroup 2 } appcCntrlOperRscv OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current collection options in effect: notActive collection of route selection control vectors is not active. active collection of route selection control vectors is active." Allen, et. al. Standards Track [Page 14] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcCntrlOperGroup 3 } appcCntrlOperRscvTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Time since the appcCntrlOperRscv object last changed. This time is in hundreds of a second." ::= { appcCntrlOperGroup 4 } appcCntrlOperTrace OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state of tracing: notActive collection of tracing information is not active. active collection of tracing information is active." ::= { appcCntrlOperGroup 5 } appcCntrlOperTraceTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Time since the appcCntrlOperTrace object last changed. This time is in hundreds of a second." ::= { appcCntrlOperGroup 6 } appcCntrlOperTraceParm OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the parameter used in conjunction with activating tracing. The actual content is implementation dependent." ::= { appcCntrlOperGroup 7 } -- ****************************************************************** Allen, et. al. Standards Track [Page 15] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 -- -- APPC global settings -- -- ****************************************************************** appcGlobalObjects OBJECT IDENTIFIER ::= { appcGlobal 3 } appcUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time, in hundredths of a second, since the APPC portion of the system was last reinitialized." ::= { appcGlobalObjects 1 } appcDefaultModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the mode name to be used under the following conditions: When an incoming BIND request contains a mode name not defined at the local node. The parameters defined for this mode are used for the inbound implicit mode capability. When an APPC program issues an [MC_]ALLOCATE, [MC_]SEND_CONVERSATION, or CNOS verb, or when a CPI-C program issues an Allocate (CMALLC) call, specifying a mode name not defined at the local node. The parameters defined for this mode are used for the outbound implicit mode capability. This mode name must match a defined entry in the appcModeAdminTable." ::= { appcGlobalObjects 2 } appcDefaultLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the name of the local LU that is to serve as the default LU. This is the default LU to which are routed inbound Allen, et. al. Standards Track [Page 16] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 BIND requests that exclude the secondary LU name. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. This local LU name must match a defined entry in the appcLluAdminTable." ::= { appcGlobalObjects 3 } appcDefaultImplInbndPlu OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether or not inbound implicit partner LU support is enabled. The following values are defined: no - Specifies that inbound implicit partner LU support is disabled, which means that an incoming bind that specifies a partner LU that is not defined at the local node will be rejected. yes - Specifies that inbound implicit partner LU support is enabled, which provides the capability to accept an incoming BIND request that contains a partner LU name that is not defined at the local node." ::= { appcGlobalObjects 4 } appcDefaultMaxMcLlSndSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum size of a logical record to be used for a mapped conversation when sending data to either the inbound or outbound implicit partner LU. This size is the maximum number of bytes in a single logical record, as indicated in the LL field of the record. The default value is 32767. Note that this object does not limit the maximum size that an application program can supply on the Send Data call for a mapped conversation." ::= { appcGlobalObjects 5 } Allen, et. al. Standards Track [Page 17] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcDefaultFileSpec OBJECT-TYPE SYNTAX DisplayString (SIZE (0..80)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local file specification that is to be searched by the APPC attach manager when no DEFINE_TP verb has been issued for the TP name received on an incoming attach. In this case, the attach manager will attempt to start a program whose file name is the same as the incoming TP name. If found, the program is loaded. If not found, the attach is rejected. The value '*' indicates that the normal search path for executable programs is to be used for locating an undefined transaction program. A null string indicates that there is no default file specification for undefined transaction programs." ::= { appcGlobalObjects 6 } appcDefaultTpOperation OBJECT-TYPE SYNTAX INTEGER { other(1), queuedOperatorStarted(2), queuedOperatorPreloaded(3), queuedAmStarted(4), nonqueuedAmStarted(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies how the program will be started. other - Specifies that the default TP operation is none of the methods specified below. It may be a product-specific method. queuedOperatorStarted - Specifies that one version of the program will be run at a time. If an incoming attach arrives and the program has not been started yet, APPC will issue a message to the operator to start the specified program. Subsequent attaches that arrive while the program is active will be queued. queuedOperatorPreloaded - Specifies that one version Allen, et. al. Standards Track [Page 18] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 of the program will be run at a time. If an incoming attach arrives and the program has not been started yet, the Attach will be rejected. The APPC attach manager determines that a TP has started upon reception of an APPC RECEIVE_ALLOCATE verb, or a CPI-C Accept_Conversation (CMACCP) or Specify_Local_TP_Name (CMSLTP) call. No message is sent to the operator. Subsequent attaches that arrive while the program is active are queued. queuedAmStarted - Specifies that one version of the program will be run at a time and will be started by the APPC attach manager. Subsequent attaches that arrive while the program is active will be queued. nonqueuedAmStarted - Specifies that multiple copies of the program will be run at a time and will be started by the APPC attach manager. " ::= { appcGlobalObjects 7 } appcDefaultTpConvSecRqd OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether or not conversation security will be used for default TPs. no - Specifies that the incoming attach does not have to contain security information. yes - Specifies that the incoming attach must contain valid authentication information (e.g., user ID and password)." ::= { appcGlobalObjects 8 } appcLocalCpName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the name of the local control point. This field is from 0 to 17 characters in length, including a period (.) which Allen, et. al. Standards Track [Page 19] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 separates the NetId from the NAU name if the NetId is present. A null string indicates that the value is unknown." ::= { appcGlobalObjects 9 } appcActiveSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the total number of active APPC sessions supported by this implementation. Sessions for which both LUs are local are counted twice." ::= { appcGlobalObjects 10 } appcActiveHprSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the total number of active HPR APPC sessions." ::= { appcGlobalObjects 11 } -- ****************************************************************** -- APPC CNOS control -- -- This group contains objects for issuing APPC Change-Number-of-Session -- (CNOS) commands to a specific mode. Specifically, the commands -- supported are: -- INITIALIZE_SESSION_LIMIT -- CHANGE_SESSION_LIMIT -- RESET_SESSION_LIMIT -- -- -- ****************************************************************** appcCnosControl OBJECT IDENTIFIER ::= { appcGlobal 4 } appcCnosCommand OBJECT-TYPE SYNTAX INTEGER { initSesslimit(1), changeSesslimit(2), resetSesslimit(3) } MAX-ACCESS read-write STATUS current Allen, et. al. Standards Track [Page 20] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 DESCRIPTION "Specifies the CNOS command or verb to issue. First set the values of the particular CNOS parameter objects (from the range { appcCnosControl 2 } through { appcCnosControl 8 }) that apply to the CNOS command to be executed, set the three CNOS target objects ({ appcCnosControl 9 } through { appcCnosControl 11 }), then set this object to the command to be executed. Here is the list of parameter objects that must be set for each of the CNOS commands: INIT_SESSION_LIMIT - appcCnosMaxSessLimit appcCnosMinCwinLimit appcCnosMinClosLimit appcCnosTargetLocLuName appcCnosTargetParLuName appcCnosTargetModeName CHANGE_SESSION_LIMIT - appcCnosMaxSessLimit appcCnosMinCwinLimit appcCnosMinClosLimit appcCnosResponsible appcCnosTargetLocLuName appcCnosTargetParLuName appcCnosTargetModeName RESET_SESSION_LIMIT - appcCnosResponsible appcCnosDrainPart appcCnosForce appcCnosTargetLocLuName appcCnosTargetParLuName appcCnosTargetModeName " ::= { appcCnosControl 1 } appcCnosMaxSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the maximum value that the local LU is to use, during CNOS processing, for the session limit. The local LU, as a target LU, will negotiate a higher session limit it receives in the CNOS request down to this maximum value. The Allen, et. al. Standards Track [Page 21] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 local LU, as a source LU, will restrict the session limit it sends in a CNOS request to a value less than or equal to this maximum value. If set (i.e., greater than 0), this overrides the maximum session limit defined in the appcModeAdminTable. This parameter should be set to the desired value before setting the command (appcCnosCommand). This parameter applies to the INITIALIZE_SESSION_LIMIT and CHANGE_SESSION_LIMIT verbs." DEFVAL { 0 } ::= { appcCnosControl 2 } appcCnosMinCwinLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the default minimum contention winner sessions limit. This parameter should be set to the desired value before setting the command (appcCnosCommand). This parameter applies to the INITIALIZE_SESSION_LIMIT and CHANGE_SESSION_LIMIT verbs." DEFVAL { 0 } ::= { appcCnosControl 3 } appcCnosMinClosLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the default minimum contention loser sessions limit. This parameter should be set to the desired value before setting the command (appcCnosCommand). This parameter applies to the INITIALIZE_SESSION_LIMIT and CHANGE_SESSION_LIMIT verbs." Allen, et. al. Standards Track [Page 22] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 DEFVAL { 0 } ::= { appcCnosControl 4 } appcCnosDrainSelf OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies whether the local LU is draining its conversations for this mode. When a mode session limit is reset (via a CNOS RESET_SESSION_LIMIT request), the local LU could be set to process all queued conversations before deactivating all of the sessions (using the SNA Bracket Initiation Stopped or BIS protocol). This parameter should be set to the desired value before setting the command (appcCnosCommand). This parameter applies only to the RESET_SESSION_LIMIT verb." DEFVAL { no } ::= { appcCnosControl 5 } appcCnosDrainPart OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies whether the partner LU is draining its conversations for this mode. When a mode session limit is reset (via a CNOS RESET_SESSION_LIMIT request), the partner LU could be set to process all queued conversations before deactivating all of the sessions (using the SNA Bracket Initiation Stop or BIS protocol). This parameter should be set to the desired value before setting the command (appcCnosCommand). This parameter applies only to the RESET_SESSION_LIMIT verb." Allen, et. al. Standards Track [Page 23] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 DEFVAL { yes } ::= { appcCnosControl 6 } appcCnosResponsible OBJECT-TYPE SYNTAX INTEGER { source(1), target(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies which LU is responsible for selecting and deactivating sessions as a result of a change that decreases the session limit or the maximum number of contention winner sessions for the source or target LU. If no session need to be deactivated, this parameter is ignored. source - specifies that the source (local) LU is responsible. The target (partner) LU cannot negotiate this value. target - specifies that the target (partner) LU is responsible. The target LU can negotiate this value to source. This parameter should be set to the desired value before setting the command (appcCnosCommand). This parameter applies to the RESET_SESSION_LIMIT and CHANGE_SESSION_LIMIT verbs." DEFVAL { source } ::= { appcCnosControl 7 } appcCnosForce OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies whether the local LU should force the resetting of the session limit when certain error conditions occur that prevent the successful exchange of CNOS request and reply. This parameter should be set to the desired value before Allen, et. al. Standards Track [Page 24] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 setting the command (appcCnosCommand). This parameter applies only to the RESET_SESSION_LIMIT verb." DEFVAL { no } ::= { appcCnosControl 8 } appcCnosTargetLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-write STATUS current DESCRIPTION "The SNA name of the local LU to which the CNOS command is to be applied. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. This object should be set to the desired value before setting the command (appcCnosCommand). This parameter applies to all CNOS verbs." ::= { appcCnosControl 9 } appcCnosTargetParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-write STATUS current DESCRIPTION "The SNA name of the partner LU to which the CNOS command is to be applied. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. This object should be set to the desired value before setting the command (appcCnosCommand). This parameter applies to all CNOS verbs." ::= { appcCnosControl 10 } appcCnosTargetModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the mode name to which the CNOS command is to be Allen, et. al. Standards Track [Page 25] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 applied. This object should be set to the desired value before setting the command (appcCnosCommand). This parameter applies to all CNOS verbs." ::= { appcCnosControl 11 } -- ********************************************************************* -- APPC LU information -- --------------------------------------------------------------------- -- Local LU -- Partner LU -- Mode -- ********************************************************************* -- ********************************************************************* -- APPC Local LU -- -- The entries in the following tables provide information for -- independent and dependent LU 6.2. -- -- ********************************************************************* -- ********************************************************************* -- APPC Local LU Admin Table -- Objects in this table contain default or expected configuration -- values for local 6.2 LUs. -- ********************************************************************* appcLluAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcLluAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPC Local LU Admin Table." ::= { appcLu 1 } appcLluAdminEntry OBJECT-TYPE SYNTAX AppcLluAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about local APPC LUs. " Allen, et. al. Standards Track [Page 26] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 INDEX { appcLluAdminName } ::= { appcLluAdminTable 1 } AppcLluAdminEntry ::= SEQUENCE { appcLluAdminName DisplayString, appcLluAdminDepType INTEGER, appcLluAdminLocalAddress OCTET STRING, appcLluAdminSessLimit Integer32, appcLluAdminBindRspMayQ INTEGER, appcLluAdminCompression INTEGER, appcLluAdminInBoundCompLevel INTEGER, appcLluAdminOutBoundCompLevel INTEGER, appcLluAdminCompRleBeforeLZ INTEGER, appcLluAdminAlias DisplayString } appcLluAdminName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the name of the local LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcLluAdminEntry 1 } appcLluAdminDepType OBJECT-TYPE SYNTAX INTEGER { dependent(1), independent(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies whether the LU is dependent or independent." ::= { appcLluAdminEntry 2 } appcLluAdminLocalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local address for this LU is a byte with a value ranging from 0 to 254. For dependent LUs, this value ranges from 1 to Allen, et. al. Standards Track [Page 27] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 254; for independent LUs this value is always 0." ::= { appcLluAdminEntry 3 } appcLluAdminSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of sessions supported by this LU." ::= { appcLluAdminEntry 4 } appcLluAdminBindRspMayQ OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether or not the local LU, as the sender of a BIND request, allows a partner partner LU to delay sending the BIND response if the partner LU cannot process the BIND request immediately." ::= { appcLluAdminEntry 5 } appcLluAdminCompression OBJECT-TYPE SYNTAX INTEGER { prohibited(1), required(2), negotiable(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether compression is supported. The local LU uses this value for negotiation during session activation (SNA BIND). prohibited - specifies that no compression is to be used. required - specifies that compression is required. negotiable - specifies that the usage of compression is to be negotiated between the LUs. The level of compression is also negotiated." ::= { appcLluAdminEntry 6 } Allen, et. al. Standards Track [Page 28] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcLluAdminInBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for inbound data. The local LU uses this value in conjunction with appcLluAdminCompression for negotiation during session activation (SNA BIND). none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger number bits used for the code, the more storage space is required for the dictionary, but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcLluAdminEntry 7 } appcLluAdminOutBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for outbound data. The local LU uses this value in conjunction with appcLluAdminCompression for negotiation during session activation (SNA BIND). Allen, et. al. Standards Track [Page 29] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger of number bits used for the code, the more storage space is required for the dictionary, but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcLluAdminEntry 8 } appcLluAdminCompRleBeforeLZ OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether run-length encoding is to be applied to the data before applying Lempel-Ziv-like compression. The local LU uses this value for negotiation during session activation (SNA BIND). This parameter is only supported if LZ compression is used." ::= { appcLluAdminEntry 9 } appcLluAdminAlias OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A local alias for the local LU. If not known or not applicable, this object contains a zero-length string." ::= { appcLluAdminEntry 10 } -- ********************************************************************* -- APPC Local LU Oper Table Allen, et. al. Standards Track [Page 30] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 -- Objects in this table contain current operational values, such -- as state values or negotiated parameters, for local 6.2 LUs. -- ********************************************************************* appcLluOperTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcLluOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPC Local LU Operational Table." ::= { appcLu 2 } appcLluOperEntry OBJECT-TYPE SYNTAX AppcLluOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about local APPC LUs." INDEX { appcLluOperName } ::= { appcLluOperTable 1 } AppcLluOperEntry ::= SEQUENCE { appcLluOperName DisplayString, appcLluOperDepType INTEGER, appcLluOperLocalAddress OCTET STRING, appcLluOperSessLimit Integer32, appcLluOperBindRspMayQ INTEGER, appcLluOperCompression INTEGER, appcLluOperInBoundCompLevel INTEGER, appcLluOperOutBoundCompLevel INTEGER, appcLluOperCompRleBeforeLZ INTEGER, appcLluOperAlias DisplayString, appcLluOperActiveSessions Gauge32 } appcLluOperName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the name of the local LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcLluOperEntry 1 } Allen, et. al. Standards Track [Page 31] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcLluOperDepType OBJECT-TYPE SYNTAX INTEGER { dependent(1), independent(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies whether the LU is dependent or independent." ::= { appcLluOperEntry 2 } appcLluOperLocalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local address for this LU is a byte with a value ranging from 0 to 254. For dependent LUs, this value ranges from 1 to 254; for independent LUs this value is always 0." ::= { appcLluOperEntry 3 } appcLluOperSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of sessions supported by this LU." ::= { appcLluOperEntry 4 } appcLluOperBindRspMayQ OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether or not the local LU, as the sender of a BIND request, allows a partner LU to delay sending the BIND response if the partner LU cannot process the BIND request immediately." ::= { appcLluOperEntry 5 } Allen, et. al. Standards Track [Page 32] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcLluOperCompression OBJECT-TYPE SYNTAX INTEGER { prohibited(1), required(2), negotiable(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether compression is supported. The local LU uses this value for negotiation during session activation (SNA BIND). prohibited - specifies that no compression is to be used. required - specifies that compression is required. negotiable - specifies that the usage of compression is to be negotiated between the LUs. The level of compression is also negotiated." ::= { appcLluOperEntry 6 } appcLluOperInBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for inbound data. The local LU uses this value in conjunction with appcLluOperCompression for negotiation during session activation (SNA BIND). none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger of number bits used for the code, the Allen, et. al. Standards Track [Page 33] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 more storage space is required for the dictionary, but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcLluOperEntry 7 } appcLluOperOutBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for outbound data. The local LU uses this value in conjunction with appcLluAdminCompression for negotiation during session activation (SNA BIND). none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger of number bits used for the code, the more storage space is required for the dictionary, but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcLluOperEntry 8 } appcLluOperCompRleBeforeLZ OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION Allen, et. al. Standards Track [Page 34] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 "Specifies whether run-length encoding is to be applied to the data before applying Lempel-Ziv-like compression. The local LU uses this value for negotiation during session activation (SNA BIND). This parameter is only supported if LZ compression is used." ::= { appcLluOperEntry 9 } appcLluOperAlias OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A local alias for the local LU. If not known or not applicable, this object contains a zero-length string." ::= { appcLluOperEntry 10 } appcLluOperActiveSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the total number of active APPC sessions for this LU." ::= { appcLluOperEntry 11 } -- ********************************************************************* -- APPC LU Pair Admin Table -- Objects in this table contain default or expected configuration -- values for 6.2 LU pairs. An LU pair consists of a local LU and -- a partner LU, which may or may not be local. -- ********************************************************************* appcLuPairAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcLuPairAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPC Partner LU administrative Table" ::= { appcLu 3 } appcLuPairAdminEntry OBJECT-TYPE SYNTAX AppcLuPairAdminEntry MAX-ACCESS not-accessible STATUS current Allen, et. al. Standards Track [Page 35] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 DESCRIPTION "Entry of APPC Partner LU Information Table. It is indexed by the local and partner LU Names." INDEX { appcLuPairAdminLocLuName, appcLuPairAdminParLuName } ::= { appcLuPairAdminTable 1 } AppcLuPairAdminEntry ::= SEQUENCE { appcLuPairAdminLocLuName DisplayString, appcLuPairAdminParLuName DisplayString, appcLuPairAdminParLuAlias DisplayString, appcLuPairAdminSessLimit Integer32, appcLuPairAdminSessSec INTEGER, appcLuPairAdminSecAccept INTEGER, appcLuPairAdminLinkObjId InstancePointer, appcLuPairAdminParaSessSup INTEGER } appcLuPairAdminLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU to which this partner LU definition applies. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. The reserved value '*ALL' indicates that the partner LU definition applies to all local LUs, and not just to a single local LU." ::= { appcLuPairAdminEntry 1 } appcLuPairAdminParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the partner LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." Allen, et. al. Standards Track [Page 36] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcLuPairAdminEntry 2 } appcLuPairAdminParLuAlias OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A local alias for the partner LU. If not known or not applicable, this object contains a zero-length string." ::= { appcLuPairAdminEntry 3 } appcLuPairAdminSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of sessions supported by this partner LU." ::= { appcLuPairAdminEntry 4 } appcLuPairAdminSessSec OBJECT-TYPE SYNTAX INTEGER { required(1), accepted(2), notAllowed(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of session-level security information that a local LU will accept on BIND requests it receives from the partner LU. required - Specifies that the BIND request must carry session level verification information that will be verified upon receipt. accepted - Specifies that the BIND request may carry session level verification information that will be verified upon receipt. notAllowed - Specifies that the BIND request must not carry session level verification information." ::= { appcLuPairAdminEntry 5 } appcLuPairAdminSecAccept OBJECT-TYPE SYNTAX INTEGER { Allen, et. al. Standards Track [Page 37] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 none(1), conversation(2), alreadyVerified(3), persistentVerification(4), aVandpV(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies support for different levels of access security information in ATTACH requests received from this partner LU. Possible values are: none - No access security information will be accepted on allocation requests (ATTACH) from this LU. conversation - Allocation requests will not be accepted that include already verified or persistent verification indicators. Accept conversation-level access security information, which must include both a user Id and password, and may also include a profile. alreadyVerified - Allocation requests will be accepted that include already verified indicators. Persistent verification indicators will not be accepted. persistentVerification - Allocation requests will be accepted that include persistent verification indicators. Already verified indicators will not be accepted. aVandpV - Allocation requests will be accepted that include already verified or persistent verification indicators." ::= { appcLuPairAdminEntry 6 } appcLuPairAdminLinkObjId OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the link associated with this partner LU. This value points to the row in the table containing information on Allen, et. al. Standards Track [Page 38] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 the link instance. (e.g., the sdlcLSAdminTable of the SNA DLC MIB module). This object may be NULL if the link is not specified or if a link is not applicable (as for APPN-level nodes)." ::= { appcLuPairAdminEntry 7 } appcLuPairAdminParaSessSup OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Defined Parallel Sessions Supported. Indicates whether or not multiple sessions between the partner LU and its associated local LU are permitted. Parallel session support also indicates that Change Number of Sessions (CNOS) will be used to negotiate session limits between the LUs." ::= { appcLuPairAdminEntry 8 } -- ********************************************************************* -- APPC LU Pair Oper Table -- Objects in this table contain current operational values, such -- as state values or negotiated parameters, for 6.2 LU pairs. -- ********************************************************************* appcLuPairOperTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcLuPairOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of active partner/local LU pairs. Two entries are present in the table when both LUs in a pair are local." ::= { appcLu 4 } appcLuPairOperEntry OBJECT-TYPE SYNTAX AppcLuPairOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry representing one partner/local LU pair." INDEX { appcLuPairOperLocLuName, Allen, et. al. Standards Track [Page 39] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcLuPairOperParLuName } ::= { appcLuPairOperTable 1 } AppcLuPairOperEntry ::= SEQUENCE { appcLuPairOperLocLuName DisplayString, appcLuPairOperParLuName DisplayString, appcLuPairOperParLuAlias DisplayString, appcLuPairOperSessLimit Integer32, appcLuPairOperSessSec INTEGER, appcLuPairOperSecAccept INTEGER, appcLuPairOperLinkObjId InstancePointer, appcLuPairOperParaSessSup INTEGER, appcLuPairOperParaSessSupLS INTEGER, appcLuPairOperState INTEGER } appcLuPairOperLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. If this object has the same value as appcLluOperName, then the two entries being indexed apply to the same resource (specifically, to the same local LU)." ::= { appcLuPairOperEntry 1 } appcLuPairOperParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the partner LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcLuPairOperEntry 2 } appcLuPairOperParLuAlias OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current Allen, et. al. Standards Track [Page 40] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 DESCRIPTION "A local alias for the partner LU. If not known or not applicable, this object contains a zero-length string." ::= { appcLuPairOperEntry 3 } appcLuPairOperSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of sessions supported by this partner LU." ::= { appcLuPairOperEntry 4 } appcLuPairOperSessSec OBJECT-TYPE SYNTAX INTEGER { required(1), accepted(2), notAllowed(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the type of security information that a local LU will accept on BIND requests it receives from the partner LU. required - Specifies that the BIND request must carry session level verification information that will be verified upon receipt. accepted - Specifies that the BIND request may carry session level verification information that will be verified upon receipt. notAllowed - Specifies that the BIND request must not carry session level verification information." ::= { appcLuPairOperEntry 5 } appcLuPairOperSecAccept OBJECT-TYPE SYNTAX INTEGER { none(1), conversation(2), alreadyVerified(3), persistentVerification(4), aVandpV(5) } MAX-ACCESS read-only Allen, et. al. Standards Track [Page 41] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 STATUS current DESCRIPTION "Specifies support for different levels of security acceptance information in ATTACH requests received from this partner LU. Possible values are: none - No access security information will be accepted on allocation requests (ATTACH) from this LU. conversation - Allocation requests will not be accepted that include already verified or persistent verification indicators. Accept conversation-level access security information, which must include both a user Id and password, and may also include a profile. alreadyVerified - Allocation requests will be accepted that include already verified indicators. Persistent verification indicators will not be accepted. persistentVerification - Allocation requests will be accepted that include persistent verification indicators. Already verified indicators will not be accepted. aVandpV - Allocation requests will be accepted that include already verified or persistent verification indicators." ::= { appcLuPairOperEntry 6 } appcLuPairOperLinkObjId OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the link associated with this partner LU. This value points to the row in the table containing information on the link instance. (e.g., the sdlcLSAdminTable of the SNA DLC MIB module). This object may be NULL if the link is not specified or if a link is not applicable (as for APPN-level nodes)." ::= { appcLuPairOperEntry 7 } appcLuPairOperParaSessSup OBJECT-TYPE Allen, et. al. Standards Track [Page 42] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Active Parallel Sessions Supported. Indicates whether or not multiple session between the partner LU and its associated local LU are permitted. Parallel session support also indicates that Change Number of Sessions (CNOS) will be used to negotiate session limits between the LUs." ::= { appcLuPairOperEntry 8 } appcLuPairOperParaSessSupLS OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Active Parallel Sessions Supported - last starting value. This object represents the initial value proposed by the local LU the last time this capability was negotiated, i.e., when the first session was bound between the local LU and its partner." ::= { appcLuPairOperEntry 9 } appcLuPairOperState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the current operational state of this LU pair: inactive (1) - no active or pending session exists between the LUs. active (2) - an active or pending session exists Allen, et. al. Standards Track [Page 43] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 between the LUs." ::= { appcLuPairOperEntry 10 } -- ********************************************************************* -- APPC Mode Admin Table -- Objects in this table contain default or expected configuration -- values for session modes. -- Modes that have active sessions appear in the appcModeOperTable. -- ********************************************************************* appcModeAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcModeAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPC Mode Table" ::= { appcLu 5 } appcModeAdminEntry OBJECT-TYPE SYNTAX AppcModeAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of APPC Mode Information Table." INDEX { appcModeAdminLocLuName, appcModeAdminParLuName, appcModeAdminModeName } ::= { appcModeAdminTable 1 } AppcModeAdminEntry ::= SEQUENCE { appcModeAdminLocLuName DisplayString, appcModeAdminParLuName DisplayString, appcModeAdminModeName DisplayString, appcModeAdminCosName DisplayString, appcModeAdminSessEndTpName DisplayString, appcModeAdminMaxSessLimit Integer32, appcModeAdminMinCwinLimit Integer32, appcModeAdminMinClosLimit Integer32, appcModeAdminConWinAutoActLmt Integer32, appcModeAdminRecvPacWinSz Integer32, appcModeAdminSendPacWinSz Integer32, appcModeAdminPrefRecvRuSz Integer32, appcModeAdminPrefSendRuSz Integer32, appcModeAdminRecvRuSzUpBnd Integer32, appcModeAdminSendRuSzUpBnd Integer32, Allen, et. al. Standards Track [Page 44] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcModeAdminRecvRuSzLoBnd Integer32, appcModeAdminSendRuSzLoBnd Integer32, appcModeAdminSingSessReinit INTEGER, appcModeAdminCompression INTEGER, appcModeAdminInBoundCompLevel INTEGER, appcModeAdminOutBoundCompLevel INTEGER, appcModeAdminCompRleBeforeLZ INTEGER, appcModeAdminSyncLvl INTEGER, appcModeAdminCrypto INTEGER } appcModeAdminLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU to which this mode definition applies. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. The reserved value '*ALL' indicates that the mode definition applies to all local LUs for the SNA node identified by appcLocalCpName, and not just to a single local LU." ::= { appcModeAdminEntry 1 } appcModeAdminParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the partner LU to which this mode definition applies. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. The reserved value '*ALL' indicates that the mode definition applies to all partner LUs for the SNA node identified by appcModeAdminLocLuName, and not just to a single partner LU." ::= { appcModeAdminEntry 2 } appcModeAdminModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current Allen, et. al. Standards Track [Page 45] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 DESCRIPTION "Specifies the mode name. A mode defines the characteristics for a group of sessions. The mode name can be blank (8 space characters). " ::= { appcModeAdminEntry 3 } appcModeAdminCosName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the class of service (COS) name associated with this mode. If the implementation does not support COS names, a null string is returned." ::= { appcModeAdminEntry 4 } appcModeAdminSessEndTpName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the name of the transaction program (TP) to be invoked when a session using this mode is deactivated or ended. If no such TP is defined, this object is a null string. When the TP name consists entirely of displayable EBCDIC code points, it is mapped directly to the equivalent ASCII display string. However, registered TP names always have a non- displayable EBCDIC code point (value less than or equal to x'3F') as the first character, so they cannot be directly mapped to an ASCII display string. These TP names are converted to a display string that is equivalent to a hexadecimal display of the EBCDIC code points. For example, the 2-byte TP name x'06F1' (CNOS) is converted to the 6-byte ASCII display string '06F1' (including the two single quotes). " ::= { appcModeAdminEntry 5 } appcModeAdminMaxSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum value that the local LU is to use, during CNOS processing, for the session limit. The local LU, as a target LU, will negotiate a higher session limit it Allen, et. al. Standards Track [Page 46] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 receives in the CNOS request down to this maximum value. The local LU, as a source LU, will restrict the session limit it sends in a CNOS request to a value less than or equal to this maximum value." ::= { appcModeAdminEntry 6 } appcModeAdminMinCwinLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the default minimum contention winner sessions limit. Some implementations internally issue a INITIALIZE_SESSION_LIMIT verb when a Mode is created. This value is the parameter used for the CNOS processing of that verb. This parameter is not used when issuing an explicit INITIALIZE_SESSION_LIMIT verb. The equivalent object in appcCnosCommandTable is used." ::= { appcModeAdminEntry 7 } appcModeAdminMinClosLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the default minimum contention loser sessions limit. Some implementations internally issue a INITIALIZE_SESSION_LIMIT verb when a Mode is created. This value is the parameter used for the CNOS processing of that verb. This is the same as target minimum contention winner sessions. This parameter is not used when issuing an explicit INITIALIZE_SESSION_LIMIT verb. The equivalent object in appcCnosCommandTable is used." ::= { appcModeAdminEntry 8 } appcModeAdminConWinAutoActLmt OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the limit on the number of contention winner sessions to be automatically activated when the minimum number of contention winner sessions increases (as a result of CNOS processing). The actual number of sessions activated is the lesser of this value and the new minimum number of contention winner sessions. " Allen, et. al. Standards Track [Page 47] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcModeAdminEntry 9 } appcModeAdminRecvPacWinSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the size of the receive pacing window. This value is used for negotiation during session activations (SNA BIND). The meaning of this value when set to 0 depends on whether adaptive pacing is supported: adaptive pacing No limit on window size fixed pacing No pacing is supported" ::= { appcModeAdminEntry 10 } appcModeAdminSendPacWinSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the size of the send pacing window. This value is used for negotiation during session activations (SNA BIND). The meaning of this value when set to 0 depends on whether adaptive pacing is supported: adaptive pacing No limit on window size fixed pacing No pacing is supported" ::= { appcModeAdminEntry 11 } appcModeAdminPrefRecvRuSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the preferred receive RU (Request Unit) size of normal-flow requests on the sessions. This value must be less than or equal to the value specified in appcModeAdminRecvRuSzUpBnd and greater than or equal to the value specified in appcModeAdminRecvRuSzLoBnd. The local LU specifies this value for the receive maximum RU size in session activation (SNA BIND) requests and responses. It will allow negotiation up to the appcModeAdminRecvRuSzUpBnd value or down to the appcModeAdminRecvRuSzLoBnd value." Allen, et. al. Standards Track [Page 48] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcModeAdminEntry 12 } appcModeAdminPrefSendRuSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the preferred send RU (Request Unit) size of normal- flow requests on the sessions. This value must be less than or equal to the value specified in appcModeAdminSendRuSzUpBnd and greater than or equal to the value specified in appcModeAdminSendRuSzLoBnd. The local LU specifies this value for the send maximum RU size in session activation (SNA BIND) requests and responses. It will allow negotiation up to the appcModeAdminSendRuSzUpBnd value or down to the appcModeAdminSendRuSzLoBnd value." ::= { appcModeAdminEntry 13 } appcModeAdminRecvRuSzUpBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the upper bound for the maximum receive RU (Request Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeAdminEntry 14 } appcModeAdminSendRuSzUpBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the upper bound for the maximum send RU (Request Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeAdminEntry 15 } appcModeAdminRecvRuSzLoBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the lower bound for the maximum receive RU (Request Allen, et. al. Standards Track [Page 49] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeAdminEntry 16 } appcModeAdminSendRuSzLoBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the lower bound for the maximum send RU (Request Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeAdminEntry 17 } appcModeAdminSingSessReinit OBJECT-TYPE SYNTAX INTEGER { notApplicable(1), operatorControlled(2), primaryOnly(3), secondaryOnly(4), primaryOrSecondary(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the responsibility for session reinitiation of a single session with the partner LU (when the session goes down). The local LU uses this parameter to specify the session reinitiation responsibility in session activation (SNA BIND) requests and responses. notApplicable - specifies that this parameter has no meaning since the value of appcLuPairAdminParaSessSup is yes. The field in the SNA BIND is reserved (set to zero). operatorControlled - specifies that neither LU will automatically attempt to reinitiate the session. The operator on either side will manually reactivate the session. A contention race (both side reinitiating at the same time) is won by the LU with the lexicographically greater fully- qualified LU name. primaryOnly - specifies that the primary LU will Allen, et. al. Standards Track [Page 50] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 automatically attempt to reinitiate the session. secondaryOnly - specifies that the secondary LU will automatically attempt to reinitiate the session. primaryOrSecondary - specifies that either the primary or the secondary may automatically attempt to reinitiate the session. A contention race is handled the same way as with operatorControlled. " ::= { appcModeAdminEntry 18 } appcModeAdminCompression OBJECT-TYPE SYNTAX INTEGER { prohibited(1), required(2), negotiable(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether compression is supported. The local LU uses this value for negotiation during session activation (SNA BIND). prohibited - specifies that no compression is to be used. required - specifies that compression is required. negotiable - specifies that the usage of compression is to be negotiated between the LUs. The level of compression is also negotiated." ::= { appcModeAdminEntry 19 } appcModeAdminInBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for inbound data. The local LU uses this value in conjunction with appcModeAdminCompression for negotiation during session Allen, et. al. Standards Track [Page 51] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 activation (SNA BIND). none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger of number bits used for the code, the more storage space is required for the dictionary, but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcModeAdminEntry 20 } appcModeAdminOutBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for outbound data. The local LU uses this value in conjunction with appcModeAdminCompression for negotiation during session activation (SNA BIND). none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger of number bits used for the code, the more storage space is required for the dictionary, Allen, et. al. Standards Track [Page 52] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcModeAdminEntry 21 } appcModeAdminCompRleBeforeLZ OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether run-length encoding is to be applied to the data before applying Lempel-Ziv-like compression. The local LU uses this value for negotiation during session activation (SNA BIND). This parameter is only supported if LZ compression is used." ::= { appcModeAdminEntry 22 } appcModeAdminSyncLvl OBJECT-TYPE SYNTAX INTEGER { none(1), noneConfirm(2), noneConfirmSyncPoint(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the sync level support. This value is used for negotiation during session activations (SNA BIND). none - No sync level is supported. noneConfirm - None and Confirm levels supported. noneConfirmSyncPoint - None, Confirm, and Sync Point is supported. " ::= { appcModeAdminEntry 23 } appcModeAdminCrypto OBJECT-TYPE SYNTAX INTEGER { notSupported(1), mandatory(2), selective(3) } Allen, et. al. Standards Track [Page 53] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether session-level cryptography is supported. This value is used for negotiation during session activations (SNA BIND). notSupported - Specifies session-level cryptography is not to be used. mandatory - Specifies session-level cryptography must be used. selective - Specifies session-level cryptography is required just on selected requests flowing on the sessions." ::= { appcModeAdminEntry 24 } -- ********************************************************************* -- APPC Mode Oper Table -- Objects in this table contain current operational values, such -- as state values or negotiated parameters, for session modes. -- -- ********************************************************************* appcModeOperTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcModeOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Operational APPC Mode Information. Two entries are present in the table when both LUs in a pair are local." ::= { appcLu 6 } appcModeOperEntry OBJECT-TYPE SYNTAX AppcModeOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of APPC mode operational information table. This entry does not augment the appcModeAdminEntry, but reflects an actual operational mode for a given local LU - partner LU pair." INDEX { appcModeOperLocLuName, appcModeOperParLuName, appcModeOperModeName } ::= { appcModeOperTable 1 } Allen, et. al. Standards Track [Page 54] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 AppcModeOperEntry ::= SEQUENCE { appcModeOperLocLuName DisplayString, appcModeOperParLuName DisplayString, appcModeOperModeName DisplayString, appcModeOperCosName DisplayString, appcModeOperSessEndTpName DisplayString, appcModeOperSessLimit Integer32, appcModeOperMaxSessLimit Integer32, appcModeOperMinCwinLimit Integer32, appcModeOperMinClosLimit Integer32, appcModeOperConWinAutoActLmt Integer32, appcModeOperRecvPacWinSz Integer32, appcModeOperSendPacWinSz Integer32, appcModeOperPrefRecvRuSz Integer32, appcModeOperPrefSendRuSz Integer32, appcModeOperRecvRuSzUpBnd Integer32, appcModeOperSendRuSzUpBnd Integer32, appcModeOperRecvRuSzLoBnd Integer32, appcModeOperSendRuSzLoBnd Integer32, appcModeOperSingSessReinit INTEGER, appcModeOperCompression INTEGER, appcModeOperInBoundCompLevel INTEGER, appcModeOperOutBoundCompLevel INTEGER, appcModeOperCompRleBeforeLZ INTEGER, appcModeOperSyncLvl INTEGER, appcModeOperCrypto INTEGER, appcModeOperSyncLvlLastStart INTEGER, appcModeOperCryptoLastStart INTEGER, appcModeOperCNOSNeg INTEGER, appcModeOperActCwin Gauge32, appcModeOperActClos Gauge32, appcModeOperPndCwin Gauge32, appcModeOperPndClos Gauge32, appcModeOperPtmCwin Gauge32, appcModeOperPtmClos Gauge32, appcModeOperDrainSelf INTEGER, appcModeOperDrainPart INTEGER } appcModeOperLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. Allen, et. al. Standards Track [Page 55] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 If this object has the same value as appcLluOperName, then the two entries being indexed apply to the same resource (specifically, to the same local LU)." ::= { appcModeOperEntry 1 } appcModeOperParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the partner LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. If this object has the same value as appcLuPairOperParLuName, then the two entries being indexed apply to the same resource (specifically, to the same partner LU)." ::= { appcModeOperEntry 2 } appcModeOperModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the mode name. A mode defines the characteristics for a group of sessions. The mode name can be blank (8 space characters). " ::= { appcModeOperEntry 3 } appcModeOperCosName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the class of service (COS) name associated with this mode. If the implementation does not support COS names, a zero-length string is returned." ::= { appcModeOperEntry 4 } appcModeOperSessEndTpName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-only STATUS current DESCRIPTION Allen, et. al. Standards Track [Page 56] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 "Specifies the name of the transaction program (TP) to be invoked when a session using this mode is deactivated or ended. If the name is NULL, no transaction program is invoked. When the TP name consists entirely of displayable EBCDIC code points, it is mapped directly to the equivalent ASCII display string. However, registered TP names always have a non- displayable EBCDIC code point (value less than or equal to x'3F') as the first character, so they cannot be directly mapped to an ASCII display string. These TP names are converted to a display string that is equivalent to a hexadecimal display of the EBCDIC code points. For example, the 2-byte TP name x'06F1' (CNOS) is converted to the 6-byte ASCII display string '06F1' (including the two single quotes)." ::= { appcModeOperEntry 5 } appcModeOperSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the current session limit of this mode as negotiated through APPC CNOS (Change Number of Sessions) processing. Identifies the total number of sessions that can be established between the local and partner LU using this mode." ::= { appcModeOperEntry 6 } appcModeOperMaxSessLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum value that the local LU is to use, during CNOS processing, for the session limit. The local LU, as a target LU, will negotiate a higher session limit it receives in the CNOS request down to this maximum value. The local LU, as a source LU, will restrict the session limit it sends in a CNOS request to a value less than or equal to this maximum value." ::= { appcModeOperEntry 7 } appcModeOperMinCwinLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION Allen, et. al. Standards Track [Page 57] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 "Specifies the minimum contention winner sessions limit that was negotiated via CNOS processing." ::= { appcModeOperEntry 8 } appcModeOperMinClosLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the minimum contention loser sessions limit that was negotiated via CNOS processing. This is the same as target minimum contention winner sessions." ::= { appcModeOperEntry 9 } appcModeOperConWinAutoActLmt OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the limit on the number of contention winner sessions to be automatically activated when the minimum number of contention winner sessions increases (as a result of CNOS processing). The actual number of sessions activated is the lesser of this value and the new minimum number of contention winner sessions. " ::= { appcModeOperEntry 10 } appcModeOperRecvPacWinSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the size of the receive pacing window. This value is used for negotiation during session activations (SNA BIND). The meaning of this value when set to 0 depends on whether adaptive pacing is supported: adaptive pacing - No limit on window size fixed pacing - No pacing is supported" ::= { appcModeOperEntry 11 } appcModeOperSendPacWinSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only Allen, et. al. Standards Track [Page 58] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 STATUS current DESCRIPTION "Specifies the size of the send pacing window. This value is used for negotiation during session activations (SNA BIND). The meaning of this value when set to 0 depends on whether adaptive pacing is supported: adaptive pacing No limit on window size fixed pacing No pacing is supported" ::= { appcModeOperEntry 12 } appcModeOperPrefRecvRuSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the preferred receive RU (Request Unit) size of normal-flow requests on the sessions. This value must be less than or equal to the value specified in appcModeOperRecvRuSzUpBnd and greater than or equal to the value specified in appcModeOperRecvRuSzLoBnd. The local LU specifies this value for the receive maximum RU size in session activation (SNA BIND) requests and responses. It will allow negotiation up to the appcModeOperRecvRuSzUpBnd value or down to the appcModeOperRecvRuSzLoBnd value." ::= { appcModeOperEntry 13 } appcModeOperPrefSendRuSz OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the preferred send RU (Request Unit) size of normal- flow requests on the sessions. This value must be less than or equal to the value specified in appcModeOperSendRuSzUpBnd and greater than or equal to the value specified in appcModeOperSendRuSzLoBnd. The local LU specifies this value for the send maximum RU size in session activation (SNA BIND) requests and responses. It will allow negotiation up to the appcModeOperSendRuSzUpBnd value or down to the appcModeOperSendRuSzLoBnd value." ::= { appcModeOperEntry 14 } Allen, et. al. Standards Track [Page 59] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcModeOperRecvRuSzUpBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the upper bound for the maximum receive RU (Request Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeOperEntry 15 } appcModeOperSendRuSzUpBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the upper bound for the maximum send RU (Request Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeOperEntry 16 } appcModeOperRecvRuSzLoBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the lower bound for the maximum receive RU (Request Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeOperEntry 17 } appcModeOperSendRuSzLoBnd OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the lower bound for the maximum send RU (Request Unit) size of normal-flow requests. This is used for negotiation during session activations (SNA BIND). " ::= { appcModeOperEntry 18 } appcModeOperSingSessReinit OBJECT-TYPE SYNTAX INTEGER { notApplicable(1), operatorControlled(2), Allen, et. al. Standards Track [Page 60] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 primaryOnly(3), secondaryOnly(4), primaryOrSecondary(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the responsibility for session reinitiation of a single session with the partner LU (when the session goes down). The local LU uses this parameter to specify the session reinitiation responsibility in session activation (SNA BIND) requests and responses. notApplicable - specifies that this parameter has no meaning since the value of appcLuPairOperParaSessSup is yes. The field in the SNA BIND is reserved (set to zero). operatorControlled - specifies that neither LU will automatically attempt to reinitiate the session. The operator on either side will manually reactivate the session. A contention race (both side reinitiating at the same time) is won by the LU with the lexicographically greater fully- qualified LU name. primaryOnly - specifies that the primary LU will automatically attempt to reinitiate the session. secondaryOnly - specifies that the secondary LU will automatically attempt to reinitiate the session. primaryOrSecondary - specifies that either the primary or the secondary may automatically attempt to reinitiate the session. A contention race is handled the same way as with operatorControlled. " ::= { appcModeOperEntry 19 } appcModeOperCompression OBJECT-TYPE SYNTAX INTEGER { prohibited(1), required(2), negotiable(3) } MAX-ACCESS read-only Allen, et. al. Standards Track [Page 61] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 STATUS current DESCRIPTION "Specifies whether compression is supported. The local LU uses this value for negotiation during session activation (SNA BIND). prohibited - specifies that no compression is to be used. required - specifies that compression is required. negotiable - specifies that the usage of compression is to be negotiated between the LUs. The level of compression is also negotiated." ::= { appcModeOperEntry 20 } appcModeOperInBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for inbound data. The local LU uses this value in conjunction with appcModeOperCompression for negotiation during session activation (SNA BIND). none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger of number bits used for the code, the more storage space is required for the dictionary, but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcModeOperEntry 21 } Allen, et. al. Standards Track [Page 62] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcModeOperOutBoundCompLevel OBJECT-TYPE SYNTAX INTEGER { none(1), rle(2), lz9(3), lz10(4), lz12(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum level of compression supported for outbound data. The local LU uses this value in conjunction with appcModeOperCompression for negotiation during session activation (SNA BIND). none - specifies that no compression is to be used. rle - specifies run-length encoding compression in which a 1 or 2 byte sequence substitution is used for each repeated run of the same character. lz9 - specifies Lempel-Ziv-like compression in which 9 bit codes are used to substitute repeated substrings in the data stream. These codes are indices that refer to entries in a common dictionary generated adaptively at both sender and receiver as the data flows and compression occurs. The larger of number bits used for the code, the more storage space is required for the dictionary, but the larger the compression ratio. lz10 - specifies a 10 bit code Lempel-Ziv-like compression. lz12 - specifies a 12 bit code Lempel-Ziv-like compression." ::= { appcModeOperEntry 22 } appcModeOperCompRleBeforeLZ OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether run-length encoding is to be applied to the data before applying Lempel-Ziv-like compression. The local LU uses this value for negotiation during session activation (SNA BIND). This parameter is only supported if LZ compression is used." Allen, et. al. Standards Track [Page 63] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcModeOperEntry 23 } appcModeOperSyncLvl OBJECT-TYPE SYNTAX INTEGER { none(1), noneConfirm(2), noneConfirmSyncPoint(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the sync level support for sessions involving this LU pair and mode name. none - No sync level is supported. noneConfirm - None and Confirm level supported. noneConfirmSyncPoint - None, Confirm and Sync Point is supported. " ::= { appcModeOperEntry 24 } appcModeOperCrypto OBJECT-TYPE SYNTAX INTEGER { notSupported(1), mandatory(2), selective(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether session-level cryptography is supported for sessions involving this LU pair and mode name. notSupported - Specifies session-level cryptography is not being used. mandatory - Specifies session-level cryptography in being used on all requests flowing on the sessions. selective - Specifies session-level cryptography is required just on selected requests flowing on the sessions." ::= { appcModeOperEntry 25 } appcModeOperSyncLvlLastStart OBJECT-TYPE SYNTAX INTEGER { none(1), Allen, et. al. Standards Track [Page 64] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 noneConfirm(2), noneConfirmSyncPoint(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the sync level support. This value represents the initial value proposed by the local LU the last time this capability was negotiated, i.e., when the first session was bound between the local LU and its partner. none - No sync level is supported. noneConfirm - None and Confirm level supported. noneConfirmSyncPoint - None, Confirm and Sync Point is supported. " ::= { appcModeOperEntry 26 } appcModeOperCryptoLastStart OBJECT-TYPE SYNTAX INTEGER { notSupported(1), mandatory(2), selective(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether session-level cryptography is supported. This value represents the initial value proposed by the local LU the last time this capability was negotiated, i.e., when the first session was bound between the local LU and its partner. notSupported - Specifies session-level cryptography is not to be used. mandatory - Specifies session-level cryptography must be used. selective - Specifies session-level cryptography is required just on selected requests flowing on the sessions." ::= { appcModeOperEntry 27 } appcModeOperCNOSNeg OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } Allen, et. al. Standards Track [Page 65] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether CNOS negotiation is in process. CNOS negotiation is used to set or change the various session limits for a mode." ::= { appcModeOperEntry 28 } appcModeOperActCwin OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of active contention winner sessions." ::= { appcModeOperEntry 29 } appcModeOperActClos OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of active contention loser sessions." ::= { appcModeOperEntry 30 } appcModeOperPndCwin OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of contention winner sessions that are pending activation." ::= { appcModeOperEntry 31 } appcModeOperPndClos OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of contention loser sessions that are pending activation." ::= { appcModeOperEntry 32 } appcModeOperPtmCwin OBJECT-TYPE Allen, et. al. Standards Track [Page 66] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of contention winner sessions that are pending termination." ::= { appcModeOperEntry 33 } appcModeOperPtmClos OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of contention loser sessions that are pending termination." ::= { appcModeOperEntry 34 } appcModeOperDrainSelf OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether the local LU is draining its conversations for this mode. When a mode session limit is reset (via a CNOS RESET_SESSION_LIMIT request), the local LU could be set to process all queued conversations before deactivating all of the sessions (using the SNA Bracket Initiation Stopped or BIS protocol). " ::= { appcModeOperEntry 35 } appcModeOperDrainPart OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether the partner LU is draining its conversations for this mode. When a mode session limit is reset (via a CNOS RESET_SESSION_LIMIT request), the partner LU could be set to process all queued conversations before deactivating all of the Allen, et. al. Standards Track [Page 67] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 sessions (using the SNA Bracket Initiation Stop or BIS protocol). " ::= { appcModeOperEntry 36 } -- ********************************************************************* -- APPC TP Admin Table -- Objects in this table contain default or expected configuration -- values for remotely attachable transaction programs. -- ********************************************************************* appcTpAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcTpAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPC Local TP Table" ::= { appcTp 1 } appcTpAdminEntry OBJECT-TYPE SYNTAX AppcTpAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of APPC Local TP Information Table." INDEX { appcTpAdminLocLuName, appcTpAdminTpName } ::= { appcTpAdminTable 1 } AppcTpAdminEntry ::= SEQUENCE { appcTpAdminLocLuName DisplayString, appcTpAdminTpName DisplayString, appcTpAdminFileSpec DisplayString, appcTpAdminStartParm DisplayString, appcTpAdminTpOperation INTEGER, appcTpAdminInAttachTimeout Integer32, appcTpAdminRcvAllocTimeout Integer32, appcTpAdminSyncLvl INTEGER, appcTpAdminInstLmt Integer32, appcTpAdminStatus INTEGER, appcTpAdminLongRun INTEGER, appcTpAdminConvType INTEGER, appcTpAdminConvDuplex INTEGER, appcTpAdminConvSecReq INTEGER, appcTpAdminVerPip INTEGER, appcTpAdminPipSubNum Integer32 Allen, et. al. Standards Track [Page 68] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 } appcTpAdminLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU to which this TP definition applies. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. The reserved value '*ALL' indicates that the TP definition applies to all local LUs, and not just to a single local LU." ::= { appcTpAdminEntry 1 } appcTpAdminTpName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local transaction program name. This name is sent on an ATTACH remote allocation request. When the TP name consists entirely of displayable EBCDIC code points, it is mapped directly to the equivalent ASCII display string. However, registered TP names always have a non-displayable EBCDIC code point (value less than or equal to x'3F') as the first character, so they cannot be directly mapped to an ASCII display string. These TP names are converted to a display string that is equivalent to a hexadecimal display of the EBCDIC code points. For example, the 2-byte TP name x'06F1' (CNOS) is converted to the 6-byte ASCII display string '06F1' (including the two single quotes)." ::= { appcTpAdminEntry 2 } appcTpAdminFileSpec OBJECT-TYPE SYNTAX DisplayString (SIZE (0..80)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local file specification of the transaction program. May be a zero-length string if not applicable." ::= { appcTpAdminEntry 3 } Allen, et. al. Standards Track [Page 69] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcTpAdminStartParm OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "A parameter string passed to the transaction program when it is started. May be a zero-length string if not supported. " ::= { appcTpAdminEntry 4 } appcTpAdminTpOperation OBJECT-TYPE SYNTAX INTEGER { other(1), queuedOperatorStarted(2), queuedOperatorPreloaded(3), queuedAmStarted(4), nonqueuedAmStarted(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies how the program will be started. other - Specifies that the program operation is none of the methods specified. It may be a product-specific method. queuedOperatorStarted - Specifies that one version of the program will be run at a time. If an incoming attach arrives and the program has not been started yet, APPC will issue a message to the operator to start the specified program. Subsequent attaches that arrive while the program is active will be queued. queuedOperatorPreloaded - Specifies that one version of the program will be run at a time. If an incoming attach arrives and the program has not been started yet, the Attach will be rejected. The APPC attach manager determines that a TP has started upon reception of an APPC RECEIVE_ALLOCATE verb, or a CPI-C Accept_Conversation (CMACCP) or Specify_Local_TP_Name (CMSLTP) call. No message is sent to the operator. Subsequent attaches that arrive while the program is active are queued. queuedAmStarted - Specifies that one version of the program will be run at a time and will be started by the APPC attach manager. Subsequent attaches Allen, et. al. Standards Track [Page 70] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 that arrive while the program is active will be queued. nonqueuedAmStarted - Specifies that multiple copies of the program will be run at a time and will be started by the APPC attach manager." ::= { appcTpAdminEntry 5 } appcTpAdminInAttachTimeout OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the number of seconds incoming attaches will be queued waiting for an APPC program to issue a RECEIVE_ALLOCATE verb or for a CPI-C program to issue an Accept_Conversation (CMACCP) call. This parameter is meaningful only when appcTpAdminTpOperation has one of the following values: queuedOperatorStarted queuedOperatorPreloaded queuedAmStarted A value of zero indicates that there is no timeout." ::= { appcTpAdminEntry 6 } appcTpAdminRcvAllocTimeout OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the number of seconds an APPC program's RECEIVE_ALLOCATE verb or a CPI-C program's Accept_Conversation (CMACCP) call will wait for an incoming attach to arrive. A value of zero indicates that there is no timeout." ::= { appcTpAdminEntry 7 } appcTpAdminSyncLvl OBJECT-TYPE SYNTAX INTEGER { none(1), confirm(2), noneAndConfirm(3), syncpoint(4), noneAndSyncpoint(5), Allen, et. al. Standards Track [Page 71] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 confirmAndSyncpoint(6), all(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the synchronization level or levels that the transaction program supports. The levels are defined as follows: none - allocation requests indicating a synchronization level of none are allowed to start the program. confirm - allocation requests indicating a synchronization level of confirm are allowed to start the program. syncpoint - allocation requests indicating a synchronization level of sync point are allowed to start the program." ::= { appcTpAdminEntry 8 } appcTpAdminInstLmt OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of concurrent instances of this transaction program that will be supported for a local LU. A value of zero indicates that there is no limit." ::= { appcTpAdminEntry 9 } appcTpAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), tempDisabled(2), permDisabled(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the status of the TP relative to starting execution when the local LU receives an allocation (ATTACH) request naming this program. enabled - the local LU can start the program. tempDisabled - the local LU cannot start the Allen, et. al. Standards Track [Page 72] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 program. The local LU rejects the request with an indication that the TP is not available but retry is possible. permDisabled - the local LU cannot start the program. The local LU rejects the request with an indication that the TP is not available and retry is not possible." ::= { appcTpAdminEntry 10 } appcTpAdminLongRun OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this is a long-running transaction program (i.e., one that stays around even after the conversation goes away)." ::= { appcTpAdminEntry 11 } appcTpAdminConvType OBJECT-TYPE SYNTAX INTEGER { basic(1), mapped(2), basicOrMapped(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the conversation type (basic or mapped) that will be used by the TP. This value is verified upon receipt of an incoming attach. The acceptable values are: basic - Indicates that this transaction program supports basic conversations. mapped - Indicates that this transaction program supports mapped conversations. basicOrMapped - Indicates that this transaction program supports both basic and mapped conversations." Allen, et. al. Standards Track [Page 73] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcTpAdminEntry 12 } appcTpAdminConvDuplex OBJECT-TYPE SYNTAX INTEGER { half(1), full(2), halfOrFull(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the conversation duplex type (half or full) that will be used by the TP. This value is verified upon receipt of an incoming attach. The acceptable values are: half - Indicates that this transaction program supports half duplex conversations. full - Indicates that this transaction program supports full duplex conversations. halfOrFull - Indicates that this transaction program supports either half or full duplex conversations." ::= { appcTpAdminEntry 13 } appcTpAdminConvSecReq OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether conversation-level security information is required on incoming attaches designating this TP name. Conversation-level security verification is always performed on those requests that include security information. yes - Indicates that conversation-level security information is required. ATTACHs designating the transaction program must carry a user_id and either a password or an already verified indicator. no - Indicates that no security information is required. ATTACHs designating the transaction Allen, et. al. Standards Track [Page 74] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 program can omit or include security information." ::= { appcTpAdminEntry 14 } appcTpAdminVerPip OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether the number of PIP (Program Initialization Parameters) subfields should be verified against the number expected (appcTpAdminPipSubNum)." ::= { appcTpAdminEntry 15 } appcTpAdminPipSubNum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of PIP subfields expected by the TP." ::= { appcTpAdminEntry 16 } -- ********************************************************************* -- APPC Active Session Table -- --------------------------------------------------------------------- -- This table contains information about active APPC sessions. -- ********************************************************************* appcActSessTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcActSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of active APPC sessions. Two entries are present in the table when both session partners are local." ::= { appcSession 1 } appcActSessEntry OBJECT-TYPE SYNTAX AppcActSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Allen, et. al. Standards Track [Page 75] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 "Entry of APPC Session Information Table. Indexed by LU pair and integer-valued session index." INDEX { appcActSessLocLuName, appcActSessParLuName, appcActSessIndex } ::= { appcActSessTable 1 } AppcActSessEntry ::= SEQUENCE { appcActSessLocLuName DisplayString, appcActSessParLuName DisplayString, appcActSessIndex Integer32, appcActSessPcidCpName DisplayString, appcActSessPcid OCTET STRING, appcActSessPluIndicator INTEGER, appcActSessModeName DisplayString, appcActSessCosName DisplayString, appcActSessTransPriority INTEGER, appcActSessEnhanceSecSup INTEGER, appcActSessSendPacingType INTEGER, appcActSessSendRpc Gauge32, appcActSessSendNxWndwSize Gauge32, appcActSessRecvPacingType INTEGER, appcActSessRecvRpc Gauge32, appcActSessRecvNxWndwSize Gauge32, appcActSessRscv OCTET STRING, appcActSessInUse INTEGER, appcActSessMaxSndRuSize INTEGER, appcActSessMaxRcvRuSize INTEGER, appcActSessSndPacingSize INTEGER, appcActSessRcvPacingSize INTEGER, appcActSessOperState INTEGER, appcActSessUpTime TimeTicks, appcActSessRtpNceId OCTET STRING, appcActSessRtpTcid OCTET STRING, appcActSessLinkIndex InstancePointer } appcActSessLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the name of the local LU for the session. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is Allen, et. al. Standards Track [Page 76] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 present. If this object has the same value as appcLluOperName, then the two entries being indexed apply to the same resource (specifically, to the same local LU)." ::= { appcActSessEntry 1 } appcActSessParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the name of the partner LU for the session. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. If this object has the same value as appcLuPairOperParLuName, then the two entries being indexed apply to the same resource (specifically, to the same partner LU)." ::= { appcActSessEntry 2 } appcActSessIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value identifies the index of the session, which is unique for this LU pair. It is recommended that an Agent not reuse the index of a deactivated session for a significant period of time (e.g., one week)." ::= { appcActSessEntry 3 } appcActSessPcidCpName OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-qualified CP name of the node at which the session and PCID originated. For APPN and LEN nodes, this is either CP name of the APPN node at which the origin LU is located or the CP name of the NN serving the LEN node at which the origin LU is located. This field is from 3 to 17 characters in length, including a period (.) which separates the NetId from the NAU name. A null string indicates that the value is unknown." Allen, et. al. Standards Track [Page 77] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcActSessEntry 4 } appcActSessPcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0|8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The procedure correlation identifier (PCID) of a session. It is an 8-octet value assigned by the control point providing session services for the primary LU. A null string indicates that the value is unknown." ::= { appcActSessEntry 5 } appcActSessPluIndicator OBJECT-TYPE SYNTAX INTEGER { localLuIsPlu(1), partnerLuIsPlu(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates which LU is the PLU for this session. For independent LUs, the PLU (primary LU) is the one that initiated the session (sent BIND), while the SLU (secondary LU) is the one that accepted the session initiation (received BIND). The 'local' LU is the one identified by appcLluOperName. The 'partner' LU is the one identified by appcLuPairOperParLuName." ::= { appcActSessEntry 6 } appcActSessModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The mode name used for this session." ::= { appcActSessEntry 7 } appcActSessCosName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION Allen, et. al. Standards Track [Page 78] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 "The Class of Service (COS) name used for this session. A null string indicates that the value is unknown." ::= { appcActSessEntry 8 } appcActSessTransPriority OBJECT-TYPE SYNTAX INTEGER { unknown(1), low(2), medium(3), high(4), network(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The transmission priority of this session. 1 = unknown priority 2 = low priority 3 = medium priority 4 = high priority 5 = network priority " ::= { appcActSessEntry 9 } appcActSessEnhanceSecSup OBJECT-TYPE SYNTAX INTEGER { none(1), level1(2), level2(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Enhanced security supported. Indicates the level of enhanced security support: 1 = none 2 = level 1 3 = level 2 " ::= { appcActSessEntry 10 } appcActSessSendPacingType OBJECT-TYPE SYNTAX INTEGER { none(1), Allen, et. al. Standards Track [Page 79] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 fixed(2), adaptive(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of pacing being used for sending data." ::= { appcActSessEntry 11 } appcActSessSendRpc OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The send residual pace count. This represents the number of MUs that can still be sent in the current session window." ::= { appcActSessEntry 12 } appcActSessSendNxWndwSize OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the next window which will be used to send data." ::= { appcActSessEntry 13 } appcActSessRecvPacingType OBJECT-TYPE SYNTAX INTEGER { none(1), fixed(2), adaptive(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of pacing being used for receiving data." ::= { appcActSessEntry 14 } appcActSessRecvRpc OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The receive residual pace count. This represents the number Allen, et. al. Standards Track [Page 80] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 of MUs that can still be received in the current session window." ::= { appcActSessEntry 15 } appcActSessRecvNxWndwSize OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the next window which will be used to receive data." ::= { appcActSessEntry 16 } appcActSessRscv OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The route selection control vector (RSCV CV2B) used for this session. It is present for APPN-level implementations. LEN-level implementations will return a null string. The internal format of this vector is described in SNA Formats. This object contains an uninterpreted copy of the control vector (including the length and key fields)." ::= { appcActSessEntry 17 } appcActSessInUse OBJECT-TYPE SYNTAX INTEGER { no(1), yes(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether the session is currently in use (i.e., in bracket with a conversation)." ::= { appcActSessEntry 18 } appcActSessMaxSndRuSize OBJECT-TYPE SYNTAX INTEGER (1..8192) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum RU size used on this session for sending RUs." Allen, et. al. Standards Track [Page 81] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcActSessEntry 19 } appcActSessMaxRcvRuSize OBJECT-TYPE SYNTAX INTEGER (1..8192) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum RU size used on this session for receiving RUs." ::= { appcActSessEntry 20 } appcActSessSndPacingSize OBJECT-TYPE SYNTAX INTEGER (1..63) MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the send pacing window on this session." ::= { appcActSessEntry 21 } appcActSessRcvPacingSize OBJECT-TYPE SYNTAX INTEGER (1..63) MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the receive pacing window on this session." ::= { appcActSessEntry 22 } appcActSessOperState OBJECT-TYPE SYNTAX INTEGER { unbound (1), pendingBind (2), bound (3), pendingUnbind (4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value indicates the current operational state of the session. 'unbound (1)' - session has been unbound; in this state it will be removed from the session table by the Agent. 'pendingBind (2)' - this state has different meanings for dependent and independent LUs; Allen, et. al. Standards Track [Page 82] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 for dependent LU - waiting for BIND from the host, for independent LU - waiting for BIND response. When a session enters this state, the corresponding entry in the session table is created by the Agent. 'bound (3)' - session has been successfully bound. 'pendingUnbind (4)' - session enters this state when an UNBIND is sent and before the rsp(UNBIND) is received. Session deactivation: If a session is in the operational state 'bound (3)' then setting the value of this object to 'unbound (1)' will initiate the session shutdown. If a session is in the operational state 'pendingBind (2)' then setting the value of this object to 'unbound (1)' will initiate the session shutdown. If a session is in the operational state 'pendingUnbind (4)' for an abnormally long period of time (e.g., three minutes) then setting the value of this object to 'unbound (1)' will change the session operational state to 'unbound (1)'. " ::= { appcActSessEntry 23 } appcActSessUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time the session has been active, measured in hundredths of a second." ::= { appcActSessEntry 24 } appcActSessRtpNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local HPR Network Connection Endpoint of the session." Allen, et. al. Standards Track [Page 83] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcActSessEntry 25 } appcActSessRtpTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0|8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local RTP connection TCID of the session." ::= { appcActSessEntry 26 } appcActSessLinkIndex OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the link over which the session passes. This value points to the row in the table containing information on the link instance. (e.g., the sdlcLSAdminTable of the SNA DLC MIB module). This object may be NULL if the link is not specified or if a link is not applicable (as for APPN-level nodes)." ::= { appcActSessEntry 27 } -- *************************************************************** -- The following table contains session statistics for APPC sessions. -- *************************************************************** appcSessStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcSessStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains dynamic statistical information relating to active APPC sessions. The entries in this table cannot be created by a Management Station. Two entries are present in the table when both session partners are local. This table is populated only when the value of appcCntrlOperStat is 'active'." ::= { appcSession 2 } appcSessStatsEntry OBJECT-TYPE SYNTAX AppcSessStatsEntry MAX-ACCESS not-accessible STATUS current Allen, et. al. Standards Track [Page 84] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 DESCRIPTION "Contains statistics information for an APPC session. Each entry is created by the Agent. Objects in this table have read-only access. Each session from appcActSessTable has one entry in this table." INDEX { appcSessStatsLocLuName, appcSessStatsParLuName, appcSessStatsSessIndex } ::= { appcSessStatsTable 1 } AppcSessStatsEntry ::= SEQUENCE { appcSessStatsLocLuName DisplayString, appcSessStatsParLuName DisplayString, appcSessStatsSessIndex Integer32, appcSessStatsSentFmdBytes Counter32, appcSessStatsSentNonFmdBytes Counter32, appcSessStatsRcvdFmdBytes Counter32, appcSessStatsRcvdNonFmdBytes Counter32, appcSessStatsSentFmdRus Counter32, appcSessStatsSentNonFmdRus Counter32, appcSessStatsRcvdFmdRus Counter32, appcSessStatsRcvdNonFmdRus Counter32, appcSessStatsCtrUpTime TimeTicks } appcSessStatsLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the name of the local LU for the session. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. If this object has the same value as appcLluOperName, then the two entries being indexed apply to the same resource (specifically, to the same local LU)." ::= { appcSessStatsEntry 1 } appcSessStatsParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Allen, et. al. Standards Track [Page 85] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 "Specifies the name of the partner LU for the session. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. If this object has the same value as appcLuPairOperParLuName, then the two entries being indexed apply to the same resource (specifically, to the same partner LU)." ::= { appcSessStatsEntry 2 } appcSessStatsSessIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value identifies the index of the session, which is unique for this LU pair. It is recommended that an Agent not reuse the index of a deactivated session for a significant period of time (e.g., one week). If this object has the same value as appcActSessIndex for the same LU pair, then the two entries being indexed apply to the same resource (specifically, to the same session)." ::= { appcSessStatsEntry 3 } appcSessStatsSentFmdBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of function management data (FMD) bytes sent by the local LU." ::= { appcSessStatsEntry 4 } appcSessStatsSentNonFmdBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of non-function management data (non-FMD) bytes sent by the local LU." ::= { appcSessStatsEntry 5 } appcSessStatsRcvdFmdBytes OBJECT-TYPE Allen, et. al. Standards Track [Page 86] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of function management data (FMD) bytes received by the local LU." ::= { appcSessStatsEntry 6 } appcSessStatsRcvdNonFmdBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of non-function management data (non-FMD) bytes received by the local LU." ::= { appcSessStatsEntry 7 } appcSessStatsSentFmdRus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of function management data (FMD) RUs sent by the local LU." ::= { appcSessStatsEntry 8 } appcSessStatsSentNonFmdRus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of non-function management data (non-FMD) RUs sent by the local LU." ::= { appcSessStatsEntry 9 } appcSessStatsRcvdFmdRus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of function management data (FMD) RUs received by the local LU." ::= { appcSessStatsEntry 10 } Allen, et. al. Standards Track [Page 87] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcSessStatsRcvdNonFmdRus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of non-function management data (non-FMD) RUs received by the local LU." ::= { appcSessStatsEntry 11 } appcSessStatsCtrUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time the counters for this session have been active, measured in hundredths of a second." ::= { appcSessStatsEntry 12 } -- ********************************************************************* -- APPC Historical Session Table -- --------------------------------------------------------------------- -- This table contains historical information about APPC sessions that -- terminated abnormally. It is an implementation choice how long to -- retain information on a given session. -- ********************************************************************* appcHistSessTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcHistSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of historical information about APPC sessions that terminated abnormally. Two entries may be present in the table when both session partners are local. It is an implementation choice how long to retain information about a given session." ::= { appcSession 3 } appcHistSessEntry OBJECT-TYPE SYNTAX AppcHistSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of APPC Session History Table. This table is indexed by an integer which is continuously incremented until it eventually wraps." Allen, et. al. Standards Track [Page 88] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 INDEX { appcHistSessIndex } ::= { appcHistSessTable 1 } AppcHistSessEntry ::= SEQUENCE { appcHistSessIndex INTEGER, appcHistSessTime DateAndTime, appcHistSessType INTEGER, appcHistSessLocLuName DisplayString, appcHistSessParLuName DisplayString, appcHistSessModeName DisplayString, appcHistSessUnbindType OCTET STRING, appcHistSessSenseData SnaSenseData, appcHistSessComponentId DisplayString, appcHistSessDetectModule DisplayString } appcHistSessIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table index. The value of the index begins at zero and is incremented up to a maximum value of 2**31-1 (2,147,483,647) before wrapping." ::= { appcHistSessEntry 1 } appcHistSessTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the session was either terminated or failed to be established." ::= { appcHistSessEntry 2 } appcHistSessType OBJECT-TYPE SYNTAX INTEGER { recvNegBindRsp(1), sendNegBindRsp(2), sessActRejected(3), unbindSent(4), unbindReceived(5) } Allen, et. al. Standards Track [Page 89] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the type of event that caused the entry to be made: recvNegBindRsp - Received a negative bind response from the partner LU. sendNegBindRsp - Sent a negative bind response to the partner LU. sessActRejected - Session activation rejected by the partner LU. unbindSent - Unbind sent to the partner LU. unbindReceived - Unbind received from the partner LU. These event types correspond to the five SNA/MS Alerts LU62001 through LU62005, documented in the SNA Management Services Reference." ::= { appcHistSessEntry 3 } appcHistSessLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-qualified local LU name. This field is from 3 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcHistSessEntry 4 } appcHistSessParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-qualified partner LU name. This field is from 3 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcHistSessEntry 5 } appcHistSessModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The mode name of the session." Allen, et. al. Standards Track [Page 90] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcHistSessEntry 6 } appcHistSessUnbindType OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The type of unbind which terminated the session. This value is consists of one (1) octet; and its meaning is defined in SNA Formats." ::= { appcHistSessEntry 7 } appcHistSessSenseData OBJECT-TYPE SYNTAX SnaSenseData MAX-ACCESS read-only STATUS current DESCRIPTION "The sense data associated with the termination of the session, taken from the negative BIND response or UNBIND request." ::= { appcHistSessEntry 8 } appcHistSessComponentId OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The implementation-specific name of the component which detected the problem." ::= { appcHistSessEntry 9 } appcHistSessDetectModule OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The implementation-specific name of the module which detected the problem." ::= { appcHistSessEntry 10 } -- ********************************************************************* -- APPC Session RTP Connection Table -- --------------------------------------------------------------------- Allen, et. al. Standards Track [Page 91] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 -- This table contains information on APPC sessions that are being -- transported on RTP connections by High Performance Routing (HPR). -- ********************************************************************* appcSessRtpTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcSessRtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table indicating how many APPC sessions terminating in this node are transported by each RTP connection." ::= { appcSession 4 } appcSessRtpEntry OBJECT-TYPE SYNTAX AppcSessRtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of APPC session RTP table." INDEX { appcSessRtpNceId, appcSessRtpTcid } ::= { appcSessRtpTable 1 } AppcSessRtpEntry ::= SEQUENCE { appcSessRtpNceId OCTET STRING, appcSessRtpTcid OCTET STRING, appcSessRtpSessions Gauge32 } appcSessRtpNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local Network Connection Endpoint of the RTP connection." ::= { appcSessRtpEntry 1 } appcSessRtpTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local TCID of the RTP connection." ::= { appcSessRtpEntry 2 } Allen, et. al. Standards Track [Page 92] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcSessRtpSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of APPC sessions terminating in this node that are using this RTP connection." ::= { appcSessRtpEntry 3 } -- ********************************************************************* -- APPC Active Conversation Table -- This table contains information about active APPC conversations. -- ********************************************************************* appcActiveConvTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcActiveConvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of information about active APPC Conversations. In this context 'active' means that a conversation is currently associated with a particular session. Two entries are present in the table when both LUs for the session are local." ::= { appcConversation 1 } appcActiveConvEntry OBJECT-TYPE SYNTAX AppcActiveConvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry representing one active APPC Conversation." INDEX { appcActiveConvLocLuName, appcActiveConvParLuName, appcActiveConvSessIndex } ::= { appcActiveConvTable 1} AppcActiveConvEntry ::= SEQUENCE { appcActiveConvLocLuName DisplayString, appcActiveConvParLuName DisplayString, appcActiveConvSessIndex Integer32, appcActiveConvId OCTET STRING, appcActiveConvState INTEGER, appcActiveConvType INTEGER, Allen, et. al. Standards Track [Page 93] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcActiveConvCorrelator OCTET STRING, appcActiveConvSyncLvl INTEGER, appcActiveConvSource INTEGER, appcActiveConvDuplex INTEGER, appcActiveConvUpTime TimeTicks, appcActiveConvSendBytes Counter32, appcActiveConvRcvBytes Counter32, appcActiveConvUserid DisplayString, appcActiveConvPcidNauName DisplayString, appcActiveConvPcid OCTET STRING, appcActiveConvModeName DisplayString, appcActiveConvLuwIdName DisplayString, appcActiveConvLuwIdInstance OCTET STRING, appcActiveConvLuwIdSequence OCTET STRING, appcActiveConvTpName DisplayString } appcActiveConvLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU for the conversation. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. If this object has the same value as appcLluOperName, then the two entries being indexed apply to the same resource (specifically, to the same local LU)." ::= { appcActiveConvEntry 1 } appcActiveConvParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the partner LU for the conversation. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. If this object has the same value as appcLuPairOperParLuName, then the two entries being indexed apply to the same resource (specifically, to the same partner LU)." ::= { appcActiveConvEntry 2 } Allen, et. al. Standards Track [Page 94] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcActiveConvSessIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of entry in appcActSessTable that is associated with this conversation. If this object has the same value as appcActSessIndex for the same LU pair, then the two entries being indexed apply to the same resource (specifically, to the same session)." ::= { appcActiveConvEntry 3 } appcActiveConvId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) MAX-ACCESS read-only STATUS current DESCRIPTION "The 4-byte ID of the conversation." ::= { appcActiveConvEntry 4 } appcActiveConvState OBJECT-TYPE SYNTAX INTEGER { reset(1), send(2), receive(3), confirm(4), confirmSend(5), confirmDealloc(6), pendingDeallocate(7), pendingPost(8), sendReceive(9), sendOnly(10), receiveOnly(11), deferReceive(12), deferDeallocate(13), syncpoint(14), syncpointSend(15), syncpointDeallocate(16), backoutRequired(17) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the state of the conversation at the instant when the information was retrieved. The values are: Allen, et. al. Standards Track [Page 95] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 reset The conversation is reset (i.e., deallocated). send The conversation can send data. This value also is returned if the conversation is in Send-Pending state. receive The conversation can receive data. confirm The conversation has received a confirm indicator. It can issue an [MC_]CONFIRMED or [MC_]SEND_ERROR verb to change state. It will continue in Receive state if an [MC_]CONFIRMED verb is issued. confirmSend The conversation is in Confirm state and changes to Send state when an [MC_]CONFIRMED verb is issued. confirmDealloc The conversation is in Confirm state and becomes inactive when an [MC_]CONFIRMED verb is issued. pendingDeallocate The conversation is in Pending-Deallocate state while it waits for (MC_)DEALLOCATE TYPE (sync_level) to complete. pendingPost The conversation is in Pending-Post state while it waits for the [MC_]RECEIVE_AND_POST verb to complete its receive function. sendReceive The full-duplex conversation can send or receive data. sendOnly The full-duplex conversation can send data, but it does not have permission to receive data, because the partner TP has already deallocated its side of the conversation. receiveOnly The full-duplex conversation can receive data, but it does not have permission to send data, because it has already deallocated its side of the conversation. deferReceive Waiting for a successful SYNCPT verb operation to go into the receive state. deferDeallocate Waiting for a successful SYNCPT verb operation to go into the reset state. Allen, et. al. Standards Track [Page 96] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 syncpoint Need to response to a SYNCPT verb issued. After successful operation, the next state will be receive. syncpointSend Need to response to a SYNCPT verb issued. After successful operation, the next state will be send. syncpointDeallocate Need to response to a SYNCPT verb issued. After successful operation, the next state will be reset. backoutRequired TP must execute a BACKOUT verb to backout the transaction." ::= { appcActiveConvEntry 5 } appcActiveConvType OBJECT-TYPE SYNTAX INTEGER { basic(1), mapped(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the type of conversation. The values are: basic Indicates that this conversation supports basic verbs. mapped Indicates that this conversation supports mapped verbs." ::= { appcActiveConvEntry 6 } appcActiveConvCorrelator OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is an 8-byte identifier that the source LU assigns to the conversation; the source LU is the one that sent the allocation request. The conversation correlator is included on the allocation request. The conversation correlator uniquely Allen, et. al. Standards Track [Page 97] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 identifies a conversation, from among all conversations, between the local and partner LUs. It may be used, for example, during problem determination associated with a conversation. A length of 0 indicates that no conversation correlator is defined." ::= { appcActiveConvEntry 7 } appcActiveConvSyncLvl OBJECT-TYPE SYNTAX INTEGER { none(1), confirm(2), syncpt(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the highest sync level support for the conversation. The values are: none Indicates that no sync-level processing can be performed on this conversation. The transaction program does not issue verbs or recognize any returned parameters relating to any sync-level function. confirm Indicates that confirmation processing can be performed on this conversation. The transaction program can issue verbs and recognize returned parameters relating to confirmation. syncpt Indicates that syncpt and confirmation processing can be performed on this conversation. The transaction program can issue verbs and recognize returned parameters relating to syncpt and confirmation." ::= { appcActiveConvEntry 8 } appcActiveConvSource OBJECT-TYPE SYNTAX INTEGER { localLu(1), partnerLu(2) } Allen, et. al. Standards Track [Page 98] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the local or partner LU is the source of the conversation, that is, which LU started the conversation by sending the allocation request. localLu The local LU is the source of the conversation, and the partner LU is the target of the conversation. partnerLu The partner LU is the source of the conversation, and the local LU is the target of the conversation." ::= { appcActiveConvEntry 9 } appcActiveConvDuplex OBJECT-TYPE SYNTAX INTEGER { half(1), full(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the conversation duplex style in effect for the conversation. half Indicates that information can be transferred in both directions, but only in one direction at a time. full Indicates that information can be transferred in both directions at the same time." ::= { appcActiveConvEntry 10 } appcActiveConvUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time since the conversation started, measured in hundredths of a second." ::= { appcActiveConvEntry 11 } Allen, et. al. Standards Track [Page 99] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcActiveConvSendBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of bytes that was sent on the conversation. The count includes all SNA RU bytes sent, including those in the FMH-5 (Attach), FMH-7 (Error Description), SIGNAL, LUSTAT, and SNA responses; it does not include SNA TH and RH bytes." ::= { appcActiveConvEntry 12 } appcActiveConvRcvBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of bytes that was received on the conversation. The count includes all SNA RU bytes sent, including those in the FMH-5 (Attach), FMH-7 (Error Description), SIGNAL, LUSTAT, and SNA responses; it does not include SNA TH and RH bytes." ::= { appcActiveConvEntry 13 } appcActiveConvUserid OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "The user ID that the initiating program provided in the incoming attach." ::= { appcActiveConvEntry 14 } appcActiveConvPcidNauName OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-qualified NAU name of the node at which the session and PCID originated. For APPN and LEN nodes, this is either CP name of the APPN node at which the origin LU is located or the CP name of the NN serving the LEN node at which the origin LU is located. This field is from 3 to 17 characters in length, including a period (.) which separates the Allen, et. al. Standards Track [Page 100] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 NetId from the NAU name. A null string indicates that the value is unknown." ::= { appcActiveConvEntry 15 } appcActiveConvPcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0|8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The procedure correlation identifier (PCID) of the session. It is an 8-octet value assigned by the control point providing session services for the primary LU. A null string indicates that the value is unknown." ::= { appcActiveConvEntry 16 } appcActiveConvModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Mode Name used for this conversation. This is a 1-8 character name." ::= { appcActiveConvEntry 17 } appcActiveConvLuwIdName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA name of the LU that initiated the logical unit of work that is associated with this active TP. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the LU name if the NetId is present." ::= { appcActiveConvEntry 18 } appcActiveConvLuwIdInstance OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..6)) MAX-ACCESS read-only STATUS current DESCRIPTION "The instance identifier for the logical unit of work." ::= { appcActiveConvEntry 19 } Allen, et. al. Standards Track [Page 101] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcActiveConvLuwIdSequence OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..2)) MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence identifier for the logical unit of work." ::= { appcActiveConvEntry 20 } appcActiveConvTpName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The transaction program name which started this conversation. This name could either be from a FMH5 ATTACH for a remotely started conversation, otherwise it could the name of the local TP if available. When the TP name consists entirely of displayable EBCDIC code points, it is mapped directly to the equivalent ASCII display string. However, registered TP names always have a non- displayable EBCDIC code point (value less than or equal to x'3F') as the first character, so they cannot be directly mapped to an ASCII display string. These TP names are converted to a display string that is equivalent to a hexadecimal display of the EBCDIC code points. For example, the 2-byte TP name x'06F1' (CNOS) is converted to the 6-byte ASCII display string '06F1' (including the two single quotes). This name is NULL if the conversation is started locally (i.e., not with a FMH5 ATTACH)." ::= { appcActiveConvEntry 21 } -- ********************************************************************* -- APPC Historical Conversation Table -- This table contains historical information about APPC -- conversations that ended abnormally. It is an implementation -- choice how long to retain information on a given conversation. -- ********************************************************************* appcHistConvTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcHistConvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of historical information about APPC Conversations that Allen, et. al. Standards Track [Page 102] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ended in error. Possible categories of error conditions that could be saved in this table are: - allocation errors, - deallocate abend, - program errors, and - service errors." ::= { appcConversation 2 } appcHistConvEntry OBJECT-TYPE SYNTAX AppcHistConvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry representing one APPC Conversation." INDEX { appcHistConvIndex } ::= { appcHistConvTable 1} AppcHistConvEntry ::= SEQUENCE { appcHistConvIndex Integer32, appcHistConvEndTime DateAndTime, appcHistConvLocLuName DisplayString, appcHistConvParLuName DisplayString, appcHistConvTpName DisplayString, appcHistConvPcidNauName DisplayString, appcHistConvPcid OCTET STRING, appcHistConvSenseData SnaSenseData, appcHistConvLogData OCTET STRING, appcHistConvEndedBy INTEGER } appcHistConvIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for entry in Conversation table. This value identifies the unique index of the conversation. It is recommended that an Agent not reuse the index of a deactivated conversation for a significant period of time (e.g. one week)." ::= { appcHistConvEntry 1 } appcHistConvEndTime OBJECT-TYPE Allen, et. al. Standards Track [Page 103] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the conversation ended." ::= { appcHistConvEntry 2 } appcHistConvLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the local LU for this conversation. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcHistConvEntry 3 } appcHistConvParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA name of the partner LU for the conversation. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcHistConvEntry 4 } appcHistConvTpName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The transaction program name which started this conversation. This name could either be from a FMH5 ATTACH for a remotely started conversation, otherwise it could the name of the local TP if available. When the TP name consists entirely of displayable EBCDIC code points, it is mapped directly to the equivalent ASCII display string. However, registered TP names always have a non- displayable EBCDIC code point (value less than or equal to x'3F') as the first character, so they cannot be directly mapped to an ASCII display string. These TP names are converted to a display string that is equivalent to a Allen, et. al. Standards Track [Page 104] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 hexadecimal display of the EBCDIC code points. For example, the 2-byte TP name x'06F1' (CNOS) is converted to the 6-byte ASCII display string '06F1' (including the two single quotes). This name is NULL if the conversation is started locally (i.e., not with a FMH5 ATTACH)." ::= { appcHistConvEntry 5 } appcHistConvPcidNauName OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-qualified NAU name of the node at which the session and PCID originated. For APPN and LEN nodes, this is either CP name of the APPN node at which the origin LU is located or the CP name of the NN serving the LEN node at which the origin LU is located. This field is from 3 to 17 characters in length, including a period (.) which separates the NetId from the NAU name. A null string indicates that the value is unknown." ::= { appcHistConvEntry 6 } appcHistConvPcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0|8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The procedure correlation identifier (PCID) of the session. It is an 8-octet value assigned by the control point providing session services for the primary LU. A null string indicates that the value is unknown." ::= { appcHistConvEntry 7 } appcHistConvSenseData OBJECT-TYPE SYNTAX SnaSenseData MAX-ACCESS read-only STATUS current DESCRIPTION "The sense data associated with the action that ended this conversation, e.g., FMH-7 or UNBIND." ::= { appcHistConvEntry 8 } Allen, et. al. Standards Track [Page 105] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcHistConvLogData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The first 32 bytes of the data portion of the Log Data GDS Variable that is associated with the last FMH-7 that occurred on this conversation. If there was no Log Data GDS Variable associated with the FMH-7, this object is null. This object reflects only the data portion of the Log Data GDS Variable (i.e. not the LL or GDS Id)." ::= { appcHistConvEntry 9 } appcHistConvEndedBy OBJECT-TYPE SYNTAX INTEGER { localLu(1), partnerLu(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates which LU ended the conversation." ::= { appcHistConvEntry 10 } -- ********************************************************************* -- APPC CPIC Admin Table -- Objects in this table contain default or expected configuration -- values for CPI-C side information. -- ********************************************************************* appcCpicAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcCpicAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPC CPI-C side information table." ::= { appcCPIC 1 } appcCpicAdminEntry OBJECT-TYPE SYNTAX AppcCpicAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of APPC CPI-C side information Table." Allen, et. al. Standards Track [Page 106] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 INDEX { appcCpicAdminLocLuName, appcCpicAdminSymbDestName } ::= { appcCpicAdminTable 1 } AppcCpicAdminEntry ::= SEQUENCE { appcCpicAdminLocLuName DisplayString, appcCpicAdminSymbDestName DisplayString, appcCpicAdminParLuAlias DisplayString, appcCpicAdminParLuName DisplayString, appcCpicAdminModeName DisplayString, appcCpicAdminTpNameType INTEGER, appcCpicAdminTpName DisplayString, appcCpicAdminUserid DisplayString, appcCpicAdminSecurity INTEGER } appcCpicAdminLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU to which this CPI-C side information definition applies. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. The reserved value '*ALL' indicates that the definition applies to all local LUs, and not just to a single local LU." ::= { appcCpicAdminEntry 1 } appcCpicAdminSymbDestName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the symbolic destination name used by CPI-C applications to identify this definition." ::= { appcCpicAdminEntry 2 } appcCpicAdminParLuAlias OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A local alias for the partner LU. If not known or Allen, et. al. Standards Track [Page 107] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 not applicable, this object contains a zero-length string." ::= { appcCpicAdminEntry 3 } appcCpicAdminParLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA name of the partner LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcCpicAdminEntry 4 } appcCpicAdminModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the mode name. A mode defines the characteristics for a group of sessions. The mode name can be blank (8 space characters)." ::= { appcCpicAdminEntry 5 } appcCpicAdminTpNameType OBJECT-TYPE SYNTAX INTEGER { normal(1), snaServiceTp(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether the TP name in appcCpicAdminTpName identifies a normal TP or an SNA service TP. In this context, a normal TP is one with a name consisting only of displayable characters, while an SNA service TP has a name containing octets that do not map to displayable characters." ::= { appcCpicAdminEntry 6 } appcCpicAdminTpName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) Allen, et. al. Standards Track [Page 108] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the name of the partner TP to be used when a CPI-C application initiates a conversation specifying this side information entry. Display convention When the TP name consists entirely of displayable EBCDIC code points, it is mapped directly to the equivalent ASCII display string. However, registered TP names always have a non-displayable EBCDIC code point (value less than or equal to x'3F') as the first character, so they cannot be directly mapped to an ASCII display string. These TP names are converted to a display string that is equivalent to a hexadecimal display of the EBCDIC code points. For example, the 2-byte TP name x'06F1' (CNOS) is converted to the 6-byte ASCII display string '06F1' (including the two single quotes)." ::= { appcCpicAdminEntry 7 } appcCpicAdminUserid OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "The security userid, if any, associated with the side information definition." ::= { appcCpicAdminEntry 8 } appcCpicAdminSecurity OBJECT-TYPE SYNTAX INTEGER { none(1), same(2), pgm(3), pgmStrong(4), distributed(5), mutual(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the security information to be used for allocating the conversation. Allen, et. al. Standards Track [Page 109] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 none - No security information. same - Use the security environment currently associated with this TP. pgm - Use the program-supplied user_id and password. pgmStrong - Use the program-supplied user_id and password. The local LU will insure that the password is not exposed in clear-text form on the physical network. distributed - Use the security environment and a distributed security system to generate the authentication information for this request. If distributed security tokens cannot be generated, then fail the conversation. mutual - Authenticate both the user to the destination system and the destination system to the user." ::= { appcCpicAdminEntry 9 } -- ********************************************************************* -- APPC CPIC Oper Table -- Objects in this table contain current operational values, such -- as state values or negotiated parameters, for CPI-C side -- information. -- ********************************************************************* appcCpicOperTable OBJECT-TYPE SYNTAX SEQUENCE OF AppcCpicOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPC CPI-C side information operational table." ::= { appcCPIC 2 } appcCpicOperEntry OBJECT-TYPE SYNTAX AppcCpicOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of APPC CPI-C side information Table." INDEX { appcCpicOperLocLuName, appcCpicOperSymbDestName } ::= { appcCpicOperTable 1 } Allen, et. al. Standards Track [Page 110] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 AppcCpicOperEntry ::= SEQUENCE { appcCpicOperLocLuName DisplayString, appcCpicOperSymbDestName DisplayString, appcCpicOperParLuAlias DisplayString, appcCpicOperParLuName DisplayString, appcCpicOperModeName DisplayString, appcCpicOperTpNameType INTEGER, appcCpicOperTpName DisplayString, appcCpicOperUserid DisplayString, appcCpicOperSecurity INTEGER } appcCpicOperLocLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of the local LU to which this CPI-C side information definition applies. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present. The reserved value '*ALL' indicates that the definition applies to all local LUs, and not just to a single local LU." ::= { appcCpicOperEntry 1 } appcCpicOperSymbDestName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the symbolic destination name used by CPI-C applications to identify this definition." ::= { appcCpicOperEntry 2 } appcCpicOperParLuAlias OBJECT-TYPE SYNTAX DisplayString (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A local alias for the partner LU. If not known or not applicable, this object contains a zero-length string." ::= { appcCpicOperEntry 3 } appcCpicOperParLuName OBJECT-TYPE Allen, et. al. Standards Track [Page 111] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA name of the partner LU. This field is from 1 to 17 characters in length, including a period (.) which separates the NetId from the NAU name if the NetId is present." ::= { appcCpicOperEntry 4 } appcCpicOperModeName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the mode name. A mode defines the characteristics for a group of sessions. The mode name can be blank (8 space characters)." ::= { appcCpicOperEntry 5 } appcCpicOperTpNameType OBJECT-TYPE SYNTAX INTEGER { normal(1), snaServiceTp(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies whether the TP name in appcCpicOperTpName identifies a normal TP or an SNA service TP. In this context, a normal TP is one with a name consisting only of displayable characters, while an SNA service TP has a name containing octets that do not map to displayable characters." ::= { appcCpicOperEntry 6 } appcCpicOperTpName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the name of the partner TP to be used when a CPI-C application initiates a conversation specifying this side information entry. Allen, et. al. Standards Track [Page 112] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 Display convention When the TP name consists entirely of displayable EBCDIC code points, it is mapped directly to the equivalent ASCII display string. However, registered TP names always have a non-displayable EBCDIC code point (value less than or equal to x'3F') as the first character, so they cannot be directly mapped to an ASCII display string. These TP names are converted to a display string that is equivalent to a hexadecimal display of the EBCDIC code points. For example, the 2-byte TP name x'06F1' (CNOS) is converted to the 6-byte ASCII display string '06F1' (including the two single quotes)." ::= { appcCpicOperEntry 7 } appcCpicOperUserid OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "The security userid, if any, associated with the active side information definition." ::= { appcCpicOperEntry 8 } appcCpicOperSecurity OBJECT-TYPE SYNTAX INTEGER { none(1), same(2), pgm(3), pgmStrong(4), distributed(5), mutual(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the security information to be used for allocating the conversation. none - No security information. same - Use the security environment currently associated with this TP. pgm - Use the program-supplied user_id and password. pgmStrong - Use the program-supplied user_id and password. The local LU will insure that the password is not exposed in clear-text form on the physical Allen, et. al. Standards Track [Page 113] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 network. distributed - Use the security environment and a distributed security system to generate the authentication information for this request. If distributed security tokens cannot be generated, then fail the conversation. mutual - Authenticate both the user to the destination system and the destination system to the user." ::= { appcCpicOperEntry 9 } -- *************************************************************** -- Conformance information -- *************************************************************** appcConformance OBJECT IDENTIFIER ::= {appcMIB 2 } appcCompliances OBJECT IDENTIFIER ::= {appcConformance 1 } appcGroups OBJECT IDENTIFIER ::= {appcConformance 2 } -- Compliance statements appcCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SNMPv2 entities which implement the APPC MIB." MODULE -- this module -- Unconditionally mandatory groups MANDATORY-GROUPS { appcGlobalConfGroup, appcLluConfGroup, appcParLuConfGroup, appcModeConfGroup, appcTpConfGroup, appcSessionConfGroup } -- Conditionally mandatory groups GROUP appcControlConfGroup DESCRIPTION "The appcControlConfGroup is mandatory only for those entities which implement activation and deactivation of specific controls such as statistics collecting and counting." Allen, et. al. Standards Track [Page 114] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 GROUP appcCnosConfGroup DESCRIPTION "The appcCnosConfGroup is mandatory only for those entities which implement CNOS. " GROUP appcCpicConfGroup DESCRIPTION "The appcCpicConfGroup is mandatory only for those entities which implement CPI-C. " GROUP appcConversationConfGroup DESCRIPTION "The appcConversationConfGroup is mandatory only for those entities which implement session endpoints for non-control APPC sessions." -- MIN-ACCESS for objects OBJECT appcActSessOperState MIN-ACCESS read-only DESCRIPTION "An implementation is not required to support session deactivation via this object." ::= {appcCompliances 1 } -- Units of conformance appcGlobalConfGroup OBJECT-GROUP OBJECTS { appcUpTime, appcDefaultModeName, appcDefaultLuName, appcDefaultImplInbndPlu, appcDefaultMaxMcLlSndSize, appcDefaultFileSpec, appcDefaultTpOperation, appcDefaultTpConvSecRqd, appcLocalCpName, appcActiveSessions, appcActiveHprSessions } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC global information and defaults." ::= { appcGroups 1 } Allen, et. al. Standards Track [Page 115] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcLluConfGroup OBJECT-GROUP OBJECTS { appcLluAdminDepType, appcLluAdminLocalAddress, appcLluAdminSessLimit, appcLluAdminBindRspMayQ, appcLluAdminCompression, appcLluAdminInBoundCompLevel, appcLluAdminOutBoundCompLevel, appcLluAdminCompRleBeforeLZ, appcLluAdminAlias, appcLluOperDepType, appcLluOperLocalAddress, appcLluOperSessLimit, appcLluOperBindRspMayQ, appcLluOperCompression, appcLluOperInBoundCompLevel, appcLluOperOutBoundCompLevel, appcLluOperCompRleBeforeLZ, appcLluOperAlias, appcLluOperActiveSessions } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC local LU6.2s." ::= { appcGroups 2 } appcParLuConfGroup OBJECT-GROUP OBJECTS { appcLuPairAdminParLuAlias, appcLuPairAdminSessLimit, appcLuPairAdminSessSec, appcLuPairAdminSecAccept, appcLuPairAdminLinkObjId, appcLuPairAdminParaSessSup, appcLuPairOperParLuAlias, appcLuPairOperSessLimit, appcLuPairOperSessSec, appcLuPairOperSecAccept, appcLuPairOperLinkObjId, appcLuPairOperParaSessSup, appcLuPairOperParaSessSupLS, appcLuPairOperState } Allen, et. al. Standards Track [Page 116] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC partner LUs." ::= { appcGroups 3 } appcModeConfGroup OBJECT-GROUP OBJECTS { appcModeAdminCosName, appcModeAdminSessEndTpName, appcModeAdminMaxSessLimit, appcModeAdminMinCwinLimit, appcModeAdminMinClosLimit, appcModeAdminConWinAutoActLmt, appcModeAdminRecvPacWinSz, appcModeAdminSendPacWinSz, appcModeAdminPrefRecvRuSz, appcModeAdminPrefSendRuSz, appcModeAdminRecvRuSzUpBnd, appcModeAdminSendRuSzUpBnd, appcModeAdminRecvRuSzLoBnd, appcModeAdminSendRuSzLoBnd, appcModeAdminSingSessReinit, appcModeAdminCompression, appcModeAdminInBoundCompLevel, appcModeAdminOutBoundCompLevel, appcModeAdminCompRleBeforeLZ, appcModeAdminSyncLvl, appcModeAdminCrypto, appcModeOperCosName, appcModeOperSessEndTpName, appcModeOperSessLimit, appcModeOperMaxSessLimit, appcModeOperMinCwinLimit, appcModeOperMinClosLimit, appcModeOperConWinAutoActLmt, appcModeOperRecvPacWinSz, appcModeOperSendPacWinSz, appcModeOperPrefRecvRuSz, appcModeOperPrefSendRuSz, appcModeOperRecvRuSzUpBnd, appcModeOperSendRuSzUpBnd, appcModeOperRecvRuSzLoBnd, appcModeOperSendRuSzLoBnd, appcModeOperSingSessReinit, Allen, et. al. Standards Track [Page 117] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcModeOperCompression, appcModeOperInBoundCompLevel, appcModeOperOutBoundCompLevel, appcModeOperCompRleBeforeLZ, appcModeOperSyncLvl, appcModeOperCrypto, appcModeOperSyncLvlLastStart, appcModeOperCryptoLastStart, appcModeOperCNOSNeg, appcModeOperActCwin, appcModeOperActClos, appcModeOperPndCwin, appcModeOperPndClos, appcModeOperPtmCwin, appcModeOperPtmClos, appcModeOperDrainSelf, appcModeOperDrainPart } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC modes." ::= { appcGroups 4 } appcTpConfGroup OBJECT-GROUP OBJECTS { appcTpAdminFileSpec, appcTpAdminStartParm, appcTpAdminTpOperation, appcTpAdminInAttachTimeout, appcTpAdminRcvAllocTimeout, appcTpAdminSyncLvl, appcTpAdminInstLmt, appcTpAdminStatus, appcTpAdminLongRun, appcTpAdminConvType, appcTpAdminConvDuplex, appcTpAdminConvSecReq, appcTpAdminVerPip, appcTpAdminPipSubNum } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC Transaction Programs." ::= { appcGroups 5 } Allen, et. al. Standards Track [Page 118] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcSessionConfGroup OBJECT-GROUP OBJECTS { appcActSessPcidCpName, appcActSessPcid, appcActSessPluIndicator, appcActSessModeName, appcActSessCosName, appcActSessTransPriority, appcActSessEnhanceSecSup, appcActSessSendPacingType, appcActSessSendRpc, appcActSessSendNxWndwSize, appcActSessRecvPacingType, appcActSessRecvRpc, appcActSessRecvNxWndwSize, appcActSessRscv, appcActSessInUse, appcActSessMaxSndRuSize, appcActSessMaxRcvRuSize, appcActSessSndPacingSize, appcActSessRcvPacingSize, appcActSessOperState, appcActSessUpTime, appcActSessRtpNceId, appcActSessRtpTcid, appcActSessLinkIndex, appcSessStatsSentFmdBytes, appcSessStatsSentNonFmdBytes, appcSessStatsRcvdFmdBytes, appcSessStatsRcvdNonFmdBytes, appcSessStatsSentFmdRus, appcSessStatsSentNonFmdRus, appcSessStatsRcvdFmdRus, appcSessStatsRcvdNonFmdRus, appcSessStatsCtrUpTime, appcHistSessTime, appcHistSessType, appcHistSessLocLuName, appcHistSessParLuName, appcHistSessModeName, appcHistSessUnbindType, appcHistSessSenseData, appcHistSessComponentId, appcHistSessDetectModule, appcSessRtpSessions Allen, et. al. Standards Track [Page 119] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC LU6.2 sessions." ::= { appcGroups 6 } appcControlConfGroup OBJECT-GROUP OBJECTS { appcCntrlAdminStat, appcCntrlAdminRscv, appcCntrlAdminTrace, appcCntrlAdminTraceParm, appcCntrlOperStat, appcCntrlOperStatTime, appcCntrlOperRscv, appcCntrlOperRscvTime, appcCntrlOperTrace, appcCntrlOperTraceTime, appcCntrlOperTraceParm } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC control." ::= { appcGroups 7 } appcCnosConfGroup OBJECT-GROUP OBJECTS { appcCnosCommand, appcCnosMaxSessLimit, appcCnosMinCwinLimit, appcCnosMinClosLimit, appcCnosDrainSelf, appcCnosDrainPart, appcCnosResponsible, appcCnosForce, appcCnosTargetLocLuName, appcCnosTargetParLuName, appcCnosTargetModeName } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC CNOS processing." Allen, et. al. Standards Track [Page 120] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 ::= { appcGroups 8 } appcCpicConfGroup OBJECT-GROUP OBJECTS { appcCpicAdminParLuAlias, appcCpicAdminParLuName, appcCpicAdminModeName, appcCpicAdminTpNameType, appcCpicAdminTpName, appcCpicAdminUserid, appcCpicAdminSecurity, appcCpicOperParLuAlias, appcCpicOperParLuName, appcCpicOperModeName, appcCpicOperTpNameType, appcCpicOperTpName, appcCpicOperUserid, appcCpicOperSecurity } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC CPI-C side information." ::= { appcGroups 9 } appcConversationConfGroup OBJECT-GROUP OBJECTS { appcActiveConvId, appcActiveConvState, appcActiveConvType, appcActiveConvCorrelator, appcActiveConvSyncLvl, appcActiveConvSource, appcActiveConvDuplex, appcActiveConvUpTime, appcActiveConvSendBytes, appcActiveConvRcvBytes, appcActiveConvUserid, appcActiveConvPcidNauName, appcActiveConvPcid, appcActiveConvModeName, appcActiveConvLuwIdName, appcActiveConvLuwIdInstance, appcActiveConvLuwIdSequence, appcActiveConvTpName, appcHistConvEndTime, Allen, et. al. Standards Track [Page 121] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 appcHistConvLocLuName, appcHistConvParLuName, appcHistConvTpName, appcHistConvPcidNauName, appcHistConvPcid, appcHistConvSenseData, appcHistConvLogData, appcHistConvEndedBy } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPC conversations." ::= { appcGroups 10 } -- end of conformance statement END Allen, et. al. Standards Track [Page 122] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 5. Acknowledgments This MIB module is the product of the SNA NAU MIB Working Group. Special thanks to Wayne Clark, Cisco Systems; Rich Daugherty, IBM Corporation; and Leo Temoshenko, IBM Corporation, for their contributions and review. 6. References [1] IBM, Systems Network Architecture Technical Overview, GC30-3073-4, January, 1994. [2] 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. [3] 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. [4] 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. [5] IBM, Systems Network Architecture Transaction Programmer's Reference for LU Type 6.2, GC30-3084-05, June, 1993. [6] IBM, Common Programming Interface Communications Specification 2.0, SC31-6180-01, June, 1994. [7] Kielczewski, Z., Kostick D., and K. Shih, "Definition of Managed Objects for SNA NAUs using SMIv2", RFC 1666, Eicon Technology Corporation, Bell Communications Research, Novell, August 1994. 7. Security Considerations Security issues are not discussed in this memo. Allen, et. al. Standards Track [Page 123] RFC 2051 SNANAU APPC MIB using SMIv2 October 1996 8. Authors' Addresses Michael Allen Wall Data Inc. P.O.Box 1120, WA 98019, USA Phone: +1 206 844 3505 EMail: mallen@hq.walldata.com Bob Clouston Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709, USA Phone: +1 919 472 2333 EMail: clouston@cisco.com Zbigniew Kielczewski Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709, USA Phone: +1 919 472 2326 EMail: zbig@cisco.com William Kwan Jupiter Technology Inc. 200 Prospect St. Waltham, MA 02254 Phone: 1 617 894-9300 x423 EMail: billk@jti.com Bob Moore IBM Corporation 800 Park Offices Drive E87/664 P.O. Box 12195 Research Triangle Park, NC 27709, USA Phone: 1 919 254 4436 EMail: remoore@ralvm6.vnet.ibm.com Allen, et. al. Standards Track [Page 124] snmp-mibs-downloader-1.1/mibrfcs/rfc2108.txt0000644000000000000000000050470011402176071015562 0ustar Network Working Group K. de Graaf Request for Comments: 2108 3Com Corporation Obsoletes: 1516 D. Romascanu Category: Standards Track Madge Networks (Israel) Ltd. D. McMaster Coloma Communications K. McCloghrie Cisco Systems Inc. February 1997 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. Table of Contents 1. The SNMP Network Management Framework.................... 2 1.1. Object Definitions..................................... 2 2. Overview................................................. 2 2.1. Relationship to RFC 1516............................... 2 2.2. Repeater Management.................................... 3 2.3. Structure of the MIB................................... 4 2.3.1. Basic Definitions.................................... 4 2.3.2. Monitor Definitions.................................. 4 2.3.3. Address Tracking Definitions......................... 4 2.3.4. Top N Definitions.................................... 4 2.4. Relationship to Other MIBs............................. 4 2.4.1. Relationship to MIB-II............................... 4 2.4.1.1. Relationship to the 'system' group................. 5 2.4.1.2. Relationship to the 'interfaces' group............. 5 3. Definitions............................................... 6 de Graaf, et. al. Standards Track [Page 1] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 4. Topology Mapping......................................... 75 5. Acknowledgements......................................... 79 6. References............................................... 80 7. Security Considerations.................................. 81 8. Authors' Addresses....................................... 81 1. 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 [6] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [5] - the core set of managed objects for the Internet suite of protocols. o the protocol, STD 15, RFC 1157 [10] and/or RFC 1905 [9] - the protocol used for accessing managed information. Textual conventions are defined in RFC 1903 [7], and conformance statements are defined in RFC 1904 [8]. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. 2. Overview 2.1. Relationship to RFC 1516 This MIB is intended as a superset of that defined by RFC 1516 [11], which will go to historic status. This MIB includes all of the objects contained in that MIB, plus several new ones which provide de Graaf, et. al. Standards Track [Page 2] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 for significant additional capabilities. Implementors are encouraged to support all applicable conformance groups in order to make the best use of the new functionality provided by this MIB. The new objects provide support for: o multiple repeaters o 100BASE-T management o port TopN capability o address search and topology mapping Certain objects have been deprecated; in particular, those scalar objects used for managing a single repeater are now of minimal use since they are duplicated in the new multiple- repeater definitions. Additional objects have been deprecated based on implementation experience with RFC 1516. 2.2. Repeater Management Instances of the object types defined in this memo represent attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE 802.3/ISO 8802-3 CSMA/CD standard [1], and Section 27, "Repeater for 100 Mb/s Baseband Networks" in the IEEE Standard 802.3u-1995 [2]. These Repeater MIB objects may be used to manage non-standard repeater-like devices, but defining objects to describe implementation-specific properties of non-standard repeater- like devices is outside the scope of this memo. The definitions presented here are based on Section 30.4, "Layer Management for 10 and 100 Mb/s Baseband Repeaters" and Annex 30A, "GDMO Specificataions for 802.3 managed objects" of [3]. Implementors of these MIB objects should note that [3] explicitly describes when, where, and how various repeater attributes are measured. The IEEE document also describes the effects of repeater actions that may be invoked by manipulating instances of the MIB objects defined here. The counters in this document are defined to be the same as those counters in [3], with the intention that the same instrumentation can be used to implement both the IEEE and IETF management standards. de Graaf, et. al. Standards Track [Page 3] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 2.3. Structure of the MIB Objects in this MIB are arranged into packages, each of which contains a set of related objects within a broad functional category. Objects within a package are generally defined under the same OID subtree. These packages are intended for organizational convenience ONLY, and have no relation to the conformance groups defined later in the document. 2.3.1. Basic Definitions The basic definitions include objects which are applicable to all repeaters: status, parameter and control objects for each repeater within the managed system, for the port groups within the system, and for the individual ports themselves. 2.3.2. Monitor Definitions The monitor definitions include monitoring statistics for each repeater within the system and for individual ports. 2.3.3. Address Tracking Definitions This collection includes objects for tracking the MAC addresses of the DTEs attached to the ports within the system and for mapping the topology of a network. Note: These definitions are based on a technology which has been patented by Hewlett-Packard Company. HP has granted rights to this technology to implementors of this MIB. See [12] and [13] for details. 2.3.4. Top N Definitions These objects may be used for tracking the ports with the most activity within the system or within particular repeaters. 2.4. Relationship to Other MIBs 2.4.1. Relationship to MIB-II It is assumed that a repeater implementing this MIB will also implement (at least) the 'system' group defined in MIB-II [5]. de Graaf, et. al. Standards Track [Page 4] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 2.4.1.1. Relationship to the 'system' group In MIB-II, the 'system' group is defined as being mandatory for all systems such that each managed entity contains one instance of each object in the 'system' group. Thus, those objects apply to the entity even if the entity's sole functionality is management of repeaters. 2.4.1.2. Relationship to the 'interfaces' group In MIB-II, the 'interfaces' group is defined as being mandatory for all systems and contains information on an entity's interfaces, where each interface is thought of as being attached to a 'subnetwork'. (Note that this term is not to be confused with 'subnet' which refers to an addressing partitioning scheme used in the Internet suite of protocols.) This Repeater MIB uses the notion of ports on a repeater. The concept of a MIB-II interface has NO specific relationship to a repeater's port. Therefore, the 'interfaces' group applies only to the one (or more) network interfaces on which the entity managing the repeater sends and receives management protocol operations, and does not apply to the repeater's ports. This is consistent with the physical-layer nature of a repeater. A repeater is a bitwise store-and-forward device. It recognizes activity and bits, but does not process incoming data based on any packet-related information (such as checksum or addresses). A repeater has no MAC address, no MAC implementation, and does not pass packets up to higher-level protocol entities for processing. (When a network management entity is observing a repeater, it may appear as though the repeater is passing packets to a higher-level protocol entity. However, this is only a means of implementing management, and this passing of management information is not part of the repeater functionality.) de Graaf, et. al. Standards Track [Page 5] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 3. Definitions SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Counter64, Integer32, Gauge32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI TimeStamp, DisplayString, MacAddress, TEXTUAL-CONVENTION, RowStatus, TestAndIncr FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF OwnerString FROM IF-MIB; snmpRptrMod MODULE-IDENTITY LAST-UPDATED "9609140000Z" ORGANIZATION "IETF HUB MIB Working Group" CONTACT-INFO "WG E-mail: hubmib@hprnd.rose.hp.com Chair: Dan Romascanu Postal: Madge Networks (Israel) Ltd. Atidim Technology Park, Bldg. 3 Tel Aviv 61131, Israel Tel: 972-3-6458414, 6458458 Fax: 972-3-6487146 E-mail: dromasca@madge.com Editor: Kathryn de Graaf Postal: 3Com Corporation 118 Turnpike Rd. Southborough, MA 01772 USA Tel: (508)229-1627 Fax: (508)490-5882 E-mail: kdegraaf@isd.3com.com" DESCRIPTION "Management information for 802.3 repeaters. The following references are used throughout this MIB module: [IEEE 802.3 Std] refers to IEEE 802.3/ISO 8802-3 Information processing systems - Local area networks - Part 3: Carrier sense multiple access with de Graaf, et. al. Standards Track [Page 6] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 collision detection (CSMA/CD) access method and physical layer specifications (1993). [IEEE 802.3 Mgt] refers to IEEE 802.3u-1995, '10 Mb/s & 100 Mb/s Management, Section 30,' Supplement to ANSI/IEEE 802.3. The following terms are used throughout this MIB module. For complete formal definitions, the IEEE 802.3 standards should be consulted wherever possible: System - A managed entity compliant with this MIB, and incorporating at least one managed 802.3 repeater. Chassis - An enclosure for one managed repeater, part of a managed repeater, or several managed repeaters. It typically contains an integral power supply and a variable number of available module slots. Repeater-unit - The portion of the repeater set that is inboard of the physical media interfaces. The physical media interfaces (MAUs, AUIs) may be physically separated from the repeater-unit, or they may be integrated into the same physical package. Trivial repeater-unit - An isolated port that can gather statistics. Group - A recommended, but optional, entity defined by the IEEE 802.3 management standard, in order to support a modular numbering scheme. The classical example allows an implementor to represent field-replaceable units as groups of ports, with the port numbering matching the modular hardware implementation. System interconnect segment - An internal segment allowing interconnection of ports belonging to different physical entities into the same logical manageable repeater. Examples of implementation might be backplane busses in modular hubs, or chaining cables in stacks of hubs. de Graaf, et. al. Standards Track [Page 7] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 Stack - A scalable system that may include managed repeaters, in which modularity is achieved by interconnecting a number of different chassis. Module - A building block in a modular chassis. It typically maps into one 'slot'; however, the range of configurations may be very large, with several modules entering one slot, or one module covering several slots. " REVISION "9309010000Z" DESCRIPTION "Published as RFC 1516" REVISION "9210010000Z" DESCRIPTION "Published as RFC 1368" ::= { snmpDot3RptrMgt 5 } snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 } OptMacAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Either a 6 octet address in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first if a value is available or a zero length string." REFERENCE "See MacAddress in SNMPv2-TC. The only difference is that a zero length string is allowed as a value for OptMacAddr and not for MacAddress." SYNTAX OCTET STRING (SIZE (0 | 6)) -- Basic information at the repeater, group, and port level. rptrBasicPackage OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 } rptrRptrInfo OBJECT IDENTIFIER ::= { rptrBasicPackage 1 } rptrGroupInfo de Graaf, et. al. Standards Track [Page 8] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 OBJECT IDENTIFIER ::= { rptrBasicPackage 2 } rptrPortInfo OBJECT IDENTIFIER ::= { rptrBasicPackage 3 } rptrAllRptrInfo OBJECT IDENTIFIER ::= { rptrBasicPackage 4 } -- Monitoring information at the repeater, group, and port level. rptrMonitorPackage OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 } rptrMonitorRptrInfo OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 } rptrMonitorGroupInfo OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 } rptrMonitorPortInfo OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 } rptrMonitorAllRptrInfo OBJECT IDENTIFIER ::= { rptrMonitorPackage 4 } -- Address tracking information at the repeater, group, -- and port level. rptrAddrTrackPackage OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 } rptrAddrTrackRptrInfo OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 } rptrAddrTrackGroupInfo -- this subtree is currently unused OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 } rptrAddrTrackPortInfo OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 } -- TopN information. rptrTopNPackage OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 4 } rptrTopNRptrInfo -- this subtree is currently unused OBJECT IDENTIFIER ::= { rptrTopNPackage 1 } rptrTopNGroupInfo -- this subtree is currently unused OBJECT IDENTIFIER ::= { rptrTopNPackage 2 } rptrTopNPortInfo OBJECT IDENTIFIER ::= { rptrTopNPackage 3 } -- Old version of basic information at the repeater level. -- -- In a system containing a single managed repeater, -- configuration, status, and control objects for the overall -- repeater. de Graaf, et. al. Standards Track [Page 9] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 -- -- The objects contained under the rptrRptrInfo subtree are -- intended for backwards compatibility with implementations of -- RFC 1516 [11]. In newer implementations (both single- and -- multiple-repeater implementations) the rptrInfoTable should -- be implemented. It is the preferred source of this information, -- as it contains the values for all repeaters managed by the -- agent. In all cases, the objects in the rptrRptrInfo subtree -- are duplicates of the corresponding objects in the first entry -- of the rptrInfoTable. rptrGroupCapacity OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** The rptrGroupCapacity is the number of groups that can be contained within the repeater. Within each managed repeater, the groups are uniquely numbered in the range from 1 to rptrGroupCapacity. Some groups may not be present in the repeater, in which case the actual number of groups present will be less than rptrGroupCapacity. The number of groups present will never be greater than rptrGroupCapacity. Note: In practice, this will generally be the number of field-replaceable units (i.e., modules, cards, or boards) that can fit in the physical repeater enclosure, and the group numbers will correspond to numbers marked on the physical enclosure." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.1.3, aRepeaterGroupCapacity." ::= { rptrRptrInfo 1 } rptrOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), -- undefined or unknown ok(2), -- no known failures rptrFailure(3), -- repeater-related failure groupFailure(4), -- group-related failure portFailure(5), -- port-related failure generalFailure(6) -- failure, unspecified type de Graaf, et. al. Standards Track [Page 10] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** The rptrOperStatus object indicates the operational state of the repeater. The rptrHealthText object may be consulted for more specific information about the state of the repeater's health. In the case of multiple kinds of failures (e.g., repeater failure and port failure), the value of this attribute shall reflect the highest priority failure in the following order, listed highest priority first: rptrFailure(3) groupFailure(4) portFailure(5) generalFailure(6)." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState." ::= { rptrRptrInfo 2 } rptrHealthText OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** The health text object is a text string that provides information relevant to the operational state of the repeater. Agents may use this string to provide detailed information on current failures, including how they were detected, and/or instructions for problem resolution. The contents are agent-specific." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.1.6, aRepeaterHealthText." ::= { rptrRptrInfo 3 } rptrReset OBJECT-TYPE SYNTAX INTEGER { noReset(1), reset(2) de Graaf, et. al. Standards Track [Page 11] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** Setting this object to reset(2) causes a transition to the START state of Fig 9-2 in section 9 [IEEE 802.3 Std] for a 10Mb/s repeater, and the START state of Fig 27-2 in section 27 of that standard for a 100Mb/s repeater. Setting this object to noReset(1) has no effect. The agent will always return the value noReset(1) when this object is read. After receiving a request to set this variable to reset(2), the agent is allowed to delay the reset for a short period. For example, the implementor may choose to delay the reset long enough to allow the SNMP response to be transmitted. In any event, the SNMP response must be transmitted. This action does not reset the management counters defined in this document nor does it affect the portAdminStatus parameters. Included in this action is the execution of a disruptive Self-Test with the following characteristics: a) The nature of the tests is not specified. b) The test resets the repeater but without affecting management information about the repeater. c) The test does not inject packets onto any segment. d) Packets received during the test may or may not be transferred. e) The test does not interfere with management functions. After performing this self-test, the agent will update the repeater health information (including rptrOperStatus and rptrHealthText), and send a rptrHealth trap." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.2.1, acResetRepeater." ::= { rptrRptrInfo 4 } rptrNonDisruptTest OBJECT-TYPE SYNTAX INTEGER { noSelfTest(1), selfTest(2) de Graaf, et. al. Standards Track [Page 12] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** Setting this object to selfTest(2) causes the repeater to perform a agent-specific, non- disruptive self-test that has the following characteristics: a) The nature of the tests is not specified. b) The test does not change the state of the repeater or management information about the repeater. c) The test does not inject packets onto any segment. d) The test does not prevent the relay of any packets. e) The test does not interfere with management functions. After performing this test, the agent will update the repeater health information (including rptrOperStatus and rptrHealthText) and send a rptrHealth trap. Note that this definition allows returning an 'okay' result after doing a trivial test. Setting this object to noSelfTest(1) has no effect. The agent will always return the value noSelfTest(1) when this object is read." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.2.2, acExecuteNonDisruptiveSelfTest." ::= { rptrRptrInfo 5 } rptrTotalPartitionedPorts OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This object returns the total number of ports in the repeater whose current state meets all three of the following criteria: rptrPortOperStatus does not have the value notPresent(3), rptrPortAdminStatus is enabled(1), and rptrPortAutoPartitionState is autoPartitioned(2)." ::= { rptrRptrInfo 6 } de Graaf, et. al. Standards Track [Page 13] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 -- Basic information at the group level. -- -- Configuration and status objects for each -- managed group in the system, independent -- of whether there is one or more managed -- repeater-units in the system. rptrGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of descriptive and status information about the groups of ports." ::= { rptrGroupInfo 1 } rptrGroupEntry OBJECT-TYPE SYNTAX RptrGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single group of ports." INDEX { rptrGroupIndex } ::= { rptrGroupTable 1 } RptrGroupEntry ::= SEQUENCE { rptrGroupIndex Integer32, rptrGroupDescr DisplayString, rptrGroupObjectID OBJECT IDENTIFIER, rptrGroupOperStatus INTEGER, rptrGroupLastOperStatusChange TimeTicks, rptrGroupPortCapacity Integer32 } rptrGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the group within the de Graaf, et. al. Standards Track [Page 14] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 system for which this entry contains information." REFERENCE "[IEEE 802.3 Mgt], 30.4.2.1.1, aGroupID." ::= { rptrGroupEntry 1 } rptrGroupDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** A textual description of the group. This value should include the full name and version identification of the group's hardware type and indicate how the group is differentiated from other types of groups in the repeater. Plug-in Module, Rev A' or 'Barney Rubble 10BASE-T 4-port SIMM socket Version 2.1' are examples of valid group descriptions. It is mandatory that this only contain printable ASCII characters." ::= { rptrGroupEntry 2 } rptrGroupObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor's authoritative identification of the group. This value may be allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides a straight-forward and unambiguous means for determining what kind of group is being managed. For example, this object could take the value 1.3.6.1.4.1.4242.1.2.14 if vendor 'Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, and had assigned the identifier 1.3.6.1.4.1.4242.1.2.14 to its 'Wilma Flintstone 6-Port FOIRL Plug-in Module.'" ::= { rptrGroupEntry 3 } rptrGroupOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), de Graaf, et. al. Standards Track [Page 15] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 operational(2), malfunctioning(3), notPresent(4), underTest(5), resetInProgress(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "An object that indicates the operational status of the group. A status of notPresent(4) indicates that the group is temporarily or permanently physically and/or logically not a part of the repeater. It is an implementation-specific matter as to whether the agent effectively removes notPresent entries from the table. A status of operational(2) indicates that the group is functioning, and a status of malfunctioning(3) indicates that the group is malfunctioning in some way." ::= { rptrGroupEntry 4 } rptrGroupLastOperStatusChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** An object that contains the value of sysUpTime at the time when the last of the following occurred: 1) the agent cold- or warm-started; 2) the row for the group was created (such as when the group was added to the system); or 3) the value of rptrGroupOperStatus for the group changed. A value of zero indicates that the group's operational status has not changed since the agent last restarted." ::= { rptrGroupEntry 5 } rptrGroupPortCapacity OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only de Graaf, et. al. Standards Track [Page 16] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 STATUS current DESCRIPTION "The rptrGroupPortCapacity is the number of ports that can be contained within the group. Valid range is 1-2147483647. Within each group, the ports are uniquely numbered in the range from 1 to rptrGroupPortCapacity. Some ports may not be present in the system, in which case the actual number of ports present will be less than the value of rptrGroupPortCapacity. The number of ports present in the group will never be greater than the value of rptrGroupPortCapacity. Note: In practice, this will generally be the number of ports on a module, card, or board, and the port numbers will correspond to numbers marked on the physical embodiment." REFERENCE "IEEE 802.3 Mgt, 30.4.2.1.2, aGroupPortCapacity." ::= { rptrGroupEntry 6 } -- Basic information at the port level. -- -- Configuration and status objects for -- each managed repeater port in the system, -- independent of whether there is one or more -- managed repeater-units in the system. rptrPortTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of descriptive and status information about the repeater ports in the system. The number of entries is independent of the number of repeaters in the managed system." ::= { rptrPortInfo 1 } rptrPortEntry OBJECT-TYPE SYNTAX RptrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single port." de Graaf, et. al. Standards Track [Page 17] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 INDEX { rptrPortGroupIndex, rptrPortIndex } ::= { rptrPortTable 1 } RptrPortEntry ::= SEQUENCE { rptrPortGroupIndex Integer32, rptrPortIndex Integer32, rptrPortAdminStatus INTEGER, rptrPortAutoPartitionState INTEGER, rptrPortOperStatus INTEGER, rptrPortRptrId Integer32 } rptrPortGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the group containing the port for which this entry contains information." ::= { rptrPortEntry 1 } rptrPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the port within the group for which this entry contains information. This identifies the port independently from the repeater it may be attached to. The numbering scheme for ports is implementation specific; however, this value can never be greater than rptrGroupPortCapacity for the associated group." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID." ::= { rptrPortEntry 2 } rptrPortAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) de Graaf, et. al. Standards Track [Page 18] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to disabled(2) disables the port. A disabled port neither transmits nor receives. Once disabled, a port must be explicitly enabled to restore operation. A port which is disabled when power is lost or when a reset is exerted shall remain disabled when normal operation resumes. The admin status takes precedence over auto- partition and functionally operates between the auto-partition mechanism and the AUI/PMA. Setting this object to enabled(1) enables the port and exerts a BEGIN on the port's auto-partition state machine. (In effect, when a port is disabled, the value of rptrPortAutoPartitionState for that port is frozen until the port is next enabled. When the port becomes enabled, the rptrPortAutoPartitionState becomes notAutoPartitioned(1), regardless of its pre-disabling state.)" REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.2, aPortAdminState and 30.4.3.2.1, acPortAdminControl." ::= { rptrPortEntry 3 } rptrPortAutoPartitionState OBJECT-TYPE SYNTAX INTEGER { notAutoPartitioned(1), autoPartitioned(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The autoPartitionState flag indicates whether the port is currently partitioned by the repeater's auto-partition protection. The conditions that cause port partitioning are specified in partition state machine in Sections 9 and 27 of [IEEE 802.3 Std]. They are not differentiated here." REFERENCE de Graaf, et. al. Standards Track [Page 19] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 "[IEEE 802.3 Mgt], 30.4.3.1.3, aAutoPartitionState." ::= { rptrPortEntry 4 } rptrPortOperStatus OBJECT-TYPE SYNTAX INTEGER { operational(1), notOperational(2), notPresent(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the port's operational status. The notPresent(3) status indicates the port is physically removed (note this may or may not be possible depending on the type of port.) The operational(1) status indicates that the port is enabled (see rptrPortAdminStatus) and working, even though it might be auto-partitioned (see rptrPortAutoPartitionState). If this object has the value operational(1) and rptrPortAdminStatus is set to disabled(2), it is expected that this object's value will soon change to notOperational(2)." ::= { rptrPortEntry 5 } rptrPortRptrId OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the repeater to which this port belongs. The repeater identified by a particular value of this object is the same as that identified by the same value of rptrInfoId. A value of zero indicates that this port currently is not a member of any repeater." ::= { rptrPortEntry 6 } -- New version of basic information at the repeater level. -- -- Configuration, status, and control objects for -- each managed repeater in the system. rptrInfoTable OBJECT-TYPE de Graaf, et. al. Standards Track [Page 20] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 SYNTAX SEQUENCE OF RptrInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about each non-trivial repeater. The number of entries depends on the physical configuration of the managed system." ::= { rptrAllRptrInfo 1 } rptrInfoEntry OBJECT-TYPE SYNTAX RptrInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single non-trivial repeater." INDEX { rptrInfoId } ::= { rptrInfoTable 1 } RptrInfoEntry ::= SEQUENCE { rptrInfoId Integer32, rptrInfoRptrType INTEGER, rptrInfoOperStatus INTEGER, rptrInfoReset INTEGER, rptrInfoPartitionedPorts Gauge32, rptrInfoLastChange TimeStamp } rptrInfoId OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the repeater for which this entry contains information." ::= { rptrInfoEntry 1 } rptrInfoRptrType OBJECT-TYPE SYNTAX INTEGER { other(1), -- undefined or unknown de Graaf, et. al. Standards Track [Page 21] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 tenMb(2), onehundredMbClassI(3), onehundredMbClassII(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The rptrInfoRptrType returns a value that identifies the CSMA/CD repeater type." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.1.2, aRepeaterType." ::= { rptrInfoEntry 2 } rptrInfoOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), ok(2), failure(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The rptrInfoOperStatus object indicates the operational state of the repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState." ::= { rptrInfoEntry 3 } rptrInfoReset OBJECT-TYPE SYNTAX INTEGER { noReset(1), reset(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to reset(2) causes a transition to the START state of Fig 9-2 in section 9 [IEEE 802.3 Std] for a 10Mb/s repeater, and to the START state of Fig 27-2 in section 27 of that standard for a 100Mb/s repeater. Setting this object to noReset(1) has no effect. The agent will always return the value noReset(1) when this object is read. After receiving a request to set this variable to reset(2), the agent is allowed to delay the reset de Graaf, et. al. Standards Track [Page 22] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 for a short period. For example, the implementor may choose to delay the reset long enough to allow the SNMP response to be transmitted. In any event, the SNMP response must be transmitted. This action does not reset the management counters defined in this document nor does it affect the portAdminStatus parameters. Included in this action is the execution of a disruptive Self-Test with the following characteristics: a) The nature of the tests is not specified. b) The test resets the repeater but without affecting management information about the repeater. c) The test does not inject packets onto any segment. d) Packets received during the test may or may not be transferred. e) The test does not interfere with management functions. After performing this self-test, the agent will update the repeater health information (including rptrInfoOperStatus), and send a rptrInfoResetEvent notification." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.2.1, acResetRepeater." ::= { rptrInfoEntry 4 } rptrInfoPartitionedPorts OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the total number of ports in the repeater whose current state meets all three of the following criteria: rptrPortOperStatus does not have the value notPresent(3), rptrPortAdminStatus is enabled(1), and rptrPortAutoPartitionState is autoPartitioned(2)." ::= { rptrInfoEntry 5 } rptrInfoLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when any of the following conditions occurred: 1) agent cold- or warm-started; 2) this instance of repeater was created de Graaf, et. al. Standards Track [Page 23] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 (such as when a device or module was added to the system); 3) a change in the value of rptrInfoOperStatus; 4) ports were added or removed as members of the repeater; or 5) any of the counters associated with this repeater had a discontinuity." ::= { rptrInfoEntry 6 } -- -- Old version of statistics at the repeater level. -- -- Performance monitoring statistics for the repeater -- -- In a system containing a single managed repeater-unit, -- the statistics object for the repeater-unit. -- The objects contained under the rptrMonitorRptrInfo subtree are -- intended for backwards compatibility with implementations of -- RFC 1516 [11]. In newer implementations (both single- and -- multiple-repeater implementations), the rptrMonitorTable will -- be implemented. It is the preferred source of this information, -- as it contains the values for all repeaters managed by the -- agent. In all cases, the objects in the rptrMonitorRptrInfo -- subtree are duplicates of the corresponding objects in the -- first entry of the rptrMonitorTable. rptrMonitorTransmitCollisions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** For a clause 9 (10Mb/s) repeater, this counter is incremented every time the repeater state machine enters the TRANSMIT COLLISION state from any state other than ONE PORT LEFT (Ref: Fig 9-2 [IEEE 802.3 Std]). For a clause 27 repeater, this counter is incremented every time the repeater core state diagram enters the Jam state as a result of Activity(ALL) > 1 (fig 27-2 [IEEE 802.3 Std]). de Graaf, et. al. Standards Track [Page 24] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 The approximate minimum time for rollover of this counter is 16 hours in a 10Mb/s repeater and 1.6 hours in a 100Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.1.8, aTransmitCollisions." ::= { rptrMonitorRptrInfo 1 } -- Statistics at the group level. -- -- In a system containing a single managed repeater-unit, -- the statistics objects for each group. rptrMonitorGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrMonitorGroupEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** Table of performance and error statistics for the groups within the repeater. The number of entries is the same as that in the rptrGroupTable." ::= { rptrMonitorGroupInfo 1 } rptrMonitorGroupEntry OBJECT-TYPE SYNTAX RptrMonitorGroupEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** An entry in the table, containing total performance and error statistics for a single group. Regular retrieval of the information in this table provides a means of tracking the performance and health of the networked devices attached to this group's ports. The counters in this table are redundant in the sense that they are the summations of information already available through other objects. However, these sums provide a considerable optimization of network management traffic over the otherwise necessary retrieval of the individual counters included in each sum. Note: Group-level counters are de Graaf, et. al. Standards Track [Page 25] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 deprecated in this MIB. It is recommended that management applications instead use the repeater-level counters contained in the rptrMonTable." INDEX { rptrMonitorGroupIndex } ::= { rptrMonitorGroupTable 1 } RptrMonitorGroupEntry ::= SEQUENCE { rptrMonitorGroupIndex Integer32, rptrMonitorGroupTotalFrames Counter32, rptrMonitorGroupTotalOctets Counter32, rptrMonitorGroupTotalErrors Counter32 } rptrMonitorGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This object identifies the group within the repeater for which this entry contains information." ::= { rptrMonitorGroupEntry 1 } rptrMonitorGroupTotalFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** The total number of frames of valid frame length that have been received on the ports in this group and for which the FCSError and CollisionEvent signals were not asserted. This counter is the summation of the values of the rptrMonitorPortReadableFrames counters for all of the ports in the group. This statistic provides one of the parameters necessary for obtaining the packet error rate. de Graaf, et. al. Standards Track [Page 26] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 The approximate minimum time for rollover of this counter is 80 hours in a 10Mb/s repeater." ::= { rptrMonitorGroupEntry 2 } rptrMonitorGroupTotalOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** The total number of octets contained in the valid frames that have been received on the ports in this group. This counter is the summation of the values of the rptrMonitorPortReadableOctets counters for all of the ports in the group. This statistic provides an indicator of the total data transferred. The approximate minimum time for rollover of this counter is 58 minutes in a 10Mb/s repeater." ::= { rptrMonitorGroupEntry 3 } rptrMonitorGroupTotalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** The total number of errors which have occurred on all of the ports in this group. This counter is the summation of the values of the rptrMonitorPortTotalErrors counters for all of the ports in the group." ::= { rptrMonitorGroupEntry 4 } -- Statistics at the port level. -- rptrMonitorPortTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrMonitorPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of performance and error statistics for the ports. The number of entries is the same as that de Graaf, et. al. Standards Track [Page 27] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 in the rptrPortTable. The columnar object rptrMonitorPortLastChange is used to indicate possible discontinuities of counter type columnar objects in the table." ::= { rptrMonitorPortInfo 1 } rptrMonitorPortEntry OBJECT-TYPE SYNTAX RptrMonitorPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing performance and error statistics for a single port." INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex } ::= { rptrMonitorPortTable 1 } RptrMonitorPortEntry ::= SEQUENCE { rptrMonitorPortGroupIndex Integer32, rptrMonitorPortIndex Integer32, rptrMonitorPortReadableFrames Counter32, rptrMonitorPortReadableOctets Counter32, rptrMonitorPortFCSErrors Counter32, rptrMonitorPortAlignmentErrors Counter32, rptrMonitorPortFrameTooLongs Counter32, rptrMonitorPortShortEvents Counter32, rptrMonitorPortRunts Counter32, rptrMonitorPortCollisions Counter32, rptrMonitorPortLateEvents Counter32, rptrMonitorPortVeryLongEvents Counter32, rptrMonitorPortDataRateMismatches Counter32, rptrMonitorPortAutoPartitions Counter32, rptrMonitorPortTotalErrors de Graaf, et. al. Standards Track [Page 28] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 Counter32, rptrMonitorPortLastChange TimeStamp } rptrMonitorPortGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the group containing the port for which this entry contains information." ::= { rptrMonitorPortEntry 1 } rptrMonitorPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the port within the group for which this entry contains information." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID." ::= { rptrMonitorPortEntry 2 } rptrMonitorPortReadableFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the number of frames of valid frame length that have been received on this port. This counter is incremented by one for each frame received on this port whose OctetCount is greater than or equal to minFrameSize and less than or equal to maxFrameSize (Ref: IEEE 802.3 Std, 4.4.2.1) and for which the FCSError and CollisionEvent signals are not asserted. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. This statistic provides one of the parameters necessary for obtaining the packet error rate. The approximate minimum time for rollover of this counter is 80 hours at 10Mb/s." REFERENCE de Graaf, et. al. Standards Track [Page 29] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 "[IEEE 802.3 Mgt], 30.4.3.1.4, aReadableFrames." ::= { rptrMonitorPortEntry 3 } rptrMonitorPortReadableOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the number of octets contained in valid frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which has been determined to be a readable frame (i.e., including FCS octets but excluding framing bits and dribble bits). A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. This statistic provides an indicator of the total data transferred. The approximate minimum time for rollover of this counter in a 10Mb/s repeater is 58 minutes. For ports receiving traffic at a maximum rate in a 100Mb/s repeater, this counter can roll over in less than 6 minutes. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information a management station is advised to also poll the rptrMonitorPortUpper32Octets object, or to use the 64-bit counter defined by rptrMonitorPortHCReadableOctets instead of the two 32-bit counters." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.5, aReadableOctets." ::= { rptrMonitorPortEntry 4 } rptrMonitorPortFCSErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each frame received on this port with the FCSError signal asserted and the FramingError and CollisionEvent signals deasserted and whose OctetCount is greater de Graaf, et. al. Standards Track [Page 30] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 than or equal to minFrameSize and less than or equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std). A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 80 hours at 10Mb/s." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.6, aFrameCheckSequenceErrors." ::= { rptrMonitorPortEntry 5 } rptrMonitorPortAlignmentErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each frame received on this port with the FCSError and FramingError signals asserted and CollisionEvent signal deasserted and whose OctetCount is greater than or equal to minFrameSize and less than or equal to maxFrameSize (Ref: IEEE 802.3 Std, 4.4.2.1). If rptrMonitorPortAlignmentErrors is incremented then the rptrMonitorPortFCSErrors Counter shall not be incremented for the same frame. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 80 hours at 10Mb/s." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.7, aAlignmentErrors." ::= { rptrMonitorPortEntry 6 } rptrMonitorPortFrameTooLongs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each frame received on this port whose OctetCount is greater de Graaf, et. al. Standards Track [Page 31] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std). If rptrMonitorPortFrameTooLongs is incremented then neither the rptrMonitorPortAlignmentErrors nor the rptrMonitorPortFCSErrors counter shall be incremented for the frame. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 61 days in a 10Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.8, aFramesTooLong." ::= { rptrMonitorPortEntry 7 } rptrMonitorPortShortEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each CarrierEvent on this port with ActivityDuration less than ShortEventMaxTime. ShortEventMaxTime is greater than 74 bit times and less than 82 bit times. ShortEventMaxTime has tolerances included to provide for circuit losses between a conformance test point at the AUI and the measurement point within the state machine. Notes: ShortEvents may indicate externally generated noise hits which will cause the repeater to transmit Runts to its other ports, or propagate a collision (which may be late) back to the transmitting DTE and damaged frames to the rest of the network. Implementors may wish to consider selecting the ShortEventMaxTime towards the lower end of the allowed tolerance range to accommodate bit losses suffered through physical channel devices not budgeted for within this standard. The significance of this attribute is different in 10 and 100 Mb/s collision domains. Clause 9 repeaters perform fragment extension of short de Graaf, et. al. Standards Track [Page 32] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 events which would be counted as runts on the interconnect ports of other repeaters. Clause 27 repeaters do not perform fragment extension. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 16 hours in a 10Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.9, aShortEvents." ::= { rptrMonitorPortEntry 8 } rptrMonitorPortRunts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each CarrierEvent on this port that meets one of the following two conditions. Only one test need be made. a) The ActivityDuration is greater than ShortEventMaxTime and less than ValidPacketMinTime and the CollisionEvent signal is deasserted. b) The OctetCount is less than 64, the ActivityDuration is greater than ShortEventMaxTime and the CollisionEvent signal is deasserted. ValidPacketMinTime is greater than or equal to 552 bit times and less than 565 bit times. An event whose length is greater than 74 bit times but less than 82 bit times shall increment either the shortEvents counter or the runts counter but not both. A CarrierEvent greater than or equal to 552 bit times but less than 565 bit times may or may not be counted as a runt. ValidPacketMinTime has tolerances included to provide for circuit losses between a conformance test point at the AUI and the measurement point within the state machine. Runts usually indicate collision fragments, a normal network event. In certain situations associated with large diameter networks a percentage of collision fragments may exceed ValidPacketMinTime. de Graaf, et. al. Standards Track [Page 33] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 16 hours in a 10Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.10, aRunts." ::= { rptrMonitorPortEntry 9 } rptrMonitorPortCollisions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For a clause 9 repeater, this counter is incremented by one for any CarrierEvent signal on any port for which the CollisionEvent signal on this port is asserted. For a clause 27 repeater port the counter increments on entering the Collision Count Increment state of the partition state diagram (fig 27-8 of [IEEE 802.3 Std]). A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 16 hours in a 10Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.11, aCollisions." ::= { rptrMonitorPortEntry 10 } rptrMonitorPortLateEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For a clause 9 repeater port, this counter is incremented by one for each CarrierEvent on this port in which the CollIn(X) variable transitions to the value SQE (Ref: 9.6.6.2, IEEE 802.3 Std) while the ActivityDuration is greater than the LateEventThreshold. For a clause 27 repeater port, this counter is incremented by one on entering the Collision Count Increment state de Graaf, et. al. Standards Track [Page 34] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 of the partition state diagram (fig 27-8) while the ActivityDuration is greater than the LateEvent- Threshold. Such a CarrierEvent is counted twice, as both a collision and as a lateEvent. The LateEventThreshold is greater than 480 bit times and less than 565 bit times. LateEventThreshold has tolerances included to permit an implementation to build a single threshold to serve as both the LateEventThreshold and ValidPacketMinTime threshold. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 81 hours in a 10Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.12, aLateEvents." ::= { rptrMonitorPortEntry 11 } rptrMonitorPortVeryLongEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For a clause 9 repeater port, this counter is incremented by one for each CarrierEvent whose ActivityDuration is greater than the MAU Jabber Lockup Protection timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std). For a clause 27 repeater port, this counter is incremented by one on entry to the Rx Jabber state of the receiver timer state diagram (fig 27-7). Other counters may be incremented as appropriate. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.13, aVeryLongEvents." ::= { rptrMonitorPortEntry 12 } rptrMonitorPortDataRateMismatches OBJECT-TYPE de Graaf, et. al. Standards Track [Page 35] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each frame received by this port that meets all of the conditions required by only one of the following two measurement methods: Measurement method A: 1) The CollisionEvent signal is not asserted (10Mb/s operation) or the Collision Count Increment state of the partition state diagram (fig 27-8 of [IEEE 802.3 Std]) has not been entered (100Mb/s operation). 2) The ActivityDuration is greater than ValidPacketMinTime. 3) The frequency (data rate) is detectably mismatched from the local transmit frequency. Measurement method B: 1) The CollisionEvent signal is not asserted (10Mb/s operation) or the Collision Count Increment state of the partition state diagram (fig 27-8 of [IEEE 802.3 Std]) has not been entered (100Mb/s operation). 2) The OctetCount is greater than 63. 3) The frequency (data rate) is detectably mismatched from the local transmit frequency. The exact degree of mismatch is vendor specific and is to be defined by the vendor for conformance testing. When this event occurs, other counters whose increment conditions were satisfied may or may not also be incremented, at the implementor's discretion. Whether or not the repeater was able to maintain data integrity is beyond the scope of this standard. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.14, aDataRateMismatches." ::= { rptrMonitorPortEntry 13 } rptrMonitorPortAutoPartitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only de Graaf, et. al. Standards Track [Page 36] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 STATUS current DESCRIPTION "This counter is incremented by one for each time the repeater has automatically partitioned this port. The conditions that cause a clause 9 repeater port to partition are specified in the partition state diagram in clause 9 of [IEEE 802.3 Std]. They are not differentiated here. A clause 27 repeater port partitions on entry to the Partition Wait state of the partition state diagram (fig 27-8 in [IEEE 802.3 Std]). A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.15, aAutoPartitions." ::= { rptrMonitorPortEntry 14 } rptrMonitorPortTotalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of errors which have occurred on this port. This counter is the summation of the values of other error counters (for the same port), namely: rptrMonitorPortFCSErrors, rptrMonitorPortAlignmentErrors, rptrMonitorPortFrameTooLongs, rptrMonitorPortShortEvents, rptrMonitorPortLateEvents, rptrMonitorPortVeryLongEvents, rptrMonitorPortDataRateMismatches, and rptrMonitorPortSymbolErrors. This counter is redundant in the sense that it is the summation of information already available through other objects. However, it is included specifically because the regular retrieval of this object as a means of tracking the health of a port provides a considerable optimization of network management traffic over the otherwise necessary de Graaf, et. al. Standards Track [Page 37] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 retrieval of the summed counters. Note that rptrMonitorPortRunts is not included in this total; this is because runts usually indicate collision fragments, a normal network event. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes." ::= { rptrMonitorPortEntry 15 } rptrMonitorPortLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last of the following occurred: 1) the agent cold- or warm-started; 2) the row for the port was created (such as when a device or module was added to the system); or 3) any condition that would cause one of the counters for the row to experience a discontinuity." ::= { rptrMonitorPortEntry 16 } rptrMonitor100PortTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrMonitor100PortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of additional performance and error statistics for 100Mb/s ports, above and beyond those parameters that apply to both 10 and 100Mbps ports. Entries exist only for ports attached to 100Mbps repeaters. The columnar object rptrMonitorPortLastChange is used to indicate possible discontinuities of counter type columnar objects in this table." ::= { rptrMonitorPortInfo 2 } rptrMonitor100PortEntry OBJECT-TYPE SYNTAX RptrMonitor100PortEntry MAX-ACCESS not-accessible STATUS current de Graaf, et. al. Standards Track [Page 38] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 DESCRIPTION "An entry in the table, containing performance and error statistics for a single 100Mb/s port." INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex } ::= { rptrMonitor100PortTable 1 } RptrMonitor100PortEntry ::= SEQUENCE { rptrMonitorPortIsolates Counter32, rptrMonitorPortSymbolErrors Counter32, rptrMonitorPortUpper32Octets Counter32, rptrMonitorPortHCReadableOctets Counter64 } rptrMonitorPortIsolates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one each time that the repeater port automatically isolates as a consequence of false carrier events. The conditions which cause a port to automatically isolate are defined by the transition from the False Carrier state to the Link Unstable state of the carrier integrity state diagram (figure 27-9) [IEEE 802.3 Standard]. Note: Isolates do not affect the value of the PortOperStatus object. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.16, aIsolates." ::= { rptrMonitor100PortEntry 1 } rptrMonitorPortSymbolErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one each time when de Graaf, et. al. Standards Track [Page 39] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 valid length packet was received at the port and there was at least one occurrence of an invalid data symbol. This can increment only once per valid carrier event. A collision presence at any port of the repeater containing port N, will not cause this attribute to increment. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 7.4 hours at 100Mb/s." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.17, aSymbolErrorDuringPacket." ::= { rptrMonitor100PortEntry 2 } rptrMonitorPortUpper32Octets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the number of octets contained in valid frames that have been received on this port, modulo 2**32. That is, it contains the upper 32 bits of a 64-bit octets counter, of which the lower 32 bits are contained in the rptrMonitorPortReadableOctets object. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMP V1) and are used to manage a repeater type of 100Mb/s. Conformance clauses for this MIB are defined such that implementation of this object is not required in a system which does not support 100Mb/s. However, systems with mixed 10 and 100Mb/s ports may implement this object across all ports, including 10Mb/s. If this object is implemented, it must be according to the definition in the first paragraph of this description; that is, the value of this object MUST be a valid count. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes." de Graaf, et. al. Standards Track [Page 40] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 ::= { rptrMonitor100PortEntry 3 } rptrMonitorPortHCReadableOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the number of octets contained in valid frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which has been determined to be a readable frame (i.e., including FCS octets but excluding framing bits and dribble bits). This statistic provides an indicator of the total data transferred. This counter is a 64-bit version of rptrMonitor- PortReadableOctets. It should be used by network management protocols which suppport 64-bit counters (e.g. SNMPv2). Conformance clauses for this MIB are defined such that implementation of this object is not required in a system which does not support 100Mb/s. However, systems with mixed 10 and 100Mb/s ports may implement this object across all ports, including 10Mb/s. If this object is implemented, it must be according to the definition in the first paragraph of this description; that is, the value of this object MUST be a valid count. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.5, aReadableOctets." ::= { rptrMonitor100PortEntry 4 } -- New version of statistics at the repeater level. -- -- Statistics objects for each managed repeater -- in the system. rptrMonTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrMonEntry de Graaf, et. al. Standards Track [Page 41] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about each non-trivial repeater. The number of entries in this table is the same as the number of entries in the rptrInfoTable. The columnar object rptrInfoLastChange is used to indicate possible discontinuities of counter type columnar objects in this table." ::= { rptrMonitorAllRptrInfo 1 } rptrMonEntry OBJECT-TYPE SYNTAX RptrMonEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single non-trivial repeater." INDEX { rptrInfoId } ::= { rptrMonTable 1 } RptrMonEntry ::= SEQUENCE { rptrMonTxCollisions Counter32, rptrMonTotalFrames Counter32, rptrMonTotalErrors Counter32, rptrMonTotalOctets Counter32 } rptrMonTxCollisions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For a clause 9 (10Mb/s) repeater, this counter is incremented every time the repeater state machine enters the TRANSMIT COLLISION state from any state other than ONE PORT LEFT (Ref: Fig 9-2 [IEEE 802.3 Std]). For a clause 27 repeater, this counter is incremented every time the repeater core state de Graaf, et. al. Standards Track [Page 42] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 diagram enters the Jam state as a result of Activity(ALL) > 1 (fig 27-2 [IEEE 802.3 Std]). The approximate minimum time for rollover of this counter is 16 hours in a 10Mb/s repeater and 1.6 hours in a 100Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.1.8, aTransmitCollisions" ::= { rptrMonEntry 1 } rptrMonTotalFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames of valid frame length that have been received on the ports in this repeater and for which the FCSError and CollisionEvent signals were not asserted. If an implementation can not obtain a count of frames as seen by the repeater itself, this counter may be implemented as the summation of the values of the rptrMonitorPortReadableFrames counters for all of the ports in the repeater. This statistic provides one of the parameters necessary for obtaining the packet error rate. The approximate minimum time for rollover of this counter is 80 hours in a 10Mb/s repeater." ::= { rptrMonEntry 3 } rptrMonTotalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of errors which have occurred on all of the ports in this repeater. The errors included in this count are the same as those listed for the rptrMonitorPortTotalErrors counter. If an implementation can not obtain a count of these errors as seen by the repeater itself, this counter may be implemented as the summation of the values of the rptrMonitorPortTotalErrors counters for all of the ports in the repeater." ::= { rptrMonEntry 4 } rptrMonTotalOctets OBJECT-TYPE de Graaf, et. al. Standards Track [Page 43] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets contained in the valid frames that have been received on the ports in this group. If an implementation can not obtain a count of octets as seen by the repeater itself, this counter may be the summation of the values of the rptrMonitorPortReadableOctets counters for all of the ports in the group. This statistic provides an indicator of the total data transferred. The approximate minimum time for rollover of this counter in a 10Mb/s repeater is 58 minutes divided by the number of ports in the repeater. For 100Mb/s repeaters processing traffic at a maximum rate, this counter can roll over in less than 6 minutes divided by the number of ports in the repeater. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information a management station is advised to also poll the rptrMonUpper32TotalOctets object, or to use the 64-bit counter defined by rptrMonHCTotalOctets instead of the two 32-bit counters." ::= { rptrMonEntry 5 } rptrMon100Table OBJECT-TYPE SYNTAX SEQUENCE OF RptrMon100Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of additional information about each 100Mb/s repeater, augmenting the entries in the rptrMonTable. Entries exist in this table only for 100Mb/s repeaters. The columnar object rptrInfoLastChange is used to indicate possible discontinuities of counter type columnar objects in this table." ::= { rptrMonitorAllRptrInfo 2 } rptrMon100Entry OBJECT-TYPE SYNTAX RptrMon100Entry MAX-ACCESS not-accessible de Graaf, et. al. Standards Track [Page 44] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 STATUS current DESCRIPTION "An entry in the table, containing information about a single 100Mbps repeater." INDEX { rptrInfoId } ::= { rptrMon100Table 1 } RptrMon100Entry ::= SEQUENCE { rptrMonUpper32TotalOctets Counter32, rptrMonHCTotalOctets Counter64 } rptrMonUpper32TotalOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets contained in the valid frames that have been received on the ports in this repeater, modulo 2**32. That is, it contains the upper 32 bits of a 64-bit counter, of which the lower 32 bits are contained in the rptrMonTotalOctets object. If an implementation can not obtain a count of octets as seen by the repeater itself, the 64-bit value may be the summation of the values of the rptrMonitorPortReadableOctets counters combined with the corresponding rptrMonitorPortUpper32Octets counters for all of the ports in the repeater. This statistic provides an indicator of the total data transferred within the repeater. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMP V1) and are used to manage a repeater type of 100Mb/s. Conformance clauses for this MIB are defined such that implementation of this object is not required in a system which does not support 100Mb/s. However, systems with mixed 10 and 100Mb/s ports may implement this object across all ports, including 10Mb/s. If this object is implemented, it must be according to the definition in the first de Graaf, et. al. Standards Track [Page 45] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 paragraph of this description; that is, the value of this object MUST be a valid count." ::= { rptrMon100Entry 1 } rptrMonHCTotalOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets contained in the valid frames that have been received on the ports in this group. If a implementation can not obtain a count of octets as seen by the repeater itself, this counter may be the summation of the values of the rptrMonitorPortReadableOctets counters for all of the ports in the group. This statistic provides an indicator of the total data transferred. This counter is a 64-bit (high-capacity) version of rptrMonUpper32TotalOctets and rptrMonTotalOctets. It should be used by network management protocols which support 64-bit counters (e.g. SNMPv2). Conformance clauses for this MIB are defined such that implementation of this object is not required in a system which does not support 100Mb/s. However, systems with mixed 10 and 100Mb/s ports may implement this object across all ports, including 10Mb/s. If this object is implemented, it must be according to the definition in the first paragraph of this description; that is, the value of this object MUST be a valid count." ::= { rptrMon100Entry 2 } -- -- The Repeater Address Search Table -- -- This table provides an active address tracking -- capability which can be also used to collect the -- necessary information for mapping the topology -- of a network. Note that an NMS is required to have -- read-write access to the table in order to access -- this function. Section 4, "Topology Mapping", -- contains a description of an algorithm which can -- make use of this table, in combination with the de Graaf, et. al. Standards Track [Page 46] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 -- forwarding databases of managed bridges/switches -- in the network, to map network topology. -- rptrAddrSearchTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrAddrSearchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one entry per repeater in the system. It defines objects which allow a network management application to instruct an agent to watch for a given MAC address and report which port it was seen on. Only one address search can be in progress on each repeater at any one time. Before starting an address search, a management application should obtain 'ownership' of the entry in rptrAddrSearchTable for the repeater that is to perform the search. This is accomplished with the rptrAddrSearchLock and rptrAddrSearchStatus as follows: try_again: get(rptrAddrSearchLock, rptrAddrSearchStatus) while (rptrAddrSearchStatus != notInUse) { /* Loop waiting for objects to be available*/ short delay get(rptrAddrSearchLock, rptrAddrSearchStatus) } /* Try to claim map objects */ lock_value = rptrAddrSearchLock if ( set(rptrAddrSearchLock = lock_value, rptrAddrSearchStatus = inUse, rptrAddrSearchOwner = 'my-IP-address) == FAILURE) /* Another manager got the lock */ goto try_again /* I have the lock */ set (rptrAddrSearchAddress = ) wait for rptrAddrSearchState to change from none if (rptrAddrSearchState == single) get (rptrAddrSearchGroup, rptrAddrSearchPort) de Graaf, et. al. Standards Track [Page 47] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 /* release the lock, making sure not to overwrite anyone else's lock */ set (rptrAddrSearchLock = lock_value+1, rptrAddrSearchStatus = notInUse, rptrAddrSearchOwner = '') A management station first retrieves the values of the appropriate instances of the rptrAddrSearchLock and rptrAddrSearchStatus objects, periodically repeating the retrieval if necessary, until the value of rptrAddrSearchStatus is 'notInUse'. The management station then tries to set the same instance of the rptrAddrSearchLock object to the value it just retrieved, the same instance of the rptrAddrSearchStatus object to 'inUse', and the corresponding instance of rptrAddrSearchOwner to a value indicating itself. If the set operation succeeds, then the management station has obtained ownership of the rptrAddrSearchEntry, and the value of rptrAddrSearchLock is incremented by the agent (as per the semantics of TestAndIncr). Failure of the set operation indicates that some other manager has obtained ownership of the rptrAddrSearchEntry. Once ownership is obtained, the management station can proceed with the search operation. Note that the agent will reset rptrAddrSearchStatus to 'notInUse' if it has been in the 'inUse' state for an abnormally long period of time, to prevent a misbehaving manager from permanently locking the entry. It is suggested that this timeout period be between one and five minutes. When the management station has completed its search operation, it should free the entry by setting the instance of the rptrAddrSearchLock object to the previous value + 1, the instance of the rptrAddrSearchStatus to 'notInUse', and the instance of rptrAddrSearchOwner to a zero length string. This is done to prevent overwriting another station's lock." ::= { rptrAddrTrackRptrInfo 1 } rptrAddrSearchEntry OBJECT-TYPE SYNTAX RptrAddrSearchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION de Graaf, et. al. Standards Track [Page 48] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 "An entry containing objects for invoking an address search on a repeater." INDEX { rptrInfoId } ::= { rptrAddrSearchTable 1 } RptrAddrSearchEntry ::= SEQUENCE { rptrAddrSearchLock TestAndIncr, rptrAddrSearchStatus INTEGER, rptrAddrSearchAddress MacAddress, rptrAddrSearchState INTEGER, rptrAddrSearchGroup Integer32, rptrAddrSearchPort Integer32, rptrAddrSearchOwner OwnerString } rptrAddrSearchLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used by a management station as an advisory lock for this rptrAddrSearchEntry." ::= { rptrAddrSearchEntry 1 } rptrAddrSearchStatus OBJECT-TYPE SYNTAX INTEGER { notInUse(1), inUse(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to indicate that some management station is currently using this rptrAddrSearchEntry. Cooperating managers should set this object to 'notInUse' when they are finished using this entry. The agent will automatically set the value of this object to 'notInUse' if it has been set to 'inUse' for an unusually long period of time." ::= { rptrAddrSearchEntry 2 } rptrAddrSearchAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION de Graaf, et. al. Standards Track [Page 49] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 "This object is used to search for a specified MAC address. When this object is set, an address search begins. This automatically sets the corresponding instance of the rptrAddrSearchState object to 'none' and the corresponding instances of the rptrAddrSearchGroup and rptrAddrSearchPort objects to 0. When a valid frame is received by this repeater with a source MAC address which matches the current value of rptrAddrSearchAddress, the agent will update the corresponding instances of rptrAddrSearchState, rptrAddrSearchGroup and rptrAddrSearchPort to reflect the current status of the search, and the group and port on which the frame was seen." ::= { rptrAddrSearchEntry 3 } rptrAddrSearchState OBJECT-TYPE SYNTAX INTEGER { none(1), single(2), multiple(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the MAC address search on this repeater. This object is initialized to 'none' when the corresponding instance of rptrAddrSearchAddress is set. If the agent detects the address on exactly one port, it will set this object to 'single', and set the corresponding instances of rptrAddrSearchGroup and rptrAddrSearchPort to reflect the group and port on which the address was heard. If the agent detects the address on more than one port, it will set this object to 'multiple'." ::= { rptrAddrSearchEntry 4 } rptrAddrSearchGroup OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The group from which an error-free frame whose source address is equal to the corresponding instance of rptrAddrSearchAddress has been received. The value of this object is undefined when the corresponding instance of rptrAddrSearchState is de Graaf, et. al. Standards Track [Page 50] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 equal to 'none' or 'multiple'." ::= { rptrAddrSearchEntry 5 } rptrAddrSearchPort OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The port rom which an error-free frame whose source address is equal to the corresponding instance of rptrAddrSearchAddress has been received. The value of this object is undefined when the corresponding instance of rptrAddrSearchState is equal to 'none' or 'multiple'." ::= { rptrAddrSearchEntry 6 } rptrAddrSearchOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS current DESCRIPTION "The entity which currently has 'ownership' of this rptrAddrSearchEntry." ::= { rptrAddrSearchEntry 7 } -- -- The Port Address Tracking Table -- -- This table provides a way for a network management -- application to passively gather information (using -- read-only privileges) about which network addresses -- are connected to which ports of a repeater. -- rptrAddrTrackTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrAddrTrackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of address mapping information about the ports." ::= { rptrAddrTrackPortInfo 1 } rptrAddrTrackEntry OBJECT-TYPE SYNTAX RptrAddrTrackEntry MAX-ACCESS not-accessible STATUS current de Graaf, et. al. Standards Track [Page 51] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 DESCRIPTION "An entry in the table, containing address mapping information about a single port." INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex } ::= { rptrAddrTrackTable 1 } RptrAddrTrackEntry ::= SEQUENCE { rptrAddrTrackGroupIndex INTEGER, rptrAddrTrackPortIndex INTEGER, rptrAddrTrackLastSourceAddress -- DEPRECATED OBJECT MacAddress, rptrAddrTrackSourceAddrChanges Counter32, rptrAddrTrackNewLastSrcAddress OptMacAddr, rptrAddrTrackCapacity Integer32 } rptrAddrTrackGroupIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the group containing the port for which this entry contains information." ::= { rptrAddrTrackEntry 1 } rptrAddrTrackPortIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the port within the group for which this entry contains information." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID." ::= { rptrAddrTrackEntry 2 } rptrAddrTrackLastSourceAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** de Graaf, et. al. Standards Track [Page 52] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 This object is the SourceAddress of the last readable frame (i.e., counted by rptrMonitorPortReadableFrames) received by this port. This object has been deprecated because its value is undefined when no frames have been observed on this port. The replacement object is rptrAddrTrackNewLastSrcAddress." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.18, aLastSourceAddress." ::= { rptrAddrTrackEntry 3 } rptrAddrTrackSourceAddrChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one for each time that the rptrAddrTrackLastSourceAddress attribute for this port has changed. This may indicate whether a link is connected to a single DTE or another multi-user segment. A discontinuity may occur in the value when the value of object rptrMonitorPortLastChange changes. The approximate minimum time for rollover of this counter is 81 hours in a 10Mb/s repeater." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.19, aSourceAddressChanges." ::= { rptrAddrTrackEntry 4 } rptrAddrTrackNewLastSrcAddress OBJECT-TYPE SYNTAX OptMacAddr MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the SourceAddress of the last readable frame (i.e., counted by rptrMonitorPortReadableFrames) received by this port. If no frames have been received by this port since the agent began monitoring the port activity, the agent shall return a string of length zero." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.18, aLastSourceAddress." de Graaf, et. al. Standards Track [Page 53] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 ::= { rptrAddrTrackEntry 5 } rptrAddrTrackCapacity OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of addresses that can be detected on this port. This value indicates to the maximum number of entries in the rptrExtAddrTrackTable relative to this port. If this object has the value of 1, the agent implements only the LastSourceAddress mechanism described by RFC 1368 or RFC 1516." ::= { rptrAddrTrackEntry 6 } -- Table for multiple addresses per port rptrExtAddrTrackTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrExtAddrTrackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table to extend the address tracking table (i.e., rptrAddrTrackTable) with a list of source MAC addresses that were recently received on each port. The number of ports is the same as the number of entries in table rptrPortTable. The number of entries in this table depends on the agent/repeater implementation and the number of different addresses received on each port. The first entry for each port contains the same MAC address that is given by the rptrAddrTrackNewLastSrcAddress for that port. Entries in this table for a particular port are retained when that port is switched from one repeater to another. The ordering of MAC addresses listed for a particular port is implementation dependent." ::= { rptrAddrTrackPortInfo 2 } rptrExtAddrTrackEntry OBJECT-TYPE SYNTAX RptrExtAddrTrackEntry de Graaf, et. al. Standards Track [Page 54] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the table of extended address tracking information for ports. Entries can not be directly created or deleted via SNMP operations." INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex, rptrExtAddrTrackMacIndex } ::= { rptrExtAddrTrackTable 1 } RptrExtAddrTrackEntry ::= SEQUENCE { rptrExtAddrTrackMacIndex Integer32, rptrExtAddrTrackSourceAddress MacAddress } rptrExtAddrTrackMacIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index of a source MAC address seen on the port. The ordering of MAC addresses listed for a particular port is implementation dependent. There is no implied relationship between a particular index and a particular MAC address. The index for a particular MAC address may change without notice." ::= { rptrExtAddrTrackEntry 1 } rptrExtAddrTrackSourceAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The source MAC address from a readable frame (i.e., counted by rptrMonitorPortReadableFrames) recently received by the port." REFERENCE "[IEEE 802.3 Mgt], 30.4.3.1.18, aLastSourceAddress." ::= { rptrExtAddrTrackEntry 2 } -- The Repeater Top "N" Port Group de Graaf, et. al. Standards Track [Page 55] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 -- The Repeater Top N Port group is used to prepare reports that -- describe a list of ports ordered by one of the statistics in the -- Repeater Monitor Port Table. The statistic chosen by the -- management station is sampled over a management -- station-specified time interval, making the report rate based. -- The management station also specifies the number of ports that -- are reported. -- -- The rptrTopNPortControlTable is used to initiate the generation -- of a report. The management station may select the parameters -- of such a report, such as which repeater, which statistic, how -- many ports, and the start & stop times of the sampling. When -- the report is prepared, entries are created in the -- rptrTopNPortTable associated with the relevent -- rptrTopNControlEntry. These entries are static for -- each report after it has been prepared. -- Note that counter discontinuities may appear in some -- implementations if ports' assignment to repeaters changes -- during the collection of data for a Top "N" report. -- A management application could read the corresponding -- rptrMonitorPortLastChange timestamp in order to check -- whether a discontinuity occurred. rptrTopNPortControlTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrTopNPortControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control records for reports on the top `N' ports for the rate of a selected counter. The number of entries depends on the configuration of the agent. The maximum number of entries is implementation dependent." ::= { rptrTopNPortInfo 1 } rptrTopNPortControlEntry OBJECT-TYPE SYNTAX RptrTopNPortControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N ports according to several metrics." INDEX { rptrTopNPortControlIndex } ::= { rptrTopNPortControlTable 1 } RptrTopNPortControlEntry ::= SEQUENCE { de Graaf, et. al. Standards Track [Page 56] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 rptrTopNPortControlIndex Integer32, rptrTopNPortRepeaterId Integer32, rptrTopNPortRateBase INTEGER, rptrTopNPortTimeRemaining Integer32, rptrTopNPortDuration Integer32, rptrTopNPortRequestedSize Integer32, rptrTopNPortGrantedSize Integer32, rptrTopNPortStartTime TimeStamp, rptrTopNPortOwner OwnerString, rptrTopNPortRowStatus RowStatus } rptrTopNPortControlIndex OBJECT-TYPE SYNTAX Integer32 (1 .. 65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the rptrTopNPortControl table. Each such entry defines one top N report prepared for a repeater or system." ::= { rptrTopNPortControlEntry 1 } rptrTopNPortRepeaterId OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the repeater for which a top N report will be prepared (see rptrInfoId). If the value of this object is positive, only ports assigned to this repeater will be used to form the list in which to order the Top N table. If this value is zero, all ports will be eligible for inclusion on the list. The value of this object may not be modified if the associated rptrTopNPortRowStatus object is equal to active(1). de Graaf, et. al. Standards Track [Page 57] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 If, for a particular row in this table, the repeater specified by the value of this object goes away (is removed from the rptrInfoTable) while the associated rptrTopNPortRowStatus object is equal to active(1), the row in this table is preserved by the agent but the value of rptrTopNPortRowStatus is changed to notInService(2), and the agent may time out the row if appropriate. If the specified repeater comes back (reappears in the rptrInfoTable) before the row has been timed out, the management station must set the value of the rptrTopNPortRowStatus object back to active(1) if desired (the agent doesn't do this automatically)." ::= { rptrTopNPortControlEntry 2 } rptrTopNPortRateBase OBJECT-TYPE SYNTAX INTEGER { readableFrames(1), readableOctets(2), fcsErrors(3), alignmentErrors(4), frameTooLongs(5), shortEvents(6), runts(7), collisions(8), lateEvents(9), veryLongEvents(10), dataRateMismatches(11), autoPartitions(12), totalErrors(13), isolates(14), symbolErrors(15) } MAX-ACCESS read-create STATUS current DESCRIPTION "The monitored variable, which the rptrTopNPortRate variable is based upon. The value of this object may not be modified if the associated rptrTopNPortRowStatus object has a value of active(1)." ::= { rptrTopNPortControlEntry 3 } rptrTopNPortTimeRemaining OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current de Graaf, et. al. Standards Track [Page 58] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report, which is loaded into the associated rptrTopNPortDuration object. When this object is set to a non-zero value, any associated rptrTopNPortEntries shall be made inaccessible by the agent. While the value of this object is non-zero, it decrements by one per second until it reaches zero. During this time, all associated rptrTopNPortEntries shall remain inaccessible. At the time that this object decrements to zero, the report is made accessible in the rptrTopNPortTable. Thus, the rptrTopNPort table needs to be created only at the end of the collection interval. If the value of this object is set to zero while the associated report is running, the running report is aborted and no associated rptrTopNPortEntries are created." DEFVAL { 0 } ::= { rptrTopNPortControlEntry 4 } rptrTopNPortDuration OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval, or if this report is currently being collected, the number of seconds that this report is being collected during this sampling interval. When the associated rptrTopNPortTimeRemaining object is set, this object shall be set by the agent to the same value and shall not be modified until the next time the rptrTopNPortTimeRemaining is set. This value shall be zero if no reports have been requested for this rptrTopNPortControlEntry." de Graaf, et. al. Standards Track [Page 59] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 ::= { rptrTopNPortControlEntry 5 } rptrTopNPortRequestedSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of repeater ports requested for the Top N Table. When this object is created or modified, the agent should set rptrTopNPortGrantedSize as close to this object as is possible for the particular implementation and available resources." DEFVAL { 10 } ::= { rptrTopNPortControlEntry 6 } rptrTopNPortGrantedSize OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of repeater ports in the top N table. When the associated rptrTopNPortRequestedSize object is created or modified, the agent should set this object as closely to the requested value as is possible for the particular implementation and available resources. The agent must not lower this value except as a result of a set to the associated rptrTopNPortRequestedSize object." ::= { rptrTopNPortControlEntry 7 } rptrTopNPortStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this top N report was last started. In other words, this is the time that the associated rptrTopNPortTimeRemaining object was modified to start the requested report. If the report has not yet been started, the value of this object is zero." ::= { rptrTopNPortControlEntry 8 } rptrTopNPortOwner OBJECT-TYPE de Graaf, et. al. Standards Track [Page 60] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is using the resources assigned to it." ::= { rptrTopNPortControlEntry 9 } rptrTopNPortRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. If the value of this object is not equal to active(1), all associated entries in the rptrTopNPortTable shall be deleted by the agent." ::= { rptrTopNPortControlEntry 10 } -- Top "N" reports rptrTopNPortTable OBJECT-TYPE SYNTAX SEQUENCE OF RptrTopNPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of reports for the top `N' ports based on setting of associated control table entries. The maximum number of entries depends on the number of entries in table rptrTopNPortControlTable and the value of object rptrTopNPortGrantedSize for each entry. For each entry in the rptrTopNPortControlTable, repeater ports with the highest value of rptrTopNPortRate shall be placed in this table in decreasing order of that rate until there is no more room or until there are no more ports." ::= { rptrTopNPortInfo 2 } rptrTopNPortEntry OBJECT-TYPE SYNTAX RptrTopNPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION de Graaf, et. al. Standards Track [Page 61] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 "A set of statistics for a repeater port that is part of a top N report." INDEX { rptrTopNPortControlIndex, rptrTopNPortIndex } ::= { rptrTopNPortTable 1 } RptrTopNPortEntry ::= SEQUENCE { rptrTopNPortIndex Integer32, rptrTopNPortGroupIndex Integer32, rptrTopNPortPortIndex Integer32, rptrTopNPortRate Gauge32 } rptrTopNPortIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the rptrTopNPort table among those in the same report. This index is between 1 and N, where N is the number of entries in this report. Increasing values of rptrTopNPortIndex shall be assigned to entries with decreasing values of rptrTopNPortRate until index N is assigned to the entry with the lowest value of rptrTopNPortRate or there are no more rptrTopNPortEntries. No ports are included in a report where their value of rptrTopNPortRate would be zero." ::= { rptrTopNPortEntry 1 } rptrTopNPortGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifes the group containing the port for this entry. (See also object type rptrGroupIndex.)" ::= { rptrTopNPortEntry 2 } rptrTopNPortPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) de Graaf, et. al. Standards Track [Page 62] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the repeater port. (See object type rptrPortIndex.)" ::= { rptrTopNPortEntry 3 } rptrTopNPortRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval for the identified port. The selected variable is that port's instance of the object selected by rptrTopNPortRateBase." ::= { rptrTopNPortEntry 4 } -- Notifications for use by Repeaters rptrHealth NOTIFICATION-TYPE OBJECTS { rptrOperStatus } STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** In a system containing a single managed repeater, the rptrHealth notification conveys information related to the operational status of the repeater. It is sent either when the value of rptrOperStatus changes, or upon completion of a non-disruptive test. The rptrHealth notification must contain the rptrOperStatus object. The agent may optionally include the rptrHealthText object in the varBind list. See the rptrOperStatus and rptrHealthText objects for descriptions of the information that is sent. The agent must throttle the generation of consecutive rptrHealth traps so that there is at least a five-second gap between traps of this type. When traps are throttled, they are dropped, not queued for sending at a future time. (Note de Graaf, et. al. Standards Track [Page 63] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 that 'generating' a trap means sending to all configured recipients.)" REFERENCE "[IEEE 802.3 Mgt], 30.4.1.3.1, nRepeaterHealth notification." ::= { snmpDot3RptrMgt 0 1 } rptrGroupChange NOTIFICATION-TYPE OBJECTS { rptrGroupIndex } STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** In a system containing a single managed repeater, this notification is sent when a change occurs in the group structure of the repeater. This occurs only when a group is logically or physically removed from or added to a repeater. The varBind list contains the identifier of the group that was removed or added. The agent must throttle the generation of consecutive rptrGroupChange traps for the same group so that there is at least a five-second gap between traps of this type. When traps are throttled, they are dropped, not queued for sending at a future time. (Note that 'generating' a trap means sending to all configured recipients.)" REFERENCE "[IEEE 802.3 Mgt], 30.4.1.3.3, nGroupMapChange notification." ::= { snmpDot3RptrMgt 0 2 } rptrResetEvent NOTIFICATION-TYPE OBJECTS { rptrOperStatus } STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** In a system containing a single managed repeater-unit, the rptrResetEvent notification conveys information related to the operational status of the repeater. This trap is sent on completion of a repeater reset action. A repeater reset action is defined as an a transition to the START state of Fig 9-2 in section 9 [IEEE 802.3 Std], when triggered by a management command (e.g., an SNMP Set on the de Graaf, et. al. Standards Track [Page 64] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 rptrReset object). The agent must throttle the generation of consecutive rptrResetEvent traps so that there is at least a five-second gap between traps of this type. When traps are throttled, they are dropped, not queued for sending at a future time. (Note that 'generating' a trap means sending to all configured recipients.) The rptrResetEvent trap is not sent when the agent restarts and sends an SNMP coldStart or warmStart trap. However, it is recommended that a repeater agent send the rptrOperStatus object as an optional object with its coldStart and warmStart trap PDUs. The rptrOperStatus object must be included in the varbind list sent with this trap. The agent may optionally include the rptrHealthText object as well." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.3.2, nRepeaterReset notification." ::= { snmpDot3RptrMgt 0 3 } -- Notifications for repeaters in a multiple-repeater implementation. -- An implementation may send either the single-repeater OR -- multiple-repeater version of these notifications (1 or 4; 2 or 5) -- but not both. rptrInfoHealth NOTIFICATION-TYPE OBJECTS { rptrInfoOperStatus } STATUS current DESCRIPTION "In a system containing multiple managed repeaters, the rptrInfoHealth notification conveys information related to the operational status of a repeater. It is sent either when the value of rptrInfoOperStatus changes, or upon completion of a non-disruptive test. The agent must throttle the generation of consecutive rptrInfoHealth notifications for the same repeater so that there is at least a five-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time. (Note de Graaf, et. al. Standards Track [Page 65] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 that 'generating' a notification means sending to all configured recipients.)" REFERENCE "[IEEE 802.3 Mgt], 30.4.1.3.1, nRepeaterHealth notification." ::= { snmpDot3RptrMgt 0 4 } rptrInfoResetEvent NOTIFICATION-TYPE OBJECTS { rptrInfoOperStatus } STATUS current DESCRIPTION "In a system containing multiple managed repeaters, the rptrInfoResetEvent notification conveys information related to the operational status of a repeater. This notification is sent on completion of a repeater reset action. A repeater reset action is defined as a transition to the START state of Fig 9-2 in section 9 of [IEEE 802.3 Std], when triggered by a management command (e.g., an SNMP Set on the rptrInfoReset object). The agent must throttle the generation of consecutive rptrInfoResetEvent notifications for a single repeater so that there is at least a five-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time. (Note that 'generating' a notification means sending to all configured recipients.) The rptrInfoResetEvent is not sent when the agent restarts and sends an SNMP coldStart or warmStart trap. However, it is recommended that a repeater agent send the rptrInfoOperStatus object as an optional object with its coldStart and warmStart trap PDUs." REFERENCE "[IEEE 802.3 Mgt], 30.4.1.3.2, nRepeaterReset notification." ::= { snmpDot3RptrMgt 0 5 } -- Conformance information snmpRptrModConf OBJECT IDENTIFIER ::= { snmpRptrMod 1 } de Graaf, et. al. Standards Track [Page 66] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 snmpRptrModCompls OBJECT IDENTIFIER ::= { snmpRptrModConf 1 } snmpRptrModObjGrps OBJECT IDENTIFIER ::= { snmpRptrModConf 2 } snmpRptrModNotGrps OBJECT IDENTIFIER ::= { snmpRptrModConf 3 } -- Object groups snmpRptrGrpBasic1516 OBJECT-GROUP OBJECTS { rptrGroupCapacity, rptrOperStatus, rptrHealthText, rptrReset, rptrNonDisruptTest, rptrTotalPartitionedPorts, rptrGroupIndex, rptrGroupDescr, rptrGroupObjectID, rptrGroupOperStatus, rptrGroupLastOperStatusChange, rptrGroupPortCapacity, rptrPortGroupIndex, rptrPortIndex, rptrPortAdminStatus, rptrPortAutoPartitionState, rptrPortOperStatus } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** Basic group from RFCs 1368 and 1516. NOTE: this object group is DEPRECATED and replaced with snmpRptrGrpBasic." ::= { snmpRptrModObjGrps 1 } snmpRptrGrpMonitor1516 OBJECT-GROUP OBJECTS { rptrMonitorTransmitCollisions, rptrMonitorGroupIndex, rptrMonitorGroupTotalFrames, rptrMonitorGroupTotalOctets, rptrMonitorGroupTotalErrors, de Graaf, et. al. Standards Track [Page 67] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 rptrMonitorPortGroupIndex, rptrMonitorPortIndex, rptrMonitorPortReadableFrames, rptrMonitorPortReadableOctets, rptrMonitorPortFCSErrors, rptrMonitorPortAlignmentErrors, rptrMonitorPortFrameTooLongs, rptrMonitorPortShortEvents, rptrMonitorPortRunts, rptrMonitorPortCollisions, rptrMonitorPortLateEvents, rptrMonitorPortVeryLongEvents, rptrMonitorPortDataRateMismatches, rptrMonitorPortAutoPartitions, rptrMonitorPortTotalErrors } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** Monitor group from RFCs 1368 and 1516. NOTE: this object group is DEPRECATED and replaced with snmpRptrGrpMonitor." ::= { snmpRptrModObjGrps 2 } snmpRptrGrpAddrTrack1368 OBJECT-GROUP OBJECTS { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex, rptrAddrTrackLastSourceAddress, rptrAddrTrackSourceAddrChanges } STATUS obsolete DESCRIPTION "Address tracking group from RFC 1368. NOTE: this object group is OBSOLETE and replaced with snmpRptrGrpAddrTrack1516." ::= { snmpRptrModObjGrps 3 } snmpRptrGrpAddrTrack1516 OBJECT-GROUP OBJECTS { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex, rptrAddrTrackLastSourceAddress, rptrAddrTrackSourceAddrChanges, rptrAddrTrackNewLastSrcAddress } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** de Graaf, et. al. Standards Track [Page 68] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 Address tracking group from RFC 1516. NOTE: this object group is DEPRECATED and replaced with snmpRptrGrpAddrTrack." ::= { snmpRptrModObjGrps 4 } snmpRptrGrpBasic OBJECT-GROUP OBJECTS { rptrGroupIndex, rptrGroupObjectID, rptrGroupOperStatus, rptrGroupPortCapacity, rptrPortGroupIndex, rptrPortIndex, rptrPortAdminStatus, rptrPortAutoPartitionState, rptrPortOperStatus, rptrPortRptrId, rptrInfoId, rptrInfoRptrType, rptrInfoOperStatus, rptrInfoReset, rptrInfoPartitionedPorts, rptrInfoLastChange } STATUS current DESCRIPTION "Basic group for a system with one or more repeater-units in multi-segment (post-RFC 1516) version of the MIB module." ::= { snmpRptrModObjGrps 5 } snmpRptrGrpMonitor OBJECT-GROUP OBJECTS { rptrMonitorPortGroupIndex, rptrMonitorPortIndex, rptrMonitorPortReadableFrames, rptrMonitorPortReadableOctets, rptrMonitorPortFCSErrors, rptrMonitorPortAlignmentErrors, rptrMonitorPortFrameTooLongs, rptrMonitorPortShortEvents, rptrMonitorPortRunts, rptrMonitorPortCollisions, rptrMonitorPortLateEvents, rptrMonitorPortVeryLongEvents, rptrMonitorPortDataRateMismatches, rptrMonitorPortAutoPartitions, rptrMonitorPortTotalErrors, de Graaf, et. al. Standards Track [Page 69] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 rptrMonitorPortLastChange, rptrMonTxCollisions, rptrMonTotalFrames, rptrMonTotalErrors, rptrMonTotalOctets } STATUS current DESCRIPTION "Monitor group for a system with one or more repeater-units in multi-segment (post-RFC 1516) version of the MIB module." ::= { snmpRptrModObjGrps 6 } snmpRptrGrpMonitor100 OBJECT-GROUP OBJECTS { rptrMonitorPortIsolates, rptrMonitorPortSymbolErrors, rptrMonitorPortUpper32Octets, rptrMonUpper32TotalOctets } STATUS current DESCRIPTION "Monitor group for 100Mb/s ports and repeaters in a system with one or more repeater-units in multi-segment (post-RFC 1516) version of the MIB module. Systems which support Counter64 should also implement snmpRptrGrpMonitor100w64." ::= { snmpRptrModObjGrps 7 } snmpRptrGrpMonitor100w64 OBJECT-GROUP OBJECTS { rptrMonitorPortHCReadableOctets, rptrMonHCTotalOctets } STATUS current DESCRIPTION "Monitor group for 100Mb/s ports and repeaters in a system with one or more repeater-units and support for Counter64." ::= { snmpRptrModObjGrps 8 } snmpRptrGrpAddrTrack OBJECT-GROUP OBJECTS { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex, rptrAddrTrackSourceAddrChanges, rptrAddrTrackNewLastSrcAddress, rptrAddrTrackCapacity } STATUS current DESCRIPTION "Passive address tracking group for post-RFC 1516 version of the MIB module." de Graaf, et. al. Standards Track [Page 70] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 ::= { snmpRptrModObjGrps 9 } snmpRptrGrpExtAddrTrack OBJECT-GROUP OBJECTS { rptrExtAddrTrackMacIndex, rptrExtAddrTrackSourceAddress } STATUS current DESCRIPTION "Extended passive address tracking group for a system with one or more repeater-units in post-RFC 1516 version of the MIB module." ::= { snmpRptrModObjGrps 10 } snmpRptrGrpRptrAddrSearch OBJECT-GROUP OBJECTS { rptrAddrSearchLock, rptrAddrSearchStatus, rptrAddrSearchAddress, rptrAddrSearchState, rptrAddrSearchGroup, rptrAddrSearchPort, rptrAddrSearchOwner } STATUS current DESCRIPTION "Active MAC address search group and topology mapping support for repeaters." ::= { snmpRptrModObjGrps 11 } snmpRptrGrpTopNPort OBJECT-GROUP OBJECTS { rptrTopNPortControlIndex, rptrTopNPortRepeaterId, rptrTopNPortRateBase, rptrTopNPortTimeRemaining, rptrTopNPortDuration, rptrTopNPortRequestedSize, rptrTopNPortGrantedSize, rptrTopNPortStartTime, rptrTopNPortOwner, rptrTopNPortRowStatus, rptrTopNPortIndex, rptrTopNPortGroupIndex, rptrTopNPortPortIndex, rptrTopNPortRate } STATUS current DESCRIPTION "Top `N' group for repeater ports." ::= { snmpRptrModObjGrps 12 } -- Compliances de Graaf, et. al. Standards Track [Page 71] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 snmpRptrModComplRFC1368 MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "Compliance for RFC 1368. NOTE: this module compliance is OBSOLETE and replaced by snmpRptrModComplRFC1516." MODULE -- this module MANDATORY-GROUPS { snmpRptrGrpBasic1516 } GROUP snmpRptrGrpMonitor1516 DESCRIPTION "Implementation of this optional group is recommended for systems which have the instrumentation to do performance monitoring." GROUP snmpRptrGrpAddrTrack1368 DESCRIPTION "Implementation of this group is recommended for systems which have the necessary instrumentation." ::= { snmpRptrModCompls 1 } snmpRptrModComplRFC1516 MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "********* THIS COMPLIANCE IS DEPRECATED ********** Compliance for RFC 1516 and for backwards compatibility with single-repeater, 10Mb/s-only implementations." MODULE -- this module MANDATORY-GROUPS { snmpRptrGrpBasic1516 } GROUP snmpRptrGrpMonitor1516 DESCRIPTION "Implementation of this optional group is recommended for systems which have the instrumentation to do performance monitoring." GROUP snmpRptrGrpAddrTrack1516 DESCRIPTION "Implementation of this group is recommended for systems which have the necessary instrumentation." de Graaf, et. al. Standards Track [Page 72] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 ::= { snmpRptrModCompls 2 } snmpRptrModCompl MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for the multi-segment version of the MIB module for a system with one or more repeater-units." MODULE -- this module MANDATORY-GROUPS { snmpRptrGrpBasic, snmpRptrGrpMonitor, snmpRptrGrpAddrTrack } GROUP snmpRptrGrpMonitor100 DESCRIPTION "Implementation of this group is mandatory for managed systems which contain 100Mb/s repeaters." GROUP snmpRptrGrpMonitor100w64 DESCRIPTION "Implementation of this group is mandatory for managed systems which contain 100Mb/s repeaters and which can support Counter64." GROUP snmpRptrGrpExtAddrTrack DESCRIPTION "Implementation of this group is recommended for systems which have the necessary instrumentation to track MAC addresses of multiple DTEs attached to a single repeater port." GROUP snmpRptrGrpRptrAddrSearch DESCRIPTION "Implementation of this group is recommended for systems which allow read-write access and which have the necessary instrumentation to search all incoming data streams for a particular MAC address." GROUP snmpRptrGrpTopNPort DESCRIPTION "Implementation of this group is recommended for systems which have de Graaf, et. al. Standards Track [Page 73] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 the necessary resources to support TopN statistics reporting." ::= { snmpRptrModCompls 3 } END de Graaf, et. al. Standards Track [Page 74] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 4. Topology Mapping The network mapping algorithm presented below takes information available from network devices such as repeaters, bridges, and switches, and creates a representation of the physical topology of the network. Networking devices connect to the network via one or more ports. Through these ports, the device is capable of hearing network packets sent by other devices. By looking the source address in the packet, and identifying which port the packet was heard on, the device can provide information to a Network Management System about the location of an address in the network, relative to that device. For devices such as bridges and switches, the association of address to port can be retrieved via the forwarding data base part of the Bridge MIB. For repeaters, the rptrAddrSearchTable may be used to perform the association. Given this information, it would be possible for the NMS to create a topology of the network which represents the physical relationships of the devices in the networks. The following is an example of how this might be done: Assume the network: ============================= | | | | | | d1 d4 d7 / \ | / \ | d2 d3 d5 | | d6 The discovery process would first determine the existence of the network devices and nodes in the network. In the above example, the network devices discovered would be: d1,d2,d3,d4,d5,d6,d7 From this list of discovered devices, select (arbitrarily or via some heuristic) a device as the starting point. From that device, determine where all other devices are located in the network with respect to the selected device. de Graaf, et. al. Standards Track [Page 75] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 For example, if d1 is the selected device, the network in relation to d1 would look like: d1 / | \ / | \ d2 d3 d4,d5,d6,d7 So d1 sees d2 on one port, d3 on another port, and d4, d5, and d6 on the third port. In other words, using the rptrAddrSearchTable (if d1 is a repeater) or the Forwarding Database (if it is a bridge or a switch), d1 has located d2 on one port, d1 has located d3 on another port, and finally, d1 has located d4, d5, d6, and d7 on yet another port. After the first step of the algorithm is accomplished, the next and final step is a recursive one. Go to each of these temporary 'segments' (e.g., the segment connecting d1 and d2, or the segment connecting d1 and d3, or the segment connecting d1, d4, d5, d6, and d7) and determine which of these devices really belongs in that segment. As new segments are created due to this process, the recursive algorithm visits them, and performs the exact same process. In the example, the segments connecting d1 and d2, and connecting d1 and d3, require no further scrutiny, since there are only two nodes in those segments. However, the segment connecting d1, d4, d5, d6, and d7 may prove to be one or more segments, so we will investigate it. The purpose of this step is to determine which devices are really connected to this segment, and which are actually connected downstream. This is done by giving each of the child devices in the segment (d4, d5, d6, and d7) a chance to eliminate each of the others from the segment. A device eliminates another device by showing that it hears the parent device (in this case, d1) on one port, and the other device on another port (different from the port on which it heard the parent). If this is true, then it must mean that that device is _between_ the parent device and the device which is being eliminated. de Graaf, et. al. Standards Track [Page 76] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 In the example, we can see that device d4 can eliminate both d5 and d6, , but nobody can eliminate d4 and d7, because everybody hears them on the same port that they hear the parent device (d1). So the resulting topology looks like: d1 / | \ / | \ d2 d3 d4,d7 | | d5,d6 Next the algorithm visits the next segment, which is the one connecting d4, d5, and d6. Using the process stated above, d5 can eliminate d6, since it hears d4 on a different port from where it hears d6. Finally, the topology looks like: d1 / | \ / | \ d2 d3 d4,d7 | | d5 | | d6 This is actually the topology shown at the beginning of the description. With this information about how the network devices are connected, it is a relatively simple extension to then place nodes such as workstations and PCs in the network. This can be done by placing the node into a segment, then allowing the network devices to show that the node is really not part of that segment. This elimination can be done because the devices know what port connects them to the segment on which the node is temporarily placed. If they actually hear the node on a different port than that which connects the device to the segment, then the node must be downstream, and so it is moved onto the downstream segment. Then that segment is evaluated, and so forth. Eventually, no device can show that the node is connected downstream, and so it must be attached to that segment. de Graaf, et. al. Standards Track [Page 77] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 For example, assume the network: ============================= | | | | | | d1 d4 d7 / \ | / \ | d2 d3 d5 | | | | e1 d6 In this network, we are trying to place e1 where it belongs. We begin by placing it arbitrarily into a segment: ================================== | | | | | | | | e1 d1 d4 d7 / \ | / \ | d2 d3 d5 | | d6 In the above case, we would give d1, d4, and d7 a chance to show that e1 is not really on that segment. d4 and d7 hear e1 on the same port which connects them to that segment, so they cannot eliminate e1 from the segment. However, d1 will hear e1 on a different port, so we move e1 down onto the segment which is connected by that port. This yields the following: ============================= | | | | | | d1 d4 d7 / \ | / \ | d2 d3,e1 d5 | | d6 de Graaf, et. al. Standards Track [Page 78] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 Now we give everyone in that segment (besides that parent device, d1) a chance to eliminate e1. Only d3 can try, and it succeeds, so we place e1 on segment which is connected by the port on which d3 heard e1. There is no segment there (yet), so we create one, and end up with the following: ============================= | | | | | | d1 d4 d7 / \ | / \ | d2 d3 d5 | | | | e1 d6 which is the correct position. 5. Acknowledgements This document was produced by the IETF Hub MIB Working Group, whose efforts were greatly advanced by the contributions of the following people: Chuck Black John Flick Jeff Johnson Leon Leong Mike Lui Dave Perkins Geoff Thompson Maurice Turcotte Paul Woodruff de Graaf, et. al. Standards Track [Page 79] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 6. References [1] IEEE 802.3/ISO 8802-3 Information processing systems - Local area networks - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 1993. [2] IEEE 802.3u-1995, "MAC Parameters, Physical Layer, Medium Attachment Units and Repeater for 100 Mb/s Operation, Type 100BASE-T," Sections 21 through 29, Supplement to IEEE Std 802.3, October 26, 1995. [3] IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30, Supplement to IEEE Std 802.3, October 26, 1995. [4] de Graaf, K., D. Romascanu, D. McMaster, K. McCloghrie, and S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", Work in Progress. [5] 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. [6] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [7] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [8] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [9] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. de Graaf, et. al. Standards Track [Page 80] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 [10] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [11] McMaster, D., and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices", RFC 1516, September 1993. [12] McAnally, G., D. Gilbert, and J. Flick, "Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework", RFC 1988, August 1996. [13] Hewlett-Packard Company, US Patents 5,293,635 and 5,421,024. [14] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994. 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Kathryn de Graaf 3Com Corporation 118 Turnpike Rd. Southborough, MA 01772 USA Phone: (508)229-1627 Fax: (508)490-5882 EMail: kdegraaf@isd.3com.com Dan Romascanu Madge Networks (Israel) Ltd. Atidim Technology Park, Bldg. 3 Tel Aviv 61131, Israel Phone: 972-3-6458414, 6458458 Fax: 972-3-6487146 EMail: dromasca@madge.com de Graaf, et. al. Standards Track [Page 81] RFC 2108 802.3 Repeater MIB using SMIv2 February 1997 Donna McMaster Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 526-5260 EMail: mcmaster@cisco.com Keith McCloghrie Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 526-5260 EMail: kzm@cisco.com de Graaf, et. al. Standards Track [Page 82] snmp-mibs-downloader-1.1/mibrfcs/rfc2115.txt0000644000000000000000000016505611402176071015567 0ustar Network Working Group C. Brown Request for Comments: 2115 Cadia Networks, Inc. Obsoletes: 1315 F. Baker Category: Standards Track Cisco Systems September 1997 Management Information Base for Frame Relay DTEs Using SMIv2 1. 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. 2. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Frame Relay interfaces on DTEs. Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 The SNMPv2 Network Management Framework ............... 2 4 Overview .............................................. 2 4.1 Frame Relay Operational Model ....................... 2 4.2 Textual Conventions ................................. 6 4.3 Structure of MIB .................................... 6 5 Changes from RFC 1315 ................................. 6 6 Definitions ........................................... 8 6.1 Data Link Connection Management Interface ........... 9 6.2 Circuit Table ....................................... 14 6.3 Error Table ......................................... 22 6.4 Trap Management ..................................... 25 7 Security Issues ....................................... 30 8 Acknowledgments ....................................... 30 9 Authors' Addresses .................................... 31 10 References ........................................... 31 Brown & Baker Standards Track [Page 1] RFC 2115 Frame Relay DTE MIB September 1997 3. The SNMPv2 Network Management Framework The major components of the SNMPv2 Network Management framework are described in the documents listed below. o RFC 1902 [1] defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects (MO) for the Internet suite of protocols. o RFC 1905 [3] defines the protocol used for network access to managed objects. The framework is adaptable/extensible by defining new MIBs to suit the requirements of specific applications/protocols/situations. Managed objects are accessed via a virtual information store, the 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, which is 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, often a textual string, termed the descriptor, is used to refer to the object type. 4. Overview 4.1. Frame Relay Operational Model For the purposes of understanding this document, Frame Relay is viewed as a multi-access media, not as a group of point- to-point connections. This model proposes that Frame Relay is a single interface to the network (physical connection) with many destinations or neighbors (virtual connections). This view enables a network manager the ability to group all virtual connections with their corresponding physical connection thereby allowing simpler diagnostics and trouble shooting. With the extension of the interfaces MIB, it is possible to configure frame relay DLCs as individual interfaces and create ifTable entries for each. This is not recommended and is not directly supported by this MIB. Additionally, in the presence of demand circuits creation of individual ifEntries for each is not possible. Brown & Baker Standards Track [Page 2] RFC 2115 Frame Relay DTE MIB September 1997 Should the user wish to group DLCs together to associate them with a higher layer, or to associate a DLC with an unnumbered point-to-point service, the frame relay DTE MIB provides an entry in the frCircuitEntry record. For example, suppose one were to configure a company proprietary protocol to run above several of the frame relay VCs. The basic layering would look something like the following: IP (ipaddrEntry 1 ) IP (ipaddrEntry 2) IP (ipaddrEntry 3) | | | | | | | | proprietary protocol | | layer (ifIndex 3) | | | | | | DLCI 20 DLCI 30 DLCI 40/41/42 (ifIndex 2) (ifIndex 2) (ifIndex 2, logical ifIndex 3) | | | | | | |____________________|_____________________| | | FR DLMCI (ifIndex.2) | | Physical Interface (ifIndex.1) A configuration which specified that DLCI 40, 41,and 42 were associated with a proprietary protocol layer, while DLCI 20 and 30 were to run IP directly can now be expressed using a combination of frCircuitIfIndex and frCircuitLogicalIfIndex. In this particular case DLCIs 40, 41 and 42 would use frCircuitIfIndex equal to the frame relay interface level (2) while their frCircuitLogicalIfIndex would indicate the proprietary protocol (3). DLCIs 20 and 30 would have both instances set to the frame relay interface (2). Object Meaning for Frame Relay Interface ______ _____________________________________ ifDescr As per DESCRIPTION in RFC 1573. ifType The value allocated for Frame Relay Interfaces - frameRelay (32). ifMtu Set to maximum frame size in octets for this frame relay interface. Brown & Baker Standards Track [Page 3] RFC 2115 Frame Relay DTE MIB September 1997 ifSpeed The access rate for the frame relay interface. This could be different from the speed of the underlying physical interface, e.g. in a fractional T1 case the access rate could be 384 kbits/s (the value reported in this object) whereas the speed of the underlying interface would be 1.544 Mbits/s (the value reported in the instance of ifSpeed for the ifEntry with type ds1). ifPhysAddress The primary address for this interface assigned by the Frame Relay interface provider. An octet string of zero length if no address is used for this interface. ifAdminStatus As per DESCRIPTION in RFC 1573. ifOperStatus As per DESCRIPTION in RFC 1573. ifLastChange As per DESCRIPTION in RFC 1573. ifInOctets The number of received octets. This includes not only the information field (user data) but also the frame relay header and CRC. ifInUcastPkts The number of frames received on non- multicast DLCIs ifInDiscards The number of frames that were successfully received but were discarded because of format errors or because the VC was not known. Format errors, in this case, are any errors which would prevent the system from recognizing the DLCI and placing the error in the frCircuitDiscard category. ifInErrors The number of received frames that are discarded, because of an error. Possible errors can be the following: the frame relay frames were too long or were too short, the frames had an invalid or unrecognized DLCI values, or incorrect header values. Brown & Baker Standards Track [Page 4] RFC 2115 Frame Relay DTE MIB September 1997 ifInUnknownProtos Number of unknown or unsupported upper layer protocol frames received and discarded. ifOutOctets The number of received octets. This includes not only the information field (user data) but also the frame relay header and CRC. ifOutUcastpkts The number of frames sent. ifOutDiscards The number of frames discarded in the transmit direction. ifOutErrors The number of frames discarded in the egress direction, because of errors. ifName As per DESCRIPTION in RFC 1573. ifInMulticastPkts The number of unerrored frames received on a multicast DLCI. ifInBroadcastPkts Always zero (0) as there are no broadcast frames. ifOutMulticastPkts The number of frames transmitted over a multicast DLCI. ifOutBroadcastPkts Always zero (0) as there are no broadcast frames. ifHCInOctets Only required when ifSpeed >= 155 Mbits/s. See details for ifInOctets. ifHCOutOctets Only required when ifSpeed >= 155 Mbits/s. See details for ifInOctets. ifLinkUpDownTrapEnble As per DESCRIPTION in RFC 1573. ifHighSpeed The access rate of the frame relay interface measured in Mbits/s. If the access rate is less than 1 Mbits/s, this object returns 0. ifPromiscuousMode Set to false(2). ifConnectorPresent Set to false(2). Brown & Baker Standards Track [Page 5] RFC 2115 Frame Relay DTE MIB September 1997 4.2. Textual Conventions One new data type is introduced as a textual convention in this MIB document. This textual convention enhances the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of this textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of this is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate this textual conventions which is adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. The new data type is DLCI. DLCI refers to the range 0..DLCINumber, and is used to refer to the valid Data Link Connection Indices. DLCINumber is, by definition, the largest possible DLCI value possible under the configured Q.922 Address Format. 4.3. Structure of MIB The MIB is composed of three groups, one defining the Data Link Connection Management Interface (DLCMI), one describing the Circuits, and a third describing errors. During normal operation, Frame Relay virtual circuits will be added, deleted and change availability. The occurrence of such changes is of interest to the network manager and therefore, one trap is defined, intended to be corollary to the SNMP "Link Up" and "Link Down" traps. 5. Changes from RFC 1315 Below are listed the changes from the previously published version this document, which was RFC 1315: o The MIB module was converted from SMIv1 to SMIv2 format. Note: due to this, the table indices have access of "read-only" instead of "not-accessible", which is the typical value for index objects in SMIv2. o The module name was changed from RFC1315-MIB to FRAME- RELAY-DTE-MIB. o The textual convention "Index" was dropped from the MIB module and "InterfaceIndex" from the interfaces MIB module, IF-MIB, was used in its place. Brown & Baker Standards Track [Page 6] RFC 2115 Frame Relay DTE MIB September 1997 o Objects frDlcmiStatus and frDlcmiRowStatus were added to table frDlcmiTable. o Added values "itut933A(5)" (from CCITT Q933 Annex A) and "ansiT1617D1994(6)" (from ANSI T1.617a-1994 Annex D) to the enumerations for object frDlcmiState. o The labels for the enumerated values for object frDlcmiAddressLen were renamed to remove their hyphens as required by SMIv2. o Added clarification that the "management virtual circuit" (i.e. DLCI 0) is a member of the circuit table. o Added the following objects to table frCircuitTable: frCircuitMulticast, frCircuitType, frCircuitDiscards, frCircuitReceivedDEs, frCircuitSentDEs, frCircuitLogicalIfIndex, and frCircuitRowStatus. o The definition of object frCircuitReceivedOctets was clarified as to which octets were counted. o Added the objects frErrFaults and frErrFaultTime to table frErrTable. o Added clarification to the values of object frErrType. o Added size on definition of object frErrData and clarified what data to capture. o Changed identififier for OID value { frameDelayDTE 4 } from frame-relay-globals to frameRelayTrapControl. o Added object frTrapMaxRate. o Created object groups frPortGroup, frCircuitGroup, frTrapGroup, frErrGroup, frPortGroup0, frCircuitGroup0, frTrapGroup0, and frErrGroup0. o Created notification group frNotificationGroup. o Created module compliances frCompliance and frCompliance0. o Added ranges to objects frCircuitCommittedBurst, frCircuitExcessBurst, and frCircuitThroughput. Brown & Baker Standards Track [Page 7] RFC 2115 Frame Relay DTE MIB September 1997 6. Definitions FRAME-RELAY-DTE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF transmission FROM RFC1213-MIB InterfaceIndex FROM IF-MIB; -- Frame Relay DTE MIB frameRelayDTE MODULE-IDENTITY LAST-UPDATED "9705010229Z" -- Thu May 1 02:29:46 PDT 1997 ORGANIZATION "IETF IPLPDN Working Group" CONTACT-INFO " Caralyn Brown Postal: Cadia Networks, Inc. 1 Corporate Drive Andover, Massachusetts 01810 Tel: +1 508 689 2400 x133 E-Mail: cbrown@cadia.com Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Tel: +1 408 526 425 E-Mail: fred@cisco.com" DESCRIPTION "The MIB module to describe the use of a Frame Relay interface by a DTE." REVISION "9705010229Z" -- Thu May 1 02:29:46 PDT 1997 DESCRIPTION "Converted from SMIv1 to SMIv2. (Thus, indices are read-only rather than being not-accessible.) Added objects and made clarifications based on implementation experience." REVISION "9204010000Z" DESCRIPTION "Published as RFC 1315, the initial version of this MIB module." ::= { transmission 32 } Brown & Baker Standards Track [Page 8] RFC 2115 Frame Relay DTE MIB September 1997 -- -- the range of a Data Link Connection Identifier -- DLCI ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The range of DLCI values. Note that this varies by interface configuration; normally, interfaces may use 0..1023, but may be configured to use ranges as large as 0..2^23." SYNTAX Integer32(0..8388607) -- -- Data Link Connection Management Interface -- The variables that configure the DLC Management Interface. frDlcmiTable OBJECT-TYPE SYNTAX SEQUENCE OF FrDlcmiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Parameters for the Data Link Connection Management Interface for the frame relay service on this interface." REFERENCE "American National Standard T1.617-1991, Annex D" ::= { frameRelayDTE 1 } frDlcmiEntry OBJECT-TYPE SYNTAX FrDlcmiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Parameters for a particular Data Link Connection Management Interface." INDEX { frDlcmiIfIndex } ::= { frDlcmiTable 1 } Brown & Baker Standards Track [Page 9] RFC 2115 Frame Relay DTE MIB September 1997 FrDlcmiEntry ::= SEQUENCE { frDlcmiIfIndex InterfaceIndex, frDlcmiState INTEGER, frDlcmiAddress INTEGER, frDlcmiAddressLen INTEGER, frDlcmiPollingInterval Integer32, frDlcmiFullEnquiryInterval Integer32, frDlcmiErrorThreshold Integer32, frDlcmiMonitoredEvents Integer32, frDlcmiMaxSupportedVCs DLCI, frDlcmiMulticast INTEGER, frDlcmiStatus INTEGER, frDlcmiRowStatus RowStatus } frDlcmiIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the corresponding ifEntry." ::= { frDlcmiEntry 1 } frDlcmiState OBJECT-TYPE SYNTAX INTEGER { noLmiConfigured (1), lmiRev1 (2), ansiT1617D (3), -- ANSI T1.617 Annex D ansiT1617B (4), -- ANSI T1.617 Annex B itut933A (5), -- CCITT Q933 Annex A ansiT1617D1994 (6) -- ANSI T1.617a-1994 Annex D } MAX-ACCESS read-create STATUS current DESCRIPTION "This variable states which Data Link Connection Management scheme is active (and by implication, what DLCI it uses) on the Frame Relay interface." REFERENCE "American National Standard T1.617-1991, American National Standard T1.617a-1994, ITU-T Recommendation Q.933 (03/93)." ::= { frDlcmiEntry 2 } Brown & Baker Standards Track [Page 10] RFC 2115 Frame Relay DTE MIB September 1997 frDlcmiAddress OBJECT-TYPE SYNTAX INTEGER { q921 (1), -- 13 bit DLCI q922March90 (2), -- 11 bit DLCI q922November90 (3), -- 10 bit DLCI q922 (4) -- Final Standard } MAX-ACCESS read-create STATUS current DESCRIPTION "This variable states which address format is in use on the Frame Relay interface." ::= { frDlcmiEntry 3 } frDlcmiAddressLen OBJECT-TYPE SYNTAX INTEGER { twoOctets (2), threeOctets (3), fourOctets (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This variable states the address length in octets. In the case of Q922 format, the length indicates the entire length of the address including the control portion." ::= { frDlcmiEntry 4 } frDlcmiPollingInterval OBJECT-TYPE SYNTAX Integer32 (5..30) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This is the number of seconds between successive status enquiry messages." REFERENCE "American National Standard T1.617-1991, Section D.7 Timer T391." DEFVAL { 10 } ::= { frDlcmiEntry 5 } Brown & Baker Standards Track [Page 11] RFC 2115 Frame Relay DTE MIB September 1997 frDlcmiFullEnquiryInterval OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Number of status enquiry intervals that pass before issuance of a full status enquiry message." REFERENCE "American National Standard T1.617-1991, Section D.7 Counter N391." DEFVAL { 6 } ::= { frDlcmiEntry 6 } frDlcmiErrorThreshold OBJECT-TYPE SYNTAX Integer32 (1..10) MAX-ACCESS read-create STATUS current DESCRIPTION "This is the maximum number of unanswered Status Enquiries the equipment shall accept before declaring the interface down." REFERENCE "American National Standard T1.617-1991, Section D.5.1 Counter N392." DEFVAL { 3 } ::= { frDlcmiEntry 7 } frDlcmiMonitoredEvents OBJECT-TYPE SYNTAX Integer32 (1..10) MAX-ACCESS read-create STATUS current DESCRIPTION "This is the number of status polling intervals over which the error threshold is counted. For example, if within 'MonitoredEvents' number of events the station receives 'ErrorThreshold' number of errors, the interface is marked as down." REFERENCE "American National Standard T1.617-1991, Section D.5.2 Counter N393." DEFVAL { 4 } ::= { frDlcmiEntry 8 } Brown & Baker Standards Track [Page 12] RFC 2115 Frame Relay DTE MIB September 1997 frDlcmiMaxSupportedVCs OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of Virtual Circuits allowed for this interface. Usually dictated by the Frame Relay network. In response to a SET, if a value less than zero or higher than the agent's maximal capability is configured, the agent should respond badValue" ::= { frDlcmiEntry 9 } frDlcmiMulticast OBJECT-TYPE SYNTAX INTEGER { nonBroadcast (1), broadcast (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This indicates whether the Frame Relay interface is using a multicast service." ::= { frDlcmiEntry 10 } frDlcmiStatus OBJECT-TYPE SYNTAX INTEGER { running (1), -- init complete, system running fault (2), -- error threshold exceeded initializing (3) -- system start up } MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates the status of the Frame Relay interface as determined by the performance of the dlcmi. If no dlcmi is running, the Frame Relay interface will stay in the running state indefinitely." ::= { frDlcmiEntry 11 } Brown & Baker Standards Track [Page 13] RFC 2115 Frame Relay DTE MIB September 1997 frDlcmiRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "SNMP Version 2 Row Status Variable. Writable objects in the table may be written in any RowStatus state." ::= { frDlcmiEntry 12 } -- -- A Frame Relay service is a multiplexing service. Data -- Link Connection Identifiers enumerate virtual circuits -- (permanent or dynamic) which are layered onto the underlying -- circuit, represented by ifEntry. Therefore, each of the entries -- in the Standard MIB's Interface Table with an IfType of -- Frame Relay represents a Q.922 interface. Zero or more -- virtual circuits are layered onto this interface and provide -- interconnection with various remote destinations. -- Each such virtual circuit is represented by an entry in the -- circuit table. The management virtual circuit (i.e. DLCI 0) -- is a virtual circuit by this definition and will be represented -- with an entry in the circuit table. -- Circuit Table -- The table describing the use of the DLCIs attached to -- each Frame Relay Interface. frCircuitTable OBJECT-TYPE SYNTAX SEQUENCE OF FrCircuitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about specific Data Link Connections (DLC) or virtual circuits." ::= { frameRelayDTE 2 } Brown & Baker Standards Track [Page 14] RFC 2115 Frame Relay DTE MIB September 1997 frCircuitEntry OBJECT-TYPE SYNTAX FrCircuitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The information regarding a single Data Link Connection. Discontinuities in the counters contained in this table are indicated by the value in frCircuitCreationTime." INDEX { frCircuitIfIndex, frCircuitDlci } ::= { frCircuitTable 1 } FrCircuitEntry ::= SEQUENCE { frCircuitIfIndex InterfaceIndex, frCircuitDlci DLCI, frCircuitState INTEGER, frCircuitReceivedFECNs Counter32, frCircuitReceivedBECNs Counter32, frCircuitSentFrames Counter32, frCircuitSentOctets Counter32, frCircuitReceivedFrames Counter32, frCircuitReceivedOctets Counter32, frCircuitCreationTime TimeStamp, frCircuitLastTimeChange TimeStamp, frCircuitCommittedBurst Integer32, frCircuitExcessBurst Integer32, frCircuitThroughput Integer32, frCircuitMulticast INTEGER, frCircuitType INTEGER, frCircuitDiscards Counter32, frCircuitReceivedDEs Counter32, frCircuitSentDEs Counter32, frCircuitLogicalIfIndex InterfaceIndex, frCircuitRowStatus RowStatus } frCircuitIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex Value of the ifEntry this virtual circuit is layered onto." ::= { frCircuitEntry 1 } Brown & Baker Standards Track [Page 15] RFC 2115 Frame Relay DTE MIB September 1997 frCircuitDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-only STATUS current DESCRIPTION "The Data Link Connection Identifier for this virtual circuit." REFERENCE "American National Standard T1.618-1991, Section 3.3.6" ::= { frCircuitEntry 2 } frCircuitState OBJECT-TYPE SYNTAX INTEGER { invalid (1), active (2), inactive (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the particular virtual circuit is operational. In the absence of a Data Link Connection Management Interface, virtual circuit entries (rows) may be created by setting virtual circuit state to 'active', or deleted by changing Circuit state to 'invalid'. Whether or not the row actually disappears is left to the implementation, so this object may actually read as 'invalid' for some arbitrary length of time. It is also legal to set the state of a virtual circuit to 'inactive' to temporarily disable a given circuit. The use of 'invalid' is deprecated in this SNMP Version 2 MIB, in favor of frCircuitRowStatus." DEFVAL { active } ::= { frCircuitEntry 3 } Brown & Baker Standards Track [Page 16] RFC 2115 Frame Relay DTE MIB September 1997 frCircuitReceivedFECNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames received from the network indicating forward congestion since the virtual circuit was created. This occurs when the remote DTE sets the FECN flag, or when a switch in the network enqueues the frame to a trunk whose transmission queue is congested." REFERENCE "American National Standard T1.618-1991, Section 3.3.3" ::= { frCircuitEntry 4 } frCircuitReceivedBECNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames received from the network indicating backward congestion since the virtual circuit was created. This occurs when the remote DTE sets the BECN flag, or when a switch in the network receives the frame from a trunk whose transmission queue is congested." REFERENCE "American National Standard T1.618-1991, Section 3.3.4" ::= { frCircuitEntry 5 } frCircuitSentFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames sent from this virtual circuit since it was created." ::= { frCircuitEntry 6 } frCircuitSentOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Brown & Baker Standards Track [Page 17] RFC 2115 Frame Relay DTE MIB September 1997 DESCRIPTION "The number of octets sent from this virtual circuit since it was created. Octets counted are the full frame relay header and the payload, but do not include the flag characters or CRC." ::= { frCircuitEntry 7 } frCircuitReceivedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames received over this virtual circuit since it was created." ::= { frCircuitEntry 8 } frCircuitReceivedOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of octets received over this virtual circuit since it was created. Octets counted include the full frame relay header, but do not include the flag characters or the CRC." ::= { frCircuitEntry 9 } frCircuitCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the virtual circuit was created, whether by the Data Link Connection Management Interface or by a SetRequest." ::= { frCircuitEntry 10 } Brown & Baker Standards Track [Page 18] RFC 2115 Frame Relay DTE MIB September 1997 frCircuitLastTimeChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when last there was a change in the virtual circuit state" ::= { frCircuitEntry 11 } frCircuitCommittedBurst OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the maximum amount of data, in bits, that the network agrees to transfer under normal conditions, during the measurement interval." REFERENCE "American National Standard T1.617-1991, Section 6.5.19" DEFVAL { 0 } -- the default indicates no commitment ::= { frCircuitEntry 12 } frCircuitExcessBurst OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the maximum amount of uncommitted data bits that the network will attempt to deliver over the measurement interval. By default, if not configured when creating the entry, the Excess Information Burst Size is set to the value of ifSpeed." REFERENCE "American National Standard T1.617-1991, Section 6.5.19" ::= { frCircuitEntry 13 } frCircuitThroughput OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION Brown & Baker Standards Track [Page 19] RFC 2115 Frame Relay DTE MIB September 1997 "Throughput is the average number of 'Frame Relay Information Field' bits transferred per second across a user network interface in one direction, measured over the measurement interval. If the configured committed burst rate and throughput are both non-zero, the measurement interval, T, is T=frCircuitCommittedBurst/frCircuitThroughput. If the configured committed burst rate and throughput are both zero, the measurement interval, T, is T=frCircuitExcessBurst/ifSpeed." REFERENCE "American National Standard T1.617-1991, Section 6.5.19" DEFVAL {0} -- the default value of Throughput is -- "no commitment". ::= { frCircuitEntry 14 } frCircuitMulticast OBJECT-TYPE SYNTAX INTEGER { unicast (1), oneWay (2), twoWay (3), nWay (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This indicates whether this VC is used as a unicast VC (i.e. not multicast) or the type of multicast service subscribed to" REFERENCE "Frame Relay PVC Multicast Service and Protocol Description Implementation: FRF.7 Frame Relay Forum Technical Committe October 21, 1994" DEFVAL {unicast} -- the default value of frCircuitMulticast is -- "unicast" (not a multicast VC). ::= { frCircuitEntry 15 } frCircuitType OBJECT-TYPE SYNTAX INTEGER { static (1), dynamic (2) } Brown & Baker Standards Track [Page 20] RFC 2115 Frame Relay DTE MIB September 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether the VC was manually created (static), or dynamically created (dynamic) via the data link control management interface." ::= { frCircuitEntry 16 } frCircuitDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound frames dropped because of format errors, or because the VC is inactive." ::= { frCircuitEntry 17 } frCircuitReceivedDEs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames received from the network indicating that they were eligible for discard since the virtual circuit was created. This occurs when the remote DTE sets the DE flag, or when in remote DTE's switch detects that the frame was received as Excess Burst data." REFERENCE "American National Standard T1.618-1991, Section 3.3.4" ::= { frCircuitEntry 18 } frCircuitSentDEs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames sent to the network indicating that they were eligible for discard since the virtual circuit was created. This occurs when the local DTE sets the DE flag, indicating that during Network congestion situations those frames should be discarded in preference of other frames sent without the DE bit set." REFERENCE Brown & Baker Standards Track [Page 21] RFC 2115 Frame Relay DTE MIB September 1997 "American National Standard T1.618-1991, Section 3.3.4" ::= { frCircuitEntry 19 } frCircuitLogicalIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "Normally the same value as frDlcmiIfIndex, but different when an implementation associates a virtual ifEntry with a DLC or set of DLCs in order to associate higher layer objects such as the ipAddrEntry with a subset of the virtual circuits on a Frame Relay interface. The type of such ifEntries is defined by the higher layer object; for example, if PPP/Frame Relay is implemented, the ifType of this ifEntry would be PPP. If it is not so defined, as would be the case with an ipAddrEntry, it should be of type Other." ::= { frCircuitEntry 20 } frCircuitRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or destroy an existing row in the manner described in the definition of the RowStatus textual convention. Writable objects in the table may be written in any RowStatus state." ::= { frCircuitEntry 21 } -- -- Error Table -- The table describing errors encountered on each Frame -- Relay Interface. frErrTable OBJECT-TYPE SYNTAX SEQUENCE OF FrErrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about Errors on the Frame Relay interface. Discontinuities in the counters contained in this table are the same as apply to the Brown & Baker Standards Track [Page 22] RFC 2115 Frame Relay DTE MIB September 1997 ifEntry associated with the Interface." ::= { frameRelayDTE 3 } frErrEntry OBJECT-TYPE SYNTAX FrErrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The error information for a single frame relay interface." INDEX { frErrIfIndex } ::= { frErrTable 1 } FrErrEntry ::= SEQUENCE { frErrIfIndex InterfaceIndex, frErrType INTEGER, frErrData OCTET STRING, frErrTime TimeStamp, frErrFaults Counter32, frErrFaultTime TimeStamp } frErrIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex Value of the corresponding ifEntry." ::= { frErrEntry 1 } frErrType OBJECT-TYPE SYNTAX INTEGER { unknownError(1), receiveShort(2), receiveLong(3), illegalAddress(4), unknownAddress(5), dlcmiProtoErr(6), dlcmiUnknownIE(7), dlcmiSequenceErr(8), dlcmiUnknownRpt(9), noErrorSinceReset(10) } Brown & Baker Standards Track [Page 23] RFC 2115 Frame Relay DTE MIB September 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The type of error that was last seen on this interface: receiveShort: frame was not long enough to allow demultiplexing - the address field was incomplete, or for virtual circuits using Multiprotocol over Frame Relay, the protocol identifier was missing or incomplete. receiveLong: frame exceeded maximum length configured for this interface. illegalAddress: address field did not match configured format. unknownAddress: frame received on a virtual circuit which was not active or administratively disabled. dlcmiProtoErr: unspecified error occurred when attempting to interpret link maintenance frame. dlcmiUnknownIE: link maintenance frame contained an Information Element type which is not valid for the configured link maintenance protocol. dlcmiSequenceErr: link maintenance frame contained a sequence number other than the expected value. dlcmiUnknownRpt: link maintenance frame contained a Report Type Information Element whose value was not valid for the configured link maintenance protocol. noErrorSinceReset: no errors have been detected since the last cold start or warm start." ::= { frErrEntry 2 } frErrData OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..1600)) MAX-ACCESS read-only STATUS current DESCRIPTION "An octet string containing as much of the error packet as possible. As a minimum, it must contain the Q.922 Address or as much as was delivered. It is desirable to include all header and demultiplexing information." ::= { frErrEntry 3 } Brown & Baker Standards Track [Page 24] RFC 2115 Frame Relay DTE MIB September 1997 frErrTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which the error was detected." ::= { frErrEntry 4 } frErrFaults OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the interface has gone down since it was initialized." ::= { frErrEntry 5 } frErrFaultTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time when the interface was taken down due to excessive errors. Excessive errors is defined as the time when a DLCMI exceeds the frDlcmiErrorThreshold number of errors within frDlcmiMonitoredEvents. See FrDlcmiEntry for further details." ::= { frErrEntry 6 } -- -- Frame Relay Trap Control frameRelayTrapControl OBJECT IDENTIFIER ::= { frameRelayDTE 4 } -- the following highly unusual OID is as it is for compatibility -- with RFC 1315, the SNMP V1 predecessor of this document. frameRelayTraps OBJECT IDENTIFIER ::= { frameRelayDTE 0 } Brown & Baker Standards Track [Page 25] RFC 2115 Frame Relay DTE MIB September 1997 frTrapState OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates whether the system produces the frDLCIStatusChange trap." DEFVAL { disabled } ::= { frameRelayTrapControl 1 } frTrapMaxRate OBJECT-TYPE SYNTAX Integer32 (0..3600000) MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the number of milliseconds that must elapse between trap emissions. If events occur more rapidly, the impementation may simply fail to trap, or may queue traps until an appropriate time." DEFVAL { 0 } -- no minimum elapsed period is specified ::= { frameRelayTrapControl 2 } -- Data Link Connection Management Interface Related Traps frDLCIStatusChange NOTIFICATION-TYPE OBJECTS { frCircuitState } STATUS current DESCRIPTION "This trap indicates that the indicated Virtual Circuit has changed state. It has either been created or invalidated, or has toggled between the active and inactive states. If, however, the reason for the state change is due to the DLCMI going down, per-DLCI traps should not be generated." ::= { frameRelayTraps 1 } -- conformance information frConformance OBJECT IDENTIFIER ::= { frameRelayDTE 6 } frGroups OBJECT IDENTIFIER ::= { frConformance 1 } frCompliances OBJECT IDENTIFIER ::= { frConformance 2 } -- compliance statements Brown & Baker Standards Track [Page 26] RFC 2115 Frame Relay DTE MIB September 1997 frCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { frPortGroup, frCircuitGroup } GROUP frErrGroup DESCRIPTION "This optional group is used for debugging Frame Relay Systems." GROUP frTrapGroup DESCRIPTION "This optional group is used for the management of asynchronous notifications by Frame Relay Systems." GROUP frNotificationGroup DESCRIPTION "This optional group defines the asynchronous notifications generated by Frame Relay Systems." OBJECT frDlcmiRowStatus MIN-ACCESS read-only DESCRIPTION "Row creation is not required for the frDlcmiTable." OBJECT frCircuitRowStatus MIN-ACCESS read-only DESCRIPTION "Row creation is not required for the frCircuitTable." ::= { frCompliances 1 } frCompliance0 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for objects and the trap defined in RFC 1315." MODULE -- this module MANDATORY-GROUPS { frPortGroup0, frCircuitGroup0 } GROUP frErrGroup0 DESCRIPTION "This optional group is used for debugging Frame Relay Systems." Brown & Baker Standards Track [Page 27] RFC 2115 Frame Relay DTE MIB September 1997 GROUP frTrapGroup0 DESCRIPTION "This optional group is used for the management of asynchronous notifications by Frame Relay Systems." GROUP frNotificationGroup DESCRIPTION "This optional group defines the asynchronous notifications generated by Frame Relay Systems." ::= { frCompliances 2 } -- units of conformance frPortGroup OBJECT-GROUP OBJECTS { frDlcmiIfIndex, frDlcmiState, frDlcmiAddress, frDlcmiAddressLen, frDlcmiPollingInterval, frDlcmiFullEnquiryInterval, frDlcmiErrorThreshold, frDlcmiMonitoredEvents, frDlcmiMaxSupportedVCs, frDlcmiMulticast, frDlcmiStatus, frDlcmiRowStatus } STATUS current DESCRIPTION "The objects necessary to control the Link Management Interface for a Frame Relay Interface as well as maintain the error statistics on this interface." ::= { frGroups 1 } frCircuitGroup OBJECT-GROUP OBJECTS { frCircuitIfIndex, frCircuitDlci, frCircuitState, frCircuitReceivedFECNs, frCircuitReceivedBECNs, frCircuitSentFrames, frCircuitSentOctets, frCircuitReceivedFrames, frCircuitReceivedOctets, frCircuitCreationTime, frCircuitLastTimeChange, frCircuitCommittedBurst, frCircuitExcessBurst, frCircuitThroughput, frCircuitMulticast, frCircuitType, frCircuitDiscards, frCircuitReceivedDEs, frCircuitSentDEs, frCircuitLogicalIfIndex, frCircuitRowStatus } STATUS current DESCRIPTION "The objects necessary to control the Virtual Circuits layered onto a Frame Relay Interface." ::= { frGroups 2 } Brown & Baker Standards Track [Page 28] RFC 2115 Frame Relay DTE MIB September 1997 frTrapGroup OBJECT-GROUP OBJECTS { frTrapState, frTrapMaxRate } STATUS current DESCRIPTION "The objects necessary to control a Frame Relay Interface's notification messages." ::= { frGroups 3 } frErrGroup OBJECT-GROUP OBJECTS { frErrIfIndex, frErrType, frErrData, frErrTime, frErrFaults, frErrFaultTime } STATUS current DESCRIPTION "Objects designed to assist in debugging Frame Relay Interfaces." ::= { frGroups 4 } frNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { frDLCIStatusChange } STATUS current DESCRIPTION "Traps which may be used to enhance event driven management of the interface." ::= { frGroups 5 } frPortGroup0 OBJECT-GROUP OBJECTS { frDlcmiIfIndex, frDlcmiState, frDlcmiAddress, frDlcmiAddressLen, frDlcmiPollingInterval, frDlcmiFullEnquiryInterval, frDlcmiErrorThreshold, frDlcmiMonitoredEvents, frDlcmiMaxSupportedVCs, frDlcmiMulticast } STATUS current DESCRIPTION "The objects necessary to control the Link Management Interface for a Frame Relay Interface as well as maintain the error statistics on this interface from RFC 1315." ::= { frGroups 6 } frCircuitGroup0 OBJECT-GROUP OBJECTS { frCircuitIfIndex, frCircuitDlci, frCircuitState, frCircuitReceivedFECNs, frCircuitReceivedBECNs, frCircuitSentFrames, frCircuitSentOctets, Brown & Baker Standards Track [Page 29] RFC 2115 Frame Relay DTE MIB September 1997 frCircuitReceivedFrames, frCircuitReceivedOctets, frCircuitCreationTime, frCircuitLastTimeChange, frCircuitCommittedBurst, frCircuitExcessBurst, frCircuitThroughput } STATUS current DESCRIPTION "The objects necessary to control the Virtual Circuits layered onto a Frame Relay Interface from RFC 1315." ::= { frGroups 7 } frErrGroup0 OBJECT-GROUP OBJECTS { frErrIfIndex, frErrType, frErrData, frErrTime } STATUS current DESCRIPTION "Objects designed to assist in debugging Frame Relay Interfaces from RFC 1315." ::= { frGroups 8 } frTrapGroup0 OBJECT-GROUP OBJECTS { frTrapState } STATUS current DESCRIPTION "The objects necessary to control a Frame Relay Interface's notification messages from RFC 1315." ::= { frGroups 9 } END 7. Security Issues Security issues for this MIB are entirely covered by the SNMP Security Architecture, and have not been expanded within the contents of this MIB. 8. Acknowledgments This document was originally produced by the IP Over Large Public Data Networks (IPLPDN) Working Group, and has since been carried on in the PPP Working Group, sort of. Currently, the Ion Working Group is its host. Special thanks to James Watt of Newbridge Networks for his fine suggestions and pastable text. Brown & Baker Standards Track [Page 30] RFC 2115 Frame Relay DTE MIB September 1997 9. Authors' Addresses Caralyn Brown Cadia Networks, Inc. 1 Corporate Dirve Andover, Massachusetts 01810 Telephone: +1 508 689 2400 x133 E-Mail: cbrown@cadia.com Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Telephone +1 408 526 4257 E-Mail: fred@cisco.com 10. References [1] 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. [2] 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. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin. " A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Computer Science, May 1990. [4] 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. [5] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] T. Bradley, C. Brown, A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, 07/26/1993. [7] International Telegraph and Telephone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", CCITT Recommendation Q.922, 19 Brown & Baker Standards Track [Page 31] RFC 2115 Frame Relay DTE MIB September 1997 April 1991. [8] American National Standard For Telecommunications - Integrated Services Digital Network - Frame Relay Bearer Service - Architectural Framework and Service Description, ANSI T1.606-1991, 18 June 1991. [9] American National Standard For Telecommunications - Integrated Services Digital Network - Digital Subscriber Signalling System No. 1 - Signaling Specification for Frame Relay Bearer Service, ANSI T1.617-1991, 18 June 1991. [10] American National Standard For Telecommunications - Integrated Services Digital Network - Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18 June 1991. Brown & Baker Standards Track [Page 32] snmp-mibs-downloader-1.1/mibrfcs/rfc2127.txt0000644000000000000000000027337211402176071015573 0ustar Network Working Group G. Roeck, Editor Request for Comments: 2127 cisco Systems Category: Standards Track March 1997 ISDN Management Information Base using SMIv2 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a minimal set of managed objects for SNMP- based management of ISDN terminal interfaces. ISDN interfaces are supported on a variety of equipment (for data and voice) including terminal adapters, bridges, hosts, and routers. This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This document is a product of the ISDN MIB working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author. The current version of this document reflects changes made during the last call period and the IESG review. Table of Contents 1 The SNMPv2 Network Management Framework ...................... 2 2 Object Definitions ........................................... 2 3 Overview ..................................................... 3 3.1 Structure of the MIB ....................................... 3 3.1.1 General Description ...................................... 3 3.2 Relationship to the Interfaces MIB ......................... 4 3.2.1 Layering Model ........................................... 4 3.2.2 ifTestTable .............................................. 8 3.2.3 ifRcvAddressTable ........................................ 8 3.2.4 ifEntry .................................................. 8 Roeck Standards Track [Page 1] RFC 2127 ISDN MIB March 1997 3.2.4.1 ifEntry for a Basic Rate hardware interface ............ 8 3.2.4.2 ifEntry for a B channel ................................ 9 3.2.4.3 ifEntry for LAPD (D channel Data Link Layer) ........... 10 3.2.4.4 ifEntry for a signaling channel ........................ 12 3.3 Relationship to other MIBs ................................. 14 3.3.1 Relationship to the DS1/E1 MIB ........................... 14 3.3.2 Relationship to the DS0 and DS0Bundle MIBs ............... 14 3.3.3 Relationship to the Dial Control MIB ..................... 14 3.4 ISDN interface specific information and implementation hints ........................................................... 14 3.4.1 ISDN leased lines ........................................ 14 3.4.2 Hyperchannels ............................................ 15 3.4.3 D channel backup and NFAS trunks ......................... 16 3.4.4 X.25 based packet-mode service in B and D channels ....... 16 3.4.5 SPID handling ............................................ 17 3.4.6 Closed User Groups ....................................... 17 3.4.7 Provision of point-to-point line topology ................ 18 3.4.8 Speech and audio bearer capability information elements .. 18 3.4.9 Attaching incoming calls to router ports ................. 19 3.4.10 Usage of isdnMibDirectoryGroup and isdnDirectoryTable ... 20 4 Definitions .................................................. 21 5 Acknowledgments .............................................. 47 6 References ................................................... 47 7 Security Considerations ...................................... 49 8 Author's Address ............................................. 49 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, STD 15, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. 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) Roeck Standards Track [Page 2] RFC 2127 ISDN MIB March 1997 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 3.1. Structure of the MIB For managing ISDN interfaces, the following information is necessary: o Information for managing physical interfaces. In case of ISDN primary rate, this are usually T1 or E1 lines, being managed in the DS1/E1 MIB [12]. For Basic Rate lines, physical interfaces are managed by this MIB. o Information for managing B channels. o Information for managing signaling channels. o Optionally, information for managing Terminal Endpoints (TE). A Terminal Endpoint is a link layer connection to a switch. o Optionally, information for managing a list of directory numbers. In order to manage connections over ISDN lines, the management of peer information and call history information is required as well. This information is defined in the Dial Control MIB [15]. The purpose for splitting the required information in two MIBs is to be able to use parts of this information for non-ISDN interfaces as well. In particular, the Dial Control MIB might also be used for other types of interfaces, e.g. modems or X.25 virtual connections. Within this document, information has been structured into five groups, which are described in the following chapters. 3.1.1. General Description This MIB controls all aspects of ISDN interfaces. It consists of five groups. o The isdnMibBasicRateGroup is used to provide information regarding physical Basic Rate interfaces. o The isdnMibBearerGroup is used to control B (bearer) channels. Roeck Standards Track [Page 3] RFC 2127 ISDN MIB March 1997 It supports configuration parameters as well as statistical information related to B channels. o The isdnMibSignalingGroup is used to control D (delta) channels. There are three tables in this group. The isdnSignalingTable and isdnSignalingStatsTable support ISDN Network Layer configuration and statistics. The isdnLapdTable supports ISDN Data Link Layer (LAPD) configuration and statistics. o The optional isdnMibEndpointGroup can be used to specify Terminal Endpoints. It is required only if there are non-ISDN endpoints defined for a given D channel, or if additional information like Terminal Endpoint Identifier (TEI) values or Service Profile IDentifiers (SPID) is required to identify a given ISDN user. o The optional isdnMibDirectoryGroup can be used to specify a list of directory numbers for each signaling channel. It is required only if the directory numbers to be accepted differ from the isdnSignalingCallingAddress as specified in the isdnSignalingTable. 3.2. Relationship to the Interfaces MIB This section clarifies the relationship of this MIB to the Interfaces MIB [11]. Several areas of correlation are addressed in the following subsections. The implementor is referred to the Interfaces MIB document in order to understand the general intent of these areas. 3.2.1. Layering Model An ISDN interface usually consists of a D channel and a number of B channels, all of which are layered on top of a physical interface. Furthermore, there are multiple interface layers for each D channel. There are Data Link Layer (LAPD) as well as Network Layer entities. This is accomplished in this MIB by creating a logical interface (ifEntry) for each of the D channel entities and a logical interface (ifEntry) for each of the B channels. These are then correlated to each other and to the physical interface using the ifStack table of the Interfaces MIB [11]. Roeck Standards Track [Page 4] RFC 2127 ISDN MIB March 1997 The basic model, therefore, looks something like this: | | +--+ +--+ | D ch. | |Layer 3| +--+ +--+ | | | | | | <== interface to upper +--+ +--+ +--+ +--+ +--+ +--+ layers, to be provided | D ch. | | B | | B | by ifStack table |Layer 2| |channel| .... |channel| +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | <== attachment to physical +--+ +--------+ +------------+ +----+ interfaces, to be provided | physical interface | by ifStack table | (S/T, U or T1/E1) | +-----------------------------------+ Mapping of B/D channels to physical interfaces Each D channel can support multiple Terminal Endpoints. Terminal Endpoints can either be one or multiple ISDN signaling channels, or channels supporting X.25 based packet mode services. To accomplish this, there can be multiple Network Layer entities on top of each ISDN Data Link Layer (LAPD) interface. The detailed model therefore looks something like this, including interface types as examples: +------+ +----+ +----+ |x25ple| |isdn| |isdn| Terminal Endpoints (X.25 or ISDN) +--+---+ +-+--+ +-+--+ | | | | +------+ | | | <== Interface to upper layers, | | +------------+ | | to be provided by ifStack | | | | | table ++-+-++ +-+-+ +-+-+ |lapd | D channel |ds0| |ds0| B channels +--+--+ Data Link Layer +-+-+ +-+-+ | | | +--+----------------------+------+--------------------+ | ds1 or isdns/isdnu | +-----------------------------------------------------+ Detailed interface mapping IfEntries are maintained for each D channel Network Layer entity (Terminal Endpoint), for LAPD and for each B channel. Roeck Standards Track [Page 5] RFC 2127 ISDN MIB March 1997 The ifType for a Terminal Endpoint can be isdn(63) for ISDN signaling channels or x25ple(40) for X.25 based packet mode services. The ifType for D channel Data Link Layer (LAPD) interfaces is lapd(77). The ifType for B channels is ds0(81). The ifType for physical interfaces is the matching IANA ifType, usually ds1(18) for Primary Rate interfaces or isdns(75)/isdnu(76) for Basic Rate interfaces. The ifStackTable is used to map B channels and LAPD interfaces to physical interfaces and to map D channel Network Layer interfaces (Terminal Endpoints) to LAPD. In the example given above, the assignment of index values could for example be as follows: ifIndex ifType ISDN MIB tables Description indexed by ifIndex 1 isdns(75) isdnBasicRateTable Basic Rate physical interface 2 lapd(77) isdnLapdTable LAPD interface 3 x25ple(40) isdnEndpointTable X.25 Packet Layer 4 isdn(63) isdnSignalingTable ISDN signaling channel #1 isdnEndpointTable 5 isdn(63) isdnSignalingTable ISDN signaling channel #2 isdnEndpointTable 6 ds0(81) isdnBearerTable B channel #1 7 ds0(81) isdnBearerTable B channel #2 8 ppp(23) peer entry #1 (see below) 9 ppp(23) peer entry #2 (see below) Roeck Standards Track [Page 6] RFC 2127 ISDN MIB March 1997 The corresponding ifStack table entries would then be: ifStackTable Entries HigherLayer LowerLayer 0 3 0 4 0 5 0 8 0 9 1 0 2 1 3 2 4 2 5 2 6 1 7 1 8 6 9 7 Mapping of B channels to upper interface layers is usually done using the Dial Control MIB. For example, mapping on top of B channels might look as follows: +-------------------------------------------------------+ | Network Layer Protocol | +------+ +-------+ +-------+ +-------+ +-------+ +------+ | | | | | | | | | | <== appears active +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | PPP | | PPP | | F/R | | PPP | | F/R | | for | | for | | for | | for | | for | ifEntry with |Peer1| |Peer2| |switch |Peer3| |switch shadow PeerEntry | | | | | A | | | | B | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | | | | <== some actually are +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | B | | B | | B | | B | | B | |channel| |channel| |channel| |channel| |channel| +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | +------+ +-------+ +-------+ +-------+ +-------+ +------+ | Basic/Primary Rate Interface | +-------------------------------------------------------+ Mapping of IP interfaces to Called Peers to B Channels Roeck Standards Track [Page 7] RFC 2127 ISDN MIB March 1997 In this model, ifEntries are maintained for each peer. Each peer is required to have an associated ifEntry. This interface can be of any kind, e.g. PPP or LAPB. The Dial Control MIB can be used for all types of demand-access interfaces, e.g., ISDN, modems or X.25 virtual connections. 3.2.2. ifTestTable The ifTestTable is not supported by this MIB. 3.2.3. ifRcvAddressTable The ifRcvAddressTable is not supported by this MIB. 3.2.4. ifEntry 3.2.4.1. ifEntry for a Basic Rate hardware interface The ifGeneralGroup is supported for Basic Rate hardware interfaces. ifTable Comments ============== =========================================== ifIndex Each ISDN Basic Rate hardware interface is represented by an ifEntry. ifDescr Textual port description. ifType The IANA value of isdns(75) or isdnu(76), whichever is appropriate. ifSpeed The overall bandwidth of this interface. ifPhysAddress Return an empty string. ifAdminStatus The administrative status of the ISDN interface. ifOperStatus The current operational status of this interface. The operational status is dormant(5) if the interface is in standby mode, i.e. connected to the network, but without call activity. The operational status is down(2) if the hardware has detected that there is no layer 1 connection to the switch. For other values, refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB. Roeck Standards Track [Page 8] RFC 2127 ISDN MIB March 1997 ifLinkUpDownTrapEnable Refer to the Interfaces MIB. ifConnectorPresent Refer to the Interfaces MIB. ifHighSpeed Return zero. ifName Refer to the Interfaces MIB. 3.2.4.2. ifEntry for a B channel The ifEntry for a B channel supports the ifGeneralGroup of the Interfaces MIB. ifTable Comments ============== =========================================== ifIndex Each ISDN B channel is represented by an ifEntry. ifDescr Textual port description. ifType The IANA value of ds0(81). ifSpeed The bandwidth of this B channel. Usually, this is the value of 56000 or 64000. ifPhysAddress Return an empty string. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of this interface. Note that dormant(5) is explicitly being used as defined in the Interfaces MIB. For other values, refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB. ifLinkUpDownTrapEnable Refer to the Interfaces MIB. ifConnectorPresent Refer to the Interfaces MIB. ifHighSpeed Return zero. ifName Refer to the Interfaces MIB. Roeck Standards Track [Page 9] RFC 2127 ISDN MIB March 1997 3.2.4.3. ifEntry for LAPD (D channel Data Link Layer) The ifEntry for LAPD (D channel Data Link Layer) supports the ifGeneralGroup and the ifPacketGroup of the Interfaces MIB. ifTable Comments ============== =========================================== ifIndex Each ISDN D channel Data Link layer is represented by an ifEntry. ifDescr Textual port description. ifType The IANA value of lapd(77). ifSpeed The bandwidth of this interface. Usually, this is the value of 16000 for basic rate interfaces or 64000 for primary rate interfaces. ifPhysAddress Return an empty string. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of the ISDN LAPD interface. The operational status is dormant(5) if the interface is in standby mode (see Q.931 [8], Annex F, D channel backup procedures). For other values, refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB. ifLinkUpDownTrapEnable Refer to the Interfaces MIB. ifConnectorPresent Refer to the Interfaces MIB. ifHighSpeed Return zero. ifName Refer to the Interfaces MIB. ifMtu The size of the largest frame which can be sent/received on this interface, specified in octets. Usually, this is the default value of 260 as specified in Q.921 [6], chapter 5.9.3. Roeck Standards Track [Page 10] RFC 2127 ISDN MIB March 1997 ifInOctets The total number of octets received on this interface. ifInUcastPkts The number of frames received on this interface whose address is not TEI=127. ifInNUcastPkts Deprecated. Return the number of frames received on this interface with TEI=127. ifInMulticastPkts Return zero. ifInBroadcastPkts Return the number of frames received on this interface with TEI=127. ifInDiscards The total number of received frames which have been discarded. The possible reasons are: buffer shortage. ifInErrors The number of inbound frames that contained errors preventing them from being deliverable to LAPD. ifInUnknownProtos The number of frames with known TEI, but unknown SAPI (Service Access Point Identifier, see Q.921 [6], chapter 3.3.3). ifOutOctets The total number of octets transmitted on this interface. ifOutUcastPkts The number of frames transmitted on this interface whose address is not TEI=127. ifOutNUcastPkts Deprecated. Return the number of frames transmitted on this interface with TEI=127. ifOutMulticastPkts Return zero. ifOutBroadcastPkts Return the number of frames transmitted on this interface with TEI=127. ifOutDiscards The total number of outbound frames which were discarded. Possible reasons are: buffer shortage. ifOutErrors The number of frames which could not be transmitted due to errors. Roeck Standards Track [Page 11] RFC 2127 ISDN MIB March 1997 ifOutQlen Deprecated. Return zero. ifSpecific Deprecated. Return {0 0}. 3.2.4.4. ifEntry for a signaling channel The ifEntry for a signaling channel supports the ifGeneralGroup and the ifPacketGroup of the Interfaces MIB. ifTable Comments ============== =========================================== ifIndex Each ISDN signaling channel is represented by an ifEntry. ifDescr Textual port description. ifType The IANA value of isdn(63). ifSpeed The bandwidth of this signaling channel. Usually, this is the same value as for LAPD, i.e. 16000 for basic rate interfaces or 64000 for primary rate interfaces. ifPhysAddress The ISDN address assigned to this signaling channel. This is a copy of isdnSignalingCallingAddress. ifAdminStatus The administrative status of the signaling channel. ifOperStatus The current operational status of this signaling channel. The operational status is dormant(5) if the signaling channel is currently not activated. For other values, refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB. ifLinkUpDownTrapEnable Refer to the Interfaces MIB. ifConnectorPresent Refer to the Interfaces MIB. ifHighSpeed Return zero. ifName Refer to the Interfaces MIB. Roeck Standards Track [Page 12] RFC 2127 ISDN MIB March 1997 ifMtu The size of the largest frame which can be sent/received on this signaling channel, specified in octets. Usually, this is the default value of 260 as specified in Q.921 [6], chapter 5.9.3. ifInOctets The total number of octets received on this signaling channel. ifInUcastPkts The number of frames received which are targeted to this channel. ifInNUcastPkts Deprecated. Return the number of frames received on this signaling channel with TEI=127. ifInMulticastPkts Return zero. ifInBroadcastPkts Return the number of frames received on this signaling channel with TEI=127. ifInDiscards The total number of received frames which have been discarded. The possible reasons are: buffer shortage. ifInErrors The number of inbound frames that contained errors preventing them from being deliverable to the signaling channel. ifInUnknownProtos Return zero. ifOutOctets The total number of octets transmitted on this signaling channel. ifOutUcastPkts The number of frames transmitted on this signaling channel whose address is not TEI=127. ifOutNUcastPkts Deprecated. Return the number of frames transmitted on this signaling channel with TEI=127. ifOutMulticastPkts Return zero. ifOutBroadcastPkts Return the number of frames transmitted on this signaling channel with TEI=127. Roeck Standards Track [Page 13] RFC 2127 ISDN MIB March 1997 ifOutDiscards The total number of outbound frames which were discarded. Possible reasons are: buffer shortage. ifOutErrors The number of frames which could not be transmitted due to errors. ifOutQlen Deprecated. Return zero. ifSpecific Deprecated. Return {0 0}. 3.3. Relationship to other MIBs 3.3.1. Relationship to the DS1/E1 MIB Implementation of the DS1/E1 MIB [12] is not required for supporting this MIB. It is however recommended to implement the DS1/E1 MIB on entities supporting Primary Rate interfaces. 3.3.2. Relationship to the DS0 and DS0Bundle MIBs Implementation of the DS0 MIB [13] is optional. Implementation of the DS0Bundle MIB [13] may be required only if hyperchannels are to be supported, depending on the multiplexing scheme used in a given implementation. See chapter 3.4.2 for details on how to implement hyperchannels. 3.3.3. Relationship to the Dial Control MIB Implementation of the Dial Control MIB [15] is required. 3.4. ISDN interface specific information and implementation hints 3.4.1. ISDN leased lines ISDN leased lines can be specified on a per-B-channel basis. To do so, the value of isdnBearerChannelType has to be set to leased(2). There is no signaling protocol support for leased line B channels, since there is no signaling protocol action for these kinds of interfaces. Roeck Standards Track [Page 14] RFC 2127 ISDN MIB March 1997 If there is no signaling support available for an ISDN interface, this must be specified in the appropriate interface specific table. For Basic Rate interfaces, isdnBasicRateSignalMode of isdnBasicRateTable must be set to inactive(2). For Primary Rate interfaces, dsx1SignalMode of dsx1ConfigTable in DS1/E1 MIB [12] must be set to none(1). There are no isdnLapdTable or isdnSignalingTable entries for such interfaces. Depending on the leased line type and the service provider, the D channel can be used for data transfer. If this is the case the D channel interface type is ds0(81) instead of lapd(77) and its usage is identical to B channel usage if there is no signaling channel available. For a Primary Rate interface which is entirely used as a leased line, there is no ISDN specific information available or required. Such leased lines can entirely be handled by the DS1/E1 MIB. 3.4.2. Hyperchannels The active switch protocol defines if hyperchannels are supported, and the actual support is implementation dependent. Hyperchannel connections will be requested by the interface user at call setup time, e.g. by the peer connection handling procedures. In the ISDN MIB, the isdnBearerMultirate object of isdnBearerTable can be used to check if hyperchannels are being used for an active call. If hyperchannels are being used, multiplexing between the encapsulation layer and the B channels is required, since there is one encapsulation layer interface connected to several B channel interfaces. This can be accomplished in two ways. o The DS0Bundle MIB [13] can be used to provide the multiplexing. See the DS0Bundle MIB document for details. o The ifStackTable can be used to provide the multiplexing. In this case, there are several ifStackTable entries with the same value of HigherLayer, and different values of LowerLayer. It is up to the implementor to decide which multiplexing scheme to use. Each hyperchannel call is treated as one call in the isdnSignalingStatsTable, independent of the number of B channels involved. Roeck Standards Track [Page 15] RFC 2127 ISDN MIB March 1997 For a hyperchannel call, all objects in the isdnBearerTable entries related to this call (i.e., all isdnBearerTable entries associated to B channels used by the hyperchannel) have identical values. The related objects in the isdnBearerTable are: isdnBearerPeerAddress isdnBearerPeerSubAddress isdnBearerCallOrigin isdnBearerInfoType isdnBearerMultirate isdnBearerCallSetupTime isdnBearerCallConnectTime isdnBearerChargedUnits 3.4.3. D channel backup and NFAS trunks D channel backup is defined in Q.931 [8], Annex F. It describes Non- Associated signaling and its use and functionality is basically identical to Non Facility Associated Signaling (NFAS) trunks. Non Facility Accociated Signaling (NFAS) basically means that a D channel on a PRI interface is used to manage calls on other PRI trunks. This is required in North America for H11 channels, since all 24 time slots are being used for B channels. According to Q.931, Annex F, the D channel backup feature can be provided on a subscription basis and is network dependent. The D channel backup procedure is described in detail in Q.931. For D channel backup, the controlling isdnSignalingTable entry is layered on top of all attached LAPD interfaces. This layering is done using the ifStack table. There is only one active LAPD interface, however. Inactive LAPD interfaces have an ifOperStatus of dormant(5). NFAS trunks are also handled using the ifStack table. In this case, a signaling channel is layered on top of a LAPD interface as well as on top of all physical interfaces which are controlled by the signaling channel, but do not supply a D channel. 3.4.4. X.25 based packet-mode service in B and D channels X.25 based packet mode service over B channels can be handled using the Dial Control MIB by creating an appropriate peer entry. The peer entry ifType can then be x25(5), thus providing access to X.25 service. Roeck Standards Track [Page 16] RFC 2127 ISDN MIB March 1997 X.25 based packet mode service over D channels can be handled by creating an ifEndpointTable entry with an isdnEndpointIfType of x25ple(40). The upper protocol layers can then be attached to this interface using the ifStack table. 3.4.5. SPID handling Service Profile IDentifiers (SPIDs) are defined for BRI interfaces only, and being used in North America. SPIDs are required for DMS- 100, NI-1 and NI-2, and are optional for 5ESS. A switch can define up to 8 SPIDs per BRI. Each Terminal Endpoint has a SPID assigned. It is normally built from the party number (calling address for outgoing calls) with a number of digits prepended and appended. Since each network appears to be different, both the calling address and the SPID have to be stored. The SPID identifies the particular services that have been provisioned for a terminal. If there are two B channels on a BRI, there can be two SPIDs, one for each of the two B channels. There can also be a single SPID, providing access to both B channels. The SPID gets registered with the switch after link establishment. There is one data link for each SPID. As part of terminal registration, an EID (Endpoint IDentifier) is defined by the switch. On incoming calls, the switch may provide the EID, a called party number, or both, depending on the ISDN code implemented in the switch. The EID has two bytes: USID (User Service IDentifier) and TID (Terminal IDentifier). These are later used by some of the software versions running on the switch side (e.g. compliant with NI-1, 5ESS custom) to broadcast SETUP messages with these included, so the correct endpoint would accept the call. Other switch software versions identify the endpoint with the Called Party Number. In the ISDN MIB, the SPID can be entered using the isdnEndpointSpid object of isdnEndpointTable. The isdnSignalingCallingAddress, already being used to specify the calling number, cannot be used to record the SPID since the values of the SPID and the Calling Address may differ and both may be required to be present. 3.4.6. Closed User Groups Closed User Groups (CUG), as defined in I.255.1 [14], are supported for circuit mode calls by ETSI (ETS 300 138) and 1TR6. In these networks, an ISDN address can have one or more Closed User Groups Roeck Standards Track [Page 17] RFC 2127 ISDN MIB March 1997 assigned. If there is more than one Closed User Group assigned to a given address, one of those is the preferred Closed User Group. For such addresses, only calls from assigned Closed User Groups are accepted by the network. Thus, Closed User Groups are a parameter for peer entries and are defined in the Dial Control MIB. A peer entry attached to a Closed User Group has to point to an ISDN interface which is attached to the Closed User Group in question. 3.4.7. Provision of point-to-point line topology In the ISDN standards, there are two different meanings for the term "point-to-point". In ISDN standards, the term point-to-point are usually used for data link connections, i.e. layer 2 connections, where each layer 2 connection from the TE to the network is a single point-to-point connection. Multiple connections of this kind may exist on one physical (layer 1) connection, however, and in case of Basic Rate interfaces there may be several TE's connected to one physical line to the network. The second meaning of "point-to-point" refers to the line topology, i.e. to layer 1 connections. For Primary Rate interfaces, the line topology is always point-to-point. For Basic Rate interfaces, layer 1 point-to- point connections do exist in several countries, usually being used for connecting PBX systems to the network. The second meaning (layer 1 connections) is what will be referred to as "point-to-point" connection throughout this document. For Basic Rate interfaces, the isdnBasicRateTable object isdnBasicRateLineTopology can be used to select the line topology. 3.4.8. Speech and audio bearer capability information elements The objects speech(2), audio31(6) and audio7(7), as being used in isdnBearerInfoType, refer to the Speech, 3.1 kHz Audio and old 7 kHz Audio (now Multi-use) bearer capabilities for ISDN, as defined in Q.931 [8], chapter 4.5.5, octet 3 of bearer capability information element. These capabilities are signaling artifices that allow networks to do certain things with the call. It is up to the network to decide what to do. Roeck Standards Track [Page 18] RFC 2127 ISDN MIB March 1997 The Speech Bearer Capability means that speech is being carried over the channel, as in two people talking. This would be POTS-type speech. The network may compress this, encrypt it or whatever it wants with it as long as it delivers POTS quality speech to the other end. In other words, a modem is not guaranteed to work over this connection. The 3.1 kHz Audio capability indicates that the network carries the 3.1 kHz bandwidth across the network. This would (theoretically) allow modem signals to be carried across the network. In the US, the network automatically enters a capability of 3.1 kHz Audio on calls coming into the ISDN from a POTS network. This capability restricts the network from interfering with the data channel in a way that would corrupt the 3.1 kHz VoiceBand data. 7 kHz Audio was meant to signal the use of a higher quality audio connection (e.g., music from radio). It was changed to Multi-Use capability to allow it to be used for video-conferencing with fall back to audio. In some cases, the Speech or 3.1 kHz Bearer Capability provides a 56 kbit/s data path through the network. Therefore, some people are setting up calls with the Speech or 3.1 kHz BC and transmitting 56 kbit/s data over the connection. This is usually to take advantage of favorable tariffs for Speech as opposed to Data. On the incoming side, the equipment is usually configured to ignore the Bearer Capability and either answer all Speech calls as 56 kbit/s data or to use one Directory Number for real speech and another for data. 3.4.9. Attaching incoming calls to router ports In ISDN, there are several ways to identify an incoming call and to attach a router port to this call. o The call can be identified and attached to a router port using the ISDN Calling Address, that is, the peer ISDN address. Since the peer address is defined in a Dial Control MIB configuration entry for this peer, this would be the most natural way to attach an incoming call to a router port. In this configuration, only a single isdnSignalingTable entry is required for each physical ISDN interface. Unfortunately, the ISDN Calling Address is not available in all countries and/or switch protocols. Therefore, other means for attaching incoming calls to router ports must be provided. Roeck Standards Track [Page 19] RFC 2127 ISDN MIB March 1997 o The call can also be identified and attached to a router port using the ISDN Called Address. In this case, a distinct ISDN address or subaddress must be specified for each of the router ports. This can be accomplished in the ISDN MIB by creating a isdnSignalingTable entry for each of the router ports, and by connecting Dial Control MIB peer entries to the thereby created interface using the dialCtlPeerCfgLowerIf object of dialCtlPeerCfgTable. If this type of router port identification is used in an implementation, it is up to the implementor to decide if there should be distinct TEI values assigned for each of the isdnSignalingTable entries. For this reason, the isdnEndpointTable permits specifying the same TEI value in multiple entries. It is recommended to use dynamic TEI assignment whenever possible. The implementor should be aware that this type of configuration requires a lot of configuration work for the customer, since an entry in isdnSignalingTable must be created for each of the router ports. o Incoming calls can also be identified and attached to router ports using a higher layer functionality, such as PPP authentication. Defining this functionality is outside the scope of this document. 3.4.10. Usage of isdnMibDirectoryGroup and isdnDirectoryTable In some switch protocol or PBX implementations, the Called Number Information Element on incoming calls can differ from the Calling Number on outgoing calls. Sometimes, the Called Number can be different for incoming Local Calls, Long Distance Calls and International Calls. For Hunt Groups, the Called Number can be any of the numbers in the Hunt Group. The isdnDirectoryTable can be used to specify all these numbers. Entries in the isdnDirectoryTable are always connected to specific isdnSignalingTable entries. No ifEntry is created for isdnDirectoryTable entries. Therefore, the isdnDirectoryTable can not be used to attach incoming calls to router ports. For router port identification, isdnSignalingTable entries should be created instead. Roeck Standards Track [Page 20] RFC 2127 ISDN MIB March 1997 4. Definitions ISDN-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Counter32, Gauge32, Integer32 FROM SNMPv2-SMI DisplayString, TruthValue, TimeStamp, RowStatus, TestAndIncr, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB IANAifType FROM IANAifType-MIB transmission FROM RFC1213-MIB; isdnMib MODULE-IDENTITY LAST-UPDATED "9609231642Z" -- Sep 23, 1996 ORGANIZATION "IETF ISDN MIB Working Group" CONTACT-INFO " Guenter Roeck Postal: cisco Systems 170 West Tasman Drive San Jose, CA 95134 U.S.A. Phone: +1 408 527 3143 E-mail: groeck@cisco.com" DESCRIPTION "The MIB module to describe the management of ISDN interfaces." ::= { transmission 20 } -- The ISDN hardware interface (BRI or PRI) is represented Roeck Standards Track [Page 21] RFC 2127 ISDN MIB March 1997 -- by a media specific ifEntry. -- -- For basic rate lines, the media specifics for the physical interface -- is defined in the physical interface group of the ISDN MIB. -- The ifType for physical basic rate interfaces is isdns(75) -- or isdnu(76), whichever is appropriate. -- -- For primary rate, the media specifics are defined in the Trunk -- MIB and the ifType has a value of ds1(18). -- Each signaling channel is represented by an entry -- in the isdnSignalingTable. -- The signaling channel has an ifType value of isdn(63). -- Each B channel is also represented as an entry -- in the ifTable. The B channels have an ifType value -- of ds0(81). -- This model is used while defining objects and tables -- for management. -- The ISDN MIB allows sub-layers. For example, the data transfer -- over a B channel may take place with PPP encapsulation. While the -- ISDN MIB describes the D and B channels, a media specific MIB -- for PPP can be used on a layered basis. This is as per -- the interfaces MIB. -- Textual conventions IsdnSignalingProtocol ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the isdnSignalingProtocol object in the definition of ISDN-MIB's isdnSignalingTable. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@iana.org)." SYNTAX INTEGER { other(1), -- none of the following dss1(2), -- ITU DSS1 (formerly CCITT) Q.931 etsi(3), -- Europe / ETSI ETS300-102 -- plus supplementary services Roeck Standards Track [Page 22] RFC 2127 ISDN MIB March 1997 -- (ETSI 300-xxx) -- note that NET3, NET5 define -- test procedures for ETS300-102 -- and have been replaced by -- I-CTR 3 and I-CTR 4. dass2(4), -- U.K. / DASS2 (PRI) ess4(5), -- U.S.A. / AT&T 4ESS ess5(6), -- U.S.A. / AT&T 5ESS dms100(7), -- U.S.A. / Northern Telecom DMS100 dms250(8), -- U.S.A. / Northern Telecom DMS250 ni1(9), -- U.S.A. / National ISDN 1 (BRI) ni2(10), -- U.S.A. / National ISDN 2 (BRI, PRI) ni3(11), -- U.S.A. / next one vn2(12), -- France / VN2 vn3(13), -- France / VN3 vn4(14), -- France / VN4 (ETSI with changes) vn6(15), -- France / VN6 (ETSI with changes) -- delta document CSE P 10-21 A -- test document CSE P 10-20 A kdd(16), -- Japan / KDD ins64(17), -- Japan / NTT INS64 ins1500(18), -- Japan / NTT INS1500 itr6(19), -- Germany/ 1TR6 (BRI, PRI) cornet(20), -- Germany/ Siemens HiCom CORNET ts013(21), -- Australia / TS013 -- (formerly TPH 1962, BRI) ts014(22), -- Australia / TS014 -- (formerly TPH 1856, PRI) qsig(23), -- Q.SIG swissnet2(24), -- SwissNet-2 swissnet3(25) -- SwissNet-3 } -- Isdn Mib objects definitions isdnMibObjects OBJECT IDENTIFIER ::= { isdnMib 1 } -- ISDN physical interface group -- This group describes physical basic rate interfaces. isdnBasicRateGroup OBJECT IDENTIFIER ::= { isdnMibObjects 1 } isdnBasicRateTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnBasicRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Roeck Standards Track [Page 23] RFC 2127 ISDN MIB March 1997 "Table containing configuration and operational parameters for all physical Basic Rate interfaces on this managed device." ::= { isdnBasicRateGroup 1 } isdnBasicRateEntry OBJECT-TYPE SYNTAX IsdnBasicRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ISDN Basic Rate Table." INDEX { ifIndex } ::= { isdnBasicRateTable 1 } IsdnBasicRateEntry ::= SEQUENCE { isdnBasicRateIfType INTEGER, isdnBasicRateLineTopology INTEGER, isdnBasicRateIfMode INTEGER, isdnBasicRateSignalMode INTEGER } isdnBasicRateIfType OBJECT-TYPE SYNTAX INTEGER { isdns(75), isdnu(76) } MAX-ACCESS read-write STATUS current DESCRIPTION "The physical interface type. For 'S/T' interfaces, also called 'Four-wire Basic Access Interface', the value of this object is isdns(75). For 'U' interfaces, also called 'Two-wire Basic Access Interface', the value of this object is isdnu(76)." ::= { isdnBasicRateEntry 1 } isdnBasicRateLineTopology OBJECT-TYPE SYNTAX INTEGER { pointToPoint(1), pointToMultipoint(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The line topology to be used for this interface. Note that setting isdnBasicRateIfType to isdns(75) does not necessarily mean a line topology of Roeck Standards Track [Page 24] RFC 2127 ISDN MIB March 1997 point-to-multipoint." ::= { isdnBasicRateEntry 2 } isdnBasicRateIfMode OBJECT-TYPE SYNTAX INTEGER { te(1), nt(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The physical interface mode. For TE mode, the value of this object is te(1). For NT mode, the value of this object is nt(2)." ::= { isdnBasicRateEntry 3 } isdnBasicRateSignalMode OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The signaling channel operational mode for this interface. If active(1) there is a signaling channel on this interface. If inactive(2) a signaling channel is not available." ::= { isdnBasicRateEntry 4 } -- The B channel (bearer channel) group -- Note that disconnects can explicitely be handled using the -- ifStack table. If a connection is to be disconnected, -- the according ifStack entry has to be removed. -- More specifically, the ifStackTable entry which binds the high-layer -- ifTable entry (and related dialCtlNbrCfgTable entry) to the -- B channel ifTable entry (and related isdnBearerTable entry) -- during an active call has to be removed. isdnBearerGroup OBJECT IDENTIFIER ::= { isdnMibObjects 2 } isdnBearerTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnBearerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines port specific operational, statistics Roeck Standards Track [Page 25] RFC 2127 ISDN MIB March 1997 and active call data for ISDN B channels. Each entry in this table describes one B (bearer) channel." ::= { isdnBearerGroup 1 } isdnBearerEntry OBJECT-TYPE SYNTAX IsdnBearerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Operational and statistics information relating to one port. A port is a single B channel." INDEX { ifIndex } ::= { isdnBearerTable 1 } IsdnBearerEntry ::= SEQUENCE { isdnBearerChannelType INTEGER, isdnBearerOperStatus INTEGER, isdnBearerChannelNumber INTEGER, isdnBearerPeerAddress DisplayString, isdnBearerPeerSubAddress DisplayString, isdnBearerCallOrigin INTEGER, isdnBearerInfoType INTEGER, isdnBearerMultirate TruthValue, isdnBearerCallSetupTime TimeStamp, isdnBearerCallConnectTime TimeStamp, isdnBearerChargedUnits Gauge32 } isdnBearerChannelType OBJECT-TYPE SYNTAX INTEGER { dialup(1), leased(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The B channel type. If the B channel is connected to a dialup line, this object has a value of dialup(1). In this case, it is controlled by an associated signaling channel. If the B channel is connected to a leased line, this object has a value of leased(2). For leased line B channels, there is no signaling channel control available." ::= { isdnBearerEntry 1 } isdnBearerOperStatus OBJECT-TYPE SYNTAX INTEGER { Roeck Standards Track [Page 26] RFC 2127 ISDN MIB March 1997 idle(1), connecting(2), connected(3), active(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current call control state for this port. idle(1): The B channel is idle. No call or call attempt is going on. connecting(2): A connection attempt (outgoing call) is being made on this interface. connected(3): An incoming call is in the process of validation. active(4): A call is active on this interface." ::= { isdnBearerEntry 2 } isdnBearerChannelNumber OBJECT-TYPE SYNTAX INTEGER (1..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The identifier being used by a signaling protocol to identify this B channel, also referred to as B channel number. If the Agent also supports the DS0 MIB, the values of isdnBearerChannelNumber and dsx0Ds0Number must be identical for a given B channel." ::= { isdnBearerEntry 3 } isdnBearerPeerAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The ISDN address the current or last call is or was connected to. In some cases, the format of this information can not be predicted, since it largely depends on the type of switch or PBX the device is connected to. Therefore, the detailed format of this information is not specified and is implementation dependent. If possible, the agent should supply this information using the E.164 format. In this case, the number must start with '+'. Otherwise, IA5 number digits must be used. Roeck Standards Track [Page 27] RFC 2127 ISDN MIB March 1997 If the peer ISDN address is not available, this object has a length of zero." REFERENCE "ITU-T E.164, Q.931 chapter 4.5.10" ::= { isdnBearerEntry 4 } isdnBearerPeerSubAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The ISDN subaddress the current or last call is or was connected to. The subaddress is an user supplied string of up to 20 IA5 characters and is transmitted transparently through the network. If the peer subaddress is not available, this object has a length of zero." REFERENCE "ITU-T I.330, Q.931 chapter 4.5.11" ::= { isdnBearerEntry 5 } isdnBearerCallOrigin OBJECT-TYPE SYNTAX INTEGER { unknown(1), originate(2), answer(3), callback(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The call origin for the current or last call. If since system startup there was no call on this interface, this object has a value of unknown(1)." ::= { isdnBearerEntry 6 } isdnBearerInfoType OBJECT-TYPE SYNTAX INTEGER { unknown(1), speech(2), unrestrictedDigital(3), -- as defined in Q.931 unrestrictedDigital56(4), -- with 56k rate adaption restrictedDigital(5), audio31(6), -- 3.1 kHz audio audio7(7), -- 7 kHz audio Roeck Standards Track [Page 28] RFC 2127 ISDN MIB March 1997 video(8), packetSwitched(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The Information Transfer Capability for the current or last call. speech(2) refers to a non-data connection, whereas audio31(6) and audio7(7) refer to data mode connections. Note that Q.931, chapter 4.5.5, originally defined audio7(7) as '7 kHz audio' and now defines it as 'Unrestricted digital information with tones/ announcements'. If since system startup there has been no call on this interface, this object has a value of unknown(1)." REFERENCE "Q.931 [8], chapter 4.5.5, octet 3 of bearer capability information element, combined with the User Rate (as defined in octets 5 and 5a to 5d), if rate adaption is being used." ::= { isdnBearerEntry 7 } isdnBearerMultirate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This flag indicates if the current or last call used multirate. The actual information transfer rate, in detail specified in octet 4.1 (rate multiplier), is the sum of all B channel ifSpeed values for the hyperchannel. If since system startup there was no call on this interface, this object has a value of false(2)." REFERENCE "Q.931 [8], chapter 4.5.5." ::= { isdnBearerEntry 8 } isdnBearerCallSetupTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Roeck Standards Track [Page 29] RFC 2127 ISDN MIB March 1997 "The value of sysUpTime when the ISDN setup message for the current or last call was sent or received. If since system startup there has been no call on this interface, this object has a value of zero." ::= { isdnBearerEntry 9 } isdnBearerCallConnectTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the ISDN connect message for the current or last call was sent or received. If since system startup there has been no call on this interface, this object has a value of zero." ::= { isdnBearerEntry 10 } isdnBearerChargedUnits OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of charged units for the current or last connection. For incoming calls or if charging information is not supplied by the switch, the value of this object is zero." ::= { isdnBearerEntry 11 } -- ISDN signaling group isdnSignalingGroup OBJECT IDENTIFIER ::= { isdnMibObjects 3 } -- signaling channel configuration table -- There is one entry in this table for each Terminal Endpoint -- (link layer connection to the switch). -- Usually, there is one endpoint per D channel. In some -- cases, however, there can be multiple endpoints. -- Thus, entries in this table can be created and deleted. -- This also means the creation of an associated ifEntry. -- -- D channel backup and NFAS trunks are handled using the -- ifStack table. -- In case of D channel backup, there are multiple -- Data Link Layer (LAPD) interfaces. Only one interface is -- active; all others are dormant(5). -- In case of NFAS trunks, one lower interface is the -- LAPD interface, while the other lower interfaces are physical -- interfaces. Roeck Standards Track [Page 30] RFC 2127 ISDN MIB March 1997 -- If directory number and calling address differ from each other -- or multiple directory numbers are being used, -- the isdnDirectoryTable has to be used to enter such -- directory numbers. isdnSignalingGetIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "The recommended procedure for selecting a new index for isdnSignalingTable row creation is to GET the value of this object, and then to SET the object with the same value. If the SET operation succeeds, the manager can use this value as an index to create a new row in this table." REFERENCE "RFC1903, TestAndIncr textual convention." ::= { isdnSignalingGroup 1 } isdnSignalingTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnSignalingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "ISDN signaling table containing configuration and operational parameters for all ISDN signaling channels on this managed device." ::= { isdnSignalingGroup 2 } isdnSignalingEntry OBJECT-TYPE SYNTAX IsdnSignalingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ISDN Signaling Table. To create a new entry, only isdnSignalingProtocol needs to be specified before isdnSignalingStatus can become active(1)." INDEX { isdnSignalingIndex } ::= { isdnSignalingTable 1 } IsdnSignalingEntry ::= SEQUENCE { isdnSignalingIndex INTEGER, isdnSignalingIfIndex InterfaceIndex, isdnSignalingProtocol IsdnSignalingProtocol, isdnSignalingCallingAddress DisplayString, isdnSignalingSubAddress DisplayString, isdnSignalingBchannelCount Integer32, isdnSignalingInfoTrapEnable INTEGER, Roeck Standards Track [Page 31] RFC 2127 ISDN MIB March 1997 isdnSignalingStatus RowStatus } isdnSignalingIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value which uniquely identifies an entry in the isdnSignalingTable." ::= { isdnSignalingEntry 1 } isdnSignalingIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the interface associated with this signaling channel." ::= { isdnSignalingEntry 2 } isdnSignalingProtocol OBJECT-TYPE SYNTAX IsdnSignalingProtocol MAX-ACCESS read-create STATUS current DESCRIPTION "The particular protocol type supported by the switch providing access to the ISDN network to which this signaling channel is connected." ::= { isdnSignalingEntry 3 } isdnSignalingCallingAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The ISDN Address to be assigned to this signaling channel. More specifically, this is the 'Calling Address information element' as being passed to the switch in outgoing call setup messages. It can be an EAZ (1TR6), a calling number (DSS1, ETSI) or any other number necessary to identify a signaling interface. If there is no such number defined or required, this is a zero length string. It is represented in DisplayString form. Incoming calls can also be identified by this number. Roeck Standards Track [Page 32] RFC 2127 ISDN MIB March 1997 If the Directory Number, i.e. the Called Number in incoming calls, is different to this number, the isdnDirectoryTable has to be used to specify all possible Directory Numbers. The format of this information largely depends on the type of switch or PBX the device is connected to. Therefore, the detailed format of this information is not specified and is implementation dependent. If possible, the agent should implement this information using the E.164 number format. In this case, the number must start with '+'. Otherwise, IA5 number digits must be used." REFERENCE "ITU-T E.164, Q.931 chapter 4.5.10" DEFVAL { "" } ::= { isdnSignalingEntry 4 } isdnSignalingSubAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "Supplementary information to the ISDN address assigned to this signaling channel. Usually, this is the subaddress as defined in Q.931. If there is no such number defined or required, this is a zero length string. The subaddress is used for incoming calls as well as for outgoing calls. The subaddress is an user supplied string of up to 20 IA5 characters and is transmitted transparently through the network." REFERENCE "ITU-T I.330, Q.931 chapter 4.5.11" DEFVAL { "" } ::= { isdnSignalingEntry 5 } isdnSignalingBchannelCount OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The total number of B channels (bearer channels) managed by this signaling channel. The default value of this object depends on the physical interface type and is either 2 for Basic Rate interfaces or Roeck Standards Track [Page 33] RFC 2127 ISDN MIB March 1997 24 (30) for Primary Rate interfaces." ::= { isdnSignalingEntry 6 } isdnSignalingInfoTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether isdnMibCallInformation traps should be generated for calls on this signaling channel." DEFVAL { disabled } ::= { isdnSignalingEntry 7 } isdnSignalingStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the isdnSignalingTable." ::= { isdnSignalingEntry 8 } -- Signaling channel statistics table -- There is one entry for each signaling connection -- in this table. -- Note that the ifEntry also has some statistics information. isdnSignalingStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnSignalingStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "ISDN signaling table containing statistics information for all ISDN signaling channels on this managed device. Only statistical information which is not already being counted in the ifTable is being defined in this table." ::= { isdnSignalingGroup 3 } isdnSignalingStatsEntry OBJECT-TYPE SYNTAX IsdnSignalingStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Roeck Standards Track [Page 34] RFC 2127 ISDN MIB March 1997 "An entry in the ISDN Signaling statistics Table." AUGMENTS { isdnSignalingEntry } ::= { isdnSignalingStatsTable 1 } IsdnSignalingStatsEntry ::= SEQUENCE { isdnSigStatsInCalls Counter32, isdnSigStatsInConnected Counter32, isdnSigStatsOutCalls Counter32, isdnSigStatsOutConnected Counter32, isdnSigStatsChargedUnits Counter32 } isdnSigStatsInCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming calls on this interface." ::= { isdnSignalingStatsEntry 1 } isdnSigStatsInConnected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming calls on this interface which were actually connected." ::= { isdnSignalingStatsEntry 2 } isdnSigStatsOutCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outgoing calls on this interface." ::= { isdnSignalingStatsEntry 3 } isdnSigStatsOutConnected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outgoing calls on this interface which were actually connected." ::= { isdnSignalingStatsEntry 4 } isdnSigStatsChargedUnits OBJECT-TYPE SYNTAX Counter32 Roeck Standards Track [Page 35] RFC 2127 ISDN MIB March 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of charging units on this interface since system startup. Only the charging units applying to the local interface, i.e. for originated calls or for calls with 'Reverse charging' being active, are counted here." ::= { isdnSignalingStatsEntry 5 } -- -- The LAPD table isdnLapdTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnLapdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing configuration and statistics information for all LAPD (D channel Data Link) interfaces on this managed device. Only statistical information which is not already being counted in the ifTable is being defined in this table." ::= { isdnSignalingGroup 4 } isdnLapdEntry OBJECT-TYPE SYNTAX IsdnLapdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the LAPD Table." INDEX { ifIndex } ::= { isdnLapdTable 1 } IsdnLapdEntry ::= SEQUENCE { isdnLapdPrimaryChannel TruthValue, isdnLapdOperStatus INTEGER, isdnLapdPeerSabme Counter32, isdnLapdRecvdFrmr Counter32 } isdnLapdPrimaryChannel OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If set to true(1), this D channel is the designated primary D channel if D channel backup is active. Roeck Standards Track [Page 36] RFC 2127 ISDN MIB March 1997 There must be exactly one primary D channel configured. If D channel backup is not used, this object has a value of true(1)." REFERENCE "Q.931 [8], Annex F, D channel backup procedures." ::= { isdnLapdEntry 1 } isdnLapdOperStatus OBJECT-TYPE SYNTAX INTEGER { inactive(1), l1Active(2), l2Active(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this interface: inactive all layers are inactive l1Active layer 1 is activated, layer 2 datalink not established l2Active layer 1 is activated, layer 2 datalink established." ::= { isdnLapdEntry 2 } isdnLapdPeerSabme OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of peer SABME frames received on this interface. This is the number of peer-initiated new connections on this interface." ::= { isdnLapdEntry 3 } isdnLapdRecvdFrmr OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LAPD FRMR response frames received. This is the number of framing errors on this interface." ::= { isdnLapdEntry 4 } -- -- Optional groups follow here. Roeck Standards Track [Page 37] RFC 2127 ISDN MIB March 1997 -- The Terminal Endpoint group and table -- This table is required only if TEI values or SPID numbers -- have to be entered. -- The ifIndex values for this table are identical to those of -- the isdnSignalingChannel table. isdnEndpointGroup OBJECT IDENTIFIER ::= { isdnMibObjects 4 } isdnEndpointGetIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "The recommended procedure for selecting a new index for isdnEndpointTable row creation is to GET the value of this object, and then to SET the object with the same value. If the SET operation succeeds, the manager can use this value as an index to create a new row in this table." REFERENCE "RFC1903, TestAndIncr textual convention." ::= { isdnEndpointGroup 1 } isdnEndpointTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing configuration for Terminal Endpoints." ::= { isdnEndpointGroup 2 } isdnEndpointEntry OBJECT-TYPE SYNTAX IsdnEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Terminal Endpoint Table. The value of isdnEndpointIfType must be supplied for a row in this table to become active." INDEX { isdnEndpointIndex } ::= { isdnEndpointTable 1 } IsdnEndpointEntry ::= SEQUENCE { isdnEndpointIndex INTEGER, isdnEndpointIfIndex InterfaceIndex, isdnEndpointIfType IANAifType, isdnEndpointTeiType INTEGER, Roeck Standards Track [Page 38] RFC 2127 ISDN MIB March 1997 isdnEndpointTeiValue INTEGER, isdnEndpointSpid DisplayString, isdnEndpointStatus RowStatus } isdnEndpointIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value which uniquely identifies an entry in the isdnEndpointTable." ::= { isdnEndpointEntry 1 } isdnEndpointIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the interface associated with this Terminal Endpoint." ::= { isdnEndpointEntry 2 } isdnEndpointIfType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-create STATUS current DESCRIPTION "The interface type for this Terminal Endpoint. Interface types of x25ple(40) and isdn(63) are allowed. The interface type is identical to the value of ifType in the associated ifEntry." ::= { isdnEndpointEntry 3 } isdnEndpointTeiType OBJECT-TYPE SYNTAX INTEGER { dynamic(1), static(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of TEI (Terminal Endpoint Identifier) used for this Terminal Endpoint. In case of dynamic(1), the TEI value is selected by the switch. In case of static(2), a valid TEI value has to be entered in the isdnEndpointTeiValue object. The default value for this object depends on the Roeck Standards Track [Page 39] RFC 2127 ISDN MIB March 1997 interface type as well as the Terminal Endpoint type. On Primary Rate interfaces the default value is static(2). On Basic Rate interfaces the default value is dynamic(1) for isdn(63) Terminal Endpoints and static(2) for x25ple(40) Terminal Endpoints." ::= { isdnEndpointEntry 4 } isdnEndpointTeiValue OBJECT-TYPE SYNTAX INTEGER ( 0..255 ) MAX-ACCESS read-create STATUS current DESCRIPTION "The TEI (Terminal Endpoint Identifier) value for this Terminal Endpoint. If isdnEndpointTeiType is set to static(2), valid numbers are 0..63, while otherwise the value is set internally. The default value of this object is 0 for static TEI assignment. The default value for dynamic TEI assignment is also 0 as long as no TEI has been assigned. After TEI assignment, the assigned TEI value is returned." ::= { isdnEndpointEntry 5 } isdnEndpointSpid OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The Service profile IDentifier (SPID) information for this Terminal Endpoint. The SPID is composed of 9-20 numeric characters. This information has to be defined in addition to the local number for some switch protocol types, e.g. Bellcore NI-1 and NI-2. If this object is not required, it is a zero length string." REFERENCE "Bellcore SR-NWT-001953, Generic Guidelines for ISDN Terminal Equipment on Basic Access Interfaces, Chapter 8.5.1." DEFVAL { "" } ::= { isdnEndpointEntry 6 } isdnEndpointStatus OBJECT-TYPE SYNTAX RowStatus Roeck Standards Track [Page 40] RFC 2127 ISDN MIB March 1997 MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the isdnEndpointTable." ::= { isdnEndpointEntry 7 } -- -- The Directory Number group -- isdnDirectoryGroup OBJECT IDENTIFIER ::= { isdnMibObjects 5 } isdnDirectoryTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnDirectoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing Directory Numbers." ::= { isdnDirectoryGroup 1 } isdnDirectoryEntry OBJECT-TYPE SYNTAX IsdnDirectoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Directory Number Table. All objects in an entry must be set for a new row to become active." INDEX { isdnDirectoryIndex } ::= { isdnDirectoryTable 1 } IsdnDirectoryEntry ::= SEQUENCE { isdnDirectoryIndex INTEGER, isdnDirectoryNumber DisplayString, isdnDirectorySigIndex INTEGER, isdnDirectoryStatus RowStatus } isdnDirectoryIndex OBJECT-TYPE SYNTAX INTEGER ( 1..'7fffffff'h ) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value which uniquely identifies an entry in the isdnDirectoryTable." ::= { isdnDirectoryEntry 1 } isdnDirectoryNumber OBJECT-TYPE Roeck Standards Track [Page 41] RFC 2127 ISDN MIB March 1997 SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "A Directory Number. Directory Numbers are used to identify incoming calls on the signaling channel given in isdnDirectorySigIndex. The format of this information largely depends on the type of switch or PBX the device is connected to. Therefore, the detailed format of this information is not specified and is implementation dependent. If possible, the agent should implement this information using the E.164 number format. In this case, the number must start with '+'. Otherwise, IA5 number digits must be used." REFERENCE "ITU-T E.164, Q.931 chapter 4.5.10" ::= { isdnDirectoryEntry 2 } isdnDirectorySigIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "An index pointing to an ISDN signaling channel. Incoming calls are accepted on this signaling channel if the isdnDirectoryNumber is presented as Called Number in the SETUP message." ::= { isdnDirectoryEntry 3 } isdnDirectoryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the isdnDirectoryTable." ::= { isdnDirectoryEntry 4 } -- Traps isdnMibTrapPrefix OBJECT IDENTIFIER ::= { isdnMib 2 } isdnMibTraps OBJECT IDENTIFIER ::= { isdnMibTrapPrefix 0 } isdnMibCallInformation NOTIFICATION-TYPE OBJECTS { Roeck Standards Track [Page 42] RFC 2127 ISDN MIB March 1997 ifIndex, -- isdnBearerTable ifIndex isdnBearerOperStatus, isdnBearerPeerAddress, isdnBearerPeerSubAddress, isdnBearerCallSetupTime, isdnBearerInfoType, isdnBearerCallOrigin } STATUS current DESCRIPTION "This trap/inform is sent to the manager under the following condidions: - on incoming calls for each call which is rejected for policy reasons (e.g. unknown neighbor or access violation) - on outgoing calls whenever a call attempt is determined to have ultimately failed. In the event that call retry is active, then this will be after all retry attempts have failed. - whenever a call connects. In this case, the object isdnBearerCallConnectTime should be included in the trap. Only one such trap is sent in between successful or unsuccessful call attempts from or to a single neighbor; subsequent call attempts result in no trap. If the Dial Control MIB objects dialCtlNbrCfgId and dialCtlNbrCfgIndex are known by the entity generating this trap, both objects should be included in the trap as well. The receipt of this trap with no dial neighbor information indicates that the manager must poll the callHistoryTable of the Dial Control MIB to see what changed." ::= { isdnMibTraps 1 } -- -- conformance information -- isdnMibConformance OBJECT IDENTIFIER ::= { isdnMib 2 } isdnMibCompliances OBJECT IDENTIFIER ::= { isdnMibConformance 1 } isdnMibGroups OBJECT IDENTIFIER ::= { isdnMibConformance 2 } -- compliance statements isdnMibCompliance MODULE-COMPLIANCE STATUS current Roeck Standards Track [Page 43] RFC 2127 ISDN MIB March 1997 DESCRIPTION "The compliance statement for entities which implement the ISDN MIB." MODULE -- this module -- unconditionally mandatory groups MANDATORY-GROUPS { isdnMibSignalingGroup, isdnMibBearerGroup, isdnMibNotificationsGroup } -- conditionally mandatory group GROUP isdnMibBasicRateGroup DESCRIPTION "The isdnMibBasicRateGroup is mandatory for entities supporting ISDN Basic Rate interfaces." -- optional groups GROUP isdnMibEndpointGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to ISDN interfaces." GROUP isdnMibDirectoryGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to ISDN interfaces." OBJECT isdnBasicRateIfType MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT isdnBasicRateLineTopology MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT isdnBasicRateIfMode MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT isdnBasicRateSignalMode MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." Roeck Standards Track [Page 44] RFC 2127 ISDN MIB March 1997 ::= { isdnMibCompliances 1 } -- units of conformance isdnMibBasicRateGroup OBJECT-GROUP OBJECTS { isdnBasicRateIfType, isdnBasicRateLineTopology, isdnBasicRateIfMode, isdnBasicRateSignalMode } STATUS current DESCRIPTION "A collection of objects required for ISDN Basic Rate physical interface configuration and statistics." ::= { isdnMibGroups 1 } isdnMibBearerGroup OBJECT-GROUP OBJECTS { isdnBearerChannelType, isdnBearerOperStatus, isdnBearerChannelNumber, isdnBearerPeerAddress, isdnBearerPeerSubAddress, isdnBearerCallOrigin, isdnBearerInfoType, isdnBearerMultirate, isdnBearerCallSetupTime, isdnBearerCallConnectTime, isdnBearerChargedUnits } STATUS current DESCRIPTION "A collection of objects required for ISDN Bearer channel control and statistics." ::= { isdnMibGroups 2 } isdnMibSignalingGroup OBJECT-GROUP OBJECTS { isdnSignalingGetIndex, isdnSignalingIfIndex, isdnSignalingProtocol, isdnSignalingCallingAddress, isdnSignalingSubAddress, isdnSignalingBchannelCount, isdnSignalingInfoTrapEnable, isdnSignalingStatus, isdnSigStatsInCalls, Roeck Standards Track [Page 45] RFC 2127 ISDN MIB March 1997 isdnSigStatsInConnected, isdnSigStatsOutCalls, isdnSigStatsOutConnected, isdnSigStatsChargedUnits, isdnLapdPrimaryChannel, isdnLapdOperStatus, isdnLapdPeerSabme, isdnLapdRecvdFrmr } STATUS current DESCRIPTION "A collection of objects required for ISDN D channel configuration and statistics." ::= { isdnMibGroups 3 } isdnMibEndpointGroup OBJECT-GROUP OBJECTS { isdnEndpointGetIndex, isdnEndpointIfIndex, isdnEndpointIfType, isdnEndpointTeiType, isdnEndpointTeiValue, isdnEndpointSpid, isdnEndpointStatus } STATUS current DESCRIPTION "A collection of objects describing Terminal Endpoints." ::= { isdnMibGroups 4 } isdnMibDirectoryGroup OBJECT-GROUP OBJECTS { isdnDirectoryNumber, isdnDirectorySigIndex, isdnDirectoryStatus } STATUS current DESCRIPTION "A collection of objects describing directory numbers." ::= { isdnMibGroups 5 } isdnMibNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { isdnMibCallInformation } STATUS current DESCRIPTION "The notifications which a ISDN MIB entity is required to implement." ::= { isdnMibGroups 6 } Roeck Standards Track [Page 46] RFC 2127 ISDN MIB March 1997 END 5. Acknowledgments This document was produced by the ISDN MIB Working Group. Special thanks is due to the following persons: Ed Alcoff Fred Baker Scott Bradner Bibek A. Das Maria Greene Ken Grigg Stefan Hochuli Jeffrey T. Johnson Glenn Kime Oliver Korfmacher Kedar Madineni Bill Miskovetz Mike O'Dowd David M. Piscitello Lisa A. Phifer Randy Roberts Hascall H. Sharp John Shriver Robert Snyder Bob Stewart Ron Stoughton James Watt 6. References [1] 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. [2] 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. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Computer Science, May 1990. Roeck Standards Track [Page 47] RFC 2127 ISDN MIB March 1997 [4] 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. [5] ITU-T Recommendation "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN User-Network Interface Data Link Layer - General Aspects Rec. Q.920. [6] ITU-T Recommendation "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN User-Network Interface - Data Link Layer Specification Rec. Q.921. [7] ITU-T Recommendation "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN Data Link Layer Specification for Frame Mode Bearer Services (LAPF) Rec. Q.922. [8] ITU-T Recommendation "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), March 1993. [9] ITU-T Recommendation "Generic procedures for the control of ISDN supplementary services ISDN user-network interface layer 3 specification", Rec. Q.932(I.452). [10] ITU-T Recommendation "Digital subscriber Signaling System No. 1 (DSS 1) - Signaling specification for frame-mode basic call control", Rec. Q.933. [11] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [12] Fowler, D., "Definitions of Managed Objects for the DS1/E1/DS2/E2 Interface Types", Work in Progress. [13] Fowler, D., "Definitions of Managed Objects for the DS0 and DS0Bundle Interface Types", Work in Progress. [14] ITU-T Recommendation "Integrated Services Digital Network (ISDN) General Structure and Service Capabilities - Closed User Group", Rec. I.255.1. [15] Roeck, G., "Dial Control Management Information Base", RFC 2128, March 1997. Roeck Standards Track [Page 48] RFC 2127 ISDN MIB March 1997 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Guenter Roeck cisco Systems 170 West Tasman Drive San Jose, CA 95134 U.S.A. Phone: +1 408 527 3143 EMail: groeck@cisco.com Roeck Standards Track [Page 49] snmp-mibs-downloader-1.1/mibrfcs/rfc2128.txt0000644000000000000000000020115111402176071015556 0ustar Network Working Group G. Roeck, Editor Request for Comments: 2128 cisco Systems Category: Standards Track March 1997 Dial Control Management Information Base using SMIv2 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing demand access circuits, including ISDN. This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This document is a product of the ISDN MIB working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author. Table of Contents 1 The SNMPv2 Network Management Framework ...................... 2 1.1 Object Definitions ......................................... 2 2 Overview ..................................................... 2 2.1 Structure of MIB ........................................... 2 2.2 Relationship to the Interfaces MIB ......................... 3 2.2.1 Layering Model and Virtual Circuits ...................... 3 2.2.2 ifTestTable .............................................. 4 2.2.3 ifRcvAddressTable ........................................ 4 2.2.3.1 ifEntry for a single peer .............................. 5 2.3 Multilink and backup line support .......................... 5 2.4 Support for generic peers .................................. 5 3 Definitions .................................................. 6 3.1 Dial Control MIB ........................................... 6 4 Acknowledgments .............................................. 32 5 References ................................................... 33 Roeck Standards Track [Page 1] RFC 2128 Dial Control MIB March 1997 6 Security Considerations ...................................... 33 7 Author's Address ............................................. 34 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, STD 15, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. 2. Overview 2.1. Structure of MIB Managing demand access circuits requires the following groups of information: o General configuration information. o Information to describe peer configuration and peer statistics. In this respect, peer configuration means information on how to connect to peers on outgoing calls, how to identify peers on incoming calls, and other call related configuration information. o Information to store active call information. Roeck Standards Track [Page 2] RFC 2128 Dial Control MIB March 1997 o Information to retain call history. The MIB, therefore, is structured into four groups. o The dialCtlConfiguration group is used to specify general configuration information. o The dialCtlPeer group is used to describe peer configuration and peer statistics. o The callActive group is used to store active call information. o The callHistory group is used to store call history information. These calls could be circuit switched or they could be virtual circuits. History of each and every call is stored, of successful calls as well as unsuccessful and rejected calls. An entry will be created when a call is cleared. 2.2. Relationship to the Interfaces MIB This section clarifies the relationship of this MIB to the Interfaces MIB [8]. Several areas of correlation are addressed in the following subsections. The implementor is referred to the Interfaces MIB document in order to understand the general intent of these areas. 2.2.1. Layering Model and Virtual Circuits On an occasional access channel, there are a number of peer systems that are permitted to call or be called, all of which need to be treated as active from a routing viewpoint, but most of which have no call in progress at any given time. On dialup interfaces, this is further complicated by the fact that calls to a given peer float from channel to channel. One cannot definitively say "I call this peer on that interface." It is necessary, therefore, to provide a mapping algorithm between the low-level interfaces, and the various logical interfaces supporting the peers. This is solved by creating a logical interface (ifEntry) for each peer and a logical interface (ifEntry) for each low-level interface. These are then correlated using the ifStackTable. The low-level interfaces are either physical interfaces, e.g. modem interfaces, or logical interfaces, e.g. ISDN B channels, which then in turn are layered on top of physical ISDN interfaces. Roeck Standards Track [Page 3] RFC 2128 Dial Control MIB March 1997 The model, therefore, looks something like this, taking ISDN as an example: +-------------------------------------------------------+ | Network Layer Protocol | +------+ +-------+ +-------+ +-------+ +-------+ +------+ | | | | | | | | | | <== appears active +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | PPP | | PPP | | F/R | | PPP | | F/R | | for | | for | | for | | for | | for | ifEntry with |Peer1| |Peer2| |switch |Peer3| |switch shadow PeerEntry | | | | | A | | | | B | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | | | | <== some actually are +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | B | | B | | B | | B | | B | |channel| |channel| |channel| |channel| |channel| +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | +------+ +-------+ +-------+ +-------+ +-------+ +------+ | Basic/Primary Rate Interface | +-------------------------------------------------------+ Mapping of IP interfaces to Called Peers to B Channels IfEntries are maintained for each peer. In this model, each peer is required to have an associated encapsulation layer interface. This interface can be of any kind, e.g. PPP or LAPB. In order to specify the network address for a given peer, one would then usually add a routing/forwarding table entry, pointing to the encapsulation layer interface through which this peer can be reached. 2.2.2. ifTestTable The ifTestTable usage is defined in the MIBs defining the encapsulation below the network layer. For example, if PPP encapsulation is being used, the ifTestTable is defined by PPP. 2.2.3. ifRcvAddressTable The ifRcvAddressTable usage is defined in the MIBs defining the encapsulation below the network layer. For example, if PPP encapsulation is being used, the ifRcvAddressTable is defined by PPP. Roeck Standards Track [Page 4] RFC 2128 Dial Control MIB March 1997 2.2.3.1. ifEntry for a single peer IfEntries are defined in the MIBs defining the encapsulation below the network layer. For example, if PPP encapsulation is being used, the ifEntry is defined by PPP. ifEntries will never be created by the Dial Control MIB. The Dial Control MIB always depends on some other ifIndex of some set of ifTypes. That is, to create an entry in the Dial Control MIB, the base ifEntry must already have been created through some other mechanism. The Dial Control entry does have its own RowStatus, permitting the Dial Control supplementary information to come and go, but not otherwise disturbing the ifIndex to which it is attached. If in a given implementation the two are tightly bound, deleting the ifEntry may have the side effect of deleting the Dial Control entry. 2.3. Multilink and backup line support In order to support multilink and backup procedures, there may be several entries for a single peer in the dialCtlPeerCfgTable. A single peer is identified using the dialCtlPeerCfgId object of the dialCtlPeerCfgTable. There may be several entries in dialCtlPeerCfgTable with the same value of dialCtlPeerCfgId, but different ifIndex values. Each of those entries will then describe a possible connection to the same peer. Such entries can then be used to handle multilink as well as backup procedures, e.g. by bundling the attached ifEntries using PPP multilink. 2.4. Support for generic peers Generic peers can for example be supported by permitting wild-card characters (e.g., '?' or '*') in dialCtlPeerCfgAnswerAddress. A number to be accepted could then be defined as partly (e.g., '*1234') or entirely generic (e.g., '*'). A detailed specification of such a functionality is outside the scope of this document. However, the implementor should be aware that supporting generic peers may cause a security hole. The user would not know where a call is from, which could potentially allow unauthorized access. Roeck Standards Track [Page 5] RFC 2128 Dial Control MIB March 1997 3. Definitions 3.1. Dial Control MIB DIAL-CONTROL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, TimeStamp, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF IANAifType FROM IANAifType-MIB ifOperStatus, ifIndex, InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB transmission FROM RFC1213-MIB; dialControlMib MODULE-IDENTITY LAST-UPDATED "9609231544Z" -- Sep 23, 1996 ORGANIZATION "IETF ISDN Working Group" CONTACT-INFO " Guenter Roeck Postal: cisco Systems 170 West Tasman Drive San Jose, CA 95134 U.S.A. Phone: +1 408 527 3143 E-mail: groeck@cisco.com" DESCRIPTION "The MIB module to describe peer information for demand access and possibly other kinds of interfaces." ::= { transmission 21 } AbsoluteCounter32 ::= TEXTUAL-CONVENTION Roeck Standards Track [Page 6] RFC 2128 Dial Control MIB March 1997 STATUS current DESCRIPTION "Represents a Counter32-like value that starts at zero, does not decrease, and does not wrap. This may be used only in situations where wrapping is not possible or extremely unlikely. Should such a counter overflow, it locks at the maxium value of 4,294,967,295. The primary use of this type of counter is situations where a counter value is to be recorded as history and is thus no longer subject to reading for changing values." SYNTAX Unsigned32 -- Dial Control Mib objects definitions dialControlMibObjects OBJECT IDENTIFIER ::= { dialControlMib 1 } -- General configuration group dialCtlConfiguration OBJECT IDENTIFIER ::= { dialControlMibObjects 1 } -- general configuration data/parameters dialCtlAcceptMode OBJECT-TYPE SYNTAX INTEGER { acceptNone(1), acceptAll(2), acceptKnown(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The security level for acceptance of incoming calls. acceptNone(1) - incoming calls will not be accepted acceptAll(2) - incoming calls will be accepted, even if there is no matching entry in the dialCtlPeerCfgTable acceptKnown(3) - incoming calls will be accepted only if there is a matching entry in the dialCtlPeerCfgTable " ::= { dialCtlConfiguration 1 } dialCtlTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) Roeck Standards Track [Page 7] RFC 2128 Dial Control MIB March 1997 } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether dialCtlPeerCallInformation and dialCtlPeerCallSetup traps should be generated for all peers. If the value of this object is enabled(1), traps will be generated for all peers. If the value of this object is disabled(2), traps will be generated only for peers having dialCtlPeerCfgTrapEnable set to enabled(1)." DEFVAL { disabled } ::= { dialCtlConfiguration 2 } -- Peer group dialCtlPeer OBJECT IDENTIFIER ::= { dialControlMibObjects 2 } -- peer configuration table dialCtlPeerCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF DialCtlPeerCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The list of peers from which the managed device will accept calls or to which it will place them." ::= { dialCtlPeer 1 } dialCtlPeerCfgEntry OBJECT-TYPE SYNTAX DialCtlPeerCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration data for a single Peer. This entry is effectively permanent, and contains information to identify the peer, how to connect to the peer, how to identify the peer and its permissions. The value of dialCtlPeerCfgOriginateAddress must be specified before a new row in this table can become active(1). Any writeable parameters in an existing entry can be modified while the entry is active. The modification will take effect when the peer in question will be called the next time. An entry in this table can only be created if the associated ifEntry already exists." INDEX { dialCtlPeerCfgId, ifIndex } Roeck Standards Track [Page 8] RFC 2128 Dial Control MIB March 1997 ::= { dialCtlPeerCfgTable 1 } DialCtlPeerCfgEntry ::= SEQUENCE { dialCtlPeerCfgId INTEGER, dialCtlPeerCfgIfType IANAifType, dialCtlPeerCfgLowerIf InterfaceIndexOrZero, dialCtlPeerCfgOriginateAddress DisplayString, dialCtlPeerCfgAnswerAddress DisplayString, dialCtlPeerCfgSubAddress DisplayString, dialCtlPeerCfgClosedUserGroup DisplayString, dialCtlPeerCfgSpeed INTEGER, dialCtlPeerCfgInfoType INTEGER, dialCtlPeerCfgPermission INTEGER, dialCtlPeerCfgInactivityTimer INTEGER, dialCtlPeerCfgMinDuration INTEGER, dialCtlPeerCfgMaxDuration INTEGER, dialCtlPeerCfgCarrierDelay INTEGER, dialCtlPeerCfgCallRetries INTEGER, dialCtlPeerCfgRetryDelay INTEGER, dialCtlPeerCfgFailureDelay INTEGER, dialCtlPeerCfgTrapEnable INTEGER, dialCtlPeerCfgStatus RowStatus } dialCtlPeerCfgId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a single peer. There may be several entries in this table for one peer, defining different ways of reaching this peer. Thus, there may be several entries in this table with the same value of dialCtlPeerCfgId. Multiple entries for one peer may be used to support multilink as well as backup lines. A single peer will be identified by a unique value of this object. Several entries for one peer MUST have the same value of dialCtlPeerCfgId, but different ifEntries and thus different values of ifIndex." ::= { dialCtlPeerCfgEntry 1 } dialCtlPeerCfgIfType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-create STATUS current DESCRIPTION "The interface type to be used for calling this peer. Roeck Standards Track [Page 9] RFC 2128 Dial Control MIB March 1997 In case of ISDN, the value of isdn(63) is to be used." DEFVAL { other } ::= { dialCtlPeerCfgEntry 2 } dialCtlPeerCfgLowerIf OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "ifIndex value of an interface the peer will have to be called on. For example, on an ISDN interface, this can be the ifIndex value of a D channel or the ifIndex value of a B channel, whatever is appropriate for a given peer. As an example, for Basic Rate leased lines it will be necessary to specify a B channel ifIndex, while for semi-permanent connections the D channel ifIndex has to be specified. If the interface can be dynamically assigned, this object has a value of zero." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 3 } dialCtlPeerCfgOriginateAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "Call Address at which the peer will be called. Think of this as the set of characters following 'ATDT ' or the 'phone number' included in a D channel call request. The structure of this information will be switch type specific. If there is no address information required for reaching the peer, i.e., for leased lines, this object will be a zero length string." ::= { dialCtlPeerCfgEntry 4 } dialCtlPeerCfgAnswerAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "Calling Party Number information element, as for example passed in an ISDN SETUP message by a PBX or switch, for incoming calls. This address can be used to identify the peer. If this address is either unknown or identical to dialCtlPeerCfgOriginateAddress, this object will be Roeck Standards Track [Page 10] RFC 2128 Dial Control MIB March 1997 a zero length string." DEFVAL { "" } ::= { dialCtlPeerCfgEntry 5 } dialCtlPeerCfgSubAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "Subaddress at which the peer will be called. If the subaddress is undefined for the given media or unused, this is a zero length string." DEFVAL { "" } ::= { dialCtlPeerCfgEntry 6 } dialCtlPeerCfgClosedUserGroup OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "Closed User Group at which the peer will be called. If the Closed User Group is undefined for the given media or unused, this is a zero length string." REFERENCE "Q.931, chapter 4.6.1." DEFVAL { "" } ::= { dialCtlPeerCfgEntry 7 } dialCtlPeerCfgSpeed OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The desired information transfer speed in bits/second when calling this peer. The detailed media specific information, e.g. information type and information transfer rate for ISDN circuits, has to be extracted from this object. If the transfer speed to be used is unknown or the default speed for this type of interfaces, the value of this object may be zero." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 8 } dialCtlPeerCfgInfoType OBJECT-TYPE SYNTAX INTEGER { other(1), speech(2), Roeck Standards Track [Page 11] RFC 2128 Dial Control MIB March 1997 unrestrictedDigital(3), -- 64k/s data unrestrictedDigital56(4), -- with 56k rate adaption restrictedDigital(5), audio31(6), -- 3.1 kHz audio audio7(7), -- 7 kHz audio video(8), packetSwitched(9), fax(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "The Information Transfer Capability to be used when calling this peer. speech(2) refers to a non-data connection, whereas audio31(6) and audio7(7) refer to data mode connections." DEFVAL { other } ::= { dialCtlPeerCfgEntry 9 } dialCtlPeerCfgPermission OBJECT-TYPE SYNTAX INTEGER { originate(1), answer(2), both(3), -- both originate & answer callback(4), none(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "Applicable permissions. callback(4) either rejects the call and then calls back, or uses the 'Reverse charging' information element if it is available. Note that callback(4) is supposed to control charging, not security, and applies to callback prior to accepting a call. Callback for security reasons can be handled using PPP callback." DEFVAL { both } ::= { dialCtlPeerCfgEntry 10 } dialCtlPeerCfgInactivityTimer OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION Roeck Standards Track [Page 12] RFC 2128 Dial Control MIB March 1997 "The connection will be automatically disconnected if no longer carrying useful data for a time period, in seconds, specified in this object. Useful data in this context refers to forwarding packets, including routing information; it excludes the encapsulator maintenance frames. A value of zero means the connection will not be automatically taken down due to inactivity, which implies that it is a dedicated circuit." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 11 } dialCtlPeerCfgMinDuration OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum duration of a call in seconds, starting from the time the call is connected until the call is disconnected. This is to accomplish the fact that in most countries charging applies to units of time, which should be matched as closely as possible." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 12 } dialCtlPeerCfgMaxDuration OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum call duration in seconds. Zero means 'unlimited'." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 13 } dialCtlPeerCfgCarrierDelay OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The call timeout time in seconds. The default value of zero means that the call timeout as specified for the media in question will apply." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 14 } dialCtlPeerCfgCallRetries OBJECT-TYPE SYNTAX INTEGER (0..2147483647) Roeck Standards Track [Page 13] RFC 2128 Dial Control MIB March 1997 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of calls to a non-responding address that may be made. A retry count of zero means there is no bound. The intent is to bound the number of successive calls to an address which is inaccessible, or which refuses those calls. Some countries regulate the number of call retries to a given peer that can be made." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 15 } dialCtlPeerCfgRetryDelay OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time in seconds between call retries if a peer cannot be reached. A value of zero means that call retries may be done without any delay." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 16 } dialCtlPeerCfgFailureDelay OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time in seconds after which call attempts are to be placed again after a peer has been noticed to be unreachable, i.e. after dialCtlPeerCfgCallRetries unsuccessful call attempts. A value of zero means that a peer will not be called again after dialCtlPeerCfgCallRetries unsuccessful call attempts." DEFVAL { 0 } ::= { dialCtlPeerCfgEntry 17 } dialCtlPeerCfgTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } Roeck Standards Track [Page 14] RFC 2128 Dial Control MIB March 1997 MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether dialCtlPeerCallInformation and dialCtlPeerCallSetup traps should be generated for this peer." DEFVAL { disabled } ::= { dialCtlPeerCfgEntry 18 } dialCtlPeerCfgStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Status of one row in this table." ::= { dialCtlPeerCfgEntry 19 } -- Peer statistics table dialCtlPeerStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DialCtlPeerStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics information for each peer entry. There will be one entry in this table for each entry in the dialCtlPeerCfgTable." ::= { dialCtlPeer 2 } dialCtlPeerStatsEntry OBJECT-TYPE SYNTAX DialCtlPeerStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics information for a single Peer. This entry is effectively permanent, and contains information describing the last call attempt as well as supplying statistical information." AUGMENTS { dialCtlPeerCfgEntry } ::= { dialCtlPeerStatsTable 1 } DialCtlPeerStatsEntry ::= SEQUENCE { dialCtlPeerStatsConnectTime AbsoluteCounter32, dialCtlPeerStatsChargedUnits AbsoluteCounter32, dialCtlPeerStatsSuccessCalls AbsoluteCounter32, dialCtlPeerStatsFailCalls AbsoluteCounter32, dialCtlPeerStatsAcceptCalls AbsoluteCounter32, Roeck Standards Track [Page 15] RFC 2128 Dial Control MIB March 1997 dialCtlPeerStatsRefuseCalls AbsoluteCounter32, dialCtlPeerStatsLastDisconnectCause OCTET STRING, dialCtlPeerStatsLastDisconnectText DisplayString, dialCtlPeerStatsLastSetupTime TimeStamp } dialCtlPeerStatsConnectTime OBJECT-TYPE SYNTAX AbsoluteCounter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Accumulated connect time to the peer since system startup. This is the total connect time, i.e. the connect time for outgoing calls plus the time for incoming calls." ::= { dialCtlPeerStatsEntry 1 } dialCtlPeerStatsChargedUnits OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of charging units applying to this peer since system startup. Only the charging units applying to the local interface, i.e. for originated calls or for calls with 'Reverse charging' being active, will be counted here." ::= { dialCtlPeerStatsEntry 2 } dialCtlPeerStatsSuccessCalls OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of completed calls to this peer." ::= { dialCtlPeerStatsEntry 3 } dialCtlPeerStatsFailCalls OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of failed call attempts to this peer since system startup." ::= { dialCtlPeerStatsEntry 4 } dialCtlPeerStatsAcceptCalls OBJECT-TYPE SYNTAX AbsoluteCounter32 Roeck Standards Track [Page 16] RFC 2128 Dial Control MIB March 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from this peer accepted since system startup." ::= { dialCtlPeerStatsEntry 5 } dialCtlPeerStatsRefuseCalls OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from this peer refused since system startup." ::= { dialCtlPeerStatsEntry 6 } dialCtlPeerStatsLastDisconnectCause OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..4)) MAX-ACCESS read-only STATUS current DESCRIPTION "The encoded network cause value associated with the last call. This object will be updated whenever a call is started or cleared. The value of this object will depend on the interface type as well as on the protocol and protocol version being used on this interface. Some references for possible cause values are given below." REFERENCE "- Bellcore SR-NWT-001953, Generic Guidelines for ISDN Terminal Equipment On Basic Access Interfaces, chapter 5.2.5.8. - Bellcore SR-NWT-002343, ISDN Primary Rate Interface Generic Guidelines for Customer Premises Equipment, chapter 8.2.5.8. - ITU-T Q.931, Appendix I. - ITU-T X.25, CAUSE and DIAGNOSTIC field values. - German Telekom FTZ 1TR6, chapter 3.2.3.4.4.4." ::= { dialCtlPeerStatsEntry 7 } dialCtlPeerStatsLastDisconnectText OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "ASCII text describing the reason for the last call termination. Roeck Standards Track [Page 17] RFC 2128 Dial Control MIB March 1997 This object exists because it would be impossible for a management station to store all possible cause values for all types of interfaces. It should be used only if a management station is unable to decode the value of dialCtlPeerStatsLastDisconnectCause. This object will be updated whenever a call is started or cleared." ::= { dialCtlPeerStatsEntry 8 } dialCtlPeerStatsLastSetupTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last call to this peer was started. For ISDN media, this will be the time when the setup message was received from or sent to the network. This object will be updated whenever a call is started or cleared." ::= { dialCtlPeerStatsEntry 9 } -- -- the active call group -- callActive OBJECT IDENTIFIER ::= { dialControlMibObjects 3 } -- callActiveTable -- Table to store active call information. -- These calls could be circuit switched or they could -- be virtual circuits. -- An entry will be created when a call is started and deleted -- when a call is cleared. callActiveTable OBJECT-TYPE SYNTAX SEQUENCE OF CallActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about active calls to a specific destination." ::= { callActive 1 } callActiveEntry OBJECT-TYPE SYNTAX CallActiveEntry MAX-ACCESS not-accessible Roeck Standards Track [Page 18] RFC 2128 Dial Control MIB March 1997 STATUS current DESCRIPTION "The information regarding a single active Connection. An entry in this table will be created when a call is started. An entry in this table will be deleted when an active call clears." INDEX { callActiveSetupTime, callActiveIndex } ::= { callActiveTable 1 } CallActiveEntry ::= SEQUENCE { callActiveSetupTime TimeStamp, callActiveIndex INTEGER, callActivePeerAddress DisplayString, callActivePeerSubAddress DisplayString, callActivePeerId INTEGER, callActivePeerIfIndex INTEGER, callActiveLogicalIfIndex InterfaceIndexOrZero, callActiveConnectTime TimeStamp, callActiveCallState INTEGER, callActiveCallOrigin INTEGER, callActiveChargedUnits AbsoluteCounter32, callActiveInfoType INTEGER, callActiveTransmitPackets AbsoluteCounter32, callActiveTransmitBytes AbsoluteCounter32, callActiveReceivePackets AbsoluteCounter32, callActiveReceiveBytes AbsoluteCounter32 } callActiveSetupTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of sysUpTime when the call associated to this entry was started. This will be useful for an NMS to retrieve all calls after a specific time. Also, this object can be useful in finding large delays between the time the call was started and the time the call was connected. For ISDN media, this will be the time when the setup message was received from or sent to the network." ::= { callActiveEntry 1 } callActiveIndex OBJECT-TYPE SYNTAX INTEGER (1..'7fffffff'h) MAX-ACCESS not-accessible STATUS current Roeck Standards Track [Page 19] RFC 2128 Dial Control MIB March 1997 DESCRIPTION "Small index variable to distinguish calls that start in the same hundredth of a second." ::= { callActiveEntry 2 } callActivePeerAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The number this call is connected to. If the number is not available, then it will have a length of zero." ::= { callActiveEntry 3 } callActivePeerSubAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The subaddress this call is connected to. If the subaddress is undefined or not available, this will be a zero length string." ::= { callActiveEntry 4 } callActivePeerId OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the Id value of the peer table entry to which this call was made. If a peer table entry for this call does not exist or is unknown, the value of this object will be zero." ::= { callActiveEntry 5 } callActivePeerIfIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the ifIndex value of the peer table entry to which this call was made. If a peer table entry for this call does not exist or is unknown, the value of this object will be zero." ::= { callActiveEntry 6 } callActiveLogicalIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero Roeck Standards Track [Page 20] RFC 2128 Dial Control MIB March 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "This is the ifIndex value of the logical interface through which this call was made. For ISDN media, this would be the ifIndex of the B channel which was used for this call. If the ifIndex value is unknown, the value of this object will be zero." ::= { callActiveEntry 7 } callActiveConnectTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the call was connected. If the call is not connected, this object will have a value of zero." ::= { callActiveEntry 8 } callActiveCallState OBJECT-TYPE SYNTAX INTEGER { unknown(1), connecting(2), connected(3), active(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current call state. unknown(1) - The call state is unknown. connecting(2) - A connection attempt (outgoing call) is being made. connected(3) - An incoming call is in the process of validation. active(4) - The call is active. " ::= { callActiveEntry 9 } callActiveCallOrigin OBJECT-TYPE SYNTAX INTEGER { originate(1), answer(2), callback(3) } MAX-ACCESS read-only STATUS current Roeck Standards Track [Page 21] RFC 2128 Dial Control MIB March 1997 DESCRIPTION "The call origin." ::= { callActiveEntry 10 } callActiveChargedUnits OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of charged units for this connection. For incoming calls or if charging information is not supplied by the switch, the value of this object will be zero." ::= { callActiveEntry 11 } callActiveInfoType OBJECT-TYPE SYNTAX INTEGER { other(1), -- e.g. for non-isdn media speech(2), unrestrictedDigital(3), -- 64k/s data unrestrictedDigital56(4), -- with 56k rate adaption restrictedDigital(5), audio31(6), -- 3.1 kHz audio audio7(7), -- 7 kHz audio video(8), packetSwitched(9), fax(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "The information type for this call." ::= { callActiveEntry 12 } callActiveTransmitPackets OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which were transmitted for this call." ::= { callActiveEntry 13 } callActiveTransmitBytes OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION Roeck Standards Track [Page 22] RFC 2128 Dial Control MIB March 1997 "The number of bytes which were transmitted for this call." ::= { callActiveEntry 14 } callActiveReceivePackets OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which were received for this call." ::= { callActiveEntry 15 } callActiveReceiveBytes OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes which were received for this call." ::= { callActiveEntry 16 } -- -- the call history group -- callHistory OBJECT IDENTIFIER ::= { dialControlMibObjects 4 } callHistoryTableMaxLength OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit on the number of entries that the callHistoryTable may contain. A value of 0 will prevent any history from being retained. When this table is full, the oldest entry will be deleted and the new one will be created." ::= { callHistory 1 } callHistoryRetainTimer OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum amount of time that an callHistoryEntry will be maintained before being deleted. A value of 0 will prevent any history from being retained in the Roeck Standards Track [Page 23] RFC 2128 Dial Control MIB March 1997 callHistoryTable, but will neither prevent callCompletion traps being generated nor affect other tables." ::= { callHistory 2 } -- callHistoryTable -- Table to store the past call information. The Destination number -- and the call connect and disconnect time, the disconnection cause -- are stored. These calls could be circuit switched or they could -- be virtual circuits. History of each and every call is stored, -- of successful calls as well as of unsuccessful and rejected calls. -- An entry will be created when a call is cleared. callHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF CallHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about specific calls to a specific destination." ::= { callHistory 3 } callHistoryEntry OBJECT-TYPE SYNTAX CallHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The information regarding a single Connection." INDEX { callActiveSetupTime, callActiveIndex } ::= { callHistoryTable 1 } CallHistoryEntry ::= SEQUENCE { callHistoryPeerAddress DisplayString, callHistoryPeerSubAddress DisplayString, callHistoryPeerId INTEGER, callHistoryPeerIfIndex INTEGER, callHistoryLogicalIfIndex InterfaceIndex, callHistoryDisconnectCause OCTET STRING, callHistoryDisconnectText DisplayString, callHistoryConnectTime TimeStamp, callHistoryDisconnectTime TimeStamp, callHistoryCallOrigin INTEGER, callHistoryChargedUnits AbsoluteCounter32, callHistoryInfoType INTEGER, callHistoryTransmitPackets AbsoluteCounter32, callHistoryTransmitBytes AbsoluteCounter32, callHistoryReceivePackets AbsoluteCounter32, Roeck Standards Track [Page 24] RFC 2128 Dial Control MIB March 1997 callHistoryReceiveBytes AbsoluteCounter32 } callHistoryPeerAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The number this call was connected to. If the number is not available, then it will have a length of zero." ::= { callHistoryEntry 1 } callHistoryPeerSubAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The subaddress this call was connected to. If the subaddress is undefined or not available, this will be a zero length string." ::= { callHistoryEntry 2 } callHistoryPeerId OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the Id value of the peer table entry to which this call was made. If a peer table entry for this call does not exist, the value of this object will be zero." ::= { callHistoryEntry 3 } callHistoryPeerIfIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the ifIndex value of the peer table entry to which this call was made. If a peer table entry for this call does not exist, the value of this object will be zero." ::= { callHistoryEntry 4 } callHistoryLogicalIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current Roeck Standards Track [Page 25] RFC 2128 Dial Control MIB March 1997 DESCRIPTION "This is the ifIndex value of the logical interface through which this call was made. For ISDN media, this would be the ifIndex of the B channel which was used for this call." ::= { callHistoryEntry 5 } callHistoryDisconnectCause OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..4)) MAX-ACCESS read-only STATUS current DESCRIPTION "The encoded network cause value associated with this call. The value of this object will depend on the interface type as well as on the protocol and protocol version being used on this interface. Some references for possible cause values are given below." REFERENCE "- Bellcore SR-NWT-001953, Generic Guidelines for ISDN Terminal Equipment On Basic Access Interfaces, chapter 5.2.5.8. - Bellcore SR-NWT-002343, ISDN Primary Rate Interface Generic Guidelines for Customer Premises Equipment, chapter 8.2.5.8. - ITU-T Q.931, Appendix I. - ITU-T X.25, CAUSE and DIAGNOSTIC field values. - German Telekom FTZ 1TR6, chapter 3.2.3.4.4.4." ::= { callHistoryEntry 6 } callHistoryDisconnectText OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "ASCII text describing the reason for call termination. This object exists because it would be impossible for a management station to store all possible cause values for all types of interfaces. It should be used only if a management station is unable to decode the value of dialCtlPeerStatsLastDisconnectCause." ::= { callHistoryEntry 7 } callHistoryConnectTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Roeck Standards Track [Page 26] RFC 2128 Dial Control MIB March 1997 "The value of sysUpTime when the call was connected." ::= { callHistoryEntry 8 } callHistoryDisconnectTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the call was disconnected." ::= { callHistoryEntry 9 } callHistoryCallOrigin OBJECT-TYPE SYNTAX INTEGER { originate(1), answer(2), callback(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The call origin." ::= { callHistoryEntry 10 } callHistoryChargedUnits OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of charged units for this connection. For incoming calls or if charging information is not supplied by the switch, the value of this object will be zero." ::= { callHistoryEntry 11 } callHistoryInfoType OBJECT-TYPE SYNTAX INTEGER { other(1), -- e.g. for non-isdn media speech(2), unrestrictedDigital(3), -- 64k/s data unrestrictedDigital56(4), -- with 56k rate adaption restrictedDigital(5), audio31(6), -- 3.1 kHz audio audio7(7), -- 7 kHz audio video(8), packetSwitched(9), fax(10) } MAX-ACCESS read-only Roeck Standards Track [Page 27] RFC 2128 Dial Control MIB March 1997 STATUS current DESCRIPTION "The information type for this call." ::= { callHistoryEntry 12 } callHistoryTransmitPackets OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which were transmitted while this call was active." ::= { callHistoryEntry 13 } callHistoryTransmitBytes OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes which were transmitted while this call was active." ::= { callHistoryEntry 14 } callHistoryReceivePackets OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which were received while this call was active." ::= { callHistoryEntry 15 } callHistoryReceiveBytes OBJECT-TYPE SYNTAX AbsoluteCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes which were received while this call was active." ::= { callHistoryEntry 16 } -- Traps related to Connection management dialControlMibTrapPrefix OBJECT IDENTIFIER ::= { dialControlMib 2 } dialControlMibTraps OBJECT IDENTIFIER ::= { dialControlMibTrapPrefix 0 } dialCtlPeerCallInformation NOTIFICATION-TYPE OBJECTS { Roeck Standards Track [Page 28] RFC 2128 Dial Control MIB March 1997 callHistoryPeerId, callHistoryPeerIfIndex, callHistoryLogicalIfIndex, ifOperStatus, callHistoryPeerAddress, callHistoryPeerSubAddress, callHistoryDisconnectCause, callHistoryConnectTime, callHistoryDisconnectTime, callHistoryInfoType, callHistoryCallOrigin } STATUS current DESCRIPTION "This trap/inform is sent to the manager whenever a successful call clears, or a failed call attempt is determined to have ultimately failed. In the event that call retry is active, then this is after all retry attempts have failed. However, only one such trap is sent in between successful call attempts; subsequent call attempts result in no trap. ifOperStatus will return the operational status of the virtual interface associated with the peer to whom this call was made to." ::= { dialControlMibTraps 1 } dialCtlPeerCallSetup NOTIFICATION-TYPE OBJECTS { callActivePeerId, callActivePeerIfIndex, callActiveLogicalIfIndex, ifOperStatus, callActivePeerAddress, callActivePeerSubAddress, callActiveInfoType, callActiveCallOrigin } STATUS current DESCRIPTION "This trap/inform is sent to the manager whenever a call setup message is received or sent. ifOperStatus will return the operational status of the virtual interface associated with the peer to whom this call was made to." ::= { dialControlMibTraps 2 } -- conformance information Roeck Standards Track [Page 29] RFC 2128 Dial Control MIB March 1997 dialControlMibConformance OBJECT IDENTIFIER ::= { dialControlMib 3 } dialControlMibCompliances OBJECT IDENTIFIER ::= { dialControlMibConformance 1 } dialControlMibGroups OBJECT IDENTIFIER ::= { dialControlMibConformance 2 } -- compliance statements dialControlMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the DIAL CONTROL MIB" MODULE -- this module MANDATORY-GROUPS { dialControlGroup, callActiveGroup, callHistoryGroup, callNotificationsGroup } ::= { dialControlMibCompliances 1 } -- units of conformance dialControlGroup OBJECT-GROUP OBJECTS { dialCtlAcceptMode, dialCtlTrapEnable, dialCtlPeerCfgIfType, dialCtlPeerCfgLowerIf, dialCtlPeerCfgOriginateAddress, dialCtlPeerCfgAnswerAddress, dialCtlPeerCfgSubAddress, dialCtlPeerCfgClosedUserGroup, dialCtlPeerCfgSpeed, dialCtlPeerCfgInfoType, dialCtlPeerCfgPermission, dialCtlPeerCfgInactivityTimer, dialCtlPeerCfgMinDuration, dialCtlPeerCfgMaxDuration, dialCtlPeerCfgCarrierDelay, dialCtlPeerCfgCallRetries, dialCtlPeerCfgRetryDelay, dialCtlPeerCfgFailureDelay, dialCtlPeerCfgTrapEnable, dialCtlPeerCfgStatus, dialCtlPeerStatsConnectTime, dialCtlPeerStatsChargedUnits, dialCtlPeerStatsSuccessCalls, dialCtlPeerStatsFailCalls, Roeck Standards Track [Page 30] RFC 2128 Dial Control MIB March 1997 dialCtlPeerStatsAcceptCalls, dialCtlPeerStatsRefuseCalls, dialCtlPeerStatsLastDisconnectCause, dialCtlPeerStatsLastDisconnectText, dialCtlPeerStatsLastSetupTime } STATUS current DESCRIPTION "A collection of objects providing the DIAL CONTROL capability." ::= { dialControlMibGroups 1 } callActiveGroup OBJECT-GROUP OBJECTS { callActivePeerAddress, callActivePeerSubAddress, callActivePeerId, callActivePeerIfIndex, callActiveLogicalIfIndex, callActiveConnectTime, callActiveCallState, callActiveCallOrigin, callActiveChargedUnits, callActiveInfoType, callActiveTransmitPackets, callActiveTransmitBytes, callActiveReceivePackets, callActiveReceiveBytes } STATUS current DESCRIPTION "A collection of objects providing the active call capability." ::= { dialControlMibGroups 2 } callHistoryGroup OBJECT-GROUP OBJECTS { callHistoryTableMaxLength, callHistoryRetainTimer, callHistoryPeerAddress, callHistoryPeerSubAddress, callHistoryPeerId, callHistoryPeerIfIndex, callHistoryLogicalIfIndex, callHistoryDisconnectCause, callHistoryDisconnectText, callHistoryConnectTime, callHistoryDisconnectTime, Roeck Standards Track [Page 31] RFC 2128 Dial Control MIB March 1997 callHistoryCallOrigin, callHistoryChargedUnits, callHistoryInfoType, callHistoryTransmitPackets, callHistoryTransmitBytes, callHistoryReceivePackets, callHistoryReceiveBytes } STATUS current DESCRIPTION "A collection of objects providing the Call History capability." ::= { dialControlMibGroups 3 } callNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { dialCtlPeerCallInformation, dialCtlPeerCallSetup } STATUS current DESCRIPTION "The notifications which a Dial Control MIB entity is required to implement." ::= { dialControlMibGroups 4 } END 4. Acknowledgments This document was produced by the ISDN MIB Working Group. Special thanks is due to the following persons: Ed Alcoff Fred Baker Bibek A. Das Ken Grigg Jeffrey T. Johnson Glenn Kime Oliver Korfmacher Kedar Madineni Bill Miskovetz David M. Piscitello Lisa A. Phifer Randy Roberts Hascall H. Sharp Hongchi Shih Robert Snyder Bob Stewart Ron Stoughton James Watt Roeck Standards Track [Page 32] RFC 2128 Dial Control MIB March 1997 5. References [1] 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. [2] 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. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Computer Science, May 1990. [4] 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. [5] ITU-T Recommendation "Digital subscriber Signalling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), March 1993. [6] ITU-T Recommendation "Generic procedures for the control of ISDN supplementary services ISDN user-network interface layer 3 specification", Rec. Q.932(I.452). [7] ITU-T Recommendation "Digital subscriber Signalling System No. 1 (DSS 1) - Signalling specification for frame-mode basic call control", Rec. Q.933. [8] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 6. Security Considerations Information in this MIB may be used by upper protocol layers for security purpose. The implementor should be aware that supporting generic peers as described in section 3.4 may cause a security hole. The user would not know where a call is from, which could potentially allow unauthorized access if there is no other authentication scheme, e.g. PPP authentication, available. Roeck Standards Track [Page 33] RFC 2128 Dial Control MIB March 1997 7. Author's Address Guenter Roeck cisco Systems 170 West Tasman Drive San Jose, CA 95134 U.S.A. Phone: +1 408 527 3143 EMail: groeck@cisco.com Roeck Standards Track [Page 34] snmp-mibs-downloader-1.1/mibrfcs/rfc2206.txt0000644000000000000000000033445111402176071015565 0ustar Network Working Group F. Baker Request for Comments: 2206 Cisco Systems Category: Standards Track J. Krawczyk ArrowPoint Communications A. Sastry Cisco Systems September 1997 RSVP Management Information Base using SMIv2 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. Table of Contents 1 The SNMPv2 Network Management Framework ............... 2 1.1 Object Definitions .................................. 2 2 Overview .............................................. 3 2.1 Textual Conventions ................................. 3 2.2 Structure of MIB .................................... 3 2.3 Semantics of Writing the Path and Reservation State Databases .................................... 3 2.4 Intended use of Flow Notifications .................. 4 2.4.1 The lostFlow Notification ......................... 4 2.4.2 The newFlow Notification .......................... 4 3 Definitions ........................................... 4 3.1 RSVP Session Statistics Database .................... 6 3.2 RSVP Session Sender Database ........................ 9 3.3 RSVP Reservations Requested Database ................ 25 3.4 RSVP Reservation Requests Database .................. 35 3.5 RSVP Interface Attributes Database .................. 44 Baker, et. al. Standards Track [Page 1] RFC 2206 RSVP MIB using SMIv2 September 1997 3.6 RSVP Neighbor Database .............................. 48 3.7 Notifications ....................................... 49 4 Security Considerations................................ 63 5 Authors' Addresses .................................... 63 6 Acknowledgements ...................................... 63 7 References ............................................ 64 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1441 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. Baker, et. al. Standards Track [Page 2] RFC 2206 RSVP MIB using SMIv2 September 1997 2. Overview 2.1. Textual Conventions Several new data types are introduced as a textual convention in this MIB document. These textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of the these textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. 2.2. Structure of MIB The MIB is composed of the following sections: General Objects Session Statistics Table Session Sender Table Reservation Requests Received Table Reservation Requests Forwarded Table RSVP Interface Attributes Table RSVP Neighbor Table As a general rule, it is difficult in SNMP to describe arbitrarily long of complex messages; this MIB therefore seeks to describe the Path State Database and the Reservation State Database as though each flow and filter description received in an aggregate message had been received in a separate reservation message. Thus, if a RESV message is received for session 224.1.2.3+UDP+4455 with two filter/flow spec groups describing a sender 1.2.3.4 and another sender 1.2.7.8, these two will show in the MIB as two separate rows: one for 224.1.2.3+UDP+4455 from 1.2.3.4 and the other for 224.1.2.3+UDP+4455 from 1.2.7.8. 2.3. Semantics of Writing the Path and Reservation State Databases The path and reservation state tables are writeable. Writing into the Path and Reservation State databases allows one to perform RSVP reservations without authenticating through RSVP mechanisms, but Baker, et. al. Standards Track [Page 3] RFC 2206 RSVP MIB using SMIv2 September 1997 rather through SNMP mechanisms. State created in this way by SNMP does not time out and cannot be deleted by receiving an RSVP teardown message; it can only be deleted by SNMP. Deletion is accomplished by writing 'destroy' to the associated Row Status object, and this will initiate a teardown message as if the state had timed out. 2.4. Intended use of Flow Notifications 2.4.1. The lostFlow Notification The Lost Flow notification is an asychronous event that signifies that a flow is no longer being observed. 2.4.2. The newFlow Notification The newFlow Notification defined in this MIB can be used to advise a network management system of the state of a flow. 3. Definitions RSVP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Gauge32, NOTIFICATION-TYPE, Integer32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, RowStatus, TimeStamp, TestAndIncr, TimeInterval FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF Port, SessionNumber, SessionType, Protocol, QosService, intSrvFlowStatus, MessageSize, BitRate, BurstSize FROM INTEGRATED-SERVICES-MIB ifIndex, InterfaceIndex FROM IF-MIB; rsvp MODULE-IDENTITY LAST-UPDATED "9511030500Z" -- Thu Aug 28 09:03:53 PDT 1997 ORGANIZATION "IETF RSVP Working Group" CONTACT-INFO " Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Tel: +1 805 681 0115 E-Mail: fred@cisco.com Baker, et. al. Standards Track [Page 4] RFC 2206 RSVP MIB using SMIv2 September 1997 John Krawczyk Postal: ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886 Tel: +1 508 692 5875 E-Mail: jjk@tiac.net Arun Sastry Postal: Cisco Systems 210 W. Tasman Drive San Jose, California 95134 Tel: +1 408 526 7685 E-Mail: arun@cisco.com" DESCRIPTION "The MIB module to describe the RSVP Protocol" ::= { mib-2 51 } rsvpObjects OBJECT IDENTIFIER ::= { rsvp 1 } -- tables rsvpGenObjects OBJECT IDENTIFIER ::= { rsvp 2 } -- global objects rsvpNotificationsPrefix OBJECT IDENTIFIER ::= { rsvp 3 } -- traps rsvpConformance OBJECT IDENTIFIER ::= { rsvp 4 } -- conformance RsvpEncapsulation ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This indicates the encapsulation that an RSVP Neighbor is perceived to be using." SYNTAX INTEGER { ip (1), -- IP Protocol 46 udp (2), -- UDP Encapsulation both (3) -- neighbor is using both encapsulations } RefreshInterval ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The number of milliseconds that are expected to elapse between refreshes of path or reserva- tion state. Unrefreshed Path or reservation state is removed after a small multiple of this period." Baker, et. al. Standards Track [Page 5] RFC 2206 RSVP MIB using SMIv2 September 1997 SYNTAX INTEGER (0..'7FFFFFFF'h) -- The RSVP Session Statistics Database displays statistics -- relating to the number of senders and receivers in each -- session. rsvpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF RsvpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of all sessions seen by a given sys- tem." ::= { rsvpObjects 1 } rsvpSessionEntry OBJECT-TYPE SYNTAX RsvpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single session seen by a given system." INDEX { rsvpSessionNumber } ::= { rsvpSessionTable 1 } RsvpSessionEntry ::= SEQUENCE { rsvpSessionNumber SessionNumber, rsvpSessionType SessionType, rsvpSessionDestAddr OCTET STRING, rsvpSessionDestAddrLength INTEGER, rsvpSessionProtocol Protocol, rsvpSessionPort Port, rsvpSessionSenders Gauge32, rsvpSessionReceivers Gauge32, rsvpSessionRequests Gauge32 } rsvpSessionNumber OBJECT-TYPE SYNTAX SessionNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of this session. This is for SNMP Baker, et. al. Standards Track [Page 6] RFC 2206 RSVP MIB using SMIv2 September 1997 Indexing purposes only and has no relation to any protocol value." ::= { rsvpSessionEntry 1 } rsvpSessionType OBJECT-TYPE SYNTAX SessionType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of session (IP4, IP6, IP6 with flow information, etc)." ::= { rsvpSessionEntry 2 } rsvpSessionDestAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The destination address used by all senders in this session. This object may not be changed when the value of the RowStatus object is 'ac- tive'." ::= { rsvpSessionEntry 3 } rsvpSessionDestAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-only STATUS current DESCRIPTION "The CIDR prefix length of the session address, which is 32 for IP4 host and multicast ad- dresses, and 128 for IP6 addresses. This ob- ject may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpSessionEntry 4 } rsvpSessionProtocol OBJECT-TYPE SYNTAX Protocol MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Protocol used by this session. This object may not be changed when the value of the RowStatus object is 'active'." Baker, et. al. Standards Track [Page 7] RFC 2206 RSVP MIB using SMIv2 September 1997 ::= { rsvpSessionEntry 5 } rsvpSessionPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-only STATUS current DESCRIPTION "The UDP or TCP port number used as a destina- tion port for all senders in this session. If the IP protocol in use, specified by rsvpSen- derProtocol, is 50 (ESP) or 51 (AH), this represents a virtual destination port number. A value of zero indicates that the IP protocol in use does not have ports. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpSessionEntry 6 } rsvpSessionSenders OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of distinct senders currently known to be part of this session." ::= { rsvpSessionEntry 7 } rsvpSessionReceivers OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reservations being requested of this system for this session." ::= { rsvpSessionEntry 8 } rsvpSessionRequests OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reservation requests this system is sending upstream for this session." ::= { rsvpSessionEntry 9 } Baker, et. al. Standards Track [Page 8] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpBadPackets OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object keeps a count of the number of bad RSVP packets received." ::= { rsvpGenObjects 1 } -- The RSVP Session Sender Database contains the information -- displayed by senders regarding their potential contribution -- to session data content. It is in essence a list of the -- valid PATH messages that the RSVP Router or Host is receiving. rsvpSenderNewIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assign values to rsvpSenderNumber as described in 'Textual Con- ventions for SNMPv2'. The network manager reads the object, and then writes the value back in the SET that creates a new instance of rsvpSenderEntry. If the SET fails with the code 'inconsistentValue', then the process must be repeated; If the SET succeeds, then the ob- ject is incremented, and the new instance is created according to the manager's directions." ::= { rsvpGenObjects 2 } rsvpSenderTable OBJECT-TYPE SYNTAX SEQUENCE OF RsvpSenderEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the state information displayed by senders in PATH messages." ::= { rsvpObjects 2 } rsvpSenderEntry OBJECT-TYPE SYNTAX RsvpSenderEntry MAX-ACCESS not-accessible STATUS current Baker, et. al. Standards Track [Page 9] RFC 2206 RSVP MIB using SMIv2 September 1997 DESCRIPTION "Information describing the state information displayed by a single sender's PATH message." INDEX { rsvpSessionNumber, rsvpSenderNumber } ::= { rsvpSenderTable 1 } RsvpSenderEntry ::= SEQUENCE { rsvpSenderNumber SessionNumber, rsvpSenderType SessionType, rsvpSenderDestAddr OCTET STRING, rsvpSenderAddr OCTET STRING, rsvpSenderDestAddrLength INTEGER, rsvpSenderAddrLength INTEGER, rsvpSenderProtocol Protocol, rsvpSenderDestPort Port, rsvpSenderPort Port, rsvpSenderFlowId INTEGER, rsvpSenderHopAddr OCTET STRING, rsvpSenderHopLih Integer32, rsvpSenderInterface InterfaceIndex, rsvpSenderTSpecRate BitRate, rsvpSenderTSpecPeakRate BitRate, rsvpSenderTSpecBurst BurstSize, rsvpSenderTSpecMinTU MessageSize, rsvpSenderTSpecMaxTU MessageSize, rsvpSenderInterval RefreshInterval, rsvpSenderRSVPHop TruthValue, rsvpSenderLastChange TimeStamp, rsvpSenderPolicy OCTET STRING, rsvpSenderAdspecBreak TruthValue, rsvpSenderAdspecHopCount INTEGER, rsvpSenderAdspecPathBw BitRate, rsvpSenderAdspecMinLatency Integer32, rsvpSenderAdspecMtu INTEGER, rsvpSenderAdspecGuaranteedSvc TruthValue, rsvpSenderAdspecGuaranteedBreak TruthValue, rsvpSenderAdspecGuaranteedCtot Integer32, rsvpSenderAdspecGuaranteedDtot Integer32, rsvpSenderAdspecGuaranteedCsum Integer32, rsvpSenderAdspecGuaranteedDsum Integer32, rsvpSenderAdspecGuaranteedHopCount INTEGER, rsvpSenderAdspecGuaranteedPathBw BitRate, rsvpSenderAdspecGuaranteedMinLatency Integer32, rsvpSenderAdspecGuaranteedMtu INTEGER, rsvpSenderAdspecCtrlLoadSvc TruthValue, Baker, et. al. Standards Track [Page 10] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpSenderAdspecCtrlLoadBreak TruthValue, rsvpSenderAdspecCtrlLoadHopCount INTEGER, rsvpSenderAdspecCtrlLoadPathBw BitRate, rsvpSenderAdspecCtrlLoadMinLatency Integer32, rsvpSenderAdspecCtrlLoadMtu INTEGER, rsvpSenderStatus RowStatus, rsvpSenderTTL INTEGER } rsvpSenderNumber OBJECT-TYPE SYNTAX SessionNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of this sender. This is for SNMP Indexing purposes only and has no relation to any protocol value." ::= { rsvpSenderEntry 1 } rsvpSenderType OBJECT-TYPE SYNTAX SessionType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of session (IP4, IP6, IP6 with flow information, etc)." ::= { rsvpSenderEntry 2 } rsvpSenderDestAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The destination address used by all senders in this session. This object may not be changed when the value of the RowStatus object is 'ac- tive'." ::= { rsvpSenderEntry 3 } rsvpSenderAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current Baker, et. al. Standards Track [Page 11] RFC 2206 RSVP MIB using SMIv2 September 1997 DESCRIPTION "The source address used by this sender in this session. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpSenderEntry 4 } rsvpSenderDestAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the destination address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpSenderEntry 5 } rsvpSenderAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the sender's address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpSenderEntry 6 } rsvpSenderProtocol OBJECT-TYPE SYNTAX Protocol MAX-ACCESS read-create STATUS current DESCRIPTION "The IP Protocol used by this session. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpSenderEntry 7 } rsvpSenderDestPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-create STATUS current Baker, et. al. Standards Track [Page 12] RFC 2206 RSVP MIB using SMIv2 September 1997 DESCRIPTION "The UDP or TCP port number used as a destina- tion port for all senders in this session. If the IP protocol in use, specified by rsvpSen- derProtocol, is 50 (ESP) or 51 (AH), this represents a virtual destination port number. A value of zero indicates that the IP protocol in use does not have ports. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpSenderEntry 8 } rsvpSenderPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-create STATUS current DESCRIPTION "The UDP or TCP port number used as a source port for this sender in this session. If the IP protocol in use, specified by rsvpSenderPro- tocol is 50 (ESP) or 51 (AH), this represents a generalized port identifier (GPI). A value of zero indicates that the IP protocol in use does not have ports. This object may not be changed when the value of the RowStatus object is 'ac- tive'." ::= { rsvpSenderEntry 9 } rsvpSenderFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this sender is using, if this is an IPv6 session." ::= { rsvpSenderEntry 10 } rsvpSenderHopAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The address used by the previous RSVP hop (which may be the original sender)." ::= { rsvpSenderEntry 11 } Baker, et. al. Standards Track [Page 13] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpSenderHopLih OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Logical Interface Handle used by the pre- vious RSVP hop (which may be the original sender)." ::= { rsvpSenderEntry 12 } rsvpSenderInterface OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value of the interface on which this PATH message was most recently received." ::= { rsvpSenderEntry 13 } rsvpSenderTSpecRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The Average Bit Rate of the sender's data stream. Within a transmission burst, the ar- rival rate may be as fast as rsvpSenderTSpec- PeakRate (if supported by the service model); however, averaged across two or more burst in- tervals, the rate should not exceed rsvpSen- derTSpecRate. Note that this is a prediction, often based on the general capability of a type of codec or particular encoding; the measured average rate may be significantly lower." ::= { rsvpSenderEntry 14 } rsvpSenderTSpecPeakRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION Baker, et. al. Standards Track [Page 14] RFC 2206 RSVP MIB using SMIv2 September 1997 "The Peak Bit Rate of the sender's data stream. Traffic arrival is not expected to exceed this rate at any time, apart from the effects of jitter in the network. If not specified in the TSpec, this returns zero or noSuchValue." ::= { rsvpSenderEntry 15 } rsvpSenderTSpecBurst OBJECT-TYPE SYNTAX BurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The size of the largest burst expected from the sender at a time." ::= { rsvpSenderEntry 16 } rsvpSenderTSpecMinTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum message size for this flow. The policing algorithm will treat smaller messages as though they are this size." ::= { rsvpSenderEntry 17 } rsvpSenderTSpecMaxTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum message size for this flow. The admission algorithm will reject TSpecs whose Maximum Transmission Unit, plus the interface headers, exceed the interface MTU." ::= { rsvpSenderEntry 18 } rsvpSenderInterval OBJECT-TYPE SYNTAX RefreshInterval MAX-ACCESS read-create STATUS current DESCRIPTION "The interval between refresh messages as ad- Baker, et. al. Standards Track [Page 15] RFC 2206 RSVP MIB using SMIv2 September 1997 vertised by the Previous Hop." ::= { rsvpSenderEntry 19 } rsvpSenderRSVPHop OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, the node believes that the previous IP hop is an RSVP hop. If FALSE, the node be- lieves that the previous IP hop may not be an RSVP hop." ::= { rsvpSenderEntry 20 } rsvpSenderLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time of the last change in this PATH mes- sage; This is either the first time it was re- ceived or the time of the most recent change in parameters." ::= { rsvpSenderEntry 21 } rsvpSenderPolicy OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..65536)) MAX-ACCESS read-create STATUS current DESCRIPTION "The contents of the policy object, displayed as an uninterpreted string of octets, including the object header. In the absence of such an object, this should be of zero length." ::= { rsvpSenderEntry 22 } rsvpSenderAdspecBreak OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The global break bit general characterization parameter from the ADSPEC. If TRUE, at least one non-IS hop was detected in the path. If Baker, et. al. Standards Track [Page 16] RFC 2206 RSVP MIB using SMIv2 September 1997 FALSE, no non-IS hops were detected." ::= { rsvpSenderEntry 23 } rsvpSenderAdspecHopCount OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The hop count general characterization parame- ter from the ADSPEC. A return of zero or noSuchValue indicates one of the following con- ditions: the invalid bit was set the parameter was not present" ::= { rsvpSenderEntry 24 } rsvpSenderAdspecPathBw OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The path bandwidth estimate general character- ization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the fol- lowing conditions: the invalid bit was set the parameter was not present" ::= { rsvpSenderEntry 25 } rsvpSenderAdspecMinLatency OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum path latency general characteriza- tion parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the fol- lowing conditions: the invalid bit was set the parameter was not present" Baker, et. al. Standards Track [Page 17] RFC 2206 RSVP MIB using SMIv2 September 1997 ::= { rsvpSenderEntry 26 } rsvpSenderAdspecMtu OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The composed Maximum Transmission Unit general characterization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the following conditions: the invalid bit was set the parameter was not present" ::= { rsvpSenderEntry 27 } rsvpSenderAdspecGuaranteedSvc OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, the ADSPEC contains a Guaranteed Ser- vice fragment. If FALSE, the ADSPEC does not contain a Guaranteed Service fragment." ::= { rsvpSenderEntry 28 } rsvpSenderAdspecGuaranteedBreak OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, the Guaranteed Service fragment has its 'break' bit set, indicating that one or more nodes along the path do not support the guaranteed service. If FALSE, and rsvpSen- derAdspecGuaranteedSvc is TRUE, the 'break' bit is not set. If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns FALSE or noSuchValue." ::= { rsvpSenderEntry 29 } rsvpSenderAdspecGuaranteedCtot OBJECT-TYPE Baker, et. al. Standards Track [Page 18] RFC 2206 RSVP MIB using SMIv2 September 1997 SYNTAX Integer32 UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the end-to-end composed value for the guaranteed service 'C' parameter. A return of zero or noSuchValue indicates one of the fol- lowing conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 30 } rsvpSenderAdspecGuaranteedDtot OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the end-to-end composed value for the guaranteed service 'D' parameter. A return of zero or noSuchValue indicates one of the fol- lowing conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 31 } rsvpSenderAdspecGuaranteedCsum OBJECT-TYPE SYNTAX Integer32 UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the composed value for the guaranteed ser- Baker, et. al. Standards Track [Page 19] RFC 2206 RSVP MIB using SMIv2 September 1997 vice 'C' parameter since the last reshaping point. A return of zero or noSuchValue indi- cates one of the following conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 32 } rsvpSenderAdspecGuaranteedDsum OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the composed value for the guaranteed ser- vice 'D' parameter since the last reshaping point. A return of zero or noSuchValue indi- cates one of the following conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 33 } rsvpSenderAdspecGuaranteedHopCount OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the service-specific override of the hop count general characterization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the following conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this Baker, et. al. Standards Track [Page 20] RFC 2206 RSVP MIB using SMIv2 September 1997 returns zero or noSuchValue." ::= { rsvpSenderEntry 34 } rsvpSenderAdspecGuaranteedPathBw OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the service-specific override of the path bandwidth estimate general characterization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the following con- ditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 35 } rsvpSenderAdspecGuaranteedMinLatency OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the service-specific override of the minimum path latency general characterization parameter from the ADSPEC. A return of zero or noSuch- Value indicates one of the following condi- tions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 36 } rsvpSenderAdspecGuaranteedMtu OBJECT-TYPE SYNTAX INTEGER (0..65535) Baker, et. al. Standards Track [Page 21] RFC 2206 RSVP MIB using SMIv2 September 1997 UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecGuaranteedSvc is TRUE, this is the service-specific override of the com- posed Maximum Transmission Unit general charac- terization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the following conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecGuaranteedSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 37 } rsvpSenderAdspecCtrlLoadSvc OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, the ADSPEC contains a Controlled Load Service fragment. If FALSE, the ADSPEC does not contain a Controlled Load Service frag- ment." ::= { rsvpSenderEntry 38 } rsvpSenderAdspecCtrlLoadBreak OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, the Controlled Load Service fragment has its 'break' bit set, indicating that one or more nodes along the path do not support the controlled load service. If FALSE, and rsvpSenderAdspecCtrlLoadSvc is TRUE, the 'break' bit is not set. If rsvpSenderAdspecCtrlLoadSvc is FALSE, this returns FALSE or noSuchValue." ::= { rsvpSenderEntry 39 } Baker, et. al. Standards Track [Page 22] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpSenderAdspecCtrlLoadHopCount OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecCtrlLoadSvc is TRUE, this is the service-specific override of the hop count general characterization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the following conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecCtrlLoadSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 40 } rsvpSenderAdspecCtrlLoadPathBw OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecCtrlLoadSvc is TRUE, this is the service-specific override of the path bandwidth estimate general characterization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the following con- ditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecCtrlLoadSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 41 } rsvpSenderAdspecCtrlLoadMinLatency OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecCtrlLoadSvc is TRUE, this Baker, et. al. Standards Track [Page 23] RFC 2206 RSVP MIB using SMIv2 September 1997 is the service-specific override of the minimum path latency general characterization parameter from the ADSPEC. A return of zero or noSuch- Value indicates one of the following condi- tions: the invalid bit was set the parameter was not present If rsvpSenderAdspecCtrlLoadSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 42 } rsvpSenderAdspecCtrlLoadMtu OBJECT-TYPE SYNTAX INTEGER (0..65535) UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "If rsvpSenderAdspecCtrlLoadSvc is TRUE, this is the service-specific override of the com- posed Maximum Transmission Unit general charac- terization parameter from the ADSPEC. A return of zero or noSuchValue indicates one of the following conditions: the invalid bit was set the parameter was not present If rsvpSenderAdspecCtrlLoadSvc is FALSE, this returns zero or noSuchValue." ::= { rsvpSenderEntry 43 } rsvpSenderStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "'active' for all active PATH messages. This object may be used to install static PATH in- formation or delete PATH information." ::= { rsvpSenderEntry 44 } rsvpSenderTTL OBJECT-TYPE SYNTAX INTEGER (0..255) Baker, et. al. Standards Track [Page 24] RFC 2206 RSVP MIB using SMIv2 September 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The TTL value in the RSVP header that was last received." ::= { rsvpSenderEntry 45 } rsvpSenderOutInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF RsvpSenderOutInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of outgoing interfaces that PATH messages use. The ifIndex is the ifIndex value of the egress interface." ::= { rsvpObjects 3 } rsvpSenderOutInterfaceEntry OBJECT-TYPE SYNTAX RsvpSenderOutInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of outgoing interfaces that a particular PATH message has." INDEX { rsvpSessionNumber, rsvpSenderNumber, ifIndex } ::= { rsvpSenderOutInterfaceTable 1 } RsvpSenderOutInterfaceEntry ::= SEQUENCE { rsvpSenderOutInterfaceStatus RowStatus } rsvpSenderOutInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "'active' for all active PATH messages." ::= { rsvpSenderOutInterfaceEntry 1 } -- The RSVP Reservation Requests Received Table contains the -- information displayed by receivers regarding their needs with -- respect to sessions and senders. It is in essence a list of the -- valid RESV messages that the RSVP Router or Host is receiving. Baker, et. al. Standards Track [Page 25] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpResvNewIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assign values to rsvpResvNumber as described in 'Textual Conven- tions for SNMPv2'. The network manager reads the object, and then writes the value back in the SET that creates a new instance of rsvpResvEntry. If the SET fails with the code 'inconsistentValue', then the process must be repeated; If the SET succeeds, then the object is incremented, and the new instance is created according to the manager's directions." ::= { rsvpGenObjects 3 } rsvpResvTable OBJECT-TYPE SYNTAX SEQUENCE OF RsvpResvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the state information displayed by receivers in RESV messages." ::= { rsvpObjects 4 } rsvpResvEntry OBJECT-TYPE SYNTAX RsvpResvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the state information displayed by a single receiver's RESV message concerning a single sender." INDEX { rsvpSessionNumber, rsvpResvNumber } ::= { rsvpResvTable 1 } RsvpResvEntry ::= SEQUENCE { rsvpResvNumber SessionNumber, rsvpResvType SessionType, rsvpResvDestAddr OCTET STRING, rsvpResvSenderAddr OCTET STRING, rsvpResvDestAddrLength INTEGER, Baker, et. al. Standards Track [Page 26] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpResvSenderAddrLength INTEGER, rsvpResvProtocol Protocol, rsvpResvDestPort Port, rsvpResvPort Port, rsvpResvHopAddr OCTET STRING, rsvpResvHopLih Integer32, rsvpResvInterface InterfaceIndex, rsvpResvService QosService, rsvpResvTSpecRate BitRate, rsvpResvTSpecPeakRate BitRate, rsvpResvTSpecBurst BurstSize, rsvpResvTSpecMinTU MessageSize, rsvpResvTSpecMaxTU MessageSize, rsvpResvRSpecRate BitRate, rsvpResvRSpecSlack Integer32, rsvpResvInterval RefreshInterval, rsvpResvScope OCTET STRING, rsvpResvShared TruthValue, rsvpResvExplicit TruthValue, rsvpResvRSVPHop TruthValue, rsvpResvLastChange TimeStamp, rsvpResvPolicy OCTET STRING, rsvpResvStatus RowStatus, rsvpResvTTL INTEGER, rsvpResvFlowId INTEGER } rsvpResvNumber OBJECT-TYPE SYNTAX SessionNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of this reservation request. This is for SNMP Indexing purposes only and has no relation to any protocol value." ::= { rsvpResvEntry 1 } rsvpResvType OBJECT-TYPE SYNTAX SessionType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of session (IP4, IP6, IP6 with flow information, etc)." ::= { rsvpResvEntry 2 } Baker, et. al. Standards Track [Page 27] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpResvDestAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The destination address used by all senders in this session. This object may not be changed when the value of the RowStatus object is 'ac- tive'." ::= { rsvpResvEntry 3 } rsvpResvSenderAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The source address of the sender selected by this reservation. The value of all zeroes in- dicates 'all senders'. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvEntry 4 } rsvpResvDestAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the destination address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvEntry 5 } rsvpResvSenderAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the sender's address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." Baker, et. al. Standards Track [Page 28] RFC 2206 RSVP MIB using SMIv2 September 1997 ::= { rsvpResvEntry 6 } rsvpResvProtocol OBJECT-TYPE SYNTAX Protocol MAX-ACCESS read-create STATUS current DESCRIPTION "The IP Protocol used by this session. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvEntry 7 } rsvpResvDestPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-create STATUS current DESCRIPTION "The UDP or TCP port number used as a destina- tion port for all senders in this session. If the IP protocol in use, specified by rsvpResvProtocol, is 50 (ESP) or 51 (AH), this represents a virtual destination port number. A value of zero indicates that the IP protocol in use does not have ports. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvEntry 8 } rsvpResvPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-create STATUS current DESCRIPTION "The UDP or TCP port number used as a source port for this sender in this session. If the IP protocol in use, specified by rsvpResvProto- col is 50 (ESP) or 51 (AH), this represents a generalized port identifier (GPI). A value of zero indicates that the IP protocol in use does not have ports. This object may not be changed when the value of the RowStatus object is 'ac- tive'." ::= { rsvpResvEntry 9 } Baker, et. al. Standards Track [Page 29] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpResvHopAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The address used by the next RSVP hop (which may be the ultimate receiver)." ::= { rsvpResvEntry 10 } rsvpResvHopLih OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Logical Interface Handle received from the previous RSVP hop (which may be the ultimate receiver)." ::= { rsvpResvEntry 11 } rsvpResvInterface OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value of the interface on which this RESV message was most recently received." ::= { rsvpResvEntry 12 } rsvpResvService OBJECT-TYPE SYNTAX QosService MAX-ACCESS read-create STATUS current DESCRIPTION "The QoS Service classification requested by the receiver." ::= { rsvpResvEntry 13 } rsvpResvTSpecRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The Average Bit Rate of the sender's data Baker, et. al. Standards Track [Page 30] RFC 2206 RSVP MIB using SMIv2 September 1997 stream. Within a transmission burst, the ar- rival rate may be as fast as rsvpResvTSpec- PeakRate (if supported by the service model); however, averaged across two or more burst in- tervals, the rate should not exceed rsvpResvTSpecRate. Note that this is a prediction, often based on the general capability of a type of codec or particular encoding; the measured average rate may be significantly lower." ::= { rsvpResvEntry 14 } rsvpResvTSpecPeakRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The Peak Bit Rate of the sender's data stream. Traffic arrival is not expected to exceed this rate at any time, apart from the effects of jitter in the network. If not specified in the TSpec, this returns zero or noSuchValue." ::= { rsvpResvEntry 15 } rsvpResvTSpecBurst OBJECT-TYPE SYNTAX BurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The size of the largest burst expected from the sender at a time. If this is less than the sender's advertised burst size, the receiver is asking the network to provide flow pacing beyond what would be provided under normal circumstances. Such pac- ing is at the network's option." ::= { rsvpResvEntry 16 } rsvpResvTSpecMinTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-create Baker, et. al. Standards Track [Page 31] RFC 2206 RSVP MIB using SMIv2 September 1997 STATUS current DESCRIPTION "The minimum message size for this flow. The policing algorithm will treat smaller messages as though they are this size." ::= { rsvpResvEntry 17 } rsvpResvTSpecMaxTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum message size for this flow. The admission algorithm will reject TSpecs whose Maximum Transmission Unit, plus the interface headers, exceed the interface MTU." ::= { rsvpResvEntry 18 } rsvpResvRSpecRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "If the requested service is Guaranteed, as specified by rsvpResvService, this is the clearing rate that is being requested. Other- wise, it is zero, or the agent may return noSuchValue." ::= { rsvpResvEntry 19 } rsvpResvRSpecSlack OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "If the requested service is Guaranteed, as specified by rsvpResvService, this is the delay slack. Otherwise, it is zero, or the agent may return noSuchValue." ::= { rsvpResvEntry 20 } rsvpResvInterval OBJECT-TYPE Baker, et. al. Standards Track [Page 32] RFC 2206 RSVP MIB using SMIv2 September 1997 SYNTAX RefreshInterval MAX-ACCESS read-create STATUS current DESCRIPTION "The interval between refresh messages as ad- vertised by the Next Hop." ::= { rsvpResvEntry 21 } rsvpResvScope OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..65536)) MAX-ACCESS read-create STATUS current DESCRIPTION "The contents of the scope object, displayed as an uninterpreted string of octets, including the object header. In the absence of such an object, this should be of zero length. If the length is non-zero, this contains a series of IP4 or IP6 addresses." ::= { rsvpResvEntry 22 } rsvpResvShared OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, a reservation shared among senders is requested. If FALSE, a reservation specific to this sender is requested." ::= { rsvpResvEntry 23 } rsvpResvExplicit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, individual senders are listed using Filter Specifications. If FALSE, all senders are implicitly selected. The Scope Object will contain a list of senders that need to receive this reservation request for the purpose of routing the RESV message." ::= { rsvpResvEntry 24 } Baker, et. al. Standards Track [Page 33] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpResvRSVPHop OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, the node believes that the previous IP hop is an RSVP hop. If FALSE, the node be- lieves that the previous IP hop may not be an RSVP hop." ::= { rsvpResvEntry 25 } rsvpResvLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time of the last change in this reserva- tion request; This is either the first time it was received or the time of the most recent change in parameters." ::= { rsvpResvEntry 26 } rsvpResvPolicy OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..65536)) MAX-ACCESS read-create STATUS current DESCRIPTION "The contents of the policy object, displayed as an uninterpreted string of octets, including the object header. In the absence of such an object, this should be of zero length." ::= { rsvpResvEntry 27 } rsvpResvStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "'active' for all active RESV messages. This object may be used to install static RESV in- formation or delete RESV information." ::= { rsvpResvEntry 28 } rsvpResvTTL OBJECT-TYPE Baker, et. al. Standards Track [Page 34] RFC 2206 RSVP MIB using SMIv2 September 1997 SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The TTL value in the RSVP header that was last received." ::= { rsvpResvEntry 29 } rsvpResvFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this receiver is using, if this is an IPv6 session." ::= { rsvpResvEntry 30 } -- The RSVP Reservation Requests Forwarded Table contains the -- information displayed by receivers regarding their needs with -- respect to sessions and senders. It is in essence a list of the -- valid RESV messages that the RSVP Router or Host is sending -- to its upstream neighbors. rsvpResvFwdNewIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assign values to rsvpResvFwdNumber as described in 'Textual Con- ventions for SNMPv2'. The network manager reads the object, and then writes the value back in the SET that creates a new instance of rsvpResvFwdEntry. If the SET fails with the code 'inconsistentValue', then the process must be repeated; If the SET succeeds, then the ob- ject is incremented, and the new instance is created according to the manager's directions." ::= { rsvpGenObjects 4 } rsvpResvFwdTable OBJECT-TYPE SYNTAX SEQUENCE OF RsvpResvFwdEntry MAX-ACCESS not-accessible STATUS current Baker, et. al. Standards Track [Page 35] RFC 2206 RSVP MIB using SMIv2 September 1997 DESCRIPTION "Information describing the state information displayed upstream in RESV messages." ::= { rsvpObjects 5 } rsvpResvFwdEntry OBJECT-TYPE SYNTAX RsvpResvFwdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the state information displayed upstream in an RESV message concern- ing a single sender." INDEX { rsvpSessionNumber, rsvpResvFwdNumber } ::= { rsvpResvFwdTable 1 } RsvpResvFwdEntry ::= SEQUENCE { rsvpResvFwdNumber SessionNumber, rsvpResvFwdType SessionType, rsvpResvFwdDestAddr OCTET STRING, rsvpResvFwdSenderAddr OCTET STRING, rsvpResvFwdDestAddrLength INTEGER, rsvpResvFwdSenderAddrLength INTEGER, rsvpResvFwdProtocol Protocol, rsvpResvFwdDestPort Port, rsvpResvFwdPort Port, rsvpResvFwdHopAddr OCTET STRING, rsvpResvFwdHopLih Integer32, rsvpResvFwdInterface InterfaceIndex, rsvpResvFwdService QosService, rsvpResvFwdTSpecRate BitRate, rsvpResvFwdTSpecPeakRate BitRate, rsvpResvFwdTSpecBurst BurstSize, rsvpResvFwdTSpecMinTU MessageSize, rsvpResvFwdTSpecMaxTU MessageSize, rsvpResvFwdRSpecRate BitRate, rsvpResvFwdRSpecSlack Integer32, rsvpResvFwdInterval RefreshInterval, rsvpResvFwdScope OCTET STRING, rsvpResvFwdShared TruthValue, rsvpResvFwdExplicit TruthValue, rsvpResvFwdRSVPHop TruthValue, rsvpResvFwdLastChange TimeStamp, rsvpResvFwdPolicy OCTET STRING, rsvpResvFwdStatus RowStatus, Baker, et. al. Standards Track [Page 36] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpResvFwdTTL INTEGER, rsvpResvFwdFlowId INTEGER } rsvpResvFwdNumber OBJECT-TYPE SYNTAX SessionNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of this reservation request. This is for SNMP Indexing purposes only and has no relation to any protocol value." ::= { rsvpResvFwdEntry 1 } rsvpResvFwdType OBJECT-TYPE SYNTAX SessionType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of session (IP4, IP6, IP6 with flow information, etc)." ::= { rsvpResvFwdEntry 2 } rsvpResvFwdDestAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The destination address used by all senders in this session. This object may not be changed when the value of the RowStatus object is 'ac- tive'." ::= { rsvpResvFwdEntry 3 } rsvpResvFwdSenderAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The source address of the sender selected by this reservation. The value of all zeroes in- dicates 'all senders'. This object may not be changed when the value of the RowStatus object is 'active'." Baker, et. al. Standards Track [Page 37] RFC 2206 RSVP MIB using SMIv2 September 1997 ::= { rsvpResvFwdEntry 4 } rsvpResvFwdDestAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-only STATUS current DESCRIPTION "The length of the destination address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvFwdEntry 5 } rsvpResvFwdSenderAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-only STATUS current DESCRIPTION "The length of the sender's address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvFwdEntry 6 } rsvpResvFwdProtocol OBJECT-TYPE SYNTAX Protocol MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Protocol used by a session. for secure sessions, this indicates IP Security. This ob- ject may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvFwdEntry 7 } rsvpResvFwdDestPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-only STATUS current DESCRIPTION "The UDP or TCP port number used as a destina- tion port for all senders in this session. If Baker, et. al. Standards Track [Page 38] RFC 2206 RSVP MIB using SMIv2 September 1997 the IP protocol in use, specified by rsvpResvFwdProtocol, is 50 (ESP) or 51 (AH), this represents a virtual destination port number. A value of zero indicates that the IP protocol in use does not have ports. This ob- ject may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvFwdEntry 8 } rsvpResvFwdPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-only STATUS current DESCRIPTION "The UDP or TCP port number used as a source port for this sender in this session. If the IP protocol in use, specified by rsvpResvFwdProtocol is 50 (ESP) or 51 (AH), this represents a generalized port identifier (GPI). A value of zero indicates that the IP protocol in use does not have ports. This ob- ject may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpResvFwdEntry 9 } rsvpResvFwdHopAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the (previous) RSVP that will receive this message." ::= { rsvpResvFwdEntry 10 } rsvpResvFwdHopLih OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Logical Interface Handle sent to the (pre- vious) RSVP that will receive this message." ::= { rsvpResvFwdEntry 11 } rsvpResvFwdInterface OBJECT-TYPE Baker, et. al. Standards Track [Page 39] RFC 2206 RSVP MIB using SMIv2 September 1997 SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the interface on which this RESV message was most recently sent." ::= { rsvpResvFwdEntry 12 } rsvpResvFwdService OBJECT-TYPE SYNTAX QosService MAX-ACCESS read-only STATUS current DESCRIPTION "The QoS Service classification requested." ::= { rsvpResvFwdEntry 13 } rsvpResvFwdTSpecRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The Average Bit Rate of the sender's data stream. Within a transmission burst, the ar- rival rate may be as fast as rsvpResvFwdTSpec- PeakRate (if supported by the service model); however, averaged across two or more burst in- tervals, the rate should not exceed rsvpResvFwdTSpecRate. Note that this is a prediction, often based on the general capability of a type of codec or particular encoding; the measured average rate may be significantly lower." ::= { rsvpResvFwdEntry 14 } rsvpResvFwdTSpecPeakRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The Peak Bit Rate of the sender's data stream Traffic arrival is not expected to exceed this rate at any time, apart from the effects of Baker, et. al. Standards Track [Page 40] RFC 2206 RSVP MIB using SMIv2 September 1997 jitter in the network. If not specified in the TSpec, this returns zero or noSuchValue." ::= { rsvpResvFwdEntry 15 } rsvpResvFwdTSpecBurst OBJECT-TYPE SYNTAX BurstSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the largest burst expected from the sender at a time. If this is less than the sender's advertised burst size, the receiver is asking the network to provide flow pacing beyond what would be provided under normal circumstances. Such pac- ing is at the network's option." ::= { rsvpResvFwdEntry 16 } rsvpResvFwdTSpecMinTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum message size for this flow. The policing algorithm will treat smaller messages as though they are this size." ::= { rsvpResvFwdEntry 17 } rsvpResvFwdTSpecMaxTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum message size for this flow. The admission algorithm will reject TSpecs whose Maximum Transmission Unit, plus the interface headers, exceed the interface MTU." ::= { rsvpResvFwdEntry 18 } rsvpResvFwdRSpecRate OBJECT-TYPE SYNTAX BitRate UNITS "bytes per second" Baker, et. al. Standards Track [Page 41] RFC 2206 RSVP MIB using SMIv2 September 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "If the requested service is Guaranteed, as specified by rsvpResvService, this is the clearing rate that is being requested. Other- wise, it is zero, or the agent may return noSuchValue." ::= { rsvpResvFwdEntry 19 } rsvpResvFwdRSpecSlack OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the requested service is Guaranteed, as specified by rsvpResvService, this is the delay slack. Otherwise, it is zero, or the agent may return noSuchValue." ::= { rsvpResvFwdEntry 20 } rsvpResvFwdInterval OBJECT-TYPE SYNTAX RefreshInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The interval between refresh messages adver- tised to the Previous Hop." ::= { rsvpResvFwdEntry 21 } rsvpResvFwdScope OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..65536)) MAX-ACCESS read-only STATUS current DESCRIPTION "The contents of the scope object, displayed as an uninterpreted string of octets, including the object header. In the absence of such an object, this should be of zero length." ::= { rsvpResvFwdEntry 22 } rsvpResvFwdShared OBJECT-TYPE SYNTAX TruthValue Baker, et. al. Standards Track [Page 42] RFC 2206 RSVP MIB using SMIv2 September 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "If TRUE, a reservation shared among senders is requested. If FALSE, a reservation specific to this sender is requested." ::= { rsvpResvFwdEntry 23 } rsvpResvFwdExplicit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If TRUE, individual senders are listed using Filter Specifications. If FALSE, all senders are implicitly selected. The Scope Object will contain a list of senders that need to receive this reservation request for the purpose of routing the RESV message." ::= { rsvpResvFwdEntry 24 } rsvpResvFwdRSVPHop OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If TRUE, the node believes that the next IP hop is an RSVP hop. If FALSE, the node be- lieves that the next IP hop may not be an RSVP hop." ::= { rsvpResvFwdEntry 25 } rsvpResvFwdLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time of the last change in this request; This is either the first time it was sent or the time of the most recent change in parame- ters." ::= { rsvpResvFwdEntry 26 } rsvpResvFwdPolicy OBJECT-TYPE Baker, et. al. Standards Track [Page 43] RFC 2206 RSVP MIB using SMIv2 September 1997 SYNTAX OCTET STRING (SIZE(0..65536)) MAX-ACCESS read-only STATUS current DESCRIPTION "The contents of the policy object, displayed as an uninterpreted string of octets, including the object header. In the absence of such an object, this should be of zero length." ::= { rsvpResvFwdEntry 27 } rsvpResvFwdStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "'active' for all active RESV messages. This object may be used to delete RESV information." ::= { rsvpResvFwdEntry 28 } rsvpResvFwdTTL OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The TTL value in the RSVP header that was last received." ::= { rsvpResvFwdEntry 29 } rsvpResvFwdFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this receiver is using, if this is an IPv6 session." ::= { rsvpResvFwdEntry 30 } -- The RSVP Interface Attributes Database contains the -- RSVP-specific information for an interface. Information -- that is shared with other reservation procedures such -- as ST-II is in the Integrated Interface Attributes -- Database. Baker, et. al. Standards Track [Page 44] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpIfTable OBJECT-TYPE SYNTAX SEQUENCE OF RsvpIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RSVP-specific attributes of the system's interfaces." ::= { rsvpObjects 6 } rsvpIfEntry OBJECT-TYPE SYNTAX RsvpIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RSVP-specific attributes of the a given interface." INDEX { ifIndex } ::= { rsvpIfTable 1 } RsvpIfEntry ::= SEQUENCE { rsvpIfUdpNbrs Gauge32, rsvpIfIpNbrs Gauge32, rsvpIfNbrs Gauge32, rsvpIfEnabled TruthValue, rsvpIfUdpRequired TruthValue, rsvpIfRefreshBlockadeMultiple INTEGER, rsvpIfRefreshMultiple INTEGER, rsvpIfTTL INTEGER, rsvpIfRefreshInterval TimeInterval, rsvpIfRouteDelay TimeInterval, rsvpIfStatus RowStatus } rsvpIfUdpNbrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of neighbors perceived to be using only the RSVP UDP Encapsulation." ::= { rsvpIfEntry 1 } rsvpIfIpNbrs OBJECT-TYPE SYNTAX Gauge32 Baker, et. al. Standards Track [Page 45] RFC 2206 RSVP MIB using SMIv2 September 1997 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of neighbors perceived to be using only the RSVP IP Encapsulation." ::= { rsvpIfEntry 2 } rsvpIfNbrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of neighbors currently perceived; this will exceed rsvpIfIpNbrs + rsvpIfUdpNbrs by the number of neighbors using both encapsu- lations." ::= { rsvpIfEntry 3 } rsvpIfRefreshBlockadeMultiple OBJECT-TYPE SYNTAX INTEGER (1..65536) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the RSVP value 'Kb', Which is the minimum number of refresh intervals that blockade state will last once entered." DEFVAL { 4 } ::= { rsvpIfEntry 4 } rsvpIfRefreshMultiple OBJECT-TYPE SYNTAX INTEGER (1..65536) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the RSVP value 'K', which is the number of refresh intervals which must elapse (minimum) before a PATH or RESV message which is not being refreshed will be aged out." DEFVAL { 3 } ::= { rsvpIfEntry 5 } rsvpIfTTL OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-create Baker, et. al. Standards Track [Page 46] RFC 2206 RSVP MIB using SMIv2 September 1997 STATUS current DESCRIPTION "The value of SEND_TTL used on this interface for messages this node originates. If set to zero, the node determines the TTL via other means." DEFVAL { 0 } -- which is to say, no override ::= { rsvpIfEntry 6 } rsvpIfRefreshInterval OBJECT-TYPE SYNTAX TimeInterval UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the RSVP value 'R', which is the minimum period between refresh transmissions of a given PATH or RESV message on an interface." DEFVAL { 3000 } -- 30 seconds ::= { rsvpIfEntry 7 } rsvpIfRouteDelay OBJECT-TYPE SYNTAX TimeInterval UNITS "hundredths of a second" MAX-ACCESS read-create STATUS current DESCRIPTION "The approximate period from the time a route is changed to the time a resulting message ap- pears on the interface." DEFVAL { 200 } -- 2 seconds ::= { rsvpIfEntry 8 } rsvpIfEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, RSVP is enabled on this Interface. If FALSE, RSVP is not enabled on this inter- face." ::= { rsvpIfEntry 9 } rsvpIfUdpRequired OBJECT-TYPE Baker, et. al. Standards Track [Page 47] RFC 2206 RSVP MIB using SMIv2 September 1997 SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If TRUE, manual configuration forces the use of UDP encapsulation on the interface. If FALSE, UDP encapsulation is only used if rsvpI- fUdpNbrs is not zero." ::= { rsvpIfEntry 10 } rsvpIfStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "'active' on interfaces that are configured for RSVP." ::= { rsvpIfEntry 11 } -- The RSVP Neighbor Database lists the neighbors the RSVP -- process currently is receiving messages from. rsvpNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF RsvpNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the Neighbors of an RSVP system." ::= { rsvpObjects 7 } rsvpNbrEntry OBJECT-TYPE SYNTAX RsvpNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing a single RSVP Neigh- bor." INDEX { ifIndex, rsvpNbrAddress } ::= { rsvpNbrTable 1 } RsvpNbrEntry ::= SEQUENCE { Baker, et. al. Standards Track [Page 48] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpNbrAddress OCTET STRING, rsvpNbrProtocol RsvpEncapsulation, rsvpNbrStatus RowStatus } rsvpNbrAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP4 or IP6 Address used by this neighbor. This object may not be changed when the value of the RowStatus object is 'active'." ::= { rsvpNbrEntry 1 } rsvpNbrProtocol OBJECT-TYPE SYNTAX RsvpEncapsulation MAX-ACCESS read-create STATUS current DESCRIPTION "The encapsulation being used by this neigh- bor." ::= { rsvpNbrEntry 2 } rsvpNbrStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "'active' for all neighbors. This object may be used to configure neighbors. In the pres- ence of configured neighbors, the implementa- tion may (but is not required to) limit the set of valid neighbors to those configured." ::= { rsvpNbrEntry 3 } -- -- Notifications used to signal events -- rsvpNotifications OBJECT IDENTIFIER ::= { rsvpNotificationsPrefix 0 } newFlow NOTIFICATION-TYPE Baker, et. al. Standards Track [Page 49] RFC 2206 RSVP MIB using SMIv2 September 1997 OBJECTS { intSrvFlowStatus, rsvpSessionDestAddr, rsvpResvFwdStatus, rsvpResvStatus, rsvpSenderStatus } STATUS current DESCRIPTION "The newFlow trap indicates that the originat- ing system has installed a new flow in its classifier, or (when reservation authorization is in view) is prepared to install such a flow in the classifier and is requesting authoriza- tion. The objects included with the Notifica- tion may be used to read further information using the Integrated Services and RSVP MIBs. Authorization or non-authorization may be enacted by a write to the variable intSrvFlowS- tatus." ::= { rsvpNotifications 1 } lostFlow NOTIFICATION-TYPE OBJECTS { intSrvFlowStatus, rsvpSessionDestAddr, rsvpResvFwdStatus, rsvpResvStatus, rsvpSenderStatus } STATUS current DESCRIPTION "The lostFlow trap indicates that the originat- ing system has removed a flow from its classif- ier." ::= { rsvpNotifications 2 } -- conformance information rsvpGroups OBJECT IDENTIFIER ::= { rsvpConformance 1 } rsvpCompliances OBJECT IDENTIFIER ::= { rsvpConformance 2 } -- compliance statements rsvpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement. Note that the im- plementation of this module requires implemen- tation of the Integrated Services MIB as well." Baker, et. al. Standards Track [Page 50] RFC 2206 RSVP MIB using SMIv2 September 1997 MODULE -- this module MANDATORY-GROUPS { rsvpSessionGroup, rsvpSenderGroup, rsvpResvGroup, rsvpIfGroup, rsvpNbrGroup } GROUP rsvpResvFwdGroup DESCRIPTION "The Reservation Requests table is appropriate in implementations that store upstream reserva- tion messages, but not appropriate in implemen- tations which calculate them on each transmis- sion." GROUP rsvpNotificationGroup DESCRIPTION "The notifications in this module may be used to advise a network management station of changes in flow status, and are required when this use is in view." OBJECT rsvpSessionRequests MIN-ACCESS not-accessible DESCRIPTION "This object is optional." OBJECT rsvpSenderType MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderDestAddr MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderAddr MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderDestAddrLength MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be Baker, et. al. Standards Track [Page 51] RFC 2206 RSVP MIB using SMIv2 September 1997 read-only." OBJECT rsvpSenderAddrLength MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderProtocol MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderDestPort MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderPort MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderHopAddr MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderHopLih MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderInterface MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderTSpecRate MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be Baker, et. al. Standards Track [Page 52] RFC 2206 RSVP MIB using SMIv2 September 1997 read-only." OBJECT rsvpSenderTSpecPeakRate MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderTSpecBurst MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderTSpecMinTU MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderTSpecMaxTU MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderInterval MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderRSVPHop MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderPolicy MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderAdspecBreak MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be Baker, et. al. Standards Track [Page 53] RFC 2206 RSVP MIB using SMIv2 September 1997 read-only." OBJECT rsvpSenderAdspecHopCount MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderAdspecPathBw MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderAdspecMinLatency MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderAdspecMtu MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderAdspecGuaranteedSvc MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedBreak MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedCtot MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedDtot MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not Baker, et. al. Standards Track [Page 54] RFC 2206 RSVP MIB using SMIv2 September 1997 support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedCsum MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedDsum MIN-ACCESS read-only DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedHopCount MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedPathBw MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedMinLatency MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecGuaranteedMtu MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Guaranteed Service." OBJECT rsvpSenderAdspecCtrlLoadSvc MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Controlled Load." OBJECT rsvpSenderAdspecCtrlLoadBreak MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not Baker, et. al. Standards Track [Page 55] RFC 2206 RSVP MIB using SMIv2 September 1997 support Controlled Load." OBJECT rsvpSenderAdspecCtrlLoadHopCount MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Controlled Load." OBJECT rsvpSenderAdspecCtrlLoadPathBw MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Controlled Load." OBJECT rsvpSenderAdspecCtrlLoadMinLatency MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Controlled Load." OBJECT rsvpSenderAdspecCtrlLoadMtu MIN-ACCESS not-accessible DESCRIPTION "This may be not-accessible if the system does not support Controlled Load." OBJECT rsvpSenderStatus MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpSenderFlowId MIN-ACCESS not-accessible DESCRIPTION "This object is needed only in a system that imple- ments IPv6." OBJECT rsvpResvType MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvDestAddr MIN-ACCESS read-only DESCRIPTION Baker, et. al. Standards Track [Page 56] RFC 2206 RSVP MIB using SMIv2 September 1997 "read-create access is not required. This may be read-only." OBJECT rsvpResvSenderAddr MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvDestAddrLength MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvSenderAddrLength MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvProtocol MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvDestPort MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvPort MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvHopAddr MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvHopLih MIN-ACCESS read-only DESCRIPTION Baker, et. al. Standards Track [Page 57] RFC 2206 RSVP MIB using SMIv2 September 1997 "read-create access is not required. This may be read-only." OBJECT rsvpResvInterface MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvService MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvTSpecRate MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvTSpecPeakRate MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvTSpecBurst MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvTSpecMinTU MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvTSpecMaxTU MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvRSpecRate MIN-ACCESS read-only DESCRIPTION Baker, et. al. Standards Track [Page 58] RFC 2206 RSVP MIB using SMIv2 September 1997 "read-create access is not required. This may be read-only." OBJECT rsvpResvRSpecSlack MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvInterval MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvScope MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvShared MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvExplicit MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvRSVPHop MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvPolicy MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvStatus MIN-ACCESS read-only DESCRIPTION Baker, et. al. Standards Track [Page 59] RFC 2206 RSVP MIB using SMIv2 September 1997 "read-create access is not required. This may be read-only." OBJECT rsvpResvFlowId MIN-ACCESS not-accessible DESCRIPTION "This object is needed only in a system that imple- ments IPv6." OBJECT rsvpResvFwdStatus MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT rsvpResvFwdFlowId MIN-ACCESS not-accessible DESCRIPTION "This object is needed only in a system that imple- ments IPv6." ::= { rsvpCompliances 1 } rsvpSessionGroup OBJECT-GROUP OBJECTS { rsvpSessionType, rsvpSessionDestAddr, rsvpSessionDestAddrLength, rsvpSessionProtocol, rsvpSessionPort, rsvpSessionSenders, rsvpSessionReceivers, rsvpSessionRequests } STATUS current DESCRIPTION "These objects are required for RSVP Systems." ::= { rsvpGroups 1 } rsvpSenderGroup OBJECT-GROUP OBJECTS { rsvpSenderType, rsvpSenderDestAddr, rsvpSenderAddr, rsvpSenderDestAddrLength, rsvpSenderAddrLength, rsvpSenderProtocol, rsvpSenderDestPort, rsvpSenderPort, rsvpSenderHopAddr, rsvpSenderHopLih, rsvpSenderInterface, rsvpSenderTSpecRate, rsvpSenderTSpecPeakRate, rsvpSenderTSpecBurst, rsvpSenderTSpecMinTU, rsvpSenderTSpecMaxTU, rsvpSenderInterval, rsvpSenderLastChange, rsvpSenderStatus, rsvpSenderRSVPHop, rsvpSenderPolicy, rsvpSenderAdspecBreak, rsvpSenderAdspecHopCount, rsvpSenderAdspecPathBw, rsvpSenderAdspecMinLatency, Baker, et. al. Standards Track [Page 60] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpSenderAdspecMtu, rsvpSenderAdspecGuaranteedSvc, rsvpSenderAdspecGuaranteedBreak, rsvpSenderAdspecGuaranteedCtot, rsvpSenderAdspecGuaranteedDtot, rsvpSenderAdspecGuaranteedCsum, rsvpSenderAdspecGuaranteedDsum, rsvpSenderAdspecGuaranteedHopCount, rsvpSenderAdspecGuaranteedPathBw, rsvpSenderAdspecGuaranteedMinLatency, rsvpSenderAdspecGuaranteedMtu, rsvpSenderAdspecCtrlLoadSvc, rsvpSenderAdspecCtrlLoadBreak, rsvpSenderAdspecCtrlLoadHopCount, rsvpSenderAdspecCtrlLoadPathBw, rsvpSenderAdspecCtrlLoadMinLatency, rsvpSenderAdspecCtrlLoadMtu, rsvpSenderNewIndex } STATUS current DESCRIPTION "These objects are required for RSVP Systems." ::= { rsvpGroups 2 } rsvpResvGroup OBJECT-GROUP OBJECTS { rsvpResvType, rsvpResvDestAddr, rsvpResvSenderAddr, rsvpResvDestAddrLength, rsvpResvSenderAddrLength, rsvpResvProtocol, rsvpResvDestPort, rsvpResvPort, rsvpResvHopAddr, rsvpResvHopLih, rsvpResvInterface, rsvpResvService, rsvpResvTSpecRate, rsvpResvTSpecBurst, rsvpResvTSpecPeakRate, rsvpResvTSpecMinTU, rsvpResvTSpecMaxTU, rsvpResvRSpecRate, rsvpResvRSpecSlack, rsvpResvInterval, rsvpResvScope, rsvpResvShared, rsvpResvExplicit, rsvpResvRSVPHop, rsvpResvLastChange, rsvpResvPolicy, rsvpResvStatus, rsvpResvNewIndex } STATUS current DESCRIPTION "These objects are required for RSVP Systems." ::= { rsvpGroups 3 } rsvpResvFwdGroup OBJECT-GROUP OBJECTS { rsvpResvFwdType, rsvpResvFwdDestAddr, rsvpResvFwdSenderAddr, rsvpResvFwdDestAddrLength, rsvpResvFwdSenderAddrLength, rsvpResvFwdProtocol, rsvpResvFwdDestPort, rsvpResvFwdPort, rsvpResvFwdHopAddr, rsvpResvFwdHopLih, rsvpResvFwdInterface, Baker, et. al. Standards Track [Page 61] RFC 2206 RSVP MIB using SMIv2 September 1997 rsvpResvFwdNewIndex, rsvpResvFwdService, rsvpResvFwdTSpecPeakRate, rsvpResvFwdTSpecMinTU, rsvpResvFwdTSpecMaxTU, rsvpResvFwdTSpecRate, rsvpResvFwdTSpecBurst, rsvpResvFwdRSpecRate, rsvpResvFwdRSpecSlack, rsvpResvFwdInterval, rsvpResvFwdScope, rsvpResvFwdShared, rsvpResvFwdExplicit, rsvpResvFwdRSVPHop, rsvpResvFwdLastChange, rsvpResvFwdPolicy, rsvpResvFwdStatus } STATUS current DESCRIPTION "These objects are optional, used for some RSVP Systems." ::= { rsvpGroups 4 } rsvpIfGroup OBJECT-GROUP OBJECTS { rsvpIfUdpNbrs, rsvpIfIpNbrs, rsvpIfNbrs, rsvpIfEnabled, rsvpIfUdpRequired, rsvpIfRefreshBlockadeMultiple, rsvpIfRefreshMultiple, rsvpIfRefreshInterval, rsvpIfTTL, rsvpIfRouteDelay, rsvpIfStatus } STATUS current DESCRIPTION "These objects are required for RSVP Systems." ::= { rsvpGroups 6 } rsvpNbrGroup OBJECT-GROUP OBJECTS { rsvpNbrProtocol, rsvpNbrStatus } STATUS current DESCRIPTION "These objects are required for RSVP Systems." ::= { rsvpGroups 7 } rsvpNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { newFlow, lostFlow } STATUS current DESCRIPTION "This notification is required for Systems sup- porting the RSVP Policy Module using an SNMP interface to the Policy Manager." ::= { rsvpGroups 8 } Baker, et. al. Standards Track [Page 62] RFC 2206 RSVP MIB using SMIv2 September 1997 END 4. Security Considerations The use of an SNMP SET results in an RSVP or Integrated Services reservation under rules that are different compared to if the reservation was negotiated using RSVP. However, no other security considerations exist other than those imposed by SNMP itself. 5. Authors' Addresses Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: +1 805 681 0115 EMail: fred@cisco.com John Krawczyk Postal: ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886 Phone: +1 508 692 5875 EMail: jjk@tiac.net Arun Sastry Postal: Cisco Systems 210 W. Tasman Drive San Jose, California 95134 Phone: +1 408 526 7685 EMail: arun@cisco.com 6. Acknowledgements This document was produced by the RSVP Working Group. Baker, et. al. Standards Track [Page 63] RFC 2206 RSVP MIB using SMIv2 September 1997 7. References [1] Rose, M., Editor, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, May 1990. [2] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [3] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). Baker, et. al. Standards Track [Page 64] snmp-mibs-downloader-1.1/mibrfcs/rfc2213.txt0000644000000000000000000010646311402176071015563 0ustar Network Working Group F. Baker Request for Comments: 2213 Cisco Systems Category: Standards Track J. Krawczyk ArrowPoint Communications A. Sastry Cisco Systems September 1997 Integrated Services Management Information Base using SMIv2 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. Table of Contents 1 The SNMPv2 Network Management Framework ............... 2 1.1 Object Definitions .................................. 2 2 Overview .............................................. 2 2.1 Textual Conventions ................................. 2 2.2 Structure of MIB .................................... 3 3 Definitions ........................................... 3 3.2 Interface Attributes Database ....................... 6 3.3 Integrated Services Interface Flows Database ........ 8 4 Security Considerations ............................... 19 5 Authors' Addresses .................................... 20 6 Acknowledgements ...................................... 20 7 References ............................................ 20 Baker, et. al. Standards Track [Page 1] RFC 2213 Integrated Services MIB using SMIv2 September 1997 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1441 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. 2. Overview 2.1. Textual Conventions Several new data types are introduced as a textual convention in this MIB document. These textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of the these textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an Baker, et. al. Standards Track [Page 2] RFC 2213 Integrated Services MIB using SMIv2 September 1997 artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents. 2.2. Structure of MIB The MIB is composed of the following sections: Integrated Services Interface Attributes Table Interface Flow Table 3. Definitions INTEGRATED-SERVICES-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, mib-2 FROM SNMPv2-SMI TimeInterval, TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [9]. intSrv MODULE-IDENTITY LAST-UPDATED "9511030500Z" -- Thu Aug 28 09:04:13 PDT 1997 ORGANIZATION "IETF Integrated Services Working Group" CONTACT-INFO " Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Tel: +1 805 681 0115 E-Mail: fred@cisco.com John Krawczyk Postal: ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886 Tel: +1 508 692 5875 E-Mail: jjk@tiac.net" DESCRIPTION "The MIB module to describe the Integrated Services Baker, et. al. Standards Track [Page 3] RFC 2213 Integrated Services MIB using SMIv2 September 1997 Protocol" ::= { mib-2 52 } intSrvObjects OBJECT IDENTIFIER ::= { intSrv 1 } intSrvGenObjects OBJECT IDENTIFIER ::= { intSrv 2 } intSrvNotifications OBJECT IDENTIFIER ::= { intSrv 3 } intSrvConformance OBJECT IDENTIFIER ::= { intSrv 4 } -- Textual Conventions -- SessionNumber ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Session Number convention is used for numbers identifying sessions or saved PATH or RESV information. It is a number in the range returned by a TestAndIncr variable, having no protocol meaning whatsoever but serving instead as simple identifier. The alternative was a very complex instance or instance object that became unwieldy." SYNTAX INTEGER (0..2147483647) Protocol ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The value of the IP Protocol field of an IP Datagram Header. This identifies the protocol layer above IP. For example, the value 6 is used for TCP and the value 17 is used for UDP. The values of this field are defined in the As- signed Numbers RFC." SYNTAX INTEGER (1..255) SessionType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of the C-Type field of a Session ob- ject, as defined in the RSVP specification. This value determines the lengths of octet strings and use of certain objects such as the 'port' variables. If the C-Type calls for an IP6 address, one would expect all source, des- Baker, et. al. Standards Track [Page 4] RFC 2213 Integrated Services MIB using SMIv2 September 1997 tination, and next/previous hop addresses to be 16 bytes long, and for the ports to be UDP/TCP port numbers, for example." SYNTAX INTEGER (1..255) Port ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The value of the UDP or TCP Source or Destina- tion Port field, a virtual destination port or generalized port identifier used with the IPSEC Authentication Header or Encapsulating Security Payload, or other session discriminator. If it is not used, the value should be of length 0. This pair, when coupled with the IP Addresses of the source and destination system and the IP protocol field, uniquely identifies a data stream." SYNTAX OCTET STRING (SIZE(2..4)) MessageSize ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The size of a message in bytes. This is used to specify the minimum and maximum size of a message along an integrated services route." SYNTAX INTEGER (0..'7FFFFFFF'h) BitRate ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The rate, in bits/second, that data may move in the context. Applicable contexts minimally include the speed of an interface or virtual circuit, the data rate of a (potentially aggre- gated) data flow, or the data rate to be allo- cated for use by a flow." SYNTAX INTEGER (0..'7FFFFFFF'h) BurstSize ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION Baker, et. al. Standards Track [Page 5] RFC 2213 Integrated Services MIB using SMIv2 September 1997 "The number of octets of IP Data, including IP Headers, that a stream may send without concern for policing." SYNTAX INTEGER (0..'7FFFFFFF'h) QosService ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The class of service in use by a flow." SYNTAX INTEGER { bestEffort (1), -- Best Effort Service guaranteedDelay (2), -- Guaranteed Delay controlledLoad (5) -- Controlled Load } -- The Integrated Services Interface Attributes Database contains -- information about resources allocated by resource reservation -- protocols, such as RSVP and ST-II. intSrvIfAttribTable OBJECT-TYPE SYNTAX SEQUENCE OF IntSrvIfAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The reservable attributes of the system's in- terfaces." ::= { intSrvObjects 1 } intSrvIfAttribEntry OBJECT-TYPE SYNTAX IntSrvIfAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The reservable attributes of a given inter- face." INDEX { ifIndex } ::= { intSrvIfAttribTable 1 } IntSrvIfAttribEntry ::= SEQUENCE { intSrvIfAttribAllocatedBits BitRate, intSrvIfAttribMaxAllocatedBits BitRate, intSrvIfAttribAllocatedBuffer BurstSize, intSrvIfAttribFlows Gauge32, intSrvIfAttribPropagationDelay Integer32, Baker, et. al. Standards Track [Page 6] RFC 2213 Integrated Services MIB using SMIv2 September 1997 intSrvIfAttribStatus RowStatus } intSrvIfAttribAllocatedBits OBJECT-TYPE SYNTAX BitRate UNITS "Bits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bits/second currently allocated to reserved sessions on the interface." ::= { intSrvIfAttribEntry 1 } intSrvIfAttribMaxAllocatedBits OBJECT-TYPE SYNTAX BitRate UNITS "Bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of bits/second that may be allocated to reserved sessions on the inter- face." ::= { intSrvIfAttribEntry 2 } intSrvIfAttribAllocatedBuffer OBJECT-TYPE SYNTAX BurstSize UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of buffer space required to hold the simultaneous burst of all reserved flows on the interface." ::= { intSrvIfAttribEntry 3 } intSrvIfAttribFlows OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reserved flows currently active on this interface. A flow can be created ei- ther from a reservation protocol (such as RSVP or ST-II) or via configuration information." ::= { intSrvIfAttribEntry 4 } Baker, et. al. Standards Track [Page 7] RFC 2213 Integrated Services MIB using SMIv2 September 1997 intSrvIfAttribPropagationDelay OBJECT-TYPE SYNTAX Integer32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The amount of propagation delay that this in- terface introduces in addition to that intro- diced by bit propagation delays." DEFVAL { 0 }-- by default, interfaces are presumed to add -- no extra delays ::= { intSrvIfAttribEntry 5 } intSrvIfAttribStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "'active' on interfaces that are configured for RSVP." ::= { intSrvIfAttribEntry 6 } -- The Integrated Services Active Flows Database -- lists all flows active on an outgoing interface, including -- relevant attributes. intSrvFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF IntSrvFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the reserved flows us- ing the system's interfaces." ::= { intSrvObjects 2 } intSrvFlowEntry OBJECT-TYPE SYNTAX IntSrvFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the use of a given in- terface by a given flow. The counter intSrvFlowPoliced starts counting at the in- stallation of the flow." Baker, et. al. Standards Track [Page 8] RFC 2213 Integrated Services MIB using SMIv2 September 1997 INDEX { intSrvFlowNumber } ::= { intSrvFlowTable 1 } IntSrvFlowEntry ::= SEQUENCE { intSrvFlowNumber SessionNumber, intSrvFlowType SessionType, intSrvFlowOwner INTEGER, intSrvFlowDestAddr OCTET STRING, intSrvFlowSenderAddr OCTET STRING, intSrvFlowDestAddrLength INTEGER, intSrvFlowSenderAddrLength INTEGER, intSrvFlowProtocol Protocol, intSrvFlowDestPort Port, intSrvFlowPort Port, intSrvFlowFlowId INTEGER, intSrvFlowInterface InterfaceIndex, intSrvFlowIfAddr OCTET STRING, intSrvFlowRate BitRate, intSrvFlowBurst BurstSize, intSrvFlowWeight Integer32, intSrvFlowQueue Integer32, intSrvFlowMinTU MessageSize, intSrvFlowMaxTU MessageSize, intSrvFlowBestEffort Counter32, intSrvFlowPoliced Counter32, intSrvFlowDiscard TruthValue, intSrvFlowService QosService, intSrvFlowOrder INTEGER, intSrvFlowStatus RowStatus } intSrvFlowNumber OBJECT-TYPE SYNTAX SessionNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of this flow. This is for SNMP In- dexing purposes only and has no relation to any protocol value." ::= { intSrvFlowEntry 1 } intSrvFlowType OBJECT-TYPE SYNTAX SessionType MAX-ACCESS read-create Baker, et. al. Standards Track [Page 9] RFC 2213 Integrated Services MIB using SMIv2 September 1997 STATUS current DESCRIPTION "The type of session (IP4, IP6, IP6 with flow information, etc)." ::= { intSrvFlowEntry 2 } intSrvFlowOwner OBJECT-TYPE SYNTAX INTEGER { other(1), rsvp(2), management(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The process that installed this flow in the queue policy database." ::= { intSrvFlowEntry 3 } intSrvFlowDestAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The destination address used by all senders in this session. This object may not be changed when the value of the RowStatus object is 'ac- tive'." ::= { intSrvFlowEntry 4 } intSrvFlowSenderAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The source address of the sender selected by this reservation. The value of all zeroes in- dicates 'all senders'. This object may not be changed when the value of the RowStatus object is 'active'." ::= { intSrvFlowEntry 5 } intSrvFlowDestAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) Baker, et. al. Standards Track [Page 10] RFC 2213 Integrated Services MIB using SMIv2 September 1997 MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the destination address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." ::= { intSrvFlowEntry 6 } intSrvFlowSenderAddrLength OBJECT-TYPE SYNTAX INTEGER(0..128) MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the sender's address in bits. This is the CIDR Prefix Length, which for IP4 hosts and multicast addresses is 32 bits. This object may not be changed when the value of the RowStatus object is 'active'." ::= { intSrvFlowEntry 7 } intSrvFlowProtocol OBJECT-TYPE SYNTAX Protocol MAX-ACCESS read-create STATUS current DESCRIPTION "The IP Protocol used by a session. This ob- ject may not be changed when the value of the RowStatus object is 'active'." ::= { intSrvFlowEntry 8 } intSrvFlowDestPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-create STATUS current DESCRIPTION "The UDP or TCP port number used as a destina- tion port for all senders in this session. If the IP protocol in use, specified by intSrvResvFwdProtocol, is 50 (ESP) or 51 (AH), this represents a virtual destination port number. A value of zero indicates that the IP protocol in use does not have ports. This ob- ject may not be changed when the value of the Baker, et. al. Standards Track [Page 11] RFC 2213 Integrated Services MIB using SMIv2 September 1997 RowStatus object is 'active'." ::= { intSrvFlowEntry 9 } intSrvFlowPort OBJECT-TYPE SYNTAX Port MAX-ACCESS read-create STATUS current DESCRIPTION "The UDP or TCP port number used as a source port for this sender in this session. If the IP protocol in use, specified by intSrvResvFwdProtocol is 50 (ESP) or 51 (AH), this represents a generalized port identifier (GPI). A value of zero indicates that the IP protocol in use does not have ports. This ob- ject may not be changed when the value of the RowStatus object is 'active'." ::= { intSrvFlowEntry 10 } intSrvFlowFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this sender is using, if this is an IPv6 session." ::= { intSrvFlowEntry 11 } intSrvFlowInterface OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value of the interface on which this reservation exists." ::= { intSrvFlowEntry 12 } intSrvFlowIfAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The IP Address on the ifEntry on which this reservation exists. This is present primarily Baker, et. al. Standards Track [Page 12] RFC 2213 Integrated Services MIB using SMIv2 September 1997 to support those interfaces which layer multi- ple IP Addresses on the interface." ::= { intSrvFlowEntry 13 } intSrvFlowRate OBJECT-TYPE SYNTAX BitRate UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The Reserved Rate of the sender's data stream. If this is a Controlled Load service flow, this rate is derived from the Tspec rate parameter (r). If this is a Guaranteed service flow, this rate is derived from the Rspec clearing rate parameter (R)." ::= { intSrvFlowEntry 14 } intSrvFlowBurst OBJECT-TYPE SYNTAX BurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The size of the largest burst expected from the sender at a time. If this is less than the sender's advertised burst size, the receiver is asking the network to provide flow pacing beyond what would be provided under normal circumstances. Such pac- ing is at the network's option." ::= { intSrvFlowEntry 15 } intSrvFlowWeight OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The weight used to prioritize the traffic. Note that the interpretation of this object is implementation-specific, as implementations vary in their use of weighting procedures." ::= { intSrvFlowEntry 16 } Baker, et. al. Standards Track [Page 13] RFC 2213 Integrated Services MIB using SMIv2 September 1997 intSrvFlowQueue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of the queue used by this traffic. Note that the interpretation of this object is implementation-specific, as implementations vary in their use of queue identifiers." ::= { intSrvFlowEntry 17 } intSrvFlowMinTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum message size for this flow. The policing algorithm will treat smaller messages as though they are this size." ::= { intSrvFlowEntry 18 } intSrvFlowMaxTU OBJECT-TYPE SYNTAX MessageSize MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum datagram size for this flow that will conform to the traffic specification. This value cannot exceed the MTU of the interface." ::= { intSrvFlowEntry 19 } intSrvFlowBestEffort OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that were remanded to best effort service." ::= { intSrvFlowEntry 20 } intSrvFlowPoliced OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Baker, et. al. Standards Track [Page 14] RFC 2213 Integrated Services MIB using SMIv2 September 1997 DESCRIPTION "The number of packets policed since the incep- tion of the flow's service." ::= { intSrvFlowEntry 21 } intSrvFlowDiscard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If 'true', the flow is to incur loss when traffic is policed. If 'false', policed traff- ic is treated as best effort traffic." DEFVAL { false } -- traffic is, by default, treated as best -- effort ::= { intSrvFlowEntry 22 } intSrvFlowService OBJECT-TYPE SYNTAX QosService MAX-ACCESS read-only STATUS current DESCRIPTION "The QoS service being applied to this flow." ::= { intSrvFlowEntry 23 } intSrvFlowOrder OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "In the event of ambiguity, the order in which the classifier should make its comparisons. The row with intSrvFlowOrder=0 is tried first, and comparisons proceed in the order of in- creasing value. Non-serial implementations of the classifier should emulate this behavior." ::= { intSrvFlowEntry 24 } intSrvFlowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "'active' for all active flows. This object Baker, et. al. Standards Track [Page 15] RFC 2213 Integrated Services MIB using SMIv2 September 1997 may be used to install static classifier infor- mation, delete classifier information, or au- thorize such." ::= { intSrvFlowEntry 25 } intSrvFlowNewIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assign values to intSrvFlowNumber as described in 'Textual Con- ventions for SNMPv2'. The network manager reads the object, and then writes the value back in the SET that creates a new instance of intSrvFlowEntry. If the SET fails with the code 'inconsistentValue', then the process must be repeated; If the SET succeeds, then the ob- ject is incremented, and the new instance is created according to the manager's directions." ::= { intSrvGenObjects 1 } -- conformance information intSrvGroups OBJECT IDENTIFIER ::= { intSrvConformance 1 } intSrvCompliances OBJECT IDENTIFIER ::= { intSrvConformance 2 } -- compliance statements intSrvCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { intSrvIfAttribGroup, intSrvFlowsGroup } OBJECT intSrvFlowType MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowOwner MIN-ACCESS read-only Baker, et. al. Standards Track [Page 16] RFC 2213 Integrated Services MIB using SMIv2 September 1997 DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowDestAddr MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowSenderAddr MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowDestAddrLength MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowSenderAddrLength MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowProtocol MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowDestPort MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowPort MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowFlowId MIN-ACCESS not-accessible Baker, et. al. Standards Track [Page 17] RFC 2213 Integrated Services MIB using SMIv2 September 1997 DESCRIPTION "This object is needed only in a system that imple- ments IPv6." OBJECT intSrvFlowInterface MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowRate MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowBurst MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowWeight MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowQueue MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowMinTU MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowMaxTU MIN-ACCESS read-only DESCRIPTION "read-create access is not required. This may be read-only." OBJECT intSrvFlowStatus MIN-ACCESS read-only Baker, et. al. Standards Track [Page 18] RFC 2213 Integrated Services MIB using SMIv2 September 1997 DESCRIPTION "read-create access is not required. This may be read-only." ::= { intSrvCompliances 1 } intSrvIfAttribGroup OBJECT-GROUP OBJECTS { intSrvIfAttribAllocatedBits, intSrvIfAttribMaxAllocatedBits, intSrvIfAttribAllocatedBuffer, intSrvIfAttribFlows, intSrvIfAttribPropagationDelay, intSrvIfAttribStatus } STATUS current DESCRIPTION "These objects are required for Systems sup- porting the Integrated Services Architecture." ::= { intSrvGroups 1 } intSrvFlowsGroup OBJECT-GROUP OBJECTS { intSrvFlowType, intSrvFlowOwner, intSrvFlowDestAddr, intSrvFlowSenderAddr, intSrvFlowDestAddrLength, intSrvFlowSenderAddrLength, intSrvFlowProtocol, intSrvFlowDestPort, intSrvFlowPort, intSrvFlowInterface, intSrvFlowBestEffort, intSrvFlowRate, intSrvFlowBurst, intSrvFlowWeight, intSrvFlowQueue, intSrvFlowMinTU, intSrvFlowDiscard, intSrvFlowPoliced, intSrvFlowService, intSrvFlowIfAddr, intSrvFlowOrder, intSrvFlowStatus } STATUS current DESCRIPTION "These objects are required for Systems sup- porting the Integrated Services Architecture." ::= { intSrvGroups 2 } END 4. Security Considerations The use of an SNMP SET results in an RSVP or Integrated Services reservation under rules that are different compared to if the reservation was negotiated using RSVP. However, no other security considerations exist other than those imposed by SNMP itself. Baker, et. al. Standards Track [Page 19] RFC 2213 Integrated Services MIB using SMIv2 September 1997 5. Authors' Addresses Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: +1 805 681 0115 EMail: fred@cisco.com John Krawczyk Postal: ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886 Phone: +1 508 692 5875 EMail: jjk@tiac.net Arun Sastry Postal: Cisco Systems 210 W. Tasman Drive San Jose, California 95314 Phone: +1 408 526 7685 EMail: arun@cisco.com 6. Acknowledgements This document was produced by the Integrated Services Working Group. The authors would like to thank the following people for providing feedback on this document: Lou Berger, Fore Systems Bob Braden, ISI Viswanatha Rao, Compaq John Wroclawski, MIT 7. References [1] Rose, M., Editor, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, May 1990. [2] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, Baker, et. al. Standards Track [Page 20] RFC 2213 Integrated Services MIB using SMIv2 September 1997 1987). [3] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). Baker, et. al. Standards Track [Page 21] snmp-mibs-downloader-1.1/mibrfcs/rfc2214.txt0000644000000000000000000003714311402176071015562 0ustar Network Working Group F. Baker Request for Comments: 2214 Cisco Systems Category: Standards Track J. Krawczyk ArrowPoint Communications A. Sastry Cisco Systems September 1997 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. Comments should be made to the Integrated Services Working Group, intserv@isi.edu. Table of Contents 1 The SNMPv2 Network Management Framework ............... 2 1.1 Object Definitions .................................. 2 2 Overview .............................................. 2 2.1 Textual Conventions ................................. 2 3 Definitions ........................................... 3 3.1 Interface Attributes Database ....................... 3 3.2 Notifications ....................................... 6 4 Security Considerations ............................... 7 5 Authors' Addresses .................................... 8 6 Acknowledgements ...................................... 8 7 References ............................................ 8 Baker, et. al. Standards Track [Page 1] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1441 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. 2. Overview 2.1. Textual Conventions Several new data types are introduced as a textual convention in this MIB document. These textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of the these textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit Baker, et. al. Standards Track [Page 2] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 of the elusive goal of clear, concise, and unambiguous MIB documents. 3. Definitions INTEGRATED-SERVICES-GUARANTEED-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF intSrv FROM INTEGRATED-SERVICES-MIB ifIndex FROM IF-MIB; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [9]. intSrvGuaranteed MODULE-IDENTITY LAST-UPDATED "9511030500Z" -- Thu Aug 28 09:04:22 PDT 1997 ORGANIZATION "IETF Integrated Services Working Group" CONTACT-INFO " Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Tel: +1 805 681 0115 E-Mail: fred@cisco.com" DESCRIPTION "The MIB module to describe the Guaranteed Service of the Integrated Services Protocol" ::= { intSrv 5 } intSrvGuaranteedObjects OBJECT IDENTIFIER ::= { intSrvGuaranteed 1 } intSrvGuaranteedNotifications OBJECT IDENTIFIER ::= { intSrvGuaranteed 2 } intSrvGuaranteedConformance OBJECT IDENTIFIER ::= { intSrvGuaranteed 3 } -- The Integrated Services Interface Attributes Database -- contains information that is shared with other reservation -- procedures such as ST-II. intSrvGuaranteedIfTable OBJECT-TYPE SYNTAX SEQUENCE OF IntSrvGuaranteedIfEntry MAX-ACCESS not-accessible STATUS current Baker, et. al. Standards Track [Page 3] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 DESCRIPTION "The attributes of the system's interfaces ex- ported by the Guaranteed Service." ::= { intSrvGuaranteedObjects 1 } intSrvGuaranteedIfEntry OBJECT-TYPE SYNTAX IntSrvGuaranteedIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The reservable attributes of a given inter- face." INDEX { ifIndex } ::= { intSrvGuaranteedIfTable 1 } IntSrvGuaranteedIfEntry ::= SEQUENCE { intSrvGuaranteedIfBacklog INTEGER, intSrvGuaranteedIfDelay INTEGER, intSrvGuaranteedIfSlack INTEGER, intSrvGuaranteedIfStatus RowStatus } intSrvGuaranteedIfBacklog OBJECT-TYPE SYNTAX INTEGER (0..'0FFFFFFF'h) UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The Backlog parameter is the data backlog resulting from the vagaries of how a specific implementation deviates from a strict bit-by- bit service. So, for instance, for packetized weighted fair queueing, Backlog is set to the Maximum Packet Size. The Backlog term is measured in units of bytes. An individual element can advertise a Backlog value between 1 and 2**28 (a little over 250 megabytes) and the total added over all ele- ments can range as high as (2**32)-1. Should the sum of the different elements delay exceed (2**32)-1, the end-to-end error term should be (2**32)-1." ::= { intSrvGuaranteedIfEntry 1 } intSrvGuaranteedIfDelay OBJECT-TYPE Baker, et. al. Standards Track [Page 4] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 SYNTAX INTEGER (0..'0FFFFFFF'h) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Delay parameter at each service element should be set to the maximum packet transfer delay (independent of bucket size) through the service element. For instance, in a simple router, one might compute the worst case amount of time it make take for a datagram to get through the input interface to the processor, and how long it would take to get from the pro- cessor to the outbound interface (assuming the queueing schemes work correctly). For an Eth- ernet, it might represent the worst case delay if the maximum number of collisions is experi- enced. The Delay term is measured in units of one mi- crosecond. An individual element can advertise a delay value between 1 and 2**28 (somewhat over two minutes) and the total delay added all elements can range as high as (2**32)-1. Should the sum of the different elements delay exceed (2**32)-1, the end-to-end delay should be (2**32)-1." ::= { intSrvGuaranteedIfEntry 2 } intSrvGuaranteedIfSlack OBJECT-TYPE SYNTAX INTEGER (0..'0FFFFFFF'h) MAX-ACCESS read-create STATUS current DESCRIPTION "If a network element uses a certain amount of slack, Si, to reduce the amount of resources that it has reserved for a particular flow, i, the value Si should be stored at the network element. Subsequently, if reservation re- freshes are received for flow i, the network element must use the same slack Si without any further computation. This guarantees consisten- cy in the reservation process. As an example for the use of the slack term, consider the case where the required end-to-end delay, Dreq, is larger than the maximum delay of the fluid flow system. In this, Ctot is the Baker, et. al. Standards Track [Page 5] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 sum of the Backlog terms end to end, and Dtot is the sum of the delay terms end to end. Dreq is obtained by setting R=r in the fluid delay formula, and is given by b/r + Ctot/r + Dtot. In this case the slack term is S = Dreq - (b/r + Ctot/r + Dtot). The slack term may be used by the network ele- ments to adjust their local reservations, so that they can admit flows that would otherwise have been rejected. A service element at an in- termediate network element that can internally differentiate between delay and rate guarantees can now take advantage of this information to lower the amount of resources allocated to this flow. For example, by taking an amount of slack s <= S, an RCSD scheduler [5] can increase the local delay bound, d, assigned to the flow, to d+s. Given an RSpec, (Rin, Sin), it would do so by setting Rout = Rin and Sout = Sin - s. Similarly, a network element using a WFQ scheduler can decrease its local reservation from Rin to Rout by using some of the slack in the RSpec. This can be accomplished by using the transformation rules given in the previous section, that ensure that the reduced reserva- tion level will not increase the overall end- to-end delay." ::= { intSrvGuaranteedIfEntry 3 } intSrvGuaranteedIfStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "'valid' on interfaces that are configured for the Guaranteed Service." ::= { intSrvGuaranteedIfEntry 4 } -- No notifications are currently defined -- conformance information Baker, et. al. Standards Track [Page 6] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 intSrvGuaranteedGroups OBJECT IDENTIFIER ::= { intSrvGuaranteedConformance 1 } intSrvGuaranteedCompliances OBJECT IDENTIFIER ::= { intSrvGuaranteedConformance 2 } -- compliance statements intSrvGuaranteedCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { intSrvGuaranteedIfAttribGroup } ::= { intSrvGuaranteedCompliances 1 } intSrvGuaranteedIfAttribGroup OBJECT-GROUP OBJECTS { intSrvGuaranteedIfBacklog, intSrvGuaranteedIfDelay, intSrvGuaranteedIfSlack, intSrvGuaranteedIfStatus } STATUS current DESCRIPTION "These objects are required for Systems sup- porting the Guaranteed Service of the Integrat- ed Services Architecture." ::= { intSrvGuaranteedGroups 2 } END 4. Security Considerations The use of an SNMP SET results in an RSVP or Integrated Services reservation under rules that are different compared to if the reservation was negotiated using RSVP. However, no other security considerations exist other than those imposed by SNMP itself. Baker, et. al. Standards Track [Page 7] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 5. Authors' Addresses Fred Baker Postal: Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: +1 805 681 0115 EMail: fred@cisco.com John Krawczyk Postal: ArrowPoint Communications 235 Littleton Road Westford, Massachusetts 01886 Phone: +1 508 692 5875 EMail: jjk@tiac.net Arun Sastry Postal: Cisco Systems 210 W. Tasman Drive San Jose, California 95314 Phone: +1 408 526 7685 EMail: arun@cisco.com 6. Acknowledgements This document was produced by the Integrated Services Working Group. 7. References [1] Rose, M., Editor, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, May 1990. [2] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [3] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). Baker, et. al. Standards Track [Page 8] RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997 Baker, et. al. Standards Track [Page 9] snmp-mibs-downloader-1.1/mibrfcs/rfc2232.txt0000644000000000000000000011210311402176071015550 0ustar Network Working Group B. Clouston, Editor Request for Comments: 2232 Cisco Systems Category: Standards Track B. Moore, Editor IBM Corporation November 1997 Definitions of Managed Objects for DLUR using SMIv2 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. Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. Table of Contents 1. Status of this Memo .................................... 1 2. Introduction ........................................... 1 3. The SNMP Network Management Framework .................. 2 4. Overview ............................................... 2 4.1 DLUR MIB structure .................................... 3 5. Definitions ............................................ 5 6. Acknowledgments ........................................ 18 7. References ............................................. 19 8. Security Considerations ................................ 19 9. Authors' Addresses ..................................... 20 10. Full Copyright Statement ................................ 21 2. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. Clouston & Moore Standards Track [Page 1] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 3. The SNMP Network Management Framework The SNMP Network Management Framework consists of several components. For the purpose of this specification, the applicable components of the Framework are the SMI and related documents [1, 2, 3], which define the mechanisms used for describing and naming objects for the purpose of management. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 4. Overview This document identifies objects for monitoring the configuration and active characteristics of devices with DLUR capabilities. Dependent LU requester/server (DLUR/S) is an extension to the Advanced Peer- to-Peer Networking (APPN) architecture that provides dependent LU services in APPN networks. See the SNANAU APPN MIB [4] for management of APPN networks. The base APPN architecture only provided for transport of data between independent logical units (LUs). However, customers have an enormous investment in applications based on dependent LU types. DLUR/S provides for support of dependent LU sessions in an APPN network. A dependent LU server (DLUS) is an APPN node that provides System Services Control Point (SSCP) services over an APPN network to remote secondary dependent LUs by using SSCP-PU (physical unit) and SSCP-LU sessions whose flows are encapsulated on LU 6.2 session flows between the DLUS node and the appropriate dependent LU requester (DLUR) node. The secondary dependent LUs may be local to the DLUR node, or in adjacent type 2.0 or 2.1 nodes. The LU 6.2 control sessions between a DLUS node and a DLUR node are referred to as a CPSVRMGR pipe. CPSVRMGR refers to the mode used for the sessions. In this document, we describe DLUR managed objects. The DLUR terms and overall architecture are described in [5]. Highlights of the management functions supported by the DLUR MIB module include the following: Clouston & Moore Standards Track [Page 2] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 o Identifying the node's DLUR capabilities o Displaying the physical units (PUs) this node is supporting o Identification of Dependent LU Servers o Displaying the state of control sessions to Dependent LU Servers. This MIB module does not support: o Management of dependent LU servers o Configuration of DLUR nodes. o Changing the state of control session to the DLUS o Displaying the dependent LUs this node is supporting o Traps. The APPN MIB contains a trap for Alert conditions that may affect DLUR resources. The value for the affectedObject object contained in the alertTrap is determined by the implementation. It may contain a VariablePointer from the DLUR MIB. The APPN/DLUR Alerts are defined in [6]. 4.1. DLUR MIB Structure Although DLUR is an extension to APPN, the DLUR MIB relies very little upon the APPN MIB. The dlurNodeCpName object in this MIB has the same value as the appnNodeCpName object in the APPN MIB. If the dlurPuLsName object in the MIB has the same value as the appnLsName object in the APPN MIB, then the two objects are referring to the same link station. The DLUR MIB module contains the following collections of objects: o dlurNodeInfo--objects representing the capabilities and architecture options supported by the DLUR implementation, as well as default primary and backup DLUSs. o dlurPuInfo--objects describing the PUs that this APPN node is supporting with DLUR. o dlurDlusInfo--objects describing the control sessions with DLUSs. These are described below in more detail. Clouston & Moore Standards Track [Page 3] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 4.1.1. dlurNodeInfo group The dlurNodeInfo group consists of the following objects and table: 1) dlurNodeCapabilities group These objects represent the capabilities and options of the DLUR implementation, such as the release level of the implementation 2) dlurDefaultDefBackupDlusTable This table identifies the list of defined backup DLUSs for all PUs served by this DLUR, if there is no specific DLUS backup list for the PU. The list is in descending order of preference as a backup DLUS. 4.1.2. dlurPuInfo group The dlurPuInfo group consists of the following tables: 1) dlurPuTable This table has an entry for each PU this node is supporting via DLUR, including the locally known name, the SSCP supplied name (if known), and the PU status. 2) dlurPuDefBackupDlusTable This table contains the backup DLUS list defined on a PU basis. The table has an entry for each specifically defined backup DLUS on each PU. The first index to the entry is the PU name, which organizes the table by PU name. The second index is a ranking which further sorts the table in descending order of preference as a backup DLUS for the PU. If a PU name is not found in this table, the dlurDefaultDefBackupDlusNameTable is used as a backup list for that PU. 4.1.3. dlurDlusInfo group This group consists of the following table: 1) dlurDlusTable This table contains information about the control sessions (CPSVRMGR pipes) with the DLUS, including the control point (CP) name of the DLUS and the status of the control session. Clouston & Moore Standards Track [Page 4] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 5. Definitions APPN-DLUR-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString, TruthValue FROM SNMPv2-TC OBJECT-TYPE, MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF snanauMIB FROM SNA-NAU-MIB SnaControlPointName FROM APPN-MIB; dlurMIB MODULE-IDENTITY LAST-UPDATED "9705101500Z" ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN/HPR MIBs SIG" CONTACT-INFO " Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Tel: 1 919 472 2333 E-mail: clouston@cisco.com Bob Moore IBM Corporation 800 Park Offices Drive RHJA/664 P.O. Box 12195 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@ralvm6.vnet.ibm.com " DESCRIPTION "This is the MIB module for objects used to manage network devices with DLUR capabilities. This MIB contains information that is useful for managing an APPN product that implements a DLUR (Dependent Logical Unit Clouston & Moore Standards Track [Page 5] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 Requester). The DLUR product has a client/server relationship with an APPN product that implements a DLUS (Dependent Logical Unit Server)." ::= { snanauMIB 5 } -- snanauMIB ::= { mib-2 34 } -- ********************************************************************* -- Textual Convention -- ********************************************************************* -- SnaControlPointName is imported from the APPN MIB -- ********************************************************************* dlurObjects OBJECT IDENTIFIER ::= { dlurMIB 1 } -- ********************************************************************* dlurNodeInfo OBJECT IDENTIFIER ::= { dlurObjects 1 } -- ********************************************************************* -- DLUR Capabilities of the node -- -- This group represents the capabilities and options of the DLUR -- implementation. -- ********************************************************************* dlurNodeCapabilities OBJECT IDENTIFIER ::= { dlurNodeInfo 1 } dlurNodeCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned network name for the APPN node where this DLUR implementation resides. If this object has the same value as the appnNodeCpName object in the APPN MIB, then the two objects are referring to the same APPN node." ::= { dlurNodeCapabilities 1 } dlurReleaseLevel OBJECT-TYPE SYNTAX DisplayString (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "The DLUR release level of this implementation. This is the value that is encoded in the DLUR/DLUS Capabilites (CV 51). To insure consistent display, this one-byte value is encoded here as two displayable characters that are equivalent to a hexadecimal display. For example, if the one-byte value as Clouston & Moore Standards Track [Page 6] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 encoded in CV51 is X'01', this object will contain the displayable string '01'." ::= { dlurNodeCapabilities 2 } dlurAnsSupport OBJECT-TYPE SYNTAX INTEGER { continueOrStop(1), stopOnly(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Automatic Network Shutdown (ANS) capability of this node. - 'continueOrStop' indicates that the DLUR implementation supports either ANS value (continue or stop) as specified by the DLUS on ACTPU for each PU. - 'stopOnly' indicates that the DLUR implementation only supports the ANS value of stop. ANS = continue means that the DLUR node will keep LU-LU sessions active even if SSCP-PU and SSCP-LU control sessions are interrupted. ANS = stop means that LU-LU sessions will be interrupted when the SSCP-PU and SSCP-LU sessions are interrupted." ::= { dlurNodeCapabilities 3 } dlurMultiSubnetSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether this DLUR implementation can support CPSVRMGR sessions that cross NetId boundaries." ::= { dlurNodeCapabilities 4 } dlurDefaultDefPrimDlusName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA name of the defined default primary DLUS for all of the PUs served by this DLUR. This can be overridden for a Clouston & Moore Standards Track [Page 7] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 particular PU by a defined primary DLUS for that PU, represented by the dlurPuDefPrimDlusName object." ::= { dlurNodeCapabilities 5 } dlurNetworkNameForwardingSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether this DLUR implementation supports forwarding of Network Name control vectors on ACTPUs and ACTLUs to DLUR-served PUs and their associated LUs. This object corresponds to byte 9. bit 3 of cv51." ::= { dlurNodeCapabilities 6 } dlurNondisDlusDlurSessDeactSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether this DLUR implementation supports nondisruptive deactivation of its DLUR-DLUS sessions. Upon receiving from a DLUS an UNBIND for the CPSVRMGR pipe with sense data X'08A0 000B', a DLUR that supports this option immediately begins attempting to activate a CPSVRMGR pipe with a DLUS other than the one that sent the UNBIND. This object corresponds to byte 9. bit 4 of cv51." ::= { dlurNodeCapabilities 7 } -- ********************************************************************* -- DLUR default defined backup DLUS table -- ********************************************************************* dlurDefaultDefBackupDlusTable OBJECT-TYPE SYNTAX SEQUENCE OF DlurDefaultDefBackupDlusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains an ordered list of defined backup DLUSs for all of the PUs served by this DLUR. These can be overridden for a particular PU by a list of defined backup DLUSs for that PU, represented by the dlurPuDefBackupDlusNameTable. Entries in this table are Clouston & Moore Standards Track [Page 8] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 ordered from most preferred default backup DLUS to least preferred." ::= { dlurNodeInfo 2 } dlurDefaultDefBackupDlusEntry OBJECT-TYPE SYNTAX DlurDefaultDefBackupDlusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by an integer-valued index, which orders the entries from most preferred default backup DLUS to least preferred." INDEX { dlurDefaultDefBackupDlusIndex } ::= { dlurDefaultDefBackupDlusTable 1 } DlurDefaultDefBackupDlusEntry ::= SEQUENCE { dlurDefaultDefBackupDlusIndex Unsigned32, dlurDefaultDefBackupDlusName SnaControlPointName } dlurDefaultDefBackupDlusIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for this table. The index values start at 1, which identifies the most preferred default backup DLUS." ::= { dlurDefaultDefBackupDlusEntry 1 } dlurDefaultDefBackupDlusName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Fully qualified name of a default backup DLUS for PUs served by this DLUR." ::= { dlurDefaultDefBackupDlusEntry 2 } -- ********************************************************************* -- PU Information -- -- The following table carries information about the PUs that this APPN -- node is supporting via DLUR. Clouston & Moore Standards Track [Page 9] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 -- ********************************************************************* dlurPuInfo OBJECT IDENTIFIER ::= { dlurObjects 2 } dlurPuTable OBJECT-TYPE SYNTAX SEQUENCE OF DlurPuEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the PUs supported by this DLUR." ::= { dlurPuInfo 1 } dlurPuEntry OBJECT-TYPE SYNTAX DlurPuEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry in a table of PU information, indexed by PU name." INDEX { dlurPuName } ::= { dlurPuTable 1 } DlurPuEntry ::= SEQUENCE { dlurPuName DisplayString, dlurPuSscpSuppliedName DisplayString, dlurPuStatus INTEGER, dlurPuAnsSupport INTEGER, dlurPuLocation INTEGER, dlurPuLsName DisplayString, dlurPuDlusSessnStatus INTEGER, dlurPuActiveDlusName DisplayString, dlurPuDefPrimDlusName DisplayString } dlurPuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally administered name of the PU." ::= { dlurPuEntry 1 } dlurPuSscpSuppliedName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..17)) MAX-ACCESS read-only Clouston & Moore Standards Track [Page 10] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 STATUS current DESCRIPTION "The SNA name of the PU. This value is supplied to a PU by the SSCP that activated it. If a value has not been supplied, a zero-length string is returned." ::= { dlurPuEntry 2 } dlurPuStatus OBJECT-TYPE SYNTAX INTEGER { reset(1), pendReqActpuRsp(2), pendActpu(3), pendActpuRsp(4), active(5), pendLinkact(6), pendDactpuRsp(7), pendInop(8), pendInopActpu(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Status of the DLUR-supported PU. The following values are defined: reset(1) - reset pendReqActpuRsp(2) - pending a response from the DLUS to a Request ACTPU pendActpu(3) - pending an ACTPU from the DLUS pendActpuRsp(4) - pending an ACTPU response from the PU active(5) - active pendLinkact(6) - pending activation of the link to a downstream PU pendDactpuRsp(7) - pending a DACTPU response from the PU pendInop(8) - the CPSVRMGR pipe became inoperative while the DLUR was pending an ACTPU response from the PU pendInopActpu(9) - when the DLUR was in the pendInop state, a CPSVRMGR pipe became active and a new ACTPU was received over it, before a response to the previous ACTPU was received from the PU." ::= { dlurPuEntry 3 } dlurPuAnsSupport OBJECT-TYPE SYNTAX INTEGER { Clouston & Moore Standards Track [Page 11] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 continue(1), stop(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The Automatic Network Shutdown (ANS) support configured for this PU. This value (as configured by the network administrator) is sent by DLUS with ACTPU for each PU. - 'continue' means that the DLUR node will attempt to keep LU-LU sessions active even if SSCP-PU and SSCP-LU control sessions are interrupted. - 'stop' means that LU-LU sessions will be interrupted when the SSCP-PU and SSCP-LU sessions are interrupted." ::= { dlurPuEntry 4 } dlurPuLocation OBJECT-TYPE SYNTAX INTEGER { internal(1), downstream(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Location of the DLUR-support PU: internal(1) - internal to the APPN node itself (no link) downstream(2) - downstream of the APPN node (connected via a link)." ::= { dlurPuEntry 5 } dlurPuLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned name of the link station through which a downstream PU is connected to this DLUR. A zero-length string is returned for internal PUs. If this object has the same value as the appnLsName object in the APPN MIB, then the two are identifying the same link station." ::= { dlurPuEntry 6 } dlurPuDlusSessnStatus OBJECT-TYPE SYNTAX INTEGER { Clouston & Moore Standards Track [Page 12] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 reset(1), pendingActive(2), active(3), pendingInactive(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Status of the control session to the DLUS identified in dlurPuActiveDlusName. This is a combination of the separate states for the contention-winner and contention-loser sessions: reset(1) - none of the cases below pendingActive(2) - either contention-winner session or contention-loser session is pending active active(3) - contention-winner and contention-loser sessions are both active pendingInactive(4) - either contention-winner session or contention-loser session is pending inactive - this test is made AFTER the 'pendingActive' test. The following matrix provides a different representation of how the values of this object are related to the individual states of the contention-winner and contention-loser sessions: Conwinner | pA | pI | A | X = !(pA | pI | A) C ++++++++++++++++++++++++++++++++++ o pA | 2 | 2 | 2 | 2 n ++++++++++++++++++++++++++++++++++ l pI | 2 | 4 | 4 | 4 o ++++++++++++++++++++++++++++++++++ s A | 2 | 4 | 3 | 1 e ++++++++++++++++++++++++++++++++++ r X | 2 | 4 | 1 | 1 ++++++++++++++++++++++++++++++++++ " ::= { dlurPuEntry 7 } dlurPuActiveDlusName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA name of the active DLUS for this PU. If its length is not zero, this name follows the SnaControlPointName textual Clouston & Moore Standards Track [Page 13] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 convention. A zero-length string indicates that the PU does not currently have an active DLUS." ::= { dlurPuEntry 8 } dlurPuDefPrimDlusName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA name of the defined primary DLUS for this PU, if one has been defined. If present, this name follows the SnaControlPointName textual convention. A zero-length string indicates that no primary DLUS has been defined for this PU, in which case the global default represented by the dlurDefaultDefPrimDlusName object is used." ::= { dlurPuEntry 9 } -- ***************************************** -- Defined backup DLUS table for a PU -- ***************************************** dlurPuDefBackupDlusTable OBJECT-TYPE SYNTAX SEQUENCE OF DlurPuDefBackupDlusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains an ordered list of defined backup DLUSs for those PUs served by this DLUR that have their own defined backup DLUSs. PUs that have no entries in this table use the global default backup DLUSs for the DLUR, represented by the dlurDefaultDefBackupDlusNameTable. Entries in this table are ordered from most preferred backup DLUS to least preferred for each PU." ::= { dlurPuInfo 2 } dlurPuDefBackupDlusEntry OBJECT-TYPE SYNTAX DlurPuDefBackupDlusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by PU name and by an integer-valued index, which orders the entries from most preferred backup DLUS for the PU to least preferred." INDEX { dlurPuDefBackupDlusPuName, Clouston & Moore Standards Track [Page 14] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 dlurPuDefBackupDlusIndex } ::= { dlurPuDefBackupDlusTable 1 } DlurPuDefBackupDlusEntry ::= SEQUENCE { dlurPuDefBackupDlusPuName DisplayString, dlurPuDefBackupDlusIndex Unsigned32, dlurPuDefBackupDlusName SnaControlPointName } dlurPuDefBackupDlusPuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally administered name of the PU. If this object has the same value as the dlurPuName object, then the two are identifying the same PU." ::= { dlurPuDefBackupDlusEntry 1 } dlurPuDefBackupDlusIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Secondary index for this table. The index values start at 1, which identifies the most preferred backup DLUS for the PU." ::= { dlurPuDefBackupDlusEntry 2 } dlurPuDefBackupDlusName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Fully qualified name of a backup DLUS for this PU." ::= { dlurPuDefBackupDlusEntry 3 } -- ********************************************************************* -- DLUS Control Sessions (CPSVRMGR Pipes) -- -- This table contains information about DLUS control sessions, also -- known as CPSVRMGR pipes. Although DLUR uses a pair of CPSVRMGR -- sessions for communication, for the purpose of status, information -- about these two sessions is combined to yield a single status for the -- requester/server connection. Clouston & Moore Standards Track [Page 15] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 -- ********************************************************************* dlurDlusInfo OBJECT IDENTIFIER ::= { dlurObjects 3 } dlurDlusTable OBJECT-TYPE SYNTAX SEQUENCE OF DlurDlusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about DLUS control sessions." ::= { dlurDlusInfo 1} dlurDlusEntry OBJECT-TYPE SYNTAX DlurDlusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry is indexed by the name of the DLUS." INDEX { dlurDlusName } ::= { dlurDlusTable 1 } DlurDlusEntry ::= SEQUENCE { dlurDlusName SnaControlPointName, dlurDlusSessnStatus INTEGER } dlurDlusName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNA name of a DLUS with which this DLUR currently has a CPSVRMGR pipe established." ::= { dlurDlusEntry 1 } dlurDlusSessnStatus OBJECT-TYPE SYNTAX INTEGER { reset(1), pendingActive(2), active(3), pendingInactive(4) } MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 16] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 DESCRIPTION "Status of the CPSVRMGR pipe between the DLUR and this DLUS. This is a combination of the separate states for the contention-winner and contention-loser sessions: reset(1) - none of the cases below pendingActive(2) - either contention-winner session or contention-loser session is pending active active(3) - contention-winner and contention-loser sessions are both active pendingInactive(4) - either contention-winner session or contention-loser session is pending inactive - this test is made AFTER the 'pendingActive' test. The following matrix provides a different representation of how the values of this object are related to the individual states of the contention-winner and contention-loser sessions: Conwinner | pA | pI | A | X = !(pA | pI | A) C ++++++++++++++++++++++++++++++++++ o pA | 2 | 2 | 2 | 2 n ++++++++++++++++++++++++++++++++++ l pI | 2 | 4 | 4 | 4 o ++++++++++++++++++++++++++++++++++ s A | 2 | 4 | 3 | 1 e ++++++++++++++++++++++++++++++++++ r X | 2 | 4 | 1 | 1 ++++++++++++++++++++++++++++++++++ " ::= { dlurDlusEntry 2 } -- *************************************************************** -- Conformance information -- *************************************************************** dlurConformance OBJECT IDENTIFIER ::= { dlurMIB 2 } dlurCompliances OBJECT IDENTIFIER ::= { dlurConformance 1 } dlurGroups OBJECT IDENTIFIER ::= { dlurConformance 2 } -- Compliance statements dlurCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 17] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 "The compliance statement for the SNMPv2 entities which implement the DLUR MIB." MODULE -- this module -- Unconditionally mandatory groups MANDATORY-GROUPS { dlurConfGroup } ::= { dlurCompliances 1 } -- Units of conformance dlurConfGroup OBJECT-GROUP OBJECTS { dlurNodeCpName, dlurReleaseLevel, dlurAnsSupport, dlurMultiSubnetSupport, dlurNetworkNameForwardingSupport, dlurNondisDlusDlurSessDeactSup, dlurDefaultDefPrimDlusName, dlurDefaultDefBackupDlusName, dlurPuSscpSuppliedName, dlurPuStatus, dlurPuAnsSupport, dlurPuLocation, dlurPuLsName, dlurPuDlusSessnStatus, dlurPuActiveDlusName, dlurPuDefPrimDlusName, dlurPuDefBackupDlusName, dlurDlusSessnStatus } STATUS current DESCRIPTION "A collection of objects providing information on an implementation of APPN DLUR." ::= { dlurGroups 1 } -- end of conformance statement END 6. Acknowledgments This MIB module is the product of the IETF SNA NAU MIB WG and the AIW APPN/HPR MIBs SIG. Clouston & Moore Standards Track [Page 18] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 7. References [1] 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. [2] 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. [3] 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. [4] Clouston, B., and B. Moore, "Definition of Managed Objects for APPN", RFC 2155, June 1997. [5] IBM, Systems Network Architecture Advanced Peer-to-Peer Networking Dependent LU Requester Architecture Reference, Version 1.2, SV40-1010-01, December 1995. [6] IBM, SNA/MS Formats, GC31-8302-00. 8. Security Considerations In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. None of the read-only objects in the DLUR MIB reports a password, user data, or anything else that is particularly sensitive. Some enterprises view their network configuration itself, as well as information about network usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. There are no read-write objects in the DLUR MIB. Clouston & Moore Standards Track [Page 19] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 9. Authors' Addresses Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Phone: +1 919 472 2333 EMail: clouston@cisco.com Bob Moore IBM Corporation 800 Park Offices Drive CNMA/664 P.O. Box 12195 Research Triangle Park, NC 27709, USA Phone: +1 919 254 4436 EMail: remoore@ralvm6.vnet.ibm.com Clouston & Moore Standards Track [Page 20] RFC 2232 Managed Objects for DLUR using SMIv2 November 1997 10. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Clouston & Moore Standards Track [Page 21] snmp-mibs-downloader-1.1/mibrfcs/rfc2238.txt0000644000000000000000000017773211402176071015601 0ustar Network Working Group B. Clouston, Editor Request for Comments: 2238 Cisco Systems Category: Standards Track B. Moore, Editor IBM Corporation November 1997 Definitions of Managed Objects for HPR using SMIv2 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. Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. Table of Contents 1. Status of this Memo ..................................... 1 2. Introduction ............................................ 1 3. The SNMP Network Management Framework ................... 2 4. Overview ................................................ 2 4.1 HPR MIB structure ...................................... 3 5. Definitions ............................................. 5 6. Acknowledgments ........................................ 33 7. References ............................................. 33 8. Security Considerations ................................ 33 9. Authors' Addresses ..................................... 34 10. Full Copyright Statement ................................ 35 2. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. Clouston & Moore Standards Track [Page 1] RFC 2238 Definitions of Managed Objects for HPR November 1997 3. The SNMP Network Management Framework The SNMP Network Management Framework consists of several components. For the purpose of this specification, the applicable components of the Framework are the SMI and related documents [1, 2, 3], which define the mechanisms used for describing and naming objects for the purpose of management. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 4. Overview This document identifies objects for monitoring the configuration and active characteristics of devices with HPR capabilities. HPR is an enhancement to the Advanced Peer-to-Peer Network (APPN) architecture that provides fast data routing and improved session reliability. APPN is one of the protocols that can use the HPR transport mechanism. See the SNANAU APPN MIB [4] for management of APPN and APPN use of the HPR transport. The HPR terms and overall architecture [5] are available at http://www.networking.ibm.com/app/aiwdoc/aiwsrc.htm. Automatic Network Routing (ANR) is a fast low-level routing technique. Each node assigns a unique (within that node) ANR label for each out-bound link as it is activated. The label size is defined by the ANR node, and nodes only need to know how to interpret their own labels. The ANR string is a group of ANR labels encoded in a header in front of the message being sent. At each hop the node strips off its own ANR label and forwards the message onto the link with that label. The last label in the string is the Network Connection Endpoint (NCE), which identifies the component within the destination node that is to receive the message. Rapid Transport Protocol (RTP) is an end-to-end full duplex transport connection (pipe). It provides for high-speed transport of data using ANR. RTP is connection-oriented, and delivers data in correct order reliably. Error recovery is done efficiently with selective retransmission of data. An RTP path can be switched without disrupting the sessions using it. An RTP path switch may be done automatically if a link in the path fails and another RTP path is available, or on demand to attempt to restore the optimal path. RTP performs flow/congestion control with the Adaptive Rate-Based (ARB) algorithm, described in [5]. ARB is done only at the endpoints of the RTP pipe, so intermediate hops are not involved. Clouston & Moore Standards Track [Page 2] RFC 2238 Definitions of Managed Objects for HPR November 1997 ARB regulates the flow of data over an RTP connection by adaptively changing the sender's rate based on feedback on the receiver's rate. It is designed to prevent congestion rather than react to it. In this document, we describe HPR managed objects. Highlights of the management functions supported by the HPR MIB module include the following: o Identifying network connection endpoints (NCEs). o Identifying how incoming packets are routed based on ANR labels. o Monitoring the RTP connections between nodes. o Ability to trigger an RTP path switch. The MIB only supports a path switch with no specified path. Some implementations may have a product-specific option to specify a new path. The hprOperatorPathSwitchSupport object identifies this support. o Historical information about RTP path switch attempts. This MIB module does not support: o Configuration of HPR nodes. o Protocol-specific uses of HPR (such as APPN). o Traps. The APPN MIB contains a trap for Alert conditions that may affect HPR resources. The value for the affectedObject object contained in the alertTrap is determined by the implementation. It may contain a VariablePointer from the HPR MIB. The APPN/HPR Alerts are defined in [6]. 4.1. HPR MIB Structure Although HPR is an extension to APPN, the HPR MIB relies very little upon the APPN MIB. The appnNodeCounterDisconTime object in the APPN MIB is used to detect discontinuities in HPR MIB counters. The hprNodeCpName object in this MIB has the same value as the appnNodeCpName object in the APPN MIB. The HPR MIB module contains the following collections of objects: o hprGlobal - general HPR objects. o hprAnrRouting - objects related to the ANR routing table. Clouston & Moore Standards Track [Page 3] RFC 2238 Definitions of Managed Objects for HPR November 1997 o hprTransportUser - objects related to users of the HPR transport. o hprRtp - objects related to the HPR Transport Tower. These are described below in more detail. 4.1.1. hprGlobal group The hprGlobal group consists of general objects such as the APPN CP (control point) name of the HPR node and the level of support for operator-requested path switches. 4.1.2. hprAnrRouting group The hprAnrRouting group consists objects to monitor and control the counting of ANR packets received and the following table: The hprAnrRoutingTable correlates incoming ANR labels to the outbound transmission group (TG) or local NCE to which incoming packet will be forwarded. An entry defines the label type as identifying a local NCE or a TG, identifies the NCE or TG, and counts the number of packets received with the entry's ANR label. 4.1.3. hprTransportUser group The hprTransportUser group consists of the following table: The hprNceTable identifies network connection endpoints and their function types. The function type can be any combination of a CP, logical unit (LU), boundary function, and route setup. 4.1.4. hprRtp group The hprRtp group consists of the following objects and tables: 1) hprRtpGlobe These objects contain information about the number of RTP connection setups, and control of RTP counters. 2) hprRtpTable This table contains one entry for each RTP connection. The information includes local and remote NCE IDs and TCIDs (transport connection identifiers), timers, send rates, and statistics. A path switch can be triggered by the hprRptPathSwitchTrigger object if the agent node supports it; however, a new path cannot be specified. Clouston & Moore Standards Track [Page 4] RFC 2238 Definitions of Managed Objects for HPR November 1997 3) hprRtpStatusTable This table contains statistics and historical information for RTP path switches attempts, including old and new ANR strings and Route Selection Control Vectors (RSCVs), why the path switch was initiated, and the result (successful or reason for failure). 5. Definitions HPR-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString, DateAndTime, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC Counter32, Gauge32, Unsigned32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF snanauMIB FROM SNA-NAU-MIB SnaControlPointName FROM APPN-MIB; hprMIB MODULE-IDENTITY LAST-UPDATED "970514000000Z" ORGANIZATION "AIW APPN / HPR MIB SIG" CONTACT-INFO " Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Tel: 1 919 472 2333 E-mail: clouston@cisco.com Bob Moore IBM Corporation 800 Park Offices Drive RHJA/664 P.O. Box 12195 Clouston & Moore Standards Track [Page 5] RFC 2238 Definitions of Managed Objects for HPR November 1997 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@ralvm6.vnet.ibm.com " DESCRIPTION "This is the MIB module for objects used to manage network devices with HPR capabilities." ::= { snanauMIB 6 } -- snanauMIB ::= { mib-2 34 } -- ********************************************************************* -- Textual Conventions -- ********************************************************************* -- SnaControlPointName is imported from the APPN MIB HprNceTypes ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A bit string identifying the set of functions provided by a network connection endpoint (NCE). The following values are defined: bit 0: control point bit 1: logical unit bit 2: boundary function bit 3: route setup " SYNTAX BITS { controlPoint(0), logicalUnit(1), boundaryFunction(2), routeSetup(3) } HprRtpCounter ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object providing statistics for an RTP connection. A Management Station can detect discontinuities in this counter by monitoring the correspondingly indexed hprRtpCounterDisconTime object." SYNTAX Counter32 -- ********************************************************************* hprObjects OBJECT IDENTIFIER ::= { hprMIB 1 } -- ********************************************************************* -- ********************************************************************* Clouston & Moore Standards Track [Page 6] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprGlobal OBJECT IDENTIFIER ::= { hprObjects 1 } -- ********************************************************************* -- The hprGlobal group applies to both intermediate and end nodes. -- ********************************************************************* hprNodeCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned network name for the APPN node where this HPR implementation resides. If this object has the same value as the appnNodeCpName object in the APPN MIB, then the two objects are referring to the same APPN node." ::= { hprGlobal 1 } hprOperatorPathSwitchSupport OBJECT-TYPE SYNTAX INTEGER { notSupported(1), switchTriggerSupported(2), switchToPathSupported(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates an implementation's level of support for an operator-requested path switch. notSupported(1) - the agent does not support operator-requested path switches switchTriggerSupported(2) - the agent supports a 'switch path now' command from an operator, but not a command to switch to a specified path switchToPathSupported(3) - the agent supports both a 'switch path now' command and a command to switch to a specified path. Note that the latter command is not available via this MIB; a system that supports it must do so via other means, such as a local operator interface." ::= { hprGlobal 2 } -- ********************************************************************* Clouston & Moore Standards Track [Page 7] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprAnrRouting OBJECT IDENTIFIER ::= { hprObjects 2 } -- ********************************************************************* hprAnrsAssigned OBJECT-TYPE SYNTAX Counter32 UNITS "ANR labels" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of ANR labels assigned by this node since it was last re-initialized. A Management Station can detect discontinuities in this counter by monitoring the appnNodeCounterDisconTime object in the APPN MIB." ::= { hprAnrRouting 1 } hprAnrCounterState OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used for a network management station to turn on/off the counting of ANR packets in the hprAnrRoutingTable. The initial value of this object is an implementation choice. notActive(1) - the counter hprAnrPacketsReceived returns no meaningful value active(2) - the counter hprAnrPacketsReceived is being incremented and is returning meaningful values" ::= { hprAnrRouting 2 } hprAnrCounterStateTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the hprAnrCounterState object last changed its value. The initial value returned by this object is the time at which the APPN node instrumented with this MIB was last brought up." ::= { hprAnrRouting 3 } Clouston & Moore Standards Track [Page 8] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprAnrRoutingTable OBJECT-TYPE SYNTAX SEQUENCE OF HprAnrRoutingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ANR Routing table provides a means of correlating an incoming ANR label (i.e., one assigned by this node) with the TG over which a packet containing the label will be forwarded. When the ANR label identifies a local NCE, the hprAnrOutTgDest and hprAnrOutTgNum objects have no meaning. The table also contains an object to count the number of packets received with a given ANR label." ::= { hprAnrRouting 4 } hprAnrRoutingEntry OBJECT-TYPE SYNTAX HprAnrRoutingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ANR label is used to index this table." INDEX { hprAnrLabel } ::= { hprAnrRoutingTable 1 } HprAnrRoutingEntry ::= SEQUENCE { hprAnrLabel OCTET STRING, hprAnrType INTEGER, hprAnrOutTgDest DisplayString, hprAnrOutTgNum INTEGER, hprAnrPacketsReceived Counter32, hprAnrCounterDisconTime TimeStamp } hprAnrLabel OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first ANR label in an incoming packet." ::= { hprAnrRoutingEntry 1 } hprAnrType OBJECT-TYPE SYNTAX INTEGER { nce(1), tg(2) Clouston & Moore Standards Track [Page 9] RFC 2238 Definitions of Managed Objects for HPR November 1997 } MAX-ACCESS read-only STATUS current DESCRIPTION "An object indicating whether an ANR label assigned by this node identifies a local NCE or a TG on which outgoing packets are forwarded. nce(1) - the ANR label identifies a local NCE. In this case the hprAnrOutTgDest and hprAnrOutTgNum objects have no meaning. tg(2) - the ANR label identifies a TG." ::= { hprAnrRoutingEntry 2 } hprAnrOutTgDest OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination node for the TG over which packets with this ANR label are forwarded. This is the fully qualified name of an APPN network node or end node, formatted according to the SnaControlPointName textual convention. If the ANR label identifies a local NCE, then this object returns a zero-length string. This object corresponds to the appnLocalTgDest object in the APPN MIB." ::= { hprAnrRoutingEntry 3 } hprAnrOutTgNum OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of the TG over which packets with this ANR label are forwarded. If the ANR label identifies a local NCE, then this object returns the value 0, since 0 is not a valid TG number for a TG that supports HPR. This object corresponds to the appnLocalTgNum object in the APPN MIB." ::= { hprAnrRoutingEntry 4 } hprAnrPacketsReceived OBJECT-TYPE Clouston & Moore Standards Track [Page 10] RFC 2238 Definitions of Managed Objects for HPR November 1997 SYNTAX Counter32 UNITS "ANR packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of packets received with this ANR label as their first label. A Management Station can detect discontinuities in this counter by monitoring the hprAnrCounterDisconTime object in the same row." ::= { hprAnrRoutingEntry 5 } hprAnrCounterDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the hprAnrPacketsReceived counter for this ANR label last experienced a discontinuity. This will be the more recent of two times: the time at which the ANR label was associated with either an outgoing TG or a local NCE, or the time at which the ANR counters were last turned on or off." ::= { hprAnrRoutingEntry 6 } -- ********************************************************************* hprTransportUser OBJECT IDENTIFIER ::= { hprObjects 3 } -- ********************************************************************* -- Transport Service User (TU) Table: (RTP Connection Users) -- -- There will be several users of the HPR transport and each HPR node -- shall maintain a table of these users. -- ********************************************************************* hprNceTable OBJECT-TYPE SYNTAX SEQUENCE OF HprNceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Network Connection Endpoint (NCE) table." ::= { hprTransportUser 1 } hprNceEntry OBJECT-TYPE SYNTAX HprNceEntry Clouston & Moore Standards Track [Page 11] RFC 2238 Definitions of Managed Objects for HPR November 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The NCE ID is used to index this table." INDEX { hprNceId } ::= { hprNceTable 1 } HprNceEntry ::= SEQUENCE { hprNceId OCTET STRING, hprNceType HprNceTypes, hprNceDefault HprNceTypes, hprNceInstanceId OCTET STRING } hprNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Network Connection Endpoint (NCE) ID. NCEs identify Control Points (Cp), Logical Units (Lu), HPR Boundary Functions (Bf) and Route Setup (Rs) Functions. A value for this object can be retrieved from any of the following objects in the APPN MIB: - appnLsCpCpNceId - appnLsRouteNceId - appnLsBfNceId - appnIsInRtpNceId - appnIsRtpNceId In each case this value identifies a row in this table containing information related to that in the APPN MIB." ::= { hprNceEntry 1 } hprNceType OBJECT-TYPE SYNTAX HprNceTypes MAX-ACCESS read-only STATUS current DESCRIPTION "A bit string identifying the function types provided by this Network Connection Endpoint (NCE)." ::= { hprNceEntry 2 } Clouston & Moore Standards Track [Page 12] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprNceDefault OBJECT-TYPE SYNTAX HprNceTypes MAX-ACCESS read-only STATUS current DESCRIPTION "A bit string identifying the function types for which this Network Connection Endpoint (NCE) is the default NCE. While default NCEs are not explicitly defined in the architecture, some implementations provide them; for such implementations, it is useful to make this information available to a Management Station." ::= { hprNceEntry 3 } hprNceInstanceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) MAX-ACCESS read-only STATUS current DESCRIPTION "The NCE instance identifier (NCEII) identifying the current instance of this NCE. An NCEII is used to denote different instances (IPLs) of an NCE component. Each time an NCE is activated (IPL'd), it acquires a different, unique NCEII." ::= { hprNceEntry 4 } -- ********************************************************************* hprRtp OBJECT IDENTIFIER ::= { hprObjects 4 } -- ********************************************************************* -- ********************************************************************* -- -- The RTP group is implemented by all managed nodes supporting the -- HPR Transport Tower. The group contains several scalars (simple -- objects) and a table. -- ********************************************************************* -- ********************************************************************* hprRtpGlobe OBJECT IDENTIFIER ::= { hprRtp 1} -- ********************************************************************* hprRtpGlobeConnSetups OBJECT-TYPE SYNTAX Counter32 UNITS "RTP connection setups" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of RTP connection setups in which this node has participated, as either sender or receiver, since it was last re-initialized. Retries of a setup attempt do not cause the Clouston & Moore Standards Track [Page 13] RFC 2238 Definitions of Managed Objects for HPR November 1997 counter to be incremented. A Management Station can detect discontinuities in this counter by monitoring the appnNodeCounterDisconTime object in the APPN MIB." ::= { hprRtpGlobe 1 } hprRtpGlobeCtrState OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows a network management station to turn the counters in the hprRtpTable on and off. The initial value of this object is an implementation choice. notActive(1) - the counters in the hprRtpTable are returning no meaningful values active(2) - the counters in the hprRtpTable are being incremented and are returning meaningful values" ::= { hprRtpGlobe 2 } hprRtpGlobeCtrStateTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the value of the hprRtpGlobeCtrState object last changed. The initial value returned by this object is the time at which the APPN node instrumented with this MIB was last brought up." ::= { hprRtpGlobe 3 } -- ********************************************************************* -- The RTP Connection Table -- There may be many RTP connections on a node supporting the functions -- specified in the RTP option set. Each node implementing this option -- set shall maintain a table of these RTP connections. -- ********************************************************************* hprRtpTable OBJECT-TYPE Clouston & Moore Standards Track [Page 14] RFC 2238 Definitions of Managed Objects for HPR November 1997 SYNTAX SEQUENCE OF HprRtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RTP Connection table" ::= { hprRtp 2 } hprRtpEntry OBJECT-TYPE SYNTAX HprRtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local NCE ID and local TCID are used to index this table." INDEX { hprRtpLocNceId, hprRtpLocTcid } ::= { hprRtpTable 1 } HprRtpEntry ::= SEQUENCE { hprRtpLocNceId OCTET STRING, -- local nce id hprRtpLocTcid OCTET STRING, -- local tcid hprRtpRemCpName SnaControlPointName,-- remote cp name hprRtpRemNceId OCTET STRING, -- remote nce id hprRtpRemTcid OCTET STRING, -- remote tcid hprRtpPathSwitchTrigger INTEGER, -- trigger (read-write) hprRtpRscv OCTET STRING, -- rscv hprRtpTopic DisplayString, -- topic (cos) hprRtpState INTEGER, -- state hprRtpUpTime TimeTicks, -- up time hprRtpLivenessTimer Unsigned32, -- liveness timer hprRtpShortReqTimer Unsigned32, -- short request timer hprRtpPathSwTimer Unsigned32, -- path switch timer hprRtpLivenessTimeouts HprRtpCounter, -- liveness timeouts hprRtpShortReqTimeouts HprRtpCounter, -- short req timeouts hprRtpMaxSendRate Gauge32, -- maximum send rate hprRtpMinSendRate Gauge32, -- minimum send rate hprRtpCurSendRate Gauge32, -- current send rate hprRtpSmRdTripDelay Gauge32, -- smooth rnd trip delay hprRtpSendPackets HprRtpCounter, -- packets sent Clouston & Moore Standards Track [Page 15] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprRtpRecvPackets HprRtpCounter, -- packets received hprRtpSendBytes HprRtpCounter, -- bytes sent hprRtpRecvBytes HprRtpCounter, -- bytes received hprRtpRetrPackets HprRtpCounter, -- pkts re-xmitted hprRtpPacketsDiscarded HprRtpCounter, -- pkts discarded hprRtpDetectGaps HprRtpCounter, -- gaps detected hprRtpRateReqSends HprRtpCounter, -- rate req send hprRtpOkErrPathSws HprRtpCounter, -- ok err path sws hprRtpBadErrPathSws HprRtpCounter, -- bad err path sws hprRtpOkOpPathSws HprRtpCounter, -- ok op path sws hprRtpBadOpPathSws HprRtpCounter, -- bad op path sws hprRtpCounterDisconTime TimeStamp -- discontinuity ind } hprRtpLocNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local Network Connection Endpoint (NCE) ID of this RTP connection. NCEs identify CPs, LUs, Boundary Functions (BFs), and Route Setup (RS) components. A value for this object can be retrieved from any of the following objects in the APPN MIB: - appnLsCpCpNceId - appnLsRouteNceId - appnLsBfNceId - appnIsInRtpNceId - appnIsRtpNceId In each case this value identifies a row in this table containing information related to that in the APPN MIB." ::= { hprRtpEntry 1 } hprRtpLocTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local TCID of this RTP connection. A value for this object can be retrieved from either the appnIsInRtpTcid object or the appnIsRtpTcid object the APPN MIB; in each case this value identifies a row in this table containing information Clouston & Moore Standards Track [Page 16] RFC 2238 Definitions of Managed Objects for HPR November 1997 related to that in the APPN MIB." ::= { hprRtpEntry 2 } hprRtpRemCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned network name for the remote node of this RTP connection." ::= { hprRtpEntry 3 } hprRtpRemNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote Network Connection Endpoint (NCE) of this RTP connection. NCEs identify CPs, LUs, Boundary Functions (BFs), and Route Setup (RS) components." ::= { hprRtpEntry 4 } hprRtpRemTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote TCID of this RTP connection." ::= { hprRtpEntry 5 } hprRtpPathSwitchTrigger OBJECT-TYPE SYNTAX INTEGER { ready(1), switchPathNow(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Object by which a Management Station can trigger an operator- requested path switch, by setting the value to switchPathNow(2). Setting this object to switchPathNow(2) triggers a path switch even if its previous value was already switchPathNow(2). Clouston & Moore Standards Track [Page 17] RFC 2238 Definitions of Managed Objects for HPR November 1997 The value ready(1) is returned on GET operations until a SET has been processed; after that the value received on the most recent SET is returned. This MIB module provides no support for an operator-requested switch to a specified path." ::= { hprRtpEntry 6 } hprRtpRscv OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The forward Route Selection Control Vector for this RTP connection. The format of this vector is described in SNA Formats. The value returned in this object during a path switch is implementation-dependent: it may be the old path, the new path, a zero-length string, or some other valid RSCV string." ::= { hprRtpEntry 7 } hprRtpTopic OBJECT-TYPE SYNTAX DisplayString (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The topic for this RTP connection. This is used to indicate the Class of Service." ::= { hprRtpEntry 8 } hprRtpState OBJECT-TYPE SYNTAX INTEGER { rtpListening(1), rtpCalling(2), rtpConnected(3), rtpPathSwitching(4), rtpDisconnecting(5), other(99) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the RTP connection, from the perspective of the local RTP protocol machine: Clouston & Moore Standards Track [Page 18] RFC 2238 Definitions of Managed Objects for HPR November 1997 rtpListening - connection open; waiting for other end to call in rtpCalling - connection opened, attempting to call out, have not yet received any data from other end rtpConnected - connection is active; responded to a call-in or received other end's TCID from a call-out attempt rtpPathSwitching - the path switch timer is running; attempting to find a new path for this connection. rtpDisconnecting - no sessions are using this connection; in process of bringing it down other - the connection is not in any of the states listed above." ::= { hprRtpEntry 9 } hprRtpUpTime OBJECT-TYPE SYNTAX TimeTicks UNITS "1/100ths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time the RTP connection has been up, measured in 1/100ths of a second." ::= { hprRtpEntry 10 } hprRtpLivenessTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "1/100ths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the liveness (ALIVE) timer of this RTP connection, in units of 1/100th of a second. When this timer expires and no packet has arrived from the partner since it was last set, packets with Status Request indicators will be sent to see if the RTP connection is still alive." ::= { hprRtpEntry 11 } hprRtpShortReqTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "1/100ths of a second" MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 19] RFC 2238 Definitions of Managed Objects for HPR November 1997 DESCRIPTION "The value of the RTP SHORT_REQ timer, in units of 1/100 of a second. This timer represents the maximum time that a sender waits for a reply from a receiver." ::= { hprRtpEntry 12 } hprRtpPathSwTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "1/100ths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time that RTP should attempt a path switch for a connection, in units of 1/100th of a second." ::= { hprRtpEntry 13 } hprRtpLivenessTimeouts OBJECT-TYPE SYNTAX HprRtpCounter UNITS "liveness timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of liveness timeouts for this RTP connection." ::= { hprRtpEntry 14 } hprRtpShortReqTimeouts OBJECT-TYPE SYNTAX HprRtpCounter UNITS "short request timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of short request timeouts for this RTP connection." ::= { hprRtpEntry 15 } hprRtpMaxSendRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bytes per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The high-water mark for this RTP connection's send rate, in units of bytes per second. This is the high-water mark for the entire life of the connection, not just the high-water mark for the connection's current path. Clouston & Moore Standards Track [Page 20] RFC 2238 Definitions of Managed Objects for HPR November 1997 For more details on this and other parameters related to HPR, see the High Performance Routing Architecture Reference." ::= { hprRtpEntry 16 } hprRtpMinSendRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bytes per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The low-water mark for this RTP connection's send rate, in units of bytes per second. This is the low-water mark for the entire life of the connection, not just the low-water mark for the connection's current path. For more details on this and other parameters related to HPR, see the High Performance Routing Architecture Reference." ::= { hprRtpEntry 17 } hprRtpCurSendRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bytes per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The current send rate for this RTP connection, in units of bytes per second. For more details on this and other parameters related to HPR, see the High Performance Routing Architecture Reference." ::= { hprRtpEntry 18 } hprRtpSmRdTripDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "1/1000ths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The smoothed round trip delay for this RTP connection, in units of 1/1000th of a second (ms). For more details on this and other parameters related to HPR, see the High Performance Routing Architecture Reference." ::= { hprRtpEntry 19 } Clouston & Moore Standards Track [Page 21] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprRtpSendPackets OBJECT-TYPE SYNTAX HprRtpCounter UNITS "RTP packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of packets successfully sent on this RTP connection." ::= { hprRtpEntry 20 } hprRtpRecvPackets OBJECT-TYPE SYNTAX HprRtpCounter UNITS "RTP packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of packets received on this RTP connection. The counter is incremented only once if duplicate copies of a packet are received." ::= { hprRtpEntry 21 } hprRtpSendBytes OBJECT-TYPE SYNTAX HprRtpCounter UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of bytes sent on this RTP connection. Both RTP Transport Header (THDR) bytes and data bytes are included in this count." ::= { hprRtpEntry 22 } hprRtpRecvBytes OBJECT-TYPE SYNTAX HprRtpCounter UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of bytes received on this RTP connection. Both RTP Transport Header (THDR) bytes and data bytes are included in this count." ::= { hprRtpEntry 23 } hprRtpRetrPackets OBJECT-TYPE Clouston & Moore Standards Track [Page 22] RFC 2238 Definitions of Managed Objects for HPR November 1997 SYNTAX HprRtpCounter UNITS "RTP packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of packets retransmitted on this RTP connection." ::= { hprRtpEntry 24 } hprRtpPacketsDiscarded OBJECT-TYPE SYNTAX HprRtpCounter UNITS "RTP packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of packets received on this RTP connection and then discarded. A packet may be discarded because it is determined to be a duplicate, or for other reasons." ::= { hprRtpEntry 25 } hprRtpDetectGaps OBJECT-TYPE SYNTAX HprRtpCounter UNITS "gaps" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of gaps detected on this RTP connection." ::= { hprRtpEntry 26 } hprRtpRateReqSends OBJECT-TYPE SYNTAX HprRtpCounter UNITS "rate requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Rate Requests sent on this RTP connection." ::= { hprRtpEntry 27 } hprRtpOkErrPathSws OBJECT-TYPE SYNTAX HprRtpCounter UNITS "path switch attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of successful path switch attempts for this RTP Clouston & Moore Standards Track [Page 23] RFC 2238 Definitions of Managed Objects for HPR November 1997 connection due to errors." ::= { hprRtpEntry 28 } hprRtpBadErrPathSws OBJECT-TYPE SYNTAX HprRtpCounter UNITS "path switch attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of unsuccessful path switches for this RTP connection due to errors." ::= { hprRtpEntry 29 } hprRtpOkOpPathSws OBJECT-TYPE SYNTAX HprRtpCounter UNITS "path switches" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of successful path switches for this RTP connection due to operator requests." ::= { hprRtpEntry 30 } hprRtpBadOpPathSws OBJECT-TYPE SYNTAX HprRtpCounter UNITS "path switches" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of unsuccessful path switches for this RTP connection due to operator requests. This counter is not incremented by an implementation that does not support operator-requested path switches, even if a Management Station requests such a path switch by setting the hprRtpPathSwitchTrigger object." ::= { hprRtpEntry 31 } hprRtpCounterDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for this RTP connection last experienced a discontinuity. This will be Clouston & Moore Standards Track [Page 24] RFC 2238 Definitions of Managed Objects for HPR November 1997 the more recent of two times: the time at which the connection was established or the time at which the HPR counters were last turned on or off." ::= { hprRtpEntry 32 } -- ********************************************************************* -- The RTP Connection Status Table -- This table contains statistics and historical information related to -- both successful and unsuccessful RTP path switches. This -- information can be important for both trend analysis and problem -- determination. -- -- Note the terminology here: when RTP is triggered to find a new path -- for a connection, this initiates a 'path switch,' which will end up -- being either successful or unsuccessful. During this path switch, -- RTP will make one or more 'path switch attempts,' which are attempts -- to find a new path for the connection and switch the connection to -- it. This 'new' path may be the same path that the connection was -- using before the path switch. -- -- It is an implementation option how many entries to keep in this -- table, and how long to retain any individual entry. -- ********************************************************************* hprRtpStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF HprRtpStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "RTP Connection Status Table: This table contains historical information on RTP connections. An entry is created in this table when a path switch is completed, either successfully or unsuccessfully." ::= { hprRtp 3 } hprRtpStatusEntry OBJECT-TYPE SYNTAX HprRtpStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by local NCE ID, local TCID, and an integer hprRtpStatusIndex. Thus the primary grouping of table rows is by RTP connection, with the multiple entries for a given RTP connection ordered by time." INDEX { hprRtpStatusLocNceId, Clouston & Moore Standards Track [Page 25] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprRtpStatusLocTcid, hprRtpStatusIndex } ::= { hprRtpStatusTable 1 } HprRtpStatusEntry ::= SEQUENCE { hprRtpStatusLocNceId OCTET STRING, -- local nce id hprRtpStatusLocTcid OCTET STRING, -- local tcid hprRtpStatusIndex Unsigned32, -- index hprRtpStatusStartTime DateAndTime, -- time stamp hprRtpStatusEndTime DateAndTime, -- time stamp hprRtpStatusRemCpName SnaControlPointName,-- remote cp name hprRtpStatusRemNceId OCTET STRING, -- remote nce id hprRtpStatusRemTcid OCTET STRING, -- remote tcid hprRtpStatusNewRscv OCTET STRING, -- new rscv hprRtpStatusOldRscv OCTET STRING, -- old rscv hprRtpStatusCause INTEGER, -- cause hprRtpStatusLastAttemptResult INTEGER -- result of last } hprRtpStatusLocNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local Network Connection Endpoint (NCE) of this RTP connection. NCEs identify CPs, LUs, Boundary Functions (BFs), and Route Setup (RS) components." ::= { hprRtpStatusEntry 1 } hprRtpStatusLocTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local TCID of this RTP connection." ::= { hprRtpStatusEntry 2 } hprRtpStatusIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table index. This value begins at one and is incremented when a new entry is added to the table. It is an implementation choice whether to run a single counter for Clouston & Moore Standards Track [Page 26] RFC 2238 Definitions of Managed Objects for HPR November 1997 all entries in the table, or to run a separate counter for the entries for each RTP connection. In the unlikely event of a wrap, it is assumed that Management Stations will have the ability to order table entries correctly." ::= { hprRtpStatusEntry 3 } hprRtpStatusStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the path switch began." ::= { hprRtpStatusEntry 4 } hprRtpStatusEndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the path switch was ended, either successfully or unsuccessfully." ::= { hprRtpStatusEntry 5 } hprRtpStatusRemCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned network name for the remote node of this RTP connection." ::= { hprRtpStatusEntry 6 } hprRtpStatusRemNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote Network Connection Endpoint (NCE) of this RTP connection. NCEs identify CPs, LUs, Boundary Functions (BFs), and Route Setup (RS) components." ::= { hprRtpStatusEntry 7 } hprRtpStatusRemTcid OBJECT-TYPE Clouston & Moore Standards Track [Page 27] RFC 2238 Definitions of Managed Objects for HPR November 1997 SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote TCID of this RTP connection." ::= { hprRtpStatusEntry 8 } hprRtpStatusNewRscv OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The new Route Selection Control Vector for this RTP connection. A zero-length string indicates that no value is available, perhaps because the implementation does not save RSCVs." ::= { hprRtpStatusEntry 9 } hprRtpStatusOldRscv OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The old Route Selection Control Vector for this RTP connection. A zero-length string indicates that no value is available, perhaps because the implementation does not save RSCVs." ::= { hprRtpStatusEntry 10 } hprRtpStatusCause OBJECT-TYPE SYNTAX INTEGER { other(1), rtpConnFail(2), locLinkFail(3), remLinkFail(4), operRequest(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The reason for the path switch: other(1) - Reason other than those listed below, rtpConnFail(2) - RTP connection failure detected, locLinkFail(3) - Local link failure, Clouston & Moore Standards Track [Page 28] RFC 2238 Definitions of Managed Objects for HPR November 1997 remLinkFail(4) - Remote link failure (learned from TDUs), operRequest(5) - Operator requested path switch. " ::= { hprRtpStatusEntry 11 } hprRtpStatusLastAttemptResult OBJECT-TYPE SYNTAX INTEGER { successful(1), initiatorMoving(2), directorySearchFailed(3), rscvCalculationFailed(4), negativeRouteSetupReply(5), backoutRouteSetupReply(6), timeoutDuringFirstAttempt(7), otherUnsuccessful(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The result of the last completed path switch attempt. If the path switch is aborted in the middle of a path switch attempt because the path switch timer expires, the result of the previous path switch attempt is reported. The values are defined as follows: successful(1) - The final path switch attempt was successful. initiatorMoving(2) - The final path switch attempt failed because the initiator is mobile, and there was no active link out of this node. directorySearchFailed(3) - The final path switch attempt failed because a directory search for the destination node's CP name failed. rscvCalculationFailed(4) - The final path switch attempt failed because an RSCV to the node containing the remote RTP endpoint could not be calculated. negativeRouteSetupReply(5) - The final path switch attempt failed because route setup failed for the new path. backoutRouteSetupReply(6) - The final path switch attempt failed because the Clouston & Moore Standards Track [Page 29] RFC 2238 Definitions of Managed Objects for HPR November 1997 remote RTP endpoint refused to continue the RTP connection. timeoutDuringFirstAttempt(7) - The path switch timer expired during the first path switch attempt. otherUnsuccessful(8) - The final path switch attempt failed for a reason other than those listed above." ::= { hprRtpStatusEntry 12 } -- *************************************************************** -- Conformance information -- *************************************************************** hprConformance OBJECT IDENTIFIER ::= { hprMIB 2 } hprCompliances OBJECT IDENTIFIER ::= { hprConformance 1 } hprGroups OBJECT IDENTIFIER ::= { hprConformance 2 } -- Compliance statements hprCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SNMPv2 entities that implement the HPR MIB." MODULE -- this module -- Unconditionally mandatory groups MANDATORY-GROUPS { hprGlobalConfGroup, hprAnrRoutingConfGroup, hprTransportUserConfGroup } -- Conditionally mandatory groups GROUP hprRtpConfGroup DESCRIPTION "The hprRtpConfGroup is mandatory for HPR implementations supporting the HPR transport tower." ::= { hprCompliances 1 } Clouston & Moore Standards Track [Page 30] RFC 2238 Definitions of Managed Objects for HPR November 1997 -- Units of conformance hprGlobalConfGroup OBJECT-GROUP OBJECTS { hprNodeCpName, hprOperatorPathSwitchSupport } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of HPR general information and capabilities." ::= { hprGroups 1 } hprAnrRoutingConfGroup OBJECT-GROUP OBJECTS { hprAnrsAssigned, hprAnrCounterState, hprAnrCounterStateTime, hprAnrType, hprAnrOutTgDest, hprAnrOutTgNum, hprAnrPacketsReceived, hprAnrCounterDisconTime } STATUS current DESCRIPTION "A collection of objects providing instrumentation for the node's ANR routing." ::= { hprGroups 2 } hprTransportUserConfGroup OBJECT-GROUP OBJECTS { hprNceType, hprNceDefault, hprNceInstanceId } STATUS current DESCRIPTION "A collection of objects providing information on the users of the HPR transport known to the node." ::= { hprGroups 3 } hprRtpConfGroup OBJECT-GROUP OBJECTS { hprRtpGlobeConnSetups, hprRtpGlobeCtrState, Clouston & Moore Standards Track [Page 31] RFC 2238 Definitions of Managed Objects for HPR November 1997 hprRtpGlobeCtrStateTime, hprRtpRemCpName, hprRtpRemNceId, hprRtpRemTcid, hprRtpPathSwitchTrigger, hprRtpRscv, hprRtpTopic, hprRtpState, hprRtpUpTime, hprRtpLivenessTimer, hprRtpShortReqTimer, hprRtpPathSwTimer, hprRtpLivenessTimeouts, hprRtpShortReqTimeouts, hprRtpMaxSendRate, hprRtpMinSendRate, hprRtpCurSendRate, hprRtpSmRdTripDelay, hprRtpSendPackets, hprRtpRecvPackets, hprRtpSendBytes, hprRtpRecvBytes, hprRtpRetrPackets, hprRtpPacketsDiscarded, hprRtpDetectGaps, hprRtpRateReqSends, hprRtpOkErrPathSws, hprRtpBadErrPathSws, hprRtpOkOpPathSws, hprRtpBadOpPathSws, hprRtpCounterDisconTime, hprRtpStatusStartTime, hprRtpStatusEndTime, hprRtpStatusRemNceId, hprRtpStatusRemTcid, hprRtpStatusRemCpName, hprRtpStatusNewRscv, hprRtpStatusOldRscv, hprRtpStatusCause, hprRtpStatusLastAttemptResult } Clouston & Moore Standards Track [Page 32] RFC 2238 Definitions of Managed Objects for HPR November 1997 STATUS current DESCRIPTION "A collection of objects providing the instrumentation for RTP connection end points." ::= { hprGroups 4 } -- end of conformance statement END 6. Acknowledgments This MIB module is the product of the IETF SNA NAU MIB WG and the AIW APPN/HPR MIBs SIG. Thanks to Ray Bird, IBM Corporation; Jim Cobban, Nortel; and Laura Petrie, IBM Corporation, for their contributions and review. 7. References [1] 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. [2] 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. [3] 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. [4] Clouston, B., and B. Moore, "Definition of Managed Objects for APPN", RFC 2115, June 1997. [5] IBM, APPN High Performance Routing Architecture Reference, SV40- 1018-00. [6] IBM, SNA/MS Formats, GC31-8302-00 8. Security Considerations In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. Clouston & Moore Standards Track [Page 33] RFC 2238 Definitions of Managed Objects for HPR November 1997 None of the read-only objects in the HPR MIB reports a password, user data, or anything else that is particularly sensitive. Some enterprises view their network configuration itself, as well as information about network usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. One read-write object in the MIB can affect network operations: o hprRtpPathSwitchTrigger: Setting this object to 'switchPathNow' triggers an immediate path switch attempt. An HPR path switch does not itself disrupt the SNA sessions using the RTP connection undergoing the path switch. However, frequent path switches for many RTP connections can have an adverse impact on overall network performance. It is recommended that SNMP access to this object be restricted. Other read-write objects control the gathering of network management data; controlling access to these objects is less critical. 9. Authors' Addresses Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Phone: +1 919 472 2333 EMail: clouston@cisco.com Bob Moore IBM Corporation 800 Park Offices Drive CNMA/664 P.O. Box 12195 Research Triangle Park, NC 27709, USA Phone: +1 919 254 4436 EMail: remoore@ralvm6.vnet.ibm.com Clouston & Moore Standards Track [Page 34] RFC 2238 Definitions of Managed Objects for HPR November 1997 10. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Clouston & Moore Standards Track [Page 35] snmp-mibs-downloader-1.1/mibrfcs/rfc2266.txt0000644000000000000000000040561311402176071015572 0ustar Network Working Group J. Flick Request for Comments: 2266 Hewlett Packard Company Category: Standards Track January 1998 Definitions of Managed Objects for IEEE 802.12 Repeater Devices 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network repeaters based on IEEE 802.12. Table of Contents 1. The SNMP Network Management Framework ...................... 2 1.1. Object Definitions ....................................... 2 2. Overview ................................................... 2 2.1. Repeater Management Model ................................ 3 2.2. MAC Addresses ............................................ 4 2.3. Master Mode and Slave Mode ............................... 4 2.4. IEEE 802.12 Training Frames .............................. 4 2.5. Structure of the MIB ..................................... 6 2.5.1. Basic Definitions ...................................... 7 2.5.2. Monitor Definitions .................................... 7 2.5.3. Address Tracking Definitions ........................... 7 2.6. Relationship to other MIBs ............................... 7 2.6.1. Relationship to MIB-II ................................. 7 2.6.1.1. Relationship to the 'system' group ................... 7 2.6.1.2. Relationship to the 'interfaces' group ............... 8 2.6.2. Relationship to the 802.3 Repeater MIB ................. 8 Flick Standards Track [Page 1] RFC 2266 IEEE 802.12 Repeater MIB January 1998 2.7. Mapping of IEEE 802.12 Managed Objects ................... 9 3. Definitions ................................................ 12 4. Acknowledgements ........................................... 53 5. References ................................................. 53 6. Security Considerations .................................... 54 7. Author's Address ........................................... 55 8. Full Copyright Statement ................................... 56 1. The SNMP Network Management Framework The SNMP Network Management Framework consists of several components. For the purpose of this specification, the applicable components of the Framework are the SMI and related documents [2, 3, 4], which define the mechanisms used for describing and naming objects for the purpose of management. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base (MIB). Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [1] defined in the SMI [2]. 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. 2. Overview Instances of these object types represent attributes of an IEEE 802.12 repeater, as defined by Section 12, "RMAC Protocol" in IEEE Standard 802.12-1995 [6]. The definitions presented here are based on Section 13, "Layer management functions and services", and Annex C, "GDMO Specifications for Demand Priority Managed Objects" of IEEE Standard 802.12-1995 [6]. Implementors of these MIB objects should note that the IEEE document explicitly describes (in the form of Pascal pseudocode) when, where, and how various repeater attributes are measured. The IEEE document also describes the effects of repeater actions that may be invoked by manipulating instances of the MIB objects defined here. Flick Standards Track [Page 2] RFC 2266 IEEE 802.12 Repeater MIB January 1998 The counters in this document are defined to be the same as those counters in IEEE Standard 802.12-1995, with the intention that the same instrumentation can be used to implement both the IEEE and IETF management standards. 2.1. Repeater Management Model The model used in the design of this MIB allows for a managed system to contain one or more managed 802.12 repeaters, and one or more managed 802.12 repeater ports. A repeater port may be thought of as a source of traffic into a repeater in the system. The vgRptrBasicPortTable contains entries for each physical repeater port in the managed system. An implementor may choose to separate these ports into "groups". For example, a group may be used to represent a field-replaceable unit, so that the port numbering may match the numbering in the hardware implementation. Note that this group mapping is recommended but optional. An implementor may choose to put all of the system's ports into a single group, or to divide the ports into groups that do not match physical divisions. Each group within the system is uniquely identified by a group number. Each port within a system is uniquely identified by a combination of group number and port number. The method of numbering groups and ports is implementation-specific. Both groups and ports may be sparsely numbered. In addition to the externally visible ports, some implementations may have internal ports that are not obvious to the end-user but are nevertheless sources of traffic into the repeater system. Examples include internal management ports, through which an agent communicates, and ports connecting to a backplane internal to the implementation. It is the decision of the implementor to select the appropriate group(s) in which to place internal ports. Managed repeaters in the system are represented by entries in the vgRptrInfoTable. There may be multiple repeaters in the managed system. They are uniquely identified by a repeater number. The method of numbering repeaters is implementation-specific. Each port will either be associated with one of the repeaters, or isolated (a so-called "trivial" repeater). The set of ports associated with a single repeater will be in the same contention domain, and will be participating in the same instance of the Demand Priority Access Method protocol. The mapping of ports to repeaters may be static or dynamic. A column in the vgRptrBasicPortTable, vgRptrPortRptrInfoIndex, indicates the repeater that the port is currently associated with. The method for assigning a port to a repeater is implementation-specific. Flick Standards Track [Page 3] RFC 2266 IEEE 802.12 Repeater MIB January 1998 2.2. MAC Addresses All representations of MAC addresses in this MIB module are in "canonical" order defined by 802.1a, i.e., as if it were transmitted least significant bit first. This is true even if the repeater is operating in token ring framing mode, which requires MAC addresses to be transmitted most significant bit first. 2.3. Master Mode and Slave Mode In an IEEE 802.12 network, "master" devices act as network controllers to decide when to grant requesting end-nodes permission to transmit. These master devices may be repeaters, or other active controller devices such as switches. Devices which do not act as network controllers, such as end-nodes or passive switches, are considered to be operating in "slave" mode. An 802.12 repeater always acts in "master" mode on its local ports, which may connect to end nodes, switch or other device ports acting in "slave" mode, or lower-level repeaters in a cascade. It acts in "slave" mode on cascade ports, which may connect to an upper-level repeater in a cascade, or to switch or other device ports operating in "master" mode. 2.4. IEEE 802.12 Training Frames Training frames are special MAC frames that are used only during link initialization. Training frames are initially constructed by the device at the "lower" end of a link, which is the slave mode device for the link. The training frame format is as follows: +----+----+------------+--------------+----------+-----+ | DA | SA | Req Config | Allow Config | Data | FCS | +----+----+------------+--------------+----------+-----+ DA = destination address (six octets) SA = source address (six octets) Req Config = requested configuration (2 octets) Allow Config = allowed configuration (2 octets) Data = data (594 to 675 octets) FCS = frame check sequence (4 octets) Training frames are always sent with a null destination address. To pass training, an end node must use its source address in the source address field of the training frame. A repeater may use a non-null source address if it has one, or it may use a null source address. Flick Standards Track [Page 4] RFC 2266 IEEE 802.12 Repeater MIB January 1998 The requested configuration field allows the slave mode device to inform the master mode device about itself and to request configuration options. The training response frame from the master mode device contains the slave mode device's requested configuration from the training request frame. The currently defined format of the requested configuration field as defined in the IEEE Standard 802.12-1995 standard is shown below. Please refer to the most current version of the IEEE document for a more up to date description of this field. In particular, the reserved bits may be used in later versions of the standard. First Octet: Second Octet: 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |v|v|v|r|r|r|r|r| |r|r|r|F|F|P|P|R| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ vvv: The version of the 802.12 training protocol with which the training initiator is compliant. The current version is 100. Note that because of the different bit ordering used in IEEE and IETF documents, this value corresponds to version 1. r: Reserved bits (set to zero) FF: 00 = frameType88023 01 = frameType88025 10 = reserved 11 = frameTypeEither PP: 00 = singleAddressMode 01 = promiscuousMode 10 = reserved 11 = reserved R: 0 = the training initiator is an end node 1 = the training initiator is a repeater The allowed configuration field allows the master mode device to respond with the allowed configuration. The slave mode device sets the contents of this field to all zero bits. The master mode device sets the allowed configuration field as follows: First Octet: Second Octet: 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |v|v|v|D|C|N|r|r| |r|r|r|F|F|P|P|R| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Flick Standards Track [Page 5] RFC 2266 IEEE 802.12 Repeater MIB January 1998 vvv: The version of the 802.12 training protocol with which the training responder is compliant. The current version is 100. Note that because of the different bit ordering used in IEEE and IETF documents, this value corresponds to version 1. D: 0 = No duplicate address has been detected. 1 = Duplicate address has been detected. C: 0 = The requested configuration is compatible with the network and the attached port. 1 = The requested configuration is not compatible with the network and/or the attached port. In this case, the FF, PP, and R bits indicate a configuration that would be allowed. N: 0 = Access will be allowed, providing the configuration is compatible (C = 0). 1 = Access is not granted because of security restrictions. r: Reserved bits (set to zero). FF: 00 = frameType88023 will be used. 01 = frameType88025 will be used. 10 = reserved 11 = reserved PP: 00 = singleAddressMode 01 = promiscuousMode 10 = reserved 11 = reserved R: 0 = Requested access as an end node is allowed. 1 = Requested access as a repeater is allowed. Again, note that the most recent version of the IEEE 802.12 standard should be consulted for the most up to date definition of the requested configuration and allowed configuration fields. The data field contains between 594 and 675 octets and is filled in by the training initiator. The first 55 octets may be used for vendor specific protocol information. The remaining octets are all zeros. The length of the training frame combined with the requirement that 24 consecutive training frames be exchanged without error to complete training ensures that marginal links will not complete training. 2.5. Structure of the MIB Objects in this MIB are arranged into OID subtrees, each of which contains a set of related objects within a broad functional category. These subtrees are intended for organizational convenience ONLY, and have no relation to the conformance groups defined later in the document. Flick Standards Track [Page 6] RFC 2266 IEEE 802.12 Repeater MIB January 1998 2.5.1. Basic Definitions The basic definitions include objects for managing the basic status and control parameters for each repeater within the managed system, for the port groups within the managed system, and for the individual ports themselves. 2.5.2. Monitor Definitions The monitor definitions include monitoring statistics for each repeater within the system and for individual ports. 2.5.3. Address Tracking Definitions This collection includes objects for tracking the MAC addresses of the DTEs attached to the ports within the system. Note that this MIB also includes by reference a collection of objects from the 802.3 Repeater MIB which may be used for mapping the topology of a network. These definitions are based on a technology which has been patented by Hewlett-Packard Company (HP). HP has granted rights to this technology to implementors of this MIB. See [8] and [9] for details. 2.6. Relationship to other MIBs 2.6.1. Relationship to MIB-II It is assumed that a repeater implementing this MIB will also implement (at least) the 'system' group defined in MIB-II [5]. 2.6.1.1. Relationship to the 'system' group In MIB-II, the 'system' group is defined as being mandatory for all systems such that each managed entity contains one instance of each object in the 'system' group. Thus, those objects apply to the entity even if the entity's sole functionality is management of repeaters. Note that all of the managed repeaters (i.e. entries in the vgRptrInfoTable) will normally exist within a single naming scope. Therefore, there will normally only be a single instance of each of the objects in the system group for the entire managed repeater system regardless of how many managed repeaters there are in the system. Flick Standards Track [Page 7] RFC 2266 IEEE 802.12 Repeater MIB January 1998 2.6.1.2. Relationship to the 'interfaces' group In MIB-II, the 'interfaces' group is defined as being mandatory for all systems and contains information on an entity's interfaces, where each interface is thought of as being attached to a 'subnetwork'. (Note that this term is not to be confused with 'subnet' which refers to an addressing partitioning scheme used in the Internet suite of protocols.) This Repeater MIB uses the notion of ports on a repeater. The concept of a MIB-II interface has NO specific relationship to a repeater's port. Therefore, the 'interfaces' group applies only to the one (or more) network interfaces on which the entity managing the repeater sends and receives management protocol operations, and does not apply to the repeater's ports. This is consistent with the physical-layer nature of a repeater. An 802.12 repeater has an RMAC implementation, which acts as the repeater end of the Demand Priority Access Method, but does not contain a DTE MAC implementation, and does not pass packets up to higher-level protocol entities for processing. (When a network management entity is observing a repeater, it may appear as though the repeater is passing packets to a higher-level protocol entity. However, this is only a means of implementing management, and this passing of management information is not part of the repeater functionality.) 2.6.2. Relationship to the 802.3 Repeater MIB An IEEE 802.12 repeater can be configured to operate in either ethernet or token ring framing mode. This only affects the frame format and address bit order of the frames on the wire. An 802.12 network does not use the media access protocol for either ethernet or token ring. Instead, IEEE 802.12 defines its own media access protocol, the Demand Priority Access Method (DPAM). There is an existing standards-track MIB module for instrumenting IEEE 802.3 repeaters [7]. That MIB module is designed to instrument the operation of the repeater in a network implementing the 802.3 media access protocol. Therefore, much of that MIB does not apply to 802.12 repeaters. However, the 802.3 Repeater MIB also contains a collection of objects that may be used to map the topology of a network. These objects are contained in a separable OBJECT-GROUP, are not 802.3-specific, and are considered useful for 802.12 repeaters. In addition, the layer Flick Standards Track [Page 8] RFC 2266 IEEE 802.12 Repeater MIB January 1998 management clause of the IEEE 802.12 specification includes similar functionality. Therefore, vendors of agents for 802.12 repeaters are encouraged to implement the snmpRptrGrpRptrAddrSearch OBJECT-GROUP defined in the 802.3 Repeater MIB. 2.7. Mapping of IEEE 802.12 Managed Objects IEEE 802.12 Managed Object Corresponding SNMP Object oRepeater .aCurrentFramingType vgRptrInfoCurrentFramingType .aDesiredFramingType vgRptrInfoDesiredFramingType .aFramingCapability vgRptrInfoFramingCapability .aMACAddress vgRptrInfoMACAddress .aRepeaterHealthState vgRptrInfoOperStatus .aRepeaterID vgRptrInfoIndex .aRepeaterSearchAddress SNMP-REPEATER-MIB - rptrAddrSearchAddress .aRepeaterSearchGroup SNMP-REPEATER-MIB - rptrAddrSearchGroup .aRepeaterSearchPort SNMP-REPEATER-MIB - rptrAddrSearchPort .aRepeaterSearchState SNMP-REPEATER-MIB - rptrAddrSearchState .aRMACVersion vgRptrInfoTrainingVersion .acRepeaterSearchAddress SNMP-REPEATER-MIB - rptrAddrSearchAddress .acResetRepeater vgRptrInfoReset .nRepeaterHealth vgRptrHealth .nRepeaterReset vgRptrResetEvent oGroup .aGroupCablesBundled vgRptrGroupCablesBundled .aGroupID vgRptrGroupIndex .aGroupPortCapacity vgRptrGroupPortCapacity oPort .aAllowableTrainingType vgRptrPortAllowedTrainType .aBroadcastFramesReceived vgRptrPortBroadcastFrames .aCentralMgmtDetectedDupAddr vgRptrMgrDetectedDupAddress .aDataErrorFramesReceived vgRptrPortDataErrorFrames .aHighPriorityFramesReceived vgRptrPortHighPriorityFrames .aHighPriorityOctetsReceived vgRptrPortHCHighPriorityOctets, or vgRptrPortHighPriorityOctets and vgRptrPortHighPriOctetRollovers .aIPMFramesReceived vgRptrPortIPMFrames .aLastTrainedAddress vgRptrAddrLastTrainedAddress .aLastTrainingConfig vgRptrPortLastTrainConfig Flick Standards Track [Page 9] RFC 2266 IEEE 802.12 Repeater MIB January 1998 .aLocalRptrDetectedDupAddr vgRptrRptrDetectedDupAddress .aMulticastFramesReceived vgRptrPortMulticastFrames .aNormalPriorityFramesReceived vgRptrPortNormPriorityFrames .aNormalPriorityOctetsReceived vgRptrPortHCNormPriorityOctets, or vgRptrPortNormPriorityOctets and vgRptrPortNormPriOctetRollovers .aNullAddressedFramesReceived vgRptrPortNullAddressedFrames .aOctetsInUnreadableFramesRcvd vgRptrPortHCUnreadableOctets, or vgRptrPortUnreadableOctets and vgRptrPortUnreadOctetRollovers .aOversizeFramesReceived vgRptrPortOversizeFrames .aPortAdministrativeState vgRptrPortAdminStatus .aPortID vgRptrPortIndex .aPortStatus vgRptrPortOperStatus .aPortType vgRptrPortType .aPriorityEnable vgRptrPortPriorityEnable .aPriorityPromotions vgRptrPortPriorityPromotions .aReadableFramesReceived vgRptrPortReadableFrames .aReadableOctetsReceived vgRptrPortHCReadableOctets, or vgRptrPortReadableOctets and vgRptrPortReadOctetRollovers .aSupportedCascadeMode vgRptrPortSupportedCascadeMode .aSupportedPromiscMode vgRptrPortSupportedPromiscMode .aTrainedAddressChanges vgRptrAddrTrainedAddressChanges .aTrainingResult vgRptrPortTrainingResult .aTransitionsIntoTraining vgRptrPortTransitionToTrainings .acPortAdministrativeControl vgRptrPortAdminStatus The following IEEE 802.12 managed objects have not been included in the 802.12 Repeater MIB for the indicated reasons. IEEE 802.12 Managed Object Disposition oRepeater .aGroupMap Can be determined by GetNext sweep of vgRptrBasicGroupTable .aRepeaterGroupCapacity Meaning is unclear in many repeater implementations. For example, some cards may have daughter cards which make group capacity change depending on the cards installed. Meaning is also unclear in a stackable implementation. Also, since groups are not required to be numbered from 1..capacity, but may be computed algorithmically or Flick Standards Track [Page 10] RFC 2266 IEEE 802.12 Repeater MIB January 1998 related to Entity MIB indices, this object was not considered useful. .aRepeaterHealthData Since the data is implementation specific and non-interoperable, it was not considered useful. .aRepeaterHealthText Implementation experience with similar object in 802.3 Rptr MIB indicated it was not useful. .acExecuteNonDisruptiveSelfTest Implementation experience with similar object in 802.3 Rptr MIB indicated it was not useful. .nGroupMapChange Since aGroupMap was not included, a notification of a change in that object was not needed. oGroup .aPortMap Can be determined by GetNext sweep of vgRptrBasicPortTable .nPortMapChange Since aPortMap was not included, a notification of a change in that object was not needed. oPort .aMediaType This object is a function of the Physical Media Dependent (PMD) layer, which is defined differently for each type of network. For an 802.3 network, .aMediaType corresponds to the PMD definitions in the 802.3 MAU MIB. For management of an 802.12 network, mapping of this object is deferred to future work on an 802.12 PMD MIB which will include both repeater and interface PMD information and redundant link support. Flick Standards Track [Page 11] RFC 2266 IEEE 802.12 Repeater MIB January 1998 3. Definitions DOT12-RPTR-MIB DEFINITIONS ::= BEGIN IMPORTS mib-2, Integer32, Counter32, Counter64, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI MacAddress, TruthValue, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; vgRptrMIB MODULE-IDENTITY LAST-UPDATED "9705192256Z" -- May 19, 1997 ORGANIZATION "IETF 100VG-AnyLAN Working Group" CONTACT-INFO "WG E-mail: vgmib@hprnd.rose.hp.com Chair: Jeff Johnson Postal: RedBack Networks 2570 North First Street, Suite 410 San Jose, CA 95131 Tel: +1 408 571 2699 Fax: +1 408 571 2698 E-mail: jeff@redbacknetworks.com Editor: John Flick Postal: Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 Tel: +1 916 785 4018 Fax: +1 916 785 3583 E-mail: johnf@hprnd.rose.hp.com" DESCRIPTION "This MIB module describes objects for managing IEEE 802.12 repeaters." ::= { mib-2 53 } vgRptrObjects OBJECT IDENTIFIER ::= { vgRptrMIB 1 } vgRptrBasic OBJECT IDENTIFIER ::= { vgRptrObjects 1 } vgRptrBasicRptr OBJECT IDENTIFIER ::= { vgRptrBasic 1 } vgRptrInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF VgRptrInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Flick Standards Track [Page 12] RFC 2266 IEEE 802.12 Repeater MIB January 1998 "A table of information about each 802.12 repeater in the managed system." ::= { vgRptrBasicRptr 1 } vgRptrInfoEntry OBJECT-TYPE SYNTAX VgRptrInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single repeater." INDEX { vgRptrInfoIndex } ::= { vgRptrInfoTable 1 } VgRptrInfoEntry ::= SEQUENCE { vgRptrInfoIndex Integer32, vgRptrInfoMACAddress MacAddress, vgRptrInfoCurrentFramingType INTEGER, vgRptrInfoDesiredFramingType INTEGER, vgRptrInfoFramingCapability INTEGER, vgRptrInfoTrainingVersion INTEGER, vgRptrInfoOperStatus INTEGER, vgRptrInfoReset INTEGER, vgRptrInfoLastChange TimeStamp } vgRptrInfoIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for the repeater for which this entry contains information. The numbering scheme for repeaters is implementation specific." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.1, aRepeaterID." ::= { vgRptrInfoEntry 1 } vgRptrInfoMACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC address used by the repeater when it initiates training on the uplink port. Repeaters are allowed to train with an assigned MAC address Flick Standards Track [Page 13] RFC 2266 IEEE 802.12 Repeater MIB January 1998 or a null (all zeroes) MAC address." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.1, aMACAddress." ::= { vgRptrInfoEntry 2 } vgRptrInfoCurrentFramingType OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of framing (802.3 or 802.5) currently in use by the repeater." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.1, aCurrentFramingType." ::= { vgRptrInfoEntry 3 } vgRptrInfoDesiredFramingType OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of framing which will be used by the repeater after the next time it is reset. The value of this object should be preserved across repeater resets and power failures." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.1, aDesiredFramingType." ::= { vgRptrInfoEntry 4 } vgRptrInfoFramingCapability OBJECT-TYPE SYNTAX INTEGER { frameType88023(1), frameType88025(2), frameTypeEither(3) } MAX-ACCESS read-only STATUS current DESCRIPTION Flick Standards Track [Page 14] RFC 2266 IEEE 802.12 Repeater MIB January 1998 "The type of framing this repeater is capable of supporting." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.1, aFramingCapability." ::= { vgRptrInfoEntry 5 } vgRptrInfoTrainingVersion OBJECT-TYPE SYNTAX INTEGER (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "The highest version bits (vvv bits) supported by the repeater during training." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.1, aRMACVersion." ::= { vgRptrInfoEntry 6 } vgRptrInfoOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), ok(2), generalFailure(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The vgRptrInfoOperStatus object indicates the operational state of the repeater." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.1, aRepeaterHealthState." ::= { vgRptrInfoEntry 7 } vgRptrInfoReset OBJECT-TYPE SYNTAX INTEGER { noReset(1), reset(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to reset(2) causes the repeater to transition to its initial state as specified in clause 12 [IEEE Std 802.12]. Flick Standards Track [Page 15] RFC 2266 IEEE 802.12 Repeater MIB January 1998 Setting this object to noReset(1) has no effect. The agent will always return the value noReset(1) when this object is read. After receiving a request to set this variable to reset(2), the agent is allowed to delay the reset for a short period. For example, the implementor may choose to delay the reset long enough to allow the SNMP response to be transmitted. In any event, the SNMP response must be transmitted. This action does not reset the management counters defined in this document nor does it affect the vgRptrPortAdminStatus parameters. Included in this action is the execution of a disruptive Self-Test with the following characteristics: 1) The nature of the tests is not specified. 2) The test resets the repeater but without affecting configurable management information about the repeater. 3) Packets received during the test may or may not be transferred. 4) The test does not interfere with management functions. After performing this self-test, the agent will update the repeater health information (including vgRptrInfoOperStatus), and send a vgRptrResetEvent." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.2.2, acResetRepeater." ::= { vgRptrInfoEntry 8 } vgRptrInfoLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when any of the following conditions occurred: 1) agent cold- or warm-started; 2) this instance of repeater was created (such as when a device or module was added to the system); Flick Standards Track [Page 16] RFC 2266 IEEE 802.12 Repeater MIB January 1998 3) a change in the value of vgRptrInfoOperStatus; 4) ports were added or removed as members of the repeater; or 5) any of the counters associated with this repeater had a discontinuity." ::= { vgRptrInfoEntry 9 } vgRptrBasicGroup OBJECT IDENTIFIER ::= { vgRptrBasic 2 } vgRptrBasicGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF VgRptrBasicGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about groups of ports." ::= { vgRptrBasicGroup 1 } vgRptrBasicGroupEntry OBJECT-TYPE SYNTAX VgRptrBasicGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vgRptrBasicGroupTable, containing information about a single group of ports." INDEX { vgRptrGroupIndex } ::= { vgRptrBasicGroupTable 1 } VgRptrBasicGroupEntry ::= SEQUENCE { vgRptrGroupIndex Integer32, vgRptrGroupObjectID OBJECT IDENTIFIER, vgRptrGroupOperStatus INTEGER, vgRptrGroupPortCapacity Integer32, vgRptrGroupCablesBundled INTEGER } vgRptrGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2146483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the group within the system for which this entry contains information. The numbering scheme for groups is implementation specific." REFERENCE Flick Standards Track [Page 17] RFC 2266 IEEE 802.12 Repeater MIB January 1998 "IEEE Standard 802.12-1995, 13.2.4.4.1, aGroupID." ::= { vgRptrBasicGroupEntry 1 } vgRptrGroupObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor's authoritative identification of the group. This value may be allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides a straight-forward and unambiguous means for determining what kind of group is being managed. For example, this object could take the value 1.3.6.1.4.1.4242.1.2.14 if vendor 'Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, and had assigned the identifier 1.3.6.1.4.1.4242.1.2.14 to its 'Wilma Flintstone 6-Port Plug-in Module.'" ::= { vgRptrBasicGroupEntry 2 } vgRptrGroupOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), operational(2), malfunctioning(3), notPresent(4), underTest(5), resetInProgress(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "An object that indicates the operational status of the group. A status of notPresent(4) indicates that the group is temporarily or permanently physically and/or logically not a part of the system. It is an implementation-specific matter as to whether the agent effectively removes notPresent entries from the table. A status of operational(2) indicates that the group is functioning, and a status of Flick Standards Track [Page 18] RFC 2266 IEEE 802.12 Repeater MIB January 1998 malfunctioning(3) indicates that the group is malfunctioning in some way." ::= { vgRptrBasicGroupEntry 3 } vgRptrGroupPortCapacity OBJECT-TYPE SYNTAX Integer32 (1..2146483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The vgRptrGroupPortCapacity is the number of ports that can be contained within the group. Valid range is 1-2147483647. Within each group, the ports are uniquely numbered in the range from 1 to vgRptrGroupPortCapacity. Some ports may not be present in the system, in which case the actual number of ports present will be less than the value of vgRptrGroupPortCapacity. The number of ports present is never greater than the value of vgRptrGroupPortCapacity. Note: In practice, this will generally be the number of ports on a module, card, or board, and the port numbers will correspond to numbers marked on the physical embodiment." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.4.1, aGroupPortCapacity." ::= { vgRptrBasicGroupEntry 4 } vgRptrGroupCablesBundled OBJECT-TYPE SYNTAX INTEGER { someCablesBundled(1), noCablesBundled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to indicate whether there are any four-pair UTP links connected to this group that are contained in a cable bundle with multiple four-pair groups (e.g. a 25-pair bundle). Bundled cable may only be used for repeater-to-end node links where the end node is not in promiscuous mode. When a broadcast or multicast packet is received from a port on this group that is not a Flick Standards Track [Page 19] RFC 2266 IEEE 802.12 Repeater MIB January 1998 promiscuous or cascaded port, the packet will be buffered completely before being repeated if this object is set to 'someCablesBundled(1)'. When this object is equal to 'noCablesBundled(2)', all packets received from ports on this group will be repeated as the frame is being received. Note that the value 'someCablesBundled(1)' will work in the vast majority of all installations, regardless of whether or not any cables are physically in a bundle, since packets received from promiscuous and cascaded ports automatically avoid the store and forward. The main situation in which 'noCablesBundled(2)' is beneficial is when there is a large amount of multicast traffic and the cables are not in a bundle. The value of this object should be preserved across repeater resets and power failures." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.4.1, aGroupCablesBundled." ::= { vgRptrBasicGroupEntry 5 } vgRptrBasicPort OBJECT IDENTIFIER ::= { vgRptrBasic 3 } vgRptrBasicPortTable OBJECT-TYPE SYNTAX SEQUENCE OF VgRptrBasicPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing configuration and status information about 802.12 repeater ports in the system. The number of entries is independent of the number of repeaters in the managed system." ::= { vgRptrBasicPort 1 } vgRptrBasicPortEntry OBJECT-TYPE SYNTAX VgRptrBasicPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vgRptrBasicPortTable, containing information about a single port." INDEX { vgRptrGroupIndex, vgRptrPortIndex } ::= { vgRptrBasicPortTable 1 } VgRptrBasicPortEntry ::= Flick Standards Track [Page 20] RFC 2266 IEEE 802.12 Repeater MIB January 1998 SEQUENCE { vgRptrPortIndex Integer32, vgRptrPortType INTEGER, vgRptrPortAdminStatus INTEGER, vgRptrPortOperStatus INTEGER, vgRptrPortSupportedPromiscMode INTEGER, vgRptrPortSupportedCascadeMode INTEGER, vgRptrPortAllowedTrainType INTEGER, vgRptrPortLastTrainConfig OCTET STRING, vgRptrPortTrainingResult OCTET STRING, vgRptrPortPriorityEnable TruthValue, vgRptrPortRptrInfoIndex Integer32 } vgRptrPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the port within the group for which this entry contains information. This identifies the port independently from the repeater it may be attached to. The numbering scheme for ports is implementation specific; however, this value can never be greater than vgRptrGroupPortCapacity for the associated group." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aPortID." ::= { vgRptrBasicPortEntry 1 } vgRptrPortType OBJECT-TYPE SYNTAX INTEGER { cascadeExternal(1), cascadeInternal(2), localExternal(3), localInternal(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the type of port. One of the following: cascadeExternal - Port is an uplink with physical connections which are externally visible cascadeInternal - Port is an uplink with Flick Standards Track [Page 21] RFC 2266 IEEE 802.12 Repeater MIB January 1998 physical connections which are not externally visible, such as a connection to an internal backplane in a chassis localExternal - Port is a downlink or local port with externally visible connections localInternal - Port is a downlink or local port with connections which are not externally visible, such as a connection to an internal agent 'internal' is used to identify ports which place traffic into the repeater, but do not have any external connections. Note that both DTE and cascaded repeater downlinks are considered 'local' ports." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aPortType." ::= { vgRptrBasicPortEntry 2 } vgRptrPortAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Port enable/disable function. Enabling a disabled port will cause training to be initiated by the training initiator (the slave mode device) on the link. Setting this object to disabled(2) disables the port. A disabled port neither transmits nor receives. Once disabled, a port must be explicitly enabled to restore operation. A port which is disabled when power is lost or when a reset is exerted shall remain disabled when normal operation resumes. The value of this object should be preserved across repeater resets and power failures." REFERENCE Flick Standards Track [Page 22] RFC 2266 IEEE 802.12 Repeater MIB January 1998 "IEEE Standard 802.12-1995, 13.2.4.5.1, aPortAdministrativeState." ::= { vgRptrBasicPortEntry 3 } vgRptrPortOperStatus OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2), training(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current status for the port as specified by the PORT_META_STATE in the port process module of clause 12 [IEEE Std 802.12]. During initialization or any link warning conditions, vgRptrPortStatus will be 'inactive(2)'. When Training_Up is received by the repeater on a local port (or when Training_Down is received on a cascade port), vgRptrPortStatus will change to 'training(3)' and vgRptrTrainingResult can be monitored to see the detailed status regarding training. When 24 consecutive good FCS packets are exchanged and the configuration bits are OK, vgRptrPortStatus will change to 'active(1)'. A disabled port shall have a port status of 'inactive(2)'." REFERENCE "IEEE Standard 802.12, 13.2.4.5.1, aPortStatus." ::= { vgRptrBasicPortEntry 4 } vgRptrPortSupportedPromiscMode OBJECT-TYPE SYNTAX INTEGER { singleModeOnly(1), singleOrPromiscMode(2), promiscModeOnly(3) } MAX-ACCESS read-only STATUS current DESCRIPTION Flick Standards Track [Page 23] RFC 2266 IEEE 802.12 Repeater MIB January 1998 "This object describes whether the port hardware is capable of supporting promiscuous mode, single address mode (i.e., repeater filters unicasts not addressed to the end station attached to this port), or both. A port for which vgRptrPortType is equal to 'cascadeInternal' or 'cascadeExternal' will always have a value of 'promiscModeOnly' for this object." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aSupportedPromiscMode." ::= { vgRptrBasicPortEntry 5 } vgRptrPortSupportedCascadeMode OBJECT-TYPE SYNTAX INTEGER { endNodesOnly(1), endNodesOrRepeaters(2), cascadePort(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes whether the port hardware is capable of supporting cascaded repeaters, end nodes, or both. A port for which vgRptrPortType is equal to 'cascadeInternal' or 'cascadeExternal' will always have a value of 'cascadePort' for this object." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aSupportedCascadeMode." ::= { vgRptrBasicPortEntry 6 } vgRptrPortAllowedTrainType OBJECT-TYPE SYNTAX INTEGER { allowEndNodesOnly(1), allowPromiscuousEndNodes(2), allowEndNodesOrRepeaters(3), allowAnything(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "This security object is set by the network manager to configure what type of device is permitted to connect to the port. One of the following values: Flick Standards Track [Page 24] RFC 2266 IEEE 802.12 Repeater MIB January 1998 allowEndNodesOnly - only non- promiscuous end nodes permitted. allowPromiscuousEndNodes - promiscuous or non-promiscuous end nodes permitted allowEndNodesOrRepeaters - repeaters or non- promiscuous end nodes permitted allowAnything - repeaters, promiscuous or non-promiscuous end nodes permitted For a port for which vgRptrPortType is equal to 'cascadeInternal' or 'cascadeExternal', the corresponding instance of this object may not be set to 'allowEndNodesOnly' or 'allowPromiscuousEndNodes'. The agent must reject a SET of this object if the value includes no capabilities that are supported by this port's hardware, as defined by the values of the corresponding instances of vgRptrPortSupportedPromiscMode and vgRptrPortSupportedCascadeMode. Note that vgRptrPortSupportPromiscMode and vgRptrPortSupportedCascadeMode represent what the port hardware is capable of supporting. vgRptrPortAllowedTrainType is used for setting an administrative policy for a port. The actual set of training configurations that will be allowed to succeed on a port is the intersection of what the hardware will support and what is administratively allowed. The above requirement on what values may be set to this object says that the intersection of what is supported and what is allowed must be non-empty. In other words, it must not result in a situation in which nothing would be allowed to train on that port. However, a value can be set to this object as long as the combination of this object and what is supported by the hardware would still leave at least one configuration that could successfully train on the port. Flick Standards Track [Page 25] RFC 2266 IEEE 802.12 Repeater MIB January 1998 The value of this object should be preserved across repeater resets and power failures." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aAllowableTrainingType." ::= { vgRptrBasicPortEntry 7 } vgRptrPortLastTrainConfig OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 16 bit field. For local ports, this object contains the requested configuration field from the most recent error-free training request frame sent by the device connected to the port. For cascade ports, this object contains the responder's allowed configuration field from the most recent error-free training response frame received in response to training initiated by this repeater. The format of the current version of this field is described in section 3.2. Please refer to the most recent version of the IEEE 802.12 standard for the most up-to-date definition of the format of this object." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aLastTrainingConfig." ::= { vgRptrBasicPortEntry 8 } vgRptrPortTrainingResult OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This 18 bit field is used to indicate the result of training. It contains two bits which indicate if error-free training frames have been received, and it also contains the 16 bits of the allowed configuration field from the most recent error-free training response frame on the port. First Octet: Second and Third Octets: 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-----------------------------+ |0|0|0|0|0|0|V|G| allowed configuration field | +-+-+-+-+-+-+-+-+-----------------------------+ Flick Standards Track [Page 26] RFC 2266 IEEE 802.12 Repeater MIB January 1998 V: Valid: set when at least one error-free training frame has been received. Indicates the 16 training configuration bits in vgRptrPortLastTrainConfig and vgRptrPortTrainingResult contain valid information. This bit is cleared when vgRptrPortStatus transitions to the 'inactive' or 'training' state. G: LinkGood: indicates the link hardware is OK. Set if 24 consecutive error-free training packets have been exchanged. Cleared when a training packet with errors is received, or when vgRptrPortStatus transitions to the 'inactive' or 'training' state. The format of the current version of the allowed configuration field is described in section 3.2. Please refer to the most recent version of the IEEE 802.12 standard for the most up-to-date definition of the format of this field. If the port is in training, a management station can examine this object to see if any training packets have been passed successfully. If there have been any good training packets, the Valid bit will be set and the management station can examine the allowed configuration field to see if there is a duplicate address, configuration, or security problem. Note that on a repeater local port, this repeater generates the training response bits, while on a cascade port, the device at the upper end of the link originated the training response bits." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aTrainingResult." ::= { vgRptrBasicPortEntry 9 } vgRptrPortPriorityEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "A configuration flag used to determine whether the repeater will service high priority requests received on the port as high priority or normal priority. When 'false', high priority requests Flick Standards Track [Page 27] RFC 2266 IEEE 802.12 Repeater MIB January 1998 on this port will be serviced as normal priority. The setting of this object has no effect on a cascade port. Also note that the setting of this object has no effect on a port connected to a cascaded repeater. In both of these cases, this setting is treated as always 'true'. The value 'false' only has an effect when the port is a localInternal or localExternal port connected to an end node. The value of this object should be preserved across repeater resets and power failures." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aPriorityEnable." ::= { vgRptrBasicPortEntry 10 } vgRptrPortRptrInfoIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the repeater that this port is currently mapped to. The repeater identified by a particular value of this object is the same as that identified by the same value of vgRptrInfoIndex. A value of zero indicates that this port is not currently mapped to any repeater." ::= { vgRptrBasicPortEntry 11 } vgRptrMonitor OBJECT IDENTIFIER ::= { vgRptrObjects 2 } vgRptrMonRepeater OBJECT IDENTIFIER ::= { vgRptrMonitor 1 } vgRptrMonitorTable OBJECT-TYPE SYNTAX SEQUENCE OF VgRptrMonitorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of performance and error statistics for each repeater in the system. The instance of the vgRptrInfoLastChange associated with a repeater is used to indicate possible discontinuities of the counters in this table that are associated with the same repeater." Flick Standards Track [Page 28] RFC 2266 IEEE 802.12 Repeater MIB January 1998 ::= { vgRptrMonRepeater 1 } vgRptrMonitorEntry OBJECT-TYPE SYNTAX VgRptrMonitorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing statistics for a single repeater." INDEX { vgRptrInfoIndex } ::= { vgRptrMonitorTable 1 } VgRptrMonitorEntry ::= SEQUENCE { vgRptrMonTotalReadableFrames Counter32, vgRptrMonTotalReadableOctets Counter32, vgRptrMonReadableOctetRollovers Counter32, vgRptrMonHCTotalReadableOctets Counter64, vgRptrMonTotalErrors Counter32 } vgRptrMonTotalReadableFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of good frames of valid frame length that have been received on all ports in this repeater. If an implementation cannot obtain a count of frames as seen by the repeater itself, this counter may be implemented as the summation of the values of the vgRptrPortReadableFrames counters for all of the ports in this repeater. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrInfoLastChange changes." ::= { vgRptrMonitorEntry 1 } vgRptrMonTotalReadableOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets contained in good frames that have been received on all ports in this repeater. If an implementation cannot Flick Standards Track [Page 29] RFC 2266 IEEE 802.12 Repeater MIB January 1998 obtain a count of octets as seen by the repeater itself, this counter may be implemented as the summation of the values of the vgRptrPortReadableOctets counters for all of the ports in this repeater. Note that this counter can roll over very quickly. A management station is advised to also poll the vgRptrReadableOctetRollovers object, or to use the 64-bit counter defined by vgRptrMonHCTotalReadableOctets instead of the two 32-bit counters. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrInfoLastChange changes." ::= { vgRptrMonitorEntry 2 } vgRptrMonReadableOctetRollovers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times that the associated instance of the vgRptrMonTotalReadableOctets counter has rolled over. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrInfoLastChange changes." ::= { vgRptrMonitorEntry 3 } vgRptrMonHCTotalReadableOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current Flick Standards Track [Page 30] RFC 2266 IEEE 802.12 Repeater MIB January 1998 DESCRIPTION "The total number of octets contained in good frames that have been received on all ports in this repeater. If an implementation cannot obtain a count of octets as seen by the repeater itself, this counter may be implemented as the summation of the values of the vgRptrPortHCReadableOctets counters for all of the ports in this repeater. This counter is a 64 bit version of vgRptrMonTotalReadableOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2). This counter may experience a discontinuity when the value of the corresponding instance of vgRptrInfoLastChange changes." ::= { vgRptrMonitorEntry 4 } vgRptrMonTotalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of errors which have occurred on all of the ports in this repeater. If an implementation cannot obtain a count of these errors as seen by the repeater itself, this counter may be implemented as the summation of the values of the vgRptrPortIPMFrames, vgRptrPortOversizeFrames, and vgRptrPortDataErrorFrames counters for all of the ports in this repeater. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrInfoLastChange changes." ::= { vgRptrMonitorEntry 5 } vgRptrMonGroup OBJECT IDENTIFIER ::= { vgRptrMonitor 2 } -- Currently unused vgRptrMonPort OBJECT IDENTIFIER ::= { vgRptrMonitor 3 } vgRptrMonPortTable OBJECT-TYPE SYNTAX SEQUENCE OF VgRptrMonPortEntry MAX-ACCESS not-accessible Flick Standards Track [Page 31] RFC 2266 IEEE 802.12 Repeater MIB January 1998 STATUS current DESCRIPTION "A table of performance and error statistics for the ports. The columnar object vgRptrPortLastChange is used to indicate possible discontinuities of counter type columnar objects in this table." ::= { vgRptrMonPort 1 } vgRptrMonPortEntry OBJECT-TYPE SYNTAX VgRptrMonPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vgRptrMonPortTable, containing performance and error statistics for a single port." INDEX { vgRptrGroupIndex, vgRptrPortIndex } ::= { vgRptrMonPortTable 1 } VgRptrMonPortEntry ::= SEQUENCE { vgRptrPortReadableFrames Counter32, vgRptrPortReadableOctets Counter32, vgRptrPortReadOctetRollovers Counter32, vgRptrPortHCReadableOctets Counter64, vgRptrPortUnreadableOctets Counter32, vgRptrPortUnreadOctetRollovers Counter32, vgRptrPortHCUnreadableOctets Counter64, vgRptrPortHighPriorityFrames Counter32, vgRptrPortHighPriorityOctets Counter32, vgRptrPortHighPriOctetRollovers Counter32, vgRptrPortHCHighPriorityOctets Counter64, vgRptrPortNormPriorityFrames Counter32, vgRptrPortNormPriorityOctets Counter32, vgRptrPortNormPriOctetRollovers Counter32, vgRptrPortHCNormPriorityOctets Counter64, vgRptrPortBroadcastFrames Counter32, vgRptrPortMulticastFrames Counter32, vgRptrPortNullAddressedFrames Counter32, vgRptrPortIPMFrames Counter32, vgRptrPortOversizeFrames Counter32, vgRptrPortDataErrorFrames Counter32, vgRptrPortPriorityPromotions Counter32, vgRptrPortTransitionToTrainings Counter32, vgRptrPortLastChange TimeStamp } Flick Standards Track [Page 32] RFC 2266 IEEE 802.12 Repeater MIB January 1998 vgRptrPortReadableFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the number of good frames of valid frame length that have been received on this port. This counter is incremented by one for each frame received on the port which is not counted by any of the following error counters: vgRptrPortIPMFrames, vgRptrPortOversizeFrames, vgRptrPortNullAddressedFrames, or vgRptrPortDataErrorFrames. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aReadableFramesReceived." ::= { vgRptrMonPortEntry 1 } vgRptrPortReadableOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in good frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which has been determined to be a readable frame (i.e. each frame counted by vgRptrPortReadableFrames). Note that this counter can roll over very quickly. A management station is advised to also poll the vgRptrPortReadOctetRollovers object, or to use the 64-bit counter defined by vgRptrPortHCReadableOctets instead of the two 32-bit counters. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. Flick Standards Track [Page 33] RFC 2266 IEEE 802.12 Repeater MIB January 1998 This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aReadableOctetsReceived." ::= { vgRptrMonPortEntry 2 } vgRptrPortReadOctetRollovers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of times that the associated instance of the vgRptrPortReadableOctets counter has rolled over. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aReadableOctetsReceived." ::= { vgRptrMonPortEntry 3 } vgRptrPortHCReadableOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in good frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which has been determined to be a readable frame (i.e. each frame counted by vgRptrPortReadableFrames). This counter is a 64 bit version of vgRptrPortReadableOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2). Flick Standards Track [Page 34] RFC 2266 IEEE 802.12 Repeater MIB January 1998 This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aReadableOctetsReceived." ::= { vgRptrMonPortEntry 4 } vgRptrPortUnreadableOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in invalid frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which is counted by vgRptrPortIPMFrames, vgRptrPortOversizeFrames, vgRptrPortNullAddressedFrames, or vgRptrPortDataErrorFrames. This counter can be combined with vgRptrPortReadableOctets to calculate network utilization. Note that this counter can roll over very quickly. A management station is advised to also poll the vgRptrPortUnreadOctetRollovers object, or to use the 64-bit counter defined by vgRptrPortHCUnreadableOctets instead of the two 32-bit counters. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aOctetsInUnreadableFramesRcvd." ::= { vgRptrMonPortEntry 5 } vgRptrPortUnreadOctetRollovers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Flick Standards Track [Page 35] RFC 2266 IEEE 802.12 Repeater MIB January 1998 STATUS current DESCRIPTION "This object is a count of the number of times that the associated instance of the vgRptrPortUnreadableOctets counter has rolled over. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aOctetsInUnreadableFramesRcvd." ::= { vgRptrMonPortEntry 6 } vgRptrPortHCUnreadableOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in invalid frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which is counted by vgRptrPortIPMFrames, vgRptrPortOversizeFrames, vgRptrPortNullAddressedFrames, or vgRptrPortDataErrorFrames. This counter can be combined with vgRptrPortHCReadableOctets to calculate network utilization. This counter is a 64 bit version of vgRptrPortUnreadableOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2). This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aOctetsInUnreadableFramesRcvd." Flick Standards Track [Page 36] RFC 2266 IEEE 802.12 Repeater MIB January 1998 ::= { vgRptrMonPortEntry 7 } vgRptrPortHighPriorityFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of high priority frames that have been received on this port. This counter is incremented by one for each high priority frame received on this port. This counter includes both good and bad high priority frames, as well as high priority training frames. This counter does not include normal priority frames which were priority promoted. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aHighPriorityFramesReceived." ::= { vgRptrMonPortEntry 8 } vgRptrPortHighPriorityOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in high priority frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which is counted by vgRptrPortHighPriorityFrames. Note that this counter can roll over very quickly. A management station is advised to also poll the vgRptrPortHighPriOctetRollovers object, or to use the 64-bit counter defined by vgRptrPortHCHighPriorityOctets instead of the two 32-bit counters. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. Flick Standards Track [Page 37] RFC 2266 IEEE 802.12 Repeater MIB January 1998 This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aHighPriorityOctetsReceived." ::= { vgRptrMonPortEntry 9 } vgRptrPortHighPriOctetRollovers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of times that the associated instance of the vgRptrPortHighPriorityOctets counter has rolled over. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aHighPriorityOctetsReceived." ::= { vgRptrMonPortEntry 10 } vgRptrPortHCHighPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in high priority frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which is counted by vgRptrPortHighPriorityFrames. This counter is a 64 bit version of vgRptrPortHighPriorityOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2). Flick Standards Track [Page 38] RFC 2266 IEEE 802.12 Repeater MIB January 1998 This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aHighPriorityOctetsReceived." ::= { vgRptrMonPortEntry 11 } vgRptrPortNormPriorityFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of normal priority frames that have been received on this port. This counter is incremented by one for each normal priority frame received on this port. This counter includes both good and bad normal priority frames, as well as normal priority training frames and normal priority frames which were priority promoted. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aNormalPriorityFramesReceived." ::= { vgRptrMonPortEntry 12 } vgRptrPortNormPriorityOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in normal priority frames that have been received on this port. This counter is incremented by OctetCount for each frame received on this port which is counted by vgRptrPortNormPriorityFrames. Note that this counter can roll over very quickly. A management station is advised to also poll the vgRptrPortNormPriOctetRollovers object, or to use the 64-bit counter defined by vgRptrPortHCNormPriorityOctets instead of the two 32-bit counters. Flick Standards Track [Page 39] RFC 2266 IEEE 802.12 Repeater MIB January 1998 This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aNormalPriorityOctetsReceived." ::= { vgRptrMonPortEntry 13 } vgRptrPortNormPriOctetRollovers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of times that the associated instance of the vgRptrPortNormPriorityOctets counter has rolled over. This two-counter mechanism is provided for those network management protocols that do not support 64-bit counters (e.g. SNMPv1). Note that retrieval of these two counters in the same PDU is NOT guaranteed to be atomic. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aNormalPriorityOctetsReceived." ::= { vgRptrMonPortEntry 14 } vgRptrPortHCNormPriorityOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of octets contained in normal priority frames that have been received on this port. This counter is incremented by OctetCount for each frame received Flick Standards Track [Page 40] RFC 2266 IEEE 802.12 Repeater MIB January 1998 on this port which is counted by vgRptrPortNormPriorityFrames. This counter is a 64 bit version of vgRptrPortNormPriorityOctets. It should be used by Network Management protocols which support 64 bit counters (e.g. SNMPv2). This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aNormalPriorityOctetsReceived." ::= { vgRptrMonPortEntry 15 } vgRptrPortBroadcastFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of broadcast packets that have been received on this port. This counter is incremented by one for each readable frame received on this port whose destination MAC address is the broadcast address. Frames counted by this counter are also counted by vgRptrPortReadableFrames. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aBroadcastFramesReceived." ::= { vgRptrMonPortEntry 16 } vgRptrPortMulticastFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of multicast packets that have been received on this port. This counter is incremented by one for each readable frame received on this port whose destination MAC address has the group address bit set, but is not the broadcast address. Frames counted by this Flick Standards Track [Page 41] RFC 2266 IEEE 802.12 Repeater MIB January 1998 counter are also counted by vgRptrPortReadableFrames, but not by vgRptrPortBroadcastFrames. Note that when the value of the instance vgRptrInfoCurrentFramingType for the repeater that this port is associated with is equal to 'frameType88025', this count includes packets addressed to functional addresses. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aMulticastFramesReceived." ::= { vgRptrMonPortEntry 17 } vgRptrPortNullAddressedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of null addressed packets that have been received on this port. This counter is incremented by one for each frame received on this port with a destination MAC address consisting of all zero bits. Both void and training frames are included in this counter. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aNullAddressedFramesReceived." ::= { vgRptrMonPortEntry 18 } vgRptrPortIPMFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of the number of frames that have been received on this port with an invalid packet marker and no PMI errors. A repeater will write an invalid packet marker to the end of a frame containing errors as it is Flick Standards Track [Page 42] RFC 2266 IEEE 802.12 Repeater MIB January 1998 forwarded through the repeater to the other ports. This counter is incremented by one for each frame received on this port which has had an invalid packet marker added to the end of the frame. This counter indicates problems occurring in the domain of other repeaters, as opposed to problems with cables or devices directly attached to this repeater. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aIPMFramesReceived." ::= { vgRptrMonPortEntry 19 } vgRptrPortOversizeFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of oversize frames received on this port. This counter is incremented by one for each frame received on this port whose OctetCount is larger than the maximum legal frame size. The frame size which causes this counter to increment is dependent on the current value of vgRptrInfoCurrentFramingType for the repeater that the port is associated with. When vgRptrInfoCurrentFramingType is equal to frameType88023 this counter will increment for frames that are 1519 octets or larger. When vgRptrInfoCurrentFramingType is equal to frameType88025 this counter will increment for frames that are 4521 octets or larger. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aOversizeFramesReceived." ::= { vgRptrMonPortEntry 20 } Flick Standards Track [Page 43] RFC 2266 IEEE 802.12 Repeater MIB January 1998 vgRptrPortDataErrorFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a count of errored frames received on this port. This counter is incremented by one for each frame received on this port with any of the following errors: bad FCS (with no IPM), PMI errors (excluding frames with an IPM error as the only PMI error), or undersize (with no IPM). Does not include packets counted by vgRptrPortIPMFrames, vgRptrPortOversizeFrames, or vgRptrPortNullAddressedFrames. This counter indicates problems with cables or devices directly connected to this repeater, while vgRptrPortIPMFrames indicates problems occurring in the domain of other repeaters. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aDataErrorFramesReceived." ::= { vgRptrMonPortEntry 21 } vgRptrPortPriorityPromotions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one each time the priority promotion timer has expired on this port and a normal priority frame is priority promoted. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aPriorityPromotions." ::= { vgRptrMonPortEntry 22 } vgRptrPortTransitionToTrainings OBJECT-TYPE Flick Standards Track [Page 44] RFC 2266 IEEE 802.12 Repeater MIB January 1998 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented by one each time the vgRptrPortStatus object for this port transitions into the 'training' state. This counter may experience a discontinuity when the value of the corresponding instance of vgRptrPortLastChange changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aTransitionsIntoTraining." ::= { vgRptrMonPortEntry 23 } vgRptrPortLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last of the following occurred: 1) the agent cold- or warm-started; 2) the row for the port was created (such as when a device or module was added to the system); or 3) any condition that would cause one of the counters for the row to experience a discontinuity." ::= { vgRptrMonPortEntry 24 } vgRptrAddrTrack OBJECT IDENTIFIER ::= { vgRptrObjects 3 } vgRptrAddrTrackRptr OBJECT IDENTIFIER ::= { vgRptrAddrTrack 1 } -- Currently unused vgRptrAddrTrackGroup OBJECT IDENTIFIER ::= { vgRptrAddrTrack 2 } -- Currently unused vgRptrAddrTrackPort OBJECT IDENTIFIER ::= { vgRptrAddrTrack 3 } vgRptrAddrTrackTable OBJECT-TYPE Flick Standards Track [Page 45] RFC 2266 IEEE 802.12 Repeater MIB January 1998 SYNTAX SEQUENCE OF VgRptrAddrTrackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of address mapping information about the ports." ::= { vgRptrAddrTrackPort 1 } vgRptrAddrTrackEntry OBJECT-TYPE SYNTAX VgRptrAddrTrackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing address mapping information about a single port." INDEX { vgRptrGroupIndex, vgRptrPortIndex } ::= { vgRptrAddrTrackTable 1 } VgRptrAddrTrackEntry ::= SEQUENCE { vgRptrAddrLastTrainedAddress OCTET STRING, vgRptrAddrTrainedAddrChanges Counter32, vgRptrRptrDetectedDupAddress TruthValue, vgRptrMgrDetectedDupAddress TruthValue } vgRptrAddrLastTrainedAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 6)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the MAC address of the last station which succeeded in training on this port. A cascaded repeater may train using the null address. If no stations have succeeded in training on this port since the agent began monitoring the port activity, the agent shall return a string of length zero." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aLastTrainedAddress." ::= { vgRptrAddrTrackEntry 1 } vgRptrAddrTrainedAddrChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Flick Standards Track [Page 46] RFC 2266 IEEE 802.12 Repeater MIB January 1998 DESCRIPTION "This counter is incremented by one for each time that the vgRptrAddrLastTrainedAddress object for this port changes." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aTrainedAddressChanges." ::= { vgRptrAddrTrackEntry 2 } vgRptrRptrDetectedDupAddress OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to indicate that the repeater detected an error-free training frame on this port with a non-null source MAC address which matches the value of vgRptrAddrLastTrainedAddress of another active port in the same repeater. This is reset to 'false' when an error-free training frame is received with a non-null source MAC address which does not match vgRptrAddrLastTrainedAddress of another port which is active in the same repeater. For the cascade port, this object will be 'true' if the 'D' bit in the most recently received error-free training response frame was set, indicating the device at the other end of the link believes that this repeater's cascade port is using a duplicate address. This may be because the device at the other end of the link detected a duplicate address itself, or, if the other device is also a repeater, it could be because vgRptrMgrDetectedDupAddress was set to 'true' on the port that this repeater's cascade port is connected to." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aLocalRptrDetectedDupAddr." ::= { vgRptrAddrTrackEntry 3 } vgRptrMgrDetectedDupAddress OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object can be set by a management station Flick Standards Track [Page 47] RFC 2266 IEEE 802.12 Repeater MIB January 1998 when it detects that there is a duplicate MAC address. This object is OR'd with vgRptrRptrDetectedDupAddress to form the value of the 'D' bit in training response frames on this port. The purpose of this object is to provide a means for network management software to inform an end station that it is using a duplicate station address. Setting this object does not affect the current state of the link; the end station will not be informed of the duplicate address until it retrains for some reason. Note that regardless of its station address, the end station will not be able to train successfully until the network management software has set this object back to 'false'. Although this object exists on cascade ports, it does not perform any function since this repeater is the initiator of training on a cascade port." REFERENCE "IEEE Standard 802.12-1995, 13.2.4.5.1, aCentralMgmtDetectedDupAddr." ::= { vgRptrAddrTrackEntry 4 } vgRptrTraps OBJECT IDENTIFIER ::= { vgRptrMIB 2 } vgRptrTrapPrefix OBJECT IDENTIFIER ::= { vgRptrTraps 0 } vgRptrHealth NOTIFICATION-TYPE OBJECTS { vgRptrInfoOperStatus } STATUS current DESCRIPTION "A vgRptrHealth trap conveys information related to the operational state of a repeater. This trap is sent when the value of an instance of vgRptrInfoOperStatus changes. The vgRptrHealth trap is not sent as a result of powering up a repeater. The vgRptrHealth trap must contain the instance of the vgRptrInfoOperStatus object associated with the affected repeater. The agent must throttle the generation of consecutive vgRptrHealth traps so that there is at least a five-second gap between traps of this type. When traps are throttled, they are dropped, Flick Standards Track [Page 48] RFC 2266 IEEE 802.12 Repeater MIB January 1998 not queued for sending at a future time. (Note that 'generating' a trap means sending to all configured recipients.)" REFERENCE "IEEE 802.12, Layer Management, 13.2.4.2.3, nRepeaterHealth." ::= { vgRptrTrapPrefix 1 } vgRptrResetEvent NOTIFICATION-TYPE OBJECTS { vgRptrInfoOperStatus } STATUS current DESCRIPTION "A vgRptrResetEvent trap conveys information related to the operational state of a repeater. This trap is sent on completion of a repeater reset action. A repeater reset action is defined as a transition to its initial state as specified in clause 12 [IEEE Std 802.12] when triggered by a management command. The vgRptrResetEvent trap is not sent when the agent restarts and sends an SNMP coldStart or warmStart trap. The vgRptrResetEvent trap must contain the instance of the vgRptrInfoOperStatus object associated with the affected repeater. The agent must throttle the generation of consecutive vgRptrResetEvent traps so that there is at least a five-second gap between traps of this type. When traps are throttled, they are dropped, not queued for sending at a future time. (Note that 'generating' a trap means sending to all configured recipients.)" REFERENCE "IEEE 802.12, Layer Management, 13.2.4.2.3, nRepeaterReset." ::= { vgRptrTrapPrefix 2 } -- conformance information vgRptrConformance OBJECT IDENTIFIER ::= { vgRptrMIB 3 } vgRptrCompliances OBJECT IDENTIFIER ::= { vgRptrConformance 1 } vgRptrGroups OBJECT IDENTIFIER ::= { vgRptrConformance 2 } Flick Standards Track [Page 49] RFC 2266 IEEE 802.12 Repeater MIB January 1998 -- compliance statements vgRptrCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for managed 802.12 repeaters." MODULE -- this module MANDATORY-GROUPS { vgRptrConfigGroup, vgRptrStatsGroup, vgRptrAddrGroup, vgRptrNotificationsGroup } GROUP vgRptrStats64Group DESCRIPTION "Implementation of this group is recommended for systems which can support Counter64." OBJECT vgRptrInfoDesiredFramingType MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required in a repeater system that does not support configuration of framing types." MODULE SNMP-REPEATER-MIB GROUP snmpRptrGrpRptrAddrSearch DESCRIPTION "Implementation of this group is recommended for systems which have the necessary instrumentation to search all incoming data streams for a particular source MAC address." ::= { vgRptrCompliances 1 } -- units of conformance vgRptrConfigGroup OBJECT-GROUP OBJECTS { vgRptrInfoMACAddress, vgRptrInfoCurrentFramingType, vgRptrInfoDesiredFramingType, vgRptrInfoFramingCapability, vgRptrInfoTrainingVersion, vgRptrInfoOperStatus, vgRptrInfoReset, vgRptrInfoLastChange, vgRptrGroupObjectID, Flick Standards Track [Page 50] RFC 2266 IEEE 802.12 Repeater MIB January 1998 vgRptrGroupOperStatus, vgRptrGroupPortCapacity, vgRptrGroupCablesBundled, vgRptrPortType, vgRptrPortAdminStatus, vgRptrPortOperStatus, vgRptrPortSupportedPromiscMode, vgRptrPortSupportedCascadeMode, vgRptrPortAllowedTrainType, vgRptrPortLastTrainConfig, vgRptrPortTrainingResult, vgRptrPortPriorityEnable, vgRptrPortRptrInfoIndex } STATUS current DESCRIPTION "A collection of objects for managing the status and configuration of IEEE 802.12 repeaters." ::= { vgRptrGroups 1 } vgRptrStatsGroup OBJECT-GROUP OBJECTS { vgRptrMonTotalReadableFrames, vgRptrMonTotalReadableOctets, vgRptrMonReadableOctetRollovers, vgRptrMonTotalErrors, vgRptrPortReadableFrames, vgRptrPortReadableOctets, vgRptrPortReadOctetRollovers, vgRptrPortUnreadableOctets, vgRptrPortUnreadOctetRollovers, vgRptrPortHighPriorityFrames, vgRptrPortHighPriorityOctets, vgRptrPortHighPriOctetRollovers, vgRptrPortNormPriorityFrames, vgRptrPortNormPriorityOctets, vgRptrPortNormPriOctetRollovers, vgRptrPortBroadcastFrames, vgRptrPortMulticastFrames, vgRptrPortNullAddressedFrames, vgRptrPortIPMFrames, vgRptrPortOversizeFrames, vgRptrPortDataErrorFrames, vgRptrPortPriorityPromotions, vgRptrPortTransitionToTrainings, vgRptrPortLastChange } STATUS current Flick Standards Track [Page 51] RFC 2266 IEEE 802.12 Repeater MIB January 1998 DESCRIPTION "A collection of objects for providing statistics for IEEE 802.12 repeaters. Systems which support Counter64 should also implement vgRptrStats64Group." ::= { vgRptrGroups 2 } vgRptrStats64Group OBJECT-GROUP OBJECTS { vgRptrMonHCTotalReadableOctets, vgRptrPortHCReadableOctets, vgRptrPortHCUnreadableOctets, vgRptrPortHCHighPriorityOctets, vgRptrPortHCNormPriorityOctets } STATUS current DESCRIPTION "A collection of objects for providing statistics for IEEE 802.12 repeaters in a system that supports Counter64." ::= { vgRptrGroups 3 } vgRptrAddrGroup OBJECT-GROUP OBJECTS { vgRptrAddrLastTrainedAddress, vgRptrAddrTrainedAddrChanges, vgRptrRptrDetectedDupAddress, vgRptrMgrDetectedDupAddress } STATUS current DESCRIPTION "A collection of objects for tracking addresses on IEEE 802.12 repeaters." ::= { vgRptrGroups 4 } vgRptrNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { vgRptrHealth, vgRptrResetEvent } STATUS current DESCRIPTION "A collection of notifications used to indicate 802.12 repeater general status changes." ::= { vgRptrGroups 5 } END Flick Standards Track [Page 52] RFC 2266 IEEE 802.12 Repeater MIB January 1998 4. Acknowledgements This document was produced by the IETF 100VG-AnyLAN Working Group, whose efforts were greatly advanced by the contributions of the following people: Paul Chefurka Bob Faulk Jeff Johnson Karen Kimball David Lapp Jason Spofford Kaj Tesink This document is based on the work of IEEE 802.12. 5. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824 (December, 1987). [2] 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. [3] 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. [4] 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. [5] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", STD 17, RFC 1213, March 1991. [6] IEEE, "Demand Priority Access Method, Physical Layer and Repeater Specifications for 100 Mb/s Operation", IEEE Standard 802.12-1995" Flick Standards Track [Page 53] RFC 2266 IEEE 802.12 Repeater MIB January 1998 [7] de Graaf, K., D. Romascanu, D. McMaster, and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices", RFC 2108, 3Com Corporation, Madge Networks (Israel) Ltd., Cisco Systems, Inc., February, 1997. [8] McAnally, G., Gilbert, D. and J. Flick, "Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework", RFC 1988, August 1996. [9] Hewlett-Packard Company, US Patents 5,293,635 and 5,421,024. 6. Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information should be employed in such environments. The method for this authentication is a function of the SNMP Administrative Framework, and has not been expanded by this MIB. Several objects in the vgRptrConfigGroup allow write access. Setting these objects can have a serious effect on the operation of the network, including modifying the framing type of the network, resetting the repeater, enabling and disabling individual ports, and modifying the allowed capabilities of end stations attached to each port. It is recommended that implementers seriously consider whether set operations should be allowed without providing, at a minimum, authentication of request origin. One particular object in this MIB, vgRptrPortAllowedTrainType, is considered significant for providing operational security in an 802.12 network. It is recommended that network administrators configure this object to the 'allowEndNodesOnly' value on all ports except ports which the administrator knows are attached to cascaded repeaters or devices which require promiscuous receive capability (bridges, switches, RMON probes, etc.). This will prevent unauthorized users from extending the network (by attaching cascaded repeaters or bridges) without the administrator's knowledge, and will prevent unauthorized end nodes from listening promiscuously to network traffic. Flick Standards Track [Page 54] RFC 2266 IEEE 802.12 Repeater MIB January 1998 7. Author's Address John Flick Hewlett Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 Phone: +1 916 785 4018 Email: johnf@hprnd.rose.hp.com Flick Standards Track [Page 55] RFC 2266 IEEE 802.12 Repeater MIB January 1998 8. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Flick Standards Track [Page 56] snmp-mibs-downloader-1.1/mibrfcs/rfc2287.txt0000644000000000000000000027764211402176071015606 0ustar Network Working Group C. Krupczak Request for Comments: 2287 Empire Technologies, Inc. Category: Standards Track J. Saperia BGS Systems Inc. February 1998 Definitions of System-Level Managed Objects for Applications 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Table of Contents 1 Abstract .............................................. 2 2 The SNMPv2 Network Management Framework ............... 2 2.1 Object Definitions .................................. 2 3 Overview .............................................. 3 4 Architecture for Application Management ............... 3 5 The Structure of the MIB .............................. 4 5.1 System Application Installed Group .................. 5 5.2 System Application Run Group ........................ 5 5.2.1 sysApplRunTable and sysApplPastRunTable ........... 5 5.2.2 sysApplElmtRunTable and sysApplElmtPastRunTable .................................................... 6 5.3 System Application Map Group ........................ 7 6 Definitions ........................................... 7 7 Implementation Issues ................................. 40 7.1 Implementation with Polling Agents .................. 40 7.2 sysApplElmtPastRunTable Entry Collisions ............ 40 8 Security Considerations ............................... 41 9 Acknowledgements ...................................... 42 10 Author's Address ..................................... 42 11 References ........................................... 42 12 Full Copyright Statement ............................. 44 Krupczak & Saperia Standards Track [Page 1] RFC 2287 MIB for Applications February 1998 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. More specifically, the managed objects are restricted to information that can be determined from the system itself and which does not require special instrumentation within the applications to make the information available. This memo does not specify a standard for the Internet community. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of the following major components: o RFC 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) [2] o RFC 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) [3] o RFC 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) [4] o RFC 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) [5] o RFC 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) [6] o RFC 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) [7] o RFC 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework [8] 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) [1], defined in the Structure of Management Information (SMI) (See RFC Krupczak & Saperia Standards Track [Page 2] RFC 2287 MIB for Applications February 1998 1902 [2]). 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 object descriptor, to refer to the object type. 3. Overview The primary purpose of computing technologies is the execution of application software. These applications, typically specialized collections of executables, files, and interprocess communications, exist to solve business, scientific or other "problems". The configuration, fault detection, performance monitoring and control of application software across its life on a host computer is of great economic importance. For the purposes of our work, we define applications as one or more units of executable code and other resources, installed on a single host system that a manager may think of as a single object for management purposes. The information described by the objects in the System Application MIB support configuration, fault, and performance management; they represent some of the basic attributes of application software from a systems (non-application specific) perspective. The information allows for the description of applications as collections of executables and files installed and executing on a host computer. This memo is concerned primarily with, and defines a model for, application information resident on a host computer which can be determined from the system itself, and not from the individual applications. This system-level view of applications is designed to provide information about software applications installed and running on the host system without requiring modifications and code additions to the applications themselves. This approach was taken to insure ease and speed of implementation, while allowing room for future growth. 4. Architecture for Application Management In the area of application management it is fully acknowledged and even expected that additional MIB modules will be defined over time to provide an even greater level of detail regarding applications. This MIB module presents the most general case: a set of management objects for providing generic information about applications and whose object values can be determined from the computer system itself without requiring instrumentation within the application. Krupczak & Saperia Standards Track [Page 3] RFC 2287 MIB for Applications February 1998 A finer-grained level of detail is planned for the future "appl MIB" which will be a common set of management objects relating to generic applications, but which require some type of instrumentation in the application in order to be determined. Since the applmib MIB module will provide a finer level of detail, any connection to the sysAppl MIB should be made by having references from the more detailed appl MIB back to the more generic sysAppl MIB. Likewise, as application- specific MIB modules such as the WWW MIB, etc., are developed over time, these more specific MIBs should reference back to the more generic MIBs. While this MIB module does not attempt to provide every detailed piece of information for managing applications, it does provide a basic systems-level view of the applications and their components on a single host system. 5. The Structure of the MIB The System Application MIB structure models application packages as a whole, and also models the individual elements (files and executables) which collectively form an application. The MIB is structured to model information regarding installed application packages and the elements which make up each application package. The MIB also models activity information on applications (and in turn, their components) that are running or have previously run on the host system. In modeling applications and their elements, this MIB module provides the necessary link for associating executing processes with the applications of which they are a part. The objects are arranged into the following groups: - System Application Installed Group - sysApplInstallPkgTable - sysApplInstallElmtTable - System Application Run Group - sysApplRunTable - sysApplPastRunTable - sysApplElmtRunTable - sysApplElmtPastRunTable - (scalars for restricting table sizes) - System Application Map Group - sysApplMapTable Krupczak & Saperia Standards Track [Page 4] RFC 2287 MIB for Applications February 1998 As can be seen by the arrangement above, for each category, the MIB first treats an application package as a whole, and then breaks down the package to provide information about each of the elements (executable and non-executable files) of the package. 5.1. System Application Installed Group The System Application Installed group consists of two tables. Through these two tables, administrators will be able to determine which applications have been installed on a system and what their constituent components are. The first table, the sysApplInstallPkgTable, lists the application packages installed on a particular host. The second, the sysApplInstallElmtTable, provides information regarding the executables and non-executable files, or elements, which collectively compose an application. NOTE: This MIB is intended to work with applications that have been installed on a particular host, where "installed" means that the existence of the application and the association between an application and its component files can be discovered without requiring additional instrumentation of the application itself. This may require that certain conventions be used, such as using a central software installation mechanism or registry, when installing application packages. For example, many UNIX systems utilize a "pkgadd" utility to track installed application packages, while many PC systems utilize a global registry. 5.2. System Application Run Group This group models activity information for applications that have been invoked and are either currently running, or have previously run, on the host system. Likewise, the individual elements of an invoked application are also modeled to show currently running processes, and processes that have run in the past. This information is modeled using two pairs of tables: a pair of tables for currently running applications and past run applications, and a pair of tables for the currently running elements and the past run elements. Seven scalars are also defined to control the size of the past run tables. 5.2.1. sysApplRunTable and sysApplPastRunTable The sysApplRunTable and the sysApplPastRunTable make up the first pair of tables. The sysApplRunTable contains the application instances which are currently running on the host. Each time an application is invoked, a new entry is created in the sysApplRunTable to provide information about that particular invocation of the application. An entry will remain in this table until the Krupczak & Saperia Standards Track [Page 5] RFC 2287 MIB for Applications February 1998 application instance terminates, at which time the entry will be deleted from the sysApplRunTable and placed in the sysApplPastRunTable. The sysApplPastRunTable maintains a history of instances of applications which have previously executed on the host. Entries to this table are made when an invoked application from the sysApplRunTable terminates; the table entry which represents the application instance is removed from the SysApplRunTable and a corresponding entry is added to the sysApplPastRunTable. Because the sysApplPastRunTable will continuously grow as applications are executed and terminate, two scalars are defined to control the aging-out of table entries. The value of sysApplPastRunMaxRows specifies the maximum number of entries the table may contain, while the sysApplPastRunTblTimeLimit specifies the maximum age of the table entries. Oldest entries are removed first. It is important to note that the sysApplRunTable and sysApplPastRunTable contain entries for each INVOCATION of an application. A single application package might be invoked multiple times; each invocation is properly recorded by a separate entry in the sysApplRunTable. In order to implement this group, the agent must be able to recognize that an application has been invoked, and be able to determine when that invocation terminates. This poses a complex problem since a single application invocation may involve numerous processes, some of which may be required to remain running throughout the duration of the application, others which might come and go. The sysApplInstallElmtRole columnar object in the sysApplInstallElmtTable is meant to assist in this task by indicating which element is the application's primary executable, which elements must be running in order for the application to be running, which elements are dependent on required elements, etc. See the description of sysApplInstallElmtRole for more details. 5.2.2. sysApplElmtRunTable and sysApplElmtPastRunTable While the sysApplRunTable and sysApplPastRunTable focus on applications as a whole, the sysApplElmtRunTable and sysApplElmtPastRunTable provide information regarding an application's executable elements, (processes), which are either currently executing or have executed in the past. The sysApplElmtRunTable contains an entry for every process currently running on the host. An entry is created in this table for each process at the time it is started, and will remain in the table until Krupczak & Saperia Standards Track [Page 6] RFC 2287 MIB for Applications February 1998 the process terminates. Note that in order to provide complete information on the load on the system, this table lists EVERY running process, not just those processes that are running as part of an identified application. However, when processes terminate, only information from entries corresponding to elements of an identified application are moved to the sysApplElmtPastRunTable. The sysApplElmtPastRunTable maintains a history of processes which have previously executed on the host as part of an application. When a process from the sysApplElmtRunTable terminates, the entry's information is moved to this sysApplElmtPastRunTable provided that the process was part of an identified application. If the process cannot be associated with any 'parent' application, then it is simply removed from the sysApplElmtRunTable. This allows for processes like 'ps' or 'grep' to show up in the sysApplElmtRunTable, (where they are consuming resources and are thus "interesting"), but not in the sysApplElmtPastRunTable. Because the sysApplElmtPastRunTable will continuously grow as processes are executed and terminate, two scalars are defined to control the aging-out of table entries. The value of sysApplElmtPastRunMaxRows specifies the maximum number of entries the table may contain, while the sysApplElmtPastRunTblTimeLimit specifies the maximum age of the table entries. Oldest entries are removed first. 5.3. System Application Map Group The System Application Map group contains a single table, the sysApplMapTable, whose sole purpose is to provide a backwards mapping for determining the invoked application, installed element, and installed application package given a known process identification number. 6. Definitions SYSAPPL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, TimeTicks, Counter32, Gauge32 FROM SNMPv2-SMI DateAndTime, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2 FROM SNMPv2-SMI; Krupczak & Saperia Standards Track [Page 7] RFC 2287 MIB for Applications February 1998 -- System Application MIB sysApplMIB MODULE-IDENTITY LAST-UPDATED "9710200000Z" ORGANIZATION "IETF Applications MIB Working Group" CONTACT-INFO "Cheryl Krupczak (Editor, WG Advisor) Postal: Empire Technologies, Inc. 541 Tenth Street NW Suite 169 Atlanta, GA 30318 USA Phone: (770) 384-0184 Email: cheryl@empiretech.com Jon Saperia (WG Chair) Postal: BGS Systems, Inc. One First Avenue Waltham, MA 02254-9111 USA Phone: (617) 891-0000 Email: saperia@networks.bgs.com" DESCRIPTION "The MIB module defines management objects that model applications as collections of executables and files installed and executing on a host system. The MIB presents a system-level view of applications; i.e., objects in this MIB are limited to those attributes that can typically be obtained from the system itself without adding special instrumentation to the applications." ::= { mib-2 54 } sysApplOBJ OBJECT IDENTIFIER ::= { sysApplMIB 1 } sysApplInstalled OBJECT IDENTIFIER ::= { sysApplOBJ 1 } sysApplRun OBJECT IDENTIFIER ::= { sysApplOBJ 2 } sysApplMap OBJECT IDENTIFIER ::= { sysApplOBJ 3 } sysApplNotifications OBJECT IDENTIFIER ::= { sysApplMIB 2 } sysApplConformance OBJECT IDENTIFIER ::= { sysApplMIB 3 } -- Textual Conventions RunState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes the current execution state of a running application or process. The possible values are: Krupczak & Saperia Standards Track [Page 8] RFC 2287 MIB for Applications February 1998 running(1), runnable(2), - waiting for a resource (CPU, etc.) waiting(3), - waiting for an event exiting(4), other(5) - other invalid state" SYNTAX INTEGER { running (1), runnable (2), -- waiting for resource (CPU, etc.) waiting (3), -- waiting for event exiting (4), other (5) -- other invalid state } LongUtf8String ::= TEXTUAL-CONVENTION DISPLAY-HINT "1024a" STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044 [10]. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding." SYNTAX OCTET STRING (SIZE (0..1024)) Utf8String ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044 [10]. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding." SYNTAX OCTET STRING (SIZE (0..255)) -- sysApplInstalled Group -- This group provides information about application packages -- that have been installed on the host computer. The group -- contains two tables. The first, the sysApplInstallPkgTable, -- describes the application packages, the second, the -- sysApplInstallElmtTable, describes the constituent elements -- (files and executables) which compose an application package. Krupczak & Saperia Standards Track [Page 9] RFC 2287 MIB for Applications February 1998 -- -- In order to appear in this group, an application and its -- component files must be discoverable by the system itself, -- possibly through some type of software installation mechanism -- or registry. -- sysApplInstallPkgTable -- The system installed application packages table provides -- information on the software packages installed on a system. -- These packages may consist of many different files including -- executable and non-executable files. sysApplInstallPkgTable OBJECT-TYPE SYNTAX SEQUENCE OF SysApplInstallPkgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table listing the software application packages installed on a host computer. In order to appear in this table, it may be necessary for the application to be installed using some type of software installation mechanism or global registry so that its existence can be detected by the agent implementation." ::= { sysApplInstalled 1 } sysApplInstallPkgEntry OBJECT-TYPE SYNTAX SysApplInstallPkgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The logical row describing an installed application package." INDEX { sysApplInstallPkgIndex } ::= { sysApplInstallPkgTable 1 } SysApplInstallPkgEntry ::= SEQUENCE { sysApplInstallPkgIndex Unsigned32, sysApplInstallPkgManufacturer Utf8String, sysApplInstallPkgProductName Utf8String, sysApplInstallPkgVersion Utf8String, sysApplInstallPkgSerialNumber Utf8String, sysApplInstallPkgDate DateAndTime, sysApplInstallPkgLocation LongUtf8String } sysApplInstallPkgIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) Krupczak & Saperia Standards Track [Page 10] RFC 2287 MIB for Applications February 1998 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer used only for indexing purposes. Generally monotonically increasing from 1 as new applications are installed. The value for each installed application must remain constant at least from one re-initialization of the network management entity which implements this MIB module to the next re-initialization. The specific value is meaningful only within a given SNMP entity. A sysApplInstallPkgIndex value must not be re-used until the next agent entity restart in the event the installed application entry is deleted." ::= { sysApplInstallPkgEntry 1 } sysApplInstallPkgManufacturer OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The Manufacturer of the software application package." ::= { sysApplInstallPkgEntry 2 } sysApplInstallPkgProductName OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The name assigned to the software application package by the Manufacturer." ::= { sysApplInstallPkgEntry 3 } sysApplInstallPkgVersion OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The version number assigned to the application package by the manufacturer of the software." ::= { sysApplInstallPkgEntry 4 } sysApplInstallPkgSerialNumber OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current Krupczak & Saperia Standards Track [Page 11] RFC 2287 MIB for Applications February 1998 DESCRIPTION "The serial number of the software assigned by the manufacturer." ::= { sysApplInstallPkgEntry 5 } sysApplInstallPkgDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time this software application was installed on the host." ::= { sysApplInstallPkgEntry 6 } sysApplInstallPkgLocation OBJECT-TYPE SYNTAX LongUtf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The complete path name where the application package is installed. For example, the value would be '/opt/MyapplDir' if the application package was installed in the /opt/MyapplDir directory." ::= { sysApplInstallPkgEntry 7 } -- sysApplInstallElmtTable -- The table describing the individual application package -- elements (files and executables) installed on the host computer. sysApplInstallElmtTable OBJECT-TYPE SYNTAX SEQUENCE OF SysApplInstallElmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table details the individual application package elements (files and executables) which comprise the applications defined in the sysApplInstallPkg Table. Each entry in this table has an index to the sysApplInstallPkg table to identify the application package of which it is a part. As a result, there may be many entries in this table for each instance in the sysApplInstallPkg Table. Table entries are indexed by sysApplInstallPkgIndex, sysApplInstallElmtIndex to facilitate retrieval of all elements associated with a particular installed application package." Krupczak & Saperia Standards Track [Page 12] RFC 2287 MIB for Applications February 1998 ::= { sysApplInstalled 2 } sysApplInstallElmtEntry OBJECT-TYPE SYNTAX SysApplInstallElmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The logical row describing an element of an installed application. The element may be an executable or non-executable file." INDEX {sysApplInstallPkgIndex, sysApplInstallElmtIndex} ::= { sysApplInstallElmtTable 1 } SysApplInstallElmtEntry ::= SEQUENCE { sysApplInstallElmtIndex Unsigned32, sysApplInstallElmtName Utf8String, sysApplInstallElmtType INTEGER, sysApplInstallElmtDate DateAndTime, sysApplInstallElmtPath LongUtf8String, sysApplInstallElmtSizeHigh Unsigned32, sysApplInstallElmtSizeLow Unsigned32, sysApplInstallElmtRole BITS, sysApplInstallElmtModifyDate DateAndTime, sysApplInstallElmtCurSizeHigh Unsigned32, sysApplInstallElmtCurSizeLow Unsigned32 } sysApplInstallElmtIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used for indexing. The value of this index is unique among all rows in this table that exist or have existed since the last agent restart." ::= { sysApplInstallElmtEntry 1 } sysApplInstallElmtName OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this element which is contained in the application." ::= { sysApplInstallElmtEntry 2 } Krupczak & Saperia Standards Track [Page 13] RFC 2287 MIB for Applications February 1998 sysApplInstallElmtType OBJECT-TYPE SYNTAX INTEGER { unknown(1), nonexecutable(2), operatingSystem(3), -- executable deviceDriver(4), -- executable application(5) -- executable } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of element that is part of the installed application." ::= { sysApplInstallElmtEntry 3 } sysApplInstallElmtDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time that this component was installed on the system." ::= { sysApplInstallElmtEntry 4 } sysApplInstallElmtPath OBJECT-TYPE SYNTAX LongUtf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The full directory path where this element is installed. For example, the value would be '/opt/EMPuma/bin' for an element installed in the directory '/opt/EMPuma/bin'. Most application packages include information about the elements contained in the package. In addition, elements are typically installed in sub-directories under the package installation directory. In cases where the element path names are not included in the package information itself, the path can usually be determined by a simple search of the sub-directories. If the element is not installed in that location and there is no other information available to the agent implementation, then the path is unknown and null is returned." ::= { sysApplInstallElmtEntry 5} sysApplInstallElmtSizeHigh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Krupczak & Saperia Standards Track [Page 14] RFC 2287 MIB for Applications February 1998 DESCRIPTION "The installed file size in 2^32 byte blocks. This is the size of the file on disk immediately after installation. For example, for a file with a total size of 4,294,967,296 bytes, this variable would have a value of 1; for a file with a total size of 4,294,967,295 bytes this variable would be 0." ::= { sysApplInstallElmtEntry 6 } sysApplInstallElmtSizeLow OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The installed file size modulo 2^32 bytes. This is the size of the file on disk immediately after installation. For example, for a file with a total size of 4,294,967,296 bytes this variable would have a value of 0; for a file with a total size of 4,294,967,295 bytes this variable would be 4,294,967,295." ::= { sysApplInstallElmtEntry 7 } sysApplInstallElmtRole OBJECT-TYPE SYNTAX BITS { executable(0), -- An application may have one or -- more executable elements. The rest of the -- bits have no meaning if the element is not -- executable. exclusive(1), -- Only one copy of an exclusive element may be -- running per invocation of the running -- application. primary(2), -- The primary executable. An application can -- have one, and only one element that is designated -- as the primary executable. The execution of -- this element constitutes an invocation of -- the application. This is used by the agent -- implementation to determine the initiation of -- an application. The primary executable must -- remain running long enough for the agent -- implementation to detect its presence. required(3), -- An application may have zero or more required -- elements. All required elements must be running Krupczak & Saperia Standards Track [Page 15] RFC 2287 MIB for Applications February 1998 -- in order for the application to be judged to be -- running and healthy. dependent(4), -- An application may have zero or more -- dependent elements. Dependent elements may -- not be running unless required elements are. unknown(5) -- Default value for the case when an operator -- has not yet assigned one of the other values. -- When set, bits 1, 2, 3, and 4 have no meaning. } MAX-ACCESS read-write STATUS current DESCRIPTION "An operator assigned value used in the determination of application status. This value is used by the agent to determine both the mapping of started processes to the initiation of an application, as well as to allow for a determination of application health. The default value, unknown(5), is used when an operator has not yet assigned one of the other values. If unknown(5) is set, bits 1 - 4 have no meaning. The possible values are: executable(0), An application may have one or more executable elements. The rest of the bits have no meaning if the element is not executable. exclusive(1), Only one copy of an exclusive element may be running per invocation of the running application. primary(2), The primary executable. An application can have one, and only one element that is designated as the primary executable. The execution of this element constitutes an invocation of the application. This is used by the agent implementation to determine the initiation of an application. The primary executable must remain running long enough for the agent implementation to detect its presence. required(3), An application may have zero or more required elements. All required elements must be running in order for the application to be judged to be running and healthy. dependent(4), Krupczak & Saperia Standards Track [Page 16] RFC 2287 MIB for Applications February 1998 An application may have zero or more dependent elements. Dependent elements may not be running unless required elements are. unknown(5) Default value for the case when an operator has not yet assigned one of the other values. When set, bits 1, 2, 3, and 4 have no meaning. sysApplInstallElmtRole is used by the agent implementation in determining the initiation of an application, the current state of a running application (see sysApplRunCurrentState), when an application invocation is no longer running, and the exit status of a terminated application invocation (see sysApplPastRunExitState)." DEFVAL { { unknown } } ::= { sysApplInstallElmtEntry 8 } sysApplInstallElmtModifyDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time that this element was last modified. Modification of the sysApplInstallElmtRole columnar object does NOT constitute a modification of the element itself and should not affect the value of this object." ::= { sysApplInstallElmtEntry 9 } sysApplInstallElmtCurSizeHigh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current file size in 2^32 byte blocks. For example, for a file with a total size of 4,294,967,296 bytes, this variable would have a value of 1; for a file with a total size of 4,294,967,295 bytes this variable would be 0." ::= { sysApplInstallElmtEntry 10 } sysApplInstallElmtCurSizeLow OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current file size modulo 2^32 bytes. For example, for a file with a total size of 4,294,967,296 Krupczak & Saperia Standards Track [Page 17] RFC 2287 MIB for Applications February 1998 bytes this variable would have a value of 0; for a file with a total size of 4,294,967,295 bytes this variable would be 4,294,967,295." ::= { sysApplInstallElmtEntry 11 } -- sysApplRun Group -- This group models activity information for applications -- that have been invoked and are either currently running, -- or have previously run on the host system. Likewise, -- the individual elements of an invoked application are -- also modeled to show currently running processes, and -- processes that have run in the past. -- sysApplRunTable -- The sysApplRunTable contains the application instances -- which are currently running on the host. Since a single -- application might be invoked multiple times, an entry is -- added to this table for each INVOCATION of an application. -- The table is indexed by sysApplInstallPkgIndex, sysApplRunIndex -- to enable managers to easily locate all invocations of -- a particular application package. sysApplRunTable OBJECT-TYPE SYNTAX SEQUENCE OF SysApplRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table describes the applications which are executing on the host. Each time an application is invoked, an entry is created in this table. When an application ends, the entry is removed from this table and a corresponding entry is created in the SysApplPastRunTable. A new entry is created in this table whenever the agent implementation detects a new running process that is an installed application element whose sysApplInstallElmtRole designates it as being the application's primary executable (sysApplInstallElmtRole = primary(2) ). The table is indexed by sysApplInstallPkgIndex, sysApplRunIndex to enable managers to easily locate all invocations of a particular application package." ::= { sysApplRun 1 } sysApplRunEntry OBJECT-TYPE SYNTAX SysApplRunEntry Krupczak & Saperia Standards Track [Page 18] RFC 2287 MIB for Applications February 1998 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The logical row describing an application which is currently running on this host." INDEX { sysApplInstallPkgIndex, sysApplRunIndex } ::= { sysApplRunTable 1 } SysApplRunEntry ::= SEQUENCE { sysApplRunIndex Unsigned32, sysApplRunStarted DateAndTime, sysApplRunCurrentState RunState } sysApplRunIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Part of the index for this table. An arbitrary integer used only for indexing purposes. Generally monotonically increasing from 1 as new applications are started on the host, it uniquely identifies application invocations. The numbering for this index increases by 1 for each INVOCATION of an application, regardless of which installed application package this entry represents a running instance of. An example of the indexing for a couple of entries is shown below. : sysApplRunStarted.17.14 sysApplRunStarted.17.63 sysApplRunStarted.18.13 : In this example, the agent has observed 12 application invocations when the application represented by entry 18 in the sysApplInstallPkgTable is invoked. The next invocation detected by the agent is an invocation of installed application package 17. Some time later, installed application 17 is invoked a second time. NOTE: this index is not intended to reflect a real-time (wall clock time) ordering of application invocations; Krupczak & Saperia Standards Track [Page 19] RFC 2287 MIB for Applications February 1998 it is merely intended to uniquely identify running instances of applications. Although the sysApplInstallPkgIndex is included in the INDEX clause for this table, it serves only to ease searching of this table by installed application and does not contribute to uniquely identifying table entries." ::= { sysApplRunEntry 1 } sysApplRunStarted OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time that the application was started." ::= { sysApplRunEntry 2 } sysApplRunCurrentState OBJECT-TYPE SYNTAX RunState MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the running application instance. The possible values are running(1), runnable(2) but waiting for a resource such as CPU, waiting(3) for an event, exiting(4), or other(5). This value is based on an evaluation of the running elements of this application instance (see sysApplElmRunState) and their Roles as defined by sysApplInstallElmtRole. An agent implementation may detect that an application instance is in the process of exiting if one or more of its REQUIRED elements are no longer running. Most agent implementations will wait until a second internal poll has been completed to give the system time to start REQUIRED elements before marking the application instance as exiting." ::= { sysApplRunEntry 3 } -- sysApplPastRunTable -- The sysApplPastRunTable provides a history of applications -- previously run on the host computer. Entries are removed from -- the sysApplRunTable and corresponding entries are added to this -- table when an application becomes inactive. Entries remain in -- this table until they are aged out when either the table size -- reaches a maximum as determined by the sysApplPastRunMaxRows, -- or when an entry has aged to exceed a time limit as set be -- sysApplPastRunTblTimeLimit. -- -- When aging out entries, the oldest entry, as determined by Krupczak & Saperia Standards Track [Page 20] RFC 2287 MIB for Applications February 1998 -- the value of sysApplPastRunTimeEnded, will be removed first. sysApplPastRunTable OBJECT-TYPE SYNTAX SEQUENCE OF SysApplPastRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A history of the applications that have previously run on the host computer. An entry's information is moved to this table from the sysApplRunTable when the invoked application represented by the entry ceases to be running. An agent implementation can determine that an application invocation is no longer running by evaluating the running elements of the application instance and their Roles as defined by sysApplInstallElmtRole. Obviously, if there are no running elements for the application instance, then the application invocation is no longer running. If any one of the REQUIRED elements is not running, the application instance may be in the process of exiting. Most agent implementations will wait until a second internal poll has been completed to give the system time to either restart partial failures or to give all elements time to exit. If, after the second poll, there are REQUIRED elements that are not running, then the application instance may be considered by the agent implementation to no longer be running. Entries remain in the sysApplPastRunTable until they are aged out when either the table size reaches a maximum as determined by the sysApplPastRunMaxRows, or when an entry has aged to exceed a time limit as set by sysApplPastRunTblTimeLimit. Entries in this table are indexed by sysApplInstallPkgIndex, sysApplPastRunIndex to facilitate retrieval of all past run invocations of a particular installed application." ::= { sysApplRun 2 } sysApplPastRunEntry OBJECT-TYPE SYNTAX SysApplPastRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The logical row describing an invocation of an application which was previously run and has terminated. The entry is basically copied from the sysApplRunTable when the application instance terminates. Hence, the entry's Krupczak & Saperia Standards Track [Page 21] RFC 2287 MIB for Applications February 1998 value for sysApplPastRunIndex is the same as its value was for sysApplRunIndex." INDEX { sysApplInstallPkgIndex, sysApplPastRunIndex } ::= { sysApplPastRunTable 1 } SysApplPastRunEntry ::= SEQUENCE { sysApplPastRunIndex Unsigned32, sysApplPastRunStarted DateAndTime, sysApplPastRunExitState INTEGER, sysApplPastRunTimeEnded DateAndTime } sysApplPastRunIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Part of the index for this table. An integer matching the value of the removed sysApplRunIndex corresponding to this row." ::= { sysApplPastRunEntry 1 } sysApplPastRunStarted OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time that the application was started." ::= { sysApplPastRunEntry 2 } sysApplPastRunExitState OBJECT-TYPE SYNTAX INTEGER { complete (1), -- normal exit at sysApplRunTimeEnded failed (2), -- abnormal exit other (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the application instance when it terminated. This value is based on an evaluation of the running elements of an application and their Roles as defined by sysApplInstallElmtRole. An application instance is said to have exited in a COMPLETE state and its entry is removed from the sysApplRunTable and added to the sysApplPastRunTable when the agent detects that ALL elements of an application invocation are no longer running. Most agent implementations will wait until a second internal poll has been completed to Krupczak & Saperia Standards Track [Page 22] RFC 2287 MIB for Applications February 1998 give the system time to either restart partial failures or to give all elements time to exit. A failed state occurs if, after the second poll, any elements continue to run but one or more of the REQUIRED elements are no longer running. All other combinations MUST be defined as OTHER." ::= { sysApplPastRunEntry 3 } sysApplPastRunTimeEnded OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The DateAndTime the application instance was determined to be no longer running." ::= { sysApplPastRunEntry 4 } -- sysApplElmtRunTable -- The sysApplElmtRunTable contains an entry for each process that -- is currently running on the host. An entry is created in -- this table for each process at the time it is started, and will -- remain in the table until the process terminates. -- -- The table is indexed by sysApplElmtRunInstallPkg, -- sysApplElmtRunInvocID, and sysApplElmtRunIndex to make it easy -- to locate all running elements of a particular invoked application -- which has been installed on the system. sysApplElmtRunTable OBJECT-TYPE SYNTAX SEQUENCE OF SysApplElmtRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table describes the processes which are currently executing on the host system. Each entry represents a running process and is associated with the invoked application of which that process is a part, if possible. This table contains an entry for every process currently running on the system, regardless of whether its 'parent' application can be determined. So, for example, processes like 'ps' and 'grep' will have entries though they are not associated with an installed application package. Because a running application may involve more than one executable, it is possible to have multiple entries in this table for each application. Entries are removed from this table when the process terminates. Krupczak & Saperia Standards Track [Page 23] RFC 2287 MIB for Applications February 1998 The table is indexed by sysApplElmtRunInstallPkg, sysApplElmtRunInvocID, and sysApplElmtRunIndex to facilitate the retrieval of all running elements of a particular invoked application which has been installed on the system." ::= { sysApplRun 3 } sysApplElmtRunEntry OBJECT-TYPE SYNTAX SysApplElmtRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The logical row describing a process currently running on this host. When possible, the entry is associated with the invoked application of which it is a part." INDEX { sysApplElmtRunInstallPkg, sysApplElmtRunInvocID, sysApplElmtRunIndex } ::= { sysApplElmtRunTable 1 } SysApplElmtRunEntry ::= SEQUENCE { sysApplElmtRunInstallPkg Unsigned32, sysApplElmtRunInvocID Unsigned32, sysApplElmtRunIndex Unsigned32, sysApplElmtRunInstallID Unsigned32, sysApplElmtRunTimeStarted DateAndTime, sysApplElmtRunState RunState, sysApplElmtRunName LongUtf8String, sysApplElmtRunParameters Utf8String, sysApplElmtRunCPU TimeTicks, sysApplElmtRunMemory Gauge32, sysApplElmtRunNumFiles Gauge32, sysApplElmtRunUser Utf8String } sysApplElmtRunInstallPkg OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Part of the index for this table, this value identifies the installed software package for the application of which this process is a part. Provided that the process's 'parent' application can be determined, the value of this object is the same value as the sysApplInstallPkgIndex for the entry in the sysApplInstallPkgTable that corresponds to the installed application of which this process Krupczak & Saperia Standards Track [Page 24] RFC 2287 MIB for Applications February 1998 is a part. If, however, the 'parent' application cannot be determined, (for example the process is not part of a particular installed application), the value for this object is then '0', signifying that this process cannot be related back to an application, and in turn, an installed software package." ::= { sysApplElmtRunEntry 1 } sysApplElmtRunInvocID OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Part of the index for this table, this value identifies the invocation of an application of which this process is a part. Provided that the 'parent' application can be determined, the value of this object is the same value as the sysApplRunIndex for the corresponding application invocation in the sysApplRunTable. If, however, the 'parent' application cannot be determined, the value for this object is then '0', signifying that this process cannot be related back to an invocation of an application in the sysApplRunTable." ::= { sysApplElmtRunEntry 2 } sysApplElmtRunIndex OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Part of the index for this table. A unique value for each process running on the host. Wherever possible, this should be the system's native, unique identification number." ::= { sysApplElmtRunEntry 3 } sysApplElmtRunInstallID OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS read-only STATUS current DESCRIPTION "The index into the sysApplInstallElmtTable. The Krupczak & Saperia Standards Track [Page 25] RFC 2287 MIB for Applications February 1998 value of this object is the same value as the sysApplInstallElmtIndex for the application element of which this entry represents a running instance. If this process cannot be associated with an installed executable, the value should be '0'." ::= { sysApplElmtRunEntry 4 } sysApplElmtRunTimeStarted OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time the process was started." ::= { sysApplElmtRunEntry 5 } sysApplElmtRunState OBJECT-TYPE SYNTAX RunState MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the running process. The possible values are running(1), runnable(2) but waiting for a resource such as CPU, waiting(3) for an event, exiting(4), or other(5)." ::= { sysApplElmtRunEntry 6 } sysApplElmtRunName OBJECT-TYPE SYNTAX LongUtf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The full path and filename of the process. For example, '/opt/MYYpkg/bin/myyproc' would be returned for process 'myyproc' whose execution path is '/opt/MYYpkg/bin/myyproc'." ::= { sysApplElmtRunEntry 7 } sysApplElmtRunParameters OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The starting parameters for the process." ::= { sysApplElmtRunEntry 8 } sysApplElmtRunCPU OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Krupczak & Saperia Standards Track [Page 26] RFC 2287 MIB for Applications February 1998 STATUS current DESCRIPTION "The number of centi-seconds of the total system's CPU resources consumed by this process. Note that on a multi-processor system, this value may have been incremented by more than one centi-second in one centi-second of real (wall clock) time." ::= { sysApplElmtRunEntry 9 } sysApplElmtRunMemory OBJECT-TYPE SYNTAX Gauge32 UNITS "Kbytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of real system memory measured in Kbytes currently allocated to this process." ::= { sysApplElmtRunEntry 10 } sysApplElmtRunNumFiles OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of regular files currently open by the process. Transport connections (sockets) should NOT be included in the calculation of this value, nor should operating system specific special file types." ::= { sysApplElmtRunEntry 11 } sysApplElmtRunUser OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The process owner's login name (e.g. root)." ::= { sysApplElmtRunEntry 12 } -- sysApplElmtPastRunTable -- The sysApplElmtPastRunTable maintains a history of -- processes which have previously executed on -- the host as part of an application. Upon termination -- of a process, the entry representing the process is removed from -- the sysApplElmtRunTable and a corresponding entry is created in -- this table provided that the process was part of an -- identifiable application. If the process could not be associated Krupczak & Saperia Standards Track [Page 27] RFC 2287 MIB for Applications February 1998 -- with an invoked application, no corresponding entry is created. -- Hence, whereas the sysApplElmtRunTable contains an entry for -- every process currently executing on the system, the -- sysApplElmtPastRunTable only contains entries for processes -- that previously executed as part of an invoked application. -- -- Entries remain in this table until they are aged out when -- either the number of entries in the table reaches a -- maximum as determined by sysApplElmtPastRunMaxRows, or -- when an entry has aged to exceed a time limit as set by -- sysApplElmtPastRunTblTimeLimit. When aging out entries, -- the oldest entry, as determined by the value of -- sysApplElmtPastRunTimeEnded, will be removed first. -- -- The table is indexed by sysApplInstallPkgIndex (from the -- sysApplInstallPkgTable), sysApplElmtPastRunInvocID, and -- sysApplElmtPastRunIndex to make it easy to locate all -- previously executed processes of a particular invoked application -- that has been installed on the system. sysApplElmtPastRunTable OBJECT-TYPE SYNTAX SEQUENCE OF SysApplElmtPastRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table describes the processes which have previously executed on the host system as part of an application. Each entry represents a process which has previously executed and is associated with the invoked application of which it was a part. Because an invoked application may involve more than one executable, it is possible to have multiple entries in this table for each application invocation. Entries are added to this table when the corresponding process in the sysApplElmtRun Table terminates. Entries remain in this table until they are aged out when either the number of entries in the table reaches a maximum as determined by sysApplElmtPastRunMaxRows, or when an entry has aged to exceed a time limit as set by sysApplElmtPastRunTblTimeLimit. When aging out entries, the oldest entry, as determined by the value of sysApplElmtPastRunTimeEnded, will be removed first. The table is indexed by sysApplInstallPkgIndex (from the sysApplInstallPkgTable), sysApplElmtPastRunInvocID, and sysApplElmtPastRunIndex to make it easy to locate all Krupczak & Saperia Standards Track [Page 28] RFC 2287 MIB for Applications February 1998 previously executed processes of a particular invoked application that has been installed on the system." ::= { sysApplRun 4 } sysApplElmtPastRunEntry OBJECT-TYPE SYNTAX SysApplElmtPastRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The logical row describing a process which was previously executed on this host as part of an installed application. The entry is basically copied from the sysApplElmtRunTable when the process terminates. Hence, the entry's value for sysApplElmtPastRunIndex is the same as its value was for sysApplElmtRunIndex. Note carefully: only those processes which could be associated with an identified application are included in this table." INDEX { sysApplInstallPkgIndex, sysApplElmtPastRunInvocID, sysApplElmtPastRunIndex } ::= { sysApplElmtPastRunTable 1 } SysApplElmtPastRunEntry ::= SEQUENCE { sysApplElmtPastRunInvocID Unsigned32, sysApplElmtPastRunIndex Unsigned32, sysApplElmtPastRunInstallID Unsigned32, sysApplElmtPastRunTimeStarted DateAndTime, sysApplElmtPastRunTimeEnded DateAndTime, sysApplElmtPastRunName LongUtf8String, sysApplElmtPastRunParameters Utf8String, sysApplElmtPastRunCPU TimeTicks, sysApplElmtPastRunMemory Unsigned32, sysApplElmtPastRunNumFiles Unsigned32, sysApplElmtPastRunUser Utf8String } sysApplElmtPastRunInvocID OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Part of the index for this table, this value identifies the invocation of an application of which the process represented by this entry was a part. The value of this object is the same value as the sysApplRunIndex for the corresponding application invocation in the sysApplRunTable. If the invoked application as a whole has terminated, it will be the Krupczak & Saperia Standards Track [Page 29] RFC 2287 MIB for Applications February 1998 same as the sysApplPastRunIndex." ::= { sysApplElmtPastRunEntry 1 } sysApplElmtPastRunIndex OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Part of the index for this table. An integer assigned by the agent equal to the corresponding sysApplElmtRunIndex which was removed from the sysApplElmtRunTable and moved to this table when the element terminated. Note: entries in this table are indexed by sysApplElmtPastRunInvocID, sysApplElmtPastRunIndex. The possibility exists, though unlikely, of a collision occurring by a new entry which was run by the same invoked application (InvocID), and was assigned the same process identification number (ElmtRunIndex) as an element which was previously run by the same invoked application. Should this situation occur, the new entry replaces the old entry. See Section: 'Implementation Issues - sysApplElmtPastRunTable Entry Collisions' for the conditions that would have to occur in order for a collision to occur." ::= { sysApplElmtPastRunEntry 2 } sysApplElmtPastRunInstallID OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS read-only STATUS current DESCRIPTION "The index into the installed element table. The value of this object is the same value as the sysApplInstallElmtIndex for the application element of which this entry represents a previously executed process." ::= { sysApplElmtPastRunEntry 3 } sysApplElmtPastRunTimeStarted OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only Krupczak & Saperia Standards Track [Page 30] RFC 2287 MIB for Applications February 1998 STATUS current DESCRIPTION "The time the process was started." ::= { sysApplElmtPastRunEntry 4 } sysApplElmtPastRunTimeEnded OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time the process ended." ::= { sysApplElmtPastRunEntry 5 } sysApplElmtPastRunName OBJECT-TYPE SYNTAX LongUtf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The full path and filename of the process. For example, '/opt/MYYpkg/bin/myyproc' would be returned for process 'myyproc' whose execution path was '/opt/MYYpkg/bin/myyproc'." ::= { sysApplElmtPastRunEntry 6 } sysApplElmtPastRunParameters OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The starting parameters for the process." ::= { sysApplElmtPastRunEntry 7 } sysApplElmtPastRunCPU OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The last known number of centi-seconds of the total system's CPU resources consumed by this process. Note that on a multi-processor system, this value may increment by more than one centi-second in one centi-second of real (wall clock) time." ::= { sysApplElmtPastRunEntry 8 } sysApplElmtPastRunMemory OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) UNITS "Kbytes" MAX-ACCESS read-only Krupczak & Saperia Standards Track [Page 31] RFC 2287 MIB for Applications February 1998 STATUS current DESCRIPTION "The last known total amount of real system memory measured in Kbytes allocated to this process before it terminated." ::= { sysApplElmtPastRunEntry 9 } sysApplElmtPastRunNumFiles OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS read-only STATUS current DESCRIPTION "The last known number of files open by the process before it terminated. Transport connections (sockets) should NOT be included in the calculation of this value." ::= { sysApplElmtPastRunEntry 10 } sysApplElmtPastRunUser OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The process owner's login name (e.g. root)." ::= { sysApplElmtPastRunEntry 11 } -- Additional Scalar objects to control table sizes sysApplPastRunMaxRows OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries allowed in the sysApplPastRunTable. Once the number of rows in the sysApplPastRunTable reaches this value, the management subsystem will remove the oldest entry in the table to make room for the new entry to be added. Entries will be removed on the basis of oldest sysApplPastRunTimeEnded value first. This object may be used to control the amount of system resources that can used for sysApplPastRunTable entries. A conforming implementation should attempt to support the default value, however, a lesser value may be necessary due to implementation-dependent issues and resource availability." Krupczak & Saperia Standards Track [Page 32] RFC 2287 MIB for Applications February 1998 DEFVAL { 500 } ::= { sysApplRun 5 } sysApplPastRunTableRemItems OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter of the number of entries removed from the sysApplPastRunTable because of table size limitations as set in sysApplPastRunMaxRows. This counter is the number of entries the management subsystem has had to remove in order to make room for new entries (so as not to exceed the limit set by sysApplPastRunMaxRows) since the last initialization of the management subsystem." ::= { sysApplRun 6 } sysApplPastRunTblTimeLimit OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum time in seconds which an entry in the sysApplPastRunTable may exist before it is removed. Any entry that is older than this value will be removed (aged out) from the table. Note that an entry may be aged out prior to reaching this time limit if it is the oldest entry in the table and must be removed to make space for a new entry so as to not exceed sysApplPastRunMaxRows." DEFVAL { 7200 } ::= { sysApplRun 7 } sysApplElemPastRunMaxRows OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries allowed in the sysApplElmtPastRunTable. Once the number of rows in the sysApplElmtPastRunTable reaches this value, the management subsystem will remove the oldest entry to make room for the new entry to be added. Entries will be removed on the basis of oldest sysApplElmtPastRunTimeEnded value first. Krupczak & Saperia Standards Track [Page 33] RFC 2287 MIB for Applications February 1998 This object may be used to control the amount of system resources that can used for sysApplElemPastRunTable entries. A conforming implementation should attempt to support the default value, however, a lesser value may be necessary due to implementation-dependent issues and resource availability." DEFVAL { 500 } ::= { sysApplRun 8 } sysApplElemPastRunTableRemItems OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter of the number of entries removed from the sysApplElemPastRunTable because of table size limitations as set in sysApplElemPastRunMaxRows. This counter is the number of entries the management subsystem has had to remove in order to make room for new entries (so as not to exceed the limit set by sysApplElemPastRunMaxRows) since the last initialization of the management subsystem." ::= { sysApplRun 9 } sysApplElemPastRunTblTimeLimit OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum time in seconds which an entry in the sysApplElemPastRunTable may exist before it is removed. Any entry that is older than this value will be removed (aged out) from the table. Note that an entry may be aged out prior to reaching this time limit if it is the oldest entry in the table and must be removed to make space for a new entry so as to not exceed sysApplElemPastRunMaxRows." DEFVAL { 7200 } ::= { sysApplRun 10 } sysApplAgentPollInterval OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum interval in seconds that the management Krupczak & Saperia Standards Track [Page 34] RFC 2287 MIB for Applications February 1998 subsystem implementing this MIB will poll the status of the managed resources. Because of the non-trivial effort involved in polling the managed resources, and because the method for obtaining the status of the managed resources is implementation-dependent, a conformant implementation may chose a lower bound greater than 0. A value of 0 indicates that there is no delay in the passing of information from the managed resources to the agent." DEFVAL { 60 } ::= { sysApplRun 11 } -- sysApplMap Group -- This group contains a table, the sysApplMapTable, -- whose sole purpose is to provide a 'backwards' -- mapping so that, given a known sysApplElmtRunIndex -- (process identification number), the corresponding invoked -- application (sysApplRunIndex), installed element -- (sysApplInstallElmtIndex), and installed application -- package (sysApplInstallPkgIndex) can be quickly determined. -- -- The table will contain one entry for each process -- currently running on the system. -- -- A backwards mapping is extremely useful since the tables -- in this MIB module are typically indexed with the -- installed application package (sysApplInstallPkgIndex) -- as the primary key, and on down as required by the -- specific table, with the process ID number (sysApplElmtRunIndex) -- being the least significant key. -- -- It is expected that management applications will use -- this mapping table by doing a 'GetNext' operation with -- the known process ID number (sysApplElmtRunIndex) as the partial -- instance identifier. Assuming that there is an entry for -- the process, the result should return a single columnar value, -- the sysApplMapInstallPkgIndex, with the sysApplElmtRunIndex, -- sysApplRunIndex, and sysApplInstallElmtIndex contained in the -- instance identifier for the returned MIB object value. -- -- NOTE: if the process can not be associated back to an -- invoked application installed on the system, then the -- value returned for the columnar value sysApplMapInstallPkgIndex -- will be '0' and the instance portion of the object-identifier -- will be the process ID number (sysApplElmtRunIndex) followed Krupczak & Saperia Standards Track [Page 35] RFC 2287 MIB for Applications February 1998 -- by 0.0. sysApplMapTable OBJECT-TYPE SYNTAX SEQUENCE OF SysApplMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The sole purpose of this table is to provide a 'backwards' mapping so that, given a known sysApplElmtRunIndex (process identification number), the corresponding invoked application (sysApplRunIndex), installed element (sysApplInstallElmtIndex), and installed application package (sysApplInstallPkgIndex) can be quickly determined. This table will contain one entry for each process that is currently executing on the system. It is expected that management applications will use this mapping table by doing a 'GetNext' operation with the known process ID number (sysApplElmtRunIndex) as the partial instance identifier. Assuming that there is an entry for the process, the result should return a single columnar value, the sysApplMapInstallPkgIndex, with the sysApplElmtRunIndex, sysApplRunIndex, and sysApplInstallElmtIndex contained in the instance identifier for the returned MIB object value. NOTE: if the process can not be associated back to an invoked application installed on the system, then the value returned for the columnar value sysApplMapInstallPkgIndex will be '0' and the instance portion of the object-identifier will be the process ID number (sysApplElmtRunIndex) followed by 0.0." ::= { sysApplMap 1 } sysApplMapEntry OBJECT-TYPE SYNTAX SysApplMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logical row representing a process currently running on the system. This entry provides the index mapping from process identifier, back to the invoked application, installed element, and finally, the installed application package. The entry includes only one accessible columnar object, the sysApplMapInstallPkgIndex, but the invoked application and installed element can be Krupczak & Saperia Standards Track [Page 36] RFC 2287 MIB for Applications February 1998 determined from the instance identifier since they form part of the index clause." INDEX { sysApplElmtRunIndex, sysApplElmtRunInvocID, sysApplMapInstallElmtIndex } ::= { sysApplMapTable 1 } SysApplMapEntry ::= SEQUENCE { sysApplMapInstallElmtIndex Unsigned32, sysApplMapInstallPkgIndex Unsigned32 } sysApplMapInstallElmtIndex OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index into the sysApplInstallElmtTable. The value of this object is the same value as the sysApplInstallElmtIndex for the application element of which this entry represents a running instance. If this process cannot be associated to an installed executable, the value should be '0'." ::= { sysApplMapEntry 1 } sysApplMapInstallPkgIndex OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the installed software package for the application of which this process is a part. Provided that the process's 'parent' application can be determined, the value of this object is the same value as the sysApplInstallPkgIndex for the entry in the sysApplInstallPkgTable that corresponds to the installed application of which this process is a part. If, however, the 'parent' application cannot be determined, (for example the process is not part of a particular installed application), the value for this object is then '0', signifying that this process cannot be related back to an application, and in turn, an installed software package." ::= { sysApplMapEntry 2 } -- Conformance Macros Krupczak & Saperia Standards Track [Page 37] RFC 2287 MIB for Applications February 1998 sysApplMIBCompliances OBJECT IDENTIFIER ::= { sysApplConformance 1 } sysApplMIBGroups OBJECT IDENTIFIER ::= { sysApplConformance 2 } sysApplMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the System Application MIB" MODULE -- this module MANDATORY-GROUPS { sysApplInstalledGroup, sysApplRunGroup, sysApplMapGroup } ::= { sysApplMIBCompliances 1 } sysApplInstalledGroup OBJECT-GROUP OBJECTS { sysApplInstallPkgManufacturer, sysApplInstallPkgProductName, sysApplInstallPkgVersion, sysApplInstallPkgSerialNumber, sysApplInstallPkgDate, sysApplInstallPkgLocation, sysApplInstallElmtName, sysApplInstallElmtType, sysApplInstallElmtDate, sysApplInstallElmtPath, sysApplInstallElmtSizeHigh, sysApplInstallElmtSizeLow, sysApplInstallElmtRole, sysApplInstallElmtModifyDate, sysApplInstallElmtCurSizeHigh, sysApplInstallElmtCurSizeLow } STATUS current DESCRIPTION "The system application installed group contains information about applications and their constituent components which have been installed on the host system." ::= { sysApplMIBGroups 1 } sysApplRunGroup OBJECT-GROUP OBJECTS { sysApplRunStarted, sysApplRunCurrentState, sysApplPastRunStarted, sysApplPastRunExitState, sysApplPastRunTimeEnded, sysApplElmtRunInstallID, sysApplElmtRunTimeStarted, sysApplElmtRunState, sysApplElmtRunName, sysApplElmtRunParameters, Krupczak & Saperia Standards Track [Page 38] RFC 2287 MIB for Applications February 1998 sysApplElmtRunCPU, sysApplElmtRunMemory, sysApplElmtRunNumFiles, sysApplElmtRunUser, sysApplElmtPastRunInstallID, sysApplElmtPastRunTimeStarted, sysApplElmtPastRunTimeEnded, sysApplElmtPastRunName, sysApplElmtPastRunParameters, sysApplElmtPastRunCPU, sysApplElmtPastRunMemory, sysApplElmtPastRunNumFiles, sysApplElmtPastRunUser, sysApplPastRunMaxRows, sysApplPastRunTableRemItems, sysApplPastRunTblTimeLimit, sysApplElemPastRunMaxRows, sysApplElemPastRunTableRemItems, sysApplElemPastRunTblTimeLimit, sysApplAgentPollInterval } STATUS current DESCRIPTION "The system application run group contains information about applications and associated elements which have run or are currently running on the host system." ::= { sysApplMIBGroups 2 } sysApplMapGroup OBJECT-GROUP OBJECTS { sysApplMapInstallPkgIndex } STATUS current DESCRIPTION "The Map Group contains a single table, sysApplMapTable, that provides a backwards mapping for determining the invoked application, installed element, and installed application package given a known process identification number." ::= { sysApplMIBGroups 3 } END Krupczak & Saperia Standards Track [Page 39] RFC 2287 MIB for Applications February 1998 7. Implementation Issues This section discusses implementation issues that are important for both an agent developer, and a management application developer or user to understand with regards to this MIB module. Although this section does not attempt to prescribe a particular implementation strategy, it does attempt to recognize some of the real world limitations that could effect an implementation of this MIB module. 7.1. Implementation with Polling Agents Implementations of the System Application MIB on popular operating systems might require some considerable processing power to obtain status information from the managed resources. It might also be difficult to determine when an application or a process starts or finishes. Implementors of this MIB might therefore choose an implementation approach where the agent polls the managed resources at regular intervals. The information retrieved by every poll is used to update a cached version of this MIB maintained inside of the agent. SNMP request are processed based on the information found in this MIB cache. A scalar sysApplAgentPollInterval is defined to give the manager control over the polling frequency. There is a trade- off between the amount of resources consumed during every poll to update the MIB cache, and the accuracy of the information provided by the System Application MIB agent. A default value of 60 seconds is defined to keep the processing overhead low, while providing usable information for long-lived processes. A manager is expected to adjust this value if more accurate information about short-lived applications or processes is needed, or if the amount of resources consumed by the agent is too high. 7.2. sysApplElmtPastRunTable Entry Collisions The sysApplElmtPastRunTable maintains a history of processes which have previously executed on the host as part of an application. Information is moved from the sysApplElmtRunTable to this PastRun table when the process represented by the entry terminates. The sysApplElmtPastRunTable is indexed by the tuple, (sysApplElmtPastRunInvocID, sysApplElmtPastRunIndex), where the first part identifies the application invocation of which the process was a part, and the second part identifies the process itself. Recall that the sysApplElmtRunIndex represents the system's unique identification number assigned to a running process and that this value is mapped to sysApplElmtPastRunIndex when the process Krupczak & Saperia Standards Track [Page 40] RFC 2287 MIB for Applications February 1998 terminates and the entry's information is moved from the sysApplElmtRunTable to the sysApplElmtPastRunTable. Many systems re-use process ID numbers which are no longer assigned to running processes; typically, the process numbers wrap and the next available process number is used. It is therefore possible for two entries in the sysApplElmtPastRun Table to have the same value for sysApplElmtPastRunIndex. For this reason, entries in the ElmtPastRun table are indexed by the tuple sysApplElmtPastRunInvocID, sysApplElmtPastRunIndex to reduce the chance of a collision by two past run elements with the same sysApplElmtPastRunIndex. However, it is still possible, though unlikely, for a collision to occur if the following happens: 1) the invoked application (identified by InvocID), has an element which runs, terminates, and is moved into the sysApplElmtPastRun table (index: InvocID, RunIndex) 2) the numbers used for the system's process identification numbering wrap 3) that same invoked application (same InvocID), has another element process run, AND that process is assigned the same identification number as one of the processes previously run by that invoked application (same RunIndex), and finally, 4) that element process terminates and is moved to the sysApplElmtPastRun table prior to the old, duplicate (InvocID, RunIndex) entry being aged out of the table by settings defined for sysApplElmtPastRunMaxRows and sysApplElmtPastRunTblTimeLimit. In the event that a collision occurs, the new entry will replace the old entry. 8. Security Considerations In order to implement this MIB, an agent must make certain management information available about various logical and physical entities within a managed system which may be considered sensitive in some network environments. Therefore, a network administrator may wish to employ instance-level access control, and configure the access mechanism (i.e., community strings in SNMPv1 and SNMPv2C), such that certain instances within this MIB are excluded from particular MIB views. Krupczak & Saperia Standards Track [Page 41] RFC 2287 MIB for Applications February 1998 9. Acknowledgements This document was produced by the Application MIB working group. Special acknowledgement is made to: Rick Sturm Enterprise Management Professional Services, Inc. sturm@emi-summit.com For hosting the working group mailing list, and for his participation in the development of the initial draft. Jon Weinstock General Instrument Corporation jweinstock@gic.gi.com For his participation in the development of the initial drafts and for serving as editor for drafts 1 and 2. The editor would like to extend special thanks to the following working group members for their contributions to this effort. Harald Alvestrand, George Best, Ian Hanson, Harrie Hazewinkel, Carl Kalbfleisch, Bobby Krupczak, Randy Presuhn, Jon Saperia, Juergen Schoenwaelder 11. Author's Address Cheryl Krupczak Empire Technologies, Inc. 541 Tenth Street, NW Suite 169 Atlanta, GA 30318 Phone: 770.384.0184 EMail: cheryl@empiretech.com Jonathan Saperia BGS Systems Inc. saperia@networks.bgs.com 12. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). Krupczak & Saperia Standards Track [Page 42] RFC 2287 MIB for Applications February 1998 [2] 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. [3] 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. [4] 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. [5] 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. [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for SNMPv2", RFC 1906, January 1996. [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [9] Grillo, P., and S. Waldbusser, "Host Resources MIB", RFC 1514, September 1993. [10] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [11] Krupczak, C., and S. Waldbusser, "Applicability of Host Resources MIB to Application Management", Application MIB working group report, October 1995. Krupczak & Saperia Standards Track [Page 43] RFC 2287 MIB for Applications February 1998 12. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Krupczak & Saperia Standards Track [Page 44] snmp-mibs-downloader-1.1/mibrfcs/rfc2320.txt0000644000000000000000000030735511402176071015565 0ustar Network Working Group M. Greene Request for Comments: 2320 Xedia Corp. Category: Standards Track J. Luciani Bay Networks, Inc. K. White IBM Corp. T. Kuo Bay Networks, Inc. April 1998 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM, refer to reference [3]. Support of an ATM interface by an IP layer will require implementation of objects from several Management Information Bases (MIBs) as well as their enhancement in order to enable usage of ATM transports. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of the Simple Network Management Protocol Version (refer to RFC 1902, reference [1]). Greene, et al. [Page 1] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 Table of Contents 1. Introduction............................................. 2 2. The SNMPv2 Network Management Framework.................. 3 2.1 Object Definitions...................................... 4 3. Structure of the MIB..................................... 4 3.1 Basic Support MIB Definitions........................... 5 3.1.1 ATM Logical IP Subnet (LIS) Table..................... 5 3.1.2 ATM Logical IP Subnet Interface Mapping Table......... 7 3.1.3 ATMARP Remote Server Table............................ 7 3.1.4 ATM VC Table.......................................... 8 3.1.5 ATM Config PVC Table.................................. 9 3.1.6 Notifications......................................... 10 3.2 Client Supported MIB Definitions........................ 10 3.2.1 ATMARP Client Table................................... 11 3.3 Server Supported MIB Definitions........................ 12 3.3.1 ATMARP Server Table................................... 12 3.3.2 Notifications......................................... 13 4. Definitions.............................................. 14 5. Security Considerations.................................. 48 6. Intellectual Property.................................... 49 7. Acknowledgments.......................................... 49 8. References............................................... 50 9. Authors' Addresses....................................... 51 10. Full Copyright Statement................................ 52 1. Introduction This document is a product of the Internetworking Over NBMA Working Group. Its purpose is to define a MIB module for extending the traditional MIBs supported by a TCP/IP implementation to support Classical IP and ARP over ATM. Many MIB related RFCs and Internet Drafts have been considered in the development of this document. The ones that are considered central to the extensions defined by this document are: o RFC 2011 - SNMPv2 Management Information Base for the Internet Protocol using SMIv2 [9]. The IP over ATM (IPOA) MIB provides extensions to the IP Group for handling IP over ATM flows. A basic understanding of the IP Group is essential for understanding this document. Greene, et al. [Page 2] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 o RFC 2233 - The Interfaces Group MIB (IF-MIB) using SMIv2, reference [2]. This document is important since it provides several very useful enhancements over the interface group defined in RFC 1213 (reference [5]) that aid in handling ATM related interfaces. o RFC 1695 - Definitions of Managed Objects for ATM Management [4] (ATM-MIB). Support of this MIB is REQUIRED for implementing the layers between AAL5 and ATM. The contents of this MIB will not explicitly be addressed here. The ATM-MIB provides a basis for managing ATM interface layering and management of: - ATM Switched Virtual Connections (SVCs) - ATM Permanent Virtual Connections (PVCs) The ATM Forum UNI ILMI MIB is specified by the ATM Forum in various versions of the UNI specification. The ILMI MIBs being defined are not supported via SNMP agents but via SNMP requests sent over an ATM network to an ATM entity encapsulated in an AAL5 header. Support of the ILMI MIB(s) is considered out of the scope of this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [10]. 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of seven major components. They are: o RFC 1902 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1903 [6] defines textual conventions for SNMPv2. o RFC 1904 [8] defines conformance statements for SNMPv2. o RFC 1905 [7] defines transport mappings for SNMPv2. o RFC 1906 [12] defines the protocol operations used for network access to managed objects. o RFC 1907 [13] defines the Management Information Base for SNMPv2. o RFC 1908 [14] specifies coexistence between SNMPv1 and SNMPv2. Greene, et al. [Page 3] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 The Framework permits new objects to be defined for the purpose of experimentation and evaluation. This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A semantically identical MIB conforming to the SNMPv1 SMI can be produced through the appropriate translation. 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. Structure of the MIB The Classical ARP and IP over ATM (IPOA) MIB structure is split into three components: o Basic Support MIB Definitions o Client Supported MIB Definitions o Server Supported MIB Definitions All IP and ARP over ATM entities, both clients and ATMARP Servers, are REQUIRED to support the MIB definitions in the Basic Support MIB Definitions section. Clients need to additionally support the MIB definitions outlined in the Client specific section and ATMARP Servers MUST additionally support the ATMARP Server specific MIB definitions. Implementation of the Definitions of Managed Objects for ATM Management [4] defines the modeling of the various layers within an ATM Interface. This modeling is assumed as a prerequisite for the IPOA-MIB. The IPOA-MIB makes no assumptions on how this layering is actually implemented within a system. Several of the MIB tables defined by the IPOA-MIB, like the base TCP/IP MIBs, require that an ifIndex exist that points to an ATM Interface. Refer to the ATM-MIB [4] for the definition of ATM Interface layering. The use of an IP over ATM Virtual Interface layer is NOT explicitly REQUIRED by the IPOA-MIB. The use of virtual layers above an ATM-MIB defined interface layer is not absolutely necessary for modeling the Greene, et al. [Page 4] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 attachment of IP to an ATM network. The IPOA-MIB refers to use of a generic ifIndex object, whose value SHOULD reflect that of some specific ATM related interface as determined by an implementation. It is up to the implementers of this MIB to determine their own ATM interface layering (assuming compliance with the IF-MIB and the ATM- MIB). The Internet Assigned Numbers Authority (IANA) ifType ipOverAtm(114) was created for use by systems that require a virtual IP over ATM interface layer. The IF-MIB's ifStackTable SHOULD be used to show the relationship between virtual IP over ATM interfaces and the actual ATM physical interface layers. The current set of ifType values can be accessed via the IANA homepage at: "http://www.iana.org/iana/". 3.1. Basic Support MIB Definitions Basic support that MUST be implemented by both Clients and ATMARP Servers consists of: o ATM Logical IP Subnet (LIS) Table o ATM Logical IP Subnet Interface Mapping Table o ATMARP Remote Server Table o ATM VC Table o ATM Config PVC Table o Notifications 3.1.1. ATM Logical IP Subnet (LIS) Table The ATM Logical IP Subnet (LIS) Table defines the subnets that this system is a member of for purposes of reaching destinations over an ATM transport. The LIS table is indexed by the subnet address (ipoaLisSubnetAddr) and not ifIndex. The ipoaLisIfMappingTable described in the next section provides the mapping between Logical IP Subnets and the interface layer. It is possible that the same LIS can be reached via different ATM interfaces. The ipAddrTable and the ipoaClientTable provides the mapping from a local IP address to an ATM interface. One or more ipAddrTable entries can point to the same ipoaLisEntry. An ipAddrEntry's ipAdEntAddr ANDed with its ipAdEntNetMask SHOULD equal an ipoaLisEntry's ipoaLisSubnetAddr. Given that an interface can be multi-homed, each local IP address associated with an interface requires an entry in the ipAddrTable. Each ipAddrTable entry for a local IP address associated with an ATM interface SHOULD map to an entry in the ipoaLisTable. Greene, et al. [Page 5] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 The bulk of the objects in an ipoaLisEntry exists to control ATMARP for a particular LIS. In a PVC only environment it is implementation dependent as to whether this table should be supported: ipoaLisInactivityTimer ipoaLisMinHoldingTime ipoaLisQDepth ipoaLisMaxCalls ipoaLisCacheEntryAge ipoaLisRetries ipoaLisTimeout The value of an ipoaLisMaxCalls object defines the maximum number of VCs that can be established simultaneously per LIS. The value of an ipoaLisDefaultPeakCellRate object defines the best effort default peak cell rate in both the forward and backward directions when establishing VCCs (Virtual Channel Connections). Refer to RFC 1755, ATM Signaling Support for IP over ATM (reference [11]), for a definition of the use of this object's value. The ipAddrTable's ipAdEntReasmMaxSize is the "The size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface" and is different from the ipoaLisTable's ipoaLisDefaultMtu with is the default MTU used within an LIS. Note that this is the default MTU, not the actual MTU (which is represented as ipoaVcNegotiatedMtu in the ipoaVcTable). The ipoaLisRowStatus object enables entries in the ipoaLisTable to be created or deleted via SNMP. Creation of an ipoaLisTable entry results in the addition of a corresponding ipAddrTable entry and an ipoaLisIfMappingTable entry. Creation of multiple ipAddrTable entries and ipoaLisIfMappingTable entries for the same LIS is not addressed by this document. When ipoaLisRowStatus is changed from active(1) to notInService(2) or from active(1) to destroy(6), this has the side- effect of removing all entries from the ipNetToMediaTable that are associated with this LIS (in other words, it flushes the entity's ATMARP cache). It also removes the ipoaVcTable entries that were associated with those ipNetToMediaTable entries. Destroying the row removes the corresponding entries in the ipoaArpSrvrTable, ipoaArpClientTable, ipoaLisIfMappingTable, and the ipoaArpRemoteSrvrTable. Entries in both the ipNetToMediaTable and the ipoaVcTable that are associated with an ipoaConfigPvcEntry are not affected by changes to ipoaLisRowStatus. Greene, et al. [Page 6] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 3.1.2. ATM Logical IP Subnet Interface Mapping Table The ipoaLisIfMappingTable maps a LIS to all ATM interfaces from which it is configured to be supported. Each entry in the ipoaLisIfMappingTable SHOULD map to an ipAddrTable entry. It is also possible for a system, most commonly a switch, to have multiple LISs associated with the same ATM interface. 3.1.3. ATMARP Remote Server Table Entries in the ipoaArpRemoteSrvrTable exists to locally configure the remote ATMARP Servers that exist on a per LIS and interface basis. Classical IP and ARP over ATM [3] requires that at least one ATMARP Server be configured per LIS where SVC traffic is intended. PVC usage doesn't require use of ATMARP. No ipoaArpRemoteSrvrTable entries SHOULD be configured for a LIS where only PVCs will be used. An entry in the ipoaArpRemoteSrvrTable is indexed by the subnet address of the LIS (ipoaLisSubnetAddr), the ATM address of the remote ATMARP Server (ipoaArpRemoteSrvrAtmAddr) and an interface ifIndex (ipoaArpRemoteSrvrIfIndex) value. The object ipoaArpRemoteSrvrIpAddr in an ipoaArpRemoteSrvrEntry is set with the IP Address of the Remote ATMARP Server when a VC to the Remote ATMARP Server is established. A value of 0.0.0.0 SHOULD be used when the IP address of the Remote ATMARP Server is not known. Once ipoaArpRemoteSrvrIpAddr is set then the ipoaVcTable can be searched using ipoaArpRemoteSrvrIfIndex and ipoaArpRemoteSrvrIpAddr to find the VC in use to the Remote ATMARP Server. ipoaArpRemoteSrvrIfIndex is defined to have the textual convention of InterfaceIndexOrZero. Adding ipoaArpRemoteSrvrIfIndex to the index clause allows a system to have a VC to a ATMARP Remote Server on a per LIS and interface basis. An entry in this table SHOULD exist for each interface on a per LIS basis. Each interface would then have a separate VC to the Remote ATMARP Server for ATMARP purposes. An implementation that wants to use a single VC MAY use an ipoaArpRemoteSrvrIfIndex value of 0 when configuring an ipoaArpRemoteSrvrEntry for the associating LIS. If ipoaArpRemoteSrvrIfIndex is 0 then an implementation dependent method MAY be used for finding the VPI and VCI of the VC in use to the Remote ATMARP Server. For example, search the ipoaVcTable for a match between ipNetToMediaNetAddress and ipoaArpRemoteSrvrIpAddr from an ipoaArpRemoteSrvrEntry, ignoring ipNetToMediaIfIndex. Since a single VC is being used the first match SHOULD correspond to the correct VC. Greene, et al. [Page 7] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 If a PVC is intended to be used to communicate with a remote ATMARP Server then the ipoaConfigPvcTable MUST be used to create and activate the PVC prior to activating a ipoaArpRemoteSrvrEntry. The object ipoaArpRemoteSrvrRowStatus allows for row creation and deletion of entries in the ipoaArpRemoteSrvrTable. The objects ipoaArpRemoteSrvrAdminStatus and ipoaArpRemoteSrvrOperStatus exist to control and reflect the operational use of a Remote ATMARP Server defined by an ipoaArpRemoteSrvrEntry. The object ipoaArpRemoteSrvrOperStatus SHOULD have a value of up(1) when an SVC has been established to the Remote ATMARP Server or if using a PVC when the InATMARP reply with the IP Address of the Remote ATMARP Server has been received. The value of down(2) SHOULD be used to indicate that a VC to the Remote ATMARP Server doesn't exist. 3.1.4. ATM VC Table An entry in the ipoaVcTable SHOULD have at least one corresponding ipNetToMediaTable entry. Both tables use the ipNetToMediaTable's indexes ipNetToMediaIfIndex and ipNetToMediaNetAddress. The ipoaVcTable has the additional indexes ipoaVcVpi and ipoaVcVci. An ipoaVcEntry exists for every VC per ATM interface per destination IP address. Refer to the following diagram that illustrates the relationship between ipoaVcTable and the ipNetToMediaTable: ipoaVcTable ipNetToMediatable ------------------------------ ---------------------------- | ipNetToMediaIfIndex | | ipNetToMediaIfIndex | | ipNetToMediaNetAddress | | ipNetToMediaNetAddress | | ipoaVcVpi | | | | ipoaVcVci | | | | ipoaVcType | | | | ---> use IpoaAtmAddr TC | | ipNetToMediaPhysAddress | | ipoaVcNegotiatedEncapsType | | | | ipoaVcNegotiatedMtu | | | | | | ipNetToMediaType | ------------------------------ ---------------------------- ipoaVcType indicates if the entry is for an SVC or a PVC. An ipoaVcEntry, corresponding to an PVC, is created automatically when an ipoaConfigPvcEntry is created and the IP Address at the end of the PVC is discovered. The associating ipNetToMediaTable entry would have its ipNetToMediaType set to static(4). ipNetToMediaTable entries created during ATMARP processing have a ipNetToMediaType of dynamic(3). The process to locally configuring an ipNetToMediaTable entry and an ipoaVcTable entry for an SVC without using ATMARP is not within the scope of this document. Greene, et al. [Page 8] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 The objects ipoaVcVpi and ipoaVcVci are defined to have a MAX-ACCESS of not-accessible since they are only used for purposes of indexing an entry in the ipoaVcTable. 3.1.5. ATM Config PVC Table An entry in the ipoaVcTable is created after the InATMARP reply is successfully received for an ipoaConfigPvcEntry during its activation. InATMARP should return the IP Address of the other end of the PVC in order to have the needed indexes to create an ipNetToMediaEntry and an ipoaVcEntry. The corresponding ARP Cache entry SHOULD be deleted whenever a PVC becomes unusable. A Network Management Station wanting to create a PVC at a particular system for use as an IP transport would: o use the ATM-MIB, reference [4], to create the PVC o use the ipoaConfigPvcTable in the IPOA-MIB to configure the PVC for use by IP Refer to the following diagram that illustrates the relationship between the ipoaVcTable and the ipoaConfigPvcTable: ipoaVcTable ipoaConfigPvcTable ------------------------------ ---------------------------- | ipNetToMediaIfIndex | | ipNetToMediaIfIndex | | ipNetToMediaNetAddress | | | | ipoaVcVpi | | ipoaConfigPvcVpi | | ipoaVcVci | | ipoaConfigPvcVci | | ipoaVcType | | | | | | ipoaConfigPvcDefaultMtu | | ipoaVcNegotiatedEncapsType | | | | ipoaVcNegotiatedMtu | | | | | | ipoaConfigPvcRowStatus | ------------------------------ ---------------------------- When the ipoaVcEntry is created its ipoaVcType will be set to pvc(1), its ipoaVcNegotiatedEncapsType set to llcSnap(1), and its ipoaVcNegotiatedMtu set to 9180 octets by default. Classical IP and ARP over ATM [3] allows use of other MTU values for PVCs but considers the selection of a value other than 9180 to be out of scope. ipoaConfigPvcDefaultMtu can be used to configure the MTU to be used for the PVC. Both ends MUST have the same value configured. The associating ipNetToMediaTable entry would have its ipNetToMediaType set to static(4). Greene, et al. [Page 9] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 Changing ipoaConfigPvcRowStatus from active(1) to notInService(2) or from active(1) to destroy(6) has the side-effect of removing the corresponding ipNetToMediaTable, ipoaVcTable, and ipoaConfigPvcTable entries. 3.1.6. Notifications Both ATM clients and ATMARP Servers MUST support generation of an ipoaMtuExceeded notification. 3.2. Client Supported MIB Definitions The ATMARP Client Table is the only additional MIB table that a client MUST implement. Greene, et al. [Page 10] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 3.2.1. ATMARP Client Table An entry in the ipoaArpClientTable SHOULD have a corresponding ipAddrTable entry where both are indexed by the same ipAdEntAddr value. Refer to the following diagram that illustrates the relationship between ipoaArpClientTable and ipAddrTable entries: ipoaArpClientTable ipAddrTable ----------------------------------- ------------------------ | ipAdEntAddr | | ipAdEntAddr | | | | ipAdEntNetMask | | | | ipAdEntIfIndex | | ipoaArpClientAtmAddr | | | | ipoaArpClientSrvrInUse | | | | ipoaArpClientInArpInReqs | | | | ipoaArpClientInArpOutReqs | | | | ipoaArpClientInArpInReplies | | | | ipoaArpClientInArpOutReplies | | | | ipoaArpClientInArpInvalidInReqs | | | | ipoaArpClientInArpInvalidOutReqs| | | | ipoaArpClientArpInReqs | | | | ipoaArpClientArpOutReqs | | | | ipoaArpClientArpInReplies | | | | ipoaArpClientArpOutReplies | | | | ipoaArpClientArpInNaks | | | | ipoaArpClientArpOutNaks | | | | ipoaArpClientArpUnknownOps | | | | ipoaArpClientArpNoSrvrResps | | | | ipoaArpClientRowStatus | | | | | | ipAdEntBcastAddr | | | | ipAdEntReasmMaxSize | ----------------------------------- ------------------------ Both tables have the same index, ipAdEntAddr. The ipAddrTable's ipAdEntNetMask when ANDed with its corresponding ipAdEntAddr yield the subnet of the LIS which can be used as an index into the ipoaLisTable (ipoaLisSubnetAddr). The ipAddrTable's ipAdEntIfIndex points to an interface ifTable entry via an ifIndex value. The attachment point for IP into an ATM network is via an ATM interface's ifIndex. Each ipoaArpClientEntry MUST point to an ATM interface via its corresponding ipAddrEntry. ipoaArpClientAtmAddr is the local ATM address associated with the corresponding ATM ifTable entry. ipoaArpClientSrvrInUse is the ATM address of the ATMARP Server being used for a particular client. If SVCs are not being used then the value of this object is a zero-length OCTET STRING. Greene, et al. [Page 11] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 It is sometimes possible for a system to have multiple IP addresses configured within the same IP subnet. The indexing of this table would seem to preclude that. However, it is possible to have additional entries in the ipAddrTable with the same ifIndex and with the same subnet address. The mechanism for adding these multiple entries to the ipAddrTable (which is read-only) is beyond the scope of this document. The counter object ipoaArpClientInArpInvalidInReqs is "The number of times that this client detected an invalid InATMARP request." This object SHOULD be incremented when processing fails for an InATMARP request (e.g., for incorrect InATMARP request structure fields). The object ipoaArpClientInArpInvalidOutReqs is defined as "The number of times that this client did not receive an InATMARP reply." This is different from ipoaArpClientArpNoSrvrResps which counts the number of times no response was received from an ATMARP request. InATMARP retransmission processing is not controlled by objects in the ipoaLisTable. In general, the ipoaLisTable objects relate to ATMARP Server processing. Configuration of InATMARP retransmission processing is considered to be implementation dependent and not defined by the IPOA-MIB. Implementations SHOULD use local policy for defining both InATMARP timeout and retry count values. This policy would be expected to differ for sending an InATMARP Request over a PVC as opposed to an SVC. For transmission of an InATMARP Request over a SVC a timeout of 60 seconds with a retry count of 3 is suggested. InATMARP transmission over a PVC should differ since its retry limit may need to be infinite in order to ensure that InATMARP Request processing eventually occurs. 3.3. Server Supported MIB Definitions ATMARP Servers MUST support: o ATMARP Server Table o Notifications as defined in the following sections. This table exists only on a system where at least one ATMARP Server is present. 3.3.1. ATMARP Server Table This table defines the list of ATMARP Servers within a LIS. Each entry of the table defines each ATMARP Server's ATM address, the LIS it is a member of, and various InATMARP and ATMARP statistics. Greene, et al. [Page 12] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 An entry in this table provides information about an ATMARP Server within a LIS and is indexed by ipAdEntAddr (a local IP Address from an IP Address Table entry) and ipoaArpSrvrAddr (an ATM Address associated with the ATMARP Server). Entries MAY be created by a management application using the ipoaArpSrvrRowStatus object. Entries in this table MAY also be created by the system and not by a management application, for example via ILMI. Entries in this table MAY be deleted by setting the ipoaArpSrvrRowStatus object to destroy(6). This includes entries that were added by the system and not by a management application. On a host that supports multiple ATMARP Servers where the local IP address being associated with each ATMARP Server is the same (for example a non-multihomed host), the ATM Address (ipoaArpSrvrAddr) uniquely identifies a particular ATMARP Server. On a host supporting multiple ATMARP Servers having a single ATM Interface with a single ATM Address, the ipAdEntAddr MUST be used to uniquely identify an entry in the ipoaArpSrvrTable. The indexing of the ipoaArpSrvrTable does not allow entries with the same or no local IP Address (ipAdEntAddr) and the same ATM Address (ipoaArpSrvrAddr) to exist. The values of the index elements when combined to index a row must be unique. 3.3.2. Notifications An ATMARP Server MUST support the following notifications: o ipoaDuplicateIpAddress o ipoaLisCreate o ipoaLisDelete Generation of ipoaLisCreate and ipoaLisDelete notifications is controlled by the ipoaLisTrapEnable object. These notifications indicate when an ipoaLisEntry is either created or deleted. The purpose of these notifications is to enable Network Management Applications to dynamically discover the existence of ATMARP Server LIS participation in order to eventually determine LIS composition via subsequent SNMP queries. It is permissible for an ATM client-only system to support the ipoaLisTrapEnable object and generate ipoaLisCreate and ipoaLisDelete notifications. Greene, et al. [Page 13] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 4. Definitions IPOA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, transmission, Integer32, IpAddress, Counter32, Gauge32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ipNetToMediaNetAddress, ipNetToMediaIfIndex, ipNetToMediaPhysAddress, ipAdEntAddr FROM IP-MIB -- The following textual conventions are defined locally within -- this MIB module. They have been prefixed with 'Ipoa' to -- distinguish them from their counterparts in the ATM-TC-MIB. -- This was done so that the IPOA-MIB could be advanced as -- a standards-based MIB without waiting for the ATM-TC-MIB. -- AtmConnKind, AtmAddr -- FROM ATM-TC-MIB InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB ; ipoaMIB MODULE-IDENTITY LAST-UPDATED "9802090000Z" -- February 9, 1998 ORGANIZATION "IETF Internetworking Over NBMA Working Group (ion)" CONTACT-INFO "Maria Greene (greene@xedia.com) Xedia Corp. Jim Luciani (jluciani@BayNetworks.com) Bay Networks Kenneth White (kennethw@vnet.ibm.com) IBM Corp. Ted Kuo (tkuo@eos.ncsu.edu) Bay Networks" DESCRIPTION "This module defines a portion of the management Greene, et al. [Page 14] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 information base (MIB) for managing Classical IP and ARP over ATM entities." ::= { transmission 46 } -- Textual Conventions IpoaEncapsType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The encapsulation type used on a VC." SYNTAX INTEGER { llcSnap(1), vcMuxed(2), other(3) } IpoaVpiInteger ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer large enough to contain the value of a VPI." SYNTAX Integer32 (0..255) IpoaVciInteger ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An integer large enough to contain the value of a VCI." SYNTAX Integer32 (0..65535) IpoaAtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "The ATM address used by the network entity. The semantics are implied by the length. The address types are: - no address (0 octets) - E.164 (8 octets) - NSAP (20 octets) In addition, when subaddresses are used IpoaAtmAddr may represent the concatenation of address and subaddress. The associated address types are: - E.164, E.164 (16 octets) - E.164, NSAP (28 octets) - NSAP, NSAP (40 octets) Greene, et al. [Page 15] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 Address lengths other than defined in this definition imply address types defined elsewhere. Note: The E.164 address is encoded in BCD format." SYNTAX OCTET STRING (SIZE(0..40)) IpoaAtmConnKind ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The use of call control. The use is as follows: pvc(1) Virtual link of a PVC. Should not be used in a PVC/SVC (i.e., SPVC) crossconnect. svcIncoming(2) Virtual link established after a received signaling request to setup an SVC. svcOutgoing(3) Virtual link established after a transmitted or forwarded signaling request to setup an SVC. spvcInitiator(4) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the initiator of the SPVC setup. spvcTarget(5) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the target of the SPVC setup. An spvcInitiator is always cross-connected to an svcOutgoing, and an spvcTarget is always cross-connected to an svcIncoming." SYNTAX INTEGER { pvc(1), svcIncoming(2), svcOutgoing(3), spvcInitiator(4), spvcTarget(5) } -- Top-level structure of the MIB ipoaObjects OBJECT IDENTIFIER ::= { ipoaMIB 1 } ipoaNotifications OBJECT IDENTIFIER ::= { ipoaMIB 2 } ipoaConformance OBJECT IDENTIFIER ::= { ipoaMIB 3 } Greene, et al. [Page 16] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 -- MIB Objects ipoaLisTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether ipoaLisCreate and ipoaLisDelete traps should be generated by this system. By default, this object should have the value enabled(1) for systems where ATMARP Servers are present and disabled(2) on systems where only clients reside." ::= { ipoaObjects 1 } -- The ATM Logical IP Subnet (LIS) Table ipoaLisTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaLisEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There is one entry in this table for every Logical IP Subnet (LIS) of which this system is a member. The bulk of the objects in an ipoaLisEntry exists to control ATMARP for a particular LIS. In a PVC only environment it is implementation dependent as to whether this table should be supported." ::= { ipoaObjects 2 } ipoaLisEntry OBJECT-TYPE SYNTAX IpoaLisEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single LIS of which this system is a member. Membership in a LIS is independent of the actual ATM interfaces being used. The ipoaLisTable defines all LISs that a system is a member of. The ipAddrTable and the ipoaClientTable provides the mapping from local IP address to ATM interface. The ipoaLisIfMappingTable provides the mappings between Logical IP Subnets and interfaces. Greene, et al. [Page 17] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 The ipoaLisTable is indexed by ipoaLisSubnetAddr (IP subnet address). An entry in the ipoaLisTable should exist for each ipAddrEntry that is associated with an ATM related interface used for Classical IP and ARP over ATM traffic. Its ipAdEntAddr and ipAdEntNetMask when ANDed together should equal the ipoaLisSubnetAddr of the corresponding ipoaLisEntry." INDEX { ipoaLisSubnetAddr } ::= { ipoaLisTable 1 } IpoaLisEntry ::= SEQUENCE { ipoaLisSubnetAddr IpAddress, ipoaLisDefaultMtu Integer32, ipoaLisDefaultEncapsType IpoaEncapsType, ipoaLisInactivityTimer Integer32, ipoaLisMinHoldingTime Integer32, ipoaLisQDepth Integer32, ipoaLisMaxCalls Integer32, ipoaLisCacheEntryAge Integer32, ipoaLisRetries Integer32, ipoaLisTimeout Integer32, ipoaLisDefaultPeakCellRate Integer32, ipoaLisActiveVcs Gauge32, ipoaLisRowStatus RowStatus } ipoaLisSubnetAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP subnet address associated with this LIS." ::= { ipoaLisEntry 1 } ipoaLisDefaultMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The default MTU used within this LIS. Note that the actual MTU used for a VC between two members of the LIS may be negotiated during connection setup and may be different than this value. The ipoaVcNegotiatedMtu object indicates the actual MTU in use for a particular VC." DEFVAL { 9180 } Greene, et al. [Page 18] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ::= { ipoaLisEntry 2 } ipoaLisDefaultEncapsType OBJECT-TYPE SYNTAX IpoaEncapsType MAX-ACCESS read-create STATUS current DESCRIPTION "The default encapsulation to use on VCs created for this LIS. Note that the actual encapsulation type may be negotiated during connection setup and may be different than this value. The ipoaVcNegotiatedEncapsType object indicates the actual encapsulation in use for a particular VC." DEFVAL { llcSnap } ::= { ipoaLisEntry 3 } ipoaLisInactivityTimer OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time, in seconds, before a call established for an ipNetToMediaEntry on a client will timeout due to no traffic being passed on the VC. A value of 0 implies no time out." REFERENCE "RFC 1755, Sec. 3.4 VC Teardown" DEFVAL { 1200 } ::= { ipoaLisEntry 4 } ipoaLisMinHoldingTime OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum amount of time, in seconds, that a call will remain open. If 0 then ipoaInactivityTimer will completely determine when a call is terminated." REFERENCE "RFC 1755, Sec. 3.4 VC Teardown" DEFVAL { 60 } ::= { ipoaLisEntry 5 } ipoaLisQDepth OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "packets" Greene, et al. [Page 19] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of outstanding requests that are allowed while waiting for ATMARP replies and InATMARP replies for this LIS." DEFVAL { 1 } ::= { ipoaLisEntry 6 } ipoaLisMaxCalls OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of SVCs that can be established simultaneously for this LIS." DEFVAL { 500 } ::= { ipoaLisEntry 7 } ipoaLisCacheEntryAge OBJECT-TYPE SYNTAX Integer32 (60..1200) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time, in seconds, before an ipNetToMediaEntry will age out of the table. Note that the default value will be different for a client and a server. An ATMARP Server should use a default of 1200 and a client should use 900." DEFVAL { 900 } ::= { ipoaLisEntry 8 } ipoaLisRetries OBJECT-TYPE SYNTAX Integer32 (0..10) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times the ATMARP request will be retried when no response is received in the timeout interval indicated by ipoaLisTimeout." DEFVAL { 2 } ::= { ipoaLisEntry 9 } ipoaLisTimeout OBJECT-TYPE SYNTAX Integer32 (1..60) UNITS "seconds" MAX-ACCESS read-create Greene, et al. [Page 20] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 STATUS current DESCRIPTION "The time to wait, in seconds, before retransmission of an ARP request." DEFVAL { 10 } ::= { ipoaLisEntry 10 } ipoaLisDefaultPeakCellRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object is the signalling parameter that should be used when setting up all best effort VCCs (Virtual Channel Connections). This parameter applies to the forward and backward direction on a per best effort VCC basis. A value of zero implies that no configured default exists and that local policy should be used to determine the actual default to used during call setup. ATM Signaling Support for IP over ATM (RFC 1755) recommends 1/10th of the ATM interface's speed." ::= { ipoaLisEntry 11 } ipoaLisActiveVcs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of active SVCs for this LIS." ::= { ipoaLisEntry 12 } ipoaLisRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the ipoaLisTable. When the ipoaLisRowStatus deleted (by setting this object to destroy(6)), this has the side-effect of removing all entries from the ipNetToMediaTable that are associated with this LIS (in other words, it flushes the entity's ATMARP cache). It also removes the ipoaVcTable entries that were associated with those ipNetToMediaTable entries. Destroying the row also Greene, et al. [Page 21] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 removes the corresponding entries in the ipoaArpSrvrTable, ipoaArpClientTable, ipoaLisIfMappingTable, and ipoaArpRemoteSrvrTable. Entries in both the ipNetToMediaTable and the ipoaVcTable that are associated with a ipoaConfigPvcEntry are not affected by changes to ipoaLisRowStatus." REFERENCE "RFC 1903, 'Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaLisEntry 13 } -- The ATM Logical IP Subnet Interface Mapping Table ipoaLisIfMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaLisIfMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There is one entry in this table for every combination of ipoaLisEntry and IP over ATM interface." ::= { ipoaObjects 3 } ipoaLisIfMappingEntry OBJECT-TYPE SYNTAX IpoaLisIfMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipoaLisIfMappingTable." INDEX { ipoaLisSubnetAddr, ipoaLisIfMappingIfIndex } ::= { ipoaLisIfMappingTable 1 } IpoaLisIfMappingEntry ::= SEQUENCE { ipoaLisIfMappingIfIndex InterfaceIndex, ipoaLisIfMappingRowStatus RowStatus } ipoaLisIfMappingIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ipAdEntIfIndex object from an ipAddrEntry is used as an index to this table when its ipAdEntAddr is in the subnet implied by ipoaLisSubnetAddr." Greene, et al. [Page 22] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ::= { ipoaLisIfMappingEntry 1 } ipoaLisIfMappingRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the ipoaLisIfMappingTable." REFERENCE "RFC 1903, 'Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaLisIfMappingEntry 2 } -- The ATMARP Client Table ipoaArpClientTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaArpClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATMARP clients running on this system." ::= { ipoaObjects 4 } ipoaArpClientEntry OBJECT-TYPE SYNTAX IpoaArpClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single ATMARP Client. Clients can be started and stopped by adding and removing entries from this table. An entry in the ipoaArpClientTable has a corresponding entry in the ipAddrTable. Both are indexed by ipAdEntAddr. The ifIndex and subnet mask of a client entry are the ipAddrEntry's ipAdEntIfIndex and ipAdEntNetMask, respectively. Note that adding and removing entries from this table may have the same effect on the corresponding ipAddrTable entry. Row creation of an entry in this table requires that either the corresponding ipAddrTable entry exists or that ipAdEntIfIndex and ipAdEntNetMask be specified in the creation of an ipoaArpClientEntry at a minimum in order to create the corresponding ipAddrEntry. Specification of ipAdEntBcastAddr and ipAdEntReasmMaxSize to complete an ipAddrEntry is implementation dependent. Greene, et al. [Page 23] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 Whether a corresponding ipAddrEntry is deleted during the deletion of an ipoaArpClientEntry is considered implementation dependent." INDEX { ipAdEntAddr } ::= { ipoaArpClientTable 1 } IpoaArpClientEntry ::= SEQUENCE { ipoaArpClientAtmAddr IpoaAtmAddr, ipoaArpClientSrvrInUse IpoaAtmAddr, ipoaArpClientInArpInReqs Counter32, ipoaArpClientInArpOutReqs Counter32, ipoaArpClientInArpInReplies Counter32, ipoaArpClientInArpOutReplies Counter32, ipoaArpClientInArpInvalidInReqs Counter32, ipoaArpClientInArpInvalidOutReqs Counter32, ipoaArpClientArpInReqs Counter32, ipoaArpClientArpOutReqs Counter32, ipoaArpClientArpInReplies Counter32, ipoaArpClientArpOutReplies Counter32, ipoaArpClientArpInNaks Counter32, ipoaArpClientArpOutNaks Counter32, ipoaArpClientArpUnknownOps Counter32, ipoaArpClientArpNoSrvrResps Counter32, ipoaArpClientRowStatus RowStatus } ipoaArpClientAtmAddr OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The ATM address of the client." ::= { ipoaArpClientEntry 1 } ipoaArpClientSrvrInUse OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS read-only STATUS current DESCRIPTION "The ATM address of the ATMARP Server, ipoaArpRemoteSrvrAtmAddr, in use by this client. A zero length octet string implies that communication with a Remote ATMARP Server is not in effect." DEFVAL { ''H } ::= { ipoaArpClientEntry 2 } ipoaArpClientInArpInReqs OBJECT-TYPE SYNTAX Counter32 Greene, et al. [Page 24] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests received by this client." ::= { ipoaArpClientEntry 3 } ipoaArpClientInArpOutReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests sent by this client." ::= { ipoaArpClientEntry 4 } ipoaArpClientInArpInReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP replies received by this client." ::= { ipoaArpClientEntry 5 } ipoaArpClientInArpOutReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of InATMARP replies sent by this client." ::= { ipoaArpClientEntry 6 } ipoaArpClientInArpInvalidInReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this client detected an invalid InATMARP request." ::= { ipoaArpClientEntry 7 } ipoaArpClientInArpInvalidOutReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this client did not receive an InATMARP reply." Greene, et al. [Page 25] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ::= { ipoaArpClientEntry 8 } ipoaArpClientArpInReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP requests received by this client." ::= { ipoaArpClientEntry 9 } ipoaArpClientArpOutReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP requests sent by this client." ::= { ipoaArpClientEntry 10 } ipoaArpClientArpInReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP replies received by this client." ::= { ipoaArpClientEntry 11 } ipoaArpClientArpOutReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP replies sent by this client." ::= { ipoaArpClientEntry 12 } ipoaArpClientArpInNaks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of negative ATMARP replies received by this client." ::= { ipoaArpClientEntry 13 } ipoaArpClientArpOutNaks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Greene, et al. [Page 26] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 STATUS current DESCRIPTION "Total number of negative ATMARP replies sent by this client. Classic IP and ARP over ATM does not require an ATMARP client to transmit an ATMARP_NAK upon receipt of an ATMARP request from another ATMARP client. However, implementation experience has shown that this error condition is somewhat easy to create inadvertently by configuring one ATMARP client with an ipoaArpRemoteSrvrTable entry containing an ipoaArpRemoteSrvrAtmAddr value which is the ATM address of another ATMARP client-only system. If an ATMARP client supports the transmission of ATMARP_NAKs, then it should increment ipoaArpClientArpOutNaks each time it transmits an ATMARP_NAK. Otherwise, support of this object is considered optional." ::= { ipoaArpClientEntry 14 } ipoaArpClientArpUnknownOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this client received an ATMARP message with an operation code for which it is not coded to support." ::= { ipoaArpClientEntry 15 } ipoaArpClientArpNoSrvrResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this client failed to receive a response from a ATMARP Server within the ipoaLisTimeout value for ipoaLisRetries times. This may imply that the client will re-elect a new primary ATMARP Server for this LIS from the ipoaArpRemoteSrvrTable." ::= { ipoaArpClientEntry 16 } ipoaArpClientRowStatus OBJECT-TYPE SYNTAX RowStatus Greene, et al. [Page 27] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted from the ipoaArpClientTable." REFERENCE "RFC 1903, 'Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaArpClientEntry 17 } -- The ATMARP Server Table ipoaArpSrvrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATMARP Servers running on this system." ::= { ipoaObjects 5 } ipoaArpSrvrEntry OBJECT-TYPE SYNTAX IpoaArpSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an ATMARP Server within a LIS. An entry in this table has two indexes: first ipAdEntAddr, which is the IP address that this system uses as a member of the LIS, and then ipoaArpSrvrAddr, which is the ATM address of the ATMARP Server. Entries may be created by a management application using the ipoaArpSrvrRowStatus object. Entries in this table may also be created by the system and not by a management application, for example via ILMI. Entries in this table may be deleted by setting the ipoaArpSrvrRowStatus object to 'destroy(6)'. This includes entries that were added by the system and not by a management application." INDEX { ipAdEntAddr, ipoaArpSrvrAddr } ::= { ipoaArpSrvrTable 1 } IpoaArpSrvrEntry ::= SEQUENCE { ipoaArpSrvrAddr IpoaAtmAddr, ipoaArpSrvrLis IpAddress, ipoaArpSrvrInArpInReqs Counter32, ipoaArpSrvrInArpOutReqs Counter32, Greene, et al. [Page 28] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ipoaArpSrvrInArpInReplies Counter32, ipoaArpSrvrInArpOutReplies Counter32, ipoaArpSrvrInArpInvalidInReqs Counter32, ipoaArpSrvrInArpInvalidOutReqs Counter32, ipoaArpSrvrArpInReqs Counter32, ipoaArpSrvrArpOutReplies Counter32, ipoaArpSrvrArpOutNaks Counter32, ipoaArpSrvrArpDupIpAddrs Counter32, ipoaArpSrvrArpUnknownOps Counter32, ipoaArpSrvrRowStatus RowStatus } ipoaArpSrvrAddr OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM address of the ATMARP Server." ::= { ipoaArpSrvrEntry 1 } ipoaArpSrvrLis OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The subnet address that identifies the LIS with which this server is associated." ::= { ipoaArpSrvrEntry 2 } ipoaArpSrvrInArpInReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests received by this ATMARP Server." ::= { ipoaArpSrvrEntry 3 } ipoaArpSrvrInArpOutReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP requests sent by this ATMARP Server." ::= { ipoaArpSrvrEntry 4 } ipoaArpSrvrInArpInReplies OBJECT-TYPE Greene, et al. [Page 29] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP replies received by this ATMARP Server." ::= { ipoaArpSrvrEntry 5 } ipoaArpSrvrInArpOutReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of InATMARP replies sent by this ATMARP Server." ::= { ipoaArpSrvrEntry 6 } ipoaArpSrvrInArpInvalidInReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid InATMARP requests received by this ATMARP Server." ::= { ipoaArpSrvrEntry 7 } ipoaArpSrvrInArpInvalidOutReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this server did not receive an InATMARP reply." ::= { ipoaArpSrvrEntry 8 } ipoaArpSrvrArpInReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ATMARP requests received by this ATMARP Server." ::= { ipoaArpSrvrEntry 9 } ipoaArpSrvrArpOutReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Greene, et al. [Page 30] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 DESCRIPTION "Total number of ATMARP replies sent by this ATMARP Server." ::= { ipoaArpSrvrEntry 10 } ipoaArpSrvrArpOutNaks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of negative ATMARP replies sent by this ATMARP Server." ::= { ipoaArpSrvrEntry 11 } ipoaArpSrvrArpDupIpAddrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a duplicate IP address was detected by this ATMARP Server." ::= { ipoaArpSrvrEntry 12 } ipoaArpSrvrArpUnknownOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this ATMARP Server received an ATMARP message with an operation code for which it is not coded to support." ::= { ipoaArpSrvrEntry 13 } ipoaArpSrvrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted from the ipoaArpSrvrTable." REFERENCE "RFC 1903, 'Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaArpSrvrEntry 14 } -- The Remote ATMARP Server Table ipoaArpRemoteSrvrTable OBJECT-TYPE Greene, et al. [Page 31] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 SYNTAX SEQUENCE OF IpoaArpRemoteSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of non-local ATMARP Servers associated with a LIS. An entry in this table has three indexes: first the ipoaLisSubnetAddr of the LIS for which the corresponding ATMARP Server provides ATMARP services, then the ipoaArpRemoteSrvrAtmAddr, which is the ATM address of the remote ATMARP Server, and finally the ifIndex of the interface on which the VC to the ATMARP Remote Server will be opened. An ifIndex value of 0 should be used when a single VC is to be shared for ATMARP purposes by multiple interfaces." ::= { ipoaObjects 6 } ipoaArpRemoteSrvrEntry OBJECT-TYPE SYNTAX IpoaArpRemoteSrvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one non-local ATMARP Server." INDEX { ipoaLisSubnetAddr, ipoaArpRemoteSrvrAtmAddr, ipoaArpRemoteSrvrIfIndex } ::= { ipoaArpRemoteSrvrTable 1 } IpoaArpRemoteSrvrEntry ::= SEQUENCE { ipoaArpRemoteSrvrAtmAddr IpoaAtmAddr, ipoaArpRemoteSrvrRowStatus RowStatus, ipoaArpRemoteSrvrIfIndex InterfaceIndexOrZero, ipoaArpRemoteSrvrIpAddr IpAddress, ipoaArpRemoteSrvrAdminStatus INTEGER, ipoaArpRemoteSrvrOperStatus INTEGER } ipoaArpRemoteSrvrAtmAddr OBJECT-TYPE SYNTAX IpoaAtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM address of the remote ATMARP Server." ::= { ipoaArpRemoteSrvrEntry 1 } ipoaArpRemoteSrvrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Greene, et al. [Page 32] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 "This object allows entries to be created and deleted from the ipoaArpRemoteSrvrTable. Deleting an ipoaArpRemoteSrvrEntry (by setting this object to destroy(6)) may affect ipoaArpClientTable entries. The object ipoaArpClientSrvrInUse in an ipoaArpClientSrvrEntry may contain the ATM address of an ATMARP Remote Server whose entry in the ipoaArpRemoteSrvrTable is being removed. In this case, any corresponding ipoaArpClientSrvrInUse objects should be at a minimum invalidated by setting their values to that of a zero length OCTET STRING. The value of ipoaArpRemoteSrvrOperStatus should be consistent with that of ipoaArpRemoteSrvrRowStatus. For example, successfully setting the value of this object to notInService(2) after its being in the up(1) state should result in ipoaArpRemoteSrvrOperStatus being set to down(2) if currently up(1)." REFERENCE "RFC 1903, 'Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaArpRemoteSrvrEntry 2 } ipoaArpRemoteSrvrIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the interface that the VC to the Remote ATMARP Server is associated with." ::= { ipoaArpRemoteSrvrEntry 3 } ipoaArpRemoteSrvrIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the Remote ATMARP Server. A value of 0.0.0.0 implies that this address isn't known." DEFVAL { '00000000'H } ::= { ipoaArpRemoteSrvrEntry 4 } ipoaArpRemoteSrvrAdminStatus OBJECT-TYPE SYNTAX INTEGER { Greene, et al. [Page 33] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 up(1), -- use this ATMARP Server down(2) -- stop using this ATMARP Server } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state for use of the ATMARP Server represented by an entry in this table. ipoaArpRemoteSrvrAdminStatus values: up(1) - Attempt to activate use of the ATMARP Server represented by this entry in the ipoaArpRemoteSrvrTable. down(2) - Deactivate use of this ATMARP Server. When a managed system creates an entry in this table ipoaArpRemoteSrvrAdminStatus and ipoaArpRemoteSrvrOperStatus are initialized as down(2) by default." DEFVAL { down } ::= { ipoaArpRemoteSrvrEntry 5 } ipoaArpRemoteSrvrOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- eligible for use down(2) -- not eligible for use } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state for use of a Remote ATMARP Server. An up(1) entry has a VC established to the respective Remote ATMARP Server: up(1) - A VC exists to Remote ATMARP Server whose IP Address is stored in ipoaArpRemoteSrvrIpAddr. This VC can be determined by searching the ipoaVcTable using ipoaArpRemoteSrvrIfIndex (if not 0, otherwise ignore ipNetToMediaIfIndex index) and ipoaArpRemoteSrvrIpAddr. An ipoaArpClientEntry should exist with its ipoaArpClientSrvrInUse object having the same value as ipoaArpRemoteSrvrAtmAddr. Greene, et al. [Page 34] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 down(2) - Entry exists without an active VC to the Remote ATMARP Server. Transition from up(1) to down(2) status may affect ipoaArpClientTable entries. The object ipoaArpClientSrvrInUse in an ipoaArpClientSrvrEntry may contain the ATM address of an ATMARP Remote Server whose entry in the ipoaArpRemoteSrvrTable is being deactivated. In this case, any corresponding ipoaArpClientSrvrInUse objects should be at a minimum invalidated by setting their values to that of a zero length OCTET STRING. If ipoaArpRemoteSrvrAdminStatus is down(2) then ipoaArpRemoteSrvrOperStatus should be down(2). If ipoaArpRemoteSrvrAdminStatus is changed to up(1) then ipoaArpRemoteSrvrOperStatus should change to up(1) if the Remote ATMARP Server entry can be activated." DEFVAL { down } ::= { ipoaArpRemoteSrvrEntry 6 } -- The ATM VC Table ipoaVcTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A system that supports IP over ATM is an IP system and therefore MUST support all of the appropriate tables in the SNMPv2-MIB (RFC 1907), the IF-MIB (RFC 2233), the IP-MIB (RFC 2011), the TCP-MIB (RFC 2012), and the UDP-MIB (RFC 2013). This includes the ipNetToMediaTable (the ARP cache) that is defined within the IP-MIB (RFC 2011). The ipoaVcTable keeps a set of VCs for each entry in the ARP cache that was put there by an IP over ATM system acting as either a host or server. The ipoaVcTable doesn't augment the ipNetToMediaTable (ARP Cache) since the the correspondence between tables is not necessarily one-to-one. An ipNetToMediaPhysAddress object should contain the content as defined by the IpoaAtmAddr textual convention when used to hold an IPOA-MIB ATM Address." ::= { ipoaObjects 7 } Greene, et al. [Page 35] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ipoaVcEntry OBJECT-TYPE SYNTAX IpoaVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A VC (permanent or switched) that this host or server has opened with another member of a LIS. Additional information can be determined about the VC from the ATM-MIB. Entries in this table cannot be created by management applications. In an SVC environment, an entry is automatically added by the system as the result of ATMARP processing. In a PVC environment, an entry is automatically added to this table when an entry is created in the ipoaConfigPvcTable and the IP Address at the remote end of the PVC is discovered using InATMARP. An entry also is added to the ipNetToMediaTable." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipoaVcVpi, ipoaVcVci } ::= { ipoaVcTable 1 } IpoaVcEntry ::= SEQUENCE { ipoaVcVpi IpoaVpiInteger, ipoaVcVci IpoaVciInteger, ipoaVcType IpoaAtmConnKind, ipoaVcNegotiatedEncapsType IpoaEncapsType, ipoaVcNegotiatedMtu Integer32 } ipoaVcVpi OBJECT-TYPE SYNTAX IpoaVpiInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value for the Virtual Circuit." ::= { ipoaVcEntry 1 } ipoaVcVci OBJECT-TYPE SYNTAX IpoaVciInteger MAX-ACCESS not-accessible STATUS current Greene, et al. [Page 36] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 DESCRIPTION "The VCI value for the Virtual Circuit." ::= { ipoaVcEntry 2 } ipoaVcType OBJECT-TYPE SYNTAX IpoaAtmConnKind MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the Virtual Circuit." ::= { ipoaVcEntry 3 } ipoaVcNegotiatedEncapsType OBJECT-TYPE SYNTAX IpoaEncapsType MAX-ACCESS read-only STATUS current DESCRIPTION "The encapsulation type used when communicating over this circuit." ::= { ipoaVcEntry 4 } ipoaVcNegotiatedMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The MTU used when communicating over this circuit." ::= { ipoaVcEntry 5 } -- The ATM Config PVC Table ipoaConfigPvcTable OBJECT-TYPE SYNTAX SEQUENCE OF IpoaConfigPvcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table MUST be supported when PVCs are intended to be supported in order to enable the setup of PVCs for use by IP." ::= { ipoaObjects 8 } ipoaConfigPvcEntry OBJECT-TYPE SYNTAX IpoaConfigPvcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a single PVC that exists at this host for use by IP." Greene, et al. [Page 37] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 INDEX { ipoaConfigPvcIfIndex, ipoaConfigPvcVpi, ipoaConfigPvcVci } ::= { ipoaConfigPvcTable 1 } IpoaConfigPvcEntry ::= SEQUENCE { ipoaConfigPvcIfIndex InterfaceIndex, ipoaConfigPvcVpi IpoaVpiInteger, ipoaConfigPvcVci IpoaVciInteger, ipoaConfigPvcDefaultMtu Integer32, ipoaConfigPvcRowStatus RowStatus } ipoaConfigPvcIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the ATM Interface that this PVC is associated with." ::= { ipoaConfigPvcEntry 1 } ipoaConfigPvcVpi OBJECT-TYPE SYNTAX IpoaVpiInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value for the Virtual Circuit." ::= { ipoaConfigPvcEntry 2 } ipoaConfigPvcVci OBJECT-TYPE SYNTAX IpoaVciInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value for the Virtual Circuit." ::= { ipoaConfigPvcEntry 3 } ipoaConfigPvcDefaultMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Classical IP and ARP over ATM allows use of other MTU values for PVCs but considers how a value other than 9180 could be selected to be out of scope. ipoaConfigPvcDefaultMtu can be used to configure the MTU to be used for the PVC. Greene, et al. [Page 38] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 Both ends MUST have the same value configured." DEFVAL { 9180 } ::= { ipoaConfigPvcEntry 4 } ipoaConfigPvcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows rows to be created and deleted in the ipoaConfigPvcTable. Creation of an entry in this table should eventually result in the creation of an ipNetToMediaEntry and a corresponding ipoaVcEntry after InATMARP has determined the destination address of the remote system that the PVC is connected to. Setting this object to destroy(6) should remove the corresponding ipNetToMediaTable and ipoaVcTable entries." REFERENCE "RFC 1903, 'Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { ipoaConfigPvcEntry 5 } -- Notifications ipoaTrapPrefix OBJECT IDENTIFIER ::= { ipoaNotifications 0 } ipoaMtuExceeded NOTIFICATION-TYPE OBJECTS { ipoaVcNegotiatedMtu } STATUS current DESCRIPTION "A frame was received that exceeds the negotiated MTU size. The VPI and VCI of the VC for which this condition was detected can be determined from the index values for ipoaVcNegotiatedMtu. In addition, the ifIndex and IP Address can be determined as well (refer to the ipoaVcTable)." ::= { ipoaTrapPrefix 1 } ipoaDuplicateIpAddress NOTIFICATION-TYPE OBJECTS { ipNetToMediaIfIndex, ipNetToMediaNetAddress, ipNetToMediaPhysAddress, ipNetToMediaPhysAddress Greene, et al. [Page 39] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 } STATUS current DESCRIPTION "The ATMARP Server has detected more than one ATM end point attempting to associate the same IP address with different ATM addresses." ::= { ipoaTrapPrefix 2 } ipoaLisCreate NOTIFICATION-TYPE OBJECTS { ipoaLisSubnetAddr } STATUS current DESCRIPTION "Generation of this trap occurs when an ipoaLisEntry is created while the ipoaLisTrapEnable.0 object has the value enabled(1)." ::= { ipoaTrapPrefix 3 } ipoaLisDelete NOTIFICATION-TYPE OBJECTS { ipoaLisSubnetAddr } STATUS current DESCRIPTION "Generation of this trap occurs when an ipoaLisEntry is deleted while the ipoaLisTrapEnable.0 object has the value enabled(1)." ::= { ipoaTrapPrefix 4 } -- Conformance Definitions ipoaGroups OBJECT IDENTIFIER ::= { ipoaConformance 1 } ipoaCompliances OBJECT IDENTIFIER ::= { ipoaConformance 2 } -- compliance statements ipoaCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the IPOA-MIB." MODULE -- this module MANDATORY-GROUPS { ipoaGeneralGroup, ipoaBasicNotificationsGroup } GROUP ipoaClientGroup Greene, et al. [Page 40] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 DESCRIPTION "This group is mandatory for all hosts where IP over ATM client support is present." GROUP ipoaSrvrGroup DESCRIPTION "This group is mandatory for all hosts where ATMARP Servers are present." GROUP ipoaSrvrNotificationsGroup DESCRIPTION "This group is mandatory for all hosts where ATMARP Servers are present." GROUP ipoaLisNotificationsGroup DESCRIPTION "This group is mandatory for all hosts where ATMARP client only support is present and ipoaLisTrapEnable is allowed to be set to enabled(1)." GROUP ipoaLisTableGroup DESCRIPTION "This group is mandatory for all entities which support IP over ATM SVCs. Support of objects in this group by IP over ATM clients which only support IP over ATM PVCs is optional." OBJECT ipoaLisDefaultMtu MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to change the default MTU from the value 9180. The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisDefaultEncapsType MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to specify the default encapsulation type for the LIS. The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisInactivityTimer MIN-ACCESS read-only DESCRIPTION Greene, et al. [Page 41] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisMinHoldingTime MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisQDepth MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisMaxCalls MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisCacheEntryAge MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisRetries MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to change the default number of times an ATMARP request will be retried when no response is received from the default of 2. The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisTimeout MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user Greene, et al. [Page 42] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 to change the default retransmission time from the default of 10 seconds. The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisDefaultPeakCellRate MIN-ACCESS read-only DESCRIPTION "Implementations that do not support IP over ATM SVC usage are not required to allow the user to specify a best effort default peak cell rate since typically the ipoaLisTable won't exist. The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisIfMappingRowStatus SYNTAX INTEGER { active(1) -- subset of RowStatus } MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipoaArpClientAtmAddr MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaArpSrvrLis MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaArpRemoteSrvrAdminStatus MIN-ACCESS read-only Greene, et al. [Page 43] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security. In this case the value of this object should be up(1) when a VC exists to the Remote ATMARP Server or otherwise down(2), and the agent should not allow a SET operation to this object." OBJECT ipoaConfigPvcDefaultMtu MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT ipoaLisRowStatus SYNTAX INTEGER { active(1) -- subset of RowStatus } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipoaArpClientRowStatus SYNTAX INTEGER { active(1) -- subset of RowStatus } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipoaArpRemoteSrvrRowStatus SYNTAX INTEGER { active(1) -- subset of RowStatus } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." Greene, et al. [Page 44] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 OBJECT ipoaArpSrvrRowStatus SYNTAX INTEGER { active(1) -- subset of RowStatus } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipoaConfigPvcRowStatus SYNTAX INTEGER { active(1) -- subset of RowStatus } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipoaArpClientArpOutNaks MIN-ACCESS not-accessible DESCRIPTION "Classic IP and ARP over ATM does not require an ATMARP client to transmit an ATMARP_NAK upon receipt of an ATMARP request from another ATMARP client. This object should be implemented when an ATMARP client supports the transmission of ATMARP_NAKs." ::= { ipoaCompliances 1 } -- units of conformance ipoaGeneralGroup OBJECT-GROUP OBJECTS { ipoaVcType, ipoaVcNegotiatedEncapsType, ipoaVcNegotiatedMtu, ipoaConfigPvcDefaultMtu, ipoaConfigPvcRowStatus } STATUS current DESCRIPTION "This group is mandatory for all IP over ATM entities." ::= { ipoaGroups 1 } Greene, et al. [Page 45] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ipoaClientGroup OBJECT-GROUP OBJECTS { ipoaArpClientAtmAddr, ipoaArpClientSrvrInUse, ipoaArpClientInArpInReqs, ipoaArpClientInArpOutReqs, ipoaArpClientInArpInReplies, ipoaArpClientInArpOutReplies, ipoaArpClientInArpInvalidInReqs, ipoaArpClientInArpInvalidOutReqs, ipoaArpClientArpInReqs, ipoaArpClientArpOutReqs, ipoaArpClientArpInReplies, ipoaArpClientArpOutReplies, ipoaArpClientArpInNaks, ipoaArpClientArpOutNaks, ipoaArpClientArpUnknownOps, ipoaArpClientArpNoSrvrResps, ipoaArpClientRowStatus } STATUS current DESCRIPTION "This group is mandatory for all hosts where an IP over ATM client is present." ::= { ipoaGroups 2 } ipoaSrvrGroup OBJECT-GROUP OBJECTS { ipoaArpSrvrLis, ipoaArpSrvrInArpInReqs, ipoaArpSrvrInArpOutReqs, ipoaArpSrvrInArpInReplies, ipoaArpSrvrInArpOutReplies, ipoaArpSrvrInArpInvalidInReqs, ipoaArpSrvrInArpInvalidOutReqs, ipoaArpSrvrArpInReqs, ipoaArpSrvrArpOutReplies, ipoaArpSrvrArpOutNaks, ipoaArpSrvrArpDupIpAddrs, ipoaArpSrvrArpUnknownOps, ipoaArpSrvrRowStatus } STATUS current DESCRIPTION "This group is mandatory for all hosts where ATMARP Servers are present." ::= { ipoaGroups 3 } Greene, et al. [Page 46] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ipoaBasicNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ipoaMtuExceeded } STATUS current DESCRIPTION "The notification which an IP over ATM entity is required to implement." ::= { ipoaGroups 4 } ipoaSrvrNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ipoaDuplicateIpAddress } STATUS current DESCRIPTION "The notification which an IP over ATM ATMARP Server is required to implement." ::= { ipoaGroups 5 } ipoaLisNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ipoaLisCreate, ipoaLisDelete } STATUS current DESCRIPTION "The LIS-related notifications which are required to be implemented by an IP over ATM ATMARP server, as well as by any IP over ATM client which allows ipoaLisTrapEnable to be set to enabled(1)." ::= { ipoaGroups 6 } ipoaLisTableGroup OBJECT-GROUP OBJECTS { ipoaLisTrapEnable, ipoaLisSubnetAddr, ipoaLisDefaultMtu, ipoaLisDefaultEncapsType, ipoaLisInactivityTimer, ipoaLisMinHoldingTime, ipoaLisQDepth, ipoaLisMaxCalls, ipoaLisCacheEntryAge, ipoaLisRetries, ipoaLisTimeout, ipoaLisDefaultPeakCellRate, ipoaLisActiveVcs, Greene, et al. [Page 47] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 ipoaLisRowStatus, ipoaLisIfMappingRowStatus, ipoaArpRemoteSrvrRowStatus, ipoaArpRemoteSrvrIpAddr, ipoaArpRemoteSrvrAdminStatus, ipoaArpRemoteSrvrOperStatus } STATUS current DESCRIPTION "This group is mandatory for all entities which support IP over ATM SVCs. Support of objects in this group by IP over ATM clients which only support IP over ATM PVCs is optional." ::= { ipoaGroups 7 } END 5. Security Considerations Certain management information defined in this MIB MAY be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. The method for this authentication is a function of the SNMP Administrative Framework, and has not been expanded by this MIB. Several objects in this MIB allow write access or provide for row creation. Allowing this support in a non-secure environment can have a negative effect on network operations. It is RECOMMENDED that implementers seriously consider whether set operations or row creation be allowed without providing, at a minimum, authentication of request origin. It is RECOMMENDED that without such support that the following objects be implemented as read-only: o ipoaLisDefaultMtu o ipoaLisDefaultEncapsType o ipoaLisInactivityTimer o ipoaLisMinHoldingTime o ipoaLisQDepth o ipoaLisMaxCalls o ipoaLisCacheEntryAge o ipoaLisRetries o ipoaLisTimeout o ipoaLisDefaultPeakCellRate o ipoaArpClientAtmAddr o ipoaArpSrvrLis Greene, et al. [Page 48] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 o ipoaArpRemoteSrvrAdminStatus, show status as being either up(1) when a VC exists to the Remote ATMARP Server or otherwise down(2). Don't allow set support. ipoaArpRemoteSrvrOperStatus would have the same value as ipoaArpRemoteSrvrAdminStatus. o ipoaConfigPvcDefaultMtu o ipoaLisRowStatus o ipoaArpClientRowStatus o ipoaArpRemoteSrvrRowStatus o ipoaArpSrvrRowStatus o ipoaConfigPvcRowStatus o ipoaLisIfMappingRowStatus 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments This document is a product of the Internetworking Over NBMA Working Group. The authors of this document would like to recognize Keith McCloghrie from Cisco Systems for his support as our mentor from the Network Management Area. Greene, et al. [Page 49] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 8. References [1] 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. [2] McCloghrie, K., and F. Kastenholtz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [3] Laubach M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998. [4] Ahmed, M., and K. Tesink, "Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2", RFC 1695, August 1994. [5] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [6] 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. [7] 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. [8] 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. [9] McCloghrie K., "Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996. [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Greene, et al. [Page 50] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 [11] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. [12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. 9. Authors' Addresses Maria N. Greene Xedia Corp. 119 Russell Dr. Littleton, MA 01460 EMail: maria@xedia.com James Luciani Bay Networks, Inc. 3 Federal St., BL3-04 Billerica, MA 01821, USA Phone: +1-508-439-4734 EMail: luciani@baynetworks.com Kenneth D. White Dept. G80/Bldg 503 IBM Corporation Research Triangle Park, NC 27709, USA EMail: kennethw@vnet.ibm.com Ted T.I. Kuo Bay Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95052-8185 Phone: +1-408-495-7319 Fax: +1-408-495-1905 EMail: ted_kuo@Baynetworks.com Greene, et al. [Page 51] RFC 2320 IP and ARP over ATM (IPOA) MIB April 1998 10. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Greene, et al. [Page 52] snmp-mibs-downloader-1.1/mibrfcs/rfc2417.txt0000644000000000000000000040731611402176071015572 0ustar Network Working Group C. Chung Request for Comments: 2417 Independent Consultant Obsoletes: 2366 M. Greene Category: Standards Track Independent Contractor (Editor) September 1998 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. IANA Note Due to a clerical error in the assignment of the snmpModules in this memo, this RFC provides the corrected number assignment for this protocol. This memo obsoletes RFC 2366. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks' [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Chung & Greene Standards Track [Page 1] RFC 2417 Multicast MIB September 1998 Table of Contents 1 The SNMP Network Management Framework ........................ 2 1.1 Object Definitions ......................................... 2 2 Overview ..................................................... 3 2.1 The MARS Client Group ...................................... 4 2.2 The MARS Server Group ...................................... 4 2.3 The MARS Multicast Server Group ............................ 5 3 IP over ATM Multicast Address Resolution Server MIB Definitions ............................................... 6 4 Acknowledgments ..............................................73 5 References ...................................................74 6 Security Considerations ......................................75 7 Authors' Addresses ...........................................75 8 Full Copyright Statement .....................................76 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of these components. They are: o the SMI, described in RFC 1902 [2] - the mechanisms used for describing and naming objects for the purpose of management. o the Textual Conventions, described in RFC 1903 [3] for SNMPv2. o the Conformance Statements, described in RFC 1904 [4] for SNMPv2. o the Simple Network Management Protocol, described in STD 15, RFC 1157 [5]. o the Protocol Operations, described in RFC 1905 [6] for SNMPv2. o the MIB-II, STD 17, RFC 1213 [7] - the core set of managed objects for the Internet suite of protocols for SNMPv2. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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 Chung & Greene Standards Track [Page 2] RFC 2417 Multicast MIB September 1998 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 also refer to the object type. 2. Overview This MARS MIB is designed to define managed objects that can be used to manage the MARS clients, servers, and the multicast servers (MCS), as described in the RFC2022[1]. The MIB is supposed to be used on a system where one or more MARS clients are running, or where one or more MARS servers are running, or where one or more MARS multicast servers are running. An understanding of MARS, as defined in [1] is assumed in this MIB module definition. However, the following terms are used frequently and are included here for reference: Multicast Group A group of endpoints that communicate with each other such that packets sent from one endpoint are received by all other members of the multicast group. Multicast Address Resolution Server (MARS) A server that distributes multicast group membership information to endpoints. Client/Endpoint An ATM-attached host or router that registers with a MARS and that is a member of one or more multicast groups. An endpoint may establish ATM Virtual Channels (VCs) to the other group members or may make use of a Multicast Server. Cluster The set of clients managed by a MARS. Multicast Server (MCS) A server that sets up ATM Virtual Channels (VCs) between endpoints in a multicast group and to which the endpoints forward data traffic for transmission on their behalf. The MIB is broken down into three major groups: a MARS client group, MARS (server) group, and MARS Multicast Server (MCS) Group. Chung & Greene Standards Track [Page 3] RFC 2417 Multicast MIB September 1998 2.1. The MARS Client Group This client group defines a collection of objects required to be implemented in a MIB for the management of MARS clients. It contains the following tables: o MARS Client Table Information about a client such as its ATM address, the ATM address of its default MARS, registration status, and timers. o MARS Client Multicast Group Table A list of IP multicast address blocks associated with a MARS client. o MARS Client Backup MARS Group Table A list of backup MARS's associated with a MARS client. o MARS Client VC Table Information about VCs opened by a client. o MARS Client Statistics Table Statistics collected by a MARS client. 2.2. The MARS Server Group This MARS server group defines a collection of objects required to be implemented in a MIB for the management of MARS servers. It contains the following tables: o MARS Table Information about a MARS such as its ATM address, its status and timers. o MARS Multicast Group Table A list of IP multicast address blocks associated with a MARS. o MARS VC Table Information about VCs opened by a MARS. o MARS Registered Client Table Chung & Greene Standards Track [Page 4] RFC 2417 Multicast MIB September 1998 A list of clients registered with a MARS. o MARS Registered Multicast Server Table A list of MCSs registered with a MARS. o MARS Statistics Table Statistics collected by a MARS. o MARS Host Map Table Mappings between multicast groups and clients maintained by a MARS. o MARS Server Map Table Mappings between multicast groups and MCSs maintained by a MARS. 2.3. The MARS Multicast Server Group This MARS multicast server group defines a collection of objects required to be implemented in a MIB for the management of MARS multicast servers. It contains the following tables: This group contains the following tables: o MARS Multicast Server Table Information about a MCS, such as its ATM address, default MARS ATM address, and registration state. o MARS MCS Multicast Group Table A list of IP multicast address blocks associated with a MARS MCS. o MARS MCS Backup Mars Group Table A list of backup MARS's associated with a MARS MCS. o MARS Multicast Server VC Table Information about VCs opened by a MCS. o MARS Multicast Server Statistics Table Statistics collected by a MCS. Chung & Greene Standards Track [Page 5] RFC 2417 Multicast MIB September 1998 3. IP Over ATM Multicast Address Resolution Server MIB Definitions IPATM-IPMC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF snmpModules, MODULE-IDENTITY, NOTIFICATION-TYPE, Counter32, Integer32, Unsigned32, OBJECT-TYPE, IpAddress FROM SNMPv2-SMI AtmAddr FROM ATM-TC-MIB TruthValue, RowStatus FROM SNMPv2-TC ipAdEntAddr FROM RFC1213-MIB InterfaceIndex FROM IF-MIB; marsMIB MODULE-IDENTITY LAST-UPDATED "9809010000Z" -- 01 September 1998 ORGANIZATION "Internetworking Over NBMA (ion) Working Group" CONTACT-INFO " Chris Chung (chihschung@aol.com) Independent Consultant Editor: Maria Greene Postal: Independent Contractor E-mail: maria@xedia.com " DESCRIPTION "This module defines a portion of the managed information base (MIB) for managing classical IP multicast address resolution server (MARS) and related entities as described in the RFC2022. This MIB is meant to be used in conjunction with the ATM-MIB (RFC1695), MIB-II (RFC1213), and optionally the IF-MIB (RFC1573). " REVISION "9809010000Z" -- 01 September 1998 DESCRIPTION "Published as RFC 2417. Changes/fixes: - reroot this MIB from snmpModules to mib-2 to be consistent with location of other MIBs. - obsoletes RFC2366." REVISION "9804150145Z" -- 15 April 1998 DESCRIPTION "Initial version, published as RFC 2366" ::= { mib-2 57 } --*************************************************************** Chung & Greene Standards Track [Page 6] RFC 2417 Multicast MIB September 1998 -- IP ATM MARS Client Object Definitions --*************************************************************** marsClientObjects OBJECT IDENTIFIER ::= { marsMIB 1 } marsClientTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The objects defined in this table are used for the management of MARS clients, ATM attached endpoints." ::= { marsClientObjects 1 } marsClientEntry OBJECT-TYPE SYNTAX MarsClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains a MARS client and its associated attributes. An entry in the marsClientTable has a corresponding entry in the ipAddrTable defined in RFC1213. Association between the ipAddrTable and the marsClientTable is made through the index, ipAdEntAddr." INDEX { ipAdEntAddr, marsClientIndex } ::= { marsClientTable 1 } MarsClientEntry ::= SEQUENCE { marsClientIndex Integer32, marsClientAddr AtmAddr, marsClientDefaultMarsAddr AtmAddr, marsClientHsn Unsigned32, marsClientRegistration INTEGER, marsClientCmi INTEGER, marsClientDefaultMtu INTEGER, marsClientFailureTimer INTEGER, marsClientRetranDelayTimer INTEGER, marsClientRdmMulReqAddRetrTimer INTEGER, marsClientRdmVcRevalidateTimer INTEGER, marsClientJoinLeaveRetrInterval INTEGER, marsClientJoinLeaveRetrLimit INTEGER, marsClientRegWithMarsRdmTimer INTEGER, marsClientForceWaitTimer INTEGER, marsClientLmtToMissRedirMapTimer INTEGER, marsClientIdleTimer INTEGER, Chung & Greene Standards Track [Page 7] RFC 2417 Multicast MIB September 1998 marsClientRowStatus RowStatus } marsClientIndex OBJECT-TYPE SYNTAX Integer32(1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the MARS MarsClientTable." ::= { marsClientEntry 1 } marsClientAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The ATM address associated with the ATM Client." ::= { marsClientEntry 2 } marsClientDefaultMarsAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The default MARS ATM address which is needed to setup the initial signalling path between a MARS client and its associated MARS." ::= { marsClientEntry 3 } marsClientHsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The cluster membership own 32 bit Host Sequence Number. When a new cluster member starts up, it is initialized to zero. When the cluster member sends the MARS_JOIN to register, the HSN will be correctly set to the current cluster sequence number (CSN) when the Client receives the copy of its MARS_JOIN from the MARS. It is is used to track the MARS sequence number." ::= { marsClientEntry 4 } marsClientRegistration OBJECT-TYPE SYNTAX INTEGER { notRegistered (1), Chung & Greene Standards Track [Page 8] RFC 2417 Multicast MIB September 1998 registering (2), registered (3), reRegisteringFault (4), reRegisteringRedirMap (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication with regards to the registration status of this client. The registration codes of 'notRegistered (1)', 'registered (2)', and registered (3) are self-explanatory. The 'reRegisteringFault (4)' indicates the client is in the process of re-registering with a MARS due to some fault conditions. The 'reRegisteringRedMap (5)' status code shows that client is re-registering because it has received a MARS_REDIRECT_MAP message and was told to register with a different MARS from the current MARS." ::= { marsClientEntry 5 } marsClientCmi OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "16 bit Cluster member identifier (CMI) assigned by the MARS which uniquely identifies each endpoint attached to the cluster. The value becomes valid after the 'marsClientRegistration' is set to the value of 'registered (1)'." ::= { marsClientEntry 6 } marsClientDefaultMtu OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum transmission unit (MTU) used for this cluster. Note that the actual size used for a VC between two members of the cluster may be negotiated during connection setup and may be different than this value. Default value = 9180 bytes." DEFVAL { 9180 } ::= { marsClientEntry 7 } marsClientFailureTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) Chung & Greene Standards Track [Page 9] RFC 2417 Multicast MIB September 1998 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A timer used to flag the failure of last MARS_MULTI to arrive. Default value = 10 seconds (recommended)." DEFVAL { 10 } ::= { marsClientEntry 8 } marsClientRetranDelayTimer OBJECT-TYPE SYNTAX INTEGER (5..10) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The delay timer for sending out new MARS_REQUEST for the group after the client learned that there is no other group in the cluster. The timer must be set between 5 and 10 seconds inclusive." ::= { marsClientEntry 9 } marsClientRdmMulReqAddRetrTimer OBJECT-TYPE SYNTAX INTEGER (5..10) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The initial random L_MULTI_RQ/ADD retransmit timer which can be set between 5 and 10 seconds inclusive." ::= { marsClientEntry 10 } marsClientRdmVcRevalidateTimer OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The random time to set VC_revalidate flag. The timer value ranges between 1 and 10 seconds inclusive." ::= { marsClientEntry 11 } marsClientJoinLeaveRetrInterval OBJECT-TYPE SYNTAX INTEGER(5..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION Chung & Greene Standards Track [Page 10] RFC 2417 Multicast MIB September 1998 "MARS_JOIN/LEAVE retransmit interval. The minimum and recommended values are 5 and 10 seconds, respectively." DEFVAL { 10 } ::= { marsClientEntry 12 } marsClientJoinLeaveRetrLimit OBJECT-TYPE SYNTAX INTEGER (0..5) MAX-ACCESS read-create STATUS current DESCRIPTION "MARS_JOIN/LEAVE retransmit limit. The maximum value is 5." ::= { marsClientEntry 13 } marsClientRegWithMarsRdmTimer OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Random time to register with MARS." ::= { marsClientEntry 14 } marsClientForceWaitTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "Force wait if MARS re-registration is looping. The minimum value is 1 minute." ::= { marsClientEntry 15 } marsClientLmtToMissRedirMapTimer OBJECT-TYPE SYNTAX INTEGER (1..4) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Timer limit for client to miss MARS_REDIRECT_MAPS." ::= { marsClientEntry 16 } marsClientIdleTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "minutes" MAX-ACCESS read-create STATUS current Chung & Greene Standards Track [Page 11] RFC 2417 Multicast MIB September 1998 DESCRIPTION "The configurable inactivity timer associated with a client. When a VC is created at this client, it gets the idle timer value from this configurable timer. The minimum suggested value is 1 minute and the recommended default value is 20 minutes." DEFVAL { 20 } ::= { marsClientEntry 17 } marsClientRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. A row cannot be made 'active' until instances of all corresponding columns in the row of this table are appropriately configured and until the agent has also created a corresponding row in the marsClientStatTable. When this object has a value of 'active', the following columnar objects can not be modified: marsClientDefaultMarsAddr, marsClientHsn, marsClientRegstration, marsClientCmi, marsClientDefaultMtu while other objects in this conceptual row can be modified irrespective of the value of this object. Deletion of this row is allowed regardless of whether or not a row in any associated tables (i.e., marsClientVcTable) still exists or is in use. Once this row is deleted, it is recommended that the agent or the SNMP management station (if possible) through the set command deletes any stale rows that are associated with this row." ::= { marsClientEntry 18 } --**************************************************************** Chung & Greene Standards Track [Page 12] RFC 2417 Multicast MIB September 1998 -- IP ATM MARS Client Multicast Group Address Object Definitions --**************************************************************** marsClientMcGrpTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsClientMcGrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of IP multicast group address blocks associated with a MARS client. Entries in this table are used by the client that needs to receive or transmit packets from/to the specified range of multicast addresses. Each row can be created or deleted via configuration." ::= { marsClientObjects 2 } marsClientMcGrpEntry OBJECT-TYPE SYNTAX MarsClientMcGrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a consecutive block of multicast group addresses." INDEX { ipAdEntAddr, marsClientIndex, marsClientMcMinGrpAddr, marsClientMcMaxGrpAddr } ::= { marsClientMcGrpTable 1 } MarsClientMcGrpEntry ::= SEQUENCE { marsClientMcMinGrpAddr IpAddress, marsClientMcMaxGrpAddr IpAddress, marsClientMcGrpRowStatus RowStatus } marsClientMcMinGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Minimum multicast group address - the min and max multicast forms multi-group block. If the MinGrpAddr and MaxGrpAddr are the same, it indicates that this block contains a single group address." ::= { marsClientMcGrpEntry 1 } marsClientMcMaxGrpAddr OBJECT-TYPE Chung & Greene Standards Track [Page 13] RFC 2417 Multicast MIB September 1998 SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maximum multicast group address - the min and max multicast forms a multi-group block. If the MinGrpAddr and MaxGrpAddr are the same, it indicates that this block contains a single group address." ::= { marsClientMcGrpEntry 2 } marsClientMcGrpRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create or delete a row in this table. Since other objects in this row are not-accessible 'index-objects', the value of this object has no effect on whether those objects in this conceptual row can be modified." ::= { marsClientMcGrpEntry 3 } --**************************************************************** -- IP ATM MARS Client Backup MARS Object Definitions --**************************************************************** marsClientBackupMarsTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsClientBackupMarsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of backup MARS addresses that a client can connect to in case of failure for connecting to the primary server. The list of addresses is in descending order of preference. It should be noted that the backup list provided by the MARS to the client via the MARS_REDIRECT_MAP message has a higher preference than addresses that are manually configured into the client. When such a list is received from the MARS, this information should be inserted at the top of the list. Each row can be created or deleted via configuration." ::= { marsClientObjects 3 } marsClientBackupMarsEntry OBJECT-TYPE SYNTAX MarsClientBackupMarsEntry MAX-ACCESS not-accessible Chung & Greene Standards Track [Page 14] RFC 2417 Multicast MIB September 1998 STATUS current DESCRIPTION "Each entry represents an ATM address of a backup MARS." INDEX { ipAdEntAddr, marsClientIndex, marsClientBackupMarsPriority, marsClientBackupMarsAddr } ::= { marsClientBackupMarsTable 1 } MarsClientBackupMarsEntry ::= SEQUENCE { marsClientBackupMarsPriority Unsigned32, marsClientBackupMarsAddr AtmAddr, marsClientBackupMarsRowStatus RowStatus } marsClientBackupMarsPriority OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The priority associated with a backup MARS. A lower priority value inidcates a higher preference." ::= { marsClientBackupMarsEntry 1 } marsClientBackupMarsAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM address associated with a backup MARS." ::= { marsClientBackupMarsEntry 2 } marsClientBackupMarsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create or delete a row in this table. Since other objects in this row are not-accessible 'index-objects', the value of this object has no effect on whether those objects in this conceptual row can be modified." ::= { marsClientBackupMarsEntry 3 } --*************************************************************** Chung & Greene Standards Track [Page 15] RFC 2417 Multicast MIB September 1998 -- IP ATM MARS Client VC Object Definition Table --*************************************************************** marsClientVcTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsClientVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about open virtual circuits (VCs) that a client has. For point to point circuit, each entry represents a single VC connection between this client ATM address to another party ATM address. In the case of point to multipoint connection where a single source address is associated with multiple destinations, several entries are used to represent the relationship. An example of point to multi-point VC represented in a table is shown below. Client VPI/VCI Grp Addr1/Addr2 Part Addr 1 0,1 g1,g2 p1 1 0,1 g1,g2 p2 1 0,1 g1,g2 p3 Note: This table assumes the IP multicast address groups (min, max) defined in each entry are always consecutive. In the case of that a client receives a JOIN/LEAVE with mars$flag.punched set, each pair of the IP groups will first be broken into several pairs of consecutive IP groups before each entry row corresponding to a pair of IP group is created." ::= { marsClientObjects 4 } marsClientVcEntry OBJECT-TYPE SYNTAX MarsClientVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The objects contained in the entry are VC related attributes such as VC signalling type, control VC type, idle timer, negotiated MTU size, etc." INDEX { ipAdEntAddr, marsClientIndex, marsClientVcVpi, marsClientVcVci, marsClientVcMinGrpAddr, marsClientVcMaxGrpAddr, Chung & Greene Standards Track [Page 16] RFC 2417 Multicast MIB September 1998 marsClientVcPartyAddr } ::= { marsClientVcTable 1 } MarsClientVcEntry ::= SEQUENCE { marsClientVcVpi INTEGER, marsClientVcVci INTEGER, marsClientVcMinGrpAddr IpAddress, marsClientVcMaxGrpAddr IpAddress, marsClientVcPartyAddr AtmAddr, marsClientVcPartyAddrType INTEGER, marsClientVcType INTEGER, marsClientVcCtrlType INTEGER, marsClientVcIdleTimer INTEGER, marsClientVcRevalidate TruthValue, marsClientVcEncapsType INTEGER, marsClientVcNegotiatedMtu INTEGER, marsClientVcRowStatus RowStatus } marsClientVcVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of virtual path identifier (VPI). Since a VPI can be numbered 0, this sub-index can take a value of 0." ::= { marsClientVcEntry 1 } marsClientVcVci OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of virtual circuit identifier (VCI). Since a VCI can be numbered 0, this sub-index can take a value of 0." ::= { marsClientVcEntry 2 } marsClientVcMinGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Minimum IP multicast group address - the min and max multicast forms a multi-group consecutive block which is associated with a table entry. Chung & Greene Standards Track [Page 17] RFC 2417 Multicast MIB September 1998 if the MinGrpAddr and MaxGrpAddr are the same, it indicates that the size of multi-group block is 1, a single IP group." ::= { marsClientVcEntry 3 } marsClientVcMaxGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maximum IP multicast group address - the min and max multicast forms a multi-group consecutive block which is associated with a table entry. if the MinGrpAddr and MaxGrpAddr are the same, it indicates that the size of multi-group block is 1, a single IP group." ::= { marsClientVcEntry 4 } marsClientVcPartyAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ATM party address in which this VC is linked. The party type is identified by the marsClientVcPartyAddrType." ::= { marsClientVcEntry 5 } marsClientVcPartyAddrType OBJECT-TYPE SYNTAX INTEGER { called (1), calling (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The party type is associated with the party address. The 'called (1)' indicates that the party address is a destination address which implies that VC is originated from this client. The 'calling (2)' indicates the VC was initiated externally to this client. In this case, the party address is the source address." ::= { marsClientVcEntry 6 } marsClientVcType OBJECT-TYPE Chung & Greene Standards Track [Page 18] RFC 2417 Multicast MIB September 1998 SYNTAX INTEGER { pvc (1), svc (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Circuit Connection type: permanent virtual circuit or switched virtual circuit." ::= { marsClientVcEntry 7 } marsClientVcCtrlType OBJECT-TYPE SYNTAX INTEGER { pointToPointVC (1), clusterControlVC (2), pointToMultiPointVC (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Control VC type used to specify a particular connection. pointToPointVC (1): used by the ATM Clients for the registration and queries. This VC or the initial signalling path is set up from the source Client to a MARS. It is bi-directional. clusterControlVC (2): used by a MARS to issue asynchronous updates to an ATM Client. This VC is established from the MARS to the ATM Client. pointToMultiPointVC (3): used by the client to transfer multicast data packets from layer 3. This VC is established from the source ATM Client to a destination ATM endpoint which can be a multicast group member or an MCS. The destination endpoint was obtained from the MARS." ::= { marsClientVcEntry 8 } marsClientVcIdleTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "The idle timer associated with this VC. The minimum suggested value is 1 minute and the recommended default value is 20 minutes." Chung & Greene Standards Track [Page 19] RFC 2417 Multicast MIB September 1998 DEFVAL { 20 } ::= { marsClientVcEntry 9 } marsClientVcRevalidate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A flag associated with an open and active multipoint VC. It is checked every time a packet is queued for transmission on that VC. The object has the value of true (1) if revalidate is required and the value false (2) otherwise." ::= { marsClientVcEntry 10 } marsClientVcEncapsType OBJECT-TYPE SYNTAX INTEGER { other (1), llcSnap (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The encapsulation type used when communicating over this VC." ::= { marsClientVcEntry 11 } marsClientVcNegotiatedMtu OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The negotiated MTU when communicating over this VC." ::= { marsClientVcEntry 12 } marsClientVcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. A row cannot be made 'active' until instances of all corresponding columns in the row of this table are appropriately configured. While objects: marsClientVcIdleTimer and Chung & Greene Standards Track [Page 20] RFC 2417 Multicast MIB September 1998 marsClientVcRevalidate in this conceptual row can be modified irrespective of the value of this object, all other objects in the row can not be modified when this object has a value of 'active'. It is possible for an SNMP management station to set the row to 'notInService' and modify the entry and then set it back to 'active' with the following exception. That is, rows for which the corresponding instance of marsClientVcType has a value of 'svc' can not be modified or deleted." ::= { marsClientVcEntry 13 } --*************************************************************** -- IP ATM MARS Client Statistic Object Definition Table --*************************************************************** marsClientStatTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsClientStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table contains statistics collected at MARS clients." ::= { marsClientObjects 5 } marsClientStatEntry OBJECT-TYPE SYNTAX MarsClientStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains statistics collected at one MARS client." INDEX { ipAdEntAddr, marsClientIndex } ::= { marsClientStatTable 1 } MarsClientStatEntry ::= SEQUENCE { marsClientStatTxReqMsgs Counter32, marsClientStatTxJoinMsgs Counter32, marsClientStatTxLeaveMsgs Counter32, marsClientStatTxGrpLstReqMsgs Counter32, marsClientStatRxJoinMsgs Counter32, marsClientStatRxLeaveMsgs Counter32, marsClientStatRxMultiMsgs Counter32, Chung & Greene Standards Track [Page 21] RFC 2417 Multicast MIB September 1998 marsClientStatRxNakMsgs Counter32, marsClientStatRxMigrateMsgs Counter32, marsClientStatRxGrpLstRplyMsgs Counter32, marsClientStatFailMultiMsgs Counter32 } marsClientStatTxReqMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_REQUEST messages transmitted from a client." ::= { marsClientStatEntry 1 } marsClientStatTxJoinMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_JOIN messages transmitted from a client." ::= { marsClientStatEntry 2 } marsClientStatTxLeaveMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_LEAVE messages transmitted from a client." ::= { marsClientStatEntry 3 } marsClientStatTxGrpLstReqMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_GROUPLIST_REQUEST messages transmitted from a client." ::= { marsClientStatEntry 4 } marsClientStatRxJoinMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_JOIN messages received by Chung & Greene Standards Track [Page 22] RFC 2417 Multicast MIB September 1998 a client." ::= { marsClientStatEntry 5 } marsClientStatRxLeaveMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_LEAVE messages received by a client." ::= { marsClientStatEntry 6 } marsClientStatRxMultiMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MULTI messages received by a client." ::= { marsClientStatEntry 7 } marsClientStatRxNakMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_NAK messages received by a client." ::= { marsClientStatEntry 8 } marsClientStatRxMigrateMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MIGRATE messages received by a client." ::= { marsClientStatEntry 9 } marsClientStatRxGrpLstRplyMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_GROUPLIST_REPLY messages received by a client." ::= { marsClientStatEntry 10 } Chung & Greene Standards Track [Page 23] RFC 2417 Multicast MIB September 1998 marsClientStatFailMultiMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of timeouts occurred indicating failure of the last MARS_MULTI to arrive." ::= { marsClientStatEntry 11 } --*************************************************************** -- IP ATM MARS Object Definitions --*************************************************************** marsObjects OBJECT IDENTIFIER ::= { marsMIB 2 } marsTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The objects defined in this table are used for the management of MARS servers." ::= { marsObjects 1 } marsEntry OBJECT-TYPE SYNTAX MarsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains a MARS and its associated attributes." INDEX { marsIndex, marsIfIndex } ::= { marsTable 1 } MarsEntry ::= SEQUENCE { marsIndex Integer32, marsIfIndex InterfaceIndex, marsAddr AtmAddr, marsLocal TruthValue, marsServStatus INTEGER, marsServType INTEGER, marsServPriority Unsigned32, marsRedirMapMsgTimer INTEGER, marsCsn Unsigned32, marsSsn Unsigned32, marsRowStatus RowStatus } Chung & Greene Standards Track [Page 24] RFC 2417 Multicast MIB September 1998 marsIndex OBJECT-TYPE SYNTAX Integer32(1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the MARS table." ::= { marsEntry 1 } marsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the interface that the MARS is associated with." ::= { marsEntry 2 } marsAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The ATM address associated with the MARS." ::= { marsEntry 3 } marsLocal OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A flag associated with a MARS entry. The object has the value of true (1) if the MARS whose interface is local to the machine that implements this MIB; otherwise the object has the value of false (2)." ::= { marsEntry 4 } marsServStatus OBJECT-TYPE SYNTAX INTEGER { active (1), inactive (2), faulted (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The current status of MARS." ::= { marsEntry 5 } Chung & Greene Standards Track [Page 25] RFC 2417 Multicast MIB September 1998 marsServType OBJECT-TYPE SYNTAX INTEGER { primary (1), backup (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Types of MARS servers: primary or backup." ::= { marsEntry 6 } marsServPriority OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Priority associated with a backup MARS server. A backup MARS server with lower priority value indicates a higher preference than other backup MARS servers to be used as the MARS server when the primary server fails." ::= { marsEntry 7 } marsRedirMapMsgTimer OBJECT-TYPE SYNTAX INTEGER (1..2) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "Periodic interval on which a multi-part MARS_REDIRECT_MAP is sent from this MARS." DEFVAL { 1 } ::= { marsEntry 8 } marsCsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Current cluster sequence number (CSN) which is global within the context of a given protocol. The CSN is incremented by the MARS on every transmission of a message on ClusterControlVC. A cluster member uses the CSN to track the message loss on ClusterControlVC or to monitor a membership change." ::= { marsEntry 9 } marsSsn OBJECT-TYPE Chung & Greene Standards Track [Page 26] RFC 2417 Multicast MIB September 1998 SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Current server sequence number (SSN) which is global within the context of a given protocol. The SSN is incremented by the MARS on every transmission of a message on ServerControlVC. A MCS uses the SSN to track the message loss on ServerControlVC or to monitor a membership change." ::= { marsEntry 10 } marsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. A row cannot be made 'active' until instances of all corresponding columns in the row of this table are appropriately configured and until the agent has also created a corresponding row in the marsStatTable. When this object has a value of 'active', the following columnar objects can not be modified: marsAddr, marsAddrLocal, marsServStatus, marsServType, marsCsn, marsSsn while other objects in this conceptual row can be modified irrespective of the value of this object. Deletion of this row is allowed regardless of whether or not a row in any associated tables (i.e., marsVcTable) still exists or is in use. Once this row is deleted, it is recommended that the agent or the SNMP management station (if possible) through the set command deletes any stale rows that are associated with this row." ::= { marsEntry 11 } Chung & Greene Standards Track [Page 27] RFC 2417 Multicast MIB September 1998 --**************************************************************** -- IP ATM MARS Multicast Group Address Object Definitions --**************************************************************** marsMcGrpTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsMcGrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of IP multicast address blocks associated with a MARS. Entries in this table are used by the MARS host map table and the server map table. They should be created prior to being referenced as indices by those tables. Each row can be created or deleted via configuration." ::= { marsObjects 2 } marsMcGrpEntry OBJECT-TYPE SYNTAX MarsMcGrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a consecutive block of multicast group addresses." INDEX { marsIndex, marsIfIndex, marsMcMinGrpAddr, marsMcMaxGrpAddr } ::= { marsMcGrpTable 1 } MarsMcGrpEntry ::= SEQUENCE { marsMcMinGrpAddr IpAddress, marsMcMaxGrpAddr IpAddress, marsMcGrpAddrUsage INTEGER, marsMcGrpRxLayer3GrpSets Counter32, marsMcGrpRxLayer3GrpResets Counter32, marsMcGrpRowStatus RowStatus } marsMcMinGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Minimum multicast group address - the min and max multicast forms multi-group block. If the MinGrpAddr and MaxGrpAddr are the same, it indicates that this Chung & Greene Standards Track [Page 28] RFC 2417 Multicast MIB September 1998 block contains a single group address." ::= { marsMcGrpEntry 1 } marsMcMaxGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maximum multicast group address - the min and max multicast forms a multi-group block. If The MinGrpAddr and MaxGrpAddr are the same, it indicates that this block contains a single group address." ::= { marsMcGrpEntry 2 } marsMcGrpAddrUsage OBJECT-TYPE SYNTAX INTEGER { hostMap (1), serverMap (2), hostServerMap (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Usage of the multicast address block. The hostMap (1) indicates that the address block is only used in the MARS host map table. The serverMap (2) indicates that the address block is only used in the MARS server map table. The hostServerMap (3) indicates that the address block is used in both the host map and the server map tables." ::= { marsMcGrpEntry 3 } marsMcGrpRxLayer3GrpSets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of MARS_JOIN messages received with mars$flags.layer3grp flag set." ::= { marsMcGrpEntry 4 } marsMcGrpRxLayer3GrpResets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of MARS_JOIN messages received with mars$flags.layer3grp flag reset." Chung & Greene Standards Track [Page 29] RFC 2417 Multicast MIB September 1998 ::= { marsMcGrpEntry 5 } marsMcGrpRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { marsMcGrpEntry 6 } --*************************************************************** -- IP ATM MARS Host Map Object Definitions --*************************************************************** marsHostMapTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsHostMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table caches mappings between IP multicast address to a list of ATM addresses that are configured or dynamically learned from the MARS. This address resolution is used for the host map. It supports the mapping of a block of multicast group addresses to a cluster member address. In the case where a group block is associated with multiple cluster members, several entries are used to representing the relationship." ::= { marsObjects 3 } marsHostMapEntry OBJECT-TYPE SYNTAX MarsHostMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry row contains attributes associated with the mapping between a multicast group block and an ATM address." INDEX { marsIndex, marsIfIndex, marsMcMinGrpAddr, marsMcMaxGrpAddr, marsHostMapAtmAddr } ::= { marsHostMapTable 1 } Chung & Greene Standards Track [Page 30] RFC 2417 Multicast MIB September 1998 MarsHostMapEntry ::= SEQUENCE { marsHostMapAtmAddr AtmAddr, marsHostMapRowType INTEGER, marsHostMapRowStatus RowStatus } marsHostMapAtmAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mapped cluster member ATM address." ::= { marsHostMapEntry 1 } marsHostMapRowType OBJECT-TYPE SYNTAX INTEGER { static (1), dynamic (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Method in which this entry row is created. The static (1) indicates that this row is created through configuration. The dynamic (2) indicates that the row is created as the result of group address updates received at this MARS." ::= { marsHostMapEntry 2 } marsHostMapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. This object must not be set to 'active' until instances of all corresponding columns in the row of this table are appropriately configured. It is possible for an SNMP management station to set the row to 'notInService' and modify the entry and then set it back to 'active' with the following exception. That is, rows for which the corresponding instance of marsHostMapRowType has a value of 'dynamic' Chung & Greene Standards Track [Page 31] RFC 2417 Multicast MIB September 1998 can not be modified or deleted." ::= { marsHostMapEntry 3 } --*************************************************************** -- IP ATM MARS Server Map Object Definitions --*************************************************************** marsServerMapTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsServerMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table caches mappings between IP multicast address to a list of MCS ATM addresses that are configured or dynamically learned from the MARS. This address resolution is used for the server map. It supports the mapping of a block of multicast group addresses to a MCS address. In the case where a group block is associated with multiple MCSs, several entries are used to representing the relationship." ::= { marsObjects 4 } marsServerMapEntry OBJECT-TYPE SYNTAX MarsServerMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry row contains attributes associated with the mapping between a multicast group block and an MCS address." INDEX { marsIndex, marsIfIndex, marsMcMinGrpAddr, marsMcMaxGrpAddr, marsServerMapAtmAddr } ::= { marsServerMapTable 1 } MarsServerMapEntry ::= SEQUENCE { marsServerMapAtmAddr AtmAddr, marsServerMapRowType INTEGER, marsServerMapRowStatus RowStatus } marsServerMapAtmAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible Chung & Greene Standards Track [Page 32] RFC 2417 Multicast MIB September 1998 STATUS current DESCRIPTION "The mapped MCS ATM address." ::= { marsServerMapEntry 1 } marsServerMapRowType OBJECT-TYPE SYNTAX INTEGER { static (1), dynamic (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Method in which this entry row is created. The 'static (1)' indicates that this row is created through configuration. The 'dynamic (2)' indicates that the row is created as the result of group address updates received at this MARS." ::= { marsServerMapEntry 2 } marsServerMapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. This object must not be set to 'active' until instances of all corresponding columns in the row of this table are appropriately configured. It is possible for an SNMP management station to set the row to 'notInService' and modify the entry and then set it back to 'active' with the following exception. That is, rows for which the corresponding instance of marsServerMapRowType has a value of 'dynamic' can not be modified or deleted." ::= { marsServerMapEntry 3 } --*************************************************************** -- IP ATM MARS VC Object Definition Table --*************************************************************** marsVcTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsVcEntry MAX-ACCESS not-accessible Chung & Greene Standards Track [Page 33] RFC 2417 Multicast MIB September 1998 STATUS current DESCRIPTION "This table contains information about open virtual circuits (VCs) that a MARS has. For point to point circuit, each entry represents a single VC connection between this MARS ATM address to another party's ATM address. In the case of point to multipoint connection where a ControlVc is attached with multiple leaf nodes, several entries are used to represent the relationship. An example of point to multi-point VC represented in a table is shown below. MARS VPI/VCI MARS Addr Party Addr 1 0,1 m1 p1 1 0,1 m1 p2 1 0,1 m1 p3" ::= { marsObjects 5 } marsVcEntry OBJECT-TYPE SYNTAX MarsVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The objects contained in the entry are VC related attributes such as VC signalling type, control VC type, idle timer, negotiated MTU size, etc." INDEX { marsIndex, marsIfIndex, marsVcVpi, marsVcVci, marsVcPartyAddr } ::= { marsVcTable 1 } MarsVcEntry ::= SEQUENCE { marsVcVpi INTEGER, marsVcVci INTEGER, marsVcPartyAddr AtmAddr, marsVcPartyAddrType INTEGER, marsVcType INTEGER, marsVcCtrlType INTEGER, marsVcIdleTimer INTEGER, marsVcCmi INTEGER, marsVcEncapsType INTEGER, marsVcNegotiatedMtu INTEGER, marsVcRowStatus RowStatus } marsVcVpi OBJECT-TYPE Chung & Greene Standards Track [Page 34] RFC 2417 Multicast MIB September 1998 SYNTAX INTEGER (0..4095) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of virtual path identifier (VPI). Since a VPI can be numbered 0, this sub-index can take a value of 0." ::= { marsVcEntry 1 } marsVcVci OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of virtual circuit identifier (VCI). Since a VCI can be numbered 0, this sub-index can take a value of 0." ::= { marsVcEntry 2 } marsVcPartyAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ATM party address in which this VC is linked. The party type is identified by the marsVcPartyAddrType." ::= { marsVcEntry 5 } marsVcPartyAddrType OBJECT-TYPE SYNTAX INTEGER { called (1), calling (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The party type is associated with the party address. The 'called (1)' indicates that the party address is a destination address which implies that VC is originated from this MARS. The 'calling (2)' indicates the VC was initiated externally to this MARS. The party address is the source address." ::= { marsVcEntry 6 } marsVcType OBJECT-TYPE SYNTAX INTEGER { pvc (1), svc (2) Chung & Greene Standards Track [Page 35] RFC 2417 Multicast MIB September 1998 } MAX-ACCESS read-create STATUS current DESCRIPTION "Circuit Connection type: permanent virtual circuit or switched virtual circuit." ::= { marsVcEntry 7 } marsVcCtrlType OBJECT-TYPE SYNTAX INTEGER { pointToPointVC (1), clusterControlVC (2), serverControlVC (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Control VC type used to specify a particular connection. pointToPointVC (1): used by the ATM endpoints (clients) or the MCS for registration and queries. This VC is set up from a MARS client and MCS to this MARS. It is a bi-directional VC. clusterControlVC (2): used by MARS to issue asynchronous updates to ATM an ATM client. This VC is established from the MARs to the ATM client. serverControlVC (3): used by MARS to issue asynchronous update to ATM multicast servers. This type of VC exists when at least a MCS is being used." ::= { marsVcEntry 8 } marsVcIdleTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "The idle timer associated with this VC. The minimum suggested value is 1 minute and the recommended default value is 20 minutes." DEFVAL { 20 } ::= { marsVcEntry 9 } marsVcCmi OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create Chung & Greene Standards Track [Page 36] RFC 2417 Multicast MIB September 1998 STATUS current DESCRIPTION "Cluster member identifier (CMI) which uniquely identifies each endpoint attached to the cluster. This variable applies to each 'leaf node' of an outgoing control VC." ::= { marsVcEntry 10 } marsVcEncapsType OBJECT-TYPE SYNTAX INTEGER { other (1), llcSnap (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The encapsulation type used when communicating over this VC." ::= { marsVcEntry 11 } marsVcNegotiatedMtu OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The negotiated MTU when communicating over this VC." ::= { marsVcEntry 12 } marsVcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. A row cannot be made 'active' until instances of all corresponding columns in the row of this table are appropriately configured. While the marsVcIdleTimer in this conceptual row can be modified irrespective of the value of this object, all other objects in the row can not be modified when this object has a value of 'active'. It is possible for an SNMP management station to set the row to 'notInService' and modify the entry and then set it back to 'active' Chung & Greene Standards Track [Page 37] RFC 2417 Multicast MIB September 1998 with the following exception. That is, rows for which the corresponding instance of marsVcType has a value of 'svc' can not be modified or deleted." ::= { marsVcEntry 13 } --*************************************************************** -- IP ATM MARS Registered Cluster Member List Table --*************************************************************** marsRegClientTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsRegClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM identities of all the currently registered cluster members at a MARS. Each entry represents one set of ATM identities associated with one cluster member or the MARS client." ::= { marsObjects 6 } marsRegClientEntry OBJECT-TYPE SYNTAX MarsRegClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry row contains attributes associated with one register cluster member." INDEX { marsIndex, marsIfIndex, marsRegClientCmi} ::= { marsRegClientTable 1 } MarsRegClientEntry ::= SEQUENCE { marsRegClientCmi INTEGER, marsRegClientAtmAddr AtmAddr } marsRegClientCmi OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This cluster member identifier is used as an auxiliary index for the entry in this table." ::= { marsRegClientEntry 1 } Chung & Greene Standards Track [Page 38] RFC 2417 Multicast MIB September 1998 marsRegClientAtmAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-only STATUS current DESCRIPTION "The registered client's ATM address." ::= { marsRegClientEntry 2 } --*************************************************************** -- IP ATM MARS Registered Server Member List Table --*************************************************************** marsRegMcsTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsRegMcsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM identities of all the currently registered MCSs at a MARS. Each entry represents one set of ATM identities associated with one MCS." ::= { marsObjects 7 } marsRegMcsEntry OBJECT-TYPE SYNTAX MarsRegMcsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry row contains attributes associated with one registered MCS." INDEX { marsIndex, marsIfIndex, marsRegMcsAtmAddr } ::= { marsRegMcsTable 1 } MarsRegMcsEntry ::= SEQUENCE { marsRegMcsAtmAddr AtmAddr } marsRegMcsAtmAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-only STATUS current DESCRIPTION "The registered MCS's ATM address." ::= { marsRegMcsEntry 1 } Chung & Greene Standards Track [Page 39] RFC 2417 Multicast MIB September 1998 --*************************************************************** -- IP ATM MARS Statistics Object Definition Table --*************************************************************** marsStatTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table contains statistics collected at MARS." ::= { marsObjects 8 } marsStatEntry OBJECT-TYPE SYNTAX MarsStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains statistics collected at one MARS." INDEX { marsIndex, marsIfIndex } ::= { marsStatTable 1 } MarsStatEntry ::= SEQUENCE { marsStatTxMultiMsgs Counter32, marsStatTxGrpLstRplyMsgs Counter32, marsStatTxRedirectMapMsgs Counter32, marsStatTxMigrateMsgs Counter32, marsStatTxNakMsgs Counter32, marsStatTxJoinMsgs Counter32, marsStatTxLeaveMsgs Counter32, marsStatTxSjoinMsgs Counter32, marsStatTxSleaveMsgs Counter32, marsStatTxMservMsgs Counter32, marsStatTxUnservMsgs Counter32, marsStatRxReqMsgs Counter32, marsStatRxGrpLstReqMsgs Counter32, marsStatRxJoinMsgs Counter32, marsStatRxLeaveMsgs Counter32, marsStatRxMservMsgs Counter32, marsStatRxUnservMsgs Counter32, marsStatRxBlkJoinMsgs Counter32, marsStatRegMemGroups Counter32, marsStatRegMcsGroups Counter32 } marsStatTxMultiMsgs OBJECT-TYPE Chung & Greene Standards Track [Page 40] RFC 2417 Multicast MIB September 1998 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MULTI transmitted by this MARS." ::= { marsStatEntry 1 } marsStatTxGrpLstRplyMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_GROUPLIST_REPLY messages transmitted by this MARS." ::= { marsStatEntry 2 } marsStatTxRedirectMapMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_REDIRECT_MAP messages transmitted by this MARS." ::= { marsStatEntry 3 } marsStatTxMigrateMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MIGRATE messages transmitted by this MARS." ::= { marsStatEntry 4 } marsStatTxNakMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_NAK messages transmitted by this MARS." ::= { marsStatEntry 5 } marsStatTxJoinMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_JOIN messages transmitted by this Chung & Greene Standards Track [Page 41] RFC 2417 Multicast MIB September 1998 MARS." ::= { marsStatEntry 6 } marsStatTxLeaveMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_LEAVE messages transmitted by this MARS." ::= { marsStatEntry 7 } marsStatTxSjoinMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_SJOIN messages transmitted by this MARS." ::= { marsStatEntry 8 } marsStatTxSleaveMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_SLEAVE messages transmitted by this MARS." ::= { marsStatEntry 9 } marsStatTxMservMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MSERV messages transmitted by this MARS." ::= { marsStatEntry 10 } marsStatTxUnservMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_UNSERV messages transmitted by this MARS." ::= { marsStatEntry 11 } Chung & Greene Standards Track [Page 42] RFC 2417 Multicast MIB September 1998 marsStatRxReqMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_REQUEST messages received by this MARS." ::= { marsStatEntry 12 } marsStatRxGrpLstReqMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_GROUPLIST_REQUEST messages received by this MARS." ::= { marsStatEntry 13 } marsStatRxJoinMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_JOINS messages received by this MARS." ::= { marsStatEntry 14 } marsStatRxLeaveMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_LEAVES messages received by this MARS." ::= { marsStatEntry 15 } marsStatRxMservMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MSERV messages received by this MARS." ::= { marsStatEntry 16 } marsStatRxUnservMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_UNSERV messages received by this MARS." Chung & Greene Standards Track [Page 43] RFC 2417 Multicast MIB September 1998 ::= { marsStatEntry 17 } marsStatRxBlkJoinMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of block joins messages received by this MARS." ::= { marsStatEntry 18 } marsStatRegMemGroups OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP multicast groups with 1 or more joined cluster members." ::= { marsStatEntry 19 } marsStatRegMcsGroups OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP multicast groups with 1 or more joined MCSs." ::= { marsStatEntry 20 } --*************************************************************** -- IP ATM MARS MCS Object Definitions --*************************************************************** marsMcsObjects OBJECT IDENTIFIER ::= { marsMIB 3 } marsMcsTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsMcsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The objects defined in this table are used for the management of a multicast server (MCS)." ::= { marsMcsObjects 1 } marsMcsEntry OBJECT-TYPE SYNTAX MarsMcsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Chung & Greene Standards Track [Page 44] RFC 2417 Multicast MIB September 1998 "Each entry contains a MCS and its associated attributes." INDEX { marsMcsIndex, marsMcsIfIndex } ::= { marsMcsTable 1 } MarsMcsEntry ::= SEQUENCE { marsMcsIndex Integer32, marsMcsIfIndex InterfaceIndex, marsMcsAddr AtmAddr, marsMcsDefaultMarsAddr AtmAddr, marsMcsRegistration INTEGER, marsMcsSsn Unsigned32, marsMcsDefaultMtu INTEGER, marsMcsFailureTimer INTEGER, marsMcsRetranDelayTimer INTEGER, marsMcsRdmMulReqAddRetrTimer INTEGER, marsMcsRdmVcRevalidateTimer INTEGER, marsMcsRegisterRetrInterval INTEGER, marsMcsRegisterRetrLimit INTEGER, marsMcsRegWithMarsRdmTimer INTEGER, marsMcsForceWaitTimer INTEGER, marsMcsIdleTimer INTEGER, marsMcsLmtToMissRedirMapTimer INTEGER, marsMcsRowStatus RowStatus } marsMcsIndex OBJECT-TYPE SYNTAX Integer32(1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used to identify instances of the columnar objects in the MCS table." ::= { marsMcsEntry 1 } marsMcsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the interface that the MCS is associated with." ::= { marsMcsEntry 2 } marsMcsAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create Chung & Greene Standards Track [Page 45] RFC 2417 Multicast MIB September 1998 STATUS current DESCRIPTION "The ATM address associated with the MCS." ::= { marsMcsEntry 3 } marsMcsDefaultMarsAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The default MARS ATM address which is needed to setup the initial signalling path between a MCS and its associated MARS." ::= { marsMcsEntry 4 } marsMcsRegistration OBJECT-TYPE SYNTAX INTEGER { notRegistered (1), registering (2), registered (3), reRegisteringFault (4), reRegisteringRedirMap (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication with regards to the registration STATUS of this MCS. The registration codes of 'notRegistered (1)', 'registered (2)', and registered (3) are self-explanatory. The 'reRegisteringFault (4)' indicates the MCS is in the process of re-registering with a MARS due to some fault conditions. The 'reRegisteringRedMap (5)' status code shows that MCS is re-registering because it has received a MARS_REDIRECT_MAP message and was told to register with a shift MARS." ::= { marsMcsEntry 5 } marsMcsSsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The MCS own 32 bit Server Sequence Number. It is used to track the Mars sequence number." ::= { marsMcsEntry 6 } marsMcsDefaultMtu OBJECT-TYPE Chung & Greene Standards Track [Page 46] RFC 2417 Multicast MIB September 1998 SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum transmission unit (MTU) used for this cluster. Note that the actual size used for a VC between two members of the cluster may be negotiated during connection setup and may be different than this value. Default value = 9180 bytes." DEFVAL { 9180 } ::= { marsMcsEntry 7 } marsMcsFailureTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A timer used to flag the failure of last MARS_MULTI to arrive. Default value = 10 seconds (recommended)." DEFVAL { 10 } ::= { marsMcsEntry 8 } marsMcsRetranDelayTimer OBJECT-TYPE SYNTAX INTEGER (5..10) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The delay timer for sending out new MARS_REQUEST for the group after the MCS learned that there is no other group in the cluster. The timer must be set between 5 and 10 seconds inclusive." ::= { marsMcsEntry 9 } marsMcsRdmMulReqAddRetrTimer OBJECT-TYPE SYNTAX INTEGER (5..10) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The initial random L_MULTI_RQ/ADD retransmit timer which can be set between 5 and 10 seconds inclusive." ::= { marsMcsEntry 10 } marsMcsRdmVcRevalidateTimer OBJECT-TYPE SYNTAX INTEGER (1..10) Chung & Greene Standards Track [Page 47] RFC 2417 Multicast MIB September 1998 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The random time to set VC_revalidate flag. The timer value ranges between 1 and 10 seconds inclusive." ::= { marsMcsEntry 11 } marsMcsRegisterRetrInterval OBJECT-TYPE SYNTAX INTEGER(5..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "MARS_MSERV/UNSERV retransmit interval. The minimum and recommended values are 5 and 10 seconds, respectively." DEFVAL { 10 } ::= { marsMcsEntry 12 } marsMcsRegisterRetrLimit OBJECT-TYPE SYNTAX INTEGER (0..5) MAX-ACCESS read-create STATUS current DESCRIPTION "MARS_MSERV/UNSERV retransmit limit. The maximum value is 5." ::= { marsMcsEntry 13 } marsMcsRegWithMarsRdmTimer OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Random time for a MCS to register with a MARS." ::= { marsMcsEntry 14 } marsMcsForceWaitTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "Force wait if MARS re-registration is looping. The minimum value is 1 minute." ::= { marsMcsEntry 15 } Chung & Greene Standards Track [Page 48] RFC 2417 Multicast MIB September 1998 marsMcsLmtToMissRedirMapTimer OBJECT-TYPE SYNTAX INTEGER (1..4) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Timer limit for MCS to miss MARS_REDIRECT_MAPS." ::= { marsMcsEntry 16 } marsMcsIdleTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION "The configurable inactivity timer associated with a MCS. When a VC is created at this MCS, it gets the idle timer value from this configurable timer. The minimum suggested value is 1 minute and the recommended default value is 20 minutes." DEFVAL { 20 } ::= { marsMcsEntry 17 } marsMcsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. A row cannot be made 'active' until instances of all corresponding columns in the row of this table are appropriately configured and until the agent has also created a corresponding row in the marsMcsStatTable. When this object has a value of 'active', the following columnar objects can not be modified: marsMcsDefaultMarsAddr, marsMcsSsn, marsMcsRegstration, marsMcsDefaultMtu while other objects in this conceptual row can be modified irrespective of the value of this object. Chung & Greene Standards Track [Page 49] RFC 2417 Multicast MIB September 1998 Deletion of this row is allowed regardless of whether or not a row in any associated tables (i.e., marsMcsVcTable) still exists or is in use. Once this row is deleted, it is recommended that the agent or the SNMP management station (if possible) through the set command deletes any stale rows that are associated with this row." ::= { marsMcsEntry 18 } --**************************************************************** -- IP ATM MARS MCS Multicast Group Address Object Definitions --**************************************************************** marsMcsMcGrpTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsMcsMcGrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of IP multicast group address blocks associated by a MARS MCS. The MCS uses the information contained in list to advertise its multicast group service to the MARS. Each row can be created or deleted via configuration." ::= { marsMcsObjects 2 } marsMcsMcGrpEntry OBJECT-TYPE SYNTAX MarsMcsMcGrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a consecutive block of multicast group addresses." INDEX { marsMcsIndex, marsMcsIfIndex, marsMcsMcMinGrpAddr, marsMcsMcMaxGrpAddr } ::= { marsMcsMcGrpTable 1 } MarsMcsMcGrpEntry ::= SEQUENCE { marsMcsMcMinGrpAddr IpAddress, marsMcsMcMaxGrpAddr IpAddress, marsMcsMcGrpRowStatus RowStatus } marsMcsMcMinGrpAddr OBJECT-TYPE Chung & Greene Standards Track [Page 50] RFC 2417 Multicast MIB September 1998 SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Minimum multicast group address - the min and max multicast forms multi-group block. If the MinGrpAddr and MaxGrpAddr are the same, it indicates that this block contains a single group address. Since the block joins are no allowed by a MCS as implied in the RFC2022, the MinGrpAddr and MaxGrpAddress should be set to the same value at this time when an entry row is created." ::= { marsMcsMcGrpEntry 1 } marsMcsMcMaxGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maximum multicast group address - the min and max multicast forms a multi-group block. If the MinGrpAddr and MaxGrpAddr are the same, it indicates that this block contains a single group address. Since the block joins are no allowed by a MCS as implied in the RFC2022, the MinGrpAddr and MaxGrpAddress should be set to the same value at this time when an entry row is created." ::= { marsMcsMcGrpEntry 2 } marsMcsMcGrpRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create or delete a row in this table. Since other objects in this row are not-accessible 'index-objects', the value of this object has no effect on whether those objects in this conceptual row can be modified." ::= { marsMcsMcGrpEntry 3 } --**************************************************************** -- IP ATM MARS MCS Backup MARS Object Definitions --**************************************************************** marsMcsBackupMarsTable OBJECT-TYPE Chung & Greene Standards Track [Page 51] RFC 2417 Multicast MIB September 1998 SYNTAX SEQUENCE OF MarsMcsBackupMarsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of backup MARS addresses that a MCS can make contact to in case of failure for connecting to the primary server. The list of addresses is in descending order of preference. It should be noted that the backup list provided by the MARS to the MCS via the MARS_REDIRECT_MAP message has a higher preference than addresses that are manually configured into the MCS. When such a list is received from the MARS, this information should be inserted at the top of the list. Each row can be created or deleted via configuration." ::= { marsMcsObjects 3 } marsMcsBackupMarsEntry OBJECT-TYPE SYNTAX MarsMcsBackupMarsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents an ATM address of a backup MARS." INDEX { marsMcsIndex, marsMcsIfIndex, marsMcsBackupMarsPriority, marsMcsBackupMarsAddr } ::= { marsMcsBackupMarsTable 1 } MarsMcsBackupMarsEntry ::= SEQUENCE { marsMcsBackupMarsPriority Unsigned32, marsMcsBackupMarsAddr AtmAddr, marsMcsBackupMarsRowStatus RowStatus } marsMcsBackupMarsPriority OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The priority associated with a backup MARS. A lower priority value inidcates a higher preference." ::= { marsMcsBackupMarsEntry 1 } marsMcsBackupMarsAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current Chung & Greene Standards Track [Page 52] RFC 2417 Multicast MIB September 1998 DESCRIPTION "The ATM address associated with a backup MARS." ::= { marsMcsBackupMarsEntry 2 } marsMcsBackupMarsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create or delete a row in this table. Since other objects in this row are not-accessible 'index-objects', the value of this object has no effect on whether those objects in this conceptual row can be modified." ::= { marsMcsBackupMarsEntry 3 } --*************************************************************** -- IP ATM MARS MCS VC Object Definition Table --*************************************************************** marsMcsVcTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsMcsVcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about open virtual circuits (VCs) that a MCS has. For point to point circuit, each entry represents a single VC connection between this MCS ATM address to another party ATM address. In the case of point to multipoint connection where a single source address is associated with multiple destinations, several entries are used to represent the relationship. An example of point to multi-point VC represented in a table is shown below. MCS VPI/VCI Grp Addr1/Addr2 Part Addr 1 0,1 g1,g2 p1 1 0,1 g1,g2 p2 1 0,1 g1,g2 p3" ::= { marsMcsObjects 4 } marsMcsVcEntry OBJECT-TYPE SYNTAX MarsMcsVcEntry MAX-ACCESS not-accessible STATUS current Chung & Greene Standards Track [Page 53] RFC 2417 Multicast MIB September 1998 DESCRIPTION "The objects contained in the entry are VC related attributes such as VC signalling type, control VC type, idle timer, negotiated MTU size, etc." INDEX { marsMcsIndex, marsMcsIfIndex, marsMcsVcVpi, marsMcsVcVci, marsMcsVcMinGrpAddr, marsMcsVcMaxGrpAddr, marsMcsVcPartyAddr } ::= { marsMcsVcTable 1 } MarsMcsVcEntry ::= SEQUENCE { marsMcsVcVpi INTEGER, marsMcsVcVci INTEGER, marsMcsVcMinGrpAddr IpAddress, marsMcsVcMaxGrpAddr IpAddress, marsMcsVcPartyAddr AtmAddr, marsMcsVcPartyAddrType INTEGER, marsMcsVcType INTEGER, marsMcsVcCtrlType INTEGER, marsMcsVcIdleTimer INTEGER, marsMcsVcRevalidate TruthValue, marsMcsVcEncapsType INTEGER, marsMcsVcNegotiatedMtu INTEGER, marsMcsVcRowStatus RowStatus } marsMcsVcVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of virtual path identifier (VPI). Since a VPI can be numbered 0, this sub-index can take a value of 0." ::= { marsMcsVcEntry 1 } marsMcsVcVci OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of virtual circuit identifier (VCI). Since a VCI can be numbered 0, this sub-index can take a value of 0." Chung & Greene Standards Track [Page 54] RFC 2417 Multicast MIB September 1998 ::= { marsMcsVcEntry 2 } marsMcsVcMinGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Minimum IP multicast group address - the min and max multicast forms a multi-group block which is associated with a VC. If the MinGrpAddr and MaxGrpAddr are the same, it indicates that the size of multi-group block is 1, a single IP group." ::= { marsMcsVcEntry 3 } marsMcsVcMaxGrpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maximum IP multicast group address - the min and max multicast forms a multi-group block which is associated with a VC. If the MinGrpAddr and MaxGrpAddr are the same, it indicates that the size of multi-group block is 1, a single IP group." ::= { marsMcsVcEntry 4 } marsMcsVcPartyAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ATM party address in which this VC is linked. The party type is identified by the marsMcsVcPartyAddrType." ::= { marsMcsVcEntry 5 } marsMcsVcPartyAddrType OBJECT-TYPE SYNTAX INTEGER { called (1), calling (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The party type is associated with the party address. The called (1) indicates that the party address is Chung & Greene Standards Track [Page 55] RFC 2417 Multicast MIB September 1998 a destination address which implies that VC is originated from this MCS. The calling (2) indicates the VC was initiated externally to this MCS. In this case, the party address is the source address." ::= { marsMcsVcEntry 6 } marsMcsVcType OBJECT-TYPE SYNTAX INTEGER { pvc (1), svc (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Circuit Connection type: permanent virtual circuit or switched virtual circuit." ::= { marsMcsVcEntry 7 } marsMcsVcCtrlType OBJECT-TYPE SYNTAX INTEGER { pointToPointVC (1), serverControlVC (2), pointToMultiPointVC (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Control VC type used to specify a particular connection. pointToPointVC (1): used by the ATM Clients for the registration and queries. This VC or the initial signalling path is set up from the source MCS to a MARS. It is bi-directional. serverControlVC (2): used by a MARS to issue asynchronous updates to an ATM Client. This VC is established from the MARS to the MCS. pointToMultiPointVC (3): used by the client to transfer multicast data packets from layer 3. This VC is established from this VC to a cluster member." ::= { marsMcsVcEntry 8 } marsMcsVcIdleTimer OBJECT-TYPE SYNTAX INTEGER (1..2147483647) UNITS "minutes" MAX-ACCESS read-create Chung & Greene Standards Track [Page 56] RFC 2417 Multicast MIB September 1998 STATUS current DESCRIPTION "The idle timer associated with this VC. The minimum suggested value is 1 minute and the recommended default value is 20 minutes." DEFVAL { 20 } ::= { marsMcsVcEntry 9 } marsMcsVcRevalidate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A flag associated with an open and active multipoint VC. It is checked every time a packet is queued for transmission on that VC. The object has the value of true (1) if revalidate is required and the value false (2) otherwise." ::= { marsMcsVcEntry 10 } marsMcsVcEncapsType OBJECT-TYPE SYNTAX INTEGER { other (1), llcSnap (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The encapsulation type used when communicating over this VC." ::= { marsMcsVcEntry 11 } marsMcsVcNegotiatedMtu OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The negotiated MTU when communicating over this VC." ::= { marsMcsVcEntry 12 } marsMcsVcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The object is used to create, delete or modify a row in this table. Chung & Greene Standards Track [Page 57] RFC 2417 Multicast MIB September 1998 A row cannot be made 'active' until instances of all corresponding columns in the row of this table are appropriately configured. While objects: marsMcsVcIdleTimer and marsMcsVcRevalidate in this conceptual row can be modified irrespective of the value of this object, all other objects in the row can not be modified when this object has a value of 'active'. It is possible for an SNMP management station to set the row to 'notInService' and modify the entry and then set it back to 'active' with the following exception. That is, rows for which the corresponding instance of marsMcsVcType has a value of 'svc' can not be modified or deleted." ::= { marsMcsVcEntry 13 } --*************************************************************** -- IP ATM MARS MCS Statistics Definition Table --*************************************************************** marsMcsStatTable OBJECT-TYPE SYNTAX SEQUENCE OF MarsMcsStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table contains statistics collected at MARS MCSs." ::= { marsMcsObjects 5 } marsMcsStatEntry OBJECT-TYPE SYNTAX MarsMcsStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains statistics collected at one MARS MCS." INDEX { marsMcsIndex, marsMcsIfIndex } ::= { marsMcsStatTable 1 } MarsMcsStatEntry ::= SEQUENCE { marsMcsStatTxReqMsgs Counter32, marsMcsStatTxMservMsgs Counter32, marsMcsStatTxUnservMsgs Counter32, marsMcsStatRxMultiMsgs Counter32, marsMcsStatRxSjoinMsgs Counter32, Chung & Greene Standards Track [Page 58] RFC 2417 Multicast MIB September 1998 marsMcsStatRxSleaveMsgs Counter32, marsMcsStatRxNakMsgs Counter32, marsMcsStatRxMigrateMsgs Counter32, marsMcsStatFailMultiMsgs Counter32 } marsMcsStatTxReqMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_REQUEST messages transmitted from this MCS." ::= { marsMcsStatEntry 1 } marsMcsStatTxMservMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MSERV messages transmitted from this MCS." ::= { marsMcsStatEntry 2 } marsMcsStatTxUnservMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_UNSERV messages transmitted from this MCS." ::= { marsMcsStatEntry 3 } marsMcsStatRxMultiMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MULTI messages received by this MCS." ::= { marsMcsStatEntry 4 } marsMcsStatRxSjoinMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_SJOIN messages received by Chung & Greene Standards Track [Page 59] RFC 2417 Multicast MIB September 1998 this MCS." ::= { marsMcsStatEntry 5 } marsMcsStatRxSleaveMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_SLEAVE messages received by this MCS." ::= { marsMcsStatEntry 6 } marsMcsStatRxNakMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_NAK messages received by this MCS." ::= { marsMcsStatEntry 7 } marsMcsStatRxMigrateMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of MARS_MIGRATE messages received by this MCS." ::= { marsMcsStatEntry 8 } marsMcsStatFailMultiMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of timeouts occurred indicating failure of the last MARS_MULTI to arrive." ::= { marsMcsStatEntry 9 } --*************************************************************** -- IP ATM MARS Notification Definitions --*************************************************************** marsTrapInfo OBJECT IDENTIFIER ::= { marsMIB 0 } marsFaultTrap NOTIFICATION-TYPE OBJECTS { marsAddr, Chung & Greene Standards Track [Page 60] RFC 2417 Multicast MIB September 1998 marsServStatus } STATUS current DESCRIPTION "This trap/inform is sent to the manager whenever there is a fault condition occurred on a MARS." ::= { marsTrapInfo 1 } --*************************************************************** -- IP ATM MARS Conformance Definitions --*************************************************************** marsConformance OBJECT IDENTIFIER ::= { marsMIB 4 } marsClientConformance OBJECT IDENTIFIER ::= { marsConformance 1 } marsServerConformance OBJECT IDENTIFIER ::= { marsConformance 2 } marsMcsConformance OBJECT IDENTIFIER ::= { marsConformance 3 } marsClientCompliances OBJECT IDENTIFIER ::= { marsClientConformance 1 } marsClientGroups OBJECT IDENTIFIER ::= { marsClientConformance 2 } marsServerCompliances OBJECT IDENTIFIER ::= { marsServerConformance 1 } marsServerGroups OBJECT IDENTIFIER ::= { marsServerConformance 2 } marsMcsCompliances OBJECT IDENTIFIER ::= { marsMcsConformance 1 } marsMcsGroups OBJECT IDENTIFIER ::= { marsMcsConformance 2 } --*************************************************************** -- MARS Client Compliance Statements --*************************************************************** marsClientCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that are required for the management of MARS clients." MODULE MANDATORY-GROUPS { marsClientGroup } OBJECT marsClientAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientDefaultMarsAddr Chung & Greene Standards Track [Page 61] RFC 2417 Multicast MIB September 1998 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientHsn MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientRegistration MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientCmi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientDefaultMtu MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientFailureTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientRetranDelayTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientRdmMulReqAddRetrTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientRdmVcRevalidateTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientJoinLeaveRetrInterval MIN-ACCESS read-only DESCRIPTION Chung & Greene Standards Track [Page 62] RFC 2417 Multicast MIB September 1998 "Write access is not required." OBJECT marsClientJoinLeaveRetrLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientRegWithMarsRdmTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientForceWaitTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientLmtToMissRedirMapTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientIdleTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientMcGrpRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientBackupMarsRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientVcType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientVcCtrlType Chung & Greene Standards Track [Page 63] RFC 2417 Multicast MIB September 1998 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientVcIdleTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientVcRevalidate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientVcEncapsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientVcNegotiatedMtu MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsClientVcRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { marsClientCompliances 1 } marsClientGroup OBJECT-GROUP OBJECTS { marsClientAddr, marsClientDefaultMarsAddr, marsClientHsn, marsClientRegistration, marsClientCmi, marsClientDefaultMtu, marsClientFailureTimer, marsClientRetranDelayTimer, marsClientRdmMulReqAddRetrTimer, marsClientRdmVcRevalidateTimer, marsClientJoinLeaveRetrInterval, marsClientJoinLeaveRetrLimit, marsClientRegWithMarsRdmTimer, marsClientForceWaitTimer, marsClientIdleTimer, Chung & Greene Standards Track [Page 64] RFC 2417 Multicast MIB September 1998 marsClientLmtToMissRedirMapTimer, marsClientRowStatus, marsClientMcGrpRowStatus, marsClientBackupMarsRowStatus, marsClientVcPartyAddrType, marsClientVcType, marsClientVcCtrlType, marsClientVcIdleTimer, marsClientVcRevalidate, marsClientVcEncapsType, marsClientVcNegotiatedMtu, marsClientVcRowStatus, marsClientStatTxReqMsgs, marsClientStatTxJoinMsgs, marsClientStatTxLeaveMsgs, marsClientStatTxGrpLstReqMsgs, marsClientStatRxJoinMsgs, marsClientStatRxLeaveMsgs, marsClientStatRxMultiMsgs, marsClientStatRxNakMsgs, marsClientStatRxGrpLstRplyMsgs, marsClientStatRxMigrateMsgs, marsClientStatFailMultiMsgs } STATUS current DESCRIPTION "A collection of objects to be implemented in a MIB for the management of MARS clients." ::= { marsClientGroups 1 } --*************************************************************** -- MARS Server Compliance Statements --*************************************************************** marsServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that are required for the management of MARS servers." MODULE -- this module MANDATORY-GROUPS { marsServerGroup, marsServerEventGroup } OBJECT marsAddr MIN-ACCESS read-only DESCRIPTION Chung & Greene Standards Track [Page 65] RFC 2417 Multicast MIB September 1998 "Write access is not required." OBJECT marsLocal MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsServStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsServType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsServPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsRedirMapMsgTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsCsn MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsSsn MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcGrpAddrUsage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcGrpRowStatus Chung & Greene Standards Track [Page 66] RFC 2417 Multicast MIB September 1998 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsHostMapRowType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsHostMapRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsServerMapRowType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsServerMapRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsVcPartyAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsVcType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsVcCtrlType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsVcIdleTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsVcCmi MIN-ACCESS read-only DESCRIPTION "Write access is not required." Chung & Greene Standards Track [Page 67] RFC 2417 Multicast MIB September 1998 OBJECT marsVcEncapsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsVcNegotiatedMtu MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsVcRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { marsServerCompliances 1 } marsServerGroup OBJECT-GROUP OBJECTS { marsAddr, marsLocal, marsServStatus, marsServType, marsServPriority, marsRedirMapMsgTimer, marsCsn, marsSsn, marsRowStatus, marsMcGrpAddrUsage, marsMcGrpRxLayer3GrpSets, marsMcGrpRxLayer3GrpResets, marsMcGrpRowStatus, marsHostMapRowType, marsHostMapRowStatus, marsServerMapRowType, marsServerMapRowStatus, marsVcPartyAddrType, marsVcType, marsVcCtrlType, marsVcIdleTimer, marsVcCmi, marsVcEncapsType, marsVcNegotiatedMtu, marsVcRowStatus, marsRegClientAtmAddr, marsRegMcsAtmAddr, marsStatTxMultiMsgs, marsStatTxGrpLstRplyMsgs, Chung & Greene Standards Track [Page 68] RFC 2417 Multicast MIB September 1998 marsStatTxRedirectMapMsgs, marsStatTxMigrateMsgs, marsStatTxNakMsgs, marsStatTxJoinMsgs, marsStatTxLeaveMsgs, marsStatTxSjoinMsgs, marsStatTxSleaveMsgs, marsStatTxMservMsgs, marsStatTxUnservMsgs, marsStatRxReqMsgs, marsStatRxGrpLstReqMsgs, marsStatRxJoinMsgs, marsStatRxLeaveMsgs, marsStatRxMservMsgs, marsStatRxUnservMsgs, marsStatRxBlkJoinMsgs, marsStatRegMemGroups, marsStatRegMcsGroups } STATUS current DESCRIPTION "A collection of objects to be implemented in a MIB for the management of MARS servers." ::= { marsServerGroups 1 } marsServerEventGroup NOTIFICATION-GROUP NOTIFICATIONS { marsFaultTrap } STATUS current DESCRIPTION "A collection of events that can be generated from a MARS server." ::= { marsServerGroups 2 } --*************************************************************** -- MARS Multicast Server (MCS) Compliance Statements --*************************************************************** marsMcsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that are required for the management of MARS multicast servers (MCS)." MODULE MANDATORY-GROUPS { marsMcsGroup } OBJECT marsMcsAddr Chung & Greene Standards Track [Page 69] RFC 2417 Multicast MIB September 1998 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsDefaultMarsAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsRegistration MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsSsn MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsDefaultMtu MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsFailureTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsRetranDelayTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsRdmMulReqAddRetrTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsRdmVcRevalidateTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsRegisterRetrInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." Chung & Greene Standards Track [Page 70] RFC 2417 Multicast MIB September 1998 OBJECT marsMcsRegisterRetrLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsForceWaitTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsLmtToMissRedirMapTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsIdleTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsMcGrpRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsBackupMarsRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsVcPartyAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsVcType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsVcCtrlType MIN-ACCESS read-only DESCRIPTION Chung & Greene Standards Track [Page 71] RFC 2417 Multicast MIB September 1998 "Write access is not required." OBJECT marsMcsVcIdleTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsVcRevalidate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsVcEncapsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsVcNegotiatedMtu MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT marsMcsVcRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { marsMcsCompliances 1 } marsMcsGroup OBJECT-GROUP OBJECTS { marsMcsAddr, marsMcsDefaultMarsAddr, marsMcsRegistration, marsMcsSsn , marsMcsDefaultMtu, marsMcsFailureTimer, marsMcsRetranDelayTimer, marsMcsRdmMulReqAddRetrTimer, marsMcsRdmVcRevalidateTimer, marsMcsRegisterRetrInterval, marsMcsRegisterRetrLimit, marsMcsRegWithMarsRdmTimer, marsMcsForceWaitTimer, marsMcsIdleTimer, marsMcsLmtToMissRedirMapTimer, marsMcsRowStatus, marsMcsMcGrpRowStatus, Chung & Greene Standards Track [Page 72] RFC 2417 Multicast MIB September 1998 marsMcsVcPartyAddrType, marsMcsBackupMarsRowStatus, marsMcsVcType, marsMcsVcCtrlType, marsMcsVcIdleTimer, marsMcsVcRevalidate, marsMcsVcEncapsType, marsMcsVcNegotiatedMtu, marsMcsVcRowStatus, marsMcsStatTxReqMsgs, marsMcsStatTxMservMsgs, marsMcsStatTxUnservMsgs, marsMcsStatRxMultiMsgs, marsMcsStatRxSjoinMsgs, marsMcsStatRxSleaveMsgs, marsMcsStatRxNakMsgs, marsMcsStatRxMigrateMsgs, marsMcsStatFailMultiMsgs } STATUS current DESCRIPTION "A collection of objects to be implemented in a MIB for the management of MARS multicast servers (MCS)." ::= { marsMcsGroups 1 } END 4. Acknowledgments This document is a product of the IETF's Internetworking Over NBMA Networks (ion) Working Group. The original work of the MARS MIB developement was sponsored by Science Applications International Corporation (SAIC). The author would like to recognize Grenville Armitage (Bellcore), Ken Carlberg (SAIC), Ramesh Uppuluri (Fore Systems), and Radha Gowda SYNNET), and Bill Willcox (Fujitsu Nexion) for their support and comments in completing the MARS MIB. Also thanks to Bert Wijnen (IBM) for his thorough review of the MARS MIB. 5. References [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996. Chung & Greene Standards Track [Page 73] RFC 2417 Multicast MIB September 1998 [2] 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. [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [6] 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. [7] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [8] SNMPv3 Working Group, Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [9] SNMPv3 Working Group, Wijnen, B., Presuhn, R., and K. McCloghire, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. Chung & Greene Standards Track [Page 74] RFC 2417 Multicast MIB September 1998 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such object may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [8] and the View-based Access Control Model RFC 2275 [9] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have a legitimate rights to indeed SET (change/create/delete) them. Note: read-access in fact may also need access-control. 7. Authors' Addresses Chris Chung Independent Consultant EMail: chihschung@aol.com Maria Greene (editor) Independent Contractor EMail: maria@xedia.com Chung & Greene Standards Track [Page 75] RFC 2417 Multicast MIB September 1998 8. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chung & Greene Standards Track [Page 76] snmp-mibs-downloader-1.1/mibrfcs/rfc2452.txt0000644000000000000000000004517611402176071015573 0ustar Network Working Group M. Daniele Request for Comments: 2452 Compaq Computer Corporation Category: Standards Track December 1998 IP Version 6 Management Information Base for the Transmission Control Protocol 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of which IP versions underlie TCP, and only the TCP connection information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. 1. Introduction A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Daniele Standards Track [Page 1] RFC 2452 TCP MIB for IPv6 December 1998 Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. 2. Overview This document is one in the series of documents that define various MIB objects, and statements of conformance, for IPv6. This document defines the required instrumentation for implementations of TCP over IPv6. 3. Transparency of IP versions to TCP The fact that a particular TCP connection uses IPv6 as opposed to IPv4, is largely invisible to a TCP implementation. A "TCPng" did not need to be defined, implementations simply need to support IPv6 addresses. As such, the managed objects already defined in [TCP MIB] are sufficient for managing TCP in the presence of IPv6. These objects are equally applicable whether the managed node supports IPv4 only, IPv6 only, or both IPv4 and IPv6. For example, tcpActiveOpens counts "The number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state", regardless of which version of IP is used between the connection endpoints. Stated differently, TCP implementations don't need separate counters for IPv4 and for IPv6. 4. Representing TCP Connections The exception to the statements in section 3 is the tcpConnTable. Since IPv6 addresses cannot be represented with the IpAddress syntax, not all TCP connections can be represented in the tcpConnTable defined in [TCP MIB]. Daniele Standards Track [Page 2] RFC 2452 TCP MIB for IPv6 December 1998 This memo defines a new, separate table to represent only those TCP connections between IPv6 endpoints. TCP connections between IPv4 endpoints continue to be represented in tcpConnTable [TCP MIB]. (It is not possible to establish a TCP connection between an IPv4 endpoint and an IPv6 endpoint.) A different approach would have been to define a new table to represent all TCP connections regardless of IP version. This would require changes to [TCP MIB] and hence to existing (IPv4-only) TCP implementations. The approach suggested in this memo has the advantage of leaving IPv4-only implementations intact. It is assumed that the objects defined in this memo will eventually be defined in an update to [TCP MIB]. For this reason, the module identity is assigned under the experimental portion of the MIB. 5. Conformance This memo contains conformance statements to define conformance to this MIB for TCP over IPv6 implementations. 6. Definitions IPV6-TCP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, mib-2, experimental FROM SNMPv2-SMI Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; ipv6TcpMIB MODULE-IDENTITY LAST-UPDATED "9801290000Z" ORGANIZATION "IETF IPv6 MIB Working Group" CONTACT-INFO " Mike Daniele Postal: Compaq Computer Corporation 110 Spitbrook Rd Nashua, NH 03062. US Phone: +1 603 884 1423 Email: daniele@zk3.dec.com" DESCRIPTION "The MIB module for entities implementing TCP over IPv6." ::= { experimental 86 } Daniele Standards Track [Page 3] RFC 2452 TCP MIB for IPv6 December 1998 -- objects specific to TCP for IPv6 tcp OBJECT IDENTIFIER ::= { mib-2 6 } -- the TCP over IPv6 Connection table -- This connection table contains information about this -- entity's existing TCP connections between IPv6 endpoints. -- Only connections between IPv6 addresses are contained in -- this table. This entity's connections between IPv4 -- endpoints are contained in tcpConnTable. ipv6TcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6TcpConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing TCP connection-specific information, for only those connections whose endpoints are IPv6 addresses." ::= { tcp 16 } ipv6TcpConnEntry OBJECT-TYPE SYNTAX Ipv6TcpConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the ipv6TcpConnTable containing information about a particular current TCP connection. Each row of this table is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state. Note that conceptual rows in this table require an additional index object compared to tcpConnTable, since IPv6 addresses are not guaranteed to be unique on the managed node." INDEX { ipv6TcpConnLocalAddress, ipv6TcpConnLocalPort, ipv6TcpConnRemAddress, ipv6TcpConnRemPort, ipv6TcpConnIfIndex } ::= { ipv6TcpConnTable 1 } Ipv6TcpConnEntry ::= SEQUENCE { ipv6TcpConnLocalAddress Ipv6Address, ipv6TcpConnLocalPort INTEGER (0..65535), ipv6TcpConnRemAddress Ipv6Address, ipv6TcpConnRemPort INTEGER (0..65535), ipv6TcpConnIfIndex Ipv6IfIndexOrZero, Daniele Standards Track [Page 4] RFC 2452 TCP MIB for IPv6 December 1998 ipv6TcpConnState INTEGER } ipv6TcpConnLocalAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local IPv6 address for this TCP connection. In the case of a connection in the listen state which is willing to accept connections for any IPv6 address associated with the managed node, the value ::0 is used." ::= { ipv6TcpConnEntry 1 } ipv6TcpConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local port number for this TCP connection." ::= { ipv6TcpConnEntry 2 } ipv6TcpConnRemAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote IPv6 address for this TCP connection." ::= { ipv6TcpConnEntry 3 } ipv6TcpConnRemPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port number for this TCP connection." ::= { ipv6TcpConnEntry 4 } ipv6TcpConnIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index object used to disambiguate conceptual rows in the table, since the connection 4-tuple may not be unique. If the connection's remote address (ipv6TcpConnRemAddress) is a link-local address and the connection's local address Daniele Standards Track [Page 5] RFC 2452 TCP MIB for IPv6 December 1998 (ipv6TcpConnLocalAddress) is not a link-local address, this object identifies a local interface on the same link as the connection's remote link-local address. Otherwise, this object identifies the local interface that is associated with the ipv6TcpConnLocalAddress for this TCP connection. If such a local interface cannot be determined, this object should take on the value 0. (A possible example of this would be if the value of ipv6TcpConnLocalAddress is ::0.) The interface identified by a particular non-0 value of this index is the same interface as identified by the same value of ipv6IfIndex. The value of this object must remain constant during the life of the TCP connection." ::= { ipv6TcpConnEntry 5 } ipv6TcpConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) } MAX-ACCESS read-write STATUS current DESCRIPTION "The state of this TCP connection. The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return an error response (`badValue' for SNMPv1, 'wrongValue' for SNMPv2) if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. Daniele Standards Track [Page 6] RFC 2452 TCP MIB for IPv6 December 1998 As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably)." ::= { ipv6TcpConnEntry 6 } -- -- conformance information -- ipv6TcpConformance OBJECT IDENTIFIER ::= { ipv6TcpMIB 2 } ipv6TcpCompliances OBJECT IDENTIFIER ::= { ipv6TcpConformance 1 } ipv6TcpGroups OBJECT IDENTIFIER ::= { ipv6TcpConformance 2 } -- compliance statements ipv6TcpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement TCP over IPv6." MODULE -- this module MANDATORY-GROUPS { ipv6TcpGroup } ::= { ipv6TcpCompliances 1 } ipv6TcpGroup OBJECT-GROUP OBJECTS { -- these are defined in this module -- ipv6TcpConnLocalAddress (not-accessible) -- ipv6TcpConnLocalPort (not-accessible) -- ipv6TcpConnRemAddress (not-accessible) -- ipv6TcpConnRemPort (not-accessible) -- ipv6TcpConnIfIndex (not-accessible) ipv6TcpConnState } STATUS current DESCRIPTION "The group of objects providing management of TCP over IPv6." ::= { ipv6TcpGroups 1 } END Daniele Standards Track [Page 7] RFC 2452 TCP MIB for IPv6 December 1998 7. Acknowledgments This memo is a product of the IPng work group, and benefited especially from the contributions of the following working group members: Dimitry Haskin Bay Networks Margaret Forsythe Epilogue Tim Hartrick Mentat Frank Solensky FTP Jack McCann DEC 8. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] McCloghrie, K., Editor, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [TCP MIB] SNMPv2 Working Group, McCloghrie, K., Editor, "SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2", RFC 2012, November 1996. [IPV6 MIB TC] Haskin, D., and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998. [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2274] Blumenthal, U., and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. 9. Security Considerations This MIB contains a management object that has a MAX-ACCESS clause of read-write and/or read-create. In particular, it is possible to delete individual TCP control blocks (i.e., connections). Daniele Standards Track [Page 8] RFC 2452 TCP MIB for IPv6 December 1998 Consequently, anyone having the ability to issue a SET on this object can impact the operation of the node. There are a number of managed objects in this MIB that may be considered to contain sensitive information in some environments. For example, the MIB identifies the active TCP connections on the node. Although this information might be considered sensitive in some environments (i.e., to identify ports on which to launch denial-of-service or other attacks), there are already other ways of obtaining similar information. For example, sending a random TCP packet to an unused port prompts the generation of a TCP reset message. Therefore, it may be important in some environments to control read and/or write access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself does not provide encryption or strong authentication. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [RFC2274] and the View-based Access Control Model [RFC2275] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 10. Author's Address Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua, NH 03062 Phone: +1-603-884-1423 EMail: daniele@zk3.dec.com Daniele Standards Track [Page 9] RFC 2452 TCP MIB for IPv6 December 1998 11. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Daniele Standards Track [Page 10] snmp-mibs-downloader-1.1/mibrfcs/rfc2454.txt0000644000000000000000000003676211402176071015576 0ustar Network Working Group M. Daniele Request for Comments: 2454 Compaq Computer Corporation Category: Standards Track December 1998 IP Version 6 Management Information Base for the User Datagram Protocol 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of which IP versions underlie UDP, and only the UDP listener information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. 1. Introduction A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Daniele Standards Track [Page 1] RFC 2454 UDP MIB for IPv6 December 1998 Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. 2. Overview This document is one in the series of documents that define various MIB objects, and statements of conformance, for IPv6. This document defines the required instrumentation for implementations of UDP over IPv6. 3. Transparency of IP versions to UDP The fact that UDP is carried over IPv6 as opposed to IPv4, is largely invisible to a UDP implementation. A "UDPng" did not need to be defined, implementations simply need to support IPv6 addresses. As such, the managed objects already defined in [UDP MIB] are sufficient for managing UDP in the presence of IPv6. These objects are equally applicable whether the managed node supports IPv4 only, IPv6 only, or both IPv4 and IPv6. For example, udpInDatagrams counts "The total number of UDP datagrams delivered to UDP users", regardless of which version of IP is used to deliver any of those datagrams. Stated differently, UDP implementations don't need separate counters for IPv4 and for IPv6. 4. Representing UDP Listeners The exception to the statements in section 3 is the udpTable. Since IPv6 addresses cannot be represented with the IpAddress syntax, not all UDP endpoints can be represented in the udpTable defined in [UDP MIB]. This memo defines a new, separate table to represent only those UDP endpoints that utilize an IPv6 address. UDP endpoints on IPv4 addresses continue to be represented in udpTable [UDP MIB]. Daniele Standards Track [Page 2] RFC 2454 UDP MIB for IPv6 December 1998 A different approach would have been to define a new table to represent all UDP endpoints regardless of IP version. This would require changes to [UDP MIB] and hence to existing (IPv4-only) UDP implementations. The approach suggested in this memo has the advantage of leaving IPv4-only implementations intact. It is assumed that the objects defined in this memo will eventually be defined in an update to [UDP MIB]. For this reason, the module identity is assigned under the experimental portion of the MIB. 5. Conformance This memo contains conformance statements to define conformance to this MIB for UDP over IPv6 implementations. 6. Definitions IPV6-UDP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, mib-2, experimental FROM SNMPv2-SMI Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC; ipv6UdpMIB MODULE-IDENTITY LAST-UPDATED "9801290000Z" ORGANIZATION "IETF IPv6 MIB Working Group" CONTACT-INFO " Mike Daniele Postal: Compaq Computer Corporation 110 Spitbrook Rd Nashua, NH 03062. US Phone: +1 603 884 1423 Email: daniele@zk3.dec.com" DESCRIPTION "The MIB module for entities implementing UDP over IPv6." ::= { experimental 87 } -- objects specific to UDP for IPv6 udp OBJECT IDENTIFIER ::= { mib-2 7 } -- the UDP over IPv6 Listener table Daniele Standards Track [Page 3] RFC 2454 UDP MIB for IPv6 December 1998 -- This table contains information about this entity's -- UDP/IPv6 endpoints. Only endpoints utilizing IPv6 addresses -- are contained in this table. This entity's UDP/IPv4 endpoints -- are contained in udpTable. ipv6UdpTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6UdpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing UDP listener information for UDP/IPv6 endpoints." ::= { udp 6 } ipv6UdpEntry OBJECT-TYPE SYNTAX Ipv6UdpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular current UDP listener. Note that conceptual rows in this table require an additional index object compared to udpTable, since IPv6 addresses are not guaranteed to be unique on the managed node." INDEX { ipv6UdpLocalAddress, ipv6UdpLocalPort, ipv6UdpIfIndex } ::= { ipv6UdpTable 1 } Ipv6UdpEntry ::= SEQUENCE { ipv6UdpLocalAddress Ipv6Address, ipv6UdpLocalPort INTEGER (0..65535), ipv6UdpIfIndex Ipv6IfIndexOrZero } ipv6UdpLocalAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local IPv6 address for this UDP listener. In the case of a UDP listener which is willing to accept datagrams for any IPv6 address associated with the managed node, the value ::0 is used." ::= { ipv6UdpEntry 1 } ipv6UdpLocalPort OBJECT-TYPE Daniele Standards Track [Page 4] RFC 2454 UDP MIB for IPv6 December 1998 SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local port number for this UDP listener." ::= { ipv6UdpEntry 2 } ipv6UdpIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "An index object used to disambiguate conceptual rows in the table, since the ipv6UdpLocalAddress/ipv6UdpLocalPort pair may not be unique. This object identifies the local interface that is associated with ipv6UdpLocalAddress for this UDP listener. If such a local interface cannot be determined, this object should take on the value 0. (A possible example of this would be if the value of ipv6UdpLocalAddress is ::0.) The interface identified by a particular non-0 value of this index is the same interface as identified by the same value of ipv6IfIndex. The value of this object must remain constant during the life of this UDP endpoint." ::= { ipv6UdpEntry 3 } -- -- conformance information -- ipv6UdpConformance OBJECT IDENTIFIER ::= { ipv6UdpMIB 2 } ipv6UdpCompliances OBJECT IDENTIFIER ::= { ipv6UdpConformance 1 } ipv6UdpGroups OBJECT IDENTIFIER ::= { ipv6UdpConformance 2 } -- compliance statements ipv6UdpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement UDP over IPv6." MODULE -- this module MANDATORY-GROUPS { ipv6UdpGroup } Daniele Standards Track [Page 5] RFC 2454 UDP MIB for IPv6 December 1998 ::= { ipv6UdpCompliances 1 } ipv6UdpGroup OBJECT-GROUP OBJECTS { -- these are defined in this module -- ipv6UdpLocalAddress (not-accessible) -- ipv6UdpLocalPort (not-accessible) ipv6UdpIfIndex } STATUS current DESCRIPTION "The group of objects providing management of UDP over IPv6." ::= { ipv6UdpGroups 1 } END 7. Acknowledgments This memo is a product of the IPng work group, and benefited especially from the contributions of the following working group members: Dimitry Haskin Bay Networks Margaret Forsythe Epilogue Tim Hartrick Mentat Frank Solensky FTP Jack McCann DEC 8. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] McCloghrie, K., Editor, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [UDP MIB] SNMPv2 Working Group, McCloghrie, K., Editor, "SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2", RFC 2013, November 1996. [IPV6 MIB TC] Haskin, D., and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998. Daniele Standards Track [Page 6] RFC 2454 UDP MIB for IPv6 December 1998 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2274] Blumenthal, U., and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. 9. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. There are a number of managed objects in this MIB that may be considered to contain sensitive information in some environments. For example, the MIB identifies UDP ports on which processes are listening. Although this information might be considered sensitive in some environments (i.e., to identify ports on which to launch denial-of-service or other attacks), there are already other ways of obtaining similar information. For example, sending a random UDP packet to an unused port prompts the generation of an ICMP port unreachable message. Therefore, it may be important in some environments to control read access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself does not provide encryption or strong authentication. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [RFC2274] and the View-based Access Control Model [RFC2275] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. Daniele Standards Track [Page 7] RFC 2454 UDP MIB for IPv6 December 1998 10. Author's Address Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua, NH 03062 Phone: +1-603-884-1423 EMail: daniele@zk3.dec.com Daniele Standards Track [Page 8] RFC 2454 UDP MIB for IPv6 December 1998 11. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Daniele Standards Track [Page 9] snmp-mibs-downloader-1.1/mibrfcs/rfc2455.txt0000644000000000000000000075226511402176071015602 0ustar Network Working Group B. Clouston Request for Comments: 2455 Cisco Systems Obsoletes: 2155 B. Moore Category: Standards Track IBM Corporation November 1998 Definitions of Managed Objects for APPN 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. Table of Contents 1. Introduction .......................................... 2 2. The SNMPv2 Network Management Framework ............... 2 3. Overview .............................................. 3 3.1 Relationship with RFC 2155 ........................... 6 3.2 APPN MIB structure ................................... 7 4. Definitions ........................................... 10 5. Security Considerations ............................... 135 6. Intellectual Property ................................. 136 7. Acknowledgments ....................................... 137 8. References ............................................ 137 9. Authors' Addresses .................................... 139 10. Full Copyright Statement .............................. 140 Clouston & Moore Standards Track [Page 1] RFC 2455 APPN MIB November 1998 1. Introduction This document is a product of the SNA NAU Services MIB Working Group. It defines a MIB module for managing devices with Advanced Peer-to- Peer Networking (APPN) capabilities. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [17]. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Clouston & Moore Standards Track [Page 2] RFC 2455 APPN MIB November 1998 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This document identifies a set of objects for monitoring the configuration and active characteristics of devices with APPN capabilities, and for controlling certain characteristics. APPN is the aspect of Systems Network Architecture (SNA) that supports peer- to-peer networking. These networks transport both independent and dependent LU session traffic. See the SNANAU APPC MIB [21] and the SNA NAU MIB [22] for management of these sessions. See also RFC 2232, the DLUR MIB [23], and RFC 2238, the HPR MIB [24] for management of extensions to the APPN architecture. In this document, we describe APPN managed objects. An APPN network comprises various types of nodes, and transmission groups (TGs) that connect the nodes. Network nodes (NNs) provide directory and routing functions for session establishment. NNs may be session end points or intermediate nodes in a session. A border node is a type of network node that connects networks together for session establishment without fully merging them. A branch network node (BrNN) is a network node that is similar to a border node, but with only minimal functions to build a large APPN network within an enterprise. Although a BrNN is defined to be a network node in the APPN architecture, it also has an end node (EN) appearance to upstream NNs in the network. In this MIB module it is treated as a separate node type since it does not fit cleanly as an EN or NN, and this module explicity identifies those objects returned by a BrNN. For example, a BrNN does not implement the appnNnTopo objects since it is the only node in its network topology table; but it does implement the appnSessIntermediate objects since it does have intermediate session support. It also implements two of the appnEnUniqueCaps objects that could be useful to a management application. A BrNN identifies itself as 'endNode' in the appnNodeType object but further identifies itself as a BrNN in the appnNodeBrNn object. End nodes are session end points that receive directory and routing functions from network nodes, over control-point to control-point (CP-CP) sessions. Low-entry networking (LEN) nodes are also session Clouston & Moore Standards Track [Page 3] RFC 2455 APPN MIB November 1998 end points, but do not support CP-CP sessions, and therefore need additional manual configuration definitions to establish sessions in an APPN network. ENs and LEN nodes may have minimal directory and routing functions to establish control sessions (ENs) or to connect into the APPN network (LEN nodes). Virtual routing nodes (VRNs) are not really nodes, but rather common definitions among actual nodes in a shared transport facility such as a local area network (LAN) that allow these actual nodes to temporarily establish a logical link with one another without defining each other's link-level addressing information. Ports and link stations are the node's interface to the data link control (DLC), which provides the physical transport, or to another protocol such as Data Link Switching (DLSw), which provides transport over an IP network. See the SNADLC SDLC MIB[25], the SNADLC LLC MIB[26], and the DLSw MIB[27]. A link station uses a port to make a connection to another node. This connection establishes a TG between the two nodes. The directory and routing functions enable an NN to find where an LU is located in the network, and calculate the optimal route for the session based on the requested class of service (COS). A network node saves the LU information in a directory database, which is built from LUs defined locally, LU registration from served end nodes, and LUs learned from network searches. Each NN maintains a local COS database that assigns a routing weight, or relative cost, to each resource for each class of service. For example, the #INTER COS assigns a lower weight to TGs with a greater effective capacity, while the #BATCH COS favors TGs with a lower relative cost per byte. A node saves network topology information (on NNs, VRNs, and TGs between them) in a network topology database. A node that supports APPN function set 1120, branch awareness, also saves information on TGs to adjacent BrNNs. The topology information includes state and routing characteristics. Topology information is exchanged between NNs over CP-CP sessions such that the database is fully replicated at each NN. Information on TGs to all node types are kept in a local topology database. Local topology information is shared with other nodes only during the session establishment process, to give the NN responsible for route calculation the necessary information for end- to-end route calculation. A management application can show a full representation of the APPN network from the network and local topology information. To show the network topology, the application need only query the network Clouston & Moore Standards Track [Page 4] RFC 2455 APPN MIB November 1998 topology tables from a single NN. To show all of the BrNNs, the application must also directly query all destinations of TGs that indicate they are branch TGs (indicated by the appnNnTgFRBranchTg object) to see if they have any cascaded BrNNs. For any NNs that do not indicate branch awareness support (indicated by the appnNnNodeFRBranchAwareness object), the application must query each NN's appnLocalTgTable, and then the appnNodeBrNn object of each row's destination node to identify BrNNs. To show all of the nodes in the network, including ENs and LEN nodes, the application must query every NN's appnLocalTgTable, and iteratively do the same for each BrNN it finds. SNA names such as LU names, CP names, COS names, and mode names can be padded with blanks (space characters) in SNA formats. These blanks are nonsignificant. For example, in a BIND Request Unit (RU) a COS name of "#INTER" with a length of 6 is identical to a COS name of "#INTER " with a length of 8. However, in this MIB, nonsignificant blanks are not included by the agent. Using the COS name from the previous example, an agent would return a length of 6 and the string "#INTER" with no blanks for appnCosName, regardless of how it appears in the BIND RU or in internal storage. The lone exception is the all blank mode name, for which the agent returns a length of 8 and the string " " (8 blank spaces). The MIB variables that this applies to are identified by a textual convention syntax that also describes this behavior. When an SNA name is functioning as a table index, an agent treats trailing blanks as significant. If a management station requests the objects from a row with index "#INTER ", the agent does not match this to the row with index "#INTER". Since an agent has no nonsignificant blanks in any of its table indices, the only reason for a Management Station to include them would be to start GetNext processing at a chosen point in a table. For example, a GetNext request with index "M " would start retrieval from a table at the first row with an 8-character index beginning with "M" or a letter after "M". The SNA/APPN terms and overall architecture are documented in [18], [19], [20], and [28]. Highlights of the management functions supported by the APPN MIB module include the following: o Activating and deactivating ports and link stations. o Monitoring of configuration parameters related to the node, ports, link stations, virtual routing nodes, and classes of service. Clouston & Moore Standards Track [Page 5] RFC 2455 APPN MIB November 1998 o Monitoring of operational parameters related to ports, link stations, virtual routing nodes, topology, directory, and intermediate sessions. o Historical information about link station errors during connection establishment, or that caused the connection to terminate. o Deactivating intermediate sessions. o Traps for SNA Management Services (SNA/MS) Alert conditions. This MIB module does not support: o Configuration of APPN nodes. o Monitoring and control of endpoint sessions. o Dependent LU Requester (DLUR) management. o High-Performance Routing (HPR) management. 3.1. Relationship with RFC 2155 This MIB obsoletes RFC 2155 [29] with changes due to additions to the APPN architecture and some implementation experience of RFC 2155. The changes from RFC 2155 are as follows: o New objects for the multi-link TG architecture enhancement: appnLsMltgMember, appnNnTgFRMltgLinkType, appnLocalTgMltgLinkType, and appnLocalEnTgMltgLinkType. o New objects, and explanations for values for existing objects, for the branch network node architecture enhancement: appnNodeBrNn, appnNnNodeFRBranchAwareness, appnNnTgFRBranchTg, and appnLocalTgBranchLinkType. o New object, appnNodeLsCounterType, to indicate which type of ANR traffic is returned in the appnLsTable traffic counters. o Deprecated appnNodeMibVersion object. o Miscellaneous editorial changes. Clouston & Moore Standards Track [Page 6] RFC 2455 APPN MIB November 1998 3.2. APPN MIB Structure The APPN MIB module contains the following groups of objects: o appnNode - objects related to the APPN node for all node types. o appnNn - objects to represent the network nodes, virtual routing nodes, and TGs between these nodes that make up the APPN network topology database maintained in NNs. o appnLocalTopology - objects to represent nodes and TGs between nodes in the local topology database maintained in all nodes. o appnDir - objects related to LU location information from the node's directory database. o appnCos - objects related to classes of service information. o appnSessIntermediate - objects related to intermediate sessions that pass through this node. These groups are described below in more detail. 3.2.1. appnNode group The appnNode group consists of the following tables and objects: 1) appnGeneralInfoAndCaps This group of objects describes general information about the APPN node. The type of information includes the node type and the time since this node was initialized. 2) appnNnUniqueInfoAndCaps This group of objects describes information specific to network nodes such as node routing characteristics. 3) appnEnUniqueInfoAndCaps This group of objects describes information specific to end nodes, with two objects that also apply to branch network nodes. This group includes an object indicating the node's network node server. Clouston & Moore Standards Track [Page 7] RFC 2455 APPN MIB November 1998 4) appnPortInformation This includes the appnPortTable, which describes the configuration and current status of the ports used by APPN, including the port state and DLC type. 5) appnLinkStationInformation This includes the appnNodeLsTable, which describes the configuration and current status of the link stations used by APPN, including the link state and port name; and the appnLsStatusTable, which provides information about errors this node encountered with connections to adjacent nodes, such as the sense data captured during connection failures. It is a product option to decide how many appnLsStatusTable entries are kept. 6) appnVrnInfo This includes the appnVrnTable, which describes the relationship between virtual routing nodes' TGs described in the appnLocalTgTable with ports in the appnPortTable. 3.2.2. appnNn group The appnNn group consists of the following objects and tables 1) appnNnTopo These objects contain general information about the network topology database including the number of nodes present, and the number of topology database updates (TDU) wars the node has detected. 2) appnNnTopology This includes tables representing the APPN network topology database. This includes the network nodes, virtual routing nodes, and TGs between these nodes, as well as the information about these resources carried in topology updates. The tables are first indexed by the same flow reduction sequence number (FRSN) used in topology exchanges between NNs. This allows a management station to retrieve only incremental updates, since the agent will update the FRSN of new or changed resources. 3.2.3. appnLocalTopology group The appnLocalTopology group consists of the following objects and tables: Clouston & Moore Standards Track [Page 8] RFC 2455 APPN MIB November 1998 1) appnLocalThisNode a) appnLocalGeneral Contains the local node and type. b) appnLocalNnSpecific These objects contain routing information about the local network node. c) appnLocalTg This table represents information about this node's local TGs. 2) appnLocalEnTopology This table represents TG information for EN TGs learned by the NN via TG registration with the local node. 3.2.4. appnDir group The appnDir group consists of the following objects and tables: 1) appnDirPerf These objects represent information related to information about the directory database and directory searches involving this node. 2) appnDirTable This table represents the directory database, listing LUs known to this node, along with the owning node of the LU and the serving NN of the owning node. 3.2.5. appnCos group The appnCos group consists of the following tables: 1) appnCosModeTable This table represents the mode to class of service mapping. 2) appnCosNameTable This table represents the tranmission priority for each class of service. Clouston & Moore Standards Track [Page 9] RFC 2455 APPN MIB November 1998 3) appnCosNodeRowTable This table represents the node-row information for each class of service, including the weight of each node. 3) appnCosTGRowTable This table represents the TG-row information for each class of service, including the weight of each TG. 3.2.6. appnSessIntermediate group The appnSessIntermediate group consists of the following objects and tables: 1) appnIsInGlobal These objects allow control of the collection of intermediate session information such as Route Selection Control Vectors (RSCVs) and counters. 2) appnIsInTable This table contains information on active intermediate sessions. 3) appnIsRtpTable This table contains information on active intermediate sessions that are being transported on Rapid Transport Protocol (RTP) connections by High Performance Routing (HPR). 3.2.7. appnTraps One APPN trap is defined. It is intended to correspond to SNA/MS Alerts, but is optional for a product to implement this trap. The trap identifies the Alert ID number and, where possible, the affected resource. 4. Definitions APPN-MIB DEFINITIONS ::= BEGIN IMPORTS IANAifType FROM IANAifType-MIB DisplayString, VariablePointer, RowPointer, DateAndTime, Clouston & Moore Standards Track [Page 10] RFC 2455 APPN MIB November 1998 TruthValue, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC Counter32, Gauge32, Unsigned32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF snanauMIB FROM SNA-NAU-MIB; appnMIB MODULE-IDENTITY LAST-UPDATED "9807151800Z" -- July 15, 1998 ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG" CONTACT-INFO " Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Tel: 1 919 472 2333 E-mail: clouston@cisco.com Bob Moore IBM Corporation 4205 S. Miami Boulevard BRQA/501 P.O. Box 12195 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@us.ibm.com " DESCRIPTION "This is the MIB module for objects used to manage network devices with APPN capabilities." -- Revision tracking starts with Proposed Standard (RFC 2155) REVISION "9807151800Z" DESCRIPTION "Minor editorial fixes; new value 'none(5)' added to the enumeration for the appnLocalTgBranchLinkType object." Clouston & Moore Standards Track [Page 11] RFC 2455 APPN MIB November 1998 REVISION "9805261800Z" DESCRIPTION "Post-RFC 2155 conformance definitions added, appnNodeLsCounterType and appnNodeBrNn objects added, appnNodeMibVersion object deprecated." REVISION "9707311800Z" DESCRIPTION "Branch network node (Branch Extender) objects added." REVISION "9703311800Z" DESCRIPTION "MLTG objects added." REVISION "9703201200Z" DESCRIPTION "RFC 2155 (Proposed Standard)" ::= { snanauMIB 4 } -- snanauMIB ::= { mib-2 34 } -- ********************************************************************* -- Textual Conventions -- ********************************************************************* SnaNodeIdentification ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNA Node Identification consists of two parts, which together comprise four bytes of hexadecimal data. In SNA the Node Identification is transported in bytes 2-5 of the XID. The block number is the first three digits of the Node Identification. These 3 hexadecimal digits identify the product. The ID number is the last 5 digits of the Node Identification. These 5 hexadecimal digits are administratively defined and combined with the 3-digit block number form the 8-digit Node Identification. A unique value is required for connections to SNA subarea. In some implementations, the value 'bbb00000' (where 'bbb' represents a 3-digit block number) is returned to mean that the ID number is not unique on this node. An SNA Node Identification is represented as eight ASCII-encoded hexadecimal digits, using the characters '0' - '9' and 'A' - 'F'." SYNTAX OCTET STRING (SIZE (8)) SnaControlPointName ::= TEXTUAL-CONVENTION Clouston & Moore Standards Track [Page 12] RFC 2455 APPN MIB November 1998 STATUS current DESCRIPTION "A fully qualified SNA control point name, consisting of a 1 to 8 character network identifier (NetId), a period ('.'), and a 1 to 8 character control point name (CpName). The NetId and CpName are constructed from the uppercase letters 'A' - 'Z' and the numerics '0' - '9', all encoded in ASCII, with the restriction that the first character of each must be a letter. Trailing blanks are not allowed. Earlier versions of SNA permitted three additional characters in NetIds and CpNames: '#', '@', and '$'. While this use of these characters has been retired, a Management Station should still accept them for backward compatibility." SYNTAX OCTET STRING (SIZE (3..17)) SnaClassOfServiceName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNA class-of-service (COS) name, ranging from 1 to 8 ASCII characters. COS names take one of two forms: - a user-defined COS name is constructed from the uppercase letters 'A' - 'Z' and the numerics '0' - '9', with the restriction that the first character of the name must be a letter. - an SNA-defined user-session COS name begins with the character '#', which is followed by up to seven additional characters from the set of uppercase letters and numerics. Trailing blanks are not allowed in either form of COS name. A zero-length string indicates that a COS name is not available." SYNTAX OCTET STRING (SIZE (0..8)) SnaModeName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNA mode name, ranging from 1 to 8 ASCII characters. Mode names take one of two forms: - a user-defined mode name is constructed from the uppercase letters 'A' - 'Z' and the numerics '0' - '9', Clouston & Moore Standards Track [Page 13] RFC 2455 APPN MIB November 1998 with the restriction that the first character of the name must be a letter. - an SNA-defined user-session mode name begins with the character '#', which is followed by up to seven additional characters from the set of uppercase letters and numerics. Trailing blanks are not allowed in either form of mode name, with the single exception of the all-blank mode name, where a string consisting of 8 blanks is returned. A zero-length string indicates that a mode name is not available." SYNTAX OCTET STRING (SIZE (0..8)) SnaSenseData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "To facilitate their display by a Management Station, sense data objects in the MIB are represented as OCTET STRINGS containing eight ASCII characters. Eight '0' characters indicates that no sense data identifying an SNA error condition is available. An SNA sense data is represented as eight hexadecimal digits, using the characters '0' - '9' and 'A' - 'F'." SYNTAX OCTET STRING (SIZE (8)) DisplayableDlcAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "DLC address of a port or link station, represented as an OCTET STRING containing 0 to 64 ASCII characters. A Management Station should use a value of this type only for display. The 'real' DLC address, i.e., the sequence of bytes that flow in the DLC header, is often available in a DLC-specific MIB. The zero-length string indicates that the DLC address in question is not known to the agent." SYNTAX OCTET STRING (SIZE (0..64)) AppnNodeCounter ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 14] RFC 2455 APPN MIB November 1998 "An object providing global statistics for the entire APPN node. A Management Station can detect discontinuities in this counter by monitoring the appnNodeCounterDisconTime object." SYNTAX Counter32 AppnPortCounter ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object providing statistics for an APPN port. A Management Station can detect discontinuities in this counter by monitoring the appnPortCounterDisconTime object." SYNTAX Counter32 AppnLinkStationCounter ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object providing statistics for an APPN link station. A Management Station can detect discontinuities in this counter by monitoring the appnLsCounterDisconTime object." SYNTAX Counter32 AppnTopologyEntryTimeLeft ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Number of days before deletion of this entry from the topology database. Range is 0-15. A value of 0 indicates that the entry is either in the process of being deleted, or is being marked for deletion at the next garbage collection cycle." SYNTAX INTEGER (0..15) AppnTgDlcData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "DLC-specific data related to a connection network transmission group. For other TGs, a zero-length string is returned. Examples of the type of data returned by an object with this syntax include the following: Token-Ring - MAC/SAP X.25 Switched - dial digits X.21 Switched - dial digits Circuit Switch - dial digits Clouston & Moore Standards Track [Page 15] RFC 2455 APPN MIB November 1998 This MIB does not specify formats for these or any other types of DLC-specific data. Formats may, however, be specified in documents related to a particular DLC. The contents of an object with this syntax correspond to the contents of the DLC-specific subfields of cv46, documented in (6)." SYNTAX OCTET STRING (SIZE (0..64)) AppnTgEffectiveCapacity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value representing the effective capacity of a transmission group. This is an administratively assigned value derived from the link bandwidth and maximum load factor. It is encoded in the same way as byte 7 of cv47, and represents a floating-point number in units of 300 bits per second." SYNTAX OCTET STRING (SIZE (1)) AppnTgSecurity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value representing the level of security on a transmission group. A class of service definition includes an indication of the acceptable TG security value(s) for that class of service. The following seven values are defined: nonsecure(1) - (X'01'): none of the values listed below; for example, satellite-connected or located in a nonsecure country publicSwitchedNetwork(32) - (X'20'): public switched network; secure in the sense that there is no predetermined route that traffic will take undergroundCable(64) - (X'40'): underground cable; located in a secure country (as determined by the network administrator) secureConduit(96) - (X'60'): secure conduit, not guarded; for example, pressurized pipe guardedConduit(128) - (X'80'): guarded conduit; protected against physical tapping Clouston & Moore Standards Track [Page 16] RFC 2455 APPN MIB November 1998 encrypted(160) - (X'A0'): link-level encryption is provided guardedRadiation(192) - (X'C0'): guarded conduit containing the transmission medium; protected against physical and radiation tapping" SYNTAX INTEGER { nonsecure(1), -- X'01' publicSwitchedNetwork(32), -- X'20' undergroundCable(64), -- X'40' secureConduit(96), -- X'60' guardedConduit(128), -- X'80' encrypted(160), -- X'A0' guardedRadiation(192) -- X'C0' } AppnTgDelay ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Relative amount of time that it takes for a signal to travel the length of a logical link. This time is represented in microseconds, using the same encoding scheme used in cv47 in a topology update. Some of the more common values, along with their encoded hex values, are: minimum(0), X'00' negligible(384), X'4C' terrestrial(9216), X'71' packet(147456), X'91' long(294912), X'99' maximum(2013265920) X'FF' " SYNTAX OCTET STRING (SIZE (1)) -- ********************************************************************* appnObjects OBJECT IDENTIFIER ::= { appnMIB 1 } -- ********************************************************************* -- ******************** The APPN Node Group **************************** appnNode OBJECT IDENTIFIER ::= { appnObjects 1 } appnGeneralInfoAndCaps OBJECT IDENTIFIER ::= { appnNode 1 } appnNnUniqueInfoAndCaps OBJECT IDENTIFIER ::= { appnNode 2 } appnEnUniqueCaps OBJECT IDENTIFIER ::= { appnNode 3 } appnPortInformation OBJECT IDENTIFIER ::= { appnNode 4 } Clouston & Moore Standards Track [Page 17] RFC 2455 APPN MIB November 1998 appnLinkStationInformation OBJECT IDENTIFIER ::= { appnNode 5 } appnVrnInfo OBJECT IDENTIFIER ::= { appnNode 6 } -- This group provides global information about an APPN network node, -- an APPN end node, an APPN branch network node, or an LEN node. -- APPN General Information -- This section applies to APPN network nodes, end nodes, and branch -- network nodes, as well as to LEN end nodes. appnNodeCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned network name for this node." ::= { appnGeneralInfoAndCaps 1 } -- appnNodeMibVersion OBJECT-TYPE (deprecated: moved to end of module) appnNodeId OBJECT-TYPE SYNTAX SnaNodeIdentification MAX-ACCESS read-only STATUS current DESCRIPTION "This node's Node Identification, which it sends in bytes 2-5 of XID." ::= { appnGeneralInfoAndCaps 3 } appnNodeType OBJECT-TYPE SYNTAX INTEGER { networkNode(1), endNode(2), t21len(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Type of APPN node: networkNode(1) - APPN network node endNode(2) - APPN end node t21len(4) - LEN end node Note: A branch network node SHALL return endNode(2) as the value of this object. A management application Clouston & Moore Standards Track [Page 18] RFC 2455 APPN MIB November 1998 can distinguish between a branch network node and an actual end node by retrieving the appnNodeBrNn object." ::= { appnGeneralInfoAndCaps 4 } appnNodeUpTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "Amount of time (in hundredths of a second) since the APPN node was last reinitialized." ::= { appnGeneralInfoAndCaps 5 } appnNodeParallelTg OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node supports parallel TGs." ::= { appnGeneralInfoAndCaps 6 } appnNodeAdaptiveBindPacing OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node supports adaptive bind pacing for dependent LUs." ::= { appnGeneralInfoAndCaps 7 } appnNodeHprSupport OBJECT-TYPE SYNTAX INTEGER { noHprSupport(1), hprBaseOnly(2), rtpTower(3), controlFlowsOverRtpTower(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates this node's level of support for high-performance routing (HPR): Clouston & Moore Standards Track [Page 19] RFC 2455 APPN MIB November 1998 noHprSupport(1) - no HPR support hprBaseOnly(2) - HPR base (option set 1400) supported rtpTower(3) - HPR base and RTP tower (option set 1401) supported controlFlowsOverRtpTower(4) - HPR base, RTP tower, and control flows over RTP (option set 1402) supported This object corresponds to cv4580, byte 9, bits 3-4." ::= { appnGeneralInfoAndCaps 8 } appnNodeMaxSessPerRtpConn OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents a configuration parameter indicating the maximum number of sessions that the APPN node is to put on any HPR connection. The value is zero if not applicable." ::= { appnGeneralInfoAndCaps 9 } appnNodeHprIntRteSetups OBJECT-TYPE SYNTAX AppnNodeCounter MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of HPR route setups received for routes passing through this node since the node was last reinitialized." ::= { appnGeneralInfoAndCaps 10 } appnNodeHprIntRteRejects OBJECT-TYPE SYNTAX AppnNodeCounter MAX-ACCESS read-only STATUS current DESCRIPTION "The number of HPR route setups rejected by this node for routes passing through it since the node was last reinitialized." ::= { appnGeneralInfoAndCaps 11 } appnNodeHprOrgRteSetups OBJECT-TYPE SYNTAX AppnNodeCounter Clouston & Moore Standards Track [Page 20] RFC 2455 APPN MIB November 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of HPR route setups sent for routes originating in this node since the node was last reinitialized." ::= { appnGeneralInfoAndCaps 12 } appnNodeHprOrgRteRejects OBJECT-TYPE SYNTAX AppnNodeCounter MAX-ACCESS read-only STATUS current DESCRIPTION "The number of HPR route setups rejected by other nodes for routes originating in this node since the node was last reinitialized." ::= { appnGeneralInfoAndCaps 13 } appnNodeHprEndRteSetups OBJECT-TYPE SYNTAX AppnNodeCounter MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of HPR route setups received for routes ending in this node since the node was last reinitialized." ::= { appnGeneralInfoAndCaps 14 } appnNodeHprEndRteRejects OBJECT-TYPE SYNTAX AppnNodeCounter MAX-ACCESS read-only STATUS current DESCRIPTION "The number of HPR route setups rejected by this node for routes ending in it since the node was last reinitialized." ::= { appnGeneralInfoAndCaps 15 } appnNodeCounterDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object the last time the APPN node was reinitialized." Clouston & Moore Standards Track [Page 21] RFC 2455 APPN MIB November 1998 ::= { appnGeneralInfoAndCaps 16 } appnNodeLsCounterType OBJECT-TYPE SYNTAX INTEGER { other(1), noAnr(2), anrForLocalNces(3), allAnr(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates which ANR traffic, if any, the node includes in the counts returned by the APPN link station counters appnLsInXidBytes, appnLsInMsgBytes, appnLsInXidFrames, appnLsInMsgFrames, appnLsOutXidBytes, appnLsOutMsgBytes, appnLsOutXidFrames, and appnLsOutMsgFrames. These counters are always incremented for ISR traffic. The following values are defined: other(1) - the node does something different from all the options listed below noAnr(2) - the node does not include any ANR traffic in these counts anrForLocalNces(3) - the node includes in these counts ANR traffic for RTP connections that terminate in this node, but not ANR traffic for RTP connections that pass through this node without terminating in it allAnr(4) - the node includes all ANR traffic in these counts." ::= { appnGeneralInfoAndCaps 17 } appnNodeBrNn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node is currently configured as a branch network node. Note: throughout the remainder of this MIB module, branch network node is treated as a third node type, parallel to network node and end node. This is not how branch network nodes are treated in the base APPN architecture, but it Clouston & Moore Standards Track [Page 22] RFC 2455 APPN MIB November 1998 increases clarity to do it here." ::= { appnGeneralInfoAndCaps 18 } -- ********************************************************************* -- APPN Network Node Information -- This section provides global information about an APPN network node. -- ********************************************************************* appnNodeNnCentralDirectory OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node supports central directory services. This object corresponds to cv4580, byte 8, bit 1." ::= { appnNnUniqueInfoAndCaps 1 } appnNodeNnTreeCache OBJECT-TYPE SYNTAX INTEGER { noCache(1), cacheNoIncrUpdate(2), cacheWithIncrUpdate(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates this node's level of support for caching of route trees. Three levels are specified: noCache(1) - caching of route trees is not supported cacheNoIncrUpdate(2) - caching of route trees is supported, but without incremental updates cacheWithIncrUpdate(3) - caching of route trees with incremental updates is supported" ::= { appnNnUniqueInfoAndCaps 2 } appnNodeNnRouteAddResist OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 23] RFC 2455 APPN MIB November 1998 "Route addition resistance. This administratively assigned value indicates the relative desirability of using this node for intermediate session traffic. The value, which can be any integer 0-255, is used in route computation. The lower the value, the more desirable the node is for intermediate routing. This object corresponds to cv4580, byte 6." ::= { appnNnUniqueInfoAndCaps 3 } appnNodeNnIsr OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node supports intermediate session routing. This object corresponds to cv4580, byte 8, bit 2." ::= { appnNnUniqueInfoAndCaps 4 } appnNodeNnFrsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The last flow-reduction sequence number (FRSN) sent by this node in a topology update to an adjacent network node." ::= { appnNnUniqueInfoAndCaps 5 } appnNodeNnPeriBorderSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node has peripheral border node support. This object corresponds to cv4580, byte 9, bit 0." ::= { appnNnUniqueInfoAndCaps 6 } appnNodeNnInterchangeSup OBJECT-TYPE SYNTAX TruthValue Clouston & Moore Standards Track [Page 24] RFC 2455 APPN MIB November 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node has interchange node support. This object corresponds to cv4580, byte 9, bit 1." ::= { appnNnUniqueInfoAndCaps 7 } appnNodeNnExteBorderSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node has extended border node support. This object corresponds to cv4580, byte 9, bit 2." ::= { appnNnUniqueInfoAndCaps 8 } appnNodeNnSafeStoreFreq OBJECT-TYPE SYNTAX INTEGER (0..32767) UNITS "TDUs" MAX-ACCESS read-write STATUS current DESCRIPTION "The topology safe store frequency. If this number is not zero, then the topology database is saved each time the total number of topology database updates (TDUs) received by this node increases by this number. A value of zero indicates that the topology database is not being saved." ::= { appnNnUniqueInfoAndCaps 9 } appnNodeNnRsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Resource sequence number for this node, which it assigns and controls. This object corresponds to the numeric value in cv4580, bytes 2-5." ::= { appnNnUniqueInfoAndCaps 10 } Clouston & Moore Standards Track [Page 25] RFC 2455 APPN MIB November 1998 appnNodeNnCongested OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node is congested. Other network nodes stop routing traffic to this node while this flag is on. This object corresponds to cv4580, byte 7, bit 0." ::= { appnNnUniqueInfoAndCaps 11 } appnNodeNnIsrDepleted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicate whether intermediated session routing resources are depleted. Other network nodes stop routing traffic through this node while this flag is on. This object corresponds to cv4580, byte 7, bit 1." ::= { appnNnUniqueInfoAndCaps 12 } appnNodeNnQuiescing OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node is quiescing. This object corresponds to cv4580, byte 7, bit 5." ::= { appnNnUniqueInfoAndCaps 13 } appnNodeNnGateway OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node has gateway services support. This object corresponds to cv4580, byte 8, bit 0." ::= { appnNnUniqueInfoAndCaps 14 } -- ********************************************************************* Clouston & Moore Standards Track [Page 26] RFC 2455 APPN MIB November 1998 -- APPN End Node Information -- This section provides global information about an APPN end node. Two -- of the objects are also implemented by a branch network node. -- ********************************************************************* appnNodeEnModeCosMap OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this end node supports mode name to COS name mapping." ::= { appnEnUniqueCaps 1 } appnNodeEnNnServer OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The fully qualified name of the current NN server for this end node. An NN server is identified using the format specified in the SnaControlPointName textual convention. The value is a zero-length string when there is no active NN server. A branch network node shall also implement this object." ::= { appnEnUniqueCaps 2 } appnNodeEnLuSearch OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node is to be searched for LUs as part of a network broadcast search. A branch network node shall also implement this object." ::= { appnEnUniqueCaps 3 } -- ********************************************************************* -- APPN Port information -- This section provides information about an APPN node's ports. -- ********************************************************************* Clouston & Moore Standards Track [Page 27] RFC 2455 APPN MIB November 1998 appnPortTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Port table describes the configuration and current status of the ports used by APPN. When it is known to the APPN component, an OBJECT IDENTIFIER pointing to additional information related to the port is included. This may, but need not, be a RowPointer to an ifTable entry for a DLC interface immediately 'below' the port." ::= { appnPortInformation 1 } appnPortEntry OBJECT-TYPE SYNTAX AppnPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The port name is used as the index to this table." INDEX { appnPortName } ::= { appnPortTable 1 } AppnPortEntry ::= SEQUENCE { appnPortName DisplayString, appnPortCommand INTEGER, appnPortOperState INTEGER, appnPortDlcType IANAifType, appnPortPortType INTEGER, appnPortSIMRIM TruthValue, appnPortLsRole INTEGER, appnPortNegotLs TruthValue, appnPortDynamicLinkSupport TruthValue, appnPortMaxRcvBtuSize INTEGER, appnPortMaxIframeWindow Gauge32, appnPortDefLsGoodXids AppnPortCounter, appnPortDefLsBadXids AppnPortCounter, appnPortDynLsGoodXids AppnPortCounter, appnPortDynLsBadXids AppnPortCounter, appnPortSpecific RowPointer, appnPortDlcLocalAddr DisplayableDlcAddress, appnPortCounterDisconTime TimeStamp } appnPortName OBJECT-TYPE Clouston & Moore Standards Track [Page 28] RFC 2455 APPN MIB November 1998 SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for this APPN port." ::= { appnPortEntry 1 } appnPortCommand OBJECT-TYPE SYNTAX INTEGER { deactivate(1), activate(2), recycle(3), ready(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Object by which a Management Station can activate, deactivate, or recycle (i.e., cause to be deactivated and then immediately activated) a port, by setting the value to activate(1), deactivate(2), or recycle(3), respectively. The value ready(4) is returned on GET operations until a SET has been processed; after that the value received on the most recent SET is returned." ::= { appnPortEntry 2 } appnPortOperState OBJECT-TYPE SYNTAX INTEGER { inactive(1), pendactive(2), active(3), pendinact(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state of this port: inactive(1) - port is inactive pendactive(2) - port is pending active active(3) - port is active pendinact(4) - port is pending inactive" ::= { appnPortEntry 3 } Clouston & Moore Standards Track [Page 29] RFC 2455 APPN MIB November 1998 appnPortDlcType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of DLC interface, distinguished according to the protocol immediately 'below' this layer." ::= { appnPortEntry 4 } appnPortPortType OBJECT-TYPE SYNTAX INTEGER { leased(1), switched(2), sharedAccessFacilities(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the type of line used by this port: leased(1) - leased line switched(2) - switched line sharedAccessFacilities(3) - shared access facility, such as a LAN." ::= { appnPortEntry 5 } appnPortSIMRIM OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether Set Initialization Mode (SIM) and Receive Initialization Mode (RIM) are supported for this port." ::= { appnPortEntry 6 } appnPortLsRole OBJECT-TYPE SYNTAX INTEGER { primary(1), secondary(2), negotiable(3), abm(4) } MAX-ACCESS read-only STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 30] RFC 2455 APPN MIB November 1998 "Initial role for link stations activated through this port. The values map to the following settings in the initial XID, where 'ABM' indicates asynchronous balanced mode and 'NRM' indicated normal response mode: primary(1): ABM support = 0 ( = NRM) role = 01 ( = primary) secondary(2): ABM support = 0 ( = NRM) role = 00 ( = secondary) negotiable(3): ABM support = 0 ( = NRM) role = 11 ( = negotiable) abm(4): ABM support = 1 ( = ABM) role = 11 ( = negotiable)" ::= { appnPortEntry 7 } appnPortNegotLs OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node supports negotiable link stations for this port." ::= { appnPortEntry 8 } appnPortDynamicLinkSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node allows call-in on this port from nodes not defined locally." ::= { appnPortEntry 9 } appnPortMaxRcvBtuSize OBJECT-TYPE SYNTAX INTEGER (99..32767) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Basic Transmission Unit (BTU) size that a link station on this port can receive. This object corresponds to bytes 21-22 of XID3." ::= { appnPortEntry 10 } Clouston & Moore Standards Track [Page 31] RFC 2455 APPN MIB November 1998 appnPortMaxIframeWindow OBJECT-TYPE SYNTAX Gauge32 UNITS "I-frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum number of I-frames that can be received by the XID sender before an acknowledgement is received." ::= { appnPortEntry 11 } appnPortDefLsGoodXids OBJECT-TYPE SYNTAX AppnPortCounter UNITS "XID exchanges" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of successful XID exchanges that have occurred on all defined link stations on this port since the last time this port was started." ::= { appnPortEntry 12 } appnPortDefLsBadXids OBJECT-TYPE SYNTAX AppnPortCounter UNITS "XID exchanges" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of unsuccessful XID exchanges that have occurred on all defined link stations on this port since the last time this port was started." ::= { appnPortEntry 13 } appnPortDynLsGoodXids OBJECT-TYPE SYNTAX AppnPortCounter UNITS "XID exchanges" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of successful XID exchanges that have occurred on all dynamic link stations on this port since the last time this port was started." ::= { appnPortEntry 14 } appnPortDynLsBadXids OBJECT-TYPE Clouston & Moore Standards Track [Page 32] RFC 2455 APPN MIB November 1998 SYNTAX AppnPortCounter UNITS "XID exchanges" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of unsuccessful XID exchanges that have occurred on all dynamic link stations on this port since the last time this port was started." ::= { appnPortEntry 15 } appnPortSpecific OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the object, e.g., one in a DLC-specific MIB, that can provide additional information related to this port. If the agent is unable to identify such an object, the value 0.0 is returned." ::= { appnPortEntry 16 } appnPortDlcLocalAddr OBJECT-TYPE SYNTAX DisplayableDlcAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Local DLC address of this port." ::= { appnPortEntry 17 } appnPortCounterDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object the last time the port was started." ::= { appnPortEntry 18 } -- ********************************************************************* -- APPN Link Station Information -- This section provides information about an APPN node's link stations. -- ********************************************************************* Clouston & Moore Standards Track [Page 33] RFC 2455 APPN MIB November 1998 appnLsTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains detailed information about the link station configuration and its current status." ::= { appnLinkStationInformation 1 } appnLsEntry OBJECT-TYPE SYNTAX AppnLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the link station name." INDEX { appnLsName } ::= { appnLsTable 1 } AppnLsEntry ::= SEQUENCE { appnLsName DisplayString, appnLsCommand INTEGER, appnLsOperState INTEGER, appnLsPortName DisplayString, appnLsDlcType IANAifType, appnLsDynamic TruthValue, appnLsAdjCpName OCTET STRING, appnLsAdjNodeType INTEGER, appnLsTgNum INTEGER, appnLsLimResource TruthValue, appnLsActOnDemand TruthValue, appnLsMigration TruthValue, appnLsPartnerNodeId SnaNodeIdentification, appnLsCpCpSessionSupport TruthValue, appnLsMaxSendBtuSize INTEGER, -- performance data appnLsInXidBytes AppnLinkStationCounter, appnLsInMsgBytes AppnLinkStationCounter, appnLsInXidFrames AppnLinkStationCounter, appnLsInMsgFrames AppnLinkStationCounter, appnLsOutXidBytes AppnLinkStationCounter, appnLsOutMsgBytes AppnLinkStationCounter, Clouston & Moore Standards Track [Page 34] RFC 2455 APPN MIB November 1998 appnLsOutXidFrames AppnLinkStationCounter, appnLsOutMsgFrames AppnLinkStationCounter, -- propagation delay appnLsEchoRsps AppnLinkStationCounter, appnLsCurrentDelay Gauge32, appnLsMaxDelay Gauge32, appnLsMinDelay Gauge32, appnLsMaxDelayTime DateAndTime, -- XID Statistics appnLsGoodXids AppnLinkStationCounter, appnLsBadXids AppnLinkStationCounter, -- DLC-specific appnLsSpecific RowPointer, appnLsActiveTime Unsigned32, appnLsCurrentStateTime TimeTicks, -- HPR-specific appnLsHprSup INTEGER, appnLsErrRecoSup TruthValue, appnLsForAnrLabel OCTET STRING, appnLsRevAnrLabel OCTET STRING, appnLsCpCpNceId OCTET STRING, appnLsRouteNceId OCTET STRING, appnLsBfNceId OCTET STRING, appnLsLocalAddr DisplayableDlcAddress, appnLsRemoteAddr DisplayableDlcAddress, appnLsRemoteLsName DisplayString, appnLsCounterDisconTime TimeStamp, appnLsMltgMember TruthValue } appnLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for the link station. The name can be from one to ten characters." ::= { appnLsEntry 1 } appnLsCommand OBJECT-TYPE SYNTAX INTEGER { deactivate(1), activate(2), recycle(3), ready(4) } Clouston & Moore Standards Track [Page 35] RFC 2455 APPN MIB November 1998 MAX-ACCESS read-write STATUS current DESCRIPTION "Object by which a Management Station can activate, deactivate, or recycle (i.e., cause to be deactivated and then immediately reactivated) a link station, by setting the value to activate(1), deactivate(2), or recycle(3), respectively. The value ready(4) is returned on GET operations until a SET has been processed; after that the value received on the most recent SET is returned." ::= { appnLsEntry 2 } appnLsOperState OBJECT-TYPE SYNTAX INTEGER { inactive(1), sentConnectOut(2), -- pending active pendXidExch(3), -- pending active sendActAs(4), -- pending active sendSetMode(5), -- pending active otherPendingActive(6),-- pending active active(7), sentDeactAsOrd(8), -- pending inactive sentDiscOrd(9), -- pending inactive sentDiscImmed(10), -- pending inactive otherPendingInact(11) -- pending inactive } MAX-ACCESS read-only STATUS current DESCRIPTION "State of this link station. The comments map these more granular states to the 'traditional' four states for SNA resources. Values (2) through (5) represent the normal progression of states when a link station is being activated. Value (6) represents some other state of a link station in the process of being activated. Values (8) through (10) represent different ways a link station can be deactivated. Value (11) represents some other state of a link station in the process of being deactivated." ::= { appnLsEntry 3 } appnLsPortName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned name for the port associated with Clouston & Moore Standards Track [Page 36] RFC 2455 APPN MIB November 1998 this link station. The name can be from one to ten characters." ::= { appnLsEntry 4 } appnLsDlcType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of DLC interface, distinguished according to the protocol immediately 'below' this layer." ::= { appnLsEntry 5 } appnLsDynamic OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies whether this is a dynamic link station. Dynamic link stations are created when links that have not been locally defined are established by adjacent nodes." ::= { appnLsEntry 6 } appnLsAdjCpName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "Fully qualified name of the adjacent node for this link station. An adjacent node is identified using the format specified in the SnaControlPointName textual convention. The value of this object is determined as follows: 1. If the adjacent node's name was received on XID, it is returned. 2. If the adjacent node's name was not received on XID, but a locally-defined value is available, it is returned. 3. Otherwise a string of length 0 is returned, indicating that no name is known for the adjacent node." ::= { appnLsEntry 7 } Clouston & Moore Standards Track [Page 37] RFC 2455 APPN MIB November 1998 appnLsAdjNodeType OBJECT-TYPE SYNTAX INTEGER { networkNode(1), endNode(2), t21len(4), unknown(255) } MAX-ACCESS read-only STATUS current DESCRIPTION "Node type of the adjacent node on this link: networkNode(1) - APPN network node endNode(2) - APPN end node t21len(4) - LEN end node unknown(255) - the agent does not know the node type of the adjacent node " ::= { appnLsEntry 8 } appnLsTgNum OBJECT-TYPE SYNTAX INTEGER (0..256) MAX-ACCESS read-only STATUS current DESCRIPTION "Number associated with the TG to this link station, with a range from 0 to 256. A value of 256 indicates that the TG number has not been negotiated and is unknown at this time." ::= { appnLsEntry 9 } appnLsLimResource OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the link station is a limited resource. A link station that is a limited resource is deactivated when it is no longer in use." ::= { appnLsEntry 10 } appnLsActOnDemand OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 38] RFC 2455 APPN MIB November 1998 "Indicates whether the link station is activatable on demand. Such a link station is reported in the topology as active regardless of its actual state, so that it can be considered in route calculations. If the link station is inactive and is chosen for a route, it will be activated at that time." ::= { appnLsEntry 11 } appnLsMigration OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this link station will be used for connections to down-level or migration partners. In general, migration nodes do not append their CP names on XID3. Such nodes: (1) will not support parallel TGs, (2) should be sent an ACTIVATE PHYSICAL UNIT (ACTPU), provided that the partner supports ACTPUs, and (3) should not be sent segmented BINDs. However, if this node receives an XID3 with an appended CP name, then the partner node will not be treated as a migration node. In the case of DYNAMIC TGs this object should be set to 'no'." ::= { appnLsEntry 12 } appnLsPartnerNodeId OBJECT-TYPE SYNTAX SnaNodeIdentification MAX-ACCESS read-only STATUS current DESCRIPTION "The partner's Node Identification, from bytes 2-5 of the XID received from the partner. If this value is not available, then the characters '00000000' are returned." ::= { appnLsEntry 13 } appnLsCpCpSessionSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether CP-CP sessions are supported by this link station. For a dynamic link, this object represents the default ('Admin') value." Clouston & Moore Standards Track [Page 39] RFC 2455 APPN MIB November 1998 ::= { appnLsEntry 14 } appnLsMaxSendBtuSize OBJECT-TYPE SYNTAX INTEGER (99..32767) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Numeric value between 99 and 32767 inclusive indicating the maximum number of bytes in a Basic Transmission Unit (BTU) sent on this link. When the link state (returned by the appnLsOperState object) is inactive or pending active, the value configured at this node is returned. When the link state is active, the value that was negotiated for it is returned. This negotiated value is the smaller of the value configured at this node and the partner's maximum receive BTU length, received in XID." ::= { appnLsEntry 15 } appnLsInXidBytes OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of XID bytes received. All of the bytes in the SNA basic transmission unit (BTU), i.e., all of the bytes in the DLC XID Information Field, are counted." ::= { appnLsEntry 16 } appnLsInMsgBytes OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of message (I-frame) bytes received. All of the bytes in the SNA basic transmission unit (BTU), including the transmission header (TH), are counted." ::= { appnLsEntry 17 } appnLsInXidFrames OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "XID frames" Clouston & Moore Standards Track [Page 40] RFC 2455 APPN MIB November 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of XID frames received." ::= { appnLsEntry 18 } appnLsInMsgFrames OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "I-frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of message (I-frame) frames received." ::= { appnLsEntry 19 } appnLsOutXidBytes OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of XID bytes sent. All of the bytes in the SNA basic transmission unit (BTU), i.e., all of the bytes in the DLC XID Information Field, are counted." ::= { appnLsEntry 20 } appnLsOutMsgBytes OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of message (I-frame) bytes sent. All of the bytes in the SNA basic transmission unit (BTU), including the transmission header (TH), are counted." ::= { appnLsEntry 21 } appnLsOutXidFrames OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "XID frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of XID frames sent." Clouston & Moore Standards Track [Page 41] RFC 2455 APPN MIB November 1998 ::= { appnLsEntry 22 } appnLsOutMsgFrames OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "I-frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of message (I-frame) frames sent." ::= { appnLsEntry 23 } appnLsEchoRsps OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "echo responses" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of echo responses returned from adjacent link station. A response should be returned for each test frame sent by this node. Test frames are sent to adjacent nodes periodically to verify connectivity and to measure the actual round trip time, that is, the time interval from when the test frame is sent until when the response is received." ::= { appnLsEntry 24 } appnLsCurrentDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time that it took for the last test signal to be sent and returned from this link station to the adjacent link station. This time is represented in milliseconds." ::= { appnLsEntry 25 } appnLsMaxDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The longest time it took for a test signal to be sent and returned from this link station to the adjacent link station. Clouston & Moore Standards Track [Page 42] RFC 2455 APPN MIB November 1998 This time is represented in milliseconds . The value 0 is returned if no test signal has been sent and returned." ::= { appnLsEntry 26 } appnLsMinDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The shortest time it took for a test signal to be sent and returned from this link station to the adjacent link station. This time is represented in milliseconds. The value 0 is returned if no test signal has been sent and returned." ::= { appnLsEntry 27 } appnLsMaxDelayTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the longest delay occurred. This time can be used to identify when this high water mark occurred in relation to other events in the APPN node, for example, the time at which an APPC session was either terminated or failed to be established. This latter time is available in the appcHistSessTime object in the APPC MIB. The value 00000000 is returned if no test signal has been sent and returned." ::= { appnLsEntry 28 } appnLsGoodXids OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "XID exchanges" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of successful XID exchanges that have occurred on this link station since the time it was started." Clouston & Moore Standards Track [Page 43] RFC 2455 APPN MIB November 1998 ::= { appnLsEntry 29 } appnLsBadXids OBJECT-TYPE SYNTAX AppnLinkStationCounter UNITS "XID exchanges" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of unsuccessful XID exchanges that have occurred on this link station since the time it was started." ::= { appnLsEntry 30 } appnLsSpecific OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the object, e.g., one in a DLC-specific MIB, that can provide additional information related to this link station. If the agent is unable to identify such an object, the value 0.0 is returned." ::= { appnLsEntry 31 } appnLsActiveTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The cumulative amount of time since the node was last reinitialized, measured in hundredths of a second, that this link station has been in the active state. A zero value indicates that the link station has never been active since the node was last reinitialized." ::= { appnLsEntry 32 } appnLsCurrentStateTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time, measured in hundredths of a second, that Clouston & Moore Standards Track [Page 44] RFC 2455 APPN MIB November 1998 the link station has been in its current state." ::= { appnLsEntry 33 } appnLsHprSup OBJECT-TYPE SYNTAX INTEGER { noHprSupport(1), hprBaseOnly(2), rtpTower(3), controlFlowsOverRtpTower(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the level of high performance routing (HPR) support over this link: noHprSupport(1) - no HPR support hprBaseOnly(2) - HPR base (option set 1400) supported rtpTower(3) - HPR base and RTP tower (option set 1401) supported controlFlowsOverRtpTower(4) - HPR base, RTP tower, and control flows over RTP (option set 1402) supported If the link is not active, the defined value is returned." ::= { appnLsEntry 34 } appnLsErrRecoSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the link station is supporting HPR link-level error recovery." ::= { appnLsEntry 35 } appnLsForAnrLabel OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The forward Automatic Network Routing (ANR) label for this link station. If the link does not support HPR or the value is unknown, a zero-length string is returned." Clouston & Moore Standards Track [Page 45] RFC 2455 APPN MIB November 1998 ::= { appnLsEntry 36 } appnLsRevAnrLabel OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The reverse Automatic Network Routing (ANR) label for this link station. If the link does not support HPR or the value is unknown, a zero-length string is returned." ::= { appnLsEntry 37 } appnLsCpCpNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network connection endpoint identifier (NCE ID) for CP-CP sessions if this node supports the HPR transport tower, a zero-length string if the value is unknown or not meaningful for this node." ::= { appnLsEntry 38 } appnLsRouteNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network connection endpoint identifier (NCE ID) for Route Setup if this node supports the HPR transport tower, a zero- length string if the value is unknown or not meaningful for this node." ::= { appnLsEntry 39 } appnLsBfNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network connection endpoint identifier (NCE ID) for the APPN/HPR boundary function if this node supports the HPR transport tower, a zero-length string if the value is unknown or not meaningful for this node." ::= { appnLsEntry 40 } Clouston & Moore Standards Track [Page 46] RFC 2455 APPN MIB November 1998 appnLsLocalAddr OBJECT-TYPE SYNTAX DisplayableDlcAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Local address of this link station." ::= { appnLsEntry 41 } appnLsRemoteAddr OBJECT-TYPE SYNTAX DisplayableDlcAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Address of the remote link station on this link." ::= { appnLsEntry 42 } appnLsRemoteLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "Remote link station discovered from the XID exchange. The name can be from one to ten characters. A zero-length string indicates that the value is not known." ::= { appnLsEntry 43 } appnLsCounterDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object the last time the link station was started." ::= { appnLsEntry 44 } appnLsMltgMember OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the link is a member of a multi-link TG. If the link's TG has been brought up as a multi-link TG, then the link is reported as a member of a multi-link TG, even if it is Clouston & Moore Standards Track [Page 47] RFC 2455 APPN MIB November 1998 currently the only active link in the TG." ::= { appnLsEntry 45 } --******************************************************************** -- This table provides information about errors this node encountered -- with connections to adjacent nodes. Entries are added for exceptional -- conditions encountered establishing connections, and for exceptional -- conditions that resulted in termination of a connection. It is an -- implementation option when entries are removed from this table. --******************************************************************** appnLsStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnLsStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information related to exceptional and potentially exceptional conditions that occurred during the activation, XID exchange, and termination of a connection. No entries are created when these activities proceed normally. It is an implementation option when entries are removed from this table." ::= { appnLinkStationInformation 2 } appnLsStatusEntry OBJECT-TYPE SYNTAX AppnLsStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the LsStatusIndex, which is an integer that is continuously updated until it eventually wraps." INDEX { appnLsStatusIndex } ::= { appnLsStatusTable 1 } AppnLsStatusEntry ::= SEQUENCE { appnLsStatusIndex INTEGER, appnLsStatusTime DateAndTime, appnLsStatusLsName DisplayString, appnLsStatusCpName DisplayString, Clouston & Moore Standards Track [Page 48] RFC 2455 APPN MIB November 1998 appnLsStatusPartnerId SnaNodeIdentification, appnLsStatusTgNum INTEGER, appnLsStatusGeneralSense SnaSenseData, appnLsStatusRetry TruthValue, appnLsStatusEndSense SnaSenseData, appnLsStatusXidLocalSense SnaSenseData, appnLsStatusXidRemoteSense SnaSenseData, appnLsStatusXidByteInError INTEGER, appnLsStatusXidBitInError INTEGER, appnLsStatusDlcType IANAifType, appnLsStatusLocalAddr DisplayableDlcAddress, appnLsStatusRemoteAddr DisplayableDlcAddress } appnLsStatusIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table index. The value of the index begins at zero and is incremented up to a maximum value of 2**31-1 (2,147,483,647) before wrapping." ::= { appnLsStatusEntry 1 } appnLsStatusTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Time when the exception condition occurred. This time can be used to identify when this event occurred in relation to other events in the APPN node, for example, the time at which an APPC session was either terminated or failed to be established. This latter time is available in the appcHistSessTime object in the APPC MIB." ::= { appnLsStatusEntry 2 } appnLsStatusLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned name for the link station experiencing the condition." Clouston & Moore Standards Track [Page 49] RFC 2455 APPN MIB November 1998 ::= { appnLsStatusEntry 3 } appnLsStatusCpName OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "Fully qualified name of the adjacent node for this link station. An adjacent node is identified using the format specified in the SnaControlPointName textual convention. The value of this object is determined as follows: 1. If the adjacent node's name was received on XID, it is returned. 2. If the adjacent node's name was not received on XID, but a locally-defined value is available, it is returned. 3. Otherwise a string of length 0 is returned, indicating that no name is known for the adjacent node." ::= { appnLsStatusEntry 4 } appnLsStatusPartnerId OBJECT-TYPE SYNTAX SnaNodeIdentification MAX-ACCESS read-only STATUS current DESCRIPTION "The partner's Node Identification, from bytes 2-5 of the XID received from the partner. If this value is not available, then the characters '00000000' are returned." ::= { appnLsStatusEntry 5 } appnLsStatusTgNum OBJECT-TYPE SYNTAX INTEGER (0..256) MAX-ACCESS read-only STATUS current DESCRIPTION "Number associated with the TG to this link station, with a range from 0 to 256. A value of 256 indicates that the TG number was unknown at the time of the failure." ::= { appnLsStatusEntry 6 } appnLsStatusGeneralSense OBJECT-TYPE Clouston & Moore Standards Track [Page 50] RFC 2455 APPN MIB November 1998 SYNTAX SnaSenseData MAX-ACCESS read-only STATUS current DESCRIPTION "The error sense data associated with the start sequence of activation of a link up to the beginning of the XID sequence. This is the sense data that came from Configuration Services whenever the link did not activate or when it went inactive." ::= { appnLsStatusEntry 7 } appnLsStatusRetry OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node will retry the start request to activate the link." ::= { appnLsStatusEntry 8 } appnLsStatusEndSense OBJECT-TYPE SYNTAX SnaSenseData MAX-ACCESS read-only STATUS current DESCRIPTION "The sense data associated with the termination of the link connection to adjacent node. This is the sense data that came from the DLC layer." ::= { appnLsStatusEntry 9 } appnLsStatusXidLocalSense OBJECT-TYPE SYNTAX SnaSenseData MAX-ACCESS read-only STATUS current DESCRIPTION "The sense data associated with the rejection of the XID. This is the sense data that came from the local node (this node) when it built the XID Negotiation Error control vector (cv22) to send to the remote node." ::= { appnLsStatusEntry 10 } appnLsStatusXidRemoteSense OBJECT-TYPE Clouston & Moore Standards Track [Page 51] RFC 2455 APPN MIB November 1998 SYNTAX SnaSenseData MAX-ACCESS read-only STATUS current DESCRIPTION "The sense data the adjacent node returned to this node indicating the reason the XID was rejected. This is the sense data that came from the remote node in the XID Negotiation Error control vector (cv22) it sent to the local node (this node)." ::= { appnLsStatusEntry 11 } appnLsStatusXidByteInError OBJECT-TYPE SYNTAX INTEGER (0..65536) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the actual byte in the XID that caused the error. The value 65536 indicates that the object has no meaning. For values in the range 0-65535, this object corresponds to bytes 2-3 of the XID Negotiation (X'22') control vector." ::= { appnLsStatusEntry 12 } appnLsStatusXidBitInError OBJECT-TYPE SYNTAX INTEGER (0..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the actual bit in error (0 through 7) within the errored byte of the XID. The value 8 indicates that this object has no meaning. For values in the range 0-7, this object corresponds to byte 4 of the XID Negotiation (X'22') control vector." ::= { appnLsStatusEntry 13 } appnLsStatusDlcType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of DLC interface, distinguished according to the protocol immediately 'below' this layer." Clouston & Moore Standards Track [Page 52] RFC 2455 APPN MIB November 1998 ::= { appnLsStatusEntry 14 } appnLsStatusLocalAddr OBJECT-TYPE SYNTAX DisplayableDlcAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Local address of this link station." ::= { appnLsStatusEntry 15 } appnLsStatusRemoteAddr OBJECT-TYPE SYNTAX DisplayableDlcAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Address of the remote link station on this link." ::= { appnLsStatusEntry 16 } -- ********************************************************************* -- APPN Virtual Routing Node Information -- This section provides information relating a virtual routing node to -- an APPN port. -- ********************************************************************* appnVrnTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnVrnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table relates a virtual routing node to an APPN port." ::= { appnVrnInfo 1 } appnVrnEntry OBJECT-TYPE SYNTAX AppnVrnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the virtual routing node name, TG number, and port name. There will be a matching entry in the appnLocalTgTable to represent status and characteristics of the TG representing each virtual routing node definition." INDEX { appnVrnName, appnVrnTgNum, appnVrnPortName } Clouston & Moore Standards Track [Page 53] RFC 2455 APPN MIB November 1998 ::= { appnVrnTable 1 } AppnVrnEntry ::= SEQUENCE { appnVrnName SnaControlPointName, appnVrnTgNum INTEGER, appnVrnPortName DisplayString } appnVrnName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name of the virtual routing node. This is a fully qualified name, and matches the appnLocalTgDest name in the appnLocalTgTable." ::= { appnVrnEntry 1 } appnVrnTgNum OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Number associated with the transmission group representing this virtual routing node definition." ::= { appnVrnEntry 2 } appnVrnPortName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the port this virtual routing node definition is defined to." ::= { appnVrnEntry 3 } -- ************** The APPN Topology Group ****************************** appnNn OBJECT IDENTIFIER ::= { appnObjects 2 } appnNnTopo OBJECT IDENTIFIER ::= { appnNn 1 } appnNnTopology OBJECT IDENTIFIER ::= { appnNn 2 } -- This group is used to represent the entire APPN network-node topology -- including network nodes, virtual routing nodes and all TGs associated -- with these nodes, including intersubnetwork TGs (ISTGs) and branch TGs. Clouston & Moore Standards Track [Page 54] RFC 2455 APPN MIB November 1998 -- -- Network nodes -- The APPN topology database consists of information about every APPN -- network node in this network node's topology subnetwork. This -- information is learned over time as each network node exchanges -- topology information with the network nodes adjacent to it. The -- database consists of information about each node, and information -- about all of the transmission groups used by these nodes. -- -- Virtual routing nodes -- Information about virtual routing nodes (representing connection -- networks) is treated in the same way as information about network -- nodes, and is replicated at each network node. The FRSN, node name, -- and node type are the only meaningful fields for a virtual routing -- node. The other node objects return unspecified values. Each -- node that has defined a TG with this virtual routing node as the -- destination also defines a TG on this virtual routing node. There -- is a TG record for each node that uses this virtual routing node. -- -- The APPN node table represents node information from the APPN topology -- database, with the FRSN and APPN fully qualified CP name serving as -- the index. The FRSN is the agent's relative time stamp of an update -- to the network topology database. After collecting the entire database -- once, a management application can issue GET NEXT commands starting -- from the last rows it has retrieved from the appnNnTopologyFRTable and -- from the appnNnTgTopologyFRTable. When the response to either of these -- GET NEXT commands returns another row of its respective table, this -- indicates a change to the agent's topology database. The management -- application can then retrieve only the updates to the table, using -- GET NEXT commands starting from the last retrieved node or TG entry. -- -- The format of the actual APPN topology database is as follows: -- -- Node table (entry for each node in network) -- TG table (entry for each TG owned by node) -- -- Due to SNMP's ASN.1 limitations, we cannot represent the TG table -- within the node table in this way. We define separate tables for -- nodes and TGs, adding the node name to each TG entry to provide a -- means of correlating the TG with its originating node. appnNnTopoMaxNodes OBJECT-TYPE SYNTAX Gauge32 UNITS "node entries" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum number of node entries allowed in the APPN topology Clouston & Moore Standards Track [Page 55] RFC 2455 APPN MIB November 1998 database. It is an implementation choice whether to count only network-node entries, or to count all node entries. If the number of node entries exceeds this value, APPN will issue an Alert and the node can no longer participate as a network node. The value 0 indicates that the local node has no defined limit, and the number of node entries is bounded only by memory." ::= { appnNnTopo 1 } appnNnTopoCurNumNodes OBJECT-TYPE SYNTAX Gauge32 UNITS "node entries" MAX-ACCESS read-only STATUS current DESCRIPTION "Current number of node entries in this node's topology database. It is an implementation choice whether to count only network-node entries, or to count all node entries, but an implementation must make the same choice here that it makes for the appnNnTopoMaxNodes object. If this value exceeds the maximum number of nodes allowed (appnNnTopoMaxNodes, if that field in not 0), APPN Alert CPDB002 is issued." ::= { appnNnTopo 2 } appnNnTopoNodePurges OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "node entries" MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of topology node records purged from this node's topology database since the node was last reinitialized." ::= { appnNnTopo 3 } appnNnTopoTgPurges OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "TG entries" MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of topology TG records purged from this node's topology database since the node was last reinitialized." ::= { appnNnTopo 4 } appnNnTopoTotalTduWars OBJECT-TYPE Clouston & Moore Standards Track [Page 56] RFC 2455 APPN MIB November 1998 SYNTAX AppnNodeCounter UNITS "TDU wars" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of TDU wars detected by this node since its last initialization." ::= { appnNnTopo 5 } -- APPN network node topology table (using FRSN and name as index) -- This table describes every APPN network node and virtual routing node -- represented in this node's topology database. appnNnTopologyFRTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnNnTopologyFREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Portion of the APPN topology database that describes all of the APPN network nodes and virtual routing nodes known to this node." ::= { appnNnTopology 3 } appnNnTopologyFREntry OBJECT-TYPE SYNTAX AppnNnTopologyFREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FRSN and the fully qualified node name are used to index this table." INDEX {appnNnNodeFRFrsn, appnNnNodeFRName} ::= { appnNnTopologyFRTable 1 } AppnNnTopologyFREntry ::= SEQUENCE { appnNnNodeFRFrsn Unsigned32, appnNnNodeFRName SnaControlPointName, appnNnNodeFREntryTimeLeft AppnTopologyEntryTimeLeft, appnNnNodeFRType INTEGER, Clouston & Moore Standards Track [Page 57] RFC 2455 APPN MIB November 1998 appnNnNodeFRRsn Unsigned32, appnNnNodeFRRouteAddResist INTEGER, appnNnNodeFRCongested TruthValue, appnNnNodeFRIsrDepleted TruthValue, appnNnNodeFRQuiescing TruthValue, appnNnNodeFRGateway TruthValue, appnNnNodeFRCentralDirectory TruthValue, appnNnNodeFRIsr TruthValue, appnNnNodeFRGarbageCollect TruthValue, appnNnNodeFRHprSupport INTEGER, appnNnNodeFRPeriBorderSup TruthValue, appnNnNodeFRInterchangeSup TruthValue, appnNnNodeFRExteBorderSup TruthValue, appnNnNodeFRBranchAwareness TruthValue } appnNnNodeFRFrsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last relative time this resource was updated at the agent node." ::= { appnNnTopologyFREntry 1 } appnNnNodeFRName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned network name that is locally defined at each network node." ::= { appnNnTopologyFREntry 2 } appnNnNodeFREntryTimeLeft OBJECT-TYPE SYNTAX AppnTopologyEntryTimeLeft UNITS "days" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of days before deletion of this network node entry." Clouston & Moore Standards Track [Page 58] RFC 2455 APPN MIB November 1998 ::= { appnNnTopologyFREntry 3 } appnNnNodeFRType OBJECT-TYPE SYNTAX INTEGER { networkNode(1), virtualRoutingNode(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Type of APPN node." ::= { appnNnTopologyFREntry 4 } appnNnNodeFRRsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Resource sequence number, which is assigned and controlled by the network node that owns this resource. An odd number indicates that information about the resource is inconsistent. This object corresponds to the numeric value in cv4580, bytes 2-5." ::= { appnNnTopologyFREntry 5 } appnNnNodeFRRouteAddResist OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Route addition resistance. This administratively assigned value indicates the relative desirability of using this node for intermediate session traffic. The value, which can be any integer 0-255, is used in route computation. The lower the value, the more desirable the node is for intermediate routing. This object corresponds to cv4580, byte 6." ::= { appnNnTopologyFREntry 6 } appnNnNodeFRCongested OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only Clouston & Moore Standards Track [Page 59] RFC 2455 APPN MIB November 1998 STATUS current DESCRIPTION "Indicates whether this node is congested. This node is not be included in route selection by other nodes when this congestion exists. This object corresponds to cv4580, byte 7, bit 0." ::= { appnNnTopologyFREntry 7 } appnNnNodeFRIsrDepleted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether intermediate session routing resources are depleted. This node is not included in intermediate route selection by other nodes when resources are depleted. This object corresponds to cv4580, byte 7, bit 1." ::= { appnNnTopologyFREntry 8 } appnNnNodeFRQuiescing OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node is quiescing. This node is not included in route selection by other nodes when the node is quiescing. This object corresponds to cv4580, byte 7, bit 5." ::= { appnNnTopologyFREntry 9 } appnNnNodeFRGateway OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node provide gateway services. This object corresponds to cv4580, byte 8, bit 0." ::= { appnNnTopologyFREntry 10 } Clouston & Moore Standards Track [Page 60] RFC 2455 APPN MIB November 1998 appnNnNodeFRCentralDirectory OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node supports central directory services. This object corresponds to cv4580, byte 8, bit 1." ::= { appnNnTopologyFREntry 11 } appnNnNodeFRIsr OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node supports intermediate session routing (ISR). This object corresponds to cv4580, byte 8, bit 2." ::= { appnNnTopologyFREntry 12 } appnNnNodeFRGarbageCollect OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the node has been marked for garbage collection (deletion from the topology database) upon the next garbage collection cycle. This object corresponds to cv4580, byte 7, bit 3." ::= { appnNnTopologyFREntry 13 } appnNnNodeFRHprSupport OBJECT-TYPE SYNTAX INTEGER { noHprSupport(1), hprBaseOnly(2), rtpTower(3), controlFlowsOverRtpTower(4) } MAX-ACCESS read-only STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 61] RFC 2455 APPN MIB November 1998 "Indicates the node's level of support for high-performance routing (HPR): noHprSupport(1) - no HPR support hprBaseOnly(2) - HPR base (option set 1400) supported rtpTower(3) - HPR base and RTP tower (option set 1401) supported controlFlowsOverRtpTower(4) - HPR base, RTP tower, and control flows over RTP (option set 1402) supported This object corresponds to cv4580, byte 9, bits 3-4." ::= { appnNnTopologyFREntry 14 } appnNnNodeFRPeriBorderSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node has peripheral border node support. This object corresponds to cv4580, byte 9, bit 0." ::= { appnNnTopologyFREntry 15 } appnNnNodeFRInterchangeSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node has interchange node support. This object corresponds to cv4580, byte 9, bit 1." ::= { appnNnTopologyFREntry 16 } appnNnNodeFRExteBorderSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node has extended border node support. This object corresponds to cv4580, byte 9, bit 2." Clouston & Moore Standards Track [Page 62] RFC 2455 APPN MIB November 1998 ::= { appnNnTopologyFREntry 17 } appnNnNodeFRBranchAwareness OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this node supports branch awareness. This object corresponds to cv4580, byte 8, bit 4." ::= { appnNnTopologyFREntry 18 } --APPN transmission group (TG) table -- This table describes the TGs associated with all the APPN network -- nodes known to this node. The originating (owning) node for each -- TG is repeated here to provide a means of correlating the TGs with -- the nodes. appnNnTgTopologyFRTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnNnTgTopologyFREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Portion of the APPN topology database that describes all of the APPN transmissions groups between nodes in the database." ::= { appnNnTopology 4 } appnNnTgTopologyFREntry OBJECT-TYPE SYNTAX AppnNnTgTopologyFREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by four columns: FRSN, TG owner fully qualified node name, TG destination fully qualified node name, and TG number." INDEX {appnNnTgFRFrsn, appnNnTgFROwner, appnNnTgFRDest, appnNnTgFRNum} ::= { appnNnTgTopologyFRTable 1 } Clouston & Moore Standards Track [Page 63] RFC 2455 APPN MIB November 1998 AppnNnTgTopologyFREntry ::= SEQUENCE { appnNnTgFRFrsn Unsigned32, appnNnTgFROwner SnaControlPointName, appnNnTgFRDest SnaControlPointName, appnNnTgFRNum INTEGER, appnNnTgFREntryTimeLeft AppnTopologyEntryTimeLeft, appnNnTgFRDestVirtual TruthValue, appnNnTgFRDlcData AppnTgDlcData, appnNnTgFRRsn Unsigned32, appnNnTgFROperational TruthValue, appnNnTgFRQuiescing TruthValue, appnNnTgFRCpCpSession INTEGER, appnNnTgFREffCap AppnTgEffectiveCapacity, appnNnTgFRConnCost INTEGER, appnNnTgFRByteCost INTEGER, appnNnTgFRSecurity AppnTgSecurity, appnNnTgFRDelay AppnTgDelay, appnNnTgFRUsr1 INTEGER, appnNnTgFRUsr2 INTEGER, appnNnTgFRUsr3 INTEGER, appnNnTgFRGarbageCollect TruthValue, appnNnTgFRSubareaNum Unsigned32, appnNnTgFRHprSup TruthValue, appnNnTgFRDestHprTrans TruthValue, appnNnTgFRTypeIndicator INTEGER, appnNnTgFRIntersubnet TruthValue, appnNnTgFRMltgLinkType TruthValue, appnNnTgFRBranchTg TruthValue } appnNnTgFRFrsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Flow reduction sequence numbers (FRSNs) are associated with Topology Database Updates (TDUs) and are unique only within each APPN network node. A TDU can be associated with multiple APPN resources. This FRSN indicates the last time this resource was updated at this node." ::= { appnNnTgTopologyFREntry 1 } Clouston & Moore Standards Track [Page 64] RFC 2455 APPN MIB November 1998 appnNnTgFROwner OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for the originating node for this TG. This is the same name specified in the node table." ::= { appnNnTgTopologyFREntry 2 } appnNnTgFRDest OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned fully qualified network name for the destination node for this TG." ::= { appnNnTgTopologyFREntry 3 } appnNnTgFRNum OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Number associated with this transmission group. Range is 0-255." ::= { appnNnTgTopologyFREntry 4 } appnNnTgFREntryTimeLeft OBJECT-TYPE SYNTAX AppnTopologyEntryTimeLeft UNITS "days" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of days before deletion of this network node TG entry if it is not operational or has an odd (inconsistent) RSN." ::= { appnNnTgTopologyFREntry 5 } appnNnTgFRDestVirtual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the destination node is a virtual routing node." Clouston & Moore Standards Track [Page 65] RFC 2455 APPN MIB November 1998 ::= { appnNnTgTopologyFREntry 6 } appnNnTgFRDlcData OBJECT-TYPE SYNTAX AppnTgDlcData MAX-ACCESS read-only STATUS current DESCRIPTION "DLC-specific data related to a link connection network." ::= { appnNnTgTopologyFREntry 7 } appnNnTgFRRsn OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current owning node's resource sequence number for this resource. An odd number indicates that information about the resource is inconsistent. This object corresponds to the numeric value in cv47, bytes 2-5" ::= { appnNnTgTopologyFREntry 8 } appnNnTgFROperational OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is operational. This object corresponds to cv47, byte 6, bit 0." ::= { appnNnTgTopologyFREntry 9 } appnNnTgFRQuiescing OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is quiescing. If the TG owner is either an extended border node or a branch-aware network node (indicated, respectively, by the appnNnNodeFRExteBorderSup and appnNnNodeFRBranchAwareness objects in the corresponding appnNnTopologyFREntry), then this indicator is artificially set to TRUE in the APPN Clouston & Moore Standards Track [Page 66] RFC 2455 APPN MIB November 1998 topology database, to remove the TG from other nodes' route calculations. A management application can determine whether the TG is actually quiescing by examining its appnLocalTgQuiescing object at the TG owner. This object corresponds to cv47, byte 6, bit 2." ::= { appnNnTgTopologyFREntry 10 } appnNnTgFRCpCpSession OBJECT-TYPE SYNTAX INTEGER { supportedUnknownStatus(1), supportedActive(2), notSupported(3), supportedNotActive(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether CP-CP sessions are supported on this TG, and whether the TG owner's contention-winner session is active on this TG. Some nodes in the network are not able to differentiate support and status of CP-CP sessions, and thus may report the 'supportedUnknownStatus' value. This object corresponds to cv47, byte 6, bits 3-4." ::= { appnNnTgTopologyFREntry 11 } appnNnTgFREffCap OBJECT-TYPE SYNTAX AppnTgEffectiveCapacity MAX-ACCESS read-only STATUS current DESCRIPTION "Effective capacity for this TG." ::= { appnNnTgTopologyFREntry 12 } appnNnTgFRConnCost OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Cost per connect time. This is an administratively assigned value representing the relative cost per unit of time to use this TG. Range is from Clouston & Moore Standards Track [Page 67] RFC 2455 APPN MIB November 1998 0, which means no cost, to 255, which indicates maximum cost. This object corresponds to cv47, byte 13." ::= { appnNnTgTopologyFREntry 13 } appnNnTgFRByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Cost per byte transmitted. This is an administratively assigned value representing the relative cost of transmitting a byte over this TG. Range is from 0, which means no cost, to 255, which indicates maximum cost. This object corresponds to cv47, byte 14." ::= { appnNnTgTopologyFREntry 14 } appnNnTgFRSecurity OBJECT-TYPE SYNTAX AppnTgSecurity MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned security level of this TG. This object corresponds to cv47, byte 16." ::= { appnNnTgTopologyFREntry 15 } appnNnTgFRDelay OBJECT-TYPE SYNTAX AppnTgDelay MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned delay associated with this TG. This object corresponds to cv47, byte 17." ::= { appnNnTgTopologyFREntry 16 } appnNnTgFRUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 68] RFC 2455 APPN MIB November 1998 DESCRIPTION "First user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG. This object corresponds to cv47, byte 19." ::= { appnNnTgTopologyFREntry 17 } appnNnTgFRUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Second user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG. This object corresponds to cv47, byte 20." ::= { appnNnTgTopologyFREntry 18 } appnNnTgFRUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Third user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG. This object corresponds to cv47, byte 21." ::= { appnNnTgTopologyFREntry 19 } appnNnTgFRGarbageCollect OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the TG has been marked for garbage collection (deletion from the topology database) upon the next garbage collection cycle. This object corresponds to cv47, byte 6, bit 1." ::= { appnNnTgTopologyFREntry 20 } appnNnTgFRSubareaNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Clouston & Moore Standards Track [Page 69] RFC 2455 APPN MIB November 1998 STATUS current DESCRIPTION "The subarea number associated with this TG. This object corresponds to cv4680, bytes m+2 through m+5." ::= { appnNnTgTopologyFREntry 21 } appnNnTgFRHprSup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether high performance routing (HPR) is supported over this TG. This object corresponds to cv4680, byte m+1, bit 2." ::= { appnNnTgTopologyFREntry 22 } appnNnTgFRDestHprTrans OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the destination node supports high performance routing (HPR) transport tower. This object corresponds to cv4680, byte m+1, bit 7." ::= { appnNnTgTopologyFREntry 23 } appnNnTgFRTypeIndicator OBJECT-TYPE SYNTAX INTEGER { unknown(1), appnOrBfTg(2), interchangeTg(3), virtualRouteTg(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the type of the TG. This object corresponds to cv4680, byte m+1, bits 3-4." ::= { appnNnTgTopologyFREntry 24 } Clouston & Moore Standards Track [Page 70] RFC 2455 APPN MIB November 1998 appnNnTgFRIntersubnet OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is an intersubnet TG, which defines a border between subnetworks. This object corresponds to cv4680, byte m+1, bit 5." ::= { appnNnTgTopologyFREntry 25 } appnNnTgFRMltgLinkType OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the transmission group is a multi-link TG. A TG that has been brought up as a multi-link TG is reported as one, even if it currently has only one link active. This object corresponds to cv47, byte 6, bit 5." ::= { appnNnTgTopologyFREntry 26 } appnNnTgFRBranchTg OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is a branch TG (equivalently, whether the destination of the transmission group is a branch network node). This object corresponds to cv4680, byte m+1, bit 1." ::= { appnNnTgTopologyFREntry 27 } -- ************** The APPN Local Topology Group ************************ -- This MIB Group represents the local topology maintained in -- APPN network nodes, end nodes, and branch network nodes. It consists -- of two tables: -- - a table containing information about all of the TGs owned -- by this node, which is implemented by all node types. -- - a table containing all of the information known to this node -- about the TGs owned by its end nodes, which is implemented only -- by network nodes. Clouston & Moore Standards Track [Page 71] RFC 2455 APPN MIB November 1998 appnLocalTopology OBJECT IDENTIFIER ::= { appnObjects 3 } -- APPN Local Transmission Group (TG) table -- This table describes the TGs associated with this node only. appnLocalTgTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnLocalTgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "TG Table describes all of the TGs owned by this node. The TG destination can be a virtual node, network node, LEN node, or end node." ::= { appnLocalTopology 1 } appnLocalTgEntry OBJECT-TYPE SYNTAX AppnLocalTgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the destination CpName and the TG number." INDEX {appnLocalTgDest, appnLocalTgNum} ::= { appnLocalTgTable 1 } AppnLocalTgEntry ::= SEQUENCE { appnLocalTgDest SnaControlPointName, appnLocalTgNum INTEGER, appnLocalTgDestVirtual TruthValue, appnLocalTgDlcData AppnTgDlcData, appnLocalTgPortName DisplayString, appnLocalTgQuiescing TruthValue, appnLocalTgOperational TruthValue, appnLocalTgCpCpSession INTEGER, appnLocalTgEffCap AppnTgEffectiveCapacity, appnLocalTgConnCost INTEGER, appnLocalTgByteCost INTEGER, appnLocalTgSecurity AppnTgSecurity, appnLocalTgDelay AppnTgDelay, appnLocalTgUsr1 INTEGER, appnLocalTgUsr2 INTEGER, Clouston & Moore Standards Track [Page 72] RFC 2455 APPN MIB November 1998 appnLocalTgUsr3 INTEGER, appnLocalTgHprSup INTEGER, appnLocalTgIntersubnet TruthValue, appnLocalTgMltgLinkType TruthValue, appnLocalTgBranchLinkType INTEGER } appnLocalTgDest OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name of the destination node for this TG. This is the fully qualified name of a network node, end node, LEN node, or virtual routing node." ::= { appnLocalTgEntry 1 } appnLocalTgNum OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Number associated with this transmission group." ::= { appnLocalTgEntry 2 } appnLocalTgDestVirtual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the destination node for this TG is a virtual routing node." ::= { appnLocalTgEntry 3 } appnLocalTgDlcData OBJECT-TYPE SYNTAX AppnTgDlcData MAX-ACCESS read-only STATUS current DESCRIPTION "DLC-specific data related to a link connection network." ::= { appnLocalTgEntry 4 } appnLocalTgPortName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) Clouston & Moore Standards Track [Page 73] RFC 2455 APPN MIB November 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned name for the local port associated with this TG. A zero-length string indicates that this value is unknown." ::= { appnLocalTgEntry 5 } appnLocalTgQuiescing OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is quiescing." ::= { appnLocalTgEntry 6 } appnLocalTgOperational OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is operational." ::= { appnLocalTgEntry 7 } appnLocalTgCpCpSession OBJECT-TYPE SYNTAX INTEGER { supportedUnknownStatus(1), supportedActive(2), notSupported(3), supportedNotActive(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether CP-CP sessions are supported on this TG, and whether the TG owner's contention-winner session is active on this TG. Some nodes in the network are not able to differentiate support and status of CP-CP sessions, and thus may report the 'supportedUnknownStatus' value." ::= { appnLocalTgEntry 8 } appnLocalTgEffCap OBJECT-TYPE SYNTAX AppnTgEffectiveCapacity MAX-ACCESS read-only Clouston & Moore Standards Track [Page 74] RFC 2455 APPN MIB November 1998 STATUS current DESCRIPTION "Effective capacity for this TG." ::= { appnLocalTgEntry 9 } appnLocalTgConnCost OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255." ::= { appnLocalTgEntry 10 } appnLocalTgByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Relative cost of transmitting a byte over this link. Range is from 0 (lowest cost) to 255." ::= { appnLocalTgEntry 11 } appnLocalTgSecurity OBJECT-TYPE SYNTAX AppnTgSecurity MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned security level of this TG." ::= { appnLocalTgEntry 12 } appnLocalTgDelay OBJECT-TYPE SYNTAX AppnTgDelay MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned delay associated with this TG." ::= { appnLocalTgEntry 13 } appnLocalTgUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 75] RFC 2455 APPN MIB November 1998 DESCRIPTION "First user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG." ::= { appnLocalTgEntry 14 } appnLocalTgUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Second user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG." ::= { appnLocalTgEntry 15 } appnLocalTgUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Third user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG." ::= { appnLocalTgEntry 16 } appnLocalTgHprSup OBJECT-TYPE SYNTAX INTEGER { noHprSupport(1), hprBaseOnly(2), rtpTower(3), controlFlowsOverRtpTower(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the level of high performance routing (HPR) support over this TG : noHprSupport(1) - no HPR support hprBaseOnly(2) - HPR base (option set 1400) supported rtpTower(3) - HPR base and RTP tower (option set 1401) supported controlFlowsOverRtpTower(4) - HPR base, RTP tower, and control flows over RTP (option set 1402) supported" Clouston & Moore Standards Track [Page 76] RFC 2455 APPN MIB November 1998 ::= { appnLocalTgEntry 17 } appnLocalTgIntersubnet OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is an intersubnet TG, which defines a border between subnetworks." ::= { appnLocalTgEntry 18 } appnLocalTgMltgLinkType OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the transmission group is a multi-link TG. A TG that has been brought up as a multi-link TG is reported as one, even if it currently has only one link active." ::= { appnLocalTgEntry 19 } appnLocalTgBranchLinkType OBJECT-TYPE SYNTAX INTEGER { other(1), uplink(2), downlink(3), downlinkToBranchNetworkNode(4), none(5), unknown(255) } MAX-ACCESS read-only STATUS current DESCRIPTION "Branch link type of this TG: other(1) = the agent has determined the TG's branch link type to be a value other than branch uplink or branch downlink. This is the value used for a connection network TG owned by a branch network node. uplink(2) = the TG is a branch uplink. downlink(3) = the TG is a branch downlink to an end node. downlinkToBranchNetworkNode(4) = the TG is a branch downlink to a cascaded branch Clouston & Moore Standards Track [Page 77] RFC 2455 APPN MIB November 1998 network node. none(5) = the TG is not a branch TG. unknown(255) = the agent cannot determine the branch link type of the TG." ::= { appnLocalTgEntry 20 } -- APPN Local End Node Transmission Group (TG) table -- This table describes the TGs associated with all of the end nodes -- known to this node. appnLocalEnTgTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnLocalEnTgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table describing all of the TGs owned by the end nodes known to this node via TG registration. This node does not represent its own view of the TG on behalf of the partner node in this table. The TG destination can be a virtual routing node, network node, or end node." ::= { appnLocalTopology 2 } appnLocalEnTgEntry OBJECT-TYPE SYNTAX AppnLocalEnTgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table requires multiple indexes to uniquely identify each TG. They are originating CPname, destination CPname, and the TG number." INDEX {appnLocalEnTgOrigin, appnLocalEnTgDest, appnLocalEnTgNum} ::= { appnLocalEnTgTable 1 } AppnLocalEnTgEntry ::= SEQUENCE { appnLocalEnTgOrigin SnaControlPointName, appnLocalEnTgDest SnaControlPointName, appnLocalEnTgNum INTEGER, appnLocalEnTgEntryTimeLeft AppnTopologyEntryTimeLeft, appnLocalEnTgDestVirtual TruthValue, Clouston & Moore Standards Track [Page 78] RFC 2455 APPN MIB November 1998 appnLocalEnTgDlcData AppnTgDlcData, appnLocalEnTgOperational TruthValue, appnLocalEnTgCpCpSession INTEGER, appnLocalEnTgEffCap AppnTgEffectiveCapacity, appnLocalEnTgConnCost INTEGER, appnLocalEnTgByteCost INTEGER, appnLocalEnTgSecurity AppnTgSecurity, appnLocalEnTgDelay AppnTgDelay, appnLocalEnTgUsr1 INTEGER, appnLocalEnTgUsr2 INTEGER, appnLocalEnTgUsr3 INTEGER, appnLocalEnTgMltgLinkType TruthValue } appnLocalEnTgOrigin OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name of the origin node for this TG. This is a fully qualified network name." ::= { appnLocalEnTgEntry 1 } appnLocalEnTgDest OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name of the destination node for this TG. This is the fully qualified name of a network node, end node, LEN node, or virtual routing node." ::= { appnLocalEnTgEntry 2 } appnLocalEnTgNum OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Number associated with this transmission group." ::= { appnLocalEnTgEntry 3 } appnLocalEnTgEntryTimeLeft OBJECT-TYPE SYNTAX AppnTopologyEntryTimeLeft UNITS "days" Clouston & Moore Standards Track [Page 79] RFC 2455 APPN MIB November 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of days before deletion of this end node TG entry." ::= { appnLocalEnTgEntry 4 } appnLocalEnTgDestVirtual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the destination node is a virtual routing node." ::= { appnLocalEnTgEntry 5 } appnLocalEnTgDlcData OBJECT-TYPE SYNTAX AppnTgDlcData MAX-ACCESS read-only STATUS current DESCRIPTION "DLC-specific data related to a link connection network." ::= { appnLocalEnTgEntry 6 } appnLocalEnTgOperational OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the transmission group is operational." ::= { appnLocalEnTgEntry 7 } appnLocalEnTgCpCpSession OBJECT-TYPE SYNTAX INTEGER { supportedUnknownStatus(1), supportedActive(2), notSupported(3), supportedNotActive(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether CP-CP sessions are supported on this TG, and whether the TG owner's contention-winner session is active on this TG. Some nodes in the network are not able to Clouston & Moore Standards Track [Page 80] RFC 2455 APPN MIB November 1998 differentiate support and status of CP-CP sessions, and thus may report the 'supportedUnknownStatus' value." ::= { appnLocalEnTgEntry 8 } appnLocalEnTgEffCap OBJECT-TYPE SYNTAX AppnTgEffectiveCapacity MAX-ACCESS read-only STATUS current DESCRIPTION "Effective capacity for this TG." ::= { appnLocalEnTgEntry 9 } appnLocalEnTgConnCost OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Cost per connect time: a value representing the relative cost per unit of time to use the TG. Range is from 0, which means no cost, to 255." ::= { appnLocalEnTgEntry 10 } appnLocalEnTgByteCost OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Relative cost of transmitting a byte over this link. Range is from 0, which means no cost, to 255." ::= { appnLocalEnTgEntry 11 } appnLocalEnTgSecurity OBJECT-TYPE SYNTAX AppnTgSecurity MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned security level of this TG." ::= { appnLocalEnTgEntry 12 } appnLocalEnTgDelay OBJECT-TYPE SYNTAX AppnTgDelay MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 81] RFC 2455 APPN MIB November 1998 DESCRIPTION "Administratively assigned delay associated with this TG." ::= { appnLocalEnTgEntry 13 } appnLocalEnTgUsr1 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "First user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG." ::= { appnLocalEnTgEntry 14 } appnLocalEnTgUsr2 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Second user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG." ::= { appnLocalEnTgEntry 15 } appnLocalEnTgUsr3 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Third user-defined TG characteristic for this TG. This is an administratively assigned value associated with the TG." ::= { appnLocalEnTgEntry 16 } appnLocalEnTgMltgLinkType OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the transmission group is a multi-link TG. A TG that has been brought up as a multi-link TG is reported as one, even if it currently has only one link active." ::= { appnLocalEnTgEntry 17 } -- ************** The APPN Directory Group ***************************** Clouston & Moore Standards Track [Page 82] RFC 2455 APPN MIB November 1998 appnDir OBJECT IDENTIFIER ::= { appnObjects 4 } appnDirPerf OBJECT IDENTIFIER ::= { appnDir 1 } -- The APPN Directory Group -- The APPN Directory Database -- Each APPN network node and branch network node maintains directories -- containing information on which LUs (applications) are available and -- where they are located. LUs can be located in an APPN network node, -- in any of its attached end nodes or branch network nodes, or in any -- of the nodes below one of its attached branch network nodes. appnDirMaxCaches OBJECT-TYPE SYNTAX Unsigned32 UNITS "directory entries" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum number of cache entries allowed. This is an administratively assigned value." ::= { appnDirPerf 1 } appnDirCurCaches OBJECT-TYPE SYNTAX Gauge32 UNITS "directory entries" MAX-ACCESS read-only STATUS current DESCRIPTION "Current number of cache entries." ::= { appnDirPerf 2 } appnDirCurHomeEntries OBJECT-TYPE SYNTAX Gauge32 UNITS "directory entries" MAX-ACCESS read-only STATUS current DESCRIPTION "Current number of home entries." ::= { appnDirPerf 3 } appnDirRegEntries OBJECT-TYPE SYNTAX Gauge32 UNITS "directory entries" MAX-ACCESS read-only Clouston & Moore Standards Track [Page 83] RFC 2455 APPN MIB November 1998 STATUS current DESCRIPTION "Current number of registered entries." ::= { appnDirPerf 4 } appnDirInLocates OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "Locate messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of directed Locates received since the node was last reinitialized." ::= { appnDirPerf 5 } appnDirInBcastLocates OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "Locate messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of broadcast Locates received since the node was last reinitialized." ::= { appnDirPerf 6 } appnDirOutLocates OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "Locate messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of directed Locates sent since the node was last reinitialized." ::= { appnDirPerf 7 } appnDirOutBcastLocates OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "Locate messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of broadcast Locates sent since the node was last reinitialized." Clouston & Moore Standards Track [Page 84] RFC 2455 APPN MIB November 1998 ::= { appnDirPerf 8 } appnDirNotFoundLocates OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "Locate messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of directed Locates returned with a 'not found' since the node was last reinitialized." ::= { appnDirPerf 9 } appnDirNotFoundBcastLocates OBJECT-TYPE SYNTAX AppnNodeCounter UNITS "Locate messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of broadcast Locates returned with a 'not found' since the node was last reinitialized." ::= { appnDirPerf 10 } appnDirLocateOutstands OBJECT-TYPE SYNTAX Gauge32 UNITS "Locate messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Current number of outstanding Locates, both directed and broadcast. This value varies. A value of zero indicates that no Locates are unanswered." ::= { appnDirPerf 11 } --APPN Directory table -- This table contains information about all known LUs. appnDirTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing information about all known LUs." Clouston & Moore Standards Track [Page 85] RFC 2455 APPN MIB November 1998 ::= { appnDir 2 } appnDirEntry OBJECT-TYPE SYNTAX AppnDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the LU name." INDEX {appnDirLuName} ::= { appnDirTable 1 } AppnDirEntry ::= SEQUENCE { appnDirLuName DisplayString, appnDirNnServerName SnaControlPointName, appnDirLuOwnerName SnaControlPointName, appnDirLuLocation INTEGER, appnDirType INTEGER, appnDirApparentLuOwnerName DisplayString } appnDirLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..17)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Fully qualified network LU name in the domain of the serving network node. Entries take one of three forms: - Explicit entries do not contain the character '*'. - Partial wildcard entries have the form 'ccc*', where 'ccc' represents one to sixteen characters in a legal SNA LuName. - A full wildcard entry consists of the single character '*'" ::= { appnDirEntry 1 } appnDirNnServerName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Fully qualified control point (CP) name of the network node server. For unassociated end node entries, a zero-length string is returned." Clouston & Moore Standards Track [Page 86] RFC 2455 APPN MIB November 1998 ::= { appnDirEntry 2 } appnDirLuOwnerName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "Fully qualified CP name of the node at which the LU is located. This name is the same as the serving NN name when the LU is located at a network node. It is also the same as the fully qualified LU name when this is the control point LU for this node." ::= { appnDirEntry 3 } appnDirLuLocation OBJECT-TYPE SYNTAX INTEGER { local(1), --Local domain(2), --Domain xdomain(3) --Cross Domain } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the location of the LU with respect to the local node." ::= { appnDirEntry 4 } appnDirType OBJECT-TYPE SYNTAX INTEGER { home(1), --defined as home entry cache(2), --learned over time registered(3) --registered by end node } MAX-ACCESS read-only STATUS current DESCRIPTION "Directory types are: 1 - Home The LU is in the domain of the local node, and the LU information has been configured at the local node. 2 - Cache The LU has previously been located by a broadcast search, and the location information has been saved. Clouston & Moore Standards Track [Page 87] RFC 2455 APPN MIB November 1998 3 - Registered The LU is at an end node that is in the domain of the local network node. Registered entries are registered by the served end node." ::= { appnDirEntry 5 } appnDirApparentLuOwnerName OBJECT-TYPE SYNTAX DisplayString (SIZE (0 | 3..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "Fully qualified CP name of the node at which the LU appears to be located. This object and the appnDirLuOwnerName object are related as follows: Implementations that support this object save in their directory database information about an LU's owning control point that was communicated in two control vectors: - an Associated Resource Entry (X'3C') CV with resource type X'00F4' (ENCP) - a Real Owning Control Point (X'4A') CV. The X'4A' CV is created by a branch network node to preserve the name of the real owning control point for an LU below the branch network node, before it overwrites this name with its own name in the X'3C' CV. The X'4A' CV is not present for LUs that are not below branch network nodes. If the information a node has about an LU's owning CP came only in a X'3C' CV, then the name from the X'3C' is returned in the appnDirLuOwnerName object, and a null string is returned in this object. If the information a node has about an LU's owning CP came in both X'3C' and X'4A' CVs, then the name from the X'4A' is returned in the appnDirLuOwnerName object, and the name from the X'3C' (which will be the branch network node's name) is returned in this object." ::= { appnDirEntry 6 } -- ************** The APPN Class of Service Group ********************** appnCos OBJECT IDENTIFIER ::= { appnObjects 5 } Clouston & Moore Standards Track [Page 88] RFC 2455 APPN MIB November 1998 -- The APPN Class of Service (COS) -- Class of Service is a means of expressing the quality of routes and -- the transmission priority of traffic that flows on these routes. -- The quality of routes is specified by two tables, a COS weight table -- for TGs and a COS weight table for nodes. Values in these COS tables -- are administratively assigned at each APPN node, with seven default -- tables specified by the APPN architecture. -- ********************************************************************* appnCosModeTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnCosModeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table representing all of the defined mode names for this node. The table contains the matching COS name for each mode name." ::= { appnCos 1 } appnCosModeEntry OBJECT-TYPE SYNTAX AppnCosModeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the mode name." INDEX {appnCosModeName} ::= { appnCosModeTable 1 } AppnCosModeEntry ::= SEQUENCE { appnCosModeName SnaModeName, appnCosModeCosName SnaClassOfServiceName } appnCosModeName OBJECT-TYPE SYNTAX SnaModeName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for this mode." ::= { appnCosModeEntry 1 } appnCosModeCosName OBJECT-TYPE Clouston & Moore Standards Track [Page 89] RFC 2455 APPN MIB November 1998 SYNTAX SnaClassOfServiceName MAX-ACCESS read-only STATUS current DESCRIPTION "Administratively assigned name for this class of service." ::= { appnCosModeEntry 2 } -- ********************************************************************* appnCosNameTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnCosNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table mapping all of the defined class-of-service names for this node to their network transmission priorities." ::= { appnCos 2 } appnCosNameEntry OBJECT-TYPE SYNTAX AppnCosNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The COS name is the index to this table." INDEX {appnCosName} ::= { appnCosNameTable 1 } AppnCosNameEntry ::= SEQUENCE { appnCosName SnaClassOfServiceName, appnCosTransPriority INTEGER } appnCosName OBJECT-TYPE SYNTAX SnaClassOfServiceName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for this class of service." ::= { appnCosNameEntry 1 } appnCosTransPriority OBJECT-TYPE Clouston & Moore Standards Track [Page 90] RFC 2455 APPN MIB November 1998 SYNTAX INTEGER { low(1), --X'01' medium(2), --X'02' high(3), --X'03' network(4) --X'04' } MAX-ACCESS read-only STATUS current DESCRIPTION "Transmission priority for this class of service: low(1) - (X'01'): low priority medium(2) - (X'02'): medium priority high(3) - (X'03'): high priority network(4) - (X'04'): network priority" ::= { appnCosNameEntry 2 } -- ********************************************************************* appnCosNodeRowTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnCosNodeRowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all node-row information for all classes of service defined in this node." ::= { appnCos 3 } appnCosNodeRowEntry OBJECT-TYPE SYNTAX AppnCosNodeRowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A node entry for a given class of service." INDEX {appnCosNodeRowName, appnCosNodeRowIndex} ::= { appnCosNodeRowTable 1 } AppnCosNodeRowEntry ::= SEQUENCE { appnCosNodeRowName SnaClassOfServiceName, appnCosNodeRowIndex INTEGER, appnCosNodeRowWgt DisplayString, appnCosNodeRowResistMin INTEGER, Clouston & Moore Standards Track [Page 91] RFC 2455 APPN MIB November 1998 appnCosNodeRowResistMax INTEGER, appnCosNodeRowMinCongestAllow INTEGER, appnCosNodeRowMaxCongestAllow INTEGER } appnCosNodeRowName OBJECT-TYPE SYNTAX SnaClassOfServiceName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for this class of service." ::= { appnCosNodeRowEntry 1 } appnCosNodeRowIndex OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Subindex under appnCosNodeRowName, corresponding to a row in the node table for the class of service identified in appnCosNodeRowName. For each class of service, this subindex orders rows in the appnCosNodeRowTable in the same order as that used for route calculation in the APPN node." ::= { appnCosNodeRowEntry 2 } appnCosNodeRowWgt OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "Weight to be associated with the nodes that fit the criteria specified by this node row. This value can either be a character representation of an integer, or a formula for calculating the weight." ::= { appnCosNodeRowEntry 3 } appnCosNodeRowResistMin OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum route addition resistance value for this node. Clouston & Moore Standards Track [Page 92] RFC 2455 APPN MIB November 1998 Range of values is 0-255. The lower the value, the more desirable the node is for intermediate routing." ::= { appnCosNodeRowEntry 4 } appnCosNodeRowResistMax OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum route addition resistance value for this node. Range of values is 0-255. The lower the value, the more desirable the node is for intermediate routing." ::= { appnCosNodeRowEntry 5 } appnCosNodeRowMinCongestAllow OBJECT-TYPE SYNTAX INTEGER (0..1) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether low congestion will be tolerated. This object and appnCosNodeRowMaxCongestAllow together delineate a range of acceptable congestion states for a node. For the ordered pair (minimum congestion allowed, maximum congestion allowed), the values are interpreted as follows: - (0,0): only low congestion is acceptable - (0,1): either low or high congestion is acceptable - (1,1): only high congestion is acceptable. Note that the combination (1,0) is not defined, since it would identify a range whose lower bound was high congestion and whose upper bound was low congestion." ::= { appnCosNodeRowEntry 6 } appnCosNodeRowMaxCongestAllow OBJECT-TYPE SYNTAX INTEGER (0..1) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether low congestion will be tolerated. This object and appnCosNodeRowMinCongestAllow together delineate a range of acceptable congestion states for a node. For the ordered pair (minimum congestion allowed, maximum congestion allowed), the values are interpreted as follows: Clouston & Moore Standards Track [Page 93] RFC 2455 APPN MIB November 1998 - (0,0): only low congestion is acceptable - (0,1): either low or high congestion is acceptable - (1,1): only high congestion is acceptable. Note that the combination (1,0) is not defined, since it would identify a range whose lower bound was high congestion and whose upper bound was low congestion." ::= { appnCosNodeRowEntry 7 } -- ********************************************************************* appnCosTgRowTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnCosTgRowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing all the TG-row information for all classes of service defined in this node." ::= { appnCos 4 } appnCosTgRowEntry OBJECT-TYPE SYNTAX AppnCosTgRowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TG entry for a given class of service." INDEX {appnCosTgRowName, appnCosTgRowIndex} ::= { appnCosTgRowTable 1 } AppnCosTgRowEntry ::= SEQUENCE { appnCosTgRowName SnaClassOfServiceName, appnCosTgRowIndex INTEGER, appnCosTgRowWgt DisplayString, appnCosTgRowEffCapMin AppnTgEffectiveCapacity, appnCosTgRowEffCapMax AppnTgEffectiveCapacity, appnCosTgRowConnCostMin INTEGER, appnCosTgRowConnCostMax INTEGER, appnCosTgRowByteCostMin INTEGER, appnCosTgRowByteCostMax INTEGER, appnCosTgRowSecurityMin AppnTgSecurity, appnCosTgRowSecurityMax AppnTgSecurity, appnCosTgRowDelayMin AppnTgDelay, Clouston & Moore Standards Track [Page 94] RFC 2455 APPN MIB November 1998 appnCosTgRowDelayMax AppnTgDelay, appnCosTgRowUsr1Min INTEGER, appnCosTgRowUsr1Max INTEGER, appnCosTgRowUsr2Min INTEGER, appnCosTgRowUsr2Max INTEGER, appnCosTgRowUsr3Min INTEGER, appnCosTgRowUsr3Max INTEGER } appnCosTgRowName OBJECT-TYPE SYNTAX SnaClassOfServiceName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for this class of service." ::= { appnCosTgRowEntry 1 } appnCosTgRowIndex OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Subindex under appnCosTgRowName, corresponding to a row in the TG table for the class of service identified in appnCosTgRowName. For each class of service, this subindex orders rows in the appnCosTgRowTable in the same order as that used for route calculation in the APPN node." ::= { appnCosTgRowEntry 2 } appnCosTgRowWgt OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "Weight to be associated with the TGs that fit the criteria specified by this TG row. This value can either be a character representation of an integer, or a formula for calculating the weight." ::= { appnCosTgRowEntry 3 } appnCosTgRowEffCapMin OBJECT-TYPE SYNTAX AppnTgEffectiveCapacity Clouston & Moore Standards Track [Page 95] RFC 2455 APPN MIB November 1998 MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum acceptable capacity for this class of service." ::= { appnCosTgRowEntry 4 } appnCosTgRowEffCapMax OBJECT-TYPE SYNTAX AppnTgEffectiveCapacity MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum acceptable capacity for this class of service." ::= { appnCosTgRowEntry 5 } appnCosTgRowConnCostMin OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum acceptable cost per connect time for this class of service. Cost per connect time: a value representing the relative cost per unit of time to use this TG. Range is from 0, which means no cost, to 255." ::= { appnCosTgRowEntry 6 } appnCosTgRowConnCostMax OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum acceptable cost per connect time for this class of service. Cost per connect time: a value representing the relative cost per unit of time to use this TG. Range is from 0, which means no cost, to 255." ::= { appnCosTgRowEntry 7 } appnCosTgRowByteCostMin OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 96] RFC 2455 APPN MIB November 1998 DESCRIPTION "Minimum acceptable cost per byte transmitted for this class of service. Cost per byte transmitted: a value representing the relative cost per unit of time to use this TG. Range is from 0, which means no cost, to 255." ::= { appnCosTgRowEntry 8 } appnCosTgRowByteCostMax OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum acceptable cost per byte transmitted for this class of service. Cost per byte transmitted: a value representing the relative cost of transmitting a byte over this TG. Range is from 0, which means no cost, to 255." ::= { appnCosTgRowEntry 9 } appnCosTgRowSecurityMin OBJECT-TYPE SYNTAX AppnTgSecurity MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum acceptable security for this class of service." ::= { appnCosTgRowEntry 10 } appnCosTgRowSecurityMax OBJECT-TYPE SYNTAX AppnTgSecurity MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum acceptable security for this class of service." ::= { appnCosTgRowEntry 11 } appnCosTgRowDelayMin OBJECT-TYPE SYNTAX AppnTgDelay MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum acceptable propagation delay for this class of Clouston & Moore Standards Track [Page 97] RFC 2455 APPN MIB November 1998 service." ::= { appnCosTgRowEntry 12 } appnCosTgRowDelayMax OBJECT-TYPE SYNTAX AppnTgDelay MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum acceptable propagation delay for this class of service." ::= { appnCosTgRowEntry 13 } appnCosTgRowUsr1Min OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum acceptable value for this user-defined characteristic." ::= { appnCosTgRowEntry 14 } appnCosTgRowUsr1Max OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum acceptable value for this user-defined characteristic." ::= { appnCosTgRowEntry 15 } appnCosTgRowUsr2Min OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum acceptable value for this user-defined characteristic." ::= { appnCosTgRowEntry 16 } appnCosTgRowUsr2Max OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 98] RFC 2455 APPN MIB November 1998 DESCRIPTION "Maximum acceptable value for this user-defined characteristic." ::= { appnCosTgRowEntry 17 } appnCosTgRowUsr3Min OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum acceptable value for this user-defined characteristic." ::= { appnCosTgRowEntry 18 } appnCosTgRowUsr3Max OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum acceptable value for this user-defined characteristic." ::= { appnCosTgRowEntry 19 } -- ********************************************************************* -- Intermediate Session Information -- ********************************************************************* appnSessIntermediate OBJECT IDENTIFIER ::= { appnObjects 6 } -- ********************************************************************* -- Intermediate Session Information Global Objects -- ********************************************************************* -- The following simple objects allow the collection of intermediate -- session Information to be started and stopped. -- ********************************************************************* appnIsInGlobal OBJECT IDENTIFIER ::= { appnSessIntermediate 1 } appnIsInGlobeCtrAdminStatus OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2), ready(3) } MAX-ACCESS read-write STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 99] RFC 2455 APPN MIB November 1998 "Object by which a Management Station can deactivate or activate capture of intermediate-session counts and names, by setting the value to notActive(1) or active(2), respectively. The value ready(3) is returned on GET operations until a SET has been processed; after that the value received on the most recent SET is returned. The counts referred to here are the eight objects in the AppnIsInTable, from appnIsInP2SFmdPius through appnIsInS2PNonFmdBytes. The names are the four objects in this table, from appnIsInPriLuName through appnIsInCosName. Setting this object to the following values has the following effects: notActive(1) stop collecting count data. If a count is queried, it returns the value 0. Collection of names may, but need not be, disabled. active(2) start collecting count data. If it is supported, collection of names is enabled." ::= { appnIsInGlobal 1 } appnIsInGlobeCtrOperStatus OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether or not the intermediate session counts are active. The counts referred to here are the eight objects in the AppnIsInTable, from appnIsInP2SFmdPius through appnIsInS2PNonFmdBytes. These eight counts are of type Unsigned32 rather than Counter32 because when this object enters the notActive state, either because a Management Station has set appnInInGlobeCtrAdminStatus to notActive or because of a locally-initiated transition, the counts are all reset to 0. The values for this object are: notActive(1): collection of counts is not active; if it is queried, a count returns the value 0. active(2): collection of counts is active." Clouston & Moore Standards Track [Page 100] RFC 2455 APPN MIB November 1998 ::= { appnIsInGlobal 2 } appnIsInGlobeCtrStatusTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time since the appnIsInGlobeCtrOperStatus object last changed, measured in hundredths of a second. This time can be used to identify when this change occurred in relation to other events in the agent, such as the last time the APPN node was reinitialized." ::= { appnIsInGlobal 3 } appnIsInGlobeRscv OBJECT-TYPE SYNTAX INTEGER { notActive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the current route selection control vector (RSCV) collection option in effect, and allows a Management Station to change the option. The values for this object are: notActive(1): collection of route selection control vectors is not active. active(2): collection of route selection control vectors is active." ::= { appnIsInGlobal 4 } appnIsInGlobeRscvTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time since the appnIsInGlobeRscv object last changed, measured in hundredths of a second. This time can be used to identify when this change occurred in relation to other events in the agent, such as the last time the APPN node was reinitialized." Clouston & Moore Standards Track [Page 101] RFC 2455 APPN MIB November 1998 ::= { appnIsInGlobal 5 } appnIsInGlobeActSess OBJECT-TYPE SYNTAX Gauge32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active intermediate sessions." ::= { appnIsInGlobal 6 } appnIsInGlobeHprBfActSess OBJECT-TYPE SYNTAX Gauge32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active HPR intermediate sessions." ::= { appnIsInGlobal 7 } -- ********************************************************************* -- Intermediate Session Information Table -- ********************************************************************* -- This table contains information on intermediate sessions -- which are currently active. -- ********************************************************************* appnIsInTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnIsInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Intermediate Session Information Table" ::= { appnSessIntermediate 2 } appnIsInEntry OBJECT-TYPE SYNTAX AppnIsInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of Intermediate Session Information Table." INDEX { appnIsInFqCpName, appnIsInPcid } Clouston & Moore Standards Track [Page 102] RFC 2455 APPN MIB November 1998 ::= { appnIsInTable 1 } AppnIsInEntry ::= SEQUENCE { appnIsInFqCpName SnaControlPointName, appnIsInPcid OCTET STRING, appnIsInSessState INTEGER, appnIsInPriLuName DisplayString, appnIsInSecLuName DisplayString, appnIsInModeName SnaModeName, appnIsInCosName SnaClassOfServiceName, appnIsInTransPriority INTEGER, appnIsInSessType INTEGER, appnIsInSessUpTime TimeTicks, appnIsInCtrUpTime TimeTicks, appnIsInP2SFmdPius Unsigned32, appnIsInS2PFmdPius Unsigned32, appnIsInP2SNonFmdPius Unsigned32, appnIsInS2PNonFmdPius Unsigned32, appnIsInP2SFmdBytes Unsigned32, appnIsInS2PFmdBytes Unsigned32, appnIsInP2SNonFmdBytes Unsigned32, appnIsInS2PNonFmdBytes Unsigned32, appnIsInPsAdjCpName SnaControlPointName, appnIsInPsAdjTgNum INTEGER, appnIsInPsSendMaxBtuSize INTEGER, appnIsInPsSendPacingType INTEGER, appnIsInPsSendRpc Gauge32, appnIsInPsSendNxWndwSize Gauge32, appnIsInPsRecvPacingType INTEGER, appnIsInPsRecvRpc Gauge32, appnIsInPsRecvNxWndwSize Gauge32, appnIsInSsAdjCpName SnaControlPointName, appnIsInSsAdjTgNum INTEGER, appnIsInSsSendMaxBtuSize INTEGER, appnIsInSsSendPacingType INTEGER, appnIsInSsSendRpc Gauge32, appnIsInSsSendNxWndwSize Gauge32, appnIsInSsRecvPacingType INTEGER, appnIsInSsRecvRpc Gauge32, appnIsInSsRecvNxWndwSize Gauge32, appnIsInRouteInfo OCTET STRING, appnIsInRtpNceId OCTET STRING, Clouston & Moore Standards Track [Page 103] RFC 2455 APPN MIB November 1998 appnIsInRtpTcid OCTET STRING } appnIsInFqCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network-qualified control point name of the node at which the session and PCID originated. For APPN and LEN nodes, this is either CP name of the APPN node at which the origin LU is located or the CP name of the NN serving the LEN node at which the origin LU is located. For resources served by a dependent LU requester (DLUR), it is the name of the owning system services control point (SSCP)." ::= { appnIsInEntry 1 } appnIsInPcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The procedure correlation identifier (PCID) of a session. It is an 8-byte value assigned by the primary LU." ::= { appnIsInEntry 2 } appnIsInSessState OBJECT-TYPE SYNTAX INTEGER { inactive(1), pendactive(2), active(3), pendinact(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the state of the session: inactive(1) - session is inactive pendactive(2) - session is pending active active(3) - session is active pendinact(4) - session is pending inactive Active sessions can be deactivated by setting this object to inactive(1)." Clouston & Moore Standards Track [Page 104] RFC 2455 APPN MIB November 1998 ::= { appnIsInEntry 3 } appnIsInPriLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The primary LU name of the session. A zero-length string indicates that this name is not available." ::= { appnIsInEntry 4 } appnIsInSecLuName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary LU name of the session. A zero-length string indicates that this name is not available." ::= { appnIsInEntry 5 } appnIsInModeName OBJECT-TYPE SYNTAX SnaModeName MAX-ACCESS read-only STATUS current DESCRIPTION "The mode name used for this session." ::= { appnIsInEntry 6 } appnIsInCosName OBJECT-TYPE SYNTAX SnaClassOfServiceName MAX-ACCESS read-only STATUS current DESCRIPTION "The Class of Service (COS) name used for this session." ::= { appnIsInEntry 7 } appnIsInTransPriority OBJECT-TYPE SYNTAX INTEGER { low(1), --X'01' medium(2), --X'02' high(3), --X'03' network(4) --X'04' } MAX-ACCESS read-only Clouston & Moore Standards Track [Page 105] RFC 2455 APPN MIB November 1998 STATUS current DESCRIPTION "Transmission priority for this class of service. Values are: low(1) - (X'01'): low priority medium(2) - (X'02'): medium priority high(3) - (X'03'): high priority network(4) - (X'04'): network priority" ::= { appnIsInEntry 8 } appnIsInSessType OBJECT-TYPE SYNTAX INTEGER { unknown(1), lu62(2), lu0thru3(3), lu62dlur(4), lu0thru3dlur(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of intermediate session. Defined values are unknown The session type is not known. lu62 A session between LUs of type 6.2 (as indicated by the LU type in Bind) lu0thru3 A session between LUs of type 0, 1, 2, or 3 (as indicated by the LU type in Bind) lu62dlur A session between LUs of type 6.2 (as indicated by the LU type in Bind). One of the LUs is a dependent LU supported by the dependent LU requester (DLUR) function at this node. lu0thru3dlur A session between LUs of type 0, 1, 2, or 3 (as indicated by the LU type in Bind) One of the LUs is a dependent LU supported by the dependent LU requester (DLUR) function at this node." ::= { appnIsInEntry 9 } appnIsInSessUpTime OBJECT-TYPE SYNTAX TimeTicks Clouston & Moore Standards Track [Page 106] RFC 2455 APPN MIB November 1998 UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "Length of time the session has been active, measured in hundredths of a second." ::= { appnIsInEntry 10 } appnIsInCtrUpTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "Length of time the session counters have been active, measured in hundredths of a second." ::= { appnIsInEntry 11 } appnIsInP2SFmdPius OBJECT-TYPE SYNTAX Unsigned32 UNITS "path information units (PIUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of function management data (FMD) path information units (PIUs) sent from the Primary LU to the Secondary LU since the counts were last activated." ::= { appnIsInEntry 12 } appnIsInS2PFmdPius OBJECT-TYPE SYNTAX Unsigned32 UNITS "path information units (PIUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of FMD PIUs sent from the Secondary LU to the Primary LU since the counts were last activated." ::= { appnIsInEntry 13 } appnIsInP2SNonFmdPius OBJECT-TYPE SYNTAX Unsigned32 UNITS "path information units (PIUs)" MAX-ACCESS read-only STATUS current Clouston & Moore Standards Track [Page 107] RFC 2455 APPN MIB November 1998 DESCRIPTION "Number of non-FMD PIUs sent from the Primary LU to the Secondary LU since the counts were last activated." ::= { appnIsInEntry 14 } appnIsInS2PNonFmdPius OBJECT-TYPE SYNTAX Unsigned32 UNITS "path information units (PIUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of non-FMD PIUs sent from the Secondary LU to the Primary LU since the counts were last activated." ::= { appnIsInEntry 15 } appnIsInP2SFmdBytes OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of FMD bytes sent from the Primary LU to the Secondary LU since the counts were last activated." ::= { appnIsInEntry 16 } appnIsInS2PFmdBytes OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of FMD bytes sent from the Secondary LU to the Primary LU since the counts were last activated." ::= { appnIsInEntry 17 } appnIsInP2SNonFmdBytes OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of non-FMD bytes sent from the Primary LU to the Secondary LU since the counts were last activated." Clouston & Moore Standards Track [Page 108] RFC 2455 APPN MIB November 1998 ::= { appnIsInEntry 18 } appnIsInS2PNonFmdBytes OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of non-FMD bytes sent from the Secondary LU to the Primary LU since the counts were last activated." ::= { appnIsInEntry 19 } appnIsInPsAdjCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage adjacent CP name of this session. If the session stage traverses an RTP connection, the CP name of the remote RTP endpoint is returned." ::= { appnIsInEntry 20 } appnIsInPsAdjTgNum OBJECT-TYPE SYNTAX INTEGER (0..300) MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage adjacent transmission group (TG) number associated with this session. If the session stage traverses an RTP connection, the value 256 is returned. Values between 257 and 300 are available for other possible TG 'stand-ins' that may be added to APPN in the future." ::= { appnIsInEntry 21 } appnIsInPsSendMaxBtuSize OBJECT-TYPE SYNTAX INTEGER (99..32767) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage maximum basic transmission unit (BTU) size for sending data." ::= { appnIsInEntry 22 } Clouston & Moore Standards Track [Page 109] RFC 2455 APPN MIB November 1998 appnIsInPsSendPacingType OBJECT-TYPE SYNTAX INTEGER { fixed(1), adaptive(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage type of pacing being used for sending data." ::= { appnIsInEntry 23 } appnIsInPsSendRpc OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage send residual pace count. This represents the primary stage number of message units (MUs) that can still be sent in the current session window." ::= { appnIsInEntry 24 } appnIsInPsSendNxWndwSize OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage size of the next window which will be used to send data." ::= { appnIsInEntry 25 } appnIsInPsRecvPacingType OBJECT-TYPE SYNTAX INTEGER { fixed(1), adaptive(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage type of pacing being used for receiving data." ::= { appnIsInEntry 26 } Clouston & Moore Standards Track [Page 110] RFC 2455 APPN MIB November 1998 appnIsInPsRecvRpc OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage receive residual pace count. This represents the primary stage number of message units (MUs) that can still be received in the current session window." ::= { appnIsInEntry 27 } appnIsInPsRecvNxWndwSize OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The primary stage size of the next window which will be used to receive data." ::= { appnIsInEntry 28 } appnIsInSsAdjCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage adjacent CP name of this session. If the session stage traverses an RTP connection, the CP name of the remote RTP endpoint is returned." ::= { appnIsInEntry 29 } appnIsInSsAdjTgNum OBJECT-TYPE SYNTAX INTEGER (0..300) MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage adjacent transmission group (TG) number associated with this session. If the session stage traverses an RTP connection, the value 256 is returned. Values between 257 and 300 are available for other possible TG 'stand-ins' that may be added to APPN in the future." ::= { appnIsInEntry 30 } Clouston & Moore Standards Track [Page 111] RFC 2455 APPN MIB November 1998 appnIsInSsSendMaxBtuSize OBJECT-TYPE SYNTAX INTEGER (99..32767) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage maximum basic transmission unit (BTU) size for sending data." ::= { appnIsInEntry 31 } appnIsInSsSendPacingType OBJECT-TYPE SYNTAX INTEGER { fixed(1), adaptive(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage type of pacing being used for sending data." ::= { appnIsInEntry 32 } appnIsInSsSendRpc OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage send residual pace count. This represents the secondary stage number of message units (MUs) that can still be sent in the current session window." ::= { appnIsInEntry 33 } appnIsInSsSendNxWndwSize OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage size of the next window which will be used to send data." ::= { appnIsInEntry 34 } appnIsInSsRecvPacingType OBJECT-TYPE Clouston & Moore Standards Track [Page 112] RFC 2455 APPN MIB November 1998 SYNTAX INTEGER { fixed(1), adaptive(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage type of pacing being used for receiving data." ::= { appnIsInEntry 35 } appnIsInSsRecvRpc OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage receive residual pace count. This represents the secondary stage number of message units (MUs) that can still be received in the current session window." ::= { appnIsInEntry 36 } appnIsInSsRecvNxWndwSize OBJECT-TYPE SYNTAX Gauge32 UNITS "message units (MUs)" MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary stage size of the next window which will be used to receive data." ::= { appnIsInEntry 37 } appnIsInRouteInfo OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The route selection control vector (RSCV X'2B') used for this session. It is present for APPN nodes; but is not present for LEN nodes. The format of this vector is described in SNA Formats. If no RSCV is available, a zero-length string is returned." ::= { appnIsInEntry 38 } Clouston & Moore Standards Track [Page 113] RFC 2455 APPN MIB November 1998 appnIsInRtpNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The HPR local Network Connection Endpoint of the session." ::= { appnIsInEntry 39 } appnIsInRtpTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The RTP connection local TCID of the session." ::= { appnIsInEntry 40 } -- ********************************************************************* -- Intermediate Session RTP Table -- ********************************************************************* -- This table contains information on intermediate sessions that are -- being transported on Rapid Transport Protocol (RTP) connections by -- High Performance Routing (HPR). -- ********************************************************************* appnIsRtpTable OBJECT-TYPE SYNTAX SEQUENCE OF AppnIsRtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table indicating how many ISR sessions are transported by each RTP connection." ::= { appnSessIntermediate 3 } appnIsRtpEntry OBJECT-TYPE SYNTAX AppnIsRtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of Intermediate Session RTP Table." INDEX { appnIsRtpNceId, appnIsRtpTcid } ::= { appnIsRtpTable 1 } Clouston & Moore Standards Track [Page 114] RFC 2455 APPN MIB November 1998 AppnIsRtpEntry ::= SEQUENCE { appnIsRtpNceId OCTET STRING, appnIsRtpTcid OCTET STRING, appnIsRtpSessions Gauge32 } appnIsRtpNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local Network Connection Endpoint of the RTP connection." ::= { appnIsRtpEntry 1 } appnIsRtpTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local TCID of the RTP connection." ::= { appnIsRtpEntry 2 } appnIsRtpSessions OBJECT-TYPE SYNTAX Gauge32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intermediate sessions using this RTP connection." ::= { appnIsRtpEntry 3 } -- ********************************************************************* appnTraps OBJECT IDENTIFIER ::= { appnMIB 2 } -- ********************************************************************* alertTrap NOTIFICATION-TYPE OBJECTS { alertIdNumber, affectedObject } STATUS current DESCRIPTION "This trap carries a 32-bit SNA Management Services (SNA/MS) Alert ID Number, as specified in SNA/MS Formats." ::= { appnTraps 1 } Clouston & Moore Standards Track [Page 115] RFC 2455 APPN MIB November 1998 alertIdNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "A 32-bit SNA Management Services (SNA/MS) Alert ID Number, as specified in SNA/MS Formats." ::= { appnTraps 2 } affectedObject OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The MIB object associated with the Alert condition, if there is an object associated with it. If no associated object can be identified, the value 0.0 is passed in the trap." ::= { appnTraps 3 } -- ********************************************************************* -- Conformance information -- ********************************************************************* appnConformance OBJECT IDENTIFIER ::= { appnMIB 3 } appnCompliances OBJECT IDENTIFIER ::= { appnConformance 1 } appnGroups OBJECT IDENTIFIER ::= { appnConformance 2 } -- Compliance statements -- appnCompliance MODULE-COMPLIANCE (deprecated: moved to end of module) appnCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SNMPv2 entities that implement the APPN MIB. In the descriptions for the conditionally mandatory groups that follow, the branch network node is treated as a third node type, parallel to network node and end node. This is not how branch network nodes are treated in the base APPN architecture, but it increases clarity here to do it." MODULE -- this module -- Unconditionally mandatory groups Clouston & Moore Standards Track [Page 116] RFC 2455 APPN MIB November 1998 MANDATORY-GROUPS { appnGeneralConfGroup2, appnPortConfGroup, appnLinkConfGroup2, appnLocalTgConfGroup2, appnDirTableConfGroup2 } -- Conditionally mandatory groups GROUP appnNnUniqueConfGroup DESCRIPTION "The appnNnUniqueConfGroup is mandatory for network nodes." GROUP appnEnUniqueConfGroup DESCRIPTION "The appnEnUniqueConfGroup is mandatory for end nodes." GROUP appnVrnConfGroup DESCRIPTION "The appnVrnConfGroup is mandatory for network nodes, end nodes, and branch network nodes that implement virtual routing node support." GROUP appnNnTopoConfGroup2 DESCRIPTION "The appnNnTopoConfGroup2 is mandatory for network nodes." GROUP appnLocalEnTopoConfGroup2 DESCRIPTION "The appnLocalEnTopoConfGroup2 is mandatory for network nodes." GROUP appnLocalDirPerfConfGroup DESCRIPTION "The appnLocalDirPerfConfGroup is mandatory for APPN network nodes, end nodes, and branch network nodes." GROUP appnCosConfGroup DESCRIPTION "The appnCosConfGroup is mandatory for APPN network nodes, end nodes, and branch network nodes." GROUP appnIntSessConfGroup Clouston & Moore Standards Track [Page 117] RFC 2455 APPN MIB November 1998 DESCRIPTION "The appnIntSessConfGroup is mandatory for network nodes and branch network nodes." GROUP appnHprBaseConfGroup DESCRIPTION "The appnHprBaseConfGroup is mandatory for nodes that implement the HPR base (APPN option set 1400)." GROUP appnHprRtpConfGroup DESCRIPTION "The appnHprRtpConfGroup is mandatory for nodes that implement the HPR RTP tower (APPN option set 1401)." GROUP appnHprCtrlFlowsRtpConfGroup DESCRIPTION "The appnHprCtrlFlowsRtpConfGroup is mandatory for nodes that implement the HPR Control Flows over RTP tower (APPN option set 1402)." GROUP appnHprBfConfGroup DESCRIPTION "The appnHprBfConfGroup is mandatory for nodes that implement the APPN/HPR boundary function." GROUP appnTrapConfGroup DESCRIPTION "Traps are optional for all nodes." GROUP appnTrapNotifGroup DESCRIPTION "Traps are optional for all nodes." GROUP appnBrNnConfGroup DESCRIPTION "The appnBrNnConfGroup is mandatory for branch network nodes." ::= { appnCompliances 3 } -- { appnCompliances 2 } is used by the APPN-TRAP-MIB -- Units of conformance appnGeneralConfGroup2 OBJECT-GROUP OBJECTS { appnNodeCpName, appnNodeId, appnNodeType, appnNodeUpTime, Clouston & Moore Standards Track [Page 118] RFC 2455 APPN MIB November 1998 appnNodeParallelTg, appnNodeAdaptiveBindPacing, appnNodeHprSupport, appnNodeCounterDisconTime, appnNodeLsCounterType, appnNodeBrNn } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPN general information and capabilities." ::= { appnGroups 26 } -- { appnGroups 21 - 25 } are used by the APPN-TRAP-MIB appnPortConfGroup OBJECT-GROUP OBJECTS { appnPortCommand, appnPortOperState, appnPortDlcType, appnPortPortType, appnPortSIMRIM, appnPortLsRole, appnPortNegotLs, appnPortDynamicLinkSupport, appnPortMaxRcvBtuSize, appnPortMaxIframeWindow, appnPortDefLsGoodXids, appnPortDefLsBadXids, appnPortDynLsGoodXids, appnPortDynLsBadXids, appnPortSpecific, appnPortDlcLocalAddr, appnPortCounterDisconTime } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPN port information." ::= { appnGroups 2 } appnLinkConfGroup2 OBJECT-GROUP OBJECTS { appnLsCommand, appnLsOperState, appnLsPortName, appnLsDlcType, appnLsDynamic, Clouston & Moore Standards Track [Page 119] RFC 2455 APPN MIB November 1998 appnLsAdjCpName, appnLsAdjNodeType, appnLsTgNum, appnLsLimResource, appnLsActOnDemand, appnLsMigration, appnLsPartnerNodeId, appnLsCpCpSessionSupport, appnLsMaxSendBtuSize, appnLsInXidBytes, appnLsInMsgBytes, appnLsInXidFrames, appnLsInMsgFrames, appnLsOutXidBytes, appnLsOutMsgBytes, appnLsOutXidFrames, appnLsOutMsgFrames, appnLsEchoRsps, appnLsCurrentDelay, appnLsMaxDelay, appnLsMinDelay, appnLsMaxDelayTime, appnLsGoodXids, appnLsBadXids, appnLsSpecific, appnLsActiveTime, appnLsCurrentStateTime, appnLsHprSup, appnLsLocalAddr, appnLsRemoteAddr, appnLsRemoteLsName, appnLsStatusTime, appnLsStatusLsName, appnLsStatusCpName, appnLsStatusPartnerId, appnLsStatusTgNum, appnLsStatusGeneralSense, appnLsStatusRetry, appnLsStatusEndSense, appnLsStatusXidLocalSense, appnLsStatusXidRemoteSense, appnLsStatusXidByteInError, appnLsStatusXidBitInError, appnLsStatusDlcType, appnLsStatusLocalAddr, appnLsStatusRemoteAddr, appnLsCounterDisconTime, appnLsMltgMember Clouston & Moore Standards Track [Page 120] RFC 2455 APPN MIB November 1998 } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPN link information." ::= { appnGroups 27 } appnLocalTgConfGroup2 OBJECT-GROUP OBJECTS { appnLocalTgDestVirtual, appnLocalTgDlcData, appnLocalTgPortName, appnLocalTgQuiescing, appnLocalTgOperational, appnLocalTgCpCpSession, appnLocalTgEffCap, appnLocalTgConnCost, appnLocalTgByteCost, appnLocalTgSecurity, appnLocalTgDelay, appnLocalTgUsr1, appnLocalTgUsr2, appnLocalTgUsr3, appnLocalTgHprSup, appnLocalTgIntersubnet, appnLocalTgMltgLinkType } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of APPN local TG information." ::= { appnGroups 28 } appnDirTableConfGroup2 OBJECT-GROUP OBJECTS { appnDirNnServerName, appnDirLuOwnerName, appnDirLuLocation, appnDirType, appnDirApparentLuOwnerName } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of the APPN directory database." ::= { appnGroups 29 } appnNnUniqueConfGroup OBJECT-GROUP Clouston & Moore Standards Track [Page 121] RFC 2455 APPN MIB November 1998 OBJECTS { appnNodeNnCentralDirectory, appnNodeNnTreeCache, appnNodeNnRouteAddResist, appnNodeNnIsr, appnNodeNnFrsn, appnNodeNnPeriBorderSup, appnNodeNnInterchangeSup, appnNodeNnExteBorderSup, appnNodeNnSafeStoreFreq, appnNodeNnRsn, appnNodeNnCongested, appnNodeNnIsrDepleted, appnNodeNnQuiescing, appnNodeNnGateway } STATUS current DESCRIPTION "A collection of objects providing instrumentation unique to APPN network nodes." ::= { appnGroups 6 } appnEnUniqueConfGroup OBJECT-GROUP OBJECTS { appnNodeEnModeCosMap, appnNodeEnNnServer, appnNodeEnLuSearch } STATUS current DESCRIPTION "A collection of objects providing instrumentation for APPN end nodes. Some of these objects also appear in the instrumentation for a branch network node." ::= { appnGroups 7 } appnVrnConfGroup OBJECT-GROUP OBJECTS { appnVrnPortName } STATUS current DESCRIPTION "An object providing the instrumentation for virtual routing node support in an APPN node." ::= { appnGroups 8 } appnNnTopoConfGroup2 OBJECT-GROUP OBJECTS { appnNnTopoMaxNodes, Clouston & Moore Standards Track [Page 122] RFC 2455 APPN MIB November 1998 appnNnTopoCurNumNodes, appnNnTopoNodePurges, appnNnTopoTgPurges, appnNnTopoTotalTduWars, appnNnNodeFREntryTimeLeft, appnNnNodeFRType, appnNnNodeFRRsn, appnNnNodeFRRouteAddResist, appnNnNodeFRCongested, appnNnNodeFRIsrDepleted, appnNnNodeFRQuiescing, appnNnNodeFRGateway, appnNnNodeFRCentralDirectory, appnNnNodeFRIsr, appnNnNodeFRGarbageCollect, appnNnNodeFRHprSupport, appnNnNodeFRPeriBorderSup, appnNnNodeFRInterchangeSup, appnNnNodeFRExteBorderSup, appnNnNodeFRBranchAwareness, appnNnTgFREntryTimeLeft, appnNnTgFRDestVirtual, appnNnTgFRDlcData, appnNnTgFRRsn, appnNnTgFROperational, appnNnTgFRQuiescing, appnNnTgFRCpCpSession, appnNnTgFREffCap, appnNnTgFRConnCost, appnNnTgFRByteCost, appnNnTgFRSecurity, appnNnTgFRDelay, appnNnTgFRUsr1, appnNnTgFRUsr2, appnNnTgFRUsr3, appnNnTgFRGarbageCollect, appnNnTgFRSubareaNum, appnNnTgFRHprSup, appnNnTgFRDestHprTrans, appnNnTgFRTypeIndicator, appnNnTgFRIntersubnet, appnNnTgFRMltgLinkType, appnNnTgFRBranchTg } STATUS current DESCRIPTION "The appnNnTopoConfGroup is mandatory only for network nodes." Clouston & Moore Standards Track [Page 123] RFC 2455 APPN MIB November 1998 ::= { appnGroups 30 } appnLocalEnTopoConfGroup2 OBJECT-GROUP OBJECTS { appnLocalEnTgEntryTimeLeft, appnLocalEnTgDestVirtual, appnLocalEnTgDlcData, appnLocalEnTgOperational, appnLocalEnTgCpCpSession, appnLocalEnTgEffCap, appnLocalEnTgConnCost, appnLocalEnTgByteCost, appnLocalEnTgSecurity, appnLocalEnTgDelay, appnLocalEnTgUsr1, appnLocalEnTgUsr2, appnLocalEnTgUsr3, appnLocalEnTgMltgLinkType } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of the information that a network node possesses about the end nodes directly attached to it." ::= { appnGroups 31 } appnLocalDirPerfConfGroup OBJECT-GROUP OBJECTS { appnDirMaxCaches, appnDirCurCaches, appnDirCurHomeEntries, appnDirRegEntries, appnDirInLocates, appnDirInBcastLocates, appnDirOutLocates, appnDirOutBcastLocates, appnDirNotFoundLocates, appnDirNotFoundBcastLocates, appnDirLocateOutstands } STATUS current DESCRIPTION "The appnLocalDirPerfConfGroup is mandatory only for APPN network nodes and end nodes." ::= { appnGroups 11 } appnCosConfGroup OBJECT-GROUP OBJECTS { Clouston & Moore Standards Track [Page 124] RFC 2455 APPN MIB November 1998 appnCosModeCosName, appnCosTransPriority, appnCosNodeRowWgt, appnCosNodeRowResistMin, appnCosNodeRowResistMax, appnCosNodeRowMinCongestAllow, appnCosNodeRowMaxCongestAllow, appnCosTgRowWgt, appnCosTgRowEffCapMin, appnCosTgRowEffCapMax, appnCosTgRowConnCostMin, appnCosTgRowConnCostMax, appnCosTgRowByteCostMin, appnCosTgRowByteCostMax, appnCosTgRowSecurityMin, appnCosTgRowSecurityMax, appnCosTgRowDelayMin, appnCosTgRowDelayMax, appnCosTgRowUsr1Min, appnCosTgRowUsr1Max, appnCosTgRowUsr2Min, appnCosTgRowUsr2Max, appnCosTgRowUsr3Min, appnCosTgRowUsr3Max } STATUS current DESCRIPTION "The appnCosConfGroup is mandatory only for APPN network nodes and end nodes." ::= { appnGroups 12 } appnIntSessConfGroup OBJECT-GROUP OBJECTS { appnIsInGlobeCtrAdminStatus, appnIsInGlobeCtrOperStatus, appnIsInGlobeCtrStatusTime, appnIsInGlobeRscv, appnIsInGlobeRscvTime, appnIsInGlobeActSess, appnIsInSessState, appnIsInPriLuName, appnIsInSecLuName, appnIsInModeName, appnIsInCosName, appnIsInTransPriority, appnIsInSessType, appnIsInSessUpTime, appnIsInCtrUpTime, Clouston & Moore Standards Track [Page 125] RFC 2455 APPN MIB November 1998 appnIsInP2SFmdPius, appnIsInS2PFmdPius, appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius, appnIsInP2SFmdBytes, appnIsInS2PFmdBytes, appnIsInP2SNonFmdBytes, appnIsInS2PNonFmdBytes, appnIsInPsAdjCpName, appnIsInPsAdjTgNum, appnIsInPsSendMaxBtuSize, appnIsInPsSendPacingType, appnIsInPsSendRpc, appnIsInPsSendNxWndwSize, appnIsInPsRecvPacingType, appnIsInPsRecvRpc, appnIsInPsRecvNxWndwSize, appnIsInSsAdjCpName, appnIsInSsAdjTgNum, appnIsInSsSendMaxBtuSize, appnIsInSsSendPacingType, appnIsInSsSendRpc, appnIsInSsSendNxWndwSize, appnIsInSsRecvPacingType, appnIsInSsRecvRpc, appnIsInSsRecvNxWndwSize, appnIsInRouteInfo } STATUS current DESCRIPTION "The appnIntSessConfGroup is mandatory only for network nodes." ::= { appnGroups 13 } appnHprBaseConfGroup OBJECT-GROUP OBJECTS { appnNodeHprIntRteSetups, appnNodeHprIntRteRejects, appnLsErrRecoSup, appnLsForAnrLabel, appnLsRevAnrLabel } STATUS current DESCRIPTION "The appnHprBaseConfGroup is mandatory only for nodes that implement the HPR base (APPN option set 1400)." ::= { appnGroups 14 } Clouston & Moore Standards Track [Page 126] RFC 2455 APPN MIB November 1998 appnHprRtpConfGroup OBJECT-GROUP OBJECTS { appnNodeMaxSessPerRtpConn, appnNodeHprOrgRteSetups, appnNodeHprOrgRteRejects, appnNodeHprEndRteSetups, appnNodeHprEndRteRejects, appnLsBfNceId } STATUS current DESCRIPTION "The appnHprRtpConfGroup is mandatory only for nodes that implement the HPR RTP tower (APPN option set 1401)." ::= { appnGroups 15 } appnHprCtrlFlowsRtpConfGroup OBJECT-GROUP OBJECTS { appnLsCpCpNceId, appnLsRouteNceId } STATUS current DESCRIPTION "The appnHprCtrlFlowsRtpConfGroup is mandatory only for nodes that implement the HPR Control Flows over RTP tower (APPN option set 1402)." ::= { appnGroups 16 } appnHprBfConfGroup OBJECT-GROUP OBJECTS { appnIsInGlobeHprBfActSess, appnIsInRtpNceId, appnIsInRtpTcid, appnIsRtpSessions } STATUS current DESCRIPTION "The appnHprBfConfGroup is mandatory only for nodes that implement the APPN/HPR boundary function." ::= { appnGroups 17 } appnTrapConfGroup OBJECT-GROUP OBJECTS { alertIdNumber, affectedObject } STATUS current DESCRIPTION "The appnTrapConfGroup is optional for all APPN nodes. Nodes Clouston & Moore Standards Track [Page 127] RFC 2455 APPN MIB November 1998 implementing this group shall also implement the appnTrapNotifGroup." ::= { appnGroups 18 } appnTrapNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { alertTrap } STATUS current DESCRIPTION "The appnTrapNotifGroup is optional for all APPN nodes. Nodes implementing this group shall also implement the appnTrapConfGroup." ::= { appnGroups 19 } appnBrNnConfGroup OBJECT-GROUP OBJECTS { appnNodeEnNnServer, appnNodeEnLuSearch, appnLocalTgBranchLinkType } STATUS current DESCRIPTION "A collection of objects providing instrumentation for branch network nodes. Some of these objects also appear in the instrumentation for an end node. Note: A branch network node always returns endNode(2) as the value of the appnNodeType object from the appnGeneralConfGroup2 conformance group." ::= { appnGroups 20 } -- ********************************************************************* -- Deprecated definitions -- ********************************************************************* appnNodeMibVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (11)) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of LAST-UPDATED from this module's MODULE-IDENTITY macro. This object gives a Management Station an easy way of determining the level of the MIB supported by an agent. Since this object incorporates the Year 2000-unfriendly 2-digit year specified in SMI for the LAST-UPDATED field, and Clouston & Moore Standards Track [Page 128] RFC 2455 APPN MIB November 1998 since it was not found to be particularly useful, it has been deprecated. No replacement object has been defined." ::= { appnGeneralInfoAndCaps 2 } appnCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for the SNMPv2 entities that implement the APPN MIB. This is the compliance statement for the RFC 2155-level version of the APPN MIB. It was deprecated as new objects were added to the MIB for MLTG, branch network node, and other extensions to the APPN architecture." MODULE -- this module -- Unconditionally mandatory groups MANDATORY-GROUPS { appnGeneralConfGroup, appnPortConfGroup, appnLinkConfGroup, appnLocalTgConfGroup, appnDirTableConfGroup } -- Conditionally mandatory groups GROUP appnNnUniqueConfGroup DESCRIPTION "The appnNnUniqueConfGroup is mandatory only for network nodes." GROUP appnEnUniqueConfGroup DESCRIPTION "The appnEnUniqueConfGroup is mandatory only for end nodes." GROUP appnVrnConfGroup DESCRIPTION "The appnVrnConfGroup is mandatory only for network nodes and end nodes that implement virtual routing node support." GROUP appnNnTopoConfGroup DESCRIPTION "The appnNnTopoConfGroup is mandatory only for network nodes." Clouston & Moore Standards Track [Page 129] RFC 2455 APPN MIB November 1998 GROUP appnLocalEnTopoConfGroup DESCRIPTION "The appnLocalEnTopoConfGroup is mandatory only for network nodes." GROUP appnLocalDirPerfConfGroup DESCRIPTION "The appnLocalDirPerfConfGroup is mandatory only for APPN network nodes and end nodes." GROUP appnCosConfGroup DESCRIPTION "The appnCosConfGroup is mandatory only for APPN network nodes and end nodes." GROUP appnIntSessConfGroup DESCRIPTION "The appnIntSessConfGroup is mandatory only for network nodes." GROUP appnHprBaseConfGroup DESCRIPTION "The appnHprBaseConfGroup is mandatory only for nodes that implement the HPR base (APPN option set 1400)." GROUP appnHprRtpConfGroup DESCRIPTION "The appnHprRtpConfGroup is mandatory only for nodes that implement the HPR RTP tower (APPN option set 1401)." GROUP appnHprCtrlFlowsRtpConfGroup DESCRIPTION "The appnHprCtrlFlowsRtpConfGroup is mandatory only for nodes that implement the HPR Control Flows over RTP tower (APPN option set 1402)." GROUP appnHprBfConfGroup DESCRIPTION "The appnHprBfConfGroup is mandatory only for nodes that implement the APPN/HPR boundary function." GROUP appnTrapConfGroup DESCRIPTION "Traps are optional for all nodes." GROUP appnTrapNotifGroup DESCRIPTION "Traps are optional for all nodes." Clouston & Moore Standards Track [Page 130] RFC 2455 APPN MIB November 1998 ::= { appnCompliances 1 } appnGeneralConfGroup OBJECT-GROUP OBJECTS { appnNodeCpName, appnNodeMibVersion, appnNodeId, appnNodeType, appnNodeUpTime, appnNodeParallelTg, appnNodeAdaptiveBindPacing, appnNodeHprSupport, appnNodeCounterDisconTime } STATUS deprecated DESCRIPTION "A collection of objects providing the instrumentation of APPN general information and capabilities. This RFC 2155-level group was deprecated when the appnNodeMibVersion object was removed and the appnNodeLsCounterType and appnNodeBrNn objects were added." ::= { appnGroups 1 } appnLinkConfGroup OBJECT-GROUP OBJECTS { appnLsCommand, appnLsOperState, appnLsPortName, appnLsDlcType, appnLsDynamic, appnLsAdjCpName, appnLsAdjNodeType, appnLsTgNum, appnLsLimResource, appnLsActOnDemand, appnLsMigration, appnLsPartnerNodeId, appnLsCpCpSessionSupport, appnLsMaxSendBtuSize, appnLsInXidBytes, appnLsInMsgBytes, appnLsInXidFrames, appnLsInMsgFrames, appnLsOutXidBytes, appnLsOutMsgBytes, appnLsOutXidFrames, appnLsOutMsgFrames, Clouston & Moore Standards Track [Page 131] RFC 2455 APPN MIB November 1998 appnLsEchoRsps, appnLsCurrentDelay, appnLsMaxDelay, appnLsMinDelay, appnLsMaxDelayTime, appnLsGoodXids, appnLsBadXids, appnLsSpecific, appnLsActiveTime, appnLsCurrentStateTime, appnLsHprSup, appnLsLocalAddr, appnLsRemoteAddr, appnLsRemoteLsName, appnLsStatusTime, appnLsStatusLsName, appnLsStatusCpName, appnLsStatusPartnerId, appnLsStatusTgNum, appnLsStatusGeneralSense, appnLsStatusRetry, appnLsStatusEndSense, appnLsStatusXidLocalSense, appnLsStatusXidRemoteSense, appnLsStatusXidByteInError, appnLsStatusXidBitInError, appnLsStatusDlcType, appnLsStatusLocalAddr, appnLsStatusRemoteAddr, appnLsCounterDisconTime } STATUS deprecated DESCRIPTION "A collection of objects providing the instrumentation of APPN link information. This RFC 2155-level group was deprecated when the appnLsMltgMember object was added." ::= { appnGroups 3 } appnLocalTgConfGroup OBJECT-GROUP OBJECTS { appnLocalTgDestVirtual, appnLocalTgDlcData, appnLocalTgPortName, appnLocalTgQuiescing, appnLocalTgOperational, Clouston & Moore Standards Track [Page 132] RFC 2455 APPN MIB November 1998 appnLocalTgCpCpSession, appnLocalTgEffCap, appnLocalTgConnCost, appnLocalTgByteCost, appnLocalTgSecurity, appnLocalTgDelay, appnLocalTgUsr1, appnLocalTgUsr2, appnLocalTgUsr3, appnLocalTgHprSup, appnLocalTgIntersubnet } STATUS deprecated DESCRIPTION "A collection of objects providing the instrumentation of APPN local TG information. This RFC 2155-level group was deprecated when the appnLocalTgMltgLinkType object was added." ::= { appnGroups 4 } appnDirTableConfGroup OBJECT-GROUP OBJECTS { appnDirNnServerName, appnDirLuOwnerName, appnDirLuLocation, appnDirType } STATUS deprecated DESCRIPTION "A collection of objects providing the instrumentation of the APPN directory database. This RFC 2155-level group was deprecated when the appnDirApparentLuOwnerName object was added." ::= { appnGroups 5 } appnNnTopoConfGroup OBJECT-GROUP OBJECTS { appnNnTopoMaxNodes, appnNnTopoCurNumNodes, appnNnTopoNodePurges, appnNnTopoTgPurges, appnNnTopoTotalTduWars, appnNnNodeFREntryTimeLeft, appnNnNodeFRType, Clouston & Moore Standards Track [Page 133] RFC 2455 APPN MIB November 1998 appnNnNodeFRRsn, appnNnNodeFRRouteAddResist, appnNnNodeFRCongested, appnNnNodeFRIsrDepleted, appnNnNodeFRQuiescing, appnNnNodeFRGateway, appnNnNodeFRCentralDirectory, appnNnNodeFRIsr, appnNnNodeFRGarbageCollect, appnNnNodeFRHprSupport, appnNnNodeFRPeriBorderSup, appnNnNodeFRInterchangeSup, appnNnNodeFRExteBorderSup, appnNnTgFREntryTimeLeft, appnNnTgFRDestVirtual, appnNnTgFRDlcData, appnNnTgFRRsn, appnNnTgFROperational, appnNnTgFRQuiescing, appnNnTgFRCpCpSession, appnNnTgFREffCap, appnNnTgFRConnCost, appnNnTgFRByteCost, appnNnTgFRSecurity, appnNnTgFRDelay, appnNnTgFRUsr1, appnNnTgFRUsr2, appnNnTgFRUsr3, appnNnTgFRGarbageCollect, appnNnTgFRSubareaNum, appnNnTgFRHprSup, appnNnTgFRDestHprTrans, appnNnTgFRTypeIndicator, appnNnTgFRIntersubnet } STATUS deprecated DESCRIPTION "The appnNnTopoConfGroup is mandatory only for network nodes. This RFC 2155-level group was deprecated when the appnNnNodeFRBranchAwareness, appnNnTgFRMltgLinkType, and appnNnFRBranchTg objects were added." ::= { appnGroups 9 } appnLocalEnTopoConfGroup OBJECT-GROUP OBJECTS { Clouston & Moore Standards Track [Page 134] RFC 2455 APPN MIB November 1998 appnLocalEnTgEntryTimeLeft, appnLocalEnTgDestVirtual, appnLocalEnTgDlcData, appnLocalEnTgOperational, appnLocalEnTgCpCpSession, appnLocalEnTgEffCap, appnLocalEnTgConnCost, appnLocalEnTgByteCost, appnLocalEnTgSecurity, appnLocalEnTgDelay, appnLocalEnTgUsr1, appnLocalEnTgUsr2, appnLocalEnTgUsr3 } STATUS deprecated DESCRIPTION "The appnLocalEnTopoConfGroup is mandatory only for network nodes. This RFC 2155-level group was deprecated when the appnLocalEnTgMltgLinkType object was added." ::= { appnGroups 10 } END 5. Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. An authentication protocol is defined in [12]. A protocol for access control is defined in [15]. The read-only objects appnNnTgFRSecurity, appnLocalTgSecurity, appnLocalEnTgSecurity, appnCosTgRowSecurityMin, and appnCosTgRowSecurityMax can be used to determine the potential path of secure data. While these objects cannot be changed by a management application using this MIB, these objects could be used to determine where a security exposure exists due to an improper configuration on the agent. None of the other read-only objects in the APPN MIB reports a password, user data, or anything else that is particularly sensitive. Some enterprises view their network configuration itself, as well as Clouston & Moore Standards Track [Page 135] RFC 2455 APPN MIB November 1998 information about network usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. Four of the read-write objects in the MIB can affect network operations; it is recommended that SNMP access to these objects be restricted. The four objects are: o appnNodeNnSafeStoreFreq: Setting this object to 0, or to a very large value, effectively turns off safe storing of topology data. o appnPortCommand, appnLsCommand: These two objects allow an APPN port or link station to be activated, deactivated, or recycled via an SNMP operation. The latter two operations may disrupt current users of the network. o appnIsInSessState: Setting this object to 'inactive' causes an active SNA session to be deactivated. Other read-write objects control the gathering of network management data; controlling access to these objects is less critical. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11 [16]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Clouston & Moore Standards Track [Page 136] RFC 2455 APPN MIB November 1998 7. Acknowledgments This MIB module is the product of the IETF SNA NAU MIB WG and the AIW APPN/HPR MIBs SIG. Thanks to Wayne Clark, Cisco Systems; Jim Cobban, Nortel; Rich Daugherty, IBM Corporation; Mark Regan, Cisco Systems; and Leo Temoshenko, IBM Corporation, for their contributions and review. 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] 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. [6] 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. [7] 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. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. Clouston & Moore Standards Track [Page 137] RFC 2455 APPN MIB November 1998 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [18] IBM, Systems Network Architecture Technical Overview, GC30-3073. [19] IBM, Systems Network Architecture APPN Architecture Reference, SC30-3422 [20] IBM, Systems Network Architecture Formats, SC30-3346. [21] Allen, M., Clouston, B., Kielczewski, Z., Kwan, W., and B. Moore, "Definition of Managed Objects for APPC", RFC 2051, December 1995. [22] Kielczewski, Z., Kostick D., and K. Shih, "Definition of Managed Objects for SNA NAUs using SMIv2", RFC 1666, August 1994. [23] Clouston, B., and B. Moore, "Definitions of Managed Objects for DLUR", RFC 2232, November 1996. [24] Clouston, B., and B. Moore, "Definitions of Managed Objects for HPR", RFC 2238, November 1996. Clouston & Moore Standards Track [Page 138] RFC 2455 APPN MIB November 1998 [25] SNA DLC Services MIB Working Group, Hilgeman, J., Nix, S., Bartky, A., and W. Clark, "Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2", RFC 1747, January 1995. [26] SNA DLC Services MIB Working Group, Berl, S., Nix, S., and W. Clark, "Definitions of Managed Objects for SNA Data Link Control: LLC", May 1995. [27] Chen, D., Gayek, P., and S. Nix, "Definitions of Managed Objects for Data Link Switching using SNMPv2", RFC 2024, October 1995. [28] IBM, Systems Network Architecture Management Services Formats, GC31-8302. [29] Clouston, B., and B. Moore, "Definitions of Managed Objects for APPN", RFC 2155, June 1997. 9. Authors' Addresses Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Phone: +1 919 472 2333 EMail: clouston@cisco.com Robert Moore Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA Phone: +1 919 254 4436 EMail: remoore@us.ibm.com Clouston & Moore Standards Track [Page 139] RFC 2455 APPN MIB November 1998 10. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Clouston & Moore Standards Track [Page 140] snmp-mibs-downloader-1.1/mibrfcs/rfc2456.txt0000644000000000000000000012576711402176071015604 0ustar Network Working Group B. Clouston Request for Comments: 2456 Cisco Systems Category: Standards Track B. Moore IBM Corporation November 1998 Definitions of Managed Objects for APPN TRAPS 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. Table of Contents 1. Introduction ........................................... 2 2. The SNMP Network Management Framework .................. 2 3. Overview ............................................... 3 3.1 APPN TRAP MIB structure .............................. 5 4. Definitions ............................................ 6 5. Security Considerations ................................ 17 6. Intellectual Property .................................. 17 7. Acknowledgments ........................................ 18 8. References ............................................. 18 9. Authors' Addresses ..................................... 20 10. Full Copyright Statement ............................... 21 Clouston & Moore Standards Track [Page 1] RFC 2456 APPN TRAPS MIB November 1998 1. Introduction This document is a product of the SNA NAU Services MIB Working Group. It defines a MIB module for notifications for devices with Advanced Peer-to-Peer Networking (APPN) and Dependent LU Requester (DLUR) capabilities. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [13]. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Clouston & Moore Standards Track [Page 2] RFC 2456 APPN TRAPS MIB November 1998 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This document identifies the set of objects for reporting the status of devices with APPN and DLUR capabilities via notifications. See the SNANAU APPN MIB [18] and SNANAU DLUR MIB [19] for the objects for monitoring the configuration and active characteristics of the devices with APPN and DLUR capabilities. Many objects contained in the notifications of this MIB are imported from the APPN and DLUR MIBs. Implementors of this MIB must also implement the APPN MIB. Implementations that support the appnTrapMibDlurConfGroup and the appnTrapMibDlurNotifGroup must also implement the DLUR MIB. The SNANAU APPN MIB allows a management station to collect the network topology of an APPN network (the network nodes (NNs) in the network and all of transmission groups (TGs) between the network nodes) from an APPN device. It also allows the management station to collect the local topology (TGs to end stations, and locally defined ports and link stations) from an APPN device. While the SNANAU APPN MIB has an efficient way to poll the APPN device for updates to the network topology, using flow reduction sequence numbers (FRSNs) as a table index; it does not have a mechanism to poll the local topology tables (appnLocalTgTable, appnPortTable, and appnLsTable) for status changes. This MIB provides a mechanism for an APPN device to send notifications to inform the management station of status changes to rows of these tables. Status changes include operational state changes, and for TGs also include control-point to control-point (CP-CP) session state changes. A notification is defined for each type of status change for each table. The port and link operational state objects have intermediate states. Notifications are only sent for transition to active or inactive state. Clouston & Moore Standards Track [Page 3] RFC 2456 APPN TRAPS MIB November 1998 Notifications are only sent for row creation if the state is active or operational. This is done to avoid sending a notification as the row is created with an inactive initial state, followed by another notification as the resource is activated. Notifications are only sent for row deletion if the last state was active or operational. In most cases, a resource must be deactivated before it can be deleted, and the deactivation will cause a notification to be sent. There is no need for a second notification to be sent for the row deletion, except for the case where the deletion occurred without deactivation. In this case, the state of the object in the notification will indicate an inactve state, since a deleted resource can no longer be active. The purpose of the appnLocalTgCpCpStateChangeTrap notification is to identify the loss or recovery of CP-CP sessions on a TG while the TG remains operational. Thus this notification is only sent if there is a change to an appnLocalTgCpCpSession object, but not a change to the appnLocalTgOperational object. This notification is never sent for the creation or deletion of a row in the appnLocalTgTable. Each notification always contains an object which is a count of the number of times the status of a row in table has changed since the APPN node was last reinitialized. This enables a management station to detect that it has missed a notification, if it does not get the notifications in numerical sequence. If the notifications are not in sequence, the management station should retrieve the entire table to get the correct status for all rows. Similarly, the SNANAU DLUR MIB provides a mechanism for retrieving the configuration and status of dependent LU server (DLUS) sessions on a device with DLUR capabilities. This MIB defines a notification for a DLUR-DLUS session state change of a row in the dlurDlusTable, in the manner described above. A notification is only sent for a session state transition to active or inactive. As with the above notifications, it is only sent on row creation if the initial state is active; and on row deletion is the last state was active, in which case the notification indicates that the state is now inactive. The SNANAU APPN MIB also provides a mechanism for a management station to collect traffic statistics on intermediate sessions, primarily for accounting purposes. However, when the session is terminated, all statistics from the last poll until the session termination time are lost, since the row for that session is deleted from the appnIsInTable. This MIB defines a notification so that the session's final statistics can be sent to a management station. If the notification is not delivered, the final session statistics are lost. If this is a concern, polling of the appnIsInTable in the APPN Clouston & Moore Standards Track [Page 4] RFC 2456 APPN TRAPS MIB November 1998 MIB should be increased to more likely reduce the time between the last poll and the session termination, thereby reducing the amount of data lost. Highlights of the management functions supported by the APPN TRAP MIB module include the following: o A notification for an APPN local TG operational state change. o A notification for an APPN local TG CP-CP session state change. o A notification for an APPN port operational state change. o A notification for an APPN link station operational state change. o A notification for a DLUR-DLUS session state change. o A notification for reporting final APPN intermediate session statistics. This MIB module does not support: o Objects to query the configuration or status of APPN nodes on demand. o Notifications for changes to local topology tables not related to status. 3.1. APPN TRAP MIB Structure The APPN TRAP MIB module contains a group of notifications, and a group of supporting objects. The group of notifications consists of the following notifications: 1) appnIsrAccountingDataTrap This notification is generated by an APPN device when an intermediate session is terminating, to report the final accounting statistics of the session. 2) appnLocalTgOperStateChangeTrap This notification identifies a change to the appnLocalTgOperational object in a row of the SNANAU APPN MIB appnLocalTgTable. Clouston & Moore Standards Track [Page 5] RFC 2456 APPN TRAPS MIB November 1998 3) appnLocalTgCpCpStateChangeTrap This notification identifies a change to the appnLocalTgCpCpSession object in a row of the SNANAU APPN MIB appnLocalTgTable. 4) appnPortOperStateChangeTrap This notification identifies a change to the appnPortOperState object in a row of the SNANAU APPN MIB appnPortTable. 5) appnLsOperStateChangeTrap This notification identifies a change to the appnLsOperState object in a row of the SNANAU APPN MIB appnLsTable. 6) dlurDlusStateChangeTrap This notification identifies a change to the dlurDlusSessnStatus object in a row of the SNANAU DLUR MIB dlurDlusTable. The group of supporting objects contains the appnTrapControl object, which controls whether the APPN device generates each type of notification. Note that generation of the appnIsrAccountingDataTrap is not controlled by this object; instead it is controlled by the appnIsInGlobalCtrAdminStatus object in the SNANAU APPN MIB. Although APPN notification generation could be controlled solely by entries in the snmpNotificationMIB, RFC 2273 [9], the appnTrapControl object exists in this MIB so that implementations are not required to implement RFC 2273 to control generation of APPN notifications. For a notification to be generated and sent as a TRAP or INFORM, the notification type must first be enabled by the appnTrapControl object. It must also not be disabled by an snmpNotificationMIB entry. The destination of notifications is not within the scope of this MIB. Also contained in this group are objects for the TG, port, link, and DLUR-DLUS session notifications to indicate the number of times each of the tables has had a status change of a row since the APPN node was last reinitialized. 4. Definitions APPN-TRAP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, OBJECT-TYPE, MODULE-IDENTITY, Clouston & Moore Standards Track [Page 6] RFC 2456 APPN TRAPS MIB November 1998 NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF appnMIB, appnIsInP2SFmdPius, appnIsInS2PFmdPius, appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius, appnIsInP2SFmdBytes, appnIsInS2PFmdBytes, appnIsInP2SNonFmdBytes, appnIsInS2PNonFmdBytes, appnIsInSessUpTime, appnObjects, appnLocalTgOperational, appnLocalTgCpCpSession, appnPortOperState, appnLsOperState, appnCompliances, appnGroups FROM APPN-MIB dlurDlusSessnStatus FROM APPN-DLUR-MIB; appnTrapMIB MODULE-IDENTITY LAST-UPDATED "9808310000Z" -- August 31, 1998 ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG" CONTACT-INFO " Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Tel: 1 919 472 2333 E-mail: clouston@cisco.com Bob Moore IBM Corporation 4205 S. Miami Boulevard BRQA/501 P.O. Box 12195 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@us.ibm.com " DESCRIPTION "This MIB module defines notifications to be generated by network devices with APPN capabilities. It presupposes support for the APPN MIB. It also presupposes support for the DLUR MIB for implementations that support the DLUR-related groups." Clouston & Moore Standards Track [Page 7] RFC 2456 APPN TRAPS MIB November 1998 ::= { appnMIB 0 } -- ********************************************************************* -- Notifications -- ********************************************************************* appnIsrAccountingDataTrap NOTIFICATION-TYPE OBJECTS { appnIsInP2SFmdPius, appnIsInS2PFmdPius, appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius, appnIsInP2SFmdBytes, appnIsInS2PFmdBytes, appnIsInP2SNonFmdBytes, appnIsInS2PNonFmdBytes, appnIsInSessUpTime } STATUS current DESCRIPTION "When it has been enabled, this notification is generated by an APPN node whenever an ISR session passing through the node is taken down, regardless of whether the session went down normally or abnormally. Its purpose is to allow a management application (primarily an accounting application) that is monitoring the ISR counts to receive the final values of these counts, so that the application can properly account for the amounts the counts were incremented since the last time the application polled them. The appnIsInSessUpTime object provides the total amount of time that the session was active. This notification is not a substitute for polling the ISR counts. In particular, the count values reported in this notification cannot be assumed to be the complete totals for the life of the session, since they may have wrapped while the session was up. The session to which the objects in this notification apply is identified by the fully qualified CP name and PCID that make up the table index. An instance of this notification will contain exactly one instance of each of its objects, and these objects will all belong to the same conceptual row of the appnIsInTable. Generation of this notification is controlled by the same object in the APPN MIB, appnIsInGlobeCtrAdminStatus, that controls whether the count objects themselves are being incremented." Clouston & Moore Standards Track [Page 8] RFC 2456 APPN TRAPS MIB November 1998 ::= { appnTrapMIB 1 } appnLocalTgOperStateChangeTrap NOTIFICATION-TYPE OBJECTS { appnLocalTgTableChanges, appnLocalTgOperational } STATUS current DESCRIPTION "When it has been enabled, this notification makes it possible for an APPN topology application to get asynchronous notifications of local TG operational state changes, and thus to reduce the frequency with which it polls for these changes. This notification is sent whenever there is a change to the appnLocalTgOperational object in a row of the appnLocalTgTable. This notification is only sent for row creation if the row is created with a value of 'true' for appnLocalTgOperational. This notification is only sent for row deletion if the last value of appnLocalTgOperational was 'true'. In this case, the value of appnLocalTgOperational in the notification shall be 'false', since the deletion of a row indicates that the TG is no longer operational. The notification is more than a simple 'poll me now' indication. It carries both a count of local TG topology changes, and the current operational state itself. The count of changes allows an application to detect lost notifications, either when polling or upon receiving a subsequent notification, at which point it knows it must retrieve the entire appnLocalTgTable again. This is the same count as used in the appnLocalCpCpStateChangeTrap. A lost notification could indicate a local TG CP-CP session state change or an operational state change. Generation of this notification is controlled by the appnTrapControl object." ::= { appnTrapMIB 2 } appnLocalTgCpCpChangeTrap NOTIFICATION-TYPE OBJECTS { appnLocalTgTableChanges, appnLocalTgCpCpSession } STATUS current DESCRIPTION "When it has been enabled, this notification makes it possible Clouston & Moore Standards Track [Page 9] RFC 2456 APPN TRAPS MIB November 1998 for an APPN topology application to get asynchronous notifications of local TG control-point to control-point (CP-CP) session state changes, and thus to reduce the frequency with which it polls for these changes. This notification is sent whenever there is a change to the appnLocalTgCpCpSession object but NOT the appnLocalTgOperational object in a row of the appnLocalTgTable. This notification is never sent for appnLocalTgTable row creation or deletion. The notification is more than a simple 'poll me now' indication. It carries both a count of local TG topology changes, and the current CP-CP session state itself. The count of changes allows an application to detect lost notifications, either when polling or upon receiving a subsequent notification, at which point it knows it must retrieve the entire appnLocalTgTable again. This is the same count as used in the appnLocalTgOperStateChangeTrap. A lost notification could indicate a local TG CP-CP session state change or an operational state change. Generation of this notification is controlled by the appnTrapControl object." ::= { appnTrapMIB 3 } appnPortOperStateChangeTrap NOTIFICATION-TYPE OBJECTS { appnPortTableChanges, appnPortOperState } STATUS current DESCRIPTION "When it has been enabled, this notification makes it possible for an APPN topology application to get asynchronous notifications of port operational state changes, and thus to reduce the frequency with which it polls for these changes. This notification is only sent when a appnPortOperState has transitioned to a value of 'active' or 'inactive'. This notification is sent whenever there is a appnPortOperState object transition to 'inactive' or 'active' state in the appnPortTable. This notification is only sent for row creation if the row is created with a value of 'active' for appnPortOperState. This notification is only sent for row deletion if the last value of appnPortOperState was 'active'. In this case, the value of appnPortOperState Clouston & Moore Standards Track [Page 10] RFC 2456 APPN TRAPS MIB November 1998 in the notification shall be 'inactive', since the deletion of a row indicates that the port is no longer active. The notification is more than a simple 'poll me now' indication. It carries both a count of port table changes, and the operational state itself. The count of changes allows an application to detect lost notifications, either when polling or upon receiving a subsequent notification, at which point it knows it must retrieve the entire appnPortTable again. Generation of this notification is controlled by the appnTrapControl object." ::= { appnTrapMIB 4 } appnLsOperStateChangeTrap NOTIFICATION-TYPE OBJECTS { appnLsTableChanges, appnLsOperState } STATUS current DESCRIPTION "When it has been enabled, this notification makes it possible for an APPN topology application to get asynchronous notifications of link station operational state changes, and thus to reduce the frequency with which it polls for these changes. This notification is only sent when a appnLsOperState has transitioned to a value of 'active' or 'inactive'. This notification is sent whenever there is a appnLsOperState object transition to 'inactive' or 'active' state in the appnLsTable. This notification is only sent for row creation if the row is created with a value of 'active' for appnLsOperState. This notification is only sent for row deletion if the last value of appnLsOperState was 'active'. In this case, the value of appnLsOperState in the notification shall be 'inactive', since the deletion of a row indicates that the link station is no longer active. The notification is more than a simple 'poll me now' indication. It carries both a count of link station table changes, and the operational state itself. The count of changes allows an application to detect lost notifications, either when polling or upon receiving a subsequent notification, at which point it knows it must retrieve the entire appnLsTable again. Generation of this notification is controlled by the appnTrapControl object." Clouston & Moore Standards Track [Page 11] RFC 2456 APPN TRAPS MIB November 1998 ::= { appnTrapMIB 5 } dlurDlusStateChangeTrap NOTIFICATION-TYPE OBJECTS { dlurDlusTableChanges, dlurDlusSessnStatus } STATUS current DESCRIPTION "When it has been enabled, this notification makes it possible for an APPN topology application to get asynchronous notifications of DLUR-DLUS session changes, and thus to reduce the frequency with which it polls for these changes. This notification is sent whenever there is a dlurDlusSessnStatus object transition to 'inactive' or 'active' state in the dlurDlusTable. This notification is only sent for row creation if the row is created with a value of 'active' for dlurDlusSessnStatus. This notification is only sent for row deletion if the last value of dlurDlusSessnStatus was 'active'. In this case, the value of dlurDlusSessnStatus in the notification shall be 'inactive', since the deletion of a row indicates that the session is no longer active. The notification is more than a simple 'poll me now' indication. It carries both a count of DLUR-DLUS table changes, and the session status itself. The count of changes allows an application to detect lost notifications, either when polling or upon receiving a subsequent notification, at which point it knows it must retrieve the entire dlurDlusTable again. Generation of this notification is controlled by the appnTrapControl object." ::= { appnTrapMIB 6 } -- ********************************************************************* -- Supporting Objects -- ********************************************************************* appnTrapObjects OBJECT IDENTIFIER ::= { appnObjects 7 } appnTrapControl OBJECT-TYPE SYNTAX BITS { appnLocalTgOperStateChangeTrap(0), appnLocalTgCpCpChangeTrap(1), appnPortOperStateChangeTrap(2), Clouston & Moore Standards Track [Page 12] RFC 2456 APPN TRAPS MIB November 1998 appnLsOperStateChangeTrap(3), dlurDlusStateChangeTrap(4) -- add other notification types here } MAX-ACCESS read-write STATUS current DESCRIPTION "An object to turn APPN notification generation on and off. Setting a notification type's bit to 1 enables generation of notifications of that type, subject to further filtering resulting from entries in the snmpNotificationMIB. Setting this bit to 0 disables generation of notifications of that type. Note that generation of the appnIsrAccountingDataTrap is controlled by the appnIsInGlobeCtrAdminStatus object in the APPN MIB: if counts of intermediate session traffic are being kept at all, then the notification is also enabled." ::= { appnTrapObjects 1 } appnLocalTgTableChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a row in the appnLocalTgTable has changed status since the APPN node was last reinitialized. This counter is incremented whenever a condition is detected that would cause a appnLocalTgOperStateChangeTrap or appnLocalTgCpCpChangeTrap notification to be sent, whether or not those notifications are enabled." ::= { appnTrapObjects 2 } appnPortTableChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a row in the appnPortTable has changed status since the APPN node was last reinitialized. This counter is incremented whenever a condition is detected that would cause a appnPortOperStateChangeTrap notification to be sent, whether or not this notification is enabled." ::= { appnTrapObjects 3 } Clouston & Moore Standards Track [Page 13] RFC 2456 APPN TRAPS MIB November 1998 appnLsTableChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a row in the appnLsTable has changed status since the APPN node was last reinitialized. This counter is incremented whenever a condition is detected that would cause a appnLsOperStateChangeTrap notification to be sent, whether or not this notification is enabled." ::= { appnTrapObjects 4 } dlurDlusTableChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a row in the dlurDlusTable has changed status since the APPN node was last reinitialized. This counter is incremented whenever a condition is detected that would cause a dlurDlusStateChangeTrap notification to be sent, whether or not this notification is enabled." ::= { appnTrapObjects 5 } -- ********************************************************************* -- Conformance information -- ********************************************************************* -- Tie into the conformance structure in the APPN MIB: -- appnConformance OBJECT IDENTIFIER ::= {appnMIB 3 } -- -- appnCompliances OBJECT IDENTIFIER ::= {appnConformance 1 } -- appnGroups OBJECT IDENTIFIER ::= {appnConformance 2 } -- Compliance statement appnTrapMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SNMP entities that implement the APPN-TRAP-MIB." MODULE -- this module -- Conditionally mandatory groups GROUP appnTrapMibIsrNotifGroup DESCRIPTION Clouston & Moore Standards Track [Page 14] RFC 2456 APPN TRAPS MIB November 1998 "This group is mandatory for APPN nodes supporting reporting of final ISR counter values via notifications." GROUP appnTrapMibTopoConfGroup DESCRIPTION "This group is mandatory for APPN nodes supporting polling reduction for local topology." GROUP appnTrapMibTopoNotifGroup DESCRIPTION "This group is mandatory for APPN nodes supporting polling reduction for local topology." GROUP appnTrapMibDlurConfGroup DESCRIPTION "This group is mandatory for APPN nodes supporting polling reduction for the dlurDlusTable." GROUP appnTrapMibDlurNotifGroup DESCRIPTION "This group is mandatory for APPN nodes supporting polling reduction for the dlurDlusTable." OBJECT appnTrapControl MIN-ACCESS read-only DESCRIPTION "An agent is not required to support a set to this object." ::= {appnCompliances 2 } -- Units of conformance appnTrapMibIsrNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { appnIsrAccountingDataTrap } STATUS current DESCRIPTION "A notification for reporting the final values of the APPN MIB's ISR counters." ::= { appnGroups 21 } appnTrapMibTopoConfGroup OBJECT-GROUP OBJECTS { appnTrapControl, appnLocalTgTableChanges, appnPortTableChanges, Clouston & Moore Standards Track [Page 15] RFC 2456 APPN TRAPS MIB November 1998 appnLsTableChanges } STATUS current DESCRIPTION "A collection of objects for reducing the polling associated with the local topology tables in the APPN MIB. Nodes that implement this group SHALL also implement the appnTrapMibTopoNotifGroup." ::= { appnGroups 22 } appnTrapMibTopoNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { appnLocalTgOperStateChangeTrap, appnLocalTgCpCpChangeTrap, appnPortOperStateChangeTrap, appnLsOperStateChangeTrap } STATUS current DESCRIPTION "A collection of notifications for reducing the polling associated with the local topology tables in the APPN MIB. Nodes that implement this group SHALL also implement the appnTrapMibTopoConfGroup." ::= { appnGroups 23 } appnTrapMibDlurConfGroup OBJECT-GROUP OBJECTS { appnTrapControl, dlurDlusTableChanges } STATUS current DESCRIPTION "A collection of objects for reducing the polling associated with the dlurDlusTable in the DLUR MIB. Nodes that implement this group SHALL also implement the appnTrapMibDlurNotifGroup." ::= { appnGroups 24 } appnTrapMibDlurNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { dlurDlusStateChangeTrap } STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 16] RFC 2456 APPN TRAPS MIB November 1998 "A notification for reducing the polling associated with the dlurDlusTable in the DLUR MIB. Nodes that implement this group SHALL also implement the appnTrapMibDlurConfGroup." ::= { appnGroups 25 } END 5. Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. An authentication protocol is defined in [12]. A protocol for access control is defined in [15]. None of the read-only objects in the APPN TRAP MIB reports a password, user data, or anything else that is particularly sensitive. Some enterprises view their network configuration itself, as well as information about network usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. There is one read-write object in the APPN TRAP MIB, appnTrapControl. This object controls the generation of the notifications defined in the APPN TRAP MIB. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11 [16]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. Clouston & Moore Standards Track [Page 17] RFC 2456 APPN TRAPS MIB November 1998 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments This MIB module is the product of the IETF SNA NAU MIB WG and the AIW APPN/HPR MIBs SIG. 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] 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. [6] 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. [7] 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. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. Clouston & Moore Standards Track [Page 18] RFC 2456 APPN TRAPS MIB November 1998 [10] 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. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998 [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [18] Clouston, B., and B. Moore, "Definition of Managed Objects for APPN", RFC 2455, November 1998. [19] Clouston, B., and B. Moore, "Definitions of Managed Objects for DLUR", RFC 2232, November 1997. Clouston & Moore Standards Track [Page 19] RFC 2456 APPN TRAPS MIB November 1998 9. Authors' Addresses Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Phone: +1 919 472 2333 EMail: clouston@cisco.com Robert Moore Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA Phone: +1 919 254 4436 EMail: remoore@us.ibm.com Clouston & Moore Standards Track [Page 20] RFC 2456 APPN TRAPS MIB November 1998 10. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Clouston & Moore Standards Track [Page 21] snmp-mibs-downloader-1.1/mibrfcs/rfc2457.txt0000644000000000000000000015215411402176071015573 0ustar Network Working Group B. Clouston Request for Comments: 2457 Cisco Systems Category: Standards Track B. Moore IBM Corporation November 1998 Definitions of Managed Objects for Extended Border Node 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . 2 3.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 EBN MIB Structure . . . . . . . . . . . . . . . . . . . . 4 3.1.1 enbDir group . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 ebnIsRscv group . . . . . . . . . . . . . . . . . . . 5 3.1.3 ebnDirConfig group . . . . . . . . . . . . . . . . . . 7 3.1.4 ebnCos group . . . . . . . . . . . . . . . . . . . . . 8 3.1.5 ebnSubnetRoutingList group . . . . . . . . . . . . . . 8 3.1.6 hbn group . . . . . . . . . . . . . . . . . . . . . . 8 4.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 5.0 Security Considerations . . . . . . . . . . . . . . . . . 24 6.0 Intellectual Property . . . . . . . . . . . . . . . . . . 25 7.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 25 8.0 References . . . . . . . . . . . . . . . . . . . . . . . . 25 Clouston & Moore Standards Track [Page 1] RFC 2457 Extended Border Node MIB November 1998 9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 27 10.0 Full Copyright Statement . . . . . . . . . . . . . . . . 28 1.0 Introduction This document is a product of the SNA NAU Services MIB Working Group. It defines a MIB module for managing devices with Advanced Peer-to- Peer Networking (APPN) Extended Border Node (EBN) capabilities. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [13]. 2.0 The SNMP Network Management Framework The SNMP Network Management Framework presently consists of six major components. They are: o the overall architecture, described in RFC 2271 [7]. o the SMI, described in RFC 1902 [3], - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed objects for the Internet suite of protocols. o the protocol, STD 15, RFC 1157 [1] and/or RFC 1905 [6] and/or RFC 2272 [8] -- the protocol for accessing managed information. o the user-based security model defined in RFC 2274 [10]. o the view-based access control model defined in RFC 2275 [11]. Textual conventions are defined in RFC 1903 [4], and conformance statements are defined in RFC 1904 [5]. Common applications are defined in RFC 2273 [9]. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translation. Clouston & Moore Standards Track [Page 2] RFC 2457 Extended Border Node MIB November 1998 3.0 Overview This document identifies the proposed set of objects for monitoring the configuration and active characteristics of devices with EBN capabilities. The Extended Border Node function is an APPN enhancement for an APPN network node (NN). It supports topology isolation, subnet interconnection, and session establishment between subnets. In a single APPN network, all network topology information is propagated to all network nodes. Directory searches can also be forwarded to all network nodes. As the network grows, this network traffic could become prohibitive. Also, in networks where different enterprises are connected via APPN, it may be desirable to shield an enterprise from the network traffic of another enterprise. EBNs allow customers to partition a network into subnets to reduce or shield such network traffic. An EBN provides this function by blocking topology information exchange between subnets, and controlling where directory searches are forwarded. A subnetwork is a cluster of APPN NNs which share the same network topology. Subnetwork boundaries, or partitions, occur where an EBN and an NN adjacent to it have different network identifiers (NETIDs). They may also occur where an EBN and adjacent NN have the same NETID but are configured to have a subnetwork boundary. The connection between two APPN nodes is an APPN transmission group (TG). A TG at a subnet boundary is called an Intersubnetwork Transmission Group (ISTG). The subnet in which an EBN resides is called its native subnetwork. The subnet across the subnet boundary is called the non-native subnetwork, with respect to the EBN. A cost of the EBN function is that customers may have difficulty determining the end-to-end route of sessions that cross subnet boundaries, and understanding how the EBN will control directory searches between subnets. This MIB addresses these issues. Another challenge facing customers is to identify subnet boundaries formed by EBNs. The SNANAU APPN MIB [14] identifies subnet boundaries in the appnNnTopology group. The SNANAU APPN MIB provides management of APPN objects, and contains some tables that are extended by this MIB. In this document, we describe EBN managed objects. Clouston & Moore Standards Track [Page 3] RFC 2457 Extended Border Node MIB November 1998 The EBN terms and overall architecture are available from the networking.raleigh.ibm.com ftp site [15]. Highlights of the management functions supported by the EBN MIB module include the following: o Identifying the subnet affiliation of LUs (logical units) o Identifying session routes in non-native subnets, with correlation to the route in the native subnet provided in the SNANAU APPN MIB. o Identifying the COS (Class of Service) mappings between subnets. o Identifying the subnet routing lists This MIB module does not support: o Configuration of EBN nodes. o Historical information about session initiation failures. o Peripheral Border Node (PBN) support. PBN is an APPN function that only supports communication to adjacent subnetworks, and is not expected to be widely implemented. o Traps. The APPN MIB contains a trap for Alert conditions that may affect EBN resources. Although no APPN/EBN Alerts are defined today in the APPN MIB [14], they could exist in the future. The value for the affectedObject object contained in the alertTrap is determined by the implementation. It may contain a VariablePointer from the EBN MIB. 3.1 EBN MIB Structure The EBN MIB module contains the following groups of objects: o ebnDir - subnet information about LUs. o ebnIsRscv - provides the RSCV (Route Selection Control Vector) and COS for the subnetwork on the BIND destination side of the EBN. o ebnDirConfig - objects related to the EBN directory. o ebnCos - COS mapping between subnetworks, Clouston & Moore Standards Track [Page 4] RFC 2457 Extended Border Node MIB November 1998 o ebnSubnetRoutingList - the customer-supplied list of where to forward search requests. o hbn - HPR (High Performance Routing) EBN intermediate session information. These groups are described below in more detail. 3.1.1 enbDir group The ebnDir group contains the ebnDirTable, which is an extension to the appnDirTable. It specifies the subnet affiliation of LUs in the EBN's directory. 3.1.2 ebnIsRscv group The ebnIsRscv group contains the ebnIsRscvTable, which is an extension to the appnIsInTable. The appnIsInTable only allows for the RSCV and COS name for one subnetwork traversed by a session. This extension contains the RSCV and COS name for the other subnetwork. When an EBN changes RSCVs before forwarding a BIND, appnIsInRouteInfo contains the incoming RSCV, and ebnIsRscvDestinationRoute contains the outgoing RSCV. The following three cases illustrate the contents of appnIsInRouteInfo and ebnIsRscvDestinationRoute at Extended Border Nodes. 1. EBN connected to another EBN **subnet 1**|-----ISTG ------|**subnet 2** EBN1 EBN2 PLU SLU ---------------------------->| (1) |--------------->| (2) |----------> (3) PLU = Primary Logical Unit (session initiator) SLU = Secondary Logical Unit (session destination) The value of the appnIsInRouteInfo object at EBN1 is the RSCV containing the route, represented by (1), from the PLU (or the entry EBN in its subnet) to EBN2. The value of ebnIsRscvDestinationRoute object at EBN1 is the RSCV, represented by (2), containing the one-hop route from EBN1 to EBN2. The Clouston & Moore Standards Track [Page 5] RFC 2457 Extended Border Node MIB November 1998 appnIsInRouteInfo object at EBN2 also contains the RSCV represented by (2). The value of ebnIsRscvDestinationRoute in EBN2 is the RSVC containing the route to the SLU (or to the next subnet's entry EBN), represented by (3). 2. EBN connected to a NN or PBN **subnet 1**|-----ISTG ------|**subnet 2** EBN1 NN/PBN PLU SLU ---------------------------->| (1) |---------------------------> (2) The value of the appnIsInRouteInfo object at EBN1 is the RSCV containing the route from the PLU (or the entry EBN in its subnet) to the NN or PBN, represented by (1). The value of the ebnIsRscvDestinationRoute object at EBN1 is the RSCV containing the route from EBN1 to the SLU, represented by (2). Note that the SLU must be in subnet 2, because the entry node is an NN or PBN rather than an EBN. The appnIsInRouteInfo object at NN/PBN contains the same RSCV, as represented by (2). 3. NN or PBN connected to EBN **subnet 1**|-----ISTG ------|**subnet 2** NN/PBN EBN1 PLU SLU ---------------------------->| (1) |----------> (2) The value of the appnIsInRouteInfo object at the NN/PBN is the RSCV containing the route from the PLU to EBN1, represented by (1). Note that the PLU must be in subnet 1, because the exit node is an NN/PBN rather than an EBN. The appnIsInRouteInfo object at EBN1 contains the same RSCV. The value of the ebnIsRscvDestinationRoute object at EBN1 is the RSCV containing the route from EBN1 to the SLU (or the next subnet's entry border node), as represented by (2). The following three cases illustrate the contents of ebnIsRscvDestinationCos at Extended Border Nodes. Clouston & Moore Standards Track [Page 6] RFC 2457 Extended Border Node MIB November 1998 1. EBN connected to another EBN **subnet 1**|-----ISTG ------|**subnet 2** EBN1 EBN2 PLU SLU COS A ---------------------------->| COS B |----------> PLU = Primary Logical Unit (session initiator) SLU = Secondary Logical Unit (session destination) The value of ebnIsRscvDestinationCos object at EBN1 is COS A. The value of ebnIsRscvDestinationCos object at EBN2 is COS B. 2. EBN connected to a NN or PBN **subnet 1**|-----ISTG ------|**subnet 2** EBN1 NN/PBN PLU SLU COS A ----------->| COS B |---------------------------> The value of the ebvIsRscvDestinationCos object at EBN1 is COS B. 3. NN or PBN connected to EBN **subnet 1**|-----ISTG ------|**subnet 2** NN/PBN EBN1 PLU SLU COS A ---------------------------->| COS B |----------> The value of the ebnIsRscvDestinationCos object at the EBN2 is COSB. 3.1.3 ebnDirConfig group The ebnDirConfig group consists of simple objects that provide EBN- specific information about directory caching and the local default value for the maximum number of subnetworks a LOCATE search procedure may traverse. Clouston & Moore Standards Track [Page 7] RFC 2457 Extended Border Node MIB November 1998 3.1.4 ebnCos group The ebnCos group contains the ebnCosMapTable, which specifies how COS values are mapped between the non-native subnetwork and the native subnetwork. 3.1.5 ebnSubnetRoutingList group The ebnSubnetRoutingList group contains information about the customer-supplied EBN subnetwork routing list, which indicates to which adjacent nodes an EBN will forward LOCATE search requests. It consists of the following tables: 1. ebnSubnetSearchTable This table has an entry for each LU name that has a defined subnet routing list. The LU name may identify a single LU, or it may contain a wildcard character that could identify a group of LUs (partial wildcard) or all LUs (full wildcard). The objects in the table indicate whether the EBN may add dynamic entries to the subnet routing list, and whether the subnet routing list entries may be reordered for better search performance. 2. ebnSearchTable This table has an entry for each control point name which is included in a multi-subnet search for a particular LU name. The index to the table is the LU name to be searched for, and an index which lists the order in which the CP names are to be searched. Both the CP name and the LU name entries in the table allow for partial and full wildcards. The CP name also allows for special entries that indicate that the EBN will search itself and its own native subnetwork at this point in the search, or will search all native EBNs. 3.1.6 hbn group The hbn group contains information about HBN (HPR EBN) intermediate sessions. The hbnIsInTable is an extension to the appnIsInTable. This table is present for intermediate sessions when there are back- to-back RTP (Rapid Transport Protocol) connections in an HBN. It provides the NCE ID (network connection endpoint identifier) and TCID (transport connection identifier) for the second RTP connection. Clouston & Moore Standards Track [Page 8] RFC 2457 Extended Border Node MIB November 1998 4.0 Definitions EBN-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF DisplayString, TEXTUAL-CONVENTION FROM SNMPv2-TC SnaControlPointName -- Because the characters allowed in an SNA control -- point name come from a restricted character set, -- these names are not subject to internationalization. FROM APPN-MIB snanauMIB FROM SNA-NAU-MIB; ebnMIB MODULE-IDENTITY LAST-UPDATED "9804281800Z" -- April 28, 1998 ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG" CONTACT-INFO " Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Tel: 1 919 472 2333 E-mail: clouston@cisco.com Bob Moore IBM Corporation BRQA/501 P.O. Box 12195 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@us.ibm.com " DESCRIPTION " The MIB Module for Extended Border Node" ::= { snanauMIB 7 } -- snanauMIB ::= { mib-2 34 } Clouston & Moore Standards Track [Page 9] RFC 2457 Extended Border Node MIB November 1998 -- ****************************************************************** -- Textual Conventions -- ------------------------------------------------------------------ SnaNAUWildcardName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Fully-qualified network NAU name. Entries take one of three forms: - Explicit entries do not contain the character '*'. - Partial Wildcard entries have the form 'ccc*', where 'ccc' represents one to sixteen characters in a legal SNA NAU Name. - A full wildcard consists of a single character '*'. Because the characters allowed in an SNA NAU name come from a restricted character set, these names are not subject to internationalization." SYNTAX DisplayString(SIZE(1..17)) -- ****************************************************************** ebnObjects OBJECT IDENTIFIER ::= { ebnMIB 1 } -- ****************************************************************** -- ****************************************************************** -- EBN Directory Group -- The ebnDirTable is an extension to the appnDirTable. It specifies -- the subnet affiliation for LUs in the EBN's directory. -- ****************************************************************** ebnDir OBJECT IDENTIFIER ::= { ebnObjects 1 } ebnDirTable OBJECT-TYPE SYNTAX SEQUENCE OF EbnDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The EBN Directory Table. This table is an extension to the APPN MIB's appnDirTable. Entries in this table are in one-to-one correspondence with entries in the appnDirTable, with corresponding entries having identical values for their respective indexes." ::= { ebnDir 1 } ebnDirEntry OBJECT-TYPE SYNTAX EbnDirEntry MAX-ACCESS not-accessible Clouston & Moore Standards Track [Page 10] RFC 2457 Extended Border Node MIB November 1998 STATUS current DESCRIPTION "Entry in the EBN Directory Table." INDEX { ebnDirLuName } ::= { ebnDirTable 1 } EbnDirEntry ::= SEQUENCE { ebnDirLuName SnaNAUWildcardName, ebnDirSubnetAffiliation INTEGER } ebnDirLuName OBJECT-TYPE SYNTAX SnaNAUWildcardName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Fully qualified network LU name in the domain of a serving network node. If this object has the same value as the appnDirLuName object in the APPN MIB, then the two objects are referring to the same LU." ::= { ebnDirEntry 1 } ebnDirSubnetAffiliation OBJECT-TYPE SYNTAX INTEGER { native (1), nonNative (2), subarea (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the subnetwork affiliation of the LU: - native(1) : The LU is in the native APPN subnetwork. - nonNative(2) : The LU is in a non-native APPN subnetwork. - subarea(3) : The LU is in a subarea network." ::= { ebnDirEntry 2 } -- ****************************************************************** -- EBN Intermediate Session RSCV Group -- This table is a sparse extension to the appnIsInTable. For -- sessions crossing ISTGs adjacent to the EBN, it contains the RSCV -- and COS used in the direction of the BIND destination. -- ****************************************************************** ebnIsRscv OBJECT IDENTIFIER ::= { ebnObjects 2 } ebnIsRscvTable OBJECT-TYPE Clouston & Moore Standards Track [Page 11] RFC 2457 Extended Border Node MIB November 1998 SYNTAX SEQUENCE OF EbnIsRscvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The EBN Intermediate Session RSCV table. This table is an extension to the appnIsInTable. It contains the RSCV and COS used in the direction of the BIND destination. There is an entry in this table for each session that traverses an ISTG when it enters or leaves this EBN, with corresponding entries having identical values for their respective indexes." ::= { ebnIsRscv 1} ebnIsRscvEntry OBJECT-TYPE SYNTAX EbnIsRscvEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry in ebnIsRscvTable." INDEX { ebnIsRscvCpName, ebnIsRscvPcid } ::= { ebnIsRscvTable 1 } EbnIsRscvEntry ::= SEQUENCE { ebnIsRscvCpName SnaControlPointName, ebnIsRscvPcid OCTET STRING, ebnIsRscvDestinationRoute OCTET STRING, ebnIsRscvDestinationCos DisplayString } ebnIsRscvCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network-qualified control point name of the node at which the session and PCID originated. For APPN and LEN nodes, this is either CP name of the APPN node at which the origin LU is located or the CP name of the NN serving the LEN node at which the origin LU is located. For DLUR resources it is the name of the owning SSCP. If this object has the same value as the appnIsInFqCpName object in the APPN MIB, then the two objects are referring to the same APPN control point." ::= { ebnIsRscvEntry 1 } Clouston & Moore Standards Track [Page 12] RFC 2457 Extended Border Node MIB November 1998 ebnIsRscvPcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The procedure correlation identifier (PCID) of a session. It is an 8-octet value. If this object has the same value as the appnIsInPcid object in the APPN MIB, and if the corresponding ebnIsRscvCpName object has the same value as the corresponding appnIsInFqCpName object, then the entries indexed by these objects are referring to the same session." ::= { ebnIsRscvEntry 2 } ebnIsRscvDestinationRoute OBJECT-TYPE SYNTAX OCTET STRING(SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The route selection control vector (RSCV x'2B') used in the direction towards the SLU." ::= { ebnIsRscvEntry 3 } ebnIsRscvDestinationCos OBJECT-TYPE SYNTAX DisplayString (SIZE (1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Class of Service (COS) name used in the direction towards the SLU. Because the characters allowed in an SNA COS name come from a restricted character set, these names are not subject to internationalization." ::= { ebnIsRscvEntry 4 } -- ****************************************************************** -- EBN Directory Config Group -- The following simple objects provide information about EBN -- directory. -- ****************************************************************** ebnDirConfig OBJECT IDENTIFIER ::= { ebnObjects 3 } Clouston & Moore Standards Track [Page 13] RFC 2457 Extended Border Node MIB November 1998 ebnSearchCacheTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in minutes an extended border node will retain information about a multi-subnetwork search, once that that search terminates. A value 0 indicates that the EBN has no defined limit, and the number of entries is bounded only by memory." ::= { ebnDirConfig 1 } ebnMaxSearchCache OBJECT-TYPE SYNTAX Unsigned32 UNITS "entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of multi-subnet entries to be cached. The value 0 indicates that the local node has no defined limit, and the number of entries is bounded only by memory." ::= { ebnDirConfig 2 } ebnDefaultSubnetVisitCount OBJECT-TYPE SYNTAX Unsigned32 UNITS "topology subnetworks" MAX-ACCESS read-only STATUS current DESCRIPTION "The default maximum number of subnetworks a LOCATE search procedure may traverse." ::= { ebnDirConfig 3 } -- ****************************************************************** -- EBN COS Mapping Group -- The ebnCosMap Table specifies how non-native COS values are mapped -- to COS values defined in the native subnetwork. The COS mappings -- that an EBN performs are determined by multiple factors, one of -- which is a set of user-defined mappings. This table returns the -- COS mappings that the EBN is actually performing, rather than -- the user-defined mappings. -- ****************************************************************** Clouston & Moore Standards Track [Page 14] RFC 2457 Extended Border Node MIB November 1998 ebnCOS OBJECT IDENTIFIER ::= { ebnObjects 4 } ebnCosMapTable OBJECT-TYPE SYNTAX SEQUENCE OF EbnCosMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The EBN COS Mapping Table. This table specifies how non- native COS values are mapped to COS values defined in the native subnetwork. Note: The COS mappings that an EBN performs are determined by multiple factors, one of which is a set of user-defined initial mappings. This table returns the COS mappings that the EBN is actually performing at the time it is queried, rather than the user-defined initial ones." ::= { ebnCOS 1 } ebnCosMapEntry OBJECT-TYPE SYNTAX EbnCosMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EBN COS Mapping table." INDEX { ebnCosMapCpName, ebnCosMapNonNativeCos } ::= { ebnCosMapTable 1 } EbnCosMapEntry ::= SEQUENCE { ebnCosMapCpName SnaNAUWildcardName, ebnCosMapNonNativeCos DisplayString, ebnCosMapNativeCos DisplayString } ebnCosMapCpName OBJECT-TYPE SYNTAX SnaNAUWildcardName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Fully qualified network CP name for which the COS mapping applies." ::= { ebnCosMapEntry 1 } ebnCosMapNonNativeCos OBJECT-TYPE SYNTAX DisplayString (SIZE(1..8)) Clouston & Moore Standards Track [Page 15] RFC 2457 Extended Border Node MIB November 1998 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains one of the following values: - An 8-character COS name used in a non-native subnetwork. - The single character '*', identifying the entry with the default native COS for a non-native CP name. This entry is used when there is no entry in the table for a non-native CP name / non-native COS pair. Because the characters allowed in an SNA COS name come from a restricted character set, these names are not subject to internationalization." ::= { ebnCosMapEntry 2 } ebnCosMapNativeCos OBJECT-TYPE SYNTAX DisplayString (SIZE(1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "An 8-byte name for the class-of-service, as known in the native subnetwork. Because the characters allowed in an SNA COS name come from a restricted character set, these names are not subject to internationalization." ::= { ebnCosMapEntry 3 } -- ****************************************************************** -- EBN Subnet Routing List Group -- The EBN Subnet Routing List indicates to which nodes an EBN -- forwards search request. This group contains information -- pertaining to the CONFIGURED Subnet Routing List at an EBN. How a -- particular search request is routed is determined by a transient -- list that the EBN creates based on the configured list and other -- factors. -- ******************************************************************* ebnSubnetRoutingList OBJECT IDENTIFIER ::= { ebnObjects 5 } ebnSubnetSearchTable OBJECT-TYPE SYNTAX SEQUENCE OF EbnSubnetSearchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 16] RFC 2457 Extended Border Node MIB November 1998 "This table contains one entry for each fully qualified LU name for which an associated subnet routing list has been defined. An entry in this table contains general characteristics of the subnet search routing list for an LU name. The routing list itself is represented by a set of contiguous entries in the ebnSearchTable." ::= { ebnSubnetRoutingList 1 } ebnSubnetSearchEntry OBJECT-TYPE SYNTAX EbnSubnetSearchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for the ebnSubnetSearchTable. The entry represents the configured parameters the EBN uses when it is determining how to search for the LU identified by the ebnSubnetSearchLuName object." INDEX { ebnSubnetSearchLuName } ::= { ebnSubnetSearchTable 1 } EbnSubnetSearchEntry ::= SEQUENCE { ebnSubnetSearchLuName SnaNAUWildcardName, ebnSubnetSearchDynamics INTEGER, ebnSubnetSearchOrdering INTEGER } ebnSubnetSearchLuName OBJECT-TYPE SYNTAX SnaNAUWildcardName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Fully qualified network LU name." ::= { ebnSubnetSearchEntry 1 } ebnSubnetSearchDynamics OBJECT-TYPE SYNTAX INTEGER { none(1), limited (2), full (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether an EBN may add dynamic entries to a subnetwork routing list. none(1) means no entries may be added to the subnetwork routing list. limited(2) means only likely entries may be added to the subnetwork routing Clouston & Moore Standards Track [Page 17] RFC 2457 Extended Border Node MIB November 1998 list. full(3) means all native extended border nodes and adjacent, non-native EBNs and NNs will be added to the subnetwork routing list." ::= { ebnSubnetSearchEntry 2 } ebnSubnetSearchOrdering OBJECT-TYPE SYNTAX INTEGER{ priority(1), defined(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether an EBN may reorder a subnetwork routing list so that entries which are more likely to be successful move to the top of the subnetwork routing list and entries which are more likely to be unsuccessful move to the bottom of the list. The following values are defined: - priority(1): Entries may be reordered. - defined(2): Entries must not be reordered." ::= { ebnSubnetSearchEntry 3 } -- Border node search table ebnSearchTable OBJECT-TYPE SYNTAX SEQUENCE OF EbnSearchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table indicates the CONFIGURED list of control points to which the EBN sends Locate searches for a given fully qualified LU name. Each entry in the table indicates one control point that should be included in a multi-subnet search for a particular LU name." ::= { ebnSubnetRoutingList 2 } ebnSearchEntry OBJECT-TYPE SYNTAX EbnSearchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ebnSearchTable. An entry can exist in this table only if an entry exists in the ebnSubnetSearchTable with an ebnSubnetSearchLuName value matching this entry's ebnSearchLuName. Clouston & Moore Standards Track [Page 18] RFC 2457 Extended Border Node MIB November 1998 For a given ebnSearchLuName value, the ordering of entries provides by the ebnSearchIndex values corresponds to the order in which the control points to be searched appear in the CONFIGURED search list for the ebnSearchLuName." INDEX { ebnSearchLuName, ebnSearchIndex } ::= { ebnSearchTable 1 } EbnSearchEntry ::= SEQUENCE { ebnSearchLuName SnaNAUWildcardName, ebnSearchIndex Unsigned32, ebnSearchCpName DisplayString, ebnSearchSNVC Unsigned32 } ebnSearchLuName OBJECT-TYPE SYNTAX SnaNAUWildcardName MAX-ACCESS not-accessible STATUS current DESCRIPTION "Fully qualified network LU name. If this object has the same value as the ebnSubnetSearchLuName object, then the two objects are referring to the same LU." ::= { ebnSearchEntry 1 } ebnSearchIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Secondary index enumerating the CONFIGURED order in which a search is forwarded to CPs for a particular LU name. The order for an actual search is determined dynamically by the EBN, based on this configured information and on other factors, including whether search dynamics and search ordering are enabled. Information on these last two settings is available in, respectively, the ebnSubnetSearchDynamics and ebnSubnetSearch ordering objects." ::= { ebnSearchEntry 2 } ebnSearchCpName OBJECT-TYPE SYNTAX DisplayString(SIZE(1..17)) MAX-ACCESS read-only STATUS current DESCRIPTION Clouston & Moore Standards Track [Page 19] RFC 2457 Extended Border Node MIB November 1998 "This object specifies the CP(s) to which a search should be forwarded. It either follows the SnaNAUWildcardName textual convention or takes one of the following special formats: '*' indicates that all native EBNs and all adjacent non- native EBNs and NNs may be added to the routing list dynamically, '*SELF' indicates that the EBN should search itself and its native subnetwork at this time during the cross-subnet search, '*EBNS' indicates all native EBNs. Because the characters allowed in a CP name come from a restricted character set, and because the three formats listed here use no special characters, this object is not subject to internationalization." ::= { ebnSearchEntry 3 } ebnSearchSNVC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of subnets a Locate search procedure may traverse. " ::= { ebnSearchEntry 4 } -- ******************************************************************* -- HPR Extended Border Node Intermediate Session Group -- The hbnIsInTable is a sparse extension to the appnIsInTable. -- For sessions that use back-to-back RTP connections in an HBN, -- this table provides the network connection endpoint identifier -- (NceId) and the transport connection identifier (Tcid) for the -- second RTP connection. -- ******************************************************************* hbn OBJECT IDENTIFIER ::= { ebnObjects 6 } hbnIsInTable OBJECT-TYPE SYNTAX SEQUENCE OF HbnIsInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The HBN Intermediate Session table." Clouston & Moore Standards Track [Page 20] RFC 2457 Extended Border Node MIB November 1998 ::= { hbn 1} hbnIsInEntry OBJECT-TYPE SYNTAX HbnIsInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of the HBN Intermediate Session Table. An entry exists in this table for every intermediate session being routed between back-to-back RTP connections in the HBN. When an entry for a session exists in this table, the NceIds and Tcids for the back-to-back RTP connections are made available in the following four objects: RTP connection in the direction of the PLU: - NceId: appnIsInRtpNceId (in the APPN MIB) - Tcid: appnIsinRtpTcid (in the APPN MIB). RTP connection in the direction of the SLU: - NceId: hbnIsInRtpNceId (in this table) - Tcid: hbnIsInRtpTcid (in this table)." INDEX { hbnIsInFqCpName, hbnIsInPcid } ::= { hbnIsInTable 1 } HbnIsInEntry ::= SEQUENCE { hbnIsInFqCpName SnaControlPointName, hbnIsInPcid OCTET STRING, hbnIsInRtpNceId OCTET STRING, hbnIsInRtpTcid OCTET STRING } hbnIsInFqCpName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network-qualified control point name of the node at which the session and PCID originated. For APPN and LEN nodes, this is either the CP name of the APPN node at which the origin LU is located or the CP name of the NN serving the LEN node at which the origin LU is located. If this object has the same value as the appnIsInFqCpName object in the APPN MIB, then the two objects are referring to the same APPN control point." Clouston & Moore Standards Track [Page 21] RFC 2457 Extended Border Node MIB November 1998 ::= { hbnIsInEntry 1 } hbnIsInPcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The procedure correlation identifier (PCID) of a session. It is an 8-octet value. If this object has the same value as the appnIsInPcid object in the APPN MIB, and if the corresponding hbnIsInFqCpName object has the same value as the corresponding appnIsInFqCpName object, then the entries indexed by these objects are referring to the same session." ::= { hbnIsInEntry 2 } hbnIsInRtpNceId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The HPR local Network Connection Endpoint of the session in the direction of the SLU." ::= { hbnIsInEntry 3 } hbnIsInRtpTcid OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The RTP connection local TCID of the session in the direction of the SLU." ::= { hbnIsInEntry 4 } -- ******************************************************************* -- Conformance Statement -- ******************************************************************* ebnConformance OBJECT IDENTIFIER ::= { ebnMIB 2 } ebnCompliances OBJECT IDENTIFIER ::= { ebnConformance 1 } ebnGroups OBJECT IDENTIFIER ::= { ebnConformance 2 } -- Compliance statements ebnCompliance MODULE-COMPLIANCE Clouston & Moore Standards Track [Page 22] RFC 2457 Extended Border Node MIB November 1998 STATUS current DESCRIPTION "The compliance statement for the SNMPv2 entities which implement the ebnMIB." MODULE -- this module -- Unconditionally mandatory groups MANDATORY-GROUPS { ebnDirectoryGroup, ebnIsRscvGroup, ebnDirectoryConfigGroup, ebnCosMappingGroup, ebnSubnetRoutingListGroup } -- Conditionally mandatory groups GROUP hbnIsInGroup DESCRIPTION "The hbnIsInGroup is mandatory only for HPR extended border nodes." ::= {ebnCompliances 1 } -- Group definitions ebnDirectoryGroup OBJECT-GROUP OBJECTS { ebnDirSubnetAffiliation } STATUS current DESCRIPTION "The EBN-related directory objects." ::= { ebnGroups 1 } ebnIsRscvGroup OBJECT-GROUP OBJECTS { ebnIsRscvDestinationRoute, ebnIsRscvDestinationCos } STATUS current DESCRIPTION "Two objects representing RSCV and class of service information saved by an EBN." ::= { ebnGroups 2 } ebnDirectoryConfigGroup OBJECT-GROUP OBJECTS { ebnSearchCacheTime, ebnMaxSearchCache, ebnDefaultSubnetVisitCount } STATUS current Clouston & Moore Standards Track [Page 23] RFC 2457 Extended Border Node MIB November 1998 DESCRIPTION "The EBN Directory Configuration Group." ::= { ebnGroups 3 } ebnCosMappingGroup OBJECT-GROUP OBJECTS { ebnCosMapNativeCos } STATUS current DESCRIPTION "The EBN COS Mapping Group." ::= { ebnGroups 4 } ebnSubnetRoutingListGroup OBJECT-GROUP OBJECTS { ebnSubnetSearchDynamics, ebnSubnetSearchOrdering, ebnSearchCpName, ebnSearchSNVC } STATUS current DESCRIPTION "The Subnet Routing List Group." ::= { ebnGroups 5 } hbnIsInGroup OBJECT-GROUP OBJECTS { hbnIsInRtpNceId, hbnIsInRtpTcid } STATUS current DESCRIPTION "The HBN-related Intermediate Session Objects." ::= { ebnGroups 6 } END 5.0 Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. An authentication protocol is defined in [10]. A protocol for access control is defined in [11]. None of the read-only objects in the EBN MIB reports a password, user data, or anything else that is particularly sensitive. Some enterprises view their network configuration itself, as well as information about network usage and performance, as corporate assets; Clouston & Moore Standards Track [Page 24] RFC 2457 Extended Border Node MIB November 1998 such enterprises may wish to restrict SNMP access to most of the objects in the MIB. There are no read-write objects in the EBN MIB. 6.0 Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7.0 Acknowledgments This MIB module is the product of the IETF SNA NAU MIB WG and the AIW APPN/HPR MIBs SIG. Thanks to Dave Billing, Cisco Systems; Katie Lee, IBM Corporation; and Marcia Peters, IBM Corporation, for their contributions and review. 8.0 References [1] Case, J., Fedor, M. Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [2] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser S., "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. Clouston & Moore Standards Track [Page 25] RFC 2457 Extended Border Node MIB November 1998 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [7] Harrington D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [8] Harrington D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [9] Levi D., Meyer P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [10] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [11] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [12] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [14] Clouston, B. and B. Moore, "Definition of Managed Objects for APPN", RFC 2455, November 1998. [15] IBM, APPN Extended Border Node Architecture Reference Version 1.0, available only via anonymous FTP at networking.raleigh.ibm.com, as /pub/standards/aiw/appn/bordernode/ebn4.psbin. [16] IBM, SNA/MS Formats, GC31-8302-01 Clouston & Moore Standards Track [Page 26] RFC 2457 Extended Border Node MIB November 1998 9.0 Authors' Addresses Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Phone: +1-919-472-2333 EMail: clouston@cisco.com Robert Moore Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA Phone: +1-919-254-4436 EMail: remoore@us.ibm.com Clouston & Moore Standards Track [Page 27] RFC 2457 Extended Border Node MIB November 1998 10.0 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Clouston & Moore Standards Track [Page 28] snmp-mibs-downloader-1.1/mibrfcs/rfc2465.txt0000644000000000000000000022703311402176071015571 0ustar Network Working Group D. Haskin Request for Comments: 2465 S. Onishi Category: Standards Track Bay Networks, Inc. December 1998 Management Information Base for IP Version 6: Textual Conventions and General Group 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Table of Contents 1. The SNMPv2 Network Management Framework ............. 2 1.1 Object Definitions ................................ 2 2. Overview ............................................ 2 3. IPv6 Address Representation ......................... 3 4. Definition of Textual Conventions ................... 4 5. The IPv6 General Group .............................. 5 6. Acknowledgments ..................................... 36 7. References .......................................... 36 8. Security Considerations ............................. 37 9. Authors' Addresses................................... 37 Haskin & Onishi Standards Track [Page 1] RFC 2465 IPv6 MIB: General Group December 1998 10. Full Copyright Statement............................. 38 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, described in RFC 1213/STD 17 [3] - the core set of managed objects for the Internet suite of protocols. o RFC 1157/STD 15 [4] and RFC 1905 [5] which define two versions of the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. 2. Overview This document is the first in the series of documents that define various MIB object groups for IPv6. These groups are the basic unit of conformance: if the semantics of a group is applicable to an implementation, then it must implement all objects in that group. For example, an implementation must implement the TCP group if and only if it implements the TCP over IPv6 protocol. At minimum, implementations must implement the IPv6 General group defined in this document as well as the ICMPv6 group [9]. Haskin & Onishi Standards Track [Page 2] RFC 2465 IPv6 MIB: General Group December 1998 This document defines the IPv6 MIB textual conventions as well as the IPv6 General group which provides for the basic management of IPv6 entities and serve as the foundation for other IPv6 MIB definitions. The IPv6 General group consists of 6 tables: - ipv6IfTable The IPv6 Interfaces table contains information on the entity's IPv6 interfaces. - ipv6IfStatsTable This table contains information on the traffic statistics of the entity's IPv6 interfaces. - ipv6AddrPrefixTable The IPv6 Address Prefix table contains information on Address Prefixes that are associated with the entity's IPv6 interfaces. - ipv6AddrTable This table contains the addressing information relevant to the entity's IPv6 interfaces. - ipv6RouteTable The IPv6 routing table contains an entry for each valid IPv6 unicast route that can be used for packet forwarding determination. - ipv6NetToMediaTable The IPv6 address translation table contain the IPv6 Address to `physical' address equivalencies. 3. IPv6 Address Representation The IPv6 MIB defined in this memo uses an OCTET STRING of length 16 to represent 128-bit IPv6 address in network byte- order. This approach allows to implement IPv6 MIB without requiring any changes to the SNMPv2 SMI and compliant SNMP implementations. Haskin & Onishi Standards Track [Page 3] RFC 2465 IPv6 MIB: General Group December 1998 4. Definition of Textual Conventions IPV6-TC DEFINITIONS ::= BEGIN IMPORTS Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; -- definition of textual conventions Ipv6Address ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:" STATUS current DESCRIPTION "This data type is used to model IPv6 addresses. This is a binary string of 16 octets in network byte-order." SYNTAX OCTET STRING (SIZE (16)) Ipv6AddressPrefix ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:" STATUS current DESCRIPTION "This data type is used to model IPv6 address prefixes. This is a binary string of up to 16 octets in network byte-order." SYNTAX OCTET STRING (SIZE (0..16)) Ipv6AddressIfIdentifier ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:" STATUS current DESCRIPTION "This data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order." SYNTAX OCTET STRING (SIZE (0..8)) Ipv6IfIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero for each internetwork-layer interface in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each internetwork-layer interface must remain constant at least from one re-initialization of the entity's network management system to the next Haskin & Onishi Standards Track [Page 4] RFC 2465 IPv6 MIB: General Group December 1998 re-initialization." SYNTAX Integer32 (1..2147483647) Ipv6IfIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the Ipv6IfIndex convention. The latter defines a greater than zero value used to identify an IPv6 interface in the managed system. This extension permits the additional value of zero. The value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced." SYNTAX Integer32 (0..2147483647) END 5. The IPv6 General Group IPV6-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Counter32, Unsigned32, Integer32, Gauge32 FROM SNMPv2-SMI DisplayString, PhysAddress, TruthValue, TimeStamp, VariablePointer, RowPointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF Ipv6IfIndex, Ipv6Address, Ipv6AddressPrefix, Ipv6AddressIfIdentifier, Ipv6IfIndexOrZero FROM IPV6-TC; ipv6MIB MODULE-IDENTITY LAST-UPDATED "9802052155Z" ORGANIZATION "IETF IPv6 Working Group" CONTACT-INFO " Dimitry Haskin Postal: Bay Networks, Inc. 660 Techology Park Drive. Billerica, MA 01821 Haskin & Onishi Standards Track [Page 5] RFC 2465 IPv6 MIB: General Group December 1998 US Tel: +1-978-916-8124 E-mail: dhaskin@baynetworks.com Steve Onishi Postal: Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 US Tel: +1-978-916-3816 E-mail: sonishi@baynetworks.com" DESCRIPTION "The MIB module for entities implementing the IPv6 protocol." ::= { mib-2 55 } -- the IPv6 general group ipv6MIBObjects OBJECT IDENTIFIER ::= { ipv6MIB 1 } ipv6Forwarding OBJECT-TYPE SYNTAX INTEGER { forwarding(1), -- acting as a router -- NOT acting as notForwarding(2) -- a router } MAX-ACCESS read-write STATUS current DESCRIPTION "The indication of whether this entity is acting as an IPv6 router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv6 routers forward datagrams. IPv6 hosts do not (except those source-routed via the host). Note that for some managed nodes, this object may take on only a subset of the values possible. Accordingly, it is appropriate for an agent to return a `wrongValue' response if a management station attempts to change this object to an inappropriate value." Haskin & Onishi Standards Track [Page 6] RFC 2465 IPv6 MIB: General Group December 1998 ::= { ipv6MIBObjects 1 } ipv6DefaultHopLimit OBJECT-TYPE SYNTAX INTEGER(0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The default value inserted into the Hop Limit field of the IPv6 header of datagrams originated at this entity, whenever a Hop Limit value is not supplied by the transport layer protocol." DEFVAL { 64 } ::= { ipv6MIBObjects 2 } ipv6Interfaces OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IPv6 interfaces (regardless of their current state) present on this system." ::= { ipv6MIBObjects 3 } ipv6IfTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last insertion or removal of an entry in the ipv6IfTable. If the number of entries has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { ipv6MIBObjects 4 } -- the IPv6 Interfaces table ipv6IfTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 Interfaces table contains information on the entity's internetwork-layer interfaces. An IPv6 interface constitutes a logical network layer attachment to the layer immediately below Haskin & Onishi Standards Track [Page 7] RFC 2465 IPv6 MIB: General Group December 1998 IPv6 including internet layer 'tunnels', such as tunnels over IPv4 or IPv6 itself." ::= { ipv6MIBObjects 5 } ipv6IfEntry OBJECT-TYPE SYNTAX Ipv6IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An interface entry containing objects about a particular IPv6 interface." INDEX { ipv6IfIndex } ::= { ipv6IfTable 1 } Ipv6IfEntry ::= SEQUENCE { ipv6IfIndex Ipv6IfIndex, ipv6IfDescr DisplayString, ipv6IfLowerLayer VariablePointer, ipv6IfEffectiveMtu Unsigned32, ipv6IfReasmMaxSize Unsigned32, ipv6IfIdentifier Ipv6AddressIfIdentifier, ipv6IfIdentifierLength INTEGER, ipv6IfPhysicalAddress PhysAddress, ipv6IfAdminStatus INTEGER, ipv6IfOperStatus INTEGER, ipv6IfLastChange TimeStamp } ipv6IfIndex OBJECT-TYPE SYNTAX Ipv6IfIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique non-zero value identifying the particular IPv6 interface." ::= { ipv6IfEntry 1 } ipv6IfDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A textual string containing information about the interface. This string may be set by the network management system." ::= { ipv6IfEntry 2 } ipv6IfLowerLayer OBJECT-TYPE Haskin & Onishi Standards Track [Page 8] RFC 2465 IPv6 MIB: General Group December 1998 SYNTAX VariablePointer MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the protocol layer over which this network interface operates. If this network interface operates over the data-link layer, then the value of this object refers to an instance of ifIndex [6]. If this network interface operates over an IPv4 interface, the value of this object refers to an instance of ipAdEntAddr [3]. If this network interface operates over another IPv6 interface, the value of this object refers to an instance of ipv6IfIndex. If this network interface is not currently operating over an active protocol layer, then the value of this object should be set to the OBJECT ID { 0 0 }." ::= { ipv6IfEntry 3 } ipv6IfEffectiveMtu OBJECT-TYPE SYNTAX Unsigned32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the largest IPv6 packet which can be sent/received on the interface, specified in octets." ::= { ipv6IfEntry 4 } ipv6IfReasmMaxSize OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the largest IPv6 datagram which this entity can re-assemble from incoming IPv6 fragmented datagrams received on this interface." ::= { ipv6IfEntry 5 } ipv6IfIdentifier OBJECT-TYPE SYNTAX Ipv6AddressIfIdentifier MAX-ACCESS read-write STATUS current DESCRIPTION "The Interface Identifier for this interface that Haskin & Onishi Standards Track [Page 9] RFC 2465 IPv6 MIB: General Group December 1998 is (at least) unique on the link this interface is attached to. The Interface Identifier is combined with an address prefix to form an interface address. By default, the Interface Identifier is autoconfigured according to the rules of the link type this interface is attached to." ::= { ipv6IfEntry 6 } ipv6IfIdentifierLength OBJECT-TYPE SYNTAX INTEGER (0..64) UNITS "bits" MAX-ACCESS read-write STATUS current DESCRIPTION "The length of the Interface Identifier in bits." ::= { ipv6IfEntry 7 } ipv6IfPhysicalAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The interface's physical address. For example, for an IPv6 interface attached to an 802.x link, this object normally contains a MAC address. Note that in some cases this address may differ from the address of the interface's protocol sub-layer. The interface's media-specific MIB must define the bit and byte ordering and the format of the value of this object. For interfaces which do not have such an address (e.g., a serial line), this object should contain an octet string of zero length." ::= { ipv6IfEntry 8 } ipv6IfAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired state of the interface. When a managed system initializes, all IPv6 interfaces start with ipv6IfAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed Haskin & Onishi Standards Track [Page 10] RFC 2465 IPv6 MIB: General Group December 1998 system, ipv6IfAdminStatus is then changed to the up(1) state (or remains in the down(2) state)." ::= { ipv6IfEntry 9 } ipv6IfOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), noIfIdentifier(3), -- no interface identifier -- status can not be -- determined for some unknown(4), -- reason -- some component is notPresent(5) -- missing } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the interface. The noIfIdentifier(3) state indicates that no valid Interface Identifier is assigned to the interface. This state usually indicates that the link-local interface address failed Duplicate Address Detection. If ipv6IfAdminStatus is down(2) then ipv6IfOperStatus should be down(2). If ipv6IfAdminStatus is changed to up(1) then ipv6IfOperStatus should change to up(1) if the interface is ready to transmit and receive network traffic; it should remain in the down(2) or noIfIdentifier(3) state if and only if there is a fault that prevents it from going to the up(1) state; it should remain in the notPresent(5) state if the interface has missing (typically, lower layer) components." ::= { ipv6IfEntry 10 } ipv6IfLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management Haskin & Onishi Standards Track [Page 11] RFC 2465 IPv6 MIB: General Group December 1998 subsystem, then this object contains a zero value." ::= { ipv6IfEntry 11 } -- IPv6 Interface Statistics table ipv6IfStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6IfStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "IPv6 interface traffic statistics." ::= { ipv6MIBObjects 6 } ipv6IfStatsEntry OBJECT-TYPE SYNTAX Ipv6IfStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An interface statistics entry containing objects at a particular IPv6 interface." AUGMENTS { ipv6IfEntry } ::= { ipv6IfStatsTable 1 } Ipv6IfStatsEntry ::= SEQUENCE { ipv6IfStatsInReceives Counter32, ipv6IfStatsInHdrErrors Counter32, ipv6IfStatsInTooBigErrors Counter32, ipv6IfStatsInNoRoutes Counter32, ipv6IfStatsInAddrErrors Counter32, ipv6IfStatsInUnknownProtos Counter32, ipv6IfStatsInTruncatedPkts Counter32, ipv6IfStatsInDiscards Counter32, ipv6IfStatsInDelivers Counter32, ipv6IfStatsOutForwDatagrams Counter32, ipv6IfStatsOutRequests Counter32, ipv6IfStatsOutDiscards Haskin & Onishi Standards Track [Page 12] RFC 2465 IPv6 MIB: General Group December 1998 Counter32, ipv6IfStatsOutFragOKs Counter32, ipv6IfStatsOutFragFails Counter32, ipv6IfStatsOutFragCreates Counter32, ipv6IfStatsReasmReqds Counter32, ipv6IfStatsReasmOKs Counter32, ipv6IfStatsReasmFails Counter32, ipv6IfStatsInMcastPkts Counter32, ipv6IfStatsOutMcastPkts Counter32 } ipv6IfStatsInReceives OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of input datagrams received by the interface, including those received in error." ::= { ipv6IfStatsEntry 1 } ipv6IfStatsInHdrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams discarded due to errors in their IPv6 headers, including version number mismatch, other format errors, hop count exceeded, errors discovered in processing their IPv6 options, etc." ::= { ipv6IfStatsEntry 2 } ipv6IfStatsInTooBigErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams that could not be forwarded because their size exceeded the link MTU of outgoing interface." Haskin & Onishi Standards Track [Page 13] RFC 2465 IPv6 MIB: General Group December 1998 ::= { ipv6IfStatsEntry 3 } ipv6IfStatsInNoRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams discarded because no route could be found to transmit them to their destination." ::= { ipv6IfStatsEntry 4 } ipv6IfStatsInAddrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams discarded because the IPv6 address in their IPv6 header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., ::0) and unsupported addresses (e.g., addresses with unallocated prefixes). For entities which are not IPv6 routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address." ::= { ipv6IfStatsEntry 5 } ipv6IfStatsInUnknownProtos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol. This counter is incremented at the interface to which these datagrams were addressed which might not be necessarily the input interface for some of the datagrams." ::= { ipv6IfStatsEntry 6 } ipv6IfStatsInTruncatedPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Haskin & Onishi Standards Track [Page 14] RFC 2465 IPv6 MIB: General Group December 1998 DESCRIPTION "The number of input datagrams discarded because datagram frame didn't carry enough data." ::= { ipv6IfStatsEntry 7 } ipv6IfStatsInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IPv6 datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly." ::= { ipv6IfStatsEntry 8 } ipv6IfStatsInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of datagrams successfully delivered to IPv6 user-protocols (including ICMP). This counter is incremented at the interface to which these datagrams were addressed which might not be necessarily the input interface for some of the datagrams." ::= { ipv6IfStatsEntry 9 } ipv6IfStatsOutForwDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output datagrams which this entity received and forwarded to their final destinations. In entities which do not act as IPv6 routers, this counter will include only those packets which were Source-Routed via this entity, and the Source-Route processing was successful. Note that for a successfully forwarded datagram the counter of the outgoing interface is incremented." ::= { ipv6IfStatsEntry 10 } ipv6IfStatsOutRequests OBJECT-TYPE Haskin & Onishi Standards Track [Page 15] RFC 2465 IPv6 MIB: General Group December 1998 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IPv6 datagrams which local IPv6 user-protocols (including ICMP) supplied to IPv6 in requests for transmission. Note that this counter does not include any datagrams counted in ipv6IfStatsOutForwDatagrams." ::= { ipv6IfStatsEntry 11 } ipv6IfStatsOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output IPv6 datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipv6IfStatsOutForwDatagrams if any such packets met this (discretionary) discard criterion." ::= { ipv6IfStatsEntry 12 } ipv6IfStatsOutFragOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IPv6 datagrams that have been successfully fragmented at this output interface." ::= { ipv6IfStatsEntry 13 } ipv6IfStatsOutFragFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IPv6 datagrams that have been discarded because they needed to be fragmented at this output interface but could not be." ::= { ipv6IfStatsEntry 14 } ipv6IfStatsOutFragCreates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Haskin & Onishi Standards Track [Page 16] RFC 2465 IPv6 MIB: General Group December 1998 DESCRIPTION "The number of output datagram fragments that have been generated as a result of fragmentation at this output interface." ::= { ipv6IfStatsEntry 15 } ipv6IfStatsReasmReqds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IPv6 fragments received which needed to be reassembled at this interface. Note that this counter is incremented at the interface to which these fragments were addressed which might not be necessarily the input interface for some of the fragments." ::= { ipv6IfStatsEntry 16 } ipv6IfStatsReasmOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IPv6 datagrams successfully reassembled. Note that this counter is incremented at the interface to which these datagrams were addressed which might not be necessarily the input interface for some of the fragments." ::= { ipv6IfStatsEntry 17 } ipv6IfStatsReasmFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failures detected by the IPv6 re- assembly algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count of discarded IPv6 fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received. This counter is incremented at the interface to which these fragments were addressed which might not be necessarily the input interface for some of the fragments." ::= { ipv6IfStatsEntry 18 } Haskin & Onishi Standards Track [Page 17] RFC 2465 IPv6 MIB: General Group December 1998 ipv6IfStatsInMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of multicast packets received by the interface" ::= { ipv6IfStatsEntry 19 } ipv6IfStatsOutMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of multicast packets transmitted by the interface" ::= { ipv6IfStatsEntry 20 } -- Address Prefix table -- The IPv6 Address Prefix table contains information on -- the entity's IPv6 Address Prefixes that are associated -- with IPv6 interfaces. ipv6AddrPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6AddrPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The list of IPv6 address prefixes of IPv6 interfaces." ::= { ipv6MIBObjects 7 } ipv6AddrPrefixEntry OBJECT-TYPE SYNTAX Ipv6AddrPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An interface entry containing objects of a particular IPv6 address prefix." INDEX { ipv6IfIndex, ipv6AddrPrefix, ipv6AddrPrefixLength } ::= { ipv6AddrPrefixTable 1 } Ipv6AddrPrefixEntry ::= SEQUENCE { Haskin & Onishi Standards Track [Page 18] RFC 2465 IPv6 MIB: General Group December 1998 ipv6AddrPrefix Ipv6AddressPrefix, ipv6AddrPrefixLength INTEGER (0..128), ipv6AddrPrefixOnLinkFlag TruthValue, ipv6AddrPrefixAutonomousFlag TruthValue, ipv6AddrPrefixAdvPreferredLifetime Unsigned32, ipv6AddrPrefixAdvValidLifetime Unsigned32 } ipv6AddrPrefix OBJECT-TYPE SYNTAX Ipv6AddressPrefix MAX-ACCESS not-accessible STATUS current DESCRIPTION "The prefix associated with the this interface." ::= { ipv6AddrPrefixEntry 1 } ipv6AddrPrefixLength OBJECT-TYPE SYNTAX INTEGER (0..128) UNITS "bits" MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length of the prefix (in bits)." ::= { ipv6AddrPrefixEntry 2 } ipv6AddrPrefixOnLinkFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object has the value 'true(1)', if this prefix can be used for on-link determination and the value 'false(2)' otherwise." ::= { ipv6AddrPrefixEntry 3 } ipv6AddrPrefixAutonomousFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Autonomous address configuration flag. When true(1), indicates that this prefix can be used for autonomous address configuration (i.e. can be used to form a local interface address). If false(2), it is not used to autoconfigure a local interface address." ::= { ipv6AddrPrefixEntry 4 } Haskin & Onishi Standards Track [Page 19] RFC 2465 IPv6 MIB: General Group December 1998 ipv6AddrPrefixAdvPreferredLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "It is the length of time in seconds that this prefix will remain preferred, i.e. time until deprecation. A value of 4,294,967,295 represents infinity. The address generated from a deprecated prefix should no longer be used as a source address in new communications, but packets received on such an interface are processed as expected." ::= { ipv6AddrPrefixEntry 5 } ipv6AddrPrefixAdvValidLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "It is the length of time in seconds that this prefix will remain valid, i.e. time until invalidation. A value of 4,294,967,295 represents infinity. The address generated from an invalidated prefix should not appear as the destination or source address of a packet." ::= { ipv6AddrPrefixEntry 6 } -- the IPv6 Address table -- The IPv6 address table contains this node's IPv6 -- addressing information. ipv6AddrTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6AddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of addressing information relevant to this node's interface addresses." ::= { ipv6MIBObjects 8 } Haskin & Onishi Standards Track [Page 20] RFC 2465 IPv6 MIB: General Group December 1998 ipv6AddrEntry OBJECT-TYPE SYNTAX Ipv6AddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The addressing information for one of this node's interface addresses." INDEX { ipv6IfIndex, ipv6AddrAddress } ::= { ipv6AddrTable 1 } Ipv6AddrEntry ::= SEQUENCE { ipv6AddrAddress Ipv6Address, ipv6AddrPfxLength INTEGER, ipv6AddrType INTEGER, ipv6AddrAnycastFlag TruthValue, ipv6AddrStatus INTEGER } ipv6AddrAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 address to which this entry's addressing information pertains." ::= { ipv6AddrEntry 1 } ipv6AddrPfxLength OBJECT-TYPE SYNTAX INTEGER(0..128) UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of the prefix (in bits) associated with the IPv6 address of this entry." ::= { ipv6AddrEntry 2 } ipv6AddrType OBJECT-TYPE SYNTAX INTEGER { -- address has been formed -- using stateless stateless(1), -- autoconfiguration -- address has been acquired -- by stateful means -- (e.g. DHCPv6, manual stateful(2), -- configuration) Haskin & Onishi Standards Track [Page 21] RFC 2465 IPv6 MIB: General Group December 1998 -- type can not be determined unknown(3) -- for some reason. } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address. Note that 'stateless(1)' refers to an address that was statelessly autoconfigured; 'stateful(2)' refers to a address which was acquired by via a stateful protocol (e.g. DHCPv6, manual configuration)." ::= { ipv6AddrEntry 3 } ipv6AddrAnycastFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object has the value 'true(1)', if this address is an anycast address and the value 'false(2)' otherwise." ::= { ipv6AddrEntry 4 } ipv6AddrStatus OBJECT-TYPE SYNTAX INTEGER { preferred(1), deprecated(2), invalid(3), inaccessible(4), unknown(5) -- status can not be determined -- for some reason. } MAX-ACCESS read-only STATUS current DESCRIPTION "Address status. The preferred(1) state indicates that this is a valid address that can appear as the destination or source address of a packet. The deprecated(2) state indicates that this is a valid but deprecated address that should no longer be used as a source address in new communications, but packets addressed to such an address are processed as expected. The invalid(3) state indicates that this is not valid address which should not Haskin & Onishi Standards Track [Page 22] RFC 2465 IPv6 MIB: General Group December 1998 appear as the destination or source address of a packet. The inaccessible(4) state indicates that the address is not accessible because the interface to which this address is assigned is not operational." ::= { ipv6AddrEntry 5 } -- IPv6 Routing objects ipv6RouteNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of current ipv6RouteTable entries. This is primarily to avoid having to read the table in order to determine this number." ::= { ipv6MIBObjects 9 } ipv6DiscardedRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries." ::= { ipv6MIBObjects 10 } -- IPv6 Routing table ipv6RouteTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6RouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "IPv6 Routing table. This table contains an entry for each valid IPv6 unicast route that can be used for packet forwarding determination." ::= { ipv6MIBObjects 11 } ipv6RouteEntry OBJECT-TYPE SYNTAX Ipv6RouteEntry MAX-ACCESS not-accessible Haskin & Onishi Standards Track [Page 23] RFC 2465 IPv6 MIB: General Group December 1998 STATUS current DESCRIPTION "A routing entry." INDEX { ipv6RouteDest, ipv6RoutePfxLength, ipv6RouteIndex } ::= { ipv6RouteTable 1 } Ipv6RouteEntry ::= SEQUENCE { ipv6RouteDest Ipv6Address, ipv6RoutePfxLength INTEGER, ipv6RouteIndex Unsigned32, ipv6RouteIfIndex Ipv6IfIndexOrZero, ipv6RouteNextHop Ipv6Address, ipv6RouteType INTEGER, ipv6RouteProtocol INTEGER, ipv6RoutePolicy Integer32, ipv6RouteAge Unsigned32, ipv6RouteNextHopRDI Unsigned32, ipv6RouteMetric Unsigned32, ipv6RouteWeight Unsigned32, ipv6RouteInfo RowPointer, ipv6RouteValid TruthValue } ipv6RouteDest OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination IPv6 address of this route. This object may not take a Multicast address value." ::= { ipv6RouteEntry 1 } ipv6RoutePfxLength OBJECT-TYPE SYNTAX INTEGER(0..128) UNITS "bits" MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the prefix length of the destination address." ::= { ipv6RouteEntry 2 } ipv6RouteIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible Haskin & Onishi Standards Track [Page 24] RFC 2465 IPv6 MIB: General Group December 1998 STATUS current DESCRIPTION "The value which uniquely identifies the route among the routes to the same network layer destination. The way this value is chosen is implementation specific but it must be unique for ipv6RouteDest/ipv6RoutePfxLength pair and remain constant for the life of the route." ::= { ipv6RouteEntry 3 } ipv6RouteIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of ipv6IfIndex. For routes of the discard type this value can be zero." ::= { ipv6RouteEntry 4 } ipv6RouteNextHop OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS read-only STATUS current DESCRIPTION "On remote routes, the address of the next system en route; otherwise, ::0 ('00000000000000000000000000000000'H in ASN.1 string representation)." ::= { ipv6RouteEntry 5 } ipv6RouteType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following -- an route indicating that -- packets to destinations -- matching this route are discard(2), -- to be discarded -- route to directly local(3), -- connected (sub-)network -- route to a remote Haskin & Onishi Standards Track [Page 25] RFC 2465 IPv6 MIB: General Group December 1998 remote(4) -- destination } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of route. Note that 'local(3)' refers to a route for which the next hop is the final destination; 'remote(4)' refers to a route for which the next hop is not the final destination; 'discard(2)' refers to a route indicating that packets to destinations matching this route are to be discarded (sometimes called black-hole route)." ::= { ipv6RouteEntry 6 } ipv6RouteProtocol OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following -- non-protocol information, -- e.g., manually configured local(2), -- entries netmgmt(3), -- static route -- obtained via Neighbor -- Discovery protocol, ndisc(4), -- e.g., result of Redirect -- the following are all -- dynamic routing protocols rip(5), -- RIPng ospf(6), -- Open Shortest Path First bgp(7), -- Border Gateway Protocol idrp(8), -- InterDomain Routing Protocol igrp(9) -- InterGateway Routing Protocol } MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which this route was learned." ::= { ipv6RouteEntry 7 } ipv6RoutePolicy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only Haskin & Onishi Standards Track [Page 26] RFC 2465 IPv6 MIB: General Group December 1998 STATUS current DESCRIPTION "The general set of conditions that would cause the selection of one multipath route (set of next hops for a given destination) is referred to as 'policy'. Unless the mechanism indicated by ipv6RouteProtocol specified otherwise, the policy specifier is the 8-bit Traffic Class field of the IPv6 packet header that is zero extended at the left to a 32-bit value. Protocols defining 'policy' otherwise must either define a set of values which are valid for this object or must implement an integer- instanced policy table for which this object's value acts as an index." ::= { ipv6RouteEntry 8 } ipv6RouteAge OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned." ::= { ipv6RouteEntry 9 } ipv6RouteNextHopRDI OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Routing Domain ID of the Next Hop. The semantics of this object are determined by the routing-protocol specified in the route's ipv6RouteProtocol value. When this object is unknown or not relevant its value should be set to zero." ::= { ipv6RouteEntry 10 } ipv6RouteMetric OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION Haskin & Onishi Standards Track [Page 27] RFC 2465 IPv6 MIB: General Group December 1998 "The routing metric for this route. The semantics of this metric are determined by the routing protocol specified in the route's ipv6RouteProtocol value. When this is unknown or not relevant to the protocol indicated by ipv6RouteProtocol, the object value should be set to its maximum value (4,294,967,295)." ::= { ipv6RouteEntry 11 } ipv6RouteWeight OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The system internal weight value for this route. The semantics of this value are determined by the implementation specific rules. Generally, within routes with the same ipv6RoutePolicy value, the lower the weight value the more preferred is the route." ::= { ipv6RouteEntry 12 } ipv6RouteInfo OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route's ipv6RouteProto value. If this information is not present, its value should be set to the OBJECT ID { 0 0 }, which is a syntactically valid object identifier, and any implementation conforming to ASN.1 and the Basic Encoding Rules must be able to generate and recognize this value." ::= { ipv6RouteEntry 13 } ipv6RouteValid OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to the value 'false(2)' has the effect of invalidating the corresponding entry in the ipv6RouteTable object. That is, it effectively disassociates the destination Haskin & Onishi Standards Track [Page 28] RFC 2465 IPv6 MIB: General Group December 1998 identified with said entry from the route identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipv6RouteValid object." DEFVAL { true } ::= { ipv6RouteEntry 14 } -- IPv6 Address Translation table ipv6NetToMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6NetToMediaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 Address Translation table used for mapping from IPv6 addresses to physical addresses. The IPv6 address translation table contain the Ipv6Address to `physical' address equivalencies. Some interfaces do not use translation tables for determining address equivalencies; if all interfaces are of this type, then the Address Translation table is empty, i.e., has zero entries." ::= { ipv6MIBObjects 12 } ipv6NetToMediaEntry OBJECT-TYPE SYNTAX Ipv6NetToMediaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IPv6 address to `physical' address equivalence." INDEX { ipv6IfIndex, ipv6NetToMediaNetAddress } ::= { ipv6NetToMediaTable 1 } Ipv6NetToMediaEntry ::= SEQUENCE { ipv6NetToMediaNetAddress Ipv6Address, ipv6NetToMediaPhysAddress Haskin & Onishi Standards Track [Page 29] RFC 2465 IPv6 MIB: General Group December 1998 PhysAddress, ipv6NetToMediaType INTEGER, ipv6IfNetToMediaState INTEGER, ipv6IfNetToMediaLastUpdated TimeStamp, ipv6NetToMediaValid TruthValue } ipv6NetToMediaNetAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 Address corresponding to the media-dependent `physical' address." ::= { ipv6NetToMediaEntry 1 } ipv6NetToMediaPhysAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The media-dependent `physical' address." ::= { ipv6NetToMediaEntry 2 } ipv6NetToMediaType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following dynamic(2), -- dynamically resolved static(3), -- statically configured local(4) -- local interface } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the mapping. The 'dynamic(2)' type indicates that the IPv6 address to physical addresses mapping has been dynamically resolved using the IPv6 Neighbor Discovery protocol. The static(3)' types indicates that the mapping has been statically configured. The local(4) indicates that the mapping is provided for an entity's own interface address." ::= { ipv6NetToMediaEntry 3 } Haskin & Onishi Standards Track [Page 30] RFC 2465 IPv6 MIB: General Group December 1998 ipv6IfNetToMediaState OBJECT-TYPE SYNTAX INTEGER { reachable(1), -- confirmed reachability stale(2), -- unconfirmed reachability delay(3), -- waiting for reachability -- confirmation before entering -- the probe state probe(4), -- actively probing invalid(5), -- an invalidated mapping unknown(6) -- state can not be determined -- for some reason. } MAX-ACCESS read-only STATUS current DESCRIPTION "The Neighbor Unreachability Detection [8] state for the interface when the address mapping in this entry is used." ::= { ipv6NetToMediaEntry 4 } ipv6IfNetToMediaLastUpdated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this entry was last updated. If this entry was updated prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { ipv6NetToMediaEntry 5 } ipv6NetToMediaValid OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to the value 'false(2)' has the effect of invalidating the corresponding entry in the ipv6NetToMediaTable. That is, it effectively disassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to Haskin & Onishi Standards Track [Page 31] RFC 2465 IPv6 MIB: General Group December 1998 whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipv6NetToMediaValid object." DEFVAL { true } ::= { ipv6NetToMediaEntry 6 } -- definition of IPv6-related notifications. -- Note that we need ipv6NotificationPrefix with the 0 -- sub-identifier to make this MIB to translate to -- an SNMPv1 format in a reversible way. For example -- it is needed for proxies that convert SNMPv1 traps -- to SNMPv2 notifications without MIB knowledge. ipv6Notifications OBJECT IDENTIFIER ::= { ipv6MIB 2 } ipv6NotificationPrefix OBJECT IDENTIFIER ::= { ipv6Notifications 0 } ipv6IfStateChange NOTIFICATION-TYPE OBJECTS { ipv6IfDescr, ipv6IfOperStatus -- the new state of the If. } STATUS current DESCRIPTION "An ipv6IfStateChange notification signifies that there has been a change in the state of an ipv6 interface. This notification should be generated when the interface's operational status transitions to or from the up(1) state." ::= { ipv6NotificationPrefix 1 } -- conformance information ipv6Conformance OBJECT IDENTIFIER ::= { ipv6MIB 3 } ipv6Compliances OBJECT IDENTIFIER ::= { ipv6Conformance 1 } ipv6Groups OBJECT IDENTIFIER ::= { ipv6Conformance 2 } -- compliance statements Haskin & Onishi Standards Track [Page 32] RFC 2465 IPv6 MIB: General Group December 1998 ipv6Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement ipv6 MIB." MODULE -- this module MANDATORY-GROUPS { ipv6GeneralGroup, ipv6NotificationGroup } OBJECT ipv6Forwarding MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6DefaultHopLimit MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfDescr MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfIdentifier MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfIdentifierLength MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6IfAdminStatus MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6RouteValid MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object" OBJECT ipv6NetToMediaValid MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write Haskin & Onishi Standards Track [Page 33] RFC 2465 IPv6 MIB: General Group December 1998 access to this object" ::= { ipv6Compliances 1 } ipv6GeneralGroup OBJECT-GROUP OBJECTS { ipv6Forwarding, ipv6DefaultHopLimit, ipv6Interfaces, ipv6IfTableLastChange, ipv6IfDescr, ipv6IfLowerLayer, ipv6IfEffectiveMtu, ipv6IfReasmMaxSize, ipv6IfIdentifier, ipv6IfIdentifierLength, ipv6IfPhysicalAddress, ipv6IfAdminStatus, ipv6IfOperStatus, ipv6IfLastChange, ipv6IfStatsInReceives, ipv6IfStatsInHdrErrors, ipv6IfStatsInTooBigErrors, ipv6IfStatsInNoRoutes, ipv6IfStatsInAddrErrors, ipv6IfStatsInUnknownProtos, ipv6IfStatsInTruncatedPkts, ipv6IfStatsInDiscards, ipv6IfStatsInDelivers, ipv6IfStatsOutForwDatagrams, ipv6IfStatsOutRequests, ipv6IfStatsOutDiscards, ipv6IfStatsOutFragOKs, ipv6IfStatsOutFragFails, ipv6IfStatsOutFragCreates, ipv6IfStatsReasmReqds, ipv6IfStatsReasmOKs, ipv6IfStatsReasmFails, ipv6IfStatsInMcastPkts, ipv6IfStatsOutMcastPkts, ipv6AddrPrefixOnLinkFlag, ipv6AddrPrefixAutonomousFlag, ipv6AddrPrefixAdvPreferredLifetime, ipv6AddrPrefixAdvValidLifetime, ipv6AddrPfxLength, ipv6AddrType, ipv6AddrAnycastFlag, ipv6AddrStatus, ipv6RouteNumber, ipv6DiscardedRoutes, Haskin & Onishi Standards Track [Page 34] RFC 2465 IPv6 MIB: General Group December 1998 ipv6RouteIfIndex, ipv6RouteNextHop, ipv6RouteType, ipv6RouteProtocol, ipv6RoutePolicy, ipv6RouteAge, ipv6RouteNextHopRDI, ipv6RouteMetric, ipv6RouteWeight, ipv6RouteInfo, ipv6RouteValid, ipv6NetToMediaPhysAddress, ipv6NetToMediaType, ipv6IfNetToMediaState, ipv6IfNetToMediaLastUpdated, ipv6NetToMediaValid } STATUS current DESCRIPTION "The IPv6 group of objects providing for basic management of IPv6 entities." ::= { ipv6Groups 1 } ipv6NotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { ipv6IfStateChange } STATUS current DESCRIPTION "The notification that an IPv6 entity is required to implement." ::= { ipv6Groups 2 } END Haskin & Onishi Standards Track [Page 35] RFC 2465 IPv6 MIB: General Group December 1998 6. Acknowledgments This document borrows from MIB works produced by IETF for IPv4-based internets. We would like to thanks the following individuals for constructive and valuable comments: Mike Daniele, Margaret Forsythe, Tim Hartrick, Jean-Pierre Roch, Juergen Schoenwaelder, Frank Solensky, Vivek Venkatraman. 7. References [1] 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. [2] 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. [3] 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. [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Computer Science, May 1990. [5] 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. [6] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994. [7] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Haskin & Onishi Standards Track [Page 36] RFC 2465 IPv6 MIB: General Group December 1998 [8] Narten, T., Nordmark E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [9] Haskin, D., and S. Onishi, "Management Information Base for IP Version 6: ICMPv6 Group", RFC 2466, December 1998. 8. Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information should be employed in such environments. 9. Authors' Addresses Dimitry Haskin Bay Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 EMail: dhaskin@baynetworks.com Steve Onishi Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 EMail: sonishi@baynetworks.com Haskin & Onishi Standards Track [Page 37] RFC 2465 IPv6 MIB: General Group December 1998 10. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Haskin & Onishi Standards Track [Page 38] snmp-mibs-downloader-1.1/mibrfcs/rfc2466.txt0000644000000000000000000006563311402176071015600 0ustar Network Working Group D. Haskin Request for Comments: 2466 S. Onishi Category: Standards Track Bay Networks, Inc. December 1998 Management Information Base for IP Version 6: ICMPv6 Group 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Table of Contents 1. The SNMPv2 Network Management Framework ............. 2 1.1 Object Definitions ................................ 2 2. Overview ............................................ 2 3. The ICMPv6 Group .................................... 3 4. Acknowledgments .................................... 14 5. References .......................................... 14 6. Security Considerations ............................. 15 7. Authors' Addresses................................... 15 8. Full Copyright Statement............................. 16 Haskin & Onishi Standards Track [Page 1] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, described in RFC 1213/STD 17 [3] - the core set of managed objects for the Internet suite of protocols. o RFC 1157/STD 15 [4] and RFC 1905 [5] which define two versions of the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.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. 2. Overview This document is the one in the series of documents that define various MIB object groups for IPv6. These groups are the basic unit of conformance: if the semantics of a group is applicable to an implementation, then it must implement all objects in that group. For example, an implementation must implement the TCP group if and only if it implements the TCP over IPv6 protocol. At minimum, implementations must implement the IPv6 General group [9] as well as the ICMPv6 group defined in this document. This document defines the ICMPv6 group of the IPv6 MIB. Haskin & Onishi Standards Track [Page 2] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 3. The ICMPv6 Group IPV6-ICMP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ipv6IfEntry FROM IPV6-MIB; ipv6IcmpMIB MODULE-IDENTITY LAST-UPDATED "9801082155Z" ORGANIZATION "IETF IPv6 Working Group" CONTACT-INFO " Dimitry Haskin Postal: Bay Networks, Inc. 660 Techology Park Drive. Billerica, MA 01821 US Tel: +1-978-916-8124 E-mail: dhaskin@baynetworks.com Steve Onishi Postal: Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 US Tel: +1-978-916-3816 E-mail: sonishi@baynetworks.com" DESCRIPTION "The MIB module for entities implementing the ICMPv6." ::= { mib-2 56 } -- the ICMPv6 group ipv6IcmpMIBObjects OBJECT IDENTIFIER ::= { ipv6IcmpMIB 1 } -- Per-interface ICMPv6 statistics table ipv6IfIcmpTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6IfIcmpEntry MAX-ACCESS not-accessible Haskin & Onishi Standards Track [Page 3] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 STATUS current DESCRIPTION "IPv6 ICMP statistics. This table contains statistics of ICMPv6 messages that are received and sourced by the entity." ::= { ipv6IcmpMIBObjects 1 } ipv6IfIcmpEntry OBJECT-TYPE SYNTAX Ipv6IfIcmpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ICMPv6 statistics entry containing objects at a particular IPv6 interface. Note that a receiving interface is the interface to which a given ICMPv6 message is addressed which may not be necessarily the input interface for the message. Similarly, the sending interface is the interface that sources a given ICMP message which is usually but not necessarily the output interface for the message." AUGMENTS { ipv6IfEntry } ::= { ipv6IfIcmpTable 1 } Ipv6IfIcmpEntry ::= SEQUENCE { ipv6IfIcmpInMsgs Counter32 , ipv6IfIcmpInErrors Counter32 , ipv6IfIcmpInDestUnreachs Counter32 , ipv6IfIcmpInAdminProhibs Counter32 , ipv6IfIcmpInTimeExcds Counter32 , ipv6IfIcmpInParmProblems Counter32 , ipv6IfIcmpInPktTooBigs Counter32 , ipv6IfIcmpInEchos Counter32 , ipv6IfIcmpInEchoReplies Counter32 , ipv6IfIcmpInRouterSolicits Counter32 , Haskin & Onishi Standards Track [Page 4] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 ipv6IfIcmpInRouterAdvertisements Counter32 , ipv6IfIcmpInNeighborSolicits Counter32 , ipv6IfIcmpInNeighborAdvertisements Counter32 , ipv6IfIcmpInRedirects Counter32 , ipv6IfIcmpInGroupMembQueries Counter32 , ipv6IfIcmpInGroupMembResponses Counter32 , ipv6IfIcmpInGroupMembReductions Counter32 , ipv6IfIcmpOutMsgs Counter32 , ipv6IfIcmpOutErrors Counter32 , ipv6IfIcmpOutDestUnreachs Counter32 , ipv6IfIcmpOutAdminProhibs Counter32 , ipv6IfIcmpOutTimeExcds Counter32 , ipv6IfIcmpOutParmProblems Counter32 , ipv6IfIcmpOutPktTooBigs Counter32 , ipv6IfIcmpOutEchos Counter32 , ipv6IfIcmpOutEchoReplies Counter32 , ipv6IfIcmpOutRouterSolicits Counter32 , ipv6IfIcmpOutRouterAdvertisements Counter32 , ipv6IfIcmpOutNeighborSolicits Counter32 , ipv6IfIcmpOutNeighborAdvertisements Counter32 , ipv6IfIcmpOutRedirects Counter32 , ipv6IfIcmpOutGroupMembQueries Counter32 , ipv6IfIcmpOutGroupMembResponses Counter32 , ipv6IfIcmpOutGroupMembReductions Counter32 Haskin & Onishi Standards Track [Page 5] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 } ipv6IfIcmpInMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ICMP messages received by the interface which includes all those counted by ipv6IfIcmpInErrors. Note that this interface is the interface to which the ICMP messages were addressed which may not be necessarily the input interface for the messages." ::= { ipv6IfIcmpEntry 1 } ipv6IfIcmpInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP messages which the interface received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.)." ::= { ipv6IfIcmpEntry 2 } ipv6IfIcmpInDestUnreachs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Destination Unreachable messages received by the interface." ::= { ipv6IfIcmpEntry 3 } ipv6IfIcmpInAdminProhibs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP destination unreachable/communication administratively prohibited messages received by the interface." ::= { ipv6IfIcmpEntry 4 } ipv6IfIcmpInTimeExcds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Haskin & Onishi Standards Track [Page 6] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 DESCRIPTION "The number of ICMP Time Exceeded messages received by the interface." ::= { ipv6IfIcmpEntry 5 } ipv6IfIcmpInParmProblems OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Parameter Problem messages received by the interface." ::= { ipv6IfIcmpEntry 6 } ipv6IfIcmpInPktTooBigs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Packet Too Big messages received by the interface." ::= { ipv6IfIcmpEntry 7 } ipv6IfIcmpInEchos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Echo (request) messages received by the interface." ::= { ipv6IfIcmpEntry 8 } ipv6IfIcmpInEchoReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Echo Reply messages received by the interface." ::= { ipv6IfIcmpEntry 9 } ipv6IfIcmpInRouterSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Router Solicit messages received by the interface." Haskin & Onishi Standards Track [Page 7] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 ::= { ipv6IfIcmpEntry 10 } ipv6IfIcmpInRouterAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Router Advertisement messages received by the interface." ::= { ipv6IfIcmpEntry 11 } ipv6IfIcmpInNeighborSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Neighbor Solicit messages received by the interface." ::= { ipv6IfIcmpEntry 12 } ipv6IfIcmpInNeighborAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Neighbor Advertisement messages received by the interface." ::= { ipv6IfIcmpEntry 13 } ipv6IfIcmpInRedirects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Redirect messages received by the interface." ::= { ipv6IfIcmpEntry 14 } ipv6IfIcmpInGroupMembQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMPv6 Group Membership Query messages received by the interface." ::= { ipv6IfIcmpEntry 15} ipv6IfIcmpInGroupMembResponses OBJECT-TYPE Haskin & Onishi Standards Track [Page 8] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMPv6 Group Membership Response messages received by the interface." ::= { ipv6IfIcmpEntry 16} ipv6IfIcmpInGroupMembReductions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMPv6 Group Membership Reduction messages received by the interface." ::= { ipv6IfIcmpEntry 17} ipv6IfIcmpOutMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ICMP messages which this interface attempted to send. Note that this counter includes all those counted by icmpOutErrors." ::= { ipv6IfIcmpEntry 18 } ipv6IfIcmpOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP messages which this interface did not send due to problems discovered within ICMP such as a lack of buffers. This value should not include errors discovered outside the ICMP layer such as the inability of IPv6 to route the resultant datagram. In some implementations there may be no types of error which contribute to this counter's value." ::= { ipv6IfIcmpEntry 19 } ipv6IfIcmpOutDestUnreachs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Destination Unreachable Haskin & Onishi Standards Track [Page 9] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 messages sent by the interface." ::= { ipv6IfIcmpEntry 20 } ipv6IfIcmpOutAdminProhibs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of ICMP dest unreachable/communication administratively prohibited messages sent." ::= { ipv6IfIcmpEntry 21 } ipv6IfIcmpOutTimeExcds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Time Exceeded messages sent by the interface." ::= { ipv6IfIcmpEntry 22 } ipv6IfIcmpOutParmProblems OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Parameter Problem messages sent by the interface." ::= { ipv6IfIcmpEntry 23 } ipv6IfIcmpOutPktTooBigs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Packet Too Big messages sent by the interface." ::= { ipv6IfIcmpEntry 24 } ipv6IfIcmpOutEchos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Echo (request) messages sent by the interface." ::= { ipv6IfIcmpEntry 25 } Haskin & Onishi Standards Track [Page 10] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 ipv6IfIcmpOutEchoReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Echo Reply messages sent by the interface." ::= { ipv6IfIcmpEntry 26 } ipv6IfIcmpOutRouterSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Router Solicitation messages sent by the interface." ::= { ipv6IfIcmpEntry 27 } ipv6IfIcmpOutRouterAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Router Advertisement messages sent by the interface." ::= { ipv6IfIcmpEntry 28 } ipv6IfIcmpOutNeighborSolicits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Neighbor Solicitation messages sent by the interface." ::= { ipv6IfIcmpEntry 29 } ipv6IfIcmpOutNeighborAdvertisements OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP Neighbor Advertisement messages sent by the interface." ::= { ipv6IfIcmpEntry 30 } ipv6IfIcmpOutRedirects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Haskin & Onishi Standards Track [Page 11] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 STATUS current DESCRIPTION "The number of Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects." ::= { ipv6IfIcmpEntry 31 } ipv6IfIcmpOutGroupMembQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMPv6 Group Membership Query messages sent." ::= { ipv6IfIcmpEntry 32} ipv6IfIcmpOutGroupMembResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMPv6 Group Membership Response messages sent." ::= { ipv6IfIcmpEntry 33} ipv6IfIcmpOutGroupMembReductions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMPv6 Group Membership Reduction messages sent." ::= { ipv6IfIcmpEntry 34} -- conformance information ipv6IcmpConformance OBJECT IDENTIFIER ::= { ipv6IcmpMIB 2 } ipv6IcmpCompliances OBJECT IDENTIFIER ::= { ipv6IcmpConformance 1 } ipv6IcmpGroups OBJECT IDENTIFIER ::= { ipv6IcmpConformance 2 } -- compliance statements ipv6IcmpCompliance MODULE-COMPLIANCE STATUS current Haskin & Onishi Standards Track [Page 12] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 DESCRIPTION "The compliance statement for SNMPv2 entities which implement ICMPv6." MODULE -- this module MANDATORY-GROUPS { ipv6IcmpGroup } ::= { ipv6IcmpCompliances 1 } ipv6IcmpGroup OBJECT-GROUP OBJECTS { ipv6IfIcmpInMsgs, ipv6IfIcmpInErrors, ipv6IfIcmpInDestUnreachs, ipv6IfIcmpInAdminProhibs, ipv6IfIcmpInTimeExcds, ipv6IfIcmpInParmProblems, ipv6IfIcmpInPktTooBigs, ipv6IfIcmpInEchos, ipv6IfIcmpInEchoReplies, ipv6IfIcmpInRouterSolicits, ipv6IfIcmpInRouterAdvertisements, ipv6IfIcmpInNeighborSolicits, ipv6IfIcmpInNeighborAdvertisements, ipv6IfIcmpInRedirects, ipv6IfIcmpInGroupMembQueries, ipv6IfIcmpInGroupMembResponses, ipv6IfIcmpInGroupMembReductions, ipv6IfIcmpOutMsgs, ipv6IfIcmpOutErrors, ipv6IfIcmpOutDestUnreachs, ipv6IfIcmpOutAdminProhibs, ipv6IfIcmpOutTimeExcds, ipv6IfIcmpOutParmProblems, ipv6IfIcmpOutPktTooBigs, ipv6IfIcmpOutEchos, ipv6IfIcmpOutEchoReplies, ipv6IfIcmpOutRouterSolicits, ipv6IfIcmpOutRouterAdvertisements, ipv6IfIcmpOutNeighborSolicits, ipv6IfIcmpOutNeighborAdvertisements, ipv6IfIcmpOutRedirects, ipv6IfIcmpOutGroupMembQueries, ipv6IfIcmpOutGroupMembResponses, ipv6IfIcmpOutGroupMembReductions } STATUS current DESCRIPTION "The ICMPv6 group of objects providing information specific to ICMPv6." Haskin & Onishi Standards Track [Page 13] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 ::= { ipv6IcmpGroups 1 } END 4. Acknowledgments This document borrows from MIB works produced by IETF for IPv4-based internets. We would like to thanks the following people for constructive and valuable comments: Mike Daniele, Margaret Forsythe, Jean-Pierre Roch, Juergen Schoenwaelder, Vivek Venkatraman. 5. References [1] 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. [2] 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. [3] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [5] 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. [6] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994. [7] Deering, S. and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Haskin & Onishi Standards Track [Page 14] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 [8] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [9] Haskin, D., and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998. 6. Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information should be employed in such environments. 7. Authors' Addresses Dimitry Haskin Bay Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 EMail: dhaskin@baynetworks.com Steve Onishi Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 EMail: sonishi@baynetworks.com Haskin & Onishi Standards Track [Page 15] RFC 2466 IPv6 MIB: ICMPv6 Group December 1998 8. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Haskin & Onishi Standards Track [Page 16] snmp-mibs-downloader-1.1/mibrfcs/rfc2494.txt0000644000000000000000000013415011402176071015570 0ustar Network Working Group D. Fowler, Editor Request for Comments: 2494 Newbridge Networks Category: Standards Track January 1999 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495 [17]), DS3/E3 (RFC 2496 [18]), and the work in progress, SONET/SDH Interface Types. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Table of Contents 1 The SNMP Management Framework ................................ 2 2 Overview ..................................................... 3 2.1 BONDing Terminology ........................................ 3 2.2 Use of ifTable for DS0 Layer ............................... 3 2.3 Using ifStackTable ......................................... 4 2.3.1 Usage of Channelization for DS3, DS1, DS0 ................ 6 2.3.2 Usage of ifIndex Mapping for DS0Bundle ................... 7 3 Overview of the MIB .......................................... 7 3.1 DS0 MIB .................................................... 8 3.2 DS0Bundle MIB .............................................. 8 4 Object Definitions for DS0 ................................... 8 4.1 The DS0 Config Group ....................................... 9 Fowler, Ed. Standards Track [Page 1] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 4.1.1 The DS0 Configuration Table .............................. 9 4.1.2 The DS0 Channel Mapping Table ............................ 12 5 Object Definitions for DS0 Bundle ............................ 15 5.1 The DS0 Bundle Config Group ................................ 15 5.1.1 The DS0 Bundle Table ..................................... 15 5.2 The DS0 Bonding Group ...................................... 18 5.2.1 The DS0 Bonding Table .................................... 18 6 Intellectual Property ........................................ 21 7 Acknowledgments .............................................. 22 8 References ................................................... 22 9 Security Considerations ...................................... 23 10 Author's Address ............................................ 24 11 Full Copyright Statement .................................... 25 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Fowler, Ed. Standards Track [Page 2] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview These objects are used when the particular media being used to realize an interface is a DS0 interface. At present, this applies to these values of the ifType variable in the Internet-standard MIB: ds0 (81) ds0Bundle (82) 2.1. BONDing Terminology Please reference The BONDing Spec [20] for definitions of terms used to describe bonding modes. 2.2. Use of ifTable for DS0 Layer The following items are defined in RFC 2233 [16]. Only the ifGeneralInformationGroup and ifCounterDiscontinuityGroup need to be supported. ifTable Object Use for DS0 Layer ====================================================================== ifIndex Interface index. ifDescr See interfaces MIB [16]. ifType ds0(81) or ds0Bundle(82). ifSpeed 64000 for ds0 (regardless of the setting of robbed bit signalling) or N*64000 for ds0Bundle. ifPhysAddress The value of the Circuit Identifier. If no Circuit Identifier has been assigned this object should have an octet string with zero length. Fowler, Ed. Standards Track [Page 3] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 ifAdminStatus See interfaces MIB [16]. ifOperStatus See interfaces MIB [16]. ifLastChange See interfaces MIB [16]. ifName See interfaces MIB [16]. ifLinkUpDownTrapEnable Set to disabled(2). Supports read-only access. ifHighSpeed Set to rounded ifSpeed/1000000. ifConnectorPresent Set to false(2). 2.3. Using ifStackTable This section describes by example how to use ifStackTable to represent the relationship of ds0 and ds0Bundles with ds1 interfaces. Implementors of the stack table for ds0 and ds0Bundle interfaces should look at the appropriate RFC for the service being stacked on ds0s and ds0Bundles. Examples given below are for illustration purposes only. Example: A Frame Relay Service is being carried on 4 ds0s of a ds1. +---------------------+ | Frame Relay Service | +---------------------+ | +---------------------+ | ds0Bundle | +---------------------+ | | | | +---+ +---+ +---+ +---+ |ds0| |ds0| |ds0| |ds0| +---+ +---+ +---+ +---+ | | | | +---------------------+ | ds1 | +---------------------+ The assignment of the index values could for example be: ifIndex Description 1 FrameRelayService (type 44) 2 ds0Bundle (type 82) 3 ds0 #1 (type 81) Fowler, Ed. Standards Track [Page 4] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 4 ds0 #2 (type 81) 5 ds0 #3 (type 81) 6 ds0 #4 (type 81) 7 ds1 (type 18) The ifStackTable is then used to show the relationships between the various interfaces. ifStackTable Entries HigherLayer LowerLayer 0 1 1 2 2 3 2 4 2 5 2 6 3 7 4 7 5 7 6 7 7 0 In the case where the frameRelayService is using a single ds0, then the ds0Bundle is not required. +---------------------+ | Frame Relay Service | +---------------------+ | +---+ |ds0| +---+ | +---------------------+ | ds1 | +---------------------+ The assignment of the index values could for example be: ifIndex Description 1 FrameRelayService (type 44) 2 ds0 (type 81) 3 ds1 (type 18) The ifStackTable is then used to show the relationships between the various interfaces. Fowler, Ed. Standards Track [Page 5] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 ifStackTable Entries HigherLayer LowerLayer 0 1 1 2 2 3 3 0 2.3.1. Usage of Channelization for DS3, DS1, DS0 An example is given here to explain the channelization objects in the DS3, DS1, and DS0 MIBs to help the implementor use the objects correctly. Treatment of E3 and E1 would be similar, with the number of DS0s being different depending on the framing of the E1. Timeslot 16 is not created for framing types that do not pass data over it. Assume that a DS3 (with ifIndex 1) is channelized into DS1s (without DS2s). The object dsx3Channelization is set to enabledDs1. There will be 28 DS1s in the ifTable. Assume the entries in the ifTable for the DS1s are created in channel order and the ifIndex values are 2 through 29. In the DS1 MIB, there will be an entry in the dsx1ChanMappingTable for each ds1. The entries will be as follows: dsx1ChanMappingTable Entries ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex 1 1 2 1 2 3 ...... 1 28 29 In addition, the DS1s are channelized into DS0s. The object dsx1Channelization is set to enabledDs0 for each DS1. When this object is set to this value, 24 DS0s are created by the agent. There will be 24 DS0s in the ifTable for each DS1. If the dsx1Channelization is set to disabled, the 24 DS0s are destroyed. Assume the entries in the ifTable are created in channel order and the ifIndex values for the DS0s in the first DS1 are 30 through 53. In the DS0 MIB, there will be an entry in the dsx0ChanMappingTable for each DS0. The entries will be as follows: Fowler, Ed. Standards Track [Page 6] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 dsx0ChanMappingTable Entries ifIndex dsx0Ds0ChannelNumber dsx0ChanMappedIfIndex 2 1 30 2 2 31 ...... 2 24 53 2.3.2. Usage of ifIndex Mapping for DS0Bundle An example is given here to explain the ifIndex mapping objects in the DS0Bundle MIB to help the implementor use the objects correctly. Assume that a DS1 (with ifIndex 1) is channelized into DS0s. There will be 24 DS0s in the ifTable. Assume the entries in the ifTable for the DS0s are created in channel order and the ifIndex values are 2 through 25. Now, assume that there are two bundles on the DS1. The first one uses channels 1 and 2. The second uses channels 3 and 4. There will be two ifTable entries for these bundles, with values of 26 and 27 for ifIndex. There will be an entry in the dsx0BundleTable for each bundle. The entries will be as follows: dsx0BundleTable Entries dsx0BundleIndex dsx0BundleIfIndex 1 26 2 27 There will be an entry in the dsx0ConfigTable for each DS0. The entries will be as follows: dsx0ConfigTable Entries ifIndex dsx0Ds0ChannelNumber dsx0Ds0BundleMappedIfIndex 2 1 26 3 2 26 4 3 27 5 4 27 6 5 0 7 6 0 ...... 25 24 0 3. Overview of the MIB This document contains 2 MIB modules, the DS0 MIB and the DS0Bundle MIB. Fowler, Ed. Standards Track [Page 7] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 3.1. DS0 MIB The DS0 MIB is used to represent individual DS0s in a DS1 or E1. Variables in this MIB would be created for each DS0 in the ifTable. This MIB contains the following group: The DS0 Config Group - This group contains configuration information about a particular DS0. 3.2. DS0Bundle MIB The DS0Bundle MIB is used to represent collections of DS0s that are used together to carry data within a DS1/E1 at speeds greater than that of a single DS0. DS0Bundles are created on top of DS0s and are represented that way in the ifStackTable. This MIB contains the following groups: The DS0 Bundle Group - This group contains objects used for creating new ds0Bundles. This group is mandatory. The DS0 Bonding Group - This group contains information about bonding for a ds0Bundle, if bonding is enabled. This group is optional. 4. Object Definitions for DS0 DS0-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF DisplayString, TruthValue FROM SNMPv2-TC ifIndex, InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB; -- This is the MIB module for the DS0 Interface objects. ds0 MODULE-IDENTITY LAST-UPDATED "9807161630Z" ORGANIZATION "IETF Trunk MIB Working Group" CONTACT-INFO " David Fowler Postal: Newbridge Networks Corporation 600 March Road Kanata, Ontario, Canada K2K 2E6 Tel: +1 613 591 3600 Fowler, Ed. Standards Track [Page 8] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 Fax: +1 613 599 3619 E-mail: davef@newbridge.com" DESCRIPTION "The MIB module to describe DS0 interfaces objects." REVISION "9805242010Z" DESCRIPTION "Initial version of the DS0-MIB." ::= { transmission 81 } -- The DS0 Config Group -- Implementation of this group is mandatory for all -- systems that use a DS0 Interface. -- The DS0 Config Group consists of two tables: -- DS0 Configuration Table -- DS0 Channel Mapping Table -- The DS0 Configuration Table dsx0ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx0ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS0 Configuration table." ::= { ds0 1 } dsx0ConfigEntry OBJECT-TYPE SYNTAX Dsx0ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS0 Configuration table. There is an entry in this table for each DS0 interface." INDEX { ifIndex } ::= { dsx0ConfigTable 1 } Dsx0ConfigEntry ::= SEQUENCE { dsx0Ds0ChannelNumber INTEGER, dsx0RobbedBitSignalling TruthValue, dsx0CircuitIdentifier DisplayString, dsx0IdleCode INTEGER, dsx0SeizedCode INTEGER, Fowler, Ed. Standards Track [Page 9] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 dsx0ReceivedCode INTEGER, dsx0TransmitCodesEnable TruthValue, dsx0Ds0BundleMappedIfIndex InterfaceIndexOrZero } dsx0Ds0ChannelNumber OBJECT-TYPE SYNTAX INTEGER(0..31) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the channel number of the ds0 on its DS1/E1." ::= { dsx0ConfigEntry 1 } dsx0RobbedBitSignalling OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates if Robbed Bit Signalling is turned on or off for a given ds0. This only applies to DS0s on a DS1 link. For E1 links the value is always off (false)." ::= { dsx0ConfigEntry 2 } dsx0CircuitIdentifier OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains the transmission vendor's circuit identifier, for the purpose of facilitating troubleshooting." ::= { dsx0ConfigEntry 3 } dsx0IdleCode OBJECT-TYPE SYNTAX INTEGER(0..15) MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains the code transmitted in the ABCD bits when the ds0 is not connected and dsx0TransmitCodesEnable is enabled. The object is a bitmap and the various bit positions are: 1 D bit 2 C bit 4 B bit 8 A bit" Fowler, Ed. Standards Track [Page 10] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 ::= { dsx0ConfigEntry 4 } dsx0SeizedCode OBJECT-TYPE SYNTAX INTEGER(0..15) MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains the code transmitted in the ABCD bits when the ds0 is connected and dsx0TransmitCodesEnable is enabled. The object is a bitmap and the various bit positions are: 1 D bit 2 C bit 4 B bit 8 A bit" ::= { dsx0ConfigEntry 5 } dsx0ReceivedCode OBJECT-TYPE SYNTAX INTEGER(0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the code being received in the ABCD bits. The object is a bitmap and the various bit positions are: 1 D bit 2 C bit 4 B bit 8 A bit" ::= { dsx0ConfigEntry 6 } dsx0TransmitCodesEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines if the idle and seized codes are transmitted. If the value of this object is true then the codes are transmitted." ::= { dsx0ConfigEntry 7 } dsx0Ds0BundleMappedIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the ifIndex value assigned by the agent for the ds0Bundle(82) ifEntry to Fowler, Ed. Standards Track [Page 11] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 which the given ds0(81) ifEntry may belong. If the given ds0(81) ifEntry does not belong to any ds0Bundle(82) ifEntry, then this object has a value of zero. While this object provides information that can also be found in the ifStackTable, it provides this same information with a single table lookup, rather than by walking the ifStackTable to find the possibly non-existent ds0Bundle(82) ifEntry that may be stacked above the given ds0(81) ifTable entry." ::= { dsx0ConfigEntry 8 } -- The DS0 Channel Mapping Table dsx0ChanMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx0ChanMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS0 Channel Mapping table. This table maps a DS0 channel number on a particular DS1/E1 into an ifIndex." ::= { ds0 3 } dsx0ChanMappingEntry OBJECT-TYPE SYNTAX Dsx0ChanMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS0 Channel Mapping table. There is an entry in this table corresponding to each ds0 ifEntry within any interface that is channelized to the individual ds0 ifEntry level. This table is intended to facilitate mapping from channelized interface / channel number to DS0 ifEntry. (e.g. mapping (DS1 ifIndex, DS0 Channel Number) -> ifIndex) While this table provides information that can also be found in the ifStackTable and dsx0ConfigTable, it provides this same information with a single table lookup, rather than by walking the ifStackTable to find the various constituent ds0 ifTable entries, and testing various Fowler, Ed. Standards Track [Page 12] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 dsx0ConfigTable entries to check for the entry with the applicable DS0 channel number." INDEX { ifIndex, dsx0Ds0ChannelNumber } ::= { dsx0ChanMappingTable 1 } Dsx0ChanMappingEntry ::= SEQUENCE { dsx0ChanMappedIfIndex InterfaceIndex } dsx0ChanMappedIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the ifIndex value assigned by the agent for the individual ds0 ifEntry that corresponds to the given DS0 channel number (specified by the INDEX element dsx0Ds0ChannelNumber) of the given channelized interface (specified by INDEX element ifIndex)." ::= { dsx0ChanMappingEntry 1 } -- conformance information ds0Conformance OBJECT IDENTIFIER ::= { ds0 2 } ds0Groups OBJECT IDENTIFIER ::= { ds0Conformance 1 } ds0Compliances OBJECT IDENTIFIER ::= { ds0Conformance 2 } -- compliance statements ds0Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DS0 interfaces." MODULE -- this module MANDATORY-GROUPS { ds0ConfigGroup } OBJECT dsx0RobbedBitSignalling MIN-ACCESS read-only DESCRIPTION "The ability to set RBS is not required." OBJECT dsx0CircuitIdentifier MIN-ACCESS read-only DESCRIPTION Fowler, Ed. Standards Track [Page 13] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 "The ability to set the circuit identifier is not required." OBJECT dsx0IdleCode MIN-ACCESS read-only DESCRIPTION "The ability to set the idle code is not required." OBJECT dsx0SeizedCode MIN-ACCESS read-only DESCRIPTION "The ability to set the seized code is not required." OBJECT dsx0TransmitCodesEnable MIN-ACCESS read-only DESCRIPTION "The ability to enable and disable the transmitting of idle and seized codes is not required." ::= { ds0Compliances 1 } -- units of conformance ds0ConfigGroup OBJECT-GROUP OBJECTS { dsx0Ds0ChannelNumber, dsx0RobbedBitSignalling, dsx0CircuitIdentifier, dsx0IdleCode, dsx0SeizedCode, dsx0ReceivedCode, dsx0TransmitCodesEnable, dsx0Ds0BundleMappedIfIndex, dsx0ChanMappedIfIndex } STATUS current DESCRIPTION "A collection of objects providing configuration information applicable to all DS0 interfaces." ::= { ds0Groups 1 } END Fowler, Ed. Standards Track [Page 14] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 5. Object Definitions for DS0 Bundle DS0BUNDLE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF DisplayString, RowStatus, TestAndIncr FROM SNMPv2-TC ifIndex, InterfaceIndex FROM IF-MIB; -- This is the MIB module for the DS0Bundle Interface -- objects. ds0Bundle MODULE-IDENTITY LAST-UPDATED "9807161630Z" ORGANIZATION "IETF Trunk MIB Working Group" CONTACT-INFO " David Fowler Postal: Newbridge Networks Corporation 600 March Road Kanata, Ontario, Canada K2K 2E6 Tel: +1 613 591 3600 Fax: +1 613 599 3619 E-mail: davef@newbridge.com" DESCRIPTION "The MIB module to describe DS0 Bundle interfaces objects." REVISION "9805242010Z" DESCRIPTION "Initial version of the DS0BUNDLE-MIB." ::= { transmission 82 } -- -- The DS0 Bundle Config Group -- -- Implementation of this group is mandatory for all -- systems that use a DS0Bundle Interface. -- -- The DS0 Bundle Config Group consists of one table: -- DS0 Bundle Table -- The DS0 Bundle Table Fowler, Ed. Standards Track [Page 15] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 dsx0BundleNextIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assist the manager in selecting a value for dsx0BundleIndex. Because this object is of syntax TestAndIncr (see the SNMPv2-TC document, RFC 1903) it can also be used to avoid race conditions with multiple managers trying to create rows in the table. If the result of the SET for dsx0BundleNextIndex is not success, this means the value has been changed from index (i.e. another manager used the value), so a new value is required. The algorithm is: done = false while done == false index = GET (dsx0BundleNextIndex.0) SET (dsx0BundleNextIndex.0=index) if (set failed) done = false else SET(dsx0BundleRowStatus.index=createAndGo) if (set failed) done = false else done = true other error handling" ::= { ds0Bundle 2 } dsx0BundleTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx0BundleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There is an row in this table for each ds0Bundle in the system. This table can be used to (indirectly) create rows in the ifTable with ifType = 'ds0Bundle(82)'." ::= { ds0Bundle 3 } dsx0BundleEntry OBJECT-TYPE SYNTAX Dsx0BundleEntry MAX-ACCESS not-accessible STATUS current Fowler, Ed. Standards Track [Page 16] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 DESCRIPTION "There is a row in entry in this table for each ds0Bundle interface." INDEX { dsx0BundleIndex } ::= { dsx0BundleTable 1 } Dsx0BundleEntry ::= SEQUENCE { dsx0BundleIndex INTEGER, dsx0BundleIfIndex InterfaceIndex, dsx0BundleCircuitIdentifier DisplayString, dsx0BundleRowStatus RowStatus } dsx0BundleIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for a ds0Bundle. This is not the same value as ifIndex. This table is not indexed by ifIndex because the manager has to choose the index in a createable row and the agent must be allowed to select ifIndex values." ::= { dsx0BundleEntry 1 } dsx0BundleIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value the agent selected for the (new) ds0Bundle interface." ::= { dsx0BundleEntry 2 } dsx0BundleCircuitIdentifier OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This variable contains the transmission vendor's circuit identifier, for the purpose of facilitating troubleshooting." ::= { dsx0BundleEntry 3 } dsx0BundleRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Fowler, Ed. Standards Track [Page 17] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 STATUS current DESCRIPTION "This object is used to create and delete rows in this table." ::= { dsx0BundleEntry 4 } -- The DS0 Bonding Group -- Implementation of this group is optional for all -- systems that use a DS0Bundle Interface. -- The DS0 Bonding Group consists of one table: -- DS0 Bonding Table -- The DS0 Bonding Table dsx0BondingTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx0BondingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS0 Bonding table." ::= { ds0Bundle 1 } dsx0BondingEntry OBJECT-TYPE SYNTAX Dsx0BondingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS0 Bonding table. There is a row in this table for each DS0Bundle interface." INDEX { ifIndex } ::= { dsx0BondingTable 1 } Dsx0BondingEntry ::= SEQUENCE { dsx0BondMode INTEGER, dsx0BondStatus INTEGER, dsx0BondRowStatus RowStatus } dsx0BondMode OBJECT-TYPE SYNTAX INTEGER { none(1), other(2), mode0(3), mode1(4), mode2(5), Fowler, Ed. Standards Track [Page 18] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 mode3(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates which BONDing mode is used, if any, for a ds0Bundle. Mode0 provides parameter and number exchange with no synchronization. Mode 1 provides parameter and number exchange. Mode 1 also provides synchronization during initialization but does not include inband monitoring. Mode 2 provides all of the above plus inband monitoring. Mode 2 also steals 1/64th of the bandwidth of each channel (thus not supporting n x 56/64 kbit/s data channels for most values of n). Mode 3 provides all of the above, but also provides n x 56/64 kbit/s data channels. Most common implementations of Mode 3 add an extra channel to support the inband monitoring overhead. ModeNone should be used when the interface is not performing bandwidth-on-demand." ::= { dsx0BondingEntry 1 } dsx0BondStatus OBJECT-TYPE SYNTAX INTEGER { idle(1), callSetup(2), dataTransfer(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the current status of the bonding call using this ds0Bundle. idle(1) should be used when the bonding mode is set to none(1)." ::= { dsx0BondingEntry 2 } dsx0BondRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create new rows in this table, modify existing rows, and to delete existing rows." ::= { dsx0BondingEntry 3 } Fowler, Ed. Standards Track [Page 19] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 -- conformance information ds0BundleConformance OBJECT IDENTIFIER ::= { ds0Bundle 4 } ds0BundleGroups OBJECT IDENTIFIER ::= { ds0BundleConformance 1 } ds0BundleCompliances OBJECT IDENTIFIER ::= { ds0BundleConformance 2 } -- compliance statements ds0BundleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DS0Bundle interfaces." MODULE -- this module MANDATORY-GROUPS {ds0BundleConfigGroup } GROUP ds0BondingGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS0Bundle Interface." OBJECT dsx0BundleRowStatus SYNTAX INTEGER { active(1), createAndGo(4), destroy(6) } MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object, and only three of the six enumerated values for the RowStatus textual convention need be supported. Only supporting createAndGo for a creation process prevents the manager from creating an inactive row in the ds0BundleTable. Inactive rows in the ds0BundleTable do not make sense." OBJECT dsx0BundleCircuitIdentifier MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET Fowler, Ed. Standards Track [Page 20] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 operation to this object." ::= { ds0BundleCompliances 1 } -- units of conformance ds0BondingGroup OBJECT-GROUP OBJECTS { dsx0BondMode, dsx0BondStatus, dsx0BondRowStatus } STATUS current DESCRIPTION "A collection of objects providing configuration information applicable to all DS0 interfaces." ::= { ds0BundleGroups 1 } ds0BundleConfigGroup OBJECT-GROUP OBJECTS { dsx0BundleNextIndex, dsx0BundleIfIndex, dsx0BundleCircuitIdentifier, dsx0BundleRowStatus } STATUS current DESCRIPTION "A collection of objects providing the ability to create a new ds0Bundle in the ifTable as well as configuration information about the ds0Bundle." ::= { ds0BundleGroups 2 } END 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Fowler, Ed. Standards Track [Page 21] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments This document was produced by the Trunk MIB Working Group. 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] 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. [6] 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. [7] 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. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. Fowler, Ed. Standards Track [Page 22] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [17] Fowler D., "Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types", RFC 2495, January 1999. [18] Fowler, D., "Definitions of Managed Objects for the DS3/E3 Interface Types", RFC 2496, January 1999. [19] Brown, T., and K. Tesink, "Definitions of Managed Objects for the SONET/SDH Interface Type", Work in Progress. [20] Sharp, H. (Editor), "Interoperability Requirements for Nx56/64 kbit/s Calls", BONDING Spec Version 1.0, BONDING Consortium, Sept 1992. 9. Security Considerations SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended. Fowler, Ed. Standards Track [Page 23] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. Setting the following objects to an inappropriate value can cause loss of traffic. In the case of dsx0RobbedBitSignalling, for example, the nature of the traffic flowing on the DS0 can be affected. dsx0RobbedBitSignalling dsx0IdleCode dsx0SeizedCode dsx0TransmitCodesEnable dsx0BundleRowStatus dsx0BondMode dsx0BondRowStatus Setting the following objects is mischievous, but not harmful to traffic. dsx0CircuitIdentifier dsx0BundleNextIndex 10. Author's Address David Fowler Newbridge Networks 600 March Road Kanata, Ontario, Canada K2K 2E6 Phone: (613) 599-3600, ext 6559 EMail: davef@newbridge.com Fowler, Ed. Standards Track [Page 24] RFC 2494 DSO MIB / DSOBUNDLE MIB January 1999 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Fowler, Ed. Standards Track [Page 25] snmp-mibs-downloader-1.1/mibrfcs/rfc2512.txt0000644000000000000000000007067711402176071015574 0ustar Network Working Group K. McCloghrie Request for Comments: 2512 Cisco Systems, Inc. Category: Standards Track J. Heinanen Telia Finland, Inc. W. Greene MCI Telecommunications Corp. A. Prasad Cisco Systems, Inc. February 1999 Accounting Information for ATM Networks 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Introduction ................................................... 1 2 The SNMP Network Management Framework .......................... 2 3 Overview ....................................................... 3 4 Definitions .................................................... 3 5 Acknowledgements ...............................................12 6 References .....................................................12 7 Security Considerations ........................................13 8 IANA Considerations ............................................13 9 Authors' Addresses .............................................14 10 Full Copyright Statement ......................................15 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. A separate memo [16] defines managed objects, in a manner independent of the type of network, for controlling the selection, collection and storage of accounting information into files for later retrieval via a file transfer protocol. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. McCloghrie, et. al. Standards Track [Page 1] RFC 2512 Accounting Information for ATM Networks February 1999 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. McCloghrie, et. al. Standards Track [Page 2] RFC 2512 Accounting Information for ATM Networks February 1999 3. Overview In [16], the items of accounting data to be collected are specified as a set of objects. Which objects are contained in such a set is selectable by an administrator through the specification of one or more (subtree, list) tuples, where the set of objects to be collected is the union of the subsets specified by each tuple: 'subtree' specifies a OBJECT IDENTIFIER value such that every object in the subset is named by the subtree's value appended with a single additional sub-identifier. 'list' specifies an OCTET STRING value, such that if the N-th bit of the string's value is set then the the subset contains the object named by appending N as a single additional sub- identifier to the subtree. This memo specifies such a subtree containing a set of objects defining items of accounting information which are applicable to ATM connections. Note that all of the objects defined here have a MAX-ACCESS clause of not-accessible, since their purpose is not to be read/written by SNMP, but rather, to be the syntax and semantics of the set of information which can be represented within a single (subtree, list) tuple. 4. Definitions ATM-ACCOUNTING-INFORMATION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, Integer32, Counter64 FROM SNMPv2-SMI DisplayString, DateAndTime FROM SNMPv2-TC AtmAddr FROM ATM-TC-MIB; atmAccountingInformationMIB MODULE-IDENTITY LAST-UPDATED "9611052000Z" ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO " Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 5260 Email: kzm@cisco.com" McCloghrie, et. al. Standards Track [Page 3] RFC 2512 Accounting Information for ATM Networks February 1999 DESCRIPTION "The MIB module for identifying items of accounting information which are applicable to ATM connections." ::= { mib-2 59 } atmAcctngMIBObjects OBJECT IDENTIFIER ::= { atmAccountingInformationMIB 1 } -- Definitions of objects for use in specifying ATM accounting -- data to be collected atmAcctngDataObjects OBJECT-IDENTITY STATUS current DESCRIPTION "This identifier defines a subtree under which various objects are defined such that a set of objects to be collected as ATM accounting data can be specified as a (subtree, list) tuple using this identifier as the subtree." ::= { atmAcctngMIBObjects 1 } -- Objects defined under the atmAcctngDataObjects subtree -- -- In each case the semantics of the object are interpreted with -- respect to the creation/storage of an accounting record for a -- particular connection on a particular interface. atmAcctngConnectionType OBJECT-TYPE SYNTAX INTEGER { pvc(1), pvp(2), svcIncoming(3), svcOutgoing(4), svpIncoming(5), svpOutgoing(6), spvcInitiator(7), spvcTarget(8), spvpInitiator(9), spvpTarget(10) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of connection." ::= { atmAcctngDataObjects 1 } atmAcctngCastType OBJECT-TYPE SYNTAX INTEGER { p2p(1), p2mp(2) } MAX-ACCESS not-accessible McCloghrie, et. al. Standards Track [Page 4] RFC 2512 Accounting Information for ATM Networks February 1999 STATUS current DESCRIPTION "An indication of whether the connection is point-to-point or point-to-multipoint." ::= { atmAcctngDataObjects 2 } atmAcctngIfName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "A textual name for the interface on which the data for the connection was collected. If the local SNMP agent supports the object ifName, the value of this object must be identical to that of ifName in the conceptual row of the ifTable corresponding to this interface." ::= { atmAcctngDataObjects 3 } atmAcctngIfAlias OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 'alias' name for the interface as specified by a network manager, e.g., via a management set operation to modify the relevant instance of the ifAlias object. Note that in contrast to ifIndex, ifAlias provides a non-volatile 'handle' for the interface, the value of which is retained across agent reboots." ::= { atmAcctngDataObjects 4 } atmAcctngVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI used for the connection." ::= { atmAcctngDataObjects 5 } atmAcctngVci OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI used for the connection." ::= { atmAcctngDataObjects 6 } atmAcctngCallingParty OBJECT-TYPE McCloghrie, et. al. Standards Track [Page 5] RFC 2512 Accounting Information for ATM Networks February 1999 SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's calling party. If unknown (e.g., for a PVC), then the value of this object is the zero-length string." ::= { atmAcctngDataObjects 7 } atmAcctngCalledParty OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's called party. If unknown (e.g., for a PVC), then the value of this object is the zero-length string." ::= { atmAcctngDataObjects 8 } atmAcctngCallReference OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..3)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's call reference value (e.g., from Q.2931). If unknown (e.g., for a PVC), then the value of this object is the zero-length string." ::= { atmAcctngDataObjects 9 } atmAcctngStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time when the connection was established." ::= { atmAcctngDataObjects 10 } atmAcctngCollectionTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time at which the data in this record was collected." ::= { atmAcctngDataObjects 11 } atmAcctngCollectMode OBJECT-TYPE SYNTAX INTEGER { onRelease(1), periodically(2), McCloghrie, et. al. Standards Track [Page 6] RFC 2512 Accounting Information for ATM Networks February 1999 onCommand(3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The reason why this connection data was collected." ::= { atmAcctngDataObjects 12 } atmAcctngReleaseCause OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the connection data was collected because of the release of an SVC, then this is the cause code in the Release message for the connection; otherwise, this object has the value zero." ::= { atmAcctngDataObjects 13 } atmAcctngServiceCategory OBJECT-TYPE SYNTAX INTEGER { other(1), cbr(2), vbrRt(3), vbrNrt(4), abr(5), ubr(6), unknown(7) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's service category." ::= { atmAcctngDataObjects 14 } atmAcctngTransmittedCells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of cells, including OAM cells, transmitted by this switch on this connection." ::= { atmAcctngDataObjects 15 } atmAcctngTransmittedClp0Cells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of cells with CLP=0, including OAM cells, transmitted by this switch on this connection." ::= { atmAcctngDataObjects 16 } atmAcctngReceivedCells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible McCloghrie, et. al. Standards Track [Page 7] RFC 2512 Accounting Information for ATM Networks February 1999 STATUS current DESCRIPTION "The number of cells, including OAM cells, received by this switch on this connection." ::= { atmAcctngDataObjects 17 } atmAcctngReceivedClp0Cells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of cells with CLP=0, including OAM cells, received by this switch on this connection." ::= { atmAcctngDataObjects 18 } atmAcctngTransmitTrafficDescriptorType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The traffic descriptor type (as defined in RFC 1695 and its successors) in the direction in which the switch transmits cells on the connection." REFERENCE "See atmTrafficDescriptorTypes in ATM-MIB.my in RFC 1695 and its successors." ::= { atmAcctngDataObjects 19 } atmAcctngTransmitTrafficDescriptorParam1 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 20 } atmAcctngTransmitTrafficDescriptorParam2 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The second traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." McCloghrie, et. al. Standards Track [Page 8] RFC 2512 Accounting Information for ATM Networks February 1999 ::= { atmAcctngDataObjects 21 } atmAcctngTransmitTrafficDescriptorParam3 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The third traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 22 } atmAcctngTransmitTrafficDescriptorParam4 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fourth traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 23 } atmAcctngTransmitTrafficDescriptorParam5 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fifth traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 24 } atmAcctngReceiveTrafficDescriptorType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The traffic descriptor type (as defined in RFC 1695 and its successors) in the direction in which this switch receives cells on this connection." REFERENCE "See atmTrafficDescriptorTypes in ATM-MIB.my in RFC 1695 and its successors." ::= { atmAcctngDataObjects 25 } McCloghrie, et. al. Standards Track [Page 9] RFC 2512 Accounting Information for ATM Networks February 1999 atmAcctngReceiveTrafficDescriptorParam1 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 26 } atmAcctngReceiveTrafficDescriptorParam2 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The second traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 27 } atmAcctngReceiveTrafficDescriptorParam3 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The third traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 28 } atmAcctngReceiveTrafficDescriptorParam4 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fourth traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 29 } atmAcctngReceiveTrafficDescriptorParam5 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current McCloghrie, et. al. Standards Track [Page 10] RFC 2512 Accounting Information for ATM Networks February 1999 DESCRIPTION "The fifth traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 30 } atmAcctngCallingPartySubAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's calling party sub-address. If the connection has no calling party sub-address, or it's value is unknown, then the value of this object is the zero-length string." ::= { atmAcctngDataObjects 31 } atmAcctngCalledPartySubAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's called party sub-address. If the connection has no called party sub-address, or it's value is unknown, then the value of this object is the zero-length string." ::= { atmAcctngDataObjects 32 } atmAcctngRecordCrc16 OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of the CRC-16 checksum (as defined by ISO 3309 (HDLC) and/or ITU X.25) calculated over the accounting record containing this object. While the mechanism for calculating/encoding the checksum value is specific to the method of encoding the accounting record, an accounting record containing this object is typically generated by initializing the value of this object to the all-zeros string ('0000'H), with the location of these zeros being saved. After generating the record, the checksum is calculated over the whole connection record and then the all-zeros value is overwritten (at the saved location) by the calculated value of the checksum." ::= { atmAcctngDataObjects 33 } McCloghrie, et. al. Standards Track [Page 11] RFC 2512 Accounting Information for ATM Networks February 1999 END 5. Acknowledgements The comments of the IETF's AToM MIB Working Group are acknowledged. 6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] 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. [6] 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. [7] 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. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. McCloghrie, et. al. Standards Track [Page 12] RFC 2512 Accounting Information for ATM Networks February 1999 [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks", RFC 2513, February 1999. [17] Noto, M., Spiegel, E. and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. 7. Security Considerations This MIB module defines data items for potential use as accounting information. Each of these data items is only accessible through a collected accounting file. After being collected, the accounting data should be protected against modification or unauthorized deletion. 8. IANA Considerations Prior to publication of this memo as an RFC, IANA is requested to make a suitable OBJECT IDENTIFIER assignment. McCloghrie, et. al. Standards Track [Page 13] RFC 2512 Accounting Information for ATM Networks February 1999 9. Authors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134 Phone: +1 408 526 5260 EMail: kzm@cisco.com Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland Phone +358 303 944 808 EMail: jh@telia.fi Wedge Greene MCI Telecommunications Corporation 901 International Parkway Richardson, Texas 75081 Phone: 214-498-1232 or 972-729-1232 EMail: wedge.greene@mci.com Anil Prasad Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134 Phone: +1 408 525-7209 EMail: aprasad@cisco.com McCloghrie, et. al. Standards Track [Page 14] RFC 2512 Accounting Information for ATM Networks February 1999 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McCloghrie, et. al. Standards Track [Page 15] snmp-mibs-downloader-1.1/mibrfcs/rfc2513.txt0000644000000000000000000016656511402176071015577 0ustar Network Working Group K. McCloghrie Request for Comments: 2513 Cisco Systems, Inc. Category: Standards Track J. Heinanen Telia Finland, Inc. W. Greene MCI Telecommunications Corp. A. Prasad Cisco Systems, Inc. February 1999 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Introduction .................................................... 2 2 The SNMP Network Management Framework ........................... 2 3 Overview ........................................................ 3 3.1 Operational Model ............................................. 3 3.2 Selection of Accounting Data .................................. 5 3.3 Format of Collection File ..................................... 6 4 Definitions ..................................................... 9 5 Acknowledgements ................................................25 6 References ......................................................25 7 Security Considerations .........................................27 8 IANA Considerations .............................................27 9 Authors' Addresses ..............................................28 10 Full Copyright Statement .......................................29 McCloghrie, et. al. Standards Track [Page 1] RFC 2513 Connection-Oriented Accounting MIB February 1999 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection- oriented networks such as ATM. The accounting data is collected into files for later retrieval via a file transfer protocol. For information on data which can be collected for ATM networks, see [19]. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. McCloghrie, et. al. Standards Track [Page 2] RFC 2513 Connection-Oriented Accounting MIB February 1999 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview In some connection-oriented network environments, there is a need for the network administrator to be able to collect accounting data on the usage of bandwidth/resources by connections (e.g., ATM connections) within the network. Data collection should be available for switched virtual connections (SVCs and SVPs), and permanent virtual connections (PVCs and PVPs), including soft-permanent virtual connections (SPVCCs and SPVPCs). This need exists for ATM networks, and may well exist for other connection-oriented networks, such as Frame Relay. The potential quantity of such accounting information is such that it is not, in general, feasible to retrieve the information via SNMP. A better method is to store the collected accounting information in a file which can be subsequently retrieved via a file transfer protocol. It is, however, appropriate to provide management control of the selection and collection of such accounting data via SNMP. This memo describes a MIB module which provides such control in a manner independent of the type of network. One or more other documents provide definitions of particular items of accounting data which can be selected; for example, a particular set of data items which can be collected for ATM networks is specified in [19]. 3.1. Operational Model The requirement is for switches (e.g., ATM switches) to collect data concerning the connections which are routed across some subset of their interfaces (e.g., ATM UNI and/or NNI interfaces). The collected data is stored into one or more "files". The use of multiple files allows, for example, the data collected for PVCs to be different from that collected for SVCs. In order to retrieve the data currently being stored in a file, the administrator instructs the switch to terminate the collection of data into that file, and start collecting data into a new file. McCloghrie, et. al. Standards Track [Page 3] RFC 2513 Connection-Oriented Accounting MIB February 1999 After this operation, the data in the old file is available for retrieval via file transfer. A collection file is defined to have a maximum size. When the size of the file currently being collected exceeds a threshold percentage of that maximum size, an SNMP notification (e.g., a trap) can be optionally generated. An SNMP notification might also be generated if the file reaches its maximum size. The accounting data collected for each connection consists of a set of objects and their values. The set of objects and their values are collected on one or more of the following occasions: (1) on the release (termination) of a connection optionally including failed connection attempts; (2) for each active connection (having a particular minimum age) on a periodic basis; (3) for each active connection (having a particular minimum age) when so commanded by a management application. While collecting data to be stored in a particular file, the same set of objects is collected for each connection on each occasion. Having the same set of objects stored on each occasion allows the optimization of storing only the values of those objects. This results in a significantly smaller file size, since it allows the names of the objects to be stored once and only once at the beginning of the file, rather than having to store every value as a (name, value) pair. Two modes of agent behaviour are allowed on the event of a file reaching its maximum size: (1) management application in control: The agent does not automatically swap to a new file; rather, it discards newly collected data until the management application subsequently instructs it to swap to a new file. Before swapping to a new file, the name of the file into which data is currently being collected is an implementation issue of no concern to an NM application; after swapping to a new file, the name of the file available for retrieval is as specified by the controlling MIB objects. This behaviour allows the application to know exactly how many files need to be retrieved and their names without having to perform any type of file directory operation, but also results in the possibility that data will be discarded if the application does not instruct the agent to swap McCloghrie, et. al. Standards Track [Page 4] RFC 2513 Connection-Oriented Accounting MIB February 1999 within the required time frame. (2) agent automatically swaps to new file: The agent terminates collection into the current (full) file, and begins collecting data into a new version of the same base file name. This behaviour aims to avoid loss of data by assuming that additional storage space is actually available to create a new version of the file. To support this behaviour, files are named using suffixes, such that when the current version of the file becomes full, the agent begins collecting data into a file with the same base file-name but with an incremented (or otherwise modified) suffix. This requires the application to perform file directory operations prior to retrieving completed files in order to know how many and which suffixes have been used. With either behaviour, any completed file must be an integral number of connection records (see below). When a file reaches its maximum size, collection into that file is terminated either immediately before or immediately after storing the whole of the current connection record into the file. The former causes the file to be just less than its maximum size, and the latter causes the file to be just greater than its maximum size. 3.2. Selection of Accounting Data The items of accounting data to be collected are specified as a set of objects. Which objects are contained in such a set is selectable by an administrator through the specification of one or more (subtree, list) tuples, where the set of objects to be collected is the union of the subsets specified by each tuple: 'subtree' specifies an OBJECT IDENTIFIER value such that every object in the subset is named by the subtree's value appended with a single additional sub-identifier. 'list' specifies an OCTET STRING value, such that if the N-th bit of the string's value is set then the the subset contains the object named by appending N as a single additional sub- identifier to the subtree. The rationale for defining each subset as a (subtree,list) tuple is that one and only one OBJECT IDENTIFIER and one OCTET STRING is needed to define the subset of objects. This simplifies the MIB mechanisms needed for selection: an NM application needs to create only one conceptual row in a MIB table for each subset (rather than needing to create a conceptual row in a table for each and every McCloghrie, et. al. Standards Track [Page 5] RFC 2513 Connection-Oriented Accounting MIB February 1999 object in the set). The number of tuples supported by a particular switch is an implementation choice. One possibility is to support two (subtree, list) tuples so that one such tuple can specify a standard 'subtree' (e.g., the atmAcctngDataObjects subtree defined in [19]), and the second tuple can specify an enterprise-specific 'subtree'; this would allow the selected set of objects to be the union of a set of standard objects and a set of enterprise-defined objects. 3.3. Format of Collection File A collection file generated by this process contains the values of MIB objects defined using the SMIv2. The standard way to encode the values of SNMP MIB objects in a device-independent manner is through the use of ASN.1's Basic Encoding Rules (BER) [18]. Thus, the standard format of an accounting file is defined here using the same adapted subset of ASN.1 [17] as the SMIv2. The file consists of a set of header information followed by a sequence of zero or more collection records. The header information identifies (via sysName [16]) the switch which collected the data, the date and time at which the collection in to this file started, and the sequence of one or more (subtree, list) tuples identifying the objects whose values are contained in each connection record. The header information also includes a textual description of the data contained in the file. Each connection record contains a sequence of values for each identified tuple, in the same order as the tuples are identified in the header information. For each tuple, the sequence of values are in ascending order of the sub-identifier which identifies them within the subtree. Formally, an accounting file is an ASN.1 value with the following syntax: File ::= [1] IMPLICIT SEQUENCE { -- header information sysName -- name of the switch DisplayString, description -- textual description of the collection DisplayString, startTime -- start time of the collection McCloghrie, et. al. Standards Track [Page 6] RFC 2513 Connection-Oriented Accounting MIB February 1999 DateAndTime, SEQUENCE OF { -- sequence of (subtree, list) tuples SEQUENCE { subtree OBJECT IDENTIFIER, list OCTET STRING } } -- sequence of connection records SEQUENCE OF { -- each record containing a sequence SEQUENCE OF { -- per identified tuple SEQUENCE OF { -- each per-tuple sequence containing value -- a sequence of object values ObjectSyntax } } } } where: (1) the value of the sysName component is that of the sysName object in the System group [16]. (2) each (subtree, list) specifies the set of objects contained in that tuple's sequence within each and every connection record. (3) the tuples' sequences within each connection record occur in the same order as the (subtree, list) tuples occur in the header information. (4) the object values within each connection record occur in the same order as they are represented by the bits in the corresponding list value. (5) ObjectSyntax is defined by the SMIv2 [5]. (6) One particular category of object values deserves special attention: an object defined to hold the checksum value of an accounting record (e.g., atmAcctngRecordCrc16, defined in [19]). An object in this category will generally have a SYNTAX of a fixed-length OCTET STRING, and have its value initialized to the string of all zeros when composing the accounting record containing it, with the location of these zeros being saved. McCloghrie, et. al. Standards Track [Page 7] RFC 2513 Connection-Oriented Accounting MIB February 1999 Once the record is generated, the checksum is calculated over the whole connection record (including the starting SEQUENCE OF and the trailing end-of-contents octets, if used), and then the zeros are overwritten (at the saved location) by the calculated value of the checksum. The encoding of the above syntax using the Basic Encoding Rules is the same as defined by the SNMPv2 [10], with the following exception: - when encoding the length field for a structured type, i.e., a SEQUENCE or SEQUENCE OF, the indefinite form encoding is permitted. For example, the file containing the data: [1] IMPLICIT SEQUENCE a1 80 OCTET STRING 04 09 73 77 69 74 63 68 2d 31 32 OCTET STRING 04 0a 41 63 63 6f 75 6e 74 69 6e 67 OCTET STRING 04 08 07 cc 07 14 10 05 00 00 SEQUENCE OF 30 0e SEQUENCE 30 0c OBJECT IDENTIFIER 06 07 2b 06 01 03 7f 01 01 OCTET STRING 04 01 c0 SEQUENCE OF 30 80 SEQUENCE OF 30 08 SEQUENCE OF 30 06 INTEGER 02 01 00 INTEGER 02 01 21 SEQUENCE OF 30 08 SEQUENCE OF 30 06 INTEGER 02 01 00 INTEGER 02 01 22 end-of-contents 00 00 end-of-contents 00 00 contains two connection records, each containing one tuple listing two (integer) data items in a (fictitious) subtree: 1.3.6.1.3.127.1.1. Its header indicates it's for "switch-12", with description "Accounting", and was collected at 16:05:00 on 20 July 1996. As well as the standard format defined above, the MIB allows other enterprise-specific formats to be used. McCloghrie, et. al. Standards Track [Page 8] RFC 2513 Connection-Oriented Accounting MIB February 1999 4. Definitions ACCOUNTING-CONTROL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TestAndIncr, DisplayString, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB; accountingControlMIB MODULE-IDENTITY LAST-UPDATED "9809281000Z" ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO "Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 5260 Email: kzm@cisco.com" DESCRIPTION "The MIB module for managing the collection and storage of accounting information for connections in a connection- oriented network such as ATM." ::= { mib-2 60 } acctngMIBObjects OBJECT IDENTIFIER ::= { accountingControlMIB 1 } acctngSelectionControl OBJECT IDENTIFIER ::= { acctngMIBObjects 1 } acctngFileControl OBJECT IDENTIFIER ::= { acctngMIBObjects 2 } acctngInterfaceControl OBJECT IDENTIFIER ::= { acctngMIBObjects 3 } acctngTrapControl OBJECT IDENTIFIER ::= { acctngMIBObjects 4 } -- Textual Conventions DataCollectionSubtree ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The subtree component of a (subtree, list) tuple. Such a (subtree, list) tuple defines a set of objects and their values to be collected as accounting data for a connection. The subtree specifies a single OBJECT IDENTIFIER value such that each object in the set is named by the subtree value McCloghrie, et. al. Standards Track [Page 9] RFC 2513 Connection-Oriented Accounting MIB February 1999 appended with a single additional sub-identifier." SYNTAX OBJECT IDENTIFIER DataCollectionList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The list component of a (subtree, list) tuple. Such a (subtree, list) tuple defines a set of objects and their values to be collected as accounting data for a connection. The subtree specifies a single OBJECT IDENTIFIER value such that each object in the set is named by the subtree value appended with a single additional sub-identifier. The list specifies a set of data items, where the presence of an item in the list indicates that the item is (to be) present in the data collected for a connection; the absence of an item from the list indicates that the item is not (to be) present in the data collected for a connection. Each data item is represented by an integer which when appended (as as additional sub-identifier) to the OBJECT IDENTIFIER value of the subtree identified by the tuple, is the name of an object defining that data item (its description and its syntax). The list is specified as an OCTET STRING in which each data item is represented by a single bit, where data items 1 through 8 are represented by the bits in the first octet, data items 9 through 16 by the bits in the second octet, etc. In each octet, the lowest numbered data item is represented by the most significant bit, and the highest numbered data item by the least significant bit. A data item is present in the list when its bit is set, and absent when its bit is reset. If the length of an OCTET STRING value is too short to represent one or more data items defined in a subtree, then those data items are absent from the set identified by the tuple of that subtree and that OCTET STRING value." SYNTAX OCTET STRING (SIZE(0..8)) FileIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An arbitrary integer value identifying a file into which accounting data is being collected." SYNTAX Integer32 (1..65535) -- The Accounting Information Selection table McCloghrie, et. al. Standards Track [Page 10] RFC 2513 Connection-Oriented Accounting MIB February 1999 acctngSelectionTable OBJECT-TYPE SYNTAX SEQUENCE OF AcctngSelectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of accounting information selection entries. Note that additions, modifications and deletions of entries in this table can occur at any time, but such changes only take effect on the next occasion when collection begins into a new file. Thus, between modification and the next 'swap', the content of this table does not reflect the current selection." ::= { acctngSelectionControl 1 } acctngSelectionEntry OBJECT-TYPE SYNTAX AcctngSelectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry identifying an (subtree, list) tuple used to select a set of accounting information which is to be collected." INDEX { acctngSelectionIndex } ::= { acctngSelectionTable 1 } AcctngSelectionEntry ::= SEQUENCE { acctngSelectionIndex Integer32, acctngSelectionSubtree DataCollectionSubtree, acctngSelectionList DataCollectionList, acctngSelectionFile FileIndex, acctngSelectionType BITS, acctngSelectionRowStatus RowStatus } acctngSelectionIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer value which uniquely identifies a tuple stored in this table. This value is required to be the permanent 'handle' for an entry in this table for as long as that entry exists, including across restarts and power outages." ::= { acctngSelectionEntry 1 } McCloghrie, et. al. Standards Track [Page 11] RFC 2513 Connection-Oriented Accounting MIB February 1999 acctngSelectionSubtree OBJECT-TYPE SYNTAX DataCollectionSubtree MAX-ACCESS read-create STATUS current DESCRIPTION "The combination of acctngSelectionSubtree and acctngSelectionList specifies one (subtree, list) tuple which is to be collected." ::= { acctngSelectionEntry 2 } acctngSelectionList OBJECT-TYPE SYNTAX DataCollectionList MAX-ACCESS read-create STATUS current DESCRIPTION "The combination of acctngSelectionSubtree and acctngSelectionList specifies one (subtree, list) tuple which is to be collected." ::= { acctngSelectionEntry 3 } acctngSelectionFile OBJECT-TYPE SYNTAX FileIndex MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of the file into which the accounting information identified by this entry is to be stored. If there is no conceptual row in the acctngFileTable for which the value of acctngFileIndex has the same value as this object, then the information selected by this entry is not collected." ::= { acctngSelectionEntry 4 } acctngSelectionType OBJECT-TYPE SYNTAX BITS { svcIncoming(0), svcOutgoing(1), svpIncoming(2), svpOutgoing(3), pvc(4), pvp(5), spvcOriginator(6), spvcTarget(7), spvpOriginator(8), spvpTarget(9) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the types of connections for which the McCloghrie, et. al. Standards Track [Page 12] RFC 2513 Connection-Oriented Accounting MIB February 1999 information selected by this entry are to be collected." DEFVAL { { svcIncoming, svcOutgoing, svpIncoming, svpOutgoing } } ::= { acctngSelectionEntry 5 } acctngSelectionRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. An agent may refuse to create new conceptual rows and/or modify existing conceptual rows, if such creation/modification would cause multiple rows to have the same values of acctngSelectionSubtree and acctngSelectionList. A conceptual row can not have the status of 'active' until values have been assigned to the acctngSelectionSubtree, acctngSelectionList and acctngSelectionFile columnar objects within that row. An agent must not refuse to change the values of the acctngSelectionSubtree, acctngSelectionList and acctngSelectionFile columnar objects within a conceptual row even while that row's status is 'active'. Similarly, an agent must not refuse to destroy an existing conceptual row while the file referenced by that row's instance of acctngSelectionFile is in active use, i.e., while the corresponding instance of acctngFileRowStatus has the value 'active'. However, such changes only take effect upon the next occasion when collection begins into a new (version of the) file." ::= { acctngSelectionEntry 6 } -- The Accounting File table acctngFileTable OBJECT-TYPE SYNTAX SEQUENCE OF AcctngFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of files into which accounting information is to be stored." ::= { acctngFileControl 1 } acctngFileEntry OBJECT-TYPE SYNTAX AcctngFileEntry MAX-ACCESS not-accessible McCloghrie, et. al. Standards Track [Page 13] RFC 2513 Connection-Oriented Accounting MIB February 1999 STATUS current DESCRIPTION "An entry identifying a file into which accounting information is to be collected." INDEX { acctngFileIndex } ::= { acctngFileTable 1 } AcctngFileEntry ::= SEQUENCE { acctngFileIndex FileIndex, acctngFileName DisplayString, acctngFileNameSuffix DisplayString, acctngFileDescription DisplayString, acctngFileCommand INTEGER, acctngFileMaximumSize Integer32, acctngFileCurrentSize Integer32, acctngFileFormat INTEGER, acctngFileCollectMode BITS, acctngFileCollectFailedAttempts BITS, acctngFileInterval Integer32, acctngFileMinAge Integer32, acctngFileRowStatus RowStatus } acctngFileIndex OBJECT-TYPE SYNTAX FileIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value identifying a file into which accounting data is to be stored. This value is required to be the permanent 'handle' for an entry in this table for as long as that entry exists, including across restarts and power outages." ::= { acctngFileEntry 1 } acctngFileName OBJECT-TYPE SYNTAX DisplayString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the file into which accounting data is to be stored. If files are named using suffixes, then the name of the current file is the concatenation of acctngFileName and acctngFileNameSuffix. An agent will respond with an error (e.g., 'wrongValue') to a management set operation which attempts to modify the McCloghrie, et. al. Standards Track [Page 14] RFC 2513 Connection-Oriented Accounting MIB February 1999 value of this object to the same value as already held by another instance of acctngFileName. An agent will also respond with an error (e.g., 'wrongValue') if the new value is invalid for use as a file name on the local file system (e.g., many file systems do not support white space embedded in file names). The value of this object can not be modified while the corresponding instance of acctngFileRowStatus is 'active'." ::= { acctngFileEntry 2 } acctngFileNameSuffix OBJECT-TYPE SYNTAX DisplayString (SIZE(0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The suffix, if any, of the name of a file into which accounting data is currently being stored. If suffixes are not used, then the value of this object is the zero-length string. Note that if a separator, such as a period, is used in appending the suffix to the file name, then that separator appears as the first character of this value." ::= { acctngFileEntry 3 } acctngFileDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The textual description of the accounting data which will be stored (on the next occasion) when header information is stored in the file. The value of this object may be modified at any time." DEFVAL { "" } ::= { acctngFileEntry 4 } acctngFileCommand OBJECT-TYPE SYNTAX INTEGER { -- the following two values are states: -- they may be read but not written idle(1), cmdInProgress(2), -- the following two values are actions: -- they may be written, but are never read swapToNewFile(3), collectNow(4) } MAX-ACCESS read-create McCloghrie, et. al. Standards Track [Page 15] RFC 2513 Connection-Oriented Accounting MIB February 1999 STATUS current DESCRIPTION "A control object for the collection of accounting data. When read the value is either 'idle' or 'cmdInProgress'. Writing a value is only allowed when the current value is 'idle'. When a value is successfully written, the value changes to 'cmdInProgress' until completion of the action, at which time the value reverts to 'idle'. Actions are invoked by writing the following values: 'swapToNewFile' - the collection of data into the current file is terminated, and collection continues into a new (version of the) file. 'collectNow' - the agent creates and stores a connection record into the current file for each active connection having a type matching acctngSelectionType and an age greater than acctngFileMinAge." DEFVAL { idle } ::= { acctngFileEntry 5 } acctngFileMaximumSize OBJECT-TYPE SYNTAX Integer32 (100..2147483647) UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum size of the file (including header information). When the file of collected data reaches this size, either the agent automatically swaps to a new version (i.e., a new value acctngFileNameSuffix) of the file, or new records are discarded. Since a file must contain an integral number of connection records, the actual maximum size of the file may be just less OR Just greater than the value of this object. The value of this object can not be modified while the corresponding instance of acctngFileRowStatus is 'active'. The largest value of the maximum file size in some agents will be less than 2147483647 bytes." DEFVAL { 5000000 } ::= { acctngFileEntry 6 } acctngFileCurrentSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "bytes" MAX-ACCESS read-only McCloghrie, et. al. Standards Track [Page 16] RFC 2513 Connection-Oriented Accounting MIB February 1999 STATUS current DESCRIPTION "The current size of the file into which data is currently being collected, including header information." ::= { acctngFileEntry 7 } acctngFileFormat OBJECT-TYPE SYNTAX INTEGER { other(1), ber(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of the format in which the accounting data is to be stored in the file. If the value is modified, the new value takes effect after the next 'swap' to a new file. The value ber(2) indicates the standard format." DEFVAL { ber } ::= { acctngFileEntry 8 } acctngFileCollectMode OBJECT-TYPE SYNTAX BITS { onRelease(0), periodically(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of when accounting data is to be written into this file. Note that in addition to the occasions indicated by the value of this object, an agent always writes information on appropriate connections to the file when the corresponding instance of acctngFileCommand is set to 'collectNow'. - 'onRelease' - whenever a connection (or possibly, connection attempt) is terminated, either through a Release message or through management removal, information on that connection is written. - 'periodically' - information on appropriate connections is written on the expiry of a periodic timer, This value may be modified at any time." DEFVAL { { onRelease } } ::= { acctngFileEntry 9 } acctngFileCollectFailedAttempts OBJECT-TYPE SYNTAX BITS { soft(0), regular(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether connection data is to be collected McCloghrie, et. al. Standards Track [Page 17] RFC 2513 Connection-Oriented Accounting MIB February 1999 for failed connection attempts when the value of the corresponding instance of acctngFileCollectMode includes 'onRelease'. The individual values have the following meaning: 'soft' - indicates that connection data is to be collected for failed Soft PVCs/PVPs which originate or terminate at the relevant interface. 'regular' - indicates that connection data is to be collected for failed SVCs, including Soft PVCs/PVPs not originating or terminating at the relevant interface. This value may be modified at any time." DEFVAL { { soft, regular } } ::= { acctngFileEntry 10 } acctngFileInterval OBJECT-TYPE SYNTAX Integer32 (60..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between the periodic collections of accounting data when the value of the corresponding instance of acctngFileCollectMode includes 'periodically'. Some agents may impose restrictions on the range of this interval. This value may be modified at any time." DEFVAL { 3600 } ::= { acctngFileEntry 11 } acctngFileMinAge OBJECT-TYPE SYNTAX Integer32 (60..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum age of a connection, as used to determine the set of connections for which data is to be collected at the periodic intervals and/or when acctngFileCommand is set to 'collectNow'. The age of a connection is the elapsed time since it was last installed. When the periodic interval expires for a file or when acctngFileCommand is set to 'collectNow', accounting data is collected and stored in the file for each connection having a type matching acctngSelectionType and whose age at that time is greater than the value of acctngFileMinAge McCloghrie, et. al. Standards Track [Page 18] RFC 2513 Connection-Oriented Accounting MIB February 1999 associated with the file. This value may be modified at any time." DEFVAL { 3600 } ::= { acctngFileEntry 12 } acctngFileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object can not be set to 'active' until a value has been assigned to the corresponding instance of acctngFileName. Collection of data into the file does not begin until this object has the value 'active' and one or more (active) instances of acctngSelectionFile refer to it. If this value is modified after a collection has begun, collection into this file terminates and a new (or new version of the) file is immediately made ready for future collection (as if acctngFileCommand had been set to 'swapToNewFile'), but collection into the new (or new version of the) file does not begin until the value is subsequently set back to active." ::= { acctngFileEntry 13 } -- Overall Control acctngAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control object to indicate the administratively desired state of the collection of accounting records across all interfaces. Modifying the value of acctngAdminStatus to 'disabled' does not remove or change the current configuration as represented by the active rows in the acctngSelectionTable, acctngFileTable and acctngInterfaceTable tables." ::= { acctngInterfaceControl 1 } acctngOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION McCloghrie, et. al. Standards Track [Page 19] RFC 2513 Connection-Oriented Accounting MIB February 1999 "A status object to indicate the operational state of the collection of accounting records across all interfaces. When the value of acctngAdminStatus is modified to be 'enabled', the value of this object will change to 'enabled' providing it is possible to begin collecting accounting records. When the value of acctngAdminStatus is modified to be 'disabled', the value of this object will change to 'disabled' as soon as the collection of accounting records has terminated." ::= { acctngInterfaceControl 2 } acctngProtection OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "A control object to protect against duplication of control commands. Over some transport/network protocols, it is possible for SNMP messages to get duplicated. Such duplication, if it occurred at just the wrong time could cause serious disruption to the collection and retrieval of accounting data, e.g., if a SNMP message setting acctngFileCommand to 'swapToNewFile' were to be duplicated, a whole file of accounting data could be lost. To protect against such duplication, a management application should retrieve the value of this object, and include in the Set operation needing protection, a variable binding which sets this object to the retrieved value." ::= { acctngInterfaceControl 3 } acctngAgentMode OBJECT-TYPE SYNTAX INTEGER { swapOnCommand(1), swapOnFull(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the behaviour mode of the agent when a file becomes full: 'swapOnCommand' - the agent does not automatically swap to a new file; rather, it discards newly collected data until a management application subsequently instructs it to swap to a new file. 'swapOnFull' - the agent terminates collection into the McCloghrie, et. al. Standards Track [Page 20] RFC 2513 Connection-Oriented Accounting MIB February 1999 current file as and when that file becomes full." ::= { acctngInterfaceControl 4 } -- Per-interface control table acctngInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF AcctngInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table controlling the collection of accounting data on specific interfaces of the switch." ::= { acctngInterfaceControl 5 } acctngInterfaceEntry OBJECT-TYPE SYNTAX AcctngInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry which controls whether accounting data is to be collected on an interface. The types of interfaces which are represented in this table is implementation-specific." INDEX { ifIndex } ::= { acctngInterfaceTable 1 } AcctngInterfaceEntry ::= SEQUENCE { acctngInterfaceEnable TruthValue } acctngInterfaceEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the collection of accounting data is enabled on this interface." ::= { acctngInterfaceEntry 1 } -- Objects for controlling the use of Notifications acctngControlTrapThreshold OBJECT-TYPE SYNTAX INTEGER (0..99) MAX-ACCESS read-write STATUS current DESCRIPTION "A percentage of the maximum file size at which a 'nearly- McCloghrie, et. al. Standards Track [Page 21] RFC 2513 Connection-Oriented Accounting MIB February 1999 full' trap is generated. The value of 0 indicates that no 'nearly-full' trap is to be generated." ::= { acctngTrapControl 1 } acctngControlTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "An indication of whether the acctngFileNearlyFull and acctngFileFull traps are enabled." ::= { acctngTrapControl 2 } -- notifications acctngNotifications OBJECT IDENTIFIER ::= { accountingControlMIB 2 } acctngNotifyPrefix OBJECT IDENTIFIER ::= { acctngNotifications 0 } acctngFileNearlyFull NOTIFICATION-TYPE OBJECTS { acctngFileName, acctngFileMaximumSize, acctngControlTrapThreshold, acctngFileNameSuffix } STATUS current DESCRIPTION "An indication that the size of the file into which accounting information is currently being collected has exceeded the threshold percentage of its maximum file size. This notification is generated only at the time of the transition from not-exceeding to exceeding." ::= { acctngNotifyPrefix 1 } acctngFileFull NOTIFICATION-TYPE OBJECTS { acctngFileName, acctngFileMaximumSize, acctngFileNameSuffix } STATUS current DESCRIPTION "An indication that the size of the file into which accounting information is currently being collected has transistioned to its maximum file size. This notification is generated (for all values of acctngAgentMode) at the time of the transition from not-full to full. If acctngAgentMode has the value 'swapOnCommand', it is also generated periodically thereafter until such time as collection of McCloghrie, et. al. Standards Track [Page 22] RFC 2513 Connection-Oriented Accounting MIB February 1999 data is no longer inhibited by the file full condition." ::= { acctngNotifyPrefix 2 } -- conformance information acctngConformance OBJECT IDENTIFIER ::= { accountingControlMIB 3 } acctngGroups OBJECT IDENTIFIER ::= { acctngConformance 1 } acctngCompliances OBJECT IDENTIFIER ::= { acctngConformance 2 } acctngCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for switches which implement the Accounting Control MIB." MODULE -- this module MANDATORY-GROUPS { acctngBasicGroup, acctngNotificationsGroup } OBJECT acctngSelectionType SYNTAX BITS { svcIncoming(0), svcOutgoing(1) } DESCRIPTION "The minimal requirement is collection for SVCs." OBJECT acctngSelectionRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acctngFileName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acctngFileCommand MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acctngFileFormat SYNTAX INTEGER { ber(2) } MIN-ACCESS read-only DESCRIPTION "Only the standard format is required, and write access is not required." OBJECT acctngFileMaximumSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acctngFileCollectMode SYNTAX BITS { onRelease(0) } McCloghrie, et. al. Standards Track [Page 23] RFC 2513 Connection-Oriented Accounting MIB February 1999 MIN-ACCESS read-only DESCRIPTION "The minimal requirement is for collection on connection release." OBJECT acctngFileInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acctngFileCollectFailedAttempts MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acctngFileRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { acctngCompliances 1 } -- units of conformance acctngBasicGroup OBJECT-GROUP OBJECTS { acctngSelectionSubtree, acctngSelectionList, acctngSelectionFile, acctngSelectionType, acctngSelectionRowStatus, acctngFileName, acctngFileNameSuffix, acctngFileDescription, acctngFileCommand, acctngFileMaximumSize, acctngFileCurrentSize, acctngFileRowStatus, acctngFileFormat, acctngFileCollectMode, acctngFileCollectFailedAttempts, acctngFileInterval, acctngFileMinAge, acctngAdminStatus, acctngOperStatus, acctngProtection, acctngAgentMode, acctngInterfaceEnable, acctngControlTrapThreshold, acctngControlTrapEnable } STATUS current DESCRIPTION "A collection of objects providing control of the basic collection of accounting data for connection-oriented networks." ::= { acctngGroups 1 } acctngNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { acctngFileNearlyFull, acctngFileFull } STATUS current DESCRIPTION McCloghrie, et. al. Standards Track [Page 24] RFC 2513 Connection-Oriented Accounting MIB February 1999 "The notifications of events relating to controlling the collection of accounting data." ::= { acctngGroups 2 } END 5. Acknowledgements The comments of the IETF's AToM MIB Working Group are acknowledged. 6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] 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. [6] 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. [7] 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. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. McCloghrie, et. al. Standards Track [Page 25] RFC 2513 Connection-Oriented Accounting MIB February 1999 [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [17] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, Internation Standard 8824, December 1987. [18] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, Internation Standard 8825, December 1987. [19] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "Accounting Information for ATM Networks", RFC 2512, February 1999. [20] Noto, M., Spiegel, E., and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. McCloghrie, et. al. Standards Track [Page 26] RFC 2513 Connection-Oriented Accounting MIB February 1999 7. Security Considerations The MIB defined in this memo controls and monitors the collection of accounting data. Care should be taken to prohibit unauthorized access to this control capability in order to prevent the disruption of data collection, possibly with fraudulent intent. Example of such disruption are disabling the collection of data, or causing the wrong set of data items to be collected. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations Prior to publication of this memo as an RFC, IANA is requested to make a suitable OBJECT IDENTIFIER assignment. McCloghrie, et. al. Standards Track [Page 27] RFC 2513 Connection-Oriented Accounting MIB February 1999 9. Authors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134 Phone: +1 408 526 5260 EMail: kzm@cisco.com Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland Phone +358 303 944 808 EMail: jh@telia.fi Wedge Greene MCI Telecommunications Corporation 901 International Parkway Richardson, Texas 75081 Phone: 214-498-1232 or 972-729-1232 EMail: wedge.greene@mci.com Anil Prasad Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134 Phone: 408 525-7209 EMail: aprasad@cisco.com McCloghrie, et. al. Standards Track [Page 28] RFC 2513 Connection-Oriented Accounting MIB February 1999 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McCloghrie, et. al. Standards Track [Page 29] snmp-mibs-downloader-1.1/mibrfcs/rfc2514.txt0000644000000000000000000011131711402176071015561 0ustar Network Working Group M. Noto Request for Comments: 2514 3Com Category: Standards Track E. Spiegel Cisco Systems K. Tesink Bellcore Editors February 1999 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Introduction .......................................... 2 2 Definitions ........................................... 3 3 Acknowledgments ....................................... 17 4 References ............................................ 17 5 Security Considerations ............................... 17 6 Authors' Addresses .................................... 18 7 Intellectual Property ................................. 19 8 Full Copyright Statement .............................. 20 Abstract This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. 1. Introduction This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. Noto, et. al. Standards Track [Page 1] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 When designing a MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. This is done through Textual Conventions as defined in RFC1903 [1]. It is the purpose of this document to define the set of textual conventions available to ATM MIB modules. When designing MIB modules, it is also often useful to register further properties with object identifier assignments so that they can be further used by other MIB modules. This is done through the OBJECT-IDENTITY macro defined in RFC1902 [2]. This document defines OBJECT-IDENTITIES available to ATM MIB modules. Note that for organizational purposes OBJECT IDENTITIES previously defined in RFC1695 have been moved to this specification and no longer appear in the revision of RFC1695 [3]. However, the original OBJECT IDENTIFIERs have been preserved. For an introduction to the concepts of ATM connections, see [3]. 2. Definitions ATM-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, TimeTicks, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; atmTCMIB MODULE-IDENTITY LAST-UPDATED "9810190200Z" ORGANIZATION "IETF AToMMIB Working Group" CONTACT-INFO " Michael Noto Postal: 3Com Corporation 5400 Bayfront Plaza, M/S 3109 Santa Clara, CA 95052 USA Tel: +1 408 326 2218 E-mail: mike_noto@3com.com Ethan Mickey Spiegel Noto, et. al. Standards Track [Page 2] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 Postal: Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Tel: +1 408 526 6408 E-mail: mspiegel@cisco.com Kaj Tesink Postal: Bellcore 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 732 758 5254 Fax: +1 732 758 4177 E-mail: kaj@bellcore.com" DESCRIPTION "This MIB Module provides Textual Conventions and OBJECT-IDENTITY Objects to be used by ATM systems." ::= { mib-2 37 3 } -- atmMIB 3 (see [3]) -- The Textual Conventions defined below are organized -- alphabetically AtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "An ATM address. The semantics are implied by the length. The address types are: - no address (0 octets) - E.164 (8 octets) - NSAP (20 octets) In addition, when subaddresses are used the AtmAddr may represent the concatenation of address and subaddress. The associated address types are: - E.164, E.164 (16 octets) - E.164, NSAP (28 octets) - NSAP, NSAP (40 octets) Address lengths other than defined in this definition imply address types defined elsewhere. Note: The E.164 address is encoded in BCD format." SYNTAX OCTET STRING (SIZE(0..40)) AtmConnCastType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of topology of a connection (point- Noto, et. al. Standards Track [Page 3] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 to-point, point-to-multipoint). In the case of point-to-multipoint, the orientation of this VPL or VCL in the connection. On a host: - p2mpRoot indicates that the host is the root of the p2mp connection. - p2mpLeaf indicates that the host is a leaf of the p2mp connection. On a switch interface: - p2mpRoot indicates that cells received by the switching fabric from the interface are from the root of the p2mp connection. - p2mpLeaf indicates that cells transmitted to the interface from the switching fabric are to the leaf of the p2mp connection." SYNTAX INTEGER { p2p(1), p2mpRoot(2), p2mpLeaf(3) } AtmConnKind ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of call control used for an ATM connection at a particular interface. The use is as follows: pvc(1) Virtual link of a PVC. Should not be used for an PVC/SVC (i.e., Soft PVC) crossconnect. svcIncoming(2) Virtual link established after a received signaling request to setup an SVC. svcOutgoing(3) Virtual link established after a transmitted or forwarded signaling request to setup an SVC. spvcInitiator(4) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the initiator of the Soft PVC setup. spvcTarget(5) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the target of the Soft PVC Noto, et. al. Standards Track [Page 4] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 setup. For PVCs, a pvc virtual link is always cross- connected to a pvc virtual link. For SVCs, an svcIncoming virtual link is always cross- connected to an svcOutgoing virtual link. For Soft PVCs, an spvcInitiator is either cross-connected to an svcOutgoing or an spvcTarget, and an spvcTarget is either cross-connected to an svcIncoming or an spvcInitiator." SYNTAX INTEGER { pvc(1), svcIncoming(2), svcOutgoing(3), spvcInitiator(4), spvcTarget(5) } AtmIlmiNetworkPrefix ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A network prefix used for ILMI address registration. In the case of ATM endsystem addresses (AESAs), the network prefix is the first 13 octets of the address which includes the AFI, IDI, and HO-DSP fields. In the case of native E.164 addresses, the network prefix is the entire E.164 address encoded in 8 octets, as if it were an E.164 IDP in an ATM endsystem address structure." REFERENCE "ATM Forum, Integrated Local Management Interface (ILMI) Specification, Version 4.0, af-ilmi-0065.000, September 1996, Section 9 ATM Forum, ATM User-Network Interface Signalling Specification, Version 4.0 (UNI 4.0), af-sig-0061.000, June 1996, Section 3" SYNTAX OCTET STRING (SIZE(8|13)) AtmInterfaceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The connection setup procedures used for the identified interface. Other: Connection setup procedures other than those listed below. Noto, et. al. Standards Track [Page 5] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 Auto-configuration: Indicates that the connection setup procedures are to be determined dynamically, or that determination has not yet been completed. One such mechanism is via ATM Forum ILMI auto-configuration procedures. ITU-T DSS2: - ITU-T Recommendation Q.2931, Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control (September 1994) - ITU-T Draft Recommendation Q.2961, B-ISDN DSS 2 Support of Additional Traffic Parameters (May 1995) - ITU-T Draft Recommendation Q.2971, B-ISDN DSS 2 User Network Interface Layer 3 Specification for Point-to-multipoint Call/connection Control (May 1995) ATM Forum UNI 3.0: ATM Forum, ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, (1994). ATM Forum UNI 3.1: ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, (November 1994). ATM Forum UNI Signalling 4.0: ATM Forum, ATM User-Network Interface (UNI) Signalling Specification Version 4.0, af-sig-0061.000 (June 1996). ATM Forum IISP (based on UNI 3.0 or UNI 3.1) : Interim Inter-switch Signaling Protocol (IISP) Specification, Version 1.0, af-pnni-0026.000, (December 1994). ATM Forum PNNI 1.0 : ATM Forum, Private Network-Network Interface Specification, Version 1.0, af-pnni-0055.000, (March 1996). Noto, et. al. Standards Track [Page 6] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 ATM Forum B-ICI: ATM Forum, B-ICI Specification, Version 2.0, af-bici-0013.002, (November 1995). ATM Forum UNI PVC Only: An ATM Forum compliant UNI with the signalling disabled. ATM Forum NNI PVC Only: An ATM Forum compliant NNI with the signalling disabled." SYNTAX INTEGER { other(1), autoConfig(2), ituDss2(3), atmfUni3Dot0(4), atmfUni3Dot1(5), atmfUni4Dot0(6), atmfIispUni3Dot0(7), atmfIispUni3Dot1(8), atmfIispUni4Dot0(9), atmfPnni1Dot0(10), atmfBici2Dot0(11), atmfUniPvcOnly(12), atmfNniPvcOnly(13) } AtmServiceCategory ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The service category for a connection." REFERENCE "ATM Forum Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." SYNTAX INTEGER { other(1), -- none of the following cbr(2), -- constant bit rate rtVbr(3), -- real-time variable bit rate nrtVbr(4), -- non real-time variable bit rate abr(5), -- available bit rate ubr(6) -- unspecified bit rate } AtmSigDescrParamIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies a row in the atmSigDescrParamTable. The value 0 signifies that none of the signalling parameters defined in the atmSigDescrParamTable are applicable." Noto, et. al. Standards Track [Page 7] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 SYNTAX INTEGER (0..2147483647) AtmTrafficDescrParamIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies a row in the atmTrafficDescrParamTable. The value 0 signifies that no row has been identified." SYNTAX INTEGER (0..2147483647) AtmVcIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The VCI value for a VCL. The maximum VCI value cannot exceed the value allowable by atmInterfaceMaxVciBits defined in ATM-MIB." SYNTAX INTEGER (0..65535) AtmVpIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The VPI value for a VPL or VCL. The value VPI=0 is only allowed for a VCL. For ATM UNIs supporting VPCs the VPI value ranges from 0 to 255. The VPI value 0 is supported for ATM UNIs conforming to the ATM Forum UNI 4.0 Annex 8 (Virtual UNIs) specification. For ATM UNIs supporting VCCs the VPI value ranges from 0 to 255. For ATM NNIs the VPI value ranges from 0 to 4095. The maximum VPI value cannot exceed the value allowable by atmInterfaceMaxVpiBits defined in ATM-MIB." SYNTAX INTEGER (0..4095) AtmVorXAdminStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value determines the desired administrative status of a virtual link or cross-connect. The up and down states indicate that the traffic flow is enabled or disabled respectively on the virtual link or cross-connect." SYNTAX INTEGER { up(1), down(2) } AtmVorXLastChange ::= TEXTUAL-CONVENTION STATUS current Noto, et. al. Standards Track [Page 8] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 DESCRIPTION "The value of MIB II's sysUpTime at the time a virtual link or cross-connect entered its current operational state. If the current state was entered prior to the last re-initialization of the agent then this object contains a zero value." SYNTAX TimeTicks AtmVorXOperStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value determines the operational status of a virtual link or cross-connect. The up and down states indicate that the traffic flow is enabled or disabled respectively on the virtual link or cross-connect. The unknown state indicates that the state of it cannot be determined. The state will be down or unknown if the supporting ATM interface(s) is down or unknown respectively." SYNTAX INTEGER { up(1), down(2), unknown(3) } -- OBJECT-IDENTITIES: -- The following atmTrafficDescriptorTypes has been moved -- from RFC1695 and no longer appear in the revision of -- RFC1695[3]. atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1} -- atmMIBObjects -- See [3]. -- All other and new OBJECT IDENTITIES -- are defined under the following subtree: atmObjectIdentities OBJECT IDENTIFIER ::= {atmTCMIB 1} -- The following values are defined for use as -- possible values of the ATM traffic descriptor type. atmNoTrafficDescriptor OBJECT-IDENTITY STATUS deprecated Noto, et. al. Standards Track [Page 9] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 DESCRIPTION "This identifies the no ATM traffic descriptor type. Parameters 1, 2, 3, 4, and 5 are not used. This traffic descriptor type can be used for best effort traffic." ::= {atmTrafficDescriptorTypes 1} atmNoClpNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: not used Parameter 3: not used Parameter 4: not used Parameter 5: not used." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994." ::= {atmTrafficDescriptorTypes 2} atmClpNoTaggingNoScr OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This traffic descriptor is for CLP without tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: peak cell rate in cells/second for CLP=0 traffic Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= {atmTrafficDescriptorTypes 3} atmClpTaggingNoScr OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This traffic descriptor is for CLP with tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Noto, et. al. Standards Track [Page 10] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: peak cell rate in cells/second for CLP=0 traffic, excess tagged as CLP=1 Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= {atmTrafficDescriptorTypes 4} atmNoClpScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP with Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0+1 traffic Parameter 3: maximum burst size in cells Parameter 4: not used Parameter 5: not used." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994." ::= {atmTrafficDescriptorTypes 5} atmClpNoTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for CLP with Sustained Cell Rate and no tagging. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic Parameter 3: maximum burst size in cells Parameter 4: not used Parameter 5: not used." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Noto, et. al. Standards Track [Page 11] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 Version 3.1 (UNI 3.1) Specification, November 1994." ::= {atmTrafficDescriptorTypes 6} atmClpTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for CLP with tagging and Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic, excess tagged as CLP=1 Parameter 3: maximum burst size in cells Parameter 4: not used Parameter 5: not used." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994." ::= {atmTrafficDescriptorTypes 7} atmClpNoTaggingMcr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for CLP with Minimum Cell Rate and no tagging. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: minimum cell rate in cells/second Parameter 4: unused Parameter 5: unused." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994." ::= {atmTrafficDescriptorTypes 8} atmClpTransparentNoScr OBJECT-IDENTITY STATUS current Noto, et. al. Standards Track [Page 12] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 DESCRIPTION "This traffic descriptor type is for the CLP- transparent model and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: not used Parameter 4: not used Parameter 5: not used. This traffic descriptor type is applicable to connections following the CBR.1 conformance definition. Connections specifying this traffic descriptor type will be rejected at UNI 3.0 or UNI 3.1 interfaces. For a similar traffic descriptor type that can be accepted at UNI 3.0 and UNI 3.1 interfaces, see atmNoClpNoScr." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994. ATM Forum, Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." ::= {atmTrafficDescriptorTypes 9} atmClpTransparentScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for the CLP- transparent model with Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0+1 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to connections following the VBR.1 conformance definition. Noto, et. al. Standards Track [Page 13] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 Connections specifying this traffic descriptor type will be rejected at UNI 3.0 or UNI 3.1 interfaces. For a similar traffic descriptor type that can be accepted at UNI 3.0 and UNI 3.1 interfaces, see atmNoClpScr." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994. ATM Forum, Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." ::= {atmTrafficDescriptorTypes 10} atmNoClpTaggingNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP with tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: not used Parameter 4: not used Parameter 5: not used. This traffic descriptor type is applicable to connections following the UBR.2 conformance definition ." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994. ATM Forum, Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." ::= {atmTrafficDescriptorTypes 11} atmNoClpNoScrCdvt OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second Noto, et. al. Standards Track [Page 14] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: not used Parameter 4: not used Parameter 5: not used. This traffic descriptor type is applicable to CBR connections following the UNI 3.0/3.1 conformance definition for PCR CLP=0+1. These CBR connections differ from CBR.1 connections in that the CLR objective applies only to the CLP=0 cell flow. This traffic descriptor type is also applicable to connections following the UBR.1 conformance definition." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994. ATM Forum, Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." ::= {atmTrafficDescriptorTypes 12} atmNoClpScrCdvt OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP with Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0+1 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to VBR connections following the UNI 3.0/3.1 conformance definition for PCR CLP=0+1 and SCR CLP=0+1. These VBR connections differ from VBR.1 connections in that the CLR objective applies only to the CLP=0 cell flow." REFERENCE Noto, et. al. Standards Track [Page 15] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994. ATM Forum, Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." ::= {atmTrafficDescriptorTypes 13} atmClpNoTaggingScrCdvt OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for CLP with Sustained Cell Rate and no tagging. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to connections following the VBR.2 conformance definition." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994. ATM Forum, Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." ::= {atmTrafficDescriptorTypes 14} atmClpTaggingScrCdvt OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for CLP with tagging and Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic, excess tagged as CLP=1 Parameter 3: maximum burst size in cells Noto, et. al. Standards Track [Page 16] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to connections following the VBR.3 conformance definition." REFERENCE "ATM Forum,ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, November 1994. ATM Forum, Traffic Management Specification, Version 4.0, af-tm-0056.000, June 1996." ::= {atmTrafficDescriptorTypes 15} END 3. Acknowledgments This document is a product of the AToMMIB Working Group. 4. References [1] 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. [2] 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. [3] Tesink, K., Editor, "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. 5. Security Considerations This memo defines textual conventions and object identities for use in ATM MIB modules. Security issues for these MIB modules are addressed in the memos defining those modules. Noto, et. al. Standards Track [Page 17] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 6. Authors' Addresses Michael Noto 3Com Corporation 5400 Bayfront Plaza, M/S 3109 Santa Clara, CA 95052 Phone +1 408 326 2218 Email: mike_noto@3com.com Ethan Mickey Spiegel Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone +1 408 526 6408 EMail: mspiegel@cisco.com Kaj Tesink Bellcore 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (732) 758-5254 EMail: kaj@bellcore.com Noto, et. al. Standards Track [Page 18] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Noto, et. al. Standards Track [Page 19] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999 8. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Noto, et. al. Standards Track [Page 20] snmp-mibs-downloader-1.1/mibrfcs/rfc2515.txt0000644000000000000000000053743111402176071015573 0ustar Network Working Group K. Tesink, Editor Request for Comments: 2515 Bell Communications Research Obsoletes: 1695 February 1999 Category: Standards Track Definitions of Managed Objects for ATM Management 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Abstract ............................................. 2 2 The SNMP Network Management Framework ................. 2 3 ATM Terminology ....................................... 3 3.1 VCL/VPL and VCC/VPC ................................. 3 3.2 PVC, SVC and Soft PVC ............................... 5 3.3 Traffic Management Parameters ....................... 6 3.3.1 Traffic Policing and Traffic Shaping Parameters .................................................... 6 3.3.2 Cell Loss Priority ................................ 6 3.3.3 QoS Class ......................................... 6 3.3.4 Service Category .................................. 7 3.4 Max Active and Max Current VPI and VCI Bits ......... 7 4 Overview .............................................. 8 4.1 Background .......................................... 8 4.2 Structure of the MIB ................................ 9 4.3 ATM Interface Configuration Table ................... 9 4.4 ATM Interface DS3 PLCP and TC Layer Tables .......... 9 4.5 ATM Virtual Link and Cross-Connect Tables ........... 9 5 Application of MIB II to ATM .......................... 10 5.1 The System Group .................................... 10 5.2 The Interface Group ................................. 10 5.2.1 Support of the ATM Cell Layer by ifTable .......... 10 6 Support of the AAL3/4 Based Interfaces ................ 12 7 Support of the AAL5 Managed Objects ................... 12 7.1 Managing AAL5 in a Switch ........................... 12 Tesink Standards Track [Page 1] RFC 2515 ATM Management Objects February 1999 7.2 Managing AAL5 in a Host ............................. 14 7.3 Support of AAL5 by ifTable .......................... 15 7.4 Support of Proprietary Virtual Interface by ifT- able ............................................... 16 7.5 AAL5 Connection Performance Statistics Table ........ 17 8 ILMI MIBs and the ATM Managed Objects ................. 18 9 Definitions ........................................... 20 10 Acknowledgments ...................................... 83 11 References ........................................... 83 12 Security Considerations .............................. 85 13 Author's Address ..................................... 85 14 Intellectual Property ................................ 86 15 Full Copyright Statement ............................. 87 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. This memo replaces RFC 1695 [24]. Changes relative to RFC 1695 are summarized in the MIB module's REVISION clause. Textual Conventions used in this MIB are defined in [6] and [19]. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: 0 An overall architecture, described in RFC 2271 [1]. 0 Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. 0 Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. Tesink Standards Track [Page 2] RFC 2515 ATM Management Objects February 1999 The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 0 Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. 0 A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. ATM Terminology Some basic ATM terminologies are described in this section to facilitate defining the ATM managed objects. 3.1. VCL/VPL and VCC/VPC There are two distinct types of ATM virtual connections: Virtual Channel Connections (VCCs) and Virtual Path Connection (VPCs). As shown in Figures 1 and 2, ATM virtual connections consist of concatenated series of virtual links which forms a path between two end points, with each concatenation occurring at an ATM switch. Virtual links of VCCs are called Virtual Channel Links (VCLs). Virtual links of VPCs are called Virtual Path Links (VPLs). The VCI and VPI fields in the ATM cell header associate each cell of a VCC with a particular VCL over a given physical link. The VPI field in the ATM cell header associates each cell of a VPC with a particular VPL over a given physical link. Switches route cells between VCLs (or VPLs) via a cross-connect function according to the cells' VCI/VPI (or VPI) values. Tesink Standards Track [Page 3] RFC 2515 ATM Management Objects February 1999 <-----------------------VCC--------------------------> ------------ ----------- |ATM | |ATM | |X-Connect | |X-Connect | VCL1 |Point | VCL2 |Point | VCL3 O---------|----X-----|-------|-----|----X-----|-------O | | | | ------------ ------------ ATM Switch ATM Switch Figure 1: Virtual Channel Links and Virtual Channel Connection <-----------------------VPC--------------------------> ------------ ----------- |ATM | |ATM | |X-Connect | |X-Connect | VPL1 |Point | VPL2 |Point | VPL3 O---------|----X-----|-------|-----|----X-----|-------O | | | | ------------ ------------ ATM Switch ATM Switch Figure 2: Virtual Path Links and Virtual Path Connection A single ATM end-system or switch does not support the whole end-to- end span of a VCC (or VPC). Rather, multiple ATM end-systems and/or switches each support one piece of the VCC (or VPC). That is, each ATM end-system (or ATM switch) at one end of the VCC/VPC supports its end of the VCC/VPC plus the VCL or VPL on its external interface, and each switch through which the VCC/VPC passes supports the pair of VCLs/VPLs on its external interfaces as well as the cross-connection of those VCLs/VPLs. Thus, the end-to-end management of a VCC or VPC is achieved only by appropriate management of its individual pieces in combination. Note that for management purposes, an ATM network may be viewed as a large distributed switch by hiding all the network's internal connectivity as being internal to the distributed switch (as shown in Figure 2a). This model may for example be used for Customer Network Management (CNM) purposes. Tesink Standards Track [Page 4] RFC 2515 ATM Management Objects February 1999 <---------------------VCC---------------------------> -------------------------------------- | | | ---------- ---------- | | | ATM | | ATM | | VCL1 | | Switch | | Switch | | VCL3 O-------|-|--------|------/-------|--------|-|------O | | | | | | | ---------- ---------- | | | | ATM Network | -------------------------------------- Figure 2a: ATM Network modeled as a large distributed switch A VCC has a set of traffic characteristics (i.e., bandwidth parameters, service category parameters, etc.). VCLs inherit their traffic characteristics from the VCC of which they are a part. VCCs are bi-directional by definition. However, the traffic parameters in the two directions of a connection can be symmetric or asymmetric, i.e., the two directions can have the same or different traffic flows. A uni-directional traffic flow across a VCC is achieved by assigning a zero bandwidth in one direction. Note that in addition to the bandwidth required by the user traffic flow, bandwidth is also required for OAM cell flows, even for the zero-bandwidth direction of a uni-directional connection. These same principles apply to VPCs. 3.2. PVC, SVC and Soft PVC A Permanent Virtual Connection (PVC) is a provisioned VCC or VPC. A Switched Virtual Connection (SVC) is a switched VCC or VPC that is set up in real-time via call set-up signaling procedures. A PVC (or an SVC) can be a point-to-point, point-to-multipoint, or multipoint- to-multipoint VCC or VPC. A Soft PVC is a connection of which portions are switched, while other portions are permanent (see Figure 3 and [22]). +--------+ +--------+ +--------+ pvc| ATM |svc svc | ATM |svc svc | ATM |pvc ----| Switch |-----------| Switch |-----------| Switch |---- +--------+ +--------+ +--------+ Figure 3: An example of a Soft PVC Tesink Standards Track [Page 5] RFC 2515 ATM Management Objects February 1999 3.3. Traffic Management Parameters 3.3.1. Traffic Policing and Traffic Shaping Parameters In order to allocate resources fairly among different users, some networks police traffic at resource access points. The traffic enforcement or policing taken at a UNI is called Usage Parameter Control (UPC) and is conceptually activated on an incoming VCL or VPL as shown in Figure 4. The use of the traffic enforcer at the ingress of the connection is to make sure that the user traffic does not exceed the negotiated traffic parameters such as the peak cell rate associated with a specific traffic descriptor type. ---------- ---------- UNI | ATM | NNI | ATM | UNI | | switch | | | switch | | O<---|---->X(UPC) |<----|------>| (UPC)X<-----|--->O | VCL | | | VCL | | VCL | ---------- ---------- Figure 4: An Example of a UPC In addition, traffic shaping may be performed on an outgoing VPL or VCL at a given ATM interface. The function of the ATM traffic shaper, conceptually either at the source or an egress point of the connection, is to smooth the outgoing cell traffic inter-arrival time. If policing or shaping is not performed then the policing or shaping algorithm is not activated. 3.3.2. Cell Loss Priority To prioritize traffic during resource congestion, ATM cells are assigned one of the two types of Cell Loss Priority (CLP), CLP=0 and CLP=1. ATM cells with CLP=0 have a higher priority in regard to cell loss than ATM cells with CLP=1. Therefore, during resource congestions, CLP=1 cells are dropped before any CLP=0 cell is dropped. 3.3.3. QoS Class RFC1695 specified that one of a number of Quality of Service (QoS) classes is assigned to a VCC or VPC by associating the object atmTrafficQoSClass with each VCL or VPL. However, new insights in ATM traffic management have caused this object to be deprecated. Tesink Standards Track [Page 6] RFC 2515 ATM Management Objects February 1999 3.3.4. Service Category Replacing QoS Class, VPLs and VCLs are qualified in terms of their service category (atmServiceCategory). When properly configured, VCLs (or VPLs) concatenated to form a VCC (or VPC) will all have the same service category class as that of the VCC (or VPC). 3.4. Max Active and Max Current VPI and VCI Bits A manager may wish to configure the maximum number of VPI and VCI bits that can be used to identify VPIs and VCIs on a given ATM interface. This value can be less than or equal to the maximum number of bits supported by the interface hardware, and is referred to in the MIB as the Max Active VPI Bits and Max Active VCI Bits. However, a manager may not be able to configure the Max Active Bits on both ends of an ATM link. For example, the manager may not be allowed write access to the peer's MIB, or there may be hardware limitations on the peer device. Therefore, the two ATM devices may use ILMI to negotiate "Max Current" VPI and VCI bits, which is the maximum number of bits that both interfaces are willing to support. This is illustrated in Figure 5. The relationship between the different parameters is illustrated in Figure 6. Note that if ILMI negotiation is not supported, then the devices have no choice but to use the configured Max Active bits, and assume that it has been configured to the same value on both ends of the link. +--------+ +--------+ +--------+ | ATM | IF a IF b | ATM | IF c IF d | ATM | | Device |--------------| Device |--------------| Device | +--------+ +--------+ +--------+ IF a: Max Active VPI Bits = 6 (configured) Max Current VPI Bits = 6 (negotiated) IF b: Max Active VPI Bits = 8 (configured) Max Current VPI Bits = 6 (negotiated) IF c: Max Active VPI Bits = 8 (configured) Max Current VPI Bits = 8 (negotiated) IF d: Max Active VPI Bits = 8 (configured) Max Current VPI Bits = 8 (negotiated) Tesink Standards Track [Page 7] RFC 2515 ATM Management Objects February 1999 (between IF a and IF b, the minimum of the two configured "Max Active VPI Bits" is 6, so both interfaces set their "Max Current VPI Bits" to 6. Since IF c and IF d both are configured with "Max Active VPI Bits" of 8, they set their "Max Current VPI Bits" to 8.) Figure 5 MSB LSB +----------------------------------------------------+ | | | | | +----------------------------------------------------+ ^ ^ ^ ^ | | | | Max bits Max Bits Max Max supported supported Active (config.) current (negotiated) by MIB by h/w Bits Bits Figure 6 4. Overview ATM management objects are used to manage ATM interfaces, ATM virtual links, ATM cross-connects, AAL5 entities and AAL5 connections supported by ATM hosts, ATM switches and ATM networks. This section provides an overview and background of how to use this MIB and other potential MIBs for this purpose. The purpose of this memo is primarily to manage ATM PVCs. ATM SVCs are also represented by the management information in this MIB. However, full management of SVCs may require additional capabilities which are beyond the scope of this memo. 4.1. Background In addition to the MIB module defined in this memo, other MIB modules are necessary to manage ATM interfaces, links and cross-connects. Examples include MIB II for general system and interface management [16][17], the DS3 or SONET MIBs for management of physical interfaces, and, as appropriate, MIB modules for applications that make use of ATM, such as SMDS. These MIB modules are outside the scope of this specification. The current specification of this ATM MIB is based on SNMPv2-SMI. Tesink Standards Track [Page 8] RFC 2515 ATM Management Objects February 1999 4.2. Structure of the MIB The managed ATM objects are arranged into the following tables: (1) ATM interface configuration table (2) ATM interface DS3 PLCP and TC sublayer tables (3) ATM traffic parameter table (4) ATM interface virtual link (VPL/VCL) configuration tables (5) ATM VP/VC cross-connect tables (6) AAL5 connection performance statistics table Note that, managed objects for activation/deactivation of OAM cell flows and ATM traps notifying virtual connection or virtual link failures are outside the scope of this memo. 4.3. ATM Interface Configuration Table This table contains information on ATM cell layer configuration of local ATM interfaces on an ATM device in addition to the information on such interfaces contained in the ifTable. 4.4. ATM Interface DS3 PLCP and TC Layer Tables These tables provide performance statistics of the DS3 PLCP and TC sublayer of local ATM interfaces on a managed ATM device. DS3 PLCP and TC sublayer are currently used to carry ATM cells respectively over DS3 and SONET transmission paths. 4.5. ATM Virtual Link and Cross-Connect Tables ATM virtual link and cross-connect tables model bi-directional ATM virtual links and ATM cross-connects. The ATM VP/VC link tables are implemented in an ATM host, ATM switch and ATM network. The ATM switch and ATM network also implement the ATM VP/VC cross-connect tables. Both link and cross-connect tables are implemented in a carrier's network for Customer Network Management (CNM) purposes. The ATM virtual link tables are used to create, delete or modify ATM virtual links in an ATM host, ATM switch and ATM network. ATM virtual link tables along with the cross-connect tables are used to create, delete or modify ATM cross-connects in an ATM switch or ATM network (e.g., for CNM purposes). For a PVC, the cross-connect between two VPLs is represented in the atmVpCrossConnectTable of the ATM-MIB, indexed by the atmVplCrossConnectIdentifier values for the two VPLs, and the cross- Tesink Standards Track [Page 9] RFC 2515 ATM Management Objects February 1999 rconnect between two VCLs is represented in the atmVcCrossConnectTable of the ATM-MIB, indexed by the atmVclCrossConnectIdentifier values for the two VCLs. For an SVC or Soft PVC the VPL and VCL tables defined in this memo are used. Hoewever, for an SVC or Soft PVC the cross-connect between two VPLs is represented in the atmSvcVpCrossConnectTable of the ATM2-MIB, indexed by the atmVplCrossConnectIdentifier values for the two VPLs, and the cross-connect between two VCLs is represented in the atmSvcVcCrossConnectTable of the ATM2-MIB, indexed by the atmVclCrossConnectIdentifier values for the two VCLs. Note: The ATM2-MIB module was being defined in a separate memo at the time of this publication. Please consult the RFC directory for an exact reference. 5. Application of MIB II to ATM 5.1. The System Group For the purposes of the sysServices object in the System Group of MIB II [16], ATM is a data link layer protocol. Thus, for ATM switches and ATM networks, sysServices will have the value "2". 5.2. The Interface Group The Interfaces Group of MIB II defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing ATM interfaces. This memo assumes the interpretation of the Interfaces Group to be in accordance with [17] which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Thus, the ATM cell layer interface is represented as an entry in the ifTable. This entry is concerned with the ATM cell layer as a whole, and not with individual virtual connections which are managed via the ATM-specific managed objects specified in this memo. The inter-relation of entries in the ifTable is defined by Interfaces Stack Group defined in [17]. 5.2.1. Support of the ATM Cell Layer by ifTable Some specific interpretations of ifTable for the ATM cell layer follow. Tesink Standards Track [Page 10] RFC 2515 ATM Management Objects February 1999 Object Use for the generic ATM layer ====== ============================= ifIndex Each ATM port is represented by an ifEntry. ifDescr Description of the ATM interface. ifType The value that is allocated for ATM is 37. ifSpeed The total bandwidth in bits per second for use by the ATM layer. ifPhysAddress The interface's address at the ATM protocol sublayer; the ATM address which would be used as the value of the Called Party Address Information Element (IE) of a signalling message for a connection which either: - would terminate at this interface, or - for which the Called Party Address IE would need to be replaced by the Called Party SubAddress IE before the message was forwarded to any other interface. For an interface on which signalling is not supported, then the interface does not necessarily have an address, but if it does, then ifPhysAddress is the address which would be used as above in the event that signalling were supported. If the interface has multiple such addresses, then ifPhysAddress is its primary address. If the interface has no addresses, then ifPhysAddress is an octet string of zero length. Address encoding is as per [20]. Note that addresses assigned for purposes other than those listed above (e.g., an address associated with the service provider side of a public network UNI) may be represented through atmInterfaceSubscrAddress. ifAdminStatus See [17]. ifOperStatus Assumes the value down(2) if the ATM cell layer is down. ifLastChange See [17]. ifInOctets The number of received octets over the interface, i.e., the number of received, assigned cells multiplied by 53. ifOutOctets The number of transmitted octets over the interface, i.e., the number of transmitted, assigned cells multiplied by 53. Tesink Standards Track [Page 11] RFC 2515 ATM Management Objects February 1999 ifInErrors The number of cells dropped due to uncorrectable HEC errors. ifInUnknownProtos The number of received cells discarded during cell header validation, including cells with unrecognized VPI/VCI values, and cells with invalid cell header patterns. If cells with undefined PTI values are discarded, they are also counted here. ifOutErrors See [17]. ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). ifConnectorPresent Set to false (2). ifHighSpeed See [17]. ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in [17]. ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in [17]. ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. 6. Support of the AAL3/4 Based Interfaces For the management of AAL3/4 CPCS layer, see [18]. 7. Support of the AAL5 Managed Objects Support of AAL5 managed objects in an ATM switch and ATM host are described below. 7.1. Managing AAL5 in a Switch Managing AAL5 in a switch involves: (1) performance management of an AAL5 entity as an internal resource in a switch (2) performance management of AAL5 per virtual connection Tesink Standards Track [Page 12] RFC 2515 ATM Management Objects February 1999 AAL5 in a switch is modeled as shown in Figure 7 and 8. AAL5 will be managed in a switch for only those virtual connections that carry AAL5 and are terminated at the AAL5 entity in the switch. Note that, the virtual channels within the ATM UNIs carrying AAL5 will be switched by the ATM switching fabric (termed as ATM Entity in the figure) to the virtual channels on a proprietary internal interface associated with the AAL5 process (termed as AAL5 Entity in the figure). Therefore, performance management of the AAL5 resource in the switch will be modeled using the ifTable through an internal (pseudo-ATM) virtual interface and the AAL5 performance management per virtual connection will be supported using an additional AAL5 connection table in the ATM MIB. The association between the AAL5 virtual link at the proprietary virtual, internal interface and the ATM virtual link at the ATM interface will be derived from the virtual channel cross-connect table and the virtual channel link table in the ATM MIB. Note that for the proprietary virtual interface the traffic transmit and receive conventions in the virtual channel link table are as follows: Transmitting traffic: ATM Entity ---> AAL5 Entity Receiving traffic: ATM Entity <--- AAL5 Entity ___________________________ | | | ============= | | | AAL5 | | | | Entity | | | ============= | | | | | -----Prop. Virtual Interface | | | | ============= | | | ATM | | | | Entity | | | ============= | |_____|__|__|__|__|_______| | | | | | ---------------- ATM UNIs | | | | | | | | | | v v v v v Figure 7: Model of an AAL5 Entity in a Switch Tesink Standards Track [Page 13] RFC 2515 ATM Management Objects February 1999 __________________ | | | AAL5 | |________________| | | | Prop. Virtual | | Interface | |________________| Figure 8: AAL5 Entity's Interface Stack in a Switch 7.2. Managing AAL5 in a Host Managing AAL5 in a host involves managing the AAL5 sublayer interface as shown in Figure 9 and 10. The AAL5 sublayer is stacked directly over the ATM sublayer. The ifTable is applied to the AAL5 sublayer as defined in Section 10.3. ___________________________ | | | ============= | | | AAL5 | | | | Entity | | | ============= | | | ATM | | | | Entity | | | ============= | |___________|_____________| | __|__ ATM UNI | | v Figure 9: Model of an AAL5 Entity in a Host __________________ | | | AAL5 | |________________| | | | ATM Layer | |________________| | | | Physical Layer| |________________| Figure 10: AAL5 Entity's Interface Stack in a Host Tesink Standards Track [Page 14] RFC 2515 ATM Management Objects February 1999 7.3. Support of AAL5 by ifTable The AAL5 entity in an ATM device (e.g., switch or host) is managed using the ifTable. There are additional counters specified for AAL5 than those specified in the ATM B-ICI document [21]. Specific interpretations of ifTable for the AAL5 CPCS layer are as follows. Object Use for AAL5 CPCS layer entity ====== ============================== ifIndex Each AAL5 entity is represented by an ifEntry. ifDescr Description of the AAL5 entity. ifType The value that is allocated for AAL5 is 49. ifMtu Set to the largest PDU size for the AAL5 CPCS layer that can be processed by the AAL5 entity. ifSpeed Set to 0. ifPhysAddress An octet string of zero length. ifAdminStatus See [17]. ifOperStatus Assumes the value down(2) if the AAL5 layer is down. ifLastChange See [17]. ifInOctets The number of received AAL5 CPCS PDU octets. ifOutOctets The number of AAL5 CPCS PDU octets transmitted. ifInUcastPkts The number of received AAL5 CPCS PDUs passed to a higher-layer. ifOutUcastPkts The number of AAL5 CPCS PDUs received from a higher-layer for transmission. [Note: The number of AAL5 PDUs actually transmitted is the number received from a higher-layer for transmission minus any which are counted by ifOutErrors and ifOutDiscards.] Tesink Standards Track [Page 15] RFC 2515 ATM Management Objects February 1999 ifInErrors Number of errored AAL5 CPCS PDUs received. The types of errors counted include CRC-32 errors, SAR time-out errors, and oversized SDU errors. ifInUnknownProtos Set to 0. ifInDiscards Number of received AAL5 CPCS PDUs discarded. Possible reason may be input buffer overflow. ifOutErrors Number of AAL5 CPCS PDUs that could not be transmitted due to errors. ifOutDiscards Number of AAL5 CPCS PDUs received for transmission that are discarded. Possible reason may be output buffer overflow. ifInMulticastPkts Set to 0. ifInBroadcastPkts Set to 0. ifOutMulticastPkts Set to 0. ifOutBroadcastPkts Set to 0. ifName Textual name (unique on this system) of the AAL5 entity or an octet string of zero length. ifHighSpeed Set to 0. ifConnectorPresent Set to false (2). ifPromiscuousMode Set to false(2). ifLinkUpDownTrapEnable Default is disabled (2). ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. 7.4. Support of Proprietary Virtual Interface by ifTable Specific interpretations of ifTable for the proprietary virtual, internal interface associated with an AAL5 entity in an ATM switch are as follows. Tesink Standards Track [Page 16] RFC 2515 ATM Management Objects February 1999 Object Use for proprietary virtual, internal interface associated with AAL entities ====== =============================================== ifIndex Each proprietary virtual, internal interface associated with AAL entities is represented by an ifEntry. ifDescr Description of the proprietary virtual, internal interface associated with AAL entities. ifType The value that is allocated for proprietary virtual, internal interface is 53. ifSpeed See [17]. Set to 0 if the speed is not known. ifPhysAddress See [17]. An octet string of zero length if no address is used for this interface. ifAdminStatus See [17]. ifOperStatus See [17]. ifLastChange See [17]. ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifHighSpeed See [17]. Set to 0 if the speed is not known. ifConnectorPresent Set to false (2). ifLinkUpDownTrapEnable Default is disabled (2). ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. 7.5. AAL5 Connection Performance Statistics Table An AAL5 connection table is used to provide AAL5 performance information for each AAL5 virtual connection that is terminated at the AAL5 entity contained within an ATM switch or host. Tesink Standards Track [Page 17] RFC 2515 ATM Management Objects February 1999 8. ILMI MIBs and the ATM Managed Objects The ILMI MIBs are specified by the ATM Forum as a set of several MIBs, all currently defined in the ILMI Specification [23]. The ILMI protocols and MIBs allow two connected ATM Interface Management Entities (IMEs) to exchange bi-directional parameters, mainly to facilitate auto-configuration between ATM peer entities. The support of the ATM management functions by the ILMI MIBs and those contained in this memo are compared in Table 1. In this table, "yes" in the "ILMI MIBs" column indicates that the management functions are supported by the ILMI MIBs. The parenthesized numbers in the "This memo" column correspond to the sets of tables enumerated in Section 6.2. For that subset of management information which the ILMI MIBs and this memo have in common, every effort has been made to retain identical semantics and syntax, even though the MIB objects are identified using different OBJECT IDENTIFIERs. Table 1 - Structuring of ATM Managed Objects ______________________________________________________________ | |This |ILMI| ATM Mgmt.Inf. |ATM Managed Objects |memo |MIBs| ______________|_________________________________|_______|____| Local Interface Information: _____________________________________________________________ ATM interface:| (1) port identifier |ATM MIB| | physical layer| (2) physical transmission types | (1)*|yes | configuration | (3) operational status |MIB II | * | | (4) administrative status | | ** | | (5) last change status | | | _____________________________________________________________ ATM interface:| (1) active VPI/VCI fields |ATM MIB| | cell layer | (2) maximum number of VPCs/VCCs | (1) |yes | configuration | (3) configured VPCs/VCCs | | ** | | (4) ILMI VPI/VCI values | | | | (5) Neighbor system info | | | | (6) Max. number of VPI/VCI bits | |yes | | (7) ATM Subscribed Address | | | _____________________________________________________________ ATM interface:|(1) received/transmitted cells | | | cell layer |(2) cells with HEC error |MIB II |yes | performance |(3) cell header validation errors| | | _____________________________________________________________ Tesink Standards Track [Page 18] RFC 2515 ATM Management Objects February 1999 _____________________________________________________________ ATM interface:|(1)DS3 PLCP severely errored |ATM MIB| | PLCP & TC | framing seconds | (2)| | layer |(2)DS3 PLCP unavailable seconds | |no | performance |(3)DS3 PLCP alarm state | | | |(4)out of cell delineation events| | | |(5)TC alarm state | | | _____________________________________________________________ VP/VC link: |(1)VPI or VPI/VCI value |ATM MIB| | configuration |(2)VCL or VPL operational status | (3,4)|yes | |(3)VCL/VPL administrative status | |*** | |(4)VCL/VPL last change status | | | |(5)transmit/receive traffic/ | | | | service category parameters | | | |(6)AAL type | | | |(7)transmit/receive AAL5 SDU size| | | |(8)AAL5 encapsulation type | | | |(9)connection topology type | | | |(10)use of call control | | | _____________________________________________________________ VP/VC |(1)cross-connect identifier | | | Cross-connect:|(2)port identifier of one | | | configuration | end | | | |(3)port identifier of the other |ATM MIB| | | end | (5)|no | |(4)VPI or VPI/VCI value | | | | of one end | | | |(5)VPI or VPI/VCI value of | | | | the other end | | | |(6)VC/VP cross-connect | | | | operational status | | | |(7)VC/VP cross-connect | | | | administrative status | | | |(8)VC/VP last change status | | | _____________________________________________________________ VCC AAL5 CPCS |(1)PDUs discarded for CRC errors |ATM MIB| | layer: |(2)PDUs discarded due to | (6) | | performance | reassembly time out | |no | |(3)PDUs discarded due to large | | | | SDUs | | | _____________________________________________________________ AAL5 entity: |(1)received/transmitted PDUs | | | |(2)PDUs discarded due to | | | | protocol errors |MIB II |no | |(3)a set of configuration/state | | | | parameters | | | _____________________________________________________________ Tesink Standards Track [Page 19] RFC 2515 ATM Management Objects February 1999 *The operational, administrative, and last change status of the ATM interface and the physical transmission type shall be supported by the interface table in MIB II [16][17]. ILMI does not contain the administrative and last change status of the ATM interface. ** The ILMI MIB contains read-only objects for various parameters at the ATM interface level. ***The ILMI MIBs contain local and end-to-end operational status of the VPC/VCC segment. However, it does not contain the VPC/VCC administrative and last change status and the VCC AAL information. 9. Definitions ATM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, IpAddress, mib-2 FROM SNMPv2-SMI DisplayString, RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndex, ifIndex FROM IF-MIB AtmAddr, AtmConnKind, AtmConnCastType, AtmServiceCategory, AtmTrafficDescrParamIndex, AtmVpIdentifier, AtmVcIdentifier, AtmVorXAdminStatus, AtmVorXLastChange, AtmVorXOperStatus, atmNoClpNoScr FROM ATM-TC-MIB; atmMIB MODULE-IDENTITY LAST-UPDATED "9810191200Z" ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO " Kaj Tesink Postal: Bellcore 331 Newman Springs Road Red Bank, NJ 07701 Tel: 732-758-5254 Fax: 732-758-2269 E-mail: kaj@bellcore.com" DESCRIPTION "This is the MIB Module for ATM and AAL5-related objects for managing ATM interfaces, ATM virtual Tesink Standards Track [Page 20] RFC 2515 ATM Management Objects February 1999 links, ATM cross-connects, AAL5 entities, and and AAL5 connections." REVISION "9810191200Z" DESCRIPTION "The initial revision of this module was published as RFC 1695. Key revisions include: o Textual Conventions and OBJECT IDENTITIES have been moved to a separate MIB module. o Applicability of objects to PVCs, SVCs and Soft PVCs has been clarified. o DEFVAL clauses have been added. o The relationship of ifIndex values with different layers and sublayers related to ATM has been clarified. o atmTrafficQosClass has been deprecated and replaced with atmServiceCategory. o atmInterfaceCurrentMaxVpiBits and atmInterfaceCurrentMaxVciBits have been added with a description on their relationship with other objects. o atmInterfaceAddressType and atmInterfaceAdminAddress have been deprecated and replaced by atmInterfaceSubscrAddress. o atmInterfaceTCAlarmState has been clarified. o atmTrafficDescrParamIndexNext has been introduced in order to provide a manager a free atmTrafficDescrParamIndex value. o The atmTrafficFrameDiscard capability has been added. o A connection topology type (atmVpl/VclCastType) and a call control type (atmVpl/VclConnKind) have been added. o aal2 has been added to atmVccAalType." REVISION "9406072245Z" DESCRIPTION "The RFC1695 version of this MIB module." ::= { mib-2 37 } atmMIBObjects OBJECT IDENTIFIER ::= {atmMIB 1} -- {atmMIBObjects 1} has been moved to a separate -- specification [19]. -- This ATM MIB Module consists of the following tables: -- (1) ATM Interface configuration table -- (2) ATM Interface DS3 PLCP table -- (3) ATM Interface TC Sublayer table Tesink Standards Track [Page 21] RFC 2515 ATM Management Objects February 1999 -- (4) Atm Traffic Descriptor table -- (5) ATM Interface VPL configuration table -- (6) ATM Interface VCL configuration table -- (7) ATM VP Cross Connect table (for PVCs) -- (8) ATM VC Cross Connect table (for PVCs) -- (9) ATM Interface AAL5 VCC performance statistics -- table -- ATM Interface Configuration Parameters Table -- This table contains ATM specific -- configuration information associated with -- an ATM interface beyond those -- supported using the ifTable. atmInterfaceConfTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM local interface configuration parameters, one entry per ATM interface port." ::= { atmMIBObjects 2 } atmInterfaceConfEntry OBJECT-TYPE SYNTAX AtmInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains ATM interface configuration parameters and state variables and is indexed by ifIndex values of ATM interfaces." INDEX { ifIndex } ::= { atmInterfaceConfTable 1} AtmInterfaceConfEntry ::= SEQUENCE { atmInterfaceMaxVpcs INTEGER, atmInterfaceMaxVccs INTEGER, atmInterfaceConfVpcs INTEGER, atmInterfaceConfVccs INTEGER, atmInterfaceMaxActiveVpiBits INTEGER, atmInterfaceMaxActiveVciBits INTEGER, atmInterfaceIlmiVpi AtmVpIdentifier, atmInterfaceIlmiVci AtmVcIdentifier, Tesink Standards Track [Page 22] RFC 2515 ATM Management Objects February 1999 atmInterfaceAddressType INTEGER, atmInterfaceAdminAddress AtmAddr, atmInterfaceMyNeighborIpAddress IpAddress, atmInterfaceMyNeighborIfName DisplayString, atmInterfaceCurrentMaxVpiBits INTEGER, atmInterfaceCurrentMaxVciBits INTEGER, atmInterfaceSubscrAddress AtmAddr } atmInterfaceMaxVpcs OBJECT-TYPE SYNTAX INTEGER (0..4096) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of VPCs (PVPCs and SVPCs) supported at this ATM interface. At the ATM UNI, the maximum number of VPCs (PVPCs and SVPCs) ranges from 0 to 256 only." ::= { atmInterfaceConfEntry 1} atmInterfaceMaxVccs OBJECT-TYPE SYNTAX INTEGER (0..65536) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of VCCs (PVCCs and SVCCs) supported at this ATM interface." ::= { atmInterfaceConfEntry 2} atmInterfaceConfVpcs OBJECT-TYPE SYNTAX INTEGER (0..4096) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VPCs (PVPC, Soft PVPC and SVPC) currently in use at this ATM interface. It includes the number of PVPCs and Soft PVPCs that are configured at the interface, plus the number of SVPCs that are currently established at the interface. At the ATM UNI, the configured number of VPCs (PVPCs and SVPCs) can range from 0 to 256 only." ::= { atmInterfaceConfEntry 3} atmInterfaceConfVccs OBJECT-TYPE Tesink Standards Track [Page 23] RFC 2515 ATM Management Objects February 1999 SYNTAX INTEGER (0..65536) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VCCs (PVCC, Soft PVCC and SVCC) currently in use at this ATM interface. It includes the number of PVCCs and Soft PVCCs that are configured at the interface, plus the number of SVCCs that are currently established at the interface." ::= { atmInterfaceConfEntry 4} atmInterfaceMaxActiveVpiBits OBJECT-TYPE SYNTAX INTEGER (0..12) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of active VPI bits configured for use at the ATM interface. At the ATM UNI, the maximum number of active VPI bits configured for use ranges from 0 to 8 only." ::= { atmInterfaceConfEntry 5} atmInterfaceMaxActiveVciBits OBJECT-TYPE SYNTAX INTEGER (0..16) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of active VCI bits configured for use at this ATM interface." ::= { atmInterfaceConfEntry 6} atmInterfaceIlmiVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-write STATUS current DESCRIPTION "The VPI value of the VCC supporting the ILMI at this ATM interface. If the values of atmInterfaceIlmiVpi and atmInterfaceIlmiVci are both equal to zero then the ILMI is not supported at this ATM interface." DEFVAL { 0 } ::= { atmInterfaceConfEntry 7} atmInterfaceIlmiVci OBJECT-TYPE SYNTAX AtmVcIdentifier Tesink Standards Track [Page 24] RFC 2515 ATM Management Objects February 1999 MAX-ACCESS read-write STATUS current DESCRIPTION "The VCI value of the VCC supporting the ILMI at this ATM interface. If the values of atmInterfaceIlmiVpi and atmInterfaceIlmiVci are both equal to zero then the ILMI is not supported at this ATM interface." DEFVAL { 16 } ::= { atmInterfaceConfEntry 8} atmInterfaceAddressType OBJECT-TYPE SYNTAX INTEGER { private(1), nsapE164(2), nativeE164(3), other(4) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The type of primary ATM address configured for use at this ATM interface." ::= { atmInterfaceConfEntry 9 } -- The atmInterfaceAdminAddress object has been replaced by -- atmInterfaceSubscrAddress. atmInterfaceAdminAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The primary address assigned for administrative purposes, for example, an address associated with the service provider side of a public network UNI (thus, the value of this address corresponds with the value of ifPhysAddress at the host side). If this interface has no assigned administrative address, or when the address used for administrative purposes is the same as that used for ifPhysAddress, then this is an octet string of zero length." ::= { atmInterfaceConfEntry 10 } atmInterfaceMyNeighborIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write Tesink Standards Track [Page 25] RFC 2515 ATM Management Objects February 1999 STATUS current DESCRIPTION "The IP address of the neighbor system connected to the far end of this interface, to which a Network Management Station can send SNMP messages, as IP datagrams sent to UDP port 161, in order to access network management information concerning the operation of that system. Note that the value of this object may be obtained in different ways, e.g., by manual configuration, or through ILMI interaction with the neighbor system." ::= { atmInterfaceConfEntry 11 } atmInterfaceMyNeighborIfName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The textual name of the interface on the neighbor system on the far end of this interface, and to which this interface connects. If the neighbor system is manageable through SNMP and supports the object ifName, the value of this object must be identical with that of ifName for the ifEntry of the lowest level physical interface for this port. If this interface does not have a textual name, the value of this object is a zero length string. Note that the value of this object may be obtained in different ways, e.g., by manual configuration, or through ILMI interaction with the neighbor system." ::= { atmInterfaceConfEntry 12 } atmInterfaceCurrentMaxVpiBits OBJECT-TYPE SYNTAX INTEGER (0..12) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of VPI Bits that may currently be used at this ATM interface. The value is the minimum of atmInterfaceMaxActiveVpiBits, and the atmInterfaceMaxActiveVpiBits of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the number of VPI Bits that can be used on the interface, then the Tesink Standards Track [Page 26] RFC 2515 ATM Management Objects February 1999 value of this object must equal atmInterfaceMaxActiveVpiBits." ::= { atmInterfaceConfEntry 13 } atmInterfaceCurrentMaxVciBits OBJECT-TYPE SYNTAX INTEGER (0..16) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of VCI Bits that may currently be used at this ATM interface. The value is the minimum of atmInterfaceMaxActiveVciBits, and the atmInterfaceMaxActiveVciBits of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the number of VCI Bits that can be used on the interface, then the value of this object must equal atmInterfaceMaxActiveVciBits." ::= { atmInterfaceConfEntry 14 } atmInterfaceSubscrAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-write STATUS current DESCRIPTION "The identifier assigned by a service provider to the network side of a public network UNI. If this interface has no assigned service provider address, or for other interfaces this is an octet string of zero length." ::= { atmInterfaceConfEntry 15 } -- The ATM Interface DS3 PLCP Table -- This table contains the DS3 PLCP configuration and -- state parameters of those ATM interfaces -- which use DS3 PLCP for carrying ATM cells over DS3. atmInterfaceDs3PlcpTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceDs3PlcpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM interface DS3 PLCP parameters and state variables, one entry per Tesink Standards Track [Page 27] RFC 2515 ATM Management Objects February 1999 ATM interface port." ::= { atmMIBObjects 3} atmInterfaceDs3PlcpEntry OBJECT-TYPE SYNTAX AtmInterfaceDs3PlcpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains DS3 PLCP parameters and state variables at the ATM interface and is indexed by the ifIndex value of the ATM interface." INDEX { ifIndex } ::= { atmInterfaceDs3PlcpTable 1} AtmInterfaceDs3PlcpEntry ::= SEQUENCE { atmInterfaceDs3PlcpSEFSs Counter32, atmInterfaceDs3PlcpAlarmState INTEGER, atmInterfaceDs3PlcpUASs Counter32 } atmInterfaceDs3PlcpSEFSs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of DS3 PLCP Severely Errored Framing Seconds (SEFS). Each SEFS represents a one-second interval which contains one or more SEF events." ::= { atmInterfaceDs3PlcpEntry 1} atmInterfaceDs3PlcpAlarmState OBJECT-TYPE SYNTAX INTEGER { noAlarm(1), receivedFarEndAlarm(2), incomingLOF(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is an alarm present for the DS3 PLCP. The value receivedFarEndAlarm means that the DS3 PLCP has received an incoming Yellow Signal, the value incomingLOF means that the DS3 PLCP has declared a loss of frame (LOF) failure condition, and the value noAlarm Tesink Standards Track [Page 28] RFC 2515 ATM Management Objects February 1999 means that there are no alarms present. Transition from the failure to the no alarm state occurs when no defects (e.g., LOF) are received for more than 10 seconds." ::= { atmInterfaceDs3PlcpEntry 2} atmInterfaceDs3PlcpUASs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by the PLCP." ::= { atmInterfaceDs3PlcpEntry 3} -- The ATM Interface TC Sublayer Table -- This table contains TC sublayer configuration and -- state parameters of those ATM interfaces -- which use TC sublayer for carrying ATM cells over -- SONET/SDH or DS3. atmInterfaceTCTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceTCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM interface TC Sublayer parameters and state variables, one entry per ATM interface port." ::= { atmMIBObjects 4} atmInterfaceTCEntry OBJECT-TYPE SYNTAX AtmInterfaceTCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains TC Sublayer parameters and state variables at the ATM interface and is indexed by the ifIndex value of the ATM interface." INDEX {ifIndex } ::= { atmInterfaceTCTable 1} AtmInterfaceTCEntry ::= SEQUENCE { atmInterfaceOCDEvents Counter32, atmInterfaceTCAlarmState INTEGER Tesink Standards Track [Page 29] RFC 2515 ATM Management Objects February 1999 } atmInterfaceOCDEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the Out of Cell Delineation (OCD) events occur. If seven consecutive ATM cells have Header Error Control (HEC) violations, an OCD event occurs. A high number of OCD events may indicate a problem with the TC Sublayer." ::= { atmInterfaceTCEntry 1} atmInterfaceTCAlarmState OBJECT-TYPE SYNTAX INTEGER { noAlarm(1), lcdFailure(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is an alarm present for the TC Sublayer. The value lcdFailure(2) indicates that the TC Sublayer is currently in the Loss of Cell Delineation (LCD) defect maintenance state. The value noAlarm(1) indicates that the TC Sublayer is currently not in the LCD defect maintenance state." ::= { atmInterfaceTCEntry 2} -- ATM Traffic Descriptor Parameter Table -- This table contains a set of self-consistent -- ATM traffic parameters including the -- ATM traffic service category. -- The ATM virtual link tables (i.e., VPL and VCL tables) -- will use this ATM Traffic Descriptor table -- to assign traffic parameters and service category -- to the receive and transmit directions of -- the ATM virtual links (i.e., VPLs and VCLs). -- The ATM VPL or VCL table will indicate a row -- in the atmTrafficDescrParamTable -- using its atmTrafficDescrParamIndex value. Tesink Standards Track [Page 30] RFC 2515 ATM Management Objects February 1999 -- The management application can then compare a set of -- ATM traffic parameters with a single value. -- If no suitable row(s) in the atmTrafficDescrParamTable -- exists, the manager must create a new row(s) in this -- table. If such a row is created, agent checks the -- sanity of that set of ATM traffic parameter values. -- The manager may use atmTrafficDescrParamIndexNext -- in order to obtain a free atmTrafficDescrParamIndex -- value. -- When creating a new row, the parameter values -- will be checked for self-consistency. -- Predefined/template rows may be supported. -- A row in the atmTrafficDescrParamTable is deleted -- by setting the atmTrafficDescrRowStatus to destroy(6). -- The agent will check whether this row is still in use -- by any entry of the atmVplTable or atmVclTable. -- The agent denies the request if the row is still in -- use. -- The ATM Traffic Descriptor Parameter Table atmTrafficDescrParamTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmTrafficDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on ATM traffic descriptor type and the associated parameters." ::= { atmMIBObjects 5} atmTrafficDescrParamEntry OBJECT-TYPE SYNTAX AtmTrafficDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains ATM traffic descriptor type and the associated parameters." INDEX {atmTrafficDescrParamIndex} ::= { atmTrafficDescrParamTable 1} AtmTrafficDescrParamEntry ::= SEQUENCE { atmTrafficDescrParamIndex AtmTrafficDescrParamIndex, atmTrafficDescrType OBJECT IDENTIFIER, Tesink Standards Track [Page 31] RFC 2515 ATM Management Objects February 1999 atmTrafficDescrParam1 Integer32, atmTrafficDescrParam2 Integer32, atmTrafficDescrParam3 Integer32, atmTrafficDescrParam4 Integer32, atmTrafficDescrParam5 Integer32, atmTrafficQoSClass INTEGER, atmTrafficDescrRowStatus RowStatus, atmServiceCategory AtmServiceCategory, atmTrafficFrameDiscard TruthValue } atmTrafficDescrParamIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used by the virtual link table (i.e., VPL or VCL table) to identify the row of this table. When creating a new row in the table the value of this index may be obtained by retrieving the value of atmTrafficDescrParamIndexNext." ::= { atmTrafficDescrParamEntry 1} atmTrafficDescrType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the type of ATM traffic descriptor. The type may indicate no traffic descriptor or traffic descriptor with one or more parameters. These parameters are specified as a parameter vector, in the corresponding instances of the objects: atmTrafficDescrParam1 atmTrafficDescrParam2 atmTrafficDescrParam3 atmTrafficDescrParam4 atmTrafficDescrParam5." DEFVAL { atmNoClpNoScr } ::= { atmTrafficDescrParamEntry 2} atmTrafficDescrParam1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create Tesink Standards Track [Page 32] RFC 2515 ATM Management Objects February 1999 STATUS current DESCRIPTION "The first parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 3} atmTrafficDescrParam2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The second parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 4} atmTrafficDescrParam3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The third parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 5} atmTrafficDescrParam4 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The fourth parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 6} atmTrafficDescrParam5 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The fifth parameter of the ATM traffic descriptor used according to the value of Tesink Standards Track [Page 33] RFC 2515 ATM Management Objects February 1999 atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 7} atmTrafficQoSClass OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The value of this object identifies the QoS Class. Four Service classes have been specified in the ATM Forum UNI Specification: Service Class A: Constant bit rate video and Circuit emulation Service Class B: Variable bit rate video/audio Service Class C: Connection-oriented data Service Class D: Connectionless data Four QoS classes numbered 1, 2, 3, and 4 have been specified with the aim to support service classes A, B, C, and D respectively. An unspecified QoS Class numbered `0' is used for best effort traffic." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 8} atmTrafficDescrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table." DEFVAL { active } ::= {atmTrafficDescrParamEntry 9} atmServiceCategory OBJECT-TYPE SYNTAX AtmServiceCategory MAX-ACCESS read-create STATUS current DESCRIPTION "The ATM service category." DEFVAL { ubr } ::= { atmTrafficDescrParamEntry 10} atmTrafficFrameDiscard OBJECT-TYPE SYNTAX TruthValue Tesink Standards Track [Page 34] RFC 2515 ATM Management Objects February 1999 MAX-ACCESS read-create STATUS current DESCRIPTION "If set to 'true', this object indicates that the network is requested to treat data for this connection, in the given direction, as frames (e.g. AAL5 CPCS_PDU's) rather than as individual cells. While the precise implementation is network-specific, this treatment may for example involve discarding entire frames during congestion, rather than a few cells from many frames." DEFVAL { true } ::= { atmTrafficDescrParamEntry 11 } -- ATM Interface Virtual Path Link (VPL) Table -- This table contains configuration and state -- information of a bi-directional Virtual Path Link -- (VPL) -- This table can be used to create, delete or modify -- a VPL that is terminated in an ATM host or switch. -- This table can also be used to create, delete or -- modify a VPL which is cross-connected to another -- VPL. -- In the example below, the traffic flows on the receive -- and transmit directions of the VPLs are characterized -- by atmVplReceiveTrafficDescrIndex and -- atmVplTransmitTrafficDescrIndex respectively. -- The cross-connected VPLs are identified by -- atmVplCrossConnectIdentifier. -- ________________________________ -- | | -- VPL | ATM Host, Switch, or Network | VPL -- receive | | receive -- ========> X X <======= -- <======== X X ========> -- transmit | | transmit -- |______________________________| -- The ATM Interface VPL Table Tesink Standards Track [Page 35] RFC 2515 ATM Management Objects February 1999 atmVplTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Virtual Path Link (VPL) table. A bi-directional VPL is modeled as one entry in this table. This table can be used for PVCs, SVCs and Soft PVCs. Entries are not present in this table for the VPIs used by entries in the atmVclTable." ::= { atmMIBObjects 6} atmVplEntry OBJECT-TYPE SYNTAX AtmVplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the VPL table. This entry is used to model a bi-directional VPL. To create a VPL at an ATM interface, either of the following procedures are used: Negotiated VPL establishment (1) The management application creates a VPL entry in the atmVplTable by setting atmVplRowStatus to createAndWait(5). This may fail for the following reasons: - The selected VPI value is unavailable, - The selected VPI value is in use. Otherwise, the agent creates a row and reserves the VPI value on that port. (2) The manager selects an existing row(s) in the atmTrafficDescrParamTable, thereby, selecting a set of self-consistent ATM traffic parameters and the service category for receive and transmit directions of the VPL. (2a) If no suitable row(s) in the atmTrafficDescrParamTable exists, the manager must create a new row(s) in that table. (2b) The manager characterizes the VPL's traffic parameters through setting the atmVplReceiveTrafficDescrIndex and the Tesink Standards Track [Page 36] RFC 2515 ATM Management Objects February 1999 atmVplTransmitTrafficDescrIndex values in the VPL table, which point to the rows containing desired ATM traffic parameter values in the atmTrafficDescrParamTable. The agent will check the availability of resources and may refuse the request. If the transmit and receive service categories are inconsistent, the agent should refuse the request. (3) The manager activates the VPL by setting the the atmVplRowStatus to active(1). If this set is successful, the agent has reserved the resources to satisfy the requested traffic parameter values and the service category for that VPL. (4) If the VPL terminates a VPC in the ATM host or switch, the manager turns on the atmVplAdminStatus to up(1) to turn the VPL traffic flow on. Otherwise, the atmVpCrossConnectTable must be used to cross-connect the VPL to another VPL(s) in an ATM switch or network. One-Shot VPL Establishment A VPL may also be established in one step by a set-request with all necessary VPL parameter values and atmVplRowStatus set to createAndGo(4). In contrast to the negotiated VPL establishment which allows for detailed error checking (i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VPL establishment performs the setup on one operation but does not have the advantage of step-wise error checking. VPL Retirement A VPL is released by setting atmVplRowStatus to destroy(6), and the agent may release all associated resources." INDEX {ifIndex, atmVplVpi } ::= { atmVplTable 1} Tesink Standards Track [Page 37] RFC 2515 ATM Management Objects February 1999 AtmVplEntry ::= SEQUENCE { atmVplVpi AtmVpIdentifier, atmVplAdminStatus AtmVorXAdminStatus, atmVplOperStatus AtmVorXOperStatus, atmVplLastChange AtmVorXLastChange, atmVplReceiveTrafficDescrIndex AtmTrafficDescrParamIndex, atmVplTransmitTrafficDescrIndex AtmTrafficDescrParamIndex, atmVplCrossConnectIdentifier INTEGER, atmVplRowStatus RowStatus, atmVplCastType AtmConnCastType, atmVplConnKind AtmConnKind } atmVplVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value of the VPL." ::= { atmVplEntry 1} atmVplAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is instanciated only for a VPL which terminates a VPC (i.e., one which is NOT cross-connected to other VPLs). Its value specifies the desired administrative state of the VPL." DEFVAL { down } ::= { atmVplEntry 2} atmVplOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VPL." ::= { atmVplEntry 3} atmVplLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only Tesink Standards Track [Page 38] RFC 2515 ATM Management Objects February 1999 STATUS current DESCRIPTION "The value of sysUpTime at the time this VPL entered its current operational state." ::= { atmVplEntry 4 } atmVplReceiveTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the atmTrafficDescrParamTable which applies to the receive direction of the VPL." DEFVAL { 0 } ::= { atmVplEntry 5} atmVplTransmitTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the atmTrafficDescrParamTable which applies to the transmit direction of the VPL." DEFVAL { 0 } ::= { atmVplEntry 6} atmVplCrossConnectIdentifier OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is instantiated only for a VPL which is cross-connected to other VPLs that belong to the same VPC. All such associated VPLs have the same value of this object, and all their cross-connections are identified either by entries that are indexed by the same value of atmVpCrossConnectIndex in the atmVpCrossConnectTable of this MIB module or by the same value of the cross-connect index in the cross-connect table for SVCs and Soft PVCs (defined in a separate MIB module). At no time should entries in these respective cross-connect tables exist simultaneously with the same cross-connect index value. Tesink Standards Track [Page 39] RFC 2515 ATM Management Objects February 1999 The value of this object is initialized by the agent after the associated entries in the atmVpCrossConnectTable have been created." ::= {atmVplEntry 7} atmVplRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, delete or modify a row in this table. To create a new VCL, this object is initially set to 'createAndWait' or 'createAndGo'. This object should not be set to 'active' unless the following columnar objects have been set to their desired value in this row: atmVplReceiveTrafficDescrIndex and atmVplTransmitTrafficDescrIndex. The DESCRIPTION of atmVplEntry provides further guidance to row treatment in this table." DEFVAL { createAndWait } ::= {atmVplEntry 8} atmVplCastType OBJECT-TYPE SYNTAX AtmConnCastType MAX-ACCESS read-create STATUS current DESCRIPTION "The connection topology type." DEFVAL { p2p } ::= {atmVplEntry 9} atmVplConnKind OBJECT-TYPE SYNTAX AtmConnKind MAX-ACCESS read-create STATUS current DESCRIPTION "The use of call control." DEFVAL { pvc } ::= {atmVplEntry 10} -- ATM Interface Virtual Channel Link (VCL) Table -- This table contains configuration and state -- information of a bi-directional Virtual Channel -- Link (VCL) at an ATM interface. Tesink Standards Track [Page 40] RFC 2515 ATM Management Objects February 1999 -- This table can be used to create, delete or modify -- a VCL that is terminated in an ATM host or switch. -- This table can also be -- used to create, delete or modify a VCL that is -- cross-connected to another VCL. -- The ATM Interface VCL Table atmVclTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Virtual Channel Link (VCL) table. A bi-directional VCL is modeled as one entry in this table. This table can be used for PVCs, SVCs and Soft PVCs." ::= { atmMIBObjects 7} atmVclEntry OBJECT-TYPE SYNTAX AtmVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the VCL table. This entry is used to model a bi-directional VCL. To create a VCL at an ATM interface, either of the following procedures are used: Negotiated VCL establishment (1) The management application creates a VCL entry in the atmVclTable by setting atmVclRowStatus to createAndWait(5). This may fail for the following reasons: - The selected VPI/VCI values are unavailable, - The selected VPI/VCI values are in use. Otherwise, the agent creates a row and reserves the VPI/VCI values on that port. (2) The manager selects an existing row(s) in the atmTrafficDescrParamTable, thereby, selecting a set of self-consistent ATM traffic parameters and the service category for receive and transmit directions of the VCL. Tesink Standards Track [Page 41] RFC 2515 ATM Management Objects February 1999 (2a) If no suitable row(s) in the atmTrafficDescrParamTable exists, the manager must create a new row(s) in that table. (2b) The manager characterizes the VCL's traffic parameters through setting the atmVclReceiveTrafficDescrIndex and the atmVclTransmitTrafficDescrIndex values in the VCL table, which point to the rows containing desired ATM traffic parameter values in the atmTrafficDescrParamTable. The agent will check the availability of resources and may refuse the request. If the transmit and receive service categories are inconsistent, the agent should refuse the request. (3) The manager activates the VCL by setting the the atmVclRowStatus to active(1) (for requirements on this activation see the description of atmVclRowStatus). If this set is successful, the agent has reserved the resources to satisfy the requested traffic parameter values and the service category for that VCL. (4) If the VCL terminates a VCC in the ATM host or switch, the manager turns on the atmVclAdminStatus to up(1) to turn the VCL traffic flow on. Otherwise, the atmVcCrossConnectTable must be used to cross-connect the VCL to another VCL(s) in an ATM switch or network. One-Shot VCL Establishment A VCL may also be established in one step by a set-request with all necessary VCL parameter values and atmVclRowStatus set to createAndGo(4). In contrast to the negotiated VCL establishment which allows for detailed error checking (i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VCL establishment performs the setup on one operation but does not have the advantage of step-wise error checking. Tesink Standards Track [Page 42] RFC 2515 ATM Management Objects February 1999 VCL Retirement A VCL is released by setting atmVclRowStatus to destroy(6), and the agent may release all associated resources." INDEX {ifIndex, atmVclVpi, atmVclVci } ::= { atmVclTable 1} AtmVclEntry ::= SEQUENCE { atmVclVpi AtmVpIdentifier, atmVclVci AtmVcIdentifier, atmVclAdminStatus AtmVorXAdminStatus, atmVclOperStatus AtmVorXOperStatus, atmVclLastChange AtmVorXLastChange, atmVclReceiveTrafficDescrIndex AtmTrafficDescrParamIndex, atmVclTransmitTrafficDescrIndex AtmTrafficDescrParamIndex, atmVccAalType INTEGER, atmVccAal5CpcsTransmitSduSize INTEGER, atmVccAal5CpcsReceiveSduSize INTEGER, atmVccAal5EncapsType INTEGER, atmVclCrossConnectIdentifier INTEGER, atmVclRowStatus RowStatus, atmVclCastType AtmConnCastType, atmVclConnKind AtmConnKind } atmVclVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value of the VCL." ::= { atmVclEntry 1} atmVclVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value of the VCL." ::= { atmVclEntry 2} atmVclAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current Tesink Standards Track [Page 43] RFC 2515 ATM Management Objects February 1999 DESCRIPTION "This object is instanciated only for a VCL which terminates a VCC (i.e., one which is NOT cross-connected to other VCLs). Its value specifies the desired administrative state of the VCL." DEFVAL { down } ::= { atmVclEntry 3} atmVclOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VCL." ::= { atmVclEntry 4} atmVclLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VCL entered its current operational state." ::= { atmVclEntry 5 } atmVclReceiveTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ATM Traffic Descriptor Table which applies to the receive direction of this VCL." DEFVAL { 0 } ::= { atmVclEntry 6} atmVclTransmitTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row of the ATM Traffic Descriptor Table which applies to the transmit direction of this VCL." DEFVAL { 0 } ::= { atmVclEntry 7} Tesink Standards Track [Page 44] RFC 2515 ATM Management Objects February 1999 atmVccAalType OBJECT-TYPE SYNTAX INTEGER { aal1(1), aal34(2), aal5(3), other(4), unknown(5), aal2(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL is in use. The type of AAL used on this VCC. The AAL type includes AAL1, AAL2, AAL3/4, and AAL5. The other(4) may be user-defined AAL type. The unknown type indicates that the AAL type cannot be determined." DEFVAL { aal5 } ::= { atmVclEntry 8 } atmVccAal5CpcsTransmitSduSize OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL5 is in use. The maximum AAL5 CPCS SDU size in octets that is supported on the transmit direction of this VCC." DEFVAL { 9188 } ::= { atmVclEntry 9 } atmVccAal5CpcsReceiveSduSize OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL5 is in use. The maximum AAL5 CPCS SDU size in octets that is supported on the receive direction of this VCC." DEFVAL { 9188 } ::= { atmVclEntry 10 } Tesink Standards Track [Page 45] RFC 2515 ATM Management Objects February 1999 atmVccAal5EncapsType OBJECT-TYPE SYNTAX INTEGER { vcMultiplexRoutedProtocol(1), vcMultiplexBridgedProtocol8023(2), vcMultiplexBridgedProtocol8025(3), vcMultiplexBridgedProtocol8026(4), vcMultiplexLANemulation8023(5), vcMultiplexLANemulation8025(6), llcEncapsulation(7), multiprotocolFrameRelaySscs(8), other(9), unknown(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL5 is in use. The type of data encapsulation used over the AAL5 SSCS layer. The definitions reference RFC 1483 Multiprotocol Encapsulation over ATM AAL5 and to the ATM Forum LAN Emulation specification." DEFVAL { llcEncapsulation } ::= { atmVclEntry 11 } atmVclCrossConnectIdentifier OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is instantiated only for a VCL which is cross-connected to other VCLs that belong to the same VCC. All such associated VCLs have the same value of this object, and all their cross-connections are identified either by entries that are indexed by the same value of atmVcCrossConnectIndex in the atmVcCrossConnectTable of this MIB module or by the same value of the cross-connect index in the cross-connect table for SVCs and Soft PVCs (defined in a separate MIB module). At no time should entries in these respective cross-connect tables exist simultaneously with the same cross-connect index value. Tesink Standards Track [Page 46] RFC 2515 ATM Management Objects February 1999 The value of this object is initialized by the agent after the associated entries in the atmVcCrossConnectTable have been created." ::= {atmVclEntry 12} atmVclRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, delete or modify a row in this table. To create a new VCL, this object is initially set to 'createAndWait' or 'createAndGo'. This object should not be set to 'active' unless the following columnar objects have been set to their desired value in this row: atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex. In addition, if the local VCL end-point is also the VCC end-point: atmVccAalType. In addition, for AAL5 connections only: atmVccAal5CpcsTransmitSduSize, atmVccAal5CpcsReceiveSduSize, and atmVccAal5EncapsType. (The existence of these objects imply the AAL connection type.). The DESCRIPTION of atmVclEntry provides further guidance to row treatment in this table." DEFVAL { createAndWait } ::= {atmVclEntry 13} atmVclCastType OBJECT-TYPE SYNTAX AtmConnCastType MAX-ACCESS read-create STATUS current DESCRIPTION "The connection topology type." DEFVAL { p2p } ::= {atmVclEntry 14} atmVclConnKind OBJECT-TYPE SYNTAX AtmConnKind MAX-ACCESS read-create STATUS current DESCRIPTION Tesink Standards Track [Page 47] RFC 2515 ATM Management Objects February 1999 "The use of call control." DEFVAL { pvc } ::= {atmVclEntry 15} -- ATM Virtual Path (VP) Cross Connect Table -- This table contains configuration and state -- information of point-to-point, -- point-to-multipoint, or multipoint-to-multipoint -- VP cross-connects for PVCs. -- This table has read-create access and can be used -- to cross-connect the VPLs together in an ATM switch -- or network. The atmVpCrossConnectIndex -- is used to associate the related -- VPLs that are cross-connected together. -- The ATM VP Cross Connect Table -- models each bi-directional VPC -- cross-connect as a set of entries in -- the atmVpCrossConnectTable. A -- point-to-point VPC cross-connect is modeled -- as one entry; a point-to-multipoint (N leafs) VPC -- cross-connect as N entries in this table; and -- a multipoint-to-multipoint (N parties) VPC cross- -- connect as N(N-1)/2 entries in this table. -- In the latter cases, all the N (or N(N-1)/2) entries -- are associated with a single VPC cross-connect by -- having the same value of atmVpCrossConnectIndex. -- _________________________________________ -- | | -- Low | ATM Switch or Network | High -- port| | port -- _____|>> from low to high VPC traffic flow >>|______ -- |<< from high to low VPC traffic flow <<| -- | | -- |_______________________________________| -- -- The terms low and high are chosen to represent -- numerical ordering of the two interfaces associated -- with a VPC cross-connect. That is, the ATM interface -- with the lower value of ifIndex is termed 'low', -- while the other ATM interface associated with the -- VPC cross-connect is termed 'high'. This terminology Tesink Standards Track [Page 48] RFC 2515 ATM Management Objects February 1999 -- is used to provide directional information; for -- example, the atmVpCrossConnectL2HOperStatus applies -- to the low->high direction, and -- atmVpCrossConnectH2LOperStatus applies to the -- high->low direction, as illustrated above. atmVpCrossConnectIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for atmVpCrossConnectIndex when creating entries in the atmVpCrossConnectTable. The value 0 indicates that no unassigned entries are available. To obtain the atmVpCrossConnectIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next unassigned index. After a manager retrieves a value the agent will determine through its local policy when this index value will be made available for reuse." ::= { atmMIBObjects 8 } -- The ATM VP Cross Connect Table atmVpCrossConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVpCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM VP Cross Connect table for PVCs. An entry in this table models two cross-connected VPLs. Each VPL must have its atmConnKind set to pvc(1)." ::= { atmMIBObjects 9 } atmVpCrossConnectEntry OBJECT-TYPE SYNTAX AtmVpCrossConnectEntry Tesink Standards Track [Page 49] RFC 2515 ATM Management Objects February 1999 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM VP Cross Connect table. This entry is used to model a bi-directional ATM VP cross-connect which cross-connects two VPLs. Step-wise Procedures to set up a VP Cross-connect Once the entries in the atmVplTable are created, the following procedures are used to cross-connect the VPLs together. (1) The manager obtains a unique atmVpCrossConnectIndex by reading the atmVpCrossConnectIndexNext object. (2) Next, the manager creates a set of one or more rows in the ATM VP Cross Connect Table, one for each cross-connection between two VPLs. Each row is indexed by the ATM interface port numbers and VPI values of the two ends of that cross-connection. This set of rows specifies the topology of the VPC cross-connect and is identified by a single value of atmVpCrossConnectIndex. Negotiated VP Cross-Connect Establishment (2a) The manager creates a row in this table by setting atmVpCrossConnectRowStatus to createAndWait(5). The agent checks the requested topology and the mutual sanity of the ATM traffic parameters and service categories, i.e., the row creation fails if: - the requested topology is incompatible with associated values of atmVplCastType, - the requested topology is not supported by the agent, - the traffic/service category parameter values associated with the requested row are incompatible with those of already existing rows for this VP cross-connect. [For example, for setting up a point-to-point VP cross-connect, the ATM traffic parameters in the receive direction Tesink Standards Track [Page 50] RFC 2515 ATM Management Objects February 1999 of a VPL at the low end of the cross-connect must equal to the traffic parameters in the transmit direction of the other VPL at the high end of the cross-connect, otherwise, the row creation fails.] The agent also checks for internal errors in building the cross-connect. The atmVpCrossConnectIndex values in the corresponding atmVplTable rows are filled in by the agent at this point. (2b) The manager promotes the row in the atmVpCrossConnectTable by setting atmVpCrossConnectRowStatus to active(1). If this set is successful, the agent has reserved the resources specified by the ATM traffic parameter and Service category values for each direction of the VP cross-connect in an ATM switch or network. (3) The manager sets the atmVpCrossConnectAdminStatus to up(1) in all rows of this VP cross-connect to turn the traffic flow on. One-Shot VP Cross-Connect Establishment A VP cross-connect may also be established in one step by a set-request with all necessary parameter values and atmVpCrossConnectRowStatus set to createAndGo(4). In contrast to the negotiated VP cross-connect establishment which allows for detailed error checking (i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VP cross-connect establishment performs the setup on one operation but does not have the advantage of step-wise error checking. VP Cross-Connect Retirement A VP cross-connect identified by a particular value of atmVpCrossConnectIndex is released by: (1) Setting atmVpCrossConnectRowStatus of all Tesink Standards Track [Page 51] RFC 2515 ATM Management Objects February 1999 rows identified by this value of atmVpCrossConnectIndex to destroy(6). The agent may release all associated resources, and the atmVpCrossConnectIndex values in the corresponding atmVplTable row are removed. Note that a situation when only a subset of the associated rows are deleted corresponds to a VP topology change. (2) After deletion of the appropriate atmVpCrossConnectEntries, the manager may set atmVplRowStatus to destroy(6) the associated VPLs. The agent releases the resources and removes the associated rows in the atmVplTable. VP Cross-connect Reconfiguration At the discretion of the agent, a VP cross-connect may be reconfigured by adding and/or deleting leafs to/from the VP topology as per the VP cross-connect establishment/retirement procedures. Reconfiguration of traffic/service category parameter values requires release of the VP cross-connect before those parameter values may by changed for individual VPLs." INDEX { atmVpCrossConnectIndex, atmVpCrossConnectLowIfIndex, atmVpCrossConnectLowVpi, atmVpCrossConnectHighIfIndex, atmVpCrossConnectHighVpi } ::= { atmVpCrossConnectTable 1 } AtmVpCrossConnectEntry ::= SEQUENCE { atmVpCrossConnectIndex INTEGER, atmVpCrossConnectLowIfIndex InterfaceIndex, atmVpCrossConnectLowVpi AtmVpIdentifier, atmVpCrossConnectHighIfIndex InterfaceIndex, atmVpCrossConnectHighVpi AtmVpIdentifier, atmVpCrossConnectAdminStatus AtmVorXAdminStatus, atmVpCrossConnectL2HOperStatus AtmVorXOperStatus, atmVpCrossConnectH2LOperStatus AtmVorXOperStatus, atmVpCrossConnectL2HLastChange AtmVorXLastChange, atmVpCrossConnectH2LLastChange AtmVorXLastChange, atmVpCrossConnectRowStatus RowStatus } Tesink Standards Track [Page 52] RFC 2515 ATM Management Objects February 1999 atmVpCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify this VP cross-connect. For each VPL associated with this cross-connect, the agent reports this cross-connect index value in the atmVplCrossConnectIdentifier attribute of the corresponding atmVplTable entries." ::= { atmVpCrossConnectEntry 1 } atmVpCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the ATM interface for this VP cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmVpCrossConnectEntry." ::= { atmVpCrossConnectEntry 2 } atmVpCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VP cross-connect that is identified by atmVpCrossConnectLowIfIndex." ::= { atmVpCrossConnectEntry 3 } atmVpCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the ATM interface for this VP cross-connect. The term high implies that this ATM interface has the numerically higher ifIndex value than the other ATM interface identified in the same atmVpCrossConnectEntry." ::= { atmVpCrossConnectEntry 4 } atmVpCrossConnectHighVpi OBJECT-TYPE SYNTAX AtmVpIdentifier Tesink Standards Track [Page 53] RFC 2515 ATM Management Objects February 1999 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VP cross-connect that is identified by atmVpCrossConnectHighIfIndex." ::= { atmVpCrossConnectEntry 5 } atmVpCrossConnectAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The desired administrative status of this bi-directional VP cross-connect." DEFVAL { down } ::= { atmVpCrossConnectEntry 6 } atmVpCrossConnectL2HOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the VP cross-connect in one direction; (i.e., from the low to high direction)." ::= { atmVpCrossConnectEntry 7 } atmVpCrossConnectH2LOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the VP cross-connect in one direction; (i.e., from the high to low direction)." ::= { atmVpCrossConnectEntry 8 } atmVpCrossConnectL2HLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VP cross-connect entered its current operational state in the low to high direction." ::= { atmVpCrossConnectEntry 9 } Tesink Standards Track [Page 54] RFC 2515 ATM Management Objects February 1999 atmVpCrossConnectH2LLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VP cross-connect entered its current operational in the high to low direction." ::= { atmVpCrossConnectEntry 10 } atmVpCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry in the atmVpCrossConnectTable. This object is used to create a cross-connect for cross-connecting VPLs which are created using the atmVplTable or to change or delete an existing cross-connect. This object must be initially set to `createAndWait' or 'createAndGo'. To turn on a VP cross-connect, the atmVpCrossConnectAdminStatus is set to `up'." DEFVAL { createAndWait } ::= { atmVpCrossConnectEntry 11 } -- ATM Virtual Channel (VC) Cross Connect Table -- This table contains configuration and state -- information of point-to-point, -- point-to-multipoint or multipoint-to-multipoint -- VC cross-connects for PVCs. -- This table has read-create access and is used -- to cross-connect the VCLs together in an ATM switch -- or network that belong to a VC connection. -- The atmVcCrossConnectIndex is used to associate -- the related VCLs that are cross-connected together. -- The model using step-wise procedures described for setting -- up a VP cross-connect is also used for setting up -- a VC cross-connect. Tesink Standards Track [Page 55] RFC 2515 ATM Management Objects February 1999 atmVcCrossConnectIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for atmVcCrossConnectIndex when creating entries in the atmVcCrossConnectTable. The value 0 indicates that no unassigned entries are available. To obtain the atmVcCrossConnectIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next unassigned index. After a manager retrieves a value the agent will determine through its local policy when this index value will be made available for reuse." ::= { atmMIBObjects 10 } -- The ATM VC Cross Connect Table atmVcCrossConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM VC Cross Connect table for PVCs. An entry in this table models two cross-connected VCLs. Each VCL must have its atmConnKind set to pvc(1)." ::= { atmMIBObjects 11 } atmVcCrossConnectEntry OBJECT-TYPE SYNTAX AtmVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM VC Cross Connect table. This entry is used to model a bi-directional ATM VC cross-connect cross-connecting two end points. Step-wise Procedures to set up a VC Cross-connect Tesink Standards Track [Page 56] RFC 2515 ATM Management Objects February 1999 Once the entries in the atmVclTable are created, the following procedures are used to cross-connect the VCLs together to form a VCC segment. (1) The manager obtains a unique atmVcCrossConnectIndex by reading the atmVcCrossConnectIndexNext object. (2) Next, the manager creates a set of one or more rows in the ATM VC Cross Connect Table, one for each cross-connection between two VCLs. Each row is indexed by the ATM interface port numbers and VPI/VCI values of the two ends of that cross-connection. This set of rows specifies the topology of the VCC cross-connect and is identified by a single value of atmVcCrossConnectIndex. Negotiated VC Cross-Connect Establishment (2a) The manager creates a row in this table by setting atmVcCrossConnectRowStatus to createAndWait(5). The agent checks the requested topology and the mutual sanity of the ATM traffic parameters and service categories, i.e., the row creation fails if: - the requested topology is incompatible with associated values of atmVclCastType, - the requested topology is not supported by the agent, - the traffic/service category parameter values associated with the requested row are incompatible with those of already existing rows for this VC cross-connect. [For example, for setting up a point-to-point VC cross-connect, the ATM traffic parameters in the receive direction of a VCL at the low end of the cross-connect must equal to the traffic parameters in the transmit direction of the other VCL at the high end of the cross-connect, otherwise, the row creation fails.] The agent also checks for internal errors in building the cross-connect. The atmVcCrossConnectIndex values in the Tesink Standards Track [Page 57] RFC 2515 ATM Management Objects February 1999 corresponding atmVclTable rows are filled in by the agent at this point. (2b) The manager promotes the row in the atmVcCrossConnectTable by setting atmVcCrossConnectRowStatus to active(1). If this set is successful, the agent has reserved the resources specified by the ATM traffic parameter and Service category values for each direction of the VC cross-connect in an ATM switch or network. (3) The manager sets the atmVcCrossConnectAdminStatus to up(1) in all rows of this VC cross-connect to turn the traffic flow on. One-Shot VC Cross-Connect Establishment A VC cross-connect may also be established in one step by a set-request with all necessary parameter values and atmVcCrossConnectRowStatus set to createAndGo(4). In contrast to the negotiated VC cross-connect establishment which allows for detailed error checking i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VC cross-connect establishment performs the setup on one operation but does not have the advantage of step-wise error checking. VC Cross-Connect Retirement A VC cross-connect identified by a particular value of atmVcCrossConnectIndex is released by: (1) Setting atmVcCrossConnectRowStatus of all rows identified by this value of atmVcCrossConnectIndex to destroy(6). The agent may release all associated resources, and the atmVcCrossConnectIndex values in the corresponding atmVclTable row are removed. Note that a situation when only a subset of the associated rows are deleted corresponds Tesink Standards Track [Page 58] RFC 2515 ATM Management Objects February 1999 to a VC topology change. (2) After deletion of the appropriate atmVcCrossConnectEntries, the manager may set atmVclRowStatus to destroy(6) the associated VCLs. The agent releases the resources and removes the associated rows in the atmVclTable. VC Cross-Connect Reconfiguration At the discretion of the agent, a VC cross-connect may be reconfigured by adding and/or deleting leafs to/from the VC topology as per the VC cross-connect establishment/retirement procedures. Reconfiguration of traffic/service category parameter values requires release of the VC cross-connect before those parameter values may by changed for individual VCLs." INDEX { atmVcCrossConnectIndex, atmVcCrossConnectLowIfIndex, atmVcCrossConnectLowVpi, atmVcCrossConnectLowVci, atmVcCrossConnectHighIfIndex, atmVcCrossConnectHighVpi, atmVcCrossConnectHighVci } ::= { atmVcCrossConnectTable 1 } AtmVcCrossConnectEntry ::= SEQUENCE { atmVcCrossConnectIndex INTEGER, atmVcCrossConnectLowIfIndex InterfaceIndex, atmVcCrossConnectLowVpi AtmVpIdentifier, atmVcCrossConnectLowVci AtmVcIdentifier, atmVcCrossConnectHighIfIndex InterfaceIndex, atmVcCrossConnectHighVpi AtmVpIdentifier, atmVcCrossConnectHighVci AtmVcIdentifier, atmVcCrossConnectAdminStatus AtmVorXAdminStatus, atmVcCrossConnectL2HOperStatus AtmVorXOperStatus, atmVcCrossConnectH2LOperStatus AtmVorXOperStatus, atmVcCrossConnectL2HLastChange AtmVorXLastChange, atmVcCrossConnectH2LLastChange AtmVorXLastChange, atmVcCrossConnectRowStatus RowStatus } atmVcCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible Tesink Standards Track [Page 59] RFC 2515 ATM Management Objects February 1999 STATUS current DESCRIPTION "A unique value to identify this VC cross-connect. For each VCL associated with this cross-connect, the agent reports this cross-connect index value in the atmVclCrossConnectIdentifier attribute of the corresponding atmVclTable entries." ::= { atmVcCrossConnectEntry 1 } atmVcCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the ATM interface for this VC cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmVcCrossConnectEntry." ::= { atmVcCrossConnectEntry 2 } atmVcCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VC cross-connect that is identified by atmVcCrossConnectLowIfIndex." ::= { atmVcCrossConnectEntry 3 } atmVcCrossConnectLowVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value at the ATM interface associated with this VC cross-connect that is identified by atmVcCrossConnectLowIfIndex." ::= { atmVcCrossConnectEntry 4 } atmVcCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value for the ATM interface for this VC cross-connect. The term high implies Tesink Standards Track [Page 60] RFC 2515 ATM Management Objects February 1999 that this ATM interface has the numerically higher ifIndex value than the other ATM interface identified in the same atmVcCrossConnectEntry." ::= { atmVcCrossConnectEntry 5 } atmVcCrossConnectHighVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VC cross-connect that is identified by atmVcCrossConnectHighIfIndex." ::= { atmVcCrossConnectEntry 6 } atmVcCrossConnectHighVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value at the ATM interface associated with the VC cross-connect that is identified by atmVcCrossConnectHighIfIndex." ::= { atmVcCrossConnectEntry 7 } atmVcCrossConnectAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The desired administrative status of this bi-directional VC cross-connect." DEFVAL { down } ::= { atmVcCrossConnectEntry 8 } atmVcCrossConnectL2HOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VC cross-connect in one direction; (i.e., from the low to high direction)." ::= { atmVcCrossConnectEntry 9 } atmVcCrossConnectH2LOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus Tesink Standards Track [Page 61] RFC 2515 ATM Management Objects February 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VC cross-connect in one direction; (i.e., from the high to low direction)." ::= { atmVcCrossConnectEntry 10 } atmVcCrossConnectL2HLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VC cross-connect entered its current operational state in low to high direction." ::= { atmVcCrossConnectEntry 11 } atmVcCrossConnectH2LLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VC cross-connect entered its current operational state in high to low direction." ::= { atmVcCrossConnectEntry 12 } atmVcCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry in the atmVcCrossConnectTable. This object is used to create a new cross-connect for cross-connecting VCLs which are created using the atmVclTable or to change or delete existing cross-connect. This object must be initially set to `createAndWait' or 'createAndGo'. To turn on a VC cross-connect, the atmVcCrossConnectAdminStatus is set to `up'." DEFVAL { createAndWait } ::= { atmVcCrossConnectEntry 13 } -- AAL5 Virtual Channel Connection Performance Statistics Tesink Standards Track [Page 62] RFC 2515 ATM Management Objects February 1999 -- Table -- This table contains the AAL5 -- performance statistics of a VCC at the -- interface associated with an AAL5 entity in an ATM -- host or ATM switch. aal5VccTable OBJECT-TYPE SYNTAX SEQUENCE OF Aal5VccEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains AAL5 VCC performance parameters." ::= { atmMIBObjects 12 } aal5VccEntry OBJECT-TYPE SYNTAX Aal5VccEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains the AAL5 VCC performance parameters and is indexed by ifIndex values of AAL5 interfaces and the associated VPI/VCI values." INDEX { ifIndex, aal5VccVpi, aal5VccVci } ::= { aal5VccTable 1 } Aal5VccEntry ::= SEQUENCE { aal5VccVpi AtmVpIdentifier, aal5VccVci AtmVcIdentifier, aal5VccCrcErrors Counter32, aal5VccSarTimeOuts Counter32, aal5VccOverSizedSDUs Counter32 } aal5VccVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value of the AAL5 VCC at the interface identified by the ifIndex." ::= { aal5VccEntry 1 } aal5VccVci OBJECT-TYPE Tesink Standards Track [Page 63] RFC 2515 ATM Management Objects February 1999 SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value of the AAL5 VCC at the interface identified by the ifIndex." ::= { aal5VccEntry 2 } aal5VccCrcErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs received with CRC-32 errors on this AAL5 VCC at the interface associated with an AAL5 entity." ::= { aal5VccEntry 3 } aal5VccSarTimeOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of partially re-assembled AAL5 CPCS PDUs which were discarded on this AAL5 VCC at the interface associated with an AAL5 entity because they were not fully re-assembled within the required time period. If the re-assembly timer is not supported, then this object contains a zero value." ::= { aal5VccEntry 4 } aal5VccOverSizedSDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs discarded on this AAL5 VCC at the interface associated with an AAL5 entity because the AAL5 SDUs were too large." ::= { aal5VccEntry 5 } -- -- The following object may be used in conjunction with -- the atmTrafficDescrParamTable for the creation of Tesink Standards Track [Page 64] RFC 2515 ATM Management Objects February 1999 -- new table entries. -- atmTrafficDescrParamIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for atmTrafficDescrParamIndex when creating entries in the atmTrafficDescrParamTable. The value 0 indicates that no unassigned entries are available. To obtain the atmTrafficDescrParamIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next unassigned index. After a manager retrieves a value the agent will determine through its local policy when this index value will be made available for reuse." ::= { atmMIBObjects 13 } -- Conformance Information atmMIBConformance OBJECT IDENTIFIER ::= { atmMIB 2 } atmMIBGroups OBJECT IDENTIFIER ::= { atmMIBConformance 1 } atmMIBCompliances OBJECT IDENTIFIER ::= { atmMIBConformance 2 } -- Compliance Statements atmMIBCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities including networks which have ATM and AAL5 interfaces." MODULE -- this module -- -- ****** Interface and Traffic Descriptor Support *** Tesink Standards Track [Page 65] RFC 2515 ATM Management Objects February 1999 -- MANDATORY-GROUPS {atmInterfaceConfGroup2, atmTrafficDescrGroup2 } OBJECT atmInterfaceMaxVpcs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxVccs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxActiveVpiBits MIN-ACCESS read-only DESCRIPTION "Write access is not required. At the ATM UNI the maximum number of active VPI bits configured for use ranges from 0 to 8 only. Implementations may support smaller ranges." OBJECT atmInterfaceMaxActiveVciBits MIN-ACCESS read-only DESCRIPTION "Write access is not required. Implementations may support smaller ranges." OBJECT atmInterfaceIlmiVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceIlmiVci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIpAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIfName MIN-ACCESS read-only DESCRIPTION "Write access is not required." Tesink Standards Track [Page 66] RFC 2515 ATM Management Objects February 1999 OBJECT atmInterfaceSubscrAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParamIndexNext DESCRIPTION "This object is only required for systems that support the creation of entries in the atmTrafficDescrParamTable." OBJECT atmTrafficDescrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam1 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmServiceCategory MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrRowStatus SYNTAX INTEGER {active(1)} Tesink Standards Track [Page 67] RFC 2515 ATM Management Objects February 1999 -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmTrafficFrameDiscard MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- -- ****** DS3 PLCP Support ************************** -- GROUP atmInterfaceDs3PlcpGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the DS3 PLCP layer." -- -- ****** TC Sublayer Support ******************************** -- GROUP atmInterfaceTCGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the TC Sublayer." -- -- ****** VPC Support ******************************* -- GROUP atmVpcTerminationGroup2 DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that terminate VPCs (i.e., ones which are NOT cross-connected to other VPLs)." GROUP atmVplCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that are not associated with VCLs and are cross-connected to other VPLs for VPCs." Tesink Standards Track [Page 68] RFC 2515 ATM Management Objects February 1999 GROUP atmVpPvcCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that are not associated with VCLs and are cross-connected to other VPLs for permanent VPCs (i.e., PVCs). This group is not used to crossconnect a PVC with an SVC to form a Soft PVC." OBJECT atmVplAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVplCastType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplConnKind MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVpCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION Tesink Standards Track [Page 69] RFC 2515 ATM Management Objects February 1999 "Write access is not required." OBJECT atmVpCrossConnectRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- -- ****** VCC Support ******************************* -- GROUP atmVccTerminationGroup2 DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that terminate VCCs (i.e., ones which are NOT cross-connected to other VCLs)." GROUP atmVclCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that are cross-connected to other VCLs for VCCs." GROUP atmVcPvcCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that are cross-connected to other VCLs for permanent VCCs (i.e., PVCs). This group is not used to crossconnect a PVC with an SVC to form a Soft PVC." OBJECT atmVclAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." Tesink Standards Track [Page 70] RFC 2515 ATM Management Objects February 1999 OBJECT atmVclTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAalType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVclCastType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclConnKind MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVcCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVcCrossConnectRowStatus SYNTAX INTEGER { active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- -- ****** AAL5 Support ****************************** -- GROUP aal5VccGroup Tesink Standards Track [Page 71] RFC 2515 ATM Management Objects February 1999 DESCRIPTION "This group is mandatory for the AAL5 virtual connections only." OBJECT atmVccAal5CpcsTransmitSduSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAal5CpcsReceiveSduSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAal5EncapsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { atmMIBCompliances 2 } -- Units of Conformance atmInterfaceDs3PlcpGroup OBJECT-GROUP OBJECTS {atmInterfaceDs3PlcpSEFSs, atmInterfaceDs3PlcpAlarmState, atmInterfaceDs3PlcpUASs} STATUS current DESCRIPTION "A collection of objects providing information about DS3 PLCP layer at an ATM interface." ::= { atmMIBGroups 3 } atmInterfaceTCGroup OBJECT-GROUP OBJECTS { atmInterfaceOCDEvents, atmInterfaceTCAlarmState } STATUS current DESCRIPTION "A collection of objects providing information about TC sublayer at an ATM interface." ::= { atmMIBGroups 4 } aal5VccGroup OBJECT-GROUP OBJECTS {atmVccAal5CpcsTransmitSduSize, atmVccAal5CpcsReceiveSduSize, atmVccAal5EncapsType, aal5VccCrcErrors, aal5VccSarTimeOuts, aal5VccOverSizedSDUs } STATUS current Tesink Standards Track [Page 72] RFC 2515 ATM Management Objects February 1999 DESCRIPTION "A collection of objects providing AAL5 configuration and performance statistics of a VCC." ::= { atmMIBGroups 9 } atmInterfaceConfGroup2 OBJECT-GROUP OBJECTS { atmInterfaceMaxVpcs, atmInterfaceMaxVccs, atmInterfaceConfVpcs, atmInterfaceConfVccs, atmInterfaceMaxActiveVpiBits, atmInterfaceMaxActiveVciBits, atmInterfaceIlmiVpi, atmInterfaceIlmiVci, atmInterfaceMyNeighborIpAddress, atmInterfaceMyNeighborIfName, atmInterfaceCurrentMaxVpiBits, atmInterfaceCurrentMaxVciBits, atmInterfaceSubscrAddress } STATUS current DESCRIPTION "A collection of objects providing configuration information about an ATM interface." ::= { atmMIBGroups 10 } atmTrafficDescrGroup2 OBJECT-GROUP OBJECTS { atmTrafficDescrType, atmTrafficDescrParam1, atmTrafficDescrParam2, atmTrafficDescrParam3, atmTrafficDescrParam4, atmTrafficDescrParam5, atmTrafficDescrRowStatus, atmServiceCategory, atmTrafficFrameDiscard, atmTrafficDescrParamIndexNext } STATUS current DESCRIPTION "A collection of objects providing information about ATM traffic descriptor type and the associated parameters." ::= { atmMIBGroups 11 } atmVpcTerminationGroup2 OBJECT-GROUP OBJECTS {atmVplOperStatus, atmVplAdminStatus, atmVplLastChange, atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplRowStatus, atmVplCastType, atmVplConnKind } STATUS current Tesink Standards Track [Page 73] RFC 2515 ATM Management Objects February 1999 DESCRIPTION "A collection of objects providing information about a VPL at an ATM interface which terminates a VPC (i.e., one which is NOT cross-connected to other VPLs)." ::= { atmMIBGroups 12 } atmVccTerminationGroup2 OBJECT-GROUP OBJECTS {atmVclOperStatus, atmVclAdminStatus, atmVclLastChange, atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVccAalType, atmVclRowStatus, atmVclCastType, atmVclConnKind } STATUS current DESCRIPTION "A collection of objects providing information about a VCL at an ATM interface which terminates a VCC (i.e., one which is NOT cross-connected to other VCLs)." ::= { atmMIBGroups 13 } atmVplCrossConnectGroup OBJECT-GROUP OBJECTS { atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplOperStatus, atmVplLastChange, atmVplRowStatus, atmVplCastType, atmVplConnKind } STATUS current DESCRIPTION "A collection of objects providing information about the VPLs that are cross-connected together." ::= { atmMIBGroups 14 } atmVpPvcCrossConnectGroup OBJECT-GROUP OBJECTS { atmVpCrossConnectAdminStatus, atmVpCrossConnectL2HOperStatus, atmVpCrossConnectH2LOperStatus, atmVpCrossConnectL2HLastChange, atmVpCrossConnectH2LLastChange, atmVpCrossConnectRowStatus, atmVplCrossConnectIdentifier, atmVpCrossConnectIndexNext } STATUS current DESCRIPTION "A collection of objects providing information about a VP cross-connect Tesink Standards Track [Page 74] RFC 2515 ATM Management Objects February 1999 for PVCs. These objects are not used for Soft PVCs or SVCs." ::= { atmMIBGroups 15 } atmVclCrossConnectGroup OBJECT-GROUP OBJECTS { atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVclOperStatus, atmVclLastChange, atmVclRowStatus, atmVclCastType, atmVclConnKind } STATUS current DESCRIPTION "A collection of objects providing information about the VCLs that are cross-connected together." ::= { atmMIBGroups 16 } atmVcPvcCrossConnectGroup OBJECT-GROUP OBJECTS { atmVcCrossConnectAdminStatus, atmVcCrossConnectL2HOperStatus, atmVcCrossConnectH2LOperStatus, atmVcCrossConnectL2HLastChange, atmVcCrossConnectH2LLastChange, atmVcCrossConnectRowStatus, atmVclCrossConnectIdentifier, atmVcCrossConnectIndexNext } STATUS current DESCRIPTION "A collection of objects providing information about a VC cross-connect for PVCs. These objects are not used for Soft PVCs or SVCs." ::= { atmMIBGroups 17 } -- Deprecated Definitions - Objects -- atmInterfaceAddressType -- atmTrafficQoSClass -- Deprecated Definitions - Compliance atmMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMP entities including networks which have ATM and Tesink Standards Track [Page 75] RFC 2515 ATM Management Objects February 1999 AAL5 interfaces." MODULE -- this module MANDATORY-GROUPS {atmInterfaceConfGroup, atmTrafficDescrGroup} OBJECT atmInterfaceMaxVpcs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxVccs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxActiveVpiBits MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxActiveVciBits MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceIlmiVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceIlmiVci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIpAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIfName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrType MIN-ACCESS read-only Tesink Standards Track [Page 76] RFC 2515 ATM Management Objects February 1999 DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam1 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficQoSClass MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." GROUP atmInterfaceDs3PlcpGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the DS3 PLCP layer." Tesink Standards Track [Page 77] RFC 2515 ATM Management Objects February 1999 GROUP atmInterfaceTCGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the TC Sublayer." GROUP atmVpcTerminationGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that terminate VPCs (i.e., ones which are NOT cross-connected to other VPLs)." GROUP atmVpCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that are not associated with VCLs and are cross-connected to other VPLs." OBJECT atmVplAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVpCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION Tesink Standards Track [Page 78] RFC 2515 ATM Management Objects February 1999 "Write access is not required." OBJECT atmVpCrossConnectRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." GROUP atmVccTerminationGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that terminate VCCs (i.e., ones which are NOT cross-connected to other VCLs)." GROUP atmVcCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that are cross-connected to other VCLs." OBJECT atmVclAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAalType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclRowStatus SYNTAX INTEGER {active(1)} Tesink Standards Track [Page 79] RFC 2515 ATM Management Objects February 1999 -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVcCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVcCrossConnectRowStatus SYNTAX INTEGER { active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." GROUP aal5VccGroup DESCRIPTION "This group is mandatory for the AAL5 virtual connections only." OBJECT atmVccAal5CpcsTransmitSduSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAal5CpcsReceiveSduSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAal5EncapsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { atmMIBCompliances 1 } -- Deprecated Definitions - Groups Tesink Standards Track [Page 80] RFC 2515 ATM Management Objects February 1999 atmInterfaceConfGroup OBJECT-GROUP OBJECTS { atmInterfaceMaxVpcs, atmInterfaceMaxVccs, atmInterfaceConfVpcs, atmInterfaceConfVccs, atmInterfaceMaxActiveVpiBits, atmInterfaceMaxActiveVciBits, atmInterfaceIlmiVpi, atmInterfaceIlmiVci, atmInterfaceAddressType, atmInterfaceAdminAddress, atmInterfaceMyNeighborIpAddress, atmInterfaceMyNeighborIfName } STATUS deprecated DESCRIPTION "A collection of objects providing configuration information about an ATM interface." ::= { atmMIBGroups 1 } atmTrafficDescrGroup OBJECT-GROUP OBJECTS { atmTrafficDescrType, atmTrafficDescrParam1, atmTrafficDescrParam2, atmTrafficDescrParam3, atmTrafficDescrParam4, atmTrafficDescrParam5, atmTrafficQoSClass, atmTrafficDescrRowStatus} STATUS deprecated DESCRIPTION "A collection of objects providing information about ATM traffic descriptor type and the associated parameters." ::= { atmMIBGroups 2 } atmVpcTerminationGroup OBJECT-GROUP OBJECTS {atmVplOperStatus, atmVplAdminStatus, atmVplLastChange, atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplRowStatus } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VPL at an ATM interface which terminates a VPC (i.e., one which is NOT cross-connected to other VPLs)." ::= { atmMIBGroups 5 } atmVccTerminationGroup OBJECT-GROUP OBJECTS {atmVclOperStatus, atmVclAdminStatus, Tesink Standards Track [Page 81] RFC 2515 ATM Management Objects February 1999 atmVclLastChange, atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVccAalType, atmVclRowStatus } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VCL at an ATM interface which terminates a VCC (i.e., one which is NOT cross-connected to other VCLs)." ::= { atmMIBGroups 6 } atmVpCrossConnectGroup OBJECT-GROUP OBJECTS { atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplOperStatus, atmVplRowStatus, atmVpCrossConnectAdminStatus, atmVpCrossConnectL2HOperStatus, atmVpCrossConnectH2LOperStatus, atmVpCrossConnectL2HLastChange, atmVpCrossConnectH2LLastChange, atmVpCrossConnectRowStatus, atmVplCrossConnectIdentifier, atmVpCrossConnectIndexNext } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VP cross-connect and the associated VPLs that are cross-connected together." ::= { atmMIBGroups 7 } atmVcCrossConnectGroup OBJECT-GROUP OBJECTS { atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVclOperStatus, atmVclRowStatus, atmVcCrossConnectAdminStatus, atmVcCrossConnectL2HOperStatus, atmVcCrossConnectH2LOperStatus, atmVcCrossConnectL2HLastChange, atmVcCrossConnectH2LLastChange, atmVcCrossConnectRowStatus, atmVclCrossConnectIdentifier, atmVcCrossConnectIndexNext } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VC cross-connect Tesink Standards Track [Page 82] RFC 2515 ATM Management Objects February 1999 and the associated VCLs that are cross-connected together." ::= { atmMIBGroups 8 } -- {atmMIB 3} has been used by [19]. END 10. Acknowledgments This memo is the result of the work of the AToMMIB Working Group. 11. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] 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. [6] 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. [7] 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. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. Tesink Standards Track [Page 83] RFC 2515 ATM Management Objects February 1999 [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, MPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2233, November 1997. [18] Brown, T. and K. Tesink, "Definitions of Managed Objects for SMDS Interfaces", RFC 1694, May 1994. [19] Noto, M., Spiegel, E. and K. Tesink, Editors, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. [20] ATM Forum, ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, 1994. [21] ATM Forum, B-ICI Specification, Version 2.0, af-bici-0013.002, November 1995. [22] "ATM Forum Private Network-Network Interface Specification, Version 1.0 (PNNI 1.0)", af-sig-0055.000, March 1996. [23] "ATM Forum Integrated Local Management Interface (ILMI) Specification", Version 4.0", af-ilmi-0065.000, September 1996. Tesink Standards Track [Page 84] RFC 2515 ATM Management Objects February 1999 [24] Ahmed, M. and K. Tesink, "Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2", RFC 1695, August 1994. 12. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The managed objects in this MIB contain sensitive information since, collectively, they allow tracing and influencing of virtual connections in ATM switches or networks and provide information of their traffic characteristics. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 13. Author's Address Kaj Tesink Bellcore 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (732) 758-5254 EMail: kaj@bellcore.com Tesink Standards Track [Page 85] RFC 2515 ATM Management Objects February 1999 14. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Tesink Standards Track [Page 86] RFC 2515 ATM Management Objects February 1999 15. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Tesink Standards Track [Page 87] snmp-mibs-downloader-1.1/mibrfcs/rfc2561.txt0000644000000000000000000033605111402176071015567 0ustar Network Working Group K. White Request for Comments: 2561 IBM Corp. Category: Standards Track R. Moore IBM Corp. April 1999 Base Definitions of Managed Objects for TN3270E Using SMIv2 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be. A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods. White & Moore Standards Track [Page 1] RFC 2561 TN3270E Using SMIv2 MIB April 1999 It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data. Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . 3 3.0 Structure of the MIB . . . . . . . . . . . . . . . . . . . 4 3.1 TN3270E Server Control . . . . . . . . . . . . . . . . . . 5 3.1.1 tn3270eSrvrConfTable . . . . . . . . . . . . . . . . . 5 3.1.2 tn3270eSrvrPortTable . . . . . . . . . . . . . . . . . 6 3.1.3 tn3270eSrvrStatsTable . . . . . . . . . . . . . . . . 7 3.2 TN3270E Server Resource Configuration . . . . . . . . . . 7 3.3 Resource Name / Client Address Mappings . . . . . . . . . 8 3.3.1 tn3270eSnaMapTable . . . . . . . . . . . . . . . . . . 8 3.3.2 tn3270eResMapTable . . . . . . . . . . . . . . . . . . 9 3.3.3 tn3270eTcpConnTable . . . . . . . . . . . . . . . . . 9 3.4 Advisory Spin Lock Usage . . . . . . . . . . . . . . . . . 9 3.5 Row Persistence . . . . . . . . . . . . . . . . . . . . . 10 3.6 IANA Considerations . . . . . . . . . . . . . . . . . . . 10 4.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 5.0 Security Considerations . . . . . . . . . . . . . . . . . 51 6.0 Intellectual Property . . . . . . . . . . . . . . . . . . 52 7.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 53 8.0 References . . . . . . . . . . . . . . . . . . . . . . . . 53 9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 56 1.0 Introduction This document is a product of the TN3270E Working Group. Its purpose is to define a MIB module for support by a TCP/IP implementation for configuration and management of TN3270E servers. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [22]. White & Moore Standards Track [Page 2] RFC 2561 TN3270E Using SMIv2 MIB April 1999 2.0 The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. White & Moore Standards Track [Page 3] RFC 2561 TN3270E Using SMIv2 MIB April 1999 3.0 Structure of the MIB The TN3270E-MIB is split into the following components: o TN3270E Server Control o TN3270E Server Resource Configuration o Resource/Client Address Mappings There are three additional sections to address: o Advisory Spin Lock Usage o Row Persistence o IANA Considerations The TN3270E-MIB is defined primarily for TN3270E servers. This memo does not explicitly address use of the MIB by TN3270 servers that do not support the TN3270E protocol. Even though a significant number of the objects in the MIB do apply in the TN3270-only case, the case was not addressed, since it is unlikely that a TN3270-only server would implement this MIB. The SYSAPPL-MIB, reference [24], contains the Utf8String textual convention (TC) that the TN3270E-MIB imports. This TC, which is used for some MIB objects containing textual information, enables internationalization of text strings, whereas the DisplayString TC does not. The SNMP-FRAMEWORK-MIB, reference [1], contains the SnmpAdminString TC that the TN3270E-MIB also imports. Like the Utf8String TC, this TC also enables internationalization of text strings; in addition, it provides some guidelines on the length and content of the strings. It is important to note that implementation of the SYSAPPL-MIB is not actually a prerequisite for implementing the TN3270E-MIB. On the other hand, implementation of the TN3270E-MIB does not preclude implementing the SYSAPPL-MIB as well. When both MIBs are implemented, the primary index into most of the TN3270E-MIB tables, tn3270eSrvrConfIndex, SHOULD equal one of the SYSAPPL-MIB's sysApplElmtRunIndex values. In this case the entry in the sysApplElmtRunTable provides additional information on a TN3270E server. The MIB defined by this memo supports use of both IPv4 and IPv6 addressing. Two textual conventions, IANATn3270eAddrType and Tn3270eAddress, are defined for this purpose. IANATn3270eAddress is essentially equivalent to the TAddress TC, defined by RFC 1903. The difference between the two is that IANATn3270eAddress allows a zero- length octet string, while TAddress doesn't. It is important that IANATn3270eAddress allow for the absence of an address, because some White & Moore Standards Track [Page 4] RFC 2561 TN3270E Using SMIv2 MIB April 1999 objects with this syntax are used as table indexes, and have special meanings when they contain zero-length strings. The IANATn3270eAddrType textual convention is used rather than the TDomain TC (defined by RFC 1903) for identifying the contents of a tn3270eTAddress object. TDomain uses an OID to characterize the contents of an associated TAddress object. IANATn3270eAddrType was chosen over TDomain because, with a SYNTAX of Unsigned32 (enumeration type), it is much simpler to use as a component in an instance identifier. It was placed in the IANA-administered module to allow for the addition of values to cover cases (such as proxy servers) not covered by the TN3270E-MIB itself. 3.1 TN3270E Server Control This group of objects provides for TN3270E server configuration and control. It consists of three tables: o tn3270eSrvrConfTable o tn3270eSrvrPortTable o tn3270eSrvrStatsTable The tn3270eSrvrConfTable is the primary table within the entire TN3270E-MIB. As section 3.1.1 indicates, each TN3270E server is represented by an entry in this table, indexed by tn3270eSrvrConfIndex. Most of the other tables defined by the TN3270E-MIB have tn3270eSrvrConfIndex as their primary index. Entries in these tables MUST NOT exist for a TN3270E server when it does not have a tn3270eSrvrConfigEntry. 3.1.1 tn3270eSrvrConfTable The tn3270eSrvrConfTable contains a set of objects primarily used for configuring and managing TN3270E servers. As with most of the other tables in the TN3270E-MIB, this table is indexed by an unsigned integer, tn3270eSrvrConfIndex. This primary index element enables support of multiple TN3270E servers by a single SNMP agent. Within the set of MIB objects returned by one SNMP agent, tn3270eSrvrConfIndex values MUST be unique, and need not be contiguous. The tn3270eSrvrConfInactivityTimer object defines the inactivity period for user traffic on TN3270 and TN3270E sessions. White & Moore Standards Track [Page 5] RFC 2561 TN3270E Using SMIv2 MIB April 1999 The four objects: o tn3270eSrvrConfConnectivityChk o tn3270eSrvrConfTmNopInterval o tn3270eSrvrConfTmNopInactTime o tn3270eSrvrConfTmTimeout define the parameters for performing the "Telnet Timing Mark Option" as defined by RFC 860 [17]. The object tn3270eSrvrConfConnectivityChk allows a Management Station to select either a NOP command or a TIMING-MARK command. Sending a NOP command results in less overhead then a TIMING-MARK command, since a client doesn't send a reply. The objects tn3270eSrvrConfAdminStatus and tn3270eSrvrConfOperStatus enable remote starting and stopping of a TN3270E server, and report the current state of the server. The object tn3270eSrvrConfFunctionsSupported indicates which of the TN3270 and TN3270E options a server supports. The object tn3270eSrvrConfSessionTermState defines as a TN3270E server-wide option what SHOULD occur when the SNA portion of a TN3270 or TN3270E session terminates with respect to the associated TCP connection. The object tn3270eSrvrConfSrvrType indicates whether the TN3270E server represented by a tn3270eSrvrConfEntry is a host or a gateway server. The object tn3270eSrvrConfContact provides a scratch pad area for a TN3270E server administrator to store information for later retrieval. The object tn3270eSrvrConfLastActTime reports the DateAndTime when the server was most recently activated. The special value of all '00'Hs indicates that the server has never been active. The object tn3270eSrvrConfRowStatus provides the capability to perform row creation and deletion operations on this table. 3.1.2 tn3270eSrvrPortTable The tn3270eSrvrPortTable represents the local TCP ports associated with a TN3270E server. This information is important because some TN3270E server implementations support usage of multiple local ports. A tn3270eSrvrPortEntry is indexed by: o tn3270eSrvrConfIndex o tn3270eSrvrConfPort o tn3270eSrvrConfPortAddrType o tn3270eSrvrConfPortAddress Certain TN3270E server implementations restrict a local TCP port to a particular local IP address, instead of allowing connections for any local IP address to occur via the port. tn3270eSrvrConfPortAddrType White & Moore Standards Track [Page 6] RFC 2561 TN3270E Using SMIv2 MIB April 1999 and tn3270eSrvrConfPortAddress allow this restriction to be represented in the MIB. A TN3270E server that doesn't restrict connections over a port to a local IP Address SHALL use the value unknown(0) for tn3270eSrvrConfPortAddrType, and a zero-length octet string for tn3270eSrvrConfPortAddress. 3.1.3 tn3270eSrvrStatsTable The tn3270eSrvrStatsTable defines a series of objects that provide general usage statistics for a TN3270E server. An entry can represent the total activity for a server, or it can represent the activity occurring at the server on either a port or a port-and- local-address basis. An implementation of this table MUST use only one of the three levels of refinement that the indexing of this table supports for the entries associated with a single TN3270E server. The objects in this table reporting maximum, in-use, and spare LUs for terminals and printers presuppose an implementation where terminal resources and printer resources come from disjoint, dedicated pools. An implementation where resources for the two types of LUs come from a single shared pool should return the following values: o maximum: maximum size of the shared pool o in-use: number currently in use as this type of LU o spare: maximum - (terminal in-use + printer in-use) 3.2 TN3270E Server Resource Configuration The following three tables provide for configuration of resources at a TN3270E server: o tn3270eClientGroupTable o tn3270eResPoolTable o tn3270eClientResMapTable tn3270eClientGroupTable and tn3270eResPoolTable enable implementations to define groupings of both client addresses and resource pools for mapping client addresses to resources. The tn3270eClientResMapTable provides a mapping from a client group to a resource pool. White & Moore Standards Track [Page 7] RFC 2561 TN3270E Using SMIv2 MIB April 1999 3.3 Resource Name / Client Address Mappings The TN3270E-MIB contains three tables for mapping resource names to client addresses, and client addresses to resource names: o tn3270eSnaMapTable o tn3270eResMapTable o tn3270eTcpConnTable 3.3.1 tn3270eSnaMapTable The tn3270eSnaMapTable is a read-only table that maps a secondary LU's SNA network name to the name by which it is known locally at the TN3270E server. For correlation with data from the SNA network, the name of the associated primary LU also appears in a tn3270eSnaMapEntry. An entry in this table is created when the Activate LU (ACTLU) request carrying the SNA network name of the SLU is received from the SSCP. The entry is deleted when the SLU is deactivated. A TN3270E server provides a client with access to an SNA application by associating a TCP connection from the client with an SNA secondary LU (SLU) at the server. This SLU in turn has an SNA session with a primary LU (PLU) running on an SNA host. This PLU represents the application with which the client is communicating. The TN3270E-MIB includes two tables for mapping back and forth among the SNA name identifying the PLU, the SNA name identifying the SLU, and the TCP connection with the client. In order to understand how these name mappings work, it is necessary to understand a subtlety involving the names of the SLUs at the TN3270E server: these names are often different from the names by which the SLUs are known in the rest of the SNA network. In the TN3270E-MIB, these two types of SLU names are termed "local names" and "SSCP-supplied names"; the latter term indicates that the name by which the SLU is known in the SNA network comes to the TN3270E server from the SNA System Services Control Point. SSCPs don't always send SLU names down to secondary LUs; in some cases this capability must be turned on. In the case of SLUs served by a Dependent LU Requester (DLUR), an SSCP always sends SLU names to the DLUR. It is necessary, however, to enable the DLUR's PU/LU Network Name Forwarding function, so that it forwards the SLU names it receives from the SSCP down to the PUs that it serves. White & Moore Standards Track [Page 8] RFC 2561 TN3270E Using SMIv2 MIB April 1999 For SLUs associated with an SNA type 2.0 node (or with a boundary- function-attached type 2.1 node) not served by a DLUR, inclusion of SLU names on ACTLU must be enabled explicitly at the SSCP via local configuration. 3.3.2 tn3270eResMapTable The tn3270eResMapTable is a read-only table that maps a resource name to a client's address. An entry in this table is created when a TCP connection is received by a TN3270E server and mapped to a resource. The entry is deleted when the resource-to-address association is no longer valid. 3.3.3 tn3270eTcpConnTable The TCP Connection Table is currently defined by RFC 2012 (Refer to reference [20], TCP-MIB Definitions). It contains the following objects: o tcpConnState (INTEGER) o tcpConnLocalAddress (IpAddress) o tcpConnLocalPort (INTEGER) o tcpConnRemAddress (IpAddress) o tcpConnRemPort (INTEGER) It is indexed by: tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, and tcpConnRemPort. The tn3270eTcpConnTable contains objects for keeping a list of the current set of TN3270 and TN3270E sessions at a TN3270E server. The relationship between the tcpConnTable and the Tn3270eTcpConnTable is not one-to-one, since the tn3270eTcpConnTable contains information pertaining only to TN3270(E) sessions. The tn3270eTcpConnTable has a different indexing structure from that of the tcpConnTable. Instead of using IpAddress objects, Tn3270eAddress and IANATn3270eAddrType object pairs are used to specify client addresses (both local and remote). This enables support of IPv6 addresses. In addition, the remote address pair precedes the local address pair in the index clause, in order to enable a GET-NEXT operation using only the remote address pair. 3.4 Advisory Spin Lock Usage Within the TN3270E-MIB, tn3270eConfSpinLock is defined as an advisory lock that allows cooperating TN3270E-MIB applications to coordinate their use of the tn3270eSrvrConfTable, the tn3270eSrvrPortTable, the tn3270eClientGroupTable, the tn3270eResPoolTable, and the White & Moore Standards Track [Page 9] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eClientResMapTable. When creating a new entry or altering an existing entry in any of these tables, an application SHOULD make use of tn3270eConfSpinLock to serialize application changes or additions. Since this is an advisory lock, its use by management applications SHALL NOT be enforced by agents. Agents MUST, however, implement the tn3270eConfSpinLock object. 3.5 Row Persistence The following tables enable remote creation of their entries by including RowStatus objects: o tn3270eSrvrConfTable o tn3270eSrvrPortTable o tn3270eClientGroupTable o tn3270eResPoolTable o tn3270eClientResMapTable An implementation SHOULD NOT retain SNMP-created entries in these tables across reIPLs (Initial Program Loads) of the corresponding TN3270E server, since management applications need to see consistent behavior with respect to the persistence of the table entries that they create. It is expected that local, implementation-dependent configuration information will be used to define the initial and persistent configurations for TN3270E server usage. Thus it is not necessary to enable persistence of table entries by adding StorageType (refer to RFC 1903 [6]) objects to these tables. 3.6 IANA Considerations The tn3270eSrvrFunctionsSupported, tn3270eTcpConnFunctions, tn3270eTcpConnClientIdFormat, and tn3270eTcpConnLogInfo objects, as well as a number of objects identifying various address types, resource types, and device types, use textual conventions imported from the IANATn3270eTC-MIB. The purpose of defining these textual conventions in a separate MIB module is to allow additional values to be defined without having to issue a new version of this document. The Internet Assigned Numbers Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers; it will administer the values associated with these textual conventions. The rules for additions or changes to the IANATn3270eTC-MIB are outlined in the DESCRIPTION clause associated with its MODULE- IDENTITY statement. White & Moore Standards Track [Page 10] RFC 2561 TN3270E Using SMIv2 MIB April 1999 The current version of the IANATn3270eTC-MIB can be accessed from the IANA home page at: "http://www.iana.org/". 4.0 Definitions TN3270E-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, TimeTicks, IpAddress, Counter32, Gauge32, Counter64 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TestAndIncr, DateAndTime, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF snanauMIB FROM SNA-NAU-MIB Utf8String FROM SYSAPPL-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB IANATn3270eAddrType, IANATn3270eAddress, IANATn3270eClientType, IANATn3270Functions, IANATn3270ResourceType, IANATn3270DeviceType, IANATn3270eLogData FROM IANATn3270eTC-MIB; tn3270eMIB MODULE-IDENTITY LAST-UPDATED "9807270000Z" -- July 27, 1998 ORGANIZATION "TN3270E Working Group" CONTACT-INFO "Kenneth White (kennethw@vnet.ibm.com) IBM Corp. - Dept. BRQA/Bldg. 501/G114 P.O. Box 12195 3039 Cornwallis RTP, NC 27709-2195 USA Robert Moore (remoore@us.ibm.com) IBM Corp. - Dept. BRQA/Bldg. 501/G114 P.O. Box 12195 3039 Cornwallis RTP, NC 27709-2195 USA +1-919-254-4436" DESCRIPTION "This module defines a portion of the management White & Moore Standards Track [Page 11] RFC 2561 TN3270E Using SMIv2 MIB April 1999 information base (MIB) for managing TN3270E servers." REVISION "9807270000Z" -- July 27, 1998 DESCRIPTION "RFC nnnn (Proposed Standard)" -- RFC Editor to fill in ::= { snanauMIB 8 } -- Textual Conventions SnaResourceName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for defining an SNA resource name. A fully qualified SNA resource name, consisting of a 1 to 8 character network identifier (NetId), a period ('.'), and a 1 to 8 character resource name (ResName). The NetId and ResName are constructed from the uppercase letters 'A' - 'Z' and the numerics '0' - '9', all encoded in ASCII, with the restriction that the first character of each must be a letter. Blanks are not allowed. Earlier versions of SNA permitted three additional characters in NetIds and ResNames: '#', '@', and '$'. While this use of these characters has been retired, a Management Station should still accept them for backward compatibility. Note: This Textual Convention is not subject to internationalization, and does not use the character encodings used by the Utf8String Textual Convention." SYNTAX OCTET STRING (SIZE(0..17)) Tn3270eTraceData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An octet string representing trace data from the Telnet half of a TN3270E session, from the SNA half, or from both. The octet string contains a sequence of trace elements, with the trace elements in the string ordered from earliest to latest. Each trace element has the following form: +---+---+----+----------------------+ !length !type!data ! +---+---+----+----------------------+ White & Moore Standards Track [Page 12] RFC 2561 TN3270E Using SMIv2 MIB April 1999 where: length = two-octet length of the data portion of the trace element, not including the length and type octets type = one-octet code point characterizing the data; defined values are: X'01' telnet PDU from the server to the client X'02' telnet PDU from the client to the server X'03' SNA data from the server to the SNA host X'04' SNA data from the SNA host to the server data = initial part of a PDU. It is implementation-dependent where the 'initial part of a PDU' starts. For SNA data, however, the starting point SHOULD be the first byte of the TH. For IP data the starting point SHOULD be the first byte of the IP header. It is left to implementations to determine how much of each PDU to return in a trace element. The zero-length string indicates that no trace data is available." SYNTAX OCTET STRING (SIZE (0 | 3..4096)) -- Top-level structure of the MIB tn3270eNotifications OBJECT IDENTIFIER ::= { tn3270eMIB 0 } tn3270eObjects OBJECT IDENTIFIER ::= { tn3270eMIB 1 } tn3270eConformance OBJECT IDENTIFIER ::= { tn3270eMIB 3 } -- MIB Objects tn3270eSrvrConfTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eSrvrConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the configuration elements for TN3270E servers. The number of entries in this table is expected to vary depending on the location of the table. A particular TN3270E server is expected to have a single entry. Modeling of the configuration elements as a table allows multiple TN3270E servers to be serviced by the same SNMP agent. White & Moore Standards Track [Page 13] RFC 2561 TN3270E Using SMIv2 MIB April 1999 An implementation SHOULD NOT retain an SNMP-created entry in this table across re-IPLs (Initial Program Loads) of the corresponding TN3270E server." ::= { tn3270eObjects 1 } tn3270eSrvrConfEntry OBJECT-TYPE SYNTAX Tn3270eSrvrConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Definition of the configuration elements for a single TN3270E server." INDEX { tn3270eSrvrConfIndex } ::= { tn3270eSrvrConfTable 1 } Tn3270eSrvrConfEntry ::= SEQUENCE { tn3270eSrvrConfIndex Unsigned32, tn3270eSrvrConfInactivityTimeout Unsigned32, tn3270eSrvrConfConnectivityChk INTEGER, tn3270eSrvrConfTmNopInactTime Unsigned32, tn3270eSrvrConfTmNopInterval Unsigned32, tn3270eSrvrFunctionsSupported IANATn3270Functions, tn3270eSrvrConfAdminStatus INTEGER, tn3270eSrvrConfOperStatus INTEGER, tn3270eSrvrConfSessionTermState INTEGER, tn3270eSrvrConfSrvrType INTEGER, tn3270eSrvrConfContact SnmpAdminString, tn3270eSrvrConfRowStatus RowStatus, tn3270eSrvrConfLastActTime DateAndTime, tn3270eSrvrConfTmTimeout Unsigned32 } tn3270eSrvrConfIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifier for a single TN3270E server. tn3270eSrvrConfIndex values need not be contiguous." ::= { tn3270eSrvrConfEntry 1 } tn3270eSrvrConfInactivityTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..99999999) UNITS "seconds" MAX-ACCESS read-create White & Moore Standards Track [Page 14] RFC 2561 TN3270E Using SMIv2 MIB April 1999 STATUS current DESCRIPTION "The inactivity time-out specified in seconds. When a connection has been inactive for the number of seconds specified by this object it is closed. Only user traffic is considered when determining whether there has been activity on a connection. The default value 0 means that no inactivity time-out is in effect." DEFVAL { 0 } ::= { tn3270eSrvrConfEntry 2 } tn3270eSrvrConfConnectivityChk OBJECT-TYPE SYNTAX INTEGER { timingMark(1), nop(2), noCheck(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables TIMING-MARK processing, NOP processing, or neither for a TN3270E server." DEFVAL { noCheck } ::= { tn3270eSrvrConfEntry 3 } tn3270eSrvrConfTmNopInactTime OBJECT-TYPE SYNTAX Unsigned32 (1..86400) -- 1 second to 24 hours UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The amount of time a connection must have had no traffic on it in order for a TIMING-MARK or NOP request to be sent on the connection. This value applies only when connections are being examined for recent activity on a scan interval controlled by the value of the tn3270eSrvrConfTmNopInterval object." DEFVAL { 600 } -- 10 minutes ::= { tn3270eSrvrConfEntry 4 } tn3270eSrvrConfTmNopInterval OBJECT-TYPE SYNTAX Unsigned32 (1..86400) -- 1 second to 24 hours UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION White & Moore Standards Track [Page 15] RFC 2561 TN3270E Using SMIv2 MIB April 1999 "The scan interval to be used by a TN3270E server when it examines its Telnet connections for recent activity. The server scans its Telnet connections on the interval provided by this object, looking for ones that have been idle for more than the value provided by the tn3270eSrvrConfTmNopInactTime object. A TIMING-MARK or NOP request is sent for each connection that has exhibited no activity for this period of time." DEFVAL { 120 } -- 2 minutes ::= { tn3270eSrvrConfEntry 5 } tn3270eSrvrFunctionsSupported OBJECT-TYPE SYNTAX IANATn3270Functions MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the functions supported by a TN3270E server." DEFVAL { { scsCtlCodes, dataStreamCtl, responses, bindImage, sysreq } } ::= { tn3270eSrvrConfEntry 6 } tn3270eSrvrConfAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), stopImmediate(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the TN3270E server represented by this entry in the table: up(1) - Activate this TN3270E server. down(2) - Informs the associated TN3270E server to gracefully terminate its processing. stopImmediate(3) - Informs the associated TN3270E server to terminate itself immediately. When a managed system creates an entry in this table, tn3270eSrvrConfAdminStatus and tn3270eSrvrConfOperStatus are initialized as up(1) by default. The exact behavior of a server in response to a down(2) or stopImmediate(3) command is left implementation- White & Moore Standards Track [Page 16] RFC 2561 TN3270E Using SMIv2 MIB April 1999 dependent. A TN3270E server that is capable of it SHOULD close all of its TN3270 and TN3270E sessions during a graceful termination. Often the function enabled via stopImmediate(3) is used as a last resort by a system administrator, to attempt to either bring down a hung TN3270E server or free up its resources immediately to aid in general system availability, or to shut down a TN3270E server that is not recognizing a down(2) request. A TN3270E server that does not distinguish between down(2) or stopImmediate(3) transitions should not support stopImmediate(3)." DEFVAL { up } ::= { tn3270eSrvrConfEntry 7 } tn3270eSrvrConfOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), busy(3), shuttingDown(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of a TN3270E server. The following values are defined: up(1) - the server is active and accepting new client connections down(2) - the server is not active busy(3) - the server is active, but is not accepting new client connections because it lacks the resources to do so shuttingDown(4) - the server is active, but is not accepting new client connections because it is in the process of performing a graceful shutdown." DEFVAL { up } ::= { tn3270eSrvrConfEntry 8 } tn3270eSrvrConfSessionTermState OBJECT-TYPE SYNTAX INTEGER { terminate(1), luSessionPend(2), White & Moore Standards Track [Page 17] RFC 2561 TN3270E Using SMIv2 MIB April 1999 queueSession(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object determines what a TN3270E server should do when a TN3270 Session terminates: terminate(1) => Terminate the TCP connection. luSessionPend(2) => Do not drop the TCP connection associated with a client when its TN3270 session ends. Processing should redrive session initialization as if the client were first connecting. queueSession(3) => This value relates to the Close Destination PASS (CLSDST PASS) operation in VTAM. An example provides the easiest explanation. Suppose a TN3270E client is in session with APPL1, and APPL1 does a CLSDST PASS of the client's session to APPL2. queueSession(3) specifies that the TN3270E server must keep the TCP connection with the client active after it receives the UNBIND from APPL1, waiting for the BIND from APPL2." DEFVAL { terminate } ::= { tn3270eSrvrConfEntry 9 } tn3270eSrvrConfSrvrType OBJECT-TYPE SYNTAX INTEGER { host(1), gateway(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of TN3270E server. The existence of MIB tables and objects that will be defined by follow-on MIBs may be predicated on whether the TN3270E server can be local to the same host as a target application (host(1)) or will always be remote (gateway(2)). A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into an SNA network. White & Moore Standards Track [Page 18] RFC 2561 TN3270E Using SMIv2 MIB April 1999 A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) requirements." ::= { tn3270eSrvrConfEntry 10 } tn3270eSrvrConfContact OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This object provides a scratch pad for a TN3270E server administrator for storing information for later retrieval." DEFVAL { ''H } -- the empty string ::= { tn3270eSrvrConfEntry 11 } tn3270eSrvrConfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the tn3270eSrvrConfTable. Entries may also be created and deleted as a result of implementation- dependent operations. With the exception of tn3270eSrvrConfSrvrType, which an implementation can easily fill in for itself, all the columnar objects in this table have DEFVALs associated with them. Consequently, a Management Station can create a conceptual row via a SET operation that specifies a value only for this object. When a tn3270eSrvrConfEntry is deleted (by setting this object to destroy(6)), this has the side-effect of removing all the associated entries (i.e., those having the same tn3270eSrvrConfIndex) from the tn3270eSrvrPortTable, the tn3270eSrvrStatsTable, the tn3270eClientGroupTable, the tn3270eResPoolTable, the tn3270eSnaMapTable, the tn3270eClientResMapTable, and the tn3270eResMapTable. All entries in the tn3270eTcpConnTable that belong to a TN3270E server that has been deleted MUST also be removed. White & Moore Standards Track [Page 19] RFC 2561 TN3270E Using SMIv2 MIB April 1999 In other words, a tn3270eSrvrConfEntry must exist for a TN3270E server in order for it to have entries in any of the other tables defined by this MIB." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { tn3270eSrvrConfEntry 12 } tn3270eSrvrConfLastActTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This object reports the DateAndTime when a TN3270E server was most recently activated. The special value of all '00'Hs indicates that the server has never been active, i.e., that the value of tn3270eSrvrOperStatus has never been anything other than down(2)." DEFVAL { '0000000000000000'H } ::= { tn3270eSrvrConfEntry 13 } tn3270eSrvrConfTmTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..600) -- 1 second to 10 minutes UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The TIMING-MARK time-out, specified in seconds." DEFVAL { 5 } -- 5 seconds ::= { tn3270eSrvrConfEntry 14 } tn3270eSrvrPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eSrvrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the TCP ports associated with TN3270E servers. No entry in this table shall exist without a corresponding (same tn3270eSrvrConfIndex) entry in the tn3270eSrvrConfTable existing. An implementation SHOULD NOT retain SNMP-created entries in this table across re-IPLs (Initial Program Loads) of the corresponding TN3270E server." ::= { tn3270eObjects 2 } White & Moore Standards Track [Page 20] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eSrvrPortEntry OBJECT-TYPE SYNTAX Tn3270eSrvrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Definition of a single TCP port assignment to a TN3270E server. Assignment of a port on a local address basis is enabled though use of tn3270eSrvrPortAddrType and tn3270eSrvrPortAddress. A TCP port assignment that is not restricted to a local address SHALL specify a tn3270eSrvrPortAddrType of unknown(0), and SHALL use a zero-length octet string for the tn3270eSrvrPortAddress." INDEX { tn3270eSrvrConfIndex, tn3270eSrvrPort, tn3270eSrvrPortAddrType, tn3270eSrvrPortAddress } ::= { tn3270eSrvrPortTable 1 } Tn3270eSrvrPortEntry ::= SEQUENCE { tn3270eSrvrPort Unsigned32, tn3270eSrvrPortAddrType IANATn3270eAddrType, tn3270eSrvrPortAddress IANATn3270eAddress, tn3270eSrvrPortRowStatus RowStatus } tn3270eSrvrPort OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates a port assigned to a server." ::= { tn3270eSrvrPortEntry 1 } tn3270eSrvrPortAddrType OBJECT-TYPE SYNTAX IANATn3270eAddrType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the type of an address local to the host on which the TN3270E server resides that is represented in tn3270eSrvrPortAddress. A value of unknown(0) SHALL be used for this object when the port is not to be restricted to a local address." ::= { tn3270eSrvrPortEntry 2 } White & Moore Standards Track [Page 21] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eSrvrPortAddress OBJECT-TYPE SYNTAX IANATn3270eAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "A local address on the host that a TN3270E server resides on that is associated with a TCP port that is to be used or is in use by a TN3270E server. tn3270eClientGroupAddrType indicates the address type (IPv4 or IPv6, for example). A zero-length octet string SHALL be used as the value of this object when a local address isn't being specified." ::= { tn3270eSrvrPortEntry 3 } tn3270eSrvrPortRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the tn3270eSrvrPortTable. Entries may also be created and deleted as a result of implementation- dependent operations. Since this is the only accessible object in this table, a Management Station can create a conceptual row via a SET operation that specifies a value only for this object. An entry in this table is deleted by setting this object to destroy(6). Deletion of a tn3270eSrvrPortEntry has no effect on any other table entry defined by this MIB." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { tn3270eSrvrPortEntry 4 } tn3270eSrvrStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eSrvrStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines a set of statistics concerning TN3270E server performance. No entry in this table shall exist without a corresponding (same tn3270eSrvrConfIndex) entry in White & Moore Standards Track [Page 22] RFC 2561 TN3270E Using SMIv2 MIB April 1999 the tn3270eSrvrConfTable existing." ::= { tn3270eObjects 3 } tn3270eSrvrStatsEntry OBJECT-TYPE SYNTAX Tn3270eSrvrStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistical and maximum usage objects for a single TN3270 server. An entry can represent the total activity of the server, or it can represent the activity occurring at the server on either a port or a port-and-local-address basis. Collection of the statistics represented by the objects in this table is not mandatory. An implementation of this table MUST use only one of the three levels of refinement that this table supports for the entries associated with each TN3270E server. The indexing for a row that represents total server statistics is as follows: tn3270eSrvrConfIndex value identifying the server tn3270eSrvrPort 0 tn3270eSrvrPortAddrType unknown(0) tn3270eSrvrPortAddress zero-length octet string. On a port basis: tn3270eSrvrConfIndex value identifying the server tn3270eSrvrPort > 0 tn3270eSrvrPortAddrType unknown(0) tn3270eSrvrPortAddress zero-length octet string. On a port-and-local-address basis: tn3270eSrvrConfIndex value identifying the server tn3270eSrvrPort > 0 tn3270eSrvrPortAddrType valid value other than unknown(0) tn3270eSrvrPortAddress non-zero-length octet string. " INDEX { tn3270eSrvrConfIndex, tn3270eSrvrPort, tn3270eSrvrPortAddrType, tn3270eSrvrPortAddress White & Moore Standards Track [Page 23] RFC 2561 TN3270E Using SMIv2 MIB April 1999 } ::= { tn3270eSrvrStatsTable 1 } Tn3270eSrvrStatsEntry ::= SEQUENCE { tn3270eSrvrStatsUpTime TimeStamp, tn3270eSrvrStatsMaxTerms Unsigned32, tn3270eSrvrStatsInUseTerms Gauge32, tn3270eSrvrStatsSpareTerms Gauge32, tn3270eSrvrStatsMaxPtrs Unsigned32, tn3270eSrvrStatsInUsePtrs Gauge32, tn3270eSrvrStatsSparePtrs Gauge32, tn3270eSrvrStatsInConnects Counter32, tn3270eSrvrStatsConnResrceRejs Counter32, tn3270eSrvrStatsDisconnects Counter32, tn3270eSrvrStatsHCInOctets Counter64, tn3270eSrvrStatsInOctets Counter32, tn3270eSrvrStatsHCOutOctets Counter64, tn3270eSrvrStatsOutOctets Counter32, tn3270eSrvrStatsConnErrorRejs Counter32 } tn3270eSrvrStatsUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object the last time the TN3270E server was re-initialized. Server re-initialization is the only discontinuity event for the counters in this table. Even if table entries are on a port or port-and-local-address basis, port deactivation and reactivation do not result in counter discontinuities." ::= { tn3270eSrvrStatsEntry 2 } tn3270eSrvrStatsMaxTerms OBJECT-TYPE SYNTAX Unsigned32 UNITS "LUs" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the maximum number of terminal LUs available for use at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address)." ::= { tn3270eSrvrStatsEntry 3 } White & Moore Standards Track [Page 24] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eSrvrStatsInUseTerms OBJECT-TYPE SYNTAX Gauge32 UNITS "LUs" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of terminal LUs currently in use at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address)." ::= { tn3270eSrvrStatsEntry 4 } tn3270eSrvrStatsSpareTerms OBJECT-TYPE SYNTAX Gauge32 UNITS "LUs" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of free terminal LUs at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address). It is possible that the difference between tn3270eSrvrStatsMaxTerms and tn3270eSrvrStatsInUseTerms in a conceptual row does not equal the value of tn3270eSrvrStatsSpareTerms in that row: an LU may exist but not be usable by a client connection. Alternatively, the administrative ceiling represented by tn3270eSrvrStatsMaxTerms may have been lowered to a point where it is less than the current value of tn3270eSrvrStatsInUseTerms. In this case tn3270eSrvrStatsSpareTerms returns the value 0." ::= { tn3270eSrvrStatsEntry 5 } tn3270eSrvrStatsMaxPtrs OBJECT-TYPE SYNTAX Unsigned32 UNITS "Printer Resources" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the maximum number of printer resources available for use by a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address)." ::= { tn3270eSrvrStatsEntry 6 } White & Moore Standards Track [Page 25] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eSrvrStatsInUsePtrs OBJECT-TYPE SYNTAX Gauge32 UNITS "Printer Resources" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of printer resources currently in use by a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address)." ::= { tn3270eSrvrStatsEntry 7 } tn3270eSrvrStatsSparePtrs OBJECT-TYPE SYNTAX Gauge32 UNITS "Spare Printer Resources" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of free printer resources at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address). It is possible that the difference between tn3270eSrvrStatsMaxPtrs and tn3270eSrvrStatsInUsePtrs in a conceptual row does not equal the value of tn3270eSrvrStatsSparePtrs in that row: a printer resource may exist but not be usable by a client connection. Alternatively, the administrative ceiling represented by tn3270eSrvrStatsMaxPtrs may have been lowered to a point where it is less than the current value of tn3270eSrvrStatsInUsePtrs. In this case tn3270eSrvrStatsSparePtrs returns the value 0." ::= { tn3270eSrvrStatsEntry 8 } tn3270eSrvrStatsInConnects OBJECT-TYPE SYNTAX Counter32 UNITS "connections" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of client (TCP) connections that succeeded at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address). The tn3270eSrvrStatsConnResrceRejs and White & Moore Standards Track [Page 26] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eSrvrStatsConnErrorRejs objects provide a count of failed connection attempts. A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 9 } tn3270eSrvrStatsConnResrceRejs OBJECT-TYPE SYNTAX Counter32 UNITS "connection attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of (TCP) connections rejected during connection setup at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address) due to a lack of resources at the server. An example of when this counter would be incremented is when no terminal or printer resource is available to associate with a client's TCP connection. A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 10 } tn3270eSrvrStatsDisconnects OBJECT-TYPE SYNTAX Counter32 UNITS "disconnections" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of (TCP) connections that were disconnected at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address). A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 11 } tn3270eSrvrStatsHCInOctets OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only White & Moore Standards Track [Page 27] RFC 2561 TN3270E Using SMIv2 MIB April 1999 STATUS current DESCRIPTION "Indicates the number of octets received from TN3270 and TN3270E clients for the granularity of this conceptual row (server-wide, port, or port-and-local-address). A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 12 } tn3270eSrvrStatsInOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Low-order 32 bits of tn3270eSrvrStatsHCInOctets for this conceptual row. A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 13 } tn3270eSrvrStatsHCOutOctets OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of octets sent to TN3270 and TN3270E clients for the granularity of this conceptual row (server-wide, port, or port-and-local-address). A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 14 } tn3270eSrvrStatsOutOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION White & Moore Standards Track [Page 28] RFC 2561 TN3270E Using SMIv2 MIB April 1999 "Low-order 32 bits of tn3270eSrvrStatsHCOutOctets for this conceptual row. A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 15 } tn3270eSrvrStatsConnErrorRejs OBJECT-TYPE SYNTAX Counter32 UNITS "connection attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of (TCP) connections rejected during connection setup at a TN3270E server for the granularity of this conceptual row (server-wide, port, or port-and-local-address) due to an error of some type. An example of when this counter would be incremented is when the client and the server cannot agree on a common set of TN3270E functions for the connection. A Management Station can detect discontinuities in this counter by monitoring the tn3270eSrvrStatsUpTime object." ::= { tn3270eSrvrStatsEntry 16 } tn3270eClientGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eClientGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines client address groupings for use by a TN3270E server. No entry in this table shall exist without a corresponding (same tn3270eSrvrConfIndex) entry in the tn3270eSrvrConfTable existing. An implementation SHOULD NOT retain SNMP-created entries in this table across re-IPLs (Initial Program Loads) of the corresponding TN3270E server." ::= { tn3270eObjects 4 } tn3270eClientGroupEntry OBJECT-TYPE SYNTAX Tn3270eClientGroupEntry MAX-ACCESS not-accessible White & Moore Standards Track [Page 29] RFC 2561 TN3270E Using SMIv2 MIB April 1999 STATUS current DESCRIPTION "Definition of a single client address entry. All entries with the same first two indexes, tn3270eSrvrConfIndex and tn3270eClientGroupName, are considered to be in the same client group." INDEX { tn3270eSrvrConfIndex, tn3270eClientGroupName, tn3270eClientGroupAddrType, tn3270eClientGroupAddress } ::= { tn3270eClientGroupTable 1 } Tn3270eClientGroupEntry ::= SEQUENCE { tn3270eClientGroupName Utf8String, tn3270eClientGroupAddrType IANATn3270eAddrType, tn3270eClientGroupAddress IANATn3270eAddress, tn3270eClientGroupSubnetMask IpAddress, tn3270eClientGroupPfxLength Unsigned32, tn3270eClientGroupRowStatus RowStatus } tn3270eClientGroupName OBJECT-TYPE SYNTAX Utf8String (SIZE(1..24)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a client group. Note: client group names are required to be unique only with respect to a single TN3270E server." ::= { tn3270eClientGroupEntry 1 } tn3270eClientGroupAddrType OBJECT-TYPE SYNTAX IANATn3270eAddrType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the type of the address represented in tn3270eClientGroupAddress." ::= { tn3270eClientGroupEntry 2 } tn3270eClientGroupAddress OBJECT-TYPE SYNTAX IANATn3270eAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The client address of a member of a client group. The value of tn3270eClientGroupAddrType indicates the address type (IPv4 or IPv6, for example)." White & Moore Standards Track [Page 30] RFC 2561 TN3270E Using SMIv2 MIB April 1999 ::= { tn3270eClientGroupEntry 3 } tn3270eClientGroupSubnetMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The corresponding subnet mask associated with tn3270eClientGroupAddress. A single IP address is represented by having this object contain the value of 255.255.255.255. This object's value is meaningful only if tn3270eClientGroupAddrType has a value of ipv4(1)." DEFVAL { 'FFFFFFFF'H } ::= { tn3270eClientGroupEntry 4 } tn3270eClientGroupPfxLength OBJECT-TYPE SYNTAX Unsigned32 (0..128) UNITS "bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The corresponding IPv6 network prefix length. This object's value is meaningful only if tn3270eClientGroupAddrType has a value of ipv6(2)." DEFVAL { 0 } ::= { tn3270eClientGroupEntry 5 } tn3270eClientGroupRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the tn3270eClientGroupTable. Entries may also be created and deleted as a result of implementation- dependent operations. An entry in this table is deleted by setting this object to destroy(6). When the number of entries in this table for a given client group becomes 0, this has the side- effect of removing any entries for the group in the tn3270eClientResMapTable." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" White & Moore Standards Track [Page 31] RFC 2561 TN3270E Using SMIv2 MIB April 1999 ::= { tn3270eClientGroupEntry 6 } tn3270eResPoolTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eResPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines resource groupings; the term 'pool' is used as it is defined by RFC 2355. No entry in this table shall exist without a corresponding (same tn3270eSrvrConfIndex) entry in the tn3270eSrvrConfTable existing. An implementation SHOULD NOT retain SNMP-created entries in this table across re-IPLs (Initial Program Loads) of the corresponding TN3270E server." ::= { tn3270eObjects 5 } tn3270eResPoolEntry OBJECT-TYPE SYNTAX Tn3270eResPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Definition of a single resource pool member. All entries with the same first two indexes, tn3270eSrvrConfIndex and tn3270eResPoolName, are considered to be in the same pool." INDEX { tn3270eSrvrConfIndex, tn3270eResPoolName, tn3270eResPoolElementName } ::= { tn3270eResPoolTable 1 } Tn3270eResPoolEntry ::= SEQUENCE { tn3270eResPoolName Utf8String, tn3270eResPoolElementName SnaResourceName, tn3270eResPoolElementType IANATn3270ResourceType, tn3270eResPoolRowStatus RowStatus } tn3270eResPoolName OBJECT-TYPE SYNTAX Utf8String (SIZE(1..24)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a resource pool." ::= { tn3270eResPoolEntry 1 } tn3270eResPoolElementName OBJECT-TYPE White & Moore Standards Track [Page 32] RFC 2561 TN3270E Using SMIv2 MIB April 1999 SYNTAX SnaResourceName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a member of a resource pool." ::= { tn3270eResPoolEntry 2 } tn3270eResPoolElementType OBJECT-TYPE SYNTAX IANATn3270ResourceType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the entity in a resource pool." ::= { tn3270eResPoolEntry 3 } tn3270eResPoolRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the tn3270eResPoolTable. Entries may also be created and deleted as a result of implementation- dependent operations. An entry in this table is deleted by setting this object to destroy(6). When all entries in this table associated with the same tn3270eResPoolElementName have been removed, then any associated (tn3270eResPoolElementName matching tn3270eClientResMapPoolName with same tn3270eSrvrConfIndex values) entries in the tn3270eClientResMapTable SHALL also be removed." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { tn3270eResPoolEntry 4 } tn3270eSnaMapTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eSnaMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provide a mapping from the name by which a secondary LU is known in the SNA network to the name by which it is known locally at the TN3270e server. This latter name serves as an index into the tn3270eResPoolTable and the tn3270eResMapTable. White & Moore Standards Track [Page 33] RFC 2561 TN3270E Using SMIv2 MIB April 1999 No entry in this table shall exist without a corresponding (same tn3270eSrvrConfIndex) entry in the tn3270eSrvrConfTable existing." ::= { tn3270eObjects 6 } tn3270eSnaMapEntry OBJECT-TYPE SYNTAX Tn3270eSnaMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Definition of a single mapping from an SSCP-supplied SLU name to a local SLU name. Note: In certain pathological cases, it is possible that an SSCP will send on an ACTLU for a local LU an SLU name currently represented by an entry in this table that associates it with a different local LU. In these cases the association from the newer ACTLU SHOULD be the one represented in this table." INDEX { tn3270eSrvrConfIndex, tn3270eSnaMapSscpSuppliedName } ::= { tn3270eSnaMapTable 1 } Tn3270eSnaMapEntry ::= SEQUENCE { tn3270eSnaMapSscpSuppliedName SnaResourceName, tn3270eSnaMapLocalName SnaResourceName, tn3270eSnaMapPrimaryLuName SnaResourceName } tn3270eSnaMapSscpSuppliedName OBJECT-TYPE SYNTAX SnaResourceName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the secondary LU (SLU) as it is known in the SNA network. This name is sent by the SSCP on the Activate Logical Unit (ACTLU) request." ::= { tn3270eSnaMapEntry 1 } tn3270eSnaMapLocalName OBJECT-TYPE SYNTAX SnaResourceName MAX-ACCESS read-only STATUS current DESCRIPTION "The local name of the secondary LU (SLU)." ::= { tn3270eSnaMapEntry 2 } tn3270eSnaMapPrimaryLuName OBJECT-TYPE White & Moore Standards Track [Page 34] RFC 2561 TN3270E Using SMIv2 MIB April 1999 SYNTAX SnaResourceName MAX-ACCESS read-only STATUS current DESCRIPTION "When there is a currently active LU-LU session for this connection, this object returns the primary LU (PLU) name from the BIND. When there is no active LU-LU session, or when the PLU name is unavailable for some other reason, this object returns a zero-length octet string." ::= { tn3270eSnaMapEntry 3 } tn3270eClientResMapTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eClientResMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines resource-pool to client-group mappings. Since both the resource pool name and client group name are included in the index clause of this table, multiple resource pools can be assigned to the same client group. This enables use of multiple resource pools for use in client to resource mapping. Assigning multiple client groups to the same resource pool is also allowed, but is not the primary purpose for how the indexing is structured. Assignment of a resource pool to client group can be restricted based on TCP port. An index value of 0 for tn3270eClientResMapClientPort disables restriction of resource assignment based on client target port selection. No entry in this table shall exist without a corresponding (same tn3270eSrvrConfIndex) entry in the tn3270eSrvrConfTable existing. An implementation SHOULD NOT retain SNMP-created entries in this table across re-IPLs (Initial Program Loads) of the corresponding TN3270E server." ::= { tn3270eObjects 7 } tn3270eClientResMapEntry OBJECT-TYPE SYNTAX Tn3270eClientResMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Definition of a single resource pool to client group White & Moore Standards Track [Page 35] RFC 2561 TN3270E Using SMIv2 MIB April 1999 mapping." INDEX { tn3270eSrvrConfIndex, tn3270eClientResMapPoolName, tn3270eClientResMapClientGroupName, tn3270eClientResMapClientPort } ::= { tn3270eClientResMapTable 1 } Tn3270eClientResMapEntry ::= SEQUENCE { tn3270eClientResMapPoolName Utf8String, tn3270eClientResMapClientGroupName Utf8String, tn3270eClientResMapClientPort Unsigned32, tn3270eClientResMapRowStatus RowStatus } tn3270eClientResMapPoolName OBJECT-TYPE SYNTAX Utf8String (SIZE(1..24)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a resource pool." ::= { tn3270eClientResMapEntry 1 } tn3270eClientResMapClientGroupName OBJECT-TYPE SYNTAX Utf8String (SIZE(1..24)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the client group that is mapped to a resource pool." ::= { tn3270eClientResMapEntry 2 } tn3270eClientResMapClientPort OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A port number restricting the scope of a mapping from a resource pool to a client group. The value 0 for this object indicates that the scope of the mapping is not restricted." ::= { tn3270eClientResMapEntry 3 } tn3270eClientResMapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted White & Moore Standards Track [Page 36] RFC 2561 TN3270E Using SMIv2 MIB April 1999 in the tn3270eClientResMapTable. Entries may also be created and deleted as a result of implementation- dependent operations. An entry in this table is deleted by setting this object to destroy(6). Removing an entry from this table doesn't affect any other table entry defined in this MIB." REFERENCE "RFC 1903, 'Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2).'" ::= { tn3270eClientResMapEntry 4 } tn3270eResMapTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eResMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the actual mapping of a resource to a client address. No entry in this table shall exist without a corresponding (same tn3270eSrvrConfIndex) entry in the tn3270eSrvrConfTable existing." ::= { tn3270eObjects 8 } tn3270eResMapEntry OBJECT-TYPE SYNTAX Tn3270eResMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Definition of the mapping of a Resource Element to a client address." INDEX { tn3270eSrvrConfIndex, tn3270eResMapElementName } ::= { tn3270eResMapTable 1 } Tn3270eResMapEntry ::= SEQUENCE { tn3270eResMapElementName SnaResourceName, tn3270eResMapAddrType IANATn3270eAddrType, tn3270eResMapAddress IANATn3270eAddress, tn3270eResMapPort Unsigned32, tn3270eResMapElementType IANATn3270ResourceType, tn3270eResMapSscpSuppliedName SnaResourceName } tn3270eResMapElementName OBJECT-TYPE SYNTAX SnaResourceName MAX-ACCESS not-accessible White & Moore Standards Track [Page 37] RFC 2561 TN3270E Using SMIv2 MIB April 1999 STATUS current DESCRIPTION "The name of a resource element. This is the name by which the server implementing this table knows the resource. It may be different from the name by which the resource is known in the SNA network. This latter name is returned in the tn3270eResMapSscpSuppliedName object." ::= { tn3270eResMapEntry 1 } tn3270eResMapAddrType OBJECT-TYPE SYNTAX IANATn3270eAddrType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the type of the client address represented in tn3270eResMapAddress." ::= { tn3270eResMapEntry 2 } tn3270eResMapAddress OBJECT-TYPE SYNTAX IANATn3270eAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A client address." ::= { tn3270eResMapEntry 3 } tn3270eResMapPort OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "A client port." ::= { tn3270eResMapEntry 4 } tn3270eResMapElementType OBJECT-TYPE SYNTAX IANATn3270ResourceType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the associated resource element." ::= { tn3270eResMapEntry 5 } tn3270eResMapSscpSuppliedName OBJECT-TYPE SYNTAX SnaResourceName MAX-ACCESS read-only STATUS current DESCRIPTION White & Moore Standards Track [Page 38] RFC 2561 TN3270E Using SMIv2 MIB April 1999 "The name of the secondary LU (SLU) as it is known in a SNA network. This name is sent by the SSCP on the Activate Logical Unit (ACTLU) request. If this name is not known, this object returns a zero-length octet string." ::= { tn3270eResMapEntry 6 } -- Define the set of objects to supplement the TCP Connection Table tn3270eTcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eTcpConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table has an entry for each TN3270(E) client connection that is currently active at a TN3270E server. An implementation MAY retain entries for connections that have been terminated, but which entries are retained, how many entries are retained, and how long they are retained is entirely implementation-dependent. The indexing for this table is designed to support the use of an SNMP GET-NEXT operation using only the remote address type, remote address, and remote port, as a way for a Management Station to retrieve the table entries related to a particular TN3270(E) client." ::= { tn3270eObjects 9 } tn3270eTcpConnEntry OBJECT-TYPE SYNTAX Tn3270eTcpConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides information about a single TN3270/TN3270E session. Note: a tn3270eSrvrConfIndex is not needed in this table, since the combination of remote and local addresses and ports is sufficient to guarantee uniqueness across the TN3270E servers serviced by an SNMP agent. Because of this indexing structure, however, this table does not support view-based access control policies that provide access to table rows on a per-server basis." INDEX { tn3270eTcpConnRemAddrType, tn3270eTcpConnRemAddress, tn3270eTcpConnRemPort, tn3270eTcpConnLocalAddrType, tn3270eTcpConnLocalAddress, tn3270eTcpConnLocalPort White & Moore Standards Track [Page 39] RFC 2561 TN3270E Using SMIv2 MIB April 1999 } ::= { tn3270eTcpConnTable 1 } Tn3270eTcpConnEntry ::= SEQUENCE { tn3270eTcpConnRemAddrType IANATn3270eAddrType, tn3270eTcpConnRemAddress IANATn3270eAddress, tn3270eTcpConnRemPort Unsigned32, tn3270eTcpConnLocalAddrType IANATn3270eAddrType, tn3270eTcpConnLocalAddress IANATn3270eAddress, tn3270eTcpConnLocalPort Unsigned32, tn3270eTcpConnLastActivity TimeTicks, tn3270eTcpConnBytesIn Counter32, tn3270eTcpConnBytesOut Counter32, tn3270eTcpConnResourceElement SnaResourceName, tn3270eTcpConnResourceType IANATn3270ResourceType, tn3270eTcpConnDeviceType IANATn3270DeviceType, tn3270eTcpConnFunctions IANATn3270Functions, tn3270eTcpConnId Unsigned32, tn3270eTcpConnClientIdFormat IANATn3270eClientType, tn3270eTcpConnClientId OCTET STRING, tn3270eTcpConnTraceData Tn3270eTraceData, tn3270eTcpConnLogInfo IANATn3270eLogData, tn3270eTcpConnLuLuBindImage OCTET STRING, tn3270eTcpConnSnaState INTEGER, tn3270eTcpConnStateLastDiscReason INTEGER, tn3270eTcpConnSrvrConfIndex Unsigned32, tn3270eTcpConnActivationTime TimeStamp } tn3270eTcpConnRemAddrType OBJECT-TYPE SYNTAX IANATn3270eAddrType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the type of the value of the tn3270eTcpConnRemAddress object. For example, ipv4(1) or ipv6(2)." ::= { tn3270eTcpConnEntry 1 } tn3270eTcpConnRemAddress OBJECT-TYPE SYNTAX IANATn3270eAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote address associated with a TN3270E client. tn3270eTcpConnRemAddrType indicates the address type White & Moore Standards Track [Page 40] RFC 2561 TN3270E Using SMIv2 MIB April 1999 (IPv4 or IPv6, for example). If a TN3270(E) client is connected to its server via a proxy client the address represented by the value of this object shall be the remote client's address, not the proxy client's address." ::= { tn3270eTcpConnEntry 2 } tn3270eTcpConnRemPort OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port associated with a TN3270E client. The value 0 is used if the tn3270eTcpConnRemAddrType identifies an address type that does not support ports. If a TN3270(E) client is connected to its server via a proxy client, the port represented by the value of this object shall be the remote client's port, not the proxy client's port." ::= { tn3270eTcpConnEntry 3 } tn3270eTcpConnLocalAddrType OBJECT-TYPE SYNTAX IANATn3270eAddrType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the type of the value of the tn3270eTcpConnLocalAddress object. For example, ipv4(1) or ipv6(2)." ::= { tn3270eTcpConnEntry 4 } tn3270eTcpConnLocalAddress OBJECT-TYPE SYNTAX IANATn3270eAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local address associated with a TN3270E client. tn3270eTcpConnRemAddrType indicates the address type (IPv4 or IPv6, for example)." ::= { tn3270eTcpConnEntry 5 } tn3270eTcpConnLocalPort OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port associated with a TN3270E client." White & Moore Standards Track [Page 41] RFC 2561 TN3270E Using SMIv2 MIB April 1999 ::= { tn3270eTcpConnEntry 6 } tn3270eTcpConnLastActivity OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 100ths of seconds since any data was transferred for the associated TCP Connection." DEFVAL { 0 } ::= { tn3270eTcpConnEntry 7 } tn3270eTcpConnBytesIn OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes received by the server from TCP for this connection. A Management Station can detect discontinuities in this counter by monitoring the tn3270eTcpConnActivationTime object." ::= { tn3270eTcpConnEntry 8 } tn3270eTcpConnBytesOut OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes sent to TCP for this connection. A Management Station can detect discontinuities in this counter by monitoring the tn3270eTcpConnActivationTime object." ::= { tn3270eTcpConnEntry 9 } tn3270eTcpConnResourceElement OBJECT-TYPE SYNTAX SnaResourceName MAX-ACCESS read-only STATUS current DESCRIPTION "LU/Print secondary name for connecting an client into an SNA network." ::= { tn3270eTcpConnEntry 10 } White & Moore Standards Track [Page 42] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eTcpConnResourceType OBJECT-TYPE SYNTAX IANATn3270ResourceType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the type of resource identified by tn3270eTcpConnResourceElement." ::= { tn3270eTcpConnEntry 11 } tn3270eTcpConnDeviceType OBJECT-TYPE SYNTAX IANATn3270DeviceType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the device type if negotiated with the client. A value of unknown(100) should be used as the value of this object when a device type is not negotiated. Refer to RFC 2355 for how device types can be negotiated." ::= { tn3270eTcpConnEntry 12 } tn3270eTcpConnFunctions OBJECT-TYPE SYNTAX IANATn3270Functions MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates which of the TN3270 and TN3270E functions were negotiated by the server and the client for this TCP connection. Refer to tn3270eSrvrFunctionsSupported for the list of these functions supported by the server." ::= { tn3270eTcpConnEntry 13 } tn3270eTcpConnId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The connection identifier associated with a TN3270 or a TN3270E session's TCP connection. TCP implementations often assign a unique (with respect to itself) unsigned integer as an identifier for a TCP connection. The value 0 indicates that a connection does not have a valid connection identifier." ::= { tn3270eTcpConnEntry 14 } White & Moore Standards Track [Page 43] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eTcpConnClientIdFormat OBJECT-TYPE SYNTAX IANATn3270eClientType MAX-ACCESS read-only STATUS current DESCRIPTION "The format of a corresponding tn3270eTcpConnClientId object as defined by the IANSTn3270eClientType textual convention imported from the IANATn3270eTC-MIB." ::= { tn3270eTcpConnEntry 15 } tn3270eTcpConnClientId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "Additional client identification information. The type of this information is indicated by the value of the corresponding tn3270eTcpConnClientIdFormat object. All values are returned in network-byte order. The purpose of this object is to provide an alternate means of identifying a client, other than though the remote address returned in tn3270eTcpConnRemAddress." ::= { tn3270eTcpConnEntry 16 } tn3270eTcpConnTraceData OBJECT-TYPE SYNTAX Tn3270eTraceData MAX-ACCESS read-only STATUS current DESCRIPTION "Trace data for this session." ::= { tn3270eTcpConnEntry 17 } tn3270eTcpConnLogInfo OBJECT-TYPE SYNTAX IANATn3270eLogData MAX-ACCESS read-only STATUS current DESCRIPTION "Log information, encoded as specified in the IANATn3270eLogData textual convention from the IANAtn3270eTC-MIB." ::= { tn3270eTcpConnEntry 18 } tn3270eTcpConnLuLuBindImage OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-only STATUS current DESCRIPTION White & Moore Standards Track [Page 44] RFC 2561 TN3270E Using SMIv2 MIB April 1999 "When there is a currently active LU-LU session for this connection, this object returns the BIND Image (defined to be bytes 1-p of the complete BIND Request Unit -- see 'SNA Formats' for more information) that was received from the PLU during session activation. When there is no active LU-LU session, or when a BIND image is unavailable for some other reason, this object returns a zero-length octet string." REFERENCE "'Systems Network Architecture Formats', IBM Publication GA27-3136." ::= { tn3270eTcpConnEntry 19 } tn3270eTcpConnSnaState OBJECT-TYPE SYNTAX INTEGER { unknown(1), noSluSession(2), sscpLuSession(3), -- but no LU-LU session luLuSession(4), -- but no SSCP-LU session sscpLuSessionAndLuLuSession(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the SNA side of the end-to-end TN3270 connection. The following states are defined: unknown(1) - The true state is not known. noSluSession(2) - The SLU has neither an SSCP-LU nor an LU-LU session active. sscpLuSession(3) - The SSCP-LU session for the SLU is active, but the SLU is not currently in session with a PLU. luLuSession(4) - The SLU is currently in session with a PLU, but the SSCP-LU session for the LU is not active. sscpLuSessionAndLuLuSession(5) - The SLU currently has an active session with a PLU, and the SSCP-LU session for the SLU is active." ::= { tn3270eTcpConnEntry 20 } tn3270eTcpConnStateLastDiscReason OBJECT-TYPE SYNTAX INTEGER { unknown(1), hostSendsUnbind(2), White & Moore Standards Track [Page 45] RFC 2561 TN3270E Using SMIv2 MIB April 1999 hostDontAcceptConnection(3), outOfResource(4), clientProtocolError(5), invalidDeviceName(6), deviceInUse(7), inactivityTimeout(8), hostNotResponding(9), clientNotResponding(10), serverClose(11), sysreqLogoff(12), serverSpecificHexCode(13) } MAX-ACCESS read-only STATUS current DESCRIPTION "The last disconnect reason. A session that has not experienced a disconnect shall use the value unknown(1) for this object. Depending on when an implementation removes entries from this table, certain states may never be returned." ::= { tn3270eTcpConnEntry 21 } tn3270eTcpConnSrvrConfIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "tn3270eSrvrConfIndex of the tn3270eSrvrConfEntry belonging to the TN3270E server to which this entry belongs." ::= { tn3270eTcpConnEntry 22 } tn3270eTcpConnActivationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object the last time this TCP connection became active." ::= { tn3270eTcpConnEntry 23 } tn3270eConfSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating TN3270E-MIB applications to coordinate their use White & Moore Standards Track [Page 46] RFC 2561 TN3270E Using SMIv2 MIB April 1999 of the tn3270eSrvrConfTable, the tn3270eSrvrPortTable, the tn3270eClientGroupTable, the tn3270eResPoolTable, and the tn3270eClientResMapTable. When creating a new entry or altering an existing entry in the any of the tables mentioned above, an application should make use of tn3270eRtSpinLock to serialize application changes or additions. Since this is an advisory lock, the use of this lock is not enforced." ::= { tn3270eObjects 10 } -- Conformance Definitions tn3270eGroups OBJECT IDENTIFIER ::= { tn3270eConformance 1 } tn3270eCompliances OBJECT IDENTIFIER ::= { tn3270eConformance 2 } -- compliance statements tn3270eCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the TN3270E-MIB." MODULE -- this module MANDATORY-GROUPS { tn3270eBasicGroup, tn3270eSessionGroup } GROUP tn3270eResMapGroup DESCRIPTION "This group is optional and provides a method of performing tn3270eClientGroup to tn3270eResPool mapping." GROUP tn3270eHiCapacityGroup DESCRIPTION "This group is optional and provides for support of high capacity counters." OBJECT tn3270eSrvrConfConnectivityChk MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a set to this object if the associated TN3270E server doesn't support either TIMING-MARK or NOP processing. In this case an agent should return noCheck on White & Moore Standards Track [Page 47] RFC 2561 TN3270E Using SMIv2 MIB April 1999 retrieval." OBJECT tn3270eSrvrConfTmNopInactTime MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a set to this object if the functions enabled by tn3270eSrvrConfConnectivityChk are not supported. An agent in this case should return a value of 0." OBJECT tn3270eSrvrConfTmNopInterval MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a set to this object if the functions enabled by tn3270eSrvrConfConnectivityChk are not supported. An agent in this case should return a value of 0." OBJECT tn3270eSrvrConfAdminStatus DESCRIPTION "A TN3270E server is not required to support a stopImmediate state transition." OBJECT tn3270eSrvrConfRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tn3270eSrvrConfTmTimeout MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a set to this object if the functions enabled by tn3270eSrvrConfConnectivityChk are not supported. An agent in this case should return a value of 0." OBJECT tn3270eSrvrPortRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tn3270eClientGroupRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tn3270eResPoolRowStatus MIN-ACCESS read-only White & Moore Standards Track [Page 48] RFC 2561 TN3270E Using SMIv2 MIB April 1999 DESCRIPTION "Write access is not required." OBJECT tn3270eClientResMapRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { tn3270eCompliances 1 } -- units of conformance tn3270eBasicGroup OBJECT-GROUP OBJECTS { tn3270eSrvrConfInactivityTimeout, tn3270eSrvrConfConnectivityChk, tn3270eSrvrConfTmNopInactTime, tn3270eSrvrConfTmNopInterval, tn3270eSrvrFunctionsSupported, tn3270eSrvrConfAdminStatus, tn3270eSrvrConfOperStatus, tn3270eSrvrConfSessionTermState, tn3270eSrvrConfSrvrType, tn3270eSrvrConfContact, tn3270eSrvrConfRowStatus, tn3270eSrvrConfLastActTime, tn3270eSrvrConfTmTimeout, tn3270eSrvrPortRowStatus, tn3270eSrvrStatsUpTime, tn3270eSrvrStatsMaxTerms, tn3270eSrvrStatsInUseTerms, tn3270eSrvrStatsSpareTerms, tn3270eSrvrStatsMaxPtrs, tn3270eSrvrStatsInUsePtrs, tn3270eSrvrStatsSparePtrs, tn3270eSrvrStatsInConnects, tn3270eSrvrStatsConnResrceRejs, tn3270eSrvrStatsDisconnects, tn3270eSrvrStatsInOctets, tn3270eSrvrStatsOutOctets, tn3270eSrvrStatsConnErrorRejs, tn3270eClientGroupSubnetMask, tn3270eClientGroupPfxLength, tn3270eClientGroupRowStatus, tn3270eSnaMapLocalName, tn3270eSnaMapPrimaryLuName, tn3270eConfSpinLock } White & Moore Standards Track [Page 49] RFC 2561 TN3270E Using SMIv2 MIB April 1999 STATUS current DESCRIPTION "This group is mandatory for all hosts supporting the TN3270E-MIB." ::= { tn3270eGroups 1 } tn3270eSessionGroup OBJECT-GROUP OBJECTS { tn3270eResMapAddrType, tn3270eResMapAddress, tn3270eResMapPort, tn3270eResMapElementType, tn3270eResMapSscpSuppliedName, tn3270eTcpConnLastActivity, tn3270eTcpConnBytesIn, tn3270eTcpConnBytesOut, tn3270eTcpConnResourceElement, tn3270eTcpConnResourceType, tn3270eTcpConnDeviceType, tn3270eTcpConnFunctions, tn3270eTcpConnSrvrConfIndex, tn3270eTcpConnActivationTime } STATUS current DESCRIPTION "This group is mandatory for all hosts supporting the TN3270E-MIB." ::= { tn3270eGroups 2 } tn3270eResMapGroup OBJECT-GROUP OBJECTS { tn3270eResPoolElementType, tn3270eResPoolRowStatus, tn3270eClientResMapRowStatus, tn3270eTcpConnId, tn3270eTcpConnClientIdFormat, tn3270eTcpConnClientId, tn3270eTcpConnTraceData, tn3270eTcpConnLogInfo, tn3270eTcpConnLuLuBindImage, tn3270eTcpConnSnaState, tn3270eTcpConnStateLastDiscReason } STATUS current DESCRIPTION "This group is optional for all hosts supporting the TN3270E-MIB." ::= { tn3270eGroups 3 } White & Moore Standards Track [Page 50] RFC 2561 TN3270E Using SMIv2 MIB April 1999 tn3270eHiCapacityGroup OBJECT-GROUP OBJECTS { tn3270eSrvrStatsHCInOctets, tn3270eSrvrStatsHCOutOctets } STATUS current DESCRIPTION "Support of these objects is REQUIRED when the Counter32 versions can potentially wrap too frequently. This group is optional for all other hosts supporting the TN3270E-MIB. The IF-MIB (RFC 2233) requires that the 64-bit versions of its counters be implemented when an interface can support rates of around 20 million bits per second or greater. This implies a minimum wrap rate of just over 28 minutes. It is recommended that this same guideline be used for determining whether an implementation implements these objects. This group contains two objects with the syntax Counter64. An implementation that doesn't support these objects should return noSuchObject, since returning a zero is misleading." ::= { tn3270eGroups 4 } END 5.0 Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. An authentication protocol is defined in [12]. A protocol for access control is defined in [15]. Several objects in this MIB allow write access or provide for row creation. Allowing this support in a non-secure environment can have a negative effect on network operations. It is RECOMMENDED that implementers seriously consider whether set operations or row creation should be allowed without providing, at a minimum, authentication of request origin. It is RECOMMENDED that without such support, the following objects be implemented as read-only: White & Moore Standards Track [Page 51] RFC 2561 TN3270E Using SMIv2 MIB April 1999 o tn3270eSrvrConfInactivityTimout o tn3270eSrvrConfConnectivityChk o tn3270eSrvrConfActivityTimeout o tn3270eSrvrConfActivityInterval o tn3270eSrvrConfAdminStatus o tn3270eSrvrConfSessionTermState o tn3270eSrvrConfContact o tn3270eClientGroupSubnetMask o tn3270eResPoolElementType o tn3270eSrvrConfRowStatus o tn3270eSrvrPortRowStatus o tn3270eClientGroupRowStatus o tn3270eResPoolRowStatus o tn3270eResMapRowStatus For all tables in the MIB except the tn3270eTcpConnTable, the first index identifies an individual TN3270E server. This makes it easy to implement an access control policy under which different principals have access to objects related to different servers. Implementation of such a policy is not possible for the entries in the tn3270eTcpConTable. 6.0 Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. White & Moore Standards Track [Page 52] RFC 2561 TN3270E Using SMIv2 MIB April 1999 7.0 Acknowledgments This document is a product of the TN3270E Working Group. Thanks to Randy Presuhn of BMC Software for his valuable review comments on several versions of the document. 8.0 References [1] Harrington D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] 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. [6] 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. [7] 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. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. White & Moore Standards Track [Page 53] RFC 2561 TN3270E Using SMIv2 MIB April 1999 [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [17] Postel, J. and J. Reynolds, "Telnet Timing Mark Option", STD 31, RFC 860, May 1983. [18] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, January 1988. [19] Kelly, B., "TN3270 Enhancements", RFC 2355, June 1998. [20] McCloghrie, K., "TCP-MIB Definitions", RFC 2012, November 1996. [21] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [23] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [24] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. White & Moore Standards Track [Page 54] RFC 2561 TN3270E Using SMIv2 MIB April 1999 9.0 Authors' Addresses Kenneth D. White Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA EMail: kennethw@vnet.ibm.com Robert Moore Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA Phone: +1-919-254-4436 EMail: remoore@us.ibm.com White & Moore Standards Track [Page 55] RFC 2561 TN3270E Using SMIv2 MIB April 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. White & Moore Standards Track [Page 56] snmp-mibs-downloader-1.1/mibrfcs/rfc2562.txt0000644000000000000000000033005111402176071015562 0ustar Network Working Group K. White Request for Comments: 2562 IBM Corp. Category: Standards Track R. Moore IBM Corp. April 1999 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. The response time data collected by a TN3270E server is structured to support both validation of service level agreements and performance monitoring of TN3270 and TN3270E Sessions. This MIB has as a prerequisite the TN3270E-MIB, reference [20]. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices. Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . 2 3.0 Response Time Collection Methodology . . . . . . . . . . . 3 3.1 General Response Time Collection . . . . . . . . . . . . . 3 3.2 TN3270E Server Response Time Collection . . . . . . . . . 5 3.3 Correlating TN3270E Server and Host Response Times . . . . 10 3.4 Timestamp Calculation . . . . . . . . . . . . . . . . . . 11 3.4.1 DR Usage . . . . . . . . . . . . . . . . . . . . . . . 12 White & Moore Standards Track [Page 1] RFC 2562 TN3270E-RT-MIB April 1999 3.4.2 TIMING-MARK Usage . . . . . . . . . . . . . . . . . . 13 3.5 Performance Data Modelling . . . . . . . . . . . . . . . . 15 3.5.1 Averaging Response Times . . . . . . . . . . . . . . . 15 3.5.2 Response Time Buckets . . . . . . . . . . . . . . . . 18 4.0 Structure of the MIB . . . . . . . . . . . . . . . . . . . 19 4.1 tn3270eRtCollCtlTable . . . . . . . . . . . . . . . . . . 19 4.2 tn3270eRtDataTable . . . . . . . . . . . . . . . . . . . . 23 4.3 Notifications . . . . . . . . . . . . . . . . . . . . . . 24 4.4 Advisory Spin Lock Usage . . . . . . . . . . . . . . . . . 26 5.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 26 6.0 Security Considerations . . . . . . . . . . . . . . . . . 45 7.0 Intellectual Property . . . . . . . . . . . . . . . . . . 45 8.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 46 9.0 References . . . . . . . . . . . . . . . . . . . . . . . . 46 10.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . 48 11.0 Full Copyright Statement . . . . . . . . . . . . . . . . 49 1.0 Introduction This document is a product of the TN3270E Working Group. It defines a protocol and a MIB module to enable a TN3270E server to collect and keep track of response time data for both TN3270 and TN3270E clients. Basis for implementing this MIB: o TN3270E-MIB, Base Definitions of Managed Objects for TN3270E Using SMIv2 [20] o TN3270E RFCs o Telnet Timing Mark Option RFC [17]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [23]. 2.0 The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC White & Moore Standards Track [Page 2] RFC 2562 TN3270E-RT-MIB April 1999 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3.0 Response Time Collection Methodology This section explains the methodology and approach used by the MIB defined by this memo for response time data collection by a TN3270E server. 3.1 General Response Time Collection Two primary methods exist for measuring response times in SNA networks: o The Systems Network Architecture Management Services (SNA/MS) Response Time Monitoring (RTM) function. White & Moore Standards Track [Page 3] RFC 2562 TN3270E-RT-MIB April 1999 o Timestamping using definite response flows. This memo defines an approach using definite responses to timestamp the flows between a client and its TN3270E server, rather than by use of the RTM method. Extensions to the SNA/MS RTM flow were considered, but this approach was deemed unsuitable since not all TN3270E server implementations have access to their underlying SNA stacks. The RTM concepts of keeping response time buckets for service level agreements and of interval-based response time collection for performance monitoring are preserved in the MIB module defined in this memo. As mentioned, this memo focuses on using definite responses to timestamp the flows between a client and its TN3270E server for generating performance data. Use of a definite response flow requires that the client supports TN3270E with the RESPONSES function negotiated. The TN3270 TIMING-MARK option can be used instead of definite response for supporting TN3270 clients or TN3270E clients that don't support RESPONSES. This document focuses first on defining the protocol and methods for generating performance data using definite responses, and then describes how the TIMING-MARK option can be used instead of definite response. In an SNA network, a transaction between a client Logical Unit (LU) and a target host in general looks as follows: ------------------------------------------------ | | | Client LU Target SNA Host | | | | Timestamps | | request A | | -----------------------------------------> | | reply(DR) B | | | <---------------------------------------< | | | +/-RSP C | | >---------------------------------------> | | | | DR: Definite Response requested | | +/-RSP: Definite Response | | | ------------------------------------------------ This transaction is a simple one, and is being used only to illustrate how timestamping at a target SNA host can be used to generate response times. An IBM redbook [12] provides a more detailed description of response time collection for a transaction of this type. Note that for the purpose of calculating an approximation White & Moore Standards Track [Page 4] RFC 2562 TN3270E-RT-MIB April 1999 for network transit time, it doesn't matter if the response is positive or negative. Two response time values are typically calculated: o Host Transit Time: Timestamp B - Timestamp A o Network Transit Time: Timestamp C - Timestamp B Network transit time is an approximation for the amount of time that a transaction requires to flow across a network, since the response flow is being substituted for the request flow at the start of the transaction. Network transit time, timestamp C - timestamp B, is the amount of time that the definite response request and its response required. Host time, timestamp B - timestamp A, is the actual time that the host required to process the transaction. Experience has shown that using the response flow to approximate network transit times is useful, and does correlate well with actual network transit times. A client SHOULD respond to a definite response request when it completes processing the transaction. This is important since it increases the accuracy of a total response time. Clients that immediately respond to a definite response request will be attributed with lower total response times then those that actually occurred. The TN3270E-RT-MIB describes a method of collecting performance data that is not appropriate for printer (LU Type 1 or LU Type 3) sessions; thus collection of performance data for printer sessions is excluded from this MIB. This exclusion of printer sessions is not considered a problem, since these sessions are not the most important ones for response time monitoring, and since historically they were excluded from SNA/MS RTM collection. The tn3270eTcpConnResourceType object in a tn3270eTcpConnEntry (in the TN3270E-MIB) can be examined to determine if a client session is ineligible for response time data collection for this reason. 3.2 TN3270E Server Response Time Collection A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be. For ease of exposition this document uses the term "IP network" to refer to the client-side network, since IP is by far the most common protocol for these networks. A TN3270E server can use SNA definite responses and the TN3270 Enhancement (RFC 2355 [19]) RESPONSES function to calculate response times for a transaction, by timestamping when a client request White & Moore Standards Track [Page 5] RFC 2562 TN3270E-RT-MIB April 1999 arrives at the server, when the reply arrives from the target host, and when the response acknowledging this reply arrives from the client. Section 3.4, Timestamp Calculation, provides specifics on when in the sequence of flows between a TN3270E client and its target SNA host a TN3270E server takes the required timestamps. In addition, it provides information on how a TN3270 TIMING-MARK request/response flow can be used instead of DR for approximating IP network transit times. The following figure adds a TN3270E server between the client, in this case a TN3270E client and the target SNA host: ------------------------------------------------ | | | Client TN3270E Target | | Server SNA Host | | Timestamps | | | | <---IP Network-------><---SNA Network---> | | | | request D | | ------------------------------------------> | | reply(DR) E | | | <----------------------------------------< | | | +/-RSP F | | >-------------------- - - - - - - - - - > | | | ------------------------------------------------ A TN3270E server can save timestamp D when it receives a client request, save timestamp E when the target SNA host replies, and save timestamp F when the client responds to the definite response request that flowed with the reply. It doesn't matter whether the target SNA host requested a definite response on its reply: if it didn't, the TN3270E server makes the request on its own, to enable it to produce timestamp F. In this case the TN3270E server does not forward the response to the target SNA host, as the dotted line in the figure indicates. Because it is a special case, a transaction in which a target SNA host returns an UNBIND in response to a client's request, and the TN3270E server forwards the UNBIND to the client, is not included in any response time calculations. White & Moore Standards Track [Page 6] RFC 2562 TN3270E-RT-MIB April 1999 In order to generate timestamp F, a TN3270E server MUST insure that the transaction specifies DR, and that the TN3270E RESPONSES function has been negotiated between itself and the client. Negotiation of the TN3270E RESPONSES function occurs during the client's TN3270E session initialization. The TN3270E servers that the authors are aware of do request the RESPONSES function during client session initialization. TN3270E clients either automatically support the RESPONSES function, or can be configured during startup to support it. Using timestamps D, E, and F the following response times can be calculated by a TN3270E server: o Total Response time: Timestamp F - Timestamp D o IP Network Transit Time: Timestamp F - Timestamp E Just as in the SNA case presented above, these response times are also approximations, since the final +/- RSP from the client is being substituted for the request from the client that began the transaction. The MIB provides an object, tn3270eRtCollCtlType, to control several aspects of response time data collection. One of the available options in setting up a response time collection policy is to eliminate the IP-network component altogether. This might be done because it is determined either that the additional IP network traffic would not be desirable, or that the IP-network component of the overall response times is not significant. Excluding the IP-network component from response times also has an implication for the way in which response time data is aggregated. A TN3270E server may find that some of its clients simply don't support any of the functions necessary for the server to calculate the IP- network component of response times. For these clients, the most that the server can calculate is the SNA-network component of their overall response times; the server records this SNA-network component as the TOTAL response time each of these clients' transactions. If a response time collection is aggregating data from a number of clients, some of which have the support necessary for including the IP-network component in their total response time calculations, and some of which do not, then the server aggregates the data differently depending on whether the collection has been defined to include or exclude the IP-network component: o If the IP-network component is included, then transactions for the clients that don't support calculation of the IP-network component of their response times are excluded from the aggregation altogether. White & Moore Standards Track [Page 7] RFC 2562 TN3270E-RT-MIB April 1999 o If the IP-network component is excluded, then total response times for ALL clients include only the SNA-network component, even though the server could have included an IP-network component in the overall response times for some of these clients. The server does this by setting timestamp F, which marks the end of a transaction's total response time, equal to timestamp E, the end of the transaction's SNA-network component. The principle here is that all the transactions contributing their response times to an aggregated value MUST make the same contribution. If the aggregation specifies that an IP-network component MUST be included in the aggregation's response times, then transactions for which an IP-network component cannot be calculated aren't included at all. If the aggregation specifies that an IP- network component is not to be included, then only the SNA-network component is used, even for those transactions for which an IP- network component could have been calculated. There is one more complication here: the MIB allows a management application to enable or disable dynamic definite responses for a response time collection. Once again the purpose of this option is to give the network operator control over the amount of traffic introduced into the IP network for response time data collection. A DYNAMIC definite response is one that the TN3270E server itself adds to a reply, in a transaction for which the SNA application at the target SNA host did not specify DR in its reply. When the +/-RSP comes back from the client, the server uses this response to calculate timestamp F, but then it does not forward the response on to the SNA application (since the application is not expecting a response to its reply). The dynamic definite responses option is related to the option of including or excluding the IP-network component of response times (discussed above) as follows: o If the IP-network component is excluded, then there is no reason for enabling dynamic definite responses: the server always sets timestamp F equal to timestamp E, so the additional IP-network traffic elicited by a dynamic definite response would serve no purpose. o If the IP-network component is included, then enabling dynamic definite responses causes MORE transactions to be included in the aggregated response time values: - For clients that do not support sending of responses, timestamp F can never be calculated, and so their transactions are never included in the aggregate. White & Moore Standards Track [Page 8] RFC 2562 TN3270E-RT-MIB April 1999 - For clients that support sending of responses, timestamp F will always be calculated for transactions in which the host SNA application specifies DR in its reply, and so these transactions will always be included in the aggregate. - For clients that support sending of responses, having dynamic definite responses enabled for a collection results in the inclusion of additional transactions in the aggregate: specifically, those for which the host SNA application did not specify DR in its reply. A TN3270E server also has the option of substituting TIMING-MARK processing for definite responses in calculating the IP-network component of a transaction's response time. Once again, there is no reason for the server to do this if the collection has been set up to exclude the IP-network component altogether in computing response times. The MIB is structured to keep counts and averages for total response times (F - D) and their IP-network components (F - E). A management application can obviously calculate from these two values an average SNA-network component (E - D) for the response times. This SNA- network component includes the SNA node processing time at both the TN3270E server and at the target application. A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into an SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and System Definition (SYSDEF) requirements. If a host TN3270E server is in the same SNA host as the target application, then the SNA-network component of a transaction's response time will approximately equal the host transit time (B - A) described previously. A host TN3270E server implementation can, however, typically support the establishment of sessions to target applications in SNA hosts remote from itself. In this case the SNA- network component of the response time equals the actual SNA-network transit time plus two host transit times. White & Moore Standards Track [Page 9] RFC 2562 TN3270E-RT-MIB April 1999 3.3 Correlating TN3270E Server and Host Response Times It is possible that response time data is collected from TN3270E servers at the same time as a management application is monitoring the SNA sessions at a host. For example, a management application can be monitoring a secondary logical unit (SLU) while retrieving data from a TN3270E server. Consider the following figure: ------------------------------------------------ | | | Client TN3270E Target | | Server SNA Host | | Timestamps (PLU) | | (SLU) Timestamps| | <---IP Network-------><---SNA Network---> | | | | request D A | | ------------------------------------------> | | reply(DR) E B | | | <----------------------------------------< | | | +/-RSP F C | | >--------------------------------------> | | | ------------------------------------------------ The following response times are available: o Target SNA host transit time: Timestamp B - Timestamp A o Target SNA host network transit time: Timestamp C - Timestamp B o TN3270E server total response time: Timestamp F - Timestamp D o TN3270E server IP-network component: Timestamp F - Timestamp E The value added by the TN3270E server in this situation is its approximation of the IP-network component of the overall response time. The IP-network component can be subtracted from the total network transit time (which can be captured at an SSCP monitoring SNA traffic from/to the SLU) to see the actual SNA versus IP network transit times. The MIB defined by this memo does not specifically address correlation of the data it contains with response time data collected by direct monitoring of SNA resources: its focus is exclusively response time data collection from a TN3270E server perspective. It has, however, in conjunction with the TN3270E-MIB [10], been structured to provide the information necessary for correlation between TN3270E server-provided response time information and that gathered from directly monitoring SNA resources. White & Moore Standards Track [Page 10] RFC 2562 TN3270E-RT-MIB April 1999 A management application attempting to correlate SNA resource usage to Telnet clients can monitor either the tn3270eResMapTable or the tn3270eTcpConnTable to determine resource-to-client address mappings. Both of these tables are defined by the TN3270E-MIB [10]. Another helpful table is the tn3270eSnaMapTable, which provides a mapping between SLU names as they are known at the SSCP (VTAM) and their local names at the TN3270E server. Neither the tn3270eClientGroupTable, the tn3270eResPoolTable, nor the tn3270eClientResMapTable from the TN3270E-MIB can be used for correlation, since the mappings defined by these tables can overlap, and may not provide one-to-one mappings. 3.4 Timestamp Calculation This section goes into more detail concerning when the various timestamps can be taken as the flows between a TN3270E client and its target SNA host pass through a TN3270E server. In addition, information is provided on how the TN3270 TIMING-MARK request/response flow can be used in place of DR for approximating IP network transit times. White & Moore Standards Track [Page 11] RFC 2562 TN3270E-RT-MIB April 1999 3.4.1 DR Usage Consider the following flow: ---------------------------------------------------------- | | | Client TN3270E Target SNA | | Server Host | | Timestamps | | | | <---IP Network-------><---SNA Network---> | | | | request D (BB,CD,OIC,ER) | | -------------------------------------------> | | reply(DR) (FIC,ER,EB) | | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply E (LIC,DR) | | <-----------------------------------------< | | | +/-RSP F | | >----------------------------------------> | | | | BB : Begin Bracket ER : Response by exception | | EB : End Bracket DR : Definite Response Requested | | CD : Change Direction FIC : First in chain | | OIC: Only in chain MIC: Middle in chain | | LIC: Last in chain | ---------------------------------------------------------- Timestamp D is taken at the TN3270E server when the server has received data from a client for forwarding to its target SNA host, and the direction of the SNA session allows the server to forward the data immediately (either the direction is inbound towards the SNA host, or the session is between brackets). This is most likely when the server finds the end of record indicator in the TCP data received from the client. The target SNA application returns its reply in one or more SNA Request Units (RUs); in this example there are four RUs in the reply. The first RU is marked as first in chain (FIC), the next two are marked as middle in chain (MIC), and the last is marked as last in chain (LIC). If the SNA host sends a multiple-RU chain, the server does not know until the last RU is received whether DR is being requested. The server's only chance to request DR from the client, however, comes when it forwards the FIC RU, since this is the only White & Moore Standards Track [Page 12] RFC 2562 TN3270E-RT-MIB April 1999 time that the TN3270E header is included. Since a server may forward the FIC RU to the client before it receives the LIC RU from the SNA host, some servers routinely specify DR on all FIC RUs. If the server has specified DR on the TN3270E request for the FIC RU in a chain, it takes timestamp E when it forwards the LIC RU to the client. Since timestamp E is used for calculating the IP-network time for the transaction, the server SHOULD take timestamp E as close as possible to its "Telnet edge". The server takes timestamp F when it receives the RESPONSES response from the client. A target SNA application doesn't necessarily return data to a client in a transaction; it may, for example, require more data from the client before it can formulate a reply. In this case the application may simply return to the TN3270E server a change of direction indicator. At this point the server must send something to the client (typically a Write operation with a WCC) to unlock the keyboard. If the server specifies DR on the request to the client triggered by its receipt of the change of direction indicator from the SNA application, then timestamps E and F can be taken, and the usual response times can be calculated. When the client sends in the additional data and gets a textual response from the SNA application, the server treats this as a separate transaction from the one involving the change of direction. 3.4.2 TIMING-MARK Usage It is possible for a TN3270E server to use the TIMING-MARK flow for approximating IP network transit times. Using TIMING-MARKs would make it possible for a server to collect performance data for TN3270 clients, as well as for TN3270E clients that do not support the RESPONSES function. In order for TIMING-MARKs to be used in this way, a client can't have the NOP option enabled, since responses are needed to the server's TIMING-MARK requests. An IP network transit time approximation using a TIMING-MARK is basically the amount of time it takes for a TN3270 server to receive from a client a response to a TIMING-MARK request. To get an estimate for IP network transit time, a TN3270E server sends a TIMING-MARK request to a client after a LIC RU has been received, as a means of approximating IP network transit time: White & Moore Standards Track [Page 13] RFC 2562 TN3270E-RT-MIB April 1999 --------------------------------------------------- | | | Client TN3270E Target | | Server Host | | Timestamps | | | | <---IP Network-------><---SNA Network---> | | | | request D (BB,CD,OIC,ER) | | -------------------------------------------> | | reply (FIC,ER,EB) | | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply (MIC,ER) | | <-----------------------------------------< | | reply E (LIC,ER) | | <-----------------------------------------< | | TIMING-MARK Rqst E' | | <--------------------- | | | TIMING-MARK Rsp F' | | >-------------------> | | | --------------------------------------------------- The response times can then be calculated as follows: o TN3270E server total response time: (Timestamp E - Timestamp D) + (Timestamp F' - Timestamp E') o TN3270E server IP network time: Timestamp F' - Timestamp E' If a TN3270E server is performing the TIMING-MARK function (independent of the response time monitoring use of the function discussed here), then it most likely has a TIMING-MARK interval for determining when to examine client sessions for sending the TIMING- MARK request. This interval, which is ordinarily a global value for an entire TN3270E server, is represented in the TN3270E-MIB by the tn3270eSrvrConfTmNopInterval object. A TIMING-MARK request is sent only if, when it is examined, a client session is found to have had no activity for a different fixed length of time, represented in the TN3270E-MIB by the tn3270eSrvrConfTmNopInactTime object. Servers that support a large number of client sessions should spread out the TIMING-MARK requests they send to these clients over the activity interval, rather than sending them all in a single burst, since otherwise the network may be flooded with TIMING-MARK requests. When a server uses TIMING-MARKs for approximating response times, White & Moore Standards Track [Page 14] RFC 2562 TN3270E-RT-MIB April 1999 this tends to introduce a natural spreading into its TIMING-MARK requests, since the requests are triggered by the arrival of traffic from an SNA host. A TN3270E server MUST integrate its normal TIMING-MARK processing with its use of TIMING-MARKs for computing response times. In particular, it MUST NOT send a second TIMING-MARK request to a client while waiting for the first to return, since this is ruled out by the TIMING-MARK protocol itself. If a TIMING-MARK flow has just been performed for a client shortly before the LIC RU arrives, the server MAY use the interval from this flow as its approximation for IP network transit time, (in other words, as its (F' - E') value) when calculating its approximation for the transaction's total response time, rather than sending a second TIMING-MARK request so soon after the preceding one. Regardless of when the server sends its TIMING-MARK request, the accuracy of its total response time calculation depends on exactly when the client responds to the TIMING-MARK request. 3.5 Performance Data Modelling The following two subsections detail how the TN3270E-RT-MIB models and controls capture of two types of response time data: average response times and response time buckets. 3.5.1 Averaging Response Times Average response times play two different roles in the MIB: o They are made available for management applications to retrieve. o They serve as triggers for emitting notifications. Sliding-window averages are used rather than straight interval-based averages, because they are often more meaningful, and because they cause less notification thrashing. Sliding-window average calculation can, if necessary, be disabled, by setting the sample period multiplier, tn3270eRtCollCtlSPMult, to 1, and setting the sample period, tn3270eRtCollCtlSPeriod, to the required collection interval. In order to calculate sliding-window averages, a TN3270E server MUST: o Select a fixed, relatively short, sample period SPeriod; the default value for SPeriod in the MIB is 20 seconds. White & Moore Standards Track [Page 15] RFC 2562 TN3270E-RT-MIB April 1999 o Select an averaging period multiplier SPMult. The actual collection interval will then be SPMult times SPeriod. The default value for SPMult in the MIB is 30, yielding a default collection interval of 10 minutes. Note that the collection interval (SPMult*SPeriod) is always a multiple of the sample period. Clearlly, SPMult*SPeriod should not be thought of as literally the averaging period. The average calculated will include contributions older than that time, and does not weight equally all contributions since that time. In fact, it gives a smoother result than a traditional sliding average, as used in finance. More subtly, it is best to think of the effective averaging period as being 2*SPMult*SPeriod. To see this, consider how long the contribution to the result made by a particular transaction lasts. With a traditional sliding average, it lasts exactly the averaging period. With the aging mechanism described here, it has a half-life of SPMult*SPeriod. o Maintain the following counters to keep track of activity within the current sample period; these are internal counters, not made visible to a management application via the MIB. - T (number of transactions in the period) - TotalRts (sum of the total response times for all transactions in the period) - TotalIpRts (sum of the IP network transit times for all transactions in the period; note that if IP network transit times are being excluded from the response time collection, this value will always be 0). o Also maintain sliding counters, initialized to zero, for each of the quantities being counted: - AvgCountTrans (sliding count of transactions) - TotalRtsSliding (sliding count of total response times) - TotalIpRtsSliding (sliding count of IP network transit times) o At the end of each sample period, update the sliding interval counters, using the following floating-point calculations: AvgCountTrans = AvgCountTrans + T - (AvgCountTrans / SPMult) TotalRtsSliding = TotalRtsSliding + TotalRts - (TotalRtsSliding / SPMult) White & Moore Standards Track [Page 16] RFC 2562 TN3270E-RT-MIB April 1999 TotalIpRtsSliding = TotalIpRtsSliding + TotalIpRts - (TotalIpRtsSliding / SPMult) Then reset T, TotalRts, and TotalIpRts to zero for use during the next sample period. o At the end of a collection interval, update the following MIB objects as indicated; the floating-point numbers are rounded rather than truncated. tn3270eRtDataAvgCountTrans = AvgCountTrans tn3270eRtDataAvgRt = TotalRtsSliding / AvgCountTrans tn3270eRtDataAvgIpRt = TotalIpRtsSliding / AvgCountTrans As expected, if IP network transit times are being excluded from response time collection, then tn3270eRtDataAvgIpRt will always return 0. The sliding transaction counter AvgCountTrans is not used for updating the MIB object tn3270eRtDataCountTrans: this object is an ordinary SMI Counter32, which maintains a total count of transactions since its last discontinuity event. The sliding counters are used only for calculating averages. Two mechanisms are present in the MIB to inhibit the generation of an excessive number of notifications related to average response times. First, there are high and low thresholds for average response times. A tn3270eRtExceeded notification is generated the first time a statistically significant average response time is found to have exceeded the high threshold. (The test for statistical significance is described below.) After this, no other tn3270eRtExceeded notifications are generated until an average response time is found to have fallen below the low threshold. The other mechanism to limit notifications is the significance test for a high average response time. Intuitively, the significance of an average is directly related to the number of samples that go into it; so we might be inclined to use a rule such as "for the purpose of generating tn3270eRtExceeded notifications, ignore average response times based on fewer than 20 transactions in the sample period." In the case of response times, however, the number of transactions sampled in a fixed sampling period is tied to these transactions' response times. A few transactions with long response times can guarantee that there will not be many transactions in a sample, because these transactions "use up" the sampling time. Yet this case White & Moore Standards Track [Page 17] RFC 2562 TN3270E-RT-MIB April 1999 of a few transactions with very poor response times should obviously be classified as a problem, not as a statistical anomaly based on too small a sample. The solution is to make the significance level for a sample a function of the average response time. A value IdleCount is specified, which is used to qualify an sample as statistically significant. In order to determine at a collection interval whether to generate a tn3270eRtExceeded notification, a TN3270E server uses the following algorithm: if AvgCountTrans * ((AvgRt/ThreshHigh - 1) ** 2) >= IdleCount then generate the notification, where AvgRt is the value that would be returned by the object tn3270eRtDataAvgRt at the end of the interval, and the "**" notation indicates exponientiation. Two examples illustrate how this algorithm works. Suppose that IdleCount has been set to 20 transactions, and the high threshold to 200 msecs per transaction. If the average observed response time is 300 msecs, then a notification will be generated only if AvgCountTrans >= 80. If, however, the observed response time is 500 msecs, then a notification is generated if AvgCountTrans >= 9. There is no corresponding significance test for the tn3270eRtOkay notification: this notification is generated based on an average response time that falls below the low threshold, regardless of the sample size behind that average. 3.5.2 Response Time Buckets The MIB also supports collection of response time data into a set of five buckets. This data is suitable either for verification of service level agreements, or for monitoring by a management application to identify performance problems. The buckets provide counts of transactions whose total response times fall into a set of specified ranges. Like everything for a collection, the "total" response times collected in the buckets are governed by the specification of whether IP network transit times are to be included in the totals. Depending on how this option is specified, the response times being counted in the buckets will either be total response times (F - D), or only SNA network transit times (effectively E - D, because when it is excluding the IP-network component of transactions, a server makes timestamp F identical to timestamp E). White & Moore Standards Track [Page 18] RFC 2562 TN3270E-RT-MIB April 1999 Four bucket boundaries are specified for a response time collection, resulting in five buckets. The first response time bucket counts those transactions whose total response times were less than or equal to Boundary 1, the second bucket counts those whose response times were greater than Boundary 1 but less than or equal to Boundary 2, and so on. The fifth bucket is unbounded on the top, counting all transactions whose response times were greater than Boundary 4. The four bucket boundaries have default values of: 1 second, 2 seconds, 5 seconds, and 10 seconds, respectively. These values are the defaults in the 3174 controller's implementation of the SNA/MS RTM function, and are thought to be appropriate for this MIB as well. In SNA/MS the counter buckets were (by today's standards) relatively small, with a maximum value of 65,535. The bucket objects in the MIB are all Counter32's. The following figure represents the buckets pictorially: ---------------------------------------------- | | | Response Time Boundaries | | | | | | | | | | | | | | | | | | | | | | | no | | 0 B-1 B-2 B-3 B-4 bound| | | | | | | | | | |Bucket1|Bucket2|Bucket3|Bucket4|Bucket5| | | ----------------------------------------- | | | ---------------------------------------------- 4.0 Structure of the MIB The TN3270E-RT-MIB has the following components: o tn3270eRtCollCtlTable o tn3270eRtDataTable o Notifications o Advisory Spin Lock Usage 4.1 tn3270eRtCollCtlTable The tn3270eRtCollCtlTable is indexed by tn3270eSrvrConfIndex and tn3270eClientGroupName imported from the TN3270E-MIB. tn3270eSrvrConfIndex identifies within a host a particular TN3270E White & Moore Standards Track [Page 19] RFC 2562 TN3270E-RT-MIB April 1999 server. tn3270eClientGroupName identifies a collection of IP clients for which response time data is to be collected. The set of clients is defined using the tn3270eClientGroupTable from the TN3270E-MIB. A tn3270eRtCollCtlEntry contains the following objects: -------------------------------------------------- 1st Index | tn3270eSrvrConfIndex Unsigned32 | 2nd Index | tn3270eClientGroupName Utf8String | | tn3270eRtCollCtlType BITS | | tn3270eRtCollCtlSPeriod Unsigned32 | | tn3270eRtCollCtlSPMult Unsigned32 | | tn3270eRtCollCtlThreshHigh Unsigned32 | | tn3270eRtCollCtlThreshLow Unsigned32 | | tn3270eRtCollCtlIdleCount Unsigned32 | | tn3270eRtCollCtlBucketBndry1 Unsigned32 | | tn3270eRtCollCtlBucketBndry2 Unsigned32 | | tn3270eRtCollCtlBucketBndry3 Unsigned32 | | tn3270eRtCollCtlBucketBndry4 Unsigned32 | | tn3270eRtCollCtlRowStatus RowStatus | -------------------------------------------------- The tn3270eRtCollCtlType object controls the type(s) of response time collection that occur, the granularity of the collection, whether dynamic definite responses SHOULD be initiated, and whether notifications SHOULD be generated. This object is of BITS SYNTAX, and thus allows selection of multiple options. The BITS in the tn3270eRtCollCtlType object have the following meanings: o aggregate(0) - If this bit is set to 1, then data SHOULD be aggregated for the whole client group. In this case there will be only one row created for the collection in the tn3270eRtDataTable. The first two indexes for this row, tn3270eSrvrConfIndex and tn3270eClientGroupName, will have the same values as the indexes for the corresponding tn3270eRtCollCtlEntry. The third and fourth indexes of an aggregated tn3270eRtDataEntry have the values unknown(0) (tn3270eRtDataClientAddrType) and a zero-length octet string (tn3270eRtDataClientAddress). The fifth index, tn3270eRtDataClientPort, has the value 0. If this bit is set to 0, then a separate entry is created in the tn3270eRtDataTable from each member of the client group. In this case tn3270eRtDataClientAddress contains the client's actual IP White & Moore Standards Track [Page 20] RFC 2562 TN3270E-RT-MIB April 1999 Address, tn3270eRtDataClientAddrType indicates the address type, and tn3270eRtDataClientPort contains the number of the port the client is using for its TN3270/TN3270E session. o excludeIpComponent(1) - If this bit is set to 1, then the server SHOULD exclude the IP-network component from all the response times for this collection. If the target SNA application specifies DR in any of its replies, this DR will still be passed down to the client, and the client's response will still be forwarded to the application. But this response will play no role in the server's response time calculations. If this bit is set to 0, then the server includes in the collection only those transactions for which it can include an (approximate) IP-network component in the total response time for the transaction. This component MAY be derived from a "natural" DR (if the client supports the RESPONSES function), from a dynamic DR introduced by the server (if the client supports the RESPONSES function and the ddr(2) bit has been set to 1), or from TIMING-MARK processing (if the client supports TIMING-MARKs). If this bit is set to 1, then the ddr(2) bit is ignored, since there is no reason for the server to request additional responses from the client(s) in the group. o ddr(2) - If this bit is set to 1, then the server SHOULD, for those clients in the group that support the RESPONSES function, add a DR request to the FIC reply in each transaction, and use the client's subsequent response for calculating an (approximate) IP-network component to include in the transaction's total response times. If this bit is set to 0, then the server does not add a DR request that it was not otherwise going to add to any replies from the target SNA application. If the excludeIpComponent(1) bit is set to 1, then this bit is ignored by the server. o average(3) - If this bit is set to 1, then the server SHOULD calculate a sliding-window average for the collection, based on the parameters specified for the group. If this bit is set to 0, then an average is not calculated. In this case the tn3270eRtExceeded and tn3270eRtOkay notifications are not generated, even if the traps(5) bit is set to 1. White & Moore Standards Track [Page 21] RFC 2562 TN3270E-RT-MIB April 1999 o buckets(4) - If this bit is set to 1, then the server SHOULD create and increment response time buckets for the collection, based on the parameters specified for the group. If this bit is set to 0, then response time buckets are not created. o traps(5) - If this bit is set to 1, then a TN3270E Server is enabled to generate notifications pertaining to an tn3270eCollCtlEntry. tn3270CollStart and tn3270CollEnd generation is enabled simply by traps(5) being set to 1. tn3270eRtExceeded and tn3270eRtOkay generation enablement requires that average(3) be set to 1 in addition to the traps(5) requirement. If traps(5) is set to 0, then none of the notifications defined in this MIB are generated for a particular tn3270eRtCollCtlEntry. Either the average(3) or the buckets(4) bit MUST be set to 1 in order for response time data collection to occur; both bits MAY be set to 1. If the average(3) bit is set to 1, then the following objects have meaning, and are used to control the calculation of the averages, as well as the generation of the two notifications related to them: o tn3270eRtCollCtlSPeriod o tn3270eRtCollCtlSPMult o tn3270eRtCollCtlThreshHigh o tn3270eRtCollCtlThreshLow o tn3270eRtCollCtlIdleCount The previous objects' values are meaningless if the associated average(3) bit is not set to 1. If the buckets(4) bit is set to 1, then the following objects have meaning, and specify the bucket boundaries: o tn3270eRtCollCtlBucketBndry1 o tn3270eRtCollCtlBucketBndry2 o tn3270eRtCollCtlBucketBndry3 o tn3270eRtCollCtlBucketBndry4 The previous objects' values are meaningless if the associated buckets(4) bit is not set to 1. If an entry in the tn3270RtCollCtlTable has the value active(1) for its RowStatus, then an implementation SHALL NOT allow Set operations for any objects in the entry except: White & Moore Standards Track [Page 22] RFC 2562 TN3270E-RT-MIB April 1999 o tn3270eRtCollCtlThreshHigh o tn3270eRtCollCtlThreshLow o tn3270eRtCollCtlRowStatus 4.2 tn3270eRtDataTable Either a single entry or multiple entries are created in the tn3270eRtDataTable for each tn3270eRtCollCtlEntry, depending on whether tn3270eRtCollCtlType in the control entry has aggregate(0) selected. The contents of an entry in the tn3270eRtDataTable depend on the contents of the corresponding entry in the tn3270eRtCollCtlTable: as described above, some objects in the data entry return meaningful values only when the average(3) option is selected in the control entry, while others return meaningful values only when the buckets(4) option is selected. If both options are selected, then all the objects return meaningful values. When an object is not specified to return a meaningful value, an implementation may return any syntactically valid value in response to a Get operation. The following objects return meaningful values if and only if the average(3) option was selected in the corresponding tn3270eRtCollCtlEntry: o tn3270eRtDataAvgRt o tn3270eRtDataAvgIpRt o tn3270eRtDataAvgCountTrans o tn3270eRtDataIntTimeStamp o tn3270eRtDataTotalRts o tn3270eRtDataTotalIpRts o tn3270eRtDataCountTrans o tn3270eRtDataCountDrs o tn3270eRtDataElapsRndTrpSq o tn3270eRtDataElapsIpRtSq The first three objects in this list return values derived from the sliding-window average calculations described earlier. The time of the most recent sample for these calculations is returned in the tn3270eRtDataIntTimeStamp object. The next four objects are normal Counter32 objects, maintaining counts of total response time and total transactions. The last two objects return sum of the squares values, to enable variance calculations by a management application. The following objects return meaningful values if and only if the buckets(4) option was selected in the corresponding tn3270eRtCollCtlEntry: White & Moore Standards Track [Page 23] RFC 2562 TN3270E-RT-MIB April 1999 o tn3270eRtDataBucket1Rts o tn3270eRtDataBucket2Rts o tn3270eRtDataBucket3Rts o tn3270eRtDataBucket4Rts o tn3270eRtDataBucket5Rts A discontinuity object, tn3270eRtDataDiscontinuityTime, can be used by a management application to detect when the values of the counter objects in this table may have been reset, or otherwise experienced a discontinuity. A possible cause for such a discontinuity is the TN3270E server's being stopped or restarted. This object returns a meaningful value regardless of which collection control options were selected. An object, tn3270eRtDataRtMethod, identifies whether the IP Network Time was calculated using either the definite response or TIMING-MARK approach. When an entry is created in the tn3270eRtCollCtlTable with its tn3270eRtCollCtlType aggregate(0) bit set to 1, an entry is automatically created in the tn3270eRtDataTable; this entry's tn3270eRtDataClientAddress has the value of a zero-length octet string, its tn3270eRtDataClientAddrType has the value of unknown(0), and its tn3270eRtDataClientPort has the value 0. When an entry is created in the tn3270eRtCollCtlTable with its tn3270eRtCollCtlType aggregate(0) bit set to 0, a separate entry is created in the tn3270eRtDataTable for each member of the client group that currently has a session with the TN3270E server. Entries are subsequently created for clients that the TN3270E server determines to be members of the client group when these clients establish sessions with the server. Entries are also created when clients with existing sessions are added to the group. All entries associated with a tn3270eRtCollCtlEntry are deleted from the tn3270eRtDataTable when that entry is deleted from the tn3270eRtCollCtlTable. An entry for an individual client in a client group is deleted when its TCP connection terminates. Once it has been created, a client's entry in the tn3270eRtDataTable remains active as long as the collection's tn3270eRtCollCtlEntry exists, even if the client is removed from the client group for the tn3270eRtCollCtlEntry. 4.3 Notifications This MIB defines four notifications related to a tn3270eRtDataEntry. If the associated tn3270eRtCollCtlType object's traps(5) bit is set to 1, then the tn3270RtCollStart and tn3270RtCollEnd notifications White & Moore Standards Track [Page 24] RFC 2562 TN3270E-RT-MIB April 1999 are generated when, respsectively, the tn3270eRtDataEntry is created and deleted. If, in addition, this tn3270eRtCollCtlType object's average(3) bit is set to 1, then the the tn3270eRtExceeded and tn3270eRtOkay notifications are generated when the conditions they report occur. The following notifications are defined by this MIB: o tn3270eRtExceeded - The purpose of this notification is to signal that a performance problem has been detected. If average(3) response time data is being collected, then this notification is generated whenever (1) an average response time is first found, on a collection interval boundary, to have exceeded the high threshold tn3270eRtCollCtlThreshHigh specified for the client group, AND (2) the sample on which the average is based is determined to have been a significant one, via the significance algorithm described earlier. This notification is not generated again for a tn3270eRtDataEntry until an average response time falling below the low threshold tn3270eRtCollCtlThreshLow specified for the client group has occurred for the entry. o tn3270eRtOkay - The purpose of this notification is to signal that a previously reported performance problem has been resolved. If average(3) response time data is being collected, then this notification is generated whenever (1) a tn3270eRtExceeded notification has already been generated, AND (2) an average response time is first found, on a collection interval boundary, to have fallen below the low threshold tn3270eRtCollCtlThreshLow specified for the client group. This notification is not generated again for a tn3270eRtDataEntry until an average response time exceeding the high threshold tn3270eRtCollCtlThreshHigh specified for the client group has occurred for the entry. Taken together, the two preceding notifications serve to minimize the generation of an excessive number of traps in the case of an average response time that oscillates about its high threshold. o tn3270eRtCollStart - This notification is generated whenever data collection begins for a client group, or when a new tn3270eRtDataEntry becomes active. The primary purpose of this notification is signal to a management application that a new client TCP session has been established, and to provide the IP- to-resource mapping for the session. This notification is not critical when average(3) data collection is not being performed for the client group. White & Moore Standards Track [Page 25] RFC 2562 TN3270E-RT-MIB April 1999 o tn3270eRtCollEnd - This notification is generated whenever a data collection ends. For an aggregate collection, this occurs when the corresponding tn3270eRtCollCtlEntry is deleted. For an individual collection, this occurs either when the tn3270eRtCollCtlEntry is deleted, or when the client's TCP connection terminates. The purpose of this notification is to enable a management application to complete a monitoring function that it was performing, by returning final values for the collection's data objects. 4.4 Advisory Spin Lock Usage Within the TN3270E-RT-MIB, tn3270eRtSpinLock is defined as an advisory lock that allows cooperating TN3270E-RT-MIB applications to coordinate their use of the tn3270eRtCollCtlTable. When creating a new entry or altering an existing entry in the tn3270eRtCollCtlTable, an application SHOULD make use of tn3270eRtSpinLock to serialize application changes or additions. Since this is an advisory lock, its use by management applications SHALL NOT be enforced by agents. Agents MUST, however, implement the tn3270eRtSpinLock object. 5.0 Definitions TN3270E-RT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Unsigned32, Gauge32 FROM SNMPv2-SMI RowStatus, DateAndTime, TimeStamp, TestAndIncr FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF tn3270eSrvrConfIndex, tn3270eClientGroupName, tn3270eResMapElementType FROM TN3270E-MIB IANATn3270eAddrType, IANATn3270eAddress FROM IANATn3270eTC-MIB snanauMIB FROM SNA-NAU-MIB; tn3270eRtMIB MODULE-IDENTITY LAST-UPDATED "9807270000Z" -- July 27, 1998 ORGANIZATION "TN3270E Working Group" CONTACT-INFO "Kenneth White (kennethw@vnet.ibm.com) IBM Corp. - Dept. BRQA/Bldg. 501/G114 P.O. Box 12195 White & Moore Standards Track [Page 26] RFC 2562 TN3270E-RT-MIB April 1999 3039 Cornwallis RTP, NC 27709-2195 Robert Moore (remoore@us.ibm.com) IBM Corp. - Dept. BRQA/Bldg. 501/G114 P.O. Box 12195 3039 Cornwallis RTP, NC 27709-2195 (919) 254-4436" DESCRIPTION "This module defines a portion of the management information base (MIB) that enables monitoring of TN3270 and TN3270E clients' response times by a TN3270E server." REVISION "9807270000Z" -- July 27, 1998 DESCRIPTION "RFC nnnn (Proposed Standard)" -- RFC Editor to fill in ::= { snanauMIB 9 } -- snanauMIB ::= { mib-2 34 } -- Top level structure of the MIB tn3270eRtNotifications OBJECT IDENTIFIER ::= { tn3270eRtMIB 0 } tn3270eRtObjects OBJECT IDENTIFIER ::= { tn3270eRtMIB 1 } tn3270eRtConformance OBJECT IDENTIFIER ::= { tn3270eRtMIB 3 } -- MIB Objects -- Response Time Control Table tn3270eRtCollCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eRtCollCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The response time monitoring collection control table, which allows a management application to control the types of response time data being collected, and the clients for which it is being collected. This table is indexed by tn3270eSrvrConfIndex and tn3270eClientGroupName imported from the TN3270E-MIB. tn3270eSrvrConfIndex indicates within a host which TN3270E server an entry applies to. tn3270eClientGroupName it identifies the set of IP clients for which response time data is being collected. The particular IP clients making up the set are identified in the tn3270eClientGroupTable in the TN3270E-MIB." White & Moore Standards Track [Page 27] RFC 2562 TN3270E-RT-MIB April 1999 ::= { tn3270eRtObjects 1} tn3270eRtCollCtlEntry OBJECT-TYPE SYNTAX Tn3270eRtCollCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the TN3270E response time monitoring collection control table. To handle the case of multiple TN3270E servers on the same host, the first index of this table is the tn3270eSrvrConfIndex from the TN3270E-MIB." INDEX { tn3270eSrvrConfIndex, -- Server's index tn3270eClientGroupName } -- What to collect on ::= { tn3270eRtCollCtlTable 1 } Tn3270eRtCollCtlEntry ::= SEQUENCE { tn3270eRtCollCtlType BITS, tn3270eRtCollCtlSPeriod Unsigned32, tn3270eRtCollCtlSPMult Unsigned32, tn3270eRtCollCtlThreshHigh Unsigned32, tn3270eRtCollCtlThreshLow Unsigned32, tn3270eRtCollCtlIdleCount Unsigned32, tn3270eRtCollCtlBucketBndry1 Unsigned32, tn3270eRtCollCtlBucketBndry2 Unsigned32, tn3270eRtCollCtlBucketBndry3 Unsigned32, tn3270eRtCollCtlBucketBndry4 Unsigned32, tn3270eRtCollCtlRowStatus RowStatus } -- The OID { tn3270eRtCollCtlEntry 1 } is not used tn3270eRtCollCtlType OBJECT-TYPE SYNTAX BITS { aggregate(0), excludeIpComponent(1), ddr(2), average(3), buckets(4), traps(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls what types of response time data to collect, whether to summarize the data across the members of a client group or keep it individually, whether to introduce dynamic definite responses, and whether to generate traps. White & Moore Standards Track [Page 28] RFC 2562 TN3270E-RT-MIB April 1999 aggregate(0) - Aggregate response time data for the client group as a whole. If this bit is set to 0, then maintain response time data separately for each member of the client group. excludeIpComponent(1) - Do not include the IP-network component in any response times. ddr(2) - Enable dynamic definite response. average(3) - Produce an average response time based on a specified collection interval. buckets(4) - Maintain tn3270eRtDataBucket values in a corresponding tn3270eRtDataEntry, based on the bucket boundaries specified in the tn3270eRtCollCtlBucketBndry objects . traps(5) - generate the notifications specified in this MIB module. The tn3270eRtExceeded and tn3270eRtOkay notifications are generated only if average(3) is also specified." ::= { tn3270eRtCollCtlEntry 2 } tn3270eRtCollCtlSPeriod OBJECT-TYPE SYNTAX Unsigned32 (15..86400) -- 15 second min, 24 hour max UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that defines the sample period. The actual interval is defined as tn3270eRtCollCtlSPeriod times tn3270eRtCollCtlSPMult. The value of this object is used only if the corresponding tn3270eRtCollCtlType has the average(3) setting." DEFVAL {20} -- 20 seconds ::= { tn3270eRtCollCtlEntry 3 } tn3270eRtCollCtlSPMult OBJECT-TYPE SYNTAX Unsigned32 (1..5760) -- 5760 x SPeriod of 15 is 24 hours UNITS "period" MAX-ACCESS read-create STATUS current DESCRIPTION "The sample period multiplier; this value is multiplied by the sample period, tn3270eRtCollCtlSPeriod, to determine the collection interval. White & Moore Standards Track [Page 29] RFC 2562 TN3270E-RT-MIB April 1999 Sliding-window average calculation can, if necessary, be disabled, by setting the sample period multiplier, tn3270eRtCollCtlSPMult, to 1, and setting the sample period, tn3270eRtCollCtlSPeriod, to the required collection interval. The value of this object is used only if the corresponding tn3270eRtCollCtlType has the average(3) setting." DEFVAL { 30 } -- yields an interval of 10 minutes when -- used with the default SPeriod value ::= { tn3270eRtCollCtlEntry 4 } tn3270eRtCollCtlThreshHigh OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a tn3270eRtExceeded notification, signalling that a monitored total response time has exceeded the specified limit. A value of zero for this object suppresses generation of this notification. The value of this object is used only if the corresponding tn3270eRtCollCtlType has average(3) and traps(5) selected. A tn3270eRtExceeded notification is not generated again for a tn3270eRtDataEntry until an average response time falling below the low threshold tn3270eRtCollCtlThreshLow specified for the client group has occurred for the entry." DEFVAL { 0 } -- suppress notifications ::= { tn3270eRtCollCtlEntry 5 } tn3270eRtCollCtlThreshLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a tn3270eRtOkay notification, signalling that a monitored total response time has fallen below the specified limit. A value of zero for this object suppresses generation of this notification. The value of this object is used only if the corresponding tn3270eRtCollCtlType has average(3) and traps(5) selected. A tn3270eRtOkay notification is not generated again for a tn3270eRtDataEntry until an average response time White & Moore Standards Track [Page 30] RFC 2562 TN3270E-RT-MIB April 1999 exceeding the high threshold tn3270eRtCollCtlThreshHigh specified for the client group has occurred for the entry." DEFVAL { 0 } -- suppress notifications ::= { tn3270eRtCollCtlEntry 6 } tn3270eRtCollCtlIdleCount OBJECT-TYPE SYNTAX Unsigned32 UNITS "transactions" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is used to determine whether a sample that yields an average response time exceeding the value of tn3270eRtCollCtlThreshHigh was a statistically valid one. If the following statement is true, then the sample was statistically valid, and so a tn3270eRtExceeded notification should be generated: AvgCountTrans * ((AvgRt/ThreshHigh - 1) ** 2) >= IdleCount This comparison is done only if the corresponding tn3270eRtCollCtlType has average(3) and traps(5) selected." DEFVAL { 1 } ::= { tn3270eRtCollCtlEntry 7 } tn3270eRtCollCtlBucketBndry1 OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object defines the range of transaction response times counted in the Tn3270eRtDataBucket1Rts object: those less than or equal to this value." DEFVAL { 10 } ::= { tn3270eRtCollCtlEntry 8 } tn3270eRtCollCtlBucketBndry2 OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object, together with that of the tn3270eRtCollCtlBucketBndry1 object, defines the range of transaction response times counted in the Tn3270eRtDataBucket2Rts object: those greater than the value of the tn3270eRtCollCtlBucketBndry1 object, and White & Moore Standards Track [Page 31] RFC 2562 TN3270E-RT-MIB April 1999 less than or equal to the value of this object." DEFVAL { 20 } ::= { tn3270eRtCollCtlEntry 9 } tn3270eRtCollCtlBucketBndry3 OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object, together with that of the tn3270eRtCollCtlBucketBndry2 object, defines the range of transaction response times counted in the Tn3270eRtDataBucket3Rts object: those greater than the value of the tn3270eRtCollCtlBucketBndry2 object, and less than or equal to the value of this object." DEFVAL { 50 } ::= { tn3270eRtCollCtlEntry 10 } tn3270eRtCollCtlBucketBndry4 OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object, together with that of the tn3270eRtCollCtlBucketBndry3 object, defines the range of transaction response times counted in the Tn3270eRtDataBucket4Rts object: those greater than the value of the tn3270eRtCollCtlBucketBndry3 object, and less than or equal to the value of this object. The value of this object also defines the range of transaction response times counted in the Tn3270eRtDataBucket5Rts object: those greater than the value of this object." DEFVAL { 100 } ::= { tn3270eRtCollCtlEntry 11 } tn3270eRtCollCtlRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the tn3270eRtCollCtlTable. An entry in this table is deleted by setting this object to destroy(6). Deleting an entry in this table has the side-effect White & Moore Standards Track [Page 32] RFC 2562 TN3270E-RT-MIB April 1999 of removing all entries from the tn3270eRtDataTable that are associated with the entry being deleted." ::= { tn3270eRtCollCtlEntry 12 } -- TN3270E Response Time Data Table tn3270eRtDataTable OBJECT-TYPE SYNTAX SEQUENCE OF Tn3270eRtDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The response time data table. Entries in this table are created based on entries in the tn3270eRtCollCtlTable." ::= { tn3270eRtObjects 2 } tn3270eRtDataEntry OBJECT-TYPE SYNTAX Tn3270eRtDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created based upon the tn3270eRtCollCtlTable. When the corresponding tn3270eRtCollCtlType has aggregate(0) specified, a single entry is created in this table, with a tn3270eRtDataClientAddrType of unknown(0), a zero-length octet string value for tn3270eRtDataClientAddress, and a tn3270eRtDataClientPort value of 0. When aggregate(0) is not specified, a separate entry is created for each client in the group. Note that the following objects defined within an entry in this table can wrap: tn3270eRtDataTotalRts tn3270eRtDataTotalIpRts tn3270eRtDataCountTrans tn3270eRtDataCountDrs tn3270eRtDataElapsRnTrpSq tn3270eRtDataElapsIpRtSq tn3270eRtDataBucket1Rts tn3270eRtDataBucket2Rts tn3270eRtDataBucket3Rts tn3270eRtDataBucket4Rts tn3270eRtDataBucket5Rts" INDEX { tn3270eSrvrConfIndex, -- Server's local index tn3270eClientGroupName, -- Collection target tn3270eRtDataClientAddrType, tn3270eRtDataClientAddress, White & Moore Standards Track [Page 33] RFC 2562 TN3270E-RT-MIB April 1999 tn3270eRtDataClientPort } ::= { tn3270eRtDataTable 1 } Tn3270eRtDataEntry ::= SEQUENCE { tn3270eRtDataClientAddrType IANATn3270eAddrType, tn3270eRtDataClientAddress IANATn3270eAddress, tn3270eRtDataClientPort Unsigned32, tn3270eRtDataAvgRt Gauge32, tn3270eRtDataAvgIpRt Gauge32, tn3270eRtDataAvgCountTrans Gauge32, tn3270eRtDataIntTimeStamp DateAndTime, tn3270eRtDataTotalRts Counter32, tn3270eRtDataTotalIpRts Counter32, tn3270eRtDataCountTrans Counter32, tn3270eRtDataCountDrs Counter32, tn3270eRtDataElapsRndTrpSq Unsigned32, tn3270eRtDataElapsIpRtSq Unsigned32, tn3270eRtDataBucket1Rts Counter32, tn3270eRtDataBucket2Rts Counter32, tn3270eRtDataBucket3Rts Counter32, tn3270eRtDataBucket4Rts Counter32, tn3270eRtDataBucket5Rts Counter32, tn3270eRtDataRtMethod INTEGER, tn3270eRtDataDiscontinuityTime TimeStamp } tn3270eRtDataClientAddrType OBJECT-TYPE SYNTAX IANATn3270eAddrType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the type of address represented by the value of tn3270eRtDataClientAddress. The value unknown(0) is used if aggregate data is being collected for the client group." ::= { tn3270eRtDataEntry 1 } tn3270eRtDataClientAddress OBJECT-TYPE SYNTAX IANATn3270eAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the IP address of the TN3270 client being monitored. A zero-length octet string is used if aggregate data is being collected for the client group." ::= { tn3270eRtDataEntry 2 } tn3270eRtDataClientPort OBJECT-TYPE White & Moore Standards Track [Page 34] RFC 2562 TN3270E-RT-MIB April 1999 SYNTAX Unsigned32(0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the client port number of the TN3270 client being monitored. The value 0 is used if aggregate data is being collected for the client group, or if the tn3270eRtDataClientAddrType identifies an address type that does not support ports." ::= { tn3270eRtDataEntry 3 } tn3270eRtDataAvgRt OBJECT-TYPE SYNTAX Gauge32 UNITS "tenths of seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The average total response time measured over the last collection interval." DEFVAL { 0 } ::= { tn3270eRtDataEntry 4 } tn3270eRtDataAvgIpRt OBJECT-TYPE SYNTAX Gauge32 UNITS "tenths of seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The average IP response time measured over the last collection interval." DEFVAL { 0 } ::= { tn3270eRtDataEntry 5 } tn3270eRtDataAvgCountTrans OBJECT-TYPE SYNTAX Gauge32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "The sliding transaction count used for calculating the values of the tn3270eRtDataAvgRt and tn3270eRtDataAvgIpRt objects. The actual transaction count is available in the tn3270eRtDataCountTrans object. The initial value of this object, before any averages have been calculated, is 0." ::= { tn3270eRtDataEntry 6 } White & Moore Standards Track [Page 35] RFC 2562 TN3270E-RT-MIB April 1999 tn3270eRtDataIntTimeStamp OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time of the last interval that tn3270eRtDataAvgRt, tn3270eRtDataAvgIpRt, and tn3270eRtDataAvgCountTrans were calculated. Prior to the calculation of the first interval averages, this object returns the value 0x0000000000000000000000. When this value is returned, the remaining objects in the entry have no significance." ::= { tn3270eRtDataEntry 7 } tn3270eRtDataTotalRts OBJECT-TYPE SYNTAX Counter32 UNITS "tenths of seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the total response times collected. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 8 } tn3270eRtDataTotalIpRts OBJECT-TYPE SYNTAX Counter32 UNITS "tenths of seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the total IP-network response times collected. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 9 } tn3270eRtDataCountTrans OBJECT-TYPE SYNTAX Counter32 UNITS "transactions" MAX-ACCESS read-only STATUS current White & Moore Standards Track [Page 36] RFC 2562 TN3270E-RT-MIB April 1999 DESCRIPTION "The count of the total number of transactions detected. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 10 } tn3270eRtDataCountDrs OBJECT-TYPE SYNTAX Counter32 UNITS "definite responses" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the total number of definite responses detected. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 11 } tn3270eRtDataElapsRndTrpSq OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of seconds squared" MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of the elapsed round trip time squared. The sum of the squares is kept in order to enable calculation of a variance." DEFVAL { 0 } ::= { tn3270eRtDataEntry 12 } tn3270eRtDataElapsIpRtSq OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of seconds squared" MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of the elapsed IP round trip time squared. The sum of the squares is kept in order to enable calculation of a variance." DEFVAL { 0 } ::= { tn3270eRtDataEntry 13 } tn3270eRtDataBucket1Rts OBJECT-TYPE SYNTAX Counter32 White & Moore Standards Track [Page 37] RFC 2562 TN3270E-RT-MIB April 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the response times falling into bucket 1. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 14 } tn3270eRtDataBucket2Rts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the response times falling into bucket 2. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 15 } tn3270eRtDataBucket3Rts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the response times falling into bucket 3. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 16 } tn3270eRtDataBucket4Rts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the response times falling into bucket 4. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 17 } tn3270eRtDataBucket5Rts OBJECT-TYPE SYNTAX Counter32 White & Moore Standards Track [Page 38] RFC 2562 TN3270E-RT-MIB April 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the response times falling into bucket 5. A management application can detect discontinuities in this counter by monitoring the tn3270eRtDataDiscontinuityTime object." ::= { tn3270eRtDataEntry 18 } tn3270eRtDataRtMethod OBJECT-TYPE SYNTAX INTEGER { none(0), responses(1), timingMark(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the method that was used in calculating the IP network time. The value 'none(0) indicates that response times were not calculated for the IP network." ::= { tn3270eRtDataEntry 19 } tn3270eRtDataDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which one or more of this entry's counter objects suffered a discontinuity. This may happen if a TN3270E server is stopped and then restarted, and local methods are used to set up collection policy (tn3270eRtCollCtlTable entries)." ::= { tn3270eRtDataEntry 20 } tn3270eRtSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating TN3270E-RT-MIB applications to coordinate their use of the tn3270eRtCollCtlTable. White & Moore Standards Track [Page 39] RFC 2562 TN3270E-RT-MIB April 1999 When creating a new entry or altering an existing entry in the tn3270eRtCollCtlTable, an application should make use of tn3270eRtSpinLock to serialize application changes or additions. Since this is an advisory lock, the use of this lock is not enforced." ::= { tn3270eRtObjects 3 } -- Notifications tn3270eRtExceeded NOTIFICATION-TYPE OBJECTS { tn3270eRtDataIntTimeStamp, tn3270eRtDataAvgRt, tn3270eRtDataAvgIpRt, tn3270eRtDataAvgCountTrans, tn3270eRtDataRtMethod } STATUS current DESCRIPTION "This notification is generated when the average response time, tn3270eRtDataAvgRt, exceeds tn3270eRtCollCtlThresholdHigh at the end of a collection interval specified by tn3270eCollCtlSPeriod times tn3270eCollCtlSPMult. Note that the corresponding tn3270eCollCtlType must have traps(5) and average(3) set for this notification to be generated. In addition, tn3270eRtDataAvgCountTrans, tn3270eRtCollCtlThreshHigh, and tn3270eRtDataAvgRt are algorithmically compared to tn3270eRtCollCtlIdleCount for determination if this notification will be suppressed." ::= { tn3270eRtNotifications 1 } tn3270eRtOkay NOTIFICATION-TYPE OBJECTS { tn3270eRtDataIntTimeStamp, tn3270eRtDataAvgRt, tn3270eRtDataAvgIpRt, tn3270eRtDataAvgCountTrans, tn3270eRtDataRtMethod } STATUS current DESCRIPTION "This notification is generated when the average response time, tn3270eRtDataAvgRt, falls below tn3270eRtCollCtlThresholdLow at the end of a collection interval specified by tn3270eCollCtlSPeriod times White & Moore Standards Track [Page 40] RFC 2562 TN3270E-RT-MIB April 1999 tn3270eCollCtlSPMult, after a tn3270eRtExceeded notification was generated. Note that the corresponding tn3270eCollCtlType must have traps(5) and average(3) set for this notification to be generated." ::= { tn3270eRtNotifications 2 } tn3270eRtCollStart NOTIFICATION-TYPE OBJECTS { tn3270eRtDataRtMethod, -- type of collection tn3270eResMapElementType -- type of resource } STATUS current DESCRIPTION "This notification is generated when response time data collection is enabled for a member of a client group. In order for this notification to occur the corresponding tn3270eRtCollCtlType must have traps(5) selected. tn3270eResMapElementType contains a valid value only if tn3270eRtDataClientAddress contains a valid address (rather than a zero-length octet string)." ::= { tn3270eRtNotifications 3 } tn3270eRtCollEnd NOTIFICATION-TYPE OBJECTS { tn3270eRtDataDiscontinuityTime, tn3270eRtDataAvgRt, tn3270eRtDataAvgIpRt, tn3270eRtDataAvgCountTrans, tn3270eRtDataIntTimeStamp, tn3270eRtDataTotalRts, tn3270eRtDataTotalIpRts, tn3270eRtDataCountTrans, tn3270eRtDataCountDrs, tn3270eRtDataElapsRndTrpSq, tn3270eRtDataElapsIpRtSq, tn3270eRtDataBucket1Rts, tn3270eRtDataBucket2Rts, tn3270eRtDataBucket3Rts, tn3270eRtDataBucket4Rts, tn3270eRtDataBucket5Rts, tn3270eRtDataRtMethod } STATUS current DESCRIPTION "This notification is generated when an tn3270eRtDataEntry is deleted after being active (actual data collected), in order to enable a management application monitoring an White & Moore Standards Track [Page 41] RFC 2562 TN3270E-RT-MIB April 1999 tn3270eRtDataEntry to get the entry's final values. Note that the corresponding tn3270eCollCtlType must have traps(5) set for this notification to be generated." ::= { tn3270eRtNotifications 4 } -- Conformance Statement tn3270eRtGroups OBJECT IDENTIFIER ::= { tn3270eRtConformance 1 } tn3270eRtCompliances OBJECT IDENTIFIER ::= { tn3270eRtConformance 2 } -- Compliance statements tn3270eRtCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the TN327E-RT-MIB." MODULE -- this module MANDATORY-GROUPS { tn3270eRtGroup, tn3270eRtNotGroup } OBJECT tn3270eRtCollCtlType MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlSPeriod MIN-ACCESS read-only DESCRIPTION "The agent is not required to allow the user to change the default value of this object, and is allowed to use a different default." OBJECT tn3270eRtCollCtlSPMult MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlThreshHigh MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlThreshLow MIN-ACCESS read-only DESCRIPTION White & Moore Standards Track [Page 42] RFC 2562 TN3270E-RT-MIB April 1999 "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlIdleCount MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlBucketBndry1 MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlBucketBndry2 MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlBucketBndry3 MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlBucketBndry4 MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a SET operation to this object in the absence of adequate security." OBJECT tn3270eRtCollCtlRowStatus SYNTAX INTEGER { active(1) -- subset of RowStatus } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." ::= {tn3270eRtCompliances 1 } -- Group definitions tn3270eRtGroup OBJECT-GROUP White & Moore Standards Track [Page 43] RFC 2562 TN3270E-RT-MIB April 1999 OBJECTS { tn3270eRtCollCtlType, tn3270eRtCollCtlSPeriod, tn3270eRtCollCtlSPMult, tn3270eRtCollCtlThreshHigh, tn3270eRtCollCtlThreshLow, tn3270eRtCollCtlIdleCount, tn3270eRtCollCtlBucketBndry1, tn3270eRtCollCtlBucketBndry2, tn3270eRtCollCtlBucketBndry3, tn3270eRtCollCtlBucketBndry4, tn3270eRtCollCtlRowStatus, tn3270eRtDataDiscontinuityTime, tn3270eRtDataAvgRt, tn3270eRtDataAvgIpRt, tn3270eRtDataAvgCountTrans, tn3270eRtDataIntTimeStamp, tn3270eRtDataTotalRts, tn3270eRtDataTotalIpRts, tn3270eRtDataCountTrans, tn3270eRtDataCountDrs, tn3270eRtDataElapsRndTrpSq, tn3270eRtDataElapsIpRtSq, tn3270eRtDataBucket1Rts, tn3270eRtDataBucket2Rts, tn3270eRtDataBucket3Rts, tn3270eRtDataBucket4Rts, tn3270eRtDataBucket5Rts, tn3270eRtDataRtMethod, tn3270eRtSpinLock } STATUS current DESCRIPTION "This group is mandatory for all implementations that support the TN3270E-RT-MIB. " ::= { tn3270eRtGroups 1 } tn3270eRtNotGroup NOTIFICATION-GROUP NOTIFICATIONS { tn3270eRtExceeded, tn3270eRtOkay, tn3270eRtCollStart, tn3270eRtCollEnd } White & Moore Standards Track [Page 44] RFC 2562 TN3270E-RT-MIB April 1999 STATUS current DESCRIPTION "The notifications that must be supported when the TN3270E-RT-MIB is implemented. " ::= { tn3270eRtGroups 2 } END 6.0 Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. An authentication protocol is defined in [12]. A protocol for access control is defined in [15]. Several objects in this MIB allow write access or provide for row creation. Allowing this support in a non-secure environment can have a negative effect on network operations. It is RECOMMENDED that implementers seriously consider whether set operations or row creation SHOULD be allowed without providing, at a minimum, authentication of request origin. It is RECOMMENDED that without such support that the following objects be implemented as read-only: o tn3270eRtCollCtlType o tn3270eRtCollCtlSPeriod o tn3270eRtCollCtlSPMult o tn3270eRtCollCtlThreshHigh o tn3270eRtCollCtlThreshLow o tn3270eRtCollCtlIdleCount o tn3270eRtCollCtlBucketBndry1 o tn3270eRtCollCtlBucketBndry2 o tn3270eRtCollCtlBucketBndry3 o tn3270eRtCollCtlBucketBndry4 o tn3270eRtCollCtlRowStatus The administrative method to use to create and manage the tn3270eRtCollCtlTable when SET support is not allowed is outside of the scope of this memo. 7.0 Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights White & Moore Standards Track [Page 45] RFC 2562 TN3270E-RT-MIB April 1999 might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8.0 Acknowledgments This document is a product of the TN3270E Working Group. Special thanks are due to Derek Bolton and Michael Boe of Cisco Systems for their numerous comments and suggestions for improving the structure of this MIB. Thanks also to Randy Presuhn of BMC Software for his valuable review comments on several versions of the document. 9.0 References [1] Harrington D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] 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. [6] 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. White & Moore Standards Track [Page 46] RFC 2562 TN3270E-RT-MIB April 1999 [7] 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. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [17] Postel, J. and J. Reynolds, "Telnet Timing Mark Option", STD 31, RFC 860, May 1983. [18] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, January 1988. [19] Kelly, B., "TN3270 Enhancements", RFC 2355, June 1998. [20] White, K. and R. Moore, "Base Definitions of Managed Objects for TN3270E Using SMIv2", RFC 2561, April 1999. White & Moore Standards Track [Page 47] RFC 2562 TN3270E-RT-MIB April 1999 [21] IBM, International Technical Support Centers, "Response Time Data Gathering", GG24-3212-01, November 1990. [22] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [23] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.0 Authors' Addresses Kenneth D. White Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA EMail: kennethw@vnet.ibm.com Robert Moore Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA Phone: +1-919-254-7507 EMail: remoore@us.ibm.com White & Moore Standards Track [Page 48] RFC 2562 TN3270E-RT-MIB April 1999 11.0 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. White & Moore Standards Track [Page 49] snmp-mibs-downloader-1.1/mibrfcs/rfc2564.txt0000644000000000000000000054602211402176071015573 0ustar Network Working Group C. Kalbfleisch Request for Comments: 2564 Verio, Inc. Category: Standards Track C. Krupczak Empire Technologies, Inc. R. Presuhn BMC Software, Inc. J. Saperia IronBridge Networks May 1999 Application Management MIB 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the System Application MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed. Table of Contents 1. Introduction and Overview ................................... 2 2. The SNMP Management Framework ............................... 4 3. Architecture ................................................ 5 3.1. Relationships to other MIBs ............................... 5 3.1.1. Relationship to the System Application MIB .............. 5 3.1.2. Relationship to the Host Resources MIB .................. 6 3.1.3. Relationship to NSM ..................................... 6 4. MIB Structure ............................................... 6 4.1. The service-level tables .................................. 8 4.1.1. The service name to service instance table .............. 8 4.1.2. The service instance to service name table .............. 9 4.1.3. The service instance to running application element table 9 4.1.4. The running application element to service instance table 9 Kalbfleisch, et al. Standards Track [Page 1] RFC 2564 Application Management MIB May 1999 4.2. The I/O channel group ..................................... 9 4.2.1. The open channels table ................................. 10 4.2.2. The open files table .................................... 10 4.2.3. The open connections table .............................. 11 4.2.4. The transaction stream summary table .................... 12 4.2.5. The transaction flow statistics table ................... 13 4.2.6. The transaction kind statistics table ................... 13 4.3. The former channel group .................................. 13 4.3.1. The former channel control table ........................ 14 4.3.2. The former channel table ................................ 14 4.3.3. The former connection table ............................. 14 4.3.4. The former file table ................................... 14 4.3.5. The transaction history tables .......................... 14 4.4. The running element status and control group .............. 15 4.4.1. The running application element status table ............ 15 4.4.2. The running application element control table ........... 15 5. Definitions ................................................. 16 6. Implementation Issues ....................................... 80 7. Intellectual Property ....................................... 80 8. Acknowledgements ............................................ 81 9. Security Considerations ..................................... 81 10. References ................................................. 82 11. Authors' Addresses ......................................... 84 12. Full Copyright Statement ................................... 86 1. Introduction and Overview This document furthers the work begun in the systems application MIB [31]. The development of the "Host Resources MIB" [10], "Network Services Monitoring MIB" [23], "Mail Monitoring MIB" [24], "Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2" [12], "Entity MIB using SMIv2" [20], and "Applicability of Standards Track MIBs to Management of World Wide Web Servers" [21] provides us with a base of experience in making a variety of applications visible to management; this specification abstracts out the common aspects of applications management and provides a generic base usable for the management of almost any application. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [22]. Due to the design decision to not require application instrumentation, many important topics were not handled in system application MIB [31]. The following topics are within the scope of this document: Kalbfleisch, et al. Standards Track [Page 2] RFC 2564 Application Management MIB May 1999 - Support for generic application throughput measurements; - Providing MIB definitions that allow managed entities to report what they considered to be units of work; - Providing support for generic application response time monitoring capabilities; (Note that APIs for this purpose have already been developed, an example of such an API is to be found in the "Application Response Measurement (ARM) API Guide, Version 2" [1].) - Provide explicit support for the management of applications distributed within a single managed system ("local" distribution); - Address generic resource management issues, including: - files in use; - I/O statistics (from the application's perspective, not at the operating system or device driver level); - application-layer networking resource usage - Facilities for the control of applications, including: - Stopping application elements - Suspending and resuming application elements; - Requesting reconfiguration (e.g., SIGHUP). Note that these issues are addressed at least in part by other (non- IETF) standards work, including "ITU-T Recommendation X.744 | ISO/IEC IS 10164-18:1996" [3] and "IEEE P1387.2, POSIX System Administration - Part 2: Software Administration" [2]. Kalbfleisch, et al. Standards Track [Page 3] RFC 2564 Application Management MIB May 1999 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: An overall architecture, described in RFC 2571 [26]. Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [4], STD 16, RFC 1212 [6] and RFC 1215 [7]. The second version, called SMIv2, is described in STD 58, RFC 2578 [15], RFC 2579 [16] and RFC 2580 [17]. Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [5]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [14] and RFC 1906 [19]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [19], RFC 2572 [27] and RFC 2574 [29]. Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [5]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [18]. A set of fundamental applications described in RFC 2573 [28] and the view-based access control mechanism described in RFC 2575 [30]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Kalbfleisch, et al. Standards Track [Page 4] RFC 2564 Application Management MIB May 1999 3. Architecture Object-oriented modeling techniques like subclassing and multiple inheritance can be emulated in the SNMP information model through the use of tables with common indexes. The challenge for the developer of management applications is to recognize those situations in which various aspects of a single logical resource are represented in several different tables, possibly defined in different MIBs. Most of the management information defined here may pertain to any number of applications in a managed system. The simplest way of supporting this requirement within the SNMP information model is to use tables. This means that the management information for a particular resource may be found in one or more rows of one or more tables; the fact that this information pertains to a single resource may be inferred from the index values used, possibly with the support of mapping tables. This also means that a single table may contain management information relevant to a number of applications. This has significant implementation implications; see the implementation issues section below for more information. 3.1. Relationships to other MIBs This section outlines the relationships of the components of this MIB (usually in the form of common indexing structures) to: - the systems applications MIB [31] - the host resources MIB [10] - the network services monitoring MIB [23] 3.1.1. Relationship to the System Application MIB The system application MIB defines attributes for management of applications which can be realized without instrumenting the application itself. This specification extends that framework to include additional attributes which will typically require instrumentation within the managed resource. The sysApplRunElmtIndex is the key connection between these two MIBs; it is essential that implementations of this MIB and of the system applications MIB running concurrently on a given platform employ a consistent policy for assigning this value to identify running application elements. Kalbfleisch, et al. Standards Track [Page 5] RFC 2564 Application Management MIB May 1999 3.1.2. Relationship to the Host Resources MIB The Host Resources MIB [10] supplies information on the hardware, operating system, installed and running software on a host. The Host Resources MIB has three hardware groups ("hrSystem", "hrStorage" and "hrDevice") and three software groups ("hrSWRun", "hrSWRunPerf" and "hrSWInstalled"). Of these, the software groups are of greatest significance to this MIB. The software groups define management information on the software used in the system. The information provided is grouped into (1) the currently running, (2) the performance and (3) the installed applications. The index "hrSWRunIndex" used in the "hrSWRunTable" and other tables to identify running software by process identifier (or equivalent) relates information in the Host Resources MIB to information in the System Applications MIB and this MIB. It is essential that the values assigned to hrSWRunIndex from the Host Resources MIB be consistent with the values used for sysApplRunElmtIndex. 3.1.3. Relationship to NSM The Network Services Monitoring MIB [23] is defined as the base set of attributes for managing network applications. The Application MIB includes information normally obtainable only from the managed resource itself, rather than the supporting system. Due to differences in index representation, the relationship between the Network Services Monitoring MIB and the Application MIB is not formally defined. 4. MIB Structure This MIB is organized into several groups, which in turn are organized into tables to provide the monitoring and control of information relevant to the management of applications. The groups model: - the service-level view of applications - information on open channels (files, connections, transaction streams) in use by applications - historical information on former channels - process-level status and control information Kalbfleisch, et al. Standards Track [Page 6] RFC 2564 Application Management MIB May 1999 These groups are organized into various tables. Information for a particular running managed application appears in the form of entries in the appropriate tables. The tables are: - the tables providing a service-level view, including: - the service name to service instance table - the service instance to service name table - the service instance to running application element table - the running application element to service instance table - the tables providing information on I/O channels, including: - the table of open channels - the table of open files - the open connections table - the transaction statistics tables - historical information on I/O channels - the running application element status and control group - the running application element status table - the running application element control table In order to support SNMPv1, SNMPv2, and SNMPv3 environments, in cases where counter objects may potentially advance very rapidly, where sixty-four bit counters have been used thirty-two bit counters reporting the low-order thirty-two bits of the value have also been defined. Since rows in most of these tables will come and go with the running application elements whose information is contained in them, sysUpTime.0 is not appropriate as a discontinuity indicator for counters in these tables. By defining separate discontinuity indicators for the rows in these tables, entries can come and go as needed without causing other objects to appear to have discontinuities. As required by [15], the discontinuity indicators for the various information objects in these tables are identified in Kalbfleisch, et al. Standards Track [Page 7] RFC 2564 Application Management MIB May 1999 the relevant DESCRIPTION clauses. Note that a discontinuity in one of these counters does not imply a sysUpTime.0 discontinuity, nor does a sysUpTime.0 discontinuity imply a discontinuity in any of these counters. 4.1. The service-level tables The service-level tables permit the identification of one or more instances of named services on a system, and the association of running application elements to these services. Service names are represented as human-readable strings, using values assigned by IANA where possible. The allocation of unique values for service instance identifiers is a local administrative issue; the values allocated must be constant for the lifetime of the service instance, and re-use of values should be avoided. It is important to understand that a service is not the same thing as a protocol. Rather, some services may be at least partially described by the protocol(s) used to provide that service. In deciding what should or should not be considered a service, the following factors merit consideration: - is there an identifiable set of resources associated with providing this service? - is there a reasonably long-lived server or client process? Following this reasoning, one can see where SMTP and HTTP service providers would be good candidates for classification as services for purposes of application management, where finger probably would not. Of course, implementors of this MIB are free to define additional services. An applicability statement may be an appropriate vehicle for standardizing how a specific service's information is reported using this MIB. 4.1.1. The service name to service instance table The service name to service instance table uses the service name as its primary key, and the service instance identifier as its secondary key. It facilitates the identification and lookup of the instances of a given service in a system. Kalbfleisch, et al. Standards Track [Page 8] RFC 2564 Application Management MIB May 1999 4.1.2. The service instance to service name table The service instance to service name table uses the service instance identifier as its primary key, and the service name as its secondary key. Given a service instance identifier, it facilitates the lookup of the name of the service being provided. 4.1.3. The service instance to running application element table The service instance to running application element table uses the service instance identifier as its primary key, and the running application element index as its secondary key. This facilitates the identification of the set of running application elements providing a given instance of a service. 4.1.4. The running application element to service instance table The running application element to service instance table uses the running application element index as its primary key and the service instance identifier as its secondary key. It identifies the set of services provided by a given running application element. 4.2. The I/O channel group Information processed by an application can be modeled using the concept of a channel. Two kinds of channels, for example, are files and network connections. +-------+ | File | +---------+ /+-------+ +-------------+ | Generic | / | transaction |----| I/O |-------< | stream | | Channel | \ +------------+ +-------------+ +---------+ \ | open or | \| listening | | connection | +------------+ For each entry in the open channel table, there will be a corresponding entry in either the open file table or the open connection table. The information flowing on a channel may be structured as transactions. When the information flow on a channel is being monitored as a transaction stream, an entry in the transaction stream table will represent this fact and the associated information about Kalbfleisch, et al. Standards Track [Page 9] RFC 2564 Application Management MIB May 1999 that stream. To facilitate traversal of these tables and retrieval of information relevant to a specific running application element or service instances, the initial indexes of these tables are the same. In each case, the first index determines whether the second index is interpreted as a running application element identifier or as a service instance identifier. The third index serves to uniquely identify a channel (and consequently, an open connection or file) in the context of a running application element or service instance. The transaction stream summary table contains per-stream summaries of transaction statistics. The transaction flow statistics table contains statistics broken into both transmit and receive counts for requests and responses on each stream. The transaction kind statistics table contains information further broken down by transaction kind. The transaction tables have a common structure for their indexing, with additional indexes added for increasing detail. The initial three indexes are the same as all the other tables in this group, serving to uniquely identify each transaction stream. 4.2.1. The open channels table The following information is available in this table: - time at which the channel was opened - number of read requests - number of bytes read - time at which most recent read operation was initiated - number of write requests - number of bytes written - time at which most recent write operation was initiated 4.2.2. The open files table The open files table contains one entry for each file in use by a manageable running application element. (See "Definitions of System-Level Managed Objects for Applications" [31] for a detailed definition of a running application element.) The purpose of this table is to identify the files in use and to record information Kalbfleisch, et al. Standards Track [Page 10] RFC 2564 Application Management MIB May 1999 peculiar to files not already covered in the open channel table. If multiple running application elements open the same file, there will be an entry for each running application element opening that file. Similarly, if a running application element opens a file multiple times, there will be an entry in this table for the file corresponding to each open. The task of combining the information for file activity from this table (organized by running application element) into per-application statistics can be accomplished by a manager using the System Application MIB's [31] sysApplInstallPkgTable to find the installed application, the sysApplRunTable to find the running instances of that application, and the sysApplElmtRunTable to find the relevant values of sysApplElmtRunIndex. The manager, armed with a set of values for sysApplElmtRunIndex, is now able to retrieve the relevant portions of the applOpenFileTable and other tables in this MIB. The following information is available in this table: - file name - file size - current mode (read/write) of this file By convention, the names "stdin", "stdout" and "stderr" are used when these streams cannot be resolved to actual file names. 4.2.3. The open connections table This table provides information on channels that are open connections or listeners. The following information is available for each connection: - identification of the transport protocol in use - near-end address and port - far-end address and port - identification of the application layer protocol in use Kalbfleisch, et al. Standards Track [Page 11] RFC 2564 Application Management MIB May 1999 4.2.4. The transaction stream summary table The transaction stream summary table contains per-stream summaries of transaction statistics. The simple model of a transaction used here looks like this: invoker | Request | performer | - - - - - - > | | | | Response | | < - - - - - - | | | Since in some protocols it is possible for an entity to take on both the invoker and performer roles, information here is accumulated for transmitted and received requests, as well as for transmitted and received responses. Counts are maintained for both transactions and bytes transferred. The information represented in this table includes: - identification of the underlying connection or file used for this transaction stream - a human-readable description of this stream - a human-readable description of this stream's notion of what a unit of work is - the cumulative amount of time spent (as an operation invoker) waiting for responses (from queueing of request to arrival of first response) - the cumulative amount of time spent (as an operation invoker) receiving responses (time from the arrival of the first response to the arrival of the last response in a series of responses to a particular request) - the cumulative amount of time spent (as an operation performer) handling requests (time from receipt of request to queueing of first outgoing response) - the cumulative amount of time spent (as an operation performer) sending responses (time from queuing of first response to the last response in a series of responses to a particular request) Kalbfleisch, et al. Standards Track [Page 12] RFC 2564 Application Management MIB May 1999 - the cumulative number of transactions initiated (as an invoker) - the cumulative number of transactions processed (as a performer) 4.2.5. The transaction flow statistics table The transaction flow statistics table contains statistics broken into both transmit and receive counts for requests and responses on each stream. In addition to the service instance / running application element and transaction stream identifier indexes, rows in this table are indexed by flow direction (transmit or receive) and role (requests and responses). The information in this table includes: - the number of transactions processed - the number of bytes processed - the time at which the most recent transaction was processed in this flow 4.2.6. The transaction kind statistics table The transaction kind statistics table contains summary information organized by direction, request/response, and transaction kind for each stream. The indexing of this table is like that of the transaction flow table, with the addition of a transaction kind index. - number of transactions processed - number of bytes processed - the time at which the most recent transaction of this kind in this direction in this stream was processed 4.3. The former channel group The former channel group has several tables. The former channel control table controls the retention of history information by a running application element or service instance. The remaining tables parallel the structure of the channel group, with one significant difference in indexing structure. The closed channel index is independent from the open channel index. Kalbfleisch, et al. Standards Track [Page 13] RFC 2564 Application Management MIB May 1999 4.3.1. The former channel control table The former channel control table provides control over the accumulation of information on former connections for running application elements and service instances. For each one, this table, indexed by the running application element or service instance index, controls whether information on former channels is accumulated, how many of these history records are retained, how long these are retained (within the lifetime of the process), and a count of history entries that were deleted before their expiration time in order to make room for new entries. 4.3.2. The former channel table The former channel table provides historical information on channels that have been closed. The number and lifetime of these entries is controlled, for each running application element or service instance, by the former channel control table. Most of the information in this table corresponds to information in the open channel table. For the connection or file-specific aspects of a given former channel, an entry will exist in the former connection table or in the former file table. 4.3.3. The former connection table For formerly open channels that were connections, connection-specific historical information is kept in the former connection table. For each entry in the former connection table, there will be an identically indexed entry in the former channel table. 4.3.4. The former file table For formerly open channels that were files, file-specific historical information is kept in the former file table. For each entry in the former file table, there will be an identically indexed entry in the former channel table. 4.3.5. The transaction history tables Two tables provide per-transaction-kind breakdowns for channels carrying transaction-structured flows. These tables are analogous to the transaction flow and kind statistics tables, with similar index structures. Kalbfleisch, et al. Standards Track [Page 14] RFC 2564 Application Management MIB May 1999 4.4. The running element status and control group The running application element status and control group has two tables. 4.4.1. The running application element status table This table provides information for a running application element. Indexed by the sysApplElmtRunIndex, an entry in this table reports useful information on that running element's resource usage. Entries in this table contain: - current heap usage for this running application element - current number of open network connections for this running application element - the most recent error status message issued by this running application element Note that other information, such as the current number of open files for this running application element, is available from the sysapplElmtRunTable in [31]. 4.4.2. The running application element control table This table provides rudimentary control over a running application element. Indexed by the sysApplElmtRunIndex, an entry in this table gives a manager with appropriate permissions the ability to suspend and resume processing by this running element, the ability to request reconfiguration, and the ability to terminate the running element. Variables in this table include: - a suspend/resume control - a reconfiguration request control - a termination request control Kalbfleisch, et al. Standards Track [Page 15] RFC 2564 Application Management MIB May 1999 5. Definitions APPLICATION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter64, Counter32, Gauge32, mib-2, Unsigned32, zeroDotZero FROM SNMPv2-SMI DateAndTime, TEXTUAL-CONVENTION, TestAndIncr, TDomain, TimeStamp, TruthValue FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF LongUtf8String, sysApplElmtRunIndex FROM SYSAPPL-MIB; applicationMib MODULE-IDENTITY LAST-UPDATED "9811171815Z" ORGANIZATION "Application MIB Working Group" CONTACT-INFO "http://www.ietf.org/html.charters/applmib-charter.html Randy Presuhn BMC Software, Inc. 965 Stewart Drive Sunnyvale, CA 94086 USA Telephone: +1 408 616-3100 Facsimile: +1 408 616-3101 EMail: randy_presuhn@bmc.com " DESCRIPTION "This MIB defines objects representing generic aspects of applications that are of interest to management but typically require instrumentation within managed application elements. " ::= { mib-2 62 } -- -- Registration hierarchy for this MIB -- applicationMibObjects OBJECT IDENTIFIER ::= { applicationMib 1 } Kalbfleisch, et al. Standards Track [Page 16] RFC 2564 Application Management MIB May 1999 applicationMibConformance OBJECT IDENTIFIER ::= { applicationMib 2 } -- -- Groups defined in this MIB -- applServiceGroup OBJECT IDENTIFIER ::= { applicationMibObjects 1 } applChannelGroup OBJECT IDENTIFIER ::= { applicationMibObjects 2 } applPastChannelGroup OBJECT IDENTIFIER ::= { applicationMibObjects 3 } applElmtRunControlGroup OBJECT IDENTIFIER ::= { applicationMibObjects 4 } Unsigned64TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A non-negative 64-bit bit integer, without counter semantics." SYNTAX Counter64 ApplTAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. For snmpUDPDomain, an ApplTAddress is 6 octets long, the initial 4 octets containing the IP-address in network-byte order and the last 2 containing the UDP port in network-byte order. Consult 'Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)' for further information on snmpUDPDomain." SYNTAX OCTET STRING (SIZE (0..255)) Kalbfleisch, et al. Standards Track [Page 17] RFC 2564 Application Management MIB May 1999 -- **************************************************************** -- -- applServiceGroup - -- -- The service-level tables permit the identification of one -- or more instances of named services on a system, and the -- association of running application elements to services. -- -- **************************************************************** -- **************************************************************** -- -- The service name to service instance table -- -- **************************************************************** applSrvNameToSrvInstTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplSrvNameToSrvInstEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The service name to service instance table uses service name as its primary key, and service instance identifier as its secondary key. It facilitates the identification and lookup of the instances of a given service in a system." ::= { applServiceGroup 1 } applSrvNameToSrvInstEntry OBJECT-TYPE SYNTAX ApplSrvNameToSrvInstEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applSrvNameToSrvInstEntry identifies an instance of a given service. The allocation and reservation of unique values for applSrvIndex is an administrative issue. An applSrvNameToSrvInstEntry exists for the lifetime of that instance of that service; the index values may not change during that lifetime. " INDEX { applSrvName, applSrvIndex } ::= { applSrvNameToSrvInstTable 1 } Kalbfleisch, et al. Standards Track [Page 18] RFC 2564 Application Management MIB May 1999 ApplSrvNameToSrvInstEntry ::= SEQUENCE { applSrvInstQual SnmpAdminString } applSrvInstQual OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of applSrcInstQual provides additional information about this particular instance of this service. Although not used for indexing purposes, the value of this attribute should be sufficiently unique to be helpful to an administrator in distinguishing among service instances. " ::= { applSrvNameToSrvInstEntry 1 } -- **************************************************************** -- -- Service instance to Service Name table -- -- **************************************************************** applSrvInstToSrvNameTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplSrvInstToSrvNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The service instance to service name table uses service instance identifier as its primary key, and service name as its secondary key. Given a service instance identifier, it facilitates the lookup of the name of the service being provided." ::= { applServiceGroup 2 } Kalbfleisch, et al. Standards Track [Page 19] RFC 2564 Application Management MIB May 1999 applSrvInstToSrvNameEntry OBJECT-TYPE SYNTAX ApplSrvInstToSrvNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applSrvInstToSrvNameEntry maps a service instance identifier back to a service name." INDEX { applSrvIndex, applSrvName } ::= { applSrvInstToSrvNameTable 1 } ApplSrvInstToSrvNameEntry ::= SEQUENCE { applSrvName SnmpAdminString } applSrvName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The human-readable name of a service. Where appropriate, as in the case where a service can be identified in terms of a single protocol, the strings should be established names such as those assigned by IANA and found in STD 2 [13], or defined by some other authority. In some cases private conventions apply and the string should in these cases be consistent with these non-standard conventions. An applicability statement may specify the service name(s) to be used. " ::= { applSrvInstToSrvNameEntry 1 } -- **************************************************************** -- -- The service instance to running application element table -- -- **************************************************************** applSrvInstToRunApplElmtTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplSrvInstToRunApplElmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The service instance to running application element table uses the service instance identifier as its primary key, and the running application element index as its secondary key. This facilitates the identification Kalbfleisch, et al. Standards Track [Page 20] RFC 2564 Application Management MIB May 1999 of the set of running application elements providing a given instance of a service." ::= { applServiceGroup 3 } applSrvInstToRunApplElmtEntry OBJECT-TYPE SYNTAX ApplSrvInstToRunApplElmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applSrvInstToRunApplElmtEntry identifies a running application element providing an instance of a service. Note that there may be multiple running application elements involved in the provision of an instance of a service." INDEX { applSrvIndex, sysApplElmtRunIndex } ::= { applSrvInstToRunApplElmtTable 1 } ApplSrvInstToRunApplElmtEntry ::= SEQUENCE { applSrvIndex Unsigned32 } applSrvIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS read-only STATUS current DESCRIPTION "An applSrvIndex is the system-unique identifier of an instance of a service. The value is unique not only across all instances of a given service, but also across all services in a system. Re-use of values for this index should be avoided. No two service instances in a given system shall concurrently have the same value for this index. The value zero is excluded from the set of permitted values for this index. This allows other tables to potentially represent things which cannot be associated with a specific service instance. " ::= { applSrvInstToRunApplElmtEntry 1 } Kalbfleisch, et al. Standards Track [Page 21] RFC 2564 Application Management MIB May 1999 -- **************************************************************** -- -- The running application element to service instance table -- -- **************************************************************** applRunApplElmtToSrvInstTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplRunApplElmtToSrvInstEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The running application element to service instance table uses the running application element index as its primary key and the service instance identifier as its secondary key. It identifies the set of services provided by a given running application element." ::= { applServiceGroup 4 } applRunApplElmtToSrvInstEntry OBJECT-TYPE SYNTAX ApplRunApplElmtToSrvInstEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applRunApplElmtToSrvInstEntry serves to identify an instance of a service being provided by a given running application element. Note that a particular running application element may provide multiple services." INDEX { sysApplElmtRunIndex, applSrvInstance } ::= { applRunApplElmtToSrvInstTable 1 } ApplRunApplElmtToSrvInstEntry ::= SEQUENCE { applSrvInstance Unsigned32 } applSrvInstance OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS read-only STATUS current DESCRIPTION "An applSrvInstance is the system-unique identifier of an instance of a service. The value is unique not only across all instances of a given service, but also across all services. Re-use of values for this index should be avoided. No two service instances in a given system shall concurrently have the same value for this index. Kalbfleisch, et al. Standards Track [Page 22] RFC 2564 Application Management MIB May 1999 The value zero is excluded from the set of permitted values for this index. This allows other tables to potentially represent things which cannot be associated with a specific service instance. This attribute is semantically identical to applSrvIndex." ::= { applRunApplElmtToSrvInstEntry 1 } -- **************************************************************** -- -- applChannelGroup - group with tables for I/O -- -- In this group, the common abstraction is the Channel. -- Channels are realized as files or connections. -- The information flowing on a channel can always be -- measured in terms of a byte stream. Furthermore, for many -- channels, this information may also be measured in terms -- of transactions. -- -- For all of these tables, the first two indexes determines -- whether what is being measured is for a single running -- application element or for an instance of a service. -- -- The second index identifies the running application element -- or service instance. -- -- The third index is the channel id, which uniquely identifies -- a channel within the context of a running application element -- or service instance. -- -- Any remaining indexes are table-specific. -- -- **************************************************************** -- **************************************************************** -- -- applOpenChannelTable - Table of Open Channels -- -- **************************************************************** applOpenChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplOpenChannelEntry MAX-ACCESS not-accessible STATUS current Kalbfleisch, et al. Standards Track [Page 23] RFC 2564 Application Management MIB May 1999 DESCRIPTION "The applOpenChannelTable reports information on open channels for running application elements and for service instances. This table is indexed by applElmtOrSvc, applElmtOrSvcId, and applOpenChannelIndex. This effectively groups all entries for a given running application element or service instance together. ApplChannelIndex uniquely identifies an open channel (and, consequently, a file or connection) within the context of a particular running application element or service instance. Some of the information in this table is available through both sixty-four and thirty-two bit counters. The sixty-four bit counters are not accessible in protocols that do not support this data type." ::= { applChannelGroup 1 } applOpenChannelEntry OBJECT-TYPE SYNTAX ApplOpenChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applOpenChannelEntry indicates that a channel has been opened by this running application element or service instance and is still open. Note that if a file has been opened multiple times, even by the same process, it will have multiple channel entries." INDEX { applElmtOrSvc, applElmtOrSvcId, applOpenChannelIndex } ::= { applOpenChannelTable 1 } ApplOpenChannelEntry ::= SEQUENCE { applElmtOrSvc INTEGER, applElmtOrSvcId Unsigned32, applOpenChannelIndex Unsigned32, applOpenChannelOpenTime TimeStamp, applOpenChannelReadRequests Counter64, applOpenChannelReadRequestsLow Counter32, applOpenChannelReadFailures Counter32, applOpenChannelBytesRead Counter64, applOpenChannelBytesReadLow Counter32, applOpenChannelLastReadTime DateAndTime, applOpenChannelWriteRequests Counter64, applOpenChannelWriteRequestsLow Counter32, applOpenChannelWriteFailures Counter32, applOpenChannelBytesWritten Counter64, Kalbfleisch, et al. Standards Track [Page 24] RFC 2564 Application Management MIB May 1999 applOpenChannelBytesWrittenLow Counter32, applOpenChannelLastWriteTime DateAndTime } applElmtOrSvc OBJECT-TYPE SYNTAX INTEGER { service(1), element(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applElmtOrSvc attribute serves as an index for tables that can hold information both for individual running application elements as well as for service instances. If the value is service(1), the row contains information gathered at the level of a service. If the value is element(2), the row contains information for an individual running application element." ::= { applOpenChannelEntry 1 } applElmtOrSvcId OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applElmtOrSvcId attribute is used as an index in conjunction with the applElmtOrSvc attribute. When the value of applElmtOrSvc is service(1), this attribute's value corresponds to that of applSrvIndex, when the value of applElmtOrSvc is element(2), this attribute's value corresponds to sysApplElmtRunIndex." ::= { applOpenChannelEntry 2 } applOpenChannelIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This attribute serves to uniquely identify this open connection in the context of the running application element or service instance. Where suitable, the application's native descriptor number should be used." ::= { applOpenChannelEntry 3 } Kalbfleisch, et al. Standards Track [Page 25] RFC 2564 Application Management MIB May 1999 applOpenChannelOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the value of sysUpTime.0 when this channel was opened and this entry was added to this table. This attribute serves as a discontinuity indicator for the counter attributes in this entry and for any corresponding entries in the applOpenConnectionTable, applOpenFileTable, and the applTransactionStreamTable." ::= { applOpenChannelEntry 4 } applOpenChannelReadRequests OBJECT-TYPE SYNTAX Counter64 UNITS "read requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of read requests for this channel. All read requests for this channel by this entity, regardless of completion status, are included in this count. Read requests are counted in terms of system calls, rather than API calls. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 5 } applOpenChannelReadRequestsLow OBJECT-TYPE SYNTAX Counter32 UNITS "read requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the low thirty-two bits of applOpenChannelReadRequests. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 6 } Kalbfleisch, et al. Standards Track [Page 26] RFC 2564 Application Management MIB May 1999 applOpenChannelReadFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failed read requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of failed read requests. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 7 } applOpenChannelBytesRead OBJECT-TYPE SYNTAX Counter64 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of bytes read from this channel. Only bytes successfully read are included in this count. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 8 } applOpenChannelBytesReadLow OBJECT-TYPE SYNTAX Counter32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applOpenChannelBytesRead. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 9 } applOpenChannelLastReadTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 27] RFC 2564 Application Management MIB May 1999 DESCRIPTION "This attribute reports the time of the most recent read request made by this entity, regardless of completion status, for this open channel. If no read requests have been made the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applOpenChannelEntry 10 } applOpenChannelWriteRequests OBJECT-TYPE SYNTAX Counter64 UNITS "write requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of write requests for this channel made by this entity. All write requests for this channel, regardless of completion status, are included in this count. Write requests are counted in terms of system calls, rather than API calls. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 11 } applOpenChannelWriteRequestsLow OBJECT-TYPE SYNTAX Counter32 UNITS "write requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applOpenChannelWriteRequests. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 12 } applOpenChannelWriteFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failed write requests" MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 28] RFC 2564 Application Management MIB May 1999 DESCRIPTION "This attribute reports the number of failed write requests. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 13 } applOpenChannelBytesWritten OBJECT-TYPE SYNTAX Counter64 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of bytes written to this channel. Only bytes successfully written (without errors reported by the system to the API in use by the application) are included in this count. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 14 } applOpenChannelBytesWrittenLow OBJECT-TYPE SYNTAX Counter32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applOpenChannelBytesWritten. Discontinuities in this counter can be detected by monitoring the applOpenChannelOpenTime value for this entry." ::= { applOpenChannelEntry 15 } applOpenChannelLastWriteTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the time of the most recent write request made by this running application element or service instance, regardless of completion status, for this open channel. Kalbfleisch, et al. Standards Track [Page 29] RFC 2564 Application Management MIB May 1999 If no write requests have been made, the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applOpenChannelEntry 16 } -- **************************************************************** -- -- applOpenFileTable - Table of Open Files -- -- **************************************************************** applOpenFileTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplOpenFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applOpenFileTable reports information on open files for service instances or application elements. This table is indexed by applElmtOrSvc and applElmtOrSvcId, effectively grouping all entries for a given running service instance or application element together, and by applOpenChannelIndex, uniquely identifying an open channel (and, consequently, a file) within the context of a particular service instance or application element. Elements in this table correspond to elements in the applOpenChannelTable that represent files. For rows in the applOpenChannelTable that do not represent files, corresponding rows in this table will not exist." ::= { applChannelGroup 2 } applOpenFileEntry OBJECT-TYPE SYNTAX ApplOpenFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applOpenFileEntry indicates that a file has been opened by this running application element and is still open. Note that if a file has been opened multiple times, even by the same process, it will have multiple entries." INDEX { applElmtOrSvc, applElmtOrSvcId, applOpenChannelIndex } ::= { applOpenFileTable 1 } Kalbfleisch, et al. Standards Track [Page 30] RFC 2564 Application Management MIB May 1999 ApplOpenFileEntry ::= SEQUENCE { applOpenFileName LongUtf8String, applOpenFileSizeHigh Unsigned32, applOpenFileSizeLow Unsigned32, applOpenFileMode INTEGER } applOpenFileName OBJECT-TYPE SYNTAX LongUtf8String MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the name of this open file. Wherever practical, a fully qualified path name should be reported. The values 'stdin', 'stdout', and 'stderr' are reserved in accordance with common usage when the fully qualified path name cannot be determined." ::= { applOpenFileEntry 1 } applOpenFileSizeHigh OBJECT-TYPE SYNTAX Unsigned32 UNITS "2^32 byte blocks" MAX-ACCESS read-only STATUS current DESCRIPTION "This file's current size in 2^32 byte blocks. For example, for a file with a total size of 4,294,967,296 bytes, this attribute would have a value of 1; for a file with a total size of 4,294,967,295 bytes this attribute's value would be 0." ::= { applOpenFileEntry 2 } applOpenFileSizeLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This file's current size modulo 2^32 bytes. For example, for a file with a total size of 4,294,967,296 bytes this attribute would have a value of 0; for a file with a total size of 4,294,967,295 bytes this attribute's value would be 4,294,967,295." Kalbfleisch, et al. Standards Track [Page 31] RFC 2564 Application Management MIB May 1999 ::= { applOpenFileEntry 3 } applOpenFileMode OBJECT-TYPE SYNTAX INTEGER { read(1), write(2), readWrite(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the current mode of this file from the perspective of this running application element. These values have the following meanings: read(1) - file opened for reading only write(2) - file opened for writing only readWrite(3) - file opened for read and write. These values correspond to the POSIX/ANSI C library function fopen() 'type' parameter, using the following mappings: r -> read(1) w -> write(2) a -> write(2) + -> readWrite(3) " ::= { applOpenFileEntry 4 } -- **************************************************************** -- -- applOpenConnectionTable - Open Connection Table -- -- **************************************************************** applOpenConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplOpenConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applOpenConnectionTable provides information about open and listening connections from the perspective of a running application element or service instance. Entries in this table are indexed by applElmtOrSvc, applElmtOrSvcID, and by applOpenChannelIndex, which serves to uniquely identify each connection in the context of a service instance or running application Kalbfleisch, et al. Standards Track [Page 32] RFC 2564 Application Management MIB May 1999 element. For each row in this table, a corresponding row will exist in the applOpenChannel table. For rows in the applOpenChannelTable which do not represent open or listening connections, no corresponding rows will exist in this table." ::= { applChannelGroup 3 } applOpenConnectionEntry OBJECT-TYPE SYNTAX ApplOpenConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applOpenConnectionEntry indicates that a running application element or service instance has an open connection. The entry has information describing that connection. In the case of a TCP transport, the element applOpenConnectionNearEndAddr and that row's applOpenConnectionFarEndAddr would correspond to a tcpConnEntry. For a UDP transport, a similar relationship exists with respect to a udpEntry." INDEX { applElmtOrSvc, applElmtOrSvcId, applOpenChannelIndex } ::= { applOpenConnectionTable 1 } ApplOpenConnectionEntry ::= SEQUENCE { applOpenConnectionTransport TDomain, applOpenConnectionNearEndAddr ApplTAddress, applOpenConnectionNearEndpoint SnmpAdminString, applOpenConnectionFarEndAddr ApplTAddress, applOpenConnectionFarEndpoint SnmpAdminString, applOpenConnectionApplication SnmpAdminString } applOpenConnectionTransport OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 33] RFC 2564 Application Management MIB May 1999 DESCRIPTION "The applOpenConnectionTransport attribute identifies the transport protocol in use for this connection. If it is not practical to determine the underlying transport, this attribute's value shall have a value of {0 0}." DEFVAL { zeroDotZero } ::= { applOpenConnectionEntry 1 } applOpenConnectionNearEndAddr OBJECT-TYPE SYNTAX ApplTAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The applOpenConnectionNearEndAddr attribute reports the transport address and port information for the near end of this connection. If the value is not known, the value has a length of zero." DEFVAL { "" } ::= { applOpenConnectionEntry 2 } applOpenConnectionNearEndpoint OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applOpenConnectionNearEndpoint attribute reports the fully-qualified domain name and port information for the near end of this connection. The format of this attribute for TCP and UDP-based protocols is the fully-qualified domain name immediately followed by a colon which is immediately followed by the decimal representation of the port number. If the value is not known, the value has a length of zero." DEFVAL { "" } ::= { applOpenConnectionEntry 3 } applOpenConnectionFarEndAddr OBJECT-TYPE SYNTAX ApplTAddress MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 34] RFC 2564 Application Management MIB May 1999 DESCRIPTION "The applOpenConnectionFarEndAddr attribute reports the transport address and port information for the far end of this connection. If not known, as in the case of a connectionless transport, the value of this attribute shall be a zero-length string." DEFVAL { "" } ::= { applOpenConnectionEntry 4 } applOpenConnectionFarEndpoint OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applOpenConnectionFarEndpoint attribute reports the fully-qualified domain name and port information for the far end of this connection. The format of this attribute for TCP and UDP-based protocols is the fully-qualified domain name immediately followed by a colon which is immediately followed by the decimal representation of the port number. If not known, as in the case of a connectionless transport, the value of this attribute shall be a zero-length string." DEFVAL { "" } ::= { applOpenConnectionEntry 5 } applOpenConnectionApplication OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applOpenConnectionApplication attribute identifies the application layer protocol in use. If not known, the value of this attribute shall be a zero-length string. When possible, protocol names should be those used in the 'ASSIGNED NUMBERS' [13]. For example, an SMTP mail server would use 'SMTP'." DEFVAL { "" } ::= { applOpenConnectionEntry 6 } Kalbfleisch, et al. Standards Track [Page 35] RFC 2564 Application Management MIB May 1999 -- **************************************************************** -- -- applTransactionStreamTable - common -- information for transaction stream monitoring -- -- **************************************************************** applTransactionStreamTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplTransactionStreamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applTransactionStreamTable contains common information for transaction statistic accumulation." ::= { applChannelGroup 4 } applTransactionStreamEntry OBJECT-TYPE SYNTAX ApplTransactionStreamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applTransactionStreamEntry contains information for a single transaction stream. A transaction stream can be a network connection, file, or other source of transactions." INDEX { applElmtOrSvc, applElmtOrSvcId, applOpenChannelIndex } ::= { applTransactionStreamTable 1 } ApplTransactionStreamEntry ::= SEQUENCE { applTransactStreamDescr SnmpAdminString, applTransactStreamUnitOfWork SnmpAdminString, applTransactStreamInvokes Counter64, applTransactStreamInvokesLow Counter32, applTransactStreamInvCumTimes Counter32, applTransactStreamInvRspTimes Counter32, applTransactStreamPerforms Counter64, applTransactStreamPerformsLow Counter32, applTransactStreamPrfCumTimes Counter32, applTransactStreamPrfRspTimes Counter32 } applTransactStreamDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactStreamDescr attribute provides a human-readable description of this transaction stream. Kalbfleisch, et al. Standards Track [Page 36] RFC 2564 Application Management MIB May 1999 If no descriptive information is available, this attribute's value shall be a zero-length string." DEFVAL { "" } ::= { applTransactionStreamEntry 1 } applTransactStreamUnitOfWork OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactStreamUnitOfWork attribute provides a human-readable definition of what the unit of work is for this transaction stream. If no descriptive information is available, this attribute's value shall be a zero-length string." DEFVAL { "" } ::= { applTransactionStreamEntry 2 } applTransactStreamInvokes OBJECT-TYPE SYNTAX Counter64 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "Cumulative count of requests / invocations issued. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 3 } applTransactStreamInvokesLow OBJECT-TYPE SYNTAX Counter32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "This counter corresponds to the low thirty-two bits of applTransactStreamInvokes. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 4 } Kalbfleisch, et al. Standards Track [Page 37] RFC 2564 Application Management MIB May 1999 applTransactStreamInvCumTimes OBJECT-TYPE SYNTAX Counter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactStreamInvCumTimes attribute reports the cumulative sum of the lengths of the intervals measured between the transmission of requests and the receipt of (the first of) the corresponding response(s). Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 5 } applTransactStreamInvRspTimes OBJECT-TYPE SYNTAX Counter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactStreamInvRspTimes attribute reports the cumulative sum of the lengths of the intervals measured between the receipt of the first and last of multiple responses to a request. For transaction streams which do not permit multiple responses to a single request, this attribute will be constant. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 6 } applTransactStreamPerforms OBJECT-TYPE SYNTAX Counter64 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "Cumulative count of transactions performed. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 7 } Kalbfleisch, et al. Standards Track [Page 38] RFC 2564 Application Management MIB May 1999 applTransactStreamPerformsLow OBJECT-TYPE SYNTAX Counter32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "This counter reports the low thirty-two bits of applTransactStreamPerforms. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 8 } applTransactStreamPrfCumTimes OBJECT-TYPE SYNTAX Counter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactStreamPrfCumTimes attribute reports the cumulative sum of the interval lengths measured between receipt of requests and the transmission of the corresponding responses. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 9 } applTransactStreamPrfRspTimes OBJECT-TYPE SYNTAX Counter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For each transaction performed, the elapsed time between when the first response is enqueued and when the last response is enqueued is added to this cumulative sum. For single-response protocols, the value of applTransactStreamPrfRspTimes will be constant. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactionStreamEntry 10 } Kalbfleisch, et al. Standards Track [Page 39] RFC 2564 Application Management MIB May 1999 -- **************************************************************** -- -- applTransactFlowTable -- -- **************************************************************** applTransactFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplTransactFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applTransactFlowTable contains entries, organized by application instance or running application element, direction of flow, and type (request/response) for each open transaction stream. The simple model of a transaction used here looks like this: invoker | Request | performer | - - - - - - > | | | | Response | | < - - - - - - | | | Since in some protocols it is possible for an entity to take on both the invoker and performer roles, information here is accumulated for transmitted and received requests, as well as for transmitted and received responses. Counts are maintained for both transactions and bytes transferred." ::= { applChannelGroup 5 } applTransactFlowEntry OBJECT-TYPE SYNTAX ApplTransactFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applTransactFlowEntry reports transaction throughput information for requests or response in a particular direction (transmit / receive) for a transaction stream. Entries in this table correspond to those in the applTransactionStreamTable with identical values for the applElmtOrSvc, applElmtOrSvcId, and applOpenChannelIndex. For all counter objects in one of these entries, Kalbfleisch, et al. Standards Track [Page 40] RFC 2564 Application Management MIB May 1999 the corresponding (same value for applElmtOrSvc, applElmtOrSvcId, and applOpenChannelIndex) applOpenChannelOpenTime object serves as a discontinuity indicator. " INDEX { applElmtOrSvc, applElmtOrSvcId, applOpenChannelIndex, applTransactFlowDirection, applTransactFlowReqRsp } ::= { applTransactFlowTable 1 } ApplTransactFlowEntry ::= SEQUENCE { applTransactFlowDirection INTEGER, applTransactFlowReqRsp INTEGER, applTransactFlowTrans Counter64, applTransactFlowTransLow Counter32, applTransactFlowBytes Counter64, applTransactFlowBytesLow Counter32, applTransactFlowTime DateAndTime } applTransactFlowDirection OBJECT-TYPE SYNTAX INTEGER { transmit(1), receive(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applTransactFlowDirection index serves to identify an entry as containing information pertaining to the transmit (1) or receive (2) flow of a transaction stream." ::= { applTransactFlowEntry 1 } applTransactFlowReqRsp OBJECT-TYPE SYNTAX INTEGER { request(1), response(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of the applTransactFlowReqRsp index indicates whether this entry contains information on requests (1), or responses (2)." ::= { applTransactFlowEntry 2 } applTransactFlowTrans OBJECT-TYPE SYNTAX Counter64 UNITS "transactions" MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 41] RFC 2564 Application Management MIB May 1999 DESCRIPTION "The applTransactFlowTrans attribute reports the number of request/response transactions (as indicated by the applTransactFlowReqRsp index) received/generated (as indicated by the applTransactFlowDirection index) that this service instance or running application element has processed for this transaction stream. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactFlowEntry 3 } applTransactFlowTransLow OBJECT-TYPE SYNTAX Counter32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applTransactFlowTrans. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactFlowEntry 4 } applTransactFlowBytes OBJECT-TYPE SYNTAX Counter64 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactFlowBytes attribute reports the number of request/response (as indicated by the applTransactFlowReqRsp index) bytes received/generated (as indicated by the applTransactFlowDirection index) handled by this application element or service instance on this transaction stream. All application layer bytes are included in this count, including any application layer wrappers, headers, or other overhead. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactFlowEntry 5 } Kalbfleisch, et al. Standards Track [Page 42] RFC 2564 Application Management MIB May 1999 applTransactFlowBytesLow OBJECT-TYPE SYNTAX Counter32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applTransactFlowBytes. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactFlowEntry 6 } applTransactFlowTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactFlowTime attribute records the time of the processing (receipt or transmission as indicated by the applTransactFlowDirection index) by this running application element or service instance of the most recent request/response (as indicated by the applTransactFlowReqRsp index) on this transaction stream. If no requests/responses been received/transmitted by this entity over this transaction stream, the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applTransactFlowEntry 7 } -- **************************************************************** -- -- applTransactKindTable - transaction statistics broken down -- according to the kinds of transactions in each direction -- for a transaction stream. -- -- **************************************************************** applTransactKindTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplTransactKindEntry MAX-ACCESS not-accessible STATUS current Kalbfleisch, et al. Standards Track [Page 43] RFC 2564 Application Management MIB May 1999 DESCRIPTION "The applTransactKindTable provides transaction statistics broken down by kinds of transaction. The definition of the kinds of transactions is specific to the application protocol in use, and may be documented in the form of an applicability statement. " ::= { applChannelGroup 6 } applTransactKindEntry OBJECT-TYPE SYNTAX ApplTransactKindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applTransactKindEntry reports information for a specific service instance or running application element's use of a specific transaction stream in a particular direction in requests or responses (as indicated by the applTransactFlowReqRsp index) broken down by transaction kind, as indicated by the applTransactKind index. Discontinuities in any of the counters in an entry can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." INDEX { applElmtOrSvc, applElmtOrSvcId, applOpenChannelIndex, applTransactFlowDirection, applTransactFlowReqRsp, applTransactKind } ::= { applTransactKindTable 1 } ApplTransactKindEntry ::= SEQUENCE { applTransactKind SnmpAdminString, applTransactKindTrans Counter64, applTransactKindTransLow Counter32, applTransactKindBytes Counter64, applTransactKindBytesLow Counter32, applTransactKindTime DateAndTime } applTransactKind OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1 .. 32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Kalbfleisch, et al. Standards Track [Page 44] RFC 2564 Application Management MIB May 1999 "The applTransactKind index is the human-readable identifier for a particular transaction kind within the context of an application protocol. The values to be used for a particular protocol may be identified in an applicability statement." ::= { applTransactKindEntry 1 } applTransactKindTrans OBJECT-TYPE SYNTAX Counter64 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactKindTrans attribute reports the number of request/response (as indicated by the applTransactFlowReqRsp index) transactions received/generated (as indicated by the applTransactFlowDirection index) handled by this application instance or application element on this transaction stream for this transaction kind. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactKindEntry 2 } applTransactKindTransLow OBJECT-TYPE SYNTAX Counter32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactKindTransLow attribute reports the low thirty-two bits of applTransactKindTrans. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactKindEntry 3 } applTransactKindBytes OBJECT-TYPE SYNTAX Counter64 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactKindBytes attribute reports the number of request/response (as indicated by the Kalbfleisch, et al. Standards Track [Page 45] RFC 2564 Application Management MIB May 1999 applTransactFlowReqRsp index) bytes received/generated (as indicated by the applTransactFlowDirection index) handled by this application element on this transaction stream for this transaction kind. All application layer bytes are included in this count, including any application layer wrappers, headers, or other overhead. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactKindEntry 4 } applTransactKindBytesLow OBJECT-TYPE SYNTAX Counter32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactKindBytesLow attribute corresponds to the low thirty-two bits of applTransactKindBytes. Discontinuities in this counter can be detected by monitoring the corresponding instance of applOpenChannelOpenTime." ::= { applTransactKindEntry 5 } applTransactKindTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The applTransactKindTime attribute records the time of the processing (receipt or transmission as indicated by the applTransactFlowDirection index) by this running application element or service instance of the most recent request/response (as indicated by the applTransactFlowReqRsp index) of this kind of transaction on this transaction stream. If no requests/responses of this kind been received/transmitted by this running application element or service instance over this transaction stream, the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applTransactKindEntry 6 } Kalbfleisch, et al. Standards Track [Page 46] RFC 2564 Application Management MIB May 1999 -- **************************************************************** -- -- applPastChannelGroup - logged information on former channels. -- These tables control the collection of channel history -- information and represent the accumulated historical data. -- -- **************************************************************** applPastChannelControlTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplPastChannelControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastChannelControlTable controls the accumulation of history information about channels from the perspective of service instances and running application elements. Entries in this table are indexed by applElmtOrSvc and applElmtOrSvcId, giving control of channel history accumulation at the level of each service instance and running application element." ::= { applPastChannelGroup 1 } applPastChannelControlEntry OBJECT-TYPE SYNTAX ApplPastChannelControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applPastChannelControlEntry provides the ability to control the retention of channel history information by service instances and running application elements." INDEX { applElmtOrSvc, applElmtOrSvcId } ::= { applPastChannelControlTable 1 } ApplPastChannelControlEntry ::= SEQUENCE { applPastChannelControlCollect INTEGER, applPastChannelControlMaxRows Unsigned32, applPastChannelControlTimeLimit Unsigned32, applPastChannelControlRemItems Counter32 } applPastChannelControlCollect OBJECT-TYPE SYNTAX INTEGER { enabled (1), frozen (2), disabled (3) } MAX-ACCESS read-write STATUS current DESCRIPTION Kalbfleisch, et al. Standards Track [Page 47] RFC 2564 Application Management MIB May 1999 "When the value of applPastChannelControlCollect is 'enabled', each time the corresponding running application element or service instance closes an open channel a new entry will be added to the applPastChannelTable. When the value of applPastChannelControlCollect is 'frozen', no new entries are added to the applPastChannelTable for this running application element or service instance, and old entries are not aged out. When the value of applPastChannelControlCollect is 'disabled', all entries are removed from applPastChannelTable for this running application or service instance, and no new entries are added." DEFVAL { enabled } ::= { applPastChannelControlEntry 1 } applPastChannelControlMaxRows OBJECT-TYPE SYNTAX Unsigned32 UNITS "channel history entries" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries allowed in the applPastChannelTable for this running application element or service instance. Once the number of rows for this running application element or service instance in the applPastChannelTable reaches this value, when new entries are to be added the management subsystem will make room for them by removing the oldest entries. Entries will be removed on the basis of oldest applPastChannelCloseTime value first." DEFVAL { 500 } ::= { applPastChannelControlEntry 2 } applPastChannelControlTimeLimit OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum time in seconds which an entry for this running application element or service instance may exist in the applPastChannelTable before it is removed. Any entry that is older than this value will be removed (aged out) from the table, unless the Kalbfleisch, et al. Standards Track [Page 48] RFC 2564 Application Management MIB May 1999 applPastChannelControlCollect is set to 'frozen'. Note that an entry may be aged out prior to reaching this time limit if it is the oldest entry in the table and must be removed to make space for a new entry so as to not exceed applPastChannelControlMaxRows, or if the applPastChannelControlCollect is set to 'disabled'." DEFVAL { 7200 } ::= { applPastChannelControlEntry 3 } applPastChannelControlRemItems OBJECT-TYPE SYNTAX Counter32 UNITS "channel history entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastChannelControlRemItems attribute reports the number of applPastChannelControlTable entries for this running application element or service instance that were deleted in order to make room for new history entries. This count does NOT include entries deleted for the following reasons: - the corresponding applPastChannelControlCollect attribute has been set to 'disabled' - the entry has been in the table longer that the time limit indicated by the corresponding applPastChannelControlTimeLimit. " ::= { applPastChannelControlEntry 4 } -- **************************************************************** -- -- applPastChannelTable - Table of former channels -- -- **************************************************************** applPastChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplPastChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastChannelTable provides history information about channels from the perspective of running application elements and service instances. Kalbfleisch, et al. Standards Track [Page 49] RFC 2564 Application Management MIB May 1999 Entries in this table are indexed by applElmtOrSvc, applElmtOrSvcId, and by applPastChannelIndex, which serves to uniquely identify each former channel in the context of a running application element or service instance. Note that the value of applPastChannelIndex is independent of the value applOpenChannelIndex had when this channel was open. Entries for closed channels for a given running application element or service instance can be added to this table only if its entry in the applPastChannelControlTable has the value 'enabled' for the attribute applPastChannelControlCollect. Entries for closed channels are removed under the following circumstances: - the running application element or service instance no longer exists - the corresponding applPastChannelControlCollect attribute has been set to 'disabled' - the entry has been in the table longer that the time limit indicated by the corresponding applPastChannelControlTimeLimit and the value of applPastChannelControlCollect is not 'frozen' - this is the oldest entry for the running application element or service instance in question and the addition of a new element would otherwise cause applPastChannelControlMaxRows to be exceeded for this running application element or service instance. - a value of applPastChannelIndex has been re-used. Note that under normal circumstances, this is unlikely. Removal/replacement of an entry under the last two conditions causes the corresponding applPastChannelControlRemItems to be incremented." ::= { applPastChannelGroup 2 } Kalbfleisch, et al. Standards Track [Page 50] RFC 2564 Application Management MIB May 1999 applPastChannelEntry OBJECT-TYPE SYNTAX ApplPastChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applPastChannelEntry indicates that a running application element or service instance once had an open channel, which is now closed. The entry has information describing that channel." INDEX { applElmtOrSvc, applElmtOrSvcId, applPastChannelIndex } ::= { applPastChannelTable 1 } ApplPastChannelEntry ::= SEQUENCE { applPastChannelIndex Unsigned32, applPastChannelOpenTime DateAndTime, applPastChannelCloseTime DateAndTime, applPastChannelReadRequests Unsigned64TC, applPastChannelReadReqsLow Unsigned32, applPastChannelReadFailures Unsigned32, applPastChannelBytesRead Unsigned64TC, applPastChannelBytesReadLow Unsigned32, applPastChannelLastReadTime DateAndTime, applPastChannelWriteRequests Unsigned64TC, applPastChannelWriteReqsLow Unsigned32, applPastChannelWriteFailures Unsigned32, applPastChannelBytesWritten Unsigned64TC, applPastChannelBytesWritLow Unsigned32, applPastChannelLastWriteTime DateAndTime } applPastChannelIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This attribute serves to uniquely identify this closed channel in the context of the running application element or service instance. This attribute has no other semantics. Note that the value of applPastChannelIndex is independent of the value applOpenChannelIndex had when this channel was active. In issuing this index value, the implementation must avoid re-issuing an index value which has already been Kalbfleisch, et al. Standards Track [Page 51] RFC 2564 Application Management MIB May 1999 assigned to an entry which has not yet been deleted due to age or space considerations. The value zero is excluded from the set of permitted values for this index in order to permit other tables to possibly represent information that cannot be associated with a specific entry in this table. " ::= { applPastChannelEntry 1 } applPastChannelOpenTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the time when this channel was originally opened. Note that this information is quite different from applOpenChannelOpenTime, which is used for the detection of counter discontinuities." ::= { applPastChannelEntry 2 } applPastChannelCloseTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the time when this channel was closed." ::= { applPastChannelEntry 3 } applPastChannelReadRequests OBJECT-TYPE SYNTAX Unsigned64TC UNITS "read requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the number of read requests for this channel made by this running application element or service instance. All read requests for this channel by this running application element or service instance, regardless of completion status, are included in this count. Read requests are counted in terms of system calls, rather than API calls." ::= { applPastChannelEntry 4 } Kalbfleisch, et al. Standards Track [Page 52] RFC 2564 Application Management MIB May 1999 applPastChannelReadReqsLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "read requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applPastChannelReadRequests." ::= { applPastChannelEntry 5 } applPastChannelReadFailures OBJECT-TYPE SYNTAX Unsigned32 UNITS "failed read requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of failed read requests." ::= { applPastChannelEntry 6 } applPastChannelBytesRead OBJECT-TYPE SYNTAX Unsigned64TC UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of bytes read from this channel by this running application element or service instance. Only bytes successfully read are included in this count. " ::= { applPastChannelEntry 7 } applPastChannelBytesReadLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applPastChannelBytesRead." ::= { applPastChannelEntry 8 } applPastChannelLastReadTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 53] RFC 2564 Application Management MIB May 1999 DESCRIPTION "This attribute reports the time of the most recent read request made by this running application element or service instance regardless of completion status, for this former channel. If no read requests have been made , the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applPastChannelEntry 9 } applPastChannelWriteRequests OBJECT-TYPE SYNTAX Unsigned64TC UNITS "write requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastChannelWriteRequests attribute reports the number of write requests, regardless of completion status, made by this running application element or service instance for this former channel. Write requests are counted in terms of system calls, rather than API calls." ::= { applPastChannelEntry 10 } applPastChannelWriteReqsLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "write requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applPastChannelWriteRequests." ::= { applPastChannelEntry 11 } applPastChannelWriteFailures OBJECT-TYPE SYNTAX Unsigned32 UNITS "failed write requests" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of failed write requests." ::= { applPastChannelEntry 12 } Kalbfleisch, et al. Standards Track [Page 54] RFC 2564 Application Management MIB May 1999 applPastChannelBytesWritten OBJECT-TYPE SYNTAX Unsigned64TC UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute reports the number of bytes written to this former channel by this running application element or service instance. Only bytes successfully written (no errors reported by the API in use by the application) are included in this count." ::= { applPastChannelEntry 13 } applPastChannelBytesWritLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applPastChannelBytesWritten." ::= { applPastChannelEntry 14 } applPastChannelLastWriteTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastChannelLastWriteTime attribute reports the time of the most recent write request made by this running application element or service instance, regardless of completion status, for this former channel. If no write requests have been made the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applPastChannelEntry 15 } -- **************************************************************** -- -- applPastFileTable - information specific to former files -- -- **************************************************************** Kalbfleisch, et al. Standards Track [Page 55] RFC 2564 Application Management MIB May 1999 applPastFileTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplPastFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastFileTable supplements the applPastChannelTable for entries corresponding to channels which were files. The indexing structure is identical to applPastChannelTable. An entry exists in the applPastFileTable only if there is a corresponding (same index values) entry in the applPastChannelTable and if the channel was a file. Entries for closed files are removed when the corresponding entries are removed from the applPastChannelTable." ::= { applPastChannelGroup 3 } applPastFileEntry OBJECT-TYPE SYNTAX ApplPastFileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applPastFileEntry provides additional, file-specific information to complement the corresponding applPastChannelEntry for a channel which was a file." INDEX { applElmtOrSvc, applElmtOrSvcId, applPastChannelIndex } ::= { applPastFileTable 1 } ApplPastFileEntry ::= SEQUENCE { applPastFileName LongUtf8String, applPastFileSizeHigh Unsigned32, applPastFileSizeLow Unsigned32, applPastFileMode INTEGER } applPastFileName OBJECT-TYPE SYNTAX LongUtf8String MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the last known value of applOpenFileName before the channel was closed." ::= { applPastFileEntry 1 } Kalbfleisch, et al. Standards Track [Page 56] RFC 2564 Application Management MIB May 1999 applPastFileSizeHigh OBJECT-TYPE SYNTAX Unsigned32 UNITS "2^32 byte blocks" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the value of applOpenFileSizeHigh at the time this channel was closed. For example, for a file with a total size of 4,294,967,296 bytes, this attribute would have a value of 1; for a file with a total size of 4,294,967,295 bytes this attribute's value would be 0." ::= { applPastFileEntry 2 } applPastFileSizeLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the value of applOpenFileSizeLow at the time this channel was closed. For example, for a file with a total size of 4,294,967,296 bytes this attribute would have a value of 0; for a file with a total size of 4,294,967,295 bytes this attribute's value would be 4,294,967,295." ::= { applPastFileEntry 3 } applPastFileMode OBJECT-TYPE SYNTAX INTEGER { read(1), write(2), readWrite(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute records the value of applOpenFileMode at the time this channel was closed. " ::= { applPastFileEntry 4 } -- **************************************************************** -- -- applPastConTable - information specific to former connections -- -- **************************************************************** Kalbfleisch, et al. Standards Track [Page 57] RFC 2564 Application Management MIB May 1999 applPastConTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplPastConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastConTable supplements the applPastChannelTable for entries corresponding to channels which were connections. The indexing structure is identical to applPastChannelTable. An entry exists in the applPastConTable only if there is a corresponding (same index values) entry in the applPastChannelTable and if the channel was a connection. Entries for closed connections are removed when the corresponding entries are removed from the applPastChannelTable." ::= { applPastChannelGroup 4 } applPastConEntry OBJECT-TYPE SYNTAX ApplPastConEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applPastConEntry provides additional, connection-specific information to complement the corresponding applPastChannelEntry for a channel which was a connection." INDEX { applElmtOrSvc, applElmtOrSvcId, applPastChannelIndex } ::= { applPastConTable 1 } ApplPastConEntry ::= SEQUENCE { applPastConTransport TDomain, applPastConNearEndAddr ApplTAddress, applPastConNearEndpoint SnmpAdminString, applPastConFarEndAddr ApplTAddress, applPastConFarEndpoint SnmpAdminString, applPastConApplication SnmpAdminString } applPastConTransport OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 58] RFC 2564 Application Management MIB May 1999 DESCRIPTION "The applPastConTransport attribute identifies the transport protocol that was in use for this former connection. If the transport protocol could not be determined, the value { 0 0 } shall be used." DEFVAL { zeroDotZero } ::= { applPastConEntry 1 } applPastConNearEndAddr OBJECT-TYPE SYNTAX ApplTAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastConNearEndAddr attribute reports the transport address and port information for the near end of this former connection. If the information could not be determined, the value shall be a zero-length string." DEFVAL { "" } ::= { applPastConEntry 2 } applPastConNearEndpoint OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastConNearEndpoint attribute reports the fully-qualified domain name and port information for the near end of this former connection. The format of this attribute for TCP and UDP-based protocols is the fully-qualified domain name immediately followed by a colon which is immediately followed by the decimal representation of the port number. If the information could not be determined, the value shall be a zero-length string." DEFVAL { "" } ::= { applPastConEntry 3 } applPastConFarEndAddr OBJECT-TYPE SYNTAX ApplTAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastConFarEnd attribute reports the transport address and port information for the far end of this Kalbfleisch, et al. Standards Track [Page 59] RFC 2564 Application Management MIB May 1999 former connection. If not known, as in the case of a connectionless transport, the value of this attribute shall be a zero-length string." DEFVAL { "" } ::= { applPastConEntry 4 } applPastConFarEndpoint OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastConFarEndpoint attribute reports the transport address and port information for the far end of this former connection. The format of this attribute for TCP and UDP-based protocols is the fully-qualified domain name immediately followed by a colon which is immediately followed by the decimal representation of the port number. If not known, as in the case of a connectionless transport, the value of this attribute shall be a zero-length string." DEFVAL { "" } ::= { applPastConEntry 5 } applPastConApplication OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastConApplication attribute identifies the application layer protocol that was in use. Where possible, the values defined in [13] shall be used. If not known, the value of this attribute shall be a zero-length string." DEFVAL { "" } ::= { applPastConEntry 6 } -- **************************************************************** -- -- applPastTransStreamTable - historical -- information for transaction stream monitoring -- -- **************************************************************** Kalbfleisch, et al. Standards Track [Page 60] RFC 2564 Application Management MIB May 1999 applPastTransStreamTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplPastTransStreamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastTransStreamTable contains common information for historical transaction statistics." ::= { applPastChannelGroup 5 } applPastTransStreamEntry OBJECT-TYPE SYNTAX ApplPastTransStreamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applPastTransStreamEntry contains information for a single former transaction stream. A transaction stream could have been a network connection, file, or other source of transactions." INDEX { applElmtOrSvc, applElmtOrSvcId, applPastChannelIndex } ::= { applPastTransStreamTable 1 } ApplPastTransStreamEntry ::= SEQUENCE { applPastTransStreamDescr SnmpAdminString, applPastTransStreamUnitOfWork SnmpAdminString, applPastTransStreamInvokes Unsigned64TC, applPastTransStreamInvokesLow Unsigned32, applPastTransStreamInvCumTimes Unsigned32, applPastTransStreamInvRspTimes Unsigned32, applPastTransStreamPerforms Unsigned64TC, applPastTransStreamPerformsLow Unsigned32, applPastTransStreamPrfCumTimes Unsigned32, applPastTransStreamPrfRspTimes Unsigned32 } applPastTransStreamDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransStreamDescr attribute provides a human-readable description of this transaction stream. If no descriptive information is available, this attribute's value shall be a zero-length string." DEFVAL { "" } ::= { applPastTransStreamEntry 1 } Kalbfleisch, et al. Standards Track [Page 61] RFC 2564 Application Management MIB May 1999 applPastTransStreamUnitOfWork OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransStreamUnitOfWork attribute provides a human-readable definition of what the unit of work is for this transaction stream. If no descriptive information is available, this attribute's value shall be a zero-length string." DEFVAL { "" } ::= { applPastTransStreamEntry 2 } applPastTransStreamInvokes OBJECT-TYPE SYNTAX Unsigned64TC UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "Cumulative count of requests / invocations issued for this transaction stream when it was active." ::= { applPastTransStreamEntry 3 } applPastTransStreamInvokesLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "This object corresponds to the low thirty-two bits of applPastTransStreamInvokes." ::= { applPastTransStreamEntry 4 } applPastTransStreamInvCumTimes OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransStreamInvCumTimes attribute reports the cumulative sum of the lengths of the intervals times measured between the transmission of requests and the receipt of (the first of) the corresponding response(s)." ::= { applPastTransStreamEntry 5 } Kalbfleisch, et al. Standards Track [Page 62] RFC 2564 Application Management MIB May 1999 applPastTransStreamInvRspTimes OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransStreamInvRspTimes attribute reports the cumulative sum of the lengths of the intervals measured between the receipt of the first and last of multiple responses to a request. For transaction streams which do not permit multiple responses to a single request, this attribute will be zero." ::= { applPastTransStreamEntry 6 } applPastTransStreamPerforms OBJECT-TYPE SYNTAX Unsigned64TC UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of transactions performed." ::= { applPastTransStreamEntry 7 } applPastTransStreamPerformsLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "This objecy reports the low thirty-two bits of applPastTransStreamPerforms." ::= { applPastTransStreamEntry 8 } applPastTransStreamPrfCumTimes OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransStreamPrfCumTimes attribute reports the cumulative sum of the lengths of the intervals measured between receipt of requests and the transmission of the corresponding responses." ::= { applPastTransStreamEntry 9 } Kalbfleisch, et al. Standards Track [Page 63] RFC 2564 Application Management MIB May 1999 applPastTransStreamPrfRspTimes OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For each transaction performed, the elapsed time between when the first response is enqueued and when the last response is enqueued is added to this cumulative sum. For single-response protocols, the value of applPastTransStreamPrfRspTimes will be zero." ::= { applPastTransStreamEntry 10 } -- **************************************************************** -- -- applPastTransFlowTable -- -- **************************************************************** applPastTransFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplPastTransFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastTransFlowTable contains entries, organized by application instance or running application element, direction of flow, and type (request/response) for each former transaction stream. The simple model of a transaction used here looks like this: invoker | Request | performer | - - - - - - > | | | | Response | | < - - - - - - | | | Since in some protocols it is possible for an entity to take on both the invoker and performer roles, information here is accumulated for transmitted and received requests, as well as for transmitted and received responses. Counts are maintained for both transactions and bytes transferred." ::= { applPastChannelGroup 6 } Kalbfleisch, et al. Standards Track [Page 64] RFC 2564 Application Management MIB May 1999 applPastTransFlowEntry OBJECT-TYPE SYNTAX ApplPastTransFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applPastTransFlowEntry records transaction throughput information for requests or response in a particular direction (transmit / receive) for a transaction stream. Entries in this table correspond to those in the applPastTransStreamTable with identical values for the applElmtOrSvc, applElmtOrSvcId, and the applPastChannelIndex." INDEX { applElmtOrSvc, applElmtOrSvcId, applPastChannelIndex, applPastTransFlowDirection, applPastTransFlowReqRsp } ::= { applPastTransFlowTable 1 } ApplPastTransFlowEntry ::= SEQUENCE { applPastTransFlowDirection INTEGER, applPastTransFlowReqRsp INTEGER, applPastTransFlowTrans Unsigned64TC, applPastTransFlowTransLow Unsigned32, applPastTransFlowBytes Unsigned64TC, applPastTransFlowBytesLow Unsigned32, applPastTransFlowTime DateAndTime } applPastTransFlowDirection OBJECT-TYPE SYNTAX INTEGER { transmit(1), receive(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastTransFlowDirection index serves to identify an entry as containing information pertaining to the transmit (1) or receive (2) flow of a past transaction stream. This index corresponds to applTransactFlowDirection." ::= { applPastTransFlowEntry 1 } applPastTransFlowReqRsp OBJECT-TYPE SYNTAX INTEGER { request(1), response(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION Kalbfleisch, et al. Standards Track [Page 65] RFC 2564 Application Management MIB May 1999 "The value of the applPastTransFlowReqRsp index indicates whether this entry contains information on requests (1), or responses (2). This index corresponds to applTransactFlowReqRsp." ::= { applPastTransFlowEntry 2 } applPastTransFlowTrans OBJECT-TYPE SYNTAX Unsigned64TC UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransFlowTrans attribute reports the number of request/response (as indicated by the applPastTransFlowReqRsp index) transactions received/generated (as indicated by the applPastTransFlowDirection index) handled on this transaction stream." ::= { applPastTransFlowEntry 3 } applPastTransFlowTransLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applPastTransFlowTrans." ::= { applPastTransFlowEntry 4 } applPastTransFlowBytes OBJECT-TYPE SYNTAX Unsigned64TC UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransFlowBytes attribute reports the number of request/response (as indicated by the applPastTransFlowReqRsp index) bytes received/generated (as indicated by the applPastTransFlowDirection index) handled on this transaction stream. All application layer bytes are included in this count, including any application layer wrappers, headers, or other overhead." ::= { applPastTransFlowEntry 5 } Kalbfleisch, et al. Standards Track [Page 66] RFC 2564 Application Management MIB May 1999 applPastTransFlowBytesLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute corresponds to the low thirty-two bits of applPastTransFlowBytes." ::= { applPastTransFlowEntry 6 } applPastTransFlowTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransFlowTime attribute records the time of the processing (receipt or transmission as indicated by the applPastTransFlowDirection index) of the last request/response (as indicated by the applPastTransFlowReqRsp index) on this transaction stream. If no requests/responses been received/transmitted by this entity over this transaction stream, the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applPastTransFlowEntry 7 } -- **************************************************************** -- -- applPastTransKindTable - transaction statistics broken down -- according to the kinds of transactions in each direction -- for a transaction stream. -- -- **************************************************************** applPastTransKindTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplPastTransKindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastTransKindTable provides transaction statistics broken down by kinds of transaction. The definition of the kinds of transactions is specific to the application protocol in use, and may be documented in the form of an applicability statement. " ::= { applPastChannelGroup 7 } Kalbfleisch, et al. Standards Track [Page 67] RFC 2564 Application Management MIB May 1999 applPastTransKindEntry OBJECT-TYPE SYNTAX ApplPastTransKindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applPastTransKindEntry reports historical data for a specific service instance or running application element's use of a specific transaction stream in a particular direction in requests or responses (as indicated by the applPastTransFlowReqRsp index) broken down by transaction kind, as indicated by the applPastTransKind index." INDEX { applElmtOrSvc, applElmtOrSvcId, applPastChannelIndex, applPastTransFlowDirection, applPastTransFlowReqRsp, applPastTransKind } ::= { applPastTransKindTable 1 } ApplPastTransKindEntry ::= SEQUENCE { applPastTransKind SnmpAdminString, applPastTransKindTrans Unsigned64TC, applPastTransKindTransLow Unsigned32, applPastTransKindBytes Unsigned64TC, applPastTransKindBytesLow Unsigned32, applPastTransKindTime DateAndTime } applPastTransKind OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1 .. 32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The applPastTransKind index is the human-readable identifier for a particular transaction kind within the context of an application protocol. The values to be used for a particular protocol may be identified in an applicability statement. This index corresponds to applTransactKind." ::= { applPastTransKindEntry 1 } applPastTransKindTrans OBJECT-TYPE SYNTAX Unsigned64TC UNITS "transactions" MAX-ACCESS read-only STATUS current Kalbfleisch, et al. Standards Track [Page 68] RFC 2564 Application Management MIB May 1999 DESCRIPTION "For this transaction stream, this attribute records the total number of transactions of the type identified by the indexes. The type is characterized according to the receive/transmit direction (applPastTransFlowDirecton), whether it was a request or a response (applPastTransFlowReqRsp), and the protocol-specific transaction kind (applPastTransKind). stream for this transaction kind." ::= { applPastTransKindEntry 2 } applPastTransKindTransLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "transactions" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransKindTransLow attribute reports the low thirty-two bits of applPastTransKindTrans." ::= { applPastTransKindEntry 3 } applPastTransKindBytes OBJECT-TYPE SYNTAX Unsigned64TC UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "For this transaction stream and transaction kind, the applPastTransKindBytes attribute reports the number of bytes received or generated (as indicated by the applPastTransFlowDirection index) in requests or responses (as indicated by the applPastTransFlowReqRsp index). All application layer bytes are included in this count, including any application layer wrappers, headers, or other overhead." ::= { applPastTransKindEntry 4 } applPastTransKindBytesLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransKindBytesLow attribute corresponds to the low thirty-two bits of applPastTransKindBytes." ::= { applPastTransKindEntry 5 } Kalbfleisch, et al. Standards Track [Page 69] RFC 2564 Application Management MIB May 1999 applPastTransKindTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The applPastTransKindTime attribute records the time of the processing (receipt or transmission as indicated by the applPastTransFlowDirection index) of the last request/response (as indicated by the applPastTransFlowReqRsp index) of this kind of transaction on this transaction stream. If no requests/responses of this kind were received/transmitted over this transaction stream, the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applPastTransKindEntry 6 } -- **************************************************************** -- -- applElmtRunControlGroup - monitor and control running -- application elements -- -- **************************************************************** applElmtRunStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplElmtRunStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides information on running application elements, complementing information available in the correspondingly indexed sysApplElmtRunTable [31]." ::= { applElmtRunControlGroup 1 } applElmtRunStatusEntry OBJECT-TYPE SYNTAX ApplElmtRunStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applElmtRunStatusEntry contains information to support the control and monitoring of a single running application element." INDEX { sysApplElmtRunIndex } ::= { applElmtRunStatusTable 1 } Kalbfleisch, et al. Standards Track [Page 70] RFC 2564 Application Management MIB May 1999 ApplElmtRunStatusEntry ::= SEQUENCE { applElmtRunStatusSuspended TruthValue, applElmtRunStatusHeapUsage Unsigned32, applElmtRunStatusOpenConnections Unsigned32, applElmtRunStatusOpenFiles Gauge32, applElmtRunStatusLastErrorMsg SnmpAdminString, applElmtRunStatusLastErrorTime DateAndTime } applElmtRunStatusSuspended OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The applElmtRunStatusSuspended attribute reports whether processing by this running application element has been suspended, whether by management request or by other means." ::= { applElmtRunStatusEntry 1 } applElmtRunStatusHeapUsage OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The applElmtRunStatusHeapUsage reports the current approximate heap usage by this running application element." ::= { applElmtRunStatusEntry 2 } applElmtRunStatusOpenConnections OBJECT-TYPE SYNTAX Unsigned32 UNITS "connections" MAX-ACCESS read-only STATUS current DESCRIPTION "The applElmtRunStatusOpenConnections attribute reports the current number of open connections in use by this running application element." ::= { applElmtRunStatusEntry 3 } applElmtRunStatusOpenFiles OBJECT-TYPE SYNTAX Gauge32 UNITS "files" MAX-ACCESS read-only STATUS current DESCRIPTION "The applElmtRunStatusOpenFiles attribute reports the Kalbfleisch, et al. Standards Track [Page 71] RFC 2564 Application Management MIB May 1999 current number of open files in use by this running application element." ::= { applElmtRunStatusEntry 4 } applElmtRunStatusLastErrorMsg OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The applElmtRunStatusLastErrorMessage attribute reports the most recent error message (typically written to stderr or a system error logging facility) from this running application element. If no such message has yet been generated, the value of this attribute shall be a zero-length string." DEFVAL { "" } ::= { applElmtRunStatusEntry 5 } applElmtRunStatusLastErrorTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The applElmtRunStatusLastErrorTime attribute reports the time of the most recent error message in applElmtRunStatusLastErrorMsg. If no such message has yet been generated, the value of this attribute shall be '0000000000000000'H " DEFVAL { '0000000000000000'H } ::= { applElmtRunStatusEntry 6 } -- **************************************************************** -- -- applElmtRunControlTable - control running application -- elements -- -- **************************************************************** applElmtRunControlTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplElmtRunControlEntry MAX-ACCESS not-accessible STATUS current Kalbfleisch, et al. Standards Track [Page 72] RFC 2564 Application Management MIB May 1999 DESCRIPTION "This table provides the ability to control application elements, complementing information available in the correspondingly indexed sysApplElmtRunTable [31]." ::= { applElmtRunControlGroup 2 } applElmtRunControlEntry OBJECT-TYPE SYNTAX ApplElmtRunControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An applElmtRunControlEntry contains information to support the control of a single running application element." INDEX { sysApplElmtRunIndex } ::= { applElmtRunControlTable 1 } ApplElmtRunControlEntry ::= SEQUENCE { applElmtRunControlSuspend TruthValue, applElmtRunControlReconfigure TestAndIncr, applElmtRunControlTerminate TruthValue } applElmtRunControlSuspend OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this variable to 'true' requests the suspension of processing by this running application element. Setting this variable to 'false' requests that processing be resumed. The effect, if any, will be reported by the applElmtRunStatusSuspended attribute." DEFVAL { false } ::= { applElmtRunControlEntry 1 } applElmtRunControlReconfigure OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "Changing the value of this variable requests that the running application element re-load its configuration (like SIGHUP for many UNIX-based daemons). Note that completion of a SET on this object only implies that configuration reload was initiated, not necessarily that the reload has been completed." ::= { applElmtRunControlEntry 2 } Kalbfleisch, et al. Standards Track [Page 73] RFC 2564 Application Management MIB May 1999 applElmtRunControlTerminate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting the value of applElmtRunControlTerminate to 'true' requests that the running application element terminate processing and exit in an orderly manner. This is a 'polite' shutdown request. When read, this object's value will be 'false' except when orderly termination is in progress. Note that completion of a SET on this object only implies that termination was initiated, not necessarily that the termination has been completed." DEFVAL { false } ::= { applElmtRunControlEntry 3 } -- **************************************************************** -- -- Conformance requirements -- -- **************************************************************** applicationMibGroups OBJECT IDENTIFIER ::= { applicationMibConformance 1} applicationMonitorGroup OBJECT-GROUP OBJECTS { applSrvInstQual, applSrvName, applSrvIndex, applSrvInstance, applOpenChannelOpenTime, applOpenChannelReadRequestsLow, applOpenChannelReadFailures, applOpenChannelBytesReadLow, applOpenChannelLastReadTime, applOpenChannelWriteRequestsLow, applOpenChannelWriteFailures, applOpenChannelBytesWrittenLow, applOpenChannelLastWriteTime, applOpenFileName, applOpenFileSizeHigh, applOpenFileSizeLow, applOpenFileMode, applOpenConnectionTransport, Kalbfleisch, et al. Standards Track [Page 74] RFC 2564 Application Management MIB May 1999 applOpenConnectionNearEndAddr, applOpenConnectionNearEndpoint, applOpenConnectionFarEndAddr, applOpenConnectionFarEndpoint, applOpenConnectionApplication } STATUS current DESCRIPTION "This group represents the basic capabilities of this MIB." ::= { applicationMibGroups 1 } applicationFastMonitorGroup OBJECT-GROUP OBJECTS { applOpenChannelReadRequests, applOpenChannelBytesRead, applOpenChannelWriteRequests, applOpenChannelBytesWritten } STATUS current DESCRIPTION "This group comprises 64-bit counters mandatory in high-throughput environments, where 32-bit counters could wrap in less than an hour." ::= { applicationMibGroups 2 } applicationTransactGroup OBJECT-GROUP OBJECTS { applTransactStreamDescr, applTransactStreamUnitOfWork, applTransactStreamInvokesLow, applTransactStreamInvCumTimes, applTransactStreamInvRspTimes, applTransactStreamPerformsLow, applTransactStreamPrfCumTimes, applTransactStreamPrfRspTimes, applTransactFlowTransLow, applTransactFlowBytesLow, applTransactFlowTime, applTransactKindTransLow, applTransactKindBytesLow, applTransactKindTime } STATUS current DESCRIPTION "This group comprises objects appropriate from monitoring transaction-structured flows." ::= { applicationMibGroups 3 } applicationFastTransactGroup OBJECT-GROUP OBJECTS { applTransactStreamInvokes, applTransactStreamPerforms, applTransactFlowTrans, applTransactFlowBytes, Kalbfleisch, et al. Standards Track [Page 75] RFC 2564 Application Management MIB May 1999 applTransactKindTrans, applTransactKindBytes } STATUS current DESCRIPTION "This group comprises 64-bit transaction counters required in high-throughput environments, where 32-bit counters could wrap in less than an hour." ::= { applicationMibGroups 4 } applicationHistoryGroup OBJECT-GROUP OBJECTS { applPastChannelControlCollect, applPastChannelControlMaxRows, applPastChannelControlTimeLimit, applPastChannelControlRemItems, applPastChannelOpenTime, applPastChannelCloseTime, applPastChannelReadReqsLow, applPastChannelReadFailures, applPastChannelBytesReadLow, applPastChannelLastReadTime, applPastChannelWriteReqsLow, applPastChannelWriteFailures, applPastChannelBytesWritLow, applPastChannelLastWriteTime, applPastFileName, applPastFileSizeHigh, applPastFileSizeLow, applPastFileMode, applPastConTransport, applPastConNearEndAddr, applPastConNearEndpoint, applPastConFarEndAddr, applPastConFarEndpoint, applPastConApplication} STATUS current DESCRIPTION "This group models basic historical data." ::= { applicationMibGroups 5 } applicationFastHistoryGroup OBJECT-GROUP OBJECTS { applPastChannelReadRequests, applPastChannelBytesRead, applPastChannelWriteRequests, applPastChannelBytesWritten} STATUS current Kalbfleisch, et al. Standards Track [Page 76] RFC 2564 Application Management MIB May 1999 DESCRIPTION "This group comprises additional 64-bit objects required for recording historical data in high-volume environments, where a 32-bit integer would be insufficient." ::= { applicationMibGroups 6 } applicationTransHistoryGroup OBJECT-GROUP OBJECTS { applPastTransStreamDescr, applPastTransStreamUnitOfWork, applPastTransStreamInvokesLow, applPastTransStreamInvCumTimes, applPastTransStreamInvRspTimes, applPastTransStreamPerformsLow, applPastTransStreamPrfCumTimes, applPastTransStreamPrfRspTimes, applPastTransFlowTransLow, applPastTransFlowBytesLow, applPastTransFlowTime, applPastTransKindTransLow, applPastTransKindBytesLow, applPastTransKindTime } STATUS current DESCRIPTION "This group represents historical data for transaction- structured information streams." ::= { applicationMibGroups 7 } applicationFastTransHistoryGroup OBJECT-GROUP OBJECTS { applPastTransFlowTrans, applPastTransFlowBytes, applPastTransKindTrans, applPastTransKindBytes, applPastTransStreamPerforms, applPastTransStreamInvokes } STATUS current DESCRIPTION "This group contains 64-bit objects required for historical records on high-volume transaction-structured streams, where 32-bit integers would be insufficient." ::= { applicationMibGroups 8 } applicationRunGroup OBJECT-GROUP OBJECTS { applElmtRunStatusSuspended, applElmtRunStatusHeapUsage, applElmtRunStatusOpenConnections, applElmtRunStatusOpenFiles, applElmtRunStatusLastErrorMsg, applElmtRunStatusLastErrorTime, Kalbfleisch, et al. Standards Track [Page 77] RFC 2564 Application Management MIB May 1999 applElmtRunControlSuspend, applElmtRunControlReconfigure, applElmtRunControlTerminate } STATUS current DESCRIPTION "This group represents extensions to the system application MIB." ::= { applicationMibGroups 9 } applicationMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the application MIB." MODULE MANDATORY-GROUPS { applicationMonitorGroup, applicationHistoryGroup, applicationRunGroup } OBJECT applPastChannelControlCollect MIN-ACCESS read-only DESCRIPTION "This object should be limited to read-only access in environments with inadequate security." OBJECT applPastChannelControlMaxRows MIN-ACCESS read-only DESCRIPTION "This object should be limited to read-only access in environments with inadequate security." OBJECT applPastChannelControlTimeLimit MIN-ACCESS read-only DESCRIPTION "This object should be limited to read-only access in environments with inadequate security." OBJECT applElmtRunControlSuspend MIN-ACCESS read-only DESCRIPTION "This object should be limited to read-only access in environments with inadequate security." Kalbfleisch, et al. Standards Track [Page 78] RFC 2564 Application Management MIB May 1999 OBJECT applElmtRunControlReconfigure MIN-ACCESS read-only DESCRIPTION "This object should be limited to read-only access in environments with inadequate security." OBJECT applElmtRunControlTerminate MIN-ACCESS read-only DESCRIPTION "This object should be limited to read-only access in environments with inadequate security." GROUP applicationTransactGroup DESCRIPTION "The applicationTransactGroup is required when the information stream processed has a transaction structure. " GROUP applicationTransHistoryGroup DESCRIPTION "The applicationTransHistoryGroup must be implemented if applicationTransactGroup and applicationHistoryGroup are implemented." GROUP applicationFastMonitorGroup DESCRIPTION "The applicationFastMonitorGroup is mandatory when the applicationMonitorGroup is implemented and its counts group may exceed what can be represented in 32 bits." GROUP applicationFastTransactGroup DESCRIPTION "The applicationFastTransactGroup is mandatory when the applicationTransactGroup is implemented and its counts may exceed what can be represented in 32 bits." GROUP applicationFastHistoryGroup DESCRIPTION "The applicationFastHistoryGroup is mandatory when the applicationHistoryGroup is implemented and its counts may exceed what can be represented in 32 bits." Kalbfleisch, et al. Standards Track [Page 79] RFC 2564 Application Management MIB May 1999 GROUP applicationFastTransHistoryGroup DESCRIPTION "The applicationFastTransHistoryGroup is mandatory when the applicationTransHistoryGroup is implemented and its counts may exceed what can be represented in 32 bits." ::= { applicationMibConformance 2 } END 6. Implementation Issues Unlike the system application MIB [31], in many environments support for much of this MIB requires instrumentation built into the managed resource. Some tables may be implemented by a single monitor process; for others, the implementation may be distributed within the managed system with the resources being managed. As a practical matter, this means that the management infrastructure of the managed system must support different subagents taking responsibility for different rows of a single table. This can be supported by AgentX [25], as well as some other subagent protocols such as [8], [9], and [11]. The sysApplRunElmtIndex is the key connection between this MIB and the systems application MIB. Implementations of these two MIBs intended to run concurrently on a given platform must employ a consistent policy for assigning this value to running application elements. Some of the objects defined in this MIB may carry a high run-time cost in some environments. For example, tracking transaction elapsed time could be expensive if it required two kernel calls (start and finish) per transaction. Similarly, maintaining tables of per- transaction information, rather than aggregating information by transaction type or transaction stream, could have significant storage and performance impacts. Unless a collision-free mechanism for allocating service instance indexes is in place, the structure of the service-level tables makes an index-reservation mechanism necessary. AgentX [25] is an example of a subagent protocol capable of satisfying this requirement. 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in Kalbfleisch, et al. Standards Track [Page 80] RFC 2564 Application Management MIB May 1999 this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Acknowledgements This document was produced by the Application MIB working group. The editor gratefully acknowledges the comments and contributions of the following individuals: Harrie Hazewinkel Carl Kalbfleisch Cheryl Krupczak David Partain Jon Saperia Juergen Schoenwaelder Kenneth White 9. Security Considerations By making potentially sensitive information externally accessible, the capabilities supported by the MIB have the potential of becoming security problems. How security fits into SNMP frameworks is described in [26], and a specific access control model is described in [30]. The tables in this MIB are organized to separate sensitive control capabilities from less sensitive usage information. For example, the objects to control application suspend/resume are separated from those to handle reconfiguration, which in turn are distinct from those for termination. This recognizes the need to support configurations where the level of authorization needed by a manager to do a "reconfigure" might be substantially less than the level needed to terminate an application element. By keeping these in Kalbfleisch, et al. Standards Track [Page 81] RFC 2564 Application Management MIB May 1999 separate columns, we make it possible to set up access control that allows, for example, "reconfigure" but not "kill". The MIB is structured to be useful for managers with read-only access rights. In some environments, it may be approprate to restrict even read-only access to these MIBs. The capabilities supported by this MIB include several that may be of value to a security administrator. These include the ability to monitor the level of usage of a given application, and to check the integrity of application components. 10. References [1] ARM Working Group, "Application Response Measurement (ARM) API Guide, Version 2", September, 1997. [2] IEEE P1387.2, POSIX System Administration - Part 2: Software Administration. (Draft) [3] ITU-T Recommendation X.744 | ISO/IEC IS 10164-18:1996, Information Technology - Open Systems Interconnection - Systems Management: Software Management Function, 1996. [4] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [5] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [6] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [7] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [8] Rose, M., "SNMP MUX Protocol and MIB", RFC 1227, May 1991. [9] Carpenter, G. and B. Wijnen, "SNMP-DPI Simple Network Management Protocol Distributed Program Interface", RFC 1228, May 1991. [10] Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514, September 1993. [11] Carpenter, G., Curran, K., Sehgal, A., Waters, G. and B. Wijnen, "Simple Network Management Protocol Distributed Protocol Interface Version 2.0", RFC 1592, March 1994. Kalbfleisch, et al. Standards Track [Page 82] RFC 2564 Application Management MIB May 1999 [12] Brower, D., Purvy, R., Daniel, A., Sinykin, M. and J. Smith, "Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2", RFC 1697, August 1994. [13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [15] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [16] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [17] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [18] 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. [19] 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. [20] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2", RFC 2037, October 1996. [21] Kalbfleisch, C., "Applicability of Standards Track MIBs to Management of World Wide Web Servers", RFC 2039, November 1996. [22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [23] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC 2248, January 1998. [24] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2249, January 1998. [25] Daniele, M., Francisco, D. and B. Wijnen, "Agent Extensibility (AgentX) Protocol", RFC 2257, January, 1998. [26] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Kalbfleisch, et al. Standards Track [Page 83] RFC 2564 Application Management MIB May 1999 describing SNMP Management Frameworks", RFC 2571, May 1999. [27] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, May 1999. [28] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, May 1999. [29] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, May 1999. [30] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, May 1999. [31] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. 11. Authors' Addresses Carl Kalbfleisch Verio, Inc. 1950 Stemmons Freeway 2004 INFOMART Dallas, TX 75207 USA Phone: +1 972-238-8303 Fax: +1 972-238-0268 EMail: cwk@verio.net Cheryl Krupczak Empire Technologies, Inc. 541 Tenth Street, NW Suite 169 Atlanta, GA 30318 USA Phone: +1 770-384-0184 EMail: cheryl@empiretech.com Kalbfleisch, et al. Standards Track [Page 84] RFC 2564 Application Management MIB May 1999 Randy Presuhn (Editor) BMC Software, Inc. 965 Stewart Drive Sunnyvale, CA 94086 USA Phone: +1 408-616-3100 Fax: +1 408-616-3101 EMail: randy_presuhn@bmc.com Jon Saperia IronBridge Networks 55 Hayden Avenue Lexington, MA 02173 USA Phone: +1 781-402-8029 Fax: +1 781-402-8090 EMail: saperia@mediaone.net Kalbfleisch, et al. Standards Track [Page 85] RFC 2564 Application Management MIB May 1999 12. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kalbfleisch, et al. Standards Track [Page 86] snmp-mibs-downloader-1.1/mibrfcs/rfc2578.txt0000644000000000000000000025741011402176071015600 0ustar Network Working Group Editors of this version: Request for Comments: 2578 K. McCloghrie STD: 58 Cisco Systems Obsoletes: 1902 D. Perkins Category: Standards Track SNMPinfo J. Schoenwaelder TU Braunschweig Authors of previous version: J. Case SNMP Research K. McCloghrie Cisco Systems M. Rose First Virtual Holdings S. Waldbusser International Network Services April 1999 Structure of Management Information Version 2 (SMIv2) 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Introduction .................................................3 1.1 A Note on Terminology ......................................4 2 Definitions ..................................................4 2.1 The MODULE-IDENTITY macro ..................................5 2.2 Object Names and Syntaxes ..................................5 2.3 The OBJECT-TYPE macro ......................................8 2.5 The NOTIFICATION-TYPE macro ...............................10 2.6 Administrative Identifiers ................................11 3 Information Modules .........................................11 3.1 Macro Invocation ..........................................12 3.1.1 Textual Values and Strings ..............................13 McCloghrie, et al. Standards Track [Page 1] RFC 2578 SMIv2 April 1999 3.2 IMPORTing Symbols .........................................14 3.3 Exporting Symbols .........................................14 3.4 ASN.1 Comments ............................................14 3.5 OBJECT IDENTIFIER values ..................................15 3.6 OBJECT IDENTIFIER usage ...................................15 3.7 Reserved Keywords .........................................16 4 Naming Hierarchy ............................................16 5 Mapping of the MODULE-IDENTITY macro ........................17 5.1 Mapping of the LAST-UPDATED clause ........................17 5.2 Mapping of the ORGANIZATION clause ........................17 5.3 Mapping of the CONTACT-INFO clause ........................18 5.4 Mapping of the DESCRIPTION clause .........................18 5.5 Mapping of the REVISION clause ............................18 5.5.1 Mapping of the DESCRIPTION sub-clause ...................18 5.6 Mapping of the MODULE-IDENTITY value ......................18 5.7 Usage Example .............................................18 6 Mapping of the OBJECT-IDENTITY macro ........................19 6.1 Mapping of the STATUS clause ..............................19 6.2 Mapping of the DESCRIPTION clause .........................20 6.3 Mapping of the REFERENCE clause ...........................20 6.4 Mapping of the OBJECT-IDENTITY value ......................20 6.5 Usage Example .............................................20 7 Mapping of the OBJECT-TYPE macro ............................20 7.1 Mapping of the SYNTAX clause ..............................21 7.1.1 Integer32 and INTEGER ...................................21 7.1.2 OCTET STRING ............................................21 7.1.3 OBJECT IDENTIFIER .......................................22 7.1.4 The BITS construct ......................................22 7.1.5 IpAddress ...............................................22 7.1.6 Counter32 ...............................................23 7.1.7 Gauge32 .................................................23 7.1.8 TimeTicks ...............................................24 7.1.9 Opaque ..................................................24 7.1.10 Counter64 ..............................................24 7.1.11 Unsigned32 .............................................25 7.1.12 Conceptual Tables ......................................25 7.1.12.1 Creation and Deletion of Conceptual Rows .............26 7.2 Mapping of the UNITS clause ...............................26 7.3 Mapping of the MAX-ACCESS clause ..........................26 7.4 Mapping of the STATUS clause ..............................27 7.5 Mapping of the DESCRIPTION clause .........................27 7.6 Mapping of the REFERENCE clause ...........................27 7.7 Mapping of the INDEX clause ...............................27 7.8 Mapping of the AUGMENTS clause ............................29 7.8.1 Relation between INDEX and AUGMENTS clauses .............30 7.9 Mapping of the DEFVAL clause ..............................30 7.10 Mapping of the OBJECT-TYPE value .........................31 7.11 Usage Example ............................................32 McCloghrie, et al. Standards Track [Page 2] RFC 2578 SMIv2 April 1999 8 Mapping of the NOTIFICATION-TYPE macro ......................34 8.1 Mapping of the OBJECTS clause .............................34 8.2 Mapping of the STATUS clause ..............................34 8.3 Mapping of the DESCRIPTION clause .........................35 8.4 Mapping of the REFERENCE clause ...........................35 8.5 Mapping of the NOTIFICATION-TYPE value ....................35 8.6 Usage Example .............................................35 9 Refined Syntax ..............................................36 10 Extending an Information Module ............................37 10.1 Object Assignments .......................................37 10.2 Object Definitions .......................................38 10.3 Notification Definitions .................................39 11 Appendix A: Detailed Sub-typing Rules ......................40 11.1 Syntax Rules .............................................40 11.2 Examples .................................................41 12 Security Considerations ....................................41 13 Editors' Addresses .........................................41 14 References .................................................42 15 Full Copyright Statement ...................................43 1. Introduction Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. The SMI is divided into three parts: module definitions, object definitions, and, notification definitions. (1) Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module. (2) Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object. (3) Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification. McCloghrie, et al. Standards Track [Page 3] RFC 2578 SMIv2 April 1999 1.1. A Note on Terminology For the purpose of exposition, the original Structure of Management Information, as described in RFCs 1155 (STD 16), 1212 (STD 16), and RFC 1215, is termed the SMI version 1 (SMIv1). The current version of the Structure of Management Information is termed SMI version 2 (SMIv2). 2. Definitions SNMPv2-SMI DEFINITIONS ::= BEGIN -- the path to the root org OBJECT IDENTIFIER ::= { iso 3 } -- "iso" = 1 dod OBJECT IDENTIFIER ::= { org 6 } internet OBJECT IDENTIFIER ::= { dod 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } transmission OBJECT IDENTIFIER ::= { mib-2 10 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } security OBJECT IDENTIFIER ::= { internet 5 } snmpV2 OBJECT IDENTIFIER ::= { internet 6 } -- transport domains snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 } -- transport proxies snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 } -- module identities snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 } -- Extended UTCTime, to allow dates with four-digit years -- (Note that this definition of ExtUTCTime is not to be IMPORTed -- by MIB modules.) ExtUTCTime ::= OCTET STRING(SIZE(11 | 13)) -- format is YYMMDDHHMMZ or YYYYMMDDHHMMZ McCloghrie, et al. Standards Track [Page 4] RFC 2578 SMIv2 April 1999 -- where: YY - last two digits of year (only years -- between 1900-1999) -- YYYY - last four digits of the year (any year) -- MM - month (01 through 12) -- DD - day of month (01 through 31) -- HH - hours (00 through 23) -- MM - minutes (00 through 59) -- Z - denotes GMT (the ASCII character Z) -- -- For example, "9502192015Z" and "199502192015Z" represent -- 8:15pm GMT on 19 February 1995. Years after 1999 must use -- the four digit year format. Years 1900-1999 may use the -- two or four digit format. -- definitions for information modules MODULE-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= "LAST-UPDATED" value(Update ExtUTCTime) "ORGANIZATION" Text "CONTACT-INFO" Text "DESCRIPTION" Text RevisionPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) RevisionPart ::= Revisions | empty Revisions ::= Revision | Revisions Revision Revision ::= "REVISION" value(Update ExtUTCTime) "DESCRIPTION" Text -- a character string as defined in section 3.1.1 Text ::= value(IA5String) END OBJECT-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text McCloghrie, et al. Standards Track [Page 5] RFC 2578 SMIv2 April 1999 ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- a character string as defined in section 3.1.1 Text ::= value(IA5String) END -- names of objects -- (Note that these definitions of ObjectName and NotificationName -- are not to be IMPORTed by MIB modules.) ObjectName ::= OBJECT IDENTIFIER NotificationName ::= OBJECT IDENTIFIER -- syntax of objects -- the "base types" defined here are: -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER -- 8 application-defined types: Integer32, IpAddress, Counter32, -- Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64 ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that SEQUENCEs for conceptual tables and -- rows are not mentioned here... application-wide ApplicationSyntax } McCloghrie, et al. Standards Track [Page 6] RFC 2578 SMIv2 April 1999 -- built-in ASN.1 types SimpleSyntax ::= CHOICE { -- INTEGERs with a more restrictive range -- may also be used integer-value -- includes Integer32 INTEGER (-2147483648..2147483647), -- OCTET STRINGs with a more restrictive size -- may also be used string-value OCTET STRING (SIZE (0..65535)), objectID-value OBJECT IDENTIFIER } -- indistinguishable from INTEGER, but never needs more than -- 32-bits for a two's complement representation Integer32 ::= INTEGER (-2147483648..2147483647) -- application-wide types ApplicationSyntax ::= CHOICE { ipAddress-value IpAddress, counter-value Counter32, timeticks-value TimeTicks, arbitrary-value Opaque, big-counter-value Counter64, unsigned-integer-value -- includes Gauge32 Unsigned32 } -- in network-byte order McCloghrie, et al. Standards Track [Page 7] RFC 2578 SMIv2 April 1999 -- (this is a tagged type for historical reasons) IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) -- this wraps Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) -- this doesn't wrap Gauge32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) -- an unsigned 32-bit quantity -- indistinguishable from Gauge32 Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) -- hundredths of seconds since an epoch TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) -- for backward-compatibility only Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING -- for counters that wrap in less than one hour with only 32 bits Counter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615) -- definition for objects OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" Syntax UnitsPart "MAX-ACCESS" Access "STATUS" Status "DESCRIPTION" Text ReferPart McCloghrie, et al. Standards Track [Page 8] RFC 2578 SMIv2 April 1999 IndexPart DefValPart VALUE NOTATION ::= value(VALUE ObjectName) Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative UnitsPart ::= "UNITS" Text | empty Access ::= "not-accessible" | "accessible-for-notify" | "read-only" | "read-write" | "read-create" Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty IndexPart ::= "INDEX" "{" IndexTypes "}" | "AUGMENTS" "{" Entry "}" | empty IndexTypes ::= IndexType | IndexTypes "," IndexType IndexType ::= "IMPLIED" Index | Index McCloghrie, et al. Standards Track [Page 9] RFC 2578 SMIv2 April 1999 Index ::= -- use the SYNTAX value of the -- correspondent OBJECT-TYPE invocation value(ObjectName) Entry ::= -- use the INDEX value of the -- correspondent OBJECT-TYPE invocation value(ObjectName) DefValPart ::= "DEFVAL" "{" Defvalue "}" | empty Defvalue ::= -- must be valid for the type specified in -- SYNTAX clause of same OBJECT-TYPE macro value(ObjectSyntax) | "{" BitsValue "}" BitsValue ::= BitNames | empty BitNames ::= BitName | BitNames "," BitName BitName ::= identifier -- a character string as defined in section 3.1.1 Text ::= value(IA5String) END -- definitions for notifications NOTIFICATION-TYPE MACRO ::= BEGIN TYPE NOTATION ::= ObjectsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE NotificationName) ObjectsPart ::= "OBJECTS" "{" Objects "}" | empty Objects ::= Object McCloghrie, et al. Standards Track [Page 10] RFC 2578 SMIv2 April 1999 | Objects "," Object Object ::= value(ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- a character string as defined in section 3.1.1 Text ::= value(IA5String) END -- definitions of administrative identifiers zeroDotZero OBJECT-IDENTITY STATUS current DESCRIPTION "A value used for null identifiers." ::= { 0 0 } END 3. Information Modules An "information module" is an ASN.1 module defining information relating to network management. The SMI describes how to use an adapted subset of ASN.1 (1988) to define an information module. Further, additional restrictions are placed on "standard" information modules. It is strongly recommended that "enterprise-specific" information modules also adhere to these restrictions. Typically, there are three kinds of information modules: (1) MIB modules, which contain definitions of inter-related managed objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros; (2) compliance statements for MIB modules, which make use of the MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and, (3) capability statements for agent implementations which make use of the AGENT-CAPABILITIES macros [2]. McCloghrie, et al. Standards Track [Page 11] RFC 2578 SMIv2 April 1999 This classification scheme does not imply a rigid taxonomy. For example, a "standard" information module will normally include definitions of managed objects and a compliance statement. Similarly, an "enterprise-specific" information module might include definitions of managed objects and a capability statement. Of course, a "standard" information module may not contain capability statements. The constructs of ASN.1 allowed in SMIv2 information modules include: the IMPORTS clause, value definitions for OBJECT IDENTIFIERs, type definitions for SEQUENCEs (with restrictions), ASN.1 type assignments of the restricted ASN.1 types allowed in SMIv2, and instances of ASN.1 macros defined in this document and its companion documents [2, 3]. Additional ASN.1 macros must not be defined in SMIv2 information modules. SMIv1 macros must not be used in SMIv2 information modules. The names of all standard information modules must be unique (but different versions of the same information module should have the same name). Developers of enterprise information modules are encouraged to choose names for their information modules that will have a low probability of colliding with standard or other enterprise information modules. An information module may not use the ASN.1 construct of placing an object identifier value between the module name and the "DEFINITIONS" keyword. For the purposes of this specification, an ASN.1 module name begins with an upper-case letter and continues with zero or more letters, digits, or hyphens, except that a hyphen can not be the last character, nor can there be two consecutive hyphens. All information modules start with exactly one invocation of the MODULE-IDENTITY macro, which provides contact information as well as revision history to distinguish between versions of the same information module. This invocation must appear immediately after any IMPORTs statements. 3.1. Macro Invocation Within an information module, each macro invocation appears as: ::= where corresponds to an ASN.1 identifier, names the macro being invoked, and and depend on the definition of the macro. (Note that this definition of a descriptor applies to all macros defined in this memo and in [2].) McCloghrie, et al. Standards Track [Page 12] RFC 2578 SMIv2 April 1999 For the purposes of this specification, an ASN.1 identifier consists of one or more letters or digits, and its initial character must be a lower-case letter. Note that hyphens are not allowed by this specification (except for use by information modules converted from SMIv1 which did allow hyphens). For all descriptors appearing in an information module, the descriptor shall be unique and mnemonic, and shall not exceed 64 characters in length. (However, descriptors longer than 32 characters are not recommended.) This promotes a common language for humans to use when discussing the information module and also facilitates simple table mappings for user-interfaces. The set of descriptors defined in all "standard" information modules shall be unique. Finally, by convention, if the descriptor refers to an object with a SYNTAX clause value of either Counter32 or Counter64, then the descriptor used for the object should denote plurality. 3.1.1. Textual Values and Strings Some clauses in a macro invocation may take a character string as a textual value (e.g., the DESCRIPTION clause). Other clauses take binary or hexadecimal strings (in any position where a non-negative number is allowed). A character string is preceded and followed by the quote character ("), and consists of an arbitrary number (possibly zero) of: - any 7-bit displayable ASCII characters except quote ("), - tab characters, - spaces, and - line terminator characters (\n or \r\n). The value of a character string is interpreted as ASCII. A binary string consists of a number (possibly zero) of zeros and ones preceded by a single (') and followed by either the pair ('B) or ('b), where the number is a multiple of eight. A hexadecimal string consists of an even number (possibly zero) of hexadecimal digits, preceded by a single (') and followed by either the pair ('H) or ('h). Digits specified via letters can be in upper or lower case. Note that ASN.1 comments can not be enclosed inside any of these types of strings. McCloghrie, et al. Standards Track [Page 13] RFC 2578 SMIv2 April 1999 3.2. IMPORTing Symbols To reference an external object, the IMPORTS statement must be used to identify both the descriptor and the module in which the descriptor is defined, where the module is identified by its ASN.1 module name. Note that when symbols from "enterprise-specific" information modules are referenced (e.g., a descriptor), there is the possibility of collision. As such, if different objects with the same descriptor are IMPORTed, then this ambiguity is resolved by prefixing the descriptor with the name of the information module and a dot ("."), i.e., "module.descriptor" (All descriptors must be unique within any information module.) Of course, this notation can be used to refer to objects even when there is no collision when IMPORTing symbols. Finally, if any of the ASN.1 named types and macros defined in this document, specifically: Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE- IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT- IDENTITY, TimeTicks, Unsigned32, or any of those defined in [2] or [3], are used in an information module, then they must be imported using the IMPORTS statement. However, the following must not be included in an IMPORTS statement: - named types defined by ASN.1 itself, specifically: INTEGER, OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type, - the BITS construct. 3.3. Exporting Symbols The ASN.1 EXPORTS statement is not allowed in SMIv2 information modules. All items defined in an information module are automatically exported. 3.4. ASN.1 Comments ASN.1 comments can be included in an information module. However, it is recommended that all substantive descriptions be placed within an appropriate DESCRIPTION clause. McCloghrie, et al. Standards Track [Page 14] RFC 2578 SMIv2 April 1999 ASN.1 comments commence with a pair of adjacent hyphens and end with the next pair of adjacent hyphens or at the end of the line, whichever occurs first. Comments ended by a pair of hyphens have the effect of a single space character. 3.5. OBJECT IDENTIFIER values An OBJECT IDENTIFIER value is an ordered list of non-negative numbers. For the SMIv2, each number in the list is referred to as a sub-identifier, there are at most 128 sub-identifiers in a value, and each sub-identifier has a maximum value of 2^32-1 (4294967295 decimal). All OBJECT IDENTIFIER values have at least two sub-identifiers, where the value of the first sub-identifier is one of the following well- known names: Value Name 0 ccitt 1 iso 2 joint-iso-ccitt (Note that this SMI does not recognize "new" well-known names, e.g., as defined when the CCITT became the ITU.) 3.6. OBJECT IDENTIFIER usage OBJECT IDENTIFIERs are used in information modules in two ways: (1) registration: the definition of a particular item is registered as a particular OBJECT IDENTIFIER value, and associated with a particular descriptor. After such a registration, the semantics thereby associated with the value are not allowed to change, the OBJECT IDENTIFIER can not be used for any other registration, and the descriptor can not be changed nor associated with any other registration. The following macros result in a registration: OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP, OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE, AGENT-CAPABILITIES. (2) assignment: a descriptor can be assigned to a particular OBJECT IDENTIFIER value. For this usage, the semantics associated with the OBJECT IDENTIFIER value is not allowed to change, and a descriptor assigned to a particular OBJECT IDENTIFIER value cannot subsequently be assigned to another. However, multiple descriptors can be assigned to the same OBJECT IDENTIFIER value. Such assignments are specified in the following manner: McCloghrie, et al. Standards Track [Page 15] RFC 2578 SMIv2 April 1999 mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213 fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 } barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 } Note while the above examples are legal, the following is not: dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 } A descriptor is allowed to be associated with both a registration and an assignment, providing both are associated with the same OBJECT IDENTIFIER value and semantics. 3.7. Reserved Keywords The following are reserved keywords which must not be used as descriptors or module names: ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS BEGIN BIT BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-INFO CREATION-REQUIRES Counter32 Counter64 DEFAULT DEFINED DEFINITIONS DEFVAL DESCRIPTION DISPLAY-HINT END ENUMERATED ENTERPRISE EXPLICIT EXPORTS EXTERNAL FALSE FROM GROUP Gauge32 IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INDEX INTEGER Integer32 IpAddress LAST-UPDATED MANDATORY-GROUPS MAX MAX-ACCESS MIN MIN-ACCESS MINUS-INFINITY MODULE MODULE-COMPLIANCE MODULE- IDENTITY NOTIFICATION-GROUP NOTIFICATION-TYPE NOTIFICATIONS NULL OBJECT OBJECT-GROUP OBJECT-IDENTITY OBJECT-TYPE OBJECTS OCTET OF OPTIONAL ORGANIZATION Opaque PLUS-INFINITY PRESENT PRIVATE PRODUCT-RELEASE REAL REFERENCE REVISION SEQUENCE SET SIZE STATUS STRING SUPPORTS SYNTAX TAGS TEXTUAL-CONVENTION TRAP-TYPE TRUE TimeTicks UNITS UNIVERSAL Unsigned32 VARIABLES VARIATION WITH WRITE-SYNTAX 4. Naming Hierarchy The root of the subtree administered by the Internet Assigned Numbers Authority (IANA) for the Internet is: internet OBJECT IDENTIFIER ::= { iso 3 6 1 } That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1. Several branches underneath this subtree are used for network management: McCloghrie, et al. Standards Track [Page 16] RFC 2578 SMIv2 April 1999 mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } However, the SMI does not prohibit the definition of objects in other portions of the object tree. The mgmt(2) subtree is used to identify "standard" objects. The experimental(3) subtree is used to identify objects being designed by working groups of the IETF. If an information module produced by a working group becomes a "standard" information module, then at the very beginning of its entry onto the Internet standards track, the objects are moved under the mgmt(2) subtree. The private(4) subtree is used to identify objects defined unilaterally. The enterprises(1) subtree beneath private is used, among other things, to permit providers of networking subsystems to register models of their products. 5. Mapping of the MODULE-IDENTITY macro The MODULE-IDENTITY macro is used to provide contact and revision history for each information module. It must appear exactly once in every information module. It should be noted that the expansion of the MODULE-IDENTITY macro is something which conceptually happens during implementation and not during run-time. Note that reference in an IMPORTS clause or in clauses of SMIv2 macros to an information module is NOT through the use of the 'descriptor' of a MODULE-IDENTITY macro; rather, an information module is referenced through specifying its module name. 5.1. Mapping of the LAST-UPDATED clause The LAST-UPDATED clause, which must be present, contains the date and time that this information module was last edited. 5.2. Mapping of the ORGANIZATION clause The ORGANIZATION clause, which must be present, contains a textual description of the organization under whose auspices this information module was developed. McCloghrie, et al. Standards Track [Page 17] RFC 2578 SMIv2 April 1999 5.3. Mapping of the CONTACT-INFO clause The CONTACT-INFO clause, which must be present, contains the name, postal address, telephone number, and electronic mail address of the person to whom technical queries concerning this information module should be sent. 5.4. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a high-level textual description of the contents of this information module. 5.5. Mapping of the REVISION clause The REVISION clause, which need not be present, is repeatedly used to describe the revisions (including the initial version) made to this information module, in reverse chronological order (i.e., most recent first). Each instance of this clause contains the date and time of the revision. 5.5.1. Mapping of the DESCRIPTION sub-clause The DESCRIPTION sub-clause, which must be present for each REVISION clause, contains a high-level textual description of the revision identified in that REVISION clause. 5.6. Mapping of the MODULE-IDENTITY value The value of an invocation of the MODULE-IDENTITY macro is an OBJECT IDENTIFIER. As such, this value may be authoritatively used when specifying an OBJECT IDENTIFIER value to refer to the information module containing the invocation. Note that it is a common practice to use the value of the MODULE- IDENTITY macro as a subtree under which other OBJECT IDENTIFIER values assigned within the module are defined. However, it is legal (and occasionally necessary) for the other OBJECT IDENTIFIER values assigned within the module to be unrelated to the OBJECT IDENTIFIER value of the MODULE-IDENTITY macro. 5.7. Usage Example Consider how a skeletal MIB module might be constructed: e.g., FIZBIN-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental McCloghrie, et al. Standards Track [Page 18] RFC 2578 SMIv2 April 1999 FROM SNMPv2-SMI; fizbin MODULE-IDENTITY LAST-UPDATED "199505241811Z" ORGANIZATION "IETF SNMPv2 Working Group" CONTACT-INFO " Marshall T. Rose Postal: Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US Tel: +1 415 968 1052 Fax: +1 415 968 2510 E-mail: mrose@dbc.mtview.ca.us" DESCRIPTION "The MIB module for entities implementing the xxxx protocol." REVISION "9505241811Z" DESCRIPTION "The latest version of this MIB module." REVISION "9210070433Z" DESCRIPTION "The initial version of this MIB module, published in RFC yyyy." -- contact IANA for actual number ::= { experimental xx } END 6. Mapping of the OBJECT-IDENTITY macro The OBJECT-IDENTITY macro is used to define information about an OBJECT IDENTIFIER assignment. All administrative OBJECT IDENTIFIER assignments which define a type identification value (see AutonomousType, a textual convention defined in [3]) should be defined via the OBJECT-IDENTITY macro. It should be noted that the expansion of the OBJECT-IDENTITY macro is something which conceptually happens during implementation and not during run-time. 6.1. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. McCloghrie, et al. Standards Track [Page 19] RFC 2578 SMIv2 April 1999 The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value "deprecated" also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. 6.2. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual description of the object assignment. 6.3. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 6.4. Mapping of the OBJECT-IDENTITY value The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT IDENTIFIER. 6.5. Usage Example Consider how an OBJECT IDENTIFIER assignment might be made: e.g., fizbin69 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identity of the Fizbin 69 chipset." ::= { fizbinChipSets 1 } 7. Mapping of the OBJECT-TYPE macro The OBJECT-TYPE macro is used to define a type of managed object. It should be noted that the expansion of the OBJECT-TYPE macro is something which conceptually happens during implementation and not during run-time. For leaf objects which are not columnar objects (i.e., not contained within a conceptual table), instances of the object are identified by appending a sub-identifier of zero to the name of that object. Otherwise, the INDEX clause of the conceptual row object superior to a columnar object defines instance identification information. McCloghrie, et al. Standards Track [Page 20] RFC 2578 SMIv2 April 1999 7.1. Mapping of the SYNTAX clause The SYNTAX clause, which must be present, defines the abstract data structure corresponding to that object. The data structure must be one of the following: a base type, the BITS construct, or a textual convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see section 7.1.12). The base types are those defined in the ObjectSyntax CHOICE. A textual convention is a newly-defined type defined as a sub-type of a base type [3]. An extended subset of the full capabilities of ASN.1 (1988) sub- typing is allowed, as appropriate to the underlying ASN.1 type. Any such restriction on size, range or enumerations specified in this clause represents the maximal level of support which makes "protocol sense". Restrictions on sub-typing are specified in detail in Section 9 and Appendix A of this memo. The semantics of ObjectSyntax are now described. 7.1.1. Integer32 and INTEGER The Integer32 type represents integer-valued information between -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This type is indistinguishable from the INTEGER type. Both the INTEGER and Integer32 types may be sub-typed to be more constrained than the Integer32 type. The INTEGER type (but not the Integer32 type) may also be used to represent integer-valued information as named-number enumerations. In this case, only those named-numbers so enumerated may be present as a value. Note that although it is recommended that enumerated values start at 1 and be numbered contiguously, any valid value for Integer32 is allowed for an enumerated value and, further, enumerated values needn't be contiguously assigned. Finally, a label for a named-number enumeration must consist of one or more letters or digits, up to a maximum of 64 characters, and the initial character must be a lower-case letter. (However, labels longer than 32 characters are not recommended.) Note that hyphens are not allowed by this specification (except for use by information modules converted from SMIv1 which did allow hyphens). 7.1.2. OCTET STRING The OCTET STRING type represents arbitrary binary or textual data. Although the SMI-specified size limitation for this type is 65535 octets, MIB designers should realize that there may be implementation and interoperability limitations for sizes in excess of 255 octets. McCloghrie, et al. Standards Track [Page 21] RFC 2578 SMIv2 April 1999 7.1.3. OBJECT IDENTIFIER The OBJECT IDENTIFIER type represents administratively assigned names. Any instance of this type may have at most 128 sub- identifiers. Further, each sub-identifier must not exceed the value 2^32-1 (4294967295 decimal). 7.1.4. The BITS construct The BITS construct represents an enumeration of named bits. This collection is assigned non-negative, contiguous (but see below) values, starting at zero. Only those named-bits so enumerated may be present in a value. (Thus, enumerations must be assigned to consecutive bits; however, see Section 9 for refinements of an object with this syntax.) As part of updating an information module, for an object defined using the BITS construct, new enumerations can be added or existing enumerations can have new labels assigned to them. After an enumeration is added, it might not be possible to distinguish between an implementation of the updated object for which the new enumeration is not asserted, and an implementation of the object prior to the addition. Depending on the circumstances, such an ambiguity could either be desirable or could be undesirable. The means to avoid such an ambiguity is dependent on the encoding of values on the wire; however, one possibility is to define new enumerations starting at the next multiple of eight bits. (Of course, this can also result in the enumerations no longer being contiguous.) Although there is no SMI-specified limitation on the number of enumerations (and therefore on the length of a value), except as may be imposed by the limit on the length of an OCTET STRING, MIB designers should realize that there may be implementation and interoperability limitations for sizes in excess of 128 bits. Finally, a label for a named-number enumeration must consist of one or more letters or digits, up to a maximum of 64 characters, and the initial character must be a lower-case letter. (However, labels longer than 32 characters are not recommended.) Note that hyphens are not allowed by this specification. 7.1.5. IpAddress The IpAddress type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order. McCloghrie, et al. Standards Track [Page 22] RFC 2578 SMIv2 April 1999 Note that the IpAddress type is a tagged type for historical reasons. Network addresses should be represented using an invocation of the TEXTUAL-CONVENTION macro [3]. 7.1.6. Counter32 The Counter32 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Examples of appropriate SYNTAX clause include: TimeStamp (a textual convention defined in [3]), DateAndTime (another textual convention from [3]) or TimeTicks. The value of the MAX-ACCESS clause for objects with a SYNTAX clause value of Counter32 is either "read-only" or "accessible-for-notify". A DEFVAL clause is not allowed for objects with a SYNTAX clause value of Counter32. 7.1.7. Gauge32 The Gauge32 type represents a non-negative integer, which may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum value. The maximum value can not be greater than 2^32-1 (4294967295 decimal), and the minimum value can not be smaller than 0. The value of a Gauge32 has its maximum value whenever the information being modeled is greater than or equal to its maximum value, and has its minimum value whenever the information being modeled is smaller than or equal to its minimum value. If the information being modeled subsequently decreases below (increases above) the maximum (minimum) value, the Gauge32 also decreases (increases). (Note that despite of the use of the term "latched" in the original definition of this type, it does not become "stuck" at its maximum or minimum value.) McCloghrie, et al. Standards Track [Page 23] RFC 2578 SMIv2 April 1999 7.1.8. TimeTicks The TimeTicks type represents a non-negative integer which represents the time, modulo 2^32 (4294967296 decimal), in hundredths of a second between two epochs. When objects are defined which use this ASN.1 type, the description of the object identifies both of the reference epochs. For example, [3] defines the TimeStamp textual convention which is based on the TimeTicks type. With a TimeStamp, the first reference epoch is defined as the time when sysUpTime [5] was zero, and the second reference epoch is defined as the current value of sysUpTime. The TimeTicks type may not be sub-typed. 7.1.9. Opaque The Opaque type is provided solely for backward-compatibility, and shall not be used for newly-defined object types. The Opaque type supports the capability to pass arbitrary ASN.1 syntax. A value is encoded using the ASN.1 Basic Encoding Rules [4] into a string of octets. This, in turn, is encoded as an OCTET STRING, in effect "double-wrapping" the original ASN.1 value. Note that a conforming implementation need only be able to accept and recognize opaquely-encoded data. It need not be able to unwrap the data and then interpret its contents. A requirement on "standard" MIB modules is that no object may have a SYNTAX clause value of Opaque. 7.1.10. Counter64 The Counter64 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^64-1 (18446744073709551615 decimal), when it wraps around and starts increasing again from zero. Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Examples of appropriate SYNTAX McCloghrie, et al. Standards Track [Page 24] RFC 2578 SMIv2 April 1999 clause are: TimeStamp (a textual convention defined in [3]), DateAndTime (another textual convention from [3]) or TimeTicks. The value of the MAX-ACCESS clause for objects with a SYNTAX clause value of Counter64 is either "read-only" or "accessible-for-notify". A requirement on "standard" MIB modules is that the Counter64 type may be used only if the information being modeled would wrap in less than one hour if the Counter32 type was used instead. A DEFVAL clause is not allowed for objects with a SYNTAX clause value of Counter64. 7.1.11. Unsigned32 The Unsigned32 type represents integer-valued information between 0 and 2^32-1 inclusive (0 to 4294967295 decimal). 7.1.12. Conceptual Tables Management operations apply exclusively to scalar objects. However, it is sometimes convenient for developers of management applications to impose an imaginary, tabular structure on an ordered collection of objects within the MIB. Each such conceptual table contains zero or more rows, and each row may contain one or more scalar objects, termed columnar objects. This conceptualization is formalized by using the OBJECT-TYPE macro to define both an object which corresponds to a table and an object which corresponds to a row in that table. A conceptual table has SYNTAX of the form: SEQUENCE OF where refers to the SEQUENCE type of its subordinate conceptual row. A conceptual row has SYNTAX of the form: where is a SEQUENCE type defined as follows: ::= SEQUENCE { , ... , } where there is one for each subordinate object, and each is of the form: where is the descriptor naming a subordinate object, and has the value of that subordinate object's SYNTAX clause, McCloghrie, et al. Standards Track [Page 25] RFC 2578 SMIv2 April 1999 except that both sub-typing information and the named values for enumerated integers or the named bits for the BITS construct, are omitted from . Further, a is always present for every subordinate object. (The ASN.1 DEFAULT and OPTIONAL clauses are disallowed in the SEQUENCE definition.) The MAX-ACCESS clause for conceptual tables and rows is "not-accessible". 7.1.12.1. Creation and Deletion of Conceptual Rows For newly-defined conceptual rows which allow the creation of new object instances and/or the deletion of existing object instances, there should be one columnar object with a SYNTAX clause value of RowStatus (a textual convention defined in [3]) and a MAX-ACCESS clause value of read-create. By convention, this is termed the status column for the conceptual row. 7.2. Mapping of the UNITS clause This UNITS clause, which need not be present, contains a textual definition of the units associated with that object. 7.3. Mapping of the MAX-ACCESS clause The MAX-ACCESS clause, which must be present, defines whether it makes "protocol sense" to read, write and/or create an instance of the object, or to include its value in a notification. This is the maximal level of access for the object. (This maximal level of access is independent of any administrative authorization policy.) The value "read-write" indicates that read and write access make "protocol sense", but create does not. The value "read-create" indicates that read, write and create access make "protocol sense". The value "not-accessible" indicates an auxiliary object (see Section 7.7). The value "accessible-for-notify" indicates an object which is accessible only via a notification (e.g., snmpTrapOID [5]). These values are ordered, from least to greatest: "not-accessible", "accessible-for-notify", "read-only", "read-write", "read-create". If any columnar object in a conceptual row has "read-create" as its maximal level of access, then no other columnar object of the same conceptual row may have a maximal access of "read-write". (Note that "read-create" is a superset of "read-write".) McCloghrie, et al. Standards Track [Page 26] RFC 2578 SMIv2 April 1999 7.4. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value "deprecated" also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. 7.5. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual definition of that object which provides all semantic definitions necessary for implementation, and should embody any information which would otherwise be communicated in any ASN.1 commentary annotations associated with the object. 7.6. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 7.7. Mapping of the INDEX clause The INDEX clause, which must be present if that object corresponds to a conceptual row (unless an AUGMENTS clause is present instead), and must be absent otherwise, defines instance identification information for the columnar objects subordinate to that object. The instance identification information in an INDEX clause must specify object(s) such that value(s) of those object(s) will unambiguously distinguish a conceptual row. The objects can be columnar objects from the same and/or another conceptual table, but must not be scalar objects. Multiple occurrences of the same object in a single INDEX clause is strongly discouraged. The syntax of the objects in the INDEX clause indicate how to form the instance-identifier: (1) integer-valued (i.e., having INTEGER as its underlying primitive type): a single sub-identifier taking the integer value (this works only for non-negative integers); McCloghrie, et al. Standards Track [Page 27] RFC 2578 SMIv2 April 1999 (2) string-valued, fixed-length strings (or variable-length preceded by the IMPLIED keyword): `n' sub-identifiers, where `n' is the length of the string (each octet of the string is encoded in a separate sub-identifier); (3) string-valued, variable-length strings (not preceded by the IMPLIED keyword): `n+1' sub-identifiers, where `n' is the length of the string (the first sub-identifier is `n' itself, following this, each octet of the string is encoded in a separate sub-identifier); (4) object identifier-valued (when preceded by the IMPLIED keyword): `n' sub-identifiers, where `n' is the number of sub-identifiers in the value (each sub-identifier of the value is copied into a separate sub-identifier); (5) object identifier-valued (when not preceded by the IMPLIED keyword): `n+1' sub-identifiers, where `n' is the number of sub- identifiers in the value (the first sub-identifier is `n' itself, following this, each sub-identifier in the value is copied); (6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d notation. Note that the IMPLIED keyword can only be present for an object having a variable-length syntax (e.g., variable-length strings or object identifier-valued objects), Further, the IMPLIED keyword can only be associated with the last object in the INDEX clause. Finally, the IMPLIED keyword may not be used on a variable-length string object if that string might have a value of zero-length. Since a single value of a Counter has (in general) no information content (see section 7.1.6 and 7.1.10), objects defined using the syntax, Counter32 or Counter64, must not be specified in an INDEX clause. If an object defined using the BITS construct is used in an INDEX clause, it is considered a variable-length string. Instances identified by use of integer-valued objects should be numbered starting from one (i.e., not from zero). The use of zero as a value for an integer-valued index object should be avoided, except in special cases. Objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects. The MAX-ACCESS clause for auxiliary objects is "not-accessible", except in the following circumstances: McCloghrie, et al. Standards Track [Page 28] RFC 2578 SMIv2 April 1999 (1) within a MIB module originally written to conform to SMIv1, and later converted to conform to SMIv2; or (2) a conceptual row must contain at least one columnar object which is not an auxiliary object. In the event that all of a conceptual row's columnar objects are also specified in its INDEX clause, then one of them must be accessible, i.e., have a MAX-ACCESS clause of "read-only". (Note that this situation does not arise for a conceptual row allowing create access, since such a row will have a status column which will not be an auxiliary object.) Note that objects specified in a conceptual row's INDEX clause need not be columnar objects of that conceptual row. In this situation, the DESCRIPTION clause of the conceptual row must include a textual explanation of how the objects which are included in the INDEX clause but not columnar objects of that conceptual row, are used in uniquely identifying instances of the conceptual row's columnar objects. 7.8. Mapping of the AUGMENTS clause The AUGMENTS clause, which must not be present unless the object corresponds to a conceptual row, is an alternative to the INDEX clause. Every object corresponding to a conceptual row has either an INDEX clause or an AUGMENTS clause. If an object corresponding to a conceptual row has an INDEX clause, that row is termed a base conceptual row; alternatively, if the object has an AUGMENTS clause, the row is said to be a conceptual row augmentation, where the AUGMENTS clause names the object corresponding to the base conceptual row which is augmented by this conceptual row augmentation. (Thus, a conceptual row augmentation cannot itself be augmented.) Instances of subordinate columnar objects of a conceptual row augmentation are identified according to the INDEX clause of the base conceptual row corresponding to the object named in the AUGMENTS clause. Further, instances of subordinate columnar objects of a conceptual row augmentation exist according to the same semantics as instances of subordinate columnar objects of the base conceptual row being augmented. As such, note that creation of a base conceptual row implies the correspondent creation of any conceptual row augmentations. For example, a MIB designer might wish to define additional columns in an "enterprise-specific" MIB which logically extend a conceptual row in a "standard" MIB. The "standard" MIB definition of the conceptual row would include the INDEX clause and the "enterprise- specific" MIB would contain the definition of a conceptual row using the AUGMENTS clause. On the other hand, it would be incorrect to use the AUGMENTS clause for the relationship between RFC 2233's ifTable McCloghrie, et al. Standards Track [Page 29] RFC 2578 SMIv2 April 1999 and the many media-specific MIBs which extend it for specific media (e.g., the dot3Table in RFC 2358), since not all interfaces are of the same media. Note that a base conceptual row may be augmented by multiple conceptual row augmentations. 7.8.1. Relation between INDEX and AUGMENTS clauses When defining instance identification information for a conceptual table: (1) If there is a one-to-one correspondence between the conceptual rows of this table and an existing table, then the AUGMENTS clause should be used. (2) Otherwise, if there is a sparse relationship between the conceptual rows of this table and an existing table, then an INDEX clause should be used which is identical to that in the existing table. For example, the relationship between RFC 2233's ifTable and a media-specific MIB which extends the ifTable for a specific media (e.g., the dot3Table in RFC 2358), is a sparse relationship. (3) Otherwise, if no existing objects have the required syntax and semantics, then auxiliary objects should be defined within the conceptual row for the new table, and those objects should be used within the INDEX clause for the conceptual row. 7.9. Mapping of the DEFVAL clause The DEFVAL clause, which need not be present, defines an acceptable default value which may be used at the discretion of an agent when an object instance is created. That is, the value is a "hint" to implementors. During conceptual row creation, if an instance of a columnar object is not present as one of the operands in the correspondent management protocol set operation, then the value of the DEFVAL clause, if present, indicates an acceptable default value that an agent might use (especially for a read-only object). Note that with this definition of the DEFVAL clause, it is appropriate to use it for any columnar object of a read-create table. It is also permitted to use it for scalar objects dynamically created by an agent, or for columnar objects of a read-write table dynamically created by an agent. McCloghrie, et al. Standards Track [Page 30] RFC 2578 SMIv2 April 1999 The value of the DEFVAL clause must, of course, correspond to the SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER, then it must be expressed as a single ASN.1 identifier, and not as a collection of sub-identifiers. Note that if an operand to the management protocol set operation is an instance of a read-only object, then the error `notWritable' [6] will be returned. As such, the DEFVAL clause can be used to provide an acceptable default value that an agent might use. By way of example, consider the following possible DEFVAL clauses: ObjectSyntax DEFVAL clause ---------------- ------------ Integer32 DEFVAL { 1 } -- same for Gauge32, TimeTicks, Unsigned32 INTEGER DEFVAL { valid } -- enumerated value OCTET STRING DEFVAL { 'ffffffffffff'H } DisplayString DEFVAL { "SNMP agent" } IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21 OBJECT IDENTIFIER DEFVAL { sysDescr } BITS DEFVAL { { primary, secondary } } -- enumerated values that are set BITS DEFVAL { { } } -- no enumerated values are set A binary string used in a DEFVAL clause for an OCTET STRING must be either an integral multiple of eight or zero bits in length; similarly, a hexadecimal string must be an even number of hexadecimal digits. The value of a character string used in a DEFVAL clause must not contain tab characters or line terminator characters. Object types with SYNTAX of Counter32 and Counter64 may not have DEFVAL clauses, since they do not have defined initial values. However, it is recommended that they be initialized to zero. 7.10. Mapping of the OBJECT-TYPE value The value of an invocation of the OBJECT-TYPE macro is the name of the object, which is an OBJECT IDENTIFIER, an administratively assigned name. When an OBJECT IDENTIFIER is assigned to an object: (1) If the object corresponds to a conceptual table, then only a single assignment, that for a conceptual row, is present immediately beneath that object. The administratively assigned name for the conceptual row object is derived by appending a sub-identifier of McCloghrie, et al. Standards Track [Page 31] RFC 2578 SMIv2 April 1999 "1" to the administratively assigned name for the conceptual table. (2) If the object corresponds to a conceptual row, then at least one assignment, one for each column in the conceptual row, is present beneath that object. The administratively assigned name for each column is derived by appending a unique, positive sub-identifier to the administratively assigned name for the conceptual row. (3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the object may be assigned. Note that the final sub-identifier of any administratively assigned name for an object shall be positive. A zero-valued final sub- identifier is reserved for future use. 7.11. Usage Example Consider how one might define a conceptual table and its subordinates. (This example uses the RowStatus textual convention defined in [3].) evalSlot OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index number of the first unassigned entry in the evaluation table, or the value of zero indicating that all entries are assigned. A management station should create new entries in the evaluation table using this algorithm: first, issue a management protocol retrieval operation to determine the value of evalSlot; and, second, issue a management protocol set operation to create an instance of the evalStatus object setting its value to createAndGo(4) or createAndWait(5). If this latter operation succeeds, then the management station may continue modifying the instances corresponding to the newly created conceptual row, without fear of collision with other management stations." ::= { eval 1 } evalTable OBJECT-TYPE SYNTAX SEQUENCE OF EvalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION McCloghrie, et al. Standards Track [Page 32] RFC 2578 SMIv2 April 1999 "The (conceptual) evaluation table." ::= { eval 2 } evalEntry OBJECT-TYPE SYNTAX EvalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the evaluation table." INDEX { evalIndex } ::= { evalTable 1 } EvalEntry ::= SEQUENCE { evalIndex Integer32, evalString DisplayString, evalValue Integer32, evalStatus RowStatus } evalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used for identifying instances of the columnar objects in the evaluation table." ::= { evalEntry 1 } evalString OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The string to evaluate." ::= { evalEntry 2 } evalValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when evalString was last evaluated, or zero if no such value is available." DEFVAL { 0 } ::= { evalEntry 3 } evalStatus OBJECT-TYPE McCloghrie, et al. Standards Track [Page 33] RFC 2578 SMIv2 April 1999 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status column used for creating, modifying, and deleting instances of the columnar objects in the evaluation table." DEFVAL { active } ::= { evalEntry 4 } 8. Mapping of the NOTIFICATION-TYPE macro The NOTIFICATION-TYPE macro is used to define the information contained within an unsolicited transmission of management information (i.e., within either a SNMPv2-Trap-PDU or InformRequest- PDU). It should be noted that the expansion of the NOTIFICATION-TYPE macro is something which conceptually happens during implementation and not during run-time. 8.1. Mapping of the OBJECTS clause The OBJECTS clause, which need not be present, defines an ordered sequence of MIB object types. One and only one object instance for each occurrence of each object type must be present, and in the specified order, in every instance of the notification. If the same object type occurs multiple times in a notification's ordered sequence, then an object instance is present for each of them. An object type specified in this clause must not have an MAX-ACCESS clause of "not-accessible". The notification's DESCRIPTION clause must specify the information/meaning conveyed by each occurrence of each object type in the sequence. The DESCRIPTION clause must also specify which object instance is present for each object type in the notification. Note that an agent is allowed, at its own discretion, to append as many additional objects as it considers useful to the end of the notification (i.e., after the objects defined by the OBJECTS clause). 8.2. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value "deprecated" also indicates an obsolete definition, it permits new/continued implementation in order to foster McCloghrie, et al. Standards Track [Page 34] RFC 2578 SMIv2 April 1999 interoperability with older/existing implementations. 8.3. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual definition of the notification which provides all semantic definitions necessary for implementation, and should embody any information which would otherwise be communicated in any ASN.1 commentary annotations associated with the notification. In particular, the DESCRIPTION clause should document which instances of the objects mentioned in the OBJECTS clause should be contained within notifications of this type. 8.4. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 8.5. Mapping of the NOTIFICATION-TYPE value The value of an invocation of the NOTIFICATION-TYPE macro is the name of the notification, which is an OBJECT IDENTIFIER, an administratively assigned name. In order to achieve compatibility with SNMPv1 traps, both when converting SMIv1 information modules to/from this SMI, and in the procedures employed by multi-lingual systems and proxy forwarding applications, the next to last sub- identifier in the name of any newly-defined notification must have the value zero. Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE macro is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU, respectively. 8.6. Usage Example Consider how a configuration change notification might be described: entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } entConfigChange NOTIFICATION-TYPE STATUS current DESCRIPTION "An entConfigChange trap is sent when the value of entLastChangeTime changes. It can be utilized by an NMS to trigger logical/physical entity table maintenance polls. McCloghrie, et al. Standards Track [Page 35] RFC 2578 SMIv2 April 1999 An agent must not generate more than one entConfigChange 'trap-event' in a five second period, where a 'trap-event' is the transmission of a single trap PDU to a list of trap destinations. If additional configuration changes occur within the five second 'throttling' period, then these trap-events should be suppressed by the agent. An NMS should periodically check the value of entLastChangeTime to detect any missed entConfigChange trap-events, e.g. due to throttling or transmission loss." ::= { entityMIBTrapPrefix 1 } According to this invocation, the notification authoritatively identified as { entityMIBTrapPrefix 1 } is used to report a particular type of configuration change. 9. Refined Syntax Some macros have clauses which allows syntax to be refined, specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT- CAPABILITIES macros [2]. However, not all refinements of syntax are appropriate. In particular, the object's primitive or application type must not be changed. Further, the following restrictions apply: Restrictions to Refinement of object syntax range enumeration size ----------------- ----- ----------- ---- INTEGER (1) (2) - Integer32 (1) - - Unsigned32 (1) - - OCTET STRING - - (3) OBJECT IDENTIFIER - - - BITS - (2) - IpAddress - - - Counter32 - - - Counter64 - - - Gauge32 (1) - - TimeTicks - - - where: McCloghrie, et al. Standards Track [Page 36] RFC 2578 SMIv2 April 1999 (1) the range of permitted values may be refined by raising the lower- bounds, by reducing the upper-bounds, and/or by reducing the alternative value/range choices; (2) the enumeration of named-values may be refined by removing one or more named-values (note that for BITS, a refinement may cause the enumerations to no longer be contiguous); or, (3) the size in octets of the value may be refined by raising the lower-bounds, by reducing the upper-bounds, and/or by reducing the alternative size choices. No other types of refinements can be specified in the SYNTAX clause. However, the DESCRIPTION clause is available to specify additional restrictions which can not be expressed in the SYNTAX clause. Further details on (and examples of) sub-typing are provided in Appendix A. 10. Extending an Information Module As experience is gained with an information module, it may be desirable to revise that information module. However, changes are not allowed if they have any potential to cause interoperability problems "over the wire" between an implementation using an original specification and an implementation using an updated specification(s). For any change, the invocation of the MODULE-IDENTITY macro must be updated to include information about the revision: specifically, updating the LAST-UPDATED clause, adding a pair of REVISION and DESCRIPTION clauses (see section 5.5), and making any necessary changes to existing clauses, including the ORGANIZATION and CONTACT- INFO clauses. Note that any definition contained in an information module is available to be IMPORT-ed by any other information module, and is referenced in an IMPORTS clause via the module name. Thus, a module name should not be changed. Specifically, the module name (e.g., "FIZBIN-MIB" in the example of Section 5.7) should not be changed when revising an information module (except to correct typographical errors), and definitions should not be moved from one information module to another. Also note that obsolete definitions must not be removed from MIB modules since their descriptors may still be referenced by other information modules, and the OBJECT IDENTIFIERs used to name them must never be re-assigned. McCloghrie, et al. Standards Track [Page 37] RFC 2578 SMIv2 April 1999 10.1. Object Assignments If any non-editorial change is made to any clause of a object assignment, then the OBJECT IDENTIFIER value associated with that object assignment must also be changed, along with its associated descriptor. 10.2. Object Definitions An object definition may be revised in any of the following ways: (1) A SYNTAX clause containing an enumerated INTEGER may have new enumerations added or existing labels changed. Similarly, named bits may be added or existing labels changed for the BITS construct. (2) The value of a SYNTAX clause may be replaced by a textual convention, providing the textual convention is defined to use the same primitive ASN.1 type, has the same set of values, and has identical semantics. (3) A STATUS clause value of "current" may be revised as "deprecated" or "obsolete". Similarly, a STATUS clause value of "deprecated" may be revised as "obsolete". When making such a change, the DESCRIPTION clause should be updated to explain the rationale. (4) A DEFVAL clause may be added or updated. (5) A REFERENCE clause may be added or updated. (6) A UNITS clause may be added. (7) A conceptual row may be augmented by adding new columnar objects at the end of the row, and making the corresponding update to the SEQUENCE definition. (8) Clarifications and additional information may be included in the DESCRIPTION clause. (9) Entirely new objects may be defined, named with previously unassigned OBJECT IDENTIFIER values. Otherwise, if the semantics of any previously defined object are changed (i.e., if a non-editorial change is made to any clause other than those specifically allowed above), then the OBJECT IDENTIFIER value associated with that object must also be changed. McCloghrie, et al. Standards Track [Page 38] RFC 2578 SMIv2 April 1999 Note that changing the descriptor associated with an existing object is considered a semantic change, as these strings may be used in an IMPORTS statement. 10.3. Notification Definitions A notification definition may be revised in any of the following ways: (1) A REFERENCE clause may be added or updated. (2) A STATUS clause value of "current" may be revised as "deprecated" or "obsolete". Similarly, a STATUS clause value of "deprecated" may be revised as "obsolete". When making such a change, the DESCRIPTION clause should be updated to explain the rationale. (3) A DESCRIPTION clause may be clarified. Otherwise, if the semantics of any previously defined notification are changed (i.e., if a non-editorial change is made to any clause other those specifically allowed above), then the OBJECT IDENTIFIER value associated with that notification must also be changed. Note that changing the descriptor associated with an existing notification is considered a semantic change, as these strings may be used in an IMPORTS statement. McCloghrie, et al. Standards Track [Page 39] RFC 2578 SMIv2 April 1999 11. Appendix A: Detailed Sub-typing Rules 11.1. Syntax Rules The syntax rules for sub-typing are given below. Note that while this syntax is based on ASN.1, it includes some extensions beyond what is allowed in ASN.1, and a number of ASN.1 constructs are not allowed by this syntax. ::= | "(" ["|" ]... ")" ::= | "(" "SIZE" "(" ["|" ]... ")" ")" ::= | ".." ::= "-" | | | where: is the empty string is a non-negative integer is a hexadecimal string (e.g., '0F0F'H) is a binary string (e.g, '1010'B) is further restricted as follows: - any used in a SIZE clause must be non-negative. - when a pair of values is specified, the first value must be less than the second value. - when multiple ranges are specified, the ranges may not overlap but may touch. For example, (1..4 | 4..9) is invalid, and (1..4 | 5..9) is valid. - the ranges must be a subset of the maximum range of the base type. McCloghrie, et al. Standards Track [Page 40] RFC 2578 SMIv2 April 1999 11.2. Examples Some examples of legal sub-typing: Integer32 (-20..100) Integer32 (0..100 | 300..500) Integer32 (300..500 | 0..100) Integer32 (0 | 2 | 4 | 6 | 8 | 10) OCTET STRING (SIZE(0..100)) OCTET STRING (SIZE(0..100 | 300..500)) OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10)) SYNTAX TimeInterval (0..100) SYNTAX DisplayString (SIZE(0..32)) (Note the last two examples above are not valid in a TEXTUAL CONVENTION, see [3].) Some examples of illegal sub-typing: Integer32 (150..100) -- first greater than second Integer32 (0..100 | 50..500) -- ranges overlap Integer32 (0 | 2 | 0 ) -- value duplicated Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed Integer32 (SIZE (0..34)) -- must not use SIZE OCTET STRING (0..100) -- must use SIZE OCTET STRING (SIZE(-10..100)) -- negative SIZE 12. Security Considerations This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet. 13. Editors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 EMail: kzm@cisco.com McCloghrie, et al. Standards Track [Page 41] RFC 2578 SMIv2 April 1999 David Perkins SNMPinfo 3763 Benton Street Santa Clara, CA 95051 USA Phone: +1 408 221-8702 EMail: dperkins@snmpinfo.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de 14. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [5] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [6] The 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. McCloghrie, et al. Standards Track [Page 42] RFC 2578 SMIv2 April 1999 15. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." McCloghrie, et al. Standards Track [Page 43] snmp-mibs-downloader-1.1/mibrfcs/rfc2579.txt0000644000000000000000000016321411402176071015577 0ustar Network Working Group Editors of this version: Request for Comments: 2579 K. McCloghrie STD: 58 Cisco Systems Obsoletes: 1903 D. Perkins Category: Standards Track SNMPinfo J. Schoenwaelder TU Braunschweig Authors of previous version: J. Case SNMP Research K. McCloghrie Cisco Systems M. Rose First Virtual Holdings S. Waldbusser International Network Services April 1999 Textual Conventions for SMIv2 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Introduction ..................................................2 1.1 A Note on Terminology .......................................2 2 Definitions ...................................................2 3 Mapping of the TEXTUAL-CONVENTION macro ......................20 3.1 Mapping of the DISPLAY-HINT clause .........................21 3.2 Mapping of the STATUS clause ...............................22 3.3 Mapping of the DESCRIPTION clause ..........................23 3.4 Mapping of the REFERENCE clause ............................23 3.5 Mapping of the SYNTAX clause ...............................23 4 Sub-typing of Textual Conventions ............................23 5 Revising a Textual Convention Definition .....................23 McCloghrie, et al. Standards Track [Page 1] RFC 2579 Textual Conventions for SMIv2 April 1999 6 Security Considerations ......................................24 7 Editors' Addresses ...........................................25 8 References ...................................................25 9 Full Copyright Statement .....................................26 1. Introduction Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1], termed the Structure of Management Information (SMI) [2]. When designing a MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. Objects defined using a textual convention are always encoded by means of the rules that define their primitive type. However, textual conventions often have special semantics associated with them. As such, an ASN.1 macro, TEXTUAL-CONVENTION, is used to concisely convey the syntax and semantics of a textual convention. 1.1. A Note on Terminology For the purpose of exposition, the original Structure of Management Information, as described in RFCs 1155 (STD 16), 1212 (STD 16), and RFC 1215, is termed the SMI version 1 (SMIv1). The current version of the Structure of Management Information is termed SMI version 2 (SMIv2). 2. Definitions SNMPv2-TC DEFINITIONS ::= BEGIN IMPORTS TimeTicks FROM SNMPv2-SMI; -- definition of textual conventions TEXTUAL-CONVENTION MACRO ::= McCloghrie, et al. Standards Track [Page 2] RFC 2579 Textual Conventions for SMIv2 April 1999 BEGIN TYPE NOTATION ::= DisplayPart "STATUS" Status "DESCRIPTION" Text ReferPart "SYNTAX" Syntax VALUE NOTATION ::= value(VALUE Syntax) -- adapted ASN.1 DisplayPart ::= "DISPLAY-HINT" Text | empty Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- a character string as defined in [2] Text ::= value(IA5String) Syntax ::= -- Must be one of the following: -- a base type (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative END DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII McCloghrie, et al. Standards Track [Page 3] RFC 2579 Textual Conventions for SMIv2 April 1999 character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length." SYNTAX OCTET STRING (SIZE (0..255)) PhysAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents media- or physical-level addresses." SYNTAX OCTET STRING MacAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first." SYNTAX OCTET STRING (SIZE (6)) McCloghrie, et al. Standards Track [Page 4] RFC 2579 Textual Conventions for SMIv2 April 1999 TruthValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a boolean value." SYNTAX INTEGER { true(1), false(2) } TestAndIncr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents integer-valued information used for atomic operations. When the management protocol is used to specify that an object instance having this syntax is to be modified, the new value supplied via the management protocol must precisely match the value presently held by the instance. If not, the management protocol set operation fails with an error of `inconsistentValue'. Otherwise, if the current value is the maximum value of 2^31-1 (2147483647 decimal), then the value held by the instance is wrapped to zero; otherwise, the value held by the instance is incremented by one. (Note that regardless of whether the management protocol set operation succeeds, the variable- binding in the request and response PDUs are identical.) The value of the ACCESS clause for objects having this syntax is either `read-write' or `read-create'. When an instance of a columnar object having this syntax is created, any value may be supplied via the management protocol. When the network management portion of the system is re- initialized, the value of every object instance having this syntax must either be incremented from its value prior to the re-initialization, or (if the value prior to the re- initialization is unknown) be set to a pseudo-randomly generated value." SYNTAX INTEGER (0..2147483647) AutonomousType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents an independently extensible type identification value. It may, for example, indicate a particular sub-tree with further MIB definitions, or define a particular type of protocol or hardware." SYNTAX OBJECT IDENTIFIER InstancePointer ::= TEXTUAL-CONVENTION STATUS obsolete McCloghrie, et al. Standards Track [Page 5] RFC 2579 Textual Conventions for SMIv2 April 1999 DESCRIPTION "A pointer to either a specific instance of a MIB object or a conceptual row of a MIB table in the managed device. In the latter case, by convention, it is the name of the particular instance of the first accessible columnar object in the conceptual row. The two uses of this textual convention are replaced by VariablePointer and RowPointer, respectively." SYNTAX OBJECT IDENTIFIER VariablePointer ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A pointer to a specific object instance. For example, sysContact.0 or ifInOctets.3." SYNTAX OBJECT IDENTIFIER RowPointer ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a pointer to a conceptual row. The value is the name of the instance of the first accessible columnar object in the conceptual row. For example, ifIndex.3 would point to the 3rd row in the ifTable (note that if ifIndex were not-accessible, then ifDescr.3 would be used instead)." SYNTAX OBJECT IDENTIFIER RowStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) McCloghrie, et al. Standards Track [Page 6] RFC 2579 Textual Conventions for SMIv2 April 1999 The status column has six defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: `notReady', `notInService' or `active'. That is, when queried, an existing conceptual row has only three states: it is either available for use by the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady'). McCloghrie, et al. Standards Track [Page 7] RFC 2579 Textual Conventions for SMIv2 April 1999 NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. Also note that whenever any elements of a row exist, the RowStatus column must also exist. McCloghrie, et al. Standards Track [Page 8] RFC 2579 Textual Conventions for SMIv2 April 1999 To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram: STATE +--------------+-----------+-------------+------------- | A | B | C | D | |status col.|status column| |status column | is | is |status column ACTION |does not exist| notReady | notInService| is active --------------+--------------+-----------+-------------+------------- set status |noError ->D|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndGo |inconsistent- | | | | Value| | | --------------+--------------+-----------+-------------+------------- set status |noError see 1|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndWait |wrongValue | | | --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError column to | Value| entValue| | active | | | | | | or | | | | | | | |see 2 ->D|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- set any other |see 4 |noError |noError |see 5 column to some| | | | value | | see 1| ->C| ->D --------------+--------------+-----------+-------------+------------- (1) goto B or C, depending on information available to the agent. (2) if other variable bindings included in the same PDU, McCloghrie, et al. Standards Track [Page 9] RFC 2579 Textual Conventions for SMIv2 April 1999 provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C. (4) at the discretion of the agent, the return value may be either: inconsistentName: because the agent does not choose to create such an instance when the corresponding RowStatus instance does not exist, or inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or noError: because the agent chooses to create the instance. If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A. (5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. McCloghrie, et al. Standards Track [Page 10] RFC 2579 Textual Conventions for SMIv2 April 1999 (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. Conceptual Row Creation There are four potential interactions when creating a conceptual row: selecting an instance-identifier which is not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device. Interaction 1: Selecting an Instance-Identifier The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics. In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.) Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different. Finally, the management station could select a pseudo-random number to use as the index. In the event that this index McCloghrie, et al. Standards Track [Page 11] RFC 2579 Textual Conventions for SMIv2 April 1999 was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. McCloghrie, et al. Standards Track [Page 12] RFC 2579 Textual Conventions for SMIv2 April 1999 - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. McCloghrie, et al. Standards Track [Page 13] RFC 2579 Textual Conventions for SMIv2 April 1999 NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: McCloghrie, et al. Standards Track [Page 14] RFC 2579 Textual Conventions for SMIv2 April 1999 - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. McCloghrie, et al. Standards Track [Page 15] RFC 2579 Textual Conventions for SMIv2 April 1999 Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. McCloghrie, et al. Standards Track [Page 16] RFC 2579 Textual Conventions for SMIv2 April 1999 Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed." SYNTAX INTEGER { -- the following two values are states: -- these values may be read or written active(1), notInService(2), -- the following value is a state: -- this value may be read, but not written notReady(3), -- the following three values are -- actions: these values may be written, -- but are never read createAndGo(4), createAndWait(5), destroy(6) } TimeStamp ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be McCloghrie, et al. Standards Track [Page 17] RFC 2579 Textual Conventions for SMIv2 April 1999 defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects." SYNTAX TimeTicks TimeInterval ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A period of time, measured in units of 0.01 seconds." SYNTAX INTEGER (0..2147483647) DateAndTime ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d" STATUS current DESCRIPTION "A date-time specification. field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC* 0..13 10 11 minutes from UTC 0..59 * Notes: - the value of year is in network-byte order - daylight saving time in New Zealand is +13 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 McCloghrie, et al. Standards Track [Page 18] RFC 2579 Textual Conventions for SMIv2 April 1999 Note that if only local time is known, then timezone information (fields 8-10) is not present." SYNTAX OCTET STRING (SIZE (8 | 11)) StorageType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Describes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted. If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." SYNTAX INTEGER { other(1), -- eh? volatile(2), -- e.g., in RAM nonVolatile(3), -- e.g., in NVRAM permanent(4), -- e.g., partially in ROM readOnly(5) -- e.g., completely in ROM } McCloghrie, et al. Standards Track [Page 19] RFC 2579 Textual Conventions for SMIv2 April 1999 TDomain ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a kind of transport service. Some possible values, such as snmpUDPDomain, are defined in the SNMPv2-TM MIB module. Other possible values are defined in other MIB modules." REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906." SYNTAX OBJECT IDENTIFIER TAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. A TAddress value is always interpreted within the context of a TDomain value. Thus, each definition of a TDomain value must be accompanied by a definition of a textual convention for use with that TDomain. Some possible textual conventions, such as SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM MIB module. Other possible textual conventions are defined in other MIB modules." REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906." SYNTAX OCTET STRING (SIZE (1..255)) END 3. Mapping of the TEXTUAL-CONVENTION macro The TEXTUAL-CONVENTION macro is used to convey the syntax and semantics associated with a textual convention. It should be noted that the expansion of the TEXTUAL-CONVENTION macro is something which conceptually happens during implementation and not during run-time. The name of a textual convention must consist of one or more letters or digits, with the initial character being an upper case letter. The name must not conflict with any of the reserved words listed in section 3.7 of [2], should not consist of all upper case letters, and shall not exceed 64 characters in length. (However, names longer than 32 characters are not recommended.) The hyphen is not allowed in the name of a textual convention (except for use in information modules converted from SMIv1 which allowed hyphens in ASN.1 type assignments). Further, all names used for the textual conventions defined in all "standard" information modules shall be unique. McCloghrie, et al. Standards Track [Page 20] RFC 2579 Textual Conventions for SMIv2 April 1999 3.1. Mapping of the DISPLAY-HINT clause The DISPLAY-HINT clause, which need not be present, gives a hint as to how the value of an instance of an object with the syntax defined using this textual convention might be displayed. The DISPLAY-HINT clause must not be present if the Textual Convention is defined with a syntax of: OBJECT IDENTIFIER, IpAddress, Counter32, Counter64, or any enumerated syntax (BITS or INTEGER). The determination of whether it makes sense for other syntax types is dependent on the specific definition of the Textual Convention. When the syntax has an underlying primitive type of INTEGER, the hint consists of an integer-format specification, containing two parts. The first part is a single character suggesting a display format, either: `x' for hexadecimal, or `d' for decimal, or `o' for octal, or `b' for binary. For all types, when rendering the value, leading zeros are omitted, and for negative values, a minus sign is rendered immediately before the digits. The second part is always omitted for `x', `o' and `b', and need not be present for `d'. If present, the second part starts with a hyphen and is followed by a decimal number, which defines the implied decimal point when rendering the value. For example: Hundredths ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-2" ... SYNTAX INTEGER (0..10000) suggests that a Hundredths value of 1234 be rendered as "12.34" When the syntax has an underlying primitive type of OCTET STRING, the hint consists of one or more octet-format specifications. Each specification consists of five parts, with each part using and removing zero or more of the next octets from the value and producing the next zero or more characters to be displayed. The octets within the value are processed in order of significance, most significant first. The five parts of a octet-format specification are: (1) the (optional) repeat indicator; if present, this part is a `*', and indicates that the current octet of the value is to be used as the repeat count. The repeat count is an unsigned integer (which may be zero) which specifies how many times the remainder of this octet-format specification should be successively applied. If the repeat indicator is not present, the repeat count is one. McCloghrie, et al. Standards Track [Page 21] RFC 2579 Textual Conventions for SMIv2 April 1999 (2) the octet length: one or more decimal digits specifying the number of octets of the value to be used and formatted by this octet- specification. Note that the octet length can be zero. If less than this number of octets remain in the value, then the lesser number of octets are used. (3) the display format, either: `x' for hexadecimal, `d' for decimal, `o' for octal, `a' for ascii, or `t' for UTF-8. If the octet length part is greater than one, and the display format part refers to a numeric format, then network-byte ordering (big-endian encoding) is used interpreting the octets in the value. The octets processed by the `t' display format do not necessarily form an integral number of UTF-8 characters. Trailing octets which do not form a valid UTF-8 encoded character are discarded. (4) the (optional) display separator character; if present, this part is a single character which is produced for display after each application of this octet-specification; however, this character is not produced for display if it would be immediately followed by the display of the repeat terminator character for this octet- specification. This character can be any character other than a decimal digit and a `*'. (5) the (optional) repeat terminator character, which can be present only if the display separator character is present and this octet- specification begins with a repeat indicator; if present, this part is a single character which is produced after all the zero or more repeated applications (as given by the repeat count) of this octet-specification. This character can be any character other than a decimal digit and a `*'. Output of a display separator character or a repeat terminator character is suppressed if it would occur as the last character of the display. If the octets of the value are exhausted before all the octet-format specification have been used, then the excess specifications are ignored. If additional octets remain in the value after interpreting all the octet-format specifications, then the last octet-format specification is re-interpreted to process the additional octets, until no octets remain in the value. 3.2. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. The value "current" means that the definition is current and valid. McCloghrie, et al. Standards Track [Page 22] RFC 2579 Textual Conventions for SMIv2 April 1999 The value "obsolete" means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value "deprecated" also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. 3.3. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual definition of the textual convention, which provides all semantic definitions necessary for implementation, and should embody any information which would otherwise be communicated in any ASN.1 commentary annotations associated with the object. 3.4. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 3.5. Mapping of the SYNTAX clause The SYNTAX clause, which must be present, defines abstract data structure corresponding to the textual convention. The data structure must be one of the alternatives defined in the ObjectSyntax CHOICE or the BITS construct (see section 7.1 in [2]). Note that this means that the SYNTAX clause of a Textual Convention can not refer to a previously defined Textual Convention. An extended subset of the full capabilities of ASN.1 (1988) sub- typing is allowed, as appropriate to the underlying ASN.1 type. Any such restriction on size, range or enumerations specified in this clause represents the maximal level of support which makes "protocol sense". Restrictions on sub-typing are specified in detail in Section 9 and Appendix A of [2]. 4. Sub-typing of Textual Conventions The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in the same way as the SYNTAX clause of an OBJECT-TYPE macro (see section 11 of [2]). 5. Revising a Textual Convention Definition It may be desirable to revise the definition of a textual convention after experience is gained with it. However, changes are not allowed if they have any potential to cause interoperability problems "over McCloghrie, et al. Standards Track [Page 23] RFC 2579 Textual Conventions for SMIv2 April 1999 the wire" between an implementation using an original specification and an implementation using an updated specification(s). Such changes can only be accommodated by defining a new textual convention (i.e., a new name). The following revisions are allowed: (1) A SYNTAX clause containing an enumerated INTEGER may have new enumerations added or existing labels changed. Similarly, named bits may be added or existing labels changed for the BITS construct. (2) A STATUS clause value of "current" may be revised as "deprecated" or "obsolete". Similarly, a STATUS clause value of "deprecated" may be revised as "obsolete". When making such a change, the DESCRIPTION clause should be updated to explain the rationale. (3) A REFERENCE clause may be added or updated. (4) A DISPLAY-HINTS clause may be added or updated. (5) Clarifications and additional information may be included in the DESCRIPTION clause. (6) Any editorial change. Note that with the introduction of the TEXTUAL-CONVENTION macro, there is no longer any need to define types in the following manner: DisplayString ::= OCTET STRING (SIZE (0..255)) When revising an information module containing a definition such as this, that definition should be replaced by a TEXTUAL-CONVENTION macro. 6. Security Considerations This document defines the means to define new data types for the language used to write and read descriptions of management information. These data types have no security impact on the Internet. McCloghrie, et al. Standards Track [Page 24] RFC 2579 Textual Conventions for SMIv2 April 1999 7. Editors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 EMail: kzm@cisco.com David Perkins SNMPinfo 3763 Benton Street Santa Clara, CA 95051 USA Phone: +1 408 221-8702 EMail: dperkins@snmpinfo.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de 8. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and Waldbusser, S., "Transport Mappings for Version 2 of the" Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. McCloghrie, et al. Standards Track [Page 25] RFC 2579 Textual Conventions for SMIv2 April 1999 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." McCloghrie, et al. Standards Track [Page 26] snmp-mibs-downloader-1.1/mibrfcs/rfc2580.txt0000644000000000000000000015173211402176071015571 0ustar Network Working Group Editors of this version: Request for Comments: 2580 K. McCloghrie STD: 58 Cisco Systems Obsoletes: 1904 D. Perkins Category: Standards Track SNMPinfo J. Schoenwaelder TU Braunschweig Authors of previous version: J. Case SNMP Research K. McCloghrie Cisco Systems M. Rose First Virtual Holdings S. Waldbusser International Network Services April 1999 Conformance Statements for SMIv2 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Introduction .....................................................3 1.1 A Note on Terminology ..........................................3 2 Definitions ......................................................3 2.1 The OBJECT-GROUP macro .........................................3 2.2 The NOTIFICATION-GROUP macro ...................................4 2.3 The MODULE-COMPLIANCE macro ....................................5 2.4 The AGENT-CAPABILITIES macro ...................................7 3 Mapping of the OBJECT-GROUP macro ...............................10 3.1 Mapping of the OBJECTS clause .................................10 3.2 Mapping of the STATUS clause ..................................11 3.3 Mapping of the DESCRIPTION clause .............................11 3.4 Mapping of the REFERENCE clause ...............................11 McCloghrie, et al. Standards Track [Page 1] RFC 2580 Conformance Statements for SMIv2 April 1999 3.5 Mapping of the OBJECT-GROUP value .............................11 3.6 Usage Example .................................................12 4 Mapping of the NOTIFICATION-GROUP macro .........................12 4.1 Mapping of the NOTIFICATIONS clause ...........................12 4.2 Mapping of the STATUS clause ..................................13 4.3 Mapping of the DESCRIPTION clause .............................13 4.4 Mapping of the REFERENCE clause ...............................13 4.5 Mapping of the NOTIFICATION-GROUP value .......................13 4.6 Usage Example .................................................13 5 Mapping of the MODULE-COMPLIANCE macro ..........................14 5.1 Mapping of the STATUS clause ..................................14 5.2 Mapping of the DESCRIPTION clause .............................14 5.3 Mapping of the REFERENCE clause ...............................15 5.4 Mapping of the MODULE clause ..................................15 5.4.1 Mapping of the MANDATORY-GROUPS clause ......................15 5.4.2 Mapping of the GROUP clause .................................15 5.4.3 Mapping of the OBJECT clause ................................16 5.4.3.1 Mapping of the SYNTAX clause ..............................16 5.4.3.2 Mapping of the WRITE-SYNTAX clause ........................16 5.4.3.3 Mapping of the MIN-ACCESS clause ..........................16 5.4.4 Mapping of the DESCRIPTION clause ...........................17 5.5 Mapping of the MODULE-COMPLIANCE value ........................17 5.6 Usage Example .................................................17 6 Mapping of the AGENT-CAPABILITIES macro .........................19 6.1 Mapping of the PRODUCT-RELEASE clause .........................19 6.2 Mapping of the STATUS clause ..................................19 6.3 Mapping of the DESCRIPTION clause .............................20 6.4 Mapping of the REFERENCE clause ...............................20 6.5 Mapping of the SUPPORTS clause ................................20 6.5.1 Mapping of the INCLUDES clause ..............................20 6.5.2 Mapping of the VARIATION clause .............................20 6.5.2.1 Mapping of the SYNTAX clause ..............................21 6.5.2.2 Mapping of the WRITE-SYNTAX clause ........................21 6.5.2.3 Mapping of the ACCESS clause ..............................21 6.5.2.4 Mapping of the CREATION-REQUIRES clause ...................22 6.5.2.5 Mapping of the DEFVAL clause ..............................22 6.5.2.6 Mapping of the DESCRIPTION clause .........................22 6.6 Mapping of the AGENT-CAPABILITIES value .......................22 6.7 Usage Example .................................................23 7 Extending an Information Module .................................25 7.1 Conformance Groups ............................................25 7.2 Compliance Definitions ........................................26 7.3 Capabilities Definitions ......................................26 8 Security Considerations .........................................27 9 Editors' Addresses ..............................................27 10 References .....................................................28 11 Full Copyright Statement .......................................29 McCloghrie, et al. Standards Track [Page 2] RFC 2580 Conformance Statements for SMIv2 April 1999 1. Introduction Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1], termed the Structure of Management Information (SMI) [2]. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. 1.1. A Note on Terminology For the purpose of exposition, the original Structure of Management Information, as described in RFCs 1156 (STD 16), 1212 (STD 16), and RFC 1215, is termed the SMI version 1 (SMIv1). The current version of the Structure of Management Information is termed SMI version 2 (SMIv2). 2. Definitions SNMPv2-CONF DEFINITIONS ::= BEGIN IMPORTS ObjectName, NotificationName, ObjectSyntax FROM SNMPv2-SMI; -- definitions for conformance groups OBJECT-GROUP MACRO ::= BEGIN TYPE NOTATION ::= ObjectsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) ObjectsPart ::= "OBJECTS" "{" Objects "}" Objects ::= Object | Objects "," Object Object ::= McCloghrie, et al. Standards Track [Page 3] RFC 2580 Conformance Statements for SMIv2 April 1999 value(ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- a character string as defined in [2] Text ::= value(IA5String) END -- more definitions for conformance groups NOTIFICATION-GROUP MACRO ::= BEGIN TYPE NOTATION ::= NotificationsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) NotificationsPart ::= "NOTIFICATIONS" "{" Notifications "}" Notifications ::= Notification | Notifications "," Notification Notification ::= value(NotificationName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- a character string as defined in [2] Text ::= value(IA5String) END McCloghrie, et al. Standards Track [Page 4] RFC 2580 Conformance Statements for SMIv2 April 1999 -- definitions for compliance statements MODULE-COMPLIANCE MACRO ::= BEGIN TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart ModulePart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty ModulePart ::= Modules Modules ::= Module | Modules Module Module ::= -- name of module -- "MODULE" ModuleName MandatoryPart CompliancePart ModuleName ::= -- identifier must start with uppercase letter identifier ModuleIdentifier -- must not be empty unless contained -- in MIB Module | empty ModuleIdentifier ::= value(OBJECT IDENTIFIER) | empty MandatoryPart ::= "MANDATORY-GROUPS" "{" Groups "}" | empty Groups ::= McCloghrie, et al. Standards Track [Page 5] RFC 2580 Conformance Statements for SMIv2 April 1999 Group | Groups "," Group Group ::= value(OBJECT IDENTIFIER) CompliancePart ::= Compliances | empty Compliances ::= Compliance | Compliances Compliance Compliance ::= ComplianceGroup | Object ComplianceGroup ::= "GROUP" value(OBJECT IDENTIFIER) "DESCRIPTION" Text Object ::= "OBJECT" value(ObjectName) SyntaxPart WriteSyntaxPart AccessPart "DESCRIPTION" Text -- must be a refinement for object's SYNTAX clause SyntaxPart ::= "SYNTAX" Syntax | empty -- must be a refinement for object's SYNTAX clause WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax | empty Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative AccessPart ::= McCloghrie, et al. Standards Track [Page 6] RFC 2580 Conformance Statements for SMIv2 April 1999 "MIN-ACCESS" Access | empty Access ::= "not-accessible" | "accessible-for-notify" | "read-only" | "read-write" | "read-create" -- a character string as defined in [2] Text ::= value(IA5String) END -- definitions for capabilities statements AGENT-CAPABILITIES MACRO ::= BEGIN TYPE NOTATION ::= "PRODUCT-RELEASE" Text "STATUS" Status "DESCRIPTION" Text ReferPart ModulePart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) Status ::= "current" | "obsolete" ReferPart ::= "REFERENCE" Text | empty ModulePart ::= Modules | empty Modules ::= Module | Modules Module Module ::= -- name of module -- "SUPPORTS" ModuleName "INCLUDES" "{" Groups "}" VariationPart ModuleName ::= McCloghrie, et al. Standards Track [Page 7] RFC 2580 Conformance Statements for SMIv2 April 1999 -- identifier must start with uppercase letter identifier ModuleIdentifier ModuleIdentifier ::= value(OBJECT IDENTIFIER) | empty Groups ::= Group | Groups "," Group Group ::= value(OBJECT IDENTIFIER) VariationPart ::= Variations | empty Variations ::= Variation | Variations Variation Variation ::= ObjectVariation | NotificationVariation NotificationVariation ::= "VARIATION" value(NotificationName) AccessPart "DESCRIPTION" Text ObjectVariation ::= "VARIATION" value(ObjectName) SyntaxPart WriteSyntaxPart AccessPart CreationPart DefValPart "DESCRIPTION" Text -- must be a refinement for object's SYNTAX clause SyntaxPart ::= "SYNTAX" Syntax | empty WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax | empty Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type McCloghrie, et al. Standards Track [Page 8] RFC 2580 Conformance Statements for SMIv2 April 1999 type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative AccessPart ::= "ACCESS" Access | empty Access ::= "not-implemented" -- only "not-implemented" for notifications | "accessible-for-notify" | "read-only" | "read-write" | "read-create" -- following is for backward-compatibility only | "write-only" CreationPart ::= "CREATION-REQUIRES" "{" Cells "}" | empty Cells ::= Cell | Cells "," Cell Cell ::= value(ObjectName) DefValPart ::= "DEFVAL" "{" Defvalue "}" | empty Defvalue ::= -- must be valid for the object's syntax -- in this macro's SYNTAX clause, if present, -- or if not, in object's OBJECT-TYPE macro value(ObjectSyntax) | "{" BitsValue "}" BitsValue ::= BitNames | empty BitNames ::= BitName | BitNames "," BitName BitName ::= identifier McCloghrie, et al. Standards Track [Page 9] RFC 2580 Conformance Statements for SMIv2 April 1999 -- a character string as defined in [2] Text ::= value(IA5String) END END 3. Mapping of the OBJECT-GROUP macro For conformance purposes, it is useful to define a collection of related managed objects. The OBJECT-GROUP macro is used to define each such collection of related objects. It should be noted that the expansion of the OBJECT-GROUP macro is something which conceptually happens during implementation and not during run-time. To "implement" an object, an agent must return a reasonably accurate value for management protocol retrieval operations; similarly, if the object is writable, then in response to a management protocol set operation, an agent must accordingly be able to reasonably influence the underlying managed entity. If an agent can not implement an object, the management protocol provides for it to return an exception or error, e.g, noSuchObject [4]. Under no circumstances shall an agent return a value for objects which it does not implement -- it must always return the appropriate exception or error, as described in the protocol specification [4]. Note that the OBJECT-GROUP macro itself provides no conformance information. Rather, conformance information is specified through the inclusion of defined groups in a MODULE-COMPLIANCE macro. 3.1. Mapping of the OBJECTS clause The OBJECTS clause, which must be present, is used to specify each object contained in the conformance group. Each of the specified objects must be defined in the same information module as the OBJECT-GROUP macro appears, and must have a MAX-ACCESS clause value of "accessible-for-notify", "read-only", "read-write", or "read- create". It is required that every object defined in an information module with a MAX-ACCESS clause other than "not-accessible" be contained in at least one object group. This avoids the common error of adding a new object to an information module and forgetting to add the new object to a group. McCloghrie, et al. Standards Track [Page 10] RFC 2580 Conformance Statements for SMIv2 April 1999 3.2. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete and the group should no longer be used for defining conformance. While the value "deprecated" also indicates an obsolete definition, it permits new/continued use of conformance definitions using this group. 3.3. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual definition of that group, along with a description of any relations to other groups. Note that generic compliance requirements should not be stated in this clause. However, implementation relationships between this group and other groups may be defined in this clause. 3.4. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 3.5. Mapping of the OBJECT-GROUP value The value of an invocation of the OBJECT-GROUP macro is the name of the group, which is an OBJECT IDENTIFIER, an administratively assigned name. McCloghrie, et al. Standards Track [Page 11] RFC 2580 Conformance Statements for SMIv2 April 1999 3.6. Usage Example The SNMP Group [3] is described: snmpGroup OBJECT-GROUP OBJECTS { snmpInPkts, snmpInBadVersions, snmpInASNParseErrs, snmpBadOperations, snmpSilentDrops, snmpProxyDrops, snmpEnableAuthenTraps } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation and control of an agent." ::= { snmpMIBGroups 8 } According to this invocation, the conformance group named { snmpMIBGroups 8 } contains 7 objects. 4. Mapping of the NOTIFICATION-GROUP macro For conformance purposes, it is useful to define a collection of notifications. The NOTIFICATION-GROUP macro serves this purpose. It should be noted that the expansion of the NOTIFICATION-GROUP macro is something which conceptually happens during implementation and not during run-time. 4.1. Mapping of the NOTIFICATIONS clause The NOTIFICATIONS clause, which must be present, is used to specify each notification contained in the conformance group. Each of the specified notifications must be defined in the same information module as the NOTIFICATION-GROUP macro appears. It is required that every notification defined in an information module be contained in at least one notification group. McCloghrie, et al. Standards Track [Page 12] RFC 2580 Conformance Statements for SMIv2 April 1999 4.2. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete and this group should no longer be used for defining conformance. While the value "deprecated" also indicates an obsolete definition, it permits new/continued use of conformance definitions using this group. 4.3. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual definition of the group, along with a description of any relations to other groups. Note that generic compliance requirements should not be stated in this clause. However, implementation relationships between this group and other groups may be defined in this clause. 4.4. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 4.5. Mapping of the NOTIFICATION-GROUP value The value of an invocation of the NOTIFICATION-GROUP macro is the name of the group, which is an OBJECT IDENTIFIER, an administratively assigned name. 4.6. Usage Example The SNMP Basic Notifications Group [3] is described: McCloghrie, et al. Standards Track [Page 13] RFC 2580 Conformance Statements for SMIv2 April 1999 snmpBasicNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { coldStart, authenticationFailure } STATUS current DESCRIPTION "The two notifications which an agent is required to implement." ::= { snmpMIBGroups 7 } According to this invocation, the conformance group named { snmpMIBGroups 7 } contains 2 notifications. 5. Mapping of the MODULE-COMPLIANCE macro The MODULE-COMPLIANCE macro is used to convey a minimum set of requirements with respect to implementation of one or more MIB modules. It should be noted that the expansion of the MODULE- COMPLIANCE macro is something which conceptually happens during implementation and not during run-time. A requirement on all "standard" MIB modules is that a corresponding MODULE-COMPLIANCE specification is also defined, either in the same information module or in a companion information module. 5.1. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete, and this MODULE-COMPLIANCE specification no longer specifies a valid definition of conformance. While the value "deprecated" also indicates an obsolete definition, it permits new/continued use of the MODULE-COMPLIANCE specification. 5.2. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual definition of this compliance statement and should embody any information which would otherwise be communicated in any ASN.1 commentary annotations associated with the statement. McCloghrie, et al. Standards Track [Page 14] RFC 2580 Conformance Statements for SMIv2 April 1999 5.3. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 5.4. Mapping of the MODULE clause The MODULE clause, which must be present, is repeatedly used to name each MIB module for which compliance requirements are being specified. Each MIB module is named by its module name, and optionally, by its associated OBJECT IDENTIFIER as well. The module name can be omitted when the MODULE-COMPLIANCE invocation occurs inside a MIB module, to refer to the encompassing MIB module. 5.4.1. Mapping of the MANDATORY-GROUPS clause The MANDATORY-GROUPS clause, which need not be present, names the one or more object or notification groups within the correspondent MIB module which are unconditionally mandatory for implementation. If an agent claims compliance to the MIB module, then it must implement each and every object and notification within each conformance group listed. That is, if an agent returns a noSuchObject exception in response to a management protocol get operation [4] for any object within any mandatory conformance group for every possible MIB view, or if the agent cannot generate each notification listed in any conformance group under the appropriate circumstances, then that agent is not a conformant implementation of the MIB module. 5.4.2. Mapping of the GROUP clause The GROUP clause, which need not be present, is repeatedly used to name each object and notification group which is conditionally mandatory for compliance to the MIB module. The GROUP clause can also be used to name unconditionally optional groups. A group named in a GROUP clause must be absent from the correspondent MANDATORY- GROUPS clause. Conditionally mandatory groups include those which are mandatory only if a particular protocol is implemented, or only if another group is implemented. A GROUP clause's DESCRIPTION specifies the conditions under which the group is conditionally mandatory. A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP clause, is unconditionally optional for compliance to the MIB module. McCloghrie, et al. Standards Track [Page 15] RFC 2580 Conformance Statements for SMIv2 April 1999 5.4.3. Mapping of the OBJECT clause The OBJECT clause, which need not be present, is repeatedly used to specify each MIB object for which compliance has a refined requirement with respect to the MIB module definition. The MIB object must be present in one of the conformance groups named in the correspondent MANDATORY-GROUPS clause or GROUP clauses. By definition, each object specified in an OBJECT clause follows a MODULE clause which names the information module in which that object is defined. Therefore, the use of an IMPORTS statement, to specify from where such objects are imported, is redundant and is not required in an information module. 5.4.3.1. Mapping of the SYNTAX clause The SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent OBJECT clause. Note that if this clause and a WRITE-SYNTAX clause are both present, then this clause only applies when instances of the object named in the correspondent OBJECT clause are read. Consult Section 9 of [2] for more information on refined syntax. 5.4.3.2. Mapping of the WRITE-SYNTAX clause The WRITE-SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent OBJECT clause when instances of that object are written. Consult Section 9 of [2] for more information on refined syntax. 5.4.3.3. Mapping of the MIN-ACCESS clause The MIN-ACCESS clause, which need not be present, is used to define the minimal level of access for the object named in the correspondent OBJECT clause. If this clause is absent, the minimal level of access is the same as the maximal level specified in the correspondent invocation of the OBJECT-TYPE macro. If present, this clause must not specify a greater level of access than is specified in the correspondent invocation of the OBJECT-TYPE macro. The level of access for certain types of objects is fixed according to their syntax definition. These types include: conceptual tables and rows, auxiliary objects, and objects with the syntax of Counter32, Counter64 (and possibly, certain types of textual conventions). A MIN-ACCESS clause should not be present for such McCloghrie, et al. Standards Track [Page 16] RFC 2580 Conformance Statements for SMIv2 April 1999 objects. An implementation is compliant if the level of access it provides is greater or equal to the minimal level in the MODULE-COMPLIANCE macro and less or equal to the maximal level in the OBJECT-TYPE macro. 5.4.4. Mapping of the DESCRIPTION clause The DESCRIPTION clause must be present for each use of the GROUP or OBJECT clause. For an OBJECT clause, it contains a textual description of the refined compliance requirement. For a GROUP clause, it contains a textual description of the conditions under which the group is conditionally mandatory or unconditionally optional. 5.5. Mapping of the MODULE-COMPLIANCE value The value of an invocation of the MODULE-COMPLIANCE macro is an OBJECT IDENTIFIER. As such, this value may be authoritatively used when referring to the compliance statement embodied by that invocation of the macro. 5.6. Usage Example The compliance statement contained in the (hypothetical) XYZv2-MIB might be: xyzMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for XYZv2 entities which implement the XYZv2 MIB." MODULE -- compliance to the containing MIB module MANDATORY-GROUPS { xyzSystemGroup, xyzStatsGroup, xyzTrapGroup, xyzSetGroup, xyzBasicNotificationsGroup } GROUP xyzV1Group DESCRIPTION "The xyzV1 group is mandatory only for those XYZv2 entities which also implement XYZv1." ::= { xyzMIBCompliances 1 } According to this invocation, to claim alignment with the compliance statement named { xyzMIBCompliances 1 } McCloghrie, et al. Standards Track [Page 17] RFC 2580 Conformance Statements for SMIv2 April 1999 a system must implement the XYZv2-MIB's xyzSystemGroup, xyzStatsGroup, xyzTrapGroup, and xyzSetGroup object conformance groups, as well as the xyzBasicNotificationsGroup notifications group. Furthermore, if the XYZv2 entity also implements XYZv1, then it must also support the XYZv1Group group, if compliance is to be claimed. McCloghrie, et al. Standards Track [Page 18] RFC 2580 Conformance Statements for SMIv2 April 1999 6. Mapping of the AGENT-CAPABILITIES macro The AGENT-CAPABILITIES macro is used to convey a set of capabilities present in an agent. It should be noted that the expansion of the AGENT-CAPABILITIES macro is something which conceptually happens during implementation and not during run-time. When a MIB module is written, it is divided into units of conformance termed groups. If an agent claims to implement a group, then it must implement each and every object, or each and every notification, within that group. Of course, for whatever reason, an agent might implement only a subset of the groups within a MIB module. In addition, the definition of some MIB objects/notifications leave some aspects of the definition to the discretion of an implementor. Practical experience has demonstrated a need for concisely describing the capabilities of an agent with respect to one or more MIB modules. The AGENT-CAPABILITIES macro allows an agent implementor to describe the precise level of support which an agent claims in regards to a MIB group, and to bind that description to the value of an instance of sysORID [3]. In particular, some objects may have restricted or augmented syntax or access-levels. If the AGENT-CAPABILITIES invocation is given to a management-station implementor, then that implementor can build management applications which optimize themselves when communicating with a particular agent. For example, the management-station can maintain a database of these invocations. When a management-station interacts with an agent, it retrieves from the agent the values of all instances of sysORID [3]. Based on this, it consults the database to locate each entry matching one of the retrieved values of sysORID. Using the located entries, the management application can now optimize its behavior accordingly. Note that the AGENT-CAPABILITIES macro specifies refinements or variations with respect to OBJECT-TYPE and NOTIFICATION-TYPE macros in MIB modules, NOT with respect to MODULE-COMPLIANCE macros in compliance statements. 6.1. Mapping of the PRODUCT-RELEASE clause The PRODUCT-RELEASE clause, which must be present, contains a textual description of the product release which includes this set of capabilities. 6.2. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this McCloghrie, et al. Standards Track [Page 19] RFC 2580 Conformance Statements for SMIv2 April 1999 definition is current or historic. The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete and this capabilities statement is no longer in use. 6.3. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual description of this set of capabilities. 6.4. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module which defines a related assignment, or some other document which provides additional information relevant to this definition. 6.5. Mapping of the SUPPORTS clause The SUPPORTS clause, which need not be present, is repeatedly used to name each MIB module for which the agent claims a complete or partial implementation. Each MIB module is named by its module name, and optionally, by its associated OBJECT IDENTIFIER (as registered by the MODULE-IDENTITY macro, see [2]) as well. 6.5.1. Mapping of the INCLUDES clause The INCLUDES clause, which must follow each and every use of the SUPPORTS clause, is used to name each MIB group associated with the SUPPORTS clause, which the agent claims to implement. 6.5.2. Mapping of the VARIATION clause The VARIATION clause, which need not be present, is repeatedly used to name each object or notification which the agent implements in some variant or refined fashion with respect to the correspondent invocation of the OBJECT-TYPE or NOTIFICATION-TYPE macro. Note that the variation concept is meant for generic implementation restrictions, e.g., if the variation for an object depends on the values of other objects, then this should be noted in the appropriate DESCRIPTION clause. By definition, each object specified in a VARIATION clause follows a SUPPORTS clause which names the information module in which that object is defined. Therefore, the use of an IMPORTS statement, to specify from where such objects are imported, is redundant and is not McCloghrie, et al. Standards Track [Page 20] RFC 2580 Conformance Statements for SMIv2 April 1999 required in an information module. 6.5.2.1. Mapping of the SYNTAX clause The SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent VARIATION clause. Note that if this clause and a WRITE-SYNTAX clause are both present, then this clause only applies when instances of the object named in the correspondent VARIATION clause are read. Consult Section 9 of [2] for more information on refined syntax. Note that for enumerated INTEGERs and for the BITS construct, the changes allowed when updating a MIB module include the addition of enumerations and/or changing the labels of existing enumerations (see Section 10.2 of [2]). This type of change can cause problems for an AGENT-CAPABILITIES macro written against the old revision of a MIB module. One way to avoid such problems is to explicitly list all objects having an enumerated syntax in a VARIATION clause, even when all enumerations are currently supported. 6.5.2.2. Mapping of the WRITE-SYNTAX clause The WRITE-SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent VARIATION clause when instances of that object are written. Consult Section 9 of [2] for more information on refined syntax. 6.5.2.3. Mapping of the ACCESS clause The ACCESS clause, which need not be present, is used to indicate the agent provides less than the maximal level of access to the object or notification named in the correspondent VARIATION clause. The only value applicable to notifications is "not-implemented". The value "not-implemented" indicates the agent does not implement the object or notification, and in the ordering of possible values is equivalent to "not-accessible". The value "write-only" is provided solely for backward compatibility, and shall not be used for newly-defined object types. In the ordering of possible values, "write-only" is less than "not- accessible". McCloghrie, et al. Standards Track [Page 21] RFC 2580 Conformance Statements for SMIv2 April 1999 6.5.2.4. Mapping of the CREATION-REQUIRES clause The CREATION-REQUIRES clause, which need not be present, is used to name the columnar objects of a conceptual row to which values must be explicitly assigned, by a management protocol set operation, before the agent will allow the instance of the status column of that row to be set to `active'. (Consult the definition of RowStatus [5].) If the conceptual row does not have a status column (i.e., the objects corresponding to the conceptual table were defined using the mechanisms in [6,7]), then the CREATION-REQUIRES clause, which need not be present, is used to name the columnar objects of a conceptual row to which values must be explicitly assigned, by a management protocol set operation, before the agent will create new instances of objects in that row. This clause must not be present unless the object named in the correspondent VARIATION clause is a conceptual row, i.e., has a syntax which resolves to a SEQUENCE containing columnar objects. The objects named in the value of this clause usually will refer to columnar objects in that row. However, objects unrelated to the conceptual row may also be specified. All objects which are named in the CREATION-REQUIRES clause for a conceptual row, and which are columnar objects of that row, must have an access level of "read-create". 6.5.2.5. Mapping of the DEFVAL clause The DEFVAL clause, which need not be present, is used to provide a alternate DEFVAL value for the object named in the correspondent VARIATION clause. The semantics of this value are identical to those of the OBJECT-TYPE macro's DEFVAL clause. 6.5.2.6. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present for each use of the VARIATION clause, contains a textual description of the variant or refined implementation of the object or notification. 6.6. Mapping of the AGENT-CAPABILITIES value The value of an invocation of the AGENT-CAPABILITIES macro is an OBJECT IDENTIFIER, which names the value of sysORID [3] for which this capabilities statement is valid. McCloghrie, et al. Standards Track [Page 22] RFC 2580 Conformance Statements for SMIv2 April 1999 6.7. Usage Example Consider how a capabilities statement for an agent might be described: exampleAgent AGENT-CAPABILITIES PRODUCT-RELEASE "ACME Agent release 1.1 for 4BSD." STATUS current DESCRIPTION "ACME agent for 4BSD." SUPPORTS SNMPv2-MIB INCLUDES { systemGroup, snmpGroup, snmpSetGroup, snmpBasicNotificationsGroup } VARIATION coldStart DESCRIPTION "A coldStart trap is generated on all reboots." SUPPORTS IF-MIB INCLUDES { ifGeneralGroup, ifPacketGroup } VARIATION ifAdminStatus SYNTAX INTEGER { up(1), down(2) } DESCRIPTION "Unable to set test mode on 4BSD." VARIATION ifOperStatus SYNTAX INTEGER { up(1), down(2) } DESCRIPTION "Information limited on 4BSD." SUPPORTS IP-MIB INCLUDES { ipGroup, icmpGroup } VARIATION ipDefaultTTL SYNTAX INTEGER (255..255) DESCRIPTION "Hard-wired on 4BSD." VARIATION ipInAddrErrors ACCESS not-implemented DESCRIPTION "Information not available on 4BSD." VARIATION ipNetToMediaEntry CREATION-REQUIRES { ipNetToMediaPhysAddress } DESCRIPTION "Address mappings on 4BSD require both protocol and media addresses." SUPPORTS TCP-MIB INCLUDES { tcpGroup } VARIATION tcpConnState McCloghrie, et al. Standards Track [Page 23] RFC 2580 Conformance Statements for SMIv2 April 1999 ACCESS read-only DESCRIPTION "Unable to set this on 4BSD." SUPPORTS UDP-MIB INCLUDES { udpGroup } SUPPORTS EVAL-MIB INCLUDES { functionsGroup, expressionsGroup } VARIATION exprEntry CREATION-REQUIRES { evalString, evalStatus } DESCRIPTION "Conceptual row creation is supported." ::= { acmeAgents 1 } According to this invocation, an agent with a sysORID value of { acmeAgents 1 } supports objects defined in six MIB modules. From SNMPv2-MIB, five conformance groups are supported. From IF-MIB, the ifGeneralGroup and ifPacketGroup groups are supported. However, the objects ifAdminStatus and ifOperStatus have a restricted syntax. From IP-MIB, all objects in the ipGroup and icmpGroup are supported except ipInAddrErrors, while ipDefaultTTL has a restricted range, and when creating a new instance in the ipNetToMediaTable, the set- request must create an instance of ipNetToMediaPhysAddress. From TCP-MIB, the tcpGroup is supported except that tcpConnState is available only for reading. From UDP-MIB, the udpGroup is fully supported. From the EVAL-MIB, all the objects contained in the functionsGroup and expressionsGroup conformance groups are supported, without variation. In addition, creation of new instances in the expr table is supported, and requires both of the objects: evalString and evalStatus, to be assigned a value. McCloghrie, et al. Standards Track [Page 24] RFC 2580 Conformance Statements for SMIv2 April 1999 7. Extending an Information Module As experience is gained with a published information module, it may be desirable to revise that information module. Section 10 of [2] defines the rules for extending an information module. The remainder of this section defines how conformance groups, compliance statements, and capabilities statements may be extended. 7.1. Conformance Groups It may be desirable to revise the definition of a conformance group (an OBJECT-GROUP or a NOTIFICATION-GROUP) after experience is gained with it. However, conformance groups can be referenced by compliance and/or capabilities definitions. Therefore, a change to a conformance group is not allowed if it has the potential to cause a reference to the group's original definition to be different from a reference to the updated definition. Such changes can only be accommodated by defining a new conformance group with a new descriptor and a new OBJECT IDENTIFIER value. The following revisions are allowed: (1) A STATUS clause value of "current" may be revised as "deprecated" or "obsolete". Similarly, a STATUS clause value of "deprecated" may be revised as "obsolete". When making such a change, the DESCRIPTION clause should be updated to explain the rationale. (2) A REFERENCE clause may be added or updated. (3) Clarifications and additional information may be included in the DESCRIPTION clause. (4) Any editorial change. It is not necessary to change the STATUS value of a conformance group when the status of a member of the group is changed. 7.2. Compliance Definitions It may be desirable to revise the definition of a compliance definition (MODULE-COMPLIANCE) after experience is gained with it. However, changes are not allowed if they cause the requirements specified by the original definition to be different from the requirements of the updated definition. Such changes can only be accommodated by defining a new compliance definition with a new McCloghrie, et al. Standards Track [Page 25] RFC 2580 Conformance Statements for SMIv2 April 1999 descriptor and a new OBJECT IDENTIFIER value. The following revisions are allowed: (1) A STATUS clause value of "current" may be revised as "deprecated" or "obsolete". Similarly, a STATUS clause value of "deprecated" may be revised as "obsolete". When making such a change, the DESCRIPTION clause should be updated to explain the rationale. (2) A REFERENCE clause may be added or updated. (3) Clarifications and additional information may be included in the DESCRIPTION clause(s). (4) Any editorial change. It is not necessary to change the STATUS value of a compliance definition due to a change in the STATUS value of a definition it references. 7.3. Capabilities Definitions It may be desirable to revise the definition of a capabilities definition (AGENT-CAPABILITIES) after experience is gained with it. However, changes are not allowed if they cause the capabilities specified by the original specification to be different from the capabilities of the updated specification. Such changes can only be accommodated by defining a new capabilities definition with a new descriptor and a new OBJECT IDENTIFIER value. The following revisions are allowed: (1) A STATUS clause value of "current" may be revised as "obsolete". When making such a change, the DESCRIPTION clause should be updated to explain the rationale. (2) A REFERENCE clause may be added or updated. (3) Clarifications and additional information may be included in the DESCRIPTION clause(s). (4) Any editorial change. It is not necessary to change the STATUS value of a capabilities definition due to a change in the STATUS value of a definition it references. McCloghrie, et al. Standards Track [Page 26] RFC 2580 Conformance Statements for SMIv2 April 1999 8. Security Considerations This document defines the means to define conformance requirements for implementing on documents describing management information. This method of defining conformance requirements has no security impact on the Internet. 9. Editors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 EMail: kzm@cisco.com David Perkins SNMPinfo 3763 Benton Street Santa Clara, CA 95051 USA Phone: +1 408 221-8702 Email: dperkins@snmpinfo.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de McCloghrie, et al. Standards Track [Page 27] RFC 2580 Conformance Statements for SMIv2 April 1999 10. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [4] The 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. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [6] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [7] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. McCloghrie, et al. Standards Track [Page 28] RFC 2580 Conformance Statements for SMIv2 April 1999 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." McCloghrie, et al. Standards Track [Page 29] snmp-mibs-downloader-1.1/mibrfcs/rfc2584.txt0000644000000000000000000011637311402176071015577 0ustar Network Working Group B. Clouston, Ed. Request for Comments: 2584 Cisco Systems Category: Standards Track B. Moore, Ed. IBM Corporation May 1999 Definitions of Managed Objects for APPN/HPR in IP Networks 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. This memo identifies managed objects for the HPR in IP network communications. Table of Contents 1. Introduction ........................................... 2 2. The SNMP Network Management Framework .................. 2 3. Overview ............................................... 3 3.1 HPR/IP Values for Objects in the APPN MIB ............. 3 3.2 APPN/HPR in IP Networks MIB structure ................. 4 3.2.1 hprIpMonitoringGroup ................................ 5 3.2.2 hprIpConfigurationGroup ............................. 5 4. Definitions ............................................ 6 5. Security Considerations ................................ 16 6. Intellectual Property .................................. 17 7. Acknowledgments ........................................ 18 8. References ............................................. 18 9. Authors' Addresses ..................................... 20 10. Full Copyright Statement ............................... 21 Clouston & Moore Standards Track [Page 1] RFC 2584 APPN/HPR in IP Networks MIB May 1999 1. Introduction This document is a product of the SNA NAU Services MIB Working Group. It defines a MIB module for managing devices with HPR in IP networks capabilities. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [17]. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2478 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Clouston & Moore Standards Track [Page 2] RFC 2584 APPN/HPR in IP Networks MIB May 1999 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This document identifies a set of objects for monitoring the configuration and active characteristics of devices with HPR in IP network capabilities. HPR is an enhancement to the Advanced Peer- to-Peer Network (APPN) architecture that provides fast data routing and improved session reliability. APPN is the aspect of Systems Network Architecture (SNA) that supports peer-to-peer networking. APPN/HPR in IP Networks is a further enhancement to the APPN/HPR architecture, described in RFC 2353 [18]. It provides a method with which APPN/HPR nodes can communicate in IP networks. APPN management information is defined by the APPN MIB [19]. HPR management information is defined by the HPR MIB, RFC 2238 [20]. Highlights of the management functions supported by the APPN/HPR in IP Networks MIB module include the following: o A count of UDP packets sent with each type of APPN traffic on HPR/IP links. o Monitoring and setting configuration parameters for the mappings between APPN traffic types on Type of Service (TOS) Precedence settings in the IP header. Note that the TOS Precedence settings have been redefined in RFC 2474 [21] as the first three bits of the differentiated services code point (DSCP). This MIB module does not support: o Configuration of IP addresses used for APPN ports or link stations. 3.1. HPR/IP Values for Objects in the APPN MIB Ports and link stations are the APPN device's interface to the data link control (DLC), which provides the physical transport, or to another protocol, such as IP. The APPN MIB identifies ports and link stations using IP as the transport with the following objects: Clouston & Moore Standards Track [Page 3] RFC 2584 APPN/HPR in IP Networks MIB May 1999 o appnPortDlcType o appnLsDlcType o appnLsStatusDlcType These objects all have the syntax IANAifType, and the value 126, defined as "IP (for APPN HPR in IP networks)" shall be returned when they identify an HPR/IP port or link station. The IP address used for the port or link station is returned in the following objects: o appnPortDlcLocalAddr o appnLsLocalAddr o appnLsRemoteAddr o appnLsStatusLocalAddr o appnLsStatusRemoteAddr These objects have the syntax DisplayableDlcAddress, defined in the APPN MIB as a textual convention to represent the address as an octet string of ASCII characters. The following two objects return object identifiers that tie port and link table entries in the APPN MIB to lower-layer MIB entries: o appnPortSpecific o appnLsSpecific Both objects should return a RowPointer to the ifEntry in the agent's ifTable for the physical interface associated with the local IP address for the port. If the agent implements the IP-MIB (RFC 2011), this association between the IP address and the physical interface will be represented in the ipNetToMediaTable. 3.2. APPN/HPR in IP Networks MIB Structure The APPN/HPR in IP Networks MIB module contains two groups of objects: o hprIpMonitoringGroup - an object for counting outgoing HPR/IP traffic for each APPN traffic type Clouston & Moore Standards Track [Page 4] RFC 2584 APPN/HPR in IP Networks MIB May 1999 o hprIpConfigurationGroup - objects to represent TOS Precedence to APPN traffic type mappings These groups are described below in more detail. 3.2.1. hprIpMonitoringGroup The hprIpMonitoringGroup group consists of the hprIpActiveLsTable. This table is indexed by the link station name and traffic type, and contains a counter for the number of UDP packets sent on a link station for that traffic type. 3.2.2. hprIpConfigurationGroup The hprIpMonitoringGroup group consists of the following objects and tables: 1) hprIpAppnPortTable This table supports reading and setting the default mapping between APPN traffic types and TOS Precedence settings for all link stations using a port. This mapping may be overridden for individual link stations or individual connection networks. 2) hprIpLsTable This table supports reading and setting the mappings between APPN traffic types and TOS Precedence settings for an individual link station and APPN traffic type. If there is no entry in this table for a given link station and traffic type, then that link station inherits its mapping from its port. 3) hprIpCnTable This table supports reading and setting the mapping between APPN traffic types and TOS Precedence settings for an individual connection network and traffic type. If there is no entry in this table for a given connection network and traffic type, then that connection network inherits its mapping from its port. Clouston & Moore Standards Track [Page 5] RFC 2584 APPN/HPR in IP Networks MIB May 1999 4. Definitions HPR-IP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY,OBJECT-TYPE, Counter32 FROM SNMPv2-SMI DisplayString, RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnaControlPointName FROM APPN-MIB hprObjects, hprCompliances, hprGroups FROM HPR-MIB ; hprIp MODULE-IDENTITY LAST-UPDATED "9809240000Z" -- September 24, 1998 ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG" CONTACT-INFO " Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Tel: 1 919 472 2333 E-mail: clouston@cisco.com Bob Moore IBM Corporation 4205 S. Miami Boulevard BRQA/501 P.O. Box 12195 Research Triangle Park, NC 27709, USA Tel: 1 919 254 4436 E-mail: remoore@us.ibm.com " DESCRIPTION "The MIB module for HPR over IP. This module contains two groups: - the HPR over IP Monitoring Group provides a count of the UDP packets sent by a link station for each APPN traffic type. - the HPR over IP Configuration Group provides for reading and setting the mappings between APPN traffic types and TOS Precedence settings in the IP header. These mappings are Clouston & Moore Standards Track [Page 6] RFC 2584 APPN/HPR in IP Networks MIB May 1999 configured at the APPN port level, and are inherited by the APPN connection networks and link stations associated with an APPN port. A port-level mapping can, however, be overridden for a particular connection network or link station." REVISION "9809240000Z" -- September 24, 1998 DESCRIPTION "Initial version, Published as RFC 2584" ::= { hprObjects 5 } -- ********************************************************************* -- Textual Conventions -- ********************************************************************* AppnTrafficType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "APPN traffic type. The first four values correspond to APPN transmission priorities (network, high, medium and low), while the fifth is used for both LLC commands (XID, TEST, DISC, and DM) and function-routed NLPs (XID_DONE_RQ and XID_DONE_RSP)." SYNTAX INTEGER { low (1), medium (2), high (3), network (4), llcAndFnRoutedNlp (5) } AppnTOSPrecedence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A DisplayString representing the setting of the three TOS Precedence bits in the IP Type of Service field for this APPN traffic type. The HPR over IP architecture specifies the following default mapping: APPN traffic type IP TOS Precedence bits ------------------ ---------------------- Network 110 High 100 Medium 010 Low 001 LLC commands, etc. 110 " SYNTAX DisplayString (SIZE(3)) -- ******************************************************************* Clouston & Moore Standards Track [Page 7] RFC 2584 APPN/HPR in IP Networks MIB May 1999 -- hprObjects OBJECT IDENTIFIER ::= { hprMIB 1 } -- ******************************************************************* -- ******************************************************************* -- HPR over IP Monitoring Group -- -- This group contains a single table, the hprIsActiveLsTable, -- providing a count of UDP packets sent with each type of -- APPN traffic on each active link supporting HPR over IP. -- ******************************************************************* hprIpActiveLsTable OBJECT-TYPE SYNTAX SEQUENCE OF HprIpActiveLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The HPR/IP active link station table. This table provides counts of the number of UDP packets sent for each APPN traffic type." ::= { hprIp 1 } hprIpActiveLsEntry OBJECT-TYPE SYNTAX HprIpActiveLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of the HPR/IP link station table." INDEX { hprIpActiveLsLsName, hprIpActiveLsAppnTrafficType } ::= { hprIpActiveLsTable 1 } HprIpActiveLsEntry ::= SEQUENCE { hprIpActiveLsLsName DisplayString, hprIpActiveLsAppnTrafficType AppnTrafficType, hprIpActiveLsUdpPackets Counter32 } hprIpActiveLsLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for the link station. If this object has the same value as the appnLsName in the APPN MIB, then the two objects are referring to the same APPN link station." Clouston & Moore Standards Track [Page 8] RFC 2584 APPN/HPR in IP Networks MIB May 1999 ::= { hprIpActiveLsEntry 1 } hprIpActiveLsAppnTrafficType OBJECT-TYPE SYNTAX AppnTrafficType MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPN traffic type being sent through the link station." ::= { hprIpActiveLsEntry 2 } hprIpActiveLsUdpPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of outgoing UDP packets carrying this type of APPN traffic. A discontinuity in the counter is indicated by the appnLsCounterDisconTime object in the APPN MIB." ::= { hprIpActiveLsEntry 3 } -- ******************************************************************* -- HPR over IP Configuration Group -- -- This group contains three tables for reading and setting the -- mapping between APPN traffic types and values for the TOS -- Precedence bits in the IP header. hprIpAppnPortTOSPrecedence -- represents the APPN port-level mapping. This mapping can be -- overridden for an individual link station or an individual -- connection network via, respectively, the hprIpLsTOSPrecedence -- and the hprIpCnTOSPrecedence objects. -- ******************************************************************* hprIpAppnPortTable OBJECT-TYPE SYNTAX SEQUENCE OF HprIpAppnPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The HPR/IP APPN port table. This table supports reading and setting the mapping between APPN traffic types and TOS Precedence settings for all the link stations at this APPN port. This mapping can be overridden for an individual link station or an individual connection network via, respectively, the hprIpLsTOSPrecedence and the hprIpCnTOSPrecedence objects." ::= { hprIp 2 } Clouston & Moore Standards Track [Page 9] RFC 2584 APPN/HPR in IP Networks MIB May 1999 hprIpAppnPortEntry OBJECT-TYPE SYNTAX HprIpAppnPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of the HPR/IP APPN port table. Entries exist for every APPN port defined to support HPR over IP." INDEX { hprIpAppnPortName, hprIpAppnPortAppnTrafficType } ::= { hprIpAppnPortTable 1 } HprIpAppnPortEntry ::= SEQUENCE { hprIpAppnPortName DisplayString, hprIpAppnPortAppnTrafficType AppnTrafficType, hprIpAppnPortTOSPrecedence AppnTOSPrecedence } hprIpAppnPortName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for this APPN port. If this object has the same value as the appnPortName in the APPN MIB, then the two objects are referring to the same APPN port." ::= { hprIpAppnPortEntry 1 } hprIpAppnPortAppnTrafficType OBJECT-TYPE SYNTAX AppnTrafficType MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPN traffic type sent through the port." ::= { hprIpAppnPortEntry 2 } hprIpAppnPortTOSPrecedence OBJECT-TYPE SYNTAX AppnTOSPrecedence MAX-ACCESS read-write STATUS current DESCRIPTION "A setting for the three TOS Precedence bits in the IP Type of Service field for this APPN traffic type. When this value is changed via a Set operation, the new setting for the TOS Precedence bits takes effect immediately, rather Clouston & Moore Standards Track [Page 10] RFC 2584 APPN/HPR in IP Networks MIB May 1999 than waiting for some event such as reinitialization of the port or of the APPN node itself." ::= { hprIpAppnPortEntry 3 } -- ******************************************************************* hprIpLsTable OBJECT-TYPE SYNTAX SEQUENCE OF HprIpLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The HPR/IP link station table. Values for TOS Precedence at the link station level override those at the level of the containing port. If there is no entry in this table for a given link station, then that link station inherits its TOS Precedence values from its port." ::= { hprIp 3 } hprIpLsEntry OBJECT-TYPE SYNTAX HprIpLsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of the HPR/IP link station table." INDEX { hprIpLsLsName, hprIpLsAppnTrafficType } ::= { hprIpLsTable 1 } HprIpLsEntry ::= SEQUENCE { hprIpLsLsName DisplayString, hprIpLsAppnTrafficType AppnTrafficType, hprIpLsTOSPrecedence AppnTOSPrecedence, hprIpLsRowStatus RowStatus } hprIpLsLsName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..10)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Administratively assigned name for the link station. If this object has the same value as the appnLsName in the APPN MIB, then the two objects are referring to the same APPN link station." Clouston & Moore Standards Track [Page 11] RFC 2584 APPN/HPR in IP Networks MIB May 1999 ::= { hprIpLsEntry 1 } hprIpLsAppnTrafficType OBJECT-TYPE SYNTAX AppnTrafficType MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPN traffic type sent through the link station." ::= { hprIpLsEntry 2 } hprIpLsTOSPrecedence OBJECT-TYPE SYNTAX AppnTOSPrecedence MAX-ACCESS read-create STATUS current DESCRIPTION "A setting for the three TOS Precedence bits in the IP Type of Service field for this APPN traffic type. When this value is changed via a Set operation, the new setting for the TOS Precedence bits takes effect immediately, rather than waiting for some event such as reinitialization of the port or of the APPN node itself." ::= { hprIpLsEntry 3 } hprIpLsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the hprIpLsTable. As soon as an entry becomes active, the mapping between APPN traffic types and TOS Precedence settings that it specifies becomes effective. The value of the other accessible object in this entry, hprIpLsTOSPrecedence, can be changed via a Set operation when this object's value is active(1). An entry in this table is deleted by setting this object to destroy(6). Deleting an entry in this table causes the link station to revert to the default TOS Precedence mapping for its port." ::= { hprIpLsEntry 4 } Clouston & Moore Standards Track [Page 12] RFC 2584 APPN/HPR in IP Networks MIB May 1999 -- ******************************************************************* hprIpCnTable OBJECT-TYPE SYNTAX SEQUENCE OF HprIpCnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The HPR/IP connection network table. Values for TOS Precedence at the connection network level override those at the level of the containing port. If there is no entry in this table for a given connection network, then that connection network inherits its TOS Precedence values from its port. A node may have connections to a given connection network through multiple ports. There is no provision in the HPR-IP architecture for variations in TOS Precedence values for a single connection network based on the port through which traffic is flowing to the connection network. Thus an entry in this table overrides the port-level settings for all the ports through which the node can reach the connection network." ::= { hprIp 4 } hprIpCnEntry OBJECT-TYPE SYNTAX HprIpCnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of the HPR/IP connection network table." INDEX { hprIpCnVrnName, hprIpCnAppnTrafficType } ::= { hprIpCnTable 1 } HprIpCnEntry ::= SEQUENCE { hprIpCnVrnName SnaControlPointName, hprIpCnAppnTrafficType AppnTrafficType, hprIpCnTOSPrecedence AppnTOSPrecedence, hprIpCnRowStatus RowStatus } hprIpCnVrnName OBJECT-TYPE SYNTAX SnaControlPointName MAX-ACCESS not-accessible STATUS current DESCRIPTION "SNA control point name of the virtual routing node (VRN) that Clouston & Moore Standards Track [Page 13] RFC 2584 APPN/HPR in IP Networks MIB May 1999 identifies the connection network in the APPN topology database. If this object has the same value as the appnVrnName in the APPN MIB, then the two objects are referring to the same APPN VRN." ::= { hprIpCnEntry 1 } hprIpCnAppnTrafficType OBJECT-TYPE SYNTAX AppnTrafficType MAX-ACCESS not-accessible STATUS current DESCRIPTION "APPN traffic type sent to this connection network." ::= { hprIpCnEntry 2 } hprIpCnTOSPrecedence OBJECT-TYPE SYNTAX AppnTOSPrecedence MAX-ACCESS read-create STATUS current DESCRIPTION "A setting for the three TOS Precedence bits in the IP Type of Service field for this APPN traffic type. This setting applies to all traffic sent to this connection network by this node, regardless of the port through which the traffic is sent. When this value is changed via a Set operation, the new setting for the TOS Precedence bits takes effect immediately, rather than waiting for some event such as reinitialization of a port or of the APPN node itself." ::= { hprIpCnEntry 3 } hprIpCnRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the hprIpCnTable. As soon as an entry becomes active, the mapping between APPN traffic types and TOS Precedence settings that it specifies becomes effective. The value of the other accessible object in this entry, hprIpCnTOSPrecedence, can be changed via a Set operation when this object's value is active(1). An entry in this table is deleted by setting this object to destroy(6). Deleting an entry in this table causes the Clouston & Moore Standards Track [Page 14] RFC 2584 APPN/HPR in IP Networks MIB May 1999 connection network to revert to the default TOS Precedence mapping for each port through which it is accessed." ::= { hprIpCnEntry 4 } -- ******************************************************************* -- Conformance Statement -- ******************************************************************* -- Definitions imported from the HPR MIB: -- hprConformance OBJECT IDENTIFIER ::= { hprMIB 2 } -- hprCompliances OBJECT IDENTIFIER ::= { hprConformance 1 } -- hprGroups OBJECT IDENTIFIER ::= { hprConformance 2 } -- Compliance statements hprIpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for the HPR over IP MIB module." MODULE -- this module -- Conditionally mandatory groups GROUP hprIpMonitoringGroup DESCRIPTION "The hprIpMonitoringGroup is mandatory for APPN implementations supporting HPR over IP." GROUP hprIpConfigurationGroup DESCRIPTION "The hprIpConfigurationGroup is mandatory for APPN implementations supporting HPR over IP. It may, however, be implemented as a collection of read-only objects." OBJECT hprIpAppnPortTOSPrecedence MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT hprIpLsTOSPrecedence MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT hprIpLsRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." Clouston & Moore Standards Track [Page 15] RFC 2584 APPN/HPR in IP Networks MIB May 1999 OBJECT hprIpCnTOSPrecedence MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT hprIpCnRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { hprCompliances 2 } -- Group definitions hprIpMonitoringGroup OBJECT-GROUP OBJECTS { hprIpActiveLsUdpPackets } STATUS current DESCRIPTION "An object for counting outgoing HPR/IP traffic for each APPN traffic type." ::= { hprGroups 5 } hprIpConfigurationGroup OBJECT-GROUP OBJECTS { hprIpAppnPortTOSPrecedence, hprIpLsTOSPrecedence, hprIpLsRowStatus, hprIpCnTOSPrecedence, hprIpCnRowStatus } STATUS current DESCRIPTION "A collection of HPR/IP objects representing the mappings between APPN traffic types and TOS Precedence bits at the APPN port, APPN link station, and APPN connection network levels." ::= { hprGroups 6 } END 5. Security Considerations Certain management information defined in this MIB may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. An authentication protocol is defined in [12]. A protocol for access control is defined in [15]. It is a customer responsibility to properly set up access control for MIB access. Clouston & Moore Standards Track [Page 16] RFC 2584 APPN/HPR in IP Networks MIB May 1999 None of the read-only objects in this MIB reports a password, user data, or anything else that is particularly sensitive. Some enterprises view their network configuration itself, as well as information about network usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. The one read-write and four read-create objects in the MIB can affect network operations; it is recommended that SNMP access to these objects be restricted. The five objects are: o hprIpPortTOSPrecedence: Setting this object immediately changes the mapping for all link stations using this port which do not have an entry to override the port value. Improper mappings may cause delays or disruptions in the network. For example, if APPN traffic type 'High' is mapped to IP TOS Precedence bits ' 001', network control traffic will have the same TOS precedence as bulk data traffic. This may cause delays with session initializations, and timeouts on control sessions that could cause network outages. o hprIpLsTOSPrecedence: Setting this object has the potential for delay or disruption for this link station as described above with hprIpPortTOSPrecedence. o hprIpLsRowStatus: Setting this object to delete(6) causes this link station to revert to the default TOS Precedence mapping for its port. The customized mapping for this link station will no longer be in effect. o hprIpCnTOSPrecedence: Setting this object has the potential for delay or disruption for this links created for this connection network as described above with hprIpPortTOSPrecedence. o hprIpCnRowStatus: Setting this object to delete(6) causes links created for this connection network to revert to the default TOS Precedence mapping for its port. The customized mapping for this connection network will no longer be in effect. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and Clouston & Moore Standards Track [Page 17] RFC 2584 APPN/HPR in IP Networks MIB May 1999 standards-related documentation can be found in BCP-11 [16]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments This MIB module is the product of the IETF SNA NAU MIB WG and the AIW APPN/HPR MIBs SIG. The editors would like to thank Katie Lee, IBM Corporation, for her work in creating the original version of this MIB. 8. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998 [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Clouston & Moore Standards Track [Page 18] RFC 2584 APPN/HPR in IP Networks MIB May 1999 [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. [16] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [18] Dudley, G, "APPN/HPR in IP Networks", RFC 2353, May 1998. [19] Clouston, B. and B. Moore, "Definition of Managed Objects for APPN", RFC 2455, November 1998. [20] Clouston, B. and B. Moore, "Definitions of Managed Objects for HPR", RFC 2238, May 1997. [21] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. Clouston & Moore Standards Track [Page 19] RFC 2584 APPN/HPR in IP Networks MIB May 1999 9. Authors' Addresses Bob Clouston Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709, USA Phone: +1 919 472 2333 EMail: clouston@cisco.com Robert Moore Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA Phone: +1 919 254 4436 EMail: remoore@us.ibm.com Clouston & Moore Standards Track [Page 20] RFC 2584 APPN/HPR in IP Networks MIB May 1999 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Clouston & Moore Standards Track [Page 21] snmp-mibs-downloader-1.1/mibrfcs/rfc2594.txt0000644000000000000000000025545411402176071015604 0ustar Network Working Group H. Hazewinkel Request for Comments: 2594 Joint Research Centre of the E.C. Category: Standards Track C. Kalbfleisch Verio, Inc. J. Schoenwaelder TU Braunschweig May 1999 Definitions of Managed Objects for WWW Services 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. Table of Contents 1 Introduction ................................................. 1 2 The SNMP Management Framework ................................ 2 3 Terminology .................................................. 3 4 Overview ..................................................... 4 4.1 Purpose and Requirements ................................... 4 4.2 Relationship to other Standards Efforts .................... 5 4.3 WWW Services ............................................... 5 4.4 Document Transfer Protocol ................................. 6 5 Structure of the MIB ......................................... 7 5.1 Service Information Group .................................. 7 5.2 Protocol Statistics Group .................................. 7 5.3 Document Statistics Group .................................. 8 6 Definitions .................................................. 10 7 Document Transfer Protocol Mappings .......................... 36 7.1 The HyperText Transfer Protocol ............................ 36 7.2 The File Transfer Protocol ................................. 37 8 Security Considerations ...................................... 38 9 Intellectual Property ........................................ 39 10 Acknowledgments ............................................. 39 Hazewinkel, et al. Standards Track [Page 1] RFC 2594 WWW Service MIB May 1999 11 Editors' Addresses .......................................... 39 12 References .................................................. 40 13 Full Copyright Statement .................................... 43 1. Introduction This memo defines a set of objects for managing World Wide Web (WWW) services. This MIB extends the application management framework defined by the System Application Management MIB (SYSAPPL-MIB) [23] and the Application Management MIB (APPLICATION-MIB) [24]. The MIB is also self-contained so that it can be implemented and used without having to implement or install the APPLICATION-MIB or the SYSAPPL- MIB. The protocol statistics defined in the WWW Service MIB are based on an abstract document transfer protocol (DTP). This memo also defines a mapping of the abstract DTP to HTTP and FTP. Additional mappings may be defined in the future in order to use this MIB with other document transfer protocols. It is anticipated that such future mappings will be defined in separate RFCs. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [17]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. Hazewinkel, et al. Standards Track [Page 2] RFC 2594 WWW Service MIB May 1999 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Terminology This section defines the terminology used throughout this document. o The 'World Wide Web' (WWW) is a world wide information system which is based on the concept of documents that are linked together by embedding references (links) to other local or remote documents. o A 'document' is a coherent piece of data which is accessible in the World Wide Web. No assumptions are made about the content or the type of a document. o A 'Uniform Resource Locator' (URL) is a formatted string representation for a document available via the Internet. URLs are used to express references between documents. For the syntax and semantics of the URL string representation refer to RFC 2396 [18] o A 'Document Transfer Protocol' (DTP) is a protocol used within the World Wide Web to invoke actions on documents. The DTP is an abstraction from real protocols, such as HTTP [19,20] or FTP [21]. Hazewinkel, et al. Standards Track [Page 3] RFC 2594 WWW Service MIB May 1999 o A 'request' is a DTP protocol operation which is targeted to a 'document' and invokes an action on the target document. The request type specifies the action that should be performed. A request can have a document associated with it. o A 'response' is a DTP protocol operation which is returned as a result of a previous (and associated) request. The response status indicates if the requested action was successful or if errors occurred. A response can have a document associated with it. o A 'WWW service' is a set of actions that can be invoked on a document. Typical actions are the transfer of documents or the retrieval of administrative information about documents. WWW services are provided by means of a DTP. A WWW service can be identified by the DTP protocol used to invoke services and the transport endpoint used by that protocol. o A 'client' is a program which establishes connections for the purpose of sending requests and receiving responses. o A 'server' is a program that accepts connections in order to service requests by sending back responses. o A 'proxy' is an intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. o A 'caching proxy' is a proxy with the capability of locally storing responses to associated requests. A caching proxy can respond to similar requests with a previously stored response. 4. Overview The World Wide Web (WWW) is a global network of information. Information is stored in documents, which can have various formats, including hyper-text and multi-media documents. Access to these documents is provided by servers which are located all around the world and are linked to each other via hyper-links embedded in documents. The usability of the World Wide Web depends largely on the performance of the services realized by these servers. The services are typically monitored through log files. This becomes a difficult task when a single organization is responsible for a large number of services. It is therefore desirable to treat WWW services as objects that can be managed by using the Internet network management framework [22]. Hazewinkel, et al. Standards Track [Page 4] RFC 2594 WWW Service MIB May 1999 4.1. Purpose and Requirements The goal of this MIB is to define a standardized set of objects which lead to integrated and improved performance and fault management in a heterogeneous environment of WWW services. This MIB focuses on the service-oriented view. It does not deal with the process oriented view, which is covered by the System Application MIB [23] and the Application MIB [24]. This document defines a set of managed objects to monitor WWW services for short-term operational purposes, such as problem detection and troubleshooting. No attempts are made here to cover accounting or hit metering issues. The scope of the MIB is further limited by the requirement that an implementation conforming to this MIB must be possible without putting a huge CPU or memory burden on the WWW server implementation. In addition, this MIB does not cover WWW service configuration. Server software has become an open market where competing vendors constantly invent new features in order to shape their products. It is therefore not possible to reach consensus on a common way to configure WWW services at this point in time. 4.2. Relationship to other Standards Efforts The WWW Service MIB fits into the application management architecture defined in the System Application MIB [23]. The System Application MIB and the Application MIB [24] use a process-oriented view, where an application is viewed as a collection of processes. The WWW Service MIB described in this memo uses a service-oriented view, which looks at the services provided by a set of processes. The relationship between the process-oriented view and the service- oriented view is a many-to-many relationship, because one process can implement multiple services and multiple services can be implemented by a single set of processes. The Application Management MIB [24] contains generic mapping tables, which map back and forth between both views. The WWW Service MIB interfaces to the Application MIB [24] by using the service instance identifier (applSrvIndex) for wwwServiceIndex if an applicable instance of applSrvIndex is available. The WWW Service MIB is self-contained and can be implemented as a stand-alone module if the service-level tables in the Application MIB are not available. Hazewinkel, et al. Standards Track [Page 5] RFC 2594 WWW Service MIB May 1999 4.3. WWW Services The MIB is organized around the concept of WWW services. WWW services are a set of actions that can be invoked on a document. A WWW service is provided or used by either a client, a server or a proxy. Clients send out requests for information to server or proxy server. Servers receive, process and respond to requests received from clients. Servers usually have access to local documents, which can be transferred to clients. A proxy is a special server, who acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy is able to translate between the client and the origin server. A proxy might also interact with other information retrieval system, like for example databases. The MIB defined in this memo distinguishes between outgoing and incoming requests and responses. This makes it possible to obtain statistics for clients, servers and proxies with a single set of objects. A special proxy server is the caching proxy, which maintains a cache of previously received documents in order to reduce the bandwidth used by World Wide Web clients. One interesting piece of management information is the percentage of requests that were served from the cache of the caching proxy (hits/miss-ratio). This ratio is not contained explicitly in this MIB. Instead, the ratio can be derived from the objects that count incoming and outgoing requests and responses. 4.4. Document Transfer Protocol The MIB is based on the concept of an abstract document transfer protocol (DTP). The purpose of the abstract document transfer protocol is to make the MIB definitions independent from concrete protocols, like the Hypertext Transfer Protocol (HTTP) [19,20] or the File Transfer Protocol (FTP) [21]. The abstract document transfer protocol makes the following assumptions about a concrete transfer protocol: o The transfer protocol uses a request/response style of interactions. o Every request contains a request type, which defines the operations performed by the receiving server. The request type is represented by an OCTET STRING. It might be necessary to define a translation into an OCTET STRING value for protocols that use numbers to identify request types. Hazewinkel, et al. Standards Track [Page 6] RFC 2594 WWW Service MIB May 1999 o A response contains a status code, which indicates if the request was processed successfully or which error occurred. The status code is represented as an INTEGER value. It might be necessary to define a mapping for protocols that do not use an INTEGER status code. o A transfer protocol can send multiple responses for a single request. Multiple responses are counted separately in the protocol statistics group. A primary response has to be identified for the document statistics. The primary response is the response that indicates whether the request was successful. Section 7 of this memo defines a mapping of the document transfer protocol to the HTTP protocol and the FTP protocol. Mappings to other protocols, like NNTP [25] or WebNFS [26,27] might be defined in the future. 5. Structure of the MIB This section presents the structure of the MIB. The objects are arranged into the following groups: o service information o protocol statistics o document statistics 5.1. Service Information Group The service information group consists of a single table describing all the WWW services managed by the SNMP agent. The service table contains administrative network management information for (potentially) multiple WWW services running on a single host. It also contains information for all services within virtual domains of a host. The columnar objects in the table can be divided into two main groups: o global administrative information of the service, such as service contact person, and o network information, such as the transfer protocol. Hazewinkel, et al. Standards Track [Page 7] RFC 2594 WWW Service MIB May 1999 5.2. Protocol Statistics Group The protocol statistics group provides network management information about the traffic received or transmitted by a WWW service. This group contains counters related to DTP protocol operations and consists of five tables: o The wwwSummaryTable contains a set of network traffic related counters. The table provides a summarization of the network traffic and protocol operations related to a WWW service. It is well recognized that certain variables are redundant with respect to the request and response tables, but they are added to provide an operator a quick overview and to reduce SNMP network traffic. o The wwwRequestInTable contains detailed information about incoming requests. Every particular request type is counted separately. o The wwwRequestOutTable contains detailed information about outgoing requests. Every particular request type is counted separately. o The wwwResponseInTable contains detailed information about incoming responses. Every particular response type is counted separately. o The wwwResponseOutTable contains detailed information about outgoing responses. Every particular response type is counted separately. 5.3. Document Statistics Group The document group contains information about the documents which were accessed in the past. The group provides four types of statistics. 1. Details about the last N attempts to invoke actions on documents. 2. The Top N documents sorted by the number of actions invoked on them computed over a time interval. 3. The Top N documents sorted by the number of content bytes transferred computed over a time interval. 4. Summary statistics computed over a time interval. Hazewinkel, et al. Standards Track [Page 8] RFC 2594 WWW Service MIB May 1999 The Top N document statistics are collected in buckets in order to reduce agent resources and to allow a manager to detect changes in the service usage pattern. Buckets are filled over a configurable time interval. The agent computes the Top N statistics and starts a new bucket once the time interval for the bucket has passed. The time interval is configurable for each WWW service. The document statistics group associates a response type to the request which invoked an action. In case a DTP sends multiple responses, the primary response must be used to derive the response type of the request/response interaction. The group consist of the following tables: o The wwwDocCtrlTable provides the manager a means to limit the document statistic tables in size and to control the expiration and creation of buckets. o The wwwDocLastNTable provides the manager information about the last N documents which where accessed. The table lists the documents for which access was attempted along with the request and response type of the DTP and a status message. The request and response types provide a manager information of how attempts to invoke actions were handled by the DTP. The status message object provides human readable text to further describe the response type. The number of documents in the wwwDocLastNTable is controlled by the wwwDocCtrlLastNSize object in the wwwDocCtrlTable. The wwwDocCtrlLastNLock object of the wwwDocCtrlTable allows a management application to lock the wwwDocLastNTable in order to retrieve a consistent snapshot of the fast changing wwwDocLastNTable. o The wwwDocBucketTable lists the buckets of statistical information that have been collected. An entry in the wwwDocBucketTable contains the creation timestamp of the bucket as well as summary information (number of accesses, number of documents accessed and number of bytes transferred). The time interval is controlled by the wwwDocCtrlBucketTimeInterval object of the wwwDocCtrlTable. The maximum number of buckets maintained by the SNMP agent for a particular WWW service is controlled by the wwwDocCtrlBuckets object of the wwwDocCtrlTable. o The wwwDocAccessTopNTable provides the manager an overview of the top N documents which were accessed while statistics were collected for a particular bucket. The wwwDocAccessTopNTable is Hazewinkel, et al. Standards Track [Page 9] RFC 2594 WWW Service MIB May 1999 sorted by the number of read attempts per document. The maximum number of entries in the wwwDocAccessTopNTable is controlled by the wwwDocCtrlTopNSize object. o The wwwDocBytesTopNTable provides the manager an overview of the top N documents which caused most of the network traffic while statistics were collected for a particular bucket. The wwwDocBytesTopNTable is sorted by the number of bytes transferred. The maximum number of entries in the wwwDocBytesTopNTable is controlled by the wwwDocCtrlTopNSize object. The Top N statistics and the parameters of the underlying bucket are not visible in the MIB as long as the bucket is filling up. Instead, the following steps must be taken when the time interval for a buckets has passed: 1. A new entry in the wwwDocBucketTable is created to summarize the document statistics for that time interval. 2. The corresponding entries in the wwwDocAccessTopNTable and the wwwDocBytesTopNTable are computed and made available. 3. If the resulting number of entries in the wwwDocBucketTable for the WWW service now exceeds wwwDocCtrlBuckets, then the oldest bucket for this WWW service and all corresponding entries in the wwwDocBucketTable, wwwDocAccessTopNTable, and wwwDocBytesTopNTable are deleted. Note that a bucket usually contains much more data than displayed in the Top N tables. The number of entries in the Top N table for a bucket is controlled by wwwDocCtrlTopNSize, while the number of entries in a bucket depends on the number of actions invoked on documents within the time interval over which a bucket is filled up. It is therefore suggested to discard the data associated with a bucket once the entries for the wwwDocBucketTable, wwwDocAccessTopNTable and wwwDocBytesTopNTable have been calculated. 6. Definitions WWW-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Counter32, Counter64, Integer32, Unsigned32, TimeTicks FROM SNMPv2-SMI Hazewinkel, et al. Standards Track [Page 10] RFC 2594 WWW Service MIB May 1999 TEXTUAL-CONVENTION, DisplayString, DateAndTime, TimeInterval FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF Utf8String FROM SYSAPPL-MIB; wwwMIB MODULE-IDENTITY LAST-UPDATED "9902251400Z" ORGANIZATION "IETF Application MIB Working Group" CONTACT-INFO " Harrie Hazewinkel Postal: Joint Research Centre of the E.C. via Fermi - Ispra 21020 (VA) Italy Tel: +39+(0)332 786322 Fax: +39+(0)332 785641 E-mail: harrie.hazewinkel@jrc.it Carl W. Kalbfleisch Postal: Verio, Inc. 1950 Stemmons Freeway Suite 2006 Dallas, TX 75207 US Tel: +1 214 290-8653 Fax: +1 214 744-0742 E-mail: cwk@verio.net Juergen Schoenwaelder Postal: TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Tel: +49 531 391-3683 Fax: +49 531 489-5936 E-mail: schoenw@ibr.cs.tu-bs.de" DESCRIPTION "This WWW service MIB module is applicable to services realized by a family of 'Document Transfer Protocols' (DTP). Examples of DTPs are HTTP and FTP." Hazewinkel, et al. Standards Track [Page 11] RFC 2594 WWW Service MIB May 1999 -- revision history REVISION "9902251400Z" DESCRIPTION "Initial version, published as RFC2594." ::= { mib-2 65 } -- -- Object Identifier Assignments -- wwwMIBObjects OBJECT IDENTIFIER ::= { wwwMIB 1 } wwwMIBConformance OBJECT IDENTIFIER ::= { wwwMIB 2 } -- -- Textual Conventions -- WwwRequestType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The WwwRequestType defines the textual identification of request types used by a document transfer protocol. For the proper values for a given DTP, refer to the protocol mappings for that DTP." SYNTAX OCTET STRING (SIZE (1..40)) WwwResponseType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The WwwResponseType defines the different response values used by document transfer protocols. For the proper values for a given DTP, refer to the protocol mappings for that DTP." SYNTAX Integer32 (0..2147483647) WwwOperStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The operational status of a WWW service. 'down' indicates that the service is not available. 'running' indicates that the service is operational and available. 'halted' indicates that the service is operational but not available. 'congested' indicates that the service is operational but no additional inbound associations can be accommodated. 'restarting' indicates that the service is currently unavailable but is in the process of restarting and will be available soon." SYNTAX INTEGER { down(1), Hazewinkel, et al. Standards Track [Page 12] RFC 2594 WWW Service MIB May 1999 running(2), halted(3), congested(4), restarting(5) } WwwDocName ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "The server relative name of a document. If the URL were http://www.x.org/standards/search/search.cgi?string=test then the value of this textual convention would resolve to '/standards/search/search.cgi'. This textual convention uses the character set for URIs as defined in RFC 2396 section 2." SYNTAX OCTET STRING (SIZE (0..255)) -- The WWW Service Information Group -- -- The WWW service information group contains information about -- the WWW services known by the SNMP agent. wwwService OBJECT IDENTIFIER ::= { wwwMIBObjects 1 } wwwServiceTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwServiceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of the WWW services known by the SNMP agent." ::= { wwwService 1 } wwwServiceEntry OBJECT-TYPE SYNTAX WwwServiceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Details about a particular WWW service." INDEX { wwwServiceIndex } ::= { wwwServiceTable 1 } WwwServiceEntry ::= SEQUENCE { wwwServiceIndex Unsigned32, wwwServiceDescription Utf8String, wwwServiceContact Utf8String, wwwServiceProtocol OBJECT IDENTIFIER, wwwServiceName DisplayString, wwwServiceType INTEGER, Hazewinkel, et al. Standards Track [Page 13] RFC 2594 WWW Service MIB May 1999 wwwServiceStartTime DateAndTime, wwwServiceOperStatus WwwOperStatus, wwwServiceLastChange DateAndTime } wwwServiceIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer used to uniquely identify a WWW service. The value must be the same as the corresponding value of the applSrvIndex defined in the Application Management MIB (APPLICATION-MIB) if the applSrvIndex object is available. It might be necessary to manually configure sub-agents in order to meet this requirement." ::= { wwwServiceEntry 1 } wwwServiceDescription OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "Textual description of the WWW service. This shall include at least the vendor and version number of the application realizing the WWW service. In a minimal case, this might be the Product Token (see RFC 2068) for the application." ::= { wwwServiceEntry 2 } wwwServiceContact OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The textual identification of the contact person for this service, together with information on how to contact this person. For instance, this might be a string containing an email address, e.g. ''." ::= { wwwServiceEntry 3 } wwwServiceProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An identification of the primary protocol in use by this service. For Internet applications, the IANA maintains a registry of the OIDs which correspond to well-known application protocols. If the application protocol is not listed in the registry, an OID value of the form Hazewinkel, et al. Standards Track [Page 14] RFC 2594 WWW Service MIB May 1999 {applTCPProtoID port} or {applUDPProtoID port} are used for TCP-based and UDP-based protocols, respectively. In either case 'port' corresponds to the primary port number being used by the protocol." REFERENCE "The OID values applTCPProtoID and applUDPProtoID are defined in the NETWORK-SERVICES-MIB (RFC 2248)." ::= { wwwServiceEntry 4 } wwwServiceName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The fully qualified domain name by which this service is known. This object must contain the virtual host name if the service is realized for a virtual host." ::= { wwwServiceEntry 5 } wwwServiceType OBJECT-TYPE SYNTAX INTEGER { wwwOther(1), wwwServer(2), wwwClient(3), wwwProxy(4), wwwCachingProxy(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The application type using or realizing this WWW service." ::= { wwwServiceEntry 6 } wwwServiceStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when this WWW service was last started. The value SHALL be '0000000000000000'H if the last start time of this WWW service is not known." ::= { wwwServiceEntry 7 } wwwServiceOperStatus OBJECT-TYPE SYNTAX WwwOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the operational status of the WWW service." ::= { wwwServiceEntry 8 } Hazewinkel, et al. Standards Track [Page 15] RFC 2594 WWW Service MIB May 1999 wwwServiceLastChange OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when this WWW service entered its current operational state. The value SHALL be '0000000000000000'H if the time of the last state change is not known." ::= { wwwServiceEntry 9 } -- The WWW Protocol Statistics Group -- -- The WWW protocol statistics group contains statistics about -- the DTP requests and responses sent or received. wwwProtocolStatistics OBJECT IDENTIFIER ::= { wwwMIBObjects 2 } wwwSummaryTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table providing overview statistics for the WWW services on this system." ::= { wwwProtocolStatistics 1 } wwwSummaryEntry OBJECT-TYPE SYNTAX WwwSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Overview statistics for an individual service." INDEX { wwwServiceIndex } ::= { wwwSummaryTable 1 } WwwSummaryEntry ::= SEQUENCE { wwwSummaryInRequests Counter32, wwwSummaryOutRequests Counter32, wwwSummaryInResponses Counter32, wwwSummaryOutResponses Counter32, wwwSummaryInBytes Counter64, wwwSummaryInLowBytes Counter32, wwwSummaryOutBytes Counter64, wwwSummaryOutLowBytes Counter32 } wwwSummaryInRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Hazewinkel, et al. Standards Track [Page 16] RFC 2594 WWW Service MIB May 1999 STATUS current DESCRIPTION "The number of requests successfully received." ::= { wwwSummaryEntry 1 } wwwSummaryOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests generated." ::= { wwwSummaryEntry 2 } wwwSummaryInResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of responses successfully received." ::= { wwwSummaryEntry 3 } wwwSummaryOutResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of responses generated." ::= { wwwSummaryEntry 4 } wwwSummaryInBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of content bytes received." ::= { wwwSummaryEntry 5 } wwwSummaryInLowBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest thirty-two bits of wwwSummaryInBytes." ::= { wwwSummaryEntry 6 } wwwSummaryOutBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION Hazewinkel, et al. Standards Track [Page 17] RFC 2594 WWW Service MIB May 1999 "The number of content bytes transmitted." ::= { wwwSummaryEntry 7 } wwwSummaryOutLowBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest thirty-two bits of wwwSummaryOutBytes." ::= { wwwSummaryEntry 8 } -- The WWW request tables contain detailed information about -- requests send or received by WWW services. wwwRequestInTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwRequestInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table providing detailed statistics for requests received by WWW services on this system." ::= { wwwProtocolStatistics 2 } wwwRequestInEntry OBJECT-TYPE SYNTAX WwwRequestInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Request statistics for an individual service." INDEX { wwwServiceIndex, wwwRequestInIndex } ::= { wwwRequestInTable 1 } WwwRequestInEntry ::= SEQUENCE { wwwRequestInIndex WwwRequestType, wwwRequestInRequests Counter32, wwwRequestInBytes Counter32, wwwRequestInLastTime DateAndTime } wwwRequestInIndex OBJECT-TYPE SYNTAX WwwRequestType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The particular request type the statistics apply to." ::= { wwwRequestInEntry 1 } wwwRequestInRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Hazewinkel, et al. Standards Track [Page 18] RFC 2594 WWW Service MIB May 1999 STATUS current DESCRIPTION "The number of requests of this type received by this WWW service." ::= { wwwRequestInEntry 2 } wwwRequestInBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of content bytes per request type received by this WWW service." ::= { wwwRequestInEntry 3 } wwwRequestInLastTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the last byte of the last complete request of this type was received by this WWW service. The value SHALL be '0000000000000000'H if no request of this type has been received yet." ::= { wwwRequestInEntry 4 } wwwRequestOutTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwRequestOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table providing detailed statistics for requests generated by the services on this system." ::= { wwwProtocolStatistics 3 } wwwRequestOutEntry OBJECT-TYPE SYNTAX WwwRequestOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Request statistics for an individual service." INDEX { wwwServiceIndex, wwwRequestOutIndex } ::= { wwwRequestOutTable 1 } WwwRequestOutEntry ::= SEQUENCE { wwwRequestOutIndex WwwRequestType, wwwRequestOutRequests Counter32, wwwRequestOutBytes Counter32, wwwRequestOutLastTime DateAndTime } Hazewinkel, et al. Standards Track [Page 19] RFC 2594 WWW Service MIB May 1999 wwwRequestOutIndex OBJECT-TYPE SYNTAX WwwRequestType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The particular request type the statistics apply to." ::= { wwwRequestOutEntry 1 } wwwRequestOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests of this type generated by this WWW service." ::= { wwwRequestOutEntry 2 } wwwRequestOutBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of content bytes per requests type generated by this WWW service." ::= { wwwRequestOutEntry 3 } wwwRequestOutLastTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the first byte of the last request of this type was send by this WWW service. The value SHALL be '0000000000000000'H if no request of this type has been send yet." ::= { wwwRequestOutEntry 4 } -- The WWW response tables contain detailed information about -- responses sent or received by WWW services. wwwResponseInTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwResponseInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table providing detailed statistics for responses received by WWW services on this system." ::= { wwwProtocolStatistics 4 } wwwResponseInEntry OBJECT-TYPE Hazewinkel, et al. Standards Track [Page 20] RFC 2594 WWW Service MIB May 1999 SYNTAX WwwResponseInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Response statistics for an individual service." INDEX { wwwServiceIndex, wwwResponseInIndex } ::= { wwwResponseInTable 1 } WwwResponseInEntry ::= SEQUENCE { wwwResponseInIndex WwwResponseType, wwwResponseInResponses Counter32, wwwResponseInBytes Counter32, wwwResponseInLastTime DateAndTime } wwwResponseInIndex OBJECT-TYPE SYNTAX WwwResponseType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The particular response type the statistics apply to." ::= { wwwResponseInEntry 1 } wwwResponseInResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of responses of this type received by this WWW service." ::= { wwwResponseInEntry 2 } wwwResponseInBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of content bytes per response type received by this WWW service." ::= { wwwResponseInEntry 3 } wwwResponseInLastTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the last byte of the last complete response of this type was received by this WWW service. The value SHALL be '0000000000000000'H if no response of this type has been received yet." Hazewinkel, et al. Standards Track [Page 21] RFC 2594 WWW Service MIB May 1999 ::= { wwwResponseInEntry 4 } wwwResponseOutTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwResponseOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table providing detailed statistics for responses generated by services on this system." ::= { wwwProtocolStatistics 5 } wwwResponseOutEntry OBJECT-TYPE SYNTAX WwwResponseOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Response statistics for an individual service." INDEX { wwwServiceIndex, wwwResponseOutIndex } ::= { wwwResponseOutTable 1 } WwwResponseOutEntry ::= SEQUENCE { wwwResponseOutIndex WwwResponseType, wwwResponseOutResponses Counter32, wwwResponseOutBytes Counter32, wwwResponseOutLastTime DateAndTime } wwwResponseOutIndex OBJECT-TYPE SYNTAX WwwResponseType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The particular response type the statistics apply to." ::= { wwwResponseOutEntry 1 } wwwResponseOutResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of responses of this type generated by this WWW service." ::= { wwwResponseOutEntry 2 } wwwResponseOutBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of content bytes per response type generated Hazewinkel, et al. Standards Track [Page 22] RFC 2594 WWW Service MIB May 1999 by this WWW service." ::= { wwwResponseOutEntry 3 } wwwResponseOutLastTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the first byte of the last response of this type was sent by this WWW service. The value SHALL be '0000000000000000'H if response of this type has been send yet." ::= { wwwResponseOutEntry 4 } -- The WWW Document Statistics Group -- -- The WWW document statistics group contains statistics about -- document read attempts. wwwDocumentStatistics OBJECT IDENTIFIER ::= { wwwMIBObjects 3 } wwwDocCtrlTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwDocCtrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table which controls how the MIB implementation collects and maintains document statistics." ::= { wwwDocumentStatistics 1 } wwwDocCtrlEntry OBJECT-TYPE SYNTAX WwwDocCtrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry used to configure the wwwDocLastNTable, the wwwDocBucketTable, the wwwDocAccessTopNTable, and the wwwDocBytesTopNTable." INDEX { wwwServiceIndex } ::= { wwwDocCtrlTable 1 } WwwDocCtrlEntry ::= SEQUENCE { wwwDocCtrlLastNSize Unsigned32, wwwDocCtrlLastNLock TimeTicks, wwwDocCtrlBuckets Unsigned32, wwwDocCtrlBucketTimeInterval TimeInterval, wwwDocCtrlTopNSize Unsigned32 } Hazewinkel, et al. Standards Track [Page 23] RFC 2594 WWW Service MIB May 1999 wwwDocCtrlLastNSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries in the wwwDocLastNTable." DEFVAL { 25 } ::= { wwwDocCtrlEntry 1 } wwwDocCtrlLastNLock OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows a manager to lock the wwwDocLastNTable in order to retrieve the wwwDocLastNTable in a consistent state. The agent is expected to take a snapshot of the wwwDocLastNTable when it is locked and to continue updating the real wwwDocLastNTable table so that recent information is available as soon as the wwwDocLastNTable is unlocked again. Setting this object to a value greater than 0 will lock the table. The timer ticks backwards until it reaches 0. The table unlocks automatically once the timer reaches 0 and the timer stops ticking. A manager can increase the timer to request more time to read the table. However, any attempt to decrease the timer will fail with an inconsistentValue error. This rule ensures that multiple managers can simultaneously lock and retrieve the wwwDocLastNTable. Note that managers must cooperate in using wwwDocCtrlLastNLock. In particular, a manager MUST not keep the wwwDocLastNTable locked when it is not necessary to finish a retrieval operation." ::= { wwwDocCtrlEntry 2 } wwwDocCtrlBuckets OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of buckets maintained by the agent before the oldest bucket is deleted. The buckets are used to populate the wwwDocAccessTopNTable and the wwwDocBytesTopNTable. The time interval captured in each bucket can be configured by setting the wwwDocCtrlBucketTimeInterval object." DEFVAL { 4 } -- 4 buckets times 15 minutes = 1 hour ::= { wwwDocCtrlEntry 3 } Hazewinkel, et al. Standards Track [Page 24] RFC 2594 WWW Service MIB May 1999 wwwDocCtrlBucketTimeInterval OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "The time interval after which a new bucket is created. Changing this object has no effect on existing buckets." DEFVAL { 90000 } -- 15 minutes (resolution .01 s) ::= { wwwDocCtrlEntry 4 } wwwDocCtrlTopNSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of entries shown in the wwwDocAccessTopNTable and the wwwDocBytesTopNTable. Changing this object has no effect on existing buckets." DEFVAL { 25 } ::= { wwwDocCtrlEntry 5 } wwwDocLastNTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwDocLastNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table which logs the last N access attempts." ::= { wwwDocumentStatistics 2 } wwwDocLastNEntry OBJECT-TYPE SYNTAX WwwDocLastNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry which describes a recent access attempt." INDEX { wwwServiceIndex, wwwDocLastNIndex } ::= { wwwDocLastNTable 1 } WwwDocLastNEntry ::= SEQUENCE { wwwDocLastNIndex Unsigned32, wwwDocLastNName WwwDocName, wwwDocLastNTimeStamp DateAndTime, wwwDocLastNRequestType WwwRequestType, wwwDocLastNResponseType WwwResponseType, wwwDocLastNStatusMsg Utf8String, wwwDocLastNBytes Unsigned32 } wwwDocLastNIndex OBJECT-TYPE Hazewinkel, et al. Standards Track [Page 25] RFC 2594 WWW Service MIB May 1999 SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary monotonically increasing integer number used for indexing the wwwDocLastNTable. The first document accessed appears in the table with this index value equal to one. Each subsequent document is indexed with the next sequential index value. The Nth document accessed will be indexed by N. This table presents a sliding window of the last wwwDocCtrlLastNSize documents accessed. Thus, entries in this table will be indexed by N-wwwDocCtrlLastNSize thru N if N > wwwDocCtrlLastNSize and 1 thru N if N <= wwwDocCtrlLastNSize. The wwwDocCtrlLastNLock attribute can be used to lock this table to allow the manager to read its contents." ::= { wwwDocLastNEntry 1 } wwwDocLastNName OBJECT-TYPE SYNTAX WwwDocName MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the document for which access was attempted." ::= { wwwDocLastNEntry 2 } wwwDocLastNTimeStamp OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time of the last attempt to access this document." ::= { wwwDocLastNEntry 3 } wwwDocLastNRequestType OBJECT-TYPE SYNTAX WwwRequestType MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol request type which was received by the server when this document access was attempted." ::= { wwwDocLastNEntry 4 } wwwDocLastNResponseType OBJECT-TYPE SYNTAX WwwResponseType MAX-ACCESS read-only STATUS current DESCRIPTION Hazewinkel, et al. Standards Track [Page 26] RFC 2594 WWW Service MIB May 1999 "The protocol response type which was sent to the client as a result of this attempt to access a document. This object contains the type of the primary response if there were multiple responses to a single request." ::= { wwwDocLastNEntry 5 } wwwDocLastNStatusMsg OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a human readable description of the reason why the wwwDocLastNResponseType was returned to the client. This object defines the implementation-specific reason if the value of wwwDocLastNResponseType indicates an error. For example, this object can indicate that the requested document could not be transferred due to a timeout condition or the document could not be transferred because a 'soft link' pointing to the document could not be resolved." ::= { wwwDocLastNEntry 6 } wwwDocLastNBytes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of content bytes that were returned as a result of this attempt to access a document." ::= { wwwDocLastNEntry 7 } wwwDocBucketTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwDocBucketEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides administrative summary information for the buckets maintained per WWW service." ::= { wwwDocumentStatistics 3 } wwwDocBucketEntry OBJECT-TYPE SYNTAX WwwDocBucketEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry which describes the parameters associated with a particular bucket." INDEX { wwwServiceIndex, wwwDocBucketIndex } ::= { wwwDocBucketTable 1 } Hazewinkel, et al. Standards Track [Page 27] RFC 2594 WWW Service MIB May 1999 WwwDocBucketEntry ::= SEQUENCE { wwwDocBucketIndex Unsigned32, wwwDocBucketTimeStamp DateAndTime, wwwDocBucketAccesses Unsigned32, wwwDocBucketDocuments Unsigned32, wwwDocBucketBytes Unsigned32 } wwwDocBucketIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary monotonically increasing integer number used for indexing the wwwDocBucketTable. The index number wraps to 1 whenever the maximum value is reached." ::= { wwwDocBucketEntry 1 } wwwDocBucketTimeStamp OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the bucket was made available." ::= { wwwDocBucketEntry 2 } wwwDocBucketAccesses OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of access attempts for any document provided by this WWW service during the time interval over which this bucket was created." ::= { wwwDocBucketEntry 3 } wwwDocBucketDocuments OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of different documents for which access was attempted this this WWW service during the time interval over which this bucket was created." ::= { wwwDocBucketEntry 4 } wwwDocBucketBytes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Hazewinkel, et al. Standards Track [Page 28] RFC 2594 WWW Service MIB May 1999 DESCRIPTION "The total number of content bytes which were transferred from this WWW service during the time interval over which this bucket was created." ::= { wwwDocBucketEntry 5 } wwwDocAccessTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwDocAccessTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of the most frequently accessed documents in a given bucket. This table is sorted by the column wwwDocAccessTopNAccesses. Entries having the same number of accesses are secondarily sorted by wwwDocAccessTopNBytes. Entries with the same number of accesses and the same number of bytes will have an arbitrary order." ::= { wwwDocumentStatistics 4 } wwwDocAccessTopNEntry OBJECT-TYPE SYNTAX WwwDocAccessTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the top N table sorted by document accesses." INDEX { wwwServiceIndex, wwwDocBucketIndex, wwwDocAccessTopNIndex } ::= { wwwDocAccessTopNTable 1 } WwwDocAccessTopNEntry ::= SEQUENCE { wwwDocAccessTopNIndex Unsigned32, wwwDocAccessTopNName WwwDocName, wwwDocAccessTopNAccesses Unsigned32, wwwDocAccessTopNBytes Unsigned32, wwwDocAccessTopNLastResponseType WwwResponseType } wwwDocAccessTopNIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary monotonically increasing integer number used for indexing the wwwDocAccessTopNTable. The index is inversely correlated to the sorting order of the table. The document with the highest access count will get the index value 1." ::= { wwwDocAccessTopNEntry 1 } Hazewinkel, et al. Standards Track [Page 29] RFC 2594 WWW Service MIB May 1999 wwwDocAccessTopNName OBJECT-TYPE SYNTAX WwwDocName MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the document for which access was attempted." ::= { wwwDocAccessTopNEntry 2 } wwwDocAccessTopNAccesses OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of access attempts for this document." ::= { wwwDocAccessTopNEntry 3 } wwwDocAccessTopNBytes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of content bytes that were transmitted as a result of attempts to access this document." ::= { wwwDocAccessTopNEntry 4 } wwwDocAccessTopNLastResponseType OBJECT-TYPE SYNTAX WwwResponseType MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol response type which was sent to the client as a result of the last attempt to access this document. This object contains the type of the primary response if there were multiple responses to a single request." ::= { wwwDocAccessTopNEntry 5 } wwwDocBytesTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF WwwDocBytesTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of the documents which caused most network traffic in a given bucket. This table is sorted by the column wwwDocBytesTopNBytes. Entries having the same number bytes are secondarily sorted by wwwDocBytesTopNAccesses. Entries with the same number of accesses and the same number of bytes will have an arbitrary order." ::= { wwwDocumentStatistics 5 } Hazewinkel, et al. Standards Track [Page 30] RFC 2594 WWW Service MIB May 1999 wwwDocBytesTopNEntry OBJECT-TYPE SYNTAX WwwDocBytesTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the top N table sorted by network traffic." INDEX { wwwServiceIndex, wwwDocBucketIndex, wwwDocBytesTopNIndex } ::= { wwwDocBytesTopNTable 1 } WwwDocBytesTopNEntry ::= SEQUENCE { wwwDocBytesTopNIndex Unsigned32, wwwDocBytesTopNName WwwDocName, wwwDocBytesTopNAccesses Unsigned32, wwwDocBytesTopNBytes Unsigned32, wwwDocBytesTopNLastResponseType WwwResponseType } wwwDocBytesTopNIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary monotonically increasing integer number used for indexing the wwwDocBytesTopNTable. The index is inversely correlated to the sorting order of the table. The document with the highest byte count will get the index value 1." ::= { wwwDocBytesTopNEntry 1 } wwwDocBytesTopNName OBJECT-TYPE SYNTAX WwwDocName MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the document for which access was attempted." ::= { wwwDocBytesTopNEntry 2 } wwwDocBytesTopNAccesses OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of access attempts for this document." ::= { wwwDocBytesTopNEntry 3 } wwwDocBytesTopNBytes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Hazewinkel, et al. Standards Track [Page 31] RFC 2594 WWW Service MIB May 1999 DESCRIPTION "The total number of content bytes that were transmitted as a result of attempts to access this document." ::= { wwwDocBytesTopNEntry 4 } wwwDocBytesTopNLastResponseType OBJECT-TYPE SYNTAX WwwResponseType MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol response type which was sent to the client as a result of the last attempt to access this document. This object contains the type of the primary response if there were multiple responses to a single request." ::= { wwwDocBytesTopNEntry 5 } -- -- Conformance Definitions -- wwwMIBCompliances OBJECT IDENTIFIER ::= { wwwMIBConformance 1 } wwwMIBGroups OBJECT IDENTIFIER ::= { wwwMIBConformance 2 } wwwMinimalCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP agents which implement the minimal subset of the WWW-MIB. Implementors might choose this subset for high-performance server where full compliance might be to expensive." MODULE -- this module MANDATORY-GROUPS { wwwServiceGroup, wwwSummaryGroup } OBJECT wwwSummaryOutRequests DESCRIPTION "Instances of wwwSummaryOutRequests do not exist on pure WWW server implementations." OBJECT wwwSummaryInResponses DESCRIPTION "Instances of wwwSummaryOutRequests do not exist on pure WWW server implementations." OBJECT wwwSummaryInRequests DESCRIPTION "Instances of wwwSummaryInRequests do not exist on pure WWW client implementations." OBJECT wwwSummaryOutResponses DESCRIPTION "Instances of wwwSummaryOutResponses do not exist on pure Hazewinkel, et al. Standards Track [Page 32] RFC 2594 WWW Service MIB May 1999 WWW client implementations." ::= { wwwMIBCompliances 1 } wwwFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP agents which implement the full WWW-MIB." MODULE -- this module MANDATORY-GROUPS { wwwServiceGroup, wwwSummaryGroup } GROUP wwwRequestInGroup DESCRIPTION "The wwwRequestInGroup is mandatory only for WWW server or proxy server implementations." GROUP wwwResponseOutGroup DESCRIPTION "The wwwResponseOutGroup is mandatory only for WWW server or proxy server implementations." GROUP wwwRequestOutGroup DESCRIPTION "The wwwRequestOutGroup is mandatory only for WWW client or proxy server implementations." GROUP wwwResponseInGroup DESCRIPTION "The wwwRequestOutGroup is mandatory only for WWW client or proxy server implementations." GROUP wwwDocumentGroup DESCRIPTION "The wwwDocumentGroup is mandatory only for WWW server or proxy server implementations." OBJECT wwwSummaryOutRequests DESCRIPTION "Instances of wwwSummaryOutRequests do not exist on pure WWW server implementations." OBJECT wwwSummaryInResponses DESCRIPTION "Instances of wwwSummaryOutRequests do not exist on pure WWW server implementations." OBJECT wwwSummaryInRequests DESCRIPTION "Instances of wwwSummaryInRequests do not exist on pure WWW client implementations." OBJECT wwwSummaryOutResponses DESCRIPTION "Instances of wwwSummaryOutResponses do not exist on pure WWW client implementations." ::= { wwwMIBCompliances 2 } Hazewinkel, et al. Standards Track [Page 33] RFC 2594 WWW Service MIB May 1999 wwwServiceGroup OBJECT-GROUP OBJECTS { wwwServiceDescription, wwwServiceContact, wwwServiceProtocol, wwwServiceName, wwwServiceType, wwwServiceStartTime, wwwServiceOperStatus, wwwServiceLastChange } STATUS current DESCRIPTION "A collection of objects providing information about the WWW services known by the SNMP agent." ::= { wwwMIBGroups 1 } wwwSummaryGroup OBJECT-GROUP OBJECTS { wwwSummaryInRequests, wwwSummaryOutRequests, wwwSummaryInResponses, wwwSummaryOutResponses, wwwSummaryInBytes, wwwSummaryInLowBytes, wwwSummaryOutBytes, wwwSummaryOutLowBytes } STATUS current DESCRIPTION "A collection of objects providing summary statistics about requests and responses generated and received by a WWW service." ::= { wwwMIBGroups 2 } wwwRequestInGroup OBJECT-GROUP OBJECTS { wwwRequestInRequests, wwwRequestInBytes, wwwRequestInLastTime } STATUS current DESCRIPTION "A collection of objects providing detailed statistics about requests received by a WWW service." ::= { wwwMIBGroups 3 } wwwRequestOutGroup OBJECT-GROUP OBJECTS { wwwRequestOutRequests, Hazewinkel, et al. Standards Track [Page 34] RFC 2594 WWW Service MIB May 1999 wwwRequestOutBytes, wwwRequestOutLastTime } STATUS current DESCRIPTION "A collection of objects providing detailed statistics about requests generated by a WWW service." ::= { wwwMIBGroups 4 } wwwResponseInGroup OBJECT-GROUP OBJECTS { wwwResponseInResponses, wwwResponseInBytes, wwwResponseInLastTime } STATUS current DESCRIPTION "A collection of objects providing detailed statistics about responses received by a WWW service." ::= { wwwMIBGroups 5 } wwwResponseOutGroup OBJECT-GROUP OBJECTS { wwwResponseOutResponses, wwwResponseOutBytes, wwwResponseOutLastTime } STATUS current DESCRIPTION "A collection of objects providing detailed statistics about responses generated by a WWW service." ::= { wwwMIBGroups 6 } wwwDocumentGroup OBJECT-GROUP OBJECTS { wwwDocCtrlLastNSize, wwwDocCtrlLastNLock, wwwDocCtrlBuckets, wwwDocCtrlBucketTimeInterval, wwwDocCtrlTopNSize, wwwDocLastNName, wwwDocLastNTimeStamp, wwwDocLastNRequestType, wwwDocLastNResponseType, wwwDocLastNStatusMsg, wwwDocLastNBytes, wwwDocBucketTimeStamp, wwwDocBucketAccesses, wwwDocBucketDocuments, wwwDocBucketBytes, Hazewinkel, et al. Standards Track [Page 35] RFC 2594 WWW Service MIB May 1999 wwwDocAccessTopNName, wwwDocAccessTopNAccesses, wwwDocAccessTopNBytes, wwwDocAccessTopNLastResponseType, wwwDocBytesTopNName, wwwDocBytesTopNAccesses, wwwDocBytesTopNBytes, wwwDocBytesTopNLastResponseType } STATUS current DESCRIPTION "A collection of objects providing information about accesses to documents." ::= { wwwMIBGroups 7 } END 7. Document Transfer Protocol Mappings This section describes how existing protocols such as HTTP [19,20] and FTP [21] can be mapped on the abstract Document Transfer Protocol (DTP) used within the definitions of the WWW MIB. Every mapping must define the identifier which is used to uniquely identify the transfer protocol. In addition, the mappings must define how requests and responses are identified. 7.1. The HyperText Transfer Protocol The HyperText Transfer Protocol (HTTP) [19,20] is an application- level protocol used to transfer hypermedia documents in a distributed networked environment. HTTP is based on the request/response paradigm and can be mapped on the abstract DTP easily. The HTTP protocol usually runs over TCP and uses the well-known TCP port 80. Therefore, the default value for the wwwServiceProtocol object is { applTCPProtoID 80 }. HTTP allows for both requests and responses and an open-ended set of message types. The general message syntax of HTTP is therefore used for the protocol mapping. The BNF specification of the general HTTP message syntax as defined in [20] is as follows: generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | Status-Line Hazewinkel, et al. Standards Track [Page 36] RFC 2594 WWW Service MIB May 1999 Request-Line = Method SP Request-URI SP HTTP-Version CRLF Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Every HTTP-message where the start-line is a Request-Line is considered a request in the abstract DTP. Every HTTP-message where the start-line is a Status-Line is considered a response in the abstract DTP. The mappings of WwwRequestType and WwwResponseType are defined as follows: o The WwwRequestType corresponds to the method token in the Request-Line. o The WwwResponseType corresponds to the Status-Code in the Status-Line. 7.2. The File Transfer Protocol The File Transfer Protocol (FTP) [21] is an application-level protocol used to transfer files between hosts connected by the TCP/IP suite of protocols. FTP is based on a request/response paradigm and is mapped on the abstract DTP as defined in this section. The FTP model as defined in [21] is depicted below. ------------- |+---------+| || User || -------- ||Interface|<--->| User | |+----|----+| -------- ---------- | | | |+------+| control connection |+----|----+| ||Server|<------------------->|| Client || || PI || Commands/Replies || PI || |+--|---+| |+----|----+| | | | | | | -------- |+--|---+| Data |+----|----+| -------- | File |<--->|Server|<------------------->|| Client |<--->| File | |System| || DTP || Connection || DTP || |System| -------- |+------+| |+---------+| -------- ---------- ------------- FTP uses two different connection types between a client and a server to transfer files. The control connection is persistent during a FTP session and used to exchange FTP commands and associated replies. The data connection is only available when bulk data has to be transferred. The FTP protocol usually runs over TCP and uses the well-known TCP port 21 to setup the control connection. Therefore, the default value Hazewinkel, et al. Standards Track [Page 37] RFC 2594 WWW Service MIB May 1999 for the wwwServiceProtocol object is { applTCPProtoID 21 }. Every FTP command is considered a request in the abstract DTP. Every FTP reply is considered a response in the abstract DTP. It should be noted that a single FTP command can result in multiple FTP replies (e.g. preliminary positive replies). The primary response for a FTP request contains a status code of the form 2xy, 3xy, 4xy or 5xy. See section 4.2 in [21] for the exact meaning of these status codes. The mappings for WwwRequestType and WwwResponseType are defined as follows: o The WwwRequestType corresponds to the FTP command token. o The WwwResponseType corresponds to the three-digit code which starts a reply. Multi-line replies with the same three-digit code are counted as a single DTP response. 8. Security Considerations There are a number of management objects defined in this MIB module that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for write operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information: o The document statistics group contains traffic information including the names of documents that were a target of protocol operations. This information is sensitive as it allows to obtain access statistics for documents. o The protocol statistics are less sensitive, because they do not contain details about the target of individual requests and responses. However, traffic statistics and error counters still provide usage information about WWW services and about the overall quality of WWW services. It is suggested that sites configure MIB views so that a user of this MIB can only access the portion of the statistics that belong to the WWW services managed by that user. o The service and the summary statistics groups provide information about the existence of WWW services and condensed usage statistics. Some sites may want to protect this information as well, especially if they offer private WWW services that should not be known by the outside world. Hazewinkel, et al. Standards Track [Page 38] RFC 2594 WWW Service MIB May 1999 SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access (read/change/create/delete) the objects in this MIB. It is recommended that implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed read or write (change/create/delete) them. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Acknowledgments This document was produced by the Application MIB working group. The editors gratefully acknowledge the comments of the following individuals: Mark Gamble, Cheryl Krupczak, Randy Presuhn, Jon Saperia, Bob Stewart, Martin Toet, Chris Wellens, Kenneth White. Hazewinkel, et al. Standards Track [Page 39] RFC 2594 WWW Service MIB May 1999 11. Editors' Addresses Harrie Hazewinkel Joint Research Centre of the E.C. via Fermi - Ispra 21020 (VA) Italy Phone: +39 0332786322 Fax: +39 0332785641 EMail: harrie.hazewinkel@jrc.it Carl W. Kalbfleisch Verio, Inc. 1950 Stemmons Frwy Suite 2006 Dallas, TX 75207 USA Phone: +1 214 290-8653 Fax: +1 214 744-0742 EMail: cwk@verio.net Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3683 Fax: +49 531 489-5936 EMail: schoenw@ibr.cs.tu-bs.de 12. References [1] Wijnen,, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD, 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Hazewinkel, et al. Standards Track [Page 40] RFC 2594 WWW Service MIB May 1999 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. Hazewinkel, et al. Standards Track [Page 41] RFC 2594 WWW Service MIB May 1999 [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [18] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [19] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [20] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [21] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [22] Kalbfleisch, C., "Applicability of Standards Track MIBs to Management of World Wide Web Servers", RFC 2039, November 1996. [23] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [24] Kalbfleisch, C., Krupczak, C., Presuhn, R. and J. Saperia, "Application Management MIB", RFC 2564, May 1999. [25] Kantor, B. and P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, February 1986. [26] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996 [27] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996. Hazewinkel, et al. Standards Track [Page 42] RFC 2594 WWW Service MIB May 1999 13. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hazewinkel, et al. Standards Track [Page 43] snmp-mibs-downloader-1.1/mibrfcs/rfc2605.txt0000644000000000000000000014001611402176071015560 0ustar Network Working Group G. Mansfield Request for Comments: 2605 Cyber Solutions Inc. Obsoletes: 1567 S. Kille Category: Standards Track MessagingDirect Ltd. June 1999 Directory Server Monitoring MIB 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1567, "X.500 Directory Monitoring MIB". This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoring Directory Servers. Table of Contents 1. The SNMP Network Management Framework ....................... 2 2. The Directory Services Model ................................ 3 3. MIB Model for Directory Management .......................... 4 4. MIB design .................................................. 5 5. The Directory Server Monitoring MIB ......................... 5 6. Intellectual Property .......................................22 7. Changes from RFC1567 ........................................22 8. Acknowledgements ............................................22 9. References ..................................................23 Security Considerations .........................................24 Authors' Addresses ..............................................25 Full Copyright Statement ........................................26 Mansfield & Kille Standards Track [Page 1] RFC 2605 Directory Server Monitoring MIB June 1999 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Mansfield & Kille Standards Track [Page 2] RFC 2605 Directory Server Monitoring MIB June 1999 2. The Directory Services Model. The Directory comprises of a set of servers (Directory Servers). Clients or Directory User Agents (DUA) are provided access to the Directory which maybe local or distributed, by the Directory Servers. The server maybe a X.500 Directory System Agent (DSA) [16] running over the OSI suite of protocols or, a (C)LDAP[17,18] frontend to the X.500 Directory System Agent or, a native LDAP Directory Server running directly over TCP or other protocols, or a database acting as a backend to another server, or any other application protocol, or any combination of the above. A Directory Server has one or more application protocol interfaces. Through these interfaces the Directory Server interacts with the DUA and with the peer Directory Servers. Fig. 1 shows the case of a Directory Server that receives requests and sends back responses in some protocol. Fig. 2 shows one possible scenario where the Directory Server speaks multiple protocols. +----------------+ | | | Directory | Directory Protocol | Server X--------> | | | | +----------------+ FIG. 1. +----------------+ | | DSP <----------X X--------> DAP | Directory | Other | Server | Protocol <----------X X--------> LDAP | | +----------------+ FIG. 2. The Directory contains information in the form of entries. An entry is a collection of attributes and is uniquely identified by a name, the Distinguished Name (DN). The entries are arranged in a hierarchical tree-like structure called the Directory Information Tree (DIT). Mansfield & Kille Standards Track [Page 3] RFC 2605 Directory Server Monitoring MIB June 1999 A DUA requests a Directory Server to perform some operation on the Directory. The Directory Server is responsible for performing the operation and after completing its effort to carry out the request, returns a response to the DUA. A Directory Server may use information stored in its local database or interact with (chain the request to) other Directory Servers to service the DUA request. Alternatively, a Directory Server may return a reference to another Directory Server (referral). The local database of a Directory Server consists of the part of the Directory that is mastered by the Directory Server, the part of the Directory for which it keeps slave copies and cached information that is gathered during the operation of the Directory Server. In the connection oriented mode a DUA "binds" to a Directory Server with a particular identification. The Directory Server may authenticate the identity of the DUA. In the connectionless mode as is employed in CLDAP no binding and/or authentication is carried out between the DUA and the Directory Server. The following type of operations are carried out by the Directory Server : Read, Compare, Addition of an Entry (AddEntry), Modification of an Entry (ModifyEntry), Modification of a DN (ModifyRDN), Deletion of an Entry (RemoveEntry), List, Search, Abandon. Some Directory Servers do not support some type of operations. For example CLDAP does not support AddEntry, ModifyEntry, ModifyRDN, RemoveEntry etc. In response to requests results and/or errors are returned by the Directory Server. In the distributed Directory data is often replicated to enhance performance and for other advantages. The data to be replicated is transferred from the "Supplier" Directory Server to the "Consumer" Directory Server according to the replication agreement between the supplier and the receiver. 3. MIB Model for Directory Management. A Directory manager should be able to monitor all the Directory Servers in his/her domain of management. The Directory Servers may be running on one or more hosts and, multiple Directory Servers may be running on the same host. The manager may wish to monitor several aspects of the operational Directory Servers. He/she may want to know the process related aspects - the resource utilization of an operational Directory Server; the network service related aspects e.g. inbound- associations, outbound-associations, operational status, and finally the information specific to the Directory Server application - its operations and performance. Mansfield & Kille Standards Track [Page 4] RFC 2605 Directory Server Monitoring MIB June 1999 The MIB defined in this document covers the portion which is specific to Directory services. The network service related part of the MIB, and the host-resources related part of the MIB, as well as other parts of interest to a Manager monitoring the Directory services, are covered in separate documents [19] [20]. The MIB will cover a group of Directory Servers. The grouping will be done on some logical basis by the administrator/manager. In all cases, the grouping will be reflected in the pertinent NETWORK- SERVICES-MIB which will have an entry corresponding to each Directory Server in the group. 4. MIB design. The basic principle has been to keep the MIB as simple as possible. The Managed objects included in the MIB are divided into three tables - dsTable, dsApplIfOpsTable, and dsIntTable. - The dsTable contains a list of Directory Servers. The list contains a description of the Directory Servers as well as summary statistics on the entries held by and the cache performance of each Directory Server. The group of servers on this list is likely to contain a part of, if not all, the Directory Servers in the management domain. - The dsApplIfOpsTable provides summary statistics on the accesses, operations and errors for each application protocol interface of a Directory Server. - The dsIntTable provides some useful information on the interaction of the monitored Directory Servers with peer Directory Servers. There are references to the Directory itself for static information pertaining to the Directory Server. These references are in the form of "Directory Distinguished Name" [21] of the corresponding object. It is intended that Directory management applications will use these references to obtain further information on the objects of interest. 5. The Directory Server Monitoring MIB. DIRECTORY-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Counter32, Gauge32, OBJECT-TYPE FROM SNMPv2-SMI mib-2 FROM RFC1213-MIB DisplayString, TimeStamp Mansfield & Kille Standards Track [Page 5] RFC 2605 Directory Server Monitoring MIB June 1999 FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ZeroBasedCounter32 FROM RMON2-MIB applIndex, DistinguishedName, URLString FROM NETWORK-SERVICES-MIB; dsMIB MODULE-IDENTITY LAST-UPDATED "9906070000Z" ORGANIZATION "IETF Mail and Directory Management Working Group" CONTACT-INFO " Glenn Mansfield Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Working Group E-mail: ietf-madman@innosoft.com To subscribe: ietf-madman-request@innosoft.com" DESCRIPTION " The MIB module for monitoring Directory Services." -- revision information REVISION "9906070000Z" DESCRIPTION "This revision of this MIB is published in RFC 2605. This revision obsoletes RFC 1567. It is incompatible with the original MIB and so it has been renamed from dsaMIB to dsMIB." REVISION "9311250000Z" -- 25th November 1993 DESCRIPTION "The original version of this MIB was published in RFC 1567." ::= { mib-2 66 } dsTable OBJECT-TYPE SYNTAX SEQUENCE OF DsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Mansfield & Kille Standards Track [Page 6] RFC 2605 Directory Server Monitoring MIB June 1999 " The table holding information related to the Directory Servers." ::= {dsMIB 1} dsTableEntry OBJECT-TYPE SYNTAX DsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entry containing summary description for a Directory Server." INDEX { applIndex } ::= {dsTable 1} -- General description of the Directory Server application will be -- available in the applTable of the NETWORK-SERVICES-MIB indexed by -- applIndex. DsTableEntry ::= SEQUENCE { dsServerType BITS, dsServerDescription DisplayString, -- Entry statistics/Cache performance dsMasterEntries Gauge32, dsCopyEntries Gauge32, dsCacheEntries Gauge32, dsCacheHits Counter32, dsSlaveHits Counter32 } dsServerType OBJECT-TYPE SYNTAX BITS { frontEndDirectoryServer(0), backEndDirectoryServer(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the server is a frontend or, a backend or, both. If the server is a frontend, then the frontEndDirectoryServer Mansfield & Kille Standards Track [Page 7] RFC 2605 Directory Server Monitoring MIB June 1999 bit will be set. Similarly for the backend." ::= {dsTableEntry 1} dsServerDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A text description of the application. This information is intended to identify and briefly describe the application in a status display." ::= {dsTableEntry 2} -- A (C)LDAP frontend to the X.500 Directory will not have -- MasterEntries, CopyEntries; the following counters will -- be inaccessible for LDAP/CLDAP frontends to the X.500 -- directory: dsMasterEntries, dsCopyEntries, dsSlaveHits. dsMasterEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of entries mastered in the Directory Server." ::= {dsTableEntry 3} dsCopyEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of entries for which systematic (slave) copies are maintained in the Directory Server." ::= {dsTableEntry 4} dsCacheEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of entries cached (non-systematic copies) in the Directory Server. This will include the entries that are cached partially. The negative cache is not counted." ::= {dsTableEntry 5} dsCacheHits OBJECT-TYPE SYNTAX Counter32 Mansfield & Kille Standards Track [Page 8] RFC 2605 Directory Server Monitoring MIB June 1999 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that were serviced from the locally held cache." ::= {dsTableEntry 6} dsSlaveHits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations that were serviced from the locally held object replications ( copy- entries)." ::= {dsTableEntry 7} dsApplIfOpsTable OBJECT-TYPE SYNTAX SEQUENCE OF DsApplIfOpsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The table holding information related to the Directory Server operations." ::= {dsMIB 2} dsApplIfOpsEntry OBJECT-TYPE SYNTAX DsApplIfOpsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entry containing operations related statistics for a Directory Server." INDEX { applIndex, dsApplIfProtocolIndex } ::= {dsApplIfOpsTable 1} DsApplIfOpsEntry ::= SEQUENCE { dsApplIfProtocolIndex INTEGER, dsApplIfProtocol OBJECT IDENTIFIER, -- Bindings dsApplIfUnauthBinds Counter32, dsApplIfSimpleAuthBinds Counter32, Mansfield & Kille Standards Track [Page 9] RFC 2605 Directory Server Monitoring MIB June 1999 dsApplIfStrongAuthBinds Counter32, dsApplIfBindSecurityErrors Counter32, -- In-coming operations dsApplIfInOps Counter32, dsApplIfReadOps Counter32, dsApplIfCompareOps Counter32, dsApplIfAddEntryOps Counter32, dsApplIfRemoveEntryOps Counter32, dsApplIfModifyEntryOps Counter32, dsApplIfModifyRDNOps Counter32, dsApplIfListOps Counter32, dsApplIfSearchOps Counter32, dsApplIfOneLevelSearchOps Counter32, dsApplIfWholeSubtreeSearchOps Counter32, -- Out going operations dsApplIfReferrals Counter32, dsApplIfChainings Counter32, -- Errors dsApplIfSecurityErrors Counter32, dsApplIfErrors Counter32, -- replications dsApplIfReplicationUpdatesIn Counter32, Mansfield & Kille Standards Track [Page 10] RFC 2605 Directory Server Monitoring MIB June 1999 dsApplIfReplicationUpdatesOut Counter32, -- Traffic Volume dsApplIfInBytes Counter32, dsApplIfOutBytes Counter32 } -- CLDAP does not use binds; for the CLDAP interface of a Directory -- Server the bind related counters will be inaccessible. -- -- CLDAP and LDAP implement "Read" and "List" operations -- indirectly via the "search" operation; the following -- counters will be inaccessible for the CLDAP and LDAP interfaces of -- Directory Servers: dsApplIfReadOps, dsApplIfListOps -- -- CLDAP does not implement "Compare", "Add", "Remove", -- "Modify", "ModifyRDN"; the following counters will be -- inaccessible for the CLDAP interfaces of Directory Servers: -- dsApplIfCompareOps, dsApplIfAddEntryOps, dsApplIfRemoveEntryOps, -- dsApplIfModifyEntryOps, dsApplIfModifyRDNOps. -- -- CLDAP Directory Servers do not return Referrals -- the following fields will remain inaccessible for -- CLDAP interfaces of Directory Servers: dsApplIfReferrals. dsApplIfProtocolIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index to uniquely identify an entry corresponding to a application-layer protocol interface. This index is used for lexicographic ordering of the table." ::= {dsApplIfOpsEntry 1} dsApplIfProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An identification of the protocol being used by the application on this interface. For an OSI Application, this will be the Application Context. For Internet applications, the IANA maintains a registry[22] of the OIDs which correspond to Mansfield & Kille Standards Track [Page 11] RFC 2605 Directory Server Monitoring MIB June 1999 well-known applications. If the application protocol is not listed in the registry, an OID value of the form {applTCPProtoID port} or {applUDProtoID port} are used for TCP-based and UDP-based protocols, respectively. In either case 'port' corresponds to the primary port number being used by the protocol. The OIDs applTCPProtoID and applUDPProtoID are defined in NETWORK-SERVICES-MIB" ::= {dsApplIfOpsEntry 2} dsApplIfUnauthBinds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of unauthenticated/anonymous bind requests received." ::= {dsApplIfOpsEntry 3} dsApplIfSimpleAuthBinds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of bind requests that were authenticated using simple authentication procedures like password checks. This includes the password authentication using SASL mechanisms like CRAM-MD5." ::= {dsApplIfOpsEntry 4} dsApplIfStrongAuthBinds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of bind requests that were authenticated using TLS and X.500 strong authentication procedures. This includes the binds that were authenticated using external authentication procedures." ::= {dsApplIfOpsEntry 5} dsApplIfBindSecurityErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of bind requests that have been rejected due to inappropriate authentication or Mansfield & Kille Standards Track [Page 12] RFC 2605 Directory Server Monitoring MIB June 1999 invalid credentials." ::= {dsApplIfOpsEntry 6} dsApplIfInOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of requests received from DUAs or other Directory Servers." ::= {dsApplIfOpsEntry 7} dsApplIfReadOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of read requests received." ::= {dsApplIfOpsEntry 8} dsApplIfCompareOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of compare requests received." ::= {dsApplIfOpsEntry 9} dsApplIfAddEntryOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of addEntry requests received." ::= {dsApplIfOpsEntry 10} dsApplIfRemoveEntryOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of removeEntry requests received." ::= {dsApplIfOpsEntry 11} dsApplIfModifyEntryOps OBJECT-TYPE Mansfield & Kille Standards Track [Page 13] RFC 2605 Directory Server Monitoring MIB June 1999 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of modifyEntry requests received." ::= {dsApplIfOpsEntry 12} dsApplIfModifyRDNOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of modifyRDN requests received." ::= {dsApplIfOpsEntry 13} dsApplIfListOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of list requests received." ::= {dsApplIfOpsEntry 14} dsApplIfSearchOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of search requests- baseObject searches, oneLevel searches and whole subtree searches, received." ::= {dsApplIfOpsEntry 15} dsApplIfOneLevelSearchOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of oneLevel search requests received." ::= {dsApplIfOpsEntry 16} dsApplIfWholeSubtreeSearchOps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Mansfield & Kille Standards Track [Page 14] RFC 2605 Directory Server Monitoring MIB June 1999 " Number of whole subtree search requests received." ::= {dsApplIfOpsEntry 17} dsApplIfReferrals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of referrals returned in response to requests for operations." ::= {dsApplIfOpsEntry 18} dsApplIfChainings OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of operations forwarded by this Directory Server to other Directory Servers." ::= {dsApplIfOpsEntry 19} dsApplIfSecurityErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of requests received which did not meet the security requirements. " ::= {dsApplIfOpsEntry 20} dsApplIfErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of requests that could not be serviced due to errors other than security errors, and referrals. A partially serviced operation will not be counted as an error. The errors include naming-related, update-related, attribute-related and service-related errors." ::= {dsApplIfOpsEntry 21} -- Replication operations dsApplIfReplicationUpdatesIn OBJECT-TYPE Mansfield & Kille Standards Track [Page 15] RFC 2605 Directory Server Monitoring MIB June 1999 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of replication updates fetched or received from supplier Directory Servers." ::= {dsApplIfOpsEntry 22} dsApplIfReplicationUpdatesOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Number of replication updates sent to or taken by consumer Directory Servers." ::= {dsApplIfOpsEntry 23} dsApplIfInBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Incoming traffic, in bytes, on the interface. This will include requests from DUAs as well as responses from other Directory Servers." ::= {dsApplIfOpsEntry 24} dsApplIfOutBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Outgoing traffic in bytes on the interface. This will include responses to DUAs and Directory Servers as well as requests to other Directory Servers." ::= {dsApplIfOpsEntry 25} -- The dsIntTable contains statistical data on the peer -- Directory Servers with which the monitored Directory -- Server interacts or, attempts to interact. This table is -- expected to provide a useful insight into the effect of -- neighbours on the Directory Server's performance. -- The table keeps track of the last "N" Directory Servers -- with which the monitored Directory has interacted -- (attempted to interact), where "N" is a locally-defined -- constant. -- For a multiprotocol server, statistics for each protocol Mansfield & Kille Standards Track [Page 16] RFC 2605 Directory Server Monitoring MIB June 1999 -- are kept separetely. dsIntTable OBJECT-TYPE SYNTAX SEQUENCE OF DsIntEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Each row of this table contains some details related to the history of the interaction of the monitored Directory Server with its peer Directory Servers." ::= { dsMIB 3 } dsIntEntry OBJECT-TYPE SYNTAX DsIntEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entry containing interaction details of a Directory Server with a peer Directory Server." INDEX { applIndex,dsIntEntIndex, dsApplIfProtocolIndex } ::= { dsIntTable 1 } DsIntEntry ::= SEQUENCE { dsIntEntIndex INTEGER, dsIntEntDirectoryName DistinguishedName, dsIntEntTimeOfCreation TimeStamp, dsIntEntTimeOfLastAttempt TimeStamp, dsIntEntTimeOfLastSuccess TimeStamp, dsIntEntFailuresSinceLastSuccess Gauge32, dsIntEntFailures ZeroBasedCounter32, dsIntEntSuccesses ZeroBasedCounter32, dsIntEntURL URLString } dsIntEntIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current Mansfield & Kille Standards Track [Page 17] RFC 2605 Directory Server Monitoring MIB June 1999 DESCRIPTION " Together with applIndex and dsApplIfProtocolIndex, this object forms the unique key to identify the conceptual row which contains useful info on the (attempted) interaction between the Directory Server (referred to by applIndex) and a peer Directory Server using a particular protocol." ::= {dsIntEntry 1} dsIntEntDirectoryName OBJECT-TYPE SYNTAX DistinguishedName MAX-ACCESS read-only STATUS current DESCRIPTION " Distinguished Name of the peer Directory Server to which this entry pertains." ::= {dsIntEntry 2} dsIntEntTimeOfCreation OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION " The value of sysUpTime when this row was created. If the entry was created before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsIntEntry 3} dsIntEntTimeOfLastAttempt OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION " The value of sysUpTime when the last attempt was made to contact the peer Directory Server. If the last attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsIntEntry 4} dsIntEntTimeOfLastSuccess OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION " The value of sysUpTime when the last attempt made to contact the peer Directory Server was successful. If there have been no successful attempts this entry will have a value Mansfield & Kille Standards Track [Page 18] RFC 2605 Directory Server Monitoring MIB June 1999 of zero. If the last successful attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsIntEntry 5} dsIntEntFailuresSinceLastSuccess OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION " The number of failures since the last time an attempt to contact the peer Directory Server was successful. If there have been no successful attempts, this counter will contain the number of failures since this entry was created." ::= {dsIntEntry 6} -- note this gauge has a maximum value of 4294967295 and, -- it does not wrap.[5] dsIntEntFailures OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Cumulative failures in contacting the peer Directory Server since the creation of this entry." ::= {dsIntEntry 7} dsIntEntSuccesses OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION " Cumulative successes in contacting the peer Directory Server since the creation of this entry." ::= {dsIntEntry 8} dsIntEntURL OBJECT-TYPE SYNTAX URLString MAX-ACCESS read-only STATUS current DESCRIPTION " URL of the peer Directory Server." ::= {dsIntEntry 9} -- Conformance information Mansfield & Kille Standards Track [Page 19] RFC 2605 Directory Server Monitoring MIB June 1999 dsConformance OBJECT IDENTIFIER ::= { dsMIB 4 } dsGroups OBJECT IDENTIFIER ::= { dsConformance 1 } dsCompliances OBJECT IDENTIFIER ::= { dsConformance 2 } -- Compliance statements dsEntryCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the DIRECTORY-SERVER-MIB for a summary overview of the Directory Servers ." MODULE -- this module MANDATORY-GROUPS { dsEntryGroup } ::= { dsCompliances 1 } dsOpsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the DIRECTORY-SERVER-MIB for monitoring Directory Server operations, entry statistics and cache performance." MODULE -- this module MANDATORY-GROUPS { dsEntryGroup, dsOpsGroup } ::= { dsCompliances 2 } dsIntCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION " The compliance statement for SNMP entities which implement the DIRECTORY-SERVER-MIB for monitoring Directory Server operations and the interaction of the Directory Server with peer Directory Servers." MODULE -- this module MANDATORY-GROUPS { dsEntryGroup, dsIntGroup } ::= { dsCompliances 3 } dsOpsIntCompliance MODULE-COMPLIANCE STATUS current Mansfield & Kille Standards Track [Page 20] RFC 2605 Directory Server Monitoring MIB June 1999 DESCRIPTION " The compliance statement for SNMP entities which implement the DIRECTORY-SERVER-MIB for monitoring Directory Server operations and the interaction of the Directory Server with peer Directory Servers." MODULE -- this module MANDATORY-GROUPS { dsEntryGroup, dsOpsGroup, dsIntGroup } ::= { dsCompliances 4 } -- Units of conformance dsEntryGroup OBJECT-GROUP OBJECTS {dsServerType, dsServerDescription, dsMasterEntries, dsCopyEntries, dsCacheEntries, dsCacheHits, dsSlaveHits} STATUS current DESCRIPTION " A collection of objects for a summary overview of the Directory Servers." ::= { dsGroups 1 } dsOpsGroup OBJECT-GROUP OBJECTS { dsApplIfProtocolIndex, dsApplIfProtocol, dsApplIfUnauthBinds, dsApplIfSimpleAuthBinds, dsApplIfStrongAuthBinds, dsApplIfBindSecurityErrors, dsApplIfInOps, dsApplIfReadOps, dsApplIfCompareOps, dsApplIfAddEntryOps, dsApplIfRemoveEntryOps, dsApplIfModifyEntryOps, dsApplIfModifyRDNOps, dsApplIfListOps, dsApplIfSearchOps, dsApplIfOneLevelSearchOps, dsApplIfWholeSubtreeSearchOps, dsApplIfReferrals, dsApplIfChainings, dsApplIfSecurityErrors, dsApplIfErrors, dsApplIfReplicationUpdatesIn, dsApplIfReplicationUpdatesOut, dsApplIfInBytes, dsApplIfOutBytes } STATUS current DESCRIPTION " A collection of objects for monitoring the Directory Server operations." ::= { dsGroups 2 } dsIntGroup OBJECT-GROUP OBJECTS { Mansfield & Kille Standards Track [Page 21] RFC 2605 Directory Server Monitoring MIB June 1999 dsIntEntDirectoryName, dsIntEntTimeOfCreation, dsIntEntTimeOfLastAttempt, dsIntEntTimeOfLastSuccess, dsIntEntFailuresSinceLastSuccess, dsIntEntFailures, dsIntEntSuccesses, dsIntEntURL} STATUS current DESCRIPTION " A collection of objects for monitoring the Directory Server's interaction with peer Directory Servers." ::= { dsGroups 3 } END 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Changes from RFC1567. A more general Directory model in which, several Directory protocols coexist, has been adopted for the purpose of the MIB design. The result is a generic Directory Server Monitoring MIB. 8. Acknowledgements This memo is the product of discussions and deliberations carried out in the Mail and Directory Management Working Group (ietf-madman-wg). Mansfield & Kille Standards Track [Page 22] RFC 2605 Directory Server Monitoring MIB June 1999 References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. Mansfield & Kille Standards Track [Page 23] RFC 2605 Directory Server Monitoring MIB June 1999 [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] ITU-T Rec. X.501, "The Directory: Models", 1993. [17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [18] Young, A., "Connection-less Lightweight X.500 Directory Access Protocol", RFC 1798, June 1995. [19] Freed N. and Kille, S., "Network Services Monitoring MIB", RFC 2248, January 1998. [20] Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514, September 1993. [21] Wahl, W., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [22] http://www.isi.edu/in-notes/iana/assignments/protocol-numbers Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. However, the information itself may partly reveal the configuration of the directory system and passively increase its vulnerability. The information could also be used to analyze network usage and traffic patterns. Therefore, it may be important in some environments to control read access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. Mansfield & Kille Standards Track [Page 24] RFC 2605 Directory Server Monitoring MIB June 1999 SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. Authors' Addresses Glenn Mansfield Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Steve E. Kille MessagingDirect Ltd. The Dome, The Square Richmond TW9 1DT UK Phone: +44-181-332-9091 EMail: Steve.Kille@MessagingDirect.com Mansfield & Kille Standards Track [Page 25] RFC 2605 Directory Server Monitoring MIB June 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mansfield & Kille Standards Track [Page 26] snmp-mibs-downloader-1.1/mibrfcs/rfc2613.txt0000644000000000000000000025517511402176071015574 0ustar Network Working Group R. Waterman Request for Comments: 2613 Allot Networks Inc. Category: Standards Track B. Lahaye Xylan Corp. D. Romascanu Lucent Technologies S. Waldbusser INS June 1999 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. Table of Contents 1 The Network Management Framework 2 2 Overview 3 2.1 Remote Network Management Goals 3 2.2 Switched Networks Monitoring 5 2.3 Mechanisms for Monitoring Switched Networks 5 2.3.1 DataSource Objects 6 2.3.2 Copy Port 7 2.3.3 VLAN Monitoring 7 2.4 Relationship to Other MIBs 8 2.4.1 The RMON and RMON 2 MIBs 8 2.4.2 The Interfaces Group MIB 8 2.4.3 The Entity MIB 8 2.4.4 The Bridge MIB 9 Waterman, et al. Standards Track [Page 1] RFC 2613 SMON MIB June 1999 2.5 Relationship with IEEE 802.1 Standards 9 3 SMON/RMON Groups 9 3.1 SMON ProbeCapabilities 9 3.2 smonVlanStats 10 3.3 smonPrioStats 10 3.4 dataSourceCaps 10 3.5 portCopyConfig 11 4 Control of Remote Network Monitoring Devices 12 5 Definitions 13 6 References 39 7 Intellectual Property 41 8 Security Considerations 41 9 Authors' Addresses 44 A Full Copyright Statement 44 1. The Network Management Framework The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2571 [1]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. - A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Waterman, et al. Standards Track [Page 2] RFC 2613 SMON MIB June 1999 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [24]. 2. Overview This document continues the architecture created in the RMON MIB [17] by providing RMON analysis for switched networks (SMON). Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network. Often these remote probes are stand-alone devices and devote significant internal resources for the sole purpose of managing a network. An organization may employ many of these devices, one per network segment, to manage its internet. In addition, these devices may be used for a network management service provider to access a client network, often geographically remote. The objects defined in this document are intended as an interface between an RMON agent and an RMON management application and are not intended for direct manipulation by humans. While some users may tolerate the direct display of some of these objects, few will tolerate the complexity of manually manipulating objects to accomplish row creation. These functions should be handled by the management application. 2.1 Remote Network Management Goals o Offline Operation There are sometimes conditions when a management station will not be in constant contact with its remote monitoring devices. This is sometimes by design in an attempt to lower communications costs Waterman, et al. Standards Track [Page 3] RFC 2613 SMON MIB June 1999 (especially when communicating over a WAN or dialup link), or by accident as network failures affect the communications between the management station and the probe. For this reason, this MIB allows a probe to be configured to perform diagnostics and to collect statistics continuously, even when communication with the management station may not be possible or efficient. The probe may then attempt to notify the management station when an exceptional condition occurs. Thus, even in circumstances where communication between management station and probe is not continuous, fault, performance, and configuration information may be continuously accumulated and communicated to the management station conveniently and efficiently. o Proactive Monitoring Given the resources available on the monitor, it is potentially helpful for it continuously to run diagnostics and to log network performance. The monitor is always available at the onset of any failure. It can notify the management station of the failure and can store historical statistical information about the failure. This historical information can be played back by the management station in an attempt to perform further diagnosis into the cause of the problem. o Problem Detection and Reporting The monitor can be configured to recognize conditions, most notably error conditions, and continuously to check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways. o Value Added Data Because a remote monitoring device represents a network resource dedicated exclusively to network management functions, and because it is located directly on the monitored portion of the network, the remote network monitoring device has the opportunity to add significant value to the data it collects. For instance, by highlighting those hosts on the network that generate the most traffic or errors, the probe can give the management station precisely the information it needs to solve a class of problems. o Multiple Managers An organization may have multiple management stations for different units of the organization, for different functions (e.g. engineering and operations), and in an attempt to provide disaster Waterman, et al. Standards Track [Page 4] RFC 2613 SMON MIB June 1999 recovery. Because environments with multiple management stations are common, the remote network monitoring device has to deal with more than one management station, potentially using its resources concurrently. 2.2 Switched Networks Monitoring This document addresses issues related to applying "Remote Technology" to Switch Networks. Switches today differ from standard shared media protocols: 1) Data is not, in general, broadcast. This MAY be caused by the switch architecture or by the connection-oriented nature of the data. This means, therefore, that monitoring non-broadcast traffic needs to be considered. 2) Monitoring the multiple entry and exit points from a switching device requires a vast amount of resources - memory and CPU, and aggregation of the data in logical packets of information, determined by the application needs. 3) Switching incorporates logical segmentation such as Virtual LANs (VLANs). 4) Switching incorporates packet prioritization. 5) Data across the switch fabric can be in the form of cells. Like RMON, SMON is only concerned with the monitoring of packets. Differences such as these make monitoring difficult. The current RMON and RMON 2 standards do not provide for things that are unique to switches or switched environments. In order to overcome the limitations of the existing standards, new monitoring mechanisms have been implemented by vendors of switching equipment. All these monitoring strategies are currently proprietary in nature. This document provides the framework to include different switching strategies and allow for monitoring operations consistent with the RMON framework. This MIB is limited to monitoring and control operations aimed at providing monitoring data for RMON probes. 2.3 Mechanisms for Monitoring Switched Networks The following mechanisms are used by SMON devices, for the purpose of monitoring switched networks. Waterman, et al. Standards Track [Page 5] RFC 2613 SMON MIB June 1999 2.3.1 DataSource Objects The RMON MIB standard [17] defines data source objects which point to MIB-II interfaces, identified by instances of ifIndex objects. The SMON MIB extends this concept and allows for other types of objects to be defined as data sources for RMON and/or SMON data. Three forms of dataSources are described: ifIndex. Traditional RMON dataSources. Called 'port-based' for ifType. not equal to 'propVirtual(53)'. is the ifIndex value (see [22]). smonVlanDataSource. A dataSource of this form refers to a 'Packet-based VLAN' and is called a 'VLAN-based' dataSource. is the VLAN ID as defined by the IEEE 802.1Q standard [19]. The value is between 1 and 4094 inclusive, and it represents an 802.1Q VLAN-ID with global scope within a given bridged domain, as defined by [19]. entPhysicalEntry. A dataSource of this form refers to a physical entity within the agent and is called an 'entity-based' dataSource. is the value of the entPhysicalIndex in the entPhysicalTable (see [18]). In addition to these new dataSource types, SMON introduces a new group called dataSourceCapsTable to aid an NMS in discovering dataSource identity and attributes. The extended data source mechanism supported by the SMON MIB allows for the use of external collection points, similar to the one defined and supported by the RMON and RMON 2 MIBs, as well as internal collection points (e.g. propVirtual ifTable entry, entPhysicalEntry). The latter reflects either data sources which MAY be the result of aggregation (e.g. switch-wide) or internal channels of physical entities, which have the capability of being monitored by an SMON probe. Waterman, et al. Standards Track [Page 6] RFC 2613 SMON MIB June 1999 2.3.2 Copy Port In order to make the switching devices support RMON statistics, many vendors have implemented a port copy feature, allowing traffic to be replicated from switch port to switch port. Several levels of configuration are possible: 1) 1 source port to 1 destination port 2) N source ports to 1 destination port 3) N source ports to M destination ports The SMON standard presents a standard MIB interface which allows for the control of this function. Note that this function can apply to devices that have no other SMON or RMON functionality than copy port. The agent of such a device would support only the portCopyCaps and the portCopyConfig MIB groups, out of the whole SMON MIB. Switch vendors are encouraged to implement this subset of the SMON MIB, as it would allow for standard port copy configuration from the same NMS application that does RMON or SMON. Port copy may cause congestion problems on the SMON device. This situation is more likely occur when copying from a port of higher speed to a port of lower speed or copy from multiple port to a single port. Particular implementations MAY chose to build protection mechanisms that would prevent creation of new port copy links when the capacity of the destination port is exceeded. The MIB allows for implementations to (if supported) instrument a destination drop count on port copy to provide NMS applications a sense of the quality of data presented at the destination port. 2.3.3 VLAN Monitoring VLAN monitoring can be accomplished by using a VLAN-based dataSource and/or by configuring smonVlanIdStats and/or smonPrioStats collections. These functions allow VLAN-ID or user priority distributions per dataSource. VLAN monitoring provides a high-level view of total VLAN usages and relative non-unicast traffic usage as well as a profile of VLAN priority as defined in the 3-bit user_priority field. NOTE: priority statistics reflect what was parsed from the packet, not what priority, if any, was necessarily granted by the switch. Waterman, et al. Standards Track [Page 7] RFC 2613 SMON MIB June 1999 2.4 Relationship to Other MIBs 2.4.1 The RMON and RMON 2 MIBs The Remote Monitoring MIB (RMON) [17] provides several management functions that MAY be directly or indirectly applicable to switched networks. The port copy mechanisms defined by the SMON MIB allow for the destination ports to become a data source for any RMON statistics. However, an NMS application SHOULD check whether it is in the device capability (portCopyCap) to filter errors from a source to a destination port and whether this capability is enabled, in order to provide a correct interpretation of the copied port traffic. RMON host and matrix group statistics entries MAY be aggregated by use of the extended dataSource capability defined in SMON. RMON 2 groups are similarly extended through the use of SMON's dataSource definition. RMON also defines a simple thresholding monitoring mechanism, event- logging and event-notification for any MIB instance; SMON utilizes the alarms and events groups from RMON without modification. These groups SHOULD be implemented on SMON devices if a simple thresholding mechanism is desired. The RMON 2 usrHistory group (user-defined history collection) SHOULD be implemented by an SMON device if a history collection mechanism is desired for smonStats entries. 2.4.2 The Interfaces Group MIB The SMON MIB utilizes the propVirtual(53) ifType defined in the Interfaces Group MIB [22] to provide SMON and RMON with new dataSources such as VLANs and internal monitoring points. NMS applications SHOULD consult the SMON dataSource capabilities group (dataSourceCap) for a description of these virtual interfaces. 2.4.3 The Entity MIB The SMON MIB does not mandate Entity MIB [18] support, but allows for physical entities, as defined by this MIB to be defined as SMON data sources. For such cases, the support for the entPhysicalTable is required. Waterman, et al. Standards Track [Page 8] RFC 2613 SMON MIB June 1999 2.4.4 The Bridge MIB One of the important indicators for measuring the effectiveness of a switching device is the ratio between the number of forwarded frames and the number of dropped frames at the switch port. It is out of the scope of this MIB to provide instrumentation information relative to switching devices. However, such indication may be part of other MIB modules. For instance the Bridge MIB [23] provides such MIB objects, for the 802.1 bridges (dot1dTpPortInFrames, dot1dTpPortInDiscards) and switches managed according to the 802.1 bridge model MAY provide this information. 2.5 Relationship with IEEE 802.1 Standards The SMON MIB provides simple statistics per VLAN and priority levels. Those two categories of statistics are important to managers of switched networks. Interoperability for those features is ensured by the use of the IEEE 802.1 p/Q standards ([19], [20]) defined by the IEEE 802.1 WG. Interoperability from the SMON MIB point of view is ensured by referencing the IEEE definition of VLANs and priority levels for the SMON statistics. 3. SMON Groups 3.1 SMON ProbeCapabilities The SMON probeCapabilities BITS object covers the following four capabilities. - smonVlanStats(0) The probe supports the smonVlanStats object group. - smonPrioStats(1) The probe supports the smonPrioStats object group. - dataSource(2) The probe supports the dataSourceCaps object group. - portCopy(4) The probe supports the portCopyConfig object group. Waterman, et al. Standards Track [Page 9] RFC 2613 SMON MIB June 1999 3.2 smonVlanStats The smonVlanStats MIB group includes the control and statistics objects related to 802.1Q VLANs. Specific statistics per 802.1Q virtual LAN are supported. The group provides a high level view of total VLAN usage, and relative non-unicast traffic usage. It is an implementation-specific matter as to how the agent determines the proper default-VLAN for untagged or priority-tagged frames. 3.3 smonPrioStats The smonPrioStatsTable provides a distribution based on the user_priority field in the VLAN header. Note that this table merely reports priority as encoded in VLAN headers, not the priority (if any) given the frame for actual switching purposes. 3.4 dataSourceCaps The dataSourceCaps MIB group identifies all supported data sources on an SMON device. An NMS MAY use this table to discover the RMON and Copy Port attributes of each data source. Upon restart of the agent, the dataSourceTable, ifTable and entPhysicalTable are initialized for the available data sources. The agent MAY modify these tables as data sources become known or are removed (e.g. hot swap of interfaces, chassis cards or the discovery of VLAN usage). It is understood that dataSources representing VLANs may not always be instantiated immediately upon restart, but rather as VLAN usage is detected by the agent. The agent SHOULD attempt to create dataSource and interface entries for all dataSources as soon as possible. For each dataSourceCapsEntry representing a VLAN or entPhysicalEntry, the agent MUST create an associated ifEntry with a ifType value of associated dataSourceCapsIfIndex object. The rationale of the above derives from the fact that according to [16] and [17] an RMON dataSource MUST be associated with an ifEntry. Specifically, the dataSourceCapsTable allows for an agent to map Entity MIB physical entities (e.g., switch backplanes) and entire VLANs to ifEntries with ifType "propVirtual(53)". This ifEntry values will be used as the actual values in RMON control table dataSource objects. This allows for physical entities and VLANs to be treated as RMON data sources, and RMON functions to be applied to this type Waterman, et al. Standards Track [Page 10] RFC 2613 SMON MIB June 1999 of data sources. 3.5 portCopyConfig The portCopyConfig MIB group includes the objects defined for the control of the port copy functionality in a device. The standard does not place a limit on the mode in which this copy function may be used: Mode 1 -- 1:1 Copy Single dataSource copied to a single destination dataSource. Agent MAY limit configuration based on ifTypes, ifSpeeds, half- duplex/full-duplex, or agent resources. In this mode the single instance of the portCopyDestDropEvents object refers to dropped frames on the portCopyDest interface. Mode 2 -- N:1 Copy Multiple dataSources copied to a single destination dataSource. Agent MAY limit configuration based on ifTypes, ifSpeeds, half- duplex/full-duplex, portCopyDest over-subscription, or agent resources. In this mode all N instances of the portCopyDestDropEvents object SHOULD contain the same value, and refer to dropped frames on the portCopyDest interface. Mode 3 -- N:M Copy Multiple dataSources copied to multiple destination dataSources. Agent MAY limit configuration based on ifTypes, ifSpeeds, half- duplex/full-duplex, portCopyDest over-subscription, or agent resources. Since portCopyDestDropEvents is kept per destination port, all instances of the portCopyDestDropEvents object associated with (indexed by) a given portCopyDest SHOULD have the same value (i.e. replicated or aliased for each instance associated with a given portCopyDest). The rows do not have an OwnerString, since multiple rows MAY be part of the same portCopy operation. The agent is expected to activate or deactivate entries one at a time, based on the rowStatus for the given row. This can lead to unpredictable results in Modes 2 and 3 in applications utilizing the portCopy target traffic, if multiple PDUs are used to fully configure the operation. It is RECOMMENDED that an entire portCopy operation be configured in one SetRequest PDU if possible. Waterman, et al. Standards Track [Page 11] RFC 2613 SMON MIB June 1999 The portCopyDest object MAY NOT reference an interface associated with a packet-based VLAN (smonVlanDataSource.), but this dataSource type MAY be used as a portCopySource. 4. Control of Remote Network Monitoring Devices Due to the complex nature of the available functions in these devices, the functions often need user configuration. In many cases, the function requires parameters to be set up for a data collection operation. The operation can proceed only after these parameters are fully set up. Many functional groups in this MIB have one or more tables in which to set up control parameters, and one or more data tables in which to place the results of the operation. The control tables are typically read/write in nature, while the data tables are typically read-only. Because the parameters in the control table often describe resulting data in the data table, many of the parameters can be modified only when the control entry is not active. Thus, the method for modifying these parameters is to de-activate the entry, perform the SNMP Set operations to modify the entry, and then re-activate the entry. Deleting the control entry causes the deletion of any associated data entries, which also gives a convenient method for reclaiming the resources used by the associated data. Some objects in this MIB provide a mechanism to execute an action on the remote monitoring device. These objects MAY execute an action as a result of a change in the state of the object. For those objects in this MIB, a request to set an object to the same value as it currently holds would thus cause no action to occur. To facilitate control by multiple managers, resources have to be shared among the managers. These resources are typically the memory and computation resources that a function requires. The control mechanisms defined and used in this MIB are the same as those defined in the RMON MIB [17], for control functionality and interaction with multiple managers. Waterman, et al. Standards Track [Page 12] RFC 2613 SMON MIB June 1999 5. Definitions SMON-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Counter64 FROM SNMPv2-SMI RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC rmon, OwnerString FROM RMON-MIB LastCreateTime, DataSource, rmonConformance, probeConfig FROM RMON2-MIB InterfaceIndex FROM IF-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; switchRMON MODULE-IDENTITY LAST-UPDATED "9812160000Z" ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "IETF RMONMIB WG Mailing list: rmonmib@cisco.com Rich Waterman Allot Networks Inc. Tel: +1-408-559-0253 Email: rich@allot.com Bill Lahaye Xylan Corp. Tel: +1-800-995-2612 Email: lahaye@ctron.com Dan Romascanu Lucent Technologies Tel: +972-3-645-8414 Email: dromasca@lucent.com Steven Waldbusser International Network Services (INS) Tel: +1-650-318-1251 Email: waldbusser@ins.com" DESCRIPTION "The MIB module for managing remote monitoring device implementations for Switched Networks" Waterman, et al. Standards Track [Page 13] RFC 2613 SMON MIB June 1999 -- revision history REVISION "9812160000Z" -- 16 Dec 1998 midemight DESCRIPTION "Initial Version, published as RFC 2613." ::= { rmon 22 } smonMIBObjects OBJECT IDENTIFIER ::= { switchRMON 1 } dataSourceCaps OBJECT IDENTIFIER ::= {smonMIBObjects 1} smonStats OBJECT IDENTIFIER ::= {smonMIBObjects 2} portCopyConfig OBJECT IDENTIFIER ::= {smonMIBObjects 3} smonRegistrationPoints OBJECT IDENTIFIER ::= {smonMIBObjects 4} -- Textual Conventions -- SmonDataSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the source of the data that the associated function is configured to analyze. This Textual Convention extends the DataSource Textual Convention defined by RMON 2 to the following data source types: - ifIndex. DataSources of this traditional form are called 'port-based', but only if ifType. is not equal to 'propVirtual(53)'. - smonVlanDataSource. A dataSource of this form refers to a 'Packet-based VLAN' and is called a 'VLAN-based' dataSource. is the VLAN ID as defined by the IEEE 802.1Q standard [19]. The value is between 1 and 4094 inclusive, and it represents an 802.1Q VLAN-ID with global scope within a given bridged domain, as defined by [19]. - entPhysicalEntry. A dataSource of this form refers to a physical entity within the agent (e.g. entPhysicalClass = backplane(4)) and is called an 'entity-based' dataSource." SYNTAX OBJECT IDENTIFIER -- The smonCapabilities object describes SMON agent capabilities. smonCapabilities OBJECT-TYPE SYNTAX BITS { smonVlanStats(0), Waterman, et al. Standards Track [Page 14] RFC 2613 SMON MIB June 1999 smonPrioStats(1), dataSource(2), smonUnusedBit(3), portCopy(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the SMON MIB groups supported by this agent." ::= { probeConfig 15 } -- dataSourceCaps MIB group - defines SMON data source and port -- copy capabilities for devices supporting SMON. -- A NMS application will check this MIB group and retrieve -- information about the SMON capabilities of the device before -- applying SMON control operations to the device. -- dataSourceCapsTable: defines capabilities of RMON data sources dataSourceCapsTable OBJECT-TYPE SYNTAX SEQUENCE OF DataSourceCapsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes RMON data sources and port copy capabilities. An NMS MAY use this table to discover the identity and attributes of the data sources on a given agent implementation. Similar to the probeCapabilities object, actual row-creation operations will succeed or fail based on the resources available and parameter values used in each row-creation operation. Upon restart of the RMON agent, the dataSourceTable, ifTable, and perhaps entPhysicalTable are initialized for the available dataSources. For each dataSourceCapsEntry representing a VLAN or entPhysicalEntry the agent MUST create an associated ifEntry with a ifType value of 'propVirtual(53)'. This ifEntry will be used as the actual value in RMON control table dataSource objects. The assigned ifIndex value is copied into the associated dataSourceCapsIfIndex object. It is understood that dataSources representing VLANs may not always be instantiated immediately upon restart, but rather as Waterman, et al. Standards Track [Page 15] RFC 2613 SMON MIB June 1999 VLAN usage is detected by the agent. The agent SHOULD attempt to create dataSource and interface entries for all dataSources as soon as possible." ::= { dataSourceCaps 1 } dataSourceCapsEntry OBJECT-TYPE SYNTAX DataSourceCapsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries per data source containing descriptions of data source and port copy capabilities. This table is populated by the SMON agent with one entry for each supported data source." INDEX { IMPLIED dataSourceCapsObject } ::= { dataSourceCapsTable 1 } DataSourceCapsEntry ::= SEQUENCE { dataSourceCapsObject SmonDataSource, dataSourceRmonCaps BITS, dataSourceCopyCaps BITS, dataSourceCapsIfIndex InterfaceIndex } dataSourceCapsObject OBJECT-TYPE SYNTAX SmonDataSource MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an object that can be a SMON data source or a source or a destination for a port copy operation." ::= { dataSourceCapsEntry 1 } dataSourceRmonCaps OBJECT-TYPE SYNTAX BITS { countErrFrames(0), countAllGoodFrames(1), countAnyRmonTables(2), babyGiantsCountAsGood(3) } MAX-ACCESS read-only STATUS current DESCRIPTION Waterman, et al. Standards Track [Page 16] RFC 2613 SMON MIB June 1999 " General attributes of the specified dataSource. Note that these are static attributes, which SHOULD NOT be adjusted because of current resources or configuration. - countErrFrames(0) The agent sets this bit for the dataSource if errored frames received on this dataSource can actually be monitored by the agent The agent clears this bit if any errored frames are not visible to the RMON data collector. - countAllGoodFrames(1) The agent sets this bit for the dataSource if all good frames received on this dataSource can actually be monitored by the agent. The agent clears this bit if any good frames are not visible for RMON collection, e.g., the dataSource is a non-promiscuous interface or an internal switch interface which may not receive frames which were switched in hardware or dropped by the bridge forwarding function. - countAnyRmonTables(2) The agent sets this bit if this dataSource can actually be used in any of the implemented RMON tables, resources notwithstanding. The agent clears this bit if this dataSourceCapsEntry is present simply to identify a dataSource that may only be used as portCopySource and/or a portCopyDest, but not the source of an actual RMON data collection. - babyGiantsCountAsGood(3) The agent sets this bit if it can distinguish, for counting purposes, between true giant frames and frames that exceed Ethernet maximum frame size 1518 due to VLAN tagging ('baby giants'). Specifically, this BIT means that frames up to 1522 octets are counted as good. Agents not capable of detecting 'baby giants' will clear this bit and will view all frames less than or equal to 1518 octets as 'good frames' and all frames larger than 1518 octets as 'bad frames' for the purpose of counting in the smonVlanIdStats and smonPrioStats tables. Agents capable of detecting 'baby giants' SHALL consider them as 'good frames' for the purpose of counting in the smonVlanIdStats and smonPrioStats tables." ::= { dataSourceCapsEntry 2 } dataSourceCopyCaps OBJECT-TYPE Waterman, et al. Standards Track [Page 17] RFC 2613 SMON MIB June 1999 SYNTAX BITS { copySourcePort(0), copyDestPort(1), copySrcTxTraffic(2), copySrcRxTraffic(3), countDestDropEvents(4), copyErrFrames(5), copyUnalteredFrames(6), copyAllGoodFrames(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "PortCopy function capabilities of the specified dataSource. Note that these are static capabilities, which SHOULD NOT be adjusted because of current resources or configuration. - copySourcePort(0) The agent sets this bit if this dataSource is capable of acting as a source of a portCopy operation. The agent clears this bit otherwise. - copyDestPort(1) The agent sets this bit if this dataSource is capable of acting as a destination of a portCopy operation. The agent clears this bit otherwise. - copySrcTxTraffic(2) If the copySourcePort bit is set: The agent sets this bit if this dataSource is capable of copying frames transmitted out this portCopy source. The agent clears this bit otherwise. This function is needed to support full-duplex ports. Else: this bit SHOULD be cleared. - copySrcRxTraffic(3) If the copySourcePort bit is set: The agent sets this bit if this dataSource is capable of copying frames received on this portCopy source. The agent clears this bit otherwise. This function is needed to support full-duplex ports. Else: this bit SHOULD be cleared. - countDestDropEvents(4) If the copyDestPort bit is set: The agent sets this bit if it is capable of incrementing Waterman, et al. Standards Track [Page 18] RFC 2613 SMON MIB June 1999 portCopyDestDropEvents, when this dataSource is the target of a portCopy operation and a frame destined to this dataSource is dropped (for RMON counting purposes). Else: this BIT SHOULD be cleared. - copyErrFrames(5) If the copySourcePort bit is set: The agent sets this bit if it is capable of copying all errored frames from this portCopy source-port, for errored frames received on this dataSource. Else: this BIT SHOULD be cleared. - copyUnalteredFrames(6) If the copySourcePort bit is set: The agent sets the copyUnalteredFrames bit If it is capable of copying all frames from this portCopy source-port without alteration in any way; Else: this bit SHOULD be cleared. - copyAllGoodFrames(7) If the copySourcePort bit is set: The agent sets this bit for the dataSource if all good frames received on this dataSource are normally capable of being copied by the agent. The agent clears this bit if any good frames are not visible for the RMON portCopy operation, e.g., the dataSource is a non-promiscuous interface or an internal switch interface which may not receive frames which were switched in hardware or dropped by the bridge forwarding function. Else: this bit SHOULD be cleared." ::= { dataSourceCapsEntry 3 } dataSourceCapsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the ifIndex value of the ifEntry associated with this smonDataSource. The agent MUST create 'propVirtual' ifEntries for each dataSourceCapsEntry of type VLAN or entPhysicalEntry." ::= { dataSourceCapsEntry 4 } Waterman, et al. Standards Track [Page 19] RFC 2613 SMON MIB June 1999 -- The SMON Statistics MIB Group -- aggregated statistics for IEEE 802.1Q VLAN environments. -- VLAN statistics can be gathered by configuring smonVlanIdStats -- and/or smonPrioStats collections. These functions allow a -- VLAN-ID or user priority distributions per dataSource, -- auto-populated by the agent in a manner similar to the RMON -- hostTable. -- Only good frames are counted in the tables described in this -- section. -- VLAN ID Stats -- smonVlanStatsControlTable allows configuration of VLAN-ID -- collections. smonVlanStatsControlTable OBJECT-TYPE SYNTAX SEQUENCE OF SmonVlanStatsControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of VLAN statistics tables. The statistics collected represent a distribution based on the IEEE 802.1Q VLAN-ID (VID), for each good frame attributed to the data source for the collection." ::= { smonStats 1 } smonVlanStatsControlEntry OBJECT-TYPE SYNTAX SmonVlanStatsControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the smonVlanStatsControlTable." INDEX { smonVlanStatsControlIndex } ::= { smonVlanStatsControlTable 1 } SmonVlanStatsControlEntry ::= SEQUENCE { smonVlanStatsControlIndex Integer32, smonVlanStatsControlDataSource DataSource, smonVlanStatsControlCreateTime LastCreateTime, smonVlanStatsControlOwner OwnerString, smonVlanStatsControlStatus RowStatus } Waterman, et al. Standards Track [Page 20] RFC 2613 SMON MIB June 1999 smonVlanStatsControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique arbitrary index for this smonVlanStatsControlEntry." ::= { smonVlanStatsControlEntry 1 } smonVlanStatsControlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of data for this set of VLAN statistics. This object MAY NOT be modified if the associated smonVlanStatsControlStatus object is equal to active(1)." ::= { smonVlanStatsControlEntry 2 } smonVlanStatsControlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This object allows to a management station to detect deletion and recreation cycles between polls." ::= { smonVlanStatsControlEntry 3 } smonVlanStatsControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Administratively assigned named of the owner of this entry. It usually defines the entity that created this entry and is therefore using the resources assigned to it, though there is no enforcement mechanism, nor assurance that rows created are ever used." ::= { smonVlanStatsControlEntry 4 } smonVlanStatsControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Waterman, et al. Standards Track [Page 21] RFC 2613 SMON MIB June 1999 An entry MAY NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the smonVlanIdStatsTable SHALL be deleted." ::= { smonVlanStatsControlEntry 5 } -- The VLAN Statistics Table smonVlanIdStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SmonVlanIdStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the VLAN statistics data. The statistics collected represent a distribution based on the IEEE 802.1Q VLAN-ID (VID), for each good frame attributed to the data source for the collection. This function applies the same rules for attributing frames to VLAN-based collections. RMON VLAN statistics are collected after the Ingress Rules defined in section 3.13 of the VLAN Specification [20] are applied. It is possible that entries in this table will be garbage-collected, based on agent resources, and VLAN configuration. Agents are encouraged to support all 4094 index values and not garbage collect this table." ::= { smonStats 2 } smonVlanIdStatsEntry OBJECT-TYPE SYNTAX SmonVlanIdStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in smonVlanIdStatsTable." INDEX { smonVlanStatsControlIndex, smonVlanIdStatsId } ::= { smonVlanIdStatsTable 1 } SmonVlanIdStatsEntry ::= SEQUENCE { smonVlanIdStatsId Integer32, smonVlanIdStatsTotalPkts Counter32, smonVlanIdStatsTotalOverflowPkts Counter32, smonVlanIdStatsTotalHCPkts Counter64, smonVlanIdStatsTotalOctets Counter32, smonVlanIdStatsTotalOverflowOctets Counter32, smonVlanIdStatsTotalHCOctets Counter64, smonVlanIdStatsNUcastPkts Counter32, Waterman, et al. Standards Track [Page 22] RFC 2613 SMON MIB June 1999 smonVlanIdStatsNUcastOverflowPkts Counter32, smonVlanIdStatsNUcastHCPkts Counter64, smonVlanIdStatsNUcastOctets Counter32, smonVlanIdStatsNUcastOverflowOctets Counter32, smonVlanIdStatsNUcastHCOctets Counter64, smonVlanIdStatsCreateTime LastCreateTime } smonVlanIdStatsId OBJECT-TYPE SYNTAX Integer32 (1..4094) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the VLAN monitored for this specific statistics collection. Tagged packets match the VID for the range between 1 and 4094. An external RMON probe MAY detect VID=0 on an Inter Switch Link, in which case the packet belongs to a VLAN determined by the PVID of the ingress port. The VLAN to which such a packet belongs can be determined only by a RMON probe internal to the switch." REFERENCE "Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D10, chapter 3.13" ::= { smonVlanIdStatsEntry 1 } smonVlanIdStatsTotalPkts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets counted on this VLAN." ::= { smonVlanIdStatsEntry 2 } smonVlanIdStatsTotalOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated smonVlanIdStatsTotalPkts counter has overflowed." ::= { smonVlanIdStatsEntry 3 } smonVlanIdStatsTotalHCPkts OBJECT-TYPE SYNTAX Counter64 Waterman, et al. Standards Track [Page 23] RFC 2613 SMON MIB June 1999 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets counted on this VLAN." ::= { smonVlanIdStatsEntry 4 } smonVlanIdStatsTotalOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets counted on this VLAN." ::= { smonVlanIdStatsEntry 5 } smonVlanIdStatsTotalOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated smonVlanIdStatsTotalOctets counter has overflowed." ::= { smonVlanIdStatsEntry 6 } smonVlanIdStatsTotalHCOctets OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets counted on this VLAN." ::= { smonVlanIdStatsEntry 7 } smonVlanIdStatsNUcastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of non-unicast packets counted on this VLAN." ::= { smonVlanIdStatsEntry 8 } smonVlanIdStatsNUcastOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" Waterman, et al. Standards Track [Page 24] RFC 2613 SMON MIB June 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated smonVlanIdStatsNUcastPkts counter has overflowed." ::= { smonVlanIdStatsEntry 9 } smonVlanIdStatsNUcastHCPkts OBJECT-TYPE SYNTAX Counter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of non-unicast packets counted on this VLAN." ::= { smonVlanIdStatsEntry 10 } smonVlanIdStatsNUcastOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of non-unicast octets counted on this VLAN." ::= { smonVlanIdStatsEntry 11 } smonVlanIdStatsNUcastOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated smonVlanIdStatsNUcastOctets counter has overflowed." ::= { smonVlanIdStatsEntry 12 } smonVlanIdStatsNUcastHCOctets OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Non-unicast octets counted on this VLAN." ::= { smonVlanIdStatsEntry 13 } smonVlanIdStatsCreateTime OBJECT-TYPE Waterman, et al. Standards Track [Page 25] RFC 2613 SMON MIB June 1999 SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This object allows to a management station to detect deletion and recreation cycles between polls." ::= { smonVlanIdStatsEntry 14 } -- smonPrioStatsControlTable smonPrioStatsControlTable OBJECT-TYPE SYNTAX SEQUENCE OF SmonPrioStatsControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of priority statistics tables. The smonPrioStatsControlTable allows configuration of collections based on the value of the 3-bit user priority field encoded in the Tag Control Information (TCI) field according to [19],[20]. Note that this table merely reports priority as encoded in the VLAN headers, not the priority (if any) given to the frame for the actual switching purposes." ::= { smonStats 3 } smonPrioStatsControlEntry OBJECT-TYPE SYNTAX SmonPrioStatsControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the smonPrioStatsControlTable." INDEX { smonPrioStatsControlIndex } ::= { smonPrioStatsControlTable 1 } SmonPrioStatsControlEntry ::= SEQUENCE { smonPrioStatsControlIndex Integer32, smonPrioStatsControlDataSource DataSource, smonPrioStatsControlCreateTime LastCreateTime, smonPrioStatsControlOwner OwnerString, smonPrioStatsControlStatus RowStatus } smonPrioStatsControlIndex OBJECT-TYPE Waterman, et al. Standards Track [Page 26] RFC 2613 SMON MIB June 1999 SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique arbitrary index for this smonPrioStatsControlEntry." ::= { smonPrioStatsControlEntry 1 } smonPrioStatsControlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of data for this set of VLAN statistics. This object MAY NOT be modified if the associated smonPrioStatsControlStatus object is equal to active(1)." ::= { smonPrioStatsControlEntry 2 } smonPrioStatsControlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was created. This object allows to a management station to detect deletion and recreation cycles between polls." ::= { smonPrioStatsControlEntry 3 } smonPrioStatsControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Administratively assigned named of the owner of this entry. It usually defines the entity that created this entry and is therefore using the resources assigned to it, though there is no enforcement mechanism, nor assurance that rows created are ever used." ::= { smonPrioStatsControlEntry 4 } smonPrioStatsControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Waterman, et al. Standards Track [Page 27] RFC 2613 SMON MIB June 1999 An entry MAY NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the smonPrioStatsTable SHALL be deleted." ::= { smonPrioStatsControlEntry 5 } -- The Priority Statistics Table smonPrioStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SmonPrioStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the priority statistics. The collections are based on the value of the 3-bit user priority field encoded in the Tag Control Information (TCI) field according to [19], [20]. Note that this table merely reports priority as encoded in the VLAN headers, not the priority (if any) given to the frame for the actual switching purposes. No garbage collection is designed for this table, as there always are at most eight rows per statistical set, and the low memory requirements do not justify the implementation of such a mechanism." ::= { smonStats 4 } smonPrioStatsEntry OBJECT-TYPE SYNTAX SmonPrioStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in smonPrioStatsTable." INDEX { smonPrioStatsControlIndex, smonPrioStatsId } ::= { smonPrioStatsTable 1 } SmonPrioStatsEntry ::= SEQUENCE { smonPrioStatsId Integer32, smonPrioStatsPkts Counter32, smonPrioStatsOverflowPkts Counter32, smonPrioStatsHCPkts Counter64, smonPrioStatsOctets Counter32, smonPrioStatsOverflowOctets Counter32, smonPrioStatsHCOctets Counter64 } smonPrioStatsId OBJECT-TYPE SYNTAX Integer32 (0..7) Waterman, et al. Standards Track [Page 28] RFC 2613 SMON MIB June 1999 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the priority level monitored for this specific statistics collection." REFERENCE " Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D10, chapter 4.3.2.1" ::= { smonPrioStatsEntry 1 } smonPrioStatsPkts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets counted on this priority level." ::= { smonPrioStatsEntry 2 } smonPrioStatsOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated smonPrioStatsPkts counter has overflowed." ::= { smonPrioStatsEntry 3 } smonPrioStatsHCPkts OBJECT-TYPE SYNTAX Counter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets counted on this priority level." ::= { smonPrioStatsEntry 4 } smonPrioStatsOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets counted on this priority level." Waterman, et al. Standards Track [Page 29] RFC 2613 SMON MIB June 1999 ::= { smonPrioStatsEntry 5 } smonPrioStatsOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated smonPrioStatsOctets counter has overflowed." ::= { smonPrioStatsEntry 6 } smonPrioStatsHCOctets OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets counted on this priority level." ::= { smonPrioStatsEntry 7 } portCopyTable OBJECT-TYPE SYNTAX SEQUENCE OF PortCopyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Port Copy provides the ability to copy all frames from a specified source to specified destination within a switch. Source and destinations MUST be ifEntries, as defined by [22]. One to one, one to many, many to one and many to many source to destination relationships may be configured. Applicable counters on the destination will increment for all packets transiting the port, be it by normal bridging/switching or due to packet copy. Note that this table manages no RMON data collection by itself, and an agent may possibly implement no RMON objects except objects related to the port copy operation defined by the portCopyCompliance conformance macro. That allows for a switch with no other embedded RMON capability to perform port copy operations to a destination port at which a different external RMON probe is connected. One to one, many to one and one to many source to destination relationships may be configured. Waterman, et al. Standards Track [Page 30] RFC 2613 SMON MIB June 1999 Each row that exists in this table defines such a relationship. By disabling a row in this table the port copy relationship no longer exists. The number of entries and the types of port copies (1-1, many-1, 1-many) are implementation specific and could possibly be dynamic due to changing resource availability. In order to configure a source to destination portCopy relationship, both source and destination interfaces MUST be present as an ifEntry in the ifTable and their respective ifAdminStatus and ifOperStatus values MUST be equal to 'up(1)'. If the value of any of those two objects changes after the portCopyEntry is activated, portCopyStatus will transition to 'notReady(3)'. The capability of an interface to be source or destination of a port copy operation is described by the 'copySourcePort(0)' and 'copyDestPort(1)' bits in dataSourceCopyCaps. Those bits SHOULD be appropriately set by the agent, in order to allow for a portCopyEntry to be created. Applicable counters on the destination will increment for all packets transmitted, be it by normal bridging/switching or due to packet copy." ::= { portCopyConfig 1 } portCopyEntry OBJECT-TYPE SYNTAX PortCopyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a particular port copy entry." INDEX { portCopySource, portCopyDest } ::= { portCopyTable 1 } PortCopyEntry ::= SEQUENCE { portCopySource InterfaceIndex, portCopyDest InterfaceIndex, portCopyDestDropEvents Counter32, portCopyDirection INTEGER, portCopyStatus RowStatus } Waterman, et al. Standards Track [Page 31] RFC 2613 SMON MIB June 1999 portCopySource OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the source which will have all packets redirected to the destination as defined by portCopyDest." ::= { portCopyEntry 1 } portCopyDest OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the ifIndex destination for the copy operation." ::= { portCopyEntry 2 } portCopyDestDropEvents OBJECT-TYPE SYNTAX Counter32 UNITS "events" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of events in which port copy packets were dropped by the switch at the destination port due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is just the number of times this condition has been detected. A single dropped event counter is maintained for each portCopyDest. Thus all instances associated with a given portCopyDest will have the same portCopyDestDropEvents value." ::= { portCopyEntry 3 } portCopyDirection OBJECT-TYPE SYNTAX INTEGER { copyRxOnly(1), copyTxOnly(2), copyBoth(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object affects the way traffic is copied from a switch source port, for the indicated port copy operation. Waterman, et al. Standards Track [Page 32] RFC 2613 SMON MIB June 1999 If this object has the value 'copyRxOnly(1)', then only traffic received on the indicated source port will be copied to the indicated destination port. If this object has the value 'copyTxOnly(2)', then only traffic transmitted out the indicated source port will be copied to the indicated destination port. If this object has the value 'copyBoth(3)', then all traffic received or transmitted on the indicated source port will be copied to the indicated destination port. The creation and deletion of instances of this object is controlled by the portCopyRowStatus object. Note that there is no guarantee that changes in the value of this object performed while the associated portCopyRowStatus object is equal to active will not cause traffic discontinuities in the packet stream." DEFVAL { copyBoth } ::= { portCopyEntry 4 } portCopyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the status of the port copy entry. In order to configure a source to destination portCopy relationship, both source and destination interfaces MUST be present as an ifEntry in the ifTable and their respective ifAdminStatus and ifOperStatus values MUST be equal to 'up(1)'. If the value of any of those two objects changes after the portCopyEntry is activated, portCopyStatus will transition to 'notReady(3)'. The capability of an interface to be source or destination of a port copy operation is described by the 'copySourcePort(0)' and 'copyDestPort(1)' bits in dataSourceCopyCaps. Those bits SHOULD be appropriately set by the agent, in order to allow for a portCopyEntry to be created." ::= { portCopyEntry 5 } -- smonRegistrationPoints -- defines a set of OIDs for registration purposes of entities -- supported by the SMON MIB. smonVlanDataSource Waterman, et al. Standards Track [Page 33] RFC 2613 SMON MIB June 1999 OBJECT IDENTIFIER ::= { smonRegistrationPoints 1} -- Defined for use as an SmonDataSource. A single integer parameter -- is appended to the end of this OID when actually encountered in -- the dataSourceCapsTable, which represents a positive, non-zero -- VLAN identifier value. -- Conformance Macros smonMIBCompliances OBJECT IDENTIFIER ::= { rmonConformance 3} smonMIBGroups OBJECT IDENTIFIER ::= { rmonConformance 4} smonMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for full conformance with the SMON MIB" MODULE -- this module MANDATORY-GROUPS {dataSourceCapsGroup, smonVlanStatsGroup, smonPrioStatsGroup, portCopyConfigGroup, smonInformationGroup} GROUP smonHcTo100mbGroup DESCRIPTION "This group of VLAN statistics counter are mandatory only for those network interfaces for which the corresponding ifSpeed can be greater than 10MB/sec and less than or equal to 100MB/sec." GROUP smonHc100mbPlusGroup DESCRIPTION "This group of VLAN statistics counters are mandatory only for those network interfaces for which the corresponding ifSpeed can be more than 100MB/sec. This group of VLAN statistics is also mandatory for smonDataSources of type VLAN or entPhysicalEntry." ::= { smonMIBCompliances 1 } smonMIBVlanStatsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance with the SMON MIB with support for VLAN Statistics. Mandatory for a SMON probe in environment where IEEE 802.1Q bridging is implemented." MODULE -- this module Waterman, et al. Standards Track [Page 34] RFC 2613 SMON MIB June 1999 MANDATORY-GROUPS {dataSourceCapsGroup, smonVlanStatsGroup, smonInformationGroup} GROUP hcVlanTo100mbGroup DESCRIPTION "This group of VLAN statistics counter are mandatory only for those network interfaces for which the corresponding ifSpeed can be up to and including 100MB/sec." GROUP hcVlan100mbPlusGroup DESCRIPTION "This group of VLAN statistics counters are mandatory only for those network interfaces for which the corresponding ifSpeed is greater than 100MB/sec. This group of VLAN statistics is also mandatory for smonDataSources of type VLAN or entPhysicalEntry." ::= { smonMIBCompliances 2 } smonMIBPrioStatsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance with the SMON MIB with support for priority level Statistics. Mandatory for a SMON probe in a environment where IEEE 802.1p priority-switching is implemented." MODULE -- this module MANDATORY-GROUPS {dataSourceCapsGroup, smonPrioStatsGroup, smonInformationGroup} GROUP hcPrioTo100mbGroup DESCRIPTION "This group of VLAN priority statistics counters are mandatory only for those network interfaces for which the corresponding ifSpeed can be up to and including 100MB/sec." GROUP hcPrio100mbPlusGroup DESCRIPTION "This group is mandatory only for those network interfaces for which the corresponding ifSpeed is greater than 100MB/sec. This group of VLAN priority statistics is also mandatory for smonDataSources of type VLAN or entPhysicalEntry" ::= { smonMIBCompliances 3 } portCopyCompliance MODULE-COMPLIANCE Waterman, et al. Standards Track [Page 35] RFC 2613 SMON MIB June 1999 STATUS current DESCRIPTION "Describes the requirements for conformance with the port copy functionality defined by the SMON MIB" MODULE -- this module MANDATORY-GROUPS {dataSourceCapsGroup, portCopyConfigGroup, smonInformationGroup} ::= { smonMIBCompliances 4} dataSourceCapsGroup OBJECT-GROUP OBJECTS { dataSourceRmonCaps, dataSourceCopyCaps, dataSourceCapsIfIndex} STATUS current DESCRIPTION "Defines the objects that describe the capabilities of RMON data sources." ::= {smonMIBGroups 1 } smonVlanStatsGroup OBJECT-GROUP OBJECTS { smonVlanStatsControlDataSource, smonVlanStatsControlCreateTime, smonVlanStatsControlOwner, smonVlanStatsControlStatus, smonVlanIdStatsTotalPkts, smonVlanIdStatsTotalOctets, smonVlanIdStatsNUcastPkts, smonVlanIdStatsCreateTime} STATUS current DESCRIPTION "Defines the switch monitoring specific statistics - per VLAN Id on interfaces of 10MB or less." ::= { smonMIBGroups 2 } smonPrioStatsGroup OBJECT-GROUP OBJECTS { smonPrioStatsControlDataSource, smonPrioStatsControlCreateTime, smonPrioStatsControlOwner, smonPrioStatsControlStatus, smonPrioStatsPkts, smonPrioStatsOctets} STATUS current DESCRIPTION "Defines the switch monitoring specific statistics - per VLAN Id on interface." Waterman, et al. Standards Track [Page 36] RFC 2613 SMON MIB June 1999 ::= { smonMIBGroups 3 } smonHcTo100mbGroup OBJECT-GROUP OBJECTS { smonVlanIdStatsTotalOverflowOctets, smonVlanIdStatsTotalHCOctets, smonPrioStatsOverflowOctets, smonPrioStatsHCOctets} STATUS current DESCRIPTION "Defines the additional high capacity statistics needed to be kept on interfaces with ifSpeed greater than 10MB/sec and less than or equal to 100MB/sec." ::= { smonMIBGroups 4 } smonHc100mbPlusGroup OBJECT-GROUP OBJECTS { smonVlanIdStatsTotalOverflowPkts, smonVlanIdStatsTotalHCPkts, smonVlanIdStatsTotalOverflowOctets, smonVlanIdStatsTotalHCOctets, smonVlanIdStatsNUcastOverflowPkts, smonVlanIdStatsNUcastHCPkts, smonPrioStatsOverflowPkts, smonPrioStatsHCPkts, smonPrioStatsOverflowOctets, smonPrioStatsHCOctets} STATUS current DESCRIPTION "Defines the additional high capacity statistics needed to be kept on interfaces with ifSpeed of more than 100MB/sec. These statistics MUST also be kept on smonDataSources of type VLAN or entPhysicalEntry." ::= { smonMIBGroups 5 } hcVlanTo100mbGroup OBJECT-GROUP OBJECTS { smonVlanIdStatsTotalOverflowOctets, smonVlanIdStatsTotalHCOctets} STATUS current DESCRIPTION "Defines the additional high capacity VLAN statistics needed to be kept on interfaces with ifSpeed greater than 10MB/sec and less than or equal to 100MB/sec." ::= { smonMIBGroups 6 } hcVlan100mbPlusGroup OBJECT-GROUP OBJECTS { smonVlanIdStatsTotalOverflowPkts, smonVlanIdStatsTotalHCPkts, smonVlanIdStatsTotalOverflowOctets, smonVlanIdStatsTotalHCOctets, Waterman, et al. Standards Track [Page 37] RFC 2613 SMON MIB June 1999 smonVlanIdStatsNUcastOverflowPkts, smonVlanIdStatsNUcastHCPkts} STATUS current DESCRIPTION "Defines the additional high capacity VLAN statistics needed to be kept on interfaces with ifSpeed of more than 100MB/sec. These statistics MUST also be kept on smonDataSources of type VLAN or entPhysicalEntry." ::= { smonMIBGroups 7 } hcPrioTo100mbGroup OBJECT-GROUP OBJECTS { smonPrioStatsOverflowOctets, smonPrioStatsHCOctets } STATUS current DESCRIPTION "Defines the additional high capacity VLAN priority statistics needed to be kept on interfaces with ifSpeed of greater than 10MB/sec and less than or equal to 100MB/sec." ::= { smonMIBGroups 8 } hcPrio100mbPlusGroup OBJECT-GROUP OBJECTS { smonPrioStatsOverflowPkts, smonPrioStatsHCPkts, smonPrioStatsOverflowOctets, smonPrioStatsHCOctets} STATUS current DESCRIPTION "Defines the additional high capacity VLAN priority statistics needed to be kept on interfaces with ifSpeed of greater than 100MB/sec. These statistics MUST also be kept on smonDataSources of type VLAN or entPhysicalEntry." ::= { smonMIBGroups 9 } smonVlanStatsExtGroup OBJECT-GROUP OBJECTS {smonVlanIdStatsNUcastOctets, smonVlanIdStatsNUcastOverflowOctets, smonVlanIdStatsNUcastHCOctets} STATUS current DESCRIPTION "Defines the switch monitoring specific statistics for systems capable of counting non-unicast octets for a given dataSource (as described in the dataSourceRmonCaps object)." ::= { smonMIBGroups 10 } smonInformationGroup OBJECT-GROUP OBJECTS { smonCapabilities } Waterman, et al. Standards Track [Page 38] RFC 2613 SMON MIB June 1999 STATUS current DESCRIPTION "An indication of the SMON capabilities supported by this agent." ::= { smonMIBGroups 11 } portCopyConfigGroup OBJECT-GROUP OBJECTS { portCopyDestDropEvents, portCopyDirection, portCopyStatus } STATUS current DESCRIPTION "Defines the control objects for copy port operations." ::= { smonMIBGroups 12 } END 6. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Waterman, et al. Standards Track [Page 39] RFC 2613 SMON MIB June 1999 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [17] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995. [18] McCloghrie, K. and A. Bierman, "Entity MIB", RFC 2037, October 1996. [19] ISO/IEC Final CD 15802-3, ANSI/IEEE Std 802.1D-1998 "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class Expediting and Dynamic Multicast Filtering)", March 1998. [20] ANSI/IEEE Draft Standard P802.1Q/D10, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", March 1998. Waterman, et al. Standards Track [Page 40] RFC 2613 SMON MIB June 1999 [21] De Graaf, K., Romascanu, D., McMaster, D. and K. McCloghrie, "Definition of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997. [22] McCloghrie, K. and F. Kastenholz," The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [23] Decker, E. Langille, P., Rijsinghani, A. and K. McCloghrie.. - "Definitions of Managed Objects for Bridges", RFC 1493, July 1993 [24] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [25] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Waterman, et al. Standards Track [Page 41] RFC 2613 SMON MIB June 1999 There are a number of managed objects in this MIB that may contain sensitive information. These are: smonCapabilities dataSourceCapsTable portCopyTable It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is RECOMMENDED that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is RECOMMENDED. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Waterman, et al. Standards Track [Page 42] RFC 2613 SMON MIB June 1999 9. Authors' Addresses Richard Waterman Allot Communications 292 E. Main St. Los Gatos, CA. 95030 USA Phone: +1-408-399-3154 EMail: rich@allot.com Bill Lahaye Xylan Corporation 26707 W. Agoura Rd. Calabasas, CA 91302 USA Phone: +1-800-995-2612 EMail bill.lahaye@xylan.com Dan Romascanu Lucent Technologies Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Phone: +972-3-645-8414 EMail: dromasca@lucent.com Steven Waldbusser International Network Services (INS) 1213 Innsbruck Dr. Sunnyvale, CA 94089 Phone: +1-650-318-1251 EMail: waldbusser@ins.com Waterman, et al. Standards Track [Page 43] RFC 2613 SMON MIB June 1999 A. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Waterman, et al. Standards Track [Page 44] snmp-mibs-downloader-1.1/mibrfcs/rfc2662.txt0000644000000000000000000074252211402176071015575 0ustar Network Working Group G. Bathrick Request for Comments: 2662 AG Communication Systems Category: Standards Track F. Ly Copper Mountain Networks August 1999 Definitions of Managed Objects for the ADSL Lines 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1. Abstract .............................................. 1 2. The SNMP Network Management Framework ................. 2 3. Object Definitions ..................................... 3 4. Relationship of the ADSL LINE MIB with standard MIBs ... 3 5. Conventions used in the MIB ............................ 7 6. Conformance and Compliance ............................. 17 7. Definitions ............................................ 17 8. Acknowledgments ........................................ 110 9. References ............................................. 111 10. Security Considerations ................................ 113 11. Intellectual Property Notice ........................... 114 12. Authors' Addresses ..................................... 114 13. Full Copyright Statement ............................... 115 1. Abstract This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model [9]. The ADSL standard describes ATU-C and ATU-R as two sides of the ADSL line. This MIB covers both ATU-C and ATU-R agent's perspectives. Each instance defined in the MIB represents a single ADSL line. Bathrick & Ly Standards Track [Page 1] RFC 2662 ADSL Line MIB August 1999 It should be noted that the ADSL Forum Network Management Working Group provided input towards the content of this document. See the Acknowledgement Section for a list of individuals who made this document possible. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [13]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [14], STD 16, RFC 1212 [15] and RFC 1215 [16]. The second version, called SMIv2, is described in STD 58, RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [17]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [7]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [18] and RFC 1906 [19]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [19], RFC 2572 [20] and RFC 2574 [21]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [7]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [8]. o A set of fundamental applications described in RFC 2573 [22] and the view-based access control mechanism described in RFC 2575 [23]. This document specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Bathrick & Ly Standards Track [Page 2] RFC 2662 ADSL Line MIB August 1999 3. 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 extended 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 also refer to the object type. 4. Relationship of the ADSL LINE MIB with standard MIBs This section outlines the relationship of ADSL Line MIB with other MIBs described in RFCs and in their various degrees of "standardization". 4.1 Use of the IfTable The ADSL LINE MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with IF-MIB [5]. The IANA has assigned the following ifType(s) relative to ADSL: IANAifType ::= TEXTUAL-CONVENTION . . . SYNTAX INTEGER { . . . adsl(94), -- Asymmetric Digital Subscriber Loop . . . adslInterleave(124), -- ADSL Interleaved Channel adslFast(125), -- ADSL Fast Channel . . . } Interfaces of each of these types are modeled by this document. Most MIB tables in this document represent information of one of these interface types and are indexed by ifIndex. Remaining are `profile' tables which may be accessed by the profileIndex. This is explained in more detail in section 5.4 Profiles. Bathrick & Ly Standards Track [Page 3] RFC 2662 ADSL Line MIB August 1999 4.1.1 ADSL Interface Types As shown below, three ADSL interface types are defined in this document, namely physical, interleaved channel, and fast channel. The physical interface represents characteristics of the physical media associated with both the ATUC and ATUR. The interleaved and fast channel interface represent the characteristics of the two types of ADSL channels. For each ADSL Line, a physical interface always exists. Depending on which ADSL operational configuration is present (as listed in Figure 5), the channel interfaces (fast or interleaved) may or may not exist. ______ ______ | |____________________| | | ATUC | | ATUR | | |____________________| | |______| |______| | <----- physical --------> | | <--- fast channel ------> | | <- interleaved channel -> | Figure 1: ADSL Model 4.1.2 Use of IF-MIB (Interface MIB RFC 2233) [5] The following attributes are part of the required ifGeneralInformationGroup object group specified in RFC 2233 [5], and are not duplicated in the ADSL MIB. Keep in mind that these objects apply to the agent's view of the line. Bathrick & Ly Standards Track [Page 4] RFC 2662 ADSL Line MIB August 1999 ifTable Object Use for ADSL ================================================================== ifIndex Interface index. ifDescr See interfaces MIB [5] ifType physical - adsl(94) fast - adslFast(125) interleaved - adslInterleave(124) ifSpeed Transmit rate from the perspective of the agent. physical - line rate fast - channel rate interleaved - channel rate ifPhysAddress This object should have an octet string with zero length. ifAdminStatus See interfaces MIB [5] ifOperStatus See interfaces MIB [5] Supplemented by adslAturCurrStatus and adslAturCurrStatus ifLastChange See interfaces MIB [5] ifName See interfaces MIB [5] ifLinkUpDownTrapEnable See interfaces MIB [5] Default set as follows: physical - enabled(1) fast - disabled(2) interleaved - disabled(2) ifHighSpeed Speed of line in Mega-bits per second (ifSpeed/1,000,000) ifConnectorPresent See interfaces MIB [5] Default set as follows: physical - true(1) fast - false(2) Bathrick & Ly Standards Track [Page 5] RFC 2662 ADSL Line MIB August 1999 interleaved - false(2) ifAlias See interfaces MIB [5] ifTableLastChange See interfaces MIB [5] ================================================================== Figure 2: Use of ifTable Objects: ifGeneralInformationGroup Use of the ifStackTable to associate the entries for physical, fast, interleaved channels, and higher layers (e.g., ATM) is shown below in figure 3. Use of ifStackTable is necessary, because configuration information is stored in profile tables associated with the physical-layer ifEntry only. The channels' ifEntrys need the ifStackTable to find their associated physical-layer entry and thus their configuration parameters. (See Profile section, 5.4). ______ (ifEntry=j) ______ | | fast channel | | | |________________________| | | | and/or | | | | | | | | (ifEntry=k) | | | | interleaved channel | | | |________________________| | | ATUC | | ATUR | | | | | | | (ifEntry=i) | | | | physical | | | |________________________| | |______| |______| Figure 3: Use of ifStackTable (part 1) The ifStackTable is then used to show the relationships between the various ADSL interfaces, as illustrated below in figure 4. HigherLayer LowerLayer -------------------------- j i k i Figure 4: Use of ifStackTable (part 2) The ifRcvAddressTable is not applicable for ADSL interfaces. Bathrick & Ly Standards Track [Page 6] RFC 2662 ADSL Line MIB August 1999 4.2 Relationship with RFC 2037 [25] Implementation of the Entity MIB [25] is optional. It in no way alters the information required in the adslLineMib, nor does it alter the relationship with IF-MIB. The Entity MIB introduces a standardized way of presenting the components of complex systems, such as a Digital Subscriber Line Access Multiplexer (DSLAM), that may contain multiple racks, shelves, line cards, and/or ports. The Entity MIB's main goal is to present these system components, their containment relationship, and mapping information with other MIBs such as the Interface MIB and the adslLineMib. If ATU-C agent is implemented, the Entity MIB should include entities for the ATU-C in the entPhysicalTable. The MIB's entAliasMappingTable would contain mapping information identifying the 'ifIndex' object associated with each ATU-C. However, if ATU-R agent is implemented, the Entity MIB should include entities for the ATU-R in the entPhysicalTable. In this case, the MIB's entAliasMappingTable would contain mapping information identifying the 'ifIndex' object associated with each ATU-R. Also associating the relationship between the ifTable and Entity MIB, the entPhysicalTable contains an 'entPhysicalName' object, which approximates the semantics of the 'ifName' object from the Interface MIB. 5. Conventions used in the MIB 5.1 Naming Conventions A. Atuc/Atur are used for the ATU-C and ATU-R. In other RFCs, these are sometimes referred to as the Near End (Ne) and Far End (Fe) respectively, but not in this document. B. The terms, "transmit" and "receive", are from the perspective of the corresponding table's end of the line. For example, in the case of Fast channels, adslAtucChanConfFastMaxTxRate defines the "downstream" rate, while adslAturChanConfFastMaxTxRate defines the "upstream" rate for a particular channel. C. There are two possible channels: fast, and interleaved. None, one or both may be implemented on a particular ADSL Line. Figure 5 illustrates all possible operational configurations. Bathrick & Ly Standards Track [Page 7] RFC 2662 ADSL Line MIB August 1999 D. Lof, Lol, Los, Lpr mean Loss of Framing, Link, Signal, and Power, respectively. Lpr is used by T1E1, so it is used for consistency (rather than Lop). A Loss of Link condition is declared at the ATU-C if a Loss of Signal is not preceded by a `dying-gasp' message from the ATU-R. Note that Loss of Link is only supported by the ATU-C. E. ES means errored second. An Errored Second is any second containing one or more CRC anomaly, or one or more Los(s) or Severely Errored Frame (Sef) defect(s). F. A "block" is a physical-layer `data buffer' over which CRCs are calculated. For example, in DMT, the block is defined as the ADSL superframe. The block duration is 250 micro-seconds so the block length in bytes, as defined in adslAtu*ChanCrcBlockLength, varies with data rate. See Line Code Specific MIBs [11] [12] for more line code specific information. G. Atn means Attenuation, Psd is Power Spectral Density and Snr is Signal to Noise Ratio. H. LCS means line code specific, e.g., o DMT = Discrete MultiTone o CAP = Carrierless Amplitude and Phase modulation and o QAM = Quadrature Amplitude Modulation I. Vendor (in the Inventory objects) refers to the manufacturer of the ATU-C or ATU-R assembly, not the modem chip vendor. When in doubt, use the manufacturer of the smallest field replaceable unit (e.g., stand-alone modem box, plug-in board). J. RADSL - Rate Adaptive Asymmetric Digital Subscriber Loop 5.2 Structure The MIB has multiple parallel tables. There are tables for: o line - common attributes o atuc and atur status Bathrick & Ly Standards Track [Page 8] RFC 2662 ADSL Line MIB August 1999 o atuc and atur performance - Current and up to 96 buckets of 15 min performance history - Current and Previous 1-day bucket performance history o profiles - configuration parameters and alarm parameters There are separate tables for Physical and Channel layers. Since their attributes are similar, only one set of "channel" tables are defined to be used for both fast and interleaved channels. The corresponding ifType gives the proper interpretation for that ifEntry. It is intented that Line Code Specific MIBs be located under adslLCSMib. These MIBs will be defined in separate modules. There could have been fewer tables by combining the ATU-C and ATU-R information into shared tables. However, the tables are more easily read when there are two identical sets of data. The figure below lists the five possible ADSL operational configurations. (indicated by the value of the adslLineType). In all configurations, the physical line interface entry will exist. However, the existence of the ADSL channel varies in each case, as shown below. Table Phys Fast Interleaved ___________________________________________________________ No Channels (1) | Y | | | Fast Only (2) | Y | Y | | Interleaved Only (3) | Y | | Y | Fast or Interleaved (4) | Y | Y | Y | Fast and Interleaved (5) | Y | Y | Y | Figure 5: ADSL Operational configurations NOTE: In (4), channel exists of either Fast or Interleaved type, but not both. The Manager may select the type of channel to be used. Depending on which operation configuration exists, some or all ADSL MIB tables could be supported, as shown in below. See Conformance Statements for more information on which objects are mandatory. Bathrick & Ly Standards Track [Page 9] RFC 2662 ADSL Line MIB August 1999 Table Phys Fast Interleaved ___________________________________________________________ adslLineTable | Y | | | adslAtucPhysTable | Y | | | adslAturPhysTable | Y | | | adslAtucChanTable | | Y | Y | adslAturChanTable | | Y | Y | adslAtucPerfDataTable | Y | | | adslAturPerfDataTable | Y | | | adslAtucIntervalTable | Y | | | adslAturIntervalTable | Y | | | adslAtucChanPerfDataTable | | Y | Y | adslAturChanPerfDataTable | | Y | Y | adslAtucChanIntervalTable | | Y | Y | adslAturChanIntervalTable | | Y | Y | Figure 6: Use of ADSL MIB Tables with various ifIndex values NOTE: The adslLineConfProfileTable and adslLineAlarmConfProfileTable will be present for all scenarios. See Profile Section of this document for implementation details such as profile creation, assignment, and indexing. 5.2.1 Structure of Conformance Groups The MIB is organized to cover both ends of the ADSL line, ATU-C and ATU-R. Objects defined can be categorized into two groups: the ATU-C group which provides objects that are supported by ATU-C agents and the ATU-R group which provides objects that are supported by ATU-R agents. These two groups are defined by the conformance section of the MIB. All objects defined in the MIB module are supported by the ATU-C agent and only portions of the objects are supported by the ATU-R agent. Figure 7 lists all tables/objects that are supported by the ATU-R agent. Bathrick & Ly Standards Track [Page 10] RFC 2662 ADSL Line MIB August 1999 Table Objects _______________________________________________________ adslLineTable adslLineCoding adslAtucPhysTable adslAtucInvVendorID adslAtucInvVersionNumber adslAtucCurrStatus (Partial) adslAtucCurrOutputPwr adslAtucCurrAttainableRate adslAturPhysTable all are supported adslAtucChanTable all except adslAtucChanCrcBlockLength are supported adslAtucPerfDataTable all except adslAtucPerfLols, adslAtucPerfLprs adslAtucPerfCurr15MinLols, adslAtucPerfCurr15MinLprs, adslAtucPerfCurr1DayLols, adslAtucPerfCurr1DayLprs, adslAtucPerfPrev1DayLols and adslAtucPerfPrev1DayLprs are supported adslAturPerfDataTable all are supported adslAtucIntervalTable adslAtucIntervalLofs adslAtucIntervalLoss adslAtucIntervalESs adslAtucIntervalInits adslAtucIntervalValidData adslAturIntervalTable all are supported adslAtucChanPerfDataTable all are supported adslAturChanPerfDataTable all are supported adslAtucChanIntervalTable all are supported adslAturChanIntervalTable all are supported adslLineConfProfileTable not supported adslLineAlarmConfProfileTable all are supported except adslAtucThresh15MinLols and adslAtucThresh15MinLprs -------------------------------------------------------------------- Figure 7: MIB Tables and Objects Supported by the ATU-R Agent Bathrick & Ly Standards Track [Page 11] RFC 2662 ADSL Line MIB August 1999 All traps supported by the ATU-R agent are also listed: adslAtucPerfLofsThreshTrap adslAtucPerfLossThreshTrap adslAtucPerfESsThreshTrap adslAtucRateChangeTrap adslAturPerfLofsThreshTrap adslAturPerfLossThreshTrap adslAturPerfLprsThreshTrap adslAturPerfESsThreshTrap adslAturRateChangeTrap 5.3 Counters, Interval Buckets and Thresholds For physical-level ES, Los, Lof, Lol, Lpr and line initialization attempts, there are event counters, current 15-minute and one (up to 96) 15-minute history bucket(s) of "interval-counters", as well as current and previous 1-day interval-counters. Each physical-layer current 15-minute event bucket has threshold trap. At the channel level, there are counters for total received blocks, received-and-corrected blocks, received-but-uncorrectable blocks, and transmitted blocks. There are the same set of 15-minute and 1-day buckets as at the physical-layer. There is no requirement for an agent to ensure fixed relationship between the start of a fifteen minute and any wall clock; however some implementations may align the fifteen minute intervals with quarter hours. Likewise, an implementation may choose to align one day intervals with start of a day. Separate tables are provided for the 96 interval-counters. They are indexed by {ifIndex, AdslAtu*IntervalNumber}. Counters are not reset when an ATU-C or ATU-R is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB). The 15-minute event counters are of type PerfCurrentCount and PerfIntervalCount. The 1-day event counters are of type AdslPerfCurrDayCount and AdslPerfPrevDayCount. Both 15-minute and 1- day time elapsed counters are of type AdslPerfTimeElapsed. Bathrick & Ly Standards Track [Page 12] RFC 2662 ADSL Line MIB August 1999 5.4 Profiles As a managed node can handle a large number of ATU-Cs (e.g., hundreds or perhaps thousands of ADSL lines), provisioning every parameter on every ATU-C may become burdensome. In response, two MIB tables have been created to define ADSL equipment configuration data profiles, as well as a mechanism to associate the equipment to these profiles. Profile tables may be implemented in one of two ways, but not simultaneously: o MODE-I: Dynamic Profiles - one profile shared by one or multiple ADSL lines. o MODE-II: Static Profiles - one profile per ADSL physical line always. 5.4.1 MODE-I : Dynamic Profiles Implementations using this mode will enable the manager to dynamically create and delete profiles as needed. The index of the profile is an locally-unique administratively assigned name for the profile having the textual convention `SnmpAdminString' (RFC2571 [13]). One or more ADSL lines may be configured to share parameters of a single profile (e.g., adslLineConfProfileName = `silver') by setting its adslLineConfProfile objects to the index value of this profile. If a change is made to the profile, all lines that refer to it will be re-configured to the changed parameters. Before a profile can be deleted or taken out of service it must be first unreferenced from all associated lines. This figure below shows an example of how this mode can be implemented. In the example, ADSL lines `1' and `x' share the configuration of the `silver' profile, while line `2' uses the `platinum' profile. The `gold' profile has no lines associated with it. Bathrick & Ly Standards Track [Page 13] RFC 2662 ADSL Line MIB August 1999 ADSL ifIndex ifTable Configuration Line Profile Table __________________________________________________________________ 1 i1 ADSL Line -- ---> Platinum Profile j1 Fast Chan | | k1 Int Chan | | | ^ v | Gold Profile 2 i2 ADSL Line ------->---- j2 Fast Chan | k2 Int Chan | | | | v x ix ADSL Line ------>------> Silver Profile jx Fast Chan ---------------> kx Int Chan __________________________________________________________________ Figure 8: Use of Dynamic Profiles: MODE-I In the figure above, note that three interface entries of an ADSL line, physical, fast channel, and interleaved channel, are represented by `i', `j', and `k'. Only the physical-layer entry `i' contains an adslLineTable entry, therefore only those entries contain pointers to the adslLineConfProfileTable. The ifStackTable (see rfc2233 [5]) can be used to link the channel entries to the corresponding physical-layer entry to get the channel's configuration parameters. See figure 4 for use of the ifStackTable. The same characteristics and mechanisms are present for the alarm profile type. There is no requirement that its index be the same as the configuration profile. Implementations of this mode, must provide a default profile whose name is `DEFVAL' for each profile type: Configuration and Alarm. The values of the associated parameters will be vendor specific unless otherwise indicated in this document. Before a line's profiles have been set, these profiles will be automatically used by setting adslLineConfProfile and adslLineAlarmConfProfile to `DEFVAL'. Bathrick & Ly Standards Track [Page 14] RFC 2662 ADSL Line MIB August 1999 In this mode, profiles are created, assigned, and deleted dynamically using these four objects: adslLineConfProfile, adslLineConfProfileRowStatus, adslLineAlarmConfProfile, and adslLineAlarmConfProfileRowStatus. 5.4.2 MODE-II : Static Profiles Implementations with this mode will automatically create a profile one-for-one with each ADSL line physical entry. The name of this profile is a system generated read-only object whose value is equivalent to the index of the physical line. The Agent will not allow a Manager to create/delete profiles in this mode. Therefore, adslLineConfProfile, adslLineConfProfileRowStatus, adslLineAlarmConfProfile, and adslLineAlarmConfProfileRowStatus objects have minimal value in this mode and are read-only. The figure below shows an example of this mode. In the example, ADSL lines `1', `2', and `x' each have their own profiles. ADSL ifIndex ifTable Configuration Line Profile Table __________________________________________________________________ 1 i1 ADSL Line ------------> Profile j1 Fast Chan k1 Int Chan 2 i2 ADSL Line ------------> Profile j2 Fast Chan k2 Int Chan x ix ADSL Line ------------> Profile jx Fast Chan kx Int Chan __________________________________________________________________ Figure 9: Use of Static Profiles: MODE II 5.5 Traps These SNMP traps are required: coldStart / warmStart (per [6]) -- which are per agent (e.g., per DSLAM in such a device), and linkUp / linkDown (per [5]) -- which are per interface (i.e., ADSL line). Note: RFC 2233 [5] recommends that linkUp / linkDown only be used at a physical-layer ifEntry, as discussed above. Bathrick & Ly Standards Track [Page 15] RFC 2662 ADSL Line MIB August 1999 A linkDown trap is generated whenever any of Lof, Los, Lol, Loss of Signal Quality, or Lpr events occurs. At this operational point, a manager can use adslAtu*CurrStatus for additional detailed information. The corresponding linkUp trap is sent when all link failure conditions are cleared. The traps defined in this MIB are for initialization failure, rate change, and for the threshold crossings associated with the following events: Lofs, Lols, Loss, Lprs, and ESs. Each threshold has its own enable/threshold value. When that value is 0, the trap is disabled. The current status objects (adslAtu*CurrStatus) indicate, through a bitmask, all outstanding error conditions or that the line is operational. Note that each object claims to represent the status of the modem at that end of the line. However, since the SNMP agent likely co-resides with only one end of the line, the corresponding far-end current status object may be incomplete. For example, when there are errors on the line, the far-end ATU may not be able to correctly report this condition. Therefore, not all conditions are included in its current status. A threshold trap occurs whenever the corresponding current 15-minute interval error counter becomes equal and/or exceeds to the threshold value. One trap will be sent per interval per interface. Since the current 15-minute counter are reset to 0 every 15 minutes, if the condition persists, the trap may recur as often as every 15 minutes. For example, to get a trap whenever a "loss of" event occurs (but at most once every 15 minutes), set the corresponding "Thresh15Min" to 1. The agent will generate a trap when the event originally occurs. Note that the NMS will get a linkDown trap, as well, if enabled. At the beginning of the next 15 minute interval, the counter is reset. When the first second goes by and the event occurs, the current interval bucket will be 1, which equals the threshold and the trap will be sent again. The rate change trap is invoked when the transmit rate on a channel either increases by adsl(x)Thresh(y)RateUp or decreases by adsl(x)Thresh(y)RateDown. The trap is per direction:(x) == Atuc or Atur, and per channel: (y) == Fast or Interleave. In other words, the trap is sent whenever the rate changes in either direction on either channel and: CurrTxRate >= PrevTxRate plus ThreshRateUp or CurrTxRate <= PrevTxRate minus ThreshRateDown Bathrick & Ly Standards Track [Page 16] RFC 2662 ADSL Line MIB August 1999 No trap is sent on initialization. It can be disabled by setting the Up (and/or) Down threshold rates to 0. The PrevTxRate object is set to the current value at initialization and when a trap is sent. Thus rate changes are cumulative until the total change reaches the threshold. 6. Conformance and Compliance See the conformance and compliance statements within the information module. 7. Definitions ADSL-TC-MIB DEFINITIONS ::= BEGIN IMPORTS transmission, MODULE-IDENTITY, Gauge32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; adsltcmib MODULE-IDENTITY LAST-UPDATED "9908190000Z" ORGANIZATION "IETF ADSL MIB Working Group" CONTACT-INFO " Gregory Bathrick AG Communication Systems A Subsidiary of Lucent Technologies 2500 W Utopia Rd. Phoenix, AZ 85027 USA Tel: +1 602-582-7679 Fax: +1 602-582-7697 E-mail: bathricg@agcs.com Faye Ly Copper Mountain Networks Norcal Office 2470 Embarcadero Way Palo Alto, CA 94303 Tel: +1 650-858-8500 Fax: +1 650-858-8085 E-Mail: faye@coppermountain.com Bathrick & Ly Standards Track [Page 17] RFC 2662 ADSL Line MIB August 1999 IETF ADSL MIB Working Group (adsl@xlist.agcs.com) " DESCRIPTION "The MIB module which provides a ADSL Line Coding Textual Convention to be used by ADSL Lines." -- Revision history REVISION "9908190000Z" -- 19 August 1999, midnight DESCRIPTION "Initial Version, published as RFC 2662" ::= { transmission 94 2 } -- adslMIB 2 AdslLineCodingType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax for the ADSL Line Code." SYNTAX INTEGER { other(1),-- none of the following dmt (2), -- Discrete MultiTone cap (3), -- Carrierless Amplitude & Phase modulation qam (4) -- Quadrature Amplitude Modulation } AdslPerfCurrDayCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A counter associated with interface performance measurements in a current 1-day (24 hour) measurement interval. The value of this counter starts at zero at the beginning of an interval and is increased when associated events occur, until the end of the 1-day interval. At that time the value of the counter is stored in the previous 1-day history interval, if available, and the current interval counter is restarted at zero. In the case where the agent has no valid data available for this interval the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist (for example, a noSuchName error for SNMPv1 and a noSuchInstance for SNMPv2 GET operation)." Bathrick & Ly Standards Track [Page 18] RFC 2662 ADSL Line MIB August 1999 SYNTAX Gauge32 AdslPerfPrevDayCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A counter associated with interface performance measurements during the most previous 1-day (24 hour) measurement interval. The value of this counter is equal to the value of the current day counter at the end of its most recent interval. In the case where the agent has no valid data available for this interval the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist (for example, a noSuchName error for SNMPv1 and a noSuchInstance for SNMPv2 GET operation)." SYNTAX Gauge32 AdslPerfTimeElapsed ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, the agent will return the maximum value." SYNTAX Gauge32 END ADSL-LINE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, NOTIFICATION-TYPE, transmission, Unsigned32 FROM SNMPv2-SMI RowStatus, TruthValue, VariablePointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB PerfCurrentCount, PerfIntervalCount FROM PerfHist-TC-MIB Bathrick & Ly Standards Track [Page 19] RFC 2662 ADSL Line MIB August 1999 SnmpAdminString FROM SNMP-FRAMEWORK-MIB AdslPerfCurrDayCount, AdslPerfPrevDayCount, AdslPerfTimeElapsed, AdslLineCodingType FROM ADSL-TC-MIB ; adslMIB MODULE-IDENTITY LAST-UPDATED "9908190000Z" ORGANIZATION "IETF ADSL MIB Working Group" CONTACT-INFO " Gregory Bathrick AG Communication Systems A Subsidiary of Lucent Technologies 2500 W Utopia Rd. Phoenix, AZ 85027 USA Tel: +1 602-582-7679 Fax: +1 602-582-7697 E-mail: bathricg@agcs.com Faye Ly Copper Mountain Networks Norcal Office 2470 Embarcadero Way Palo Alto, CA 94303 Tel: +1 650-858-8500 Fax: +1 650-858-8085 E-Mail: faye@coppermountain.com (ADSL Forum input only) John Burgess Predictive Systems, Inc. 25A Vreeland Rd. Florham Park, NJ 07932 USA Tel: +1 973-301-5610 Fax: +1 973-301-5699 E-mail: jtburgess@predictive.com IETF ADSL MIB Working Group (adsl@xlist.agcs.com) " DESCRIPTION "The MIB module defining objects for the management of a pair of ADSL modems at each end of the ADSL line. Each such line has Bathrick & Ly Standards Track [Page 20] RFC 2662 ADSL Line MIB August 1999 an entry in an ifTable which may include multiple modem lines. An agent may reside at either end of the ADSL line however the MIB is designed to require no management communication between them beyond that inherent in the low-level ADSL line protocol. The agent may monitor and control this protocol for its needs. ADSL lines may support optional Fast or Interleaved channels. If these are supported, additional entries corresponding to the supported channels must be created in the ifTable. Thus an ADSL line that supports both channels will have three entries in the ifTable, one for each physical, fast, and interleaved, whose ifType values are equal to adsl(94), fast(125), and interleaved(124), respectively. The ifStackTable is used to represent the relationship between the entries. Naming Conventions: Atuc -- (ATUC) modem at near (Central) end of line Atur -- (ATUR) modem at Remote end of line Curr -- Current Prev -- Previous Atn -- Attenuation ES -- Errored Second. LCS -- Line Code Specific Lof -- Loss of Frame Lol -- Loss of Link Los -- Loss of Signal Lpr -- Loss of Power xxxs-- interval of Seconds in which xxx occurs (e.g., xxx=Lof, Los, Lpr) Max -- Maximum Mgn -- Margin Min -- Minimum Psd -- Power Spectral Density Snr -- Signal to Noise Ratio Tx -- Transmit Blks-- Blocks, a data unit, see adslAtuXChanCrcBlockLength " -- Revision history REVISION "9908190000Z" -- 19 August 1999, midnight DESCRIPTION "Initial Version, published as RFC 2662" ::= { transmission 94 } adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 } adslMibObjects OBJECT IDENTIFIER ::= { adslLineMib 1 } Bathrick & Ly Standards Track [Page 21] RFC 2662 ADSL Line MIB August 1999 -- objects adslLineTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslLineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes common attributes describing both ends of the line. It is required for all ADSL physical interfaces. ADSL physical interfaces are those ifEntries where ifType is equal to adsl(94)." ::= { adslMibObjects 1 } adslLineEntry OBJECT-TYPE SYNTAX AdslLineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in adslLineTable." INDEX { ifIndex } ::= { adslLineTable 1 } AdslLineEntry ::= SEQUENCE { adslLineCoding AdslLineCodingType, adslLineType INTEGER, adslLineSpecific VariablePointer, adslLineConfProfile SnmpAdminString, adslLineAlarmConfProfile SnmpAdminString } adslLineCoding OBJECT-TYPE SYNTAX AdslLineCodingType MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the ADSL coding type used on this line." ::= { adslLineEntry 1 } adslLineType OBJECT-TYPE SYNTAX INTEGER { noChannel (1), -- no channels exist fastOnly (2), -- fast channel exists only interleavedOnly (3), -- interleaved channel exists -- only fastOrInterleaved (4),-- either fast or interleaved -- channels can exist, but -- only one at any time fastAndInterleaved (5)-- both fast or interleaved Bathrick & Ly Standards Track [Page 22] RFC 2662 ADSL Line MIB August 1999 -- channels exist } MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the type of ADSL physical line entity that exists, by defining whether and how the line is channelized. If the line is channelized, the value will be other than noChannel(1). This object defines which channel type(s) are supported. In the case that the line is channelized, the manager can use the ifStackTable to determine the ifIndex for the associated channel(s)." ::= { adslLineEntry 2 } adslLineSpecific OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-only STATUS current DESCRIPTION "OID instance in vendor-specific MIB. The Instance may be used to determine shelf/slot/port of the ATUC interface in a DSLAM." ::= { adslLineEntry 3 } adslLineConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL Line Configuration Profile Table, (adslLineConfProfileTable), which applies for this ADSL line, and channels if applicable. For `dynamic' mode, in the case which the configuration profile has not been set, the value will be set to `DEFVAL'. If the implementator of this MIB has chosen not to implement `dynamic assignment' of profiles, this object's MIN-ACCESS is read-only." ::= { adslLineEntry 4 } adslLineAlarmConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS read-write Bathrick & Ly Standards Track [Page 23] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL Line Alarm Configuration Profile Table, (adslLineAlarmConfProfileTable), which applies to this ADSL line, and channels if applicable. For `dynamic' mode, in the case which the alarm profile has not been set, the value will be set to `DEFVAL'. If the implementator of this MIB has chosen not to implement `dynamic assignment' of profiles, this object's MIN-ACCESS is read-only." ::= { adslLineEntry 5 } adslAtucPhysTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUC. Each row contains the Physical Layer Parameters table for that ATUC. ADSL physical interfaces are those ifEntries where ifType is equal to adsl(94)." ::= { adslMibObjects 2 } adslAtucPhysEntry OBJECT-TYPE SYNTAX AdslAtucPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAtucPhysTable." INDEX { ifIndex } ::= { adslAtucPhysTable 1 } AdslAtucPhysEntry ::= SEQUENCE { adslAtucInvSerialNumber SnmpAdminString, adslAtucInvVendorID SnmpAdminString, adslAtucInvVersionNumber SnmpAdminString, adslAtucCurrSnrMgn INTEGER, adslAtucCurrAtn Gauge32, adslAtucCurrStatus BITS, adslAtucCurrOutputPwr INTEGER, adslAtucCurrAttainableRate Gauge32 } -- inventory group Bathrick & Ly Standards Track [Page 24] RFC 2662 ADSL Line MIB August 1999 -- -- These items should describe the lowest level identifiable -- component, be it a stand-alone modem, a card in a rack, -- a child-board, etc. -- adslAtucInvSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific string that identifies the vendor equipment." ::= { adslAtucPhysEntry 1 } adslAtucInvVendorID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor ID code is a copy of the binary vendor identification field defined by the PHY[10] and expressed as readable characters." REFERENCE "ANSI T1.413[10]" ::= { adslAtucPhysEntry 2 } adslAtucInvVersionNumber OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific version number sent by this ATU as part of the initialization messages. It is a copy of the binary version number field defined by the PHY[10] and expressed as readable characters." REFERENCE "ANSI T1.413[10]" ::= { adslAtucPhysEntry 3 } -- current status group -- adslAtucCurrSnrMgn OBJECT-TYPE SYNTAX INTEGER (-640..640) UNITS "tenth dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Noise Margin as seen by this ATU with respect to its received signal in tenth dB." Bathrick & Ly Standards Track [Page 25] RFC 2662 ADSL Line MIB August 1999 ::= { adslAtucPhysEntry 4 } adslAtucCurrAtn OBJECT-TYPE SYNTAX Gauge32(0..630) UNITS "tenth dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured difference in the total power transmitted by the peer ATU and the total power received by this ATU." ::= { adslAtucPhysEntry 5 } adslAtucCurrStatus OBJECT-TYPE SYNTAX BITS { noDefect(0), lossOfFraming(1), lossOfSignal(2), lossOfPower(3), lossOfSignalQuality(4), lossOfLink(5), dataInitFailure(6), configInitFailure(7), protocolInitFailure(8), noPeerAtuPresent(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state of the ATUC line. This is a bit-map of possible conditions. The various bit positions are: 0 noDefect There no defects on the line 1 lossOfFraming ATUC failure due to not receiving valid frame. 2 lossOfSignal ATUC failure due to not receiving signal. 3 lossOfPower ATUC failure due to loss of power. Note: the Agent may still function. 4 lossOfSignalQuality Loss of Signal Quality is declared when the Noise Margin falls below the Minimum Noise Bathrick & Ly Standards Track [Page 26] RFC 2662 ADSL Line MIB August 1999 Margin, or the bit-error-rate exceeds 10^-7. 5 lossOfLink ATUC failure due to inability to link with ATUR. 6 dataInitFailure ATUC failure during initialization due to bit errors corrupting startup exchange data. 7 configInitFailure ATUC failure during initialization due to peer ATU not able to support requested configuration 8 protocolInitFailure ATUC failure during initialization due to incompatible protocol used by the peer ATU. 9 noPeerAtuPresent ATUC failure during initialization due to no activation sequence detected from peer ATU. This is intended to supplement ifOperStatus." ::= { adslAtucPhysEntry 6 } adslAtucCurrOutputPwr OBJECT-TYPE SYNTAX INTEGER (-310..310) UNITS "tenth dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured total output power transmitted by this ATU. This is the measurement that was reported during the last activation sequence." ::= { adslAtucPhysEntry 7 } adslAtucCurrAttainableRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the maximum currently attainable data rate by the ATU. This value will be equal or greater than Bathrick & Ly Standards Track [Page 27] RFC 2662 ADSL Line MIB August 1999 the current line rate." ::= { adslAtucPhysEntry 8 } adslAturPhysTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUR Each row contains the Physical Layer Parameters table for that ATUR. ADSL physical interfaces are those ifEntries where ifType is equal to adsl(94)." ::= { adslMibObjects 3 } adslAturPhysEntry OBJECT-TYPE SYNTAX AdslAturPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAturPhysTable." INDEX { ifIndex } ::= { adslAturPhysTable 1 } AdslAturPhysEntry ::= SEQUENCE { adslAturInvSerialNumber SnmpAdminString, adslAturInvVendorID SnmpAdminString, adslAturInvVersionNumber SnmpAdminString, adslAturCurrSnrMgn INTEGER, adslAturCurrAtn Gauge32, adslAturCurrStatus BITS, adslAturCurrOutputPwr INTEGER, adslAturCurrAttainableRate Gauge32 } -- inventory group -- adslAturInvSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific string that identifies the vendor equipment." ::= { adslAturPhysEntry 1 } adslAturInvVendorID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only Bathrick & Ly Standards Track [Page 28] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "The vendor ID code is a copy of the binary vendor identification field defined by the PHY[10] and expressed as readable characters." REFERENCE "ANSI T1.413" ::= { adslAturPhysEntry 2 } adslAturInvVersionNumber OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific version number sent by this ATU as part of the initialization messages. It is a copy of the binary version number field defined by the PHY[10] and expressed as readable characters." REFERENCE "ANSI T1.413" ::= { adslAturPhysEntry 3 } -- current status group -- adslAturCurrSnrMgn OBJECT-TYPE SYNTAX INTEGER (-640..640) UNITS "tenth dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Noise Margin as seen by this ATU with respect to its received signal in tenth dB." ::= { adslAturPhysEntry 4 } adslAturCurrAtn OBJECT-TYPE SYNTAX Gauge32(0..630) UNITS "tenth dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured difference in the total power transmitted by the peer ATU and the total power received by this ATU." ::= { adslAturPhysEntry 5 } adslAturCurrStatus OBJECT-TYPE SYNTAX BITS { noDefect(0), lossOfFraming(1), lossOfSignal(2), lossOfPower(3), Bathrick & Ly Standards Track [Page 29] RFC 2662 ADSL Line MIB August 1999 lossOfSignalQuality(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state of the ATUR line. This is a bit-map of possible conditions. Due to the isolation of the ATUR when line problems occur, many state conditions like loss of power, loss of quality signal, and initialization errors, can not be determined. While trouble shooting ATUR, also use object, adslAtucCurrStatus. The various bit positions are: 0 noDefect There no defects on the line 1 lossOfFraming ATUR failure due to not receiving valid frame 2 lossOfSignal ATUR failure due to not receiving signal 3 lossOfPower ATUR failure due to loss of power 4 lossOfSignalQuality Loss of Signal Quality is declared when the Noise Margin falls below the Minimum Noise Margin, or the bit-error-rate exceeds 10^-7. This is intended to supplement ifOperStatus." ::= { adslAturPhysEntry 6 } adslAturCurrOutputPwr OBJECT-TYPE SYNTAX INTEGER (-310..310) UNITS "tenth dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured total output power transmitted by this ATU. This is the measurement that was reported during the last activation sequence." ::= { adslAturPhysEntry 7 } adslAturCurrAttainableRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bps" MAX-ACCESS read-only Bathrick & Ly Standards Track [Page 30] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "Indicates the maximum currently attainable data rate by the ATU. This value will be equal or greater than the current line rate." ::= { adslAturPhysEntry 8 } adslAtucChanTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUC channel. ADSL channel interfaces are those ifEntries where ifType is equal to adslInterleave(124) or adslFast(125)." ::= { adslMibObjects 4 } adslAtucChanEntry OBJECT-TYPE SYNTAX AdslAtucChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAtucChanTable." INDEX { ifIndex } ::= { adslAtucChanTable 1 } AdslAtucChanEntry ::= SEQUENCE { adslAtucChanInterleaveDelay Gauge32, adslAtucChanCurrTxRate Gauge32, adslAtucChanPrevTxRate Gauge32, adslAtucChanCrcBlockLength Gauge32 } -- current group -- adslAtucChanInterleaveDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "milli-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Interleave Delay for this channel. Interleave delay applies only to the interleave channel and defines the mapping (relative spacing) between subsequent input bytes at the interleaver input and their placement Bathrick & Ly Standards Track [Page 31] RFC 2662 ADSL Line MIB August 1999 in the bit stream at the interleaver output. Larger numbers provide greater separation between consecutive input bytes in the output bit stream allowing for improved impulse noise immunity at the expense of payload latency. In the case where the ifType is Fast(125), use noSuchObject." ::= { adslAtucChanEntry 1 } adslAtucChanCurrTxRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual transmit rate on this channel." ::= { adslAtucChanEntry 2 } adslAtucChanPrevTxRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "The rate at the time of the last adslAtucRateChangeTrap event. It is also set at initialization to prevent a trap being sent. Rate changes less than adslAtucThresh(*)RateDown or less than adslAtucThresh(*)RateUp will not cause a trap or cause this object to change. (*) == Fast or Interleave. See AdslLineAlarmConfProfileEntry." ::= { adslAtucChanEntry 3 } adslAtucChanCrcBlockLength OBJECT-TYPE SYNTAX Gauge32 UNITS "byte" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the length of the channel data-block on which the CRC operates. Refer to Line Code Specific MIBs, [11] and [12] for more information." ::= { adslAtucChanEntry 4 } Bathrick & Ly Standards Track [Page 32] RFC 2662 ADSL Line MIB August 1999 adslAturChanTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUR channel. ADSL channel interfaces are those ifEntries where ifType is equal to adslInterleave(124) or adslFast(125)." ::= { adslMibObjects 5 } adslAturChanEntry OBJECT-TYPE SYNTAX AdslAturChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAturChanTable." INDEX { ifIndex } ::= { adslAturChanTable 1 } AdslAturChanEntry ::= SEQUENCE { adslAturChanInterleaveDelay Gauge32, adslAturChanCurrTxRate Gauge32, adslAturChanPrevTxRate Gauge32, adslAturChanCrcBlockLength Gauge32 } -- current group -- adslAturChanInterleaveDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "milli-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Interleave Delay for this channel. Interleave delay applies only to the interleave channel and defines the mapping (relative spacing) between subsequent input bytes at the interleaver input and their placement in the bit stream at the interleaver output. Larger numbers provide greater separation between consecutive input bytes in the output bit stream allowing for improved impulse noise immunity at the expense of payload latency. In the case where the ifType is Fast(125), use Bathrick & Ly Standards Track [Page 33] RFC 2662 ADSL Line MIB August 1999 noSuchObject." ::= { adslAturChanEntry 1 } adslAturChanCurrTxRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual transmit rate on this channel." ::= { adslAturChanEntry 2 } adslAturChanPrevTxRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "The rate at the time of the last adslAturRateChangeTrap event. It is also set at initialization to prevent a trap being sent. Rate changes less than adslAturThresh(*)RateDown or less than adslAturThresh(*)RateUp will not cause a trap or cause this object to change. (*) == Fast or Interleave. See AdslLineAlarmConfProfileEntry." ::= { adslAturChanEntry 3 } adslAturChanCrcBlockLength OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the length of the channel data-block on which the CRC operates. Refer to Line Code Specific MIBs, [11] and [12] for more information." ::= { adslAturChanEntry 4 } adslAtucPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUC. ADSL physical interfaces are those ifEntries where ifType is equal to adsl(94)." ::= { adslMibObjects 6 } Bathrick & Ly Standards Track [Page 34] RFC 2662 ADSL Line MIB August 1999 adslAtucPerfDataEntry OBJECT-TYPE SYNTAX AdslAtucPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in adslAtucPerfDataTable." INDEX { ifIndex } ::= { adslAtucPerfDataTable 1 } AdslAtucPerfDataEntry ::= SEQUENCE { adslAtucPerfLofs Counter32, adslAtucPerfLoss Counter32, adslAtucPerfLols Counter32, adslAtucPerfLprs Counter32, adslAtucPerfESs Counter32, adslAtucPerfInits Counter32, adslAtucPerfValidIntervals INTEGER, adslAtucPerfInvalidIntervals INTEGER, adslAtucPerfCurr15MinTimeElapsed AdslPerfTimeElapsed, adslAtucPerfCurr15MinLofs PerfCurrentCount, adslAtucPerfCurr15MinLoss PerfCurrentCount, adslAtucPerfCurr15MinLols PerfCurrentCount, adslAtucPerfCurr15MinLprs PerfCurrentCount, adslAtucPerfCurr15MinESs PerfCurrentCount, adslAtucPerfCurr15MinInits PerfCurrentCount, adslAtucPerfCurr1DayTimeElapsed AdslPerfTimeElapsed, adslAtucPerfCurr1DayLofs AdslPerfCurrDayCount, adslAtucPerfCurr1DayLoss AdslPerfCurrDayCount, adslAtucPerfCurr1DayLols AdslPerfCurrDayCount, adslAtucPerfCurr1DayLprs AdslPerfCurrDayCount, adslAtucPerfCurr1DayESs AdslPerfCurrDayCount, adslAtucPerfCurr1DayInits AdslPerfCurrDayCount, adslAtucPerfPrev1DayMoniSecs INTEGER, adslAtucPerfPrev1DayLofs AdslPerfPrevDayCount, adslAtucPerfPrev1DayLoss AdslPerfPrevDayCount, adslAtucPerfPrev1DayLols AdslPerfPrevDayCount, adslAtucPerfPrev1DayLprs AdslPerfPrevDayCount, adslAtucPerfPrev1DayESs AdslPerfPrevDayCount, adslAtucPerfPrev1DayInits AdslPerfPrevDayCount } -- Event Counters -- -- Also see adslAtucIntervalTable for 15 minute interval -- elapsed counters. -- adslAtucPerfLofs OBJECT-TYPE SYNTAX Counter32 Bathrick & Ly Standards Track [Page 35] RFC 2662 ADSL Line MIB August 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Loss of Framing failures since agent reset." ::= { adslAtucPerfDataEntry 1 } adslAtucPerfLoss OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Loss of Signal failures since agent reset." ::= { adslAtucPerfDataEntry 2 } adslAtucPerfLols OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Loss of Link failures since agent reset." ::= { adslAtucPerfDataEntry 3 } adslAtucPerfLprs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Loss of Power failures since agent reset." ::= { adslAtucPerfDataEntry 4 } adslAtucPerfESs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Errored Seconds since agent reset. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAtucPerfDataEntry 5 } adslAtucPerfInits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Bathrick & Ly Standards Track [Page 36] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "Count of the line initialization attempts since agent reset. Includes both successful and failed attempts." ::= { adslAtucPerfDataEntry 6 } -- general 15 min interval information -- adslAtucPerfValidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous 15-minute intervals in the interval table for which data was collected. Given that is the maximum # of intervals supported. The value will be unless the measurement was (re-)started within the last (*15) minutes, in which case the value will be the number of complete 15 minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy) it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { adslAtucPerfDataEntry 7 } adslAtucPerfInvalidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to the value of adslAtucPerfValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { adslAtucPerfDataEntry 8 } -- 15 min current performance group -- adslAtucPerfCurr15MinTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..899) UNITS "seconds" MAX-ACCESS read-only Bathrick & Ly Standards Track [Page 37] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { adslAtucPerfDataEntry 9 } adslAtucPerfCurr15MinLofs OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the current 15 minute interval when there was Loss of Framing." ::= { adslAtucPerfDataEntry 10 } adslAtucPerfCurr15MinLoss OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the current 15 minute interval when there was Loss of Signal." ::= { adslAtucPerfDataEntry 11 } adslAtucPerfCurr15MinLols OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the current 15 minute interval when there was Loss of Link." ::= { adslAtucPerfDataEntry 12 } adslAtucPerfCurr15MinLprs OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the current 15 minute interval when there was Loss of Power." ::= { adslAtucPerfDataEntry 13 } adslAtucPerfCurr15MinESs OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" Bathrick & Ly Standards Track [Page 38] RFC 2662 ADSL Line MIB August 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds in the current 15 minute interval. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAtucPerfDataEntry 14 } adslAtucPerfCurr15MinInits OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts in the current 15 minute interval. Includes both successful and failed attempts." ::= { adslAtucPerfDataEntry 15 } -- 1-day current and previous performance group -- adslAtucPerfCurr1DayTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..86399) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::= { adslAtucPerfDataEntry 16 } adslAtucPerfCurr1DayLofs OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of seconds when there was Loss of Framing during the current day as measured by adslAtucPerfCurr1DayTimeElapsed." ::= { adslAtucPerfDataEntry 17 } adslAtucPerfCurr1DayLoss OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Bathrick & Ly Standards Track [Page 39] RFC 2662 ADSL Line MIB August 1999 "Count of the number of seconds when there was Loss of Signal during the current day as measured by adslAtucPerfCurr1DayTimeElapsed." ::= { adslAtucPerfDataEntry 18 } adslAtucPerfCurr1DayLols OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of seconds when there was Loss of Link during the current day as measured by adslAtucPerfCurr1DayTimeElapsed." ::= { adslAtucPerfDataEntry 19 } adslAtucPerfCurr1DayLprs OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of seconds when there was Loss of Power during the current day as measured by adslAtucPerfCurr1DayTimeElapsed." ::= { adslAtucPerfDataEntry 20 } adslAtucPerfCurr1DayESs OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds during the current day as measured by adslAtucPerfCurr1DayTimeElapsed. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAtucPerfDataEntry 21 } adslAtucPerfCurr1DayInits OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts in the day as measured by adslAtucPerfCurr1DayTimeElapsed. Includes both successful and failed attempts." Bathrick & Ly Standards Track [Page 40] RFC 2662 ADSL Line MIB August 1999 ::= { adslAtucPerfDataEntry 22 } adslAtucPerfPrev1DayMoniSecs OBJECT-TYPE SYNTAX INTEGER(0..86400) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the previous 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::= { adslAtucPerfDataEntry 23 } adslAtucPerfPrev1DayLofs OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Framing within the most recent previous 1-day period." ::= { adslAtucPerfDataEntry 24 } adslAtucPerfPrev1DayLoss OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Signal within the most recent previous 1-day period." ::= { adslAtucPerfDataEntry 25 } adslAtucPerfPrev1DayLols OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Link within the most recent previous 1-day period." ::= { adslAtucPerfDataEntry 26 } Bathrick & Ly Standards Track [Page 41] RFC 2662 ADSL Line MIB August 1999 adslAtucPerfPrev1DayLprs OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Power within the most recent previous 1-day period." ::= { adslAtucPerfDataEntry 27 } adslAtucPerfPrev1DayESs OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds within the most recent previous 1-day period. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAtucPerfDataEntry 28 } adslAtucPerfPrev1DayInits OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts in the most recent previous 1-day period. Includes both successful and failed attempts." ::= { adslAtucPerfDataEntry 29 } adslAturPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUR. ADSL physical interfaces are those ifEntries where ifType is equal to adsl(94)." ::= { adslMibObjects 7 } adslAturPerfDataEntry OBJECT-TYPE SYNTAX AdslAturPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in adslAturPerfDataTable." Bathrick & Ly Standards Track [Page 42] RFC 2662 ADSL Line MIB August 1999 INDEX { ifIndex } ::= { adslAturPerfDataTable 1 } AdslAturPerfDataEntry ::= SEQUENCE { adslAturPerfLofs Counter32, adslAturPerfLoss Counter32, adslAturPerfLprs Counter32, adslAturPerfESs Counter32, adslAturPerfValidIntervals INTEGER, adslAturPerfInvalidIntervals INTEGER, adslAturPerfCurr15MinTimeElapsed AdslPerfTimeElapsed, adslAturPerfCurr15MinLofs PerfCurrentCount, adslAturPerfCurr15MinLoss PerfCurrentCount, adslAturPerfCurr15MinLprs PerfCurrentCount, adslAturPerfCurr15MinESs PerfCurrentCount, adslAturPerfCurr1DayTimeElapsed AdslPerfTimeElapsed, adslAturPerfCurr1DayLofs AdslPerfCurrDayCount, adslAturPerfCurr1DayLoss AdslPerfCurrDayCount, adslAturPerfCurr1DayLprs AdslPerfCurrDayCount, adslAturPerfCurr1DayESs AdslPerfCurrDayCount, adslAturPerfPrev1DayMoniSecs INTEGER, adslAturPerfPrev1DayLofs AdslPerfPrevDayCount, adslAturPerfPrev1DayLoss AdslPerfPrevDayCount, adslAturPerfPrev1DayLprs AdslPerfPrevDayCount, adslAturPerfPrev1DayESs AdslPerfPrevDayCount } -- Event (Raw) Counters -- -- Also see adslAturIntervalTable for 15 minute interval -- elapsed counters. -- adslAturPerfLofs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Loss of Framing failures since agent reset." ::= { adslAturPerfDataEntry 1 } adslAturPerfLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current Bathrick & Ly Standards Track [Page 43] RFC 2662 ADSL Line MIB August 1999 DESCRIPTION "Count of the number of Loss of Signal failures since agent reset." ::= { adslAturPerfDataEntry 2 } adslAturPerfLprs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Loss of Power failures since agent reset." ::= { adslAturPerfDataEntry 3 } adslAturPerfESs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of Errored Seconds since agent reset. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAturPerfDataEntry 4 } -- general 15 min interval information -- adslAturPerfValidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous 15-minute intervals in the interval table for which data was collected. Given that is the maximum # of intervals supported. The value will be unless the measurement was (re-)started within the last (*15) minutes, in which case the value will be the number of complete 15 minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy) it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { adslAturPerfDataEntry 5 } Bathrick & Ly Standards Track [Page 44] RFC 2662 ADSL Line MIB August 1999 adslAturPerfInvalidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to the value of adslAturPerfValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { adslAturPerfDataEntry 6 } -- 15 min current performance group -- adslAturPerfCurr15MinTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..899) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { adslAturPerfDataEntry 7 } adslAturPerfCurr15MinLofs OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the current 15 minute interval when there was Loss of Framing." ::= { adslAturPerfDataEntry 8 } adslAturPerfCurr15MinLoss OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the current 15 minute interval when there was Loss of Signal." ::= { adslAturPerfDataEntry 9 } adslAturPerfCurr15MinLprs OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only Bathrick & Ly Standards Track [Page 45] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "Count of seconds in the current 15 minute interval when there was Loss of Power." ::= { adslAturPerfDataEntry 10 } adslAturPerfCurr15MinESs OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds in the current 15 minute interval. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAturPerfDataEntry 11 } -- 1-day current and previous performance group -- adslAturPerfCurr1DayTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..86399) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::= { adslAturPerfDataEntry 12 } adslAturPerfCurr1DayLofs OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of seconds when there was Loss of Framing during the current day as measured by adslAturPerfCurr1DayTimeElapsed." ::= { adslAturPerfDataEntry 13 } adslAturPerfCurr1DayLoss OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Bathrick & Ly Standards Track [Page 46] RFC 2662 ADSL Line MIB August 1999 "Count of the number of seconds when there was Loss of Signal during the current day as measured by adslAturPerfCurr1DayTimeElapsed." ::= { adslAturPerfDataEntry 14 } adslAturPerfCurr1DayLprs OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of seconds when there was Loss of Power during the current day as measured by adslAturPerfCurr1DayTimeElapsed." ::= { adslAturPerfDataEntry 15 } adslAturPerfCurr1DayESs OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds during the current day as measured by adslAturPerfCurr1DayTimeElapsed. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAturPerfDataEntry 16 } adslAturPerfPrev1DayMoniSecs OBJECT-TYPE SYNTAX INTEGER(0..86400) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the previous 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::= { adslAturPerfDataEntry 17 } adslAturPerfPrev1DayLofs OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current Bathrick & Ly Standards Track [Page 47] RFC 2662 ADSL Line MIB August 1999 DESCRIPTION "Count of seconds in the interval when there was Loss of Framing within the most recent previous 1-day period." ::= { adslAturPerfDataEntry 18 } adslAturPerfPrev1DayLoss OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Signal within the most recent previous 1-day period." ::= { adslAturPerfDataEntry 19 } adslAturPerfPrev1DayLprs OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Power within the most recent previous 1-day period." ::= { adslAturPerfDataEntry 20 } adslAturPerfPrev1DayESs OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds within the most recent previous 1-day period. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAturPerfDataEntry 21 } adslAtucIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUC performance data collection interval. ADSL physical interfaces are Bathrick & Ly Standards Track [Page 48] RFC 2662 ADSL Line MIB August 1999 those ifEntries where ifType is equal to adsl(94)." ::= { adslMibObjects 8 } adslAtucIntervalEntry OBJECT-TYPE SYNTAX AdslAtucIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAtucIntervalTable." INDEX { ifIndex, adslAtucIntervalNumber } ::= { adslAtucIntervalTable 1 } AdslAtucIntervalEntry ::= SEQUENCE { adslAtucIntervalNumber INTEGER, adslAtucIntervalLofs PerfIntervalCount, adslAtucIntervalLoss PerfIntervalCount, adslAtucIntervalLols PerfIntervalCount, adslAtucIntervalLprs PerfIntervalCount, adslAtucIntervalESs PerfIntervalCount, adslAtucIntervalInits PerfIntervalCount, adslAtucIntervalValidData TruthValue } adslAtucIntervalNumber OBJECT-TYPE SYNTAX INTEGER(1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number 1 is the the most recent previous interval; interval 96 is 24 hours ago. Intervals 2..96 are optional." ::= { adslAtucIntervalEntry 1 } adslAtucIntervalLofs OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Framing." ::= { adslAtucIntervalEntry 2 } adslAtucIntervalLoss OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only Bathrick & Ly Standards Track [Page 49] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Signal." ::= { adslAtucIntervalEntry 3 } adslAtucIntervalLols OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Link." ::= { adslAtucIntervalEntry 4 } adslAtucIntervalLprs OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Power." ::= { adslAtucIntervalEntry 5 } adslAtucIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds in the interval. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAtucIntervalEntry 6 } adslAtucIntervalInits OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts during the interval. Includes both successful and failed attempts." ::= { adslAtucIntervalEntry 7 } Bathrick & Ly Standards Track [Page 50] RFC 2662 ADSL Line MIB August 1999 adslAtucIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adslAtucIntervalEntry 8 } adslAturIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUR performance data collection interval. ADSL physical interfaces are those ifEntries where ifType is equal to adsl(94)." ::= { adslMibObjects 9 } adslAturIntervalEntry OBJECT-TYPE SYNTAX AdslAturIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAturIntervalTable." INDEX { ifIndex, adslAturIntervalNumber } ::= { adslAturIntervalTable 1 } AdslAturIntervalEntry ::= SEQUENCE { adslAturIntervalNumber INTEGER, adslAturIntervalLofs PerfIntervalCount, adslAturIntervalLoss PerfIntervalCount, adslAturIntervalLprs PerfIntervalCount, adslAturIntervalESs PerfIntervalCount, adslAturIntervalValidData TruthValue } adslAturIntervalNumber OBJECT-TYPE SYNTAX INTEGER(1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number 1 is the the most recent previous interval; interval 96 is 24 hours ago. Intervals 2..96 are optional." ::= { adslAturIntervalEntry 1 } Bathrick & Ly Standards Track [Page 51] RFC 2662 ADSL Line MIB August 1999 adslAturIntervalLofs OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Framing." ::= { adslAturIntervalEntry 2 } adslAturIntervalLoss OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Signal." ::= { adslAturIntervalEntry 3 } adslAturIntervalLprs OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Power." ::= { adslAturIntervalEntry 4 } adslAturIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds in the interval. The errored second parameter is a count of one-second intervals containing one or more crc anomalies, or one or more los or sef defects." ::= { adslAturIntervalEntry 5 } adslAturIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this Bathrick & Ly Standards Track [Page 52] RFC 2662 ADSL Line MIB August 1999 interval is valid." ::= { adslAturIntervalEntry 6 } adslAtucChanPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUC channel. ADSL channel interfaces are those ifEntries where ifType is equal to adslInterleave(124) or adslFast(125)." ::= { adslMibObjects 10 } adslAtucChanPerfDataEntry OBJECT-TYPE SYNTAX AdslAtucChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in adslAtucChanPerfDataTable." INDEX { ifIndex } ::= { adslAtucChanPerfDataTable 1 } AdslAtucChanPerfDataEntry ::= SEQUENCE { adslAtucChanReceivedBlks Counter32, adslAtucChanTransmittedBlks Counter32, adslAtucChanCorrectedBlks Counter32, adslAtucChanUncorrectBlks Counter32, adslAtucChanPerfValidIntervals INTEGER, adslAtucChanPerfInvalidIntervals INTEGER, adslAtucChanPerfCurr15MinTimeElapsed AdslPerfTimeElapsed, adslAtucChanPerfCurr15MinReceivedBlks PerfCurrentCount, adslAtucChanPerfCurr15MinTransmittedBlks PerfCurrentCount, adslAtucChanPerfCurr15MinCorrectedBlks PerfCurrentCount, adslAtucChanPerfCurr15MinUncorrectBlks PerfCurrentCount, adslAtucChanPerfCurr1DayTimeElapsed AdslPerfTimeElapsed, adslAtucChanPerfCurr1DayReceivedBlks AdslPerfCurrDayCount, adslAtucChanPerfCurr1DayTransmittedBlks AdslPerfCurrDayCount, adslAtucChanPerfCurr1DayCorrectedBlks AdslPerfCurrDayCount, adslAtucChanPerfCurr1DayUncorrectBlks AdslPerfCurrDayCount, adslAtucChanPerfPrev1DayMoniSecs INTEGER, adslAtucChanPerfPrev1DayReceivedBlks AdslPerfPrevDayCount, adslAtucChanPerfPrev1DayTransmittedBlks AdslPerfPrevDayCount, adslAtucChanPerfPrev1DayCorrectedBlks AdslPerfPrevDayCount, adslAtucChanPerfPrev1DayUncorrectBlks AdslPerfPrevDayCount } -- performance group Bathrick & Ly Standards Track [Page 53] RFC 2662 ADSL Line MIB August 1999 -- -- Note: block is intended to be the length of the channel -- data-block on which the CRC operates. See -- adslAtucChanCrcBlockLength for more information. -- adslAtucChanReceivedBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel since agent reset." ::= { adslAtucChanPerfDataEntry 1 } adslAtucChanTransmittedBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel since agent reset." ::= { adslAtucChanPerfDataEntry 2 } adslAtucChanCorrectedBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected since agent reset. These blocks are passed on as good data." ::= { adslAtucChanPerfDataEntry 3 } adslAtucChanUncorrectBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors since agent reset." ::= { adslAtucChanPerfDataEntry 4 } -- general 15 min interval information -- adslAtucChanPerfValidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current Bathrick & Ly Standards Track [Page 54] RFC 2662 ADSL Line MIB August 1999 DESCRIPTION "The number of previous 15-minute intervals in the interval table for which data was collected. Given that is the maximum # of intervals supported. The value will be unless the measurement was (re-)started within the last (*15) minutes, in which case the value will be the number of complete 15 minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy) it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { adslAtucChanPerfDataEntry 5 } adslAtucChanPerfInvalidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to the value of adslAtucChanPerfValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { adslAtucChanPerfDataEntry 6 } -- 15 min current performance group -- adslAtucChanPerfCurr15MinTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..899) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { adslAtucChanPerfDataEntry 7 } adslAtucChanPerfCurr15MinReceivedBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel within the current 15 minute interval." ::= { adslAtucChanPerfDataEntry 8 } Bathrick & Ly Standards Track [Page 55] RFC 2662 ADSL Line MIB August 1999 adslAtucChanPerfCurr15MinTransmittedBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel within the current 15 minute interval." ::= { adslAtucChanPerfDataEntry 9 } adslAtucChanPerfCurr15MinCorrectedBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected on this channel within the current 15 minute interval." ::= { adslAtucChanPerfDataEntry 10 } adslAtucChanPerfCurr15MinUncorrectBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel within the current 15 minute interval." ::= { adslAtucChanPerfDataEntry 11 } -- 1-day current and previous performance group -- adslAtucChanPerfCurr1DayTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..86399) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::= { adslAtucChanPerfDataEntry 12 } adslAtucChanPerfCurr1DayReceivedBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel during the current day as measured by Bathrick & Ly Standards Track [Page 56] RFC 2662 ADSL Line MIB August 1999 adslAtucChanPerfCurr1DayTimeElapsed." ::= { adslAtucChanPerfDataEntry 13 } adslAtucChanPerfCurr1DayTransmittedBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel during the current day as measured by adslAtucChanPerfCurr1DayTimeElapsed." ::= { adslAtucChanPerfDataEntry 14 } adslAtucChanPerfCurr1DayCorrectedBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected on this channel during the current day as measured by adslAtucChanPerfCurr1DayTimeElapsed." ::= { adslAtucChanPerfDataEntry 15 } adslAtucChanPerfCurr1DayUncorrectBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel during the current day as measured by adslAtucChanPerfCurr1DayTimeElapsed." ::= { adslAtucChanPerfDataEntry 16 } adslAtucChanPerfPrev1DayMoniSecs OBJECT-TYPE SYNTAX INTEGER(0..86400) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the previous 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::= { adslAtucChanPerfDataEntry 17 } adslAtucChanPerfPrev1DayReceivedBlks OBJECT-TYPE Bathrick & Ly Standards Track [Page 57] RFC 2662 ADSL Line MIB August 1999 SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel within the most recent previous 1-day period." ::= { adslAtucChanPerfDataEntry 18 } adslAtucChanPerfPrev1DayTransmittedBlks OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel within the most recent previous 1-day period." ::= { adslAtucChanPerfDataEntry 19 } adslAtucChanPerfPrev1DayCorrectedBlks OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected on this channel within the most recent previous 1-day period." ::= { adslAtucChanPerfDataEntry 20 } adslAtucChanPerfPrev1DayUncorrectBlks OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel within the most recent previous 1-day period." ::= { adslAtucChanPerfDataEntry 21 } adslAturChanPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUR channel. ADSL channel interfaces are those ifEntries where ifType is equal to adslInterleave(124) or adslFast(125)." Bathrick & Ly Standards Track [Page 58] RFC 2662 ADSL Line MIB August 1999 ::= { adslMibObjects 11 } adslAturChanPerfDataEntry OBJECT-TYPE SYNTAX AdslAturChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in adslAturChanPerfDataTable." INDEX { ifIndex } ::= { adslAturChanPerfDataTable 1 } AdslAturChanPerfDataEntry ::= SEQUENCE { adslAturChanReceivedBlks Counter32, adslAturChanTransmittedBlks Counter32, adslAturChanCorrectedBlks Counter32, adslAturChanUncorrectBlks Counter32, adslAturChanPerfValidIntervals INTEGER, adslAturChanPerfInvalidIntervals INTEGER, adslAturChanPerfCurr15MinTimeElapsed AdslPerfTimeElapsed, adslAturChanPerfCurr15MinReceivedBlks PerfCurrentCount, adslAturChanPerfCurr15MinTransmittedBlks PerfCurrentCount, adslAturChanPerfCurr15MinCorrectedBlks PerfCurrentCount, adslAturChanPerfCurr15MinUncorrectBlks PerfCurrentCount, adslAturChanPerfCurr1DayTimeElapsed AdslPerfTimeElapsed, adslAturChanPerfCurr1DayReceivedBlks AdslPerfCurrDayCount, adslAturChanPerfCurr1DayTransmittedBlks AdslPerfCurrDayCount, adslAturChanPerfCurr1DayCorrectedBlks AdslPerfCurrDayCount, adslAturChanPerfCurr1DayUncorrectBlks AdslPerfCurrDayCount, adslAturChanPerfPrev1DayMoniSecs INTEGER, adslAturChanPerfPrev1DayReceivedBlks AdslPerfPrevDayCount, adslAturChanPerfPrev1DayTransmittedBlks AdslPerfPrevDayCount, adslAturChanPerfPrev1DayCorrectedBlks AdslPerfPrevDayCount, adslAturChanPerfPrev1DayUncorrectBlks AdslPerfPrevDayCount } -- performance group -- -- Note: block is intended to be the length of the channel -- data-block on which the CRC operates. See -- adslAturChanCrcBlockLength for more information. -- adslAturChanReceivedBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel since agent reset." ::= { adslAturChanPerfDataEntry 1 } Bathrick & Ly Standards Track [Page 59] RFC 2662 ADSL Line MIB August 1999 adslAturChanTransmittedBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel since agent reset." ::= { adslAturChanPerfDataEntry 2 } adslAturChanCorrectedBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected since agent reset. These blocks are passed on as good data." ::= { adslAturChanPerfDataEntry 3 } adslAturChanUncorrectBlks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors since agent reset." ::= { adslAturChanPerfDataEntry 4 } -- general 15 min interval information -- adslAturChanPerfValidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous 15-minute intervals in the interval table for which data was collected. Given that is the maximum # of intervals supported. The value will be unless the measurement was (re-)started within the last (*15) minutes, in which case the value will be the number of complete 15 minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy) it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { adslAturChanPerfDataEntry 5 } Bathrick & Ly Standards Track [Page 60] RFC 2662 ADSL Line MIB August 1999 adslAturChanPerfInvalidIntervals OBJECT-TYPE SYNTAX INTEGER(0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to the value of adslAturChanPerfValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { adslAturChanPerfDataEntry 6 } -- 15 min current performance group -- adslAturChanPerfCurr15MinTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..899) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval. A full interval is 900 seconds." ::= { adslAturChanPerfDataEntry 7 } adslAturChanPerfCurr15MinReceivedBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel within the current 15 minute interval." ::= { adslAturChanPerfDataEntry 8 } adslAturChanPerfCurr15MinTransmittedBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel within the current 15 minute interval." ::= { adslAturChanPerfDataEntry 9 } adslAturChanPerfCurr15MinCorrectedBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION Bathrick & Ly Standards Track [Page 61] RFC 2662 ADSL Line MIB August 1999 "Count of all blocks received with errors that were corrected on this channel within the current 15 minute interval." ::= { adslAturChanPerfDataEntry 10 } adslAturChanPerfCurr15MinUncorrectBlks OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel within the current 15 minute interval." ::= { adslAturChanPerfDataEntry 11 } -- 1-day current and previous performance group -- adslAturChanPerfCurr1DayTimeElapsed OBJECT-TYPE SYNTAX AdslPerfTimeElapsed(0..86399) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::= { adslAturChanPerfDataEntry 12 } adslAturChanPerfCurr1DayReceivedBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel during the current day as measured by adslAturChanPerfCurr1DayTimeElapsed." ::= { adslAturChanPerfDataEntry 13 } adslAturChanPerfCurr1DayTransmittedBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel during the current day as measured by adslAturChanPerfCurr1DayTimeElapsed." ::= { adslAturChanPerfDataEntry 14 } Bathrick & Ly Standards Track [Page 62] RFC 2662 ADSL Line MIB August 1999 adslAturChanPerfCurr1DayCorrectedBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected on this channel during the current day as measured by adslAturChanPerfCurr1DayTimeElapsed." ::= { adslAturChanPerfDataEntry 15 } adslAturChanPerfCurr1DayUncorrectBlks OBJECT-TYPE SYNTAX AdslPerfCurrDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel during the current day as measured by adslAturChanPerfCurr1DayTimeElapsed." ::= { adslAturChanPerfDataEntry 16 } adslAturChanPerfPrev1DayMoniSecs OBJECT-TYPE SYNTAX INTEGER(0..86400) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the previous 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::= { adslAturChanPerfDataEntry 17 } adslAturChanPerfPrev1DayReceivedBlks OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel within the most recent previous 1-day period." ::= { adslAturChanPerfDataEntry 18 } adslAturChanPerfPrev1DayTransmittedBlks OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current Bathrick & Ly Standards Track [Page 63] RFC 2662 ADSL Line MIB August 1999 DESCRIPTION "Count of all encoded blocks transmitted on this channel within the most recent previous 1-day period." ::= { adslAturChanPerfDataEntry 19 } adslAturChanPerfPrev1DayCorrectedBlks OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected on this channel within the most recent previous 1-day period." ::= { adslAturChanPerfDataEntry 20 } adslAturChanPerfPrev1DayUncorrectBlks OBJECT-TYPE SYNTAX AdslPerfPrevDayCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel within the most recent previous 1-day period." ::= { adslAturChanPerfDataEntry 21 } adslAtucChanIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUC channel's performance data collection interval. ADSL channel interfaces are those ifEntries where ifType is equal to adslInterleave(124) or adslFast(125)." ::= { adslMibObjects 12 } adslAtucChanIntervalEntry OBJECT-TYPE SYNTAX AdslAtucChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAtucIntervalTable." INDEX { ifIndex, adslAtucChanIntervalNumber } ::= { adslAtucChanIntervalTable 1 } AdslAtucChanIntervalEntry ::= SEQUENCE { Bathrick & Ly Standards Track [Page 64] RFC 2662 ADSL Line MIB August 1999 adslAtucChanIntervalNumber INTEGER, adslAtucChanIntervalReceivedBlks PerfIntervalCount, adslAtucChanIntervalTransmittedBlks PerfIntervalCount, adslAtucChanIntervalCorrectedBlks PerfIntervalCount, adslAtucChanIntervalUncorrectBlks PerfIntervalCount, adslAtucChanIntervalValidData TruthValue } adslAtucChanIntervalNumber OBJECT-TYPE SYNTAX INTEGER(1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number 1 is the the most recent previous interval; interval 96 is 24 hours ago. Intervals 2..96 are optional." ::= { adslAtucChanIntervalEntry 1 } adslAtucChanIntervalReceivedBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel during this interval." ::= { adslAtucChanIntervalEntry 2 } adslAtucChanIntervalTransmittedBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel during this interval." ::= { adslAtucChanIntervalEntry 3 } adslAtucChanIntervalCorrectedBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected on this channel during this interval." ::= { adslAtucChanIntervalEntry 4 } adslAtucChanIntervalUncorrectBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only Bathrick & Ly Standards Track [Page 65] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel during this interval." ::= { adslAtucChanIntervalEntry 5 } adslAtucChanIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adslAtucChanIntervalEntry 6 } adslAturChanIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATUR channel's performance data collection interval. ADSL channel interfaces are those ifEntries where ifType is equal to adslInterleave(124) or adslFast(125)." ::= { adslMibObjects 13 } adslAturChanIntervalEntry OBJECT-TYPE SYNTAX AdslAturChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAturIntervalTable." INDEX { ifIndex, adslAturChanIntervalNumber } ::= { adslAturChanIntervalTable 1 } AdslAturChanIntervalEntry ::= SEQUENCE { adslAturChanIntervalNumber INTEGER, adslAturChanIntervalReceivedBlks PerfIntervalCount, adslAturChanIntervalTransmittedBlks PerfIntervalCount, adslAturChanIntervalCorrectedBlks PerfIntervalCount, adslAturChanIntervalUncorrectBlks PerfIntervalCount, adslAturChanIntervalValidData TruthValue } adslAturChanIntervalNumber OBJECT-TYPE SYNTAX INTEGER(1..96) MAX-ACCESS not-accessible STATUS current Bathrick & Ly Standards Track [Page 66] RFC 2662 ADSL Line MIB August 1999 DESCRIPTION "Performance Data Interval number 1 is the the most recent previous interval; interval 96 is 24 hours ago. Intervals 2..96 are optional." ::= { adslAturChanIntervalEntry 1 } adslAturChanIntervalReceivedBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks received on this channel during this interval." ::= { adslAturChanIntervalEntry 2 } adslAturChanIntervalTransmittedBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all encoded blocks transmitted on this channel during this interval." ::= { adslAturChanIntervalEntry 3 } adslAturChanIntervalCorrectedBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with errors that were corrected on this channel during this interval." ::= { adslAturChanIntervalEntry 4 } adslAturChanIntervalUncorrectBlks OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of all blocks received with uncorrectable errors on this channel during this interval." ::= { adslAturChanIntervalEntry 5 } adslAturChanIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Bathrick & Ly Standards Track [Page 67] RFC 2662 ADSL Line MIB August 1999 "This variable indicates if the data for this interval is valid." ::= { adslAturChanIntervalEntry 6 } -- Profile Group -- adslLineConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslLineConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the ADSL line configuration. One entry in this table reflects a profile defined by a manager which can be used to configure the ADSL line." ::= { adslMibObjects 14} adslLineConfProfileEntry OBJECT-TYPE SYNTAX AdslLineConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of an ADSL modem. When `dynamic' profiles are implemented, a default profile will always exist. This profile's name will be set to `DEFVAL' and its parameters will be set to vendor specific values, unless otherwise specified in this document. When `static' profiles are implemented, profiles are automaticly created or destroyed as ADSL physical lines are discovered and removed by the system. The name of the profile will be equivalent to the decimal value of the line's interface index. " INDEX { IMPLIED adslLineConfProfileName} ::= { adslLineConfProfileTable 1} AdslLineConfProfileEntry ::= SEQUENCE { adslLineConfProfileName SnmpAdminString, adslAtucConfRateMode INTEGER, adslAtucConfRateChanRatio INTEGER, adslAtucConfTargetSnrMgn INTEGER, Bathrick & Ly Standards Track [Page 68] RFC 2662 ADSL Line MIB August 1999 adslAtucConfMaxSnrMgn INTEGER, adslAtucConfMinSnrMgn INTEGER, adslAtucConfDownshiftSnrMgn INTEGER, adslAtucConfUpshiftSnrMgn INTEGER, adslAtucConfMinUpshiftTime INTEGER, adslAtucConfMinDownshiftTime INTEGER, adslAtucChanConfFastMinTxRate Unsigned32, adslAtucChanConfInterleaveMinTxRate Unsigned32, adslAtucChanConfFastMaxTxRate Unsigned32, adslAtucChanConfInterleaveMaxTxRate Unsigned32, adslAtucChanConfMaxInterleaveDelay INTEGER, adslAturConfRateMode INTEGER, adslAturConfRateChanRatio INTEGER, adslAturConfTargetSnrMgn INTEGER, adslAturConfMaxSnrMgn INTEGER, adslAturConfMinSnrMgn INTEGER, adslAturConfDownshiftSnrMgn INTEGER, adslAturConfUpshiftSnrMgn INTEGER, adslAturConfMinUpshiftTime INTEGER, adslAturConfMinDownshiftTime INTEGER, adslAturChanConfFastMinTxRate Unsigned32, adslAturChanConfInterleaveMinTxRate Unsigned32, adslAturChanConfFastMaxTxRate Unsigned32, adslAturChanConfInterleaveMaxTxRate Unsigned32, adslAturChanConfMaxInterleaveDelay INTEGER, adslLineConfProfileRowStatus RowStatus } adslLineConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used by the line configuration table in order to identify a row of this table. When `dynamic' profiles are implemented, the profile name is user specified. Also, the system will always provide a default profile whose name is `DEFVAL'. When `static' profiles are implemented, there is an one-to-one relationship between each line and its profile. In which case, the profile name will need to algorithmicly represent the Line's ifIndex. Therefore, the profile's name is a decimalized string of the ifIndex that is fixed-length (i.e., 10) with leading zero(s). For example, the profile name for ifIndex which equals '15' will be '0000000015'." Bathrick & Ly Standards Track [Page 69] RFC 2662 ADSL Line MIB August 1999 ::= { adslLineConfProfileEntry 1 } adslAtucConfRateMode OBJECT-TYPE SYNTAX INTEGER { fixed (1), -- no rate adaptation adaptAtStartup (2), -- perform rate adaptation -- only at initialization adaptAtRuntime (3) -- perform rate adaptation at -- any time } MAX-ACCESS read-create STATUS current DESCRIPTION "Defines what form of transmit rate adaptation is configured on this modem. See ADSL Forum TR-005 [3] for more information." ::= { adslLineConfProfileEntry 2 } adslAtucConfRateChanRatio OBJECT-TYPE SYNTAX INTEGER(0..100) UNITS "%" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured allocation ratio of excess transmit bandwidth between fast and interleaved channels. Only applies when two channel mode and RADSL are supported. Distribute bandwidth on each channel in excess of the corresponding ChanConfMinTxRate so that: adslAtucConfRateChanRatio = [Fast / (Fast + Interleaved)] * 100 In other words this value is the fast channel percentage." ::= { adslLineConfProfileEntry 3 } adslAtucConfTargetSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Target Signal/Noise Margin. This is the Noise Margin the modem must achieve with a BER of 10-7 or better to successfully complete initialization." ::= { adslLineConfProfileEntry 4 } Bathrick & Ly Standards Track [Page 70] RFC 2662 ADSL Line MIB August 1999 adslAtucConfMaxSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Maximum acceptable Signal/Noise Margin. If the Noise Margin is above this the modem should attempt to reduce its power output to optimize its operation." ::= { adslLineConfProfileEntry 5 } adslAtucConfMinSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Minimum acceptable Signal/Noise Margin. If the noise margin falls below this level, the modem should attempt to increase its power output. If that is not possible the modem will attempt to re-initialize or shut down." ::= { adslLineConfProfileEntry 6 } adslAtucConfDownshiftSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Signal/Noise Margin for rate downshift. If the noise margin falls below this level, the modem should attempt to decrease its transmit rate. In the case that RADSL mode is not present, the value will be `0'." ::= { adslLineConfProfileEntry 7 } adslAtucConfUpshiftSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Signal/Noise Margin for rate upshift. If the noise margin rises above this level, the modem should attempt to increase its transmit rate. In the case that RADSL is not present, the value will Bathrick & Ly Standards Track [Page 71] RFC 2662 ADSL Line MIB August 1999 be `0'." ::= { adslLineConfProfileEntry 8 } adslAtucConfMinUpshiftTime OBJECT-TYPE SYNTAX INTEGER(0..16383) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum time that the current margin is above UpshiftSnrMgn before an upshift occurs. In the case that RADSL is not present, the value will be `0'." ::= { adslLineConfProfileEntry 9 } adslAtucConfMinDownshiftTime OBJECT-TYPE SYNTAX INTEGER(0..16383) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum time that the current margin is below DownshiftSnrMgn before a downshift occurs. In the case that RADSL mode is not present, the value will be `0'." ::= { adslLineConfProfileEntry 10 } adslAtucChanConfFastMinTxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Minimum Transmit rate for `Fast' channels, in bps. See adslAtucConfRateChanRatio for information regarding RADSL mode and ATUR transmit rate for ATUC receive rates." ::= { adslLineConfProfileEntry 11 } adslAtucChanConfInterleaveMinTxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Minimum Transmit rate for `Interleave' channels, in bps. See adslAtucConfRateChanRatio for information regarding RADSL mode and see ATUR transmit rate for receive rates." Bathrick & Ly Standards Track [Page 72] RFC 2662 ADSL Line MIB August 1999 ::= { adslLineConfProfileEntry 12 } adslAtucChanConfFastMaxTxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Maximum Transmit rate for `Fast' channels, in bps. See adslAtucConfRateChanRatio for information regarding RADSL mode and see ATUR transmit rate for ATUC receive rates." ::= { adslLineConfProfileEntry 13 } adslAtucChanConfInterleaveMaxTxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Maximum Transmit rate for `Interleave' channels, in bps. See adslAtucConfRateChanRatio for information regarding RADSL mode and ATUR transmit rate for ATUC receive rates." ::= { adslLineConfProfileEntry 14 } adslAtucChanConfMaxInterleaveDelay OBJECT-TYPE SYNTAX INTEGER(0..255) UNITS "milli-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured maximum Interleave Delay for this channel. Interleave delay applies only to the interleave channel and defines the mapping (relative spacing) between subsequent input bytes at the interleaver input and their placement in the bit stream at the interleaver output. Larger numbers provide greater separation between consecutive input bytes in the output bit stream allowing for improved impulse noise immunity at the expense of payload latency." ::= { adslLineConfProfileEntry 15 } adslAturConfRateMode OBJECT-TYPE SYNTAX INTEGER { fixed (1), -- no rate adaptation adaptAtStartup (2), -- perform rate adaptation Bathrick & Ly Standards Track [Page 73] RFC 2662 ADSL Line MIB August 1999 -- only at initialization adaptAtRuntime (3) -- perform rate adaptation at -- any time } MAX-ACCESS read-create STATUS current DESCRIPTION "Defines what form of transmit rate adaptation is configured on this modem. See ADSL Forum TR-005 [3] for more information." ::= { adslLineConfProfileEntry 16 } adslAturConfRateChanRatio OBJECT-TYPE SYNTAX INTEGER(0..100) UNITS "%" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured allocation ratio of excess transmit bandwidth between fast and interleaved channels. Only applies when two channel mode and RADSL are supported. Distribute bandwidth on each channel in excess of the corresponding ChanConfMinTxRate so that: adslAturConfRateChanRatio = [Fast / (Fast + Interleaved)] * 100 In other words this value is the fast channel percentage." ::= { adslLineConfProfileEntry 17 } adslAturConfTargetSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Target Signal/Noise Margin. This is the Noise Margin the modem must achieve with a BER of 10-7 or better to successfully complete initialization." ::= { adslLineConfProfileEntry 18 } adslAturConfMaxSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current Bathrick & Ly Standards Track [Page 74] RFC 2662 ADSL Line MIB August 1999 DESCRIPTION "Configured Maximum acceptable Signal/Noise Margin. If the Noise Margin is above this the modem should attempt to reduce its power output to optimize its operation." ::= { adslLineConfProfileEntry 19 } adslAturConfMinSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Minimum acceptable Signal/Noise Margin. If the noise margin falls below this level, the modem should attempt to increase its power output. If that is not possible the modem will attempt to re-initialize or shut down." ::= { adslLineConfProfileEntry 20 } adslAturConfDownshiftSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Signal/Noise Margin for rate downshift. If the noise margin falls below this level, the modem should attempt to decrease its transmit rate. In the case that RADSL mode is not present, the value will be `0'." ::= { adslLineConfProfileEntry 21 } adslAturConfUpshiftSnrMgn OBJECT-TYPE SYNTAX INTEGER (0..310) UNITS "tenth dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Signal/Noise Margin for rate upshift. If the noise margin rises above this level, the modem should attempt to increase its transmit rate. In the case that RADSL is not present, the value will be `0'." ::= { adslLineConfProfileEntry 22 } adslAturConfMinUpshiftTime OBJECT-TYPE SYNTAX INTEGER(0..16383) Bathrick & Ly Standards Track [Page 75] RFC 2662 ADSL Line MIB August 1999 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum time that the current margin is above UpshiftSnrMgn before an upshift occurs. In the case that RADSL is not present, the value will be `0'." ::= { adslLineConfProfileEntry 23 } adslAturConfMinDownshiftTime OBJECT-TYPE SYNTAX INTEGER(0..16383) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum time that the current margin is below DownshiftSnrMgn before a downshift occurs. In the case that RADSL mode is not present, the value will be `0'." ::= { adslLineConfProfileEntry 24 } adslAturChanConfFastMinTxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Minimum Transmit rate for `Fast' channels, in bps. See adslAturConfRateChanRatio for information regarding RADSL mode and ATUC transmit rate for ATUR receive rates." ::= { adslLineConfProfileEntry 25 } adslAturChanConfInterleaveMinTxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Minimum Transmit rate for `Interleave' channels, in bps. See adslAturConfRateChanRatio for information regarding RADSL mode and ATUC transmit rate for ATUR receive rates." ::= { adslLineConfProfileEntry 26 } adslAturChanConfFastMaxTxRate OBJECT-TYPE SYNTAX Unsigned32 Bathrick & Ly Standards Track [Page 76] RFC 2662 ADSL Line MIB August 1999 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Maximum Transmit rate for `Fast' channels, in bps. See adslAturConfRateChanRatio for information regarding RADSL mode and ATUC transmit rate for ATUR receive rates." ::= { adslLineConfProfileEntry 27 } adslAturChanConfInterleaveMaxTxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured Maximum Transmit rate for `Interleave' channels, in bps. See adslAturConfRateChanRatio for information regarding RADSL mode and see ATUC transmit rate for ATUR receive rates." ::= { adslLineConfProfileEntry 28 } adslAturChanConfMaxInterleaveDelay OBJECT-TYPE SYNTAX INTEGER(0..255) UNITS "milli-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Configured maximum Interleave Delay for this channel. Interleave delay applies only to the interleave channel and defines the mapping (relative spacing) between subsequent input bytes at the interleaver input and their placement in the bit stream at the interleaver output. Larger numbers provide greater separation between consecutive input bytes in the output bit stream allowing for improved impulse noise immunity at the expense of payload latency." ::= { adslLineConfProfileEntry 29 } adslLineConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. Bathrick & Ly Standards Track [Page 77] RFC 2662 ADSL Line MIB August 1999 A profile activated by setting this object to `active'. When `active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `outOfService') it must be first unreferenced from all associated lines. If the implementator of this MIB has chosen not to implement `dynamic assignment' of profiles, this object's MIN-ACCESS is read-only and its value is always to be `active'." ::= { adslLineConfProfileEntry 30 } adslLineAlarmConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslLineAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the ADSL line configuration. One entry in this table reflects a profile defined by a manager which can be used to configure the modem for a physical line" ::= { adslMibObjects 15} adslLineAlarmConfProfileEntry OBJECT-TYPE SYNTAX AdslLineAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of an ADSL modem. When `dynamic' profiles are implemented, a default profile will always exist. This profile's name will be set to `DEFVAL' and its parameters will be set to vendor specific values, unless otherwise specified in this document. When `static' profiles are implemented, profiles are automaticly created or destroyed as ADSL physical lines are discovered and removed by the system. The name of the profile will be equivalent to the decimal value of the line's interface index. " INDEX { IMPLIED adslLineAlarmConfProfileName} Bathrick & Ly Standards Track [Page 78] RFC 2662 ADSL Line MIB August 1999 ::= { adslLineAlarmConfProfileTable 1} AdslLineAlarmConfProfileEntry ::= SEQUENCE { adslLineAlarmConfProfileName SnmpAdminString, adslAtucThresh15MinLofs INTEGER, adslAtucThresh15MinLoss INTEGER, adslAtucThresh15MinLols INTEGER, adslAtucThresh15MinLprs INTEGER, adslAtucThresh15MinESs INTEGER, adslAtucThreshFastRateUp Unsigned32, adslAtucThreshInterleaveRateUp Unsigned32, adslAtucThreshFastRateDown Unsigned32, adslAtucThreshInterleaveRateDown Unsigned32, adslAtucInitFailureTrapEnable INTEGER, adslAturThresh15MinLofs INTEGER, adslAturThresh15MinLoss INTEGER, adslAturThresh15MinLprs INTEGER, adslAturThresh15MinESs INTEGER, adslAturThreshFastRateUp Unsigned32, adslAturThreshInterleaveRateUp Unsigned32, adslAturThreshFastRateDown Unsigned32, adslAturThreshInterleaveRateDown Unsigned32, adslLineAlarmConfProfileRowStatus RowStatus } adslLineAlarmConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used by the line alarm configuration table in order to identify a row of this table. When `dynamic' profiles are implemented, the profile name is user specified. Also, the system will always provide a default profile whose name is `DEFVAL'. When `static' profiles are implemented, there is an one-to-one relationship between each line and its profile. In which case, the profile name will need to algorithmicly represent the Line's ifIndex. Therefore, the profile's name is a decimalized string of the ifIndex that is fixed-length (i.e., 10) with leading zero(s). For example, the profile name for ifIndex which equals '15' will be '0000000015'." ::= { adslLineAlarmConfProfileEntry 1} Bathrick & Ly Standards Track [Page 79] RFC 2662 ADSL Line MIB August 1999 adslAtucThresh15MinLofs OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Loss of Frame Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAtucPerfLofsThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 2} adslAtucThresh15MinLoss OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Loss of Signal Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAtucPerfLossThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 3} adslAtucThresh15MinLols OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Loss of Link Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAtucPerfLolsThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 4} adslAtucThresh15MinLprs OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" Bathrick & Ly Standards Track [Page 80] RFC 2662 ADSL Line MIB August 1999 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Loss of Power Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAtucPerfLprsThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 5} adslAtucThresh15MinESs OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Errored Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAtucPerfESsThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 6} adslAtucThreshFastRateUp OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Fast' channels only. Configured change in rate causing an adslAtucRateChangeTrap. A trap is produced when: ChanCurrTxRate >= ChanPrevTxRate plus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 7} adslAtucThreshInterleaveRateUp OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Interleave' channels only. Configured change in rate causing an Bathrick & Ly Standards Track [Page 81] RFC 2662 ADSL Line MIB August 1999 adslAtucRateChangeTrap. A trap is produced when: ChanCurrTxRate >= ChanPrevTxRate plus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 8} adslAtucThreshFastRateDown OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Fast' channels only. Configured change in rate causing an adslAtucRateChangeTrap. A trap is produced when: ChanCurrTxRate <= ChanPrevTxRate minus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 9 } adslAtucThreshInterleaveRateDown OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Interleave' channels only. Configured change in rate causing an adslAtucRateChangeTrap. A trap is produced when: ChanCurrTxRate <= ChanPrevTxRate minus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 10 } adslAtucInitFailureTrapEnable OBJECT-TYPE SYNTAX INTEGER { enable (1), disable (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Enables and disables the InitFailureTrap. This object is defaulted disable(2)." DEFVAL { disable } ::= { adslLineAlarmConfProfileEntry 11 } adslAturThresh15MinLofs OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create Bathrick & Ly Standards Track [Page 82] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "The number of Loss of Frame Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAturPerfLofsThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 12 } adslAturThresh15MinLoss OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Loss of Signal Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAturPerfLossThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 13 } adslAturThresh15MinLprs OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Loss of Power Seconds encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAturPerfLprsThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 14 } adslAturThresh15MinESs OBJECT-TYPE SYNTAX INTEGER(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of Errored Seconds Bathrick & Ly Standards Track [Page 83] RFC 2662 ADSL Line MIB August 1999 encountered by an ADSL interface within any given 15 minutes performance data collection period, which causes the SNMP agent to send an adslAturPerfESsThreshTrap. One trap will be sent per interval per interface. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 15 } adslAturThreshFastRateUp OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Fast' channels only. Configured change in rate causing an adslAturRateChangeTrap. A trap is produced when: ChanCurrTxRate >= ChanPrevTxRate plus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 16 } adslAturThreshInterleaveRateUp OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Interleave' channels only. configured change in rate causing an adslAturRateChangeTrap. A trap is produced when: ChanCurrTxRate >= ChanPrevTxRate plus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 17 } adslAturThreshFastRateDown OBJECT-TYPE SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Fast' channels only. Configured change in rate causing an adslAturRateChangeTrap. A trap is produced when: ChanCurrTxRate <= ChanPrevTxRate minus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 18 } adslAturThreshInterleaveRateDown OBJECT-TYPE Bathrick & Ly Standards Track [Page 84] RFC 2662 ADSL Line MIB August 1999 SYNTAX Unsigned32 UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "Applies to `Interleave' channels only. Configured change in rate causing an adslAturRateChangeTrap. A trap is produced when: ChanCurrTxRate <= ChanPrevTxRate minus the value of this object. A value of `0' will disable the trap." ::= { adslLineAlarmConfProfileEntry 19 } adslLineAlarmConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile activated by setting this object to `active'. When `active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `outOfService') it must be first unreferenced from all associated lines. If the implementator of this MIB has chosen not to implement `dynamic assignment' of profiles, this object's MIN-ACCESS is read-only and its value is always to be `active'." ::= { adslLineAlarmConfProfileEntry 20 } -- Line Code Specific Tables -- These are place holders for the Line Code Specific MIBs -- once they become available. adslLCSMib OBJECT IDENTIFIER ::= { adslMibObjects 16 } -- trap definitions adslTraps OBJECT IDENTIFIER ::= { adslLineMib 2 } adslAtucTraps OBJECT IDENTIFIER ::= { adslTraps 1 } Bathrick & Ly Standards Track [Page 85] RFC 2662 ADSL Line MIB August 1999 adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAtucTraps 0 1 } adslAtucPerfLossThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLoss, adslAtucThresh15MinLoss } STATUS current DESCRIPTION "Loss of Signal 15-minute interval threshold reached." ::= { adslAtucTraps 0 2 } adslAtucPerfLprsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLprs, adslAtucThresh15MinLprs } STATUS current DESCRIPTION "Loss of Power 15-minute interval threshold reached." ::= { adslAtucTraps 0 3 } adslAtucPerfESsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinESs, adslAtucThresh15MinESs } STATUS current DESCRIPTION "Errored Second 15-minute interval threshold reached." ::= { adslAtucTraps 0 4 } adslAtucRateChangeTrap NOTIFICATION-TYPE OBJECTS { adslAtucChanCurrTxRate, adslAtucChanPrevTxRate } STATUS current DESCRIPTION "The ATUCs transmit rate has changed (RADSL mode only)" ::= { adslAtucTraps 0 5 } adslAtucPerfLolsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLols, adslAtucThresh15MinLols } STATUS current DESCRIPTION "Loss of Link 15-minute interval threshold reached." ::= { adslAtucTraps 0 6 } Bathrick & Ly Standards Track [Page 86] RFC 2662 ADSL Line MIB August 1999 adslAtucInitFailureTrap NOTIFICATION-TYPE OBJECTS { adslAtucCurrStatus } STATUS current DESCRIPTION "ATUC initialization failed. See adslAtucCurrStatus for potential reasons." ::= { adslAtucTraps 0 7 } adslAturTraps OBJECT IDENTIFIER ::= { adslTraps 2 } adslAturPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAturPerfCurr15MinLofs, adslAturThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAturTraps 0 1 } adslAturPerfLossThreshTrap NOTIFICATION-TYPE OBJECTS { adslAturPerfCurr15MinLoss, adslAturThresh15MinLoss } STATUS current DESCRIPTION "Loss of Signal 15-minute interval threshold reached." ::= { adslAturTraps 0 2 } adslAturPerfLprsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAturPerfCurr15MinLprs, adslAturThresh15MinLprs } STATUS current DESCRIPTION "Loss of Power 15-minute interval threshold reached." ::= { adslAturTraps 0 3 } adslAturPerfESsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAturPerfCurr15MinESs, adslAturThresh15MinESs } STATUS current DESCRIPTION "Errored Second 15-minute interval threshold reached." ::= { adslAturTraps 0 4 } adslAturRateChangeTrap NOTIFICATION-TYPE OBJECTS { adslAturChanCurrTxRate, adslAturChanPrevTxRate } STATUS current DESCRIPTION "The ATURs transmit rate has changed (RADSL mode only)" Bathrick & Ly Standards Track [Page 87] RFC 2662 ADSL Line MIB August 1999 ::= { adslAturTraps 0 5 } -- no adslAturPerfLolsThreshTrap possible { 0 6 } -- no adslAturInitFailureTrap possible { 0 7 } -- conformance information adslConformance OBJECT IDENTIFIER ::= { adslLineMib 3 } adslGroups OBJECT IDENTIFIER ::= { adslConformance 1 } adslCompliances OBJECT IDENTIFIER ::= { adslConformance 2 } -- ATU-C agent compliance statements adslLineMibAtucCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which manage ADSL ATU-C interfaces." MODULE -- this module MANDATORY-GROUPS { adslLineGroup, adslPhysicalGroup, adslChannelGroup, adslAtucPhysPerfIntervalGroup, adslAturPhysPerfIntervalGroup, adslLineConfProfileGroup, adslLineAlarmConfProfileGroup, adslLineConfProfileControlGroup } GROUP adslAtucPhysPerfRawCounterGroup DESCRIPTION "This group is optional. Implementations which require continuous ATU-C physical event counters should implement this group." GROUP adslAturPhysPerfRawCounterGroup DESCRIPTION "This group is optional. Implementations which require continuous ATU-R physical event counters should implement this group." GROUP adslAtucChanPerformanceGroup DESCRIPTION "This group is optional. Implementations which require ATU-C channel block event counters should implement this group." Bathrick & Ly Standards Track [Page 88] RFC 2662 ADSL Line MIB August 1999 GROUP adslAturChanPerformanceGroup DESCRIPTION "This group is optional. Implementations which require ATU-R channel block event counters should implement this group." OBJECT adslLineConfProfile MIN-ACCESS read-only DESCRIPTION "Read-only access is applicable when static profiles are implemented." OBJECT adslAtucConfRateMode MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucConfRateChanRatio MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucConfTargetSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucConfMaxSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucConfMinSnrMgn MIN-ACCESS read-wr MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucConfDownshiftSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." Bathrick & Ly Standards Track [Page 89] RFC 2662 ADSL Line MIB August 1999 OBJECT adslAtucConfUpshiftSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucConfMinUpshiftTime MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucConfMinDownshiftTime MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucChanConfFastMinTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucChanConfInterleaveMinTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucChanConfFastMaxTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucChanConfInterleaveMaxTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucChanConfMaxInterleaveDelay MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." Bathrick & Ly Standards Track [Page 90] RFC 2662 ADSL Line MIB August 1999 OBJECT adslAturConfRateMode MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturConfRateChanRatio MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturConfTargetSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturConfMaxSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturConfMinSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturConfDownshiftSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturConfUpshiftSnrMgn MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturConfMinUpshiftTime MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." Bathrick & Ly Standards Track [Page 91] RFC 2662 ADSL Line MIB August 1999 OBJECT adslAturConfMinDownshiftTime MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturChanConfFastMinTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturChanConfInterleaveMinTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturChanConfFastMaxTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturChanConfInterleaveMaxTxRate MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturChanConfMaxInterleaveDelay MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslLineConfProfileRowStatus MIN-ACCESS read-only DESCRIPTION "Read-only access is applicable only when static profiles are implemented." OBJECT adslLineAlarmConfProfile MIN-ACCESS read-only DESCRIPTION "Read-only access is applicable only when static profiles are implemented." Bathrick & Ly Standards Track [Page 92] RFC 2662 ADSL Line MIB August 1999 OBJECT adslAtucThresh15MinLofs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThresh15MinLoss MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThresh15MinLols MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThresh15MinLprs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThresh15MinESs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThreshFastRateUp MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThreshInterleaveRateUp MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThreshFastRateDown MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." Bathrick & Ly Standards Track [Page 93] RFC 2662 ADSL Line MIB August 1999 OBJECT adslAtucThreshInterleaveRateDown MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucInitFailureTrapEnable MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinLofs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinLoss MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinLprs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinESs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThreshFastRateUp MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThreshInterleaveRateUp MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." Bathrick & Ly Standards Track [Page 94] RFC 2662 ADSL Line MIB August 1999 OBJECT adslAturThreshFastRateDown MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThreshInterleaveRateDown MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslLineAlarmConfProfileRowStatus MIN-ACCESS read-only DESCRIPTION "Read-only access is applicable only when static profiles are implemented." ::= { adslCompliances 1 } -- ATU-R agent compliance statements adslLineMibAturCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which manage ADSL ATU-R interfaces." MODULE -- this module MANDATORY-GROUPS { adslAturLineGroup, adslAturPhysicalGroup, adslAturChannelGroup, adslAturAtucPhysPerfIntervalGroup, adslAturAturPhysPerfIntervalGroup, adslAturLineAlarmConfProfileGroup, adslAturLineConfProfileControlGroup } GROUP adslAturAtucPhysPerfRawCounterGroup DESCRIPTION "This group is optional. Implementations which require continuous ATU-C physical event counters should implement this group." GROUP adslAturAturPhysPerfRawCounterGroup DESCRIPTION "This group is optional. Implementations which Bathrick & Ly Standards Track [Page 95] RFC 2662 ADSL Line MIB August 1999 require continuous ATU-R physical event counters should implement this group." GROUP adslAturAtucChanPerformanceGroup DESCRIPTION "This group is optional. Implementations which require ATU-C channel block event counters should implement this group." GROUP adslAturAturChanPerformanceGroup DESCRIPTION "This group is optional. Implementations which require ATU-R channel block event counters should implement this group." OBJECT adslLineAlarmConfProfile MIN-ACCESS read-only DESCRIPTION "Read-only access is applicable only when static profiles are implemented." OBJECT adslAtucThresh15MinLofs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThresh15MinLoss MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThresh15MinESs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThreshFastRateUp MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThreshInterleaveRateUp MIN-ACCESS read-write DESCRIPTION Bathrick & Ly Standards Track [Page 96] RFC 2662 ADSL Line MIB August 1999 "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucThreshFastRateDown MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAtucInitFailureTrapEnable MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinLofs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinLoss MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinLprs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThresh15MinESs MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThreshFastRateUp MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThreshInterleaveRateUp MIN-ACCESS read-write Bathrick & Ly Standards Track [Page 97] RFC 2662 ADSL Line MIB August 1999 DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThreshFastRateDown MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslAturThreshInterleaveRateDown MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable when static profiles are implemented." OBJECT adslLineAlarmConfProfileRowStatus MIN-ACCESS read-only DESCRIPTION "Read-only access is applicable only when static profiles are implemented." OBJECT adslAtucCurrStatus SYNTAX BITS { noDefect(0), lossOfFraming(1), lossOfSignal(2) } DESCRIPTION "It is allowable to implement only noDefect(0), lossOfFraming(1) and lossOfSignal(2) by the ATU-R agent." ::= { adslCompliances 2 } -- units of conformance adslLineGroup OBJECT-GROUP OBJECTS { adslLineCoding, adslLineType, adslLineSpecific } STATUS current DESCRIPTION "A collection of objects providing configuration information about an ADSL Line." ::= { adslGroups 1 } adslPhysicalGroup OBJECT-GROUP OBJECTS { Bathrick & Ly Standards Track [Page 98] RFC 2662 ADSL Line MIB August 1999 adslAtucInvSerialNumber, adslAtucInvVendorID, adslAtucInvVersionNumber, adslAtucCurrSnrMgn, adslAtucCurrAtn, adslAtucCurrStatus, adslAtucCurrOutputPwr, adslAtucCurrAttainableRate, adslAturInvSerialNumber, adslAturInvVendorID, adslAturInvVersionNumber, adslAturCurrSnrMgn, adslAturCurrAtn, adslAturCurrStatus, adslAturCurrOutputPwr, adslAturCurrAttainableRate } STATUS current DESCRIPTION "A collection of objects providing physical configuration information of the ADSL Line." ::= { adslGroups 2 } adslChannelGroup OBJECT-GROUP OBJECTS { adslAtucChanInterleaveDelay, adslAtucChanCurrTxRate, adslAtucChanPrevTxRate, adslAtucChanCrcBlockLength, adslAturChanInterleaveDelay, adslAturChanCurrTxRate, adslAturChanPrevTxRate, adslAturChanCrcBlockLength } STATUS current DESCRIPTION "A collection of objects providing configuration information about an ADSL channel." ::= { adslGroups 3 } adslAtucPhysPerfRawCounterGroup OBJECT-GROUP OBJECTS { adslAtucPerfLofs, adslAtucPerfLoss, adslAtucPerfLols, adslAtucPerfLprs, adslAtucPerfESs, adslAtucPerfInits } STATUS current DESCRIPTION "A collection of objects providing raw performance counts on an ADSL Line (ATU-C end)." ::= { adslGroups 4 } adslAtucPhysPerfIntervalGroup OBJECT-GROUP OBJECTS { adslAtucPerfValidIntervals, adslAtucPerfInvalidIntervals, adslAtucPerfCurr15MinTimeElapsed, adslAtucPerfCurr15MinLofs, adslAtucPerfCurr15MinLoss, adslAtucPerfCurr15MinLols, adslAtucPerfCurr15MinLprs, adslAtucPerfCurr15MinESs, adslAtucPerfCurr15MinInits, Bathrick & Ly Standards Track [Page 99] RFC 2662 ADSL Line MIB August 1999 adslAtucPerfCurr1DayLofs, adslAtucPerfCurr1DayLoss, adslAtucPerfCurr1DayLols, adslAtucPerfCurr1DayLprs, adslAtucPerfCurr1DayESs, adslAtucPerfCurr1DayInits, adslAtucPerfPrev1DayMoniSecs, adslAtucPerfPrev1DayLofs, adslAtucPerfPrev1DayLoss, adslAtucPerfPrev1DayLols, adslAtucPerfPrev1DayLprs, adslAtucPerfPrev1DayESs, adslAtucPerfPrev1DayInits, adslAtucIntervalLofs, adslAtucIntervalLoss, adslAtucIntervalLols, adslAtucIntervalLprs, adslAtucIntervalESs, adslAtucIntervalInits, adslAtucIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing current 15-minute, 1-day; and previous 1-day performance counts on ADSL Line (ATU-C end) ." ::= { adslGroups 5 } adslAturPhysPerfRawCounterGroup OBJECT-GROUP OBJECTS { adslAturPerfLofs, adslAturPerfLoss, adslAturPerfLprs, adslAturPerfESs } STATUS current DESCRIPTION "A collection of objects providing raw performance counts on an ADSL Line (ATU-R end)." ::= { adslGroups 6 } adslAturPhysPerfIntervalGroup OBJECT-GROUP OBJECTS { adslAturPerfValidIntervals, adslAturPerfInvalidIntervals, adslAturPerfCurr15MinTimeElapsed, adslAturPerfCurr15MinLofs, adslAturPerfCurr15MinLoss, adslAturPerfCurr15MinLprs, adslAturPerfCurr15MinESs, adslAturPerfCurr1DayTimeElapsed, adslAturPerfCurr1DayLofs, adslAturPerfCurr1DayLoss, adslAturPerfCurr1DayLprs, adslAturPerfCurr1DayESs, adslAturPerfPrev1DayMoniSecs, adslAturPerfPrev1DayLofs, adslAturPerfPrev1DayLoss, adslAturPerfPrev1DayLprs, adslAturPerfPrev1DayESs, adslAturIntervalLofs, adslAturIntervalLoss, adslAturIntervalLprs, adslAturIntervalESs, adslAturIntervalValidData } Bathrick & Ly Standards Track [Page 100] RFC 2662 ADSL Line MIB August 1999 STATUS current DESCRIPTION "A collection of objects providing current 15-minute, 1-day; and previous 1-day performance counts on ADSL Line (ATU-R end)." ::= { adslGroups 7 } adslAtucChanPerformanceGroup OBJECT-GROUP OBJECTS { adslAtucChanReceivedBlks, adslAtucChanTransmittedBlks, adslAtucChanCorrectedBlks, adslAtucChanUncorrectBlks, adslAtucChanPerfValidIntervals, adslAtucChanPerfInvalidIntervals, adslAtucChanPerfCurr15MinTimeElapsed, adslAtucChanPerfCurr15MinReceivedBlks, adslAtucChanPerfCurr15MinTransmittedBlks, adslAtucChanPerfCurr15MinCorrectedBlks, adslAtucChanPerfCurr15MinUncorrectBlks, adslAtucChanPerfCurr1DayTimeElapsed, adslAtucChanPerfCurr1DayReceivedBlks, adslAtucChanPerfCurr1DayTransmittedBlks, adslAtucChanPerfCurr1DayCorrectedBlks, adslAtucChanPerfCurr1DayUncorrectBlks, adslAtucChanPerfPrev1DayMoniSecs, adslAtucChanPerfPrev1DayReceivedBlks, adslAtucChanPerfPrev1DayTransmittedBlks, adslAtucChanPerfPrev1DayCorrectedBlks, adslAtucChanPerfPrev1DayUncorrectBlks, adslAtucChanIntervalReceivedBlks, adslAtucChanIntervalTransmittedBlks, adslAtucChanIntervalCorrectedBlks, adslAtucChanIntervalUncorrectBlks, adslAtucChanIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing channel block performance information on an ADSL channel (ATU-C end)." ::= { adslGroups 8 } adslAturChanPerformanceGroup OBJECT-GROUP OBJECTS { adslAturChanReceivedBlks, adslAturChanTransmittedBlks, adslAturChanCorrectedBlks, Bathrick & Ly Standards Track [Page 101] RFC 2662 ADSL Line MIB August 1999 adslAturChanUncorrectBlks, adslAturChanPerfValidIntervals, adslAturChanPerfInvalidIntervals, adslAturChanPerfCurr15MinTimeElapsed, adslAturChanPerfCurr15MinReceivedBlks, adslAturChanPerfCurr15MinTransmittedBlks, adslAturChanPerfCurr15MinCorrectedBlks, adslAturChanPerfCurr15MinUncorrectBlks, adslAturChanPerfCurr1DayTimeElapsed, adslAturChanPerfCurr1DayReceivedBlks, adslAturChanPerfCurr1DayTransmittedBlks, adslAturChanPerfCurr1DayCorrectedBlks, adslAturChanPerfCurr1DayUncorrectBlks, adslAturChanPerfPrev1DayMoniSecs, adslAturChanPerfPrev1DayReceivedBlks, adslAturChanPerfPrev1DayTransmittedBlks, adslAturChanPerfPrev1DayCorrectedBlks, adslAturChanPerfPrev1DayUncorrectBlks, adslAturChanIntervalReceivedBlks, adslAturChanIntervalTransmittedBlks, adslAturChanIntervalCorrectedBlks, adslAturChanIntervalUncorrectBlks, adslAturChanIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing channel block performance information on an ADSL channel (ATU-C end)." ::= { adslGroups 9 } adslLineConfProfileGroup OBJECT-GROUP OBJECTS { adslAtucConfRateMode, adslAtucConfRateChanRatio, adslAtucConfTargetSnrMgn, adslAtucConfMaxSnrMgn, adslAtucConfMinSnrMgn, adslAtucConfDownshiftSnrMgn, adslAtucConfUpshiftSnrMgn, adslAtucConfMinUpshiftTime, adslAtucConfMinDownshiftTime, adslAtucChanConfFastMinTxRate, adslAtucChanConfInterleaveMinTxRate, adslAtucChanConfFastMaxTxRate, adslAtucChanConfInterleaveMaxTxRate, adslAtucChanConfMaxInterleaveDelay, adslAturConfRateMode, adslAturConfRateChanRatio, adslAturConfTargetSnrMgn, adslAturConfMaxSnrMgn, adslAturConfMinSnrMgn, adslAturConfDownshiftSnrMgn, Bathrick & Ly Standards Track [Page 102] RFC 2662 ADSL Line MIB August 1999 adslAturConfUpshiftSnrMgn, adslAturConfMinUpshiftTime, adslAturConfMinDownshiftTime, adslAturChanConfFastMinTxRate, adslAturChanConfInterleaveMinTxRate, adslAturChanConfFastMaxTxRate, adslAturChanConfInterleaveMaxTxRate, adslAturChanConfMaxInterleaveDelay } STATUS current DESCRIPTION "A collection of objects providing provisioning information about an ADSL Line." ::= { adslGroups 10 } adslLineAlarmConfProfileGroup OBJECT-GROUP OBJECTS { adslAtucThresh15MinLofs, adslAtucThresh15MinLoss, adslAtucThresh15MinLols, adslAtucThresh15MinLprs, adslAtucThresh15MinESs, adslAtucThreshFastRateUp, adslAtucThreshInterleaveRateUp, adslAtucThreshFastRateDown, adslAtucThreshInterleaveRateDown, adslAtucInitFailureTrapEnable, adslAturThresh15MinLofs, adslAturThresh15MinLoss, adslAturThresh15MinLprs, adslAturThresh15MinESs, adslAturThreshFastRateUp, adslAturThreshInterleaveRateUp, adslAturThreshFastRateDown, adslAturThreshInterleaveRateDown } STATUS current DESCRIPTION "A collection of objects providing alarm provisioning information about an ADSL Line." ::= { adslGroups 11 } adslLineConfProfileControlGroup OBJECT-GROUP OBJECTS { adslLineConfProfile, adslLineAlarmConfProfile, adslLineConfProfileRowStatus, adslLineAlarmConfProfileRowStatus } STATUS current DESCRIPTION "A collection of objects providing profile control for the ADSL system." ::= { adslGroups 12 } Bathrick & Ly Standards Track [Page 103] RFC 2662 ADSL Line MIB August 1999 adslNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { adslAtucPerfLofsThreshTrap, adslAtucPerfLossThreshTrap, adslAtucPerfLprsThreshTrap, adslAtucPerfESsThreshTrap, adslAtucRateChangeTrap, adslAtucPerfLolsThreshTrap, adslAtucInitFailureTrap, adslAturPerfLofsThreshTrap, adslAturPerfLossThreshTrap, adslAturPerfLprsThreshTrap, adslAturPerfESsThreshTrap, adslAturRateChangeTrap } STATUS current DESCRIPTION "The collection of adsl notifications." ::= { adslGroups 13 } -- units of conformance for ATU-R agent adslAturLineGroup OBJECT-GROUP OBJECTS { adslLineCoding } STATUS current DESCRIPTION "A collection of objects providing configuration information about an ADSL Line on the ATU-R side." ::= { adslGroups 14 } adslAturPhysicalGroup OBJECT-GROUP OBJECTS { adslAtucInvVendorID, adslAtucInvVersionNumber, adslAtucCurrOutputPwr, adslAtucCurrAttainableRate, adslAturInvSerialNumber, adslAturInvVendorID, adslAturInvVersionNumber, adslAturCurrSnrMgn, adslAturCurrAtn, adslAturCurrStatus, adslAturCurrOutputPwr, adslAturCurrAttainableRate, adslAtucCurrStatus } STATUS current DESCRIPTION "A collection of objects providing physical configuration information of the ADSL Line on the ATU-R side." Bathrick & Ly Standards Track [Page 104] RFC 2662 ADSL Line MIB August 1999 ::= { adslGroups 15 } adslAturChannelGroup OBJECT-GROUP OBJECTS { adslAtucChanInterleaveDelay, adslAtucChanCurrTxRate, adslAtucChanPrevTxRate, adslAturChanInterleaveDelay, adslAturChanCurrTxRate, adslAturChanPrevTxRate, adslAturChanCrcBlockLength } STATUS current DESCRIPTION "A collection of objects providing configuration information about an ADSL channel on the ATU-R side." ::= { adslGroups 16 } adslAturAtucPhysPerfRawCounterGroup OBJECT-GROUP OBJECTS { adslAtucPerfLofs, adslAtucPerfLoss, adslAtucPerfESs, adslAtucPerfInits } STATUS current DESCRIPTION "A collection of objects providing raw performance counts on an ADSL Line (ATU-C end) provided by the ATU-R agent." ::= { adslGroups 17 } adslAturAtucPhysPerfIntervalGroup OBJECT-GROUP OBJECTS { adslAtucPerfValidIntervals, adslAtucPerfInvalidIntervals, adslAtucPerfCurr15MinTimeElapsed, adslAtucPerfCurr15MinLofs, adslAtucPerfCurr15MinLoss, adslAtucPerfCurr15MinESs, adslAtucPerfCurr15MinInits, adslAtucPerfCurr1DayTimeElapsed, adslAtucPerfCurr1DayLofs, adslAtucPerfCurr1DayLoss, adslAtucPerfCurr1DayESs, adslAtucPerfCurr1DayInits, adslAtucPerfPrev1DayMoniSecs, adslAtucPerfPrev1DayLofs, adslAtucPerfPrev1DayLoss, adslAtucPerfPrev1DayESs, adslAtucPerfPrev1DayInits, adslAtucIntervalLofs, adslAtucIntervalLoss, adslAtucIntervalESs, adslAtucIntervalInits, adslAtucIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing current Bathrick & Ly Standards Track [Page 105] RFC 2662 ADSL Line MIB August 1999 15-minute, 1-day; and previous 1-day performance counts on ADSL Line (ATU-C end) provided by the ATU-R agent." ::= { adslGroups 18 } adslAturAturPhysPerfRawCounterGroup OBJECT-GROUP OBJECTS { adslAturPerfLofs, adslAturPerfLoss, adslAturPerfLprs, adslAturPerfESs } STATUS current DESCRIPTION "A collection of objects providing raw performance counts on an ADSL Line (ATU-R end) provided by the ATU-R agent." ::= { adslGroups 19 } adslAturAturPhysPerfIntervalGroup OBJECT-GROUP OBJECTS { adslAturPerfValidIntervals, adslAturPerfInvalidIntervals, adslAturPerfCurr15MinTimeElapsed, adslAturPerfCurr15MinLofs, adslAturPerfCurr15MinLoss, adslAturPerfCurr15MinLprs, adslAturPerfCurr15MinESs, adslAturPerfCurr1DayTimeElapsed, adslAturPerfCurr1DayLofs, adslAturPerfCurr1DayLoss, adslAturPerfCurr1DayLprs, adslAturPerfCurr1DayESs, adslAturPerfPrev1DayMoniSecs, adslAturPerfPrev1DayLofs, adslAturPerfPrev1DayLoss, adslAturPerfPrev1DayLprs, adslAturPerfPrev1DayESs, adslAturIntervalLofs, adslAturIntervalLoss, adslAturIntervalLprs, adslAturIntervalESs, adslAturIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing current 15-minute, 1-day; and previous 1-day performance counts on ADSL Line (ATU-R end) provided by the ATU-R agent." ::= { adslGroups 20 } adslAturAtucChanPerformanceGroup OBJECT-GROUP OBJECTS { adslAtucChanReceivedBlks, adslAtucChanTransmittedBlks, adslAtucChanCorrectedBlks, adslAtucChanUncorrectBlks, Bathrick & Ly Standards Track [Page 106] RFC 2662 ADSL Line MIB August 1999 adslAtucChanPerfCurr15MinTimeElapsed, adslAtucChanPerfCurr15MinReceivedBlks, adslAtucChanPerfCurr15MinTransmittedBlks, adslAtucChanPerfCurr15MinCorrectedBlks, adslAtucChanPerfCurr15MinUncorrectBlks, adslAtucChanPerfCurr1DayTimeElapsed, adslAtucChanPerfCurr1DayReceivedBlks, adslAtucChanPerfCurr1DayTransmittedBlks, adslAtucChanPerfCurr1DayCorrectedBlks, adslAtucChanPerfCurr1DayUncorrectBlks, adslAtucChanPerfPrev1DayMoniSecs, adslAtucChanPerfPrev1DayReceivedBlks, adslAtucChanPerfPrev1DayTransmittedBlks, adslAtucChanPerfPrev1DayCorrectedBlks, adslAtucChanPerfPrev1DayUncorrectBlks, adslAtucChanPerfValidIntervals, adslAtucChanPerfInvalidIntervals, adslAtucChanIntervalReceivedBlks, adslAtucChanIntervalTransmittedBlks, adslAtucChanIntervalCorrectedBlks, adslAtucChanIntervalUncorrectBlks, adslAtucChanIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing channel block performance information on an ADSL channel (ATU-C end) provided by the ATU-R agent." ::= { adslGroups 21 } adslAturAturChanPerformanceGroup OBJECT-GROUP OBJECTS { adslAturChanReceivedBlks, adslAturChanTransmittedBlks, adslAturChanCorrectedBlks, adslAturChanUncorrectBlks, adslAturChanPerfValidIntervals, adslAturChanPerfInvalidIntervals, adslAturChanPerfCurr15MinTimeElapsed, adslAturChanPerfCurr15MinReceivedBlks, adslAturChanPerfCurr15MinTransmittedBlks, adslAturChanPerfCurr15MinCorrectedBlks, adslAturChanPerfCurr15MinUncorrectBlks, adslAturChanPerfCurr1DayTimeElapsed, adslAturChanPerfCurr1DayReceivedBlks, adslAturChanPerfCurr1DayTransmittedBlks, adslAturChanPerfCurr1DayCorrectedBlks, adslAturChanPerfCurr1DayUncorrectBlks, Bathrick & Ly Standards Track [Page 107] RFC 2662 ADSL Line MIB August 1999 adslAturChanPerfPrev1DayMoniSecs, adslAturChanPerfPrev1DayReceivedBlks, adslAturChanPerfPrev1DayTransmittedBlks, adslAturChanPerfPrev1DayCorrectedBlks, adslAturChanPerfPrev1DayUncorrectBlks, adslAturChanIntervalReceivedBlks, adslAturChanIntervalTransmittedBlks, adslAturChanIntervalCorrectedBlks, adslAturChanIntervalUncorrectBlks, adslAturChanIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing channel block performance information on an ADSL channel (ATU-R end) provided by the ATU-R agent." ::= { adslGroups 22 } adslAturLineAlarmConfProfileGroup OBJECT-GROUP OBJECTS { adslAtucThresh15MinLofs, adslAtucThresh15MinLoss, adslAtucThresh15MinESs, adslAtucThreshFastRateUp, adslAtucThreshInterleaveRateUp, adslAtucThreshFastRateDown, adslAtucThreshInterleaveRateDown, adslAtucInitFailureTrapEnable, adslAturThresh15MinLofs, adslAturThresh15MinLoss, adslAturThresh15MinLprs, adslAturThresh15MinESs, adslAturThreshFastRateUp, adslAturThreshInterleaveRateUp, adslAturThreshFastRateDown, adslAturThreshInterleaveRateDown } STATUS current DESCRIPTION "A collection of objects providing alarm provisioning information about an ADSL Line provided by the ATU-R agent." ::= { adslGroups 23 } adslAturLineConfProfileControlGroup OBJECT-GROUP OBJECTS { adslLineAlarmConfProfile, adslLineAlarmConfProfileRowStatus } STATUS current DESCRIPTION Bathrick & Ly Standards Track [Page 108] RFC 2662 ADSL Line MIB August 1999 "A collection of objects providing profile control for the ADSL system by the ATU-R agent." ::= { adslGroups 24 } adslAturNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { adslAtucPerfLofsThreshTrap, adslAtucPerfLossThreshTrap, adslAtucPerfESsThreshTrap, adslAtucRateChangeTrap, adslAturPerfLofsThreshTrap, adslAturPerfLossThreshTrap, adslAturPerfLprsThreshTrap, adslAturPerfESsThreshTrap, adslAturRateChangeTrap } STATUS current DESCRIPTION "The collection of ADSL notifications implemented by the ATU-R agent." ::= { adslGroups 25 } END Bathrick & Ly Standards Track [Page 109] RFC 2662 ADSL Line MIB August 1999 8. Acknowledgments The current authors/editors are: Gregory Bathrick (AG Communication Systems) Faye Ly (Copper Mountain Networks) Input from the ADSL Forum was edited by: Gregory Bathrick (AG Communication Systems) John Burgess (Predictive Systems) Contributions have been received from, but not limited to the following. (in alphabetical order) David Allen (Nortel) Rajesh Abbi (Alcatel) Gregory Bathrick (AG Communication Systems) Umberto Bonollo (NEC) John Burgess (Predictive Systems) Gail Cone (Amati) Andrew Cheers (NEC) Peter Duffy (Atlantech) Kevin Godfrey (Motorola) Bill Hong (Diamond Lane) Bob Jenness (Siemens) Lars Johansson (Ericsson) Jeff Johnson (RedBack Network) Tsu Kai Lu (DSC) Faye Ly (Copper Mountain Networks) Gigi Karmous-Edwards (Pulsecom) Ron Knipper (Diamond Lane) Adil Masood (AG Communication Systems) Padmore Peterson (BT) Anna Salguero (SBC) Donald Simon (Motorola) Mike Sneed (Pulsecom) Ted Soo-Hoo (Pulsecom) John Stehman (Diamond Lane) Chuck Storry (Newbridge) Chi-Lin Tom (AFC) Frank Van der Putten (Alcatel) Marc Van Vlimmeren (Alcatel) Bert Wijnen (IBM) Bathrick & Ly Standards Track [Page 110] RFC 2662 ADSL Line MIB August 1999 9. References [1] McCloghrie K., Perkins D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [2] McCloghrie K., Perkins D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [3] ADSL Forum TR-005, "Network Management Element Management", March 1998. [4] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [5] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [6] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [7] Case, J., Fedor, M., Schoffstall, M. and J. Davin. " A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [8] 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. [9] ADSL Forum TR-006, "SNMP-based ADSL Line MIB", March 1998. [10] American National Standards Institute, ANSI T1.413-1995, August 1995. [11] ADSL Forum WT-014, "DMT Line Code Specific MIB", February 1999. [12] ADSL Forum WT-015, "CAP Line Code Specific MIB", February 1999. [13] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [14] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. Bathrick & Ly Standards Track [Page 111] RFC 2662 ADSL Line MIB August 1999 [15] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [16] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [17] McCloghrie K., Perkins D. and J. Schoenwaelder, "Conformance Statements for SMIv2", RFC 2580, April 1999. [18] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [19] 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. [20] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [21] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [22] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [23] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [24] Ahmed, M. and K. Tesink, Editors, "Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2", RFC 1695, August 1994. [25] McCloghrie, K. and A. Bierman, "Entity MIB", RFC 2037, October 1996. [26] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Bathrick & Ly Standards Track [Page 112] RFC 2662 ADSL Line MIB August 1999 10. Security Considerations 1) Blocking unauthorized access to the ADSL MIB via the element management system is outside the scope of this document. It should be noted that access to the MIB permits the unauthorized entity to modify the profiles (sect 6.4) such that both subscriber service and network operations can be interfered with. Subscriber service can be altered by modifying any of a number of service characteristics such as rate partitioning and maximum transmission rates. Network operations can be impacted by modification of trap thresholds such as SNR margins. 2) There are a number of managed objects in this MIB that may be considered to contain sensitive information. In particular, the certain objects may be considered sensitive in many environments, since it would allow an intruder to obtain information about which vendor's equipment is in use on the network. Therefore, it may be important in some environments to control read access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [21] and the View-based Access Control Model RFC 2575 [23] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 3) ADSL layer connectivity from the ATU-R will permit the subscriber to manipulate both the ADSL link directly and the AOC/EOC channels for their own loop. For example, unchecked or unfiltered fluctuations initiated by the subscriber could generate sufficient traps to potentially overwhelm either the management interface to the network or the element manager. Other attacks affecting the ATU-R portions of the MIB may also be possible. Bathrick & Ly Standards Track [Page 113] RFC 2662 ADSL Line MIB August 1999 11. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Authors' Addresses Gregory Bathrick AG Communication Systems [A Subsidiary of Lucent Technologies] 2500 W Utopia Rd. Phoenix, AZ 85027 USA Phone: +1 602-582-7679 Fax: +1 602-582-7697 EMail: bathricg@agcs.com Faye Ly Copper Mountain Networks Norcal Office 2470 Embarcadero Way Palo Alto, CA 94303 Phone: +1 650-858-8500 Fax: +1 650-858-8085 EMail: faye@coppermountain.com Bathrick & Ly Standards Track [Page 114] RFC 2662 ADSL Line MIB August 1999 13. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bathrick & Ly Standards Track [Page 115] snmp-mibs-downloader-1.1/mibrfcs/rfc2666.txt0000644000000000000000000011150311402176071015566 0ustar Network Working Group J. Flick Request for Comments: 2666 Hewlett-Packard Company Category: Informational August 1999 Definitions of Object Identifiers for Identifying Ethernet Chip Sets Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes. Table of Contents 1. Introduction ............................................... 2 2. The SNMP Management Framework .............................. 2 3. Definitions ................................................ 3 4. Intellectual Property ...................................... 14 5. Acknowledgements ........................................... 15 6. References ................................................. 15 7. Security Considerations .................................... 16 8. Author's Address ........................................... 17 9. Full Copyright Statement ................................... 18 Flick Informational [Page 1] RFC 2666 Ethernet Chipset MIB August 1999 1. Introduction This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes. The dot3StatsEtherChipSet object has recently been deprecated. The purpose of this document is to capture historic assignments made by the various IETF working groups that have been responsible for maintaining the EtherLike-MIB. Implementations which support the dot3StatsEtherChipSet object for backwards compatability may continue to use the OBJECT IDENTIFIER values assigned in this document. For those chipsets not represented in this document, implementors should assign OBJECT IDENTIFIER values within that part of the registration tree delegated to individual enterprises. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. Flick Informational [Page 2] RFC 2666 Ethernet Chipset MIB August 1999 o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Definitions ETHER-CHIPSET-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI dot3 FROM EtherLike-MIB; etherChipsetMIB MODULE-IDENTITY LAST-UPDATED "9908240400Z" -- August 24, 199 ORGANIZATION "IETF 802.3 Hub MIB Working Group" CONTACT-INFO "WG E-mail: hubmib@hprnd.rose.hp.com To subscribe: hubmib-request@hprnd.rose.hp.com Chair: Dan Romascanu Postal: Lucent Technologies Atidum Technology Park, Bldg. 3 Tel Aviv 61131 Israel Tel: +972 3 645 8414 E-mail: dromasca@lucent.com Editor: John Flick Postal: Hewlett-Packard Company 8000 Foothills Blvd. M/S 5556 Roseville, CA 95747-5556 USA Flick Informational [Page 3] RFC 2666 Ethernet Chipset MIB August 1999 Tel: +1 916 785 4018 Fax: +1 916 785 3583 E-mail: johnf@rose.hp.com" DESCRIPTION "This MIB module contains registered values for use by the dot3StatsEtherChipSet object in the EtherLike-MIB. This object is used to identify the MAC hardware used to communicate on an interface. Note that the dot3StatsEtherChipSet object has been deprecated. The primary purpose of this module is to capture historic assignments made by the various IETF working groups that have been responsible for maintaining the EtherLike-MIB. Implementations which support the dot3StatsEtherChipSet object for backwards compatability may continue to use these values. For those chipsets not represented in this module, registration is required in other documentation, e.g., assignment within that part of the registration tree delegated to individual enterprises (see RFC 1155 and RFC 1902)." REVISION "9908240400Z" -- August 24, 1999 DESCRIPTION "Initial version of this module created by splitting the chipset registration information out from the EtherLike-MIB. Version published as RFC 2666." ::= { mib-2 70 } dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 } dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 } dot3ChipSetAMD7990 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am7990 Local Area Network Controller for Ethernet (LANCE)." ::= { dot3ChipSetAMD 1 } dot3ChipSetAMD79900 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79900 chip." ::= { dot3ChipSetAMD 2 } Flick Informational [Page 4] RFC 2666 Ethernet Chipset MIB August 1999 dot3ChipSetAMD79C940 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C940 Media Access Controller for Ethernet (MACE)." ::= { dot3ChipSetAMD 3 } dot3ChipSetAMD79C90 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C90 CMOS Local Area Network Controller for Ethernet (C-LANCE)." ::= { dot3ChipSetAMD 4 } dot3ChipSetAMD79C960 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C960 PCnet-ISA Single Chip Ethernet Controller for ISA." ::= { dot3ChipSetAMD 5 } dot3ChipSetAMD79C961 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C961 PCnet-ISA+ Single Chip Plug & Play Full-Duplex Ethernet Controller for ISA." ::= { dot3ChipSetAMD 6 } dot3ChipSetAMD79C961A OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C961A PCnet-ISA II Single Chip Plug & Play Full-Duplex Ethernet Controller for ISA." ::= { dot3ChipSetAMD 7 } dot3ChipSetAMD79C965 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C965 PCnet-32 Single Chip Ethernet Controller for PCI." ::= { dot3ChipSetAMD 8 } dot3ChipSetAMD79C970 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C970 PCnet PCI Single Chip Flick Informational [Page 5] RFC 2666 Ethernet Chipset MIB August 1999 Ethernet Controller for PCI Local Bus." ::= { dot3ChipSetAMD 9 } dot3ChipSetAMD79C970A OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices AM79C970A PCnet PCI II Single Chip Full-Duplex Ethernet Controller for PCI Local Bus." ::= { dot3ChipSetAMD 10 } dot3ChipSetAMD79C971 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C971 PCnet-FAST Single Chip Full-Duplex 10/100 Mbps Ethernet Controller for PCI Local Bus." ::= { dot3ChipSetAMD 11 } dot3ChipSetAMD79C972 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Advanced Micro Devices Am79C972 PCnet-FAST+ Enhanced 10/100 Mbps PCI Ethernet Controller with OnNow Support." ::= { dot3ChipSetAMD 12 } dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 } dot3ChipSetIntel82586 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Intel 82586 IEEE 802.3 Ethernet LAN Coprocessor." ::= { dot3ChipSetIntel 1 } dot3ChipSetIntel82596 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Intel 82596 High-Performance 32-Bit Local Area Network Coprocessor." ::= { dot3ChipSetIntel 2 } dot3ChipSetIntel82595 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Intel 82595 High Integration Ethernet Controller." ::= { dot3ChipSetIntel 3 } Flick Informational [Page 6] RFC 2666 Ethernet Chipset MIB August 1999 dot3ChipSetIntel82557 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Intel 82557 Fast Ethernet PCI Bus Lan Controller." ::= { dot3ChipSetIntel 4 } dot3ChipSetIntel82558 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Intel 82558 Fast Ethernet PCI Bus LAN Controller with Integrated PHY." ::= { dot3ChipSetIntel 5 } dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 } dot3ChipSetSeeq8003 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 8003 chip set." ::= { dot3ChipSetSeeq 1 } dot3ChipSetSeeq80C03 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 80C03 Full-Duplex CMOS Ethernet Data Link Controller (MAC)." ::= { dot3ChipSetSeeq 2 } dot3ChipSetSeeq84C30 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 4-Port 84C30 Full-Duplex CMOS Ethernet 10 MBit/Sec Data Link Controller (MAC)." ::= { dot3ChipSetSeeq 3 } dot3ChipSetSeeq8431 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 4-Port 8431 Full-Duplex CMOS Ethernet 10 MBit/Sec Data Link Controller (MAC)." ::= { dot3ChipSetSeeq 4 } dot3ChipSetSeeq80C300 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 80C300 Full-Duplex CMOS Ethernet 10/100 Mbit/Sec Data Link Controller (MAC)." ::= { dot3ChipSetSeeq 5 } Flick Informational [Page 7] RFC 2666 Ethernet Chipset MIB August 1999 dot3ChipSetSeeq84C300 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 4-Port 84C300 Fast Ethernet Controller (MAC)." ::= { dot3ChipSetSeeq 6 } dot3ChipSetSeeq84301 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 4-Port 84301 Fast Ethernet Controller (MAC)." ::= { dot3ChipSetSeeq 7 } dot3ChipSetSeeq84302 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 4-Port 84302 Fast Ethernet Controller (MAC)." ::= { dot3ChipSetSeeq 8 } dot3ChipSetSeeq8100 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the SEEQ 8100 Gigabit Ethernet Controller (MAC & PCS)." ::= { dot3ChipSetSeeq 9 } dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } dot3ChipSetNational8390 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP8390 Network Interface Controller." ::= { dot3ChipSetNational 1 } dot3ChipSetNationalSonic OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83932 Systems-Oriented Network Interface Controller (SONIC)." ::= { dot3ChipSetNational 2 } dot3ChipSetNational83901 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83901 Serial Network Interface Controller (SNIC)." ::= { dot3ChipSetNational 3 } dot3ChipSetNational83902 OBJECT-IDENTITY Flick Informational [Page 8] RFC 2666 Ethernet Chipset MIB August 1999 STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83902 Serial Network Interface Controller for Twisted Pair (ST-NIC)." ::= { dot3ChipSetNational 4 } dot3ChipSetNational83905 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83905 AT Local Area Network Twisted-Pair Interface (AT/LANTIC)." ::= { dot3ChipSetNational 5 } dot3ChipSetNational83907 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83907 AT Twisted-Pair Enhanced Coaxial Network Interface Controller (AT/LANTIC II)." ::= { dot3ChipSetNational 6 } dot3ChipSetNational83916 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83916 Systems-Oriented Network Interface Controller (SONIC-16)." ::= { dot3ChipSetNational 7 } dot3ChipSetNational83934 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83934 Systems-Oriented Network Interface Controller with Twisted Pair Interface (SONIC-T)." ::= { dot3ChipSetNational 8 } dot3ChipSetNational83936 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the National Semiconductor DP83936AVUL Full-Duplex Systems- Oriented Network Interface Controller with Twisted Pair Interface (SONIC-T)." ::= { dot3ChipSetNational 9 } dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 } dot3ChipSetFujitsu86950 OBJECT-IDENTITY STATUS current Flick Informational [Page 9] RFC 2666 Ethernet Chipset MIB August 1999 DESCRIPTION "The authoritative identifier for the Fujitsu 86950 chip." ::= { dot3ChipSetFujitsu 1 } dot3ChipSetFujitsu86960 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Fujitsu MB86960 Network Interface Controller with Encoder/Decoder (NICE)." ::= { dot3ChipSetFujitsu 2 } dot3ChipSetFujitsu86964 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Fujitsu MB86964 Ethernet Controller with 10BASE-T Tranceiver." ::= { dot3ChipSetFujitsu 3 } dot3ChipSetFujitsu86965A OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Fujitsu MB86965A EtherCoupler Single-Chip Ethernet Controller." ::= { dot3ChipSetFujitsu 4 } dot3ChipSetFujitsu86965B OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Fujitsu MB86965B EtherCoupler Single-Chip Ethernet Controller (supports full-duplex)." ::= { dot3ChipSetFujitsu 5 } dot3ChipSetDigital OBJECT IDENTIFIER ::= { dot3ChipSets 6 } dot3ChipSetDigitalDC21040 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Digital Semiconductor DC21040 chip." ::= { dot3ChipSetDigital 1 } dot3ChipSetDigital21041 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Digital Semiconductor 21041 PCI Ethernet LAN Controller." ::= { dot3ChipSetDigital 2 } dot3ChipSetDigital21140 OBJECT-IDENTITY Flick Informational [Page 10] RFC 2666 Ethernet Chipset MIB August 1999 STATUS current DESCRIPTION "The authoritative identifier for the Digital Semiconductor 21140 PCI Fast Ethernet LAN Controller." ::= { dot3ChipSetDigital 3 } dot3ChipSetDigital21143 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Digital Semiconductor 21143 PCI/CardBus 10/100-Mb/s Ethernet LAN Controller." ::= { dot3ChipSetDigital 4 } dot3ChipSetDigital21340 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Digital Semiconductor 21340 10/100-MB/s managed buffered port switch." ::= { dot3ChipSetDigital 5 } dot3ChipSetDigital21440 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Digital Semiconductor 21440 Multiport 10/100Mbps Ethernet Controller." ::= { dot3ChipSetDigital 6 } dot3ChipSetDigital21540 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Digital Semiconductor 21540 PCI/CardBus Ethernet LAN Controller with Modem Interface." ::= { dot3ChipSetDigital 7 } dot3ChipSetTI OBJECT IDENTIFIER ::= { dot3ChipSets 7 } dot3ChipSetTIE100 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Texas Instruments TNETE100 ThunderLAN PCI Fast Ethernet Controller." ::= { dot3ChipSetTI 1 } dot3ChipSetTIE110 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Texas Instruments TNETE110 ThunderLAN PCI 10BASE-T Ethernet Adapter." Flick Informational [Page 11] RFC 2666 Ethernet Chipset MIB August 1999 ::= { dot3ChipSetTI 2 } dot3ChipSetTIX3100 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Texas Instruments TNETX3100 Desktop ThunderSWITCH 8/2." ::= { dot3ChipSetTI 3 } dot3ChipSetTIX3150 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Texas Instruments TNETX3150 ThunderSWITCH 12/3." ::= { dot3ChipSetTI 4 } dot3ChipSetTIX3270 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Texas Instruments TNETX3270 ThunderSWITCH 24/3." ::= { dot3ChipSetTI 5 } dot3ChipSetToshiba OBJECT IDENTIFIER ::= { dot3ChipSets 8 } dot3ChipSetToshibaTC35815F OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Toshiba TC35815F PCI-Based 100/10Mbps Ethernet Controller." ::= { dot3ChipSetToshiba 1 } dot3ChipSetLucent OBJECT IDENTIFIER ::= { dot3ChipSets 9 } dot3ChipSetLucentATT1MX10 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Lucent Technologies ATT1MX10 (Spinnaker) Quad MAC and Tranceiver for Ethernet Frame Switching." ::= { dot3ChipSetLucent 1 } dot3ChipSetLucentLUC3M08 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Lucent Technologies LUC3M08 Eight Ethernet MACs for 10/100 Mbits/s Frame Switching." ::= { dot3ChipSetLucent 2 } dot3ChipSetGalileo OBJECT IDENTIFIER ::= { dot3ChipSets 10 } Flick Informational [Page 12] RFC 2666 Ethernet Chipset MIB August 1999 dot3ChipSetGalileoGT48001 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Galileo Technology GT-48001A Switched Ethernet Controller." ::= { dot3ChipSetGalileo 1 } dot3ChipSetGalileoGT48002 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Galileo Technology GT-48002A Switched Fast Ethernet Controller." ::= { dot3ChipSetGalileo 2 } dot3ChipSetGalileoGT48004 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Galileo Technology GT-48004A Four Port Fast Ethernet Switch for Multiport 10/100BASE-X Systems." ::= { dot3ChipSetGalileo 3 } dot3ChipSetGalileoGT48207 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Galileo Technology GT-48207 Low-Cost 10 Port Switched Ethernet Controller for 10+10/100BASE-X." ::= { dot3ChipSetGalileo 4 } dot3ChipSetGalileoGT48208 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Galileo Technology GT-48208 Advanced 10 Port Switched Ethernet Controller for 10+10/100BASE-X." ::= { dot3ChipSetGalileo 5 } dot3ChipSetGalileoGT48212 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Galileo Technology GT-48212 Advanced 14 Port Switched Ethernet Controller for 10+10/100BASE-X." ::= { dot3ChipSetGalileo 6 } dot3ChipSetJato OBJECT IDENTIFIER ::= { dot3ChipSets 11 } dot3ChipSetJatoJT1001 OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the Jato Technologies JT1001 GigEMAC Server Flick Informational [Page 13] RFC 2666 Ethernet Chipset MIB August 1999 10/100/1000Mbps Ethernet Controller with PCI interface." ::= { dot3ChipSetJato 1 } dot3ChipSetXaQti OBJECT IDENTIFIER ::= { dot3ChipSets 12 } dot3ChipSetXaQtiXQ11800FP OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the XaQTI XQ11800FP XMAC II Gigabit Ethernet Media Access Controller." ::= { dot3ChipSetXaQti 1 } dot3ChipSetXaQtiXQ18110FP OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier for the XaQTI XQ18110FP GigaPower Protocol Accelerator." ::= { dot3ChipSetXaQti 2 } END 4. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Flick Informational [Page 14] RFC 2666 Ethernet Chipset MIB August 1999 5. Acknowledgements This document was produced by the Ethernet Interfaces and Hub MIB Working Group. 6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, May 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, STD 58, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, May 1999. Flick Informational [Page 15] RFC 2666 Ethernet Chipset MIB August 1999 [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, May 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, May 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, May 1999. [16] Flick, J. and J. Johnson, "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 2665, August 1999. 7. Security Considerations There are no management objects actually defined in this MIB module. It merely contains a list of OBJECT IDENTIFIER values for use in other MIB modules. As such, it does not, by itself, have any effect on the security of the Internet. The values in this module are expected to be used only for backwards compatability with the deprecated dot3StatsEtherChipSet object in the EtherLike-MIB [16]. That object may be considered sensitive in some environments, since it would allow an intruder to obtain information about which vendor's equipment is in use on the network. Therefore, it may be important in some environments, where the dot3StatsEtherChipSet object is implemented for backwards compatability, to control read access to that object and possibly to even encrypt the values of that object when sending it over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. Flick Informational [Page 16] RFC 2666 Ethernet Chipset MIB August 1999 It is then a customer/user responsibility to ensure that the SNMP entity giving access to a managed object whose values are defined in this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 8. Author's Address John Flick Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557 Phone: +1 916 785 4018 EMail: johnf@rose.hp.com Flick Informational [Page 17] RFC 2666 Ethernet Chipset MIB August 1999 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Flick Informational [Page 18] snmp-mibs-downloader-1.1/mibrfcs/rfc2677.txt0000644000000000000000000037524311402176071015605 0ustar Network Working Group M. Greene Request for Comments: 2677 Contractor Category: Standards Track J. Cucchiara IronBridge Networks J. Luciani Bay Networks August 1999 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Next Hop Resolution Protocol (NHRP) as defined in RFC 2332. Table of Contents 1 Introduction ................................................. 2 2 The SNMP Management Framework ................................ 2 3 Structure of the MIB ......................................... 3 3.1 The NHRP General Group ..................................... 3 3.1.1 The NHRP Cache Table ..................................... 4 3.1.2 The NHRP Purge Request Table ............................. 4 3.2 The NHRP Client Group ...................................... 4 3.2.1 The NHRP Client Table .................................... 4 3.2.2 The NHRP Client Registration Table ....................... 5 3.2.3 The NHRP Client NHS Table ................................ 5 3.2.4 The NHRP Client Statistics Table ......................... 5 3.3 The NHRP Server Group ...................................... 5 3.3.1 The NHRP Server Table .................................... 5 3.3.2 The NHRP Server Cache Table .............................. 5 3.3.3 The NHRP Server NHC Table ................................ 6 Greene, et al. Standards Track [Page 1] RFC 2677 NHRP MIB August 1999 3.3.4 The NHRP Server Statistics Table ......................... 6 4 NBMA Next Hop Resolution Protocol MIB Definitions ............ 6 5 IANA Considerations .......................................... 62 6 Security ..................................................... 62 7 Intellectual Property ........................................ 63 8 Acknowledgments .............................................. 63 9 References ................................................... 64 10 Authors' Addresses .......................................... 66 11 Full Copyright Statement .................................... 67 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Next Hop Resolution Protocol (NHRP) as defined in RFC 2332 [17]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [21]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. Greene, et al. Standards Track [Page 2] RFC 2677 NHRP MIB August 1999 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Structure of the MIB The NHRP MIB contains three groups: the General Group, the Client Group, and the Server Group. 3.1. The NHRP General Group The General Group contains objects that apply to both clients and servers -- in particular the nhrpNextIndex scalar object, the NHRP Cache Table and the NHRP Purge Request Table. The nhrpNextIndex scalar object is used to provide unique indices for the nhprClientIndex in the nhrpClientTable and the nhrpServerIndex in the nhrpServerTable. If used consistently, this object may prevent conflicts when multiple managers attempt to create rows simultaneously in the same table. Greene, et al. Standards Track [Page 3] RFC 2677 NHRP MIB August 1999 3.1.1. The NHRP Cache Table The NHRP Cache Table represents the internetwork layer address to NBMA address cache that is maintained by both NHRP clients and NHRP servers. The NHRP Cache Table contains an ifIndex as part of the Index Clause. This ifIndex represents the use of a generic ifIndex, such that the value of this ifIndex SHOULD reflect a specific NBMA subnetwork related interface as determined by an implementation. For example, assuming that the NBMA subnetwork is ATM, then it is up to the implementors of this MIB to determine their own ATM interface layering (assuming compliance with the IF-MIB, RFC 2233 [18] and the ATM-MIB, RFC 2515 [19]). In other words, assuming that the NBMA subnetwork is ATM, the ifIndex in the NHRP Cache Table would represent the ifIndex containing or consisting of the VC (or shortcut) denoted by this Table entry. The indexing scheme for the NHRP Cache Table is very similar to the MPC Ingress Cache Table and the MPS Ingress Cache Table in the Multiprotocol Over ATM (MPOA) MIB [23]. This MIB and the MPOA MIB were designed to be complementary and non-overlapping. The MPOA MIB should also support this MIB. The MPOA MIB was designed prior to this MIB, and was designed by the LANE/MPOA Working Group in the ATM FORUM. The indexing scheme of the NHRP Cache Table (and the NHRP Server Cache Table) reflect the indexing scheme of the MPC Ingress Cache Table and the MPS Ingress Cache Table. Although, other indexing schemes could have been used for the NHRP Cache Table, a consistent indexing scheme between these tables was thought to be more advantageous from an implementation standpoint. 3.1.2. The NHRP Purge Request Table The NHRP Purge Request Table is a way to track Purge Request Information. 3.2. The NHRP Client Group The Client Group contains objects that only apply to NHRP clients (NHCs). 3.2.1. The NHRP Client Table The NHRP Client Table contains entries for NHRP Next Hop Clients (NHCs) associated with this agent. Each row in the table represents a single NHC. The RequestID used in Registration requests needs to be saved to non-volatile storage. Depending upon the implementation, Greene, et al. Standards Track [Page 4] RFC 2677 NHRP MIB August 1999 this may or may not impact how the StorageType is used. For a complete description of how the Registration RequestID is used, see Section 5.2.3 of [17]. 3.2.2. The NHRP Client Registration Table The NHRP Client Registration Table contains information on registration requests which need to be maintained by the Clients. Each entry in this table represents a single registration request. Note: since the NHRP specification does not mandate a refresh algorithm, this table omits refresh information, however, this table does contain information for all the registration requests which need to be maintained by the NHRP Clients. 3.2.3. The NHRP Client NHS Table The NHRP Client NHS Table contains the NBMA subnetwork addresses of servers configured for use by the client. By default, the agent will add an entry to this table which corresponds to the client's default router. 3.2.4. The NHRP Client Statistics Table The NHRP Client Statistics Table contains NHRP statistics maintained by a client. These statistics include counters on requests and replies, as well as counters for errors which are encountered by the Clients. 3.3. The NHRP Server Group The Server Group contains objects that only apply to NHRP servers (NHSes). 3.3.1. The NHRP Server Table The NHRP Server Table contains entries for each server associated with this agent. 3.3.2. The NHRP Server Cache Table The NHRP Server Cache Table contains additional objects that a server keeps for each entry in its cache. This table extends the NHRP Cache Table defined in the General Group. Greene, et al. Standards Track [Page 5] RFC 2677 NHRP MIB August 1999 3.3.3. The NHRP Server NHC Table This table contains information about all the Clients known to the Servers. 3.3.4. The NHRP Server Statistics Table The NHRP Server Statistics Table contains NHRP statistics maintained by a server. These statistics include counters on requests and replies, as well as counters for errors which are encountered by the Servers. 4. NBMA Next Hop Resolution Protocol MIB Definitions NHRP-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, mib-2, Integer32, Counter32, Unsigned32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, TimeStamp FROM SNMPv2-TC ifIndex FROM IF-MIB AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB ; nhrpMIB MODULE-IDENTITY LAST-UPDATED "9908260000Z" -- August 26, 1999 ORGANIZATION "Internetworking Over NBMA (ion) Working Group" CONTACT-INFO "Maria Greene (maria@xedia.com) Contractor Joan Cucchiara (joan@ironbridgenetworks.com) IronBridge Networks James V. Luciani (luciani@baynetworks.com) Bay Networks" Greene, et al. Standards Track [Page 6] RFC 2677 NHRP MIB August 1999 DESCRIPTION "This MIB contains managed object definitions for the Next Hop Resolution Procol, NHRP, as defined in RFC 2332 [17]." -- revision history REVISION "9908260000Z" -- August 26, 1999 DESCRIPTION "Initial version, published as RFC 2677." ::= { mib-2 71 } --**************************************************************** -- NHRP Textual Conventions --**************************************************************** NhrpGenAddr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of an internetwork layer or NBMA address." SYNTAX OCTET STRING (SIZE (0..64)) nhrpObjects OBJECT IDENTIFIER ::= { nhrpMIB 1 } --**************************************************************** -- NHRP General (Client and Server) Objects --**************************************************************** nhrpGeneralObjects OBJECT IDENTIFIER ::= { nhrpObjects 1 } -- -- The following scalar is to be used to -- provided indices for the -- nhrpClientTable, and/or the nhrpServerTable. -- nhrpNextIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This scalar is used for creating rows in the nhrpClientTable and the nhrpServerTable. The value of this variable is a currently unused value for nhrpClientIndex and nhrpServerIndex. Greene, et al. Standards Track [Page 7] RFC 2677 NHRP MIB August 1999 The value returned when reading this variable must be unique for the NHC's and NHS's indices associated with this row. Subsequent attempts to read this variable must return different values. NOTE: this object exists in the General Group because it is to be used in establishing rows in the nhrpClientTable and the nhrpServerTable. In other words, the value retrieved from this object could become the value of nhrpClientIndex and nhprServerIndex. In the situation of an agent re-initialization the value of this object must be saved in non-volatile storage. This variable will return the special value 0 if no new rows can be created." ::= { nhrpGeneralObjects 1 } -- -- The NHRP Cache Table -- nhrpCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains mappings between internetwork layer addresses and NBMA subnetwork layer addresses." ::= { nhrpGeneralObjects 2 } nhrpCacheEntry OBJECT-TYPE SYNTAX NhrpCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A cached mapping between an internetwork layer address and an NBMA address. Entries can be created by the network administrator using the nhrpCacheRowStatus column, or they may be added dynamically based on protocol operation (including NHRP, SCSP, and others, such as ATMARP). When created based by NHRP protocol operations this entry is largely based on contents contained in the Client Information Entry (CIE). Greene, et al. Standards Track [Page 8] RFC 2677 NHRP MIB August 1999 Zero or more Client Information Entries (CIEs) may be included in the NHRP Packet. For a complete description of the CIE, refer to Section 5.2.0.1 of RFC 2332 [17]." INDEX { nhrpCacheInternetworkAddrType, nhrpCacheInternetworkAddr, ifIndex, nhrpCacheIndex } ::= { nhrpCacheTable 1 } NhrpCacheEntry ::= SEQUENCE { nhrpCacheInternetworkAddrType AddressFamilyNumbers, nhrpCacheInternetworkAddr NhrpGenAddr, nhrpCacheIndex Unsigned32, nhrpCachePrefixLength Integer32, nhrpCacheNextHopInternetworkAddr NhrpGenAddr, nhrpCacheNbmaAddrType AddressFamilyNumbers, nhrpCacheNbmaAddr NhrpGenAddr, nhrpCacheNbmaSubaddr NhrpGenAddr, nhrpCacheType INTEGER, nhrpCacheState INTEGER, nhrpCacheHoldingTimeValid TruthValue, nhrpCacheHoldingTime Unsigned32, nhrpCacheNegotiatedMtu Integer32, nhrpCachePreference Integer32, nhrpCacheStorageType StorageType, nhrpCacheRowStatus RowStatus } nhrpCacheInternetworkAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS not-accessible STATUS current DESCRIPTION "The internetwork layer address type of this Next Hop Resolution Cache entry. The value of this object indicates how to interpret the values of nhrpCacheInternetworkAddr and nhrpCacheNextHopInternetworkAddr." ::= { nhrpCacheEntry 1 } nhrpCacheInternetworkAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS not-accessible STATUS current Greene, et al. Standards Track [Page 9] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The value of the internetwork address of the destination." ::= { nhrpCacheEntry 2 } nhrpCacheIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier for this entry that has local significance within the scope of the General Group. This identifier is used here to uniquely identify this row, and also used in the 'nhrpPurgeTable' for the value of the 'nhrpPurgeCacheIdentifier'." ::= { nhrpCacheEntry 3 } nhrpCachePrefixLength OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bits that define the internetwork layer prefix associated with the nhrpCacheInternetworkAddr." ::= { nhrpCacheEntry 4 } nhrpCacheNextHopInternetworkAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the internetwork address of the next hop." ::= { nhrpCacheEntry 5 } nhrpCacheNbmaAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The NBMA address type. The value of this object indicates how to interpret the values of nhrpCacheNbmaAddr and nhrpCacheNbmaSubaddr." ::= { nhrpCacheEntry 6 } Greene, et al. Standards Track [Page 10] RFC 2677 NHRP MIB August 1999 nhrpCacheNbmaAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the NBMA subnetwork address of the next hop." ::= { nhrpCacheEntry 7 } nhrpCacheNbmaSubaddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the NBMA subaddress of the next hop. If there is no subaddress concept for the NBMA address family, this value will be a zero-length OCTET STRING." ::= { nhrpCacheEntry 8 } nhrpCacheType OBJECT-TYPE SYNTAX INTEGER { other(1), register(2), resolveAuthoritative(3), resoveNonauthoritative(4), transit(5), administrativelyAdded(6), atmarp(7), scsp(8) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of how this cache entry was created. The values are: 'other(1)' The entry was added by some other means. 'register(2)' In a server, added based on a client registration. 'resolveAuthoritative(3)' In a client, added based on receiving an Authoritative NHRP Resolution Reply. Greene, et al. Standards Track [Page 11] RFC 2677 NHRP MIB August 1999 'resolveNonauthoritative(4)' In a client, added based on receiving a Nonauthoritative NHRP Resolution Reply. 'transit(5)' In a transit server, added by examining a forwarded NHRP packet. 'administrativelyAdded(6)' In a client or server, manually added by the administrator. The StorageType of this entry is reflected in 'nhrpCacheStorageType'. 'atmarp(7)' The entry was added due to an ATMARP. 'scsp(8)' The entry was added due to SCSP. When the entry is under creation using the nhrpCacheRowStatus column, the only value that can be specified by the administrator is 'administrativelyAdded'. Attempting to set any other value will cause an 'inconsistentValue' error. The value cannot be modified once the entry is active." ::= { nhrpCacheEntry 9 } nhrpCacheState OBJECT-TYPE SYNTAX INTEGER { incomplete(1), ackReply(2), nakReply(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the state of this entry. The values are: 'incomplete(1)' The client has sent a NHRP Resolution Request but has not yet received the NHRP Resolution Reply. Greene, et al. Standards Track [Page 12] RFC 2677 NHRP MIB August 1999 'ackReply(2)' For a client or server, this is a cached valid mapping. 'nakReply(3)' For a client or server, this is a cached NAK mapping." ::= { nhrpCacheEntry 10 } nhrpCacheHoldingTimeValid OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "True(1) is returned if the value of 'nhrpCacheType' is not 'administrativelyAdded'. Since the value of 'nhrpCacheType' was not configured by a user, the value of 'nhrpCacheHoldingTime' is considered valid. In other words, the value of 'nhrpCacheHoldingTime' represents the Holding Time for the cache Entry. If 'nhrpCacheType has been configured by a user, (i.e. the value of 'nhrpCacheType' is 'administrativelyAdded') then false(2) will be returned. This indicates that the value of 'nhrpCacheHoldingTime' is undefined because this row could possibly be backed up in nonvolatile storage." ::= { nhrpCacheEntry 11 } nhrpCacheHoldingTime OBJECT-TYPE SYNTAX Unsigned32(0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of 'nhrpCacheHoldingTimeValid is true(1) then this object represents the number of seconds that the cache entry will remain in this table. When this value reaches 0 (zero) the row should be deleted. If the value of 'nhrpCacheHoldingTimeValid is false(2) then this object is undefined." ::= { nhrpCacheEntry 12 } Greene, et al. Standards Track [Page 13] RFC 2677 NHRP MIB August 1999 nhrpCacheNegotiatedMtu OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum transmission unit (MTU) that was negotiated or registered for this entity. In other words, this is the actual MTU being used." ::= { nhrpCacheEntry 13 } nhrpCachePreference OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "An object which reflects the Preference value of the Client Information Entry (CIE). Zero or more Client Information Entries (CIEs) may be included in the NHRP Packet. One of the fields in the CIE is the Preference. For a complete description of the CIE, refer to Section 5.2.0.1 of RFC 2332 [17]." REFERENCE "Section 5.2.0.1 Mandatory Part Format, RFC 2332 [17]." ::= { nhrpCacheEntry 14 } nhrpCacheStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This value only has meaning when the 'nhrpCacheType' has the value of 'administrativelyAdded'. When the row is created due to being 'administrativelyAdded', this object reflects whether this row is kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. If the value of 'nhrpCacheType' has a value which is not 'administrativelyAdded, then the value of this object is 'other(1)'." DEFVAL { nonVolatile } ::= { nhrpCacheEntry 15 } Greene, et al. Standards Track [Page 14] RFC 2677 NHRP MIB August 1999 nhrpCacheRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { nhrpCacheEntry 16 } -- -- The NHRP Purge Request Table -- nhrpPurgeReqTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpPurgeReqEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table will track Purge Request Information." ::= { nhrpGeneralObjects 3 } nhrpPurgeReqEntry OBJECT-TYPE SYNTAX NhrpPurgeReqEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information regarding a Purge Request." INDEX { nhrpPurgeIndex } ::= { nhrpPurgeReqTable 1 } NhrpPurgeReqEntry ::= SEQUENCE { nhrpPurgeIndex Unsigned32, nhrpPurgeCacheIdentifier Unsigned32, nhrpPurgePrefixLength Integer32, nhrpPurgeRequestID Unsigned32, nhrpPurgeReplyExpected TruthValue, nhrpPurgeRowStatus RowStatus } nhrpPurgeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index for this entry that has local significance within the scope of this table." ::= { nhrpPurgeReqEntry 1 } Greene, et al. Standards Track [Page 15] RFC 2677 NHRP MIB August 1999 nhrpPurgeCacheIdentifier OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies which row in 'nhrpCacheTable' is being purged. This object should have the same value as the 'nhrpCacheIndex' in the 'nhrpCacheTable'." ::= { nhrpPurgeReqEntry 2 } nhrpPurgePrefixLength OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "In the case of NHRP Purge Requests, this specifies the equivalence class of addresses which match the first 'Prefix Length' bit positions of the Client Protocol Address specified in the Client Information Entry (CIE)." ::= { nhrpPurgeReqEntry 3 } nhrpPurgeRequestID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Request ID used in the purge request." ::= { nhrpPurgeReqEntry 4 } nhrpPurgeReplyExpected OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether this Purge Request has the 'N' Bit cleared (off)." ::= { nhrpPurgeReqEntry 5 } nhrpPurgeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { nhrpPurgeReqEntry 6 } Greene, et al. Standards Track [Page 16] RFC 2677 NHRP MIB August 1999 --**************************************************************** -- NHRP Client Objects --**************************************************************** nhrpClientObjects OBJECT IDENTIFIER ::= { nhrpObjects 2 } -- -- The NHRP Client Table -- nhrpClientTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about NHRP clients (NHCs) managed by this agent." ::= { nhrpClientObjects 1 } nhrpClientEntry OBJECT-TYPE SYNTAX NhrpClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single NHC." INDEX { nhrpClientIndex } ::= { nhrpClientTable 1 } NhrpClientEntry ::= SEQUENCE { nhrpClientIndex Unsigned32, nhrpClientInternetworkAddrType AddressFamilyNumbers, nhrpClientInternetworkAddr NhrpGenAddr, nhrpClientNbmaAddrType AddressFamilyNumbers, nhrpClientNbmaAddr NhrpGenAddr, nhrpClientNbmaSubaddr NhrpGenAddr, nhrpClientInitialRequestTimeout Integer32, nhrpClientRegistrationRequestRetries Integer32, nhrpClientResolutionRequestRetries Integer32, nhrpClientPurgeRequestRetries Integer32, nhrpClientDefaultMtu Unsigned32, nhrpClientHoldTime Unsigned32, nhrpClientRequestID Unsigned32, nhrpClientStorageType StorageType, nhrpClientRowStatus RowStatus } Greene, et al. Standards Track [Page 17] RFC 2677 NHRP MIB August 1999 nhrpClientIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier for the NHRP client that is unique within the scope of this agent. The 'nhrpNextIndex' value should be consulted (read), prior to creating a row in this table, and the value returned from reading 'nhrpNextIndex' should be used as this object's value." ::= { nhrpClientEntry 1 } nhrpClientInternetworkAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the internetwork layer address of this client. This object indicates how the value of nhrpClientInternetworkAddr is to be interpreted." ::= { nhrpClientEntry 2 } nhrpClientInternetworkAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the internetwork layer address of this client." ::= { nhrpClientEntry 3 } nhrpClientNbmaAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the NBMA subnetwork address of this client. This object indicates how the values of nhrpClientNbmaAddr and nhrpClientNbmaSubaddr are to be interpreted." ::= { nhrpClientEntry 4 } nhrpClientNbmaAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current Greene, et al. Standards Track [Page 18] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The NBMA subnetwork address of this client." ::= { nhrpClientEntry 5 } nhrpClientNbmaSubaddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The NBMA subaddress of this client. For NBMA address families without a subaddress concept, this will be a zero-length OCTET STRING." ::= { nhrpClientEntry 6 } nhrpClientInitialRequestTimeout OBJECT-TYPE SYNTAX Integer32 (1..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that the client will wait before timing out an NHRP initial request. This object only has meaning for the initial timeout period." DEFVAL { 10 } ::= { nhrpClientEntry 7 } nhrpClientRegistrationRequestRetries OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times the client will retry the registration request before failure. A value of 0 means don't retry. A value of 65535 means retry forever." DEFVAL { 3 } ::= { nhrpClientEntry 8 } nhrpClientResolutionRequestRetries OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times the client will retry the resolution request before failure. A value of 0 means don't retry. A value of 65535 means retry forever." DEFVAL { 3 } ::= { nhrpClientEntry 9 } Greene, et al. Standards Track [Page 19] RFC 2677 NHRP MIB August 1999 nhrpClientPurgeRequestRetries OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times the client will retry a purge request before failure. A value of 0 means don't retry. A value of 65535 means retry forever." DEFVAL { 3 } ::= { nhrpClientEntry 10 } nhrpClientDefaultMtu OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum transmission unit (MTU) of the LIS/LAG which this client should use. This object will be initialized by the agent to the default MTU of the LIS/LAG (which is 9180) unless a different MTU value is specified during creation of this Client." REFERENCE "RFC 2225 [25], Classical IP and ARP over ATM, Section 7, DEFAULT VALUE FOR IP MTU OVER ATM AAL5." DEFVAL { 9180 } ::= { nhrpClientEntry 11 } nhrpClientHoldTime OBJECT-TYPE SYNTAX Unsigned32(0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The hold time the client will register." DEFVAL { 900 } ::= { nhrpClientEntry 12 } nhrpClientRequestID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Request ID used to register this client with its server. According to Section 5.2.3 of the NHRP Specification, RFC 2332 [17], the Request ID must be kept in non-volatile storage, so that if an NHC crashes and re-initializes, it will use a different Greene, et al. Standards Track [Page 20] RFC 2677 NHRP MIB August 1999 Request ID during the registration process when reregistering with the same NHS." REFERENCE "Section 5.2.3 NHRP Registration Request, RFC 2332 [17]." ::= { nhrpClientEntry 13 } nhrpClientStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row is kept in volatile storage and lost upon a Client crash or reboot situation, or if this row is backed up by nonvolatile or permanent storage." DEFVAL { nonVolatile } ::= { nhrpClientEntry 14 } nhrpClientRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { nhrpClientEntry 15 } -- -- The NHRP Client Registration Table -- nhrpClientRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpClientRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Registration Request Information that needs to be maintained by the NHCs (clients)." REFERENCE "Section 5.2.3 NHRP Registration Request, RFC 2332 [17]." ::= { nhrpClientObjects 2 } nhrpClientRegistrationEntry OBJECT-TYPE SYNTAX NhrpClientRegistrationEntry MAX-ACCESS not-accessible STATUS current Greene, et al. Standards Track [Page 21] RFC 2677 NHRP MIB August 1999 DESCRIPTION "An NHC needs to maintain registration request information between the NHC and the NHS. An entry in this table represents information for a single registration request." INDEX { nhrpClientIndex, nhrpClientRegIndex } ::= { nhrpClientRegistrationTable 1 } NhrpClientRegistrationEntry ::= SEQUENCE { nhrpClientRegIndex Unsigned32, nhrpClientRegUniqueness INTEGER, nhrpClientRegState INTEGER, nhrpClientRegRowStatus RowStatus } nhrpClientRegIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier for this entry such that it identifies a specific Registration Request from the NHC represented by the nhrpClientIndex." ::= { nhrpClientRegistrationEntry 1 } nhrpClientRegUniqueness OBJECT-TYPE SYNTAX INTEGER { requestUnique(1), requestNotUnique(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The Uniqueness indicator for this Registration Request. If this object has the value of requestUnique(1), then the Uniqueness bit is set in the the NHRP Registration Request represented by this row. The value cannot be changed once the row is created." ::= { nhrpClientRegistrationEntry 2 } nhrpClientRegState OBJECT-TYPE SYNTAX INTEGER { other(1), registering(2), ackRegisterReply(3), nakRegisterReply(4) Greene, et al. Standards Track [Page 22] RFC 2677 NHRP MIB August 1999 } MAX-ACCESS read-only STATUS current DESCRIPTION "The registration state of this client. The values are: 'other(1)' The state of the registration request is not one of 'registering', 'ackRegisterReply' or 'nakRegisterReply'. 'registering(2)' A registration request has been issued and a registration reply is expected. 'ackRegisterReply(3)' A positive registration reply has been received. 'nakRegisterReply(4)' The client has received a negative registration reply (NAK)." ::= { nhrpClientRegistrationEntry 3 } nhrpClientRegRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { nhrpClientRegistrationEntry 4 } -- -- The NHRP Client->Server Table -- nhrpClientNhsTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpClientNhsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of NHSes that are available for use by this NHC (client). By default, the agent will add an entry to this table that corresponds to the client's default router." ::= { nhrpClientObjects 3 } Greene, et al. Standards Track [Page 23] RFC 2677 NHRP MIB August 1999 nhrpClientNhsEntry OBJECT-TYPE SYNTAX NhrpClientNhsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An NHS that may be used by an NHC." INDEX { nhrpClientIndex, nhrpClientNhsIndex } ::= { nhrpClientNhsTable 1 } NhrpClientNhsEntry ::= SEQUENCE { nhrpClientNhsIndex Unsigned32, nhrpClientNhsInternetworkAddrType AddressFamilyNumbers, nhrpClientNhsInternetworkAddr NhrpGenAddr, nhrpClientNhsNbmaAddrType AddressFamilyNumbers, nhrpClientNhsNbmaAddr NhrpGenAddr, nhrpClientNhsNbmaSubaddr NhrpGenAddr, nhrpClientNhsInUse TruthValue, nhrpClientNhsRowStatus RowStatus } nhrpClientNhsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier for an NHS available to an NHC." ::= { nhrpClientNhsEntry 1 } nhrpClientNhsInternetworkAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the internetwork layer address of the NHRP server represented in this entry. This object indicates how the value of nhrpClientNhsInternetworkAddr is to be interpreted." ::= { nhrpClientNhsEntry 2 } nhrpClientNhsInternetworkAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the destination internetwork layer address of the NHRP server represented by this Greene, et al. Standards Track [Page 24] RFC 2677 NHRP MIB August 1999 entry. If this value is not known, this will be a zero-length OCTET STRING." ::= { nhrpClientNhsEntry 3 } nhrpClientNhsNbmaAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the NBMA subnetwork address of the NHRP Server represented by this entry. This object indicates how the values of nhrpClientNhsNbmaAddr and nhrpClientNhsNbmaSubaddr are to be interpreted." ::= { nhrpClientNhsEntry 4 } nhrpClientNhsNbmaAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The NBMA subnetwork address of the NHS. The type of the address is indicated by the corresponding value of nhrpClientNhsNbmaAddrType." ::= { nhrpClientNhsEntry 5 } nhrpClientNhsNbmaSubaddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The NBMA subaddress of the NHS. For NMBA address families that do not have the concept of subaddress, this will be a zero-length OCTET STRING." ::= { nhrpClientNhsEntry 6 } nhrpClientNhsInUse OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this NHS is in use by the NHC." ::= { nhrpClientNhsEntry 7 } nhrpClientNhsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Greene, et al. Standards Track [Page 25] RFC 2677 NHRP MIB August 1999 DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { nhrpClientNhsEntry 8 } -- -- The NHRP Client StatisticsTable -- nhrpClientStatTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpClientStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistics collected by NHRP clients." ::= { nhrpClientObjects 4 } nhrpClientStatEntry OBJECT-TYPE SYNTAX NhrpClientStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics collected by a NHRP client." INDEX { nhrpClientIndex } ::= { nhrpClientStatTable 1 } NhrpClientStatEntry ::= SEQUENCE { nhrpClientStatTxResolveReq Counter32, nhrpClientStatRxResolveReplyAck Counter32, nhrpClientStatRxResolveReplyNakProhibited Counter32, nhrpClientStatRxResolveReplyNakInsufResources Counter32, nhrpClientStatRxResolveReplyNakNoBinding Counter32, nhrpClientStatRxResolveReplyNakNotUnique Counter32, nhrpClientStatTxRegisterReq Counter32, nhrpClientStatRxRegisterAck Counter32, nhrpClientStatRxRegisterNakProhibited Counter32, nhrpClientStatRxRegisterNakInsufResources Counter32, nhrpClientStatRxRegisterNakAlreadyReg Counter32, nhrpClientStatRxPurgeReq Counter32, nhrpClientStatTxPurgeReq Counter32, nhrpClientStatRxPurgeReply Counter32, nhrpClientStatTxPurgeReply Counter32, nhrpClientStatTxErrorIndication Counter32, nhrpClientStatRxErrUnrecognizedExtension Counter32, nhrpClientStatRxErrLoopDetected Counter32, Greene, et al. Standards Track [Page 26] RFC 2677 NHRP MIB August 1999 nhrpClientStatRxErrProtoAddrUnreachable Counter32, nhrpClientStatRxErrProtoError Counter32, nhrpClientStatRxErrSduSizeExceeded Counter32, nhrpClientStatRxErrInvalidExtension Counter32, nhrpClientStatRxErrAuthenticationFailure Counter32, nhrpClientStatRxErrHopCountExceeded Counter32, nhrpClientStatDiscontinuityTime TimeStamp } nhrpClientStatTxResolveReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Resolution Requests transmitted by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 1 } nhrpClientStatRxResolveReplyAck OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of positively acknowledged NHRP Resolution Replies received by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 2 } nhrpClientStatRxResolveReplyNakProhibited OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Resolution Replies received by this client that contained the code indicating 'Administratively Prohibited'. Greene, et al. Standards Track [Page 27] RFC 2677 NHRP MIB August 1999 Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 3 } nhrpClientStatRxResolveReplyNakInsufResources OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Resolution Replies received by this client that contained the code indicating 'Insufficient Resources'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 4 } nhrpClientStatRxResolveReplyNakNoBinding OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Resolution Replies received by this client that contained the code indicating 'No Internetworking Layer Address to NBMA Address Binding Exists'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 5 } nhrpClientStatRxResolveReplyNakNotUnique OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Greene, et al. Standards Track [Page 28] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The number of NAKed NHRP Resolution Replies received by this client that contained the code indicating 'Binding Exists But Is Not Unique'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 6 } nhrpClientStatTxRegisterReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Registration Requests transmitted by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 7 } nhrpClientStatRxRegisterAck OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of positively acknowledged NHRP Registration Replies received by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 8 } nhrpClientStatRxRegisterNakProhibited OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Greene, et al. Standards Track [Page 29] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The number of NAKed NHRP Registration Replies received by this client that contained the code indicating 'Administratively Prohibited'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 9 } nhrpClientStatRxRegisterNakInsufResources OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Registration Replies received by this client that contained the code indicating 'Insufficient Resources'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 10 } nhrpClientStatRxRegisterNakAlreadyReg OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Registration Replies received by this client that contained the code indicating 'Unique Internetworking Layer Address Already Registered'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 11 } nhrpClientStatRxPurgeReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Greene, et al. Standards Track [Page 30] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The number of NHRP Purge Requests received by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 12 } nhrpClientStatTxPurgeReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Requests transmitted by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 13 } nhrpClientStatRxPurgeReply OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Replies received by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 14 } nhrpClientStatTxPurgeReply OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Replies transmitted by this client. Greene, et al. Standards Track [Page 31] RFC 2677 NHRP MIB August 1999 Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." ::= { nhrpClientStatEntry 15 } nhrpClientStatTxErrorIndication OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this client. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 16 } nhrpClientStatRxErrUnrecognizedExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'Unrecognized Extension'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 17 } nhrpClientStatRxErrLoopDetected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Greene, et al. Standards Track [Page 32] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'NHRP Loop Detected'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 18 } nhrpClientStatRxErrProtoAddrUnreachable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'Protocol Address Unreachable'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 19 } nhrpClientStatRxErrProtoError OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'Protocol Error'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 20 } Greene, et al. Standards Track [Page 33] RFC 2677 NHRP MIB August 1999 nhrpClientStatRxErrSduSizeExceeded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'NHRP SDU Size Exceeded'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 21 } nhrpClientStatRxErrInvalidExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'Invalid Extension'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 22 } nhrpClientStatRxErrAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'Authentication Failure'. Greene, et al. Standards Track [Page 34] RFC 2677 NHRP MIB August 1999 Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 23 } nhrpClientStatRxErrHopCountExceeded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this client with the error code 'Hop Count Exceeded'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Client re-initialization and at other times as indicated by the value of nhrpClientStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpClientStatEntry 24 } nhrpClientStatDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this Client's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem or the NHRP Client re-initialization associated with this entry, then this object contains a zero value." REFERENCE "RFC 2233 [18]." ::= { nhrpClientStatEntry 25 } Greene, et al. Standards Track [Page 35] RFC 2677 NHRP MIB August 1999 --**************************************************************** -- NHRP Server Objects --**************************************************************** nhrpServerObjects OBJECT IDENTIFIER ::= { nhrpObjects 3 } -- -- The NHRP Next Hop Server Table -- nhrpServerTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information for a set of NHSes associated with this agent." ::= { nhrpServerObjects 1 } nhrpServerEntry OBJECT-TYPE SYNTAX NhrpServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single NHS." INDEX { nhrpServerIndex } ::= { nhrpServerTable 1 } NhrpServerEntry ::= SEQUENCE { nhrpServerIndex Unsigned32, nhrpServerInternetworkAddrType AddressFamilyNumbers, nhrpServerInternetworkAddr NhrpGenAddr, nhrpServerNbmaAddrType AddressFamilyNumbers, nhrpServerNbmaAddr NhrpGenAddr, nhrpServerNbmaSubaddr NhrpGenAddr, nhrpServerStorageType StorageType, nhrpServerRowStatus RowStatus } nhrpServerIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier for the server that is unique within the scope of this agent." ::= { nhrpServerEntry 1 } Greene, et al. Standards Track [Page 36] RFC 2677 NHRP MIB August 1999 nhrpServerInternetworkAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the internetwork layer address of this server. This object is used to interpret the value of nhrpServerInternetworkAddr." ::= { nhrpServerEntry 2 } nhrpServerInternetworkAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the internetwork layer address of this server." ::= { nhrpServerEntry 3 } nhrpServerNbmaAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the NBMA subnetwork address of this server. This object is used to interpret the value of nhrpServerNbmaAddr." ::= { nhrpServerEntry 4 } nhrpServerNbmaAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the NBMA subnetwork address of this server." ::= { nhrpServerEntry 5 } nhrpServerNbmaSubaddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the NBMA subaddress of this server. For NBMA address families without a subaddress concept, this will be a zero-length OCTET STRING." ::= { nhrpServerEntry 6 } Greene, et al. Standards Track [Page 37] RFC 2677 NHRP MIB August 1999 nhrpServerStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row is kept in volatile storage and lost upon a Server crash or reboot situation, or if this row is backed up by nonvolatile or permanent storage." DEFVAL { nonVolatile } ::= { nhrpServerEntry 7 } nhrpServerRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { nhrpServerEntry 8 } -- -- The Server Cache Table -- nhrpServerCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpServerCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table extends the nhrpCacheTable for NHSes. If the nhrpCacheTable has a row added due to an NHS or based on information regarding an NHS then a row is also added in this table. The rows in this table will be created when rows in the nhrpCacheTable are created. However, there may be rows created in the nhrpCacheTable which do not have corresponding rows in this table. For example, if the nhrpCacheTable has a row added due to a Next Hop Client which is co-resident on the same device as the NHS, a row will not be added to this table." ::= { nhrpServerObjects 2 } nhrpServerCacheEntry OBJECT-TYPE SYNTAX NhrpServerCacheEntry MAX-ACCESS not-accessible STATUS current Greene, et al. Standards Track [Page 38] RFC 2677 NHRP MIB August 1999 DESCRIPTION "Additional information kept by a NHS for a relevant Next Hop Resolution Cache entry." INDEX { nhrpCacheInternetworkAddrType, nhrpCacheInternetworkAddr, ifIndex, nhrpCacheIndex } ::= { nhrpServerCacheTable 1 } NhrpServerCacheEntry ::= SEQUENCE { nhrpServerCacheAuthoritative TruthValue, nhrpServerCacheUniqueness TruthValue } nhrpServerCacheAuthoritative OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this cache entry is authoritative, which means the entry was added because of a direct registration request with this server or by Server Cache Synchronization Protocol (SCSP) from an authoritative source." ::= { nhrpServerCacheEntry 1 } nhrpServerCacheUniqueness OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The Uniqueness indicator for this cache entry used in duplicate address detection. This value cannot be changed after the entry is active." ::= { nhrpServerCacheEntry 2 } -- -- The NHRP Server->Client Table -- nhrpServerNhcTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpServerNhcEntry MAX-ACCESS not-accessible STATUS current Greene, et al. Standards Track [Page 39] RFC 2677 NHRP MIB August 1999 DESCRIPTION "A table of NHCs that are available for use by this NHS (Server)." REFERENCE "Section 4 Configuration (Next Hop Servers), RFC 2332 [17]." ::= { nhrpServerObjects 3 } nhrpServerNhcEntry OBJECT-TYPE SYNTAX NhrpServerNhcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An NHC that may be used by an NHS." INDEX { nhrpServerIndex, nhrpServerNhcIndex } ::= { nhrpServerNhcTable 1 } NhrpServerNhcEntry ::= SEQUENCE { nhrpServerNhcIndex Unsigned32, nhrpServerNhcPrefixLength Integer32, nhrpServerNhcInternetworkAddrType AddressFamilyNumbers, nhrpServerNhcInternetworkAddr NhrpGenAddr, nhrpServerNhcNbmaAddrType AddressFamilyNumbers, nhrpServerNhcNbmaAddr NhrpGenAddr, nhrpServerNhcNbmaSubaddr NhrpGenAddr, nhrpServerNhcInUse TruthValue, nhrpServerNhcRowStatus RowStatus } nhrpServerNhcIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier for an NHC available to an NHS." ::= { nhrpServerNhcEntry 1 } nhrpServerNhcPrefixLength OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of bits that define the internetwork layer prefix associated with the nhrpServerNhcInternetworkAddr." ::= { nhrpServerNhcEntry 2 } Greene, et al. Standards Track [Page 40] RFC 2677 NHRP MIB August 1999 nhrpServerNhcInternetworkAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the internetwork layer address of the NHRP Client represented in this entry. This object indicates how the value of nhrpServerNhcInternetworkAddr is to be interpreted." ::= { nhrpServerNhcEntry 3 } nhrpServerNhcInternetworkAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the internetwork layer address of the NHRP Client represented by this entry. If this value is not known, this will be a zero-length OCTET STRING." ::= { nhrpServerNhcEntry 4 } nhrpServerNhcNbmaAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the NBMA subnetwork address of the NHRP Client represented by this entry. This object indicates how the values of nhrpServerNhcNbmaAddr and nhrpServerNhcNbmaSubaddr are to be interpreted." ::= { nhrpServerNhcEntry 5 } nhrpServerNhcNbmaAddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "The NBMA subnetwork address of the NHC. The type of the address is indicated by the corresponding value of nhrpServerNbmaAddrType." ::= { nhrpServerNhcEntry 6 } nhrpServerNhcNbmaSubaddr OBJECT-TYPE SYNTAX NhrpGenAddr MAX-ACCESS read-create STATUS current Greene, et al. Standards Track [Page 41] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The NBMA subaddress of the NHC. For NMBA address familes that do not have the concept of subaddress, this will be a zero-length OCTET STRING." ::= { nhrpServerNhcEntry 7 } nhrpServerNhcInUse OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this NHC is in use by the NHS." ::= { nhrpServerNhcEntry 8 } nhrpServerNhcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention." ::= { nhrpServerNhcEntry 9 } -- -- The Next Hop Server Statistics Table -- nhrpServerStatTable OBJECT-TYPE SYNTAX SEQUENCE OF NhrpServerStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics collected by Next Hop Servers." ::= { nhrpServerObjects 4 } nhrpServerStatEntry OBJECT-TYPE SYNTAX NhrpServerStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for a particular NHS. The statistics are broken into received (Rx), transmitted (Tx) and forwarded (Fw). Forwarded (Fw) would be done by a transit NHS." INDEX { nhrpServerIndex } ::= { nhrpServerStatTable 1 } Greene, et al. Standards Track [Page 42] RFC 2677 NHRP MIB August 1999 NhrpServerStatEntry ::= SEQUENCE { nhrpServerStatRxResolveReq Counter32, nhrpServerStatTxResolveReplyAck Counter32, nhrpServerStatTxResolveReplyNakProhibited Counter32, nhrpServerStatTxResolveReplyNakInsufResources Counter32, nhrpServerStatTxResolveReplyNakNoBinding Counter32, nhrpServerStatTxResolveReplyNakNotUnique Counter32, nhrpServerStatRxRegisterReq Counter32, nhrpServerStatTxRegisterAck Counter32, nhrpServerStatTxRegisterNakProhibited Counter32, nhrpServerStatTxRegisterNakInsufResources Counter32, nhrpServerStatTxRegisterNakAlreadyReg Counter32, nhrpServerStatRxPurgeReq Counter32, nhrpServerStatTxPurgeReq Counter32, nhrpServerStatRxPurgeReply Counter32, nhrpServerStatTxPurgeReply Counter32, -- Error Indications nhrpServerStatRxErrUnrecognizedExtension Counter32, nhrpServerStatRxErrLoopDetected Counter32, nhrpServerStatRxErrProtoAddrUnreachable Counter32, nhrpServerStatRxErrProtoError Counter32, nhrpServerStatRxErrSduSizeExceeded Counter32, nhrpServerStatRxErrInvalidExtension Counter32, nhrpServerStatRxErrInvalidResReplyReceived Counter32, nhrpServerStatRxErrAuthenticationFailure Counter32, nhrpServerStatRxErrHopCountExceeded Counter32, nhrpServerStatTxErrUnrecognizedExtension Counter32, nhrpServerStatTxErrLoopDetected Counter32, nhrpServerStatTxErrProtoAddrUnreachable Counter32, nhrpServerStatTxErrProtoError Counter32, nhrpServerStatTxErrSduSizeExceeded Counter32, nhrpServerStatTxErrInvalidExtension Counter32, nhrpServerStatTxErrAuthenticationFailure Counter32, nhrpServerStatTxErrHopCountExceeded Counter32, -- Transit NHS statistics nhrpServerStatFwResolveReq Counter32, nhrpServerStatFwResolveReply Counter32, nhrpServerStatFwRegisterReq Counter32, nhrpServerStatFwRegisterReply Counter32, nhrpServerStatFwPurgeReq Counter32, nhrpServerStatFwPurgeReply Counter32, nhrpServerStatFwErrorIndication Counter32, nhrpServerStatDiscontinuityTime TimeStamp Greene, et al. Standards Track [Page 43] RFC 2677 NHRP MIB August 1999 } nhrpServerStatRxResolveReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Resolution Requests received by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 1 } nhrpServerStatTxResolveReplyAck OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of positively acknowledged NHRP Resolution Replies transmitted by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 2 } nhrpServerStatTxResolveReplyNakProhibited OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Resolution Replies transmitted by this server with the code 'Administratively Prohibited'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 3 } Greene, et al. Standards Track [Page 44] RFC 2677 NHRP MIB August 1999 nhrpServerStatTxResolveReplyNakInsufResources OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Resolution Replies transmitted by this server with the code 'Insufficient Resources'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 4 } nhrpServerStatTxResolveReplyNakNoBinding OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Resolution Replies transmitted by this server with the code 'No Internetworking Layer Address to NBMA Address Binding Exists'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 5 } nhrpServerStatTxResolveReplyNakNotUnique OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Resolution Replies transmitted by this server with the code 'Binding Exists But Is Not Unique'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 6 } Greene, et al. Standards Track [Page 45] RFC 2677 NHRP MIB August 1999 nhrpServerStatRxRegisterReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Registration Requests received by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 7 } nhrpServerStatTxRegisterAck OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of positively acknowledged NHRP Registration Replies transmitted by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 8 } nhrpServerStatTxRegisterNakProhibited OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Registration Replies transmitted by this server with the code 'Administratively Prohibited'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 9 } Greene, et al. Standards Track [Page 46] RFC 2677 NHRP MIB August 1999 nhrpServerStatTxRegisterNakInsufResources OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Registration Replies transmitted by this server with the code 'Insufficient Resources'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 10 } nhrpServerStatTxRegisterNakAlreadyReg OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NAKed NHRP Registration Replies transmitted by this server with the code 'Unique Internetworking Layer Address Already Registered'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 11 } nhrpServerStatRxPurgeReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Requests received by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 12 } Greene, et al. Standards Track [Page 47] RFC 2677 NHRP MIB August 1999 nhrpServerStatTxPurgeReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Requests transmitted by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 13 } nhrpServerStatRxPurgeReply OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Replies received by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 14 } nhrpServerStatTxPurgeReply OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Replies transmitted by this server. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 15 } nhrpServerStatRxErrUnrecognizedExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Greene, et al. Standards Track [Page 48] RFC 2677 NHRP MIB August 1999 STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'Unrecognized Extension'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 16 } nhrpServerStatRxErrLoopDetected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'NHRP Loop Detected'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 17 } nhrpServerStatRxErrProtoAddrUnreachable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'Protocol Address Unreachable'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." Greene, et al. Standards Track [Page 49] RFC 2677 NHRP MIB August 1999 REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 18 } nhrpServerStatRxErrProtoError OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'Protocol Error'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 19 } nhrpServerStatRxErrSduSizeExceeded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'NHRP SDU Size Exceeded'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 20 } nhrpServerStatRxErrInvalidExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Greene, et al. Standards Track [Page 50] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'Invalid Extension'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 21 } nhrpServerStatRxErrInvalidResReplyReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'Invalid Resolution Reply Received'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 22 } nhrpServerStatRxErrAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'Authentication Failure'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 23 } Greene, et al. Standards Track [Page 51] RFC 2677 NHRP MIB August 1999 nhrpServerStatRxErrHopCountExceeded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets received by this server with the error code 'Hop Count Exceeded'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 24 } nhrpServerStatTxErrUnrecognizedExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'Unrecognized Extension'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 25 } nhrpServerStatTxErrLoopDetected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'NHRP Loop Detected'. Greene, et al. Standards Track [Page 52] RFC 2677 NHRP MIB August 1999 Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 26 } nhrpServerStatTxErrProtoAddrUnreachable OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'Protocol Address Unreachable'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 27 } nhrpServerStatTxErrProtoError OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'Protocol Error'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 28 } Greene, et al. Standards Track [Page 53] RFC 2677 NHRP MIB August 1999 nhrpServerStatTxErrSduSizeExceeded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'NHRP SDU Size Exceeded'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 29 } nhrpServerStatTxErrInvalidExtension OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'Invalid Extension'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 30 } nhrpServerStatTxErrAuthenticationFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'Authentication Failure'. Greene, et al. Standards Track [Page 54] RFC 2677 NHRP MIB August 1999 Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 31 } nhrpServerStatTxErrHopCountExceeded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets transmitted by this server with the error code 'Hop Count Exceeded'. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." REFERENCE "Section 5.2.7 NHRP Error Indication, RFC 2332 [17]." ::= { nhrpServerStatEntry 32 } nhrpServerStatFwResolveReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Resolution Requests forwarded by this server acting as a transit NHS. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 33 } nhrpServerStatFwResolveReply OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Greene, et al. Standards Track [Page 55] RFC 2677 NHRP MIB August 1999 DESCRIPTION "The number of NHRP Resolution Replies forwarded by this server acting as a transit NHS. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 34 } nhrpServerStatFwRegisterReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Registration Requests forwarded by this server acting as a transit NHS. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 35 } nhrpServerStatFwRegisterReply OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Registration Replies forwarded by this server acting as a transit NHS. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 36 } nhrpServerStatFwPurgeReq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Requests forwarded by this server acting as a transit NHS. Greene, et al. Standards Track [Page 56] RFC 2677 NHRP MIB August 1999 Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 37 } nhrpServerStatFwPurgeReply OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Purge Replies forwarded by this server acting as a transit NHS. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 38 } nhrpServerStatFwErrorIndication OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of NHRP Error Indication packets forwarded by this server acting as a transit NHS. Discontinuities in the value of this counter can occur at re-initialization of the management system, at NHRP Server re-initialization and at other times as indicated by the value of nhrpServerStatDiscontinuityTime." ::= { nhrpServerStatEntry 39 } nhrpServerStatDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this Server's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the Greene, et al. Standards Track [Page 57] RFC 2677 NHRP MIB August 1999 local management subsystem or the NHRP Server re-initialization associated with this entry, then this object contains a zero value." REFERENCE "RFC 2233 [18]." ::= { nhrpServerStatEntry 40 } --**************************************************************** -- Module Compliance Statement --**************************************************************** nhrpConformance OBJECT IDENTIFIER ::= { nhrpMIB 2 } nhrpCompliances OBJECT IDENTIFIER ::= { nhrpConformance 1 } nhrpGroups OBJECT IDENTIFIER ::= { nhrpConformance 2 } nhrpModuleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the NHRP MIB." MODULE -- this module MANDATORY-GROUPS { nhrpGeneralGroup } GROUP nhrpClientGroup DESCRIPTION "This group must be supported only by stations that are NHRP clients." GROUP nhrpServerGroup DESCRIPTION "This group must be supported only by stations that are NHRP servers." ::= { nhrpCompliances 1 } nhrpGeneralGroup OBJECT-GROUP OBJECTS { nhrpNextIndex, nhrpCachePrefixLength, nhrpCacheNextHopInternetworkAddr, nhrpCacheNbmaAddrType, nhrpCacheNbmaAddr, nhrpCacheNbmaSubaddr, nhrpCacheType, nhrpCacheState, Greene, et al. Standards Track [Page 58] RFC 2677 NHRP MIB August 1999 nhrpCacheHoldingTimeValid, nhrpCacheHoldingTime, nhrpCacheNegotiatedMtu, nhrpCachePreference, nhrpCacheStorageType, nhrpCacheRowStatus, nhrpPurgeCacheIdentifier, nhrpPurgePrefixLength, nhrpPurgeRequestID, nhrpPurgeReplyExpected, nhrpPurgeRowStatus } STATUS current DESCRIPTION "Objects that apply to both NHRP clients and NHRP servers." ::= { nhrpGroups 1 } nhrpClientGroup OBJECT-GROUP OBJECTS { nhrpClientInternetworkAddrType, nhrpClientInternetworkAddr, nhrpClientNbmaAddrType, nhrpClientNbmaAddr, nhrpClientNbmaSubaddr, nhrpClientInitialRequestTimeout, nhrpClientRegistrationRequestRetries, nhrpClientResolutionRequestRetries, nhrpClientPurgeRequestRetries, nhrpClientDefaultMtu, nhrpClientHoldTime, nhrpClientRequestID, nhrpClientStorageType, nhrpClientRowStatus, nhrpClientRegUniqueness, nhrpClientRegState, nhrpClientRegRowStatus, nhrpClientNhsInternetworkAddrType, nhrpClientNhsInternetworkAddr, nhrpClientNhsNbmaAddrType, nhrpClientNhsNbmaAddr, nhrpClientNhsNbmaSubaddr, nhrpClientNhsInUse, nhrpClientNhsRowStatus, nhrpClientStatTxResolveReq, nhrpClientStatRxResolveReplyAck, nhrpClientStatRxResolveReplyNakProhibited, Greene, et al. Standards Track [Page 59] RFC 2677 NHRP MIB August 1999 nhrpClientStatRxResolveReplyNakInsufResources, nhrpClientStatRxResolveReplyNakNoBinding, nhrpClientStatRxResolveReplyNakNotUnique, nhrpClientStatTxRegisterReq, nhrpClientStatRxRegisterAck, nhrpClientStatRxRegisterNakProhibited, nhrpClientStatRxRegisterNakInsufResources, nhrpClientStatRxRegisterNakAlreadyReg, nhrpClientStatRxPurgeReq, nhrpClientStatTxPurgeReq, nhrpClientStatRxPurgeReply, nhrpClientStatTxPurgeReply, nhrpClientStatTxErrorIndication, nhrpClientStatRxErrUnrecognizedExtension, nhrpClientStatRxErrLoopDetected, nhrpClientStatRxErrProtoAddrUnreachable, nhrpClientStatRxErrProtoError, nhrpClientStatRxErrSduSizeExceeded, nhrpClientStatRxErrInvalidExtension, nhrpClientStatRxErrAuthenticationFailure, nhrpClientStatRxErrHopCountExceeded, nhrpClientStatDiscontinuityTime } STATUS current DESCRIPTION "Objects that apply only to NHRP clients." ::= { nhrpGroups 2 } nhrpServerGroup OBJECT-GROUP OBJECTS { nhrpServerInternetworkAddrType, nhrpServerInternetworkAddr, nhrpServerNbmaAddrType, nhrpServerNbmaAddr, nhrpServerNbmaSubaddr, nhrpServerStorageType, nhrpServerRowStatus, nhrpServerCacheAuthoritative, nhrpServerCacheUniqueness, nhrpServerNhcPrefixLength, nhrpServerNhcInternetworkAddrType, nhrpServerNhcInternetworkAddr, nhrpServerNhcNbmaAddrType, nhrpServerNhcNbmaAddr, nhrpServerNhcNbmaSubaddr, nhrpServerNhcInUse, nhrpServerNhcRowStatus, nhrpServerStatRxResolveReq, Greene, et al. Standards Track [Page 60] RFC 2677 NHRP MIB August 1999 nhrpServerStatTxResolveReplyAck, nhrpServerStatTxResolveReplyNakProhibited, nhrpServerStatTxResolveReplyNakInsufResources, nhrpServerStatTxResolveReplyNakNoBinding, nhrpServerStatTxResolveReplyNakNotUnique, nhrpServerStatRxRegisterReq, nhrpServerStatTxRegisterAck, nhrpServerStatTxRegisterNakProhibited, nhrpServerStatTxRegisterNakInsufResources, nhrpServerStatTxRegisterNakAlreadyReg, nhrpServerStatRxPurgeReq, nhrpServerStatTxPurgeReq, nhrpServerStatRxPurgeReply, nhrpServerStatTxPurgeReply, nhrpServerStatRxErrUnrecognizedExtension, nhrpServerStatRxErrLoopDetected, nhrpServerStatRxErrProtoAddrUnreachable, nhrpServerStatRxErrProtoError, nhrpServerStatRxErrSduSizeExceeded, nhrpServerStatRxErrInvalidExtension, nhrpServerStatRxErrInvalidResReplyReceived, nhrpServerStatRxErrAuthenticationFailure, nhrpServerStatRxErrHopCountExceeded, nhrpServerStatTxErrUnrecognizedExtension, nhrpServerStatTxErrLoopDetected, nhrpServerStatTxErrProtoAddrUnreachable, nhrpServerStatTxErrProtoError, nhrpServerStatTxErrSduSizeExceeded, nhrpServerStatTxErrInvalidExtension, nhrpServerStatTxErrAuthenticationFailure, nhrpServerStatTxErrHopCountExceeded, nhrpServerStatFwResolveReq, nhrpServerStatFwResolveReply, nhrpServerStatFwRegisterReq, nhrpServerStatFwRegisterReply, nhrpServerStatFwPurgeReq, nhrpServerStatFwPurgeReply, nhrpServerStatFwErrorIndication, nhrpServerStatDiscontinuityTime } STATUS current DESCRIPTION "Objects that apply only to NHRP servers." ::= { nhrpGroups 3 } END Greene, et al. Standards Track [Page 61] RFC 2677 NHRP MIB August 1999 5. IANA Considerations The Internet Assigned Numbers Authority (IANA) has been and continues to be responsible for maintaining the ADDRESS FAMILY NUMBERS (http://www.isi.edu/in-notes/iana/assignments/address-family-numbers) name space assignments. The IANA has placed this list in a MIB module, such that it may be imported into other MIBs. The motivation for doing this is to allow MIBs to not have to change when a new assignment is made to the ADDRESS FAMILY NUMBERS. This is very similar to the motivation behind the IANAifType-MIB. Any additions or changes to the list of ADDRESS FAMILY NUMBERS registered via IANA will be done as they have in the past and this document does not propose any changes to the ADDRESS FAMILY NUMBERS other than to place them into a MIB, which can be found via anonymous FTP at: ftp://ftp.isi.edu/mib/ianaaddressfamilynumbers.mib. 6. Security There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The NHRP Protocol, RFC 2332 [17], Section 5.2.4.4 discusses security. There is an authentication option which should be utilized to authenticate the source and also provide data integrity to the NHRP payload. This MIB does not contain any managed objects which configure or expose security information such as that needed for NHRP authentication or data integrity. The following items were deemed to jeopardize security and thus, were NOT added to this MIB. Items denoted as (configurable) are those which would need values. Items denoted as (read-only) are those which would provide information. Although the NHRP Protocol [17], requires or has this information, exposing it in a MIB would jeopardize the entire NBMA domain where NHRP was being used. Therefore, these items have been omitted from the MIB. Greene, et al. Standards Track [Page 62] RFC 2677 NHRP MIB August 1999 1. (configurable) enable/disable security 2. (configurable) SPI (security parameter index). Depending upon the implementation, there may be multiple SPIs, and these would be configurable also. For example, if the implementation switched to a different SPI after a given time. 3. (configurable) algorithm. The HMAC-MD5-128 is the default hash algorithm. 4. (configurable) lifetime value in seconds. 5. (read-only) key. 6. (read-only) list of users who have access to the above information. 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Acknowledgments This document is a product of the IETF's Internetworking Over NBMA Networks (ion) Working Group. The authors would like to thank Avri Doria (Bytex) for the first draft of the NHRP MIB and Keith McCloghrie (cisco) and David Horton (CITR) for their feedback and suggestions. Also, we would like to thank Naganand Doraswamy (Bay Networks) for assistance with the "Security Considerations" section. Greene, et al. Standards Track [Page 63] RFC 2677 NHRP MIB August 1999 9. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. Greene, et al. Standards Track [Page 64] RFC 2677 NHRP MIB August 1999 [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [17] Luciani, J. V., Katz, D., Piscitello, D. and B. Cole, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, December 1997. [18] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [19] Tesink, K., Editor, "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. [20] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [21] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [22] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [23] Cucchiara, J., editor, "Multiprotocol Over ATM Version 1.0 MIB", af-mpoa-0092.000, ATM Forum, July 1998. [24] Fredette, A., editor, "Multiprotocol Over ATM Version 1.0", af-mpoa-0087.000, ATM Forum, May 1997. [25] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998. [26] Greene, M., J. Luciani, K. White and T. Kuo, "Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2", RFC 2320, April 1998. Greene, et al. Standards Track [Page 65] RFC 2677 NHRP MIB August 1999 10. Authors' Addresses James V. Luciani Bay Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821 Phone: (978) 288-4734 EMail: luciani@baynetworks.com Maria Greene Contractor Xedia, Corp. 119 Russell Dr. Littleton, MA 01460 EMail: maria@xedia.com Joan Cucchiara IronBridge Networks 55 Hayden Ave. Lexington, MA 02421 Phone: (781) 372-8236 EMail: joan@ironbridgenetworks.com Greene, et al. Standards Track [Page 66] RFC 2677 NHRP MIB August 1999 12. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Greene, et al. Standards Track [Page 67] snmp-mibs-downloader-1.1/mibrfcs/rfc2707.txt0000644000000000000000000076330511402176071015577 0ustar Network Working Group R. Bergman Request for Comments: 2707 Dataproducts Corp. Category: Informational T. Hastings, Ed. Xerox Corporation S. Isaacson Novell, Inc. H. Lewis IBM Corp. November 1999 Job Monitoring MIB - V1.0 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. IESG Note This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the design of future MIBs. The "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB. Abstract This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future Bergman, et al. Informational [Page 1] RFC 2707 Job Monitoring MIB - V1.0 November 1999 extensions to this MIB may include, but are not limited to, fax machines and scanners. Table of Contents 1 INTRODUCTION 4 1.1 Types of Information in the MIB 5 1.2 Types of Job Monitoring Applications 6 2 TERMINOLOGY AND JOB MODEL 7 2.1 System Configurations for the Job Monitoring MIB 11 2.1.1 Configuration 1 - client-printer 11 2.1.2 Configuration 2 - client-server-printer - agent in the server 12 2.1.3 Configuration 3 - client-server-printer - client monitors printer agent and server 14 3 MANAGED OBJECT USAGE 15 3.1 Conformance Considerations 15 3.1.1 Conformance Terminology 16 3.1.2 Agent Conformance Requirements 16 3.1.2.1 MIB II System Group objects 17 3.1.2.2 MIB II Interface Group objects 17 3.1.2.3 Printer MIB objects 17 3.1.3 Job Monitoring Application Conformance Requirements 17 3.2 The Job Tables and the Oldest Active and Newest Active Indexes 18 3.3 The Attribute Mechanism and the Attribute Table(s) 20 3.3.1 Conformance of Attribute Implementation 21 3.3.2 Useful, 'Unknown', and 'Other' Values for Objects and Attributes 21 3.3.3 Index Value Attributes 22 3.3.4 Data Sub-types and Attribute Naming Conventions 22 3.3.5 Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes 23 3.3.6 Requested Objects and Attributes 23 3.3.7 Consumption Attributes 24 3.3.8 Attribute Specifications 24 3.3.9 Job State Reason bit definitions 43 3.3.9.1 JmJobStateReasons1TC specification 44 3.3.9.2 JmJobStateReasons2TC specification 47 3.3.9.3 JmJobStateReasons3TC specification 51 3.3.9.4 JmJobStateReasons4TC specification 51 3.4 Monitoring Job Progress 51 3.5 Job Identification 55 3.5.1 The Job Submission ID specifications 56 3.6 Internationalization Considerations 60 3.6.1 Text generated by the server or device 61 3.6.2 Text supplied by the job submitter 61 3.6.3 'DateAndTime' for representing the date and time 63 Bergman, et al. Informational [Page 2] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.7 IANA and PWG Registration Considerations 63 3.7.1 PWG Registration of enums 63 3.7.1.1 Type 1 enumerations 64 3.7.1.2 Type 2 enumerations 64 3.7.1.3 Type 3 enumeration 64 3.7.2 PWG Registration of type 2 bit values 65 3.7.3 PWG Registration of Job Submission Id Formats 65 3.7.4 PWG Registration of MIME types/sub-types for document- formats 65 3.8 Security Considerations 65 3.8.1 Read-Write objects 65 3.8.2 Read-Only Objects In Other User's Jobs 66 3.9 Notifications 66 4 MIB SPECIFICATION 67 Textual conventions for this MIB module 68 JmUTF8StringTC 68 JmJobStringTC 68 JmNaturalLanguageTagTC 68 JmTimeStampTC 69 JmJobSourcePlatformTypeTC 69 JmFinishingTC 70 JmPrintQualityTC 71 JmPrinterResolutionTC 71 JmTonerEconomyTC 72 JmBooleanTC 72 JmMediumTypeTC 72 JmJobCollationTypeTC 74 JmJobSubmissionIDTypeTC 74 JmJobStateTC 75 JmAttributeTypeTC 78 JmJobServiceTypesTC 81 JmJobStateReasons1TC 83 JmJobStateReasons2TC 83 JmJobStateReasons3TC 83 JmJobStateReasons4TC 84 The General Group (MANDATORY) 84 jmGeneralJobSetIndex (Int32(1..32767)) 85 jmGeneralNumberOfActiveJobs (Int32(0..)) 86 jmGeneralOldestActiveJobIndex (Int32(0..)) 86 jmGeneralNewestActiveJobIndex (Int32(0..)) 86 jmGeneralJobPersistence (Int32(15..)) 87 jmGeneralAttributePersistence (Int32(15..)) 87 jmGeneralJobSetName (UTF8String63) 88 The Job ID Group (MANDATORY) 88 jmJobSubmissionID (OCTET STRING(SIZE(48))) 89 jmJobIDJobSetIndex (Int32(0..32767)) 90 jmJobIDJobIndex (Int32(0..)) 91 The Job Group (MANDATORY) 91 Bergman, et al. Informational [Page 3] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jmJobIndex (Int32(1..)) 92 jmJobState (JmJobStateTC) 92 jmJobStateReasons1 (JmJobStateReasons1TC) 93 jmNumberOfInterveningJobs (Int32(-2..)) 93 jmJobKOctetsPerCopyRequested (Int32(-2..)) 94 jmJobKOctetsProcessed (Int32(-2..)) 94 jmJobImpressionsPerCopyRequested (Int32(-2..)) 95 jmJobImpressionsCompleted (Int32(-2..)) 96 jmJobOwner (JobString63) 96 The Attribute Group (MANDATORY) 97 jmAttributeTypeIndex (JmAttributeTypeTC) 98 jmAttributeInstanceIndex (Int32(1..32767)) 99 jmAttributeValueAsInteger (Int32(-2..)) 99 jmAttributeValueAsOctets (Octets63) 100 5 APPENDIX A - IMPLEMENTING THE JOB LIFE CYCLE 104 6 APPENDIX B - SUPPORT OF JOB SUBMISSION PROTOCOLS 105 7 REFERENCES 105 8 NOTICES 108 9 AUTHORS' ADDRESSES 109 10 INDEX 111 11 Full Copyright Statement 114 1 Introduction This specification defines an official Printer Working Group (PWG) [PWG] standard SNMP MIB for the monitoring of jobs on network printers. This specification is being published as an IETF Information Document for the convenience of the Internet community. In consultation with the IETF Application Area Directors, it was concluded that this MIB specification properly belongs as an Information document, because this MIB monitors a service node on the network, rather than a network node proper. The Job Monitoring MIB is intended to be implemented by an agent within a printer or the first server closest to the printer, where the printer is either directly connected to the server only or the printer does not contain the job monitoring MIB agent. It is recommended that implementations place the SNMP agent as close as possible to the processing of the print job. This MIB applies to printers with and without spooling capabilities. This MIB is designed to be compatible with most current commonly-used job submission protocols. In most environments that support high function job submission/job control protocols, like ISO DPA [iso- dpa], those protocols would be used to monitor and manage print jobs rather than using the Job Monitoring MIB. Bergman, et al. Informational [Page 4] RFC 2707 Job Monitoring MIB - V1.0 November 1999 The Job Monitoring MIB consists of a General Group, a Job Submission ID Group, a Job Group, and an Attribute Group. Each group is a table. All accessible objects are read-only. The General Group contains general information that applies to all jobs in a job set. The Job Submission ID table maps the job submission ID that the client uses to identify a job to the jmJobIndex that the Job Monitoring Agent uses to identify jobs in the Job and Attribute tables. The Job table contains the MANDATORY integer job state and status objects. The Attribute table consists of multiple entries per job that specify (1) job and document identification and parameters, (2) requested resources, and (3) consumed resources during and after job processing/printing. A larger number of job attributes are defined as textual conventions that an agent SHALL return if the server or device implements the functionality so represented and the agent has access to the information. 1.1 Types of Information in the MIB The job MIB is intended to provide the following information for the indicated Role Models in the Printer MIB [print-mib] (Appendix D - Roles of Users). User: Provide the ability to identify the least busy printer. The user will be able to determine the number and size of jobs waiting for each printer. No attempt is made to actually predict the length of time that jobs will take. Provide the ability to identify the current status of the user's job (user queries). Provide a timely indication that the job has completed and where it can be found. Provide error and diagnostic information for jobs that did not successfully complete. Operator: Provide a presentation of the state of all the jobs in the print system. Provide the ability to identify the user that submitted the print job. Provide the ability to identify the resources required by each job. Bergman, et al. Informational [Page 5] RFC 2707 Job Monitoring MIB - V1.0 November 1999 Provide the ability to define which physical printers are candidates for the print job. Provide some idea of how long each job will take. However, exact estimates of time to process a job is not being attempted. Instead, objects are included that allow the operator to be able to make gross estimates. Capacity Planner: Provide the ability to determine printer utilization as a function of time. Provide the ability to determine how long jobs wait before starting to print. Accountant: Provide information to allow the creation of a record of resources consumed and printer usage data for charging users or groups for resources consumed. Provide information to allow the prediction of consumable usage and resource need. The MIB supports printers that can contain more than one job at a time, but still be usable for low end printers that only contain a single job at a time. In particular, the MIB supports the needs of Windows and other PC environments for managing low-end direct-connect (serial or parallel) and networked devices without unnecessary overhead or complexity, while also providing for higher end systems and devices. 1.2 Types of Job Monitoring Applications The Job Monitoring MIB is designed for the following types of monitoring applications: 1. Monitor a single job starting when the job is submitted and ending a defined period after the job completes. The Job Submission ID table provides the map to find the specific job to be monitored. 2. Monitor all 'active' jobs in a queue, which this specification generalizes to a "job set". End users may use such a program when selecting a least busy printer, so the MIB is designed for such a program to start up quickly and find the information needed quickly without having to read Bergman, et al. Informational [Page 6] RFC 2707 Job Monitoring MIB - V1.0 November 1999 all (completed) jobs in order to find the active jobs. System operators may also use such a program, in which case it would be running for a long period of time and may also be interested in the jobs that have completed. Finally such a program may be used to provide an enhanced console and logging capability. 3. Collect resource usage for accounting or system utilization purposes that copy the completed job statistics to an accounting system. It is recognized that depending on accounting programs to copy MIB data during the job-retention period is somewhat unreliable, since the accounting program may not be running (or may have crashed). Such a program is also expected to keep a shadow copy of the entire Job Attribute table including completed, canceled, and aborted jobs which the program updates on each polling cycle. Such a program polls at the rate of the persistence of the Attribute table. The design is not optimized to help such an application determine which jobs are completed, canceled, or aborted. Instead, the application SHOULD query each job that the application's shadow copy shows was not complete, canceled, or aborted at the previous poll cycle to see if it is now complete or canceled, plus any new jobs that have been submitted. The MIB provides a set of objects that represent a compatible subset of job and document attributes of the ISO DPA standard [iso-dpa] and the Internet Printing Protocol (IPP) [ipp-model], so that coherence is maintained between these two protocols and the information presented to end users and system operators by monitoring applications. However, the job monitoring MIB is intended to be used with printers that implement other job submitting and management protocols, such as IEEE 1284.1 (TIPSI) [tipsi], as well as with ones that do implement ISO DPA. Thus the job monitoring MIB does not require implementation of either the ISO DPA or IPP protocols. The MIB is designed so that an additional MIB(s) can be specified in the future for monitoring multi-function (scan, FAX, copy) jobs as an augmentation to this MIB. 2 Terminology and Job Model This section defines the terms that are used in this specification and the general model for jobs in alphabetical order. Bergman, et al. Informational [Page 7] RFC 2707 Job Monitoring MIB - V1.0 November 1999 NOTE - Existing systems use conflicting terms, so these terms are drawn from the ISO 10175 Document Printing Application (DPA) standard [iso-dpa]. For example, PostScript systems use the term session for what is called a job in this specification and the term job to mean what is called a document in this specification. Accounting Application: The SNMP management application that copies job information to some more permanent medium so that another application can perform accounting on the data for Accountants, Asset Managers, and Capacity Planners use. Agent: The network entity that accepts SNMP requests from a monitor or accounting application and provides access to the instrumentation for managing jobs modeled by the management objects defined in the Job Monitoring MIB module for a server or a device. Attribute: A name, value-pair that specifies a job or document instruction, a status, or a condition of a job or a document that has been submitted to a server or device. A particular attribute NEED NOT be present in each job instance. In other words, attributes are present in a job instance only when there is a need to express the value, either because (1) the client supplied a value in the job submission protocol, (2) the document data contained an embedded attribute, or (3) the server or device supplied a default value. An agent MAY represent an attribute as an entry (row) in the Attribute table in this MIB in which entries are present only when necessary. Attributes are identified in this MIB by an enum. Client: The network entity that end users use to submit jobs to spoolers, servers, or printers and other devices, depending on the configuration, using any job submission protocol over a serial or parallel port to a directly-connected device or over the network to a networked-connected device. Device: A hardware entity that (1) interfaces to humans, such as a device that produces marks on paper or scans marks on paper to produce an electronic representation, (2) accesses digital media, such as CD-ROMs, or (3) interfaces electronically to another device, such as sends FAX data to another FAX device. Document: A sub-section within a job that contains print data and document instructions that apply to just the document. Document Instruction: An instruction specifying how to process the document. Document instructions MAY be passed in the job submission protocol separate from the actual document data, or MAY be embedded in the document data or a combination, depending on the job submission protocol and implementation. Bergman, et al. Informational [Page 8] RFC 2707 Job Monitoring MIB - V1.0 November 1999 End User: A user that uses a client to submit a print job. See "user". Impression: For a print job, an impression is the passage of the entire side of a sheet by the marker, whether or not any marks are made and independent of the number of passes that the side makes past the marker. Thus a four pass color process counts as a single impression, as does highlight color. Impression counters count all kinds: monochrome, highlight color, and full process color, while full color counters only count full color impressions, and high light color counters only count high light color impressions. One-sided processing involves one impression per sheet. Two-sided processing involves two impressions per sheet. If a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker or the marker marks on both sides of a sheet in a single pass. Two-up printing is the placement of two logical pages on one side of a sheet and so is still a single impression. See "page" and "sheet". NOTE - Since impressions include blank sides, it is suggested that accounting application implementers consider charging for sheets, rather than impressions, possibly using the value of the sides attribute to select different charges for one-sided versus two-sided printing, since some users may think that impressions don't include blank sides. Internal Collation: The production of the sheets for each document copy performed within the printing device by making multiple passes over either the source or an intermediate representation of the document. Job: A unit of work whose results are expected together without interjection of unrelated results. A job contains one or more documents. Job Accounting: The activity of a management application of accessing the MIB and recording what happens to the job during and after the processing of the job. Job Instruction: An instruction specifying how, when, or where the job is to be processed. Job instructions MAY be passed in the job submission protocol or MAY be embedded in the document data or a combination depending on the job submission protocol and implementation. Bergman, et al. Informational [Page 9] RFC 2707 Job Monitoring MIB - V1.0 November 1999 Job Monitoring (using SNMP): The activity of a management application of accessing the MIB and (1) identifying jobs in the job tables being processed by the server, printer or other devices, and (2) displaying information to the user about the processing of the job. Job Monitoring Application: The SNMP management application that End Users, and System Operators use to monitor jobs using SNMP. A monitor MAY be either a separate application or MAY be part of the client that also submits jobs. See "monitor". Job Set: A group of jobs that are queued and scheduled together according to a specified scheduling algorithm for a specified device or set of devices. For implementations that embed the SNMP agent in the device, the MIB job set normally represents all the jobs known to the device, so that the implementation only implements a single job set. If the SNMP agent is implemented in a server that controls one or more devices, each MIB job set represents a job queue for (1) a specific device or (2) set of devices, if the server uses a single queue to load balance between several devices. Each job set is disjoint; no job SHALL be represented in more than one MIB job set. Monitor: Short for Job Monitoring Application. Page: A page is a logical division of the original source document. Number up is the imposition of more than one page on a single side of a sheet. See "impression" and "sheet" and "two-up". Proxy: An agent that acts as a concentrator for one or more other agents by accepting SNMP operations on the behalf of one or more other agents, forwarding them on to those other agents, gathering responses from those other agents and returning them to the original requesting monitor. Queuing: The act of a device or server of ordering (queuing) the jobs for the purposes of scheduling the jobs to be processed. Printer: A device that puts marks on media. Server: A network entity that accepts jobs from clients and in turn submits the jobs to printers and other devices that may be directly connected to the server via a serial or parallel port or may be on the network. A server MAY be a printer supervisor control program, or a print spooler. Sheet: A sheet is a single instance of a medium, whether printing on one or both sides of the medium. See "impression" and "page". Bergman, et al. Informational [Page 10] RFC 2707 Job Monitoring MIB - V1.0 November 1999 SNMP Information Object: A name, value-pair that specifies an action, a status, or a condition in an SNMP MIB. Objects are identified in SNMP by an OBJECT IDENTIFIER. Spooler: A server that accepts jobs, spools the data, and decides when and on which printer to print the job. A spooler is a client to a printer or a printer supervisor, depending on implementation. Spooling: The act of a device or server of (1) accepting jobs and (2) writing the job's attributes and document data on to secondary storage. Stacked: When a media sheet is placed in an output bin of a device. Supervisor: A server that contains a control program that controls a printer or other device. A supervisor is a client to the printer or other device. System Operator: A user that uses a monitor to monitor the system and carries out tasks to keep the system running. System Administrator: A user that specifies policy for the system. Two-up: The placement of two pages on one side of a sheet so that each side or impressions counts as two pages. See "page" and "sheet". User: A person that uses a client or a monitor. See "end user". 2.1 System Configurations for the Job Monitoring MIB This section enumerates the three configurations in which the Job Monitoring MIB is intended to be used. To simplify the pictures, the devices are shown as printers. See section 1.1 entitled "Types of Information in the MIB". The diagram in the Printer MIB [print-mib] entitled: "One Printer's View of the Network" is assumed for this MIB as well. Please refer to that diagram to aid in understanding the following system configurations. 2.1.1 Configuration 1 - client-printer In the client-printer configuration 1, the client(s) submit jobs directly to the printer, either by some direct connect, or by network connection. Bergman, et al. Informational [Page 11] RFC 2707 Job Monitoring MIB - V1.0 November 1999 The job submitting client and/or monitoring application monitor jobs by communicating directly with an agent that is part of the printer. The agent in the printer SHALL keep the job in the Job Monitoring MIB as long as the job is in the printer, plus a defined time period after the job enters the completed state in which accounting programs can copy out the accounting data from the Job Monitoring MIB. all end-user ######## SNMP query +-------+ +--------+ ---- job submission |monitor| | client | +---#---+ +--#--+--+ # # | # ############ | # # | +==+===#=#=+==+ | | | agent | | | | +-------+ | | | PRINTER <--------+ | | Print Job Delivery Channel | | +=============+ Figure 2-1 - Configuration 1 - client-printer - agent in the printer The Job Monitoring MIB is designed to support the following relationships (not shown in Figure 2-1): 1. Multiple clients MAY submit jobs to a printer. 2. Multiple clients MAY monitor a printer. 3. Multiple monitors MAY monitor a printer. 4. A client MAY submit jobs to multiple printers. 5. A monitor MAY monitor multiple printers. 2.1.2 Configuration 2 - client-server-printer - agent in the server In the client-server-printer configuration 2, the client(s) submit jobs to an intermediate server by some network connection, not directly to the printer. While configuration 2 is included, the design center for this MIB is configurations 1 and 3. The job submitting client and/or monitoring application monitor jobs by communicating directly with: A Job Monitoring MIB agent that is part of the server (or a front for the server) Bergman, et al. Informational [Page 12] RFC 2707 Job Monitoring MIB - V1.0 November 1999 There is no SNMP Job Monitoring MIB agent in the printer in configuration 2, at least that the client or monitor are aware. In this configuration, the agent SHALL return the current values of the objects in the Job Monitoring MIB both for jobs the server keeps and jobs that the server has submitted to the printer. The Job Monitoring MIB agent obtains the required information from the printer by a method that is beyond the scope of this document. The agent in the server SHALL keep the job in the Job Monitoring MIB in the server as long as the job is in the printer, plus a defined time period after the job enters the completed state in which accounting programs can copy out the accounting data from the Job Monitoring MIB. all end-user +-------+ +----------+ |monitor| | client | ######## SNMP query +---+---# +---#----+-+ **** non-SNMP cntrl # # | ---- job submission # # | # # | #=====#=+==v==+ | agent | | +-------+ | | server | +----+-----+--+ control * | ********** | * | +========v====+ | | | | | | | | PRINTER <---------+ | | Print Job Delivery Channel | | +=============+ Figure 2-2 - Configuration 2 - client-server-printer - agent in the server The Job Monitoring MIB is designed to support the following relationships (not shown in Figure 2-2): 1. Multiple clients MAY submit jobs to a server. 2. Multiple clients MAY monitor a server. 3. Multiple monitors MAY monitor a server. 4. A client MAY submit jobs to multiple servers. 5. A monitor MAY monitor multiple servers. 6. Multiple servers MAY submit jobs to a printer. 7. Multiple servers MAY control a printer. Bergman, et al. Informational [Page 13] RFC 2707 Job Monitoring MIB - V1.0 November 1999 2.1.3 Configuration 3 - client-server-printer - client monitors printer agent and server In the client-server-printer configuration 3, the client(s) submit jobs to an intermediate server by some network connection, not directly to the printer. That server does not contain a Job Monitoring MIB agent. The job submitting client and/or monitoring application monitor jobs by communicating directly with: 1. The server using some undefined protocol to monitor jobs in the server (that does not contain the Job Monitoring MIB) AND 2. A Job Monitoring MIB agent that is part of the printer to monitor jobs after the server passes the jobs to the printer. In such configurations, the server deletes its copy of the job from the server after submitting the job to the printer usually almost immediately (before the job does much processing, if any). In configuration 3, the agent (in the printer) SHALL keep the values of the objects in the Job Monitoring MIB that the agent implements updated for a job that the server has submitted to the printer. The agent SHALL obtain information about the jobs submitted to the printer from the server (either in the job submission protocol, in the document data, or by direct query of the server), in order to populate some of the objects the Job Monitoring MIB in the printer. The agent in the printer SHALL keep the job in the Job Monitoring MIB as long as the job is in the Printer, and longer in order to implement the completed state in which monitoring programs can copy out the accounting data from the Job Monitoring MIB. Bergman, et al. Informational [Page 14] RFC 2707 Job Monitoring MIB - V1.0 November 1999 all end-user +-------+ +----------+ |monitor| | client | ######## SNMP query +---+---* +---*----+-+ **** non-SNMP query # * * | ---- job submission # * * | # * * | # *=====v====v==+ # | | # | server | # | | # +----#-----+--+ # optional# | # ########## | # # | +==+=v===v=+==+ | | | agent | | | | +-------+ | | | PRINTER <---------+ | | Print Job Delivery Channel | | +=============+ Figure 2-3 - Configuration 3 - client-server-printer - client monitors printer agent and server The Job Monitoring MIB is designed to support the following relationships (not shown in Figure 2-3): 1. Multiple clients MAY submit jobs to a server. 2. Multiple clients MAY monitor a server. 3. Multiple monitors MAY monitor a server. 4. A client MAY submit jobs to multiple servers. 5. A monitor MAY monitor multiple servers. 6. Multiple servers MAY submit jobs to a printer. 7. Multiple servers MAY control a printer. 3 Managed Object Usage This section describes the usage of the objects in the MIB. 3.1 Conformance Considerations In order to achieve interoperability between job monitoring applications and job monitoring agents, this specification includes the conformance requirements for both monitoring applications and agents. Bergman, et al. Informational [Page 15] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.1.1 Conformance Terminology This specification uses the verbs: "SHALL", "SHOULD", "MAY", and "NEED NOT" to specify conformance requirements according to RFC 2119 [RFC2119] as follows: "SHALL": indicates an action that the subject of the sentence must implement in order to claim conformance to this specification "MAY": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification, in other words that action is an implementation option "NEED NOT": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification. The verb "NEED NOT" is used instead of "may not", since "may not" sounds like a prohibition. "SHOULD": indicates an action that is recommended for the subject of the sentence to implement, but is not required, in order to claim conformance to this specification. 3.1.2 Agent Conformance Requirements A conforming agent: 1. SHALL implement all MANDATORY groups in this specification. 2. SHALL implement any attributes if (1) the server or device supports the functionality represented by the attribute and (2) the information is available to the agent. 3. SHOULD implement both forms of an attribute if it implements an attribute that permits a choice of INTEGER and OCTET STRING forms, since implementing both forms may help management applications by giving them a choice of representations, since the representation are equivalent. See the JmAttributeTypeTC textual-convention. NOTE - This MIB, like the Printer MIB, is written following the subset of SMIv2 that can be supported by SMIv1 and SNMPv1 implementations. Bergman, et al. Informational [Page 16] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.1.2.1 MIB II System Group objects The Job Monitoring MIB agent SHALL implement all objects in the System Group of MIB-II [mib-II], whether the Printer MIB [print-mib] is implemented or not. 3.1.2.2 MIB II Interface Group objects The Job Monitoring MIB agent SHALL implement all objects in the Interfaces Group of MIB-II [mib-II], whether the Printer MIB [print- mib] is implemented or not. 3.1.2.3 Printer MIB objects If the agent is providing access to a device that is a printer, the agent SHALL implement all of the MANDATORY objects in the Printer MIB [print-mib] and all the objects in other MIBs that conformance to the Printer MIB requires, such as the Host Resources MIB [hr-mib]. If the agent is providing access to a server that controls one or more direct-connect or networked printers, the agent NEED NOT implement the Printer MIB and NEED NOT implement the Host Resources MIB. 3.1.3 Job Monitoring Application Conformance Requirements A conforming job monitoring application: 1. SHALL accept the full syntactic range for all objects in all MANDATORY groups and all MANDATORY attributes that are required to be implemented by an agent according to Section 3.1.2 and SHALL either present them to the user or ignore them. 2. SHALL accept the full syntactic range for all attributes, including enum and bit values specified in this specification and additional ones that may be registered with the PWG and SHALL either present them to the user or ignore them. In particular, a conforming job monitoring application SHALL not malfunction when receiving any standard or registered enum or bit values. See Section 3.7 entitled "IANA and PWG Registration Considerations". 3. SHALL NOT fail when operating with agents that materialize attributes after the job has been submitted, as opposed to when the job is submitted. 4. SHALL, if it supports a time attribute, accept either form of the time attribute, since agents are free to implement either time form. Bergman, et al. Informational [Page 17] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.2 The Job Tables and the Oldest Active and Newest Active Indexes The jmJobTable and jmAttributeTable contain objects and attributes, respectively, for each job in a job set. These first two indexes are: 1. jmGeneralJobSetIndex - which job set 2. jmJobIndex - which job in the job set In order for a monitoring application to quickly find that active jobs (jobs in the pending, processing, or processingStopped states), the MIB contains two indexes: 1. jmGeneralOldestActiveJobIndex - the index of the active job that has been in the tables the longest. 2. jmGeneralNewestActiveJobIndex - the index of the active job that has been most recently added to the tables. The agent SHALL assign the next incremental value of jmJobIndex to the job, when a new job is accepted by the server or device to which the agent is providing access. If the incremented value of jmJobIndex would exceed the implementation-defined maximum value for jmJobIndex, the agent SHALL 'wrap' back to 1. An agent uses the resulting value of jmJobIndex for storing information in the jmJobTable and the jmAttributeTable about the job. It is recommended that the largest value for jmJobIndex be much larger than the maximum number of jobs that the implementation can contain at a single time, so as to minimize the premature re-use of a jmJobIndex value for a newer job while clients retain the same ' stale' value for an older job. It is recommended that agents that are providing access to servers/devices that already allocate job-identifiers for jobs as integers use the same integer value for the jmJobIndex. Then management applications using this MIB and applications using other protocols will see the same job identifiers for the same jobs. Agents providing access to systems that contain jobs with a job identifier of 0 SHALL map the job identifier value 0 to a jmJobIndex value that is one higher than the highest job identifier value that any job can have on that system. Then only job 0 will have a different job-identifier value than the job's jmJobIndex value. NOTE - If a server or device accepts jobs using multiple job submission protocols, it may be difficult for the agent to meet the recommendation to use the job-identifier values that the server or Bergman, et al. Informational [Page 18] RFC 2707 Job Monitoring MIB - V1.0 November 1999 device assigns as the jmJobIndex value, unless the server/device assigns job-identifiers for each of its job submission protocols from the same job-identifier number space. Each time a new job is accepted by the server or device that the agent is providing access to AND that job is to be 'active' (pending, processing, or processingStopped, but not pendingHeld), the agent SHALL copy the value of the job's jmJobIndex to the jmGeneralNewestActiveJobIndex object. If the new job is to be ' inactive' (pendingHeld state), the agent SHALL not change the value of jmGeneralNewestActiveJobIndex object (though the agent SHALL assign the next incremental jmJobIndex value to the job). When a job transitions from one of the 'active' job states (pending, processing, processingStopped) to one of the 'inactive' job states (pendingHeld, completed, canceled, or aborted), with a jmJobIndex value that matches the jmGeneralOldestActiveJobIndex object, the agent SHALL advance (or wrap) the value to the next oldest 'active' job, if any. See the JmJobStateTC textual-convention for a definition of the job states. Whenever a job transitions from one of the 'inactive' job states to one of the 'active' job states (from pendingHeld to pending or processing), the agent SHALL update the value of either the jmGeneralOldestActiveJobIndex or the jmGeneralNewestActiveJobIndex objects, or both, if the job's jmJobIndex value is outside the range between jmGeneralOldestActiveJobIndex and jmGeneralNewestActiveJobIndex. When all jobs become 'inactive', i.e., enter the pendingHeld, completed, canceled, or aborted states, the agent SHALL set the value of both the jmGeneralOldestActiveJobIndex and jmGeneralNewestActiveJobIndex objects to 0. NOTE - Applications that wish to efficiently access all of the active jobs MAY use jmGeneralOldestActiveJobIndex value to start with the oldest active job and continue until they reach the index value equal to jmGeneralNewestActiveJobIndex, skipping over any pendingHeld, completed, canceled, or aborted jobs that might intervene. If an application detects that the jmGeneralNewestActiveJobIndex is smaller than jmGeneralOldestActiveJobIndex, the job index has wrapped. In this case, the application SHALL reset the index to 1 when the end of the table is reached and continue the GetNext operations to find the rest of the active jobs. Bergman, et al. Informational [Page 19] RFC 2707 Job Monitoring MIB - V1.0 November 1999 NOTE - Applications detect the end of the jmAttributeTable table when the OID returned by the GetNext operation is an OID in a different MIB. There is no object in this MIB that specifies the maximum value for the jmJobIndex supported by the implementation. When the server or device is power-cycled, the agent SHALL remember the next jmJobIndex value to be assigned, so that new jobs are not assigned the same jmJobIndex as recent jobs before the power cycle. 3.3 The Attribute Mechanism and the Attribute Table(s) Attributes are similar to information objects, except that attributes are identified by an enum, instead of an OID, so that attributes may be registered without requiring a new MIB. Also an implementation that does not have the functionality represented by the attribute can omit the attribute entirely, rather than having to return a distinguished value. The agent is free to materialize an attribute in the jmAttributeTable as soon as the agent is aware of the value of the attribute. The agent materializes job attributes in a four-indexed jmAttributeTable: 1. jmGeneralJobSetIndex - which job set 2. jmJobIndex - which job in the job set 3. jmAttributeTypeIndex - which attribute 4. jmAttributeInstanceIndex - which attribute instance for those attributes that can have multiple values per job. Some attributes represent information about a job, such as a file- name, a document-name, a submission-time or a completion time. Other attributes represent resources required, e.g., a medium or a colorant, etc. to process the job before the job starts processing OR to indicate the amount of the resource consumed during and after processing, e.g., pages completed or impressions completed. If both a required and a consumed value of a resource is needed, this specification assigns two separate attribute enums in the textual convention. NOTE - The table of contents lists all the attributes in order. This order is the order of enum assignments which is the order that the SNMP GetNext operation returns attributes. Most attributes apply to all three configurations covered by this MIB specification (see Bergman, et al. Informational [Page 20] RFC 2707 Job Monitoring MIB - V1.0 November 1999 section 2.1 entitled "System Configurations for the Job Monitoring MIB"). Those attributes that apply to a particular configuration are indicated as 'Configuration n:' and SHALL NOT be used with other configurations. 3.3.1 Conformance of Attribute Implementation An agent SHALL implement any attribute if (1) the server or device supports the functionality represented by the attribute and (2) the information is available to the agent. The agent MAY create the attribute row in the jmAttributeTable when the information is available or MAY create the row earlier with the designated 'unknown' value appropriate for that attribute. See next section. If the server or device does not implement or does not provide access to the information about an attribute, the agent SHOULD NOT create the corresponding row in the jmAttributeTable. 3.3.2 Useful, 'Unknown', and 'Other' Values for Objects and Attributes Some attributes have a 'useful' Integer32 value, some have a 'useful' OCTET STRING value, some MAY have either or both depending on implementation, and some MUST have both. See the JmAttributeTypeTC textual convention for the specification of each attribute. SNMP requires that if an object cannot be implemented because its values cannot be accessed, then a compliant agent SHALL return an SNMP error in SNMPv1 or an exception value in SNMPv2. However, this MIB has been designed so that 'all' objects can and SHALL be implemented by an agent, so that neither the SNMPv1 error nor the SNMPv2 exception value SHALL be generated by the agent. This MIB has also been designed so that when an agent materializes an attribute, the agent SHALL materialize a row consisting of both the jmAttributeValueAsInteger and jmAttributeValueAsOctets objects. In general, values for objects and attributes have been chosen so that a management application will be able to determine whether a ' useful', 'unknown', or 'other' value is available. When a useful value is not available for an object, that agent SHALL return a zero-length string for octet strings, the value 'unknown(2)' for enums, a '0' value for an object that represents an index in another table, and a value '-2' for counting integers. Since each attribute is represented by a row consisting of both the jmAttributeValueAsInteger and jmAttributeValueAsOctets MANDATORY objects, SNMP requires that the agent SHALL always create an attribute row with both objects specified. However, for most attributes the agent SHALL return a "useful" value for one of the Bergman, et al. Informational [Page 21] RFC 2707 Job Monitoring MIB - V1.0 November 1999 objects and SHALL return the 'other' value for the other object. For integer only attributes, the agent SHALL always return a zero-length string value for the jmAttributeValueAsOctets object. For octet string only attributes, the agent SHALL always return a '-1' value for the jmAttributeValueAsInteger object. 3.3.3 Index Value Attributes A number of attributes are indexes in other tables. Such attribute names end with the word 'Index'. If the agent has not (yet) assigned an index value for a particular index attribute for a job, the agent SHALL either: (1) return the value 0 or (2) not add this attribute to the jmAttributeTable until the index value is assigned. In the interests of brevity, the semantics for 0 is specified once here and is not repeated for each index attribute specification and a DEFVAL of 0 is implied, even though the DEFVAL for jmAttributeValueAsInteger is -2. 3.3.4 Data Sub-types and Attribute Naming Conventions Many attributes are sub-typed to give a more specific data type than Integer32 or OCTET STRING. The data sub-type of each attribute is indicated on the first line(s) of the description. Some attributes have several different data sub-type representations. When an attribute has both an Integer32 data sub-type and an OCTET STRING data sub-type, the attribute can be represented in a single row in the jmAttributeTable. In this case, the data sub-type name is not included as the last part of the name of the attribute, e.g., documentFormat(38) which is both an enum and/or a name. When the data sub-types cannot be represented by a single row in the jmAttributeTable, each such representation is considered a separate attribute and is assigned a separate name and enum value. For these attributes, the name of the data sub-type is the last part of the name of the attribute: Name, Index, DateAndTime, TimeStamp, etc. For example, documentFormatIndex(37) is an index. NOTE: The Table of Contents also lists the data sub-type and/or data sub-types of each attribute, using the textual-convention name when such is defined. The following abbreviations are used in the Table of Contents as shown: Bergman, et al. Informational [Page 22] RFC 2707 Job Monitoring MIB - V1.0 November 1999 'Int32(-2..)' Integer32 (-2..2147483647) 'Int32(0..)' Integer32 (0..2147483647) 'Int32(1..)' Integer32 (1..2147483647) 'Int32(m..n)' For all other Integer ranges, the lower and upper bound of the range is indicated. 'UTF8String63' JmUTF8StringTC (SIZE(0..63)) 'JobString63' JmJobStringTC (SIZE(0..63)) 'Octets63' OCTET STRING (SIZE(0..63)) 'Octets(m..n)' For all other OCTET STRING ranges, the exact range is indicated. 3.3.5 Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes Most attributes have only one row per job. However, a few attributes can have multiple values per job or even per document, where each value is a separate row in the jmAttributeTable. Unless indicated with 'MULTI-ROW:' in the JmAttributeTypeTC description, an agent SHALL ensure that each attribute occurs only once in the jmAttributeTable for a job. Most of the 'MULTI-ROW' attributes do not allow duplicate values, i.e., the agent SHALL ensure that each value occurs only once for a job. Only if the specification of the ' MULTI-ROW' attribute also says "There is no restriction on the same xxx occurring in multiple rows" can the agent allow duplicate values to occur for the job. NOTE - Duplicates are allowed for 'extensive' 'MULTI-ROW' attributes, such as fileName(34) or documentName(35) which are specified to be ' per-document' attributes, but are not allowed for 'intensive' ' MULTI-ROW' attributes, such as mediumConsumed(171) and documentFormat(38) which are specified to be 'per-job' attributes. 3.3.6 Requested Objects and Attributes A number of objects and attributes record requirements for the job. Such object and attribute names end with the word 'Requested'. In the interests of brevity, the phrase 'requested' means: (1) requested by the client (or intervening server) in the job submission protocol and may also mean (2) embedded in the submitted document data, and/or (3) defaulted by the recipient device or server with the same semantics as if the requester had supplied, depending on implementation. Also if a value is supplied by the job submission client, and the server/device determines a better value, through processing or other means, the agent MAY return that better value for such object and attribute. Bergman, et al. Informational [Page 23] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.3.7 Consumption Attributes A number of objects and attributes record consumption. Such attribute names end with the word 'Completed' or 'Consumed'. If the job has not yet consumed what that resource is metering, the agent either: (1) SHALL return the value 0 or (2) SHALL not add this attribute to the jmAttributeTable until the consumption begins. In the interests of brevity, the semantics for 0 is specified once here and is not repeated for each consumption attribute specification and a DEFVAL of 0 is implied, even though the DEFVAL for jmAttributeValueAsInteger is -2. 3.3.8 Attribute Specifications This section specifies the job attributes. In the following definitions of the attributes, each description indicates whether the useful value of the attribute SHALL be represented using the jmAttributeValueAsInteger or the jmAttributeValueAsOctets objects by the initial tag: 'INTEGER:' or ' OCTETS:', respectively. Some attributes allow the agent implementer a choice of useful values of either an integer, an octet string representation, or both, depending on implementation. These attributes are indicated with ' INTEGER:' AND/OR 'OCTETS:' tags. A very few attributes require both objects at the same time to represent a pair of useful values (see mediumConsumed(171)). These attributes are indicated with 'INTEGER:' AND 'OCTETS:' tags. See the jmAttributeGroup for the descriptions of these two MANDATORY objects. NOTE - The enum assignments are grouped logically with values assigned in groups of 20, so that additional values may be registered in the future and assigned a value that is part of their logical grouping. Values in the range 2**30 to 2**31-1 are reserved for private or experimental usage. This range corresponds to the same range reserved in IPP. Implementers are warned that use of such values may conflict with other implementations. Implementers are encouraged to request registration of enum values following the procedures in Section 3.7.1. NOTE: No attribute name exceeds 31 characters. Bergman, et al. Informational [Page 24] RFC 2707 Job Monitoring MIB - V1.0 November 1999 The standard attribute types are: jmAttributeTypeIndex Datatype -------------------- -------- other(1), Integer32 (-2..2147483647) AND/OR OCTET STRING(SIZE(0..63)) INTEGER: and/or OCTETS: An attribute that is not in the list and/or that has not been approved and registered with the PWG. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Job State attributes (3 - 19 decimal) + + The following attributes specify the state of a job. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobStateReasons2(3), JmJobStateReasons2TC INTEGER: Additional information about the job's current state that augments the jmJobState object. See the description under the JmJobStateReasons1TC textual-convention. jobStateReasons3(4), JmJobStateReasons3TC INTEGER: Additional information about the job's current state that augments the jmJobState object. See the description under JmJobStateReasons1TC textual-convention. jobStateReasons4(5), JmJobStateReasons4TC INTEGER: Additional information about the job's current state that augments the jmJobState object. See the description under JmJobStateReasons1TC textual-convention. processingMessage(6), JmUTF8StringTC (SIZE(0..63)) OCTETS: MULTI-ROW: A coded character set message that is generated by the server or device during the processing of the job as a simple form of processing log to show progress and any problems. The natural language of each value is specified by the corresponding processingMessageNaturalLangTag(7) value. NOTE - This attribute is intended for such conditions as interpreter messages, rather than being the printable form of the jmJobState and jmJobStateReasons1 objects and jobStateReasons2, jobStateReasons3, and jobStateReasons4 attributes. In order to produce a localized printable form of these job state objects/attribute, a management application SHOULD produce a message from their enum and bit values. Bergman, et al. Informational [Page 25] RFC 2707 Job Monitoring MIB - V1.0 November 1999 NOTE - There is no job description attribute in IPP/1.0 that corresponds to this attribute and this attribute does not correspond to the IPP/1.0 'job-state-message' job description attribute, which is just a printable form of the IPP 'job-state' and 'job-state-reasons' job attributes. There is no restriction for the same message occurring in multiple rows. processingMessageNaturalLangTag(7), OCTET STRING(SIZE(0..63)) OCTETS: MULTI-ROW: The natural language of the corresponding processingMessage(6) attribute value. See section 3.6.1, entitled 'Text generated by the server or device'. If the agent does not know the natural language of the job processing message, the agent SHALL either (1) return a zero length string value for the processingMessageNaturalLangTag(7) attribute or (2) not return the processingMessageNaturalLangTag(7) attribute for the job. There is no restriction for the same tag occurring in multiple rows, since when this attribute is implemented, it SHOULD have a value row for each corresponding processingMessage(6) attribute value row. jobCodedCharSet(8), CodedCharSet INTEGER: The MIBenum identifier of the coded character set that the agent is using to represent coded character set objects and attributes of type 'JmJobStringTC'. These coded character set objects and attributes are either: (1) supplied by the job submitting client or (2) defaulted by the server or device when omitted by the job submitting client. The agent SHALL represent these objects and attributes in the MIB either (1) in the coded character set as they were submitted or (2) MAY convert the coded character set to another coded character set or encoding scheme as identified by the jobCodedCharSet(8) attribute. See section 3.6.2, entitled 'Text supplied by the job submitter'. These MIBenum values are assigned by IANA [IANA-charsets] when the coded character sets are registered. The coded character set SHALL be one of the ones registered with IANA [IANA] and the enum value uses the CodedCharSet textual-convention from the Printer MIB. See the JmJobStringTC textual-convention. If the agent does not know what coded character set was used by the job submitting client, the agent SHALL either (1) return the 'unknown(2)' value for the jobCodedCharSet(8) attribute or (2) not return the jobCodedCharSet(8) attribute for the job. Bergman, et al. Informational [Page 26] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jobNaturalLanguageTag(9), OCTET STRING(SIZE(0..63)) OCTETS: The natural language of the job attributes supplied by the job submitter or defaulted by the server or device for the job, i.e., all objects and attributes represented by the ' JmJobStringTC' textual-convention, such as jobName, mediumRequested, etc. See Section 3.6.2, entitled 'Text supplied by the job submitter'. If the agent does not know what natural language was used by the job submitting client, the agent SHALL either (1) return a zero length string value for the jobNaturalLanguageTag(9) attribute or (2) not return jobNaturalLanguageTag(9) attribute for the job. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Job Identification attributes (20 - 49 decimal) + + The following attributes help an end user, a system + operator, or an accounting program identify a job. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobURI(20), OCTET STRING(SIZE(0..63)) OCTETS: MULTI-ROW: The job's Universal Resource Identifier (URI) [RFC1738]. See IPP [ipp-model] for example usage. NOTE - The agent may be able to generate this value on each SNMP Get operation from smaller values, rather than having to store the entire URI. If the URI exceeds 63 octets, the agent SHALL use multiple values, with the next 63 octets coming in the second value, etc. NOTE - IPP [ipp-model] has a 1023-octet maximum length for a URI, though the URI standard itself and HTTP/1.1 specify no maximum length. jobAccountName(21), OCTET STRING(SIZE(0..63)) OCTETS: Arbitrary binary information which MAY be coded character set data or encrypted data supplied by the submitting user for use by accounting services to allocate or categorize charges for services provided, such as a customer account name or number. NOTE: This attribute NEED NOT be printable characters. Bergman, et al. Informational [Page 27] RFC 2707 Job Monitoring MIB - V1.0 November 1999 serverAssignedJobName(22), JmJobStringTC (SIZE(0..63)) OCTETS: Configuration 3 only: The human readable string name, number, or ID of the job as assigned by the server that submitted the job to the device that the agent is providing access to with this MIB. NOTE - This attribute is intended for enabling a user to find his/her job that a server submitted to a device when either the client does not support the jmJobSubmissionID or the server does not pass the jmJobSubmissionID through to the device. jobName(23), JmJobStringTC (SIZE(0..63)) OCTETS: The human readable string name of the job as assigned by the submitting user to help the user distinguish between his/her various jobs. This name does not need to be unique. This attribute is intended for enabling a user or the user's application to convey a job name that MAY be printed on a start sheet, returned in a query result, or used in notification or logging messages. In order to assist users to find their jobs for job submission protocols that don't supply a jmJobSubmissionID, the agent SHOULD maintain the jobName attribute for the time specified by the jmGeneralJobPersistence object, rather than the (shorter) jmGeneralAttributePersistence object. If this attribute is not specified when the job is submitted, no job name is assumed, but implementation specific defaults are allowed, such as the value of the documentName attribute of the first document in the job or the fileName attribute of the first document in the job. The jobName attribute is distinguished from the jobComment attribute, in that the jobName attribute is intended to permit the submitting user to distinguish between different jobs that he/she has submitted. The jobComment attribute is intended to be free form additional information that a user might wish to use to communicate with himself/herself, such as a reminder of what to do with the results or to indicate a different set of input parameters were tried in several different job submissions. Bergman, et al. Informational [Page 28] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jobServiceTypes(24), JmJobServiceTypesTC INTEGER: Specifies the type(s) of service to which the job has been submitted (print, fax, scan, etc.). The service type is bit encoded with each job service type so that more general and arbitrary services can be created, such as services with more than one destination type, or ones with only a source or only a destination. For example, a job service might scan, faxOut, and print a single job. In this case, three bits would be set in the jobServiceTypes attribute, corresponding to the hexadecimal values: 0x8 + 0x20 + 0x4, respectively, yielding: 0x2C. Whether this attribute is set from a job attribute supplied by the job submission client or is set by the recipient job submission server or device depends on the job submission protocol. This attribute SHALL be implemented if the server or device has other types in addition to or instead of printing. One of the purposes of this attribute is to permit a requester to filter out jobs that are not of interest. For example, a printer operator may only be interested in jobs that include printing. jobSourceChannelIndex(25), Integer32 (0..2147483647) INTEGER: The index of the row in the associated Printer MIB [print-mib] of the channel which is the source of the print job. jobSourcePlatformType(26), JmJobSourcePlatformTypeTC INTEGER: The source platform type of the immediate upstream submitter that submitted the job to the server (configuration 2) or device (configuration 1 and 3) to which the agent is providing access. For configuration 1, this is the type of the client that submitted the job to the device; for configuration 2, this is the type of the client that submitted the job to the server; and for configuration 3, this is the type of the server that submitted the job to the device. submittingServerName(27), JmJobStringTC (SIZE(0..63)) OCTETS: For configuration 3 only: The administrative name of the server that submitted the job to the device. submittingApplicationName(28), JmJobStringTC (SIZE(0..63)) OCTETS: The name of the client application (not the server in configuration 3) that submitted the job to the server or device. Bergman, et al. Informational [Page 29] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jobOriginatingHost(29), JmJobStringTC (SIZE(0..63)) OCTETS: The name of the client host (not the server host name in configuration 3) that submitted the job to the server or device. deviceNameRequested(30), JmJobStringTC (SIZE(0..63)) OCTETS: The administratively defined coded character set name of the target device requested by the submitting user. For configuration 1, its value corresponds to the Printer MIB [print-mib]: prtGeneralPrinterName object. For configuration 2 and 3, its value is the name of the logical or physical device that the user supplied to indicate to the server on which device(s) they wanted the job to be processed. queueNameRequested(31), JmJobStringTC (SIZE(0..63)) OCTETS: The administratively defined coded character set name of the target queue requested by the submitting user. For configuration 1, its value corresponds to the queue in the device for which the agent is providing access. For configuration 2 and 3, its value is the name of the queue that the user supplied to indicate to the server on which device(s) they wanted the job to be processed. NOTE - typically an implementation SHOULD support either the deviceNameRequested or queueNameRequested attribute, but not both. physicalDevice(32), hrDeviceIndex AND/OR JmUTF8StringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The index of the physical device MIB instance requested/used, such as the Printer MIB [print-mib]. This value is an hrDeviceIndex value. See the Host Resources MIB [hr-mib]. AND/OR OCTETS: MULTI-ROW: The name of the physical device to which the job is assigned. numberOfDocuments(33), Integer32 (-2..2147483647) INTEGER: The number of documents in this job. The agent SHOULD return this attribute if the job has more than one document. Bergman, et al. Informational [Page 30] RFC 2707 Job Monitoring MIB - V1.0 November 1999 fileName(34), JmJobStringTC (SIZE(0..63)) OCTETS: MULTI-ROW: The coded character set file name or URI [URI-spec] of the document. There is no restriction on the same file name occurring in multiple rows. documentName(35), JmJobStringTC (SIZE(0..63)) OCTETS: MULTI-ROW: The coded character set name of the document. There is no restriction on the same document name occurring in multiple rows. jobComment(36), JmJobStringTC (SIZE(0..63)) OCTETS: An arbitrary human-readable coded character text string supplied by the submitting user or the job submitting application program for any purpose. For example, a user might indicate what he/she is going to do with the printed output or the job submitting application program might indicate how the document was produced. The jobComment attribute is not intended to be a name; see the jobName attribute. documentFormatIndex(37), Integer32 (0..2147483647) INTEGER: MULTI-ROW: The index in the prtInterpreterTable in the Printer MIB [print-mib] of the page description language (PDL) or control language interpreter that this job requires/uses. A document or a job MAY use more than one PDL or control language. NOTE - As with all intensive attributes where multiple rows are allowed, there SHALL be only one distinct row for each distinct interpreter; there SHALL be no duplicates. NOTE - This attribute type is intended to be used with an agent that implements the Printer MIB and SHALL not be used if the agent does not implement the Printer MIB. Such an agent SHALL use the documentFormat attribute instead. Bergman, et al. Informational [Page 31] RFC 2707 Job Monitoring MIB - V1.0 November 1999 documentFormat(38), PrtInterpreterLangFamilyTC AND/OR OCTET STRING(SIZE(0..63)) INTEGER: MULTI-ROW: The interpreter language family corresponding to the Printer MIB [print-mib] prtInterpreterLangFamily object, that this job requires/uses. A document or a job MAY use more than one PDL or control language. AND/OR OCTETS: MULTI-ROW: The document format registered as a media type [iana-media-types], i.e., the name of the MIME content-type/subtype. Examples: 'application/postscript', 'application/vnd.hp-PCL', 'application/pdf', 'text/plain' (US-ASCII SHALL be assumed), 'text/plain; charset=iso-8859-1', and 'application/octet-stream'. The IPP 'document-format' job attribute uses these same values with the same semantics. See the IPP [ipp-model] 'mimeMediaType' attribute syntax and the document-format attribute for further examples and explanation. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Job Parameter attributes (50 - 67 decimal) + + The following attributes represent input parameters + supplied by the submitting client in the job submission + protocol. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobPriority(50), Integer32 (-2..100) INTEGER: The priority for scheduling the job. It is used by servers and devices that employ a priority-based scheduling algorithm. A higher value specifies a higher priority. The value 1 is defined to indicate the lowest possible priority (a job which a priority-based scheduling algorithm SHALL pass over in favor of higher priority jobs). The value 100 is defined to indicate the highest possible priority. Priority is expected to be evenly or 'normally' distributed across this range. The mapping of vendor-defined priority over this range is implementation- specific. -2 indicates unknown. jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC) OCTETS: The calendar date and time of day after which the job SHALL become a candidate to be scheduled for processing. If the value of this attribute is in the future, the server SHALL set Bergman, et al. Informational [Page 32] RFC 2707 Job Monitoring MIB - V1.0 November 1999 the value of the job's jmJobState object to pendingHeld and add the jobProcessAfterSpecified bit value to the job's jmJobStateReasons1 object. When the specified date and time arrives, the server SHALL remove the jobProcessAfterSpecified bit value from the job's jmJobStateReasons1 object and, if no other reasons remain, SHALL change the job's jmJobState object to pending. jobHold(52), JmBooleanTC INTEGER: If the value is 'true(4)', a client has explicitly specified that the job is to be held until explicitly released. Until the job is explicitly released by a client, the job SHALL be in the pendingHeld state with the jobHoldSpecified value in the jmJobStateReasons1 attribute. jobHoldUntil(53), JmJobStringTC (SIZE(0..63)) OCTETS: The named time period during which the job SHALL become a candidate for processing, such as 'evening', 'night', ' weekend', 'second-shift', 'third-shift', etc., (supported values configured by the system administrator). See IPP [ipp-model] for the standard keyword values. Until that time period arrives, the job SHALL be in the pendingHeld state with the jobHoldUntilSpecified value in the jmJobStateReasons1 object. The value 'no-hold' SHALL indicate explicitly that no time period has been specified; the absence of this attribute SHALL indicate implicitly that no time period has been specified. outputBin(54), Integer32 (0..2147483647) AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The output subunit index in the Printer MIB [print-mib] AND/OR OCTETS: MULTI-ROW: the name or number (represented as ASCII digits) of the output bin to which all or part of the job is placed in. sides(55), Integer32 (-2..2) INTEGER: MULTI-ROW: The number of sides, '1' or '2', that any document in this job requires/used. finishing(56), JmFinishingTC INTEGER: MULTI-ROW: Type of finishing that any document in this job requires/used. Bergman, et al. Informational [Page 33] RFC 2707 Job Monitoring MIB - V1.0 November 1999 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Image Quality attributes (requested and consumed) (70 - 87) + + For devices that can vary the image quality. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ printQualityRequested(70), JmPrintQualityTC INTEGER: MULTI-ROW: The print quality selection requested for a document in the job for printers that allow quality differentiation. printQualityUsed(71), JmPrintQualityTC INTEGER: MULTI-ROW: The print quality selection actually used by a document in the job for printers that allow quality differentiation. printerResolutionRequested(72), JmPrinterResolutionTC OCTETS: MULTI-ROW: The printer resolution requested for a document in the job for printers that support resolution selection. printerResolutionUsed(73), JmPrinterResolutionTC OCTETS: MULTI-ROW: The printer resolution actually used by a document in the job for printers that support resolution selection. tonerEcomonyRequested(74), JmTonerEconomyTC INTEGER: MULTI-ROW: The toner economy selection requested for documents in the job for printers that allow toner economy differentiation. tonerEcomonyUsed(75), JmTonerEconomyTC INTEGER: MULTI-ROW: The toner economy selection actually used by documents in the job for printers that allow toner economy differentiation. tonerDensityRequested(76) Integer32 (-2..100) INTEGER: MULTI-ROW: The toner density requested for a document in this job for devices that can vary toner density levels. Level 1 is the lowest density and level 100 is the highest density level. Devices with a smaller range, SHALL map the 1-100 range evenly onto the implemented range. tonerDensityUsed(77), Integer32 (-2..100) INTEGER: MULTI-ROW: The toner density used by documents in this job for devices that can vary toner density levels. Level Bergman, et al. Informational [Page 34] RFC 2707 Job Monitoring MIB - V1.0 November 1999 1 is the lowest density and level 100 is the highest density level. Devices with a smaller range, SHALL map the 1-100 range evenly onto the implemented range. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Job Progress attributes (requested and consumed) (90-109) + + Pairs of these attributes can be used by monitoring + applications to show an indication of relative progress + to users. See section 3.4, entitled: + 'Monitoring Job Progress'. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobCopiesRequested(90), Integer32 (-2..2147483647) INTEGER: The number of copies of the entire job that are to be produced. jobCopiesCompleted(91), Integer32 (-2..2147483647) INTEGER: The number of copies of the entire job that have been completed so far. documentCopiesRequested(92), Integer32 (-2..2147483647) INTEGER: The total count of the number of document copies requested for the job as a whole. If there are documents A, B, and C, and document B is specified to produce 4 copies, the number of document copies requested is 6 for the job. This attribute SHALL be used only when a job has multiple documents. The jobCopiesRequested attribute SHALL be used when the job has only one document. documentCopiesCompleted(93), Integer32 (-2..2147483647) INTEGER: The total count of the number of document copies completed so far for the job as a whole. If there are documents A, B, and C, and document B is specified to produce 4 copies, the number of document copies starts a 0 and runs up to 6 for the job as the job processes. This attribute SHALL be used only when a job has multiple documents. The jobCopiesCompleted attribute SHALL be used when the job has only one document. jobKOctetsTransferred(94), Integer32 (-2..2147483647) INTEGER: The number of K (1024) octets transferred to the server or device to which the agent is providing access. This count is independent of the number of copies of the job or documents that will be produced, but it is only a measure of the number of bytes transferred to the server or device. Bergman, et al. Informational [Page 35] RFC 2707 Job Monitoring MIB - V1.0 November 1999 The agent SHALL round the actual number of octets transferred up to the next higher K. Thus 0 octets SHALL be represented as ' 0', 1-1024 octets SHALL BE represented as '1', 1025-2048 SHALL be '2', etc. When the job completes, the values of the jmJobKOctetsPerCopyRequested object and the jobKOctetsTransferred attribute SHALL be equal. NOTE - The jobKOctetsTransferred can be used with the jmJobKOctetsPerCopyRequested object in order to produce a relative indication of the progress of the job for agents that do not implement the jmJobKOctetsProcessed object. sheetCompletedCopyNumber(95), Integer32 (-2..2147483647) INTEGER: The number of the copy being stacked for the current document. This number starts at 0, is set to 1 when the first sheet of the first copy for each document is being stacked and is equal to n where n is the nth sheet stacked in the current document copy. See section 3.4 , entitled 'Monitoring Job Progress'. sheetCompletedDocumentNumber(96), Integer32 (-2..2147483647) INTEGER: The ordinal number of the document in the job that is currently being stacked. This number starts at 0, increments to 1 when the first sheet of the first document in the job is being stacked, and is equal to n where n is the nth document in the job, starting with 1. Implementations that only support one document jobs SHOULD NOT implement this attribute. jobCollationType(97), JmJobCollationTypeTC INTEGER: The type of job collation. See also Section 3.4, entitled 'Monitoring Job Progress'. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Impression attributes (110 - 129 decimal) + + See the definition of the terms 'impression', 'sheet', + and 'page' in Section 2. + + See also jmJobImpressionsPerCopyRequested and + jmJobImpressionsCompleted objects in the jmJobTable. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ impressionsSpooled(110), Integer32 (-2..2147483647) INTEGER: The number of impressions spooled to the server or device for the job so far. Bergman, et al. Informational [Page 36] RFC 2707 Job Monitoring MIB - V1.0 November 1999 impressionsSentToDevice(111), Integer32 (-2..2147483647) INTEGER: The number of impressions sent to the device for the job so far. impressionsInterpreted(112), Integer32 (-2..2147483647) INTEGER: The number of impressions interpreted for the job so far. impressionsCompletedCurrentCopy(113), Integer32 (-2..2147483647) INTEGER: The number of impressions completed by the device for the current copy of the current document so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. This value SHALL be reset to 0 for each document in the job and for each document copy. fullColorImpressionsCompleted(114), Integer32 (-2..2147483647) INTEGER: The number of full color impressions completed by the device for this job so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. Full color impressions are typically defined as those requiring 3 or more colorants, but this MAY vary by implementation. In any case, the value of this attribute counts by 1 for each side that has full color, not by the number of colors per side (and the other impression counters are incremented, except highlightColorImpressionsCompleted(115)). highlightColorImpressionsCompleted(115), Integer32 (-2..2147483647) INTEGER: The number of highlight color impressions completed by the device for this job so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. Highlight color impressions are typically defined as those requiring black plus one other colorant, but this MAY vary by implementation. In any case, the value of this attribute counts by 1 for each side that has highlight color (and the other impression counters are incremented, except fullColorImpressionsCompleted(114)). Bergman, et al. Informational [Page 37] RFC 2707 Job Monitoring MIB - V1.0 November 1999 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Page attributes (130 - 149 decimal) + + See the definition of 'impression', 'sheet', and 'page' + in Section 2. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ pagesRequested(130), Integer32 (-2..2147483647) INTEGER: The number of logical pages requested by the job to be processed. pagesCompleted(131), Integer32 (-2..2147483647) INTEGER: The number of logical pages completed for this job so far. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the pagesRequested object. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the pagesRequested object. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The pagesCompleted object can be used with the pagesRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies. pagesCompletedCurrentCopy(132), Integer32 (-2..2147483647) INTEGER: The number of logical pages completed for the current copy of the document so far. This value SHALL be reset to 0 for each document in the job and for each document copy. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Sheet attributes (150 - 169 decimal) + + See the definition of 'impression', 'sheet', and 'page' + in Section 2. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Bergman, et al. Informational [Page 38] RFC 2707 Job Monitoring MIB - V1.0 November 1999 sheetsRequested(150), Integer32 (-2..2147483647) INTEGER: The total number of medium sheets requested to be produced for this job. Unlike the jmJobKOctetsPerCopyRequested and jmJobImpressionsPerCopyRequested attributes, the sheetsRequested(150) attribute SHALL include the multiplicative factor contributed by the number of copies and so is the total number of sheets to be produced by the job, as opposed to the size of the document(s) submitted. sheetsCompleted(151), Integer32 (-2..2147483647) INTEGER: The total number of medium sheets that have completed marking and stacking for the entire job so far whether those sheets have been processed on one side or on both. sheetsCompletedCurrentCopy(152), Integer32 (-2..2147483647) INTEGER: The number of medium sheets that have completed marking and stacking for the current copy of a document in the job so far whether those sheets have been processed on one side or on both. The value of this attribute SHALL be 0 before the job starts processing and SHALL be reset to 1 after the first sheet of each document and document copy in the job is processed and stacked. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Resources attributes (requested and consumed) (170 - 189) + + Pairs of these attributes can be used by monitoring + applications to show an indication of relative usage to + users, i.e., a 'thermometer'. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ mediumRequested(170), JmMediumTypeTC AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The type AND/OR OCTETS: MULTI-ROW: the name of the medium that is required by the job. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib] and the name, size, and input tray values of the IPP 'media' attribute [ipp-model]. Bergman, et al. Informational [Page 39] RFC 2707 Job Monitoring MIB - V1.0 November 1999 mediumConsumed(171), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets AND OCTETS: MULTI-ROW: the name of the medium that has been consumed so far whether those sheets have been processed on one side or on both. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtInputMediaName object in the Printer MIB [print-mib] and the name, size, and input tray values of the IPP 'media' attribute [ipp-model]. colorantRequested(172), Integer32 (-2..2147483647) AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The index (prtMarkerColorantIndex) in the Printer MIB [print-mib] AND/OR OCTETS: MULTI-ROW: the name of the colorant requested. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtMarkerColorantValue object in the Printer MIB. Examples are: red, blue. colorantConsumed(173), Integer32 (-2..2147483647) AND/OR JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The index (prtMarkerColorantIndex) in the Printer MIB [print-mib] AND/OR OCTETS: MULTI-ROW: the name of the colorant consumed. NOTE - The name (JmJobStringTC) values correspond to the name values of the prtMarkerColorantValue object in the Printer MIB. Examples are: red, blue Bergman, et al. Informational [Page 40] RFC 2707 Job Monitoring MIB - V1.0 November 1999 mediumTypeConsumed(174), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets of the indicated medium type that has been consumed so far whether those sheets have been processed on one side or on both AND OCTETS: MULTI-ROW: the name of that medium type. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The type name (JmJobStringTC) values correspond to the type name values of the prtInputMediaType object in the Printer MIB [print-mib]. Values are: 'stationery', 'transparency', 'envelope', etc. These medium type names correspond to the enum values of JmMediumTypeTC used in the mediumRequested attribute. mediumSizeConsumed(175), Integer32 (-2..2147483647) AND JmJobStringTC (SIZE(0..63)) INTEGER: MULTI-ROW: The number of sheets of the indicated medium size that has been consumed so far whether those sheets have been processed on one side or on both AND OCTETS: MULTI-ROW: the name of that medium size. This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values. NOTE - The size name (JmJobStringTC) values correspond to the size name values in the Printer MIB [print-mib] Appendix B. These size name values are also a subset of the keyword values defined by [ipp-model] for the 'media' Job Template attribute. Values are: 'letter', 'a', 'iso- a4', 'jis-b4', etc. Bergman, et al. Informational [Page 41] RFC 2707 Job Monitoring MIB - V1.0 November 1999 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Time attributes (set by server or device) (190 - 209 decimal) + + This section of attributes are ones that are set by the + server or device that accepts jobs. Two forms of time are + provided. Each form is represented in a separate attribute. + See section 3.1.2 and section 3.1.3 for the + conformance requirements for time attribute for agents and + monitoring applications, respectively. The two forms are: + + 'DateAndTime' is an 8 or 11 octet binary encoded year, + month, day, hour, minute, second, deci-second with + optional offset from UTC. See SNMPv2-TC [SMIv2-TC]. + + NOTE: 'DateAndTime' is not printable characters; it is + binary. + + 'JmTimeStampTC' is the time of day measured in the number of + seconds since the system was booted. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ jobSubmissionToServerTime(190), JmTimeStampTC AND/OR DateAndTime INTEGER: Configuration 3 only: The time AND/OR OCTETS: the date and time that the job was submitted to the server (as distinguished from the device which uses jobSubmissionTime). jobSubmissionTime(191), JmTimeStampTC AND/OR DateAndTime INTEGER: Configurations 1, 2, and 3: The time AND/OR OCTETS: the date and time that the job was submitted to the server or device to which the agent is providing access. jobStartedBeingHeldTime(192), JmTimeStampTC AND/OR DateAndTime INTEGER: The time AND/OR OCTETS: the date and time that the job last entered the pendingHeld state. If the job has never entered the pendingHeld state, then the value SHALL be '0' or the attribute SHALL not be present in the table. Bergman, et al. Informational [Page 42] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jobStartedProcessingTime(193), JmTimeStampTC AND/OR DateAndTime INTEGER: The time AND/OR OCTETS: the date and time that the job started processing. jobCompletionTime(194), JmTimeStampTC AND/OR DateAndTime INTEGER: The time AND/OR OCTETS: the date and time that the job entered the completed, canceled, or aborted state. jobProcessingCPUTime(195) Integer32 (-2..2147483647) UNITS 'seconds' INTEGER: The amount of CPU time in seconds that the job has been in the processing state. If the job enters the processingStopped state, that elapsed time SHALL not be included. In other words, the jobProcessingCPUTime value SHOULD be relatively repeatable when the same job is processed again on the same device. 3.3.9 Job State Reason bit definitions The JmJobStateReasonsNTC (N=1..4) textual-conventions are used with the jmJobStateReasons1 object and jobStateReasonsN (N=2..4), respectively, to provide additional information regarding the current jmJobState object value. These values MAY be used with any job state or states for which the reason makes sense. NOTE - While values cannot be added to the jmJobState object without impacting deployed clients that take actions upon receiving jmJobState values, it is the intent that additional JmJobStateReasonsNTC enums can be defined and registered without impacting such deployed clients. In other words, the jmJobStateReasons1 object and jobStateReasonsN attributes are intended to be extensible. NOTE - The Job Monitoring MIB contains a superset of the IPP values [ipp-model] for the IPP 'job-state-reasons' attribute, since the Job Monitoring MIB is intended to cover other job submission protocols as well. Also some of the names of the reasons have been changed from ' printer' to 'device', since the Job Monitoring MIB is intended to cover additional types of devices, including input devices, such as scanners. Bergman, et al. Informational [Page 43] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.3.9.1 JmJobStateReasons1TC specification The following standard values are defined (in hexadecimal) as powers of two, since multiple values MAY be used at the same time. For ease of understanding, the JmJobStateReasons1TC reasons are presented in the order in which the reasons are likely to occur (if implemented), starting with the 'jobIncoming' value and ending with the ' jobCompletedWithErrors' value. other 0x1 The job state reason is not one of the standardized or registered reasons. unknown 0x2 The job state reason is not known to the agent or is indeterminent. jobIncoming 0x4 The job has been accepted by the server or device, but the server or device is expecting (1) additional operations from the client to finish creating the job and/or (2) is accessing/accepting document data. submissionInterrupted 0x8 The job was not completely submitted for some unforeseen reason, such as: (1) the server has crashed before the job was closed by the client, (2) the server or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the server, (3) the client crashed or failed to close the job before the time-out period. jobOutgoing 0x10 Configuration 2 only: The server is transmitting the job to the device. jobHoldSpecified 0x20 The value of the job's jobHold(52) attribute is TRUE. The job SHALL NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job. jobHoldUntilSpecified 0x40 The value of the job's jobHoldUntil(53) attribute specifies a time period that is still in the future. The job SHALL NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job. Bergman, et al. Informational [Page 44] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jobProcessAfterSpecified 0x80 The value of the job's jobProcessAfterDateAndTime(51) attribute specifies a time that is still in the future. The job SHALL NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job. resourcesAreNotReady 0x100 At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical devices for which the job is a candidate. This condition MAY be detected when the job is accepted, or subsequently while the job is pending or processing, depending on implementation. deviceStoppedPartly 0x200 One or more, but not all, of the devices to which the job is assigned are stopped. If all of the devices are stopped (or the only device is stopped), the deviceStopped reason SHALL be used. deviceStopped 0x400 The device(s) to which the job is assigned is (are all) stopped. jobInterpreting 0x800 The device to which the job is assigned is interpreting the document data. jobPrinting 0x1000 The output device to which the job is assigned is marking media. This value is useful for servers and output devices which spend a great deal of time processing (1) when no marking is happening and then want to show that marking is now happening or (2) when the job is in the process of being canceled or aborted while the job remains in the processing state, but the marking has not yet stopped so that impression or sheet counts are still increasing for the job. jobCanceledByUser 0x2000 The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job's jmJobOwner object, or by some other authorized end-user, such as a member of the job owner's security group. jobCanceledByOperator 0x4000 The job was canceled by the operator, i.e., by a user who has been authenticated as having operator privileges (whether local or remote). Bergman, et al. Informational [Page 45] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jobCanceledAtDevice 0x8000 The job was canceled by an unidentified local user, i.e., a user at a console at the device. abortedBySystem 0x10000 The job (1) is in the process of being aborted, (2) has been aborted by the system and placed in the 'aborted' state, or (3) has been aborted by the system and placed in the 'pendingHeld' state, so that a user or operator can manually try the job again. processingToStopPoint 0x20000 The requester has issued an operation to cancel or interrupt the job or the server/device has aborted the job, but the server/device is still performing some actions on the job until a specified stop point occurs or job termination/cleanup is completed. This reason is recommended to be used in conjunction with the processing job state to indicate that the server/device is still performing some actions on the job while the job remains in the processing state. After all the job's resources consumed counters have stopped incrementing, the server/device moves the job from the processing state to the canceled or aborted job states. serviceOffLine 0x40000 The service or document transform is off-line and accepting no jobs. All pending jobs are put into the pendingHeld state. This situation could be true if the service's or document transform's input is impaired or broken. jobCompletedSuccessfully 0x80000 The job completed successfully. jobCompletedWithWarnings 0x100000 The job completed with warnings. jobCompletedWithErrors 0x200000 The job completed with errors (and possibly warnings too). The following additional job state reasons have been added to represent job states that are in ISO DPA [iso-dpa] and other job submission protocols: Bergman, et al. Informational [Page 46] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jobPaused 0x400000 The job has been indefinitely suspended by a client issuing an operation to suspend the job so that other jobs may proceed using the same devices. The client MAY issue an operation to resume the paused job at any time, in which case the agent SHALL remove the jobPaused values from the job's jmJobStateReasons1 object and the job is eventually resumed at or near the point where the job was paused. jobInterrupted 0x800000 The job has been interrupted while processing by a client issuing an operation that specifies another job to be run instead of the current job. The server or device will automatically resume the interrupted job when the interrupting job completes. jobRetained 0x1000000 The job is being retained by the server or device with all of the job's document data (and submitted resources, such as fonts, logos, and forms, if any). Thus a client could issue an operation to the server or device to either (1) re-do the job (or a copy of the job) on the same server or device or (2) resubmit the job to another server or device. When a client could no longer re-do/resubmit the job, such as after the document data has been discarded, the agent SHALL remove the jobRetained value from the jmJobStateReasons1 object. These bit definitions are the equivalent of a type 2 enum except that combinations of bits may be used together. See section 3.7.1.2. The remaining bits are reserved for future standardization and/or registration. 3.3.9.2 JmJobStateReasons2TC specification The following standard values are defined (in hexadecimal) as powers of two, since multiple values MAY be used at the same time. cascaded 0x1 An outbound gateway has transmitted all of the job's job and document attributes and data to another spooling system. deletedByAdministrator 0x2 The administrator has deleted the job. discardTimeArrived 0x4 The job has been deleted due to the fact that the time specified by the job's job-discard-time attribute has arrived. Bergman, et al. Informational [Page 47] RFC 2707 Job Monitoring MIB - V1.0 November 1999 postProcessingFailed 0x8 The post-processing agent failed while trying to log accounting attributes for the job; therefore the job has been placed into the completed state with the jobRetained jmJobStateReasons1 object value for a system-defined period of time, so the administrator can examine it, resubmit it, etc. jobTransforming 0x10 The server/device is interpreting document data and producing another electronic representation. maxJobFaultCountExceeded 0x20 The job has faulted several times and has exceeded the administratively defined fault count limit. devicesNeedAttentionTimeOut 0x40 One or more document transforms that the job is using needs human intervention in order for the job to make progress, but the human intervention did not occur within the site-settable time-out value. needsKeyOperatorTimeOut 0x80 One or more devices or document transforms that the job is using need a specially trained operator (who may need a key to unlock the device and gain access) in order for the job to make progress, but the key operator intervention did not occur within the site-settable time-out value. jobStartWaitTimeOut 0x100 The server/device has stopped the job at the beginning of processing to await human action, such as installing a special cartridge or special non-standard media, but the job was not resumed within the site-settable time-out value and the server/device has transitioned the job to the pendingHeld state. jobEndWaitTimeOut 0x200 The server/device has stopped the job at the end of processing to await human action, such as removing a special cartridge or restoring standard media, but the job was not resumed within the site-settable time-out value and the server/device has transitioned the job to the completed state. jobPasswordWaitTimeOut 0x400 The server/device has stopped the job at the beginning of processing to await input of the job's password, but the password was not received within the site-settable time-out value. Bergman, et al. Informational [Page 48] RFC 2707 Job Monitoring MIB - V1.0 November 1999 deviceTimedOut 0x800 A device that the job was using has not responded in a period specified by the device's site-settable attribute. connectingToDeviceTimeOut 0x1000 The server is attempting to connect to one or more devices which may be dial-up, polled, or queued, and so may be busy with traffic from other systems, but server was unable to connect to the device within the site-settable time-out value. transferring 0x2000 The job is being transferred to a down stream server or downstream device. queuedInDevice 0x4000 The server/device has queued the job in a down stream server or downstream device. jobQueued 0x8000 The server/device has queued the document data. jobCleanup 0x10000 The server/device is performing cleanup activity as part of ending normal processing. jobPasswordWait 0x20000 The server/device has selected the job to be next to process, but instead of assigning resources and starting the job processing, the server/device has transitioned the job to the pendingHeld state to await entry of a password (and dispatched another job, if there is one). validating 0x40000 The server/device is validating the job after accepting the job. queueHeld 0x80000 The operator has held the entire job set or queue. jobProofWait 0x100000 The job has produced a single proof copy and is in the pendingHeld state waiting for the requester to issue an operation to release the job to print normally, obeying any job and document copy attributes that were originally submitted. heldForDiagnostics 0x200000 The system is running intrusive diagnostics, so that all jobs are being held. Bergman, et al. Informational [Page 49] RFC 2707 Job Monitoring MIB - V1.0 November 1999 noSpaceOnServer 0x800000 There is no room on the server to store all of the job. pinRequired 0x1000000 The System Administrator settable device policy is (1) to require PINs, and (2) to hold jobs that do not have a pin supplied as an input parameter when the job was created. exceededAccountLimit 0x2000000 The account for which this job is drawn has exceeded its limit. This condition SHOULD be detected before the job is scheduled so that the user does not wait until his/her job is scheduled only to find that the account is overdrawn. This condition MAY also occur while the job is processing either as processing begins or part way through processing. heldForRetry 0x4000000 The job encountered some errors that the server/device could not recover from with its normal retry procedures, but the error might not be encountered if the job is processed again in the future. Example cases are phone number busy or remote file system in-accessible. For such a situation, the server/device SHALL transition the job from the processing to the pendingHeld, rather than to the aborted state. The following values are from the X/Open PSIS draft standard: canceledByShutdown 0x8000000 The job was canceled because the server or device was shutdown before completing the job. deviceUnavailable 0x10000000 This job was aborted by the system because the device is currently unable to accept jobs. wrongDevice 0x20000000 This job was aborted by the system because the device is unable to handle this particular job; the spooler SHOULD try another device or the user should submit the job to another device. badJob 0x40000000 This job was aborted by the system because this job has a major problem, such as an ill-formed PDL; the spooler SHOULD not even try another device. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 3.7.1.2. Bergman, et al. Informational [Page 50] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.3.9.3 JmJobStateReasons3TC specification This textual-convention is used with the jobStateReasons3 attribute to provides additional information regarding the jmJobState object. The following standard values are defined (in hexadecimal) as powers of two, since multiple values may be used at the same time: jobInterruptedByDeviceFailure 0x1 A device or the print system software that the job was using has failed while the job was processing. The server or device is keeping the job in the pendingHeld state until an operator can determine what to do with the job. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 3.7.1.2. The remaining bits are reserved for future standardization and/or registration. 3.3.9.4 JmJobStateReasons4TC specification This textual-convention is used with the jobStateReasons4 attribute to provides additional information regarding the jmJobState object. The following standard values are defined (in hexadecimal) as powers of two, since multiple values MAY be used at the same time. None defined at this time. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 3.7.1.2. The remaining bits are reserved for future standardization and/or registration. 3.4 Monitoring Job Progress There are a number of objects and attributes for monitoring the progress of a job. These objects and attributes count the number of K octets, impressions, sheets, and pages requested or completed. For impressions and sheets, "completed" means stacked, unless the implementation is unable to detect when each sheet is stacked, in which case stacked is approximated when processing of each sheet completes. There are objects and attributes for the overall job and for the current copy of the document currently being stacked. For the latter, the rate at which the various objects and attributes count depends on the sheet and document collation of the job. Bergman, et al. Informational [Page 51] RFC 2707 Job Monitoring MIB - V1.0 November 1999 Job Collation included sheet collation and document collation. Sheet collation is defined to be the ordering of sheets within a document copy. Document collation is defined to be ordering of document copies within a multi-document job. There are three types of job collation (see terminology definitions in Section 2): 1.uncollatedSheets(3) - No collation of the sheets within each document copy, i.e., each sheet of a document that is to produce multiple copies is replicated before the next sheet in the document is processed and stacked. If the device has an output bin collator, the uncollatedSheets(3) value may actually produce collated sheets as far as the user is concerned (in the output bins). However, when the job collation is the to a monitoring application between a device that has an output bin collator and one that does not. 2.collatedDocuments(4) - Collation of the sheets within each document copy is performed within the printing device by making multiple passes over either the source or an intermediate representation of the document. In addition, when there are multiple documents per job, the i'th copy of each document is stacked before the j'th copy of each document, i.e., the documents are collated within each job copy. For example, if a job is submitted with documents, A and B, the job is made available to the end user as: A, B, A, B, .... The ' collatedDocuments(4)' value corresponds to the IPP [ipp-model] ' separate-documents-collated-copies' value of the "multiple- document-handling" attribute. If jobCopiesRequested or documentCopiesRequested = 1, then jobCollationType is defined as 4. 3.uncollatedDocuments(5) - Collation of the sheets within each document copy is performed within the printing device by making multiple passes over either the source or an intermediate representation of the document. In addition, when there are multiple documents per job, all copies of the first document in the job are stacked before the any copied of the next document in the job, i.e., the documents are uncollated within the job. For example, if a job is submitted with documents, A and B, the job is mad available to the end user as: A, A, ..., B, B, .... The 'uncollatedDocuments(5)' value corresponds to the IPP [ipp-model] 'separate-documents-uncollated-copies' value of the "multiple- document-handling" attribute. Consider the following four variables that are used to monitor the progress of a job's impressions: Bergman, et al. Informational [Page 52] RFC 2707 Job Monitoring MIB - V1.0 November 1999 1.jmJobImpressionsCompleted - counts the total number of impressions stacked for the job 2.impressionsCompletedCurrentCopy - counts the number of impressions stacked for the current document copy 3.sheetCompletedCopyNumber - identifies the number of the copy for the current document being stacked where the first copy is 1. 4.sheetCompletedDocumentNumber - identifies the current document within the job that is being stacked where the first document in a job is 1. NOTE: this attribute SHOULD NOT be implemented for implementations that only support one document per job. For each of the three types of job collation, a job with three copies of two documents (1, 2), where each document consists of 3 impressions, the four variables have the following values as each sheet is stacked for one-sided printing: Job Collation Type = uncollatedSheets(3) jmJobImpressions Impressions sheetCompleted sheetCompleted Completed CompletedCurrent CopyNumber DocumentNumber Copy 0 0 0 0 1 1 1 1 2 1 2 1 3 1 3 1 4 2 1 1 5 2 2 1 6 2 3 1 7 3 1 1 8 3 2 1 9 3 3 1 10 1 1 2 11 1 2 2 12 1 3 2 13 2 1 2 14 2 2 2 15 2 3 2 16 3 1 2 17 3 2 2 18 3 3 2 Bergman, et al. Informational [Page 53] RFC 2707 Job Monitoring MIB - V1.0 November 1999 Job Collation Type = collatedDocuments(4) JmJobImpressions Impressions sheetCompleted sheetCompleted Completed CompletedCurrent CopyNumber DocumentNumber Copy 0 0 0 0 1 1 1 1 2 2 1 1 3 3 1 1 4 1 1 2 5 2 1 2 6 3 1 2 7 1 2 1 8 2 2 1 9 3 2 1 10 1 2 2 11 2 2 2 12 3 2 2 13 1 3 1 14 2 3 1 15 3 3 1 16 1 3 2 17 2 3 2 18 3 3 2 Bergman, et al. Informational [Page 54] RFC 2707 Job Monitoring MIB - V1.0 November 1999 Job Collation Type = uncollatedDocuments(5) jmJobImpressions Impressions sheetCompleted sheetCompleted Completed CompletedCurrent CopyNumber DocumentNumber Copy 0 0 0 0 1 1 1 1 2 2 1 1 3 3 1 1 4 1 2 1 5 2 2 1 6 3 2 1 7 1 3 1 8 2 3 1 9 3 3 1 10 1 1 2 11 2 1 2 12 3 1 2 13 1 2 2 14 2 2 2 15 3 2 2 16 1 3 2 17 2 3 2 18 3 3 2 3.5 Job Identification There are a number of attributes that permit a user, operator or system administrator to identify jobs of interest, such as jobURI, jobName, jobOriginatingHost, etc. In addition, there is a jmJobSubmissionID object that is a text string table index. Being a table index allows a monitoring application to quickly locate and identify a particular job of interest that was submitted from a particular client by the user invoking the monitoring application without having to scan the entire job table. The Job Monitoring MIB needs to provide for identification of the job at both sides of the job submission process. The primary identification point is the client side. The jmJobSubmissionID allows the monitoring application to identify the job of interest from all the jobs currently "known" by the server or device. The value of jmJobSubmissionID can be assigned by either the client's local system or a downstream server or device. The point of assignment depends on the job submission protocol in use. Bergman, et al. Informational [Page 55] RFC 2707 Job Monitoring MIB - V1.0 November 1999 The server/device-side identifier, called the jmJobIndex object, SHALL be assigned by the SNMP Job Monitoring MIB agent when the server or device accepts the jobs from submitting clients. The jmJobIndex object allows the interested party to obtain all objects desired that relate to a particular job. See Section 3.2, entitled ' The Job Tables and the Oldest Active and Newest Active Indexes' for the specification of how the agent SHALL assign the jmJobIndex values. The MIB provides a mapping table that maps each jmJobSubmissionID value to a corresponding jmJobIndex value generated by the agent, so that an application can determine the correct value for the jmJobIndex value for the job of interest in a single Get operation, given the Job Submission ID. See the jmJobIDGroup. In some configurations there may be more than one application program that monitors the same job when the job passes from one network entity to another when it is submitted. See configuration 3. When there are multiple job submission IDs, each entity MAY supply an appropriate jmJobSubmissionID value. In this case there would be a separate entry in the jmJobSubmissionID table, one for each jmJobSubmissionID. All entries would map to the same jmJobIndex that contains the job data. When the job is deleted, it is up to the agent to remove all entries that point to the job from the jmJobSubmissionID table as well. The jobName attribute provides a name that the user supplies as a job attribute with the job. The jobName attribute is not necessarily unique, even for one user, let alone across users. 3.5.1 The Job Submission ID specifications This section specifies the formats for each of the registered Job Submission Ids. This format is used by the JmJobSubmissionIDTypeTC. Each job submission ID is a fixed-length, 48-octet printable US-ASCII [US-ASCII] coded character string containing no control characters, consisting of the following fields: octet 1: The format letter identifying the format. The US-ASCII characters '0-9', 'A-Z', and 'a-z' are assigned in order giving 62 possible formats. octets 2-40: A 39-character, US-ASCII trailing SPACE filled field specified by the format letter, if the data is less than 39 ASCII characters. octets 41-48: A sequential or random US-ASCII number to make the ID quasi-unique. Bergman, et al. Informational [Page 56] RFC 2707 Job Monitoring MIB - V1.0 November 1999 If the client does not supply a job submission ID in the job submission protocol, then the agent SHALL assign a job submission ID using any of the standard formats that are reserved for the agent. Clients SHALL not use formats that are reserved for agents and agents SHALL NOT use formats that are reserved for clients, in order to reduce conflicts in ID generation. See the description for which formats are reserved for clients or for agents. Registration of additional formats may be done following the procedures described in Section 3.7.3. The format values defined at the time of completion of this specification are: Format Letter Description ------ ------------ '0' Job Owner generated by the server/device octets 2-40: The last 39 bytes of the jmJobOwner object. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the agent. This format is reserved for agents. NOTE - Clients wishing to use a job submission ID that incorporates the job owner, SHALL use format '8', not format '0'. '1' Job Name octets 2-40: The last 39 bytes of the jobName attribute. octets 41-48: The US-ASCII 8-decimal-digit random number assigned by the client. This format is reserved for clients. '2' Client MAC address octets 2-40: The client MAC address: in hexadecimal with each nibble of the 6 octet address being '0'-'9' or 'A' - 'F' (uppercase only). Most significant octet first. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients. '3' Client URL octets 2-40: The last 39 bytes of the client URL [URI-spec]. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients. Bergman, et al. Informational [Page 57] RFC 2707 Job Monitoring MIB - V1.0 November 1999 '4' Job URI octets 2-40: The last 39 bytes of the URI [URI-spec] assigned by the server or device to the job when the job was submitted for processing. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the agent. This format is reserved for agents. '5' POSIX User Number octets 2-40: The last 39 bytes of a user number, such as POSIX user number. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients. '6' User Account Number octets 2-40: The last 39 bytes of the user account number. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients. '7' DTMF Incoming FAX routing number octets 2-40: The last 39 bytes of the DTMF incoming FAX routing number. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients. '8' Job Owner supplied by the client octets 2-40: The last 39 bytes of the job owner name (that the agent returns in the jmJobOwner object). octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients. See format '0' which is reserved for agents. '9' Host Name octets 2-40: The last 39 bytes of the host name with trailing SPACES that submitted the job to this server/device using a protocol, such as LPD [RFC1179] which includes the host name in the job submission protocol. octets 41-48: The US-ASCII 8-decimal-digit leading zero representation of the job id generated by the submitting server (configuration 3) or the client (configuration 1 and 2), such as in the LPD protocol. This format is reserved for clients. Bergman, et al. Informational [Page 58] RFC 2707 Job Monitoring MIB - V1.0 November 1999 'A' AppleTalk Protocol octets 2-40: Contains the AppleTalk printer name, with the first character of the name in octet 2. AppleTalk printer names are a maximum of 31 characters. Any unused portion of this field shall be filled with spaces. octets 41-48: '00000XXX', where 'XXX' is the 3-digit US-ASCII decimal representation of the Connection Id. This format is reserved for agents. 'B' NetWare PServer octets 2-40: Contains the Directory Path Name as recorded by the Novell File Server in the queue directory. If the string is less than 40 octets, the left-most character in the string shall appear in octet position 2. Otherwise, only the last 39 bytes shall be included. Any unused portion of this field shall be filled with spaces. octets 41-48: '000XXXXX' The US-ASCII representation of the Job Number as per the NetWare File Server Queue Management Services. This format is reserved for agents. 'C' Server Message Block protocol (SMB) octets 2-40: Contains a decimal (US-ASCII coded) representation of the 16 bit SMB Tree Id field, which uniquely identifies the connection that submitted the job to the printer. The most significant digit of the numeric string shall be placed in octet position 2. All unused portions of this field shall be filled with spaces. The SMB Tree Id has a maximum value of 65,535. octets 41-48: The US-ASCII 8-decimal-digit leading zero representation of the File Handle returned from the device to the client in response to a Create Print File command. This format is reserved for agents. 'D' Transport Independent Printer/System Interface (TIP/SI) octets 2-40: Contains the Job Name from the Job Control-Start Job (JC-SJ) command. If the Job Name portion is less than 40 octets, the left-most character in the string shall appear in octet position 2. Any unused portion of this field shall be filled with spaces. Otherwise, only the last 39 bytes shall be included. octets 41-48: The US-ASCII 8-decimal-digit leading zero representation of the jmJobIndex assigned by the agent. This format is reserved for agents, since the agent supplies octets 41-48, though the client supplies the job name. See format '1' reserved to clients to submit job name ids in which they supply octets 41-48. Bergman, et al. Informational [Page 59] RFC 2707 Job Monitoring MIB - V1.0 November 1999 'E' IPDS on the MVS or VSE platform octets 2-40: Contains bytes 2-27 of the XOH Define Group Boundary Group ID triplet. Octet position 2 MUST carry the value x'01'. Bytes 28-40 MUST be filled with spaces. octets 41-48: The US-ASCII 8-decimal-digit leading zero representation of the jmJobIndex assigned by the agent. This format is reserved for agents, since the agent supplies octets 41-48, though the client supplies the job name. 'F' IPDS on the VM platform octets 2-40: Contains bytes 2-31 of the XOH Define Group Boundary Group ID triplet. Octet position 2 MUST carry the value x'02'. Bytes 32-40 MUST be filled with spaces. octets 41-48: The US-ASCII 8-decimal-digit leading zero representation of the jmJobIndex assigned by the agent. This format is reserved for agents, since the agent supplies octets 41-48, though the client supplies the file name. 'G' IPDS on the OS/400 platform octets 2-40: Contains bytes 2-36 of the XOH Define Group Boundary Group ID triplet. Octet position 2 MUST carry the value x'03'. Bytes 37-40 MUST be filled with spaces. octets 41-48: The US-ASCII 8-decimal-digit leading zero representation of the jmJobIndex assigned by the agent. This format is reserved for agents, since the agent supplies octets 41-48, though the client supplies the job name. NOTE - the job submission id is only intended to be unique between a limited set of clients for a limited duration of time, namely, for the life time of the job in the context of the server or device that is processing the job. Some of the formats include something that is unique per client and a random number so that the same job submitted by the same client will have a different job submission id. For other formats, where part of the id is guaranteed to be unique for each client, such as the MAC address or URL, a sequential number SHOULD suffice for each client (and may be easier for each client to manage). Therefore, the length of the job submission id has been selected to reduce the probability of collision to an extremely low number, but is not intended to be an absolute guarantee of uniqueness. None-the-less, collisions are remotely possible, but without bad consequences, since this MIB is intended to be used only for monitoring jobs, not for controlling and managing them. 3.6 Internationalization Considerations This section describes the internationalization considerations included in this MIB. Bergman, et al. Informational [Page 60] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.6.1 Text generated by the server or device There are a few objects and attributes generated by the server or device that SHALL be represented using the Universal Multiple-Octet Coded Character Set (UCS) [ISO-10646]. These objects and attributes are always supplied (if implemented) by the agent, not by the job submitting client: 1. jmGeneralJobSetName object 2. processingMessage(6) attribute 3. physicalDevice(32) (name value) attribute The character encoding scheme for representing these objects and attributes SHALL be UTF-8 as REQUIRED by RFC 2277 [RFC2277]. The ' JmUTF8StringTC' textual convention is used to indicate UTF-8 text strings. NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] encoding. The text contained in the processingMessage(6) attribute is generated by the server/device. The natural language for the processingMessage(6) attribute is identified by the processingMessageNaturalLangTag(7) attribute. The processingMessageNaturalLangTag(7) attribute uses the JmNaturalLanguageTagTC textual convention which SHALL conform to the language tag mechanism specified in RFC 1766 [RFC1766]. The JmNaturalLanguageTagTC value is the same as the IPP [ipp-model] ' naturalLanguage' attribute syntax. RFC 1766 specifies that a US- ASCII string consisting of the natural language followed by an optional country field. Both fields use the same two-character codes from ISO 639 [ISO-639] and ISO 3166 [ISO-3166], respectively, that are used in the Printer MIB for identifying language and country. Examples of the values of the processingMessageNaturalLangTag(7) attribute include: 1. 'en' for English 2. 'en-us' for US English 3. 'fr' for French 4. 'de' for German 3.6.2 Text supplied by the job submitter All of the objects and attributes represented by the 'JmJobStringTC' textual-convention are either (1) supplied in the job submission protocol by the client that submits the job to the server or device or (2) are defaulted by the server or device if the job submitting client does not supply values. The agent SHALL represent these Bergman, et al. Informational [Page 61] RFC 2707 Job Monitoring MIB - V1.0 November 1999 objects and attributes in the MIB either (1) in the coded character set as they were submitted or (2) MAY convert the coded character set to another coded character set or encoding scheme. In any case, the resulting coded character set representation SHOULD be UTF-8 [UTF-8], but SHALL be one in which the code positions from 0 to 31 is not used, 32 to 127 is US-ASCII [US-ASCII], 127 is not unused, and the remaining code positions 128 to 255 represent single-byte or multi- byte graphic characters structured according to ISO 2022 [ISO-2022] or are unused. The coded character set SHALL be one of the ones registered with IANA [IANA] and SHALL be identified by the jobCodedCharSet attribute in the jmJobAttributeTable for the job. If the agent does not know what coded character set was used by the job submitting client, the agent SHALL either (1) return the 'unknown(2)' value for the jobCodedCharSet attribute or (2) not return the jobCodedCharSet attribute for the job. Examples of coded character sets which meet this criteria for use as the value of the jobCodedCharSet job attribute are: US-ASCII [US- ASCII], ISO 8859-1 (Latin-1) [ISO-8859-1], any ISO 8859-n, HP Roman8, IBM Code Page 850, Windows Default 8-bit set, UTF-8 [UTF-8], US-ASCII plus JIS X0208-1990 Japanese [JIS X0208], US-ASCII plus GB2312-1980 PRC Chinese [GB2312]. See the IANA registry of coded character sets [IANA charsets]. Examples of coded character sets which do not meet this criteria are: national 7-bit sets conforming to ISO 646 (except US-ASCII), EBCDIC, and ISO 10646 (Unicode) [ISO-10646]. In order to represent Unicode characters, the UTF-8 [UTF-8] encoding scheme SHALL be used which has been assigned the MIBenum value of '106' by IANA. The jobCodedCharSet attribute uses the imported 'CodedCharSet' textual-convention from the Printer MIB [printmib]. The natural language for attributes represented by the textual- convention JmJobStringTC is identified either (1) by the jobNaturalLanguageTag(9) attribute or is keywords in US-English (as in IPP). A monitoring application SHOULD attempt to localize keywords into the language of the user by means of some lookup mechanism. If the keyword value is not known to the monitoring application, the monitoring application SHOULD assume that the value is in the natural language specified by the job's jobNaturalLanguageTag(9) attribute and SHOULD present the value to its user as is. The jobNaturalLanguageTag(9) attribute value SHALL have the same syntax and semantics as the processingMessageNaturalLangTag(7) attribute, except that the jobNaturalLanguageTag(9) attribute identifies the natural language of Bergman, et al. Informational [Page 62] RFC 2707 Job Monitoring MIB - V1.0 November 1999 attributes supplied by the job submitter instead of the natural language of the processingMessage(6) attribute. See Section 3.6.1. 3.6.3 'DateAndTime' for representing the date and time This MIB also contains objects that are represented using the DateAndTime textual convention from SMIv2 [SMIv2-TC]. The job management application SHALL display such objects in the locale of the user running the monitoring application. 3.7 IANA and PWG Registration Considerations This MIB does not require any additional registration schemes for IANA, but does depend on registration schemes that other Internet standards track specifications have set up. The names of these IANA registration assignments under the /in-notes/iana/assignments/ path: 1.printer-language-numbers - used as enums in the documentFormat(38) attribute 2.media-types - uses as keywords in the documentFormat(38) attribute 3.character-sets - used as enums in the jobCodedCharSet(8) attribute The Printer Working Group (PWG) will handle registration of additional enums after approving this standard, according to the procedures described in this section: 3.7.1 PWG Registration of enums This specification uses textual conventions to define enumerated values (enums) and bit values. Enumerations (enums) and bit values are sets of symbolic values defined for use with one or more objects or attributes. All enumeration sets and bit value sets are assigned a symbolic data type name (textual convention). As a convention the symbolic name ends in "TC" for textual convention. These enumerations are defined at the beginning of the MIB module specification. The PWG has defined several type of enumerations for use in the Job Monitoring MIB and the Printer MIB [print-mib]. These types differ in the method employed to control the addition of new enumerations. Throughout this document, references to "type n enum", where n can be 1, 2 or 3 can be found in the various tables. The definitions of these types of enumerations are: Bergman, et al. Informational [Page 63] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.7.1.1 Type 1 enumerations Type 1 enumeration: All the values are defined in the Job Monitoring MIB specification (RFC for the Job Monitoring MIB). Additional enumerated values require a new RFC. There are no type 1 enums in the current document. 3.7.1.2 Type 2 enumerations Type 2 enumeration: An initial set of values are defined in the Job Monitoring MIB specification. Additional enumerated values are registered with the PWG. The following type 2 enums are contained in the current document: 1. JmUTF8StringTC 2. JmJobStringTC 3. JmNaturalLanguageTagTC 4. JmTimeStampTC 5. JmFinishingTC [same enum values as IPP "finishing" attribute] 6. JmPrintQualityTC [same enum values as IPP "print-quality" attribute] 7. JmTonerEconomyTC 8. JmMediumTypeTC 9. JmJobSubmissionIDTypeTC 10.JmJobCollationTypeTC 11.JmJobStateTC [same enum values as IPP "job-state" attribute] 12.JmAttributeTypeTC For those textual conventions that have the same enum values as the indicated IPP Job attribute are simultaneously registered by the PWG for use with IPP [ipp-model] and the Job Monitoring MIB. 3.7.1.3 Type 3 enumeration Type 3 enumeration: An initial set of values are defined in the Job Monitoring MIB specification. Additional enumerated values are registered through the PWG without PWG review. There are no type 3 enums in the current document. Bergman, et al. Informational [Page 64] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.7.2 PWG Registration of type 2 bit values This memo contains the following type 2 bit value textual- conventions: 1. JmJobServiceTypesTC 2. JmJobStateReasons1TC 3. JmJobStateReasons2TC 4. JmJobStateReasons3TC 5. JmJobStateReasons4TC These textual-conventions are defined as bits in an Integer so that they can be used with SNMPv1 SMI. The jobStateReasonsN (N=1..4) attributes are defined as bit values using the corresponding JmJobStateReasonsNTC textual-conventions. The registration of JmJobServiceTypesTC and JmJobStateReasonsNTC bit values follow the procedures for a type 2 enum as specified in Section 3.7.1.2. 3.7.3 PWG Registration of Job Submission Id Formats In addition to enums and bit values, this specification assigns a single ASCII digit or letter to various job submission ID formats. See the JmJobSubmissionIDTypeTC textual-convention and the object. The registration of JobSubmissionID format numbers follows the procedures for a type 2 enum as specified in Section 3.7.1.2. 3.7.4 PWG Registration of MIME types/sub-types for document-formats The documentFormat(38) attribute has MIME type/sub-type values for indicating document formats which IANA registers as "media type" names. The values of the documentFormat(38) attribute are the same as the corresponding Internet Printing Protocol (IPP) "document- format" Job attribute values [ipp-model]. 3.8 Security Considerations 3.8.1 Read-Write objects All objects are read-only, greatly simplifying the security considerations. If another MIB augments this MIB, that MIB might accept SNMP Write operations to objects in that MIB whose effect is to modify the values of read-only objects in this MIB. However, that MIB SHALL have to support the required access control in order to achieve security, not this MIB. Bergman, et al. Informational [Page 65] RFC 2707 Job Monitoring MIB - V1.0 November 1999 3.8.2 Read-Only Objects In Other User's Jobs The security policy of some sites MAY be that unprivileged users can only get the objects from jobs that they submitted, plus a few minimal objects from other jobs, such as the jmJobKOctetsPerCopyRequested and jmJobKOctetsProcessed objects, so that a user can tell how busy a printer is. Other sites MAY allow all unprivileged users to see all objects of all jobs. This MIB does not require, nor does it specify how, such restrictions would be implemented. A monitoring application SHOULD enforce the site security policy with respect to returning information to an unprivileged end user that is using the monitoring application to monitor jobs that do not belong to that user, i.e., the jmJobOwner object in the jmJobTable does not match the user's user name. An operator is a privileged user that would be able to see all objects of all jobs, independent of the policy for unprivileged users. 3.9 Notifications This MIB does not specify any notifications. For simplicity, management applications are expected to poll for status. The jmGeneralJobPersistence and jmGeneralAttributePersistence objects assist an application to determine the polling rate. The resulting network traffic is not expected to be significant. Bergman, et al. Informational [Page 66] RFC 2707 Job Monitoring MIB - V1.0 November 1999 4 MIB specification The following pages constitute the actual Job Monitoring MIB. Job-Monitoring-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, enterprises, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- The following textual-conventions are needed to implement -- certain attributes, but are not needed to compile this MIB. -- They are provided here for convenience: -- hrDeviceIndex FROM HOST-RESOURCES-MIB -- DateAndTime FROM SNMPv2-TC -- PrtInterpreterLangFamilyTC, -- CodedCharSet FROM Printer-MIB -- Use the enterprises arc assigned to the PWG which is pwg(2699). -- Group all PWG mibs under mibs(1). jobmonMIB MODULE-IDENTITY LAST-UPDATED "9902190000Z" ORGANIZATION "Printer Working Group (PWG)" CONTACT-INFO "Tom Hastings Postal: Xerox Corp. Mail stop ESAE-231 701 S. Aviation Blvd. El Segundo, CA 90245 Tel: (301)333-6413 Fax: (301)333-5514 E-mail: hastings@cp10.es.xerox.com Send questions and comments to the Printer Working Group (PWG) using the Job Monitoring Project (JMP) Mailing List: jmp@pwg.org For further information, including how to subscribe to the jmp mailing list, access the PWG web page under 'JMP': http://www.pwg.org/ Implementers of this specification are encouraged to join the jmp mailing list in order to participate in discussions on any clarifications needed and registration proposals being reviewed Bergman, et al. Informational [Page 67] RFC 2707 Job Monitoring MIB - V1.0 November 1999 in order to achieve consensus." DESCRIPTION "The MIB module for monitoring job in servers, printers, and other devices. Version: 1.0" -- revision history REVISION "9902190000Z" DESCRIPTION " This version published as RFC 2707" ::= { enterprises pwg(2699) mibs(1) jobmonMIB(1) } -- Textual conventions for this MIB module JmUTF8StringTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme. See section 3.6.1, entitled: 'Text generated by the server or device'." SYNTAX OCTET STRING (SIZE (0..63)) JmJobStringTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information using any coded character set registered by IANA as specified in section 3.7. While it is recommended that the coded character set be UTF-8 [UTF-8], the actual coded character set SHALL be indicated by the value of the jobCodedCharSet(8) attribute for the job. See section 3.6.2, entitled: 'Text supplied by the job submitter'." SYNTAX OCTET STRING (SIZE (0..63)) Bergman, et al. Informational [Page 68] RFC 2707 Job Monitoring MIB - V1.0 November 1999 JmNaturalLanguageTagTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An IETF RFC 1766-compliant 'language tag', with zero or more sub-tags that identify a natural language. While RFC 1766 specifies that the US-ASCII values are case-insensitive, this MIB specification requires that all characters SHALL be lower case in order to simplify comparing by management applications. See section 3.6.1, entitled: 'Text generated by the server or device' and section 3.6.2, entitled: 'Text supplied by the job submitter'." SYNTAX OCTET STRING (SIZE (0..63)) JmTimeStampTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The simple time at which an event took place. The units are in seconds since the system was booted. NOTE - JmTimeStampTC is defined in units of seconds, rather than 100ths of seconds, so as to be simpler for agents to implement (even if they have to implement the 100ths of a second to comply with implementing sysUpTime in MIB-II[mib- II].) NOTE - JmTimeStampTC is defined as an Integer32 so that it can be used as a value of an attribute, i.e., as a value of the jmAttributeValueAsInteger object. The TimeStamp textual- convention defined in SNMPv2-TC [SMIv2-TC] is defined as an APPLICATION 3 IMPLICIT INTEGER tag, not an Integer32 which is defined in SNMPv2-SMI [SMIv2-TC] as UNIVERSAL 2 IMPLICIT INTEGER, so cannot be used in this MIB as one of the values of jmAttributeValueAsInteger." SYNTAX INTEGER (0..2147483647) JmJobSourcePlatformTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The source platform type that can submit jobs to servers or devices in any of the 3 configurations. This is a type 2 enumeration. See Section 3.7.1.2. See also Bergman, et al. Informational [Page 69] RFC 2707 Job Monitoring MIB - V1.0 November 1999 IANA operating-system-names registry." SYNTAX INTEGER { other(1), unknown(2), sptUNIX(3), -- UNIX sptOS2(4), -- OS/2 sptPCDOS(5), -- DOS sptNT(6), -- NT sptMVS(7), -- MVS sptVM(8), -- VM sptOS400(9), -- OS/400 sptVMS(10), -- VMS sptWindows(11), -- Windows sptNetWare(12) -- NetWare } JmFinishingTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of finishing operation. These values are the same as the enum values of the IPP 'finishings' attribute. See Section 3.7.1.2. other(1), Some other finishing operation besides one of the specified or registered values. unknown(2), The finishing is unknown. none(3), Perform no finishing. staple(4), Bind the document(s) with one or more staples. The exact number and placement of the staples is site-defined. punch(5), Holes are required in the finished document. The exact number and placement of the holes is site-defined. The punch specification MAY be satisfied (in a site- and implementation-specific manner) either by drilling/punching, or by substituting pre-drilled media. cover(6), Bergman, et al. Informational [Page 70] RFC 2707 Job Monitoring MIB - V1.0 November 1999 Select a non-printed (or pre-printed) cover for the document. This does not supplant the specification of a printed cover (on cover stock medium) by the document itself. bind(7) Binding is to be applied to the document; the type and placement of the binding is product-specific. This is a type 2 enumeration. See Section 3.7.1.2." SYNTAX INTEGER { other(1), unknown(2), none(3), staple(4), punch(5), cover(6), bind(7) } JmPrintQualityTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Print quality settings. These values are the same as the enum values of the IPP 'print- quality' attribute. See Section 3.7.1.2. This is a type 2 enumeration. See Section 3.7.1.2." SYNTAX INTEGER { other(1), -- Not one of the specified or registered -- values. unknown(2), -- The actual value is unknown. draft(3), -- Lowest quality available on the printer. normal(4), -- Normal or intermediate quality on the -- printer. high(5) -- Highest quality available on the printer. } JmPrinterResolutionTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Printer resolutions. Nine octets consisting of two 4-octet SIGNED-INTEGERs followed Bergman, et al. Informational [Page 71] RFC 2707 Job Monitoring MIB - V1.0 November 1999 by a SIGNED-BYTE. The values are the same as those specified in the Printer MIB [printmib]. The first SIGNED-INTEGER contains the value of prtMarkerAddressabilityXFeedDir. The second SIGNED-INTEGER contains the value of prtMarkerAddressabilityFeedDir. The SIGNED-BYTE contains the value of prtMarkerAddressabilityUnit. Note: the latter value is either 3 (tenThousandsOfInches) or 4 (micrometers) and the addressability is in 10,000 units of measure. Thus the SIGNED-INTEGERs represent integral values in either dots-per-inch or dots-per-centimeter. The syntax is the same as the IPP 'printer-resolution' attribute. See Section 3.7.1.2." SYNTAX OCTET STRING (SIZE(9)) JmTonerEconomyTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Toner economy settings. This is a type 2 enumeration. See Section 3.7.1.2." SYNTAX INTEGER { unknown(2), -- unknown. off(3), -- Off. Normal. Use full toner. on(4) -- On. Use less toner than normal. } JmBooleanTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Boolean true or false value. This is a type 2 enumeration. See Section 3.7.1.2." SYNTAX INTEGER { unknown(2), -- unknown. false(3), -- FALSE. true(4) -- TRUE. } JmMediumTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Bergman, et al. Informational [Page 72] RFC 2707 Job Monitoring MIB - V1.0 November 1999 "Identifies the type of medium. other(1), The type is neither one of the values listed in this specification nor a registered value. unknown(2), The type is not known. stationery(3), Separately cut sheets of an opaque material. transparency(4), Separately cut sheets of a transparent material. envelope(5), Envelopes that can be used for conventional mailing purposes. envelopePlain(6), Envelopes that are not preprinted and have no windows. envelopeWindow(7), Envelopes that have windows for addressing purposes. continuousLong(8), Continuously connected sheets of an opaque material connected along the long edge. continuousShort(9), Continuously connected sheets of an opaque material connected along the short edge. tabStock(10), Media with tabs. multiPartForm(11), Form medium composed of multiple layers not pre-attached to one another; each sheet MAY be drawn separately from an input source. labels(12), Label-stock. multiLayer(13) Form medium composed of multiple layers which are pre- attached to one another, e.g. for use with impact printers. Bergman, et al. Informational [Page 73] RFC 2707 Job Monitoring MIB - V1.0 November 1999 This is a type 2 enumeration. See Section 3.7.1.2. These enum values correspond to the keyword name strings of the prtInputMediaType object in the Printer MIB [print-mib]. There is no printer description attribute in IPP/1.0 that represents these values." SYNTAX INTEGER { other(1), unknown(2), stationery(3), transparency(4), envelope(5), envelopePlain(6), envelopeWindow(7), continuousLong(8), continuousShort(9), tabStock(10), multiPartForm(11), labels(12), multiLayer(13) } JmJobCollationTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This value is the type of job collation. Implementations that don't support multiple documents or don't support multiple copies SHALL NOT support the uncollatedDocuments(5) value. This is a type 2 enumeration. See Section 3.7.1.2. See also Section 3.4, entitled 'Monitoring Job Progress'." SYNTAX INTEGER { other(1), unknown(2), uncollatedSheets(3), -- sheets within each document copy -- are not collated: 1 1 ..., 2 2 ..., -- No corresponding value of IPP -- "multiple-document-handling" collatedDocuments(4), -- internal collated sheets, -- documents: A, B, A, B, ... -- Corresponds to IPP "multiple- -- document-handling"='separate- -- documents-collated-copies' uncollatedDocuments(5) -- internal collated sheets, -- documents: A, A, ..., B, B, ... -- Corresponds to IPP "multiple- -- document-handling"='separate- -- documents-uncollated-copies' Bergman, et al. Informational [Page 74] RFC 2707 Job Monitoring MIB - V1.0 November 1999 } JmJobSubmissionIDTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the format type of a job submission ID. Each job submission ID is a fixed-length, 48-octet printable US-ASCII [US-ASCII] coded character string containing no control characters, consisting of the fields defined in section 3.5.1. This is like a type 2 enumeration. See section 3.7.3." SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z' JmJobStateTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The current state of the job (pending, processing, completed, etc.). The following figure shows the normal job state transitions: +----> canceled(7) / +---> pending(3) -------> processing(5) ------+------> completed(9) | ^ ^ \ --->+ | | +----> aborted(8) | v v / +---> pendingHeld(4) processingStopped(6) ---+ Figure 4 - Normal Job State Transitions Normally a job progresses from left to right. Other state transitions are unlikely, but are not forbidden. Not shown are the transitions to the canceled state from the pending, pendingHeld, and processingStopped states. Jobs in the pending, processing, and processingStopped states are called 'active', while jobs in the pendingHeld, canceled, aborted, and completed states are called 'inactive'. Jobs reach one of the three terminal states: completed, canceled, or aborted, after the jobs have completed all activity, and all MIB objects and attributes have reached their final values for the job. Bergman, et al. Informational [Page 75] RFC 2707 Job Monitoring MIB - V1.0 November 1999 These values are the same as the enum values of the IPP 'job- state' job attribute. See Section 3.7.1.2. unknown(2), The job state is not known, or its state is indeterminate. pending(3), The job is a candidate to start processing, but is not yet processing. pendingHeld(4), The job is not a candidate for processing for any number of reasons but will return to the pending state as soon as the reasons are no longer present. The job's jmJobStateReasons1 object and/or jobStateReasonsN (N=2..4) attributes SHALL indicate why the job is no longer a candidate for processing. The reasons are represented as bits in the jmJobStateReasons1 object and/or jobStateReasonsN (N=2..4) attributes. See the JmJobStateReasonsNTC (N=1..4) textual convention for the specification of each reason. processing(5), One or more of: 1. the job is using, or is attempting to use, one or more purely software processes that are analyzing, creating, or interpreting a PDL, etc., 2. the job is using, or is attempting to use, one or more hardware devices that are interpreting a PDL, making mark on a medium, and/or performing finishing, such as stapling, etc., OR 3. (configuration 2) the server has made the job ready for printing, but the output device is not yet printing it, either because the job hasn't reached the output device or because the job is queued in the output device or some other spooler, awaiting the output device to print it. When the job is in the processing state, the entire job state includes the detailed status represented in the device MIB indicated by the hrDeviceIndex value of the job's physicalDevice attribute, if the agent implements such a device MIB. Implementations MAY, though they NEED NOT, include Bergman, et al. Informational [Page 76] RFC 2707 Job Monitoring MIB - V1.0 November 1999 additional values in the job's jmJobStateReasons1 object to indicate the progress of the job, such as adding the jobPrinting value to indicate when the device is actually making marks on a medium and/or the processingToStopPoint value to indicate that the server or device is in the process of canceling or aborting the job. processingStopped(6), The job has stopped while processing for any number of reasons and will return to the processing state as soon as the reasons are no longer present. The job's jmJobStateReasons1 object and/or the job's jobStateReasonsN (N=2..4) attributes MAY indicate why the job has stopped processing. For example, if the output device is stopped, the deviceStopped value MAY be included in the job's jmJobStateReasons1 object. NOTE - When an output device is stopped, the device usually indicates its condition in human readable form at the device. The management application can obtain more complete device status remotely by querying the appropriate device MIB using the job's deviceIndex attribute(s), if the agent implements such a device MIB canceled(7), A client has canceled the job and the server or device has completed canceling the job AND all MIB objects and attributes have reached their final values for the job. While the server or device is canceling the job, the job's jmJobStateReasons1 object SHOULD contain the processingToStopPoint value and one of the canceledByUser, canceledByOperator, or canceledAtDevice values. The canceledByUser, canceledByOperator, or canceledAtDevice values remain while the job is in the canceled state. aborted(8), The job has been aborted by the system, usually while the job was in the processing or processingStopped state and the server or device has completed aborting the job AND all MIB objects and attributes have reached their final values for the job. While the server or device is aborting the job, the job's jmJobStateReasons1 object MAY contain the processingToStopPoint and abortedBySystem values. If implemented, the abortedBySystem value SHALL remain while the job is in the aborted state. Bergman, et al. Informational [Page 77] RFC 2707 Job Monitoring MIB - V1.0 November 1999 completed(9) The job has completed successfully or with warnings or errors after processing and all of the media have been successfully stacked in the appropriate output bin(s) AND all MIB objects and attributes have reached their final values for the job. The job's jmJobStateReasons1 object SHOULD contain one of: completedSuccessfully, completedWithWarnings, or completedWithErrors values. This is a type 2 enumeration. See Section 3.7.1.2." SYNTAX INTEGER { unknown(2), pending(3), pendingHeld(4), processing(5), processingStopped(6), canceled(7), aborted(8), completed(9) } JmAttributeTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of the attribute which identifies the attribute. NOTE - The enum assignments are grouped logically with values assigned in groups of 20, so that additional values may be registered in the future and assigned a value that is part of their logical grouping. Values in the range 2**30 to 2**31-1 are reserved for private or experimental usage. This range corresponds to the same range reserved in IPP. Implementers are warned that use of such values may conflict with other implementations. Implementers are encouraged to request registration of enum values following the procedures in Section 3.7.1. See Section 3.2 entitled 'The Attribute Mechanism' for a description of this textual-convention and its use in the jmAttributeTable. See Section 3.3.8 for the specification of each attribute. The comment(s) after each enum assignment specifies the data type(s) of the attribute. This is a type 2 enumeration. See Section 3.7.1.2." Bergman, et al. Informational [Page 78] RFC 2707 Job Monitoring MIB - V1.0 November 1999 SYNTAX INTEGER { other(1), -- Integer32 (-2..2147483647) -- AND/OR -- OCTET STRING(SIZE(0..63)) -- Job State attributes: jobStateReasons2(3), -- JmJobStateReasons2TC jobStateReasons3(4), -- JmJobStateReasons3TC jobStateReasons4(5), -- JmJobStateReasons4TC processingMessage(6), -- JmUTF8StringTC (SIZE(0..63)) processingMessageNaturalLangTag(7), -- OCTET STRING(SIZE(0..63)) jobCodedCharSet(8), -- CodedCharSet jobNaturalLanguageTag(9), -- OCTET STRING(SIZE(0..63)) -- Job Identification attributes: jobURI(20), -- OCTET STRING(SIZE(0..63)) jobAccountName(21), -- OCTET STRING(SIZE(0..63)) serverAssignedJobName(22), -- JmJobStringTC (SIZE(0..63)) jobName(23), -- JmJobStringTC (SIZE(0..63)) jobServiceTypes(24), -- JmJobServiceTypesTC jobSourceChannelIndex(25), -- Integer32 (0..2147483647) jobSourcePlatformType(26), -- JmJobSourcePlatformTypeTC submittingServerName(27), -- JmJobStringTC (SIZE(0..63)) submittingApplicationName(28), -- JmJobStringTC (SIZE(0..63)) jobOriginatingHost(29), -- JmJobStringTC (SIZE(0..63)) deviceNameRequested(30), -- JmJobStringTC (SIZE(0..63)) queueNameRequested(31), -- JmJobStringTC (SIZE(0..63)) physicalDevice(32), -- hrDeviceIndex -- AND/OR -- JmUTF8StringTC (SIZE(0..63)) numberOfDocuments(33), -- Integer32 (-2..2147483647) fileName(34), -- JmJobStringTC (SIZE(0..63)) documentName(35), -- JmJobStringTC (SIZE(0..63)) jobComment(36), -- JmJobStringTC (SIZE(0..63)) documentFormatIndex(37), -- Integer32 (0..2147483647) documentFormat(38), -- PrtInterpreterLangFamilyTC -- AND/OR -- OCTET STRING(SIZE(0..63)) -- Job Parameter attributes: jobPriority(50), -- Integer32 (-2..100) jobProcessAfterDateAndTime(51), -- DateAndTime (SNMPv2-TC) jobHold(52), -- JmBooleanTC jobHoldUntil(53), -- JmJobStringTC (SIZE(0..63)) outputBin(54), -- Integer32 (0..2147483647) -- AND/OR Bergman, et al. Informational [Page 79] RFC 2707 Job Monitoring MIB - V1.0 November 1999 -- JmJobStringTC (SIZE(0..63)) sides(55), -- Integer32 (-2..2) finishing(56), -- JmFinishingTC -- Image Quality attributes: printQualityRequested(70), -- JmPrintQualityTC printQualityUsed(71), -- JmPrintQualityTC printerResolutionRequested(72), -- JmPrinterResolutionTC printerResolutionUsed(73), -- JmPrinterResolutionTC tonerEcomonyRequested(74), -- JmTonerEconomyTC tonerEcomonyUsed(75), -- JmTonerEconomyTC tonerDensityRequested(76), -- Integer32 (-2..100) tonerDensityUsed(77), -- Integer32 (-2..100) -- Job Progress attributes: jobCopiesRequested(90), -- Integer32 (-2..2147483647) jobCopiesCompleted(91), -- Integer32 (-2..2147483647) documentCopiesRequested(92), -- Integer32 (-2..2147483647) documentCopiesCompleted(93), -- Integer32 (-2..2147483647) jobKOctetsTransferred(94), -- Integer32 (-2..2147483647) sheetCompletedCopyNumber(95), -- Integer32 (-2..2147483647) sheetCompletedDocumentNumber(96), -- Integer32 (-2..2147483647) jobCollationType(97), -- JmJobCollationTypeTC -- Impression attributes: impressionsSpooled(110), -- Integer32 (-2..2147483647) impressionsSentToDevice(111), -- Integer32 (-2..2147483647) impressionsInterpreted(112), -- Integer32 (-2..2147483647) impressionsCompletedCurrentCopy(113), -- Integer32 (-2..2147483647) fullColorImpressionsCompleted(114), -- Integer32 (-2..2147483647) highlightColorImpressionsCompleted(115), -- Integer32 (-2..2147483647) -- Page attributes: pagesRequested(130), -- Integer32 (-2..2147483647) pagesCompleted(131), -- Integer32 (-2..2147483647) pagesCompletedCurrentCopy(132), -- Integer32 (-2..2147483647) -- Sheet attributes: sheetsRequested(150), -- Integer32 (-2..2147483647) sheetsCompleted(151), -- Integer32 (-2..2147483647) sheetsCompletedCurrentCopy(152),-- Integer32 (-2..2147483647) -- Resource attributes: Bergman, et al. Informational [Page 80] RFC 2707 Job Monitoring MIB - V1.0 November 1999 mediumRequested(170), -- JmMediumTypeTC -- AND/OR -- JmJobStringTC (SIZE(0..63)) mediumConsumed(171), -- Integer32 (-2..2147483647) -- AND -- JmJobStringTC (SIZE(0..63)) colorantRequested(172), -- Integer32 (-2..2147483647) -- AND/OR -- JmJobStringTC (SIZE(0..63)) colorantConsumed(173), -- Integer32 (-2..2147483647) -- AND/OR -- JmJobStringTC (SIZE(0..63)) mediumTypeConsumed(174), -- Integer32 (-2..2147483647) -- AND -- JmJobStringTC (SIZE(0..63)) mediumSizeConsumed(175), -- Integer32 (-2..2147483647) -- AND -- JmJobStringTC (SIZE(0..63)) -- Time attributes: jobSubmissionToServerTime(190), -- JmTimeStampTC -- AND/OR -- DateAndTime jobSubmissionTime(191), -- JmTimeStampTC -- AND/OR -- DateAndTime jobStartedBeingHeldTime(192), -- JmTimeStampTC -- AND/OR -- DateAndTime jobStartedProcessingTime(193), -- JmTimeStampTC -- AND/OR -- DateAndTime jobCompletionTime(194), -- JmTimeStampTC -- AND/OR -- DateAndTime jobProcessingCPUTime(195) -- Integer32 (-2..2147483647) } JmJobServiceTypesTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the type(s) of service to which the job has been submitted (print, fax, scan, etc.). The service type is represented as an enum that is bit encoded with each job service type so that more general and arbitrary services can be created, such as services with more than one destination type, Bergman, et al. Informational [Page 81] RFC 2707 Job Monitoring MIB - V1.0 November 1999 or ones with only a source or only a destination. For example, a job service might scan, faxOut, and print a single job. In this case, three bits would be set in the jobServiceTypes attribute, corresponding to the hexadecimal values: 0x8 + 0x20 + 0x4, respectively, yielding: 0x2C. Whether this attribute is set from a job attribute supplied by the job submission client or is set by the recipient job submission server or device depends on the job submission protocol. With either implementation, the agent SHALL return a non-zero value for this attribute indicating the type of the job. One of the purposes of this attribute is to permit a requester to filter out jobs that are not of interest. For example, a printer operator MAY only be interested in jobs that include printing. That is why the attribute is in the job identification category. The following service component types are defined (in hexadecimal) and are assigned a separate bit value for use with the jobServiceTypes attribute: other 0x1 The job contains some instructions that are not one of the identified types. unknown 0x2 The job contains some instructions whose type is unknown to the agent. print 0x4 The job contains some instructions that specify printing scan 0x8 The job contains some instructions that specify scanning faxIn 0x10 The job contains some instructions that specify receive fax faxOut 0x20 The job contains some instructions that specify sending fax getFile 0x40 The job contains some instructions that specify accessing files or documents putFile 0x80 Bergman, et al. Informational [Page 82] RFC 2707 Job Monitoring MIB - V1.0 November 1999 The job contains some instructions that specify storing files or documents mailList 0x100 The job contains some instructions that specify distribution of documents using an electronic mail system. These bit definitions are the equivalent of a type 2 enum except that combinations of them MAY be used together. See section 3.7.1.2." SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit JmJobStateReasons1TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The JmJobStateReasonsNTC (N=1..4) textual-conventions are used with the jmJobStateReasons1 object and jobStateReasonsN (N=2..4), respectively, to provide additional information regarding the current jmJobState object value. These values MAY be used with any job state or states for which the reason makes sense. See section 3.3.9.1 for the specification of each bit value defined for use with the JmJobStateReasons1TC. These bit definitions are the equivalent of a type 2 enum except that combinations of bits may be used together. See section 3.7.1.2." SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit JmJobStateReasons2TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual-convention is used with the jobStateReasons2 attribute to provides additional information regarding the jmJobState object. See section 3.3.9.2 for the specification of JmJobStateReasons2TC. See section 3.3.9.1 for the description under JmJobStateReasons1TC for additional information that applies to all reasons. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 3.7.1.2." SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit JmJobStateReasons3TC ::= TEXTUAL-CONVENTION Bergman, et al. Informational [Page 83] RFC 2707 Job Monitoring MIB - V1.0 November 1999 STATUS current DESCRIPTION "This textual-convention is used with the jobStateReasons3 attribute to provides additional information regarding the jmJobState object. See section 3.3.9.3 for the specification of JmJobStateReasons3TC. See section 3.3.9.1 for the description under JmJobStateReasons1TC for additional information that applies to all reasons. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 3.7.1.2. " SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit JmJobStateReasons4TC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual-convention is used in the jobStateReasons4 attribute to provides additional information regarding the jmJobState object. See section 3.3.9.4 for the specification of JmJobStateReasons4TC. See section 3.3.9.1 for the description under JmJobStateReasons1TC for additional information that applies to all reasons. These bit definitions are the equivalent of a type 2 enum except that combinations of them may be used together. See section 3.7.1.2." SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit jobmonMIBObjects OBJECT IDENTIFIER ::= { jobmonMIB 1 } -- The General Group (MANDATORY) -- The jmGeneralGroup consists entirely of the jmGeneralTable. jmGeneral OBJECT IDENTIFIER ::= { jobmonMIBObjects 1 } jmGeneralTable OBJECT-TYPE SYNTAX SEQUENCE OF JmGeneralEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Bergman, et al. Informational [Page 84] RFC 2707 Job Monitoring MIB - V1.0 November 1999 "The jmGeneralTable consists of information of a general nature that are per-job-set, but are not per-job. See Section 2 entitled 'Terminology and Job Model' for the definition of a job set. The MANDATORY-GROUP macro specifies that this group is MANDATORY." ::= { jmGeneral 1 } jmGeneralEntry OBJECT-TYPE SYNTAX JmGeneralEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a job set (queue). An entry SHALL exist in this table for each job set." INDEX { jmGeneralJobSetIndex } ::= { jmGeneralTable 1 } JmGeneralEntry ::= SEQUENCE { jmGeneralJobSetIndex Integer32 (1..32767), jmGeneralNumberOfActiveJobs Integer32 (0..2147483647), jmGeneralOldestActiveJobIndex Integer32 (0..2147483647), jmGeneralNewestActiveJobIndex Integer32 (0..2147483647), jmGeneralJobPersistence Integer32 (15..2147483647), jmGeneralAttributePersistence Integer32 (15..2147483647), jmGeneralJobSetName JmUTF8StringTC (SIZE(0..63)) } jmGeneralJobSetIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for each job set in this MIB. The jmJobTable and jmAttributeTable tables have this same index as their primary index. The value(s) of the jmGeneralJobSetIndex SHALL be persistent across power cycles, so that clients that have retained jmGeneralJobSetIndex values will access the same job sets upon subsequent power-up. An implementation that has only one job set, such as a printer Bergman, et al. Informational [Page 85] RFC 2707 Job Monitoring MIB - V1.0 November 1999 with a single queue, SHALL hard code this object with the value 1. See Section 2 entitled 'Terminology and Job Model' for the definition of a job set. Corresponds to the first index in jmJobTable and jmAttributeTable." ::= { jmGeneralEntry 1 } jmGeneralNumberOfActiveJobs OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of 'active' jobs in the jmJobIDTable, jmJobTable, and jmAttributeTable, i.e., the total number of jobs that are in the pending, processing, or processingStopped states. See the JmJobStateTC textual-convention for the exact specification of the semantics of the job states." DEFVAL { 0 } -- no jobs ::= { jmGeneralEntry 2 } jmGeneralOldestActiveJobIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The jmJobIndex of the oldest job that is still in one of the 'active' states (pending, processing, or processingStopped). In other words, the index of the 'active' job that has been in the job tables the longest. If there are no active jobs, the agent SHALL set the value of this object to 0. See Section 3.2 entitled 'The Job Tables and the Oldest Active and Newest Active Indexes' for a description of the usage of this object." DEFVAL { 0 } -- no active jobs ::= { jmGeneralEntry 3 } jmGeneralNewestActiveJobIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only Bergman, et al. Informational [Page 86] RFC 2707 Job Monitoring MIB - V1.0 November 1999 STATUS current DESCRIPTION "The jmJobIndex of the newest job that is in one of the 'active' states (pending, processing, or processingStopped). In other words, the index of the 'active' job that has been most recently added to the job tables. When all jobs become 'inactive', i.e., enter the pendingHeld, completed, canceled, or aborted states, the agent SHALL set the value of this object to 0. See Section 3.2 entitled 'The Job Tables and the Oldest Active and Newest Active Indexes' for a description of the usage of this object." DEFVAL { 0 } -- no active jobs ::= { jmGeneralEntry 4 } jmGeneralJobPersistence OBJECT-TYPE SYNTAX Integer32 (15..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time in seconds for this instance of the Job Set that an entry SHALL remain in the jmJobIDTable and jmJobTable after processing has completed, i.e., the minimum time in seconds starting when the job enters the completed, canceled, or aborted state. Configuring this object is implementation-dependent. This value SHALL be equal to or greater than the value of jmGeneralAttributePersistence. This value SHOULD be at least 60 which gives a monitoring or accounting application one minute in which to poll for job data." DEFVAL { 60 } -- one minute ::= { jmGeneralEntry 5 } jmGeneralAttributePersistence OBJECT-TYPE SYNTAX Integer32 (15..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Bergman, et al. Informational [Page 87] RFC 2707 Job Monitoring MIB - V1.0 November 1999 "The minimum time in seconds for this instance of the Job Set that an entry SHALL remain in the jmAttributeTable after processing has completed , i.e., the time in seconds starting when the job enters the completed, canceled, or aborted state. Configuring this object is implementation-dependent. This value SHOULD be at least 60 which gives a monitoring or accounting application one minute in which to poll for job data." DEFVAL { 60 } -- one minute ::= { jmGeneralEntry 6 } jmGeneralJobSetName OBJECT-TYPE SYNTAX JmUTF8StringTC (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable name of this job set assigned by the system administrator (by means outside of this MIB). Typically, this name SHOULD be the name of the job queue. If a server or device has only a single job set, this object can be the administratively assigned name of the server or device itself. This name does not need to be unique, though each job set in a single Job Monitoring MIB SHOULD have distinct names. NOTE - If the job set corresponds to a single printer and the Printer MIB is implemented, this value SHOULD be the same as the prtGeneralPrinterName object in the draft Printer MIB [print-mib-draft]. If the job set corresponds to an IPP Printer, this value SHOULD be the same as the IPP 'printer- name' Printer attribute. NOTE - The purpose of this object is to help the user of the job monitoring application distinguish between several job sets in implementations that support more than one job set. See the OBJECT compliance macro for the minimum maximum length required for conformance." DEFVAL { ''H } -- empty string ::= { jmGeneralEntry 7 } -- The Job ID Group (MANDATORY) -- The jmJobIDGroup consists entirely of the jmJobIDTable. Bergman, et al. Informational [Page 88] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jmJobID OBJECT IDENTIFIER ::= { jobmonMIBObjects 2 } jmJobIDTable OBJECT-TYPE SYNTAX SEQUENCE OF JmJobIDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmJobIDTable provides a correspondence map (1) between the job submission ID that a client uses to refer to a job and (2) the jmGeneralJobSetIndex and jmJobIndex that the Job Monitoring MIB agent assigned to the job and that are used to access the job in all of the other tables in the MIB. If a monitoring application already knows the jmGeneralJobSetIndex and the jmJobIndex of the job it is querying, that application NEED NOT use the jmJobIDTable. The MANDATORY-GROUP macro specifies that this group is MANDATORY." ::= { jmJobID 1 } jmJobIDEntry OBJECT-TYPE SYNTAX JmJobIDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The map from (1) the jmJobSubmissionID to (2) the jmGeneralJobSetIndex and jmJobIndex. An entry SHALL exist in this table for each job currently known to the agent for all job sets and job states. There MAY be more than one jmJobIDEntry that maps to a single job. This many to one mapping can occur when more than one network entity along the job submission path supplies a job submission ID. See Section 3.5. However, each job SHALL appear once and in one and only one job set." INDEX { jmJobSubmissionID } ::= { jmJobIDTable 1 } JmJobIDEntry ::= SEQUENCE { jmJobSubmissionID OCTET STRING(SIZE(48)), jmJobIDJobSetIndex Integer32 (0..32767), jmJobIDJobIndex Integer32 (0..2147483647) } jmJobSubmissionID OBJECT-TYPE Bergman, et al. Informational [Page 89] RFC 2707 Job Monitoring MIB - V1.0 November 1999 SYNTAX OCTET STRING(SIZE(48)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A quasi-unique 48-octet fixed-length string ID which identifies the job within a particular client-server environment. There are multiple formats for the jmJobSubmissionID. Each format SHALL be uniquely identified. See the JmJobSubmissionIDTypeTC textual convention. Each format SHALL be registered using the procedures of a type 2 enum. See section 3.7.3 entitled: 'PWG Registration of Job Submission Id Formats'. If the requester (client or server) does not supply a job submission ID in the job submission protocol, then the recipient (server or device) SHALL assign a job submission ID using any of the standard formats that have been reserved for agents and adding the final 8 octets to distinguish the ID from others submitted from the same requester. The monitoring application, whether in the client or running separately, MAY use the job submission ID to help identify which jmJobIndex was assigned by the agent, i.e., in which row the job information is in the other tables. NOTE - fixed-length is used so that a management application can use a shortened GetNext varbind (in SNMPv1 and SNMPv2) in order to get the next submission ID, disregarding the remainder of the ID in order to access jobs independent of the trailing identifier part, e.g., to get all jobs submitted by a particular jmJobOwner or submitted from a particular MAC address. See the JmJobSubmissionIDTypeTC textual convention. See APPENDIX B - Support of Job Submission Protocols." ::= { jmJobIDEntry 1 } jmJobIDJobSetIndex OBJECT-TYPE SYNTAX Integer32 (0..32767) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of the jmGeneralJobSetIndex for the job with the jmJobSubmissionID value, i.e., the job set index of the job set in which the job was placed when that server or device accepted the job. This 16-bit value in Bergman, et al. Informational [Page 90] RFC 2707 Job Monitoring MIB - V1.0 November 1999 combination with the jmJobIDJobIndex value permits the management application to access the other tables to obtain the job-specific objects for this job. See jmGeneralJobSetIndex in the jmGeneralTable." DEFVAL { 0 } -- 0 indicates no job set index ::= { jmJobIDEntry 2 } jmJobIDJobIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of the jmJobIndex for the job with the jmJobSubmissionID value, i.e., the job index for the job when the server or device accepted the job. This value, in combination with the jmJobIDJobSetIndex value, permits the management application to access the other tables to obtain the job-specific objects for this job. See jmJobIndex in the jmJobTable." DEFVAL { 0 } -- 0 indicates no jmJobIndex value. ::= { jmJobIDEntry 3 } -- The Job Group (MANDATORY) -- The jmJobGroup consists entirely of the jmJobTable. jmJob OBJECT IDENTIFIER ::= { jobmonMIBObjects 3 } jmJobTable OBJECT-TYPE SYNTAX SEQUENCE OF JmJobEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmJobTable consists of basic job state and status information for each job in a job set that (1) monitoring applications need to be able to access in a single SNMP Get operation, (2) that have a single value per job, and (3) that SHALL always be implemented. The MANDATORY-GROUP macro specifies that this group is MANDATORY." ::= { jmJob 1 } Bergman, et al. Informational [Page 91] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jmJobEntry OBJECT-TYPE SYNTAX JmJobEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Basic per-job state and status information. An entry SHALL exist in this table for each job, no matter what the state of the job is. Each job SHALL appear in one and only one job set. See Section 3.2 entitled 'The Job Tables'." INDEX { jmGeneralJobSetIndex, jmJobIndex } ::= { jmJobTable 1 } JmJobEntry ::= SEQUENCE { jmJobIndex Integer32 (1..2147483647), jmJobState JmJobStateTC, jmJobStateReasons1 JmJobStateReasons1TC, jmNumberOfInterveningJobs Integer32 (-2..2147483647), jmJobKOctetsPerCopyRequested Integer32 (-2..2147483647), jmJobKOctetsProcessed Integer32 (-2..2147483647), jmJobImpressionsPerCopyRequested Integer32 (-2..2147483647), jmJobImpressionsCompleted Integer32 (-2..2147483647), jmJobOwner JmJobStringTC (SIZE(0..63)) } jmJobIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The sequential, monatonically increasing identifier index for the job generated by the server or device when that server or device accepted the job. This index value permits the management application to access the other tables to obtain the job-specific row entries. See Section 3.2 entitled 'The Job Tables and the Oldest Active and Newest Active Indexes'. See Section 3.5 entitled 'Job Identification'. See also jmGeneralNewestActiveJobIndex for the largest value of jmJobIndex. See JmJobSubmissionIDTypeTC for a limit on the size of this index if the agent represents it as an 8-digit decimal number." ::= { jmJobEntry 1 } Bergman, et al. Informational [Page 92] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jmJobState OBJECT-TYPE SYNTAX JmJobStateTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the job (pending, processing, completed, etc.). Agents SHALL implement only those states which are appropriate for the particular implementation. However, management applications SHALL be prepared to receive all the standard job states. The final value for this object SHALL be one of: completed, canceled, or aborted. The minimum length of time that the agent SHALL maintain MIB data for a job in the completed, canceled, or aborted state before removing the job data from the jmJobIDTable and jmJobTable is specified by the value of the jmGeneralJobPersistence object." DEFVAL { unknown } -- default is unknown ::= { jmJobEntry 2 } jmJobStateReasons1 OBJECT-TYPE SYNTAX JmJobStateReasons1TC MAX-ACCESS read-only STATUS current DESCRIPTION "Additional information about the job's current state, i.e., information that augments the value of the job's jmJobState object. Implementation of any reason values is OPTIONAL, but an agent SHOULD return any reason information available. These values MAY be used with any job state or states for which the reason makes sense. Since the Job State Reasons will be more dynamic than the Job State, it is recommended that a job monitoring application read this object every time jmJobState is read. When the agent cannot provide a reason for the current state of the job, the value of the jmJobStateReasons1 object and jobStateReasonsN attributes SHALL be 0. The jobStateReasonsN (N=2..4) attributes provide further additional information about the job's current state." DEFVAL { 0 } -- no reasons ::= { jmJobEntry 3 } Bergman, et al. Informational [Page 93] RFC 2707 Job Monitoring MIB - V1.0 November 1999 jmNumberOfInterveningJobs OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of jobs that are expected to complete processing before this job has completed processing according to the implementation's queuing algorithm, if no other jobs were to be submitted. In other words, this value is the job's queue position. The agent SHALL return a value of 0 for this attribute when the job is the next job to complete processing (or has completed processing)." DEFVAL { 0 } -- default is no intervening jobs. ::= { jmJobEntry 4 } jmJobKOctetsPerCopyRequested OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total size in K (1024) octets of the document(s) being requested to be processed in the job. The agent SHALL round the actual number of octets up to the next highest K. Thus 0 octets is represented as '0', 1-1024 octets is represented as '1', 1025-2048 is represented as '2', etc. In computing this value, the server/device SHALL NOT include the multiplicative factors contributed by (1) the number of document copies, and (2) the number of job copies, independent of whether the device can process multiple copies of the job or document without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the server/device computation is independent of the implementation and indicates the size of the document(s) measured in K octets independent of the number of copies." DEFVAL { -2 } -- the default is unknown(-2) ::= { jmJobEntry 5 } jmJobKOctetsProcessed OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets processed by the server or device Bergman, et al. Informational [Page 94] RFC 2707 Job Monitoring MIB - V1.0 November 1999 measured in units of K (1024) octets so far. The agent SHALL round the actual number of octets processed up to the next higher K. Thus 0 octets is represented as '0', 1-1024 octets is represented as '1', 1025-2048 octets is '2', etc. For printing devices, this value is the number interpreted by the page description language interpreter rather than what has been marked on media. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the jmJobKOctetsPerCopyRequested object. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the jmJobKOctetsPerCopyRequested object. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobKOctetsProcessed object can be used with the jmJobKOctetsPerCopyRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies." DEFVAL { 0 } -- default is no octets processed. ::= { jmJobEntry 6 } jmJobImpressionsPerCopyRequested OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total size in number of impressions of the document(s) submitted. In computing this value, the server/device SHALL NOT include the multiplicative factors contributed by (1) the number of document copies, and (2) the number of job copies, independent of whether the device can process multiple copies of the job or document without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the server/device computation is independent of the implementation and reflects the size of the document(s) measured in impressions independent of the number of copies. See the definition of the term 'impression' in Section 2." Bergman, et al. Informational [Page 95] RFC 2707 Job Monitoring MIB - V1.0 November 1999 DEFVAL { -2 } -- default is unknown(-2) ::= { jmJobEntry 7 } jmJobImpressionsCompleted OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of impressions completed for this job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobImpressionsCompleted object can be used with the jmJobImpressionsPerCopyRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies. See the definition of the term 'impression' in Section 2 and the counting example in Section 3.4 entitled 'Monitoring Job Progress'." DEFVAL { 0 } -- default is no octets ::= { jmJobEntry 8 } jmJobOwner OBJECT-TYPE SYNTAX JmJobStringTC (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The coded character set name of the user that submitted the job. The method of assigning this user name will be system and/or site specific but the method MUST ensure that the name is unique to the network that is visible to the client and target device. This value SHOULD be the most authenticated name of the user submitting the job. See the OBJECT compliance macro for the minimum maximum length Bergman, et al. Informational [Page 96] RFC 2707 Job Monitoring MIB - V1.0 November 1999 required for conformance." DEFVAL { ''H } -- default is empty string ::= { jmJobEntry 9 } -- The Attribute Group (MANDATORY) -- The jmAttributeGroup consists entirely of the jmAttributeTable. -- -- Implementation of the objects in this group is MANDATORY. -- See Section 3.1 entitled 'Conformance Considerations'. -- An agent SHALL implement any attribute if (1) the server or device -- supports the functionality represented by the attribute and (2) the -- information is available to the agent. jmAttribute OBJECT IDENTIFIER ::= { jobmonMIBObjects 4 } jmAttributeTable OBJECT-TYPE SYNTAX SEQUENCE OF JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The jmAttributeTable SHALL contain attributes of the job and document(s) for each job in a job set. Instead of allocating distinct objects for each attribute, each attribute is represented as a separate row in the jmAttributeTable. The MANDATORY-GROUP macro specifies that this group is MANDATORY. An agent SHALL implement any attribute if (1) the server or device supports the functionality represented by the attribute and (2) the information is available to the agent. " ::= { jmAttribute 1 } jmAttributeEntry OBJECT-TYPE SYNTAX JmAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes representing information about the job and document(s) or resources required and/or consumed. Each entry in the jmAttributeTable is a per-job entry with an extra index for each type of attribute (jmAttributeTypeIndex) that a job can have and an additional index (jmAttributeInstanceIndex) for those attributes that can have Bergman, et al. Informational [Page 97] RFC 2707 Job Monitoring MIB - V1.0 November 1999 multiple instances per job. The jmAttributeTypeIndex object SHALL contain an enum type that indicates the type of attribute (see the JmAttributeTypeTC textual-convention). The value of the attribute SHALL be represented in either the jmAttributeValueAsInteger or jmAttributeValueAsOctets objects, and/or both, as specified in the JmAttributeTypeTC textual- convention. The agent SHALL create rows in the jmAttributeTable as the server or device is able to discover the attributes either from the job submission protocol itself or from the document PDL. As the documents are interpreted, the interpreter MAY discover additional attributes and so the agent adds additional rows to this table. As the attributes that represent resources are actually consumed, the usage counter contained in the jmAttributeValueAsInteger object is incremented according to the units indicated in the description of the JmAttributeTypeTC enum. The agent SHALL maintain each row in the jmAttributeTable for at least the minimum time after a job completes as specified by the jmGeneralAttributePersistence object. Zero or more entries SHALL exist in this table for each job in a job set. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmAttributeTable." INDEX { jmGeneralJobSetIndex, jmJobIndex, jmAttributeTypeIndex, jmAttributeInstanceIndex } ::= { jmAttributeTable 1 } JmAttributeEntry ::= SEQUENCE { jmAttributeTypeIndex JmAttributeTypeTC, jmAttributeInstanceIndex Integer32 (1..32767), jmAttributeValueAsInteger Integer32 (-2..2147483647), jmAttributeValueAsOctets OCTET STRING(SIZE(0..63)) } jmAttributeTypeIndex OBJECT-TYPE SYNTAX JmAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of attribute that this row entry represents. The type MAY identify information about the job or document(s) Bergman, et al. Informational [Page 98] RFC 2707 Job Monitoring MIB - V1.0 November 1999 or MAY identify a resource required to process the job before the job start processing and/or consumed by the job as the job is processed. Examples of job attributes (i.e., apply to the job as a whole) that have only one instance per job include: jobCopiesRequested(90), documentCopiesRequested(92), jobCopiesCompleted(91), documentCopiesCompleted(93), while examples of job attributes that may have more than one instance per job include: documentFormatIndex(37), and documentFormat(38). Examples of document attributes (one instance per document) include: fileName(34), and documentName(35). Examples of required and consumed resource attributes include: pagesRequested(130), mediumRequested(170), pagesCompleted(131), and mediumConsumed(171), respectively." ::= { jmAttributeEntry 1 } jmAttributeInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..32767) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A running 16-bit index of the attributes of the same type for each job. For those attributes with only a single instance per job, this index value SHALL be 1. For those attributes that are a single value per document, the index value SHALL be the document number, starting with 1 for the first document in the job. Jobs with only a single document SHALL use the index value of 1. For those attributes that can have multiple values per job or per document, such as documentFormatIndex(37) or documentFormat(38), the index SHALL be a running index for the job as a whole, starting at 1." ::= { jmAttributeEntry 2 } jmAttributeValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The integer value of the attribute. The value of the attribute SHALL be represented as an integer if the enum Bergman, et al. Informational [Page 99] RFC 2707 Job Monitoring MIB - V1.0 November 1999 description in the JmAttributeTypeTC textual-convention definition has the tag: 'INTEGER:'. Depending on the enum definition, this object value MAY be an integer, a counter, an index, or an enum, depending on the jmAttributeTypeIndex value. The units of this value are specified in the enum description. For those attributes that are accumulating job consumption as the job is processed as specified in the JmAttributeTypeTC textual-convention, SHALL contain the final value after the job completes processing, i.e., this value SHALL indicate the total usage of this resource made by the job. A monitoring application is able to copy this value to a suitable longer term storage for later processing as part of an accounting system. Since the agent MAY add attributes representing resources to this table while the job is waiting to be processed or being processed, which can be a long time before any of the resources are actually used, the agent SHALL set the value of the jmAttributeValueAsInteger object to 0 for resources that the job has not yet consumed. Attributes for which the concept of an integer value is meaningless, such as fileName(34), jobName, and processingMessage, do not have the 'INTEGER:' tag in the JmAttributeTypeTC definition and so an agent SHALL always return a value of '-1' to indicate 'other' for the value of the jmAttributeValueAsInteger object for these attributes. For attributes which do have the 'INTEGER:' tag in the JmAttributeTypeTC definition, if the integer value is not (yet) known, the agent either (1) SHALL not materialize the row in the jmAttributeTable until the value is known or (2) SHALL return a '-2' to represent an 'unknown' counting integer value, a '0' to represent an 'unknown' index value, and a '2' to represent an 'unknown(2)' enum value." DEFVAL { -2 } -- default value is unknown(-2) ::= { jmAttributeEntry 3 } jmAttributeValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..63)) MAX-ACCESS read-only STATUS current Bergman, et al. Informational [Page 100] RFC 2707 Job Monitoring MIB - V1.0 November 1999 DESCRIPTION "The octet string value of the attribute. The value of the attribute SHALL be represented as an OCTET STRING if the enum description in the JmAttributeTypeTC textual-convention definition has the tag: 'OCTETS:'. Depending on the enum definition, this object value MAY be a coded character set string (text), such as 'JmUTF8StringTC', or a binary octet string, such as 'DateAndTime'. Attributes for which the concept of an octet string value is meaningless, such as pagesCompleted, do not have the tag 'OCTETS:' in the JmAttributeTypeTC definition and so the agent SHALL always return a zero length string for the value of the jmAttributeValueAsOctets object. For attributes which do have the 'OCTETS:' tag in the JmAttributeTypeTC definition, if the OCTET STRING value is not (yet) known, the agent either SHALL NOT materialize the row in the jmAttributeTable until the value is known or SHALL return a zero-length string." DEFVAL { ''H } -- empty string ::= { jmAttributeEntry 4 } -- Notifications and Trapping -- Reserved for the future jobmonMIBNotifications OBJECT IDENTIFIER ::= { jobmonMIB 2 } -- Conformance Information jmMIBConformance OBJECT IDENTIFIER ::= { jobmonMIB 3 } -- compliance statements jmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the job monitoring MIB." MODULE -- this module MANDATORY-GROUPS { jmGeneralGroup, jmJobIDGroup, jmJobGroup, jmAttributeGroup } Bergman, et al. Informational [Page 101] RFC 2707 Job Monitoring MIB - V1.0 November 1999 OBJECT jmGeneralJobSetName SYNTAX JmUTF8StringTC (SIZE(0..8)) DESCRIPTION "Only 8 octets maximum string length NEED be supported by the agent." OBJECT jmJobOwner SYNTAX JmJobStringTC (SIZE(0..16)) DESCRIPTION "Only 16 octets maximum string length NEED be supported by the agent." -- There are no CONDITIONALLY MANDATORY or OPTIONAL groups. ::= { jmMIBConformance 1 } jmMIBGroups OBJECT IDENTIFIER ::= { jmMIBConformance 2 } jmGeneralGroup OBJECT-GROUP OBJECTS { jmGeneralNumberOfActiveJobs, jmGeneralOldestActiveJobIndex, jmGeneralNewestActiveJobIndex, jmGeneralJobPersistence, jmGeneralAttributePersistence, jmGeneralJobSetName} STATUS current DESCRIPTION "The general group." ::= { jmMIBGroups 1 } jmJobIDGroup OBJECT-GROUP OBJECTS { jmJobIDJobSetIndex, jmJobIDJobIndex } STATUS current DESCRIPTION "The job ID group." ::= { jmMIBGroups 2 } jmJobGroup OBJECT-GROUP OBJECTS { jmJobState, jmJobStateReasons1, jmNumberOfInterveningJobs, jmJobKOctetsPerCopyRequested, jmJobKOctetsProcessed, jmJobImpressionsPerCopyRequested, jmJobImpressionsCompleted, jmJobOwner } STATUS current Bergman, et al. Informational [Page 102] RFC 2707 Job Monitoring MIB - V1.0 November 1999 DESCRIPTION "The job group." ::= { jmMIBGroups 3 } jmAttributeGroup OBJECT-GROUP OBJECTS { jmAttributeValueAsInteger, jmAttributeValueAsOctets } STATUS current DESCRIPTION "The attribute group." ::= { jmMIBGroups 4 } END Bergman, et al. Informational [Page 103] RFC 2707 Job Monitoring MIB - V1.0 November 1999 5 Appendix A - Implementing the Job Life Cycle The job object has well-defined states and client operations that affect the transition between the job states. Internal server and device actions also affect the transitions of the job between the job states. These states and transitions are referred to as the job's life cycle. Not all implementations of job submission protocols have all of the states of the job model specified here. The job model specified here is intended to be a superset of most implementations. It is the purpose of the agent to map the particular implementation's job life cycle onto the one specified here. The agent MAY omit any states not implemented. Only the processing and completed states are required to be implemented by an agent. However, a conforming management application SHALL be prepared to accept any of the states in the job life cycle specified here, so that the management application can interoperate with any conforming agent. The job states are intended to be user visible. The agent SHALL make these states visible in the MIB, but only for the subset of job states that the implementation has. Some implementations MAY need to have sub-states of these user-visible states. The jmJobStateReasons1 object and the jobStateReasonsN (N=2..4) attributes can be used to represent the sub-states of the jobs. Job states are intended to last a user-visible length of time in most implementations. However, some jobs may pass through some states in zero time in some situations and/or in some implementations. The job model does not specify how accounting and auditing is implemented, except to assume that accounting and auditing logs are separate from the job life cycle and last longer than job entries in the MIB. Jobs in the completed, aborted, or canceled states are not logs, since jobs in these states are accessible via SNMP protocol operations and SHALL be removed from the Job Monitoring MIB tables after a site-settable or implementation-defined period of time. An accounting application MAY copy accounting information incrementally to an accounting log as a job processes, or MAY be copied while the job is in the canceled, aborted, or completed states, depending on implementation. The same is true for auditing logs. The jmJobState object specifies the standard job states. The normal job state transitions are shown in the state transition diagram presented in Figure 4. Bergman, et al. Informational [Page 104] RFC 2707 Job Monitoring MIB - V1.0 November 1999 6 APPENDIX B - Support of Job Submission Protocols A companion PWG document, entitled "Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB" [protomap] contains the recommended usage of each of the objects and attributes in this MIB with a number of job submission protocols. In particular, which job submission ID format should be used is indicated for each job submission protocol. Some job submission protocols have support for the client to specify a job submission ID. A second approach is to enhance the document format to embed the job submission ID in the document data. This second approach is independent of the job submission protocol. This appendix lists some examples of these approaches. Some PJL implementations wrap a banner page as a PJL job around a job submitted by a client. If this results in multiple job submission IDs, the agent SHALL create multiple jmJobIDEntry rows in the jmJobIDTable that each point to the same job entry in the job tables. See the specification of the jmJobIDEntry. 7 References [BCP-11] Bradner S. and R. Hovey, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [GB2312] GB 2312-1980, "Chinese People's Republic of China (PRC) mixed one byte and two byte coded character set" [hr-mib] Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514, September 1993. [iana] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [IANA-charsets] Coded Character Sets registered by IANA and assigned an enum value for use in the CodedCharSet textual convention imported from the Printer MIB. See ftp://ftp.isi.edu/in- notes/iana/assignments/character-sets [iana-media-types] IANA Registration of MIME media types (MIME content types/subtypes). See ftp://ftp.isi.edu/in-notes/iana/assignments/ Bergman, et al. Informational [Page 105] RFC 2707 Job Monitoring MIB - V1.0 November 1999 [ipp-model] deBry, R., Hastings, T., Herriot, R., Issaacson, S. and P. Powell, "The Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999. [ISO-639] ISO 639:1988 (E/F) - Code for Representation of names of languages - The International Organization for Standardization, 1st edition, 1988. [ISO-646] ISO/IEC 646:1991, "Information technology -- ISO 7-bit coded character set for information interchange", JTC1/SC2. [ISO-2022] ISO/IEC 2022:1994 - "Information technology -- Character code structure and extension techniques", JTC1/SC2. [ISO-3166] ISO 3166:1988 (E/F) - Codes for representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15." [ISO-8859-1] ISO/IEC 8859-1:1987, "Information technology -- 8-bit single byte coded graphic character sets - Part 1: Latin alphabet No. 1, JTC1/SC2." [ISO-10646] ISO/IEC 10646-1:1993, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, JTC1/SC2. [iso-dpa] ISO/IEC 10175-1:1996 "Information technology -- Text and Office Systems -- Document Printing Application (DPA) -- Part 1: Abstract service definition and procedures. See ftp://ftp.pwg.org/pub/pwg/dpa/ [JIS X0208] JIS X0208-1990, "Japanese two byte coded character set." [mib-II] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. Bergman, et al. Informational [Page 106] RFC 2707 Job Monitoring MIB - V1.0 November 1999 [print-mib] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995. [print-mib-draft] Turner, R., "Printer MIB", Work in Progress, [protomap] Bergman, R., "Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB", RFC 2708, November 1999. [pwg] The Printer Working Group is a printer industry consortium open to any individuals. For more information, access the PWG web page: http://www.pwg.org [RFC1179] McLaughlin, L., III, "Line Printer Daemon Protocol", RFC 1179, August 1990. [RFC1738] Berners-Lee, T., Masinter, L. and M., McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC1766] Avelstrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2278] Freed, N. and J. Postel, "IANA CharSet Registration Procedures", BCP 19, RFC 2278, January 1998. [SMIv2-SMI] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [SMIv2-TC] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Bergman, et al. Informational [Page 107] RFC 2707 Job Monitoring MIB - V1.0 November 1999 [tipsi] IEEE 1284.1, Transport-independent Printer System Interface (TIPSI). [URI-spec] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI), Generic Syntax", RFC 2396, August 1998. [US-ASCII] Coded Character Set - 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 8 Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11 [BCP-11]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Bergman, et al. Informational [Page 108] RFC 2707 Job Monitoring MIB - V1.0 November 1999 9 Authors' Addresses Ron Bergman Dataproducts Corp. 1757 Tapo Canyon Road Simi Valley, CA 93063-3394 Phone: 805-578-4421 Fax: 805-578-4001 EMail: rbergma@dpc.com Tom Hastings Xerox Corporation, ESAE-231 737 Hawaii St. El Segundo, CA 90245 Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 EMail: scott_isaacson@novell.com Harry Lewis IBM Corporation 6300 Diagonal Hwy Boulder, CO 80301 Phone: (303) 924-5337 EMail: harryl@us.ibm.com Send questions and comments to the Printer Working Group (PWG) using the Job Monitoring Project (JMP) Mailing List: jmp@pwg.org To learn how to subscribe, send email to: jmp-request@pwg.org Bergman, et al. Informational [Page 109] RFC 2707 Job Monitoring MIB - V1.0 November 1999 Implementers of this specification are encouraged to join the jmp mailing list in order to participate in discussions on any clarifications needed and registration proposals for additional attributes and values being reviewed in order to achieve consensus. For further information, access the PWG web page under "JMP": http://www.pwg.org/ Other Participants: Chuck Adams - Tektronix Jeff Barnett - IBM Keith Carter, IBM Corporation Jeff Copeland - QMS Andy Davidson - Tektronix Roger deBry - IBM Mabry Dozier - QMS Lee Farrell - Canon Steve Gebert - IBM Robert Herriot - Sun Microsystems Inc. Shige Kanemitsu - Kyocera David Kellerman - Northlake Software Rick Landau - Digital Pete Loya - HP Ray Lutz - Cognisys Jay Martin - Underscore Mike MacKay, Novell, Inc. Stan McConnell - Xerox Carl-Uno Manros, Xerox, Corp. Pat Nogay - IBM Bob Pentecost - HP Rob Rhoads - Intel David Roach - Unisys Stuart Rowley - Kyocera Hiroyuki Sato - Canon Bob Setterbo - Adobe Gail Songer, EFI Mike Timperman - Lexmark Randy Turner - Sharp William Wagner - Digital Products Jim Walker - Dazel Chris Wellens - Interworking Labs Rob Whittle - Novell Don Wright - Lexmark Lloyd Young - Lexmark Atsushi Yuki - Kyocera Peter Zehler, Xerox, Corp. Bergman, et al. Informational [Page 110] RFC 2707 Job Monitoring MIB - V1.0 November 1999 10 INDEX This index includes the textual conventions, the objects, and the attributes. Textual conventions all start with the prefix: "JM" and end with the suffix: "TC". Objects all starts with the prefix: "jm" followed by the group name. Attributes are identified with enums, and so start with any lower case letter and have no special prefix. colorantConsumed, 40 colorantRequested, 40 deviceNameRequested, 30 documentCopiesCompleted, 35 documentCopiesRequested, 35 documentFormat, 31 documentFormatIndex, 31 documentName, 31 fileName, 31 finishing, 33 fullColorImpressionsCompleted, 37 highlightColorImpressionsCompleted, 37 impressionsCompletedCurrentCopy, 37 impressionsInterpreted, 37 impressionsSentToDevice, 37 impressionsSpooled, 36 jmAttributeInstanceIndex, 99 jmAttributeTypeIndex, 98 JmAttributeTypeTC, 78 jmAttributeValueAsInteger, 99 jmAttributeValueAsOctets, 100 JmBooleanTC, 72 JmFinishingTC, 70 jmGeneralAttributePersistence, 87 jmGeneralJobPersistence, 87 jmGeneralJobSetIndex, 85 jmGeneralJobSetName, 88 jmGeneralNewestActiveJobIndex, 86 jmGeneralNumberOfActiveJobs, 86 jmGeneralOldestActiveJobIndex, 86 JmJobCollationTypeTC, 74 jmJobIDJobIndex, 91 jmJobIDJobSetIndex, 90 jmJobImpressionsCompleted, 96 jmJobImpressionsPerCopyRequested, 95 jmJobIndex, 92 jmJobKOctetsPerCopyRequested, 94 jmJobKOctetsProcessed, 94 jmJobOwner, 96 Bergman, et al. Informational [Page 111] RFC 2707 Job Monitoring MIB - V1.0 November 1999 JmJobServiceTypesTC, 81 JmJobSourcePlatformTypeTC, 69 jmJobState, 92 jmJobStateReasons1, 93 JmJobStateReasons1TC, 83 JmJobStateReasons2TC, 83 JmJobStateReasons3TC, 83 JmJobStateReasons4TC, 84 JmJobStateTC, 75 JmJobStringTC, 68 jmJobSubmissionID, 89 JmJobSubmissionIDTypeTC, 74 JmMediumTypeTC, 72 JmNaturalLanguageTagTC, 68 jmNumberOfInterveningJobs, 93 JmPrinterResolutionTC, 71 JmPrintQualityTC, 71 JmTimeStampTC, 69 JmTonerEconomyTC, 72 JmUTF8StringTC, 68 jobAccountName, 27 jobCodedCharSet, 26 jobCollationType, 36 jobComment, 31 jobCompletionTime, 43 jobCopiesCompleted, 35 jobCopiesRequested, 35 jobHold, 33 jobHoldUntil, 33 jobKOctetsTransferred, 35 jobName, 28 jobNaturalLanguageTag, 27 jobOriginatingHost, 30 jobPriority, 32 jobProcessAfterDateAndTime, 32 jobProcessingCPUTime, 43 jobServiceTypes, 29 jobSourceChannelIndex, 29 jobSourcePlatformType, 29 jobStartedBeingHeldTime, 42 jobStartedProcessingTime, 43 jobStateReasons2, 25 jobStateReasons3, 25 jobStateReasons4, 25 jobSubmissionTime, 42 jobSubmissionToServerTime, 42 jobURI, 27 mediumConsumed, 40 Bergman, et al. Informational [Page 112] RFC 2707 Job Monitoring MIB - V1.0 November 1999 mediumRequested, 39 mediumSizeConsumed, 41 mediumTypeConsumed, 41 numberOfDocuments, 30 other, 25 outputBin, 33 pagesCompleted, 38 pagesCompletedCurrentCopy, 38 pagesRequested, 38 physicalDevice, 30 printerResolutionRequested, 34 printerResolutionUsed, 34 printQualityRequested, 34 printQualityUsed, 34 processingMessage, 25 processingMessageNaturalLangTag, 26 queueNameRequested, 30 serverAssignedJobName, 28 sheetCompletedCopyNumber, 36 sheetCompletedDocumentNumber, 36 sheetsCompleted, 39 sheetsCompletedCurrentCopy, 39 sheetsRequested, 39 sides, 33 submittingApplicationName, 29 submittingServerName, 29 tonerDensityRequested, 34 tonerDensityUsed, 34 tonerEcomonyRequested, 34 tonerEcomonyUsed, 34 Bergman, et al. Informational [Page 113] RFC 2707 Job Monitoring MIB - V1.0 November 1999 11 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bergman, et al. Informational [Page 114] snmp-mibs-downloader-1.1/mibrfcs/rfc2720.txt0000644000000000000000000031254511402176071015566 0ustar Network Working Group N. Brownlee Request for Comments: 2720 The University of Auckland Obsoletes: 2064 October 1999 Category: Standards Track Traffic Flow Measurement: Meter MIB 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 The SNMP Management Framework . . . . . . . . . . . . . . . . 2 3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Scope of Definitions, Textual Conventions . . . . . . . . . 4 3.2 Usage of the MIB variables . . . . . . . . . . . . . . . . 4 4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 46 5.1 SNMP Concerns . . . . . . . . . . . . . . . . . . . . . . 46 5.2 Traffic Meter Concerns . . . . . . . . . . . . . . . . . . 46 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 48 7 Appendix A: Changes Introduced Since RFC 2064 . . . . . . . . . 49 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 9 Intellectual Property Notice . . . . . . . . . . . . . . . . . 50 Brownlee Standards Track [Page 1] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 53 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 54 1 Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for managing and collecting data from network Realtime Traffic Flow Meters, as described in [RTFM- ARC]. The MIB is 'basic' in the sense that it provides more than enough information for everyday traffic measurment. Furthermore, it can be easily extended by adding new attributes as required. The RTFM Working group is actively pursuing the development of the meter in this way. 2 The SNMP Management Framework The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2571 [RFC2571]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. Brownlee Standards Track [Page 2] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 - A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3 Overview Traffic Flow Measurement seeks to provide a well-defined method for gathering traffic flow information from networks and internetworks. The background for this is given in "Internet Accounting Background" [ACT-BKG]. The Realtime Traffic Flow Measurement (rtfm) Working Group has produced a measurement architecture to achieve this goal; this is documented in "Traffic Flow Measurement: Architecture" [RTFM-ARC]. The architecture defines three entities: - METERS, which observe network traffic flows and build up a table of flow data records for them, - METER READERS, which collect traffic flow data from meters, and - MANAGERS, which oversee the operation of meters and meter readers. This memo defines the SNMP management information for a Traffic Flow Meter (TFM). Work in this field was begun by the Internet Accounting Working Group. It has been further developed and expanded by the Realtime Traffic Flow Measurement Working Group. Brownlee Standards Track [Page 3] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 3.1 Scope of Definitions, Textual Conventions All objects defined in this memo are registered in a single subtree within the mib-2 namespace [MIB-II, RFC2578], and are for use in network devices which may perform a PDU forwarding or monitoring function. For these devices, this MIB defines a group of objects with an SMI Network Management MGMT Code [ASG-NBR] of 40, i.e. flowMIB OBJECT IDENTIFIER ::= mib-2 40 as defined below. The RTFM Meter MIB was first produced and tested using SNMPv1. It was converted into SNMPv2 following the guidelines in [RFC1908]. 3.2 Usage of the MIB variables The MIB is organised in four parts - control, data, rules and conformance statements. The rules implement the set of packet-matching actions, as described in the "Traffic Flow Measurment: Architecture" document [RTFM-ARC]. In addition they provide for BASIC-style subroutines, allowing a network manager to dramatically reduce the number of rules required to monitor a large network. Traffic flows are identified by a set of attributes for each of their end-points. Attributes include network addresses for each layer of the network protocol stack, and 'subscriber ids', which may be used to identify an accountable entity for the flow. The conformance statements are set out as defined in [RFC2580]. They explain what must be implemented in a meter which claims to conform to this MIB. To retrieve flow data one could simply do a linear scan of the flow table. This would certainly work, but would require a lot of protocol exchanges. To reduce the overhead in retrieving flow data the flow table uses a TimeFilter variable, defined as a Textual Convention in the RMON2 MIB [RMON2-MIB]. As an alternative method of reading flow data, the MIB provides a view of the flow table called the flowDataPackageTable. This is (logically) a four-dimensional array, subscripted by package selector, RuleSet, activity time and starting flow number. The package selector is a sequence of bytes which specifies a list of flow attributes. Brownlee Standards Track [Page 4] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 A data package (as returned by the meter) is a sequence of values for the attributes specified in its selector, encoded using the Basic Encoding Rules [ASN-BER]. It allows a meter reader to retrieve all the attribute values it requires in a single MIB object. This, when used together with SNMPv2's GetBulk request, allows a meter reader to scan the flow table and upload a specified set of attribute values for flows which have changed since the last reading, and which were created by a specified rule set. One aspect of data collection which needs emphasis is that all the MIB variables are set up to allow multiple independent meter readers to work properly, i.e. the flow table indexes are stateless. An alternative approach would have been to 'snapshot' the flow table, which would mean that the meter readers would have to be synchronized. The stateless approach does mean that two meter readers will never return exactly the same set of traffic counts, but over long periods (e.g. 15-minute collections over a day) the discrepancies are acceptable. If one really needs a snapshot, this can be achieved by switching to an identical rule set with a different RuleSet number, hence asynchronous collections may be regarded as a useful generalisation of synchronised ones. The control variables are the minimum set required for a meter reader. Their number has been whittled down as experience has been gained with the MIB implementation. A few of them are 'general', i.e. they control the overall behaviour of the meter. These are set by a single 'master' manager, and no other manager should attempt to change their values. The decision as to which manager is the ' master' must be made by the network operations personnel responsible; this MIB does not attempt to define any interaction between managers. There are three other groups of control variables, arranged into tables in the same way as in the RMON2 MIB [RMON2-MIB]. They are used as follows: - RULE SET INFO: Before attempting to download a RuleSet, a manager must create a row in the flowRuleSetInfoTable and set its flowRuleInfoSize to a value large enough to hold the RuleSet. When the rule set is ready the manager must set flowRuleInfoRulesReady to 'true', indicating that the rule set is ready for use (but not yet 'running'). - METER READER INFO: Any meter reader wishing to collect data reliably for all flows from a RuleSet should first create a row in the flowReaderInfoTable with flowReaderRuleSet set to that RuleSet's index in the flowRuleSetInfoTable. It should write that row's flowReaderLastTime object each time it starts a collection Brownlee Standards Track [Page 5] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 pass through the flow table. The meter will not recover a flow's memory until every meter reader holding a row for that flow's RuleSet has collected the flow's data. - MANAGER INFO: Any manager wishing to run a RuleSet in the meter must create a row in the flowManagerInfo table, specifying the desired RuleSet to run and its corresponding 'standby' RuleSet (if one is desired). A current RuleSet is 'running' if its flowManagerRunningStandby value is false(2), similarly a standby RuleSet is 'running' if flowManagerRunningStandby is true(1). Times within the meter are in terms of its Uptime, i.e. centiseconds since the meter started. For meters implemented as self-contained SNMP agents this will be the same as sysUptime, but this may not be true for meters implemented as subagents. Managers can read the meter's Uptime when neccessary (e.g. to set a TimeFilter value) by setting flowReaderLastTime, then reading its new value. 4 Definitions FLOW-METER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64, Integer32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, TruthValue FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF ifIndex FROM IF-MIB TimeFilter FROM RMON2-MIB; flowMIB MODULE-IDENTITY LAST-UPDATED "9910250000Z" -- October 25, 1999 ORGANIZATION "IETF Realtime Traffic Flow Measurement Working Group" CONTACT-INFO "Nevil Brownlee, The University of Auckland Postal: Information Technology Sytems & Services The University of Auckland Private Bag 92-019 Auckland, New Zealand Phone: +64 9 373 7599 x8941 E-mail: n.brownlee@auckland.ac.nz" Brownlee Standards Track [Page 6] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 DESCRIPTION "MIB for the RTFM Traffic Flow Meter." REVISION "9910250000Z" DESCRIPTION "Initial Version, published as RFC 2720." REVISION "9908301250Z" DESCRIPTION "UTF8OwnerString Textual Convention added, and used to replace OwnerString. Conceptually the same as OwnerString, but facilitating internationalisation by using UTF-8 encoding for its characters rather than US-ASCII." REVISION "9908191010Z" DESCRIPTION "Changes to SIZE specification for two variables: - flowRuleInfoName SIZE specified as (0..127) - flowRuleIndex SIZE increased to (1..2147483647)" REVISION "9712230937Z" DESCRIPTION "Two further variables deprecated: - flowRuleInfoRulesReady (use flowRuleInfoStatus intead) - flowDataStatus (contains no useful information)" REVISION "9707071715Z" DESCRIPTION "Significant changes since RFC 2064 include: - flowDataPackageTable added - flowColumnActivityTable deprecated - flowManagerCounterWrap deprecated" REVISION "9603080208Z" DESCRIPTION "Initial version of this MIB (RFC 2064)" ::= { mib-2 40 } flowControl OBJECT IDENTIFIER ::= { flowMIB 1 } flowData OBJECT IDENTIFIER ::= { flowMIB 2 } flowRules OBJECT IDENTIFIER ::= { flowMIB 3 } flowMIBConformance OBJECT IDENTIFIER ::= { flowMIB 4 } -- Textual Conventions Brownlee Standards Track [Page 7] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 UTF8OwnerString ::= TEXTUAL-CONVENTION DISPLAY-HINT "127t" STATUS current DESCRIPTION "An administratively assigned name for the owner of a resource, conceptually the same as OwnerString in the RMON MIB [RMON-MIB]. To facilitate internationalisation, this name information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in the UTF-8 standard [UTF-8]." SYNTAX OCTET STRING (SIZE (0..127)) PeerType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the type of a PeerAddress (see below). The values used are from the 'Address Family Numbers' section of the Assigned Numbers RFC [ASG-NBR]. Peer types from other address families may also be used, provided only that they are identified by their assigned Address Family numbers." SYNTAX INTEGER { ipv4(1), ipv6(2), nsap(3), ipx(11), appletalk(12), decnet(13) } PeerAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the value of a peer address for various network protocols. Address format depends on the actual protocol, as indicated below: IPv4: ipv4(1) 4-octet IpAddress (defined in the SNMPv2 SMI [RFC2578]) IPv6: ipv6(2) 16-octet IpAddress (defined in the IPv6 Addressing RFC [V6-ADDR]) CLNS: nsap(3) NsapAddress (defined in the SNMPv2 SMI [RFC2578]) Novell: ipx(11) Brownlee Standards Track [Page 8] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 4-octet Network number, 6-octet Host number (MAC address) AppleTalk: appletalk(12) 2-octet Network number (sixteen bits), 1-octet Host number (eight bits) DECnet: decnet(13) 1-octet Area number (in low-order six bits), 2-octet Host number (in low-order ten bits) " SYNTAX OCTET STRING (SIZE (3..20)) AdjacentType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the type of an adjacent address. May be a medium type or (if metering is taking place inside a tunnel) a PeerType (see above). The values used for IEEE 802 medium types are from the 'Network Management Parameters (ifType definitions)' section of the Assigned Numbers RFC [ASG-NBR]. Other medium types may also be used, provided only that they are identified by their assigned ifType numbers." SYNTAX INTEGER { ip(1), nsap(3), ethernet(7), -- ethernet-like [ENET-OBJ], -- includes ethernet-csmacd(6) tokenring(9), ipx(11), appletalk(12), decnet(13), fddi(15) } AdjacentAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the value of an adjacent address. May be a Medium Access Control (MAC) address or (if metering is taking place inside a tunnel) a PeerAddress (see above). MAC Address format depends on the actual medium, as follows: Ethernet: ethernet(7) 6-octet 802.3 MAC address in 'canonical' order Brownlee Standards Track [Page 9] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 Token Ring: tokenring(9) 6-octet 802.5 MAC address in 'canonical' order FDDI: fddi(15) FddiMACLongAddress, i.e. a 6-octet MAC address in 'canonical' order (defined in [FDDI-MIB]) " SYNTAX OCTET STRING (SIZE (3..20)) TransportType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the type of a TransportAddress (see below). Values will depend on the actual protocol; for IP they will be those given in the 'Protocol Numbers' section of the Assigned Numbers RFC [ASG-NBR], including icmp(1), tcp(6) and udp(17)." SYNTAX Integer32 (1..255) TransportAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the value of a transport address for various network protocols. Format as follows: IP: 2-octet UDP or TCP port number Other protocols: 2-octet port number " SYNTAX OCTET STRING (SIZE (2)) RuleAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the value of an address. Is a superset of MediumAddress, PeerAddress and TransportAddress." SYNTAX OCTET STRING (SIZE (2..20)) FlowAttributeNumber ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Uniquely identifies an attribute within a flow data record." SYNTAX INTEGER { flowIndex(1), flowStatus(2), flowTimeMark(3), Brownlee Standards Track [Page 10] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 sourceInterface(4), sourceAdjacentType(5), sourceAdjacentAddress(6), sourceAdjacentMask(7), sourcePeerType(8), sourcePeerAddress(9), sourcePeerMask(10), sourceTransType(11), sourceTransAddress(12), sourceTransMask(13), destInterface(14), destAdjacentType(15), destAdjacentAddress(16), destAdjacentMask(17), destPeerType(18), destPeerAddress(19), destPeerMask(20), destTransType(21), destTransAddress(22), destTransMask(23), pduScale(24), octetScale(25), ruleSet(26), toOctets(27), -- Source-to-Dest toPDUs(28), fromOctets(29), -- Dest-to-Source fromPDUs(30), firstTime(31), -- Activity times lastActiveTime(32), sourceSubscriberID(33), -- Subscriber ID destSubscriberID(34), sessionID(35), sourceClass(36), -- Computed attributes destClass(37), flowClass(38), sourceKind(39), destKind(40), flowKind(41) } RuleAttributeNumber ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Uniquely identifies an attribute which may be tested in Brownlee Standards Track [Page 11] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 a rule. These include attributes whose values come directly from (or are computed from) the flow's packets, and the five 'meter' variables used to hold an Attribute Number." SYNTAX INTEGER { null(0), sourceInterface(4), -- Source Address sourceAdjacentType(5), sourceAdjacentAddress(6), sourcePeerType(8), sourcePeerAddress(9), sourceTransType(11), sourceTransAddress(12), destInterface(14), -- Dest Address destAdjacentType(15), destAdjacentAddress(16), destPeerType(18), destPeerAddress(19), destTransType(21), destTransAddress(22), sourceSubscriberID(33), -- Subscriber ID destSubscriberID(34), sessionID(35), sourceClass(36), -- Computed attributes destClass(37), flowClass(38), sourceKind(39), destKind(40), flowKind(41), matchingStoD(50), -- Packet matching v1(51), -- Meter variables v2(52), v3(53), v4(54), v5(55) } ActionNumber ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Uniquely identifies the action of a rule, i.e. the Pattern Matching Engine's opcode number. Details of the opcodes are given in the 'Traffic Flow Measurement: Architecture' document [RTFM-ARC]." SYNTAX INTEGER { Brownlee Standards Track [Page 12] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 ignore(1), noMatch(2), count(3), countPkt(4), return(5), gosub(6), gosubAct(7), assign(8), assignAct(9), goto(10), gotoAct(11), pushRuleTo(12), pushRuleToAct(13), pushPktTo(14), pushPktToAct(15), popTo(16), popToAct(17) } -- -- Control Group: RuleSet Info Table -- flowRuleSetInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowRuleSetInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An array of information about the RuleSets held in the meter. Any manager may configure a new RuleSet for the meter by creating a row in this table with status active(1), and setting values for all the objects in its rules. At this stage the new RuleSet is available but not 'running', i.e. it is not being used by the meter to produce entries in the flow table. To actually 'run' a RuleSet a manager must create a row in the flowManagerInfoTable, set it's flowManagerStatus to active(1), and set either its CurrentRuleSet or StandbyRuleSet to point to the RuleSet to be run. Once a RuleSet is running a manager may not change any of the objects within the RuleSet itself. Any attempt to do so should result in a notWritable(17) SNMP error-status for such objects. A manager may stop a RuleSet running by removing all references to it in the flowManagerInfoTable (i.e. by setting CurrentRuleSet and StandbyRuleSet values to 0). This provides Brownlee Standards Track [Page 13] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 a way to stop RuleSets left running if a manager fails. For example, when a manager is started, it could search the meter's flowManager table and stop all RuleSets having a specified value of flowRuleInfoOwner. To prevent a manager from interfering with variables belonging to another manager, the meter should use MIB views [RFC2575] so as to limit each manager's access to the meter's variables, effectively dividing the single meter into several virtual meters, one for each independent manager." ::= { flowControl 1 } flowRuleSetInfoEntry OBJECT-TYPE SYNTAX FlowRuleSetInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular RuleSet." INDEX { flowRuleInfoIndex } ::= { flowRuleSetInfoTable 1 } FlowRuleSetInfoEntry ::= SEQUENCE { flowRuleInfoIndex Integer32, flowRuleInfoSize Integer32, flowRuleInfoOwner UTF8OwnerString, flowRuleInfoTimeStamp TimeStamp, flowRuleInfoStatus RowStatus, flowRuleInfoName OCTET STRING, flowRuleInfoRulesReady TruthValue, flowRuleInfoFlowRecords Integer32 } flowRuleInfoIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index which selects an entry in the flowRuleSetInfoTable. Each such entry contains control information for a particular RuleSet which the meter may run." ::= { flowRuleSetInfoEntry 1 } flowRuleInfoSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Number of rules in this RuleSet. Setting this variable will Brownlee Standards Track [Page 14] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 cause the meter to allocate space for these rules." ::= { flowRuleSetInfoEntry 2 } flowRuleInfoOwner OBJECT-TYPE SYNTAX UTF8OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the manager which 'owns' this RuleSet. A manager must set this variable when creating a row in this table." ::= { flowRuleSetInfoEntry 3 } flowRuleInfoTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Time this row's associated RuleSet was last changed." ::= { flowRuleSetInfoEntry 4 } flowRuleInfoStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this flowRuleSetInfoEntry. If this value is not active(1) the meter must not attempt to use the row's associated RuleSet. Once its value has been set to active(1) a manager may not change any of the other variables in the row, nor the contents of the associated RuleSet. Any attempt to do so should result in a notWritable(17) SNMP error-status for such variables or objects. To download a RuleSet, a manger could: - Locate an open slot in the RuleSetInfoTable. - Create a RuleSetInfoEntry by setting the status for this open slot to createAndWait(5). - Set flowRuleInfoSize and flowRuleInfoName as required. - Download the rules into the row's rule table. - Set flowRuleInfoStatus to active(1). The RuleSet would then be ready to run. The manager is not allowed to change the value of flowRuleInfoStatus from active(1) if the associated RuleSet is being referenced by any of the entries in the flowManagerInfoTable. Setting RuleInfoStatus to destroy(6) destroys the associated RuleSet together with any flow data collected by it." Brownlee Standards Track [Page 15] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 ::= { flowRuleSetInfoEntry 5 } flowRuleInfoName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..127)) MAX-ACCESS read-create STATUS current DESCRIPTION "An alphanumeric identifier used by managers and readers to identify a RuleSet. For example, a manager wishing to run a RuleSet named WWW-FLOWS could search the flowRuleSetInfoTable to see whether the WWW-FLOWS RuleSet is already available on the meter. Note that references to RuleSets in the flowManagerInfoTable use indexes for their flowRuleSetInfoTable entries. These may be different each time the RuleSet is loaded into a meter." ::= { flowRuleSetInfoEntry 6 } flowRuleInfoRulesReady OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Indicates whether the rules for this row's associated RuleSet are ready for use. The meter will refuse to 'run' the RuleSet unless this variable has been set to true(1). While RulesReady is false(2), the manager may modify the RuleSet, for example by downloading rules into it." ::= { flowRuleSetInfoEntry 7 } flowRuleInfoFlowRecords OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the flow table for this RuleSet. These may be current (waiting for collection by one or more meter readers) or idle (waiting for the meter to recover their memory)." ::= { flowRuleSetInfoEntry 8 } -- -- Control Group: Interface Info Table -- flowInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowInterfaceEntry MAX-ACCESS not-accessible Brownlee Standards Track [Page 16] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 STATUS current DESCRIPTION "An array of information specific to each meter interface." ::= { flowControl 2 } flowInterfaceEntry OBJECT-TYPE SYNTAX FlowInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular interface." INDEX { ifIndex } ::= { flowInterfaceTable 1 } FlowInterfaceEntry ::= SEQUENCE { flowInterfaceSampleRate Integer32, flowInterfaceLostPackets Counter32 } flowInterfaceSampleRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The parameter N for statistical counting on this interface. Set to N to count 1/Nth of the packets appearing at this interface. A sampling rate of 1 counts all packets. A sampling rate of 0 results in the interface being ignored by the meter. A meter should choose its own algorithm to introduce variance into the sampling so that exactly every Nth packet is counted. The IPPM Working Group's RFC 'Framework for IP Performance Metrics' [IPPM-FRM] explains why this should be done, and sets out an algorithm for doing it." DEFVAL { 1 } ::= { flowInterfaceEntry 1 } flowInterfaceLostPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets the meter has lost for this interface. Such losses may occur because the meter has been unable to keep up with the traffic volume." ::= { flowInterfaceEntry 2 } Brownlee Standards Track [Page 17] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 -- -- Control Group: Meter Reader Info Table -- -- Any meter reader wishing to collect data reliably for flows -- should first create a row in this table. It should write that -- row's flowReaderLastTime object each time it starts a collection -- pass through the flow table. -- If a meter reader (MR) does not create a row in this table, e.g. -- because its MIB view [RFC2575] did not allow MR create access to -- flowReaderStatus, collection can still proceed but the meter will -- not be aware of meter reader MR. This could lead the meter to -- recover flows before they have been collected by MR. flowReaderInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowReaderInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An array of information about meter readers which have registered their intent to collect flow data from this meter." ::= { flowControl 3 } flowReaderInfoEntry OBJECT-TYPE SYNTAX FlowReaderInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular meter reader." INDEX { flowReaderIndex } ::= { flowReaderInfoTable 1 } FlowReaderInfoEntry ::= SEQUENCE { flowReaderIndex Integer32, flowReaderTimeout Integer32, flowReaderOwner UTF8OwnerString, flowReaderLastTime TimeStamp, flowReaderPreviousTime TimeStamp, flowReaderStatus RowStatus, flowReaderRuleSet Integer32 } flowReaderIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION Brownlee Standards Track [Page 18] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 "An index which selects an entry in the flowReaderInfoTable." ::= { flowReaderInfoEntry 1 } flowReaderTimeout OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum time (in seconds) between flow data collections for this meter reader. If this time elapses without a collection, the meter should assume that this meter reader has stopped collecting, and delete this row from the table. A value of zero indicates that this row should not be timed out." ::= { flowReaderInfoEntry 2 } flowReaderOwner OBJECT-TYPE SYNTAX UTF8OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the meter reader which created this row." ::= { flowReaderInfoEntry 3 } flowReaderLastTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-create STATUS current DESCRIPTION "Time this meter reader began its most recent data collection. This variable should be written by a meter reader as its first step in reading flow data. The meter will set this LastTime value to its current Uptime, and set its PreviousTime value (below) to the old LastTime. This allows the meter to recover flows which have been inactive since PreviousTime, for these have been collected at least once. If the meter reader fails to write flowLastReadTime, collection may still proceed but the meter may not be able to recover inactive flows until the flowReaderTimeout has been reached for this entry." ::= { flowReaderInfoEntry 4 } flowReaderPreviousTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current Brownlee Standards Track [Page 19] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 DESCRIPTION "Time this meter reader began the collection before last." ::= { flowReaderInfoEntry 5 } flowReaderStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this FlowReaderInfoEntry. A value of active(1) implies that the associated reader should be collecting data from the meter. Once this variable has been set to active(1) a manager may only change this row's flowReaderLastTime and flowReaderTimeout variables." ::= { flowReaderInfoEntry 6 } flowReaderRuleSet OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "An index to the array of RuleSets. Specifies a set of rules of interest to this meter reader. The reader will attempt to collect any data generated by the meter for this RuleSet, and the meter will not recover the memory of any of the RuleSet's flows until this collection has taken place. Note that a reader may have entries in this table for several RuleSets." ::= { flowReaderInfoEntry 7 } -- -- Control Group: Manager Info Table -- -- Any manager wishing to run a RuleSet must create a row in this -- table. Once it has a table row, the manager may set the control -- variables in its row so as to cause the meter to run any valid -- RuleSet held by the meter. -- A single manager may run several RuleSets; it must create a row -- in this table for each of them. In short, each row of this table -- describes (and controls) a 'task' which the meter is executing. flowManagerInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowManagerInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An array of information about managers which have Brownlee Standards Track [Page 20] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 registered their intent to run RuleSets on this meter." ::= { flowControl 4 } flowManagerInfoEntry OBJECT-TYPE SYNTAX FlowManagerInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular meter 'task.' By creating an entry in this table and activating it, a manager requests that the meter 'run' the indicated RuleSet. The entry also specifies a HighWaterMark and a StandbyRuleSet. If the meter's flow table usage exceeds this task's HighWaterMark the meter will stop running the task's CurrentRuleSet and switch to its StandbyRuleSet. If the value of the task's StandbyRuleSet is 0 when its HighWaterMark is exceeded, the meter simply stops running the task's CurrentRuleSet. By careful selection of HighWaterMarks for the various tasks a manager can ensure that the most critical RuleSets are the last to stop running as the number of flows increases. When a manager has determined that the demand for flow table space has abated, it may cause the task to switch back to its CurrentRuleSet by setting its flowManagerRunningStandby variable to false(2)." INDEX { flowManagerIndex } ::= { flowManagerInfoTable 1 } FlowManagerInfoEntry ::= SEQUENCE { flowManagerIndex Integer32, flowManagerCurrentRuleSet Integer32, flowManagerStandbyRuleSet Integer32, flowManagerHighWaterMark Integer32, flowManagerCounterWrap INTEGER, flowManagerOwner UTF8OwnerString, flowManagerTimeStamp TimeStamp, flowManagerStatus RowStatus, flowManagerRunningStandby TruthValue } flowManagerIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION Brownlee Standards Track [Page 21] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 "An index which selects an entry in the flowManagerInfoTable." ::= { flowManagerInfoEntry 1 } flowManagerCurrentRuleSet OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Index to the array of RuleSets. Specifies which set of rules is the 'current' one for this task. The meter will be 'running' the current RuleSet if this row's flowManagerRunningStandby value is false(2). When the manager sets this variable the meter will stop using the task's old current RuleSet and start using the new one. Specifying RuleSet 0 (the empty set) stops flow measurement for this task." ::= { flowManagerInfoEntry 2 } flowManagerStandbyRuleSet OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Index to the array of RuleSets. After reaching HighWaterMark (see below) the manager will switch to using the task's StandbyRuleSet in place of its CurrentRuleSet. For this to be effective the designated StandbyRuleSet should have a coarser reporting granularity then the CurrentRuleSet. The manager may also need to decrease the meter reading interval so that the meter can recover flows measured by this task's CurrentRuleSet." DEFVAL { 0 } -- No standby ::= { flowManagerInfoEntry 3 } flowManagerHighWaterMark OBJECT-TYPE SYNTAX Integer32 (0..100) MAX-ACCESS read-create STATUS current DESCRIPTION "A value expressed as a percentage, interpreted by the meter as an indication of how full the flow table should be before it should switch to the standby RuleSet (if one has been specified) for this task. Values of 0% or 100% disable the checking represented by this variable." ::= { flowManagerInfoEntry 4 } flowManagerCounterWrap OBJECT-TYPE SYNTAX INTEGER { wrap(1), scale(2) } Brownlee Standards Track [Page 22] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Specifies whether PDU and octet counters should wrap when they reach the top of their range (normal behaviour for Counter64 objects), or whether their scale factors should be used instead. The combination of counter and scale factor allows counts to be returned as non-negative binary floating point numbers, with 64-bit mantissas and 8-bit exponents." DEFVAL { wrap } ::= { flowManagerInfoEntry 5 } flowManagerOwner OBJECT-TYPE SYNTAX UTF8OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the manager which created this row." ::= { flowManagerInfoEntry 6 } flowManagerTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Time this row was last changed by its manager." ::= { flowManagerInfoEntry 7 } flowManagerStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row in the flowManagerInfoTable. A value of active(1) implies that this task may be activated, by setting its CurrentRuleSet and StandbyRuleSet variables. Its HighWaterMark and RunningStandby variables may also be changed." ::= { flowManagerInfoEntry 8 } flowManagerRunningStandby OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Set to true(1) by the meter to indicate that it has switched to runnning this task's StandbyRuleSet in place of its Brownlee Standards Track [Page 23] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 CurrentRuleSet. To switch back to the CurrentRuleSet, the manager may simply set this variable to false(2)." DEFVAL { false } ::= { flowManagerInfoEntry 9 } -- -- Control Group: General Meter Control Variables -- flowFloodMark OBJECT-TYPE SYNTAX Integer32 (0..100) MAX-ACCESS read-write STATUS current DESCRIPTION "A value expressed as a percentage, interpreted by the meter as an indication of how full the flow table should be before it should take some action to avoid running out of resources to handle new flows, as discussed in section 4.6 (Handling Increasing Traffic Levels) of the RTFM Architecture RFC [RTFM-ARC]. Values of 0% or 100% disable the checking represented by this variable." DEFVAL { 95 } -- Enabled by default. ::= { flowControl 5 } flowInactivityTimeout OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The time in seconds since the last packet seen, after which a flow becomes 'idle.' Note that although a flow may be idle, it will not be discarded (and its memory recovered) until after its data has been collected by all the meter readers registered for its RuleSet." DEFVAL { 600 } -- 10 minutes ::= { flowControl 6 } flowActiveFlows OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of flows which are currently in use." ::= { flowControl 7 } flowMaxFlows OBJECT-TYPE Brownlee Standards Track [Page 24] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of flows allowed in the meter's flow table. At present this is determined when the meter is first started up." ::= { flowControl 8 } flowFloodMode OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates that the meter has passed its FloodMark and is not running in its normal mode. When the manager notices this it should take action to remedy the problem which caused the flooding. It should then monitor flowActiveFlows so as to determine when the flood has receded. At that point the manager may set flowFloodMode to false(2) to resume normal operation." ::= { flowControl 9 } -- -- The Flow Table -- -- This is a table kept by a meter, with one flow data entry for every -- flow being measured. Each flow data entry stores the attribute -- values for a traffic flow. Details of flows and their attributes -- are given in the 'Traffic Flow Measurement: Architecture' -- document [RTFM-ARC]. -- From time to time a meter reader may sweep the flow table so as -- to read counts. This is most effectively achieved by using the -- TimeMark variable together with successive GetBulk requests to -- retrieve the values of the desired flow attribute variables. -- This scheme allows multiple meter readers to independently use the -- same meter; the meter readers do not have to be synchronised and -- they may use different collection intervals. -- If identical sets of counts are required from a meter, a manager -- could achieve this using two identical copies of a RuleSet in that -- meter and switching back and forth between them. This is discussed -- further in the RTFM Architecture document [RTFM-ARC]. Brownlee Standards Track [Page 25] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 flowDataTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The list of all flows being measured." ::= { flowData 1 } flowDataEntry OBJECT-TYPE SYNTAX FlowDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The flow data record for a particular flow." INDEX { flowDataRuleSet, flowDataTimeMark, flowDataIndex } ::= { flowDataTable 1 } FlowDataEntry ::= SEQUENCE { flowDataIndex Integer32, flowDataTimeMark TimeFilter, flowDataStatus INTEGER, flowDataSourceInterface Integer32, flowDataSourceAdjacentType AdjacentType, flowDataSourceAdjacentAddress AdjacentAddress, flowDataSourceAdjacentMask AdjacentAddress, flowDataSourcePeerType PeerType, flowDataSourcePeerAddress PeerAddress, flowDataSourcePeerMask PeerAddress, flowDataSourceTransType TransportType, flowDataSourceTransAddress TransportAddress, flowDataSourceTransMask TransportAddress, flowDataDestInterface Integer32, flowDataDestAdjacentType AdjacentType, flowDataDestAdjacentAddress AdjacentAddress, flowDataDestAdjacentMask AdjacentAddress, flowDataDestPeerType PeerType, flowDataDestPeerAddress PeerAddress, flowDataDestPeerMask PeerAddress, flowDataDestTransType TransportType, flowDataDestTransAddress TransportAddress, flowDataDestTransMask TransportAddress, flowDataPDUScale Integer32, flowDataOctetScale Integer32, flowDataRuleSet Integer32, Brownlee Standards Track [Page 26] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 flowDataToOctets Counter64, -- Source->Dest flowDataToPDUs Counter64, flowDataFromOctets Counter64, -- Dest->Source flowDataFromPDUs Counter64, flowDataFirstTime TimeStamp, -- Activity times flowDataLastActiveTime TimeStamp, flowDataSourceSubscriberID OCTET STRING, flowDataDestSubscriberID OCTET STRING, flowDataSessionID OCTET STRING, flowDataSourceClass Integer32, flowDataDestClass Integer32, flowDataClass Integer32, flowDataSourceKind Integer32, flowDataDestKind Integer32, flowDataKind Integer32 } flowDataIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Value of this flow data record's index within the meter's flow table." ::= { flowDataEntry 1 } flowDataTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. Allows GetNext and GetBulk to find flow table rows which have changed since a specified value of the meter's Uptime." ::= { flowDataEntry 2 } flowDataStatus OBJECT-TYPE SYNTAX INTEGER { inactive(1), current(2) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Status of this flow data record." ::= { flowDataEntry 3 } flowDataSourceInterface OBJECT-TYPE SYNTAX Integer32 Brownlee Standards Track [Page 27] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "Index of the interface associated with the source address for this flow. It's value is one of those contained in the ifIndex field of the meter's interfaces table." ::= { flowDataEntry 4 } flowDataSourceAdjacentType OBJECT-TYPE SYNTAX AdjacentType MAX-ACCESS read-only STATUS current DESCRIPTION "Adjacent address type of the source for this flow. If metering is being performed at the network level, AdjacentType will indicate the medium for the interface on which the flow was observed and AdjacentAddress will be the MAC address for that interface. This is the usual case. If traffic is being metered inside a tunnel, AdjacentType will be the peer type of the host at the end of the tunnel and AdjacentAddress will be the peer address for that host." ::= { flowDataEntry 5 } flowDataSourceAdjacentAddress OBJECT-TYPE SYNTAX AdjacentAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Address of the adjacent device on the path for the source for this flow." ::= { flowDataEntry 6 } flowDataSourceAdjacentMask OBJECT-TYPE SYNTAX AdjacentAddress MAX-ACCESS read-only STATUS current DESCRIPTION "1-bits in this mask indicate which bits must match when comparing the adjacent source address for this flow." ::= { flowDataEntry 7 } flowDataSourcePeerType OBJECT-TYPE SYNTAX PeerType MAX-ACCESS read-only STATUS current DESCRIPTION Brownlee Standards Track [Page 28] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 "Peer address type of the source for this flow." ::= { flowDataEntry 8 } flowDataSourcePeerAddress OBJECT-TYPE SYNTAX PeerAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Address of the peer device for the source of this flow." ::= { flowDataEntry 9 } flowDataSourcePeerMask OBJECT-TYPE SYNTAX PeerAddress MAX-ACCESS read-only STATUS current DESCRIPTION "1-bits in this mask indicate which bits must match when comparing the source peer address for this flow." ::= { flowDataEntry 10 } flowDataSourceTransType OBJECT-TYPE SYNTAX TransportType MAX-ACCESS read-only STATUS current DESCRIPTION "Transport address type of the source for this flow. The value of this attribute will depend on the peer address type." ::= { flowDataEntry 11 } flowDataSourceTransAddress OBJECT-TYPE SYNTAX TransportAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Transport address for the source of this flow." ::= { flowDataEntry 12 } flowDataSourceTransMask OBJECT-TYPE SYNTAX TransportAddress MAX-ACCESS read-only STATUS current DESCRIPTION "1-bits in this mask indicate which bits must match when comparing the transport source address for this flow." ::= { flowDataEntry 13 } flowDataDestInterface OBJECT-TYPE SYNTAX Integer32 Brownlee Standards Track [Page 29] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "Index of the interface associated with the dest address for this flow. This value is one of the values contained in the ifIndex field of the interfaces table." ::= { flowDataEntry 14 } flowDataDestAdjacentType OBJECT-TYPE SYNTAX AdjacentType MAX-ACCESS read-only STATUS current DESCRIPTION "Adjacent address type of the destination for this flow." ::= { flowDataEntry 15 } flowDataDestAdjacentAddress OBJECT-TYPE SYNTAX AdjacentAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Address of the adjacent device on the path for the destination for this flow." ::= { flowDataEntry 16 } flowDataDestAdjacentMask OBJECT-TYPE SYNTAX AdjacentAddress MAX-ACCESS read-only STATUS current DESCRIPTION "1-bits in this mask indicate which bits must match when comparing the adjacent destination address for this flow." ::= { flowDataEntry 17 } flowDataDestPeerType OBJECT-TYPE SYNTAX PeerType MAX-ACCESS read-only STATUS current DESCRIPTION "Peer address type of the destination for this flow." ::= { flowDataEntry 18 } flowDataDestPeerAddress OBJECT-TYPE SYNTAX PeerAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Address of the peer device for the destination of this flow." Brownlee Standards Track [Page 30] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 ::= { flowDataEntry 19 } flowDataDestPeerMask OBJECT-TYPE SYNTAX PeerAddress MAX-ACCESS read-only STATUS current DESCRIPTION "1-bits in this mask indicate which bits must match when comparing the destination peer type for this flow." ::= { flowDataEntry 20 } flowDataDestTransType OBJECT-TYPE SYNTAX TransportType MAX-ACCESS read-only STATUS current DESCRIPTION "Transport address type of the destination for this flow. The value of this attribute will depend on the peer address type." ::= { flowDataEntry 21 } flowDataDestTransAddress OBJECT-TYPE SYNTAX TransportAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Transport address for the destination of this flow." ::= { flowDataEntry 22 } flowDataDestTransMask OBJECT-TYPE SYNTAX TransportAddress MAX-ACCESS read-only STATUS current DESCRIPTION "1-bits in this mask indicate which bits must match when comparing the transport destination address for this flow." ::= { flowDataEntry 23 } flowDataPDUScale OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The scale factor applied to this particular flow. Indicates the number of bits the PDU counter values should be moved left to obtain the actual values." ::= { flowDataEntry 24 } flowDataOctetScale OBJECT-TYPE Brownlee Standards Track [Page 31] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The scale factor applied to this particular flow. Indicates the number of bits the octet counter values should be moved left to obtain the actual values." ::= { flowDataEntry 25 } flowDataRuleSet OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RuleSet number of the RuleSet which created this flow. Allows a manager to use GetNext or GetBulk requests to find flows belonging to a particular RuleSet." ::= { flowDataEntry 26 } flowDataToOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of octets flowing from source to destination for this flow." ::= { flowDataEntry 27 } flowDataToPDUs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of packets flowing from source to destination for this flow." ::= { flowDataEntry 28 } flowDataFromOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of octets flowing from destination to source for this flow." ::= { flowDataEntry 29 } flowDataFromPDUs OBJECT-TYPE SYNTAX Counter64 Brownlee Standards Track [Page 32] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of packets flowing from destination to source for this flow." ::= { flowDataEntry 30 } flowDataFirstTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which this flow was first entered in the table" ::= { flowDataEntry 31 } flowDataLastActiveTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The last time this flow had activity, i.e. the time of arrival of the most recent PDU belonging to this flow." ::= { flowDataEntry 32 } flowDataSourceSubscriberID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..20)) MAX-ACCESS read-only STATUS current DESCRIPTION "Subscriber ID associated with the source address for this flow. A Subscriber ID is an unspecified text string, used to ascribe traffic flows to individual users. At this time the means by which a Subscriber ID may be associated with a flow is unspecified." ::= { flowDataEntry 33 } flowDataDestSubscriberID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..20)) MAX-ACCESS read-only STATUS current DESCRIPTION "Subscriber ID associated with the destination address for this flow. A Subscriber ID is an unspecified text string, used to ascribe traffic flows to individual users. At this time the means by which a Subscriber ID may be associated with a flow is unspecified." ::= { flowDataEntry 34 } Brownlee Standards Track [Page 33] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 flowDataSessionID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..10)) MAX-ACCESS read-only STATUS current DESCRIPTION "Session ID for this flow. Such an ID might be allocated by a network access server to distinguish a series of sessions between the same pair of addresses, which would otherwise appear to be parts of the same accounting flow." ::= { flowDataEntry 35 } flowDataSourceClass OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Source class for this flow. Determined by the rules, set by a PushRule action when this flow was entered in the table." ::= { flowDataEntry 36 } flowDataDestClass OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination class for this flow. Determined by the rules, set by a PushRule action when this flow was entered in the table." ::= { flowDataEntry 37 } flowDataClass OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Class for this flow. Determined by the rules, set by a PushRule action when this flow was entered in the table." ::= { flowDataEntry 38 } flowDataSourceKind OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Source kind for this flow. Determined by the rules, set by a PushRule action when this flow was entered in the table." ::= { flowDataEntry 39 } flowDataDestKind OBJECT-TYPE Brownlee Standards Track [Page 34] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination kind for this flow. Determined by the rules, set by a PushRule action when this flow was entered in the table." ::= { flowDataEntry 40 } flowDataKind OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Class for this flow. Determined by the rules, set by a PushRule action when this flow was entered in the table." ::= { flowDataEntry 41 } -- -- The Activity Column Table -- flowColumnActivityTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowColumnActivityEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Index into the Flow Table. Allows a meter reader to retrieve a list containing the flow table indexes of flows which were last active at or after a given time, together with the values of a specified attribute for each such flow." ::= { flowData 2 } flowColumnActivityEntry OBJECT-TYPE SYNTAX FlowColumnActivityEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The Column Activity Entry for a particular attribute, activity time and flow." INDEX { flowColumnActivityAttribute, flowColumnActivityTime, flowColumnActivityIndex } ::= { flowColumnActivityTable 1 } FlowColumnActivityEntry ::= SEQUENCE { flowColumnActivityAttribute FlowAttributeNumber, flowColumnActivityTime TimeFilter, flowColumnActivityIndex Integer32, flowColumnActivityData OCTET STRING Brownlee Standards Track [Page 35] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 } flowColumnActivityAttribute OBJECT-TYPE SYNTAX FlowAttributeNumber MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Specifies the attribute for which values are required from active flows." ::= { flowColumnActivityEntry 1 } flowColumnActivityTime OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This variable is a copy of flowDataLastActiveTime in the flow data record identified by the flowColumnActivityIndex value of this flowColumnActivityTable entry." ::= { flowColumnActivityEntry 2 } flowColumnActivityIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Index of a flow table entry which was active at or after a specified flowColumnActivityTime." ::= { flowColumnActivityEntry 3 } flowColumnActivityData OBJECT-TYPE SYNTAX OCTET STRING (SIZE (3..1000)) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Collection of attribute data for flows active after flowColumnActivityTime. Within the OCTET STRING is a sequence of { flow index, attribute value } pairs, one for each active flow. The end of the sequence is marked by a flow index value of 0, indicating that there are no more rows in this column. The format of objects inside flowColumnFlowData is as follows. All numbers are unsigned. Numbers and strings appear with their high-order bytes leading. Numbers are fixed size, as specified by their SYNTAX in the flow table (above), i.e. one octet for flowAddressType and small constants, and four octets for Counter and TimeStamp. Strings are variable-length, with Brownlee Standards Track [Page 36] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 the length given in a single leading octet. The following is an attempt at an ASN.1 definition of flowColumnActivityData: flowColumnActivityData ::= SEQUENCE flowRowItemEntry flowRowItemEntry ::= SEQUENCE { flowRowNumber Integer32 (1..65535), -- 0 indicates the end of this column flowDataValue flowDataType -- Choice depends on attribute } flowDataType ::= CHOICE { flowByteValue Integer32 (1..255), flowShortValue Integer32 (1..65535), flowLongValue Integer32, flowStringValue OCTET STRING -- Length (n) in first byte, -- n+1 bytes total length, trailing zeroes truncated }" ::= { flowColumnActivityEntry 4 } -- -- The Data Package Table -- flowDataPackageTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowDataPackageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index into the Flow Table. Allows a meter reader to retrieve a sequence containing the values of a specified set of attributes for a flow which came from a specified RuleSet and which was last active at or after a given time." ::= { flowData 3 } flowDataPackageEntry OBJECT-TYPE SYNTAX FlowDataPackageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The data package containing selected variables from active rows in the flow table." INDEX { flowPackageSelector, flowPackageRuleSet, flowPackageTime, flowPackageIndex } ::= { flowDataPackageTable 1 } FlowDataPackageEntry ::= SEQUENCE { flowPackageSelector OCTET STRING, Brownlee Standards Track [Page 37] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 flowPackageRuleSet Integer32, flowPackageTime TimeFilter, flowPackageIndex Integer32, flowPackageData OCTET STRING } flowPackageSelector OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the attributes for which values are required from an active flow. These are encoded as a sequence of octets each containing a FlowAttribute number, preceded by an octet giving the length of the sequence (not including the length octet). For a flowPackageSelector to be valid, it must contain at least one attribute." ::= { flowDataPackageEntry 1 } flowPackageRuleSet OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the index (in the flowRuleSetInfoTable) of the rule set which produced the required flow." ::= { flowDataPackageEntry 2 } flowPackageTime OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable is a copy of flowDataLastActiveTime in the flow data record identified by the flowPackageIndex value of this flowPackageTable entry." ::= { flowDataPackageEntry 3 } flowPackageIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of a flow table entry which was active at or after a specified flowPackageTime." ::= { flowDataPackageEntry 4 } flowPackageData OBJECT-TYPE Brownlee Standards Track [Page 38] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "A collection of attribute values for a single flow, as specified by this row's indexes. The attribute values are contained within a BER-encoded sequence [ASN-1, ASN-BER], in the order they appear in their flowPackageSelector. For example, to retrieve a flowPackage containing values for attributes 11, 18 and 29, for a flow in RuleSet 7, with flow index 3447, one would GET the package whose Object Identifier (OID) is flowPackageData . 3.11.18.29 . 7. 0 . 3447 To get a package for the next such flow which had been active since time 12345 one would GETNEXT the package whose Object Identifier (OID) is flowPackageData . 3.11.18.29 . 7. 12345 . 3447" ::= { flowDataPackageEntry 5 } -- -- The Rule Table -- -- This is an array of RuleSets; the 'running' ones are indicated -- by the entries in the meter's flowManagerInfoTable. Several -- RuleSets can be held in a meter so that the manager can change the -- running RuleSets easily, for example with time of day. Note that -- a manager may not change the rules in any RuleSet currently -- referenced within the flowManagerInfoTable (either as 'current' or -- 'standby')! See the 'Traffic Flow Measurement: Architecture' -- document [RTFM-ARC] for details of rules and how they are used. -- Space for a RuleSet is allocated by setting the value of -- flowRuleInfoSize in the rule table's flowRuleSetInfoTable row. -- Values for each row in the RuleSet (Selector, Mask, MatchedValue, -- Action and Parameter) can then be set by the meter. -- Although an individual rule within a RuleSet could be modified, -- it is much safer to simply download a complete new RuleSet. flowRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF FlowRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains all the RuleSets which may be used by the meter." Brownlee Standards Track [Page 39] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 ::= { flowRules 1 } flowRuleEntry OBJECT-TYPE SYNTAX FlowRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The rule record itself." INDEX { flowRuleSet, flowRuleIndex } ::= { flowRuleTable 1 } FlowRuleEntry ::= SEQUENCE { flowRuleSet Integer32, flowRuleIndex Integer32, flowRuleSelector RuleAttributeNumber, flowRuleMask RuleAddress, flowRuleMatchedValue RuleAddress, flowRuleAction ActionNumber, flowRuleParameter Integer32 } flowRuleSet OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Selects a RuleSet from the array of RuleSets." ::= { flowRuleEntry 1 } flowRuleIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index into the Rule table. N.B: These values will normally be consecutive, given the fall-through semantics of processing the table." ::= { flowRuleEntry 2 } flowRuleSelector OBJECT-TYPE SYNTAX RuleAttributeNumber MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the attribute to be matched. null(0) is a special case; null rules always succeed. Brownlee Standards Track [Page 40] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 matchingStoD(50) is set by the meter's Packet Matching Engine. Its value is true(1) if the PME is attempting to match the packet with its addresses in Source-to-Destination order (i.e. as they appear in the packet), and false(2) otherwise. Details of how packets are matched are given in the 'Traffic Flow Measurement: Architecture' document [RTFM-ARC]. v1(51), v2(52), v3(53), v4(54) and v5(55) select meter variables, each of which can hold the name (i.e. selector value) of an address attribute. When one of these is used as a selector, its value specifies the attribute to be tested. Variable values are set by an Assign action." ::= { flowRuleEntry 3 } flowRuleMask OBJECT-TYPE SYNTAX RuleAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The initial mask used to compute the desired value. If the mask is zero the rule's test will always succeed." ::= { flowRuleEntry 4 } flowRuleMatchedValue OBJECT-TYPE SYNTAX RuleAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The resulting value to be matched for equality. Specifically, if the attribute chosen by the flowRuleSelector logically ANDed with the mask specified by the flowRuleMask equals the value specified in the flowRuleMatchedValue, then continue processing the table entry based on the action specified by the flowRuleAction entry. Otherwise, proceed to the next entry in the rule table." ::= { flowRuleEntry 5 } flowRuleAction OBJECT-TYPE SYNTAX ActionNumber MAX-ACCESS read-write STATUS current DESCRIPTION "The action to be taken if this rule's test succeeds, or if the meter's 'test' flag is off. Actions are opcodes for the meter's Packet Matching Engine; details are given in the 'Traffic Flow Measurement: Architecture' document [RTFM-ARC]." ::= { flowRuleEntry 6 } flowRuleParameter OBJECT-TYPE Brownlee Standards Track [Page 41] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "A parameter value providing extra information for this rule's action. Most of the actions use the parameter value to specify which rule to execute after this rule's test has failed; details are given in the 'Traffic Flow Measurement: Architecture' document [RTFM-ARC]." ::= { flowRuleEntry 7 } -- -- Traffic Flow Meter conformance statement -- flowMIBCompliances OBJECT IDENTIFIER ::= { flowMIBConformance 1 } flowMIBGroups OBJECT IDENTIFIER ::= { flowMIBConformance 2 } flowControlGroup OBJECT-GROUP OBJECTS { flowRuleInfoSize, flowRuleInfoOwner, flowRuleInfoTimeStamp, flowRuleInfoStatus, flowRuleInfoName, flowRuleInfoRulesReady, flowRuleInfoFlowRecords, flowInterfaceSampleRate, flowInterfaceLostPackets, flowReaderTimeout, flowReaderOwner, flowReaderLastTime, flowReaderPreviousTime, flowReaderStatus, flowReaderRuleSet, flowManagerCurrentRuleSet, flowManagerStandbyRuleSet, flowManagerHighWaterMark, flowManagerCounterWrap, flowManagerOwner, flowManagerTimeStamp, flowManagerStatus, flowManagerRunningStandby, flowFloodMark, flowInactivityTimeout, flowActiveFlows, flowMaxFlows, flowFloodMode } STATUS deprecated DESCRIPTION "The control group defines objects which are used to control an accounting meter." ::= {flowMIBGroups 1 } flowDataTableGroup OBJECT-GROUP Brownlee Standards Track [Page 42] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 OBJECTS { -- flowDataIndex, <- INDEX, not-accessible flowDataStatus, flowDataSourceInterface, flowDataSourceAdjacentType, flowDataSourceAdjacentAddress, flowDataSourceAdjacentMask, flowDataSourcePeerType, flowDataSourcePeerAddress, flowDataSourcePeerMask, flowDataSourceTransType, flowDataSourceTransAddress, flowDataSourceTransMask, flowDataDestInterface, flowDataDestAdjacentType, flowDataDestAdjacentAddress, flowDataDestAdjacentMask, flowDataDestPeerType, flowDataDestPeerAddress, flowDataDestPeerMask, flowDataDestTransType, flowDataDestTransAddress, flowDataDestTransMask, -- flowDataRuleSet, <- INDEX, not-accessible flowDataToOctets, flowDataToPDUs, flowDataFromOctets, flowDataFromPDUs, flowDataFirstTime, flowDataLastActiveTime, flowDataSourceClass, flowDataDestClass, flowDataClass, flowDataSourceKind, flowDataDestKind, flowDataKind } STATUS deprecated DESCRIPTION "The flow table group defines objects which provide the structure for the flow table, including the creation time and activity time indexes into it. In addition it defines objects which provide a base set of flow attributes for the adjacent, peer and transport layers, together with a flow's counters and times. Finally it defines a flow's class and kind attributes, which are set by rule actions." ::= {flowMIBGroups 2 } flowDataScaleGroup OBJECT-GROUP OBJECTS { flowManagerCounterWrap, flowDataPDUScale, flowDataOctetScale } STATUS deprecated DESCRIPTION "The flow scale group defines objects which specify scale factors for counters." ::= {flowMIBGroups 3 } flowDataSubscriberGroup OBJECT-GROUP OBJECTS { Brownlee Standards Track [Page 43] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 flowDataSourceSubscriberID, flowDataDestSubscriberID, flowDataSessionID } STATUS current DESCRIPTION "The flow subscriber group defines objects which may be used to identify the end point(s) of a flow." ::= {flowMIBGroups 4 } flowDataColumnTableGroup OBJECT-GROUP OBJECTS { flowColumnActivityAttribute, flowColumnActivityIndex, flowColumnActivityTime, flowColumnActivityData } STATUS deprecated DESCRIPTION "The flow column table group defines objects which can be used to collect part of a column of attribute values from the flow table." ::= {flowMIBGroups 5 } flowDataPackageGroup OBJECT-GROUP OBJECTS { flowPackageData } STATUS current DESCRIPTION "The data package group defines objects which can be used to collect a specified set of attribute values from a row of the flow table." ::= {flowMIBGroups 6 } flowRuleTableGroup OBJECT-GROUP OBJECTS { flowRuleSelector, flowRuleMask, flowRuleMatchedValue, flowRuleAction, flowRuleParameter } STATUS current DESCRIPTION "The rule table group defines objects which hold the set(s) of rules specifying which traffic flows are to be accounted for." ::= {flowMIBGroups 7 } flowDataScaleGroup2 OBJECT-GROUP Brownlee Standards Track [Page 44] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 OBJECTS { -- flowManagerCounterWrap, <- Deprecated flowDataPDUScale, flowDataOctetScale } STATUS current DESCRIPTION "The flow scale group defines objects which specify scale factors for counters. This group replaces the earlier version of flowDataScaleGroup above (now deprecated)." ::= {flowMIBGroups 8} flowControlGroup2 OBJECT-GROUP OBJECTS { flowRuleInfoSize, flowRuleInfoOwner, flowRuleInfoTimeStamp, flowRuleInfoStatus, flowRuleInfoName, -- flowRuleInfoRulesReady, <- Deprecated flowRuleInfoFlowRecords, flowInterfaceSampleRate, flowInterfaceLostPackets, flowReaderTimeout, flowReaderOwner, flowReaderLastTime, flowReaderPreviousTime, flowReaderStatus, flowReaderRuleSet, flowManagerCurrentRuleSet, flowManagerStandbyRuleSet, flowManagerHighWaterMark, -- flowManagerCounterWrap, <- Moved to DataScaleGroup flowManagerOwner, flowManagerTimeStamp, flowManagerStatus, flowManagerRunningStandby, flowFloodMark, flowInactivityTimeout, flowActiveFlows, flowMaxFlows, flowFloodMode } STATUS current DESCRIPTION "The control group defines objects which are used to control an accounting meter. It replaces the earlier version of flowControlGroup above (now deprecated)." ::= {flowMIBGroups 9 } flowMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for a Traffic Flow Meter." MODULE MANDATORY-GROUPS { flowControlGroup2, flowDataTableGroup, flowDataPackageGroup, flowRuleTableGroup Brownlee Standards Track [Page 45] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 } ::= { flowMIBCompliances 1 } END Brownlee Standards Track [Page 46] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 5 Security Considerations 5.1 SNMP Concerns There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information. These include all the objects in the Control Group (since they control access to meter resources by Managers and Meter Readers) and those in the Flow Table (since they hold the collected traffic flow data). It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [RFC2574] and the View-based Access Control Model [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 5.2 Traffic Meter Concerns This MIB describes how an RTFM traffic meter is controlled, and provides a way for traffic flow data to be retrieved from it by a meter reader. This is essentially an application using SNMP as a method of communication between co-operating hosts; it does not - in itself - have any inherent security risks. Brownlee Standards Track [Page 47] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 Since, however, the traffic flow data can be extremely valuable for network management purposes it is vital that sensible precautions be taken to keep the meter and its data secure. In particular, an attacker must not be permitted to write any of the meter's variables! This requires that access to the meter for control purposes (e.g. loading RuleSets and reading flow data) be restricted. Such restriction could be achieved in many ways, for example: - Physical Separation. Meter(s) and meter reader(s) could be deployed so that control capabilities are kept within a separate network, access to which is carefully controlled. - Application-layer Security. A minimal level of security for SNMP can be provided by using 'community' strings (which are essentially clear-text passwords) with SNMPv2C [RFC1157]. Where stronger security is needed, users should consider using the User-based Security Model [RFC2574] and the View-based Access Control Model [RFC2575]. - Lower-layer Security. Access to the meter can be protected using encryption at the network layer. For example, one could run SNMP to the meter through an encrypted TCP tunnel. When implementing a meter it may be sensible to use separate network interfaces for control and for metering. If this is done the control network can be set up so that it doesn't carry any 'user' traffic, and the metering interfaces can ignore any user attempts to take control of the meter. Users should also consider how they will address attempts to circumvent a meter, i.e. to prevent it from measuring flows. Such attempts are essentially denial-of-service attacks on the metering interfaces. For example - Port Scan attacks. The attacker sends packets to each of a very large number of IP (Address : Port) pairs. Each of these packets creates a new flow in the meter; if there are enough of them the meter will recognise a 'flood' condition, and will probably stop creating new flows. As a minimum, users (and implementors) should ensure that meters can recover from flood conditions as soon as possible after they occur. - Counter Wrap attacks: The attacker sends enough packets to cause the counters in a flow to wrap several times between meter readings, thus causing the counts to be artificially low. The change to using 64-bit counters in this MIB reduces this problem significantly. Brownlee Standards Track [Page 48] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 Users can reduce the severity of both the above attacks by ensuring that their meters are read often enough to prevent them being flooded. The resulting flow data will contain a record of the attacking packets, which may well be useful in determining where any attack came from. 6 IANA Considerations The RTFM Architecture document [RTFM-ARC], has two sets of assigned numbers: Opcodes for the PME (Pattern Matching Engine) and RTFM Attribute numbers. All the assigned numbers used in the Meter MIB appear in Textual Conventions. The numbers they use are derived as follows: The MIB's 'Type' textual conventions use names and numbers from the Assigned Numbers RFC [ASG-NBR]: MediumType Uses ifType Definitions PeerType Uses Address Family Numbers TransportType Uses Protocol Numbers The MIB's 'AttributeNumber' textual conventions use RTFM Attribute names and numbers from the RTFM Architecture document [RTFM-ARC], or other numbers allocated according to that document's IANA Considerations section: FlowAttributeNumber Have values stored in a flow table row RuleAttributeNumber May be tested in a rule The MIB's ActionNumber textual convention uses RTFM PME Opcode names and numbers from the RTFM Architecture document [RTFM-ARC], or other numbers allocated according to that document's IANA Considerations section. Brownlee Standards Track [Page 49] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 7 Appendix A: Changes Introduced Since RFC 2064 The first version of the Meter MIB was published as RFC 2064 in January 1997. The most significant changes since then are summarised below. - TEXTUAL CONVENTIONS: Greater use is made of textual conventions to describe the various types of addresses used by the meter. - PACKET MATCHING ATTRIBUTES: Computed attributes (e.g. FlowClass and FlowKind) may now be tested. This allows one to use these variables to store information during packet matching. A new attribute, MatchingStoD, has been added. Its value is 1 while a packet is being matched with its adresses in 'wire' (source-to-destination) order. - FLOOD MODE: This is now a read-write variable. Setting it to false(2) switches the meter out of flood mode and back to normal operation. - CONTROL TABLES: Several variables have been added to the RuleSet, Reader and Manager tables to provide more effective control of the meter's activities. - FLOW TABLE: 64-bit counters are used for octet and PDU counts. This reduces the problems caused by the wrap-around of 32-bit counters in earlier versions. flowDataRuleSet is now used as an index to the flow table. This allows a meter reader to collect only those flow table rows created by a specified RuleSet. - DATA PACKAGES: This is a new table, allowing a meter reader to retrieve values for a list of attributes from a flow as a single object (a BER-encoded sequence [ASN-1, ASN-BER]). It provides an efficient way to recover flow data, particularly when used with SNMP GetBulk requests. Earlier versions had a 'Column Activity Table'; using this it was difficult to collect all data for a flow efficiently in a single SNMP request. Brownlee Standards Track [Page 50] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 8 Acknowledgements An early draft of this document was produced under the auspices of the IETF's Accounting Working Group with assistance from the SNMP Working Group and the Security Area Advisory Group. Particular thanks are due to Jim Barnes, Sig Handelman and Stephen Stibler for their support and their assistance with checking early versions of the MIB. Stephen Stibler shared the development workload of producing the MIB changes summarized in chapter 5 (above). 9 Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10 References [ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting Background", RFC 1272, November 1991. [ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, ISI, October 1994. [ASN-1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. Brownlee Standards Track [Page 51] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 [ASN-BER] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [ENET-OBJ] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 1643, July 1994. [FDDI-MIB] Case, J. and A. Rijsinghani, "FDDI Management Information Base", RFC 1512, September 1993. [IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [MIB-II] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB- II", STD 17, RFC 1213, March 1991. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1905] 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] 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. Brownlee Standards Track [Page 52] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 [RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995. [RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. Brownlee Standards Track [Page 53] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 [RTFM-ARC] Brownlee, N., Mills, C. and Ruth, G., "Traffic Flow Measurement: Architecture", RFC 722, October 1999. [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [V6-ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. 11 Author's Address Nevil Brownlee Information Technology Systems & Services The University of Auckland Private Bag 92-019 Auckland, New Zealand Phone: +64 9 373 7599 x8941 EMail: n.brownlee@auckland.ac.nz Brownlee Standards Track [Page 54] RFC 2720 Traffic Flow Measurement: Meter MIB October 1999 12 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Brownlee Standards Track [Page 55] snmp-mibs-downloader-1.1/mibrfcs/rfc2742.txt0000644000000000000000000010744411402176071015572 0ustar Network Working Group L. Heintz Request For Comments: 2742 Cisco Systems Category: Standards Track S. Gudur Independent Consultant M. Ellison, Ed. Ellison Software Consulting, Inc. January 2000 Definitions of Managed Objects for Extensible SNMP Agents 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions. Table of Contents 1. The SNMP Management Framework ............................... 2 2. Introduction ................................................ 3 3. AgentX MIB Overview ......................................... 3 4. Managed Object Definitions for AgentX ....................... 4 5. Intellectual Property ....................................... 15 6. Acknowledgements ............................................ 16 7. Security Considerations ..................................... 16 8. References .................................................. 17 9. Authors' and Editor's Addresses ............................. 19 10. Full Copyright Statement ................................... 20 Heintz, et al. Standards Track [Page 1] RFC 2742 Agent X MIB January 2000 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2571 [1]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. - A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in Heintz, et al. Standards Track [Page 2] RFC 2742 Agent X MIB January 2000 SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "master agent" and multiple "subagents". See [17] for details about the AgentX protocol. The goals of the AgentX MIB are: - List the set of subagent connections that currently have logical sessions open with the master agent. - Identify each subagent connection transport address and type. - Identify each subagent session vendor, AgentX protocol version, and other characteristics. - Identify the set of MIB objects each session implements, the context in which the objects are registered, and the priority of the registration. - Determine protocol operational parameters such as the timeout interval for responses from a session and the priority at which a session registers a particular MIB region. - Allow (but do not require) managers to explicitly close subagent sessions with the master agent. 3. AgentX MIB Overview This MIB is organized into four groups. The agentxGeneral group provides information describing the master agent's AgentX support, including the protocol version supported. The agentxConnection group provides information describing the current set of connections capable of carrying AgentX sessions. The agentxSession group provides information describing the current set of AgentX sessions. The agentxRegistration group provides information describing the current set of registrations. Three tables form the heart of this mib. These are the connection, session, and registration tables. Heintz, et al. Standards Track [Page 3] RFC 2742 Agent X MIB January 2000 Entries in the registration table exist in a many-to-one relationship with entries in the session table. This relationship is expressed through the two common indices, agentxSessionIndex and agentxConnIndex. Entries in the registration table also exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. Entries in the session table exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. 4. Managed Object Definitions for AgentX AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp, TruthValue, TDomain FROM SNMPv2-TC; agentxMIB MODULE-IDENTITY LAST-UPDATED "200001100000Z" -- Midnight 10 January 2000 ORGANIZATION "AgentX Working Group" CONTACT-INFO "WG-email: agentx@dorothy.bmc.com Subscribe: agentx-request@dorothy.bmc.com WG-email Archive: ftp://ftp.peer.com/pub/agentx/archives FTP repository: ftp://ftp.peer.com/pub/agentx http://www.ietf.org/html.charters/agentx-charter.html Chair: Bob Natale ACE*COMM Corporation Email: bnatale@acecomm.com WG editor: Mark Ellison Ellison Software Consulting, Inc. Email: ellison@world.std.com Co-author: Lauren Heintz Cisco Systems, EMail: lheintz@cisco.com Co-author: Smitha Gudur Independent Consultant Email: sgudur@hotmail.com Heintz, et al. Standards Track [Page 4] RFC 2742 Agent X MIB January 2000 " DESCRIPTION "This is the MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent. " REVISION "200001100000Z" -- Midnight 10 January 2000 DESCRIPTION "Initial version published as RFC 2742." ::= { mib-2 74 } -- Textual Conventions AgentxTAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. This is identical to the TAddress textual convention (SNMPv2-SMI) except that zero-length values are permitted. " SYNTAX OCTET STRING (SIZE (0..255)) -- Administrative assignments agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxConnection OBJECT IDENTIFIER ::= { agentxObjects 2 } agentxSession OBJECT IDENTIFIER ::= { agentxObjects 3 } agentxRegistration OBJECT IDENTIFIER ::= { agentxObjects 4 } agentxDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The default length of time, in seconds, that the master agent should allow to elapse after dispatching a message to a session before it regards the subagent as not responding. This is a system-wide value that may override the timeout value associated with a particular session (agentxSessionTimeout) or a particular registered MIB region (agentxRegTimeout). If the associated value of agentxSessionTimeout and agentxRegTimeout are zero, or impractical in accordance with implementation-specific procedure of the master agent, the value represented by this object will be the effective timeout value for the Heintz, et al. Standards Track [Page 5] RFC 2742 Agent X MIB January 2000 master agent to await a response to a dispatch from a given subagent. " DEFVAL { 5 } ::= { agentxGeneral 1 } agentxMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. The current protocol version is 1. Note that the master agent must also allow interaction with earlier version subagents. " ::= { agentxGeneral 2 } -- The AgentX Subagent Connection Group agentxConnTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxConnectionTable. " ::= { agentxConnection 1 } agentxConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The agentxConnectionTable tracks all current AgentX transport connections. There may be zero, one, or more AgentX sessions carried on a given AgentX connection. " ::= { agentxConnection 2 } agentxConnectionEntry OBJECT-TYPE SYNTAX AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An agentxConnectionEntry contains information describing a single AgentX transport connection. A connection may be Heintz, et al. Standards Track [Page 6] RFC 2742 Agent X MIB January 2000 used to support zero or more AgentX sessions. An entry is created when a new transport connection is established, and is destroyed when the transport connection is terminated. " INDEX { agentxConnIndex } ::= { agentxConnectionTable 1 } AgentxConnectionEntry ::= SEQUENCE { agentxConnIndex Unsigned32, agentxConnOpenTime TimeStamp, agentxConnTransportDomain TDomain, agentxConnTransportAddress AgentxTAddress } agentxConnIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxConnIndex contains the value that uniquely identifies an open transport connection used by this master agent to provide AgentX service. Values of this index should not be re-used. The value assigned to a given transport connection is constant for the lifetime of that connection. " ::= { agentxConnectionEntry 1 } agentxConnOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this connection was established and, therefore, its value when this entry was added to the table. " ::= { agentxConnectionEntry 2 } agentxConnTransportDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol in use for this connection to the subagent. " ::= { agentxConnectionEntry 3 } agentxConnTransportAddress OBJECT-TYPE SYNTAX AgentxTAddress Heintz, et al. Standards Track [Page 7] RFC 2742 Agent X MIB January 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent. This object may be zero-length for unix-domain sockets (and possibly other types of transport addresses) since the subagent need not bind a filename to its local socket. " ::= { agentxConnectionEntry 4 } -- The AgentX Subagent Session Group agentxSessionTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxSessionTable. " ::= { agentxSession 1 } agentxSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagent sessions currently in effect. " ::= { agentxSession 2 } agentxSessionEntry OBJECT-TYPE SYNTAX AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open session between the AgentX master agent and a subagent is contained in this entry. An entry is created when a new session is successfully established and is destroyed either when the subagent transport connection has terminated or when the subagent session is closed. " INDEX { agentxConnIndex, agentxSessionIndex } ::= { agentxSessionTable 1 } AgentxSessionEntry ::= SEQUENCE { agentxSessionIndex Unsigned32, Heintz, et al. Standards Track [Page 8] RFC 2742 Agent X MIB January 2000 agentxSessionObjectID OBJECT IDENTIFIER, agentxSessionDescr SnmpAdminString, agentxSessionAdminStatus INTEGER, agentxSessionOpenTime TimeStamp, agentxSessionAgentXVer INTEGER, agentxSessionTimeout INTEGER } agentxSessionIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the subagent session. It is the same as h.sessionID defined in the agentx header. Note that if a subagent's session with the master agent is closed for any reason its index should not be re-used. A value of zero(0) is specifically allowed in order to be compatible with the definition of h.sessionId. " ::= { agentxSessionEntry 1 } agentxSessionObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is taken from the o.id field of the agentx-Open-PDU. This attribute will report a value of '0.0' for subagents not supporting the notion of an AgentX session object identifier. " ::= { agentxSessionEntry 2 } agentxSessionDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the session. This is analogous to sysDescr defined in the SNMPv2-MIB in RFC 1907 [19] and is taken from the o.descr field of the agentx-Open-PDU. This attribute will report a zero-length string value for subagents not supporting the notion of a session description. " ::= { agentxSessionEntry 3 } agentxSessionAdminStatus OBJECT-TYPE Heintz, et al. Standards Track [Page 9] RFC 2742 Agent X MIB January 2000 SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the session. Setting the value to 'down(2)' closes the subagent session (with c.reason set to 'reasonByManager'). " ::= { agentxSessionEntry 4 } agentxSessionOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this session was opened and, therefore, its value when this entry was added to the table. " ::= { agentxSessionEntry 5 } agentxSessionAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the session. This must be less than or equal to the value of agentxMasterAgentXVer. " ::= { agentxSessionEntry 6 } agentxSessionTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to this session before it regards the subagent as not responding. This value is taken from the o.timeout field of the agentx-Open-PDU. This is a session-specific value that may be overridden by values associated with the specific registered MIB regions (see agentxRegTimeout). A value of zero(0) indicates that the master agent's default timeout value should be used Heintz, et al. Standards Track [Page 10] RFC 2742 Agent X MIB January 2000 (see agentxDefaultTimeout). " ::= { agentxSessionEntry 7 } -- The AgentX Registration Group agentxRegistrationTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxRegistrationTable. " ::= { agentxRegistration 1 } agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered regions. " ::= { agentxRegistration 2 } agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains information for a single registered region. An entry is created when a session successfully registers a region and is destroyed for any of three reasons: this region is unregistered by the session, the session is closed, or the subagent connection is closed. " INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } ::= { agentxRegistrationTable 1 } AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex Unsigned32, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegRangeSubId Unsigned32, agentxRegUpperBound Unsigned32, agentxRegPriority Unsigned32, agentxRegTimeout INTEGER, agentxRegInstance TruthValue } Heintz, et al. Standards Track [Page 11] RFC 2742 Agent X MIB January 2000 agentxRegIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxRegIndex uniquely identifies a registration entry. This value is constant for the lifetime of an entry. " ::= { agentxRegistrationEntry 1 } agentxRegContext OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the session supports the objects in this region. A zero-length context indicates the default context. " ::= { agentxRegistrationEntry 2 } agentxRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The session identified by agentxSessionIndex implements objects starting at this value (inclusive). Note that this value could identify an object type, an object instance, or a partial object instance. " ::= { agentxRegistrationEntry 3 } agentxRegRangeSubId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegRangeSubId is used to specify the range. This is taken from r.region_subid in the registration PDU. If the value of this object is zero, no range is specified. If it is non-zero, it identifies the `nth' sub-identifier in r.region for which this entry's agentxRegUpperBound value is substituted in the OID for purposes of defining the region's upper bound. " ::= { agentxRegistrationEntry 4 } agentxRegUpperBound OBJECT-TYPE Heintz, et al. Standards Track [Page 12] RFC 2742 Agent X MIB January 2000 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegUpperBound represents the upper-bound sub-identifier in a registration. This is taken from the r.upper_bound in the registration PDU. If agentxRegRangeSubid (r.region_subid) is zero, this value is also zero and is not used to define an upper bound for this registration. " ::= { agentxRegistrationEntry 5 } agentxRegPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The registration priority. Lower values have higher priority. This value is taken from r.priority in the register PDU. Sessions should use the value of 127 for r.priority if a default value is desired. " ::= { agentxRegistrationEntry 6 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The timeout value, in seconds, for responses to requests associated with this registered MIB region. A value of zero(0) indicates the default value (indicated by by agentxSessionTimeout or agentxDefaultTimeout) is to be used. This value is taken from the r.timeout field of the agentx-Register-PDU. " ::= { agentxRegistrationEntry 7 } agentxRegInstance OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxRegInstance is `true' for registrations for which the INSTANCE_REGISTRATION was set, and is `false' for all other registrations. " Heintz, et al. Standards Track [Page 13] RFC 2742 Agent X MIB January 2000 ::= { agentxRegistrationEntry 8 } -- Conformance Statements for AgentX agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } -- Compliance Statements for AgentX agentxMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only. " MODULE -- this module MANDATORY-GROUPS { agentxMIBGroup } OBJECT agentxSessionAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxConnTableLastChange, agentxConnOpenTime, agentxConnTransportDomain, agentxConnTransportAddress, agentxSessionTableLastChange, agentxSessionTimeout, agentxSessionObjectID, agentxSessionDescr, agentxSessionAdminStatus, agentxSessionOpenTime, agentxSessionAgentXVer, agentxRegistrationTableLastChange, agentxRegContext, agentxRegStart, agentxRegRangeSubId, agentxRegUpperBound, agentxRegPriority, Heintz, et al. Standards Track [Page 14] RFC 2742 Agent X MIB January 2000 agentxRegTimeout, agentxRegInstance } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB. " ::= { agentxMIBGroups 1 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Heintz, et al. Standards Track [Page 15] RFC 2742 Agent X MIB January 2000 6. Acknowledgements This document is the result of the efforts of the IETF AgentX Working Group (WG). This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [18]. Thanks are in order to the following AgentX WG members: Mike Daniele (Compaq Computer Corporation) Dale Francisco (Cisco Systems) Bob Natale (ACE*COMM Corporation) Randy Presuhn (BMC Software, Inc.) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Special acknowledgement is made to: Maria Greene (Xedia) Special acknowledgement is also made to the following individuals for participating in the 1998 AgentX testing summit (bakeoff) held in Sunnyvale, California: Jeff Case (SNMP Research, Inc.) Mike Daniele (Compaq Computer Corporation) Mark Ellison (Ellison Software Consulting, Inc.) Lauren Heintz (BMC Software, Inc.) Verne Hyde (Independent Consultant) Bob Natale (ACE*COMM Corporation) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T. J. Watson Research Center) 7. Security Considerations There is a single management object defined in this MIB that has a MAX-ACCESS clause of read-write. This object may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Heintz, et al. Standards Track [Page 16] RFC 2742 Agent X MIB January 2000 There is a single managed object in this MIB that may contain sensitive information. This object is agentxSessionAdminStatus. Setting agentxSessionAdminStatus to an inappropriate value can effectively prevent access to management information, or provide access to inappropriate information. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/delete) them. 8. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Heintz, et al. Standards Track [Page 17] RFC 2742 Agent X MIB January 2000 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [17] Daniele, M., Wijnen, B., Ellison, M. and D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1", RFC 2741, January 2000. [18] Rose, M., "SNMP MUX Protocol and MIB", RFC 1227, May 1991. Heintz, et al. Standards Track [Page 18] RFC 2742 Agent X MIB January 2000 [19] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. 9. Authors' and Editor's Addresses Lauren Heintz Cisco Systems 1450 North McDowell Blvd. Petaluma, CA 94954-6515 USA Phone: +1 707-793-1714 EMail: lheintz@cisco.com Smitha Gudur Independent Consultant EMail: sgudur@hotmail.com Mark Ellison (WG editor) Ellison Software Consulting, Inc. 38 Salem Road Atkinso, NH 03811 USA Phone: +1 603-362-9270 Email: ellison@world.std.com Heintz, et al. Standards Track [Page 19] RFC 2742 Agent X MIB January 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Heintz, et al. Standards Track [Page 20] snmp-mibs-downloader-1.1/mibrfcs/rfc2758.txt0000644000000000000000000043425511402176071015604 0ustar Network Working Group K. White Request for Comments: 2758 IBM Corp. Category: Experimental February 2000 Definitions of Managed Objects for Service Level Agreements Performance Monitoring Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data. Table of Contents 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . 2 3.0 Structure of the MIB . . . . . . . . . . . . . . . . . . . 3 3.1 Scalar objects . . . . . . . . . . . . . . . . . . . . . . 4 3.2 slapmPolicyNameTable . . . . . . . . . . . . . . . . . . . 5 3.3 slapmPolicyRuleStatsTable . . . . . . . . . . . . . . . . 6 3.4 slapmPRMonTable . . . . . . . . . . . . . . . . . . . . . 6 3.5 slapmSubcomponentTable . . . . . . . . . . . . . . . . . . 8 4.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 5.0 Security Considerations . . . . . . . . . . . . . . . . . 67 6.0 Intellectual Property . . . . . . . . . . . . . . . . . . 67 7.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 68 8.0 References . . . . . . . . . . . . . . . . . . . . . . . . 68 9.0 Author's Address . . . . . . . . . . . . . . . . . . . . . 70 10.0 Full Copyright Statement . . . . . . . . . . . . . . . . 71 White Experimental [Page 1] RFC 2758 SLAPM-MIB February 2000 1.0 Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [13]. This document's purpose is to define a MIB module for performance management of Service Level Agreements (SLAs). It is assumed that an SLA is defined via policy schema definitions. The policy definitions being modeled with respect to performance management is primarily related to network Quality of Service (QOS). There are a number of methods that exist for defining and administering policy. Definition of these methods is considered out side of the scope of this document. The MIB module defined within this memo has been modeled using the various versions of the schema definitions being developed within the Policy Framework Working Group in the IETF. The content of the MIB defined within this memo has evolved along with the Policy Framework Working Group schema definitions. 2.0 The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [7]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [14], STD 16, RFC 1212 [15] and RFC 1215 [16]. The second version, called SMIv2, is described in STD 58, RFC 2578 [3], STD 58, RFC 2579 [4] and STD 58, RFC 2580 [5]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [1]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [17] and RFC 1906 [18]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [18], RFC 2572 [8] and RFC 2574 [10]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [1]. A second set of protocol White Experimental [Page 2] RFC 2758 SLAPM-MIB February 2000 operations and associated PDU formats is described in RFC 1905 [6]. o A set of fundamental applications described in RFC 2573 [9] and the view-based access control mechanism described in RFC 2575 [11]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3.0 Structure of the MIB The SLAPM-MIB consists of the following components: o scalar objects o slapmPolicyNameTable o slapmPolicyRuleStatsTable (equivalent to the deprecated slapmPolicyStatsTable) o slapmPRMonTable (equivalent to the deprecated slapmPolicyMonitorTable) o slapmSubcomponentTable Refer to the compliance statement defined within SLAPM-MIB for a definition of what objects and notifications MUST be implemented by all systems as opposed to those that MUST be implemented by end systems only. Initially most of the tables defined by the MIB module within this document where directly indexed using a policy's name and a subordinate traffic profile name. Over time the structure and resulting naming has grown more complex and as such has exceeded the capacity of being used as a direct MIB table index. As a result of this the original tables (slapmPolicyStatsTable and White Experimental [Page 3] RFC 2758 SLAPM-MIB February 2000 slapmPolicyMonitorTable) have been deprecated and replaced with new tables that use an Unsigned32 index element instead of "names". A new table has been defined, slapmPolicyNameTable, that maps the Unsigned32 index to a unique name associated with a given policy rule definition. 3.1 Scalar objects Global objects defined within SLAPM-MIB: o slapmSpinLock Enables multiple management application access to SLAPM-MIB. An agent MUST implement the slapmSpinLock object to enable management applications to coordinate their use of the SLAPM-MIB. Management application use of slapmSpinLock is OPTIONAL. o slapmPolicyCountQueries, slapmPolicyCountAccesses, slapmPolicyCountSuccessAccesses, and slapmPolicyCountNotFounds Basic statistics on the amount of policy directory access that has occurred at a system. o slapmPolicyPurgeTime Used to prevent the entries in various SLAPM-MIB tables that relate to a policy definition from immediately being deleted when the corresponding policy definition no longer exists. This gives management applications time to discover this condition and close out any polled based interval data that may be being collected. All dependent slapmPRMonTable entries are also deleted when its parent slapmPolicyRuleStatsEntry is removed. Refer to the OBJECT description for slapmPolicyPurgeTime for a more precise description of this function. o slapmPolicyTrapEnable This object enables or suppresses generation of slapmPolicyRuleDeleted or slapmPolicyRuleMonDeleted notifications. o slapmPolicyTrapFilter This object enables suppression of slapmSubcMonitorNotOkay notifications. White Experimental [Page 4] RFC 2758 SLAPM-MIB February 2000 3.2 slapmPolicyNameTable The slapmPolicyNameTable maps a Unsigned32 index to a unique name associated with a given policy rule definition. Currently, the core schema definition being worked on within the Policy Framework working group defines five general classes: policyGroup, policyRule, policyCondition, policyTimePeriodCondition, and policyAction. "Policies can either be used in a stand-alone fashion or aggregated into policy groups to perform more elaborate functions. Stand-alone policies are called policy rules. Policy groups are aggregations of policy rules, or aggregations of policy groups, but not both." Each policy rule consists of a set of conditions and a set of actions. Policy rules may be aggregated into policy groups. "Instances in a directory are identified by distinguished names (DNs), which provide the same type of hierarchical organization that a file system provides in a computer system. A distinguished name is a sequence of relative distinguished names (RDNs), where an RDN provides a unique identifier for an instance within the context of its immediate superior, in the same way that a filename provides a unique identifier for a file within the context of the folder in which it resides." Each of these instances can also be named to fit in with the existing DEN practice with a commonName (cn) attribute as oppose to the classes name attribute. "The cn, or commonName, attribute is an X.500 attribute. It stands for commonName. It specifies a user-friendly name by which the object is commonly known. This name may be ambiguous by itself. This name is used in a limited scope (such as an organization). It conforms to the naming conventions of the country or culture with which it is associated. CN is used universally in DEN as the naming attribute for a class." An slapmPolicyNameEntry contains a single object, slapmPolicyNameOfRule, that contains the unique name associated with a policy rule instance. An slapmPolicyNameEntry is indexed by a Unsigned32 index, slapmPolicyNameIndex, that is assigned by the implementation of this MIB. White Experimental [Page 5] RFC 2758 SLAPM-MIB February 2000 3.3 slapmPolicyRuleStatsTable This table is functionally equivalent to the deprecated slapmPolicyStatsTable. The slapmPolicyStatsTable uses the name of both a policy definition and a traffic profile name to index an entry. The slapmPolicyRuleStatsTable uses an slapmPolicyNameEntry index (Unsigned32) instead. The slapmPolicyRuleStatsTable is the main table defined by SLAPM-MIB. The primary index for this table is slapmPolicyNameSystemAddress that enables support of multiple systems from a single policy agent. The index element, slapmPolicyNameSystemAddress, value must be either the zero-length octet string when at a policy agent only a single system is being support, 4 octets for a ipv4 address, or 16 octets for a ipv6 address. It is possible that on a single system multiple policy agent instances exists. The Entity MIB, refer to [19], should be used to handle the resulting MIBs. With respect to slapmPolicyNameSystemAddress one slapmPolicyRuleStatsEntry exists for each policy rule instance. Entries in this table are not administered via SNMP. An agent implementation for this table MUST reflect its current set of policy rule instances via table entries. The mechanisms for policy administration are outside of the scope of this memo. 3.4 slapmPRMonTable This table is functionally equivalent to the deprecated slapmPolicyMonitorTable. The slapmPolicyMonitorTable uses the name of both a policy definition and a traffic profile name to index an entry. The slapmPRMonTable uses an slapmPolicyNameEntry index (Unsigned32) instead. The slapmPRMonTable provides a method of monitoring the effect of SLA policy being used at a system. A management application creates an slapmPRMonEntry for each collection that it requires. The value of the BITS slapmPRMonControl object determines what type of monitoring occurs, at what level to monitor and whether trap support is enabled: o monitorMinRate(0) Use the value of slapmPRMonInterval as the interval to determine current traffic in and out rates, using slapmPRMonCurrentInRate and slapmPRMonCurrentOutRate, that can be compared to slapmPRMonMinRateLow for determining when to generate a slapmPolicyRuleMonNotOkay notification. The notification White Experimental [Page 6] RFC 2758 SLAPM-MIB February 2000 slapmPolicyRuleMonOkay is generated when the problem is resolved. This can be determined by comparing the current rates to slapmPRMonMinRateHigh. o monitorMaxRate(1) Use the value of slapmPRMonInterval as the interval to determine current traffic in and out rate, using slapmPRMonCurrentInRate and slapmPRMonCurrentOutRate, that can be compared to slapmPRMonMaxRateHigh for determining when to generate a slapmPolicyRuleMonNotOkay notification. The notification slapmPolicyRuleMonOkay is generated when the problem is resolved. This can be determined by comparing the current rates to slapmPRMonMaxRateLow. o monitorMaxDelay(2) Use the value of slapmPRMonInterval as the interval to determine the current delay. This can be calculated on an aggregate level by averaging the round trip times for all TCP connections associated with the policy definition. For an individual subcomponent its round trip time can be used directly. Compare this value to slapmPRMonMaxDelayHigh for determining when to generate a slapmPolicyRuleMonNotOkay notification. The notification slapmPolicyRuleMonOkay is generated when the problem is resolved. This can be determined by comparing the current rates to slapmPRMonMaxDelayLow. UDP subcomponents don't support max delay monitoring. o enableAggregateTraps(3) The slapmPRMonitorControl BITS setting, enableAggregateTraps(3), MUST be set in order for any notifications relating to slapmPolicyRuleStatsTable monitoring to be generated. o enableSubcomponentTraps(4) This slapmPRMonControl BITS setting MUST be set in order for any notifications relating to slapmSubcomponetTable monitoring to be generated. The slapmPRMonControl BITS setting monitorSubcomponents(5) MUST be selected in order for this setting to be allowed. o monitorSubcomponents(5) If selected monitor slapmSubcomponentTable entries individually. Note: aggregate policy rule monitoring is always enabled. White Experimental [Page 7] RFC 2758 SLAPM-MIB February 2000 The index element slapmPRMonOwnerIndex is used as the first index in slapmPRMonTable in order to enable SNMP VACM security control. The slapmPRMonTable is the only table that supports SNMP RowStatus operations. 3.5 slapmSubcomponentTable Entries are made into this table for the protocol entities (policy traffic profile subcomponents) to indicate actual policy rule usage, provide general statistics at either a TCP connection or UDP listener level, and enable subcomponent monitoring. 4.0 Definitions SLAPM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, NOTIFICATION-TYPE, Gauge32, Counter32, Unsigned32 FROM SNMPv2-SMI -- RFC2578 TEXTUAL-CONVENTION, RowStatus, TestAndIncr, DateAndTime FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- RFC2571 slapmMIB MODULE-IDENTITY LAST-UPDATED "200001240000Z" -- 24 January 2000 ORGANIZATION "International Business Machines Corp." CONTACT-INFO "Kenneth White International Business Machines Corporation Network Computing Software Division Research Triangle Park, NC, USA E-mail: wkenneth@us.ibm.com" DESCRIPTION "The Service Level Agreement Performance Monitoring MIB (SLAPM-MIB) provides data collection and monitoring capabilities for Service Level Agreements (SLAs) policy definitions." -- Revision history White Experimental [Page 8] RFC 2758 SLAPM-MIB February 2000 REVISION "200001240000Z" -- 24 January 2000 DESCRIPTION "This version published as RFC 2758." ::= { experimental 88 } -- Textual Conventions SlapmNameType ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "The textual convention for naming entities within this MIB. The actual contents of an object defined using this textual convention should consist of the distinguished name portion of an name. This is usually the right-most portion of the name. This convention is necessary, since names within this MIB can be used as index items and an instance identifier is limited to 128 subidentifiers. This textual convention has been deprecated. All of the tables defined within this MIB that use this textual convention have been deprecated as well since the method of using a portion of the name (either of a policy definition or of a traffic profile) has been replaced by using an Unsigned32 index. The new slapmPolicyNameTable would then map the Unsigned32 index to a real name." SYNTAX SnmpAdminString (SIZE(0..32)) SlapmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The textual convention for defining the various slapmPRMonTable (or old slapmPolicyMonitorTable) and the slapmSubcomponentTable states for actual policy rule traffic monitoring." SYNTAX BITS { slaMinInRateNotAchieved(0), slaMaxInRateExceeded(1), slaMaxDelayExceeded(2), slaMinOutRateNotAchieved(3), slaMaxOutRateExceeded(4), monitorMinInRateNotAchieved(5), monitorMaxInRateExceeded(6), monitorMaxDelayExceeded(7), monitorMinOutRateNotAchieved(8), monitorMaxOutRateExceeded(9) White Experimental [Page 9] RFC 2758 SLAPM-MIB February 2000 } SlapmPolicyRuleName ::= TEXTUAL-CONVENTION DISPLAY-HINT "1024t" STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding." SYNTAX OCTET STRING (SIZE (0..1024)) -- Top-level structure of the MIB slapmNotifications OBJECT IDENTIFIER ::= { slapmMIB 0 } slapmObjects OBJECT IDENTIFIER ::= { slapmMIB 1 } slapmConformance OBJECT IDENTIFIER ::= { slapmMIB 2 } -- All scalar objects slapmBaseObjects OBJECT IDENTIFIER ::= { slapmObjects 1 } -- Scalar Object Definitions slapmSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating applications to coordinate their use of the contents of this MIB. This typically occurs when an application seeks to create an new entry or alter an existing entry in slapmPRMonTable (or old slapmPolicyMonitorTable). A management implementation MAY utilize the slapmSpinLock to serialize its changes or additions. This usage is not required. However, slapmSpinLock MUST be supported by agent implementations." ::= { slapmBaseObjects 1 } slapmPolicyCountQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION White Experimental [Page 10] RFC 2758 SLAPM-MIB February 2000 "The total number of times that a policy lookup occurred with respect to a policy agent. This is the number of times that a reference was made to a policy definition at a system and includes the number of times that a policy repository was accessed, slapmPolicyCountAccesses. The object slapmPolicyCountAccesses should be less than slapmPolicyCountQueries when policy definitions are cached at a system." ::= { slapmBaseObjects 2 } slapmPolicyCountAccesses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of times that a policy repository was accessed with respect to a policy agent. The value of this object should be less than slapmPolicyCountQueries, since typically policy entries are cached to minimize repository accesses." ::= { slapmBaseObjects 3 } slapmPolicyCountSuccessAccesses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of successful policy repository accesses with respect to a policy agent." ::= { slapmBaseObjects 4 } slapmPolicyCountNotFounds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of policy repository accesses, with respect to a policy agent, that resulted in an entry not being located." ::= { slapmBaseObjects 5 } slapmPolicyPurgeTime OBJECT-TYPE SYNTAX Integer32 (0..3600) -- maximum of 1 hour UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION White Experimental [Page 11] RFC 2758 SLAPM-MIB February 2000 "The purpose of this object is to define the amount of time (in seconds) to wait before removing an slapmPolicyRuleStatsEntry (or old slapmPolicyStatsEntry) when a system detects that the associated policy definition has been deleted. This gives any polling management applications time to complete their last poll before an entry is removed. An slapmPolicyRuleStatsEntry (or old slapmPolicyStatsEntry) enters the deleteNeeded(3) state via slapmPolicyRuleStatsOperStatus (or old slapmPolicyStatsOperStatus) when a system first detects that the entry needs to be removed. Once slapmPolicyPurgeTime has expired for an entry in deleteNeeded(3) state it is removed a long with any dependent slapmPRMonTable (or slapmPolicyMonitorTable) entries. A value of 0 for this option disables this function and results in the automatic purging of slapmPRMonTable (or slapmPolicyTable) entries upon transition into deleteNeeded(3) state. A slapmPolicyRuleDeleted (or slapmPolicyProfileDeleted) notification is sent when an slapmPolicyRuleStatsEntry (or slapmPolicyStatsEntry) is removed. Dependent slapmPRMonTable (or slapmPolicyMonitorTable) deletion results in a slapmPolicyRuleMonDeleted (or slapmPolicyMonitorDeleted) notification being sent. These notifications are suppressed if the value of slapmPolicyTrapEnable is disabled(2)." DEFVAL { 900 } -- 15 minute default purge time ::= { slapmBaseObjects 6 } slapmPolicyTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether slapmPolicyRuleDeleted and slapmPolicyRuleMonDeleted (or slapmPolicyProfileDeleted and slapmPolicyMonitorDeleted) notifications should be generated by this system." DEFVAL { disabled } ::= { slapmBaseObjects 7 } slapmPolicyTrapFilter OBJECT-TYPE SYNTAX Integer32 (0..64) UNITS "intervals" White Experimental [Page 12] RFC 2758 SLAPM-MIB February 2000 MAX-ACCESS read-write STATUS current DESCRIPTION "The purpose of this object is to suppress unnecessary slapmSubcMonitorNotOkay (or slapmSubcomponentMonitoredEventNotAchieved), for example, notifications. Basically, a monitored event has to not meet its SLA requirement for the number of consecutive intervals indicated by the value of this object." DEFVAL { 3 } ::= { slapmBaseObjects 8 } slapmTableObjects OBJECT IDENTIFIER ::= { slapmObjects 2 } -- Sla Performance Monitoring Policy Statistics Table slapmPolicyStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SlapmPolicyStatsEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Provides statistics on all policies known at a system. This table has been deprecated and replaced with the slapmPolicyRuleStatsTable. Older implementations of this MIB are expected to continue their support of this table." ::= { slapmTableObjects 1 } slapmPolicyStatsEntry OBJECT-TYPE SYNTAX SlapmPolicyStatsEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Defines an entry in the slapmPolicyStatsTable. This table defines a set of statistics that is kept on a per system, policy and traffic profile basis. A policy can be defined to contain multiple traffic profiles that map to a single action. Entries in this table are not created or deleted via SNMP but reflect the set of policy definitions known at a system." INDEX { slapmPolicyStatsSystemAddress, slapmPolicyStatsPolicyName, slapmPolicyStatsTrafficProfileName White Experimental [Page 13] RFC 2758 SLAPM-MIB February 2000 } ::= { slapmPolicyStatsTable 1 } SlapmPolicyStatsEntry ::= SEQUENCE { slapmPolicyStatsSystemAddress OCTET STRING, slapmPolicyStatsPolicyName SlapmNameType, slapmPolicyStatsTrafficProfileName SlapmNameType, slapmPolicyStatsOperStatus INTEGER, slapmPolicyStatsActiveConns Gauge32, slapmPolicyStatsTotalConns Counter32, slapmPolicyStatsFirstActivated DateAndTime, slapmPolicyStatsLastMapping DateAndTime, slapmPolicyStatsInOctets Counter32, slapmPolicyStatsOutOctets Counter32, slapmPolicyStatsConnectionLimit Integer32, slapmPolicyStatsCountAccepts Counter32, slapmPolicyStatsCountDenies Counter32, slapmPolicyStatsInDiscards Counter32, slapmPolicyStatsOutDiscards Counter32, slapmPolicyStatsInPackets Counter32, slapmPolicyStatsOutPackets Counter32, slapmPolicyStatsInProfileOctets Counter32, slapmPolicyStatsOutProfileOctets Counter32, slapmPolicyStatsMinRate Integer32, slapmPolicyStatsMaxRate Integer32, slapmPolicyStatsMaxDelay Integer32 } slapmPolicyStatsSystemAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 4 | 16)) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Address of a system that an Policy definition relates to. A zero length octet string must be used to indicate that only a single system is being represented. Otherwise, the length of the octet string must be 4 for an ipv4 address or 16 for an ipv6 address." ::= { slapmPolicyStatsEntry 1 } slapmPolicyStatsPolicyName OBJECT-TYPE SYNTAX SlapmNameType MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Policy name that this entry relates to." ::= { slapmPolicyStatsEntry 2 } White Experimental [Page 14] RFC 2758 SLAPM-MIB February 2000 slapmPolicyStatsTrafficProfileName OBJECT-TYPE SYNTAX SlapmNameType MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The name of a traffic profile that is associated with a policy." ::= { slapmPolicyStatsEntry 3 } slapmPolicyStatsOperStatus OBJECT-TYPE SYNTAX INTEGER { inactive(1), active(2), deleteNeeded(3) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The state of a policy entry: inactive(1) - An policy entry was either defined by local system definition or discovered via a directory search but has not been activated (not currently being used). active(2) - Policy entry is being used to affect traffic flows. deleteNeeded(3) - Either though local implementation dependent methods or by discovering that the directory entry corresponding to this table entry no longer exists and slapmPolicyPurgeTime needs to expire before attempting to remove the corresponding slapmPolicyStatsEntry and any dependent slapmPolicyMonitor table entries. Note: a policy traffic profile in a state other than active(1) is not being used to affect traffic flows." ::= { slapmPolicyStatsEntry 4 } slapmPolicyStatsActiveConns OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of active TCP connections that are affected by the corresponding policy entry." ::= { slapmPolicyStatsEntry 5 } White Experimental [Page 15] RFC 2758 SLAPM-MIB February 2000 slapmPolicyStatsTotalConns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of total TCP connections that are affected by the corresponding policy entry." ::= { slapmPolicyStatsEntry 6 } slapmPolicyStatsFirstActivated OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The timestamp for when the corresponding policy entry is activated. The value of this object serves as the discontinuity event indicator when polling entries in this table. The value of this object is updated on transition of slapmPolicyStatsOperStatus into the active(2) state." DEFVAL { '0000000000000000'H } ::= { slapmPolicyStatsEntry 7 } slapmPolicyStatsLastMapping OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The timestamp for when the last time that the associated policy entry was used." DEFVAL { '0000000000000000'H } ::= { slapmPolicyStatsEntry 8 } slapmPolicyStatsInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of octets that was received by IP for an entity that map to this entry." ::= { slapmPolicyStatsEntry 9 } slapmPolicyStatsOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of octets that was transmitted by IP for an White Experimental [Page 16] RFC 2758 SLAPM-MIB February 2000 entity that map to this entry." ::= { slapmPolicyStatsEntry 10 } slapmPolicyStatsConnectionLimit OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The limit for the number of active TCP connections that are allowed for this policy definition. A value of zero for this object implies that a connection limit has not been specified." ::= { slapmPolicyStatsEntry 11 } slapmPolicyStatsCountAccepts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter is incremented when a policy action's Permission value is set to Accept and a session (TCP connection) is accepted." ::= { slapmPolicyStatsEntry 12 } slapmPolicyStatsCountDenies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter is incremented when a policy action's Permission value is set to Deny and a session is denied, or when a session (TCP connection) is rejected due to a policy's connection limit (slapmPolicyStatsConnectLimit) being reached." ::= { slapmPolicyStatsEntry 13 } slapmPolicyStatsInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter counts the number of in octets discarded. This occurs when an error is detected. Examples of this are buffer overflow, checksum error, or bad packet format." ::= { slapmPolicyStatsEntry 14 } slapmPolicyStatsOutDiscards OBJECT-TYPE White Experimental [Page 17] RFC 2758 SLAPM-MIB February 2000 SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter counts the number of out octets discarded. Examples of this are buffer overflow, checksum error, or bad packet format." ::= { slapmPolicyStatsEntry 15 } slapmPolicyStatsInPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter counts the number of in packets received that relate to this policy entry from IP." ::= { slapmPolicyStatsEntry 16 } slapmPolicyStatsOutPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter counts the number of out packets sent by IP that relate to this policy entry." ::= { slapmPolicyStatsEntry 17 } slapmPolicyStatsInProfileOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter counts the number of in octets that are determined to be within profile." ::= { slapmPolicyStatsEntry 18 } slapmPolicyStatsOutProfileOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This counter counts the number of out octets that are determined to be within profile." ::= { slapmPolicyStatsEntry 19 } slapmPolicyStatsMinRate OBJECT-TYPE SYNTAX Integer32 UNITS "Kilobits per second" White Experimental [Page 18] RFC 2758 SLAPM-MIB February 2000 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The minimum transfer rate defined for this entry." ::= { slapmPolicyStatsEntry 20 } slapmPolicyStatsMaxRate OBJECT-TYPE SYNTAX Integer32 UNITS "Kilobits per second" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The maximum transfer rate defined for this entry." ::= { slapmPolicyStatsEntry 21 } slapmPolicyStatsMaxDelay OBJECT-TYPE SYNTAX Integer32 UNITS "milliseconds" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The maximum delay defined for this entry." ::= { slapmPolicyStatsEntry 22 } -- SLA Performance Monitoring Policy Monitor Table slapmPolicyMonitorTable OBJECT-TYPE SYNTAX SEQUENCE OF SlapmPolicyMonitorEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Provides a method of monitoring policies and their effect at a system. This table has been deprecated and replaced with the slapmPRMonTable. Older implementations of this MIB are expected to continue their support of this table." ::= { slapmTableObjects 2 } slapmPolicyMonitorEntry OBJECT-TYPE SYNTAX SlapmPolicyMonitorEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Defines an entry in the slapmPolicyMonitorTable. This table defines which policies should be monitored on a per policy traffic profile basis." White Experimental [Page 19] RFC 2758 SLAPM-MIB February 2000 INDEX { slapmPolicyMonitorOwnerIndex, slapmPolicyMonitorSystemAddress, slapmPolicyMonitorPolicyName, slapmPolicyMonitorTrafficProfileName } ::= { slapmPolicyMonitorTable 1 } SlapmPolicyMonitorEntry ::= SEQUENCE { slapmPolicyMonitorOwnerIndex SnmpAdminString, slapmPolicyMonitorSystemAddress OCTET STRING, slapmPolicyMonitorPolicyName SlapmNameType, slapmPolicyMonitorTrafficProfileName SlapmNameType, slapmPolicyMonitorControl BITS, slapmPolicyMonitorStatus SlapmStatus, slapmPolicyMonitorInterval Integer32, slapmPolicyMonitorIntTime DateAndTime, slapmPolicyMonitorCurrentInRate Gauge32, slapmPolicyMonitorCurrentOutRate Gauge32, slapmPolicyMonitorMinRateLow Integer32, slapmPolicyMonitorMinRateHigh Integer32, slapmPolicyMonitorMaxRateHigh Integer32, slapmPolicyMonitorMaxRateLow Integer32, slapmPolicyMonitorMaxDelayHigh Integer32, slapmPolicyMonitorMaxDelayLow Integer32, slapmPolicyMonitorMinInRateNotAchieves Counter32, slapmPolicyMonitorMaxInRateExceeds Counter32, slapmPolicyMonitorMaxDelayExceeds Counter32, slapmPolicyMonitorMinOutRateNotAchieves Counter32, slapmPolicyMonitorMaxOutRateExceeds Counter32, slapmPolicyMonitorCurrentDelayRate Gauge32, slapmPolicyMonitorRowStatus RowStatus } slapmPolicyMonitorOwnerIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..16)) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (RFC 2575, VACM) for tables in which multiple users may need to independently create or modify entries, the initial index is used as an 'owner index'. Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a White Experimental [Page 20] RFC 2758 SLAPM-MIB February 2000 security policy. All entries in that table belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the 'column' subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask 'wildcarding' the column subidentifier. More elaborate configurations are possible." ::= { slapmPolicyMonitorEntry 1 } slapmPolicyMonitorSystemAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 4 | 16)) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Address of a system that an Policy definition relates to. A zero length octet string can be used to indicate that only a single system is being represented. Otherwise, the length of the octet string should be 4 for an ipv4 address and 16 for an ipv6 address." ::= { slapmPolicyMonitorEntry 2 } slapmPolicyMonitorPolicyName OBJECT-TYPE SYNTAX SlapmNameType MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Policy name that this entry relates to." ::= { slapmPolicyMonitorEntry 3 } slapmPolicyMonitorTrafficProfileName OBJECT-TYPE SYNTAX SlapmNameType MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The corresponding Traffic Profile name." ::= { slapmPolicyMonitorEntry 4 } slapmPolicyMonitorControl OBJECT-TYPE SYNTAX BITS { monitorMinRate(0), monitorMaxRate(1), White Experimental [Page 21] RFC 2758 SLAPM-MIB February 2000 monitorMaxDelay(2), enableAggregateTraps(3), enableSubcomponentTraps(4), monitorSubcomponents(5) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The value of this object determines the type and level of monitoring that is applied to a policy/profile. The value of this object can't be changed once the table entry that it is a part of is activated via a slapmPolicyMonitorRowStatus transition to active state. monitorMinRate(0) - Monitor minimum transfer rate. monitorMaxRate(1) - Monitor maximum transfer rate. monitorMaxDelay(2) - Monitor maximum delay. enableAggregateTraps(3) - The enableAggregateTraps(3) BITS setting enables notification generation when monitoring a policy traffic profile as an aggregate using the values in the corresponding slapmPolicyStatsEntry. By default this function is not enabled. enableSubcomponentTraps(4) - This BITS setting enables notification generation when monitoring all subcomponents that are mapped to an corresponding slapmPolicyStatsEntry. By default this function is not enabled. monitorSubcomponents(5) - This BITS setting enables monitoring of each subcomponent (typically a TCP connection or UDP listener) individually." DEFVAL { { monitorMinRate, monitorMaxRate, monitorMaxDelay } } ::= { slapmPolicyMonitorEntry 5 } slapmPolicyMonitorStatus OBJECT-TYPE SYNTAX SlapmStatus MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of this object indicates when a monitored value has not meet a threshold or isn't meeting the defined service level. The SlapmStatus TEXTUAL-CONVENTION defines two levels of not meeting a threshold. The first set: slaMinInRateNotAchieved(0), slaMaxInRateExceeded(1), slaMaxDelayExceeded(2), White Experimental [Page 22] RFC 2758 SLAPM-MIB February 2000 slaMinOutRateNotAchieved(3), slaMaxOutRateExceeded(4) are used to indicate when the SLA as an aggregate is not meeting a threshold while the second set: monitorMinInRateNotAchieved(5), monitorMaxInRateExceeded(6), monitorMaxDelayExceeded(7), monitorMinOutRateNotAchieved(8), monitorMaxOutRateExceeded(9) indicate that at least one subcomponent is not meeting a threshold." ::= { slapmPolicyMonitorEntry 6 } slapmPolicyMonitorInterval OBJECT-TYPE SYNTAX Integer32 (15..86400) -- 15 second min, 24 hour max UNITS "seconds" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The number of seconds that defines the sample period." DEFVAL {20} -- 20 seconds ::= { slapmPolicyMonitorEntry 7 } slapmPolicyMonitorIntTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The timestamp for when the last interval ended." DEFVAL { '0000000000000000'H } ::= { slapmPolicyMonitorEntry 8 } slapmPolicyMonitorCurrentInRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kilobits per second" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Using the value of the corresponding slapmPolicyMonitorInterval, slapmPolicyStatsInOctets is sampled and then divided by slapmPolicyMonitorInterval to determine the current in transfer rate." ::= { slapmPolicyMonitorEntry 9 } slapmPolicyMonitorCurrentOutRate OBJECT-TYPE White Experimental [Page 23] RFC 2758 SLAPM-MIB February 2000 SYNTAX Gauge32 UNITS "kilobits per second" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Using the value of the corresponding slapmPolicyMonitorInterval, slapmPolicyStatsOutOctets is sampled and then divided by slapmPolicyMonitorInterval to determine the current out transfer rate." ::= { slapmPolicyMonitorEntry 10 } slapmPolicyMonitorMinRateLow OBJECT-TYPE SYNTAX Integer32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The threshold for generating a slapmMonitoredEventNotAchieved notification, signalling that a monitored minimum transfer rate has not been meet. A slapmMonitoredEventNotAchieved notification is not generated again for an slapmPolicyMonitorEntry until the minimum transfer rate exceeds slapmPolicyMonitorMinRateHigh (a slapmMonitoredEventOkay notification is then transmitted) and then fails below slapmPolicyMonitorMinRateLow. This behavior reduces the slapmMonitoredEventNotAchieved notifications that are transmitted. A value of zero for this object is returned when the slapmPolicyMonitorControl monitorMinRate(0) is not enabled. When enabled the default value for this object is the min rate value specified in the associated action definition minus 10%. If the action definition doesn't have a min rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMinRate(0) is selected. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPolicyMonitorEntry 11 } slapmPolicyMonitorMinRateHigh OBJECT-TYPE SYNTAX Integer32 White Experimental [Page 24] RFC 2758 SLAPM-MIB February 2000 UNITS "kilobits per second" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The threshold for generating a slapmMonitoredEventOkay notification, signalling that a monitored minimum transfer rate has increased to an acceptable level. A value of zero for this object is returned when the slapmPolicyMonitorControl monitorMinRate(0) is not enabled. When enabled the default value for this object is the min rate value specified in the associated action definition plus 10%. If the action definition doesn't have a min rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMinRate(0) is selected. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPolicyMonitorEntry 12 } slapmPolicyMonitorMaxRateHigh OBJECT-TYPE SYNTAX Integer32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The threshold for generating a slapmMonitoredEventNotAchieved notification, signalling that a monitored maximum transfer rate has been exceeded. A slapmMonitoredEventNotAchieved notification is not generated again for an slapmPolicyMonitorEntry until the maximum transfer rate fails below slapmPolicyMonitorMaxRateLow (a slapmMonitoredEventOkay notification is then transmitted) and then raises above slapmPolicyMonitorMaxRateHigh. This behavior reduces the slapmMonitoredEventNotAchieved notifications that are transmitted. A value of zero for this object is returned when the slapmPolicyMonitorControl monitorMaxRate(1) is not enabled. When enabled the default value for this object is the max rate value specified in the associated action definition plus 10%. If the action definition White Experimental [Page 25] RFC 2758 SLAPM-MIB February 2000 doesn't have a max rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxRate(1) is selected. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPolicyMonitorEntry 13 } slapmPolicyMonitorMaxRateLow OBJECT-TYPE SYNTAX Integer32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The threshold for generating a slapmMonitoredEventOkay notification, signalling that a monitored maximum transfer rate has fallen to an acceptable level. A value of zero for this object is returned when the slapmPolicyMonitorControl monitorMaxRate(1) is not enabled. When enabled the default value for this object is the max rate value specified in the associated action definition minus 10%. If the action definition doesn't have a max rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxRate(1) is selected. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPolicyMonitorEntry 14 } slapmPolicyMonitorMaxDelayHigh OBJECT-TYPE SYNTAX Integer32 UNITS "milliseconds" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The threshold for generating a slapmMonitoredEventNotAchieved notification, signalling that a monitored maximum delay rate has been exceeded. A slapmMonitoredEventNotAchieved notification is not White Experimental [Page 26] RFC 2758 SLAPM-MIB February 2000 generated again for an slapmPolicyMonitorEntry until the maximum delay rate falls below slapmPolicyMonitorMaxDelayLow (a slapmMonitoredEventOkay notification is then transmitted) and raises above slapmPolicyMonitorMaxDelayHigh. This behavior reduces the slapmMonitoredEventNotAchieved notifications that are transmitted. A value of zero for this object is returned when the slapmPolicyMonitorControl monitorMaxDelay(4) is not enabled. When enabled the default value for this object is the max delay value specified in the associated action definition plus 10%. If the action definition doesn't have a max delay defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxDelay(4) is selected. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPolicyMonitorEntry 15 } slapmPolicyMonitorMaxDelayLow OBJECT-TYPE SYNTAX Integer32 UNITS "milliseconds" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The threshold for generating a slapmMonitoredEventOkay notification, signalling that a monitored maximum delay rate has fallen to an acceptable level. A value of zero for this object is returned when the slapmPolicyMonitorControl monitorMaxDelay(4) is not enabled. When enabled the default value for this object is the max delay value specified in the associated action definition minus 10%. If the action definition doesn't have a max delay defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxDelay(4) is selected. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." White Experimental [Page 27] RFC 2758 SLAPM-MIB February 2000 ::= { slapmPolicyMonitorEntry 16 } slapmPolicyMonitorMinInRateNotAchieves OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times that a minimum transfer in rate was not achieved." ::= { slapmPolicyMonitorEntry 17 } slapmPolicyMonitorMaxInRateExceeds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times that a maximum transfer in rate was exceeded." ::= { slapmPolicyMonitorEntry 18 } slapmPolicyMonitorMaxDelayExceeds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times that a maximum delay in rate was exceeded." ::= { slapmPolicyMonitorEntry 19 } slapmPolicyMonitorMinOutRateNotAchieves OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times that a minimum transfer out rate was not achieved." ::= { slapmPolicyMonitorEntry 20 } slapmPolicyMonitorMaxOutRateExceeds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times that a maximum transfer out rate was exceeded." ::= { slapmPolicyMonitorEntry 21 } slapmPolicyMonitorCurrentDelayRate OBJECT-TYPE White Experimental [Page 28] RFC 2758 SLAPM-MIB February 2000 SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The current delay rate for this entry. This is calculated by taking the average of the TCP round trip times for all associating slapmSubcomponentTable entries within a interval." ::= { slapmPolicyMonitorEntry 22 } slapmPolicyMonitorRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object allows entries to be created and deleted in the slapmPolicyMonitorTable. An entry in this table is deleted by setting this object to destroy(6). Removal of a corresponding (same policy and traffic profile names) slapmPolicyStatsEntry has the side effect of the automatic deletion an entry in this table." ::= { slapmPolicyMonitorEntry 23 } -- Subcomponent Table slapmSubcomponentTable OBJECT-TYPE SYNTAX SEQUENCE OF SlapmSubcomponentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a table to provide information on the individually components that are mapped to a policy rule (or old traffic profile). The indexing for this table is designed to support the use of an SNMP GET-NEXT operation using only the remote address and remote port as a way for a management station to retrieve the table entries relating to a particular client." ::= { slapmTableObjects 3 } slapmSubcomponentEntry OBJECT-TYPE SYNTAX SlapmSubcomponentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION White Experimental [Page 29] RFC 2758 SLAPM-MIB February 2000 "Describes a particular subcomponent entry. This table does not have an OwnerIndex as part of its indexing since this table's contents is intended to span multiple users." INDEX { slapmSubcomponentRemAddress, slapmSubcomponentRemPort, slapmSubcomponentLocalAddress, slapmSubcomponentLocalPort } ::= { slapmSubcomponentTable 1 } SlapmSubcomponentEntry ::= SEQUENCE { slapmSubcomponentRemAddress OCTET STRING, slapmSubcomponentRemPort Integer32, slapmSubcomponentLocalAddress OCTET STRING, slapmSubcomponentLocalPort Integer32, slapmSubcomponentProtocol INTEGER, slapmSubcomponentSystemAddress OCTET STRING, slapmSubcomponentPolicyName SlapmNameType, slapmSubcomponentTrafficProfileName SlapmNameType, slapmSubcomponentLastActivity DateAndTime, slapmSubcomponentInOctets Counter32, slapmSubcomponentOutOctets Counter32, slapmSubcomponentTcpOutBufferedOctets Counter32, slapmSubcomponentTcpInBufferedOctets Counter32, slapmSubcomponentTcpReXmts Counter32, slapmSubcomponentTcpRoundTripTime Integer32, slapmSubcomponentTcpRoundTripVariance Integer32, slapmSubcomponentInPdus Counter32, slapmSubcomponentOutPdus Counter32, slapmSubcomponentApplName SnmpAdminString, slapmSubcomponentMonitorStatus SlapmStatus, slapmSubcomponentMonitorIntTime DateAndTime, slapmSubcomponentMonitorCurrentInRate Gauge32, slapmSubcomponentMonitorCurrentOutRate Gauge32, slapmSubcomponentPolicyRuleIndex Unsigned32 } slapmSubcomponentRemAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 4 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicate the remote address of a subcomponent. A remote address can be either an ipv4 address in which case 4 octets are required or as an ipv6 address that White Experimental [Page 30] RFC 2758 SLAPM-MIB February 2000 requires 16 octets. The value of this subidentifier is a zero length octet string when this entry relates to a UDP listener." ::= { slapmSubcomponentEntry 1 } slapmSubcomponentRemPort OBJECT-TYPE SYNTAX Integer32(0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicate the remote port of a subcomponent. The value of this subidentifier is 0 when this entry relates to a UDP listener." ::= { slapmSubcomponentEntry 2 } slapmSubcomponentLocalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicate the local address of a subcomponent. A local address can be either an ipv4 address in which case 4 octets are required or as an ipv6 address that requires 16 octets." ::= { slapmSubcomponentEntry 3 } slapmSubcomponentLocalPort OBJECT-TYPE SYNTAX Integer32(0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicate the local port of a subcomponent." ::= { slapmSubcomponentEntry 4 } slapmSubcomponentProtocol OBJECT-TYPE SYNTAX INTEGER { udpListener(1), tcpConnection(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicate the protocol in use that identifies the type of subcomponent." ::= { slapmSubcomponentEntry 5 } slapmSubcomponentSystemAddress OBJECT-TYPE White Experimental [Page 31] RFC 2758 SLAPM-MIB February 2000 SYNTAX OCTET STRING (SIZE(0 | 4 | 16)) MAX-ACCESS read-only STATUS current DESCRIPTION "Address of a system that an Policy definition relates to. A zero length octet string can be used to indicate that only a single system is being represented. Otherwise, the length of the octet string should be 4 for an ipv4 address and 16 for an ipv6 address." ::= { slapmSubcomponentEntry 6 } slapmSubcomponentPolicyName OBJECT-TYPE SYNTAX SlapmNameType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Policy name that this entry relates to. This object, along with slapmSubcomponentTrafficProfileName, have been replaced with the use of an unsigned integer index that is mapped to an slapmPolicyNameEntry to actually identify policy naming." ::= { slapmSubcomponentEntry 7 } slapmSubcomponentTrafficProfileName OBJECT-TYPE SYNTAX SlapmNameType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The corresponding traffic profile name. This object, along with slapmSubcomponentProfileName, have been replaced with the use of an unsigned integer index that is mapped to an slapmPolicyNameEntry to actually identify policy naming." ::= { slapmSubcomponentEntry 8 } slapmSubcomponentLastActivity OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and timestamp of when this entry was last used." DEFVAL { '0000000000000000'H } ::= { slapmSubcomponentEntry 9 } slapmSubcomponentInOctets OBJECT-TYPE SYNTAX Counter32 White Experimental [Page 32] RFC 2758 SLAPM-MIB February 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets received from IP for this connection." ::= { slapmSubcomponentEntry 10 } slapmSubcomponentOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets sent to IP for this connection." ::= { slapmSubcomponentEntry 11 } slapmSubcomponentTcpOutBufferedOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of outgoing octets buffered. The value of this object is zero when the entry is not for a TCP connection." ::= { slapmSubcomponentEntry 12 } slapmSubcomponentTcpInBufferedOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of incoming octets buffered. The value of this object is zero when the entry is not for a TCP connection." ::= { slapmSubcomponentEntry 13 } slapmSubcomponentTcpReXmts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of retransmissions. The value of this object is zero when the entry is not for a TCP connection." ::= { slapmSubcomponentEntry 14 } slapmSubcomponentTcpRoundTripTime OBJECT-TYPE SYNTAX Integer32 UNITS "milliseconds" White Experimental [Page 33] RFC 2758 SLAPM-MIB February 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time that has elapsed, measured in milliseconds, from when the last TCP segment was transmitted by the TCP Stack until the ACK was received. The value of this object is zero when the entry is not for a TCP connection." ::= { slapmSubcomponentEntry 15 } slapmSubcomponentTcpRoundTripVariance OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Round trip time variance. The value of this object is zero when the entry is not for a TCP connection." ::= { slapmSubcomponentEntry 16 } slapmSubcomponentInPdus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of protocol related data units transferred inbound: slapmSubcomponentProtocol PDU Type udpListener(1) UDP datagrams tcpConnection(2) TCP segments" ::= { slapmSubcomponentEntry 17 } slapmSubcomponentOutPdus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of protocol related data units transferred outbound: slapmSubcomponentProtocol PDU Type udpListener(1) UDP datagrams White Experimental [Page 34] RFC 2758 SLAPM-MIB February 2000 tcpConnection(2) TCP segments" ::= { slapmSubcomponentEntry 18 } slapmSubcomponentApplName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The application name associated with this entry if known, otherwise a zero-length octet string is returned as the value of this object." ::= { slapmSubcomponentEntry 19 } slapmSubcomponentMonitorStatus OBJECT-TYPE SYNTAX SlapmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates when a monitored value has exceeded a threshold or isn't meeting the defined service level. Only the following SlapmStatus BITS setting can be reported here: monitorMinInRateNotAchieved(5), monitorMaxInRateExceeded(6), monitorMaxDelayExceeded(7), monitorMinOutRateNotAchieved(8), monitorMaxOutRateExceeded(9) This object only has meaning when an corresponding slapmPolicyMonitorEntry exists with the slapmPolicyMonitorControl BITS setting monitorSubcomponents(5) enabled." ::= { slapmSubcomponentEntry 20 } slapmSubcomponentMonitorIntTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp for when the last interval ended. This object only has meaning when an corresponding slapmPRMonEntry (or old slapmPolicyMonitorEntry) exists with the slapmPRMonControl (or slapmPolicyMonitorControl) BITS setting monitorSubcomponents(5) enabled. All of the octets returned when monitoring is not in effect White Experimental [Page 35] RFC 2758 SLAPM-MIB February 2000 must be zero." DEFVAL { '0000000000000000'H } ::= { slapmSubcomponentEntry 21 } slapmSubcomponentMonitorCurrentInRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kilobits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "Using the value of the corresponding slapmPRMonInterval (or slapmPolicyMonitorInterval), slapmSubcomponentStatsInOctets is divided by slapmSubcomponentMonitorInterval to determine the current in transfer rate. This object only has meaning when an corresponding slapmPRMonEntry (or slapmPolicyMonitorEntry) exists with the slapmPRMonControl (or slapmPolicyMonitorControl) BITS setting monitorSubcomponents(5) enabled. The value of this object is zero when monitoring is not in effect." ::= { slapmSubcomponentEntry 22 } slapmSubcomponentMonitorCurrentOutRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kilobits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "Using the value of the corresponding slapmPRMonInterval (or slapmPolicyMonitorInterva)l, slapmSubcomponentStatsOutOctets is divided by slapmPRMonInterval (or slapmPolicyMonitorInterval) to determine the current out transfer rate. This object only has meaning when an corresponding slapmPRMonEntry (or slapmPolicyMonitorEntry) exists with the slapmPRMonControl (or slapmPolicyMonitorControl) BITS setting monitorSubcomponents(5) enabled. The value of this object is zero when monitoring is not in effect." ::= { slapmSubcomponentEntry 23 } slapmSubcomponentPolicyRuleIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION White Experimental [Page 36] RFC 2758 SLAPM-MIB February 2000 "Points to an slapmPolicyNameEntry when combined with slapmSubcomponentSystemAddress to indicate the policy naming that relates to this entry. A value of 0 for this object MUST be returned when the corresponding slapmSubcomponentEntry has no policy rule associated with it." ::= { slapmSubcomponentEntry 24 } -- Table that maps an unsigned integer index to whatever -- names a policy rule. slapmPolicyNameTable OBJECT-TYPE SYNTAX SEQUENCE OF SlapmPolicyNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides the mapping between a policy index as a unsigned 32 bit integer and the unique name associated with a policy rule." ::= { slapmTableObjects 4 } slapmPolicyNameEntry OBJECT-TYPE SYNTAX SlapmPolicyNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the slapmPolicyNameTable." INDEX { slapmPolicyNameSystemAddress, slapmPolicyNameIndex } ::= { slapmPolicyNameTable 1 } SlapmPolicyNameEntry ::= SEQUENCE { slapmPolicyNameSystemAddress OCTET STRING, slapmPolicyNameIndex Unsigned32, slapmPolicyNameOfRule SlapmPolicyRuleName } slapmPolicyNameSystemAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 4 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address of a system that an Policy rule definition relates to. A zero length octet string must be used to indicate White Experimental [Page 37] RFC 2758 SLAPM-MIB February 2000 that only a single system is being represented. Otherwise, the length of the octet string must be 4 for an ipv4 address or 16 for an ipv6 address." ::= { slapmPolicyNameEntry 1 } slapmPolicyNameIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally arbitrary, but unique identifier associated with this table entry. This value is not expected to remain constant across reIPLs." ::= { slapmPolicyNameEntry 2 } slapmPolicyNameOfRule OBJECT-TYPE SYNTAX SlapmPolicyRuleName MAX-ACCESS read-only STATUS current DESCRIPTION "The unique name that identifies a policy rule definition." ::= { slapmPolicyNameEntry 3 } -- Sla Performance Monitoring Policy Rule Statistics Table slapmPolicyRuleStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SlapmPolicyRuleStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides statistics on a per system and a per policy rule basis." ::= { slapmTableObjects 5 } slapmPolicyRuleStatsEntry OBJECT-TYPE SYNTAX SlapmPolicyRuleStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the slapmPolicyRuleStatsTable. This table defines a set of statistics that is kept on a per system and per policy rule basis. Entries in this table are not created or deleted via SNMP but reflect the set of policy rule definitions known at a system." INDEX { slapmPolicyNameSystemAddress, White Experimental [Page 38] RFC 2758 SLAPM-MIB February 2000 slapmPolicyNameIndex } ::= { slapmPolicyRuleStatsTable 1 } SlapmPolicyRuleStatsEntry ::= SEQUENCE { slapmPolicyRuleStatsOperStatus INTEGER, slapmPolicyRuleStatsActiveConns Gauge32, slapmPolicyRuleStatsTotalConns Counter32, slapmPolicyRuleStatsLActivated DateAndTime, slapmPolicyRuleStatsLastMapping DateAndTime, slapmPolicyRuleStatsInOctets Counter32, slapmPolicyRuleStatsOutOctets Counter32, slapmPolicyRuleStatsConnLimit Unsigned32, slapmPolicyRuleStatsCountAccepts Counter32, slapmPolicyRuleStatsCountDenies Counter32, slapmPolicyRuleStatsInDiscards Counter32, slapmPolicyRuleStatsOutDiscards Counter32, slapmPolicyRuleStatsInPackets Counter32, slapmPolicyRuleStatsOutPackets Counter32, slapmPolicyRuleStatsInProOctets Counter32, slapmPolicyRuleStatsOutProOctets Counter32, slapmPolicyRuleStatsMinRate Unsigned32, slapmPolicyRuleStatsMaxRate Unsigned32, slapmPolicyRuleStatsMaxDelay Unsigned32, slapmPolicyRuleStatsTotalRsvpFlows Counter32, slapmPolicyRuleStatsActRsvpFlows Gauge32 } slapmPolicyRuleStatsOperStatus OBJECT-TYPE SYNTAX INTEGER { inactive(1), active(2), deleteNeeded(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of a policy entry: inactive(1) - An policy entry was either defined by local system definition or discovered via a directory search but has not been activated (not currently being used). active(2) - Policy entry is being used to affect traffic flows. deleteNeeded(3) - Either though local implementation White Experimental [Page 39] RFC 2758 SLAPM-MIB February 2000 dependent methods or by discovering that the directory entry corresponding to this table entry no longer exists and slapmPolicyPurgeTime needs to expire before attempting to remove the corresponding slapmPolicyStatsEntry and any dependent slapmPolicyMonitor table entries. Note: a policy rule in a state other than active(2) is not being used to affect traffic flows." ::= { slapmPolicyRuleStatsEntry 1 } slapmPolicyRuleStatsActiveConns OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active TCP connections that are affected by the corresponding policy entry." ::= { slapmPolicyRuleStatsEntry 2 } slapmPolicyRuleStatsTotalConns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of total TCP connections that are affected by the corresponding policy entry." ::= { slapmPolicyRuleStatsEntry 3 } slapmPolicyRuleStatsLActivated OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp for when the corresponding policy entry was last activated. The value of this object serves as the discontinuity event indicator when polling entries in this table. The value of this object is updated on transition of slapmPolicyRuleStatsOperStatus into the active(2) state." DEFVAL { '0000000000000000'H } ::= { slapmPolicyRuleStatsEntry 4 } slapmPolicyRuleStatsLastMapping OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current White Experimental [Page 40] RFC 2758 SLAPM-MIB February 2000 DESCRIPTION "The timestamp for when the last time that the associated policy entry was used." DEFVAL { '0000000000000000'H } ::= { slapmPolicyRuleStatsEntry 5 } slapmPolicyRuleStatsInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that was received by IP for an entity that map to this entry." ::= { slapmPolicyRuleStatsEntry 6 } slapmPolicyRuleStatsOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that was transmitted by IP for an entity that map to this entry." ::= { slapmPolicyRuleStatsEntry 7 } slapmPolicyRuleStatsConnLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The limit for the number of active TCP connections that are allowed for this policy definition. A value of zero for this object implies that a connection limit has not been specified." ::= { slapmPolicyRuleStatsEntry 8 } slapmPolicyRuleStatsCountAccepts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when a policy action's Permission value is set to Accept and a session (TCP connection) is accepted." ::= { slapmPolicyRuleStatsEntry 9 } slapmPolicyRuleStatsCountDenies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only White Experimental [Page 41] RFC 2758 SLAPM-MIB February 2000 STATUS current DESCRIPTION "This counter is incremented when a policy action's Permission value is set to Deny and a session is denied, or when a session (TCP connection) is rejected due to a policy's connection limit (slapmPolicyRuleStatsConnectLimit) being reached." ::= { slapmPolicyRuleStatsEntry 10 } slapmPolicyRuleStatsInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter counts the number of in octets discarded. This occurs when an error is detected. Examples of this are buffer overflow, checksum error, or bad packet format." ::= { slapmPolicyRuleStatsEntry 11 } slapmPolicyRuleStatsOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter counts the number of out octets discarded. Examples of this are buffer overflow, checksum error, or bad packet format." ::= { slapmPolicyRuleStatsEntry 12 } slapmPolicyRuleStatsInPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter counts the number of in packets received that relate to this policy entry from IP." ::= { slapmPolicyRuleStatsEntry 13 } slapmPolicyRuleStatsOutPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter counts the number of out packets sent by IP that relate to this policy entry." ::= { slapmPolicyRuleStatsEntry 14 } White Experimental [Page 42] RFC 2758 SLAPM-MIB February 2000 slapmPolicyRuleStatsInProOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter counts the number of in octets that are determined to be within profile." ::= { slapmPolicyRuleStatsEntry 15 } slapmPolicyRuleStatsOutProOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter counts the number of out octets that are determined to be within profile." ::= { slapmPolicyRuleStatsEntry 16 } slapmPolicyRuleStatsMinRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "Kilobits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum transfer rate defined for this entry." ::= { slapmPolicyRuleStatsEntry 17 } slapmPolicyRuleStatsMaxRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "Kilobits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum transfer rate defined for this entry." ::= { slapmPolicyRuleStatsEntry 18 } slapmPolicyRuleStatsMaxDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum delay defined for this entry." ::= { slapmPolicyRuleStatsEntry 19 } slapmPolicyRuleStatsTotalRsvpFlows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only White Experimental [Page 43] RFC 2758 SLAPM-MIB February 2000 STATUS current DESCRIPTION "Total number of RSVP flows that have be activated." ::= { slapmPolicyRuleStatsEntry 20 } slapmPolicyRuleStatsActRsvpFlows OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current number of active RSVP flows." ::= { slapmPolicyRuleStatsEntry 21 } -- SLA Performance Monitoring Policy Rule Monitor Table slapmPRMonTable OBJECT-TYPE SYNTAX SEQUENCE OF SlapmPRMonEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides a method of monitoring policies and their effect at a system." ::= { slapmTableObjects 6 } slapmPRMonEntry OBJECT-TYPE SYNTAX SlapmPRMonEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the slapmPRMonTable. This table defines which policies should be monitored on a per policy rule basis. An attempt to set any read-create object defined within an slapmPRMonEntry while the value of slapmPRMonRowStatus is active(1) will result in an inconsistentValue error." INDEX { slapmPRMonOwnerIndex, slapmPRMonSystemAddress, slapmPRMonIndex } ::= { slapmPRMonTable 1 } SlapmPRMonEntry ::= SEQUENCE { slapmPRMonOwnerIndex SnmpAdminString, slapmPRMonSystemAddress OCTET STRING, slapmPRMonIndex Unsigned32, White Experimental [Page 44] RFC 2758 SLAPM-MIB February 2000 slapmPRMonControl BITS, slapmPRMonStatus SlapmStatus, slapmPRMonInterval Unsigned32, slapmPRMonIntTime DateAndTime, slapmPRMonCurrentInRate Gauge32, slapmPRMonCurrentOutRate Gauge32, slapmPRMonMinRateLow Unsigned32, slapmPRMonMinRateHigh Unsigned32, slapmPRMonMaxRateHigh Unsigned32, slapmPRMonMaxRateLow Unsigned32, slapmPRMonMaxDelayHigh Unsigned32, slapmPRMonMaxDelayLow Unsigned32, slapmPRMonMinInRateNotAchieves Counter32, slapmPRMonMaxInRateExceeds Counter32, slapmPRMonMaxDelayExceeds Counter32, slapmPRMonMinOutRateNotAchieves Counter32, slapmPRMonMaxOutRateExceeds Counter32, slapmPRMonCurrentDelayRate Gauge32, slapmPRMonRowStatus RowStatus } slapmPRMonOwnerIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (RFC 2575, VACM) for tables in which multiple users may need to independently create or modify entries, the initial index is used as an 'owner index'. Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in that table belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the 'column' subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask 'wildcarding' the column subidentifier. More elaborate configurations are possible." White Experimental [Page 45] RFC 2758 SLAPM-MIB February 2000 ::= { slapmPRMonEntry 1 } slapmPRMonSystemAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 4 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address of a system that an Policy definition relates to. A zero length octet string can be used to indicate that only a single system is being represented. Otherwise, the length of the octet string should be 4 for an ipv4 address and 16 for an ipv6 address." ::= { slapmPRMonEntry 2 } slapmPRMonIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An slapmPolicyNameTable index, slapmPolicyNameIndex, that points to the unique name associated with a policy rule definition." ::= { slapmPRMonEntry 3 } slapmPRMonControl OBJECT-TYPE SYNTAX BITS { monitorMinRate(0), monitorMaxRate(1), monitorMaxDelay(2), enableAggregateTraps(3), enableSubcomponentTraps(4), monitorSubcomponents(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object determines the type and level of monitoring that is applied to a policy rule. The value of this object can't be changed once the table entry that it is a part of is activated via a slapmPRMonRowStatus transition to active state. monitorMinRate(0) - Monitor minimum transfer rate. monitorMaxRate(1) - Monitor maximum transfer rate. monitorMaxDelay(2) - Monitor maximum delay. enableAggregateTraps(3) - The enableAggregateTraps(3) BITS setting enables notification generation when monitoring a policy rule as an White Experimental [Page 46] RFC 2758 SLAPM-MIB February 2000 aggregate using the values in the corresponding slapmPRMonStatsEntry. By default this function is not enabled. enableSubcomponentTraps(4) - This BITS setting enables notification generation when monitoring all subcomponents that are mapped to an corresponding slapmPRMonStatsEntry. By default this function is not enabled. monitorSubcomponents(5) - This BITS setting enables monitoring of each subcomponent (typically a TCP connection or UDP listener) individually." DEFVAL { { monitorMinRate, monitorMaxRate, monitorMaxDelay } } ::= { slapmPRMonEntry 4 } slapmPRMonStatus OBJECT-TYPE SYNTAX SlapmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates when a monitored value has not meet a threshold or isn't meeting the defined service level. The SlapmStatus TEXTUAL-CONVENTION defines two levels of not meeting a threshold. The first set: slaMinInRateNotAchieved(0), slaMaxInRateExceeded(1), slaMaxDelayExceeded(2), slaMinOutRateNotAchieved(3), slaMaxOutRateExceeded(4) are used to indicate when the SLA as an aggregate is not meeting a threshold while the second set: monitorMinInRateNotAchieved(5), monitorMaxInRateExceeded(6), monitorMaxDelayExceeded(7), monitorMinOutRateNotAchieved(8), monitorMaxOutRateExceeded(9) indicate that at least one subcomponent is not meeting a threshold." ::= { slapmPRMonEntry 5 } slapmPRMonInterval OBJECT-TYPE SYNTAX Unsigned32 (15..86400) -- 15 second min, 24 hour max UNITS "seconds" MAX-ACCESS read-create White Experimental [Page 47] RFC 2758 SLAPM-MIB February 2000 STATUS current DESCRIPTION "The number of seconds that defines the sample period." DEFVAL {20} -- 20 seconds ::= { slapmPRMonEntry 6 } slapmPRMonIntTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp for when the last interval ended." DEFVAL { '0000000000000000'H } ::= { slapmPRMonEntry 7 } slapmPRMonCurrentInRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kilobits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "Using the value of the corresponding slapmPRMonInterval, slapmPolicyRuleStatsInOctets is sampled and then divided by slapmPRMonInterval to determine the current in transfer rate." ::= { slapmPRMonEntry 8 } slapmPRMonCurrentOutRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kilobits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "Using the value of the corresponding slapmPolicyMonInterval, slapmPolicyRuleStatsOutOctets is sampled and then divided by slapmPRMonInterval to determine the current out transfer rate." ::= { slapmPRMonEntry 9 } slapmPRMonMinRateLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a slapmPolicyRuleMonNotOkay notification, signalling that a monitored minimum transfer rate has not been meet. White Experimental [Page 48] RFC 2758 SLAPM-MIB February 2000 A slapmPolicyRuleMonNotOkay notification is not generated again for an slapmPRMonEntry until the minimum transfer rate exceeds slapmPRMonMinRateHigh (a slapmPolicyRuleMonOkay notification is then transmitted) and then fails below slapmPRMonMinRateLow. This behavior reduces the slapmPolicyRuleMonNotOkay notifications that are transmitted. A value of zero for this object is returned when the slapmPRMonControl monitorMinRate(0) is not enabled. When enabled the default value for this object is the min rate value specified in the associated action definition minus 10%. If the action definition doesn't have a min rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMinRate(0) is selected. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPRMonEntry 10 } slapmPRMonMinRateHigh OBJECT-TYPE SYNTAX Unsigned32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a slapmPolicyRuleMonOkay notification, signalling that a monitored minimum transfer rate has increased to an acceptable level. A value of zero for this object is returned when the slapmPRMonControl monitorMinRate(0) is not enabled. When enabled the default value for this object is the min rate value specified in the associated action definition plus 10%. If the action definition doesn't have a min rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMinRate(0) is selected. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to White Experimental [Page 49] RFC 2758 SLAPM-MIB February 2000 potentially be generated." ::= { slapmPRMonEntry 11 } slapmPRMonMaxRateHigh OBJECT-TYPE SYNTAX Unsigned32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a slapmPolicyRuleMonNotOkay notification, signalling that a monitored maximum transfer rate has been exceeded. A slapmPolicyRuleNotOkay notification is not generated again for an slapmPRMonEntry until the maximum transfer rate fails below slapmPRMonMaxRateLow (a slapmPolicyRuleMonOkay notification is then transmitted) and then raises above slapmPRMonMaxRateHigh. This behavior reduces the slapmPolicyRuleMonNotOkay notifications that are transmitted. A value of zero for this object is returned when the slapmPRMonControl monitorMaxRate(1) is not enabled. When enabled the default value for this object is the max rate value specified in the associated action definition plus 10%. If the action definition doesn't have a max rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxRate(1) is selected. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPRMonEntry 12 } slapmPRMonMaxRateLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a slapmPolicyRuleMonOkay notification, signalling that a monitored maximum transfer rate has fallen to an acceptable level. White Experimental [Page 50] RFC 2758 SLAPM-MIB February 2000 A value of zero for this object is returned when the slapmPRMonControl monitorMaxRate(1) is not enabled. When enabled the default value for this object is the max rate value specified in the associated action definition minus 10%. If the action definition doesn't have a max rate defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxRate(1) is selected. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPRMonEntry 13 } slapmPRMonMaxDelayHigh OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a slapmPolicyRuleMonNotOkay notification, signalling that a monitored maximum delay rate has been exceeded. A slapmPolicyRuleMonNotOkay notification is not generated again for an slapmPRMonEntry until the maximum delay rate falls below slapmPRMonMaxDelayLow (a slapmPolicyRuleMonOkay notification is then transmitted) and raises above slapmPRMonMaxDelayHigh. This behavior reduces the slapmPolicyRuleMonNotOkay notifications that are transmitted. A value of zero for this object is returned when the slapmPRMonControl monitorMaxDelay(4) is not enabled. When enabled the default value for this object is the max delay value specified in the associated action definition plus 10%. If the action definition doesn't have a max delay defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxDelay(4) is selected. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to White Experimental [Page 51] RFC 2758 SLAPM-MIB February 2000 potentially be generated." ::= { slapmPRMonEntry 14 } slapmPRMonMaxDelayLow OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold for generating a slapmPolicyRuleMonOkay notification, signalling that a monitored maximum delay rate has fallen to an acceptable level. A value of zero for this object is returned when the slapmPRMonControl monitorMaxDelay(4) is not enabled. When enabled the default value for this object is the max delay value specified in the associated action definition minus 10%. If the action definition doesn't have a max delay defined then there is no default for this object and a value MUST be specified prior to activating this entry when monitorMaxDelay(4) is selected. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for any notification relating to this entry to potentially be generated." ::= { slapmPRMonEntry 15 } slapmPRMonMinInRateNotAchieves OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a minimum transfer in rate was not achieved." ::= { slapmPRMonEntry 16 } slapmPRMonMaxInRateExceeds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a maximum transfer in rate was exceeded." ::= { slapmPRMonEntry 17 } slapmPRMonMaxDelayExceeds OBJECT-TYPE White Experimental [Page 52] RFC 2758 SLAPM-MIB February 2000 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a maximum delay in rate was exceeded." ::= { slapmPRMonEntry 18 } slapmPRMonMinOutRateNotAchieves OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a minimum transfer out rate was not achieved." ::= { slapmPRMonEntry 19 } slapmPRMonMaxOutRateExceeds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a maximum transfer out rate was exceeded." ::= { slapmPRMonEntry 20 } slapmPRMonCurrentDelayRate OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The current delay rate for this entry. This is calculated by taking the average of the TCP round trip times for all associating slapmSubcomponentTable entries within a interval." ::= { slapmPRMonEntry 21 } slapmPRMonRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the slapmPRMonTable. An entry in this table is deleted by setting this object to destroy(6). Removal of an corresponding (same policy index) White Experimental [Page 53] RFC 2758 SLAPM-MIB February 2000 slapmPolicyRuleStatsEntry has the side effect of the automatic deletion an entry in this table. Note that an attempt to set any read-create object defined within an slapmPRMonEntry while the value of slapmPRMonRowStatus is active(1) will result in an inconsistentValue error." ::= { slapmPRMonEntry 22 } -- Notifications slapmMonitoredEventNotAchieved NOTIFICATION-TYPE OBJECTS { slapmPolicyMonitorIntTime, slapmPolicyMonitorControl, slapmPolicyMonitorStatus, slapmPolicyMonitorStatus, slapmPolicyMonitorCurrentInRate, slapmPolicyMonitorCurrentOutRate, slapmPolicyMonitorCurrentDelayRate } STATUS deprecated DESCRIPTION "This notification is generated when an monitored event is not achieved with respect to threshold. This applies only towards monitoring a policy traffic profile as an aggregate via an associating slapmPolicyStatsEntry. The value of slapmPolicyMonitorControl can be examined to determine what is being monitored. The first slapmPolicyMonitorStatus value supplies the current monitor status while the 2nd value supplies the previous status. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 1 } slapmMonitoredEventOkay NOTIFICATION-TYPE OBJECTS { slapmPolicyMonitorIntTime, slapmPolicyMonitorControl, slapmPolicyMonitorStatus, slapmPolicyMonitorStatus, slapmPolicyMonitorCurrentInRate, slapmPolicyMonitorCurrentOutRate, White Experimental [Page 54] RFC 2758 SLAPM-MIB February 2000 slapmPolicyMonitorCurrentDelayRate } STATUS deprecated DESCRIPTION "This notification is generated when a monitored event has improved to an acceptable level. This applies only towards monitoring a policy traffic profile as an aggregate via an associating slapmPolicyStatsEntry. The value of slapmPolicyMonitorControl can be examined to determine what is being monitored. The first slapmPolicyMonitorStatus value supplies the current monitor status while the 2nd value supplies the previous status. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableAggregateTraps(3), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 2 } slapmPolicyProfileDeleted NOTIFICATION-TYPE OBJECTS { slapmPolicyStatsActiveConns, slapmPolicyStatsTotalConns, slapmPolicyStatsFirstActivated, slapmPolicyStatsLastMapping, slapmPolicyStatsInOctets, slapmPolicyStatsOutOctets, slapmPolicyStatsConnectionLimit, slapmPolicyStatsCountAccepts, slapmPolicyStatsCountDenies, slapmPolicyStatsInDiscards, slapmPolicyStatsOutDiscards, slapmPolicyStatsInPackets, slapmPolicyStatsOutPackets, slapmPolicyStatsInProfileOctets, slapmPolicyStatsOutProfileOctets, slapmPolicyStatsMinRate, slapmPolicyStatsMaxRate, slapmPolicyStatsMaxDelay } STATUS deprecated DESCRIPTION "A slapmPolicyDeleted notification is sent when a slapmPolicyStatsEntry is deleted if the value of slapmPolicyTrapEnable is enabled(1)." ::= { slapmNotifications 3 } White Experimental [Page 55] RFC 2758 SLAPM-MIB February 2000 slapmPolicyMonitorDeleted NOTIFICATION-TYPE OBJECTS { slapmPolicyMonitorStatus, slapmPolicyMonitorInterval, slapmPolicyMonitorIntTime, slapmPolicyMonitorCurrentInRate, slapmPolicyMonitorCurrentOutRate, slapmPolicyMonitorCurrentDelayRate, slapmPolicyMonitorMinRateLow, slapmPolicyMonitorMinRateHigh, slapmPolicyMonitorMaxRateHigh, slapmPolicyMonitorMaxRateLow, slapmPolicyMonitorMaxDelayHigh, slapmPolicyMonitorMaxDelayLow, slapmPolicyMonitorMinInRateNotAchieves, slapmPolicyMonitorMaxInRateExceeds, slapmPolicyMonitorMaxDelayExceeds, slapmPolicyMonitorMinOutRateNotAchieves, slapmPolicyMonitorMaxOutRateExceeds } STATUS deprecated DESCRIPTION "A slapmPolicyMonitorDeleted notification is sent when a slapmPolicyMonitorEntry is deleted if the value of slapmPolicyTrapEnable is enabled(1)." ::= { slapmNotifications 4 } slapmSubcomponentMonitoredEventNotAchieved NOTIFICATION-TYPE OBJECTS { slapmSubcomponentSystemAddress, slapmSubcomponentPolicyName, slapmSubcomponentTrafficProfileName, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorIntTime, slapmSubcomponentMonitorCurrentInRate, slapmSubcomponentMonitorCurrentOutRate, slapmSubcomponentTcpRoundTripTime } STATUS deprecated DESCRIPTION "This notification is generated when a monitored value does not achieved a threshold specification. This applies only towards monitoring the individual components of a policy traffic profile. The value of the corresponding slapmPolicyMonitorControl can be examined to determine what is being monitored. The first slapmSubcomponentMonitorStatus value supplies the current White Experimental [Page 56] RFC 2758 SLAPM-MIB February 2000 monitor status while the 2nd value supplies the previous status. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableSubcomponentTraps(4), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 5 } slapmSubcomponentMonitoredEventOkay NOTIFICATION-TYPE OBJECTS { slapmSubcomponentSystemAddress, slapmSubcomponentPolicyName, slapmSubcomponentTrafficProfileName, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorIntTime, slapmSubcomponentMonitorCurrentInRate, slapmSubcomponentMonitorCurrentOutRate, slapmSubcomponentTcpRoundTripTime } STATUS deprecated DESCRIPTION "This notification is generated when a monitored value has reached an acceptable level. Note: The corresponding slapmPolicyMonitorControl BITS setting, enableSubcomponentTraps(3), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 6 } slapmPolicyRuleMonNotOkay NOTIFICATION-TYPE OBJECTS { slapmPRMonIntTime, slapmPRMonControl, slapmPRMonStatus, slapmPRMonStatus, slapmPRMonCurrentInRate, slapmPRMonCurrentOutRate, slapmPRMonCurrentDelayRate } STATUS current DESCRIPTION "This notification is generated when an monitored event is not achieved with respect to a threshold. This applies only towards monitoring a policy rule as an aggregate via an associating slapmPolicyRuleStatsEntry. The value White Experimental [Page 57] RFC 2758 SLAPM-MIB February 2000 of slapmPRMonControl can be examined to determine what is being monitored. The first slapmPRMonStatus value supplies the current monitor status while the 2nd value supplies the previous status. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 7 } slapmPolicyRuleMonOkay NOTIFICATION-TYPE OBJECTS { slapmPRMonIntTime, slapmPRMonControl, slapmPRMonStatus, slapmPRMonStatus, slapmPRMonCurrentInRate, slapmPRMonCurrentOutRate, slapmPRMonCurrentDelayRate } STATUS current DESCRIPTION "This notification is generated when a monitored event has improved to an acceptable level. This applies only towards monitoring a policy rule as an aggregate via an associating slapmPolicyRuleStatsEntry. The value of slapmPRMonControl can be examined to determine what is being monitored. The first slapmPRMonStatus value supplies the current monitor status while the 2nd value supplies the previous status. Note: The corresponding slapmPRMonControl BITS setting, enableAggregateTraps(3), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 8 } slapmPolicyRuleDeleted NOTIFICATION-TYPE OBJECTS { slapmPolicyRuleStatsActiveConns, slapmPolicyRuleStatsTotalConns, slapmPolicyRuleStatsLActivated, slapmPolicyRuleStatsLastMapping, slapmPolicyRuleStatsInOctets, White Experimental [Page 58] RFC 2758 SLAPM-MIB February 2000 slapmPolicyRuleStatsOutOctets, slapmPolicyRuleStatsConnLimit, slapmPolicyRuleStatsCountAccepts, slapmPolicyRuleStatsCountDenies, slapmPolicyRuleStatsInDiscards, slapmPolicyRuleStatsOutDiscards, slapmPolicyRuleStatsInPackets, slapmPolicyRuleStatsOutPackets, slapmPolicyRuleStatsInProOctets, slapmPolicyRuleStatsOutProOctets, slapmPolicyRuleStatsMinRate, slapmPolicyRuleStatsMaxRate, slapmPolicyRuleStatsMaxDelay, slapmPolicyRuleStatsTotalRsvpFlows, slapmPolicyRuleStatsActRsvpFlows } STATUS current DESCRIPTION "A slapmPolicyRuleDeleted notification is sent when a slapmPolicyRuleStatsEntry is deleted if the value of slapmPolicyTrapEnable is enabled(1)." ::= { slapmNotifications 9 } slapmPolicyRuleMonDeleted NOTIFICATION-TYPE OBJECTS { slapmPRMonControl, slapmPRMonStatus, slapmPRMonInterval, slapmPRMonIntTime, slapmPRMonCurrentInRate, slapmPRMonCurrentOutRate, slapmPRMonCurrentDelayRate, slapmPRMonMinRateLow, slapmPRMonMinRateHigh, slapmPRMonMaxRateHigh, slapmPRMonMaxRateLow, slapmPRMonMaxDelayHigh, slapmPRMonMaxDelayLow, slapmPRMonMinInRateNotAchieves, slapmPRMonMaxInRateExceeds, slapmPRMonMaxDelayExceeds, slapmPRMonMinOutRateNotAchieves, slapmPRMonMaxOutRateExceeds } STATUS current DESCRIPTION "A slapmPolicyRuleMonDeleted notification is sent when a slapmPRMonEntry is deleted if the value of White Experimental [Page 59] RFC 2758 SLAPM-MIB February 2000 slapmPolicyTrapEnable is enabled(1)." ::= { slapmNotifications 10 } slapmSubcMonitorNotOkay NOTIFICATION-TYPE OBJECTS { slapmSubcomponentSystemAddress, slapmSubcomponentPolicyRuleIndex, slapmPRMonControl, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorIntTime, slapmSubcomponentMonitorCurrentInRate, slapmSubcomponentMonitorCurrentOutRate, slapmSubcomponentTcpRoundTripTime } STATUS current DESCRIPTION "This notification is generated when a monitored value does not achieved a threshold specification. This applies only towards monitoring the individual components of a policy rule. The value of the corresponding slapmPRMonControl can be examined to determine what is being monitored. The first slapmSubcomponentMonitorStatus value supplies the current monitor status while the 2nd value supplies the previous status. Note: The corresponding slapmPRMonControl BITS setting, enableSubcomponentTraps(4), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 11 } slapmSubcMonitorOkay NOTIFICATION-TYPE OBJECTS { slapmSubcomponentSystemAddress, slapmSubcomponentPolicyRuleIndex, slapmPRMonControl, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorIntTime, slapmSubcomponentMonitorCurrentInRate, slapmSubcomponentMonitorCurrentOutRate, slapmSubcomponentTcpRoundTripTime } STATUS current DESCRIPTION "This notification is generated when a monitored value White Experimental [Page 60] RFC 2758 SLAPM-MIB February 2000 has reached an acceptable level. Note: The corresponding slapmPRMonControl BITS setting, enableSubcomponentTraps(3), MUST be selected in order for this notification to potentially be generated." ::= { slapmNotifications 12 } -- Conformance information -- Compliance statements slapmCompliances OBJECT IDENTIFIER ::= { slapmConformance 1 } slapmGroups OBJECT IDENTIFIER ::= { slapmConformance 2 } -- Compliance statements slapmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SLAPM-MIB." MODULE -- this module MANDATORY-GROUPS { slapmBaseGroup2, slapmNotGroup2 } GROUP slapmEndSystemGroup2 DESCRIPTION "The contents of this group is required by end-system implementations." GROUP slapmEndSystemNotGroup2 DESCRIPTION "The contents of this group is required by end-system implementations." GROUP slapmBaseGroup DESCRIPTION "The contents of this group has been deprecated in favor of the new slapmBaseGroup2. Older implementations of this MIB would continue its support of the contents of this group." GROUP slapmNotGroup DESCRIPTION "The contents of this group has been deprecated in favor of the new slapmNotGroup2. Older implementations of this MIB would continue its support of the contents of this group." GROUP slapmOptionalGroup DESCRIPTION "The contents of this group has been deprecated." White Experimental [Page 61] RFC 2758 SLAPM-MIB February 2000 GROUP slapmEndSystemGroup DESCRIPTION "The contents of this group has been deprecated in favor of the new slapmEndSystemGroup2. Older implementations of this MIB would continue its support of the contents of this group." GROUP slapmEndSystemNotGroup DESCRIPTION "The contents of this group has been deprecated in favor of the new slapmEndSystemNotGroup2. Older implementations of this MIB would continue its support of the contents of this group." ::= { slapmCompliances 1 } -- MIB groupings slapmBaseGroup OBJECT-GROUP OBJECTS { slapmSpinLock, slapmPolicyCountQueries, slapmPolicyCountAccesses, slapmPolicyCountSuccessAccesses, slapmPolicyCountNotFounds, slapmPolicyPurgeTime, slapmPolicyTrapEnable, slapmPolicyStatsOperStatus, slapmPolicyStatsActiveConns, slapmPolicyStatsFirstActivated, slapmPolicyStatsLastMapping, slapmPolicyStatsInOctets, slapmPolicyStatsOutOctets, slapmPolicyStatsConnectionLimit, slapmPolicyStatsTotalConns, slapmPolicyStatsCountAccepts, slapmPolicyStatsCountDenies, slapmPolicyStatsInDiscards, slapmPolicyStatsOutDiscards, slapmPolicyStatsInPackets, slapmPolicyStatsOutPackets, slapmPolicyStatsMinRate, slapmPolicyStatsMaxRate, slapmPolicyStatsMaxDelay, slapmPolicyMonitorControl, slapmPolicyMonitorStatus, slapmPolicyMonitorInterval, slapmPolicyMonitorIntTime, slapmPolicyMonitorCurrentInRate, slapmPolicyMonitorCurrentOutRate, White Experimental [Page 62] RFC 2758 SLAPM-MIB February 2000 slapmPolicyMonitorMinRateLow, slapmPolicyMonitorMinRateHigh, slapmPolicyMonitorMaxRateHigh, slapmPolicyMonitorMaxRateLow, slapmPolicyMonitorMaxDelayHigh, slapmPolicyMonitorMaxDelayLow, slapmPolicyMonitorMinInRateNotAchieves, slapmPolicyMonitorMaxInRateExceeds, slapmPolicyMonitorMaxDelayExceeds, slapmPolicyMonitorMinOutRateNotAchieves, slapmPolicyMonitorMaxOutRateExceeds, slapmPolicyMonitorCurrentDelayRate, slapmPolicyMonitorRowStatus } STATUS deprecated DESCRIPTION "The group of objects defined by this MIB that are required for all implementations to be compliant." ::= { slapmGroups 1 } slapmOptionalGroup OBJECT-GROUP OBJECTS { slapmPolicyStatsInProfileOctets, slapmPolicyStatsOutProfileOctets } STATUS deprecated DESCRIPTION "The group of objects defined by this MIB that are optional." ::= { slapmGroups 2 } slapmEndSystemGroup OBJECT-GROUP OBJECTS { slapmPolicyTrapFilter, slapmSubcomponentProtocol, slapmSubcomponentSystemAddress, slapmSubcomponentPolicyName, slapmSubcomponentTrafficProfileName, slapmSubcomponentLastActivity, slapmSubcomponentInOctets, slapmSubcomponentOutOctets, slapmSubcomponentTcpOutBufferedOctets, slapmSubcomponentTcpInBufferedOctets, slapmSubcomponentTcpReXmts, slapmSubcomponentTcpRoundTripTime, slapmSubcomponentTcpRoundTripVariance, slapmSubcomponentInPdus, slapmSubcomponentOutPdus, White Experimental [Page 63] RFC 2758 SLAPM-MIB February 2000 slapmSubcomponentApplName, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorIntTime, slapmSubcomponentMonitorCurrentOutRate, slapmSubcomponentMonitorCurrentInRate } STATUS deprecated DESCRIPTION "The group of objects defined by this MIB that are required for end system implementations." ::= { slapmGroups 3 } slapmNotGroup NOTIFICATION-GROUP NOTIFICATIONS { slapmMonitoredEventNotAchieved, slapmMonitoredEventOkay, slapmPolicyProfileDeleted, slapmPolicyMonitorDeleted } STATUS deprecated DESCRIPTION "The group of notifications defined by this MIB that MUST be implemented." ::= { slapmGroups 4 } slapmEndSystemNotGroup NOTIFICATION-GROUP NOTIFICATIONS { slapmSubcomponentMonitoredEventNotAchieved, slapmSubcomponentMonitoredEventOkay } STATUS deprecated DESCRIPTION "The group of objects defined by this MIB that are required for end system implementations." ::= { slapmGroups 5 } slapmBaseGroup2 OBJECT-GROUP OBJECTS { slapmSpinLock, slapmPolicyCountQueries, slapmPolicyCountAccesses, slapmPolicyCountSuccessAccesses, slapmPolicyCountNotFounds, slapmPolicyPurgeTime, slapmPolicyTrapEnable, slapmPolicyNameOfRule, slapmPolicyRuleStatsOperStatus, slapmPolicyRuleStatsActiveConns, White Experimental [Page 64] RFC 2758 SLAPM-MIB February 2000 slapmPolicyRuleStatsTotalConns, slapmPolicyRuleStatsLActivated, slapmPolicyRuleStatsLastMapping, slapmPolicyRuleStatsInOctets, slapmPolicyRuleStatsOutOctets, slapmPolicyRuleStatsConnLimit, slapmPolicyRuleStatsCountAccepts, slapmPolicyRuleStatsCountDenies, slapmPolicyRuleStatsInDiscards, slapmPolicyRuleStatsOutDiscards, slapmPolicyRuleStatsInPackets, slapmPolicyRuleStatsOutPackets, slapmPolicyRuleStatsInProOctets, slapmPolicyRuleStatsOutProOctets, slapmPolicyRuleStatsMinRate, slapmPolicyRuleStatsMaxRate, slapmPolicyRuleStatsMaxDelay, slapmPolicyRuleStatsTotalRsvpFlows, slapmPolicyRuleStatsActRsvpFlows, slapmPRMonControl, slapmPRMonStatus, slapmPRMonInterval, slapmPRMonIntTime, slapmPRMonCurrentInRate, slapmPRMonCurrentOutRate, slapmPRMonMinRateLow, slapmPRMonMinRateHigh, slapmPRMonMaxRateHigh, slapmPRMonMaxRateLow, slapmPRMonMaxDelayHigh, slapmPRMonMaxDelayLow, slapmPRMonMinInRateNotAchieves, slapmPRMonMaxInRateExceeds, slapmPRMonMaxDelayExceeds, slapmPRMonMinOutRateNotAchieves, slapmPRMonMaxOutRateExceeds, slapmPRMonCurrentDelayRate, slapmPRMonRowStatus } STATUS current DESCRIPTION "The group of objects defined by this MIB that are required for all implementations to be compliant." ::= { slapmGroups 6 } slapmEndSystemGroup2 OBJECT-GROUP OBJECTS { slapmPolicyTrapFilter, White Experimental [Page 65] RFC 2758 SLAPM-MIB February 2000 slapmSubcomponentProtocol, slapmSubcomponentSystemAddress, slapmSubcomponentLastActivity, slapmSubcomponentInOctets, slapmSubcomponentOutOctets, slapmSubcomponentTcpOutBufferedOctets, slapmSubcomponentTcpInBufferedOctets, slapmSubcomponentTcpReXmts, slapmSubcomponentTcpRoundTripTime, slapmSubcomponentTcpRoundTripVariance, slapmSubcomponentInPdus, slapmSubcomponentOutPdus, slapmSubcomponentApplName, slapmSubcomponentMonitorStatus, slapmSubcomponentMonitorIntTime, slapmSubcomponentMonitorCurrentOutRate, slapmSubcomponentMonitorCurrentInRate, slapmSubcomponentPolicyRuleIndex } STATUS current DESCRIPTION "The group of objects defined by this MIB that are required for end system implementations." ::= { slapmGroups 7 } slapmNotGroup2 NOTIFICATION-GROUP NOTIFICATIONS { slapmPolicyRuleMonNotOkay, slapmPolicyRuleMonOkay, slapmPolicyRuleDeleted, slapmPolicyRuleMonDeleted } STATUS current DESCRIPTION "The group of notifications defined by this MIB that MUST be implemented." ::= { slapmGroups 8 } slapmEndSystemNotGroup2 NOTIFICATION-GROUP NOTIFICATIONS { slapmSubcMonitorNotOkay, slapmSubcMonitorOkay } STATUS current DESCRIPTION "The group of objects defined by this MIB that are required for end system implementations." ::= { slapmGroups 9 } White Experimental [Page 66] RFC 2758 SLAPM-MIB February 2000 END 5.0 Security Considerations Certain management information in the MIB defined by this document may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. The method for this authentication is a function of the SNMP Administrative Framework, and has not been expanded by this MIB. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 2575 [11] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index" (refer to slapmPRMonOwnerIndex in an slapmPRMonEntry). Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control It is RECOMMENDED that the slapmPRMonTable (equivalent to the deprecated slapmPolicyMonitorTable) and the slapmSubcomponentTable not be supported in insecure environments. 6.0 Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of White Experimental [Page 67] RFC 2758 SLAPM-MIB February 2000 licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7.0 Acknowledgments This document is an individual submission and not the product of any IETF working group. Special thanks should be given to Robert Moore of IBM for his numerous reviews. 8.0 References [1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [2] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [6] Case, J., McCloghrie, K., Rose, M. and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [7] Harrington D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [8] Case, J., Harrington D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. White Experimental [Page 68] RFC 2758 SLAPM-MIB February 2000 [9] Levi D., Meyer P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [10] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [11] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [12] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [14] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [15] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [16] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [17] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [18] 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. [19] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2", RFC 2037, October 1996. [20] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. White Experimental [Page 69] RFC 2758 SLAPM-MIB February 2000 9.0 Author's Address Kenneth D. White Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA EMail: wkenneth@us.ibm.com White Experimental [Page 70] RFC 2758 SLAPM-MIB February 2000 10.0 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. White Experimental [Page 71] snmp-mibs-downloader-1.1/mibrfcs/rfc2786.txt0000644000000000000000000012442011402176071015573 0ustar Network Working Group M. St. Johns Request for Comments: 2786 Excite@Home Category: Experimental March 2000 Diffie-Helman USM Key Management Information Base and Textual Convention Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. IESG Note This document specifies an experimental MIB. Readers, implementers and users of this MIB should be aware that in the future the IETF may charter an IETF Working Group to develop a standards track MIB to address the same problem space that this MIB addresses. It is quite possible that an incompatible standards track MIB may result from that effort. Abstract 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 defines a textual convention for doing Diffie-Helman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of a DH key exchange in addition to the key change method described in [12]. In otherwords, this MIB adds the possibility of forward secrecy to the USM model. It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential. The KeyChange textual convention described in [12] permits secure key changes, but has the property that if a third-party has knowledge of the original key (e.g. if the agent was manufactured with a standard default key) and could capture all SNMP exchanges, the third-party would know the new key. The Diffie-Helman key change described here St. Johns Experimental [Page 1] RFC 2786 Diffie-Helman USM Key March 2000 limits knowledge of the new key to the agent and the manager making the change. In otherwords, this process adds forward secrecy to the key change process. The recommendation in [12] is that the usmUserTable be populated out of band - e.g. not via SNMP. If the number of agents to be configured is small, this can be done via a console port and manually. If the number of agents is large, as is the case for a cable modem system, the manual approach doesn't scale well. The combination of the two mechanisms specified here - the DH key change mechanism, and the DH key ignition mechanism - allows managable use of SNMPv3 USM in a system of millions of devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards and is intended for use with the SNMPv3 User Security Model MIB and other security related MIBs. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [16]. This memo is a private submission by the author, but is applicable to the SNMPv3 working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the the author. Table of Contents 1 The SNMP Management Framework ................................. 2 1.1 Structure of the MIB ........................................ 3 2 Theory of Operation ........................................... 4 2.1 Diffie-Helman Key Changes ................................... 4 2.2 Diffie-Helman Key Ignition .................................. 4 3 Definitions ................................................... 6 4 References .................................................... 17 5 Security Considerations ....................................... 18 6 Intellectual Property ......................................... 19 7 Author's Address .............................................. 19 8 Full Copyright Statement ...................................... 20 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD St. Johns Experimental [Page 2] RFC 2786 Diffie-Helman USM Key March 2000 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 1.1. Structure of the MIB This MIB is structured into three groups and a single textual convention: o The DHKeyChange textual convention defines the process for changing a secret key value via a Diffie-Helman key exchange. o The usmDHPublicObjects group contains a single object which describes the public Diffie-Helman parameters required by any instance of a DHKeyChange typed object. St. Johns Experimental [Page 3] RFC 2786 Diffie-Helman USM Key March 2000 o The usmDHUserKeyTable augments and extends the usmUserTable defined in the SNMPv3 User-based Security Model MIB [12] by providing objects which permit the updating of the Authentication and Privacy keys for a row in this table through the use of a Diffie-Helman key exchange. o The usmDHKickstartTable provides a mechanism for a management station to be able to agree upon a set of authentication and confidentiality keys and their associated row in the usmUserTable. 2. Theory of Operation 2.1. Diffie-Helman Key Changes Upon row creation (in the usmUserTable), or object change (either of the object in the usmDHUserKeyTable or its associated value in the usmUserTable), the agent generates a random number. From this random number, the agent uses the DH parameters and transforms to derive a DH public value which is then published to the associated MIB object. The management station reads one or more of the objects in the usmDHUserKeyTable to get the agent's DH public values. The management station generates a random number, derives a DH public value from that random number (as described in the DHKeyChange Textual Convention), and does an SNMP SET against the object in the usmDHUserKeyTable. The set consists of the concatenation of the agent's derived DH public value and the manager's derived DH public value (to ensure the DHKeyChange object hasn't otherwise changed in the meantime). Upon successful completion of the set, the underlying key (authentication or confidentiality) for the associated object in the usmUserTable is changed to a key derived from the DH shared secret. Both the agent and the management station are able to calculate this value based on their knowledge of their own random number and the other's DH public number. 2.2. Diffie-Helman Key Ignition [12] recommends that the usmUserTable be populated out of band, for example - manually. This works reasonably well if there are a small number of agents, or if all the agents are using the same key material, and if the device is physically accessible for that action. It does not scale very well to the case of possibly millions of devices located in thousands of locations in hundreds of markets in St. Johns Experimental [Page 4] RFC 2786 Diffie-Helman USM Key March 2000 multiple countries. In other words, it doesn't work well with a cable modem system, and may not work all that well with other large- scale consumer broadband IP offerings. The methods described in the objects under the usmDHKickstartGroup can be used to populate the usmUserTable in the circumstances where you may be able to provide at least limited integrity for the provisioning process, but you can't guarantee confidentiality. In addition, as a side effect of using the DH exchange, the operational USM keys for each agent will differ from the operational USM keys for every other device in the system, ensuring that compromise of one device does not compromise the system as a whole. The vendor who implements these objects is expected to provide one or more usmSecurityNames which map to a set of accesses defined in the VACM [15] tables. For example, the vendor may provide a 'root' user who has access to the entire device for read-write, and 'operator' user who has access to the network specific monitoring objects and can also reset the device, and a 'customer' user who has access to a subset of the monitoring objects which can be used to help the customer debug the device in conjunction with customer service questions. To use, the system manager (the organization or individual who own the group of devices) generates one or more random numbers - R. The manager derives the DH Public Numbers R' from these random numbers, associates the public numbers with a security name, and configures the agent with this association. The configuration would be done either manually (in the case of a small number of devices), or via some sort of distributed configuration file. The actual mechanism is outside the scope of this document. The agent in turn generates a random number for each name/number pair, and publishes the DH Public Number derived from its random number in the usmDHKickstartTable along with the manager's public number and provided security name. Once the agent is initialized, an SNMP Manager can read the contents of the usmDHKickstartTable using the security name of 'dhKickstart' with no authentication. The manager looks for one or more entries in this table where it knows the random number used to derive the usmDHKickstartMgrPublic number. Given the manager's knowledge of the private random number, and the usmDHKickstartMyPublic number, the manager can calculate the DH shared secret. From that shared secret, it can derive the operational authentication and confidentiality keys for the usmUserTable row which has the matching security name. Given the keys and the security name, the manager can then use normal USM mechanisms to access the remainder of the agent's MIB space. St. Johns Experimental [Page 5] RFC 2786 Diffie-Helman USM Key March 2000 3. Definitions SNMP-USM-DH-OBJECTS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, -- OBJECT-IDENTITY, experimental, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF usmUserEntry FROM SNMP-USER-BASED-SM-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; snmpUsmDHObjectsMIB MODULE-IDENTITY LAST-UPDATED "200003060000Z" -- 6 March 2000, Midnight ORGANIZATION "Excite@Home" CONTACT-INFO "Author: Mike StJohns Postal: Excite@Home 450 Broadway Redwood City, CA 94063 Email: stjohns@corp.home.net Phone: +1-650-556-5368" DESCRIPTION "The management information definitions for providing forward secrecy for key changes for the usmUserTable, and for providing a method for 'kickstarting' access to the agent via a Diffie-Helman key agreement." REVISION "200003060000Z" DESCRIPTION "Initial version published as RFC 2786." ::= { experimental 101 } -- IANA DHKEY-CHANGE 101 -- Administrative assignments usmDHKeyObjects OBJECT IDENTIFIER ::= { snmpUsmDHObjectsMIB 1 } usmDHKeyConformance OBJECT IDENTIFIER ::= { snmpUsmDHObjectsMIB 2 } -- Textual conventions St. Johns Experimental [Page 6] RFC 2786 Diffie-Helman USM Key March 2000 DHKeyChange ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Upon initialization, or upon creation of a row containing an object of this type, and after any successful SET of this value, a GET of this value returns 'y' where y = g^xa MOD p, and where g is the base from usmDHParameters, p is the prime from usmDHParameters, and xa is a new random integer selected by the agent in the interval 2^(l-1) <= xa < 2^l < p-1. 'l' is the optional privateValueLength from usmDHParameters in bits. If 'l' is omitted, then xa (and xr below) is selected in the interval 0 <= xa < p-1. y is expressed as an OCTET STRING 'PV' of length 'k' which satisfies k y = SUM 2^(8(k-i)) PV'i i=1 where PV1,...,PVk are the octets of PV from first to last, and where PV1 <> 0. A successful SET consists of the value 'y' expressed as an OCTET STRING as above concatenated with the value 'z'(expressed as an OCTET STRING in the same manner as y) where z = g^xr MOD p, where g, p and l are as above, and where xr is a new random integer selected by the manager in the interval 2^(l-1) <= xr < 2^l < p-1. A SET to an object of this type will fail with the error wrongValue if the current 'y' does not match the 'y' portion of the value of the varbind for the object. (E.g. GET yout, SET concat(yin, z), yout <> yin). Note that the private values xa and xr are never transmitted from manager to device or vice versa, only the values y and z. Obviously, these values must be retained until a successful SET on the associated object. The shared secret 'sk' is calculated at the agent as sk = z^xa MOD p, and at the manager as sk = y^xr MOD p. Each object definition of this type MUST describe how to map from the shared secret 'sk' to the operational key value used by the protocols and operations related to the object. In general, if n bits of key are required, the author suggests using the n right-most bits of the shared secret as the operational key value." REFERENCE "-- Diffie-Hellman Key-Agreement Standard, PKCS #3; RSA Laboratories, November 1993" SYNTAX OCTET STRING St. Johns Experimental [Page 7] RFC 2786 Diffie-Helman USM Key March 2000 -- Diffie Hellman public values usmDHPublicObjects OBJECT IDENTIFIER ::= { usmDHKeyObjects 1 } usmDHParameters OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "The public Diffie-Hellman parameters for doing a Diffie-Hellman key agreement for this device. This is encoded as an ASN.1 DHParameter per PKCS #3, section 9. E.g. DHParameter ::= SEQUENCE { prime INTEGER, -- p base INTEGER, -- g privateValueLength INTEGER OPTIONAL } Implementors are encouraged to use either the values from Oakley Group 1 or the values of from Oakley Group 2 as specified in RFC-2409, The Internet Key Exchange, Section 6.1, 6.2 as the default for this object. Other values may be used, but the security properties of those values MUST be well understood and MUST meet the requirements of PKCS #3 for the selection of Diffie-Hellman primes. In addition, any time usmDHParameters changes, all values of type DHKeyChange will change and new random numbers MUST be generated by the agent for each DHKeyChange object." REFERENCE "-- Diffie-Hellman Key-Agreement Standard, PKCS #3, RSA Laboratories, November 1993 -- The Internet Key Exchange, RFC 2409, November 1998, Sec 6.1, 6.2" ::= { usmDHPublicObjects 1 } usmDHUserKeyTable OBJECT-TYPE SYNTAX SEQUENCE OF UsmDHUserKeyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table augments and extends the usmUserTable and provides 4 objects which exactly mirror the objects in that table with the textual convention of 'KeyChange'. This extension allows key changes to be done in a manner where the knowledge of the current secret plus knowledge of the key change data exchanges (e.g. via wiretapping) will not reveal the new key." St. Johns Experimental [Page 8] RFC 2786 Diffie-Helman USM Key March 2000 ::= { usmDHPublicObjects 2 } usmDHUserKeyEntry OBJECT-TYPE SYNTAX UsmDHUserKeyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of DHKeyChange objects which augment or replace the functionality of the KeyChange objects in the base table row." AUGMENTS { usmUserEntry } ::= {usmDHUserKeyTable 1 } UsmDHUserKeyEntry ::= SEQUENCE { usmDHUserAuthKeyChange DHKeyChange, usmDHUserOwnAuthKeyChange DHKeyChange, usmDHUserPrivKeyChange DHKeyChange, usmDHUserOwnPrivKeyChange DHKeyChange } usmDHUserAuthKeyChange OBJECT-TYPE SYNTAX DHKeyChange MAX-ACCESS read-create STATUS current DESCRIPTION "The object used to change any given user's Authentication Key using a Diffie-Hellman key exchange. The right-most n bits of the shared secret 'sk', where 'n' is the number of bits required for the protocol defined by usmUserAuthProtocol, are installed as the operational authentication key for this row after a successful SET." ::= { usmDHUserKeyEntry 1 } usmDHUserOwnAuthKeyChange OBJECT-TYPE SYNTAX DHKeyChange MAX-ACCESS read-create STATUS current DESCRIPTION "The object used to change the agents own Authentication Key using a Diffie-Hellman key exchange. The right-most n bits of the shared secret 'sk', where 'n' is the number of bits required for the protocol defined by usmUserAuthProtocol, are installed as the operational authentication key for this row after a successful SET." ::= { usmDHUserKeyEntry 2 } usmDHUserPrivKeyChange OBJECT-TYPE St. Johns Experimental [Page 9] RFC 2786 Diffie-Helman USM Key March 2000 SYNTAX DHKeyChange MAX-ACCESS read-create STATUS current DESCRIPTION "The object used to change any given user's Privacy Key using a Diffie-Hellman key exchange. The right-most n bits of the shared secret 'sk', where 'n' is the number of bits required for the protocol defined by usmUserPrivProtocol, are installed as the operational privacy key for this row after a successful SET." ::= { usmDHUserKeyEntry 3 } usmDHUserOwnPrivKeyChange OBJECT-TYPE SYNTAX DHKeyChange MAX-ACCESS read-create STATUS current DESCRIPTION "The object used to change the agent's own Privacy Key using a Diffie-Hellman key exchange. The right-most n bits of the shared secret 'sk', where 'n' is the number of bits required for the protocol defined by usmUserPrivProtocol, are installed as the operational privacy key for this row after a successful SET." ::= { usmDHUserKeyEntry 4 } usmDHKickstartGroup OBJECT IDENTIFIER ::= { usmDHKeyObjects 2 } usmDHKickstartTable OBJECT-TYPE SYNTAX SEQUENCE OF UsmDHKickstartEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of mappings between zero or more Diffie-Helman key agreement values and entries in the usmUserTable. Entries in this table are created by providing the associated device with a Diffie-Helman public value and a usmUserName/usmUserSecurityName pair during initialization. How these values are provided is outside the scope of this MIB, but could be provided manually, or through a configuration file. Valid public value/name pairs result in the creation of a row in this table as well as the creation of an associated row (with keys derived as indicated) in the usmUserTable. The actual access the related usmSecurityName has is dependent on the entries in the VACM tables. In general, an implementor will specify one or more standard security names and will provide entries in the VACM tables granting various levels of access to those names. The actual content of the VACM St. Johns Experimental [Page 10] RFC 2786 Diffie-Helman USM Key March 2000 table is beyond the scope of this MIB. Note: This table is expected to be readable without authentication using the usmUserSecurityName 'dhKickstart'. See the conformance statements for details." ::= { usmDHKickstartGroup 1 } usmDHKickstartEntry OBJECT-TYPE SYNTAX UsmDHKickstartEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the usmDHKickstartTable. The agent SHOULD either delete this entry or mark it as inactive upon a successful SET of any of the KeyChange-typed objects in the usmUserEntry or upon a successful SET of any of the DHKeyChange-typed objects in the usmDhKeyChangeEntry where the related usmSecurityName (e.g. row of usmUserTable or row of ushDhKeyChangeTable) equals this entry's usmDhKickstartSecurityName. In otherwords, once you've changed one or more of the keys for a row in usmUserTable with a particular security name, the row in this table with that same security name is no longer useful or meaningful." INDEX { usmDHKickstartIndex } ::= {usmDHKickstartTable 1 } UsmDHKickstartEntry ::= SEQUENCE { usmDHKickstartIndex Integer32, usmDHKickstartMyPublic OCTET STRING, usmDHKickstartMgrPublic OCTET STRING, usmDHKickstartSecurityName SnmpAdminString } usmDHKickstartIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index value for this row." ::= { usmDHKickstartEntry 1 } usmDHKickstartMyPublic OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The agent's Diffie-Hellman public value for this row. At St. Johns Experimental [Page 11] RFC 2786 Diffie-Helman USM Key March 2000 initialization, the agent generates a random number and derives its public value from that number. This public value is published here. This public value 'y' equals g^r MOD p where g is the from the set of Diffie-Hellman parameters, p is the prime from those parameters, and r is a random integer selected by the agent in the interval 2^(l-1) <= r < p-1 < 2^l. If l is unspecified, then r is a random integer selected in the interval 0 <= r < p-1 The public value is expressed as an OCTET STRING 'PV' of length 'k' which satisfies k y = SUM 2^(8(k-i)) PV'i i = 1 where PV1,...,PVk are the octets of PV from first to last, and where PV1 != 0. The following DH parameters (Oakley group #2, RFC 2409, sec 6.1, 6.2) are used for this object: g = 2 p = FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF l=1024 " REFERENCE "-- Diffie-Hellman Key-Agreement Standard, PKCS#3v1.4; RSA Laboratories, November 1993 -- The Internet Key Exchange, RFC2409; Harkins, D., Carrel, D.; November 1998" ::= { usmDHKickstartEntry 2 } usmDHKickstartMgrPublic OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The manager's Diffie-Hellman public value for this row. Note that this value is not set via the SNMP agent, but may be set via some out of band method, such as the device's configuration file. St. Johns Experimental [Page 12] RFC 2786 Diffie-Helman USM Key March 2000 The manager calculates this value in the same manner and using the same parameter set as the agent does. E.g. it selects a random number 'r', calculates y = g^r mod p and provides 'y' as the public number expressed as an OCTET STRING. See usmDHKickstartMyPublic for details. When this object is set with a valid value during initialization, a row is created in the usmUserTable with the following values: usmUserEngineID localEngineID usmUserName [value of usmDHKickstartSecurityName] usmUserSecurityName [value of usmDHKickstartSecurityName] usmUserCloneFrom ZeroDotZero usmUserAuthProtocol usmHMACMD5AuthProtocol usmUserAuthKeyChange -- derived from set value usmUserOwnAuthKeyChange -- derived from set value usmUserPrivProtocol usmDESPrivProtocol usmUserPrivKeyChange -- derived from set value usmUserOwnPrivKeyChange -- derived from set value usmUserPublic '' usmUserStorageType permanent usmUserStatus active A shared secret 'sk' is calculated at the agent as sk = mgrPublic^r mod p where r is the agents random number and p is the DH prime from the common parameters. The underlying privacy key for this row is derived from sk by applying the key derivation function PBKDF2 defined in PKCS#5v2.0 with a salt of 0xd1310ba6, and iterationCount of 500, a keyLength of 16 (for usmDESPrivProtocol), and a prf (pseudo random function) of 'id-hmacWithSHA1'. The underlying authentication key for this row is derived from sk by applying the key derivation function PBKDF2 with a salt of 0x98dfb5ac , an interation count of 500, a keyLength of 16 (for usmHMAC5AuthProtocol), and a prf of 'id-hmacWithSHA1'. Note: The salts are the first two words in the ks0 [key schedule 0] of the BLOWFISH cipher from 'Applied Cryptography' by Bruce Schnier - they could be any relatively random string of bits. The manager can use its knowledge of its own random number and the agent's public value to kickstart its access to the agent in a secure manner. Note that the security of this approach is directly related to the strength of the authorization security of the out of band provisioning of the managers public value (e.g. the configuration file), but is not dependent at all on the strength of the confidentiality of the out of band provisioning data." REFERENCE St. Johns Experimental [Page 13] RFC 2786 Diffie-Helman USM Key March 2000 "-- Password-Based Cryptography Standard, PKCS#5v2.0; RSA Laboratories, March 1999 -- Applied Cryptography, 2nd Ed.; B. Schneier, Counterpane Systems; John Wiley & Sons, 1996" ::= { usmDHKickstartEntry 3 } usmDHKickstartSecurityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The usmUserName and usmUserSecurityName in the usmUserTable associated with this row. This is provided in the same manner and at the same time as the usmDHKickstartMgrPublic value - e.g. possibly manually, or via the device's configuration file." ::= { usmDHKickstartEntry 4 } -- Conformance Information usmDHKeyMIBCompliances OBJECT IDENTIFIER ::= { usmDHKeyConformance 1 } usmDHKeyMIBGroups OBJECT IDENTIFIER ::= { usmDHKeyConformance 2 } -- Compliance statements usmDHKeyMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for this module." MODULE GROUP usmDHKeyMIBBasicGroup DESCRIPTION "This group MAY be implemented by any agent which implements the usmUserTable and which wishes to provide the ability to change user and agent authentication and privacy keys via Diffie-Hellman key exchanges." GROUP usmDHKeyParamGroup DESCRIPTION "This group MUST be implemented by any agent which implements a MIB containing the DHKeyChange Textual Convention defined in this module." GROUP usmDHKeyKickstartGroup DESCRIPTION "This group MAY be implemented by any agent which implements the usmUserTable and which wishes the ability to populate the USM table based on out-of-band provided DH ignition values. St. Johns Experimental [Page 14] RFC 2786 Diffie-Helman USM Key March 2000 Any agent implementing this group is expected to provide preinstalled entries in the vacm tables as follows: In the usmUserTable: This entry allows access to the system and dhKickstart groups usmUserEngineID localEngineID usmUserName 'dhKickstart' usmUserSecurityName 'dhKickstart' usmUserCloneFrom ZeroDotZero usmUserAuthProtocol none usmUserAuthKeyChange '' usmUserOwnAuthKeyChange '' usmUserPrivProtocol none usmUserPrivKeyChange '' usmUserOwnPrivKeyChange '' usmUserPublic '' usmUserStorageType permanent usmUserStatus active In the vacmSecurityToGroupTable: This maps the initial user into the accessible objects. vacmSecurityModel 3 (USM) vacmSecurityName 'dhKickstart' vacmGroupName 'dhKickstart' vacmSecurityToGroupStorageType permanent vacmSecurityToGroupStatus active In the vacmAccessTable: Group name to view name translation. vacmGroupName 'dhKickstart' vacmAccessContextPrefix '' vacmAccessSecurityModel 3 (USM) vacmAccessSecurityLevel noAuthNoPriv vacmAccessContextMatch exact vacmAccessReadViewName 'dhKickRestricted' vacmAccessWriteViewName '' vacmAccessNotifyViewName 'dhKickRestricted' vacmAccessStorageType permanent vacmAccessStatus active In the vacmViewTreeFamilyTable: Two entries to allow the initial entry to access the system and kickstart groups. vacmViewTreeFamilyViewName 'dhKickRestricted' vacmViewTreeFamilySubtree 1.3.6.1.2.1.1 (system) vacmViewTreeFamilyMask '' St. Johns Experimental [Page 15] RFC 2786 Diffie-Helman USM Key March 2000 vacmViewTreeFamilyType 1 vacmViewTreeFamilyStorageType permanent vacmViewTreeFamilyStatus active vacmViewTreeFamilyViewName 'dhKickRestricted' vacmViewTreeFamilySubtree (usmDHKickstartTable OID) vacmViewTreeFamilyMask '' vacmViewTreeFamilyType 1 vacmViewTreeFamilyStorageType permanent vacmViewTreeFamilyStatus active " OBJECT usmDHParameters MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only for any device." ::= { usmDHKeyMIBCompliances 1 } -- Units of Compliance usmDHKeyMIBBasicGroup OBJECT-GROUP OBJECTS { usmDHUserAuthKeyChange, usmDHUserOwnAuthKeyChange, usmDHUserPrivKeyChange, usmDHUserOwnPrivKeyChange } STATUS current DESCRIPTION "" ::= { usmDHKeyMIBGroups 1 } usmDHKeyParamGroup OBJECT-GROUP OBJECTS { usmDHParameters } STATUS current DESCRIPTION "The mandatory object for all MIBs which use the DHKeyChange textual convention." ::= { usmDHKeyMIBGroups 2 } usmDHKeyKickstartGroup OBJECT-GROUP OBJECTS { usmDHKickstartMyPublic, usmDHKickstartMgrPublic, St. Johns Experimental [Page 16] RFC 2786 Diffie-Helman USM Key March 2000 usmDHKickstartSecurityName } STATUS current DESCRIPTION "The objects used for kickstarting one or more SNMPv3 USM associations via a configuration file or other out of band, non-confidential access." ::= { usmDHKeyMIBGroups 3 } END 4. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. St. Johns Experimental [Page 17] RFC 2786 Diffie-Helman USM Key March 2000 [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [17] "Diffie-Hellman Key-Agreement Standard, Version 1.4", PKCS #3, RSA Laboratories, November 1993. [18] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1988. [19] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. 5. Security Considerations Objects in the usmDHUserKeyTable should be considered to have the same security sensitivity as the objects of the KeyChange type in usmUserTable and should be afforded the same level of protection. Specifically, the VACM should not grant more or less access to these objects than it grants to the usmUserTable KeyChange object. The improper selection of parameters for use with Diffie-Hellman key changes may adversely affect the security of the agent. Please see the body of the MIB for specific recommendations or requirements on the selection of the DH parameters. St. Johns Experimental [Page 18] RFC 2786 Diffie-Helman USM Key March 2000 An unauthenticated DH exchange is subject to "man-in-the-middle" attacks. The use of the DH exchange in any specific environment should balance risk versus threat. Good security from a DH exchange requires a good source of random numbers. If your application cannot provide a reasonable source of randomness, do not use a DH exchange. For more information, see "Randomness Recommendations for Security" [19]. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Author's Address Michael C. StJohns Excite@Home 450 Broadway Redwood City, CA 94063 USA Phone: +1-650-556-5368 EMail: stjohns@corp.home.net St. Johns Experimental [Page 19] RFC 2786 Diffie-Helman USM Key March 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. St. Johns Experimental [Page 20] snmp-mibs-downloader-1.1/mibrfcs/rfc2787.txt0000644000000000000000000015654011402176071015604 0ustar Network Working Group B. Jewell Request for Comments: 2787 Copper Mountain Networks, Inc. Category: Standards Track D. Chuang CoSine Communications March 2000 Definitions of Managed Objects for the Virtual Router Redundancy Protocol 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [17]. This memo specifies a MIB module in a manner that is compliant with SMIv2 [5], and semantically identical to the SMIv1 definitions [2]. Jewell & Chuang Standards Track [Page 1] RFC 2787 VRRP MIB Management Objects March 2000 Table of Contents 1 The SNMP Network Management Framework ................. 2 2 Overview .............................................. 3 2.1 VRRP MIB Structure .................................. 3 2.2 Virtual Router Redundancy Protocol .................. 4 2.3 VRRP MIB Table Design ............................... 4 2.3.1 Relation to Interface Group ....................... 5 2.4 VRRP Scenarios ...................................... 5 2.4.1 Scenario #1 ....................................... 5 2.4.2 Scenario #2 ....................................... 8 3 Definitions ........................................... 11 4 Security Considerations ............................... 27 5 Acknowledgements ...................................... 28 6 References ............................................ 28 7 Authors' Addresses .................................... 30 8 Intellectual Property Statement........................ 30 9 Full Copyright Statement............................... 31 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. Jewell & Chuang Standards Track [Page 2] RFC 2787 VRRP MIB Management Objects March 2000 o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview This memo identifies the set of objects for configuring, monitoring, and controlling the Virtual Router Redundancy Protocol (VRRP), as defined in RFC 2338 [17]. VRRP specifies an election protocol that will allow one or more associated IP addresses to be assumed by another router in the event of a failure of the IP address(es) owner. Thus, IP traffic from a host using a failed router as a default gateway is transparently fowarded by the VRRP router that has assumed control. VRRP provides redundancy in routed networks without requiring configuration of dynamic routing or router discovery protocols on every end-host. Since the VRRP protocol is intended for use with IPv4 routers only, this MIB uses the SYNTAX for IP addresses which is specific to IPv4. Thus, changes will be required for this MIB to interoperate in an IPv6 environment. 2.1. VRRP MIB Structure The VRRP MIB contains three conformance groups: - vrrpOperations Group: Objects related to VRRP router's configuration and control. - vrrpStatistics Group: Objects containing information useful in monitoring the operation of VRRP routers. Jewell & Chuang Standards Track [Page 3] RFC 2787 VRRP MIB Management Objects March 2000 - vrrpNotifications Group: Consists of objects and definitions for use in SNMP notifications sent by VRRP routers. Tables in the MIB include the following: (1) The vrrpOperTable, which contains objects that define the operational characteristics of a VRRP router. Rows in this table correspond to instances of virtual routers. (2) The vrrpAssoIpAddrTable, which contains the addresses of the virtual router(s) that a given VRRP router is backing up. (3) The vrrpRouterStatsTable which contains the operating statistics for a VRRP router. 2.2. Virtual Router Redundancy Protocol This MIB is based on the following characteristics of VRRP as defined in the VRRP specification [17]. - A "VRRP router" is one that is configured to run the VRRP protocol in conjunction with one or more other VRRP routers attached to a LAN. - A VRRP router can be running one or more instances of a virtual router. - A "virtual router" is an abstraction which consists of two or more physical routers associated by a Virtual Router Identifier (VRID). - An instance of a virtual router (on a physical VRRP router), can be uniquely identified by a combination of the 'ifIndex' [18] and "Virtual Router Identifier" (VRID). - For each VRID there is a set of one or more "associated IP addresses" that are backed-up by the virtual router. 2.3. VRRP MIB Table Design The tables in the VRRP MIB are structured with the assumption that a VRRP network management application would likely be designed to display information or provide configuration about a VRRP router on a "per-virtual-router basis". Thus, the tables defined in the MIB consist of conceptual rows which are grouped in a manner to present a view of individual virtual routers with a minimal number of SNMP operations. Jewell & Chuang Standards Track [Page 4] RFC 2787 VRRP MIB Management Objects March 2000 2.3.1. Relation to Interface Group (RFC 2233) [18]. Since a router can be participating in VRRP on one or more physical interfaces, "ifIndex" is used as an index into the tables defined in the VRRP MIB. 2.4. VRRP Scenarios The following section provides examples of how some of the objects in this MIB are instantiated for two different VRRP scenarios. KEY: ---- The labels in the following tables and diagrams correspond to the actual MIB objects as follows: if = vrrpOperIfIndex VrId = vrrpOperVrId State = vrrpOperState Prior = vrrpOperPriority AddrCnt = vrrpOperIpAddrCount IpAddr = vrrpOperMasterIpAddr RowStat = vrrpOperRowStatus 2.4.1. VRRP Scenario #1 The following figure shows a simple network with two VRRP routers configured with two virtual routers. This sample topology is taken from the VRRP specification [17]. Addresses in '()' indicate the IP address of the default gateway for a given host, H1 - H4. In the diagram, "Interface" is used in the context defined in IF-MIB [18]. Jewell & Chuang Standards Track [Page 5] RFC 2787 VRRP MIB Management Objects March 2000 VRID=1 VRID=2 +-----+ +-----+ | MR1 | | MR2 | | & | | & | | BR2 | | BR1 | +-----+ +-----+ IP A ---------->* *<---------- IP B Interface=I1 | | Interface=I2 | | | | ------------------+------------+-----+--------+--------+--------+-- ^ ^ ^ ^ | | | | (IP A) (IP A) (IP A) (IP A) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1 | | H2 | | H3 | | H4 | +-----+ +-----+ +--+--+ +--+--+ ----- MIB Tables For VRRP Router "IP A": ----- vrrpOperTable ------------- | if | VrId | State | Prior | AddrCnt | IpAddr | ... | RowStat | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I1 | 01 | M | 255 | 1 | A | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I1 | 02 | B | 1-254 | 1 | B | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ Jewell & Chuang Standards Track [Page 6] RFC 2787 VRRP MIB Management Objects March 2000 vrrpAssoIpAddrTable ------------------- | if | VrId | IP | RowStat | +----+------+-------+---------+ | | | | | | I1 | 01 | A | active | | | | | | +----+------+-------+---------+ | | | | | | I1 | 02 | B | active | | | | | | +----+------+-------+---------+ ----- MIB Tables For VRRP Router "IP B": ----- vrrpOperTable ------------- | if | VrId | State | Prior | AddrCnt | IpAddr | ... | RowStat | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I2 | 01 | B | 1-254 | 1 | A | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I2 | 02 | M | 255 | 1 | B | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ vrrpAssoIpAddrTable ------------------- | if | VrId | IP | RowStat | +----+------+-------+---------+ | | | | | | I2 | 01 | A | active | | | | | | +----+------+-------+---------+ | | | | | | I2 | 02 | B | active | | | | | | +----+------+-------+---------+ Jewell & Chuang Standards Track [Page 7] RFC 2787 VRRP MIB Management Objects March 2000 NOTES: 1) "I1" and "I2" are used to designate IF indices on each respective router. 2) For "State": M = Master; B = Backup. 3) In the vrrpOperTable, a "priority" of 255 indicates that the respective router owns the IP address, e.g., this IP address is native to the router (i.e., "the IP Address Owner" [17]). 2.4.2. VRRP Scenario #2 The following figure shows a simple network with two virtual routers. Here, a single interface has been configured with two IP addresses. Again, addresses in () indicate the IP address of the default gateway for a given host, H1 - H2. VRID=1 VRID=2 +-----+ +-----+ | MR1 | | MR2 | | & | | & | | BR2 | | BR1 | +-----+ +-----+ IP A ---------->* *<---------- IP B IP C | | Interface=I2 Interface=I1 | | | | | | ------------------+------------+-----+--------+ ^ ^ | | (IP A) (IP B) | | +--+--+ +--+--+ | H1 | | H2 | +-----+ +-----+ Jewell & Chuang Standards Track [Page 8] RFC 2787 VRRP MIB Management Objects March 2000 ----- MIB Tables For VRRP Router "IP A": ----- vrrpOperTable ------------- | if | VrId | State | Prior | AddrCnt | IpAddr | ... | RowStat | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I1 | 01 | M | 255 | 2 | A | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I1 | 02 | B | 1-254 | 1 | B | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ vrrpAssoIpAddrTable ------------------- | if | VrId | IP | RowStat | +----+------+-------+---------+ | | | | | | I1 | 01 | A | active | | | | | | +----+------+-------+---------+ | | | | | | I1 | 01 | C | active | | | | | | +----+------+-------+---------+ | | | | | | I1 | 02 | B | active | | | | | | +----+------+-------+---------+ Jewell & Chuang Standards Track [Page 9] RFC 2787 VRRP MIB Management Objects March 2000 ----- MIB Tables For VRRP Router "IP B": ----- vrrpOperTable ------------- | if | VrId | State | Prior | AddrCnt | IpAddr | ... | RowStat | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I2 | 01 | B | 1-254 | 2 | A | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ | | | | | | | | | | I2 | 02 | M | 255 | 1 | B | | active | | | | | | | | | | +----+------+-------+-------+---------+--------+-( )-+---------+ vrrpAssoIpAddrTable ------------------- | if | VrId | IP | RowStat | +----+------+-------+---------+ | | | | | | I2 | 01 | A | active | | | | | | +----+------+-------+---------+ | | | | | | I2 | 01 | C | active | | | | | | +----+------+-------+---------+ | | | | | | I2 | 02 | B | active | | | | | | +----+------+-------+---------+ Jewell & Chuang Standards Track [Page 10] RFC 2787 VRRP MIB Management Objects March 2000 3. Definitions VRRP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, IpAddress, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, MacAddress, TruthValue, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB; vrrpMIB MODULE-IDENTITY LAST-UPDATED "200003030000Z" ORGANIZATION "IETF VRRP Working Group" CONTACT-INFO "Brian R. Jewell Postal: Copper Mountain Networks, Inc. 2470 Embarcadero Way Palo Alto, California 94303 Tel: +1 650 687 3367 E-Mail: bjewell@coppermountain.com" DESCRIPTION "This MIB describes objects used for managing Virtual Router Redundancy Protocol (VRRP) routers." REVISION "200003030000Z" -- 03 Mar 2000 DESCRIPTION "Initial version as published in RFC 2787." ::= { mib-2 68 } -- ******************************************************************* -- Textual Conventions -- ******************************************************************* VrId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A number which, along with an interface index (ifIndex), serves to uniquely identify a virtual router on a given VRRP router. A set of one or more associated addresses is assigned to a VRID." SYNTAX Integer32 (1..255) Jewell & Chuang Standards Track [Page 11] RFC 2787 VRRP MIB Management Objects March 2000 -- ******************************************************************* -- VRRP MIB Groups -- ******************************************************************* vrrpOperations OBJECT IDENTIFIER ::= { vrrpMIB 1 } vrrpStatistics OBJECT IDENTIFIER ::= { vrrpMIB 2 } vrrpConformance OBJECT IDENTIFIER ::= { vrrpMIB 3 } -- ******************************************************************* -- Start of MIB objects -- ******************************************************************* vrrpNodeVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the particular version of the VRRP supported by this node." ::= { vrrpOperations 1 } vrrpNotificationCntl OBJECT-TYPE SYNTAX INTEGER { enabled (1), disabled (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the VRRP-enabled router will generate SNMP traps for events defined in this MIB. 'Enabled' results in SNMP traps; 'disabled', no traps are sent." DEFVAL { enabled } ::= { vrrpOperations 2 } -- ******************************************************************* -- VRRP Operations Table -- ******************************************************************* vrrpOperTable OBJECT-TYPE SYNTAX SEQUENCE OF VrrpOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Operations table for a VRRP router which consists of a sequence (i.e., one or more conceptual rows) of 'vrrpOperEntry' items." Jewell & Chuang Standards Track [Page 12] RFC 2787 VRRP MIB Management Objects March 2000 ::= { vrrpOperations 3 } vrrpOperEntry OBJECT-TYPE SYNTAX VrrpOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vrrpOperTable containing the operational characteristics of a virtual router. On a VRRP router, a given virtual router is identified by a combination of the IF index and VRID. Rows in the table cannot be modified unless the value of `vrrpOperAdminState' is `disabled' and the `vrrpOperState' has transitioned to `initialize'." INDEX { ifIndex, vrrpOperVrId } ::= { vrrpOperTable 1 } VrrpOperEntry ::= SEQUENCE { vrrpOperVrId VrId, vrrpOperVirtualMacAddr MacAddress, vrrpOperState INTEGER, vrrpOperAdminState INTEGER, vrrpOperPriority Integer32, vrrpOperIpAddrCount Integer32, vrrpOperMasterIpAddr IpAddress, vrrpOperPrimaryIpAddr IpAddress, vrrpOperAuthType INTEGER, vrrpOperAuthKey OCTET STRING, vrrpOperAdvertisementInterval Integer32, vrrpOperPreemptMode TruthValue, vrrpOperVirtualRouterUpTime TimeStamp, vrrpOperProtocol Jewell & Chuang Standards Track [Page 13] RFC 2787 VRRP MIB Management Objects March 2000 INTEGER, vrrpOperRowStatus RowStatus } vrrpOperVrId OBJECT-TYPE SYNTAX VrId MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains the Virtual Router Identifier (VRID)." ::= { vrrpOperEntry 1 } vrrpOperVirtualMacAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The virtual MAC address of the virtual router. Although this object can be derived from the 'vrrpOperVrId' object, it is defined so that it is easily obtainable by a management application and can be included in VRRP-related SNMP traps." ::= { vrrpOperEntry 2 } vrrpOperState OBJECT-TYPE SYNTAX INTEGER { initialize(1), backup(2), master(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the virtual router. This object has three defined values: - `initialize', which indicates that all the virtual router is waiting for a startup event. - `backup', which indicates the virtual router is monitoring the availability of the master router. - `master', which indicates that the virtual router is forwarding packets for IP addresses that are associated with this router. Setting the `vrrpOperAdminState' object (below) initiates Jewell & Chuang Standards Track [Page 14] RFC 2787 VRRP MIB Management Objects March 2000 transitions in the value of this object." ::= { vrrpOperEntry 3 } vrrpOperAdminState OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object will enable/disable the virtual router function. Setting the value to `up', will transition the state of the virtual router from `initialize' to `backup' or `master', depending on the value of `vrrpOperPriority'. Setting the value to `down', will transition the router from `master' or `backup' to `initialize'. State transitions may not be immediate; they sometimes depend on other factors, such as the interface (IF) state. The `vrrpOperAdminState' object must be set to `down' prior to modifying the other read-create objects in the conceptual row. The value of the `vrrpOperRowStatus' object (below) must be `active', signifying that the conceptual row is valid (i.e., the objects are correctly set), in order for this object to be set to `up'." DEFVAL { down } ::= { vrrpOperEntry 4 } vrrpOperPriority OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the priority to be used for the virtual router master election process. Higher values imply higher priority. A priority of '0', although not settable, is sent by the master router to indicate that this router has ceased to participate in VRRP and a backup virtual router should transition to become a new master. A priority of 255 is used for the router that owns the associated IP address(es)." DEFVAL { 100 } ::= { vrrpOperEntry 5 } Jewell & Chuang Standards Track [Page 15] RFC 2787 VRRP MIB Management Objects March 2000 vrrpOperIpAddrCount OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP addresses that are associated with this virtual router. This number is equal to the number of rows in the vrrpAssoIpAddrTable that correspond to a given IF index/VRID pair." ::= { vrrpOperEntry 6 } vrrpOperMasterIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The master router's real (primary) IP address. This is the IP address listed as the source in VRRP advertisement last received by this virtual router." ::= { vrrpOperEntry 7 } vrrpOperPrimaryIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "In the case where there is more than one IP address for a given `ifIndex', this object is used to specify the IP address that will become the `vrrpOperMasterIpAddr', should the virtual router transition from backup to master. If this object is set to 0.0.0.0, the IP address which is numerically lowest will be selected." DEFVAL { '00000000'H } -- 0.0.0.0 ::= { vrrpOperEntry 8 } vrrpOperAuthType OBJECT-TYPE SYNTAX INTEGER { noAuthentication(1), -- VRRP protocol exchanges are not -- authenticated. simpleTextPassword(2), -- Exchanges are authenticated by a -- clear text password. ipAuthenticationHeader(3) -- Exchanges are authenticated using -- the IP authentication header. } MAX-ACCESS read-create STATUS current DESCRIPTION Jewell & Chuang Standards Track [Page 16] RFC 2787 VRRP MIB Management Objects March 2000 "Authentication type used for VRRP protocol exchanges between virtual routers. This value of this object is the same for a given ifIndex. New enumerations to this list can only be added via a new RFC on the standards track." DEFVAL { noAuthentication } ::= { vrrpOperEntry 9 } vrrpOperAuthKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The Authentication Key. This object is set according to the value of the 'vrrpOperAuthType' object ('simpleTextPassword' or 'ipAuthenticationHeader'). If the length of the value is less than 16 octets, the agent will left adjust and zero fill to 16 octets. The value of this object is the same for a given ifIndex. When read, vrrpOperAuthKey always returns an Octet String of length zero." ::= { vrrpOperEntry 10 } vrrpOperAdvertisementInterval OBJECT-TYPE SYNTAX Integer32 (1..255) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time interval, in seconds, between sending advertisement messages. Only the master router sends VRRP advertisements." DEFVAL { 1 } ::= { vrrpOperEntry 11 } vrrpOperPreemptMode OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Controls whether a higher priority virtual router will preempt a lower priority master." DEFVAL { true } ::= { vrrpOperEntry 12 } vrrpOperVirtualRouterUpTime OBJECT-TYPE Jewell & Chuang Standards Track [Page 17] RFC 2787 VRRP MIB Management Objects March 2000 SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This is the value of the `sysUpTime' object when this virtual router (i.e., the `vrrpOperState') transitioned out of `initialized'." ::= { vrrpOperEntry 13 } vrrpOperProtocol OBJECT-TYPE SYNTAX INTEGER { ip (1), bridge (2), decnet (3), other (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The particular protocol being controlled by this Virtual Router. New enumerations to this list can only be added via a new RFC on the standards track." DEFVAL { ip } ::= { vrrpOperEntry 14 } vrrpOperRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status variable, used in accordance to installation and removal conventions for conceptual rows. The rowstatus of a currently active row in the vrrpOperTable is constrained by the operational state of the corresponding virtual router. When `vrrpOperRowStatus' is set to active(1), no other objects in the conceptual row, with the exception of `vrrpOperAdminState', can be modified. Prior to setting the `vrrpOperRowStatus' object from `active' to a different value, the `vrrpOperAdminState' object must be set to `down' and the `vrrpOperState' object be transitioned to `initialize'. To create a row in this table, a manager sets this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the `vrrpOperRowStatus' column will be read as notReady(3). Jewell & Chuang Standards Track [Page 18] RFC 2787 VRRP MIB Management Objects March 2000 In particular, a newly created row cannot be made active(1) until (minimally) the corresponding instance of `vrrpOperVrId' has been set and there is at least one active row in the `vrrpAssoIpAddrTable' defining an associated IP address for the virtual router." ::= { vrrpOperEntry 15 } -- ******************************************************************* -- VRRP Associated IP Address Table -- ******************************************************************* vrrpAssoIpAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF VrrpAssoIpAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of addresses associated with this virtual router." ::= { vrrpOperations 4 } vrrpAssoIpAddrEntry OBJECT-TYPE SYNTAX VrrpAssoIpAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table contains an IP address that is associated with a virtual router. The number of rows for a given ifIndex and VrId will equal the number of IP addresses associated (e.g., backed up) by the virtual router (equivalent to 'vrrpOperIpAddrCount'). Rows in the table cannot be modified unless the value of `vrrpOperAdminState' is `disabled' and the `vrrpOperState' has transitioned to `initialize'." INDEX { ifIndex, vrrpOperVrId, vrrpAssoIpAddr } ::= { vrrpAssoIpAddrTable 1 } VrrpAssoIpAddrEntry ::= SEQUENCE { vrrpAssoIpAddr IpAddress, vrrpAssoIpAddrRowStatus RowStatus } vrrpAssoIpAddr OBJECT-TYPE SYNTAX IpAddress Jewell & Chuang Standards Track [Page 19] RFC 2787 VRRP MIB Management Objects March 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The assigned IP addresses that a virtual router is responsible for backing up." ::= { vrrpAssoIpAddrEntry 1 } vrrpAssoIpAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status variable, used according to installation and removal conventions for conceptual rows. Setting this object to active(1) or createAndGo(4) results in the addition of an associated address for a virtual router. Destroying the entry or setting it to notInService(2) removes the associated address from the virtual router. The use of other values is implementation-dependent." ::= { vrrpAssoIpAddrEntry 2 } -- ******************************************************************* -- VRRP Router Statistics -- ******************************************************************* vrrpRouterChecksumErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of VRRP packets received with an invalid VRRP checksum value." ::= { vrrpStatistics 1 } vrrpRouterVersionErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of VRRP packets received with an unknown or unsupported version number." ::= { vrrpStatistics 2 } vrrpRouterVrIdErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Jewell & Chuang Standards Track [Page 20] RFC 2787 VRRP MIB Management Objects March 2000 DESCRIPTION "The total number of VRRP packets received with an invalid VRID for this virtual router." ::= { vrrpStatistics 3 } -- ******************************************************************* -- VRRP Router Statistics Table -- ******************************************************************* vrrpRouterStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF VrrpRouterStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of virtual router statistics." ::= { vrrpStatistics 4 } vrrpRouterStatsEntry OBJECT-TYPE SYNTAX VrrpRouterStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing statistics information about a given virtual router." AUGMENTS { vrrpOperEntry } ::= { vrrpRouterStatsTable 1 } VrrpRouterStatsEntry ::= SEQUENCE { vrrpStatsBecomeMaster Counter32, vrrpStatsAdvertiseRcvd Counter32, vrrpStatsAdvertiseIntervalErrors Counter32, vrrpStatsAuthFailures Counter32, vrrpStatsIpTtlErrors Counter32, vrrpStatsPriorityZeroPktsRcvd Counter32, vrrpStatsPriorityZeroPktsSent Counter32, vrrpStatsInvalidTypePktsRcvd Counter32, vrrpStatsAddressListErrors Counter32, vrrpStatsInvalidAuthType Jewell & Chuang Standards Track [Page 21] RFC 2787 VRRP MIB Management Objects March 2000 Counter32, vrrpStatsAuthTypeMismatch Counter32, vrrpStatsPacketLengthErrors Counter32 } vrrpStatsBecomeMaster OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times that this virtual router's state has transitioned to MASTER." ::= { vrrpRouterStatsEntry 1 } vrrpStatsAdvertiseRcvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of VRRP advertisements received by this virtual router." ::= { vrrpRouterStatsEntry 2 } vrrpStatsAdvertiseIntervalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of VRRP advertisement packets received for which the advertisement interval is different than the one configured for the local virtual router." ::= { vrrpRouterStatsEntry 3 } vrrpStatsAuthFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of VRRP packets received that do not pass the authentication check." ::= { vrrpRouterStatsEntry 4 } vrrpStatsIpTtlErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Jewell & Chuang Standards Track [Page 22] RFC 2787 VRRP MIB Management Objects March 2000 DESCRIPTION "The total number of VRRP packets received by the virtual router with IP TTL (Time-To-Live) not equal to 255." ::= { vrrpRouterStatsEntry 5 } vrrpStatsPriorityZeroPktsRcvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of VRRP packets received by the virtual router with a priority of '0'." ::= { vrrpRouterStatsEntry 6 } vrrpStatsPriorityZeroPktsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of VRRP packets sent by the virtual router with a priority of '0'." ::= { vrrpRouterStatsEntry 7 } vrrpStatsInvalidTypePktsRcvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRRP packets received by the virtual router with an invalid value in the 'type' field." ::= { vrrpRouterStatsEntry 8 } vrrpStatsAddressListErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received for which the address list does not match the locally configured list for the virtual router." ::= { vrrpRouterStatsEntry 9 } vrrpStatsInvalidAuthType OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received with an unknown Jewell & Chuang Standards Track [Page 23] RFC 2787 VRRP MIB Management Objects March 2000 authentication type." ::= { vrrpRouterStatsEntry 10 } vrrpStatsAuthTypeMismatch OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received with 'Auth Type' not equal to the locally configured authentication method (`vrrpOperAuthType')." ::= { vrrpRouterStatsEntry 11 } vrrpStatsPacketLengthErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received with a packet length less than the length of the VRRP header." ::= { vrrpRouterStatsEntry 12 } -- ******************************************************************* -- Trap Definitions -- ******************************************************************* vrrpNotifications OBJECT IDENTIFIER ::= { vrrpMIB 0 } vrrpTrapPacketSrc OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The IP address of an inbound VRRP packet. Used by vrrpTrapAuthFailure trap." ::= { vrrpOperations 5 } vrrpTrapAuthErrorType OBJECT-TYPE SYNTAX INTEGER { invalidAuthType (1), authTypeMismatch (2), authFailure (3) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Potential types of configuration conflicts. Used by vrrpAuthFailure trap." Jewell & Chuang Standards Track [Page 24] RFC 2787 VRRP MIB Management Objects March 2000 ::= { vrrpOperations 6 } vrrpTrapNewMaster NOTIFICATION-TYPE OBJECTS { vrrpOperMasterIpAddr } STATUS current DESCRIPTION "The newMaster trap indicates that the sending agent has transitioned to 'Master' state." ::= { vrrpNotifications 1 } vrrpTrapAuthFailure NOTIFICATION-TYPE OBJECTS { vrrpTrapPacketSrc, vrrpTrapAuthErrorType } STATUS current DESCRIPTION "A vrrpAuthFailure trap signifies that a packet has been received from a router whose authentication key or authentication type conflicts with this router's authentication key or authentication type. Implementation of this trap is optional." ::= { vrrpNotifications 2 } -- ******************************************************************* -- Conformance Information -- ******************************************************************* vrrpMIBCompliances OBJECT IDENTIFIER ::= { vrrpConformance 1 } vrrpMIBGroups OBJECT IDENTIFIER ::= { vrrpConformance 2 } -- ................................................................... -- Compliance Statements -- ................................................................... vrrpMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The core compliance statement for all VRRP implementations." MODULE -- this module MANDATORY-GROUPS { vrrpOperGroup, vrrpStatsGroup } OBJECT vrrpOperPriority WRITE-SYNTAX Integer32 (1..255) DESCRIPTION "SETable values are from 1 to 255." Jewell & Chuang Standards Track [Page 25] RFC 2787 VRRP MIB Management Objects March 2000 ::= { vrrpMIBCompliances 1 } -- ................................................................... -- Conformance Groups -- ................................................................... vrrpOperGroup OBJECT-GROUP OBJECTS { vrrpNodeVersion, vrrpNotificationCntl, vrrpOperVirtualMacAddr, vrrpOperState, vrrpOperAdminState, vrrpOperPriority, vrrpOperIpAddrCount, vrrpOperMasterIpAddr, vrrpOperPrimaryIpAddr, vrrpOperAuthType, vrrpOperAuthKey, vrrpOperAdvertisementInterval, vrrpOperPreemptMode, vrrpOperVirtualRouterUpTime, vrrpOperProtocol, vrrpOperRowStatus, vrrpAssoIpAddrRowStatus } STATUS current DESCRIPTION "Conformance group for VRRP operations." ::= { vrrpMIBGroups 1 } vrrpStatsGroup OBJECT-GROUP OBJECTS { vrrpRouterChecksumErrors, vrrpRouterVersionErrors, vrrpRouterVrIdErrors, vrrpStatsBecomeMaster, vrrpStatsAdvertiseRcvd, vrrpStatsAdvertiseIntervalErrors, vrrpStatsAuthFailures, vrrpStatsIpTtlErrors, vrrpStatsPriorityZeroPktsRcvd, vrrpStatsPriorityZeroPktsSent, vrrpStatsInvalidTypePktsRcvd, vrrpStatsAddressListErrors, vrrpStatsInvalidAuthType, vrrpStatsAuthTypeMismatch, vrrpStatsPacketLengthErrors Jewell & Chuang Standards Track [Page 26] RFC 2787 VRRP MIB Management Objects March 2000 } STATUS current DESCRIPTION "Conformance group for VRRP statistics." ::= { vrrpMIBGroups 2 } vrrpTrapGroup OBJECT-GROUP OBJECTS { vrrpTrapPacketSrc, vrrpTrapAuthErrorType } STATUS current DESCRIPTION "Conformance group for objects contained in VRRP notifications." ::= { vrrpMIBGroups 3 } vrrpNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { vrrpTrapNewMaster, vrrpTrapAuthFailure } STATUS current DESCRIPTION "The VRRP MIB Notification Group." ::= { vrrpMIBGroups 4 } END 4. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write or read-create. Such objects may be considered sensitive or vulnerable to security attacks in some networking environments. The support for SET operations in a non- secure environment without proper protection can have a negative effect on VRRP router operations. A number of objects in the vrrpOperTable possess the read-create attribute. Manipulation of these objects is capable of affecting the operation of a virtual router. Specific examples of this include, but are not limited to: o The vrrpOperAdminState object which could be used to disable a virtual router. o The vrrpOperPrimaryIpAddr object which, if compromised, could allow assignment of an invalid IP address to a master router. Jewell & Chuang Standards Track [Page 27] RFC 2787 VRRP MIB Management Objects March 2000 o The authentication type/key related objects which could potentially render the VRRP security mechanisms ineffective. Of additional concern is the ability to disable the transmission of traps. This would nullify the capability of a virtual router to provide notification in the event of an authentication failure. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 5. Acknowledgements The authors would like to thank Danny Mitzel, Venkat Prasad, Al Pham, Robert Hinden, Venkat Prasad, Barbera Denny, Fred Baker, Jeff Case, Flavio Fernandes, Acee Lindem, Scott Barvick, and Bert Wijnen for their comments and suggestions. 6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Jewell & Chuang Standards Track [Page 28] RFC 2787 VRRP MIB Management Objects March 2000 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [17] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M. and Lindem, A., "Virtual Router Redundancy Protocol", RFC 2338, November 1997. [18] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. Jewell & Chuang Standards Track [Page 29] RFC 2787 VRRP MIB Management Objects March 2000 7. Authors' Addresses Brian R. Jewell Copper Mountain Networks, Inc. 2470 Embarcadero Way Palo Alto, California 94303 US Phone: +1 650 687 3367 EMail: bjewell@coppermountain.com David Chuang CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065 US Phone: +1 650 628 4850 EMail: david_chuang@cosinecom.com 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Jewell & Chuang Standards Track [Page 30] RFC 2787 VRRP MIB Management Objects March 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Jewell & Chuang Standards Track [Page 31] snmp-mibs-downloader-1.1/mibrfcs/rfc2788.txt0000644000000000000000000012560211402176071015600 0ustar Network Working Group N. Freed Request for Comments: 2788 Innosoft Category: Standards Track S. Kille Obsoletes: 2248 MessagingDirect Ltd. March 2000 Network Services Monitoring MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Introduction A networked application is a realization of some well-defined service on one or more host computers that is accessible via some network, uses some network for its internal operations, or both. There are a wide range of networked applications for which it is appropriate to provide SNMP monitoring of their network usage. This includes applications using both TCP/IP and OSI networking. This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application-specific monitoring and management. Two examples of this are MIBs defining additional variables for monitoring a Message Transfer Agent (MTA) service or a Directory Service Agent (DSA) service. It is expected that further MIBs of this nature will be specified. Freed & Kille Standards Track [Page 1] RFC 2788 Network Services Monitoring MIB March 2000 This MIB does not attempt to provide facilities for management of the host or hosts the network service application runs on, nor does it provide facilities for monitoring applications that provide something other than a network service. Host resource and general application monitoring is handled by either the Host Resources MIB [1] or the application MIB [2]. Table of Contents 1 The SNMP Network Management Framework ....................... 2 2 Rationale for having a Network Services Monitoring MIB ...... 3 1 General Relationship to Other MIBs ........................ 4 2 Restriction of Scope ...................................... 4 3 Configuration Information ................................. 5 3 Application Objects ......................................... 5 4 Definitions ................................................. 5 5 Changes made since RFC 2248 ................................. 18 6 Acknowledgements ............................................ 18 7 References .................................................. 19 8 Security Considerations ..................................... 20 9 Author and Chair Addresses .................................. 21 10 Full Copyright Statement .................................... 22 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [3]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [4], STD 16, RFC 1212 [5] and RFC 1215 [6]. The second version, called SMIv2, is described in STD 58, RFC 2578 [7], STD 58, RFC 2579 [8] and STD 58, RFC 2580 [9]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [10]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [11] and RFC 1906 [12]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [12], RFC 2572 [13] and RFC 2574 [14]. Freed & Kille Standards Track [Page 2] RFC 2788 Network Services Monitoring MIB March 2000 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [10]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [15]. o A set of fundamental applications described in RFC 2573 [16] and the view-based access control mechanism described in RFC 2575 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Rationale for having a Network Services Monitoring MIB Much effort has been expended in developing tools to manage lower layer network facilities. However, relatively little work has been done on managing application layer entities. It is neither efficient nor reasonable to manage all aspects of application layer entities using only lower layer information. Moreover, the difficulty of managing application entities in this way increases dramatically as application entities become more complex. This leads to a substantial need to monitor applications which provide network services, particularly distributed components such as MTAs and DSAs, by monitoring specific aspects of the application itself. Reasons to monitor such components include but are not limited to measuring load, detecting broken connectivity, isolating system failures, and locating congestion. In order to manage network service applications effectively two requirements must be met: (1) It must be possible to monitor a large number of components (typical for a large organization). Freed & Kille Standards Track [Page 3] RFC 2788 Network Services Monitoring MIB March 2000 (2) Application monitoring must be integrated into general network management. This specification defines simple read-only access; this is sufficient to determine up/down status and provide an indication of a broad class of operational problems. 2.1. General Relationship to Other MIBs This MIB is intended to only provide facilities common to the monitoring of any network service application. It does not provide all the facilities necessary to monitor any specific application. Each specific type of network service application is expected to have a MIB of its own that makes use of these common facilities. 2.2. Restriction of Scope The framework provided here is very minimal; there is a lot more that could be done. For example: (1) General network service application configuration monitoring and control. (2) Detailed examination and modification of individual entries in service-specific request queues. (3) Probing to determine the status of a specific request (e.g., the location of a mail message with a specific message-id). (4) Requesting that certain actions be performed (e.g., forcing an immediate connection and transfer of pending messages to some specific system). All these capabilities are both impressive and useful. However, these capabilities would require provisions for strict security checking. These capabilities would also mandate a much more complex design, with many characteristics likely to be fairly implementation-specific. As a result such facilities are likely to be both contentious and difficult to implement. This document religiously keeps things simple and focuses on the basic monitoring aspect of managing applications providing network services. The goal here is to provide a framework which is simple, useful, and widely implementable. Freed & Kille Standards Track [Page 4] RFC 2788 Network Services Monitoring MIB March 2000 2.3. Configuration Information This MIB attempts to provide information about the operational aspects of an application. Further information about the actual configuration of a given application may be kept in other places; the applDirectoryName or applURL may be used to point to places where such information is kept. 3. Application Objects This MIB defines a set of general purpose attributes which would be appropriate for a range of applications that provide network services. Both OSI and non-OSI services can be accommodated. Additional tables defined in extensions to this MIB provide attributes specific to specific network services. A table is defined which will have one row for each operational network service application on the system. The only static information held on the application is its name. All other static information should be obtained from various directory services. The applDirectoryName is an external key, which allows an SNMP MIB entry to be cleanly related to the X.500 Directory. In SNMP terms, the applications are grouped in a table called applTable, which is indexed by an integer key applIndex. The type of the application will be determined by one or both of: (1) Additional MIB variables specific to the applications. (2) An association to the application of a specific protocol. 4. Definitions NETWORK-SERVICES-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; application MODULE-IDENTITY LAST-UPDATED "200003030000Z" ORGANIZATION "IETF Mail and Directory Management Working Group" Freed & Kille Standards Track [Page 5] RFC 2788 Network Services Monitoring MIB March 2000 CONTACT-INFO " Ned Freed Postal: Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 US Tel: +1 626 919 3600 Fax: +1 626 919 3614 E-Mail: ned.freed@innosoft.com" DESCRIPTION "The MIB module describing network service applications" REVISION "200003030000Z" DESCRIPTION "This revision, published in RFC 2788, changes a number of DisplayStrings to SnmpAdminStrings. Note that this change is not strictly supported by SMIv2. However, the alternative of deprecating the old objects and defining new objects would have a more adverse impact on backward compatibility and interoperability, given the particular semantics of these objects. The defining reference for distinguished names has also been updated from RFC 1779 to RFC 2253." REVISION "199905120000Z" DESCRIPTION "This revision fixes a few small technical problems found in previous versions, mostly in regards to the conformance groups for different versions of this MIB. No changes have been made to the objects this MIB defines since RFC 2248." REVISION "199708170000Z" DESCRIPTION "This revision, published in RFC 2248, adds the applDescription and applURL objects, adds the quiescing state to the applOperStatus object and renames the MIB from the APPLICATION-MIB to the NETWORK-SERVICE-MIB." REVISION "199311280000Z" DESCRIPTION "The original version of this MIB was published in RFC 1565" ::= {mib-2 27} -- Textual conventions -- DistinguishedName is used to refer to objects in the -- directory. DistinguishedName ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" Freed & Kille Standards Track [Page 6] RFC 2788 Network Services Monitoring MIB March 2000 STATUS current DESCRIPTION "A Distinguished Name represented in accordance with RFC 2253, presented in the UTF-8 charset defined in RFC 2279." SYNTAX OCTET STRING (SIZE (0..255)) -- Uniform Resource Locators are stored in URLStrings. URLString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "A Uniform Resource Locator represented in accordance with RFCs 1738 and 2368, presented in the NVT ASCII charset defined in RFC 854." SYNTAX OCTET STRING (SIZE (0..255)) -- The basic applTable contains a list of the application -- entities. applTable OBJECT-TYPE SYNTAX SEQUENCE OF ApplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table holding objects which apply to all different kinds of applications providing network services. Each network service application capable of being monitored should have a single entry in this table." ::= {application 1} applEntry OBJECT-TYPE SYNTAX ApplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry associated with a single network service application." INDEX {applIndex} ::= {applTable 1} ApplEntry ::= SEQUENCE { applIndex INTEGER, applName SnmpAdminString, applDirectoryName Freed & Kille Standards Track [Page 7] RFC 2788 Network Services Monitoring MIB March 2000 DistinguishedName, applVersion SnmpAdminString, applUptime TimeStamp, applOperStatus INTEGER, applLastChange TimeStamp, applInboundAssociations Gauge32, applOutboundAssociations Gauge32, applAccumulatedInboundAssociations Counter32, applAccumulatedOutboundAssociations Counter32, applLastInboundActivity TimeStamp, applLastOutboundActivity TimeStamp, applRejectedInboundAssociations Counter32, applFailedOutboundAssociations Counter32, applDescription SnmpAdminString, applURL URLString } applIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index to uniquely identify the network service application. This attribute is the index used for lexicographic ordering of the table." ::= {applEntry 1} applName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name the network service application chooses to be known by." Freed & Kille Standards Track [Page 8] RFC 2788 Network Services Monitoring MIB March 2000 ::= {applEntry 2} applDirectoryName OBJECT-TYPE SYNTAX DistinguishedName MAX-ACCESS read-only STATUS current DESCRIPTION "The Distinguished Name of the directory entry where static information about this application is stored. An empty string indicates that no information about the application is available in the directory." ::= {applEntry 3} applVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The version of network service application software. This field is usually defined by the vendor of the network service application software." ::= {applEntry 4} applUptime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the network service application was last initialized. If the application was last initialized prior to the last initialization of the network management subsystem, then this object contains a zero value." ::= {applEntry 5} applOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), halted(3), congested(4), restarting(5), quiescing(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the operational status of the network service application. 'down' indicates that the network service is Freed & Kille Standards Track [Page 9] RFC 2788 Network Services Monitoring MIB March 2000 not available. 'up' indicates that the network service is operational and available. 'halted' indicates that the service is operational but not available. 'congested' indicates that the service is operational but no additional inbound associations can be accommodated. 'restarting' indicates that the service is currently unavailable but is in the process of restarting and will be available soon. 'quiescing' indicates that service is currently operational but is in the process of shutting down. Additional inbound associations may be rejected by applications in the 'quiescing' state." ::= {applEntry 6} applLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the network service application entered its current operational state. If the current state was entered prior to the last initialization of the local network management subsystem, then this object contains a zero value." ::= {applEntry 7} applInboundAssociations OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of current associations to the network service application, where it is the responder. An inbound association occurs when another application successfully connects to this one." ::= {applEntry 8} applOutboundAssociations OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of current associations to the network service application, where it is the initiator. An outbound association occurs when this application successfully connects to another one." ::= {applEntry 9} applAccumulatedInboundAssociations OBJECT-TYPE Freed & Kille Standards Track [Page 10] RFC 2788 Network Services Monitoring MIB March 2000 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of associations to the application entity since application initialization, where it was the responder." ::= {applEntry 10} applAccumulatedOutboundAssociations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of associations to the application entity since application initialization, where it was the initiator." ::= {applEntry 11} applLastInboundActivity OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this application last had an inbound association. If the last association occurred prior to the last initialization of the network subsystem, then this object contains a zero value." ::= {applEntry 12} applLastOutboundActivity OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this application last had an outbound association. If the last association occurred prior to the last initialization of the network subsystem, then this object contains a zero value." ::= {applEntry 13} applRejectedInboundAssociations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of inbound associations the application entity has rejected, since application initialization. Rejected associations are not counted in the accumulated association totals. Note that this only counts Freed & Kille Standards Track [Page 11] RFC 2788 Network Services Monitoring MIB March 2000 associations the application entity has rejected itself; it does not count rejections that occur at lower layers of the network. Thus, this counter may not reflect the true number of failed inbound associations." ::= {applEntry 14} applFailedOutboundAssociations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number associations where the application entity is initiator and association establishment has failed, since application initialization. Failed associations are not counted in the accumulated association totals." ::= {applEntry 15} applDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A text description of the application. This information is intended to identify and briefly describe the application in a status display." ::= {applEntry 16} applURL OBJECT-TYPE SYNTAX URLString MAX-ACCESS read-only STATUS current DESCRIPTION "A URL pointing to a description of the application. This information is intended to identify and describe the application in a status display." ::= {applEntry 17} -- The assocTable augments the information in the applTable -- with information about associations. Note that two levels -- of compliance are specified below, depending on whether -- association monitoring is mandated. assocTable OBJECT-TYPE SYNTAX SEQUENCE OF AssocEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table holding a set of all active application Freed & Kille Standards Track [Page 12] RFC 2788 Network Services Monitoring MIB March 2000 associations." ::= {application 2} assocEntry OBJECT-TYPE SYNTAX AssocEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry associated with an association for a network service application." INDEX {applIndex, assocIndex} ::= {assocTable 1} AssocEntry ::= SEQUENCE { assocIndex INTEGER, assocRemoteApplication SnmpAdminString, assocApplicationProtocol OBJECT IDENTIFIER, assocApplicationType INTEGER, assocDuration TimeStamp } assocIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index to uniquely identify each association for a network service application. This attribute is the index that is used for lexicographic ordering of the table. Note that the table is also indexed by the applIndex." ::= {assocEntry 1} assocRemoteApplication OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the system running remote network service application. For an IP-based application this should be either a domain name or IP address. For an OSI application it should be the string encoded distinguished name of the managed object. For X.400(1984) MTAs which do not have a Distinguished Name, the RFC 2156 syntax 'mta in Freed & Kille Standards Track [Page 13] RFC 2788 Network Services Monitoring MIB March 2000 globalid' used in X400-Received: fields can be used. Note, however, that not all connections an MTA makes are necessarily to another MTA." ::= {assocEntry 2} assocApplicationProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An identification of the protocol being used for the application. For an OSI Application, this will be the Application Context. For Internet applications, OID values of the form {applTCPProtoID port} or {applUDPProtoID port} are used for TCP-based and UDP-based protocols, respectively. In either case 'port' corresponds to the primary port number being used by the protocol. The usual IANA procedures may be used to register ports for new protocols." ::= {assocEntry 3} assocApplicationType OBJECT-TYPE SYNTAX INTEGER { uainitiator(1), uaresponder(2), peerinitiator(3), peerresponder(4)} MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates whether the remote application is some type of client making use of this network service (e.g., a Mail User Agent) or a server acting as a peer. Also indicated is whether the remote end initiated an incoming connection to the network service or responded to an outgoing connection made by the local application. MTAs and messaging gateways are considered to be peers for the purposes of this variable." ::= {assocEntry 4} assocDuration OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this association was started. If this association started prior to the last initialization of the network subsystem, then this object contains a zero value." Freed & Kille Standards Track [Page 14] RFC 2788 Network Services Monitoring MIB March 2000 ::= {assocEntry 5} -- Conformance information applConformance OBJECT IDENTIFIER ::= {application 3} applGroups OBJECT IDENTIFIER ::= {applConformance 1} applCompliances OBJECT IDENTIFIER ::= {applConformance 2} -- Compliance statements applCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement for RFC 1565 implementations which support the Network Services Monitoring MIB for basic monitoring of network service applications. This is the basic compliance statement for RFC 1565." MODULE MANDATORY-GROUPS {applRFC1565Group} ::= {applCompliances 1} assocCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement for RFC 1565 implementations which support the Network Services Monitoring MIB for basic monitoring of network service applications and their associations." MODULE MANDATORY-GROUPS {applRFC1565Group, assocRFC1565Group} ::= {applCompliances 2} applRFC2248Compliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for RFC 2248 implementations which support the Network Services Monitoring MIB for basic monitoring of network service applications." MODULE MANDATORY-GROUPS {applRFC2248Group} ::= {applCompliances 3} assocRFC2248Compliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for RFC 2248 implementations Freed & Kille Standards Track [Page 15] RFC 2788 Network Services Monitoring MIB March 2000 which support the Network Services Monitoring MIB for basic monitoring of network service applications and their associations." MODULE MANDATORY-GROUPS {applRFC2248Group, assocRFC2248Group} ::= {applCompliances 4} applRFC2788Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2788 implementations which support the Network Services Monitoring MIB for basic monitoring of network service applications." MODULE MANDATORY-GROUPS {applRFC2788Group} ::= {applCompliances 5} assocRFC2788Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2788 implementations which support the Network Services Monitoring MIB for basic monitoring of network service applications and their associations." MODULE MANDATORY-GROUPS {applRFC2788Group, assocRFC2788Group} ::= {applCompliances 6} -- Units of conformance applRFC1565Group OBJECT-GROUP OBJECTS { applName, applVersion, applUptime, applOperStatus, applLastChange, applInboundAssociations, applOutboundAssociations, applAccumulatedInboundAssociations, applAccumulatedOutboundAssociations, applLastInboundActivity, applLastOutboundActivity, applRejectedInboundAssociations, applFailedOutboundAssociations} STATUS obsolete DESCRIPTION "A collection of objects providing basic monitoring of network service applications. This is the original set of such objects defined in RFC 1565." ::= {applGroups 7} assocRFC1565Group OBJECT-GROUP OBJECTS { Freed & Kille Standards Track [Page 16] RFC 2788 Network Services Monitoring MIB March 2000 assocRemoteApplication, assocApplicationProtocol, assocApplicationType, assocDuration} STATUS obsolete DESCRIPTION "A collection of objects providing basic monitoring of network service applications' associations. This is the original set of such objects defined in RFC 1565." ::= {applGroups 2} applRFC2248Group OBJECT-GROUP OBJECTS { applName, applVersion, applUptime, applOperStatus, applLastChange, applInboundAssociations, applOutboundAssociations, applAccumulatedInboundAssociations, applAccumulatedOutboundAssociations, applLastInboundActivity, applLastOutboundActivity, applRejectedInboundAssociations, applFailedOutboundAssociations, applDescription, applURL} STATUS deprecated DESCRIPTION "A collection of objects providing basic monitoring of network service applications. This group was originally defined in RFC 2248; note that applDirectoryName is missing." ::= {applGroups 3} assocRFC2248Group OBJECT-GROUP OBJECTS { assocRemoteApplication, assocApplicationProtocol, assocApplicationType, assocDuration} STATUS deprecated DESCRIPTION "A collection of objects providing basic monitoring of network service applications' associations. This group was originally defined by RFC 2248." ::= {applGroups 4} applRFC2788Group OBJECT-GROUP OBJECTS { applName, applDirectoryName, applVersion, applUptime, applOperStatus, applLastChange, applInboundAssociations, applOutboundAssociations, applAccumulatedInboundAssociations, applAccumulatedOutboundAssociations, applLastInboundActivity, applLastOutboundActivity, applRejectedInboundAssociations, applFailedOutboundAssociations, applDescription, applURL} STATUS current DESCRIPTION "A collection of objects providing basic monitoring of network service applications. This is the appropriate Freed & Kille Standards Track [Page 17] RFC 2788 Network Services Monitoring MIB March 2000 group for RFC 2788 -- it adds the applDirectoryName object missing in RFC 2248." ::= {applGroups 5} assocRFC2788Group OBJECT-GROUP OBJECTS { assocRemoteApplication, assocApplicationProtocol, assocApplicationType, assocDuration} STATUS current DESCRIPTION "A collection of objects providing basic monitoring of network service applications' associations. This is the appropriate group for RFC 2788." ::= {applGroups 6} -- OIDs of the form {applTCPProtoID port} are intended to be used -- for TCP-based protocols that don't have OIDs assigned by other -- means. {applUDPProtoID port} serves the same purpose for -- UDP-based protocols. In either case 'port' corresponds to -- the primary port number being used by the protocol. For example, -- assuming no other OID is assigned for SMTP, an OID of -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based -- protocol that uses port 25 as its primary port. applTCPProtoID OBJECT IDENTIFIER ::= {application 4} applUDPProtoID OBJECT IDENTIFIER ::= {application 5} END 5. Changes made since RFC 2248 This revision corrects a few minor technical errors in the construction of the network services MIB in RFC 2248 [22]. In addition, the applName, applVersion, and applDescription fields have been changed from DisplayStrings to SnmpAdminStrings. The reference to RFC 1779 has also been updated to RFC 2253, which in turn adds the ability for distinguished names to be in the UTF-8 character set. 6. Acknowledgements This document is a product of the Mail and Directory Management (MADMAN) Working Group. It is based on an earlier MIB designed by S. Kille, T. Lenggenhager, D. Partain, and W. Yeong. The Electronic Mail Association's TSC committee was instrumental in providing feedback on and suggesting enhancements to RFC 1565 [23] that have led to the present document. Freed & Kille Standards Track [Page 18] RFC 2788 Network Services Monitoring MIB March 2000 9. References [1] Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514, September 1993. [2] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [3] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [4] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [5] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [6] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [8] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [9] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [10] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [12] 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. [13] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Freed & Kille Standards Track [Page 19] RFC 2788 Network Services Monitoring MIB March 2000 [14] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [15] 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. [16] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [17] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [18] Wahl, M., Kille, S. and T.Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [19] Kille, S., "Mapping between X.400(1988) and RFC 822/MIME", RFC 2156, January 1998. [20] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [21] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL Scheme", RFC 2368, July 1998. [22] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC 2248, January 1998. [23] Freed, N. and Kille, "Network Services Monitoring MIB", RFC 1565, January 1994. [29] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, RFC 855, May 1983. 8. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. Freed & Kille Standards Track [Page 20] RFC 2788 Network Services Monitoring MIB March 2000 However, this MIB does provide passive information about the existence, type, and configuration of applications on a given host that could potentially indicate some sort of vulnerability. Finally, the information MIB provides about network usage could be used to analyze network traffic patterns. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [14] and the View-based Access Control Model RFC 2575 [17] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Author and Chair Addresses Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: ned.freed@innosoft.com Steve Kille, MADMAN WG Chair MessagingDirect Ltd. The Dome, The Square Richmond TW9 1DT UK Phone: +44 20 8332 9091 EMail: Steve.Kille@MessagingDirect.com Freed & Kille Standards Track [Page 21] RFC 2788 Network Services Monitoring MIB March 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Freed & Kille Standards Track [Page 22] snmp-mibs-downloader-1.1/mibrfcs/rfc2789.txt0000644000000000000000000020020711402176071015574 0ustar Network Working Group N. Freed Request for Comments: 2789 Innosoft Obsoletes: 2249, 1566 S. Kille Category: Standards Track MessagingDirect Ltd. March 2000 Mail Monitoring MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. Table of Contents 1 The SNMP Network Management Framework ....................... 2 2 Message Flow Model .......................................... 3 3 MTA Objects ................................................. 3 4 Definitions ................................................. 4 5 Changes made since RFC 2249 ................................. 29 6 Acknowledgements ............................................ 30 7 References .................................................. 30 8 Security Considerations ..................................... 31 9 Author and Chair Addresses .................................. 32 10 Full Copyright Statement .................................... 33 Freed & Kille Standards Track [Page 1] RFC 2789 Mail Monitoring MIB March 2000 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Freed & Kille Standards Track [Page 2] RFC 2789 Mail Monitoring MIB March 2000 2. Message Flow Model A general model of message flow inside an MTA has to be presented before a MIB can be described. Generally speaking, message flow is modelled as occurring in four steps: (1) Messages are received by the MTA from User Agents, Message Stores, other MTAs, and gateways. (2) The "next hop" for the each message is determined. This is simply the destination the message is to be transmitted to; it may or may not be the final destination of the message. Multiple "next hops" may exist for a single message (as a result of either having multiple recipients or distribution list expansion); this may make it necessary to duplicate messages. (3) If necessary messages are converted into the format that's appropriate for the next hop. Conversion operations may be successful or unsuccessful. (4) Messages are transmitted to the appropriate destination, which may be a User Agent, Message Store, another MTA, or gateway. Storage of messages in the MTA occurs at some point during this process. However, it is important to note that storage may occur at different and possibly even multiple points during this process. For example, some MTAs expand messages into multiple copies as they are received. In this case (1), (2), and (3) may all occur prior to storage. Other MTAs store messages precisely as they are received and perform all expansions and conversions during retransmission processing. So here only (1) occurs prior to storage. This leads to situations where, in general, a measurement of messages received may not equal a measurement of messages in store, or a measurement of messages stored may not equal a measurement of messages retransmitted, or both. 3. MTA Objects If there are one or more MTAs on the host, the following MIB may be used to monitor them. Any number of the MTAs on a single host or group of hosts may be monitored. Each MTA is dealt with as a separate network service and has its own applTable entry in the Network Services Monitoring MIB. The MIB described in this document covers only the portion which is specific to the monitoring of MTAs. The network service related part of the MIB is covered in RFC 2788 [16]. Freed & Kille Standards Track [Page 3] RFC 2789 Mail Monitoring MIB March 2000 This MIB defines four tables. The first of these contains per-MTA information that isn't specific to any particular part of MTA. The second breaks each MTA down into a collection of separate components called groups. Groups are described in detail in the comments embedded in the MIB below. The third table provides a means of correlating associations tracked by the network services MIB with specific groups within different MTAs. Finally, the fourth table provides a means of tracking any errors encountered during the operation of the MTA. The first two tables must be implemented to conform with this MIB; the last two are optional. 4. Definitions MTA-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TimeInterval FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB applIndex, URLString FROM NETWORK-SERVICES-MIB; mta MODULE-IDENTITY LAST-UPDATED "200003030000Z" ORGANIZATION "IETF Mail and Directory Management Working Group" CONTACT-INFO " Ned Freed Postal: Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 US Tel: +1 626 919 3600 Fax: +1 626 919 3614 E-Mail: ned.freed@innosoft.com" DESCRIPTION "The MIB module describing Message Transfer Agents (MTAs)" REVISION "200003030000Z" DESCRIPTION "This revision, published in RFC 2789, changes a number of DisplayStrings to SnmpAdminStrings. Note that this change Freed & Kille Standards Track [Page 4] RFC 2789 Mail Monitoring MIB March 2000 is not strictly supported by SMIv2. However, the alternative of deprecating the old objects and defining new objects would have a more adverse impact on backward compatibility and interoperability, given the particular semantics of these objects. The defining reference for distinguished names has also been updated from RFC 1779 to RFC 2253." REVISION "199905120000Z" DESCRIPTION "This revision fixes a number of technical problems found in previous versions: The conformance groups for different versions of this MIB have been corrected, the recommendation that an empty string be returned if the last operation was successful has been removed from mtaGroupInboundRejectionReason and mtaGroupOutboundConnectFailureReason as it conflicts with the stated purpose of these variables, and the required mtaStatusCode entry has been added to MtaGroupErrorEntry. It should be noted that this last change in no way affects the bits on the wire." REVISION "199708170000Z" DESCRIPTION "This revision, published in RFC 2249, adds the mtaGroupDescription and mtaGroupURL fields, conversion operation counters, a group hierarchy description mechanism, counters for specific errors, oldest message IDs, per-MTA and per-group loop counters, and a new table for tracking any errors an MTA encounters." REVISION "199311280000Z" DESCRIPTION "The original version of this MIB was published in RFC 1566" ::= {mib-2 28} mtaTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table holding information specific to an MTA." ::= {mta 1} mtaEntry OBJECT-TYPE SYNTAX MtaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry associated with each MTA." INDEX {applIndex} ::= {mtaTable 1} Freed & Kille Standards Track [Page 5] RFC 2789 Mail Monitoring MIB March 2000 MtaEntry ::= SEQUENCE { mtaReceivedMessages Counter32, mtaStoredMessages Gauge32, mtaTransmittedMessages Counter32, mtaReceivedVolume Counter32, mtaStoredVolume Gauge32, mtaTransmittedVolume Counter32, mtaReceivedRecipients Counter32, mtaStoredRecipients Gauge32, mtaTransmittedRecipients Counter32, mtaSuccessfulConvertedMessages Counter32, mtaFailedConvertedMessages Counter32, mtaLoopsDetected Counter32 } mtaReceivedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages received since MTA initialization. This includes messages transmitted to this MTA from other MTAs as well as messages that have been submitted to the MTA directly by end-users or applications." ::= {mtaEntry 1} mtaStoredMessages OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of messages currently stored in the MTA. This includes messages that are awaiting transmission to some other MTA or are waiting for delivery to an end-user or application." ::= {mtaEntry 2} Freed & Kille Standards Track [Page 6] RFC 2789 Mail Monitoring MIB March 2000 mtaTransmittedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages transmitted since MTA initialization. This includes messages that were transmitted to some other MTA or are waiting for delivery to an end-user or application." ::= {mtaEntry 3} mtaReceivedVolume OBJECT-TYPE SYNTAX Counter32 UNITS "K-octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total volume of messages received since MTA initialization, measured in kilo-octets. This volume should include all transferred data that is logically above the mail transport protocol level. For example, an SMTP-based MTA should use the number of kilo-octets in the message header and body, while an X.400-based MTA should use the number of kilo-octets of P2 data. This includes messages transmitted to this MTA from other MTAs as well as messages that have been submitted to the MTA directly by end-users or applications." ::= {mtaEntry 4} mtaStoredVolume OBJECT-TYPE SYNTAX Gauge32 UNITS "K-octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total volume of messages currently stored in the MTA, measured in kilo-octets. This volume should include all stored data that is logically above the mail transport protocol level. For example, an SMTP-based MTA should use the number of kilo-octets in the message header and body, while an X.400-based MTA would use the number of kilo-octets of P2 data. This includes messages that are awaiting transmission to some other MTA or are waiting for delivery to an end-user or application." ::= {mtaEntry 5} mtaTransmittedVolume OBJECT-TYPE SYNTAX Counter32 Freed & Kille Standards Track [Page 7] RFC 2789 Mail Monitoring MIB March 2000 UNITS "K-octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total volume of messages transmitted since MTA initialization, measured in kilo-octets. This volume should include all transferred data that is logically above the mail transport protocol level. For example, an SMTP-based MTA should use the number of kilo-octets in the message header and body, while an X.400-based MTA should use the number of kilo-octets of P2 data. This includes messages that were transmitted to some other MTA or are waiting for delivery to an end-user or application." ::= {mtaEntry 6} mtaReceivedRecipients OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of recipients specified in all messages received since MTA initialization. Recipients this MTA has no responsibility for, i.e. inactive envelope recipients or ones referred to in message headers, should not be counted even if information about such recipients is available. This includes messages transmitted to this MTA from other MTAs as well as messages that have been submitted to the MTA directly by end-users or applications." ::= {mtaEntry 7} mtaStoredRecipients OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of recipients specified in all messages currently stored in the MTA. Recipients this MTA has no responsibility for, i.e. inactive envelope recipients or ones referred to in message headers, should not be counted. This includes messages that are awaiting transmission to some other MTA or are waiting for delivery to an end-user or application." ::= {mtaEntry 8} mtaTransmittedRecipients OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Freed & Kille Standards Track [Page 8] RFC 2789 Mail Monitoring MIB March 2000 STATUS current DESCRIPTION "The total number of recipients specified in all messages transmitted since MTA initialization. Recipients this MTA had no responsibility for, i.e. inactive envelope recipients or ones referred to in message headers, should not be counted. This includes messages that were transmitted to some other MTA or are waiting for delivery to an end-user or application." ::= {mtaEntry 9} mtaSuccessfulConvertedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been successfully converted from one form to another since MTA initialization." ::= {mtaEntry 10} mtaFailedConvertedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages for which an unsuccessful attempt was made to convert them from one form to another since MTA initialization." ::= {mtaEntry 11} mtaLoopsDetected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A message loop is defined as a situation where the MTA decides that a given message will never be delivered to one or more recipients and instead will continue to loop endlessly through one or more MTAs. This variable counts the number of times the MTA has detected such a situation since MTA initialization. Note that the mechanism MTAs use to detect loops (e.g., trace field counting, count of references to this MTA in a trace field, examination of DNS or other directory information, etc.), the level at which loops are detected (e.g., per message, per recipient, per directory entry, etc.), and the handling of a loop once it is detected (e.g., looping Freed & Kille Standards Track [Page 9] RFC 2789 Mail Monitoring MIB March 2000 messages are held, looping messages are bounced or sent to the postmaster, messages that the MTA knows will loop won't be accepted, etc.) vary widely from one MTA to the next and cannot be inferred from this variable." ::= {mtaEntry 12} -- MTAs typically group inbound reception, queue storage, and -- outbound transmission in some way, rather than accounting for -- such operations only across the MTA as a whole. In the most -- extreme case separate information will be maintained for each -- different entity that receives messages and for each entity -- the MTA stores messages for and delivers messages to. Other -- MTAs may elect to treat all reception equally, all queue -- storage equally, all deliveries equally, or some combination -- of this. Overlapped groupings are also possible, where an MTA -- decomposes its traffic in different ways for different -- purposes. -- In any case, a grouping abstraction is an extremely useful for -- breaking down the activities of an MTA. For purposes of -- labelling this will be called a "group" in this MIB. -- Each group contains all the variables needed to monitor all -- aspects of an MTA's operation. However, the fact that all -- groups contain all possible variables does not imply that all -- groups must use all possible variables. For example, a single -- group might be used to monitor only one kind of event (inbound -- processing, outbound processing, or storage). In this sort of -- configuration any counters that are unused as a result of a -- given MTA's use of the group construct must be inaccessible; -- e.g., returning either a noSuchName error (for an SNMPv1 get), -- or a noSuchInstance exception (for an SNMPv2 get). -- Groups can be created at any time after MTA initialization. Once -- a group is created it should not be deleted or its mtaGroupIndex -- changed unless the MTA is reinitialized. -- Groups are not necessarily mutually exclusive. A given event may -- be recorded by more than one group, a message may be seen as -- stored by more than one group, and so on. Groups should be all -- inclusive, however: if groups are implemented all aspects of an -- MTA's operation should be registered in at least one group. -- This freedom lets implementors use different sets of groups to -- provide different "views" of an MTA. -- The possibility of overlap between groups means that summing -- variables across groups may not produce values equal to those in -- the mtaTable. mtaTable should always provide accurate information Freed & Kille Standards Track [Page 10] RFC 2789 Mail Monitoring MIB March 2000 -- about the MTA as a whole. -- The term "channel" is often used in MTA implementations; channels -- are usually, but not always, equivalent to a group. However, -- this MIB does not use the term "channel" because there is no -- requirement that an MTA supporting this MIB has to map its -- "channel" abstraction one-to-one onto the MIB's group abstraction. -- An MTA may create a group or group of groups at any time. Once -- created, however, an MTA cannot delete an entry for a group from -- the group table. Deletion is only allowed when the MTA is -- reinitialized, and is not required even then. This restriction -- is imposed so that monitoring agents can rely on group -- assignments being consistent across multiple query operations. -- Groups may be laid out so as to form a hierarchical arrangement, -- with some groups acting as subgroups for other groups. -- Alternately, disjoint groups of groups may be used to provide -- different sorts of "snapshots" of MTA operation. The -- mtaGroupHierarchy variable provides an indication of how each -- group fits into the overall arrangement being used. -- Note that SNMP also defines and uses term "group". MTA groups are -- NOT the same as SNMP groups. mtaGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table holding information specific to each MTA group." ::= {mta 2} mtaGroupEntry OBJECT-TYPE SYNTAX MtaGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry associated with each MTA group." INDEX {applIndex, mtaGroupIndex} ::= {mtaGroupTable 1} MtaGroupEntry ::= SEQUENCE { mtaGroupIndex INTEGER, mtaGroupReceivedMessages Counter32, mtaGroupRejectedMessages Freed & Kille Standards Track [Page 11] RFC 2789 Mail Monitoring MIB March 2000 Counter32, mtaGroupStoredMessages Gauge32, mtaGroupTransmittedMessages Counter32, mtaGroupReceivedVolume Counter32, mtaGroupStoredVolume Gauge32, mtaGroupTransmittedVolume Counter32, mtaGroupReceivedRecipients Counter32, mtaGroupStoredRecipients Gauge32, mtaGroupTransmittedRecipients Counter32, mtaGroupOldestMessageStored TimeInterval, mtaGroupInboundAssociations Gauge32, mtaGroupOutboundAssociations Gauge32, mtaGroupAccumulatedInboundAssociations Counter32, mtaGroupAccumulatedOutboundAssociations Counter32, mtaGroupLastInboundActivity TimeInterval, mtaGroupLastOutboundActivity TimeInterval, mtaGroupLastOutboundAssociationAttempt TimeInterval, mtaGroupRejectedInboundAssociations Counter32, mtaGroupFailedOutboundAssociations Counter32, mtaGroupInboundRejectionReason SnmpAdminString, mtaGroupOutboundConnectFailureReason SnmpAdminString, mtaGroupScheduledRetry TimeInterval, mtaGroupMailProtocol OBJECT IDENTIFIER, mtaGroupName SnmpAdminString, mtaGroupSuccessfulConvertedMessages Freed & Kille Standards Track [Page 12] RFC 2789 Mail Monitoring MIB March 2000 Counter32, mtaGroupFailedConvertedMessages Counter32, mtaGroupDescription SnmpAdminString, mtaGroupURL URLString, mtaGroupCreationTime TimeInterval, mtaGroupHierarchy INTEGER, mtaGroupOldestMessageId SnmpAdminString, mtaGroupLoopsDetected Counter32 } mtaGroupIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index associated with a group for a given MTA." ::= {mtaGroupEntry 1} mtaGroupReceivedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages received to this group since group creation." ::= {mtaGroupEntry 2} mtaGroupRejectedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages rejected by this group since group creation." ::= {mtaGroupEntry 3} mtaGroupStoredMessages OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION Freed & Kille Standards Track [Page 13] RFC 2789 Mail Monitoring MIB March 2000 "The total number of messages currently stored in this group's queue." ::= {mtaGroupEntry 4} mtaGroupTransmittedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages transmitted by this group since group creation." ::= {mtaGroupEntry 5} mtaGroupReceivedVolume OBJECT-TYPE SYNTAX Counter32 UNITS "K-octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total volume of messages received to this group since group creation, measured in kilo-octets. This volume should include all transferred data that is logically above the mail transport protocol level. For example, an SMTP-based MTA should use the number of kilo-octets in the message header and body, while an X.400-based MTA should use the number of kilo-octets of P2 data." ::= {mtaGroupEntry 6} mtaGroupStoredVolume OBJECT-TYPE SYNTAX Gauge32 UNITS "K-octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total volume of messages currently stored in this group's queue, measured in kilo-octets. This volume should include all stored data that is logically above the mail transport protocol level. For example, an SMTP-based MTA should use the number of kilo-octets in the message header and body, while an X.400-based MTA would use the number of kilo-octets of P2 data." ::= {mtaGroupEntry 7} mtaGroupTransmittedVolume OBJECT-TYPE SYNTAX Counter32 UNITS "K-octets" MAX-ACCESS read-only STATUS current Freed & Kille Standards Track [Page 14] RFC 2789 Mail Monitoring MIB March 2000 DESCRIPTION "The total volume of messages transmitted by this group since group creation, measured in kilo-octets. This volume should include all transferred data that is logically above the mail transport protocol level. For example, an SMTP-based MTA should use the number of kilo-octets in the message header and body, while an X.400-based MTA should use the number of kilo-octets of P2 data." ::= {mtaGroupEntry 8} mtaGroupReceivedRecipients OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of recipients specified in all messages received to this group since group creation. Recipients this MTA has no responsibility for should not be counted." ::= {mtaGroupEntry 9} mtaGroupStoredRecipients OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of recipients specified in all messages currently stored in this group's queue. Recipients this MTA has no responsibility for should not be counted." ::= {mtaGroupEntry 10} mtaGroupTransmittedRecipients OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of recipients specified in all messages transmitted by this group since group creation. Recipients this MTA had no responsibility for should not be counted." ::= {mtaGroupEntry 11} mtaGroupOldestMessageStored OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Time since the oldest message in this group's queue was Freed & Kille Standards Track [Page 15] RFC 2789 Mail Monitoring MIB March 2000 placed in the queue." ::= {mtaGroupEntry 12} mtaGroupInboundAssociations OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of current associations to the group, where the group is the responder." ::= {mtaGroupEntry 13} mtaGroupOutboundAssociations OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of current associations to the group, where the group is the initiator." ::= {mtaGroupEntry 14} mtaGroupAccumulatedInboundAssociations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of associations to the group since group creation, where the MTA was the responder." ::= {mtaGroupEntry 15} mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of associations from the group since group creation, where the MTA was the initiator." ::= {mtaGroupEntry 16} mtaGroupLastInboundActivity OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Time since the last time that this group had an active inbound association for purposes of message reception." ::= {mtaGroupEntry 17} Freed & Kille Standards Track [Page 16] RFC 2789 Mail Monitoring MIB March 2000 mtaGroupLastOutboundActivity OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Time since the last time that this group had a successful outbound association for purposes of message delivery." ::= {mtaGroupEntry 18} mtaGroupLastOutboundAssociationAttempt OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Time since the last time that this group attempted to make an outbound association for purposes of message delivery." ::= {mtaGroupEntry 34} mtaGroupRejectedInboundAssociations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of inbound associations the group has rejected, since group creation. Rejected associations are not counted in the accumulated association totals." ::= {mtaGroupEntry 19} mtaGroupFailedOutboundAssociations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number associations where the group was the initiator and association establishment has failed, since group creation. Failed associations are not counted in the accumulated association totals." ::= {mtaGroupEntry 20} mtaGroupInboundRejectionReason OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The failure reason, if any, for the last association this group refused to respond to. If no association attempt Freed & Kille Standards Track [Page 17] RFC 2789 Mail Monitoring MIB March 2000 has been made since the MTA was initialized the value should be 'never'." ::= {mtaGroupEntry 21} mtaGroupOutboundConnectFailureReason OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The failure reason, if any, for the last association attempt this group initiated. If no association attempt has been made since the MTA was initialized the value should be 'never'." ::= {mtaGroupEntry 22} mtaGroupScheduledRetry OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time until this group is next scheduled to attempt to make an association." ::= {mtaGroupEntry 23} mtaGroupMailProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An identification of the protocol being used by this group. For an group employing OSI protocols, this will be the Application Context. For Internet applications, OID values of the form {applTCPProtoID port} or {applUDPProtoID port} are used for TCP-based and UDP-based protocols, respectively. In either case 'port' corresponds to the primary port number being used by the protocol. The usual IANA procedures may be used to register ports for new protocols. applTCPProtoID and applUDPProtoID are defined in the NETWORK-SERVICES-MIB, RFC 2788." ::= {mtaGroupEntry 24} mtaGroupName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A descriptive name for the group. If this group connects to a single remote MTA this should be the name of that MTA. If Freed & Kille Standards Track [Page 18] RFC 2789 Mail Monitoring MIB March 2000 this in turn is an Internet MTA this should be the domain name. For an OSI MTA it should be the string encoded distinguished name of the managed object using the format defined in RFC 2253. For X.400(1984) MTAs which do not have a Distinguished Name, the RFC 2156 syntax 'mta in globalid' used in X400-Received: fields can be used." ::= {mtaGroupEntry 25} mtaGroupSuccessfulConvertedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been successfully converted from one form to another in this group since group creation." ::= {mtaGroupEntry 26} mtaGroupFailedConvertedMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages for which an unsuccessful attempt was made to convert them from one form to another in this group since group creation." ::= {mtaGroupEntry 27} mtaGroupDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the group's purpose. This information is intended to identify the group in a status display." ::= {mtaGroupEntry 28} mtaGroupURL OBJECT-TYPE SYNTAX URLString MAX-ACCESS read-only STATUS current DESCRIPTION "A URL pointing to a description of the group. This information is intended to identify and briefly describe the group in a status display." ::= {mtaGroupEntry 29} Freed & Kille Standards Track [Page 19] RFC 2789 Mail Monitoring MIB March 2000 mtaGroupCreationTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Time since this group was first created." ::= {mtaGroupEntry 30} mtaGroupHierarchy OBJECT-TYPE SYNTAX INTEGER (-2147483648..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Describes how this group fits into the hierarchy. A positive value is interpreted as an mtaGroupIndex value for some other group whose variables include those of this group (and usually others). A negative value is interpreted as a group collection code: Groups with common negative hierarchy values comprise one particular breakdown of MTA activity as a whole. A zero value means that this MIB implementation doesn't implement hierarchy indicators and thus the overall group hierarchy cannot be determined." ::= {mtaGroupEntry 31} mtaGroupOldestMessageId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Message ID of the oldest message in the group's queue. Whenever possible this should be in the form of an RFC 822 msg-id; X.400 may convert X.400 message identifiers to this form by following the rules laid out in RFC2156." ::= {mtaGroupEntry 32} mtaGroupLoopsDetected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A message loop is defined as a situation where the MTA decides that a given message will never be delivered to one or more recipients and instead will continue to loop endlessly through one or more MTAs. This variable counts the number of times the MTA has detected such a situation in conjunction with something associated with Freed & Kille Standards Track [Page 20] RFC 2789 Mail Monitoring MIB March 2000 this group since group creation. Note that the mechanism MTAs use to detect loops (e.g., trace field counting, count of references to this MTA in a trace field, examination of DNS or other directory information, etc.), the level at which loops are detected (e.g., per message, per recipient, per directory entry, etc.), and the handling of a loop once it is detected (e.g., looping messages are held, looping messages are bounced or sent to the postmaster, messages that the MTA knows will loop won't be accepted, etc.) vary widely from one MTA to the next and cannot be inferred from this variable." ::= {mtaGroupEntry 33} -- The mtaGroupAssociationTable provides a means of correlating -- entries in the network services association table with the -- MTA group responsible for the association. mtaGroupAssociationTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaGroupAssociationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table holding information regarding the associations for each MTA group." ::= {mta 3} mtaGroupAssociationEntry OBJECT-TYPE SYNTAX MtaGroupAssociationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry holding information regarding the associations for each MTA group." INDEX {applIndex, mtaGroupIndex, mtaGroupAssociationIndex} ::= {mtaGroupAssociationTable 1} MtaGroupAssociationEntry ::= SEQUENCE { mtaGroupAssociationIndex INTEGER } mtaGroupAssociationIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Reference into association table to allow correlation of this group's active associations with the association table." Freed & Kille Standards Track [Page 21] RFC 2789 Mail Monitoring MIB March 2000 ::= {mtaGroupAssociationEntry 1} -- The mtaGroupErrorTable gives each group a way of tallying -- the specific errors it has encountered. The mechanism -- defined here uses RFC 1893 status codes to identify -- various specific errors. There are also classes for generic -- errors of various sorts, and the entire mechanism is also -- extensible, in that new error codes can be defined at any -- time. mtaGroupErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF MtaGroupErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table holding information regarding accumulated errors for each MTA group." ::= {mta 5} mtaGroupErrorEntry OBJECT-TYPE SYNTAX MtaGroupErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry holding information regarding accumulated errors for each MTA group." INDEX {applIndex, mtaGroupIndex, mtaStatusCode} ::= {mtaGroupErrorTable 1} MtaGroupErrorEntry ::= SEQUENCE { mtaStatusCode INTEGER (4000000..5999999), mtaGroupInboundErrorCount Counter32, mtaGroupInternalErrorCount Counter32, mtaGroupOutboundErrorCount Counter32 } mtaGroupInboundErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of errors of a given type that have been accumulated in association with a particular group while processing incoming messages. In the case of SMTP Freed & Kille Standards Track [Page 22] RFC 2789 Mail Monitoring MIB March 2000 these will typically be errors reporting by an SMTP server to the remote client; in the case of X.400 these will typically be errors encountered while processing an incoming message." ::= {mtaGroupErrorEntry 1} mtaGroupInternalErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of errors of a given type that have been accumulated in association with a particular group during internal MTA processing." ::= {mtaGroupErrorEntry 2} mtaGroupOutboundErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the number of errors of a given type that have been accumulated in association with a particular group's outbound connection activities. In the case of an SMTP client these will typically be errors reported while attempting to contact or while communicating with the remote SMTP server. In the case of X.400 these will typically be errors encountered while constructing or attempting to deliver an outgoing message." ::= {mtaGroupErrorEntry 3} mtaStatusCode OBJECT-TYPE SYNTAX INTEGER (4000000..5999999) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index capable of representing an Enhanced Mail System Status Code. Enhanced Mail System Status Codes are defined in RFC 1893. These codes have the form class.subject.detail Here 'class' is either 2, 4, or 5 and both 'subject' and 'detail' are integers in the range 0..999. Given a status code the corresponding index value is defined to be ((class * 1000) + subject) * 1000 + detail. Both SMTP error response codes and X.400 reason and diagnostic codes can be mapped into these codes, resulting in a namespace Freed & Kille Standards Track [Page 23] RFC 2789 Mail Monitoring MIB March 2000 capable of describing most error conditions a mail system encounters in a generic yet detailed way." ::= {mtaGroupErrorEntry 4} -- Conformance information mtaConformance OBJECT IDENTIFIER ::= {mta 4} mtaGroups OBJECT IDENTIFIER ::= {mtaConformance 1} mtaCompliances OBJECT IDENTIFIER ::= {mtaConformance 2} -- Compliance statements mtaCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 1566 implementations which support the Mail Monitoring MIB for basic monitoring of MTAs." MODULE -- this module MANDATORY-GROUPS {mtaRFC1566Group} ::= {mtaCompliances 1} mtaAssocCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 1566 implementations which support the Mail Monitoring MIB for monitoring of MTAs and their associations." MODULE -- this module MANDATORY-GROUPS {mtaRFC1566Group, mtaRFC1566AssocGroup} ::= {mtaCompliances 2} mtaRFC2249Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2249 implementations which support the Mail Monitoring MIB for basic monitoring of MTAs." MODULE -- this module MANDATORY-GROUPS {mtaRFC2249Group} ::= {mtaCompliances 5} mtaRFC2249AssocCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2249 implementations Freed & Kille Standards Track [Page 24] RFC 2789 Mail Monitoring MIB March 2000 which support the Mail Monitoring MIB for monitoring of MTAs and their associations." MODULE -- this module MANDATORY-GROUPS {mtaRFC2249Group, mtaRFC2249AssocGroup} ::= {mtaCompliances 6} mtaRFC2249ErrorCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2249 implementations which support the Mail Monitoring MIB for monitoring of MTAs and detailed errors." MODULE -- this module MANDATORY-GROUPS {mtaRFC2249Group, mtaRFC2249ErrorGroup} ::= {mtaCompliances 7} mtaRFC2249FullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2249 implementations which support the full Mail Monitoring MIB for monitoring of MTAs, associations, and detailed errors." MODULE -- this module MANDATORY-GROUPS {mtaRFC2249Group, mtaRFC2249AssocGroup, mtaRFC2249ErrorGroup} ::= {mtaCompliances 8} mtaRFC2789Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2789 implementations which support the Mail Monitoring MIB for basic monitoring of MTAs." MODULE -- this module MANDATORY-GROUPS {mtaRFC2789Group} ::= {mtaCompliances 9} mtaRFC2789AssocCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2789 implementations which support the Mail Monitoring MIB for monitoring of MTAs and their associations." MODULE -- this module MANDATORY-GROUPS {mtaRFC2789Group, mtaRFC2789AssocGroup} ::= {mtaCompliances 10} mtaRFC2789ErrorCompliance MODULE-COMPLIANCE Freed & Kille Standards Track [Page 25] RFC 2789 Mail Monitoring MIB March 2000 STATUS current DESCRIPTION "The compliance statement for RFC 2789 implementations which support the Mail Monitoring MIB for monitoring of MTAs and detailed errors." MODULE -- this module MANDATORY-GROUPS {mtaRFC2789Group, mtaRFC2789ErrorGroup} ::= {mtaCompliances 11} mtaRFC2789FullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for RFC 2789 implementations which support the full Mail Monitoring MIB for monitoring of MTAs, associations, and detailed errors." MODULE -- this module MANDATORY-GROUPS {mtaRFC2789Group, mtaRFC2789AssocGroup, mtaRFC2789ErrorGroup} ::= {mtaCompliances 12} -- Units of conformance mtaRFC1566Group OBJECT-GROUP OBJECTS { mtaReceivedMessages, mtaStoredMessages, mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, mtaTransmittedVolume, mtaReceivedRecipients, mtaStoredRecipients, mtaTransmittedRecipients, mtaGroupReceivedMessages, mtaGroupRejectedMessages, mtaGroupStoredMessages, mtaGroupTransmittedMessages, mtaGroupReceivedVolume, mtaGroupStoredVolume, mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, mtaGroupOldestMessageStored, mtaGroupInboundAssociations, mtaGroupOutboundAssociations, mtaGroupAccumulatedInboundAssociations, mtaGroupAccumulatedOutboundAssociations, mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity, mtaGroupRejectedInboundAssociations, mtaGroupFailedOutboundAssociations, mtaGroupInboundRejectionReason, mtaGroupOutboundConnectFailureReason, mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName} STATUS current DESCRIPTION "A collection of objects providing basic monitoring of MTAs. This is the original set of such objects defined in RFC 1566." Freed & Kille Standards Track [Page 26] RFC 2789 Mail Monitoring MIB March 2000 ::= {mtaGroups 10} mtaRFC1566AssocGroup OBJECT-GROUP OBJECTS { mtaGroupAssociationIndex} STATUS current DESCRIPTION "A collection of objects providing monitoring of MTA associations. This is the original set of such objects defined in RFC 1566." ::= {mtaGroups 11} mtaRFC2249Group OBJECT-GROUP OBJECTS { mtaReceivedMessages, mtaStoredMessages, mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, mtaTransmittedVolume, mtaReceivedRecipients, mtaStoredRecipients, mtaTransmittedRecipients, mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages, mtaGroupReceivedMessages, mtaGroupRejectedMessages, mtaGroupStoredMessages, mtaGroupTransmittedMessages, mtaGroupReceivedVolume, mtaGroupStoredVolume, mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, mtaGroupOldestMessageStored, mtaGroupInboundAssociations, mtaGroupOutboundAssociations, mtaLoopsDetected, mtaGroupAccumulatedInboundAssociations, mtaGroupAccumulatedOutboundAssociations, mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity, mtaGroupLastOutboundAssociationAttempt, mtaGroupRejectedInboundAssociations, mtaGroupFailedOutboundAssociations, mtaGroupInboundRejectionReason, mtaGroupOutboundConnectFailureReason, mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName, mtaGroupSuccessfulConvertedMessages, mtaGroupFailedConvertedMessages, mtaGroupDescription, mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy, mtaGroupOldestMessageId, mtaGroupLoopsDetected} STATUS current DESCRIPTION "A collection of objects providing basic monitoring of MTAs. This group was originally defined in RFC 2249." ::= {mtaGroups 4} mtaRFC2249AssocGroup OBJECT-GROUP OBJECTS { mtaGroupAssociationIndex} Freed & Kille Standards Track [Page 27] RFC 2789 Mail Monitoring MIB March 2000 STATUS current DESCRIPTION "A collection of objects providing monitoring of MTA associations. This group was originally defined in RFC 2249." ::= {mtaGroups 5} mtaRFC2249ErrorGroup OBJECT-GROUP OBJECTS { mtaGroupInboundErrorCount, mtaGroupInternalErrorCount, mtaGroupOutboundErrorCount} STATUS current DESCRIPTION "A collection of objects providing monitoring of detailed MTA errors. This group was originally defined in RFC 2249." ::= {mtaGroups 6} mtaRFC2789Group OBJECT-GROUP OBJECTS { mtaReceivedMessages, mtaStoredMessages, mtaTransmittedMessages, mtaReceivedVolume, mtaStoredVolume, mtaTransmittedVolume, mtaReceivedRecipients, mtaStoredRecipients, mtaTransmittedRecipients, mtaSuccessfulConvertedMessages, mtaFailedConvertedMessages, mtaGroupReceivedMessages, mtaGroupRejectedMessages, mtaGroupStoredMessages, mtaGroupTransmittedMessages, mtaGroupReceivedVolume, mtaGroupStoredVolume, mtaGroupTransmittedVolume, mtaGroupReceivedRecipients, mtaGroupStoredRecipients, mtaGroupTransmittedRecipients, mtaGroupOldestMessageStored, mtaGroupInboundAssociations, mtaGroupOutboundAssociations, mtaLoopsDetected, mtaGroupAccumulatedInboundAssociations, mtaGroupAccumulatedOutboundAssociations, mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity, mtaGroupLastOutboundAssociationAttempt, mtaGroupRejectedInboundAssociations, mtaGroupFailedOutboundAssociations, mtaGroupInboundRejectionReason, mtaGroupOutboundConnectFailureReason, mtaGroupScheduledRetry, mtaGroupMailProtocol, mtaGroupName, mtaGroupSuccessfulConvertedMessages, mtaGroupFailedConvertedMessages, mtaGroupDescription, mtaGroupURL, mtaGroupCreationTime, mtaGroupHierarchy, mtaGroupOldestMessageId, mtaGroupLoopsDetected} STATUS current DESCRIPTION "A collection of objects providing basic monitoring of MTAs. Freed & Kille Standards Track [Page 28] RFC 2789 Mail Monitoring MIB March 2000 This is the appropriate group for RFC 2789." ::= {mtaGroups 7} mtaRFC2789AssocGroup OBJECT-GROUP OBJECTS { mtaGroupAssociationIndex} STATUS current DESCRIPTION "A collection of objects providing monitoring of MTA associations. This is the appropriate group for RFC 2789 association monitoring." ::= {mtaGroups 8} mtaRFC2789ErrorGroup OBJECT-GROUP OBJECTS { mtaGroupInboundErrorCount, mtaGroupInternalErrorCount, mtaGroupOutboundErrorCount} STATUS current DESCRIPTION "A collection of objects providing monitoring of detailed MTA errors. This is the appropriate group for RFC 2789 error monitoring." ::= {mtaGroups 9} END 5. Changes made since RFC 2249 This revision corrects a number of minor technical errors in the construction of the mail monitoring MIB in RFC 2249 [18]: (1) All DisplayStrings have been changed to SnmpAdminStrings, (2) the conformance groups for different versions of this MIB have been corrected, (3) the required mtaStatusCode entry has been added to MtaGroupErrorEntry (which does not affect the bits on the wire in any way), and (4) the recommendation that an empty string be returned if the last operation was successful has been removed from mtaGroupInboundRejectionReason and mtaGroupOutboundConnectFailureReason as it conflicts with the stated purpose of these variables. Freed & Kille Standards Track [Page 29] RFC 2789 Mail Monitoring MIB March 2000 6. Acknowledgements This document is a work product of the Mail and Directory Management (MADMAN) Working Group of the IETF. It is based on an earlier MIB designed by S. Kille, T. Lenggenhager, D. Partain, and W. Yeong. The Electronic Mail Association's TSC committee was instrumental in providing feedback on and suggesting enhancements to RFC 1566 [19] that have led to the present document. 7. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Freed & Kille Standards Track [Page 30] RFC 2789 Mail Monitoring MIB March 2000 [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC 2788, March 2000. [17] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [18] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2249, January 1998. [19] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 1566, January 1994. [20] Kille, S., "Mapping between X.400(1988) and RFC 822/MIME", RFC 2156, January 1998. [21] Crocker, D., "Standard for the Format of ARPA Internet Text Message", STD 11, RFC 822, August 1982. [22] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. 8. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. Freed & Kille Standards Track [Page 31] RFC 2789 Mail Monitoring MIB March 2000 However, this MIB does provide passive information about the existence, type, and configuration of applications on a given host that could potentially indicate some sort of vulnerability. Finally, the information MIB provides about network usage could be used to analyze network traffic patterns. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Author and Chair Addresses Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: ned.freed@innosoft.com Steve Kille, MADMAN WG Chair MessagingDirect Ltd. The Dome, The Square Richmond TW9 1DT UK Phone: +44 20 8332 9091 EMail: Steve.Kille@MessagingDirect.com Freed & Kille Standards Track [Page 32] RFC 2789 Mail Monitoring MIB March 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Freed & Kille Standards Track [Page 33] snmp-mibs-downloader-1.1/mibrfcs/rfc2790.txt0000644000000000000000000027307711402176071015603 0ustar Network Working Group S. Waldbusser Request for Comments: 2790 Lucent Technologies Inc. Obsoletes: 1514 P. Grillo Category: Standards Track WeSync.com March 2000 Host Resources MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. This memo defines a MIB for use with managing host systems. The term "host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. Waldbusser & Grillo Standards Track [Page 1] RFC 2790 Host Resources MIB March 2000 Table of Contents 1 The SNMP Management Framework ............................ 2 2 Host Resources MIB ....................................... 3 3 IANA Considerations ...................................... 4 4 Definitions .............................................. 4 4.1 Textual Conventions .................................... 6 4.2 The Host Resources System Group ........................ 7 4.3 The Host Resources Storage Group ....................... 9 4.4 The Host Resources Device Group ........................ 12 4.5 The Host Resources Running Software Group .............. 26 4.6 The Host Resources Running Software Performance Group ................................................. 29 4.7 The Host Resources Installed Software Group ............ 30 4.8 Conformance Definitions ................................ 33 5 Type Definitions ......................................... 36 6 Internationalization Considerations ...................... 44 7 Security Considerations .................................. 45 8 References ............................................... 46 9 Acknowledgments .......................................... 48 10 Authors' Addresses ...................................... 49 11 Intellectual Property ................................... 49 12 Full Copyright Statement ................................ 50 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. Waldbusser & Grillo Standards Track [Page 2] RFC 2790 Host Resources MIB March 2000 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Host Resources MIB The Host Resources MIB defines a uniform set of objects useful for the management of host computers. Host computers are independent of the operating system, network services, or any software application. The Host Resources MIB defines objects which are common across many computer system architectures. In addition, there are objects in the SNMPv2-MIB [RFC1907] and IF-MIB [RFC2233] which also provide host management functionality. Implementation of the System and Interfaces groups is mandatory for implementors of the Host Resources MIB. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Waldbusser & Grillo Standards Track [Page 3] RFC 2790 Host Resources MIB March 2000 3. IANA Considerations This MIB contains type definitions for storage types, device types, and file system types for use as values for the hrStorageType, hrDeviceType, and hrFSType objects, respectively. As new computing technologies are developed, new types need to be registered for these technologies. The IANA (Internet Assigned Numbers Authority) is designated as the registration authority for new registrations beyond those published in this document. The IANA will maintain the HOST- RESOURCES-TYPES module as new registrations are added and publish new versions of this module. Given the large number of such technologies and potential confusion in naming of these technologies (such as a technology known by two names or a name and an acronym), there is a real danger that more than one registration might be created for what is essentially the same technology. In order to ensure that future type registrations are performed correctly, applications for new types will be reviewed by a Designated Expert appointed by the IESG. 4. Definitions HOST-RESOURCES-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32, Counter32, Gauge32, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, TruthValue, DateAndTime, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndexOrZero FROM IF-MIB; hostResourcesMibModule MODULE-IDENTITY LAST-UPDATED "200003060000Z" -- 6 March 2000 ORGANIZATION "IETF Host Resources MIB Working Group" CONTACT-INFO "Steve Waldbusser Postal: Lucent Technologies, Inc. 1213 Innsbruck Dr. Sunnyvale, CA 94089 USA Phone: 650-318-1251 Fax: 650-318-1633 Email: waldbusser@lucent.com Waldbusser & Grillo Standards Track [Page 4] RFC 2790 Host Resources MIB March 2000 In addition, the Host Resources MIB mailing list is dedicated to discussion of this MIB. To join the mailing list, send a request message to hostmib-request@andrew.cmu.edu. The mailing list address is hostmib@andrew.cmu.edu." DESCRIPTION "This MIB is for use in managing host systems. The term `host' is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix." REVISION "200003060000Z" -- 6 March 2000 DESCRIPTION "Clarifications and bug fixes based on implementation experience. This revision was also reformatted in the SMIv2 format. The revisions made were: New RFC document standards: Added Copyright notice, updated introduction to SNMP Framework, updated references section, added reference to RFC 2119, and added a meaningful Security Considerations section. New IANA considerations section for registration of new types Conversion to new SMIv2 syntax for the following types and macros: Counter32, Integer32, Gauge32, MODULE-IDENTITY, OBJECT-TYPE, TEXTUAL-CONVENTION, OBJECT-IDENTITY, MODULE-COMPLIANCE, OBJECT-GROUP Used new Textual Conventions: TruthValue, DateAndTime, AutonomousType, InterfaceIndexOrZero Fixed typo in hrPrinterStatus. Added missing error bits to hrPrinterDetectedErrorState and clarified confusion resulting from suggested mappings to hrPrinterStatus. Waldbusser & Grillo Standards Track [Page 5] RFC 2790 Host Resources MIB March 2000 Clarified that size of objects of type InternationalDisplayString is number of octets, not number of encoded symbols. Clarified the use of the following objects based on implementation experience: hrSystemInitialLoadDevice, hrSystemInitialLoadParameters, hrMemorySize, hrStorageSize, hrStorageAllocationFailures, hrDeviceErrors, hrProcessorLoad, hrNetworkIfIndex, hrDiskStorageCapacity, hrSWRunStatus, hrSWRunPerfCPU, and hrSWInstalledDate. Clarified implementation technique for hrSWInstalledTable. Used new AUGMENTS clause for hrSWRunPerfTable. Added Internationalization Considerations section. This revision published as RFC2790." REVISION "9910202200Z" -- 20 October, 1999 DESCRIPTION "The original version of this MIB, published as RFC1514." ::= { hrMIBAdminInfo 1 } host OBJECT IDENTIFIER ::= { mib-2 25 } hrSystem OBJECT IDENTIFIER ::= { host 1 } hrStorage OBJECT IDENTIFIER ::= { host 2 } hrDevice OBJECT IDENTIFIER ::= { host 3 } hrSWRun OBJECT IDENTIFIER ::= { host 4 } hrSWRunPerf OBJECT IDENTIFIER ::= { host 5 } hrSWInstalled OBJECT IDENTIFIER ::= { host 6 } hrMIBAdminInfo OBJECT IDENTIFIER ::= { host 7 } -- textual conventions KBytes ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Storage size, expressed in units of 1024 bytes." SYNTAX Integer32 (0..2147483647) ProductID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention is intended to identify the Waldbusser & Grillo Standards Track [Page 6] RFC 2790 Host Resources MIB March 2000 manufacturer, model, and version of a specific hardware or software product. It is suggested that these OBJECT IDENTIFIERs are allocated such that all products from a particular manufacturer are registered under a subtree distinct to that manufacturer. In addition, all versions of a product should be registered under a subtree distinct to that product. With this strategy, a management station may uniquely determine the manufacturer and/or model of a product whose productID is unknown to the management station. Objects of this type may be useful for inventory purposes or for automatically detecting incompatibilities or version mismatches between various hardware and software components on a system. For example, the product ID for the ACME 4860 66MHz clock doubled processor might be: enterprises.acme.acmeProcessors.a4860DX2.MHz66 A software product might be registered as: enterprises.acme.acmeOperatingSystems.acmeDOS.six(6).one(1) " SYNTAX OBJECT IDENTIFIER -- unknownProduct will be used for any unknown ProductID -- unknownProduct OBJECT IDENTIFIER ::= { 0 0 } InternationalDisplayString ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to model textual information in some character set. A network management station should use a local algorithm to determine which character set is in use and how it should be displayed. Note that this character set may be encoded with more than one octet per symbol, but will most often be NVT ASCII. When a size clause is specified for an object of this type, the size refers to the length in octets, not the number of symbols." SYNTAX OCTET STRING -- The Host Resources System Group hrSystemUptime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser & Grillo Standards Track [Page 7] RFC 2790 Host Resources MIB March 2000 "The amount of time since this host was last initialized. Note that this is different from sysUpTime in the SNMPv2-MIB [RFC1907] because sysUpTime is the uptime of the network management portion of the system." ::= { hrSystem 1 } hrSystemDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-write STATUS current DESCRIPTION "The host's notion of the local date and time of day." ::= { hrSystem 2 } hrSystemInitialLoadDevice OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The index of the hrDeviceEntry for the device from which this host is configured to load its initial operating system configuration (i.e., which operating system code and/or boot parameters). Note that writing to this object just changes the configuration that will be used the next time the operating system is loaded and does not actually cause the reload to occur." ::= { hrSystem 3 } hrSystemInitialLoadParameters OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE (0..128)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains the parameters (e.g. a pathname and parameter) supplied to the load device when requesting the initial operating system configuration from that device. Note that writing to this object just changes the configuration that will be used the next time the operating system is loaded and does not actually cause the reload to occur." ::= { hrSystem 4 } hrSystemNumUsers OBJECT-TYPE Waldbusser & Grillo Standards Track [Page 8] RFC 2790 Host Resources MIB March 2000 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user sessions for which this host is storing state information. A session is a collection of processes requiring a single act of user authentication and possibly subject to collective job control." ::= { hrSystem 5 } hrSystemProcesses OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of process contexts currently loaded or running on this system." ::= { hrSystem 6 } hrSystemMaxProcesses OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of process contexts this system can support. If there is no fixed maximum, the value should be zero. On systems that have a fixed maximum, this object can help diagnose failures that occur when this maximum is reached." ::= { hrSystem 7 } -- The Host Resources Storage Group -- Registration point for storage types, for use with hrStorageType. -- These are defined in the HOST-RESOURCES-TYPES module. hrStorageTypes OBJECT IDENTIFIER ::= { hrStorage 1 } hrMemorySize OBJECT-TYPE SYNTAX KBytes UNITS "KBytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of physical read-write main memory, typically RAM, contained by the host." ::= { hrStorage 2 } Waldbusser & Grillo Standards Track [Page 9] RFC 2790 Host Resources MIB March 2000 hrStorageTable OBJECT-TYPE SYNTAX SEQUENCE OF HrStorageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of logical storage areas on the host. An entry shall be placed in the storage table for each logical area of storage that is allocated and has fixed resource limits. The amount of storage represented in an entity is the amount actually usable by the requesting entity, and excludes loss due to formatting or file system reference information. These entries are associated with logical storage areas, as might be seen by an application, rather than physical storage entities which are typically seen by an operating system. Storage such as tapes and floppies without file systems on them are typically not allocated in chunks by the operating system to requesting applications, and therefore shouldn't appear in this table. Examples of valid storage for this table include disk partitions, file systems, ram (for some architectures this is further segmented into regular memory, extended memory, and so on), backing store for virtual memory (`swap space'). This table is intended to be a useful diagnostic for `out of memory' and `out of buffers' types of failures. In addition, it can be a useful performance monitoring tool for tracking memory, disk, or buffer usage." ::= { hrStorage 3 } hrStorageEntry OBJECT-TYPE SYNTAX HrStorageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one logical storage area on the host. As an example, an instance of the hrStorageType object might be named hrStorageType.3" INDEX { hrStorageIndex } ::= { hrStorageTable 1 } HrStorageEntry ::= SEQUENCE { hrStorageIndex Integer32, Waldbusser & Grillo Standards Track [Page 10] RFC 2790 Host Resources MIB March 2000 hrStorageType AutonomousType, hrStorageDescr DisplayString, hrStorageAllocationUnits Integer32, hrStorageSize Integer32, hrStorageUsed Integer32, hrStorageAllocationFailures Counter32 } hrStorageIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each logical storage area contained by the host." ::= { hrStorageEntry 1 } hrStorageType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of storage represented by this entry." ::= { hrStorageEntry 2 } hrStorageDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the type and instance of the storage described by this entry." ::= { hrStorageEntry 3 } hrStorageAllocationUnits OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The size, in bytes, of the data objects allocated from this pool. If this entry is monitoring sectors, blocks, buffers, or packets, for example, this number will commonly be greater than one. Otherwise this number will typically be one." ::= { hrStorageEntry 4 } hrStorageSize OBJECT-TYPE Waldbusser & Grillo Standards Track [Page 11] RFC 2790 Host Resources MIB March 2000 SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The size of the storage represented by this entry, in units of hrStorageAllocationUnits. This object is writable to allow remote configuration of the size of the storage area in those cases where such an operation makes sense and is possible on the underlying system. For example, the amount of main memory allocated to a buffer pool might be modified or the amount of disk space allocated to virtual memory might be modified." ::= { hrStorageEntry 5 } hrStorageUsed OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of the storage represented by this entry that is allocated, in units of hrStorageAllocationUnits." ::= { hrStorageEntry 6 } hrStorageAllocationFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests for storage represented by this entry that could not be honored due to not enough storage. It should be noted that as this object has a SYNTAX of Counter32, that it does not have a defined initial value. However, it is recommended that this object be initialized to zero, even though management stations must not depend on such an initialization." ::= { hrStorageEntry 7 } -- The Host Resources Device Group -- -- The device group is useful for identifying and diagnosing the -- devices on a system. The hrDeviceTable contains common -- information for any type of device. In addition, some devices -- have device-specific tables for more detailed information. More -- such tables may be defined in the future for other device types. -- Registration point for device types, for use with hrDeviceType. Waldbusser & Grillo Standards Track [Page 12] RFC 2790 Host Resources MIB March 2000 -- These are defined in the HOST-RESOURCES-TYPES module. hrDeviceTypes OBJECT IDENTIFIER ::= { hrDevice 1 } hrDeviceTable OBJECT-TYPE SYNTAX SEQUENCE OF HrDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of devices contained by the host." ::= { hrDevice 2 } hrDeviceEntry OBJECT-TYPE SYNTAX HrDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one device contained by the host. As an example, an instance of the hrDeviceType object might be named hrDeviceType.3" INDEX { hrDeviceIndex } ::= { hrDeviceTable 1 } HrDeviceEntry ::= SEQUENCE { hrDeviceIndex Integer32, hrDeviceType AutonomousType, hrDeviceDescr DisplayString, hrDeviceID ProductID, hrDeviceStatus INTEGER, hrDeviceErrors Counter32 } hrDeviceIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each device contained by the host. The value for each device must remain constant at least from one re-initialization of the agent to the next re-initialization." ::= { hrDeviceEntry 1 } hrDeviceType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser & Grillo Standards Track [Page 13] RFC 2790 Host Resources MIB March 2000 "An indication of the type of device. If this value is `hrDeviceProcessor { hrDeviceTypes 3 }' then an entry exists in the hrProcessorTable which corresponds to this device. If this value is `hrDeviceNetwork { hrDeviceTypes 4 }', then an entry exists in the hrNetworkTable which corresponds to this device. If this value is `hrDevicePrinter { hrDeviceTypes 5 }', then an entry exists in the hrPrinterTable which corresponds to this device. If this value is `hrDeviceDiskStorage { hrDeviceTypes 6 }', then an entry exists in the hrDiskStorageTable which corresponds to this device." ::= { hrDeviceEntry 2 } hrDeviceDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of this device, including the device's manufacturer and revision, and optionally, its serial number." ::= { hrDeviceEntry 3 } hrDeviceID OBJECT-TYPE SYNTAX ProductID MAX-ACCESS read-only STATUS current DESCRIPTION "The product ID for this device." ::= { hrDeviceEntry 4 } hrDeviceStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), running(2), warning(3), testing(4), down(5) Waldbusser & Grillo Standards Track [Page 14] RFC 2790 Host Resources MIB March 2000 } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the device described by this row of the table. A value unknown(1) indicates that the current state of the device is unknown. running(2) indicates that the device is up and running and that no unusual error conditions are known. The warning(3) state indicates that agent has been informed of an unusual error condition by the operational software (e.g., a disk device driver) but that the device is still 'operational'. An example would be a high number of soft errors on a disk. A value of testing(4), indicates that the device is not available for use because it is in the testing state. The state of down(5) is used only when the agent has been informed that the device is not available for any use." ::= { hrDeviceEntry 5 } hrDeviceErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of errors detected on this device. It should be noted that as this object has a SYNTAX of Counter32, that it does not have a defined initial value. However, it is recommended that this object be initialized to zero, even though management stations must not depend on such an initialization." ::= { hrDeviceEntry 6 } hrProcessorTable OBJECT-TYPE SYNTAX SEQUENCE OF HrProcessorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of processors contained by the host. Note that this table is potentially sparse: a (conceptual) entry exists only if the correspondent value of the hrDeviceType object is `hrDeviceProcessor'." ::= { hrDevice 3 } Waldbusser & Grillo Standards Track [Page 15] RFC 2790 Host Resources MIB March 2000 hrProcessorEntry OBJECT-TYPE SYNTAX HrProcessorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one processor contained by the host. The hrDeviceIndex in the index represents the entry in the hrDeviceTable that corresponds to the hrProcessorEntry. As an example of how objects in this table are named, an instance of the hrProcessorFrwID object might be named hrProcessorFrwID.3" INDEX { hrDeviceIndex } ::= { hrProcessorTable 1 } HrProcessorEntry ::= SEQUENCE { hrProcessorFrwID ProductID, hrProcessorLoad Integer32 } hrProcessorFrwID OBJECT-TYPE SYNTAX ProductID MAX-ACCESS read-only STATUS current DESCRIPTION "The product ID of the firmware associated with the processor." ::= { hrProcessorEntry 1 } hrProcessorLoad OBJECT-TYPE SYNTAX Integer32 (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "The average, over the last minute, of the percentage of time that this processor was not idle. Implementations may approximate this one minute smoothing period if necessary." ::= { hrProcessorEntry 2 } hrNetworkTable OBJECT-TYPE SYNTAX SEQUENCE OF HrNetworkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of network devices contained by the host. Waldbusser & Grillo Standards Track [Page 16] RFC 2790 Host Resources MIB March 2000 Note that this table is potentially sparse: a (conceptual) entry exists only if the correspondent value of the hrDeviceType object is `hrDeviceNetwork'." ::= { hrDevice 4 } hrNetworkEntry OBJECT-TYPE SYNTAX HrNetworkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one network device contained by the host. The hrDeviceIndex in the index represents the entry in the hrDeviceTable that corresponds to the hrNetworkEntry. As an example of how objects in this table are named, an instance of the hrNetworkIfIndex object might be named hrNetworkIfIndex.3" INDEX { hrDeviceIndex } ::= { hrNetworkTable 1 } HrNetworkEntry ::= SEQUENCE { hrNetworkIfIndex InterfaceIndexOrZero } hrNetworkIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex which corresponds to this network device. If this device is not represented in the ifTable, then this value shall be zero." ::= { hrNetworkEntry 1 } hrPrinterTable OBJECT-TYPE SYNTAX SEQUENCE OF HrPrinterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of printers local to the host. Note that this table is potentially sparse: a (conceptual) entry exists only if the correspondent value of the hrDeviceType object is `hrDevicePrinter'." ::= { hrDevice 5 } Waldbusser & Grillo Standards Track [Page 17] RFC 2790 Host Resources MIB March 2000 hrPrinterEntry OBJECT-TYPE SYNTAX HrPrinterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one printer local to the host. The hrDeviceIndex in the index represents the entry in the hrDeviceTable that corresponds to the hrPrinterEntry. As an example of how objects in this table are named, an instance of the hrPrinterStatus object might be named hrPrinterStatus.3" INDEX { hrDeviceIndex } ::= { hrPrinterTable 1 } HrPrinterEntry ::= SEQUENCE { hrPrinterStatus INTEGER, hrPrinterDetectedErrorState OCTET STRING } hrPrinterStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), idle(3), printing(4), warmup(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of this printer device." ::= { hrPrinterEntry 1 } hrPrinterDetectedErrorState OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents any error conditions detected by the printer. The error conditions are encoded as bits in an octet string, with the following definitions: Condition Bit # lowPaper 0 Waldbusser & Grillo Standards Track [Page 18] RFC 2790 Host Resources MIB March 2000 noPaper 1 lowToner 2 noToner 3 doorOpen 4 jammed 5 offline 6 serviceRequested 7 inputTrayMissing 8 outputTrayMissing 9 markerSupplyMissing 10 outputNearFull 11 outputFull 12 inputTrayEmpty 13 overduePreventMaint 14 Bits are numbered starting with the most significant bit of the first byte being bit 0, the least significant bit of the first byte being bit 7, the most significant bit of the second byte being bit 8, and so on. A one bit encodes that the condition was detected, while a zero bit encodes that the condition was not detected. This object is useful for alerting an operator to specific warning or error conditions that may occur, especially those requiring human intervention." ::= { hrPrinterEntry 2 } hrDiskStorageTable OBJECT-TYPE SYNTAX SEQUENCE OF HrDiskStorageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of long-term storage devices contained by the host. In particular, disk devices accessed remotely over a network are not included here. Note that this table is potentially sparse: a (conceptual) entry exists only if the correspondent value of the hrDeviceType object is `hrDeviceDiskStorage'." ::= { hrDevice 6 } hrDiskStorageEntry OBJECT-TYPE SYNTAX HrDiskStorageEntry MAX-ACCESS not-accessible STATUS current Waldbusser & Grillo Standards Track [Page 19] RFC 2790 Host Resources MIB March 2000 DESCRIPTION "A (conceptual) entry for one long-term storage device contained by the host. The hrDeviceIndex in the index represents the entry in the hrDeviceTable that corresponds to the hrDiskStorageEntry. As an example, an instance of the hrDiskStorageCapacity object might be named hrDiskStorageCapacity.3" INDEX { hrDeviceIndex } ::= { hrDiskStorageTable 1 } HrDiskStorageEntry ::= SEQUENCE { hrDiskStorageAccess INTEGER, hrDiskStorageMedia INTEGER, hrDiskStorageRemoveble TruthValue, hrDiskStorageCapacity KBytes } hrDiskStorageAccess OBJECT-TYPE SYNTAX INTEGER { readWrite(1), readOnly(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication if this long-term storage device is readable and writable or only readable. This should reflect the media type, any write-protect mechanism, and any device configuration that affects the entire device." ::= { hrDiskStorageEntry 1 } hrDiskStorageMedia OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), hardDisk(3), floppyDisk(4), opticalDiskROM(5), opticalDiskWORM(6), -- Write Once Read Many opticalDiskRW(7), ramDisk(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the type of media used in this long- term storage device." Waldbusser & Grillo Standards Track [Page 20] RFC 2790 Host Resources MIB March 2000 ::= { hrDiskStorageEntry 2 } hrDiskStorageRemoveble OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes whether or not the disk media may be removed from the drive." ::= { hrDiskStorageEntry 3 } hrDiskStorageCapacity OBJECT-TYPE SYNTAX KBytes UNITS "KBytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total size for this long-term storage device. If the media is removable and is currently removed, this value should be zero." ::= { hrDiskStorageEntry 4 } hrPartitionTable OBJECT-TYPE SYNTAX SEQUENCE OF HrPartitionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of partitions for long-term storage devices contained by the host. In particular, partitions accessed remotely over a network are not included here." ::= { hrDevice 7 } hrPartitionEntry OBJECT-TYPE SYNTAX HrPartitionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one partition. The hrDeviceIndex in the index represents the entry in the hrDeviceTable that corresponds to the hrPartitionEntry. As an example of how objects in this table are named, an instance of the hrPartitionSize object might be named hrPartitionSize.3.1" INDEX { hrDeviceIndex, hrPartitionIndex } ::= { hrPartitionTable 1 } Waldbusser & Grillo Standards Track [Page 21] RFC 2790 Host Resources MIB March 2000 HrPartitionEntry ::= SEQUENCE { hrPartitionIndex Integer32, hrPartitionLabel InternationalDisplayString, hrPartitionID OCTET STRING, hrPartitionSize KBytes, hrPartitionFSIndex Integer32 } hrPartitionIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each partition on this long-term storage device. The value for each long-term storage device must remain constant at least from one re- initialization of the agent to the next re- initialization." ::= { hrPartitionEntry 1 } hrPartitionLabel OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of this partition." ::= { hrPartitionEntry 2 } hrPartitionID OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "A descriptor which uniquely represents this partition to the responsible operating system. On some systems, this might take on a binary representation." ::= { hrPartitionEntry 3 } hrPartitionSize OBJECT-TYPE SYNTAX KBytes UNITS "KBytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The size of this partition." ::= { hrPartitionEntry 4 } hrPartitionFSIndex OBJECT-TYPE Waldbusser & Grillo Standards Track [Page 22] RFC 2790 Host Resources MIB March 2000 SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the file system mounted on this partition. If no file system is mounted on this partition, then this value shall be zero. Note that multiple partitions may point to one file system, denoting that that file system resides on those partitions. Multiple file systems may not reside on one partition." ::= { hrPartitionEntry 5 } -- The File System Table -- Registration point for popular File System types, -- for use with hrFSType. These are defined in the -- HOST-RESOURCES-TYPES module. hrFSTypes OBJECT IDENTIFIER ::= { hrDevice 9 } hrFSTable OBJECT-TYPE SYNTAX SEQUENCE OF HrFSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of file systems local to this host or remotely mounted from a file server. File systems that are in only one user's environment on a multi-user system will not be included in this table." ::= { hrDevice 8 } hrFSEntry OBJECT-TYPE SYNTAX HrFSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one file system local to this host or remotely mounted from a file server. File systems that are in only one user's environment on a multi-user system will not be included in this table. As an example of how objects in this table are named, an instance of the hrFSMountPoint object might be named hrFSMountPoint.3" INDEX { hrFSIndex } ::= { hrFSTable 1 } Waldbusser & Grillo Standards Track [Page 23] RFC 2790 Host Resources MIB March 2000 HrFSEntry ::= SEQUENCE { hrFSIndex Integer32, hrFSMountPoint InternationalDisplayString, hrFSRemoteMountPoint InternationalDisplayString, hrFSType AutonomousType, hrFSAccess INTEGER, hrFSBootable TruthValue, hrFSStorageIndex Integer32, hrFSLastFullBackupDate DateAndTime, hrFSLastPartialBackupDate DateAndTime } hrFSIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each file system local to this host. The value for each file system must remain constant at least from one re-initialization of the agent to the next re-initialization." ::= { hrFSEntry 1 } hrFSMountPoint OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The path name of the root of this file system." ::= { hrFSEntry 2 } hrFSRemoteMountPoint OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the name and/or address of the server that this file system is mounted from. This may also include parameters such as the mount point on the remote file system. If this is not a remote file system, this string should have a length of zero." ::= { hrFSEntry 3 } hrFSType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser & Grillo Standards Track [Page 24] RFC 2790 Host Resources MIB March 2000 "The value of this object identifies the type of this file system." ::= { hrFSEntry 4 } hrFSAccess OBJECT-TYPE SYNTAX INTEGER { readWrite(1), readOnly(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication if this file system is logically configured by the operating system to be readable and writable or only readable. This does not represent any local access-control policy, except one that is applied to the file system as a whole." ::= { hrFSEntry 5 } hrFSBootable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether this file system is bootable." ::= { hrFSEntry 6 } hrFSStorageIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the hrStorageEntry that represents information about this file system. If there is no such information available, then this value shall be zero. The relevant storage entry will be useful in tracking the percent usage of this file system and diagnosing errors that may occur when it runs out of space." ::= { hrFSEntry 7 } hrFSLastFullBackupDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-write STATUS current DESCRIPTION "The last date at which this complete file system was Waldbusser & Grillo Standards Track [Page 25] RFC 2790 Host Resources MIB March 2000 copied to another storage device for backup. This information is useful for ensuring that backups are being performed regularly. If this information is not known, then this variable shall have the value corresponding to January 1, year 0000, 00:00:00.0, which is encoded as (hex)'00 00 01 01 00 00 00 00'." ::= { hrFSEntry 8 } hrFSLastPartialBackupDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-write STATUS current DESCRIPTION "The last date at which a portion of this file system was copied to another storage device for backup. This information is useful for ensuring that backups are being performed regularly. If this information is not known, then this variable shall have the value corresponding to January 1, year 0000, 00:00:00.0, which is encoded as (hex)'00 00 01 01 00 00 00 00'." ::= { hrFSEntry 9 } -- The Host Resources Running Software Group -- -- The hrSWRunTable contains an entry for each distinct piece of -- software that is running or loaded into physical or virtual -- memory in preparation for running. This includes the host's -- operating system, device drivers, and applications. hrSWOSIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the hrSWRunIndex for the hrSWRunEntry that represents the primary operating system running on this host. This object is useful for quickly and uniquely identifying that primary operating system." ::= { hrSWRun 1 } hrSWRunTable OBJECT-TYPE SYNTAX SEQUENCE OF HrSWRunEntry MAX-ACCESS not-accessible STATUS current Waldbusser & Grillo Standards Track [Page 26] RFC 2790 Host Resources MIB March 2000 DESCRIPTION "The (conceptual) table of software running on the host." ::= { hrSWRun 2 } hrSWRunEntry OBJECT-TYPE SYNTAX HrSWRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one piece of software running on the host Note that because the installed software table only contains information for software stored locally on this host, not every piece of running software will be found in the installed software table. This is true of software that was loaded and run from a non-local source, such as a network-mounted file system. As an example of how objects in this table are named, an instance of the hrSWRunName object might be named hrSWRunName.1287" INDEX { hrSWRunIndex } ::= { hrSWRunTable 1 } HrSWRunEntry ::= SEQUENCE { hrSWRunIndex Integer32, hrSWRunName InternationalDisplayString, hrSWRunID ProductID, hrSWRunPath InternationalDisplayString, hrSWRunParameters InternationalDisplayString, hrSWRunType INTEGER, hrSWRunStatus INTEGER } hrSWRunIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each piece of software running on the host. Wherever possible, this should be the system's native, unique identification number." ::= { hrSWRunEntry 1 } hrSWRunName OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE (0..64)) MAX-ACCESS read-only Waldbusser & Grillo Standards Track [Page 27] RFC 2790 Host Resources MIB March 2000 STATUS current DESCRIPTION "A textual description of this running piece of software, including the manufacturer, revision, and the name by which it is commonly known. If this software was installed locally, this should be the same string as used in the corresponding hrSWInstalledName." ::= { hrSWRunEntry 2 } hrSWRunID OBJECT-TYPE SYNTAX ProductID MAX-ACCESS read-only STATUS current DESCRIPTION "The product ID of this running piece of software." ::= { hrSWRunEntry 3 } hrSWRunPath OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the location on long-term storage (e.g. a disk drive) from which this software was loaded." ::= { hrSWRunEntry 4 } hrSWRunParameters OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the parameters supplied to this software when it was initially loaded." ::= { hrSWRunEntry 5 } hrSWRunType OBJECT-TYPE SYNTAX INTEGER { unknown(1), operatingSystem(2), deviceDriver(3), application(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this software." Waldbusser & Grillo Standards Track [Page 28] RFC 2790 Host Resources MIB March 2000 ::= { hrSWRunEntry 6 } hrSWRunStatus OBJECT-TYPE SYNTAX INTEGER { running(1), runnable(2), -- waiting for resource -- (i.e., CPU, memory, IO) notRunnable(3), -- loaded but waiting for event invalid(4) -- not loaded } MAX-ACCESS read-write STATUS current DESCRIPTION "The status of this running piece of software. Setting this value to invalid(4) shall cause this software to stop running and to be unloaded. Sets to other values are not valid." ::= { hrSWRunEntry 7 } -- The Host Resources Running Software Performance Group -- -- The hrSWRunPerfTable contains an entry corresponding to -- each entry in the hrSWRunTable. hrSWRunPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF HrSWRunPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of running software performance metrics." ::= { hrSWRunPerf 1 } hrSWRunPerfEntry OBJECT-TYPE SYNTAX HrSWRunPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry containing software performance metrics. As an example, an instance of the hrSWRunPerfCPU object might be named hrSWRunPerfCPU.1287" AUGMENTS { hrSWRunEntry } -- This table augments information in -- the hrSWRunTable. ::= { hrSWRunPerfTable 1 } HrSWRunPerfEntry ::= SEQUENCE { hrSWRunPerfCPU Integer32, Waldbusser & Grillo Standards Track [Page 29] RFC 2790 Host Resources MIB March 2000 hrSWRunPerfMem KBytes } hrSWRunPerfCPU OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of centi-seconds of the total system's CPU resources consumed by this process. Note that on a multi-processor system, this value may increment by more than one centi-second in one centi-second of real (wall clock) time." ::= { hrSWRunPerfEntry 1 } hrSWRunPerfMem OBJECT-TYPE SYNTAX KBytes UNITS "KBytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of real system memory allocated to this process." ::= { hrSWRunPerfEntry 2 } -- The Host Resources Installed Software Group -- -- The hrSWInstalledTable contains an entry for each piece -- of software installed in long-term storage (e.g. a disk -- drive) locally on this host. Note that this does not -- include software loadable remotely from a network -- server. -- -- Different implementations may track software in varying -- ways. For example, while some implementations may track -- executable files as distinct pieces of software, other -- implementations may use other strategies such as keeping -- track of software "packages" (e.g., related groups of files) -- or keeping track of system or application "patches". -- -- This table is useful for identifying and inventorying -- software on a host and for diagnosing incompatibility -- and version mismatch problems between various pieces -- of hardware and software. hrSWInstalledLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Waldbusser & Grillo Standards Track [Page 30] RFC 2790 Host Resources MIB March 2000 STATUS current DESCRIPTION "The value of sysUpTime when an entry in the hrSWInstalledTable was last added, renamed, or deleted. Because this table is likely to contain many entries, polling of this object allows a management station to determine when re-downloading of the table might be useful." ::= { hrSWInstalled 1 } hrSWInstalledLastUpdateTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the hrSWInstalledTable was last completely updated. Because caching of this data will be a popular implementation strategy, retrieval of this object allows a management station to obtain a guarantee that no data in this table is older than the indicated time." ::= { hrSWInstalled 2 } hrSWInstalledTable OBJECT-TYPE SYNTAX SEQUENCE OF HrSWInstalledEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of software installed on this host." ::= { hrSWInstalled 3 } hrSWInstalledEntry OBJECT-TYPE SYNTAX HrSWInstalledEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for a piece of software installed on this host. As an example of how objects in this table are named, an instance of the hrSWInstalledName object might be named hrSWInstalledName.96" INDEX { hrSWInstalledIndex } ::= { hrSWInstalledTable 1 } HrSWInstalledEntry ::= SEQUENCE { hrSWInstalledIndex Integer32, Waldbusser & Grillo Standards Track [Page 31] RFC 2790 Host Resources MIB March 2000 hrSWInstalledName InternationalDisplayString, hrSWInstalledID ProductID, hrSWInstalledType INTEGER, hrSWInstalledDate DateAndTime } hrSWInstalledIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value for each piece of software installed on the host. This value shall be in the range from 1 to the number of pieces of software installed on the host." ::= { hrSWInstalledEntry 1 } hrSWInstalledName OBJECT-TYPE SYNTAX InternationalDisplayString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of this installed piece of software, including the manufacturer, revision, the name by which it is commonly known, and optionally, its serial number." ::= { hrSWInstalledEntry 2 } hrSWInstalledID OBJECT-TYPE SYNTAX ProductID MAX-ACCESS read-only STATUS current DESCRIPTION "The product ID of this installed piece of software." ::= { hrSWInstalledEntry 3 } hrSWInstalledType OBJECT-TYPE SYNTAX INTEGER { unknown(1), operatingSystem(2), deviceDriver(3), application(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this software." ::= { hrSWInstalledEntry 4 } Waldbusser & Grillo Standards Track [Page 32] RFC 2790 Host Resources MIB March 2000 hrSWInstalledDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The last-modification date of this application as it would appear in a directory listing. If this information is not known, then this variable shall have the value corresponding to January 1, year 0000, 00:00:00.0, which is encoded as (hex)'00 00 01 01 00 00 00 00'." ::= { hrSWInstalledEntry 5 } -- Conformance information hrMIBCompliances OBJECT IDENTIFIER ::= { hrMIBAdminInfo 2 } hrMIBGroups OBJECT IDENTIFIER ::= { hrMIBAdminInfo 3 } -- Compliance Statements hrMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The requirements for conformance to the Host Resources MIB." MODULE -- this module MANDATORY-GROUPS { hrSystemGroup, hrStorageGroup, hrDeviceGroup } OBJECT hrSystemDate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT hrSystemInitialLoadDevice MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT hrSystemInitialLoadParameters MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT hrStorageSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." Waldbusser & Grillo Standards Track [Page 33] RFC 2790 Host Resources MIB March 2000 OBJECT hrFSLastFullBackupDate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT hrFSLastPartialBackupDate MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP hrSWRunGroup DESCRIPTION "The Running Software Group. Implementation of this group is mandatory only when the hrSWRunPerfGroup is implemented." OBJECT hrSWRunStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP hrSWRunPerfGroup DESCRIPTION "The Running Software Performance Group. Implementation of this group is at the discretion of the implementor." GROUP hrSWInstalledGroup DESCRIPTION "The Installed Software Group. Implementation of this group is at the discretion of the implementor." ::= { hrMIBCompliances 1 } hrSystemGroup OBJECT-GROUP OBJECTS { hrSystemUptime, hrSystemDate, hrSystemInitialLoadDevice, hrSystemInitialLoadParameters, hrSystemNumUsers, hrSystemProcesses, hrSystemMaxProcesses } STATUS current DESCRIPTION "The Host Resources System Group." ::= { hrMIBGroups 1 } Waldbusser & Grillo Standards Track [Page 34] RFC 2790 Host Resources MIB March 2000 hrStorageGroup OBJECT-GROUP OBJECTS { hrMemorySize, hrStorageIndex, hrStorageType, hrStorageDescr, hrStorageAllocationUnits, hrStorageSize, hrStorageUsed, hrStorageAllocationFailures } STATUS current DESCRIPTION "The Host Resources Storage Group." ::= { hrMIBGroups 2 } hrDeviceGroup OBJECT-GROUP OBJECTS { hrDeviceIndex, hrDeviceType, hrDeviceDescr, hrDeviceID, hrDeviceStatus, hrDeviceErrors, hrProcessorFrwID, hrProcessorLoad, hrNetworkIfIndex, hrPrinterStatus, hrPrinterDetectedErrorState, hrDiskStorageAccess, hrDiskStorageMedia, hrDiskStorageRemoveble, hrDiskStorageCapacity, hrPartitionIndex, hrPartitionLabel, hrPartitionID, hrPartitionSize, hrPartitionFSIndex, hrFSIndex, hrFSMountPoint, hrFSRemoteMountPoint, hrFSType, hrFSAccess, hrFSBootable, hrFSStorageIndex, hrFSLastFullBackupDate, hrFSLastPartialBackupDate } STATUS current DESCRIPTION "The Host Resources Device Group." ::= { hrMIBGroups 3 } hrSWRunGroup OBJECT-GROUP OBJECTS { hrSWOSIndex, hrSWRunIndex, hrSWRunName, hrSWRunID, hrSWRunPath, hrSWRunParameters, hrSWRunType, hrSWRunStatus } STATUS current DESCRIPTION "The Host Resources Running Software Group." ::= { hrMIBGroups 4 } hrSWRunPerfGroup OBJECT-GROUP OBJECTS { hrSWRunPerfCPU, hrSWRunPerfMem } STATUS current Waldbusser & Grillo Standards Track [Page 35] RFC 2790 Host Resources MIB March 2000 DESCRIPTION "The Host Resources Running Software Performance Group." ::= { hrMIBGroups 5 } hrSWInstalledGroup OBJECT-GROUP OBJECTS { hrSWInstalledLastChange, hrSWInstalledLastUpdateTime, hrSWInstalledIndex, hrSWInstalledName, hrSWInstalledID, hrSWInstalledType, hrSWInstalledDate } STATUS current DESCRIPTION "The Host Resources Installed Software Group." ::= { hrMIBGroups 6 } END 5. Type Definitions HOST-RESOURCES-TYPES DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI hrMIBAdminInfo, hrStorage, hrDevice FROM HOST-RESOURCES-MIB; hostResourcesTypesModule MODULE-IDENTITY LAST-UPDATED "200003060000Z" -- 6 March, 2000 ORGANIZATION "IETF Host Resources MIB Working Group" CONTACT-INFO "Steve Waldbusser Postal: Lucent Technologies, Inc. 1213 Innsbruck Dr. Sunnyvale, CA 94089 USA Phone: 650-318-1251 Fax: 650-318-1633 Email: waldbusser@ins.com In addition, the Host Resources MIB mailing list is dedicated to discussion of this MIB. To join the mailing list, send a request message to hostmib-request@andrew.cmu.edu. The mailing list address is hostmib@andrew.cmu.edu." DESCRIPTION "This MIB module registers type definitions for storage types, device types, and file system types. Waldbusser & Grillo Standards Track [Page 36] RFC 2790 Host Resources MIB March 2000 After the initial revision, this module will be maintained by IANA." REVISION "200003060000Z" -- 6 March 2000 DESCRIPTION "The original version of this module, published as RFC 2790." ::= { hrMIBAdminInfo 4 } -- Registrations for some storage types, for use with hrStorageType hrStorageTypes OBJECT IDENTIFIER ::= { hrStorage 1 } hrStorageOther OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used when no other defined type is appropriate." ::= { hrStorageTypes 1 } hrStorageRam OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for RAM." ::= { hrStorageTypes 2 } hrStorageVirtualMemory OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for virtual memory, temporary storage of swapped or paged memory." ::= { hrStorageTypes 3 } hrStorageFixedDisk OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for non-removable rigid rotating magnetic storage devices." ::= { hrStorageTypes 4 } hrStorageRemovableDisk OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for removable rigid rotating magnetic storage devices." ::= { hrStorageTypes 5 } hrStorageFloppyDisk OBJECT-IDENTITY STATUS current DESCRIPTION Waldbusser & Grillo Standards Track [Page 37] RFC 2790 Host Resources MIB March 2000 "The storage type identifier used for non-rigid rotating magnetic storage devices." ::= { hrStorageTypes 6 } hrStorageCompactDisc OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for read-only rotating optical storage devices." ::= { hrStorageTypes 7 } hrStorageRamDisk OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for a file system that is stored in RAM." ::= { hrStorageTypes 8 } hrStorageFlashMemory OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for flash memory." ::= { hrStorageTypes 9 } hrStorageNetworkDisk OBJECT-IDENTITY STATUS current DESCRIPTION "The storage type identifier used for a networked file system." ::= { hrStorageTypes 10 } -- Registrations for some device types, for use with hrDeviceType hrDeviceTypes OBJECT IDENTIFIER ::= { hrDevice 1 } hrDeviceOther OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used when no other defined type is appropriate." ::= { hrDeviceTypes 1 } hrDeviceUnknown OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used when the device type is unknown." ::= { hrDeviceTypes 2 } Waldbusser & Grillo Standards Track [Page 38] RFC 2790 Host Resources MIB March 2000 hrDeviceProcessor OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a CPU." ::= { hrDeviceTypes 3 } hrDeviceNetwork OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a network interface." ::= { hrDeviceTypes 4 } hrDevicePrinter OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a printer." ::= { hrDeviceTypes 5 } hrDeviceDiskStorage OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a disk drive." ::= { hrDeviceTypes 6 } hrDeviceVideo OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a video device." ::= { hrDeviceTypes 10 } hrDeviceAudio OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for an audio device." ::= { hrDeviceTypes 11 } hrDeviceCoprocessor OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a co-processor." ::= { hrDeviceTypes 12 } hrDeviceKeyboard OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a keyboard device." ::= { hrDeviceTypes 13 } Waldbusser & Grillo Standards Track [Page 39] RFC 2790 Host Resources MIB March 2000 hrDeviceModem OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a modem." ::= { hrDeviceTypes 14 } hrDeviceParallelPort OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a parallel port." ::= { hrDeviceTypes 15 } hrDevicePointing OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a pointing device (e.g., a mouse)." ::= { hrDeviceTypes 16 } hrDeviceSerialPort OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a serial port." ::= { hrDeviceTypes 17 } hrDeviceTape OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a tape storage device." ::= { hrDeviceTypes 18 } hrDeviceClock OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a clock device." ::= { hrDeviceTypes 19 } hrDeviceVolatileMemory OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a volatile memory storage device." ::= { hrDeviceTypes 20 } hrDeviceNonVolatileMemory OBJECT-IDENTITY STATUS current DESCRIPTION "The device type identifier used for a non-volatile memory Waldbusser & Grillo Standards Track [Page 40] RFC 2790 Host Resources MIB March 2000 storage device." ::= { hrDeviceTypes 21 } -- Registrations for some popular File System types, -- for use with hrFSType. hrFSTypes OBJECT IDENTIFIER ::= { hrDevice 9 } hrFSOther OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used when no other defined type is appropriate." ::= { hrFSTypes 1 } hrFSUnknown OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used when the type of file system is unknown." ::= { hrFSTypes 2 } hrFSBerkeleyFFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Berkeley Fast File System." ::= { hrFSTypes 3 } hrFSSys5FS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the System V File System." ::= { hrFSTypes 4 } hrFSFat OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for DOS's FAT file system." ::= { hrFSTypes 5 } hrFSHPFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for OS/2's High Performance File System." ::= { hrFSTypes 6 } Waldbusser & Grillo Standards Track [Page 41] RFC 2790 Host Resources MIB March 2000 hrFSHFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Macintosh Hierarchical File System." ::= { hrFSTypes 7 } hrFSMFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Macintosh File System." ::= { hrFSTypes 8 } hrFSNTFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Windows NT File System." ::= { hrFSTypes 9 } hrFSVNode OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the VNode File System." ::= { hrFSTypes 10 } hrFSJournaled OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Journaled File System." ::= { hrFSTypes 11 } hrFSiso9660 OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the ISO 9660 File System for CD's." ::= { hrFSTypes 12 } hrFSRockRidge OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the RockRidge File System for CD's." ::= { hrFSTypes 13 } Waldbusser & Grillo Standards Track [Page 42] RFC 2790 Host Resources MIB March 2000 hrFSNFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the NFS File System." ::= { hrFSTypes 14 } hrFSNetware OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Netware File System." ::= { hrFSTypes 15 } hrFSAFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Andrew File System." ::= { hrFSTypes 16 } hrFSDFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the OSF DCE Distributed File System." ::= { hrFSTypes 17 } hrFSAppleshare OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the AppleShare File System." ::= { hrFSTypes 18 } hrFSRFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the RFS File System." ::= { hrFSTypes 19 } hrFSDGCFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Data General DGCFS." ::= { hrFSTypes 20 } Waldbusser & Grillo Standards Track [Page 43] RFC 2790 Host Resources MIB March 2000 hrFSBFS OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the SVR4 Boot File System." ::= { hrFSTypes 21 } hrFSFAT32 OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Windows FAT32 File System." ::= { hrFSTypes 22 } hrFSLinuxExt2 OBJECT-IDENTITY STATUS current DESCRIPTION "The file system type identifier used for the Linux EXT2 File System." ::= { hrFSTypes 23 } END 6. Internationalization Considerations This MIB has many objects that identify file-system pathnames on the managed host. Many file systems allow pathnames to be encoded in a variety of character sets (other than ASCII), but do not support the encoding of the actual character set used with the pathname. The implementation strategy is that user interfaces (i.e. character-based shells or graphical applications) will have configuration options that control with which character set they will interpret and display all pathnames. This is often a per-user configuration (e.g. an environment variable), so that users using different languages and character sets on a multi-user system may each work effectively with their preferred character set. A human usually controls this configuration. If an application is not configured or is configured incorrectly, it will often have trouble displaying pathnames in the intended character set. This situation made it important for this MIB to handle two issues: 1) Pathname objects must be able to transfer a variety of character sets with potentially multi-byte encodings; and, Waldbusser & Grillo Standards Track [Page 44] RFC 2790 Host Resources MIB March 2000 2) HostMIB agents will generally not be correctly configured for the appropriate character set to be used for all files on the system, particularly on a system with multiple users using different character sets. It was thus impossible to mandate that the agent tag pathnames with the character set in use. These issues were solved with the introduction of the InternationalDisplayString textual convention, which supports multi- byte encodings. Network management stations should use a local algorithm to determine which character set is in use and how it should be displayed. It is expected that network management station applications will rely on human configuration to choose which character set in which to interpret InternationalDisplayString objects, much like an application running locally on that host. 7. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on system operations. There are a number of managed objects in this MIB that may contain sensitive information. The objects in the Running Software Group list information about running software on the system (including the operating system software and version). Some may wish not to disclose to others what software they are running. Further, an inventory of the running software and versions may be helpful to an attacker who hopes to exploit software bugs in certain applications. The same issues exist for the objects in the Installed Software Group. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. Waldbusser & Grillo Standards Track [Page 45] RFC 2790 Host Resources MIB March 2000 It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. Waldbusser & Grillo Standards Track [Page 46] RFC 2790 Host Resources MIB March 2000 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet- standard Network Management Framework", RFC 2570, April 1999. [RFC1907] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2233, November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Waldbusser & Grillo Standards Track [Page 47] RFC 2790 Host Resources MIB March 2000 9. Acknowledgments This document was produced by the Host Resources MIB working group. Bobby Krupczak's efforts were particularly helpful in the creation of the draft standard version of this document. In addition, the authors gratefully acknowledge the comments of the following individuals: Amatzia Ben-Artzi NetManage Ron Bergman Hitachi, Inc. Steve Bostock Novell Stephen Bush GE Information Systems Jeff Case SNMP Research Chuck Davin Bellcore Ray Edgarton Bell Atlantic Mike Erlinger Aerospace Corporation Tim Farley Magee Enterprises Mark Kepke Hewlett Packard Bobby Krupczak Empire Technologies, Inc. Cheryl Krupczak Empire Technologies, Inc. Harry Lewis IBM Corp. Keith McCloghrie Cisco Systems Greg Minshall Novell Steve Moulton SNMP Research Dave Perkins Synoptics Ed Reeder Objective Systems Integrators Mike Ritter Apple Computer Marshall Rose Dover Beach Consulting Jon Saperia DEC Rodney Thayer Sable Technology Kaj Tesink Bellcore Dean Throop Data General Bert Wijnen Lucent Lloyd Young Lexmark International Waldbusser & Grillo Standards Track [Page 48] RFC 2790 Host Resources MIB March 2000 10. Authors' Addresses Pete Grillo WeSync.com 1001 SW Fifth Ave, Fifth Floor Portland, OR 97204 Phone: 503-425-5051 Fax: 503-827-6718 email: pete@wesync.com Phone: +1 503 827 6717 Steven Waldbusser Lucent Technologies, Inc. 1213 Innsbruck Dr. Sunnyvale CA 94089 Phone: +1 650 318 1251 Fax: +1 650 318 1633 EMail: waldbusser@ins.com 11. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Waldbusser & Grillo Standards Track [Page 49] RFC 2790 Host Resources MIB March 2000 12. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Waldbusser & Grillo Standards Track [Page 50] snmp-mibs-downloader-1.1/mibrfcs/rfc2819.txt0000644000000000000000000060402411402176071015573 0ustar Network Working Group S. Waldbusser Request for Comments: 2819 Lucent Technologies STD: 59 May 2000 Obsoletes: 1757 Category: Standards Track Remote Network Monitoring Management Information Base 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. This memo obsoletes RFC 1757. This memo extends that specification by documenting the RMON MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. Waldbusser Standards Track [Page 1] RFC 2819 Remote Network Monitoring MIB May 2000 Table of Contents 1 The SNMP Management Framework .............................. 2 2 Overview ................................................... 3 2.1 Remote Network Management Goals .......................... 4 2.2 Textual Conventions ...................................... 5 2.3 Structure of MIB ......................................... 5 2.3.1 The Ethernet Statistics Group .......................... 6 2.3.2 The History Control Group .............................. 6 2.3.3 The Ethernet History Group ............................. 6 2.3.4 The Alarm Group ........................................ 7 2.3.5 The Host Group ......................................... 7 2.3.6 The HostTopN Group ..................................... 7 2.3.7 The Matrix Group ....................................... 7 2.3.8 The Filter Group ....................................... 7 2.3.9 The Packet Capture Group ............................... 8 2.3.10 The Event Group ....................................... 8 3 Control of Remote Network Monitoring Devices ............... 8 3.1 Resource Sharing Among Multiple Management Stations ... 9 3.2 Row Addition Among Multiple Management Stations .......... 10 4 Conventions ................................................ 11 5 Definitions ................................................ 12 6 Security Considerations .................................... 94 7 Acknowledgments ............................................ 95 8 Author's Address ........................................... 95 9 References ................................................. 95 10 Intellectual Property ..................................... 97 11 Full Copyright Statement .................................. 98 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC Waldbusser Standards Track [Page 2] RFC 2819 Remote Network Monitoring MIB May 2000 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [22]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network. Often these remote probes are stand-alone devices and devote significant internal resources for the sole purpose of managing a network. An organization may employ many of these devices, one per network segment, to manage its internet. In addition, these devices may be used for a network management service provider to access a client network, often geographically remote. The objects defined in this document are intended as an interface between an RMON agent and an RMON management application and are not intended for direct manipulation by humans. While some users may tolerate the direct display of some of these objects, few will Waldbusser Standards Track [Page 3] RFC 2819 Remote Network Monitoring MIB May 2000 tolerate the complexity of manually manipulating objects to accomplish row creation. These functions should be handled by the management application. While most of the objects in this document are suitable for the management of any type of network, there are some which are specific to managing Ethernet networks. These are the objects in the etherStatsTable, the etherHistoryTable, and some attributes of the filterPktStatus and capturBufferPacketStatus objects. The design of this MIB allows similar objects to be defined for other network types. It is intended that future versions of this document and additional documents will define extensions for other network types. There are a number of companion documents to the RMON MIB. The Token Ring RMON MIB [19] provides objects specific to managing Token Ring networks. The RMON-2 MIB [20] extends RMON by providing RMON analysis up to the application layer. The SMON MIB [21] extends RMON by providing RMON analysis for switched networks. 2.1. Remote Network Management Goals o Offline Operation There are sometimes conditions when a management station will not be in constant contact with its remote monitoring devices. This is sometimes by design in an attempt to lower communications costs (especially when communicating over a WAN or dialup link), or by accident as network failures affect the communications between the management station and the probe. For this reason, this MIB allows a probe to be configured to perform diagnostics and to collect statistics continuously, even when communication with the management station may not be possible or efficient. The probe may then attempt to notify the management station when an exceptional condition occurs. Thus, even in circumstances where communication between management station and probe is not continuous, fault, performance, and configuration information may be continuously accumulated and communicated to the management station conveniently and efficiently. o Proactive Monitoring Given the resources available on the monitor, it is potentially helpful for it continuously to run diagnostics and to log network performance. The monitor is always available at the onset of any failure. It can notify the management station of the failure and can store historical statistical information Waldbusser Standards Track [Page 4] RFC 2819 Remote Network Monitoring MIB May 2000 about the failure. This historical information can be played back by the management station in an attempt to perform further diagnosis into the cause of the problem. o Problem Detection and Reporting The monitor can be configured to recognize conditions, most notably error conditions, and continuously to check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways. o Value Added Data Because a remote monitoring device represents a network resource dedicated exclusively to network management functions, and because it is located directly on the monitored portion of the network, the remote network monitoring device has the opportunity to add significant value to the data it collects. For instance, by highlighting those hosts on the network that generate the most traffic or errors, the probe can give the management station precisely the information it needs to solve a class of problems. o Multiple Managers An organization may have multiple management stations for different units of the organization, for different functions (e.g. engineering and operations), and in an attempt to provide disaster recovery. Because environments with multiple management stations are common, the remote network monitoring device has to deal with more than own management station, potentially using its resources concurrently. 2.2. Textual Conventions Two new data types are introduced as a textual convention in this MIB document, OwnerString and EntryStatus. 2.3. Structure of MIB The objects are arranged into the following groups: - ethernet statistics - history control - ethernet history - alarm - host Waldbusser Standards Track [Page 5] RFC 2819 Remote Network Monitoring MIB May 2000 - hostTopN - matrix - filter - packet capture - event These groups are the basic unit of conformance. If a remote monitoring device implements a group, then it must implement all objects in that group. For example, a managed agent that implements the host group must implement the hostControlTable, the hostTable and the hostTimeTable. While this section provides an overview of grouping and conformance information for this MIB, the authoritative reference for such information is contained in the MODULE-COMPLIANCE and OBJECT-GROUP macros later in this MIB. All groups in this MIB are optional. Implementations of this MIB must also implement the system group of MIB-II [16] and the IF-MIB [17]. MIB-II may also mandate the implementation of additional groups. These groups are defined to provide a means of assigning object identifiers, and to provide a method for implementors of managed agents to know which objects they must implement. 2.3.1. The Ethernet Statistics Group The ethernet statistics group contains statistics measured by the probe for each monitored Ethernet interface on this device. This group consists of the etherStatsTable. 2.3.2. The History Control Group The history control group controls the periodic statistical sampling of data from various types of networks. This group consists of the historyControlTable. 2.3.3. The Ethernet History Group The ethernet history group records periodic statistical samples from an ethernet network and stores them for later retrieval. This group consists of the etherHistoryTable. Waldbusser Standards Track [Page 6] RFC 2819 Remote Network Monitoring MIB May 2000 2.3.4. The Alarm Group The alarm group periodically takes statistical samples from variables in the probe and compares them to previously configured thresholds. If the monitored variable crosses a threshold, an event is generated. A hysteresis mechanism is implemented to limit the generation of alarms. This group consists of the alarmTable and requires the implementation of the event group. 2.3.5. The Host Group The host group contains statistics associated with each host discovered on the network. This group discovers hosts on the network by keeping a list of source and destination MAC Addresses seen in good packets promiscuously received from the network. This group consists of the hostControlTable, the hostTable, and the hostTimeTable. 2.3.6. The HostTopN Group The hostTopN group is used to prepare reports that describe the hosts that top a list ordered by one of their statistics. The available statistics are samples of one of their base statistics over an interval specified by the management station. Thus, these statistics are rate based. The management station also selects how many such hosts are reported. This group consists of the hostTopNControlTable and the hostTopNTable, and requires the implementation of the host group. 2.3.7. The Matrix Group The matrix group stores statistics for conversations between sets of two addresses. As the device detects a new conversation, it creates a new entry in its tables. This group consists of the matrixControlTable, the matrixSDTable and the matrixDSTable. 2.3.8. The Filter Group The filter group allows packets to be matched by a filter equation. These matched packets form a data stream that may be captured or may generate events. This group consists of the filterTable and the channelTable. Waldbusser Standards Track [Page 7] RFC 2819 Remote Network Monitoring MIB May 2000 2.3.9. The Packet Capture Group The Packet Capture group allows packets to be captured after they flow through a channel. This group consists of the bufferControlTable and the captureBufferTable, and requires the implementation of the filter group. 2.3.10. The Event Group The event group controls the generation and notification of events from this device. This group consists of the eventTable and the logTable. 3. Control of Remote Network Monitoring Devices Due to the complex nature of the available functions in these devices, the functions often need user configuration. In many cases, the function requires parameters to be set up for a data collection operation. The operation can proceed only after these parameters are fully set up. Many functional groups in this MIB have one or more tables in which to set up control parameters, and one or more data tables in which to place the results of the operation. The control tables are typically read-write in nature, while the data tables are typically read-only. Because the parameters in the control table often describe resulting data in the data table, many of the parameters can be modified only when the control entry is invalid. Thus, the method for modifying these parameters is to invalidate the control entry, causing its deletion and the deletion of any associated data entries, and then create a new control entry with the proper parameters. Deleting the control entry also gives a convenient method for reclaiming the resources used by the associated data. Some objects in this MIB provide a mechanism to execute an action on the remote monitoring device. These objects may execute an action as a result of a change in the state of the object. For those objects in this MIB, a request to set an object to the same value as it currently holds would thus cause no action to occur. To facilitate control by multiple managers, resources have to be shared among the managers. These resources are typically the memory and computation resources that a function requires. Waldbusser Standards Track [Page 8] RFC 2819 Remote Network Monitoring MIB May 2000 3.1. Resource Sharing Among Multiple Management Stations When multiple management stations wish to use functions that compete for a finite amount of resources on a device, a method to facilitate this sharing of resources is required. Potential conflicts include: o Two management stations wish to simultaneously use resources that together would exceed the capability of the device. o A management station uses a significant amount of resources for a long period of time. o A management station uses resources and then crashes, forgetting to free the resources so others may use them. A mechanism is provided for each management station initiated function in this MIB to avoid these conflicts and to help resolve them when they occur. Each function has a label identifying the initiator (owner) of the function. This label is set by the initiator to provide for the following possibilities: o A management station may recognize resources it owns and no longer needs. o A network operator can find the management station that owns the resource and negotiate for it to be freed. o A network operator may decide to unilaterally free resources another network operator has reserved. o Upon initialization, a management station may recognize resources it had reserved in the past. With this information it may free the resources if it no longer needs them. Management stations and probes should support any format of the owner string dictated by the local policy of the organization. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. This information will help users to share the resources more effectively. There is often default functionality that the device or the administrator of the probe (often the network administrator) wishes to set up. The resources associated with this functionality are then owned by the device itself or by the network administrator, and are intended to be long-lived. In this case, the device or the administrator will set the relevant owner object to a string starting with 'monitor'. Indiscriminate modification of the monitor-owned configuration by network management stations is discouraged. In fact, a network management station should only modify these objects under the direction of the administrator of the probe. Waldbusser Standards Track [Page 9] RFC 2819 Remote Network Monitoring MIB May 2000 Resources on a probe are scarce and are typically allocated when control rows are created by an application. Since many applications may be using a probe simultaneously, indiscriminate allocation of resources to particular applications is very likely to cause resource shortages in the probe. When a network management station wishes to utilize a function in a monitor, it is encouraged to first scan the control table of that function to find an instance with similar parameters to share. This is especially true for those instances owned by the monitor, which can be assumed to change infrequently. If a management station decides to share an instance owned by another management station, it should understand that the management station that owns the instance may indiscriminately modify or delete it. It should be noted that a management application should have the most trust in a monitor-owned row because it should be changed very infrequently. A row owned by the management application is less long-lived because a network administrator is more likely to re- assign resources from a row that is in use by one user than from a monitor-owned row that is potentially in use by many users. A row owned by another application would be even less long-lived because the other application may delete or modify that row completely at its discretion. 3.2. Row Addition Among Multiple Management Stations The addition of new rows is achieved using the method described in RFC 1905 [13]. In this MIB, rows are often added to a table in order to configure a function. This configuration usually involves parameters that control the operation of the function. The agent must check these parameters to make sure they are appropriate given restrictions defined in this MIB as well as any implementation specific restrictions such as lack of resources. The agent implementor may be confused as to when to check these parameters and when to signal to the management station that the parameters are invalid. There are two opportunities: o When the management station sets each parameter object. o When the management station sets the entry status object to valid. If the latter is chosen, it would be unclear to the management station which of the several parameters was invalid and caused the badValue error to be emitted. Thus, wherever possible, the implementor should choose the former as it will provide more information to the management station. Waldbusser Standards Track [Page 10] RFC 2819 Remote Network Monitoring MIB May 2000 A problem can arise when multiple management stations attempt to set configuration information simultaneously using SNMP. When this involves the addition of a new conceptual row in the same control table, the managers may collide, attempting to create the same entry. To guard against these collisions, each such control entry contains a status object with special semantics that help to arbitrate among the managers. If an attempt is made with the row addition mechanism to create such a status object and that object already exists, an error is returned. When more than one manager simultaneously attempts to create the same conceptual row, only the first can succeed. The others will receive an error. When a manager wishes to create a new control entry, it needs to choose an index for that row. It may choose this index in a variety of ways, hopefully minimizing the chances that the index is in use by another manager. If the index is in use, the mechanism mentioned previously will guard against collisions. Examples of schemes to choose index values include random selection or scanning the control table looking for the first unused index. Because index values may be any valid value in the range and they are chosen by the manager, the agent must allow a row to be created with any unused index value if it has the resources to create a new row. Some tables in this MIB reference other tables within this MIB. When creating or deleting entries in these tables, it is generally allowable for dangling references to exist. There is no defined order for creating or deleting entries in these tables. 4. Conventions The following conventions are used throughout the RMON MIB and its companion documents. Good Packets Good packets are error-free packets that have a valid frame length. For example, on Ethernet, good packets are error-free packets that are between 64 octets long and 1518 octets long. They follow the form defined in IEEE 802.3 section 3.2.all. Bad Packets Bad packets are packets that have proper framing and are therefore recognized as packets, but contain errors within the packet or have an invalid length. For example, on Ethernet, bad packets have a valid preamble and SFD, but have a bad CRC, or are either shorter than 64 octets or longer than 1518 octets. Waldbusser Standards Track [Page 11] RFC 2819 Remote Network Monitoring MIB May 2000 5. Definitions RMON-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, NOTIFICATION-TYPE, mib-2, Counter32, Integer32, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; -- Remote Network Monitoring MIB rmonMibModule MODULE-IDENTITY LAST-UPDATED "200005110000Z" -- 11 May, 2000 ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "Steve Waldbusser Phone: +1-650-948-6500 Fax: +1-650-745-0671 Email: waldbusser@nextbeacon.com" DESCRIPTION "Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network. This MIB defines objects for managing remote network monitoring devices." REVISION "200005110000Z" -- 11 May, 2000 DESCRIPTION "Reformatted into SMIv2 format. This version published as RFC 2819." REVISION "199502010000Z" -- 1 Feb, 1995 DESCRIPTION "Bug fixes, clarifications and minor changes based on implementation experience, published as RFC1757 [18]. Two changes were made to object definitions: 1) A new status bit has been defined for the captureBufferPacketStatus object, indicating that the packet order within the capture buffer may not be identical to the packet order as received off the wire. This bit may only Waldbusser Standards Track [Page 12] RFC 2819 Remote Network Monitoring MIB May 2000 be used for packets transmitted by the probe. Older NMS applications can safely ignore this status bit, which might be used by newer agents. 2) The packetMatch trap has been removed. This trap was never actually 'approved' and was not added to this document along with the risingAlarm and fallingAlarm traps. The packetMatch trap could not be throttled, which could cause disruption of normal network traffic under some circumstances. An NMS should configure a risingAlarm threshold on the appropriate channelMatches instance if a trap is desired for a packetMatch event. Note that logging of packetMatch events is still supported--only trap generation for such events has been removed. In addition, several clarifications to individual object definitions have been added to assist agent and NMS implementors: - global definition of 'good packets' and 'bad packets' - more detailed text governing conceptual row creation and modification - instructions for probes relating to interface changes and disruptions - clarification of some ethernet counter definitions - recommended formula for calculating network utilization - clarification of channel and captureBuffer behavior for some unusual conditions - examples of proper instance naming for each table" REVISION "199111010000Z" -- 1 Nov, 1991 DESCRIPTION "The original version of this MIB, published as RFC1271." ::= { rmonConformance 8 } rmon OBJECT IDENTIFIER ::= { mib-2 16 } -- textual conventions OwnerString ::= TEXTUAL-CONVENTION STATUS current Waldbusser Standards Track [Page 13] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "This data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'. SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties." SYNTAX OCTET STRING (SIZE (0..127)) EntryStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The status of a table entry. Setting this object to the value invalid(4) has the effect of invalidating the corresponding entry. That is, it effectively disassociates the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries currently not in use. Proper interpretation of such entries requires examination of the relevant EntryStatus object. An existing instance of this object cannot be set to createRequest(2). This object may only be set to createRequest(2) when this instance is created. When this object is created, the agent may wish to create supplemental object instances with default values to complete a conceptual row in this table. Because the Waldbusser Standards Track [Page 14] RFC 2819 Remote Network Monitoring MIB May 2000 creation of these default objects is entirely at the option of the agent, the manager must not assume that any will be created, but may make use of any that are created. Immediately after completing the create operation, the agent must set this object to underCreation(3). When in the underCreation(3) state, an entry is allowed to exist in a possibly incomplete, possibly inconsistent state, usually to allow it to be modified in multiple PDUs. When in this state, an entry is not fully active. Entries shall exist in the underCreation(3) state until the management station is finished configuring the entry and sets this object to valid(1) or aborts, setting this object to invalid(4). If the agent determines that an entry has been in the underCreation(3) state for an abnormally long time, it may decide that the management station has crashed. If the agent makes this decision, it may set this object to invalid(4) to reclaim the entry. A prudent agent will understand that the management station may need to wait for human input and will allow for that possibility in its determination of this abnormally long period. An entry in the valid(1) state is fully configured and consistent and fully represents the configuration or operation such a row is intended to represent. For example, it could be a statistical function that is configured and active, or a filter that is available in the list of filters processed by the packet capture process. A manager is restricted to changing the state of an entry in the following ways: To: valid createRequest underCreation invalid From: valid OK NO OK OK createRequest N/A N/A N/A N/A underCreation OK NO OK OK invalid NO NO NO OK nonExistent NO OK NO OK In the table above, it is not applicable to move the state from the createRequest state to any other state because the manager will never find the variable in that state. The nonExistent state is not a value of the enumeration, rather it means that the entryStatus variable does not exist at all. Waldbusser Standards Track [Page 15] RFC 2819 Remote Network Monitoring MIB May 2000 An agent may allow an entryStatus variable to change state in additional ways, so long as the semantics of the states are followed. This allowance is made to ease the implementation of the agent and is made despite the fact that managers should never exercise these additional state transitions." SYNTAX INTEGER { valid(1), createRequest(2), underCreation(3), invalid(4) } statistics OBJECT IDENTIFIER ::= { rmon 1 } history OBJECT IDENTIFIER ::= { rmon 2 } alarm OBJECT IDENTIFIER ::= { rmon 3 } hosts OBJECT IDENTIFIER ::= { rmon 4 } hostTopN OBJECT IDENTIFIER ::= { rmon 5 } matrix OBJECT IDENTIFIER ::= { rmon 6 } filter OBJECT IDENTIFIER ::= { rmon 7 } capture OBJECT IDENTIFIER ::= { rmon 8 } event OBJECT IDENTIFIER ::= { rmon 9 } rmonConformance OBJECT IDENTIFIER ::= { rmon 20 } -- The Ethernet Statistics Group -- -- Implementation of the Ethernet Statistics group is optional. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The ethernet statistics group contains statistics measured by the -- probe for each monitored interface on this device. These -- statistics take the form of free running counters that start from -- zero when a valid entry is created. -- -- This group currently has statistics defined only for -- Ethernet interfaces. Each etherStatsEntry contains statistics -- for one Ethernet interface. The probe must create one -- etherStats entry for each monitored Ethernet interface -- on the device. etherStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF EtherStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Ethernet statistics entries." ::= { statistics 1 } Waldbusser Standards Track [Page 16] RFC 2819 Remote Network Monitoring MIB May 2000 etherStatsEntry OBJECT-TYPE SYNTAX EtherStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics kept for a particular Ethernet interface. As an example, an instance of the etherStatsPkts object might be named etherStatsPkts.1" INDEX { etherStatsIndex } ::= { etherStatsTable 1 } EtherStatsEntry ::= SEQUENCE { etherStatsIndex Integer32, etherStatsDataSource OBJECT IDENTIFIER, etherStatsDropEvents Counter32, etherStatsOctets Counter32, etherStatsPkts Counter32, etherStatsBroadcastPkts Counter32, etherStatsMulticastPkts Counter32, etherStatsCRCAlignErrors Counter32, etherStatsUndersizePkts Counter32, etherStatsOversizePkts Counter32, etherStatsFragments Counter32, etherStatsJabbers Counter32, etherStatsCollisions Counter32, etherStatsPkts64Octets Counter32, etherStatsPkts65to127Octets Counter32, etherStatsPkts128to255Octets Counter32, etherStatsPkts256to511Octets Counter32, etherStatsPkts512to1023Octets Counter32, etherStatsPkts1024to1518Octets Counter32, etherStatsOwner OwnerString, etherStatsStatus EntryStatus } etherStatsIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object uniquely identifies this etherStats entry." ::= { etherStatsEntry 1 } etherStatsDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current Waldbusser Standards Track [Page 17] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "This object identifies the source of the data that this etherStats entry is configured to analyze. This source can be any ethernet interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in RFC 2233 [17], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. The statistics in this group reflect all packets on the local network segment attached to the identified interface. An agent may or may not be able to tell if fundamental changes to the media of the interface have occurred and necessitate an invalidation of this entry. For example, a hot-pluggable ethernet card could be pulled out and replaced by a token-ring card. In such a case, if the agent has such knowledge of the change, it is recommended that it invalidate this entry. This object may not be modified if the associated etherStatsStatus object is equal to valid(1)." ::= { etherStatsEntry 2 } etherStatsDropEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of events in which packets were dropped by the probe due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is just the number of times this condition has been detected." ::= { etherStatsEntry 3 } etherStatsOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received on the network (excluding framing bits but including FCS octets). Waldbusser Standards Track [Page 18] RFC 2819 Remote Network Monitoring MIB May 2000 This object can be used as a reasonable estimate of 10-Megabit ethernet utilization. If greater precision is desired, the etherStatsPkts and etherStatsOctets objects should be sampled before and after a common interval. The differences in the sampled values are Pkts and Octets, respectively, and the number of seconds in the interval is Interval. These values are used to calculate the Utilization as follows: Pkts * (9.6 + 6.4) + (Octets * .8) Utilization = ------------------------------------- Interval * 10,000 The result of this equation is the value Utilization which is the percent utilization of the ethernet segment on a scale of 0 to 100 percent." ::= { etherStatsEntry 4 } etherStatsPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets, broadcast packets, and multicast packets) received." ::= { etherStatsEntry 5 } etherStatsBroadcastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of good packets received that were directed to the broadcast address. Note that this does not include multicast packets." ::= { etherStatsEntry 6 } etherStatsMulticastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of good packets received that were directed to a multicast address. Note that this number does not include packets directed to the broadcast Waldbusser Standards Track [Page 19] RFC 2819 Remote Network Monitoring MIB May 2000 address." ::= { etherStatsEntry 7 } etherStatsCRCAlignErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received that had a length (excluding framing bits, but including FCS octets) of between 64 and 1518 octets, inclusive, but had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error)." ::= { etherStatsEntry 8 } etherStatsUndersizePkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received that were less than 64 octets long (excluding framing bits, but including FCS octets) and were otherwise well formed." ::= { etherStatsEntry 9 } etherStatsOversizePkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets) and were otherwise well formed." ::= { etherStatsEntry 10 } etherStatsFragments OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 20] RFC 2819 Remote Network Monitoring MIB May 2000 "The total number of packets received that were less than 64 octets in length (excluding framing bits but including FCS octets) and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Note that it is entirely normal for etherStatsFragments to increment. This is because it counts both runts (which are normal occurrences due to collisions) and noise hits." ::= { etherStatsEntry 11 } etherStatsJabbers OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets), and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Note that this definition of jabber is different than the definition in IEEE-802.3 section 8.2.1.5 (10BASE5) and section 10.3.1.4 (10BASE2). These documents define jabber as the condition where any packet exceeds 20 ms. The allowed range to detect jabber is between 20 ms and 150 ms." ::= { etherStatsEntry 12 } etherStatsCollisions OBJECT-TYPE SYNTAX Counter32 UNITS "Collisions" MAX-ACCESS read-only STATUS current DESCRIPTION "The best estimate of the total number of collisions on this Ethernet segment. The value returned will depend on the location of the RMON probe. Section 8.2.1.3 (10BASE-5) and section 10.3.1.3 (10BASE-2) of IEEE standard 802.3 states that a station must detect a collision, in the receive mode, if three or more stations are transmitting simultaneously. A repeater port must detect a collision when two or more Waldbusser Standards Track [Page 21] RFC 2819 Remote Network Monitoring MIB May 2000 stations are transmitting simultaneously. Thus a probe placed on a repeater port could record more collisions than a probe connected to a station on the same segment would. Probe location plays a much smaller role when considering 10BASE-T. 14.2.1.4 (10BASE-T) of IEEE standard 802.3 defines a collision as the simultaneous presence of signals on the DO and RD circuits (transmitting and receiving at the same time). A 10BASE-T station can only detect collisions when it is transmitting. Thus probes placed on a station and a repeater, should report the same number of collisions. Note also that an RMON probe inside a repeater should ideally report collisions between the repeater and one or more other hosts (transmit collisions as defined by IEEE 802.3k) plus receiver collisions observed on any coax segments to which the repeater is connected." ::= { etherStatsEntry 13 } etherStatsPkts64Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were 64 octets in length (excluding framing bits but including FCS octets)." ::= { etherStatsEntry 14 } etherStatsPkts65to127Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 65 and 127 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsEntry 15 } etherStatsPkts128to255Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only Waldbusser Standards Track [Page 22] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 128 and 255 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsEntry 16 } etherStatsPkts256to511Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 256 and 511 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsEntry 17 } etherStatsPkts512to1023Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 512 and 1023 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsEntry 18 } etherStatsPkts1024to1518Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 1024 and 1518 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsEntry 19 } etherStatsOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current Waldbusser Standards Track [Page 23] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { etherStatsEntry 20 } etherStatsStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this etherStats entry." ::= { etherStatsEntry 21 } -- The History Control Group -- Implementation of the History Control group is optional. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The history control group controls the periodic statistical -- sampling of data from various types of networks. The -- historyControlTable stores configuration entries that each -- define an interface, polling period, and other parameters. -- Once samples are taken, their data is stored in an entry -- in a media-specific table. Each such entry defines one -- sample, and is associated with the historyControlEntry that -- caused the sample to be taken. Each counter in the -- etherHistoryEntry counts the same event as its similarly-named -- counterpart in the etherStatsEntry, except that each value here -- is a cumulative sum during a sampling period. -- -- If the probe keeps track of the time of day, it should start -- the first sample of the history at a time such that -- when the next hour of the day begins, a sample is -- started at that instant. This tends to make more -- user-friendly reports, and enables comparison of reports -- from different probes that have relatively accurate time -- of day. -- -- The probe is encouraged to add two history control entries -- per monitored interface upon initialization that describe a short -- term and a long term polling period. Suggested parameters are 30 -- seconds for the short term polling period and 30 minutes for -- the long term period. historyControlTable OBJECT-TYPE SYNTAX SEQUENCE OF HistoryControlEntry MAX-ACCESS not-accessible Waldbusser Standards Track [Page 24] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "A list of history control entries." ::= { history 1 } historyControlEntry OBJECT-TYPE SYNTAX HistoryControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of parameters that set up a periodic sampling of statistics. As an example, an instance of the historyControlInterval object might be named historyControlInterval.2" INDEX { historyControlIndex } ::= { historyControlTable 1 } HistoryControlEntry ::= SEQUENCE { historyControlIndex Integer32, historyControlDataSource OBJECT IDENTIFIER, historyControlBucketsRequested Integer32, historyControlBucketsGranted Integer32, historyControlInterval Integer32, historyControlOwner OwnerString, historyControlStatus EntryStatus } historyControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the historyControl table. Each such entry defines a set of samples at a particular interval for an interface on the device." ::= { historyControlEntry 1 } historyControlDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the source of the data for which historical data was collected and placed in a media-specific table on behalf of this historyControlEntry. This source can be any interface on this device. In order to identify Waldbusser Standards Track [Page 25] RFC 2819 Remote Network Monitoring MIB May 2000 a particular interface, this object shall identify the instance of the ifIndex object, defined in RFC 2233 [17], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. The statistics in this group reflect all packets on the local network segment attached to the identified interface. An agent may or may not be able to tell if fundamental changes to the media of the interface have occurred and necessitate an invalidation of this entry. For example, a hot-pluggable ethernet card could be pulled out and replaced by a token-ring card. In such a case, if the agent has such knowledge of the change, it is recommended that it invalidate this entry. This object may not be modified if the associated historyControlStatus object is equal to valid(1)." ::= { historyControlEntry 2 } historyControlBucketsRequested OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The requested number of discrete time intervals over which data is to be saved in the part of the media-specific table associated with this historyControlEntry. When this object is created or modified, the probe should set historyControlBucketsGranted as closely to this object as is possible for the particular probe implementation and available resources." DEFVAL { 50 } ::= { historyControlEntry 3 } historyControlBucketsGranted OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of discrete sampling intervals over which data shall be saved in the part of the media-specific table associated with this historyControlEntry. Waldbusser Standards Track [Page 26] RFC 2819 Remote Network Monitoring MIB May 2000 When the associated historyControlBucketsRequested object is created or modified, the probe should set this object as closely to the requested value as is possible for the particular probe implementation and available resources. The probe must not lower this value except as a result of a modification to the associated historyControlBucketsRequested object. There will be times when the actual number of buckets associated with this entry is less than the value of this object. In this case, at the end of each sampling interval, a new bucket will be added to the media-specific table. When the number of buckets reaches the value of this object and a new bucket is to be added to the media-specific table, the oldest bucket associated with this historyControlEntry shall be deleted by the agent so that the new bucket can be added. When the value of this object changes to a value less than the current value, entries are deleted from the media-specific table associated with this historyControlEntry. Enough of the oldest of these entries shall be deleted by the agent so that their number remains less than or equal to the new value of this object. When the value of this object changes to a value greater than the current value, the number of associated media- specific entries may be allowed to grow." ::= { historyControlEntry 4 } historyControlInterval OBJECT-TYPE SYNTAX Integer32 (1..3600) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval in seconds over which the data is sampled for each bucket in the part of the media-specific table associated with this historyControlEntry. This interval can be set to any number of seconds between 1 and 3600 (1 hour). Because the counters in a bucket may overflow at their Waldbusser Standards Track [Page 27] RFC 2819 Remote Network Monitoring MIB May 2000 maximum value with no indication, a prudent manager will take into account the possibility of overflow in any of the associated counters. It is important to consider the minimum time in which any counter could overflow on a particular media type and set the historyControlInterval object to a value less than this interval. This is typically most important for the 'octets' counter in any media-specific table. For example, on an Ethernet network, the etherHistoryOctets counter could overflow in about one hour at the Ethernet's maximum utilization. This object may not be modified if the associated historyControlStatus object is equal to valid(1)." DEFVAL { 1800 } ::= { historyControlEntry 5 } historyControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { historyControlEntry 6 } historyControlStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this historyControl entry. Each instance of the media-specific table associated with this historyControlEntry will be deleted by the agent if this historyControlEntry is not equal to valid(1)." ::= { historyControlEntry 7 } -- The Ethernet History Group -- Implementation of the Ethernet History group is optional. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The Ethernet History group records periodic statistical samples -- from a network and stores them for later retrieval. -- Once samples are taken, their data is stored in an entry -- in a media-specific table. Each such entry defines one Waldbusser Standards Track [Page 28] RFC 2819 Remote Network Monitoring MIB May 2000 -- sample, and is associated with the historyControlEntry that -- caused the sample to be taken. This group defines the -- etherHistoryTable, for Ethernet networks. -- etherHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF EtherHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Ethernet history entries." ::= { history 2 } etherHistoryEntry OBJECT-TYPE SYNTAX EtherHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An historical sample of Ethernet statistics on a particular Ethernet interface. This sample is associated with the historyControlEntry which set up the parameters for a regular collection of these samples. As an example, an instance of the etherHistoryPkts object might be named etherHistoryPkts.2.89" INDEX { etherHistoryIndex , etherHistorySampleIndex } ::= { etherHistoryTable 1 } EtherHistoryEntry ::= SEQUENCE { etherHistoryIndex Integer32, etherHistorySampleIndex Integer32, etherHistoryIntervalStart TimeTicks, etherHistoryDropEvents Counter32, etherHistoryOctets Counter32, etherHistoryPkts Counter32, etherHistoryBroadcastPkts Counter32, etherHistoryMulticastPkts Counter32, etherHistoryCRCAlignErrors Counter32, etherHistoryUndersizePkts Counter32, etherHistoryOversizePkts Counter32, etherHistoryFragments Counter32, etherHistoryJabbers Counter32, etherHistoryCollisions Counter32, etherHistoryUtilization Integer32 } etherHistoryIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only Waldbusser Standards Track [Page 29] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "The history of which this entry is a part. The history identified by a particular value of this index is the same history as identified by the same value of historyControlIndex." ::= { etherHistoryEntry 1 } etherHistorySampleIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies the particular sample this entry represents among all samples associated with the same historyControlEntry. This index starts at 1 and increases by one as each new sample is taken." ::= { etherHistoryEntry 2 } etherHistoryIntervalStart OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the start of the interval over which this sample was measured. If the probe keeps track of the time of day, it should start the first sample of the history at a time such that when the next hour of the day begins, a sample is started at that instant. Note that following this rule may require the probe to delay collecting the first sample of the history, as each sample must be of the same interval. Also note that the sample which is currently being collected is not accessible in this table until the end of its interval." ::= { etherHistoryEntry 3 } etherHistoryDropEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of events in which packets were dropped by the probe due to lack of resources during this sampling interval. Note that this number is not necessarily the number of packets dropped, it is just the number of times this condition has been Waldbusser Standards Track [Page 30] RFC 2819 Remote Network Monitoring MIB May 2000 detected." ::= { etherHistoryEntry 4 } etherHistoryOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received on the network (excluding framing bits but including FCS octets)." ::= { etherHistoryEntry 5 } etherHistoryPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets (including bad packets) received during this sampling interval." ::= { etherHistoryEntry 6 } etherHistoryBroadcastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets received during this sampling interval that were directed to the broadcast address." ::= { etherHistoryEntry 7 } etherHistoryMulticastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets received during this sampling interval that were directed to a multicast address. Note that this number does not include packets addressed to the broadcast address." ::= { etherHistoryEntry 8 } Waldbusser Standards Track [Page 31] RFC 2819 Remote Network Monitoring MIB May 2000 etherHistoryCRCAlignErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received during this sampling interval that had a length (excluding framing bits but including FCS octets) between 64 and 1518 octets, inclusive, but had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error)." ::= { etherHistoryEntry 9 } etherHistoryUndersizePkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received during this sampling interval that were less than 64 octets long (excluding framing bits but including FCS octets) and were otherwise well formed." ::= { etherHistoryEntry 10 } etherHistoryOversizePkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received during this sampling interval that were longer than 1518 octets (excluding framing bits but including FCS octets) but were otherwise well formed." ::= { etherHistoryEntry 11 } etherHistoryFragments OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received during this sampling interval that were less than 64 octets in length (excluding framing bits but including FCS Waldbusser Standards Track [Page 32] RFC 2819 Remote Network Monitoring MIB May 2000 octets) had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Note that it is entirely normal for etherHistoryFragments to increment. This is because it counts both runts (which are normal occurrences due to collisions) and noise hits." ::= { etherHistoryEntry 12 } etherHistoryJabbers OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received during this sampling interval that were longer than 1518 octets (excluding framing bits but including FCS octets), and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Note that this definition of jabber is different than the definition in IEEE-802.3 section 8.2.1.5 (10BASE5) and section 10.3.1.4 (10BASE2). These documents define jabber as the condition where any packet exceeds 20 ms. The allowed range to detect jabber is between 20 ms and 150 ms." ::= { etherHistoryEntry 13 } etherHistoryCollisions OBJECT-TYPE SYNTAX Counter32 UNITS "Collisions" MAX-ACCESS read-only STATUS current DESCRIPTION "The best estimate of the total number of collisions on this Ethernet segment during this sampling interval. The value returned will depend on the location of the RMON probe. Section 8.2.1.3 (10BASE-5) and section 10.3.1.3 (10BASE-2) of IEEE standard 802.3 states that a station must detect a collision, in the receive mode, if three or more stations are transmitting simultaneously. A repeater port must detect a collision when two or more Waldbusser Standards Track [Page 33] RFC 2819 Remote Network Monitoring MIB May 2000 stations are transmitting simultaneously. Thus a probe placed on a repeater port could record more collisions than a probe connected to a station on the same segment would. Probe location plays a much smaller role when considering 10BASE-T. 14.2.1.4 (10BASE-T) of IEEE standard 802.3 defines a collision as the simultaneous presence of signals on the DO and RD circuits (transmitting and receiving at the same time). A 10BASE-T station can only detect collisions when it is transmitting. Thus probes placed on a station and a repeater, should report the same number of collisions. Note also that an RMON probe inside a repeater should ideally report collisions between the repeater and one or more other hosts (transmit collisions as defined by IEEE 802.3k) plus receiver collisions observed on any coax segments to which the repeater is connected." ::= { etherHistoryEntry 14 } etherHistoryUtilization OBJECT-TYPE SYNTAX Integer32 (0..10000) MAX-ACCESS read-only STATUS current DESCRIPTION "The best estimate of the mean physical layer network utilization on this interface during this sampling interval, in hundredths of a percent." ::= { etherHistoryEntry 15 } -- The Alarm Group -- Implementation of the Alarm group is optional. The Alarm Group -- requires the implementation of the Event group. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The Alarm group periodically takes statistical samples from -- variables in the probe and compares them to thresholds that have -- been configured. The alarm table stores configuration -- entries that each define a variable, polling period, and -- threshold parameters. If a sample is found to cross the -- threshold values, an event is generated. Only variables that -- resolve to an ASN.1 primitive type of INTEGER (INTEGER, Integer32, -- Counter32, Counter64, Gauge32, or TimeTicks) may be monitored in -- this way. -- Waldbusser Standards Track [Page 34] RFC 2819 Remote Network Monitoring MIB May 2000 -- This function has a hysteresis mechanism to limit the generation -- of events. This mechanism generates one event as a threshold -- is crossed in the appropriate direction. No more events are -- generated for that threshold until the opposite threshold is -- crossed. -- -- In the case of a sampling a deltaValue, a probe may implement -- this mechanism with more precision if it takes a delta sample -- twice per period, each time comparing the sum of the latest two -- samples to the threshold. This allows the detection of threshold -- crossings that span the sampling boundary. Note that this does -- not require any special configuration of the threshold value. -- It is suggested that probes implement this more precise algorithm. alarmTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of alarm entries." ::= { alarm 1 } alarmEntry OBJECT-TYPE SYNTAX AlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of parameters that set up a periodic checking for alarm conditions. For example, an instance of the alarmValue object might be named alarmValue.8" INDEX { alarmIndex } ::= { alarmTable 1 } AlarmEntry ::= SEQUENCE { alarmIndex Integer32, alarmInterval Integer32, alarmVariable OBJECT IDENTIFIER, alarmSampleType INTEGER, alarmValue Integer32, alarmStartupAlarm INTEGER, alarmRisingThreshold Integer32, alarmFallingThreshold Integer32, alarmRisingEventIndex Integer32, alarmFallingEventIndex Integer32, alarmOwner OwnerString, alarmStatus EntryStatus } Waldbusser Standards Track [Page 35] RFC 2819 Remote Network Monitoring MIB May 2000 alarmIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the alarm table. Each such entry defines a diagnostic sample at a particular interval for an object on the device." ::= { alarmEntry 1 } alarmInterval OBJECT-TYPE SYNTAX Integer32 UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval in seconds over which the data is sampled and compared with the rising and falling thresholds. When setting this variable, care should be taken in the case of deltaValue sampling - the interval should be set short enough that the sampled variable is very unlikely to increase or decrease by more than 2^31 - 1 during a single sampling interval. This object may not be modified if the associated alarmStatus object is equal to valid(1)." ::= { alarmEntry 2 } alarmVariable OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the particular variable to be sampled. Only variables that resolve to an ASN.1 primitive type of INTEGER (INTEGER, Integer32, Counter32, Counter64, Gauge, or TimeTicks) may be sampled. Because SNMP access control is articulated entirely in terms of the contents of MIB views, no access control mechanism exists that can restrict the value of this object to identify only those objects that exist in a particular MIB view. Because there is thus no acceptable means of restricting the read access that could be obtained through the alarm mechanism, the probe must only grant write access to this object in Waldbusser Standards Track [Page 36] RFC 2819 Remote Network Monitoring MIB May 2000 those views that have read access to all objects on the probe. During a set operation, if the supplied variable name is not available in the selected MIB view, a badValue error must be returned. If at any time the variable name of an established alarmEntry is no longer available in the selected MIB view, the probe must change the status of this alarmEntry to invalid(4). This object may not be modified if the associated alarmStatus object is equal to valid(1)." ::= { alarmEntry 3 } alarmSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable and calculating the value to be compared against the thresholds. If the value of this object is absoluteValue(1), the value of the selected variable will be compared directly with the thresholds at the end of the sampling interval. If the value of this object is deltaValue(2), the value of the selected variable at the last sample will be subtracted from the current value, and the difference compared with the thresholds. This object may not be modified if the associated alarmStatus object is equal to valid(1)." ::= { alarmEntry 4 } alarmValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the statistic during the last sampling period. For example, if the sample type is deltaValue, this value will be the difference between the samples at the beginning and end of the period. If the sample type is absoluteValue, this value will be the sampled value at the end of the period. Waldbusser Standards Track [Page 37] RFC 2819 Remote Network Monitoring MIB May 2000 This is the value that is compared with the rising and falling thresholds. The value during the current sampling period is not made available until the period is completed and will remain available until the next period completes." ::= { alarmEntry 5 } alarmStartupAlarm OBJECT-TYPE SYNTAX INTEGER { risingAlarm(1), fallingAlarm(2), risingOrFallingAlarm(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The alarm that may be sent when this entry is first set to valid. If the first sample after this entry becomes valid is greater than or equal to the risingThreshold and alarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3), then a single rising alarm will be generated. If the first sample after this entry becomes valid is less than or equal to the fallingThreshold and alarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3), then a single falling alarm will be generated. This object may not be modified if the associated alarmStatus object is equal to valid(1)." ::= { alarmEntry 6 } alarmRisingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the sampled statistic. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is greater than or equal to this threshold and the associated alarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3). After a rising event is generated, another such event Waldbusser Standards Track [Page 38] RFC 2819 Remote Network Monitoring MIB May 2000 will not be generated until the sampled value falls below this threshold and reaches the alarmFallingThreshold. This object may not be modified if the associated alarmStatus object is equal to valid(1)." ::= { alarmEntry 7 } alarmFallingThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the sampled statistic. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is less than or equal to this threshold and the associated alarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3). After a falling event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches the alarmRisingThreshold. This object may not be modified if the associated alarmStatus object is equal to valid(1)." ::= { alarmEntry 8 } alarmRisingEventIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the eventEntry that is used when a rising threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid event index. This object may not be modified if the associated Waldbusser Standards Track [Page 39] RFC 2819 Remote Network Monitoring MIB May 2000 alarmStatus object is equal to valid(1)." ::= { alarmEntry 9 } alarmFallingEventIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the eventEntry that is used when a falling threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid event index. This object may not be modified if the associated alarmStatus object is equal to valid(1)." ::= { alarmEntry 10 } alarmOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { alarmEntry 11 } alarmStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this alarm entry." ::= { alarmEntry 12 } -- The Host Group -- Implementation of the Host group is optional. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The host group discovers new hosts on the network by -- keeping a list of source and destination MAC Addresses seen -- in good packets. For each of these addresses, the host group Waldbusser Standards Track [Page 40] RFC 2819 Remote Network Monitoring MIB May 2000 -- keeps a set of statistics. The hostControlTable controls -- which interfaces this function is performed on, and contains -- some information about the process. On behalf of each -- hostControlEntry, data is collected on an interface and placed -- in both the hostTable and the hostTimeTable. If the -- monitoring device finds itself short of resources, it may -- delete entries as needed. It is suggested that the device -- delete the least recently used entries first. -- The hostTable contains entries for each address discovered on -- a particular interface. Each entry contains statistical -- data about that host. This table is indexed by the -- MAC address of the host, through which a random access -- may be achieved. -- The hostTimeTable contains data in the same format as the -- hostTable, and must contain the same set of hosts, but is -- indexed using hostTimeCreationOrder rather than hostAddress. -- The hostTimeCreationOrder is an integer which reflects -- the relative order in which a particular entry was discovered -- and thus inserted into the table. As this order, and thus -- the index, is among those entries currently in the table, -- the index for a particular entry may change if an -- (earlier) entry is deleted. Thus the association between -- hostTimeCreationOrder and hostTimeEntry may be broken at -- any time. -- The hostTimeTable has two important uses. The first is the -- fast download of this potentially large table. Because the -- index of this table runs from 1 to the size of the table, -- inclusive, its values are predictable. This allows very -- efficient packing of variables into SNMP PDU's and allows -- a table transfer to have multiple packets outstanding. -- These benefits increase transfer rates tremendously. -- The second use of the hostTimeTable is the efficient discovery -- by the management station of new entries added to the table. -- After the management station has downloaded the entire table, -- it knows that new entries will be added immediately after the -- end of the current table. It can thus detect new entries there -- and retrieve them easily. -- Because the association between hostTimeCreationOrder and -- hostTimeEntry may be broken at any time, the management -- station must monitor the related hostControlLastDeleteTime -- object. When the management station thus detects a deletion, -- it must assume that any such associations have been broken, -- and invalidate any it has stored locally. This includes Waldbusser Standards Track [Page 41] RFC 2819 Remote Network Monitoring MIB May 2000 -- restarting any download of the hostTimeTable that may have been -- in progress, as well as rediscovering the end of the -- hostTimeTable so that it may detect new entries. If the -- management station does not detect the broken association, -- it may continue to refer to a particular host by its -- creationOrder while unwittingly retrieving the data associated -- with another host entirely. If this happens while downloading -- the host table, the management station may fail to download -- all of the entries in the table. hostControlTable OBJECT-TYPE SYNTAX SEQUENCE OF HostControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of host table control entries." ::= { hosts 1 } hostControlEntry OBJECT-TYPE SYNTAX HostControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of parameters that set up the discovery of hosts on a particular interface and the collection of statistics about these hosts. For example, an instance of the hostControlTableSize object might be named hostControlTableSize.1" INDEX { hostControlIndex } ::= { hostControlTable 1 } HostControlEntry ::= SEQUENCE { hostControlIndex Integer32, hostControlDataSource OBJECT IDENTIFIER, hostControlTableSize Integer32, hostControlLastDeleteTime TimeTicks, hostControlOwner OwnerString, hostControlStatus EntryStatus } hostControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the Waldbusser Standards Track [Page 42] RFC 2819 Remote Network Monitoring MIB May 2000 hostControl table. Each such entry defines a function that discovers hosts on a particular interface and places statistics about them in the hostTable and the hostTimeTable on behalf of this hostControlEntry." ::= { hostControlEntry 1 } hostControlDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the source of the data for this instance of the host function. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in RFC 2233 [17], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. The statistics in this group reflect all packets on the local network segment attached to the identified interface. An agent may or may not be able to tell if fundamental changes to the media of the interface have occurred and necessitate an invalidation of this entry. For example, a hot-pluggable ethernet card could be pulled out and replaced by a token-ring card. In such a case, if the agent has such knowledge of the change, it is recommended that it invalidate this entry. This object may not be modified if the associated hostControlStatus object is equal to valid(1)." ::= { hostControlEntry 2 } hostControlTableSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of hostEntries in the hostTable and the hostTimeTable associated with this hostControlEntry." ::= { hostControlEntry 3 } hostControlLastDeleteTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Waldbusser Standards Track [Page 43] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "The value of sysUpTime when the last entry was deleted from the portion of the hostTable associated with this hostControlEntry. If no deletions have occurred, this value shall be zero." ::= { hostControlEntry 4 } hostControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { hostControlEntry 5 } hostControlStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this hostControl entry. If this object is not equal to valid(1), all associated entries in the hostTable, hostTimeTable, and the hostTopNTable shall be deleted by the agent." ::= { hostControlEntry 6 } hostTable OBJECT-TYPE SYNTAX SEQUENCE OF HostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of host entries." ::= { hosts 2 } hostEntry OBJECT-TYPE SYNTAX HostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for a particular host that has been discovered on an interface of this device. For example, an instance of the hostOutBroadcastPkts object might be named hostOutBroadcastPkts.1.6.8.0.32.27.3.176" INDEX { hostIndex, hostAddress } ::= { hostTable 1 } Waldbusser Standards Track [Page 44] RFC 2819 Remote Network Monitoring MIB May 2000 HostEntry ::= SEQUENCE { hostAddress OCTET STRING, hostCreationOrder Integer32, hostIndex Integer32, hostInPkts Counter32, hostOutPkts Counter32, hostInOctets Counter32, hostOutOctets Counter32, hostOutErrors Counter32, hostOutBroadcastPkts Counter32, hostOutMulticastPkts Counter32 } hostAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The physical address of this host." ::= { hostEntry 1 } hostCreationOrder OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that defines the relative ordering of the creation time of hosts captured for a particular hostControlEntry. This index shall be between 1 and N, where N is the value of the associated hostControlTableSize. The ordering of the indexes is based on the order of each entry's insertion into the table, in which entries added earlier have a lower index value than entries added later. It is important to note that the order for a particular entry may change as an (earlier) entry is deleted from the table. Because this order may change, management stations should make use of the hostControlLastDeleteTime variable in the hostControlEntry associated with the relevant portion of the hostTable. By observing this variable, the management station may detect the circumstances where a previous association between a value of hostCreationOrder and a hostEntry may no longer hold." ::= { hostEntry 2 } Waldbusser Standards Track [Page 45] RFC 2819 Remote Network Monitoring MIB May 2000 hostIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The set of collected host statistics of which this entry is a part. The set of hosts identified by a particular value of this index is associated with the hostControlEntry as identified by the same value of hostControlIndex." ::= { hostEntry 3 } hostInPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted to this address since it was added to the hostTable." ::= { hostEntry 4 } hostOutPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, including bad packets, transmitted by this address since it was added to the hostTable." ::= { hostEntry 5 } hostInOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address since it was added to the hostTable (excluding framing bits but including FCS octets), except for those octets in bad packets." ::= { hostEntry 6 } hostOutOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only Waldbusser Standards Track [Page 46] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "The number of octets transmitted by this address since it was added to the hostTable (excluding framing bits but including FCS octets), including those octets in bad packets." ::= { hostEntry 7 } hostOutErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bad packets transmitted by this address since this host was added to the hostTable." ::= { hostEntry 8 } hostOutBroadcastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted by this address that were directed to the broadcast address since this host was added to the hostTable." ::= { hostEntry 9 } hostOutMulticastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted by this address that were directed to a multicast address since this host was added to the hostTable. Note that this number does not include packets directed to the broadcast address." ::= { hostEntry 10 } -- host Time Table hostTimeTable OBJECT-TYPE SYNTAX SEQUENCE OF HostTimeEntry MAX-ACCESS not-accessible STATUS current Waldbusser Standards Track [Page 47] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "A list of time-ordered host table entries." ::= { hosts 3 } hostTimeEntry OBJECT-TYPE SYNTAX HostTimeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for a particular host that has been discovered on an interface of this device. This collection includes the relative ordering of the creation time of this object. For example, an instance of the hostTimeOutBroadcastPkts object might be named hostTimeOutBroadcastPkts.1.687" INDEX { hostTimeIndex, hostTimeCreationOrder } ::= { hostTimeTable 1 } HostTimeEntry ::= SEQUENCE { hostTimeAddress OCTET STRING, hostTimeCreationOrder Integer32, hostTimeIndex Integer32, hostTimeInPkts Counter32, hostTimeOutPkts Counter32, hostTimeInOctets Counter32, hostTimeOutOctets Counter32, hostTimeOutErrors Counter32, hostTimeOutBroadcastPkts Counter32, hostTimeOutMulticastPkts Counter32 } hostTimeAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The physical address of this host." ::= { hostTimeEntry 1 } hostTimeCreationOrder OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the hostTime table among those entries associated with the same hostControlEntry. This index shall be between 1 and N, where N is the value of Waldbusser Standards Track [Page 48] RFC 2819 Remote Network Monitoring MIB May 2000 the associated hostControlTableSize. The ordering of the indexes is based on the order of each entry's insertion into the table, in which entries added earlier have a lower index value than entries added later. Thus the management station has the ability to learn of new entries added to this table without downloading the entire table. It is important to note that the index for a particular entry may change as an (earlier) entry is deleted from the table. Because this order may change, management stations should make use of the hostControlLastDeleteTime variable in the hostControlEntry associated with the relevant portion of the hostTimeTable. By observing this variable, the management station may detect the circumstances where a download of the table may have missed entries, and where a previous association between a value of hostTimeCreationOrder and a hostTimeEntry may no longer hold." ::= { hostTimeEntry 2 } hostTimeIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The set of collected host statistics of which this entry is a part. The set of hosts identified by a particular value of this index is associated with the hostControlEntry as identified by the same value of hostControlIndex." ::= { hostTimeEntry 3 } hostTimeInPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted to this address since it was added to the hostTimeTable." ::= { hostTimeEntry 4 } hostTimeOutPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only Waldbusser Standards Track [Page 49] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "The number of packets, including bad packets, transmitted by this address since it was added to the hostTimeTable." ::= { hostTimeEntry 5 } hostTimeInOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address since it was added to the hostTimeTable (excluding framing bits but including FCS octets), except for those octets in bad packets." ::= { hostTimeEntry 6 } hostTimeOutOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted by this address since it was added to the hostTimeTable (excluding framing bits but including FCS octets), including those octets in bad packets." ::= { hostTimeEntry 7 } hostTimeOutErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bad packets transmitted by this address since this host was added to the hostTimeTable." ::= { hostTimeEntry 8 } hostTimeOutBroadcastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted by this address that were directed to the broadcast address Waldbusser Standards Track [Page 50] RFC 2819 Remote Network Monitoring MIB May 2000 since this host was added to the hostTimeTable." ::= { hostTimeEntry 9 } hostTimeOutMulticastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted by this address that were directed to a multicast address since this host was added to the hostTimeTable. Note that this number does not include packets directed to the broadcast address." ::= { hostTimeEntry 10 } -- The Host Top "N" Group -- Implementation of the Host Top N group is optional. The Host Top N -- group requires the implementation of the host group. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The Host Top N group is used to prepare reports that describe -- the hosts that top a list ordered by one of their statistics. -- The available statistics are samples of one of their -- base statistics, over an interval specified by the management -- station. Thus, these statistics are rate based. The management -- station also selects how many such hosts are reported. -- The hostTopNControlTable is used to initiate the generation of -- such a report. The management station may select the parameters -- of such a report, such as which interface, which statistic, -- how many hosts, and the start and stop times of the sampling. -- When the report is prepared, entries are created in the -- hostTopNTable associated with the relevant hostTopNControlEntry. -- These entries are static for each report after it has been -- prepared. hostTopNControlTable OBJECT-TYPE SYNTAX SEQUENCE OF HostTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of top N host control entries." ::= { hostTopN 1 } hostTopNControlEntry OBJECT-TYPE Waldbusser Standards Track [Page 51] RFC 2819 Remote Network Monitoring MIB May 2000 SYNTAX HostTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N hosts according to several metrics. For example, an instance of the hostTopNDuration object might be named hostTopNDuration.3" INDEX { hostTopNControlIndex } ::= { hostTopNControlTable 1 } HostTopNControlEntry ::= SEQUENCE { hostTopNControlIndex Integer32, hostTopNHostIndex Integer32, hostTopNRateBase INTEGER, hostTopNTimeRemaining Integer32, hostTopNDuration Integer32, hostTopNRequestedSize Integer32, hostTopNGrantedSize Integer32, hostTopNStartTime TimeTicks, hostTopNOwner OwnerString, hostTopNStatus EntryStatus } hostTopNControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the hostTopNControl table. Each such entry defines one top N report prepared for one interface." ::= { hostTopNControlEntry 1 } hostTopNHostIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The host table for which a top N report will be prepared on behalf of this entry. The host table identified by a particular value of this index is associated with the same host table as identified by the same value of hostIndex. This object may not be modified if the associated hostTopNStatus object is equal to valid(1)." Waldbusser Standards Track [Page 52] RFC 2819 Remote Network Monitoring MIB May 2000 ::= { hostTopNControlEntry 2 } hostTopNRateBase OBJECT-TYPE SYNTAX INTEGER { hostTopNInPkts(1), hostTopNOutPkts(2), hostTopNInOctets(3), hostTopNOutOctets(4), hostTopNOutErrors(5), hostTopNOutBroadcastPkts(6), hostTopNOutMulticastPkts(7) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable for each host that the hostTopNRate variable is based upon. This object may not be modified if the associated hostTopNStatus object is equal to valid(1)." ::= { hostTopNControlEntry 3 } hostTopNTimeRemaining OBJECT-TYPE SYNTAX Integer32 UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report, which is loaded into the associated hostTopNDuration object. When this object is set to a non-zero value, any associated hostTopNEntries shall be made inaccessible by the monitor. While the value of this object is non-zero, it decrements by one per second until it reaches zero. During this time, all associated hostTopNEntries shall remain inaccessible. At the time that this object decrements to zero, the report is made accessible in the hostTopNTable. Thus, the hostTopN table needs to be created only at the end of the collection interval." DEFVAL { 0 } ::= { hostTopNControlEntry 4 } Waldbusser Standards Track [Page 53] RFC 2819 Remote Network Monitoring MIB May 2000 hostTopNDuration OBJECT-TYPE SYNTAX Integer32 UNITS "Seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval, or if this report is currently being collected, the number of seconds that this report is being collected during this sampling interval. When the associated hostTopNTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the hostTopNTimeRemaining is set. This value shall be zero if no reports have been requested for this hostTopNControlEntry." DEFVAL { 0 } ::= { hostTopNControlEntry 5 } hostTopNRequestedSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of hosts requested for the top N table. When this object is created or modified, the probe should set hostTopNGrantedSize as closely to this object as is possible for the particular probe implementation and available resources." DEFVAL { 10 } ::= { hostTopNControlEntry 6 } hostTopNGrantedSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of hosts in the top N table. When the associated hostTopNRequestedSize object is created or modified, the probe should set this object as closely to the requested value as is possible for the particular implementation and available Waldbusser Standards Track [Page 54] RFC 2819 Remote Network Monitoring MIB May 2000 resources. The probe must not lower this value except as a result of a set to the associated hostTopNRequestedSize object. Hosts with the highest value of hostTopNRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more hosts." ::= { hostTopNControlEntry 7 } hostTopNStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this top N report was last started. In other words, this is the time that the associated hostTopNTimeRemaining object was modified to start the requested report." ::= { hostTopNControlEntry 8 } hostTopNOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { hostTopNControlEntry 9 } hostTopNStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this hostTopNControl entry. If this object is not equal to valid(1), all associated hostTopNEntries shall be deleted by the agent." ::= { hostTopNControlEntry 10 } hostTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF HostTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of top N host entries." ::= { hostTopN 2 } Waldbusser Standards Track [Page 55] RFC 2819 Remote Network Monitoring MIB May 2000 hostTopNEntry OBJECT-TYPE SYNTAX HostTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for a host that is part of a top N report. For example, an instance of the hostTopNRate object might be named hostTopNRate.3.10" INDEX { hostTopNReport, hostTopNIndex } ::= { hostTopNTable 1 } HostTopNEntry ::= SEQUENCE { hostTopNReport Integer32, hostTopNIndex Integer32, hostTopNAddress OCTET STRING, hostTopNRate Integer32 } hostTopNReport OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the top N report of which this entry is a part. The set of hosts identified by a particular value of this object is part of the same report as identified by the same value of the hostTopNControlIndex object." ::= { hostTopNEntry 1 } hostTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the hostTopN table among those in the same report. This index is between 1 and N, where N is the number of entries in this table. Increasing values of hostTopNIndex shall be assigned to entries with decreasing values of hostTopNRate until index N is assigned to the entry with the lowest value of hostTopNRate or there are no more hostTopNEntries." ::= { hostTopNEntry 2 } hostTopNAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only Waldbusser Standards Track [Page 56] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "The physical address of this host." ::= { hostTopNEntry 3 } hostTopNRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval. The selected variable is this host's instance of the object selected by hostTopNRateBase." ::= { hostTopNEntry 4 } -- The Matrix Group -- Implementation of the Matrix group is optional. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The Matrix group consists of the matrixControlTable, matrixSDTable -- and the matrixDSTable. These tables store statistics for a -- particular conversation between two addresses. As the device -- detects a new conversation, including those to a non-unicast -- address, it creates a new entry in both of the matrix tables. -- It must only create new entries based on information -- received in good packets. If the monitoring device finds -- itself short of resources, it may delete entries as needed. -- It is suggested that the device delete the least recently used -- entries first. matrixControlTable OBJECT-TYPE SYNTAX SEQUENCE OF MatrixControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information entries for the traffic matrix on each interface." ::= { matrix 1 } matrixControlEntry OBJECT-TYPE SYNTAX MatrixControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a traffic matrix on a particular Waldbusser Standards Track [Page 57] RFC 2819 Remote Network Monitoring MIB May 2000 interface. For example, an instance of the matrixControlLastDeleteTime object might be named matrixControlLastDeleteTime.1" INDEX { matrixControlIndex } ::= { matrixControlTable 1 } MatrixControlEntry ::= SEQUENCE { matrixControlIndex Integer32, matrixControlDataSource OBJECT IDENTIFIER, matrixControlTableSize Integer32, matrixControlLastDeleteTime TimeTicks, matrixControlOwner OwnerString, matrixControlStatus EntryStatus } matrixControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the matrixControl table. Each such entry defines a function that discovers conversations on a particular interface and places statistics about them in the matrixSDTable and the matrixDSTable on behalf of this matrixControlEntry." ::= { matrixControlEntry 1 } matrixControlDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the source of the data from which this entry creates a traffic matrix. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in RFC 2233 [17], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. The statistics in this group reflect all packets on the local network segment attached to the identified interface. An agent may or may not be able to tell if fundamental changes to the media of the interface have occurred and Waldbusser Standards Track [Page 58] RFC 2819 Remote Network Monitoring MIB May 2000 necessitate an invalidation of this entry. For example, a hot-pluggable ethernet card could be pulled out and replaced by a token-ring card. In such a case, if the agent has such knowledge of the change, it is recommended that it invalidate this entry. This object may not be modified if the associated matrixControlStatus object is equal to valid(1)." ::= { matrixControlEntry 2 } matrixControlTableSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of matrixSDEntries in the matrixSDTable for this interface. This must also be the value of the number of entries in the matrixDSTable for this interface." ::= { matrixControlEntry 3 } matrixControlLastDeleteTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last entry was deleted from the portion of the matrixSDTable or matrixDSTable associated with this matrixControlEntry. If no deletions have occurred, this value shall be zero." ::= { matrixControlEntry 4 } matrixControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { matrixControlEntry 5 } matrixControlStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this matrixControl entry. Waldbusser Standards Track [Page 59] RFC 2819 Remote Network Monitoring MIB May 2000 If this object is not equal to valid(1), all associated entries in the matrixSDTable and the matrixDSTable shall be deleted by the agent." ::= { matrixControlEntry 6 } matrixSDTable OBJECT-TYPE SYNTAX SEQUENCE OF MatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of traffic matrix entries indexed by source and destination MAC address." ::= { matrix 2 } matrixSDEntry OBJECT-TYPE SYNTAX MatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for communications between two addresses on a particular interface. For example, an instance of the matrixSDPkts object might be named matrixSDPkts.1.6.8.0.32.27.3.176.6.8.0.32.10.8.113" INDEX { matrixSDIndex, matrixSDSourceAddress, matrixSDDestAddress } ::= { matrixSDTable 1 } MatrixSDEntry ::= SEQUENCE { matrixSDSourceAddress OCTET STRING, matrixSDDestAddress OCTET STRING, matrixSDIndex Integer32, matrixSDPkts Counter32, matrixSDOctets Counter32, matrixSDErrors Counter32 } matrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The source physical address." ::= { matrixSDEntry 1 } matrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current Waldbusser Standards Track [Page 60] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "The destination physical address." ::= { matrixSDEntry 2 } matrixSDIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The set of collected matrix statistics of which this entry is a part. The set of matrix statistics identified by a particular value of this index is associated with the same matrixControlEntry as identified by the same value of matrixControlIndex." ::= { matrixSDEntry 3 } matrixSDPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets transmitted from the source address to the destination address (this number includes bad packets)." ::= { matrixSDEntry 4 } matrixSDOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets (excluding framing bits but including FCS octets) contained in all packets transmitted from the source address to the destination address." ::= { matrixSDEntry 5 } matrixSDErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bad packets transmitted from the source address to the destination address." ::= { matrixSDEntry 6 } Waldbusser Standards Track [Page 61] RFC 2819 Remote Network Monitoring MIB May 2000 -- Traffic matrix tables from destination to source matrixDSTable OBJECT-TYPE SYNTAX SEQUENCE OF MatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of traffic matrix entries indexed by destination and source MAC address." ::= { matrix 3 } matrixDSEntry OBJECT-TYPE SYNTAX MatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for communications between two addresses on a particular interface. For example, an instance of the matrixSDPkts object might be named matrixSDPkts.1.6.8.0.32.10.8.113.6.8.0.32.27.3.176" INDEX { matrixDSIndex, matrixDSDestAddress, matrixDSSourceAddress } ::= { matrixDSTable 1 } MatrixDSEntry ::= SEQUENCE { matrixDSSourceAddress OCTET STRING, matrixDSDestAddress OCTET STRING, matrixDSIndex Integer32, matrixDSPkts Counter32, matrixDSOctets Counter32, matrixDSErrors Counter32 } matrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The source physical address." ::= { matrixDSEntry 1 } matrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The destination physical address." ::= { matrixDSEntry 2 } Waldbusser Standards Track [Page 62] RFC 2819 Remote Network Monitoring MIB May 2000 matrixDSIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The set of collected matrix statistics of which this entry is a part. The set of matrix statistics identified by a particular value of this index is associated with the same matrixControlEntry as identified by the same value of matrixControlIndex." ::= { matrixDSEntry 3 } matrixDSPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets transmitted from the source address to the destination address (this number includes bad packets)." ::= { matrixDSEntry 4 } matrixDSOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets (excluding framing bits but including FCS octets) contained in all packets transmitted from the source address to the destination address." ::= { matrixDSEntry 5 } matrixDSErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bad packets transmitted from the source address to the destination address." ::= { matrixDSEntry 6 } -- The Filter Group -- Implementation of the Filter group is optional. Waldbusser Standards Track [Page 63] RFC 2819 Remote Network Monitoring MIB May 2000 -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The Filter group allows packets to be captured with an -- arbitrary filter expression. A logical data and -- event stream or "channel" is formed by the packets -- that match the filter expression. -- -- This filter mechanism allows the creation of an arbitrary -- logical expression with which to filter packets. Each -- filter associated with a channel is OR'ed with the others. -- Within a filter, any bits checked in the data and status are -- AND'ed with respect to other bits in the same filter. The -- NotMask also allows for checking for inequality. Finally, -- the channelAcceptType object allows for inversion of the -- whole equation. -- -- If a management station wishes to receive a trap to alert it -- that new packets have been captured and are available for -- download, it is recommended that it set up an alarm entry that -- monitors the value of the relevant channelMatches instance. -- -- The channel can be turned on or off, and can also -- generate events when packets pass through it. filterTable OBJECT-TYPE SYNTAX SEQUENCE OF FilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of packet filter entries." ::= { filter 1 } filterEntry OBJECT-TYPE SYNTAX FilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters for a packet filter applied on a particular interface. As an example, an instance of the filterPktData object might be named filterPktData.12" INDEX { filterIndex } ::= { filterTable 1 } FilterEntry ::= SEQUENCE { filterIndex Integer32, filterChannelIndex Integer32, filterPktDataOffset Integer32, Waldbusser Standards Track [Page 64] RFC 2819 Remote Network Monitoring MIB May 2000 filterPktData OCTET STRING, filterPktDataMask OCTET STRING, filterPktDataNotMask OCTET STRING, filterPktStatus Integer32, filterPktStatusMask Integer32, filterPktStatusNotMask Integer32, filterOwner OwnerString, filterStatus EntryStatus } filterIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the filter table. Each such entry defines one filter that is to be applied to every packet received on an interface." ::= { filterEntry 1 } filterChannelIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the channel of which this filter is a part. The filters identified by a particular value of this object are associated with the same channel as identified by the same value of the channelIndex object." ::= { filterEntry 2 } filterPktDataOffset OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-create STATUS current DESCRIPTION "The offset from the beginning of each packet where a match of packet data will be attempted. This offset is measured from the point in the physical layer packet after the framing bits, if any. For example, in an Ethernet frame, this point is at the beginning of the destination MAC address. This object may not be modified if the associated filterStatus object is equal to valid(1)." DEFVAL { 0 } Waldbusser Standards Track [Page 65] RFC 2819 Remote Network Monitoring MIB May 2000 ::= { filterEntry 3 } filterPktData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The data that is to be matched with the input packet. For each packet received, this filter and the accompanying filterPktDataMask and filterPktDataNotMask will be adjusted for the offset. The only bits relevant to this match algorithm are those that have the corresponding filterPktDataMask bit equal to one. The following three rules are then applied to every packet: (1) If the packet is too short and does not have data corresponding to part of the filterPktData, the packet will fail this data match. (2) For each relevant bit from the packet with the corresponding filterPktDataNotMask bit set to zero, if the bit from the packet is not equal to the corresponding bit from the filterPktData, then the packet will fail this data match. (3) If for every relevant bit from the packet with the corresponding filterPktDataNotMask bit set to one, the bit from the packet is equal to the corresponding bit from the filterPktData, then the packet will fail this data match. Any packets that have not failed any of the three matches above have passed this data match. In particular, a zero length filter will match any packet. This object may not be modified if the associated filterStatus object is equal to valid(1)." ::= { filterEntry 4 } filterPktDataMask OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The mask that is applied to the match process. After adjusting this mask for the offset, only those bits in the received packet that correspond to bits set in this mask are relevant for further processing by the Waldbusser Standards Track [Page 66] RFC 2819 Remote Network Monitoring MIB May 2000 match algorithm. The offset is applied to filterPktDataMask in the same way it is applied to the filter. For the purposes of the matching algorithm, if the associated filterPktData object is longer than this mask, this mask is conceptually extended with '1' bits until it reaches the length of the filterPktData object. This object may not be modified if the associated filterStatus object is equal to valid(1)." ::= { filterEntry 5 } filterPktDataNotMask OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The inversion mask that is applied to the match process. After adjusting this mask for the offset, those relevant bits in the received packet that correspond to bits cleared in this mask must all be equal to their corresponding bits in the filterPktData object for the packet to be accepted. In addition, at least one of those relevant bits in the received packet that correspond to bits set in this mask must be different to its corresponding bit in the filterPktData object. For the purposes of the matching algorithm, if the associated filterPktData object is longer than this mask, this mask is conceptually extended with '0' bits until it reaches the length of the filterPktData object. This object may not be modified if the associated filterStatus object is equal to valid(1)." ::= { filterEntry 6 } filterPktStatus OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The status that is to be matched with the input packet. The only bits relevant to this match algorithm are those that have the corresponding filterPktStatusMask bit equal to one. The following two rules are then applied to every packet: (1) For each relevant bit from the packet status with the corresponding filterPktStatusNotMask bit set to zero, if the bit from the packet status is not equal to the Waldbusser Standards Track [Page 67] RFC 2819 Remote Network Monitoring MIB May 2000 corresponding bit from the filterPktStatus, then the packet will fail this status match. (2) If for every relevant bit from the packet status with the corresponding filterPktStatusNotMask bit set to one, the bit from the packet status is equal to the corresponding bit from the filterPktStatus, then the packet will fail this status match. Any packets that have not failed either of the two matches above have passed this status match. In particular, a zero length status filter will match any packet's status. The value of the packet status is a sum. This sum initially takes the value zero. Then, for each error, E, that has been discovered in this packet, 2 raised to a value representing E is added to the sum. The errors and the bits that represent them are dependent on the media type of the interface that this channel is receiving packets from. The errors defined for a packet captured off of an Ethernet interface are as follows: bit # Error 0 Packet is longer than 1518 octets 1 Packet is shorter than 64 octets 2 Packet experienced a CRC or Alignment error For example, an Ethernet fragment would have a value of 6 (2^1 + 2^2). As this MIB is expanded to new media types, this object will have other media-specific errors defined. For the purposes of this status matching algorithm, if the packet status is longer than this filterPktStatus object, this object is conceptually extended with '0' bits until it reaches the size of the packet status. This object may not be modified if the associated filterStatus object is equal to valid(1)." ::= { filterEntry 7 } filterPktStatusMask OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current Waldbusser Standards Track [Page 68] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "The mask that is applied to the status match process. Only those bits in the received packet that correspond to bits set in this mask are relevant for further processing by the status match algorithm. For the purposes of the matching algorithm, if the associated filterPktStatus object is longer than this mask, this mask is conceptually extended with '1' bits until it reaches the size of the filterPktStatus. In addition, if a packet status is longer than this mask, this mask is conceptually extended with '0' bits until it reaches the size of the packet status. This object may not be modified if the associated filterStatus object is equal to valid(1)." ::= { filterEntry 8 } filterPktStatusNotMask OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The inversion mask that is applied to the status match process. Those relevant bits in the received packet status that correspond to bits cleared in this mask must all be equal to their corresponding bits in the filterPktStatus object for the packet to be accepted. In addition, at least one of those relevant bits in the received packet status that correspond to bits set in this mask must be different to its corresponding bit in the filterPktStatus object for the packet to be accepted. For the purposes of the matching algorithm, if the associated filterPktStatus object or a packet status is longer than this mask, this mask is conceptually extended with '0' bits until it reaches the longer of the lengths of the filterPktStatus object and the packet status. This object may not be modified if the associated filterStatus object is equal to valid(1)." ::= { filterEntry 9 } filterOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." Waldbusser Standards Track [Page 69] RFC 2819 Remote Network Monitoring MIB May 2000 ::= { filterEntry 10 } filterStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this filter entry." ::= { filterEntry 11 } channelTable OBJECT-TYPE SYNTAX SEQUENCE OF ChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of packet channel entries." ::= { filter 2 } channelEntry OBJECT-TYPE SYNTAX ChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters for a packet channel applied on a particular interface. As an example, an instance of the channelMatches object might be named channelMatches.3" INDEX { channelIndex } ::= { channelTable 1 } ChannelEntry ::= SEQUENCE { channelIndex Integer32, channelIfIndex Integer32, channelAcceptType INTEGER, channelDataControl INTEGER, channelTurnOnEventIndex Integer32, channelTurnOffEventIndex Integer32, channelEventIndex Integer32, channelEventStatus INTEGER, channelMatches Counter32, channelDescription DisplayString, channelOwner OwnerString, channelStatus EntryStatus } channelIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current Waldbusser Standards Track [Page 70] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "An index that uniquely identifies an entry in the channel table. Each such entry defines one channel, a logical data and event stream. It is suggested that before creating a channel, an application should scan all instances of the filterChannelIndex object to make sure that there are no pre-existing filters that would be inadvertently be linked to the channel." ::= { channelEntry 1 } channelIfIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object uniquely identifies the interface on this remote network monitoring device to which the associated filters are applied to allow data into this channel. The interface identified by a particular value of this object is the same interface as identified by the same value of the ifIndex object, defined in RFC 2233 [17]. The filters in this group are applied to all packets on the local network segment attached to the identified interface. An agent may or may not be able to tell if fundamental changes to the media of the interface have occurred and necessitate an invalidation of this entry. For example, a hot-pluggable ethernet card could be pulled out and replaced by a token-ring card. In such a case, if the agent has such knowledge of the change, it is recommended that it invalidate this entry. This object may not be modified if the associated channelStatus object is equal to valid(1)." ::= { channelEntry 2 } channelAcceptType OBJECT-TYPE SYNTAX INTEGER { acceptMatched(1), acceptFailed(2) } MAX-ACCESS read-create STATUS current DESCRIPTION Waldbusser Standards Track [Page 71] RFC 2819 Remote Network Monitoring MIB May 2000 "This object controls the action of the filters associated with this channel. If this object is equal to acceptMatched(1), packets will be accepted to this channel if they are accepted by both the packet data and packet status matches of an associated filter. If this object is equal to acceptFailed(2), packets will be accepted to this channel only if they fail either the packet data match or the packet status match of each of the associated filters. In particular, a channel with no associated filters will match no packets if set to acceptMatched(1) case and will match all packets in the acceptFailed(2) case. This object may not be modified if the associated channelStatus object is equal to valid(1)." ::= { channelEntry 3 } channelDataControl OBJECT-TYPE SYNTAX INTEGER { on(1), off(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the flow of data through this channel. If this object is on(1), data, status and events flow through this channel. If this object is off(2), data, status and events will not flow through this channel." DEFVAL { off } ::= { channelEntry 4 } channelTurnOnEventIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the event that is configured to turn the associated channelDataControl from off to on when the event is generated. The event identified by a particular value of this object is the same event as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In fact, if no event is intended for this channel, channelTurnOnEventIndex must be set to zero, a non-existent event index. Waldbusser Standards Track [Page 72] RFC 2819 Remote Network Monitoring MIB May 2000 This object may not be modified if the associated channelStatus object is equal to valid(1)." ::= { channelEntry 5 } channelTurnOffEventIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the event that is configured to turn the associated channelDataControl from on to off when the event is generated. The event identified by a particular value of this object is the same event as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In fact, if no event is intended for this channel, channelTurnOffEventIndex must be set to zero, a non-existent event index. This object may not be modified if the associated channelStatus object is equal to valid(1)." ::= { channelEntry 6 } channelEventIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the event that is configured to be generated when the associated channelDataControl is on and a packet is matched. The event identified by a particular value of this object is the same event as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In fact, if no event is intended for this channel, channelEventIndex must be set to zero, a non-existent event index. This object may not be modified if the associated channelStatus object is equal to valid(1)." ::= { channelEntry 7 } channelEventStatus OBJECT-TYPE SYNTAX INTEGER { eventReady(1), eventFired(2), Waldbusser Standards Track [Page 73] RFC 2819 Remote Network Monitoring MIB May 2000 eventAlwaysReady(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The event status of this channel. If this channel is configured to generate events when packets are matched, a means of controlling the flow of those events is often needed. When this object is equal to eventReady(1), a single event may be generated, after which this object will be set by the probe to eventFired(2). While in the eventFired(2) state, no events will be generated until the object is modified to eventReady(1) (or eventAlwaysReady(3)). The management station can thus easily respond to a notification of an event by re-enabling this object. If the management station wishes to disable this flow control and allow events to be generated at will, this object may be set to eventAlwaysReady(3). Disabling the flow control is discouraged as it can result in high network traffic or other performance problems." DEFVAL { eventReady } ::= { channelEntry 8 } channelMatches OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this channel has matched a packet. Note that this object is updated even when channelDataControl is set to off." ::= { channelEntry 9 } channelDescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..127)) MAX-ACCESS read-create STATUS current DESCRIPTION "A comment describing this channel." ::= { channelEntry 10 } channelOwner OBJECT-TYPE Waldbusser Standards Track [Page 74] RFC 2819 Remote Network Monitoring MIB May 2000 SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { channelEntry 11 } channelStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this channel entry." ::= { channelEntry 12 } -- The Packet Capture Group -- Implementation of the Packet Capture group is optional. The Packet -- Capture Group requires implementation of the Filter Group. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The Packet Capture group allows packets to be captured -- upon a filter match. The bufferControlTable controls -- the captured packets output from a channel that is -- associated with it. The captured packets are placed -- in entries in the captureBufferTable. These entries are -- associated with the bufferControlEntry on whose behalf they -- were stored. bufferControlTable OBJECT-TYPE SYNTAX SEQUENCE OF BufferControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of buffers control entries." ::= { capture 1 } bufferControlEntry OBJECT-TYPE SYNTAX BufferControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the collection of a stream of packets that have matched filters. As an example, an instance of the bufferControlCaptureSliceSize object might be named bufferControlCaptureSliceSize.3" Waldbusser Standards Track [Page 75] RFC 2819 Remote Network Monitoring MIB May 2000 INDEX { bufferControlIndex } ::= { bufferControlTable 1 } BufferControlEntry ::= SEQUENCE { bufferControlIndex Integer32, bufferControlChannelIndex Integer32, bufferControlFullStatus INTEGER, bufferControlFullAction INTEGER, bufferControlCaptureSliceSize Integer32, bufferControlDownloadSliceSize Integer32, bufferControlDownloadOffset Integer32, bufferControlMaxOctetsRequested Integer32, bufferControlMaxOctetsGranted Integer32, bufferControlCapturedPackets Integer32, bufferControlTurnOnTime TimeTicks, bufferControlOwner OwnerString, bufferControlStatus EntryStatus } bufferControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the bufferControl table. The value of this index shall never be zero. Each such entry defines one set of packets that is captured and controlled by one or more filters." ::= { bufferControlEntry 1 } bufferControlChannelIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "An index that identifies the channel that is the source of packets for this bufferControl table. The channel identified by a particular value of this index is the same as identified by the same value of the channelIndex object. This object may not be modified if the associated bufferControlStatus object is equal to valid(1)." ::= { bufferControlEntry 2 } bufferControlFullStatus OBJECT-TYPE SYNTAX INTEGER { Waldbusser Standards Track [Page 76] RFC 2819 Remote Network Monitoring MIB May 2000 spaceAvailable(1), full(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object shows whether the buffer has room to accept new packets or if it is full. If the status is spaceAvailable(1), the buffer is accepting new packets normally. If the status is full(2) and the associated bufferControlFullAction object is wrapWhenFull, the buffer is accepting new packets by deleting enough of the oldest packets to make room for new ones as they arrive. Otherwise, if the status is full(2) and the bufferControlFullAction object is lockWhenFull, then the buffer has stopped collecting packets. When this object is set to full(2) the probe must not later set it to spaceAvailable(1) except in the case of a significant gain in resources such as an increase of bufferControlOctetsGranted. In particular, the wrap-mode action of deleting old packets to make room for newly arrived packets must not affect the value of this object." ::= { bufferControlEntry 3 } bufferControlFullAction OBJECT-TYPE SYNTAX INTEGER { lockWhenFull(1), wrapWhenFull(2) -- FIFO } MAX-ACCESS read-create STATUS current DESCRIPTION "Controls the action of the buffer when it reaches the full status. When in the lockWhenFull(1) state and a packet is added to the buffer that fills the buffer, the bufferControlFullStatus will be set to full(2) and this buffer will stop capturing packets." ::= { bufferControlEntry 4 } bufferControlCaptureSliceSize OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-create Waldbusser Standards Track [Page 77] RFC 2819 Remote Network Monitoring MIB May 2000 STATUS current DESCRIPTION "The maximum number of octets of each packet that will be saved in this capture buffer. For example, if a 1500 octet packet is received by the probe and this object is set to 500, then only 500 octets of the packet will be stored in the associated capture buffer. If this variable is set to 0, the capture buffer will save as many octets as is possible. This object may not be modified if the associated bufferControlStatus object is equal to valid(1)." DEFVAL { 100 } ::= { bufferControlEntry 5 } bufferControlDownloadSliceSize OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of octets of each packet in this capture buffer that will be returned in an SNMP retrieval of that packet. For example, if 500 octets of a packet have been stored in the associated capture buffer, the associated bufferControlDownloadOffset is 0, and this object is set to 100, then the captureBufferPacket object that contains the packet will contain only the first 100 octets of the packet. A prudent manager will take into account possible interoperability or fragmentation problems that may occur if the download slice size is set too large. In particular, conformant SNMP implementations are not required to accept messages whose length exceeds 484 octets, although they are encouraged to support larger datagrams whenever feasible." DEFVAL { 100 } ::= { bufferControlEntry 6 } bufferControlDownloadOffset OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-create STATUS current DESCRIPTION Waldbusser Standards Track [Page 78] RFC 2819 Remote Network Monitoring MIB May 2000 "The offset of the first octet of each packet in this capture buffer that will be returned in an SNMP retrieval of that packet. For example, if 500 octets of a packet have been stored in the associated capture buffer and this object is set to 100, then the captureBufferPacket object that contains the packet will contain bytes starting 100 octets into the packet." DEFVAL { 0 } ::= { bufferControlEntry 7 } bufferControlMaxOctetsRequested OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-create STATUS current DESCRIPTION "The requested maximum number of octets to be saved in this captureBuffer, including any implementation-specific overhead. If this variable is set to -1, the capture buffer will save as many octets as is possible. When this object is created or modified, the probe should set bufferControlMaxOctetsGranted as closely to this object as is possible for the particular probe implementation and available resources. However, if the object has the special value of -1, the probe must set bufferControlMaxOctetsGranted to -1." DEFVAL { -1 } ::= { bufferControlEntry 8 } bufferControlMaxOctetsGranted OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of octets that can be saved in this captureBuffer, including overhead. If this variable is -1, the capture buffer will save as many octets as possible. When the bufferControlMaxOctetsRequested object is created or modified, the probe should set this object as closely to the requested value as is possible for the particular probe implementation and available resources. However, if the request object has the special value Waldbusser Standards Track [Page 79] RFC 2819 Remote Network Monitoring MIB May 2000 of -1, the probe must set this object to -1. The probe must not lower this value except as a result of a modification to the associated bufferControlMaxOctetsRequested object. When this maximum number of octets is reached and a new packet is to be added to this capture buffer and the corresponding bufferControlFullAction is set to wrapWhenFull(2), enough of the oldest packets associated with this capture buffer shall be deleted by the agent so that the new packet can be added. If the corresponding bufferControlFullAction is set to lockWhenFull(1), the new packet shall be discarded. In either case, the probe must set bufferControlFullStatus to full(2). When the value of this object changes to a value less than the current value, entries are deleted from the captureBufferTable associated with this bufferControlEntry. Enough of the oldest of these captureBufferEntries shall be deleted by the agent so that the number of octets used remains less than or equal to the new value of this object. When the value of this object changes to a value greater than the current value, the number of associated captureBufferEntries may be allowed to grow." ::= { bufferControlEntry 9 } bufferControlCapturedPackets OBJECT-TYPE SYNTAX Integer32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets currently in this captureBuffer." ::= { bufferControlEntry 10 } bufferControlTurnOnTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this capture buffer was first turned on." Waldbusser Standards Track [Page 80] RFC 2819 Remote Network Monitoring MIB May 2000 ::= { bufferControlEntry 11 } bufferControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { bufferControlEntry 12 } bufferControlStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this buffer Control Entry." ::= { bufferControlEntry 13 } captureBufferTable OBJECT-TYPE SYNTAX SEQUENCE OF CaptureBufferEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of packets captured off of a channel." ::= { capture 2 } captureBufferEntry OBJECT-TYPE SYNTAX CaptureBufferEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A packet captured off of an attached network. As an example, an instance of the captureBufferPacketData object might be named captureBufferPacketData.3.1783" INDEX { captureBufferControlIndex, captureBufferIndex } ::= { captureBufferTable 1 } CaptureBufferEntry ::= SEQUENCE { captureBufferControlIndex Integer32, captureBufferIndex Integer32, captureBufferPacketID Integer32, captureBufferPacketData OCTET STRING, captureBufferPacketLength Integer32, captureBufferPacketTime Integer32, captureBufferPacketStatus Integer32 } Waldbusser Standards Track [Page 81] RFC 2819 Remote Network Monitoring MIB May 2000 captureBufferControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the bufferControlEntry with which this packet is associated." ::= { captureBufferEntry 1 } captureBufferIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the captureBuffer table associated with a particular bufferControlEntry. This index will start at 1 and increase by one for each new packet added with the same captureBufferControlIndex. Should this value reach 2147483647, the next packet added with the same captureBufferControlIndex shall cause this value to wrap around to 1." ::= { captureBufferEntry 2 } captureBufferPacketID OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "An index that describes the order of packets that are received on a particular interface. The packetID of a packet captured on an interface is defined to be greater than the packetID's of all packets captured previously on the same interface. As the captureBufferPacketID object has a maximum positive value of 2^31 - 1, any captureBufferPacketID object shall have the value of the associated packet's packetID mod 2^31." ::= { captureBufferEntry 3 } captureBufferPacketData OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The data inside the packet, starting at the beginning of the packet plus any offset specified in the Waldbusser Standards Track [Page 82] RFC 2819 Remote Network Monitoring MIB May 2000 associated bufferControlDownloadOffset, including any link level headers. The length of the data in this object is the minimum of the length of the captured packet minus the offset, the length of the associated bufferControlCaptureSliceSize minus the offset, and the associated bufferControlDownloadSliceSize. If this minimum is less than zero, this object shall have a length of zero." ::= { captureBufferEntry 4 } captureBufferPacketLength OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The actual length (off the wire) of the packet stored in this entry, including FCS octets." ::= { captureBufferEntry 5 } captureBufferPacketTime OBJECT-TYPE SYNTAX Integer32 UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of milliseconds that had passed since this capture buffer was first turned on when this packet was captured." ::= { captureBufferEntry 6 } captureBufferPacketStatus OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A value which indicates the error status of this packet. The value of this object is defined in the same way as filterPktStatus. The value is a sum. This sum initially takes the value zero. Then, for each error, E, that has been discovered in this packet, 2 raised to a value representing E is added to the sum. The errors defined for a packet captured off of an Ethernet interface are as follows: bit # Error 0 Packet is longer than 1518 octets Waldbusser Standards Track [Page 83] RFC 2819 Remote Network Monitoring MIB May 2000 1 Packet is shorter than 64 octets 2 Packet experienced a CRC or Alignment error 3 First packet in this capture buffer after it was detected that some packets were not processed correctly. 4 Packet's order in buffer is only approximate (May only be set for packets sent from the probe) For example, an Ethernet fragment would have a value of 6 (2^1 + 2^2). As this MIB is expanded to new media types, this object will have other media-specific errors defined." ::= { captureBufferEntry 7 } -- The Event Group -- Implementation of the Event group is optional. -- Consult the MODULE-COMPLIANCE macro for the authoritative -- conformance information for this MIB. -- -- The Event group controls the generation and notification -- of events from this device. Each entry in the eventTable -- describes the parameters of the event that can be triggered. -- Each event entry is fired by an associated condition located -- elsewhere in the MIB. An event entry may also be associated -- with a function elsewhere in the MIB that will be executed -- when the event is generated. For example, a channel may -- be turned on or off by the firing of an event. -- -- Each eventEntry may optionally specify that a log entry -- be created on its behalf whenever the event occurs. -- Each entry may also specify that notification should -- occur by way of SNMP trap messages. In this case, the -- community for the trap message is given in the associated -- eventCommunity object. The enterprise and specific trap -- fields of the trap are determined by the condition that -- triggered the event. Two traps are defined: risingAlarm and -- fallingAlarm. If the eventTable is triggered by a condition -- specified elsewhere, the enterprise and specific trap fields -- must be specified for traps generated for that condition. eventTable OBJECT-TYPE SYNTAX SEQUENCE OF EventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Waldbusser Standards Track [Page 84] RFC 2819 Remote Network Monitoring MIB May 2000 "A list of events to be generated." ::= { event 1 } eventEntry OBJECT-TYPE SYNTAX EventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that describe an event to be generated when certain conditions are met. As an example, an instance of the eventLastTimeSent object might be named eventLastTimeSent.6" INDEX { eventIndex } ::= { eventTable 1 } EventEntry ::= SEQUENCE { eventIndex Integer32, eventDescription DisplayString, eventType INTEGER, eventCommunity OCTET STRING, eventLastTimeSent TimeTicks, eventOwner OwnerString, eventStatus EntryStatus } eventIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the event table. Each such entry defines one event that is to be generated when the appropriate conditions occur." ::= { eventEntry 1 } eventDescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..127)) MAX-ACCESS read-create STATUS current DESCRIPTION "A comment describing this event entry." ::= { eventEntry 2 } eventType OBJECT-TYPE SYNTAX INTEGER { none(1), log(2), Waldbusser Standards Track [Page 85] RFC 2819 Remote Network Monitoring MIB May 2000 snmptrap(3), -- send an SNMP trap logandtrap(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of notification that the probe will make about this event. In the case of log, an entry is made in the log table for each event. In the case of snmp-trap, an SNMP trap is sent to one or more management stations." ::= { eventEntry 3 } eventCommunity OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..127)) MAX-ACCESS read-create STATUS current DESCRIPTION "If an SNMP trap is to be sent, it will be sent to the SNMP community specified by this octet string." ::= { eventEntry 4 } eventLastTimeSent OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this event entry last generated an event. If this entry has not generated any events, this value will be zero." ::= { eventEntry 5 } eventOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it. If this object contains a string starting with 'monitor' and has associated entries in the log table, all connected management stations should retrieve those log entries, as they may have significance to all management stations connected to this device" ::= { eventEntry 6 } Waldbusser Standards Track [Page 86] RFC 2819 Remote Network Monitoring MIB May 2000 eventStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this event entry. If this object is not equal to valid(1), all associated log entries shall be deleted by the agent." ::= { eventEntry 7 } -- logTable OBJECT-TYPE SYNTAX SEQUENCE OF LogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of events that have been logged." ::= { event 2 } logEntry OBJECT-TYPE SYNTAX LogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of data describing an event that has been logged. For example, an instance of the logDescription object might be named logDescription.6.47" INDEX { logEventIndex, logIndex } ::= { logTable 1 } LogEntry ::= SEQUENCE { logEventIndex Integer32, logIndex Integer32, logTime TimeTicks, logDescription DisplayString } logEventIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The event entry that generated this log entry. The log identified by a particular value of this index is associated with the same eventEntry as identified by the same value of eventIndex." Waldbusser Standards Track [Page 87] RFC 2819 Remote Network Monitoring MIB May 2000 ::= { logEntry 1 } logIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the log table amongst those generated by the same eventEntries. These indexes are assigned beginning with 1 and increase by one with each new log entry. The association between values of logIndex and logEntries is fixed for the lifetime of each logEntry. The agent may choose to delete the oldest instances of logEntry as required because of lack of memory. It is an implementation-specific matter as to when this deletion may occur." ::= { logEntry 2 } logTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this log entry was created." ::= { logEntry 3 } logDescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "An implementation dependent description of the event that activated this log entry." ::= { logEntry 4 } -- Remote Network Monitoring Traps rmonEventsV2 OBJECT-IDENTITY STATUS current DESCRIPTION "Definition point for RMON notifications." ::= { rmon 0 } risingAlarm NOTIFICATION-TYPE OBJECTS { alarmIndex, alarmVariable, alarmSampleType, alarmValue, alarmRisingThreshold } STATUS current Waldbusser Standards Track [Page 88] RFC 2819 Remote Network Monitoring MIB May 2000 DESCRIPTION "The SNMP trap that is generated when an alarm entry crosses its rising threshold and generates an event that is configured for sending SNMP traps." ::= { rmonEventsV2 1 } fallingAlarm NOTIFICATION-TYPE OBJECTS { alarmIndex, alarmVariable, alarmSampleType, alarmValue, alarmFallingThreshold } STATUS current DESCRIPTION "The SNMP trap that is generated when an alarm entry crosses its falling threshold and generates an event that is configured for sending SNMP traps." ::= { rmonEventsV2 2 } -- Conformance information rmonCompliances OBJECT IDENTIFIER ::= { rmonConformance 9 } rmonGroups OBJECT IDENTIFIER ::= { rmonConformance 10 } -- Compliance Statements rmonCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The requirements for conformance to the RMON MIB. At least one of the groups in this module must be implemented to conform to the RMON MIB. Implementations of this MIB must also implement the system group of MIB-II [16] and the IF-MIB [17]." MODULE -- this module GROUP rmonEtherStatsGroup DESCRIPTION "The RMON Ethernet Statistics Group is optional." GROUP rmonHistoryControlGroup DESCRIPTION "The RMON History Control Group is optional." GROUP rmonEthernetHistoryGroup DESCRIPTION "The RMON Ethernet History Group is optional." GROUP rmonAlarmGroup DESCRIPTION Waldbusser Standards Track [Page 89] RFC 2819 Remote Network Monitoring MIB May 2000 "The RMON Alarm Group is optional." GROUP rmonHostGroup DESCRIPTION "The RMON Host Group is mandatory when the rmonHostTopNGroup is implemented." GROUP rmonHostTopNGroup DESCRIPTION "The RMON Host Top N Group is optional." GROUP rmonMatrixGroup DESCRIPTION "The RMON Matrix Group is optional." GROUP rmonFilterGroup DESCRIPTION "The RMON Filter Group is mandatory when the rmonPacketCaptureGroup is implemented." GROUP rmonPacketCaptureGroup DESCRIPTION "The RMON Packet Capture Group is optional." GROUP rmonEventGroup DESCRIPTION "The RMON Event Group is mandatory when the rmonAlarmGroup is implemented." ::= { rmonCompliances 1 } rmonEtherStatsGroup OBJECT-GROUP OBJECTS { etherStatsIndex, etherStatsDataSource, etherStatsDropEvents, etherStatsOctets, etherStatsPkts, etherStatsBroadcastPkts, etherStatsMulticastPkts, etherStatsCRCAlignErrors, etherStatsUndersizePkts, etherStatsOversizePkts, etherStatsFragments, etherStatsJabbers, etherStatsCollisions, etherStatsPkts64Octets, etherStatsPkts65to127Octets, etherStatsPkts128to255Octets, etherStatsPkts256to511Octets, etherStatsPkts512to1023Octets, etherStatsPkts1024to1518Octets, etherStatsOwner, etherStatsStatus } STATUS current DESCRIPTION "The RMON Ethernet Statistics Group." Waldbusser Standards Track [Page 90] RFC 2819 Remote Network Monitoring MIB May 2000 ::= { rmonGroups 1 } rmonHistoryControlGroup OBJECT-GROUP OBJECTS { historyControlIndex, historyControlDataSource, historyControlBucketsRequested, historyControlBucketsGranted, historyControlInterval, historyControlOwner, historyControlStatus } STATUS current DESCRIPTION "The RMON History Control Group." ::= { rmonGroups 2 } rmonEthernetHistoryGroup OBJECT-GROUP OBJECTS { etherHistoryIndex, etherHistorySampleIndex, etherHistoryIntervalStart, etherHistoryDropEvents, etherHistoryOctets, etherHistoryPkts, etherHistoryBroadcastPkts, etherHistoryMulticastPkts, etherHistoryCRCAlignErrors, etherHistoryUndersizePkts, etherHistoryOversizePkts, etherHistoryFragments, etherHistoryJabbers, etherHistoryCollisions, etherHistoryUtilization } STATUS current DESCRIPTION "The RMON Ethernet History Group." ::= { rmonGroups 3 } rmonAlarmGroup OBJECT-GROUP OBJECTS { alarmIndex, alarmInterval, alarmVariable, alarmSampleType, alarmValue, alarmStartupAlarm, alarmRisingThreshold, alarmFallingThreshold, alarmRisingEventIndex, alarmFallingEventIndex, alarmOwner, alarmStatus } STATUS current DESCRIPTION "The RMON Alarm Group." ::= { rmonGroups 4 } rmonHostGroup OBJECT-GROUP OBJECTS { hostControlIndex, hostControlDataSource, hostControlTableSize, hostControlLastDeleteTime, hostControlOwner, hostControlStatus, Waldbusser Standards Track [Page 91] RFC 2819 Remote Network Monitoring MIB May 2000 hostAddress, hostCreationOrder, hostIndex, hostInPkts, hostOutPkts, hostInOctets, hostOutOctets, hostOutErrors, hostOutBroadcastPkts, hostOutMulticastPkts, hostTimeAddress, hostTimeCreationOrder, hostTimeIndex, hostTimeInPkts, hostTimeOutPkts, hostTimeInOctets, hostTimeOutOctets, hostTimeOutErrors, hostTimeOutBroadcastPkts, hostTimeOutMulticastPkts } STATUS current DESCRIPTION "The RMON Host Group." ::= { rmonGroups 5 } rmonHostTopNGroup OBJECT-GROUP OBJECTS { hostTopNControlIndex, hostTopNHostIndex, hostTopNRateBase, hostTopNTimeRemaining, hostTopNDuration, hostTopNRequestedSize, hostTopNGrantedSize, hostTopNStartTime, hostTopNOwner, hostTopNStatus, hostTopNReport, hostTopNIndex, hostTopNAddress, hostTopNRate } STATUS current DESCRIPTION "The RMON Host Top 'N' Group." ::= { rmonGroups 6 } rmonMatrixGroup OBJECT-GROUP OBJECTS { matrixControlIndex, matrixControlDataSource, matrixControlTableSize, matrixControlLastDeleteTime, matrixControlOwner, matrixControlStatus, matrixSDSourceAddress, matrixSDDestAddress, matrixSDIndex, matrixSDPkts, matrixSDOctets, matrixSDErrors, matrixDSSourceAddress, matrixDSDestAddress, matrixDSIndex, matrixDSPkts, matrixDSOctets, matrixDSErrors } STATUS current DESCRIPTION "The RMON Matrix Group." ::= { rmonGroups 7 } rmonFilterGroup OBJECT-GROUP OBJECTS { Waldbusser Standards Track [Page 92] RFC 2819 Remote Network Monitoring MIB May 2000 filterIndex, filterChannelIndex, filterPktDataOffset, filterPktData, filterPktDataMask, filterPktDataNotMask, filterPktStatus, filterPktStatusMask, filterPktStatusNotMask, filterOwner, filterStatus, channelIndex, channelIfIndex, channelAcceptType, channelDataControl, channelTurnOnEventIndex, channelTurnOffEventIndex, channelEventIndex, channelEventStatus, channelMatches, channelDescription, channelOwner, channelStatus } STATUS current DESCRIPTION "The RMON Filter Group." ::= { rmonGroups 8 } rmonPacketCaptureGroup OBJECT-GROUP OBJECTS { bufferControlIndex, bufferControlChannelIndex, bufferControlFullStatus, bufferControlFullAction, bufferControlCaptureSliceSize, bufferControlDownloadSliceSize, bufferControlDownloadOffset, bufferControlMaxOctetsRequested, bufferControlMaxOctetsGranted, bufferControlCapturedPackets, bufferControlTurnOnTime, bufferControlOwner, bufferControlStatus, captureBufferControlIndex, captureBufferIndex, captureBufferPacketID, captureBufferPacketData, captureBufferPacketLength, captureBufferPacketTime, captureBufferPacketStatus } STATUS current DESCRIPTION "The RMON Packet Capture Group." ::= { rmonGroups 9 } rmonEventGroup OBJECT-GROUP OBJECTS { eventIndex, eventDescription, eventType, eventCommunity, eventLastTimeSent, eventOwner, eventStatus, logEventIndex, logIndex, logTime, logDescription } STATUS current DESCRIPTION Waldbusser Standards Track [Page 93] RFC 2819 Remote Network Monitoring MIB May 2000 "The RMON Event Group." ::= { rmonGroups 10 } rmonNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { risingAlarm, fallingAlarm } STATUS current DESCRIPTION "The RMON Notification Group." ::= { rmonGroups 11 } END 6. Security Considerations In order to implement this MIB, a probe must capture all packets on the locally-attached network, including packets between third parties. These packets are analyzed to collect network addresses, protocol usage information, and conversation statistics. Data of this nature may be considered sensitive in some environments. In such environments the administrator may wish to restrict SNMP access to the probe. This MIB also includes functions for returning the contents of captured packets, potentially including sensitive user data or passwords. It is recommended that SNMP access to these functions be restricted. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Waldbusser Standards Track [Page 94] RFC 2819 Remote Network Monitoring MIB May 2000 7. Acknowledgments This document was produced by the IETF Remote Network Monitoring Working Group. 8. Author's Address Steve Waldbusser Phone: +1-650-948-6500 Fax: +1-650-745-0671 Email: waldbusser@nextbeacon.com 9. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. Waldbusser Standards Track [Page 95] RFC 2819 Remote Network Monitoring MIB May 2000 [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [18] Waldbusser, S., "Remote Network Monitoring MIB", RFC 1757, February 1995. [19] Waldbusser, S., "Token Ring Extensions to the Remote Network Monitoring MIB", RFC 1513, September 1993. [20] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [21] Waterman, R., Lahaye, B., Romascanu, D. and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999. [22] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. Waldbusser Standards Track [Page 96] RFC 2819 Remote Network Monitoring MIB May 2000 10. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Waldbusser Standards Track [Page 97] RFC 2819 Remote Network Monitoring MIB May 2000 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Waldbusser Standards Track [Page 98] snmp-mibs-downloader-1.1/mibrfcs/rfc2837.txt0000644000000000000000000025346411402176071015603 0ustar Network Working Group K. S. Teow Request for Comments: 2837 Brocade Communications Systems, Inc. Category: Standards Track May 2000 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. Table of Contents 1. The SNMP Management Framework ..................................2 2. Overview .......................................................3 2.1 Management View of a Fabric Element ...........................4 2.2 Structure of the Fabric Element MIB ...........................5 3. Object Definitions .............................................6 The Configuration Group ......................................8 The Module Table ...........................................9 The FxPort Configuration Table ............................12 The Status Group ............................................16 The FxPort Status Table ...................................16 The FxPort Physical Level Table ...........................18 The FxPort Fabric Login Table .............................20 The Error Group .............................................24 The Accounting Groups........................................27 The Class 1 Accounting Table ..............................27 The Class 2 Accounting Table ..............................31 The Class 3 Accounting Table ..............................33 The Capability Group ........................................35 Teow Standards Track [Page 1] RFC 2837 FC Fabric Element MIB May 2000 Conformance information .....................................38 4. Security Considerations .......................................43 5. Intellectual Property .........................................44 6. Acknowledgements ..............................................44 7. References ....................................................45 7.1 IETF References ..............................................45 7.2 Approved ANSI/NCITS References ...............................46 7.3 ANSI/NCITS References Under Development ......................47 8. Editors' Addresses ............................................47 9. Full Copyright Statement ......................................48 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Teow Standards Track [Page 2] RFC 2837 FC Fabric Element MIB May 2000 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview A Fibre Channel Fabric is an entity which interconnects Node Ports (N_Ports) or Node Loop Ports (NL_Ports). It provides transport and routing functions. In essence, a Fabric is a network of N_Ports and/or NL_Ports to communicate with one another. A Fabric is composed of one or more Fabric Element that are interconnected via Inter-element Links (IEL). A Fabric Element is the smallest unit of a Fabric that meets the definition of a Fabric. It must consist of at least three external ports to connect to either N_Ports, NL_Ports or other Fabric Elements. In general, a Fabric Element port may be of one of the following types: (1) F_Port, a fabric port to connect to an N_Port ([17], [21], [22]); (2) FL_Port, a fabric port that also supports a FC Arbitrated Loop consisting of one or more NL_Ports ([20], [24]). (3) E_Port, an expansion port to connect to another Fabric Element ([18], [23]); This memo shall define objects related to a Fabric Element, its F_Ports and FL_Ports. Objects related to other types of FC ports shall be defined in future. For the rest of the document, the term, "FxPort", will be used to refer to both F_Port and FL_Port where the distinction is not necessary. The term, "NxPort" will be used to refer to both N_Port and NL_Port in the similar fashion. Teow Standards Track [Page 3] RFC 2837 FC Fabric Element MIB May 2000 2.1. Management View of a Fabric Element From the management perspective, it is helpful to view a Fabric Element to be consisting of multiple "modules". Each module is a grouping, either physical or logical, of one or more ports that may be managed as a sub-entity within the Fabric Element. This module mapping is recommended but optional. A vendor may elect to put all ports into a single module, or to divide the ports into modules that do not match physical divisions. The object fcFeModuleCapacity indicates the maximum number of modules that a given Fabric Element may contain. This value must remain constant from one management restart to the next. Each module is uniquely identified by a module number in the range of 1 through fcFeModuleCapacity inclusive. Modules may come and go without causing a management reset (of sysUpTime), and may be sparsely numbered within the Fabric Element. That is, the module numbering is not required to be contiguous. For instance, if a module is mapped physically to a field-replaceable card and in a 13- card cage Fabric Element, cards 3, 5, 6 and 7 may be installed. The vendor may choose to label them as modules 3, 5, 6 and 7 respectively. In this example, the value of fcFeModuleCapacity is 13. Note that the object fcFeModuleLastChange acts as the discontinuity indicator for all counter objects in this MIB. A Fabric Element may also provide a proxy management on behalf of another management entity by presenting it as one of its Fabric Element modules. The object fcFeModuleFxPortCapacity indicates the maximum number of ports that a given module may contain. The value of fcFeModuleFxPortCapacity must not change for a given module. However, a module may be deleted from the Fabric Element and replaced with a module containing a different number of ports. The value of fcFeModuleLastChange will indicate that a change took place. Each port within the Fabric Element is uniquely identified by a combination of module index and port index, where port index is an integer in the range (1..fcFeModuleFxPortCapacity). As with modules within a Fabric Element, ports within a module may be sparsely numbered. That is the port numbering is not required to be contiguous. Likewise, ports may come and go within a module without causing a management reset. Teow Standards Track [Page 4] RFC 2837 FC Fabric Element MIB May 2000 In terms of attachment, an F_Port will be attached to another N_Port; and an FL_Port will be attached to one or up to 126 NL_Ports. In general, an FxPort may be attached to one or more NxPorts. Each NxPort associated with an FxPort will be uniquely identified by a combination of module index, FxPort index and NxPort index. An NxPort index is an integer in the range (1..126). The following diagram illustrates the management view of a Fabric Element. #=======================================================# # +----------------- - - - -----------------+ # # | Module 1 [1] . . . [i] | # # +----------------- - - - -----------------+ # # o o o # # +---------------------- - - - --------+ # # | Module M [1] . . . [n] | # # +---------------------- - - - -----^--+ # #=====================================|=================# | One or more NxPorts { [1] . . . [L] }<-+ - - - - - - - - - where "i", "n", "M" and "L" are some arbitrary sample integer values, and "L" must be less than 127. 2.2. Structure of the Fabric Element MIB This memo assumes that a Fabric Element has an SNMP entity associated with its managed objects. The managed objects are divided as follow: - the Configuration group - the Status group - the Error group - the Accounting group - the Capability group In each group, scalar objects and table entries are defined. The Configuration group contains configuration and service parameters for the Fabric Element, modules and the FxPorts. The Operation group contains the operational status and parameters of an FxPort. The group also contains the service parameters that have been established between the FxPort and its attached NxPort, if applicable. The Error group contains counters tracking various types of errors detected by each FxPort. The information may be used for diagnostics and/or to derive the quality of the link between an FxPort and one or more attached NxPorts. Teow Standards Track [Page 5] RFC 2837 FC Fabric Element MIB May 2000 The Accounting group contains statistic data suitable for deriving accounting and performance information. The Capability group contains parameters indicating the inherent capability of the Fabric Element and each FxPort. 3. Object Definitions FIBRE-CHANNEL-FE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, Gauge32, Integer32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, TimeStamp FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- rfc2571 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; fcFeMIB MODULE-IDENTITY LAST-UPDATED "200005180000Z" ORGANIZATION "IETF IPFC Working Group" CONTACT-INFO "Kha Sin Teow Brocade Communications Systems, 1901 Guadalupe Parkway, San Jose, CA 95131 U.S.A Tel: +1 408 487 8180 Fax: +1 408 487 8190 Email: khasin@Brocade.COM WG Mailing list:ipfc@standards.gadzoox.com To Subscribe: ipfc-request@standards.gadzoox.com In Body: subscribe" DESCRIPTION "The MIB module for Fibre Channel Fabric Element." REVISION "200005180000Z" DESCRIPTION "Initial revision, published as RFC 2837." ::= { mib-2 75 } fcFeMIBObjects OBJECT IDENTIFIER ::= { fcFeMIB 1 } -- Note: -- fcFeMIBConformance OBJECT IDENTIFIER ::= { fcFeMIB 2 } -- see at the end of the module -- Groups under fcFeMIBObjects Teow Standards Track [Page 6] RFC 2837 FC Fabric Element MIB May 2000 fcFeConfig OBJECT IDENTIFIER ::= { fcFeMIBObjects 1 } fcFeStatus OBJECT IDENTIFIER ::= { fcFeMIBObjects 2 } fcFeError OBJECT IDENTIFIER ::= { fcFeMIBObjects 3 } fcFeAccounting OBJECT IDENTIFIER ::= { fcFeMIBObjects 4 } fcFeCapabilities OBJECT IDENTIFIER ::= { fcFeMIBObjects 5 } -- Textual Conventions MilliSeconds ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents time unit value in milliseconds." SYNTAX Unsigned32 MicroSeconds ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents time unit value in microseconds." SYNTAX Unsigned32 FcNameId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the Worldwide Name associated with a Fibre Channel (FC) entity." SYNTAX OCTET STRING (SIZE (8)) FcAddressId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric." SYNTAX OCTET STRING (SIZE (3)) FcRxDataFieldSize ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the receive data field size of an NxPort or FxPort." SYNTAX Integer32 (128..2112) FcBbCredit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the buffer-to-buffer credit of an NxPort or FxPort." SYNTAX Integer32 (0..32767) FcphVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the version of FC-PH supported by an NxPort or FxPort." SYNTAX Integer32 (0..255) FcStackedConnMode ::= TEXTUAL-CONVENTION Teow Standards Track [Page 7] RFC 2837 FC Fabric Element MIB May 2000 STATUS current DESCRIPTION "Represents an enumerated value used to indicate the Class 1 Stacked Connect Mode supported by an NxPort or FxPort." SYNTAX INTEGER { none(1), transparent(2), lockedDown(3) } FcCosCap ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the class of service capability of an NxPort or FxPort." SYNTAX BITS { classF(0), class1(1), class2(2), class3(3), class4(4), class5(5), class6(6) } FcFeModuleCapacity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the maximum number of modules within a Fabric Element." SYNTAX Unsigned32 FcFeFxPortCapacity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the maximum number of FxPorts within a module." SYNTAX Unsigned32 FcFeModuleIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the module index within a conceptual table." SYNTAX Unsigned32 FcFeFxPortIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the FxPort index within a conceptual table." SYNTAX Unsigned32 FcFeNxPortIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the NxPort index within a conceptual table." SYNTAX Integer32 (1..126) FcBbCreditModel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the BB_Credit model of an FxPort." SYNTAX INTEGER { regular(1), alternate (2) } Teow Standards Track [Page 8] RFC 2837 FC Fabric Element MIB May 2000 -- The Configuration group -- This group consists of scalar objects and tables. -- It contains the configuration and service parameters -- of the Fabric Element and the FxPorts. -- The group represents a set of parameters associated with -- the Fabric Element or an FxPort to support its NxPorts. fcFeFabricName OBJECT-TYPE SYNTAX FcNameId MAX-ACCESS read-write STATUS current DESCRIPTION "The Name_Identifier of the Fabric to which this Fabric Element belongs." ::= { fcFeConfig 1 } fcFeElementName OBJECT-TYPE SYNTAX FcNameId MAX-ACCESS read-write STATUS current DESCRIPTION "The Name_Identifier of the Fabric Element." ::= { fcFeConfig 2 } fcFeModuleCapacity OBJECT-TYPE SYNTAX FcFeModuleCapacity MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of modules in the Fabric Element, regardless of their current state." ::= { fcFeConfig 3 } -- The Module Table. -- This table contains one entry for each module, -- information of the modules. fcFeModuleTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFeModuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each module in the Fabric Element, information of the modules." ::= { fcFeConfig 4 } fcFeModuleEntry OBJECT-TYPE Teow Standards Track [Page 9] RFC 2837 FC Fabric Element MIB May 2000 SYNTAX FcFeModuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the configuration parameters of a module." INDEX { fcFeModuleIndex } ::= { fcFeModuleTable 1 } FcFeModuleEntry ::= SEQUENCE { fcFeModuleIndex FcFeModuleIndex, fcFeModuleDescr SnmpAdminString, fcFeModuleObjectID OBJECT IDENTIFIER, fcFeModuleOperStatus INTEGER, fcFeModuleLastChange TimeStamp, fcFeModuleFxPortCapacity FcFeFxPortCapacity, fcFeModuleName FcNameId } fcFeModuleIndex OBJECT-TYPE SYNTAX FcFeModuleIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the module within the Fabric Element for which this entry contains information. This value is never greater than fcFeModuleCapacity." ::= { fcFeModuleEntry 1 } fcFeModuleDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the module. This value should include the full name and version identification of the module." ::= { fcFeModuleEntry 2 } Teow Standards Track [Page 10] RFC 2837 FC Fabric Element MIB May 2000 fcFeModuleObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor's authoritative identification of the module. This value may be allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides a straight-forward and unambiguous means for determining what kind of module is being managed. For example, this object could take the value 1.3.6.1.4.1.99649.3.9 if vendor 'Neufe Inc.' was assigned the subtree 1.3.6.1.4.1.99649, and had assigned the identifier 1.3.6.1.4.1.99649.3.9 to its 'FeFiFo-16 PlugInCard.'" ::= { fcFeModuleEntry 3 } fcFeModuleOperStatus OBJECT-TYPE SYNTAX INTEGER { online (1), -- functional offline (2), -- not available testing (3), -- under testing faulty (4) -- defective } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the operational status of the module: online(1) the module is functioning properly; offline(2) the module is not available; testing(3) the module is under testing; and faulty(4) the module is defective in some way." ::= { fcFeModuleEntry 4 } fcFeModuleLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of sysUpTime when the module entered its current operational status. A value of zero indicates that the operational status of the module has not changed since the agent last restarted." ::= { fcFeModuleEntry 5 } fcFeModuleFxPortCapacity OBJECT-TYPE SYNTAX FcFeFxPortCapacity Teow Standards Track [Page 11] RFC 2837 FC Fabric Element MIB May 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FxPort that can be contained within the module. Within each module, the ports are uniquely numbered in the range from 1 to fcFeModuleFxPortCapacity inclusive. However, the numbers are not required to be contiguous." ::= { fcFeModuleEntry 6 } fcFeModuleName OBJECT-TYPE SYNTAX FcNameId MAX-ACCESS read-write STATUS current DESCRIPTION "The Name_Identifier of the module." ::= { fcFeModuleEntry 7 } -- the FxPort Configuration Table. -- This table contains, one entry for each FxPort, -- configuration parameters of the ports. fcFxPortTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort in the Fabric Element, configuration and service parameters of the FxPorts." ::= { fcFeConfig 5 } fcFxPortEntry OBJECT-TYPE SYNTAX FcFxPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the configuration and service parameters of a FxPort." INDEX { fcFeModuleIndex, fcFxPortIndex } ::= { fcFxPortTable 1 } FcFxPortEntry ::= SEQUENCE { fcFxPortIndex FcFeFxPortIndex, fcFxPortName FcNameId, Teow Standards Track [Page 12] RFC 2837 FC Fabric Element MIB May 2000 -- FxPort common service parameters fcFxPortFcphVersionHigh FcphVersion, fcFxPortFcphVersionLow FcphVersion, fcFxPortBbCredit FcBbCredit, fcFxPortRxBufSize FcRxDataFieldSize, fcFxPortRatov MilliSeconds, fcFxPortEdtov MilliSeconds, -- FxPort class service parameters fcFxPortCosSupported FcCosCap, fcFxPortIntermixSupported TruthValue, fcFxPortStackedConnMode FcStackedConnMode, fcFxPortClass2SeqDeliv TruthValue, fcFxPortClass3SeqDeliv TruthValue, -- other configuration parameters fcFxPortHoldTime MicroSeconds } fcFxPortIndex OBJECT-TYPE SYNTAX FcFeFxPortIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the FxPort within the module. This number ranges from 1 to the value of fcFeModulePortCapacity for the associated module. The value remains constant for the identified FxPort until the module is re-initialized." ::= { fcFxPortEntry 1 } fcFxPortName OBJECT-TYPE SYNTAX FcNameId MAX-ACCESS read-only STATUS current DESCRIPTION "The World_wide Name of this FxPort. Each FxPort has a unique Port World_wide Name within the Fabric." ::= { fcFxPortEntry 2 } Teow Standards Track [Page 13] RFC 2837 FC Fabric Element MIB May 2000 -- FxPort common service parameters fcFxPortFcphVersionHigh OBJECT-TYPE SYNTAX FcphVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The highest or most recent version of FC-PH that the FxPort is configured to support." ::= { fcFxPortEntry 3 } fcFxPortFcphVersionLow OBJECT-TYPE SYNTAX FcphVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest or earliest version of FC-PH that the FxPort is configured to support." ::= { fcFxPortEntry 4 } fcFxPortBbCredit OBJECT-TYPE SYNTAX FcBbCredit UNITS "buffers" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of receive buffers available for holding Class 1 connect-request, Class 2 or 3 frames from the attached NxPort. It is for buffer-to-buffer flow control in the direction from the attached NxPort (if applicable) to FxPort." ::= { fcFxPortEntry 5 } fcFxPortRxBufSize OBJECT-TYPE SYNTAX FcRxDataFieldSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The largest Data_Field Size (in octets) for an FT_1 frame that can be received by the FxPort." ::= { fcFxPortEntry 6 } fcFxPortRatov OBJECT-TYPE SYNTAX MilliSeconds UNITS "milliseconds" MAX-ACCESS read-only STATUS current Teow Standards Track [Page 14] RFC 2837 FC Fabric Element MIB May 2000 DESCRIPTION "The Resource_Allocation_Timeout Value configured for the FxPort. This is used as the timeout value for determining when to reuse an NxPort resource such as a Recovery_Qualifier. It represents E_D_TOV (see next object) plus twice the maximum time that a frame may be delayed within the Fabric and still be delivered." ::= { fcFxPortEntry 7 } fcFxPortEdtov OBJECT-TYPE SYNTAX MilliSeconds UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The E_D_TOV value configured for the FxPort. The Error_Detect_Timeout Value is used as the timeout value for detecting an error condition." ::= { fcFxPortEntry 8 } -- FxPort class service parameters fcFxPortCosSupported OBJECT-TYPE SYNTAX FcCosCap MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the set of Classes of Service supported by the FxPort." ::= { fcFxPortEntry 9 } fcFxPortIntermixSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether or not the FxPort supports an Intermixed Dedicated Connection." ::= { fcFxPortEntry 10 } fcFxPortStackedConnMode OBJECT-TYPE SYNTAX FcStackedConnMode MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the mode of Stacked Connect supported by the FxPort." Teow Standards Track [Page 15] RFC 2837 FC Fabric Element MIB May 2000 ::= { fcFxPortEntry 11 } fcFxPortClass2SeqDeliv OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether or not Class 2 Sequential Delivery is supported by the FxPort." ::= { fcFxPortEntry 12 } fcFxPortClass3SeqDeliv OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether or not Class 3 Sequential Delivery is supported by the FxPort." ::= { fcFxPortEntry 13 } -- other FxPort parameters fcFxPortHoldTime OBJECT-TYPE SYNTAX MicroSeconds UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum time (in microseconds) that the FxPort shall hold a frame before discarding the frame if it is unable to deliver the frame. The value 0 means that the FxPort does not support this parameter." ::= { fcFxPortEntry 14 } -- the Status group -- This group consists of tables that contains operational -- status and established service parameters for the Fabric -- Element and the attached NxPorts. -- The FxPort Status table -- This table contains, one entry for each FxPort, -- the operational status and parameters of the FxPorts. fcFxPortStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortStatusEntry Teow Standards Track [Page 16] RFC 2837 FC Fabric Element MIB May 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort in the Fabric Element, operational status and parameters of the FxPorts." ::= { fcFeStatus 1 } fcFxPortStatusEntry OBJECT-TYPE SYNTAX FcFxPortStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing operational status and parameters of a FxPort." AUGMENTS { fcFxPortEntry } ::= { fcFxPortStatusTable 1 } FcFxPortStatusEntry ::= SEQUENCE { fcFxPortID FcAddressId, fcFxPortBbCreditAvailable Gauge32, fcFxPortOperMode INTEGER, fcFxPortAdminMode INTEGER } fcFxPortID OBJECT-TYPE SYNTAX FcAddressId MAX-ACCESS read-only STATUS current DESCRIPTION "The address identifier by which this FxPort is identified within the Fabric. The FxPort may assign its address identifier to its attached NxPort(s) during Fabric Login." ::= { fcFxPortStatusEntry 1 } fcFxPortBbCreditAvailable OBJECT-TYPE SYNTAX Gauge32 UNITS "buffers" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of buffers currently available for receiving Teow Standards Track [Page 17] RFC 2837 FC Fabric Element MIB May 2000 frames from the attached port in the buffer-to-buffer flow control. The value should be less than or equal to fcFxPortBbCredit." ::= { fcFxPortStatusEntry 2 } fcFxPortOperMode OBJECT-TYPE SYNTAX INTEGER { unknown(1), fPort(2), flPort(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational mode of the FxPort." ::= { fcFxPortStatusEntry 3 } fcFxPortAdminMode OBJECT-TYPE SYNTAX INTEGER { fPort(2), flPort(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired operational mode of the FxPort." ::= { fcFxPortStatusEntry 4 } -- the FxPort Physical Level table -- This table contains, one entry for each FxPort in the -- Fabric Element, the physical level status and parameters -- of the FxPorts. fcFxPortPhysTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort in the Fabric Element, physical level status and parameters of the FxPorts." ::= { fcFeStatus 2 } fcFxPortPhysEntry OBJECT-TYPE SYNTAX FcFxPortPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing physical level status and parameters of a FxPort." AUGMENTS { fcFxPortEntry } ::= { fcFxPortPhysTable 1 } FcFxPortPhysEntry ::= Teow Standards Track [Page 18] RFC 2837 FC Fabric Element MIB May 2000 SEQUENCE { fcFxPortPhysAdminStatus INTEGER, fcFxPortPhysOperStatus INTEGER, fcFxPortPhysLastChange TimeStamp, fcFxPortPhysRttov MilliSeconds } fcFxPortPhysAdminStatus OBJECT-TYPE SYNTAX INTEGER { online (1), -- place port online offline (2), -- take port offline testing (3) -- initiate test procedures } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired state of the FxPort. A management station may place the FxPort in a desired state by setting this object accordingly. The testing(3) state indicates that no operational frames can be passed. When a Fabric Element initializes, all FxPorts start with fcFxPortPhysAdminStatus in the offline(2) state. As the result of either explicit management action or per configuration information accessible by the Fabric Element, fcFxPortPhysAdminStatus is then changed to either the online(1) or testing(3) states, or remains in the offline state." ::= { fcFxPortPhysEntry 1 } fcFxPortPhysOperStatus OBJECT-TYPE SYNTAX INTEGER { online (1), -- Login may proceed offline (2), -- Login cannot proceed testing (3), -- port is under test linkFailure (4) -- failure after online/testing } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the FxPort. The testing(3) indicates that no operational frames can be passed. If fcFxPortPhysAdminStatus is offline(2) then fcFxPortPhysOperStatus should be offline(2). If fcFxPortPhysAdminStatus is changed to online(1) then fcFxPortPhysOperStatus should change to online(1) if the Teow Standards Track [Page 19] RFC 2837 FC Fabric Element MIB May 2000 FxPort is ready to accept Fabric Login request from the attached NxPort; it should proceed and remain in the link- failure(4) state if and only if there is a fault that prevents it from going to the online(1) state." ::= { fcFxPortPhysEntry 2 } fcFxPortPhysLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the FxPort entered its current operational status. A value of zero indicates that the FxPort's operational status has not changed since the agent last restarted." ::= { fcFxPortPhysEntry 3 } fcFxPortPhysRttov OBJECT-TYPE SYNTAX MilliSeconds UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The Receiver_Transmitter_Timeout value of the FxPort. This is used by the receiver logic to detect Loss of Synchronization." ::= { fcFxPortPhysEntry 4 } -- The FxPort Fabric Login table -- -- This table contains, one entry for each FxPort in the -- Fabric Element, the Service Parameters that have been -- established from the most recent Fabric Login, -- implicit or explicit. fcFxLoginTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxLoginEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each NxPort attached to a particular FxPort in the Fabric Element, services parameters established from the most recent Fabric Login, explicit or implicit. Note that an FxPort may have one or more NxPort attached to it." ::= { fcFeStatus 3 } Teow Standards Track [Page 20] RFC 2837 FC Fabric Element MIB May 2000 fcFxLoginEntry OBJECT-TYPE SYNTAX FcFxLoginEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing service parameters established from a successful Fabric Login." INDEX { fcFeModuleIndex, fcFxPortIndex, fcFxPortNxLoginIndex } ::= { fcFxLoginTable 1 } FcFxLoginEntry ::= SEQUENCE { fcFxPortNxLoginIndex FcFeNxPortIndex, fcFxPortFcphVersionAgreed FcphVersion, fcFxPortNxPortBbCredit FcBbCredit, fcFxPortNxPortRxDataFieldSize FcRxDataFieldSize, fcFxPortCosSuppAgreed FcCosCap, fcFxPortIntermixSuppAgreed TruthValue, fcFxPortStackedConnModeAgreed FcStackedConnMode, fcFxPortClass2SeqDelivAgreed TruthValue, fcFxPortClass3SeqDelivAgreed TruthValue, -- fcFxPortNxPortName FcNameId, fcFxPortConnectedNxPort FcAddressId, fcFxPortBbCreditModel FcBbCreditModel } fcFxPortNxLoginIndex OBJECT-TYPE SYNTAX FcFeNxPortIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The object identifies the associated NxPort in the attachment for which the entry contains information." ::= { fcFxLoginEntry 1 } Teow Standards Track [Page 21] RFC 2837 FC Fabric Element MIB May 2000 fcFxPortFcphVersionAgreed OBJECT-TYPE SYNTAX FcphVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The version of FC-PH that the FxPort has agreed to support from the Fabric Login" ::= { fcFxLoginEntry 2 } fcFxPortNxPortBbCredit OBJECT-TYPE SYNTAX FcBbCredit UNITS "buffers" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of buffers available for holding Class 1 connect-request, Class 2 or Class 3 frames to be transmitted to the attached NxPort. It is for buffer-to- buffer flow control in the direction from FxPort to NxPort. The buffer-to-buffer flow control mechanism is indicated in the respective fcFxPortBbCreditModel." ::= { fcFxLoginEntry 3 } fcFxPortNxPortRxDataFieldSize OBJECT-TYPE SYNTAX FcRxDataFieldSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The Receive Data Field Size of the attached NxPort. This object specifies the largest Data Field Size for an FT_1 frame that can be received by the NxPort." ::= { fcFxLoginEntry 4 } fcFxPortCosSuppAgreed OBJECT-TYPE SYNTAX FcCosCap MAX-ACCESS read-only STATUS current DESCRIPTION "A variable indicating that the attached NxPort has requested the FxPort for the support of classes of services and the FxPort has granted the request." ::= { fcFxLoginEntry 5 } fcFxPortIntermixSuppAgreed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current Teow Standards Track [Page 22] RFC 2837 FC Fabric Element MIB May 2000 DESCRIPTION "A variable indicating that the attached NxPort has requested the FxPort for the support of Intermix and the FxPort has granted the request. This flag is only valid if Class 1 service is supported." ::= { fcFxLoginEntry 6 } fcFxPortStackedConnModeAgreed OBJECT-TYPE SYNTAX FcStackedConnMode MAX-ACCESS read-only STATUS current DESCRIPTION "A variable indicating whether the FxPort has agreed to support stacked connect from the Fabric Login. This is only meaningful if Class 1 service has been agreed." ::= { fcFxLoginEntry 7 } fcFxPortClass2SeqDelivAgreed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A variable indicating whether the FxPort has agreed to support Class 2 sequential delivery from the Fabric Login. This is only meaningful if Class 2 service has been agreed." ::= { fcFxLoginEntry 8 } fcFxPortClass3SeqDelivAgreed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether the FxPort has agreed to support Class 3 sequential delivery from the Fabric Login. This is only meaningful if Class 3 service has been agreed." ::= { fcFxLoginEntry 9 } fcFxPortNxPortName OBJECT-TYPE SYNTAX FcNameId MAX-ACCESS read-only STATUS current DESCRIPTION "The port name of the attached NxPort." ::= { fcFxLoginEntry 10 } fcFxPortConnectedNxPort OBJECT-TYPE SYNTAX FcAddressId Teow Standards Track [Page 23] RFC 2837 FC Fabric Element MIB May 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The address identifier of the destination NxPort with which this FxPort is currently engaged in a either a Class 1 or loop connection. If this FxPort is not engaged in a connection, then the value of this object is '000000'H." ::= { fcFxLoginEntry 11 } fcFxPortBbCreditModel OBJECT-TYPE SYNTAX FcBbCreditModel MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the BB_Credit model used by the FxPort." ::= { fcFxLoginEntry 12 } -- the Error group -- This group consists of tables that contain information about -- the various types of errors detected. The management station -- may use the information in this group to determine the -- quality of the link between the FxPort and its attached NxPort. -- the FxPort Error table -- This table contains, one entry for each FxPort in the Fabric -- Element, counters recording numbers of errors detected -- since the management agent re-initialized. -- The first 6 columnar objects after the port index corresponds -- to the counters in the Link Error Status Block. fcFxPortErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort, counters that record the numbers of errors detected." ::= { fcFeError 1 } fcFxPortErrorEntry OBJECT-TYPE SYNTAX FcFxPortErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing error counters of a FxPort." AUGMENTS { fcFxPortEntry } Teow Standards Track [Page 24] RFC 2837 FC Fabric Element MIB May 2000 ::= { fcFxPortErrorTable 1 } FcFxPortErrorEntry ::= SEQUENCE { fcFxPortLinkFailures Counter32, fcFxPortSyncLosses Counter32, fcFxPortSigLosses Counter32, fcFxPortPrimSeqProtoErrors Counter32, fcFxPortInvalidTxWords Counter32, fcFxPortInvalidCrcs Counter32, fcFxPortDelimiterErrors Counter32, fcFxPortAddressIdErrors Counter32, fcFxPortLinkResetIns Counter32, fcFxPortLinkResetOuts Counter32, fcFxPortOlsIns Counter32, fcFxPortOlsOuts Counter32 } fcFxPortLinkFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of link failures detected by this FxPort." ::= { fcFxPortErrorEntry 1 } fcFxPortSyncLosses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of loss of synchronization detected by the FxPort." ::= { fcFxPortErrorEntry 2 } Teow Standards Track [Page 25] RFC 2837 FC Fabric Element MIB May 2000 fcFxPortSigLosses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of loss of signal detected by the FxPort." ::= { fcFxPortErrorEntry 3 } fcFxPortPrimSeqProtoErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of primitive sequence protocol errors detected by the FxPort." ::= { fcFxPortErrorEntry 4 } fcFxPortInvalidTxWords OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid transmission word detected by the FxPort." ::= { fcFxPortErrorEntry 5 } fcFxPortInvalidCrcs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid CRC detected by this FxPort." ::= { fcFxPortErrorEntry 6 } fcFxPortDelimiterErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Delimiter Errors detected by this FxPort." ::= { fcFxPortErrorEntry 7 } fcFxPortAddressIdErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of address identifier errors detected by this Teow Standards Track [Page 26] RFC 2837 FC Fabric Element MIB May 2000 FxPort." ::= { fcFxPortErrorEntry 8 } fcFxPortLinkResetIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Link Reset Protocol received by this FxPort from the attached NxPort." ::= { fcFxPortErrorEntry 9 } fcFxPortLinkResetOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Link Reset Protocol issued by this FxPort to the attached NxPort." ::= { fcFxPortErrorEntry 10 } fcFxPortOlsIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Offline Sequence received by this FxPort." ::= { fcFxPortErrorEntry 11 } fcFxPortOlsOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Offline Sequence issued by this FxPort." ::= { fcFxPortErrorEntry 12 } -- Accounting Groups: -- (1) Class 1 Accounting Group, -- (2) Class 2 Accounting Group, and -- (3) Class 3 Accounting Group. -- Each group consists of a table that contains accounting -- information for the FxPorts in the Fabric Element. -- the Class 1 Accounting table -- This table contains, one entry for each FxPort in the Fabric Teow Standards Track [Page 27] RFC 2837 FC Fabric Element MIB May 2000 -- Element, Counter32s for certain types of events occurred in the -- the FxPorts since the the management agent has re-initialized. fcFxPortC1AccountingTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortC1AccountingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort in the Fabric Element, Class 1 accounting information recorded since the management agent has re-initialized." ::= { fcFeAccounting 1 } fcFxPortC1AccountingEntry OBJECT-TYPE SYNTAX FcFxPortC1AccountingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing Class 1 accounting information for each FxPort." AUGMENTS { fcFxPortEntry } ::= { fcFxPortC1AccountingTable 1 } FcFxPortC1AccountingEntry ::= SEQUENCE { fcFxPortC1InFrames Counter32, fcFxPortC1OutFrames Counter32, fcFxPortC1InOctets Counter32, fcFxPortC1OutOctets Counter32, fcFxPortC1Discards Counter32, fcFxPortC1FbsyFrames Counter32, fcFxPortC1FrjtFrames Counter32, fcFxPortC1InConnections Counter32, fcFxPortC1OutConnections Counter32, fcFxPortC1ConnTime MilliSeconds } Teow Standards Track [Page 28] RFC 2837 FC Fabric Element MIB May 2000 fcFxPortC1InFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 1 frames (other than Class 1 connect- request) received by this FxPort from its attached NxPort." ::= { fcFxPortC1AccountingEntry 1 } fcFxPortC1OutFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 1 frames (other than Class 1 connect- request) delivered through this FxPort to its attached NxPort." ::= { fcFxPortC1AccountingEntry 2 } fcFxPortC1InOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 1 frame octets, including the frame delimiters, received by this FxPort from its attached NxPort." ::= { fcFxPortC1AccountingEntry 3 } fcFxPortC1OutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 1 frame octets, including the frame delimiters, delivered through this FxPort its attached NxPort." ::= { fcFxPortC1AccountingEntry 4 } fcFxPortC1Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 1 frames discarded by this FxPort." ::= { fcFxPortC1AccountingEntry 5 } fcFxPortC1FbsyFrames OBJECT-TYPE Teow Standards Track [Page 29] RFC 2837 FC Fabric Element MIB May 2000 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of F_BSY frames generated by this FxPort against Class 1 connect-request." ::= { fcFxPortC1AccountingEntry 6 } fcFxPortC1FrjtFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of F_RJT frames generated by this FxPort against Class 1 connect-request." ::= { fcFxPortC1AccountingEntry 7 } fcFxPortC1InConnections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 1 connections successfully established in which the attached NxPort is the source of the connect- request." ::= { fcFxPortC1AccountingEntry 8 } fcFxPortC1OutConnections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 1 connections successfully established in which the attached NxPort is the destination of the connect-request." ::= { fcFxPortC1AccountingEntry 9 } fcFxPortC1ConnTime OBJECT-TYPE SYNTAX MilliSeconds UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The cumulative time that this FxPort has been engaged in Class 1 connection. The amount of time is counted from after a connect-request has been accepted until the connection is disengaged, either by an EOFdt or Link Reset." Teow Standards Track [Page 30] RFC 2837 FC Fabric Element MIB May 2000 ::= { fcFxPortC1AccountingEntry 10 } -- the Class 2 Accounting table -- This table contains, one entry for each FxPort in the Fabric -- Element, Counter32s for certain types of events occurred in the -- the FxPorts since the the management agent has re-initialized. fcFxPortC2AccountingTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortC2AccountingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort in the Fabric Element, Class 2 accounting information recorded since the management agent has re-initialized." ::= { fcFeAccounting 2 } fcFxPortC2AccountingEntry OBJECT-TYPE SYNTAX FcFxPortC2AccountingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing Class 2 accounting information for each FxPort." AUGMENTS { fcFxPortEntry } ::= { fcFxPortC2AccountingTable 1 } FcFxPortC2AccountingEntry ::= SEQUENCE { fcFxPortC2InFrames Counter32, fcFxPortC2OutFrames Counter32, fcFxPortC2InOctets Counter32, fcFxPortC2OutOctets Counter32, fcFxPortC2Discards Counter32, fcFxPortC2FbsyFrames Counter32, fcFxPortC2FrjtFrames Counter32 } fcFxPortC2InFrames OBJECT-TYPE Teow Standards Track [Page 31] RFC 2837 FC Fabric Element MIB May 2000 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames received by this FxPort from its attached NxPort." ::= { fcFxPortC2AccountingEntry 1 } fcFxPortC2OutFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames delivered through this FxPort to its attached NxPort." ::= { fcFxPortC2AccountingEntry 2 } fcFxPortC2InOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frame octets, including the frame delimiters, received by this FxPort from its attached NxPort." ::= { fcFxPortC2AccountingEntry 3 } fcFxPortC2OutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frame octets, including the frame delimiters, delivered through this FxPort to its attached NxPort." ::= { fcFxPortC2AccountingEntry 4 } fcFxPortC2Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames discarded by this FxPort." ::= { fcFxPortC2AccountingEntry 5 } fcFxPortC2FbsyFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Teow Standards Track [Page 32] RFC 2837 FC Fabric Element MIB May 2000 STATUS current DESCRIPTION "The number of F_BSY frames generated by this FxPort against Class 2 frames." ::= { fcFxPortC2AccountingEntry 6 } fcFxPortC2FrjtFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of F_RJT frames generated by this FxPort against Class 2 frames." ::= { fcFxPortC2AccountingEntry 7 } -- the Class 3 Accounting Group -- This table contains, one entry for each FxPort in the Fabric -- Element, Counter32s for certain types of events occurred in the -- the FxPorts since the management agent has re-initialized. fcFxPortC3AccountingTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortC3AccountingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort in the Fabric Element, Class 3 accounting information recorded since the management agent has re-initialized." ::= { fcFeAccounting 3 } fcFxPortC3AccountingEntry OBJECT-TYPE SYNTAX FcFxPortC3AccountingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing Class 3 accounting information for each FxPort." AUGMENTS { fcFxPortEntry } ::= { fcFxPortC3AccountingTable 1 } FcFxPortC3AccountingEntry ::= SEQUENCE { fcFxPortC3InFrames Counter32, fcFxPortC3OutFrames Counter32, fcFxPortC3InOctets Teow Standards Track [Page 33] RFC 2837 FC Fabric Element MIB May 2000 Counter32, fcFxPortC3OutOctets Counter32, fcFxPortC3Discards Counter32 } fcFxPortC3InFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames received by this FxPort from its attached NxPort." ::= { fcFxPortC3AccountingEntry 1 } fcFxPortC3OutFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames delivered through this FxPort to its attached NxPort." ::= { fcFxPortC3AccountingEntry 2 } fcFxPortC3InOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frame octets, including the frame delimiters, received by this FxPort from its attached NxPort." ::= { fcFxPortC3AccountingEntry 3 } fcFxPortC3OutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frame octets, including the frame delimiters, delivered through this FxPort to its attached NxPort." ::= { fcFxPortC3AccountingEntry 4 } fcFxPortC3Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Teow Standards Track [Page 34] RFC 2837 FC Fabric Element MIB May 2000 STATUS current DESCRIPTION "The number of Class 3 frames discarded by this FxPort." ::= { fcFxPortC3AccountingEntry 5 } -- The Capability Group - consists of a table describing -- information about what each FxPort is inherently capable -- of operating or supporting. -- A capability may be used, as expressed in its respective -- object value in the Configuration group. fcFxPortCapTable OBJECT-TYPE SYNTAX SEQUENCE OF FcFxPortCapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains, one entry for each FxPort, the capabilities of the port within the Fabric Element." ::= { fcFeCapabilities 1 } fcFxPortCapEntry OBJECT-TYPE SYNTAX FcFxPortCapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the Cap of a FxPort." AUGMENTS { fcFxPortEntry } ::= { fcFxPortCapTable 1 } FcFxPortCapEntry ::= SEQUENCE { fcFxPortCapFcphVersionHigh FcphVersion, fcFxPortCapFcphVersionLow FcphVersion, fcFxPortCapBbCreditMax FcBbCredit, fcFxPortCapBbCreditMin FcBbCredit, fcFxPortCapRxDataFieldSizeMax FcRxDataFieldSize, fcFxPortCapRxDataFieldSizeMin FcRxDataFieldSize, fcFxPortCapCos FcCosCap, fcFxPortCapIntermix Teow Standards Track [Page 35] RFC 2837 FC Fabric Element MIB May 2000 TruthValue, fcFxPortCapStackedConnMode FcStackedConnMode, fcFxPortCapClass2SeqDeliv TruthValue, fcFxPortCapClass3SeqDeliv TruthValue, fcFxPortCapHoldTimeMax MicroSeconds, fcFxPortCapHoldTimeMin MicroSeconds } fcFxPortCapFcphVersionHigh OBJECT-TYPE SYNTAX FcphVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The highest or most recent version of FC-PH that the FxPort is capable of supporting." ::= { fcFxPortCapEntry 1 } fcFxPortCapFcphVersionLow OBJECT-TYPE SYNTAX FcphVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest or earliest version of FC-PH that the FxPort is capable of supporting." ::= { fcFxPortCapEntry 2 } fcFxPortCapBbCreditMax OBJECT-TYPE SYNTAX FcBbCredit UNITS "buffers" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of receive buffers available for holding Class 1 connect-request, Class 2 or Class 3 frames from the attached NxPort." ::= { fcFxPortCapEntry 3 } fcFxPortCapBbCreditMin OBJECT-TYPE SYNTAX FcBbCredit UNITS "buffers" MAX-ACCESS read-only STATUS current DESCRIPTION Teow Standards Track [Page 36] RFC 2837 FC Fabric Element MIB May 2000 "The minimum number of receive buffers available for holding Class 1 connect-request, Class 2 or Class 3 frames from the attached NxPort." ::= { fcFxPortCapEntry 4 } fcFxPortCapRxDataFieldSizeMax OBJECT-TYPE SYNTAX FcRxDataFieldSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum size in bytes of the Data Field in a frame that the FxPort is capable of receiving from its attached NxPort." ::= { fcFxPortCapEntry 5 } fcFxPortCapRxDataFieldSizeMin OBJECT-TYPE SYNTAX FcRxDataFieldSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum size in bytes of the Data Field in a frame that the FxPort is capable of receiving from its attached NxPort." ::= { fcFxPortCapEntry 6 } fcFxPortCapCos OBJECT-TYPE SYNTAX FcCosCap MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the set of Classes of Service that the FxPort is capable of supporting." ::= { fcFxPortCapEntry 7 } fcFxPortCapIntermix OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether or not the FxPort is capable of supporting the intermixing of Class 2 and Class 3 frames during a Class 1 connection. This flag is only valid if the port is capable of supporting Class 1 service." ::= { fcFxPortCapEntry 8 } fcFxPortCapStackedConnMode OBJECT-TYPE Teow Standards Track [Page 37] RFC 2837 FC Fabric Element MIB May 2000 SYNTAX FcStackedConnMode MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the mode of Stacked Connect request that the FxPort is capable of supporting." ::= { fcFxPortCapEntry 9 } fcFxPortCapClass2SeqDeliv OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether or not the FxPort is capable of supporting Class 2 Sequential Delivery." ::= { fcFxPortCapEntry 10 } fcFxPortCapClass3SeqDeliv OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag indicating whether or not the FxPort is capable of supporting Class 3 Sequential Delivery." ::= { fcFxPortCapEntry 11 } fcFxPortCapHoldTimeMax OBJECT-TYPE SYNTAX MicroSeconds UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum holding time (in microseconds) that the FxPort is capable of supporting." ::= { fcFxPortCapEntry 12 } fcFxPortCapHoldTimeMin OBJECT-TYPE SYNTAX MicroSeconds UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum holding time (in microseconds) that the FxPort is capable of supporting." ::= { fcFxPortCapEntry 13 } -- conformance information Teow Standards Track [Page 38] RFC 2837 FC Fabric Element MIB May 2000 fcFeMIBConformance OBJECT IDENTIFIER ::= { fcFeMIB 2 } fcFeMIBCompliances OBJECT IDENTIFIER ::= { fcFeMIBConformance 1 } fcFeMIBGroups OBJECT IDENTIFIER ::= { fcFeMIBConformance 2 } -- compliance statements fcFeMIBMinimumCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The minimum compliance statement for SNMP entities which implement the FIBRE-CHANNEL-FE-MIB." MODULE -- this module MANDATORY-GROUPS { fcFeConfigGroup, fcFeStatusGroup, fcFeErrorGroup } OBJECT fcFeFabricName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFeElementName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFeModuleName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFxPortAdminMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFxPortPhysAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFxPortPhysRttov MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFxPortBbCreditModel MIN-ACCESS read-only DESCRIPTION "Write access is not required." Teow Standards Track [Page 39] RFC 2837 FC Fabric Element MIB May 2000 ::= { fcFeMIBCompliances 1 } fcFeMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The full compliance statement for SNMP entities which implement the FIBRE-CHANNEL-FE-MIB." MODULE -- this module MANDATORY-GROUPS { fcFeConfigGroup, fcFeStatusGroup, fcFeErrorGroup, fcFeCapabilitiesGroup } GROUP fcFeClass1AccountingGroup DESCRIPTION "This group is mandatory for all fibre channel fabric elements which support class 1 frames." GROUP fcFeClass2AccountingGroup DESCRIPTION "This group is mandatory for all fibre channel fabric elements which support class 2 frames." GROUP fcFeClass3AccountingGroup DESCRIPTION "This group is mandatory for all fibre channel fabric elements which support class 3 frames." OBJECT fcFeFabricName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFeElementName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFeModuleName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFxPortAdminMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFxPortPhysAdminStatus MIN-ACCESS read-only Teow Standards Track [Page 40] RFC 2837 FC Fabric Element MIB May 2000 DESCRIPTION "Write access is not required." OBJECT fcFxPortPhysRttov MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcFxPortBbCreditModel MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { fcFeMIBCompliances 2 } -- units of conformance fcFeConfigGroup OBJECT-GROUP OBJECTS { fcFeFabricName, fcFeElementName, fcFeModuleCapacity, fcFeModuleDescr, fcFeModuleObjectID, fcFeModuleOperStatus, fcFeModuleLastChange, fcFeModuleFxPortCapacity, fcFeModuleName, fcFxPortName, fcFxPortFcphVersionHigh, fcFxPortFcphVersionLow, fcFxPortBbCredit, fcFxPortRxBufSize, fcFxPortRatov, fcFxPortEdtov, fcFxPortCosSupported, fcFxPortIntermixSupported, fcFxPortStackedConnMode, fcFxPortClass2SeqDeliv, fcFxPortClass3SeqDeliv, fcFxPortHoldTime } STATUS current DESCRIPTION "A collection of objects providing the configuration and service parameters of the Fabric Element, the modules, and FxPorts." ::= { fcFeMIBGroups 1 } fcFeStatusGroup OBJECT-GROUP OBJECTS { fcFxPortID, fcFxPortBbCreditAvailable, fcFxPortOperMode, fcFxPortAdminMode, fcFxPortPhysAdminStatus, fcFxPortPhysOperStatus, fcFxPortPhysLastChange, fcFxPortPhysRttov, fcFxPortFcphVersionAgreed, fcFxPortNxPortBbCredit, fcFxPortNxPortRxDataFieldSize, fcFxPortCosSuppAgreed, fcFxPortIntermixSuppAgreed, fcFxPortStackedConnModeAgreed, fcFxPortClass2SeqDelivAgreed, fcFxPortClass3SeqDelivAgreed, fcFxPortNxPortName, fcFxPortConnectedNxPort, fcFxPortBbCreditModel } STATUS current DESCRIPTION Teow Standards Track [Page 41] RFC 2837 FC Fabric Element MIB May 2000 "A collection of objects providing the operational status and established service parameters for the Fabric Element and the attached NxPorts." ::= { fcFeMIBGroups 2 } fcFeErrorGroup OBJECT-GROUP OBJECTS { fcFxPortLinkFailures, fcFxPortSyncLosses, fcFxPortSigLosses, fcFxPortPrimSeqProtoErrors, fcFxPortInvalidTxWords, fcFxPortInvalidCrcs, fcFxPortDelimiterErrors, fcFxPortAddressIdErrors, fcFxPortLinkResetIns, fcFxPortLinkResetOuts, fcFxPortOlsIns, fcFxPortOlsOuts } STATUS current DESCRIPTION "A collection of objects providing various error statistics detected by the FxPorts." ::= { fcFeMIBGroups 3 } fcFeClass1AccountingGroup OBJECT-GROUP OBJECTS { fcFxPortC1InFrames, fcFxPortC1OutFrames, fcFxPortC1InOctets, fcFxPortC1OutOctets, fcFxPortC1Discards, fcFxPortC1FbsyFrames, fcFxPortC1FrjtFrames, fcFxPortC1InConnections, fcFxPortC1OutConnections, fcFxPortC1ConnTime } STATUS current DESCRIPTION "A collection of objects providing various class 1 performance statistics detected by the FxPorts." ::= { fcFeMIBGroups 4 } fcFeClass2AccountingGroup OBJECT-GROUP OBJECTS { fcFxPortC2InFrames, fcFxPortC2OutFrames, fcFxPortC2InOctets, fcFxPortC2OutOctets, fcFxPortC2Discards, fcFxPortC2FbsyFrames, fcFxPortC2FrjtFrames } STATUS current DESCRIPTION "A collection of objects providing various class 2 performance statistics detected by the FxPorts." ::= { fcFeMIBGroups 5 } fcFeClass3AccountingGroup OBJECT-GROUP OBJECTS { fcFxPortC3InFrames, fcFxPortC3OutFrames, fcFxPortC3InOctets, fcFxPortC3OutOctets, fcFxPortC3Discards } Teow Standards Track [Page 42] RFC 2837 FC Fabric Element MIB May 2000 STATUS current DESCRIPTION "A collection of objects providing various class 3 performance statistics detected by the FxPorts." ::= { fcFeMIBGroups 6 } fcFeCapabilitiesGroup OBJECT-GROUP OBJECTS { fcFxPortCapFcphVersionHigh, fcFxPortCapFcphVersionLow, fcFxPortCapBbCreditMax, fcFxPortCapBbCreditMin, fcFxPortCapRxDataFieldSizeMax, fcFxPortCapRxDataFieldSizeMin, fcFxPortCapCos, fcFxPortCapIntermix, fcFxPortCapStackedConnMode, fcFxPortCapClass2SeqDeliv, fcFxPortCapClass3SeqDeliv, fcFxPortCapHoldTimeMax, fcFxPortCapHoldTimeMin } STATUS current DESCRIPTION "A collection of objects providing the inherent capability of each FxPort within the Fabric Element." ::= { fcFeMIBGroups 7 } END -- End of Object Definitions 4. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. Teow Standards Track [Page 43] RFC 2837 FC Fabric Element MIB May 2000 It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/delete) them. 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements The editors would like to thank the following individuals for their assistance and constructive comments: Juergen Schoenwaelder, Technical University Braunschweig Vincent Guan, Brocade Gavin Bowlby, Gadzoox Bent Stoevhase, Brocade Jeff Meyer, HP John Y. Chu, IBM Yakov Rekhter, Cisco Martin Sachs, IBM Dan Eisenhauer, IBM Beth Vanderbeck, IBM Carl Zeitler, Compaq Paul Griffiths, IBM KC Chennappan, IBM Jessie Haug, IBM Bob Cornelius, ANCOR Lansing Sloan, LLNL Paul Rupert, LLNL Rich Taborak, NSerial Steve Wilson, Brocade Jerry Rouse, IBM Dal Allan, ENDL Hubert Huot, IBM Venkat Rao, HP Amir Artsi, RADWAY International Ltd. Teow Standards Track [Page 44] RFC 2837 FC Fabric Element MIB May 2000 7. References 7.1. IETF References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. Teow Standards Track [Page 45] RFC 2837 FC Fabric Element MIB May 2000 [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. 7.2. Approved ANSI/NCITS References [17] Fibre Channel Physical and Signaling Interface (FC-PH), American National Standard for Information Systems X3.230:1994, Computer and Business Equipment Manufacturers Association, Washington, DC. [18] Fibre Channel Fabric Generic (FC-FG), American National Standard for Information Systems X3.289:1996, Computer and Business Equipment Manufacturers Association, Washington, DC. [19] Fibre Channel Generic Services (FC-GS), American National Standard for Information Systems X3.288:1996, Computer and Business Equipment Manufacturers Association, Washington, DC. [20] Fibre Channel Arbitrated Loop (FC-AL), American National Standard for Information Systems X3.272:1996, Computer and Business Equipment Manufacturers Association, Washington, DC. [21] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2), American National Standard for Information Systems, X3.297:1997, Computer and Business Equipment Manufacturers Association, Washington, DC. [22] Fibre Channel Physical and Signaling Interface-3 (FC-PH-3), American National Standard for Information Systems, X3.303:1998, Computer and Business Equipment Manufacturers Association, Washington, DC. [23] Fibre Channel Switch Fabric (FC-SW), American National Standard for Information Systems, NCITS 321:1998, Computer and Business Equipment Manufacturers Association, Washington, DC. Teow Standards Track [Page 46] RFC 2837 FC Fabric Element MIB May 2000 7.3. ANSI/NCITS References Under Development [24] Fibre Channel Arbitrated Loop-2 (FC-AL-2), American National Standard for Information Systems, X3T11/1133D Rev 5.2, Computer and Business Equipment Manufacturers Association, Washington, DC. 8. Editor's Address Kha Sin Teow Brocade Communications Systems, Inc. 1901 Guadalupe Parkway, San Jose, CA 95131 U.S.A. Phone: +1 408-487-8180 Email: khasin@Brocade.COM Teow Standards Track [Page 47] RFC 2837 FC Fabric Element MIB May 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Teow Standards Track [Page 48] snmp-mibs-downloader-1.1/mibrfcs/rfc2856.txt0000644000000000000000000005073211402176071015575 0ustar Network Working Group A. Bierman Request for Comments: 2856 K. McCloghrie Category: Standards Track Cisco Systems, Inc. R. Presuhn BMC Software, Inc. June 2000 Textual Conventions for Additional High Capacity Data Types 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. The definitions contained in this document represent a short term solution which may be deprecated in the future. Table of Contents 1 The SNMP Management Framework ................................. 2 2 Overview ...................................................... 3 2.1 Short Term and Long Term Objectives ......................... 3 2.2 Limitations of the Textual Convention Approach .............. 3 3 New Textual Conventions ....................................... 4 3.1 CounterBasedGauge64 ......................................... 4 3.2 ZeroBasedCounter64 .......................................... 4 4 Definitions ................................................... 4 5 Intellectual Property ......................................... 7 6 References .................................................... 7 7 Security Considerations ....................................... 9 8 Authors' Addresses ............................................ 9 9 Full Copyright Statement ...................................... 10 Bierman, et al. Standards Track [Page 1] RFC 2856 High Capacity Data Types June 2000 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. The textual conventions defined in this MIB module cannot be translated to SMIv1 since the Counter64 type does not exist in SMIv1. Bierman, et al. Standards Track [Page 2] RFC 2856 High Capacity Data Types June 2000 2. Overview The Structure of Management Information [RFC2578] does not explicitly address the question of how to represent integer objects other than counters that would require up to 64 bits to provide the necessary range and precision. There are MIBs in progress targeted for the standards track, which need such data types. This memo specifies a short term solution, using textual conventions, to meet these needs. 2.1. Short Term and Long Term Objectives There is an immediate need to provide a Gauge64 data type, similar in semantics to the Gauge32 data type, in order to support common data representations such as: - a snapshot of a Counter64 at a given moment, e.g., history ring buffer - the difference between two Counter64 values There is also an immediate need for a 64-bit zero-based counter type, similar in semantics to the ZeroBasedCounter32 TC defined in the RMON-2 MIB [RFC2021]. Both of these textual conventions should use a base type of Gauge64 or Unsigned64, but such a base type is not available. Until such a base type is defined and deployed, these temporary textual conventions (which use a base type of Counter64) will be used in MIBs which require unsigned 64-bit data types. In order to be backward compatible with existing implementations of Counter64, the ASN.1 encoding of unsigned 64-bit data types must be identical to the encoding of Counter64 objects, i.e., identified by the [APPLICATION 6] ASN.1 tag. Note that the textual conventions defined in this document represent a limited and short-term solution to the problem. These textual conventions may be deprecated as a long term solution is defined and deployed to replace them. A MIB object which uses either of these textual conventions may also eventually have to be deprecated. 2.2. Limitations of the Textual Convention Approach New unsigned data types with textual conventions based on the Counter64 tag, instead of a new (or other existing) ASN.1 tag have some limitations: Bierman, et al. Standards Track [Page 3] RFC 2856 High Capacity Data Types June 2000 - The MAX-ACCESS of the TC must be read-only, because the MAX-ACCESS of the underlying Counter64 type is read-only. - No sub-range can be specified on the TC-derived types, because sub-ranges are not allowed on Counter64 objects. - No DEFVAL clause can be specified for the TC-derived types, because DEFVALs are not allowed on Counter64 objects. - The TC-derived types cannot be used in an INDEX clause, because there is no INDEX clause mapping defined for objects of type Counter64. 3. New Textual Conventions The following textual conventions are defined to support unsigned 64-bit data types. 3.1. CounterBasedGauge64 This textual convention defines a 64-bit gauge, but defined with Counter64 syntax, since no Gauge64 or Unsigned64 base type is available in SMIv2. This TC is used for storing the difference between two Counter64 values, or simply storing a snapshot of a Counter64 value at a given moment in time. 3.2. ZeroBasedCounter64 This textual convention defines a 64-bit counter with an initial value of zero, instead of an arbitrary initial value. This TC is used for counter objects in tables which are instantiated by management application action. 4. Definitions HCNUM-TC DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, Counter64 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; hcnumTC MODULE-IDENTITY LAST-UPDATED "200006080000Z" Bierman, et al. Standards Track [Page 4] RFC 2856 High Capacity Data Types June 2000 ORGANIZATION "IETF OPS Area" CONTACT-INFO " E-mail: mibs@ops.ietf.org Subscribe: majordomo@psg.com with msg body: subscribe mibs Andy Bierman Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 USA +1 408-527-3711 abierman@cisco.com Keith McCloghrie Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 USA +1 408-526-5260 kzm@cisco.com Randy Presuhn BMC Software, Inc. Office 1-3141 2141 North First Street San Jose, California 95131 USA +1 408 546-1006 rpresuhn@bmc.com" DESCRIPTION "A MIB module containing textual conventions for high capacity data types. This module addresses an immediate need for data types not directly supported in the SMIv2. This short-term solution is meant to be deprecated as a long-term solution is deployed." REVISION "200006080000Z" DESCRIPTION "Initial Version of the High Capacity Numbers MIB module, published as RFC 2856." ::= { mib-2 78 } CounterBasedGauge64 ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The CounterBasedGauge64 type represents a non-negative integer, which may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum value. The maximum value can not be greater than 2^64-1 (18446744073709551615 decimal), and the minimum value can Bierman, et al. Standards Track [Page 5] RFC 2856 High Capacity Data Types June 2000 not be smaller than 0. The value of a CounterBasedGauge64 has its maximum value whenever the information being modeled is greater than or equal to its maximum value, and has its minimum value whenever the information being modeled is smaller than or equal to its minimum value. If the information being modeled subsequently decreases below (increases above) the maximum (minimum) value, the CounterBasedGauge64 also decreases (increases). Note that this TC is not strictly supported in SMIv2, because the 'always increasing' and 'counter wrap' semantics associated with the Counter64 base type are not preserved. It is possible that management applications which rely solely upon the (Counter64) ASN.1 tag to determine object semantics will mistakenly operate upon objects of this type as they would for Counter64 objects. This textual convention represents a limited and short-term solution, and may be deprecated as a long term solution is defined and deployed to replace it." SYNTAX Counter64 ZeroBasedCounter64 ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes an object which counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^64 is reached. Provided that an application discovers the new object within the minimum time to wrap it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use. Note that this textual convention does not retain all the semantics of the Counter64 base type. Specifically, a Counter64 has an arbitrary initial value, but objects defined with this TC are required to start at the value Bierman, et al. Standards Track [Page 6] RFC 2856 High Capacity Data Types June 2000 zero. This behavior is not likely to have any adverse effects on management applications which are expecting Counter64 semantics. This textual convention represents a limited and short-term solution, and may be deprecated as a long term solution is defined and deployed to replace it." SYNTAX Counter64 END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Bierman, et al. Standards Track [Page 7] RFC 2856 High Capacity Data Types June 2000 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1905] 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] 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. [RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Bierman, et al. Standards Track [Page 8] RFC 2856 High Capacity Data Types June 2000 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 7. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects. Meaningful security considerations can only be written in the modules that define management objects. 8. Authors' Addresses Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408-527-3711 EMail: abierman@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408-526-5260 EMail: kzm@cisco.com Randy Presuhn BMC Software, Inc. Office 1-3141 2141 North First Street San Jose, California 95131 USA Phone: +1 408 546-1006 EMail: rpresuhn@bmc.com Bierman, et al. Standards Track [Page 9] RFC 2856 High Capacity Data Types June 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bierman, et al. Standards Track [Page 10] snmp-mibs-downloader-1.1/mibrfcs/rfc2863.txt0000644000000000000000000045660611402176071015605 0ustar Network Working Group K. McCloghrie Request for Comments: 2863 Cisco Systems Obsoletes: 2233 F. Kastenholz Category: Standards Track Argon Networks June 2000 The Interfaces Group MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Table of Contents 1 Introduction ................................................. 2 2 The SNMP Network Management Framework ........................ 2 3 Experience with the Interfaces Group ......................... 3 3.1 Clarifications/Revisions ................................... 4 3.1.1 Interface Sub-Layers ..................................... 4 3.1.2 Guidance on Defining Sub-layers .......................... 7 3.1.3 Virtual Circuits ......................................... 8 3.1.4 Bit, Character, and Fixed-Length Interfaces .............. 8 3.1.5 Interface Numbering ...................................... 10 3.1.6 Counter Size ............................................. 14 3.1.7 Interface Speed .......................................... 16 3.1.8 Multicast/Broadcast Counters ............................. 17 3.1.9 Trap Enable .............................................. 17 3.1.10 Addition of New ifType values ........................... 18 3.1.11 InterfaceIndex Textual Convention ....................... 18 3.1.12 New states for IfOperStatus ............................. 18 3.1.13 IfAdminStatus and IfOperStatus .......................... 19 3.1.14 IfOperStatus in an Interface Stack ...................... 21 3.1.15 Traps ................................................... 21 3.1.16 ifSpecific .............................................. 23 3.1.17 Creation/Deletion of Interfaces ......................... 23 3.1.18 All Values Must be Known ................................ 24 4 Media-Specific MIB Applicability ............................. 24 5 Overview ..................................................... 25 6 Interfaces Group Definitions ................................. 26 McCloghrie & Kastenholz Standards Track [Page 1] RFC 2863 The Interfaces Group MIB June 2000 7 Acknowledgements ............................................. 64 8 References ................................................... 64 9 Security Considerations ...................................... 66 10 Authors' Addresses .......................................... 67 11 Changes from RFC 2233 ....................................... 67 12 Notice on Intellectual Property ............................. 68 13 Full Copyright Statement .................................... 69 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. This memo discusses the 'interfaces' group of MIB-II [17], especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the ' interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the ' interfaces' group. This memo obsoletes RFC 2233, the previous version of the Interfaces Group MIB. The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119 [16]. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, which consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. McCloghrie & Kastenholz Standards Track [Page 2] RFC 2863 The Interfaces Group MIB June 2000 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [22]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Experience with the Interfaces Group One of the strengths of internetwork-layer protocols such as IP [18] is that they are designed to run over any network interface. In achieving this, IP considers any and all protocols it runs over as a single "network interface" layer. A similar view is taken by other internetwork-layer protocols. This concept is represented in MIB-II by the 'interfaces' group which defines a generic set of managed objects such that any network interface can be managed in an interface-independent manner through these managed objects. The ' interfaces' group provides the means for additional managed objects specific to particular types of network interface (e.g., a specific medium such as Ethernet) to be defined as extensions to the ' interfaces' group for media-specific management. Since the standardization of MIB-II, many such media-specific MIB modules have been defined. Experience in defining these media-specific MIB modules has shown that the model defined by MIB-II is too simplistic and/or static for some types of media-specific management. As a result, some of these media-specific MIB modules assume an evolution or loosening of the McCloghrie & Kastenholz Standards Track [Page 3] RFC 2863 The Interfaces Group MIB June 2000 model. This memo documents and standardizes that evolution of the model and fills in the gaps caused by that evolution. This memo also incorporates the interfaces group extensions documented in RFC 1229 [19]. 3.1. Clarifications/Revisions There are several areas for which experience has indicated that clarification, revision, or extension of the model would be helpful. The following sections discuss the changes in the interfaces group adopted by this memo in each of these areas. In some sections, one or more paragraphs contain discussion of rejected alternatives to the model adopted in this memo. Readers not familiar with the MIB-II model and not interested in the rationale behind the new model may want to skip these paragraphs. 3.1.1. Interface Sub-Layers Experience in defining media-specific management information has shown the need to distinguish between the multiple sub-layers beneath the internetwork-layer. In addition, there is a need to manage these sub-layers in devices (e.g., MAC-layer bridges) which are unaware of which, if any, internetwork protocols run over these sub-layers. As such, a model of having a single conceptual row in the interfaces table (MIB-II's ifTable) represent a whole interface underneath the internetwork-layer, and having a single associated media-specific MIB module (referenced via the ifType object) is too simplistic. A further problem arises with the value of the ifType object which has enumerated values for each type of interface. Consider, for example, an interface with PPP running over an HDLC link which uses a RS232-like connector. Each of these sub-layers has its own media-specific MIB module. If all of this is represented by a single conceptual row in the ifTable, then an enumerated value for ifType is needed for that specific combination which maps to the specific combination of media-specific MIBs. Furthermore, such a model still lacks a method to describe the relationship of all the sub-layers of the MIB stack. An associated problem is that of upward and downward multiplexing of the sub-layers. An example of upward multiplexing is MLP (Multi- Link-Procedure) which provides load-sharing over several serial lines by appearing as a single point-to-point link to the sub-layer(s) above. An example of downward multiplexing would be several instances of PPP, each framed within a separate X.25 virtual circuit, McCloghrie & Kastenholz Standards Track [Page 4] RFC 2863 The Interfaces Group MIB June 2000 all of which run over one fractional T1 channel, concurrently with other uses of the T1 link. The MIB structure must allow these sorts of relationships to be described. Several solutions for representing multiple sub-layers were rejected. One was to retain the concept of one conceptual row for all the sub- layers of an interface and have each media-specific MIB module identify its "superior" and "subordinate" sub-layers through OBJECT IDENTIFIER "pointers". This scheme would have several drawbacks: the superior/subordinate pointers would be contained in the media- specific MIB modules; thus, a manager could not learn the structure of an interface without inspecting multiple pointers in different MIB modules; this would be overly complex and only possible if the manager had knowledge of all the relevant media-specific MIB modules; MIB modules would all need to be retrofitted with these new "pointers"; this scheme would not adequately address the problem of upward and downward multiplexing; and finally, enumerated values of ifType would be needed for each combination of sub-layers. Another rejected solution also retained the concept of one conceptual row for all the sub-layers of an interface but had a new separate MIB table to identify the "superior" and "subordinate" sub-layers and to contain OBJECT IDENTIFIER "pointers" to the media-specific MIB module for each sub-layer. Effectively, one conceptual row in the ifTable would represent each combination of sub-layers between the internetwork-layer and the wire. While this scheme has fewer drawbacks, it still would not support downward multiplexing, such as PPP over MLP: observe that MLP makes two (or more) serial lines appear to the layers above as a single physical interface, and thus PPP over MLP should appear to the internetwork-layer as a single interface; in contrast, this scheme would result in two (or more) conceptual rows in the ifTable, both of which the internetwork-layer would run over. This scheme would also require enumerated values of ifType for each combination of sub-layers. The solution adopted by this memo is to have an individual conceptual row in the ifTable to represent each sub-layer, and have a new separate MIB table (the ifStackTable, see section 6 below) to identify the "superior" and "subordinate" sub-layers through INTEGER "pointers" to the appropriate conceptual rows in the ifTable. This solution supports both upward and downward multiplexing, allows the IANAifType to Media-Specific MIB mapping to identify the media- specific MIB module for that sub-layer, such that the new table need only be referenced to obtain information about layering, and it only requires enumerated values of ifType for each sub-layer, not for combinations of them. However, it does require that the descriptions of some objects in the ifTable (specifically, ifType, ifPhysAddress, ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to any sub-layer (rather than only to a sub-layer immediately beneath McCloghrie & Kastenholz Standards Track [Page 5] RFC 2863 The Interfaces Group MIB June 2000 the network layer as previously), plus some (specifically, ifSpeed) which need to have appropriate values identified for use when a generalized definition does not apply to a particular sub-layer. In addition, this adopted solution makes no requirement that a device, in which a sub-layer is instrumented by a conceptual row of the ifTable, be aware of whether an internetwork protocol runs on top of (i.e., at some layer above) that sub-layer. In fact, the counters of packets received on an interface are defined as counting the number "delivered to a higher-layer protocol". This meaning of "higher-layer" includes: (1) Delivery to a forwarding module which accepts packets/frames/octets and forwards them on at the same protocol layer. For example, for the purposes of this definition, the forwarding module of a MAC-layer bridge is considered as a "higher-layer" to the MAC-layer of each port on the bridge. (2) Delivery to a higher sub-layer within a interface stack. For example, for the purposes of this definition, if a PPP module operated directly over a serial interface, the PPP module would be considered the higher sub-layer to the serial interface. (3) Delivery to a higher protocol layer which does not do packet forwarding for sub-layers that are "at the top of" the interface stack. For example, for the purposes of this definition, the local IP module would be considered the higher layer to a SLIP serial interface. Similarly, for output, the counters of packets transmitted out an interface are defined as counting the number "that higher-level protocols requested to be transmitted". This meaning of "higher- layer" includes: (1) A forwarding module, at the same protocol layer, which transmits packets/frames/octets that were received on an different interface. For example, for the purposes of this definition, the forwarding module of a MAC-layer bridge is considered as a "higher-layer" to the MAC-layer of each port on the bridge. (2) The next higher sub-layer within an interface stack. For example, for the purposes of this definition, if a PPP module operated directly over a serial interface, the PPP module would be a "higher layer" to the serial interface. McCloghrie & Kastenholz Standards Track [Page 6] RFC 2863 The Interfaces Group MIB June 2000 (3) For sub-layers that are "at the top of" the interface stack, a higher element in the network protocol stack. For example, for the purposes of this definition, the local IP module would be considered the higher layer to an Ethernet interface. 3.1.2. Guidance on Defining Sub-layers The designer of a media-specific MIB must decide whether to divide the interface into sub-layers or not, and if so, how to make the divisions. The following guidance is offered to assist the media- specific MIB designer in these decisions. In general, the number of entries in the ifTable should be kept to the minimum required for network management. In particular, a group of related interfaces should be treated as a single interface with one entry in the ifTable providing that: (1) None of the group of interfaces performs multiplexing for any other interface in the agent, (2) There is a meaningful and useful way for all of the ifTable's information (e.g., the counters, and the status variables), and all of the ifTable's capabilities (e.g., write access to ifAdminStatus), to apply to the group of interfaces as a whole. Under these circumstances, there should be one entry in the ifTable for such a group of interfaces, and any internal structure which needs to be represented to network management should be captured in a MIB module specific to the particular type of interface. Note that application of bullet 2 above to the ifTable's ifType object requires that there is a meaningful media-specific MIB and a meaningful ifType value which apply to the group of interfaces as a whole. For example, it is not appropriate to treat an HDLC sub-layer and an RS-232 sub-layer as a single ifTable entry when the media- specific MIBs and the ifType values for HDLC and RS-232 are separate (rather than combined). Subject to the above, it is appropriate to assign an ifIndex value to any interface that can occur in an interface stack (in the ifStackTable) where the bottom of the stack is a physical interface (ifConnectorPresent has the value 'true') and there is a layer-3 or other application that "points down" to the top of this stack. An example of an application that points down to the top of the stack is the Character MIB [21]. McCloghrie & Kastenholz Standards Track [Page 7] RFC 2863 The Interfaces Group MIB June 2000 Note that the sub-layers of an interface on one device will sometimes be different from the sub-layers of the interconnected interface of another device; for example, for a frame-relay DTE interface connected a frameRelayService interface, the inter-connected DTE and DCE interfaces have different ifType values and media-specific MIBs. These guidelines are just that, guidelines. The designer of a media-specific MIB is free to lay out the MIB in whatever SMI conformant manner is desired. However, in doing so, the media- specific MIB MUST completely specify the sub-layering model used for the MIB, and provide the assumptions, reasoning, and rationale used to develop that model. 3.1.3. Virtual Circuits Several of the sub-layers for which media-specific MIB modules have been defined are connection oriented (e.g., Frame Relay, X.25). Experience has shown that each effort to define such a MIB module revisits the question of whether separate conceptual rows in the ifTable are needed for each virtual circuit. Most, if not all, of these efforts to date have decided to have all virtual circuits reference a single conceptual row in the ifTable. This memo strongly recommends that connection-oriented sub-layers do not have a conceptual row in the ifTable for each virtual circuit. This avoids the proliferation of conceptual rows, especially those which have considerable redundant information. (Note, as a comparison, that connection-less sub-layers do not have conceptual rows for each remote address.) There may, however, be circumstances under which it is appropriate for a virtual circuit of a connection- oriented sub-layer to have its own conceptual row in the ifTable; an example of this might be PPP over an X.25 virtual circuit. The MIB in section 6 of this memo supports such circumstances. If a media-specific MIB wishes to assign an entry in the ifTable to each virtual circuit, the MIB designer must present the rationale for this decision in the media-specific MIB's specification. 3.1.4. Bit, Character, and Fixed-Length Interfaces RS-232 is an example of a character-oriented sub-layer over which (e.g., through use of PPP) IP datagrams can be sent. Due to the packet-based nature of many of the objects in the ifTable, experience has shown that it is not appropriate to have a character-oriented sub-layer represented by a whole conceptual row in the ifTable. McCloghrie & Kastenholz Standards Track [Page 8] RFC 2863 The Interfaces Group MIB June 2000 Experience has also shown that it is sometimes desirable to have some management information for bit-oriented interfaces, which are similarly difficult to represent by a whole conceptual row in the ifTable. For example, to manage the channels of a DS1 circuit, where only some of the channels are carrying packet-based data. A further complication is that some subnetwork technologies transmit data in fixed length transmission units. One example of such a technology is cell relay, and in particular Asynchronous Transfer Mode (ATM), which transmits data in fixed-length cells. Representing such a interface as a packet-based interface produces redundant objects if the relationship between the number of packets and the number of octets in either direction is fixed by the size of the transmission unit (e.g., the size of a cell). About half the objects in the ifTable are applicable to every type of interface: packet-oriented, character-oriented, and bit-oriented. Of the other half, two are applicable to both character-oriented and packet-oriented interfaces, and the rest are applicable only to packet-oriented interfaces. Thus, while it is desirable for consistency to be able to represent any/all types of interfaces in the ifTable, it is not possible to implement the full ifTable for bit- and character-oriented sub-layers. A rejected solution to this problem would be to split the ifTable into two (or more) new MIB tables, one of which would contain objects that are relevant only to packet-oriented interfaces (e.g., PPP), and another that may be used by all interfaces. This is highly undesirable since it would require changes in every agent implementing the ifTable (i.e., just about every existing SNMP agent). The solution adopted in this memo builds upon the fact that compliance statements in SMIv2 (in contrast to SMIv1) refer to object groups, where object groups are explicitly defined by listing the objects they contain. Thus, with SMIv2, multiple compliance statements can be specified, one for all interfaces and additional ones for specific types of interfaces. The separate compliance statements can be based on separate object groups, where the object group for all interfaces can contain only those objects from the ifTable which are appropriate for every type of interfaces. Using this solution, every sub-layer can have its own conceptual row in the ifTable. Thus, section 6 of this memo contains definitions of the objects of the existing 'interfaces' group of MIB-II, in a manner which is both SNMPv2-compliant and semantically-equivalent to the existing MIB-II definitions. With equivalent semantics, and with the BER ("on the McCloghrie & Kastenholz Standards Track [Page 9] RFC 2863 The Interfaces Group MIB June 2000 wire") encodings unchanged, these definitions retain the same OBJECT IDENTIFIER values as assigned by MIB-II. Thus, in general, no rewrite of existing agents which conform to MIB-II and the ifExtensions MIB is required. In addition, this memo defines several object groups for the purposes of defining which objects apply to which types of interface: (1) the ifGeneralInformationGroup. This group contains those objects applicable to all types of network interfaces, including bit-oriented interfaces. (2) the ifPacketGroup. This group contains those objects applicable to packet-oriented network interfaces. (3) the ifFixedLengthGroup. This group contains the objects applicable not only to character-oriented interfaces, such as RS-232, but also to those subnetwork technologies, such as cell-relay/ATM, which transmit data in fixed length transmission units. As well as the octet counters, there are also a few other counters (e.g., the error counters) which are useful for this type of interface, but are currently defined as being packet-oriented. To accommodate this, the definitions of these counters are generalized to apply to character-oriented interfaces and fixed-length-transmission interfaces. It should be noted that the octet counters in the ifTable aggregate octet counts for unicast and non-unicast packets into a single octet counter per direction (received/transmitted). Thus, with the above definition of fixed-length-transmission interfaces, where such interfaces which support non-unicast packets, separate counts of unicast and multicast/broadcast transmissions can only be maintained in a media-specific MIB module. 3.1.5. Interface Numbering MIB-II defines an object, ifNumber, whose value represents: "The number of network interfaces (regardless of their current state) present on this system." Each interface is identified by a unique value of the ifIndex object, and the description of ifIndex constrains its value as follows: "Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." McCloghrie & Kastenholz Standards Track [Page 10] RFC 2863 The Interfaces Group MIB June 2000 This constancy requirement on the value of ifIndex for a particular interface is vital for efficient management. However, an increasing number of devices allow for the dynamic addition/removal of network interfaces. One example of this is a dynamic ability to configure the use of SLIP/PPP over a character-oriented port. For such dynamic additions/removals, the combination of the constancy requirement and the restriction that the value of ifIndex is less than ifNumber is problematic. Redefining ifNumber to be the largest value of ifIndex was rejected since it would not help. Such a re-definition would require ifNumber to be deprecated and the utility of the redefined object would be questionable. Alternatively, ifNumber could be deprecated and not replaced. However, the deprecation of ifNumber would require a change to that portion of ifIndex's definition which refers to ifNumber. So, since the definition of ifIndex must be changed anyway in order to solve the problem, changes to ifNumber do not benefit the solution. The solution adopted in this memo is just to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to retain ifNumber with its current definition. This is a minor change in the semantics of ifIndex; however, all existing agent implementations conform to this new definition, and in the interests of not requiring changes to existing agent implementations and to the many existing media-specific MIBs, this memo assumes that this change does not require ifIndex to be deprecated. Experience indicates that this assumption does "break" a few management applications, but this is considered preferable to breaking all agent implementations. This solution also results in the possibility of "holes" in the ifTable, i.e., the ifIndex values of conceptual rows in the ifTable are not necessarily contiguous, but SNMP's GetNext (and GetBulk) operation easily deals with such holes. The value of ifNumber still represents the number of conceptual rows, which increases/decreases as new interfaces are dynamically added/removed. The requirement for constancy (between re-initializations) of an interface's ifIndex value is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used by a *different* dynamically added interface until after the following re-initialization of the network management system. This avoids the need for assignment (in advance) of ifIndex values for all possible interfaces that might be added dynamically. The exact meaning of a "different" interface is hard to define, and there will be gray areas. Any firm definition in this document would likely turn out to be inadequate. Instead, implementors must choose what it means in their particular situation, subject to the following rules: McCloghrie & Kastenholz Standards Track [Page 11] RFC 2863 The Interfaces Group MIB June 2000 (1) a previously-unused value of ifIndex must be assigned to a dynamically added interface if an agent has no knowledge of whether the interface is the "same" or "different" to a previously incarnated interface. (2) a management station, not noticing that an interface has gone away and another has come into existence, must not be confused when calculating the difference between the counter values retrieved on successive polls for a particular ifIndex value. When the new interface is the same as an old interface, but a discontinuity in the value of the interface's counters cannot be avoided, the ifTable has (until now) required that a new ifIndex value be assigned to the returning interface. That is, either all counter values have had to be retained during the absence of an interface in order to use the same ifIndex value on that interface's return, or else a new ifIndex value has had to be assigned to the returning interface. Both alternatives have proved to be burdensome to some implementations: (1) maintaining the counter values may not be possible (e.g., if they are maintained on removable hardware), (2) using a new ifIndex value presents extra work for management applications. While the potential need for such extra work is unavoidable on agent re-initializations, it is desirable to avoid it between re-initializations. To address this, a new object, ifCounterDiscontinuityTime, has been defined to record the time of the last discontinuity in an interface's counters. By monitoring the value of this new object, a management application can now detect counter discontinuities without the ifIndex value of the interface being changed. Thus, an agent which implements this new object should, when a new interface is the same as an old interface, retain that interface's ifIndex value and update if necessary the interface's value of ifCounterDiscontinuityTime. With this new object, a management application must, when calculating differences between counter values retrieved on successive polls, discard any calculated difference for which the value of ifCounterDiscontinuityTime is different for the two polls. (Note that this test must be performed in addition to the normal checking of sysUpTime to detect an agent re-initialization.) Since such discards are a waste of network management processing and bandwidth, an agent should not update the value of ifCounterDiscontinuityTime unless absolutely necessary. While defining this new object is a change in the semantics of the ifTable counter objects, it is impractical to deprecate and redefine McCloghrie & Kastenholz Standards Track [Page 12] RFC 2863 The Interfaces Group MIB June 2000 all these counters because of their wide deployment and importance. Also, a survey of implementations indicates that many agents and management applications do not correctly implement this aspect of the current semantics (because of the burdensome issues mentioned above), such that the practical implications of such a change is small. Thus, this breach of the SMI's rules is considered to be acceptable. Note, however, that the addition of ifCounterDiscontinuityTime does not change the fact that: it is necessary at certain times for the assignment of ifIndex values to change on a re-initialization of the agent (such as a reboot). The possibility of ifIndex value re-assignment must be accommodated by a management application whenever the value of sysUpTime is reset to zero. Note also that some agents support multiple "naming scopes", e.g., for an SNMPv1 agent, multiple values of the SNMPv1 community string. For such an agent (e.g., a CNM agent which supports a different subset of interfaces for different customers), there is no required relationship between the ifIndex values which identify interfaces in one naming scope and those which identify interfaces in another naming scope. It is the agent's choice as to whether the same or different ifIndex values identify the same or different interfaces in different naming scopes. Because of the restriction of the value of ifIndex to be less than ifNumber, interfaces have been numbered with small integer values. This has led to the ability by humans to use the ifIndex values as (somewhat) user-friendly names for network interfaces (e.g., "interface number 3"). With the relaxation of the restriction on the value of ifIndex, there is now the possibility that ifIndex values could be assigned as very large numbers (e.g., memory addresses). Such numbers would be much less user-friendly. Therefore, this memo recommends that ifIndex values still be assigned as (relatively) small integer values starting at 1, even though the values in use at any one time are not necessarily contiguous. (Note that this makes remembering which values have been assigned easy for agents which dynamically add new interfaces) A new problem is introduced by representing each sub-layer as an ifTable entry. Previously, there usually was a simple, direct, mapping of interfaces to the physical ports on systems. This mapping would be based on the ifIndex value. However, by having an ifTable entry for each interface sub-layer, mapping from interfaces to physical ports becomes increasingly problematic. McCloghrie & Kastenholz Standards Track [Page 13] RFC 2863 The Interfaces Group MIB June 2000 To address this issue, a new object, ifName, is added to the MIB. This object contains the device's local name (e.g., the name used at the device's local console) for the interface of which the relevant entry in the ifTable is a component. For example, consider a router having an interface composed of PPP running over an RS-232 port. If the router uses the name "wan1" for the (combined) interface, then the ifName objects for the corresponding PPP and RS-232 entries in the ifTable would both have the value "wan1". On the other hand, if the router uses the name "wan1.1" for the PPP interface and "wan1.2" for the RS-232 port, then the ifName objects for the corresponding PPP and RS-232 entries in the ifTable would have the values "wan1.1" and "wan1.2", respectively. As an another example, consider an agent which responds to SNMP queries concerning an interface on some other (proxied) device: if such a proxied device associates a particular identifier with an interface, then it is appropriate to use this identifier as the value of the interface's ifName, since the local console in this case is that of the proxied device. In contrast, the existing ifDescr object is intended to contain a description of an interface, whereas another new object, ifAlias, provides a location in which a network management application can store a non-volatile interface-naming value of its own choice. The ifAlias object allows a network manager to give one or more interfaces their own unique names, irrespective of any interface- stack relationship. Further, the ifAlias name is non-volatile, and thus an interface must retain its assigned ifAlias value across reboots, even if an agent chooses a new ifIndex value for the interface. 3.1.6. Counter Size As the speed of network media increase, the minimum time in which a 32 bit counter will wrap decreases. For example, a 10Mbs stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that interfaces be polled frequently enough not to miss a counter wrap is increasingly problematic. A rejected solution to this problem was to scale the counters; for example, ifInOctets could be changed to count received octets in, say, 1024 byte blocks. While it would provide acceptable functionality at high rates of the counted-events, at low rates it suffers. If there is little traffic on an interface, there might be a significant interval before enough of the counted-events occur to cause the scaled counter to be incremented. Traffic would then appear to be very bursty, leading to incorrect conclusions of the network's performance. McCloghrie & Kastenholz Standards Track [Page 14] RFC 2863 The Interfaces Group MIB June 2000 Instead, this memo adopts expanded, 64 bit, counters. These counters are provided in new "high capacity" groups. The old, 32-bit, counters have not been deprecated. The 64-bit counters are to be used only when the 32-bit counters do not provide enough capacity; that is, when the 32 bit counters could wrap too fast. For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported. These speed thresholds were chosen as reasonable compromises based on the following: (1) The cost of maintaining 64-bit counters is relatively high, so minimizing the number of agents which must support them is desirable. Common interfaces (such as 10Mbs Ethernet) should not require them. (2) 64-bit counters are a new feature, introduced in the SMIv2. It is reasonable to expect that support for them will be spotty for the immediate future. Thus, we wish to limit them to as few systems as possible. This, in effect, means that 64-bit counters should be limited to higher speed interfaces. Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are fairly wide-spread so it seems reasonable to not require 64-bit counters for these interfaces. (3) The 32-bit octet counters will wrap in the following times, for the following interfaces (when transmitting maximum-sized packets back-to-back): - 10Mbs Ethernet: 57 minutes, - 16Mbs Token Ring: 36 minutes, - a US T3 line (45 megabits): 12 minutes, - FDDI: 5.7 minutes (4) The 32-bit packet counters wrap in about 57 minutes when 64- byte packets are transmitted back-to-back on a 650,000,000 bit/second link. McCloghrie & Kastenholz Standards Track [Page 15] RFC 2863 The Interfaces Group MIB June 2000 As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit octet counter to wrap in just under 5 years. Conversely, an 81,000,000 terabit/second link is required to cause a 64-bit counter to wrap in 30 minutes. We believe that, while technology rapidly marches forward, this link speed will not be achieved for at least several years, leaving sufficient time to evaluate the introduction of 96 bit counters. When 64-bit counters are in use, the 32-bit counters MUST still be available. They will report the low 32-bits of the associated 64-bit count (e.g., ifInOctets will report the least significant 32 bits of ifHCInOctets). This enhances inter-operability with existing implementations at a very minimal cost to agents. The new "high capacity" groups are: (1) the ifHCFixedLengthGroup for character-oriented/fixed-length interfaces, and the ifHCPacketGroup for packet-based interfaces; both of these groups include 64 bit counters for octets, and (2) the ifVHCPacketGroup for packet-based interfaces; this group includes 64 bit counters for octets and packets. 3.1.7. Interface Speed Network speeds are increasing. The range of ifSpeed is limited to reporting a maximum speed of (2**31)-1 bits/second, or approximately 2.2Gbs. SONET defines an OC-48 interface, which is defined at operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs. Thus, ifSpeed is insufficient for the future, and this memo defines an additional object: ifHighSpeed. The ifHighSpeed object reports the speed of the interface in 1,000,000 (1 million) bits/second units. Thus, the true speed of the interface will be the value reported by this object, plus or minus 500,000 bits/second. Other alternatives considered (but rejected) were: (1) Making the interface speed a 64-bit gauge. This was rejected since the current SMI does not allow such a syntax. Furthermore, even if 64-bit gauges were available, their use would require additional complexity in agents due to an increased requirement for 64-bit operations. McCloghrie & Kastenholz Standards Track [Page 16] RFC 2863 The Interfaces Group MIB June 2000 (2) We also considered making "high-32 bit" and "low-32-bit" objects which, when combined, would be a 64-bit value. This simply seemed overly complex for what we are trying to do. Furthermore, a full 64-bits of precision does not seem necessary. The value of ifHighSpeed will be the only report of interface speed for interfaces that are faster than 4,294,967,295 bits per second. At this speed, the granularity of ifHighSpeed will be 1,000,000 bits per second, thus the error will be 1/4294, or about 0.02%. This seems reasonable. (3) Adding a "scale" object, which would define the units which ifSpeed's value is. This would require two additional objects; one for the scaling object, and one to replace the current ifSpeed. This later object is required since the semantics of ifSpeed would be significantly altered, and manager stations which do not understand the new semantics would be confused. 3.1.8. Multicast/Broadcast Counters In MIB-II, the ifTable counters for multicast and broadcast packets are combined as counters of non-unicast packets. In contrast, the ifExtensions MIB [19] defined one set of counters for multicast, and a separate set for broadcast packets. With the separate counters, the original combined counters become redundant. To avoid this redundancy, the non-unicast counters are deprecated. For the output broadcast and multicast counters defined in RFC 1229, their definitions varied slightly from the packet counters in the ifTable, in that they did not count errors/discarded packets. Thus, this memo defines new objects with better aligned definitions. Counters with 64 bits of range are also needed, as explained above. 3.1.9. Trap Enable In the multi-layer interface model, each sub-layer for which there is an entry in the ifTable can generate linkUp/linkDown Traps. Since interface state changes would tend to propagate through the interface (from top to bottom, or bottom to top), it is likely that several traps would be generated for each linkUp/linkDown occurrence. It is desirable to provide a mechanism for manager stations to control the generation of these traps. To this end, the ifLinkUpDownTrapEnable object has been added. This object allows managers to limit generation of traps to just the sub-layers of interest. McCloghrie & Kastenholz Standards Track [Page 17] RFC 2863 The Interfaces Group MIB June 2000 The default setting should limit the number of traps generated to one per interface per linkUp/linkDown event. Furthermore, it seems that the state changes of most interest to network managers occur at the lowest level of an interface stack. Therefore we specify that by default, only the lowest sub-layer of the interface generate traps. 3.1.10. Addition of New ifType values Over time, there is the need to add new ifType enumerated values for new interface types. If the syntax of ifType were defined in the MIB in section 6, then a new version of this MIB would have to be re- issued in order to define new values. In the past, re-issuing of a MIB has occurred only after several years. Therefore, the syntax of ifType is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention, IANAifType, defined in a different document. This allows additional values to be documented without having to re-issue a new version of this document. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new ifType values. 3.1.11. InterfaceIndex Textual Convention A new textual convention, InterfaceIndex, has been defined. This textual convention "contains" all of the semantics of the ifIndex object. This allows other MIB modules to easily import the semantics of ifIndex. 3.1.12. New states for IfOperStatus Three new states have been added to ifOperStatus: 'dormant', 'notPresent', and 'lowerLayerDown'. The dormant state indicates that the relevant interface is not actually in a condition to pass packets (i.e., it is not 'up') but is in a "pending" state, waiting for some external event. For "on- demand" interfaces, this new state identifies the situation where the interface is waiting for events to place it in the up state. Examples of such events might be: (1) having packets to transmit before establishing a connection to a remote system; (2) having a remote system establish a connection to the interface (e.g. dialing up to a slip-server). McCloghrie & Kastenholz Standards Track [Page 18] RFC 2863 The Interfaces Group MIB June 2000 The notPresent state is a refinement on the down state which indicates that the relevant interface is down specifically because some component (typically, a hardware component) is not present in the managed system. Examples of use of the notPresent state are: (1) to allow an interface's conceptual row including its counter values to be retained across a "hot swap" of a card/module, and/or (2) to allow an interface's conceptual row to be created, and thereby enable interfaces to be pre-configured prior to installation of the hardware needed to make the interface operational. Agents are not required to support interfaces in the notPresent state. However, from a conceptual viewpoint, when a row in the ifTable is created, it first enters the notPresent state and then subsequently transitions into the down state; similarly, when a row in the ifTable is deleted, it first enters the notPresent state and then subsequently the object instances are deleted. For an agent with no support for notPresent, both of these transitions (from the notPresent state to the down state, and from the notPresent state to the instances being removed) are immediate, i.e., the transition does not last long enough to be recorded by ifOperStatus. Even for those agents which do support interfaces in the notPresent state, the length of time and conditions under which an interface stays in the notPresent state is implementation-specific. The lowerLayerDown state is also a refinement on the down state. This new state indicates that this interface runs "on top of" one or more other interfaces (see ifStackTable) and that this interface is down specifically because one or more of these lower-layer interfaces are down. 3.1.13. IfAdminStatus and IfOperStatus The down state of ifOperStatus now has two meanings, depending on the value of ifAdminStatus. (1) if ifAdminStatus is not down and ifOperStatus is down then a fault condition is presumed to exist on the interface. (2) if ifAdminStatus is down, then ifOperStatus will normally also be down (or notPresent) i.e., there is not (necessarily) a fault condition on the interface. Note that when ifAdminStatus transitions to down, ifOperStatus will normally also transition to down. In this situation, it is possible McCloghrie & Kastenholz Standards Track [Page 19] RFC 2863 The Interfaces Group MIB June 2000 that ifOperStatus's transition will not occur immediately, but rather after a small time lag to complete certain operations before going "down"; for example, it might need to finish transmitting a packet. If a manager station finds that ifAdminStatus is down and ifOperStatus is not down for a particular interface, the manager station should wait a short while and check again. If the condition still exists, only then should it raise an error indication. Naturally, it should also ensure that ifLastChange has not changed during this interval. Whenever an interface table entry is created (usually as a result of system initialization), the relevant instance of ifAdminStatus is set to down, and ifOperStatus will be down or notPresent. An interface may be enabled in two ways: either as a result of explicit management action (e.g. setting ifAdminStatus to up) or as a result of the managed system's initialization process. When ifAdminStatus changes to the up state, the related ifOperStatus should do one of the following: (1) Change to the up state if and only if the interface is able to send and receive packets. (2) Change to the lowerLayerDown state if and only if the interface is prevented from entering the up state because of the state of one or more of the interfaces beneath it in the interface stack. (3) Change to the dormant state if and only if the interface is found to be operable, but the interface is waiting for other, external, events to occur before it can transmit or receive packets. Presumably when the expected events occur, the interface will then change to the up state. (4) Remain in the down state if an error or other fault condition is detected on the interface. (5) Change to the unknown state if, for some reason, the state of the interface can not be ascertained. (6) Change to the testing state if some test(s) must be performed on the interface. Presumably after completion of the test, the interface's state will change to up, dormant, or down, as appropriate. (7) Remain in the notPresent state if interface components are missing. McCloghrie & Kastenholz Standards Track [Page 20] RFC 2863 The Interfaces Group MIB June 2000 3.1.14. IfOperStatus in an Interface Stack When an interface is a part of an interface-stack, but is not the lowest interface in the stack, then: (1) ifOperStatus has the value 'up' if it is able to pass packets due to one or more interfaces below it in the stack being 'up', irrespective of whether other interfaces below it are 'down', ' dormant', 'notPresent', 'lowerLayerDown', 'unknown' or ' testing'. (2) ifOperStatus may have the value 'up' or 'dormant' if one or more interfaces below it in the stack are 'dormant', and all others below it are either 'down', 'dormant', 'notPresent', ' lowerLayerDown', 'unknown' or 'testing'. (3) ifOperStatus has the value 'lowerLayerDown' while all interfaces below it in the stack are either 'down', ' notPresent', 'lowerLayerDown', or 'testing'. 3.1.15. Traps The exact definition of when linkUp and linkDown traps are generated has been changed to reflect the changes to ifAdminStatus and ifOperStatus. Operational experience indicates that management stations are most concerned with an interface being in the down state and the fact that this state may indicate a failure. Thus, it is most useful to instrument transitions into/out of either the up state or the down state. Instrumenting transitions into or out of the up state was rejected since it would have the drawback that a demand interface might have many transitions between up and dormant, leading to many linkUp traps and no linkDown traps. Furthermore, if a node's only interface is the demand interface, then a transition to dormant would entail generation of a linkDown trap, necessitating bringing the link to the up state (and a linkUp trap)!! On the other hand, instrumenting transitions into or out of the down state (to/from all other states except notPresent) has the advantages: (1) A transition into the down state (from a state other than notPresent) will occur when an error is detected on an interface. Error conditions are presumably of great interest to network managers. McCloghrie & Kastenholz Standards Track [Page 21] RFC 2863 The Interfaces Group MIB June 2000 (2) Departing the down state (to a state other than the notPresent state) generally indicates that the interface is going to either up or dormant, both of which are considered "healthy" states. Furthermore, it is believed that generating traps on transitions into or out of the down state (except to/from the notPresent state) is generally consistent with current usage and interpretation of these traps by manager stations. Transitions to/from the notPresent state are concerned with the insertion and removal of hardware, and are outside the scope of these traps. Therefore, this memo defines that LinkUp and linkDown traps are generated just after ifOperStatus leaves, or just before it enters, the down state, respectively; except that LinkUp and linkDown traps are never generated on transitions to/from the notPresent state. For the purpose of deciding when these traps occur, the lowerLayerDown state and the down state are considered to be equivalent, i.e., there is no trap on transition from lowerLayerDown into down, and there is a trap on transition from any other state except down (and notPresent) into lowerLayerDown. Note that this definition allows a node with only one interface to transmit a linkDown trap before that interface goes down. (Of course, when the interface is going down because of a failure condition, the linkDown trap probably cannot be successfully transmitted anyway.) Some interfaces perform a link "training" function when trying to bring the interface up. In the event that such an interface were defective, then the training function would fail and the interface would remain down, and the training function might be repeated at appropriate intervals. If the interface, while performing this training function, were considered to the in the testing state, then linkUp and linkDown traps would be generated for each start and end of the training function. This is not the intent of the linkUp and linkDown traps, and therefore, while performing such a training function, the interface's state should be represented as down. An exception to the above generation of linkUp/linkDown traps on changes in ifOperStatus, occurs when an interface is "flapping", i.e., when it is rapidly oscillating between the up and down states. If traps were generated for each such oscillation, the network and the network management system would be flooded with unnecessary traps. In such a situation, the agent should limit the rate at which it generates traps. McCloghrie & Kastenholz Standards Track [Page 22] RFC 2863 The Interfaces Group MIB June 2000 3.1.16. ifSpecific The original definition of the OBJECT IDENTIFIER value of ifSpecific was not sufficiently clear. As a result, different implementors used it differently, and confusion resulted. Some implementations set the value of ifSpecific to the OBJECT IDENTIFIER that defines the media- specific MIB, i.e., the "foo" of: foo OBJECT IDENTIFIER ::= { transmission xxx } while others set it to be OBJECT IDENTIFIER of the specific table or entry in the appropriate media-specific MIB (i.e., fooTable or fooEntry), while still others set it be the OBJECT IDENTIFIER of the index object of the table's row, including instance identifier, (i.e., fooIfIndex.ifIndex). A definition based on the latter would not be sufficient unless it also allowed for media-specific MIBs which include several tables, where each table has its own (different) indexing. The only definition that can both be made explicit and can cover all the useful situations is to have ifSpecific be the most general value for the media-specific MIB module (the first example given above). This effectively makes it redundant because it contains no more information than is provided by ifType. Thus, ifSpecific has been deprecated. 3.1.17. Creation/Deletion of Interfaces While some interfaces, for example, most physical interfaces, cannot be created via network management, other interfaces such as logical interfaces sometimes can be. The ifTable contains only generic information about an interface. Almost all 'create-able' interfaces have other, media-specific, information through which configuration parameters may be supplied prior to creating such an interface. Thus, the ifTable does not itself support the creation or deletion of an interface (specifically, it has no RowStatus [6] column). Rather, if a particular interface type supports the dynamic creation and/or deletion of an interface of that type, then that media-specific MIB should include an appropriate RowStatus object (see the ATM LAN- Emulation Client MIB [20] for an example of a MIB which does this). Typically, when such a RowStatus object is created/deleted, then the conceptual row in the ifTable appears/disappears as a by-product, and an ifIndex value (chosen by the agent) is stored in an appropriate object in the media-specific MIB. McCloghrie & Kastenholz Standards Track [Page 23] RFC 2863 The Interfaces Group MIB June 2000 3.1.18. All Values Must be Known There are a number of situations where an agent does not know the value of one or more objects for a particular interface. In all such circumstances, an agent MUST NOT instantiate an object with an incorrect value; rather, it MUST respond with the appropriate error/exception condition (e.g., noSuchInstance or noSuchName). One example is where an agent is unable to count the occurrences defined by one (or more) of the ifTable counters. In this circumstance, the agent MUST NOT instantiate the particular counter with a value of, say, zero. To do so would be to provide mis- information to a network management application reading the zero value, and thereby assuming that there have been no occurrences of the event (e.g., no input errors because ifInErrors is always zero). Sometimes the lack of knowledge of an object's value is temporary. For example, when the MTU of an interface is a configured value and a device dynamically learns the configured value through (after) exchanging messages over the interface (e.g., ATM LAN-Emulation [20]). In such a case, the value is not known until after the ifTable entry has already been created. In such a case, the ifTable entry should be created without an instance of the object whose value is unknown; later, when the value becomes known, the missing object can then be instantiated (e.g., the instance of ifMtu is only instantiated once the interface's MTU becomes known). As a result of this "known values" rule, management applications MUST be able to cope with the responses to retrieving the object instances within a conceptual row of the ifTable revealing that some of the row's columnar objects are missing/not available. 4. Media-Specific MIB Applicability The exact use and semantics of many objects in this MIB are open to some interpretation. This is a result of the generic nature of this MIB. It is not always possible to come up with specific, unambiguous, text that covers all cases and yet preserves the generic nature of the MIB. Therefore, it is incumbent upon a media-specific MIB designer to, wherever necessary, clarify the use of the objects in this MIB with respect to the media-specific MIB. McCloghrie & Kastenholz Standards Track [Page 24] RFC 2863 The Interfaces Group MIB June 2000 Specific areas of clarification include Layering Model The media-specific MIB designer MUST completely and unambiguously specify the layering model used. Each individual sub-layer must be identified, as must the ifStackTable's portrayal of the relationship(s) between the sub-layers. Virtual Circuits The media-specific MIB designer MUST specify whether virtual circuits are assigned entries in the ifTable or not. If they are, compelling rationale must be presented. ifRcvAddressTable The media-specific MIB designer MUST specify the applicability of the ifRcvAddressTable. ifType For each of the ifType values to which the media-specific MIB applies, it must specify the mapping of ifType values to media- specific MIB module(s) and instances of MIB objects within those modules. ifXxxOctets The definitions of ifInOctets and ifOutOctets (and similarly, ifHCInOctets and ifHCOutOctets) specify that their values include framing characters. The media-specific MIB designer MUST specify any special conditions of the media concerning the inclusion of framing characters, especially with respect to frames with errors. However, wherever this interface MIB is specific in the semantics, DESCRIPTION, or applicability of objects, the media-specific MIB designer MUST NOT change said semantics, DESCRIPTION, or applicability. 5. Overview This MIB consists of 4 tables: ifTable This table is the ifTable from MIB-II. ifXTable This table contains objects that have been added to the Interface MIB as a result of the Interface Evolution effort, or replacements for objects of the original (MIB-II) ifTable that were deprecated McCloghrie & Kastenholz Standards Track [Page 25] RFC 2863 The Interfaces Group MIB June 2000 because the semantics of said objects have significantly changed. This table also contains objects that were previously in the ifExtnsTable. ifStackTable This table contains objects that define the relationships among the sub-layers of an interface. ifRcvAddressTable This table contains objects that are used to define the media- level addresses which this interface will receive. This table is a generic table. The designers of media-specific MIBs must define exactly how this table applies to their specific MIB. 6. Interfaces Group Definitions IF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, Integer32, TimeTicks, mib-2, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, PhysAddress, TruthValue, RowStatus, TimeStamp, AutonomousType, TestAndIncr FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF snmpTraps FROM SNMPv2-MIB IANAifType FROM IANAifType-MIB; ifMIB MODULE-IDENTITY LAST-UPDATED "200006140000Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO " Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US 408-526-5260 kzm@cisco.com" DESCRIPTION "The MIB module to describe generic objects for network interface sub-layers. This MIB is an updated version of MIB-II's ifTable, and incorporates the extensions defined in RFC 1229." McCloghrie & Kastenholz Standards Track [Page 26] RFC 2863 The Interfaces Group MIB June 2000 REVISION "200006140000Z" DESCRIPTION "Clarifications agreed upon by the Interfaces MIB WG, and published as RFC 2863." REVISION "199602282155Z" DESCRIPTION "Revisions made by the Interfaces MIB WG, and published in RFC 2233." REVISION "199311082155Z" DESCRIPTION "Initial revision, published as part of RFC 1573." ::= { mib-2 31 } ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 } interfaces OBJECT IDENTIFIER ::= { mib-2 2 } -- -- Textual Conventions -- -- OwnerString has the same semantics as used in RFC 1271 OwnerString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS deprecated DESCRIPTION "This data type is used to model an administratively assigned name of the owner of a resource. This information is taken from the NVT ASCII character set. It is suggested that this name contain one or more of the following: ASCII form of the manager station's transport address, management station name (e.g., domain name), network management personnel's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'agent'." SYNTAX OCTET STRING (SIZE(0..255)) -- InterfaceIndex contains the semantics of ifIndex and should be used -- for any objects defined in other MIB modules that need these semantics. InterfaceIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 27] RFC 2863 The Interfaces Group MIB June 2000 "A unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." SYNTAX Integer32 (1..2147483647) InterfaceIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the InterfaceIndex convention. The latter defines a greater than zero value used to identify an interface or interface sub-layer in the managed system. This extension permits the additional value of zero. the value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced." SYNTAX Integer32 (0..2147483647) ifNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of network interfaces (regardless of their current state) present on this system." ::= { interfaces 1 } ifTableLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last creation or deletion of an entry in the ifTable. If the number of entries has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { ifMIBObjects 5 } -- the Interfaces table -- The Interfaces table contains information on the entity's McCloghrie & Kastenholz Standards Track [Page 28] RFC 2863 The Interfaces Group MIB June 2000 -- interfaces. Each sub-layer below the internetwork-layer -- of a network interface is considered to be an interface. ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifNumber." ::= { interfaces 2 } ifEntry OBJECT-TYPE SYNTAX IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing management information applicable to a particular interface." INDEX { ifIndex } ::= { ifTable 1 } IfEntry ::= SEQUENCE { ifIndex InterfaceIndex, ifDescr DisplayString, ifType IANAifType, ifMtu Integer32, ifSpeed Gauge32, ifPhysAddress PhysAddress, ifAdminStatus INTEGER, ifOperStatus INTEGER, ifLastChange TimeTicks, ifInOctets Counter32, ifInUcastPkts Counter32, ifInNUcastPkts Counter32, -- deprecated ifInDiscards Counter32, ifInErrors Counter32, ifInUnknownProtos Counter32, ifOutOctets Counter32, ifOutUcastPkts Counter32, ifOutNUcastPkts Counter32, -- deprecated ifOutDiscards Counter32, ifOutErrors Counter32, ifOutQLen Gauge32, -- deprecated ifSpecific OBJECT IDENTIFIER -- deprecated } McCloghrie & Kastenholz Standards Track [Page 29] RFC 2863 The Interfaces Group MIB June 2000 ifIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { ifEntry 1 } ifDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the interface hardware/software." ::= { ifEntry 2 } ifType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of interface. Additional values for ifType are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the IANAifType textual convention." ::= { ifEntry 3 } ifMtu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the largest packet which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface." ::= { ifEntry 4 } ifSpeed OBJECT-TYPE McCloghrie & Kastenholz Standards Track [Page 30] RFC 2863 The Interfaces Group MIB June 2000 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. If the bandwidth of the interface is greater than the maximum value reportable by this object then this object should report its maximum value (4,294,967,295) and ifHighSpeed must be used to report the interace's speed. For a sub-layer which has no concept of bandwidth, this object should be zero." ::= { ifEntry 5 } ifPhysAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The interface's address at its protocol sub-layer. For example, for an 802.x interface, this object normally contains a MAC address. The interface's media-specific MIB must define the bit and byte ordering and the format of the value of this object. For interfaces which do not have such an address (e.g., a serial line), this object should contain an octet string of zero length." ::= { ifEntry 6 } ifAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state)." ::= { ifEntry 7 } McCloghrie & Kastenholz Standards Track [Page 31] RFC 2863 The Interfaces Group MIB June 2000 ifOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3), -- in some test mode unknown(4), -- status can not be determined -- for some reason. dormant(5), notPresent(6), -- some component is missing lowerLayerDown(7) -- down due to state of -- lower-layer interface(s) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed. If ifAdminStatus is down(2) then ifOperStatus should be down(2). If ifAdminStatus is changed to up(1) then ifOperStatus should change to up(1) if the interface is ready to transmit and receive network traffic; it should change to dormant(5) if the interface is waiting for external actions (such as a serial line waiting for an incoming connection); it should remain in the down(2) state if and only if there is a fault that prevents it from going to the up(1) state; it should remain in the notPresent(6) state if the interface has missing (typically, hardware) components." ::= { ifEntry 8 } ifLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { ifEntry 9 } ifInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received on the interface, McCloghrie & Kastenholz Standards Track [Page 32] RFC 2863 The Interfaces Group MIB June 2000 including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 10 } ifInUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 11 } ifInNUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast or broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. This object is deprecated in favour of ifInMulticastPkts and ifInBroadcastPkts." ::= { ifEntry 12 } ifInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent McCloghrie & Kastenholz Standards Track [Page 33] RFC 2863 The Interfaces Group MIB June 2000 their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 13 } ifInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character- oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 14 } ifInUnknownProtos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For packet-oriented interfaces, the number of packets received via the interface which were discarded because of an unknown or unsupported protocol. For character-oriented or fixed-length interfaces that support protocol multiplexing the number of transmission units received via the interface which were discarded because of an unknown or unsupported protocol. For any interface that does not support protocol multiplexing, this counter will always be 0. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 15 } McCloghrie & Kastenholz Standards Track [Page 34] RFC 2863 The Interfaces Group MIB June 2000 ifOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 16 } ifOutUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 17 } ifOutNUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. This object is deprecated in favour of ifOutMulticastPkts and ifOutBroadcastPkts." ::= { ifEntry 18 } McCloghrie & Kastenholz Standards Track [Page 35] RFC 2863 The Interfaces Group MIB June 2000 ifOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 19 } ifOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 20 } ifOutQLen OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The length of the output packet queue (in packets)." ::= { ifEntry 21 } ifSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS deprecated DESCRIPTION "A reference to MIB definitions specific to the particular media being used to realize the interface. It is McCloghrie & Kastenholz Standards Track [Page 36] RFC 2863 The Interfaces Group MIB June 2000 recommended that this value point to an instance of a MIB object in the media-specific MIB, i.e., that this object have the semantics associated with the InstancePointer textual convention defined in RFC 2579. In fact, it is recommended that the media-specific MIB specify what value ifSpecific should/can take for values of ifType. If no MIB definitions specific to the particular media are available, the value should be set to the OBJECT IDENTIFIER { 0 0 }." ::= { ifEntry 22 } -- -- Extension to the interface table -- -- This table replaces the ifExtnsTable table. -- ifXTable OBJECT-TYPE SYNTAX SEQUENCE OF IfXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifNumber. This table contains additional objects for the interface table." ::= { ifMIBObjects 1 } ifXEntry OBJECT-TYPE SYNTAX IfXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing additional management information applicable to a particular interface." AUGMENTS { ifEntry } ::= { ifXTable 1 } IfXEntry ::= SEQUENCE { ifName DisplayString, ifInMulticastPkts Counter32, ifInBroadcastPkts Counter32, ifOutMulticastPkts Counter32, ifOutBroadcastPkts Counter32, ifHCInOctets Counter64, ifHCInUcastPkts Counter64, ifHCInMulticastPkts Counter64, McCloghrie & Kastenholz Standards Track [Page 37] RFC 2863 The Interfaces Group MIB June 2000 ifHCInBroadcastPkts Counter64, ifHCOutOctets Counter64, ifHCOutUcastPkts Counter64, ifHCOutMulticastPkts Counter64, ifHCOutBroadcastPkts Counter64, ifLinkUpDownTrapEnable INTEGER, ifHighSpeed Gauge32, ifPromiscuousMode TruthValue, ifConnectorPresent TruthValue, ifAlias DisplayString, ifCounterDiscontinuityTime TimeStamp } ifName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The textual name of the interface. The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name, such as `le0' or a simple port number, such as `1', depending on the interface naming syntax of the device. If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName. Note that for an agent which responds to SNMP queries concerning an interface on some other (proxied) device, then the value of ifName for such an interface is the proxied device's local name for it. If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string." ::= { ifXEntry 1 } ifInMulticastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other McCloghrie & Kastenholz Standards Track [Page 38] RFC 2863 The Interfaces Group MIB June 2000 times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 2 } ifInBroadcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 3 } ifOutMulticastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 4 } ifOutBroadcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other McCloghrie & Kastenholz Standards Track [Page 39] RFC 2863 The Interfaces Group MIB June 2000 times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 5 } -- -- High Capacity Counter objects. These objects are all -- 64 bit versions of the "basic" ifTable counters. These -- objects all have the same basic semantics as their 32-bit -- counterparts, however, their syntax has been extended -- to 64 bits. -- ifHCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received on the interface, including framing characters. This object is a 64-bit version of ifInOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 6 } ifHCInUcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. This object is a 64-bit version of ifInUcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 7 } ifHCInMulticastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 40] RFC 2863 The Interfaces Group MIB June 2000 "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifInMulticastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 8 } ifHCInBroadcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer. This object is a 64-bit version of ifInBroadcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 9 } ifHCOutOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of ifOutOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 10 } ifHCOutUcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 41] RFC 2863 The Interfaces Group MIB June 2000 "The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of ifOutUcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 11 } ifHCOutMulticastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifOutMulticastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 12 } ifHCOutBroadcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of ifOutBroadcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifXEntry 13 } ifLinkUpDownTrapEnable OBJECT-TYPE McCloghrie & Kastenholz Standards Track [Page 42] RFC 2863 The Interfaces Group MIB June 2000 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether linkUp/linkDown traps should be generated for this interface. By default, this object should have the value enabled(1) for interfaces which do not operate on 'top' of any other interface (as defined in the ifStackTable), and disabled(2) otherwise." ::= { ifXEntry 14 } ifHighSpeed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the interface's current bandwidth in units of 1,000,000 bits per second. If this object reports a value of `n' then the speed of the interface is somewhere in the range of `n-500,000' to `n+499,999'. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. For a sub-layer which has no concept of bandwidth, this object should be zero." ::= { ifXEntry 15 } ifPromiscuousMode OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object has a value of false(2) if this interface only accepts packets/frames that are addressed to this station. This object has a value of true(1) when the station accepts all packets/frames transmitted on the media. The value true(1) is only legal on certain types of media. If legal, setting this object to a value of true(1) may require the interface to be reset before becoming effective. The value of ifPromiscuousMode does not affect the reception of broadcast and multicast packets/frames by the interface." ::= { ifXEntry 16 } ifConnectorPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only McCloghrie & Kastenholz Standards Track [Page 43] RFC 2863 The Interfaces Group MIB June 2000 STATUS current DESCRIPTION "This object has the value 'true(1)' if the interface sublayer has a physical connector and the value 'false(2)' otherwise." ::= { ifXEntry 17 } ifAlias OBJECT-TYPE SYNTAX DisplayString (SIZE(0..64)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is an 'alias' name for the interface as specified by a network manager, and provides a non-volatile 'handle' for the interface. On the first instantiation of an interface, the value of ifAlias associated with that interface is the zero-length string. As and when a value is written into an instance of ifAlias through a network management set operation, then the agent must retain the supplied value in the ifAlias instance associated with the same interface for as long as that interface remains instantiated, including across all re- initializations/reboots of the network management system, including those which result in a change of the interface's ifIndex value. An example of the value which a network manager might store in this object for a WAN interface is the (Telco's) circuit number/identifier of the interface. Some agents may support write-access only for interfaces having particular values of ifType. An agent which supports write access to this object is required to keep the value in non-volatile storage, but it may limit the length of new values depending on how much storage is already occupied by the current values for other interfaces." ::= { ifXEntry 18 } ifCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or McCloghrie & Kastenholz Standards Track [Page 44] RFC 2863 The Interfaces Group MIB June 2000 Counter64 object contained in the ifTable or ifXTable. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { ifXEntry 19 } -- The Interface Stack Group -- -- Implementation of this group is optional, but strongly recommended -- for all systems -- ifStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing information on the relationships between the multiple sub-layers of network interfaces. In particular, it contains information on which sub-layers run 'on top of' which other sub-layers, where each sub-layer corresponds to a conceptual row in the ifTable. For example, when the sub-layer with ifIndex value x runs over the sub-layer with ifIndex value y, then this table contains: ifStackStatus.x.y=active For each ifIndex value, I, which identifies an active interface, there are always at least two instantiated rows in this table associated with I. For one of these rows, I is the value of ifStackHigherLayer; for the other, I is the value of ifStackLowerLayer. (If I is not involved in multiplexing, then these are the only two rows associated with I.) For example, two rows exist even for an interface which has no others stacked on top or below it: ifStackStatus.0.x=active ifStackStatus.x.0=active " ::= { ifMIBObjects 2 } ifStackEntry OBJECT-TYPE SYNTAX IfStackEntry MAX-ACCESS not-accessible STATUS current McCloghrie & Kastenholz Standards Track [Page 45] RFC 2863 The Interfaces Group MIB June 2000 DESCRIPTION "Information on a particular relationship between two sub- layers, specifying that one sub-layer runs on 'top' of the other sub-layer. Each sub-layer corresponds to a conceptual row in the ifTable." INDEX { ifStackHigherLayer, ifStackLowerLayer } ::= { ifStackTable 1 } IfStackEntry ::= SEQUENCE { ifStackHigherLayer InterfaceIndexOrZero, ifStackLowerLayer InterfaceIndexOrZero, ifStackStatus RowStatus } ifStackHigherLayer OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex corresponding to the higher sub-layer of the relationship, i.e., the sub-layer which runs on 'top' of the sub-layer identified by the corresponding instance of ifStackLowerLayer. If there is no higher sub-layer (below the internetwork layer), then this object has the value 0." ::= { ifStackEntry 1 } ifStackLowerLayer OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex corresponding to the lower sub-layer of the relationship, i.e., the sub-layer which runs 'below' the sub-layer identified by the corresponding instance of ifStackHigherLayer. If there is no lower sub-layer, then this object has the value 0." ::= { ifStackEntry 2 } ifStackStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 46] RFC 2863 The Interfaces Group MIB June 2000 "The status of the relationship between two sub-layers. Changing the value of this object from 'active' to 'notInService' or 'destroy' will likely have consequences up and down the interface stack. Thus, write access to this object is likely to be inappropriate for some types of interfaces, and many implementations will choose not to support write-access for any type of interface." ::= { ifStackEntry 3 } ifStackLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last change of the (whole) interface stack. A change of the interface stack is defined to be any creation, deletion, or change in value of any instance of ifStackStatus. If the interface stack has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { ifMIBObjects 6 } -- Generic Receive Address Table -- -- This group of objects is mandatory for all types of -- interfaces which can receive packets/frames addressed to -- more than one address. -- -- This table replaces the ifExtnsRcvAddr table. The main -- difference is that this table makes use of the RowStatus -- textual convention, while ifExtnsRcvAddr did not. ifRcvAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IfRcvAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains an entry for each address (broadcast, multicast, or uni-cast) for which the system will receive packets/frames on a particular interface, except as follows: - for an interface operating in promiscuous mode, entries are only required for those addresses for which the system would receive frames were it not operating in promiscuous mode. McCloghrie & Kastenholz Standards Track [Page 47] RFC 2863 The Interfaces Group MIB June 2000 - for 802.5 functional addresses, only one entry is required, for the address which has the functional address bit ANDed with the bit mask of all functional addresses for which the interface will accept frames. A system is normally able to use any unicast address which corresponds to an entry in this table as a source address." ::= { ifMIBObjects 4 } ifRcvAddressEntry OBJECT-TYPE SYNTAX IfRcvAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of objects identifying an address for which the system will accept packets/frames on the particular interface identified by the index value ifIndex." INDEX { ifIndex, ifRcvAddressAddress } ::= { ifRcvAddressTable 1 } IfRcvAddressEntry ::= SEQUENCE { ifRcvAddressAddress PhysAddress, ifRcvAddressStatus RowStatus, ifRcvAddressType INTEGER } ifRcvAddressAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "An address for which the system will accept packets/frames on this entry's interface." ::= { ifRcvAddressEntry 1 } ifRcvAddressStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the ifRcvAddressTable." ::= { ifRcvAddressEntry 2 } ifRcvAddressType OBJECT-TYPE SYNTAX INTEGER { McCloghrie & Kastenholz Standards Track [Page 48] RFC 2863 The Interfaces Group MIB June 2000 other(1), volatile(2), nonVolatile(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object has the value nonVolatile(3) for those entries in the table which are valid and will not be deleted by the next restart of the managed system. Entries having the value volatile(2) are valid and exist, but have not been saved, so that will not exist after the next restart of the managed system. Entries having the value other(1) are valid and exist but are not classified as to whether they will continue to exist after the next restart." DEFVAL { volatile } ::= { ifRcvAddressEntry 3 } -- definition of interface-related traps. linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } linkUp NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkUp trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 4 } -- conformance information McCloghrie & Kastenholz Standards Track [Page 49] RFC 2863 The Interfaces Group MIB June 2000 ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 } ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 } ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 } -- compliance statements ifCompliance3 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which have network interfaces." MODULE -- this module MANDATORY-GROUPS { ifGeneralInformationGroup, linkUpDownNotificationsGroup } -- The groups: -- ifFixedLengthGroup -- ifHCFixedLengthGroup -- ifPacketGroup -- ifHCPacketGroup -- ifVHCPacketGroup -- are mutually exclusive; at most one of these groups is implemented -- for a particular interface. When any of these groups is implemented -- for a particular interface, then ifCounterDiscontinuityGroup must -- also be implemented for that interface. GROUP ifFixedLengthGroup DESCRIPTION "This group is mandatory for those network interfaces which are character-oriented or transmit data in fixed-length transmission units, and for which the value of the corresponding instance of ifSpeed is less than or equal to 20,000,000 bits/second." GROUP ifHCFixedLengthGroup DESCRIPTION "This group is mandatory for those network interfaces which are character-oriented or transmit data in fixed-length transmission units, and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second." GROUP ifPacketGroup DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 50] RFC 2863 The Interfaces Group MIB June 2000 "This group is mandatory for those network interfaces which are packet-oriented, and for which the value of the corresponding instance of ifSpeed is less than or equal to 20,000,000 bits/second." GROUP ifHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second but less than or equal to 650,000,000 bits/second." GROUP ifVHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 650,000,000 bits/second." GROUP ifCounterDiscontinuityGroup DESCRIPTION "This group is mandatory for those network interfaces that are required to maintain counters (i.e., those for which one of the ifFixedLengthGroup, ifHCFixedLengthGroup, ifPacketGroup, ifHCPacketGroup, or ifVHCPacketGroup is mandatory)." GROUP ifRcvAddressGroup DESCRIPTION "The applicability of this group MUST be defined by the media-specific MIBs. Media-specific MIBs must define the exact meaning, use, and semantics of the addresses in this group." OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ifAdminStatus McCloghrie & Kastenholz Standards Track [Page 51] RFC 2863 The Interfaces Group MIB June 2000 SYNTAX INTEGER { up(1), down(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, nor is support for the value testing(3)." OBJECT ifAlias MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { ifCompliances 3 } -- units of conformance ifGeneralInformationGroup OBJECT-GROUP OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress, ifAdminStatus, ifOperStatus, ifLastChange, ifLinkUpDownTrapEnable, ifConnectorPresent, ifHighSpeed, ifName, ifNumber, ifAlias, ifTableLastChange } STATUS current DESCRIPTION "A collection of objects providing information applicable to all network interfaces." ::= { ifGroups 10 } -- the following five groups are mutually exclusive; at most -- one of these groups is implemented for any interface ifFixedLengthGroup OBJECT-GROUP OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors } STATUS current DESCRIPTION "A collection of objects providing information specific to non-high speed (non-high speed interfaces transmit and receive at speeds less than or equal to 20,000,000 bits/second) character-oriented or fixed-length-transmission network interfaces." ::= { ifGroups 2 } ifHCFixedLengthGroup OBJECT-GROUP OBJECTS { ifHCInOctets, ifHCOutOctets, ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors } STATUS current DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 52] RFC 2863 The Interfaces Group MIB June 2000 "A collection of objects providing information specific to high speed (greater than 20,000,000 bits/second) character- oriented or fixed-length-transmission network interfaces." ::= { ifGroups 3 } ifPacketGroup OBJECT-GROUP OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors, ifMtu, ifInUcastPkts, ifInMulticastPkts, ifInBroadcastPkts, ifInDiscards, ifOutUcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts, ifOutDiscards, ifPromiscuousMode } STATUS current DESCRIPTION "A collection of objects providing information specific to non-high speed (non-high speed interfaces transmit and receive at speeds less than or equal to 20,000,000 bits/second) packet-oriented network interfaces." ::= { ifGroups 4 } ifHCPacketGroup OBJECT-GROUP OBJECTS { ifHCInOctets, ifHCOutOctets, ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors, ifMtu, ifInUcastPkts, ifInMulticastPkts, ifInBroadcastPkts, ifInDiscards, ifOutUcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts, ifOutDiscards, ifPromiscuousMode } STATUS current DESCRIPTION "A collection of objects providing information specific to high speed (greater than 20,000,000 bits/second but less than or equal to 650,000,000 bits/second) packet-oriented network interfaces." ::= { ifGroups 5 } ifVHCPacketGroup OBJECT-GROUP OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, ifHCInBroadcastPkts, ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts, ifHCInOctets, ifHCOutOctets, ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors, ifMtu, ifInUcastPkts, ifInMulticastPkts, ifInBroadcastPkts, ifInDiscards, ifOutUcastPkts, ifOutMulticastPkts, McCloghrie & Kastenholz Standards Track [Page 53] RFC 2863 The Interfaces Group MIB June 2000 ifOutBroadcastPkts, ifOutDiscards, ifPromiscuousMode } STATUS current DESCRIPTION "A collection of objects providing information specific to higher speed (greater than 650,000,000 bits/second) packet- oriented network interfaces." ::= { ifGroups 6 } ifRcvAddressGroup OBJECT-GROUP OBJECTS { ifRcvAddressStatus, ifRcvAddressType } STATUS current DESCRIPTION "A collection of objects providing information on the multiple addresses which an interface receives." ::= { ifGroups 7 } ifStackGroup2 OBJECT-GROUP OBJECTS { ifStackStatus, ifStackLastChange } STATUS current DESCRIPTION "A collection of objects providing information on the layering of MIB-II interfaces." ::= { ifGroups 11 } ifCounterDiscontinuityGroup OBJECT-GROUP OBJECTS { ifCounterDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects providing information specific to interface counter discontinuities." ::= { ifGroups 13 } linkUpDownNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { linkUp, linkDown } STATUS current DESCRIPTION "The notifications which indicate specific changes in the value of ifOperStatus." ::= { ifGroups 14 } -- Deprecated Definitions - Objects -- -- The Interface Test Table -- -- This group of objects is optional. However, a media-specific McCloghrie & Kastenholz Standards Track [Page 54] RFC 2863 The Interfaces Group MIB June 2000 -- MIB may make implementation of this group mandatory. -- -- This table replaces the ifExtnsTestTable -- ifTestTable OBJECT-TYPE SYNTAX SEQUENCE OF IfTestEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table contains one entry per interface. It defines objects which allow a network manager to instruct an agent to test an interface for various faults. Tests for an interface are defined in the media-specific MIB for that interface. After invoking a test, the object ifTestResult can be read to determine the outcome. If an agent can not perform the test, ifTestResult is set to so indicate. The object ifTestCode can be used to provide further test- specific or interface-specific (or even enterprise-specific) information concerning the outcome of the test. Only one test can be in progress on each interface at any one time. If one test is in progress when another test is invoked, the second test is rejected. Some agents may reject a test when a prior test is active on another interface. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the ifTestTable for the interface to be tested. This is accomplished with the ifTestId and ifTestStatus objects as follows: try_again: get (ifTestId, ifTestStatus) while (ifTestStatus != notInUse) /* * Loop while a test is running or some other * manager is configuring a test. */ short delay get (ifTestId, ifTestStatus) } /* * Is not being used right now -- let's compete * to see who gets it. */ lock_value = ifTestId if ( set(ifTestId = lock_value, ifTestStatus = inUse, McCloghrie & Kastenholz Standards Track [Page 55] RFC 2863 The Interfaces Group MIB June 2000 ifTestOwner = 'my-IP-address') == FAILURE) /* * Another manager got the ifTestEntry -- go * try again */ goto try_again; /* * I have the lock */ set up any test parameters. /* * This starts the test */ set(ifTestType = test_to_run); wait for test completion by polling ifTestResult when test completes, agent sets ifTestResult agent also sets ifTestStatus = 'notInUse' retrieve any additional test results, and ifTestId if (ifTestId == lock_value+1) results are valid A manager station first retrieves the value of the appropriate ifTestId and ifTestStatus objects, periodically repeating the retrieval if necessary, until the value of ifTestStatus is 'notInUse'. The manager station then tries to set the same ifTestId object to the value it just retrieved, the same ifTestStatus object to 'inUse', and the corresponding ifTestOwner object to a value indicating itself. If the set operation succeeds then the manager has obtained ownership of the ifTestEntry, and the value of the ifTestId object is incremented by the agent (per the semantics of TestAndIncr). Failure of the set operation indicates that some other manager has obtained ownership of the ifTestEntry. Once ownership is obtained, any test parameters can be setup, and then the test is initiated by setting ifTestType. On completion of the test, the agent sets ifTestStatus to 'notInUse'. Once this occurs, the manager can retrieve the results. In the (rare) event that the invocation of tests by two network managers were to overlap, then there would be a possibility that the first test's results might be overwritten by the second test's results prior to the first McCloghrie & Kastenholz Standards Track [Page 56] RFC 2863 The Interfaces Group MIB June 2000 results being read. This unlikely circumstance can be detected by a network manager retrieving ifTestId at the same time as retrieving the test results, and ensuring that the results are for the desired request. If ifTestType is not set within an abnormally long period of time after ownership is obtained, the agent should time-out the manager, and reset the value of the ifTestStatus object back to 'notInUse'. It is suggested that this time-out period be 5 minutes. In general, a management station must not retransmit a request to invoke a test for which it does not receive a response; instead, it properly inspects an agent's MIB to determine if the invocation was successful. Only if the invocation was unsuccessful, is the invocation request retransmitted. Some tests may require the interface to be taken off-line in order to execute them, or may even require the agent to reboot after completion of the test. In these circumstances, communication with the management station invoking the test may be lost until after completion of the test. An agent is not required to support such tests. However, if such tests are supported, then the agent should make every effort to transmit a response to the request which invoked the test prior to losing communication. When the agent is restored to normal service, the results of the test are properly made available in the appropriate objects. Note that this requires that the ifIndex value assigned to an interface must be unchanged even if the test causes a reboot. An agent must reject any test for which it cannot, perhaps due to resource constraints, make available at least the minimum amount of information after that test completes." ::= { ifMIBObjects 3 } ifTestEntry OBJECT-TYPE SYNTAX IfTestEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry containing objects for invoking tests on an interface." AUGMENTS { ifEntry } ::= { ifTestTable 1 } IfTestEntry ::= McCloghrie & Kastenholz Standards Track [Page 57] RFC 2863 The Interfaces Group MIB June 2000 SEQUENCE { ifTestId TestAndIncr, ifTestStatus INTEGER, ifTestType AutonomousType, ifTestResult INTEGER, ifTestCode OBJECT IDENTIFIER, ifTestOwner OwnerString } ifTestId OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS deprecated DESCRIPTION "This object identifies the current invocation of the interface's test." ::= { ifTestEntry 1 } ifTestStatus OBJECT-TYPE SYNTAX INTEGER { notInUse(1), inUse(2) } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "This object indicates whether or not some manager currently has the necessary 'ownership' required to invoke a test on this interface. A write to this object is only successful when it changes its value from 'notInUse(1)' to 'inUse(2)'. After completion of a test, the agent resets the value back to 'notInUse(1)'." ::= { ifTestEntry 2 } ifTestType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-write STATUS deprecated DESCRIPTION "A control variable used to start and stop operator- initiated interface tests. Most OBJECT IDENTIFIER values assigned to tests are defined elsewhere, in association with specific types of interface. However, this document assigns a value for a full-duplex loopback test, and defines the special meanings of the subject identifier: noTest OBJECT IDENTIFIER ::= { 0 0 } When the value noTest is written to this object, no action is taken unless a test is in progress, in which case the test is aborted. Writing any other value to this object is McCloghrie & Kastenholz Standards Track [Page 58] RFC 2863 The Interfaces Group MIB June 2000 only valid when no test is currently in progress, in which case the indicated test is initiated. When read, this object always returns the most recent value that ifTestType was set to. If it has not been set since the last initialization of the network management subsystem on the agent, a value of noTest is returned." ::= { ifTestEntry 3 } ifTestResult OBJECT-TYPE SYNTAX INTEGER { none(1), -- no test yet requested success(2), inProgress(3), notSupported(4), unAbleToRun(5), -- due to state of system aborted(6), failed(7) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object contains the result of the most recently requested test, or the value none(1) if no tests have been requested since the last reset. Note that this facility provides no provision for saving the results of one test when starting another, as could be required if used by multiple managers concurrently." ::= { ifTestEntry 4 } ifTestCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object contains a code which contains more specific information on the test result, for example an error-code after a failed test. Error codes and other values this object may take are specific to the type of interface and/or test. The value may have the semantics of either the AutonomousType or InstancePointer textual conventions as defined in RFC 2579. The identifier: testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } is defined for use if no additional result code is available." ::= { ifTestEntry 5 } McCloghrie & Kastenholz Standards Track [Page 59] RFC 2863 The Interfaces Group MIB June 2000 ifTestOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The entity which currently has the 'ownership' required to invoke a test on this interface." ::= { ifTestEntry 6 } -- Deprecated Definitions - Groups ifGeneralGroup OBJECT-GROUP OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress, ifAdminStatus, ifOperStatus, ifLastChange, ifLinkUpDownTrapEnable, ifConnectorPresent, ifHighSpeed, ifName } STATUS deprecated DESCRIPTION "A collection of objects deprecated in favour of ifGeneralInformationGroup." ::= { ifGroups 1 } ifTestGroup OBJECT-GROUP OBJECTS { ifTestId, ifTestStatus, ifTestType, ifTestResult, ifTestCode, ifTestOwner } STATUS deprecated DESCRIPTION "A collection of objects providing the ability to invoke tests on an interface." ::= { ifGroups 8 } ifStackGroup OBJECT-GROUP OBJECTS { ifStackStatus } STATUS deprecated DESCRIPTION "The previous collection of objects providing information on the layering of MIB-II interfaces." ::= { ifGroups 9 } ifOldObjectsGroup OBJECT-GROUP OBJECTS { ifInNUcastPkts, ifOutNUcastPkts, ifOutQLen, ifSpecific } STATUS deprecated DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 60] RFC 2863 The Interfaces Group MIB June 2000 "The collection of objects deprecated from the original MIB- II interfaces group." ::= { ifGroups 12 } -- Deprecated Definitions - Compliance ifCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "A compliance statement defined in a previous version of this MIB module, for SNMP entities which have network interfaces." MODULE -- this module MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup } GROUP ifFixedLengthGroup DESCRIPTION "This group is mandatory for all network interfaces which are character-oriented or transmit data in fixed-length transmission units." GROUP ifHCFixedLengthGroup DESCRIPTION "This group is mandatory only for those network interfaces which are character-oriented or transmit data in fixed- length transmission units, and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second." GROUP ifPacketGroup DESCRIPTION "This group is mandatory for all network interfaces which are packet-oriented." GROUP ifHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 650,000,000 bits/second." GROUP ifTestGroup DESCRIPTION "This group is optional. Media-specific MIBs which require interface tests are strongly encouraged to use this group for invoking tests and reporting results. A medium specific MIB which has mandatory tests may make implementation of McCloghrie & Kastenholz Standards Track [Page 61] RFC 2863 The Interfaces Group MIB June 2000 this group mandatory." GROUP ifRcvAddressGroup DESCRIPTION "The applicability of this group MUST be defined by the media-specific MIBs. Media-specific MIBs must define the exact meaning, use, and semantics of the addresses in this group." OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ifStackStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ifAdminStatus SYNTAX INTEGER { up(1), down(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, nor is support for the value testing(3)." ::= { ifCompliances 1 } ifCompliance2 MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "A compliance statement defined in a previous version of this MIB module, for SNMP entities which have network interfaces." MODULE -- this module MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2, ifCounterDiscontinuityGroup } GROUP ifFixedLengthGroup DESCRIPTION McCloghrie & Kastenholz Standards Track [Page 62] RFC 2863 The Interfaces Group MIB June 2000 "This group is mandatory for all network interfaces which are character-oriented or transmit data in fixed-length transmission units." GROUP ifHCFixedLengthGroup DESCRIPTION "This group is mandatory only for those network interfaces which are character-oriented or transmit data in fixed- length transmission units, and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second." GROUP ifPacketGroup DESCRIPTION "This group is mandatory for all network interfaces which are packet-oriented." GROUP ifHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 650,000,000 bits/second." GROUP ifRcvAddressGroup DESCRIPTION "The applicability of this group MUST be defined by the media-specific MIBs. Media-specific MIBs must define the exact meaning, use, and semantics of the addresses in this group." OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ifStackStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." McCloghrie & Kastenholz Standards Track [Page 63] RFC 2863 The Interfaces Group MIB June 2000 OBJECT ifAdminStatus SYNTAX INTEGER { up(1), down(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, nor is support for the value testing(3)." OBJECT ifAlias MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { ifCompliances 2 } END 7. Acknowledgements This memo has been produced by the IETF's Interfaces MIB working- group. The original proposal evolved from conversations and discussions with many people, including at least the following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and Dean Throop. 8. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. McCloghrie & Kastenholz Standards Track [Page 64] RFC 2863 The Interfaces Group MIB June 2000 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, January 1998. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SMPv3 Applications", RFC 2573, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, January 1998. [16] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [17] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", STD 17. RFC 1213, March 1991. [18] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [19] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, May 1991. McCloghrie & Kastenholz Standards Track [Page 65] RFC 2863 The Interfaces Group MIB June 2000 [20] ATM Forum Technical Committee, "LAN Emulation Client Management: Version 1.0 Specification", af-lane-0044.000, ATM Forum, September 1995. [21] Stewart, B., "Definitions of Managed Objects for Character Stream Devices using SMIv2", RFC 1658, July 1994. [22] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [23] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994. [24] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. 9. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. In particular, write-able objects allow an administrator to control the interfaces and to perform tests on the interfaces, and unauthorized access to these could cause a denial of service, or in combination with other (e.g., physical) security breaches, could cause unauthorized connectivity to a device. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View- based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. McCloghrie & Kastenholz Standards Track [Page 66] RFC 2863 The Interfaces Group MIB June 2000 10. Authors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-5260 EMail: kzm@cisco.com" Frank Kastenholz Argon Networks 25 Porter Rd Littleton Ma 01460 Phone: (508)685-4000 EMail: kasten@argon.com 11. Changes from RFC 2233 Added linkUpDownNotificationsGroup. Changed the status of the definition of OwnerString in this MIB to be deprecated, because it is only used by ifTestOwner, which is now deprecated, and because other MIBs should import OwnerString from RFC 1757 or its successors. Added ifCompliance3 as a replacement for ifCompliance2 to omit the ifStackGroup2 group, and add linkUpDownNotificationsGroup. Also, corrected the omission of ifVHCPacketGroup, and typos in the DESCRIPTIONs of ifHCPacketGroup and ifFixedLengthGroup. Obsoleted ifCompliance2. Modified syntax of ifStackHigherLayer and ifStackLowerLayer to be InterfaceIndexOrZero. Added requirement that media-specific MIB designers specify any special conditions concerning the counting of framing characters in ifInOctets and ifOutOctets. Corrected a typo in the DESCRIPTION of the linkUp notification. Modified the introductory SNMP Network Management Framework boilerplate text. McCloghrie & Kastenholz Standards Track [Page 67] RFC 2863 The Interfaces Group MIB June 2000 12. Notice on Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. McCloghrie & Kastenholz Standards Track [Page 68] RFC 2863 The Interfaces Group MIB June 2000 13. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McCloghrie & Kastenholz Standards Track [Page 69] snmp-mibs-downloader-1.1/mibrfcs/rfc2864.txt0000644000000000000000000005170511402176071015575 0ustar Network Working Group K. McCloghrie Request for Comments: 2864 Cisco Systems Category: Standards Track G. Hanson ADC Telecommunications June 2000 The Inverted Stack Table Extension to the Interfaces Group MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Table of Contents 1 Introduction .................................................. 1 2 The SNMP Network Management Framework ......................... 1 3 Interface Sub-Layers and the ifStackTable ..................... 3 4 Definitions ................................................... 4 5 Acknowledgements .............................................. 7 6 References .................................................... 7 7 Security Considerations ....................................... 8 8 Authors' Addresses ............................................ 9 9 Notice on Intellectual Property ............................... 10 10 Full Copyright Statement ..................................... 11 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: McCloghrie & Hanson Standards Track [Page 1] RFC 2864 Inverted Stack Extension MIB June 2000 o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, which consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [18]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. McCloghrie & Hanson Standards Track [Page 2] RFC 2864 Inverted Stack Extension MIB June 2000 3. Interface Sub-Layers and the ifStackTable MIB-II [16] defines objects for managing network interfaces by providing a generic interface definition together with the ability to define media-specific extensions. The generic objects are known as the 'interfaces' group. Experience in defining media-specific extensions showed the need to distinguish between the multiple sub-layers beneath the internetwork-layer. Consider, for example, an interface with PPP running over an HDLC link which uses a RS232-like connector. Each of these sub-layers has its own media-specific MIB module. The latest definition of the 'interfaces' group in the IF-MIB [17] satisfies this need by having each sub-layer be represented by its own conceptual row in the ifTable. It also defines an additional MIB table, the ifStackTable, to identify the "superior" and "subordinate" sub-layers through ifIndex "pointers" to the appropriate conceptual rows in the ifTable. Each conceptual row in the ifStackTable represents a relationship between two interfaces, where this relationship is that the "higher- layer" interface runs "on top" of the "lower-layer" interface. For example, if a PPP module operated directly over a serial interface, the PPP module would be a "higher layer" to the serial interface, and the serial interface would be a "lower layer" to the PPP module. This concept of "higher-layer" and "lower-layer" is the same as embodied in the definitions of the ifTable's packet counters. The ifStackTable is INDEX-ed by the ifIndex values of the two interfaces involved in the relationship. By necessity, one of these ifIndex values must come first, and the IF-MIB chose to have the higher-layer interface first, and the lower-layer interface second. Due to this, it is straight-forward for a Network Management application to read a subset of the ifStackTable and thereby determine the interfaces which run underneath a particular interface. However, to determine which interfaces run on top of a particular interface, a Network Management application has no alternative but to read the whole table. This is very inefficient when querying a device which has many interfaces, and many conceptual rows in its ifStackTable. This MIB provides an inverted Interfaces Stack Table, the ifInvStackTable. While it contains no additional information beyond that already contained in the ifStackTable, the ifInvStackTable has the ifIndex values in its INDEX clause in the reverse order, i.e., the lower-layer interface first, and the higher-layer interface second. As a result, the ifInvStackTable is an inverted version of McCloghrie & Hanson Standards Track [Page 3] RFC 2864 Inverted Stack Extension MIB June 2000 the same information contained in the ifStackTable. Thus, the ifInvStackTable provides an efficient means for a Network Management application to read a subset of the ifStackTable and thereby determine which interfaces run on top of a particular interface. 4. Definitions IF-INVERTED-STACK-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifStackGroup2, ifStackHigherLayer, ifStackLowerLayer FROM IF-MIB; ifInvertedStackMIB MODULE-IDENTITY LAST-UPDATED "200006140000Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO " Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US 408-526-5260 kzm@cisco.com" DESCRIPTION "The MIB module which provides the Inverted Stack Table for interface sub-layers." REVISION "200006140000Z" DESCRIPTION "Initial revision, published as RFC 2864" ::= { mib-2 77 } ifInvMIBObjects OBJECT IDENTIFIER ::= { ifInvertedStackMIB 1 } -- -- The Inverted Interface Stack Group -- ifInvStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfInvStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information on the relationships between McCloghrie & Hanson Standards Track [Page 4] RFC 2864 Inverted Stack Extension MIB June 2000 the multiple sub-layers of network interfaces. In particular, it contains information on which sub-layers run 'underneath' which other sub-layers, where each sub-layer corresponds to a conceptual row in the ifTable. For example, when the sub-layer with ifIndex value x runs underneath the sub-layer with ifIndex value y, then this table contains: ifInvStackStatus.x.y=active For each ifIndex value, z, which identifies an active interface, there are always at least two instantiated rows in this table associated with z. For one of these rows, z is the value of ifStackHigherLayer; for the other, z is the value of ifStackLowerLayer. (If z is not involved in multiplexing, then these are the only two rows associated with z.) For example, two rows exist even for an interface which has no others stacked on top or below it: ifInvStackStatus.z.0=active ifInvStackStatus.0.z=active This table contains exactly the same number of rows as the ifStackTable, but the rows appear in a different order." REFERENCE "ifStackTable of RFC 2863" ::= { ifInvMIBObjects 1 } ifInvStackEntry OBJECT-TYPE SYNTAX IfInvStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular relationship between two sub- layers, specifying that one sub-layer runs underneath the other sub-layer. Each sub-layer corresponds to a conceptual row in the ifTable." INDEX { ifStackLowerLayer, ifStackHigherLayer } ::= { ifInvStackTable 1 } IfInvStackEntry ::= SEQUENCE { ifInvStackStatus RowStatus } ifInvStackStatus OBJECT-TYPE McCloghrie & Hanson Standards Track [Page 5] RFC 2864 Inverted Stack Extension MIB June 2000 SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the relationship between two sub-layers. An instance of this object exists for each instance of the ifStackStatus object, and vice versa. For example, if the variable ifStackStatus.H.L exists, then the variable ifInvStackStatus.L.H must also exist, and vice versa. In addition, the two variables always have the same value. However, unlike ifStackStatus, the ifInvStackStatus object is NOT write-able. A network management application wishing to change a relationship between sub-layers H and L cannot do so by modifying the value of ifInvStackStatus.L.H, but must instead modify the value of ifStackStatus.H.L. After the ifStackTable is modified, the change will be reflected in this table." ::= { ifInvStackEntry 1 } -- conformance information ifInvConformance OBJECT IDENTIFIER ::= { ifInvMIBObjects 2 } ifInvGroups OBJECT IDENTIFIER ::= { ifInvConformance 1 } ifInvCompliances OBJECT IDENTIFIER ::= { ifInvConformance 2 } -- compliance statements ifInvCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which provide inverted information on the layering of network interfaces." MODULE -- this module MANDATORY-GROUPS { ifInvStackGroup } OBJECT ifInvStackStatus SYNTAX INTEGER { active(1) } DESCRIPTION "Support is only required for 'active'." McCloghrie & Hanson Standards Track [Page 6] RFC 2864 Inverted Stack Extension MIB June 2000 MODULE IF-MIB MANDATORY-GROUPS { ifStackGroup2 } ::= { ifInvCompliances 1 } -- units of conformance ifInvStackGroup OBJECT-GROUP OBJECTS { ifInvStackStatus } STATUS current DESCRIPTION "A collection of objects providing inverted information on the layering of MIB-II interfaces." ::= { ifInvGroups 1 } END 5. Acknowledgements This memo has been produced by the IETF's Interfaces MIB working- group. 6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, January 1998. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. McCloghrie & Hanson Standards Track [Page 7] RFC 2864 Inverted Stack Extension MIB June 2000 [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, January 1998. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, January 1998. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, January 1998. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, January 1998. [16] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", STD 17, RFC 1213, March 1991. [17] McCloghrie, K. and F. Kastenholz, "The Interface Group MIB", RFC 2863, June 2000. [18] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. 7. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. McCloghrie & Hanson Standards Track [Page 8] RFC 2864 Inverted Stack Extension MIB June 2000 SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View- based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. Authors' Addresses Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 408-526-5260 EMail: kzm@cisco.com Gary Hanson ADC Telecommunications 14375 NW Science Park Drive Portland, Oregon, 97229 Phone: (800)733-5511 x6333 EMail: gary_hanson@adc.com McCloghrie & Hanson Standards Track [Page 9] RFC 2864 Inverted Stack Extension MIB June 2000 9. Notice on Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. McCloghrie & Hanson Standards Track [Page 10] RFC 2864 Inverted Stack Extension MIB June 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McCloghrie & Hanson Standards Track [Page 11] snmp-mibs-downloader-1.1/mibrfcs/rfc2922.txt0000644000000000000000000020241611402176071015565 0ustar Network Working Group A. Bierman Request for Comments: 2922 Cisco Systems, Inc. Category: Informational K. Jones Nortel Networks September 2000 Physical Topology MIB Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. Table of Contents 1 The SNMP Network Management Framework ............................2 2 Overview .........................................................3 2.1 Terms ..........................................................3 2.2 Design Goals ...................................................5 3 Topology Framework ...............................................6 3.1 Devices and Topology Agents ....................................6 3.2 Topology Mechanisms ............................................7 3.3 Future Considerations ..........................................7 4 Physical Topology MIB ............................................7 4.1 Persistent Identifiers .........................................8 4.2 Relationship to Entity MIB .....................................8 4.3 Relationship to Interfaces MIB .................................9 4.4 Relationship to RMON-2 MIB .....................................9 4.5 Relationship to Bridge MIB .....................................9 4.6 Relationship to Repeater MIB ...................................9 4.7 MIB Structure .................................................10 4.7.1 ptopoData Group .............................................10 4.7.2 ptopoGeneral Group ..........................................10 4.7.3 ptopoConfig Group ...........................................10 4.8 Physical Topology MIB Definitions .............................10 Bierman & Jones Informational [Page 1] RFC 2922 Physical Topology MIB September 2000 5 Intellectual Property ...........................................27 6 Acknowledgements ................................................28 7 References ......................................................28 8 Security Considerations .........................................30 9 Authors' Addresses ..............................................31 10 Full Copyright Statement .......................................32 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Bierman & Jones Informational [Page 2] RFC 2922 Physical Topology MIB September 2000 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview There is a need for a standardized means of representing the physical network connections pertaining to a given management domain. The Physical Topology MIB (PTOPO-MIB) provides a standard way to identify connections between network ports and to discover network addresses of SNMP agents containing management information associated with each port. A topology mechanism is used to discover the information required by the PTOPO-MIB. There is a need for a standardized topology mechanism to increase the likelihood of multi-vendor interoperability of such physical topology management information. The PTOPO-MIB does not, however, specify or restrict the discovery mechanism(s) used for an implementation of the PTOPO-MIB. Topology mechanisms exist for certain media types (such as FDDI) and proprietary mechanisms exist for other media such as shared media Ethernet, switched Ethernet, and Token Ring. Rather than specifying mechanisms for each type of technology, the PTOPO-MIB allows co-existence of multiple topology mechanisms. The required objects of the PTOPO-MIB define the core requirements for any topology mechanism. The scope of the physical topology (PTOPO) mechanism is the identification of connections between two network ports. Network addresses of SNMP agents containing management information associated with each port can also be identified. 2.1. Terms Some terms are used throughout this document: Physical Topology Physical topology represents the topology model for layer 1 of the OSI stack - the physical layer. Physical topology consists of identifying the devices on the network and how they are physically interconnected. By definition of this document, physical topology does not imply a physical relationship between ports on the same device. Other means exist for Bierman & Jones Informational [Page 3] RFC 2922 Physical Topology MIB September 2000 determining these relationships (e.g., Entity MIB [RFC2737]) exist for determining these relationships. Note that physical topology is independent of logical topology, which associates ports based on higher layer attributes, such as network layer address. Chassis A chassis is a physical component which contains other physical components. It is identified by an entPhysicalEntry with an entPhysicalClass value of 'chassis(3)' and an entPhysicalContainedIn value of zero. A chassis identifier consists of a globally unique SnmpAdminString. Local Chassis The particular chassis containing the SNMP agent implementing the PTOPO MIB. Port A port is a physical component which can be connected to another port through some medium. It is identified by an entPhysicalEntry with an entPhysicalClass value of 'port(10)'. A port identifier consists of an SnmpAdminString which must be unique within the context of the chassis which contains the port. Connection Endpoint A connection endpoint consists of a physical port, which is contained within a single physical chassis. Connection Endpoint Identifier A connection endpoint is identified by a globally unique chassis identifier and a port identifier unique within the associated chassis. Connection A connection consists of two physical ports, and the attached physical medium, configured for the purpose of transferring network traffic between the ports. A connection is identified by its endpoint identifiers. Non-local Connection A connection for which neither endpoint is located on the local chassis. Bierman & Jones Informational [Page 4] RFC 2922 Physical Topology MIB September 2000 Cloud A cloud identifies a portion of the topology for which insufficient information is known to completely infer the interconnection of devices that make up that portion of the topology. 2.2. Design Goals Several factors influenced the design of this physical topology function: - Simplicity The physical topology discovery function should be as simple as possible, exposing only the information needed to identify connection endpoints and the SNMP agent(s) associated with each connection endpoint. - Completeness At least one standard discovery protocol capable of supporting the standard physical topology MIB must be defined. Multi- vendor interoperability will not be achievable unless a simple and extensible discovery protocol is available. However, the PTOPO MIB should not specify or restrict the topology discovery mechanisms an agent can use. - No Functional Overlap Existing standard MIBs should be utilized whenever possible. Physical topology information is tightly coupled to functionality found in the Interfaces MIB [RFC2233] and Entity MIB [RFC2737]. New physical topology MIB objects should not duplicate these MIBs. - Identifier Stability Connection endpoint identifiers must be persistent (i.e. stable across device reboots). Dynamic primary key objects like ifIndex and entPhysicalIndex are not suitable for table indices in a physical topology MIB that is replicated and distributed throughout a managed system. - Identifier Flexibility Persistent string-based component identifiers should be supported from many sources. Chassis identifiers may be found in the Entity MIB [RFC2737], and port identifiers may be found in the Interfaces MIB [RFC2233] or Entity MIB [RFC2737]. Bierman & Jones Informational [Page 5] RFC 2922 Physical Topology MIB September 2000 - Partial Topology Support Physical topology data for remote components may only be partially available to an agent. An enumerated INTEGER hierarchy of component identifier types allows for incomplete physical connection identifier information to be substituted with secondary information such as unicast source MAC address or network address associated with a particular port. A PTOPO Agent maintains information derived from the 'best' source of information for each connection. If a 'better' identifier source is detected, the PTOPO entries are updated accordingly. It is an implementation specific matter whether a PTOPO agent replaces 'old' entries or retains them, however an agent must remove information known to be incorrect. - Low Polling Impact Physical topology polling should be minimized through techniques such as TimeFiltered data tables (from RMON-2 [RFC2021]), and last-change notifications. 3. Topology Framework This section describes the physical topology framework in detail. 3.1. Devices and Topology Agents The network devices, along with their physical connectivity, make up the physical topology. Some of these devices (but maybe not all) provide management agents that report their local physical topology information to a manager via the physical topology MIB. These devices include communication infrastructure devices, such as hubs, switches, and routers, as well as 'leaf' devices such as workstations, printers, and servers. Generally, user data passes through infrastructure devices while leaf devices are sources and sinks of data. Both types of devices may implement the physical topology MIB, although implementation within leaf devices is much less critical. Each managed device collects physical topology information from the network, based on the topology mechanism(s) it is configured to use. The data represents this agent's local view of the physical network. Part of the topology data collected must include the identification of other local agents which may contain additional topology information. The definition of 'local' varies based on the topology mechanism or mechanisms being used. Bierman & Jones Informational [Page 6] RFC 2922 Physical Topology MIB September 2000 3.2. Topology Mechanisms A topology mechanism is a means, possibly requiring some sort of protocol, by which devices determine topology information. The topology mechanism must provide sufficient information to populate the MIB described later in this document. Topology mechanisms can be active or passive. Active mechanisms require a device to send and receive topology protocol packets. These packets provide the device ID of the source of the packet and may also indicate out which port the packet was transmitted. When receiving these packets, devices typically are required to identify on which port that packet was received. Passive mechanisms take advantage of data on the network to populate the topology MIB. By maintaining a list of device identifiers seen on each port of all devices in a network, it is possible to populate the PTOPO-MIB. Many instances of a particular topology mechanism may be in use on a given network, and many different mechanisms may be employed. In some cases, multiple mechanisms may overlap across part of the physical topology with individual ports supporting more than one topology mechanism. In general, this simply allows the port to collect more robust topology information. Agents may need to be configured so that they know which mechanism(s) are in use on any given portion of the network. Most topology mechanisms need to be bounded to a subset of the network to contain their impact on the network and limit the size of topology tables maintained by the agent. Topology mechanisms are often naturally bounded by the media on which they run (e.g. FDDI topology mechanism) or by routers in the network that intentionally block the mechanism from crossing into other parts of the network. 3.3. Future Considerations While the framework presented here is focused on physical topology, it may well be that the topology mechanisms and MIB described could be extended to include logical topology information as well. That is not a focus of this memo. 4. Physical Topology MIB This section describes and defines the Physical Topology MIB. Bierman & Jones Informational [Page 7] RFC 2922 Physical Topology MIB September 2000 4.1. Persistent Identifiers The PTOPO MIB utilizes non-volatile identifiers to distinguish individual chassis and port components. These identifiers are associated with external objects in order to relate topology information to the existing managed objects. In particular, an object from the Entity MIB [RFC2737] or Interfaces MIB [RFC2233] can be used as the 'reference-point' for a connection component identifier. The Physical Topology MIB uses two identifier types pertaining to the PTOPO MIB: - globally unique chassis identifiers. - port identifiers; unique only within the chassis which contains the port. Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes in length, This supports flexible naming conventions and constrains the non-volatile storage requirements for an agent. 4.2. Relationship to Entity MIB The first version of the Entity MIB [RFC2037] allows the physical component inventory and hierarchy to be identified. However, this MIB does not provide persistent component identifiers, which are required for the PTOPO MIB. Therefore, version 2 of the Entity MIB [RFC2737] is required to support that feature. Specifically, the entPhysicalAlias object is utilized as a persistent chassis identifier. For agents implementing the PTOPO MIB, this new object must be used to represent the chassis identifier. Port identifiers can be based on the entPhysicalAlias object associated with the port, but only if the port is not represented as an interface in the ifXTable. Implementation of the entPhysicalGroup [RFC2737] and the entPhysicalAlias object [RFC2737] are mandatory for SNMP agents which implement the PTOPO MIB. No other objects must be implemented from these MIBs to support the physical topology function. Bierman & Jones Informational [Page 8] RFC 2922 Physical Topology MIB September 2000 4.3. Relationship to Interfaces MIB The PTOPO MIB requires a persistent identifier for each port. The Interfaces MIB [RFC2233] provides a standard mechanism for managing network interfaces. Unfortunately, not all ports which may be represented in the PTOPO MIB are also represented in the Interfaces MIB (e.g., repeater ports). For agents which implement the PTOPO MIB, for each port also represented in the Interfaces MIB, the agent must use the associated ifAlias value for the port identifier. For each port not represented in the Interfaces MIB, the associated entPhysicalAlias value must be used for the port identifier. Note that the PTOPO MIB requires only minimal support from the Interfaces MIB. Specifically, the ' ifGeneralInformationGroup' level of conformance must be provided for each port also identified in the PTOPO MIB. The agent may choose to support these objects with read-only access, as specified in the conformance section of the Interfaces MIB. 4.4. Relationship to RMON-2 MIB The RMON-2 MIB [RFC2021] contains address mapping information which can be integrated with physical topology information. The physical ports identified in a physical topology MIB can be related to the MAC and network layer addresses found in the addressMapTable. 4.5. Relationship to Bridge MIB The Bridge MIB [RFC1493] contains information which may relate to physical ports represented in the ptopoConnTable. Entries in the dot1dBasePortTable and dot1dStpPortTable can by related to physical ports represented in the PTOPO MIB. Also, bridge port MAC addresses may be used as chassis and port identifiers in some situations. 4.6. Relationship to Repeater MIB The Repeater MIB [RFC2108] contains information which may relate to physical ports represented in the PTOPO MIB. Entries in the rptrPortTable and rptrMonitorPortTable can by related to physical ports represented in the ptopoConnTable. Entries in the rptrInfoTable and rptrMonTable can be related to repeater backplanes possibly represented in the ptopoConnTable. Bierman & Jones Informational [Page 9] RFC 2922 Physical Topology MIB September 2000 4.7. MIB Structure The PTOPO MIB contains three MIB object groups: - ptopoData Exposes physical topology data learned from discovery protocols and/or manual configuration. - ptopoGeneral Contains general information regarding PTOPO MIB status. - ptopoConfig Contains configuration variables for the PTOPO MIB agent function. 4.7.1. ptopoData Group This group contains a single table to identity physical topology data. The ptopoConnTable contains information about the connections learned or configured on behalf of the PTOPO MIB SNMP Agent. 4.7.2. ptopoGeneral Group This group contains some scalar objects to report the status of the PTOPO MIB information currently known to the SNMP Agent. The global last change time, and table add and delete counters allow an NMS to set threshold alarms to trigger PTOPO polling. 4.7.3. ptopoConfig Group This group contains tables to configure the behavior of the physical topology function. The transmission of ptopoLastChange notifications can be configured using the ptopoConfigTrapInterval scalar MIB object. 4.8. Physical Topology MIB Definitions PTOPO-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Counter32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP Bierman & Jones Informational [Page 10] RFC 2922 Physical Topology MIB September 2000 FROM SNMPv2-CONF TimeFilter FROM RMON2-MIB PhysicalIndex FROM ENTITY-MIB AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB; ptopoMIB MODULE-IDENTITY LAST-UPDATED "200009210000Z" ORGANIZATION "IETF; PTOPOMIB Working Group" CONTACT-INFO "PTOPOMIB WG Discussion: ptopo@3com.com Subscription: majordomo@3com.com msg body: [un]subscribe ptopomib Andy Bierman Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 408-527-3711 abierman@cisco.com Kendall S. Jones Nortel Networks 4401 Great America Parkway Santa Clara, CA 95054 408-495-7356 kejones@nortelnetworks.com" DESCRIPTION "The MIB module for physical topology information." REVISION "200009210000Z" DESCRIPTION "Initial Version of the Physical Topology MIB. This version published as RFC 2922." ::= { mib-2 79 } ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } -- MIB groups ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } -- textual conventions Bierman & Jones Informational [Page 11] RFC 2922 Physical Topology MIB September 2000 PtopoGenAddr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of an address." SYNTAX OCTET STRING (SIZE (0..20)) PtopoChassisIdType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes the source of a chassis identifier. The enumeration 'chasIdEntPhysicalAlias(1)' represents a chassis identifier based on the value of entPhysicalAlias for a chassis component (i.e., an entPhysicalClass value of 'chassis(3)'). The enumeration 'chasIdIfAlias(2)' represents a chassis identifier based on the value of ifAlias for an interface on the containing chassis. The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a chassis identifier based on the value of entPhysicalAlias for a port or backplane component (i.e., entPhysicalClass value of 'port(10)' or 'backplane(4)'), within the containing chassis. The enumeration 'chasIdMacAddress(4)' represents a chassis identifier based on the value of a unicast source MAC address (encoded in network byte order and IEEE 802.3 canonical bit order), of a port on the containing chassis. The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis identifier based on a network address, associated with a particular chassis. The encoded address is actually composed of two fields. The first field is a single octet, representing the IANA AddressFamilyNumbers value for the specific address type, and the second field is the PtopoGenAddr address value." SYNTAX INTEGER { chasIdEntPhysicalAlias(1), chasIdIfAlias(2), chasIdPortEntPhysicalAlias(3), chasIdMacAddress(4), chasIdPtopoGenAddr(5) } PtopoChassisId ::= TEXTUAL-CONVENTION STATUS current Bierman & Jones Informational [Page 12] RFC 2922 Physical Topology MIB September 2000 DESCRIPTION "This TC describes the format of a chassis identifier string. Objects of this type are always used with an associated PtopoChassisIdType object, which identifies the format of the particular PtopoChassisId object instance. If the associated PtopoChassisIdType object has a value of 'chasIdEntPhysicalAlias(1)', then the octet string identifies a particular instance of the entPhysicalAlias object for a chassis component (i.e., an entPhysicalClass value of 'chassis(3)'). If the associated PtopoChassisIdType object has a value of 'chasIdIfAlias(2)', then the octet string identifies a particular instance of the ifAlias object for an interface on the containing chassis. If the associated PtopoChassisIdType object has a value of 'chasIdPortEntPhysicalAlias(3)', then the octet string identifies a particular instance of the entPhysicalAlias object for a port or backplane component within the containing chassis. If the associated PtopoChassisIdType object has a value of 'chasIdMacAddress(4)', then this string identifies a particular unicast source MAC address (encoded in network byte order and IEEE 802.3 canonical bit order), of a port on the containing chassis. If the associated PtopoChassisIdType object has a value of 'chasIdPtopoGenAddr(5)', then this string identifies a particular network address, encoded in network byte order, associated with one or more ports on the containing chassis. The first octet contains the IANA Address Family Numbers enumeration value for the specific address type, and octets 2 through N contain the PtopoGenAddr address value in network byte order." SYNTAX OCTET STRING (SIZE (1..32)) PtopoPortIdType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes the source of a particular type of port identifier used in the PTOPO MIB. The enumeration 'portIdIfAlias(1)' represents a port identifier based on the ifAlias MIB object. Bierman & Jones Informational [Page 13] RFC 2922 Physical Topology MIB September 2000 The enumeration 'portIdPortEntPhysicalAlias(2)' represents a port identifier based on the value of entPhysicalAlias for a port or backplane component (i.e., entPhysicalClass value of 'port(10)' or 'backplane(4)'), within the containing chassis. The enumeration 'portIdMacAddr(3)' represents a port identifier based on a unicast source MAC address, which has been detected by the agent and associated with a particular port. The enumeration 'portIdPtopoGenAddr(4)' represents a port identifier based on a network address, detected by the agent and associated with a particular port." SYNTAX INTEGER { portIdIfAlias(1), portIdEntPhysicalAlias(2), portIdMacAddr(3), portIdPtopoGenAddr(4) } PtopoPortId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes the format of a port identifier string. Objects of this type are always used with an associated PtopoPortIdType object, which identifies the format of the particular PtopoPortId object instance. If the associated PtopoPortIdType object has a value of 'portIdIfAlias(1)', then the octet string identifies a particular instance of the ifAlias object. If the associated PtopoPortIdType object has a value of 'portIdEntPhysicalAlias(2)', then the octet string identifies a particular instance of the entPhysicalAlias object for a port component (i.e., entPhysicalClass value of 'port(10)'). If the associated PtopoPortIdType object has a value of 'portIdMacAddr(3)', then this string identifies a particular unicast source MAC address associated with the port. If the associated PtopoPortIdType object has a value of 'portIdPtopoGenAddr(4)', then this string identifies a network address associated with the port. The first octet contains the IANA AddressFamilyNumbers enumeration value for the specific address type, and octets 2 through N contain Bierman & Jones Informational [Page 14] RFC 2922 Physical Topology MIB September 2000 the PtopoGenAddr address value in network byte order." SYNTAX OCTET STRING (SIZE (1..32)) PtopoAddrSeenState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes the state of address detection for a particular type of port identifier used in the PTOPO MIB. The enumeration 'notUsed(1)' represents an entry for which the particular MIB object is not applicable to the remote connection endpoint, The enumeration 'unknown(2)' represents an entry for which the particular address collection state is not known. The enumeration 'oneAddr(3)' represents an entry for which exactly one source address (of the type indicated by the particular MIB object), has been detected. The enumeration 'multiAddr(4)' represents an entry for which more than one source address (of the type indicated by the particular MIB object), has been detected. An agent is expected to set the initial state of the PtopoAddrSeenState to 'notUsed(1)' or 'unknown(2)'. Note that the PTOPO MIB does not restrict or specify the means in which the PtopoAddrSeenState is known to an agent. In particular, an agent may detect this information through configuration data, or some means other than directly monitoring all port traffic." SYNTAX INTEGER { notUsed(1), unknown(2), oneAddr(3), multiAddr(4) } -- *********************************************************** -- -- P T O P O D A T A G R O U P -- -- *********************************************************** -- Connection Table Bierman & Jones Informational [Page 15] RFC 2922 Physical Topology MIB September 2000 ptopoConnTable OBJECT-TYPE SYNTAX SEQUENCE OF PtopoConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one or more rows per physical network connection known to this agent. The agent may wish to ensure that only one ptopoConnEntry is present for each local port, or it may choose to maintain multiple ptopoConnEntries for the same local port. Entries based on lower numbered identifier types are preferred over higher numbered identifier types, i.e., lower values of the ptopoConnRemoteChassisType and ptopoConnRemotePortType objects." ::= { ptopoData 1 } ptopoConnEntry OBJECT-TYPE SYNTAX PtopoConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular physical network connection. Entries may be created and deleted in this table, either manually or by the agent, if a physical topology discovery process is active." INDEX { ptopoConnTimeMark, ptopoConnLocalChassis, ptopoConnLocalPort, ptopoConnIndex } ::= { ptopoConnTable 1 } PtopoConnEntry ::= SEQUENCE { ptopoConnTimeMark TimeFilter, ptopoConnLocalChassis PhysicalIndex, ptopoConnLocalPort PhysicalIndex, ptopoConnIndex Integer32, ptopoConnRemoteChassisType PtopoChassisIdType, ptopoConnRemoteChassis PtopoChassisId, ptopoConnRemotePortType PtopoPortIdType, ptopoConnRemotePort PtopoPortId, ptopoConnDiscAlgorithm AutonomousType, ptopoConnAgentNetAddrType AddressFamilyNumbers, ptopoConnAgentNetAddr PtopoGenAddr, ptopoConnMultiMacSASeen PtopoAddrSeenState, ptopoConnMultiNetSASeen PtopoAddrSeenState, Bierman & Jones Informational [Page 16] RFC 2922 Physical Topology MIB September 2000 ptopoConnIsStatic TruthValue, ptopoConnLastVerifyTime TimeStamp, ptopoConnRowStatus RowStatus } ptopoConnTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention in RFC 2021 to see how this works." ::= { ptopoConnEntry 1 } ptopoConnLocalChassis OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entPhysicalIndex value used to identify the chassis component associated with the local connection endpoint." ::= { ptopoConnEntry 2 } ptopoConnLocalPort OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entPhysicalIndex value used to identify the port component associated with the local connection endpoint." ::= { ptopoConnEntry 3 } ptopoConnIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents an arbitrary local integer value used by this agent to identify a particular connection instance, unique only for the indicated local connection endpoint. A particular ptopoConnIndex value may be reused in the event an entry is aged out and later re-learned with the same (or different) remote chassis and port identifiers. An agent is encouraged to assign monotonically increasing index values to new entries, starting with one, after each Bierman & Jones Informational [Page 17] RFC 2922 Physical Topology MIB September 2000 reboot. It is considered unlikely that the ptopoConnIndex will wrap between reboots." ::= { ptopoConnEntry 4 } ptopoConnRemoteChassisType OBJECT-TYPE SYNTAX PtopoChassisIdType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of encoding used to identify the chassis associated with the remote connection endpoint. This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)." ::= { ptopoConnEntry 5 } ptopoConnRemoteChassis OBJECT-TYPE SYNTAX PtopoChassisId MAX-ACCESS read-create STATUS current DESCRIPTION "The string value used to identify the chassis component associated with the remote connection endpoint. This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)." ::= { ptopoConnEntry 6 } ptopoConnRemotePortType OBJECT-TYPE SYNTAX PtopoPortIdType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of port identifier encoding used in the associated 'ptopoConnRemotePort' object. This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)." ::= { ptopoConnEntry 7 } ptopoConnRemotePort OBJECT-TYPE SYNTAX PtopoPortId MAX-ACCESS read-create STATUS current DESCRIPTION "The string value used to identify the port component associated with the remote connection endpoint. Bierman & Jones Informational [Page 18] RFC 2922 Physical Topology MIB September 2000 This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)." ::= { ptopoConnEntry 8 } ptopoConnDiscAlgorithm OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the algorithm used to discover the information contained in this conceptual row. A value of ptopoDiscoveryLocal indicates this entry was configured by the local agent, without use of a discovery protocol. A value of { 0 0 } indicates this entry was created manually by an NMS via the associated RowStatus object. " ::= { ptopoConnEntry 9 } ptopoConnAgentNetAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "This network address type of the associated ptopoConnNetAddr object, unless that object contains a zero length string. In such a case, an NMS application should ignore any returned value for this object. This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)." ::= { ptopoConnEntry 10 } ptopoConnAgentNetAddr OBJECT-TYPE SYNTAX PtopoGenAddr MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies a network address which may be used to reach an SNMP agent entity containing information for the chassis and port components represented by the associated 'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects. If no such address is known, then this object shall contain an empty string. This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)." Bierman & Jones Informational [Page 19] RFC 2922 Physical Topology MIB September 2000 ::= { ptopoConnEntry 11 } ptopoConnMultiMacSASeen OBJECT-TYPE SYNTAX PtopoAddrSeenState MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if multiple unicast source MAC addresses have been detected by the agent from the remote connection endpoint, since the creation of this entry. If this entry has an associated ptopoConnRemoteChassisType and/or ptopoConnRemotePortType value other than 'portIdMacAddr(3)', then the value 'notUsed(1)' is returned. Otherwise, one of the following conditions must be true: If the agent has not yet detected any unicast source MAC addresses from the remote port, then the value 'unknown(2)' is returned. If the agent has detected exactly one unicast source MAC address from the remote port, then the value 'oneAddr(3)' is returned. If the agent has detected more than one unicast source MAC address from the remote port, then the value 'multiAddr(4)' is returned." ::= { ptopoConnEntry 12 } ptopoConnMultiNetSASeen OBJECT-TYPE SYNTAX PtopoAddrSeenState MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if multiple network layer source addresses have been detected by the agent from the remote connection endpoint, since the creation of this entry. If this entry has an associated ptopoConnRemoteChassisType or ptopoConnRemotePortType value other than 'portIdGenAddr(4)' then the value 'notUsed(1)' is returned. Otherwise, one of the following conditions must be true: If the agent has not yet detected any network source addresses of the appropriate type from the remote port, then the value 'unknown(2)' is returned. Bierman & Jones Informational [Page 20] RFC 2922 Physical Topology MIB September 2000 If the agent has detected exactly one network source address of the appropriate type from the remote port, then the value 'oneAddr(3)' is returned. If the agent has detected more than one network source address (of the same appropriate type) from the remote port, this the value 'multiAddr(4)' is returned." ::= { ptopoConnEntry 13 } ptopoConnIsStatic OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies static ptopoConnEntries. If this object has the value 'true(1)', then this entry is not subject to any age-out mechanisms implemented by the agent. If this object has the value 'false(2)', then this entry is subject to all age-out mechanisms implemented by the agent. This object may not be modified if the associated ptopoConnRowStatus object has a value of active(1)." DEFVAL { false } ::= { ptopoConnEntry 14 } ptopoConnLastVerifyTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "If the associated value of ptopoConnIsStatic is equal to 'false(2)', then this object contains the value of sysUpTime at the time the conceptual row was last verified by the agent, e.g., via reception of a topology protocol message, pertaining to the associated remote chassis and port. If the associated value of ptopoConnIsStatic is equal to 'true(1)', then this object shall contain the value of sysUpTime at the time this entry was last activated (i.e., ptopoConnRowStatus set to 'active(1)')." ::= { ptopoConnEntry 15 } ptopoConnRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Bierman & Jones Informational [Page 21] RFC 2922 Physical Topology MIB September 2000 "The status of this conceptual row." ::= { ptopoConnEntry 16 } -- *********************************************************** -- -- P T O P O G E N E R A L G R O U P -- -- *********************************************************** -- last change time stamp for the whole MIB ptopoLastChangeTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time a conceptual row is created, modified, or deleted in the ptopoConnTable. An NMS can use this object to reduce polling of the ptopoData group objects." ::= { ptopoGeneral 1 } ptopoConnTabInserts OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an entry has been inserted into the ptopoConnTable." ::= { ptopoGeneral 2 } ptopoConnTabDeletes OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an entry has been deleted from the ptopoConnTable." ::= { ptopoGeneral 3 } ptopoConnTabDrops OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only Bierman & Jones Informational [Page 22] RFC 2922 Physical Topology MIB September 2000 STATUS current DESCRIPTION "The number of times an entry would have been added to the ptopoConnTable, (e.g., via information learned from a topology protocol), but was not because of insufficient resources." ::= { ptopoGeneral 4 } ptopoConnTabAgeouts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an entry has been deleted from the ptopoConnTable because the information timeliness interval for that entry has expired." ::= { ptopoGeneral 5 } -- *********************************************************** -- -- P T O P O C O N F I G G R O U P -- -- *********************************************************** ptopoConfigTrapInterval OBJECT-TYPE SYNTAX Integer32 (0 | 5..3600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the transmission of PTOPO notifications. If this object has a value of zero, then no ptopoConfigChange notifications will be transmitted by the agent. If this object has a non-zero value, then the agent must not generate more than one ptopoConfigChange trap-event in the indicated period, where a 'trap-event' is the transmission of a single notification PDU type to a list of notification destinations. If additional configuration changes occur within the indicated throttling period, then these trap- events must be suppressed by the agent. An NMS should periodically check the value of ptopoLastChangeTime to detect any missed ptopoConfigChange trap-events, e.g. due to throttling or transmission loss. Bierman & Jones Informational [Page 23] RFC 2922 Physical Topology MIB September 2000 If notification transmission is enabled, the suggested default throttling period is 60 seconds, but transmission should be disabled by default. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 0 } ::= { ptopoConfig 1 } ptopoConfigMaxHoldTime OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the desired time interval for which an agent will maintain dynamic ptopoConnEntries. After the specified number of seconds since the last time an entry was verified, in the absence of new verification (e.g., receipt of a topology protocol message), the agent shall remove the entry. Note that entries may not always be removed immediately, but may possibly be removed at periodic garbage collection intervals. This object only affects dynamic ptopoConnEntries, i.e. for which ptopoConnIsStatic equals 'false(2)'. Static entries are not aged out. Note that dynamic ptopoConnEntries may also be removed by the agent due to the expired timeliness of learned topology information (e.g., timeliness interval for a remote port expires). The actual age-out interval for a given entry is defined by the following formula: age-out-time = min(ptopoConfigMaxHoldTime, ) where is determined by the discovery algorithm, and may be different for each entry." DEFVAL { 300 } ::= { ptopoConfig 2 } -- PTOPO MIB Notification Definitions ptopoMIBNotifications OBJECT IDENTIFIER ::= { ptopoMIB 2 } ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= Bierman & Jones Informational [Page 24] RFC 2922 Physical Topology MIB September 2000 { ptopoMIBNotifications 0 } ptopoConfigChange NOTIFICATION-TYPE OBJECTS { ptopoConnTabInserts, ptopoConnTabDeletes, ptopoConnTabDrops, ptopoConnTabAgeouts } STATUS current DESCRIPTION "A ptopoConfigChange notification is sent when the value of ptopoLastChangeTime changes. It can be utilized by an NMS to trigger physical topology table maintenance polls. Note that transmission of ptopoConfigChange notifications are throttled by the agent, as specified by the 'ptopoConfigTrapInterval' object." ::= { ptopoMIBTrapPrefix 1 } -- PTOPO Registration Points ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 } -- values used with ptopoConnDiscAlgorithm object ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= { ptopoRegistrationPoints 1 } ptopoDiscoveryLocal OBJECT IDENTIFIER ::= { ptopoDiscoveryMechanisms 1 } -- conformance information ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 } ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 } ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 } -- compliance statements ptopoCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the PTOPO MIB." MODULE -- this module MANDATORY-GROUPS { ptopoDataGroup, Bierman & Jones Informational [Page 25] RFC 2922 Physical Topology MIB September 2000 ptopoGeneralGroup, ptopoConfigGroup, ptopoNotificationsGroup } ::= { ptopoCompliances 1 } -- MIB groupings ptopoDataGroup OBJECT-GROUP OBJECTS { ptopoConnRemoteChassisType, ptopoConnRemoteChassis, ptopoConnRemotePortType, ptopoConnRemotePort, ptopoConnDiscAlgorithm, ptopoConnAgentNetAddrType, ptopoConnAgentNetAddr, ptopoConnMultiMacSASeen, ptopoConnMultiNetSASeen, ptopoConnIsStatic, ptopoConnLastVerifyTime, ptopoConnRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to represent physical topology information for which a single agent provides management information. This group is mandatory for all implementations of the PTOPO MIB." ::= { ptopoGroups 1 } ptopoGeneralGroup OBJECT-GROUP OBJECTS { ptopoLastChangeTime, ptopoConnTabInserts, ptopoConnTabDeletes, ptopoConnTabDrops, ptopoConnTabAgeouts } STATUS current DESCRIPTION "The collection of objects which are used to report the general status of the PTOPO MIB implementation. This group is mandatory for all agents which implement the PTOPO MIB." ::= { ptopoGroups 2 } Bierman & Jones Informational [Page 26] RFC 2922 Physical Topology MIB September 2000 ptopoConfigGroup OBJECT-GROUP OBJECTS { ptopoConfigTrapInterval, ptopoConfigMaxHoldTime } STATUS current DESCRIPTION "The collection of objects which are used to configure the PTOPO MIB implementation behavior. This group is mandatory for agents which implement the PTOPO MIB." ::= { ptopoGroups 3 } ptopoNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { ptopoConfigChange } STATUS current DESCRIPTION "The collection of notifications used to indicate PTOPO MIB data consistency and general status information. This group is mandatory for agents which implement the PTOPO MIB." ::= { ptopoGroups 4 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice Bierman & Jones Informational [Page 27] RFC 2922 Physical Topology MIB September 2000 this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 6. Acknowledgements The PTOPO Discovery Protocol is a product of the IETF PTOPOMIB Working Group. 7. References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", January 1996. [RFC1902] 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] 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. Bierman & Jones Informational [Page 28] RFC 2922 Physical Topology MIB September 2000 [RFC1904] 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] 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] 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. [RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997. [RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2", RFC 2037, October 1996. [RFC2108] de Graaf, K., Romascanu, D., McMaster, D. and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997. [RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. Bierman & Jones Informational [Page 29] RFC 2922 Physical Topology MIB September 2000 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC 2737, Cisco Systems, December 1999. 8. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information. These are: read-create objects: ptopoConnRemoteChassisType ptopoConnRemoteChassis ptopoConnRemotePortType ptopoConnRemotePort ptopoConnAgentNetAddrType ptopoConnAgentNetAddr ptopoConnIsStatic ptopoConfigTrapInterval ptopoConfigMaxHoldTime read-only objects: ptopoConnDiscAlgorithm ptopoConnMultiMacSASeen ptopoConnMultiNetSASeen ptopoConnLastVerifyTime ptopoLastChangeTime notifications: ptopoConfigChange These MIB objects expose information about the physical connectivity for a particular portion of a network. Bierman & Jones Informational [Page 30] RFC 2922 Physical Topology MIB September 2000 A network administrator may also wish to inhibit transmission of any ptopoConfigChange notification by setting the ptopoConfigTrapInterval object to zero. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Authors' Addresses Andy Bierman Cisco Systems 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-3711 EMail: abierman@cisco.com Kendall S. Jones Nortel Networks 4401 Great America Parkway Santa Clara, CA USA 95054 Phone: +1 408-495-7356 EMail: kejones@nortelnetworks.com Bierman & Jones Informational [Page 31] RFC 2922 Physical Topology MIB September 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bierman & Jones Informational [Page 32] snmp-mibs-downloader-1.1/mibrfcs/rfc2932.txt0000644000000000000000000014237611402176071015576 0ustar Network Working Group K. McCloghrie Request for Comments: 2932 cisco Systems Category: Standards Track D. Farinacci Procket Networks D. Thaler Microsoft October 2000 IPv4 Multicast Routing MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. Table of Contents 1 Introduction ................................................. 2 2 The SNMP Management Framework ................................ 2 3 Overview ..................................................... 3 4 Definitions .................................................. 4 5 IANA Considerations .......................................... 22 6 Security Considerations ...................................... 22 7 Intellectual Property Notice ................................. 23 8 Acknowledgements ............................................. 23 9 Authors' Addresses ........................................... 24 10 References ................................................... 25 11 Full Copyright Statement ..................................... 27 McCloghrie, et al. Standards Track [Page 1] RFC 2932 IPv4 Multicast Routing MIB October 2000 1. Introduction This MIB describes objects used for managing IP Multicast Routing [16], independent of the specific multicast routing protocol [17-21] in use. Managed objects specific to particular multicast routing protocols are specified elsewhere. Similarly, this MIB does not support management of multicast routing for other address families, including IPv6. Such management may be supported by other MIBs. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. McCloghrie, et al. Standards Track [Page 2] RFC 2932 IPv4 Multicast Routing MIB October 2000 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This MIB module contains one scalar and five tables. The tables are: (1) the IP Multicast Route Table containing multicast routing information for IP datagrams sent by particular sources to the IP multicast groups known to a router. (2) the IP Multicast Routing Next Hop Table containing information on the next-hops for the routing IP multicast datagrams. Each entry is one of a list of next-hops on outgoing interfaces for particular sources sending to a particular multicast group address. (3) the IP Multicast Routing Interface Table containing multicast routing information specific to interfaces. (4) the IP Multicast Scope Boundary Table containing the boundaries configured for multicast scopes [22]. (5) the IP Multicast Scope Name Table containing human-readable names of multicast scope. McCloghrie, et al. Standards Track [Page 3] RFC 2932 IPv4 Multicast Routing MIB October 2000 4. Definitions IPMROUTE-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32, Counter32, Counter64, Gauge32, IpAddress, TimeTicks FROM SNMPv2-SMI RowStatus, TEXTUAL-CONVENTION, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB InterfaceIndexOrZero, InterfaceIndex FROM IF-MIB IANAipRouteProtocol, IANAipMRouteProtocol FROM IANA-RTPROTO-MIB; ipMRouteStdMIB MODULE-IDENTITY LAST-UPDATED "200009220000Z" -- September 22, 2000 ORGANIZATION "IETF IDMR Working Group" CONTACT-INFO " Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 US Phone: +1 425 703 8835 EMail: dthaler@microsoft.com" DESCRIPTION "The MIB module for management of IP Multicast routing, but independent of the specific multicast routing protocol in use." REVISION "200009220000Z" -- September 22, 2000 DESCRIPTION "Initial version, published as RFC 2932." ::= { mib-2 83 } -- Textual Conventions LanguageTag ::= TEXTUAL-CONVENTION DISPLAY-HINT "100a" STATUS current DESCRIPTION "An RFC 1766-style language tag, with all alphabetic characters converted to lowercase. This restriction is intended to make the lexical ordering imposed by SNMP useful McCloghrie, et al. Standards Track [Page 4] RFC 2932 IPv4 Multicast Routing MIB October 2000 when applied to language tags. Note that it is theoretically possible for a valid language tag to exceed the allowed length of this syntax, and thus be impossible to represent with this syntax. Sampling of language tags in current use on the Internet suggests that this limit does not pose a serious problem in practice." SYNTAX OCTET STRING (SIZE (1..100)) -- Top-level structure of the MIB ipMRouteMIBObjects OBJECT IDENTIFIER ::= { ipMRouteStdMIB 1 } ipMRoute OBJECT IDENTIFIER ::= { ipMRouteMIBObjects 1 } -- the IP Multicast Routing MIB-Group -- -- a collection of objects providing information about -- IP Multicast Groups ipMRouteEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The enabled status of IP Multicast routing on this router." ::= { ipMRoute 1 } ipMRouteEntryCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of rows in the ipMRouteTable. This can be used to monitor the multicast routing table size." ::= { ipMRoute 7 } ipMRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing multicast routing information for IP datagrams sent by particular sources to the IP multicast groups known to this router." ::= { ipMRoute 2 } McCloghrie, et al. Standards Track [Page 5] RFC 2932 IPv4 Multicast Routing MIB October 2000 ipMRouteEntry OBJECT-TYPE SYNTAX IpMRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the multicast routing information for IP datagrams from a particular source and addressed to a particular IP multicast group address. Discontinuities in counters in this entry can be detected by observing the value of ipMRouteUpTime." INDEX { ipMRouteGroup, ipMRouteSource, ipMRouteSourceMask } ::= { ipMRouteTable 1 } IpMRouteEntry ::= SEQUENCE { ipMRouteGroup IpAddress, ipMRouteSource IpAddress, ipMRouteSourceMask IpAddress, ipMRouteUpstreamNeighbor IpAddress, ipMRouteInIfIndex InterfaceIndexOrZero, ipMRouteUpTime TimeTicks, ipMRouteExpiryTime TimeTicks, ipMRoutePkts Counter32, ipMRouteDifferentInIfPackets Counter32, ipMRouteOctets Counter32, ipMRouteProtocol IANAipMRouteProtocol, ipMRouteRtProto IANAipRouteProtocol, ipMRouteRtAddress IpAddress, ipMRouteRtMask IpAddress, ipMRouteRtType INTEGER, ipMRouteHCOctets Counter64 } ipMRouteGroup OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address for which this entry contains multicast routing information." ::= { ipMRouteEntry 1 } ipMRouteSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION McCloghrie, et al. Standards Track [Page 6] RFC 2932 IPv4 Multicast Routing MIB October 2000 "The network address which when combined with the corresponding value of ipMRouteSourceMask identifies the sources for which this entry contains multicast routing information." ::= { ipMRouteEntry 2 } ipMRouteSourceMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network mask which when combined with the corresponding value of ipMRouteSource identifies the sources for which this entry contains multicast routing information." ::= { ipMRouteEntry 3 } ipMRouteUpstreamNeighbor OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the upstream neighbor (e.g., RPF neighbor) from which IP datagrams from these sources to this multicast address are received, or 0.0.0.0 if the upstream neighbor is unknown (e.g., in CBT)." ::= { ipMRouteEntry 4 } ipMRouteInIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the interface on which IP datagrams sent by these sources to this multicast address are received. A value of 0 indicates that datagrams are not subject to an incoming interface check, but may be accepted on multiple interfaces (e.g., in CBT)." ::= { ipMRouteEntry 5 } ipMRouteUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since the multicast routing information represented by this entry was learned by the router." ::= { ipMRouteEntry 6 } McCloghrie, et al. Standards Track [Page 7] RFC 2932 IPv4 Multicast Routing MIB October 2000 ipMRouteExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum amount of time remaining before this entry will be aged out. The value 0 indicates that the entry is not subject to aging." ::= { ipMRouteEntry 7 } ipMRoutePkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which this router has received from these sources and addressed to this multicast group address." ::= { ipMRouteEntry 8 } ipMRouteDifferentInIfPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which this router has received from these sources and addressed to this multicast group address, which were dropped because they were not received on the interface indicated by ipMRouteInIfIndex. Packets which are not subject to an incoming interface check (e.g., using CBT) are not counted." ::= { ipMRouteEntry 9 } ipMRouteOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in IP datagrams which were received from these sources and addressed to this multicast group address, and which were forwarded by this router." ::= { ipMRouteEntry 10 } ipMRouteProtocol OBJECT-TYPE SYNTAX IANAipMRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION McCloghrie, et al. Standards Track [Page 8] RFC 2932 IPv4 Multicast Routing MIB October 2000 "The multicast routing protocol via which this multicast forwarding entry was learned." ::= { ipMRouteEntry 11 } ipMRouteRtProto OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which the route used to find the upstream or parent interface for this multicast forwarding entry was learned. Inclusion of values for routing protocols is not intended to imply that those protocols need be supported." ::= { ipMRouteEntry 12 } ipMRouteRtAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address portion of the route used to find the upstream or parent interface for this multicast forwarding entry." ::= { ipMRouteEntry 13 } ipMRouteRtMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The mask associated with the route used to find the upstream or parent interface for this multicast forwarding entry." ::= { ipMRouteEntry 14 } ipMRouteRtType OBJECT-TYPE SYNTAX INTEGER { unicast (1), -- Unicast route used in multicast RIB multicast (2) -- Multicast route } MAX-ACCESS read-only STATUS current DESCRIPTION "The reason the given route was placed in the (logical) multicast Routing Information Base (RIB). A value of unicast means that the route would normally be placed only in the unicast RIB, but was placed in the multicast RIB (instead or in addition) due to local configuration, such as when running PIM over RIP. A value of multicast means that McCloghrie, et al. Standards Track [Page 9] RFC 2932 IPv4 Multicast Routing MIB October 2000 the route was explicitly added to the multicast RIB by the routing protocol, such as DVMRP or Multiprotocol BGP." ::= { ipMRouteEntry 15 } ipMRouteHCOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in IP datagrams which were received from these sources and addressed to this multicast group address, and which were forwarded by this router. This object is a 64-bit version of ipMRouteOctets." ::= { ipMRouteEntry 16 } -- -- The IP Multicast Routing Next Hop Table -- ipMRouteNextHopTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMRouteNextHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on the next- hops on outgoing interfaces for routing IP multicast datagrams. Each entry is one of a list of next-hops on outgoing interfaces for particular sources sending to a particular multicast group address." ::= { ipMRoute 3 } ipMRouteNextHopEntry OBJECT-TYPE SYNTAX IpMRouteNextHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the list of next-hops on outgoing interfaces to which IP multicast datagrams from particular sources to a IP multicast group address are routed. Discontinuities in counters in this entry can be detected by observing the value of ipMRouteUpTime." INDEX { ipMRouteNextHopGroup, ipMRouteNextHopSource, ipMRouteNextHopSourceMask, ipMRouteNextHopIfIndex, ipMRouteNextHopAddress } ::= { ipMRouteNextHopTable 1 } IpMRouteNextHopEntry ::= SEQUENCE { ipMRouteNextHopGroup IpAddress, McCloghrie, et al. Standards Track [Page 10] RFC 2932 IPv4 Multicast Routing MIB October 2000 ipMRouteNextHopSource IpAddress, ipMRouteNextHopSourceMask IpAddress, ipMRouteNextHopIfIndex InterfaceIndex, ipMRouteNextHopAddress IpAddress, ipMRouteNextHopState INTEGER, ipMRouteNextHopUpTime TimeTicks, ipMRouteNextHopExpiryTime TimeTicks, ipMRouteNextHopClosestMemberHops Integer32, ipMRouteNextHopProtocol IANAipMRouteProtocol, ipMRouteNextHopPkts Counter32 } ipMRouteNextHopGroup OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group for which this entry specifies a next-hop on an outgoing interface." ::= { ipMRouteNextHopEntry 1 } ipMRouteNextHopSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address which when combined with the corresponding value of ipMRouteNextHopSourceMask identifies the sources for which this entry specifies a next-hop on an outgoing interface." ::= { ipMRouteNextHopEntry 2 } ipMRouteNextHopSourceMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network mask which when combined with the corresponding value of ipMRouteNextHopSource identifies the sources for which this entry specifies a next-hop on an outgoing interface." ::= { ipMRouteNextHopEntry 3 } ipMRouteNextHopIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION McCloghrie, et al. Standards Track [Page 11] RFC 2932 IPv4 Multicast Routing MIB October 2000 "The ifIndex value of the interface for the outgoing interface for this next-hop." ::= { ipMRouteNextHopEntry 4 } ipMRouteNextHopAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the next-hop specific to this entry. For most interfaces, this is identical to ipMRouteNextHopGroup. NBMA interfaces, however, may have multiple next-hop addresses out a single outgoing interface." ::= { ipMRouteNextHopEntry 5 } ipMRouteNextHopState OBJECT-TYPE SYNTAX INTEGER { pruned(1), forwarding(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the outgoing interface and next- hop represented by this entry is currently being used to forward IP datagrams. The value 'forwarding' indicates it is currently being used; the value 'pruned' indicates it is not." ::= { ipMRouteNextHopEntry 6 } ipMRouteNextHopUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since the multicast routing information represented by this entry was learned by the router." ::= { ipMRouteNextHopEntry 7 } ipMRouteNextHopExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum amount of time remaining before this entry will be aged out. If ipMRouteNextHopState is pruned(1), the remaining time until the prune expires and the state reverts to forwarding(2). Otherwise, the remaining time until this entry is removed from the table. The time remaining may be copied from ipMRouteExpiryTime if the protocol in use for this entry does not specify next-hop timers. The value 0 McCloghrie, et al. Standards Track [Page 12] RFC 2932 IPv4 Multicast Routing MIB October 2000 indicates that the entry is not subject to aging." ::= { ipMRouteNextHopEntry 8 } ipMRouteNextHopClosestMemberHops OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum number of hops between this router and any member of this IP multicast group reached via this next-hop on this outgoing interface. Any IP multicast datagrams for the group which have a TTL less than this number of hops will not be forwarded to this next-hop." ::= { ipMRouteNextHopEntry 9 } ipMRouteNextHopProtocol OBJECT-TYPE SYNTAX IANAipMRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which this next-hop was learned." ::= { ipMRouteNextHopEntry 10 } ipMRouteNextHopPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which have been forwarded using this route." ::= { ipMRouteNextHopEntry 11 } -- -- The Multicast Routing Interface Table -- ipMRouteInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMRouteInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing multicast routing information specific to interfaces." ::= { ipMRoute 4 } ipMRouteInterfaceEntry OBJECT-TYPE SYNTAX IpMRouteInterfaceEntry MAX-ACCESS not-accessible McCloghrie, et al. Standards Track [Page 13] RFC 2932 IPv4 Multicast Routing MIB October 2000 STATUS current DESCRIPTION "An entry (conceptual row) containing the multicast routing information for a particular interface." INDEX { ipMRouteInterfaceIfIndex } ::= { ipMRouteInterfaceTable 1 } IpMRouteInterfaceEntry ::= SEQUENCE { ipMRouteInterfaceIfIndex InterfaceIndex, ipMRouteInterfaceTtl Integer32, ipMRouteInterfaceProtocol IANAipMRouteProtocol, ipMRouteInterfaceRateLimit Integer32, ipMRouteInterfaceInMcastOctets Counter32, ipMRouteInterfaceOutMcastOctets Counter32, ipMRouteInterfaceHCInMcastOctets Counter64, ipMRouteInterfaceHCOutMcastOctets Counter64 } ipMRouteInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the interface for which this entry contains information." ::= { ipMRouteInterfaceEntry 1 } ipMRouteInterfaceTtl OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The datagram TTL threshold for the interface. Any IP multicast datagrams with a TTL less than this threshold will not be forwarded out the interface. The default value of 0 means all multicast packets are forwarded out the interface." ::= { ipMRouteInterfaceEntry 2 } ipMRouteInterfaceProtocol OBJECT-TYPE SYNTAX IANAipMRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing protocol running on this interface." ::= { ipMRouteInterfaceEntry 3 } ipMRouteInterfaceRateLimit OBJECT-TYPE McCloghrie, et al. Standards Track [Page 14] RFC 2932 IPv4 Multicast Routing MIB October 2000 SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The rate-limit, in kilobits per second, of forwarded multicast traffic on the interface. A rate-limit of 0 indicates that no rate limiting is done." DEFVAL { 0 } ::= { ipMRouteInterfaceEntry 4 } ipMRouteInterfaceInMcastOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of multicast packets that have arrived on the interface, including framing characters. This object is similar to ifInOctets in the Interfaces MIB, except that only multicast packets are counted." ::= { ipMRouteInterfaceEntry 5 } ipMRouteInterfaceOutMcastOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of multicast packets that have been sent on the interface." ::= { ipMRouteInterfaceEntry 6 } ipMRouteInterfaceHCInMcastOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of multicast packets that have arrived on the interface, including framing characters. This object is a 64-bit version of ipMRouteInterfaceInMcastOctets. It is similar to ifHCInOctets in the Interfaces MIB, except that only multicast packets are counted." ::= { ipMRouteInterfaceEntry 7 } ipMRouteInterfaceHCOutMcastOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of multicast packets that have been McCloghrie, et al. Standards Track [Page 15] RFC 2932 IPv4 Multicast Routing MIB October 2000 sent on the interface. This object is a 64-bit version of ipMRouteInterfaceOutMcastOctets." ::= { ipMRouteInterfaceEntry 8 } -- -- The IP Multicast Scope Boundary Table -- ipMRouteBoundaryTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMRouteBoundaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the router's scoped multicast address boundaries." ::= { ipMRoute 5 } ipMRouteBoundaryEntry OBJECT-TYPE SYNTAX IpMRouteBoundaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the ipMRouteBoundaryTable representing a scoped boundary." INDEX { ipMRouteBoundaryIfIndex, ipMRouteBoundaryAddress, ipMRouteBoundaryAddressMask } ::= { ipMRouteBoundaryTable 1 } IpMRouteBoundaryEntry ::= SEQUENCE { ipMRouteBoundaryIfIndex InterfaceIndex, ipMRouteBoundaryAddress IpAddress, ipMRouteBoundaryAddressMask IpAddress, ipMRouteBoundaryStatus RowStatus } ipMRouteBoundaryIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IfIndex value for the interface to which this boundary applies. Packets with a destination address in the associated address/mask range will not be forwarded out this interface." ::= { ipMRouteBoundaryEntry 1 } ipMRouteBoundaryAddress OBJECT-TYPE SYNTAX IpAddress McCloghrie, et al. Standards Track [Page 16] RFC 2932 IPv4 Multicast Routing MIB October 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group address which when combined with the corresponding value of ipMRouteBoundaryAddressMask identifies the group range for which the scoped boundary exists. Scoped addresses must come from the range 239.x.x.x as specified in RFC 2365." ::= { ipMRouteBoundaryEntry 2 } ipMRouteBoundaryAddressMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group address mask which when combined with the corresponding value of ipMRouteBoundaryAddress identifies the group range for which the scoped boundary exists." ::= { ipMRouteBoundaryEntry 3 } ipMRouteBoundaryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table." ::= { ipMRouteBoundaryEntry 4 } -- -- The IP Multicast Scope Name Table -- ipMRouteScopeNameTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMRouteScopeNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the multicast scope names." ::= { ipMRoute 6 } ipMRouteScopeNameEntry OBJECT-TYPE SYNTAX IpMRouteScopeNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the ipMRouteScopeNameTable representing a multicast scope name." McCloghrie, et al. Standards Track [Page 17] RFC 2932 IPv4 Multicast Routing MIB October 2000 INDEX { ipMRouteScopeNameAddress, ipMRouteScopeNameAddressMask, IMPLIED ipMRouteScopeNameLanguage } ::= { ipMRouteScopeNameTable 1 } IpMRouteScopeNameEntry ::= SEQUENCE { ipMRouteScopeNameAddress IpAddress, ipMRouteScopeNameAddressMask IpAddress, ipMRouteScopeNameLanguage LanguageTag, ipMRouteScopeNameString SnmpAdminString, ipMRouteScopeNameDefault TruthValue, ipMRouteScopeNameStatus RowStatus } ipMRouteScopeNameAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group address which when combined with the corresponding value of ipMRouteScopeNameAddressMask identifies the group range associated with the multicast scope. Scoped addresses must come from the range 239.x.x.x." ::= { ipMRouteScopeNameEntry 1 } ipMRouteScopeNameAddressMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group address mask which when combined with the corresponding value of ipMRouteScopeNameAddress identifies the group range associated with the multicast scope." ::= { ipMRouteScopeNameEntry 2 } ipMRouteScopeNameLanguage OBJECT-TYPE SYNTAX LanguageTag MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RFC 1766-style language tag associated with the scope name." ::= { ipMRouteScopeNameEntry 3 } ipMRouteScopeNameString OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create McCloghrie, et al. Standards Track [Page 18] RFC 2932 IPv4 Multicast Routing MIB October 2000 STATUS current DESCRIPTION "The textual name associated with the multicast scope. The value of this object should be suitable for displaying to end-users, such as when allocating a multicast address in this scope. When no name is specified, the default value of this object should be the string 239.x.x.x/y with x and y replaced appropriately to describe the address and mask length associated with the scope." ::= { ipMRouteScopeNameEntry 4 } ipMRouteScopeNameDefault OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, indicates a preference that the name in the following language should be used by applications if no name is available in a desired language." DEFVAL { false } ::= { ipMRouteScopeNameEntry 5 } ipMRouteScopeNameStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table." ::= { ipMRouteScopeNameEntry 6 } -- conformance information ipMRouteMIBConformance OBJECT IDENTIFIER ::= { ipMRouteStdMIB 2 } ipMRouteMIBCompliances OBJECT IDENTIFIER ::= { ipMRouteMIBConformance 1 } ipMRouteMIBGroups OBJECT IDENTIFIER ::= { ipMRouteMIBConformance 2 } -- compliance statements ipMRouteMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the IP Multicast MIB." MODULE -- this module MANDATORY-GROUPS { ipMRouteMIBBasicGroup, McCloghrie, et al. Standards Track [Page 19] RFC 2932 IPv4 Multicast Routing MIB October 2000 ipMRouteMIBRouteGroup} GROUP ipMRouteMIBBoundaryGroup DESCRIPTION "This group is mandatory if the router supports administratively-scoped multicast address boundaries." OBJECT ipMRouteBoundaryStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMRouteScopeNameStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP ipMRouteMIBHCInterfaceGroup DESCRIPTION "This group is mandatory only for those network interfaces for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second." ::= { ipMRouteMIBCompliances 1 } -- units of conformance ipMRouteMIBBasicGroup OBJECT-GROUP OBJECTS { ipMRouteEnable, ipMRouteEntryCount, ipMRouteUpstreamNeighbor, ipMRouteInIfIndex, ipMRouteUpTime, ipMRouteExpiryTime, ipMRouteNextHopState, ipMRouteNextHopUpTime, ipMRouteNextHopExpiryTime, ipMRouteNextHopProtocol, ipMRouteNextHopPkts, ipMRouteInterfaceTtl, ipMRouteInterfaceProtocol, ipMRouteInterfaceRateLimit, ipMRouteInterfaceInMcastOctets, ipMRouteInterfaceOutMcastOctets, ipMRouteProtocol } STATUS current DESCRIPTION "A collection of objects to support basic management of IP Multicast routing." ::= { ipMRouteMIBGroups 1 } McCloghrie, et al. Standards Track [Page 20] RFC 2932 IPv4 Multicast Routing MIB October 2000 ipMRouteMIBHopCountGroup OBJECT-GROUP OBJECTS { ipMRouteNextHopClosestMemberHops } STATUS current DESCRIPTION "A collection of objects to support management of the use of hop counts in IP Multicast routing." ::= { ipMRouteMIBGroups 2 } ipMRouteMIBBoundaryGroup OBJECT-GROUP OBJECTS { ipMRouteBoundaryStatus, ipMRouteScopeNameString, ipMRouteScopeNameDefault, ipMRouteScopeNameStatus } STATUS current DESCRIPTION "A collection of objects to support management of scoped multicast address boundaries." ::= { ipMRouteMIBGroups 3 } ipMRouteMIBPktsOutGroup OBJECT-GROUP OBJECTS { ipMRouteNextHopPkts } STATUS current DESCRIPTION "A collection of objects to support management of packet counters for each outgoing interface entry of a route." ::= { ipMRouteMIBGroups 4 } ipMRouteMIBHCInterfaceGroup OBJECT-GROUP OBJECTS { ipMRouteInterfaceHCInMcastOctets, ipMRouteInterfaceHCOutMcastOctets, ipMRouteHCOctets } STATUS current DESCRIPTION "A collection of objects providing information specific to high speed (greater than 20,000,000 bits/second) network interfaces." ::= { ipMRouteMIBGroups 5 } ipMRouteMIBRouteGroup OBJECT-GROUP OBJECTS { ipMRouteRtProto, ipMRouteRtAddress, ipMRouteRtMask, ipMRouteRtType } STATUS current DESCRIPTION "A collection of objects providing information on the relationship between multicast routing information, and the IP Forwarding Table." ::= { ipMRouteMIBGroups 6 } ipMRouteMIBPktsGroup OBJECT-GROUP OBJECTS { ipMRoutePkts, ipMRouteDifferentInIfPackets, McCloghrie, et al. Standards Track [Page 21] RFC 2932 IPv4 Multicast Routing MIB October 2000 ipMRouteOctets } STATUS current DESCRIPTION "A collection of objects to support management of packet counters for each forwarding entry." ::= { ipMRouteMIBGroups 7 } END 5. IANA Considerations The ipMRouteRtProto, ipMRouteNextHopProtocol, ipMRouteInterfaceProtocol, and ipMRouteProtocol use textual conventions imported from the IANA-RTPROTO-MIB. The purpose of defining these textual conventions in a separate MIB module is to allow additional values to be defined without having to issue a new version of this document. The Internet Assigned Numbers Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers; it will administer the values associated with these textual conventions. The rules for additions or changes to the IANA-RTPROTO-MIB are outlined in the DESCRIPTION clause associated with its MODULE- IDENTITY statement. The current versions of the IANA-RTPROTO-MIB can be accessed from the IANA home page at: "http://www.iana.org/". 6. Security Considerations This MIB contains readable objects whose values provide information related to multicast routing, including information on what machines are sending to which groups. There are also a number of objects that have a MAX-ACCESS clause of read-write and/or read-create, such as those which allow an administrator to configure multicast boundaries. While unauthorized access to the readable objects is relatively innocuous, unauthorized access to the write-able objects could cause a denial of service, or could cause wider distribution of packets intended only for local distribution. Hence, the support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB. McCloghrie, et al. Standards Track [Page 22] RFC 2932 IPv4 Multicast Routing MIB October 2000 It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 7. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Acknowledgements This MIB module was updated based on feedback from the IETF's Inter- Domain Multicast Routing (IDMR) Working Group. McCloghrie, et al. Standards Track [Page 23] RFC 2932 IPv4 Multicast Routing MIB October 2000 9. Authors' Addresses Keith McCloghrie cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: +1 408 526 5260 EMail: kzm@cisco.com Dino Farinacci Procket Networks 3850 North First Street San Jose, CA 95134 Phone: +1 408-954-7909 Email: dino@procket.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com McCloghrie, et al. Standards Track [Page 24] RFC 2932 IPv4 Multicast Routing MIB October 2000 10. References [1] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, STD 58, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. McCloghrie, et al. Standards Track [Page 25] RFC 2932 IPv4 Multicast Routing MIB October 2000 [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Deering, S., "Multicast Routing in a Datagram Internetwork", PhD thesis, Electrical Engineering Dept., Stanford University, December 1991. [17] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [18] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [19] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, A. and L. Wei, "Protocol Independent Multicast Version 2, Dense Mode Specification", Work in Progress. [20] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. [21] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing", RFC 2189, September 1997. [22] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. McCloghrie, et al. Standards Track [Page 26] RFC 2932 IPv4 Multicast Routing MIB October 2000 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McCloghrie, et al. Standards Track [Page 27] snmp-mibs-downloader-1.1/mibrfcs/rfc2933.txt0000644000000000000000000010117611402176071015570 0ustar Network Working Group K. McCloghrie Request for Comments: 2933 cisco Systems Category: Standards Track D. Farinacci Procket Networks D. Thaler Microsoft October 2000 Internet Group Management Protocol MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). Table of Contents 1 Introduction ................................................ 1 2 The SNMP Network Management Framework ....................... 2 3 Overview .................................................... 3 4 Definitions ................................................. 3 5 Security Considerations ..................................... 14 6 Intellectual Property Notice ................................ 15 7 Acknowledgements ............................................ 15 8 Authors' Addresses .......................................... 16 9 References .................................................. 17 10 Full Copyright Statement .................................... 19 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet McCloghrie, et al. Standards Track [Page 1] RFC 2933 Internet Group Management Protocol MIB October 2000 Group Management Protocol (IGMP), version 1 [16] or version 2 [17]. A future version of this MIB will support IGMP version 3 (currently a work in progress). All of this MIB module is applicable to IPv4 multicast routers; a subset is applicable to hosts implementing IGMP. Since IGMP is specific to IPv4, this MIB does not support management of equivalent functionality for other address families, such as IPv6. Such management may be supported by other MIBs. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically McCloghrie, et al. Standards Track [Page 2] RFC 2933 Internet Group Management Protocol MIB October 2000 equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This MIB module contains two tables: (1) the IGMP Interface Table which contains one row for each interface on which IGMP is enabled, and (2) the IGMP Cache Table which contains one row for each IP multicast group for which there are members on a particular interface. Both tables are intended to be implemented by hosts and routers, but some columnar objects in each table apply only to routers. 4. Definitions IGMP-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Counter32, Gauge32, Unsigned32, IpAddress, TimeTicks FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndexOrZero, InterfaceIndex FROM IF-MIB; igmpStdMIB MODULE-IDENTITY LAST-UPDATED "200009280000Z" -- September 28, 2000 ORGANIZATION "IETF IDMR Working Group." CONTACT-INFO " Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 US Phone: +1 425 703 8835 EMail: dthaler@microsoft.com" DESCRIPTION "The MIB module for IGMP Management." REVISION "200009280000Z" -- September 28, 2000 McCloghrie, et al. Standards Track [Page 3] RFC 2933 Internet Group Management Protocol MIB October 2000 DESCRIPTION "Initial version, published as RFC 2933." ::= { mib-2 85 } igmpMIBObjects OBJECT IDENTIFIER ::= { igmpStdMIB 1 } -- -- The IGMP Interface Table -- igmpInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF IgmpInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interfaces on which IGMP is enabled." ::= { igmpMIBObjects 1 } igmpInterfaceEntry OBJECT-TYPE SYNTAX IgmpInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an interface on which IGMP is enabled." INDEX { igmpInterfaceIfIndex } ::= { igmpInterfaceTable 1 } IgmpInterfaceEntry ::= SEQUENCE { igmpInterfaceIfIndex InterfaceIndex, igmpInterfaceQueryInterval Unsigned32, igmpInterfaceStatus RowStatus, igmpInterfaceVersion Unsigned32, igmpInterfaceQuerier IpAddress, igmpInterfaceQueryMaxResponseTime Unsigned32, igmpInterfaceQuerierUpTime TimeTicks, igmpInterfaceQuerierExpiryTime TimeTicks, igmpInterfaceVersion1QuerierTimer TimeTicks, igmpInterfaceWrongVersionQueries Counter32, igmpInterfaceJoins Counter32, igmpInterfaceProxyIfIndex InterfaceIndexOrZero, igmpInterfaceGroups Gauge32, igmpInterfaceRobustness Unsigned32, igmpInterfaceLastMembQueryIntvl Unsigned32 } McCloghrie, et al. Standards Track [Page 4] RFC 2933 Internet Group Management Protocol MIB October 2000 igmpInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the interface for which IGMP is enabled." ::= { igmpInterfaceEntry 1 } igmpInterfaceQueryInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency at which IGMP Host-Query packets are transmitted on this interface." DEFVAL { 125 } ::= { igmpInterfaceEntry 2 } igmpInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The activation of a row enables IGMP on the interface. The destruction of a row disables IGMP on the interface." ::= { igmpInterfaceEntry 3 } igmpInterfaceVersion OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The version of IGMP which is running on this interface. This object can be used to configure a router capable of running either value. For IGMP to function correctly, all routers on a LAN must be configured to run the same version of IGMP on that LAN." DEFVAL { 2 } ::= { igmpInterfaceEntry 4 } igmpInterfaceQuerier OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the IGMP Querier on the IP subnet to which McCloghrie, et al. Standards Track [Page 5] RFC 2933 Internet Group Management Protocol MIB October 2000 this interface is attached." ::= { igmpInterfaceEntry 5 } igmpInterfaceQueryMaxResponseTime OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum query response time advertised in IGMPv2 queries on this interface." DEFVAL { 100 } ::= { igmpInterfaceEntry 6 } igmpInterfaceQuerierUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since igmpInterfaceQuerier was last changed." ::= { igmpInterfaceEntry 7 } igmpInterfaceQuerierExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time remaining before the Other Querier Present Timer expires. If the local system is the querier, the value of this object is zero." ::= { igmpInterfaceEntry 8 } igmpInterfaceVersion1QuerierTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining until the host assumes that there are no IGMPv1 routers present on the interface. While this is non- zero, the host will reply to all queries with version 1 membership reports." ::= { igmpInterfaceEntry 9 } igmpInterfaceWrongVersionQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION McCloghrie, et al. Standards Track [Page 6] RFC 2933 Internet Group Management Protocol MIB October 2000 "The number of queries received whose IGMP version does not match igmpInterfaceVersion, over the lifetime of the row entry. IGMP requires that all routers on a LAN be configured to run the same version of IGMP. Thus, if any queries are received with the wrong version, this indicates a configuration error." ::= { igmpInterfaceEntry 10 } igmpInterfaceJoins OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a group membership has been added on this interface; that is, the number of times an entry for this interface has been added to the Cache Table. This object gives an indication of the amount of IGMP activity over the lifetime of the row entry." ::= { igmpInterfaceEntry 11 } igmpInterfaceProxyIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Some devices implement a form of IGMP proxying whereby memberships learned on the interface represented by this row, cause IGMP Host Membership Reports to be sent on the interface whose ifIndex value is given by this object. Such a device would implement the igmpV2RouterMIBGroup only on its router interfaces (those interfaces with non-zero igmpInterfaceProxyIfIndex). Typically, the value of this object is 0, indicating that no proxying is being done." DEFVAL { 0 } ::= { igmpInterfaceEntry 12 } igmpInterfaceGroups OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries for this interface in the Cache Table." ::= { igmpInterfaceEntry 13 } igmpInterfaceRobustness OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create McCloghrie, et al. Standards Track [Page 7] RFC 2933 Internet Group Management Protocol MIB October 2000 STATUS current DESCRIPTION "The Robustness Variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the Robustness Variable may be increased. IGMP is robust to (Robustness Variable-1) packet losses." DEFVAL { 2 } ::= { igmpInterfaceEntry 14 } igmpInterfaceLastMembQueryIntvl OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Last Member Query Interval is the Max Response Time inserted into Group-Specific Queries sent in response to Leave Group messages, and is also the amount of time between Group-Specific Query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group. The value of this object is irrelevant if igmpInterfaceVersion is 1." DEFVAL { 10 } ::= { igmpInterfaceEntry 15 } -- -- The IGMP Cache Table -- igmpCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF IgmpCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the IP multicast groups for which there are members on a particular interface." ::= { igmpMIBObjects 2 } igmpCacheEntry OBJECT-TYPE SYNTAX IgmpCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the igmpCacheTable." INDEX { igmpCacheAddress, igmpCacheIfIndex } ::= { igmpCacheTable 1 } McCloghrie, et al. Standards Track [Page 8] RFC 2933 Internet Group Management Protocol MIB October 2000 IgmpCacheEntry ::= SEQUENCE { igmpCacheAddress IpAddress, igmpCacheIfIndex InterfaceIndex, igmpCacheSelf TruthValue, igmpCacheLastReporter IpAddress, igmpCacheUpTime TimeTicks, igmpCacheExpiryTime TimeTicks, igmpCacheStatus RowStatus, igmpCacheVersion1HostTimer TimeTicks } igmpCacheAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address for which this entry contains information." ::= { igmpCacheEntry 1 } igmpCacheIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information for an IP multicast group address." ::= { igmpCacheEntry 2 } igmpCacheSelf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether the local system is a member of this group address on this interface." DEFVAL { true } ::= { igmpCacheEntry 3 } igmpCacheLastReporter OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the source of the last membership report received for this IP Multicast group address on this interface. If no membership report has been received, this object has the value 0.0.0.0." McCloghrie, et al. Standards Track [Page 9] RFC 2933 Internet Group Management Protocol MIB October 2000 ::= { igmpCacheEntry 4 } igmpCacheUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time elapsed since this entry was created." ::= { igmpCacheEntry 5 } igmpCacheExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum amount of time remaining before this entry will be aged out. A value of 0 indicates that the entry is only present because igmpCacheSelf is true and that if the router left the group, this entry would be aged out immediately. Note that some implementations may process membership reports from the local system in the same way as reports from other hosts, so a value of 0 is not required." ::= { igmpCacheEntry 6 } igmpCacheStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry." ::= { igmpCacheEntry 7 } igmpCacheVersion1HostTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining until the local router will assume that there are no longer any IGMP version 1 members on the IP subnet attached to this interface. Upon hearing any IGMPv1 Membership Report, this value is reset to the group membership timer. While this time remaining is non-zero, the local router ignores any IGMPv2 Leave messages for this group that it receives on this interface." ::= { igmpCacheEntry 8 } -- conformance information McCloghrie, et al. Standards Track [Page 10] RFC 2933 Internet Group Management Protocol MIB October 2000 igmpMIBConformance OBJECT IDENTIFIER ::= { igmpStdMIB 2 } igmpMIBCompliances OBJECT IDENTIFIER ::= { igmpMIBConformance 1 } igmpMIBGroups OBJECT IDENTIFIER ::= { igmpMIBConformance 2 } -- compliance statements igmpV1HostMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts running IGMPv1 and implementing the IGMP MIB." MODULE -- this module MANDATORY-GROUPS { igmpBaseMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { igmpMIBCompliances 1 } igmpV1RouterMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers running IGMPv1 and implementing the IGMP MIB." MODULE -- this module MANDATORY-GROUPS { igmpBaseMIBGroup, igmpRouterMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." McCloghrie, et al. Standards Track [Page 11] RFC 2933 Internet Group Management Protocol MIB October 2000 ::= { igmpMIBCompliances 2 } igmpV2HostMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts running IGMPv2 and implementing the IGMP MIB." MODULE -- this module MANDATORY-GROUPS { igmpBaseMIBGroup, igmpV2HostMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { igmpMIBCompliances 3 } igmpV2RouterMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers running IGMPv2 and implementing the IGMP MIB." MODULE -- this module MANDATORY-GROUPS { igmpBaseMIBGroup, igmpRouterMIBGroup, igmpV2RouterMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { igmpMIBCompliances 4 } -- units of conformance McCloghrie, et al. Standards Track [Page 12] RFC 2933 Internet Group Management Protocol MIB October 2000 igmpBaseMIBGroup OBJECT-GROUP OBJECTS { igmpCacheSelf, igmpCacheStatus, igmpInterfaceStatus } STATUS current DESCRIPTION "The basic collection of objects providing management of IGMP version 1 or 2." ::= { igmpMIBGroups 1 } igmpRouterMIBGroup OBJECT-GROUP OBJECTS { igmpCacheUpTime, igmpCacheExpiryTime, igmpInterfaceJoins, igmpInterfaceGroups, igmpCacheLastReporter, igmpInterfaceQuerierUpTime, igmpInterfaceQuerierExpiryTime, igmpInterfaceQueryInterval } STATUS current DESCRIPTION "A collection of additional objects for management of IGMP version 1 or 2 in routers." ::= { igmpMIBGroups 2 } igmpV2HostMIBGroup OBJECT-GROUP OBJECTS { igmpInterfaceVersion1QuerierTimer } STATUS current DESCRIPTION "A collection of additional objects for management of IGMP version 2 in hosts." ::= { igmpMIBGroups 3 } igmpHostOptMIBGroup OBJECT-GROUP OBJECTS { igmpCacheLastReporter, igmpInterfaceQuerier } STATUS current DESCRIPTION "A collection of optional objects for IGMP hosts. Supporting this group can be especially useful in an environment with a router which does not support the IGMP MIB." ::= { igmpMIBGroups 4 } igmpV2RouterMIBGroup OBJECT-GROUP OBJECTS { igmpInterfaceVersion, igmpInterfaceQuerier, igmpInterfaceQueryMaxResponseTime, igmpInterfaceRobustness, igmpInterfaceWrongVersionQueries, McCloghrie, et al. Standards Track [Page 13] RFC 2933 Internet Group Management Protocol MIB October 2000 igmpInterfaceLastMembQueryIntvl, igmpCacheVersion1HostTimer } STATUS current DESCRIPTION "A collection of additional objects for management of IGMP version 2 in routers." ::= { igmpMIBGroups 5 } igmpV2ProxyMIBGroup OBJECT-GROUP OBJECTS { igmpInterfaceProxyIfIndex } STATUS current DESCRIPTION "A collection of additional objects for management of IGMP proxy devices." ::= { igmpMIBGroups 6 } END 5. Security Considerations This MIB contains readable objects whose values provide information related to multicast sessions. Some of these objects could contain sensitive information. In particular, the igmpCacheSelf and igmpCacheLastReporter can be used to identify machines which are listening to a given group address. There are also a number of objects that have a MAX-ACCESS clause of read-write and/or read- create, which allow an administrator to configure IGMP in the router. While unauthorized access to the readable objects is relatively innocuous, unauthorized access to the write-able objects could cause a denial of service. Hence, the support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. McCloghrie, et al. Standards Track [Page 14] RFC 2933 Internet Group Management Protocol MIB October 2000 It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 6. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgements This MIB module was updated based on feedback from the IETF's Inter- Domain Multicast Routing (IDMR) Working Group. McCloghrie, et al. Standards Track [Page 15] RFC 2933 Internet Group Management Protocol MIB October 2000 8. Authors' Addresses Keith McCloghrie cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: +1 408 526 5260 EMail: kzm@cisco.com Dino Farinacci Procket Networks 3850 North First Street San Jose, CA 95134 Phone: +1 408-954-7909 Email: dino@procket.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 48105-6399 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com McCloghrie, et al. Standards Track [Page 16] RFC 2933 Internet Group Management Protocol MIB October 2000 9. References [1] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. McCloghrie, et al. Standards Track [Page 17] RFC 2933 Internet Group Management Protocol MIB October 2000 [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [17] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. McCloghrie, et al. Standards Track [Page 18] RFC 2933 Internet Group Management Protocol MIB October 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McCloghrie, et al. Standards Track [Page 19] snmp-mibs-downloader-1.1/mibrfcs/rfc2934.txt0000644000000000000000000013637311402176071015600 0ustar Network Working Group K. McCloghrie Request for Comments: 2934 cisco Systems Category: Experimental D. Farinacci Procket Networks D. Thaler Microsoft B. Fenner AT&T Labs October 2000 Protocol Independent Multicast MIB for IPv4 Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. Table of Contents 1 Introduction ................................................. 2 2 The SNMP Network Management Framework ........................ 2 3 Overview ..................................................... 3 4 Definitions .................................................. 4 5 Security Considerations ...................................... 22 6 Intellectual Property Notice ................................. 23 7 Acknowledgements ............................................. 23 8 Authors' Addresses ........................................... 24 9 References ................................................... 24 10 Full Copyright Statement .................................... 27 McCloghrie, et al. Experimental [Page 1] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol [16,17,18,19]. This MIB module is applicable to IPv4 multicast routers which implement PIM. This MIB does not support management of PIM for other address families, including IPv6. Such management may be supported by other MIBs. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. McCloghrie, et al. Experimental [Page 2] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This MIB module contains one scalar and eight tables. Some of the objects in these tables are deprecated. This MIB contains deprecated objects since they are necessary for managing PIMv1 routers, but PIMv1 itself is obsoleted by PIMv2 [18,19]. The tables contained in this MIB are: (1) The PIM Interface Table contains one row for each of the router's PIM interfaces. (2) The PIM Neighbor Table contains one row for each of the router's PIM neighbors. (3) The PIM IP Multicast Route Table contains one row for each multicast routing entry whose incoming interface is running PIM. (4) The PIM Next Hop Table which contains one row for each outgoing interface list entry in the multicast routing table whose interface is running PIM, and whose state is pruned. (5) The (deprecated) PIM RP Table contains the PIM (version 1) information for IP multicast groups which is common to all RPs of a group. (6) The PIM RP-Set Table contains the PIM (version 2) information for sets of candidate Rendezvous Points (RPs) for IP multicast group addresses with particular address prefixes. (7) The PIM Candidate-RP Table contains the IP multicast groups for which the local router is to advertise itself as a Candidate-RP. If this table is empty, then the local router advertises itself as a Candidate-RP for all groups. (8) The PIM Component Table contains one row for each of the PIM domains to which the router is connected. McCloghrie, et al. Experimental [Page 3] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 4. Definitions PIM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, NOTIFICATION-TYPE, Integer32, IpAddress, TimeTicks FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ipMRouteGroup, ipMRouteSource, ipMRouteSourceMask, ipMRouteNextHopGroup, ipMRouteNextHopSource, ipMRouteNextHopSourceMask, ipMRouteNextHopIfIndex, ipMRouteNextHopAddress FROM IPMROUTE-STD-MIB InterfaceIndex FROM IF-MIB; pimMIB MODULE-IDENTITY LAST-UPDATED "200009280000Z" -- September 28, 2000 ORGANIZATION "IETF IDMR Working Group." CONTACT-INFO " Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 US Phone: +1 425 703 8835 EMail: dthaler@microsoft.com" DESCRIPTION "The MIB module for management of PIM routers." REVISION "200009280000Z" -- September 28, 2000 DESCRIPTION "Initial version, published as RFC 2934." ::= { experimental 61 } pimMIBObjects OBJECT IDENTIFIER ::= { pimMIB 1 } pimTraps OBJECT IDENTIFIER ::= { pimMIBObjects 0 } pim OBJECT IDENTIFIER ::= { pimMIBObjects 1 } pimJoinPruneInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-write STATUS current McCloghrie, et al. Experimental [Page 4] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 DESCRIPTION "The default interval at which periodic PIM-SM Join/Prune messages are to be sent." ::= { pim 1 } -- The PIM Interface Table pimInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF PimInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the router's PIM interfaces. IGMP and PIM are enabled on all interfaces listed in this table." ::= { pim 2 } pimInterfaceEntry OBJECT-TYPE SYNTAX PimInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimInterfaceTable." INDEX { pimInterfaceIfIndex } ::= { pimInterfaceTable 1 } PimInterfaceEntry ::= SEQUENCE { pimInterfaceIfIndex InterfaceIndex, pimInterfaceAddress IpAddress, pimInterfaceNetMask IpAddress, pimInterfaceMode INTEGER, pimInterfaceDR IpAddress, pimInterfaceHelloInterval Integer32, pimInterfaceStatus RowStatus, pimInterfaceJoinPruneInterval Integer32, pimInterfaceCBSRPreference Integer32 } pimInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of this PIM interface." ::= { pimInterfaceEntry 1 } pimInterfaceAddress OBJECT-TYPE SYNTAX IpAddress McCloghrie, et al. Experimental [Page 5] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the PIM interface." ::= { pimInterfaceEntry 2 } pimInterfaceNetMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The network mask for the IP address of the PIM interface." ::= { pimInterfaceEntry 3 } pimInterfaceMode OBJECT-TYPE SYNTAX INTEGER { dense(1), sparse(2), sparseDense(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The configured mode of this PIM interface. A value of sparseDense is only valid for PIMv1." DEFVAL { dense } ::= { pimInterfaceEntry 4 } pimInterfaceDR OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Designated Router on this PIM interface. For point-to- point interfaces, this object has the value 0.0.0.0." ::= { pimInterfaceEntry 5 } pimInterfaceHelloInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency at which PIM Hello messages are transmitted on this interface." DEFVAL { 30 } ::= { pimInterfaceEntry 6 } pimInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create McCloghrie, et al. Experimental [Page 6] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 STATUS current DESCRIPTION "The status of this entry. Creating the entry enables PIM on the interface; destroying the entry disables PIM on the interface." ::= { pimInterfaceEntry 7 } pimInterfaceJoinPruneInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency at which PIM Join/Prune messages are transmitted on this PIM interface. The default value of this object is the pimJoinPruneInterval." ::= { pimInterfaceEntry 8 } pimInterfaceCBSRPreference OBJECT-TYPE SYNTAX Integer32 (-1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The preference value for the local interface as a candidate bootstrap router. The value of -1 is used to indicate that the local interface is not a candidate BSR interface." DEFVAL { 0 } ::= { pimInterfaceEntry 9 } -- The PIM Neighbor Table pimNeighborTable OBJECT-TYPE SYNTAX SEQUENCE OF PimNeighborEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the router's PIM neighbors." ::= { pim 3 } pimNeighborEntry OBJECT-TYPE SYNTAX PimNeighborEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimNeighborTable." INDEX { pimNeighborAddress } ::= { pimNeighborTable 1 } McCloghrie, et al. Experimental [Page 7] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 PimNeighborEntry ::= SEQUENCE { pimNeighborAddress IpAddress, pimNeighborIfIndex InterfaceIndex, pimNeighborUpTime TimeTicks, pimNeighborExpiryTime TimeTicks, pimNeighborMode INTEGER } pimNeighborAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the PIM neighbor for which this entry contains information." ::= { pimNeighborEntry 1 } pimNeighborIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the interface used to reach this PIM neighbor." ::= { pimNeighborEntry 2 } pimNeighborUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this PIM neighbor (last) became a neighbor of the local router." ::= { pimNeighborEntry 3 } pimNeighborExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time remaining before this PIM neighbor will be aged out." ::= { pimNeighborEntry 4 } pimNeighborMode OBJECT-TYPE SYNTAX INTEGER { dense(1), sparse(2) } MAX-ACCESS read-only STATUS deprecated McCloghrie, et al. Experimental [Page 8] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 DESCRIPTION "The active PIM mode of this neighbor. This object is deprecated for PIMv2 routers since all neighbors on the interface must be either dense or sparse as determined by the protocol running on the interface." ::= { pimNeighborEntry 5 } -- -- The PIM IP Multicast Route Table -- pimIpMRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF PimIpMRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing PIM-specific information on a subset of the rows of the ipMRouteTable defined in the IP Multicast MIB." ::= { pim 4 } pimIpMRouteEntry OBJECT-TYPE SYNTAX PimIpMRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimIpMRouteTable. There is one entry per entry in the ipMRouteTable whose incoming interface is running PIM." INDEX { ipMRouteGroup, ipMRouteSource, ipMRouteSourceMask } ::= { pimIpMRouteTable 1 } PimIpMRouteEntry ::= SEQUENCE { pimIpMRouteUpstreamAssertTimer TimeTicks, pimIpMRouteAssertMetric Integer32, pimIpMRouteAssertMetricPref Integer32, pimIpMRouteAssertRPTBit TruthValue, pimIpMRouteFlags BITS } pimIpMRouteUpstreamAssertTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the router changes its upstream neighbor back to its RPF neighbor. This timer is called the Assert timer in the PIM Sparse and Dense mode specification. McCloghrie, et al. Experimental [Page 9] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 A value of 0 indicates that no Assert has changed the upstream neighbor away from the RPF neighbor." ::= { pimIpMRouteEntry 1 } pimIpMRouteAssertMetric OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The metric advertised by the assert winner on the upstream interface, or 0 if no such assert is in received." ::= { pimIpMRouteEntry 2 } pimIpMRouteAssertMetricPref OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The preference advertised by the assert winner on the upstream interface, or 0 if no such assert is in effect." ::= { pimIpMRouteEntry 3 } pimIpMRouteAssertRPTBit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the RPT-bit advertised by the assert winner on the upstream interface, or false if no such assert is in effect." ::= { pimIpMRouteEntry 4 } pimIpMRouteFlags OBJECT-TYPE SYNTAX BITS { rpt(0), spt(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes PIM-specific flags related to a multicast state entry. See the PIM Sparse Mode specification for the meaning of the RPT and SPT bits." ::= { pimIpMRouteEntry 5 } -- -- The PIM Next Hop Table -- McCloghrie, et al. Experimental [Page 10] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 pimIpMRouteNextHopTable OBJECT-TYPE SYNTAX SEQUENCE OF PimIpMRouteNextHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing PIM-specific information on a subset of the rows of the ipMRouteNextHopTable defined in the IP Multicast MIB." ::= { pim 7 } pimIpMRouteNextHopEntry OBJECT-TYPE SYNTAX PimIpMRouteNextHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimIpMRouteNextHopTable. There is one entry per entry in the ipMRouteNextHopTable whose interface is running PIM and whose ipMRouteNextHopState is pruned(1)." INDEX { ipMRouteNextHopGroup, ipMRouteNextHopSource, ipMRouteNextHopSourceMask, ipMRouteNextHopIfIndex, ipMRouteNextHopAddress } ::= { pimIpMRouteNextHopTable 1 } PimIpMRouteNextHopEntry ::= SEQUENCE { pimIpMRouteNextHopPruneReason INTEGER } pimIpMRouteNextHopPruneReason OBJECT-TYPE SYNTAX INTEGER { other (1), prune (2), assert (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates why the downstream interface was pruned, whether in response to a PIM prune message or due to PIM Assert processing." ::= { pimIpMRouteNextHopEntry 2 } -- The PIM RP Table pimRPTable OBJECT-TYPE SYNTAX SEQUENCE OF PimRPEntry MAX-ACCESS not-accessible STATUS deprecated McCloghrie, et al. Experimental [Page 11] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 DESCRIPTION "The (conceptual) table listing PIM version 1 information for the Rendezvous Points (RPs) for IP multicast groups. This table is deprecated since its function is replaced by the pimRPSetTable for PIM version 2." ::= { pim 5 } pimRPEntry OBJECT-TYPE SYNTAX PimRPEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) in the pimRPTable. There is one entry per RP address for each IP multicast group." INDEX { pimRPGroupAddress, pimRPAddress } ::= { pimRPTable 1 } PimRPEntry ::= SEQUENCE { pimRPGroupAddress IpAddress, pimRPAddress IpAddress, pimRPState INTEGER, pimRPStateTimer TimeTicks, pimRPLastChange TimeTicks, pimRPRowStatus RowStatus } pimRPGroupAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The IP multicast group address for which this entry contains information about an RP." ::= { pimRPEntry 1 } pimRPAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The unicast address of the RP." ::= { pimRPEntry 2 } pimRPState OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION McCloghrie, et al. Experimental [Page 12] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 "The state of the RP." ::= { pimRPEntry 3 } pimRPStateTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The minimum time remaining before the next state change. When pimRPState is up, this is the minimum time which must expire until it can be declared down. When pimRPState is down, this is the time until it will be declared up (in order to retry)." ::= { pimRPEntry 4 } pimRPLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of sysUpTime at the time when the corresponding instance of pimRPState last changed its value." ::= { pimRPEntry 5 } pimRPRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table." ::= { pimRPEntry 6 } -- The PIM RP-Set Table pimRPSetTable OBJECT-TYPE SYNTAX SEQUENCE OF PimRPSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing PIM information for candidate Rendezvous Points (RPs) for IP multicast groups. When the local router is the BSR, this information is obtained from received Candidate-RP-Advertisements. When the local router is not the BSR, this information is obtained from received RP-Set messages." ::= { pim 6 } McCloghrie, et al. Experimental [Page 13] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 pimRPSetEntry OBJECT-TYPE SYNTAX PimRPSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimRPSetTable." INDEX { pimRPSetComponent, pimRPSetGroupAddress, pimRPSetGroupMask, pimRPSetAddress } ::= { pimRPSetTable 1 } PimRPSetEntry ::= SEQUENCE { pimRPSetGroupAddress IpAddress, pimRPSetGroupMask IpAddress, pimRPSetAddress IpAddress, pimRPSetHoldTime Integer32, pimRPSetExpiryTime TimeTicks, pimRPSetComponent Integer32 } pimRPSetGroupAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address which, when combined with pimRPSetGroupMask, gives the group prefix for which this entry contains information about the Candidate-RP." ::= { pimRPSetEntry 1 } pimRPSetGroupMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group address mask which, when combined with pimRPSetGroupAddress, gives the group prefix for which this entry contains information about the Candidate-RP." ::= { pimRPSetEntry 2 } pimRPSetAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the Candidate-RP." ::= { pimRPSetEntry 3 } McCloghrie, et al. Experimental [Page 14] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 pimRPSetHoldTime OBJECT-TYPE SYNTAX Integer32 (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The holdtime of a Candidate-RP. If the local router is not the BSR, this value is 0." ::= { pimRPSetEntry 4 } pimRPSetExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time remaining before the Candidate-RP will be declared down. If the local router is not the BSR, this value is 0." ::= { pimRPSetEntry 5 } pimRPSetComponent OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION " A number uniquely identifying the component. Each protocol instance connected to a separate domain should have a different index value." ::= { pimRPSetEntry 6 } -- -- Note: { pim 8 } through { pim 10 } were used in older versions -- of this MIB. Since some earlier versions of this MIB have been -- widely-deployed, these values must not be used in the future, -- as long the MIB is rooted under { experimental 61 }. -- -- The PIM Candidate-RP Table pimCandidateRPTable OBJECT-TYPE SYNTAX SEQUENCE OF PimCandidateRPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the IP multicast groups for which the local router is to advertise itself as a Candidate-RP when the value of pimComponentCRPHoldTime is non-zero. If this table is empty, then the local router McCloghrie, et al. Experimental [Page 15] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 will advertise itself as a Candidate-RP for all groups (providing the value of pimComponentCRPHoldTime is non- zero)." ::= { pim 11 } pimCandidateRPEntry OBJECT-TYPE SYNTAX PimCandidateRPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimCandidateRPTable." INDEX { pimCandidateRPGroupAddress, pimCandidateRPGroupMask } ::= { pimCandidateRPTable 1 } PimCandidateRPEntry ::= SEQUENCE { pimCandidateRPGroupAddress IpAddress, pimCandidateRPGroupMask IpAddress, pimCandidateRPAddress IpAddress, pimCandidateRPRowStatus RowStatus } pimCandidateRPGroupAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address which, when combined with pimCandidateRPGroupMask, identifies a group prefix for which the local router will advertise itself as a Candidate-RP." ::= { pimCandidateRPEntry 1 } pimCandidateRPGroupMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group address mask which, when combined with pimCandidateRPGroupMask, identifies a group prefix for which the local router will advertise itself as a Candidate-RP." ::= { pimCandidateRPEntry 2 } pimCandidateRPAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The (unicast) address of the interface which will be McCloghrie, et al. Experimental [Page 16] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 advertised as a Candidate-RP." ::= { pimCandidateRPEntry 3 } pimCandidateRPRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table." ::= { pimCandidateRPEntry 4 } -- The PIM Component Table pimComponentTable OBJECT-TYPE SYNTAX SEQUENCE OF PimComponentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing objects specific to a PIM domain. One row exists for each domain to which the router is connected. A PIM-SM domain is defined as an area of the network over which Bootstrap messages are forwarded. Typically, a PIM-SM router will be a member of exactly one domain. This table also supports, however, routers which may form a border between two PIM-SM domains and do not forward Bootstrap messages between them." ::= { pim 12 } pimComponentEntry OBJECT-TYPE SYNTAX PimComponentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimComponentTable." INDEX { pimComponentIndex } ::= { pimComponentTable 1 } PimComponentEntry ::= SEQUENCE { pimComponentIndex Integer32, pimComponentBSRAddress IpAddress, pimComponentBSRExpiryTime TimeTicks, pimComponentCRPHoldTime Integer32, pimComponentStatus RowStatus } pimComponentIndex OBJECT-TYPE SYNTAX Integer32 (1..255) McCloghrie, et al. Experimental [Page 17] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying the component. Each protocol instance connected to a separate domain should have a different index value. Routers that only support membership in a single PIM-SM domain should use a pimComponentIndex value of 1." ::= { pimComponentEntry 1 } pimComponentBSRAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the bootstrap router (BSR) for the local PIM region." ::= { pimComponentEntry 2 } pimComponentBSRExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time remaining before the bootstrap router in the local domain will be declared down. For candidate BSRs, this is the time until the component sends an RP-Set message. For other routers, this is the time until it may accept an RP-Set message from a lower candidate BSR." ::= { pimComponentEntry 3 } pimComponentCRPHoldTime OBJECT-TYPE SYNTAX Integer32 (0..255) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The holdtime of the component when it is a candidate RP in the local domain. The value of 0 is used to indicate that the local system is not a Candidate-RP." DEFVAL { 0 } ::= { pimComponentEntry 4 } pimComponentStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION McCloghrie, et al. Experimental [Page 18] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 "The status of this entry. Creating the entry creates another protocol instance; destroying the entry disables a protocol instance." ::= { pimComponentEntry 5 } -- PIM Traps pimNeighborLoss NOTIFICATION-TYPE OBJECTS { pimNeighborIfIndex } STATUS current DESCRIPTION "A pimNeighborLoss trap signifies the loss of an adjacency with a neighbor. This trap should be generated when the neighbor timer expires, and the router has no other neighbors on the same interface with a lower IP address than itself." ::= { pimTraps 1 } -- conformance information pimMIBConformance OBJECT IDENTIFIER ::= { pimMIB 2 } pimMIBCompliances OBJECT IDENTIFIER ::= { pimMIBConformance 1 } pimMIBGroups OBJECT IDENTIFIER ::= { pimMIBConformance 2 } -- compliance statements pimV1MIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for routers running PIMv1 and implementing the PIM MIB." MODULE -- this module MANDATORY-GROUPS { pimV1MIBGroup } ::= { pimMIBCompliances 1 } pimSparseV2MIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers running PIM Sparse Mode and implementing the PIM MIB." MODULE -- this module MANDATORY-GROUPS { pimV2MIBGroup } GROUP pimV2CandidateRPMIBGroup McCloghrie, et al. Experimental [Page 19] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 DESCRIPTION "This group is mandatory if the router is capable of being a Candidate RP." OBJECT pimInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { pimMIBCompliances 2 } pimDenseV2MIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers running PIM Dense Mode and implementing the PIM MIB." MODULE -- this module MANDATORY-GROUPS { pimDenseV2MIBGroup } OBJECT pimInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { pimMIBCompliances 3 } -- units of conformance pimNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pimNeighborLoss } STATUS current DESCRIPTION "A collection of notifications for signaling important PIM events." ::= { pimMIBGroups 1 } pimV2MIBGroup OBJECT-GROUP OBJECTS { pimJoinPruneInterval, pimNeighborIfIndex, pimNeighborUpTime, pimNeighborExpiryTime, pimInterfaceAddress, pimInterfaceNetMask, pimInterfaceDR, pimInterfaceHelloInterval, pimInterfaceStatus, pimInterfaceJoinPruneInterval, pimInterfaceCBSRPreference, pimInterfaceMode, pimRPSetHoldTime, pimRPSetExpiryTime, pimComponentBSRAddress, pimComponentBSRExpiryTime, pimComponentCRPHoldTime, pimComponentStatus, pimIpMRouteFlags, pimIpMRouteUpstreamAssertTimer McCloghrie, et al. Experimental [Page 20] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 } STATUS current DESCRIPTION "A collection of objects to support management of PIM Sparse Mode (version 2) routers." ::= { pimMIBGroups 2 } pimDenseV2MIBGroup OBJECT-GROUP OBJECTS { pimNeighborIfIndex, pimNeighborUpTime, pimNeighborExpiryTime, pimInterfaceAddress, pimInterfaceNetMask, pimInterfaceDR, pimInterfaceHelloInterval, pimInterfaceStatus, pimInterfaceMode } STATUS current DESCRIPTION "A collection of objects to support management of PIM Dense Mode (version 2) routers." ::= { pimMIBGroups 5 } pimV2CandidateRPMIBGroup OBJECT-GROUP OBJECTS { pimCandidateRPAddress, pimCandidateRPRowStatus } STATUS current DESCRIPTION "A collection of objects to support configuration of which groups a router is to advertise itself as a Candidate-RP." ::= { pimMIBGroups 3 } pimV1MIBGroup OBJECT-GROUP OBJECTS { pimJoinPruneInterval, pimNeighborIfIndex, pimNeighborUpTime, pimNeighborExpiryTime, pimNeighborMode, pimInterfaceAddress, pimInterfaceNetMask, pimInterfaceJoinPruneInterval, pimInterfaceStatus, pimInterfaceMode, pimInterfaceDR, pimInterfaceHelloInterval, pimRPState, pimRPStateTimer, pimRPLastChange, pimRPRowStatus } STATUS deprecated DESCRIPTION "A collection of objects to support management of PIM (version 1) routers." ::= { pimMIBGroups 4 } pimNextHopGroup OBJECT-GROUP McCloghrie, et al. Experimental [Page 21] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 OBJECTS { pimIpMRouteNextHopPruneReason } STATUS current DESCRIPTION "A collection of optional objects to provide per-next hop information for diagnostic purposes. Supporting this group may add a large number of instances to a tree walk, but the information in this group can be extremely useful in tracking down multicast connectivity problems." ::= { pimMIBGroups 6 } pimAssertGroup OBJECT-GROUP OBJECTS { pimIpMRouteAssertMetric, pimIpMRouteAssertMetricPref, pimIpMRouteAssertRPTBit } STATUS current DESCRIPTION "A collection of optional objects to provide extra information about the assert election process. There is no protocol reason to keep such information, but some implementations may already keep this information and make it available. These objects can also be very useful in debugging connectivity or duplicate packet problems, especially if the assert winner does not support the PIM and IP Multicast MIBs." ::= { pimMIBGroups 7 } END 5. Security Considerations This MIB contains readable objects whose values provide information related to multicast routing, including information on the network topology. There are also a number of objects that have a MAX-ACCESS clause of read-write and/or read-create, which allow an administrator to configure PIM in the router. While unauthorized access to the readable objects is relatively innocuous, unauthorized access to the write-able objects could cause a denial of service. Hence, the support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB. McCloghrie, et al. Experimental [Page 22] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 6. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgements This MIB module has been updated based on feedback from the IETF's Inter-Domain Multicast Routing (IDMR) Working Group. McCloghrie, et al. Experimental [Page 23] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 8. Authors' Addresses Keith McCloghrie cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 Phone: +1 408 526 5260 EMail: kzm@cisco.com Dino Farinacci Procket Networks 3850 North First Street San Jose, CA 95134 Phone: +1 408-954-7909 Email: dino@procket.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com Bill Fenner AT&T Labs - Research 75 Willow Rd. Menlo Park, CA 94025 Phone: +1 650 330 7893 EMail: fenner@research.att.com 9. References [1] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. McCloghrie, et al. Experimental [Page 24] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, G. and L. Wei, "Protocol Independent Multicast (PIM): Motivation and Architecture", Work in Progress. McCloghrie, et al. Experimental [Page 25] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 [17] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, G. and L. Wei, "Protocol Independent Multicast (PIM): Protocol Specification", Work in Progress. [18] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [19] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, A. and L. Wei, "Protocol Independent Multicast Version 2, Dense Mode Specification", Work in Progress. [20] McCloghrie, K., Farinacci, D. and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000. McCloghrie, et al. Experimental [Page 26] RFC 2934 Protocol Independent Multicast MIB for IPv4 October 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McCloghrie, et al. Experimental [Page 27] snmp-mibs-downloader-1.1/mibrfcs/rfc2940.txt0000644000000000000000000014631311402176071015570 0ustar Network Working Group A. Smith Request for Comments: 2940 Consultant Category: Standards Track D. Partain Ericsson J. Seligson Nortel Networks October 2000 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. This memo includes a MIB module in a manner that is compliant to the SMIv2 [V2SMI]. Smith Standards Track [Page 1] RFC 2940 COPS Client MIB October 2000 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in an Architecture for Describing SNMP Management Frameworks [ARCH]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC 1215 [V1TRAPS]. The second version, called SMIv2, is described in STD 58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD 58, RFC 2580 [V2CONFORM]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [V1PROTO]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [V2COMMUNITY] and RFC 1906 [V2TRANS]. The third version of the message protocol is called SNMPv3 and described in RFC1906 [V2TRANS], Message Processing and Dispatching [V3MPC] and User-based Security Model [V3USM]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [V1PROTO]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [V2PROTO]. o A set of fundamental applications described in SNMPv3 Applications [V3APPS] and the view-based access control mechanism described in View-based Access Control Model [V3VACM]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [V3INTRO]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no Smith Standards Track [Page 2] RFC 2940 COPS Client MIB October 2000 translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview The COPS protocol [COPS] is a client-server protocol intended for the communication of policy requests and decisions between a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). The PEP acts as a COPS client in this scenario. The model for policy out- sourcing, of which the COPS protocol provides one part, is described in [FRAMEWORK]. 2.1. Scope This MIB is intended to provide management of the important features of a COPS protocol client module. It does not provide management for a COPS server - this is outside the scope of the current memo. It provides for monitoring of status and protocol statistics, as well as for configuration of the client, in particular for telling it where to locate its servers. Other mechanisms for achieving this function without SNMP configuration might include use of the Service Location Protocol [SRVLOC] although this is outside the scope of this memo and are not specified by the COPS protocol itself. This MIB also does not provide management of specific COPS client- types e.g., for use with the RSVP protocol [RSVP][COPSRSVP]. 3. Structure of COPS Client MIB Objects in this MIB are arranged into groups. Each group is organized as a set of related objects. The overall structure is described below. 3.1. copsClientCapabilitiesGroup This group contains objects that represent COPS protocol capabilities implemented by this COPS client. 3.2. copsClientStatusGroup This group contains objects that indicate the current status of connection(s) to COPS servers, including per-server protocol statistics. It maintains last-known statistics for all of the servers with which the client has ever been connected since agent restart. Smith Standards Track [Page 3] RFC 2940 COPS Client MIB October 2000 3.3. copsConfigGroup This group contains objects that allow for configuration of COPS server addresses and the order to which connections should be attempted. It contains a table of per-server objects as well as scalars for configuration of the retry algorithm to be used by a client to obtain a connection to an appropriate server. 3.4. Textual Conventions The datatypes CopsClientState, CopsServerEntryType, CopsErrorCode, CopsTcpPort and CopsAuthType are used as textual conventions in this document. These textual conventions have NO effect on either the syntax nor the semantics of any managed object. Objects defined using these conventions are always encoded by means of the rules that define their primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers. 3.5. Relationship to Other MIBs 3.5.1. Relationship to the 'system' group This MIB contains definitions for a single COPS protocol client represented by a single SNMP agent and instance of the MIB-2 system group [MIB2]. It does not address the case of multiple co-located COPS protocol clients. 4. Definitions for COPS Client MIB COPS-CLIENT-MIB DEFINITIONS ::= BEGIN -- ------------------------------------------------------------- -- ------------------------------------------------------------- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI TimeStamp, TimeInterval, RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress FROM INET-ADDRESS-MIB; -- REFERENCE Smith Standards Track [Page 4] RFC 2940 COPS Client MIB October 2000 -- "The COPS (Common Open Policy Service) Protocol RFC 2748 copsClientMIB MODULE-IDENTITY LAST-UPDATED "200009280000Z" ORGANIZATION "IETF RSVP Admission Policy Working Group" CONTACT-INFO " Andrew Smith (WG co-chair) Phone: +1 408 579 2821 Email: ah_smith@pacbell.net Mark Stevens (WG co-chair) Phone: +1 978 287 9102 Email: markstevens@lucent.com Editor: Andrew Smith Phone: +1 408 579 2821 Email: ah_smith@pacbell.net Editor: David Partain Phone: +46 13 28 41 44 Email: David.Partain@ericsson.com Editor: John Seligson Phone: +1 408 495 2992 Email: jseligso@nortelnetworks.com" DESCRIPTION "The COPS Client MIB module" REVISION "200009280000Z" DESCRIPTION "This version published as RFC 2940" ::= { mib-2 89 } copsClientMIBObjects OBJECT IDENTIFIER ::= { copsClientMIB 1 } -- ------------------------------------------------------------- -- Textual Conventions -- ------------------------------------------------------------- CopsClientState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value indicating the state of a COPS client." SYNTAX INTEGER { copsClientInvalid(1), -- default state. copsClientTcpconnected(2), -- TCP connection up but COPS -- not yet open. Smith Standards Track [Page 5] RFC 2940 COPS Client MIB October 2000 copsClientAuthenticating(3), -- TCP connection up but still -- authenticating. copsClientSecAccepted(4), -- connection authenticated. copsClientAccepted(5), -- COPS server accepted client. copsClientTimingout(6) -- Keepalive timer has expired, -- client is in process of -- tearing down connection. } CopsServerEntryType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value indicating how a COPS server entry came into existence." SYNTAX INTEGER { copsServerStatic(1), -- configured by manager copsServerRedirect(2) -- notified by COPS server } CopsErrorCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value describing a COPS protocol error. Codes are identical to those used by the COPS protocol itself." SYNTAX INTEGER { errorOther(0), -- none of the below errorBadHandle(1), errorInvalidHandleReference(2), errorBadMessageFormat(3), errorUnableToProcess(4), errorMandatoryClientSiMissing(5), errorUnsupportedClientType(6), errorMandatoryCopsObjectMissing(7), errorClientFailure(8), errorCommunicationFailure(9), errorUnspecified(10), -- client-type specific subcode errorShuttingDown(11), errorRedirectToPreferredServer(12), errorUnknownCopsObject(13), errorAuthenticationFailure(14), errorAuthenticationMissing(15) } -- REFERENCE -- "RFC 2748 section 2.2.8" CopsTcpPort ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value indicating a TCP protocol port number." Smith Standards Track [Page 6] RFC 2940 COPS Client MIB October 2000 SYNTAX INTEGER (0..65535) CopsAuthType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value indicating a type of security authentication mechanism." SYNTAX INTEGER { authNone(0), authOther(1), authIpSecAh(2), authIpSecEsp(3), authTls(4), authCopsIntegrity(5) } -- ------------------------------------------------------------- copsClientCapabilitiesGroup OBJECT IDENTIFIER ::= { copsClientMIBObjects 1 } -- ------------------------------------------------------------- -- -- Capabilities of the COPS client to connect to a COPS server: -- copsClientCapabilities OBJECT-TYPE SYNTAX BITS { copsClientVersion1(0), -- supports version1 of COPS protocol copsClientAuthIpSecAh(1) , -- supports IP-SEC Authentication copsClientAuthIpSecEsp(2), -- supports IP-SEC Encryption copsClientAuthTls(3), -- supports Transport-Layer Security copsClientAuthInteg(4) -- supports COPS Integrity } MAX-ACCESS read-only STATUS current DESCRIPTION "A list of the optional capabilities that this COPS client supports." ::= { copsClientCapabilitiesGroup 1 } -- ------------------------------------------------------------- copsClientStatusGroup OBJECT IDENTIFIER ::= { copsClientMIBObjects 2 } -- ------------------------------------------------------------- -- -- Current status of COPS server connections, all read-only. -- Smith Standards Track [Page 7] RFC 2940 COPS Client MIB October 2000 copsClientServerCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF CopsClientServerCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information regarding COPS servers as seen from the point of view of a COPS client. This table contains entries for both statically-configured and dynamically-learned servers (from a PDP Redirect operation). One entry exists in this table for each COPS Client-Type served by the COPS server. In addition, an entry will exist with copsClientServerClientType 0 (zero) representing information about the underlying connection itself: this is consistent with the COPS specification which reserves this value for this purpose." ::= { copsClientStatusGroup 1 } copsClientServerCurrentEntry OBJECT-TYPE SYNTAX CopsClientServerCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of information regarding a single COPS server serving a single COPS Client-Type from the point of view of a COPS client." INDEX { copsClientServerAddressType, copsClientServerAddress, copsClientServerClientType } ::= { copsClientServerCurrentTable 1 } CopsClientServerCurrentEntry ::= SEQUENCE { copsClientServerAddressType InetAddressType, copsClientServerAddress InetAddress, copsClientServerClientType INTEGER, copsClientServerTcpPort CopsTcpPort, copsClientServerType CopsServerEntryType, copsClientServerAuthType CopsAuthType, copsClientServerLastConnAttempt TimeStamp, copsClientState CopsClientState, copsClientServerKeepaliveTime TimeInterval, copsClientServerAccountingTime TimeInterval, copsClientInPkts Counter32, copsClientOutPkts Counter32, copsClientInErrs Counter32, copsClientLastError CopsErrorCode, copsClientTcpConnectAttempts Counter32, copsClientTcpConnectFailures Counter32, copsClientOpenAttempts Counter32, Smith Standards Track [Page 8] RFC 2940 COPS Client MIB October 2000 copsClientOpenFailures Counter32, copsClientErrUnsupportClienttype Counter32, copsClientErrUnsupportedVersion Counter32, copsClientErrLengthMismatch Counter32, copsClientErrUnknownOpcode Counter32, copsClientErrUnknownCnum Counter32, copsClientErrBadCtype Counter32, copsClientErrBadSends Counter32, copsClientErrWrongObjects Counter32, copsClientErrWrongOpcode Counter32, copsClientKaTimedoutClients Counter32, copsClientErrAuthFailures Counter32, copsClientErrAuthMissing Counter32 } copsClientServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of address in copsClientServerAddress." ::= { copsClientServerCurrentEntry 1 } copsClientServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv4, IPv6 or DNS address of a COPS Server. Note that, since this is an index to the table, the DNS name must be short enough to fit into the maximum length of indices allowed by the management protocol in use." REFERENCE "RFC 2748 section 2.3" ::= { copsClientServerCurrentEntry 2 } copsClientServerClientType OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The COPS protocol Client-Type for which this entry applies. Multiple Client-Types can be served by a single COPS server. The value 0 (zero) indicates that this entry contains information about the underlying connection itself." REFERENCE "RFC 2748 section 6, IANA" Smith Standards Track [Page 9] RFC 2940 COPS Client MIB October 2000 ::= { copsClientServerCurrentEntry 3 } copsClientServerTcpPort OBJECT-TYPE SYNTAX CopsTcpPort MAX-ACCESS read-only STATUS current DESCRIPTION "The TCP port number on the COPS server to which the client should connect/is connected." ::= { copsClientServerCurrentEntry 4 } copsClientServerType OBJECT-TYPE SYNTAX CopsServerEntryType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicator of the source of this COPS server information. COPS servers may be configured by network management into copsClientServerConfigTable and appear in this entry with type copsServerStatic(1). Alternatively, the may be notified from another COPS server by means of the COPS PDP-Redirect mechanism and appear as copsServerRedirect(2)." ::= { copsClientServerCurrentEntry 5 } copsClientServerAuthType OBJECT-TYPE SYNTAX CopsAuthType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicator of the current security mode in use between client and this COPS server." ::= { copsClientServerCurrentEntry 6 } copsClientServerLastConnAttempt OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Timestamp of the last time that this client attempted to connect to this COPS server." ::= { copsClientServerCurrentEntry 7 } copsClientState OBJECT-TYPE SYNTAX CopsClientState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the connection and COPS protocol with respect Smith Standards Track [Page 10] RFC 2940 COPS Client MIB October 2000 to this COPS server." ::= { copsClientServerCurrentEntry 8 } copsClientServerKeepaliveTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the COPS protocol Keepalive timeout, in centiseconds, currently in use by this client, as specified by this COPS server in the Client-Accept operation. A value of zero indicates no keepalive activity is expected." REFERENCE "RFC 2748 section 3.7, 4.4" ::= { copsClientServerCurrentEntry 9 } copsClientServerAccountingTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the COPS protocol Accounting timeout, in centiseconds, currently in use by this client, as specified by the COPS server in the Client-Accept operation. A value of zero indicates no accounting activity is to be performed." REFERENCE "RFC 2748 section 3.7" ::= { copsClientServerCurrentEntry 10 } copsClientInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from this COPS server marked for this Client-Type. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 11 } copsClientOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has sent to this COPS server marked for this Client-Type. This value is cumulative since agent restart and is not zeroed on new Smith Standards Track [Page 11] RFC 2940 COPS Client MIB October 2000 connections." ::= { copsClientServerCurrentEntry 12 } copsClientInErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from this COPS server marked for this Client-Type that contained errors in syntax. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 13 } copsClientLastError OBJECT-TYPE SYNTAX CopsErrorCode MAX-ACCESS read-only STATUS current DESCRIPTION "The code contained in the last COPS protocol Error Object received by this client from this COPS server marked for this Client-Type. This value is not zeroed on COPS Client-Open operations." REFERENCE "RFC 2748 section 2.2.8" ::= { copsClientServerCurrentEntry 14 } copsClientTcpConnectAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that this COPS client has tried (successfully or otherwise) to open an TCP connection to a COPS server. This value is cumulative since agent restart and is not zeroed on new connections. This value is not incremented for entries representing a non-zero Client-Type." ::= { copsClientServerCurrentEntry 15 } copsClientTcpConnectFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that this COPS client has failed to open an TCP connection to a COPS server. This value is cumulative since agent restart and is not zeroed on new connections. This value is not incremented for Smith Standards Track [Page 12] RFC 2940 COPS Client MIB October 2000 entries representing a non-zero Client-Type." ::= { copsClientServerCurrentEntry 16 } copsClientOpenAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that this COPS client has tried to perform a COPS Client-Open to a COPS server for this Client-Type. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 17 } copsClientOpenFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that this COPS client has failed to perform a COPS Client-Open to a COPS server for this Client-Type. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 18 } copsClientErrUnsupportClienttype OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers that referred to Client-Types that are unsupported by this client. This value is cumulative since agent restart and is not zeroed on new connections. This value is not incremented for entries representing a non-zero Client-Type." ::= { copsClientServerCurrentEntry 19 } copsClientErrUnsupportedVersion OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers marked for this Client-Type that had a COPS protocol Version number that is unsupported by this client. This value is cumulative since agent restart and is not zeroed on new connections." Smith Standards Track [Page 13] RFC 2940 COPS Client MIB October 2000 ::= { copsClientServerCurrentEntry 20 } copsClientErrLengthMismatch OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers marked for this Client-Type that had a COPS protocol Message Length that did not match the actual received message. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 21 } copsClientErrUnknownOpcode OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers marked for this Client-Type that had a COPS protocol Op Code that was unrecognised by this client. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 22 } copsClientErrUnknownCnum OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers marked for this Client-Type that contained a COPS protocol object C-Num that was unrecognised by this client. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 23 } copsClientErrBadCtype OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers marked for this Client-Type that contained a COPS protocol object C-Type that was not defined for the C-Nums known by this client. This value is cumulative since agent restart and is not zeroed on new connections." Smith Standards Track [Page 14] RFC 2940 COPS Client MIB October 2000 ::= { copsClientServerCurrentEntry 24 } copsClientErrBadSends OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client attempted to send to COPS servers marked for this Client-Type that resulted in a transmit error. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 25 } copsClientErrWrongObjects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers marked for this Client-Type that did not contain a permitted set of COPS protocol objects. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 26 } copsClientErrWrongOpcode OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of COPS messages that this client has received from COPS servers marked for this Client-Type that had a COPS protocol Op Code that should not have been sent to a COPS client e.g. Open-Requests. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 27 } copsClientKaTimedoutClients OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of times that this client has been shut down for this Client-Type by COPS servers that had detected a COPS protocol Keepalive timeout. This value is cumulative since agent restart and is not zeroed on new connections." ::= { copsClientServerCurrentEntry 28 } Smith Standards Track [Page 15] RFC 2940 COPS Client MIB October 2000 copsClientErrAuthFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of times that this client has received a COPS message marked for this Client-Type which could not be authenticated using the authentication mechanism used by this client." ::= { copsClientServerCurrentEntry 29 } copsClientErrAuthMissing OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of times that this client has received a COPS message marked for this Client-Type which did not contain authentication information." ::= { copsClientServerCurrentEntry 30 } -- ------------------------------------------------------------- copsClientConfigGroup OBJECT IDENTIFIER ::= { copsClientMIBObjects 3 } -- ------------------------------------------------------------- copsClientServerConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF CopsClientServerConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of possible COPS servers to try to connect to in order of copsClientServerConfigPriority. There may be multiple entries in this table for the same server and client-type which specify different security mechanisms: these mechanisms will be attempted by the client in the priority order given. Note that a server learned by means of PDPRedirect always takes priority over any of these configured entries." ::= { copsClientConfigGroup 1 } copsClientServerConfigEntry OBJECT-TYPE SYNTAX CopsClientServerConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of configuration information regarding a single Smith Standards Track [Page 16] RFC 2940 COPS Client MIB October 2000 COPS server from the point of view of a COPS client." INDEX { copsClientServerConfigAddrType, copsClientServerConfigAddress, copsClientServerConfigClientType, copsClientServerConfigAuthType } ::= { copsClientServerConfigTable 1 } CopsClientServerConfigEntry ::= SEQUENCE { copsClientServerConfigAddrType InetAddressType, copsClientServerConfigAddress InetAddress, copsClientServerConfigClientType INTEGER, copsClientServerConfigAuthType CopsAuthType, copsClientServerConfigTcpPort CopsTcpPort, copsClientServerConfigPriority Integer32, copsClientServerConfigRowStatus RowStatus } copsClientServerConfigAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of address in copsClientServerConfigAddress." ::= { copsClientServerConfigEntry 1 } copsClientServerConfigAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv4, IPv6 or DNS address of a COPS Server. Note that, since this is an index to the table, the DNS name must be short enough to fit into the maximum length of indices allowed by the management protocol in use." REFERENCE "RFC 2748 section 2.3" ::= { copsClientServerConfigEntry 2 } copsClientServerConfigClientType OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The COPS protocol Client-Type for which this entry applies and for which this COPS server is capable of serving. Multiple Client-Types can be served by a single COPS server." Smith Standards Track [Page 17] RFC 2940 COPS Client MIB October 2000 REFERENCE "RFC 2748 section 6, IANA" ::= { copsClientServerConfigEntry 3 } copsClientServerConfigAuthType OBJECT-TYPE SYNTAX CopsAuthType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of authentication mechanism for this COPS client to request when negotiating security at the start of a connection to a COPS server." REFERENCE "RFC 2748 section 4." ::= { copsClientServerConfigEntry 4 } copsClientServerConfigTcpPort OBJECT-TYPE SYNTAX CopsTcpPort MAX-ACCESS read-create STATUS current DESCRIPTION "The TCP port number on the COPS server to which the client should connect." ::= { copsClientServerConfigEntry 5 } copsClientServerConfigPriority OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The priority of this entry relative to other entries. COPS client will attempt to contact COPS servers for the appropriate Client-Type. Higher numbers are tried first. The order to be used amongst server entries with the same priority is undefined. COPS servers that are notified to the client using the COPS protocol PDP-Redirect mechanism are always used in preference to any entries in this table." ::= { copsClientServerConfigEntry 6 } copsClientServerConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "State of this entry in the table." ::= { copsClientServerConfigEntry 7 } Smith Standards Track [Page 18] RFC 2940 COPS Client MIB October 2000 copsClientServerConfigRetryAlgrm OBJECT-TYPE SYNTAX INTEGER { other(1), sequential(2), roundRobin(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The algorithm by which the client should retry when it fails to connect to a COPS server." DEFVAL { sequential } ::= { copsClientConfigGroup 2 } copsClientServerConfigRetryCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "A retry count for use by the retry algorithm. Each retry algorithm needs to specify how it uses this value. For the 'sequential(2)' algorithm, this value is the number of times the client should retry to connect to one COPS server before moving on to another. For the 'roundRobin(3)' algorithm, this value is not used." DEFVAL { 1 } ::= { copsClientConfigGroup 3 } copsClientServerConfigRetryIntvl OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "A retry interval for use by the retry algorithm. Each retry algorithm needs to specify how it uses this value. For the 'sequential(2)' algorithm, this value is the time to wait between retries of a connection to the same COPS server. For the 'roundRobin(3)' algorithm, the client always attempts to connect to each Server in turn, until one succeeds or they all fail; if they all fail, then the client waits for the value of this interval before restarting the algorithm." DEFVAL { 1000 } ::= { copsClientConfigGroup 4 } Smith Standards Track [Page 19] RFC 2940 COPS Client MIB October 2000 -- ------------------------------------------------------------- -- Conformance Information -- ------------------------------------------------------------- copsClientConformance OBJECT IDENTIFIER ::= { copsClientMIB 2 } copsClientGroups OBJECT IDENTIFIER ::= { copsClientConformance 1 } copsClientCompliances OBJECT IDENTIFIER ::= { copsClientConformance 2 } -- ------------------------------------------------------------- -- units of conformance -- ------------------------------------------------------------- copsDeviceStatusGroup OBJECT-GROUP OBJECTS { copsClientCapabilities, copsClientServerTcpPort, copsClientServerType, copsClientServerAuthType, copsClientServerLastConnAttempt, copsClientState, copsClientServerKeepaliveTime, copsClientServerAccountingTime, copsClientInPkts, copsClientOutPkts, copsClientInErrs, copsClientLastError, copsClientTcpConnectAttempts, copsClientTcpConnectFailures, copsClientOpenAttempts, copsClientOpenFailures, copsClientErrUnsupportClienttype, copsClientErrUnsupportedVersion, copsClientErrLengthMismatch, copsClientErrUnknownOpcode, copsClientErrUnknownCnum, copsClientErrBadCtype, copsClientErrBadSends, copsClientErrWrongObjects, copsClientErrWrongOpcode, copsClientKaTimedoutClients, copsClientErrAuthFailures, copsClientErrAuthMissing } STATUS current DESCRIPTION "A collection of objects for monitoring the status of connections to COPS servers and statistics for a COPS client." ::= { copsClientGroups 1 } copsDeviceConfigGroup OBJECT-GROUP OBJECTS { copsClientServerConfigTcpPort, copsClientServerConfigPriority, copsClientServerConfigRowStatus, copsClientServerConfigRetryAlgrm, copsClientServerConfigRetryCount, copsClientServerConfigRetryIntvl } STATUS current DESCRIPTION "A collection of objects for configuring COPS server Smith Standards Track [Page 20] RFC 2940 COPS Client MIB October 2000 information." ::= { copsClientGroups 2 } -- ------------------------------------------------------------- -- compliance statements -- ------------------------------------------------------------- copsClientCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for device support of management of the COPS client." MODULE MANDATORY-GROUPS { copsDeviceStatusGroup, copsDeviceConfigGroup } OBJECT copsClientServerConfigTcpPort MIN-ACCESS read-only DESCRIPTION "Write access is required only if the device supports the configuration of COPS server information." OBJECT copsClientServerConfigPriority MIN-ACCESS read-only DESCRIPTION "Write access is required only if the device supports the configuration of COPS server information." OBJECT copsClientServerConfigRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is required only if the device supports the configuration of COPS server information." OBJECT copsClientServerConfigRetryAlgrm MIN-ACCESS read-only DESCRIPTION "Write access is required only if the device supports the configuration of COPS server information." OBJECT copsClientServerConfigRetryCount MIN-ACCESS read-only DESCRIPTION "Write access is required only if the device supports the configuration of COPS server information." Smith Standards Track [Page 21] RFC 2940 COPS Client MIB October 2000 OBJECT copsClientServerConfigRetryIntvl MIN-ACCESS read-only DESCRIPTION "Write access is required only if the device supports the configuration of COPS server information." ::= { copsClientCompliances 1 } END 5. Acknowledgments This document describes instrumentation for the client side of the COPS protocol which was defined by the RSVP Admission Policy (rap) Working Group, now known as the Resource Allocation Protocol (rap) Working Group. 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [USM] and the View-based Access Control Model [VACM] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Smith Standards Track [Page 22] RFC 2940 COPS Client MIB October 2000 7. References [ARCH] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [V1PROTO] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [V1SMI] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP- based Internets", STD 16, RFC 1155, May 1990. [V1CONCISE] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [V1TRAPS] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [V2TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [V2CONFORM] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [V2COMMUNITY] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [V2TRANS] 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. [V2PROTO] 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. Smith Standards Track [Page 23] RFC 2940 COPS Client MIB October 2000 [V3INTRO] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [V3MPC] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [V3USM] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [V3APPS] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [V3VACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [MIB2] McCloghrie K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213, March 1991. [FRAMEWORK] Yavatkar, R., Pendarakis, D. and Guerin, R., "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [RSVP] Braden, R. ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC 2205, September 1997. [COPSRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000. [SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [ADDRESSMIB] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. Smith Standards Track [Page 24] RFC 2940 COPS Client MIB October 2000 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 8. Authors' Addresses Andrew Smith Fax: +1 415 345 1827 Email: ah_smith@pacbell.net David Partain Ericsson Radio Systems Research and Innovation P.O. Box 1248 SE-581 12 Linkoping Sweden Phone: +46 13 28 41 44 EMail: David.Partain@ericsson.com John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 2992 EMail: jseligso@nortelnetworks.com Smith Standards Track [Page 25] RFC 2940 COPS Client MIB October 2000 9. Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Smith Standards Track [Page 26] RFC 2940 COPS Client MIB October 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Smith Standards Track [Page 27] snmp-mibs-downloader-1.1/mibrfcs/rfc2954.txt0000644000000000000000000050057111402176071015575 0ustar Network Working Group K. Rehbehn Request for Comments: 2954 Megisto Systems Obsoletes: 1604 D. Fowler Category: Standards Track Syndesis Limited October 2000 Definitions of Managed Objects for Frame Relay Service 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. This document obsoletes RFC 1604. Table of Contents 1 The SNMP Management Framework ................................ 2 2 Overview ..................................................... 3 2.1 Scope of MIB ............................................... 3 2.2 Transiting Multiple Frame Relay Networks ................... 5 2.3 Access Control ............................................. 5 2.4 Frame Relay Service MIB Terminology ........................ 6 2.5 Relation to Other MIBs ..................................... 8 2.5.1 System Group ............................................. 8 2.5.2 Interfaces Table (ifTable, ifXtable) ..................... 8 2.5.3 Stack Table for DS1/E1 Environment ....................... 12 2.5.4 Stack Table for V.35 Environments ........................ 14 2.5.5 The Frame Relay/ATM PVC Service Interworking MIB ......... 14 2.6 Textual Convention Change .................................. 15 3 Object Definitions ........................................... 15 3.1 The Frame Relay Service Logical Port ....................... 17 Rehbehn & Fowler Standards Track [Page 1] RFC 2954 Frame Relay Service MIB October 2000 3.2 Frame Relay Management VC Signaling ........................ 22 3.3 Frame Relay PVC End-Points ................................. 32 3.4 Frame Relay PVC Connections ................................ 45 3.5 Frame Relay Accounting ..................................... 53 3.6 Frame Relay Network Service Notifications .................. 56 3.7 Conformance Information .................................... 57 4 Acknowledgments .............................................. 67 5 References ................................................... 67 6 Security Considerations ...................................... 69 7 Authors' Addresses ........................................... 70 APPENDIX A Update Information .................................. 71 Intellectual Property Rights ................................... 75 Full Copyright Statement ....................................... 76 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. Rehbehn & Fowler Standards Track [Page 2] RFC 2954 Frame Relay Service MIB October 2000 A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview These objects are used to manage a frame relay Service. At present, this applies to the following value of the ifType variable in the IF-MIB [26]: frameRelayService (44) This section provides an overview and background of how to use this MIB and other potential MIBs to manage a frame relay service. 2.1. Scope of MIB The Frame Relay Service MIB supports Customer Network Management (CNM) of a frame relay network service. Through the use of this and other related MIBs, a frame relay service customer's NMS can monitor the customer's UNI/NNI logical ports and PVCs. It provides customers with access to configuration data, performance monitoring information, and fault detection for the delivered frame relay service. As an option, an SNMP agent supporting the Frame Relay Service MIB may allow customer-initiated PVC management operations such as creation, deletion, modification, activation, and deactivation of individual PVCs. However, internal aspects of the network (e.g., switching elements, line cards, and network routing tables) are beyond the scope of this MIB. The Frame Relay Service MIB models all interfaces and PVCs delivered by a frame relay service within a single virtual SNMP system for the purpose of comprehensively representing the customer's frame relay service. The customer's interfaces and PVCs may physically exist on one or more devices within the network topology. An SNMP agent Rehbehn & Fowler Standards Track [Page 3] RFC 2954 Frame Relay Service MIB October 2000 providing support for the Frame Relay Service MIB as well as other appropriate MIBs to model a single virtual frame relay network service is referred to as a Frame Relay Service (FRS) agent. Internal communication mechanisms between the FRS agent and individual devices within the frame relay network delivering the service are implementation specific and beyond the scope of this MIB. The customer's NMS will typically access the SNMP agent implementing the Frame Relay Service MIB over a frame relay permanent virtual connection (PVC). SNMP access over a frame relay PVC is achieved through the use of SNMP over UDP over IP encapsulated in Frame Relay according to STD 55, RFC2427 and ITU X.36 Annex D [23]. Alternate access mechanisms and SNMP agent implementations are possible. This MIB will NOT be implemented on user equipment (e.g., DTE). Such devices are managed using the Frame Relay DTE MIB (RFC2115[18]). However, concentrators may use the Frame Relay Service MIB instead of the Frame Relay DTE MIB. This MIB does not define managed objects for the physical layer. Existing physical layer MIBs (e.g., DS1 MIB) and Interface MIB will be used as needed in FRS Agent implementations. This MIB supports frame relay PVCs. This MIB may be extended at a later time to handle frame relay SVCs. A switch implementation may support this MIB for the purpose of configuration and control of the frame relay service beyond the scope of traditional customer network management applications. A number of objects (e.g. frLportTypeAdmin) support administrative actions that impact the operation of frame relay switch equipment in the network. This is reflected in the differences between the two MIB compliance modules: o the frame relay service compliance module (frnetservCompliance), and o the frame relay switch compliance module (frnetSwitchCompliance). The frame relay service compliance module does not support the administrative control objects used for switch management. Rehbehn & Fowler Standards Track [Page 4] RFC 2954 Frame Relay Service MIB October 2000 2.2. Transiting Multiple Frame Relay Networks This MIB is only used to manage a single frame relay service offering from one network service provider. Therefore, if a customer PVC traverses multiple networks, then the customer must poll a different FRS agent within each frame relay network to retrieve the end-to-end view of service. Figure 1 illustrates a customer ("User B") NMS accessing FRS agents in three different frame relay networks (I, J, and K). +-------------------------------------+ | Customer Network Management Station | | (SNMP based) | +-------------------------------------+ ^ ^ ^ | | | | | | UNI | NNI | NNI | UNI | ^ | ^ | ^ | +-----------+ | +-----------+ | +-----------+ | | | | | | | | | | | Originating | | FR | | | FR | | | FR | |Terminating +--------+ | | Network I | | | Network J | | | Network K | | +--------+ | | | | | | | | | | | | | | | |---| |---| |---| |---| User B | | | | | | | | | | | | | | | | //////////////////////////////////////////////////////////// | | | | | | | | | | | | | | | +--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+ | | | | | | | | | PVC Segment 1 | PVC Segment 2 | PVC Segment 3 | |<------------->|<------------->|<------------->| | | | Multi-network PVC | |<--------------------------------------------->| | NNI = Network-to Network Interface | UNI = User-to-Network Interface Figure 1, Multi-network PVC 2.3. Access Control A frame relay network is shared amongst many frame relay subscribers. Each subscriber will only have access to their information (e.g., information with respect to their interfaces and PVCs). The FRS agent should provide instance level granularity for MIB views. Rehbehn & Fowler Standards Track [Page 5] RFC 2954 Frame Relay Service MIB October 2000 2.4. Frame Relay Service MIB Terminology Access Channel - An access channel generically refers to the DS1/E1 or DS3/E3-based UNI access channel or NNI access channel across which frame relay data transits. An access channel is the access pathway for a single stream of user data. Within a given DS1 line, an access channel can denote any one of the following: o Unchannelized DS1 - the entire DS1 line is considered an access channel. Each access channel is comprised of 24 DS0 time slots. o Channelized DS1 - an access channel is any one of 24 channels. Each access channel is comprised of a single DS0 time slot. o Fractional DS1 - an access channel is a grouping of NxDS0 time slots (NX56/64 Kbps, where N = 1-23 DS0 Time slots per Fractional DS1 Access Channel) that may be assigned in consecutive or non-consecutive order. Within a given E1 line, a channel can denote any one of the following: o Unchannelized E1 - the entire E1 line is considered a single access channel. Each access channel is comprised of 31 E1 time slots. o Channelized E1 - an access channel is any one of 31 channels. Each access channel is comprised of a single E1 time slot. o Fractional E1 - an access channel is a grouping of N E1 time slots (NX64 Kbps, where N = 1-30 E1 time slots per FE1 access channel) that may be assigned in consecutive or non-consecutive order. Within a given unformatted line, the entire unformatted line is considered an access channel. Examples include RS-232, V.35, V.36 and X.21 (non-switched), and unframed E1 (G.703 without G.704). Access Rate - The data rate of the access channel, expressed in bits/second. The speed of the user access channel determines how rapidly the end user can inject data into the network. Bc - The Committed Burst Size (Bc) is the maximum amount of subscriber data (expressed in bits) that the network agrees to transfer, under normal conditions, during a time interval Tc. Rehbehn & Fowler Standards Track [Page 6] RFC 2954 Frame Relay Service MIB October 2000 Be - The Excess Burst Size (Be) is the maximum amount of subscriber data (expressed in bits) in excess of Bc that the network will attempt to deliver during the time interval Tc. This data (Be) is delivered in general with a lower probability than Bc. CIR - The Committed Information Rate (CIR) is the subscriber data rate (expressed in bits/second) that the network commits to deliver under normal network conditions. CIR is averaged over the time interval Tc (CIR = Bc/Tc). DLCI - Data Link Connection Identifier Logical Port - This term is used to model the frame relay "interface" on a device. NNI - Network to Network Interface Permanent Virtual Connection (PVC) - A virtual connection that has its end-points and bearer capabilities defined at subscription time. Time slot (E1) - An octet within the 256-bit information field in each E1 frame is defined as a time slot. Time slots are position sensitive within the 256-bit information field. Fractional E1 service is provided in contiguous or non-contiguous time slot increments. Time slot (DS0) - An octet within the 192-bit information field in each DS1 frame is defined as a time slot. Time slots are position sensitive within the 192-bit information field. Fractional DS1 service is provided in contiguous or non-contiguous time slot increments. UNI - User to Network Interface N391 - Full status (status of all PVCs) polling counter N392 - Error threshold N393 - Monitored events count T391 - Link integrity verification polling timer T392 - Polling verification timer nT3 - Status enquiry timer nN3 - Maximum status enquiry counter Rehbehn & Fowler Standards Track [Page 7] RFC 2954 Frame Relay Service MIB October 2000 2.5. Relation to Other MIBs 2.5.1. System Group Use the System Group of the SNMPv2-MIB [27] to describe the Frame Relay Service (FRS) agent. The FRS agent may be monitoring many frame relay devices in one network. The System Group does not describe frame relay devices monitored by the FRS agent. sysDescr: ASCII string describing the FRS agent. Can be up to 255 characters long. This field is generally used to indicate the network providers identification and type of service offered. sysObjectID: Unique OBJECT IDENTIFIER (OID) for the FRS agent. sysUpTime: Clock in the FRS agent; TimeTicks in 1/100s of a second. Elapsed type since the FRS agent came on line. sysContact: Contact for the FRS agent. ASCII string of up to 255 characters. sysName: Domain name of the FRS agent, for example, acme.com sysLocation: Location of the FRS agent. ASCII string of up to 255 characters. sysServices: Services of the managed device. The value "2", which implies that the frame relay network is providing a subnetwork level service, is recommended. 2.5.2. Interfaces Table (ifTable, ifXtable) This specifies how the Interfaces Group defined in the IF MIB [26] shall be used for the management of frame relay based interfaces, and in conjunction with the Frame Relay Service MIB module. This memo assumes the interpretation of the evolution of the Interfaces group to be in accordance with: "The interfaces table (ifTable) contains information on the managed resource's interfaces. Each sub-layer below the internetwork layer of a network interface is considered an interface." Thus, the ifTable allows the following frame relay-based interfaces to be represented as table entries: Rehbehn & Fowler Standards Track [Page 8] RFC 2954 Frame Relay Service MIB October 2000 - Frame relay interfaces in equipment (e.g., switches, routers or networks) supporting frame relay. This level is concerned with generic frame counts and not with individual virtual connections. In accordance with the guidelines of ifTable, frame counts per virtual connection are not covered by ifTable, and are considered interface specific and covered in the Frame Relay Service MIB module. In order to interrelate the ifEntries properly, the Interfaces Stack Group shall be supported. Some specific interpretations of ifTable for frame relay follow. Object Use for the generic Frame Relay layer ====== ============================================= ifIndex Each frame relay port is represented by an ifEntry. ifDescr Description of the frame relay interface. ASCII string describing the UNI/NNI logical port. Can be up to 255 characters long. ifType The value allocated for Frame Relay Service is equal to 44. ifMtu Set to maximum frame size in octets for this frame relay logical port. ifSpeed Peak bandwidth in bits per second available for use. This could be the speed of the logical port and not the access rate. Actual user information transfer rate (i.e., access rate) of the UNI or NNI logical port in bits per second (this is not the clocking speed). For example, it is 1,536,000 bits per second for a DS1-based UNI/NNI logical port and 1,984,000 bits per second for an E1-based UNI/NNI logical port. ifPhysAddress The primary address for this logical port assigned by the frame relay interface provider. An octet string of zero length if no address is used for this logical port. ifAdminStatus The desired administrative status of the frame relay logical port. Rehbehn & Fowler Standards Track [Page 9] RFC 2954 Frame Relay Service MIB October 2000 ifOperStatus The current operational status of the Frame Relay UNI or NNI logical port. ifLastChange The value of sysUptime at the last re-initialization of the logical port. The value of sysUpTime at the time the logical port entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value. ifInOctets The number of received octets. This counter only counts octets from the beginning of the frame relay header field to the end of user data. ifInUcastPkts The number of received unerrored, unicast frames. ifInDiscards The number of received frames discarded. Specifically, frames discarded due to ingress buffer congestion and traffic policing. ifInErrors The number of received frames that are discarded because of an error. Specifically, frames that are too long or too short, frames that are not a multiple of 8 bits in length, frames with an invalid or unrecognized DLCI, frames with an abort sequence, frames with improper flag delimitation, and frame that fail FCS. ifInUnknownProtos The number of packets discarded because of an unknown or unsupported protocol. For Frame Relay Service interfaces, this counter will always be zero. ifOutOctets The number of transmitted octets. This counter only counts octets from the beginning of the frame relay header field to the end of user data. ifOutUcastpkts The number of unerrored, unicast frames sent. ifOutDiscards The number of frames discarded in the egress direction. Possible reasons are as follows: policing, congestion. Rehbehn & Fowler Standards Track [Page 10] RFC 2954 Frame Relay Service MIB October 2000 ifOutErrors The number of frames discarded in the egress direction because of an error. Specifically, frames that are aborted due to a transmitter underrun. ifName This variable is not applicable for Frame Relay Service interfaces, therefore, this variable contains a zero-length string. ifInMulticastPkts The number of received unerrored, multicast frames. ifInBroadcastPkts This variable is not applicable for Frame Relay Service interfaces, therefore, this counter is always zero. ifOutMulticastPkts The number of sent unerrored, multicast frames. ifOutBroadcastPkts This variable is not applicable for Frame Relay Service interfaces, therefore, this counter is always zero. ifHCInOctets Only used for DS3-based (and greater) Frame Relay logical ports. The number of received octets. This counter only counts octets from the beginning of the frame relay header field to the end of user data. ifHCOutOctets Only used for DS3-based (and greater) Frame Relay logical ports. The number of transmitted octets. This counter only counts octets from the beginning of the frame relay header field to the end of user data. ifLinkUpDownTrapEnable Set to true(1). It is recommended that the underlying physical layer notifications be disabled since both are not required. Notifications are enabled at the frame relay service layer specifically because PVC notifications are not to be sent if the frame relay interface fails. Without a linkUp/linkDown notification, the management station would receive no notification of the failure. Rehbehn & Fowler Standards Track [Page 11] RFC 2954 Frame Relay Service MIB October 2000 ifHighSpeed Set to the user data rate of the frame relay logical port in millions of bits per second. If the user data rate is less than 1 Mbps, then this value is zero. ifPromiscuousMode Set to false(2). ifConnectorPresent Set to false(2). Frame relay network service interfaces support the Interface Stack Group. Frame relay network service interfaces do not support any other groups or objects in the Interfaces group of the IF MIB. 2.5.3. Stack Table for DS1/E1 Environment This section describes by example how to use ifStackTable to represent the relationship of frame relay service to ds0 and ds0Bundles with ds1 interfaces [20]. Example: A frame relay service is being carried on 4 ds0s of a ds1. +---------------------+ | Frame Relay Service | +---------------------+ | +---------------------+ | ds0Bundle | +---------------------+ | | | | +---+ +---+ +---+ +---+ |ds0| |ds0| |ds0| |ds0| +---+ +---+ +---+ +---+ | | | | +---------------------+ | ds1 | +---------------------+ The assignment of the index values could for example be: ifIndex Description 1 FrameRelayService (type 44) 2 ds0Bundle (type 82) 3 ds0 #1 (type 81) 4 ds0 #2 (type 81) 5 ds0 #3 (type 81) 6 ds0 #4 (type 81) 7 ds1 (type 18) Rehbehn & Fowler Standards Track [Page 12] RFC 2954 Frame Relay Service MIB October 2000 The ifStackTable is then used to show the relationships between the various interfaces. ifStackTable Entries HigherLayer LowerLayer 0 1 1 2 2 3 2 4 2 5 2 6 3 7 4 7 5 7 6 7 7 0 In the case where the frame relay service is using a single ds0, then the ds0Bundle is not required. +---------------------+ | Frame Relay Service | +---------------------+ | +---+ |ds0| +---+ | +---------------------+ | ds1 | +---------------------+ The assignment of the index values could for example be: ifIndex Description 1 FrameRelayService (type 44) 2 ds0 (type 81) 3 ds1 (type 18) The ifStackTable is then used to show the relationships between the various interfaces. Rehbehn & Fowler Standards Track [Page 13] RFC 2954 Frame Relay Service MIB October 2000 ifStackTable Entries HigherLayer LowerLayer 0 1 1 2 2 3 3 0 2.5.4. Stack Table for V.35 Environments This section describes by example how to use ifStackTable to represent the relationship of frame relay service with V.35 interfaces. +---------------------+ | Frame Relay Service | +---------------------+ | +---------------------+ | v35 | +---------------------+ An example of index values in this case could be: ifIndex Description 1 FrameRelayService (type 44) 2 v35 (type 33) Note type 33 (RS232-like MIB) is used instead of type 45 (V.35). V35 does not pertain to this environment. The ifStackTable is then used to show the relationships between the various interfaces. ifStackTable Entries HigherLayer LowerLayer 0 1 1 2 2 0 2.5.5. The Frame Relay/ATM PVC Service Interworking MIB Connections between two frame relay endpoints are represented with an entry in the frPVCConnectTable of this MIB. Both endpoints are represented with rows in the frPVCEndptTable. The frPVCEndptConnectIdentifier object of each endpoint points to the frPVCConnectTable cross-connect table row for the connection. Rehbehn & Fowler Standards Track [Page 14] RFC 2954 Frame Relay Service MIB October 2000 In contrast, a connection that spans frame relay and ATM endpoints is represented with an entry in the frAtmIwfConnectionTable of the FR/ATM PVC Service Interworking MIB defined in [28]. In the case of an inter-worked connection, the frPVCEndptConnectIdentifier object is set to zero. Instead, the frPVCEndptAtmIwfConnIndex object is set to the index of the FR/ATM IWF cross-connect table row. The frame relay PVC cross-connect table (frPVCConnectTable) does not contain an entry for the FR/ATM inter-worked connection. 2.6. Textual Convention Change Version 1 of the Frame Relay Service MIB contains MIB objects defined with the DisplayString textual convention. In version 2 of this MIB, the syntax for these objects has been updated to use the (now preferred) SnmpAdminString textual convention. The new TC provides support for a greater variety of international character sets. The working group realizes that this change is not strictly supported by SMIv2. In our judgment, the alternative of deprecating the old objects and defining new objects would have a more adverse impact on backward compatibility and interoperability, given the particular semantics of these objects. 3. Object Definitions FRNETSERV-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, transmission, Counter32, Integer32 FROM SNMPv2-SMI TimeStamp, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InterfaceIndex, ifIndex FROM IF-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; frnetservMIB MODULE-IDENTITY LAST-UPDATED "200009280000Z" -- September 28, 2000 ORGANIZATION "IETF Frame Relay Service MIB Working Group" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/frnetmib-charter WG-email: frnetmib@sunroof.eng.sun.com Rehbehn & Fowler Standards Track [Page 15] RFC 2954 Frame Relay Service MIB October 2000 Subscribe: frnetmib-request@sunroof.eng.sun.com Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib Chair: Andy Malis Vivace Networks, Inc. Email: Andy.Malis@vivacenetworks.com WG editor: Kenneth Rehbehn Megisto Systems, Inc. Email: krehbehn@megisto.com Co-author: David Fowler Syndesis Limited, EMail: fowler@syndesis.com" DESCRIPTION "The MIB module to describe generic objects for Frame Relay Network Service." -- -- Revision History -- REVISION "200009280000Z" DESCRIPTION "Published as RFC 2954. The major new features of this revision include: o Support for read-write capability to provision switch components providing service, o Support for cross-connection via a frame relay to ATM service interworking function, o Support for frame relay fragmentation, o Additional frame counters to track frame loss. Refer to Appendix A for a comprehensive list of changes since RFC 1604." REVISION "199311161200Z" DESCRIPTION "Published as RFC 1604." ::= { transmission 44 } Rehbehn & Fowler Standards Track [Page 16] RFC 2954 Frame Relay Service MIB October 2000 frnetservObjects OBJECT IDENTIFIER ::= { frnetservMIB 1 } frnetservTraps OBJECT IDENTIFIER ::= { frnetservMIB 2 } frnetservTrapsPrefix OBJECT IDENTIFIER ::= { frnetservTraps 0 } -- -- The Frame Relay Service Logical Port -- frLportTable OBJECT-TYPE SYNTAX SEQUENCE OF FrLportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Logical Port Information table is an interface-specific addendum to the generic ifTable of the Interface MIB." ::= { frnetservObjects 1 } frLportEntry OBJECT-TYPE SYNTAX FrLportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay Logical Port Information table." INDEX { ifIndex } ::= { frLportTable 1 } FrLportEntry ::= SEQUENCE { frLportNumPlan INTEGER, frLportContact SnmpAdminString, frLportLocation SnmpAdminString, frLportType INTEGER, frLportAddrDLCILen INTEGER, frLportVCSigProtocol INTEGER, frLportVCSigPointer OBJECT IDENTIFIER, frLportDLCIIndexValue Integer32, frLportTypeAdmin INTEGER, frLportVCSigProtocolAdmin INTEGER, frLportFragControl INTEGER, frLportFragSize Integer32 } Rehbehn & Fowler Standards Track [Page 17] RFC 2954 Frame Relay Service MIB October 2000 frLportNumPlan OBJECT-TYPE SYNTAX INTEGER { other(1), e164(2), x121(3), none(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the network address numbering plan for this UNI/NNI logical port. The network address is the object ifPhysAddress. The value none(4) implies that there is no ifPhysAddress. The FRS agent will return an octet string of zero length for ifPhysAddress. The value other(1) means that an address has been assigned to this interface, but the numbering plan is not enumerated here." REFERENCE "E.164 [29] X.121 [30]" ::= { frLportEntry 1 } frLportContact OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the network contact for this UNI/NNI logical port." ::= { frLportEntry 2 } frLportLocation OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the frame relay network location for this UNI/NNI logical port." ::= { frLportEntry 3 } frLportType OBJECT-TYPE SYNTAX INTEGER { uni(1), nni(2) } MAX-ACCESS read-only Rehbehn & Fowler Standards Track [Page 18] RFC 2954 Frame Relay Service MIB October 2000 STATUS current DESCRIPTION "The value of this object identifies the type of network interface for this logical port." ::= { frLportEntry 4 } frLportAddrDLCILen OBJECT-TYPE SYNTAX INTEGER { twoOctets10Bits(1), threeOctets10Bits(2), threeOctets16Bits(3), fourOctets17Bits(4), fourOctets23Bits(5) } UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the Q.922 Address field length and DLCI length for this UNI/NNI logical port." REFERENCE "Q.922 [25]" ::= { frLportEntry 5 } frLportVCSigProtocol OBJECT-TYPE SYNTAX INTEGER { none(1), lmi(2), ansiT1617D(3), ansiT1617B(4), ccittQ933A(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the Local In-Channel Signaling Protocol that is used for this frame relay UNI/NNI logical port. none(1): Interface does not use a PVC signaling protocol lmi(2): Interface operates the Stratacom/ Nortel/DEC Local Management Interface Specification protocol ansiT1617D(3): Interface operates the ANSI T1.617 Annex D PVC status protocol Rehbehn & Fowler Standards Track [Page 19] RFC 2954 Frame Relay Service MIB October 2000 ansiT1617B(4): Interface operates the ANSI T1.617 Annex B procedures ccittQ933A(5): Interface operates the ITU Q.933 Annex A PVC status protocol" REFERENCE "LMI [24] T1.617 Annex D [17], Q.933 Annex A [22]" ::= { frLportEntry 6 } frLportVCSigPointer OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of this object is used as a pointer to the table that contains the Local In-Channel Signaling Protocol parameters and errors for this UNI/NNI logical port. This object has been deprecated to reflect the fact that the local in-channel signaling parameters are accessed from a single table (frMgtVCSigTable) that includes parameters for all possible signaling protocols. Early design anticipated multiple tables, one for each signaling protocol." ::= { frLportEntry 7 } frLportDLCIIndexValue OBJECT-TYPE SYNTAX Integer32 (16..4194303) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a hint to be used for frPVCEndptDLCIIndex when creating entries in the frPVCEndptTable. The SYNTAX of this object matches the SYNTAX of the frPVCEndptDLCIIndex - an object that is restricted to legal Q.922 DLCI values for the size of the address field. The value 0 indicates that no unassigned entries are available. To obtain the frPVCEndptDLCIIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of Rehbehn & Fowler Standards Track [Page 20] RFC 2954 Frame Relay Service MIB October 2000 this object. After each retrieval, the agent must modify the value to the next unassigned index to prevent assignment of the same value to multiple management systems. A management system should repeat the read to obtain a new value should an attempt to create the new row using the previously returned hint fail." REFERENCE "Q.922 [25]" ::= { frLportEntry 8 } frLportTypeAdmin OBJECT-TYPE SYNTAX INTEGER { uni(1), nni(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object desired identifies the type of network interface for this logical port." ::= { frLportEntry 9 } frLportVCSigProtocolAdmin OBJECT-TYPE SYNTAX INTEGER { none(1), lmi(2), ansiT1617D(3), ansiT1617B(4), ccittQ933A(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired Local In-Channel Signaling Protocol that is used for this frame relay UNI/NNI logical port. This value must be made the active protocol as soon as possible on the device. Refer to frLportVCSigProtocol for a description of each signaling protocol choices." REFERENCE "LMI [24] T1.617 Annex D [17], Q.933 Annex A [22]" ::= { frLportEntry 10 } frLportFragControl OBJECT-TYPE Rehbehn & Fowler Standards Track [Page 21] RFC 2954 Frame Relay Service MIB October 2000 SYNTAX INTEGER { on(1), off(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the transmission and reception of fragmentation frames for this UNI or NNI interface. on(1) Frames are fragmented using the interface fragmentation format Note: The customer side of the interface must also be configured to fragment frames. off(2) Frames are not fragmented using the interface fragmentation format." REFERENCE "FRF.12 [21]" DEFVAL { off } ::= { frLportEntry 11 } frLportFragSize OBJECT-TYPE SYNTAX Integer32 (0..4096) UNITS "Octets" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the size in octets of the maximum size of each fragment to be sent when fragmenting. This object is only used by the fragmentation transmitter, and the two sides of the interface may differ. The fragment size includes the octets for the frame relay header, the UI octet, the NLPID, the fragmentation header, and the fragment payload. If frLportFragControl is set to off, this value should be zero." REFERENCE "FRF.12 [21]" DEFVAL { 0 } ::= { frLportEntry 12 } -- -- Frame Relay Management VC Signaling -- frMgtVCSigTable OBJECT-TYPE SYNTAX SEQUENCE OF FrMgtVCSigEntry Rehbehn & Fowler Standards Track [Page 22] RFC 2954 Frame Relay Service MIB October 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Management VC Signaling Parameters and Errors table." ::= { frnetservObjects 2 } frMgtVCSigEntry OBJECT-TYPE SYNTAX FrMgtVCSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay Management VC Signaling Parameters Errors table." INDEX { ifIndex } ::= { frMgtVCSigTable 1 } FrMgtVCSigEntry ::= SEQUENCE { frMgtVCSigProced INTEGER, frMgtVCSigUserN391 INTEGER, frMgtVCSigUserN392 INTEGER, frMgtVCSigUserN393 INTEGER, frMgtVCSigUserT391 INTEGER, frMgtVCSigNetN392 INTEGER, frMgtVCSigNetN393 INTEGER, frMgtVCSigNetT392 INTEGER, frMgtVCSigNetnN4 INTEGER, frMgtVCSigNetnT3 INTEGER, frMgtVCSigUserLinkRelErrors Counter32, frMgtVCSigUserProtErrors Counter32, frMgtVCSigUserChanInactive Counter32, frMgtVCSigNetLinkRelErrors Counter32, frMgtVCSigNetProtErrors Counter32, frMgtVCSigNetChanInactive Counter32, frMgtVCSigProcedAdmin INTEGER, frMgtVCSigUserN391Admin INTEGER, frMgtVCSigUserN392Admin INTEGER, frMgtVCSigUserN393Admin INTEGER, frMgtVCSigUserT391Admin INTEGER, frMgtVCSigNetN392Admin INTEGER, frMgtVCSigNetN393Admin INTEGER, frMgtVCSigNetT392Admin INTEGER, frMgtVCSigNetnT3Admin INTEGER } frMgtVCSigProced OBJECT-TYPE SYNTAX INTEGER { Rehbehn & Fowler Standards Track [Page 23] RFC 2954 Frame Relay Service MIB October 2000 u2nnet(1), bidirect(2), u2nuser(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the local in-channel signaling procedural role that is used for this UNI/NNI logical port. Bidirectional procedures implies that both user-side and network-side procedural roles are used. u2nnet(1) Logical port operates user to network procedure in the role of the network side bidirect(2) Logical port operates the bidirectional procedure (both user and network side roles) u2nuser(3) Logical port operates user to network procedure in the role of the user side" REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" ::= { frMgtVCSigEntry 1 } frMgtVCSigUserN391 OBJECT-TYPE SYNTAX INTEGER (1..255) UNITS "Polls" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the User-side N391 full status polling cycle value for this UNI/NNI logical port. If the logical port is not performing user-side (bidirectional) procedures, then this object is not instantiated and an attempt to read will result in the noSuchInstance exception response." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" DEFVAL { 6 } ::= { frMgtVCSigEntry 2 } frMgtVCSigUserN392 OBJECT-TYPE SYNTAX INTEGER (1..10) Rehbehn & Fowler Standards Track [Page 24] RFC 2954 Frame Relay Service MIB October 2000 UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the User-side N392 error threshold value for this UNI/NNI logical port. If the logical port is not performing user-side (bidirectional) procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" DEFVAL { 3 } ::= { frMgtVCSigEntry 3 } frMgtVCSigUserN393 OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the User-side N393 monitored events count value for this UNI/NNI logical port. If the logical port is not performing user-side (bidirectional) procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" DEFVAL { 4 } ::= { frMgtVCSigEntry 4 } frMgtVCSigUserT391 OBJECT-TYPE SYNTAX INTEGER (5..30) UNITS "Seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the User-side T391 link integrity verification polling timer value for this UNI/NNI logical port. If the logical port is not performing user-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" DEFVAL { 10 } ::= { frMgtVCSigEntry 5 } frMgtVCSigNetN392 OBJECT-TYPE SYNTAX INTEGER (1..10) Rehbehn & Fowler Standards Track [Page 25] RFC 2954 Frame Relay Service MIB October 2000 UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the Network- side N392 error threshold value (nN2 for LMI) for this UNI/NNI logical port. If the logical port is not performing network-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17], LMI [24]" DEFVAL { 3 } ::= { frMgtVCSigEntry 6 } frMgtVCSigNetN393 OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the Network- side N393 monitored events count value (nN3 for LMI) for this UNI/NNI logical port. If the logical port is not performing network-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17], LMI [24]" DEFVAL { 4 } ::= { frMgtVCSigEntry 7 } frMgtVCSigNetT392 OBJECT-TYPE SYNTAX INTEGER (5..30) UNITS "Seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the Network- side T392 polling verification timer value (nT2 for LMI) for this UNI/NNI logical port. If the logical port is not performing network-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17], LMI [24]" DEFVAL { 15 } ::= { frMgtVCSigEntry 8 } Rehbehn & Fowler Standards Track [Page 26] RFC 2954 Frame Relay Service MIB October 2000 frMgtVCSigNetnN4 OBJECT-TYPE SYNTAX INTEGER (5..5) UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the Network- side nN4 maximum status enquires received value for this UNI/NNI logical port. If the logical port is not performing network-side procedures or is not performing LMI procedures, then this object is not instantiated. This object applies only to LMI and always has a value of 5." REFERENCE "LMI [24]" ::= { frMgtVCSigEntry 9 } frMgtVCSigNetnT3 OBJECT-TYPE SYNTAX INTEGER (5 | 10 | 15 | 20 | 25 | 30) UNITS "Seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the Network- side nT3 timer (for nN4 status enquires received) value for this UNI/NNI logical port. If the logical port is not performing network-side procedures or is not performing LMI procedures, then this object is not instantiated. This object applies only to LMI." REFERENCE "LMI [24]" DEFVAL { 20 } ::= { frMgtVCSigEntry 10 } frMgtVCSigUserLinkRelErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Errors" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user-side local in-channel signaling link reliability errors (i.e., non- receipt of Status/Status Enquiry messages or invalid sequence numbers in a Link Integrity Verification Information Element) for this UNI/NNI logical port. If the logical port is not Rehbehn & Fowler Standards Track [Page 27] RFC 2954 Frame Relay Service MIB October 2000 performing user-side procedures, then this object is not instantiated." ::= { frMgtVCSigEntry 11 } frMgtVCSigUserProtErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Errors" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user-side local in-channel signaling protocol errors (i.e., protocol discriminator, unnumbered information, message type, call reference, and mandatory information element errors) for this UNI/NNI logical port. If the logical port is not performing user-side procedures, then this object is not instantiated." ::= { frMgtVCSigEntry 12 } frMgtVCSigUserChanInactive OBJECT-TYPE SYNTAX Counter32 UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the user-side channel was declared inactive (i.e., N392 errors in N393 events) for this UNI/NNI logical port. If the logical port is not performing user-side procedures, then this object is not instantiated." ::= { frMgtVCSigEntry 13 } frMgtVCSigNetLinkRelErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Errors" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of network-side local in-channel signaling link reliability errors (i.e., non- receipt of Status/Status Enquiry messages or invalid sequence numbers in a Link Integrity Verification Information Element) for this UNI/NNI logical port." ::= { frMgtVCSigEntry 14 } frMgtVCSigNetProtErrors OBJECT-TYPE SYNTAX Counter32 Rehbehn & Fowler Standards Track [Page 28] RFC 2954 Frame Relay Service MIB October 2000 UNITS "Errors" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of network-side local in-channel signaling protocol errors (i.e., protocol discriminator, message type, call reference, and mandatory information element errors) for this UNI/NNI logical port." ::= { frMgtVCSigEntry 15 } frMgtVCSigNetChanInactive OBJECT-TYPE SYNTAX Counter32 UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the network-side channel was declared inactive (i.e., N392 errors in N393 events) for this UNI/NNI logical port." ::= { frMgtVCSigEntry 16 } frMgtVCSigProcedAdmin OBJECT-TYPE SYNTAX INTEGER { u2nnet(1), bidirect(2), u2nuser(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the local in-channel signaling procedural role that is used for this UNI/NNI logical port. Bidirectional procedures implies that both user-side and network-side procedural roles are used. u2nnet(1) Logical port operates user to network procedure in the role of the network side bidirect(2) Logical port operates the bidirectional procedure (both user and network side roles) u2nuser(3) Logical port operates user to network procedure in the role of the user side" Rehbehn & Fowler Standards Track [Page 29] RFC 2954 Frame Relay Service MIB October 2000 REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" DEFVAL { u2nnet } ::= { frMgtVCSigEntry 17 } frMgtVCSigUserN391Admin OBJECT-TYPE SYNTAX INTEGER (1..255) UNITS "Polls" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired User-side N391 full status polling cycle value for this UNI/NNI logical port. If the logical port is not performing user-side (bidirectional) procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" ::= { frMgtVCSigEntry 18 } frMgtVCSigUserN392Admin OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "Events" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired User-side N392 error threshold value for this UNI/NNI logical port. If the logical port is not performing user-side (bidirectional) procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" ::= { frMgtVCSigEntry 19 } frMgtVCSigUserN393Admin OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "Events" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired User-side N393 monitored events count value for this UNI/NNI logical port. If the logical port is not performing user-side (bidirectional) procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" Rehbehn & Fowler Standards Track [Page 30] RFC 2954 Frame Relay Service MIB October 2000 ::= { frMgtVCSigEntry 20 } frMgtVCSigUserT391Admin OBJECT-TYPE SYNTAX INTEGER (5..30) UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired User-side T391 link integrity verification polling timer value for this UNI/NNI logical port. If the logical port is not performing user-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17]" ::= { frMgtVCSigEntry 21 } frMgtVCSigNetN392Admin OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "Events" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired Network-side N392 error threshold value (nN2 for LMI) for this UNI/NNI logical port. If the logical port is not performing network-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17], LMI [24]" ::= { frMgtVCSigEntry 22 } frMgtVCSigNetN393Admin OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "Events" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired Network-side N393 monitored events count value (nN3 for LMI) for this UNI/NNI logical port. If the logical port is not performing network-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17], LMI [24]" ::= { frMgtVCSigEntry 23 } Rehbehn & Fowler Standards Track [Page 31] RFC 2954 Frame Relay Service MIB October 2000 frMgtVCSigNetT392Admin OBJECT-TYPE SYNTAX INTEGER (5..30) UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired Network-side T392 polling verification timer value (nT2 for LMI) for this UNI/NNI logical port. If the logical port is not performing network-side procedures, then this object is not instantiated." REFERENCE "Q.933 Annex A [22], T1.617 Annex D [17], LMI [24]" ::= { frMgtVCSigEntry 24 } frMgtVCSigNetnT3Admin OBJECT-TYPE SYNTAX INTEGER (5 | 10 | 15 | 20 | 25 | 30) UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the desired Network-side nT3 timer (for nN4 status enquires received) value for this UNI/NNI logical port. If the logical port is not performing network-side procedures or is not performing LMI procedures, then this object is not instantiated. This object applies only to LMI." REFERENCE "LMI [24]" ::= { frMgtVCSigEntry 25 } -- -- Frame Relay PVC End-points -- frPVCEndptTable OBJECT-TYPE SYNTAX SEQUENCE OF FrPVCEndptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay PVC End-Point table. This table is used to model a PVC end-point. This table contains the traffic parameters and statistics for a PVC end-point. This table is used to identify the traffic parameters for a bi-directional PVC segment end- Rehbehn & Fowler Standards Track [Page 32] RFC 2954 Frame Relay Service MIB October 2000 point, and it also provides statistics for a PVC segment end-point. A PVC segment end-point is identified by a UNI/NNI logical port index value and DLCI index value. If the frame relay service provider allows the frame relay CNM subscriber to create, modify or delete PVCs using SNMP, then this table is used to identify and reserve the requested traffic parameters of each PVC segment end-point. The Connection table is used to 'connect' the end- points together. Not all implementations will support the capability of creating/modifying/deleting PVCs using SNMP as a feature of frame relay CNM service. Uni-directional PVCs are modeled with zero valued traffic parameters in one of the directions (In or Out direction) in this table. To create a PVC, the following procedures shall be followed: 1) Create the entries for the PVC segment endpoints in the frPVCEndptTable by specifying the traffic parameters for the bi-directional PVC segment endpoints. As shown in figure 2, a point-to-point PVC has two endpoints, thus two entries in this table. Uni-directional PVCs are modeled with zero valued traffic parameters in one direction; all the `In' direction parameters for one frame relay PVC End-point or all the `Out' direction parameters for the other frame relay PVC Endpoint. In _____________________________ Out >>>>>>| |>>>>>>>> ______| Frame Relay Network |________ Out | | In <<<<<<|_____________________________|<<<<<<<< Frame Relay Frame Relay PVC PVC Endpoint Endpoint Figure 2, PVC Terminology Rehbehn & Fowler Standards Track [Page 33] RFC 2954 Frame Relay Service MIB October 2000 2) Go to the Frame Relay Connection Group." ::= { frnetservObjects 3 } frPVCEndptEntry OBJECT-TYPE SYNTAX FrPVCEndptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay PVC Endpoint table." INDEX { ifIndex, frPVCEndptDLCIIndex } ::= { frPVCEndptTable 1 } FrPVCEndptEntry ::= SEQUENCE { frPVCEndptDLCIIndex Integer32, frPVCEndptInMaxFrameSize Integer32, frPVCEndptInBc Integer32, frPVCEndptInBe Integer32, frPVCEndptInCIR Integer32, frPVCEndptOutMaxFrameSize Integer32, frPVCEndptOutBc Integer32, frPVCEndptOutBe Integer32, frPVCEndptOutCIR Integer32, frPVCEndptConnectIdentifier Integer32, frPVCEndptRowStatus RowStatus, frPVCEndptRcvdSigStatus INTEGER, frPVCEndptInFrames Counter32, frPVCEndptOutFrames Counter32, frPVCEndptInDEFrames Counter32, frPVCEndptInExcessFrames Counter32, frPVCEndptOutExcessFrames Counter32, frPVCEndptInDiscards Counter32, frPVCEndptInOctets Counter32, frPVCEndptOutOctets Counter32, frPVCEndptInDiscardsDESet Counter32, frPVCEndptInFramesFECNSet Counter32, frPVCEndptOutFramesFECNSet Counter32, frPVCEndptInFramesBECNSet Counter32, frPVCEndptOutFramesBECNSet Counter32, frPVCEndptInCongDiscards Counter32, frPVCEndptInDECongDiscards Counter32, frPVCEndptOutCongDiscards Counter32, frPVCEndptOutDECongDiscards Counter32, frPVCEndptOutDEFrames Counter32, frPVCEndptAtmIwfConnIndex Integer32 } Rehbehn & Fowler Standards Track [Page 34] RFC 2954 Frame Relay Service MIB October 2000 frPVCEndptDLCIIndex OBJECT-TYPE SYNTAX Integer32 (16..4194303) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the DLCI value for this PVC end-point. The values are restricted to the legal range for the size of address field supported by the logical port (frLportAddrDLCILen)." REFERENCE "Q.922 [25]" ::= { frPVCEndptEntry 1 } frPVCEndptInMaxFrameSize OBJECT-TYPE SYNTAX Integer32 (1..4096) UNITS "Octets" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is the size in octets of the largest frame relay information field for this PVC end-point in the ingress direction (into the frame relay network). The value of frPVCEndptInMaxFrameSize must be less than or equal to the corresponding ifMtu for this frame relay UNI/NNI logical port." REFERENCE "FRF.1 [31] Q.922 [25] Q.933 [22]" DEFVAL { 1600 } ::= { frPVCEndptEntry 2 } frPVCEndptInBc OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is equal to the committed burst size (Bc) parameter (measured in bits) for this PVC end-point in the ingress direction (into the frame relay network). Note that the max value of this range is lower than the max value allowed by Q.933 (16383 * 10**6). Rehbehn & Fowler Standards Track [Page 35] RFC 2954 Frame Relay Service MIB October 2000 Note that the value is encoded in bits whilst the Q.933 Link layer core parameters information element encodes this information using octet units." REFERENCE "Q.933 [22]" ::= { frPVCEndptEntry 3 } frPVCEndptInBe OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is equal to the excess burst size (Be) parameter (measured in bits) for this PVC end-point in the ingress direction (into the frame relay network). Note that the max value of this range is lower than the max value allowed by Q.933 (16383 * 10**6). Note that the value is encoded in bits whilst the Q.933 Link layer core parameters information element encodes this information using octet units." REFERENCE "Q.933 [22]" ::= { frPVCEndptEntry 4 } frPVCEndptInCIR OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bits per Second" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is equal to the committed information rate (CIR) parameter (measured in bits per second) for this PVC end- point in the ingress direction (into the frame relay network). Note that the max value of this range is lower than the max value allowed by Q.933 (2047 * 10**6)." REFERENCE "Q.933 [22]" ::= { frPVCEndptEntry 5 } frPVCEndptOutMaxFrameSize OBJECT-TYPE Rehbehn & Fowler Standards Track [Page 36] RFC 2954 Frame Relay Service MIB October 2000 SYNTAX Integer32 (1..4096) UNITS "Octets" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is the size in octets of the largest frame relay information field for this PVC end-point in the egress direction (out of the frame relay network). The value of frPVCEndptOutMaxFrameSize must be less than or equal to the corresponding ifMtu for this frame relay UNI/NNI logical port." REFERENCE "FRF.1 [31] Q.922 [25] Q.933 [22]" DEFVAL { 1600 } ::= { frPVCEndptEntry 6 } frPVCEndptOutBc OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is equal to the committed burst size (Bc) parameter (measured in bits) for this PVC end-point in the egress direction (out of the frame relay network). Note that the max value of this range is lower than the max value allowed by Q.933 (16383 * 10**6). Note that the value is encoded in bits whilst the Q.933 Link layer core parameters information element encodes this information using octet units." REFERENCE "Q.933 [22]" ::= { frPVCEndptEntry 7 } frPVCEndptOutBe OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is equal to the excess burst size (Be) parameter (measured in bits) for Rehbehn & Fowler Standards Track [Page 37] RFC 2954 Frame Relay Service MIB October 2000 this PVC end-point in the egress direction (out of the frame relay network). Note that the max value of this range is lower than the max value allowed by Q.933 (16383 * 10**6). Note that the value is encoded in bits whilst the Q.933 Link layer core parameters information element encodes this information using octet units." REFERENCE "Q.933 [22]" ::= { frPVCEndptEntry 8 } frPVCEndptOutCIR OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bits per Second" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is equal to the committed information rate (CIR) parameter (measured in bits per second) for this PVC end- point in the egress direction (out of the frame relay network). Note that the max value of this range is lower than the max value allowed by Q.933 (2047 * 10**6)." REFERENCE "Q.933 [22]" ::= { frPVCEndptEntry 9 } frPVCEndptConnectIdentifier OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to associate PVC end-points as being part of one PVC segment connection. This value of this object is equal to the value of frPVCConnectIndex, which is used as one of the indices into the frPVCConnectTable. A connection that has been cross-connected via the FR/ATM PVC Service IWF cross-connect table will return the value zero when this object is read. In case of these interworked connections, the frPVCEndptAtmIwfConnIndex object must be accessed Rehbehn & Fowler Standards Track [Page 38] RFC 2954 Frame Relay Service MIB October 2000 to select the entry in the FR/ATM PVC Service IWF cross-connect table. The value of this object is provided by the agent, after the associated entries in the frPVCConnectTable or frAtmIwfConnectionTable have been created." ::= { frPVCEndptEntry 10 } frPVCEndptRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create new rows in this table, modify existing rows, and to delete existing rows. To create a new PVC, the entries for the PVC segment end-points in the frPVCEndptTable must first be created. Next, the frPVCConnectTable is used to associate the frame relay PVC segment end-points. In order for the manager to have the necessary error diagnostics, the frPVCEndptRowStatus object must initially be set to `createAndWait(5)'. While the frPVCEndptRowStatus object is in the `createAndWait(5)' state, the manager can set each columnar object and get the necessary error diagnostics. The frPVCEndptRowStatus object may not be set to `active(1)' unless the following columnar objects exist in this row: frPVCEndptInMaxFrameSize, frPVCEndptInBc, frPVCEndptInBe, frPVCEndptInCIR, frPVCEndptOutMaxFrameSize, frPVCEndptOutBc, frPVCEndptOutBe, and frPVCEndptOutCIR." ::= { frPVCEndptEntry 11 } frPVCEndptRcvdSigStatus OBJECT-TYPE SYNTAX INTEGER { deleted(1), active(2), inactive(3), none(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the PVC status received via the local in-channel signaling Rehbehn & Fowler Standards Track [Page 39] RFC 2954 Frame Relay Service MIB October 2000 procedures for this PVC end-point. This object is only pertinent for interfaces that perform the bidirectional procedures. Each value has the following meaning: deleted(1): This PVC is not listed in the full status reports received from the user device. The object retains this value for as long as the PVC is not listed in the full status reports active(2): This PVC is reported as active, or operational, by the user device. inactive(3): This PVC is reported as inactive, or non-operational, by the user device. none(4): This interface is only using the network-side in-channel signaling procedures, so this object does not apply." ::= { frPVCEndptEntry 12 } frPVCEndptInFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received by the network (ingress) for this PVC end-point. This includes any frames discarded by the network due to submitting more than Bc + Be data or due to any network congestion recovery procedures." ::= { frPVCEndptEntry 13 } frPVCEndptOutFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames sent by the network (egress) regardless of whether they are Bc or Be frames for this PVC end-point." ::= { frPVCEndptEntry 14 } Rehbehn & Fowler Standards Track [Page 40] RFC 2954 Frame Relay Service MIB October 2000 frPVCEndptInDEFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received by the network (ingress) with the DE bit set to (1) for this PVC end-point." ::= { frPVCEndptEntry 15 } frPVCEndptInExcessFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received by the network (ingress) for this PVC end-point which were treated as excess traffic. Frames which are sent to the network with DE set to zero are treated as excess when more than Bc bits are submitted to the network during the Committed Information Rate Measurement Interval (Tc). Excess traffic may or may not be discarded at the ingress if more than Bc + Be bits are submitted to the network during Tc. Traffic discarded at the ingress is not recorded in frPVCEndptInExcessFrames. Frames which are sent to the network with DE set to one are also treated as excess traffic." ::= { frPVCEndptEntry 16 } frPVCEndptOutExcessFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames sent by the network (egress) for this PVC end-point which were treated as excess traffic. (The DE bit may be set to one.)" ::= { frPVCEndptEntry 17 } frPVCEndptInDiscards OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current Rehbehn & Fowler Standards Track [Page 41] RFC 2954 Frame Relay Service MIB October 2000 DESCRIPTION "The number of frames received by the network (ingress) that were discarded due to traffic enforcement for this PVC end-point. Congestion discards are not counted in this object." ::= { frPVCEndptEntry 18 } frPVCEndptInOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets received by the network (ingress) for this PVC end-point. This counter should only count octets from the beginning of the frame relay header field to the end of user data. If the network supporting frame relay can not count octets, then this count should be an approximation." ::= { frPVCEndptEntry 19 } frPVCEndptOutOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets sent by the network (egress) for this PVC end-point. This counter should only count octets from the beginning of the frame relay header field to the end of user data. If the network supporting frame relay can not count octets, then this count should be an approximation." ::= { frPVCEndptEntry 20 } frPVCEndptInDiscardsDESet OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received by the network (ingress) that were discarded with the DE bit set due to traffic enforcement for this PVC end-point. Congestion discards are not counted in this object." Rehbehn & Fowler Standards Track [Page 42] RFC 2954 Frame Relay Service MIB October 2000 ::= { frPVCEndptEntry 21 } frPVCEndptInFramesFECNSet OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received by the network (ingress) that have the FECN bit set for this PVC end-point." ::= { frPVCEndptEntry 22 } frPVCEndptOutFramesFECNSet OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames sent by the network (egress) that have the FECN bit set for this PVC end- point." ::= { frPVCEndptEntry 23 } frPVCEndptInFramesBECNSet OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received by the network (ingress) that have the BECN bit set for this PVC end-point." ::= { frPVCEndptEntry 24 } frPVCEndptOutFramesBECNSet OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames sent by the network (egress) that have the BECN bit set for this PVC end- point." ::= { frPVCEndptEntry 25 } frPVCEndptInCongDiscards OBJECT-TYPE SYNTAX Counter32 Rehbehn & Fowler Standards Track [Page 43] RFC 2954 Frame Relay Service MIB October 2000 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received by the network (ingress) that were discarded due to input buffer congestion, rather than traffic enforcement, for this PVC end-point." ::= { frPVCEndptEntry 26 } frPVCEndptInDECongDiscards OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames counted by frPVCEndptInCongDiscards with the DE bit set to (1)." ::= { frPVCEndptEntry 27 } frPVCEndptOutCongDiscards OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames sent by the network (egress) that were discarded due to output buffer congestion for this PVC end-point." ::= { frPVCEndptEntry 28 } frPVCEndptOutDECongDiscards OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames counted by frPVCEndptOutCongDiscards with the DE bit set to (1)." ::= { frPVCEndptEntry 29 } frPVCEndptOutDEFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current Rehbehn & Fowler Standards Track [Page 44] RFC 2954 Frame Relay Service MIB October 2000 DESCRIPTION "The number of frames sent by the network (egress) with the DE bit set to (1) for this PVC end- point." ::= { frPVCEndptEntry 30 } frPVCEndptAtmIwfConnIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the index value of the FR/ATM cross-connect table entry used to link the frame relay PVC with an ATM PVC. Each row of the frPVCEndptTable that is not cross-connected with an ATM PVC must return the value zero when this object is read. The value of this object is initialized by the agent after the associated entries in the frAtmIwfConnectionTable have been created. The value of this object is reset to zero following destruction of the associated entry in the frAtmIwfConnectionTable" ::= { frPVCEndptEntry 31 } -- -- Frame Relay PVC Connections -- frPVCConnectIndexValue OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns a hint to be used for frPVCConnectIndex when creating entries in the frPVCConnectTable. The value 0 indicates that no unassigned entries are available. To obtain the frPVCConnectIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent must Rehbehn & Fowler Standards Track [Page 45] RFC 2954 Frame Relay Service MIB October 2000 modify the value to the next unassigned index to prevent assignment of the same value to multiple management systems. A management system should repeat the read to obtain a new value should an attempt to create the new row using the previously returned hint fail." ::= { frnetservObjects 4 } frPVCConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF FrPVCConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay PVC Connect Table is used to model the bi-directional PVC segment flows including: point-to-point PVCs, point-to- multipoint PVCs, and multipoint-to-multipoint PVCs. This table has read-create access and is used to associate PVC end-points together as belonging to one connection. The frPVCConnectIndex is used to associate all the bi-directional flows. Not all implementations will support the capability of creating/modifying/deleting PVCs using SNMP as a feature of frame relay CNM service. Once the entries in the frPVCEndptTable are created, the following step are used to associate the PVC end-points as belonging to one PVC connection: 1) Obtain a unique frPVCConnectIndex using the frPVCConnectIndexValue object. 2) Connect the PVC segment endpoints together with the applicable frPVCConnectIndex value obtained via frPVCConnectIndexValue. The entries in this table are created by using the frPVCConnectRowStatus object. 3) The agent will provide the value of the corresponding instances of frPVCEndptConnectIdentifier with the frPVCConnectIndex value. 4) Set frPVCConnectAdminStatus to `active(1)' in Rehbehn & Fowler Standards Track [Page 46] RFC 2954 Frame Relay Service MIB October 2000 all rows for this PVC segment to turn the PVC on. For example, the Frame Relay PVC Connection Group models a bi-directional, point-to-point PVC segment as one entry in this table. Frame Relay Frame Relay Network Network Low Port High Port __________________________________ | | _____| >> from low to high PVC flow >> |_____ | << from high to low PVC flow << | |__________________________________| The terms low and high are chosen to represent numerical ordering of a PVC segment's endpoints for representation in this table. That is, the endpoint with the lower value of ifIndex is termed 'low', while the opposite endpoint of the segment is termed 'high'. This terminology is to provide directional information; for example the frPVCConnectL2hOperStatus and frPVCConnectH2lOperStatus as illustrated above. If the Frame Relay Connection table is used to model a unidirectional PVC, then one direction (either from low to high or from high to low) has its Operational Status equal to down. A PVC segment is a portion of a PVC that traverses one Frame Relay Network, and a PVC segment is identified by its two end-points (UNI/NNI logical port index value and DLCI index value) through one Frame Relay Network." ::= { frnetservObjects 5 } frPVCConnectEntry OBJECT-TYPE SYNTAX FrPVCConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay PVC Connect table. This entry is used to model a PVC segment in two directions." INDEX { frPVCConnectIndex, frPVCConnectLowIfIndex, Rehbehn & Fowler Standards Track [Page 47] RFC 2954 Frame Relay Service MIB October 2000 frPVCConnectLowDLCIIndex, frPVCConnectHighIfIndex, frPVCConnectHighDLCIIndex } ::= { frPVCConnectTable 1 } FrPVCConnectEntry ::= SEQUENCE { frPVCConnectIndex Integer32, frPVCConnectLowIfIndex InterfaceIndex, frPVCConnectLowDLCIIndex Integer32, frPVCConnectHighIfIndex InterfaceIndex, frPVCConnectHighDLCIIndex Integer32, frPVCConnectAdminStatus INTEGER, frPVCConnectL2hOperStatus INTEGER, frPVCConnectH2lOperStatus INTEGER, frPVCConnectL2hLastChange TimeStamp, frPVCConnectH2lLastChange TimeStamp, frPVCConnectRowStatus RowStatus, frPVCConnectUserName SnmpAdminString, frPVCConnectProviderName SnmpAdminString } frPVCConnectIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the frPVCConnectIndexValue obtained to uniquely identify this PVC segment connection." ::= { frPVCConnectEntry 1 } frPVCConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to IF-MIB ifIndex value of the UNI/NNI logical port for this PVC segment. The term low implies that this PVC segment end-point has the numerically lower ifIndex value than the connected/associated PVC segment end-point. RFC 1604 permitted a zero value for this object to identify termination at a non-frame relay interface. However, this cross-connect table is limited to frame relay connections. See the frame Rehbehn & Fowler Standards Track [Page 48] RFC 2954 Frame Relay Service MIB October 2000 relay/ATM IWF MIB [28] for the cross-connect table used for those types of connections." ::= { frPVCConnectEntry 2 } frPVCConnectLowDLCIIndex OBJECT-TYPE SYNTAX Integer32 (16..4194303) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the DLCI value for this end-point of the PVC segment." REFERENCE "Q.922 [25]" ::= { frPVCConnectEntry 3 } frPVCConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to IF-MIB ifIndex value for the UNI/NNI logical port for this PVC segment. The term high implies that this PVC segment end-point has the numerically higher ifIndex value than the connected/associated PVC segment end-point." ::= { frPVCConnectEntry 4 } frPVCConnectHighDLCIIndex OBJECT-TYPE SYNTAX Integer32 (16..4194303) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the egress DLCI value for this end-point of the PVC segment." REFERENCE "Q.922 [25]" ::= { frPVCConnectEntry 5 } frPVCConnectAdminStatus OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2), testing(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the desired administrative status of this bi-directional PVC Rehbehn & Fowler Standards Track [Page 49] RFC 2954 Frame Relay Service MIB October 2000 segment. The active(1) state means the PVC segment is currently operational; the inactive(2) state means the PVC segment is currently not operational; the testing(3) state means the PVC segment is currently undergoing a test. This state is set by an administrative entity. This value affects the PVC status indicated across the ingress NNI/UNI of both end-points of the bi- directional PVC segment. When a PVC segment connection is created using this table, this object is initially set to `inactive(2)'. After the frPVCConnectRowStatus object is set to `active(1)' (and the corresponding/associated entries in the frPVCEndptTable have their frPVCEndptRowStatus object set to `active(1)'), the frPVCConnectAdminStatus object may be set to `active(1)' to turn on the PVC segment connection." ::= { frPVCConnectEntry 6 } frPVCConnectL2hOperStatus OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2), testing(3), unknown(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the current operational status of the PVC segment connection in one direction; (i.e., in the low to high direction). This value affects the PVC status indicated across the ingress NNI/UNI (low side) of the PVC segment. The values mean: active(1) - PVC is currently operational inactive(2) - PVC is currently not operational. This may be because of an underlying LMI or DS1 failure. testing(3) - PVC is currently undergoing a test. This may be because of an underlying frLport or DS1 undergoing a test. Rehbehn & Fowler Standards Track [Page 50] RFC 2954 Frame Relay Service MIB October 2000 unknown(4) - the status of the PVC currently can not be determined." ::= { frPVCConnectEntry 7 } frPVCConnectH2lOperStatus OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2), testing(3), unknown(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the current operational status of the PVC segment connection in one direction; (i.e., in the high to low direction).. This value affects the PVC status indicated across the ingress NNI/UNI (high side) of the PVC segment. The values mean: active(1) - PVC is currently operational inactive(2) - PVC is currently not operational. This may be because of an underlying LMI or DS1 failure. testing(3) - PVC is currently undergoing a test. This may be because of an underlying frLport or DS1 undergoing a test. unknown(4) - the status of the PVC currently can not be determined." ::= { frPVCConnectEntry 8 } frPVCConnectL2hLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the Interface MIB's sysUpTime object at the time this PVC segment entered its current operational state in the low to high direction. If the current state was entered prior to the last re-initialization of the FRS agent, then this object contains a zero value." Rehbehn & Fowler Standards Track [Page 51] RFC 2954 Frame Relay Service MIB October 2000 ::= { frPVCConnectEntry 9 } frPVCConnectH2lLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the Interface MIB's sysUpTime object at the time this PVC segment entered its current operational state in the high to low direction. If the current state was entered prior to the last re-initialization of the FRS agent, then this object contains a zero value." ::= { frPVCConnectEntry 10 } frPVCConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry in the frPVCConnectTable. This variable is used to create new connections for the PVC end-points and to change existing connections of the PVC end- points. This object must be initially set to `createAndWait(5)'. In this state, the agent checks the parameters in the associated entries in the frPVCEndptTable to verify that the PVC end- points can be connected (i.e., the In parameters for one PVC end-point are equal to the Out parameters for the other PVC end-point). This object can not be set to `active(1)' unless the following columnar object exists in this row: frPVCConnectAdminStatus. The agent also supplies the associated value of frPVCConnectIndex for the frPVCEndptConnectIdentifier instances. To turn on a PVC segment connection, the frPVCConnectAdminStatus is set to `active(1)'." ::= { frPVCConnectEntry 11 } frPVCConnectUserName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This is a service user assigned textual representation of a PVC." ::= { frPVCConnectEntry 12 } Rehbehn & Fowler Standards Track [Page 52] RFC 2954 Frame Relay Service MIB October 2000 frPVCConnectProviderName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This is a system supplied textual representation of PVC. It is assigned by the service provider." ::= { frPVCConnectEntry 13 } -- -- The Frame Relay Accounting -- frAccountPVCTable OBJECT-TYPE SYNTAX SEQUENCE OF FrAccountPVCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Accounting PVC table. This table is used to perform accounting on a PVC segment end-point basis." ::= { frnetservObjects 6 } frAccountPVCEntry OBJECT-TYPE SYNTAX FrAccountPVCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay Accounting PVC table." INDEX { ifIndex, frAccountPVCDLCIIndex } ::= { frAccountPVCTable 1 } FrAccountPVCEntry ::= SEQUENCE { frAccountPVCDLCIIndex Integer32, frAccountPVCSegmentSize Integer32, frAccountPVCInSegments Counter32, frAccountPVCOutSegments Counter32 } frAccountPVCDLCIIndex OBJECT-TYPE SYNTAX Integer32 (16..4194303) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the DLCI Rehbehn & Fowler Standards Track [Page 53] RFC 2954 Frame Relay Service MIB October 2000 value for this PVC segment end-point." REFERENCE "Q.922 [25]" ::= { frAccountPVCEntry 1 } frAccountPVCSegmentSize OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is equal to the Segment Size for this PVC segment end-point." ::= { frAccountPVCEntry 2 } frAccountPVCInSegments OBJECT-TYPE SYNTAX Counter32 UNITS "Segments" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is equal to the number of segments received by this PVC segment end- point." ::= { frAccountPVCEntry 3 } frAccountPVCOutSegments OBJECT-TYPE SYNTAX Counter32 UNITS "Segments" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is equal to the number of segments sent by this PVC segment end-point." ::= { frAccountPVCEntry 4 } -- -- Accounting on a Frame Relay Logical Port -- frAccountLportTable OBJECT-TYPE SYNTAX SEQUENCE OF FrAccountLportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Accounting Logical Port table. This table is used to perform accounting on a UNI/NNI Logical Port basis." ::= { frnetservObjects 7 } Rehbehn & Fowler Standards Track [Page 54] RFC 2954 Frame Relay Service MIB October 2000 frAccountLportEntry OBJECT-TYPE SYNTAX FrAccountLportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay Accounting Logical Port table." INDEX { ifIndex } ::= { frAccountLportTable 1 } FrAccountLportEntry ::= SEQUENCE { frAccountLportSegmentSize Integer32, frAccountLportInSegments Counter32, frAccountLportOutSegments Counter32 } frAccountLportSegmentSize OBJECT-TYPE SYNTAX Integer32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is equal to the Segment Size for this UNI/NNI logical port." ::= { frAccountLportEntry 1 } frAccountLportInSegments OBJECT-TYPE SYNTAX Counter32 UNITS "Segments" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is equal to the number of segments received by this UNI/NNI logical port." ::= { frAccountLportEntry 2 } frAccountLportOutSegments OBJECT-TYPE SYNTAX Counter32 UNITS "Segments" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is equal to the number Rehbehn & Fowler Standards Track [Page 55] RFC 2954 Frame Relay Service MIB October 2000 of segments sent by this UNI/NNI logical port." ::= { frAccountLportEntry 3 } -- -- Frame Relay Network Service Notifications -- frPVCConnectStatusChange NOTIFICATION-TYPE OBJECTS { frPVCConnectIndex, frPVCConnectLowIfIndex, frPVCConnectLowDLCIIndex, frPVCConnectHighIfIndex, frPVCConnectHighDLCIIndex, frPVCConnectL2hOperStatus, frPVCConnectH2lOperStatus, frPVCEndptRcvdSigStatus } STATUS deprecated DESCRIPTION "Refer to the description of the frPVCConnectStatusNotif notification that has replaced this notification. The notification is deprecated due to the incorrect inclusion of index values and to take advantage of the trap prefix for automatic conversion from SMIv2 to SMIv1 by making the one but last sub-ID a zero (i.e. the so-called trap prefix)." ::= { frnetservTraps 1 } frPVCConnectStatusNotif NOTIFICATION-TYPE OBJECTS { frPVCConnectL2hOperStatus, frPVCConnectH2lOperStatus, frPVCEndptRcvdSigStatus } STATUS current DESCRIPTION "This notification indicates that the indicated PVC has changed state. This notification is not sent if an FR-UNI changes state; a linkDown or linkUp notification should be sent instead. The first instance of frPVCEndptRcvdSigStatus is for the endpoint with LowIfIndex, LowDLCIIndex. The second instance of frPVCEndptRcvdSigStatus is for the endpoint with HighIfIndex, HighDLCIIndex" ::= { frnetservTrapsPrefix 2 } -- Conformance Information Rehbehn & Fowler Standards Track [Page 56] RFC 2954 Frame Relay Service MIB October 2000 frnetservConformance OBJECT IDENTIFIER ::= { frnetservMIB 3 } frnetservGroups OBJECT IDENTIFIER ::= { frnetservConformance 1 } frnetservCompliances OBJECT IDENTIFIER ::= { frnetservConformance 2 } -- -- Service (Read-only) Modules -- frnetservCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which have Frame Relay Network Service Interfaces. The distinction between 'service' and 'switch' is that a 'switch' is configured via this MIB. Hence, the various read/write objects have write capability. A 'service' represents a passive monitor-only customer network management interface. The various read/write objects are restricted to read-only capability." MODULE -- this module MANDATORY-GROUPS { frnetservLportGroup2, frnetservMgtVCSigGroup, frnetservPVCEndptGroup, frnetservPVCEndptGroup2, frnetservPVCConnectGroup, frnetservPVCConnectNamesGroup, frnetservPVCNotifGroup2 } GROUP frnetservAccountPVCGroup DESCRIPTION "This group is optional for frame relay interfaces. It is mandatory if and only if accounting is performed on a PVC basis this frame relay interface." GROUP frnetservAccountLportGroup DESCRIPTION "This group is optional for frame relay interfaces. It is mandatory if and only if accounting is performed on a logical port basis this frame relay interface." OBJECT frPVCEndptInMaxFrameSize Rehbehn & Fowler Standards Track [Page 57] RFC 2954 Frame Relay Service MIB October 2000 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptInBc MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptInBe MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptInCIR MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutMaxFrameSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutBc MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutBe MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutCIR MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptRowStatus -- subset of RowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." Rehbehn & Fowler Standards Track [Page 58] RFC 2954 Frame Relay Service MIB October 2000 OBJECT frPVCConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCConnectRowStatus -- subset of RowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT frLportFragControl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frLportFragSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCConnectUserName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCConnectProviderName MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { frnetservCompliances 2 } -- -- Switch (Configuration) Compliance -- frnetSwitchCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which have Frame Relay Network Switch objects. The distinction between 'service' and 'switch' is that a 'switch' is configured via this MIB. Rehbehn & Fowler Standards Track [Page 59] RFC 2954 Frame Relay Service MIB October 2000 Hence, the various read/write objects have write capability. A 'service' represents a passive monitor-only customer network management interface. The various read/write objects are restricted to read-only capability." MODULE -- this module MANDATORY-GROUPS { frnetservLportGroup2, frnetservLportAdminGroup, frnetservMgtVCSigGroup, frnetservMgtVCSigAdminGroup, frnetservPVCEndptGroup, frnetservPVCEndptGroup2, frnetservPVCConnectGroup, frnetservPVCConnectNamesGroup, frnetservPVCNotifGroup2 } GROUP frnetservAccountPVCGroup DESCRIPTION "This group is optional for frame relay interfaces. It is mandatory if and only if accounting is performed on a PVC basis this frame relay interface." GROUP frnetservAccountLportGroup DESCRIPTION "This group is optional for frame relay interfaces. It is mandatory if and only if accounting is performed on a logical port basis this frame relay interface." ::= { frnetservCompliances 3 } -- -- Historical RFC 1604 Compliance Modules -- frnetservCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMP entities which have Frame Relay Network Service Interfaces. This compliance statement has been deprecated in favor of frnetservCompliance2. The new compliance module expands the mandatory groups to include notification and other new objects." MODULE -- this module MANDATORY-GROUPS { frnetservLportGroup, Rehbehn & Fowler Standards Track [Page 60] RFC 2954 Frame Relay Service MIB October 2000 frnetservMgtVCSigGroup, frnetservPVCEndptGroup, frnetservPVCConnectGroup } GROUP frnetservAccountPVCGroup DESCRIPTION "This group is optional for Frame Relay interfaces. It is mandatory if and only if accounting is performed on a PVC basis this Frame Relay interface." GROUP frnetservAccountLportGroup DESCRIPTION "This group is optional for Frame Relay interfaces. It is mandatory if and only if accounting is performed on a logical port basis this Frame Relay interface." OBJECT frPVCEndptInMaxFrameSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptInBc MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptInBe MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptInCIR MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutMaxFrameSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutBc MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutBe Rehbehn & Fowler Standards Track [Page 61] RFC 2954 Frame Relay Service MIB October 2000 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptOutCIR MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCEndptRowStatus -- subset of RowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT frPVCConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT frPVCConnectRowStatus -- subset of RowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." ::= { frnetservCompliances 1 } -- -- Frame Relay Service MIB Object Groups -- frnetservLportGroup OBJECT-GROUP OBJECTS { frLportNumPlan, frLportContact, frLportLocation, frLportType, frLportAddrDLCILen, frLportVCSigProtocol, frLportVCSigPointer } STATUS deprecated DESCRIPTION "A collection of objects providing information applicable to a Frame Relay Logical Port. This group has been deprecated to eliminate reference Rehbehn & Fowler Standards Track [Page 62] RFC 2954 Frame Relay Service MIB October 2000 to the object frLportVCSigPointer. Use the new group frnetservLportGroup2 as a replacement for this group." ::= { frnetservGroups 1 } frnetservMgtVCSigGroup OBJECT-GROUP OBJECTS { frMgtVCSigProced, frMgtVCSigUserN391, frMgtVCSigUserN392, frMgtVCSigUserN393, frMgtVCSigUserT391, frMgtVCSigNetN392, frMgtVCSigNetN393, frMgtVCSigNetT392, frMgtVCSigNetnN4, frMgtVCSigNetnT3, frMgtVCSigUserLinkRelErrors, frMgtVCSigUserProtErrors, frMgtVCSigUserChanInactive, frMgtVCSigNetLinkRelErrors, frMgtVCSigNetProtErrors, frMgtVCSigNetChanInactive } STATUS current DESCRIPTION "A collection of objects providing information applicable to the Local In-Channel Signaling Procedures used for a UNI/NNI logical port." ::= { frnetservGroups 2 } frnetservPVCEndptGroup OBJECT-GROUP OBJECTS { frPVCConnectIndexValue, frPVCEndptInMaxFrameSize, frPVCEndptInBc, frPVCEndptInBe, frPVCEndptInCIR, frPVCEndptOutMaxFrameSize, frPVCEndptOutBc, frPVCEndptOutBe, frPVCEndptOutCIR, frPVCEndptConnectIdentifier, frPVCEndptRowStatus, frPVCEndptRcvdSigStatus, frPVCEndptInFrames, frPVCEndptOutFrames, frPVCEndptInDEFrames, frPVCEndptInExcessFrames, frPVCEndptOutExcessFrames, Rehbehn & Fowler Standards Track [Page 63] RFC 2954 Frame Relay Service MIB October 2000 frPVCEndptInDiscards, frPVCEndptInOctets, frPVCEndptOutOctets } STATUS current DESCRIPTION "A collection of objects providing information applicable to a Frame Relay PVC end-point." ::= { frnetservGroups 3 } frnetservPVCConnectGroup OBJECT-GROUP OBJECTS { frPVCConnectAdminStatus, frPVCConnectL2hOperStatus, frPVCConnectH2lOperStatus, frPVCConnectL2hLastChange, frPVCConnectH2lLastChange, frPVCConnectRowStatus } STATUS current DESCRIPTION "A collection of objects providing information applicable to a Frame Relay PVC connection." ::= { frnetservGroups 4 } frnetservAccountPVCGroup OBJECT-GROUP OBJECTS { frAccountPVCSegmentSize, frAccountPVCInSegments, frAccountPVCOutSegments } STATUS current DESCRIPTION "A collection of objects providing accounting information application to a Frame Relay PVC end- point." ::= { frnetservGroups 5 } frnetservAccountLportGroup OBJECT-GROUP OBJECTS { frAccountLportSegmentSize, frAccountLportInSegments, frAccountLportOutSegments } STATUS current DESCRIPTION "A collection of objects providing accounting information application to a Frame Relay logical port." ::= { frnetservGroups 6 } frnetservLportGroup2 OBJECT-GROUP OBJECTS { frLportNumPlan, frLportContact, frLportLocation, Rehbehn & Fowler Standards Track [Page 64] RFC 2954 Frame Relay Service MIB October 2000 frLportType, frLportAddrDLCILen, frLportVCSigProtocol, frLportFragControl, frLportFragSize } STATUS current DESCRIPTION "A collection of objects providing information applicable to a Frame Relay Logical Port. This new version of the Logical Port Group eliminates the frLportVCSigPointer and adds support for fragmentation." ::= { frnetservGroups 7 } frnetservPVCEndptGroup2 OBJECT-GROUP OBJECTS { frPVCEndptInDiscardsDESet, frPVCEndptInFramesFECNSet, frPVCEndptOutFramesFECNSet, frPVCEndptInFramesBECNSet, frPVCEndptOutFramesBECNSet, frPVCEndptInCongDiscards, frPVCEndptInDECongDiscards, frPVCEndptOutCongDiscards, frPVCEndptOutDECongDiscards, frPVCEndptOutDEFrames, frPVCEndptAtmIwfConnIndex } STATUS current DESCRIPTION "Additions to the PVC end-point group. These additions provide new frame counters to track frame loss. In addition, the new FR/ATM IWF MIB cross-connect index is included." ::= { frnetservGroups 8 } frnetservPVCConnectNamesGroup OBJECT-GROUP OBJECTS { frPVCConnectUserName, frPVCConnectProviderName } STATUS current DESCRIPTION "Additions to the PVC Connect Group." ::= { frnetservGroups 9 } frnetservLportAdminGroup OBJECT-GROUP OBJECTS { frLportDLCIIndexValue, frLportTypeAdmin, frLportVCSigProtocolAdmin } STATUS current Rehbehn & Fowler Standards Track [Page 65] RFC 2954 Frame Relay Service MIB October 2000 DESCRIPTION "Administrative (R/W) objects for creating a switch logical port." ::= { frnetservGroups 10 } frnetservMgtVCSigAdminGroup OBJECT-GROUP OBJECTS { frMgtVCSigProcedAdmin, frMgtVCSigUserN391Admin, frMgtVCSigUserN392Admin, frMgtVCSigUserN393Admin, frMgtVCSigUserT391Admin, frMgtVCSigNetN392Admin, frMgtVCSigNetN393Admin, frMgtVCSigNetT392Admin, frMgtVCSigNetnT3Admin } STATUS current DESCRIPTION "A collection of objects providing information applicable to the Local In-Channel Signaling Procedures used for a UNI/NNI logical port." ::= { frnetservGroups 11 } frnetservPVCNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { frPVCConnectStatusChange } STATUS deprecated DESCRIPTION "Deprecated notification group. The frPVCConnectStatusChange notification was flawed because it included redundant indexes and was not properly encoded for SMIv1 conversion." ::= { frnetservGroups 12 } frnetservPVCNotifGroup2 NOTIFICATION-GROUP NOTIFICATIONS { frPVCConnectStatusNotif } STATUS current DESCRIPTION "A collection of notifications that apply to frame relay PVC Connections " ::= { frnetservGroups 13 } END Rehbehn & Fowler Standards Track [Page 66] RFC 2954 Frame Relay Service MIB October 2000 4. Acknowledgments This document was produced by the Frame Relay Service MIB Working Group. The working group thanks Bert Wijnen, David Perkins, and Bob Stewart for their assistance in reviewing the MIB. 5. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. Rehbehn & Fowler Standards Track [Page 67] RFC 2954 Frame Relay Service MIB October 2000 [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [17] ANSI T1.617-1991, American National Standard for Telecommunications - Integrated Services Digital Network (ISDN) - Digital Subscriber Signaling System No. 1 (DSS1) - Signaling Specification for Frame Relay Bearer Service. [18] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs", RFC 2115, September 1997. [19] Brown, C. and A. Malis, "Multi-Protocol Interconnect over Frame Relay", STD 55, RFC 2427, September 1998. [20] Fowler, D, "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Types", RFC 2494, January 1999. [21] Frame Relay Forum, "Frame Relay Fragmentation Implementation Agreement", FRF.12, December 1997. [22] ITU-T Recommendation Q.933,Integrated Services Digital Network (ISDN) Digital Subscriber Signalling System No. 1 (DSS 1) - Signalling Specifications for Frame Mode Switched and Permanent Virtual Connection Control and Status Monitoring, December 1995 Rehbehn & Fowler Standards Track [Page 68] RFC 2954 Frame Relay Service MIB October 2000 [23] ITU-T Recommendation X.36, Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) For Public Data Networks Providing Frame Relay Data Transmission Service By Dedicated Circuit, April 1995 [24] Digital Equipment Corporation, et. al., "Frame Relay Specification with Extensions Based on Proposed T1S1 Standards", Revision 1.0, September 18, 1990 [25] ITU-T Recommendation Q.922, Integrated Services Digital Network (ISDN) Data Link Layer Specification For Frame Mode Bearer Services, February 1992 [26] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [27] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [28] Rehbehn, K., Nicklass, O. and G. Mouradian, "Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function", RFC 2955, October 2000. [29] ITU-T Recommendation E.164/I.331, The International Public Telecommunication Numbering Plan, May 1997 [30] ITU-T Recommendation X.121, International Numbering Plan For Public Data Networks, October 1996 [31] Frame Relay Forum, "The Frame Relay Forum User-to-Network Implementation Agreement (UNI)", FRF 1.2, July 2000. 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. No managed objects in this MIB contain sensitive information. Rehbehn & Fowler Standards Track [Page 69] RFC 2954 Frame Relay Service MIB October 2000 SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Authors' Addresses Kenneth Rehbehn Megisto Systems, Inc. 20251 Century Boulevard Germantown, MD, USA 20874 Phone: (301) 515-3672 EMail: krehbehn@megisto.com David Fowler Syndesis Limited 28 Fulton Way Richmond Hill, Ontario, Canada L4B 1J5 Phone: (905) 886-7818 EMail: fowler@syndesis.com Rehbehn & Fowler Standards Track [Page 70] RFC 2954 Frame Relay Service MIB October 2000 APPENDIX A Update Information The changes from RFC 1604 are the following: (1) Added the object frLportDLCIIndexValue to automatically generate index values for new DLC rows. (2) Add the following objects to support manager writing to objects: Logical Port Objects frLportTypeAdmin frLportVCSigProtocolAdmin VC Objects frMgtVCSigProcedAdmin frMgtVCSigUserN391Admin frMgtVCSigUserN392Admin frMgtVCSigUserN393Admin frMgtVCSigUserT391Admin frMgtVCSigNetN392Admin frMgtVCSigNetN393Admin frMgtVCSigNetT392Admin frMgtVCSigNetnT3Admin (3) Add objects to control fragmentation: frLportFragControl frLportFragSize (4) Added objects to track frames offered to network (in) and delivered (out) for increased visibility into policing-driven discards, congestion-driven discards, DE-bit setting, and congestion bit setting: frPVCEndptInDiscardsDESet frPVCEndptInFramesFECNSet frPVCEndptOutFramesFECNSet frPVCEndptInFramesBECNSet frPVCEndptOutFramesBECNSet frPVCEndptInCongDiscards frPVCEndptInDECongDiscards frPVCEndptOutCongDiscards frPVCEndptOutDECongDiscards frPVCEndptOutDEFrames (5) Added the PVC object frPVCEndptAtmIwfConnIndex to identify the type of connection, frame relay or ATM IWF; and to identify the cross-connect row of the FR/ATM IWF MIB. Rehbehn & Fowler Standards Track [Page 71] RFC 2954 Frame Relay Service MIB October 2000 (6) Added objects to provide printable names of the connection user and service provider: frPVCConnectUserName frPVCConnectProviderName (7) Added a new notification to correct flaws in the RFC1604 trap. The flaws include improper OID suffix (SMIv1 compatibility issue) and the inclusion of redundant index fields (8) Updated compliance modules and object groups to reflect the new objects and notification: frnetservCompliance2 - New service-centric (read-only) compliance module frnetSwitchCompliance - New switch-centric (read-write) compliance module frnetservCompliance - Original RFC 1604 Module, now deprecated frnetservLportGroup - Original RFC 1604 logical port group, now deprecated frnetservLportGroup2 - Replacement logical port group frnetservPVCEndptGroup2 - Extension objects with this revision of the MIB frnetservPVCConnectNamesGroup - New group w/ display names for connections frnetservLportAdminGroup - New group w/ read-write objects for the logical port frnetservMgtVCSigAdminGroup - New group w/ read-write objects for the signaling protocol frnetservPVCNotifGroup - Group deprecated to eliminate obsolete frPVCConnectStatusChange notification frnetservPVCNotifGroup2 - New group added with w/ frPVCConnectStatusNotif (9) Added UNITS and REFERENCE clauses for objects that needed the clarification. Rehbehn & Fowler Standards Track [Page 72] RFC 2954 Frame Relay Service MIB October 2000 (10) Changed references to "proxy-agent" to "FRS agent" to avoid confusion with other proxy-agent terminology. (11) Changed objects using the DisplayString TC to use the SnmpAdminString TC. (12) frMgtVCSigProced - Expanded to include the u2nuser(3) enumeration for the UNI protocol operation where the logical port operates in the user role. (13) DESCRIPTION text added to specify agent response when object is not instantiated for the following objects: frMgtVCSigUserN391 frMgtVCSigUserN393 frMgtVCSigUserT391 frMgtVCSigUserN392 frMgtVCSigNetN391 frMgtVCSigNetN393 frMgtVCSigNetT391 frMgtVCSigNetN392 frMgtVCSigNetnN4 frMgtVCSigNetnT3 frMgtVCSigUserLinkRelErrors frMgtVCSigUserProtErrors frMgtVCSigUserChanInactive (14) DESCRIPTION text addressing case of logical port not performing network-side procedures was removed from following objects: frMgtVCSigNetLinkRelErrors frMgtVCSigNetChanInactive frMgtVCSigNetProtErrors (15) frPVCEndptConnectIdentifier - Operation described for the case of FR/ATM IWF cross-connect operation. (16) frPVCEndptRcvdSigStatus - Added description of enumerated values. (17) frPVCEndptInDiscards - Clarified DESCRIPTION to state that congestion discards are not counted by object. (18) frPVCConnect{Low|High}IfIndex - Changed to use InterfaceIndex TC and changed reference to MIB-II to the new IF-MIB. Removed statement asserting that a zero value means the port is not a FR logical port. Rehbehn & Fowler Standards Track [Page 73] RFC 2954 Frame Relay Service MIB October 2000 (19) frPVCConnectIndex - Added a range to the SYNTAX clause (20) frPVCConnect{L2h|H2l}OperStatus - Added DESCRIPTION text for each enumerated value. (21) frAccountPVCDLCIIndex - Added a range to the SYNTAX clause (22) frPVCCOnnectStatusChange Notification - STATUS change to deprecated. Obsoleted to eliminate inappropriate inclusion of index objects (23) frPVCConnectStatusNotif Notification - Replaces frPVCConnectStatusChange. In addition, the notification now requires 2 instances of the frPVCEndptRcvdSigStatus object, one for each endpoint of the connection. (24) Guidance added to recommend ifLinkUpDownTrapEnable be set on. (25) Behavior of the PVC status and endpoint signaling status is clarified for the case of underlying layer failure. (26) Overview text re-written for clarity. (27) Clarified role of system group. (28) Established maximum frame size of 4096 and default value of 1600. (29) Clarified that DLC index range is restricted to valid range for the specific length of address field used on the logical port. (30) Figure 1 and accompanying text was removed to eliminate a confusing "MIB stack" concept. See the section titled "Relation to Other MIBs" for replacement text. Rehbehn & Fowler Standards Track [Page 74] RFC 2954 Frame Relay Service MIB October 2000 Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Rehbehn & Fowler Standards Track [Page 75] RFC 2954 Frame Relay Service MIB October 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rehbehn & Fowler Standards Track [Page 76] snmp-mibs-downloader-1.1/mibrfcs/rfc2955.txt0000644000000000000000000024252111402176071015574 0ustar Network Working Group K. Rehbehn Request for Comments: 2955 Megisto Systems Category: Standards Track O. Nicklass RAD Data Communications, Ltd. G. Mouradian AT&T Labs October 2000 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. Table of Contents 1. The SNMP Management Framework ............................... 2 2. Conventions ................................................. 3 3. Overview .................................................... 3 3.1 Frame Relay/ATM Service Interworking Background ............ 4 3.2 Structure of the MIB ....................................... 4 3.3 Relationship to Other MIBs ................................. 5 3.3.1 Frame Relay Service MIB .................................. 6 3.3.2 Frame Relay DTE MIB ...................................... 6 3.3.3 ATM MIB .................................................. 6 3.3.4 IF MIB ................................................... 7 3.4 Point to Multipoint Considerations ......................... 7 3.5 Theory of Operation ........................................ 7 3.5.1 Creation Process ......................................... 7 3.5.2 Destruction Process ...................................... 10 Rehbehn, et al. Standards Track [Page 1] RFC 2955 FR to ATM Service Interworking MIB October 2000 3.5.3 Modification Process ..................................... 11 4. Object Definitions .......................................... 11 4.1 The FR/ATM PVC Service IWF Connection Group ................ 13 4.2 The FR/ATM PVC Service IWF Connection Descriptor Group ..... 21 5. Augmentation of ATM MIB VCL Endpoint Entry (atmVclEntry) .... 27 6. Frame Relay/ATM PVC Service Interworking NOTIFICATION ....... 29 7. Conformance Information ..................................... 29 7.1 Compliance Statement For Equipment ......................... 29 7.2 Compliance Statement For Service (CNM Interface) ........... 30 7.3 Units of Conformance ....................................... 32 7.3.1 Basic FR/ATM IWF PVC Connection Group .................... 32 7.3.2 FR/ATM IWF PVC Connection Descriptor Group ............... 32 7.3.3 ATM MIB VCL Endpoint Table Augmentation .................. 33 7.3.4 Notification Group ....................................... 33 8. Acknowledgments ............................................. 34 9. References .................................................. 34 10. Security Considerations .................................... 36 11. Authors' Addresses ......................................... 37 12. Intellectual Property Rights ............................... 38 13. Full Copyright Statement ................................... 39 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. Rehbehn, et al. Standards Track [Page 2] RFC 2955 FR to ATM Service Interworking MIB October 2000 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [23]. 3. Overview This document defines a Management Information Base (MIB) for monitoring and controlling a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. The agreements on which this MIB is based were reached jointly by the Frame Relay Forum and the ATM Forum and are documented in the Frame Relay Forum Document FRF.8 [17]. Rehbehn, et al. Standards Track [Page 3] RFC 2955 FR to ATM Service Interworking MIB October 2000 3.1. Frame Relay/ATM Service Interworking Background Frame relay to ATM interworking is a function that exchanges Protocol Data Units (PDU) between a frame relay service user and an ATM service user. Two types of interworking functions are specified for frame relay and ATM permanent virtual connection (PVC) service users: network interworking and service interworking. Network interworking provides PDU forwarding between frame relay service users inter-connected by an ATM service. Both endpoints are frame relay PVCs. Frame Relay to ATM PVC Network Interworking is defined in [20]. Service interworking provides PDU forwarding so that the ATM service user performs no frame relaying service-specific functions and the frame relay service user performs no ATM service-specific functions. Optionally, the service IWF translates particular higher layer protocols to satisfy the requirements of end-systems. Frame Relay to ATM PVC Service Interworking is defined in [17]. This MIB describes management objects used to provision, monitor, and control a Frame Relay/ATM PVC Service IWF. FRF.8 [17] does not address point-to-multipoint applications of the IWF. Implementations MAY provide support for point-to-multipoint capability using this MIB. Consult FRF.8 [17] for more details on the operation of a Frame Relay/ATM PVC Service IWF. 3.2. Structure of the MIB The Frame Relay/ATM PVC Service IWF managed objects are organized as follows: (1) FR/ATM PVC Service IWF cross-connect table, (2) Connection description table, and (3) Notification object The IWF cross-connect table contains one or more rows for each inter-worked connection. Each inter-worked connection is uniquely identified by the frAtmIwfConnIndex object. In the case of point-to- point, a single row is present. In the case of point-to-multipoint, one row exists for each multipoint destination. Index objects for the ATM port, VPI, VCI, frame relay port, and frame relay DLCI distinguish the constituent rows used in a point-to-multipoint case. Rehbehn, et al. Standards Track [Page 4] RFC 2955 FR to ATM Service Interworking MIB October 2000 Each inter-worked connection has attributes governing behavior of the IWF. These attributes describe how the IWF should transform a PDU during the forwarding process and provide rules for: (1) Mapping the ATM CLP bit to frame relay DE bit (2) Mapping the ATM congestion notification bit to frame relay congestion bits (3) Mapping higher protocol encapsulations between ATM and frame relay (4) Performing fragmentation and reassembly (5) Performing ARP translation between ATM and frame relay Typically, most connections share the same attributes. The attributes are represented in this MIB by the connection description table. Each row of the connection description table contains the attribute settings common to one or more inter-worked connections. One example would be full mapping and translation. All cross-connect table entries that require full mapping and translation services set the frAtmIwfConnectionDescriptor object to the index value for the connection description table row that contains objects set to values that provide full mapping and translation services. A notification object provides cross-connect status change alerts. 3.3. Relationship to Other MIBs The Frame Relay/ATM PVC Service IWF MIB describes the cross- connections between frame relay and ATM service users. Each PVC endpoint is provisioned and managed with a technology-specific MIB as described below. Each technology-specific MIB has a table of PVC endpoints (indexed by ifIndex and logical link address such as the DLCI or VPI/VCI). In the absence of interworking, two endpoints are cross-connected via a technology-specific cross connect table (e.g., the atmVcCrossConnectTable in the ATM MIB). However, a connection between a frame relay endpoint and an ATM endpoint requires a cross- connect in the ATM IWF MIB. The following sections describe the relationship between the technology-specific MIBs and the FR/ATM PVC Service IWF MIB. Rehbehn, et al. Standards Track [Page 5] RFC 2955 FR to ATM Service Interworking MIB October 2000 3.3.1. Frame Relay Service MIB Frame relay PVC endpoints are provisioned as rows in the Frame Relay Services MIB [19] endpoint table. Each frame relay PVC endpoint is described in the frPVCEndptTable. A connection between two frame relay endpoints is described by an entry in the frame relay PVC cross-connect table frPVCConnectTable. The frPVCEndptConnectIdentifier object of each endpoint points to the frPVCConnectTable cross-connect table row for the connection. In the case of an inter-worked connection, the frPVCEndptConnectIdentifier object is set to zero. Instead, the frPVCEndptAtmIwfConnIndex object is set to the index of the FR/ATM IWF cross-connect table row. The frame relay PVC cross-connect table (frPVCConnectTable) does not contain an entry for the FR/ATM inter-worked connection. Note that the frPVCEndptConnectIdentifier and frPVCEndptAtmIwfConnIndex objects are set by the system as a side- effect of cross-connect establishment. Consequently, these objects are read-only. 3.3.2. Frame Relay DTE MIB The Frame Relay DTE MIB described in [24] has no relevance to the FR/ATM PVC Service IWF MIB. 3.3.3. ATM MIB ATM PVC endpoints are provisioned as rows in the ATM MIB [21] virtual connection link table. Each ATM connection endpoint is described in the atmVclTable. A connection between two ATM endpoints is described by an entry in the ATM VCL cross-connect table atmVcCrossConnectTable. The atmVclCrossConnectIdentifier object of each endpoint points to the atmVcCrossConnectTable row for the connection. In the case of an inter-worked connection, the atmVclCrossConnectIdentifier object is set to zero. Instead, the frAtmIwfVclCrossConnectIdentifier object in the frAtmIwfVclEntry is set to the index of the applicable FR/ATM IWF cross-connect table row. Rehbehn, et al. Standards Track [Page 6] RFC 2955 FR to ATM Service Interworking MIB October 2000 Note that the frAtmIwfVclCrossConnectIdentifier object is defined not in the ATM MIB but in Section 5 of this MIB. Specifically, the object is defined as a column object in a table that AUGMENTs the ATM MIB VCL table. The ATM VCL cross-connect table (atmVcCrossConnectTable) does not contain an entry for the inter-worked connection. Note that the atmVclCrossConnectIdentifier and frAtmIwfVclCrossConnectIdentifier objects are set by the system as a side-effect of cross-connect establishment. Consequently, these objects are read-only. 3.3.4. IF MIB The ifIndex defined in the IF MIB [22] identifies the specific frame relay and ATM endpoint interfaces. The values frAtmIwfConnAtmPort and frAtmIwfConnFrPort are used in this MIB as components in the index list for the frAtmIwfConnectionTable rows. 3.4. Point to Multipoint Considerations This MIB supports IWF implementations providing point-to-multipoint functionality. All rows of the cross-connect table indexed by the same frAtmIwfConnIndex MUST utilize the same frAtmIwfConnectionDescriptor value. A group of cross-connect table entries indexed by the same frAtmIwfConnIndex value MUST agree on which service the multipoint operation is offered. Two cases are possible: (1) Many frame relay PVCs cross-connected to one ATM PVC, or (2) One frame relay PVC cross-connected to many ATM PVCs 3.5. Theory of Operation 3.5.1. Creation Process Multiple steps are required to create a frame relay to ATM cross- connection. First, rows must be created in the following tables: (1) The Frame Relay Service MIB frPVCEndptTable (2) The ATM MIB atmVclTable (3) The FR/ATM Service IWF MIB frAtmIwfConnectionDescriptorTable Rehbehn, et al. Standards Track [Page 7] RFC 2955 FR to ATM Service Interworking MIB October 2000 (4) The FR/ATM Service IWF MIB frAtmIwfConnectionTable Second, the newly created rows are cross-linked. Finally, the administrative and operational status objects are set to 'up(1)'. A step-by-step example is provided to illustrate the creation process. In this example, the term "Manager" refers to a network management system that issues SNMP protocol actions to an "Agent". The agent is integrated with the system that implements the frame relay to ATM service IWF. In this example, the following cross- connection is created: +-----------------------------------+ +---------+ | FR/ATM PVC Service IWF | | Frame | | ------------------------------ | +-----------+ | Relay | +--------> frAtmIwfConnIndex K <--------+ | ATM | |Endpoint | | | V | | | Endpoint | | ------- | | | | | | | --------- | | DLCI X | | | +------------+ | | |VPI.VCI Q.R| | on |<-+ | | | +->| on | |ifIndex Y| | V | | ifIndex S | +---------+ |frAtmIwfConnectionDescriptorIndex L| +-----------+ +-----------------------------------+ Step 1 - Create the frame relay PVC endpoint a) Manager requests creation of a new row in the frPVCEndptTable b) Agent receives management request to create a row in frPVCEndptTable for the frame relay side c) A new row is created in frPVCEndptTable as follows: - frPVCEndptConnectIdentifier initialized to zero - frPVCEndptAtmIwfConnIndex initialized to zero - remaining row objects initialized as needed for DLCI X on ifIndex Y Step 2 - Create the ATM PVC endpoint a) Agent receives management request to create a row in atmVclTable for the ATM side Rehbehn, et al. Standards Track [Page 8] RFC 2955 FR to ATM Service Interworking MIB October 2000 b) A new row is created in atmVclTable and frAtmIwfVclTable (the AUGMENT to the atmVclTable) as follows: - atmVclCrossConnectIdentifier initialized to zero - frAtmIwfVclCrossConnectIdentifier initialized to zero - atmVclConnKind initialized to pvc(1) - remaining row objects initialized as needed for VPI.VCI Q.R on ifIndex S Step 3 - Create the FR/ATM connection descriptor a) If an existing connection descriptor is appropriate for the new connection, go to Step 4 using the selected connection descriptor index value L b) Manager requests a new connection descriptor index value by reading frAtmIwfConnectionDescriptorIndexNext from the agent c) Agent receives GET request for frAtmIwfConnectionDescriptorIndexNext and responds with the next available value L d) Manager requests a new connection descriptor row entry using the value L as the index e) Agent receives SET request to create the frAtmIwfConnectionDescriptorTable row entry causes the system to create a row in the table. Step 4 - Create the FR/ATM cross-connect a) Manager requests a new cross-connect index value by reading frAtmIwfConnIndexNext from the agent b) Agent receives GET request for frAtmIwfConnIndexNext and responds with the next available value K c) Manager requests a new cross-connect row entry using the value K as the index d) Agent receives SET request to create the frAtmIwfConnectionTable row entry (note: the frame relay and ATM PVC endpoints MUST exist and be specified as part of the index fields for the row 'K.S.Q.R.Y.X') Rehbehn, et al. Standards Track [Page 9] RFC 2955 FR to ATM Service Interworking MIB October 2000 e) System creates a row in frAtmIwfConnectionTable for the following indices: - frAtmIwfConnIndex of K - frAtmIwfConnAtmPort of S - frAtmIwfConnVpi of Q - frAtmIwfConnVci of R - frAtmIwfConnFrPort of Y - frAtmIwfConnDlci of X - frAtmIwfConnectionDescriptor of L Step 5 - The system sets the frame relay PVC endpoint and ATM VCL endpoint to point to the FR/ATM cross-connect row (as a side-effect of Step 4). a) System sets frPVCEndptAtmIwfConnIndex to K b) System sets frAtmIwfVclCrossConnectIdentifier to K Step 6 - Manager signals activation by issuing a SET for the frAtmIwfConnAdminStatus object using the value of 'up(1)' Step 7 - Agent receives SET request for frAtmIwfConnAdminStatus and executes internal system mechanisms to activate each PVC segment and the IWF cross-connect. The successful activation permits the agent to respond with 'up(1)' when a GET request is received for the following fields: - frAtmIwfConnAtm2FrOperStatus - frAtmIwfConnFr2AtmOperStatus - atmVclOperStatus (Note: there is no comparable FRS MIB object) 3.5.2. Destruction Process Destruction of the frame relay to ATM cross-connection is initiated by the network management system. The agent's processing of the request stimulates implementation-specific system clean-up actions. Following removal of the row in the cross-connection table, the frAtmIwfVclCrossConnectIdentifier in the frAtmIwfVclTable (AUGMENT of Rehbehn, et al. Standards Track [Page 10] RFC 2955 FR to ATM Service Interworking MIB October 2000 the ATM MIB endpoint table) and frPVCEndptAtmIwfConnIndex in the Frame Relay Service MIB endpoint table are both re-initialized to zero. A step-by-step example is provided to illustrate the destruction process. Step 1 - Manager requests destruction of an existing row in the frAtmIwfConnectionTable by setting frAtmIwfConnRowStatus to destroy(6) Step 2 - Agent receives the SET request and performs implementation- specific system clean-up actions for the cross-connection row Step 3 - System updates the relevant cross connect information for the frame relay PVC endpoint by setting frPVCEndptAtmIwfConnIndex to 0 Step 4 - System updates the relevant cross connect information for the ATM PVC endpoint as follows: a) System sets frAtmIwfVclCrossConnectIdentifier to 0 b) System sets atmVclOperStatus to 'down(2)' (Note: there is no comparable FRS MIB object) Following the destruction of the FR/ATM cross-connection entry, the manager MAY set the frPVCConnectRowStatus and/or atmVclRowStatus to destroy(6) the associated endpoint entries. 3.5.3. Modification Process At the discretion of the agent, a FR/ATM cross-connect may be reconfigured by adding and/or deleting leafs to/from the IWF topology as per the FR/ATM IWF cross-connect creation/destruction procedures. Reconfiguration of traffic/service category parameter values requires release of the FR/ATM IWF cross-connect before those parameter values may be changed for individual frame relay or ATM endpoint segments. 4. Object Definitions FR-ATM-PVC-SERVICE-IWF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, Counter32 FROM SNMPv2-SMI Rehbehn, et al. Standards Track [Page 11] RFC 2955 FR to ATM Service Interworking MIB October 2000 RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF AtmVpIdentifier, AtmVcIdentifier FROM ATM-TC-MIB atmVclEntry FROM ATM-MIB InterfaceIndex FROM IF-MIB; frAtmIwfMIB MODULE-IDENTITY LAST-UPDATED "200009280000Z" -- September 28, 2000 ORGANIZATION "IETF Frame Relay Service MIB Working Group" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/frnetmib-charter WG-email: frnetmib@sunroof.eng.sun.com Subscribe: frnetmib-request@sunroof.eng.sun.com Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib Chair: Andy Malis Vivace Networks, Inc. Email: Andy.Malis@vivacenetworks.com WG editor: Kenneth Rehbehn Megisto Systems, Inc. Email: krehbehn@megisto.com Co-author: Orly Nicklass RAD Data Communications Ltd. EMail: orly_n@rad.co.il Co-author: George Mouradian AT&T Labs EMail: gvm@att.com" DESCRIPTION "The MIB module for monitoring and controlling the Frame Relay/ATM PVC Service Interworking Function." -- -- Revision History -- Rehbehn, et al. Standards Track [Page 12] RFC 2955 FR to ATM Service Interworking MIB October 2000 REVISION "200009280000Z" DESCRIPTION "Published as RFC 2955" ::= { mib-2 86 } -- -- Object Identifiers -- frAtmIwfMIBObjects OBJECT IDENTIFIER ::= { frAtmIwfMIB 1 } frAtmIwfTraps OBJECT IDENTIFIER ::= { frAtmIwfMIB 2 } frAtmIwfTrapsPrefix OBJECT IDENTIFIER ::= { frAtmIwfTraps 0 } frAtmIwfConformance OBJECT IDENTIFIER ::= { frAtmIwfMIB 3 } frAtmIwfGroups OBJECT IDENTIFIER ::= { frAtmIwfConformance 1 } frAtmIwfCompliances OBJECT IDENTIFIER ::= { frAtmIwfConformance 2 } -- -- The FR/ATM PVC Service IWF Group -- -- The Frame Relay/ATM PVC Service Interworking Function -- Connection Table contains all connections utilizing -- the interworking function. -- frAtmIwfConnIndexNext OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for frAtmIwfConnIndex when creating entries in the frAtmIwfConnectionTable. The value 0 indicates that no unassigned entries are available. To obtain the frAtmIwfConnIndexNext value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next unassigned index." ::= { frAtmIwfMIBObjects 1 } Rehbehn, et al. Standards Track [Page 13] RFC 2955 FR to ATM Service Interworking MIB October 2000 frAtmIwfConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF FrAtmIwfConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table in which each row represents a Frame Relay/ATM interworking connection." ::= { frAtmIwfMIBObjects 2 } frAtmIwfConnectionEntry OBJECT-TYPE SYNTAX FrAtmIwfConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FrAtmIwfConnectionEntry provides an entry for an interworking connection between a frame relay PVC and one or more ATM PVCs, or an ATM PVC and one or more frame relay PVCs. A single frame relay PVC connected to a single ATM PVC is referred to as a `point-to-point' connection and is represented by a single row in the FR/ATM IWF Connection Table. The case of a single frame relay PVC connected to multiple ATM PVCs (or single ATM PVC connected to multiple frame relay PVCs) is referred to as a `point-to-multipoint' connection and is represented by multiple rows in the FR/ATM IWF Connection Table. The object frAtmIwfConnIndex uniquely identifies each point-to-point or point-to-multipoint connection. The manager obtains the frAtmIwfConnIndex value by reading the frAtmIwfConnIndexNext object. After a frAtmIwfConnIndex is assigned for the connection, the manager creates one or more rows in the Cross Connect Table; one for each cross- connection between the frame relay PVC and an ATM PVC. In the case of `point-to-multipoint' connections, all rows are indexed by the same frAtmIwfConnIndex value and MUST refer to the same frame relay PVC or ATM PVC respectively. An entry can be created only when at least one pair of frame relay and ATM PVCs exist. A row can be established by one-step set-request with all required parameter values and frAtmIwfConnRowStatus set to createAndGo(4). The Rehbehn, et al. Standards Track [Page 14] RFC 2955 FR to ATM Service Interworking MIB October 2000 Agent should perform all error checking as needed. A pair of cross-connected PVCs, as identified by a particular value of the indexes, is released by setting frAtmIwfConnRowStatus to destroy(6). The Agent may release all associated resources. The manager may remove the related PVCs thereafter. Indexes are persistent across reboots of the system." INDEX { frAtmIwfConnIndex, frAtmIwfConnAtmPort, frAtmIwfConnVpi, frAtmIwfConnVci, frAtmIwfConnFrPort, frAtmIwfConnDlci } ::= { frAtmIwfConnectionTable 1 } FrAtmIwfConnectionEntry ::= SEQUENCE { frAtmIwfConnIndex Integer32, frAtmIwfConnAtmPort InterfaceIndex, frAtmIwfConnVpi AtmVpIdentifier, frAtmIwfConnVci AtmVcIdentifier, frAtmIwfConnFrPort InterfaceIndex, frAtmIwfConnDlci Integer32, frAtmIwfConnRowStatus RowStatus, frAtmIwfConnAdminStatus INTEGER, frAtmIwfConnAtm2FrOperStatus INTEGER, frAtmIwfConnAtm2FrLastChange TimeStamp, frAtmIwfConnFr2AtmOperStatus INTEGER, frAtmIwfConnFr2AtmLastChange TimeStamp, frAtmIwfConnectionDescriptor Integer32, frAtmIwfConnFailedFrameTranslate Counter32, frAtmIwfConnOverSizedFrames Counter32, frAtmIwfConnFailedAal5PduTranslate Counter32, frAtmIwfConnOverSizedSDUs Counter32, frAtmIwfConnCrcErrors Counter32, frAtmIwfConnSarTimeOuts Counter32 } frAtmIwfConnIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for each point-to-point or point- to-multipoint connection. The manager obtains the frAtmIwfConnIndex value by reading the Rehbehn, et al. Standards Track [Page 15] RFC 2955 FR to ATM Service Interworking MIB October 2000 frAtmIwfConnIndexNext object. A point-to- multipoint connection will be represented in the frAtmIwfConnectionTable with multiple entries that share the same frAtmIwfConnIndex value." ::= { frAtmIwfConnectionEntry 1 } frAtmIwfConnAtmPort OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index in the ifTable that identifies the ATM port for this interworking connection." ::= { frAtmIwfConnectionEntry 2 } frAtmIwfConnVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI of the ATM PVC end point for this interworking connection." ::= { frAtmIwfConnectionEntry 3 } frAtmIwfConnVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI of the ATM PVC end point for this interworking connection." ::= { frAtmIwfConnectionEntry 4 } frAtmIwfConnFrPort OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index in the ifTable that identifies the frame relay port for this interworking connection." ::= { frAtmIwfConnectionEntry 5 } frAtmIwfConnDlci OBJECT-TYPE SYNTAX Integer32 (16..4194303) MAX-ACCESS not-accessible STATUS current Rehbehn, et al. Standards Track [Page 16] RFC 2955 FR to ATM Service Interworking MIB October 2000 DESCRIPTION "The DLCI that identifies the frame relay PVC end point for this interworking connection." ::= { frAtmIwfConnectionEntry 6 } frAtmIwfConnRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The table row may be created with 'createAndWait(5)' or 'createAndGo(4)'. To activate a connection entry, a valid connection descriptor MUST be established in the frAtmIwfConnectionDescriptor object. This object is set to 'destroy(6)' to delete the table row. Before the table row is destroyed, the OperStatus/AdminStatus of the corresponding endpoints MUST be 'down(2)'. The deactivation of the ATM endpoint MAY occur as a side-effect of deleting the FR/ATM IWF cross-connection table row. Otherwise, 'destroy(6)' operation MUST fail (error code 'inconsistentValue')." ::= { frAtmIwfConnectionEntry 7 } frAtmIwfConnAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational state for this FR/ATM interworked connection. up(1) = Activate the connection. Before the activation can be completed, the OperStatus/AdminStatus of the corresponding endpoints MUST be 'up(1)'. The activation of the corresponding endpoints MAY occur as a side-effect of activating the FR/ATM IWF cross-connection. down(2) = Deactivate the connection. Before the deactivation can be completed, the atmVclAdminStatus of the corresponding ATM endpoint MUST be 'down(2)'. The deactivation of the Rehbehn, et al. Standards Track [Page 17] RFC 2955 FR to ATM Service Interworking MIB October 2000 ATM endpoint MAY occur as a side-effect of deactivating the FR/ATM IWF cross-connection." ::= { frAtmIwfConnectionEntry 8 } frAtmIwfConnAtm2FrOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this interworking connection in the ATM to frame relay direction." ::= { frAtmIwfConnectionEntry 9 } frAtmIwfConnAtm2FrLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this interworking connection entered its current operational state in the ATM to FR direction. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { frAtmIwfConnectionEntry 10 } frAtmIwfConnFr2AtmOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this interworking connection in the frame relay to ATM direction." ::= { frAtmIwfConnectionEntry 11 } frAtmIwfConnFr2AtmLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this interworking connection entered its current operational state in the FR to ATM direction. If the current state was entered prior to the last Rehbehn, et al. Standards Track [Page 18] RFC 2955 FR to ATM Service Interworking MIB October 2000 re-initialization of the local network management subsystem, then this object contains a zero value." ::= { frAtmIwfConnectionEntry 12 } frAtmIwfConnectionDescriptor OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value represents a pointer to the relevant descriptor in the IWF descriptor table. An attempt to set this value to an inactive or non- existent row in the Connection Descriptor Table MUST fail (error code 'inconsistentValue')." ::= { frAtmIwfConnectionEntry 13 } frAtmIwfConnFailedFrameTranslate OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of frames discarded by the IWF because, while operating in Translation Mode, the IWF is unable to decode the incoming frame payload header according to the mapping rules. (i.e., payload header not recognized by the IWF). Frame relay frames are received in the frame relay to ATM direction of the PVC. When operating in Transparent Mode, the IWF MUST return noSuchInstance." REFERENCE "FRF.8 [17], Section 5.3.1" ::= { frAtmIwfConnectionEntry 14 } frAtmIwfConnOverSizedFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of frames discarded by the IWF because the frame is too large to be processed by the AAL5 segmentation procedure. Specifically, the frame Rehbehn, et al. Standards Track [Page 19] RFC 2955 FR to ATM Service Interworking MIB October 2000 does not conform to the size specified in the atmVccAal5CpcsTransmitSduSize object associated with the atmVclEntry at the ATM endpoint. Frame relay frames are received in the frame relay to ATM direction of the PVC." REFERENCE "ATM MIB [21], atmVclTable FRF.8 [17], 5.3.1.4" ::= { frAtmIwfConnectionEntry 15 } frAtmIwfConnFailedAal5PduTranslate OBJECT-TYPE SYNTAX Counter32 UNITS "PDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute counts the number of AAL5 PDUs discarded by the IWF because, while operating in Translation Mode, the IWF is unable to decode the incoming AAL5 PDU payload header according to the mapping rules. (i.e., payload header not recognized by the IWF). AAL5 PDUs are received in the ATM to frame relay direction of the PVC. When operating in Transparent Mode, the IWF MUST return noSuchInstance." REFERENCE "FRF.8 [17], Section 5.3.1" ::= { frAtmIwfConnectionEntry 16 } frAtmIwfConnOverSizedSDUs OBJECT-TYPE SYNTAX Counter32 UNITS "SDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of AAL5 SDUs discarded by the IWF because the SDU is too large to be forwarded on the frame relay segment of the connection. Specifically, the frame does not conform to the size specified in the frLportFragSize object of the FRS MIB [19]. AAL5 PDUs are received in the ATM to frame relay direction of the PVC." REFERENCE "FRS MIB [19], frLportTable Rehbehn, et al. Standards Track [Page 20] RFC 2955 FR to ATM Service Interworking MIB October 2000 FRF.8 [17], 5.3.1.4" ::= { frAtmIwfConnectionEntry 17 } frAtmIwfConnCrcErrors OBJECT-TYPE SYNTAX Counter32 UNITS "PDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs received with CRC-32 errors on this AAL5 VCC at the IWF. AAL5 PDUs are received in the ATM to frame relay direction of the PVC." REFERENCE "ATM MIB [21], atmVclTable" ::= { frAtmIwfConnectionEntry 18 } frAtmIwfConnSarTimeOuts OBJECT-TYPE SYNTAX Counter32 UNITS "PDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of partially re-assembled AAL5 CPCS PDUs which were discarded on this AAL5 VCC at the IWF because they were not fully re-assembled within the required time period. If the re- assembly timer is not supported, then this object contains a zero value. AAL5 PDUs are received in the ATM to frame relay direction of the PVC." REFERENCE "ATM MIB [21], atmVclTable" ::= { frAtmIwfConnectionEntry 19 } -- -- The FR/ATM PVC Service IWF Connection Descriptor Group -- -- The Frame Relay/ATM PVC Service Interworking Function -- Connection Descriptor table. A descriptor provides the -- attributes for a type of interworked connection. -- frAtmIwfConnectionDescriptorIndexNext OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only Rehbehn, et al. Standards Track [Page 21] RFC 2955 FR to ATM Service Interworking MIB October 2000 STATUS current DESCRIPTION "This object contains an appropriate value to be used for frAtmIwfConnectionDescriptorIndex when creating entries in the frAtmIwfConnectionDescriptorTable. The value 0 indicates that no unassigned entries are available. To obtain the frAtmIwfConnectionDescriptorIndexNext value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next unassigned index." ::= { frAtmIwfMIBObjects 3 } frAtmIwfConnectionDescriptorTable OBJECT-TYPE SYNTAX SEQUENCE OF FrAtmIwfConnectionDescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table in which each row represents a descriptor for one type of Frame Relay/ATM interworking connection. A descriptor may be assigned to zero or more FR/ATM PVC service IWF connections." ::= { frAtmIwfMIBObjects 4 } frAtmIwfConnectionDescriptorEntry OBJECT-TYPE SYNTAX FrAtmIwfConnectionDescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a descriptor in an interworking connection between a frame relay PVC and an ATM PVC." INDEX { frAtmIwfConnectionDescriptorIndex } ::= { frAtmIwfConnectionDescriptorTable 1 } FrAtmIwfConnectionDescriptorEntry ::= SEQUENCE { frAtmIwfConnectionDescriptorIndex Integer32, frAtmIwfConnDescriptorRowStatus RowStatus, frAtmIwfConnDeToClpMappingMode INTEGER, frAtmIwfConnClpToDeMappingMode INTEGER, frAtmIwfConnCongestionMappingMode INTEGER, frAtmIwfConnEncapsulationMappingMode INTEGER, frAtmIwfConnEncapsulationMappings BITS, frAtmIwfConnFragAndReassEnabled INTEGER, Rehbehn, et al. Standards Track [Page 22] RFC 2955 FR to ATM Service Interworking MIB October 2000 frAtmIwfConnArpTranslationEnabled INTEGER } frAtmIwfConnectionDescriptorIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify a descriptor in the table " ::= { frAtmIwfConnectionDescriptorEntry 1 } frAtmIwfConnDescriptorRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this table row. This object is used to create or delete an entry in the descriptor table. Creation of the row requires a row index (see frAtmIwfConnectionDescriptorIndexNext). If not explicitly set or in existence, all other columns of the row will be created and initialized to the default value. During creation, this object MAY be set to 'createAndGo(4)' or 'createAndWait(5)'. The object MUST contain the value 'active(1)' before any connection table entry references the row. To destroy a row in this table, this object is set to the 'destroy(6)' action. Row destruction MUST fail (error code 'inconsistentValue') if any connection references the row." ::= { frAtmIwfConnectionDescriptorEntry 2 } frAtmIwfConnDeToClpMappingMode OBJECT-TYPE SYNTAX INTEGER { mode1(1), mode2Const0(2), mode2Const1(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes which mode of translation is in use for loss priority mapping in the frame Rehbehn, et al. Standards Track [Page 23] RFC 2955 FR to ATM Service Interworking MIB October 2000 relay to ATM direction. mode1(1) = the DE field in the Q.922 core frame shall be mapped to the ATM CLP field of every cell generated by the segmentation process of the AAL5 PDU containing the information of that frame. mode2Contst0(2) = the ATM CLP field of every cell generated by the segmentation process of the AAL5 PDU containing the information of that frame shall be set to constant 0. mode2Contst1(3) = the ATM CLP field of every cell generated by the segmentation process of the AAL5 PDU containing the information of that frame shall be set to constant 1." REFERENCE "FRF.8 [17], Section 4.2.1" DEFVAL { mode1 } ::= { frAtmIwfConnectionDescriptorEntry 3 } frAtmIwfConnClpToDeMappingMode OBJECT-TYPE SYNTAX INTEGER { mode1(1), mode2Const0(2), mode2Const1(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes which mode of translation is in use for loss priority mapping in the ATM to frame relay direction. mode1(1) = if one or more cells in a frame has its CLP field set, the DE field of the Q.922 core frame should be set. mode2Const0(2) = the DE field of the Q.922 core frame should be set to the Rehbehn, et al. Standards Track [Page 24] RFC 2955 FR to ATM Service Interworking MIB October 2000 constant 0. mode2Const1(3) = the DE field of the Q.922 core frame should be set to the constant 1." REFERENCE "FRF.8 [17], Section 4.2.2" DEFVAL { mode1 } ::= { frAtmIwfConnectionDescriptorEntry 4 } frAtmIwfConnCongestionMappingMode OBJECT-TYPE SYNTAX INTEGER { mode1(1), mode2(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes which mode of translation is in use for forward congestion indication mapping in the frame relay to ATM direction. mode1(1) = The FECN field in the Q.922 core frame shall be mapped to the ATM EFCI field of every cell generated by the segmentation process of the AAL5 PDU containing the information of that frame. mode2(2) = The FECN field in the Q.922 core frame shall not be mapped to the ATM EFCI field of cells generated by the segmentation process of the AAL5 PDU containing the information of that frame. The EFCI field is always set to 'congestion not experienced'. In both of the modes above, if there is congestion in the forward direction in the ATM layer within the IWF, then the IWF can set the EFCI field to 'congestion experienced'." REFERENCE "FRF.8 [17], Section 4.3.1.1" DEFVAL { mode1 } ::= { frAtmIwfConnectionDescriptorEntry 5 } frAtmIwfConnEncapsulationMappingMode OBJECT-TYPE SYNTAX INTEGER { Rehbehn, et al. Standards Track [Page 25] RFC 2955 FR to ATM Service Interworking MIB October 2000 transparentMode(1), translationMode(2), translationModeAll(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether the mapping of upper layer protocol encapsulation is enabled on this interworking connection. transparentMode(1) = Forward the encapsulations unaltered. translationMode(2) = Perform mapping between the two encapsulations due to the incompatibilities of the two methods. Mapping is provided for a subset of the potential encapsulations as itemized in frAtmIwfConnEncapsulationMapp ings. translationModeAll(3) = Perform mapping between the two encapsulations due to the incompatibilities of the two methods. All encapsulations are translated." REFERENCE "FRF.8 [17], Section 5.3" DEFVAL { transparentMode } ::= { frAtmIwfConnectionDescriptorEntry 6 } frAtmIwfConnEncapsulationMappings OBJECT-TYPE SYNTAX BITS { none (0), bridgedPdus(1), bridged802dot6(2), bPdus(3), routedIp(4), routedOsi(5), otherRouted(6), x25Iso8202(7), q933q2931(8) } MAX-ACCESS read-create STATUS current DESCRIPTION Rehbehn, et al. Standards Track [Page 26] RFC 2955 FR to ATM Service Interworking MIB October 2000 "If upper layer protocol encapsulation mapping is enabled on this interworking connection, then this attribute enumerates which of the encapsulation mappings are supported. none(0) = Transparent mode operation bridgedPdus(1) = PID: 0x00-01,-07,-02 or -08 bridged802dot6(2) = PID: 0x00-0B bPdus(3) = PID: 0x00-0E or -0F routedIp(4) = NLPID: OxCC routedOsi(5) = NLPID: Ox81, 0x82 or 0x83 otherRouted(6) = Other routed protocols x25Iso8202(7) = X25 q933q2931(8) = Q.933 and Q.2931" REFERENCE "FRF.8 [17], Section 5.3.1" DEFVAL { { none } } ::= { frAtmIwfConnectionDescriptorEntry 7 } frAtmIwfConnFragAndReassEnabled OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2)} MAX-ACCESS read-create STATUS current DESCRIPTION "The attribute indicates whether fragmentation and reassembly is enabled for this connection." REFERENCE "FRF.8 [17], Section 5.3.1.4" DEFVAL { disabled } ::= { frAtmIwfConnectionDescriptorEntry 8 } frAtmIwfConnArpTranslationEnabled OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2)} MAX-ACCESS read-create STATUS current DESCRIPTION "The attribute indicates whether ARP translation is enabled for this connection." REFERENCE "FRF.8 [17], Section 5.4" DEFVAL { disabled } ::= { frAtmIwfConnectionDescriptorEntry 9 } -- -- Augmentation of ATM MIB VCL Endpoint Table (atmVclTable) -- frAtmIwfVclTable OBJECT-TYPE SYNTAX SEQUENCE OF FrAtmIwfVclEntry Rehbehn, et al. Standards Track [Page 27] RFC 2955 FR to ATM Service Interworking MIB October 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FR/ATM IWF VCL Table augments the ATM MIB VCL Endpoint table." ::= { frAtmIwfMIBObjects 5 } frAtmIwfVclEntry OBJECT-TYPE SYNTAX FrAtmIwfVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table are created only by the agent. One entry exists for each ATM VCL managed by the agent." AUGMENTS { atmVclEntry } ::= { frAtmIwfVclTable 1 } FrAtmIwfVclEntry ::= SEQUENCE { frAtmIwfVclCrossConnectIdentifier Integer32 } frAtmIwfVclCrossConnectIdentifier OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the index value of the FR/ATM cross-connect table entry used to link the ATM VCL with a frame relay PVC. Each row of the atmVclTable that is not cross- connected with a frame relay PVC MUST return the value zero when this object is read. In the case of (frame relay) point to (ATM) multipoint, multiple ATM VCLs will have the same value of this object, and all their cross- connections are identified by entries that are indexed by the same value of frAtmIwfVclCrossConnectIdentifier in the frAtmIwfConnectionTable of this MIB module. The value of this object is initialized by the agent after the associated entries in the frAtmIwfConnectionTable have been created." ::= { frAtmIwfVclEntry 1 } Rehbehn, et al. Standards Track [Page 28] RFC 2955 FR to ATM Service Interworking MIB October 2000 -- -- Frame Relay/ATM PVC Service Interworking NOTIFICATION -- frAtmIwfConnStatusChange NOTIFICATION-TYPE OBJECTS { frAtmIwfConnAdminStatus, frAtmIwfConnAtm2FrOperStatus, frAtmIwfConnFr2AtmOperStatus } STATUS current DESCRIPTION "An indication that the status of this interworking connection has changed." ::= { frAtmIwfTrapsPrefix 1 } -- -- Conformance Information -- -- -- Compliance Statement For Equipment -- frAtmIwfEquipmentCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for equipment that implements the FR/ATM Interworking MIB." MODULE -- this module MANDATORY-GROUPS { frAtmIwfBasicGroup, frAtmIwfConnectionDescriptorGroup, frAtmIwfAtmVclTableAugmentGroup, frAtmIwfNotificationsGroup } OBJECT frAtmIwfConnDeToClpMappingMode SYNTAX INTEGER { mode1(1) } DESCRIPTION "Only support for Mode 1 is REQUIRED." OBJECT frAtmIwfConnClpToDeMappingMode SYNTAX INTEGER { mode1(1) } DESCRIPTION "Only support for Mode 1 is REQUIRED." OBJECT frAtmIwfConnCongestionMappingMode SYNTAX INTEGER { mode1(1) } DESCRIPTION Rehbehn, et al. Standards Track [Page 29] RFC 2955 FR to ATM Service Interworking MIB October 2000 "Only support for Mode 1 is REQUIRED." OBJECT frAtmIwfConnEncapsulationMappingMode SYNTAX INTEGER { transparentMode(1) } DESCRIPTION "Support for Translation Mode is OPTIONAL." OBJECT frAtmIwfConnEncapsulationMappings SYNTAX BITS { none(0) } DESCRIPTION "The IWF may provide one, some or none of the encapsulation translations defined in section 5.3.1 of FRF.8 [17]." OBJECT frAtmIwfConnFragAndReassEnabled SYNTAX INTEGER { disabled(2) } DESCRIPTION "Only support for Mode 1 is REQUIRED." OBJECT frAtmIwfConnArpTranslationEnabled SYNTAX INTEGER { disabled(2) } DESCRIPTION "Support for ARP Translation is NOT REQUIRED." ::= { frAtmIwfCompliances 1 } -- -- Compliance Statement For Service (CNM Interface) -- frAtmIwfServiceCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for a CNM interface that implements the FR/ATM Interworking MIB." MODULE -- this module MANDATORY-GROUPS { frAtmIwfBasicGroup, frAtmIwfConnectionDescriptorGroup, frAtmIwfAtmVclTableAugmentGroup, frAtmIwfNotificationsGroup } -- -- Exceptions for each object type implemented for a -- CNM view of the FR/ATM Interworking MIB -- OBJECT frAtmIwfConnAdminStatus MIN-ACCESS read-only Rehbehn, et al. Standards Track [Page 30] RFC 2955 FR to ATM Service Interworking MIB October 2000 DESCRIPTION "Write access is not REQUIRED." OBJECT frAtmIwfConnDeToClpMappingMode SYNTAX INTEGER { mode1(1) } MIN-ACCESS read-only DESCRIPTION "Support for Mode 1 is REQUIRED. Other modes are OPTIONAL. Write access is NOT REQUIRED." OBJECT frAtmIwfConnClpToDeMappingMode SYNTAX INTEGER { mode1(1) } MIN-ACCESS read-only DESCRIPTION "Support for Mode 1 is REQUIRED. Other modes are OPTIONAL. Write access is NOT REQUIRED." OBJECT frAtmIwfConnCongestionMappingMode SYNTAX INTEGER { mode1(1) } MIN-ACCESS read-only DESCRIPTION "Support for Mode 1 is REQUIRED. Other modes are OPTIONAL. Write access is NOT REQUIRED." OBJECT frAtmIwfConnEncapsulationMappingMode SYNTAX INTEGER { transparentMode(1) } MIN-ACCESS read-only DESCRIPTION "Support for Transparent Mode is REQUIRED. Translation Mode is OPTIONAL. Write access is not required." OBJECT frAtmIwfConnEncapsulationMappings SYNTAX BITS { none(0) } MIN-ACCESS read-only DESCRIPTION "The IWF may provide one, some or none of the encapsulation translations defined in section 5.3.1 of FRF.8 [17]. Write access is not required." OBJECT frAtmIwfConnFragAndReassEnabled SYNTAX INTEGER { disabled(2) } MIN-ACCESS read-only DESCRIPTION "Support for Fragmentation and Reassembly is NOT REQUIRED. Write access is not required." Rehbehn, et al. Standards Track [Page 31] RFC 2955 FR to ATM Service Interworking MIB October 2000 OBJECT frAtmIwfConnArpTranslationEnabled SYNTAX INTEGER { disabled(2) } MIN-ACCESS read-only DESCRIPTION "Support for ARP Translation is not required. Write access is not required." OBJECT frAtmIwfConnRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { frAtmIwfCompliances 2 } -- -- Units of Conformance -- -- -- Basic FR/ATM IWF PVC Connection Group -- frAtmIwfBasicGroup OBJECT-GROUP OBJECTS { frAtmIwfConnIndexNext, frAtmIwfConnAdminStatus, frAtmIwfConnAtm2FrOperStatus, frAtmIwfConnAtm2FrLastChange, frAtmIwfConnFr2AtmOperStatus, frAtmIwfConnFr2AtmLastChange, frAtmIwfConnectionDescriptor, frAtmIwfConnFailedFrameTranslate, frAtmIwfConnOverSizedFrames, frAtmIwfConnFailedAal5PduTranslate, frAtmIwfConnOverSizedSDUs, frAtmIwfConnCrcErrors, frAtmIwfConnSarTimeOuts, frAtmIwfConnRowStatus } STATUS current DESCRIPTION "The collection of basic objects for configuration and control of FR/ATM interworking connections." ::= { frAtmIwfGroups 1 } -- -- FR/ATM IWF PVC Connection Descriptor Group -- frAtmIwfConnectionDescriptorGroup OBJECT-GROUP OBJECTS { Rehbehn, et al. Standards Track [Page 32] RFC 2955 FR to ATM Service Interworking MIB October 2000 frAtmIwfConnectionDescriptorIndexNext, frAtmIwfConnDeToClpMappingMode, frAtmIwfConnClpToDeMappingMode, frAtmIwfConnCongestionMappingMode, frAtmIwfConnEncapsulationMappingMode, frAtmIwfConnEncapsulationMappings, frAtmIwfConnFragAndReassEnabled, frAtmIwfConnArpTranslationEnabled, frAtmIwfConnDescriptorRowStatus } STATUS current DESCRIPTION "The collection of basic objects for specification of FR/ATM interworking connection descriptors." ::= { frAtmIwfGroups 2 } -- -- ATM MIB VCL Endpoint Table Augmentation Group -- frAtmIwfAtmVclTableAugmentGroup OBJECT-GROUP OBJECTS { frAtmIwfVclCrossConnectIdentifier } STATUS current DESCRIPTION "The ATM MIB VCL Endpoint Table AUGMENT object contained in the FR/ATM PVC Service Interworking MIB." ::= { frAtmIwfGroups 3 } -- -- Notification Group -- frAtmIwfNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { frAtmIwfConnStatusChange } STATUS current DESCRIPTION "The notification for FR/ATM interworking status change." ::= { frAtmIwfGroups 4 } END Rehbehn, et al. Standards Track [Page 33] RFC 2955 FR to ATM Service Interworking MIB October 2000 8. Acknowledgments This document was produced by the Frame Relay Service MIB Working Group. The Editors thank Bert Wijnen, Kaj Tesink, Keith McCloghrie, and David Perkins for providing many helpful comments and suggestions. 9. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. Rehbehn, et al. Standards Track [Page 34] RFC 2955 FR to ATM Service Interworking MIB October 2000 [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [17] Frame Relay/ATM PVC Service Interworking Implementation Agreement, Frame Relay Forum, Document Number FRF.8.1, March, 2000. [18] Noto, M., Spiegel, E. and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. [19] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for Frame Relay Service", RFC 2954, October 2000. [20] Frame Relay/ATM PVC Network Interworking Implementation Agreement, Frame Relay Forum, Document Number FRF.5, December 20, 1994. [21] Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. [22] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [23] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Rehbehn, et al. Standards Track [Page 35] RFC 2955 FR to ATM Service Interworking MIB October 2000 [24] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. 10. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. No managed objects in this MIB contain sensitive information. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Rehbehn, et al. Standards Track [Page 36] RFC 2955 FR to ATM Service Interworking MIB October 2000 11. Authors' Addresses Kenneth Rehbehn Megisto Systems, Inc. 20251 Century Boulevard Germantown, MD, USA 20874 Phone: +1 (301) 515-3672 EMail: krehbehn@megisto.com Orly Nicklass RAD Data Communications, Ltd. 12 Hanechoshet St. Tel Aviv 69710 Israel Phone: +972 (3) 6459588 EMail: orly_n@rad.co.il George Mouradian AT&T Labs, Room 1G-325 101 Crawfords Corner Road Holmdel, NJ USA 07733 Phone: +1 908 949 7671 EMail: gvm@att.com Rehbehn, et al. Standards Track [Page 37] RFC 2955 FR to ATM Service Interworking MIB October 2000 12. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Rehbehn, et al. Standards Track [Page 38] RFC 2955 FR to ATM Service Interworking MIB October 2000 13. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rehbehn, et al. Standards Track [Page 39] snmp-mibs-downloader-1.1/mibrfcs/rfc2959.txt0000644000000000000000000017115711402176071015606 0ustar Network Working Group M. Baugher Request for Comments: 2959 B. Strahm Category: Standards Track Intel Corp. I. Suconick VideoServer Corp. October 2000 Real-Time Transport Protocol Management Information Base 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol (RTP) systems (RFC1889). Table of Contents 1. The Network Management Framework ............................. 2 2. Overview ..................................................... 3 2.1 Components .................................................. 3 2.2 Applicability of the MIB to RTP System Implementations ...... 4 2.3 The Structure of the RTP MIB ................................ 4 3 Definitions ................................................... 5 4. Security Considerations ...................................... 26 5. Acknowledgements ............................................. 27 6. Intellectual Property ........................................ 27 7. References ................................................... 28 8. Authors' Addresses ........................................... 30 9. Full Copyright Statement ..................................... 31 Baugher, et al. Standards Track [Page 1] RFC 2959 RTP MIB October 2000 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable Baugher, et al. Standards Track [Page 2] RFC 2959 RTP MIB October 2000 information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview An "RTP System" may be a host end-system that runs an application program that sends or receives RTP data packets, or it may be an intermediate-system that forwards RTP packets. RTP Control Protocol (RTCP) packets are sent by senders and receivers to convey information about RTP packet transmission and reception [RFC1889]. RTP monitors may collect RTCP information on senders and receivers to and from an RTP host or intermediate-system. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2.1 Components The RTP MIB is structured around "Session," "Receiver" and "Sender" conceptual abstractions. 2.1.1 An "RTP Session" is the "...association of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport addresses may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast addresses plus a common port pair," as defined in section 3 of [RFC1889]. 2.1.2 A "Sender" is identified within an RTP session by a 32-bit numeric "Synchronization Source," or "SSRC", value and is "...the source of a stream of RTP packets" as defined in section 3 of [RFC1889]. The sender is also a source of RTCP Sender Report packets as specified in section 6 of [RFC1889]. 2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or multicast Receiver as described in 2.1.1, above. An RTP Receiver has an SSRC value that is unique to the session. An RTP Receiver is a source of RTCP Receiver Reports as specified in section 6 of [RFC1889]. Baugher, et al. Standards Track [Page 3] RFC 2959 RTP MIB October 2000 2.2 Applicability of the MIB to RTP System Implementations The RTP MIB may be used in two types of RTP implementations, RTP Host Systems (end systems) and RTP Monitors, see section 3 of [RFC1889]. Use of the RTP MIB for RTP Translators and Mixers, as defined in section 7 of [RFC1889], is for further study. 2.2.1 RTP host Systems are end-systems that may use the RTP MIB to collect RTP session and stream data that the host is sending or receiving; these data may be used by a network manager to detect and diagnose faults that occur over the lifetime of an RTP session as in a "help-desk" scenario. 2.2.2 RTP Monitors of multicast RTP sessions may be third-party or may be located in the RTP host. RTP Monitors may use the RTP MIB to collect RTP session and stream statistical data; these data may be used by a network manager for capacity planning and other network- management purposes. An RTP Monitor may use the RTP MIB to collect data to permit a network manager to detect and diagnose faults in RTP sessions or to permit a network manger to configure its operation. 2.2.3 Many host systems will want to keep track of streams beyond what they are sending and receiving. In a host monitor system, a host agent would use RTP data from the host to maintain data about streams it is sending and receiving, and RTCP data to collect data about other hosts in the session. For example, an agent for an RTP host that is sending a stream would use data from its RTP system to maintain the rtpSenderTable, but it may want to maintain a rtpRcvrTable for endpoints that are receiving its stream. To do this the RTP agent will collect RTCP data from the receivers of its stream to build the rtpRcvrTable. A host monitor system MUST set the rtpSessionMonitor object to 'true(1)', but it does not have to accept management operations that create and destroy rows in its rtpSessionTable. 2.3 The Structure of the RTP MIB There are six tables in the RTP MIB. The rtpSessionTable contains objects that describe active sessions at the host, or monitor. The rtpSenderTable contains information about senders to the RTP session. The rtpRcvrTable contains information about receivers of RTP session data. The rtpSessionInverseTable, rtpSenderInverseTable, and rtpRcvrInverseTable contain information to efficiently find indexes into the rtpSessionTable, rtpSenderTable, and rtpRcvrTable, respectively. Baugher, et al. Standards Track [Page 4] RFC 2959 RTP MIB October 2000 The reverse lookup tables (rtpSessionInverseTable, rtpSenderInverseTable, and rtpRcvrInverseTable) are optional tables to help management applications efficiently access conceptual rows in other tables. Implementors of this MIB SHOULD implement these tables for multicast RTP sessions when table indexes (rtpSessionIndex of rtpSessionTable, rtpSenderSSRC of rtpSenderTable, and the SSRC pair in the rtpRcvrTable) are not available from other MIBs. Otherwise, the management application may be forced to perform expensive tree walks through large numbers of sessions, senders, or receivers. For any particular RTP session, the rtpSessionMonitor object indicates whether remote senders or receivers to the RTP session are to be monitored. If rtpSessionMonitor is true(1) then senders and receivers to the session MUST be monitored with entries in the rtpSenderTable and rtpRcvrTable. RTP sessions are monitored by the RTP agent that updates rtpSenderTable and rtpRcvrTable objects with information from RTCP reports from remote senders or remote receivers respectively. rtpSessionNewIndex is a global object that permits a network- management application to obtain a unique index for conceptual row creation in the rtpSessionTable. In this way the SNMP Set operation MAY be used to configure a monitor. 3. Definitions RTP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Counter64, Gauge32, mib-2, Integer32, MODULE-IDENTITY, OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI RowStatus, TAddress, TDomain, TestAndIncr, TimeStamp, TruthValue FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF Utf8String FROM SYSAPPL-MIB InterfaceIndex FROM IF-MIB; rtpMIB MODULE-IDENTITY LAST-UPDATED "200010020000Z" -- 2 October 2000 ORGANIZATION "IETF AVT Working Group Email: rem-conf@es.net" CONTACT-INFO "Mark Baugher Postal: Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 Baugher, et al. Standards Track [Page 5] RFC 2959 RTP MIB October 2000 United States Tel: +1 503 466 8406 Email: mbaugher@passedge.com Bill Strahm Postal: Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 United States Tel: +1 503 264 4632 Email: bill.strahm@intel.com Irina Suconick Postal: Ennovate Networks 60 Codman Hill Rd., Boxboro, Ma 01719 Tel: +1 781-505-2155 Email: irina@ennovatenetworks.com" DESCRIPTION "The managed objects of RTP systems. The MIB is structured around three types of information. 1. General information about RTP sessions such as the session address. 2. Information about RTP streams being sent to an RTP session by a particular sender. 3. Information about RTP streams received on an RTP session by a particular receiver from a particular sender. There are two types of RTP Systems, RTP hosts and RTP monitors. As described below, certain objects are unique to a particular type of RTP System. An RTP host may also function as an RTP monitor. Refer to RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' section 3.0, for definitions." REVISION "200010020000Z" -- 2 October 2000 DESCRIPTION "Initial version of this MIB. Published as RFC 2959." ::= { mib-2 87 } -- -- OBJECTS -- rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 } rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 2 } -- Baugher, et al. Standards Track [Page 6] RFC 2959 RTP MIB October 2000 -- SESSION NEW INDEX -- rtpSessionNewIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assign values to rtpSessionIndex as described in 'Textual Conventions for SMIv2'. For an RTP system that supports the creation of rows, the network manager would read the object, and then write the value back in the Set that creates a new instance of rtpSessionEntry. If the Set fails with the code 'inconsistentValue,' then the process must be repeated; If the Set succeeds, then the object is incremented, and the new instance is created according to the manager's directions. However, if the RTP agent is not acting as a monitor, only the RTP agent may create conceptual rows in the RTP session table." ::= { rtpMIBObjects 1 } -- -- SESSION INVERSE TABLE -- rtpSessionInverseTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSessionInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maps rtpSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr TAddress pairs to one or more rtpSessionIndex values, each describing a row in the rtpSessionTable. This makes it possible to retrieve the row(s) in the rtpSessionTable corresponding to a given session without having to walk the entire (potentially large) table." ::= { rtpMIBObjects 2 } rtpSessionInverseEntry OBJECT-TYPE SYNTAX RtpSessionInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to exactly one entry in the rtpSessionTable - the entry containing the tuple, rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr and rtpSessionIndex." INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr, rtpSessionIndex } ::= { rtpSessionInverseTable 1 } Baugher, et al. Standards Track [Page 7] RFC 2959 RTP MIB October 2000 RtpSessionInverseEntry ::= SEQUENCE { rtpSessionInverseStartTime TimeStamp } rtpSessionInverseStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpSessionInverseEntry 1 } -- -- SESSION TABLE -- rtpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There's one entry in rtpSessionTable for each RTP session on which packets are being sent, received, and/or monitored." ::= { rtpMIBObjects 3 } rtpSessionEntry OBJECT-TYPE SYNTAX RtpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Data in rtpSessionTable uniquely identify an RTP session. A host RTP agent MUST create a read-only row for each session to which packets are being sent or received. Rows MUST be created by the RTP Agent at the start of a session when one or more senders or receivers are observed. Rows created by an RTP agent MUST be deleted when the session is over and there are no rtpRcvrEntry and no rtpSenderEntry for this session. An RTP session SHOULD be monitored to create management information on all RTP streams being sent or received when the rtpSessionMonitor has the TruthValue of 'true(1)'. An RTP monitor SHOULD permit row creation with the side effect of causing the RTP System to join the multicast session for the purposes of gathering management information (additional conceptual rows are created in the rtpRcvrTable and rtpSenderTable). Thus, rtpSessionTable rows SHOULD be created for RTP session monitoring purposes. Rows created by a management application SHOULD be deleted via SNMP operations by Baugher, et al. Standards Track [Page 8] RFC 2959 RTP MIB October 2000 management applications. Rows created by management operations are deleted by management operations by setting rtpSessionRowStatus to 'destroy(6)'." INDEX { rtpSessionIndex } ::= { rtpSessionTable 1 } RtpSessionEntry ::= SEQUENCE { rtpSessionIndex Integer32, rtpSessionDomain TDomain, rtpSessionRemAddr TAddress, rtpSessionLocAddr TAddress, rtpSessionIfIndex InterfaceIndex, rtpSessionSenderJoins Counter32, rtpSessionReceiverJoins Counter32, rtpSessionByes Counter32, rtpSessionStartTime TimeStamp, rtpSessionMonitor TruthValue, rtpSessionRowStatus RowStatus } rtpSessionIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the conceptual row which is for SNMP purposes only and has no relation to any protocol value. There is no requirement that these rows are created or maintained sequentially." ::= { rtpSessionEntry 1 } rtpSessionDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-create STATUS current DESCRIPTION "The transport-layer protocol used for sending or receiving the stream of RTP data packets on this session. Cannot be changed if rtpSessionRowStatus is 'active'." ::= { rtpSessionEntry 2 } rtpSessionRemAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The address to which RTP packets are sent by the RTP system. In an IP multicast RTP session, this is the single address used Baugher, et al. Standards Track [Page 9] RFC 2959 RTP MIB October 2000 by all senders and receivers of RTP session data. In a unicast RTP session this is the unicast address of the remote RTP system. 'The destination address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network address pairs.' See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 3. The transport service is identified by rtpSessionDomain. For snmpUDPDomain, this is an IP address and even-numbered UDP Port with the RTCP being sent on the next higher odd-numbered port, see RFC 1889, sec. 5." ::= { rtpSessionEntry 3 } rtpSessionLocAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The local address used by the RTP system. In an IP multicast RTP session, rtpSessionRemAddr will be the same IP multicast address as rtpSessionLocAddr. In a unicast RTP session, rtpSessionRemAddr and rtpSessionLocAddr will have different unicast addresses. See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 3. The transport service is identified by rtpSessionDomain. For snmpUDPDomain, this is an IP address and even-numbered UDP Port with the RTCP being sent on the next higher odd-numbered port, see RFC 1889, sec. 5." ::= { rtpSessionEntry 4 } rtpSessionIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value is set to the corresponding value from IF-MIB (See RFC 2233, 'The Interfaces Group MIB using SMIv2'). This is the interface that the RTP stream is being sent to or received from, or in the case of an RTP Monitor the interface that RTCP packets will be received on. Cannot be changed if rtpSessionRowStatus is 'active'." ::= { rtpSessionEntry 5 } rtpSessionSenderJoins OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of senders that have been observed to have joined the session since this conceptual row was created Baugher, et al. Standards Track [Page 10] RFC 2959 RTP MIB October 2000 (rtpSessionStartTime). A sender 'joins' an RTP session by sending to it. Senders that leave and then re-join following an RTCP BYE (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 6.6) or session timeout may be counted twice. Every time a new RTP sender is detected either using RTP or RTCP, this counter is incremented." ::= { rtpSessionEntry 6 } rtpSessionReceiverJoins OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of receivers that have been been observed to have joined this session since this conceptual row was created (rtpSessionStartTime). A receiver 'joins' an RTP session by sending RTCP Receiver Reports to the session. Receivers that leave and then re-join following an RTCP BYE (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 6.6) or session timeout may be counted twice." ::= { rtpSessionEntry 7 } rtpSessionByes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of RTCP BYE (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 6.6) messages received by this entity." ::= { rtpSessionEntry 8 } rtpSessionStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpSessionEntry 9 } rtpSessionMonitor OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Baugher, et al. Standards Track [Page 11] RFC 2959 RTP MIB October 2000 "Boolean, Set to 'true(1)' if remote senders or receivers in addition to the local RTP System are to be monitored using RTCP. RTP Monitors MUST initialize to 'true(1)' and RTP Hosts SHOULD initialize this 'false(2)'. Note that because 'host monitor' systems are receiving RTCP from their remote participants they MUST set this value to 'true(1)'." ::= { rtpSessionEntry 10 } rtpSessionRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Value of 'active' when RTP or RTCP messages are being sent or received by an RTP System. A newly-created conceptual row must have the all read-create objects initialized before becoming 'active'. A conceptual row that is in the 'notReady' or 'notInService' state MAY be removed after 5 minutes." ::= { rtpSessionEntry 11 } -- -- SENDER INVERSE TABLE -- rtpSenderInverseTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSenderInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maps rtpSenderAddr, rtpSessionIndex, to the rtpSenderSSRC index of the rtpSenderTable. This table allows management applications to find entries sorted by rtpSenderAddr rather than sorted by rtpSessionIndex. Given the rtpSessionDomain and rtpSenderAddr, a set of rtpSessionIndex and rtpSenderSSRC values can be returned from a tree walk. When rtpSessionIndex is specified in the SNMP Get-Next operations, one or more rtpSenderSSRC values may be returned." ::= { rtpMIBObjects 4 } rtpSenderInverseEntry OBJECT-TYPE SYNTAX RtpSenderInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to exactly one entry in the rtpSenderTable - the entry containing the index pair, rtpSessionIndex, rtpSenderSSRC." INDEX { rtpSessionDomain, rtpSenderAddr, rtpSessionIndex, Baugher, et al. Standards Track [Page 12] RFC 2959 RTP MIB October 2000 rtpSenderSSRC } ::= { rtpSenderInverseTable 1 } RtpSenderInverseEntry ::= SEQUENCE { rtpSenderInverseStartTime TimeStamp } rtpSenderInverseStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpSenderInverseEntry 1 } -- -- SENDERS TABLE -- rtpSenderTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSenderEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of information about a sender or senders to an RTP Session. RTP sending hosts MUST have an entry in this table for each stream being sent. RTP receiving hosts MAY have an entry in this table for each sending stream being received by this host. RTP monitors MUST create an entry for each observed sender to a multicast RTP Session as a side-effect when a conceptual row in the rtpSessionTable is made 'active' by a manager." ::= { rtpMIBObjects 5 } rtpSenderEntry OBJECT-TYPE SYNTAX RtpSenderEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information from a single RTP Sender Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport Protocol for Real-Time Applications' sec.6). The session is identified to the the SNMP entity by rtpSessionIndex. Rows are removed by the RTP agent when a BYE is received from the sender or when the sender times out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is deleted." INDEX { rtpSessionIndex, rtpSenderSSRC } ::= { rtpSenderTable 1 } Baugher, et al. Standards Track [Page 13] RFC 2959 RTP MIB October 2000 RtpSenderEntry ::= SEQUENCE { rtpSenderSSRC Unsigned32, rtpSenderCNAME Utf8String, rtpSenderAddr TAddress, rtpSenderPackets Counter64, rtpSenderOctets Counter64, rtpSenderTool Utf8String, rtpSenderSRs Counter32, rtpSenderSRTime TimeStamp, rtpSenderPT INTEGER, rtpSenderStartTime TimeStamp } rtpSenderSSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP session address plus an SSRC uniquely identify a sender to an RTP session (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.3)." ::= { rtpSenderEntry 1 } rtpSenderCNAME OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The RTP canonical name of the sender." ::= { rtpSenderEntry 2 } rtpSenderAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The unicast transport source address of the sender. In the case of an RTP Monitor this address is the address that the sender is using to send its RTCP Sender Reports." ::= { rtpSenderEntry 3 } rtpSenderPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of RTP packets sent by this sender, or observed by Baugher, et al. Standards Track [Page 14] RFC 2959 RTP MIB October 2000 an RTP monitor, since rtpSenderStartTime." ::= { rtpSenderEntry 4 } rtpSenderOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of non-header RTP octets sent by this sender, or observed by an RTP monitor, since rtpSenderStartTime." ::= { rtpSenderEntry 5 } rtpSenderTool OBJECT-TYPE SYNTAX Utf8String (SIZE(0..127)) MAX-ACCESS read-only STATUS current DESCRIPTION "Name of the application program source of the stream." ::= { rtpSenderEntry 6 } rtpSenderSRs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of RTCP Sender Reports that have been sent from this sender, or observed if the RTP entity is a monitor, since rtpSenderStartTime." ::= { rtpSenderEntry 7 } rtpSenderSRTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "rtpSenderSRTime is the value of SysUpTime at the time that the last SR was received from this sender, in the case of a monitor or receiving host. Or sent by this sender, in the case of a sending host." ::= { rtpSenderEntry 8 } rtpSenderPT OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload type from the RTP header of the most recently received RTP Packet (see RFC 1889, 'RTP: A Transport Protocol for Baugher, et al. Standards Track [Page 15] RFC 2959 RTP MIB October 2000 Real-Time Applications' sec. 5)." ::= { rtpSenderEntry 9 } rtpSenderStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpSenderEntry 10 } -- -- RECEIVER INVERSE TABLE -- rtpRcvrInverseTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpRcvrInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maps rtpRcvrAddr and rtpSessionIndex to the rtpRcvrSRCSSRC and rtpRcvrSSRC indexes of the rtpRcvrTable. This table allows management applications to find entries sorted by rtpRcvrAddr rather than by rtpSessionIndex. Given rtpSessionDomain and rtpRcvrAddr, a set of rtpSessionIndex, rtpRcvrSRCSSRC, and rtpRcvrSSRC values can be returned from a tree walk. When rtpSessionIndex is specified in SNMP Get-Next operations, one or more rtpRcvrSRCSSRC and rtpRcvrSSRC pairs may be returned." ::= { rtpMIBObjects 6 } rtpRcvrInverseEntry OBJECT-TYPE SYNTAX RtpRcvrInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to exactly one entry in the rtpRcvrTable - the entry containing the index pair, rtpSessionIndex, rtpRcvrSSRC." INDEX { rtpSessionDomain, rtpRcvrAddr, rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC } ::= { rtpRcvrInverseTable 1 } RtpRcvrInverseEntry ::= SEQUENCE { rtpRcvrInverseStartTime TimeStamp } rtpRcvrInverseStartTime OBJECT-TYPE SYNTAX TimeStamp Baugher, et al. Standards Track [Page 16] RFC 2959 RTP MIB October 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpRcvrInverseEntry 1 } -- -- RECEIVERS TABLE -- rtpRcvrTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpRcvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of information about a receiver or receivers of RTP session data. RTP hosts that receive RTP session packets MUST create an entry in this table for that receiver/sender pair. RTP hosts that send RTP session packets MAY create an entry in this table for each receiver to their stream using RTCP feedback from the RTP group. RTP monitors create an entry for each observed RTP session receiver as a side effect when a conceptual row in the rtpSessionTable is made 'active' by a manager." ::= { rtpMIBObjects 7 } rtpRcvrEntry OBJECT-TYPE SYNTAX RtpRcvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information from a single RTP Synchronization Source that is receiving packets from the sender identified by rtpRcvrSRCSSRC (SSRC, see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.6). The session is identified to the the RTP Agent entity by rtpSessionIndex. Rows are removed by the RTP agent when a BYE is received from the sender or when the sender times out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is deleted." INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC } ::= { rtpRcvrTable 1 } RtpRcvrEntry ::= SEQUENCE { rtpRcvrSRCSSRC Unsigned32, rtpRcvrSSRC Unsigned32, rtpRcvrCNAME Utf8String, rtpRcvrAddr TAddress, Baugher, et al. Standards Track [Page 17] RFC 2959 RTP MIB October 2000 rtpRcvrRTT Gauge32, rtpRcvrLostPackets Counter64, rtpRcvrJitter Gauge32, rtpRcvrTool Utf8String, rtpRcvrRRs Counter32, rtpRcvrRRTime TimeStamp, rtpRcvrPT INTEGER, rtpRcvrPackets Counter64, rtpRcvrOctets Counter64, rtpRcvrStartTime TimeStamp } rtpRcvrSRCSSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP session address plus an SSRC uniquely identify a sender or receiver of an RTP stream (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.3)." ::= { rtpRcvrEntry 1 } rtpRcvrSSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the receiver. The RTP session address plus an SSRC uniquely identify a receiver of an RTP stream (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.3)." ::= { rtpRcvrEntry 2 } rtpRcvrCNAME OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The RTP canonical name of the receiver." ::= { rtpRcvrEntry 3 } rtpRcvrAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION Baugher, et al. Standards Track [Page 18] RFC 2959 RTP MIB October 2000 "The unicast transport address on which the receiver is receiving RTP packets and/or RTCP Receiver Reports." ::= { rtpRcvrEntry 4 } rtpRcvrRTT OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The round trip time measurement taken by the source of the RTP stream based on the algorithm described on sec. 6 of RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications.' This algorithm can produce meaningful results when the RTP agent has the same clock as the stream sender (when the RTP monitor is also the sending host for the particular receiver). Otherwise, the entity should return 'noSuchInstance' in response to queries against rtpRcvrRTT." ::= { rtpRcvrEntry 5 } rtpRcvrLostPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of RTP packets lost as observed by this receiver since rtpRcvrStartTime." ::= { rtpRcvrEntry 6 } rtpRcvrJitter OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of delay variation as observed by this receiver. (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.6.3.1 and A.8)." ::= { rtpRcvrEntry 7 } rtpRcvrTool OBJECT-TYPE SYNTAX Utf8String (SIZE(0..127)) MAX-ACCESS read-only STATUS current DESCRIPTION "Name of the application program source of the stream." ::= { rtpRcvrEntry 8 } rtpRcvrRRs OBJECT-TYPE SYNTAX Counter32 Baugher, et al. Standards Track [Page 19] RFC 2959 RTP MIB October 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of RTCP Receiver Reports that have been sent from this receiver, or observed if the RTP entity is a monitor, since rtpRcvrStartTime." ::= { rtpRcvrEntry 9 } rtpRcvrRRTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "rtpRcvrRRTime is the value of SysUpTime at the time that the last RTCP Receiver Report was received from this receiver, in the case of a monitor or RR receiver (the RTP Sender). It is the value of SysUpTime at the time that the last RR was sent by this receiver in the case of an RTP receiver sending the RR." ::= { rtpRcvrEntry 10 } rtpRcvrPT OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Static or dynamic payload type from the RTP header (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec. 5)." ::= { rtpRcvrEntry 11 } rtpRcvrPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of RTP packets received by this RTP host receiver since rtpRcvrStartTime." ::= { rtpRcvrEntry 12 } rtpRcvrOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of non-header RTP octets received by this receiving RTP host since rtpRcvrStartTime." ::= { rtpRcvrEntry 13 } Baugher, et al. Standards Track [Page 20] RFC 2959 RTP MIB October 2000 rtpRcvrStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpRcvrEntry 14 } -- -- MODULE GROUPS -- -- -- There are two types of RTP Systems, RTP hosts and RTP Monitors. -- Thus there are three kinds of objects: 1) Objects common to both -- kinds of systems, 2) Objects unique to RTP Hosts and 3) Objects -- unique to RTP Monitors. There is a fourth group, 4) Objects that -- SHOULD be implemented by Multicast hosts and RTP Monitors rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 } rtpSystemGroup OBJECT-GROUP OBJECTS { rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionSenderJoins, rtpSessionReceiverJoins, rtpSessionStartTime, rtpSessionByes, rtpSessionMonitor, rtpSenderCNAME, rtpSenderAddr, rtpSenderPackets, rtpSenderOctets, rtpSenderTool, rtpSenderSRs, rtpSenderSRTime, rtpSenderStartTime, rtpRcvrCNAME, rtpRcvrAddr, rtpRcvrLostPackets, rtpRcvrJitter, rtpRcvrTool, rtpRcvrRRs, rtpRcvrRRTime, rtpRcvrStartTime } STATUS current Baugher, et al. Standards Track [Page 21] RFC 2959 RTP MIB October 2000 DESCRIPTION "Objects available to all RTP Systems." ::= { rtpGroups 1 } rtpHostGroup OBJECT-GROUP OBJECTS { rtpSessionLocAddr, rtpSenderPT, rtpRcvrPT, rtpRcvrRTT, rtpRcvrOctets, rtpRcvrPackets } STATUS current DESCRIPTION "Objects that are available to RTP Host systems, but may not be available to RTP Monitor systems." ::= { rtpGroups 2 } rtpMonitorGroup OBJECT-GROUP OBJECTS { rtpSessionNewIndex, rtpSessionRowStatus } STATUS current DESCRIPTION "Objects used to create rows in the RTP Session Table. These objects are not needed if the system does not create rows." ::= { rtpGroups 3 } rtpInverseGroup OBJECT-GROUP OBJECTS { rtpSessionInverseStartTime, rtpSenderInverseStartTime, rtpRcvrInverseStartTime } STATUS current DESCRIPTION "Objects used in the Inverse Lookup Tables." ::= { rtpGroups 4 } -- -- Compliance -- rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 } rtpHostCompliance MODULE-COMPLIANCE STATUS current Baugher, et al. Standards Track [Page 22] RFC 2959 RTP MIB October 2000 DESCRIPTION "Host implementations MUST comply." MODULE RTP-MIB MANDATORY-GROUPS { rtpSystemGroup, rtpHostGroup } GROUP rtpMonitorGroup DESCRIPTION "Host systems my optionally support row creation and deletion. This would allow an RTP Host system to act as an RTP Monitor." GROUP rtpInverseGroup DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpSessionNewIndex MIN-ACCESS not-accessible DESCRIPTION "RTP system implementations support of row creation and deletion is OPTIONAL so implementation of this object is OPTIONAL." OBJECT rtpSessionDomain MIN-ACCESS read-only DESCRIPTION "RTP system implementation support of row creation and deletion is OPTIONAL. When it is not supported so write access is OPTIONAL." OBJECT rtpSessionRemAddr MIN-ACCESS read-only DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionIfIndex MIN-ACCESS read-only DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionRowStatus MIN-ACCESS not-accessible DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." Baugher, et al. Standards Track [Page 23] RFC 2959 RTP MIB October 2000 OBJECT rtpSenderInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpRcvrInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." ::= { rtpCompliances 1 } rtpMonitorCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Monitor implementations must comply. RTP Monitors are not required to support creation or deletion." MODULE RTP-MIB MANDATORY-GROUPS { rtpSystemGroup, rtpMonitorGroup } GROUP rtpHostGroup DESCRIPTION "Monitor implementations may not have access to values in the rtpHostGroup." GROUP rtpInverseGroup DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpSessionLocAddr MIN-ACCESS not-accessible DESCRIPTION "RTP monitor sourcing of RTP or RTCP data packets is OPTIONAL and implementation of this object is OPTIONAL." OBJECT rtpRcvrPT MIN-ACCESS not-accessible DESCRIPTION "RTP monitor systems may not support retrieval of the RTP Payload Type from the RTP header (and may receive RTCP messages only). When queried for the payload type information" OBJECT rtpSenderPT MIN-ACCESS not-accessible DESCRIPTION "RTP monitor systems may not support retrieval of the RTP Payload Type from the RTP Baugher, et al. Standards Track [Page 24] RFC 2959 RTP MIB October 2000 header (and may receive RTCP messages only). When queried for the payload type information." OBJECT rtpRcvrOctets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor systems may receive only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL" OBJECT rtpRcvrPackets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor systems may receive only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL." OBJECT rtpSessionIfIndex MIN-ACCESS read-only DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpSenderInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpRcvrInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." ::= { rtpCompliances 2 } END Baugher, et al. Standards Track [Page 25] RFC 2959 RTP MIB October 2000 4. Security Considerations In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. However, there are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. None of the read-only objects in this MIB reports a password, though some SDES [RFC1889] items such as the CNAME [RFC1889], the canonical name, may be deemed sensitive depending on the security policies of a particular enterprise. If access to these objects is not limited by an appropriate access control policy, these objects can provide an attacker with information about a system's configuration and the services that that system is providing. Some enterprises view their network and system configurations, as well as information about usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. This MIB supports read-write operations against rtpSessionNewIndex which has the side effect of creating an entry in the rtpSessionTable when it is written to. Five objects in rtpSessionEntry have read-create access: rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionRowStatus, and rtpSessionIfAddr identify an RTP session to be monitored on a particular interface. The values of these objects are not to be changed once created, and initialization of these objects affects only the monitoring of an RTP session and not the operation of an RTP session on any host end-system. Since write operations to rtpSessionNewIndex and the five objects in rtpSessionEntry affect the operation of the monitor, write access to these objects should be subject to the appropriate access control policy. Confidentiality of RTP and RTCP data packets is defined in section 9 of the RTP specification [RFC1889]. Encryption may be performed on RTP packets, RTCP packets, or both. Encryption of RTCP packets may pose a problem for third-party monitors though "For RTCP, it is allowed to split a compound RTCP packet into two lower-layer packets, one to be encrypted and one to be sent in the clear. For example, SDES information might be encrypted while reception reports were sent in the clear to accommodate third-party monitors [RFC1889]." SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET Baugher, et al. Standards Track [Page 26] RFC 2959 RTP MIB October 2000 (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View-based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 5. Acknowledgements The authors wish to thank Bert Wijnen and the participants from the ITU SG-16 management effort for their helpful comments. Alan Batie and Bill Lewis from Intel also contributed greatly to the RTP MIB through their review of various drafts of the MIB and their work on the implementation of an SNMP RTP Monitor. Stan Naudus from 3Com and John Du from Intel contributed to the original RTP MIB design and co-authored the original RTP MIB draft documents; much of their work remains in the current RTP MIB. Bill Fenner provided solid feedback that improved the quality of the final document. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Baugher, et al. Standards Track [Page 27] RFC 2959 RTP MIB October 2000 7. References [RFC1889] Shulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889, January 1996. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. Baugher, et al. Standards Track [Page 28] RFC 2959 RTP MIB October 2000 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. Baugher, et al. Standards Track [Page 29] RFC 2959 RTP MIB October 2000 8. Authors' Addresses Mark Baugher Intel Corporation 2111 N.E.25th Avenue Hillsboro, Oregon 97124 U.S.A. EMail: mbaugher@passedge.com Bill Strahm Intel Corporation 2111 N.E.25th Avenue Hillsboro, Oregon 97124 U.S.A. EMail: Bill.Strahm@intel.com Irina Suconick Ennovate Networks 60 Codman Hill Rd., Boxboro, Ma 01719 U.S.A. EMail: irina@ennovatenetworks.com Baugher, et al. Standards Track [Page 30] RFC 2959 RTP MIB October 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Baugher, et al. Standards Track [Page 31] snmp-mibs-downloader-1.1/mibrfcs/rfc2981.txt0000644000000000000000000027771011402176071015603 0ustar Network Working Group R. Kavasseri Request for Comments: 2981 (Editor of this version) Category: Standards Track B. Stewart (Author of previous version) Cisco Systems, Inc. October 2000 Event MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 3 Relationship to Other MIBs .................................. 3 4 MIB Sections ................................................ 4 5 Operation ................................................... 5 6 Security .................................................... 7 7 Definitions ................................................. 7 8 Intellectual Property ....................................... 47 9 Acknowledgements ............................................ 47 Kavasseri & Stewart Standards Track [Page 1] RFC 2981 Event MIB October 2000 10 References ................................................. 47 11 Security Considerations .................................... 49 12 Author's Address ........................................... 49 13 Editor's Address ........................................... 49 14 Full Copyright Statement ................................... 50 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Kavasseri & Stewart Standards Track [Page 2] RFC 2981 Event MIB October 2000 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. It may not be possible to meaningfully monitor Counter64 objects using an SMIv1 version of the MIB. 2. Overview With network sizes well beyond the ability of people to manage them directly, automated, distributed management is vital. An important aspect of such management is the ability of a system to monitor itself or for some other system to monitor it. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. The MIB is intended to suit either a relatively powerful manager or mid- level manager, as well as a somewhat more limited self-managing system. 3. Relationship to Other MIBs The Event MIB is based on extensive experience with the RMON MIB [RFC1757] and provides a superset of the capabilities of the RMON alarm and event groups. Conceptually, the key extension is the ability to allow alarms to be generated for MIB objects that are on another network element. The Event MIB calls "triggers" what the RMON MIB called "alarms," but the concepts are the same. Event MIB triggers maintain the RMON handling of thresholds and add the concept of booleans. Event MIB events maintain the RMON concept of sending an SNMP notification in response to a trigger and add the concept of setting a MIB object. The Event MIB is the successor and update to SNMPv2's Manager-to- Manager MIB [RFC1451] which was declared Historic pending this work. The Event MIB depends on the services of the SNMPv3 Management Target and Notification MIBs [RFC2573]. The Event MIB is nicely complemented by the Distributed Management Expression MIB [RFC2982], which is the expected source of boolean objects to monitor. Note that there is considerable overlap between Kavasseri & Stewart Standards Track [Page 3] RFC 2981 Event MIB October 2000 the wildcard and delta sample capabilities of the Event and Expression MIBs. A carefully-planned implementation might well use common code to provide the overlapping functions. 4. MIB Sections The MIB has four sections: triggers, objects, events, and notifications. Triggers define the conditions that lead to events. Events may cause notifications. The trigger table lists what objects are to be monitored and how and relates each trigger to an event. It has supplementary, companion tables for additional objects that depend on the type of test done for the trigger. The objects table lists objects that can be added to notifications based on the trigger, the trigger test type, or the event that resulted in the notification. The event table defines what happens when an event is triggered: sending a notification, setting a MIB object or both. It has supplementary, companion tables for additional objects that depend on the action taken. The notification section defines a set of generic notifications to go with the events and for Event MIB error handling, and it defines a set of objects to put in those notifications. The following diagram describes the relationships between the tables in the Event MIB. Kavasseri & Stewart Standards Track [Page 4] RFC 2981 Event MIB October 2000 +-----------------------------+ | mteTriggerEntry | subclassed by: | { mteOwner, |---+ | IMPLIED mteTriggerName } | +-- mteTriggerDeltaEntry | | | | | +-- mteTriggerExistenceEntry | | | | | +-- mteTriggerBooleanEntry | | | | | +-- mteTriggerThresholdEntry | | | mteTrigger*Event -------------------------------->+ | | | | mteTriggerObjects ------------------>+ | +-----------------------------+ | | | | +-----------------------------+ V | | mteObjectsEntry | | | | { mteOwner, |<-------------+ | | mteObjectsName, | | | mteObjectsIndex } | | +-----------------------------+ | V +---------------------------+ | | mteEventEntry |<----------------------------+ | { mteOwner, | | IMPLIED mteEventName } | | | | mteEventAction---> + (condition) +---------------------------+ | V +---------------------------+ | +---------------------------+ | mteEventNotificationEntry | | | mteEventSetEntry | | { mteOwner, |<--+-->| { mteOwner, | | IMPLIED mteEventName } | | IMPLIED mteEventName } | +---------------------------+ +---------------------------+ 5. Operation The Event MIB is instrumentation for a distributed management application that monitors MIB objects. In its simplest form this application monitors individual, local MIB objects, just as an RMON probe fulfills the functions implied by RMON's alarm and event operation. Additionally the application can monitor remote objects and wildcarded groups of objects. Kavasseri & Stewart Standards Track [Page 5] RFC 2981 Event MIB October 2000 Remote monitoring uses the tag service of the Management Target MIB [RFC2573] to select and access remote systems as an ordinary SNMP- based management application. Local monitoring may be via a more intimate, local interface which may, for example, bypass SNMP encoding but otherwise is functionally identical to remote SNMP operation, including the application of access control. A self- management only system MAY not implement remote monitoring. Wildcards indicate that the application SHOULD use a GetNext-type operation to find the zero or more instances implied by a truncated object identifier, just like an ordinary SNMP-based management application. Each instance of a wildcard is treated as if it were a separate entry, that is the instances of a wildcarded object are independent of one another. For example, a wild-carded object may trigger an event, and result in the setting of another wildcarded object. The instance that satisfied the trigger function is used to perform the set function. All of this takes place independently of any additional instances that may fill the wildcard. Error handling is by notification. These error notifications SHOULD be enabled only for the diagnosis of problems indicated by error counters. If minimizing the probability of notification loss is a concern they SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET-MIB] or directed to a log as described in the Notification Log MIB [rfcNotificationLogMIB]. Note that this does not mean the Notification Log MIB is REQUIRED, since in fact notifications usually are not lost, but that the Notification Log MIB can be helpful with this as well as other MIBs that include notifications. Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring events, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation-specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. Kavasseri & Stewart Standards Track [Page 6] RFC 2981 Event MIB October 2000 6. Security Security of Event MIB entries depends on SNMPv3 access control for the entire MIB or for subsets based on entry owner names. Security of monitored objects for remote access depends on the Management Target MIB [RFC2573]. Security for local access can depend on the Management Target MIB or on recording appropriate security credentials of the creator of an entry and using those to access the local objects. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When accessing local objects without using a local target tag, the system MUST (conceptually) use isAccessAllowed to ensure that it does not violate security. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. If a security administrator were to employ such an approach, all entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same sub-identifiers (except for the "column" sub-identifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column sub-identifier. More elaborate configurations are possible. 7. Definitions DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, NOTIFICATION-TYPE, Counter32, Gauge32, mib-2, zeroDotZero FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC Kavasseri & Stewart Standards Track [Page 7] RFC 2981 Event MIB October 2000 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF sysUpTime FROM SNMPv2-MIB SnmpTagValue FROM SNMP-TARGET-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; dismanEventMIB MODULE-IDENTITY LAST-UPDATED "200010160000Z" -- 16 October 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: ramk@cisco.com" DESCRIPTION "The MIB module for defining event triggers and actions for network management purposes." -- Revision History REVISION "200010160000Z" -- 16 October 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC 2981" ::= { mib-2 88 } dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 } -- Management Triggered Event (MTE) objects mteResource OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 } mteTrigger OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 } mteObjects OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 } mteEvent OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 } -- -- Textual Conventions -- FailureReason ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Reasons for failures in an attempt to perform a management request. The first group of errors, numbered less than 0, are related to problems in sending the request. The existence of a particular error code here does not imply that all implementations are capable of sensing that error and Kavasseri & Stewart Standards Track [Page 8] RFC 2981 Event MIB October 2000 returning that code. The second group, numbered greater than 0, are copied directly from SNMP protocol operations and are intended to carry exactly the meanings defined for the protocol as returned in an SNMP response. localResourceLack some local resource such as memory lacking or mteResourceSampleInstanceMaximum exceeded badDestination unrecognized domain name or otherwise invalid destination address destinationUnreachable can't get to destination address noResponse no response to SNMP request badType the data syntax of a retrieved object as not as expected sampleOverrun another sample attempt occurred before the previous one completed" SYNTAX INTEGER { localResourceLack(-1), badDestination(-2), destinationUnreachable(-3), noResponse(-4), badType(-5), sampleOverrun(-6), noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) } -- Kavasseri & Stewart Standards Track [Page 9] RFC 2981 Event MIB October 2000 -- Resource Control Section -- mteResourceSampleMinimum OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum mteTriggerFrequency this system will accept. A system may use the larger values of this minimum to lessen the impact of constant sampling. For larger sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all triggers created after it is set. Unless explicitly resource limited, a system's value for this object SHOULD be 1, allowing as small as a 1 second interval for ongoing trigger sampling. Changing this value will not invalidate an existing setting of mteTriggerFrequency." ::= { mteResource 1 } mteResourceSampleInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of instance entries this system will support for sampling. These are the entries that maintain state, one for each instance of each sampled object as selected by mteTriggerValueID. Note that wildcarded objects result in multiple instances of this state. A value of 0 indicates no preset limit, that is, the limit is dynamic based on system operation and resources. Unless explicitly resource limited, a system's value for this object SHOULD be 0. Changing this value will not eliminate or inhibit existing sample state but could prevent allocation of additional state information." Kavasseri & Stewart Standards Track [Page 10] RFC 2981 Event MIB October 2000 ::= { mteResource 2 } mteResourceSampleInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for mteResourceSampleInstanceMaximum." ::= { mteResource 3 } mteResourceSampleInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of mteResourceSampleInstances that has occurred since initialization of the management system." ::= { mteResource 4 } mteResourceSampleInstanceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this system could not take a new sample because that allocation would have exceeded the limit set by mteResourceSampleInstanceMaximum." ::= { mteResource 5 } -- -- Trigger Section -- -- Counters mteTriggerFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failures" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to check for a trigger condition has failed. This counts individually for each attempt in a group of targets or each attempt for a Kavasseri & Stewart Standards Track [Page 11] RFC 2981 Event MIB October 2000 wildcarded object." ::= { mteTrigger 1 } -- -- Trigger Table -- mteTriggerTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information." ::= { mteTrigger 2 } mteTriggerEntry OBJECT-TYPE SYNTAX MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger. Applications create and delete entries using mteTriggerEntryStatus." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerTable 1 } MteTriggerEntry ::= SEQUENCE { mteOwner SnmpAdminString, mteTriggerName SnmpAdminString, mteTriggerComment SnmpAdminString, mteTriggerTest BITS, mteTriggerSampleType INTEGER, mteTriggerValueID OBJECT IDENTIFIER, mteTriggerValueIDWildcard TruthValue, mteTriggerTargetTag SnmpTagValue, mteTriggerContextName SnmpAdminString, mteTriggerContextNameWildcard TruthValue, mteTriggerFrequency Unsigned32, mteTriggerObjectsOwner SnmpAdminString, mteTriggerObjects SnmpAdminString, mteTriggerEnabled TruthValue, mteTriggerEntryStatus RowStatus } mteOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Kavasseri & Stewart Standards Track [Page 12] RFC 2981 Event MIB October 2000 "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { mteTriggerEntry 1 } mteTriggerName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the trigger within the scope of mteOwner." ::= { mteTriggerEntry 2 } mteTriggerComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the trigger's function and use." DEFVAL { ''H } ::= { mteTriggerEntry 3 } mteTriggerTest OBJECT-TYPE SYNTAX BITS { existence(0), boolean(1), threshold(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of trigger test to perform. For 'boolean' and 'threshold' tests, the object at mteTriggerValueID MUST evaluate to an integer, that is, anything that ends up encoded for transmission (that is, in BER, not ASN.1) as an integer. For 'existence', the specific test is as selected by mteTriggerExistenceTest. When an object appears, vanishes or changes value, the trigger fires. If the object's appearance caused the trigger firing, the object MUST vanish before the trigger can be fired again for it, and vice versa. If the trigger fired due to a change in the object's value, it will be fired again on every successive value change for that object. For 'boolean', the specific test is as selected by mteTriggerBooleanTest. If the test result is true the trigger fires. The trigger will not fire again until the value has become false and come back to true. For 'threshold' the test works as described below for Kavasseri & Stewart Standards Track [Page 13] RFC 2981 Event MIB October 2000 mteTriggerThresholdStartup, mteTriggerThresholdRising, and mteTriggerThresholdFalling. Note that combining 'boolean' and 'threshold' tests on the same object may be somewhat redundant." DEFVAL { { boolean } } ::= { mteTriggerEntry 4 } mteTriggerSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of sampling to perform. An 'absoluteValue' sample requires only a single sample to be meaningful, and is exactly the value of the object at mteTriggerValueID at the sample time. A 'deltaValue' requires two samples to be meaningful and is thus not available for testing until the second and subsequent samples after the object at mteTriggerValueID is first found to exist. It is the difference between the two samples. For unsigned values it is always positive, based on unsigned arithmetic. For signed values it can be positive or negative. For SNMP counters to be meaningful they should be sampled as a 'deltaValue'. For 'deltaValue' mteTriggerDeltaTable contains further parameters. If only 'existence' is set in mteTriggerTest this object has no meaning." DEFVAL { absoluteValue } ::= { mteTriggerEntry 5 } mteTriggerValueID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the MIB object to sample to see if the trigger should fire. This may be wildcarded by truncating all or part of the instance portion, in which case the value is obtained as if with a GetNext function, checking multiple values Kavasseri & Stewart Standards Track [Page 14] RFC 2981 Event MIB October 2000 if they exist. If such wildcarding is applied, mteTriggerValueIDWildcard must be 'true' and if not it must be 'false'. Bad object identifiers or a mismatch between truncating the identifier and the value of mteTriggerValueIDWildcard result in operation as one would expect when providing the wrong identifier to a Get or GetNext operation. The Get will fail or get the wrong object. The GetNext will indeed get whatever is next, proceeding until it runs past the initial part of the identifier and perhaps many unintended objects for confusing results. If the value syntax of those objects is not usable, that results in a 'badType' error that terminates the scan. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteTriggerEntry 6 } mteTriggerValueIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerValueID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 7 } mteTriggerTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "The tag for the target(s) from which to obtain the condition for a trigger check. A length of 0 indicates the local system. In this case, access to the objects indicated by mteTriggerValueID is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security Kavasseri & Stewart Standards Track [Page 15] RFC 2981 Event MIB October 2000 parameters resulting from the tag." DEFVAL { ''H } ::= { mteTriggerEntry 8 } mteTriggerContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The management context from which to obtain mteTriggerValueID. This may be wildcarded by leaving characters off the end. For example use 'Repeater' to wildcard to 'Repeater1', 'Repeater2', 'Repeater-999.87b', and so on. To indicate such wildcarding is intended, mteTriggerContextNameWildcard must be 'true'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Operation of this feature assumes that the local system has a list of available contexts against which to apply the wildcard. If the objects are being read from the local system, this is clearly the system's own list of contexts. For a remote system a local version of such a list is not defined by any current standard and may not be available, so this function MAY not be supported." DEFVAL { ''H } ::= { mteTriggerEntry 9 } mteTriggerContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 10 } mteTriggerFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current Kavasseri & Stewart Standards Track [Page 16] RFC 2981 Event MIB October 2000 DESCRIPTION "The number of seconds to wait between trigger samples. To encourage consistency in sampling, the interval is measured from the beginning of one check to the beginning of the next and the timer is restarted immediately when it expires, not when the check completes. If the next sample begins before the previous one completed the system may either attempt to make the check or treat this as an error condition with the error 'sampleOverrun'. A frequency of 0 indicates instantaneous recognition of the condition. This is not possible in many cases, but may be supported in cases where it makes sense and the system is able to do so. This feature allows the MIB to be used in implementations where such interrupt-driven behavior is possible and is not likely to be supported for all MIB objects even then since such sampling generally has to be tightly integrated into low-level code. Systems that can support this SHOULD document those cases where it can be used. In cases where it can not, setting this object to 0 should be disallowed." DEFVAL { 600 } ::= { mteTriggerEntry 11 } mteTriggerObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "To go with mteTriggerObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerEntry 12 } mteTriggerObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger. A list of objects may also be added based on the event or on the value of mteTriggerTest. Kavasseri & Stewart Standards Track [Page 17] RFC 2981 Event MIB October 2000 A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerEntry 13 } mteTriggerEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow a trigger to be configured but not used. When the value is 'false' the trigger is not sampled." DEFVAL { false } ::= { mteTriggerEntry 14 } mteTriggerEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry may not be modified except to delete it." ::= { mteTriggerEntry 15 } -- -- Trigger Delta Table -- mteTriggerDeltaTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for delta sampling." ::= { mteTrigger 3 } mteTriggerDeltaEntry OBJECT-TYPE SYNTAX MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger's delta sampling. Entries automatically exist in this this table for each mteTriggerEntry that has mteTriggerSampleType set to 'deltaValue'." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerDeltaTable 1 } Kavasseri & Stewart Standards Track [Page 18] RFC 2981 Event MIB October 2000 MteTriggerDeltaEntry ::= SEQUENCE { mteTriggerDeltaDiscontinuityID OBJECT IDENTIFIER, mteTriggerDeltaDiscontinuityIDWildcard TruthValue, mteTriggerDeltaDiscontinuityIDType INTEGER } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } mteTriggerDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at mteTriggerValueID. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match mteTriggerValueID. This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking MUST still check sysUpTime for an overall discontinuity. If the object identified is not accessible the sample attempt is in error, with the error code as from an SNMP request. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the value syntax of those objects is not usable, that results in an error that terminates the sample with a 'badType' error code." DEFVAL { sysUpTimeInstance } ::= { mteTriggerDeltaEntry 1 } mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteTriggerDeltaDiscontinuityID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard. Note that the value of this object will be the same as that of the corresponding instance of mteTriggerValueIDWildcard when the corresponding Kavasseri & Stewart Standards Track [Page 19] RFC 2981 Event MIB October 2000 mteTriggerSampleType is 'deltaValue'." DEFVAL { false } ::= { mteTriggerDeltaEntry 2 } mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value 'timeTicks' indicates the mteTriggerDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime' indicates syntax DateAndTime." DEFVAL { timeTicks } ::= { mteTriggerDeltaEntry 3 } -- -- Trigger Existence Table -- mteTriggerExistenceTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for existence triggers." ::= { mteTrigger 4 } mteTriggerExistenceEntry OBJECT-TYPE SYNTAX MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single existence trigger. Entries automatically exist in this this table for each mteTriggerEntry that has 'existence' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerExistenceTable 1 } MteTriggerExistenceEntry ::= SEQUENCE { mteTriggerExistenceTest BITS, mteTriggerExistenceStartup BITS, mteTriggerExistenceObjectsOwner SnmpAdminString, mteTriggerExistenceObjects SnmpAdminString, mteTriggerExistenceEventOwner SnmpAdminString, mteTriggerExistenceEvent SnmpAdminString } Kavasseri & Stewart Standards Track [Page 20] RFC 2981 Event MIB October 2000 mteTriggerExistenceTest OBJECT-TYPE SYNTAX BITS { present(0), absent(1), changed(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of existence test to perform. The trigger fires when the object at mteTriggerValueID is seen to go from present to absent, from absent to present, or to have it's value changed, depending on which tests are selected: present(0) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from absent to present. absent(1) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from present to absent. changed(2) - when this test is selected, the trigger fires the mteTriggerValueID object value changes. Once the trigger has fired for either presence or absence it will not fire again for that state until the object has been to the other state. " DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 1 } mteTriggerExistenceStartup OBJECT-TYPE SYNTAX BITS { present(0), absent(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' and the test specified by mteTriggerExistenceTest is true. Setting an option causes that trigger to fire when its test is true." DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 2 } mteTriggerExistenceObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 3 } mteTriggerExistenceObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) Kavasseri & Stewart Standards Track [Page 21] RFC 2981 Event MIB October 2000 MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 4 } mteTriggerExistenceEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceEvent, the mteOwner of an event entry from the mteEventTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 5 } mteTriggerExistenceEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'existence' and this trigger fires. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 6 } -- -- Trigger Boolean Table -- mteTriggerBooleanTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for boolean triggers." ::= { mteTrigger 5 } Kavasseri & Stewart Standards Track [Page 22] RFC 2981 Event MIB October 2000 mteTriggerBooleanEntry OBJECT-TYPE SYNTAX MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single boolean trigger. Entries automatically exist in this this table for each mteTriggerEntry that has 'boolean' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerBooleanTable 1 } MteTriggerBooleanEntry ::= SEQUENCE { mteTriggerBooleanComparison INTEGER, mteTriggerBooleanValue Integer32, mteTriggerBooleanStartup TruthValue, mteTriggerBooleanObjectsOwner SnmpAdminString, mteTriggerBooleanObjects SnmpAdminString, mteTriggerBooleanEventOwner SnmpAdminString, mteTriggerBooleanEvent SnmpAdminString } mteTriggerBooleanComparison OBJECT-TYPE SYNTAX INTEGER { unequal(1), equal(2), less(3), lessOrEqual(4), greater(5), greaterOrEqual(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of boolean comparison to perform. The value at mteTriggerValueID is compared to mteTriggerBooleanValue, so for example if mteTriggerBooleanComparison is 'less' the result would be true if the value at mteTriggerValueID is less than the value of mteTriggerBooleanValue." DEFVAL { unequal } ::= { mteTriggerBooleanEntry 1 } mteTriggerBooleanValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to use for the test specified by mteTriggerBooleanTest." DEFVAL { 0 } ::= { mteTriggerBooleanEntry 2 } Kavasseri & Stewart Standards Track [Page 23] RFC 2981 Event MIB October 2000 mteTriggerBooleanStartup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' or a new instance of the object at mteTriggerValueID is found and the test specified by mteTriggerBooleanComparison is true. In that case an event is triggered if mteTriggerBooleanStartup is 'true'." DEFVAL { true } ::= { mteTriggerBooleanEntry 3 } mteTriggerBooleanObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 4 } mteTriggerBooleanObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 5 } mteTriggerBooleanEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } Kavasseri & Stewart Standards Track [Page 24] RFC 2981 Event MIB October 2000 ::= { mteTriggerBooleanEntry 6 } mteTriggerBooleanEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'boolean' and this trigger fires. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 7 } -- -- Trigger Threshold Table -- mteTriggerThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for threshold triggers." ::= { mteTrigger 6 } mteTriggerThresholdEntry OBJECT-TYPE SYNTAX MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single threshold trigger. Entries automatically exist in this table for each mteTriggerEntry that has 'threshold' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerThresholdTable 1 } MteTriggerThresholdEntry ::= SEQUENCE { mteTriggerThresholdStartup INTEGER, mteTriggerThresholdRising Integer32, mteTriggerThresholdFalling Integer32, mteTriggerThresholdDeltaRising Integer32, mteTriggerThresholdDeltaFalling Integer32, mteTriggerThresholdObjectsOwner SnmpAdminString, mteTriggerThresholdObjects SnmpAdminString, mteTriggerThresholdRisingEventOwner SnmpAdminString, mteTriggerThresholdRisingEvent SnmpAdminString, mteTriggerThresholdFallingEventOwner SnmpAdminString, Kavasseri & Stewart Standards Track [Page 25] RFC 2981 Event MIB October 2000 mteTriggerThresholdFallingEvent SnmpAdminString, mteTriggerThresholdDeltaRisingEventOwner SnmpAdminString, mteTriggerThresholdDeltaRisingEvent SnmpAdminString, mteTriggerThresholdDeltaFallingEventOwner SnmpAdminString, mteTriggerThresholdDeltaFallingEvent SnmpAdminString } mteTriggerThresholdStartup OBJECT-TYPE SYNTAX INTEGER { rising(1), falling(2), risingOrFalling(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The event that may be triggered when this entry is first set to 'active' and a new instance of the object at mteTriggerValueID is found. If the first sample after this instance becomes active is greater than or equal to mteTriggerThresholdRising and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling', then one mteTriggerThresholdRisingEvent is triggered for that instance. If the first sample after this entry becomes active is less than or equal to mteTriggerThresholdFalling and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling', then one mteTriggerThresholdRisingEvent is triggered for that instance." DEFVAL { risingOrFalling } ::= { mteTriggerThresholdEntry 1 } mteTriggerThresholdRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, one mteTriggerThresholdRisingEvent is triggered. That event is also triggered if the first sample after this entry becomes active is greater than or equal to this threshold and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling'. After a rising event is generated, another such event is not triggered until the sampled value falls below this threshold and reaches mteTriggerThresholdFalling." DEFVAL { 0 } Kavasseri & Stewart Standards Track [Page 26] RFC 2981 Event MIB October 2000 ::= { mteTriggerThresholdEntry 2 } mteTriggerThresholdFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, one mteTriggerThresholdFallingEvent is triggered. That event is also triggered if the first sample after this entry becomes active is less than or equal to this threshold and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling'. After a falling event is generated, another such event is not triggered until the sampled value rises above this threshold and reaches mteTriggerThresholdRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 3 } mteTriggerThresholdDeltaRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) is greater than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was less than this threshold, one mteTriggerThresholdDeltaRisingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) is the first sample taken of that instance, is greater than or equal to this threshold. After a rising event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaFalling." DEFVAL { 0 } Kavasseri & Stewart Standards Track [Page 27] RFC 2981 Event MIB October 2000 ::= { mteTriggerThresholdEntry 4 } mteTriggerThresholdDeltaFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) is less than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was greater than this threshold, one mteTriggerThresholdDeltaFallingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) is the first sample taken of that instance, is less than or equal to this threshold. After a falling event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 5 } mteTriggerThresholdObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 6 } mteTriggerThresholdObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall Kavasseri & Stewart Standards Track [Page 28] RFC 2981 Event MIB October 2000 trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 7 } mteTriggerThresholdRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdRisingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 8 } mteTriggerThresholdRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 9 } mteTriggerThresholdFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 10 } mteTriggerThresholdFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 11 } Kavasseri & Stewart Standards Track [Page 29] RFC 2981 Event MIB October 2000 mteTriggerThresholdDeltaRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaRisingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 12 } mteTriggerThresholdDeltaRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 13 } mteTriggerThresholdDeltaFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 14 } mteTriggerThresholdDeltaFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 15 } -- -- Objects Table -- Kavasseri & Stewart Standards Track [Page 30] RFC 2981 Event MIB October 2000 mteObjectsTable OBJECT-TYPE SYNTAX SEQUENCE OF MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that can be added to notifications based on the trigger, trigger test, or event, as pointed to by entries in those tables." ::= { mteObjects 1 } mteObjectsEntry OBJECT-TYPE SYNTAX MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A group of objects. Applications create and delete entries using mteObjectsEntryStatus. When adding objects to a notification they are added in the lexical order of their index in this table. Those associated with a trigger come first, then trigger test, then event." INDEX { mteOwner, mteObjectsName, mteObjectsIndex } ::= { mteObjectsTable 1 } MteObjectsEntry ::= SEQUENCE { mteObjectsName SnmpAdminString, mteObjectsIndex Unsigned32, mteObjectsID OBJECT IDENTIFIER, mteObjectsIDWildcard TruthValue, mteObjectsEntryStatus RowStatus } mteObjectsName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for a group of objects." ::= { mteObjectsEntry 1 } mteObjectsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer for the purpose of identifying individual objects within a mteObjectsName group. Kavasseri & Stewart Standards Track [Page 31] RFC 2981 Event MIB October 2000 Objects within a group are placed in the notification in the numerical order of this index. Groups are placed in the notification in the order of the selections for overall trigger, trigger test, and event. Within trigger test they are in the same order as the numerical values of the bits defined for mteTriggerTest. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the object is not available it is omitted from the notification." ::= { mteObjectsEntry 2 } mteObjectsID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of a MIB object to add to a Notification that results from the firing of a trigger. This may be wildcarded by truncating all or part of the instance portion, in which case the instance portion of the OID for obtaining this object will be the same as that used in obtaining the mteTriggerValueID that fired. If such wildcarding is applied, mteObjectsIDWildcard must be 'true' and if not it must be 'false'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteObjectsEntry 3 } mteObjectsIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteObjectsID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteObjectsEntry 4 } Kavasseri & Stewart Standards Track [Page 32] RFC 2981 Event MIB October 2000 mteObjectsEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to delete it." ::= { mteObjectsEntry 5 } -- -- Event Section -- -- Counters mteEventFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to invoke an event has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded trigger object." ::= { mteEvent 1 } -- -- Event Table -- mteEventTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 2 } mteEventEntry OBJECT-TYPE SYNTAX MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event. Applications create and delete entries using mteEventEntryStatus." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventTable 1 } Kavasseri & Stewart Standards Track [Page 33] RFC 2981 Event MIB October 2000 MteEventEntry ::= SEQUENCE { mteEventName SnmpAdminString, mteEventComment SnmpAdminString, mteEventActions BITS, mteEventEnabled TruthValue, mteEventEntryStatus RowStatus } mteEventName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the event." ::= { mteEventEntry 1 } mteEventComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the event's function and use." DEFVAL { ''H } ::= { mteEventEntry 2 } mteEventActions OBJECT-TYPE SYNTAX BITS { notification(0), set(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "The actions to perform when this event occurs. For 'notification', Traps and/or Informs are sent according to the configuration in the SNMP Notification MIB. For 'set', an SNMP Set operation is performed according to control values in this entry." DEFVAL { {} } -- No bits set. ::= { mteEventEntry 3 } mteEventEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow an event to be configured but not used. When the value is 'false' the event does not execute even if Kavasseri & Stewart Standards Track [Page 34] RFC 2981 Event MIB October 2000 triggered." DEFVAL { false } ::= { mteEventEntry 4 } mteEventEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to delete it." ::= { mteEventEntry 5 } -- -- Event Notification Table -- mteEventNotificationTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about notifications to be sent as a consequence of management events." ::= { mteEvent 3 } mteEventNotificationEntry OBJECT-TYPE SYNTAX MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event's notification. Entries automatically exist in this this table for each mteEventEntry that has 'notification' set in mteEventActions." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventNotificationTable 1 } MteEventNotificationEntry ::= SEQUENCE { mteEventNotification OBJECT IDENTIFIER, mteEventNotificationObjectsOwner SnmpAdminString, mteEventNotificationObjects SnmpAdminString } mteEventNotification OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current Kavasseri & Stewart Standards Track [Page 35] RFC 2981 Event MIB October 2000 DESCRIPTION "The object identifier from the NOTIFICATION-TYPE for the notification to use if metEventActions has 'notification' set." DEFVAL { zeroDotZero } ::= { mteEventNotificationEntry 1 } mteEventNotificationObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteEventNotificationObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteEventNotificationEntry 2 } mteEventNotificationObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable if mteEventActions has 'notification' set. These objects are to be added to any Notification generated by this event. Objects may also be added based on the trigger that stimulated the event. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteEventNotificationEntry 3 } -- -- Event Set Table -- mteEventSetTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 4 } mteEventSetEntry OBJECT-TYPE SYNTAX MteEventSetEntry MAX-ACCESS not-accessible Kavasseri & Stewart Standards Track [Page 36] RFC 2981 Event MIB October 2000 STATUS current DESCRIPTION "Information about a single event's set option. Entries automatically exist in this this table for each mteEventEntry that has 'set' set in mteEventActions." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventSetTable 1 } MteEventSetEntry ::= SEQUENCE { mteEventSetObject OBJECT IDENTIFIER, mteEventSetObjectWildcard TruthValue, mteEventSetValue Integer32, mteEventSetTargetTag SnmpTagValue, mteEventSetContextName SnmpAdminString, mteEventSetContextNameWildcard TruthValue } mteEventSetObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the MIB object to set if mteEventActions has 'set' set. This object identifier may be wildcarded by leaving sub-identifiers off the end, in which case nteEventSetObjectWildCard must be 'true'. If mteEventSetObject is wildcarded the instance used to set the object to which it points is the same as the instance from the value of mteTriggerValueID that triggered the event. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Bad object identifiers or a mismatch between truncating the identifier and the value of mteSetObjectWildcard result in operation as one would expect when providing the wrong identifier to a Set operation. The Set will fail or set the wrong object. If the value syntax of the destination object is not correct, the Set fails with the normal SNMP error code." DEFVAL { zeroDotZero } ::= { mteEventSetEntry 1 } Kavasseri & Stewart Standards Track [Page 37] RFC 2981 Event MIB October 2000 mteEventSetObjectWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control over whether mteEventSetObject is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } ::= { mteEventSetEntry 2 } mteEventSetValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to which to set the object at mteEventSetObject if mteEventActions has 'set' set." DEFVAL { 0 } ::= { mteEventSetEntry 3 } mteEventSetTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-write STATUS current DESCRIPTION "The tag for the target(s) at which to set the object at mteEventSetObject to mteEventSetValue if mteEventActions has 'set' set. Systems limited to self management MAY reject a non-zero length for the value of this object. A length of 0 indicates the local system. In this case, access to the objects indicated by mteEventSetObject is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security parameters resulting from the tag." DEFVAL { ''H } ::= { mteEventSetEntry 4 } mteEventSetContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write Kavasseri & Stewart Standards Track [Page 38] RFC 2981 Event MIB October 2000 STATUS current DESCRIPTION "The management context in which to set mteEventObjectID. if mteEventActions has 'set' set. This may be wildcarded by leaving characters off the end. To indicate such wildcarding mteEventSetContextNameWildcard must be 'true'. If this context name is wildcarded the value used to complete the wildcarding of mteTriggerContextName will be appended." DEFVAL { ''H } ::= { mteEventSetEntry 5 } mteEventSetContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteEventSetContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } ::= { mteEventSetEntry 6 } -- -- Notifications -- dismanEventMIBNotificationPrefix OBJECT IDENTIFIER ::= { dismanEventMIB 2 } dismanEventMIBNotifications OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 0 } dismanEventMIBNotificationObjects OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 1 } -- -- Notification Objects -- mteHotTrigger OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The name of the trigger causing the notification." ::= { dismanEventMIBNotificationObjects 1 } Kavasseri & Stewart Standards Track [Page 39] RFC 2981 Event MIB October 2000 mteHotTargetName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The SNMP Target MIB's snmpTargetAddrName related to the notification." ::= { dismanEventMIBNotificationObjects 2 } mteHotContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The context name related to the notification. This MUST be as fully-qualified as possible, including filling in wildcard information determined in processing." ::= { dismanEventMIBNotificationObjects 3 } mteHotOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The object identifier of the destination object related to the notification. This MUST be as fully-qualified as possible, including filling in wildcard information determined in processing. For a trigger-related notification this is from mteTriggerValueID. For a set failure this is from mteEventSetObject." ::= { dismanEventMIBNotificationObjects 4 } mteHotValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the object at mteTriggerValueID when a trigger fired." ::= { dismanEventMIBNotificationObjects 5 } mteFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS accessible-for-notify STATUS current Kavasseri & Stewart Standards Track [Page 40] RFC 2981 Event MIB October 2000 DESCRIPTION "The reason for the failure of an attempt to check for a trigger condition or set an object in response to an event." ::= { dismanEventMIBNotificationObjects 6 } -- -- Notifications -- mteTriggerFired NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the trigger indicated by the object instances has fired, for triggers with mteTriggerType 'boolean' or 'existence'." ::= { dismanEventMIBNotifications 1 } mteTriggerRising NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the rising threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 2 } mteTriggerFalling NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the falling threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 3 } mteTriggerFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, Kavasseri & Stewart Standards Track [Page 41] RFC 2981 Event MIB October 2000 mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to check a trigger has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 4 } mteEventSetFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to do a set in response to an event has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 5 } -- -- Conformance -- dismanEventMIBConformance OBJECT IDENTIFIER ::= { dismanEventMIB 3 } dismanEventMIBCompliances OBJECT IDENTIFIER ::= { dismanEventMIBConformance 1 } dismanEventMIBGroups OBJECT IDENTIFIER ::= { dismanEventMIBConformance 2 } -- Compliance dismanEventMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Kavasseri & Stewart Standards Track [Page 42] RFC 2981 Event MIB October 2000 "The compliance statement for entities which implement the Event MIB." MODULE -- this module MANDATORY-GROUPS { dismanEventResourceGroup, dismanEventTriggerGroup, dismanEventObjectsGroup, dismanEventEventGroup, dismanEventNotificationObjectGroup, dismanEventNotificationGroup } OBJECT mteTriggerTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting monitoring to the local system or pre-configured remote systems." OBJECT mteEventSetTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting setting to the local system or pre-configured remote systems." OBJECT mteTriggerValueIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteTriggerContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteObjectsIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteEventSetContextNameWildcard MIN-ACCESS read-only DESCRIPTION Kavasseri & Stewart Standards Track [Page 43] RFC 2981 Event MIB October 2000 "Write access is not required, thus allowing the system not to implement wildcarding." ::= { dismanEventMIBCompliances 1 } -- Units of Conformance dismanEventResourceGroup OBJECT-GROUP OBJECTS { mteResourceSampleMinimum, mteResourceSampleInstanceMaximum, mteResourceSampleInstances, mteResourceSampleInstancesHigh, mteResourceSampleInstanceLacks } STATUS current DESCRIPTION "Event resource status and control objects." ::= { dismanEventMIBGroups 1 } dismanEventTriggerGroup OBJECT-GROUP OBJECTS { mteTriggerFailures, mteTriggerComment, mteTriggerTest, mteTriggerSampleType, mteTriggerValueID, mteTriggerValueIDWildcard, mteTriggerTargetTag, mteTriggerContextName, mteTriggerContextNameWildcard, mteTriggerFrequency, mteTriggerObjectsOwner, mteTriggerObjects, mteTriggerEnabled, mteTriggerEntryStatus, mteTriggerDeltaDiscontinuityID, mteTriggerDeltaDiscontinuityIDWildcard, mteTriggerDeltaDiscontinuityIDType, mteTriggerExistenceTest, mteTriggerExistenceStartup, mteTriggerExistenceObjectsOwner, mteTriggerExistenceObjects, mteTriggerExistenceEventOwner, mteTriggerExistenceEvent, Kavasseri & Stewart Standards Track [Page 44] RFC 2981 Event MIB October 2000 mteTriggerBooleanComparison, mteTriggerBooleanValue, mteTriggerBooleanStartup, mteTriggerBooleanObjectsOwner, mteTriggerBooleanObjects, mteTriggerBooleanEventOwner, mteTriggerBooleanEvent, mteTriggerThresholdStartup, mteTriggerThresholdObjectsOwner, mteTriggerThresholdObjects, mteTriggerThresholdRising, mteTriggerThresholdFalling, mteTriggerThresholdDeltaRising, mteTriggerThresholdDeltaFalling, mteTriggerThresholdRisingEventOwner, mteTriggerThresholdRisingEvent, mteTriggerThresholdFallingEventOwner, mteTriggerThresholdFallingEvent, mteTriggerThresholdDeltaRisingEventOwner, mteTriggerThresholdDeltaRisingEvent, mteTriggerThresholdDeltaFallingEventOwner, mteTriggerThresholdDeltaFallingEvent } STATUS current DESCRIPTION "Event triggers." ::= { dismanEventMIBGroups 2 } dismanEventObjectsGroup OBJECT-GROUP OBJECTS { mteObjectsID, mteObjectsIDWildcard, mteObjectsEntryStatus } STATUS current DESCRIPTION "Supplemental objects." ::= { dismanEventMIBGroups 3 } dismanEventEventGroup OBJECT-GROUP OBJECTS { mteEventFailures, mteEventComment, mteEventActions, mteEventEnabled, mteEventEntryStatus, Kavasseri & Stewart Standards Track [Page 45] RFC 2981 Event MIB October 2000 mteEventNotification, mteEventNotificationObjectsOwner, mteEventNotificationObjects, mteEventSetObject, mteEventSetObjectWildcard, mteEventSetValue, mteEventSetTargetTag, mteEventSetContextName, mteEventSetContextNameWildcard } STATUS current DESCRIPTION "Events." ::= { dismanEventMIBGroups 4 } dismanEventNotificationObjectGroup OBJECT-GROUP OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue, mteFailedReason } STATUS current DESCRIPTION "Notification objects." ::= { dismanEventMIBGroups 5 } dismanEventNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mteTriggerFired, mteTriggerRising, mteTriggerFalling, mteTriggerFailure, mteEventSetFailure } STATUS current DESCRIPTION "Notifications." ::= { dismanEventMIBGroups 6 } END Kavasseri & Stewart Standards Track [Page 46] RFC 2981 Event MIB October 2000 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), the Distributed Management Working Group, and colleagues at Cisco. 10. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Kavasseri & Stewart Standards Track [Page 47] RFC 2981 Event MIB October 2000 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. Kavasseri & Stewart Standards Track [Page 48] RFC 2981 Event MIB October 2000 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. [RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000. [RFC1757] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995. [RFC1451] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Manager-to- Manager Management Information Base", RFC 1451, April 1993. [RFC2982] Stewart, B., "Distributed Management Expression MIB", RFC 2982, October 2000. [LOG-MIB] Stewart, B., "Notification Log MIB", Work in Progress. 11. Security Considerations Security issues are discussed in the Security section and in the DESCRIPTION clauses of relevant objects. 12. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 13. Editor's Address Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 EMail: ramk@cisco.com Kavasseri & Stewart Standards Track [Page 49] RFC 2981 Event MIB October 2000 14. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kavasseri & Stewart Standards Track [Page 50] snmp-mibs-downloader-1.1/mibrfcs/rfc2982.txt0000644000000000000000000023673311402176071015604 0ustar Network Working Group R. Kavasseri Request for Comments: 2982 (Editor of this version) Category: Standards Track B. Stewart (Author of previous version) Cisco Systems, Inc. October 2000 Distributed Management Expression MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 2.1 Usage ..................................................... 4 2.2 Persistence ............................................... 4 2.3 Operation ................................................. 4 2.3.1 Sampling ................................................ 5 2.3.2 Wildcards ............................................... 5 2.3.3 Evaluation .............................................. 5 2.3.4 Value Identification .................................... 6 2.4 Subsets ................................................... 6 2.4.1 No Wildcards ............................................ 6 Kavasseri & Stewart Standards Track [Page 1] RFC 2982 Distributed Management Expression MIB October 2000 2.4.2 No Deltas ............................................... 7 2.5 Structure ................................................. 7 2.5.1 Resource ................................................ 7 2.5.2 Definition .............................................. 7 2.5.3 Value ................................................... 8 2.6 Examples .................................................. 8 2.6.1 Wildcarding ............................................. 8 2.6.2 Calculation and Conditional ............................. 10 3 Definitions ................................................. 12 4 Intellectual Property ....................................... 36 5 Acknowledgements ............................................ 37 6 References .................................................. 37 7 Security Considerations ..................................... 38 8 Author's Address ............................................ 40 9 Editor's Address ............................................ 40 10 Full Copyright Statement ................................... 41 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. Kavasseri & Stewart Standards Track [Page 2] RFC 2982 Distributed Management Expression MIB October 2000 o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview Users of MIBs often desire MIB objects that MIB designers have not provided. Furthermore, such needs vary from one management philosophy to another. Rather than fill more and more MIBs with standardized objects, the Expression MIB supports externally defined expressions of existing MIB objects. In the Expression MIB the results of an evaluated expression are MIB objects that may be used like any other MIB objects. These custom- defined objects are thus usable anywhere any other MIB object can be used. For example, they can be used by a management application directly or referenced from another MIB, such as the Event MIB [MIBEventMIB]. They can even be used by the Expression MIB itself, forming expressions of expressions. The Expression MIB is instrumentation for a relatively powerful, complex, high-level application, considerably different from simple instrumentation for a communication driver or a protocol. The MIB is appropriate in a relatively powerful, resource-rich managed system and not necessarily in a severely limited environment. Nevertheless, due to dependencies from the Event MIB [RFC2981] and the need to support as low-end a system as possible, the Expression MIB can be somewhat stripped down for lower-power, lower-resource implementations, as described in the Subsets section, below. Kavasseri & Stewart Standards Track [Page 3] RFC 2982 Distributed Management Expression MIB October 2000 Implementation of the Expression MIB in a managed system led to the addition of objects that may not have been necessary in an application environment with complete knowledge of compiled MIB definitions. This is appropriate since implementation must be possible within typical managed systems with some constraints on system resources. 2.1. Usage On managed systems that can afford the overhead, the Expression MIB is a way to create new, customized MIB objects for monitoring. Although these can save some network traffic and overhead on management systems, that is often not a good tradeoff for objects that are simply to be recorded or displayed. An example of a use of the Expression MIB would be to provide custom objects for the Event MIB [RFC2981]. A complex expression can evaluate to a rate of flow or a boolean and thus be subject to testing as an event trigger, resulting in an SNMP notification. Without these capabilities such monitoring would be limited to the objects in predefined MIBs. The Expression MIB thus supports powerful tools for the network manager faced with the monitoring of large, complex systems that can support a significant level of self management. 2.2. Persistence Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring an expression, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. 2.3. Operation Most of the operation of the MIB is described or implied in the object definitions but a few highlights bear mentioning here. Kavasseri & Stewart Standards Track [Page 4] RFC 2982 Distributed Management Expression MIB October 2000 2.3.1. Sampling The MIB supports three types of object sampling for the MIB objects that make up the expression: absolute, delta, and changed. Absolute samples are simply the value of the MIB object at the time it is sampled. Absolute samples are not sufficient for expressions of counters, as counters have meaning only as a delta (difference) from one sample to the next. Thus objects may be sampled as deltas. Delta sampling requires the application to maintain state for the value at the last sample, and to do continuous sampling whether or not anyone is looking at the results. It thus creates constant overhead. Changed sampling is a simple fallout of delta sampling where rather than a difference the result is a boolean indicating whether or not the object changed value since the last sample. 2.3.2. Wildcards Wildcards allow the application of a single expression to multiple instances of the same MIB object. The definer of the expression indicates this choice and provides a partial object identifier, with some or all of the instance portion left off. The application then does the equivalent of GetNext to obtain the object values, thus discovering the instances. All wildcarded objects in an expression must have the same semantics for the missing portion of their object identifiers. Otherwise, any successful evaluation of the wildcarded expression would be the result of the accidental matching of the wildcarded portion of the object identifiers in the expression. Such an evaluation will likely produce results which are not meaningful. The expression can be evaluated only for those instances where all the objects in the expression are available with the same value for the wildcarded portion of the instance. 2.3.3. Evaluation There are two important aspects of evaluation that may not be obvious: what objects and when. What objects get used in the evaluation depends on the type of request and whether or not the expression contains wildcarded objects. If the request was a Get, that locks down the instances to Kavasseri & Stewart Standards Track [Page 5] RFC 2982 Distributed Management Expression MIB October 2000 be used. If the request was a GetNext or GetBulk, the application must work its way up to the next full set of objects for the expression. Evaluation of expressions happens at two possible times, depending on the sampling method (delta or absolute) used to evaluate the expression. If there are no delta or change values in an expression, the evaluation occurs on demand, i.e. when a requester attempts to read the value of the expression. In this case all requesters get a freshly calculated value. For expressions with delta or change values, evaluation goes on continuously, every sample period. In this case requesters get the value as of the last sample period. For any given sample period of a given expression, only those instances exist that provided a full set of object values. It may be possible that a delta expression which was evaluated successfully for one sample period may not be successfully evaluated in the next sample period. This may, for example, be due to missing instances for some or all of the objects in the expression. In such cases, the value from the previous sample period (with the successful evaluation) must not be carried forward to the next sample period (with the failed evaluation). 2.3.4. Value Identification Values resulting from expression evaluation are identified with a combination of the object identifier (OID) for the data type from expValueTable (such as expValueCounter32Val), the expression owner, the expression name, and an OID fragment. The OID fragment is not an entire OID beginning with iso.dod.org (1.3.6). Rather it begins with 0.0. The remainder is either another 0 when there is no wildcarding or the instance that satisfied the wildcard if there is wildcarding. 2.4. Subsets To pare down the Expression MIBs complexity and use of resources an implementor can leave out various parts. 2.4.1. No Wildcards Leaving out wildcarding significantly reduces the complexity of retrieving values to evaluate expressions and the processing required to do so. Such an implementation would allow expressions made up of Kavasseri & Stewart Standards Track [Page 6] RFC 2982 Distributed Management Expression MIB October 2000 individual MIB objects but would not be suitable for expressions applied across large tables as each instance in the table would require a separate expression definition. Furthermore it would not be suitable for tables with arbitrary, dynamic instances, as expressions definitions could not predict what instance values to use. An implementation without wildcards might be useful for a self- managing system with small tables or few dynamic instances, or one that can do calculations only for a few key objects. 2.4.2. No Deltas Leaving out delta processing significantly reduces state that must be kept and the burden of ongoing processing even when no one is looking at the results. Unfortunately it also makes expressions on counters unusable, as counters have meaning only as deltas. An implementation without deltas might be useful for a severely limited, self-managing system that has no need for expressions or events on counters. Although conceivable, such systems would be rare. 2.5. Structure The MIB has the following sections: o Resource -- management of the MIB's use of system resources. o Definition -- definition of expressions. o Value -- values of evaluated expressions. 2.5.1. Resource The resource section has objects to manage resource usage by wildcarded delta expressions, a potential major consumer of CPU and memory. 2.5.2. Definition The definition section contains the tables that define expressions. The expression table, indexed by expression owner and expression name, contains those parameters that apply to the entire expression, such as the expression itself, the data type of the result, and the sampling interval if it contains delta or change values. Kavasseri & Stewart Standards Track [Page 7] RFC 2982 Distributed Management Expression MIB October 2000 The object table, indexed by expression owner, expression name and object index within each expression, contains the parameters that apply to the individual objects that go into the expression, including the object identifier, sample type, discontinuity indicator, and such. 2.5.3. Value The value section contains the values of evaluated expressions. The value table, indexed by expression owner, expression name and instance fragment contains a "discriminated union" of evaluated expression results. For a given expression only one of the columns is instantiated, depending on the result data type for the expression. The instance fragment is a constant or the final section of the object identifier that filled in a wildcard. 2.6. Examples The examples refer to tables and objects defined below in the MIB itself. They may well make more sense after reading those definitions. 2.6.1. Wildcarding An expression may use wildcarded MIB objects that result in multiple values for the expression. To specify a wildcarded MIB object a management application leaves off part or all of the instance portion of the object identifier, and sets expObjectWildcard to true(1) for that object. For our example we'll use a counter of total blessings from a table of people. Another table, indexed by town and person has blessings just from that town. So the index clauses are: personEntry OBJECT-TYPE ... INDEX { personIndex } And: townPersonEntry OBJECT-TYPE ... INDEX { townIndex, personIndex } Kavasseri & Stewart Standards Track [Page 8] RFC 2982 Distributed Management Expression MIB October 2000 In our friendly application we may have entered our expression as: 100 * townPersonBlessings.976.* / personBlessings.* What goes in expExpression is: 100*$1/$2 For example purposes we'll use some slightly far-fetched OIDs. The People MIB is 1.3.6.1.99.7 and the Town MIB is 1.3.6.1.99.11, so for our two counters the OIDs are: personBlessings 1.3.6.1.99.7.1.3.1.4 townPersonBlessings 1.3.6.1.99.11.1.2.1.9 The rule for wildcards is that all the wildcarded parts have to match exactly. In this case that means we have to hardwire the town and only the personIndex can be wildcarded. So our values for expObjectID are: 1.3.6.1.99.7.1.3.1.4 1.3.6.1.99.11.1.2.1.9.976 We're hardwired to townIndex 976 and personIndex is allowed to vary. The value of expExpressionPrefix can be either of those two counter OIDs (including the instance fragment in the second case), since either of them takes you to a MIB definition where you can look at the INDEX clause and figure out what's been left off. What's been left off doesn't have to work out to be the same object, but it does have to work out to be the same values (semantics) for the result to make sense. Note that the managed system can not typically check such semantics and if given nonsense will return nonsense. If we have people numbered 6, 19, and 42 in town number 976, the successive values of expValueInstance will be: 0.0.6 0.0.19 0.0.42 So there will be three values in expValueTable, with those OIDs as the expValueInstance part of their indexing. Kavasseri & Stewart Standards Track [Page 9] RFC 2982 Distributed Management Expression MIB October 2000 2.6.2. Calculation and Conditional The following formula for line utilization of a half-duplex link is adapted from [PracPersp]. utilization = (ifInOctets + ifOutOctets) * 800 / seconds / ifSpeed The expression results in the percentage line utilization per second. The total octets are multiplied by 8 to get bits and 100 to scale up the percentage as an integer. The following Expression MIB object values implement this as an expression for all ifIndexes that directly represent actual hardware. Since the octet counters are Counter32 values, they must be delta sampled to be meaningful. The sample period is 6 seconds but for accuracy and independence is calculated as a delta of sysUpTime. The expObjectTable entry for ifInOctets has an expObjectConditional that checks for being a hardware interface. Only one object in the expression needs that check associated, since it applies to the whole expression. Since ifConnectorPresent is a TruthValue with values of 1 or 2 rather than 0 and non-zero, it must also be in an expression rather than used directly for the conditional. The interface-specific discontinuity indicator is supplied only for ifInOctets since invalidating that sample will invalidate an attempt at evaluation, effectively invalidating ifOutOctets as well (correctly, because it has the same indicator). For notational clarity, in the rest of this document, a string in quotes as part of the object instance indicates the value that would actually be one subidentifier per byte. The objects all belong to owner "me". Also for clarity OIDs are expressed as the object descriptor and instance. In fact they must be supplied numerically, with all subidentifiers in place before the part for the particular object and instance. What the user would set in expExpressionTable: expExpression.2."me".4."hard" = "$1==1" expExpressionValueType.2."me".4."hard" = unsigned32 expExpressionRowStatus.2."me"4."hard" = 'active' Kavasseri & Stewart Standards Track [Page 10] RFC 2982 Distributed Management Expression MIB October 2000 expExpression.2."me".4."util" = "($1+$2)*800/$4/$3" expExpressionValueType.2."me".4."util" = integer32 expExpressionDeltaInterval.2."me".4."util" = 6 expExpressionRowStatus.2."me"4."util" = 'active' What the user would set in expObjectTable: expObjectID.2."me".4."hard".1 = ifConnectorPresent expObjectWildcard.2."me".4."hard".1 = 'true' expObjectSampleType.2."me".4."hard".1 = 'absoluteValue' expObjectRowStatus.2."me".4."hard".1 = 'active' expObjectID.2."me".4."util".1 = ifInOctets expObjectWildcard.2."me".4."util".1 = 'true' expObjectSampleType.2."me".4."util".1 = 'deltaValue' expObjectConditional.2."me".4."util".1 = expValueUnsigned32Val.4."hard".0.0 expObjectConditionalWildcard.2."me".4."util".1 = 'true' expObjectDiscontinuityID.2."me".4."util".1 = ifCounterDiscontinuityTime expObjectDiscontinuityIDWildcard.2."me".4."util".1 = 'true' expObjectRowStatus.2."me".4."util".1 = 'active' expObjectID.2."me".4."util".2 = ifOutOctets expObjectWildcard.2."me".4."util".2 = 'true' expObjectSampleType.2."me".4."util".2 = 'deltaValue' expObjectRowStatus.2."me".4."util".2 = 'active' expObjectID.2."me".4."util".3 = ifSpeed expObjectWildcard.2."me".4."util".3 = 'true' expObjectSampleType.2."me".4."util".3 = 'absoluteValue' expObjectRowStatus.2."me".4."util".3 = 'active' expObjectID.2."me".4."util".4 = sysUpTime.0 expObjectWildcard.2."me".4."util".4 = 'false' expObjectSampleType.2."me".4."util".4 = 'deltaValue' expObjectRowStatus.2."me".4."util".4 = 'active' These settings will result in populating one column of expValueTable: expValueInteger32Val.2."me".4."util".0.0.? The subidentifier represented by "?" above represents one subidentifier that takes on a value of ifIndex and identifies a row for each ifIndex value where ifConnectorPresent is 'true' and the interface was present for two samples to provide a delta. Kavasseri & Stewart Standards Track [Page 11] RFC 2982 Distributed Management Expression MIB October 2000 This value could in turn be used as an event threshold [RFC2981] to watch for overutilization of all hardware network connections. 3. Definitions DISMAN-EXPRESSION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32, Unsigned32, Counter32, Counter64, IpAddress, TimeTicks, mib-2, zeroDotZero FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp FROM SNMPv2-TC sysUpTime FROM SNMPv2-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; dismanExpressionMIB MODULE-IDENTITY LAST-UPDATED "200010160000Z" -- 16 October 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for defining expressions of MIB objects for management purposes." -- Revision History REVISION "200010160000Z" -- 16 October 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC 2982" ::= { mib-2 90 } dismanExpressionMIBObjects OBJECT IDENTIFIER ::= { dismanExpressionMIB 1 } expResource OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 1 } expDefine OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 2 } expValue OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 3 } -- -- Resource Control -- Kavasseri & Stewart Standards Track [Page 12] RFC 2982 Distributed Management Expression MIB October 2000 expResourceDeltaMinimum OBJECT-TYPE SYNTAX Integer32 (-1 | 1..600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum expExpressionDeltaInterval this system will accept. A system may use the larger values of this minimum to lessen the impact of constantly computing deltas. For larger delta sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all expressions created after it is set. The value -1 indicates that expResourceDeltaMinimum is irrelevant as the system will not accept 'deltaValue' as a value for expObjectSampleType. Unless explicitly resource limited, a system's value for this object should be 1, allowing as small as a 1 second interval for ongoing delta sampling. Changing this value will not invalidate an existing setting of expObjectSampleType." ::= { expResource 1 } expResourceDeltaWildcardInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" MAX-ACCESS read-write STATUS current DESCRIPTION "For every instance of a deltaValue object, one dynamic instance entry is needed for holding the instance value from the previous sample, i.e. to maintain state. This object limits maximum number of dynamic instance entries this system will support for wildcarded delta objects in expressions. For a given delta expression, the number of dynamic instances is the number of values that meet all criteria to exist times the number of delta values in the expression. A value of 0 indicates no preset limit, that is, the limit is dynamic based on system operation and resources. Unless explicitly resource limited, a system's value for this object should be 0. Kavasseri & Stewart Standards Track [Page 13] RFC 2982 Distributed Management Expression MIB October 2000 Changing this value will not eliminate or inhibit existing delta wildcard instance objects but will prevent the creation of more such objects. An attempt to allocate beyond the limit results in expErrorCode being tooManyWildcardValues for that evaluation attempt." ::= { expResource 2 } expResourceDeltaWildcardInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for expResourceDeltaWildcardInstanceMaximum." ::= { expResource 3 } expResourceDeltaWildcardInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of expResourceDeltaWildcardInstances that has occurred since initialization of the managed system." ::= { expResource 4 } expResourceDeltaWildcardInstanceResourceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this system could not evaluate an expression because that would have created a value instance in excess of expResourceDeltaWildcardInstanceMaximum." ::= { expResource 5 } -- -- Definition -- -- Expression Definition Table -- expExpressionTable OBJECT-TYPE Kavasseri & Stewart Standards Track [Page 14] RFC 2982 Distributed Management Expression MIB October 2000 SYNTAX SEQUENCE OF ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression definitions." ::= { expDefine 1 } expExpressionEntry OBJECT-TYPE SYNTAX ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single expression. New expressions can be created using expExpressionRowStatus. To create an expression first create the named entry in this table. Then use expExpressionName to populate expObjectTable. For expression evaluation to succeed all related entries in expExpressionTable and expObjectTable must be 'active'. If these conditions are not met the corresponding values in expValue simply are not instantiated. Deleting an entry deletes all related entries in expObjectTable and expErrorTable. Because of the relationships among the multiple tables for an expression (expExpressionTable, expObjectTable, and expValueTable) and the SNMP rules for independence in setting object values, it is necessary to do final error checking when an expression is evaluated, that is, when one of its instances in expValueTable is read or a delta interval expires. Earlier checking need not be done and an implementation may not impose any ordering on the creation of objects related to an expression. To maintain security of MIB information, when creating a new row in this table, the managed system must record the security credentials of the requester. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of the expression takes place under the security credentials of the creator of its expExpressionEntry. Values of read-write objects in this table may be changed Kavasseri & Stewart Standards Track [Page 15] RFC 2982 Distributed Management Expression MIB October 2000 at any time." INDEX { expExpressionOwner, expExpressionName } ::= { expExpressionTable 1 } ExpExpressionEntry ::= SEQUENCE { expExpressionOwner SnmpAdminString, expExpressionName SnmpAdminString, expExpression OCTET STRING, expExpressionValueType INTEGER, expExpressionComment SnmpAdminString, expExpressionDeltaInterval Integer32, expExpressionPrefix OBJECT IDENTIFIER, expExpressionErrors Counter32, expExpressionEntryStatus RowStatus } expExpressionOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { expExpressionEntry 1 } expExpressionName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the expression. This is locally unique, within the scope of an expExpressionOwner." ::= { expExpressionEntry 2 } expExpression OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "The expression to be evaluated. This object is the same as a DisplayString (RFC 1903) except for its maximum length. Except for the variable names the expression is in ANSI C syntax. Only the subset of ANSI C operators and functions listed here is allowed. Variables are expressed as a dollar sign ('$') and an Kavasseri & Stewart Standards Track [Page 16] RFC 2982 Distributed Management Expression MIB October 2000 integer that corresponds to an expObjectIndex. An example of a valid expression is: ($1-$5)*100 Expressions must not be recursive, that is although an expression may use the results of another expression, it must not contain any variable that is directly or indirectly a result of its own evaluation. The managed system must check for recursive expressions. The only allowed operators are: ( ) - (unary) + - * / % & | ^ << >> ~ ! && || == != > >= < <= Note the parentheses are included for parenthesizing the expression, not for casting data types. The only constant types defined are: int (32-bit signed) long (64-bit signed) unsigned int unsigned long hexadecimal character string oid The default type for a positive integer is int unless it is too large in which case it is long. All but oid are as defined for ANSI C. Note that a hexadecimal constant may end up as a scalar or an array of 8-bit integers. A string constant is enclosed in double quotes and may contain back-slashed individual characters as in ANSI C. An oid constant comprises 32-bit, unsigned integers and at least one period, for example: 0. .0 1.3.6.1 Kavasseri & Stewart Standards Track [Page 17] RFC 2982 Distributed Management Expression MIB October 2000 No additional leading or trailing subidentifiers are automatically added to an OID constant. The constant is taken as expressed. Integer-typed objects are treated as 32- or 64-bit, signed or unsigned integers, as appropriate. The results of mixing them are as for ANSI C, including the type of the result. Note that a 32-bit value is thus promoted to 64 bits only in an operation with a 64-bit value. There is no provision for larger values to handle overflow. Relative to SNMP data types, a resulting value becomes unsigned when calculating it uses any unsigned value, including a counter. To force the final value to be of data type counter the expression must explicitly use the counter32() or counter64() function (defined below). OCTET STRINGS and OBJECT IDENTIFIERs are treated as one-dimensioned arrays of unsigned 8-bit integers and unsigned 32-bit integers, respectively. IpAddresses are treated as 32-bit, unsigned integers in network byte order, that is, the hex version of 255.0.0.0 is 0xff000000. Conditional expressions result in a 32-bit, unsigned integer of value 0 for false or 1 for true. When an arbitrary value is used as a boolean 0 is false and non-zero is true. Rules for the resulting data type from an operation, based on the operator: For << and >> the result is the same as the left hand operand. For &&, ||, ==, !=, <, <=, >, and >= the result is always Unsigned32. For unary - the result is always Integer32. For +, -, *, /, %, &, |, and ^ the result is promoted according to the following rules, in order from most to least preferred: If left hand and right hand operands are the same type, use that. If either side is Counter64, use that. If either side is IpAddress, use that. Kavasseri & Stewart Standards Track [Page 18] RFC 2982 Distributed Management Expression MIB October 2000 If either side is TimeTicks, use that. If either side is Counter32, use that. Otherwise use Unsigned32. The following rules say what operators apply with what data types. Any combination not explicitly defined does not work. For all operators any of the following can be the left hand or right hand operand: Integer32, Counter32, Unsigned32, Counter64. The operators +, -, *, /, %, <, <=, >, and >= work with TimeTicks. The operators &, |, and ^ work with IpAddress. The operators << and >> work with IpAddress but only as the left hand operand. The + operator performs a concatenation of two OCTET STRINGs or two OBJECT IDENTIFIERs. The operators &, | perform bitwise operations on OCTET STRINGs. If the OCTET STRING happens to be a DisplayString the results may be meaningless, but the agent system does not check this as some such systems do not have this information. The operators << and >> perform bitwise operations on OCTET STRINGs appearing as the left hand operand. The only functions defined are: counter32 counter64 arraySection stringBegins stringEnds stringContains oidBegins oidEnds oidContains average maximum minimum sum exists Kavasseri & Stewart Standards Track [Page 19] RFC 2982 Distributed Management Expression MIB October 2000 The following function definitions indicate their parameters by naming the data type of the parameter in the parameter's position in the parameter list. The parameter must be of the type indicated and generally may be a constant, a MIB object, a function, or an expression. counter32(integer) - wrapped around an integer value counter32 forces Counter32 as a data type. counter64(integer) - similar to counter32 except that the resulting data type is 'counter64'. arraySection(array, integer, integer) - selects a piece of an array (i.e. part of an OCTET STRING or OBJECT IDENTIFIER). The integer arguments are in the range 0 to 4,294,967,295. The first is an initial array index (one-dimensioned) and the second is an ending array index. A value of 0 indicates first or last element, respectively. If the first element is larger than the array length the result is 0 length. If the second integer is less than or equal to the first, the result is 0 length. If the second is larger than the array length it indicates last element. stringBegins/Ends/Contains(octetString, octetString) - looks for the second string (which can be a string constant) in the first and returns the one-dimensioned arrayindex where the match began. A return value of 0 indicates no match (i.e. boolean false). oidBegins/Ends/Contains(oid, oid) - looks for the second OID (which can be an OID constant) in the first and returns the the one-dimensioned index where the match began. A return value of 0 indicates no match (i.e. boolean false). average/maximum/minimum(integer) - calculates the average, minimum, or maximum value of the integer valued object over multiple sample times. If the object disappears for any sample period, the accumulation and the resulting value object cease to exist until the object reappears at which point the calculation starts over. sum(integerObject*) - sums all available values of the wildcarded integer object, resulting in an integer scalar. Must be used with caution as it wraps on overflow with no notification. exists(anyTypeObject) - verifies the object instance exists. A return value of 0 indicates NoSuchInstance (i.e. boolean false)." Kavasseri & Stewart Standards Track [Page 20] RFC 2982 Distributed Management Expression MIB October 2000 ::= { expExpressionEntry 3 } expExpressionValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the expression value. One and only one of the value objects in expValueTable will be instantiated to match this type. If the result of the expression can not be made into this type, an invalidOperandType error will occur." DEFVAL { counter32 } ::= { expExpressionEntry 4 } expExpressionComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A comment to explain the use or meaning of the expression." DEFVAL { ''H } ::= { expExpressionEntry 5 } expExpressionDeltaInterval OBJECT-TYPE SYNTAX Integer32 (0..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Sampling interval for objects in this expression with expObjectSampleType 'deltaValue'. This object has no effect if the the expression has no deltaValue objects. A value of 0 indicates no automated sampling. In this case the delta is the difference from the last time the expression was evaluated. Note that this is subject to unpredictable delta times in the face of retries or multiple managers. A value greater than zero is the number of seconds between automated samples. Until the delta interval has expired once the delta for the Kavasseri & Stewart Standards Track [Page 21] RFC 2982 Distributed Management Expression MIB October 2000 object is effectively not instantiated and evaluating the expression has results as if the object itself were not instantiated. Note that delta values potentially consume large amounts of system CPU and memory. Delta state and processing must continue constantly even if the expression is not being used. That is, the expression is being evaluated every delta interval, even if no application is reading those values. For wildcarded objects this can be substantial overhead. Note that delta intervals, external expression value sampling intervals and delta intervals for expressions within other expressions can have unusual interactions as they are impossible to synchronize accurately. In general one interval embedded below another must be enough shorter that the higher sample sees relatively smooth, predictable behavior. So, for example, to avoid the higher level getting the same sample twice, the lower level should sample at least twice as fast as the higher level does." DEFVAL { 0 } ::= { expExpressionEntry 6 } expExpressionPrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object prefix to assist an application in determining the instance indexing to use in expValueTable, relieving the application of the need to scan the expObjectTable to determine such a prefix. See expObjectTable for information on wildcarded objects. If the expValueInstance portion of the value OID may be treated as a scalar (that is, normally, 0) the value of expExpressionPrefix is zero length, that is, no OID at all. Note that zero length implies a null OID, not the OID 0.0. Otherwise, the value of expExpressionPrefix is the expObjectID value of any one of the wildcarded objects for the expression. This is sufficient, as the remainder, that is, the instance fragment relevant to instancing the values, must be the same for all wildcarded objects in the expression." ::= { expExpressionEntry 7 } expExpressionErrors OBJECT-TYPE Kavasseri & Stewart Standards Track [Page 22] RFC 2982 Distributed Management Expression MIB October 2000 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of errors encountered while evaluating this expression. Note that an object in the expression not being accessible, is not considered an error. An example of an inaccessible object is when the object is excluded from the view of the user whose security credentials are used in the expression evaluation. In such cases, it is a legitimate condition that causes the corresponding expression value not to be instantiated." ::= { expExpressionEntry 8 } expExpressionEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries." ::= { expExpressionEntry 9 } -- -- Expression Error Table -- expErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression errors." ::= { expDefine 2 } expErrorEntry OBJECT-TYPE SYNTAX ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about errors in processing an expression. Entries appear in this table only when there is a matching expExpressionEntry and then only when there has been an error for that expression as reflected by the error codes defined for expErrorCode." INDEX { expExpressionOwner, expExpressionName } Kavasseri & Stewart Standards Track [Page 23] RFC 2982 Distributed Management Expression MIB October 2000 ::= { expErrorTable 1 } ExpErrorEntry ::= SEQUENCE { expErrorTime TimeStamp, expErrorIndex Integer32, expErrorCode INTEGER, expErrorInstance OBJECT IDENTIFIER } expErrorTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time an error caused a failure to evaluate this expression." ::= { expErrorEntry 1 } expErrorIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The one-dimensioned character array index into expExpression for where the error occurred. The value zero indicates irrelevance." ::= { expErrorEntry 2 } expErrorCode OBJECT-TYPE SYNTAX INTEGER { invalidSyntax(1), undefinedObjectIndex(2), unrecognizedOperator(3), unrecognizedFunction(4), invalidOperandType(5), unmatchedParenthesis(6), tooManyWildcardValues(7), recursion(8), deltaTooShort(9), resourceUnavailable(10), divideByZero(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "The error that occurred. In the following explanations the expected timing of the error is in parentheses. 'S' means the error occurs on a Set request. 'E' means the error Kavasseri & Stewart Standards Track [Page 24] RFC 2982 Distributed Management Expression MIB October 2000 occurs on the attempt to evaluate the expression either due to Get from expValueTable or in ongoing delta processing. invalidSyntax the value sent for expExpression is not valid Expression MIB expression syntax (S) undefinedObjectIndex an object reference ($n) in expExpression does not have a matching instance in expObjectTable (E) unrecognizedOperator the value sent for expExpression held an unrecognized operator (S) unrecognizedFunction the value sent for expExpression held an unrecognized function name (S) invalidOperandType an operand in expExpression is not the right type for the associated operator or result (SE) unmatchedParenthesis the value sent for expExpression is not correctly parenthesized (S) tooManyWildcardValues evaluating the expression exceeded the limit set by expResourceDeltaWildcardInstanceMaximum (E) recursion through some chain of embedded expressions the expression invokes itself (E) deltaTooShort the delta for the next evaluation passed before the system could evaluate the present sample (E) resourceUnavailable some resource, typically dynamic memory, was unavailable (SE) divideByZero an attempt to divide by zero occurred (E) For the errors that occur when the attempt is made to set expExpression Set request fails with the SNMP error code 'wrongValue'. Such failures refer to the most recent failure to Set expExpression, not to the present value of expExpression which must be either unset or syntactically correct. Errors that occur during evaluation for a Get* operation return the SNMP error code 'genErr' except for 'tooManyWildcardValues' and 'resourceUnavailable' which return the SNMP error code 'resourceUnavailable'." ::= { expErrorEntry 3 } expErrorInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only Kavasseri & Stewart Standards Track [Page 25] RFC 2982 Distributed Management Expression MIB October 2000 STATUS current DESCRIPTION "The expValueInstance being evaluated when the error occurred. A zero-length indicates irrelevance." ::= { expErrorEntry 4 } -- -- Object Table -- expObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of object definitions for each expExpression. Wildcarding instance IDs: It is legal to omit all or part of the instance portion for some or all of the objects in an expression. (See the DESCRIPTION of expObjectID for details. However, note that if more than one object in the same expression is wildcarded in this way, they all must be objects where that portion of the instance is the same. In other words, all objects may be in the same SEQUENCE or in different SEQUENCEs but with the same semantic index value (e.g., a value of ifIndex) for the wildcarded portion." ::= { expDefine 3 } expObjectEntry OBJECT-TYPE SYNTAX ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an object. An application uses expObjectEntryStatus to create entries in this table while in the process of defining an expression. Values of read-create objects in this table may be changed at any time." INDEX { expExpressionOwner, expExpressionName, expObjectIndex } ::= { expObjectTable 1 } ExpObjectEntry ::= SEQUENCE { expObjectIndex Unsigned32, expObjectID OBJECT IDENTIFIER, expObjectIDWildcard TruthValue, Kavasseri & Stewart Standards Track [Page 26] RFC 2982 Distributed Management Expression MIB October 2000 expObjectSampleType INTEGER, expObjectDeltaDiscontinuityID OBJECT IDENTIFIER, expObjectDiscontinuityIDWildcard TruthValue, expObjectDiscontinuityIDType INTEGER, expObjectConditional OBJECT IDENTIFIER, expObjectConditionalWildcard TruthValue, expObjectEntryStatus RowStatus } expObjectIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Within an expression, a unique, numeric identification for an object. Prefixed with a dollar sign ('$') this is used to reference the object in the corresponding expExpression." ::= { expObjectEntry 1 } expObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of this object. The OID may be fully qualified, meaning it includes a complete instance identifier part (e.g., ifInOctets.1 or sysUpTime.0), or it may not be fully qualified, meaning it may lack all or part of the instance identifier. If the expObjectID is not fully qualified, then expObjectWildcard must be set to true(1). The value of the expression will be multiple values, as if done for a GetNext sweep of the object. An object here may itself be the result of an expression but recursion is not allowed. NOTE: The simplest implementations of this MIB may not allow wildcards." ::= { expObjectEntry 2 } expObjectIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjecID of this row is a wildcard object. False indicates that expObjectID is fully instanced. If all expObjectWildcard values for a given expression are FALSE, Kavasseri & Stewart Standards Track [Page 27] RFC 2982 Distributed Management Expression MIB October 2000 expExpressionPrefix will reflect a scalar object (i.e. will be 0.0). NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 3 } expObjectSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2), changedValue(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable. An 'absoluteValue' is simply the present value of the object. A 'deltaValue' is the present value minus the previous value, which was sampled expExpressionDeltaInterval seconds ago. This is intended primarily for use with SNMP counters, which are meaningless as an 'absoluteValue', but may be used with any integer-based value. A 'changedValue' is a boolean for whether the present value is different from the previous value. It is applicable to any data type and results in an Unsigned32 with value 1 if the object's value is changed and 0 if not. In all other respects it is as a 'deltaValue' and all statements and operation regarding delta values apply to changed values. When an expression contains both delta and absolute values the absolute values are obtained at the end of the delta period." DEFVAL { absoluteValue } ::= { expObjectEntry 4 } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } expObjectDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at expObjectID. Kavasseri & Stewart Standards Track [Page 28] RFC 2982 Distributed Management Expression MIB October 2000 This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match expObjectID. This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking must still check sysUpTime for an overall discontinuity. If the object identified is not accessible no discontinuity check will be made." DEFVAL { sysUpTimeInstance } ::= { expObjectEntry 5 } expObjectDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectDeltaDiscontinuityID of this row is a wildcard object. False indicates that expObjectDeltaDiscontinuityID is fully instanced. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 6 } expObjectDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value 'timeTicks' indicates the expObjectDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime indicates syntax DateAndTime. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'." DEFVAL { timeTicks } ::= { expObjectEntry 7 } Kavasseri & Stewart Standards Track [Page 29] RFC 2982 Distributed Management Expression MIB October 2000 expObjectConditional OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of an object that overrides whether the instance of expObjectID is to be considered usable. If the value of the object at expObjectConditional is 0 or not instantiated, the object at expObjectID is treated as if it is not instantiated. In other words, expObjectConditional is a filter that controls whether or not to use the value at expObjectID. The OID may be for a leaf object (e.g. sysObjectID.0) or may be wildcarded to match expObjectID. If expObject is wildcarded and expObjectID in the same row is not, the wild portion of expObjectConditional must match the wildcarding of the rest of the expression. If no object in the expression is wildcarded but expObjectConditional is, use the lexically first instance (if any) of expObjectConditional. If the value of expObjectConditional is 0.0 operation is as if the value pointed to by expObjectConditional is a non-zero (true) value. Note that expObjectConditional can not trivially use an object of syntax TruthValue, since the underlying value is not 0 or 1." DEFVAL { zeroDotZero } ::= { expObjectEntry 8 } expObjectConditionalWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectConditional of this row is a wildcard object. False indicates that expObjectConditional is fully instanced. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 9 } expObjectEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Kavasseri & Stewart Standards Track [Page 30] RFC 2982 Distributed Management Expression MIB October 2000 STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Objects in this table may be changed while expObjectEntryStatus is in any state." ::= { expObjectEntry 10 } -- -- Expression Value Table -- expValueTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of values from evaluated expressions." ::= { expValue 1 } expValueEntry OBJECT-TYPE SYNTAX ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single value from an evaluated expression. For a given instance, only one 'Val' object in the conceptual row will be instantiated, that is, the one with the appropriate type for the value. For values that contain no objects of expObjectSampleType 'deltaValue' or 'changedValue', reading a value from the table causes the evaluation of the expression for that value. For those that contain a 'deltaValue' or 'changedValue' the value read is as of the last sampling interval. If in the attempt to evaluate the expression one or more of the necessary objects is not available, the corresponding entry in this table is effectively not instantiated. To maintain security of MIB information, when creating a new row in this table, the managed system must record the security credentials of the requester. These security credentials are the parameters necessary as inputs to isAccessAllowed from [RFC2571]. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of that expression takes place under the Kavasseri & Stewart Standards Track [Page 31] RFC 2982 Distributed Management Expression MIB October 2000 security credentials of the creator of its expExpressionEntry. To maintain security of MIB information, expression evaluation must take place using security credentials for the implied Gets of the objects in the expression as inputs (conceptually) to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. These are the security credentials of the creator of the corresponding expExpressionEntry." INDEX { expExpressionOwner, expExpressionName, IMPLIED expValueInstance } ::= { expValueTable 1 } ExpValueEntry ::= SEQUENCE { expValueInstance OBJECT IDENTIFIER, expValueCounter32Val Counter32, expValueUnsigned32Val Unsigned32, expValueTimeTicksVal TimeTicks, expValueInteger32Val Integer32, expValueIpAddressVal IpAddress, expValueOctetStringVal OCTET STRING, expValueOidVal OBJECT IDENTIFIER, expValueCounter64Val Counter64 } expValueInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The final instance portion of a value's OID according to the wildcarding in instances of expObjectID for the expression. The prefix of this OID fragment is 0.0, leading to the following behavior. If there is no wildcarding, the value is 0.0.0. In other words, there is one value which standing alone would have been a scalar with a 0 at the end of its OID. If there is wildcarding, the value is 0.0 followed by a value that the wildcard can take, thus defining one value instance for each real, possible value of the wildcard. So, for example, if the wildcard worked out to be an ifIndex, there is an expValueInstance for each applicable ifIndex." ::= { expValueEntry 1 } expValueCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Kavasseri & Stewart Standards Track [Page 32] RFC 2982 Distributed Management Expression MIB October 2000 STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter32'." ::= { expValueEntry 2 } expValueUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'unsigned32'." ::= { expValueEntry 3 } expValueTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'timeTicks'." ::= { expValueEntry 4 } expValueInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'integer32'." ::= { expValueEntry 5 } expValueIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'ipAddress'." ::= { expValueEntry 6 } expValueOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..65536)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'octetString'." ::= { expValueEntry 7 } expValueOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only Kavasseri & Stewart Standards Track [Page 33] RFC 2982 Distributed Management Expression MIB October 2000 STATUS current DESCRIPTION "The value when expExpressionValueType is 'objectId'." ::= { expValueEntry 8 } expValueCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter64'." ::= { expValueEntry 9 } -- -- Conformance -- dismanExpressionMIBConformance OBJECT IDENTIFIER ::= { dismanExpressionMIB 3 } dismanExpressionMIBCompliances OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 1 } dismanExpressionMIBGroups OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 2 } -- Compliance dismanExpressionMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Expression MIB." MODULE -- this module MANDATORY-GROUPS { dismanExpressionResourceGroup, dismanExpressionDefinitionGroup, dismanExpressionValueGroup } OBJECT expResourceDeltaMinimum SYNTAX Integer32 (-1 | 60..600) DESCRIPTION "Implementation need not allow deltas or it may implement them and restrict them to higher values." OBJECT expObjectSampleType WRITE-SYNTAX INTEGER { absoluteValue(1) } DESCRIPTION "Implementation may disallow deltas calculation or Kavasseri & Stewart Standards Track [Page 34] RFC 2982 Distributed Management Expression MIB October 2000 change detection." OBJECT expObjectIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation may allow wildcards." OBJECT expObjectDiscontinuityIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow wildcards." OBJECT expObjectConditionalWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow deltas wildcards." ::= { dismanExpressionMIBCompliances 1 } -- Units of Conformance dismanExpressionResourceGroup OBJECT-GROUP OBJECTS { expResourceDeltaMinimum, expResourceDeltaWildcardInstanceMaximum, expResourceDeltaWildcardInstances, expResourceDeltaWildcardInstancesHigh, expResourceDeltaWildcardInstanceResourceLacks } STATUS current DESCRIPTION "Expression definition resource management." ::= { dismanExpressionMIBGroups 1 } dismanExpressionDefinitionGroup OBJECT-GROUP OBJECTS { expExpression, expExpressionValueType, expExpressionComment, expExpressionDeltaInterval, expExpressionPrefix, expExpressionErrors, expExpressionEntryStatus, expErrorTime, expErrorIndex, expErrorCode, expErrorInstance, Kavasseri & Stewart Standards Track [Page 35] RFC 2982 Distributed Management Expression MIB October 2000 expObjectID, expObjectIDWildcard, expObjectSampleType, expObjectDeltaDiscontinuityID, expObjectDiscontinuityIDWildcard, expObjectDiscontinuityIDType, expObjectConditional, expObjectConditionalWildcard, expObjectEntryStatus } STATUS current DESCRIPTION "Expression definition." ::= { dismanExpressionMIBGroups 2 } dismanExpressionValueGroup OBJECT-GROUP OBJECTS { expValueCounter32Val, expValueUnsigned32Val, expValueTimeTicksVal, expValueInteger32Val, expValueIpAddressVal, expValueOctetStringVal, expValueOidVal, expValueCounter64Val } STATUS current DESCRIPTION "Expression value." ::= { dismanExpressionMIBGroups 3 } END 4. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Kavasseri & Stewart Standards Track [Page 36] RFC 2982 Distributed Management Expression MIB October 2000 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 5. Acknowledgements This MIB contains considerable contributions from the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco who did the first implementation. 6. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Kavasseri & Stewart Standards Track [Page 37] RFC 2982 Distributed Management Expression MIB October 2000 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. [RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000. [PracPersp] Leinwand, A. and K. Fang, "Network Management: A Practical Perspective", Addison-Wesley Publishing Company, Inc., 1993. 7. Security Considerations Expression MIB security involves two perspectives: protection of expressions from tampering or unauthorized use of resources, and protection of the objects used to calculate the expressions. Kavasseri & Stewart Standards Track [Page 38] RFC 2982 Distributed Management Expression MIB October 2000 Security of expression definitions and results depends on the expression owner (expExpressionOwner). With view-based access control [RFC2575] a network manager can control who has what level of access to what expressions. Access control for the objects within the expression depends on the security credentials of the expression creator. These are the security credentials used to get the objects necessary to evaluate the expression. They are the security credentials that were used to set the expExpressionRowStatus object for that expression to 'active', as recorded by the managed system. This means that the results of an expression could potentially be made available to someone who does not have access to the raw data that went into them. This could be either legitimate or a security violation, depending on the specific situation and security policy. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2575 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. Kavasseri & Stewart Standards Track [Page 39] RFC 2982 Distributed Management Expression MIB October 2000 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 9. Editor's Address Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 EMail: ramk@cisco.com Kavasseri & Stewart Standards Track [Page 40] RFC 2982 Distributed Management Expression MIB October 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kavasseri & Stewart Standards Track [Page 41] snmp-mibs-downloader-1.1/mibrfcs/rfc3014.txt0000644000000000000000000013623711402176071015565 0ustar Network Working Group Editor of this version: Request for Comments: 3014 R. Kavasseri Category: Standards Track Cisco Systems, Inc. Author of previous version: B. Stewart November 2000 Notification Log MIB 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Kavasseri Standards Track [Page 1] RFC 3014 Notification Log MIB November 2000 Table of Contents 1 The SNMP Management Framework ................................. 2 2 Overview ...................................................... 3 2.1 Environment ................................................. 3 2.1.1 SNMP Engines and Contexts ................................. 4 2.1.2 Security .................................................. 4 2.2 Structure ................................................... 5 2.2.1 Configuration ............................................. 5 2.2.2 Statistics ................................................ 6 2.2.3 Log ....................................................... 6 2.3 Example ..................................................... 6 3 Definitions ................................................... 7 4 Intellectual Property ......................................... 23 5 References .................................................... 23 6 Security Considerations ....................................... 25 7 Author's Address .............................................. 25 8 Full Copyright Statement ...................................... 26 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. Kavasseri Standards Track [Page 2] RFC 3014 Notification Log MIB November 2000 o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs [RFC1905] that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to verify that they have not missed important Notifications. 2.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security Kavasseri Standards Track [Page 3] RFC 3014 Notification Log MIB November 2000 2.1.1. SNMP Engines and Contexts There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) is modeled here as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines. As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus, understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name. 2.1.2. Security Security for Notifications is awkward since access control for the objects in the Notification can be checked only where the Notification is created. Thus such checking is possible only for locally-generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC2573]. The Notification Log MIB has the notion of a "named log." By using log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security credentials of the creator stay associated with that log. Kavasseri Standards Track [Page 4] RFC 3014 Notification Log MIB November 2000 A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking. When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573]. The managed system SHOULD NOT apply access control when adding remotely-generated Notifications into either a named log or the default, null-named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself. The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e., it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of- service attack. Methods for countering such an attack are for further study. 2.2. Structure The MIB has the following sections: o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. 2.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends Kavasseri Standards Track [Page 5] RFC 3014 Notification Log MIB November 2000 on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table. 2.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration and resource problems. 2.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. 2.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active Note that snmpTraps is: iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 Kavasseri Standards Track [Page 6] RFC 3014 Notification Log MIB November 2000 Or numerically: 1.3.6.1.6.3.1.1.5 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. So to allow the two Notifications in snmpNotifyFilterTable: snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 = active snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 = active 3. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus, TAddress, TDomain FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "200011270000Z" -- 27 November 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps Kavasseri Standards Track [Page 7] RFC 3014 Notification Log MIB November 2000 and Informs." -- Revision History REVISION "200011270000Z" -- 27 November 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC 3014" ::= { mib-2 92 } notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- nlmConfigGlobalEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notification entries that may be held in nlmLogTable for all nlmLogNames added together. A particular setting does not guarantee that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications MUST be discarded to bring the log down to the new limit - thus the value of nlmConfigGlobalEntryLimit MUST take precedence over the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, even if the Notification being discarded has been present for fewer minutes than the value of nlmConfigGlobalAgeOut, or if the named log has fewer entries than that specified in nlmConfigLogEntryLimit. A value of 0 means no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfig 1 } nlmConfigGlobalAgeOut OBJECT-TYPE SYNTAX Unsigned32 Kavasseri Standards Track [Page 8] RFC 3014 Notification Log MIB November 2000 UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of minutes a Notification SHOULD be kept in a log before it is automatically removed. If an application changes the value of nlmConfigGlobalAgeOut, Notifications older than the new time MAY be discarded to meet the new time. A value of 0 means no age out. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 1440 } -- 24 hours ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries." ::= { nlmConfig 3 } nlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logging control entry. Depending on the entry's storage type entries may be supplied by the system or created and deleted by applications using nlmConfigLogEntryStatus." INDEX { nlmLogName } ::= { nlmConfigLogTable 1 } NlmConfigLogEntry ::= SEQUENCE { nlmLogName SnmpAdminString, nlmConfigLogFilterName SnmpAdminString, nlmConfigLogEntryLimit Unsigned32, nlmConfigLogAdminStatus INTEGER, Kavasseri Standards Track [Page 9] RFC 3014 Notification Log MIB November 2000 nlmConfigLogOperStatus INTEGER, nlmConfigLogStorageType StorageType, nlmConfigLogEntryStatus RowStatus } nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the log. An implementation may allow multiple named logs, up to some implementation-specific limit (which may be none). A zero-length log name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named logs." ::= { nlmConfigLogEntry 1 } nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A value of snmpNotifyFilterProfileName as used as an index into the snmpNotifyFilterTable in the SNMP Notification MIB, specifying the locally or remotely originated Notifications to be filtered out and not logged in this log. A zero-length value or a name that does not identify an existing entry in snmpNotifyFilterTable indicate no Notifications are to be logged in this log." DEFVAL { ''H } ::= { nlmConfigLogEntry 2 } nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of notification entries that can be held in nlmLogTable for this named log. A particular setting does not guarantee that that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. Kavasseri Standards Track [Page 10] RFC 3014 Notification Log MIB November 2000 A value of 0 indicates no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfigLogEntry 3 } nlmConfigLogAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Control to enable or disable the log without otherwise disturbing the log's entry. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { enabled } ::= { nlmConfigLogEntry 4 } nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this log: disabled administratively disabled operational administratively enabled and working noFilter administratively enabled but either nlmConfigLogFilterName is zero length or does not name an existing entry in snmpNotifyFilterTable" ::= { nlmConfigLogEntry 5 } nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." ::= { nlmConfigLogEntry 6 } nlmConfigLogEntryStatus OBJECT-TYPE Kavasseri Standards Track [Page 11] RFC 3014 Notification Log MIB November 2000 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. For non-null-named logs, the managed system records the security credentials from the request that sets nlmConfigLogStatus to 'active' and uses that identity to apply access control to the objects in the Notification to decide if that Notification may be logged." ::= { nlmConfigLogEntry 7 } -- -- Statistics Section -- nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put into the nlmLogTable. This counts a Notification once for each log entry, so a Notification put into multiple logs is counted multiple times." ::= { nlmStats 1 } nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStats 2 } -- -- Log Statistics Table -- nlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntry MAX-ACCESS not-accessible Kavasseri Standards Track [Page 12] RFC 3014 Notification Log MIB November 2000 STATUS current DESCRIPTION "A table of Notification log statistics entries." ::= { nlmStats 3 } nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { nlmStatsLogNotificationsLogged Counter32, nlmStatsLogNotificationsBumped Counter32 } nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in this named log." ::= { nlmStatsLogEntry 1 } nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded from this named log to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStatsLogEntry 2 } -- -- Log Section -- -- -- Log Table Kavasseri Standards Track [Page 13] RFC 3014 Notification Log MIB November 2000 -- nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not. Note that keeping entries across initializations of the management system leads to some confusion with counters and TimeStamps, since both of those are based on sysUpTime, which resets on management initialization. In this situation, counters apply only after the reset and nlmLogTime for entries made before the reset MUST be set to 0." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and pass filtering by nlmConfigLogFilterName and access control. They are removed to make way for new entries due to lack of resources or the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or nlmConfigLogEntryLimit. If adding an entry would exceed nlmConfigGlobalEntryLimit or system resources in general, the oldest entry in any log SHOULD be removed to make room for the new one. If adding an entry would exceed nlmConfigLogEntryLimit the oldest entry in that log SHOULD be removed to make room for the new one. Before the managed system puts a locally-generated Notification into a non-null-named log it assures that the creator of the log has access to the information in the Notification. If not it does not log that Notification in that log." INDEX { nlmLogName, nlmLogIndex } ::= { nlmLogTable 1 } Kavasseri Standards Track [Page 14] RFC 3014 Notification Log MIB November 2000 NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineTAddress TAddress, nlmLogEngineTDomain TDomain, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries within the named log. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry was placed in the log. If the entry occurred before the most recent management system initialization this object value MUST be set to zero." ::= { nlmLogEntry 2 } nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the entry was logged, instantiated only by systems that have date and time capability." ::= { nlmLogEntry 3 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the Notification Kavasseri Standards Track [Page 15] RFC 3014 Notification Log MIB November 2000 originated. If the log can contain Notifications from only one engine or the Trap is in SNMPv1 format, this object is a zero-length string." ::= { nlmLogEntry 4 } nlmLogEngineTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport service address of the SNMP engine from which the Notification was received, formatted according to the corresponding value of nlmLogEngineTDomain. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the log can contain Notifications from only one engine. Please be aware that the nlmLogEngineTAddress may not uniquely identify the SNMP engine from which the Notification was received. For example, if an SNMP engine uses DHCP or NAT to obtain ip addresses, the address it uses may be shared with other network devices, and hence will not uniquely identify the SNMP engine." ::= { nlmLogEntry 5 } nlmLogEngineTDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the kind of transport service by which a Notification was received from an SNMP engine. nlmLogEngineTAddress contains the transport service address of the SNMP engine from which this Notification was received. Possible values for this object are presently found in the Transport Mappings for SNMPv2 document (RFC 1906 [8])." ::= { nlmLogEntry 6 } nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION Kavasseri Standards Track [Page 16] RFC 3014 Notification Log MIB November 2000 "If the Notification was received in a protocol which has a contextEngineID element like SNMPv3, this object has that value. Otherwise its value is a zero-length string." ::= { nlmLogEntry 7 } nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. For SNMPv1 Traps this is the community string from the Trap." ::= { nlmLogEntry 8 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifier of the Notification that occurred." ::= { nlmLogEntry 9 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { Kavasseri Standards Track [Page 17] RFC 3014 Notification Log MIB November 2000 nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64, nlmLogVariableOpaqueVal Opaque } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification." ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow must be instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Kavasseri Standards Track [Page 18] RFC 3014 Notification Log MIB November 2000 "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'unsigned32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'. Although this seems to be unfriendly for IPv6, we have to recognize that there are a number of older MIBs that do contain an IPv4 format address, known as IpAddress. IPv6 addresses are represented using TAddress or InetAddress, and so the underlying datatype is Kavasseri Standards Track [Page 19] RFC 3014 Notification Log MIB November 2000 OCTET STRING, and their value would be stored in the nlmLogVariableOctetStringVal column." ::= { nlmLogVariableEntry 9 } nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } nlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'opaque'." ::= { nlmLogVariableEntry 12 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module Kavasseri Standards Track [Page 20] RFC 3014 Notification Log MIB November 2000 MANDATORY-GROUPS { notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named logs." GROUP notificationLogDateGroup DESCRIPTION "This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, nlmConfigLogFilterName, nlmConfigLogEntryLimit, nlmConfigLogAdminStatus, nlmConfigLogOperStatus, nlmConfigLogStorageType, nlmConfigLogEntryStatus } Kavasseri Standards Track [Page 21] RFC 3014 Notification Log MIB November 2000 STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsGlobalNotificationsLogged, nlmStatsGlobalNotificationsBumped, nlmStatsLogNotificationsLogged, nlmStatsLogNotificationsBumped } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogEngineTAddress, nlmLogEngineTDomain, nlmLogContextEngineID, nlmLogContextName, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, nlmLogVariableCounter64Val, nlmLogVariableOpaqueVal } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current Kavasseri Standards Track [Page 22] RFC 3014 Notification Log MIB November 2000 DESCRIPTION "Conditionally mandatory notification log data. This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBGroups 4 } END 4. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 5. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Kavasseri Standards Track [Page 23] RFC 3014 Notification Log MIB November 2000 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. Kavasseri Standards Track [Page 24] RFC 3014 Notification Log MIB November 2000 6. Security Considerations Security issues are discussed in Section 3.1.2. 7. Authors' Addresses Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 EMail: ramk@cisco.com Kavasseri Standards Track [Page 25] RFC 3014 Notification Log MIB November 2000 8. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kavasseri Standards Track [Page 26] snmp-mibs-downloader-1.1/mibrfcs/rfc3019.txt0000644000000000000000000006720511402176071015570 0ustar Network Working Group B. Haberman Request for Comments: 3019 Nortel Networks Category: Standards Track R. Worzella IBM January 2001 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [RFC2710]. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: An overall architecture, described in RFC 2571 [RFC2571]. Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, Haberman & Worzella Standards Track [Page 1] RFC 3019 MIB for MLD January 2001 RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine-readable information is not considered to change the semantics of the MIB. 2. Overview This MIB module contains two tables: 1. The MLD Interface Table, which contains one row for each interface on which MLD is enabled. Haberman & Worzella Standards Track [Page 2] RFC 3019 MIB for MLD January 2001 2. The MLD Cache Table which contains one row for each IPv6 Multicast group for which there are members on a particular interface. Both tables are intended to be implemented by hosts and routers. Some objects in each table apply to routers only. 3. Definitions IPV6-MLD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Unsigned32, TimeTicks, mib-2 FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC InetAddressIPv6 FROM INET-ADDRESS-MIB InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; mldMIB MODULE-IDENTITY LAST-UPDATED "200101250000Z" -- 25 Jan 2001 ORGANIZATION "IETF IPNGWG Working Group." CONTACT-INFO " Brian Haberman Nortel Networks 4309 Emperor Blvd. Durham, NC 27703 USA Phone: +1 919 992 4439 e-mail: haberman@nortelnetworks.com" DESCRIPTION "The MIB module for MLD Management." REVISION "200101250000Z" -- 25 Jan 2001 DESCRIPTION "Initial version, published as RFC 3019." ::= { mib-2 91 } mldMIBObjects OBJECT IDENTIFIER ::= { mldMIB 1 } -- -- The MLD Interface Table -- mldInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF MldInterfaceEntry Haberman & Worzella Standards Track [Page 3] RFC 3019 MIB for MLD January 2001 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interfaces on which MLD is enabled." ::= { mldMIBObjects 1 } mldInterfaceEntry OBJECT-TYPE SYNTAX MldInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an interface on which MLD is enabled." INDEX { mldInterfaceIfIndex } ::= { mldInterfaceTable 1 } MldInterfaceEntry ::= SEQUENCE { mldInterfaceIfIndex InterfaceIndex, mldInterfaceQueryInterval Unsigned32, mldInterfaceStatus RowStatus, mldInterfaceVersion Unsigned32, mldInterfaceQuerier InetAddressIPv6, mldInterfaceQueryMaxResponseDelay Unsigned32, mldInterfaceJoins Counter32, mldInterfaceGroups Gauge32, mldInterfaceRobustness Unsigned32, mldInterfaceLastListenQueryIntvl Unsigned32, mldInterfaceProxyIfIndex InterfaceIndexOrZero, mldInterfaceQuerierUpTime TimeTicks, mldInterfaceQuerierExpiryTime TimeTicks } mldInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The internetwork-layer interface value of the interface for which MLD is enabled." ::= { mldInterfaceEntry 1 } mldInterfaceQueryInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current Haberman & Worzella Standards Track [Page 4] RFC 3019 MIB for MLD January 2001 DESCRIPTION "The frequency at which MLD Host-Query packets are transmitted on this interface." DEFVAL { 125 } ::= { mldInterfaceEntry 2 } mldInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The activation of a row enables MLD on the interface. The destruction of a row disables MLD on the interface." ::= { mldInterfaceEntry 3 } mldInterfaceVersion OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The version of MLD which is running on this interface. This object is a place holder to allow for new versions of MLD to be introduced. Version 1 of MLD is defined in RFC 2710." DEFVAL { 1 } ::= { mldInterfaceEntry 4 } mldInterfaceQuerier OBJECT-TYPE SYNTAX InetAddressIPv6 (SIZE (16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the MLD Querier on the IPv6 subnet to which this interface is attached." ::= { mldInterfaceEntry 5 } mldInterfaceQueryMaxResponseDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum query response time advertised in MLD queries on this interface." DEFVAL { 10 } ::= { mldInterfaceEntry 6 } mldInterfaceJoins OBJECT-TYPE Haberman & Worzella Standards Track [Page 5] RFC 3019 MIB for MLD January 2001 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a group membership has been added on this interface; that is, the number of times an entry for this interface has been added to the Cache Table. This object gives an indication of the amount of MLD activity over time." ::= { mldInterfaceEntry 7 } mldInterfaceGroups OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries for this interface in the Cache Table." ::= { mldInterfaceEntry 8 } mldInterfaceRobustness OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Robustness Variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the Robustness Variable may be increased. MLD is robust to (Robustness Variable-1) packet losses. The discussion of the Robustness Variable is in Section 7.1 of RFC 2710." DEFVAL { 2 } ::= { mldInterfaceEntry 9 } mldInterfaceLastListenQueryIntvl OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Last Member Query Interval is the Max Response Delay inserted into Group-Specific Queries sent in response to Leave Group messages, and is also the amount of time between Group-Specific Query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group." DEFVAL { 1 } Haberman & Worzella Standards Track [Page 6] RFC 3019 MIB for MLD January 2001 ::= { mldInterfaceEntry 10 } mldInterfaceProxyIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Some devices implement a form of MLD proxying whereby memberships learned on the interface represented by this row, cause MLD Multicast Listener Reports to be sent on the internetwork-layer interface identified by this object. Such a device would implement mldRouterMIBGroup only on its router interfaces (those interfaces with non-zero mldInterfaceProxyIfIndex). Typically, the value of this object is 0, indicating that no proxying is being done." DEFVAL { 0 } ::= { mldInterfaceEntry 11 } mldInterfaceQuerierUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since mldInterfaceQuerier was last changed." ::= { mldInterfaceEntry 12 } mldInterfaceQuerierExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the Other Querier Present Timer expires. If the local system is the querier, the value of this object is zero." ::= { mldInterfaceEntry 13 } -- -- The MLD Cache Table -- mldCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MldCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the IPv6 multicast Haberman & Worzella Standards Track [Page 7] RFC 3019 MIB for MLD January 2001 groups for which there are members on a particular interface." ::= { mldMIBObjects 2 } mldCacheEntry OBJECT-TYPE SYNTAX MldCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mldCacheTable." INDEX { mldCacheAddress, mldCacheIfIndex } ::= { mldCacheTable 1 } MldCacheEntry ::= SEQUENCE { mldCacheAddress InetAddressIPv6, mldCacheIfIndex InterfaceIndex, mldCacheSelf TruthValue, mldCacheLastReporter InetAddressIPv6, mldCacheUpTime TimeTicks, mldCacheExpiryTime TimeTicks, mldCacheStatus RowStatus } mldCacheAddress OBJECT-TYPE SYNTAX InetAddressIPv6 (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 multicast group address for which this entry contains information." ::= { mldCacheEntry 1 } mldCacheIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The internetwork-layer interface for which this entry contains information for an IPv6 multicast group address." ::= { mldCacheEntry 2 } mldCacheSelf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether the local system is a member of Haberman & Worzella Standards Track [Page 8] RFC 3019 MIB for MLD January 2001 this group address on this interface." DEFVAL { true } ::= { mldCacheEntry 3 } mldCacheLastReporter OBJECT-TYPE SYNTAX InetAddressIPv6 (SIZE (16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 address of the source of the last membership report received for this IPv6 Multicast group address on this interface. If no membership report has been received, this object has the value 0::0." ::= { mldCacheEntry 4 } mldCacheUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time elapsed since this entry was created." ::= { mldCacheEntry 5 } mldCacheExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum amount of time remaining before this entry will be aged out. A value of 0 indicates that the entry is only present because mldCacheSelf is true and that if the router left the group, this entry would be aged out immediately. Note that some implementations may process Membership Reports from the local system in the same way as reports from other hosts, so a value of 0 is not required." ::= { mldCacheEntry 6 } mldCacheStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or existing entries deleted from this table." ::= { mldCacheEntry 7 } Haberman & Worzella Standards Track [Page 9] RFC 3019 MIB for MLD January 2001 -- conformance information mldMIBConformance OBJECT IDENTIFIER ::= { mldMIB 2 } mldMIBCompliances OBJECT IDENTIFIER ::= { mldMIBConformance 1 } mldMIBGroups OBJECT IDENTIFIER ::= { mldMIBConformance 2 } -- compliance statements mldHostMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts running MLD and implementing the MLD MIB." MODULE -- this module MANDATORY-GROUPS { mldBaseMIBGroup, mldHostMIBGroup } OBJECT mldInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mldMIBCompliances 1 } mldRouterMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers running MLD and implementing the MLD MIB." MODULE -- this module MANDATORY-GROUPS { mldBaseMIBGroup, mldRouterMIBGroup } OBJECT mldInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mldMIBCompliances 2 } -- units of conformance Haberman & Worzella Standards Track [Page 10] RFC 3019 MIB for MLD January 2001 mldBaseMIBGroup OBJECT-GROUP OBJECTS { mldCacheSelf, mldCacheStatus, mldInterfaceStatus } STATUS current DESCRIPTION "The basic collection of objects providing management of MLD. The mldBaseMIBGroup is designed to allow for the manager creation and deletion of MLD cache entries." ::= { mldMIBGroups 1 } mldRouterMIBGroup OBJECT-GROUP OBJECTS { mldCacheUpTime, mldCacheExpiryTime, mldInterfaceQueryInterval, mldInterfaceJoins, mldInterfaceGroups, mldCacheLastReporter, mldInterfaceQuerierUpTime, mldInterfaceQuerierExpiryTime, mldInterfaceQuerier, mldInterfaceVersion, mldInterfaceQueryMaxResponseDelay, mldInterfaceRobustness, mldInterfaceLastListenQueryIntvl } STATUS current DESCRIPTION "A collection of additional objects for management of MLD in routers." ::= { mldMIBGroups 2 } mldHostMIBGroup OBJECT-GROUP OBJECTS { mldInterfaceQuerier } STATUS current DESCRIPTION "A collection of additional objects for management of MLD in hosts." ::= { mldMIBGroups 3 } mldProxyMIBGroup OBJECT-GROUP OBJECTS { mldInterfaceProxyIfIndex } STATUS current DESCRIPTION "A collection of additional objects for management of MLD proxy devices." Haberman & Worzella Standards Track [Page 11] RFC 3019 MIB for MLD January 2001 ::= { mldMIBGroups 4 } END Security Considerations This MIB contains readable objects whose values provide information related to multicast sessions. Some of these objects could contain sensitive information. In particular, the mldCacheSelf and mldCacheLastReporter could be used to identify machines which are listening to a given group address. There are also a number of objects that have a MAX-ACCESS clause of read-write and/or read- create, which allow an administrator to configure MLD in the router. While unauthorized access to the readable objects is relatively innocuous, unauthorized access to the write-able objects could cause a denial of service. Hence, the support of SET operations in a non- secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the network is allowed to access and SET (change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. Acknowledgements This MIB module is based on the IGMP MIB authored by Keith McCloghrie, Dino Farinacci, and Dave Thaler. It was updated based on feedback from the IPNGWG working group, Bert Wijnen, Peder Norgaard, and extensive comments from Juergen Schoenwaelder. Haberman & Worzella Standards Track [Page 12] RFC 3019 MIB for MLD January 2001 References [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. Haberman & Worzella Standards Track [Page 13] RFC 3019 MIB for MLD January 2001 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. Authors' Addresses Brian Haberman Nortel Networks 4309 Emperor Blvd. Suite 200 Durham, NC 27703 USA Phone: +1-919-992-4439 EMail: haberman@nortelnetworks.com Randy Worzella IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA Phone: +1-919-254-2202 EMail: worzella@us.ibm.com Haberman & Worzella Standards Track [Page 14] RFC 3019 MIB for MLD January 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Haberman & Worzella Standards Track [Page 15] snmp-mibs-downloader-1.1/mibrfcs/rfc3020.txt0000644000000000000000000020423011402176071015547 0ustar Network Working Group P. Pate Request for Comments: 3020 B. Lynch Category: Standards Track Overture Networks K. Rehbehn Megisto Systems, Inc. December 2000 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also includes conformance and notification information. Table of Contents 1 The SNMP Management Framework ................................ 2 2 Overview ..................................................... 3 2.1 Multilink Frame Relay Background ........................... 3 2.1.1 Terminology .............................................. 4 2.1.2 Reference Model .......................................... 5 2.2 Structure of the MIB ....................................... 5 2.2.1 mfrBundleMaxNumBundles ................................... 6 2.2.2 mfrBundleNextIndex ....................................... 6 2.2.3 mfrBundleTable ........................................... 6 2.2.4 Bundle-to-ifIndex Mapping Table .......................... 6 2.2.5 mfrBundleLinkTable ....................................... 6 2.3 Relationship With Other MIBS and Tables .................... 7 2.3.1 Relationship With Interface Table ........................ 7 2.3.1.1 Bundle Links ........................................... 7 2.3.1.2 Bundles ................................................ 7 Pate, et al. Standards Track [Page 1] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 2.3.1.3 Mapping Between ifIndex and mfrBundleIndex ............. 8 2.3.1.4 ifTable Objects ........................................ 8 2.3.2 Relationship With Interface Stack Table .................. 9 2.3.3 Relationship With Frame Relay DTE MIB .................... 9 2.3.4 Relationship With Frame Relay Service MIB ................ 9 2.3.5 Example .................................................. 9 2.4 Creation Of Bundles and Bundle Links ....................... 11 2.4.1 Creation Of Bundles ...................................... 11 2.4.2 Creation Of Bundle Links ................................. 11 2.5 Notifications .............................................. 11 2.5.1 Bundle ................................................... 11 2.5.1.1 linkUp ................................................. 12 2.5.1.2 linkDown ............................................... 12 2.5.2 Bundle Link .............................................. 12 2.5.2.1 linkUp ................................................. 12 2.5.2.2 linkDown ............................................... 12 2.5.2.3 mfrMibTrapBundleLinkMismatch ........................... 12 3 Object Definitions ........................................... 13 4 Acknowledgments .............................................. 32 5 References ................................................... 32 6 Security Considerations ...................................... 34 7 Authors' Addresses ........................................... 35 8 Full Copyright Statement ..................................... 36 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58: RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. Pate, et al. Standards Track [Page 2] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview This document defines a Management Information Base (MIB) for monitoring and controlling the UNI/NNI Multilink Frame Relay function. The agreement on which this MIB is based was defined and documented by the Frame Relay Forum in the Frame Relay Forum Document FRF.16 [FRF.16]. 2.1. Multilink Frame Relay Background Multilink Frame Relay (MFR) for the User-to-Network Interface (UNI) and the Network-to-Network Interface (NNI) provides physical interface emulation for frame relay devices. The emulated physical interface consists of one or more physical links, called "bundle links", aggregated together into a single "bundle" of bandwidth. This service provides a frame-based inverse multiplexing function, sometimes referred to as an "IMUX". Pate, et al. Standards Track [Page 3] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 The bundle provides the same order-preserving service as a physical layer for frames sent on a data link connection. In addition, the bundle provides support for all Frame Relay services based on UNI and NNI standards. 2.1.1. Terminology Physical Link -- A single physical interface that interconnects two devices in a frame relay network (e.g., DS1, DS0, Bearer channel, refer to FRF.14). Bundle -- A grouping of one or more physical links using the formats and procedures of multilink frame relay. The bundle operates as a logical interface function that emulates a single physical interface to the Q.922 data link layer. Bundle Link -- A MFR sub-component that controls operation of one of the bundle's physical links. Pate, et al. Standards Track [Page 4] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 2.1.2. Reference Model +--------------------------+ +--------------------------+ | Switching Layer -OR- | | Switching Layer -OR- | | Higher-Level Applications| | Higher-Level Applications| +--------------------------+ +--------------------------+ | |C-Plane - Q.933| | |C-Plane - Q.933| | U-Plane | (Note 1) | | U-Plane | (Note 1) | | (Note 3) |---------------| | (Note 3) |---------------| | |Q.922 (Note 2) | | |Q.922 (Note 2) | +--------------------------+ +--------------------------+ | Data Link Layer (Q.922) | | Data Link Layer (Q.922) | +--------------------------+ +--------------------------+ | Bundle (B) | | Bundle (B) | +--------------------------+ +--------------------------+ | Bundle | Bundle | Bundle | | Bundle | Bundle | Bundle | | Link | Link | Link | | Link | Link | Link | | (BL) | (BL) | (BL) | | (BL) | (BL) | (BL) | +--------+--------+--------+ +--------+--------+--------+ |Physical|Physical|Physical| |Physical|Physical|Physical| | (PH) | (PH) | (PH) | __________ | (PH) | (PH) | (PH) | +----+---+----+---+----+---+ /\ \ +----+---+----+---+----+---+ | | | / \ \ | | | | | +--------\ \-----+ | | | | / \ \ | | | +-------------------\ \------------+ | | _________\_______/ Bundle /_ | | /\ / / \ | +------------| Bundle Link / / |------------------+ \/_____________/ /____/ \/__________/ Figure 1: MFR Reference Diagram Note 1: C-Plane operation as described in Q.933 [Q.933] and FRF.4 [FRF.4] Note 2: Multiple frame acknowledged information transfer mode as described in Q.922 [Q.922] Note 3: Core aspects for use with frame relay bearer service as described in Q.922, Annex A [Q.922] 2.2. Structure of the MIB The UNI/NNI MFR managed objects consist of two scalar objects and three tables. Pate, et al. Standards Track [Page 5] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 2.2.1. mfrBundleMaxNumBundles This scalar is used to inform the manager of the maximum number of bundles supported by this device. 2.2.2. mfrBundleNextIndex This scalar is used to assist the manager in selecting a value for mfrBundleIndex during row creation. It can also be used to avoid race conditions with multiple managers trying to create rows in the table (see RFC 2494 [RFC2494] for one such algorithm). 2.2.3. mfrBundleTable This table provides a means to configure and monitor bundles. It is indexed by mfrBundleIndex and contains these columns: - mfrBundleIndex Integer32 - mfrBundleIfIndex InterfaceIndex - mfrBundleRowStatus RowStatus - mfrBundleNearEndName SnmpAdminString - mfrBundleFragmentation INTEGER - mfrBundleMaxFragSize Integer32 - mfrBundleTimerHello INTEGER - mfrBundleTimerAck INTEGER - mfrBundleCountMaxRetry INTEGER - mfrBundleActivationClass INTEGER - mfrBundleThreshold Integer32 - mfrBundleMaxDiffDelay Integer32 - mfrBundleSeqNumSize INTEGER - mfrBundleLinksConfigured Integer32 - mfrBundleLinksActive Integer32 - mfrBundleBandwidth Integer32 - mfrBundleFarEndName SnmpAdminString - mfrBundleResequencingErrors Counter32 2.2.4. Bundle-to-ifIndex Mapping Table This table provides a means to take an ifIndex and find the corresponding mfrBundleIndex. It is indexed by ifIndex and contains these columns: - mfrBundleIfIndexMapping Integer32 2.2.5. mfrBundleLinkTable This table provides a means to configure and monitor bundle links. It is indexed by ifIndex and contains these columns: Pate, et al. Standards Track [Page 6] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 - mfrBundleLinkRowStatus RowStatus - mfrBundleLinkConfigBundleIndex Integer32 - mfrBundleLinkNearEndName SnmpAdminString - mfrBundleLinkState MfrBundleLinkState - mfrBundleLinkFarEndName SnmpAdminString - mfrBundleLinkFarEndBundleName SnmpAdminString - mfrBundleLinkDelay Integer32 - mfrBundleLinkFramesControlTx Counter32 - mfrBundleLinkFramesControlRx Counter32 - mfrBundleLinkFramesControlInvalid Counter32 - mfrBundleLinkTimerExpiredCount Counter32 - mfrBundleLinkLoopbackSuspected Counter32 - mfrBundleLinkUnexpectedSequence Counter32 - mfrBundleLinkMismatch Counter32 2.3. Relationship With Other MIBS and Tables 2.3.1. Relationship With Interface Table 2.3.1.1. Bundle Links Each bundle link will appear as an interface in the ifTable. The ifIndex that appears in the ifTable is used for indexing the bundle link tables in the UNI-NNI MFR MIB. 2.3.1.2. Bundles Each bundle will appear as an interface in the ifTable. There will be corresponding mfrBundleIndex which may be different than the ifIndex of the bundle. The reason is best summarized in RFC 2494 [RFC2494], which describes frame relay bundle of DS0. It says: This table is not indexed by ifIndex because the manager has to choose the index in a createable row and the agent must be allowed to select ifIndex values. The rows in the ifEntry table are not createable as they do not have row status. RFC 2863 [RFC2863] suggests that the ifIndex should be chosen by the agent. Here is its statement regarding row creation and deletion: While some interfaces, for example, most physical interfaces, cannot be created via network management, other interfaces such as logical interfaces sometimes can be. The ifTable contains only generic information about an interface. Almost all 'create-able' interfaces have other, media-specific, information through which Pate, et al. Standards Track [Page 7] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 configuration parameters may be supplied prior to creating such an interface. Thus, the ifTable does not itself support the creation or deletion of an interface (specifically, it has no RowStatus column). Rather, if a particular interface type supports the dynamic creation and/or deletion of an interface of that type, then that media-specific MIB should include an appropriate RowStatus object (see the ATM LAN-Emulation Client MIB [ATMLANE] for an example of a MIB which does this). Typically, when such a RowStatus object is created/deleted, then the conceptual row in the ifTable appears/disappears as a by-product, and an ifIndex value (chosen by the agent) is stored in an appropriate object in the media-specific MIB. The ATM LAN-Emulation Client MIB [ATMLANE] uses different indices and so does the IMA MIB [ATMIMA]. Looking at the examples we have, and the statements from RFC, it seems better to have two indices. This gives the SNMP agent implementor the freedom to manage their ifIndex in the way they like. 2.3.1.3. Mapping Between ifIndex and mfrBundleIndex The mfrBundleIfIndexMappingTable is indexed by ifIndex and provides the means to map a given ifIndex into the corresponding mfrBundleIndex. The mfrBundleIfIndexMapping object in the mfrBundleTable (indexed by mfrBundleIndex) provides the reverse mapping of a mfrBundleIndex to the corresponding ifIndex in the ifTable. 2.3.1.4. ifTable Objects The bundle configuration and status table. There is a one-to-one correspondence between a bundle and an interface represented in the ifTable. The following objects of the ifTable have specific meaning for an MFR bundle: ifAdminStatus - the bundle admin status ifOperStatus - the bundle operational status ifSpeed - the current bandwidth of the bundle ifInUcastPkts - the number of frames received on the bundle ifOutUcastPkts - the number of frames transmitted on the bundle ifInErrors - frame (not fragment) errors ifOutErrors - frame (not fragment) errors The following objects of the ifTable have specific meaning for an MFR bundle link: Pate, et al. Standards Track [Page 8] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 ifAdminStatus - the bundle link admin status ifOperStatus - the bundle link operational status ifSpeed - the bandwidth of the bundle link interface ifInUcastPkts - the number of frames received on the bundle link ifOutUcastPkts - the number of frames transmitted on the bundle link ifInErrors - frame and fragment errors ifOutErrors - frame and fragment errors 2.3.2. Relationship With Interface Stack Table The bundles and bundle links will appear in the ifStackTable defined in RFC 2863 [RFC2863]. Each bundle link will appear a lower layer to its owner bundle. The bundle will appear as a higher layer to the bundle links and as a lower layer to a frame relay service or UNI. 2.3.3. Relationship With Frame Relay DTE MIB The bundle will have a one-to-one correspondence with a DLCMI or UNI that appear in the DTE MIB tables [RFC2115]. 2.3.4. Relationship With Frame Relay Service MIB There is a one-to-one relationship between the MFR bundle and the frame relay service logical port defined in RFC1604 [RFC1604]. 2.3.5. Example Figure two shows an example of how the various tables are related. This example shows two bundles composed of 2 T1s each. The bundles have a mfrBundleIndex of 10 and 20 respectively. +-------------------------+ | Frame Relay Service | +-----+-------------+-----+ | | +-----+------+------+-----+ | MFR Bundle | MFR Bundle | | 10 | 20 | +--+-----+---+---+-----+--+ | | | | +-+-+ +-+-+ +-+-+ +-+-+ |T1 | |T1 | |T1 | |T1 | +---+ +---+ +-+-+ +---+ Figure 2: Frame Relay Service Being Carried on 4 T1s Pate, et al. Standards Track [Page 9] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 The assignment of the ifTable index values could for example be: ifIndex | Description | ifType --------+----------------------------+---------------------- 1 | FrameRelayService | frameRelayService(44) 2 | MFR Bundle #10 | frf16MfrBundle(163) 3 | MFR Bundle #20 | frf16MfrBundle(163) 4 | ds1 #1/MFR Bundle Link #1 | ds1(18) 5 | ds1 #2/MFR Bundle Link #2 | ds1(18) 6 | ds1 #3/MFR Bundle Link #3 | ds1(18) 7 | ds1 #4/MFR Bundle Link #4 | ds1(18) The ifStackTable is then used to show the relationships between the various interfaces. HigherLayer | LowerLayer ------------+----------- 0 | 1 1 | 2 1 | 3 2 | 4 2 | 5 3 | 6 3 | 7 4 | 0 5 | 0 6 | 0 7 | 0 The mfrBundleIfIndexMappingTable shows the relationship between the ifTable ifIndex and the mfrBundleIndex: ifIndex | mfrBundleIfIndexMappingIndex --------+----------------------------- 2 | 10 3 | 20 The mfrBundleTable shows the relationship between the mfrBundleIndex and the ifIndex: mfrBundleIndex | mfrBundleIfIndex ---------------+----------------- 10 | 2 20 | 3 Pate, et al. Standards Track [Page 10] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 The mfrBundleLinkTable shows the relationship between the bundles and bundle links: mfrBundleIndex | mfrBundleLinkIfIndex ---------------+--------------------- 10 | 4 10 | 5 20 | 6 20 | 7 2.4. Creation Of Bundles and Bundle Links 2.4.1. Creation Of Bundles A new bundle is created by setting a createAndGo(4) value in the mfrBundleRowStatus RowStatus object. Optionally, an agent could also support setting a value of createAndWait(5) followed by a set to the value active(1). When a bundle is created, the agent must create a new interface in the ifTable. The ifIndex for this new interface is used for the value of mfrBundleIfIndex. 2.4.2. Creation Of Bundle Links A new bundle link is created by setting a createAndGo(4) value in the mfrBundleLinkRowStatus RowStatus object. The bundle link is associated with a specific physical interface and uses the ifIndex of the physical interface. The mfrBundleLinkEntry row objects may be created after or during creation of the physical interface's ifEntry row objects. The bundle identified in the object mfrBundleIndex must exist at time of bundle link creation. 2.5. Notifications The linkUp and linkDown traps are defined in RFC 2223 [RFC2223]. 2.5.1. Bundle The following SNMP traps are defined for MFR bundles. Pate, et al. Standards Track [Page 11] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 2.5.1.1. linkUp This trap is sent when the ifOperStatus of a bundle transitions from down to up. This occurs when a sufficient number of links (determined by mfrBundleActivationClass and mfrBundleThreshold) are in the operationally up state. 2.5.1.2. linkDown This trap is sent when the ifOperStatus of a bundle transitions from up to down. This occurs when a insufficient number of links (determined by mfrBundleActivationClass and mfrBundleThreshold) are in the operationally up state. 2.5.2. Bundle Link The following SNMP traps are defined for MFR bundle links. 2.5.2.1. linkUp This trap is sent when a mfrBundleLinkState object transitions to the value mfrBundleLinkStateUp. 2.5.2.2. linkDown This trap is sent when a mfrBundleLinkState object transitions from the value mfrBundleLinkStateUp. 2.5.2.3. mfrMibTrapBundleLinkMismatch This trap indicates that a bundle link mismatch has been detected. The following objects are reported: - mfrBundleNearEndName: configured name of near end bundle - mfrBundleFarEndName: previously reported name of far end bundle - mfrBundleLinkNearEndName: configured name of near end bundle - mfrBundleLinkFarEndName: reported name of far end bundle - mfrBundleLinkFarEndBundleName: currently reported name of far end bundle Note that the configured items may have been configured automatically. Note also that the mfrBundleLinkMismatch counter is incremented when the trap is sent. Pate, et al. Standards Track [Page 12] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 3. 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. FR-MFR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, NOTIFICATION-TYPE, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION, TestAndIncr, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB InterfaceIndex, ifIndex FROM IF-MIB; mfrMib MODULE-IDENTITY LAST-UPDATED "200011300000Z" ORGANIZATION "IETF Frame Relay Service MIB (frnetmib) Working Group" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/frnetmib-charter.html WG-email: frnetmib@sunroof.eng.sun.com Subscribe: frnetmib-request@sunroof.eng.sun.com Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib Chair: Andy Malis Vivace Networks Email: Andy.Malis@vivacenetworks.com WG editor: Prayson Pate Overture Networks Email: prayson.pate@overturenetworks.com Co-author: Bob Lynch Overture Networks Pate, et al. Standards Track [Page 13] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 EMail: bob.lynch@overturenetworks.com Co-author: Kenneth Rehbehn Megisto Systems, Inc. EMail: krehbehn@megisto.com" DESCRIPTION "This is the MIB used to control and monitor the multilink frame relay (MFR) function described in FRF.16." -- --------------------------------------------------------- -- --------------------------------------------------------- -- Revision History -- --------------------------------------------------------- -- --------------------------------------------------------- REVISION "200011300000Z" DESCRIPTION "Published as RFC 3020." ::= { transmission 47 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Textual Conventions -- --------------------------------------------------------- -- --------------------------------------------------------- MfrBundleLinkState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The possible states for a bundle link, as defined in Annex A of FRF.16." REFERENCE "FRF.16 Annex A" SYNTAX INTEGER { mfrBundleLinkStateAddSent (1), mfrBundleLinkStateAddRx (2), mfrBundleLinkStateAddAckRx (3), mfrBundleLinkStateUp (4), mfrBundleLinkStateIdlePending (5), mfrBundleLinkStateIdle (6), mfrBundleLinkStateDown (7), mfrBundleLinkStateDownIdle (8) } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Object Identifiers Pate, et al. Standards Track [Page 14] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 -- --------------------------------------------------------- -- --------------------------------------------------------- mfrMibScalarObjects OBJECT IDENTIFIER ::= { mfrMib 1 } mfrMibBundleObjects OBJECT IDENTIFIER ::= { mfrMib 2 } mfrMibBundleLinkObjects OBJECT IDENTIFIER ::= { mfrMib 3 } mfrMibTraps OBJECT IDENTIFIER ::= { mfrMib 4 } mfrMibConformance OBJECT IDENTIFIER ::= { mfrMib 5 } mfrMibTrapsPrefix OBJECT IDENTIFIER ::= { mfrMibTraps 0 } mfrMibGroups OBJECT IDENTIFIER ::= { mfrMibConformance 1 } mfrMibCompliances OBJECT IDENTIFIER ::= { mfrMibConformance 2 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Scalars -- --------------------------------------------------------- -- --------------------------------------------------------- mfrBundleMaxNumBundles OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to inform the manager of the maximum number of bundles supported by this device." ::= { mfrMibScalarObjects 1 } mfrBundleNextIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assist the manager in selecting a value for mfrBundleIndex during row creation in the mfrBundleTable. It can also be used to avoid race conditions with multiple managers trying to create rows in the table (see RFC 2494 [RFC2494] for one such alogrithm)." REFERENCE "RFC 2494" ::= { mfrMibScalarObjects 2 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Bundle Table -- --------------------------------------------------------- -- --------------------------------------------------------- Pate, et al. Standards Track [Page 15] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 mfrBundleTable OBJECT-TYPE SYNTAX SEQUENCE OF MfrBundleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The bundle configuration and status table. There is a one-to-one correspondence between a bundle and an interface represented in the ifTable. The following objects of the ifTable have specific meaning for an MFR bundle: ifAdminStatus - the bundle admin status ifOperStatus - the bundle operational status ifSpeed - the current bandwidth of the bundle ifInUcastPkts - the number of frames received on the bundle ifOutUcastPkts - the number of frames transmitted on the bundle ifInErrors - frame (not fragment) errors ifOutErrors - frame (not fragment) errors " ::= { mfrMibBundleObjects 3 } mfrBundleEntry OBJECT-TYPE SYNTAX MfrBundleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the bundle table." INDEX { mfrBundleIndex } ::= { mfrBundleTable 1 } MfrBundleEntry ::= SEQUENCE { mfrBundleIndex Integer32, mfrBundleIfIndex InterfaceIndex, mfrBundleRowStatus RowStatus, mfrBundleNearEndName SnmpAdminString, mfrBundleFragmentation INTEGER, mfrBundleMaxFragSize Integer32, mfrBundleTimerHello INTEGER, Pate, et al. Standards Track [Page 16] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 mfrBundleTimerAck INTEGER, mfrBundleCountMaxRetry INTEGER, mfrBundleActivationClass INTEGER, mfrBundleThreshold Integer32, mfrBundleMaxDiffDelay Integer32, mfrBundleSeqNumSize INTEGER, mfrBundleMaxBundleLinks Integer32, mfrBundleLinksConfigured Integer32, mfrBundleLinksActive Integer32, mfrBundleBandwidth Integer32, mfrBundleFarEndName SnmpAdminString, mfrBundleResequencingErrors Counter32 } mfrBundleIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index into the table. While this corresponds to an entry in the ifTable, the value of mfrBundleIndex need not match that of the ifIndex in the ifTable. A manager can use mfrBundleNextIndex to select a unique mfrBundleIndex for creating a new row." ::= { mfrBundleEntry 1 } mfrBundleIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value must match an entry in the interface table whose ifType must be set to frf16MfrBundle(163). For example: if the value of mfrBundleIfIndex is 10, then a corresponding entry should be present in Pate, et al. Standards Track [Page 17] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 the ifTable with an index of 10 and an ifType of 163." ::= { mfrBundleEntry 2 } mfrBundleRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The mfrBundleRowStatus object allows create, change, and delete operations on bundle entries." REFERENCE "RFC 1903" ::= { mfrBundleEntry 3 } mfrBundleNearEndName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The configured name of the bundle." REFERENCE "FRF.16 section 3.4.1" ::= { mfrBundleEntry 4 } mfrBundleFragmentation OBJECT-TYPE SYNTAX INTEGER { enable (1), disable (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Controls whether the bundle performs/accepts fragmentation and re-assembly. The possible values are: enable(1) - Bundle links will fragment frames disable(2) - Bundle links will not fragment frames." DEFVAL { disable } ::= { mfrBundleEntry 5 } mfrBundleMaxFragSize OBJECT-TYPE SYNTAX Integer32 (-1..8184) UNITS "Octets" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum fragment size supported. Note that this Pate, et al. Standards Track [Page 18] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 is only valid if mfrBundleFragmentation is set to enable(1). Zero is not a valid fragment size. A bundle that does not support fragmentation must return this object with a value of -1." DEFVAL { -1 } ::= { mfrBundleEntry 6 } mfrBundleTimerHello OBJECT-TYPE SYNTAX INTEGER (1..180) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The configured MFR Hello Timer value." REFERENCE "FRF.16 section 4.3.8.1" DEFVAL { 10 } ::= { mfrBundleEntry 7 } mfrBundleTimerAck OBJECT-TYPE SYNTAX INTEGER (1..10) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The configured MFR T_ACK value." REFERENCE "FRF.16 section 4.3.8.2" DEFVAL { 4 } ::= { mfrBundleEntry 8 } mfrBundleCountMaxRetry OBJECT-TYPE SYNTAX INTEGER (1..5) MAX-ACCESS read-create STATUS current DESCRIPTION "The MFR N_MAX_RETRY value." REFERENCE "FRF.16 section 4.3.8.3" DEFVAL { 2 } ::= { mfrBundleEntry 9 } mfrBundleActivationClass OBJECT-TYPE SYNTAX INTEGER { mfrBundleActivationClassA (1), mfrBundleActivationClassB (2), mfrBundleActivationClassC (3), mfrBundleActivationClassD (4) } Pate, et al. Standards Track [Page 19] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 MAX-ACCESS read-create STATUS current DESCRIPTION "Controls the conditions under which the bundle is activated. The following settings are available: mfrBundleActivationClassA(1) - at least one must link up mfrBundleActivationClassB(2) - all links must be up mfrBundleActivationClassC(3) - a certain number must be up. Refer to mfrBundleThreshold for the required number. mfrBundleActivationClassD(4) - custom (implementation specific)." REFERENCE "FRF.16 section 4.2.2.1" DEFVAL { mfrBundleActivationClassA } ::= { mfrBundleEntry 10 } mfrBundleThreshold OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) UNITS "Bundle Links" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the number of links that must be in operational 'up' state before the bundle will transition to an operational up/active state. If the number of operational 'up' links falls below this value, then the bundle will transition to an inactive state. Note - this is only valid when mfrBundleActivationClass is set to mfrBundleActivationClassC or, depending upon the implementation, to mfrBundleActivationClassD. A bundle that is not set to one of these must return this object with a value of -1." REFERENCE "FRF.16 section 4.2.2.1" DEFVAL { -1 } ::= { mfrBundleEntry 11 } mfrBundleMaxDiffDelay OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) UNITS "Milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum delay difference between the bundle links. Pate, et al. Standards Track [Page 20] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 A value of -1 indicates that this object does not contain a valid value" DEFVAL { -1 } ::= { mfrBundleEntry 12 } mfrBundleSeqNumSize OBJECT-TYPE SYNTAX INTEGER { seqNumSize12bit (1), seqNumSize24bit (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Controls whether the standard FRF.12 12-bit sequence number is used or the optional 24-bit sequence number." REFERENCE "FRFTC/99-194" DEFVAL { seqNumSize12bit } ::= { mfrBundleEntry 13 } mfrBundleMaxBundleLinks OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bundle Links" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of bundle links supported for this bundle." ::= { mfrBundleEntry 14 } mfrBundleLinksConfigured OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "Bundle Links" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of links configured for the bundle." ::= { mfrBundleEntry 15 } mfrBundleLinksActive OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) UNITS "Bundle Links" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of links that are active." ::= { mfrBundleEntry 16 } Pate, et al. Standards Track [Page 21] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 mfrBundleBandwidth OBJECT-TYPE SYNTAX Integer32 UNITS "Bits/Sec" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of available bandwidth on the bundle" ::= { mfrBundleEntry 17 } mfrBundleFarEndName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Name of the bundle received from the far end." REFERENCE "FRF.16 section 3.4.1" ::= { mfrBundleEntry 18 } mfrBundleResequencingErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Error Events" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of resequencing errors. Each event may correspond to multiple lost frames. Example: Say sequence number 56, 59 and 60 is received for DLCI 100. It is decided by some means that sequence 57 and 58 is lost. This counter should then be incremented by ONE, even though two frames were lost." ::= { mfrBundleEntry 19 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- ifIndex Mapping to Bundle Index Table -- --------------------------------------------------------- -- --------------------------------------------------------- mfrBundleIfIndexMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF MfrBundleIfIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table mapping the values of ifIndex to the mfrBundleIndex. This is required in order to find the mfrBundleIndex given an ifIndex. The mapping of mfrBundleIndex to ifIndex is provided by the mfrBundleIfIndex entry in the mfrBundleTable." Pate, et al. Standards Track [Page 22] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 ::= { mfrMibBundleObjects 4 } mfrBundleIfIndexMappingEntry OBJECT-TYPE SYNTAX MfrBundleIfIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row describes one ifIndex to mfrBundleIndex mapping." INDEX { ifIndex } ::= { mfrBundleIfIndexMappingTable 1 } MfrBundleIfIndexMappingEntry ::= SEQUENCE { mfrBundleIfIndexMappingIndex Integer32 } mfrBundleIfIndexMappingIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The mfrBundleIndex of the given ifIndex." ::= { mfrBundleIfIndexMappingEntry 2 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Bundle Link Table -- --------------------------------------------------------- -- --------------------------------------------------------- mfrBundleLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF MfrBundleLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The bundle link configuration and status table. There is a one-to-one correspondence between a bundle link and a physical interface represented in the ifTable. The ifIndex of the physical interface is used to index the bundle link table, and to create rows. The following objects of the ifTable have specific meaning for an MFR bundle link: ifAdminStatus - the bundle link admin status ifOperStatus - the bundle link operational status Pate, et al. Standards Track [Page 23] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 ifSpeed - the bandwidth of the bundle link interface ifInUcastPkts - the number of frames received on the bundle link ifOutUcastPkts - the number of frames transmitted on the bundle link ifInErrors - frame and fragment errors ifOutErrors - frame and fragment errors" ::= { mfrMibBundleLinkObjects 1 } mfrBundleLinkEntry OBJECT-TYPE SYNTAX MfrBundleLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the bundle link table." INDEX { ifIndex } ::= { mfrBundleLinkTable 1 } MfrBundleLinkEntry ::= SEQUENCE { mfrBundleLinkRowStatus RowStatus, mfrBundleLinkConfigBundleIndex Integer32, mfrBundleLinkNearEndName SnmpAdminString, mfrBundleLinkState MfrBundleLinkState, mfrBundleLinkFarEndName SnmpAdminString, mfrBundleLinkFarEndBundleName SnmpAdminString, mfrBundleLinkDelay Integer32, mfrBundleLinkFramesControlTx Counter32, mfrBundleLinkFramesControlRx Counter32, mfrBundleLinkFramesControlInvalid Counter32, mfrBundleLinkTimerExpiredCount Counter32, mfrBundleLinkLoopbackSuspected Counter32, mfrBundleLinkUnexpectedSequence Counter32, mfrBundleLinkMismatch Pate, et al. Standards Track [Page 24] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 Counter32 } mfrBundleLinkRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The mfrBundleLinkRowStatus object allows create, change, and delete operations on mfrBundleLink entries. The create operation must fail if no physical interface is associated with the bundle link." ::= { mfrBundleLinkEntry 1 } mfrBundleLinkConfigBundleIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The mfrBundleLinkConfigBundleIndex object allows the manager to control the bundle to which the bundle link is assigned. If no value were in this field, then the bundle would remain in NOT_READY rowStatus and be unable to go to active. With an appropriate mfrBundleIndex in this field, then we could put the mfrBundleLink row in NOT_IN_SERVICE or ACTIVE rowStatus." ::= { mfrBundleLinkEntry 2 } mfrBundleLinkNearEndName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The configured bundle link name that is sent to the far end." ::= { mfrBundleLinkEntry 3 } mfrBundleLinkState OBJECT-TYPE SYNTAX MfrBundleLinkState MAX-ACCESS read-only STATUS current DESCRIPTION "Current bundle link state as defined by the MFR protocol described in Annex A of FRF.16." REFERENCE "FRF.16 Annex A" ::= { mfrBundleLinkEntry 4 } mfrBundleLinkFarEndName OBJECT-TYPE Pate, et al. Standards Track [Page 25] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Name of bundle link received from far end." REFERENCE "FRF.16 section 3.4.2" ::= { mfrBundleLinkEntry 5 } mfrBundleLinkFarEndBundleName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Name of far end bundle for this link received from far end." REFERENCE "FRF.16 section 3.4.1" ::= { mfrBundleLinkEntry 6 } mfrBundleLinkDelay OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Current round-trip delay for this bundle link. The value -1 is returned when an implementation does not support measurement of the bundle link delay." REFERENCE "FRF.16 section 3.4.4" ::= { mfrBundleLinkEntry 7 } mfrBundleLinkFramesControlTx OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of MFR control frames sent." REFERENCE "FRF.16 section 3.2" ::= { mfrBundleLinkEntry 8 } mfrBundleLinkFramesControlRx OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of valid MFR control frames received." REFERENCE "FRF.16 section 3.2" ::= { mfrBundleLinkEntry 9 } Pate, et al. Standards Track [Page 26] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 mfrBundleLinkFramesControlInvalid OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid MFR control frames received." REFERENCE "FRF.16 section 3.2" ::= { mfrBundleLinkEntry 10 } mfrBundleLinkTimerExpiredCount OBJECT-TYPE SYNTAX Counter32 UNITS "Timer Expiration Events" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the T_HELLO or T_ACK timers expired." REFERENCE "FRF.16 section 4.3.8.1 and 4.3.8.2" ::= { mfrBundleLinkEntry 11 } mfrBundleLinkLoopbackSuspected OBJECT-TYPE SYNTAX Counter32 UNITS "Loopback Suspected Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a loopback has been suspected (based upon the use of magic numbers)." REFERENCE "FRF.16 section 4.3.7" ::= { mfrBundleLinkEntry 12 } mfrBundleLinkUnexpectedSequence OBJECT-TYPE SYNTAX Counter32 UNITS "Frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of data MFR frames discarded because the sequence number of the frame for a DLCI was less than (delayed frame) or equal to (duplicate frame) the one expected for that DLCI. Example: Say frames with sequence numbers 56, 58, 59 is received for DLCI 100. While waiting for sequence number 57 another frame with sequence number 58 arrives. Frame 58 is discarded and the counter is incremented." REFERENCE "FRF.16 section 4.2.3.2" ::= { mfrBundleLinkEntry 13 } Pate, et al. Standards Track [Page 27] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 mfrBundleLinkMismatch OBJECT-TYPE SYNTAX Counter32 UNITS "Bundle Name Mismatch Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the unit has been notified by the remote peer that the bundle name is inconsistent with other bundle links attached to the far-end bundle." REFERENCE "FRF.16 section 4.3.2.4" ::= { mfrBundleLinkEntry 14 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Notifications/Traps -- --------------------------------------------------------- -- --------------------------------------------------------- mfrMibTrapBundleLinkMismatch NOTIFICATION-TYPE OBJECTS { mfrBundleNearEndName, mfrBundleFarEndName, mfrBundleLinkNearEndName, mfrBundleLinkFarEndName, mfrBundleLinkFarEndBundleName } STATUS current DESCRIPTION "This trap indicates that a bundle link mismatch has been detected. The following objects are reported: mfrBundleNearEndName: configured name of near end bundle mfrBundleFarEndName: previously reported name of far end bundle mfrBundleLinkNearEndName: configured name of near end bundle mfrBundleLinkFarEndName: reported name of far end bundle mfrBundleLinkFarEndBundleName: currently reported name of far end bundle Note: that the configured items may have been configured automatically. Note: The mfrBundleLinkMismatch counter is incremented when the trap is sent." Pate, et al. Standards Track [Page 28] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 REFERENCE "FRF.16 section 4.3.2.4" ::= { mfrMibTrapsPrefix 1 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Conformance/Compliance -- --------------------------------------------------------- -- --------------------------------------------------------- mfrMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for equipment that implements the FRF16 MIB. All of the current groups are mandatory, but a number of objects may be read-only if the implementation does not allow configuration." MODULE -- this module MANDATORY-GROUPS { mfrMibBundleGroup, mfrMibBundleLinkGroup, mfrMibTrapGroup } OBJECT mfrBundleFragmentation MIN-ACCESS read-only DESCRIPTION "Write access is not required, but the value used must be reported." OBJECT mfrBundleMaxFragSize MIN-ACCESS read-only DESCRIPTION "Write access is not required, but the value used must be reported. A value of -1 indicates that the value is not applicable." OBJECT mfrBundleThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required, but the value used must be reported. A value of -1 indicates that the value is not applicable." OBJECT mfrBundleMaxDiffDelay MIN-ACCESS read-only DESCRIPTION "Write access is not required, but the value used must be reported." Pate, et al. Standards Track [Page 29] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 OBJECT mfrBundleSeqNumSize MIN-ACCESS read-only DESCRIPTION "Write access is not required, but the value used must be reported. A value of -1 indicates that the value is not applicable." ::= { mfrMibCompliances 1 } -- --------------------------------------------------------- -- --------------------------------------------------------- -- Units of Conformance -- --------------------------------------------------------- -- --------------------------------------------------------- mfrMibBundleGroup OBJECT-GROUP OBJECTS { mfrBundleMaxNumBundles, mfrBundleNextIndex, mfrBundleIfIndex, mfrBundleRowStatus, mfrBundleNearEndName, mfrBundleFragmentation, mfrBundleMaxFragSize, mfrBundleTimerHello, mfrBundleTimerAck, mfrBundleCountMaxRetry, mfrBundleActivationClass, mfrBundleThreshold, mfrBundleMaxDiffDelay, mfrBundleMaxBundleLinks, mfrBundleLinksConfigured, mfrBundleLinksActive, mfrBundleBandwidth, mfrBundleSeqNumSize, mfrBundleFarEndName, mfrBundleResequencingErrors, mfrBundleIfIndexMappingIndex } STATUS current DESCRIPTION "Group of objects describing bundles." ::= { mfrMibGroups 1 } mfrMibBundleLinkGroup OBJECT-GROUP OBJECTS { mfrBundleLinkRowStatus, Pate, et al. Standards Track [Page 30] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 mfrBundleLinkConfigBundleIndex, mfrBundleLinkNearEndName, mfrBundleLinkState, mfrBundleLinkFarEndName, mfrBundleLinkFarEndBundleName, mfrBundleLinkDelay, mfrBundleLinkFramesControlTx, mfrBundleLinkFramesControlRx, mfrBundleLinkFramesControlInvalid, mfrBundleLinkTimerExpiredCount, mfrBundleLinkLoopbackSuspected, mfrBundleLinkUnexpectedSequence, mfrBundleLinkMismatch } STATUS current DESCRIPTION "Group of objects describing bundle links." ::= { mfrMibGroups 2 } mfrMibTrapGroup NOTIFICATION-GROUP NOTIFICATIONS { mfrMibTrapBundleLinkMismatch } STATUS current DESCRIPTION "Group of objects describing notifications (traps)." ::= { mfrMibGroups 3 } END Pate, et al. Standards Track [Page 31] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 4. Acknowledgments This document was produced by the Frame Relay Service MIB (frnetmib) Working Group in conjunction with the Frame Relay Forum. 5. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Pate, et al. Standards Track [Page 32] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [Q.922] ITU-T, Recommendation Q.922: "ISDN Data Link Layer Specification For Frame Mode Bearer Services" [Q.933] ITU-T, Recommendation Q.933: "Signalling Specification For Frame Mode Basic Call Control" [FRF.4] R. Cherukuri (ed), FRF.4: "Frame Relay User-to-Network SVC Implementation Agreement" January 5, 1994. [FRF.16] M. Sheehan (ed), FRF.16: "UNI/NNI Multilink Frame Relay Interworking Implementation Agreement" August 20, 1999. [RFC1604] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for Frame Relay Service", RFC 2954, October 2000. [RFC2494] Fowler, D., "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type", RFC 2494, November 1997. [RFC2863] McCloghrie, D. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, June 2000. [ATMLANE] T. Newton, ed., "LAN Emulation Client Management Specification Version 2.0" AF-LANE-0093.000, ATM Forum, October, 1998 [ATMIMA] R. Vallee, ed., "Inverse Multiplexing for ATM Specification Version 1.1" (Appendix A) AF-PHY-0086.001, ATM Forum, March, 1999 Pate, et al. Standards Track [Page 33] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 [RFC2115] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. No managed objects in this MIB contain sensitive information. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Pate, et al. Standards Track [Page 34] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 7. Authors' Addresses Prayson Pate Overture Networks P. O. Box 14864 RTP, NC, USA 27709 Phone: +1 919 558 2200 EMail: prayson.pate@overturenetworks.com Bob Lynch Overture Networks P. O. Box 14864 RTP, NC, USA 27709 Phone: +1 919 558-2200 EMail: bob.lynch@overturenetworks.com Kenneth Rehbehn Megisto Systems, Inc. 20251 Century Boulevard Germantown, MD, USA 20874 Phone: +1 301 529-4427 EMail: krehbehn@megisto.com Pate, et al. Standards Track [Page 35] RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000 8. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Pate, et al. Standards Track [Page 36] snmp-mibs-downloader-1.1/mibrfcs/rfc3055.txt0000644000000000000000000011462311402176071015565 0ustar Network Working Group M. Krishnaswamy Request for Comments: 3055 Photuris, Inc. Category: Standards Track D. Romascanu Avaya Communication February 2001 Management Information Base for the PINT Services Architecture 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. Table of Contents 1. Introduction ................................................ 2 2. The SNMP Management Framework ............................... 2 3. The need for PINT Services monitoring MIB ................... 3 4. PINT MIB Overview ........................................... 4 5. Definitions ................................................. 5 6. Acknowledgements ............................................ 17 7. Security Considerations ..................................... 17 8. IANA Considerations ......................................... 18 9. Intellectual Property ....................................... 18 10. References .................................................. 18 11. Authors' Addresses .......................................... 20 12. Full Copyright Statement .................................... 21 Krishnaswamy & Romascanu Standards Track [Page 1] RFC 3055 PINT MIB February 2001 1. Introduction PINT services are an emerging set of new Internet based applications where voice (and fax) requests to the PSTN (Public Switched Telephone Network) are carried over the Internet. RFC 2458 [1] gives a good introduction to the (pre-standard) PINT architecture and services. It also has examples of some of the early implementations of pre- PINT. This document defines a MIB which contains the elements for monitoring the performance of a PINT based service. The MIB consists of details of the four basic PINT services and their performance statistics measured under various criteria. It is not the purpose of this MIB to enable management of the PINT networking elements. We are concerned only with the PINT specific performance parameters. While it is understood that PINT service performance is closely related to host and network performance, they are not addressed here. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [2]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The second version, called SMIv2, is described in STD 58, RFC 2578 [6], RFC 2579 [7] and RFC 2580 [8]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [9]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [9]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [14]. Krishnaswamy & Romascanu Standards Track [Page 2] RFC 3055 PINT MIB February 2001 o A set of fundamental applications described in RFC 2573 [15] and the view-based access control mechanism described in RFC 2575 [16]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. The need for PINT services monitoring MIB Traditionally voice (and fax) requests originate and terminate inside a PSTN network. This network is well known for robust handling of the requests, in terms of availability and security. However when the requests originate from the Internet there is a concern both on the part of the user as well as the provider about issues like reliable forwarding of the call requests to the PINT gateway under various network conditions, user/host authentication, secure handling of the user information etc. Performance and security management becomes all the more important where PINT services cross multiple administrative domains (or providers). This MIB is an attempt to list the parameters that need to be monitored on an user, PINT client, PINT server and PINT gateway basis. (PINT services, their invocation methods/protocols and security issues associated with the PINT architecture are discussed in detail in [18]). Krishnaswamy & Romascanu Standards Track [Page 3] RFC 3055 PINT MIB February 2001 4. PINT MIB - Overview Following is a list of some explanations on the MIB definitions that we have chosen to construct. o The basic purpose of this MIB is to monitor the access to PINT services both from the performance and security point of view. Information may pertain to a certain user or his/her system (PINT client) or the system providing the PINT services (PINT server) or the PINT gateway that forwards the call to the PSTN network. o We chose to build the configuration table as an extension of the Application MIB - RFC 2287 [19] using the augments construct. Server location and contact might be retrieved from the standard MIB-II sysLocation and sysContact objects. There is no need to replicate this information in the PINT MIB. However, the PINT administrator may be a different person than the sysadmin with global responsibilities, thus a pintSysContact object is defined. o We chose to monitor the gateway connections from the PINT server. While the agent runs in the PINT servers, the connections to the gateways might need to be monitored in order to understand what goes on. We placed them in a separate MIB group, and by using MODULE-COMPLIANCE clauses, agents that cannot implement this stuff will not be mandated to do it. o There is no traps definition in this MIB module. Note that thresholding on counters is always possible by using a standard mechanism defined by the Remote Monitoring MIB, that can be referenced here. Some events that may be defined by using this mechanisms: * continuous login/authentication failure or refusal from a particular client or user * nuisance call - repeated calls (within a specified period) to a number originating from the same user o The client performance and user performance tables may be rather resource demanding for an agent implementation. In some MIBs, like the Remote Monitoring (RMON) MIBs, control mechanisms were built in order to activate those statistics on demand. If needed, a sorting ('topN') mechanism can be designed, so that a sorted view of clients or users is presented for the high level debugging. Krishnaswamy & Romascanu Standards Track [Page 4] RFC 3055 PINT MIB February 2001 o We built a time-distribution trying to cover both short-lived, as well as longer sessions (1-10 secs, 10 secs - 1 min., 1-15 min., 15 mins-24 hours, longer). o PintServerClientAddress is defined as a SnmpAdminString. It may include an IpAddress and/or name, but we preferred to minimize the number of indices at this stage, and keep a human-readable format at the same time. o We define pintServerUserIdName as the UserId. This UserId needs to be unique across multiple PINT servers and gateways (depending on the architecture) and is mapped to the SessionId. One way to achieve this uniqueness is by appending clientId to the UserId string before sending to the PINT server. The SessionId could then be a combination of this new UserId and a timestamp. 5. Definitions PINT-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, Counter32, MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF sysApplInstallPkgEntry FROM SYSAPPL-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- RFC 2571 [2] pintMib MODULE-IDENTITY LAST-UPDATED "200102010000Z" -- 1 Feb 2001 ORGANIZATION "IETF PINT Working Group" CONTACT-INFO " Chairs: Steve Bellovin E-mail: smb@research.att.com Igor Faynberg E-mail: faynberg@lucent.com Authors: Murali Krishnaswamy Postal: 20 Corporate Place South Piscataway, NJ 08854 Tel: +1 (732)465-1000 Krishnaswamy & Romascanu Standards Track [Page 5] RFC 3055 PINT MIB February 2001 E-mail: murali@photuris.com Dan Romascanu Postal: Atidim Technology Park, Bldg 3 Tel Aviv, Israel Tel: +972 3 6458414 E-mail: dromasca@avaya.com General Discussion:pint@lists.bell-labs.com To Subscribe: pint-request@lists.bell-labs.com In Body: subscribe your-email-addres Archive: http://www.bell-labs.com/mailing-lists/pint/ " DESCRIPTION "This MIB defines the objects necessary to monitor PINT Services" -- Revision history REVISION "200102010000Z" -- 1 Feb 2001 DESCRIPTION "Initial version, published as RFC 3055." ::= { mib-2 93 } PintServiceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes the type of a PINT service." SYNTAX INTEGER { r2C(1), -- Request-to-Talk r2F(2), -- Request-to-Fax r2FB(3), -- Request-to-Fax-Back r2HC(4) -- Request-to-Hear-Content } PintPerfStatPeriod ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes the statistics period of time. Note that the values of the counters indexed with a value SinceReboot(4) can be potentially affected by a counter rollover. It is the responsibility of the application using this object to take into account that the counter has been zeroed each time it reached a value of (2**32-1)." SYNTAX INTEGER { last30sec(1), -- Performance Statics for the last 30 sec Krishnaswamy & Romascanu Standards Track [Page 6] RFC 3055 PINT MIB February 2001 last15min(2), -- 15 min last24Hr(3), -- 24 Hour sinceReboot(4) -- Since the time the pint server was -- last rebooted } pintServerConfig OBJECT IDENTIFIER ::= { pintMib 1 } pintServerMonitor OBJECT IDENTIFIER ::= { pintMib 2 } pintMibConformance OBJECT IDENTIFIER ::= { pintMib 3 } -- pintServerConfig - PINT configuration MIB variables pintReleaseNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of version of the PINT protocol supported by this agent." ::= { pintServerConfig 1 } pintSysContact OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "Contact information related to the administration of the PINT services." ::= { pintServerConfig 2 } pintApplInstallPkgTable OBJECT-TYPE SYNTAX SEQUENCE OF PintApplInstallPkgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table describing the PINT applications that are installed." ::= { pintServerConfig 3 } pintApplInstallPkgEntry OBJECT-TYPE SYNTAX PintApplInstallPkgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries per PINT Application." AUGMENTS { sysApplInstallPkgEntry } ::= { pintApplInstallPkgTable 1 } PintApplInstallPkgEntry ::= SEQUENCE { Krishnaswamy & Romascanu Standards Track [Page 7] RFC 3055 PINT MIB February 2001 pintApplInstallPkgDescription SnmpAdminString } pintApplInstallPkgDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Textual description of the installed PINT application." ::= { pintApplInstallPkgEntry 1 } pintRegisteredGatewayTable OBJECT-TYPE SYNTAX SEQUENCE OF PintRegisteredGatewayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table describing the registered gateway applications." ::= { pintServerConfig 4 } pintRegisteredGatewayEntry OBJECT-TYPE SYNTAX PintRegisteredGatewayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries per Registered Gateway Application." AUGMENTS { sysApplInstallPkgEntry } ::= { pintRegisteredGatewayTable 1 } PintRegisteredGatewayEntry ::= SEQUENCE { pintRegisteredGatewayName SnmpAdminString, pintRegisteredGatewayDescription SnmpAdminString } pintRegisteredGatewayName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Name of the registered gateway." ::= { pintRegisteredGatewayEntry 1 } pintRegisteredGatewayDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Textual description of the registered gateway." ::= { pintRegisteredGatewayEntry 2 } Krishnaswamy & Romascanu Standards Track [Page 8] RFC 3055 PINT MIB February 2001 -- pintServerMonitor - PINT monitoring statistics MIB variables pintServerGlobalPerf OBJECT IDENTIFIER ::= {pintServerMonitor 1 } pintServerClientPerf OBJECT IDENTIFIER ::= {pintServerMonitor 2 } pintServerUserIdPerf OBJECT IDENTIFIER ::= {pintServerMonitor 3 } pintServerGatewayPerf OBJECT IDENTIFIER ::= {pintServerMonitor 4 } pintServerGlobalStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerGlobalStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table displaying the monitored global server statistics." ::= { pintServerGlobalPerf 1 } pintServerGlobalStatsEntry OBJECT-TYPE SYNTAX PintServerGlobalStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the global statistics table. One entry is defined for each monitored service type and performance statistics collection period." INDEX {pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex} ::= { pintServerGlobalStatsTable 1 } PintServerGlobalStatsEntry ::= SEQUENCE { pintServerServiceTypeIndex PintServiceType, pintServerPerfStatPeriodIndex PintPerfStatPeriod, pintServerGlobalCallsReceived Counter32, pintServerGlobalSuccessfulCalls Counter32, pintServerGlobalDisconnectedCalls Counter32, pintServerGlobalDisCUAutFCalls Counter32, pintServerGlobalDisServProbCalls Counter32, pintServerGlobalDisGatProbCalls Counter32 } pintServerServiceTypeIndex OBJECT-TYPE SYNTAX PintServiceType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the monitored service." ::= { pintServerGlobalStatsEntry 1 } pintServerPerfStatPeriodIndex OBJECT-TYPE SYNTAX PintPerfStatPeriod MAX-ACCESS not-accessible Krishnaswamy & Romascanu Standards Track [Page 9] RFC 3055 PINT MIB February 2001 STATUS current DESCRIPTION "Time period for which the performance statistics are requested from the pint server." ::= { pintServerGlobalStatsEntry 2 } pintServerGlobalCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of received global calls." ::= { pintServerGlobalStatsEntry 3 } pintServerGlobalSuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global successful calls." ::= { pintServerGlobalStatsEntry 4 } pintServerGlobalDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global disconnected (failed) calls." ::= { pintServerGlobalStatsEntry 5 } pintServerGlobalDisCUAutFCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global calls that were disconnected because of client or user authorization failure." ::= { pintServerGlobalStatsEntry 6 } pintServerGlobalDisServProbCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global calls that were disconnected because of server problems." ::= { pintServerGlobalStatsEntry 7 } Krishnaswamy & Romascanu Standards Track [Page 10] RFC 3055 PINT MIB February 2001 pintServerGlobalDisGatProbCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global calls that were disconnected because of gateway problems." ::= { pintServerGlobalStatsEntry 8 } pintServerClientStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerClientStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table displaying the monitored server client statistics." ::= { pintServerClientPerf 1 } pintServerClientStatsEntry OBJECT-TYPE SYNTAX PintServerClientStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the client server statistics table. One entry is defined for each client identified by name, monitored service type and performance statistics collection period." INDEX {pintServerClientAddress, pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex} ::= { pintServerClientStatsTable 1 } PintServerClientStatsEntry ::= SEQUENCE { pintServerClientAddress SnmpAdminString, pintServerClientCallsReceived Counter32, pintServerClientSuccessfulCalls Counter32, pintServerClientDisconnectedCalls Counter32, pintServerClientDisCAutFCalls Counter32, pintServerClientDisEFProbCalls Counter32 } pintServerClientAddress OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the monitored client identified by its address represented as as a string." ::= { pintServerClientStatsEntry 1 } Krishnaswamy & Romascanu Standards Track [Page 11] RFC 3055 PINT MIB February 2001 pintServerClientCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the specific client." ::= { pintServerClientStatsEntry 2 } pintServerClientSuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the client successfully completed." ::= { pintServerClientStatsEntry 3 } pintServerClientDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the client, and that were disconnected (failed)." ::= { pintServerClientStatsEntry 4 } pintServerClientDisCAutFCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the client that were disconnected because of client authorization failure." ::= { pintServerClientStatsEntry 5 } pintServerClientDisEFProbCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the client that were disconnected because of egress facility problems." ::= { pintServerClientStatsEntry 6 } pintServerUserIdStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerUserIdStatsEntry MAX-ACCESS not-accessible STATUS current Krishnaswamy & Romascanu Standards Track [Page 12] RFC 3055 PINT MIB February 2001 DESCRIPTION "Table displaying the monitored Pint service user statistics." ::= { pintServerUserIdPerf 1 } pintServerUserIdStatsEntry OBJECT-TYPE SYNTAX PintServerUserIdStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the user statistics table. One entry is defined for each user identified by name, each monitored service type and performance statistics collection period. It is assumed that the capabilities of the pint server are enough to accommodate the number of entries in this table. It is a local server implementation issue if an aging mechanism Is implemented in order to avoid scalability problems." INDEX {pintServerUserIdName, pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex} ::= { pintServerUserIdStatsTable 1 } PintServerUserIdStatsEntry ::= SEQUENCE { pintServerUserIdName SnmpAdminString, pintServerUserIdCallsReceived Counter32, pintServerUserIdSuccessfulCalls Counter32, pintServerUserIdDisconnectedCalls Counter32, pintServerUserIdDiscUIdAFailCalls Counter32, pintServerUserIdEFProbCalls Counter32 } pintServerUserIdName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the monitored user identified by its name." ::= { pintServerUserIdStatsEntry 1 } pintServerUserIdCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the specific user." ::= { pintServerUserIdStatsEntry 2 } Krishnaswamy & Romascanu Standards Track [Page 13] RFC 3055 PINT MIB February 2001 pintServerUserIdSuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the user successfully completed." ::= { pintServerUserIdStatsEntry 3 } pintServerUserIdDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the user that were disconnected (failed)." ::= { pintServerUserIdStatsEntry 4 } pintServerUserIdDiscUIdAFailCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the user that were disconnected because of user authorization failure." ::= { pintServerUserIdStatsEntry 5 } pintServerUserIdEFProbCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the user that were disconnected because of egress facility problems." ::= { pintServerUserIdStatsEntry 6 } pintServerGatewayStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerGatewayStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table displaying the monitored gateway statistics." ::= { pintServerGatewayPerf 1 } pintServerGatewayStatsEntry OBJECT-TYPE SYNTAX PintServerGatewayStatsEntry MAX-ACCESS not-accessible STATUS current Krishnaswamy & Romascanu Standards Track [Page 14] RFC 3055 PINT MIB February 2001 DESCRIPTION "Entries in the gateway table. One entry is defined for each gateway identified by name, each monitored service type and performance statistics collection period." INDEX { pintRegisteredGatewayName, pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex } ::= { pintServerGatewayStatsTable 1 } PintServerGatewayStatsEntry ::= SEQUENCE { pintServerGatewayCallsReceived Counter32, pintServerGatewaySuccessfulCalls Counter32, pintServerGatewayDisconnectedCalls Counter32 } pintServerGatewayCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received at the specified gateway." ::= { pintServerGatewayStatsEntry 1 } pintServerGatewaySuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls successfully completed at the specified gateway." ::= { pintServerGatewayStatsEntry 2 } pintServerGatewayDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls that were disconnected (failed) at the specified gateway." ::= { pintServerGatewayStatsEntry 3 } -- -- Notifications Section -- (none defined) -- -- -- Conformance Section Krishnaswamy & Romascanu Standards Track [Page 15] RFC 3055 PINT MIB February 2001 -- pintMibCompliances OBJECT IDENTIFIER ::= { pintMibConformance 1 } pintMibGroups OBJECT IDENTIFIER ::= { pintMibConformance 2 } pintMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the PINT MIB." MODULE -- this module MANDATORY-GROUPS { pintMibConfigGroup, pintMibMonitorGroup } ::= { pintMibCompliances 1 } pintMibConfigGroup OBJECT-GROUP OBJECTS { pintReleaseNumber, pintSysContact, pintApplInstallPkgDescription, pintRegisteredGatewayName, pintRegisteredGatewayDescription } STATUS current DESCRIPTION "A collection of objects providing configuration information for a PINT Server." ::= { pintMibGroups 1 } pintMibMonitorGroup OBJECT-GROUP OBJECTS { pintServerGlobalCallsReceived, pintServerGlobalSuccessfulCalls, pintServerGlobalDisconnectedCalls, pintServerGlobalDisCUAutFCalls, pintServerGlobalDisServProbCalls, pintServerGlobalDisGatProbCalls, pintServerClientCallsReceived, pintServerClientSuccessfulCalls, pintServerClientDisconnectedCalls, pintServerClientDisCAutFCalls, pintServerClientDisEFProbCalls, --pintServerUserIdName, pintServerUserIdCallsReceived, pintServerUserIdSuccessfulCalls, pintServerUserIdDisconnectedCalls, pintServerUserIdDiscUIdAFailCalls, pintServerUserIdEFProbCalls, Krishnaswamy & Romascanu Standards Track [Page 16] RFC 3055 PINT MIB February 2001 pintServerGatewayCallsReceived, pintServerGatewaySuccessfulCalls, pintServerGatewayDisconnectedCalls } STATUS current DESCRIPTION "A collection of objects providing monitoring information for a PINT Server." ::= { pintMibGroups 2 } END 6. Acknowledgements The authors would like to thank Igor Faynberg for his encouragement to produce this work. 7. Security Considerations There is only one management object defined in this MIB that has a MAX-ACCESS clause of read-write (pintSysContact). There are no read-create objects. This read-write object may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain information that may be sensitive from a business perspective. One could be the customer identification (UserIdName). Also information on PINT services performance might itself be need to be guarded. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [13] and the View-based Access Control Model RFC 2575 [16] is recommended. Krishnaswamy & Romascanu Standards Track [Page 17] RFC 3055 PINT MIB February 2001 It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations All extensions to the values listed in this MIB must be done through Standards Action processes as defined in RFC 2434 [20]. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. References [1] Lu, H., Conroy, L., Bellovin, S., Krishnaswamy, M., Burg, F., DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H. and K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking -- Pre-PINT Implementations", RFC 2458, November 1998. [2] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [3] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. Krishnaswamy & Romascanu Standards Track [Page 18] RFC 3055 PINT MIB February 2001 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [5] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [8] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [11] 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. [12] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [14] Case, J., McCloghrie, K., Rose, M. and Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [15] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. Krishnaswamy & Romascanu Standards Track [Page 19] RFC 3055 PINT MIB February 2001 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [18] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000. [19] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [20] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 11. Authors' Addresses Murali Krishnaswamy Lucent Technologies 3C-512, 101 Crawfords Corner Rd. Holmdel, NJ 07733 Phone: +1 (732)949-3611 Fax: +1 (732)949-3210 EMail: murali@lucent.com Dan Romascanu Avaya Communication Atidim Technology Park, Bldg 3 Tel Aviv, Israel Phone: +972 3 6458414 EMail: dromasca@avaya.com Krishnaswamy & Romascanu Standards Track [Page 20] RFC 3055 PINT MIB February 2001 12. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Krishnaswamy & Romascanu Standards Track [Page 21] snmp-mibs-downloader-1.1/mibrfcs/rfc3083.txt0000644000000000000000000025437611402176071015600 0ustar Network Working Group R. Woundy Request for Comments: 3083 Cisco Systems Category: Informational March 2001 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over-Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo specifies a MIB module in a manner that is compliant to the SMIv2 (Structure of Management Information Version 2). The set of objects is consistent with the SNMP framework and existing SNMP standards. CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. Woundy Informational [Page 1] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 Table of Contents 1 The SNMP Management Framework ................................... 2 2 Glossary ........................................................ 3 2.1 Authorization key ............................................. 3 2.2 BPI ........................................................... 4 2.3 BPI+ .......................................................... 4 2.4 CATV .......................................................... 4 2.5 CM ............................................................ 4 2.6 CMTS .......................................................... 4 2.7 DOCSIS ........................................................ 4 2.8 Downstream .................................................... 4 2.9 Head-end ...................................................... 4 2.10 MAC Packet ................................................... 4 2.11 MCNS ......................................................... 5 2.12 RF ........................................................... 5 2.13 SID .......................................................... 5 2.14 TEK .......................................................... 5 2.15 Upstream ..................................................... 5 3 Overview ........................................................ 5 3.1 Structure of the MIB .......................................... 5 3.2 Management requirements ....................................... 6 3.3 Textual convention ............................................ 7 4 Definitions ..................................................... 8 5 Acknowledgments ................................................ 40 6 References ..................................................... 40 7 Security Considerations ........................................ 42 8 Intellectual Property .......................................... 43 9 Author's Address ............................................... 44 10 Full Copyright Statement ...................................... 45 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP Woundy Informational [Page 2] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [24]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Glossary The terms in this document are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification process. 2.1. Authorization key A key used to derive a key encryption key (used to encrypt TEKs), and to derive message authentication keys. When the CMTS communicates the authorization key to the CM, it encrypts the authorization key using the RSA public key of the CM [22]. Woundy Informational [Page 3] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 2.2. BPI - Baseline Privacy Interface A term referring to the DOCSIS specification [18] for enabling simple data privacy in the DOCSIS 1.0 system. Management of the BPI is the focus of this document. 2.3. BPI+ - Baseline Privacy Plus Interface A term referring to the DOCSIS specification [21] for enabling CM authentication and data privacy in the DOCSIS 1.1 system. Management of the BPI+ is not addressed in this document. 2.4. CATV Originally "Community Antenna Television", now used to refer to any cable or hybrid fiber and cable system used to deliver video signals to a community. 2.5. CM - Cable Modem A CM acts as a "slave" station in a DOCSIS compliant cable data system. 2.6. CMTS - Cable Modem Termination System A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs. 2.7. DOCSIS "Data-Over-Cable Service Interface Specifications". A term referring to the ITU-T J.112 Annex B standard for cable modem systems [19]. 2.8. Downstream The direction from the head-end towards the subscriber. 2.9. Head-end The origination point in most cable systems of the subscriber video signals. Generally also the location of the CMTS equipment. 2.10. MAC Packet A DOCSIS PDU. Woundy Informational [Page 4] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 2.11. MCNS "Multimedia Cable Network System". Generally replaced in usage by DOCSIS. 2.12. RF Radio Frequency. 2.13 SID Service ID. The SID identifies a particular upstream bandwidth allocation and class-of-service management for DOCSIS, and identifies a particular bidirectional security association for BPI. 2.14. TEK - Traffic Encryption Key Traffic Encryption Key, which is used for DES encryption of upstream and downstream traffic. When the CMTS communicates the TEK to the CM, it encrypts the TEK using the key encryption key derived from the authorization key. 2.15. Upstream The direction from the subscriber towards the head-end. 3. Overview This MIB provides a set of objects required for the management of the Baseline Privacy Interface for DOCSIS compliant Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs). This MIB specification is derived from the DOCSIS Baseline Privacy Interface specification [18], which is an extension to the DOCSIS Radio Frequency Interface specification [19]. Please note that this MIB specification is not sufficient for the management of the DOCSIS Baseline Privacy Plus Interface specification [21]. The working group expects to issue a MIB for the management of BPI+ at a later time. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [23]. 3.1. Structure of the MIB This MIB consists of one group of CM-only objects (docsBpiCmGroup), and one group of CMTS-only objects (docsBpiCmtsGroup). Woundy Informational [Page 5] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 The CM-only objects are organized into two tables: o The docsBpiCmBaseTable contains objects for managing basic Baseline Privacy parameters and counters, and for managing the Authorization finite state machine. o The docsBpiCmTEKTable contains objects for managing the Traffic Encryption Key (TEK) finite state machine per SID. The CMTS-only objects are organized into four sub-groups: o The docsBpiCmtsBaseTable contains objects for managing basic Baseline Privacy parameters and counters. o The docsBpiCmtsAuthTable contains objects for managing the Authorization association information per cable modem. o The docsBpiCmtsTEKTable contains objects for managing the TEK association information per SID. o The docsBpiMulticastControl consists of two tables. The docsBpiIpMulticastMapTable controls the mapping of downstream IP multicast data traffic to downstream multicast SID values. The docsBpiMulticastAuthTable controls which CMs are authorized to receive downstream traffic transmitted over particular multicast SIDs; a CM will receive TEKs corresponding to the multicast SIDs for which it is authorized. The combination of these two tables will limit the distribution of downstream IP multicast data traffic to authorized CMs. 3.2. Management requirements The Baseline Privacy Interface specification is documented in [18], and is an extension to the Radio Frequency Interface specification documented in [19]. In addition to the explicit requirements in this specification, the CM and CMTS enabled for Baseline Privacy MUST support all applicable DOCSIS and IETF requirements and MIB objects. Specifications that identify relevant requirements and MIB objects include the IETF Radio Frequency MIB [16], the IETF Cable Device MIB [17], and the DOCSIS OSSI Specification [20]. The explicit management requirements of the Baseline Privacy Interface, which motivate the development of the MIB in this document, are detailed below: o The CM and CMTS MUST support viewing relevant RSA public keys, for future subscriber authentication applications. Woundy Informational [Page 6] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 o The Baseline Privacy management interface needs to support operator configuration of Authorization and TEK Finite State Machine (FSM) parameters, for performance tuning and security incident handling. The CMTS MUST support viewing (and configuring if possible) all FSM-related parameters, including baseline privacy status (enabled or disabled), key lifetimes, key grace times, and state timeout values. The CM MUST support viewing these parameters where possible. o The management interface needs to support operator analysis and override of FSM behavior, for fault management, subscriber service de-provisioning, and security incident handling. The CM MUST support viewing the current FSM states. The CM and CMTS MUST support viewing message error codes and message error strings, and counters for invalid KEK and TEK events, for key expirations and renewals, and for duplicate messages. The CM and CMTS MUST support viewing current authorization key sequence numbers and key expiration times for failure diagnosis. o The management interface needs to support dynamic control of the distribution of IP multicast data traffic. This control includes forwarding IP multicast traffic to the correct multicast group (SID), and managing the membership lists of each multicast group (SID). The CMTS MUST support configuring and viewing all IP multicast forwarding state, and all multicast group memberships, within the MAC domains of the CMTS. 3.3. Textual convention CableLabs has required the implementation of prior versions of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. The Baseline Privacy Interface MIB contains eight MIB objects defined with the (now obsolete) DisplayString textual convention, and one MIB object defined with the (now undesirable) IpAddress textual convention. In the judgment of the working group, it is preferable to keep these less-than-desirable textual conventions, in order to maintain backward compatibility and interoperability with DOCSIS 1.0 cable modems that implemented previous versions of this MIB. Woundy Informational [Page 7] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 4. Definitions DOCS-BPI-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, IpAddress FROM SNMPv2-SMI DisplayString, MacAddress, RowStatus, TruthValue, DateAndTime FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF ifIndex FROM IF-MIB docsIfMib, docsIfCmServiceId, docsIfCmtsServiceId FROM DOCS-IF-MIB ; docsBpiMIB MODULE-IDENTITY LAST-UPDATED "200103130000Z" ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO "Rich Woundy Postal: Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 U.S.A. Tel: +1 978 244 8000 E-mail: rwoundy@cisco.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, rwoundy@cisco.com Andrew Valentine, a.valentine@eu.hns.com" DESCRIPTION "This is the MIB Module for the DOCSIS Baseline Privacy Interface (BPI) at cable modems (CMs) and cable modem termination systems (CMTSs). CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification." REVISION "200103130000Z" DESCRIPTION "Version published as RFC 3083." REVISION "200011031930Z" DESCRIPTION "Modified by Richard Woundy to fix problems identified by the MIB Woundy Informational [Page 8] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 doctor. I marked docsBpiCmtsDefaultAuthGraceTime and docsBpiCmtsDefaultTEKGraceTime as obsolete objects, to prevent OID reassignment. Several object descriptions were also corrected." REVISION "200002161930Z" DESCRIPTION "Initial version. CableLabs requires the implementation of this MIB in certified DOCSIS 1.0 cable modems implementing the Baseline Privacy Interface, per DOCSIS 1.0 engineering change notice oss-n-99027." ::= { docsIfMib 5 } docsBpiMIBObjects OBJECT IDENTIFIER ::= { docsBpiMIB 1 } -- Cable Modem Group docsBpiCmObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 1 } -- -- The BPI base and authorization table for CMs, indexed by ifIndex -- docsBpiCmBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic and authorization-related Baseline Privacy attributes of each CM MAC interface." ::= { docsBpiCmObjects 1 } docsBpiCmBaseEntry OBJECT-TYPE SYNTAX DocsBpiCmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CM MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpiCmBaseTable 1 } DocsBpiCmBaseEntry ::= SEQUENCE { docsBpiCmPrivacyEnable TruthValue, docsBpiCmPublicKey OCTET STRING, docsBpiCmAuthState INTEGER, docsBpiCmAuthKeySequenceNumber Integer32, docsBpiCmAuthExpires DateAndTime, Woundy Informational [Page 9] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmAuthReset TruthValue, docsBpiCmAuthGraceTime Integer32, docsBpiCmTEKGraceTime Integer32, docsBpiCmAuthWaitTimeout Integer32, docsBpiCmReauthWaitTimeout Integer32, docsBpiCmOpWaitTimeout Integer32, docsBpiCmRekeyWaitTimeout Integer32, docsBpiCmAuthRejectWaitTimeout Integer32, docsBpiCmAuthRequests Counter32, docsBpiCmAuthReplies Counter32, docsBpiCmAuthRejects Counter32, docsBpiCmAuthInvalids Counter32, docsBpiCmAuthRejectErrorCode INTEGER, docsBpiCmAuthRejectErrorString DisplayString, docsBpiCmAuthInvalidErrorCode INTEGER, docsBpiCmAuthInvalidErrorString DisplayString } docsBpiCmPrivacyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this CM is provisioned to run Baseline Privacy. This is analogous to the presence (or absence) of the Baseline Privacy Configuration Setting option. The status of each individual SID with respect to Baseline Privacy is captured in the docsBpiCmTEKPrivacyEnable object." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1." ::= { docsBpiCmBaseEntry 1 } docsBpiCmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (74 | 106 | 140 | 270)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1) [22], corresponding to the public key of the CM. The 74, 106, 140, and 270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024 bit, and 2048 public moduli respectively." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.2.4." ::= { docsBpiCmBaseEntry 2 } docsBpiCmAuthState OBJECT-TYPE SYNTAX INTEGER { Woundy Informational [Page 10] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 authWait(2), authorized(3), reauthWait(4), authRejectWait(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the CM authorization FSM. The start state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.2.1." ::= { docsBpiCmBaseEntry 3 } docsBpiCmAuthKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the authorization key sequence number for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.10." ::= { docsBpiCmBaseEntry 4 } docsBpiCmAuthExpires OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time when the current authorization for this FSM expires. If the CM does not have an active authorization, then the value is of the expiration date and time of the last active authorization." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpiCmBaseEntry 5 } docsBpiCmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE." REFERENCE Woundy Informational [Page 11] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 "DOCSIS Baseline Privacy Interface Specification, Section 4.1.2.3.4." ::= { docsBpiCmBaseEntry 6 } docsBpiCmAuthGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for an authorization key. A CM is expected to start trying to get a new authorization key beginning AuthGraceTime seconds before the authorization key actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.3." ::= { docsBpiCmBaseEntry 7 } docsBpiCmTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for a TEK. A CM is expected to start trying to get a new TEK beginning TEKGraceTime seconds before the TEK actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.6." ::= { docsBpiCmBaseEntry 8 } docsBpiCmAuthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorize Wait Timeout." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.1." ::= { docsBpiCmBaseEntry 9 } docsBpiCmReauthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Reauthorize Wait Timeout in seconds." Woundy Informational [Page 12] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.2." ::= { docsBpiCmBaseEntry 10 } docsBpiCmOpWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Operational Wait Timeout in seconds." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.4." ::= { docsBpiCmBaseEntry 11 } docsBpiCmRekeyWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Rekey Wait Timeout in seconds." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.5." ::= { docsBpiCmBaseEntry 12 } docsBpiCmAuthRejectWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..600) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorization Reject Wait Timeout in seconds." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.7." ::= { docsBpiCmBaseEntry 13 } docsBpiCmAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has transmitted an Authorization Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmBaseEntry 14 } Woundy Informational [Page 13] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Reply message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmBaseEntry 15 } docsBpiCmAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Reject message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmBaseEntry 16 } docsBpiCmAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Invalid message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmBaseEntry 17 } docsBpiCmAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Reject message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Reject message has been received since reboot." Woundy Informational [Page 14] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.16." ::= { docsBpiCmBaseEntry 18 } docsBpiCmAuthRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Reject message received by the CM. This is a zero length string if no Authorization Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpiCmBaseEntry 19 } docsBpiCmAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Invalid message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.16." ::= { docsBpiCmBaseEntry 20 } docsBpiCmAuthInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Invalid message received by the CM. This is a zero Woundy Informational [Page 15] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 length string if no Authorization Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpiCmBaseEntry 21 } -- -- The CM TEK Table, indexed by ifIndex and SID -- docsBpiCmTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM Traffic Encryption Key (TEK) association. The CM maintains (no more than) one TEK association per SID per CM MAC interface." ::= { docsBpiCmObjects 2 } docsBpiCmTEKEntry OBJECT-TYPE SYNTAX DocsBpiCmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the TEK association attributes of one SID. The CM MUST create one entry per unicast SID, regardless of whether the SID was obtained from a Registration Response message, or from an Authorization Reply message." INDEX { ifIndex, docsIfCmServiceId } ::= { docsBpiCmTEKTable 1 } DocsBpiCmTEKEntry ::= SEQUENCE { docsBpiCmTEKPrivacyEnable TruthValue, docsBpiCmTEKState INTEGER, docsBpiCmTEKExpiresOld DateAndTime, docsBpiCmTEKExpiresNew DateAndTime, docsBpiCmTEKKeyRequests Counter32, docsBpiCmTEKKeyReplies Counter32, docsBpiCmTEKKeyRejects Counter32, docsBpiCmTEKInvalids Counter32, docsBpiCmTEKAuthPends Counter32, docsBpiCmTEKKeyRejectErrorCode INTEGER, docsBpiCmTEKKeyRejectErrorString DisplayString, docsBpiCmTEKInvalidErrorCode INTEGER, docsBpiCmTEKInvalidErrorString DisplayString } Woundy Informational [Page 16] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmTEKPrivacyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this SID is provisioned to run Baseline Privacy. This is analogous to enabling Baseline Privacy on a provisioned SID using the Class-of-Service Privacy Enable option. Baseline Privacy is not effectively enabled for any SID unless Baseline Privacy is enabled for the CM, which is managed via the docsBpiCmPrivacyEnable object." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.2." ::= { docsBpiCmTEKEntry 1 } docsBpiCmTEKState OBJECT-TYPE SYNTAX INTEGER { start(1), opWait(2), opReauthWait(3), operational(4), rekeyWait(5), rekeyReauthWait(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the indicated TEK FSM. The start(1) state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.1." ::= { docsBpiCmTEKEntry 2 } docsBpiCmTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmTEKEntry 3 } docsBpiCmTEKExpiresNew OBJECT-TYPE Woundy Informational [Page 17] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmTEKEntry 4 } docsBpiCmTEKKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has transmitted a Key Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.4." ::= { docsBpiCmTEKEntry 5 } docsBpiCmTEKKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a Key Reply message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5." ::= { docsBpiCmTEKEntry 6 } docsBpiCmTEKKeyRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received a Key Reject message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.6." ::= { docsBpiCmTEKEntry 7 } docsBpiCmTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Woundy Informational [Page 18] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 DESCRIPTION "The value of this object is the count of times the CM has received a TEK Invalid message, including a message whose authentication failed." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.8." ::= { docsBpiCmTEKEntry 8 } docsBpiCmTEKAuthPends OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times an Authorization Pending (Auth Pend) event occurred in this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.3.3." ::= { docsBpiCmTEKEntry 9 } docsBpiCmTEKKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Key Reject message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.6 and 4.2.2.16." ::= { docsBpiCmTEKEntry 10 } docsBpiCmTEKKeyRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Key Reject message received by the CM. This is a zero length string if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.6 and 4.2.2.6." ::= { docsBpiCmTEKEntry 11 } Woundy Informational [Page 19] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent TEK Invalid message received by the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.8 and 4.2.2.16." ::= { docsBpiCmTEKEntry 12 } docsBpiCmTEKInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent TEK Invalid message received by the CM. This is a zero length string if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.8 and 4.2.2.6." ::= { docsBpiCmTEKEntry 13 } -- Cable Modem Termination System Group docsBpiCmtsObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 2 } -- -- The BPI base table for CMTSs, indexed by ifIndex -- docsBpiCmtsBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic Baseline Privacy attributes of each CMTS MAC interface." ::= { docsBpiCmtsObjects 1 } Woundy Informational [Page 20] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmtsBaseEntry OBJECT-TYPE SYNTAX DocsBpiCmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CMTS MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpiCmtsBaseTable 1 } DocsBpiCmtsBaseEntry ::= SEQUENCE { docsBpiCmtsDefaultAuthLifetime Integer32, docsBpiCmtsDefaultTEKLifetime Integer32, docsBpiCmtsDefaultAuthGraceTime Integer32, docsBpiCmtsDefaultTEKGraceTime Integer32, docsBpiCmtsAuthRequests Counter32, docsBpiCmtsAuthReplies Counter32, docsBpiCmtsAuthRejects Counter32, docsBpiCmtsAuthInvalids Counter32 } docsBpiCmtsDefaultAuthLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, the CMTS assigns to a new authorization key." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.2." ::= { docsBpiCmtsBaseEntry 1 } docsBpiCmtsDefaultTEKLifetime OBJECT-TYPE SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, the CMTS assigns to a new Traffic Encryption Key (TEK)." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.2." ::= { docsBpiCmtsBaseEntry 2 } -- Note: the following two objects have been obsoleted from this MIB. Woundy Informational [Page 21] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmtsDefaultAuthGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-write STATUS obsolete DESCRIPTION "This object was obsoleted because the provisioning system, not the CMTS, manages the authorization key grace time for DOCSIS CMs." ::= { docsBpiCmtsBaseEntry 3 } docsBpiCmtsDefaultTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-write STATUS obsolete DESCRIPTION "This object was obsoleted because the provisioning system, not the CMTS, manages the Traffic Encryption Key (TEK) grace time for DOCSIS CMs." ::= { docsBpiCmtsBaseEntry 4 } docsBpiCmtsAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received an Authorization Request message from any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmtsBaseEntry 5 } docsBpiCmtsAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reply message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmtsBaseEntry 6 } docsBpiCmtsAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has Woundy Informational [Page 22] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 transmitted an Authorization Reject message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmtsBaseEntry 7 } docsBpiCmtsAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Invalid message to any CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmtsBaseEntry 8 } -- -- The CMTS Authorization Table, indexed by ifIndex and CM MAC address -- docsBpiCmtsAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM authorization association. The CMTS maintains one authorization association with each Baseline Privacy-enabled CM on each CMTS MAC interface." ::= { docsBpiCmtsObjects 2 } docsBpiCmtsAuthEntry OBJECT-TYPE SYNTAX DocsBpiCmtsAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one authorization association. The CMTS MUST create one entry per CM per MAC interface, based on the receipt of an Authorization Request message, and MUST not delete the entry before the CM authorization permanently expires." INDEX { ifIndex, docsBpiCmtsAuthCmMacAddress } ::= { docsBpiCmtsAuthTable 1 } DocsBpiCmtsAuthEntry ::= SEQUENCE { docsBpiCmtsAuthCmMacAddress MacAddress, docsBpiCmtsAuthCmPublicKey OCTET STRING, docsBpiCmtsAuthCmKeySequenceNumber Integer32, docsBpiCmtsAuthCmExpires DateAndTime, Woundy Informational [Page 23] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmtsAuthCmLifetime Integer32, docsBpiCmtsAuthCmGraceTime Integer32, docsBpiCmtsAuthCmReset INTEGER, docsBpiCmtsAuthCmRequests Counter32, docsBpiCmtsAuthCmReplies Counter32, docsBpiCmtsAuthCmRejects Counter32, docsBpiCmtsAuthCmInvalids Counter32, docsBpiCmtsAuthRejectErrorCode INTEGER, docsBpiCmtsAuthRejectErrorString DisplayString, docsBpiCmtsAuthInvalidErrorCode INTEGER, docsBpiCmtsAuthInvalidErrorString DisplayString } docsBpiCmtsAuthCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is the physical address of the CM to which the authorization association applies." ::= { docsBpiCmtsAuthEntry 1 } docsBpiCmtsAuthCmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 74 | 106 | 140 | 270)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1) [22], corresponding to the public key of the CM. The 74, 106, 140, and 270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024 bit, and 2048 public moduli respectively. This is a zero-length string if the CMTS does not retain the public key." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.2.4." ::= { docsBpiCmtsAuthEntry 2 } docsBpiCmtsAuthCmKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the authorization key sequence number for this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.10." Woundy Informational [Page 24] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 ::= { docsBpiCmtsAuthEntry 3 } docsBpiCmtsAuthCmExpires OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time when the current authorization for this CM expires. If this CM does not have an active authorization, then the value is of the expiration date and time of the last active authorization." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpiCmtsAuthEntry 4 } docsBpiCmtsAuthCmLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, the CMTS assigns to an authorization key for this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2 and Appendix A.2." ::= { docsBpiCmtsAuthEntry 5 } docsBpiCmtsAuthCmGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for the authorization key in seconds. The CM is expected to start trying to get a new authorization key beginning AuthGraceTime seconds before the authorization key actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.3." ::= { docsBpiCmtsAuthEntry 6 } docsBpiCmtsAuthCmReset OBJECT-TYPE SYNTAX INTEGER { noResetRequested(1), invalidateAuth(2), sendAuthInvalid(3), Woundy Informational [Page 25] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 invalidateTeks(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to invalidateAuth(2) causes the CMTS to invalidate the current CM authorization key, but not to transmit an Authorization Invalid message nor to invalidate unicast TEKs. Setting this object to sendAuthInvalid(3) causes the CMTS to invalidate the current CM authorization key, and to transmit an Authorization Invalid message to the CM, but not to invalidate unicast TEKs. Setting this object to invalidateTeks(4) causes the CMTS to invalidate the current CM authorization key, to transmit an Authorization Invalid message to the CM, and to invalidate all unicast TEKs associated with this CM authorization. Reading this object returns the most-recently-set value of this object, or returns noResetRequested(1) if the object has not been set since the last CMTS reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.1.2.3.4, 4.1.2.3.5, and 4.1.3.3.5." ::= { docsBpiCmtsAuthEntry 7 } docsBpiCmtsAuthCmRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received an Authorization Request message from this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.1." ::= { docsBpiCmtsAuthEntry 8 } docsBpiCmtsAuthCmReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reply message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.2." ::= { docsBpiCmtsAuthEntry 9 } docsBpiCmtsAuthCmRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Woundy Informational [Page 26] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Reject message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.3." ::= { docsBpiCmtsAuthEntry 10 } docsBpiCmtsAuthCmInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted an Authorization Invalid message to this CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.7." ::= { docsBpiCmtsAuthEntry 11 } docsBpiCmtsAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Reject message transmitted to the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Reject message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.16." ::= { docsBpiCmtsAuthEntry 12 } docsBpiCmtsAuthRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Reject message transmitted to the CM. This is a zero length string if no Authorization Reject message has been transmitted to the CM." REFERENCE Woundy Informational [Page 27] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpiCmtsAuthEntry 13 } docsBpiCmtsAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in most recent Authorization Invalid message transmitted to the CM. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Authorization Invalid message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.16." ::= { docsBpiCmtsAuthEntry 14 } docsBpiCmtsAuthInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in most recent Authorization Invalid message transmitted to the CM. This is a zero length string if no Authorization Invalid message has been transmitted to the CM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpiCmtsAuthEntry 15 } -- -- The CMTS TEK Table, indexed by ifIndex and SID -- docsBpiCmtsTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiCmtsTEKEntry MAX-ACCESS not-accessible STATUS current Woundy Informational [Page 28] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 DESCRIPTION "This table describes the attributes of each CM Traffic Encryption Key (TEK) association. The CMTS maintains one TEK association per BPI SID on each CMTS MAC interface." ::= { docsBpiCmtsObjects 3 } docsBpiCmtsTEKEntry OBJECT-TYPE SYNTAX DocsBpiCmtsTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one TEK association on a particular CMTS MAC interface. The CMTS MUST create one entry per SID per MAC interface, based on the receipt of an Key Request message, and MUST not delete the entry before the CM authorization for the SID permanently expires." INDEX { ifIndex, docsIfCmtsServiceId } ::= { docsBpiCmtsTEKTable 1 } DocsBpiCmtsTEKEntry ::= SEQUENCE { docsBpiCmtsTEKLifetime Integer32, docsBpiCmtsTEKGraceTime Integer32, docsBpiCmtsTEKExpiresOld DateAndTime, docsBpiCmtsTEKExpiresNew DateAndTime, docsBpiCmtsTEKReset TruthValue, docsBpiCmtsKeyRequests Counter32, docsBpiCmtsKeyReplies Counter32, docsBpiCmtsKeyRejects Counter32, docsBpiCmtsTEKInvalids Counter32, docsBpiCmtsKeyRejectErrorCode INTEGER, docsBpiCmtsKeyRejectErrorString DisplayString, docsBpiCmtsTEKInvalidErrorCode INTEGER, docsBpiCmtsTEKInvalidErrorString DisplayString } docsBpiCmtsTEKLifetime OBJECT-TYPE SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, the CMTS assigns to keys for this TEK association." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5 and Appendix A.2." ::= { docsBpiCmtsTEKEntry 1 } Woundy Informational [Page 29] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmtsTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for the TEK in seconds. The CM is expected to start trying to get a new TEK beginning TEKGraceTime seconds before the TEK actually expires." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Appendix A.1.1.1.6." ::= { docsBpiCmtsTEKEntry 2 } docsBpiCmtsTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmtsTEKEntry 3 } docsBpiCmtsTEKExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpiCmtsTEKEntry 4 } docsBpiCmtsTEKReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE causes the CMTS to invalidate the current active TEK(s) (plural due to key transition periods), and to generate a new TEK for the associated SID; the CMTS MAY also generate an unsolicited TEK Invalid message, to optimize the TEK synchronization Woundy Informational [Page 30] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 between the CMTS and the CM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.3.3.5." ::= { docsBpiCmtsTEKEntry 5 } docsBpiCmtsKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has received a Key Request message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.4." ::= { docsBpiCmtsTEKEntry 6 } docsBpiCmtsKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a Key Reply message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.5." ::= { docsBpiCmtsTEKEntry 7 } docsBpiCmtsKeyRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a Key Reject message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.6." ::= { docsBpiCmtsTEKEntry 8 } docsBpiCmtsTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CMTS has transmitted a TEK Invalid message." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.2.1.8." Woundy Informational [Page 31] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 ::= { docsBpiCmtsTEKEntry 9 } docsBpiCmtsKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Key Reject message sent in response to a Key Request for this BPI SID. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.6 and 4.2.2.16." ::= { docsBpiCmtsTEKEntry 10 } docsBpiCmtsKeyRejectErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in the most recent Key Reject message sent in response to a Key Request for this BPI SID. This is a zero length string if no Key Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.6 and 4.2.2.6." ::= { docsBpiCmtsTEKEntry 11 } docsBpiCmtsTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent TEK Invalid message sent in association with this BPI SID. This has value unknown(2) if the last Error-Code value was 0, and none(1) if no TEK Invalid message has been received Woundy Informational [Page 32] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.8 and 4.2.2.16." ::= { docsBpiCmtsTEKEntry 12 } docsBpiCmtsTEKInvalidErrorString OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Display-String in the most recent TEK Invalid message sent in association with this BPI SID. This is a zero length string if no TEK Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Sections 4.2.1.8 and 4.2.2.6." ::= { docsBpiCmtsTEKEntry 13 } -- -- The CMTS Multicast Control Group -- docsBpiMulticastControl OBJECT IDENTIFIER ::= { docsBpiCmtsObjects 4 } -- -- The CMTS IP Multicast Mapping Table, indexed by IP multicast -- address and prefix, and by ifindex -- docsBpiIpMulticastMapTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the mapping of IP multicast address prefixes to multicast SIDs on each CMTS MAC interface." ::= { docsBpiMulticastControl 1 } docsBpiIpMulticastMapEntry OBJECT-TYPE SYNTAX DocsBpiIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the mapping of one IP multicast address prefix to one multicast SID on one CMTS MAC interface. The CMTS uses the mapping when forwarding downstream IP multicast traffic." Woundy Informational [Page 33] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 INDEX { ifIndex, docsBpiIpMulticastAddress, docsBpiIpMulticastPrefixLength } ::= { docsBpiIpMulticastMapTable 1 } DocsBpiIpMulticastMapEntry ::= SEQUENCE { docsBpiIpMulticastAddress IpAddress, docsBpiIpMulticastPrefixLength Integer32, docsBpiIpMulticastServiceId Integer32, docsBpiIpMulticastMapControl RowStatus } docsBpiIpMulticastAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the IP multicast address (prefix) to be mapped by this row, in conjunction with docsBpiIpMulticastPrefixLength." ::= { docsBpiIpMulticastMapEntry 1 } docsBpiIpMulticastPrefixLength OBJECT-TYPE SYNTAX Integer32 (0..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the IP multicast address prefix length for this row. The value of this object represents the length in bits of docsBpiIpMulticastAddress for multicast address comparisons, using big-endian ordering. An IP multicast address matches this row if the (docsBpiIpMulticastPrefixLength) most significant bits of the IP multicast address and of the (docsBpiIpMulticastAddress) are identical. This object is similar in usage to an IP address mask. The value 0 corresponds to IP address mask 0.0.0.0, the value 1 corresponds to IP address mask 128.0.0.0, the value 8 corresponds to IP address mask 255.0.0.0, and the value 32 corresponds to IP address mask 255.255.255.255." ::= { docsBpiIpMulticastMapEntry 2 } docsBpiIpMulticastServiceId OBJECT-TYPE SYNTAX Integer32 (8192..16368) MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the multicast SID to be used in this IP multicast address prefix mapping entry." -- DEFVAL is an unused multicast SID value chosen by CMTS. Woundy Informational [Page 34] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 ::= { docsBpiIpMulticastMapEntry 3 } docsBpiIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address prefix mapping entry. There is no restriction on the ability to change values in this row while the row is active." ::= { docsBpiIpMulticastMapEntry 4 } -- -- The CMTS Multicast SID Authorization Table, indexed by ifIndex by -- multicast SID by CM MAC address -- docsBpiMulticastAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpiMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the multicast SID authorization for each CM on each CMTS MAC interface." ::= { docsBpiMulticastControl 2 } docsBpiMulticastAuthEntry OBJECT-TYPE SYNTAX DocsBpiMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the key authorization of one cable modem for one multicast SID for one CMTS MAC interface." INDEX { ifIndex, docsBpiMulticastServiceId, docsBpiMulticastCmMacAddress } ::= { docsBpiMulticastAuthTable 1 } DocsBpiMulticastAuthEntry ::= SEQUENCE { docsBpiMulticastServiceId Integer32, docsBpiMulticastCmMacAddress MacAddress, docsBpiMulticastAuthControl RowStatus } docsBpiMulticastServiceId OBJECT-TYPE SYNTAX Integer32 (8192..16368) MAX-ACCESS not-accessible STATUS current DESCRIPTION Woundy Informational [Page 35] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 "This object represents the multicast SID for authorization." ::= { docsBpiMulticastAuthEntry 1 } docsBpiMulticastCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the MAC address of the CM to which the multicast SID authorization applies." ::= { docsBpiMulticastAuthEntry 2 } docsBpiMulticastAuthControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the CM authorization for each multicast SID. There is no restriction on the ability to change values in this row while the row is active." ::= { docsBpiMulticastAuthEntry 3 } -- -- The BPI MIB Conformance Statements (with a placeholder for -- notifications) -- docsBpiNotification OBJECT IDENTIFIER ::= { docsBpiMIB 2 } docsBpiConformance OBJECT IDENTIFIER ::= { docsBpiMIB 3 } docsBpiCompliances OBJECT IDENTIFIER ::= { docsBpiConformance 1 } docsBpiGroups OBJECT IDENTIFIER ::= { docsBpiConformance 2 } docsBpiBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This is the compliance statement for devices which implement the DOCSIS Baseline Privacy Interface." MODULE -- docsBpiMIB -- conditionally mandatory group GROUP docsBpiCmGroup DESCRIPTION "This group is implemented only in CMs, not in CMTSs." -- conditionally mandatory group GROUP docsBpiCmtsGroup DESCRIPTION Woundy Informational [Page 36] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 "This group is implemented only in CMTSs, not in CMs." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmAuthGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmTEKGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsDefaultAuthLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsDefaultTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (object removed from MIB) -- OBJECT docsBpiCmtsDefaultAuthGraceTime -- SYNTAX INTEGER (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (object removed from MIB) -- OBJECT docsBpiCmtsDefaultTEKGraceTime -- SYNTAX INTEGER (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsAuthCmLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION Woundy Informational [Page 37] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmtsAuthCmGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range OBJECT docsBpiCmtsTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks, according to Appendix A.2 in [18]." -- relaxation on mandatory range (unnecessary since object is read-only) -- OBJECT docsBpiCmtsTEKGraceTime -- SYNTAX Integer32 (300..1800) -- DESCRIPTION -- "The refined range corresponds to the minimum and maximum values in -- operational networks, according to Appendix A.2 in [18]." ::= { docsBpiCompliances 1 } docsBpiCmGroup OBJECT-GROUP OBJECTS { docsBpiCmPrivacyEnable, docsBpiCmPublicKey, docsBpiCmAuthState, docsBpiCmAuthKeySequenceNumber, docsBpiCmAuthExpires, docsBpiCmAuthReset, docsBpiCmAuthGraceTime, docsBpiCmTEKGraceTime, docsBpiCmAuthWaitTimeout, docsBpiCmReauthWaitTimeout, docsBpiCmOpWaitTimeout, docsBpiCmRekeyWaitTimeout, docsBpiCmAuthRejectWaitTimeout, docsBpiCmAuthRequests, docsBpiCmAuthReplies, docsBpiCmAuthRejects, docsBpiCmAuthInvalids, docsBpiCmAuthRejectErrorCode, docsBpiCmAuthRejectErrorString, docsBpiCmAuthInvalidErrorCode, Woundy Informational [Page 38] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmAuthInvalidErrorString, docsBpiCmTEKPrivacyEnable, docsBpiCmTEKState, docsBpiCmTEKExpiresOld, docsBpiCmTEKExpiresNew, docsBpiCmTEKKeyRequests, docsBpiCmTEKKeyReplies, docsBpiCmTEKKeyRejects, docsBpiCmTEKInvalids, docsBpiCmTEKAuthPends, docsBpiCmTEKKeyRejectErrorCode, docsBpiCmTEKKeyRejectErrorString, docsBpiCmTEKInvalidErrorCode, docsBpiCmTEKInvalidErrorString } STATUS current DESCRIPTION "This collection of objects provides CM BPI status and control." ::= { docsBpiGroups 1 } docsBpiCmtsGroup OBJECT-GROUP OBJECTS { docsBpiCmtsDefaultAuthLifetime, docsBpiCmtsDefaultTEKLifetime, docsBpiCmtsAuthRequests, docsBpiCmtsAuthReplies, docsBpiCmtsAuthRejects, docsBpiCmtsAuthInvalids, docsBpiCmtsAuthCmPublicKey, docsBpiCmtsAuthCmKeySequenceNumber, docsBpiCmtsAuthCmExpires, docsBpiCmtsAuthCmLifetime, docsBpiCmtsAuthCmGraceTime, docsBpiCmtsAuthCmReset, docsBpiCmtsAuthCmRequests, docsBpiCmtsAuthCmReplies, docsBpiCmtsAuthCmRejects, docsBpiCmtsAuthCmInvalids, docsBpiCmtsAuthRejectErrorCode, docsBpiCmtsAuthRejectErrorString, docsBpiCmtsAuthInvalidErrorCode, docsBpiCmtsAuthInvalidErrorString, docsBpiCmtsTEKLifetime, docsBpiCmtsTEKGraceTime, docsBpiCmtsTEKExpiresOld, docsBpiCmtsTEKExpiresNew, docsBpiCmtsTEKReset, docsBpiCmtsKeyRequests, Woundy Informational [Page 39] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 docsBpiCmtsKeyReplies, docsBpiCmtsKeyRejects, docsBpiCmtsTEKInvalids, docsBpiCmtsKeyRejectErrorCode, docsBpiCmtsKeyRejectErrorString, docsBpiCmtsTEKInvalidErrorCode, docsBpiCmtsTEKInvalidErrorString, docsBpiIpMulticastServiceId, docsBpiIpMulticastMapControl, docsBpiMulticastAuthControl } STATUS current DESCRIPTION "This collection of objects provides CMTS BPI status and control." ::= { docsBpiGroups 2 } docsBpiObsoleteObjectsGroup OBJECT-GROUP OBJECTS { docsBpiCmtsDefaultAuthGraceTime, docsBpiCmtsDefaultTEKGraceTime } STATUS obsolete DESCRIPTION "This is a collection of obsolete BPI objects." ::= { docsBpiGroups 3 } END 5. Acknowledgments This document was produced by the IPCDN Working Group. Much of the content of this MIB was conceived by Chet Birger and Mike StJohns. Kazuyoshi Ozawa and Bob Himlin provided many useful technical corrections. 6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. Woundy Informational [Page 40] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of e Management Information for Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] St. Johns, M., editor, "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. Woundy Informational [Page 41] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 [17] St. Johns, M., editor, "DOCSIS Cable Device MIB, Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999. [18] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Interface Specification SP-BPI-I02-990319", DOCSIS, March 1999, http://www.cablemodem.com/. [19] "Data-Over-Cable Service Interface Specifications: Cable Modem Radio Frequency Interface Specification SP-RFI-I05-991105", DOCSIS, November 1999, http://www.cablemodem.com/. [20] "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification RF Interface SP-OSSI-RF- I02-990113", DOCSIS, January 1999, http://www.cablemodem.com/. [21] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification SP-BPI+-I05-000714", DOCSIS, July 2000, http://www.cablemodem.com/. [22] RSA Laboratories, "The Public-Key Cryptography Standards", RSA Data Security Inc., Redwood City, CA. [23] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [24] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. 7. Security Considerations The Baseline Privacy Interface provides data encryption for DOCSIS data-over-cable services. Baseline Privacy-capable cable modems have RSA private/public key pairs installed by manufacturers. The public key is used to encrypt an Authorization key, and the Authorization key is used to encrypt one or more Traffic Encryption Keys (TEKs). The TEKs are used to encrypt both upstream and downstream data traffic. Please refer to [18] to obtain further information on the Baseline Privacy specification. In particular, the Baseline Privacy Interface does not provide an authentication service. CMTS implementors are encouraged not to rely on the MAC address of the CM for service authorization -- in particular, for the docsBpiMulticastAuthTable in this MIB. The Baseline Privacy Plus Interface does provide a CM authentication service, and the working group expects to issue a MIB for the management of BPI+ at a later time. Woundy Informational [Page 42] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 This MIB specification contains a number of read-write objects, that should be protected from unauthorized modification to prevent denial of service and theft of service attacks: in particular, objects that reset state machines (ex. docsBpiCmAuthReset), change key lifetimes (ex. docsBpiCmtsDefaultAuthLifetime), change rekeying grace times (ex. docsBpiCmtsDefaultAuthGraceTime), and control multicast traffic (ex. most objects in the docsBpiMulticastControl group). The desired means to protect these objects from unwarranted access is to implement the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [12] and the View-based Access Control Model [15] is recommended. Weaker methods to protect CMs from unauthorized access include using the docsDevNmAccessTable from the Cable Device MIB [17] to disallow configuration changes from unauthorized network management stations, and using the SNMP MIB Object and SNMP Write-Access Control configuration file options from the Radio Frequency Interface [19] to set MIB object values and disable SNMP SET operations at cable modem boot time. Note that these mechanisms may be vulnerable to an unauthorized network management station "spoofing" the source address of a legitimate network management station. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Woundy Informational [Page 43] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 9. Author's Address Richard Woundy Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 U.S.A. Phone: +1 978 244 8000 EMail: rwoundy@cisco.com Woundy Informational [Page 44] RFC 3083 DOCSIS Baseline Privacy MIB March 2001 10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Woundy Informational [Page 45] snmp-mibs-downloader-1.1/mibrfcs/rfc3144.txt0000644000000000000000000017203311402176071015563 0ustar Network Working Group D. Romascanu Request for Comments: 3144 Avaya, Inc. Category: Standards Track August 2001 Remote Monitoring MIB Extensions for Interface Parameters Monitoring 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. Table of Contents 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . 2 2 The SNMP Management Framework . . . . . . . . . . . . . . . 2 3 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 MIB Structure . . . . . . . . . . . . . . . . . . . . . . . 4 5 Evolution of the Document, Limitations and Future Work. . . 4 6 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 7 References. . . . . . . . . . . . . . . . . . . . . . . . . 26 8 Intellectual Property . . . . . . . . . . . . . . . . . . . 28 9 Security Considerations . . . . . . . . . . . . . . . . . . 29 10 Author's Address . . . . . . . . . . . . . . . . . . . . . 29 11 Full Copyright Statement . . . . . . . . . . . . . . . . . 30 Romascanu Standards Track [Page 1] RFC 3144 Remote Monitoring MIB Extensions August 2001 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. This memo also includes a MIB module. This MIB module extends the list of managed objects specified in [RFC2819] and [RFC2613]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMEND", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. Romascanu Standards Track [Page 2] RFC 3144 Remote Monitoring MIB Extensions August 2001 A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This document continues the architecture created in the RMON MIB [RFC2819] and extended by the SMON MIB [RFC2613] by providing a method of ordering the interfaces of a device according to the value of a specific parameter that characterizes the interfaces. The need for such a technique derives from the evolution of the network devices - bridges, routers, etc., into complex entities with a large number of interfaces and with many parameters that need to be monitored on each interface. It is common for certain classes of switching devices to contain hundred of ports, and for each port to instrument and support tens of parameters - usually expressed as counters - for each interface. As a result, it becomes impossible for applications that monitor these devices to provide a view that would allow the user to understand easily what is the status of the device, whether the behavior of a port or interface is in normal boundaries or not, and which are the most congested or problematic interfaces of the device. This document tries to answer this problem by proposing a method of providing a sorted list of interfaces according to programmable criteria. The result of applying this method will be a shorter list, that includes the most significant interfaces sorted according to the selected criteria. One possible action that can be taken by a network manager could be applying to this interface a copy port operation to a destination port that has a dedicated monitoring device (e.g., a network analyzer) connected to it. A standard MIB interface for performing this operation is described in [RFC2613]. Romascanu Standards Track [Page 3] RFC 3144 Remote Monitoring MIB Extensions August 2001 4. MIB Structure This MIB contains one MIB group: - The interfaceTopNObjects The interfaceTopNObjects includes one capability object and two tables: - The interfaceControlTable - The interfaceTopNTable The interfaceControlTable is an RMON-style control table, allowing for the creation of interfaceTopN reports. The parameters specific for each report, like the duration of the report, the number of reports, start time and the characteristics of the variables that are sorted (absolute, 'deltas' or percentage of the total bandwidth) are set in this table. An optional operation that is controlled from this table is the normalization of values of the variables, which allows for sorting of variables on the interfaces, despite the basic speed of the interfaces being different on different interfaces. 5. Evolution of the Document, Limitations and Future Work The RMON MIB Working Group included in its Charter a MIB document that would offer a solution to the problem of quickly determining the most congested (highest utilized) physical ports and links in an RMON-capable device with multiple interfaces. An initial solution, proposed in the first version of this document included a limited approach. The objects whose values are used as criteria for sorting are elements in tables indexed by an InterfaceIndex type of object, as defined in [RFC2863]. This approach simplifies the search algorithm and the result table, but restricts the method to interface parameters. A more generic ' usrTopN' function was initially considered out of the scope of this work. At the Working Group meeting in Adelaide in March 2000, it was decided to try to define the more generic function of usrTopN. Under this approach, variables belonging to tables with any type of index can be sorted, but at expense of extra processing and sanity checking by the agent. At the interim meeting of the RMON Working Group in San Francisco, in May 2000, it was decided that the usrTopN solution would not be continued in this phase of the work. One of the reasons is that it is difficult to achieve a normalization factor for a generic Romascanu Standards Track [Page 4] RFC 3144 Remote Monitoring MIB Extensions August 2001 approach. The group agreed it is not desirable to require the application to plug-in the scaling factor for every instance that might be included in a TopN report. 6. Definitions INTERFACETOPN-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32 FROM SNMPv2-SMI RowStatus, TimeStamp, TruthValue FROM SNMPv2-TC rmon, OwnerString FROM RMON-MIB CounterBasedGauge64 FROM HCNUM-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; interfaceTopNMIB MODULE-IDENTITY LAST-UPDATED "200103270000Z" ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO " Dan Romascanu Avaya Inc. Tel: +972-3-645-8414 Email: dromasca@avaya.com" DESCRIPTION "The MIB module for sorting device interfaces for RMON and SMON monitoring in a multiple device implementation." ::= { rmon 27 } interfaceTopNObjects OBJECT IDENTIFIER ::= { interfaceTopNMIB 1 } interfaceTopNNotifications OBJECT IDENTIFIER ::= { interfaceTopNMIB 2 } interfaceTopNConformance OBJECT IDENTIFIER ::= { interfaceTopNMIB 3 } -- The Interface Top N group is used to prepare reports that -- describe a list of interfaces (data sources) -- ordered by the values of one -- of the objects that apply to the interfaces of the respective device. -- Those objects are defined by standard MIBs. The exact objects that -- are supported by the agent are described by interfaceTopNCaps -- The objects must be elements in tables indexed only by an -- InterfaceIndex object. -- The objects chosen by the Romascanu Standards Track [Page 5] RFC 3144 Remote Monitoring MIB Extensions August 2001 -- management station may be sampled over a management -- station-specified time interval, making the report rate based. -- The management station also specifies the number of interfaces -- that are reported. -- -- The interfaceTopNControlTable is used to initiate the generation -- of a report. The management station may select the parameters -- of such a report, such as which object, how -- many interfaces, and the start & stop times of the sampling. When -- the report is prepared, entries are created in the -- interfaceTopNTable associated with the relevant -- interfaceTopNControlEntry. These entries are static for -- each report after it has been prepared. interfaceTopNCaps OBJECT-TYPE SYNTAX BITS { ifInOctets(0), ifInUcastPkts(1), ifInNUcastPkts(2), ifInDiscards(3), ifInErrors(4), ifInUnknownProtos(5), ifOutOctets(6), ifOutUcastPkts(7), ifOutNUcastPkts(8), ifOutDiscards(9), ifOutErrors(10), ifInMulticastPkts(11), ifInBroadcastPkts(12), ifOutMulticastPkts(13), ifOutBroadcastPkts(14), ifHCInOctets(15), ifHCInUcastPkts(16), ifHCInMulticastPkts(17), ifHCInBroadcastPkts(18), ifHCOutOctets(19), ifHCOutUcastPkts(20), ifHCOutMulticastPkts(21), ifHCOutBroadcastPkts(22), dot3StatsAlignmentErrors(23), dot3StatsFCSErrors(24), dot3StatsSingleCollisionFrames(25), dot3StatsMultipleCollisionFrames(26), dot3StatsSQETestErrors(27), dot3StatsDeferredTransmissions(28), dot3StatsLateCollisions(29), dot3StatsExcessiveCollisions(30), dot3StatsInternalMacTxErrors(31), Romascanu Standards Track [Page 6] RFC 3144 Remote Monitoring MIB Extensions August 2001 dot3StatsCarrierSenseErrors(32), dot3StatsFrameTooLongs(33), dot3StatsInternalMacRxErrors(34), dot3StatsSymbolErrors(35), dot3InPauseFrames(36), dot3OutPauseFrames(37), dot5StatsLineErrors(38), dot5StatsBurstErrors(39), dot5StatsACErrors(40), dot5StatsAbortTransErrors(41), dot5StatsInternalErrors(42), dot5StatsLostFrameErrors(43), dot5StatsReceiveCongestions(44), dot5StatsFrameCopiedErrors(45), dot5StatsTokenErrors(46), dot5StatsSoftErrors(47), dot5StatsHardErrors(48), dot5StatsSignalLoss(49), dot5StatsTransmitBeacons(50), dot5StatsRecoverys(51), dot5StatsLobeWires(52), dot5StatsRemoves(53), dot5StatsSingles(54), dot5StatsFreqErrors(55), etherStatsDropEvents(56), etherStatsOctets(57), etherStatsPkts(58), etherStatsBroadcastPkts(59), etherStatsMulticastPkts(60), etherStatsCRCAlignErrors(61), etherStatsUndersizePkts(62), etherStatsOversizePkts(63), etherStatsFragments(64), etherStatsJabbers(65), etherStatsCollisions(66), etherStatsPkts64Octets(67), etherStatsPkts65to127Octets(68), etherStatsPkts128to255Octets(69), etherStatsPkts256to511Octets(70), etherStatsPkts512to1023Octets(71), etherStatsPkts1024to1518Octets(72), dot1dTpPortInFrames(73), dot1dTpPortOutFrames(74), dot1dTpPortInDiscards(75) } MAX-ACCESS read-only STATUS current DESCRIPTION Romascanu Standards Track [Page 7] RFC 3144 Remote Monitoring MIB Extensions August 2001 "The type(s) of sorting capabilities supported by the agent. If the agent can perform sorting of interfaces according to the values of ifInOctets, as defined in [RFC2863], then the 'ifInOctets' bit will be set. If the agent can perform sorting of interfaces according to the values of ifInUcastPkts, as defined in [RFC2863], then the 'ifInUcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifInNUcastPkts, as defined in [RFC2863], then the 'ifInNUcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifInDiscards, as defined in [RFC2863], then the 'ifInDiscards' bit will be set. If the agent can perform sorting of interfaces according to the values of ifInErrors, as defined in [RFC2863], then the 'ifInErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of ifInUnknownProtocols, as defined in [RFC2863], then the 'ifInUnknownProtocols' bit will be set. If the agent can perform sorting of interfaces according to the values of ifOutOctets, as defined in [RFC2863], then the 'ifOutOctets' bit will be set. If the agent can perform sorting of interfaces according to the values of ifOutUcastPackets, as defined in [RFC2863], then the 'ifOutUcastPackets' bit will be set. If the agent can perform sorting of interfaces according to the values of ifOutNUcastPackets, as defined in [RFC2863], then the 'ifOutNUcastPackets' bit will be set. If the agent can perform sorting of interfaces according to the values of ifOutDiscards, as defined in [RFC2863], then the 'ifOutDiscards' bit will be set. If the agent can perform sorting of interfaces according to the values of ifOutErrors, as defined in [RFC2863], then the 'ifOutErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of ifInMulticastPkts, as defined in [RFC2863], Romascanu Standards Track [Page 8] RFC 3144 Remote Monitoring MIB Extensions August 2001 then the 'ifInMulticastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifInBroadcastPkts, as defined in [RFC2863], then the 'ifInBroadcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifOutMulticastPkts, as defined in [RFC2863], then the 'ifOutMulticastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifOutBroadcastPkts, as defined in [RFC2863], then the 'ifOutBroadcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifHCInOctets, as defined in [RFC2863], then the 'ifHCInOctets' bit will be set. If the agent can perform sorting of interfaces according to the values of ifHCInMulticastPkts, as defined in [RFC2863], then the 'ifHCInMulticastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifHCInBroadcastPkts, as defined in [RFC2863], then the 'ifHCInBroadcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifHCOutOctets, as defined in [RFC2863], then the 'ifHCOutOctets' bit will be set. If the agent can perform sorting of interfaces according to the values of ifHCOutUcastPkts, as defined in [RFC2863], then the 'ifHCOutUcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifHCOutMulticastPkts, as defined in [RFC2863], then the 'ifHCOutMulticastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of ifHCOutBroadcastPkts, as defined in [RFC2863], then the 'ifHCOutBroadcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsAlignmentErrors, as defined in [RFC2665], then the 'dot3StatsAlignmentErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsFCSErrors, as defined in [RFC2665], Romascanu Standards Track [Page 9] RFC 3144 Remote Monitoring MIB Extensions August 2001 then the 'dot3StatsFCSErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsSingleCollisionFrames, as defined in [RFC2665],then the 'dot3StatsSingleCollisionFrames' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsSQETestErrors, as defined in [RFC2665], then the 'dot3StatsSQETestErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsDeferredTransmissions, as defined in [RFC2665], then the 'dot3StatsDeferredTransmissions' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsLateCollisions, as defined in [RFC2665], then the 'dot3StatsLateCollisions' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsExcessiveCollisions, as defined in [RFC2665], then the 'dot3StatsExcessiveCollisions' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsInternalMacTxErrors, as defined in [RFC2665],then the 'dot3StatsInternalMacTxErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsCarrierSenseErrors, as defined in [RFC2665], then the 'dot3StatsCarrierSenseErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsFrameTooLongs, as defined in [RFC2665], then the 'dot3StatsFrameTooLongs' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsInternalMacRxErrors, as defined in [RFC2665], then the 'dot3StatsInternalMacRxErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3StatsSymbolErrors, as defined in [RFC2665], then the 'dot3StatsSymbolErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3InPauseFrames, as defined in [RFC2665], Romascanu Standards Track [Page 10] RFC 3144 Remote Monitoring MIB Extensions August 2001 then the 'dot3InPauseFrames' bit will be set. If the agent can perform sorting of interfaces according to the values of dot3OutPauseFrames, as defined in [RFC2665], then the 'dot3OutPauseFrames' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsLineErrors, as defined in [RFC1748], then the 'dot5StatsLineErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsBurstErrors, as defined in [RFC1748], then the 'dot5StatsBurstErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsACErrors, as defined in [RFC1748], then the 'dot5StatsACErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsAbortTransErrors, as defined in [RFC1748], then the 'dot5StatsAbortTransErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsInternalErrors, as defined in [RFC1748], then the 'dot5StatsInternalErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsLostFrameErrors, as defined in [RFC1748], then the 'dot5StatsLostFrameErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsReceiveCongestionErrors, as defined in [RFC1748], then the 'dot5StatsReceiveCongestionErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsFrameCopiedErrors, as defined in [RFC1748], then the 'dot5StatsFrameCopiedErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsTokenErrors, as defined in [RFC1748], then the 'dot5StatsTokenErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsSoftErrors, as defined in [RFC1748], then the 'dot5StatsSoftErrors' bit will be set. If the agent can perform sorting of interfaces according to the Romascanu Standards Track [Page 11] RFC 3144 Remote Monitoring MIB Extensions August 2001 values of dot5StatsHardErrors, as defined in [RFC1748], then the 'dot5StatsHardErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsSignalLoss, as defined in [RFC1748], then the 'dot5StatsSignalLoss' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsTransmitBeacons, as defined in [RFC1748], then the 'dot5StatsTransmitBeacons' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsRecoverys, as defined in [RFC1748], then the 'dot5StatsRecoverys' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsLobeWires, as defined in [RFC1748], then the 'dot5StatsLobeWires' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsRemoves, as defined in [RFC1748], then the 'dot5StatsRemoves' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsSingles, as defined in [RFC1748], then the 'dot5StatsSingles' bit will be set. If the agent can perform sorting of interfaces according to the values of dot5StatsFreqErrors, as defined in [RFC1748], then the 'dot5StatsFreqErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsDropEvents, as defined in [RFC2819], then the 'etherStatsDropEvents' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsOctets, as defined in [RFC2819], then the 'etherStatsOctets' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsPkts, as defined in [RFC2819], then the 'etherStatsPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsBroadcastPkts, as defined in [RFC2819], then the 'etherStatsBroadcastPkts' bit will be set. If the agent can perform sorting of interfaces according to the Romascanu Standards Track [Page 12] RFC 3144 Remote Monitoring MIB Extensions August 2001 values of etherStatsMulticastPkts, as defined in [RFC2819], then the 'etherStatsMulticastPkts' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsCRCAlignErrors, as defined in [RFC2819], then the 'etherStatsCRCAlignErrors' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsUndersizePkts, as defined in [RFC2819], then the 'etherStatsUndersizePkts' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsOversizePkts, as defined in [RFC2819], then the 'etherStatsOversizePkts' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsFragments, as defined in [RFC2819], then the 'etherStatsFragments' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsJabbers, as defined in [RFC2819], then the 'etherStatsJabbers' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsCollisions, as defined in [RFC2819], then the 'etherStatsCollisions' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsPkts64Octets, as defined in [RFC2819], then the 'etherStatsPkts64Octets' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsPkts65to127Octets, as defined in [RFC2819], then the 'etherStatsPkts65to127Octets' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsPkts128to255Octets, as defined in [RFC2819], then the 'etherStatsPkts128to255Octets' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsPkts256to511Octets, as defined in [RFC2819], then the 'etherStatsPkts256to511Octets' bit will be set. If the agent can perform sorting of interfaces according to the values of etherStatsPkts512to1023Octets, as defined in [RFC2819], then the 'etherStatsPkts512to1023Octets' bit will be set. If the agent can perform sorting of interfaces according to the Romascanu Standards Track [Page 13] RFC 3144 Remote Monitoring MIB Extensions August 2001 values of etherStatsPkts1024to1518Octets, as defined in [RFC2819], then the 'etherStatsPkts1024to1518Octets' bit will be set. If the agent can perform sorting of interfaces according to the values of dot1dTpPortInFrames, as defined in [RFC1493], then the 'dot1dTpPortInFrames' bit will be set. If the agent can perform sorting of interfaces according to the values of dot1dTpPortOutFrames, as defined in [RFC1493], then the 'dot1dTpPortOutFrames' bit will be set. If the agent can perform sorting of interfaces according to the values of dot1dTpPortInDiscards, as defined in [RFC1493], then the 'dot1dTpPortInDiscards' bit will be set." ::= { interfaceTopNObjects 1 } interfaceTopNControlTable OBJECT-TYPE SYNTAX SEQUENCE OF InterfaceTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control records for reports on the top `N' interfaces for the value or rate of a selected object. The number of entries depends on the configuration of the agent. The maximum number of entries is implementation dependent." ::= { interfaceTopNObjects 2 } interfaceTopNControlEntry OBJECT-TYPE SYNTAX InterfaceTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N ports according to several metrics." INDEX { interfaceTopNControlIndex } ::= { interfaceTopNControlTable 1 } InterfaceTopNControlEntry ::= SEQUENCE { interfaceTopNControlIndex Integer32, interfaceTopNObjectVariable INTEGER, Romascanu Standards Track [Page 14] RFC 3144 Remote Monitoring MIB Extensions August 2001 interfaceTopNObjectSampleType INTEGER, interfaceTopNNormalizationReq TruthValue, interfaceTopNNormalizationFactor Integer32, interfaceTopNTimeRemaining Integer32, interfaceTopNDuration Integer32, interfaceTopNRequestedSize Integer32, interfaceTopNGrantedSize Integer32, interfaceTopNStartTime TimeStamp, interfaceTopNOwner OwnerString, interfaceTopNLastCompletionTime TimeStamp, interfaceTopNRowStatus RowStatus } interfaceTopNControlIndex OBJECT-TYPE SYNTAX Integer32 (1 .. 65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the interfaceTopNControl table. Each such entry defines one top N report prepared for a probe." ::= { interfaceTopNControlEntry 1 } interfaceTopNObjectVariable OBJECT-TYPE SYNTAX INTEGER { ifInOctets(0), ifInUcastPkts(1), ifInNUcastPkts(2), ifInDiscards(3), ifInErrors(4), ifInUnknownProtos(5), ifOutOctets(6), ifOutUcastPkts(7), ifOutNUcastPkts(8), ifOutDiscards(9), ifOutErrors(10), Romascanu Standards Track [Page 15] RFC 3144 Remote Monitoring MIB Extensions August 2001 ifInMulticastPkts(11), ifInBroadcastPkts(12), ifOutMulticastPkts(13), ifOutBroadcastPkts(14), ifHCInOctets(15), ifHCInUcastPkts(16), ifHCInMulticastPkts(17), ifHCInBroadcastPkts(18), ifHCOutOctets(19), ifHCOutUcastPkts(20), ifHCOutMulticastPkts(21), ifHCOutBroadcastPkts(22), dot3StatsAlignmentErrors(23), dot3StatsFCSErrors(24), dot3StatsSingleCollisionFrames(25), dot3StatsMultipleCollisionFrames(26), dot3StatsSQETestErrors(27), dot3StatsDeferredTransmissions(28), dot3StatsLateCollisions(29), dot3StatsExcessiveCollisions(30), dot3StatsInternalMacTxErrors(31), dot3StatsCarrierSenseErrors(32), dot3StatsFrameTooLongs(33), dot3StatsInternalMacRxErrors(34), dot3StatsSymbolErrors(35), dot3InPauseFrames(36), dot3OutPauseFrames(37), dot5StatsLineErrors(38), dot5StatsBurstErrors(39), dot5StatsACErrors(40), dot5StatsAbortTransErrors(41), dot5StatsInternalErrors(42), dot5StatsLostFrameErrors(43), dot5StatsReceiveCongestions(44), dot5StatsFrameCopiedErrors(45), dot5StatsTokenErrors(46), dot5StatsSoftErrors(47), dot5StatsHardErrors(48), dot5StatsSignalLoss(49), dot5StatsTransmitBeacons(50), dot5StatsRecoverys(51), dot5StatsLobeWires(52), dot5StatsRemoves(53), dot5StatsSingles(54), dot5StatsFreqErrors(55), etherStatsDropEvents(56), etherStatsOctets(57), etherStatsPkts(58), Romascanu Standards Track [Page 16] RFC 3144 Remote Monitoring MIB Extensions August 2001 etherStatsBroadcastPkts(59), etherStatsMulticastPkts(60), etherStatsCRCAlignErrors(61), etherStatsUndersizePkts(62), etherStatsOversizePkts(63), etherStatsFragments(64), etherStatsJabbers(65), etherStatsCollisions(66), etherStatsPkts64Octets(67), etherStatsPkts65to127Octets(68), etherStatsPkts128to255Octets(69), etherStatsPkts256to511Octets(70), etherStatsPkts512to1023Octets(71), etherStatsPkts1024to1518Octets(72), dot1dTpPortInFrames(73), dot1dTpPortOutFrames(74), dot1dTpPortInDiscards(75) } MAX-ACCESS read-create STATUS current DESCRIPTION "The particular variable to be sampled. Values between 0 and 22, point to MIB objects defined in IF-MIB [RFC2863]. Values between 23 and 37, point to MIB objects defined in EtherLike-MIB [RFC2665]. Values between 38 and 55, point to MIB objects defined in TOKENRING-MIB [RFC1748]. Values between 56 and 72, point to MIB objects defined in RMON-MIB [RFC2819]. Values between 73 and 75, point to MIB objects defined in BRIDGE-MIB [RFC1493]. Because SNMP access control is articulated entirely in terms of the contents of MIB views, no access control mechanism exists that can restrict the value of this object to identify only those objects that exist in a particular MIB view. Because there is thus no acceptable means of restricting the read access that could be obtained through the TopN mechanism, the probe must only grant write access to this object in those views that have read access to all objects on the probe. Romascanu Standards Track [Page 17] RFC 3144 Remote Monitoring MIB Extensions August 2001 During a set operation, if the supplied variable name is not available in the selected MIB view, or does not conform the other conditions mentioned above, a badValue error must be returned. This object may not be modified if the associated interfaceTopNControlStatus object is equal to active(1)." ::= { interfaceTopNControlEntry 2 } interfaceTopNObjectSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2), bandwidthPercentage(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable for storage in the interfaceTopNTable. If the value of this object is absoluteValue(1), the value of the selected variable will be copied directly into the topNValue. If the value of this object is deltaValue(2), the value of the selected variable at the last sample will be subtracted from the current value, and the difference will be stored in topNValue. If the value of this object is bandwidthPercentage(3), the agent records the total number of octets sent over an interval divided by the total number of octets that represent '100% bandwidth' for that interface. This ratio is multiplied by 1000 to retain a 3 digit integer (0..1000) in units of 'tenth of one percent'. This type of computation is accurate for the octet counters. The usage of this option with respect to packets or error counters is not recommended. This object may not be modified if the associated interfaceTopNControlStatus object is equal to active(1)." ::= { interfaceTopNControlEntry 3 } interfaceTopNNormalizationReq OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether normalization is required in the Romascanu Standards Track [Page 18] RFC 3144 Remote Monitoring MIB Extensions August 2001 computation of the selected value. If the value of this object is 'true', the value of the selected variable will be multiplied by a factor equal to the interfaceTopNNormalizationFactor divided by the value of effective speed of the interface If the value of this object is 'false', the value of the selected variable will be taken 'as is' in the TopN computation. If the value of the object interfaceTopNSampleType is bandwidthPercentage(3), the object interfaceTopNNormalizationReq cannot take the value 'true'. The value of this object MUST be false if the effective speed of the interface sub-layer as determined from ifSpeed is zero. This conforms to the ifSpeed definition in [RFC2863]for a sub-layer that has no concept of bandwidth. This object may not be modified if the associated interfaceTopNControlStatus object is equal to active(1)." ::= { interfaceTopNControlEntry 4 } interfaceTopNNormalizationFactor OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The value used for normalization if interfaceTopNNormalizationReq has the value 'true'. Example: The following set of values is applied to a device with multiple Ethernet interfaces running at 10 Mbps, 100 Mbps, and 1 Gbps. interfaceTopNObjectVariable = 'ifInOctets' interfaceTopNObjectSampleType = 'deltaValue' interfaceTopNNormalizationReq = 'true' interfaceTopNNormalizationFactor = 1000000000 Applying this set of values will result in the sampled delta values to be multiplied by 100 for the 10 Mbps interfaces, and by 10 for the 100 Mbps interfaces, while the sample values for the 1 Gbps interface are left unchanged. The effective speed of the interface is taken from the value of ifSpeed for each interface, if ifSpeed is less than 4,294,967,295, or from ifHighSpeed multiplied by 1,000,000 otherwise. At row creation the agent SHOULD set the value of this object to Romascanu Standards Track [Page 19] RFC 3144 Remote Monitoring MIB Extensions August 2001 the effective speed of the interface." ::= { interfaceTopNControlEntry 5 } interfaceTopNTimeRemaining OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report, which is loaded into the associated interfaceTopNDuration object. When this object is set to a non-zero value, any associated interfaceTopNEntries shall be made inaccessible by the agent. While the value of this object is non-zero, it decrements by one per second until it reaches zero. During this time, all associated interfaceTopNEntries shall remain inaccessible. At the time that this object decrements to zero, the report is made accessible in the interfaceTopNTable. Thus, the interfaceTopN table needs to be created only at the end of the collection interval. If the value of this object is set to zero while the associated report is running, the running report is aborted and no associated interfaceTopNEntries are created." DEFVAL { 0 } ::= { interfaceTopNControlEntry 6 } interfaceTopNDuration OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval, or if this report is currently being collected, the number of seconds that this report is being collected during this sampling interval. When the associated interfaceTopNTimeRemaining Romascanu Standards Track [Page 20] RFC 3144 Remote Monitoring MIB Extensions August 2001 object is set, this object shall be set by the agent to the same value and shall not be modified until the next time the interfaceTopNTimeRemaining is set. This value shall be zero if no reports have been requested for this interfaceTopNControlEntry." ::= { interfaceTopNControlEntry 7 } interfaceTopNRequestedSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of interfaces requested for the Top N Table. When this object is created or modified, the agent should set interfaceTopNGrantedSize as close to this object as is possible for the particular implementation and available resources." DEFVAL { 10 } ::= { interfaceTopNControlEntry 8 } interfaceTopNGrantedSize OBJECT-TYPE SYNTAX Integer32 (0.. 2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of interfaces in the top N table. When the associated interfaceTopNRequestedSize object is created or modified, the agent should set this object as closely to the requested value as is possible for the particular implementation and available resources. The agent must not lower this value except as a result of a set to the associated interfaceTopNRequestedSize object." ::= { interfaceTopNControlEntry 9 } interfaceTopNStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this top N report was last started. In other words, this is the time that the associated interfaceTopNTimeRemaining object was Romascanu Standards Track [Page 21] RFC 3144 Remote Monitoring MIB Extensions August 2001 modified to start the requested report. If the report has not yet been started, the value of this object is zero." ::= { interfaceTopNControlEntry 10 } interfaceTopNOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is using the resources assigned to it." ::= { interfaceTopNControlEntry 11 } interfaceTopNLastCompletionTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this top N report was last completed. If no report was yet completed, the value of this object is zero." ::= { interfaceTopNControlEntry 12 } interfaceTopNRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. If the value of this object is not equal to active(1), all associated entries in the interfaceTopNTable shall be deleted by the agent." ::= { interfaceTopNControlEntry 13 } -- Interface Top "N" reports interfaceTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF InterfaceTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of reports for the top `N' ports based on Romascanu Standards Track [Page 22] RFC 3144 Remote Monitoring MIB Extensions August 2001 setting of associated control table entries. The maximum number of entries depends on the number of entries in table interfaceTopNControlTable and the value of object interfaceTopNGrantedSize for each entry. For each entry in the interfaceTopNControlTable, interfaces with the highest value of interfaceTopNValue shall be placed in this table in decreasing order of that rate until there is no more room or until there are no more ports." ::= { interfaceTopNObjects 3 } interfaceTopNEntry OBJECT-TYPE SYNTAX InterfaceTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for an interface that is part of a top N report." INDEX { interfaceTopNControlIndex, interfaceTopNIndex } ::= { interfaceTopNTable 1 } InterfaceTopNEntry ::= SEQUENCE { interfaceTopNIndex Integer32, interfaceTopNDataSourceIndex Integer32, interfaceTopNValue Gauge32, interfaceTopNValue64 CounterBasedGauge64 } interfaceTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the interfaceTopN table among those in the same report. This index is between 1 and N, where N is the number of entries in this report. Increasing values of interfaceTopNIndex shall be assigned to entries with decreasing values of interfaceTopNValue or interfaceTopNValue64, whichever applies, until index N is assigned to the entry with the Romascanu Standards Track [Page 23] RFC 3144 Remote Monitoring MIB Extensions August 2001 lowest value of interfaceTopNValue / interfaceTopNValue64 or there are no more interfaceTopNEntries. No ports are included in a report where their value of interfaceTopNValue would be zero." ::= { interfaceTopNEntry 1 } interfaceTopNDataSourceIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the index corresponding to the dataSource for this entry. For sorted values of variables belonging to the IF-MIB, EtherLike-MIB or TOKENRING-MIB, this value equals the ifIndex of the interface. For sorted values of variables belonging to the RMON-MIB, this value equals the interface corresponding to the data source, pointed to by the value of etherStatsDataSource. For sorted values of variables belonging to the BRIDGE-MIB, this value equals the interface corresponding to the bridge port, pointed to by the value of dot1dBasePortIfIndex." ::= { interfaceTopNEntry 2 } interfaceTopNValue OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value at the end of the sampling interval, or the amount of change in the selected variable during this sampling interval for the identified interface. The selected variable is that interfaces's instance of the object selected by interfaceTopNObjectVariable. This value may be normalized if interfaceTopNNormalization required equals 'true'. This value of this object will be computed for all cases when interfaceTopNObjectVariable points to a 32-bit counter or Gauge or when interfaceTopNObjectSampleType equals bandwidthPercentage(3), and will be zero for all other cases." Romascanu Standards Track [Page 24] RFC 3144 Remote Monitoring MIB Extensions August 2001 ::= { interfaceTopNEntry 3 } interfaceTopNValue64 OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value at the end of the sampling interval, or the amount of change in the selected variable during this sampling interval for the identified interface. The selected variable is that interfaces's instance of the object selected by interfaceTopNObjectVariable. This value may be normalized if interfaceTopNNormalization required equals 'true'. This value of this object will be computed for all cases when interfaceTopNObjectVariable points to a 64-bit counter, and will be zero for all other cases." ::= { interfaceTopNEntry 4 } -- -- Notifications Section -- (none defined) -- -- -- Conformance Section -- interfaceTopNCompliances OBJECT IDENTIFIER ::= {interfaceTopNConformance 1 } interfaceTopNGroups OBJECT IDENTIFIER ::= {interfaceTopNConformance 2 } interfaceTopNCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the InterfaceTopN MIB." MODULE -- this module MANDATORY-GROUPS { interfaceTopNGroup } ::= { interfaceTopNCompliances 1 } interfaceTopNGroup OBJECT-GROUP OBJECTS { interfaceTopNCaps, interfaceTopNObjectVariable, interfaceTopNObjectSampleType, Romascanu Standards Track [Page 25] RFC 3144 Remote Monitoring MIB Extensions August 2001 interfaceTopNNormalizationReq, interfaceTopNNormalizationFactor, interfaceTopNTimeRemaining, interfaceTopNDuration, interfaceTopNRequestedSize, interfaceTopNGrantedSize, interfaceTopNStartTime, interfaceTopNOwner, interfaceTopNLastCompletionTime, interfaceTopNRowStatus, interfaceTopNDataSourceIndex, interfaceTopNValue, interfaceTopNValue64 } STATUS current DESCRIPTION "A collection of objects providing interfaceTopN data for a multiple interfaces device." ::= { interfaceTopNGroups 1 } END 7. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Romascanu Standards Track [Page 26] RFC 3144 Remote Monitoring MIB Extensions August 2001 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks, Version 1.0", RFC 2613, June 1999. Romascanu Standards Track [Page 27] RFC 3144 Remote Monitoring MIB Extensions August 2001 [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [RFC2863] McCloghrie, K., and Kastenholtz, F., "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2982] Kavasseri, R., Stewart B., "Distributed Management Expression MIB", RFC 2982, October 2000 [RFC2856] Bierman, A., McCloghrie, K., and Presuhn R., "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC2665] Flick, J., and Johnson, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 2665, August 1999. [RFC1748] McCloghrie, K., and Decker E., "IEEE802.5 MIB Using SMIv2", RFC 1748, December 1994. [RFC1493] E. Decker, P. Langille, A. Rijsinghani, and McCloghrie, K., "Definition of Managed Objects for Bridges", RFC 1493, July 1993. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Romascanu Standards Track [Page 28] RFC 3144 Remote Monitoring MIB Extensions August 2001 9. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information. These are: interfaceTopNDataSourceIndex interfaceTopNValue It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is RECOMMENDED that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [RFC2274] and the View-based Access Control Model [RFC2275] is RECOMMENDED. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. Author's Address Dan Romascanu Avaya Inc. Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Phone: +972-3-645-8414 EMail: dromasca@avaya.com Romascanu Standards Track [Page 29] RFC 3144 Remote Monitoring MIB Extensions August 2001 11. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Romascanu Standards Track [Page 30] snmp-mibs-downloader-1.1/mibrfcs/rfc3165.txt0000644000000000000000000040651711402176071015575 0ustar Network Working Group D. Levi Request for Comments: 3165 Nortel Networks Obsoletes: 2592 J. Schoenwaelder Category: Standards Track TU Braunschweig August 2001 Definitions of Managed Objects for the Delegation of Management Scripts 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. Levi & Schoenwaelder Standards Track [Page 1] RFC 3165 Script MIB August 2001 Table of Contents 1 Introduction ................................................. 3 2 The SNMP Management Framework ................................ 3 3 Overview ..................................................... 4 3.1 Terms ...................................................... 5 4 Requirements and Design Issues ............................... 6 4.1 Script Languages ........................................... 6 4.2 Script Transfer ............................................ 7 4.3 Script Execution ........................................... 8 5 Structure of the MIB ......................................... 9 5.1 Language Group ............................................. 9 5.2 Script Group ............................................... 10 5.3 Code Group ................................................. 11 5.4 Launch Group ............................................... 11 5.5 Run Group .................................................. 11 6 Definitions .................................................. 12 7 Usage Examples ............................................... 49 7.1 Pushing a Script via SNMP .................................. 49 7.2 Pulling a Script from a URL ................................ 50 7.3 Modifying an Existing Script ............................... 50 7.4 Removing an Existing Script ................................ 51 7.5 Creating a Launch Button ................................... 51 7.6 Launching a Script ......................................... 52 7.7 Suspending a Running Script ................................ 52 7.8 Resuming a Suspended Script ................................ 53 7.9 Terminating a Running Script ............................... 53 7.10 Removing a Terminated Script .............................. 54 7.11 Removing a Launch Button .................................. 54 8 VACM Configuration Examples .................................. 54 8.1 Sandbox for Guests ......................................... 55 8.2 Sharing Scripts ............................................ 55 8.3 Emergency Scripts .......................................... 56 9 IANA Considerations .......................................... 57 10 Security Considerations ..................................... 57 11 Intellectual Property ....................................... 59 12 Changes from RFC 2592 ....................................... 59 13 Acknowledgments ............................................. 61 14 References .................................................. 61 15 Editors' Addresses .......................................... 63 16 Full Copyright Statement .................................... 64 Levi & Schoenwaelder Standards Track [Page 2] RFC 3165 Script MIB August 2001 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Levi & Schoenwaelder Standards Track [Page 3] RFC 3165 Script MIB August 2001 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview The Script MIB module defined in this memo can be used to delegate management functions to distributed managers. Management functions are defined as management scripts written in a management scripting language. This MIB makes no assumptions about the language itself and even allows distribution of compiled native code, if an implementation is able to execute native code under the control of this MIB. The Script MIB defines a standard interface for the delegation of management functions based on the Internet management framework. In particular, it provides the following capabilities: 1. Capabilities to transfer management scripts to a distributed manager. 2. Capabilities for initiating, suspending, resuming and terminating management scripts. 3. Capabilities to transfer arguments for management scripts. 4. Capabilities to monitor and control running management scripts. 5. Capabilities to transfer the results produced by running management scripts. This memo does not address any additional topics like the generation of notifications or how to address remote agents from a Script MIB implementation. Levi & Schoenwaelder Standards Track [Page 4] RFC 3165 Script MIB August 2001 3.1. Terms This section defines the terms used throughout this memo. o A `distributed manager' is a processing entity which is capable of performing network management functions. For the scope of this memo, a distributed manager is assumed to implement the Script MIB. o A `higher-level manager', or just `manager', is a processing entity or human who initiates and controls the operations performed by one or more distributed managers. o A `management script' is a set of instructions written in an executable language which implements a management function. o A `management scripting language' is a language used to write management scripts. The term scripting language does not imply that the language must have the characteristics of scripting languages (e.g., string orientation, interpretation, weak typing). The MIB defined in this memo also allows to control management scripts written in arbitrary compiled system programming languages. o A `distributed manager' can be decomposed into an `SNMP entity' which implements the Script MIB defined in this memo and the ` runtime system' that executes scripts. The Script MIB sees the runtime system as the managed resource which is controlled by the MIB. The runtime system can act as an SNMP application, according to the SNMP architecture defined in RFC 2571 [RFC2571]. For example, a runtime system which sends SNMP requests to other SNMP entities will act as a command generator application. The SNMP applications in the runtime system may use the same SNMP engine which also serves the command responder application used to implement the Script MIB, but they are not required to do so. o A `launch button' is the conceptual button used to start the execution of a management script. It assigns control parameters to a management script. In particular, it defines the ownership of the scripts started from a launch button. The ownership can be used by the language runtime system to enforce security profiles on a running management script. Levi & Schoenwaelder Standards Track [Page 5] RFC 3165 Script MIB August 2001 4. Requirements and Design Issues This section discusses some general requirements that have influenced the design of the Script MIB. o The Script MIB must not make any assumptions about specific languages or runtime systems. o The Script MIB must provide mechanisms that help to avoid new management problems (e.g., script version problems). o The Script MIB must provide SNMP interfaces to all functions required to delegate management scripts. However, other protocols might be used in addition if they provide a significant improvement in terms of convenience for implementation or performance. o The Script MIB must be organized so that access can be controlled effectively by using view-based access control [RFC2575]. The following sections discuss some design issues in more detail. 4.1. Script Languages The Script MIB defined in this memo makes no assumption about the script language. This MIB can therefore be used in combination with different languages (such as Tcl or Java) and/or different versions of the same language. No assumptions are made about the format in which management scripts are transferred. The Script MIB provides access to information about the language versions supported by a Script MIB implementation so that a manager can learn about the capabilities provided by an implementation. Languages and language versions are identified as follows: 1. The language is identified by an object identifier. Object identifier for well-known languages will be registered by the Internet Assigned Numbers Authority (IANA). Enterprise specific languages can also be registered in the enterprise specific OID subtree. 2. A particular version of a language is identified by a language version number. The combination of a language object identifier and a language version is in most cases sufficient to decide whether a script can be executed or not. Levi & Schoenwaelder Standards Track [Page 6] RFC 3165 Script MIB August 2001 3. Different implementations of the same language version might have differences due to ambiguities in the language definition or additional language features provided by an implementor. An additional object identifier value is provided which identifies the organization which provides the implementation of a language. This might be used by scripts that require a particular implementation of a language. 4. Finally, there might be different versions of a language implementation. A version number for the language implementation is provided so that the manager can also distinguish between different implementations from the same organization of a particular language version. The version numbers can either be used by a manager to select the language version required to execute a particular script or to select a script that fits the language versions supported by a particular Script MIB implementation. An additional table lists language extensions that provide features not provided by the core language. Language extensions are usually required to turn a general purpose language into a management language. In many cases, language extensions will come in the form of libraries that provide capabilities like sending SNMP requests to remote SNMP agents or accessing the local MIB instrumentation. Every extension is associated with a language and carries its own version numbers. 4.2. Script Transfer There are two different ways to transfer management scripts to a distributed manager. The first approach requires that the manager pushes the script to the distributed manager. This is therefore called the `push model'. The second approach is the `pull model' where the manager tells the distributed manager the location of the script and the distributed manager retrieves the script itself. The MIB defined in this memo supports both models. The `push model' is realized by a table which allows a manager to write scripts by sending a sequence of SNMP set requests. The script can be split into several fragments in order to deal with SNMP message size limitations. The `pull model' is realized by the use of Uniform Resource Locators (URLs) [RFC2396] that point to the script source. The manager writes the URL which points to the script source to the distributed manager Levi & Schoenwaelder Standards Track [Page 7] RFC 3165 Script MIB August 2001 by sending an SNMP set request. The distributed manager is then responsible for retrieving the document using the protocol specified in the URL. This allows the use of protocols like FTP [RFC959] or HTTP [RFC2616] to transfer large management scripts efficiently. The Script MIB also allows management scripts that are hard-wired into the Script MIB implementation. Built-in scripts can either be implemented in a language runtime system, or they can be built natively into the Script MIB implementation. The implementation of the `push model' or the `pull model' is not required. Scripts can be stored in non-volatile storage. This allows a distributed manager to restart scripts if it is restarted (off-line restart). A manager is not required to push scripts back into the distributed manager after a restart if the script is backed up in non-volatile storage. Every script is identified by an administratively assigned name. This name may be used to derive the name which is used to access the script in non-volatile storage. This mapping is implementation specific. However, the mapping must ensure that the Script MIB implementation can handle scripts with the same administrative name owned by different managers. One way to achieve this is to use the script owner in addition to the script name in order to derive the internal name used to refer to a particular script in non-volatile storage. 4.3. Script Execution The Script MIB permits execution of several instances of the same or different management scripts. Script arguments are passed as OCTET STRING values. Scripts return a single result value which is also an OCTET STRING value. The semantic interpretation of result values is left to the invoking manager or other management scripts. A script invoker must understand the format and semantics of both the arguments and the results of the scripts that it invokes. Scripts can also export complex results through a MIB interface. This allows a management application to access and use script results in the same manner as it processes any other MIB data. However, the Script MIB does not provide any special support for the implementation of MIBs through scripts. Runtime errors terminate active scripts. An exit code and a human readable error message is left in the MIB. A notification containing the exit code, the error message and a timestamp is generated when a script terminates with an error exit code. Levi & Schoenwaelder Standards Track [Page 8] RFC 3165 Script MIB August 2001 Script arguments and results do not have any size limitations other than the limits imposed by the SMI and the SNMP protocol. However, implementations of this MIB might have further restrictions. A script designer might therefore choose to return the results via other mechanisms if the script results can be very large. One possibility is to return a URL as a script result which points to the file containing the script output. Executing scripts have a status object attached which allows script execution to be suspended, resumed, or aborted. The precise semantics of the suspend and resume operations are language and runtime system dependent. Some runtime systems may choose to not implement the suspend/resume operations. A history of finished scripts is kept in the MIB. A script invoker can collect results at a later point in time (offline operation). Control objects can be used to control how entries in the history are aged out if the table fills up. 5. Structure of the MIB This section presents the structure of the MIB. The objects are arranged into the following groups: o language group (smLangTable, smExtsnTable) o script group (smScriptTable) o script code group (smCodeTable) o script launch group (smLaunchTable) o running script group (smRunTable) 5.1. Language Group The smLanguageGroup is used to provide information about the languages and the language extensions supported by a Script MIB implementation. This group includes two tables. The smLangTable lists all languages supported by a Script MIB implementation and the smExtsnTable lists the extensions that are available for a given language. Levi & Schoenwaelder Standards Track [Page 9] RFC 3165 Script MIB August 2001 5.2. Script Group The smScriptGroup consists of a single table, called the smScriptTable. The smScriptTable lists all scripts known to a Script MIB implementation. The smScriptTable contains objects that allow the following operations: o download scripts from a URL (pull model) o read scripts from local non-volatile storage o store scripts in local non-volatile storage o delete scripts from local non-volatile storage o list permanent scripts (that can not be changed or removed) o read and modify the script status (enabled, disabled, editing) A status object called smScriptOperStatus allows a manager to obtain the current status of a script. It is also used to provide an error indication if an attempt to invoke one of the operations listed above fails. The status change of a script can be requested by modifying the associated smScriptAdminStatus object. The source of a script is defined by the smScriptSource object. This object may contain a URL pointing to a remote location which provides access to the management script. The script source is read from the smCodeTable (described below) or from non-volatile storage if the smScriptSource object contains an empty URL. The smScriptStorageType object is used to distinguish between scripts read from non-volatile storage and scripts read from the smCodeTable. Scripts are automatically loaded once the smScriptAdminStatus object is set to `enabled'. Loading a script includes retrieving the script (probably from a remote location), compiling the script for languages that require a compilation step, and making the code available to the runtime system. The smScriptOperStatus object is used to indicate the status of the loading process. This object will start in the state `retrieving', switch to the state `compiling' and finally reach the state `enabled'. Errors during the retrieval or compilation phase will result in an error state such as `compilationFailed'. Levi & Schoenwaelder Standards Track [Page 10] RFC 3165 Script MIB August 2001 5.3. Code Group The smCodeGroup consists of a single table, called the smCodeTable, which provides the ability to transfer and modify scripts via SNMP set requests. In particular, the smCodeTable allows the following operations: o download scripts via SNMP (push model) o modify scripts via SNMP (editing) The smCodeTable lists the code of a script. A script can be fragmented over multiple rows of the smCodeTable in order to handle SNMP message size limitations. Modifications of the smCodeTable are only possible if the associated smScriptOperStatus object has the value `editing'. The Script MIB implementation reloads the modified script code once the smScriptOperStatus changes to `enabled' again. The implementation of the smCodeGroup is optional. 5.4. Launch Group The smLaunchGroup contains a single table, the smLaunchTable. An entry in the smLaunchTable represents a launch button which can be used to start a script. The smLaunchTable allows the following operations: o associate a script with an owner used during script execution o provide arguments and parameters for script invocation o invoke scripts with a single set operation The smLaunchTable describes scripts and their parameters that are ready to be launched. An entry in the smLaunchTable attaches an argument to a script and control values which, for example, define the maximum number of times that a script invoked from a particular row in the smLaunchTable may be running concurrently. An entry in the smLaunchTable also defines the owner which will be used to associate permissions with the script execution. 5.5. Run Group The smRunGroup contains a single table, called the smRunTable, which lists all scripts that are currently running or have terminated recently. The smRunTable contains objects that allow the following operations: Levi & Schoenwaelder Standards Track [Page 11] RFC 3165 Script MIB August 2001 o retrieve status information from running scripts o control running scripts (suspend, resume, abort) o retrieve results from recently terminated scripts o control the remaining maximum lifetime of a running script o control how long script results are accessible Every row in the smRunTable contains the argument passed during script invocation, the result produced by the script and the script exit code. The smRunTable also provides information about the current run state as well as start and end time-stamps. There are three writable objects in the smRunTable. The smRunLifeTime object defines the maximum time a running script may run before it is terminated by the Script MIB implementation. The smRunExpireTime object defines the time that a completed script can stay in the smRunTable before it is aged out. The smRunControl object allows running scripts to be suspended, resumed, or aborted. 6. Definitions DISMAN-SCRIPT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI RowStatus, TimeInterval, DateAndTime, StorageType, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; scriptMIB MODULE-IDENTITY LAST-UPDATED "200108210000Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "WG EMail: disman@dorothy.bmc.com Subscribe: disman-request@dorothy.bmc.com Chair: Randy Presuhn BMC Software, Inc. Levi & Schoenwaelder Standards Track [Page 12] RFC 3165 Script MIB August 2001 Postal: Office 1-3141 2141 North First Street San Jose, California 95131 USA EMail: rpresuhn@bmc.com Phone: +1 408 546-1006 Editor: David B. Levi Nortel Networks Postal: 4401 Great America Parkway Santa Clara, CA 95052-8185 USA EMail: dlevi@nortelnetworks.com Phone: +1 423 686 0432 Editor: Juergen Schoenwaelder TU Braunschweig Postal: Bueltenweg 74/75 38106 Braunschweig Germany EMail: schoenw@ibr.cs.tu-bs.de Phone: +49 531 391-3283" DESCRIPTION "This MIB module defines a set of objects that allow to delegate management scripts to distributed managers." REVISION "200108210000Z" DESCRIPTION "Revised version, published as RFC 3165. This revision introduces several new objects: smScriptError, smScriptLastChange, smLaunchError, smLaunchLastChange, smLaunchRowExpireTime, smRunResultTime, and smRunErrorTime. The following existing objects were updated: the maximum value of smRunLifeTime now disables the timer, an autostart value was added to the smLaunchAdminStatus object, and a new expired state was added to the smLaunchOperStatus object. A new smScriptException notification has been added to support runtime error notifications. Created new conformance and compliance statements that take care of the new objects and notifications. Clarifications have been added in several places to remove ambiguities or contradictions that were discovered and reported by implementors." Levi & Schoenwaelder Standards Track [Page 13] RFC 3165 Script MIB August 2001 REVISION "199902221800Z" DESCRIPTION "Initial version, published as RFC 2592." ::= { mib-2 64 } -- -- The groups defined within this MIB module: -- smObjects OBJECT IDENTIFIER ::= { scriptMIB 1 } smNotifications OBJECT IDENTIFIER ::= { scriptMIB 2 } smConformance OBJECT IDENTIFIER ::= { scriptMIB 3 } -- -- Script language and language extensions. -- -- This group defines tables which list the languages and the -- language extensions supported by a Script MIB implementation. -- Languages are uniquely identified by object identifier values. -- smLangTable OBJECT-TYPE SYNTAX SEQUENCE OF SmLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists supported script languages." ::= { smObjects 1 } smLangEntry OBJECT-TYPE SYNTAX SmLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular language." INDEX { smLangIndex } ::= { smLangTable 1 } SmLangEntry ::= SEQUENCE { smLangIndex Integer32, smLangLanguage OBJECT IDENTIFIER, smLangVersion SnmpAdminString, smLangVendor OBJECT IDENTIFIER, smLangRevision SnmpAdminString, smLangDescr SnmpAdminString } smLangIndex OBJECT-TYPE Levi & Schoenwaelder Standards Track [Page 14] RFC 3165 Script MIB August 2001 SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this language entry. The value is expected to remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. Note that the data type and the range of this object must be consistent with the definition of smScriptLanguage." ::= { smLangEntry 1 } smLangLanguage OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The globally unique identification of the language." ::= { smLangEntry 2 } smLangVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language. The zero-length string shall be used if the language does not have a version number. It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smLangEntry 3 } smLangVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object identifier which identifies the vendor who provides the implementation of the language. This object identifier SHALL point to the object identifier directly below the enterprise object identifier {1 3 6 1 4 1} allocated for the vendor. The value must be the object identifier {0 0} if the vendor is not known." Levi & Schoenwaelder Standards Track [Page 15] RFC 3165 Script MIB August 2001 ::= { smLangEntry 4 } smLangRevision OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language implementation. The value of this object must be an empty string if version number of the implementation is unknown. It is suggested that the value consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smLangEntry 5 } smLangDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the language." ::= { smLangEntry 6 } smExtsnTable OBJECT-TYPE SYNTAX SEQUENCE OF SmExtsnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists supported language extensions." ::= { smObjects 2 } smExtsnEntry OBJECT-TYPE SYNTAX SmExtsnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular language extension." INDEX { smLangIndex, smExtsnIndex } ::= { smExtsnTable 1 } SmExtsnEntry ::= SEQUENCE { smExtsnIndex Integer32, smExtsnExtension OBJECT IDENTIFIER, smExtsnVersion SnmpAdminString, smExtsnVendor OBJECT IDENTIFIER, smExtsnRevision SnmpAdminString, Levi & Schoenwaelder Standards Track [Page 16] RFC 3165 Script MIB August 2001 smExtsnDescr SnmpAdminString } smExtsnIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this language extension entry. The value is expected to remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { smExtsnEntry 1} smExtsnExtension OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The globally unique identification of the language extension." ::= { smExtsnEntry 2 } smExtsnVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the language extension. It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smExtsnEntry 3 } smExtsnVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object identifier which identifies the vendor who provides the implementation of the extension. The object identifier value should point to the OID node directly below the enterprise OID {1 3 6 1 4 1} allocated for the vendor. The value must by the object identifier {0 0} if the vendor is not known." ::= { smExtsnEntry 4 } Levi & Schoenwaelder Standards Track [Page 17] RFC 3165 Script MIB August 2001 smExtsnRevision OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the extension implementation. The value of this object must be an empty string if version number of the implementation is unknown. It is suggested that the value consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { smExtsnEntry 5 } smExtsnDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the language extension." ::= { smExtsnEntry 6 } -- -- Scripts known by the Script MIB implementation. -- -- This group defines a table which lists all known scripts. -- Scripts can be added and removed through manipulation of the -- smScriptTable. -- smScriptObjects OBJECT IDENTIFIER ::= { smObjects 3 } smScriptTable OBJECT-TYPE SYNTAX SEQUENCE OF SmScriptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes locally known scripts." ::= { smScriptObjects 1 } smScriptEntry OBJECT-TYPE SYNTAX SmScriptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular script. Every script that is stored in non-volatile memory is required to appear in this script table." Levi & Schoenwaelder Standards Track [Page 18] RFC 3165 Script MIB August 2001 INDEX { smScriptOwner, smScriptName } ::= { smScriptTable 1 } SmScriptEntry ::= SEQUENCE { smScriptOwner SnmpAdminString, smScriptName SnmpAdminString, smScriptDescr SnmpAdminString, smScriptLanguage Integer32, smScriptSource DisplayString, smScriptAdminStatus INTEGER, smScriptOperStatus INTEGER, smScriptStorageType StorageType, smScriptRowStatus RowStatus, smScriptError SnmpAdminString, smScriptLastChange DateAndTime } smScriptOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the smScriptTable." ::= { smScriptEntry 1 } smScriptName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this script. This object allows an smScriptOwner to have multiple entries in the smScriptTable. This value of this object may be used to derive the name (e.g. a file name) which is used by the Script MIB implementation to access the script in non-volatile storage. The details of this mapping are implementation specific. However, the mapping needs to ensure that scripts created by different owners with the same script name do not map to the same name in non-volatile storage." ::= { smScriptEntry 2 } smScriptDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION Levi & Schoenwaelder Standards Track [Page 19] RFC 3165 Script MIB August 2001 "A description of the purpose of the script." ::= { smScriptEntry 3 } smScriptLanguage OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object type identifies an entry in the smLangTable which is used to execute this script. The special value 0 may be used by hard-wired scripts that can not be modified and that are executed by internal functions. Set requests to change this object are invalid if the value of smScriptOperStatus is `enabled' or `compiling' and will result in an inconsistentValue error. Note that the data type and the range of this object must be consistent with the definition of smLangIndex." ::= { smScriptEntry 4 } smScriptSource OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "This object either contains a reference to the script source or an empty string. A reference must be given in the form of a Uniform Resource Locator (URL) as defined in RFC 2396. The allowed character sets and the encoding rules defined in RFC 2396 section 2 apply. When the smScriptAdminStatus object is set to `enabled', the Script MIB implementation will `pull' the script source from the URL contained in this object if the URL is not empty. An empty URL indicates that the script source is loaded from local storage. The script is read from the smCodeTable if the value of smScriptStorageType is volatile. Otherwise, the script is read from non-volatile storage. Note: This document does not mandate implementation of any specific URL scheme. An attempt to load a script from a nonsupported URL scheme will cause the smScriptOperStatus to report an `unknownProtocol' error. Levi & Schoenwaelder Standards Track [Page 20] RFC 3165 Script MIB August 2001 Set requests to change this object are invalid if the value of smScriptOperStatus is `enabled', `editing', `retrieving' or `compiling' and will result in an inconsistentValue error." DEFVAL { ''H } ::= { smScriptEntry 5 } smScriptAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), editing(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of the script. See the definition of smScriptOperStatus for a description of the values. When the smScriptAdminStatus object is set to `enabled' and the smScriptOperStatus is `disabled' or one of the error states, the Script MIB implementation will `pull' the script source from the URL contained in the smScriptSource object if the URL is not empty." DEFVAL { disabled } ::= { smScriptEntry 6 } smScriptOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), editing(3), retrieving(4), compiling(5), noSuchScript(6), accessDenied(7), wrongLanguage(8), wrongVersion(9), compilationFailed(10), noResourcesLeft(11), unknownProtocol(12), protocolFailure(13), genericError(14) } MAX-ACCESS read-only STATUS current DESCRIPTION Levi & Schoenwaelder Standards Track [Page 21] RFC 3165 Script MIB August 2001 "The actual status of the script in the runtime system. The value of this object is only meaningful when the value of the smScriptRowStatus object is `active'. The smScriptOperStatus object may have the following values: - `enabled' indicates that the script is available and can be started by a launch table entry. - `disabled' indicates that the script can not be used. - `editing' indicates that the script can be modified in the smCodeTable. - `retrieving' indicates that the script is currently being loaded from non-volatile storage or a remote system. - `compiling' indicates that the script is currently being compiled by the runtime system. - `noSuchScript' indicates that the script does not exist at the smScriptSource. - `accessDenied' indicates that the script can not be loaded from the smScriptSource due to a lack of permissions. - `wrongLanguage' indicates that the script can not be loaded from the smScriptSource because of a language mismatch. - `wrongVersion' indicates that the script can not be loaded from the smScriptSource because of a language version mismatch. - `compilationFailed' indicates that the compilation failed. - `noResourcesLeft' indicates that the runtime system does not have enough resources to load the script. - `unknownProtocol' indicates that the script could not be loaded from the smScriptSource because the requested protocol is not supported. - `protocolFailure' indicates that the script could not be loaded from the smScriptSource because of a protocol failure. - `genericError' indicates that the script could not be Levi & Schoenwaelder Standards Track [Page 22] RFC 3165 Script MIB August 2001 loaded due to an error condition not listed above. The `retrieving' and `compiling' states are transient states which will either lead to one of the error states or the `enabled' state. The `disabled' and `editing' states are administrative states which are only reached by explicit management operations. All launch table entries that refer to this script table entry shall have an smLaunchOperStatus value of `disabled' when the value of this object is not `enabled'." DEFVAL { disabled } ::= { smScriptEntry 7 } smScriptStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row and the script controlled by this row are kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. The storage type of this row always complies with the value of this entry if the value of the corresponding RowStatus object is `active'. However, the storage type of the script controlled by this row may be different, if the value of this entry is `non-volatile'. The script controlled by this row is written into local non-volatile storage if the following condition becomes true: (a) the URL contained in the smScriptSource object is empty and (b) the smScriptStorageType is `nonVolatile' and (c) the smScriptOperStatus is `enabled' Setting this object to `volatile' removes a script from non-volatile storage if the script controlled by this row has been in non-volatile storage before. Attempts to set this object to permanent will always fail with an inconsistentValue error. The value of smScriptStorageType is only meaningful if the value of the corresponding RowStatus object is `active'. Levi & Schoenwaelder Standards Track [Page 23] RFC 3165 Script MIB August 2001 If smScriptStorageType has the value permanent(4), then all objects whose MAX-ACCESS value is read-create must be writable, with the exception of the smScriptStorageType and smScriptRowStatus objects, which shall be read-only." DEFVAL { volatile } ::= { smScriptEntry 8 } smScriptRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. Changing the smScriptRowStatus from `active' to `notInService' will remove the associated script from the runtime system. Deleting conceptual rows from this table may affect the deletion of other resources associated with this row. For example, a script stored in non-volatile storage may be removed from non-volatile storage. An entry may not exist in the `active' state unless all required objects in the entry have appropriate values. Rows that are not complete or not in service are not known by the script runtime system. Attempts to `destroy' a row or to set a row `notInService' while the smScriptOperStatus is `enabled' will result in an inconsistentValue error. Attempts to `destroy' a row or to set a row `notInService' where the value of the smScriptStorageType object is `permanent' or `readOnly' will result in an inconsistentValue error. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { smScriptEntry 9 } smScriptError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if the Levi & Schoenwaelder Standards Track [Page 24] RFC 3165 Script MIB August 2001 transition into the operational status `enabled' failed. Implementations must reset the error message to a zero-length string when a new attempt to change the script status to `enabled' is started." DEFVAL { ''H } ::= { smScriptEntry 10 } smScriptLastChange OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when this script table entry was last modified. The value '0000000000000000'H is returned if the script table entry has not yet been modified. Note that the resetting of smScriptError is not considered a change of the script table entry." DEFVAL { '0000000000000000'H } ::= { smScriptEntry 11 } -- -- Access to script code via SNMP -- -- The smCodeTable allows script code to be read and modified -- via SNMP. -- smCodeTable OBJECT-TYPE SYNTAX SEQUENCE OF SmCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the script code for scripts that are written via SNMP write operations." ::= { smScriptObjects 2 } smCodeEntry OBJECT-TYPE SYNTAX SmCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular fragment of a script." INDEX { smScriptOwner, smScriptName, smCodeIndex } ::= { smCodeTable 1 } SmCodeEntry ::= SEQUENCE { smCodeIndex Unsigned32, Levi & Schoenwaelder Standards Track [Page 25] RFC 3165 Script MIB August 2001 smCodeText OCTET STRING, smCodeRowStatus RowStatus } smCodeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value identifying this code fragment." ::= { smCodeEntry 1 } smCodeText OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "The code that makes up a fragment of a script. The format of this code fragment depends on the script language which is identified by the associated smScriptLanguage object." ::= { smCodeEntry 2 } smCodeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { smCodeEntry 3 } -- -- Script execution. -- -- This group defines tables which allow script execution to be -- initiated, suspended, resumed, and terminated. It also provides -- a mechanism for keeping a history of recent script executions -- and their results. -- smRunObjects OBJECT IDENTIFIER ::= { smObjects 4 } smLaunchTable OBJECT-TYPE SYNTAX SEQUENCE OF SmLaunchEntry MAX-ACCESS not-accessible Levi & Schoenwaelder Standards Track [Page 26] RFC 3165 Script MIB August 2001 STATUS current DESCRIPTION "This table lists and describes scripts that are ready to be executed together with their parameters." ::= { smRunObjects 1 } smLaunchEntry OBJECT-TYPE SYNTAX SmLaunchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular executable script." INDEX { smLaunchOwner, smLaunchName } ::= { smLaunchTable 1 } SmLaunchEntry ::= SEQUENCE { smLaunchOwner SnmpAdminString, smLaunchName SnmpAdminString, smLaunchScriptOwner SnmpAdminString, smLaunchScriptName SnmpAdminString, smLaunchArgument OCTET STRING, smLaunchMaxRunning Unsigned32, smLaunchMaxCompleted Unsigned32, smLaunchLifeTime TimeInterval, smLaunchExpireTime TimeInterval, smLaunchStart Integer32, smLaunchControl INTEGER, smLaunchAdminStatus INTEGER, smLaunchOperStatus INTEGER, smLaunchRunIndexNext Integer32, smLaunchStorageType StorageType, smLaunchRowStatus RowStatus, smLaunchError SnmpAdminString, smLaunchLastChange DateAndTime, smLaunchRowExpireTime TimeInterval } smLaunchOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the smLaunchTable. Every instance of a running script started from a particular entry in the smLaunchTable (i.e. entries in the smRunTable) will be owned by the same smLaunchOwner used to index the entry in the smLaunchTable. This owner is not necessarily the same as the owner of the script itself (smLaunchScriptOwner)." Levi & Schoenwaelder Standards Track [Page 27] RFC 3165 Script MIB August 2001 ::= { smLaunchEntry 1 } smLaunchName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this launch table entry. This object allows an smLaunchOwner to have multiple entries in the smLaunchTable. The smLaunchName is an arbitrary name that must be different from any other smLaunchTable entries with the same smLaunchOwner but can be the same as other entries in the smLaunchTable with different smLaunchOwner values. Note that the value of smLaunchName is not related in any way to the name of the script being launched." ::= { smLaunchEntry 2 } smLaunchScriptOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object in combination with the value of smLaunchScriptName identifies the script that can be launched from this smLaunchTable entry. Attempts to write this object will fail with an inconsistentValue error if the value of smLaunchOperStatus is `enabled'." ::= { smLaunchEntry 3 } smLaunchScriptName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object in combination with the value of the smLaunchScriptOwner identifies the script that can be launched from this smLaunchTable entry. The zero-length string may be used to point to a non-existing script. Attempts to write this object will fail with an inconsistentValue error if the value of smLaunchOperStatus is `enabled'." DEFVAL { ''H } ::= { smLaunchEntry 4 } smLaunchArgument OBJECT-TYPE SYNTAX OCTET STRING Levi & Schoenwaelder Standards Track [Page 28] RFC 3165 Script MIB August 2001 MAX-ACCESS read-create STATUS current DESCRIPTION "The argument supplied to the script. When a script is invoked, the value of this object is used to initialize the smRunArgument object." DEFVAL { ''H } ::= { smLaunchEntry 5 } smLaunchMaxRunning OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of concurrently running scripts that may be invoked from this entry in the smLaunchTable. Lowering the current value of this object does not affect any scripts that are already executing." DEFVAL { 1 } ::= { smLaunchEntry 6 } smLaunchMaxCompleted OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of finished scripts invoked from this entry in the smLaunchTable allowed to be retained in the smRunTable. Whenever the value of this object is changed and whenever a script terminates, entries in the smRunTable are deleted if necessary until the number of completed scripts is smaller than the value of this object. Scripts whose smRunEndTime value indicates the oldest completion time are deleted first." DEFVAL { 1 } ::= { smLaunchEntry 7 } smLaunchLifeTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum amount of time a script launched from this entry may run. The value of this object is used to initialize the smRunLifeTime object when a script is launched. Changing the value of an smLaunchLifeTime instance does not affect scripts previously launched from Levi & Schoenwaelder Standards Track [Page 29] RFC 3165 Script MIB August 2001 this entry." DEFVAL { 360000 } ::= { smLaunchEntry 8 } smLaunchExpireTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The default maximum amount of time information about a script launched from this entry is kept in the smRunTable after the script has completed execution. The value of this object is used to initialize the smRunExpireTime object when a script is launched. Changing the value of an smLaunchExpireTime instance does not affect scripts previously launched from this entry." DEFVAL { 360000 } ::= { smLaunchEntry 9 } smLaunchStart OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to start the execution of scripts. When retrieved, the value will be the value of smRunIndex for the last script that started execution by manipulating this object. The value will be zero if no script started execution yet. A script is started by setting this object to an unused smRunIndex value. A new row in the smRunTable will be created which is indexed by the value supplied by the set-request in addition to the value of smLaunchOwner and smLaunchName. An unused value can be obtained by reading the smLaunchRunIndexNext object. Setting this object to the special value 0 will start the script with a self-generated smRunIndex value. The consequence is that the script invoker has no reliable way to determine the smRunIndex value for this script invocation and that the invoker has therefore no way to obtain the results from this script invocation. The special value 0 is however useful for scheduled script invocations. If this object is set, the following checks must be Levi & Schoenwaelder Standards Track [Page 30] RFC 3165 Script MIB August 2001 performed: 1) The value of the smLaunchOperStatus object in this entry of the smLaunchTable must be `enabled'. 2) The values of smLaunchScriptOwner and smLaunchScriptName of this row must identify an existing entry in the smScriptTable. 3) The value of smScriptOperStatus of this entry must be `enabled'. 4) The principal performing the set operation must have read access to the script. This must be checked by calling the isAccessAllowed abstract service interface defined in RFC 2271 on the row in the smScriptTable identified by smLaunchScriptOwner and smLaunchScriptName. The isAccessAllowed abstract service interface must be called on all columnar objects in the smScriptTable with a MAX-ACCESS value different than `not-accessible'. The test fails as soon as a call indicates that access is not allowed. 5) If the value provided by the set operation is not 0, a check must be made that the value is currently not in use. Otherwise, if the value provided by the set operation is 0, a suitable unused value must be generated. 6) The number of currently executing scripts invoked from this smLaunchTable entry must be less than smLaunchMaxRunning. Attempts to start a script will fail with an inconsistentValue error if one of the checks described above fails. Otherwise, if all checks have been passed, a new entry in the smRunTable will be created indexed by smLaunchOwner, smLaunchName and the new value for smRunIndex. The value of smLaunchArgument will be copied into smRunArgument, the value of smLaunchLifeTime will be copied to smRunLifeTime, and the value of smLaunchExpireTime will be copied to smRunExpireTime. The smRunStartTime will be set to the current time and the smRunState will be set to `initializing' before the script execution is initiated in the appropriate runtime system. Note that the data type and the range of this object must be consistent with the smRunIndex object. Since this object might be written from the scheduling MIB, the Levi & Schoenwaelder Standards Track [Page 31] RFC 3165 Script MIB August 2001 data type Integer32 rather than Unsigned32 is used." DEFVAL { 0 } ::= { smLaunchEntry 10 } smLaunchControl OBJECT-TYPE SYNTAX INTEGER { abort(1), suspend(2), resume(3), nop(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to request a state change for all running scripts in the smRunTable that were started from this row in the smLaunchTable. Setting this object to abort(1), suspend(2) or resume(3) will set the smRunControl object of all applicable rows in the smRunTable to abort(1), suspend(2) or resume(3) respectively. The phrase `applicable rows' means the set of rows which were created from this entry in the smLaunchTable and whose value of smRunState allows the corresponding state change as described in the definition of the smRunControl object. Setting this object to nop(4) has no effect. Attempts to set this object lead to an inconsistentValue error only if all implicated sets on all the applicable rows lead to inconsistentValue errors. It is not allowed to return an inconsistentValue error if at least one state change on one of the applicable rows was successful." DEFVAL { nop } ::= { smLaunchEntry 11 } smLaunchAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), autostart(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of this launch table entry. The values enabled(1) and autostart(3) both indicate that the launch table entry Levi & Schoenwaelder Standards Track [Page 32] RFC 3165 Script MIB August 2001 should transition into the operational enabled(1) state as soon as the associated script table entry is enabled(1). The value autostart(3) further indicates that the script is started automatically by conceptually writing the value 0 into the associated smLaunchStart object during the transition from the `disabled' into the `enabled' operational state. This is useful for scripts that are to be launched on system start-up." DEFVAL { disabled } ::= { smLaunchEntry 12 } smLaunchOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), expired(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the actual status of this launch table entry. The smLaunchOperStatus object may have the following values: - `enabled' indicates that the launch table entry is available and can be used to start scripts. - `disabled' indicates that the launch table entry can not be used to start scripts. - `expired' indicates that the launch table entry can not be used to start scripts and will disappear as soon as all smRunTable entries associated with this launch table entry have disappeared. The value `enabled' requires that the smLaunchRowStatus object is active. The value `disabled' requires that there are no entries in the smRunTable associated with this smLaunchTable entry." DEFVAL { disabled } ::= { smLaunchEntry 13 } smLaunchRunIndexNext OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION Levi & Schoenwaelder Standards Track [Page 33] RFC 3165 Script MIB August 2001 "This variable is used for creating rows in the smRunTable. The value of this variable is a currently unused value for smRunIndex, which can be written into the smLaunchStart object associated with this row to launch a script. The value returned when reading this variable must be unique for the smLaunchOwner and smLaunchName associated with this row. Subsequent attempts to read this variable must return different values. This variable will return the special value 0 if no new rows can be created. Note that the data type and the range of this object must be consistent with the definition of smRunIndex." ::= { smLaunchEntry 14 } smLaunchStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines if this row is kept in volatile storage and lost upon reboot or if this row is backed up by stable storage. The value of smLaunchStorageType is only meaningful if the value of the corresponding RowStatus object is active. If smLaunchStorageType has the value permanent(4), then all objects whose MAX-ACCESS value is read-create must be writable, with the exception of the smLaunchStorageType and smLaunchRowStatus objects, which shall be read-only." DEFVAL { volatile } ::= { smLaunchEntry 15 } smLaunchRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. Attempts to `destroy' a row or to set a row `notInService' while the smLaunchOperStatus is `enabled' will result in an inconsistentValue error. Levi & Schoenwaelder Standards Track [Page 34] RFC 3165 Script MIB August 2001 Attempts to `destroy' a row or to set a row `notInService' where the value of the smLaunchStorageType object is `permanent' or `readOnly' will result in an inconsistentValue error. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { smLaunchEntry 16 } smLaunchError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if an attempt to launch a script fails. Implementations must reset the error message to a zero-length string when a new attempt to launch a script is started." DEFVAL { ''H } ::= { smLaunchEntry 17 } smLaunchLastChange OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when this launch table entry was last modified. The value '0000000000000000'H is returned if the launch table entry has not yet been modified. Note that a change of smLaunchStart, smLaunchControl, smLaunchRunIndexNext, smLaunchRowExpireTime, or the resetting of smLaunchError is not considered a change of this launch table entry." DEFVAL { '0000000000000000'H } ::= { smLaunchEntry 18 } smLaunchRowExpireTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object specifies how long this row remains in the `enabled' or `disabled' operational state. The value reported by this object ticks backwards. When the value reaches 0, it stops ticking backward and the row is deleted if there are no smRunTable entries associated with Levi & Schoenwaelder Standards Track [Page 35] RFC 3165 Script MIB August 2001 this smLaunchTable entry. Otherwise, the smLaunchOperStatus changes to `expired' and the row deletion is deferred until there are no smRunTable entries associated with this smLaunchTable entry. The smLaunchRowExpireTime will not tick backwards if it is set to its maximum value (2147483647). In other words, setting this object to its maximum value turns the timer off. The value of this object may be set in order to increase or reduce the remaining time that the launch table entry may be used. Setting the value to 0 will cause an immediate row deletion or transition into the `expired' operational state. It is not possible to set this object while the operational status is `expired'. Attempts to modify this object while the operational status is `expired' leads to an inconsistentValue error. Note that the timer ticks backwards independent of the operational state of the launch table entry." DEFVAL { 2147483647 } ::= { smLaunchEntry 19 } smRunTable OBJECT-TYPE SYNTAX SEQUENCE OF SmRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes scripts that are currently running or have been running in the past." ::= { smRunObjects 2 } smRunEntry OBJECT-TYPE SYNTAX SmRunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular running or finished script." INDEX { smLaunchOwner, smLaunchName, smRunIndex } ::= { smRunTable 1 } SmRunEntry ::= SEQUENCE { smRunIndex Integer32, Levi & Schoenwaelder Standards Track [Page 36] RFC 3165 Script MIB August 2001 smRunArgument OCTET STRING, smRunStartTime DateAndTime, smRunEndTime DateAndTime, smRunLifeTime TimeInterval, smRunExpireTime TimeInterval, smRunExitCode INTEGER, smRunResult OCTET STRING, smRunControl INTEGER, smRunState INTEGER, smRunError SnmpAdminString, smRunResultTime DateAndTime, smRunErrorTime DateAndTime } smRunIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this running or finished script. This value must be unique for all rows in the smRunTable with the same smLaunchOwner and smLaunchName. Note that the data type and the range of this object must be consistent with the definition of smLaunchRunIndexNext and smLaunchStart." ::= { smRunEntry 1 } smRunArgument OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The argument supplied to the script when it started." DEFVAL { ''H } ::= { smRunEntry 2 } smRunStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the execution started. The value '0000000000000000'H is returned if the script has not started yet." DEFVAL { '0000000000000000'H } ::= { smRunEntry 3 } Levi & Schoenwaelder Standards Track [Page 37] RFC 3165 Script MIB August 2001 smRunEndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the execution terminated. The value '0000000000000000'H is returned if the script has not terminated yet." DEFVAL { '0000000000000000'H } ::= { smRunEntry 4 } smRunLifeTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies how long the script can execute. This object returns the remaining time that the script may run. The object is initialized with the value of the associated smLaunchLifeTime object and ticks backwards. The script is aborted immediately when the value reaches 0. The value of this object may be set in order to increase or reduce the remaining time that the script may run. Setting this value to 0 will abort script execution immediately, and, if the value of smRunExpireTime is also 0, will remove this entry from the smRunTable once it has terminated. If smRunLifeTime is set to its maximum value (2147483647), either by a set operation or by its initialization from the smLaunchLifeTime object, then it will not tick backwards. A running script with a maximum smRunLifeTime value will thus never be terminated with a `lifeTimeExceeded' exit code. The value of smRunLifeTime reflects the real-time execution time as seen by the outside world. The value of this object will always be 0 for a script that finished execution, that is smRunState has the value `terminated'. The value of smRunLifeTime does not change while a script is suspended, that is smRunState has the value `suspended'. Note that this does not affect set operations. It is legal to modify smRunLifeTime via set operations while a script is suspended." ::= { smRunEntry 5 } Levi & Schoenwaelder Standards Track [Page 38] RFC 3165 Script MIB August 2001 smRunExpireTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object specifies how long this row can exist in the smRunTable after the script has terminated. This object returns the remaining time that the row may exist before it is aged out. The object is initialized with the value of the associated smLaunchExpireTime object and ticks backwards. The entry in the smRunTable is destroyed when the value reaches 0 and the smRunState has the value `terminated'. The value of this object may be set in order to increase or reduce the remaining time that the row may exist. Setting the value to 0 will destroy this entry as soon as the smRunState has the value `terminated'." ::= { smRunEntry 6 } smRunExitCode OBJECT-TYPE SYNTAX INTEGER { noError(1), halted(2), lifeTimeExceeded(3), noResourcesLeft(4), languageError(5), runtimeError(6), invalidArgument(7), securityViolation(8), genericError(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the reason why a script finished execution. The smRunExitCode code may have one of the following values: - `noError', which indicates that the script completed successfully without errors; - `halted', which indicates that the script was halted by a request from an authorized manager; - `lifeTimeExceeded', which indicates that the script exited because a time limit was exceeded; Levi & Schoenwaelder Standards Track [Page 39] RFC 3165 Script MIB August 2001 - `noResourcesLeft', which indicates that the script exited because it ran out of resources (e.g. memory); - `languageError', which indicates that the script exited because of a language error (e.g. a syntax error in an interpreted language); - `runtimeError', which indicates that the script exited due to a runtime error (e.g. a division by zero); - `invalidArgument', which indicates that the script could not be run because of invalid script arguments; - `securityViolation', which indicates that the script exited due to a security violation; - `genericError', which indicates that the script exited for an unspecified reason. If the script has not yet begun running, or is currently running, the value will be `noError'." DEFVAL { noError } ::= { smRunEntry 7 } smRunResult OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The result value produced by the running script. Note that the result may change while the script is executing." DEFVAL { ''H } ::= { smRunEntry 8 } smRunControl OBJECT-TYPE SYNTAX INTEGER { abort(1), suspend(2), resume(3), nop(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object indicates the desired status of the script execution defined by this row. Setting this object to `abort' will abort execution if the Levi & Schoenwaelder Standards Track [Page 40] RFC 3165 Script MIB August 2001 value of smRunState is `initializing', `executing', `suspending', `suspended' or `resuming'. Setting this object to `abort' when the value of smRunState is `aborting' or `terminated', or if the implementation can determine that the attempt to abort the execution would fail, will result in an inconsistentValue error. Setting this object to `suspend' will suspend execution if the value of smRunState is `executing'. Setting this object to `suspend' will cause an inconsistentValue error if the value of smRunState is not `executing' or if the implementation can determine that the attempt to suspend the execution would fail. Setting this object to `resume' will resume execution if the value of smRunState is `suspending' or `suspended'. Setting this object to `resume' will cause an inconsistentValue error if the value of smRunState is not `suspended' or if the implementation can determine that the attempt to resume the execution would fail. Setting this object to nop(4) has no effect." DEFVAL { nop } ::= { smRunEntry 9 } smRunState OBJECT-TYPE SYNTAX INTEGER { initializing(1), executing(2), suspending(3), suspended(4), resuming(5), aborting(6), terminated(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the script's execution state. If the script has been invoked but has not yet begun execution, the value will be `initializing'. If the script is running, the value will be `executing'. A running script which received a request to suspend execution first transitions into a temporary `suspending' state. The temporary `suspending' state changes to `suspended' when the script has actually been suspended. The temporary `suspending' state changes back to `executing' if Levi & Schoenwaelder Standards Track [Page 41] RFC 3165 Script MIB August 2001 the attempt to suspend the running script fails. A suspended script which received a request to resume execution first transitions into a temporary `resuming' state. The temporary `resuming' state changes to `running' when the script has actually been resumed. The temporary `resuming' state changes back to `suspended' if the attempt to resume the suspended script fails. A script which received a request to abort execution but which is still running first transitions into a temporary `aborting' state. A script which has finished its execution is `terminated'." ::= { smRunEntry 10 } smRunError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if the script startup or execution raised an abnormal condition. An implementation must store a descriptive error message in this object if the script exits with the smRunExitCode `genericError'." DEFVAL { ''H } ::= { smRunEntry 11 } smRunResultTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the smRunResult was last updated. The value '0000000000000000'H is returned if smRunResult has not yet been updated after the creation of this smRunTable entry." DEFVAL { '0000000000000000'H } ::= { smRunEntry 12 } smRunErrorTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the smRunError was last updated. The value '0000000000000000'H is returned if smRunError Levi & Schoenwaelder Standards Track [Page 42] RFC 3165 Script MIB August 2001 has not yet been updated after the creation of this smRunTable entry." DEFVAL { '0000000000000000'H } ::= { smRunEntry 13 } -- -- Notifications. The definition of smTraps makes notification -- registrations reversible (see STD 58, RFC 2578). -- smTraps OBJECT IDENTIFIER ::= { smNotifications 0 } smScriptAbort NOTIFICATION-TYPE OBJECTS { smRunExitCode, smRunEndTime, smRunError } STATUS current DESCRIPTION "This notification is generated whenever a running script terminates with an smRunExitCode unequal to `noError'." ::= { smTraps 1 } smScriptResult NOTIFICATION-TYPE OBJECTS { smRunResult } STATUS current DESCRIPTION "This notification can be used by scripts to notify other management applications about results produced by the script. This notification is not automatically generated by the Script MIB implementation. It is the responsibility of the executing script to emit this notification where it is appropriate to do so." ::= { smTraps 2 } smScriptException NOTIFICATION-TYPE OBJECTS { smRunError } STATUS current DESCRIPTION "This notification can be used by scripts to notify other management applications about script errors. This notification is not automatically generated by the Script MIB implementation. It is the responsibility of the executing script or the runtime system to emit this notification where it is appropriate to do so." ::= { smTraps 3 } -- conformance information Levi & Schoenwaelder Standards Track [Page 43] RFC 3165 Script MIB August 2001 smCompliances OBJECT IDENTIFIER ::= { smConformance 1 } smGroups OBJECT IDENTIFIER ::= { smConformance 2 } -- compliance statements smCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the Script MIB." MODULE -- this module MANDATORY-GROUPS { smLanguageGroup, smScriptGroup2, smLaunchGroup2, smRunGroup2, smNotificationsGroup2 } GROUP smCodeGroup DESCRIPTION "The smCodeGroup is mandatory only for those implementations that support the downloading of scripts via SNMP." OBJECT smScriptSource MIN-ACCESS read-only DESCRIPTION "The smScriptSource object is read-only for implementations that are not able to download script code from a URL." OBJECT smCodeText DESCRIPTION "A compliant implementation need only support write access to the smCodeText object only during row creation." OBJECT smLaunchArgument DESCRIPTION "A compliant implementation has to support a minimum size for smLaunchArgument of 255 octets." OBJECT smRunArgument DESCRIPTION "A compliant implementation has to support a minimum size for smRunArgument of 255 octets." OBJECT smRunResult DESCRIPTION "A compliant implementation has to support a minimum size for smRunResult of 255 octets." OBJECT smRunState DESCRIPTION "A compliant implementation does not have to support script suspension and the smRunState `suspended'. Such an implementation will change into the `suspending' state when the smRunControl is set to `suspend' and remain in this state until smRunControl is set to `resume' or the script terminates." Levi & Schoenwaelder Standards Track [Page 44] RFC 3165 Script MIB August 2001 ::= { smCompliances 2 } smLanguageGroup OBJECT-GROUP OBJECTS { smLangLanguage, smLangVersion, smLangVendor, smLangRevision, smLangDescr, smExtsnExtension, smExtsnVersion, smExtsnVendor, smExtsnRevision, smExtsnDescr } STATUS current DESCRIPTION "A collection of objects providing information about the capabilities of the scripting engine." ::= { smGroups 1 } smScriptGroup2 OBJECT-GROUP OBJECTS { smScriptDescr, smScriptLanguage, smScriptSource, smScriptAdminStatus, smScriptOperStatus, smScriptStorageType, smScriptRowStatus, smScriptError, smScriptLastChange } STATUS current DESCRIPTION "A collection of objects providing information about installed scripts." ::= { smGroups 7 } smCodeGroup OBJECT-GROUP OBJECTS { smCodeText, smCodeRowStatus } STATUS current DESCRIPTION "A collection of objects used to download or modify scripts by using SNMP set requests." ::= { smGroups 3 } smLaunchGroup2 OBJECT-GROUP OBJECTS { smLaunchScriptOwner, smLaunchScriptName, smLaunchArgument, smLaunchMaxRunning, smLaunchMaxCompleted, smLaunchLifeTime, smLaunchExpireTime, smLaunchStart, smLaunchControl, smLaunchAdminStatus, smLaunchOperStatus, smLaunchRunIndexNext, Levi & Schoenwaelder Standards Track [Page 45] RFC 3165 Script MIB August 2001 smLaunchStorageType, smLaunchRowStatus, smLaunchError, smLaunchLastChange, smLaunchRowExpireTime } STATUS current DESCRIPTION "A collection of objects providing information about scripts that can be launched." ::= { smGroups 8 } smRunGroup2 OBJECT-GROUP OBJECTS { smRunArgument, smRunStartTime, smRunEndTime, smRunLifeTime, smRunExpireTime, smRunExitCode, smRunResult, smRunState, smRunControl, smRunError, smRunResultTime, smRunErrorTime } STATUS current DESCRIPTION "A collection of objects providing information about running scripts." ::= { smGroups 9 } smNotificationsGroup2 NOTIFICATION-GROUP NOTIFICATIONS { smScriptAbort, smScriptResult, smScriptException } STATUS current DESCRIPTION "The notifications emitted by the Script MIB." ::= { smGroups 10 } -- -- Deprecated compliance and conformance group definitions -- from RFC 2592. -- smCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMP entities which implement the Script MIB." MODULE -- this module MANDATORY-GROUPS { Levi & Schoenwaelder Standards Track [Page 46] RFC 3165 Script MIB August 2001 smLanguageGroup, smScriptGroup, smLaunchGroup, smRunGroup } GROUP smCodeGroup DESCRIPTION "The smCodeGroup is mandatory only for those implementations that support the downloading of scripts via SNMP." OBJECT smScriptSource MIN-ACCESS read-only DESCRIPTION "The smScriptSource object is read-only for implementations that are not able to download script code from a URL." OBJECT smCodeText DESCRIPTION "A compliant implementation need only support write access to the smCodeText object during row creation." OBJECT smLaunchArgument DESCRIPTION "A compliant implementation has to support a minimum size for smLaunchArgument of 255 octets." OBJECT smRunArgument DESCRIPTION "A compliant implementation has to support a minimum size for smRunArgument of 255 octets." OBJECT smRunResult DESCRIPTION "A compliant implementation has to support a minimum size for smRunResult of 255 octets." OBJECT smRunState DESCRIPTION "A compliant implementation does not have to support script suspension and the smRunState `suspended'. Such an implementation will change into the `suspending' state when the smRunControl is set to `suspend' and remain in this state until smRunControl is set to `resume' or the script terminates." ::= { smCompliances 1 } smScriptGroup OBJECT-GROUP OBJECTS { smScriptDescr, smScriptLanguage, smScriptSource, smScriptAdminStatus, smScriptOperStatus, smScriptStorageType, smScriptRowStatus } STATUS deprecated DESCRIPTION "A collection of objects providing information about installed scripts." Levi & Schoenwaelder Standards Track [Page 47] RFC 3165 Script MIB August 2001 ::= { smGroups 2 } smLaunchGroup OBJECT-GROUP OBJECTS { smLaunchScriptOwner, smLaunchScriptName, smLaunchArgument, smLaunchMaxRunning, smLaunchMaxCompleted, smLaunchLifeTime, smLaunchExpireTime, smLaunchStart, smLaunchControl, smLaunchAdminStatus, smLaunchOperStatus, smLaunchRunIndexNext, smLaunchStorageType, smLaunchRowStatus } STATUS deprecated DESCRIPTION "A collection of objects providing information about scripts that can be launched." ::= { smGroups 4 } smRunGroup OBJECT-GROUP OBJECTS { smRunArgument, smRunStartTime, smRunEndTime, smRunLifeTime, smRunExpireTime, smRunExitCode, smRunResult, smRunState, smRunControl, smRunError } STATUS deprecated DESCRIPTION "A collection of objects providing information about running scripts." ::= { smGroups 5 } smNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { smScriptAbort, smScriptResult } STATUS deprecated DESCRIPTION "The notifications emitted by the Script MIB." ::= { smGroups 6 } END Levi & Schoenwaelder Standards Track [Page 48] RFC 3165 Script MIB August 2001 7. Usage Examples This section presents some examples that explain how a manager can use the Script MIB defined in this memo. The purpose of these examples is to explain the steps that are normally used to delegate management scripts. 7.1. Pushing a Script via SNMP This example explains the steps performed by a manager to push a script into a distributed manager. 1. The manager first checks the smLangTable and the smExtsnTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to an empty string. The smScriptLanguage object is set to the language in which the script was written. The smScriptStorageType object is set to `volatile' to indicate that the script will be loaded via the smCodeTable. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active' and the smScriptAdminStatus object to `editing'. 4. The manager pushes the script to the distributed manager by issuing a couple of SNMP set-requests to fill the smCodeTable. 5. Once the whole script has been transferred, the manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 6. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 7. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the smScriptStorageType object to `nonVolatile'. Levi & Schoenwaelder Standards Track [Page 49] RFC 3165 Script MIB August 2001 7.2. Pulling a Script from a URL This example explains the steps performed by a manager to cause a distributed manager to pull a script from a URL. 1. The manager first checks the smLangTable and the smExtsnTable in order to select the appropriate script or language. 2. The manager creates a row in the smScriptTable by issuing an SNMP set-request. The smScriptRowStatus object is set to `createAndWait' and the smScriptSource object is set to the URL which points to the script source. The smScriptLanguage object is set to the language in which the script was written. The smScriptOwner is set to a string which identifies the principal who owns the new row. The smScriptName defines the administratively assigned unique name for the script. 3. The manager sets the smScriptRowStatus object to `active'. 4. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This causes a retrieval operation to pull the script from the URL stored in smScriptSource. This retrieval operation might be followed by a compile operation if the language requires a compilation step. 5. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 6. If the manager wants to store the script in local non-volatile storage, it should send a set-request which changes the smScriptStorageType object to `nonVolatile'. 7.3. Modifying an Existing Script This section explains how a manager can modify a script by sending SNMP set-requests. 1. First, the script is de-activated by setting the smScriptAdminStatus to `disabled'. 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sets smScriptSource to an empty string and smScriptAdminStatus to `editing'. This makes the script source available in the smCodeTable. Levi & Schoenwaelder Standards Track [Page 50] RFC 3165 Script MIB August 2001 4. The manager polls the smScriptOperStatus object until the value is `editing'. 5. The manager sends SNMP set-requests to modify the script in the smCodeTable. 6. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 7. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'. 7.4. Removing an Existing Script This section explains how a manager can remove a script from a distributed manager. 1. First, the manager sets the smScriptAdminStatus to `disabled'. This will ensure that no new scripts can be started while running scripts finish their execution. 2. The manager polls the smScriptOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smScriptRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation. 7.5. Creating a Launch Button This section explains how a manager can create a launch button for starting a script. 1. The manager, who is identified by an smLaunchOwner value, first chooses a name for the new row in the smLaunchTable. The manager sends an SNMP set-request to set the smLaunchRowStatus object for this smLaunchOwner and smLaunchName to `createAndWait'. 2. The manager fills the new smLaunchTable row with all required parameters. The smLaunchScriptOwner and smLaunchScriptName values point to the script that should be started from this launch button. 3. The manager sets the smLaunchRowStatus object to `active'. Levi & Schoenwaelder Standards Track [Page 51] RFC 3165 Script MIB August 2001 4. The manager sends a set-request to change smLaunchAdminStatus to `enabled' once the new smLaunchTable row is complete. 5. The manager polls the smLaunchOperStatus object until the value is `enabled'. 7.6. Launching a Script This section explains the suggested way to launch a script from a given launch button. 1. The manager first retrieves the value of smLaunchRunIndexNext from the launch button selected to start the script. 2. The manager sends an SNMP set-request to set the smLaunchStart object to the value obtained in step 1. This will launch the script if all necessary pre-conditions are satisfied (see the definition of smLaunchStart for more details). The manager can also provide the smLaunchArgument in the same set-request that is used to start the script. Upon successful start, a new row will be created in the smRunTable indexed by smLaunchOwner, smLaunchName and the value written to smLaunchStart. 3. The manager polls the smRunState object until the value is either `executing' (the default case), `suspended' or `terminated'. The first step is not required. A manager can also try to guess an unused value for smRunIndex if the manager wants to start the script in a single transaction. A manager can also use the special value 0 if it does not care about the smRunIndex. 7.7. Suspending a Running Script This section explains how a manager can suspend a running script. 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start the running script to `suspend'. Setting smLaunchControl will suspend all running scripts started from the launch button while smRunControl will only suspend the running script associated with the smRunControl instance. 2. The manager polls the smRunState object until the value is either `suspended', `executing', or `terminated'. If the value is `suspended', then the suspend operation was successful. If the value is `executing', then the attempt to suspend the script Levi & Schoenwaelder Standards Track [Page 52] RFC 3165 Script MIB August 2001 failed. The value `terminated' can be received in cases where the suspend operation failed and the running script terminated between the polls. Note that the set operation in the first step can lead to an inconsistentValue error which indicates that the suspend operation failed (e.g., because the runtime system does not support suspend/resume). There is no need to poll smRunState in this case. 7.8. Resuming a Suspended Script This section explains how a manager can resume a suspended script. 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start the running script to `resume'. Setting smLaunchControl will resume all running scripts started from the launch button while smRunControl will only resume the running script associated with the smRunControl instance. 2. The manager polls the smRunState object until the value is either `suspended', `executing', or `terminated'. If the value is `executing', then the resume operation was successful. If the value is `suspended', then the attempt to resume the script failed. The value `terminated' can be received in cases where the resume operation was successful and the running script terminated between the polls. Note that the set operation in the first step can lead to an inconsistentValue error which indicates that the resume operation failed (e.g., because the runtime system does not support suspend/resume). There is no need to poll smRunState in this case. 7.9. Terminating a Running Script This section explains two ways to terminate a running script. The first approach is as follows: 1. The manager sets the smRunControl object of the running script or the smLaunchControl object of the launch button used to start the running script to `abort'. Setting smLaunchControl will abort all running scripts started from the launch button while smRunControl will only abort the running script associated with the smRunControl instance. 2. The manager polls the smRunState object until the value is `terminated'. Levi & Schoenwaelder Standards Track [Page 53] RFC 3165 Script MIB August 2001 The second way to terminate a script is to set the smRunLifeTime to zero which causes the runtime system to terminate the script with a `lifeTimeExceeded' exit code: 1. The manager changes the value of smRunLifeTime to 0. This causes the Script MIB implementation to abort the script because the remaining life time has expired. 2. The manager polls the smRunState object until the value is `terminated'. Note that changing the smRunLifeTime value can also be used to increase the permitted lifetime of a running script. For example, a manager can choose to set smRunLifeTime to a small fixed time interval and increase the value periodically. This strategy has the nice effect that scripts terminate automatically if the manager loses contact with the Script MIB engine. 7.10. Removing a Terminated Script This section explains how a manager can remove a terminated script. 1. The manager changes the smRunExpireTime to 0. This causes the Script MIB implementation to destroy the smRunTable entry of the terminated script. 7.11. Removing a Launch Button This section explains how a manager can remove a launch button from a distributed manager. 1. First, the manager sets the smLaunchAdminStatus to `disabled'. This will ensure that no new scripts can be started from this launch button while running scripts finish their execution. 2. The manager polls the smLaunchOperStatus object until the value is `disabled'. 3. The manager sends an SNMP set-request to change the smLaunchRowStatus object to `destroy'. This will remove the row and all associated resources from the Script MIB implementation. 8. VACM Configuration Examples This section shows how the view-based access control model defined in RFC 2575 [RFC2575] can be configured to control access to the Script MIB. Levi & Schoenwaelder Standards Track [Page 54] RFC 3165 Script MIB August 2001 8.1. Sandbox for Guests The first example demonstrates how to configure VACM to give the members of the VACM group "guest" limited access to the Script MIB. The MIB views defined below give the members of the "guest" group a sandbox where they can install and start their own scripts, but not access any other scripts maintained by the Script MIB implementation. vacmAccessReadView."guest"."".usm.authNoPriv = "guestReadView" vacmAccessWriteView."guest"."".usm.authNoPriv = "guestWriteView" The guestReadView grants read access to the smLangTable, the smExtsnTable and to all the table entries owned by "guest": guestReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included) The guestWriteView grants write access to all the table entries owned by "guest": guestWriteView: smScriptObjects.*.*.*."guest" (included) smRunObjects.*.*.*."guest" (included) 8.2. Sharing Scripts This example demonstrates how VACM can be used to share a repository of scripts between the members of the "senior" and the members of the "junior" VACM group: vacmAccessReadView."junior"."".usm.authNoPriv = "juniorReadView" vacmAccessWriteView."junior"."".usm.authNoPriv = "juniorWriteView" juniorReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included) smScriptObjects.*.*.*."utils" (included) juniorWriteView: smScriptObjects.*.*.*."junior" (included) smRunObjects.*.*.*."junior" (included) Levi & Schoenwaelder Standards Track [Page 55] RFC 3165 Script MIB August 2001 The definitions above allow the members of the "junior" VACM group to start the scripts owned by "utils" in addition to the script the members of the "junior" VACM group installed themselves. This is accomplished by giving the members of "junior" read access to scripts in "utils". This allows members of "junior" to create entries in the smLaunchTable which refer to scripts in "utils", and to launch those scripts using these entries in the smLaunchTable. vacmAccessReadView."senior"."".usm.authNoPriv = "seniorReadView" vacmAccessWriteView."senior"."".usm.authNoPriv = "seniorWriteView" seniorReadView: smLangTable (included) smExtsnTable (included) smScriptObjects.*.*.*."senior" (included) smRunObjects.*.*.*."senior" (included) smScriptObjects.*.*.*."utils" (included) seniorWriteView: smScriptObjects.*.*.*."senior" (included) smRunObjects.*.*.*."senior" (included) smScriptObjects.*.*.*."utils" (included) The definitions for the members of the "senior" VACM group allow to start the scripts owned by "utils" in addition to the script the members of the "senior" VACM group installed themself. The third write access rule in the seniorWriteView also grants the permission to install scripts owned by "utils". The members of the "senior" VACM group therefore have the permissions to install and modify scripts that can be called by the members of the "junior" VACM group. 8.3. Emergency Scripts This example demonstrates how VACM can be used to allow the members of the "junior" VACM group to launch scripts that are executed with the permissions associated with the "emergency" owner. This works by adding the following rules to the juniorReadView and the juniorWriteView: juniorReadView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) juniorWriteView smLaunchStart."emergency" (included) smLaunchArgument."emergency" (included) Levi & Schoenwaelder Standards Track [Page 56] RFC 3165 Script MIB August 2001 The rules added to the juniorReadView grant read access to the scripts, the launch buttons and the results owned by "emergency". The rules added to the juniorWriteView grant write permissions to the smLaunchStart and smLaunchArgument variables owned by "emergency". Members of the "junior" VACM group can therefore start scripts that will execute under the owner "emergency". seniorReadView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) seniorWriteView: smScriptObjects.*.*.*."emergency" (included) smRunObjects.*.*.*."emergency" (included) The rules added to the seniorReadView and the seniorWriteView will give the members of the "senior" VACM group the rights to install emergency scripts and to configure appropriate launch buttons. 9. IANA Considerations The Internet Assigned Numbers Authority (IANA) is responsible for maintaining a MIB module (IANA-LANGUAGE-MIB) which provides OID registrations for well-known languages. The IANA language registry is intended to reduce interoperability problems by providing a single list of well-known languages. However, it is of course still possible to register languages in private OID spaces. Registering languages in private OID spaces is especially attractive if a language is used for experimentation or if a language is only used in environments where the distribution of MIB modules with the language registration does not cause any maintenance problems. Any additions or changes to the list of languages registered via IANA require Designated Expert Review as defined in the IANA guidelines [RFC2434]. The Designated Expert will be selected by the IESG Area Director for the IETF Operations and Management Area. 10. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Levi & Schoenwaelder Standards Track [Page 57] RFC 3165 Script MIB August 2001 SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. This MIB provides the ability to distribute applications written in an arbitrary language to remote systems in a network. The security features of the languages available in a particular implementation should be taken into consideration when deploying an implementation of this MIB. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 2575 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control over SNMP access to Script MIB objects. There are a number of other access control issues that are outside of the scope of this MIB. For example, access control on URLs, especially those that use the file scheme, must be realized by the underlying operating system. A mapping of the owner index value to a local operating system security Levi & Schoenwaelder Standards Track [Page 58] RFC 3165 Script MIB August 2001 user identity should be used by an implementation of this MIB to control access to operating system resources when resolving URLs or executing scripts. 11. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Changes from RFC 2592 The following list documents major changes from the previous version of this document, published as RFC 2592: - Updated the boilerplate and the references. - Added revision clauses to the module identity macro. - Various typos have been fixed. - Added SIZE restriction to smScriptName which is consistent with smLaunchScriptName. Added DEFVAL and some clarifying text on the usage of a zero-length string to smLaunchScriptName. - Clarified under which conditions changes to smScriptLanguage are invalid. - Added new smScriptError and smLaunchError objects. - Setting smRunLifeTime to its maximum value now disables the timer so that scripts can run forever. Levi & Schoenwaelder Standards Track [Page 59] RFC 3165 Script MIB August 2001 - Added the `autostart' value to the smLaunchAdminStatus object which allows to launch scripts during the disable->enabled transition of smLaunchOperStatus. - Added an additional step to the "creating a launch button" procedure which sets the smLaunchRowStatus to active. - Added a final polling step in the procedure to launch a script. - Added a final polling step in the procedure to terminate a running script. - Removed the requirement that smRunError is a zero-length string while the smRunExitCode has the value `noError'. - Added new smScriptLastChange, smLaunchLastChange, smRunResultTime, and smRunErrorTime objects. - Added some additional boilerplate text to the security considerations section. - Added a new smLaunchRowExpireTime object and a new `expired' state to the smLaunchOperStatus object. - Clarified that the smRunState object reports the actual state if attempts to suspend or resume scripts fail. - Clarified the conditions under which set operations to smLaunchControl and smRunControl can lead to inconsistentValue errors. - Added procedures for suspending/resuming/removing running scripts to section 7. - Added text to the smScriptStorageType description to better highlight the difference between the storage type of the script row entry and the script itself. - Updated the smCompliances statement to not require write access to the smCodeText object after row creation. - Deprecated smCompliance, smScriptGroup, smLaunchGroup, smRunGroup, smNotificationsGroup and created smCompliance2, smScriptGroup2, smLaunchGroup2, smRunGroup2 and smNotificationsGroup2 that take care of the new objects and notifications. Levi & Schoenwaelder Standards Track [Page 60] RFC 3165 Script MIB August 2001 13. Acknowledgments This document was produced by the IETF Distributed Management (DISMAN) working group. 14. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Levi & Schoenwaelder Standards Track [Page 61] RFC 3165 Script MIB August 2001 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, " Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Levi & Schoenwaelder Standards Track [Page 62] RFC 3165 Script MIB August 2001 15. Editors' Addresses David B. Levi Nortel Networks 4401 Great America Parkway Santa Clara, CA 95052-8185 USA Phone: +1 423 686 0432 EMail: dlevi@nortelnetworks.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de Levi & Schoenwaelder Standards Track [Page 63] RFC 3165 Script MIB August 2001 16. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Levi & Schoenwaelder Standards Track [Page 64] snmp-mibs-downloader-1.1/mibrfcs/rfc3176.txt0000644000000000000000000016541311402176071015574 0ustar Network Working Group P. Phaal Request for Comments: 3176 S. Panchen Category: Informational N. McKee InMon Corp. September 2001 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo defines InMon Coporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. Table of Contents 1. Overview ..................................................... 2 2. Sampling Mechanisms .......................................... 2 2.1 Sampling of Switched Flows ............................... 3 2.1.1 Distributed Switching .............................. 4 2.1.2 Random Number Generation ........................... 4 2.2 Sampling of Network Interface Statistics ................. 4 3. sFlow MIB .................................................... 5 3.1 The SNMP Management Framework ............................ 5 3.2 Definitions .............................................. 6 4. sFlow Datagram Format ........................................ 14 5. Security Considerations ...................................... 25 5.1 Control .................................................. 26 5.2 Transport ................................................ 26 5.3 Confidentiality .......................................... 26 6. References ................................................... 27 7. Authors' Addresses ........................................... 29 Phaal, et al. Informational [Page 1] RFC 3176 InMon Corporation's sFlow September 2001 8. Intellectual Property Statement .............................. 30 9. Full Copyright Statement ..................................... 31 1. Overview sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. The architecture and sampling techniques used in the sFlow monitoring system are designed to provide continuous site-wide (and network- wide) traffic monitoring for high speed switched and routed networks. The design specifically addresses issues associated with: o Accurately monitoring network traffic at Gigabit speeds and higher. o Scaling to manage tens of thousands of agents from a single point. o Extremely low cost agent implementation. The sFlow monitoring system consists of an sFlow Agent (embedded in a switch or router or in a stand alone probe) and a central data collector, or sFlow Analyzer. The sFlow Agent uses sampling technology to capture traffic statistics from the device it is monitoring. sFlow Datagrams are used to immediately forward the sampled traffic statistics to an sFlow Analyzer for analysis. This document describes the sampling mechanisms used by the sFlow Agent, the SFLOW MIB used by the sFlow Analyzer to control the sFlow Agent, and the sFlow Datagram Format used by the sFlow Agent to send traffic data to the sFlow Analyzer. 2. Sampling Mechanisms The sFlow Agent uses two forms of sampling: statistical packet-based sampling of switched flows, and time-based sampling of network interface statistics. Phaal, et al. Informational [Page 2] RFC 3176 InMon Corporation's sFlow September 2001 2.1 Sampling of Switched Flows A flow is defined as all the packets that are received on one interface, enter the Switching/Routing Module and are sent to another interface. In the case of a one-armed router, the source and destination interface could be the same. In the case of a broadcast or multicast packet there may be multiple destination interfaces. The sampling mechanism must ensure that any packet involved in a flow has an equal chance of being sampled, irrespective of the flow to which it belongs. Sampling flows is accomplished as follows: When a packet arrives on an interface, a filtering decision is made that determines whether the packet should be dropped. If the packet is not filtered a destination interface is assigned by the switching/routing function. At this point a decision is made on whether or not to sample the packet. The mechanism involves a counter that is decremented with each packet. When the counter reaches zero a sample is taken. Whether or not a sample is taken, the counter Total_Packets is incremented. Total_Packets is a count of all the packets that could have been sampled. Taking a sample involves either copying the packet's header, or extracting features from the packet (see sFlow Datagram Format for a description of the different forms of sample). Every time a sample is taken, the counter Total_Samples, is incremented. Total_Samples is a count of the number of samples generated. Samples are sent by the sampling entity to the sFlow Agent for processing. The sample includes the packet information, and the values of the Total_Packets and Total_Samples counters. When a sample is taken, the counter indicating how many packets to skip before taking the next sample should be reset. The value of the counter should be set to a random integer where the sequence of random integers used over time should be such that (1) Total_Packets/Total_Samples = Rate An alternative strategy for packet sampling is to generate a random number for each packet, compare the random number to a preset threshold and take a sample whenever the random number is smaller than the threshold value. Calculation of an appropriate threshold value depends on the characteristics of the random number generator, however, the resulting sample stream must still satisfy (1). Phaal, et al. Informational [Page 3] RFC 3176 InMon Corporation's sFlow September 2001 2.1.1 Distributed Switching The SFLOW MIB permits separate sampling entities to be associated with different physical or logical elements of the switch (such as interfaces, backplanes or VLANs). Each sampling engine has its own independent state (i.e., Total_Packets, Total_Samples, Skip and Rate), and forwards its own sample messages to the sFlow Agent. The sFlow Agent is responsible for packaging the samples into datagrams for transmission to an sFlow Analyzer. 2.1.2 Random Number Generation The essential property of the random number generator is that the mean value of the numbers it generates converges to the required sampling rate. A uniform distribution random number generator is very effective. The range of skip counts (the variance) does not significantly affect results; variation of +-10% of the mean value is sufficient. The random number generator must ensure that all numbers in the range between its maximum and minimum values of the distribution are possible; a random number generator only capable of generating even numbers, or numbers with any common divisor is unsuitable. A new skip value is only required every time a sample is taken. 2.2 Sampling of Network Interface Statistics The objective of the counter sampling is to efficiently, periodically poll each data source on the device and extract key statistics. For efficiency and scalability reasons, the sFlow System implements counter polling in the sFlow Agent. A maximum polling interval is assigned to the agent, but the agent is free to schedule polling in order maximize internal efficiency. Flow sampling and counter sampling are designed as part of an integrated system. Both types of samples are combined in sFlow Datagrams. Since flow sampling will cause a steady, but random, stream of datagrams to be sent to the sFlow Analyzer, counter samples may be taken opportunistically in order to fill these datagrams. One strategy for counter sampling has the sFlow Agent keep a list of counter sources being sampled. When a flow sample is generated the sFlow Agent examines the list and adds counters to the sample datagram, least recently sampled first. Counters are only added to the datagram if the sources are within a short period, 5 seconds say, Phaal, et al. Informational [Page 4] RFC 3176 InMon Corporation's sFlow September 2001 of failing to meet the required sampling interval (see sFlowCounterSamplingInterval in SFLOW MIB). Whenever a counter source's statistics are added to a sample datagram, the time the counter source was last sampled is updated and the counter source is placed at the end of the list. Periodically, say every second, the sFlow Agent examines the list of counter sources and sends any counters that need to be sent to meet the sampling interval requirement. Alternatively, if the agent regularly schedules counter sampling, then it should schedule each counter source at a different start time (preferably randomly) so that counter sampling is not synchronized within an agent or between agents. 3. sFlow MIB The sFlow MIB defines a control interface for an sFlow Agent. This interface provides a standard mechanism for remotely controlling and configuring an sFlow Agent. 3.1 The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [2]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The second version, called SMIv2, is described in STD 58, RFC 2578 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [9]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13]. Phaal, et al. Informational [Page 5] RFC 3176 InMon Corporation's sFlow September 2001 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [9]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [14]. o A set of fundamental applications described in RFC 2573 [15] and the view-based access control mechanism described in RFC 2575 [16]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3.2 Definitions SFLOW-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprises FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB OwnerString FROM RMON-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; sFlowMIB MODULE-IDENTITY LAST-UPDATED "200105150000Z" -- May 15, 2001 ORGANIZATION "InMon Corp." CONTACT-INFO Phaal, et al. Informational [Page 6] RFC 3176 InMon Corporation's sFlow September 2001 "Peter Phaal InMon Corp. http://www.inmon.com/ Tel: +1-415-661-6343 Email: peter_phaal@inmon.com" DESCRIPTION "The MIB module for managing the generation and transportation of sFlow data records." -- -- Revision History -- REVISION "200105150000Z" -- May 15, 2001 DESCRIPTION "Version 1.2 Brings MIB into SMI v2 compliance." REVISION "200105010000Z" -- May 1, 2001 DESCRIPTION "Version 1.1 Adds sFlowDatagramVersion." ::= { enterprises 4300 1 } sFlowAgent OBJECT IDENTIFIER ::= { sFlowMIB 1 } sFlowVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Uniquely identifies the version and implementation of this MIB. The version string must have the following structure: ;; where: must be '1.2', the version of this MIB. the name of the organization responsible for the agent implementation. the specific software build of this agent. As an example, the string '1.2;InMon Corp.;2.1.1' indicates that this agent implements version '1.2' of the SFLOW MIB, that it was developed by 'InMon Corp.' and that the software build is '2.1.1'. The MIB Version will change with each revision of the SFLOW Phaal, et al. Informational [Page 7] RFC 3176 InMon Corporation's sFlow September 2001 MIB. Management entities must check the MIB Version and not attempt to manage agents with MIB Versions greater than that for which they were designed. Note: The sFlow Datagram Format has an independent version number which may change independently from . applies to the structure and semantics of the SFLOW MIB only." DEFVAL { "1.2;;" } ::= { sFlowAgent 1 } sFlowAgentAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the address associated with this agent. Only ipv4 and ipv6 types are supported." ::= { sFlowAgent 2 } sFlowAgentAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address associated with this agent. In the case of a multi-homed agent, this should be the loopback address of the agent. The sFlowAgent address must provide SNMP connectivity to the agent. The address should be an invariant that does not change as interfaces are reconfigured, enabled, disabled, added or removed. A manager should be able to use the sFlowAgentAddress as a unique key that will identify this agent over extended periods of time so that a history can be maintained." ::= { sFlowAgent 3 } sFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF SFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the sFlow samplers within a device." ::= { sFlowAgent 4 } sFlowEntry OBJECT-TYPE SYNTAX SFlowEntry Phaal, et al. Informational [Page 8] RFC 3176 InMon Corporation's sFlow September 2001 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of an sFlow sampler." INDEX { sFlowDataSource } ::= { sFlowTable 1 } SFlowEntry ::= SEQUENCE { sFlowDataSource OBJECT IDENTIFIER, sFlowOwner OwnerString, sFlowTimeout Integer32, sFlowPacketSamplingRate Integer32, sFlowCounterSamplingInterval Integer32, sFlowMaximumHeaderSize Integer32, sFlowMaximumDatagramSize Integer32, sFlowCollectorAddressType InetAddressType, sFlowCollectorAddress InetAddress, sFlowCollectorPort Integer32, sFlowDatagramVersion Integer32 } sFlowDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the source of the data for the sFlow sampler. The following data source types are currently defined: - ifIndex. DataSources of this traditional form are called 'port-based'. Ideally the sampling entity will perform sampling on all flows originating from or destined to the specified interface. However, if the switch architecture only permits input or output sampling then the sampling agent is permitted to only sample input flows input or output flows. Each packet must only be considered once for sampling, irrespective of the number of ports it will be forwarded to. Note: Port 0 is used to indicate that all ports on the device are represented by a single data source. - sFlowPacketSamplingRate applies to all ports on the device capable of packet sampling. - sFlowCounterSamplingInterval applies to all ports. - smonVlanDataSource. A dataSource of this form refers to a 'Packet-based VLAN' and is called a 'VLAN-based' dataSource. is the VLAN Phaal, et al. Informational [Page 9] RFC 3176 InMon Corporation's sFlow September 2001 ID as defined by the IEEE 802.1Q standard. The value is between 1 and 4094 inclusive, and it represents an 802.1Q VLAN-ID with global scope within a given bridged domain. Sampling is performed on all packets received that are part of the specified VLAN (no matter which port they arrived on). Each packet will only be considered once for sampling, irrespective of the number of ports it will be forwarded to. - entPhysicalEntry. A dataSource of this form refers to a physical entity within the agent (e.g., entPhysicalClass = backplane(4)) and is called an 'entity-based' dataSource. Sampling is performed on all packets entering the resource (e.g. If the backplane is being sampled, all packets transmitted onto the backplane will be considered as single candidates for sampling irrespective of the number of ports they ultimately reach). Note: Since each DataSource operates independently, a packet that crosses multiple DataSources may generate multiple flow records." ::= { sFlowEntry 1 } sFlowOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS current DESCRIPTION "The entity making use of this sFlow sampler. The empty string indicates that the sFlow sampler is currently unclaimed. An entity wishing to claim an sFlow sampler must make sure that the sampler is unclaimed before trying to claim it. The sampler is claimed by setting the owner string to identify the entity claiming the sampler. The sampler must be claimed before any changes can be made to other sampler objects. In order to avoid a race condition, the entity taking control of the sampler must set both the owner and a value for sFlowTimeout in the same SNMP set request. When a management entity is finished using the sampler, it should set its value back to unclaimed. The agent must restore all other entities this row to their default values when the owner is set to unclaimed. This mechanism provides no enforcement and relies on the cooperation of management entities in order to ensure that Phaal, et al. Informational [Page 10] RFC 3176 InMon Corporation's sFlow September 2001 competition for a sampler is fairly resolved." DEFVAL { "" } ::= { sFlowEntry 2 } sFlowTimeout OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The time (in seconds) remaining before the sampler is released and stops sampling. When set, the owner establishes control for the specified period. When read, the remaining time in the interval is returned. A management entity wanting to maintain control of the sampler is responsible for setting a new value before the old one expires. When the interval expires, the agent is responsible for restoring all other entities in this row to their default values." DEFVAL { 0 } ::= { sFlowEntry 3 } sFlowPacketSamplingRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The statistical sampling rate for packet sampling from this source. Set to N to sample 1/Nth of the packets in the monitored flows. An agent should choose its own algorithm introduce variance into the sampling so that exactly every Nth packet is not counted. A sampling rate of 1 counts all packets. A sampling rate of 0 disables sampling. The agent is permitted to have minimum and maximum allowable values for the sampling rate. A minimum rate lets the agent designer set an upper bound on the overhead associated with sampling, and a maximum rate may be the result of hardware restrictions (such as counter size). In addition not all values between the maximum and minimum may be realizable as the sampling rate (again because of implementation considerations). When the sampling rate is set the agent is free to adjust the value so that it lies between the maximum and minimum values Phaal, et al. Informational [Page 11] RFC 3176 InMon Corporation's sFlow September 2001 and has the closest achievable value. When read, the agent must return the actual sampling rate it will be using (after the adjustments previously described). The sampling algorithm must converge so that over time the number of packets sampled approaches 1/Nth of the total number of packets in the monitored flows." DEFVAL { 0 } ::= { sFlowEntry 4 } sFlowCounterSamplingInterval OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of seconds between successive samples of the counters associated with this data source. A sampling interval of 0 disables counter sampling." DEFVAL { 0 } ::= { sFlowEntry 5 } sFlowMaximumHeaderSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of bytes that should be copied from a sampled packet. The agent may have an internal maximum and minimum permissible sizes. If an attempt is made to set this value outside the permissible range then the agent should adjust the value to the closest permissible value." DEFVAL { 128 } ::= { sFlowEntry 6 } sFlowMaximumDatagramSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of data bytes that can be sent in a single sample datagram. The manager should set this value to avoid fragmentation of the sFlow datagrams." DEFVAL { 1400 } ::= { sFlowEntry 7 } sFlowCollectorAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write Phaal, et al. Informational [Page 12] RFC 3176 InMon Corporation's sFlow September 2001 STATUS current DESCRIPTION "The type of sFlowCollectorAddress." DEFVAL { ipv4 } ::= { sFlowEntry 8 } sFlowCollectorAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address of the sFlow collector. If set to 0.0.0.0 all sampling is disabled." DEFVAL { "0.0.0.0" } ::= { sFlowEntry 9 } sFlowCollectorPort OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The destination port for sFlow datagrams." DEFVAL { 6343 } ::= { sFlowEntry 10 } sFlowDatagramVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The version of sFlow datagrams that should be sent. When set to a value not support by the agent, the agent should adjust the value to the highest supported value less than the requested value, or return an error if no such values exist." DEFVAL { 4 } ::= { sFlowEntry 11 } -- -- Compliance Statements -- sFlowMIBConformance OBJECT IDENTIFIER ::= { sFlowMIB 2 } sFlowMIBGroups OBJECT IDENTIFIER ::= { sFlowMIBConformance 1 } sFlowMIBCompliances OBJECT IDENTIFIER ::= { sFlowMIBConformance 2 } sFlowCompliance MODULE-COMPLIANCE STATUS current Phaal, et al. Informational [Page 13] RFC 3176 InMon Corporation's sFlow September 2001 DESCRIPTION "Compliance statements for the sFlow Agent." MODULE -- this module MANDATORY-GROUPS { sFlowAgentGroup } OBJECT sFlowAgentAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "Agents need only support ipv4." OBJECT sFlowCollectorAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "Agents need only support ipv4." ::= { sFlowMIBCompliances 1 } sFlowAgentGroup OBJECT-GROUP OBJECTS { sFlowVersion, sFlowAgentAddressType, sFlowAgentAddress, sFlowDataSource, sFlowOwner, sFlowTimeout, sFlowPacketSamplingRate, sFlowCounterSamplingInterval, sFlowMaximumHeaderSize, sFlowMaximumDatagramSize, sFlowCollectorAddressType, sFlowCollectorAddress, sFlowCollectorPort, sFlowDatagramVersion } STATUS current DESCRIPTION "A collection of objects for managing the generation and transportation of sFlow data records." ::= { sFlowMIBGroups 1 } END The sFlow MIB references definitions from a number of existing RFCs [18], [19], [20] and [21]. 4. sFlow Datagram Format The sFlow datagram format specifies a standard format for the sFlow Agent to send sampled data to a remote data collector. The format of the sFlow datagram is specified using the XDR standard [1]. XDR is more compact than ASN.1 and simpler for the sFlow Agent to encode and the sFlow Analyzer to decode. Samples are sent as UDP packets to the host and port specified in the SFLOW MIB. The lack of reliability in the UDP transport mechanism does not significantly affect the accuracy of the measurements obtained from an sFlow Agent. Phaal, et al. Informational [Page 14] RFC 3176 InMon Corporation's sFlow September 2001 o If counter samples are lost then new values will be sent during the next polling interval. The chance of an undetected counter wrap is negligible. The sFlow datagram specifies 64 bit octet counters, and with typical counter polling intervals between 20 to 120 seconds, the chance of a long enough sequence of sFlow datagrams being lost to hide a counter wrap is very small. o The net effect of lost flow samples is a slight reduction in the effective sampling rate. The use of UDP reduces the amount of memory required to buffer data. UDP also provides a robust means of delivering timely traffic information during periods of intense traffic (such as a denial of service attack). UDP is more robust than a reliable transport mechanism because under overload the only effect on overall system performance is a slight increase in transmission delay and a greater number of lost packets, neither of which has a significant effect on an sFlow-based monitoring system. If a reliable transport mechanism were used then an overload would introduce long transmission delays and require large amounts of buffer memory on the agent. While the sFlow Datagram structure permits multiple samples to be included in each datagram, the sampling agent must not wait for a buffer to fill with samples before sending the sample datagram. sFlow sampling is intended to provide timely information on traffic. The agent may at most delay a sample by 1 second before it is required to send the datagram. The agent should try to piggyback counter samples on the datagram stream resulting from flow sampling. Before sending out a datagram the remaining space in the buffer can be filled with counter samples. The agent has discretion in the timing of its counter polling, the specified counter sampling intervals sFlowCounterSamplingInterval is a maximum, so the agent is free to sample counters early if it has space in a datagram. If counters must be sent in order to satisfy the maximum sampling interval then a datagram must be sent containing the outstanding counters. The following is the XDR description of an sFlow Datagram: /* sFlow Datagram Version 4 */ /* Revision History - version 4 adds support BGP communities - version 3 adds support for extended_url information */ /* sFlow Sample types */ Phaal, et al. Informational [Page 15] RFC 3176 InMon Corporation's sFlow September 2001 /* Address Types */ typedef opaque ip_v4[4]; typedef opaque ip_v6[16]; enum address_type { IP_V4 = 1, IP_V6 = 2 } union address (address_type type) { case IP_V4: ip_v4; case IP_V6: ip_v6; } /* Packet header data */ const MAX_HEADER_SIZE = 256; /* The maximum sampled header size. */ /* The header protocol describes the format of the sampled header */ enum header_protocol { ETHERNET-ISO8023 = 1, ISO88024-TOKENBUS = 2, ISO88025-TOKENRING = 3, FDDI = 4, FRAME-RELAY = 5, X25 = 6, PPP = 7, SMDS = 8, AAL5 = 9, AAL5-IP = 10, /* e.g., Cisco AAL5 mux */ IPv4 = 11, IPv6 = 12, MPLS = 13 } struct sampled_header { header_protocol protocol; /* Format of sampled header */ unsigned int frame_length; /* Original length of packet before sampling */ opaque header; /* Header bytes */ } /* Packet IP version 4 data */ struct sampled_ipv4 { Phaal, et al. Informational [Page 16] RFC 3176 InMon Corporation's sFlow September 2001 unsigned int length; /* The length of the IP packet excluding lower layer encapsulations */ unsigned int protocol; /* IP Protocol type (for example, TCP = 6, UDP = 17) */ ip_v4 src_ip; /* Source IP Address */ ip_v4 dst_ip; /* Destination IP Address */ unsigned int src_port; /* TCP/UDP source port number or equivalent */ unsigned int dst_port; /* TCP/UDP destination port number or equivalent */ unsigned int tcp_flags; /* TCP flags */ unsigned int tos; /* IP type of service */ } /* Packet IP version 6 data */ struct sampled_ipv6 { unsigned int length; /* The length of the IP packet excluding lower layer encapsulations */ unsigned int protocol; /* IP next header (for example, TCP = 6, UDP = 17) */ ip_v6 src_ip; /* Source IP Address */ ip_v6 dst_ip; /* Destination IP Address */ unsigned int src_port; /* TCP/UDP source port number or equivalent */ unsigned int dst_port; /* TCP/UDP destination port number or equivalent */ unsigned int tcp_flags; /* TCP flags */ unsigned int priority; /* IP priority */ } /* Packet data */ enum packet_information_type { HEADER = 1, /* Packet headers are sampled */ IPV4 = 2, /* IP version 4 data */ IPV6 = 3 /* IP version 6 data */ } union packet_data_type (packet_information_type type) { case HEADER: sampled_header header; case IPV4: sampled_ipv4 ipv4; case IPV6: sampled_ipv6 ipv6; } Phaal, et al. Informational [Page 17] RFC 3176 InMon Corporation's sFlow September 2001 /* Extended data types */ /* Extended switch data */ struct extended_switch { unsigned int src_vlan; /* The 802.1Q VLAN id of incoming frame */ unsigned int src_priority; /* The 802.1p priority of incoming frame */ unsigned int dst_vlan; /* The 802.1Q VLAN id of outgoing frame */ unsigned int dst_priority; /* The 802.1p priority of outgoing frame */ } /* Extended router data */ struct extended_router { address nexthop; /* IP address of next hop router */ unsigned int src_mask; /* Source address prefix mask bits */ unsigned int dst_mask; /* Destination address prefix mask bits */ } /* Extended gateway data */ enum as_path_segment_type { AS_SET = 1, /* Unordered set of ASs */ AS_SEQUENCE = 2 /* Ordered set of ASs */ } union as_path_type (as_path_segment_type) { case AS_SET: unsigned int as_set<>; case AS_SEQUENCE: unsigned int as_sequence<>; } struct extended_gateway { unsigned int as; /* Autonomous system number of router */ unsigned int src_as; /* Autonomous system number of source */ unsigned int src_peer_as; /* Autonomous system number of source peer */ as_path_type dst_as_path<>; /* Autonomous system path to the destination */ unsigned int communities<>; /* Communities associated with this route */ unsigned int localpref; /* LocalPref associated with this route */ } Phaal, et al. Informational [Page 18] RFC 3176 InMon Corporation's sFlow September 2001 /* Extended user data */ struct extended_user { string src_user<>; /* User ID associated with packet source */ string dst_user<>; /* User ID associated with packet destination */ } /* Extended URL data */ enum url_direction { src = 1, /* URL is associated with source address */ dst = 2 /* URL is associated with destination address */ } struct extended_url { url_direction direction; /* URL associated with packet source */ string url<>; /* URL associated with the packet flow */ } /* Extended data */ enum extended_information_type { SWITCH = 1, /* Extended switch information */ ROUTER = 2, /* Extended router information */ GATEWAY = 3, /* Extended gateway router information */ USER = 4, /* Extended TACACS/RADIUS user information */ URL = 5 /* Extended URL information */ } union extended_data_type (extended_information_type type) { case SWITCH: extended_switch switch; case ROUTER: extended_router router; case GATEWAY: extended_gateway gateway; case USER: extended_user user; case URL: extended_url url; } /* Format of a single flow sample */ Phaal, et al. Informational [Page 19] RFC 3176 InMon Corporation's sFlow September 2001 struct flow_sample { unsigned int sequence_number; /* Incremented with each flow sample generated by this source_id */ unsigned int source_id; /* sFlowDataSource encoded as follows: The most significant byte of the source_id is used to indicate the type of sFlowDataSource (0 = ifIndex, 1 = smonVlanDataSource, 2 = entPhysicalEntry) and the lower three bytes contain the relevant index value.*/ unsigned int sampling_rate; /* sFlowPacketSamplingRate */ unsigned int sample_pool; /* Total number of packets that could have been sampled (i.e., packets skipped by sampling process + total number of samples) */ unsigned int drops; /* Number times a packet was dropped due to lack of resources */ unsigned int input; /* SNMP ifIndex of input interface. 0 if interface is not known. */ unsigned int output; /* SNMP ifIndex of output interface, 0 if interface is not known. Set most significant bit to indicate multiple destination interfaces (i.e., in case of broadcast or multicast) and set lower order bits to indicate number of destination interfaces. Examples: 0x00000002 indicates ifIndex = 2 0x00000000 ifIndex unknown. 0x80000007 indicates a packet sent to 7 interfaces. 0x80000000 indicates a packet sent to an unknown number of interfaces greater than 1. */ packet_data_type packet_data; /* Information about sampled packet */ extended_data_type extended_data<>; /* Extended flow information */ } Phaal, et al. Informational [Page 20] RFC 3176 InMon Corporation's sFlow September 2001 /* Counter types */ /* Generic interface counters - see RFC 2233 */ struct if_counters { unsigned int ifIndex; unsigned int ifType; unsigned hyper ifSpeed; unsigned int ifDirection; /* derived from MAU MIB (RFC 2668) 0 = unknown, 1=full-duplex, 2=half-duplex, 3 = in, 4=out */ unsigned int ifStatus; /* bit field with the following bits assigned bit 0 = ifAdminStatus (0 = down, 1 = up) bit 1 = ifOperStatus (0 = down, 1 = up) */ unsigned hyper ifInOctets; unsigned int ifInUcastPkts; unsigned int ifInMulticastPkts; unsigned int ifInBroadcastPkts; unsigned int ifInDiscards; unsigned int ifInErrors; unsigned int ifInUnknownProtos; unsigned hyper ifOutOctets; unsigned int ifOutUcastPkts; unsigned int ifOutMulticastPkts; unsigned int ifOutBroadcastPkts; unsigned int ifOutDiscards; unsigned int ifOutErrors; unsigned int ifPromiscuousMode; } /* Ethernet interface counters - see RFC 2358 */ struct ethernet_counters { if_counters generic; unsigned int dot3StatsAlignmentErrors; unsigned int dot3StatsFCSErrors; unsigned int dot3StatsSingleCollisionFrames; unsigned int dot3StatsMultipleCollisionFrames; unsigned int dot3StatsSQETestErrors; unsigned int dot3StatsDeferredTransmissions; unsigned int dot3StatsLateCollisions; unsigned int dot3StatsExcessiveCollisions; unsigned int dot3StatsInternalMacTransmitErrors; unsigned int dot3StatsCarrierSenseErrors; unsigned int dot3StatsFrameTooLongs; Phaal, et al. Informational [Page 21] RFC 3176 InMon Corporation's sFlow September 2001 unsigned int dot3StatsInternalMacReceiveErrors; unsigned int dot3StatsSymbolErrors; } /* FDDI interface counters - see RFC 1512 */ struct fddi_counters { if_counters generic; } /* Token ring counters - see RFC 1748 */ struct tokenring_counters { if_counters generic; unsigned int dot5StatsLineErrors; unsigned int dot5StatsBurstErrors; unsigned int dot5StatsACErrors; unsigned int dot5StatsAbortTransErrors; unsigned int dot5StatsInternalErrors; unsigned int dot5StatsLostFrameErrors; unsigned int dot5StatsReceiveCongestions; unsigned int dot5StatsFrameCopiedErrors; unsigned int dot5StatsTokenErrors; unsigned int dot5StatsSoftErrors; unsigned int dot5StatsHardErrors; unsigned int dot5StatsSignalLoss; unsigned int dot5StatsTransmitBeacons; unsigned int dot5StatsRecoverys; unsigned int dot5StatsLobeWires; unsigned int dot5StatsRemoves; unsigned int dot5StatsSingles; unsigned int dot5StatsFreqErrors; } /* 100 BaseVG interface counters - see RFC 2020 */ struct vg_counters { if_counters generic; unsigned int dot12InHighPriorityFrames; unsigned hyper dot12InHighPriorityOctets; unsigned int dot12InNormPriorityFrames; unsigned hyper dot12InNormPriorityOctets; unsigned int dot12InIPMErrors; unsigned int dot12InOversizeFrameErrors; unsigned int dot12InDataErrors; unsigned int dot12InNullAddressedFrames; unsigned int dot12OutHighPriorityFrames; unsigned hyper dot12OutHighPriorityOctets; unsigned int dot12TransitionIntoTrainings; Phaal, et al. Informational [Page 22] RFC 3176 InMon Corporation's sFlow September 2001 unsigned hyper dot12HCInHighPriorityOctets; unsigned hyper dot12HCInNormPriorityOctets; unsigned hyper dot12HCOutHighPriorityOctets; } /* WAN counters */ struct wan_counters { if_counters generic; } /* VLAN counters */ struct vlan_counters { unsigned int vlan_id; unsigned hyper octets; unsigned int ucastPkts; unsigned int multicastPkts; unsigned int broadcastPkts; unsigned int discards; } /* Counter data */ enum counters_version { GENERIC = 1, ETHERNET = 2, TOKENRING = 3, FDDI = 4, VG = 5, WAN = 6, VLAN = 7 } union counters_type (counters_version version) { case GENERIC: if_counters generic; case ETHERNET: ethernet_counters ethernet; case TOKENRING: tokenring_counters tokenring; case FDDI: fddi_counters fddi; case VG: vg_counters vg; case WAN: wan_counters wan; case VLAN: Phaal, et al. Informational [Page 23] RFC 3176 InMon Corporation's sFlow September 2001 vlan_counters vlan; } /* Format of a single counter sample */ struct counters_sample { unsigned int sequence_number; /* Incremented with each counter sample generated by this source_id */ unsigned int source_id; /* sFlowDataSource encoded as follows: The most significant byte of the source_id is used to indicate the type of sFlowDataSource (0 = ifIndex, 1 = smonVlanDataSource, 2 = entPhysicalEntry) and the lower three bytes contain the relevant index value.*/ unsigned int sampling_interval; /* sFlowCounterSamplingInterval*/ counters_type counters; } /* Format of a sample datagram */ enum sample_types { FLOWSAMPLE = 1, COUNTERSSAMPLE = 2 } union sample_type (sample_types sampletype) { case FLOWSAMPLE: flow_sample flowsample; case COUNTERSSAMPLE: counters_sample counterssample; } struct sample_datagram_v4 { address agent_address /* IP address of sampling agent, sFlowAgentAddress. */ unsigned int sequence_number; /* Incremented with each sample datagram generated */ unsigned int uptime; /* Current time (in milliseconds since device last booted). Should be set as close to datagram transmission time as possible.*/ Phaal, et al. Informational [Page 24] RFC 3176 InMon Corporation's sFlow September 2001 sample_type samples<>; /* An array of flow, counter and delay samples */ } enum datagram_version { VERSION4 = 4 } union sample_datagram_type (datagram_version version) { case VERSION4: sample_datagram_v4 datagram; } struct sample_datagram { sample_datagram_type version; } The sFlow Datagram specification makes use of definitions from a number of existing RFCs [22], [23], [24], [25], [26], [27] and [28]. 5. Security Considerations Deploying a traffic monitoring system raises a number of security related issues. sFlow does not provide specific security mechanisms, relying instead on proper deployment and configuration to maintain an adequate level of security. While the deployment of traffic monitoring systems does create some risk, it also provides a powerful means of detecting and tracing unauthorized network activity. This section is intended to provide information that will help understand potential risks and configuration options for mitigating those risks. 5.1 Control The sFlow MIB is used to configure the generation of sFlow samples. The security of SNMP, with access control lists, is usually considered adequate in an enterprise setting. However, there are situations when these security measures are insufficient (for example a WAN router) and SNMP configuration control will be disabled. When SNMP is disabled, a command line interface is typically provided. The following arguments are required to configure sFlow sampling on an interface. Phaal, et al. Informational [Page 25] RFC 3176 InMon Corporation's sFlow September 2001 -sFlowDataSource -sFlowPacketSamplingRate -sFlowCounterSamplingInterval -sFlowMaximumHeaderSize
-sFlowMaximumDatagramSize -sFlowCollectorAddress
-sFlowCollectorPort 5.2 Transport Traffic information is sent unencrypted across the network from the sFlow Agent to the sFlow Analyzer and is thus vulnerable to eavesdropping. This risk can be limited by creating a secure measurement network and routing the sFlow Datagrams over this network. The choice of technology for creating the secure measurement network is deployment specific, but could include the use of VLANs or VPN tunnels. The sFlow Analyzer is vulnerable to attacks involving spoofed sFlow Datagrams. To limit this vulnerability the sFlow Analyzer should check sequence numbers and verify source addresses. If a secure measurement network has been constructed then only sFlow Datagrams received from that network should be processed. 5.3 Confidentiality Traffic information can reveal confidential information about individual network users. The degree of visibility of application level data can be controlled by limiting the number of header bytes captured by the sFlow agent. In addition, packet sampling makes it virtually impossible to capture sequences of packets from an individual transaction. The traffic patterns discernible by decoding the sFlow Datagrams in the sFlow Analyzer can reveal details of an individual's network related activities and due care should be taken to secure access to the sFlow Analyzer. 6. References [1] Sun Microsystems, Inc., "XDR: External Data Representation Standard", RFC 1014, June 1987. [2] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. Phaal, et al. Informational [Page 26] RFC 3176 InMon Corporation's sFlow September 2001 [3] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [5] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [11] 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. [12] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [14] 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. [15] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. Phaal, et al. Informational [Page 27] RFC 3176 InMon Corporation's sFlow September 2001 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [18] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 2819, May 2000. [19] Waterman, R., Lahaye, B., Romascanu, D. and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999. [20] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. [21] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999. [22] Smith, A., Flick, J., de Graaf, K., Romanscanu, D., McMaster, D., McCloghrie, K. and S. Roberts, "Definition of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 2668, August 1999. [23] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [24] Flick, J. and J. Johnson, "Definition of Managed Objects for the Ethernet-like Interface Types", RFC 2358, June 1998. [25] Case, J., "FDDI Management Information Base", RFC 1512, September 1993. [26] McCloghrie, K. and E. Decker, "IEEE 802.5 MIB using SMIv2", RFC 1748, December 1994. [27] Flick, J., "Definitions of Managed Objects for IEEE 802.12 Interfaces", RFC 2020, October 1996. [28] Willis, S., Burruss, J. and J. Chu, "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. Phaal, et al. Informational [Page 28] RFC 3176 InMon Corporation's sFlow September 2001 7. Authors' Addresses Peter Phaal InMon Corporation 1404 Irving Street San Francisco, CA 94122 Phone: (415) 661-6343 EMail: peter_phaal@INMON.COM Sonia Panchen InMon Corporation 1404 Irving Street San Francisco, CA 94122 Phone: (415) 661-6343 EMail: sonia_panchen@INMON.COM Neil McKee InMon Corporation 1404 Irving Street San Francisco, CA 94122 Phone: (415) 661-6343 EMail: neil_mckee@INMON.COM Phaal, et al. Informational [Page 29] RFC 3176 InMon Corporation's sFlow September 2001 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Phaal, et al. Informational [Page 30] RFC 3176 InMon Corporation's sFlow September 2001 9. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Phaal, et al. Informational [Page 31] snmp-mibs-downloader-1.1/mibrfcs/rfc3201.txt0000644000000000000000000013101711402176071015552 0ustar Network Working Group R. Steinberger Request for Comments: 3201 Paradyne Networks Category: Standards Track O. Nicklass RAD Data Communications Ltd. January 2002 Definitions of Managed Objects for Circuit to Interface Translation 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. Table of Contents 1. The SNMP Management Framework ............................... 2 2. Conventions ................................................. 3 3. Overview .................................................... 3 3.1. Circuit Concepts .......................................... 4 3.2. Theory of Operation ....................................... 4 3.2.1. Creation Process ........................................ 4 3.2.2. Destruction Process ..................................... 5 3.2.2.1. Manual Row Destruction ................................ 5 3.2.2.2. Automatic Row Destruction ............................. 5 3.2.3. Modification Process .................................... 5 3.2.4. Persistence of Data ..................................... 5 4. Relation to Other MIB Modules ............................... 6 4.1. Frame Relay DTE MIB ....................................... 6 Steinberger & Nicklass Standards Track [Page 1] RFC 3201 Circuit to Interface MIB January 2002 4.2. Frame Relay Service MIB ................................... 6 4.3. ATM MIB ................................................... 6 4.4. Interfaces Group MIB ...................................... 6 4.4.1. Interfaces Table (ifTable, ifXtable) .................... 6 4.4.2. Stack Table (ifStackTable) .............................. 9 4.5. Other MIB Modules ......................................... 11 5. Structure of the MIB Module ................................. 11 5.1. ciCircuitTable ............................................ 11 5.2. ciIfMapTable .............................................. 11 6. Object Definitions .......................................... 11 7. Acknowledgments ............................................. 19 8. References .................................................. 19 9. Security Considerations ..................................... 21 10. IANA Considerations ........................................ 21 11. Authors' Addresses ......................................... 22 12. Full Copyright Statement ................................... 23 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. Steinberger & Nicklass Standards Track [Page 2] RFC 3201 Circuit to Interface MIB January 2002 o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [21]. 3. Overview This MIB module addresses the concept of inserting circuits, which are potentially virtual, into the ifTable. There are multiple reasons to allow circuits to be added to the ifTable. The most prevalent of which are the standard routing MIB tables such as the ipCidrRouteTable (IP-FORWARD-MIB) and the ipNetToMediaTable (IP-MIB) act on the ifIndex and the RMON MIBs (RMON-MIB and RMON2-MIB as defined in RFC 2819 [23] and RFC 2021 [19]) require the use of an ifIndex a DataSource. There is a further need to potentially monitor or manage a circuit based on the directional flow of traffic going through it. For instance, monitoring of protocols passed on a circuit using RMON-II (RFC 2021 [19]) does not currently capture the direction of the flow. This MIB module provides the capability to define an interface based on the specific direction of the flow. This section provides an overview and background of how to use this MIB module. Steinberger & Nicklass Standards Track [Page 3] RFC 3201 Circuit to Interface MIB January 2002 3.1. Circuit Concepts There are multiple MIB modules that define circuits. Three commonly used MIB modules are FRAME-RELAY-DTE-MIB (RFC 2115) [20], FRNETSERV- MIB (RFC 2954) [18], and ATM-MIB (RFC 2515) [22]. These define management objects for frame relay DTEs, frame relay services, and ATM respectively. Each of these MIB modules contain the ability to add or delete circuits; however, none create a specific ifEntry for a circuit. The reason for this is that there are potentially multiple circuits and not every circuit needs to be managed as an individual interface. For example, not every circuit on a device needs to be monitored with RMON and not every circuit needs to be included as an individual circuit for routing. Further, the Interfaces Group MIB (RFC 2863) [17] strongly recommends that conceptual rows not be added to the ifTable for virtual circuits. The rationale for creating conceptual rows in the ifTable for these circuits is that there is a need for their use in either management of routing or monitoring of data. Both of these functions require mapping to an ifIndex. This MIB module is designed such that only those circuits that require an ifIndex need be added to the ifTable. This prevents over-populating the ifTable with useless or otherwise unused indices. While this document often refers to ATM and frame relay, it is not specifically designed for only those types of circuits. Any circuit that is defined in a MIB module but does not have its own ifIndex MAY be added with this MIB module. 3.2. Theory of Operation 3.2.1. Creation Process In some cases, devices will automatically populate the rows of ciCircuitTable as circuits are created or discovered. However, in many cases, it may be necessary for a network manager to manually create rows. Manual creation of rows requires the following steps: 1) Locate or create the circuit that is to be added on the device. 2) Create a row in ciCircuitTable for each flow type that is required. The first step above requires some knowledge of the circuits that exist on a device. Typically, logical ports have entries in the Steinberger & Nicklass Standards Track [Page 4] RFC 3201 Circuit to Interface MIB January 2002 ifTable. If, for example, the ifType for the logical port is frameRelay(32), the circuits can be located in the frCircuitTable of the Frame Relay DTE MIB (FRAME-RELAY-DTE-MIB) [18]. If, as another example, the ifType for the logical port is frameRelayService(44), the circuits can be located in the frPVCEndptTable of the Frame Relay Service MIB (FRNETSERV-MIB) [20]. If, as a final example, the ifType for the logical port is aal5(49), the circuits can be located in the aal5VccTable of the ATM MIB (ATM-MIB) [22]. An entry describing the circuit MUST exist in some table prior to creating a row in ciCircuitTable. The object identifier that MUST be used in the circuit definition is the lexicographically smallest accessible OID that fully describes the the circuit. 3.2.2. Destruction Process 3.2.2.1. Manual Row Destruction Manual row destruction is straight forward. Any row can be destroyed and the resources allocated to it are freed by setting the value of its status object (ciCircuitStatus) to destroy(6). It should be noted that when ciCircuitStatus is set to destroy(6) all associated rows in the ifTable and in ciIfMapTable will also be destroyed. This process MAY trigger further row destruction in other tables as well. 3.2.2.2. Automatic Row Destruction Rows in the tables MAY be destroyed automatically based on the existence of the circuit on which they rely. When a circuit no longer exists in the device, the data in the tables has no relation to anything known on the network. For this reason, rows MUST be removed from this table as soon as it is discovered that the associated circuits no longer exist. The effects of automatic row destruction are the same as manual row destruction. 3.2.3. Modification Process Since no objects in the MIB module can be changed once rows are active, there are no modification caveats. 3.2.4. Persistence of Data Each row in the tables of this MIB module relies on information from other MIB modules. The rules for persistence of the data SHOULD follow the same rules as those of the underlying MIB module. For example, if the circuit defined by ciCircuitObject would normally be stored in non-volatile memory, then the ciCircuitEntry SHOULD also be non-volatile. Steinberger & Nicklass Standards Track [Page 5] RFC 3201 Circuit to Interface MIB January 2002 4. Relation to Other MIB Modules 4.1. Frame Relay DTE MIB There is no required relation to the Frame Relay DTE MIB beyond the fact that rows in the frCircuitTable MAY be referenced. However, if frCircuitLogicalIfIndex is being used to represent the same information as a ciCircuitEntry with a value of ciCircuitFlow equal to both(3), the implementation MAY use the same ifIndex. 4.2. Frame Relay Service MIB There is no explicit relation to the Frame Relay Service MIB beyond the fact that a rows in the frPVCEndptTable MAY be referenced. 4.3. ATM MIB There is no explicit relation to the ATM MIB beyond the fact that rows in multiple tables may be referenced. 4.4. Interfaces Group MIB 4.4.1. Interfaces Table (ifTable, ifXtable) The following specifies how the Interfaces Group defined in the IF- MIB will be used for the management of interfaces created by this MIB module. Values of specific ifTable objects for circuit interfaces are as follows: Object Name Value of Object =========== ===================================================== ifIndex Each entry in the circuit table is represented by an ifEntry. The value of ifIndex is defined by the agent such that it complies with any internal numbering scheme. ifType The value of ifType is specific to the type of circuit desired. For example, the value for frame relay virtual circuits is frDlciEndPt(193) and the value for ATM virtual circuits is atmVciEndPt(194). If the circuit is to be used in RMON, propVirtual(53) SHOULD NOT be used. Steinberger & Nicklass Standards Track [Page 6] RFC 3201 Circuit to Interface MIB January 2002 ifMtu Set to the size in octets of the largest packet, frame or PDU supported on the circuit. If this is not known to the ifMtu object shall be set to zero. If the circuit is not modeled as a packet-oriented interface, this object SHOULD NOT be supported and result in noSuchInstance. ifSpeed The peak bandwidth in bits per second available for use. This will equal either the ifSpeed of the logical link if policing is not enforced or the maximum information rate otherwise. If neither is known, the ifSpeed object shall be set to zero. ifPhysAddress This will always be an octet string of zero length. ifInOctets The number of octets received by the network (ingress) for this circuit. This counter should count only octets included the header information and user data. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifInUcastPkts The unerrored number of frames, packets or PDUs received by the network (ingress) for this circuit. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifInDiscards The number of received frames, packets or PDUs for this circuit discarded due to ingress buffer congestion and traffic policing. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifInErrors The number of received frames, packets or PDUs for this circuit that are discarded because of an error. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifOutOctets The number of octets sent by the network (egress) for this circuit. This counter should count only octets included the header information and user data. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. Steinberger & Nicklass Standards Track [Page 7] RFC 3201 Circuit to Interface MIB January 2002 ifOutUcastpkts The number of unerrored frames, packets or PDUs sent by the network (egress) for this circuit. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifOutDiscards The number of frames, packets or PDUs discarded in the egress direction for this circuit. Possible reasons are as follows: policing, congestion. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifOutErrors The number of frames, packets or PDUs discarded for this circuit in the egress direction because of an error. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifInBroadcastPkts If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance. ifOutBroadcastPkts If the device does not support Broadcast packets on the circuit, this object should not be supported and result in noSuchInstance. ifLinkUpDownTrapEnable Set to false(2). Circuits often have a predefined notification mechanism. In such instances, the number of notification sent would be doubled if this were enabled. ifPromiscuousMode Set to false(2). If the circuit is not modeled as a packet-oriented interface, this object SHOULD NOT be supported and result in noSuchInstance. ifConnectorPresent Set to false(2). All other values are supported as stated in the IF-MIB documentation. Steinberger & Nicklass Standards Track [Page 8] RFC 3201 Circuit to Interface MIB January 2002 4.4.2. Stack Table (ifStackTable) This section describes by example how to use ifStackTable to represent the relationship between circuit and logical link interfaces. Example 1: Circuits (C) on a frame relay logical link. +---+ +---+ +---+ | C | | C | | C | +-+-+ +-+-+ +-+-+ | | | +---+------+------+---+ | Frame Relay Service | +----------+----------+ | +----------+----------+ | Physical Layer | +---------------------+ The assignment of the index values could for example be (for a V35 physical interface): ifIndex Description ======= =========== 1 frDlciEndPt (type 193) 2 frDlciEndPt (type 193) 3 frDlciEndPt (type 193) 4 frameRelayService (type 44) 5 v35 (type 33) The ifStackTable is then used to show the relationships between each interface. HigherLayer LowerLayer =========== ========== 0 1 0 2 0 3 1 4 2 4 3 4 4 5 5 0 In the above example the frame relay logical link could just as easily be of type frameRelay(32) instead. Steinberger & Nicklass Standards Track [Page 9] RFC 3201 Circuit to Interface MIB January 2002 Example 2: Circuits (C) on a AAL5 logical link. +---+ +---+ +---+ | C | | C | | C | +-+-+ +-+-+ +-+-+ | | | +---+------+------+---+ | AAL5 Layer | +----------+----------+ | +----------+----------+ | ATM Layer | +---------------------+ | +----------+----------+ | Physical Layer | +---------------------+ The assignment of the index values could for example be (for a DS3 physical interface): ifIndex Description ======= =========== 1 atmVciEndPt (type 194) 2 atmVciEndPt (type 194) 3 atmVciEndPt (type 194) 4 aal5 (type 49) 5 atm (type 37) 6 ds3 (type 30) The ifStackTable is then used to show the relationships between each interface. HigherLayer LowerLayer =========== ========== 0 1 0 2 0 3 1 4 2 4 3 4 4 5 5 6 6 0 Steinberger & Nicklass Standards Track [Page 10] RFC 3201 Circuit to Interface MIB January 2002 4.5. Other MIB Modules There is no explicit relation to any other media specific MIB module beyond the fact that rows in multiple tables may be referenced. 5. Structure of the MIB Module The CIRCUIT-IF-MIB consists of the following components: o ciCircuitTable o ciIfMapTable Refer to the compliance statement defined within for a definition of what objects MUST be implemented. 5.1. ciCircuitTable The ciCircuitTable is the central control table for operations of the Circuit Interfaces MIB. It provides a means of mapping a circuit to its ifIndex as well as forcing the insertion of an ifIndex into the ifTable. The agent is responsible for managing the ifIndex itself such that no device dependent indexing scheme is violated. A row in this table MUST exist in order for a row to exist in any other table in this MIB module. 5.2. ciIfMapTable This table maps the ifIndex back to the circuit that it is associated with. 6. Object Definitions CIRCUIT-IF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Gauge32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, RowPointer, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB; circuitIfMIB MODULE-IDENTITY LAST-UPDATED "200201030000Z" -- January 3, 2002 ORGANIZATION "IETF Frame Relay Service MIB Working Group" CONTACT-INFO Steinberger & Nicklass Standards Track [Page 11] RFC 3201 Circuit to Interface MIB January 2002 "IETF Frame Relay Service MIB (frnetmib) Working Group WG Charter: http://www.ietf.org/html.charters/ frnetmib-charter.html WG-email: frnetmib@sunroof.eng.sun.com Subscribe: frnetmib-request@sunroof.eng.sun.com Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib Chair: Andy Malis Vivace Networks Email: Andy.Malis@vivacenetworks.com WG editor: Robert Steinberger Paradyne Networks and Fujitsu Network Communications Email: robert.steinberger@fnc.fujitsu.com Co-author: Orly Nicklass RAD Data Communications Ltd. EMail: Orly_n@rad.co.il" DESCRIPTION "The MIB module to allow insertion of selected circuit into the ifTable." REVISION "200201030000Z" -- January 3, 2002 DESCRIPTION "Initial version, published as RFC 3201" ::= { mib-2 94 } -- Textual Conventions CiFlowDirection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The direction of data flow thru a circuit. transmit(1) - Only transmitted data receive(2) - Only received data both(3) - Both transmitted and received data." SYNTAX INTEGER { transmit(1), receive(2), both(3) } ciObjects OBJECT IDENTIFIER ::= { circuitIfMIB 1 } ciCapabilities OBJECT IDENTIFIER ::= { circuitIfMIB 2 } ciConformance OBJECT IDENTIFIER ::= { circuitIfMIB 3 } Steinberger & Nicklass Standards Track [Page 12] RFC 3201 Circuit to Interface MIB January 2002 -- The Circuit Interface Circuit Table -- -- This table is used to define and display the circuits that -- are added to the ifTable. It maps circuits to their respective -- ifIndex values. ciCircuitTable OBJECT-TYPE SYNTAX SEQUENCE OF CiCircuitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Circuit Interface Circuit Table." ::= { ciObjects 1 } ciCircuitEntry OBJECT-TYPE SYNTAX CiCircuitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Circuit Interface Circuit Table." INDEX { ciCircuitObject, ciCircuitFlow } ::= { ciCircuitTable 1 } CiCircuitEntry ::= SEQUENCE { -- -- Index Control Variables -- ciCircuitObject RowPointer, ciCircuitFlow CiFlowDirection, ciCircuitStatus RowStatus, -- -- Data variables -- ciCircuitIfIndex InterfaceIndex, ciCircuitCreateTime TimeStamp, -- -- Data Persistence -- ciCircuitStorageType StorageType } ciCircuitObject OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value contains the RowPointer that uniquely Steinberger & Nicklass Standards Track [Page 13] RFC 3201 Circuit to Interface MIB January 2002 describes the circuit that is to be added to this table. Any RowPointer that will force the size of OBJECT IDENTIFIER of the row to grow beyond the legal limit MUST be rejected. The purpose of this object is to point a network manager to the table in which the circuit was created as well as define the circuit on which the interface is defined. Valid tables for this object include the frCircuitTable from the Frame Relay DTE MIB(FRAME-RELAY-DTE-MIB), the frPVCEndptTable from the Frame Relay Service MIB (FRNETSERV-MIB), and the aal5VccTable from the ATM MIB (ATM MIB). However, including circuits from other MIB tables IS NOT prohibited." ::= { ciCircuitEntry 1 } ciCircuitFlow OBJECT-TYPE SYNTAX CiFlowDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "The direction of data flow through the circuit for which the virtual interface is defined. The following define the information that the virtual interface will report. transmit(1) - Only transmitted frames receive(2) - Only received frames both(3) - Both transmitted and received frames. It is recommended that the ifDescr of the circuit interfaces that are not both(3) SHOULD have text warning the operators that the particular interface represents only half the traffic on the circuit." ::= { ciCircuitEntry 2 } ciCircuitStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the current row. This object is used to add, delete, and disable rows in this table. When the status changes to active(1), a row will also be added to the interface map table below and a row will be added to the ifTable. These rows SHOULD not be removed until the status is changed from active(1). The value of ifIndex for the row that Steinberger & Nicklass Standards Track [Page 14] RFC 3201 Circuit to Interface MIB January 2002 is added to the ifTable is determined by the agent and MUST follow the rules of the ifTable. The value of ifType for that interface will be frDlciEndPt(193) for a frame relay circuit, atmVciEndPt(194) for an ATM circuit, or another ifType defining the circuit type for any other circuit. When this object is set to destroy(6), the associated row in the interface map table will be removed and the ifIndex will be removed from the ifTable. Removing the ifIndex MAY initiate a chain of events that causes changes to other tables as well. The rows added to this table MUST have a valid object identifier for ciCircuitObject. This means that the referenced object must exist and it must be in a table that supports circuits. The object referenced by ciCircuitObject MUST exist prior to transitioning a row to active(1). If at any point the object referenced by ciCircuitObject does not exist or the row containing it is not in the active(1) state, the status SHOULD either age out the row or report notReady(3). The effects transitioning from active(1) to notReady(3) are the same as those caused by setting the status to destroy(6). Each row in this table relies on information from other MIB modules. The rules persistence of data SHOULD follow the same rules as those of the underlying MIB module. For example, if the circuit defined by ciCircuitObject would normally be stored in non-volatile memory, then the row SHOULD also be non-volatile." ::= { ciCircuitEntry 3 } ciCircuitIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex that the agent assigns to this row." ::= { ciCircuitEntry 4 } ciCircuitCreateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Steinberger & Nicklass Standards Track [Page 15] RFC 3201 Circuit to Interface MIB January 2002 "This object returns the value of sysUpTime at the time the value of ciCircuitStatus last transitioned to active(1). If ciCircuitStatus has never been active(1), this object SHOULD return 0." ::= { ciCircuitEntry 5 } ciCircuitStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type used for this row." ::= { ciCircuitEntry 6 } -- The Circuit Interface Map Table -- -- This table maps the ifIndex values that are assigned to -- rows in the circuit table back to the objects that define -- the circuits. ciIfMapTable OBJECT-TYPE SYNTAX SEQUENCE OF CiIfMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Circuit Interface Map Table." ::= { ciObjects 2 } ciIfMapEntry OBJECT-TYPE SYNTAX CiIfMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Circuit Interface Map Table." INDEX { ifIndex } ::= { ciIfMapTable 1 } CiIfMapEntry ::= SEQUENCE { -- -- Mapped Object Variables -- ciIfMapObject RowPointer, ciIfMapFlow CiFlowDirection } ciIfMapObject OBJECT-TYPE SYNTAX RowPointer Steinberger & Nicklass Standards Track [Page 16] RFC 3201 Circuit to Interface MIB January 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "This value contains the value of RowPointer that corresponds to the current ifIndex." ::= { ciIfMapEntry 1 } ciIfMapFlow OBJECT-TYPE SYNTAX CiFlowDirection MAX-ACCESS read-only STATUS current DESCRIPTION "The value contains the value of ciCircuitFlow that corresponds to the current ifIndex." ::= { ciIfMapEntry 2 } -- Change tracking metrics ciIfLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent change to ciCircuitStatus for any row in ciCircuitTable." ::= { ciObjects 3 } ciIfNumActive OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active rows in ciCircuitTable." ::= { ciObjects 4 } -- Conformance Information ciMIBGroups OBJECT IDENTIFIER ::= { ciConformance 1 } ciMIBCompliances OBJECT IDENTIFIER ::= { ciConformance 2 } -- -- Compliance Statements -- ciCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities Steinberger & Nicklass Standards Track [Page 17] RFC 3201 Circuit to Interface MIB January 2002 which support of the Circuit Interfaces MIB module. This group defines the minimum level of support required for compliance." MODULE -- this module MANDATORY-GROUPS { ciCircuitGroup, ciIfMapGroup, ciStatsGroup } OBJECT ciCircuitStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Row creation can be done outside of the scope of the SNMP protocol. If this object is implemented with max-access of read-only, then the only value that MUST be returned is active(1)." OBJECT ciCircuitStorageType MIN-ACCESS read-only DESCRIPTION "It is legal to support ciCircuitStorageType as read- only as long as the value reported in consistent with the actual storage mechanism employed within the agent." ::= { ciMIBCompliances 1 } -- -- Units of Conformance -- ciCircuitGroup OBJECT-GROUP OBJECTS { ciCircuitStatus, ciCircuitIfIndex, ciCircuitCreateTime, ciCircuitStorageType } STATUS current DESCRIPTION "A collection of required objects providing information from the circuit table." ::= { ciMIBGroups 1 } ciIfMapGroup OBJECT-GROUP OBJECTS { ciIfMapObject, ciIfMapFlow } Steinberger & Nicklass Standards Track [Page 18] RFC 3201 Circuit to Interface MIB January 2002 STATUS current DESCRIPTION "A collection of required objects providing information from the interface map table." ::= { ciMIBGroups 2 } ciStatsGroup OBJECT-GROUP OBJECTS { ciIfLastChange, ciIfNumActive } STATUS current DESCRIPTION "A collection of statistical metrics used to help manage the ciCircuitTable." ::= { ciMIBGroups 3 } END 7. Acknowledgments This document was produced by the Frame Relay Service MIB Working Group. 8. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Steinberger & Nicklass Standards Track [Page 19] RFC 3201 Circuit to Interface MIB January 2002 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [18] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for Frame Relay Service", RFC 2954, October 2000. [19] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. Steinberger & Nicklass Standards Track [Page 20] RFC 3201 Circuit to Interface MIB January 2002 [20] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [21] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [22] Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. [23] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 2819, May 2000. 9. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations New ifTypes defined specifically for use in this MIB module SHOULD be in the form of ***EndPt. This is similar to frDlciEndPt(193) and atmVciEndPt(194) which are already defined. Steinberger & Nicklass Standards Track [Page 21] RFC 3201 Circuit to Interface MIB January 2002 11. Authors' Addresses Robert Steinberger Fujitsu Network Communications 2801 Telecom Parkway Richardson, TX 75082 Phone: 1-972-479-4739 EMail: robert.steinberger@fnc.fujitsu.com Orly Nicklass, Ph.D RAD Data Communications Ltd. 12 Hanechoshet Street Tel Aviv, Israel 69710 Phone: 972 3 7659969 EMail: Orly_n@rad.co.il Steinberger & Nicklass Standards Track [Page 22] RFC 3201 Circuit to Interface MIB January 2002 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Steinberger & Nicklass Standards Track [Page 23] snmp-mibs-downloader-1.1/mibrfcs/rfc3202.txt0000644000000000000000000037740011402176071015563 0ustar Network Working Group R. Steinberger Request for Comments: 3202 Paradyne Networks Category: Standards Track O. Nicklass RAD Data Communications Ltd. January 2002 Definitions of Managed Objects for Frame Relay Service Level Definitions 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. Table of Contents 1. The SNMP Management Framework ............................... 2 2. Conventions ................................................. 3 3. Overview .................................................... 3 3.1. Frame Relay Service Level Definitions ..................... 4 3.2. Terminology ............................................... 5 3.3. Network Model ............................................. 5 3.4. Reference Points .......................................... 6 3.5. Measurement Methodology ................................... 8 3.6. Theory of Operation ....................................... 9 3.6.1. Capabilities Discovery .................................. 9 3.6.2. Determining Reference Points for Row Creation ........... 10 3.6.2.1. Graphical Examples of Reference Points ................ 11 3.6.2.1.1. Edge-to-Edge Interface Reference Point Example ...... 12 3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example ... 13 3.6.2.1.3. End-to-End Using Reference Point Example ............ 14 3.6.3. Creation Process ........................................ 15 3.6.4. Destruction Process ..................................... 15 Steinberger & Nicklass Standards Track [Page 1] RFC 3202 Frame Relay Service Level Defs MIB January 2002 3.6.4.1. Manual Row Destruction ................................ 15 3.6.4.2. Automatic Row Destruction ............................. 16 3.6.5. Modification Process .................................... 16 3.6.6. Collection Process ...................................... 16 3.6.6.1. Remote Polling ........................................ 16 3.6.6.2. Sampling .............................................. 17 3.6.6.3. User History .......................................... 17 3.6.7. Use of MIB Module in Calculation of Service Level Definitions .................................................... 17 3.6.8. Delay ................................................... 20 3.6.9. Frame Delivery Ratio .................................... 20 3.6.10. Data Delivery Ratio .................................... 21 3.6.11. Service Availability ................................... 21 4. Relation to Other MIB Modules ............................... 22 5. Structure of the MIB Module ................................. 23 5.1. frsldPvcCtrlTable ......................................... 23 5.2. frsldSmplCtrlTable ........................................ 23 5.3. frsldPvcDataTable ......................................... 23 5.4. frsldPvcSampleTable ....................................... 24 5.5. frsldCapabilities ......................................... 24 6. Persistence of Data ......................................... 24 7. Object Definitions .......................................... 24 8. Acknowledgments ............................................. 61 9. References .................................................. 61 10. Security Considerations .................................... 63 11. Authors' Addresses ......................................... 63 12. Full Copyright Statement ................................... 64 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC Steinberger & Nicklass Standards Track [Page 2] RFC 3202 Frame Relay Service Level Defs MIB January 2002 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [22]. 3. Overview This MIB module addresses the items required to manage the Frame Relay Forum's Implementation Agreement for Service Level Definitions (FRF.13 [17]). At present, this applies to these values of the ifType variable in the Internet-standard MIB: o frameRelay (32) o frameRelayService (44) Steinberger & Nicklass Standards Track [Page 3] RFC 3202 Frame Relay Service Level Defs MIB January 2002 This section provides an overview and background of how to use this MIB module. 3.1. Frame Relay Service Level Definitions The frame relay service level definitions address specific characteristics of a frame relay service that can be used to facilitate the following tasks: o Evaluation of frame relay service providers, offerings or products. o Measurement of Quality of Service. o Enforcement of Service Level Agreements. o Planning or describing a frame relay network. The following parameters are defined in FRF.13 [17] as a sufficient set of values to accomplish the tasks previously stated. o Delay - The amount of time elapsed, in microseconds, from the time a frame exits the source to the time it reaches the destination. NOTE: FRF.13 [17] defines this value in terms of milliseconds. o Frame Delivery Ratio - The ratio of the number of frames delivered to the destination versus the number of frames sent by the source. This ratio can be further divided by inspecting either only the frames within the CIR or only the frames in excess of the CIR. o Data Delivery Ratio - The ratio of the amount of data delivered to the destination versus the amount of data sent by the source. This ratio can be further divided by inspecting either only the data within the CIR or only the data in excess of the CIR. o Service Availability - The amount of time the frame relay service was not available. There are three types of availability statistics defined in FRF.13 [17]: Mean Time to Repair, Virtual Connection Availability, and Mean Time Between Service Outages. The later two require information about the scheduled outage time. It is assumed that scheduled outage time information will be maintained by the network management software, so it is not included in the MIB module. Consult FRF.13 [17] for more details. Steinberger & Nicklass Standards Track [Page 4] RFC 3202 Frame Relay Service Level Defs MIB January 2002 3.2. Terminology o CIR - The Committed Information Rate (CIR) is the subscriber data rate (expressed in bits/second) that the network commits to deliver under normal network conditions [18]. o DLCI - Data Link Connection Identifier [18]. o Logical Port - This term is used to model the Frame Relay "interface" on a device [18]. o NNI - Network to Network Interface [18]. o Permanent Virtual Connection (PVC) - A virtual connection that has its end-points and bearer capabilities defined at subscription time [18]. o Reference Point (RP) - The point of reference within the network model at which the calculations or data collection takes place. o UNI - User to Network Interface [18]. 3.3. Network Model The basic model, as illustrated in figure 1 below, contains two frame relay DTE endpoints connected to a network cloud via a frame relay UNI interface. The network cloud can contain zero or more internal frame relay NNI connections that interconnect multiple networks. The calculations and data collection can be performed at any reference point within the network. +-------------+ +-------------+ | Frame Relay | | Frame Relay | | DTE Device | | DTE Device | +------+------+ +------+------+ | | UNI UNI Connection Connection | | +------+------+ NNI +-------------+ NNI +------+------+ | Network A +------------+ Network B +------------+ Network C | +-------------+ Connection +-------------+ Connection +-------------+ Figure 1 Frame Relay Network Reference Model Steinberger & Nicklass Standards Track [Page 5] RFC 3202 Frame Relay Service Level Defs MIB January 2002 3.4. Reference Points The collection and calculations of the service level definitions apply to two reference points within the network. These two points are the locations where the frames are referenced in the collection of the service level specific information. The reference points used in the MIB module are shown in figure 2 below. For completeness, the module also allows for proprietary reference points which MAY exist anywhere in the network that is not a previously defined reference point. The meaning of the proprietary reference points is insignificant unless defined by the device manufacturer. Steinberger & Nicklass Standards Track [Page 6] RFC 3202 Frame Relay Service Level Defs MIB January 2002 +---------------------------+ |+-----------+ +-----------+| || | |Measurement|| ||Frame Relay---Engine --(Source RP)----+ ||DTE | |(If Exists)|| | |+-----------+ +-----------+| | +---------------------------+ | Frame Relay Source | +------------------------------------------+ | Frame Relay Network | +----------------------------------+ | | +------------------------------+ | | | | +---------+ +---------+ | | | | | | | | Traffic | | | +--(Ingress RP)--- L1 / L2 --- Policing| | | | | | Control | | Engine | | | | | +---------+ +----|----+ | | | | | | | | | (Traffic Policing RP)| | | +------------------|-----------+ | | Ingress Node | | | | | | +-----------|-----------+ | | | Intermediate Nodes | | | +-----------|-----------+ | | | | | Egress Node | | | +--------------|-----------+ | | | (Egress Queue Input RP) | | | | | | | | | +-------+------+ | | | | | Egress Queue | | | | | +-------+------+ | | | | | | | | | (Egress Queue Output RP) | | | +--------------|-----------+ | +--------------------|-------------+ Frame Relay Destination | +---------------------------+ +-----------+ |+-----------+ +-----------+| | || | |Measurement|| | ||Frame Relay---Engine --(Destination RP)--+ ||DTE | |(If Exists)|| |+-----------+ +-----------+| +---------------------------+ Figure 2 Reference Points (FRF.13 [17]) Steinberger & Nicklass Standards Track [Page 7] RFC 3202 Frame Relay Service Level Defs MIB January 2002 The MIB variables frsldPvcCtrlTransmitRP and frsldPvcCtrlReceiveRP allow the user to view and configure the reference points at which the calculations occur. These variables are specific to the device on which they are located. Frame relay devices act as both frame sources and frame destinations. The definitions in this MIB module apply to the interaction of a pair of devices on the network path. The same device can potentially use different reference points for calculation and collection of the statistics based on whether the referenced frame is sent or received by the device. When the device is acting as a frame source, the value of frsldPvcCtrlTransmitRP reflects the reference point used for all source calculations pertaining to the specified PVC. When the device is acting as a frame destination, the value of frsldPvcCtrlReceiveRP reflects the reference point used for all destination calculations pertaining to the specified PVC. For example, FRF.13 [17] defines an Edge-to-Edge Egress Queue measurement domain as a domain in which measurement is performed between an Ingress Reference Point and an Egress Queue Input Reference Point. For this domain between a source device and a destination device, the value of frsldPvcCtrlTransmitRP for the source device would be set to ingTxLocalRP(2) and the value of frsldPvcCtrlReceiveRP for the destination device would be set to eqiRxLocalRP(4). While it is usually the case that the reference points would be equivalent on the remote device when monitoring frames going in the opposite direction, there is no requirement for them to be so. It can be seen from the above example that a total of four reference points are required in order to collect information for both directions of traffic flow. The reference points represent the transmit and receive directions at both ends of a PVC. If a device has knowledge of the information from the remote device, it is possible to collect the statistics from a single device. This is not always the case. In most instances, two devices will need to be monitored to capture a complete description of the service level on a PVC. The reference points a single device is capable of monitoring are contained in the frsldRPCaps object. 3.5. Measurement Methodology This document neither recommends nor suggests a method of implementation. This is left to the device manufacturer and should be independent of the data that is actually collected. Periodic collection of this data can be performed through either polling of the data table, use of the sample tables or use of the user history group of RFC 2021 [19]. Steinberger & Nicklass Standards Track [Page 8] RFC 3202 Frame Relay Service Level Defs MIB January 2002 3.6. Theory of Operation The following sections describe how to use this MIB module. They include row handling, data collection and data calculation. The recommendations here in are suggestions as to implementation and do not infer that they are the only method that can be used to perform such operations. 3.6.1. Capabilities Discovery Three objects are provided specifically to aid the network manager in discovering the capabilities of the device with respect to this MIB module. o frsldPvcCtrlWriteCaps This object reports the write capabilities of the PVC Control Table. Use this object to determine which objects can be modified. This need only be referenced if row creation or modification is to be performed. o frsldSmplCtrlWriteCaps This object reports the write capabilities of the Sample Control Table. Use this object to determine which objects can be modified. The group need only be referenced if the sample tables will be used to collect historical information. o frsldRPCaps This object reports the reference points at which the device is capable of collecting information. This object needs to be referenced if row creation is to be performed in the PVC Control Table. Devices can only create rows containing supported reference points. These objects do not imply that there is no need for an Agent Capabilities macro for devices that do not fully support every object in this MIB module. They are provided specifically to aid in the ensured network management operations of this MIB module with respect to row creation and modification. An additional four objects are provided to report and control memory the utilization of this MIB module. These objects are frsldMaxPvcCtrls, frsldNumPvcCtrls, frsldMaxSmplCtrls are frsldNumSmplCtrls. Together, they allow a manager to control the Steinberger & Nicklass Standards Track [Page 9] RFC 3202 Frame Relay Service Level Defs MIB January 2002 amount of memory allocated for specific utilization by this MIB module. This is done by setting the maximum allowed allocation of controls. 3.6.2. Determining Reference Points for Row Creation The performance of a PVC is monitored by evaluating the uni- directional flow of frames from an ingress point to an egress point. Reference points describe where each of the two measurements are made. Monitoring both of the uni-directional flows that make-up the PVC frame traffic requires a total of four reference points as shown in Figures 3 through 5. A monitoring point that evaluates traffic is restricted to counting frames that pass the reference points hosted locally on the monitoring point. Thus, if the monitoring point is near the ingress point of the flow, it will count the frames entering into the frame relay network. The complete picture of frame loss for the uni-directional flow requires information from the downstream reference point located at another (remote) monitoring point. The local monitoring point MAY be implemented in such way that the information from the downstream monitoring point is moved to the local monitoring point using implementation-specific mechanisms. In this case all information required to calculate frame loss becomes available from the local measurement point. The local measurement point agent is capable of reporting all the objects in the FrsldPvcDataEntry row - the counts for offered frames entering the network and delivered frames exiting the network. Alternatively, the local monitoring point MAY be restricted to counts of frames observed on the local device only. In this case, the objects of the FrsldPvcDataEntry row reporting what happened on the remote device are not available. The following list shows the possible valid reference points for an FRF.13 SLA from the source reference point to the destination reference point in both directions. o Local Information Only Local Device: srcLocalRP, desLocalRP Remote Device: srcLocalRP, desLocalRP o Remote Information Only Local Device: srcRemoteRP, desRemoteRP Remote Device: srcRemoteRP, desRemoteRP Steinberger & Nicklass Standards Track [Page 10] RFC 3202 Frame Relay Service Level Defs MIB January 2002 o Mixed Two Device Model 1 (Local Device Always Transmitter) Local Device: srcLocalRP, desRemoteRP Remote Device: srcLocalRP, desRemoteRP o Mixed Two Device Model 2 (Local Device Always Receiver) Local Device: srcRemoteRP, desLocalRP Remote Device: srcRemoteRP, desLocalRP o Mixed One Device Model 1 (Directional Rows) First Row: srcRemoteRP, desLocalRP (Receiver Row) Second Row: srcLocalRP, desRemoteRP (Sender Row) o Mixed One Device Model 2 (Device Based Rows) First Row: srcLocalRP, desLocalRP (Local Row) Second Row: srcRemoteRP, desRemoteRP (Remote Row) Each of the above combinations is valid and provides the same information. The following steps are recommended to find which reference points need to be configured: 1) Locate both of the devices at either end of the PVC to be monitored. 2) Determine the capabilities by referencing the frsldRPCaps object of each device. 3) Locate the best combination of the two devices such that the necessary reference points are all represented. 4) If any one of the necessary reference points does not exist in the combination of the two devices, it is not possible to monitor the FRF.13 defined SLA between the two reference point on the PVC. 3.6.2.1. Graphical Examples of Reference Points FRF.13 [17] defines three specific combinations of reference points: Edge-to-Edge Interface, Edge-to-Edge Egress Queue and End-to-End. Examples of valid reference points that may be used for each of these are discussed in the sections below. Steinberger & Nicklass Standards Track [Page 11] RFC 3202 Frame Relay Service Level Defs MIB January 2002 It is often the case that a device knows as a minimum either only local information or both local and remote information. Because these are two common examples, each will be illustrated below. 3.6.2.1.1. Edge-to-Edge Interface Reference Point Example Device 1 Device 2 +-------------+ +-------------+ | Ingress | | Egress | | +-----+ | | +-----+ | |(A)| | | Traffic Flow | | |(B)| -->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->--> | | | | From Device 1 to 2 | | | | | +-----+ | | +-----+ | | | | | | Egress | | Ingress | | +-----+ | | +-----+ | |(D)| | | Traffic Flow | | |(C)| <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- | | | | From Device 2 to 1 | | | | | +-----+ | | +-----+ | +-------------+ +-------------+ where (A), (B), (C) and (D) are reference points Figure 3 For devices with only local knowledge, one row is required on each device as follows: (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (B) frsldPvcCtlrReceiveRP for Device 2 = eqoRxLocalRP(5) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (D) frsldPvcCtlrReceiveRP for Device 1 = eqoRxLocalRP(5) In which a single row is created on Device 1 containing reference points (A) and (D), and a single row is created on Device 2 containing reference points (C) and (B). For devices with both local and remote knowledge, the two rows can exist in any combination on either device. For this example, the transmitting devices will be responsible for information regarding the flow for which they are the origin. Only one row is required per device for this example. Steinberger & Nicklass Standards Track [Page 12] RFC 3202 Frame Relay Service Level Defs MIB January 2002 (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (B) frsldPvcCtlrReceiveRP for Device 1 = eqoRxRemoteRP(11) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (D) frsldPvcCtlrReceiveRP for Device 2 = eqoRxRemoteRP(11) 3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example Device 1 Device 2 +-------------+ +-------------+ | Ingress | | Egress | | +-----+ | | +-----+ | |(A)| | | Traffic Flow |(B)| | | -->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->--> | | | | From Device 1 to 2 | | | | | +-----+ | | +-----+ | | | | | | Egress | | Ingress | | +-----+ | | +-----+ | | | |(D)| Traffic Flow | | |(C)| <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- | | | | From Device 2 to 1 | | | | | +-----+ | | +-----+ | +-------------+ +-------------+ where (A), (B), (C) and (D) are reference points Figure 4 For devices with only local knowledge, one row is required on each device as follows: (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (B) frsldPvcCtlrReceiveRP for Device 2 = eqiRxLocalRP(4) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (D) frsldPvcCtlrReceiveRP for Device 1 = eqiRxLocalRP(4) In which a single row is created on Device 1 containing reference points (A) and (D), and a single row is created on Device 2 containing reference points (C) and (B). Steinberger & Nicklass Standards Track [Page 13] RFC 3202 Frame Relay Service Level Defs MIB January 2002 For devices with both local and remote knowledge, the two rows can exist in any combination on either device. For this example, the transmitting devices will be responsible for information regarding the flow for which they are the origin. Only one row is required per device for this example. (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (B) frsldPvcCtlrReceiveRP for Device 1 = eqiRxRemoteRP(10) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (D) frsldPvcCtlrReceiveRP for Device 2 = eqiRxRemoteRP(10) 3.6.2.1.3. End-to-End Using Reference Point Example Device 1 Device 2 +-------------+ +-------------+ | Source | | Destination | | +-----+ | | +-----+ | |(A)| | | Traffic Flow | | |(B)| -->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->--> | | | | From Device 1 to 2 | | | | | +-----+ | | +-----+ | | | | | | Destination | | Source | | +-----+ | | +-----+ | |(D)| | | Traffic Flow | | |(C)| <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- | | | | From Device 2 to 1 | | | | | +-----+ | | +-----+ | +-------------+ +-------------+ where (A), (B), (C) and (D) are reference points Figure 5 For devices with only local knowledge, one row is required on each device as follows: (A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1) (B) frsldPvcCtlrReceiveRP for Device 2 = desLocalRP(1) (C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1) (D) frsldPvcCtlrReceiveRP for Device 1 = desLocalRP(1) Steinberger & Nicklass Standards Track [Page 14] RFC 3202 Frame Relay Service Level Defs MIB January 2002 In which a single row is created on Device 1 containing reference points (A) and (D), and a single row is created on Device 2 containing reference points (C) and (B). For devices with both local and remote knowledge, the two rows can exist in any combination on either device. For this example, the transmitting devices will be responsible for information regarding the flow for which they are the origin. Only one row is required per device for this example. (A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1) (B) frsldPvcCtlrReceiveRP for Device 1 = desRemoteRP(7) (C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1) (D) frsldPvcCtlrReceiveRP for Device 2 = desRemoteRP(7) 3.6.3. Creation Process In some cases, devices will automatically populate the rows of PVC Control Table and potentially the Sample Control Table. However, in many cases, it may be necessary for a network manager to manually create rows. Manual creation of rows requires the following steps: 1) Ensure the PVC exists between the two devices. 2) Determine the necessary reference points for row creation. 3) Create the row(s) in each device as needed. 4) Create the row(s) in the sample control tables if desired. 3.6.4. Destruction Process 3.6.4.1. Manual Row Destruction Manual row destruction is straight forward. Any row can be destroyed and the resources allocated to it are freed by setting the value of its status object (either frsldPvcCtrlStatus or frsldSmplCtrlStatus) to destroy(6). It should be noted that when frsldPvcCtrlStatus is set to destroy(6) all associated sample control, sample and data table rows will also be destroyed. Similarly, when frsldSmplCtrlStatus is set to destroy(6) all sample rows will also be Steinberger & Nicklass Standards Track [Page 15] RFC 3202 Frame Relay Service Level Defs MIB January 2002 destroyed. The frsldPvcCtrlPurge objects do not apply to manual row destruction. If the row is set to destroy(6) manually, the rows are destroyed as part of the set. 3.6.4.2. Automatic Row Destruction Rows is the tables may be destroyed automatically based on the existence of the DLCI on which they rely. This behavior is controlled by the frsldPvcCtrlPurge and frsldPvcCtrlDeleteOnPurge objects. When a DLCI no longer exists in the device, the data in the tables has no relation to anything known on the network. However, there may be some need to keep the historic information active for a short period after the destruction or removal of a DLCI. If the basis for the row no longer exists, the row will be destroyed at the end of the purge interval that is controlled by frsldPvcCtrlPurge. The effects of automatic row destruction are the same as manual row destruction. 3.6.5. Modification Process All read-create items in this MIB module can be modified at any time if they are fully supported. Write access is not required. To simplify the use of the MIB frsldPvcCtrlWriteCaps and frsldSmplCtrlWriteCaps state which of the read-create variables can actually be written on a particular device. 3.6.6. Collection Process 3.6.6.1. Remote Polling This MIB module supports data collection through remote polling of the free running counters in the PVC Data Table. Remote polling is a common method used to capture real-time statistics. A remote management station polls the device to collect the desired information. It is recommended all statistics for a single PVC be collected in a single PDU. The following objects are designed around the concept of real-time polling: o frsldPvcDataMissedPolls o frsldPvcDataFrDeliveredC o frsldPvcDataFrDeliveredE o frsldPvcDataFrOfferedC o frsldPvcDataFrOfferedE o frsldPvcDataDataDeliveredC o frsldPvcDataDataDeliveredE Steinberger & Nicklass Standards Track [Page 16] RFC 3202 Frame Relay Service Level Defs MIB January 2002 o frsldPvcDataDataOfferedC o frsldPvcDataDataOfferedE o frsldPvcDataHCFrDeliveredC o frsldPvcDataHCFrDeliveredE o frsldPvcDataHCFrOfferedC o frsldPvcDataHCFrOfferedE o frsldPvcDataHCDataDeliveredC o frsldPvcDataHCDataDeliveredE o frsldPvcDataHCDataOfferedC o frsldPvcDataHCDataOfferedE o frsldPvcDataUnavailableTime o frsldPvcDataUnavailables 3.6.6.2. Sampling The sample tables provide the ability to historically sample data without requiring the additional overhead of polling. At key periods, a network management station can collect the samples needed. This method allows the manager to perform the collection of data at times that will least affect the active network traffic. The sample data can be collected using a series of SNMP getNext or getBulk operations. The value of frsldPvcSmplIdx increments with each new collection bucket. This allows the managers to skip information that has already been collected. However, care should be taken in that the value can roll over after a long period of time. The start and end times of a collection period allow the manager to know what the actual period of collection was. It is possible for there to be discontinuities in the sample table, so both start and end should be referenced. 3.6.6.3. User History User history, as defined in RFC 2021 [19], is an alternative mechanism that can be used to get the same benefits as the sample table by using the objects provided for real-time polling. Some devices MAY have the ability to use user history and opt not to support the sample tables. If this is the case, the information from the data table can be used to define a group of user history objects. 3.6.7. Use of MIB Module in Calculation of Service Level Definitions The objects in this MIB module can be used to calculate the statistics defined in FRF.13 [17]. The description below describes the calculations for one direction of the data flow, i.e., data sent from local transmitter to a remote receiver. A complete set of bidirectional information would require calculations based on both Steinberger & Nicklass Standards Track [Page 17] RFC 3202 Frame Relay Service Level Defs MIB January 2002 directions. For the purposes of this description, the reference points used SHOULD consistently represent data that is sent by one device and received by the other. A complete evaluation requires the combination of two uni-directional flows. It is possible for a management station to combine all of the calculated information into one conceptual row. Doing this requires that each of the metrics are collected for both flow directions and grouped by direction If the information is split between two devices, the management station must know which two devices to communicate with for the collection of all information. The grouping of information SHOULD be from ingress to egress in each flow direction. The calculations below use the following terminology: o DelayAvg The average delay on the PVC. This is represented within the MIB module by frsldPvcSmplDelayAvg. o FrDeliveredC The number of frames received by the receiving device through the receive reference point that were delivered within CIR. This is represented within the MIB module by one of frsldPvcDataFrDeliveredC, frsldPvcDataHCFrDeliveredC, frsldPvcSmplFrDeliveredC, or frsldPvcSmplHCFrDeliveredC. o FrDeliveredE The number of frames received by the receiving device through the receive reference point that were delivered in excess of CIR. This is represented within the MIB module by one of frsldPvcDataFrDeliveredE, frsldPvcDataHCFrDeliveredE, frsldPvcSmplFrDeliveredE, or frsldPvcSmplHCFrDeliveredE. o FrOfferedC The number of frames offered by the transmitting device through the transmit reference point that were sent within CIR. This is represented within the MIB module by one of frsldPvcDataFrOfferedC, frsldPvcDataHCFrOfferedC, frsldPvcSmplFrOfferedC, or frsldPvcSmplHCFrOfferedC. Steinberger & Nicklass Standards Track [Page 18] RFC 3202 Frame Relay Service Level Defs MIB January 2002 o FrOfferedE The number of frames offered by the transmitting device through the transmit reference point that were sent in excess of CIR. This is represented within the MIB module by one of frsldPvcDataFrOfferedE, frsldPvcDataHCFrOfferedE, frsldPvcSmplFrOfferedE, or frsldPvcSmplHCFrOfferedE. o DataDeliveredC The number of octets received by the receiving device through the receive reference point that were delivered within CIR. This is represented within the MIB module by one of frsldPvcDataDataDeliveredC, frsldPvcDataHCDataDeliveredC, frsldPvcSmplDataDeliveredC, or frsldPvcSmplHCDataDeliveredC. o DataDeliveredE The number of octets received by the receiving device through the receive reference point that were delivered in excess of CIR. This is represented within the MIB module by one of frsldPvcDataDataDeliveredE, frsldPvcDataHCDataDeliveredE, frsldPvcSmplDataDeliveredE, or frsldPvcSmplHCDataDeliveredE. o DataOfferedC The number of octets offered by the transmitting device through the transmit reference point that were sent within CIR. This is represented within the MIB module by one of frsldPvcDataDataOfferedC, frsldPvcDataHCDataOfferedC, frsldPvcSmplDataOfferedC, or frsldPvcSmplHCDataOfferedC. o DataOfferedE The number of octets offered by the transmitting device through the transmit reference point that were sent in excess of CIR. This is represented within the MIB module by one of frsldPvcDataDataOfferedE, frsldPvcDataHCDataOfferedE, frsldPvcSmplDataOfferedE, or frsldPvcSmplHCDataOfferedE. o UnavailableTime The amount of time the PVC was not available during the interval of interest. This is represented within the MIB module by either frsldPvcDataUnavailableTime or frsldPvcSmplUnavailableTime. Steinberger & Nicklass Standards Track [Page 19] RFC 3202 Frame Relay Service Level Defs MIB January 2002 o Unavailables The number of times the PVC was declared to be unavailable during the interval of interest. This is represented within the MIB module by either frsldPvcDataUnavailables or frsldPvcSmplUnavailables. 3.6.8. Delay The frame transfer delay is defined as the amount of time elapsed, in microseconds, from the time a frame exits the source to the time it reaches the destination. The average delay can be found using the MIB variable described in DelayAvg above. The delay may be calculated as either round trip or one way, and this information is held in the frsldPvcCtrlDelayType MIB variable. If the delay be calculated as round trip, the value of DelayAvg represents the average of the total delays of the round trips. In this case, the manager SHOULD divide the value returned by the agent by two to obtain the frame transfer delay. In the case that frsldPvcCtrlDelayType is oneWay, the value of DelayAvg represents the average of the frame transfer delays and SHOULD be used as is. 3.6.9. Frame Delivery Ratio The frame delivery ratio is defined as the total number of frames delivered to the destination divided by the frames offered by the source. The destination values can be obtained using FrDeliveredC and FrDeliveredE. The source values can be obtained using FrOfferedC and FrOfferedE. FrDeliveredC + FrDeliveredE Frame Delivery Ratio = --------------------------- FrOfferedC + FrOfferedE FrDeliveredC Committed Frame Delivery Ratio = ------------ FrOfferedC FrDeliveredE Excess Frame Delivery Ratio = ------------ FrOfferedE Steinberger & Nicklass Standards Track [Page 20] RFC 3202 Frame Relay Service Level Defs MIB January 2002 3.6.10. Data Delivery Ratio The data delivery ratio is defined as the total amount of data delivered to the destination divided by the data offered by the source. The destination values can be obtained using DataDeliveredC and DataDeliveredE. The source values can be obtained using DataOfferedC and DataOfferedE. DataDeliveredC + DataDeliveredE Data Delivery Ratio = ------------------------------- DataOfferedC + DataOfferedE DataDeliveredC Committed Data Delivery Ratio = -------------- DataOfferedC DataDeliveredE Excess Data Delivery Ratio = -------------- DataOfferedE 3.6.11. Service Availability Some forms of service availability measurement defined in FRF.13 [17] require knowledge of the amount of time the network is allowed to be unavailable during the period of measurement. This is called the excluded outage time and will be represented in the measurements below as ExcludedTime. It is assumed that the management software will maintain this information in that it often relates to specific times and dates that many devices are not capable of maintaining. Further, it may change based on a moving maintenance window that the device cannot track well. Mean Time to Repair (FRMTTR) = 0 if Unavailables is 0. UnavailableTime Otherwise, FRMTTR = --------------- Unavailables Virtual Connection Availability (FRVCA) = 0 if IntervalTime equals ExcludedTime. IntervalTime - ExcludedTime - UnavailableTime Otherwise, FRVCA = --------------------------------------------- *100 IntervalTime - ExcludedTime Mean Time Between Service Outages (FRMTBSO) = 0 if Unavailables is 0. Steinberger & Nicklass Standards Track [Page 21] RFC 3202 Frame Relay Service Level Defs MIB January 2002 Otherwise, FRMTBSO = IntervalTime - ExcludedTime - UnavailableTime --------------------------------------------- Unavailables 4. Relation to Other MIB Modules There is no explicit relation to any other frame relay MIB module nor are any required to implement this MIB module. However, there is a need for knowledge of ifIndexes and some understanding of DLCIs. The ifIndex information can be found in the IF-MIB [21] which is required. The DLCI information can be found in either the Frame Relay DTE MIB (RFC 2115) [20] or the Frame Relay Network Services MIB (RFC 2954) [18]; however, neither is required. Upon setting of frsldPvcCtrlStatus in the frsldPvcCtrlTable to active(1) the system can be in one of the following three states: (1) The respective DLCI is known and is active. This corresponds to a state in which frPVCEndptRowStatus is active(1) and frPVCEndptRcvdSigStatus is either active(2) or none(4) for the Frame Relay Network Services MIB (RFC 2954) [18]. For the Frame Relay DTE MIB, the same state is shown by frCircuitRowStatus of active(1) and frCircuitState of active(2). (2) The respective DLCI has not been created. This corresponds to a state in which the row with either frPVCEndptDLCIIndex or frCircuitDlci equal to the respective DLCI does not exist in either the frPVCEndptTable or the frCircuitTable respectively. (3) The respective DLCI has just been removed. This corresponds to a state in which either frPVCEndptRowStatus is no longer active(1) or frPVCEndptRcvdSigStatus is no longer active(2) or none(4) for the Frame Relay Network Services MIB (RFC 2954) [18]. For the Frame Relay DTE MIB, the same state is shown when either frCircuitRowStatus is no longer active(1) or frCircuitState is no longer active(2). For the first case, the row in the frsldPvcDataTable will be filled. If frsldSmplCtrlStatus in the frsldSmplCtrlTable for the respective DLCI is also `active' the frsldPvcSampleTable will be filled as well. For the second case, the respective rows will not be added to any of the data or sample tables and frsldPvcCtrlStatus SHOULD report notReady(3). Steinberger & Nicklass Standards Track [Page 22] RFC 3202 Frame Relay Service Level Defs MIB January 2002 For the third case, frsldPvcCtrlDeleteOnPurge should direct the behavior of the system. If all tables are purged, this case will be equivalent to the second case above. Otherwise, frsldPvcCtrlStatus SHOULD remain active(1). 5. Structure of the MIB Module The FRSLD-MIB consists of the following components: o frsldPvcCtrlTable o frsldSmplCtrlTable o frsldPvcDataTable o frsldPvcSampleTable o frsldCapabilities Refer to the compliance statement defined within for a definition of what objects MUST be implemented. 5.1. frsldPvcCtrlTable The frsldPvcCtrlTable is the central control table for operations of the Frame Relay Service Level Definitions MIB. It provides variables to control the parameters required to calculate the objects in the other tables. A row in this table MUST exist in order for a row to exist in any other table in this MIB module. 5.2. frsldSmplCtrlTable This is an optional table to allow control of sampling of the data in the data table. 5.3. frsldPvcDataTable This table contains the calculated data. It relies on configuration from the control table. Steinberger & Nicklass Standards Track [Page 23] RFC 3202 Frame Relay Service Level Defs MIB January 2002 5.4. frsldPvcSampleTable This table contains samples of the delivery and availability information from the data table as well as delay information calculated over the sample period. It relies on configuration from both the control table and the sample control table. 5.5. frsldCapabilities This is a group of objects that define write capabilities of the read-create objects in the tables above. 6. Persistence of Data The data in frsldPvcCtrlTable and frsldSmplCtrlTable SHOULD persist through power cycles. Note, however, that the symantics of readiness for the rows still applies. This means that it is possible for a row to be reprovisioned as notReady(3) if the underlying DLCI does not persist. The data collected in the other tables SHOULD NOT persist through power cycles in that the reference TimeStamp is no longer valid. 7. Object Definitions FRSLD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, Counter64, TimeTicks, mib-2 FROM SNMPv2-SMI CounterBasedGauge64 FROM HCNUM-TC TEXTUAL-CONVENTION, RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB DLCI FROM FRAME-RELAY-DTE-MIB; frsldMIB MODULE-IDENTITY LAST-UPDATED "200201030000Z" -- January 3, 2002 ORGANIZATION "IETF Frame Relay Service MIB Working Group" CONTACT-INFO "IETF Frame Relay Service MIB (frnetmib) Working Group WG Charter: http://www.ietf.org/html.charters/ frnetmib-charter.html WG-email: frnetmib@sunroof.eng.sun.com Subscribe: frnetmib-request@sunroof.eng.sun.com Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib Steinberger & Nicklass Standards Track [Page 24] RFC 3202 Frame Relay Service Level Defs MIB January 2002 Chair: Andy Malis Vivace Networks Email: Andy.Malis@vivacenetworks.com WG editor: Robert Steinberger Paradyne Networks and Fujitsu Network Communications Email: robert.steinberger@fnc.fujitsu.com Co-author: Orly Nicklass RAD Data Communications Ltd. EMail: Orly_n@rad.co.il" DESCRIPTION "The MIB module to describe generic objects for FRF.13 Frame Relay Service Level Definitions." REVISION "200201030000Z" -- January 3, 2002 DESCRIPTION "Initial version, published as RFC 3202" ::= { mib-2 95 } -- -- Textual Conventions -- FrsldTxRP ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The reference point a PVC uses for calculation of transmitter related statistics. The valid values for this type of object are as follows: - srcLocalRP(1) for the local source - ingTxLocalRP(2) for the local ingress queue input - tpTxLocalRP(3) for the local traffic policing - eqiTxLocalRP(4) for the local egress queue input - eqoTxLocalRP(5) for the local egress queue output - otherTxLocalRP(6) for any other local transmit point - srcRemoteRP(7) for the remote source - ingTxLocalRP(8) for the remote ingress queue input - tpTxLocalRP(9) for the remote traffic policing - eqiTxRemoteRP(10) for the remote egress queue input - eqoTxRemoteRP(11) for the remote egress queue output - otherTxRemoteRP(12) for any other remote xmit point" REFERENCE "FRF.13: Section 2.3" SYNTAX INTEGER { srcLocalRP(1), ingTxLocalRP(2), tpTxLocalRP(3), Steinberger & Nicklass Standards Track [Page 25] RFC 3202 Frame Relay Service Level Defs MIB January 2002 eqiTxLocalRP(4), eqoTxLocalRP(5), otherTxLocalRP(6), srcRemoteRP(7), ingTxRemoteRP(8), tpTxRemoteRP(9), eqiTxRemoteRP(10), eqoTxRemoteRP(11), otherTxRemoteRP(12) } FrsldRxRP ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The reference point a PVC uses for calculation of receiver related statistics. The valid values for this object are as follows: - desLocalRP(1) for the local destination - ingRxLocalRP(2) for the local ingress queue input - tpRxLocalRP(3) for the local traffic policing - eqiRxLocalRP(4) for the local egress queue input - eqoRxLocalRP(5) for the local egress queue output - otherRxLocalRP(6) for any other local receive point - desRemoteRP(7) for the remote destination - ingRxRemoteRP(8) for the remote ingress input - tpRxRemoteRP(9) for the remote traffic policing - eqiRxRemoteRP(10) for the remote egress queue input - eqoRxRemoteRP(11) for the remote egress queue output - otherRxRemoteRP(12) for any other remote receive point" REFERENCE "FRF.13: Section 2.3" SYNTAX INTEGER { desLocalRP(1), ingRxLocalRP(2), tpRxLocalRP(3), eqiRxLocalRP(4), eqoRxLocalRP(5), otherRxLocalRP(6), desRemoteRP(7), ingRxRemoteRP(8), tpRxRemoteRP(9), eqiRxRemoteRP(10), eqoRxRemoteRP(11), otherRxRemoteRP(12) } -- Steinberger & Nicklass Standards Track [Page 26] RFC 3202 Frame Relay Service Level Defs MIB January 2002 -- Base Objects --- frsldObjects OBJECT IDENTIFIER ::= { frsldMIB 1 } frsldCapabilities OBJECT IDENTIFIER ::= { frsldMIB 2 } frsldConformance OBJECT IDENTIFIER ::= { frsldMIB 3 } -- The Frame Relay Service Level Definitions PVC Control Table -- -- This table is used to define and display the parameters of -- service level definitions on individual PVCs. frsldPvcCtrlTable OBJECT-TYPE SYNTAX SEQUENCE OF FrsldPvcCtrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Service Level Definitions PVC control table." ::= { frsldObjects 1 } frsldPvcCtrlEntry OBJECT-TYPE SYNTAX FrsldPvcCtrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay Service Level Definitions PVC control table." INDEX { ifIndex, frsldPvcCtrlDlci, frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP} ::= { frsldPvcCtrlTable 1 } FrsldPvcCtrlEntry ::= SEQUENCE { -- -- Index Control Variables -- frsldPvcCtrlDlci DLCI, frsldPvcCtrlTransmitRP FrsldTxRP, frsldPvcCtrlReceiveRP FrsldRxRP, frsldPvcCtrlStatus RowStatus, -- -- Service Level Definitions Setup Variables -- frsldPvcCtrlPacketFreq Integer32, -- -- Delay Specific Setup Variables -- Steinberger & Nicklass Standards Track [Page 27] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcCtrlDelayFrSize Integer32, frsldPvcCtrlDelayType INTEGER, frsldPvcCtrlDelayTimeOut Integer32, -- -- Data Persistence Control Variables -- frsldPvcCtrlPurge Integer32, frsldPvcCtrlDeleteOnPurge INTEGER, frsldPvcCtrlLastPurgeTime TimeStamp } frsldPvcCtrlDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the DLCI value for this PVC." ::= { frsldPvcCtrlEntry 1 } frsldPvcCtrlTransmitRP OBJECT-TYPE SYNTAX FrsldTxRP MAX-ACCESS not-accessible STATUS current DESCRIPTION "The reference point this PVC uses for calculation of transmitter related statistics. This object together with frsldPvcCtrlReceiveRP define the measurement domain." REFERENCE "FRF.13: Section 2.3" ::= { frsldPvcCtrlEntry 2 } frsldPvcCtrlReceiveRP OBJECT-TYPE SYNTAX FrsldRxRP MAX-ACCESS not-accessible STATUS current DESCRIPTION "The reference point this PVC uses for calculation of receiver related statistics. This object together with frsldPvcCtrlTransmitRP define the measurement domain." ::= { frsldPvcCtrlEntry 3 } frsldPvcCtrlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Steinberger & Nicklass Standards Track [Page 28] RFC 3202 Frame Relay Service Level Defs MIB January 2002 DESCRIPTION "The status of the current row. This object is used to add, delete, and disable rows in this table. When the status changes to active(1) for the first time, a row will also be added to the data table below. This row SHOULD not be removed until the status is changed to deleted. When this object is set to destroy(6), all associated sample and data table rows will also be deleted. When this object is changed from active(1) to any other valid value, the defined purge behavior will affect the data and sample tables. The rows added to this table MUST have a valid ifIndex and an ifType related to frame relay. Further, the reference points referred to by frsldPvcCtrlTransmitRP and frsldPvcCtrlReceiveRP MUST be supported (see the frsldRPCaps object). If at any point the row is not in the active(1) state and the DLCI no longer exists, the state SHOULD report notReady(3). The data in this table SHOULD persist through power cycles. The symantics of readiness for the rows still applies. This means that it is possible for a row to be reprovisioned as notReady(3) if the underlying DLCI does not persist." ::= { frsldPvcCtrlEntry 4 } frsldPvcCtrlPacketFreq OBJECT-TYPE SYNTAX Integer32 (0..3600) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency in seconds between initiation of specialized packets used to collect delay and / or delivery information as supported by the device. A value of zero indicates that no packets will be sent." DEFVAL { 60 } ::= { frsldPvcCtrlEntry 5 } frsldPvcCtrlDelayFrSize OBJECT-TYPE SYNTAX Integer32 (1..8188) UNITS "octets" Steinberger & Nicklass Standards Track [Page 29] RFC 3202 Frame Relay Service Level Defs MIB January 2002 MAX-ACCESS read-create STATUS current DESCRIPTION "The size of the payload in the frame used for calculation of network delay." DEFVAL { 128 } ::= { frsldPvcCtrlEntry 6 } frsldPvcCtrlDelayType OBJECT-TYPE SYNTAX INTEGER { oneWay(1), roundTrip(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of delay measurement performed." REFERENCE "FRF.13: Section 3" ::= { frsldPvcCtrlEntry 7 } frsldPvcCtrlDelayTimeOut OBJECT-TYPE SYNTAX Integer32 (1..3600) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A delay frame will count as a missed poll if it is not updated in the time specified by frsldPvcCtrlDelayTimeOut." DEFVAL { 60 } ::= { frsldPvcCtrlEntry 8 } frsldPvcCtrlPurge OBJECT-TYPE SYNTAX Integer32 (0..172800) -- up to 48 hours UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the amount of time the device will wait, after discovering that a DLCI does not exist, the DLCI was deleted or the value of frsldPvcCtrlStatus changes from active(1) to either notInService(2) or notReady(3), prior to automatically purging the history in the sample tables and resetting the data in the data tables to all zeroes. If frsldPvcCtrlStatus is manually set to destroy(6), this object does not apply." DEFVAL { 0 } Steinberger & Nicklass Standards Track [Page 30] RFC 3202 Frame Relay Service Level Defs MIB January 2002 ::= { frsldPvcCtrlEntry 9 } frsldPvcCtrlDeleteOnPurge OBJECT-TYPE SYNTAX INTEGER { none(1), sampleContols(2), all(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether rows will automatically be deleted from the tables when the information is purged. - A value of none(1) indicates that no rows will deleted. The last known values will be preserved. - A value of sampleControls(2) indicates that all associated sample control rows will be deleted. - A value of all(3) indicates that all associated rows SHOULD be deleted." DEFVAL { all } ::= { frsldPvcCtrlEntry 10 } frsldPvcCtrlLastPurgeTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the value of sysUpTime at the time the information was last purged. This value SHOULD be set to the sysUpTime upon setting frsldPvcCtrlStatus to active(1) for the first time. Each time a discontinuity in the counters occurs, this value MUST be set to the sysUpTime. If frsldPvcCtrlStatus has never been active(1), this object SHOULD return 0. This object SHOULD be used as the discontinuity timer for the counters in frsldPvcDataTable." ::= { frsldPvcCtrlEntry 11 } -- The Frame Relay Service Level Definitions Sampling Control -- Table Steinberger & Nicklass Standards Track [Page 31] RFC 3202 Frame Relay Service Level Defs MIB January 2002 -- -- This table is used to define the sample control parameters -- of service level definitions on individual PVCs. frsldSmplCtrlTable OBJECT-TYPE SYNTAX SEQUENCE OF FrsldSmplCtrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Service Level Definitions sampling control table." ::= { frsldObjects 2 } frsldSmplCtrlEntry OBJECT-TYPE SYNTAX FrsldSmplCtrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay Service Level Definitions sample control table." INDEX { ifIndex, frsldPvcCtrlDlci, frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP, frsldSmplCtrlIdx } ::= { frsldSmplCtrlTable 1 } FrsldSmplCtrlEntry ::= SEQUENCE { -- -- Index Control Variables -- frsldSmplCtrlIdx Integer32, frsldSmplCtrlStatus RowStatus, -- -- Collection Control Variables -- frsldSmplCtrlColPeriod Integer32, frsldSmplCtrlBuckets Integer32, frsldSmplCtrlBucketsGranted Integer32 } frsldSmplCtrlIdx OBJECT-TYPE SYNTAX Integer32 (1..256) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique index for this row in the sample control table." ::= { frsldSmplCtrlEntry 1 } Steinberger & Nicklass Standards Track [Page 32] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldSmplCtrlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the current row. This object is used to add, delete, and disable rows in this table. This row SHOULD NOT be removed until the status is changed to destroy(6). When the status changes to active(1), the collection in the sample tables below will be activated. The rows added to this table MUST have a valid ifIndex, an ifType related to frame relay, frsldPvcCtrlDlci MUST exist for the specified ifIndex and frsldPvcCtrlStatus MUST have a value of active(1). The value of frsldPvcCtrlStatus MUST be active(1) to transition this object to active(1). If the value of frsldPvcCtrlStatus becomes anything other than active(1) when the state of this object is not active(1), this object SHOULD be set to notReady(3). The data in this table SHOULD persist through power cycles. The symantics of readiness for the rows still applies. This means that it is possible for a row to be reprovisioned as notReady(3) if the underlying DLCI does not persist." ::= { frsldSmplCtrlEntry 2 } frsldSmplCtrlColPeriod OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The amount of time in seconds that defines a period of collection for the statistics. At the end of each period, the statistics will be sampled and a row is added to the sample table." ::= { frsldSmplCtrlEntry 3 } frsldSmplCtrlBuckets OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current Steinberger & Nicklass Standards Track [Page 33] RFC 3202 Frame Relay Service Level Defs MIB January 2002 DESCRIPTION "The number of discrete buckets over which the data statistics are sampled. When this object is created or modified, the device SHOULD attempt to set the frsldSmplCtrlBuckets- Granted to a value as close as is possible depending upon the implementation and the available resources." DEFVAL { 60 } ::= { frsldSmplCtrlEntry 4 } frsldSmplCtrlBucketsGranted OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of discrete buckets granted. This object will return 0 until frsldSmplCtrlStatus is set to active(1). At that time the buckets will be allocated depending upon implementation and available resources." ::= { frsldSmplCtrlEntry 5 } -- The Frame Relay Service Level Definitions PVC Data Table -- -- This table contains the accumulated values of -- the collected data. This table is the table that should -- be referenced by external polling mechanisms if time -- based polling be desired. frsldPvcDataTable OBJECT-TYPE SYNTAX SEQUENCE OF FrsldPvcDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Service Level Definitions data table. This table contains accumulated values of the collected data. It is the table that should be referenced by external polling mechanisms if time based polling be desired." ::= { frsldObjects 3 } frsldPvcDataEntry OBJECT-TYPE SYNTAX FrsldPvcDataEntry MAX-ACCESS not-accessible Steinberger & Nicklass Standards Track [Page 34] RFC 3202 Frame Relay Service Level Defs MIB January 2002 STATUS current DESCRIPTION "An entry in the Frame Relay Service Level Definitions data table." INDEX { ifIndex, frsldPvcCtrlDlci, frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP} ::= { frsldPvcDataTable 1 } FrsldPvcDataEntry ::= SEQUENCE { frsldPvcDataMissedPolls Counter32, frsldPvcDataFrDeliveredC Counter32, frsldPvcDataFrDeliveredE Counter32, frsldPvcDataFrOfferedC Counter32, frsldPvcDataFrOfferedE Counter32, frsldPvcDataDataDeliveredC Counter32, frsldPvcDataDataDeliveredE Counter32, frsldPvcDataDataOfferedC Counter32, frsldPvcDataDataOfferedE Counter32, frsldPvcDataHCFrDeliveredC Counter64, frsldPvcDataHCFrDeliveredE Counter64, frsldPvcDataHCFrOfferedC Counter64, frsldPvcDataHCFrOfferedE Counter64, frsldPvcDataHCDataDeliveredC Counter64, frsldPvcDataHCDataDeliveredE Counter64, frsldPvcDataHCDataOfferedC Counter64, frsldPvcDataHCDataOfferedE Counter64, frsldPvcDataUnavailableTime TimeTicks, frsldPvcDataUnavailables Counter32 } frsldPvcDataMissedPolls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of polls that have been determined to be missed. These polls are typically associated with the calculation of delay but may also be used for the calculation of other statistics. If an anticipated poll is not received in a reasonable amount of time, it should be counted as missed. The value used to determine the reasonable amount of time is contained in frsldPvcCtrlDelayTimeOut. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by Steinberger & Nicklass Standards Track [Page 35] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcCtrlLastPurgeTime." ::= { frsldPvcDataEntry 1 } frsldPvcDataFrDeliveredC OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesDeliveredc)" ::= { frsldPvcDataEntry 2 } frsldPvcDataFrDeliveredE OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been sent in excess of the CIR. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesDeliverede)" ::= { frsldPvcDataEntry 3 } frsldPvcDataFrOfferedC OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were offered through frsldPvcCtrlTransmitRP within CIR. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by Steinberger & Nicklass Standards Track [Page 36] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesOfferedc)" ::= { frsldPvcDataEntry 4 } frsldPvcDataFrOfferedE OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were offered through frsldPvcCtrlTransmitRP in excess of the CIR. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesOfferede)" ::= { frsldPvcDataEntry 5 } frsldPvcDataDataDeliveredC OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataDeliveredc)" ::= { frsldPvcDataEntry 6 } frsldPvcDataDataDeliveredE OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlReceiveRP and determined to have been sent in excess of the CIR. Discontinuities in the value of this counter can Steinberger & Nicklass Standards Track [Page 37] RFC 3202 Frame Relay Service Level Defs MIB January 2002 occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataDeliverede)" ::= { frsldPvcDataEntry 7 } frsldPvcDataDataOfferedC OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through frsldPvcCtrlTransmitRP within CIR. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataOfferedc)" ::= { frsldPvcDataEntry 8 } frsldPvcDataDataOfferedE OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through frsldPvcCtrlTransmitRP in excess of the CIR. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataOfferede)" ::= { frsldPvcDataEntry 9 } frsldPvcDataHCFrDeliveredC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR. This object is a 64-bit version of frsldPvcDataFrDeliveredC. Steinberger & Nicklass Standards Track [Page 38] RFC 3202 Frame Relay Service Level Defs MIB January 2002 Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesDeliveredc)" ::= { frsldPvcDataEntry 10 } frsldPvcDataHCFrDeliveredE OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been sent in excess of the CIR. This object is a 64-bit version of frsldPvcDataFrDeliveredE. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesDeliverede)" ::= { frsldPvcDataEntry 11 } frsldPvcDataHCFrOfferedC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were offered through frsldPvcCtrlTransmitRP within CIR. This object is a 64-bit version of frsldPvcDataFrOfferedC. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesOfferedc)" ::= { frsldPvcDataEntry 12 } frsldPvcDataHCFrOfferedE OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION Steinberger & Nicklass Standards Track [Page 39] RFC 3202 Frame Relay Service Level Defs MIB January 2002 "The number of frames that were offered through frsldPvcCtrlTransmitRP in excess of the CIR. This object is a 64-bit version of frsldPvcDataFrOfferedE. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 4.1 (FramesOfferede)" ::= { frsldPvcDataEntry 13 } frsldPvcDataHCDataDeliveredC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR. This object is a 64-bit version of frsldPvcDataDataDeliveredC. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataDeliveredc)" ::= { frsldPvcDataEntry 14 } frsldPvcDataHCDataDeliveredE OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlReceiveRP and determined to have been sent in excess of the CIR. This object is a 64-bit version of frsldPvcDataDataDeliveredE. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataDeliverede)" ::= { frsldPvcDataEntry 15 } Steinberger & Nicklass Standards Track [Page 40] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcDataHCDataOfferedC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through frsldPvcCtrlTransmitRP within CIR. This object is a 64-bit version of frsldPvcDataDataOfferedC. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataOfferedc)" ::= { frsldPvcDataEntry 16 } frsldPvcDataHCDataOfferedE OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through frsldPvcCtrlTransmitRP in excess of the CIR. This object is a 64-bit version of frsldPvcDataDataOfferedE. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 5.1 (DataOfferede)" ::= { frsldPvcDataEntry 17 } frsldPvcDataUnavailableTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time this PVC was declared unavailable for any reason since this row was created." REFERENCE "FRF.13: Section 6.1 (OutageTime)" ::= { frsldPvcDataEntry 18 } frsldPvcDataUnavailables OBJECT-TYPE SYNTAX Counter32 Steinberger & Nicklass Standards Track [Page 41] RFC 3202 Frame Relay Service Level Defs MIB January 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this PVC was declared unavailable for any reason since this row was created. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by frsldPvcCtrlLastPurgeTime." REFERENCE "FRF.13: Section 6.1 (OutageCount)" ::= { frsldPvcDataEntry 19 } -- The Frame Relay Service Level Definitions PVC Sample Table -- -- This table contains the sampled delay, delivery and -- availability information. frsldPvcSampleTable OBJECT-TYPE SYNTAX SEQUENCE OF FrsldPvcSampleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Frame Relay Service Level Definitions sample table." ::= { frsldObjects 4 } frsldPvcSampleEntry OBJECT-TYPE SYNTAX FrsldPvcSampleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Frame Relay Service Level Definitions data sample table." INDEX { ifIndex, frsldPvcCtrlDlci, frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP, frsldSmplCtrlIdx, frsldPvcSmplIdx } ::= { frsldPvcSampleTable 1 } FrsldPvcSampleEntry ::= SEQUENCE { frsldPvcSmplIdx Integer32, frsldPvcSmplDelayMin Gauge32, frsldPvcSmplDelayMax Gauge32, frsldPvcSmplDelayAvg Gauge32, frsldPvcSmplMissedPolls Gauge32, frsldPvcSmplFrDeliveredC Gauge32, Steinberger & Nicklass Standards Track [Page 42] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcSmplFrDeliveredE Gauge32, frsldPvcSmplFrOfferedC Gauge32, frsldPvcSmplFrOfferedE Gauge32, frsldPvcSmplDataDeliveredC Gauge32, frsldPvcSmplDataDeliveredE Gauge32, frsldPvcSmplDataOfferedC Gauge32, frsldPvcSmplDataOfferedE Gauge32, frsldPvcSmplHCFrDeliveredC CounterBasedGauge64, frsldPvcSmplHCFrDeliveredE CounterBasedGauge64, frsldPvcSmplHCFrOfferedC CounterBasedGauge64, frsldPvcSmplHCFrOfferedE CounterBasedGauge64, frsldPvcSmplHCDataDeliveredC CounterBasedGauge64, frsldPvcSmplHCDataDeliveredE CounterBasedGauge64, frsldPvcSmplHCDataOfferedC CounterBasedGauge64, frsldPvcSmplHCDataOfferedE CounterBasedGauge64, frsldPvcSmplUnavailableTime TimeTicks, frsldPvcSmplUnavailables Gauge32, frsldPvcSmplStartTime TimeStamp, frsldPvcSmplEndTime TimeStamp } frsldPvcSmplIdx OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The bucket index of the current sample. This increments once for each new bucket in the table." ::= { frsldPvcSampleEntry 1 } frsldPvcSmplDelayMin OBJECT-TYPE SYNTAX Gauge32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum delay reported in microseconds measured for any information packet that arrived during this interval. A value of zero means that no data is available." REFERENCE "FRF.13: Section 3.1 (FTD)" ::= { frsldPvcSampleEntry 2 } frsldPvcSmplDelayMax OBJECT-TYPE SYNTAX Gauge32 Steinberger & Nicklass Standards Track [Page 43] RFC 3202 Frame Relay Service Level Defs MIB January 2002 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The largest delay reported in microseconds measured for any information packet that arrived during this interval. A value of zero means that no data is available." REFERENCE "FRF.13: Section 3.1 (FTD)" ::= { frsldPvcSampleEntry 3 } frsldPvcSmplDelayAvg OBJECT-TYPE SYNTAX Gauge32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The average delay reported in microseconds measured for all delay packets that arrived during this interval. A value of zero means that no data is available." REFERENCE "FRF.13: Section 3.1 (FTD)" ::= { frsldPvcSampleEntry 4 } frsldPvcSmplMissedPolls OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of polls that were missed during this interval." ::= { frsldPvcSampleEntry 5 } frsldPvcSmplFrDeliveredC OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR during this interval. If it is the case that the high capacity counters are also used, this MUST report the value of the Steinberger & Nicklass Standards Track [Page 44] RFC 3202 Frame Relay Service Level Defs MIB January 2002 lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCFrDeliveredC." REFERENCE "FRF.13: Section 4.1 (FramesDeliveredc)" ::= { frsldPvcSampleEntry 6 } frsldPvcSmplFrDeliveredE OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been sent in excess of the CIR during this interval. If it is the case that the high capacity counters are also used, this MUST report the value of the lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCFrDeliveredE." REFERENCE "FRF.13: Section 4.1 (FramesDeliverede))" ::= { frsldPvcSampleEntry 7 } frsldPvcSmplFrOfferedC OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were offered through frsldPvcCtrlTransmitRP within CIR during this interval. If it is the case that the high capacity counters are also used, this MUST report the value of the lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCFrOfferedC." REFERENCE "FRF.13: Section 4.1 (FramesOfferedc)" ::= { frsldPvcSampleEntry 8 } frsldPvcSmplFrOfferedE OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were offered through frsldPvcCtrlTransmitRP in excess of the CIR during this interval. Steinberger & Nicklass Standards Track [Page 45] RFC 3202 Frame Relay Service Level Defs MIB January 2002 If it is the case that the high capacity counters are also used, this MUST report the value of the lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCFrOfferedE." REFERENCE "FRF.13: Section 4.1 (FramesOfferede)" ::= { frsldPvcSampleEntry 9 } frsldPvcSmplDataDeliveredC OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR during this interval. If it is the case that the high capacity counters are also used, this MUST report the value of the lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCDataDeliveredC." REFERENCE "FRF.13: Section 5.1 (DataDeliveredc)" ::= { frsldPvcSampleEntry 10 } frsldPvcSmplDataDeliveredE OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlDeliveredRP and determined to have been sent in excess of the CIR during this interval. If it is the case that the high capacity counters are also used, this MUST report the value of the lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCDataDeliveredE." REFERENCE "FRF.13: Section 5.1 (DataDeliverede)" ::= { frsldPvcSampleEntry 11 } frsldPvcSmplDataOfferedC OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through Steinberger & Nicklass Standards Track [Page 46] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcCtrlTransmitRP within CIR during this interval. If it is the case that the high capacity counters are also used, this MUST report the value of the lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCDataOfferredC." REFERENCE "FRF.13: Section 5.1 (DataOfferedc)" ::= { frsldPvcSampleEntry 12 } frsldPvcSmplDataOfferedE OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through frsldPvcCtrlTransmitRP in excess of the CIR during this interval. If it is the case that the high capacity counters are also used, this MUST report the value of the lower 32 bits of the CounterBasedGauge64 value of frsldPvcSmplHCDataOfferedE." REFERENCE "FRF.13: Section 5.1 (DataOfferede)" ::= { frsldPvcSampleEntry 13 } frsldPvcSmplHCFrDeliveredC OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR during this interval. This object is a 64-bit version of frsldPvcSmplFrDeliveredC." REFERENCE "FRF.13: Section 4.1 (FramesDeliveredc)" ::= { frsldPvcSampleEntry 14 } frsldPvcSmplHCFrDeliveredE OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were received at frsldPvcCtrlReceiveRP and determined to have been Steinberger & Nicklass Standards Track [Page 47] RFC 3202 Frame Relay Service Level Defs MIB January 2002 sent in excess of the CIR during this interval. This object is a 64-bit version of frsldPvcSmpl- FrDeliveredE." REFERENCE "FRF.13: Section 4.1 (FramesDeliverede)" ::= { frsldPvcSampleEntry 15 } frsldPvcSmplHCFrOfferedC OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were offered through frsldPvcCtrlTransmitRP within CIR during this interval. This object is a 64-bit version of frsldPvcSmplFrOfferedC." REFERENCE "FRF.13: Section 4.1 (FramesOfferedc)" ::= { frsldPvcSampleEntry 16 } frsldPvcSmplHCFrOfferedE OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were offered through frsldPvcCtrlTransmitRP in excess of the CIR during this interval. This object is a 64-bit version of frsldPvcSmplFrOfferedE." REFERENCE "FRF.13: Section 4.1 (FramesOfferede)" ::= { frsldPvcSampleEntry 17 } frsldPvcSmplHCDataDeliveredC OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlReceiveRP and determined to have been sent within CIR during this interval. This value is a 64-bit version of frsldPvcSmplDataDeliveredC." REFERENCE "FRF.13: Section 5.1 (DataDeliveredc)" ::= { frsldPvcSampleEntry 18 } frsldPvcSmplHCDataDeliveredE OBJECT-TYPE SYNTAX CounterBasedGauge64 Steinberger & Nicklass Standards Track [Page 48] RFC 3202 Frame Relay Service Level Defs MIB January 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were received at frsldPvcCtrlReceiveRP and determined to have been sent in excess of the CIR during this interval. This value is a 64-bit version of frsldPvcSmplData- DeliveredE." REFERENCE "FRF.13: Section 5.1 (DataDeliverede)" ::= { frsldPvcSampleEntry 19 } frsldPvcSmplHCDataOfferedC OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through frsldPvcCtrlTransmitRP within CIR during this interval. This value is a 64-bit version of frsldPvcSmplDataOfferedC." REFERENCE "FRF.13: Section 5.1 (DataOfferedc)" ::= { frsldPvcSampleEntry 20 } frsldPvcSmplHCDataOfferedE OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that were offered through frsldPvcCtrlTransmitRP in excess of the CIR during this interval. This object is a 64-bit version of frsldPvcSmplDataOfferedE." REFERENCE "FRF.13: Section 5.1 (DataOfferede)" ::= { frsldPvcSampleEntry 21 } frsldPvcSmplUnavailableTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time this PVC was declared unavailable for any reason during this interval." REFERENCE "FRF.13: Section 6.1 (OutageTime)" ::= { frsldPvcSampleEntry 22 } Steinberger & Nicklass Standards Track [Page 49] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcSmplUnavailables OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this PVC was declared unavailable for any reason during this interval." REFERENCE "FRF.13: Section 6.1 (OutageCount)" ::= { frsldPvcSampleEntry 23 } frsldPvcSmplStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this sample interval started." ::= { frsldPvcSampleEntry 24 } frsldPvcSmplEndTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this sample interval ended. No data will be reported and the row will not appear in the table until the sample has been collected." ::= { frsldPvcSampleEntry 25 } -- Capabilities Group -- This group provides capabilities objects for the tables -- that control configuration. frsldPvcCtrlWriteCaps OBJECT-TYPE SYNTAX BITS { frsldPvcCtrlStatus(0), frsldPvcCtrlPacketFreq(1), frsldPvcCtrlDelayFrSize(2), frsldPvcCtrlDelayType(3), frsldPvcCtrlDelayTimeOut(4), frsldPvcCtrlPurge(5), frsldPvcCtrlDeleteOnPurge(6) } MAX-ACCESS read-only STATUS current DESCRIPTION Steinberger & Nicklass Standards Track [Page 50] RFC 3202 Frame Relay Service Level Defs MIB January 2002 "This object specifies the write capabilities for the read-create objects of the PVC Control table. If the corresponding bit is enabled (1), the agent supports writes to that object." ::= { frsldCapabilities 1 } frsldSmplCtrlWriteCaps OBJECT-TYPE SYNTAX BITS { frsldSmplCtrlStatus(0), frsldSmplCtrlBuckets(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the write capabilities for the read-create objects of the Sample Control table. If the corresponding bit is enabled (1), the agent supports writes to that object." ::= { frsldCapabilities 2 } frsldRPCaps OBJECT-TYPE SYNTAX BITS { srcLocalRP(0), ingTxLocalRP(1), tpTxLocalRP(2), eqiTxLocalRP(3), eqoTxLocalRP(4), otherTxLocalRP(5), srcRemoteRP(6), ingTxRemoteRP(7), tpTxRemoteRP(8), eqiTxRemoteRP(9), eqoTxRemoteRP(10), otherTxRemoteRP(11), desLocalRP(12), ingRxLocalRP(13), tpRxLocalRP(14), eqiRxLocalRP(15), eqoRxLocalRP(16), otherRxLocalRP(17), desRemoteRP(18), ingRxRemoteRP(19), tpRxRemoteRP(20), eqiRxRemoteRP(21), eqoRxRemoteRP(22), otherRxRemoteRP(23) } MAX-ACCESS read-only Steinberger & Nicklass Standards Track [Page 51] RFC 3202 Frame Relay Service Level Defs MIB January 2002 STATUS current DESCRIPTION "This object specifies the reference points that the agent supports. This object allows the management application to discover which rows can be created on a specific device." ::= { frsldCapabilities 3 } frsldMaxPvcCtrls OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of control rows that can be created in frsldPvcCtrlTable. Sets to this object lower than the current value of frsldNumPvcCtrls should result in inconsistentValue." ::= { frsldCapabilities 4 } frsldNumPvcCtrls OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of rows in frsldPvcCtrlTable." ::= { frsldCapabilities 5 } frsldMaxSmplCtrls OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of control rows that can be created in frsldSmplCtrlTable. Sets to this object lower than the current value of frsldNumSmplCtrls should result in inconsistentValue." ::= { frsldCapabilities 6 } frsldNumSmplCtrls OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of rows in frsldSmplCtrlTable." ::= { frsldCapabilities 7 } -- Conformance Information Steinberger & Nicklass Standards Track [Page 52] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldMIBGroups OBJECT IDENTIFIER ::= { frsldConformance 1 } frsldMIBCompliances OBJECT IDENTIFIER ::= { frsldConformance 2 } -- -- Compliance Statements -- frsldCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which support with Frame Relay Service Level Definitions. This group defines the minimum level of support required for compliance." MODULE -- this module MANDATORY-GROUPS { frsldPvcReqCtrlGroup, frsldPvcReqDataGroup, frsldCapabilitiesGroup} GROUP frsldPvcHCFrameDataGroup DESCRIPTION "This group is mandatory only for those network interfaces with corresponding instance of ifSpeed greater than 650,000,000 bits/second." GROUP frsldPvcHCOctetDataGroup DESCRIPTION "This group is mandatory only for those network interfaces with corresponding instance of ifSpeed greater than 650,000,000 bits/second." GROUP frsldPvcPacketGroup DESCRIPTION "This group is optional. Network interfaces that allow control of the packets used to collect information are encouraged to implement this group." GROUP frsldPvcDelayCtrlGroup DESCRIPTION "This group is optional. Network interfaces that offer control of the delay measurement are strongly encouraged to implement this group." GROUP frsldPvcSampleCtrlGroup DESCRIPTION "This group is mandatory only for those network Steinberger & Nicklass Standards Track [Page 53] RFC 3202 Frame Relay Service Level Defs MIB January 2002 interfaces that allow data sampling." GROUP frsldPvcDelayDataGroup DESCRIPTION "This group is only mandatory when frsldPvcDelayCtrlGroup is implemented. It is strongly encouraged that any device capable of measuring delay implement this group." GROUP frsldPvcSampleDelayGroup DESCRIPTION "This group is only mandatory when both frsldPvcSampleCtrlGroup and frsldPvcDelayDataGroup are supported." GROUP frsldPvcSampleDataGroup DESCRIPTION "This group is mandatory whenever frsldPvcSampleCtrlGroup is supported." GROUP frsldPvcSampleHCFrameGroup DESCRIPTION "This group is mandatory whenever both frsldPvcSampleCtrlGroup and frsldPvcHCFrameDataGroup are supported." GROUP frsldPvcSampleHCDataGroup DESCRIPTION "This group is mandatory whenever both frsldPvcSampleCtrlGroup and frsldPvcHCOctetDataGroup are supported." GROUP frsldPvcSampleAvailGroup DESCRIPTION "This group is mandatory whenever frsldPvcSampleCtrlGroup is supported." GROUP frsldPvcSampleGeneralGroup DESCRIPTION "This group is mandatory whenever frsldPvcSampleCtrlGroup is supported." OBJECT frsldPvcCtrlStatus SYNTAX RowStatus { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Row creation can be done outside of the scope of the SNMP protocol. If this object is implemented Steinberger & Nicklass Standards Track [Page 54] RFC 3202 Frame Relay Service Level Defs MIB January 2002 with max-access of read-only, then the only value that MUST be returned is active(1) and frsldPvcCtrlWriteCaps MUST return 0 for the frsldPvcCtrlStatus(0) bit." OBJECT frsldPvcCtrlPurge MIN-ACCESS read-only DESCRIPTION "Write access is not required. If this object is implemented with a max-access of read-only, then the frsldPvcCtrlPurge(5) bit must return 0." OBJECT frsldPvcCtrlDeleteOnPurge MIN-ACCESS read-only DESCRIPTION "Write access is not required. If this object is implemented with a max-access of read-only, then the frsldPvcCtrlDeleteOnPurge(6) bit must return 0." OBJECT frsldMaxPvcCtrls MIN-ACCESS read-only DESCRIPTION "Write access is not required if the device either dynamically allocates memory or statically allocates a fixed number of entries. In the case of static allocation, the device should always report the correct maximum number of controls. In the case of dynamic allocation, the device SHOULD always report a number greater than frsldNumPvcCtrls when allocation is possible and a number equal to frsldNumPvcCtrls when allocation is not possible." OBJECT frsldMaxSmplCtrls MIN-ACCESS read-only DESCRIPTION "Write access is not required if the device either dynamically allocates memory or statically allocates a fixed number of entries. In the case of static allocation, the device should always report the correct maximum number of controls. In the case of dynamic allocation, the device SHOULD always report a number greater than frsldNumSmplCtrls when allocation is possible and a number equal to frsldNumSmplCtrls when allocation is not possible." ::= { frsldMIBCompliances 1 } -- Steinberger & Nicklass Standards Track [Page 55] RFC 3202 Frame Relay Service Level Defs MIB January 2002 -- Units of Conformance -- frsldPvcReqCtrlGroup OBJECT-GROUP OBJECTS { frsldPvcCtrlStatus, frsldPvcCtrlPurge, frsldPvcCtrlDeleteOnPurge, frsldPvcCtrlLastPurgeTime } STATUS current DESCRIPTION "A collection of required objects providing control information applicable to a PVC which implements Service Level Definitions." ::= { frsldMIBGroups 1 } frsldPvcPacketGroup OBJECT-GROUP OBJECTS { frsldPvcCtrlPacketFreq } STATUS current DESCRIPTION "A collection of optional objects providing packet level control information applicable to a PVC which implements Service Level Definitions." ::= { frsldMIBGroups 2 } frsldPvcDelayCtrlGroup OBJECT-GROUP OBJECTS { frsldPvcCtrlDelayFrSize, frsldPvcCtrlDelayType, frsldPvcCtrlDelayTimeOut } STATUS current DESCRIPTION "A collection of optional objects providing delay control information applicable to a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcPacketGroup and frsldPvcDelayDataGroup MUST also be implemented." ::= { frsldMIBGroups 3 } frsldPvcSampleCtrlGroup OBJECT-GROUP OBJECTS { frsldSmplCtrlStatus, frsldSmplCtrlColPeriod, frsldSmplCtrlBuckets, Steinberger & Nicklass Standards Track [Page 56] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldSmplCtrlBucketsGranted } STATUS current DESCRIPTION "A collection of optional objects providing sample control information applicable to a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcReqDataGroup and frsldPvcSampleGeneralGroup MUST also be implemented." ::= { frsldMIBGroups 4 } frsldPvcReqDataGroup OBJECT-GROUP OBJECTS { frsldPvcDataFrDeliveredC, frsldPvcDataFrDeliveredE, frsldPvcDataFrOfferedC, frsldPvcDataFrOfferedE, frsldPvcDataDataDeliveredC, frsldPvcDataDataDeliveredE, frsldPvcDataDataOfferedC, frsldPvcDataDataOfferedE, frsldPvcDataUnavailableTime, frsldPvcDataUnavailables } STATUS current DESCRIPTION "A collection of required objects providing data collected on a PVC which implements Service Level Definitions." ::= { frsldMIBGroups 5 } frsldPvcDelayDataGroup OBJECT-GROUP OBJECTS { frsldPvcDataMissedPolls } STATUS current DESCRIPTION "A collection of optional objects providing delay data collected on a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcDelayCtrlGroup MUST also be implemented." ::= { frsldMIBGroups 6 } frsldPvcHCFrameDataGroup OBJECT-GROUP Steinberger & Nicklass Standards Track [Page 57] RFC 3202 Frame Relay Service Level Defs MIB January 2002 OBJECTS { frsldPvcDataHCFrDeliveredC, frsldPvcDataHCFrDeliveredE, frsldPvcDataHCFrOfferedC, frsldPvcDataHCFrOfferedE } STATUS current DESCRIPTION "A collection of optional objects providing high capacity frame data collected on a PVC which implements Service Level Definitions." ::= { frsldMIBGroups 7 } frsldPvcHCOctetDataGroup OBJECT-GROUP OBJECTS { frsldPvcDataHCDataDeliveredC, frsldPvcDataHCDataDeliveredE, frsldPvcDataHCDataOfferedC, frsldPvcDataHCDataOfferedE } STATUS current DESCRIPTION "A collection of optional objects providing high capacity octet data collected on a PVC which implements Service Level Definitions." ::= { frsldMIBGroups 8 } frsldPvcSampleDelayGroup OBJECT-GROUP OBJECTS { frsldPvcSmplDelayMin, frsldPvcSmplDelayMax, frsldPvcSmplDelayAvg, frsldPvcSmplMissedPolls } STATUS current DESCRIPTION "A collection of optional objects providing delay sample data collected on a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcDelayCtrlGroup MUST also be implemented." ::= { frsldMIBGroups 9 } frsldPvcSampleDataGroup OBJECT-GROUP OBJECTS { frsldPvcSmplFrDeliveredC, frsldPvcSmplFrDeliveredE, Steinberger & Nicklass Standards Track [Page 58] RFC 3202 Frame Relay Service Level Defs MIB January 2002 frsldPvcSmplFrOfferedC, frsldPvcSmplFrOfferedE, frsldPvcSmplDataDeliveredC, frsldPvcSmplDataDeliveredE, frsldPvcSmplDataOfferedC, frsldPvcSmplDataOfferedE } STATUS current DESCRIPTION "A collection of optional objects providing data and frame delivery sample data collected on a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcReqDataGroup MUST also be implemented." ::= { frsldMIBGroups 10 } frsldPvcSampleHCFrameGroup OBJECT-GROUP OBJECTS { frsldPvcSmplHCFrDeliveredC, frsldPvcSmplHCFrDeliveredE, frsldPvcSmplHCFrOfferedC, frsldPvcSmplHCFrOfferedE } STATUS current DESCRIPTION "A collection of optional objects providing high capacity frame delivery sample data collected on a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcHCFrameDataGroup MUST also be implemented." ::= { frsldMIBGroups 11 } frsldPvcSampleHCDataGroup OBJECT-GROUP OBJECTS { frsldPvcSmplHCDataDeliveredC, frsldPvcSmplHCDataDeliveredE, frsldPvcSmplHCDataOfferedC, frsldPvcSmplHCDataOfferedE } STATUS current DESCRIPTION "A collection of optional objects providing high capacity data delivery sample data collected on a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcHCOctetDataGroup Steinberger & Nicklass Standards Track [Page 59] RFC 3202 Frame Relay Service Level Defs MIB January 2002 MUST also be implemented." ::= { frsldMIBGroups 12 } frsldPvcSampleAvailGroup OBJECT-GROUP OBJECTS { frsldPvcSmplUnavailableTime, frsldPvcSmplUnavailables } STATUS current DESCRIPTION "A collection of optional objects providing availability sample data collected on a PVC which implements Service Level Definitions. If this group is implemented, frsldPvcReqDataGroup MUST also be implemented." ::= { frsldMIBGroups 13 } frsldPvcSampleGeneralGroup OBJECT-GROUP OBJECTS { frsldPvcSmplStartTime, frsldPvcSmplEndTime } STATUS current DESCRIPTION "A collection of optional objects providing general sample data collected on a PVC which implements Service Level Definitions." ::= { frsldMIBGroups 14 } frsldCapabilitiesGroup OBJECT-GROUP OBJECTS { frsldPvcCtrlWriteCaps, frsldSmplCtrlWriteCaps, frsldRPCaps, frsldMaxPvcCtrls, frsldNumPvcCtrls, frsldMaxSmplCtrls, frsldNumSmplCtrls } STATUS current DESCRIPTION "A collection of required objects providing capability information and control for this MIB module." ::= { frsldMIBGroups 15 } END Steinberger & Nicklass Standards Track [Page 60] RFC 3202 Frame Relay Service Level Defs MIB January 2002 8. Acknowledgments This document was produced by the Frame Relay Service MIB Working Group. It is based on the Frame Relay Forum's implementation agreement on service level definitions, FRF.13 [17]. The editors would like to thank the following people for their helpful comments: o Ken Rehbehn, Visual Networks o Santa Dasu, Quick Eagle Networks 9. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Steinberger & Nicklass Standards Track [Page 61] RFC 3202 Frame Relay Service Level Defs MIB January 2002 [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [17] Frame Relay Forum Technical Committee, "Service Level Definitions Implementations Agreement", FRF.13, August 1998. [18] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for Frame Relay Service", RFC 2954, October 2000. [19] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [20] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [21] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Steinberger & Nicklass Standards Track [Page 62] RFC 3202 Frame Relay Service Level Defs MIB January 2002 10. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. Authors' Addresses Robert Steinberger Fujitsu Network Communications 2801 Telecom Parkway Richardson, TX 75082 Phone: 1-972-479-4739 EMail: robert.steinberger@fnc.fujitsu.com Orly Nicklass, Ph.D RAD Data Communications Ltd. 12 Hanechoshet Street Tel Aviv, Israel 69710 Phone: 972 3 7659969 EMail: Orly_n@rad.co.il Steinberger & Nicklass Standards Track [Page 63] RFC 3202 Frame Relay Service Level Defs MIB January 2002 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Steinberger & Nicklass Standards Track [Page 64] snmp-mibs-downloader-1.1/mibrfcs/rfc3231.txt0000644000000000000000000016757411402176071015576 0ustar Network Working Group D. Levi Request for Comments: 3231 Nortel Networks Obsoletes: 2591 J. Schoenwaelder Category: Standards Track TU Braunschweig January 2002 Definitions of Managed Objects for Scheduling Management Operations 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. This document obsoletes RFC 2591. Table of Contents 1 Introduction ................................................. 2 2 The SNMP Management Framework ................................ 2 3 Overview ..................................................... 3 3.1 Periodic Schedules ......................................... 4 3.2 Calendar Schedules ......................................... 4 3.3 One-shot Schedules ......................................... 5 3.4 Time Transitions ........................................... 5 3.5 Actions .................................................... 5 4 Definitions .................................................. 6 5 Usage Examples ............................................... 20 5.1 Starting a script to ping devices every 20 minutes ......... 20 5.2 Starting a script at the next Friday the 13th .............. 21 5.3 Turning an interface off during weekends ................... 22 Levi & Schoenwaelder Standards Track [Page 1] RFC 3231 Schedule MIB January 2002 6 Security Considerations ...................................... 23 7 Intellectual Property ........................................ 25 8 Changes from RFC 2591 ........................................ 25 9 Acknowledgments .............................................. 26 10 References .................................................. 26 11 Editors' Addresses .......................................... 28 12 Full Copyright Statement .................................... 29 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. Levi & Schoenwaelder Standards Track [Page 2] RFC 3231 Schedule MIB January 2002 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview The MIB defined in this memo provides the scheduling of actions periodically or at specified dates and times. The actions can be used to realize on-duty / off-duty schedules or to trigger management functions in a distributed management application. Schedules can be enabled or disabled by modifying a control object. This allows for pre-configured schedules which are activated or deactivated by some other management functions. The term `scheduler' is used throughout this memo to refer to the entity which implements the scheduling MIB and which invokes the actions at the specified points in time. Levi & Schoenwaelder Standards Track [Page 3] RFC 3231 Schedule MIB January 2002 3.1. Periodic Schedules Periodic schedules are based on fixed time periods between the initiation of scheduled actions. Periodic schedules are defined by specifying the number of seconds between two initiations. The time needed to complete the action is usually not known by the scheduler and does therefore not influence the next scheduling point. Implementations must guarantee that action invocations will not occur before their next scheduled time. However, implementations may be forced to delay invocations in the face of local constraints (e.g., a heavy load on higher-priority tasks). An accumulation of such delays would result in a drift of the scheduling interval with respect to time, and should be avoided. Scheduled actions collecting statistical data should retrieve time stamps from the data source and not rely on the accuracy of the periodic scheduler in order to obtain accurate statistics. 3.2. Calendar Schedules Calendar schedules trigger scheduled actions at specified days of the week and days of the month. Calendar schedules are therefore aware of the notion of months, days, weekdays, hours and minutes. It is possible to specify multiple values for each calendar item. This provides a mechanism for defining complex schedules. For example, a schedule could be defined which triggers an action every 15 minutes on a given weekday. Months, days and weekdays are specified using the objects schedMonth, schedDay and schedWeekDay of type BITS. Setting multiple bits to one in these objects causes an OR operation. For example, setting the bits monday(1) and friday(5) in schedWeekDay restricts the schedule to Mondays and Fridays. The bit fields for schedMonth, schedDay and schedWeekDay are combined using an AND operation. For example, setting the bits june(5) and july(6) in schedMonth and combining it with the bits monday(1) and friday(5) set in schedWeekDay will result in a schedule which is restricted to every Monday and Friday in the months June and July. Wildcarding of calendar items is achieved by setting all bits to one. It is possible to define calendar schedules that will never trigger an action. For example, one can define a calendar schedule which should trigger an action on February 31st. Schedules like this will simply be ignored by the scheduler. Levi & Schoenwaelder Standards Track [Page 4] RFC 3231 Schedule MIB January 2002 Finally, calendar schedules are always expressed in local time. A scalar, schedLocalTime, is provided so that a manager can retrieve the notion of local time and the offset to GMT time. 3.3. One-shot Schedules One-shot Schedules are similar to calendar schedules. The difference between a calendar schedule and a one-shot schedule is that a one- shot schedule will automatically disable itself once an action has been invoked. 3.4. Time Transitions A time transition occurs when the Schedule MIB's notion of time (as reported by schedLocalTime) is changed so that time continuity is lost. Time transitions may be caused by daylight savings times or administrative changes of the system's notion of time. There are two possible situations when a time transition occurs. First, time may be set backwards, in which case particular times will appear to occur twice. These are called 'ambiguous times'. Second, time may be set forwards, in which case particular times will not occur. These are called 'nonexistent times'. When an action is configured in the Schedule MIB to occur at an ambiguous time, the action will be invoked at all occurrences of the ambiguous time. For example, if an action is scheduled to occur at 2:10 am, and a time transition occurs at 3:00 am which sets the clock back to 2:00 am, the action will be invoked twice. When an action is configured in the Schedule MIB to occur at a nonexistent time, the action will not be invoked at all. For example, if an action is scheduled to occur at 2:10 am, and a time transition occurs at 2:00 am which sets the clock to 3:00 am, the action will not be invoked. 3.5. Actions Scheduled actions are modeled by SNMP set operations on local MIB variables. Scheduled actions described in this MIB are further restricted to objects of type INTEGER. This restriction does not limit the usefulness of the MIB. Simple schedules such as on-duty / off-duty schedules for resources that have a status MIB object (e.g. ifAdminStatus) are possible. Levi & Schoenwaelder Standards Track [Page 5] RFC 3231 Schedule MIB January 2002 More complex actions can be realized by triggering a management script which is responsible for performing complex state transitions. A management script can also be used to perform SNMP set operations on remote SNMP engines. 4. Definitions DISMAN-SCHEDULE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, mib-2, zeroDotZero FROM SNMPv2-SMI TEXTUAL-CONVENTION, DateAndTime, RowStatus, StorageType, VariablePointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; schedMIB MODULE-IDENTITY LAST-UPDATED "200201070000Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "WG EMail: disman@dorothy.bmc.com Subscribe: disman-request@dorothy.bmc.com Chair: Randy Presuhn BMC Software, Inc. Postal: Office 1-3141 2141 North First Street San Jose, California 95131 USA EMail: rpresuhn@bmc.com Phone: +1 408 546-1006 Editor: David B. Levi Nortel Networks Postal: 4401 Great America Parkway Santa Clara, CA 95052-8185 USA EMail: dlevi@nortelnetworks.com Phone: +1 865 686 0432 Levi & Schoenwaelder Standards Track [Page 6] RFC 3231 Schedule MIB January 2002 Editor: Juergen Schoenwaelder TU Braunschweig Postal: Bueltenweg 74/75 38106 Braunschweig Germany EMail: schoenw@ibr.cs.tu-bs.de Phone: +49 531 391-3283" DESCRIPTION "This MIB module defines a MIB which provides mechanisms to schedule SNMP set operations periodically or at specific points in time." REVISION "200201070000Z" DESCRIPTION "Revised version, published as RFC 3231. This revision introduces a new object type called schedTriggers. Created new conformance and compliance statements that take care of the new schedTriggers object. Several clarifications have been added to remove ambiguities that were discovered and reported by implementors." REVISION "199811171800Z" DESCRIPTION "Initial version, published as RFC 2591." ::= { mib-2 63 } -- -- The various groups defined within this MIB definition: -- schedObjects OBJECT IDENTIFIER ::= { schedMIB 1 } schedNotifications OBJECT IDENTIFIER ::= { schedMIB 2 } schedConformance OBJECT IDENTIFIER ::= { schedMIB 3 } -- -- Textual Conventions: -- SnmpPduErrorStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC enumerates the SNMPv1 and SNMPv2 PDU error status codes as defined in RFC 1157 and RFC 1905. It also adds a pseudo error status code `noResponse' which indicates a timeout condition." SYNTAX INTEGER { noResponse(-1), noError(0), Levi & Schoenwaelder Standards Track [Page 7] RFC 3231 Schedule MIB January 2002 tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) } -- -- Some scalars which provide information about the local time zone. -- schedLocalTime OBJECT-TYPE SYNTAX DateAndTime (SIZE (11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local time used by the scheduler. Schedules which refer to calendar time will use the local time indicated by this object. An implementation MUST return all 11 bytes of the DateAndTime textual-convention so that a manager may retrieve the offset from GMT time." ::= { schedObjects 1 } -- -- The schedule table which controls the scheduler. -- schedTable OBJECT-TYPE SYNTAX SEQUENCE OF SchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines scheduled actions triggered by SNMP set operations." ::= { schedObjects 2 } Levi & Schoenwaelder Standards Track [Page 8] RFC 3231 Schedule MIB January 2002 schedEntry OBJECT-TYPE SYNTAX SchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular scheduled action. Unless noted otherwise, writable objects of this row can be modified independent of the current value of schedRowStatus, schedAdminStatus and schedOperStatus. In particular, it is legal to modify schedInterval and the objects in the schedCalendarGroup when schedRowStatus is active and schedAdminStatus and schedOperStatus are both enabled." INDEX { schedOwner, schedName } ::= { schedTable 1 } SchedEntry ::= SEQUENCE { schedOwner SnmpAdminString, schedName SnmpAdminString, schedDescr SnmpAdminString, schedInterval Unsigned32, schedWeekDay BITS, schedMonth BITS, schedDay BITS, schedHour BITS, schedMinute BITS, schedContextName SnmpAdminString, schedVariable VariablePointer, schedValue Integer32, schedType INTEGER, schedAdminStatus INTEGER, schedOperStatus INTEGER, schedFailures Counter32, schedLastFailure SnmpPduErrorStatus, schedLastFailed DateAndTime, schedStorageType StorageType, schedRowStatus RowStatus, schedTriggers Counter32 } schedOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this scheduling entry. The exact semantics of this string are subject to the security policy defined by Levi & Schoenwaelder Standards Track [Page 9] RFC 3231 Schedule MIB January 2002 the security administrator." ::= { schedEntry 1 } schedName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally-unique, administratively assigned name for this scheduling entry. This object allows a schedOwner to have multiple entries in the schedTable." ::= { schedEntry 2 } schedDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The human readable description of the purpose of this scheduling entry." DEFVAL { "" } ::= { schedEntry 3 } schedInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between two action invocations of a periodic scheduler. Implementations must guarantee that action invocations will not occur before at least schedInterval seconds have passed. The scheduler must ignore all periodic schedules that have a schedInterval value of 0. A periodic schedule with a scheduling interval of 0 seconds will therefore never invoke an action. Implementations may be forced to delay invocations in the face of local constraints. A scheduled management function should therefore not rely on the accuracy provided by the scheduler implementation. Note that implementations which maintain a list of pending activations must re-calculate them when this object is changed." DEFVAL { 0 } Levi & Schoenwaelder Standards Track [Page 10] RFC 3231 Schedule MIB January 2002 ::= { schedEntry 4 } schedWeekDay OBJECT-TYPE SYNTAX BITS { sunday(0), monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), saturday(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of weekdays on which the scheduled action should take place. Setting multiple bits will include several weekdays in the set of possible weekdays for this schedule. Setting all bits will cause the scheduler to ignore the weekday. Note that implementations which maintain a list of pending activations must re-calculate them when this object is changed." DEFVAL { {} } ::= { schedEntry 5 } schedMonth OBJECT-TYPE SYNTAX BITS { january(0), february(1), march(2), april(3), may(4), june(5), july(6), august(7), september(8), october(9), november(10), december(11) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of months during which the scheduled action should take place. Setting multiple bits will include several months in the set of possible months for this schedule. Levi & Schoenwaelder Standards Track [Page 11] RFC 3231 Schedule MIB January 2002 Setting all bits will cause the scheduler to ignore the month. Note that implementations which maintain a list of pending activations must re-calculate them when this object is changed." DEFVAL { {} } ::= { schedEntry 6 } schedDay OBJECT-TYPE SYNTAX BITS { d1(0), d2(1), d3(2), d4(3), d5(4), d6(5), d7(6), d8(7), d9(8), d10(9), d11(10), d12(11), d13(12), d14(13), d15(14), d16(15), d17(16), d18(17), d19(18), d20(19), d21(20), d22(21), d23(22), d24(23), d25(24), d26(25), d27(26), d28(27), d29(28), d30(29), d31(30), r1(31), r2(32), r3(33), r4(34), r5(35), r6(36), r7(37), r8(38), r9(39), r10(40), r11(41), r12(42), r13(43), r14(44), r15(45), r16(46), r17(47), r18(48), r19(49), r20(50), r21(51), r22(52), r23(53), r24(54), r25(55), r26(56), r27(57), r28(58), r29(59), r30(60), r31(61) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of days in a month on which a scheduled action should take place. There are two sets of bits one can use to define the day within a month: Enumerations starting with the letter 'd' indicate a day in a month relative to the first day of a month. The first day of the month can therefore be specified by setting the bit d1(0) and d31(30) means the last day of a month with 31 days. Enumerations starting with the letter 'r' indicate a day in a month in reverse order, relative to the last day of a month. The last day in the month can therefore be specified by setting the bit r1(31) and r31(61) means the first day of a month with 31 days. Setting multiple bits will include several days in the set of possible days for this schedule. Setting all bits will cause the scheduler to ignore the day within a month. Levi & Schoenwaelder Standards Track [Page 12] RFC 3231 Schedule MIB January 2002 Setting all bits starting with the letter 'd' or the letter 'r' will also cause the scheduler to ignore the day within a month. Note that implementations which maintain a list of pending activations must re-calculate them when this object is changed." DEFVAL { {} } ::= { schedEntry 7 } schedHour OBJECT-TYPE SYNTAX BITS { h0(0), h1(1), h2(2), h3(3), h4(4), h5(5), h6(6), h7(7), h8(8), h9(9), h10(10), h11(11), h12(12), h13(13), h14(14), h15(15), h16(16), h17(17), h18(18), h19(19), h20(20), h21(21), h22(22), h23(23) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of hours within a day during which the scheduled action should take place. Note that implementations which maintain a list of pending activations must re-calculate them when this object is changed." DEFVAL { {} } ::= { schedEntry 8 } schedMinute OBJECT-TYPE SYNTAX BITS { m0(0), m1(1), m2(2), m3(3), m4(4), m5(5), m6(6), m7(7), m8(8), m9(9), m10(10), m11(11), m12(12), m13(13), m14(14), m15(15), m16(16), m17(17), m18(18), m19(19), m20(20), m21(21), m22(22), m23(23), m24(24), m25(25), m26(26), m27(27), m28(28), m29(29), m30(30), m31(31), m32(32), m33(33), m34(34), m35(35), m36(36), m37(37), m38(38), m39(39), m40(40), m41(41), m42(42), m43(43), m44(44), m45(45), m46(46), m47(47), m48(48), m49(49), m50(50), m51(51), m52(52), m53(53), m54(54), m55(55), m56(56), m57(57), m58(58), m59(59) } MAX-ACCESS read-create STATUS current DESCRIPTION Levi & Schoenwaelder Standards Track [Page 13] RFC 3231 Schedule MIB January 2002 "The set of minutes within an hour when the scheduled action should take place. Note that implementations which maintain a list of pending activations must re-calculate them when this object is changed." DEFVAL { {} } ::= { schedEntry 9 } schedContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The context which contains the local MIB variable pointed to by schedVariable." DEFVAL { "" } ::= { schedEntry 10 } schedVariable OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "An object identifier pointing to a local MIB variable which resolves to an ASN.1 primitive type of INTEGER." DEFVAL { zeroDotZero } ::= { schedEntry 11 } schedValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value which is written to the MIB object pointed to by schedVariable when the scheduler invokes an action. The implementation shall enforce the use of access control rules when performing the set operation on schedVariable. This is accomplished by calling the isAccessAllowed abstract service interface as defined in RFC 2571. Note that an implementation may choose to issue an SNMP Set message to the SNMP engine and leave the access control decision to the normal message processing procedure." DEFVAL { 0 } ::= { schedEntry 12 } schedType OBJECT-TYPE Levi & Schoenwaelder Standards Track [Page 14] RFC 3231 Schedule MIB January 2002 SYNTAX INTEGER { periodic(1), calendar(2), oneshot(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of this schedule. The value periodic(1) indicates that this entry specifies a periodic schedule. A periodic schedule is defined by the value of schedInterval. The values of schedWeekDay, schedMonth, schedDay, schedHour and schedMinute are ignored. The value calendar(2) indicates that this entry describes a calendar schedule. A calendar schedule is defined by the values of schedWeekDay, schedMonth, schedDay, schedHour and schedMinute. The value of schedInterval is ignored. A calendar schedule will trigger on all local times that satisfy the bits set in schedWeekDay, schedMonth, schedDay, schedHour and schedMinute. The value oneshot(3) indicates that this entry describes a one-shot schedule. A one-shot schedule is similar to a calendar schedule with the additional feature that it disables itself by changing in the `finished' schedOperStatus once the schedule triggers an action. Note that implementations which maintain a list of pending activations must re-calculate them when this object is changed." DEFVAL { periodic } ::= { schedEntry 13 } schedAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the schedule." DEFVAL { disabled } ::= { schedEntry 14 } schedOperStatus OBJECT-TYPE SYNTAX INTEGER { Levi & Schoenwaelder Standards Track [Page 15] RFC 3231 Schedule MIB January 2002 enabled(1), disabled(2), finished(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this schedule. The state enabled(1) indicates this entry is active and that the scheduler will invoke actions at appropriate times. The disabled(2) state indicates that this entry is currently inactive and ignored by the scheduler. The finished(3) state indicates that the schedule has ended. Schedules in the finished(3) state are ignored by the scheduler. A one-shot schedule enters the finished(3) state when it deactivates itself. Note that the operational state must not be enabled(1) when the schedRowStatus is not active." ::= { schedEntry 15 } schedFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable counts the number of failures while invoking the scheduled action. This counter at most increments once for a triggered action." ::= { schedEntry 16 } schedLastFailure OBJECT-TYPE SYNTAX SnmpPduErrorStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent error that occurred during the invocation of a scheduled action. The value noError(0) is returned if no errors have occurred yet." DEFVAL { noError } ::= { schedEntry 17 } schedLastFailed OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the most recent failure occurred. Levi & Schoenwaelder Standards Track [Page 16] RFC 3231 Schedule MIB January 2002 The value '0000000000000000'H is returned if no failure occurred since the last re-initialization of the scheduler." DEFVAL { '0000000000000000'H } ::= { schedEntry 18 } schedStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this scheduled action is kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. Conceptual rows having the value `permanent' must allow write access to the columnar objects schedDescr, schedInterval, schedContextName, schedVariable, schedValue, and schedAdminStatus. If an implementation supports the schedCalendarGroup, write access must be also allowed to the columnar objects schedWeekDay, schedMonth, schedDay, schedHour, schedMinute." DEFVAL { volatile } ::= { schedEntry 19 } schedRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this scheduled action. A control that allows entries to be added and removed from this table. Note that the operational state must change to enabled when the administrative state is enabled and the row status changes to active(1). Attempts to destroy(6) a row or to set a row notInService(2) while the operational state is enabled result in inconsistentValue errors. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { schedEntry 20 } schedTriggers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Levi & Schoenwaelder Standards Track [Page 17] RFC 3231 Schedule MIB January 2002 DESCRIPTION "This variable counts the number of attempts (either successful or failed) to invoke the scheduled action." ::= { schedEntry 21 } -- -- Notifications that are emitted to indicate failures. The -- definition of schedTraps makes notification registrations -- reversible (see STD 58, RFC 2578). -- schedTraps OBJECT IDENTIFIER ::= { schedNotifications 0 } schedActionFailure NOTIFICATION-TYPE OBJECTS { schedLastFailure, schedLastFailed } STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails." ::= { schedTraps 1 } -- conformance information schedCompliances OBJECT IDENTIFIER ::= { schedConformance 1 } schedGroups OBJECT IDENTIFIER ::= { schedConformance 2 } -- compliance statements schedCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the scheduling MIB." MODULE -- this module MANDATORY-GROUPS { schedGroup2, schedNotificationsGroup } GROUP schedCalendarGroup DESCRIPTION "The schedCalendarGroup is mandatory only for those implementations that support calendar based schedules." OBJECT schedType DESCRIPTION "The values calendar(2) or oneshot(3) are not valid for implementations that do not implement the schedCalendarGroup. Such an implementation must return inconsistentValue error responses for attempts to set schedAdminStatus to calendar(2) or oneshot(3)." Levi & Schoenwaelder Standards Track [Page 18] RFC 3231 Schedule MIB January 2002 ::= { schedCompliances 2 } schedGroup2 OBJECT-GROUP OBJECTS { schedDescr, schedInterval, schedContextName, schedVariable, schedValue, schedType, schedAdminStatus, schedOperStatus, schedFailures, schedLastFailure, schedLastFailed, schedStorageType, schedRowStatus, schedTriggers } STATUS current DESCRIPTION "A collection of objects providing scheduling capabilities." ::= { schedGroups 4 } schedCalendarGroup OBJECT-GROUP OBJECTS { schedLocalTime, schedWeekDay, schedMonth, schedDay, schedHour, schedMinute } STATUS current DESCRIPTION "A collection of objects providing calendar based schedules." ::= { schedGroups 2 } schedNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { schedActionFailure } STATUS current DESCRIPTION "The notifications emitted by the scheduler." ::= { schedGroups 3 } -- -- Deprecated compliance and conformance group definitions -- from RFC 2591. -- schedCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMP entities which implement the scheduling MIB." MODULE -- this module MANDATORY-GROUPS { schedGroup, schedNotificationsGroup } Levi & Schoenwaelder Standards Track [Page 19] RFC 3231 Schedule MIB January 2002 GROUP schedCalendarGroup DESCRIPTION "The schedCalendarGroup is mandatory only for those implementations that support calendar based schedules." OBJECT schedType DESCRIPTION "The values calendar(2) or oneshot(3) are not valid for implementations that do not implement the schedCalendarGroup. Such an implementation must return inconsistentValue error responses for attempts to set schedAdminStatus to calendar(2) or oneshot(3)." ::= { schedCompliances 1 } schedGroup OBJECT-GROUP OBJECTS { schedDescr, schedInterval, schedContextName, schedVariable, schedValue, schedType, schedAdminStatus, schedOperStatus, schedFailures, schedLastFailure, schedLastFailed, schedStorageType, schedRowStatus } STATUS deprecated DESCRIPTION "A collection of objects providing scheduling capabilities." ::= { schedGroups 1 } END 5. Usage Examples This section presents some examples how the scheduling MIB can be used to schedule scripts with the Script MIB [RFC3165] or to realize on-duty/off-duty schedules by modifying status objects of other MIB modules. 5.1. Starting a script to ping devices every 20 minutes It is assumed that the schedule entry is owned by schedOwner = "joe" and its name is schedName = "ping". The instance identifier for the scheduling entry is therefore 3.106.111.101.4.112.105.110.103. It is further assumed that the smLaunchTable entry is owned by smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs". The complete object identifier for the smLaunchStart object is therefore smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115. The script lives in the context identified by the string "engine1". Levi & Schoenwaelder Standards Track [Page 20] RFC 3231 Schedule MIB January 2002 The configuration of the scheduler entry which launches the script every 20 minutes would look as follows: schedInterval.3.106.111.101.4.112.105.110.103 = 1200 schedValue.3.106.111.101.4.112.105.110.103 = 0 schedContextName.3.106.111.101.4.112.105.110.103 = "engine1" schedVariable.3.106.111.101.4.112.105.110.103 = smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115 schedType.3.106.111.101.4.112.105.110.103 = periodic(1) schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1) schedStorageType.3.106.111.101.4.112.105.110.103 = nonVolatile(3) schedRowStatus.3.106.111.101.4.112.105.110.103 = active(1) All the remaining columns in the schedTable represent status information and are not shown here. 5.2. Starting a script at the next Friday the 13th It is assumed that the schedule entry is owned by schedOwner = "joe" and its name is schedName = "13th". The instance identifier for the scheduling entry is therefore 3.106.111.101.4.49.51.116.104. It is further assumed that the smLaunchTable entry is owned by smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The complete object identifier for the smLaunchStart object is therefore smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives in the context identified by the string "engine1". The configuration of the scheduler entry which launches the script on the next Friday 13th at midnight would look as follows: schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday } schedMonth.3.106.111.101.4.49.51.116.104 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.106.111.101.4.49.51.116.104 = { d13 } schedHour.3.106.111.101.4.49.51.116.104 = { h0 } schedMinute.3.106.111.101.4.49.51.116.104 = { m0 } schedValue.3.106.111.101.4.49.51.116.104 = 0 schedContextName.3.106.111.101.4.49.51.116.104 = "engine1" schedVariable.3.106.111.101.4.49.51.116.104 = smLaunchStart.3.106.111.101.5.103.104.111.115.116 Levi & Schoenwaelder Standards Track [Page 21] RFC 3231 Schedule MIB January 2002 schedType.3.106.111.101.4.49.51.116.104 = oneshot(3) schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2) schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3) schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1) All the remaining columns in the schedTable represent status information and are not shown here. 5.3. Turning an interface off during weekends This example assumes that a network interface should be taken down during weekends. The interface table (ifTable) of the IF-MIB [RFC2863] is assumed to exist in the context identified by an empty string and the index of the interface is ifIndex = 6. The scheduling entry which brings the interface down on every Friday evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and its name is schedName = "if-off". The instance identifier for the scheduling entry is therefore 3.98.111.98.6.105.102.45.111.102.102. schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { friday } schedMonth.3.98.111.98.6.105.102.45.111.102.102 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.98.111.98.6.105.102.45.111.102.102 = { d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 } schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 } schedMinute.3.98.111.98.6.105.102.45.111.102.102 = { m30 } schedValue.3.98.111.98.6.105.102.45.111.102.102 = down(2) schedContextName.3.98.111.98.6.105.102.45.111.102.102 = "" schedVariable.3.98.111.98.6.105.102.45.111.102.102 = ifAdminStatus.6 schedType.3.98.111.98.6.105.102.45.111.102.102 = calendar(2) schedAdminStatus.3.98.111.98.6.105.102.45.111.102.102 = enabled(1) schedStorageType.3.98.111.98.6.105.102.45.111.102.102 = nonVolatile(3) schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1) The scheduling entry which brings the interface up on every Monday morning at 5:30 is owned by schedOwner = "bob" and its name is schedName = "if-on". The instance identifier for the scheduling entry is therefore 3.98.111.98.5.105.102.45.111.110. Levi & Schoenwaelder Standards Track [Page 22] RFC 3231 Schedule MIB January 2002 The entry in the schedTable which brings the interface up again on every Monday morning at 5:30 looks as follows: schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { monday } schedMonth.3.98.111.98.5.105.102.45.111.110 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.98.111.98.5.105.102.45.111.110 = { d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31 } schedHour.3.98.111.98.5.105.102.45.111.110 = { h5 } schedMinute.3.98.111.98.5.105.102.45.111.110 = { m30 } schedValue.3.98.111.98.5.105.102.45.111.110 = up(1) schedContextName.3.98.111.98.5.105.102.45.111.110 = "" schedVariable.3.98.111.98.5.105.102.45.111.110 = ifAdminStatus.6 schedType.3.98.111.98.5.105.102.45.111.110 = calendar(2) schedAdminStatus.3.98.111.98.5.105.102.45.111.110 = enabled(1) schedStorageType.3.98.111.98.5.105.102.45.111.110 = nonVolatile(3) schedRowStatus.3.98.111.98.5.105.102.45.111.110 = active(1) A similar configuration could be used to control other schedules. For example, one could change the "if-on" and "if-off" schedules to enable and disable the periodic scheduler defined in the first example. 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. Levi & Schoenwaelder Standards Track [Page 23] RFC 3231 Schedule MIB January 2002 It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Scheduled SNMP set operations must use the security credentials that were present when the corresponding row in the scheduling entry was created. An implementation must therefore record and maintain the credentials for every scheduling entry. An implementation must ensure that access control rules are applied when doing the set operation. This is accomplished by calling the isAccessAllowed abstract service interface defined in RFC 2571 [RFC2571]: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) The securityModel, securityName and securityLevel parameters are set to the values that were recorded when the scheduling entry was created. The viewType parameter must select the write view and the contextName and variableName parameters are taken from the schedContextName and schedVariableName values of the scheduling entry. This MIB limits scheduled actions to objects in the local MIB. This avoids security problems with the delegation of access rights. However, it might be possible for a user of this MIB to own some schedules that might trigger far in the future. This can cause security risks if the security administrator did not properly update the access control lists when a user is withdrawn from an SNMP engine. Therefore, entries in the schedTable SHOULD be cleaned up whenever a user is removed from an SNMP engine. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 2575 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of Levi & Schoenwaelder Standards Track [Page 24] RFC 3231 Schedule MIB January 2002 SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11, RFC 2028. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Changes from RFC 2591 The following list documents major changes from the previous version of this document, published as RFC 2591: - Updated the SNMP Management Framework boilerplate and the references. - Added revision clauses to the module identity macro. - Clarified the behavior during time transitions. Levi & Schoenwaelder Standards Track [Page 25] RFC 3231 Schedule MIB January 2002 - Clarified that schedInterval and schedCalendarGroup objects can be modified regardless of the current value of schedRowStatus, schedAdminStatus and schedOperStatus. - Added some additional boilerplate text to the security considerations section. - Clarified that implementations must re-calculate any pending action invocations when scheduling parameters are modified. - Clarified that schedOperStatus must not be enabled while the schedRowStatus is not active. - Clarified that schedRowStatus can not be changed as long as the schedOperStatus is enabled. - Clarified that implementations can delegate the isAccessAllowed check by sending themself an SNMP Set message. - Added the schedTriggers object which counts the total number of triggers. - Added DEFVALs for schedContextName, schedVariable, and schedValue and updated the schedRowStatus description. - Deprecated schedCompliance, schedGroup and created schedCompliance2 and schedGroup2 that take care of the new schedTriggers object. 9. Acknowledgments This document was produced by the IETF Distributed Management (DISMAN) working group. 10. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. Levi & Schoenwaelder Standards Track [Page 26] RFC 3231 Schedule MIB January 2002 [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. Levi & Schoenwaelder Standards Track [Page 27] RFC 3231 Schedule MIB January 2002 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11. Editors' Addresses David B. Levi Nortel Networks 4401 Great America Parkway Santa Clara, CA 95052-8185 USA Phone: +1 865 686 0432 EMail: dlevi@nortelnetworks.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de Levi & Schoenwaelder Standards Track [Page 28] RFC 3231 Schedule MIB January 2002 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Levi & Schoenwaelder Standards Track [Page 29] snmp-mibs-downloader-1.1/mibrfcs/rfc3273.txt0000644000000000000000000044661411402176071015577 0ustar Network Working Group S. Waldbusser Request for Comments: 3273 July 2002 Category: Standards Track Remote Network Monitoring Management Information Base for High Capacity Networks 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 2.1 Structure of MIB .......................................... 3 3 Updates to RMON MIB and RMON2 MIB objects ................... 4 4 Conventions ................................................. 6 5 Definitions ................................................. 7 6 Security Considerations .....................................73 7 Acknowledgments .............................................73 8 References ..................................................73 9 Notices .....................................................75 10 Author's Address.............................................76 11 Full Copyright Statement.....................................77 Waldbusser Standards Track [Page 1] RFC 3273 Remote Network Monitoring Management July 2002 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3], and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6], and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [9], and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [10], RFC 2572 [11], and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [22]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in Waldbusser Standards Track [Page 2] RFC 3273 Remote Network Monitoring Management July 2002 SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview This document continues the architecture created in the RMON MIB [RFC 2819] by supporting high speed networks. Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network. Often these remote probes are stand-alone devices and devote significant internal resources for the sole purpose of managing a network. An organization may employ many of these devices, one per network segment, to manage its internet. In addition, these devices may be used for a network management service provider to access a client network, often geographically remote. The objects defined in this document are intended as an interface between an RMON agent and an RMON management application and are not intended for direct manipulation by humans. While some users may tolerate the direct display of some of these objects, few will tolerate the complexity of manually manipulating objects to accomplish row creation. These functions should be handled by the management application. 2.1 Structure of MIB Except for the mediaIndependentTable, each of the tables in this MIB adds high capacity capability to an associated table in the RMON-1 MIB or RMON-2 MIB. The objects are arranged into the following groups: - mediaIndependentGroup - etherStatsHighCapacityGroup - etherHistoryHighCapacityGroup - hostHighCapacityGroup - hostTopNHighCapacityGroup - matrixHighCapacityGroup - captureBufferHighCapacityGroup Waldbusser Standards Track [Page 3] RFC 3273 Remote Network Monitoring Management July 2002 - protocolDistributionHighCapacityGroup - nlHostHighCapacityGroup - nlMatrixHighCapacityGroup - nlMatrixTopNHighCapacityGroup - alHostHighCapacityGroup - alMatrixHighCapacityGroup - alMatrixTopNHighCapacityGroup - usrHistoryHighCapacityGroup These groups are the basic units of conformance. If a remote monitoring device implements a group, then it must implement all objects in that group. For example, a managed agent that implements the network layer matrix group must implement the nlMatrixSDHighCapacityTable and the nlMatrixDSHighCapacityTable. Implementations of this MIB must also implement the system and interfaces group of MIB-II [16,17]. MIB-II may also mandate the implementation of additional groups. These groups are defined to provide a means of assigning object identifiers, and to provide a method for agent implementors to know which objects they must implement. 3. Updates to RMON MIB and RMON2 MIB objects This document extends the enumerations in the following objects from the RMON MIB [18] and the RMON2 MIB [20]. From the RMON MIB: hostTopNRateBase OBJECT-TYPE SYNTAX INTEGER { hostTopNInPkts(1), hostTopNOutPkts(2), hostTopNInOctets(3), hostTopNOutOctets(4), hostTopNOutErrors(5), hostTopNOutBroadcastPkts(6), hostTopNOutMulticastPkts(7), hostTopNHCInPkts(8), hostTopNHCOutPkts(9), Waldbusser Standards Track [Page 4] RFC 3273 Remote Network Monitoring Management July 2002 hostTopNHCInOctets(10), hostTopNHCOutOctets(11) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable for each host that the hostTopNRate variable is based upon, as well as a control for the table that the results will be reported in. This object may not be modified if the associated hostTopNStatus object is equal to valid(1). If this value is less than or equal to 7, when the report is prepared, entries are created in the hostTopNTable associated with this object. If this value is greater than or equal to 8, when the report is prepared, entries are created in the hostTopNHighCapacityTable associated with this object." ::= { hostTopNControlEntry 3 } From the RMON2 MIB: nlMatrixTopNControlRateBase OBJECT-TYPE SYNTAX INTEGER { nlMatrixTopNPkts(1), nlMatrixTopNOctets(2), nlMatrixTopNHighCapacityPkts(3), nlMatrixTopNHighCapacityOctets(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable for each nlMatrix[SD/DS] entry that the nlMatrixTopNEntries are sorted by, as well as a control for the table that the results will be reported in. This object may not be modified if the associated nlMatrixTopNControlStatus object is equal to active(1). If this value is less than or equal to 2, when the report is prepared, entries are created in the nlMatrixTopNTable associated with this object. If this value is greater than or equal to 3, when the report is prepared, entries are created in the nlMatrixTopNHighCapacityTable associated with this object." ::= { nlMatrixTopNControlEntry 3 } Waldbusser Standards Track [Page 5] RFC 3273 Remote Network Monitoring Management July 2002 From the RMON2 MIB: alMatrixTopNControlRateBase OBJECT-TYPE SYNTAX INTEGER { alMatrixTopNTerminalsPkts(1), alMatrixTopNTerminalsOctets(2), alMatrixTopNAllPkts(3), alMatrixTopNAllOctets(4), alMatrixTopNTerminalsHighCapacityPkts(5), alMatrixTopNTerminalsHighCapacityOctets(6), alMatrixTopNAllHighCapacityPkts(7), alMatrixTopNAllHighCapacityOctets(8) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable for each alMatrix[SD/DS] entry that the alMatrixTopNEntries are sorted by, as well as the selector of the view of the matrix table that will be used, as well as a control for the table that the results will be reported in. The values alMatrixTopNTerminalsPkts, alMatrixTopNTerminalsOctets, alMatrixTopNTerminalsHighCapacityPkts, and alMatrixTopNTerminalsHighCapacityOctets cause collection only from protocols that have no child protocols that are counted. The values alMatrixTopNAllPkts, alMatrixTopNAllOctets, alMatrixTopNAllHighCapacityPkts, and alMatrixTopNAllHighCapacityOctets cause collection from all alMatrix entries. This object may not be modified if the associated alMatrixTopNControlStatus object is equal to active(1)." ::= { alMatrixTopNControlEntry 3 } For convenience, updated MIB modules containing these objects may be found at: ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/rmon.mib ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/rmon2.mib 4. Conventions The following conventions are used throughout the RMON MIB and its companion documents. Waldbusser Standards Track [Page 6] RFC 3273 Remote Network Monitoring Management July 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Good Packets Good packets are error-free packets that have a valid frame length. For example, on Ethernet, good packets are error-free packets that are between 64 octets long and 1518 octets long. They follow the form defined in IEEE 802.3 section 3.2.all. Implementors are urged to consult the appropriate media-specific specifications. Bad Packets Bad packets are packets that have proper framing and are therefore recognized as packets, but contain errors within the packet or have an invalid length. For example, on Ethernet, bad packets have a valid preamble and SFD (Start of Frame Delimiter), but have a bad FCS (Frame Check Sequence), or are either shorter than 64 octets or longer than 1518 octets. Implementors are urged to consult the appropriate media-specific specifications. 5. Definitions HC-RMON-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Gauge32, Counter64 FROM SNMPv2-SMI RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF rmon, OwnerString, statistics, history, hosts, hostTopN, matrix, etherStatsIndex, etherHistoryIndex, etherHistorySampleIndex, hostIndex, hostAddress, hostTimeIndex, hostTimeCreationOrder, hostTopNReport, hostTopNIndex, matrixSDIndex, matrixSDSourceAddress, matrixSDDestAddress, matrixDSIndex, matrixDSDestAddress, matrixDSSourceAddress, capture, captureBufferControlIndex, captureBufferIndex FROM RMON-MIB protocolDirLocalIndex, protocolDistControlIndex, protocolDist, hlHostControlIndex, nlHost, nlHostTimeMark, nlHostAddress, hlMatrixControlIndex, nlMatrix, nlMatrixSDTimeMark, nlMatrixSDSourceAddress, nlMatrixSDDestAddress, nlMatrixDSTimeMark, nlMatrixDSDestAddress, nlMatrixDSSourceAddress, nlMatrixTopNControlIndex, nlMatrixTopNIndex, alHost, alHostTimeMark, alMatrix, alMatrixSDTimeMark, alMatrixDSTimeMark, alMatrixTopNControlIndex, alMatrixTopNIndex, Waldbusser Standards Track [Page 7] RFC 3273 Remote Network Monitoring Management July 2002 usrHistory, usrHistoryControlIndex, usrHistorySampleIndex, usrHistoryObjectIndex, rmonConformance, ZeroBasedCounter32, probeConfig FROM RMON2-MIB ZeroBasedCounter64, CounterBasedGauge64 FROM HCNUM-TC; -- Remote Network Monitoring MIB hcRMON MODULE-IDENTITY LAST-UPDATED "200205080000Z" -- May 08, 2002 ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "Steve Waldbusser Phone: +1-650-948-6500 Fax: +1-650-745-0671 Email: waldbusser@nextbeacon.com Andy Bierman WG Chair abierman@cisco.com RMONMIB WG Mailing List rmonmib@ietf.org http://www.ietf.org/mailman/listinfo/rmonmib" DESCRIPTION "The MIB module for managing remote monitoring device implementations. This MIB module augments the original RMON MIB as specified in RFC 2819 and RFC 1513 and RMON-2 MIB as specified in RFC 2021." REVISION "200205080000Z" -- May 08, 2002 DESCRIPTION "The original version of this MIB, published as RFC3273." ::= { rmonConformance 5 } -- { rmon 1 } through { rmon 20 } are defined in RMON [RFC 2819] and -- the Token Ring RMON MIB [RFC 1513] and the RMON-2 MIB [RFC 2021]. mediaIndependentStats OBJECT IDENTIFIER ::= { rmon 21 } mediaIndependentTable OBJECT-TYPE SYNTAX SEQUENCE OF MediaIndependentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Waldbusser Standards Track [Page 8] RFC 3273 Remote Network Monitoring Management July 2002 "Media independent statistics for promiscuous monitoring of any media. The following table defines media independent statistics that provide information for full and/or half-duplex links as well as high capacity links. For half-duplex links, or full-duplex-capable links operating in half-duplex mode, the mediaIndependentIn* objects shall be used and the mediaIndependentOut* objects shall not increment. For full-duplex links, the mediaIndependentOut* objects shall be present and shall increment. Whenever possible, the probe should count packets moving away from the closest terminating equipment as output packets. Failing that, the probe should count packets moving away from the DTE as output packets." ::= { mediaIndependentStats 1 } mediaIndependentEntry OBJECT-TYPE SYNTAX MediaIndependentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Media independent statistics for promiscuous monitoring of any media." INDEX { mediaIndependentIndex } ::= { mediaIndependentTable 1 } MediaIndependentEntry ::= SEQUENCE { mediaIndependentIndex Integer32, mediaIndependentDataSource OBJECT IDENTIFIER, mediaIndependentDropEvents Counter32, mediaIndependentDroppedFrames Counter32, mediaIndependentInPkts Counter32, mediaIndependentInOverflowPkts Counter32, mediaIndependentInHighCapacityPkts Counter64, mediaIndependentOutPkts Counter32, mediaIndependentOutOverflowPkts Counter32, mediaIndependentOutHighCapacityPkts Counter64, mediaIndependentInOctets Counter32, mediaIndependentInOverflowOctets Counter32, mediaIndependentInHighCapacityOctets Counter64, mediaIndependentOutOctets Counter32, mediaIndependentOutOverflowOctets Counter32, mediaIndependentOutHighCapacityOctets Counter64, mediaIndependentInNUCastPkts Counter32, mediaIndependentInNUCastOverflowPkts Counter32, Waldbusser Standards Track [Page 9] RFC 3273 Remote Network Monitoring Management July 2002 mediaIndependentInNUCastHighCapacityPkts Counter64, mediaIndependentOutNUCastPkts Counter32, mediaIndependentOutNUCastOverflowPkts Counter32, mediaIndependentOutNUCastHighCapacityPkts Counter64, mediaIndependentInErrors Counter32, mediaIndependentOutErrors Counter32, mediaIndependentInputSpeed Gauge32, mediaIndependentOutputSpeed Gauge32, mediaIndependentDuplexMode INTEGER, mediaIndependentDuplexChanges Counter32, mediaIndependentDuplexLastChange TimeStamp, mediaIndependentOwner OwnerString, mediaIndependentStatus RowStatus } mediaIndependentIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object uniquely identifies this mediaIndependent entry." ::= { mediaIndependentEntry 1 } mediaIndependentDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the source of the data that this mediaIndependent entry is configured to analyze. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in RFC 1213 and RFC 2233 [16,17], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. The statistics in this group reflect all packets on the local network segment attached to the identified interface. An agent may or may not be able to tell if fundamental changes to the media of the interface have occurred and necessitate a deletion of this entry. For example, a hot-pluggable ethernet card could be pulled out and replaced by a Waldbusser Standards Track [Page 10] RFC 3273 Remote Network Monitoring Management July 2002 token-ring card. In such a case, if the agent has such knowledge of the change, it is recommended that it delete this entry. This object may not be modified if the associated mediaIndependentStatus object is equal to active(1)." ::= { mediaIndependentEntry 2 } mediaIndependentDropEvents OBJECT-TYPE SYNTAX Counter32 UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of events in which packets were dropped by the probe due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is just the number of times this condition has been detected." ::= { mediaIndependentEntry 3 } mediaIndependentDroppedFrames OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the mediaIndependentDropEvents, but for which the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { mediaIndependentEntry 4 } mediaIndependentInPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets, Waldbusser Standards Track [Page 11] RFC 3273 Remote Network Monitoring Management July 2002 broadcast packets, and multicast packets) received on a half-duplex link or on the inbound connection of a full-duplex link." ::= { mediaIndependentEntry 5 } mediaIndependentInOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated mediaIndependentInPkts counter has overflowed." ::= { mediaIndependentEntry 6 } mediaIndependentInHighCapacityPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets, broadcast packets, and multicast packets) received on a half-duplex link or on the inbound connection of a full-duplex link." ::= { mediaIndependentEntry 7 } mediaIndependentOutPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets, broadcast packets, and multicast packets) received on a full-duplex link in the direction of the network." ::= { mediaIndependentEntry 8 } mediaIndependentOutOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated mediaIndependentOutPkts counter has overflowed." ::= { mediaIndependentEntry 9 } Waldbusser Standards Track [Page 12] RFC 3273 Remote Network Monitoring Management July 2002 mediaIndependentOutHighCapacityPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets, broadcast packets, and multicast packets) received on a full-duplex link in the direction of the network." ::= { mediaIndependentEntry 10 } mediaIndependentInOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received (excluding framing bits but including FCS octets) on a half-duplex link or on the inbound connection of a full-duplex link." ::= { mediaIndependentEntry 11 } mediaIndependentInOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated mediaIndependentInOctets counter has overflowed." ::= { mediaIndependentEntry 12 } mediaIndependentInHighCapacityOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received (excluding framing bits but including FCS octets) on a half-duplex link or on the inbound connection of a full-duplex link." ::= { mediaIndependentEntry 13 } mediaIndependentOutOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" Waldbusser Standards Track [Page 13] RFC 3273 Remote Network Monitoring Management July 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received on a full-duplex link in the direction of the network (excluding framing bits but including FCS octets)." ::= { mediaIndependentEntry 14 } mediaIndependentOutOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated mediaIndependentOutOctets counter has overflowed." ::= { mediaIndependentEntry 15 } mediaIndependentOutHighCapacityOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received on a full-duplex link in the direction of the network (excluding framing bits but including FCS octets)." ::= { mediaIndependentEntry 16 } mediaIndependentInNUCastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of non-unicast packets (including bad packets) received on a half-duplex link or on the inbound connection of a full-duplex link." ::= { mediaIndependentEntry 17 } mediaIndependentInNUCastOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 14] RFC 3273 Remote Network Monitoring Management July 2002 "The number of times the associated mediaIndependentInNUCastPkts counter has overflowed." ::= { mediaIndependentEntry 18 } mediaIndependentInNUCastHighCapacityPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of non-unicast packets (including bad packets) received on a half-duplex link or on the inbound connection of a full-duplex link." ::= { mediaIndependentEntry 19 } mediaIndependentOutNUCastPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of non-unicast packets (including bad packets) received on a full-duplex link in the direction of the network." ::= { mediaIndependentEntry 20 } mediaIndependentOutNUCastOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated mediaIndependentOutNUCastPkts counter has overflowed." ::= { mediaIndependentEntry 21 } mediaIndependentOutNUCastHighCapacityPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received on a full-duplex link in the direction of the network." ::= { mediaIndependentEntry 22 } mediaIndependentInErrors OBJECT-TYPE Waldbusser Standards Track [Page 15] RFC 3273 Remote Network Monitoring Management July 2002 SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bad packets received on a half-duplex link or on the inbound connection of a full-duplex link." ::= { mediaIndependentEntry 23 } mediaIndependentOutErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of bad packets received on a full-duplex link in the direction of the network." ::= { mediaIndependentEntry 24 } mediaIndependentInputSpeed OBJECT-TYPE SYNTAX Gauge32 UNITS "Kilobits per Second" MAX-ACCESS read-only STATUS current DESCRIPTION "The nominal maximum speed in kilobits per second of this half-duplex link or on the inbound connection of this full-duplex link. If the speed is unknown or there is no fixed maximum (e.g. a compressed link), this value shall be zero." ::= { mediaIndependentEntry 25 } mediaIndependentOutputSpeed OBJECT-TYPE SYNTAX Gauge32 UNITS "Kilobits per Second" MAX-ACCESS read-only STATUS current DESCRIPTION "The nominal maximum speed in kilobits per second of this full-duplex link in the direction of the network. If the speed is unknown, the link is half-duplex, or there is no fixed maximum (e.g. a compressed link), this value shall be zero." ::= { mediaIndependentEntry 26 } mediaIndependentDuplexMode OBJECT-TYPE SYNTAX INTEGER { halfduplex(1), fullduplex(2) Waldbusser Standards Track [Page 16] RFC 3273 Remote Network Monitoring Management July 2002 } MAX-ACCESS read-only STATUS current DESCRIPTION "The current mode of this link. Note that if the link has full-duplex capabilities but is operating in half-duplex mode, this value will be halfduplex(1)." ::= { mediaIndependentEntry 27 } mediaIndependentDuplexChanges OBJECT-TYPE SYNTAX Counter32 UNITS "Events" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this link has changed from full-duplex mode to half-duplex mode or from half-duplex mode to full-duplex mode." ::= { mediaIndependentEntry 28 } mediaIndependentDuplexLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the duplex status of this link last changed." ::= { mediaIndependentEntry 29 } mediaIndependentOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { mediaIndependentEntry 30 } mediaIndependentStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this media independent statistics entry." ::= { mediaIndependentEntry 31 } Waldbusser Standards Track [Page 17] RFC 3273 Remote Network Monitoring Management July 2002 -- High Capacity extensions for the etherStatsTable etherStatsHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF EtherStatsHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 etherStatsTable." ::= { statistics 7 } etherStatsHighCapacityEntry OBJECT-TYPE SYNTAX EtherStatsHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 etherStatsEntry. These objects will be created by the agent for all etherStatsEntries it deems appropriate." INDEX { etherStatsIndex } ::= { etherStatsHighCapacityTable 1 } EtherStatsHighCapacityEntry ::= SEQUENCE { etherStatsHighCapacityOverflowPkts Counter32, etherStatsHighCapacityPkts Counter64, etherStatsHighCapacityOverflowOctets Counter32, etherStatsHighCapacityOctets Counter64, etherStatsHighCapacityOverflowPkts64Octets Counter32, etherStatsHighCapacityPkts64Octets Counter64, etherStatsHighCapacityOverflowPkts65to127Octets Counter32, etherStatsHighCapacityPkts65to127Octets Counter64, etherStatsHighCapacityOverflowPkts128to255Octets Counter32, etherStatsHighCapacityPkts128to255Octets Counter64, etherStatsHighCapacityOverflowPkts256to511Octets Counter32, etherStatsHighCapacityPkts256to511Octets Counter64, etherStatsHighCapacityOverflowPkts512to1023Octets Counter32, etherStatsHighCapacityPkts512to1023Octets Counter64, etherStatsHighCapacityOverflowPkts1024to1518Octets Counter32, etherStatsHighCapacityPkts1024to1518Octets Counter64 } etherStatsHighCapacityOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 18] RFC 3273 Remote Network Monitoring Management July 2002 "The number of times the associated etherStatsPkts counter has overflowed." ::= { etherStatsHighCapacityEntry 1 } etherStatsHighCapacityPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets, broadcast packets, and multicast packets) received." ::= { etherStatsHighCapacityEntry 2 } etherStatsHighCapacityOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherStatsOctets counter has overflowed." ::= { etherStatsHighCapacityEntry 3 } etherStatsHighCapacityOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received on the network (excluding framing bits but including FCS octets). If the network is half-duplex Fast Ethernet, this object can be used as a reasonable estimate of utilization. If greater precision is desired, the etherStatsHighCapacityPkts and etherStatsHighCapacityOctets objects should be sampled before and after a common interval. The differences in the sampled values are Pkts and Octets, respectively, and the number of seconds in the interval is Interval. These values are used to calculate the Utilization as follows: Waldbusser Standards Track [Page 19] RFC 3273 Remote Network Monitoring Management July 2002 Pkts * (.96 + .64) + (Octets * .08) Utilization = ------------------------------------- Interval * 10,000 The result of this equation is the value Utilization which is the percent utilization of the ethernet segment on a scale of 0 to 100 percent. This table is not appropriate for monitoring full-duplex ethernets. If the network is a full-duplex ethernet and the mediaIndependentTable is monitoring that network, the utilization can be calculated as follows: 1) Determine the utilization of the inbound path by using the appropriate equation (for ethernet or fast ethernet) to determine the utilization, substituting mediaIndependentInPkts for etherStatsHighCapacityPkts, and mediaIndependentInOctets for etherStatsHighCapacityOctets. Call the resulting utilization inUtilization. 2) Determine the utilization of the outbound path by using the same equation to determine the utilization, substituting mediaIndependentOutPkts for etherStatsHighCapacityPkts, and mediaIndependentOutOctets for etherStatsHighCapacityOctets. Call the resulting utilization outUtilization. 3) The utilization is the maximum of inUtilization and outUtilization. This metric shows the amount of percentage of bandwidth that is left before congestion will be experienced on the link." ::= { etherStatsHighCapacityEntry 4 } etherStatsHighCapacityOverflowPkts64Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherStatsPkts64Octets counter has overflowed." ::= { etherStatsHighCapacityEntry 5 } etherStatsHighCapacityPkts64Octets OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 20] RFC 3273 Remote Network Monitoring Management July 2002 "The total number of packets (including bad packets) received that were 64 octets in length (excluding framing bits but including FCS octets)." ::= { etherStatsHighCapacityEntry 6 } etherStatsHighCapacityOverflowPkts65to127Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherStatsPkts65to127Octets counter has overflowed." ::= { etherStatsHighCapacityEntry 7 } etherStatsHighCapacityPkts65to127Octets OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 65 and 127 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsHighCapacityEntry 8 } etherStatsHighCapacityOverflowPkts128to255Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherStatsPkts128to255Octets counter has overflowed." ::= { etherStatsHighCapacityEntry 9 } etherStatsHighCapacityPkts128to255Octets OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 128 and 255 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsHighCapacityEntry 10 } Waldbusser Standards Track [Page 21] RFC 3273 Remote Network Monitoring Management July 2002 etherStatsHighCapacityOverflowPkts256to511Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherStatsPkts256to511Octets counter has overflowed." ::= { etherStatsHighCapacityEntry 11 } etherStatsHighCapacityPkts256to511Octets OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 256 and 511 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsHighCapacityEntry 12 } etherStatsHighCapacityOverflowPkts512to1023Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherStatsPkts512to1023Octets counter has overflowed." ::= { etherStatsHighCapacityEntry 13 } etherStatsHighCapacityPkts512to1023Octets OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 512 and 1023 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsHighCapacityEntry 14 } etherStatsHighCapacityOverflowPkts1024to1518Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only Waldbusser Standards Track [Page 22] RFC 3273 Remote Network Monitoring Management July 2002 STATUS current DESCRIPTION "The number of times the associated etherStatsPkts1024to1518Octets counter has overflowed." ::= { etherStatsHighCapacityEntry 15 } etherStatsHighCapacityPkts1024to1518Octets OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets) received that were between 1024 and 1518 octets in length inclusive (excluding framing bits but including FCS octets)." ::= { etherStatsHighCapacityEntry 16 } -- High Capacity extensions for the etherHistoryTable etherHistoryHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF EtherHistoryHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 etherHistoryTable." ::= { history 6 } etherHistoryHighCapacityEntry OBJECT-TYPE SYNTAX EtherHistoryHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 etherHistoryEntry. These objects will be created by the agent for all etherHistoryEntries associated with whichever historyControlEntries it deems appropriate. (i.e., either all etherHistoryHighCapacityEntries associated with a particular historyControlEntry will be created, or none of them will be.)" INDEX { etherHistoryIndex, etherHistorySampleIndex } ::= { etherHistoryHighCapacityTable 1 } EtherHistoryHighCapacityEntry ::= SEQUENCE { etherHistoryHighCapacityOverflowPkts Gauge32, etherHistoryHighCapacityPkts CounterBasedGauge64, etherHistoryHighCapacityOverflowOctets Gauge32, Waldbusser Standards Track [Page 23] RFC 3273 Remote Network Monitoring Management July 2002 etherHistoryHighCapacityOctets CounterBasedGauge64 } etherHistoryHighCapacityOverflowPkts OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherHistoryPkts Gauge overflowed during this sampling interval." ::= { etherHistoryHighCapacityEntry 1 } etherHistoryHighCapacityPkts OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets (including bad packets, broadcast packets, and multicast packets) received during this sampling interval." ::= { etherHistoryHighCapacityEntry 2 } etherHistoryHighCapacityOverflowOctets OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated etherHistoryOctets counter has overflowed during this sampling interval." ::= { etherHistoryHighCapacityEntry 3 } etherHistoryHighCapacityOctets OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets of data (including those in bad packets) received on the network (excluding framing bits but including FCS octets) during this sampling interval." ::= { etherHistoryHighCapacityEntry 4 } -- High Capacity Extensions for the hostTable Waldbusser Standards Track [Page 24] RFC 3273 Remote Network Monitoring Management July 2002 hostHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF HostHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 hostTable." ::= { hosts 5 } hostHighCapacityEntry OBJECT-TYPE SYNTAX HostHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 hostEntry. These objects will be created by the agent for all hostEntries associated with whichever hostControlEntries it deems appropriate. (i.e., either all hostHighCapacityEntries associated with a particular hostControlEntry will be created, or none of them will be.)" INDEX { hostIndex, hostAddress } ::= { hostHighCapacityTable 1 } HostHighCapacityEntry ::= SEQUENCE { hostHighCapacityInOverflowPkts Counter32, hostHighCapacityInPkts Counter64, hostHighCapacityOutOverflowPkts Counter32, hostHighCapacityOutPkts Counter64, hostHighCapacityInOverflowOctets Counter32, hostHighCapacityInOctets Counter64, hostHighCapacityOutOverflowOctets Counter32, hostHighCapacityOutOctets Counter64 } hostHighCapacityInOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostInPkts counter has overflowed." ::= { hostHighCapacityEntry 1 } hostHighCapacityInPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" Waldbusser Standards Track [Page 25] RFC 3273 Remote Network Monitoring Management July 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted to this address since it was added to the hostHighCapacityTable." ::= { hostHighCapacityEntry 2 } hostHighCapacityOutOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostOutPkts counter has overflowed." ::= { hostHighCapacityEntry 3 } hostHighCapacityOutPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, including bad packets, transmitted by this address since it was added to the hostHighCapacityTable." ::= { hostHighCapacityEntry 4 } hostHighCapacityInOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostInOctets counter has overflowed." ::= { hostHighCapacityEntry 5 } hostHighCapacityInOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address since it was added to the hostHighCapacityTable (excluding framing bits but including FCS octets), except for Waldbusser Standards Track [Page 26] RFC 3273 Remote Network Monitoring Management July 2002 those octets in bad packets." ::= { hostHighCapacityEntry 6 } hostHighCapacityOutOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostOutOctets counter has overflowed." ::= { hostHighCapacityEntry 7 } hostHighCapacityOutOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted by this address since it was added to the hostHighCapacityTable (excluding framing bits but including FCS octets), including those octets in bad packets." ::= { hostHighCapacityEntry 8 } -- High Capacity extensions for the hostTimeTable hostTimeHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF HostTimeHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 hostTimeTable." ::= { hosts 6 } hostTimeHighCapacityEntry OBJECT-TYPE SYNTAX HostTimeHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 hostTimeEntry. These objects will be created by the agent for all hostTimeEntries associated with whichever hostControlEntries it deems appropriate. (i.e., either all hostTimeHighCapacityEntries associated with a particular hostControlEntry will be created, or none of them will be.)" Waldbusser Standards Track [Page 27] RFC 3273 Remote Network Monitoring Management July 2002 INDEX { hostTimeIndex, hostTimeCreationOrder } ::= { hostTimeHighCapacityTable 1 } HostTimeHighCapacityEntry ::= SEQUENCE { hostTimeHighCapacityInOverflowPkts Counter32, hostTimeHighCapacityInPkts Counter64, hostTimeHighCapacityOutOverflowPkts Counter32, hostTimeHighCapacityOutPkts Counter64, hostTimeHighCapacityInOverflowOctets Counter32, hostTimeHighCapacityInOctets Counter64, hostTimeHighCapacityOutOverflowOctets Counter32, hostTimeHighCapacityOutOctets Counter64 } hostTimeHighCapacityInOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostTimeInPkts counter has overflowed." ::= { hostTimeHighCapacityEntry 1 } hostTimeHighCapacityInPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted to this address since it was added to the hostTimeHighCapacityTable." ::= { hostTimeHighCapacityEntry 2 } hostTimeHighCapacityOutOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostTimeOutPkts counter has overflowed." ::= { hostTimeHighCapacityEntry 3 } hostTimeHighCapacityOutPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only Waldbusser Standards Track [Page 28] RFC 3273 Remote Network Monitoring Management July 2002 STATUS current DESCRIPTION "The number of packets, including bad packets, transmitted by this address since it was added to the hostTimeHighCapacityTable." ::= { hostTimeHighCapacityEntry 4 } hostTimeHighCapacityInOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostTimeInOctets counter has overflowed." ::= { hostTimeHighCapacityEntry 5 } hostTimeHighCapacityInOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address since it was added to the hostTimeHighCapacityTable (excluding framing bits but including FCS octets), except for those octets in bad packets." ::= { hostTimeHighCapacityEntry 6 } hostTimeHighCapacityOutOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hostTimeOutOctets counter has overflowed." ::= { hostTimeHighCapacityEntry 7 } hostTimeHighCapacityOutOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted by this address since it was added to the hostTimeTable (excluding framing bits but including FCS octets), including those Waldbusser Standards Track [Page 29] RFC 3273 Remote Network Monitoring Management July 2002 octets in bad packets." ::= { hostTimeHighCapacityEntry 8 } -- High Capacity Extensions for the hostTopNTable hostTopNHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF HostTopNHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 hostTopNTable when hostTopNRateBase specifies a High Capacity TopN Report." ::= { hostTopN 3 } hostTopNHighCapacityEntry OBJECT-TYPE SYNTAX HostTopNHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 hostTopNEntry when hostTopNRateBase specifies a High Capacity TopN Report. These objects will be created by the agent for all hostTopNEntries associated with whichever hostTopNControlEntries have a hostTopNRateBase that specify a high capacity report." INDEX { hostTopNReport, hostTopNIndex } ::= { hostTopNHighCapacityTable 1 } HostTopNHighCapacityEntry ::= SEQUENCE { hostTopNHighCapacityAddress OCTET STRING, hostTopNHighCapacityBaseRate Gauge32, hostTopNHighCapacityOverflowRate Gauge32, hostTopNHighCapacityRate CounterBasedGauge64 } hostTopNHighCapacityAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The physical address of this host." ::= { hostTopNHighCapacityEntry 1 } hostTopNHighCapacityBaseRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Waldbusser Standards Track [Page 30] RFC 3273 Remote Network Monitoring Management July 2002 DESCRIPTION "The amount of change in the selected variable during this sampling interval, modulo 2^32. The selected variable is this host's instance of the object selected by hostTopNRateBase." ::= { hostTopNHighCapacityEntry 2 } hostTopNHighCapacityOverflowRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32). The selected variable is this host's instance of the object selected by hostTopNRateBase." ::= { hostTopNHighCapacityEntry 3 } hostTopNHighCapacityRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval. The selected variable is this host's instance of the object selected by hostTopNRateBase." ::= { hostTopNHighCapacityEntry 4 } -- High Capacity Extensions for the matrixSDTable matrixSDHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF MatrixSDHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 matrixSDTable." ::= { matrix 5 } matrixSDHighCapacityEntry OBJECT-TYPE SYNTAX MatrixSDHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 matrixSDEntry. These objects will be created by the agent Waldbusser Standards Track [Page 31] RFC 3273 Remote Network Monitoring Management July 2002 for all matrixSDEntries associated with whichever matrixControlEntries it deems appropriate. (i.e., either all matrixSDHighCapacityEntries associated with a particular matrixControlEntry will be created, or none of them will be.)" INDEX { matrixSDIndex, matrixSDSourceAddress, matrixSDDestAddress } ::= { matrixSDHighCapacityTable 1 } MatrixSDHighCapacityEntry ::= SEQUENCE { matrixSDHighCapacityOverflowPkts Counter32, matrixSDHighCapacityPkts Counter64, matrixSDHighCapacityOverflowOctets Counter32, matrixSDHighCapacityOctets Counter64 } matrixSDHighCapacityOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated matrixSDPkts counter has overflowed." ::= { matrixSDHighCapacityEntry 1 } matrixSDHighCapacityPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets transmitted from the source address to the destination address (this number includes bad packets)." ::= { matrixSDHighCapacityEntry 2 } matrixSDHighCapacityOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated matrixSDOctets counter has overflowed." ::= { matrixSDHighCapacityEntry 3 } matrixSDHighCapacityOctets OBJECT-TYPE Waldbusser Standards Track [Page 32] RFC 3273 Remote Network Monitoring Management July 2002 SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets (excluding framing bits but including FCS octets) contained in all packets transmitted from the source address to the destination address." ::= { matrixSDHighCapacityEntry 4 } -- High Capacity extensions for the matrixDSTable matrixDSHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF MatrixDSHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 matrixDSTable." ::= { matrix 6 } matrixDSHighCapacityEntry OBJECT-TYPE SYNTAX MatrixDSHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 matrixDSEntry. These objects will be created by the agent for all matrixDSEntries associated with whichever matrixControlEntries it deems appropriate. (i.e., either all matrixDSHighCapacityEntries associated with a particular matrixControlEntry will be created, or none of them will be.)" INDEX { matrixDSIndex, matrixDSDestAddress, matrixDSSourceAddress } ::= { matrixDSHighCapacityTable 1 } MatrixDSHighCapacityEntry ::= SEQUENCE { matrixDSHighCapacityOverflowPkts Counter32, matrixDSHighCapacityPkts Counter64, matrixDSHighCapacityOverflowOctets Counter32, matrixDSHighCapacityOctets Counter64 } matrixDSHighCapacityOverflowPkts OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" Waldbusser Standards Track [Page 33] RFC 3273 Remote Network Monitoring Management July 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated matrixDSPkts counter has overflowed." ::= { matrixDSHighCapacityEntry 1 } matrixDSHighCapacityPkts OBJECT-TYPE SYNTAX Counter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets transmitted from the source address to the destination address (this number includes bad packets)." ::= { matrixDSHighCapacityEntry 2 } matrixDSHighCapacityOverflowOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated matrixDSOctets counter has overflowed." ::= { matrixDSHighCapacityEntry 3 } matrixDSHighCapacityOctets OBJECT-TYPE SYNTAX Counter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets (excluding framing bits but including FCS octets) contained in all packets transmitted from the source address to the destination address." ::= { matrixDSHighCapacityEntry 4 } -- High Capacity extensions for the captureBufferTable captureBufferHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF CaptureBufferHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 Waldbusser Standards Track [Page 34] RFC 3273 Remote Network Monitoring Management July 2002 captureBufferTable." ::= { capture 3 } captureBufferHighCapacityEntry OBJECT-TYPE SYNTAX CaptureBufferHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-1 captureBufferEntry. These objects will be created by the agent for all captureBufferEntries associated with whichever bufferControlEntries it deems appropriate. (i.e., either all captureBufferHighCapacityEntries associated with a particular bufferControlEntry will be created, or none of them will be.)" INDEX { captureBufferControlIndex, captureBufferIndex } ::= { captureBufferHighCapacityTable 1 } CaptureBufferHighCapacityEntry ::= SEQUENCE { captureBufferPacketHighCapacityTime Integer32 } captureBufferPacketHighCapacityTime OBJECT-TYPE SYNTAX Integer32 (0..999999) UNITS "nanoseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of nanoseconds that had passed since this capture buffer was first turned on when this packet was captured, modulo 10^6. This object is used in conjunction with the captureBufferPacketTime object. This object returns the number of nano-seconds to be added to to number of milli-seconds obtained from the captureBufferPacketTime object, to obtain more accurate inter packet arrival time." ::= { captureBufferHighCapacityEntry 1 } -- High Capacity extensions for the protocolDistStatsTable protocolDistStatsHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF ProtocolDistStatsHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 protocolDistStatsTable." Waldbusser Standards Track [Page 35] RFC 3273 Remote Network Monitoring Management July 2002 ::= { protocolDist 3 } protocolDistStatsHighCapacityEntry OBJECT-TYPE SYNTAX ProtocolDistStatsHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 protocolDistStatsTable. These objects will be created by the agent for all protocolDistStatsEntries associated with whichever protocolDistControlEntries it deems appropriate. (i.e., either all protocolDistStatsHighCapacityEntries associated with a particular protocolDistControlEntry will be created, or none of them will be.)" INDEX { protocolDistControlIndex, protocolDirLocalIndex } ::= { protocolDistStatsHighCapacityTable 1 } ProtocolDistStatsHighCapacityEntry ::= SEQUENCE { protocolDistStatsHighCapacityOverflowPkts ZeroBasedCounter32, protocolDistStatsHighCapacityPkts ZeroBasedCounter64, protocolDistStatsHighCapacityOverflowOctets ZeroBasedCounter32, protocolDistStatsHighCapacityOctets ZeroBasedCounter64 } protocolDistStatsHighCapacityOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated protocolDistStatsPkts counter has overflowed." ::= { protocolDistStatsHighCapacityEntry 1 } protocolDistStatsHighCapacityPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors received of this protocol type. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { protocolDistStatsHighCapacityEntry 2 } protocolDistStatsHighCapacityOverflowOctets OBJECT-TYPE Waldbusser Standards Track [Page 36] RFC 3273 Remote Network Monitoring Management July 2002 SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated protocolDistStatsOctets counter has overflowed." ::= { protocolDistStatsHighCapacityEntry 3 } protocolDistStatsHighCapacityOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets received of this protocol type since it was added to the protocolDistStatsTable (excluding framing bits but including FCS octets), except for those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { protocolDistStatsHighCapacityEntry 4 } -- High Capacity extensions for the nlHostTable. nlHostHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF NlHostHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlHostTable." ::= { nlHost 3 } nlHostHighCapacityEntry OBJECT-TYPE SYNTAX NlHostHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlHostEntry. These objects will be created by the agent for all nlHostEntries associated with whichever hlHostControlEntries it deems appropriate. (i.e., either all nlHostHighCapacityEntries associated with a particular hlHostControlEntry will be created, or none of them will be.)" Waldbusser Standards Track [Page 37] RFC 3273 Remote Network Monitoring Management July 2002 INDEX { hlHostControlIndex, nlHostTimeMark, protocolDirLocalIndex, nlHostAddress } ::= { nlHostHighCapacityTable 1 } NlHostHighCapacityEntry ::= SEQUENCE { nlHostHighCapacityInOverflowPkts ZeroBasedCounter32, nlHostHighCapacityInPkts ZeroBasedCounter64, nlHostHighCapacityOutOverflowPkts ZeroBasedCounter32, nlHostHighCapacityOutPkts ZeroBasedCounter64, nlHostHighCapacityInOverflowOctets ZeroBasedCounter32, nlHostHighCapacityInOctets ZeroBasedCounter64, nlHostHighCapacityOutOverflowOctets ZeroBasedCounter32, nlHostHighCapacityOutOctets ZeroBasedCounter64 } nlHostHighCapacityInOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated nlHostInPkts counter has overflowed." ::= { nlHostHighCapacityEntry 1 } nlHostHighCapacityInPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted to this address since it was added to the nlHostHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlHostHighCapacityEntry 2 } nlHostHighCapacityOutOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated nlHostOutPkts counter has overflowed." ::= { nlHostHighCapacityEntry 3 } Waldbusser Standards Track [Page 38] RFC 3273 Remote Network Monitoring Management July 2002 nlHostHighCapacityOutPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted by this address since it was added to the nlHostHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlHostHighCapacityEntry 4 } nlHostHighCapacityInOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated nlHostInOctets counter has overflowed." ::= { nlHostHighCapacityEntry 5 } nlHostHighCapacityInOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address since it was added to the nlHostHighCapacityTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { nlHostHighCapacityEntry 6 } nlHostHighCapacityOutOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated nlHostOutOctets counter has overflowed." Waldbusser Standards Track [Page 39] RFC 3273 Remote Network Monitoring Management July 2002 ::= { nlHostHighCapacityEntry 7 } nlHostHighCapacityOutOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted by this address since it was added to the nlHostHighCapacityTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { nlHostHighCapacityEntry 8 } -- High Capacity extensions for the nlMatrixTable nlMatrixSDHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixSDHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlMatrixTable." ::= { nlMatrix 6 } nlMatrixSDHighCapacityEntry OBJECT-TYPE SYNTAX NlMatrixSDHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlMatrixEntry. These objects will be created by the agent for all nlMatrixSDEntries associated with whichever hlMatrixControlEntries it deems appropriate. (i.e., either all nlMatrixSDHighCapacityEntries associated with a particular hlMatrixControlEntry will be created, or none of them will be.)" INDEX { hlMatrixControlIndex, nlMatrixSDTimeMark, protocolDirLocalIndex, nlMatrixSDSourceAddress, nlMatrixSDDestAddress } ::= { nlMatrixSDHighCapacityTable 1 } NlMatrixSDHighCapacityEntry ::= SEQUENCE { Waldbusser Standards Track [Page 40] RFC 3273 Remote Network Monitoring Management July 2002 nlMatrixSDHighCapacityOverflowPkts ZeroBasedCounter32, nlMatrixSDHighCapacityPkts ZeroBasedCounter64, nlMatrixSDHighCapacityOverflowOctets ZeroBasedCounter32, nlMatrixSDHighCapacityOctets ZeroBasedCounter64 } nlMatrixSDHighCapacityOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated nlMatrixSDPkts counter has overflowed." ::= { nlMatrixSDHighCapacityEntry 1 } nlMatrixSDHighCapacityPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted from the source address to the destination address since this entry was added to the nlMatrixSDHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlMatrixSDHighCapacityEntry 2 } nlMatrixSDHighCapacityOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated nlMatrixSDOctets counter has overflowed." ::= { nlMatrixSDHighCapacityEntry 3 } nlMatrixSDHighCapacityOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted from the source address to the destination address since this entry was added to the Waldbusser Standards Track [Page 41] RFC 3273 Remote Network Monitoring Management July 2002 nlMatrixSDHighCapacityTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { nlMatrixSDHighCapacityEntry 4 } -- High Capacity extensions for the nlMatrixDSTable nlMatrixDSHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixDSHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlMatrixDSTable." ::= { nlMatrix 7 } nlMatrixDSHighCapacityEntry OBJECT-TYPE SYNTAX NlMatrixDSHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlMatrixDSEntry. These objects will be created by the agent for all nlMatrixDSEntries associated with whichever hlmatrixControlEntries it deems appropriate. (i.e., either all nlMatrixDSHighCapacityEntries associated with a particular hlMatrixControlEntry will be created, or none of them will be.)" INDEX { hlMatrixControlIndex, nlMatrixDSTimeMark, protocolDirLocalIndex, nlMatrixDSDestAddress, nlMatrixDSSourceAddress } ::= { nlMatrixDSHighCapacityTable 1 } NlMatrixDSHighCapacityEntry ::= SEQUENCE { nlMatrixDSHighCapacityOverflowPkts ZeroBasedCounter32, nlMatrixDSHighCapacityPkts ZeroBasedCounter64, nlMatrixDSHighCapacityOverflowOctets ZeroBasedCounter32, nlMatrixDSHighCapacityOctets ZeroBasedCounter64 } nlMatrixDSHighCapacityOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only Waldbusser Standards Track [Page 42] RFC 3273 Remote Network Monitoring Management July 2002 STATUS current DESCRIPTION "The number of times the associated nlMatrixDSPkts counter has overflowed." ::= { nlMatrixDSHighCapacityEntry 1 } nlMatrixDSHighCapacityPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted from the source address to the destination address since this entry was added to the nlMatrixDSHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlMatrixDSHighCapacityEntry 2 } nlMatrixDSHighCapacityOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated nlMatrixDSOctets counter has overflowed." ::= { nlMatrixDSHighCapacityEntry 3 } nlMatrixDSHighCapacityOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted from the source address to the destination address since this entry was added to the nlMatrixDSHighCapacityTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { nlMatrixDSHighCapacityEntry 4 } -- High Capacity extensions for the nlMatrixTopNTable Waldbusser Standards Track [Page 43] RFC 3273 Remote Network Monitoring Management July 2002 nlMatrixTopNHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixTopNHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlMatrixTopNTable when nlMatrixTopNControlRateBase specifies a High Capacity TopN Report." ::= { nlMatrix 8 } nlMatrixTopNHighCapacityEntry OBJECT-TYPE SYNTAX NlMatrixTopNHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 nlMatrixTopNEntry when nlMatrixTopNControlRateBase specifies a High Capacity TopN Report. These objects will be created by the agent for all nlMatrixTopNEntries associated with whichever nlMatrixTopNControlEntries have a nlMatrixTopNControlRateBase that specify a high capacity report." INDEX { nlMatrixTopNControlIndex, nlMatrixTopNIndex } ::= { nlMatrixTopNHighCapacityTable 1 } NlMatrixTopNHighCapacityEntry ::= SEQUENCE { nlMatrixTopNHighCapacityProtocolDirLocalIndex Integer32, nlMatrixTopNHighCapacitySourceAddress OCTET STRING, nlMatrixTopNHighCapacityDestAddress OCTET STRING, nlMatrixTopNHighCapacityBasePktRate Gauge32, nlMatrixTopNHighCapacityOverflowPktRate Gauge32, nlMatrixTopNHighCapacityPktRate CounterBasedGauge64, nlMatrixTopNHighCapacityReverseBasePktRate Gauge32, nlMatrixTopNHighCapacityReverseOverflowPktRate Gauge32, nlMatrixTopNHighCapacityReversePktRate CounterBasedGauge64, nlMatrixTopNHighCapacityBaseOctetRate Gauge32, nlMatrixTopNHighCapacityOverflowOctetRate Gauge32, nlMatrixTopNHighCapacityOctetRate CounterBasedGauge64, nlMatrixTopNHighCapacityReverseBaseOctetRate Gauge32, nlMatrixTopNHighCapacityReverseOverflowOctetRate Gauge32, nlMatrixTopNHighCapacityReverseOctetRate CounterBasedGauge64 } nlMatrixTopNHighCapacityProtocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex of the network layer protocol of Waldbusser Standards Track [Page 44] RFC 3273 Remote Network Monitoring Management July 2002 this entry's network address." ::= { nlMatrixTopNHighCapacityEntry 1 } nlMatrixTopNHighCapacitySourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixTopNHighCapacityEntry 2 } nlMatrixTopNHighCapacityDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the nlMatrixTopNProtocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixTopNHighCapacityEntry 3 } nlMatrixTopNHighCapacityBasePktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the source host to the destination host during this sampling interval, modulo 2^32, counted using the rules for counting the Waldbusser Standards Track [Page 45] RFC 3273 Remote Network Monitoring Management July 2002 nlMatrixSDPkts object." ::= { nlMatrixTopNHighCapacityEntry 4 } nlMatrixTopNHighCapacityOverflowPktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the source host to the destination host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the nlMatrixSDPkts object." ::= { nlMatrixTopNHighCapacityEntry 5 } nlMatrixTopNHighCapacityPktRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the source host to the destination host during this sampling interval, counted using the rules for counting the nlMatrixSDPkts object. If the value of nlMatrixTopNControlRateBase is nlMatrixTopNHighCapacityPkts, this variable will be used to sort this report." ::= { nlMatrixTopNHighCapacityEntry 6 } nlMatrixTopNHighCapacityReverseBasePktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the destination host to the source host during this sampling interval, modulo 2^32, counted using the rules for counting the nlMatrixSDPkts object (note that the corresponding nlMatrixSDPkts object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNHighCapacityPkts, the sort of topN entries is based entirely on nlMatrixTopNHighCapacityPktRate, and not on the value of this object." Waldbusser Standards Track [Page 46] RFC 3273 Remote Network Monitoring Management July 2002 ::= { nlMatrixTopNHighCapacityEntry 7 } nlMatrixTopNHighCapacityReverseOverflowPktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the destination host to the source host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the nlMatrixSDPkts object (note that the corresponding nlMatrixSDPkts object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNHighCapacityPkts, the sort of topN entries is based entirely on nlMatrixTopNHighCapacityPktRate, and not on the value of this object." ::= { nlMatrixTopNHighCapacityEntry 8 } nlMatrixTopNHighCapacityReversePktRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the destination host to the source host during this sampling interval, counted using the rules for counting the nlMatrixSDPkts object (note that the corresponding nlMatrixSDPkts object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNHighCapacityPkts, the sort of topN entries is based entirely on nlMatrixTopNHighCapacityPktRate, and not on the value of this object." ::= { nlMatrixTopNHighCapacityEntry 9 } nlMatrixTopNHighCapacityBaseOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current Waldbusser Standards Track [Page 47] RFC 3273 Remote Network Monitoring Management July 2002 DESCRIPTION "The number of octets seen from the source host to the destination host during this sampling interval, modulo 2^32, counted using the rules for counting the nlMatrixSDOctets object." ::= { nlMatrixTopNHighCapacityEntry 10 } nlMatrixTopNHighCapacityOverflowOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen from the source host to the destination host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the nlMatrixSDOctets object." ::= { nlMatrixTopNHighCapacityEntry 11 } nlMatrixTopNHighCapacityOctetRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen from the source host to the destination host during this sampling interval, counted using the rules for counting the nlMatrixSDOctets object. If the value of nlMatrixTopNControlRateBase is nlMatrixTopNHighCapacityOctets, this variable will be used to sort this report." ::= { nlMatrixTopNHighCapacityEntry 12 } nlMatrixTopNHighCapacityReverseBaseOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen from the destination host to the source host during this sampling interval, modulo 2^32, counted using the rules for counting the nlMatrixSDOctets object (note that the corresponding nlMatrixSDOctets object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Waldbusser Standards Track [Page 48] RFC 3273 Remote Network Monitoring Management July 2002 Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNHighCapacityOctets, the sort of topN entries is based entirely on nlMatrixTopNHighCapacityOctetRate, and not on the value of this object." ::= { nlMatrixTopNHighCapacityEntry 13 } nlMatrixTopNHighCapacityReverseOverflowOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen from the destination host to the source host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the nlMatrixSDOctets object (note that the corresponding nlMatrixSDOctets object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNHighCapacityOctets, the sort of topN entries is based entirely on nlMatrixTopNHighCapacityOctetRate, and not on the value of this object." ::= { nlMatrixTopNHighCapacityEntry 14 } nlMatrixTopNHighCapacityReverseOctetRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen from the destination host to the source host during this sampling interval, counted using the rules for counting the nlMatrixSDOctets object (note that the corresponding nlMatrixSDOctets object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNHighCapacityOctets, the sort of topN entries is based entirely on nlMatrixTopNHighCapacityOctetRate, and not on the value of this object." ::= { nlMatrixTopNHighCapacityEntry 15 } -- High Capacity extensions for the alHostTable Waldbusser Standards Track [Page 49] RFC 3273 Remote Network Monitoring Management July 2002 alHostHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF AlHostHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alHostTable." ::= { alHost 2 } alHostHighCapacityEntry OBJECT-TYPE SYNTAX AlHostHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alHostEntry. These objects will be created by the agent for all alHostEntries associated with whichever hlHostControlEntries it deems appropriate. (i.e., either all alHostHighCapacityEntries associated with a particular hlHostControlEntry will be created, or none of them will be.)" INDEX { hlHostControlIndex, alHostTimeMark, protocolDirLocalIndex, nlHostAddress, protocolDirLocalIndex } ::= { alHostHighCapacityTable 1 } AlHostHighCapacityEntry ::= SEQUENCE { alHostHighCapacityInOverflowPkts ZeroBasedCounter32, alHostHighCapacityInPkts ZeroBasedCounter64, alHostHighCapacityOutOverflowPkts ZeroBasedCounter32, alHostHighCapacityOutPkts ZeroBasedCounter64, alHostHighCapacityInOverflowOctets ZeroBasedCounter32, alHostHighCapacityInOctets ZeroBasedCounter64, alHostHighCapacityOutOverflowOctets ZeroBasedCounter32, alHostHighCapacityOutOctets ZeroBasedCounter64 } alHostHighCapacityInOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alHostInPkts counter has overflowed." ::= { alHostHighCapacityEntry 1 } Waldbusser Standards Track [Page 50] RFC 3273 Remote Network Monitoring Management July 2002 alHostHighCapacityInPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type without errors transmitted to this address since it was added to the alHostHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alHostHighCapacityEntry 2 } alHostHighCapacityOutOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alHostOutPkts counter has overflowed." ::= { alHostHighCapacityEntry 3 } alHostHighCapacityOutPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type without errors transmitted by this address since it was added to the alHostHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alHostHighCapacityEntry 4 } alHostHighCapacityInOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alHostInOctets counter has overflowed." ::= { alHostHighCapacityEntry 5 } Waldbusser Standards Track [Page 51] RFC 3273 Remote Network Monitoring Management July 2002 alHostHighCapacityInOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address of this protocol type since it was added to the alHostHighCapacityTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { alHostHighCapacityEntry 6 } alHostHighCapacityOutOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alHostOutOctets counter has overflowed." ::= { alHostHighCapacityEntry 7 } alHostHighCapacityOutOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted by this address of this protocol type since it was added to the alHostHighCapacityTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { alHostHighCapacityEntry 8 } -- High Capacity extensions for the alMatrixSDTable alMatrixSDHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF AlMatrixSDHighCapacityEntry Waldbusser Standards Track [Page 52] RFC 3273 Remote Network Monitoring Management July 2002 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alMatrixSDTable." ::= { alMatrix 5 } alMatrixSDHighCapacityEntry OBJECT-TYPE SYNTAX AlMatrixSDHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alMatrixSDEntry. These objects will be created by the agent for all alMatrixSDEntries associated with whichever hlMatrixControlEntries it deems appropriate. (i.e., either all alMatrixSDHighCapacityEntries associated with a particular hlMatrixControlEntry will be created, or none of them will be.)" INDEX { hlMatrixControlIndex, alMatrixSDTimeMark, protocolDirLocalIndex, nlMatrixSDSourceAddress, nlMatrixSDDestAddress, protocolDirLocalIndex } ::= { alMatrixSDHighCapacityTable 1 } AlMatrixSDHighCapacityEntry ::= SEQUENCE { alMatrixSDHighCapacityOverflowPkts ZeroBasedCounter32, alMatrixSDHighCapacityPkts ZeroBasedCounter64, alMatrixSDHighCapacityOverflowOctets ZeroBasedCounter32, alMatrixSDHighCapacityOctets ZeroBasedCounter64 } alMatrixSDHighCapacityOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alMatrixSDPkts counter has overflowed." ::= { alMatrixSDHighCapacityEntry 1 } alMatrixSDHighCapacityPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 53] RFC 3273 Remote Network Monitoring Management July 2002 "The number of good packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixSDHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alMatrixSDHighCapacityEntry 2 } alMatrixSDHighCapacityOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alMatrixSDOctets counter has overflowed." ::= { alMatrixSDHighCapacityEntry 3 } alMatrixSDHighCapacityOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in good packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixSDHighCapacityTable (excluding framing bits but including FCS octets). Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { alMatrixSDHighCapacityEntry 4 } -- High Capacity extensions for the alMatrixDSTable alMatrixDSHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF AlMatrixDSHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alMatrixDSTable." ::= { alMatrix 6 } alMatrixDSHighCapacityEntry OBJECT-TYPE SYNTAX AlMatrixDSHighCapacityEntry MAX-ACCESS not-accessible Waldbusser Standards Track [Page 54] RFC 3273 Remote Network Monitoring Management July 2002 STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alMatrixSDTable. These objects will be created by the agent for all alMatrixDSEntries associated with whichever hlMatrixControlEntries it deems appropriate. (i.e., either all alMatrixDSHighCapacityEntries associated with a particular hlMatrixControlEntry will be created, or none of them will be.)" INDEX { hlMatrixControlIndex, alMatrixDSTimeMark, protocolDirLocalIndex, nlMatrixDSDestAddress, nlMatrixDSSourceAddress, protocolDirLocalIndex } ::= { alMatrixDSHighCapacityTable 1 } AlMatrixDSHighCapacityEntry ::= SEQUENCE { alMatrixDSHighCapacityOverflowPkts ZeroBasedCounter32, alMatrixDSHighCapacityPkts ZeroBasedCounter64, alMatrixDSHighCapacityOverflowOctets ZeroBasedCounter32, alMatrixDSHighCapacityOctets ZeroBasedCounter64 } alMatrixDSHighCapacityOverflowPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alMatrixDSPkts counter has overflowed." ::= { alMatrixDSHighCapacityEntry 1 } alMatrixDSHighCapacityPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixDSHighCapacityTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alMatrixDSHighCapacityEntry 2 } alMatrixDSHighCapacityOverflowOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 Waldbusser Standards Track [Page 55] RFC 3273 Remote Network Monitoring Management July 2002 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated alMatrixDSOctets counter has overflowed." ::= { alMatrixDSHighCapacityEntry 3 } alMatrixDSHighCapacityOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in good packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixDSHighCapacityTable (excluding framing bits but including FCS octets). Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { alMatrixDSHighCapacityEntry 4 } alMatrixTopNHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF AlMatrixTopNHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alMatrixTopNTable when alMatrixTopNControlRateBase specifies a High Capacity TopN Report." ::= { alMatrix 7 } alMatrixTopNHighCapacityEntry OBJECT-TYPE SYNTAX AlMatrixTopNHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 alMatrixTopNEntry when alMatrixTopNControlRateBase specifies a High Capacity TopN Report. These objects will be created by the agent for all alMatrixTopNEntries associated with whichever alMatrixTopNControlEntries have a alMatrixTopNControlRateBase that specify a high capacity report." INDEX { alMatrixTopNControlIndex, alMatrixTopNIndex } ::= { alMatrixTopNHighCapacityTable 1 } Waldbusser Standards Track [Page 56] RFC 3273 Remote Network Monitoring Management July 2002 AlMatrixTopNHighCapacityEntry ::= SEQUENCE { alMatrixTopNHighCapacityProtocolDirLocalIndex Integer32, alMatrixTopNHighCapacitySourceAddress OCTET STRING, alMatrixTopNHighCapacityDestAddress OCTET STRING, alMatrixTopNHighCapacityAppProtocolDirLocalIndex Integer32, alMatrixTopNHighCapacityBasePktRate Gauge32, alMatrixTopNHighCapacityOverflowPktRate Gauge32, alMatrixTopNHighCapacityPktRate CounterBasedGauge64, alMatrixTopNHighCapacityReverseBasePktRate Gauge32, alMatrixTopNHighCapacityReverseOverflowPktRate Gauge32, alMatrixTopNHighCapacityReversePktRate CounterBasedGauge64, alMatrixTopNHighCapacityBaseOctetRate Gauge32, alMatrixTopNHighCapacityOverflowOctetRate Gauge32, alMatrixTopNHighCapacityOctetRate CounterBasedGauge64, alMatrixTopNHighCapacityReverseBaseOctetRate Gauge32, alMatrixTopNHighCapacityReverseOverflowOctetRate Gauge32, alMatrixTopNHighCapacityReverseOctetRate CounterBasedGauge64 } alMatrixTopNHighCapacityProtocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex of the network layer protocol of this entry's network address." ::= { alMatrixTopNHighCapacityEntry 1 } alMatrixTopNHighCapacitySourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { alMatrixTopNHighCapacityEntry 2 } alMatrixTopNHighCapacityDestAddress OBJECT-TYPE SYNTAX OCTET STRING Waldbusser Standards Track [Page 57] RFC 3273 Remote Network Monitoring Management July 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { alMatrixTopNHighCapacityEntry 3 } alMatrixTopNHighCapacityAppProtocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the protocol counted by this entry." ::= { alMatrixTopNHighCapacityEntry 4 } alMatrixTopNHighCapacityBasePktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the source host to the destination host during this sampling interval, modulo 2^32, counted using the rules for counting the alMatrixSDPkts object." ::= { alMatrixTopNHighCapacityEntry 5 } alMatrixTopNHighCapacityOverflowPktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the source host to the destination host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the alMatrixSDPkts object." ::= { alMatrixTopNHighCapacityEntry 6 } Waldbusser Standards Track [Page 58] RFC 3273 Remote Network Monitoring Management July 2002 alMatrixTopNHighCapacityPktRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the alMatrixSDPkts object. If the value of alMatrixTopNControlRateBase is alMatrixTopNTerminalsPkts, alMatrixTopNAllPkts, alMatrixTopNTerminalsHighCapacityPkts, or alMatrixTopNAllHighCapacityPkts, this variable will be used to sort this report." ::= { alMatrixTopNHighCapacityEntry 7 } alMatrixTopNHighCapacityReverseBasePktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the destination host to the source host during this sampling interval, modulo 2^32, counted using the rules for counting the alMatrixSDPkts object (note that the corresponding alMatrixSDPkts object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.)" ::= { alMatrixTopNHighCapacityEntry 8 } alMatrixTopNHighCapacityReverseOverflowPktRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the destination host to the source host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the alMatrixSDPkts object (note that the corresponding alMatrixSDPkts object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.)" ::= { alMatrixTopNHighCapacityEntry 9 } Waldbusser Standards Track [Page 59] RFC 3273 Remote Network Monitoring Management July 2002 alMatrixTopNHighCapacityReversePktRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the alMatrixSDPkts object (note that the corresponding alMatrixSDPkts object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.)" ::= { alMatrixTopNHighCapacityEntry 10 } alMatrixTopNHighCapacityBaseOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the source host to the destination host during this sampling interval, modulo 2^32, counted using the rules for counting the alMatrixSDOctets object." ::= { alMatrixTopNHighCapacityEntry 11 } alMatrixTopNHighCapacityOverflowOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the source host to the destination host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the alMatrixSDOctets object." ::= { alMatrixTopNHighCapacityEntry 12 } alMatrixTopNHighCapacityOctetRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the source host to the destination host during this sampling interval, Waldbusser Standards Track [Page 60] RFC 3273 Remote Network Monitoring Management July 2002 counted using the rules for counting the alMatrixSDOctets object. If the value of alMatrixTopNControlRateBase is alMatrixTopNTerminalsOctets, alMatrixTopNAllOctets, alMatrixTopNTerminalsHighCapacityOctets, or alMatrixTopNAllHighCapacityOctets, this variable will be used to sort this report." ::= { alMatrixTopNHighCapacityEntry 13 } alMatrixTopNHighCapacityReverseBaseOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the destination host to the source host during this sampling interval, modulo 2^32, counted using the rules for counting the alMatrixSDOctets object (note that the corresponding alMatrixSDOctets object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.)" ::= { alMatrixTopNHighCapacityEntry 14 } alMatrixTopNHighCapacityReverseOverflowOctetRate OBJECT-TYPE SYNTAX Gauge32 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the destination host to the source host during this sampling interval, divided by 2^32, truncating fractions (i.e., X DIV 2^32), and counted using the rules for counting the alMatrixSDOctets object (note that the corresponding alMatrixSDOctets object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.)" ::= { alMatrixTopNHighCapacityEntry 15 } alMatrixTopNHighCapacityReverseOctetRate OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the destination host to the source host during this sampling Waldbusser Standards Track [Page 61] RFC 3273 Remote Network Monitoring Management July 2002 interval, counted using the rules for counting the alMatrixSDOctets object (note that the corresponding alMatrixSDOctets object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.)" ::= { alMatrixTopNHighCapacityEntry 16 } usrHistoryHighCapacityTable OBJECT-TYPE SYNTAX SEQUENCE OF UsrHistoryHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 usrHistoryTable." ::= { usrHistory 4 } usrHistoryHighCapacityEntry OBJECT-TYPE SYNTAX UsrHistoryHighCapacityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the High Capacity RMON extensions to the RMON-2 usrHistoryEntry. These objects will be created by the agent for all usrHistoryEntries associated with whichever usrHistoryControlEntries it deems appropriate. (i.e., either all usrHistoryHighCapacityEntries associated with a particular usrHistoryControlEntry will be created, or none of them will be.)" INDEX { usrHistoryControlIndex, usrHistorySampleIndex, usrHistoryObjectIndex } ::= { usrHistoryHighCapacityTable 1 } UsrHistoryHighCapacityEntry ::= SEQUENCE { usrHistoryHighCapacityOverflowAbsValue Gauge32, usrHistoryHighCapacityAbsValue CounterBasedGauge64 } usrHistoryHighCapacityOverflowAbsValue OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The absolute value (i.e. unsigned value) of the user-specified statistic during the last sampling period, divided by 2^32, truncating fractions (i.e., X DIV 2^32). The value during the current sampling period is not made available until the period is completed. Waldbusser Standards Track [Page 62] RFC 3273 Remote Network Monitoring Management July 2002 To obtain the true value for this sampling interval, the associated instance of usrHistoryValStatus should be checked, and usrHistoryAbsValue adjusted as necessary. If the MIB instance could not be accessed during the sampling interval, then this object will have a value of zero and the associated instance of usrHistoryValStatus will be set to 'valueNotAvailable(1)'." ::= { usrHistoryHighCapacityEntry 1 } usrHistoryHighCapacityAbsValue OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The absolute value (i.e. unsigned value) of the user-specified statistic during the last sampling period. The value during the current sampling period is not made available until the period is completed. To obtain the true value for this sampling interval, the associated instance of usrHistoryValStatus should be checked, and usrHistoryHighCapacityAbsValue adjusted as necessary. If the MIB instance could not be accessed during the sampling interval, then this object will have a value of zero and the associated instance of usrHistoryValStatus will be set to 'valueNotAvailable(1)'." ::= { usrHistoryHighCapacityEntry 2 } -- -- High Capacity RMON Probe Capabilities -- hcRMONCapabilities OBJECT-TYPE SYNTAX BITS { mediaIndependentGroup(0), etherStatsHighCapacityGroup(1), etherHistoryHighCapacityGroup(2), hostHighCapacityGroup(3), hostTopNHighCapacityGroup(4), matrixHighCapacityGroup(5), captureBufferHighCapacityGroup(6), protocolDistributionHighCapacityGroup(7), nlHostHighCapacityGroup(8), nlMatrixHighCapacityGroup(9), nlMatrixTopNHighCapacityGroup(10), alHostHighCapacityGroup(11), alMatrixHighCapacityGroup(12), Waldbusser Standards Track [Page 63] RFC 3273 Remote Network Monitoring Management July 2002 alMatrixTopNHighCapacityGroup(13), usrHistoryHighCapacityGroup(14) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the High Capacity RMON MIB groups supported on at least one interface by this probe." ::= { probeConfig 16 } -- Conformance Macros hcRmonMIBCompliances OBJECT IDENTIFIER ::= { rmonConformance 6 } hcRmonMIBGroups OBJECT IDENTIFIER ::= { rmonConformance 7 } hcMediaIndependentCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the High Capacity Media Independent Group." MODULE -- this module MANDATORY-GROUPS { mediaIndependentGroup, hcRMONInformationGroup } ::= { hcRmonMIBCompliances 1 } hcRmon1MIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the High Capacity RMON-1 MIB" MODULE -- this module GROUP etherStatsHighCapacityGroup DESCRIPTION "The etherStatsHighCapacityGroup is optional but requires implementation of the rmonEtherStatsGroup." GROUP etherHistoryHighCapacityGroup DESCRIPTION "The etherHistoryHighCapacityGroup is optional but requires implementation of the rmonHistoryControlGroup and rmonEthernetHistoryGroup." GROUP hostHighCapacityGroup DESCRIPTION "The hostHighCapacityGroup is mandatory when the hostTopNHighCapacityGroup is implemented. This group also requires implementation of the rmonHostGroup." GROUP hostTopNHighCapacityGroup Waldbusser Standards Track [Page 64] RFC 3273 Remote Network Monitoring Management July 2002 DESCRIPTION "The hostTopNHighCapacityGroup is optional but requires implementation of the rmonHostTopNGroup." GROUP matrixHighCapacityGroup DESCRIPTION "The matrixHighCapacityGroup is optional but requires implementation of the rmonMatrixGroup." GROUP captureBufferHighCapacityGroup DESCRIPTION "The captureBufferHighCapacityGroup is optional but requires implementation of the rmonFilterGroup and rmonPacketCaptureGroup." MODULE RMON-MIB GROUP rmonEtherStatsGroup DESCRIPTION "The RMON Ethernet Statistics Group is mandatory if the etherStatsHighCapacityGroup is implemented." GROUP rmonHistoryControlGroup DESCRIPTION "The RMON History Control Group is mandatory if the etherHistoryHighCapacityGroup is implemented." GROUP rmonEthernetHistoryGroup DESCRIPTION "The RMON Ethernet History Group is mandatory if the etherHistoryHighCapacityGroup is implemented." GROUP rmonHostGroup DESCRIPTION "The RMON Host Group is mandatory if the hostHighCapacityGroup is implemented." GROUP rmonHostTopNGroup DESCRIPTION "The RMON Host Top N Group is mandatory if the hostTopNHighCapacityGroup is implemented." GROUP rmonMatrixGroup DESCRIPTION "The RMON Matrix Group is mandatory if the matrixHighCapacityGroup is implemented." GROUP rmonFilterGroup DESCRIPTION Waldbusser Standards Track [Page 65] RFC 3273 Remote Network Monitoring Management July 2002 "The RMON Filter Group is mandatory when the captureBufferHighCapacityGroup is implemented." GROUP rmonPacketCaptureGroup DESCRIPTION "The RMON Packet Capture Group is mandatory when the captureBufferHighCapacityGroup is implemented." ::= { hcRmonMIBCompliances 2 } hcRmon2MIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the High Capacity RMON-2 MIB" MODULE -- this module MANDATORY-GROUPS { protocolDistributionHighCapacityGroup, nlHostHighCapacityGroup, nlMatrixHighCapacityGroup, nlMatrixTopNHighCapacityGroup, usrHistoryHighCapacityGroup, hcRMONInformationGroup } MODULE RMON2-MIB MANDATORY-GROUPS { protocolDirectoryGroup, protocolDistributionGroup, addressMapGroup, nlHostGroup, nlMatrixGroup, usrHistoryGroup, probeInformationGroup } GROUP rmon1EnhancementGroup DESCRIPTION "The rmon1EnhancementGroup is mandatory for systems which implement RMON [RFC2819]" ::= { hcRmonMIBCompliances 3 } hcRmon2MIBApplicationLayerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the High Capacity RMON-2 MIB with Application Layer Enhancements." MODULE -- this module MANDATORY-GROUPS { protocolDistributionHighCapacityGroup, nlHostHighCapacityGroup, nlMatrixHighCapacityGroup, Waldbusser Standards Track [Page 66] RFC 3273 Remote Network Monitoring Management July 2002 nlMatrixTopNHighCapacityGroup, alHostHighCapacityGroup, alMatrixHighCapacityGroup, alMatrixTopNHighCapacityGroup, usrHistoryHighCapacityGroup, hcRMONInformationGroup } MODULE RMON2-MIB MANDATORY-GROUPS { protocolDirectoryGroup, protocolDistributionGroup, addressMapGroup, nlHostGroup, nlMatrixGroup, alHostGroup, alMatrixGroup, usrHistoryGroup, probeInformationGroup } GROUP rmon1EnhancementGroup DESCRIPTION "The rmon1EnhancementGroup is mandatory for systems which implement RMON [RFC2819]" ::= { hcRmonMIBCompliances 4 } mediaIndependentGroup OBJECT-GROUP OBJECTS {mediaIndependentDataSource, mediaIndependentDropEvents, mediaIndependentDroppedFrames, mediaIndependentInPkts, mediaIndependentInOverflowPkts, mediaIndependentInHighCapacityPkts, mediaIndependentOutPkts, mediaIndependentOutOverflowPkts, mediaIndependentOutHighCapacityPkts, mediaIndependentInOctets, mediaIndependentInOverflowOctets, mediaIndependentInHighCapacityOctets, mediaIndependentOutOctets, mediaIndependentOutOverflowOctets, mediaIndependentOutHighCapacityOctets, mediaIndependentInNUCastPkts, mediaIndependentInNUCastOverflowPkts, mediaIndependentInNUCastHighCapacityPkts, mediaIndependentOutNUCastPkts, mediaIndependentOutNUCastOverflowPkts, mediaIndependentOutNUCastHighCapacityPkts, mediaIndependentInErrors, mediaIndependentOutErrors, mediaIndependentInputSpeed, Waldbusser Standards Track [Page 67] RFC 3273 Remote Network Monitoring Management July 2002 mediaIndependentOutputSpeed, mediaIndependentDuplexMode, mediaIndependentDuplexChanges, mediaIndependentDuplexLastChange, mediaIndependentOwner, mediaIndependentStatus } STATUS current DESCRIPTION "Collects utilization statistics for any type of network." ::= { hcRmonMIBGroups 1 } etherStatsHighCapacityGroup OBJECT-GROUP OBJECTS { etherStatsHighCapacityOverflowPkts, etherStatsHighCapacityPkts, etherStatsHighCapacityOverflowOctets, etherStatsHighCapacityOctets, etherStatsHighCapacityOverflowPkts64Octets, etherStatsHighCapacityPkts64Octets, etherStatsHighCapacityOverflowPkts65to127Octets, etherStatsHighCapacityPkts65to127Octets, etherStatsHighCapacityOverflowPkts128to255Octets, etherStatsHighCapacityPkts128to255Octets, etherStatsHighCapacityOverflowPkts256to511Octets, etherStatsHighCapacityPkts256to511Octets, etherStatsHighCapacityOverflowPkts512to1023Octets, etherStatsHighCapacityPkts512to1023Octets, etherStatsHighCapacityOverflowPkts1024to1518Octets, etherStatsHighCapacityPkts1024to1518Octets } STATUS current DESCRIPTION "Collects utilization statistics for ethernet networks." ::= { hcRmonMIBGroups 2 } etherHistoryHighCapacityGroup OBJECT-GROUP OBJECTS { etherHistoryHighCapacityOverflowPkts, etherHistoryHighCapacityPkts, etherHistoryHighCapacityOverflowOctets, etherHistoryHighCapacityOctets } STATUS current DESCRIPTION "Collects utilization statistics for ethernet networks." ::= { hcRmonMIBGroups 3 } hostHighCapacityGroup OBJECT-GROUP OBJECTS { hostHighCapacityInOverflowPkts, hostHighCapacityInPkts, hostHighCapacityOutOverflowPkts, hostHighCapacityOutPkts, Waldbusser Standards Track [Page 68] RFC 3273 Remote Network Monitoring Management July 2002 hostHighCapacityInOverflowOctets, hostHighCapacityInOctets, hostHighCapacityOutOverflowOctets, hostHighCapacityOutOctets, hostTimeHighCapacityInOverflowPkts, hostTimeHighCapacityInPkts, hostTimeHighCapacityOutOverflowPkts, hostTimeHighCapacityOutPkts, hostTimeHighCapacityInOverflowOctets, hostTimeHighCapacityInOctets, hostTimeHighCapacityOutOverflowOctets, hostTimeHighCapacityOutOctets } STATUS current DESCRIPTION "Collects utilization and error statistics per host." ::= { hcRmonMIBGroups 4 } hostTopNHighCapacityGroup OBJECT-GROUP OBJECTS { hostTopNHighCapacityAddress, hostTopNHighCapacityBaseRate, hostTopNHighCapacityOverflowRate, hostTopNHighCapacityRate } STATUS current DESCRIPTION "Prepares sorted reports of utilization and error statistics per host." ::= { hcRmonMIBGroups 5 } matrixHighCapacityGroup OBJECT-GROUP OBJECTS { matrixSDHighCapacityOverflowPkts, matrixSDHighCapacityPkts, matrixSDHighCapacityOverflowOctets, matrixSDHighCapacityOctets, matrixDSHighCapacityOverflowPkts, matrixDSHighCapacityPkts, matrixDSHighCapacityOverflowOctets, matrixDSHighCapacityOctets } STATUS current DESCRIPTION "Collects utilization statistics per conversation." ::= { hcRmonMIBGroups 6 } captureBufferHighCapacityGroup OBJECT-GROUP OBJECTS { captureBufferPacketHighCapacityTime } STATUS current DESCRIPTION "Provides finer granularity time stamps." Waldbusser Standards Track [Page 69] RFC 3273 Remote Network Monitoring Management July 2002 ::= { hcRmonMIBGroups 7 } protocolDistributionHighCapacityGroup OBJECT-GROUP OBJECTS { protocolDistStatsHighCapacityOverflowPkts, protocolDistStatsHighCapacityPkts, protocolDistStatsHighCapacityOverflowOctets, protocolDistStatsHighCapacityOctets } STATUS current DESCRIPTION "Collects the relative amounts of octets and packets for the different protocols detected on a network segment." ::= { hcRmonMIBGroups 8 } nlHostHighCapacityGroup OBJECT-GROUP OBJECTS { nlHostHighCapacityInOverflowPkts, nlHostHighCapacityInPkts, nlHostHighCapacityOutOverflowPkts, nlHostHighCapacityOutPkts, nlHostHighCapacityInOverflowOctets, nlHostHighCapacityInOctets, nlHostHighCapacityOutOverflowOctets, nlHostHighCapacityOutOctets } STATUS current DESCRIPTION "Counts the amount of traffic sent from and to each network address discovered by the probe." ::= { hcRmonMIBGroups 9 } nlMatrixHighCapacityGroup OBJECT-GROUP OBJECTS { nlMatrixSDHighCapacityOverflowPkts, nlMatrixSDHighCapacityPkts, nlMatrixSDHighCapacityOverflowOctets, nlMatrixSDHighCapacityOctets, nlMatrixDSHighCapacityOverflowPkts, nlMatrixDSHighCapacityPkts, nlMatrixDSHighCapacityOverflowOctets, nlMatrixDSHighCapacityOctets } STATUS current DESCRIPTION "Counts the amount of traffic sent between each pair of network addresses discovered by the probe." ::= { hcRmonMIBGroups 10 } nlMatrixTopNHighCapacityGroup OBJECT-GROUP OBJECTS { nlMatrixTopNHighCapacityProtocolDirLocalIndex, nlMatrixTopNHighCapacitySourceAddress, nlMatrixTopNHighCapacityDestAddress, nlMatrixTopNHighCapacityBasePktRate, Waldbusser Standards Track [Page 70] RFC 3273 Remote Network Monitoring Management July 2002 nlMatrixTopNHighCapacityOverflowPktRate, nlMatrixTopNHighCapacityPktRate, nlMatrixTopNHighCapacityReverseBasePktRate, nlMatrixTopNHighCapacityReverseOverflowPktRate, nlMatrixTopNHighCapacityReversePktRate, nlMatrixTopNHighCapacityBaseOctetRate, nlMatrixTopNHighCapacityOverflowOctetRate, nlMatrixTopNHighCapacityOctetRate, nlMatrixTopNHighCapacityReverseBaseOctetRate, nlMatrixTopNHighCapacityReverseOverflowOctetRate, nlMatrixTopNHighCapacityReverseOctetRate } STATUS current DESCRIPTION "Prepares sorted reports of the amount of traffic sent between each pair of network addresses discovered by the probe." ::= { hcRmonMIBGroups 11 } alHostHighCapacityGroup OBJECT-GROUP OBJECTS { alHostHighCapacityInOverflowPkts, alHostHighCapacityInPkts, alHostHighCapacityOutOverflowPkts, alHostHighCapacityOutPkts, alHostHighCapacityInOverflowOctets, alHostHighCapacityInOctets, alHostHighCapacityOutOverflowOctets, alHostHighCapacityOutOctets } STATUS current DESCRIPTION "Counts the amount of traffic, by protocol, sent from and to each network address discovered by the probe." ::= { hcRmonMIBGroups 12 } alMatrixHighCapacityGroup OBJECT-GROUP OBJECTS { alMatrixSDHighCapacityOverflowPkts, alMatrixSDHighCapacityPkts, alMatrixSDHighCapacityOverflowOctets, alMatrixSDHighCapacityOctets, alMatrixDSHighCapacityOverflowPkts, alMatrixDSHighCapacityPkts, alMatrixDSHighCapacityOverflowOctets, alMatrixDSHighCapacityOctets } STATUS current DESCRIPTION "Counts the amount of traffic, by protocol, sent between each pair of network addresses discovered by the probe." ::= { hcRmonMIBGroups 13 } Waldbusser Standards Track [Page 71] RFC 3273 Remote Network Monitoring Management July 2002 alMatrixTopNHighCapacityGroup OBJECT-GROUP OBJECTS { alMatrixTopNHighCapacityProtocolDirLocalIndex, alMatrixTopNHighCapacitySourceAddress, alMatrixTopNHighCapacityDestAddress, alMatrixTopNHighCapacityAppProtocolDirLocalIndex, alMatrixTopNHighCapacityBasePktRate, alMatrixTopNHighCapacityOverflowPktRate, alMatrixTopNHighCapacityPktRate, alMatrixTopNHighCapacityReverseBasePktRate, alMatrixTopNHighCapacityReverseOverflowPktRate, alMatrixTopNHighCapacityReversePktRate, alMatrixTopNHighCapacityBaseOctetRate, alMatrixTopNHighCapacityOverflowOctetRate, alMatrixTopNHighCapacityOctetRate, alMatrixTopNHighCapacityReverseBaseOctetRate, alMatrixTopNHighCapacityReverseOverflowOctetRate, alMatrixTopNHighCapacityReverseOctetRate } STATUS current DESCRIPTION "Prepares sorted reports of the amount of traffic per protocol sent between each pair of network addresses discovered by the probe." ::= { hcRmonMIBGroups 14 } usrHistoryHighCapacityGroup OBJECT-GROUP OBJECTS { usrHistoryHighCapacityOverflowAbsValue, usrHistoryHighCapacityAbsValue } STATUS current DESCRIPTION "Provides user-defined collection of historical information from MIB objects on the probe with scalability to statistics from high-capacity networks." ::= { hcRmonMIBGroups 15 } hcRMONInformationGroup OBJECT-GROUP OBJECTS { hcRMONCapabilities } STATUS current DESCRIPTION "An indication of the high capacity RMON groups supported on at least one interface by this probe." ::= { hcRmonMIBGroups 16 } END Waldbusser Standards Track [Page 72] RFC 3273 Remote Network Monitoring Management July 2002 6. Security Considerations In order to implement this MIB, a probe must capture all packets on the locally-attached network, including packets between third parties. These packets are analyzed to collect network addresses, protocol usage information, and conversation statistics. Data of this nature may be considered sensitive in some environments. In such environments the administrator may wish to restrict SNMP access to the probe. A probe implementing this MIB is likely to also implement RMON [RFC 2819], which includes functions for returning the contents of captured packets, potentially including sensitive user data or passwords. It is recommended that SNMP access to these functions be restricted. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Acknowledgments This document was produced by the IETF Remote Network Monitoring Working Group. 8. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. Waldbusser Standards Track [Page 73] RFC 3273 Remote Network Monitoring Management July 2002 [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] 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. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] 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. [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. Waldbusser Standards Track [Page 74] RFC 3273 Remote Network Monitoring Management July 2002 [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [18] Waldbusser, S., "Remote Network Monitoring MIB", STD 59, RFC 2819, May 2000. [19] Waldbusser, S., "Token Ring Extensions to the Remote Network Monitoring MIB", RFC 1513, September 1993. [20] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [21] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework, RFC 2570, April 1999. 9. Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Waldbusser Standards Track [Page 75] RFC 3273 Remote Network Monitoring Management July 2002 10. Author's Address Steve Waldbusser Phone: +1-650-948-6500 Fax: +1-650-745-0671 EMail: waldbusser@nextbeacon.com Waldbusser Standards Track [Page 76] RFC 3273 Remote Network Monitoring Management July 2002 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Waldbusser Standards Track [Page 77] snmp-mibs-downloader-1.1/mibrfcs/rfc3287.txt0000644000000000000000000074742611402176071015611 0ustar Network Working Group A. Bierman Request for Comments: 3287 Cisco Systems, Inc. Category: Standards Track July 2002 Remote Monitoring MIB Extensions for Differentiated Services 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. Table of Contents 1 The SNMP Network Management Framework ........................... 2 2 Overview ........................................................ 3 2.1 Terms ......................................................... 4 2.2 Relationship to Differentiated Services ....................... 4 2.3 Relationship to the Remote Monitoring MIBs .................... 5 3 MIB Structure ................................................... 6 3.1 DSCP Counter Aggregation ...................................... 7 3.1.1 Counter Aggregation Configuration .......................... 8 3.2 MIB Group Overview ........................................... 8 3.2.1 DSCP Counter Aggregation Control Group ..................... 9 3.2.2 DS Statistics Group ........................................ 10 3.2.3 DS Protocol Distribution Group ............................. 10 3.2.4 DS Host Distribution Group ................................. 11 3.2.5 DSMON Capabilities Group ................................... 12 3.2.6 DS Matrix Distribution Group ............................... 13 3.3 RMON vs. DSMON Indexing Structure ............................ 13 4 Definitions .................................................... 16 Bierman Standards Track [Page 1] RFC 3287 DSMON MIB July 2002 5 Counter Aggregation Configuration Usage Examples .............. 108 5.1 Step 1: Unlock the Counter Aggregation Configuration ........ 109 5.2 Step 2: Check the Maximum number of Counter Aggregation Groups ..................................................... 109 5.3 Step 3: Check if the counter aggregation profiles already exist ...................................................... 109 5.4 Step 4: Create the Counter Aggregation Control Entries ...... 109 5.5 Step 5: Create the Counter Aggregation Group Descriptions ............................................................ 110 5.6 Step 6: Create the Counter Aggregation Profile Mappings ..... 112 5.7 Step 7: Lock the Counter Aggregation Configuration .......... 115 6 Intellectual Property ......................................... 115 7 Acknowledgements .............................................. 116 8 References .................................................... 116 9 Security Considerations ....................................... 118 10 Author's Address ............................................. 119 11 Full Copyright Statement ..................................... 120 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. Bierman Standards Track [Page 2] RFC 3287 DSMON MIB July 2002 o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview There is a need for a standardized way of monitoring the network traffic usage of Differentiated Services (DS) [RFC2474] codepoint values. Each DS codepoint (DSCP) value may be given a different treatment by a forwarding device, and this affects which packets get dropped or delayed during periods of network congestion. The IETF DIFFSERV working group has redefined the semantics of the Type of Service (TOS) octet in the IP header, which is now called the 'DS field'. The 6-bit Codepoint (DSCP) portion is contained in the DS field, which provides for 64 different packet treatments for the implementation of differentiated network services. By polling DSCP usage counters, an NMS can determine the network throughput for traffic associated with different DSCPs. This data can then be analyzed in order to 'tune' DSCP 'allocations' within a network, based on the Quality of Service (QoS) policies for that network. Remote monitoring agents are typically implemented as independent software (and sometimes hardware) components, called 'RMON probes'. Note that DSMON-capable RMON probes simply collect and aggregate statistics, based on criteria (which includes the DSCP value) that can be determined by inspecting the contents of monitored packets and do not in any way monitor any aspect of a DS forwarding device's internal statistics. Bierman Standards Track [Page 3] RFC 3287 DSMON MIB July 2002 2.1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119. [RFC2119] This document uses some terms that need introduction: DataSource A source of data for monitoring purposes. This term is used exactly as defined in the RMON-2 MIB [RFC2021]. protocol A specific protocol encapsulation, as identified for monitoring purposes. This term is used exactly as defined in the RMON Protocol Identifiers document [RFC2074]. Counter Aggregation Group A group of statistical counters that are being combined in the agent to produce one aggregated counter. Refer to sections 3.1 and 3.2.1 for details on counter aggregation groups. Counter Aggregation Profile Also called 'profile'; A complete set of counter aggregation group mappings for DSCP values (i.e., 64 mappings, for each DSCP values 0 to 63), which are applied to all monitored packets on a particular data source and/or DSMON collection. Refer to sections 3.1 and 3.2.1 for details on counter aggregation profiles. High Capacity Monitoring The generic capability to collect and store statistics with an internal range of 64 bits (e.g., Counter64). This term does not refer to implementation of the High Capacity RMON MIB [RFC3273]. 2.2. Relationship to Differentiated Services The DSMON MIB is a product of the RMONMIB WG, not the DIFFSERV WG, and it focuses on extending several existing RMON mechanisms to support additional packet classification, based on DSCP values observed in monitored packets. This document assumes the reader is familiar with the DS Architecture [RFC2475]. It is expected that complex management applications will use the counters in this MIB to help analyze DS-related throughput. It is expected that other metrics, such as delay and jitter, will also be analyzed, but support for other metrics is outside the scope of this document. Bierman Standards Track [Page 4] RFC 3287 DSMON MIB July 2002 2.3. Relationship to the Remote Monitoring MIBs This MIB is intended to be implemented in Remote Monitoring (RMON) probes, which support the RMON-2 MIB [RFC2021]. Such probes may be stand-alone devices, or may be co-located with other networking devices (e.g., ethernet switches and repeaters). The DSMON functions are intended to be implemented in conjunction with the associated RMON functions, but the MIB is independent of all other RMON data tables. Several concepts and even MIB objects from the RMON MIBs are used in the DSMON MIB: Protocol Directory The RMON-2 MIB [RFC2021] defines the protocolDirTable, which is a directory of all the protocols that the RMON-2 agent is capable of decoding and counting. The DSMON MIB utilizes this directory to identify the protocols detected in monitored packets. The protocolDirLocalIndex MIB object is used to identify protocol encapsulations in all DSMON data tables which classify and aggregate by protocol type in some manner. Note that the protocolDirTable is used for protocol identification only, independent of DSCP classification. TimeFilter The RMON-2 TimeFilter textual convention provides a mechanism to retrieve only rows which have been created or modified since the last polling interval (for a particular NMS). The DSMON MIB uses this textual convention in the large data tables, in order to minimize polling impact. Zero-Based Counters Since counters are instantiated by management action, as in the RMON MIBs, the DSMON MIB uses zero-based counters in all data collection tables. Specifically, the ZeroBasedCounter32 textual convention from the RMON-2 MIB [RFC2021] and the ZeroBasedCounter64 textual convention (defined in the HCNUM-TC MIB [RFC2856]) are used to define counter objects in this MIB. High Capacity Counters The DSMON MIB uses the 'SNMPv1 coexistence' strategy adopted by the RMONMIB WG. That is, where a 64-bit counter is provided, a 32-bit version of the counter, and a 32-bit overflow counter are also provided. Bierman Standards Track [Page 5] RFC 3287 DSMON MIB July 2002 TopN Reports The DSMON MIB uses the same TopN reporting MIB structure as the RMON-2 MIB [RFC2021]. TopN reporting can greatly reduce the polling overhead required to analyze DSCP usage patterns. Some DESCRIPTION clauses for DSMON objects are very similar to those for existing RMON-2 or HC-RMON objects. This is intentional, since the semantics of the DSMON features are designed to be as close to existing RMON feature as possible, to allow developers and users some level of 'MIB re-use'. 3. MIB Structure Figure 1: DSMON MIB Functional Structure +--------------+ +---------------+ | | | Counter | | DSMON | | Aggregation | | Capabilities | | Control | | | | | +--------------+ +---------------+ | | +------------------------------+----------------------------+ | V | | | | +-----------+ +-----------+ +-----------+ +------------+ | | | | | | | | | | | | | Data Src | | Protocol | | Net. Host | | App Matrix | | | | Stats | | Stats | | Stats | | Stats | | | | | | | | | | | | | +-----------+ +-----------+ +-----------+ +------------+ | | | | | | | V V V | | +-----------+ +-----------+ +------------+ | | | | | | | | | | | Protocol | | Net. Host | | App Matrix | | | | TopN | | TopN | | TopN | | | | | | | | | | | +-----------+ +-----------+ +------------+ | | | | Data Collection | | | +-----------------------------------------------------------+ Bierman Standards Track [Page 6] RFC 3287 DSMON MIB July 2002 The DSMON MIB can divided into three functional components: - DSMON Capabilities Describes which DSMON object groups are supported by the agent on at least one data source. - Counter Aggregation Control Controls how individual DIFFSERV codepoint counters are aggregated in DSMON data collections. - Data Collection Controls how individual statistical collections are maintained by the agent and reported to management applications. The individual boxes within the Data Collection box represent the DSMON data collections (described in section 3.2): - Data Source Statistics - Protocol Statistics - Protocol Statistics TopN Reporting - Network Protocol Host Statistics - Network Protocol Host Statistics TopN Reporting - Application Protocol Matrix Statistics - Application Protocol Matrix Statistics TopN Reporting 3.1. DSCP Counter Aggregation A mechanism to configure the agent to internally aggregate counters is provided, based on DSCP values. This is desirable for several reasons: - agent data reduction An agent implementation can potentially reduce the number of counters maintained for a given DSMON collection. - agent data collection limitations Some implementation strategies might provide for a limited number of high-speed (e.g., hardware-based) counters for either single or aggregated codepoints. - application data retrieval reduction Applications that would otherwise aggregate counters for individual codepoints can move that function to the agent in order to reduce the polling overhead on the application, the network, and the agent device. - some unused codepoints at this time Various DSCP values may be expected to remain unused on a given network, and may be aggregated for counting purposes. Bierman Standards Track [Page 7] RFC 3287 DSMON MIB July 2002 - some DSCP values are mapped to the same packet treatment A network administrator may align the counter aggregation configuration of the monitoring device with the DS configuration, and aggregate statistics for DSCP values which are expected to receive the same treatment by the forwarding devices. 3.1.1. Counter Aggregation Configuration The configuration of DSCP counter to counter aggregation group mappings is managed in a global manner, so that these settings can be shared across several DSMON collections and/or data sources. One complete set of DSCP counter mappings is called a counter aggregation profile. The DSMON control tables are very similar to existing RMON-2 control tables, except they contain an extra parameter to identify the counter aggregation profile the agent should use for the collection. The appropriate granularity for counter aggregation profile assignment may be the data source, but in order to reduce MIB complexity (by avoiding an extra layer of tables), an instance of the counter aggregation profile parameter exists for each collection. An agent MAY choose to restrict configurations such that all DSMON data collections for the same data source must use the same counter aggregation profile. The DSMON MIB supports the configuration of an arbitrary number of counter aggregation profiles. There is a top-level counter aggregation control table, which contains one entry for each counter aggregation profile. A subordinate counter aggregation profile table provides information about each DSCP counter to counter aggregation group mapping in each profile. An auxiliary counter aggregation group table also provides descriptive information about each counter aggregation group in each profile. Refer to section 3.2.1 for details on these MIB objects. 3.2. MIB Group Overview The DSMON MIB contains six groups of MIB objects: - dsmonAggregateControl group Controls the configuration of counter aggregation groups for the purpose of reducing the total number of counters maintained by the agent. - dsmonStatsObjects group Report per counter aggregation group distribution statistics for a particular RMON dataSource. Bierman Standards Track [Page 8] RFC 3287 DSMON MIB July 2002 - dsmonPdistObjects group Report per counter aggregation group distribution statistics for each application protocol detected on a particular RMON dataSource. - dsmonHostObjects group Report host address distribution statistics for each counter aggregation group, detected on a particular RMON dataSource. - dsmonCapsObjects group Report the static DSMON MIB functional capabilities of the agent implementation. - dsmonMatrixObjects group Report host address pair distribution statistics for each counter aggregation group, detected on a particular RMON dataSource. 3.2.1. DSCP Counter Aggregation Control Group This group contains 4 scalar objects and three tables, and is used by a management station to configure counter aggregation profiles. The dsmonMaxAggGroups scalar is a read-only integer which indicates the maximum number of counter aggregation groups that the agent will allow to be configured into a single aggregation profile. This value SHOULD be equal to 64 (the number of codepoints), but an agent MAY limit the number of counter aggregation groups because of resource limitations (e.g., small number of hardware-based counters). At least one counter aggregation profile containing at least two counter aggregation groups SHOULD be supported by the agent. (Note that classifying all DSCP counters into the same statistical 'bucket' may yield a redundant data collection, which can be achieved more easily with an HC-RMON or RMON-2 collection instead.) The dsmonAggControlLocked scalar is used as a top level switch, controlling most write access to the dsmonAggControlTable, dsmonAggProfileTable, and dsmonAggGroupTable. (The dsmonAggControlOwner object is the only exception.) All active DSMON collection data is deleted, and collection suspended, while this object is equal to 'false', since the meaning of one or more counter aggregation control tables may change when it is set back to 'true'. The dsmonAggControlChanges counter and dsmonAggControlLastChangeTime timestamp can be used by a management station to detect that the codepoint to counter aggregation group mappings may have changed between polls. Bierman Standards Track [Page 9] RFC 3287 DSMON MIB July 2002 The dsmonAggControlTable is a read-create table which contains one entry for each counter aggregation profile configured on the agent. Each entry is identified by a dsmonAggControlIndex value, which is also used as the major index into the dsmonAggProfileTable and dsmonAggGroupTable. The DSMON control tables with DataSource objects select a counter aggregation profile by referencing this index value. The dsmonAggProfileTable is a read-write table which contains 64 rows for each associated entry in the dsmonAggControlTable, which MUST be indexed from 0 to 63. The agent creates this set of 64 instances when the associated dsmonAggControlEntry is activated, and deletes them when that dsmonAggControlEntry is deactivated. Each of the 64 rows represents a conceptual DSCP counter, identified by the same dsmonAggProfileDSCP value, and contains the DSCP counter to counter aggregation group mapping for that DSCP counter, in the indicated profile. The agent SHOULD use the value zero as the initial counter aggregation group assignment for each entry in this table. The dsmonAggGroupTable contains an administratively assigned descriptive label for each configured counter aggregation group. This table is not required to be fully configured in order for data collection to occur, since collections are identified by the agent with integer indices. It is provided to allow the agent to store a descriptive string for each configured counter aggregation group. There is no attempt made to convey any real semantics for each counter aggregation group. A management station MAY choose not to configure entries in this table. 3.2.2. DS Statistics Group This group contains two tables, the dsmonStatsControlTable and the dsmonStatsTable, and supports counter aggregation group distribution statistics for half and full-duplex, low and high speed interfaces. Packet and octets distributions are maintained in the dsmonStatsTable for each active control row in the dsmonStatsControlTable. This group provides the lowest statistics granularity in the DSMON MIB. It is expected that a management application will analyze certain DS deployment or performance problems by first examining the counter aggregation group distribution for an entire data source with this group. 3.2.3. DS Protocol Distribution Group This group contains two tables for statistics collection, (dsmonPdistCtlTable and dsmonPdistStatsTable), and two tables for a 'Top N' reporting function for the collected statistics (dsmonPdistTopNCtlTable and dsmonPdistTopNTable). Bierman Standards Track [Page 10] RFC 3287 DSMON MIB July 2002 The dsmonPdistCtlTable and dsmonPdistStatsTable tables provide counter aggregation group distribution statistics for each selected protocol encapsulation in packets monitored on a particular dataSource. Packet and octets distributions (per counter aggregation group per protocol) are maintained in the dsmonPdistStatsTable for each active control row in the dsmonPdistCtlTable. Due to the potentially large number of entries, the DS Protocol Distribution is different from the RMON-2 protocol distribution group in several ways: - maximum desired entries parameter added to the control table - inserts and deletes counters added to the control table - support for LRU garbage collection in the dsmonPdistStatsTable - TimeFilter index added to the dsmonPdistStatsTable - the selection of protocols is not configurable. Rather than select individual protocols to monitor, (e.g., via a 'supportedOn/Off' extension to the protocolDirTable [RFC 2021]), a simplified configuration mechanism is provided. Since DSCP usage statistics are most interesting at the application layer, the dsmonPdistStatsTable is 'hardwired' to select only application layer (i.e., 'terminal') protocols for statistical analysis. The TopN feature requires two additional tables: the dsmonPdistTopNCtlTable and the dsmonPdistTopNTable, and supports periodic usage reporting for the statistics maintained in the dsmonPdistStatsTable. This feature allows for simple periodic retrieval of the most used application/counter aggregation group combinations. 3.2.4. DS Host Distribution Group This group contains two tables for statistics collection, (dsmonHostCtlTable and dsmonHostTable), and two tables for a 'Top N' reporting function for the collected statistics (dsmonHostTopNCtlTable and dsmonHostTopNTable). The dsmonHostCtlTable and dsmonHostTables provide host distribution statistics for each counter aggregation group detected in packets monitored on a particular dataSource. The DSMON Host collection is similar to the RMON-2 network layer host collection (nlHostTable). There is no DSMON application host table defined at this time. Bierman Standards Track [Page 11] RFC 3287 DSMON MIB July 2002 It is expected that a management application will analyze certain DS deployment or performance problems by first determining the high priority DSCP values to examine (beyond the scope of this document) and then examining the dsmonHostTable or dsmonHostTopNTable statistics to determine which hosts are using the selected counter aggregation groups. Packet and octets distributions (in and out, per counter aggregation group per host) are maintained in the dsmonHostTable for each active control row in the dsmonHostCtlTable. The DS Host Distribution is different from the RMON-2 network layer host group in two ways: - the protocolDirLocalIndex in the INDEX clause MUST identify a network protocol encapsulation which contains a DS field (e.g., IPv4 or IPv6). If a protocol encapsulation with multiple network layers is specified, then associated entries in this table refer to the innermost network protocol layer. - the dsmonHostCtlTable supports limited IPv4 and IPv6 prefix aggregation by allowing the number of 'monitored address bits' in each address to be configured for each collection. The agent will zero out the selected number of rightmost address bits for counting purposes. This configuration parameter can dramatically reduce the number of entries which must be maintained by the agent, which should reduce CPU and memory resource requirements on the agent, and reduce polling overhead on the network and the management station. However, only one mask can be configured for each address type, rather than multiple different length masks for each address type, based on prefix value. The TopN feature requires two additional tables: the dsmonHostTopNCtlTable and the dsmonHostTopNTable, and supports periodic usage reporting for the statistics maintained in the dsmonHostTable. This feature allows for simple periodic retrieval of the most used IP-host/DSCP combinations. 3.2.5. DSMON Capabilities Group This group contains a single read-only scalar object, dsmonCapabilities, which provides an indication of the MIB groups within this MIB that the agent supports. Bierman Standards Track [Page 12] RFC 3287 DSMON MIB July 2002 3.2.6. DS Matrix Distribution Group This group contains three tables for statistics collection, (dsmonMatrixCtlTable, dsmonMatrixSDTable, and dsmonMatrixDSTable), and two tables for a 'Top N' reporting function for the collected statistics (dsmonMatrixTopNCtlTable and dsmonMatrixTopNTable). The dsmonMatrixCtlTable, dsmonMatrixSDTable, and dsmonMatrixDSTable provide host-pair distribution statistics for each counter aggregation group detected in packets monitored on a particular dataSource. The DSMON Matrix collection is similar to the RMON-2 application layer matrix collection (alMatrixSDTable and alMatrixDSTable). There is no DSMON network layer matrix table defined at this time. It is expected that a management application will analyze certain DS deployment or performance problems by first determining the high priority DSCP values to examine (beyond the scope of this document) and then examining the dsmonMatrixSDTable, dsmonMatrixDSTable, and/or dsmonMatrixTopNTable statistics to determine which host-pairs are using the selected counter aggregation groups. Packet and octets distributions (source to destination, per counter aggregation group per host-pair) are maintained in the dsmonMatrixSDTable and dsmonMatrixDSTable for each active control row in the dsmonMatrixCtlTable. The TopN feature requires two additional tables: the dsmonMatrixTopNCtlTable and the dsmonMatrixTopNTable, and supports periodic usage reporting for the statistics maintained in the dsmonMatrixSDTable. This feature allows for simple periodic retrieval of the most used IP-host-pair/DSCP combinations. 3.3. RMON vs. DSMON Indexing Structure The DSMON-MIB control and data tables are very similar in structure and look-and-feel to existing RMON-2 and HC-RMON control tables for the comparable feature, in order to maintain consistent agent behavior and functionality across RMON MIBs. The DSMON data tables are indexed as closely as possible to the comparable RMON-2 or HC- RMON tables, with the addition of an index component for DSCP-based classification (i.e. dsmonAggGroup). Refer to Table 1 for a comparison of DSMON indexing structure with similar existing RMON features. Bierman Standards Track [Page 13] RFC 3287 DSMON MIB July 2002 Table 1: DSMON Indexing Comparison Existing RMON DSMON -------------------------------------------------------------------- Full Duplex Interface Statistics mediaIndependentEntry | dsmonStatsControlEntry mediaIndependentIndex | dsmonStatsControlIndex | dsmonStatsEntry | dsmonStatsControlIndex, | dsmonAggGroupIndex ---------------------------------+------------------------------ Protocol Statistics protocolDistControlEntry | dsmonPdistCtlEntry protocolDistControlIndex | dsmonPdistCtlIndex protocolDistStatsEntry | dsmonPdistStatsEntry protocolDistControlIndex, | dsmonPdistCtlIndex, protocolDirLocalIndex | dsmonPdistTimeMark, | dsmonAggGroupIndex, | protocolDirLocalIndex ---------------------------------+-------------------------------- Protocol TopN Distribution | dsmonPdistTopNCtlEntry | dsmonPdistTopNCtlIndex none | dsmonPdistTopNEntry | dsmonPdistTopNCtlIndex, | dsmonPdistTopNIndex ---------------------------------+-------------------------------- Network Host Statistics hlHostControlEntry | dsmonHostCtlEntry hlHostControlIndex | dsmonHostCtlIndex nlHostEntry | dsmonHostEntry hlHostControlIndex, | dsmonHostCtlIndex, nlHostTimeMark, | dsmonHostTimeMark, protocolDirLocalIndex, | dsmonAggGroupIndex, nlHostAddress | protocolDirLocalIndex, | dsmonHostAddress ---------------------------------+-------------------------------- Bierman Standards Track [Page 14] RFC 3287 DSMON MIB July 2002 Table 1 (Continued): DSMON Indexing Comparison Existing RMON DSMON ---------------------------------+-------------------------------- Network Host TopN Distribution | dsmonHostTopNCtlEntry | dsmonHostTopNCtlIndex none | dsmonHostTopNEntry | dsmonHostTopNCtlIndex, | dsmonHostTopNIndex ---------------------------------+-------------------------------- Application Matrix Statistics hlMatrixControlEntry | dsmonMatrixCtlEntry hlMatrixControlIndex | dsmonMatrixCtlIndex alMatrixSDEntry | dsmonMatrixSDEntry hlMatrixControlIndex, | dsmonMatrixCtlIndex, alMatrixSDTimeMark, | dsmonMatrixTimeMark, protocolDirLocalIndex, | dsmonAggGroupIndex, nlMatrixSDSourceAddress, | dsmonMatrixNLIndex, nlMatrixSDDestAddress | dsmonMatrixSourceAddress protocolDirLocalIndex | dsmonMatrixDestAddress | dsmonMatrixALIndex alMatrixDSEntry | dsmonMatrixDSEntry hlMatrixControlIndex, | dsmonMatrixCtlIndex, alMatrixDSTimeMark, | dsmonMatrixTimeMark, protocolDirLocalIndex, | dsmonAggGroupIndex, nlMatrixDSDestAddress, | dsmonMatrixNLIndex, nlMatrixDSSourceAddress | dsmonMatrixDestAddress protocolDirLocalIndex | dsmonMatrixSourceAddress | dsmonMatrixALIndex ---------------------------------+-------------------------------- Application Matrix TopN Distribution | dsmonMatrixTopNCtlEntry none | dsmonMatrixTopNCtlIndex | dsmonMatrixTopNEntry (similar to nlMatrixTopN) | dsmonMatrixTopNCtlIndex, | dsmonMatrixTopNIndex ---------------------------------+-------------------------------- Bierman Standards Track [Page 15] RFC 3287 DSMON MIB July 2002 4. Definitions DSMON-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Gauge32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF RowStatus, TimeStamp, TEXTUAL-CONVENTION, TruthValue FROM SNMPv2-TC OwnerString, rmon FROM RMON-MIB protocolDirLocalIndex, LastCreateTime, DataSource, ZeroBasedCounter32, TimeFilter FROM RMON2-MIB CounterBasedGauge64, ZeroBasedCounter64 FROM HCNUM-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB Dscp FROM DIFFSERV-DSCP-TC; dsmonMIB MODULE-IDENTITY LAST-UPDATED "200205310000Z" ORGANIZATION "IETF RMONMIB Working Group" CONTACT-INFO " Andy Bierman Cisco Systems, Inc. RMONMIB WG Chair and DSMON MIB Editor Postal: 170 West Tasman Drive San Jose, CA USA 95134 Tel: +1 408 527-3711 E-mail: abierman@cisco.com Send comments to Mailing list subscription info: http://www.ietf.org/mailman/listinfo/rmonmib " DESCRIPTION "This module defines Remote Monitoring MIB extensions for Differentiated Services enabled networks. RMON DIFFSERV DSCP statistics * Per Counter Aggregation Group * Per Protocol Per Counter Aggregation Group * Per Counter Aggregation Group Per Host Bierman Standards Track [Page 16] RFC 3287 DSMON MIB July 2002 * Per Counter Aggregation Group Per Host-Pair In order to maintain the RMON 'look-and-feel' and semantic consistency, some of the text from the RMON-2 and HC-RMON MIBs by Steve Waldbusser has been adapted for use in this MIB." REVISION "200205310000Z" DESCRIPTION "Initial version of the DSMON MIB module. This version published as RFC 3287." ::= { rmon 26 } dsmonObjects OBJECT IDENTIFIER ::= { dsmonMIB 1 } dsmonNotifications OBJECT IDENTIFIER ::= { dsmonMIB 2 } dsmonConformance OBJECT IDENTIFIER ::= { dsmonMIB 3 } dsmonAggObjects OBJECT IDENTIFIER ::= { dsmonObjects 1 } dsmonStatsObjects OBJECT IDENTIFIER ::= { dsmonObjects 2 } dsmonPdistObjects OBJECT IDENTIFIER ::= { dsmonObjects 3 } dsmonHostObjects OBJECT IDENTIFIER ::= { dsmonObjects 4 } dsmonCapsObjects OBJECT IDENTIFIER ::= { dsmonObjects 5 } dsmonMatrixObjects OBJECT IDENTIFIER ::= { dsmonObjects 6 } -- -- Textual Convention to define a -- DSMON Counter Aggregation Group Index -- DsmonCounterAggGroupIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes a data type which identifies a DSMON counter aggregation group, which is an arbitrary grouping of conceptual counters, for monitoring purposes only. The range for this data type begins with zero (instead of one), to allow for a direct mapping between counter indexing schemes that start at zero (e.g. DSCP values in packets) and counter aggregation group values." SYNTAX Integer32 (0..2147483647) -- -- Textual Convention to define a -- DSMON Counter Aggregation Profile Index -- DsmonCounterAggProfileIndex ::= TEXTUAL-CONVENTION STATUS current Bierman Standards Track [Page 17] RFC 3287 DSMON MIB July 2002 DESCRIPTION "This TC describes a data type which identifies a DSMON counter aggregation profile, which is a set of counter aggregation group assignments for each of the 64 DSCP values, for a particular statistical collection." SYNTAX Integer32 (1..2147483647) -- *********************************************************** -- * * -- * D S M O N C A P A B I L I T I E S * -- * * -- *********************************************************** dsmonCapabilities OBJECT-TYPE SYNTAX BITS { dsmonCounterAggControl(0), dsmonStats(1), dsmonStatsOvfl(2), dsmonStatsHC(3), dsmonPdist(4), dsmonPdistOvfl(5), dsmonPdistHC(6), dsmonHost(7), dsmonHostOvfl(8), dsmonHostHC(9), dsmonCaps(10), dsmonMatrix(11), dsmonMatrixOvfl(12), dsmonMatrixHC(13) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides an indication of the DSMON groups supported by the agent. If a bit is set, then the agent implements all of the objects in the DSMON object group, where bit 'n' represents the MIB group identified by the OBJECT IDENTIFIER value { dsmonGroups n+1 }." ::= { dsmonCapsObjects 1 } -- *********************************************************** -- * * -- * A G G R E G A T I O N C O N T R O L G R O U P S * -- * * -- *********************************************************** Bierman Standards Track [Page 18] RFC 3287 DSMON MIB July 2002 dsmonMaxAggGroups OBJECT-TYPE SYNTAX Integer32 (2..64) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of counter aggregation groups that this agent can support. The agent will allow this number of distinct groups to be configured in the dsmonAggProfileTable, numbered from '0' to 'dsmonMaxAggGroups - 1', for each counter aggregation profile entry supported by the agent. The agent MUST NOT lower this value during system operation, and SHOULD set this object to an appropriate value during system initialization." ::= { dsmonAggObjects 1 } dsmonAggControlLocked OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the setup of counter aggregation groups for this agent. If this object contains the value 'true', then write access to the objects in the dsmonAggControlTable (except the dsmonAggControlOwner object), dsmonAggProfileTable, and dsmonAggGroupTable is not permitted, and data collection is possible. This object only controls write access to these MIB objects. The DSMON data collection control tables (e.g., dsmonHostCtlTable) can be configured at any time, regardless of the value of this object. If this object contains the value 'false', write access to the objects in the dsmonAggControlTable, dsmonAggProfileTable, and dsmonAggGroupTable is permitted, and data collection is not possible. In addition, all objects in all DSMON data tables (e.g., dsmonStatsTable) shall be deleted. An agent is not required to process SNMP Set Requests for this object in conjunction with other objects from this MIB. This is intended to simplify the processing of Set Requests for tables such as the dsmonAggProfileTable, by eliminating the possibility that a single Set PDU will contain multiple varbinds which are in conflict, such as a PDU which both modifies the dsmonAggProfileTable and locks the Bierman Standards Track [Page 19] RFC 3287 DSMON MIB July 2002 dsmonAggProfileTable at the same time. Note that the agent is not required to validate the entire counter aggregation configuration when an attempt is made to transition an instance of this object from 'true' to 'false'. That validation is done if and when a DSMON data collection is activated. An agent is required to reactivate any suspended data collections when this object transitions to 'true', Each active data control entry (e.g., dsmonStatsControlEntry), will be validated with respect to the new counter aggregation configuration. If the counter aggregation profile referenced in the data collection is valid, then that collection will be restarted. Otherwise, the RowStatus object (e.g., dsmonStatsControlStatus) will be set to 'notReady' for that collection control entry." ::= { dsmonAggObjects 2 } dsmonAggControlChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of times the value of the dsmonAggControlLocked object has changed. A management station can use this object to detect if counters in the DSMON data tables (e.g., dsmonStatsEntry) have been deleted and recreated between polls. This object shall be incremented by one each time the dsmonAggControlLocked object changes from 'false' to 'true', or from 'true' to 'false'." ::= { dsmonAggObjects 3 } dsmonAggControlLastChangeTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the value of sysUpTime at the moment the dsmonAggControlLocked object was last modified. A management station can use this object to detect if counters in the DSMON data tables (e.g., dsmonStatsEntry) have been deleted and recreated between polls. This object shall be updated with the current value of sysUpTime, if the dsmonAggControlLocked object changes from Bierman Standards Track [Page 20] RFC 3287 DSMON MIB July 2002 'false' to 'true', or from 'true' to 'false'. Upon system initialization, this object shall contain the value zero." ::= { dsmonAggObjects 4 } -- -- Counter Aggregation Control Table -- dsmonAggControlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonAggControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides an overall description and control point for all dsmonAggProfileEntries with the same dsmonAggControlIndex value. A management application SHOULD create a counter aggregation profile by first creating and activating an entry in this table. This will cause the agent to create a set of 64 dsmonAggProfileEntries on behalf of this control entry. An application can then set the individual counter aggregation group assignments for each of the 64 DSCP values, This table MUST NOT be modified if the dsmonAggControlLocked object is equal to 'true'. Note that an agent MAY choose to limit the actual number of entries which may be created in this table, and (independently) the number of counter aggregation profiles which may be applied to a particular data source. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Otherwise, each potential counter aggregation group description string SHOULD contain the empty string." ::= { dsmonAggObjects 5 } dsmonAggControlEntry OBJECT-TYPE SYNTAX DsmonAggControlEntry MAX-ACCESS not-accessible Bierman Standards Track [Page 21] RFC 3287 DSMON MIB July 2002 STATUS current DESCRIPTION "A conceptual row in the dsmonAggControlTable." INDEX { dsmonAggControlIndex } ::= { dsmonAggControlTable 1 } DsmonAggControlEntry ::= SEQUENCE { dsmonAggControlIndex DsmonCounterAggProfileIndex, dsmonAggControlDescr SnmpAdminString, dsmonAggControlOwner OwnerString, dsmonAggControlStatus RowStatus } dsmonAggControlIndex OBJECT-TYPE SYNTAX DsmonCounterAggProfileIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer index value used to identify the counter aggregation profile specified by this control entry." ::= { dsmonAggControlEntry 1 } dsmonAggControlDescr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively assigned description of the counter aggregation profile identified by this entry. Upon first creation of an instance of this object, the agent SHOULD set this object to the empty string. If the agent supports non-volatile storage, then this object SHOULD be re-initialized with its stored value after a system reboot. This object MUST NOT be modified if the associated dsmonAggControlStatus object is equal to 'active', or the dsmonAggControlLocked object is equal to 'true'." ::= { dsmonAggControlEntry 2 } dsmonAggControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." Bierman Standards Track [Page 22] RFC 3287 DSMON MIB July 2002 ::= { dsmonAggControlEntry 3 } dsmonAggControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. Upon setting this object to active(1), the agent will create a complete set of 64 associated entries in the dsmonAggProfileTable. If this object is not equal to active(1), all associated entries in the dsmonAggProfileTable shall be deleted. This object MUST NOT be modified if the dsmonAggControlLocked object is equal to 'true'." ::= { dsmonAggControlEntry 4 } -- -- Counter Aggregation Profile Table -- dsmonAggProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonAggProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of counter aggregation profiles for this agent. For each such profile, every DSCP value MUST be configured into exactly one counter aggregation group. This table MUST NOT be modified if the dsmonAggControlLocked object is equal to 'true'. The agent will create a set of 64 entries in this table (with the same dsmonAggControlIndex value) when the associated dsmonAggControlEntry is activated. If the agent supports non-volatile configuration of this table, then upon system initialization, this table SHOULD be initialized with the saved values." ::= { dsmonAggObjects 6 } Bierman Standards Track [Page 23] RFC 3287 DSMON MIB July 2002 dsmonAggProfileEntry OBJECT-TYPE SYNTAX DsmonAggProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonAggProfileTable. The dsmonAggControlIndex value in the index identifies the dsmonAggControlEntry associated with each entry in this table." INDEX { dsmonAggControlIndex, dsmonAggProfileDSCP } ::= { dsmonAggProfileTable 1 } DsmonAggProfileEntry ::= SEQUENCE { dsmonAggProfileDSCP Dscp, dsmonAggGroupIndex DsmonCounterAggGroupIndex } dsmonAggProfileDSCP OBJECT-TYPE SYNTAX Dscp MAX-ACCESS not-accessible STATUS current DESCRIPTION "The specific DSCP value for the DSCP counter which is configured in a counter aggregation group by this entry." ::= { dsmonAggProfileEntry 1 } dsmonAggGroupIndex OBJECT-TYPE SYNTAX DsmonCounterAggGroupIndex MAX-ACCESS read-write STATUS current DESCRIPTION "The counter aggregation group which contains this DSCP value. Upon creation of a new sub-tree (set of 64 entries with the same dsmonAggControlIndex value) in this table, the agent SHOULD initialize all related instances of this object to the value zero. This object MUST NOT be modified if the dsmonAggControlLocked object is equal to 'true'." DEFVAL { 0 } ::= { dsmonAggProfileEntry 2 } -- -- Counter Aggregation Group Table -- Bierman Standards Track [Page 24] RFC 3287 DSMON MIB July 2002 dsmonAggGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonAggGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a description of each counter aggregation group configured on this system. Note that the semantics of a particular counter aggregation group are only relevant within the scope of a particular counter aggregation profile. This table MUST NOT be modified if the dsmonAggControlLocked object is equal to 'true'. Note that an agent MAY choose to limit the actual number of entries which may be created in this table, and (independently) the number of counter aggregation profiles which may be applied to a particular data source. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]. If the agent supports non-volatile configuration of this table, then upon system initialization, this table SHOULD be initialized with the saved values. Otherwise, each potential counter aggregation group description string SHOULD contain the empty string. An agent SHOULD allow entries to be created or modified in this table, even if the specified dsmonAggControlIndex value does not identify a valid dsmonAggControlEntry or a complete set of valid dsmonAggProfileEntries, to reduce row creation order dependencies." ::= { dsmonAggObjects 7 } dsmonAggGroupEntry OBJECT-TYPE SYNTAX DsmonAggGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonAggGroupTable. The dsmonAggGroupIndex value in the INDEX identifies the counter aggregation group associated with each entry. The dsmonAggControlIndex in the index identifies the counter aggregation profile associated with each entry, identified by the dsmonAggControlEntry and dsmonAggProfileEntries with the same index value. Bierman Standards Track [Page 25] RFC 3287 DSMON MIB July 2002 The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. The dsmonAggGroupIndex in the index identifies the counter aggregation group associated with each entry. This object SHOULD be indexed from zero to 'N', where 'N' is less than the value of the dsmonMaxAggGroups for this agent." INDEX { dsmonAggControlIndex, dsmonAggGroupIndex } ::= { dsmonAggGroupTable 1 } DsmonAggGroupEntry ::= SEQUENCE { dsmonAggGroupDescr SnmpAdminString, dsmonAggGroupStatus RowStatus } dsmonAggGroupDescr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively assigned description of the counter aggregation group identified by this entry. Upon first creation of an instance of this object, the agent SHOULD set this object to the empty string. This object MUST NOT be modified if the associated dsmonAggGroupStatus object is equal to 'active', or the dsmonAggControlLocked object is equal to 'true'." ::= { dsmonAggGroupEntry 1 } dsmonAggGroupStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. This object MUST NOT be modified if the dsmonAggControlLocked object is equal to 'true'." ::= { dsmonAggGroupEntry 2 } Bierman Standards Track [Page 26] RFC 3287 DSMON MIB July 2002 -- ************************************************************* -- * * -- * P E R - D A T A S O U R C E C O L L E C T I O N S * -- * * -- ************************************************************* -- -- Per-DataSource Statistics Control Table -- dsmonStatsControlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonStatsControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of per data source per counter aggregation group distribution statistics. Note that an agent MAY choose to limit the actual number of entries which may be created in this table. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]." ::= { dsmonStatsObjects 1 } dsmonStatsControlEntry OBJECT-TYPE SYNTAX DsmonStatsControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonStatsControlTable. Entries are created and deleted from this table by management action only, using the dsmonStatsControlStatus RowStatus object. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Activation of a control row in this table will cause an associated dsmonStatsTable to be created and maintained by the agent." INDEX { dsmonStatsControlIndex } ::= { dsmonStatsControlTable 1 } DsmonStatsControlEntry ::= SEQUENCE { dsmonStatsControlIndex Integer32, Bierman Standards Track [Page 27] RFC 3287 DSMON MIB July 2002 dsmonStatsControlDataSource DataSource, dsmonStatsControlAggProfile DsmonCounterAggProfileIndex, dsmonStatsControlDroppedFrames Counter32, dsmonStatsControlCreateTime LastCreateTime, dsmonStatsControlOwner OwnerString, dsmonStatsControlStatus RowStatus } dsmonStatsControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary and unique index for this dsmonStatsControlEntry." ::= { dsmonStatsControlEntry 1 } dsmonStatsControlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The data source of this per protocol per counter aggregation group distribution. Note that only packets that contain a network protocol encapsulation which contains a DS field [RFC2474] will be counted in this table. This object MUST NOT be modified if the associated dsmonStatsControlStatus object is equal to active(1)." ::= { dsmonStatsControlEntry 2 } dsmonStatsControlAggProfile OBJECT-TYPE SYNTAX DsmonCounterAggProfileIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The dsmonAggControlIndex value identifying the counter aggregation profile which should be used on behalf of this dsmonStatsControlEntry. The associated dsmonAggControlEntry and dsmonAggProfileEntries, identified by the same dsmonAggControlIndex index value, MUST be active in order for this entry to remain active. It is possible for the counter aggregation configuration to change from a valid to invalid state for this dsmonStats collection. In this case, Bierman Standards Track [Page 28] RFC 3287 DSMON MIB July 2002 the associated dsmonStatsControlStatus object will be changed to the 'notReady' state, and data collection will not occur on behalf of this control entry. Note that an agent MAY choose to limit the actual number of counter aggregation profiles which may be applied to a particular data source. This object MUST NOT be modified if the associated dsmonStatsControlStatus object is equal to active(1)." ::= { dsmonStatsControlEntry 3 } dsmonStatsControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { dsmonStatsControlEntry 4 } dsmonStatsControlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to detect if the table has been deleted and recreated between polls." ::= { dsmonStatsControlEntry 5 } dsmonStatsControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION Bierman Standards Track [Page 29] RFC 3287 DSMON MIB July 2002 "The entity that configured this entry and is therefore using the resources assigned to it." ::= { dsmonStatsControlEntry 6 } dsmonStatsControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the dsmonStatsTable shall be deleted." ::= { dsmonStatsControlEntry 7 } -- -- Per-DataSource Statistics Table -- dsmonStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information on counter aggregation group usage for each monitored data source. The following table defines per counter aggregation group statistics for full and/or half-duplex links as well as high capacity links. For half-duplex links, or full-duplex-capable links operating in half-duplex mode, the dsmonStatsIn* objects shall be used and the dsmonStatsOut* objects will not increment. For full-duplex links, the dsmonStatsOut* objects will be present. Whenever possible, the probe SHOULD count packets moving away from the closest terminating equipment as output packets. Failing that, the probe SHOULD count packets moving away from the DTE as output packets. If the dsmonAggControlLocked object is equal to 'false', then all entries in this table will be deleted and the agent will not process packets on behalf of any Bierman Standards Track [Page 30] RFC 3287 DSMON MIB July 2002 dsmonStatsControlEntry." ::= { dsmonStatsObjects 2 } dsmonStatsEntry OBJECT-TYPE SYNTAX DsmonStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information on Differentiated Services DSCP usage, containing inbound and outbound packet and octet counters for each counter aggregation group configured for collection. The dsmonStatsControlIndex value in the index identifies the dsmonStatsControlEntry on whose behalf this entry was created. The dsmonAggGroupIndex value in the index is determined by examining the DSCP value in each monitored packet, and the dsmonAggProfileTable entry for that DSCP value. Note that only packets that contain a network protocol encapsulation which contains a DS field [RFC2474] will be counted in this table. An example of the indexing of this entry is dsmonStatsOutPkts.1.16" INDEX { dsmonStatsControlIndex, dsmonAggGroupIndex } ::= { dsmonStatsTable 1 } DsmonStatsEntry ::= SEQUENCE { dsmonStatsInPkts ZeroBasedCounter32, dsmonStatsInOctets ZeroBasedCounter32, dsmonStatsInOvflPkts ZeroBasedCounter32, dsmonStatsInOvflOctets ZeroBasedCounter32, dsmonStatsInHCPkts ZeroBasedCounter64, dsmonStatsInHCOctets ZeroBasedCounter64, dsmonStatsOutPkts ZeroBasedCounter32, dsmonStatsOutOctets ZeroBasedCounter32, dsmonStatsOutOvflPkts ZeroBasedCounter32, dsmonStatsOutOvflOctets ZeroBasedCounter32, dsmonStatsOutHCPkts ZeroBasedCounter64, dsmonStatsOutHCOctets ZeroBasedCounter64 } dsmonStatsInPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "packets" Bierman Standards Track [Page 31] RFC 3287 DSMON MIB July 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets using one of the DSCP values in the indicated counter aggregation group, received on a half- duplex link or on the inbound connection of a full-duplex link." ::= { dsmonStatsEntry 1 } dsmonStatsInOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets, using one of the DSCP values in the indicated counter aggregation group, received on a half-duplex link or on the inbound connection of a full-duplex link." ::= { dsmonStatsEntry 2 } dsmonStatsInOvflPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonStatsInPkts counter has overflowed. Note that this object will only be instantiated if the associated dsmonStatsInHCPkts object is also instantiated for a particular dataSource." ::= { dsmonStatsEntry 3 } dsmonStatsInOvflOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonStatsInOctets counter has overflowed. Note that this object will only be instantiated if the associated dsmonStatsInHCOctets object is also instantiated for a particular dataSource." ::= { dsmonStatsEntry 4 } dsmonStatsInHCPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "packets" MAX-ACCESS read-only STATUS current Bierman Standards Track [Page 32] RFC 3287 DSMON MIB July 2002 DESCRIPTION "The 64-bit version of the dsmonStatsInPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonStatsEntry 5 } dsmonStatsInHCOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonStatsInOctets object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonStatsEntry 6 } dsmonStatsOutPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets using one of the DSCP values in the indicated counter aggregation group, received on a full- duplex link in the direction of the network." ::= { dsmonStatsEntry 7 } dsmonStatsOutOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets, using one of the DSCP values in the indicated counter aggregation group, received on a full-duplex link in the direction of the network." ::= { dsmonStatsEntry 8 } dsmonStatsOutOvflPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION Bierman Standards Track [Page 33] RFC 3287 DSMON MIB July 2002 "The number of times the associated dsmonStatsOutPkts counter has overflowed. Note that this object will only be instantiated if the associated dsmonStatsOutHCPkts object is also instantiated for a particular dataSource." ::= { dsmonStatsEntry 9 } dsmonStatsOutOvflOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonStatsOutOctets counter has overflowed. Note that this object will only be instantiated if the associated dsmonStatsOutHCOctets object is also instantiated for a particular dataSource." ::= { dsmonStatsEntry 10 } dsmonStatsOutHCPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonStatsOutPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonStatsEntry 11 } dsmonStatsOutHCOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonStatsOutOctets object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonStatsEntry 12 } -- *********************************************************** -- * * -- * P E R - P R O T O C O L C O L L E C T I O N S * -- * * -- *********************************************************** Bierman Standards Track [Page 34] RFC 3287 DSMON MIB July 2002 -- -- DSCP Per-Protocol Statistics Control Table -- dsmonPdistCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonPdistCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of per application per counter aggregation group distribution statistics. Note that an agent MAY choose to limit the actual number of entries which may be created in this table. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]." ::= { dsmonPdistObjects 1 } dsmonPdistCtlEntry OBJECT-TYPE SYNTAX DsmonPdistCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonPdistCtlTable. Entries are created and deleted from this table by management action only, using the dsmonPdistCtlStatus RowStatus object. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Activation of a control row in this table will cause an associated dsmonPdistStatsTable to be created and maintained by the agent." INDEX { dsmonPdistCtlIndex } ::= { dsmonPdistCtlTable 1 } DsmonPdistCtlEntry ::= SEQUENCE { dsmonPdistCtlIndex Integer32, dsmonPdistCtlDataSource DataSource, dsmonPdistCtlAggProfile DsmonCounterAggProfileIndex, dsmonPdistCtlMaxDesiredEntries Integer32, dsmonPdistCtlDroppedFrames Counter32, dsmonPdistCtlInserts Counter32, dsmonPdistCtlDeletes Counter32, Bierman Standards Track [Page 35] RFC 3287 DSMON MIB July 2002 dsmonPdistCtlCreateTime LastCreateTime, dsmonPdistCtlOwner OwnerString, dsmonPdistCtlStatus RowStatus } dsmonPdistCtlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary and unique index for this dsmonPdistCtlEntry." ::= { dsmonPdistCtlEntry 1 } dsmonPdistCtlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of data for the this per protocol counter aggregation group distribution. This object MUST NOT be modified if the associated dsmonPdistCtlStatus object is equal to active(1)." ::= { dsmonPdistCtlEntry 2 } dsmonPdistCtlAggProfile OBJECT-TYPE SYNTAX DsmonCounterAggProfileIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The dsmonAggControlIndex value identifying the counter aggregation profile which should be used on behalf of this dsmonPdistCtlEntry. The associated dsmonAggControlEntry and dsmonAggProfileEntries, identified by the same dsmonAggControlIndex index value, MUST be active in order for this entry to remain active. It is possible for the counter aggregation configuration to change from a valid to invalid state for this dsmonPdist collection. In this case, the associated dsmonPdistCtlStatus object will be changed to the 'notReady' state, and data collection will not occur on behalf of this control entry. Note that an agent MAY choose to limit the actual number of counter aggregation profiles which may be applied to a particular data source. Bierman Standards Track [Page 36] RFC 3287 DSMON MIB July 2002 This object MUST NOT be modified if the associated dsmonPdistCtlStatus object is equal to active(1)." ::= { dsmonPdistCtlEntry 3 } dsmonPdistCtlMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1 | 1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of entries that are desired in the dsmonPdistStatsTable on behalf of this control entry. The probe will not create more than this number of associated entries in the table, but MAY choose to create fewer entries in this table for any reason including the lack of resources. If this value is set to -1, the probe MAY create any number of entries in this table. This object MUST NOT be modified if the associated dsmonPdistCtlStatus object is equal to active(1)." ::= { dsmonPdistCtlEntry 4 } dsmonPdistCtlDroppedFrames OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { dsmonPdistCtlEntry 5 } dsmonPdistCtlInserts OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current Bierman Standards Track [Page 37] RFC 3287 DSMON MIB July 2002 DESCRIPTION "The number of times a dsmonPdist entry has been inserted into the dsmonPdistTable. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents MAY delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting dsmonPdistCtlDeletes from dsmonPdistCtlInserts." ::= { dsmonPdistCtlEntry 6 } dsmonPdistCtlDeletes OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a dsmonPdist entry has been deleted from the dsmonPdist table (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents MAY delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting dsmonPdistCtlDeletes from dsmonPdistCtlInserts." ::= { dsmonPdistCtlEntry 7 } dsmonPdistCtlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to detect if the table has been deleted and recreated between polls." Bierman Standards Track [Page 38] RFC 3287 DSMON MIB July 2002 ::= { dsmonPdistCtlEntry 8 } dsmonPdistCtlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { dsmonPdistCtlEntry 9 } dsmonPdistCtlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the dsmonPdistStatsTable shall be deleted." ::= { dsmonPdistCtlEntry 10 } -- -- Per-Protocol Statistics Table -- dsmonPdistStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonPdistStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information on a per protocol per counter aggregation group usage. If the dsmonAggControlLocked object is equal to 'false', then all entries in this table will be deleted and the agent will not process packets on behalf of any dsmonPdistCtlEntry." ::= { dsmonPdistObjects 2 } dsmonPdistStatsEntry OBJECT-TYPE SYNTAX DsmonPdistStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Bierman Standards Track [Page 39] RFC 3287 DSMON MIB July 2002 "A list of information on Differentiated Services DSCP usage, containing packet and octet counters for each counter aggregation group configured for collection, and each protocol (as identified by the protocolDirLocalIndex for the protocol) identified in each monitored packet. The dsmonPdistCtlIndex value in the index identifies the dsmonPdistCtlEntry on whose behalf this entry was created. Note that only packets that contain a network protocol encapsulation which contains a DS field [RFC2474] will be counted in this table. The dsmonAggGroupIndex value in the index is determined by examining the DSCP value in each monitored packet, and the dsmonAggProfileTable entry for that value. The protocolDirLocalIndex in the index identifies the protocolDirEntry for the protocol encapsulation of each monitored packet. The agent will include only application layer protocols in the associated dsmonPdistStatsTable. Any 'terminal' protocol is considered to be an application protocol. An example of the indexing of this entry is dsmonPdistStatsPkts.9.29943.0.42." INDEX { dsmonPdistCtlIndex, dsmonPdistTimeMark, dsmonAggGroupIndex, protocolDirLocalIndex } ::= { dsmonPdistStatsTable 1 } DsmonPdistStatsEntry ::= SEQUENCE { dsmonPdistTimeMark TimeFilter, dsmonPdistStatsPkts ZeroBasedCounter32, dsmonPdistStatsOctets ZeroBasedCounter32, dsmonPdistStatsOvflPkts ZeroBasedCounter32, dsmonPdistStatsOvflOctets ZeroBasedCounter32, dsmonPdistStatsHCPkts ZeroBasedCounter64, dsmonPdistStatsHCOctets ZeroBasedCounter64, dsmonPdistStatsCreateTime LastCreateTime } dsmonPdistTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION Bierman Standards Track [Page 40] RFC 3287 DSMON MIB July 2002 "The Time Filter index for this table. This object may be used by a management station to retrieve only rows which have been created or modified since a particular time. Note that the current value for a row are always returned and the TimeFilter is not a historical data archiving mechanism. Refer to RFC 2021 [RFC2021] for a detailed description of TimeFilter operation." ::= { dsmonPdistStatsEntry 1 } dsmonPdistStatsPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, using one of the DSCP values in the indicated counter aggregation group, for the protocol identified by the associated protocolDirLocalIndex value." ::= { dsmonPdistStatsEntry 2 } dsmonPdistStatsOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets, using one of the DSCP values in the indicated counter aggregation group, for the protocol identified by the associated protocolDirLocalIndex value. Note that this object doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { dsmonPdistStatsEntry 3 } dsmonPdistStatsOvflPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonPdistStatsPkts counter has overflowed. Note that this object will only be instantiated if the associated dsmonPdistStatsHCPkts object is also instantiated for a particular dataSource." ::= { dsmonPdistStatsEntry 4 } dsmonPdistStatsOvflOctets OBJECT-TYPE Bierman Standards Track [Page 41] RFC 3287 DSMON MIB July 2002 SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonPdistStatsOctets counter has overflowed. Note that this object will only be instantiated if the associated dsmonPdistStatsHCOctets object is also instantiated for a particular dataSource." ::= { dsmonPdistStatsEntry 5 } dsmonPdistStatsHCPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonPdistStatsPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonPdistStatsEntry 6 } dsmonPdistStatsHCOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonPdistStatsOctets object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonPdistStatsEntry 7 } dsmonPdistStatsCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this dsmonPdistStats entry was last instantiated by the agent. This can be used by the management station to detect if the entry has been deleted and recreated between polls." ::= { dsmonPdistStatsEntry 8 } Bierman Standards Track [Page 42] RFC 3287 DSMON MIB July 2002 -- -- Per-Protocol Statistics TopN Control Table -- dsmonPdistTopNCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonPdistTopNCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N dsmonPdist entries according to a particular metric. Note that an agent MAY choose to limit the actual number of entries which may be created in this table. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]." ::= { dsmonPdistObjects 3 } dsmonPdistTopNCtlEntry OBJECT-TYPE SYNTAX DsmonPdistTopNCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonPdistTopNCtlTable. Entries are created and deleted from this table by management action only, using the dsmonPdistTopNCtlStatus RowStatus object. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Activation of a control row in this table will cause an associated dsmonPdistTopNTable to be created and maintained by the agent." INDEX { dsmonPdistTopNCtlIndex } ::= { dsmonPdistTopNCtlTable 1 } DsmonPdistTopNCtlEntry ::= SEQUENCE { dsmonPdistTopNCtlIndex Integer32, dsmonPdistTopNCtlPdistIndex Integer32, dsmonPdistTopNCtlRateBase INTEGER, dsmonPdistTopNCtlTimeRemaining Integer32, dsmonPdistTopNCtlGeneratedReprts Counter32, dsmonPdistTopNCtlDuration Integer32, Bierman Standards Track [Page 43] RFC 3287 DSMON MIB July 2002 dsmonPdistTopNCtlRequestedSize Integer32, dsmonPdistTopNCtlGrantedSize Integer32, dsmonPdistTopNCtlStartTime TimeStamp, dsmonPdistTopNCtlOwner OwnerString, dsmonPdistTopNCtlStatus RowStatus } dsmonPdistTopNCtlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the dsmonPdistTopNCtlTable, with the same dsmonPdistTopNCtlIndex value as this object. Each entry in this table defines one Top N report prepared on behalf of the dsmonPdistStatsEntry collection with the same dsmonPdistCtlIndex as this object." ::= { dsmonPdistTopNCtlEntry 1 } dsmonPdistTopNCtlPdistIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The dsmonPdistTable for which a top N report will be prepared on behalf of this entry. The dsmonPdistTable is identified by the value of the dsmonPdistCtlIndex for that table - that value is used here to identify the particular table. This object MUST NOT be modified if the associated dsmonPdistTopNCtlStatus object is equal to active(1)." ::= { dsmonPdistTopNCtlEntry 2 } dsmonPdistTopNCtlRateBase OBJECT-TYPE SYNTAX INTEGER { dsmonPdistTopNPkts(1), dsmonPdistTopNOctets(2), dsmonPdistTopNHCPkts(3), dsmonPdistTopNHCOctets(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable for each dsmonPdist that the dsmonPdistTopNRate and dsmonPdistTopNHCRate variables are based upon. Each dsmonPdistTopN report generated on behalf of this control entry will be ranked in descending order, Bierman Standards Track [Page 44] RFC 3287 DSMON MIB July 2002 based on the associated dsmonPdistStatsTable counter, identified by this object. The following table identifies the dsmonPdistTable counter associated with each enumeration: Enumeration RateBase MIB Object ----------- ------------------- dsmonPdistTopNPkts dsmonPdistStatsPkts dsmonPdistTopNOctets dsmonPdistStatsOctets dsmonPdistTopNHCPkts dsmonPdistStatsHCPkts dsmonPdistTopNHCOctets dsmonPdistStatsHCOctets Note that the dsmonPdistTopNHCPkts and dsmonPdistTopNHCOctets enumerations are only available if the agent supports High Capacity monitoring. This object MUST NOT be modified if the associated dsmonPdistTopNCtlStatus object is equal to active(1)." ::= { dsmonPdistTopNCtlEntry 3 } dsmonPdistTopNCtlTimeRemaining OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report, and is immediately loaded into the associated dsmonPdistTopNCtlDuration object. When the report finishes, the probe will automatically start another collection with the same initial value of dsmonPdistTopNCtlTimeRemaining. Thus the management station may simply read the resulting reports repeatedly, checking the startTime and duration each time to ensure that a report was not missed or that the report parameters were not changed. While the value of this object is non-zero, it decrements by one per second until it reaches zero. At the time that this object decrements to zero, the report is made accessible in the dsmonPdistTopNTable, overwriting any report that may be there. Bierman Standards Track [Page 45] RFC 3287 DSMON MIB July 2002 When this object is modified by the management station, any associated entries in the dsmonPdistTopNTable shall be deleted." DEFVAL { 1800 } ::= { dsmonPdistTopNCtlEntry 4 } dsmonPdistTopNCtlGeneratedReprts OBJECT-TYPE SYNTAX Counter32 UNITS "reports" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reports that have been generated by this entry." ::= { dsmonPdistTopNCtlEntry 5 } dsmonPdistTopNCtlDuration OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval. When the associated dsmonPdistTopNCtlTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the dsmonPdistTopNCtlTimeRemaining is set. This value shall be zero if no reports have been requested for this dsmonPdistTopNCtlEntry." ::= { dsmonPdistTopNCtlEntry 6 } dsmonPdistTopNCtlRequestedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "table entries" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of dsmonPdist entries requested for this report. When this object is created or modified, the probe SHOULD set dsmonPdistTopNCtlGrantedSize as closely to this object as is possible for the particular probe implementation and available resources." DEFVAL { 150 } Bierman Standards Track [Page 46] RFC 3287 DSMON MIB July 2002 ::= { dsmonPdistTopNCtlEntry 7 } dsmonPdistTopNCtlGrantedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of dsmonPdist entries in this report. When the associated dsmonPdistTopNCtlRequestedSize object is created or modified, the probe SHOULD set this object as closely to the requested value as is possible for the particular implementation and available resources. The probe MUST NOT lower this value except as a result of a set to the associated dsmonPdistTopNCtlRequestedSize object. Protocol entries with the highest value of dsmonPdistTopNRate or dsmonPdistTopNHCRate (depending on the value of the associated dsmonPdistTopNCtlRateBase object) shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more dsmonPdist entries." ::= { dsmonPdistTopNCtlEntry 8 } dsmonPdistTopNCtlStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this top N report was last started. In other words, this is the time that the associated dsmonPdistTopNCtlTimeRemaining object was modified to start the requested report or the time the report was last automatically (re)started. This object may be used by the management station to determine if a report was missed or not." ::= { dsmonPdistTopNCtlEntry 9 } dsmonPdistTopNCtlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." Bierman Standards Track [Page 47] RFC 3287 DSMON MIB July 2002 ::= { dsmonPdistTopNCtlEntry 10 } dsmonPdistTopNCtlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this dsmonPdistTopNCtlEntry. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the dsmonPdistTopNTable shall be deleted by the agent." ::= { dsmonPdistTopNCtlEntry 11 } -- -- dsmonPdist TopN Table -- dsmonPdistTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonPdistTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for those protocol distribution entries that have counted the highest number of octets or packets. If the dsmonAggControlLocked object is equal to 'false', then all entries in this table SHALL be deleted, and the agent will not process TopN reports on behalf of any dsmonPdistTopNCtlEntry. When the dsmonAggControlLocked object is set to 'true', then particular reports SHOULD be restarted from the beginning, on behalf of all active rows in the dsmonPdistTopNCtlTable. Note that dsmonPdist entries which did not increment at all during the report interval SHOULD NOT be included in dsmonPdistTopN reports." ::= { dsmonPdistObjects 4 } dsmonPdistTopNEntry OBJECT-TYPE SYNTAX DsmonPdistTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Bierman Standards Track [Page 48] RFC 3287 DSMON MIB July 2002 "A conceptual row in the dsmonPdistTopNTable. The dsmonPdistTopNCtlIndex value in the index identifies the dsmonPdistTopNCtlEntry on whose behalf this entry was created. Entries in this table are ordered from 1 to 'N', where lower numbers represent higher values of the rate base object, over the report interval." INDEX { dsmonPdistTopNCtlIndex, dsmonPdistTopNIndex } ::= { dsmonPdistTopNTable 1 } DsmonPdistTopNEntry ::= SEQUENCE { dsmonPdistTopNIndex Integer32, dsmonPdistTopNPDLocalIndex Integer32, dsmonPdistTopNAggGroup DsmonCounterAggGroupIndex, dsmonPdistTopNRate Gauge32, dsmonPdistTopNRateOvfl Gauge32, dsmonPdistTopNHCRate CounterBasedGauge64 } dsmonPdistTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the dsmonPdistTopNTable among those in the same report. This index is between 1 and N, where N is the number of entries in this report. Note that 'N' may change over time, and may also be less than the dsmonPdistTopNCtlGrantedSize value associated with this entry." ::= { dsmonPdistTopNEntry 1 } dsmonPdistTopNPDLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex value which identifies the protocol associated with this entry. If the protocolDirEntry associated with the protocolDirLocalIndex with the same value as this object is de-activated or deleted, then the agent MUST delete this dsmonPdistTopN entry." ::= { dsmonPdistTopNEntry 2 } dsmonPdistTopNAggGroup OBJECT-TYPE SYNTAX DsmonCounterAggGroupIndex Bierman Standards Track [Page 49] RFC 3287 DSMON MIB July 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The DSCP counter aggregation group index value associated with protocol identified in this entry. This object identifies the dsmonAggGroupEntry with the same dsmonAggControlIndex value as the associated dsmonPdistCtlAggProfile object and the same dsmonAggGroupIndex value as this object." ::= { dsmonPdistTopNEntry 3 } dsmonPdistTopNRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval. The selected variable is this protocol's instance of the object selected by dsmonPdistTopNCtlRateBase. If the associated dsmonPdistTopNCtlRateBase is equal to 'dsmonPdistTopNHCPkts' or 'dsmonPdistTopNHCOctets', then this object will contain the the least significant 32 bits of the associated dsmonPdistTopNHCRate object." ::= { dsmonPdistTopNEntry 4 } dsmonPdistTopNRateOvfl OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The most significant 32 bits of the associated dsmonPdistTopNHCRate object. If the associated dsmonPdistTopNCtlRateBase is equal to 'dsmonPdistTopNHCPkts' or 'dsmonPdistTopNHCOctets', then this object will contain the upper 32 bits of the associated dsmonPdistTopNHCRate object. If the associated dsmonPdistTopNCtlRateBase is equal to 'dsmonPdistTopNPkts' or 'dsmonPdistTopNOctets', then this object will contain the value zero. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonPdistTopNEntry 5 } Bierman Standards Track [Page 50] RFC 3287 DSMON MIB July 2002 dsmonPdistTopNHCRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval. The selected variable is this protocol's instance of the object selected by dsmonPdistTopNCtlRateBase. If the associated dsmonPdistTopNCtlRateBase is equal to 'dsmonPdistTopNPkts' or 'dsmonPdistTopNOctets', then this object will contain the value zero, and the associated dsmonPdistTopNRate object will contain the change in the selected variable during the sampling interval. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonPdistTopNEntry 6 } -- *********************************************************** -- * * -- * P E R - H O S T C O L L E C T I O N S * -- * * -- *********************************************************** -- -- NL Host Statistics Control Table -- dsmonHostCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonHostCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls setup of per counter aggregation group, per network layer host distribution statistics. Note that an agent MAY choose to limit the actual number of entries which may be created in this table. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]." ::= { dsmonHostObjects 1 } dsmonHostCtlEntry OBJECT-TYPE Bierman Standards Track [Page 51] RFC 3287 DSMON MIB July 2002 SYNTAX DsmonHostCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonHostCtlTable. Entries are created and deleted from this table by management action only, using the dsmonHostCtlStatus RowStatus object. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Activation of a control row in this table will cause an associated dsmonHostTable to be created and maintained by the agent." INDEX { dsmonHostCtlIndex } ::= { dsmonHostCtlTable 1 } DsmonHostCtlEntry ::= SEQUENCE { dsmonHostCtlIndex Integer32, dsmonHostCtlDataSource DataSource, dsmonHostCtlAggProfile DsmonCounterAggProfileIndex, dsmonHostCtlMaxDesiredEntries Integer32, dsmonHostCtlIPv4PrefixLen Integer32, dsmonHostCtlIPv6PrefixLen Integer32, dsmonHostCtlDroppedFrames Counter32, dsmonHostCtlInserts Counter32, dsmonHostCtlDeletes Counter32, dsmonHostCtlCreateTime LastCreateTime, dsmonHostCtlOwner OwnerString, dsmonHostCtlStatus RowStatus } dsmonHostCtlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary and unique index for this dsmonHostCtlEntry." ::= { dsmonHostCtlEntry 1 } dsmonHostCtlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION Bierman Standards Track [Page 52] RFC 3287 DSMON MIB July 2002 "The source of data for the associated dsmonHostTable. Note that only packets that contain a network protocol encapsulation which contains a DS field [RFC2474] will be counted in this table. This object MUST NOT be modified if the associated dsmonHostCtlStatus object is equal to active(1)." ::= { dsmonHostCtlEntry 2 } dsmonHostCtlAggProfile OBJECT-TYPE SYNTAX DsmonCounterAggProfileIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The dsmonAggControlIndex value identifying the counter aggregation profile which should be used on behalf of this dsmonHostCtlEntry. The associated dsmonAggControlEntry and dsmonAggProfileEntries, identified by the same dsmonAggControlIndex index value, MUST be active in order for this entry to remain active. It is possible for the counter aggregation configuration to change from a valid to invalid state for this dsmonHost collection. In this case, the associated dsmonHostCtlStatus object will be changed to the 'notReady' state, and data collection will not occur on behalf of this control entry. Note that an agent MAY choose to limit the actual number of counter aggregation profiles which may be applied to a particular data source. This object MUST NOT be modified if the associated dsmonHostCtlStatus object is equal to active(1)." ::= { dsmonHostCtlEntry 3 } dsmonHostCtlMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1 | 1..2147483647) UNITS "table entries" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of entries that are desired in the dsmonHostTable on behalf of this control entry. The probe will not create more than this number of associated entries in the table, but MAY choose to create fewer entries in this table for any reason including the lack of resources. Bierman Standards Track [Page 53] RFC 3287 DSMON MIB July 2002 If this value is set to -1, the probe MAY create any number of entries in this table. This object MUST NOT be modified if the associated dsmonHostCtlStatus object is equal to active(1)." ::= { dsmonHostCtlEntry 4 } dsmonHostCtlIPv4PrefixLen OBJECT-TYPE SYNTAX Integer32 (8..32) UNITS "bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of 'leftmost' contiguous bits in the host address field for encapsulations of IPv4, that should be maintained in this collection. This object controls how the dsmonHostAddress object is derived for packets which contain an encapsulation of IPv4. If this object has a value less than 32, then 'm' rightmost bits, where 'm' is equal to '32 - dsmonHostCtlIPv4PrefixLen', will be cleared to zero for counting purposes only. The 'leftmost' bit is the most significant bit of the first network-byte-order octet of the address. If this object is equal to 32, then no bits are cleared in each dsmonHostAddress field. This object MUST NOT be modified if the associated dsmonHostCtlStatus object is equal to active(1)." DEFVAL { 32 } ::= { dsmonHostCtlEntry 5 } dsmonHostCtlIPv6PrefixLen OBJECT-TYPE SYNTAX Integer32 (8..128) UNITS "bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of 'leftmost' contiguous bits in the host address field for encapsulations of IPv6, that should be maintained in this collection. This object controls how the dsmonHostAddress object is derived for packets which contain an encapsulation of IPv6. If this object has a value less than 128, then 'm' rightmost bits, where 'm' is equal to '128 - Bierman Standards Track [Page 54] RFC 3287 DSMON MIB July 2002 dsmonHostCtlIPv6PrefixLen', will be cleared to zero for counting purposes only. The 'leftmost' bit is the most significant bit of the first network-byte-order octet of the address. If this object is equal to 128, then no bits are cleared in each dsmonHostAddress field. This object MUST NOT be modified if the associated dsmonHostCtlStatus object is equal to active(1)." DEFVAL { 128 } ::= { dsmonHostCtlEntry 6 } dsmonHostCtlDroppedFrames OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for the associated dsmonHost entries for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the dsmonHostTable is inactive because no appropriate protocols are enabled in the protocol directory, this value SHOULD be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { dsmonHostCtlEntry 7 } dsmonHostCtlInserts OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a dsmonHost entry has been inserted into the dsmonHost table. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. Bierman Standards Track [Page 55] RFC 3287 DSMON MIB July 2002 To allow for efficient implementation strategies, agents MAY delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting dsmonHostCtlDeletes from dsmonHostCtlInserts." ::= { dsmonHostCtlEntry 8 } dsmonHostCtlDeletes OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a dsmonHost entry has been deleted from the dsmonHost table (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents MAY delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting dsmonHostCtlDeletes from dsmonHostCtlInserts." ::= { dsmonHostCtlEntry 9 } dsmonHostCtlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to detect if the table has been deleted and recreated between polls." ::= { dsmonHostCtlEntry 10 } dsmonHostCtlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current Bierman Standards Track [Page 56] RFC 3287 DSMON MIB July 2002 DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { dsmonHostCtlEntry 11 } dsmonHostCtlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this dsmonHostCtlEntry. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the dsmonHostTable shall be deleted." ::= { dsmonHostCtlEntry 12 } -- -- NL Host Statistics Table -- dsmonHostTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for particular network protocols which contain a DS field, and that has been discovered on a particular dataSource. The probe will add to this table all appropriate network protocols, for each network address seen as the source or destination address in all packets with no MAC errors, and will increment octet and packet counts in the table for all packets with no MAC errors. If the dsmonAggControlLocked object is equal to 'false', then all entries in this table will be deleted, and the agent will not process packets on behalf of any dsmonHostCtlEntry." ::= { dsmonHostObjects 2 } dsmonHostEntry OBJECT-TYPE SYNTAX DsmonHostEntry MAX-ACCESS not-accessible STATUS current Bierman Standards Track [Page 57] RFC 3287 DSMON MIB July 2002 DESCRIPTION "A list of information on Differentiated Services DSCP usage, containing packet and octet counters for each counter aggregation group index configured for collection per host address, as identified in the dsmonAggProfileTable. The dsmonHostCtlIndex value in the index identifies the dsmonHostCtlEntry on whose behalf this entry was created. The protocolDirLocalIndex value in the index identifies the specific network layer protocol encapsulation associated with each entry, and the network protocol type of the dsmonHostAddress object. It MUST identify a protocolDirEntry which contains a DS field (e.g., IPv4 or IPv6). Note that if a protocol encapsulation with multiple network layers is specified, then associated entries in this table refer to the innermost network protocol layer host address. The dsmonAggGroupIndex value in the index is determined by examining the DSCP value in each monitored packet, and the dsmonAggProfileTable entry configured for that value. An example of the indexing of this entry is dsmonHostOutPkts.1.27273.3.200.4.171.69.120.0" INDEX { dsmonHostCtlIndex, dsmonHostTimeMark, dsmonAggGroupIndex, protocolDirLocalIndex, dsmonHostAddress } ::= { dsmonHostTable 1 } DsmonHostEntry ::= SEQUENCE { dsmonHostTimeMark TimeFilter, dsmonHostAddress OCTET STRING, dsmonHostInPkts ZeroBasedCounter32, dsmonHostInOctets ZeroBasedCounter32, dsmonHostInOvflPkts ZeroBasedCounter32, dsmonHostInOvflOctets ZeroBasedCounter32, dsmonHostInHCPkts ZeroBasedCounter64, dsmonHostInHCOctets ZeroBasedCounter64, dsmonHostOutPkts ZeroBasedCounter32, dsmonHostOutOctets ZeroBasedCounter32, dsmonHostOutOvflPkts ZeroBasedCounter32, dsmonHostOutOvflOctets ZeroBasedCounter32, dsmonHostOutHCPkts ZeroBasedCounter64, dsmonHostOutHCOctets ZeroBasedCounter64, dsmonHostCreateTime LastCreateTime Bierman Standards Track [Page 58] RFC 3287 DSMON MIB July 2002 } dsmonHostTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Time Filter index for this table. This object may be used by a management station to retrieve only rows which have been created or modified since a particular time. Note that the current value for a row are always returned and the TimeFilter is not a historical data archiving mechanism. Refer to RFC 2021 [RFC2021] for a detailed description of TimeFilter operation." ::= { dsmonHostEntry 1 } dsmonHostAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..110)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this dsmonHostEntry. This object is encoded according to the protocol type indicated by the protocolDirLocalIndex value in the index. In addition, this object may have some 'rightmost' bits cleared to zero for counting purposes, as indicated by the associated dsmonHostCtlIPv4PrefixLen or dsmonHostCtlIPv6PrefixLen objects." ::= { dsmonHostEntry 2 } dsmonHostInPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors, using one of the DSCP values in the indicated counter aggregation group, and transmitted to this address, since this entry was added to the dsmonHostTable. Note that this is the number of link- layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { dsmonHostEntry 3 } dsmonHostInOctets OBJECT-TYPE Bierman Standards Track [Page 59] RFC 3287 DSMON MIB July 2002 SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in all packets, transmitted to this address and using one of the DSCP values in the indicated counter aggregation group, since this entry was added to the dsmonHostTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { dsmonHostEntry 4 } dsmonHostInOvflPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonHostInPkts counter has overflowed. Note that this object will only be instantiated if the associated dsmonHostInHCPkts object is also instantiated for a particular dataSource." ::= { dsmonHostEntry 5 } dsmonHostInOvflOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonHostInOctets counter has overflowed. Note that this object will only be instantiated if the associated dsmonHostInHCOctets object is also instantiated for a particular dataSource." ::= { dsmonHostEntry 6 } dsmonHostInHCPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonHostInPkts object. Note that this object will only be instantiated if the RMON Bierman Standards Track [Page 60] RFC 3287 DSMON MIB July 2002 agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonHostEntry 7 } dsmonHostInHCOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonHostInOctets object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonHostEntry 8 } dsmonHostOutPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors, using one of the DSCP values in the indicated counter aggregation group, and transmitted by this address, since this entry was added to the dsmonHostTable. Note that this is the number of link- layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { dsmonHostEntry 9 } dsmonHostOutOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets, transmitted by this address and using one of the DSCP values in the identified counter aggregation group, since this entry was added to the dsmonHostTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { dsmonHostEntry 10 } Bierman Standards Track [Page 61] RFC 3287 DSMON MIB July 2002 dsmonHostOutOvflPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonHostOutPkts counter has overflowed. Note that this object will only be instantiated if the associated dsmonHostOutHCPkts object is also instantiated for a particular dataSource." ::= { dsmonHostEntry 11 } dsmonHostOutOvflOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonHostOutOctets counter has overflowed. Note that this object will only be instantiated if the associated dsmonHostOutHCOctets object is also instantiated for a particular dataSource." ::= { dsmonHostEntry 12 } dsmonHostOutHCPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonHostOutPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonHostEntry 13 } dsmonHostOutHCOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonHostOutOctets object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonHostEntry 14 } Bierman Standards Track [Page 62] RFC 3287 DSMON MIB July 2002 dsmonHostCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this dsmonHost entry was last instantiated by the agent. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { dsmonHostEntry 15 } -- -- Per-Protocol Per-Host NL Statistics TopN Control Table -- dsmonHostTopNCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonHostTopNCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N dsmonHost entries according to a selected metric. Note that an agent MAY choose to limit the actual number of entries which may be created in this table. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]." ::= { dsmonHostObjects 3 } dsmonHostTopNCtlEntry OBJECT-TYPE SYNTAX DsmonHostTopNCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonHostTopNCtlTable. Entries are created and deleted from this table by management action only, using the dsmonHostTopNCtlStatus RowStatus object. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Activation of a control row in this table will cause an Bierman Standards Track [Page 63] RFC 3287 DSMON MIB July 2002 associated dsmonHostTopNTable to be created and maintained by the agent." INDEX { dsmonHostTopNCtlIndex } ::= { dsmonHostTopNCtlTable 1 } DsmonHostTopNCtlEntry ::= SEQUENCE { dsmonHostTopNCtlIndex Integer32, dsmonHostTopNCtlHostIndex Integer32, dsmonHostTopNCtlRateBase INTEGER, dsmonHostTopNCtlTimeRemaining Integer32, dsmonHostTopNCtlGeneratedReports Counter32, dsmonHostTopNCtlDuration Integer32, dsmonHostTopNCtlRequestedSize Integer32, dsmonHostTopNCtlGrantedSize Integer32, dsmonHostTopNCtlStartTime TimeStamp, dsmonHostTopNCtlOwner OwnerString, dsmonHostTopNCtlStatus RowStatus } dsmonHostTopNCtlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the dsmonHostTopNCtlTable. Each such entry defines one Top N report prepared for one RMON dataSource." ::= { dsmonHostTopNCtlEntry 1 } dsmonHostTopNCtlHostIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The dsmonHostTable for which a top N report will be prepared on behalf of this entry. The dsmonHostTable is identified by the value of the dsmonHostCtlIndex for that table - that value is used here to identify the particular table. This object MUST NOT be modified if the associated dsmonHostTopNCtlStatus object is equal to active(1)." ::= { dsmonHostTopNCtlEntry 2 } dsmonHostTopNCtlRateBase OBJECT-TYPE SYNTAX INTEGER { dsmonHostTopNInPkts(1), dsmonHostTopNInOctets(2), Bierman Standards Track [Page 64] RFC 3287 DSMON MIB July 2002 dsmonHostTopNOutPkts(3), dsmonHostTopNOutOctets(4), dsmonHostTopNTotalPkts(5), dsmonHostTopNTotalOctets(6), dsmonHostTopNInHCPkts(7), dsmonHostTopNInHCOctets(8), dsmonHostTopNOutHCPkts(9), dsmonHostTopNOutHCOctets(10), dsmonHostTopNTotalHCPkts(11), dsmonHostTopNTotalHCOctets(12) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable(s) for each dsmonHost that the dsmonHostTopNRate and dsmonHostTopNHCRate variables are based upon. Each dsmonHostTopN report generated on behalf of this control entry will be ranked in descending order, based on the associated dsmonHostTable counter(s), identified by this object. The following table identifies the dsmonHostTable counters associated with each enumeration: Enumeration RateBase MIB Objects ----------- -------------------- dsmonHostTopNInPkts dsmonHostInPkts dsmonHostTopNInOctets dsmonHostInOctets dsmonHostTopNOutPkts dsmonHostOutPkts dsmonHostTopNOutOctets dsmonHostOutOctets dsmonHostTopNTotalPkts dsmonHostInPkts + dsmonHostOutPkts dsmonHostTopNTotalOctets dsmonHostInOctets + dsmonHostOutOctets dsmonHostTopNInHCPkts dsmonHostInHCPkts dsmonHostTopNInHCOctets dsmonHostInHCOctets dsmonHostTopNOutHCPkts dsmonHostOutHCPkts dsmonHostTopNOutHCOctets dsmonHostOutHCPkts dsmonHostTopNTotalHCPkts dsmonHostInHCPkts + dsmonHostOutHCPkts dsmonHostTopNTotalHCOctets dsmonHostInHCOctets + dsmonHostOutHCOctets The following enumerations are only available if the agent supports High Capacity monitoring: dsmonHostTopNInHCPkts dsmonHostTopNInHCOctets Bierman Standards Track [Page 65] RFC 3287 DSMON MIB July 2002 dsmonHostTopNOutHCPkts dsmonHostTopNOutHCOctets dsmonHostTopNTotalHCPkts dsmonHostTopNTotalHCOctets It is an implementation-specific matter whether an agent can detect an overflow condition resulting from the addition of two counter delta values for the following enumerations: dsmonHostTopNTotalPkts dsmonHostTopNTotalOctets dsmonHostTopNTotalHCPkts dsmonHostTopNTotalHCOctets In the event such an overflow condition can be detected by the agent, the associated dsmonHostTopNRate, dsmonHostTopNRateOvfl, and/or dsmonHostTopNHCRate objects should be set to their maximum value. This object MUST NOT be modified if the associated dsmonHostTopNCtlStatus object is equal to active(1)." ::= { dsmonHostTopNCtlEntry 3 } dsmonHostTopNCtlTimeRemaining OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report, and is immediately loaded into the associated dsmonHostTopNCtlDuration object. When the report finishes, the probe will automatically start another collection with the same initial value of dsmonHostTopNCtlTimeRemaining. Thus the management station may simply read the resulting reports repeatedly, checking the startTime and duration each time to ensure that a report was not missed or that the report parameters were not changed. While the value of this object is non-zero, it decrements by one per second until it reaches zero. At the time that this object decrements to zero, the report is made accessible in the dsmonHostTopNTable, overwriting any report that may be Bierman Standards Track [Page 66] RFC 3287 DSMON MIB July 2002 there. When this object is modified by the management station, any associated entries in the dsmonHostTopNTable shall be deleted." DEFVAL { 1800 } ::= { dsmonHostTopNCtlEntry 4 } dsmonHostTopNCtlGeneratedReports OBJECT-TYPE SYNTAX Counter32 UNITS "reports" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reports that have been generated by this entry." ::= { dsmonHostTopNCtlEntry 5 } dsmonHostTopNCtlDuration OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval. When the associated dsmonHostTopNCtlTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the dsmonHostTopNCtlTimeRemaining is set. This value shall be zero if no reports have been requested for this dsmonHostTopNCtlEntry." ::= { dsmonHostTopNCtlEntry 6 } dsmonHostTopNCtlRequestedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "table entries" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of dsmonHost entries requested for this report. When this object is created or modified, the probe SHOULD set dsmonHostTopNCtlGrantedSize as closely to this object as is possible for the particular probe implementation and Bierman Standards Track [Page 67] RFC 3287 DSMON MIB July 2002 available resources." DEFVAL { 150 } ::= { dsmonHostTopNCtlEntry 7 } dsmonHostTopNCtlGrantedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of dsmonHost entries in this report. When the associated dsmonHostTopNCtlRequestedSize object is created or modified, the probe SHOULD set this object as closely to the requested value as is possible for the particular implementation and available resources. The probe MUST NOT lower this value except as a result of a set to the associated dsmonHostTopNCtlRequestedSize object. Protocol entries with the highest value of dsmonHostTopNRate or dsmonHostTopNHCRate (depending on the value of the associated dsmonHostTopNCtlRateBase object) shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more dsmonHost entries." ::= { dsmonHostTopNCtlEntry 8 } dsmonHostTopNCtlStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this top N report was last started. In other words, this is the time that the associated dsmonHostTopNCtlTimeRemaining object was modified to start the requested report or the time the report was last automatically (re)started. This object may be used by the management station to determine if a report was missed or not." ::= { dsmonHostTopNCtlEntry 9 } dsmonHostTopNCtlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION Bierman Standards Track [Page 68] RFC 3287 DSMON MIB July 2002 "The entity that configured this entry and is therefore using the resources assigned to it." ::= { dsmonHostTopNCtlEntry 10 } dsmonHostTopNCtlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this dsmonHostTopNCtlEntry. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the dsmonHostTopNTable shall be deleted by the agent." ::= { dsmonHostTopNCtlEntry 11 } -- -- dsmonHost TopN Table -- dsmonHostTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonHostTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for those dsmonHost entries that have counted the highest number of octets or packets. If the dsmonAggControlLocked object is equal to 'false', then all entries in this table SHALL be deleted, and the agent will not process TopN reports on behalf of any dsmonHostTopNCtlEntry. When the dsmonAggControlLocked object is set to 'true', then particular reports SHOULD be restarted from the beginning, on behalf of all active rows in the dsmonHostTopNCtlTable. Note that dsmonHost entries which did not increment at all during the report interval SHOULD NOT be included in dsmonHostTopN reports." ::= { dsmonHostObjects 4 } dsmonHostTopNEntry OBJECT-TYPE SYNTAX DsmonHostTopNEntry MAX-ACCESS not-accessible Bierman Standards Track [Page 69] RFC 3287 DSMON MIB July 2002 STATUS current DESCRIPTION "A conceptual row in the dsmonHostTopNTable. The dsmonHostTopNCtlIndex value in the index identifies the dsmonHostTopNCtlEntry on whose behalf this entry was created. Entries in this table are ordered from 1 to 'N', where lower numbers represent higher values of the rate base object, over the report interval." INDEX { dsmonHostTopNCtlIndex, dsmonHostTopNIndex } ::= { dsmonHostTopNTable 1 } DsmonHostTopNEntry ::= SEQUENCE { dsmonHostTopNIndex Integer32, dsmonHostTopNPDLocalIndex Integer32, dsmonHostTopNAddress OCTET STRING, dsmonHostTopNAggGroup DsmonCounterAggGroupIndex, dsmonHostTopNRate Gauge32, dsmonHostTopNRateOvfl Gauge32, dsmonHostTopNHCRate CounterBasedGauge64 } dsmonHostTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the dsmonHostTopNTable among those in the same report. This index is between 1 and N, where N is the number of entries in this report." ::= { dsmonHostTopNEntry 1 } dsmonHostTopNPDLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex value which identifies the protocol associated with the dsmonHostTopNAddress object in this entry. If the protocolDirEntry associated with the protocolDirLocalIndex with the same value as this object is de-activated or deleted, then the agent MUST delete this dsmonHostTopN entry." Bierman Standards Track [Page 70] RFC 3287 DSMON MIB July 2002 ::= { dsmonHostTopNEntry 2 } dsmonHostTopNAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The dsmonHostAddress value for the network host identified in this entry. The associated dsmonHostTopNPDLocalIndex object identifies the network protocol type and the encoding rules for this object." ::= { dsmonHostTopNEntry 3 } dsmonHostTopNAggGroup OBJECT-TYPE SYNTAX DsmonCounterAggGroupIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The counter aggregation group index value associated with host identified in this entry. This object identifies the dsmonAggGroupEntry with the same dsmonAggControlIndex value as the associated dsmonHostCtlAggProfile object and the same dsmonAggGroupIndex value as this object." ::= { dsmonHostTopNEntry 4 } dsmonHostTopNRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval. The selected variable is this host's instance of the object selected by dsmonHostTopNCtlRateBase. If the associated dsmonHostTopNCtlRateBase indicates a High Capacity monitoring enumeration, (e.g. 'dsmonHostTopNInHCPkts'), then this object will contain the the least significant 32 bits of the associated dsmonHostTopNHCRate object." ::= { dsmonHostTopNEntry 5 } dsmonHostTopNRateOvfl OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The most significant 32 bits of the associated dsmonHostTopNHCRate object. Bierman Standards Track [Page 71] RFC 3287 DSMON MIB July 2002 If the associated dsmonHostTopNCtlRateBase is equal to any of the High Capacity monitoring enumerations (e.g. 'dsmonHostTopNInHCPkts'), then this object will contain the upper 32 bits of the associated dsmonHostTopNHCRate object. If the associated dsmonHostTopNCtlRateBase is not equal to any of High Capacity monitoring enumerations, then this object will contain the value zero. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonHostTopNEntry 6 } dsmonHostTopNHCRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of change in the selected variable during this sampling interval. The selected variable is this host's instance of the object selected by dsmonHostTopNCtlRateBase. If the associated dsmonHostTopNCtlRateBase is not equal to any of the High Capacity monitoring enumerations (e.g., 'dsmonHostTopNInPkts'), then this object will contain the value zero, and the associated dsmonHostTopNRate object will contain the change in the selected variable during the sampling interval. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonHostTopNEntry 7 } -- ************************************************************** -- * * -- * P E R - C O N V E R S I O N C O L L E C T I O N S * -- * * -- ************************************************************** -- -- AL Matrix Statistics Control Table -- dsmonMatrixCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonMatrixCtlEntry MAX-ACCESS not-accessible STATUS current Bierman Standards Track [Page 72] RFC 3287 DSMON MIB July 2002 DESCRIPTION "Controls setup of per counter aggregation group, per host- pair, application protocol distribution statistics. Note that an agent MAY choose to limit the actual number of entries which may be created in this table. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]." ::= { dsmonMatrixObjects 1 } dsmonMatrixCtlEntry OBJECT-TYPE SYNTAX DsmonMatrixCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonMatrixCtlTable. Entries are created and deleted from this table by management action only, using the dsmonMatrixCtlStatus RowStatus object. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Activation of a control row in this table will cause an associated dsmonMatrixSDTable and dsmonMatrixDSTable to be created and maintained by the agent." INDEX { dsmonMatrixCtlIndex } ::= { dsmonMatrixCtlTable 1 } DsmonMatrixCtlEntry ::= SEQUENCE { dsmonMatrixCtlIndex Integer32, dsmonMatrixCtlDataSource DataSource, dsmonMatrixCtlAggProfile DsmonCounterAggProfileIndex, dsmonMatrixCtlMaxDesiredEntries Integer32, dsmonMatrixCtlDroppedFrames Counter32, dsmonMatrixCtlInserts Counter32, dsmonMatrixCtlDeletes Counter32, dsmonMatrixCtlCreateTime LastCreateTime, dsmonMatrixCtlOwner OwnerString, dsmonMatrixCtlStatus RowStatus } dsmonMatrixCtlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible Bierman Standards Track [Page 73] RFC 3287 DSMON MIB July 2002 STATUS current DESCRIPTION "An arbitrary and unique index for this dsmonMatrixCtlEntry." ::= { dsmonMatrixCtlEntry 1 } dsmonMatrixCtlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of data for the associated dsmonMatrixSDTable and dsmonMatrixDSTable. Note that only packets that contain a network protocol encapsulation which contains a DS field [RFC2474] will be counted in this table. This object MUST NOT be modified if the associated dsmonMatrixCtlStatus object is equal to active(1)." ::= { dsmonMatrixCtlEntry 2 } dsmonMatrixCtlAggProfile OBJECT-TYPE SYNTAX DsmonCounterAggProfileIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The dsmonAggControlIndex value identifying the counter aggregation profile which should be used on behalf of this dsmonMatrixCtlEntry. The associated dsmonAggControlEntry and dsmonAggProfileEntries, identified by the same dsmonAggControlIndex index value, MUST be active in order for this entry to remain active. It is possible for the counter aggregation configuration to change from a valid to invalid state for this dsmonMatrix collection. In this case, the associated dsmonMatrixCtlStatus object will be changed to the 'notReady' state, and data collection will not occur on behalf of this control entry. Note that an agent MAY choose to limit the actual number of counter aggregation profiles which may be applied to a particular data source. This object MUST NOT be modified if the associated dsmonMatrixCtlStatus object is equal to active(1)." ::= { dsmonMatrixCtlEntry 3 } Bierman Standards Track [Page 74] RFC 3287 DSMON MIB July 2002 dsmonMatrixCtlMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1 | 1..2147483647) UNITS "table entries" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of entries that are desired in the dsmonMatrix tables on behalf of this control entry. The probe will not create more than this number of associated entries in these tables, but may choose to create fewer entries in this table for any reason including the lack of resources. If this value is set to -1, the probe may create any number of entries in this table. This object MUST NOT be modified if the associated dsmonMatrixCtlStatus object is equal to active(1)." ::= { dsmonMatrixCtlEntry 4 } dsmonMatrixCtlDroppedFrames OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for the associated dsmonMatrixSD and dsmonMatrixDS entries for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the dsmonMatrix tables are inactive because no appropriate protocols are enabled in the protocol directory, this value SHOULD be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { dsmonMatrixCtlEntry 5 } dsmonMatrixCtlInserts OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only Bierman Standards Track [Page 75] RFC 3287 DSMON MIB July 2002 STATUS current DESCRIPTION "The number of times a dsmonMatrix entry has been inserted into the dsmonMatrix tables. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. The addition of a conversation into both the dsmonMatrixSDTable and dsmonMatrixDSTable shall be counted as two insertions (even though every addition into one table must be accompanied by an insertion into the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the sum of the dsmonMatrixSDTable and dsmonMatrixDSTable sizes can be determined by subtracting dsmonMatrixCtlDeletes from dsmonMatrixCtlInserts." ::= { dsmonMatrixCtlEntry 6 } dsmonMatrixCtlDeletes OBJECT-TYPE SYNTAX Counter32 UNITS "table entries" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a dsmonMatrix entry has been deleted from the dsmonMatrix tables (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. The deletion of a conversation from both the dsmonMatrixSDTable and dsmonMatrixDSTable shall be counted as two deletions (even though every deletion from one table must be accompanied by a deletion from the other). To allow for efficient implementation strategies, agents MAY delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the sum of the dsmonMatrixSDTable and dsmonMatrixDSTable sizes can be determined by subtracting dsmonMatrixCtlDeletes from dsmonMatrixCtlInserts." ::= { dsmonMatrixCtlEntry 7 } Bierman Standards Track [Page 76] RFC 3287 DSMON MIB July 2002 dsmonMatrixCtlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to detect if the table has been deleted and recreated between polls." ::= { dsmonMatrixCtlEntry 8 } dsmonMatrixCtlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { dsmonMatrixCtlEntry 9 } dsmonMatrixCtlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this dsmonMatrixCtlEntry. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the dsmonMatrixSDTable and dsmonMatrixDSTable shall be deleted." ::= { dsmonMatrixCtlEntry 10 } -- -- AL Matrix SD Statistics Table -- dsmonMatrixSDTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonMatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of application traffic matrix entries which collect statistics for conversations of a particular application protocol between two network-level addresses. This table is indexed first by the source address and then by the Bierman Standards Track [Page 77] RFC 3287 DSMON MIB July 2002 destination address to make it convenient to collect all statistics from a particular address. The probe will add to this table all pairs of addresses for all protocols seen in all packets with no MAC errors, and will increment octet and packet counts in the table for all packets with no MAC errors." ::= { dsmonMatrixObjects 2 } dsmonMatrixSDEntry OBJECT-TYPE SYNTAX DsmonMatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonMatrixSDTable. The dsmonMatrixCtlIndex value in the index identifies the dsmonMatrixCtlEntry on whose behalf this entry was created. The dsmonAggGroupIndex value in the index is determined by examining the DSCP value in each monitored packet, and the dsmonAggProfileTable entry configured for that value." INDEX { dsmonMatrixCtlIndex, dsmonMatrixTimeMark, dsmonAggGroupIndex, dsmonMatrixNLIndex, dsmonMatrixSourceAddress, dsmonMatrixDestAddress, dsmonMatrixALIndex } ::= { dsmonMatrixSDTable 1 } DsmonMatrixSDEntry ::= SEQUENCE { dsmonMatrixTimeMark TimeFilter, dsmonMatrixNLIndex Integer32, dsmonMatrixSourceAddress OCTET STRING, dsmonMatrixDestAddress OCTET STRING, dsmonMatrixALIndex Integer32, dsmonMatrixSDPkts ZeroBasedCounter32, dsmonMatrixSDOvflPkts ZeroBasedCounter32, dsmonMatrixSDHCPkts ZeroBasedCounter64, dsmonMatrixSDOctets ZeroBasedCounter32, dsmonMatrixSDOvflOctets ZeroBasedCounter32, dsmonMatrixSDHCOctets ZeroBasedCounter64, dsmonMatrixSDCreateTime LastCreateTime } dsmonMatrixTimeMark OBJECT-TYPE Bierman Standards Track [Page 78] RFC 3287 DSMON MIB July 2002 SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Time Filter index for this table. This object may be used by a management station to retrieve only rows which have been created or modified since a particular time. Note that the current value for a row are always returned and the TimeFilter is not a historical data archiving mechanism. Refer to RFC 2021 [RFC2021] for a detailed description of TimeFilter operation." ::= { dsmonMatrixSDEntry 1 } dsmonMatrixNLIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The protocolDirLocalIndex value of a protocolDirEntry representing the specific network layer protocol encapsulation associated with each entry, and the network protocol type of the dsmonMatrixSourceAddress and dsmonMatrixDestAddress objects." ::= { dsmonMatrixSDEntry 2 } dsmonMatrixSourceAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..54)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this dsmonMatrix entry. This is represented as an octet string with specific semantics and length as identified by the dsmonMatrixNLIndex component of the index. For example, if the dsmonMatrixNLIndex indicates an encapsulation of IPv4, this object is encoded as a length octet of 4, followed by the 4 octets of the IPv4 address, in network byte order." ::= { dsmonMatrixSDEntry 3 } dsmonMatrixDestAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..54)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this dsmonMatrix entry. Bierman Standards Track [Page 79] RFC 3287 DSMON MIB July 2002 This is represented as an octet string with specific semantics and length as identified by the dsmonMatrixNLIndex component of the index. For example, if the dsmonMatrixNLIndex indicates an encapsulation of IPv4, this object is encoded as a length octet of 4, followed by the 4 octets of the IPv4 address, in network byte order." ::= { dsmonMatrixSDEntry 4 } dsmonMatrixALIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The protocolDirLocalIndex value of the protocolDirEntry representing the specific application layer protocol associated with each entry. It MUST identify an protocolDirEntry which is a direct or indirect descendant of the protocolDirEntry identified by the associated dsmonMatrixNLIndex object." ::= { dsmonMatrixSDEntry 5 } dsmonMatrixSDPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type (indicated by the associated dsmonMatrixALIndex object) without errors transmitted from the source address to the destination address since this entry was added to the dsmonMatrixSDTable. Note that this is the number of link- layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { dsmonMatrixSDEntry 6 } dsmonMatrixSDOvflPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonMatrixSDPkts counter has overflowed, since this entry was added to the dsmonMatrixSDTable." Bierman Standards Track [Page 80] RFC 3287 DSMON MIB July 2002 ::= { dsmonMatrixSDEntry 7 } dsmonMatrixSDHCPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonMatrixSDPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonMatrixSDEntry 8 } dsmonMatrixSDOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets of this protocol type transmitted from the source address to the destination address since this entry was added to the dsmonMatrixSDTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { dsmonMatrixSDEntry 9 } dsmonMatrixSDOvflOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonMatrixSDOctets counter has overflowed, since this entry was added to the dsmonMatrixSDTable." ::= { dsmonMatrixSDEntry 10 } dsmonMatrixSDHCOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION Bierman Standards Track [Page 81] RFC 3287 DSMON MIB July 2002 "The 64-bit version of the dsmonMatrixSDPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonMatrixSDEntry 11 } dsmonMatrixSDCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { dsmonMatrixSDEntry 12 } -- -- AL Matrix DS Statistics Table -- dsmonMatrixDSTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonMatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of application traffic matrix entries which collect statistics for conversations of a particular application protocol between two network-level addresses. This table is indexed first by the destination address and then by the source address to make it convenient to collect all statistics from a particular address. The probe will add to this table all pairs of addresses for all protocols seen in all packets with no MAC errors, and will increment octet and packet counts in the table for all packets with no MAC errors." ::= { dsmonMatrixObjects 3 } dsmonMatrixDSEntry OBJECT-TYPE SYNTAX DsmonMatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonMatrixDSTable. Note that this table is conceptually a re-ordered version of the dsmonMatrixSDTable. Therefore, all of the index values from Bierman Standards Track [Page 82] RFC 3287 DSMON MIB July 2002 that table are used by reference, and their semantics are exactly as described in the dsmonMatrixSDTable. The dsmonMatrixCtlIndex value in the index identifies the dsmonMatrixCtlEntry on whose behalf this entry was created. The dsmonMatrixTimeMark value in the index identifies the Time Filter index for this table. The dsmonAggGroupIndex value in the index is determined by examining the DSCP value in each monitored packet, and the dsmonAggProfileTable entry configured for that value. The dsmonMatrixNLIndex value in the index identifies the protocolDirLocalIndex value of a protocolDirEntry representing the specific network layer protocol encapsulation associated with each entry, and the network protocol type of the dsmonMatrixSourceAddress and dsmonMatrixDestAddress objects. The dsmonMatrixDestAddress value in the index identifies the network destination address for this dsmonMatrix entry. The dsmonMatrixSourceAddress value in the index identifies the network source address for this dsmonMatrix entry. The dsmonMatrixALIndex value in the index identifies the protocolDirLocalIndex value of the protocolDirEntry representing the specific application layer protocol associated with each entry." INDEX { dsmonMatrixCtlIndex, dsmonMatrixTimeMark, dsmonAggGroupIndex, dsmonMatrixNLIndex, dsmonMatrixDestAddress, dsmonMatrixSourceAddress, dsmonMatrixALIndex } ::= { dsmonMatrixDSTable 1 } DsmonMatrixDSEntry ::= SEQUENCE { dsmonMatrixDSPkts ZeroBasedCounter32, dsmonMatrixDSOvflPkts ZeroBasedCounter32, dsmonMatrixDSHCPkts ZeroBasedCounter64, dsmonMatrixDSOctets ZeroBasedCounter32, dsmonMatrixDSOvflOctets ZeroBasedCounter32, dsmonMatrixDSHCOctets ZeroBasedCounter64, dsmonMatrixDSCreateTime LastCreateTime Bierman Standards Track [Page 83] RFC 3287 DSMON MIB July 2002 } dsmonMatrixDSPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type (indicated by the associated dsmonMatrixALIndex object) without errors transmitted from the source address to the destination address since this entry was added to the dsmonMatrixDSTable. Note that this is the number of link- layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { dsmonMatrixDSEntry 1 } dsmonMatrixDSOvflPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonMatrixDSPkts counter has overflowed, since this entry was added to the dsmonMatrixDSTable." ::= { dsmonMatrixDSEntry 2 } dsmonMatrixDSHCPkts OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonMatrixDSPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonMatrixDSEntry 3 } dsmonMatrixDSOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets of this protocol type Bierman Standards Track [Page 84] RFC 3287 DSMON MIB July 2002 transmitted from the source address to the destination address since this entry was added to the dsmonMatrixDSTable (excluding framing bits but including FCS octets), excluding those octets in packets that contained errors. Note this doesn't count just those octets in the particular protocol frames, but includes the entire packet that contained the protocol." ::= { dsmonMatrixDSEntry 4 } dsmonMatrixDSOvflOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of times the associated dsmonMatrixDSOctets counter has overflowed, since this entry was added to the dsmonMatrixDSTable." ::= { dsmonMatrixDSEntry 5 } dsmonMatrixDSHCOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The 64-bit version of the dsmonMatrixDSPkts object. Note that this object will only be instantiated if the RMON agent supports High Capacity monitoring for a particular dataSource." ::= { dsmonMatrixDSEntry 6 } dsmonMatrixDSCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { dsmonMatrixDSEntry 7 } -- -- Per-Protocol Per-Matrix Statistics TopN Control Table -- Bierman Standards Track [Page 85] RFC 3287 DSMON MIB July 2002 dsmonMatrixTopNCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonMatrixTopNCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N dsmonMatrix entries according to a selected metric. Note that an agent MAY choose to limit the actual number of entries which may be created in this table. In this case, the agent SHOULD return an error-status of 'resourceUnavailable(13)', as per section 4.2.5 of the 'Protocol Operations for SNMPv2' specification [RFC1905]." ::= { dsmonMatrixObjects 4 } dsmonMatrixTopNCtlEntry OBJECT-TYPE SYNTAX DsmonMatrixTopNCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonMatrixTopNCtlTable. Entries are created and deleted from this table by management action only, using the dsmonMatrixTopNCtlStatus RowStatus object. The agent SHOULD support non-volatile configuration of this table, and upon system initialization, the table SHOULD be initialized with the saved values. Activation of a control row in this table will cause an associated dsmonMatrixTopNTable to be created and maintained by the agent." INDEX { dsmonMatrixTopNCtlIndex } ::= { dsmonMatrixTopNCtlTable 1 } DsmonMatrixTopNCtlEntry ::= SEQUENCE { dsmonMatrixTopNCtlIndex Integer32, dsmonMatrixTopNCtlMatrixIndex Integer32, dsmonMatrixTopNCtlRateBase INTEGER, dsmonMatrixTopNCtlTimeRemaining Integer32, dsmonMatrixTopNCtlGeneratedRpts Counter32, dsmonMatrixTopNCtlDuration Integer32, dsmonMatrixTopNCtlRequestedSize Integer32, dsmonMatrixTopNCtlGrantedSize Integer32, dsmonMatrixTopNCtlStartTime TimeStamp, dsmonMatrixTopNCtlOwner OwnerString, Bierman Standards Track [Page 86] RFC 3287 DSMON MIB July 2002 dsmonMatrixTopNCtlStatus RowStatus } dsmonMatrixTopNCtlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the dsmonMatrixTopNCtlTable. Each such entry defines one Top N report prepared for one RMON dataSource." ::= { dsmonMatrixTopNCtlEntry 1 } dsmonMatrixTopNCtlMatrixIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The dsmonMatrixSDTable for which a top N report will be prepared on behalf of this entry. The dsmonMatrixSDTable is identified by the same value of the dsmonMatrixCtlIndex object. This object MUST NOT be modified if the associated dsmonMatrixTopNCtlStatus object is equal to active(1)." ::= { dsmonMatrixTopNCtlEntry 2 } dsmonMatrixTopNCtlRateBase OBJECT-TYPE SYNTAX INTEGER { dsmonMatrixTopNPkts(1), dsmonMatrixTopNOctets(2), dsmonMatrixTopNHCPkts(3), dsmonMatrixTopNHCOctets(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable for each dsmonMatrixSD entry that the dsmonMatrixTopNRate and dsmonMatrixTopNHCRate variables are based upon. Each dsmonMatrixTopN report generated on behalf of this control entry will be ranked in descending order, based on the associated dsmonMatrixSDTable counter, identified by this object. The following table identifies the dsmonMatrixSDTable counters associated with each enumeration: Enumeration RateBase MIB Objects Bierman Standards Track [Page 87] RFC 3287 DSMON MIB July 2002 ----------- -------------------- dsmonMatrixTopNPkts dsmonMatrixSDPkts dsmonMatrixTopNOctets dsmonMatrixSDOctets dsmonMatrixTopNHCPkts dsmonMatrixSDHCPkts dsmonMatrixTopNHCOctets dsmonMatrixSDHCOctets The following enumerations are only available if the agent supports High Capacity monitoring: dsmonMatrixTopNHCPkts dsmonMatrixTopNHCOctets This object MUST NOT be modified if the associated dsmonMatrixTopNCtlStatus object is equal to active(1)." ::= { dsmonMatrixTopNCtlEntry 3 } dsmonMatrixTopNCtlTimeRemaining OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report, and is immediately loaded into the associated dsmonMatrixTopNCtlDuration object. When the report finishes, the probe will automatically start another collection with the same initial value of dsmonMatrixTopNCtlTimeRemaining. Thus the management station may simply read the resulting reports repeatedly, checking the startTime and duration each time to ensure that a report was not missed or that the report parameters were not changed. While the value of this object is non-zero, it decrements by one per second until it reaches zero. At the time that this object decrements to zero, the report is made accessible in the dsmonMatrixTopNTable, overwriting any report that may be there. When this object is modified by the management station, any associated entries in the dsmonMatrixTopNTable shall be deleted." DEFVAL { 1800 } ::= { dsmonMatrixTopNCtlEntry 4 } Bierman Standards Track [Page 88] RFC 3287 DSMON MIB July 2002 dsmonMatrixTopNCtlGeneratedRpts OBJECT-TYPE SYNTAX Counter32 UNITS "reports" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reports that have been generated by this entry." ::= { dsmonMatrixTopNCtlEntry 5 } dsmonMatrixTopNCtlDuration OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval. When the associated dsmonMatrixTopNCtlTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the dsmonMatrixTopNCtlTimeRemaining is set. This value shall be zero if no reports have been requested for this dsmonMatrixTopNCtlEntry." ::= { dsmonMatrixTopNCtlEntry 6 } dsmonMatrixTopNCtlRequestedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "table entries" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of dsmonMatrix entries requested for this report. When this object is created or modified, the probe SHOULD set dsmonMatrixTopNCtlGrantedSize as closely to this object as is possible for the particular probe implementation and available resources." DEFVAL { 150 } ::= { dsmonMatrixTopNCtlEntry 7 } dsmonMatrixTopNCtlGrantedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "table entries" MAX-ACCESS read-only Bierman Standards Track [Page 89] RFC 3287 DSMON MIB July 2002 STATUS current DESCRIPTION "The maximum number of dsmonMatrix entries in this report. When the associated dsmonMatrixTopNCtlRequestedSize object is created or modified, the probe SHOULD set this object as closely to the requested value as is possible for the particular implementation and available resources. The probe MUST NOT lower this value except as a result of a set to the associated dsmonMatrixTopNCtlRequestedSize object. Protocol entries with the highest value of dsmonMatrixTopNRate or dsmonMatrixTopNHCRate (depending on the value of the associated dsmonMatrixTopNCtlRateBase object) shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more dsmonMatrix entries." ::= { dsmonMatrixTopNCtlEntry 8 } dsmonMatrixTopNCtlStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this top N report was last started. In other words, this is the time that the associated dsmonMatrixTopNCtlTimeRemaining object was modified to start the requested report or the time the report was last automatically (re)started. This object may be used by the management station to determine if a report was missed or not." ::= { dsmonMatrixTopNCtlEntry 9 } dsmonMatrixTopNCtlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { dsmonMatrixTopNCtlEntry 10 } dsmonMatrixTopNCtlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Bierman Standards Track [Page 90] RFC 3287 DSMON MIB July 2002 DESCRIPTION "The status of this dsmonMatrixTopNCtlEntry. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the dsmonMatrixTopNTable shall be deleted by the agent." ::= { dsmonMatrixTopNCtlEntry 11 } -- -- dsmonMatrix TopN Table -- dsmonMatrixTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF DsmonMatrixTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for those dsmonMatrix entries that have counted the highest number of octets or packets. If the dsmonAggControlLocked object is equal to 'false', then all entries in this table SHALL be deleted, and the agent will not process TopN reports on behalf of any dsmonMatrixTopNCtlEntry. When the dsmonAggControlLocked object is set to 'true', then particular reports SHOULD be restarted from the beginning, on behalf of all active rows in the dsmonMatrixTopNCtlTable. Note that dsmonMatrix entries which did not increment at all during the report interval SHOULD NOT be included in dsmonMatrixTopN reports." ::= { dsmonMatrixObjects 5 } dsmonMatrixTopNEntry OBJECT-TYPE SYNTAX DsmonMatrixTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the dsmonMatrixTopNTable. The dsmonMatrixTopNCtlIndex value in the index identifies the dsmonMatrixTopNCtlEntry on whose behalf this entry was created. Bierman Standards Track [Page 91] RFC 3287 DSMON MIB July 2002 Entries in this table are ordered from 1 to 'N', where lower numbers represent higher values of the rate base object, over the report interval." INDEX { dsmonMatrixTopNCtlIndex, dsmonMatrixTopNIndex } ::= { dsmonMatrixTopNTable 1 } DsmonMatrixTopNEntry ::= SEQUENCE { dsmonMatrixTopNIndex Integer32, dsmonMatrixTopNAggGroup DsmonCounterAggGroupIndex, dsmonMatrixTopNNLIndex Integer32, dsmonMatrixTopNSourceAddress OCTET STRING, dsmonMatrixTopNDestAddress OCTET STRING, dsmonMatrixTopNALIndex Integer32, dsmonMatrixTopNPktRate Gauge32, dsmonMatrixTopNPktRateOvfl Gauge32, dsmonMatrixTopNHCPktRate CounterBasedGauge64, dsmonMatrixTopNRevPktRate Gauge32, dsmonMatrixTopNRevPktRateOvfl Gauge32, dsmonMatrixTopNHCRevPktRate CounterBasedGauge64, dsmonMatrixTopNOctetRate Gauge32, dsmonMatrixTopNOctetRateOvfl Gauge32, dsmonMatrixTopNHCOctetRate CounterBasedGauge64, dsmonMatrixTopNRevOctetRate Gauge32, dsmonMatrixTopNRevOctetRateOvfl Gauge32, dsmonMatrixTopNHCRevOctetRate CounterBasedGauge64 } dsmonMatrixTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the dsmonMatrixTopNTable among those in the same report. This index is between 1 and N, where N is the number of entries in this report." ::= { dsmonMatrixTopNEntry 1 } dsmonMatrixTopNAggGroup OBJECT-TYPE SYNTAX DsmonCounterAggGroupIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The counter aggregation group index value associated with host identified in this entry. This object identifies the dsmonAggGroupEntry with the same dsmonAggControlIndex value as the associated dsmonMatrixCtlAggProfile object and the same dsmonAggGroupIndex value as this object." Bierman Standards Track [Page 92] RFC 3287 DSMON MIB July 2002 ::= { dsmonMatrixTopNEntry 2 } dsmonMatrixTopNNLIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex value which identifies the protocol associated with the dsmonMatrixTopNSourceAddress and dsmonMatrixTopNDestAddress objects in this entry. If the protocolDirEntry associated with the protocolDirLocalIndex with the same value as this object is de-activated or deleted, then the agent MUST delete this dsmonMatrixTopN entry." ::= { dsmonMatrixTopNEntry 3 } dsmonMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The dsmonMatrixSDSourceAddress value for the source network host identified in this entry. The associated dsmonMatrixTopNNLIndex object identifies the network protocol type and the encoding rules for this object." ::= { dsmonMatrixTopNEntry 4 } dsmonMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The dsmonMatrixSDDestAddress value for the destination network host identified in this entry. The associated dsmonMatrixTopNNLIndex object identifies the network protocol type and the encoding rules for this object." ::= { dsmonMatrixTopNEntry 5 } dsmonMatrixTopNALIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex value which identifies the application protocol associated with this entry. If the protocolDirEntry associated with the Bierman Standards Track [Page 93] RFC 3287 DSMON MIB July 2002 protocolDirLocalIndex with the same value as this object is de-activated or deleted, then the agent MUST delete this dsmonMatrixTopN entry." ::= { dsmonMatrixTopNEntry 6 } dsmonMatrixTopNPktRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the dsmonMatrixSDPkts object. If the value of dsmonMatrixTopNCtlRateBase is dsmonMatrixTopNPkts, this variable will be used to sort this report. If the value of the dsmonMatrixTopNCtlRateBase is dsmonMatrixTopNHCPkts or dsmonMatrixTopNHCOctets, then this object will contain the the least significant 32 bits of the associated dsmonMatrixTopNHCPktRate object." ::= { dsmonMatrixTopNEntry 7 } dsmonMatrixTopNPktRateOvfl OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The most significant 32 bits of the associated dsmonMatrixTopNHCPktRate object. If the associated dsmonMatrixTopNCtlRateBase is equal to dsmonMatrixTopNHCPkts or dsmonMatrixTopNHCOctets, then this object will contain the most significant 32 bits of the associated dsmonMatrixTopNHCPktRate object, otherwise this object will contain the value zero. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 8 } dsmonMatrixTopNHCPktRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION Bierman Standards Track [Page 94] RFC 3287 DSMON MIB July 2002 "The number of packets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the dsmonMatrixSDHCPkts object. If the value of dsmonMatrixTopNCtlRateBase is dsmonMatrixTopNHCPkts, this variable will be used to sort this report. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 9 } dsmonMatrixTopNRevPktRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the dsmonMatrixDSPkts object (note that the corresponding dsmonMatrixSDPkts object selected is the one whose source address is equal to dsmonMatrixTopNDestAddress and whose destination address is equal to dsmonMatrixTopNSourceAddress.)" ::= { dsmonMatrixTopNEntry 10 } dsmonMatrixTopNRevPktRateOvfl OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The most significant 32 bits of the associated dsmonMatrixTopNHCRevPktRate object. If the associated dsmonMatrixTopNCtlRateBase is equal to dsmonMatrixTopNHCPkts or dsmonMatrixTopNHCOCtets, then this object will contain the most significant 32 bits of the associated dsmonMatrixTopNHCRevPktRate object, otherwise this object will contain the value zero. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 11 } dsmonMatrixTopNHCRevPktRate OBJECT-TYPE SYNTAX CounterBasedGauge64 Bierman Standards Track [Page 95] RFC 3287 DSMON MIB July 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the dsmonMatrixDSHCPkts object (note that the corresponding dsmonMatrixSDHCPkts object selected is the one whose source address is equal to dsmonMatrixTopNDestAddress and whose destination address is equal to dsmonMatrixTopNSourceAddress.) The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 12 } dsmonMatrixTopNOctetRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the dsmonMatrixSDOctets object. If the value of dsmonMatrixTopNCtlRateBase is dsmonMatrixTopNOctets, this variable will be used to sort this report. If the value of the dsmonMatrixTopNCtlRateBase is dsmonMatrixTopNHCPkts or dsmonMatrixTopNHCOctets, then this object will contain the the least significant 32 bits of the associated dsmonMatrixTopNHCPktRate object." ::= { dsmonMatrixTopNEntry 13 } dsmonMatrixTopNOctetRateOvfl OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The most significant 32 bits of the associated dsmonMatrixTopNHCOctetRate object. If the associated dsmonMatrixTopNCtlRateBase is equal to dsmonMatrixTopNHCPkts or dsmonMatrixTopNHCOctets, then this object will contain the most significant 32 bits of the associated dsmonMatrixTopNHCOctetRate object, otherwise this Bierman Standards Track [Page 96] RFC 3287 DSMON MIB July 2002 object will contain the value zero. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 14 } dsmonMatrixTopNHCOctetRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the dsmonMatrixSDHCOctets object. If the value of dsmonMatrixTopNCtlRateBase is dsmonMatrixTopNHCOctets, this variable will be used to sort this report. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 15 } dsmonMatrixTopNRevOctetRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the dsmonMatrixDSOctets object (note that the corresponding dsmonMatrixSDOctets object selected is the one whose source address is equal to dsmonMatrixTopNDestAddress and whose destination address is equal to dsmonMatrixTopNSourceAddress.)" ::= { dsmonMatrixTopNEntry 16 } dsmonMatrixTopNRevOctetRateOvfl OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The most significant 32 bits of the associated dsmonMatrixTopNHCRevOctetRate object. If the associated dsmonMatrixTopNCtlRateBase is equal to Bierman Standards Track [Page 97] RFC 3287 DSMON MIB July 2002 dsmonMatrixTopNHCPkts or dsmonMatrixTopNHCOCtets, then this object will contain the most significant 32 bits of the associated dsmonMatrixTopNHCRevPktRate object, otherwise this object will contain the value zero. The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 17 } dsmonMatrixTopNHCRevOctetRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the dsmonMatrixDSHCOctets object (note that the corresponding dsmonMatrixSDHCOctets object selected is the one whose source address is equal to dsmonMatrixTopNDestAddress and whose destination address is equal to dsmonMatrixTopNSourceAddress.) The agent MAY choose not to instantiate this object if High Capacity monitoring is not supported." ::= { dsmonMatrixTopNEntry 18 } -- -- Conformance Section -- dsmonCompliances OBJECT IDENTIFIER ::= { dsmonConformance 1 } dsmonGroups OBJECT IDENTIFIER ::= { dsmonConformance 2 } -- -- Compliance for agents that do not support HC or Counter64 -- dsmonCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Differentiated Services Monitoring MIB." MODULE -- this module MANDATORY-GROUPS { dsmonCounterAggControlGroup, dsmonStatsGroup, dsmonCapsGroup Bierman Standards Track [Page 98] RFC 3287 DSMON MIB July 2002 } GROUP dsmonStatsHCGroup DESCRIPTION "The dsmonStatsHCGroup is mandatory for systems which implement High Capacity monitoring." GROUP dsmonPdistGroup DESCRIPTION "The dsmonPdistGroup is mandatory for systems which implement RMON-2 protocolDirTable based protocol distribution monitoring." GROUP dsmonPdistHCGroup DESCRIPTION "The dsmonPdistHCGroup is mandatory for systems which implement RMON-2 protocolDirTable based protocol distribution monitoring on high capacity interfaces." GROUP dsmonHostGroup DESCRIPTION "The dsmonHostGroup is mandatory for systems which implement RMON-2 nlHostTable based network protocol monitoring." GROUP dsmonHostHCGroup DESCRIPTION "The dsmonHostHCGroup is mandatory for systems which implement RMON-2 nlHostTable based network protocol monitoring, on high capacity interfaces." GROUP dsmonMatrixGroup DESCRIPTION "The dsmonMatrixGroup is mandatory for systems which implement RMON-2 alMatrix based application protocol monitoring." GROUP dsmonMatrixHCGroup DESCRIPTION "The dsmonMatrixHCGroup is mandatory for systems which implement RMON-2 alMatrix based application protocol monitoring, on high capacity interfaces." ::= { dsmonCompliances 1 } -- -- Compliance for agents that support HC and Counter64 -- Bierman Standards Track [Page 99] RFC 3287 DSMON MIB July 2002 dsmonHCCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Differentiated Services Monitoring MIB for agents which also support High Capacity monitoring and the Counter64 data type." MODULE -- this module MANDATORY-GROUPS { dsmonCounterAggControlGroup, dsmonStatsGroup, dsmonStatsHCGroup, dsmonCapsGroup } GROUP dsmonPdistGroup DESCRIPTION "The dsmonPdistGroup is mandatory for systems which implement RMON-2 protocolDirTable based protocol distribution monitoring." GROUP dsmonPdistHCGroup DESCRIPTION "The dsmonPdistHCGroup is mandatory for systems which implement RMON-2 protocolDirTable based protocol distribution monitoring." GROUP dsmonHostGroup DESCRIPTION "The dsmonHostGroup is mandatory for systems which implement RMON-2 nlHostTable based network protocol monitoring." GROUP dsmonHostHCGroup DESCRIPTION "The dsmonHostHCGroup is mandatory for systems which implement RMON-2 nlHostTable based network protocol monitoring." GROUP dsmonMatrixGroup DESCRIPTION "The dsmonMatrixGroup is mandatory for systems which implement RMON-2 alMatrix based application protocol monitoring." GROUP dsmonMatrixHCGroup DESCRIPTION "The dsmonMatrixHCGroup is mandatory for systems which implement RMON-2 alMatrix based application protocol Bierman Standards Track [Page 100] RFC 3287 DSMON MIB July 2002 monitoring." ::= { dsmonCompliances 2 } -- -- Compliance for agents that support HC, but not Counter64 -- dsmonHCNoC64Compliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "Describes the requirements for conformance to the Differentiated Services Monitoring MIB for an agent which supports high capacity monitoring, but does not support the Counter64 data type (e.g., only supports the SNMPv1 protocol)." MODULE -- this module MANDATORY-GROUPS { dsmonCounterAggControlGroup, dsmonStatsGroup, dsmonStatsOvflGroup, dsmonCapsGroup } GROUP dsmonStatsHCGroup DESCRIPTION "Implementation of the dsmonStatsHCGroup is not required. High Capacity monitoring." GROUP dsmonPdistGroup DESCRIPTION "The dsmonPdistGroup is mandatory for systems which implement RMON-2 protocolDirTable based protocol distribution monitoring." GROUP dsmonPdistOvflGroup DESCRIPTION "The dsmonPdistGroup is mandatory for systems which implement RMON-2 protocolDirTable based protocol distribution monitoring." GROUP dsmonPdistHCGroup DESCRIPTION "Implementation of the dsmonPdistHCGroup is not required." GROUP dsmonHostGroup DESCRIPTION "The dsmonHostGroup is mandatory for systems which implement Bierman Standards Track [Page 101] RFC 3287 DSMON MIB July 2002 RMON-2 nlHostTable based network protocol monitoring." GROUP dsmonHostOvflGroup DESCRIPTION "The dsmonHostGroup is mandatory for systems which implement RMON-2 nlHostTable based network protocol monitoring." GROUP dsmonHostHCGroup DESCRIPTION "Implementation of the dsmonHostHCGroup is not required." GROUP dsmonMatrixGroup DESCRIPTION "The dsmonMatrixGroup is mandatory for systems which implement RMON-2 alMatrix based application protocol monitoring." GROUP dsmonMatrixOvflGroup DESCRIPTION "The dsmonMatrixGroup is mandatory for systems which implement RMON-2 alMatrix based application protocol monitoring." GROUP dsmonMatrixHCGroup DESCRIPTION "Implementation of the dsmonMatrixHCGroup is not required." ::= { dsmonCompliances 3 } -- Object Groups dsmonCounterAggControlGroup OBJECT-GROUP OBJECTS { dsmonMaxAggGroups, dsmonAggControlLocked, dsmonAggControlChanges, dsmonAggControlLastChangeTime, dsmonAggControlDescr, dsmonAggControlOwner, dsmonAggControlStatus, dsmonAggGroupIndex, dsmonAggGroupDescr, dsmonAggGroupStatus } STATUS current DESCRIPTION Bierman Standards Track [Page 102] RFC 3287 DSMON MIB July 2002 "A collection of objects used to configure and manage counter aggregation groups for DSMON collection purposes." ::= { dsmonGroups 1 } dsmonStatsGroup OBJECT-GROUP OBJECTS { dsmonStatsControlDataSource, dsmonStatsControlAggProfile, dsmonStatsControlDroppedFrames, dsmonStatsControlCreateTime, dsmonStatsControlOwner, dsmonStatsControlStatus, dsmonStatsInPkts, dsmonStatsInOctets, dsmonStatsOutPkts, dsmonStatsOutOctets } STATUS current DESCRIPTION "A collection of objects providing per DSCP statistics." ::= { dsmonGroups 2 } dsmonStatsOvflGroup OBJECT-GROUP OBJECTS { dsmonStatsInOvflPkts, dsmonStatsInOvflOctets, dsmonStatsOutOvflPkts, dsmonStatsOutOvflOctets } STATUS deprecated DESCRIPTION "A collection of objects providing per-DSCP overflow counters for systems with high capacity data sources, but without support for the Counter64 data type." ::= { dsmonGroups 3 } dsmonStatsHCGroup OBJECT-GROUP OBJECTS { dsmonStatsInHCPkts, dsmonStatsInHCOctets, dsmonStatsOutHCPkts, dsmonStatsOutHCOctets } STATUS current DESCRIPTION "A collection of objects providing per DSCP statistics for high capacity data sources." ::= { dsmonGroups 4 } Bierman Standards Track [Page 103] RFC 3287 DSMON MIB July 2002 dsmonPdistGroup OBJECT-GROUP OBJECTS { dsmonPdistCtlDataSource, dsmonPdistCtlAggProfile, dsmonPdistCtlMaxDesiredEntries, dsmonPdistCtlDroppedFrames, dsmonPdistCtlInserts, dsmonPdistCtlDeletes, dsmonPdistCtlCreateTime, dsmonPdistCtlOwner, dsmonPdistCtlStatus, dsmonPdistStatsPkts, dsmonPdistStatsOctets, dsmonPdistStatsCreateTime, dsmonPdistTopNCtlPdistIndex, dsmonPdistTopNCtlRateBase, dsmonPdistTopNCtlTimeRemaining, dsmonPdistTopNCtlGeneratedReprts, dsmonPdistTopNCtlDuration, dsmonPdistTopNCtlRequestedSize, dsmonPdistTopNCtlGrantedSize, dsmonPdistTopNCtlStartTime, dsmonPdistTopNCtlOwner, dsmonPdistTopNCtlStatus, dsmonPdistTopNPDLocalIndex, dsmonPdistTopNAggGroup, dsmonPdistTopNRate } STATUS current DESCRIPTION "A collection of objects providing per protocol DSCP monitoring extensions to the RMON-2 MIB." ::= { dsmonGroups 5 } dsmonPdistOvflGroup OBJECT-GROUP OBJECTS { dsmonPdistStatsOvflPkts, dsmonPdistStatsOvflOctets, dsmonPdistTopNRateOvfl } STATUS deprecated DESCRIPTION "A collection of objects providing per-protocol DSCP overflow counters for systems with high capacity data sources, but without support for the Counter64 data type." ::= { dsmonGroups 6 } dsmonPdistHCGroup OBJECT-GROUP Bierman Standards Track [Page 104] RFC 3287 DSMON MIB July 2002 OBJECTS { dsmonPdistStatsHCPkts, dsmonPdistStatsHCOctets, dsmonPdistTopNHCRate } STATUS current DESCRIPTION "A collection of objects providing per protocol DSCP monitoring extensions to the RMON-2 MIB for High Capacity networks." ::= { dsmonGroups 7 } dsmonHostGroup OBJECT-GROUP OBJECTS { dsmonHostCtlDataSource, dsmonHostCtlAggProfile, dsmonHostCtlMaxDesiredEntries, dsmonHostCtlIPv4PrefixLen, dsmonHostCtlIPv6PrefixLen, dsmonHostCtlDroppedFrames, dsmonHostCtlInserts, dsmonHostCtlDeletes, dsmonHostCtlCreateTime, dsmonHostCtlOwner, dsmonHostCtlStatus, dsmonHostInPkts, dsmonHostInOctets, dsmonHostOutPkts, dsmonHostOutOctets, dsmonHostCreateTime, dsmonHostTopNCtlHostIndex, dsmonHostTopNCtlRateBase, dsmonHostTopNCtlTimeRemaining, dsmonHostTopNCtlGeneratedReports, dsmonHostTopNCtlDuration, dsmonHostTopNCtlRequestedSize, dsmonHostTopNCtlGrantedSize, dsmonHostTopNCtlStartTime, dsmonHostTopNCtlOwner, dsmonHostTopNCtlStatus, dsmonHostTopNPDLocalIndex, dsmonHostTopNAddress, dsmonHostTopNAggGroup, dsmonHostTopNRate } STATUS current DESCRIPTION "A collection of objects providing per Host monitoring Bierman Standards Track [Page 105] RFC 3287 DSMON MIB July 2002 functions." ::= { dsmonGroups 8 } dsmonHostOvflGroup OBJECT-GROUP OBJECTS { dsmonHostInOvflPkts, dsmonHostInOvflOctets, dsmonHostOutOvflPkts, dsmonHostOutOvflOctets, dsmonHostTopNRateOvfl } STATUS deprecated DESCRIPTION "A collection of objects providing per host DSCP overflow counters for systems with high capacity data sources, but without support for the Counter64 data type." ::= { dsmonGroups 9 } dsmonHostHCGroup OBJECT-GROUP OBJECTS { dsmonHostInHCPkts, dsmonHostInHCOctets, dsmonHostOutHCPkts, dsmonHostOutHCOctets, dsmonHostTopNHCRate } STATUS current DESCRIPTION "A collection of objects providing per Host monitoring functions for High Capacity networks." ::= { dsmonGroups 10 } dsmonCapsGroup OBJECT-GROUP OBJECTS { dsmonCapabilities } STATUS current DESCRIPTION "A collection of objects providing an indication of the DSMON monitoring functions supported by the agent." ::= { dsmonGroups 11 } dsmonMatrixGroup OBJECT-GROUP OBJECTS { dsmonMatrixCtlDataSource, dsmonMatrixCtlAggProfile, dsmonMatrixCtlMaxDesiredEntries, dsmonMatrixCtlDroppedFrames, Bierman Standards Track [Page 106] RFC 3287 DSMON MIB July 2002 dsmonMatrixCtlInserts, dsmonMatrixCtlDeletes, dsmonMatrixCtlCreateTime, dsmonMatrixCtlOwner, dsmonMatrixCtlStatus, dsmonMatrixSDPkts, dsmonMatrixSDOctets, dsmonMatrixSDCreateTime, dsmonMatrixDSPkts, dsmonMatrixDSOctets, dsmonMatrixDSCreateTime, dsmonMatrixTopNCtlMatrixIndex, dsmonMatrixTopNCtlRateBase, dsmonMatrixTopNCtlTimeRemaining, dsmonMatrixTopNCtlGeneratedRpts, dsmonMatrixTopNCtlDuration, dsmonMatrixTopNCtlRequestedSize, dsmonMatrixTopNCtlGrantedSize, dsmonMatrixTopNCtlStartTime, dsmonMatrixTopNCtlOwner, dsmonMatrixTopNCtlStatus, dsmonMatrixTopNAggGroup, dsmonMatrixTopNNLIndex, dsmonMatrixTopNSourceAddress, dsmonMatrixTopNDestAddress, dsmonMatrixTopNALIndex, dsmonMatrixTopNPktRate, dsmonMatrixTopNRevPktRate, dsmonMatrixTopNOctetRate, dsmonMatrixTopNRevOctetRate } STATUS current DESCRIPTION "A collection of objects providing per conversation monitoring functions." ::= { dsmonGroups 12 } dsmonMatrixOvflGroup OBJECT-GROUP OBJECTS { dsmonMatrixSDOvflPkts, dsmonMatrixSDOvflOctets, dsmonMatrixDSOvflPkts, dsmonMatrixDSOvflOctets, dsmonMatrixTopNPktRateOvfl, dsmonMatrixTopNRevPktRateOvfl, dsmonMatrixTopNOctetRateOvfl, dsmonMatrixTopNRevOctetRateOvfl } Bierman Standards Track [Page 107] RFC 3287 DSMON MIB July 2002 STATUS deprecated DESCRIPTION "A collection of objects providing per conversation monitoring functions for systems with high capacity data sources, but without support for the Counter64 data type." ::= { dsmonGroups 13 } dsmonMatrixHCGroup OBJECT-GROUP OBJECTS { dsmonMatrixSDHCPkts, dsmonMatrixSDHCOctets, dsmonMatrixDSHCPkts, dsmonMatrixDSHCOctets, dsmonMatrixTopNHCPktRate, dsmonMatrixTopNHCRevPktRate, dsmonMatrixTopNHCOctetRate, dsmonMatrixTopNHCRevOctetRate } STATUS current DESCRIPTION "A collection of objects providing per conversation monitoring functions for High Capacity networks." ::= { dsmonGroups 14 } END 5. Counter Aggregation Configuration Usage Examples This section contains an example of the steps that may be followed by a management station to configure the objects in the dsmonCounterAggControlGroup. A note about these examples: - they do not define a standard - an agent is not obligated to support them - a management application is not constrained by them - the SET(object = value [, ...]) notation is only conceptual, and is not meant to represent an actual SNMP Set PDU. Bierman Standards Track [Page 108] RFC 3287 DSMON MIB July 2002 5.1. Step 1: Unlock the Counter Aggregation Configuration Before any write operations to the tabular objects in this group can be made, the counter aggregation configuration must be unlocked by setting the dsmonAggControlLocked scalar to false: SET(dsmonAggControlLocked.0 = false(2)); 5.2. Step 2: Check the Maximum number of Counter Aggregation Groups Make sure the desired counter aggregation groups have a chance of being configured on the agent. maxGroups = GET(dsmonAggMaxAggGroups.0); For this example, maxGroups is greater or equal to 64. 5.3. Step 3: Check if the counter aggregation profiles already exist Make sure the desired counter aggregation profiles have not already been configured, or perhaps recreated after an agent restart. The following example is oversimplified, in that the entire counter aggregation configuration should actually be verified. profile1Descr = GET(dsmonAggControlDescr.1); profile1Owner = GET(dsmonAggControlOwner.1); profile1Status = GET(dsmonAggControlStatus.1); For this example, none of the counter aggregation profiles already exist. 5.4. Step 4: Create the Counter Aggregation Control Entries The management station should create one entry in the dsmonAggControlTable for each counter aggregation profile to be configured on the agent. Steps 4, 5, and 6 are repeated for each counter aggregation profile to be configured on the agent. There are 3 example counter aggregation profiles shown in each of these steps. Example 1: Each DSCP in its own counter aggregation group. SET(dsmonAggControlStatus.1 = createAndGo(4), dsmonAggControlOwner.1 = "Example App 1", dsmonAggControlDescr.1 = "1 DSCP Per Group"); Bierman Standards Track [Page 109] RFC 3287 DSMON MIB July 2002 Example 2: a collection of DIFFSERV PHBs. SET(dsmonAggControlStatus.2 = createAndGo(4), dsmonAggControlOwner.2 = "Example App 2", dsmonAggControlDescr.2 = "June 2000 DIFFSERV PHBs"); Example 3: an aggregated collection of DIFFSERV PHBs. SET(dsmonAggControlStatus.3 = createAndGo(4), dsmonAggControlOwner.3 = "Example App 3", dsmonAggControlDescr.3 = "Limited June 2000 PHBs"); 5.5. Step 5: Create the Counter Aggregation Group Descriptions Example 1: Each DSCP in its own counter aggregation group. One group is created for each codepoint, for a total of 64 rows. SET(dsmonAggGroupStatus.1.0 = createAndGo(4), dsmonAggGroupDescr.1.0 = "DSCP 0"); SET(dsmonAggGroupStatus.1.1 = createAndGo(4), dsmonAggGroupDescr.1.1 = "DSCP 1"); SET(dsmonAggGroupStatus.1.2 = createAndGo(4), dsmonAggGroupDescr.1.2 = "DSCP 2"); SET(dsmonAggGroupStatus.1.3 = createAndGo(4), dsmonAggGroupDescr.1.3 = "DSCP 3"); ... SET(dsmonAggGroupStatus.1.63 = createAndGo(4), dsmonAggGroupDescr.1.63 = "DSCP 63"); Bierman Standards Track [Page 110] RFC 3287 DSMON MIB July 2002 Example 2: a collection of current DIFFSERV PHBs. One group is created for each PHB to be monitored. SET(dsmonAggGroupStatus.2.0 = createAndGo(4), dsmonAggGroupDescr.2.0 = "CS0"); SET(dsmonAggGroupStatus.2.1 = createAndGo(4), dsmonAggGroupDescr.2.1 = "CS1"); SET(dsmonAggGroupStatus.2.2 = createAndGo(4), dsmonAggGroupDescr.2.2 = "CS2"); SET(dsmonAggGroupStatus.2.3 = createAndGo(4), dsmonAggGroupDescr.2.3 = "CS3"); SET(dsmonAggGroupStatus.2.4 = createAndGo(4), dsmonAggGroupDescr.2.4 = "CS4"); SET(dsmonAggGroupStatus.2.5 = createAndGo(4), dsmonAggGroupDescr.2.5 = "CS5"); SET(dsmonAggGroupStatus.2.6 = createAndGo(4), dsmonAggGroupDescr.2.6 = "CS6"); SET(dsmonAggGroupStatus.2.7 = createAndGo(4), dsmonAggGroupDescr.2.7 = "CS7"); SET(dsmonAggGroupStatus.2.8 = createAndGo(4), dsmonAggGroupDescr.2.8 = "EF"); SET(dsmonAggGroupStatus.2.9 = createAndGo(4), dsmonAggGroupDescr.2.9 = "AF11"); SET(dsmonAggGroupStatus.2.10 = createAndGo(4), dsmonAggGroupDescr.2.10 = "AF12"); SET(dsmonAggGroupStatus.2.11 = createAndGo(4), dsmonAggGroupDescr.2.11 = "AF13"); SET(dsmonAggGroupStatus.2.12 = createAndGo(4), dsmonAggGroupDescr.2.12 = "AF21"); SET(dsmonAggGroupStatus.2.13 = createAndGo(4), dsmonAggGroupDescr.2.13 = "AF22"); SET(dsmonAggGroupStatus.2.14 = createAndGo(4), dsmonAggGroupDescr.2.14 = "AF23"); SET(dsmonAggGroupStatus.2.15 = createAndGo(4), dsmonAggGroupDescr.2.15 = "AF31"); SET(dsmonAggGroupStatus.2.16 = createAndGo(4), dsmonAggGroupDescr.2.16 = "AF32"); SET(dsmonAggGroupStatus.2.17 = createAndGo(4), dsmonAggGroupDescr.2.17 = "AF33"); SET(dsmonAggGroupStatus.2.18 = createAndGo(4), dsmonAggGroupDescr.2.18 = "AF41"); SET(dsmonAggGroupStatus.2.19 = createAndGo(4), dsmonAggGroupDescr.2.19 = "AF42"); SET(dsmonAggGroupStatus.2.20 = createAndGo(4), dsmonAggGroupDescr.2.20 = "AF43"); SET(dsmonAggGroupStatus.2.21 = createAndGo(4), dsmonAggGroupDescr.2.21 = "Nonzero Default"); Bierman Standards Track [Page 111] RFC 3287 DSMON MIB July 2002 Example 3: an aggregated representation of current DIFFSERV PHBs. One group is created for each counter aggregation to be monitored (8 rows in this example). SET(dsmonAggGroupStatus.3.0 = createAndGo(4), dsmonAggGroupDescr.3.0 = "Zero CS"); SET(dsmonAggGroupStatus.3.1 = createAndGo(4), dsmonAggGroupDescr.3.1 = "Nonzero CS"); SET(dsmonAggGroupStatus.3.2 = createAndGo(4), dsmonAggGroupDescr.3.2 = "EF"); SET(dsmonAggGroupStatus.3.3 = createAndGo(4), dsmonAggGroupDescr.3.3 = "AF1"); SET(dsmonAggGroupStatus.3.4 = createAndGo(4), dsmonAggGroupDescr.3.4 = "AF2"); SET(dsmonAggGroupStatus.3.5 = createAndGo(4), dsmonAggGroupDescr.3.5 = "AF3"); SET(dsmonAggGroupStatus.3.6 = createAndGo(4), dsmonAggGroupDescr.3.6 = "AF4"); SET(dsmonAggGroupStatus.3.7 = createAndGo(4), dsmonAggGroupDescr.3.7 = "Nonzero Default"); 5.6. Step 6: Create the Counter Aggregation Profile Mappings After the dsmonAggControlEntries are activated, the associated read- write dsmonAggProfileEntries will be created. The management station must create 64 entries in the dsmonAggProfileTable for each counter aggregation profile configured in the dsmonAggControlTable. Example 1: Each DSCP in its own counter aggregation group SET(dsmonAggGroupIndex.1.0 = 0, dsmonAggGroupIndex.1.1 = 1, dsmonAggGroupIndex.1.2 = 2, dsmonAggGroupIndex.1.3 = 3, ... dsmonAggGroupIndex.1.63 = 63); Example 2: a collection of current DIFFSERV PHBs. SET(dsmonAggGroupIndex.2.0 = 0, -- CS0 dsmonAggGroupIndex.2.1 = 21, -- Nonzero Default dsmonAggGroupIndex.2.2 = 21, dsmonAggGroupIndex.2.3 = 21, dsmonAggGroupIndex.2.4 = 21, dsmonAggGroupIndex.2.5 = 21, dsmonAggGroupIndex.2.6 = 21, dsmonAggGroupIndex.2.7 = 21, dsmonAggGroupIndex.2.8 = 1, -- CS1 Bierman Standards Track [Page 112] RFC 3287 DSMON MIB July 2002 dsmonAggGroupIndex.2.9 = 21, dsmonAggGroupIndex.2.10 = 9, -- AF11 dsmonAggGroupIndex.2.11 = 21, dsmonAggGroupIndex.2.12 = 10, -- AF12 dsmonAggGroupIndex.2.13 = 21, dsmonAggGroupIndex.2.14 = 11, -- AF13 dsmonAggGroupIndex.2.15 = 21, dsmonAggGroupIndex.2.16 = 2, -- CS2 dsmonAggGroupIndex.2.17 = 21, dsmonAggGroupIndex.2.18 = 12, -- AF21 dsmonAggGroupIndex.2.19 = 21, dsmonAggGroupIndex.2.20 = 13, -- AF22 dsmonAggGroupIndex.2.21 = 21, dsmonAggGroupIndex.2.22 = 14, -- AF23 dsmonAggGroupIndex.2.23 = 21, dsmonAggGroupIndex.2.24 = 3, -- CS3 dsmonAggGroupIndex.2.25 = 21, dsmonAggGroupIndex.2.26 = 15, -- AF31 dsmonAggGroupIndex.2.27 = 21, dsmonAggGroupIndex.2.28 = 16, -- AF32 dsmonAggGroupIndex.2.29 = 8, -- EF dsmonAggGroupIndex.2.30 = 17, -- AF33 dsmonAggGroupIndex.2.31 = 21, dsmonAggGroupIndex.2.32 = 4, -- CS4 dsmonAggGroupIndex.2.33 = 21, dsmonAggGroupIndex.2.34 = 18, -- AF41 dsmonAggGroupIndex.2.35 = 21, dsmonAggGroupIndex.2.36 = 19, -- AF42 dsmonAggGroupIndex.2.37 = 21, dsmonAggGroupIndex.2.38 = 20, -- AF43 dsmonAggGroupIndex.2.39 = 21, dsmonAggGroupIndex.2.40 = 5, -- CS5 dsmonAggGroupIndex.2.41 = 21, dsmonAggGroupIndex.2.42 = 21, dsmonAggGroupIndex.2.43 = 21, dsmonAggGroupIndex.2.44 = 21, dsmonAggGroupIndex.2.45 = 21, dsmonAggGroupIndex.2.46 = 21, dsmonAggGroupIndex.2.47 = 21, dsmonAggGroupIndex.2.48 = 6, -- CS6 dsmonAggGroupIndex.2.49 = 21, dsmonAggGroupIndex.2.50 = 21, dsmonAggGroupIndex.2.51 = 21, dsmonAggGroupIndex.2.52 = 21, dsmonAggGroupIndex.2.53 = 21, dsmonAggGroupIndex.2.54 = 21, dsmonAggGroupIndex.2.55 = 21, dsmonAggGroupIndex.2.56 = 7, -- CS7 Bierman Standards Track [Page 113] RFC 3287 DSMON MIB July 2002 dsmonAggGroupIndex.2.57 = 21, dsmonAggGroupIndex.2.58 = 21, dsmonAggGroupIndex.2.59 = 21, dsmonAggGroupIndex.2.60 = 21, dsmonAggGroupIndex.2.61 = 21, dsmonAggGroupIndex.2.62 = 21, dsmonAggGroupIndex.2.63 = 21); Example 3: an aggregated collection of current DIFFSERV PHBs. SET(dsmonAggGroupIndex.3.0 = 0, -- Zero CS dsmonAggGroupIndex.3.1 = 7, -- Nonzero Default dsmonAggGroupIndex.3.2 = 7, dsmonAggGroupIndex.3.3 = 7, dsmonAggGroupIndex.3.4 = 7, dsmonAggGroupIndex.3.5 = 7, dsmonAggGroupIndex.3.6 = 7, dsmonAggGroupIndex.3.7 = 7, dsmonAggGroupIndex.3.8 = 1, -- Nonzero CS dsmonAggGroupIndex.3.9 = 7, dsmonAggGroupIndex.3.10 = 3, -- AF1 dsmonAggGroupIndex.3.11 = 7, dsmonAggGroupIndex.3.12 = 3, dsmonAggGroupIndex.3.13 = 7, dsmonAggGroupIndex.3.14 = 3, dsmonAggGroupIndex.3.15 = 7, dsmonAggGroupIndex.3.16 = 1, dsmonAggGroupIndex.3.17 = 7, dsmonAggGroupIndex.3.18 = 4, -- AF2 dsmonAggGroupIndex.3.19 = 7, dsmonAggGroupIndex.3.20 = 4, dsmonAggGroupIndex.3.21 = 7, dsmonAggGroupIndex.3.22 = 4, dsmonAggGroupIndex.3.23 = 7, dsmonAggGroupIndex.3.24 = 1, dsmonAggGroupIndex.3.25 = 7, dsmonAggGroupIndex.3.26 = 5, -- AF3 dsmonAggGroupIndex.3.27 = 7, dsmonAggGroupIndex.3.28 = 5, dsmonAggGroupIndex.3.29 = 2, -- EF dsmonAggGroupIndex.3.30 = 5, dsmonAggGroupIndex.3.31 = 7, dsmonAggGroupIndex.3.32 = 1, dsmonAggGroupIndex.3.33 = 7, dsmonAggGroupIndex.3.34 = 6, -- AF4 dsmonAggGroupIndex.3.35 = 7, dsmonAggGroupIndex.3.36 = 6, dsmonAggGroupIndex.3.37 = 7, Bierman Standards Track [Page 114] RFC 3287 DSMON MIB July 2002 dsmonAggGroupIndex.3.38 = 6, dsmonAggGroupIndex.3.39 = 7, dsmonAggGroupIndex.3.40 = 1, dsmonAggGroupIndex.3.41 = 7, dsmonAggGroupIndex.3.42 = 7, dsmonAggGroupIndex.3.43 = 7, dsmonAggGroupIndex.3.44 = 7, dsmonAggGroupIndex.3.45 = 7, dsmonAggGroupIndex.3.46 = 7, dsmonAggGroupIndex.3.47 = 7, dsmonAggGroupIndex.3.48 = 1, dsmonAggGroupIndex.3.49 = 7, dsmonAggGroupIndex.3.50 = 7, dsmonAggGroupIndex.3.51 = 7, dsmonAggGroupIndex.3.52 = 7, dsmonAggGroupIndex.3.53 = 7, dsmonAggGroupIndex.3.54 = 7, dsmonAggGroupIndex.3.55 = 7, dsmonAggGroupIndex.3.56 = 1, dsmonAggGroupIndex.3.57 = 7, dsmonAggGroupIndex.3.58 = 7, dsmonAggGroupIndex.3.59 = 7, dsmonAggGroupIndex.3.60 = 7, dsmonAggGroupIndex.3.61 = 7, dsmonAggGroupIndex.3.62 = 7, dsmonAggGroupIndex.3.63 = 7); 5.7. Step 7: Lock the Counter Aggregation Configuration Before any existing collections can be activated by the agent, the counter aggregation configuration must be locked, by setting the dsmonAggControlLocked scalar to 'true'. SET(dsmonAggControlLocked.0 = true(1)); 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11, RFC 2028. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of Bierman Standards Track [Page 115] RFC 3287 DSMON MIB July 2002 such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgements This memo is a product of the RMONMIB WG. It is based on an Internet Draft that was produced with a great deal of assistance from Keith McCloghrie and Bijendra Jain. 8. References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1905] 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] 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. [RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Bierman Standards Track [Page 116] RFC 3287 DSMON MIB July 2002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2571] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D.and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. Bierman Standards Track [Page 117] RFC 3287 DSMON MIB July 2002 [RFC2895] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifier Reference", RFC 2895, August 2000. [RFC3273] Waldbusser, S., "Remote Monitoring Management Information Base for High Capacity Networks", RFC 3273, May 2002. 9. Security Considerations In order to implement this MIB, a probe must capture all packets on the locally-attached network, including packets between third parties. These packets are analyzed to collect network addresses, protocol usage information, and conversation statistics. Data of this nature may be considered sensitive in some environments. In such environments the administrator may wish to restrict SNMP access to the probe. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Bierman Standards Track [Page 118] RFC 3287 DSMON MIB July 2002 10. Author's Address Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-3711 EMail: abierman@cisco.com Bierman Standards Track [Page 119] RFC 3287 DSMON MIB July 2002 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bierman Standards Track [Page 120] snmp-mibs-downloader-1.1/mibrfcs/rfc3289.txt0000644000000000000000000072270111402176071015600 0ustar Network Working Group F. Baker Request for Comments: 3289 Cisco System Category: Standards Track K. Chan Nortel Networks A. Smith Harbour Networks May 2002 Management Information Base for the Differentiated Services Architecture 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. Table of Contents 1 The SNMP Management Framework ................................. 3 2 Relationship to other working group documents ................. 4 2.1 Relationship to the Informal Management Model for Differentiated Services Router ............................. 4 2.2 Relationship to other MIBs and Policy Management ............ 5 3 MIB Overview .................................................. 6 3.1 Processing Path ............................................. 7 3.1.1 diffServDataPathTable - The Data Path Table ............... 7 3.2 Classifier .................................................. 7 3.2.1 diffServClfrElementTable - The Classifier Element Table ... 8 3.2.2 diffServMultiFieldClfrTable - The Multi-field Classifier Table ...................................................... 9 3.3 Metering Traffic ............................................ 10 3.3.1 diffServMeterTable - The Meter Table ...................... 11 Baker, et. al. Standards Track [Page 1] RFC 3289 Differentiated Services MIB May 2002 3.3.2 diffServTBParamTable - The Token Bucket Parameters Table... 11 3.4 Actions applied to packets .................................. 12 3.4.1 diffServActionTable - The Action Table .................... 12 3.4.2 diffServCountActTable - The Count Action Table ............ 12 3.4.3 diffServDscpMarkActTable - The Mark Action Table .......... 13 3.4.4 diffServAlgDropTable - The Algorithmic Drop Table ......... 13 3.4.5 diffServRandomDropTable - The Random Drop Parameters Table 14 3.5 Queuing and Scheduling of Packets ........................... 16 3.5.1 diffServQTable - The Class or Queue Table ................. 16 3.5.2 diffServSchedulerTable - The Scheduler Table .............. 16 3.5.3 diffServMinRateTable - The Minimum Rate Table ............. 16 3.5.4 diffServMaxRateTable - The Maximum Rate Table ............. 17 3.5.5 Using queues and schedulers together ...................... 17 3.6 Example configuration for AF and EF ......................... 20 3.6.1 AF and EF Ingress Interface Configuration ................. 20 3.6.1.1 Classification In The Example ........................... 22 3.6.1.2 AF Implementation On an Ingress Edge Interface .......... 22 3.6.1.2.1 AF Metering On an Ingress Edge Interface .............. 22 3.6.1.2.2 AF Actions On an Ingress Edge Interface ............... 23 3.6.1.3 EF Implementation On an Ingress Edge Interface .......... 23 3.6.1.3.1 EF Metering On an Ingress Edge Interface .............. 23 3.6.1.3.2 EF Actions On an Ingress Edge Interface ............... 23 3.7 AF and EF Egress Edge Interface Configuration ............... 24 3.7.1 Classification On an Egress Edge Interface ................ 24 3.7.2 AF Implementation On an Egress Edge Interface ............. 26 3.7.2.1 AF Metering On an Egress Edge Interface ................. 26 3.7.2.2 AF Actions On an Egress Edge Interface .................. 29 3.7.2.3 AF Rate-based Queuing On an Egress Edge Interface ....... 30 3.7.3 EF Implementation On an Egress Edge Interface ............. 30 3.7.3.1 EF Metering On an Egress Edge Interface ................. 30 3.7.3.2 EF Actions On an Egress Edge Interface .................. 30 3.7.3.3 EF Priority Queuing On an Egress Edge Interface ......... 32 4 Conventions used in this MIB .................................. 33 4.1 The use of RowPointer to indicate data path linkage ......... 33 4.2 The use of RowPointer to indicate parameters ................ 34 4.3 Conceptual row creation and deletion ........................ 34 5 Extending this MIB ............................................ 35 6 MIB Definition ................................................ 35 7 Acknowledgments ............................................... 110 8 Security Considerations ....................................... 110 9 Intellectual Property Rights .................................. 111 10 References ................................................... 112 11 Authors' Addresses ........................................... 115 12 Full Copyright Statement ..................................... 116 Baker, et. al. Standards Track [Page 2] RFC 3289 Differentiated Services MIB May 2002 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in [RFC 2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in [RFC 1155], [RFC 1212] and [RFC 1215]. The second version, called SMIv2, is described in [RFC 2578], RFC 2579 [RFC 2579] and [RFC 2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in [RFC 1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in [RFC 1901] and [RFC 1906]. The third version of the message protocol is called SNMPv3 and is described in [RFC 1906], [RFC 2572] and [RFC 2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in [RFC 1157]. A second set of protocol operations and associated PDU formats is described in [RFC 1905]. o A set of fundamental applications described in [RFC 2573] and the view-based access control mechanism described in [RFC 2575]. A more detailed introduction to the current SNMP Management Framework can be found in [RFC 2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because there is no translation is possible (use of Counter64). Some machine- readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Baker, et. al. Standards Track [Page 3] RFC 3289 Differentiated Services MIB May 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Relationship to other working group documents The Differentiated Services Working Group and related working groups developed other documents, notably the Informal Management Model and the policy configuration paradigm of SNMPCONF. The relationship between the MIB and those documents is clarified here. 2.1. Relationship to the Informal Management Model for Differentiated Services Router This MIB is similar in design to [MODEL], although it can be used to build functional data paths that the model would not well describe. The model conceptually describes ingress and egress interfaces of an n-port router, which may find some interfaces at a network edge and others facing into the network core. It describes the configuration and management of a Differentiated Services interface in terms of one or more Traffic Conditioning Blocks (TCB), each containing, arranged in the specified order, by definition, zero or more classifiers, meters, actions, algorithmic droppers, queues and schedulers. Traffic may be classified, and classified traffic may be metered. Each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it; it may have dropping algorithms applied and it may ultimately be stored into a queue before being scheduled out to its next destination, either onto a link or to another TCB. At times, the treatment for a given packet must have any of those elements repeated. [MODEL] models this by cascading multiple TCBs, while this MIB describes the policy by directly linking the functional data path elements. The MIB represents this cascade by following the "Next" attributes of the various elements. They indicate what the next step in Differentiated Services processing will be, whether it be a classifier, meter, action, algorithmic dropper, queue, scheduler or a decision to now forward a packet. The higher level concept of a TCB is not required in the parameterization or in the linking together of the individual elements, hence it is not used in the MIB itself and is only mentioned in the text for relating the MIB with the [MODEL]. Rather, the MIB models the individual elements that make up the TCBs. This MIB uses the notion of a Data Path to indicate the Differentiated Services processing a packet may experience. The Data Path a packet will initially follow is an attribute of the interface Baker, et. al. Standards Track [Page 4] RFC 3289 Differentiated Services MIB May 2002 in question. The Data Path Table provides a starting point for each direction (ingress or egress) on each interface. A Data Path Table Entry indicates the first of possible multiple elements that will apply Differentiated Services treatment to the packet. 2.2. Relationship to other MIBs and Policy Management This MIB provides for direct reporting and manipulation of detailed functional elements. These elements consist of a structural element and one or more parameter-bearing elements. While this can be cumbersome, it allows the reuse of parameters. For example, a service provider may offer three varieties of contracts, and configure three parameter elements. Each such data path on the system may then refer to these sets of parameters. The diffServDataPathTable couples each direction on each interface with the specified data path linkage. The concept of "interface" is as defined by InterfaceIndex/ifIndex of the IETF Interfaces MIB [IF- MIB]. Other MIBs and data structure definitions for policy management mechanisms, other than SNMP/SMIv2 are likely to exist in the future for the purpose of abstracting the model in other ways. An example is the Differentiated Services Policy Information Base, [DSPIB]. In particular, abstractions in the direction of less detailed definitions of Differentiated Services functionality are likely e.g. some form of "Per-Hop Behavior"-based definition involving a template of detailed object values which is applied to specific instances of objects in this MIB semi-automatically. Another possible direction of abstraction is one using a concept of "roles" (often, but not always, applied to interfaces). In this case, it may be possible to re-use the object definitions in this MIB, especially the parameterization tables. The Data Path table will help in the reuse of the data path linkage tables by having the interface specific information centralized, allowing easier mechanical replacement of ifIndex by some sort of "roleIndex". This work is ongoing. The reuse of parameter blocks on a variety of functional data paths is intended to simplify network management. In many cases, one could also re-use the structural elements as well; this has the unfortunate side-effect of re-using the counters, so that monitoring information is lost. For this reason, the re-use of structural elements is not generally recommended. Baker, et. al. Standards Track [Page 5] RFC 3289 Differentiated Services MIB May 2002 3. MIB Overview The Differentiated Services Architecture does not specify how an implementation should be assembled. The [MODEL] describes a general approach to implementation design, or to user interface design. Its components could, however, be assembled in a different way. For example, traffic conforming to a meter might be run through a second meter, or reclassified. This MIB models the same functional data path elements, allowing the network manager to assemble them in any fashion that meets the relevant policy. These data path elements include Classifiers, Meters, Actions of various sorts, Queues, and Schedulers. In many of these tables, a distinction is drawn between the structure of the policy (do this, then do that) and the parameters applied to specific policy elements. This is to facilitate configuration, if the MIB is used for that. The concept is that a set of parameters, such as the values that describe a specific token bucket, might be configured once and applied to many interfaces. The RowPointer Textual Convention is therefore used in two ways in this MIB. It is defined for the purpose of connecting an object to an entry dynamically; the RowPointer object identifies the first object in the target Entry, and in so doing points to the entire entry. In this MIB, it is used as a connector between successive functional data path elements, and as the link between the policy structure and the parameters that are used. When used as a connector, it says what happens "next"; what happens to classified traffic, to traffic conforming or not conforming to a meter, and so on. When used to indicate the parameters applied in a policy, it says "specifically" what is meant; the structure points to the parameters of its policy. The use of RowPointers as connectors allows for the simple extension of the MIB. The RowPointers, whether "next" or "specific", may point to Entries defined in other MIB modules. For example, the only type of meter defined in this MIB is a token bucket meter; if another type of meter is required, another MIB could be defined describing that type of meter, and diffServMeterSpecific could point to it. Similarly, if a new action is required, the "next" pointer of the previous functional datapath element could point to an Entry defined in another MIB, public or proprietary. Baker, et. al. Standards Track [Page 6] RFC 3289 Differentiated Services MIB May 2002 3.1. Processing Path An interface has an ingress and an egress direction, and will generally have a different policy in each direction. As traffic enters an edge interface, it may be classified, metered, counted, and marked. Traffic leaving the same interface might be remarked according to the contract with the next network, queued to manage the bandwidth, and so on. As [MODEL] points out, the functional datapath elements used on ingress and egress are of the same type, but may be structured in very different ways to implement the relevant policies. 3.1.1. diffServDataPathTable - The Data Path Table Therefore, when traffic arrives at an ingress or egress interface, the first step in applying the policy is determining what policy applies. This MIB does that by providing a table of pointers to the first functional data path element, indexed by interface and direction on that interface. The content of the diffServDataPathEntry is a single RowPointer, which points to that functional data path element. When diffServDataPathStart in a direction on an interface is undefined or is set to zeroDotZero, the implication is that there is no specific policy to apply. 3.2. Classifier Classifiers are used to differentiate among types of traffic. In the Differentiated Services architecture, one usually discusses a behavior aggregate identified by the application of one or more Differentiated Services Code Points (DSCPs). However, especially at network edges (which include hosts and first hop routers serving hosts), traffic may arrive unmarked or the marks may not be trusted. In these cases, one applies a Multi-Field Classifier, which may select an aggregate as coarse as "all traffic", as fine as a specific microflow identified by IP Addresses, IP Protocol, and TCP or UDP ports, or variety of slices in between. Classifiers can be simple or complex. In a core interface, one would expect to find simple behavior aggregate classification to be used. However, in an edge interface, one might first ask what application is being used, meter the arriving traffic, and then apply various policies to the non-conforming traffic depending on the Autonomous System number advertising the destination address. To accomplish such a thing, traffic must be classified, metered, and then reclassified. To this end, the MIB defines separate classifiers, which may be applied at any point in processing, and may have different content as needed. Baker, et. al. Standards Track [Page 7] RFC 3289 Differentiated Services MIB May 2002 The MIB also allows for ambiguous classification in a structured fashion. In the end, traffic classification must be unambiguous; one must know for certain what policy to apply to any given packet. However, writing an unambiguous specification is often tedious, while writing a specification in steps that permits and excludes various kinds of traffic may be simpler and more intuitive. In such a case, the classification "steps" are enumerated; all classification elements of one precedence are applied as if in parallel, and then all classification elements of the next precedence. This MIB defines a single classifier parameter entry, the Multi-field Classifier. A degenerate case of this multi-field classifier is a Behavior Aggregate classifier. Other classifiers may be defined in other MIB modules, to select traffic from a given layer two neighbor or a given interface, traffic whose addresses belong to a given BGP Community or Autonomous System, and so on. 3.2.1. diffServClfrElementTable - The Classifier Element Table A classifier consists of classifier elements. A classifier element identifies a specific set of traffic that forms part of a behavior aggregate; other classifier elements within the same classifier may identify other traffic that also falls into the behavior aggregate. For example, in identifying AF traffic for the aggregate AF1, one might implement separate classifier elements for AF11, AF12, and AF13 within the same classifier and pointing to the same subsequent meter. Generally, one would expect the Data Path Entry to point to a classifier (which is to say, a set of one or more classifier elements), although it may point to something else when appropriate. Reclassification in a functional data path is achieved by pointing to another Classifier Entry when appropriate. A classifier element is a structural element, indexed by classifier ID and element ID. It has a precedence value, allowing for structured ambiguity as described above, a "specific" pointer that identifies what rule is to be applied, and a "next" pointer directing traffic matching the classifier to the next functional data path element. If the "next" pointer is zeroDotZero, the indication is that there is no further differentiated services processing for this behavior aggregate. However, if the "specific" pointer is zeroDotZero, the device is misconfigured. In such a case, the classifier element should be operationally treated as if it were not present. When the MIB is used for configuration, diffServClfrNextFree and diffServClfrElementNextFree always contain legal values for diffServClfrId and diffServClfrElementId that are not currently used Baker, et. al. Standards Track [Page 8] RFC 3289 Differentiated Services MIB May 2002 in the system's configuration. The values are validated when creating diffServClfrId and diffServClfrElementId, and in the event of a failure (which would happen if two managers simultaneously attempted to create an entry) must be re-read. 3.2.2. diffServMultiFieldClfrTable - The Multi-field Classifier Table This MIB defines a single parameter type for classification, the Multi-field Classifier. As a parameter, a filter may be specified once and applied to many interfaces, using diffServClfrElementSpecific. This filter matches: o IP source address prefix, including host, CIDR Prefix, and "any source address" o IP destination address prefix, including host, CIDR Prefix, and "any destination address" o IPv6 Flow ID o IP protocol or "any" o TCP/UDP/SCTP source port range, including "any" o TCP/UDP/SCTP destination port range, including "any" o Differentiated Services Code Point Since port ranges, IP prefixes, or "any" are defined in each case, it is clear that a wide variety of filters can be constructed. The Differentiated Services Behavior Aggregate filter is a special case of this filter, in which only the DSCP is specified. Other MIB modules may define similar filters in the same way. For example, a filter for Ethernet information might define source and destination MAC addresses of "any", Ethernet Packet Type, IEEE 802.2 SAPs, and IEEE 802.1 priorities. A filter related to policy routing might be structured like the diffServMultiFieldClfrTable, but contain the BGP Communities of the source and destination prefix rather than the prefix itself, meaning "any prefix in this community". For such a filter, a table similar to diffServMultiFieldClfrTable is constructed, and diffServClfrElementSpecific is configured to point to it. Baker, et. al. Standards Track [Page 9] RFC 3289 Differentiated Services MIB May 2002 When the MIB is used for configuration, diffServMultiFieldClfrNextFree always contains a legal value for diffServMultiFieldClfrId that is not currently used in the system's configuration. 3.3. Metering Traffic As discussed in [MODEL], a meter and a shaper are functions that operate on opposing ends of a link. A shaper schedules traffic for transmission at specific times in order to approximate a particular line speed or combination of line speeds. In its simplest form, if the traffic stream contains constant sized packets, it might transmit one packet per unit time to build the equivalent of a CBR circuit. However, various factors intervene to make the approximation inexact; multiple classes of traffic may occasionally schedule their traffic at the same time, the variable length nature of IP traffic may introduce variation, and factors in the link or physical layer may change traffic timing. A meter integrates the arrival rate of traffic and determines whether the shaper at the far end was correctly applied, or whether the behavior of the application in question is naturally close enough to such behavior to be acceptable under a given policy. A common type of meter is a Token Bucket meter, such as [srTCM] or [trTCM]. This type of meter assumes the use of a shaper at a previous node; applications which send at a constant rate when sending may conform if the token bucket is properly specified. It specifies the acceptable arrival rate and quantifies the acceptable variability, often by specifying a burst size or an interval; since rate = quantity/time, specifying any two of those parameters implies the third, and a large interval provides for a forgiving system. Multiple rates may be specified, as in AF, such that a subset of the traffic (up to one rate) is accepted with one set of guarantees, and traffic in excess of that but below another rate has a different set of guarantees. Other types of meters exist as well. One use of a meter is when a service provider sells at most, a certain bit rate to one of its customers, and wants to drop the excess. In such a case, the fractal nature of normal Internet traffic must be reflected in large burst intervals, as TCP frequently sends packet pairs or larger bursts, and responds poorly when more than one packet in a round trip interval is dropped. Applications like FTP contain the effect by simply staying below the target bit rate; this type of configuration very adversely affects transaction applications like HTTP, however. Another use of a meter is in the AF specification, in which excess traffic is marked with a related DSCP and subjected to slightly more active queue depth management. The Baker, et. al. Standards Track [Page 10] RFC 3289 Differentiated Services MIB May 2002 application is not sharply limited to a contracted rate in such a case, but can be readily contained should its traffic create a burden. 3.3.1. diffServMeterTable - The Meter Table The Meter Table is a structural table, specifying a specific functional data path element. Its entry consists essentially of three RowPointers - a "succeed" pointer, for traffic conforming to the meter, a "fail" pointer, for traffic not conforming to the meter, and a "specific" pointer, to identify the parameters in question. This structure is a bow to SNMP's limitations; it would be better to have a structure with N rates and N+1 "next" pointers, with a single algorithm specified. In this case, multiple meter entries connected by the "fail" link are understood to contain the parameters for a specified algorithm, and traffic conforming to a given rate follows their "succeed" paths. Within this MIB, only Token Bucket parameters are specified; other varieties of meters may be designed in other MIB modules. When the MIB is used for configuration, diffServMeterNextFree always contains a legal value for diffServMeterId that is not currently used in the system's configuration. 3.3.2. diffServTBParamTable - The Token Bucket Parameters Table The Token Bucket Parameters Table is a set of parameters that define a Token Bucket Meter. As a parameter, a token bucket may be specified once and applied to many interfaces, using diffServMeterSpecific. Specifically, several modes of [srTCM] and [trTCM] are addressed. Other varieties of meters may be specified in other MIB modules. In general, if a Token Bucket has N rates, it has N+1 potential outcomes - the traffic stream is slower than and therefore conforms to all of the rates, it fails the first few but is slower than and therefore conforms to the higher rates, or it fails all of them. As such, multi-rate meters should specify those rates in monotonically increasing order, passing through the diffServMeterFailNext from more committed to more excess rates, and finally falling through diffServMeterFailNext to the set of actions that apply to traffic which conforms to none of the specified rates. diffServTBParamType in the first entry indicates the algorithm being used. At each rate, diffServTBParamRate is derivable from diffServTBParamBurstSize and diffServTBParamInterval; a superior implementation will allow the Baker, et. al. Standards Track [Page 11] RFC 3289 Differentiated Services MIB May 2002 configuration of any two of diffServTBParamRate, diffServTBParamBurstSize, and diffServTBParamInterval, and respond with the appropriate error code if all three are specified but are not mathematically related. When the MIB is used for configuration, diffServTBParamNextFree always contains a legal value for diffServTBParamId that is not currently used in the system's configuration. 3.4. Actions applied to packets "Actions" are the things a differentiated services interface PHB may do to a packet in transit. At a minimum, such a policy might calculate statistics on traffic in various configured classes, mark it with a DSCP, drop it, or enqueue it before passing it on for other processing. Actions are composed of a structural element, the diffServActionTable, and various component action entries that may be applied. In the case of the Algorithmic Dropper, an additional parameter table may be specified to control Active Queue Management, as defined in [RED93] and other AQM specifications. 3.4.1. diffServActionTable - The Action Table The action table identifies sequences of actions to be applied to a packet. Successive actions are chained through diffServActionNext, ultimately resulting in zeroDotZero (indicating that the policy is complete), a pointer to a queue, or a pointer to some other functional data path element. When the MIB is used for configuration, diffServActionNextFree always contains a legal value for diffServActionId that is not currently used in the system's configuration. 3.4.2. diffServCountActTable - The Count Action Table The count action accumulates statistics pertaining to traffic passing through a given path through the policy. It is intended to be useful for usage-based billing, for statistical studies, or for analysis of the behavior of a policy in a given network. The objects in the Count Action are various counters and a discontinuity time. The counters display the number of packets and bytes encountered on the path since the discontinuity time. They share the same discontinuity time, which is the discontinuity time of the interface or agent. Baker, et. al. Standards Track [Page 12] RFC 3289 Differentiated Services MIB May 2002 The designers of this MIB expect that every path through a policy should have a corresponding counter. In early versions, it was impossible to configure an action without implementing a counter, although the current design makes them in effect the network manager's option, as a result of making actions consistent in structure and extensibility. The assurance of proper debugging and accounting is therefore left with the policy designer. When the MIB is used for configuration, diffServCountActNextFree always contains a legal value for diffServCountActId that is not currently used in the system's configuration. 3.4.3. diffServDscpMarkActTable - The Mark Action Table The Mark Action table is an unusual table, both in SNMP and in this MIB. It might be viewed not so much as an array of single-object entries as an array of OBJECT-IDENTIFIER conventions, as the OID for a diffServDscpMarkActDscp instance conveys all of the necessary information: packets are to be marked with the requisite DSCP. As such, contrary to common practice, the index for the table is read- only, and is both the Entry's index and its only value. 3.4.4. diffServAlgDropTable - The Algorithmic Drop Table The Algorithmic Drop Table identifies a dropping algorithm, drops packets, and counts the drops. Classified as an action, it is in effect a method which applies a packet to a queue, and may modify either. When the algorithm is "always drop", this is simple; when the algorithm calls for head-drop, tail-drop, or a variety of Active Queue Management, the queue is inspected, and in the case of Active Queue Management, additional parameters are REQUIRED. What may not be clear from the name is that an Algorithmic Drop action often does not drop traffic. Algorithms other than "always drop" normally drop a few percent of packets at most. The action inspects the diffServQEntry that diffServAlgDropQMeasure points to in order to determine whether the packet should be dropped. When the MIB is used for configuration, diffServAlgDropNextFree always contains a legal value for diffServAlgDropId that is not currently used in the system's configuration. Baker, et. al. Standards Track [Page 13] RFC 3289 Differentiated Services MIB May 2002 3.4.5. diffServRandomDropTable - The Random Drop Parameters Table The Random Drop Table is an extension of the Algorithmic Drop Table intended for use on queues whose depth is actively managed. Active Queue Management algorithms are typified by [RED93], but the parameters they use vary. It was deemed for the purposes of this MIB that the proper values to represent include: o Target case mean queue depth, expressed in bytes or packets o Worst case mean queue depth, expressed in bytes or packets o Maximum drop rate expressed as drops per thousand o Coefficient of an exponentially weighted moving average, expressed as the numerator of a fraction whose denominator is 65536. o Sampling rate An example of the representation chosen in this MIB for this element is shown in Figure 1. Random droppers often have their drop probability function described as a plot of drop probability (P) against averaged queue length (Q). (Qmin,Pmin) then defines the start of the characteristic plot. Normally Pmin=0, meaning with average queue length below Qmin, there will be no drops. (Qmax,Pmax) defines a "knee" on the plot, after which point the drop probability becomes more progressive (greater slope). (Qclip,1) defines the queue length at which all packets will be dropped. Notice this is different from Tail Drop because this uses an averaged queue length, although it is possible for Qclip to equal Qmax. In the MIB module, diffServRandomDropMinThreshBytes and diffServRandomDropMinThreshPkts represent Qmin. diffServRandomDropMaxThreshBytes and diffServRandomDropMaxThreshPkts represent Qmax. diffServAlgDropQThreshold represents Qclip. diffServRandomDropInvProbMax represents Pmax (inverse). This MIB does not represent Pmin (assumed to be zero unless otherwise represented). In addition, since message memory is finite, queues generally have some upper bound above which they are incapable of storing additional traffic. Normally this number is equal to Qclip, specified by diffServAlgDropQThreshold. Baker, et. al. Standards Track [Page 14] RFC 3289 Differentiated Services MIB May 2002 AlgDrop Queue +-----------------+ +-------+ --->| Next ---------+--+------------------->| Next -+--> ... | QMeasure -------+--+ | ... | | QThreshold | RandomDrop +-------+ | Type=randomDrop | +----------------+ | Specific -------+---->| MinThreshBytes | +-----------------+ | MaxThreshBytes | | ProbMax | | Weight | | SamplingRate | +----------------+ Figure 1: Example Use of the RandomDropTable for Random Droppers Each random dropper specification is associated with a queue. This allows multiple drop processes (of same or different types) to be associated with the same queue, as different PHB implementations may require. This also allows for sequences of multiple droppers if necessary. The calculation of a smoothed queue length may also have an important bearing on the behavior of the dropper: parameters may include the sampling interval or rate, and the weight of each sample. The performance may be very sensitive to the values of these parameters and a wide range of possible values may be required due to a wide range of link speeds. Most algorithms include a sample weight, represented here by diffServRandomDropWeight. The availability of diffServRandomDropSamplingRate as readable is important, the information provided by Sampling Rate is essential to the configuration of diffServRandomDropWeight. Having Sampling Rate be configurable is also helpful, as line speed increases, the ability to have queue sampling be less frequent than packet arrival is needed. Note, however, that there is ongoing research on this topic, see e.g. [ACTQMGMT] and [AQMROUTER]. Additional parameters may be added in an enterprise MIB module, e.g. by using AUGMENTS on this table, to handle aspects of random drop algorithms that are not standardized here. When the MIB is used for configuration, diffServRandomDropNextFree always contains a legal value for diffServRandomDropId that is not currently used in the system's configuration. Baker, et. al. Standards Track [Page 15] RFC 3289 Differentiated Services MIB May 2002 3.5. Queuing and Scheduling of Packets These include Queues and Schedulers, which are inter-related in their use of queuing techniques. By doing so, it is possible to build multi-level schedulers, such as those which treat a set of queues as having priority among them, and at a specific priority find a secondary WFQ scheduler with some number of queues. 3.5.1. diffServQTable - The Class or Queue Table The Queue Table models simple FIFO queues. The Scheduler Table allows flexibility in constructing both simple and somewhat more complex queuing hierarchies from those queues. Queue Table entries are pointed at by the "next" attributes of the upstream elements, such as diffServMeterSucceedNext or diffServActionNext. Note that multiple upstream elements may direct their traffic to the same Queue Table entry. For example, the Assured Forwarding PHB suggests that all traffic marked AF11, AF12 or AF13 be placed in the same queue, after metering, without reordering. To accomplish that, the upstream diffServAlgDropNext pointers each point to the same diffServQEntry. A common requirement of a queue is that its traffic enjoy a certain minimum or maximum rate, or that it be given a certain priority. Functionally, the selection of such is a function of a scheduler. The parameter is associated with the queue, however, using the Minimum or Maximum Rate Parameters Table. When the MIB is used for configuration, diffServQNextFree always contains a legal value for diffServQId that is not currently used in the system's configuration. 3.5.2. diffServSchedulerTable - The Scheduler Table The scheduler, and therefore the Scheduler Table, accepts inputs from either queues or a preceding scheduler. The Scheduler Table allows flexibility in constructing both simple and somewhat more complex queuing hierarchies from those queues. When the MIB is used for configuration, diffServSchedulerNextFree always contains a legal value for diffServSchedulerId that is not currently used in the system's configuration. 3.5.3. diffServMinRateTable - The Minimum Rate Table When the output rate of a queue or scheduler must be given a minimum rate or a priority, this is done using the diffServMinRateTable. Baker, et. al. Standards Track [Page 16] RFC 3289 Differentiated Services MIB May 2002 Rates may be expressed as absolute rates, or as a fraction of ifSpeed, and imply the use of a rate-based scheduler such as WFQ or WRR. The use of a priority implies the use of a Priority Scheduler. Only one of the Absolute or Relative rates needs to be set; the other takes the relevant value as a result. Excess capacity is distributed proportionally among the inputs to a scheduler using the assured rate. More complex functionality may be described by augmenting this MIB. When a priority scheduler is used, its effect is to give the queue the entire capacity of the subject interface less the capacity used by higher priorities, if there is traffic present to use it. This is true regardless of the rate specifications applied to that queue or other queues on the interface. Policing excess traffic will mitigate this behavior. When the MIB is used for configuration, diffServMinRateNextFree always contains a legal value for diffServMinRateId that is not currently used in the system's configuration. 3.5.4. diffServMaxRateTable - The Maximum Rate Table When the output rate of a queue or scheduler must be limited to at most a specified maximum rate, this is done using the diffServMaxRateTable. Rates may be expressed as absolute rates, or as a fraction of ifSpeed. Only one of the Absolute or Relative rate needs to be set; the other takes the relevant value as a result. The definition of a multirate shaper requires multiple diffServMaxRateEntries. In this case, an algorithm such as [SHAPER] is used. In that algorithm, more than one rate is specified, and at any given time traffic is shaped to the lowest specified rate which exceeds the arrival rate of traffic. When the MIB is used for configuration, diffServMaxRateNextFree always contains a legal value for diffServMaxRateId that is not currently used in the system's configuration. 3.5.5. Using queues and schedulers together For representing a Strict Priority scheduler, each scheduler input is assigned a priority with respect to all the other inputs feeding the same scheduler, with default values for the other parameters. Higher-priority traffic that is not being delayed for shaping will be serviced before a lower-priority input. An example is found in Figure 2. Baker, et. al. Standards Track [Page 17] RFC 3289 Differentiated Services MIB May 2002 For weighted scheduling methods, such as WFQ or WRR, the "weight" of a given scheduler input is represented with a Minimum Service Rate leaky-bucket profile which provides a guaranteed minimum bandwidth to that input, if required. This is represented by a rate diffServMinRateAbsolute; the classical weight is the ratio between that rate and the interface speed, or perhaps the ratio between that rate and the sum of the configured rates for classes. The rate may be represented by a relative value, as a fraction of the interface's current line rate, diffServMinRateRelative, to assist in cases where line rates are variable or where a higher-level policy might be expressed in terms of fractions of network resources. The two rate parameters are inter-related and changes in one may be reflected in the other. An example is found in figure 3. +-----+ +-------+ | P S | | Queue +------------>+ r c | +-------+-+--------+ | i h | |Priority| | o e | +--------+ | r d +-----------> +-------+ | i u | | Queue +------------>+ t l | +-------+-+--------+ | y e | |Priority| | r | +--------+ +-----+ Figure 2: Priority Scheduler with two queues For weighted scheduling methods, one can say loosely, that WRR focuses on meeting bandwidth sharing, without concern for relative delay amongst the queues; where WFQ controls both queue the service order and the amount of traffic serviced, providing bandwidth sharing and relative delay ordering amongst the queues. A queue or scheduled set of queues (which is an input to a scheduler) may also be capable of acting as a non-work-conserving [MODEL] traffic shaper: this is done by defining a Maximum Service Rate leaky-bucket profile in order to limit the scheduler bandwidth available to that input. This is represented by a rate, in diffServMaxRateAbsolute; the classical weight is the ratio between that rate and the interface speed, or perhaps the ratio between that rate and the sum of the configured rates for classes. The rate may be represented by a relative value, as a fraction of the interface's current line rate, diffServMaxRateRelative. This MIB presumes that shaping is something a scheduler does to its inputs, which it models as a queue with a maximum rate or a scheduler whose output has a maximum rate. Baker, et. al. Standards Track [Page 18] RFC 3289 Differentiated Services MIB May 2002 +-----+ +-------+ | W S | | Queue +------------>+ R c | +-------+-+--------+ | R h | | Rate | | e | +--------+ | o d +-----------> +-------+ | r u | | Queue +------------>+ l | +-------+-+--------+ | W e | | Rate | | F r | +--------+ | Q | +-----+ Figure 3: WRR or WFQ rate-based scheduler with two inputs The same may be done on a queue, if a given class is to be shaped to a maximum rate without shaping other classes, as in Figure 5. Other types of priority and weighted scheduling methods can be defined using existing parameters in diffServMinRateEntry. NOTE: diffServSchedulerMethod uses OBJECT IDENTIFIER syntax, with the different types of scheduling methods defined as OBJECT-IDENTITY. +---+ +-------+ | S | | Queue +------------>+ c | +-------+-+--------+ | h | | | | e +-----------> +--------+ | d +-+-------+ | u | |Shaping| +-------+ | l | | Rate | | Queue +------------>+ e | +-------+ +-------+-+--------+ | r | | | +---+ +--------+ Figure 4: Shaping scheduled traffic to a known rate Baker, et. al. Standards Track [Page 19] RFC 3289 Differentiated Services MIB May 2002 +---+ +-------+ | S | | Queue +------------>+ c | +-------+-+--------+ | h | |Min Rate| | e +-----------> +--------+ | d | | u | +-------+ | l | | Queue +------------>+ e | +-------+-+--------+ | r | |Min Rate| | | +--------+ | | |Max Rate| | | +--------+ +---+ Figure 5: Shaping one input to a work-conserving scheduler Future scheduling methods may be defined in other MIBs. This requires an OBJECT-IDENTITY definition, a description of how the existing objects are reused, if they are, and any new objects they require. To implement an EF and two AF classes, one must use a combination of priority and WRR/WFQ scheduling. This requires us to cascade two schedulers. If one were to additionally shape the output of the system to a rate lower than the interface rate, one must place an upper bound rate on the output of the priority scheduler. See figure 6. 3.6. Example configuration for AF and EF For the sake of argument, let us build an example with one EF class and four AF classes using the constructs in this MIB. 3.6.1. AF and EF Ingress Interface Configuration The ingress edge interface identifies traffic into classes, meters it, and ensures that any excess is appropriately dealt with according to the PHB. For AF, this means marking excess; for EF, it means dropping excess or shaping it to a maximum rate. Baker, et. al. Standards Track [Page 20] RFC 3289 Differentiated Services MIB May 2002 +-----+ +-------+ | P S | | Queue +---------------------------------->+ r c | +-------+----------------------+--------+ | i h | |Priority| | o e +-----------> +--------+ | r d +-+-------+ +------+ | i u | |Shaping| +-------+ | W S +------------->+ t l | | Rate | | Queue +------------>+ R c +-+--------+ | y e | +-------+ +-------+-+--------+ | R h | |Priority| | r | |Min Rate| | e | +--------+ +-----+ +--------+ | o d | +-------+ | r u | | Queue +------------>+ l | +-------+-+--------+ | W e | |Min Rate| | F r | +--------+ | Q | +------+ Figure 6: Combined EF and AF services using cascaded schedulers. +-----------------------+ | diffServDataPathStart | +-----------+-----------+ | +----------+ | +--+--+ +-----+ +-----+ +-----+ +-----+ | AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ |trTCM| |trTCM| |trTCM| |trTCM| |srTCM| |Meter| |Meter| |Meter| |Meter| |Meter| +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ ||| ||| ||| ||| | | +-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+ |+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions| +||Actions| +||Actions| +||Actions| +||Actions| +| | +| | +| | +| | +| | +-+-----+ +-+-----+ +-+-----+ +-+-----+ +-+-----+ | ||| ||| ||| ||| | VVV VVV VVV VVV V Accepted traffic is sent to IP forwarding Figure 7: combined EF and AF implementation, ingress side Baker, et. al. Standards Track [Page 21] RFC 3289 Differentiated Services MIB May 2002 3.6.1.1. Classification In The Example A packet arriving at an ingress interface picks up its policy from the diffServDataPathTable. This points to a classifier, which will select traffic according to some specification for each traffic class. An example of a classifier for an AFm class would be a set of three classifier elements, each pointing to a Multi-field classification parameter block identifying one of the AFmn DSCPs. Alternatively, the filters might contain selectors for HTTP traffic or some other application. An example of a classifier for EF traffic might be a classifier element pointing to a filter specifying the EF code point, a collection of classifiers with parameter blocks specifying individual telephone calls, or a variety of other approaches. Typically, of course, a classifier identifies a variety of traffic and breaks it up into separate classes. It might very well contain fourteen classifier elements indicating the twelve AFmn DSCP values, EF, and "everything else". These would presumably direct traffic down six functional data paths: one for each AF or EF class, and one for all other traffic. 3.6.1.2. AF Implementation On an Ingress Edge Interface Each AFm class applies a Two Rate Three Color Meter, dividing traffic into three groups. These groups of traffic conform to both specified rates, only the higher one, or none. The intent, on the ingress interface at the edge of the network, is to measure and appropriately mark traffic. 3.6.1.2.1. AF Metering On an Ingress Edge Interface Each AFm class applies a Two Rate Three Color Meter, dividing traffic into three groups. If two rates R and S, where R < S, are specified and traffic arrives at rate T, traffic comprising up to R bits per second is considered to conform to the "confirmed" rate, R. If R < T, traffic comprising up to S-R bits per second is considered to conform to the "excess" rate, S. Any further excess is non- conformant. Two meter entries are used to configure this, one for the conforming rate and one for the excess rate. The rate parameters are stored in associated Token Bucket Parameter Entries. The "FailNext" pointer of the lower rate Meter Entry points to the other Meter Entry; both "SucceedNext" pointers and the "FailNext" pointer of the higher Meter Baker, et. al. Standards Track [Page 22] RFC 3289 Differentiated Services MIB May 2002 Entry point to lists of actions. In the color-blind mode, all three classifier "next" entries point to the lower rate meter entry. In the color-aware mode, the AFm1 classifier points to the lower rate entry, the AFm2 classifier points to the higher rate entry (as it is only compared against that rate), and the AFm3 classifier points directly to the actions taken when both rates fail. 3.6.1.2.2. AF Actions On an Ingress Edge Interface For network planning and perhaps for billing purposes, arriving traffic is normally counted. Therefore, a "count" action, consisting of an action table entry pointing to a count table entry, is configured. Also, traffic is marked with the appropriate DSCP. The first R bits per second are marked AFm1, the next S-R bits per second are marked AFm2, and the rest is marked AFm3. It may be that traffic is arriving marked with the same DSCP, but in general, the additional complexity of deciding that it is being remarked to the same value is not useful. Therefore, a "mark" action, consisting of an action table entry pointing to a mark table entry, is configured. At this point, the usual case is that traffic is now forwarded in the usual manner. To indicate this, the "SucceedNext" pointer of the Mark Action is set to zeroDotZero. 3.6.1.3. EF Implementation On an Ingress Edge Interface The EF class applies a Single Rate Two Color Meter, dividing traffic into "conforming" and "excess" groups. The intent, on the ingress interface at the edge of the network, is to measure and appropriately mark conforming traffic and drop the excess. 3.6.1.3.1. EF Metering On an Ingress Edge Interface A single rate two color (srTCM) meter requires one token bucket. It is therefore configured using a single meter entry with a corresponding Token Bucket Parameter Entry. Arriving traffic either "succeeds" or "fails". 3.6.1.3.2. EF Actions On an Ingress Edge Interface For network planning and perhaps for billing purposes, arriving traffic that conforms to the meter is normally counted. Therefore, a "count" action, consisting of an action table entry pointing to a count table entry, is configured. Baker, et. al. Standards Track [Page 23] RFC 3289 Differentiated Services MIB May 2002 Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark" action, consisting of an action table entry pointing to a mark table entry, is configured. At this point, the successful traffic is now forwarded in the usual manner. To indicate this, the "SucceedNext" pointer of the Mark Action is set to zeroDotZero. Traffic that exceeded the arrival policy, however, is to be dropped. One can use a count action on this traffic if the several counters are interesting. However, since the drop counter in the Algorithmic Drop Entry will count packets dropped, this is not clearly necessary. An Algorithmic Drop Entry of the type "alwaysDrop" with no successor is sufficient. 3.7. AF and EF Egress Edge Interface Configuration 3.7.1. Classification On an Egress Edge Interface A packet arriving at an egress interface may have been classified on an ingress interface, and the egress interface may have access to that information. If it is relevant, there is no reason not to use that information. If it is not available, however, there may be a need to (re)classify on the egress interface. In any event, it picks up its "program" from the diffServDataPathTable. This points to a classifier, which will select traffic according to some specification for each traffic class. Baker, et. al. Standards Track [Page 24] RFC 3289 Differentiated Services MIB May 2002 +-----------------------+ | diffServDataPathStart | +-----------+-----------+ | +----------+ | +--+--+ +-----+ +-----+ +-----+ +-----+ | AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF | +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ ||| ||| ||| ||| | | +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ |trTCM| |trTCM| |trTCM| |trTCM| |srTCM| |Meter| |Meter| |Meter| |Meter| |Meter| +-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+ ||| ||| ||| ||| | | +-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+ |+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions| +||Actions| +||Actions| +||Actions| +||Actions| +| | +| | +| | +| | +| | +-+-----+ +-+-----+ +-+-----+ +-+-----+ +-+-----+ | ||| ||| ||| ||| | +-+++--+ +-+++--+ +-+++--+ +-+++--+ +--+---+ | Queue| | Queue| | Queue| | Queue| | Queue| +--+---+ +--+---+ +--+---+ +--+---+ +--+---+ | | | | | +--+-----------+-----------+-----------+---+ | | WFQ/WRR Scheduler | | +--------------------------------------+---+ | | | +-----+-----------+----+ | Priority Scheduler | +----------+-----------+ | V Figure 8: combined EF and AF implementation An example of a classifier for an AFm class would be a succession of three classifier elements, each pointing to a Multi-field classification parameter block identifying one of the AFmn DSCPs. Alternatively, the filter might contain selectors for HTTP traffic or some other application. Baker, et. al. Standards Track [Page 25] RFC 3289 Differentiated Services MIB May 2002 An example of a classifier for EF traffic might be either a classifier element pointing to a Multi-field parameter specifying the EF code point, or a collection of classifiers with parameter blocks specifying individual telephone calls, or a variety of other approaches. Each classifier delivers traffic to appropriate functional data path elements. 3.7.2. AF Implementation On an Egress Edge Interface Each AFm class applies a Two Rate Three Color Meter, dividing traffic into three groups. These groups of traffic conform to both specified rates, only the higher one, or none. The intent, on the ingress interface at the edge of the network, is to measure and appropriately mark traffic. 3.7.2.1. AF Metering On an Egress Edge Interface Each AFm class applies a Two Rate Three Color Meter, dividing traffic into three groups. If two rates R and S, where R < S, are specified and traffic arrives at rate T, traffic comprising up to R bits per second is considered to conform to the "confirmed" rate, R. If R < T, traffic comprising up to S-R bits per second is considered to conform to the "excess" rate, S. Any further excess is non- conformant. Two meter entries are used to configure this, one for the conforming rate and one for the excess rate. The rate parameters are stored in associated Token Bucket Parameter Entries. The "FailNext" pointer of the lower rate Meter Entry points to the other Meter Entry; both "SucceedNext" pointers and the "FailNext" pointer of the higher Meter Entry point to lists of actions. In the color-blind mode, all three classifier "next" entries point to the lower rate meter entry. In the color-aware mode, the AFm1 classifier points to the lower rate entry, the AFm2 classifier points to the higher rate entry (as it is only compared against that rate), and the AFm3 classifier points directly to the actions taken when both rates fail. Baker, et. al. Standards Track [Page 26] RFC 3289 Differentiated Services MIB May 2002 +-----------------------------------------------------+ | Classifier | +--------+--------------------------------------------+ |Green| Yellow| Red | | | +--+-----+-------+--+ Fail +--------------------+ | Meter +------+ Meter | +--+----------------+ +---+-------+--------+ | Succeed (Green) | |Fail (Red) | +---------+ | | | Succeed (Yellow)| +----+----+ +----+----+ +----+----+ | Count | | Count | | Count | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +----+----+ +----+----+ +----+----+ |Mark AFx1| |Mark AFx2| |Mark AFx3| | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +----+----+ +----+----+ +----+----+ | Random | | Random | | Random | | Drop | | Drop | | Drop | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +--------+-----------------+-----------------+--------+ | Queue | +--------------------------+--------------------------+ | +----+----+ | Rate | |Scheduler| +----+----+ | Figure 9a: Typical AF Edge egress interface configuration, using color-blind meters Baker, et. al. Standards Track [Page 27] RFC 3289 Differentiated Services MIB May 2002 +-----------------------------------------------------+ | Classifier | +--------+--------------------------------------------+ |Green | Yellow | Red | | | +----+----+ +----+----+ | | Count | | Count | | | Action +-------+ Action +------------+ +----+----+ Fail +----+----+ Fail | |Succeed |Succeed | +----+----+ +----+----+ +----+----+ | Count | | Count | | Count | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +----+----+ +----+----+ +----+----+ |Mark AFx1| |Mark AFx2| |Mark AFx3| | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +----+----+ +----+----+ +----+----+ | Random | | Random | | Random | | Drop | | Drop | | Drop | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +--------+-----------------+-----------------+--------+ | Queue | +--------------------------+--------------------------+ | +----+----+ | Rate | |Scheduler| +----+----+ | Figure 9b: Typical AF Edge egress interface configuration, using color-aware meters Baker, et. al. Standards Track [Page 28] RFC 3289 Differentiated Services MIB May 2002 +-----------------------------------------------------+ | Classifier | +--------+-----------------+-----------------+--------+ | Green | Yellow | Red | | | +----+----+ +----+----+ +----+----+ | Count | | Count | | Count | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +----+----+ +----+----+ +----+----+ | Random | | Random | | Random | | Drop | | Drop | | Drop | | Action | | Action | | Action | +----+----+ +----+----+ +----+----+ | | | +--------+-----------------+-----------------+--------+ | Queue | +--------------------------+--------------------------+ | +----+----+ | Rate | |Scheduler| +----+----+ | Figure 10: Typical AF Edge core interface configuration 3.7.2.2. AF Actions On an Egress Edge Interface For network planning and perhaps for billing purposes, departing traffic is normally counted. Therefore, a "count" action, consisting of an action table entry pointing to a count table entry, is configured. Also, traffic may be marked with an appropriate DSCP. The first R bits per second are marked AFm1, the next S-R bits per second are marked AFm2, and the rest is marked AFm3. It may be that traffic is arriving marked with the same DSCP, but in general, the additional complexity of deciding that it is being remarked to the same value is not useful. Therefore, a "mark" action, consisting of an action table entry pointing to a mark table entry, is configured. At this point, the usual case is that traffic is now queued for transmission. The queue uses Active Queue Management, using an algorithm such as RED. Therefore, an Algorithmic Dropper is Baker, et. al. Standards Track [Page 29] RFC 3289 Differentiated Services MIB May 2002 configured for each AFmn traffic stream, with a slightly lower min- threshold (and possibly lower max-threshold) for the excess traffic than for the committed traffic. 3.7.2.3. AF Rate-based Queuing On an Egress Edge Interface The queue expected by AF is normally a work-conserving queue. It usually has a specified minimum rate, and may have a maximum rate below the bandwidth of the interface. In concept, it will use as much bandwidth as is available to it, but assure the lower bound. Common ways to implement this include various forms of Weighted Fair Queuing (WFQ) or Weighted Round Robin (WRR). Integrated over a longer interval, these give each class a predictable throughput rate. They differ in that over short intervals they will order traffic differently. In general, traffic classes that keep traffic in queue will tend to absorb latency from queues with lower mean occupancy, in exchange for which they make use of any available capacity. 3.7.3. EF Implementation On an Egress Edge Interface The EF class applies a Single Rate Two Color Meter, dividing traffic into "conforming" and "excess" groups. The intent, on the egress interface at the edge of the network, is to measure and appropriately mark conforming traffic and drop the excess. 3.7.3.1. EF Metering On an Egress Edge Interface A single rate two color (srTCM) meter requires one token bucket. It is therefore configured using a single meter entry with a corresponding Token Bucket Parameter Entry. Arriving traffic either "succeeds" or "fails". 3.7.3.2. EF Actions On an Egress Edge Interface For network planning and perhaps for billing purposes, departing traffic that conforms to the meter is normally counted. Therefore, a "count" action, consisting of an action table entry pointing to a count table entry, is configured. Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark" action, consisting of an action table entry pointing to a mark table entry, is configured. Baker, et. al. Standards Track [Page 30] RFC 3289 Differentiated Services MIB May 2002 +-----------------------------------------------------+ | Classifier | +-------------------------+---------------------------+ | Voice | +-------------+----------+ | Meter | +----+-------------+-----+ | Succeed | Fail | | +----+----+ +----+----+ | Count | | Always | | Action | | Drop | +----+----+ | Action | | +---------+ +----+---------+ | Algorithmic | | Drop Action | +----+---------+ | +----------------+---------------+ | Queue | +----------------+---------------+ | +-----+-----+ | Priority | | Scheduler | +-----+-----+ Figure 11: Typical EF Edge (Policing) Configuration Baker, et. al. Standards Track [Page 31] RFC 3289 Differentiated Services MIB May 2002 +--------------------------------+ | Classifier | +----------------+---------------+ | Voice | +----+----+ | Count | | Action | +----+----+ | +------+-------+ | Algorithmic | | Drop Action | +------+-------+ | +----------------+---------------+ | Queue | +----------------+---------------+ | +-----+-----+ | Priority | | Scheduler | +-----+-----+ Figure 12: Typical EF Core interface Configuration At this point, the successful traffic is now queued for transmission, using a priority queue or perhaps a rate-based queue with significant over-provision. Since the amount of traffic present is known, one might not drop from this queue at all. Traffic that exceeded the policy, however, is dropped. A count action can be used on this traffic if the several counters are interesting. However, since the drop counter in the Algorithmic Drop Entry will count packets dropped, this is not clearly necessary. An Algorithmic Drop Entry of the type "alwaysDrop" with no successor is sufficient. 3.7.3.3. EF Priority Queuing On an Egress Edge Interface The normal implementation is a priority queue, to minimize induced jitter. A separate queue is used for each EF class, with a strict ordering. Baker, et. al. Standards Track [Page 32] RFC 3289 Differentiated Services MIB May 2002 4. Conventions used in this MIB 4.1. The use of RowPointer to indicate data path linkage RowPointer is a textual convention used to identify a conceptual row in a MIB Table by pointing to one of its objects. One of the ways this MIB uses it is to indicate succession, pointing to data path linkage table entries. For succession, it answers the question "what happens next?". Rather than presume that the next table must be as specified in the conceptual model [MODEL] and providing its index, the RowPointer takes you to the MIB row representing that thing. In the diffServMeterTable, for example, the diffServMeterFailNext RowPointer might take you to another meter, while the diffServMeterSucceedNext RowPointer would take you to an action. Since a RowPointer is not tied to any specific object except by the value it contains, it is possible and acceptable to use RowPointers to merge data paths. An obvious example of such a use is in the classifier: traffic matching the DSCPs AF11, AF12, and AF13 might be presented to the same meter in order to perform the processing described in the Assured Forwarding PHB. Another use would be to merge data paths from several interfaces; if they represent a single service contract, having them share a common set of counters and common policy may be a desirable configuration. Note well, however, that such configurations may have related implementation issues - if Differentiated Services processing for the interfaces is implemented in multiple forwarding engines, the engines will need to communicate if they are to implement such a feature. An implementation that fails to provide this capability is not considered to have failed the intention of this MIB or of the [MODEL]; an implementation that does provide it is not considered superior from a standards perspective. NOTE -- the RowPointer construct is used to connect the functional data paths. The [MODEL] describes these as TCBs, as an aid to understanding. This MIB, however, does not model TCBs directly. It operates at a lower level of abstraction using only individual elements, connected in succession by RowPointers. Therefore, the concept of TCBs enclosing individual Functional Data Path elements is not directly applicable to this MIB, although management tools that use this MIB may employ such a concept. It is possible that a path through a device following a set of RowPointers is indeterminate i.e. it ends in a dangling RowPointer. Guidance is provided in the MIB module's DESCRIPTION-clause for each of the linkage attribute. In general, for both zeroDotZero and dangling RowPointer, it is assumed the data path ends and the traffic Baker, et. al. Standards Track [Page 33] RFC 3289 Differentiated Services MIB May 2002 should be given to the next logical part of the device, usually a forwarding process or a transmission engine, or the proverbial bit- bucket. Any variation from this usage is indicated by the attribute affected. 4.2. The use of RowPointer to indicate parameters RowPointer is also used in this MIB to indicate parameterization, for pointing to parameterization table entries. For indirection (as in the diffServClfrElementTable), the idea is to allow other MIBs, including proprietary ones, to define new and arcane filters - MAC headers, IPv4 and IPv6 headers, BGP Communities and all sorts of other things - while still utilizing the structures of this MIB. This is a form of class inheritance (in "object oriented" language): it allows base object definitions ("classes") to be extended in proprietary or standard ways, in the future, by other documents. RowPointer also clearly indicates the identified conceptual row's content does not change, hence they can be simultaneously used and pointed to, by more than one data path linkage table entries. The identification of RowPointer allows higher level policy mechanisms to take advantage of this characteristic. 4.3. Conceptual row creation and deletion A number of conceptual tables defined in this MIB use as an index an arbitrary integer value, unique across the scope of the agent. In order to help with multi-manager row-creation problems, a mechanism must be provided to allow a manager to obtain unique values for such an index and to ensure that, when used, the manager knows whether it got what it wanted or not. Typically, such a table has an associated NextFree variable e.g. diffServClfrNextFree which provides a suitable value for the index of the next row to be created e.g. diffServClfrId. The value zero is used to indicate that the agent can configure no more entries. The table also has a columnar Status attribute with RowStatus syntax [RFC 2579]. Generally, if a manager attempts to create a row, the agent will create the row and return success. If the agent has insufficient resources or such a row already exists, then it returns an error. A manager must be prepared to try again in such circumstances, probably by re-reading the NextFree to obtain a new index value in case a second manager had got in between the first manager's read of the NextFree value and the first manager's row-creation attempt. Baker, et. al. Standards Track [Page 34] RFC 3289 Differentiated Services MIB May 2002 To simplify management creation and deletion of rows in this MIB, the agent is expected to assist in maintaining its consistency. It may accomplish this by maintaining internal usage counters for any row that might be pointed to by a RowPointer, or by any equivalent means. When a RowPointer is created or written, and the row it points to does not exist, the SET returns an inconsistentValue error. When a RowStatus variable is set to 'destroy' but the usage counter is non- zero, the SET returns no error but the indicated row is left intact. The agent should later remove the row in the event that the usage counter becomes zero. The use of RowStatus is covered in more detail in [RFC 2579]. 5. Extending this MIB With the structures of this MIB divided into data path linkage tables and parameterization tables, and with the use of RowPointer, new data path linkage and parameterization tables can be defined in other MIB modules, and used with tables defined in this MIB. This MIB does not limit the type of entries its RowPointer attributes can point to, hence new functional data path elements can be defined in other MIBs and integrated with functional data path elements of this MIB. For example, new Action functional data path element can be defined for Traffic Engineering and be integrated with Differentiated Services functional data path elements, possibly used within the same data path sharing the same classifiers and meters. It is more likely that new parameterization tables will be created in other MIBs as new methods or proprietary methods get deployed for existing Differentiated Services Functional Data Path Elements. For example, different kinds of filters can be defined by using new filter parameterization tables. New scheduling methods can be deployed by defining new scheduling method OIDs and new scheduling parameter tables. Notice both new data path linkage tables and parameterization tables can be added without needing to change this MIB document or affect existing tables and their usage. 6. MIB Definition DIFFSERV-DSCP-TC DEFINITIONS ::= BEGIN IMPORTS Integer32, MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; Baker, et. al. Standards Track [Page 35] RFC 3289 Differentiated Services MIB May 2002 diffServDSCPTC MODULE-IDENTITY LAST-UPDATED "200205090000Z" ORGANIZATION "IETF Differentiated Services WG" CONTACT-INFO " Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117, USA E-mail: fred@cisco.com Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821, USA E-mail: khchan@nortelnetworks.com Andrew Smith Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089, PRC E-mail: ah_smith@acm.org Differentiated Services Working Group: diffserv@ietf.org" DESCRIPTION "The Textual Conventions defined in this module should be used whenever a Differentiated Services Code Point is used in a MIB." REVISION "200205090000Z" DESCRIPTION "Initial version, published as RFC 3289." ::= { mib-2 96 } Dscp ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A Differentiated Services Code-Point that may be used for marking a traffic stream." REFERENCE "RFC 2474, RFC 2780" SYNTAX Integer32 (0..63) DscpOrAny ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The IP header Differentiated Services Code-Point that may be Baker, et. al. Standards Track [Page 36] RFC 3289 Differentiated Services MIB May 2002 used for discriminating among traffic streams. The value -1 is used to indicate a wild card i.e. any value." REFERENCE "RFC 2474, RFC 2780" SYNTAX Integer32 (-1 | 0..63) END DIFFSERV-MIB DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Counter64, MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, zeroDotZero, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, RowPointer, StorageType, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndexOrZero FROM IF-MIB InetAddressType, InetAddress, InetAddressPrefixLength, InetPortNumber FROM INET-ADDRESS-MIB BurstSize FROM INTEGRATED-SERVICES-MIB Dscp, DscpOrAny FROM DIFFSERV-DSCP-TC; diffServMib MODULE-IDENTITY LAST-UPDATED "200202070000Z" ORGANIZATION "IETF Differentiated Services WG" CONTACT-INFO " Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117, USA E-mail: fred@cisco.com Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821, USA E-mail: khchan@nortelnetworks.com Andrew Smith Harbour Networks Jiuling Building Baker, et. al. Standards Track [Page 37] RFC 3289 Differentiated Services MIB May 2002 21 North Xisanhuan Ave. Beijing, 100089, PRC E-mail: ah_smith@acm.org Differentiated Services Working Group: diffserv@ietf.org" DESCRIPTION "This MIB defines the objects necessary to manage a device that uses the Differentiated Services Architecture described in RFC 2475. The Conceptual Model of a Differentiated Services Router provides supporting information on how such a router is modeled." REVISION "200202070000Z" DESCRIPTION "Initial version, published as RFC 3289." ::= { mib-2 97 } diffServMIBObjects OBJECT IDENTIFIER ::= { diffServMib 1 } diffServMIBConformance OBJECT IDENTIFIER ::= { diffServMib 2 } diffServMIBAdmin OBJECT IDENTIFIER ::= { diffServMib 3 } IndexInteger ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An integer which may be used as a table index." SYNTAX Unsigned32 (1..4294967295) IndexIntegerNextFree ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An integer which may be used as a new Index in a table. The special value of 0 indicates that no more new entries can be created in the relevant table. When a MIB is used for configuration, an object with this SYNTAX always contains a legal value (if non-zero) for an index that is not currently used in the relevant table. The Command Generator (Network Management Application) reads this variable and uses the (non-zero) value read when creating a new row with an SNMP SET. When the SET is performed, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET succeeds and the Command Responder (agent) changes the value of this object, according to an implementation-specific algorithm. If the value is in use, Baker, et. al. Standards Track [Page 38] RFC 3289 Differentiated Services MIB May 2002 however, the SET fails. The Network Management Application must then re-read this variable to obtain a new usable value. An OBJECT-TYPE definition using this SYNTAX MUST specify the relevant table for which the object is providing this functionality." SYNTAX Unsigned32 (0..4294967295) IfDirection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "IfDirection specifies a direction of data travel on an interface. 'inbound' traffic is operated on during reception from the interface, while 'outbound' traffic is operated on prior to transmission on the interface." SYNTAX INTEGER { inbound(1), -- ingress interface outbound(2) -- egress interface } -- -- Data Path -- diffServDataPath OBJECT IDENTIFIER ::= { diffServMIBObjects 1 } -- -- Data Path Table -- -- The Data Path Table enumerates the Differentiated Services -- Functional Data Paths within this device. Each entry in this table -- is indexed by ifIndex and ifDirection. Each entry provides the -- first Differentiated Services Functional Data Path Element to -- process data flowing along specific data path. This table should -- have at most two entries for each interface capable of -- Differentiated Services processing on this device: ingress and -- egress. -- Note that Differentiated Services Functional Data Path Elements -- linked together using their individual next pointers and anchored by -- an entry of the diffServDataPathTable constitute a functional data -- path. -- diffServDataPathTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServDataPathEntry MAX-ACCESS not-accessible STATUS current Baker, et. al. Standards Track [Page 39] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "The data path table contains RowPointers indicating the start of the functional data path for each interface and traffic direction in this device. These may merge, or be separated into parallel data paths." ::= { diffServDataPath 1 } diffServDataPathEntry OBJECT-TYPE SYNTAX DiffServDataPathEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the data path table indicates the start of a single Differentiated Services Functional Data Path in this device. These are associated with individual interfaces, logical or physical, and therefore are instantiated by ifIndex. Therefore, the interface index must have been assigned, according to the procedures applicable to that, before it can be meaningfully used. Generally, this means that the interface must exist. When diffServDataPathStorage is of type nonVolatile, however, this may reflect the configuration for an interface whose ifIndex has been assigned but for which the supporting implementation is not currently present." INDEX { ifIndex, diffServDataPathIfDirection } ::= { diffServDataPathTable 1 } DiffServDataPathEntry ::= SEQUENCE { diffServDataPathIfDirection IfDirection, diffServDataPathStart RowPointer, diffServDataPathStorage StorageType, diffServDataPathStatus RowStatus } diffServDataPathIfDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "IfDirection specifies whether the reception or transmission path for this interface is in view." ::= { diffServDataPathEntry 1 } diffServDataPathStart OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current Baker, et. al. Standards Track [Page 40] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "This selects the first Differentiated Services Functional Data Path Element to handle traffic for this data path. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry diffServActionEntry diffServAlgDropEntry diffServQEntry A value of zeroDotZero in this attribute indicates that no Differentiated Services treatment is performed on traffic of this data path. A pointer with the value zeroDotZero normally terminates a functional data path. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." ::= { diffServDataPathEntry 2 } diffServDataPathStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServDataPathEntry 3 } diffServDataPathStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time." ::= { diffServDataPathEntry 4 } -- -- Classifiers -- diffServClassifier OBJECT IDENTIFIER ::= { diffServMIBObjects 2 } -- Baker, et. al. Standards Track [Page 41] RFC 3289 Differentiated Services MIB May 2002 -- Classifier Table -- -- The Classifier Table allows multiple classifier elements, of same or -- different types, to be used together. A classifier must completely -- classify all packets presented to it. This means that all traffic -- presented to a classifier must match at least one classifier element -- within the classifier, with the classifier element parameters -- specified by a filter. -- If there is ambiguity between classifier elements of different -- classifier, classifier linkage order indicates their precedence; the -- first classifier in the link is applied to the traffic first. -- Entries in the classifier element table serves as the anchor for -- each classification pattern, defined in filter table entries. Each -- classifier element table entry also specifies the subsequent -- downstream Differentiated Services Functional Data Path Element when -- the classification pattern is satisfied. Each entry in the -- classifier element table describes one branch of the fan-out -- characteristic of a classifier indicated in the Informal -- Differentiated Services Model section 4.1. A classifier is composed -- of one or more classifier elements. diffServClfrNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServClfrId, or a zero to indicate that none exist." ::= { diffServClassifier 1 } diffServClfrTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServClfrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates all the diffserv classifier functional data path elements of this device. The actual classification definitions are defined in diffServClfrElementTable entries belonging to each classifier. An entry in this table, pointed to by a RowPointer specifying an instance of diffServClfrStatus, is frequently used as the name for a set of classifier elements, which all use the index diffServClfrId. Per the semantics of the classifier element table, these entries constitute one or more unordered sets of tests which may be simultaneously applied to a message to Baker, et. al. Standards Track [Page 42] RFC 3289 Differentiated Services MIB May 2002 classify it. The primary function of this table is to ensure that the value of diffServClfrId is unique before attempting to use it in creating a diffServClfrElementEntry. Therefore, the diffServClfrEntry must be created on the same SET as the diffServClfrElementEntry, or before the diffServClfrElementEntry is created." ::= { diffServClassifier 2 } diffServClfrEntry OBJECT-TYPE SYNTAX DiffServClfrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the classifier table describes a single classifier. All classifier elements belonging to the same classifier use the classifier's diffServClfrId as part of their index." INDEX { diffServClfrId } ::= { diffServClfrTable 1 } DiffServClfrEntry ::= SEQUENCE { diffServClfrId IndexInteger, diffServClfrStorage StorageType, diffServClfrStatus RowStatus } diffServClfrId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the classifier entries. Managers should obtain new values for row creation in this table by reading diffServClfrNextFree." ::= { diffServClfrEntry 1 } diffServClfrStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServClfrEntry 2 } diffServClfrStatus OBJECT-TYPE Baker, et. al. Standards Track [Page 43] RFC 3289 Differentiated Services MIB May 2002 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServClfrEntry 3 } -- -- Classifier Element Table -- diffServClfrElementNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServClfrElementId, or a zero to indicate that none exist." ::= { diffServClassifier 3 } diffServClfrElementTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServClfrElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The classifier element table enumerates the relationship between classification patterns and subsequent downstream Differentiated Services Functional Data Path elements. diffServClfrElementSpecific points to a filter that specifies the classification parameters. A classifier may use filter tables of different types together. One example of a filter table defined in this MIB is diffServMultiFieldClfrTable, for IP Multi-Field Classifiers (MFCs). Such an entry might identify anything from a single micro-flow (an identifiable sub-session packet stream directed from one sending transport to the receiving transport or transports), or aggregates of those such as the traffic from a host, traffic for an application, or traffic between two hosts using an application and a given DSCP. The standard Behavior Aggregate used in the Differentiated Services Architecture is encoded as a degenerate case of such an aggregate - the traffic using a particular DSCP value. Filter tables for other filter types may be defined elsewhere." Baker, et. al. Standards Track [Page 44] RFC 3289 Differentiated Services MIB May 2002 ::= { diffServClassifier 4 } diffServClfrElementEntry OBJECT-TYPE SYNTAX DiffServClfrElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the classifier element table describes a single element of the classifier." INDEX { diffServClfrId, diffServClfrElementId } ::= { diffServClfrElementTable 1 } DiffServClfrElementEntry ::= SEQUENCE { diffServClfrElementId IndexInteger, diffServClfrElementPrecedence Unsigned32, diffServClfrElementNext RowPointer, diffServClfrElementSpecific RowPointer, diffServClfrElementStorage StorageType, diffServClfrElementStatus RowStatus } diffServClfrElementId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Classifier Element entries. Managers obtain new values for row creation in this table by reading diffServClfrElementNextFree." ::= { diffServClfrElementEntry 1 } diffServClfrElementPrecedence OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The relative order in which classifier elements are applied: higher numbers represent classifier element with higher precedence. Classifier elements with the same order must be unambiguous i.e. they must define non-overlapping patterns, and are considered to be applied simultaneously to the traffic stream. Classifier elements with different order may overlap in their filters: the classifier element with the highest order that matches is taken. On a given interface, there must be a complete classifier in place at all times in the ingress direction. This means one or more filters must match any possible pattern. There is no such Baker, et. al. Standards Track [Page 45] RFC 3289 Differentiated Services MIB May 2002 requirement in the egress direction." ::= { diffServClfrElementEntry 2 } diffServClfrElementNext OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute provides one branch of the fan-out functionality of a classifier described in the Informal Differentiated Services Model section 4.1. This selects the next Differentiated Services Functional Data Path Element to handle traffic for this data path. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry diffServActionEntry diffServAlgDropEntry diffServQEntry A value of zeroDotZero in this attribute indicates no further Differentiated Services treatment is performed on traffic of this data path. The use of zeroDotZero is the normal usage for the last functional data path element of the current data path. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." ::= { diffServClfrElementEntry 3 } diffServClfrElementSpecific OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to a valid entry in another table, filter table, that describes the applicable classification parameters, e.g. an entry in diffServMultiFieldClfrTable. The value zeroDotZero is interpreted to match anything not matched by another classifier element - only one such entry may exist for each classifier. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or Baker, et. al. Standards Track [Page 46] RFC 3289 Differentiated Services MIB May 2002 becomes inactive by other means, the element is ignored." ::= { diffServClfrElementEntry 4 } diffServClfrElementStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServClfrElementEntry 5 } diffServClfrElementStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServClfrElementEntry 6 } -- -- IP Multi-field Classification Table -- -- Classification based on six different fields in the IP header. -- Functional Data Paths may share definitions by using the same entry. -- diffServMultiFieldClfrNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServMultiFieldClfrId, or a zero to indicate that none exist." ::= { diffServClassifier 5 } diffServMultiFieldClfrTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServMultiFieldClfrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of IP Multi-field Classifier filter entries that a Baker, et. al. Standards Track [Page 47] RFC 3289 Differentiated Services MIB May 2002 system may use to identify IP traffic." ::= { diffServClassifier 6 } diffServMultiFieldClfrEntry OBJECT-TYPE SYNTAX DiffServMultiFieldClfrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP Multi-field Classifier entry describes a single filter." INDEX { diffServMultiFieldClfrId } ::= { diffServMultiFieldClfrTable 1 } DiffServMultiFieldClfrEntry ::= SEQUENCE { diffServMultiFieldClfrId IndexInteger, diffServMultiFieldClfrAddrType InetAddressType, diffServMultiFieldClfrDstAddr InetAddress, diffServMultiFieldClfrDstPrefixLength InetAddressPrefixLength, diffServMultiFieldClfrSrcAddr InetAddress, diffServMultiFieldClfrSrcPrefixLength InetAddressPrefixLength, diffServMultiFieldClfrDscp DscpOrAny, diffServMultiFieldClfrFlowId Unsigned32, diffServMultiFieldClfrProtocol Unsigned32, diffServMultiFieldClfrDstL4PortMin InetPortNumber, diffServMultiFieldClfrDstL4PortMax InetPortNumber, diffServMultiFieldClfrSrcL4PortMin InetPortNumber, diffServMultiFieldClfrSrcL4PortMax InetPortNumber, diffServMultiFieldClfrStorage StorageType, diffServMultiFieldClfrStatus RowStatus } diffServMultiFieldClfrId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the MultiField Classifier filter entries. Managers obtain new values for row creation in this table by reading diffServMultiFieldClfrNextFree." ::= { diffServMultiFieldClfrEntry 1 } diffServMultiFieldClfrAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of IP address used by this classifier entry. While other types of addresses are defined in the InetAddressType Baker, et. al. Standards Track [Page 48] RFC 3289 Differentiated Services MIB May 2002 textual convention, and DNS names, a classifier can only look at packets on the wire. Therefore, this object is limited to IPv4 and IPv6 addresses." ::= { diffServMultiFieldClfrEntry 2 } diffServMultiFieldClfrDstAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address to match against the packet's destination IP address. This may not be a DNS name, but may be an IPv4 or IPv6 prefix. diffServMultiFieldClfrDstPrefixLength indicates the number of bits that are relevant." ::= { diffServMultiFieldClfrEntry 3 } diffServMultiFieldClfrDstPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength UNITS "bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the CIDR Prefix carried in diffServMultiFieldClfrDstAddr. In IPv4 addresses, a length of 0 indicates a match of any address; a length of 32 indicates a match of a single host address, and a length between 0 and 32 indicates the use of a CIDR Prefix. IPv6 is similar, except that prefix lengths range from 0..128." DEFVAL { 0 } ::= { diffServMultiFieldClfrEntry 4 } diffServMultiFieldClfrSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address to match against the packet's source IP address. This may not be a DNS name, but may be an IPv4 or IPv6 prefix. diffServMultiFieldClfrSrcPrefixLength indicates the number of bits that are relevant." ::= { diffServMultiFieldClfrEntry 5 } diffServMultiFieldClfrSrcPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength UNITS "bits" MAX-ACCESS read-create STATUS current DESCRIPTION Baker, et. al. Standards Track [Page 49] RFC 3289 Differentiated Services MIB May 2002 "The length of the CIDR Prefix carried in diffServMultiFieldClfrSrcAddr. In IPv4 addresses, a length of 0 indicates a match of any address; a length of 32 indicates a match of a single host address, and a length between 0 and 32 indicates the use of a CIDR Prefix. IPv6 is similar, except that prefix lengths range from 0..128." DEFVAL { 0 } ::= { diffServMultiFieldClfrEntry 6 } diffServMultiFieldClfrDscp OBJECT-TYPE SYNTAX DscpOrAny MAX-ACCESS read-create STATUS current DESCRIPTION "The value that the DSCP in the packet must have to match this entry. A value of -1 indicates that a specific DSCP value has not been defined and thus all DSCP values are considered a match." DEFVAL { -1 } ::= { diffServMultiFieldClfrEntry 7 } diffServMultiFieldClfrFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { diffServMultiFieldClfrEntry 8 } diffServMultiFieldClfrProtocol OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The IP protocol to match against the IPv4 protocol number or the IPv6 Next- Header number in the packet. A value of 255 means match all. Note the protocol number of 255 is reserved by IANA, and Next-Header number of 0 is used in IPv6." DEFVAL { 255 } ::= { diffServMultiFieldClfrEntry 9 } diffServMultiFieldClfrDstL4PortMin OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum value that the layer-4 destination port number in the packet must have in order to match this classifier entry." DEFVAL { 0 } Baker, et. al. Standards Track [Page 50] RFC 3289 Differentiated Services MIB May 2002 ::= { diffServMultiFieldClfrEntry 10 } diffServMultiFieldClfrDstL4PortMax OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum value that the layer-4 destination port number in the packet must have in order to match this classifier entry. This value must be equal to or greater than the value specified for this entry in diffServMultiFieldClfrDstL4PortMin." DEFVAL { 65535 } ::= { diffServMultiFieldClfrEntry 11 } diffServMultiFieldClfrSrcL4PortMin OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum value that the layer-4 source port number in the packet must have in order to match this classifier entry." DEFVAL { 0 } ::= { diffServMultiFieldClfrEntry 12 } diffServMultiFieldClfrSrcL4PortMax OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum value that the layer-4 source port number in the packet must have in order to match this classifier entry. This value must be equal to or greater than the value specified for this entry in diffServMultiFieldClfrSrcL4PortMin." DEFVAL { 65535 } ::= { diffServMultiFieldClfrEntry 13 } diffServMultiFieldClfrStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServMultiFieldClfrEntry 14 } diffServMultiFieldClfrStatus OBJECT-TYPE Baker, et. al. Standards Track [Page 51] RFC 3289 Differentiated Services MIB May 2002 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServMultiFieldClfrEntry 15 } -- -- Meters -- diffServMeter OBJECT IDENTIFIER ::= { diffServMIBObjects 3 } -- -- This MIB supports a variety of Meters. It includes a specific -- definition for Token Bucket Meter, which are but one type of -- specification. Other metering parameter sets can be defined in other -- MIBs. -- Multiple meter elements may be logically cascaded using their -- diffServMeterSucceedNext and diffServMeterFailNext pointers if -- required. One example of this might be for an AF PHB implementation -- that uses multiple level conformance meters. -- Cascading of individual meter elements in the MIB is intended to be -- functionally equivalent to multiple level conformance determination -- of a packet. The sequential nature of the representation is merely -- a notational convenience for this MIB. -- srTCM meters (RFC 2697) can be specified using two sets of -- diffServMeterEntry and diffServTBParamEntry. The first set specifies -- the Committed Information Rate and Committed Burst Size -- token-bucket. The second set specifies the Excess Burst Size -- token-bucket. -- trTCM meters (RFC 2698) can be specified using two sets of -- diffServMeterEntry and diffServTBParamEntry. The first set specifies -- the Committed Information Rate and Committed Burst Size -- token-bucket. The second set specifies the Peak Information Rate -- and Peak Burst Size token-bucket. -- tswTCM meters (RFC 2859) can be specified using two sets of -- diffServMeterEntry and diffServTBParamEntry. The first set specifies -- the Committed Target Rate token-bucket. The second set specifies Baker, et. al. Standards Track [Page 52] RFC 3289 Differentiated Services MIB May 2002 -- the Peak Target Rate token-bucket. diffServTBParamInterval in each -- token bucket reflects the Average Interval. -- diffServMeterNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServMeterId, or a zero to indicate that none exist." ::= { diffServMeter 1 } diffServMeterTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServMeterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates specific meters that a system may use to police a stream of traffic. The traffic stream to be metered is determined by the Differentiated Services Functional Data Path Element(s) upstream of the meter i.e. by the object(s) that point to each entry in this table. This may include all traffic on an interface. Specific meter details are to be found in table entry referenced by diffServMeterSpecific." ::= { diffServMeter 2 } diffServMeterEntry OBJECT-TYPE SYNTAX DiffServMeterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the meter table describes a single conformance level of a meter." INDEX { diffServMeterId } ::= { diffServMeterTable 1 } DiffServMeterEntry ::= SEQUENCE { diffServMeterId IndexInteger, diffServMeterSucceedNext RowPointer, diffServMeterFailNext RowPointer, diffServMeterSpecific RowPointer, diffServMeterStorage StorageType, diffServMeterStatus RowStatus } Baker, et. al. Standards Track [Page 53] RFC 3289 Differentiated Services MIB May 2002 diffServMeterId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Meter entries. Managers obtain new values for row creation in this table by reading diffServMeterNextFree." ::= { diffServMeterEntry 1 } diffServMeterSucceedNext OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the traffic does conform, this selects the next Differentiated Services Functional Data Path element to handle traffic for this data path. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry diffServActionEntry diffServAlgDropEntry diffServQEntry A value of zeroDotZero in this attribute indicates that no further Differentiated Services treatment is performed on traffic of this data path. The use of zeroDotZero is the normal usage for the last functional data path element of the current data path. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." DEFVAL { zeroDotZero } ::= { diffServMeterEntry 2 } diffServMeterFailNext OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the traffic does not conform, this selects the next Differentiated Services Functional Data Path element to handle traffic for this data path. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry Baker, et. al. Standards Track [Page 54] RFC 3289 Differentiated Services MIB May 2002 diffServActionEntry diffServAlgDropEntry diffServQEntry A value of zeroDotZero in this attribute indicates no further Differentiated Services treatment is performed on traffic of this data path. The use of zeroDotZero is the normal usage for the last functional data path element of the current data path. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." DEFVAL { zeroDotZero } ::= { diffServMeterEntry 3 } diffServMeterSpecific OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This indicates the behavior of the meter by pointing to an entry containing detailed parameters. Note that entries in that specific table must be managed explicitly. For example, diffServMeterSpecific may point to an entry in diffServTBParamTable, which contains an instance of a single set of Token Bucket parameters. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the meter always succeeds." ::= { diffServMeterEntry 4 } diffServMeterStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServMeterEntry 5 } diffServMeterStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Baker, et. al. Standards Track [Page 55] RFC 3289 Differentiated Services MIB May 2002 STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServMeterEntry 6 } -- -- Token Bucket Parameter Table -- diffServTBParam OBJECT IDENTIFIER ::= { diffServMIBObjects 4 } -- Each entry in the Token Bucket Parameter Table parameterize a single -- token bucket. Multiple token buckets can be used together to -- parameterize multiple levels of conformance. -- Note that an entry in the Token Bucket Parameter Table can be shared -- by multiple diffServMeterTable entries. -- diffServTBParamNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServTBParamId, or a zero to indicate that none exist." ::= { diffServTBParam 1 } diffServTBParamTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServTBParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates a single set of token bucket meter parameters that a system may use to police a stream of traffic. Such meters are modeled here as having a single rate and a single burst size. Multiple entries are used when multiple rates/burst sizes are needed." ::= { diffServTBParam 2 } diffServTBParamEntry OBJECT-TYPE SYNTAX DiffServTBParamEntry MAX-ACCESS not-accessible STATUS current Baker, et. al. Standards Track [Page 56] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "An entry that describes a single set of token bucket parameters." INDEX { diffServTBParamId } ::= { diffServTBParamTable 1 } DiffServTBParamEntry ::= SEQUENCE { diffServTBParamId IndexInteger, diffServTBParamType AutonomousType, diffServTBParamRate Unsigned32, diffServTBParamBurstSize BurstSize, diffServTBParamInterval Unsigned32, diffServTBParamStorage StorageType, diffServTBParamStatus RowStatus } diffServTBParamId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Token Bucket Parameter entries. Managers obtain new values for row creation in this table by reading diffServTBParamNextFree." ::= { diffServTBParamEntry 1 } diffServTBParamType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The Metering algorithm associated with the Token Bucket parameters. zeroDotZero indicates this is unknown. Standard values for generic algorithms: diffServTBParamSimpleTokenBucket, diffServTBParamAvgRate, diffServTBParamSrTCMBlind, diffServTBParamSrTCMAware, diffServTBParamTrTCMBlind, diffServTBParamTrTCMAware, and diffServTBParamTswTCM are specified in this MIB as OBJECT- IDENTITYs; additional values may be further specified in other MIBs." ::= { diffServTBParamEntry 2 } diffServTBParamRate OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kilobits per second" MAX-ACCESS read-create STATUS current Baker, et. al. Standards Track [Page 57] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "The token-bucket rate, in kilobits per second (kbps). This attribute is used for: 1. CIR in RFC 2697 for srTCM 2. CIR and PIR in RFC 2698 for trTCM 3. CTR and PTR in RFC 2859 for TSWTCM 4. AverageRate in RFC 3290." ::= { diffServTBParamEntry 3 } diffServTBParamBurstSize OBJECT-TYPE SYNTAX BurstSize UNITS "Bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of bytes in a single transmission burst. This attribute is used for: 1. CBS and EBS in RFC 2697 for srTCM 2. CBS and PBS in RFC 2698 for trTCM 3. Burst Size in RFC 3290." ::= { diffServTBParamEntry 4 } diffServTBParamInterval OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The time interval used with the token bucket. For: 1. Average Rate Meter, the Informal Differentiated Services Model section 5.2.1, - Delta. 2. Simple Token Bucket Meter, the Informal Differentiated Services Model section 5.1, - time interval t. 3. RFC 2859 TSWTCM, - AVG_INTERVAL. 4. RFC 2697 srTCM, RFC 2698 trTCM, - token bucket update time interval." ::= { diffServTBParamEntry 5 } diffServTBParamStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServTBParamEntry 6 } Baker, et. al. Standards Track [Page 58] RFC 3289 Differentiated Services MIB May 2002 diffServTBParamStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServTBParamEntry 7 } -- -- OIDs for diffServTBParamType definitions. -- diffServTBMeters OBJECT IDENTIFIER ::= { diffServMIBAdmin 1 } diffServTBParamSimpleTokenBucket OBJECT-IDENTITY STATUS current DESCRIPTION "Two Parameter Token Bucket Meter as described in the Informal Differentiated Services Model section 5.2.3." ::= { diffServTBMeters 1 } diffServTBParamAvgRate OBJECT-IDENTITY STATUS current DESCRIPTION "Average Rate Meter as described in the Informal Differentiated Services Model section 5.2.1." ::= { diffServTBMeters 2 } diffServTBParamSrTCMBlind OBJECT-IDENTITY STATUS current DESCRIPTION "Single Rate Three Color Marker Metering as defined by RFC 2697, in the `Color Blind' mode as described by the RFC." REFERENCE "RFC 2697" ::= { diffServTBMeters 3 } diffServTBParamSrTCMAware OBJECT-IDENTITY STATUS current DESCRIPTION "Single Rate Three Color Marker Metering as defined by RFC 2697, in the `Color Aware' mode as described by the RFC." REFERENCE "RFC 2697" Baker, et. al. Standards Track [Page 59] RFC 3289 Differentiated Services MIB May 2002 ::= { diffServTBMeters 4 } diffServTBParamTrTCMBlind OBJECT-IDENTITY STATUS current DESCRIPTION "Two Rate Three Color Marker Metering as defined by RFC 2698, in the `Color Blind' mode as described by the RFC." REFERENCE "RFC 2698" ::= { diffServTBMeters 5 } diffServTBParamTrTCMAware OBJECT-IDENTITY STATUS current DESCRIPTION "Two Rate Three Color Marker Metering as defined by RFC 2698, in the `Color Aware' mode as described by the RFC." REFERENCE "RFC 2698" ::= { diffServTBMeters 6 } diffServTBParamTswTCM OBJECT-IDENTITY STATUS current DESCRIPTION "Time Sliding Window Three Color Marker Metering as defined by RFC 2859." REFERENCE "RFC 2859" ::= { diffServTBMeters 7 } -- -- Actions -- diffServAction OBJECT IDENTIFIER ::= { diffServMIBObjects 5 } -- -- The Action Table allows enumeration of the different types of -- actions to be applied to a traffic flow. -- diffServActionNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServActionId, or a zero to indicate that none exist." ::= { diffServAction 1 } Baker, et. al. Standards Track [Page 60] RFC 3289 Differentiated Services MIB May 2002 diffServActionTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServActionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Action Table enumerates actions that can be performed to a stream of traffic. Multiple actions can be concatenated. For example, traffic exiting from a meter may be counted, marked, and potentially dropped before entering a queue. Specific actions are indicated by diffServActionSpecific which points to an entry of a specific action type parameterizing the action in detail." ::= { diffServAction 2 } diffServActionEntry OBJECT-TYPE SYNTAX DiffServActionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in the action table allows description of one specific action to be applied to traffic." INDEX { diffServActionId } ::= { diffServActionTable 1 } DiffServActionEntry ::= SEQUENCE { diffServActionId IndexInteger, diffServActionInterface InterfaceIndexOrZero, diffServActionNext RowPointer, diffServActionSpecific RowPointer, diffServActionStorage StorageType, diffServActionStatus RowStatus } diffServActionId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Action entries. Managers obtain new values for row creation in this table by reading diffServActionNextFree." ::= { diffServActionEntry 1 } diffServActionInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current Baker, et. al. Standards Track [Page 61] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "The interface index (value of ifIndex) that this action occurs on. This may be derived from the diffServDataPathStartEntry's index by extension through the various RowPointers. However, as this may be difficult for a network management station, it is placed here as well. If this is indeterminate, the value is zero. This is of especial relevance when reporting the counters which may apply to traffic crossing an interface: diffServCountActOctets, diffServCountActPkts, diffServAlgDropOctets, diffServAlgDropPkts, diffServAlgRandomDropOctets, and diffServAlgRandomDropPkts. It is also especially relevant to the queue and scheduler which may be subsequently applied." ::= { diffServActionEntry 2 } diffServActionNext OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This selects the next Differentiated Services Functional Data Path Element to handle traffic for this data path. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry diffServActionEntry diffServAlgDropEntry diffServQEntry A value of zeroDotZero in this attribute indicates no further Differentiated Services treatment is performed on traffic of this data path. The use of zeroDotZero is the normal usage for the last functional data path element of the current data path. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." DEFVAL { zeroDotZero } ::= { diffServActionEntry 3 } diffServActionSpecific OBJECT-TYPE Baker, et. al. Standards Track [Page 62] RFC 3289 Differentiated Services MIB May 2002 SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to an object instance providing additional information for the type of action indicated by this action table entry. For the standard actions defined by this MIB module, this should point to either a diffServDscpMarkActEntry or a diffServCountActEntry. For other actions, it may point to an object instance defined in some other MIB. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the Meter should be treated as if it were not present. This may lead to incorrect policy behavior." ::= { diffServActionEntry 4 } diffServActionStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServActionEntry 5 } diffServActionStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServActionEntry 6 } -- DSCP Mark Action Table -- -- Rows of this table are pointed to by diffServActionSpecific to -- provide detailed parameters specific to the DSCP Mark action. -- -- A single entry in this table can be shared by multiple Baker, et. al. Standards Track [Page 63] RFC 3289 Differentiated Services MIB May 2002 -- diffServActionTable entries. -- diffServDscpMarkActTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServDscpMarkActEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates specific DSCPs used for marking or remarking the DSCP field of IP packets. The entries of this table may be referenced by a diffServActionSpecific attribute." ::= { diffServAction 3 } diffServDscpMarkActEntry OBJECT-TYPE SYNTAX DiffServDscpMarkActEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DSCP mark action table that describes a single DSCP used for marking." INDEX { diffServDscpMarkActDscp } ::= { diffServDscpMarkActTable 1 } DiffServDscpMarkActEntry ::= SEQUENCE { diffServDscpMarkActDscp Dscp } diffServDscpMarkActDscp OBJECT-TYPE SYNTAX Dscp MAX-ACCESS read-only STATUS current DESCRIPTION "The DSCP that this Action will store into the DSCP field of the subject. It is quite possible that the only packets subject to this Action are already marked with this DSCP. Note also that Differentiated Services processing may result in packet being marked on both ingress to a network and on egress from it, and that ingress and egress can occur in the same router." ::= { diffServDscpMarkActEntry 1 } -- -- Count Action Table -- -- Because the MIB structure allows multiple cascading -- diffServActionEntry be used to describe multiple actions for a data -- path, the counter became an optional action type. In normal -- implementation, either a data path has counters or it does not, as -- opposed to being configurable. The management entity may choose to Baker, et. al. Standards Track [Page 64] RFC 3289 Differentiated Services MIB May 2002 -- read the counter or not. Hence it is recommended for implementation -- that have counters to always configure the count action as the first -- of multiple actions. -- diffServCountActNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServCountActId, or a zero to indicate that none exist." ::= { diffServAction 4 } diffServCountActTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServCountActEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains counters for all the traffic passing through an action element." ::= { diffServAction 5 } diffServCountActEntry OBJECT-TYPE SYNTAX DiffServCountActEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the count action table describes a single set of traffic counters." INDEX { diffServCountActId } ::= { diffServCountActTable 1 } DiffServCountActEntry ::= SEQUENCE { diffServCountActId IndexInteger, diffServCountActOctets Counter64, diffServCountActPkts Counter64, diffServCountActStorage StorageType, diffServCountActStatus RowStatus } diffServCountActId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Count Action entries. Managers obtain new values for row creation in this table by reading Baker, et. al. Standards Track [Page 65] RFC 3289 Differentiated Services MIB May 2002 diffServCountActNextFree." ::= { diffServCountActEntry 1 } diffServCountActOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets at the Action data path element. Discontinuities in the value of this counter can occur at re- initialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { diffServCountActEntry 2 } diffServCountActPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets at the Action data path element. Discontinuities in the value of this counter can occur at re- initialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { diffServCountActEntry 3 } diffServCountActStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServCountActEntry 4 } diffServCountActStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing Baker, et. al. Standards Track [Page 66] RFC 3289 Differentiated Services MIB May 2002 to it results in destruction being delayed until the row is no longer used." ::= { diffServCountActEntry 5 } -- -- Algorithmic Drop Table -- diffServAlgDrop OBJECT IDENTIFIER ::= { diffServMIBObjects 6 } diffServAlgDropNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServAlgDropId, or a zero to indicate that none exist." ::= { diffServAlgDrop 1 } diffServAlgDropTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServAlgDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The algorithmic drop table contains entries describing an element that drops packets according to some algorithm." ::= { diffServAlgDrop 2 } diffServAlgDropEntry OBJECT-TYPE SYNTAX DiffServAlgDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes a process that drops packets according to some algorithm. Further details of the algorithm type are to be found in diffServAlgDropType and with more detail parameter entry pointed to by diffServAlgDropSpecific when necessary." INDEX { diffServAlgDropId } ::= { diffServAlgDropTable 1 } DiffServAlgDropEntry ::= SEQUENCE { diffServAlgDropId IndexInteger, diffServAlgDropType INTEGER, diffServAlgDropNext RowPointer, diffServAlgDropQMeasure RowPointer, diffServAlgDropQThreshold Unsigned32, diffServAlgDropSpecific RowPointer, diffServAlgDropOctets Counter64, Baker, et. al. Standards Track [Page 67] RFC 3289 Differentiated Services MIB May 2002 diffServAlgDropPkts Counter64, diffServAlgRandomDropOctets Counter64, diffServAlgRandomDropPkts Counter64, diffServAlgDropStorage StorageType, diffServAlgDropStatus RowStatus } diffServAlgDropId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Algorithmic Dropper entries. Managers obtain new values for row creation in this table by reading diffServAlgDropNextFree." ::= { diffServAlgDropEntry 1 } diffServAlgDropType OBJECT-TYPE SYNTAX INTEGER { other(1), tailDrop(2), headDrop(3), randomDrop(4), alwaysDrop(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of algorithm used by this dropper. The value other(1) requires further specification in some other MIB module. In the tailDrop(2) algorithm, diffServAlgDropQThreshold represents the maximum depth of the queue, pointed to by diffServAlgDropQMeasure, beyond which all newly arriving packets will be dropped. In the headDrop(3) algorithm, if a packet arrives when the current depth of the queue, pointed to by diffServAlgDropQMeasure, is at diffServAlgDropQThreshold, packets currently at the head of the queue are dropped to make room for the new packet to be enqueued at the tail of the queue. In the randomDrop(4) algorithm, on packet arrival, an Active Queue Management algorithm is executed which may randomly drop a packet. This algorithm may be proprietary, and it may drop either the arriving packet or another packet in the queue. diffServAlgDropSpecific points to a diffServRandomDropEntry that describes the algorithm. For this algorithm, Baker, et. al. Standards Track [Page 68] RFC 3289 Differentiated Services MIB May 2002 diffServAlgDropQThreshold is understood to be the absolute maximum size of the queue and additional parameters are described in diffServRandomDropTable. The alwaysDrop(5) algorithm is as its name specifies; always drop. In this case, the other configuration values in this Entry are not meaningful; There is no useful 'next' processing step, there is no queue, and parameters describing the queue are not useful. Therefore, diffServAlgDropNext, diffServAlgDropMeasure, and diffServAlgDropSpecific are all zeroDotZero." ::= { diffServAlgDropEntry 2 } diffServAlgDropNext OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This selects the next Differentiated Services Functional Data Path Element to handle traffic for this data path. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry diffServActionEntry diffServQEntry A value of zeroDotZero in this attribute indicates no further Differentiated Services treatment is performed on traffic of this data path. The use of zeroDotZero is the normal usage for the last functional data path element of the current data path. When diffServAlgDropType is alwaysDrop(5), this object is ignored. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." ::= { diffServAlgDropEntry 3 } diffServAlgDropQMeasure OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Points to an entry in the diffServQTable to indicate the queue that a drop algorithm is to monitor when deciding whether to drop a packet. If the row pointed to does not exist, the algorithmic dropper element is considered inactive. Baker, et. al. Standards Track [Page 69] RFC 3289 Differentiated Services MIB May 2002 Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." ::= { diffServAlgDropEntry 4 } diffServAlgDropQThreshold OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "Bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold on the depth in bytes of the queue being measured at which a trigger is generated to the dropping algorithm, unless diffServAlgDropType is alwaysDrop(5) where this object is ignored. For the tailDrop(2) or headDrop(3) algorithms, this represents the depth of the queue, pointed to by diffServAlgDropQMeasure, at which the drop action will take place. Other algorithms will need to define their own semantics for this threshold." ::= { diffServAlgDropEntry 5 } diffServAlgDropSpecific OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Points to a table entry that provides further detail regarding a drop algorithm. Entries with diffServAlgDropType equal to other(1) may have this point to a table defined in another MIB module. Entries with diffServAlgDropType equal to randomDrop(4) must have this point to an entry in diffServRandomDropTable. For all other algorithms specified in this MIB, this should take the value zeroDotZero. The diffServAlgDropType is authoritative for the type of the drop algorithm and the specific parameters for the drop algorithm needs to be evaluated based on the diffServAlgDropType. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." Baker, et. al. Standards Track [Page 70] RFC 3289 Differentiated Services MIB May 2002 ::= { diffServAlgDropEntry 6 } diffServAlgDropOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been deterministically dropped by this drop process. Discontinuities in the value of this counter can occur at re- initialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { diffServAlgDropEntry 7 } diffServAlgDropPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that have been deterministically dropped by this drop process. Discontinuities in the value of this counter can occur at re- initialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { diffServAlgDropEntry 8 } diffServAlgRandomDropOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been randomly dropped by this drop process. This counter applies, therefore, only to random droppers. Discontinuities in the value of this counter can occur at re- initialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { diffServAlgDropEntry 9 } diffServAlgRandomDropPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only Baker, et. al. Standards Track [Page 71] RFC 3289 Differentiated Services MIB May 2002 STATUS current DESCRIPTION "The number of packets that have been randomly dropped by this drop process. This counter applies, therefore, only to random droppers. Discontinuities in the value of this counter can occur at re- initialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { diffServAlgDropEntry 10 } diffServAlgDropStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServAlgDropEntry 11 } diffServAlgDropStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServAlgDropEntry 12 } -- -- Random Drop Table -- diffServRandomDropNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServRandomDropId, or a zero to indicate that none exist." ::= { diffServAlgDrop 3 } Baker, et. al. Standards Track [Page 72] RFC 3289 Differentiated Services MIB May 2002 diffServRandomDropTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServRandomDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The random drop table contains entries describing a process that drops packets randomly. Entries in this table are pointed to by diffServAlgDropSpecific." ::= { diffServAlgDrop 4 } diffServRandomDropEntry OBJECT-TYPE SYNTAX DiffServRandomDropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes a process that drops packets according to a random algorithm." INDEX { diffServRandomDropId } ::= { diffServRandomDropTable 1 } DiffServRandomDropEntry ::= SEQUENCE { diffServRandomDropId IndexInteger, diffServRandomDropMinThreshBytes Unsigned32, diffServRandomDropMinThreshPkts Unsigned32, diffServRandomDropMaxThreshBytes Unsigned32, diffServRandomDropMaxThreshPkts Unsigned32, diffServRandomDropProbMax Unsigned32, diffServRandomDropWeight Unsigned32, diffServRandomDropSamplingRate Unsigned32, diffServRandomDropStorage StorageType, diffServRandomDropStatus RowStatus } diffServRandomDropId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Random Drop entries. Managers obtain new values for row creation in this table by reading diffServRandomDropNextFree." ::= { diffServRandomDropEntry 1 } diffServRandomDropMinThreshBytes OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "bytes" MAX-ACCESS read-create STATUS current Baker, et. al. Standards Track [Page 73] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "The average queue depth in bytes, beyond which traffic has a non-zero probability of being dropped. Changes in this variable may or may not be reflected in the reported value of diffServRandomDropMinThreshPkts." ::= { diffServRandomDropEntry 2 } diffServRandomDropMinThreshPkts OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "The average queue depth in packets, beyond which traffic has a non-zero probability of being dropped. Changes in this variable may or may not be reflected in the reported value of diffServRandomDropMinThreshBytes." ::= { diffServRandomDropEntry 3 } diffServRandomDropMaxThreshBytes OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The average queue depth beyond which traffic has a probability indicated by diffServRandomDropProbMax of being dropped or marked. Note that this differs from the physical queue limit, which is stored in diffServAlgDropQThreshold. Changes in this variable may or may not be reflected in the reported value of diffServRandomDropMaxThreshPkts." ::= { diffServRandomDropEntry 4 } diffServRandomDropMaxThreshPkts OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "packets" MAX-ACCESS read-create STATUS current DESCRIPTION "The average queue depth beyond which traffic has a probability indicated by diffServRandomDropProbMax of being dropped or marked. Note that this differs from the physical queue limit, which is stored in diffServAlgDropQThreshold. Changes in this variable may or may not be reflected in the reported value of diffServRandomDropMaxThreshBytes." ::= { diffServRandomDropEntry 5 } diffServRandomDropProbMax OBJECT-TYPE Baker, et. al. Standards Track [Page 74] RFC 3289 Differentiated Services MIB May 2002 SYNTAX Unsigned32 (0..1000) MAX-ACCESS read-create STATUS current DESCRIPTION "The worst case random drop probability, expressed in drops per thousand packets. For example, if in the worst case every arriving packet may be dropped (100%) for a period, this has the value 1000. Alternatively, if in the worst case only one percent (1%) of traffic may be dropped, it has the value 10." ::= { diffServRandomDropEntry 6 } diffServRandomDropWeight OBJECT-TYPE SYNTAX Unsigned32 (0..65536) MAX-ACCESS read-create STATUS current DESCRIPTION "The weighting of past history in affecting the Exponentially Weighted Moving Average function that calculates the current average queue depth. The equation uses diffServRandomDropWeight/65536 as the coefficient for the new sample in the equation, and (65536 - diffServRandomDropWeight)/65536 as the coefficient of the old value. Implementations may limit the values of diffServRandomDropWeight to a subset of the possible range of values, such as powers of two. Doing this would facilitate implementation of the Exponentially Weighted Moving Average using shift instructions or registers." ::= { diffServRandomDropEntry 7 } diffServRandomDropSamplingRate OBJECT-TYPE SYNTAX Unsigned32 (0..1000000) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times per second the queue is sampled for queue average calculation. A value of zero is used to mean that the queue is sampled approximately each time a packet is enqueued (or dequeued)." ::= { diffServRandomDropEntry 8 } diffServRandomDropStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current Baker, et. al. Standards Track [Page 75] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServRandomDropEntry 9 } diffServRandomDropStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServRandomDropEntry 10 } -- -- Queue Table -- diffServQueue OBJECT IDENTIFIER ::= { diffServMIBObjects 7 } -- -- An entry of diffServQTable represents a FIFO queue Differentiated -- Services Functional Data Path element as described in the Informal -- Differentiated Services Model section 7.1.1. Note that the -- specification of scheduling parameters for a queue as part of the -- input to a scheduler functional data path element as described in -- the Informal Differentiated Services Model section 7.1.2. This -- allows building of hierarchical queuing/scheduling. A queue -- therefore has these attributes: -- -- 1. Which scheduler will service this queue, diffServQNext. -- 2. How the scheduler will service this queue, with respect -- to all the other queues the same scheduler needs to service, -- diffServQMinRate. -- -- Note that upstream Differentiated Services Functional Data Path -- elements may point to a shared diffServQTable entry as described -- in the Informal Differentiated Services Model section 7.1.1. -- diffServQNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only Baker, et. al. Standards Track [Page 76] RFC 3289 Differentiated Services MIB May 2002 STATUS current DESCRIPTION "This object contains an unused value for diffServQId, or a zero to indicate that none exist." ::= { diffServQueue 1 } diffServQTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServQEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Queue Table enumerates the individual queues. Note that the MIB models queuing systems as composed of individual queues, one per class of traffic, even though they may in fact be structured as classes of traffic scheduled using a common calendar queue, or in other ways." ::= { diffServQueue 2 } diffServQEntry OBJECT-TYPE SYNTAX DiffServQEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Queue Table describes a single queue or class of traffic." INDEX { diffServQId } ::= { diffServQTable 1 } DiffServQEntry ::= SEQUENCE { diffServQId IndexInteger, diffServQNext RowPointer, diffServQMinRate RowPointer, diffServQMaxRate RowPointer, diffServQStorage StorageType, diffServQStatus RowStatus } diffServQId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Queue entries. Managers obtain new values for row creation in this table by reading diffServQNextFree." ::= { diffServQEntry 1 } diffServQNext OBJECT-TYPE Baker, et. al. Standards Track [Page 77] RFC 3289 Differentiated Services MIB May 2002 SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This selects the next Differentiated Services Scheduler. The RowPointer must point to a diffServSchedulerEntry. A value of zeroDotZero in this attribute indicates an incomplete diffServQEntry instance. In such a case, the entry has no operational effect, since it has no parameters to give it meaning. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." ::= { diffServQEntry 2 } diffServQMinRate OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This RowPointer indicates the diffServMinRateEntry that the scheduler, pointed to by diffServQNext, should use to service this queue. If the row pointed to is zeroDotZero, the minimum rate and priority is unspecified. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." ::= { diffServQEntry 3 } diffServQMaxRate OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This RowPointer indicates the diffServMaxRateEntry that the scheduler, pointed to by diffServQNext, should use to service this queue. If the row pointed to is zeroDotZero, the maximum rate is the line speed of the interface. Baker, et. al. Standards Track [Page 78] RFC 3289 Differentiated Services MIB May 2002 Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." ::= { diffServQEntry 4 } diffServQStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServQEntry 5 } diffServQStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServQEntry 6 } -- -- Scheduler Table -- diffServScheduler OBJECT IDENTIFIER ::= { diffServMIBObjects 8 } -- -- A Scheduler Entry represents a packet scheduler, such as a priority -- scheduler or a WFQ scheduler. It provides flexibility for multiple -- scheduling algorithms, each servicing multiple queues, to be used on -- the same logical/physical interface. -- -- Note that upstream queues or schedulers specify several of the -- scheduler's parameters. These must be properly specified if the -- scheduler is to behave as expected. -- -- The diffServSchedulerMaxRate attribute specifies the parameters when -- a scheduler's output is sent to another scheduler. This is used in -- building hierarchical queues or schedulers. Baker, et. al. Standards Track [Page 79] RFC 3289 Differentiated Services MIB May 2002 -- -- More discussion of the scheduler functional data path element is in -- the Informal Differentiated Services Model section 7.1.2. -- diffServSchedulerNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServSchedulerId, or a zero to indicate that none exist." ::= { diffServScheduler 1 } diffServSchedulerTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServSchedulerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Scheduler Table enumerates packet schedulers. Multiple scheduling algorithms can be used on a given data path, with each algorithm described by one diffServSchedulerEntry." ::= { diffServScheduler 2 } diffServSchedulerEntry OBJECT-TYPE SYNTAX DiffServSchedulerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Scheduler Table describing a single instance of a scheduling algorithm." INDEX { diffServSchedulerId } ::= { diffServSchedulerTable 1 } DiffServSchedulerEntry ::= SEQUENCE { diffServSchedulerId IndexInteger, diffServSchedulerNext RowPointer, diffServSchedulerMethod AutonomousType, diffServSchedulerMinRate RowPointer, diffServSchedulerMaxRate RowPointer, diffServSchedulerStorage StorageType, diffServSchedulerStatus RowStatus } diffServSchedulerId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current Baker, et. al. Standards Track [Page 80] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "An index that enumerates the Scheduler entries. Managers obtain new values for row creation in this table by reading diffServSchedulerNextFree." ::= { diffServSchedulerEntry 1 } diffServSchedulerNext OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This selects the next Differentiated Services Functional Data Path Element to handle traffic for this data path. This normally is null (zeroDotZero), or points to a diffServSchedulerEntry or a diffServQEntry. However, this RowPointer may also point to an instance of: diffServClfrEntry, diffServMeterEntry, diffServActionEntry, diffServAlgDropEntry. It would point another diffServSchedulerEntry when implementing multiple scheduler methods for the same data path, such as having one set of queues scheduled by WRR and that group participating in a priority scheduling system in which other queues compete with it in that way. It might also point to a second scheduler in a hierarchical scheduling system. If the row pointed to is zeroDotZero, no further Differentiated Services treatment is performed on traffic of this data path. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." DEFVAL { zeroDotZero } ::= { diffServSchedulerEntry 2 } diffServSchedulerMethod OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The scheduling algorithm used by this Scheduler. zeroDotZero indicates that this is unknown. Standard values for generic algorithms: diffServSchedulerPriority, diffServSchedulerWRR, and diffServSchedulerWFQ are specified in this MIB; additional values Baker, et. al. Standards Track [Page 81] RFC 3289 Differentiated Services MIB May 2002 may be further specified in other MIBs." ::= { diffServSchedulerEntry 3 } diffServSchedulerMinRate OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This RowPointer indicates the entry in diffServMinRateTable which indicates the priority or minimum output rate from this scheduler. This attribute is used only when there is more than one level of scheduler. When it has the value zeroDotZero, it indicates that no minimum rate or priority is imposed. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." DEFVAL { zeroDotZero } ::= { diffServSchedulerEntry 4 } diffServSchedulerMaxRate OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This RowPointer indicates the entry in diffServMaxRateTable which indicates the maximum output rate from this scheduler. When more than one maximum rate applies (eg, when a multi-rate shaper is in view), it points to the first of those rate entries. This attribute is used only when there is more than one level of scheduler. When it has the value zeroDotZero, it indicates that no maximum rate is imposed. Setting this to point to a target that does not exist results in an inconsistentValue error. If the row pointed to is removed or becomes inactive by other means, the treatment is as if this attribute contains a value of zeroDotZero." DEFVAL { zeroDotZero } ::= { diffServSchedulerEntry 5 } diffServSchedulerStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create Baker, et. al. Standards Track [Page 82] RFC 3289 Differentiated Services MIB May 2002 STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServSchedulerEntry 6 } diffServSchedulerStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServSchedulerEntry 7 } -- -- OIDs for diffServTBParamType definitions. -- diffServSchedulers OBJECT IDENTIFIER ::= { diffServMIBAdmin 2 } diffServSchedulerPriority OBJECT-IDENTITY STATUS current DESCRIPTION "For use with diffServSchedulerMethod to indicate the Priority scheduling method. This is defined as an algorithm in which the presence of data in a queue or set of queues absolutely precludes dequeue from another queue or set of queues of lower priority. Note that attributes from diffServMinRateEntry of the queues/schedulers feeding this scheduler are used when determining the next packet to schedule." ::= { diffServSchedulers 1 } diffServSchedulerWRR OBJECT-IDENTITY STATUS current DESCRIPTION "For use with diffServSchedulerMethod to indicate the Weighted Round Robin scheduling method, defined as any algorithm in which a set of queues are visited in a fixed order, and varying amounts of traffic are removed from each queue in turn to implement an average output rate by class. Notice attributes from diffServMinRateEntry of the queues/schedulers feeding this scheduler are used when determining the next packet to schedule." Baker, et. al. Standards Track [Page 83] RFC 3289 Differentiated Services MIB May 2002 ::= { diffServSchedulers 2 } diffServSchedulerWFQ OBJECT-IDENTITY STATUS current DESCRIPTION "For use with diffServSchedulerMethod to indicate the Weighted Fair Queuing scheduling method, defined as any algorithm in which a set of queues are conceptually visited in some order, to implement an average output rate by class. Notice attributes from diffServMinRateEntry of the queues/schedulers feeding this scheduler are used when determining the next packet to schedule." ::= { diffServSchedulers 3 } -- -- Minimum Rate Parameters Table -- -- The parameters used by a scheduler for its inputs or outputs are -- maintained separately from the Queue or Scheduler table entries for -- reusability reasons and so that they may be used by both queues and -- schedulers. This follows the approach for separation of data path -- elements from parameterization that is used throughout this MIB. -- Use of these Minimum Rate Parameter Table entries by Queues and -- Schedulers allows the modeling of hierarchical scheduling systems. -- -- Specifically, a Scheduler has one or more inputs and one output. -- Any queue feeding a scheduler, or any scheduler which feeds a second -- scheduler, might specify a minimum transfer rate by pointing to an -- Minimum Rate Parameter Table entry. -- -- The diffServMinRatePriority/Abs/Rel attributes are used as -- parameters to the work-conserving portion of a scheduler: -- "work-conserving" implies that the scheduler can continue to emit -- data as long as there is data available at its input(s). This has -- the effect of guaranteeing a certain priority relative to other -- scheduler inputs and/or a certain minimum proportion of the -- available output bandwidth. Properly configured, this means a -- certain minimum rate, which may be exceeded should traffic be -- available should there be spare bandwidth after all other classes -- have had opportunities to consume their own minimum rates. -- diffServMinRateNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServMinRateId, or a zero to indicate that none exist." Baker, et. al. Standards Track [Page 84] RFC 3289 Differentiated Services MIB May 2002 ::= { diffServScheduler 3 } diffServMinRateTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServMinRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Minimum Rate Parameters Table enumerates individual sets of scheduling parameter that can be used/reused by Queues and Schedulers." ::= { diffServScheduler 4 } diffServMinRateEntry OBJECT-TYPE SYNTAX DiffServMinRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Minimum Rate Parameters Table describes a single set of scheduling parameters for use by one or more queues or schedulers." INDEX { diffServMinRateId } ::= { diffServMinRateTable 1 } DiffServMinRateEntry ::= SEQUENCE { diffServMinRateId IndexInteger, diffServMinRatePriority Unsigned32, diffServMinRateAbsolute Unsigned32, diffServMinRateRelative Unsigned32, diffServMinRateStorage StorageType, diffServMinRateStatus RowStatus } diffServMinRateId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Scheduler Parameter entries. Managers obtain new values for row creation in this table by reading diffServMinRateNextFree." ::= { diffServMinRateEntry 1 } diffServMinRatePriority OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The priority of this input to the associated scheduler, relative Baker, et. al. Standards Track [Page 85] RFC 3289 Differentiated Services MIB May 2002 to the scheduler's other inputs. A queue or scheduler with a larger numeric value will be served before another with a smaller numeric value." ::= { diffServMinRateEntry 2 } diffServMinRateAbsolute OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum absolute rate, in kilobits/sec, that a downstream scheduler element should allocate to this queue. If the value is zero, then there is effectively no minimum rate guarantee. If the value is non-zero, the scheduler will assure the servicing of this queue to at least this rate. Note that this attribute value and that of diffServMinRateRelative are coupled: changes to one will affect the value of the other. They are linked by the following equation, in that setting one will change the other: diffServMinRateRelative = (diffServMinRateAbsolute*1000000)/ifSpeed or, if appropriate: diffServMinRateRelative = diffServMinRateAbsolute/ifHighSpeed" REFERENCE "ifSpeed, ifHighSpeed, Interface MIB, RFC 2863" ::= { diffServMinRateEntry 3 } diffServMinRateRelative OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum rate that a downstream scheduler element should allocate to this queue, relative to the maximum rate of the interface as reported by ifSpeed or ifHighSpeed, in units of 1/1000 of 1. If the value is zero, then there is effectively no minimum rate guarantee. If the value is non-zero, the scheduler will assure the servicing of this queue to at least this rate. Note that this attribute value and that of diffServMinRateAbsolute are coupled: changes to one will affect the value of the other. They are linked by the following equation, in that setting one will change the other: Baker, et. al. Standards Track [Page 86] RFC 3289 Differentiated Services MIB May 2002 diffServMinRateRelative = (diffServMinRateAbsolute*1000000)/ifSpeed or, if appropriate: diffServMinRateRelative = diffServMinRateAbsolute/ifHighSpeed" REFERENCE "ifSpeed, ifHighSpeed, Interface MIB, RFC 2863" ::= { diffServMinRateEntry 4 } diffServMinRateStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServMinRateEntry 5 } diffServMinRateStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServMinRateEntry 6 } -- -- Maximum Rate Parameter Table -- -- The parameters used by a scheduler for its inputs or outputs are -- maintained separately from the Queue or Scheduler table entries for -- reusability reasons and so that they may be used by both queues and -- schedulers. This follows the approach for separation of data path -- elements from parameterization that is used throughout this MIB. -- Use of these Maximum Rate Parameter Table entries by Queues and -- Schedulers allows the modeling of hierarchical scheduling systems. -- -- Specifically, a Scheduler has one or more inputs and one output. -- Any queue feeding a scheduler, or any scheduler which feeds a second -- scheduler, might specify a maximum transfer rate by pointing to a -- Maximum Rate Parameter Table entry. Multi-rate shapers, such as a Baker, et. al. Standards Track [Page 87] RFC 3289 Differentiated Services MIB May 2002 -- Dual Leaky Bucket algorithm, specify their rates using multiple -- Maximum Rate Parameter Entries with the same diffServMaxRateId but -- different diffServMaxRateLevels. -- -- The diffServMaxRateLevel/Abs/Rel attributes are used as -- parameters to the non-work-conserving portion of a scheduler: -- non-work-conserving implies that the scheduler may sometimes not -- emit a packet, even if there is data available at its input(s). -- This has the effect of limiting the servicing of the queue/scheduler -- input or output, in effect performing shaping of the packet stream -- passing through the queue/scheduler, as described in the Informal -- Differentiated Services Model section 7.2. -- diffServMaxRateNextFree OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for diffServMaxRateId, or a zero to indicate that none exist." ::= { diffServScheduler 5 } diffServMaxRateTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServMaxRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Maximum Rate Parameter Table enumerates individual sets of scheduling parameter that can be used/reused by Queues and Schedulers." ::= { diffServScheduler 6 } diffServMaxRateEntry OBJECT-TYPE SYNTAX DiffServMaxRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Maximum Rate Parameter Table describes a single set of scheduling parameters for use by one or more queues or schedulers." INDEX { diffServMaxRateId, diffServMaxRateLevel } ::= { diffServMaxRateTable 1 } DiffServMaxRateEntry ::= SEQUENCE { diffServMaxRateId IndexInteger, diffServMaxRateLevel Unsigned32, diffServMaxRateAbsolute Unsigned32, Baker, et. al. Standards Track [Page 88] RFC 3289 Differentiated Services MIB May 2002 diffServMaxRateRelative Unsigned32, diffServMaxRateThreshold BurstSize, diffServMaxRateStorage StorageType, diffServMaxRateStatus RowStatus } diffServMaxRateId OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that enumerates the Maximum Rate Parameter entries. Managers obtain new values for row creation in this table by reading diffServMaxRateNextFree." ::= { diffServMaxRateEntry 1 } diffServMaxRateLevel OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that indicates which level of a multi-rate shaper is being given its parameters. A multi-rate shaper has some number of rate levels. Frame Relay's dual rate specification refers to a 'committed' and an 'excess' rate; ATM's dual rate specification refers to a 'mean' and a 'peak' rate. This table is generalized to support an arbitrary number of rates. The committed or mean rate is level 1, the peak rate (if any) is the highest level rate configured, and if there are other rates they are distributed in monotonically increasing order between them." ::= { diffServMaxRateEntry 2 } diffServMaxRateAbsolute OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum rate in kilobits/sec that a downstream scheduler element should allocate to this queue. If the value is zero, then there is effectively no maximum rate limit and that the scheduler should attempt to be work conserving for this queue. If the value is non-zero, the scheduler will limit the servicing of this queue to, at most, this rate in a non-work-conserving manner. Note that this attribute value and that of diffServMaxRateRelative are coupled: changes to one will affect the value of the other. They are linked by the following Baker, et. al. Standards Track [Page 89] RFC 3289 Differentiated Services MIB May 2002 equation, in that setting one will change the other: diffServMaxRateRelative = (diffServMaxRateAbsolute*1000000)/ifSpeed or, if appropriate: diffServMaxRateRelative = diffServMaxRateAbsolute/ifHighSpeed" REFERENCE "ifSpeed, ifHighSpeed, Interface MIB, RFC 2863" ::= { diffServMaxRateEntry 3 } diffServMaxRateRelative OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum rate that a downstream scheduler element should allocate to this queue, relative to the maximum rate of the interface as reported by ifSpeed or ifHighSpeed, in units of 1/1000 of 1. If the value is zero, then there is effectively no maximum rate limit and the scheduler should attempt to be work conserving for this queue. If the value is non-zero, the scheduler will limit the servicing of this queue to, at most, this rate in a non-work-conserving manner. Note that this attribute value and that of diffServMaxRateAbsolute are coupled: changes to one will affect the value of the other. They are linked by the following equation, in that setting one will change the other: diffServMaxRateRelative = (diffServMaxRateAbsolute*1000000)/ifSpeed or, if appropriate: diffServMaxRateRelative = diffServMaxRateAbsolute/ifHighSpeed" REFERENCE "ifSpeed, ifHighSpeed, Interface MIB, RFC 2863" ::= { diffServMaxRateEntry 4 } diffServMaxRateThreshold OBJECT-TYPE SYNTAX BurstSize UNITS "Bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of bytes of queue depth at which the rate of a Baker, et. al. Standards Track [Page 90] RFC 3289 Differentiated Services MIB May 2002 multi-rate scheduler will increase to the next output rate. In the last conceptual row for such a shaper, this threshold is ignored and by convention is zero." REFERENCE "Adaptive rate Shaper, RFC 2963" ::= { diffServMaxRateEntry 5 } diffServMaxRateStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { diffServMaxRateEntry 6 } diffServMaxRateStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time. Setting this variable to 'destroy' when the MIB contains one or more RowPointers pointing to it results in destruction being delayed until the row is no longer used." ::= { diffServMaxRateEntry 7 } -- -- MIB Compliance statements. -- diffServMIBCompliances OBJECT IDENTIFIER ::= { diffServMIBConformance 1 } diffServMIBGroups OBJECT IDENTIFIER ::= { diffServMIBConformance 2 } diffServMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB." MODULE IF-MIB -- The interfaces MIB, RFC2863 MANDATORY-GROUPS { Baker, et. al. Standards Track [Page 91] RFC 3289 Differentiated Services MIB May 2002 ifCounterDiscontinuityGroup } MODULE -- This Module MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBQGroup, diffServMIBSchedulerGroup, diffServMIBMaxRateGroup, diffServMIBMinRateGroup, diffServMIBCounterGroup } GROUP diffServMIBMeterGroup DESCRIPTION "This group is mandatory for devices that implement metering functions." GROUP diffServMIBTBParamGroup DESCRIPTION "This group is mandatory for devices that implement token-bucket metering functions." GROUP diffServMIBDscpMarkActGroup DESCRIPTION "This group is mandatory for devices that implement DSCP-Marking functions." GROUP diffServMIBRandomDropGroup DESCRIPTION "This group is mandatory for devices that implement Random Drop functions." OBJECT diffServDataPathStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServClfrStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServClfrElementStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } Baker, et. al. Standards Track [Page 92] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServMultiFieldClfrAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and IPv6 addresses." OBJECT diffServMultiFieldClfrDstAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT diffServAlgDropStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServRandomDropStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServQStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServSchedulerStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServMinRateStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServMaxRateStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } Baker, et. al. Standards Track [Page 93] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "Support for createAndWait and notInService is not required." ::= { diffServMIBCompliances 1 } -- -- Read-Only Compliance -- diffServMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read-create (i.e. in read-only mode), then such an implementation can claim read-only compliance. Such a device can then be monitored but can not be configured with this MIB." MODULE IF-MIB -- The interfaces MIB, RFC2863 MANDATORY-GROUPS { ifCounterDiscontinuityGroup } MODULE -- This Module MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBQGroup, diffServMIBSchedulerGroup, diffServMIBMaxRateGroup, diffServMIBMinRateGroup, diffServMIBCounterGroup } GROUP diffServMIBMeterGroup DESCRIPTION "This group is mandatory for devices that implement metering functions." GROUP diffServMIBTBParamGroup DESCRIPTION "This group is mandatory for devices that implement token-bucket metering functions." GROUP diffServMIBDscpMarkActGroup DESCRIPTION "This group is mandatory for devices that implement DSCP-Marking functions." GROUP diffServMIBRandomDropGroup Baker, et. al. Standards Track [Page 94] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "This group is mandatory for devices that implement Random Drop functions." OBJECT diffServDataPathStart MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServDataPathStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServDataPathStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServClfrNextFree MIN-ACCESS not-accessible DESCRIPTION "Object not needed when diffServClfrTable is implemented read- only" OBJECT diffServClfrStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServClfrStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServClfrElementNextFree MIN-ACCESS not-accessible DESCRIPTION "Object not needed when diffServClfrelementTable is implemented read-only" OBJECT diffServClfrElementPrecedence MIN-ACCESS read-only DESCRIPTION Baker, et. al. Standards Track [Page 95] RFC 3289 Differentiated Services MIB May 2002 "Write access is not required." OBJECT diffServClfrElementNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServClfrElementSpecific MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServClfrElementStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServClfrElementStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServMultiFieldClfrNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServMultiFieldClfrTable is implemented in read-only mode." OBJECT diffServMultiFieldClfrAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT diffServMultiFieldClfrDstAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT diffServMultiFieldClfrDstPrefixLength MIN-ACCESS read-only DESCRIPTION "Write access is not required." Baker, et. al. Standards Track [Page 96] RFC 3289 Differentiated Services MIB May 2002 OBJECT diffServMultiFieldClfrSrcAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT diffServMultiFieldClfrSrcPrefixLength MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrDscp MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrFlowId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrDstL4PortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrDstL4PortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrSrcL4PortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrSrcL4PortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrStorage MIN-ACCESS read-only Baker, et. al. Standards Track [Page 97] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "Write access is not required." OBJECT diffServMultiFieldClfrStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, createAndWait and notInService support is not required." OBJECT diffServMeterNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServMultiFieldClfrTable is implemented in read-only mode." OBJECT diffServMeterSucceedNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMeterFailNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMeterSpecific MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMeterStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMeterStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServTBParamNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServTBParamTable is implemented in read-only mode." Baker, et. al. Standards Track [Page 98] RFC 3289 Differentiated Services MIB May 2002 OBJECT diffServTBParamType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServTBParamRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServTBParamBurstSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServTBParamInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServTBParamStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServTBParamStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServActionNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServActionTable is implemented in read-only mode." OBJECT diffServActionInterface MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServActionNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." Baker, et. al. Standards Track [Page 99] RFC 3289 Differentiated Services MIB May 2002 OBJECT diffServActionSpecific MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServActionStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServActionStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServCountActNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServCountActTable is implemented in read-only mode." OBJECT diffServCountActStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServCountActStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServAlgDropNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServAlgDropTable is implemented in read-only mode." OBJECT diffServAlgDropType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServAlgDropNext MIN-ACCESS read-only Baker, et. al. Standards Track [Page 100] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "Write access is not required." OBJECT diffServAlgDropQMeasure MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServAlgDropQThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServAlgDropSpecific MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServAlgDropStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServAlgDropStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServRandomDropNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServRandomDropTable is implemented in read-only mode." OBJECT diffServRandomDropMinThreshBytes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropMinThreshPkts MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropMaxThreshBytes MIN-ACCESS read-only Baker, et. al. Standards Track [Page 101] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "Write access is not required." OBJECT diffServRandomDropMaxThreshPkts MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropProbMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropWeight MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropSamplingRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServRandomDropStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServQNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServQTable is implemented in read-only mode." OBJECT diffServQNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServQMinRate MIN-ACCESS read-only Baker, et. al. Standards Track [Page 102] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "Write access is not required." OBJECT diffServQMaxRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServQStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServQStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServSchedulerNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServSchedulerTable is implemented in read-only mode." OBJECT diffServSchedulerNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServSchedulerMethod MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServSchedulerMinRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServSchedulerMaxRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServSchedulerStorage MIN-ACCESS read-only Baker, et. al. Standards Track [Page 103] RFC 3289 Differentiated Services MIB May 2002 DESCRIPTION "Write access is not required." OBJECT diffServSchedulerStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServMinRateNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServMinRateTable is implemented in read-only mode." OBJECT diffServMinRatePriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMinRateAbsolute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMinRateRelative MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMinRateStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMinRateStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT diffServMaxRateNextFree MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when diffServMaxrateTable is implemented in read-only mode." Baker, et. al. Standards Track [Page 104] RFC 3289 Differentiated Services MIB May 2002 OBJECT diffServMaxRateAbsolute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMaxRateRelative MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMaxRateThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMaxRateStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT diffServMaxRateStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." ::= { diffServMIBCompliances 2 } diffServMIBDataPathGroup OBJECT-GROUP OBJECTS { diffServDataPathStart, diffServDataPathStorage, diffServDataPathStatus } STATUS current DESCRIPTION "The Data Path Group defines the MIB Objects that describe a functional data path." ::= { diffServMIBGroups 1 } diffServMIBClfrGroup OBJECT-GROUP OBJECTS { diffServClfrNextFree, diffServClfrStorage, diffServClfrStatus } STATUS current DESCRIPTION "The Classifier Group defines the MIB Objects that describe the Baker, et. al. Standards Track [Page 105] RFC 3289 Differentiated Services MIB May 2002 list the starts of individual classifiers." ::= { diffServMIBGroups 2 } diffServMIBClfrElementGroup OBJECT-GROUP OBJECTS { diffServClfrElementNextFree, diffServClfrElementPrecedence, diffServClfrElementNext, diffServClfrElementSpecific, diffServClfrElementStorage, diffServClfrElementStatus } STATUS current DESCRIPTION "The Classifier Element Group defines the MIB Objects that describe the classifier elements that make up a generic classifier." ::= { diffServMIBGroups 3 } diffServMIBMultiFieldClfrGroup OBJECT-GROUP OBJECTS { diffServMultiFieldClfrNextFree, diffServMultiFieldClfrAddrType, diffServMultiFieldClfrDstAddr, diffServMultiFieldClfrDstPrefixLength, diffServMultiFieldClfrFlowId, diffServMultiFieldClfrSrcAddr, diffServMultiFieldClfrSrcPrefixLength, diffServMultiFieldClfrDscp, diffServMultiFieldClfrProtocol, diffServMultiFieldClfrDstL4PortMin, diffServMultiFieldClfrDstL4PortMax, diffServMultiFieldClfrSrcL4PortMin, diffServMultiFieldClfrSrcL4PortMax, diffServMultiFieldClfrStorage, diffServMultiFieldClfrStatus } STATUS current DESCRIPTION "The Multi-field Classifier Group defines the MIB Objects that describe a classifier element for matching on various fields of an IP and upper-layer protocol header." ::= { diffServMIBGroups 4 } diffServMIBMeterGroup OBJECT-GROUP OBJECTS { diffServMeterNextFree, diffServMeterSucceedNext, diffServMeterFailNext, diffServMeterSpecific, diffServMeterStorage, diffServMeterStatus } Baker, et. al. Standards Track [Page 106] RFC 3289 Differentiated Services MIB May 2002 STATUS current DESCRIPTION "The Meter Group defines the objects used in describing a generic meter element." ::= { diffServMIBGroups 5 } diffServMIBTBParamGroup OBJECT-GROUP OBJECTS { diffServTBParamNextFree, diffServTBParamType, diffServTBParamRate, diffServTBParamBurstSize, diffServTBParamInterval, diffServTBParamStorage, diffServTBParamStatus } STATUS current DESCRIPTION "The Token-Bucket Meter Group defines the objects used in describing a token bucket meter element." ::= { diffServMIBGroups 6 } diffServMIBActionGroup OBJECT-GROUP OBJECTS { diffServActionNextFree, diffServActionNext, diffServActionSpecific, diffServActionStorage, diffServActionInterface, diffServActionStatus } STATUS current DESCRIPTION "The Action Group defines the objects used in describing a generic action element." ::= { diffServMIBGroups 7 } diffServMIBDscpMarkActGroup OBJECT-GROUP OBJECTS { diffServDscpMarkActDscp } STATUS current DESCRIPTION "The DSCP Mark Action Group defines the objects used in describing a DSCP Marking Action element." ::= { diffServMIBGroups 8 } diffServMIBCounterGroup OBJECT-GROUP OBJECTS { diffServCountActOctets, diffServCountActPkts, diffServAlgDropOctets, diffServAlgDropPkts, diffServAlgRandomDropOctets, diffServAlgRandomDropPkts, diffServCountActStorage, diffServCountActStatus, diffServCountActNextFree Baker, et. al. Standards Track [Page 107] RFC 3289 Differentiated Services MIB May 2002 } STATUS current DESCRIPTION "A collection of objects providing information specific to packet-oriented network interfaces." ::= { diffServMIBGroups 9 } diffServMIBAlgDropGroup OBJECT-GROUP OBJECTS { diffServAlgDropNextFree, diffServAlgDropType, diffServAlgDropNext, diffServAlgDropQMeasure, diffServAlgDropQThreshold, diffServAlgDropSpecific, diffServAlgDropStorage, diffServAlgDropStatus } STATUS current DESCRIPTION "The Algorithmic Drop Group contains the objects that describe algorithmic dropper operation and configuration." ::= { diffServMIBGroups 10 } diffServMIBRandomDropGroup OBJECT-GROUP OBJECTS { diffServRandomDropNextFree, diffServRandomDropMinThreshBytes, diffServRandomDropMinThreshPkts, diffServRandomDropMaxThreshBytes, diffServRandomDropMaxThreshPkts, diffServRandomDropProbMax, diffServRandomDropWeight, diffServRandomDropSamplingRate, diffServRandomDropStorage, diffServRandomDropStatus } STATUS current DESCRIPTION "The Random Drop Group augments the Algorithmic Drop Group for random dropper operation and configuration." ::= { diffServMIBGroups 11 } diffServMIBQGroup OBJECT-GROUP OBJECTS { diffServQNextFree, diffServQNext, diffServQMinRate, diffServQMaxRate, diffServQStorage, diffServQStatus } STATUS current DESCRIPTION "The Queue Group contains the objects that describe an Baker, et. al. Standards Track [Page 108] RFC 3289 Differentiated Services MIB May 2002 interface's queues." ::= { diffServMIBGroups 12 } diffServMIBSchedulerGroup OBJECT-GROUP OBJECTS { diffServSchedulerNextFree, diffServSchedulerNext, diffServSchedulerMethod, diffServSchedulerMinRate, diffServSchedulerMaxRate, diffServSchedulerStorage, diffServSchedulerStatus } STATUS current DESCRIPTION "The Scheduler Group contains the objects that describe packet schedulers on interfaces." ::= { diffServMIBGroups 13 } diffServMIBMinRateGroup OBJECT-GROUP OBJECTS { diffServMinRateNextFree, diffServMinRatePriority, diffServMinRateAbsolute, diffServMinRateRelative, diffServMinRateStorage, diffServMinRateStatus } STATUS current DESCRIPTION "The Minimum Rate Parameter Group contains the objects that describe packet schedulers' minimum rate or priority guarantees." ::= { diffServMIBGroups 14 } diffServMIBMaxRateGroup OBJECT-GROUP OBJECTS { diffServMaxRateNextFree, diffServMaxRateAbsolute, diffServMaxRateRelative, diffServMaxRateThreshold, diffServMaxRateStorage, diffServMaxRateStatus } STATUS current DESCRIPTION "The Maximum Rate Parameter Group contains the objects that describe packet schedulers' maximum rate guarantees." ::= { diffServMIBGroups 15 } END Baker, et. al. Standards Track [Page 109] RFC 3289 Differentiated Services MIB May 2002 7. Acknowledgments This MIB builds on all the work that has gone into the Informal Management Model for Differentiated Services Routers, Differentiated Services PIB, and Differentiated Services Policy MIB (SNMPCONF WG). It has been developed with the active involvement of many people, but most notably Yoram Bernet, Steve Blake, Brian Carpenter, Dave Durham, Michael Fine, Victor Firoiu, Jeremy Greene, Dan Grossman, Roch Guerin, Scott Hahn, Joel Halpern, Van Jacobsen, Keith McCloghrie, Bob Moore, Kathleen Nichols, Ping Pan, Nabil Seddigh, John Seligson, and Walter Weiss. Juergen Schoenwaelder, Dave Perkins, Frank Strauss, Harrie Hazewinkel, and Bert Wijnen are especially to be noted for review comments on the structure and usage of the MIB for network management purposes, and its compliance with SMIv2. 8. Security Considerations It is clear that this MIB is potentially useful for configuration. Anything that can be configured can be misconfigured, with potentially disastrous effects. At this writing, no security holes have been identified beyond those that SNMP Security is itself intended to address. These relate primarily to controlled access to sensitive information and the ability to configure a device - or which might result from operator error, which is beyond the scope of any security architecture. There are many read-write and read-create management objects defined in this MIB. Such objects are often sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The use of SNMP Version 3 is recommended over prior versions for configuration control as its security model is improved. There are a number of managed objects in this MIB that may contain information that may be sensitive from a business perspective, in that they may represent a customer's service contract or the filters that the service provider chooses to apply to a customer's ingress or egress traffic. There are no objects which are sensitive in their own right, such as passwords or monetary amounts. Baker, et. al. Standards Track [Page 110] RFC 3289 Differentiated Services MIB May 2002 It may be important to even control GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [RFC 2574] and the View-based Access Control Model [RFC 2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Baker, et. al. Standards Track [Page 111] RFC 3289 Differentiated Services MIB May 2002 10. References [RFC 2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC 1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP- based Internets", STD 16, RFC 1155, May 1990. [RFC 1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC 1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC 2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC 2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC 2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC 1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC 1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC 1906] 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. [RFC 2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Baker, et. al. Standards Track [Page 112] RFC 3289 Differentiated Services MIB May 2002 [RFC 2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC 1905] 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. [RFC 2573] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [RFC 2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC 2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC 2119] Bradner, S., "Key words to use in the RFCs", BCP 14, RFC 2119, March 1997. [ACTQMGMT] V. Firoiu, M. Borden, "A Study of Active Queue Management for Congestion Control", March 2000, In IEEE Infocom 2000, http://www.ieee- infocom.org/2000/papers/405.pdf [AQMROUTER] V. Misra, W. Gong, D. Towsley, "Fluid-based analysis of a network of AQM routers supporting TCP flows with an application to RED", In SIGCOMM 2000,http://www.acm.org/sigcomm/sigcomm2000/conf/ paper/sigcomm2000-4-3.ps.gz [AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [DSARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. Baker, et. al. Standards Track [Page 113] RFC 3289 Differentiated Services MIB May 2002 [DSPIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S. and A. Smith, "Differentiated Services Quality of Service Policy Information Base", Work in Progress. [DSTERMS] Grossman, D., "New Terminology for Differentiated Services", RFC 3260, April 2002. [EF-PHB] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 3246, March 2002. [IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2863, June 2000. [INETADDRESS] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses.", RFC 3291, May 2002. [INTSERVMIB] Baker, F., Krawczyk, J. and A. Sastry, "Integrated Services Management Information Base using SMIv2", RFC 2213, September 1997. [MODEL] Bernet, Y., Blake, S., Smith, A. and D. Grossman, "An Informal Management Model for Differentiated Services Routers", Work in Progress. [RED93] "Random Early Detection", 1993. [srTCM] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [trTCM] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999. [TSWTCM] Fang, W., Seddigh, N. and B. Nandy, "A Time Sliding Window Three Color Marker (TSWTCM)", RFC 2859, June 2000. [SHAPER] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper for Differentiated Services", RFC 2963, October 2000. Baker, et. al. Standards Track [Page 114] RFC 3289 Differentiated Services MIB May 2002 11. Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 EMail: fred@cisco.com Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 EMail: khchan@nortelnetworks.com Andrew Smith Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089, PRC EMail: ah_smith@acm.org Baker, et. al. Standards Track [Page 115] RFC 3289 Differentiated Services MIB May 2002 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Baker, et. al. Standards Track [Page 116] snmp-mibs-downloader-1.1/mibrfcs/rfc3295.txt0000644000000000000000000027243411402176071015600 0ustar Network Working Group H. Sjostrand Request for Comments: 3295 ipUnplugged Category: Standards Track J. Buerkle Nortel Networks B. Srinivasan Cplane June 2002 Definitions of Managed Objects for the General Switch Management Protocol (GSMP) 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). Table of Contents 1. Introduction............................................. 2 2. The SNMP Management Framework............................ 2 3. Structure of the MIB..................................... 3 3.1 Overview............................................. 3 3.2 Scope................................................ 4 3.3 MIB guideline........................................ 4 3.4 MIB groups........................................... 5 3.4.1 GSMP Switch Controller group................... 5 3.4.2 GSMP Switch group.............................. 6 3.4.3 GSMP Encapsulation groups...................... 6 3.4.4 GSMP General group............................. 7 3.4.5 The GSMP Notifications Group................... 7 3.5 Textual Conventions................................. 8 4. GSMP MIB Definitions.................................... 9 5. Acknowledgments......................................... 42 Sjostrand, et. al. Standards Track [Page 1] RFC 3295 GSMP MIB June 2002 6. References.............................................. 42 7. Intellectual Property Rights............................ 44 8. Security Considerations................................. 45 9. Authors' Addresses...................................... 46 10. Full Copyright Statement................................ 47 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: * An overall architecture, described in RFC 2571 [RFC2571]. * Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212], and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579], and RFC 2580[RFC2580]. * Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [RFC1906], RFC 2572 [RFC2572], and RFC 2574 [RFC2574]. * Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats are described in STD 15, RFC 1157 [RFC1157]. A second set of operations and associated PDU formats are described in 1905 [RFC1905]. Sjostrand, et. al. Standards Track [Page 2] RFC 3295 GSMP MIB June 2002 * A set of fundamental applications described in RFC 2573 [RFC2573], and the view-based access control mechanism is described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Structure of the MIB This memo defines a portion of the Management Information Base (MIB) for the use with network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP), as defined in [RFC3292]. 3.1 Overview The General Switch Management Protocol (GSMP) is a general purpose protocol to control a label switch. GSMP allows a controller to establish and release connections across the switch, to manage switch ports and to request configuration information or statistics. It also allows the switch to inform the controller of asynchronous events such as a link going down. The GSMP protocol is asymmetric, the controller being the master and the switch being the slave. Multiple switches may be controlled by a single controller using multiple instantiations of the protocol over separate control connections. Also a switch may be controlled by more than one controller by using the technique of partitioning. Each instance of a (switch controller, switch partition) adjacency is a session between one switch controller entity and one switch entity. The MIB provides objects to configure/setup these entities to form the GSMP sessions. It also provide objects to monitor these GSMP sessions. Sjostrand, et. al. Standards Track [Page 3] RFC 3295 GSMP MIB June 2002 3.2 Scope The GSMP mib is a protocol mib. It contains objects to configure, monitor, and maintain the GSMP protocol entity. It does not provide any information learned via the protocol, such as "all ports config" information. The relationships between virtual entities, such as Virtual Switch Entities, and "physical" entities, such as Switch Entities, falls outside of the management of GSMP. This also applies for the management of switch partitions. So this is excluded from the GSMP mib. It is possible to configure which, and how many Switch Controllers are controlling one Switch since every potential session with the switch has to be represented with an Switch entity. It is, however, not possible to define that one Switch Controller shouldn't allow other Switch controllers to control the same switch or partition on the switch. It is assumed that there are mechanisms that synchronise controllers and the configuration of them. This is outside the scope of this mib. 3.3 MIB guideline Two tables are used to configure potential GSMP sessions depending if you are acting as a GSMP switch controller or a GSMP switch. Each row in these tables initiates a GSMP session. The entity ID is a 48-bit name that is unique within the operational context of the device. A 48-bit IEEE 802 MAC address, if available, MAY be used for the entity ID. If the Ethernet encapsulation is used, the entity ID MUST be the IEEE 802 MAC address of the interface on which the GSMP session is to be setup. First, the encapsulation of the potential GSMP session shall be defined. If ATM is used, a row in the gsmpAtmEncapTable has to be created with the index set to the entity ID. The specified resources should be allocated to GSMP. If TCP/IP is used, a row in the gsmpTcpIpEncapTable has to be created with the index set to the entity ID. The specified port shall be allocated to GSMP. No special action is needed if ethernet encapsulation is used. Then the entity information shall be defined. To create a Switch Entity, an entry in the gsmpSwitchTable is created with the index set to the entity ID. To create a Switch Controller Entity, an entry in the gsmpControllerTable is created with the index set to the entity ID. Sjostrand, et. al. Standards Track [Page 4] RFC 3295 GSMP MIB June 2002 When the row status of the GsmpControllerEntry or GsmpSwitchEntry is set to active (e.g., in the case with ATM or TCP/IP there are active rows with a corresponding entity ID), the adjacency protocol of GSMP is started. Another table, the gsmpSessionTable, shows the actual sessions that are established or are in the process of being established. Each row represents a specific session between an Entity and a peer. This table carries information about the peer, the session, and parameters that were negotiated by the adjacency procedures. The gsmpSessionTable also contains statistical information regarding the session. This creation order SHOULD be used by all GSMP managers. This is to avoid clash situations in multiple SNMP manager scenarios where different managers may create competing entries in the different tables. Entities may very well be configured by other means than SNMP, e.g., the cli command. Such configured entities SHOULD be represented as entries in the tables of this mib and SHOULD be possible to query, and MAY be possible to alter with SNMP. 3.4 MIB groups 3.4.1 GSMP Switch Controller group The controller group is used to configure a potential GSMP session on a Switch Controller. A row in the gsmpControllerTable is created for each such session. If ATM or TCP/IP encapsulation is used, a corresponding row has to be created in these tables before the session adjacency protocol is initiated. If ATM or TCP/IP is used, encapsulation data is defined in the corresponding encapsulation tables. If ethernet is used, the MAC address of the interface defined for the session is set by the Controller ID object. The adjacency parameters are defined; such as - Max supported GSMP version. - Time between the periodic adjacency messages. - Controller local port number and instance number. - Whether partitions are being used and the partition ID for the specific partitions this controller is concerned with if partitions are used. - The resynchronisation strategy for the session is specified. Sjostrand, et. al. Standards Track [Page 5] RFC 3295 GSMP MIB June 2002 The notification mapping is set to specify for with events the corresponding SNMP notifications are sent. 3.4.2 GSMP Switch group The switch group is used to configure a potential GSMP session on a Switch. A row in the gsmpSwitchTable is created for each such session. If ATM or TCP/IP encapsulation is used, a corresponding row has to be created in these tables before the session adjacency protocol is initiated. If ATM or TCP/IP is used, encapsulation data is defined in the corresponding encapsulation tables. If ethernet is used the MAC address of the interface defined for the session is set by the Switch ID object. The adjacency parameters are defined; such as - Max supported GSMP version - Time between the periodic adjacency messages - Switch Name, local port number, and instance number. - Whether partitions are being used and the partition ID for this specific partition if partitions are used. - The switch type could be set. - The suggested maximum window size for unacknowledged request messages. Also, a notification mapping is set to specify for with events the corresponding SNMP notifications are sent. 3.4.3 GSMP Encapsulation groups The ATM Encapsulation Table and the TCP/IP Encapsulation Table provides a way to configure information that are encapsulation specific. The encapsulation data is further specified in [RFC3293]. If ATM encapsulation is used, the interface and the virtual channel are specified. If TCP/IP is used, the IP address and the port number are specified. No special config data needed if Ethernet encapsulation is used. This mib MAY be extended with new, standard or proprietary, GSMP encapsulation types. If a new encapsulation type needs to be added, it SHOULD be done in the form of a new table with the entity ID as an index. A row in that encapsulation table SHOULD be created before any row in a GSMP entity table is created that is using this new GSMP encapsulation. Sjostrand, et. al. Standards Track [Page 6] RFC 3295 GSMP MIB June 2002 3.4.4 GSMP General group The GSMP session table provides a way to monitor and maintain GSMP sessions. The session is defined by a Switch Controller Entity and Switch Entity pair. 3.4.5 The GSMP Notifications Group The GSMP Notification Group defines notifications for GSMP entities. These notifications provide a mechanism for a GSMP device to inform the management station of status changes. Also a notification is defined for each type of GSMP events. The group of notifications consists of the following notifications: - gsmpSessionDown This notification is generated when a session is terminating and also reports the final accounting statistics of the session. - gsmpSessionUp This notification is generated when a new session is established. - gsmpSendFailureInd This notification is generated when a message with a failure indication was sent. This means that this notification identifies a change to the gsmpSessionStatFailureInds object in a row of the gsmpSessionTable. - gsmpReceivedFailureInd This notification is generated when a message with a failure indication received. This means that this notification identifies a change to the gsmpSessionStatReceivedFailures object in a row of the gsmpSessionTable. - gsmpPortUpEvent This notification is generated when a Port Up Event is either received or sent. Sjostrand, et. al. Standards Track [Page 7] RFC 3295 GSMP MIB June 2002 - gsmpPortDownEvent This notification is generated when a Port Down Event is either received or sent. - gsmpInvalidLabelEvent This notification is generated when an Invalid Label Event is either received or sent. - gsmpNewPortEvent This notification is generated when New Port Event either is received or sent. - gsmpDeadPortEvent This notification is generated when a Dead Port Event is either received or sent. - gsmpAdjacencyUpdateEvent This notification is generated when an Adjacency Update Event is either received or sent. To disable or enable the sending of each notification, the bits in the bitmap are set to 0 or 1 in the Notification mapping objects in the Controller Entitiy or Switch Entity tables. The GSMP notification map capability should not be seen as a duplication of the filter mechanism in the snmp notification originator application [RFC2573], but as a compliment, to configure the relation between GSMP events and the SNMP notifications already in the GSMP agent. SNMP notifications and GSMP events operate sometimes on a different timescale, and it may in some applications be devastating for a SNMP application to receive events for each GSMP events. E.g. the invalid label event in a ATM switch scenario may cause mass SNMP notification flooding if mapped to a SNMP notification. 3.5 Textual Conventions The datatypes GsmpNameType, GsmpLabelType, GsmpVersion, GsmpPartitionType, and GsmpPartitionIdType are used as textual conventions in this document. These textual conventions are used for the convenience of humans reading the MIB. Objects defined using these conventions are always encoded by means of the rules that define their primitive type. However, the textual conventions have Sjostrand, et. al. Standards Track [Page 8] RFC 3295 GSMP MIB June 2002 special semantics associated with them. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers. 4. GSMP MIB Definitions GSMP-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, Unsigned32, Integer32, mib-2 FROM SNMPv2-SMI -- [RFC2578] RowStatus, TruthValue, TimeStamp, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] ZeroBasedCounter32 FROM RMON2-MIB -- [RFC2021] InterfaceIndex FROM IF-MIB -- [RFC2863] AtmVcIdentifier, AtmVpIdentifier FROM ATM-TC-MIB -- [RFC2514] InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB ; -- [RFC3291] gsmpMIB MODULE-IDENTITY LAST-UPDATED "200205310000Z" -- May 31, 2002 ORGANIZATION "General Switch Management Protocol (gsmp) Working Group, IETF" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/gsmp-charter.html WG-email: gsmp@ietf.org Subscribe: gsmp-request@ietf.org Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/gsmp/ WG Chair: Avri Doria Email: avri@acm.org WG Chair: Kenneth Sundell Email: ksundell@nortelnetworks.com Editor: Hans Sjostrand Email: hans@ipunplugged.com Sjostrand, et. al. Standards Track [Page 9] RFC 3295 GSMP MIB June 2002 Editor: Joachim Buerkle Email: joachim.buerkle@nortelnetworks.com Editor: Balaji Srinivasan Email: balaji@cplane.com" DESCRIPTION "This MIB contains managed object definitions for the General Switch Management Protocol, GSMP, version 3" REVISION "200205310000Z" DESCRIPTION "Initial Version, published as RFC 3295" ::= { mib-2 98 } gsmpNotifications OBJECT IDENTIFIER ::= { gsmpMIB 0 } gsmpObjects OBJECT IDENTIFIER ::= { gsmpMIB 1 } gsmpNotificationsObjects OBJECT IDENTIFIER ::= { gsmpMIB 2 } gsmpConformance OBJECT IDENTIFIER ::= { gsmpMIB 3 } --************************************************************** -- GSMP Textual Conventions --************************************************************** GsmpNameType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Name is a 48-bit quantity. A 48-bit IEEE 802 MAC address, if available, may be used." SYNTAX OCTET STRING (SIZE(6)) GsmpPartitionType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Defining if partitions are used and how the partition id is negotiated. " SYNTAX INTEGER { noPartition(1), fixedPartitionRequest(2), fixedPartitionAssigned(3) } GsmpPartitionIdType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A 8-bit quantity. The format of the Partition ID is not defined in GSMP. If desired, the Partition ID can be divided into multiple sub-identifiers within a single Sjostrand, et. al. Standards Track [Page 10] RFC 3295 GSMP MIB June 2002 partition. For example: the Partition ID could be subdivided into a 6-bit partition number and a 2-bit sub-identifier which would allow a switch to support 64 partitions with 4 available IDs per partition." SYNTAX OCTET STRING (SIZE(1)) GsmpVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The version numbers defined for the GSMP protocol. The version numbers used are defined in the specifications of the respective protocol, 1 - GSMPv1.1 [RFC1987] 2 - GSMPv2.0 [RFC2397] 3 - GSMPv3 [RFC3292] Other numbers may be defined for other versions of the GSMP protocol." SYNTAX Unsigned32 GsmpLabelType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The label is structured as a TLV, a tuple, consisting of a Type, a Length, and a Value. The structure is defined in [RFC 3292]. The label TLV is encoded as a 2 octet type field, followed by a 2 octet Length field, followed by a variable length Value field. Additionally, a label field can be composed of many stacked labels that together constitute the label." SYNTAX OCTET STRING --************************************************************** -- GSMP Entity Objects --************************************************************** -- -- Switch Controller Entity table -- gsmpControllerTable OBJECT-TYPE SYNTAX SEQUENCE OF GsmpControllerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the Switch Controller Entities. An entry in this table needs to be configured (created) before a GSMP session might be started." ::= { gsmpObjects 1 } Sjostrand, et. al. Standards Track [Page 11] RFC 3295 GSMP MIB June 2002 gsmpControllerEntry OBJECT-TYPE SYNTAX GsmpControllerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the data for a specific Switch Controller Entity. If partitions are used, one entity corresponds to one specific switch partition. Depending of the encapsulation used, a corresponding row in the gsmpAtmEncapTable or the gsmpTcpIpEncapTable may have been created." INDEX { gsmpControllerEntityId } ::= { gsmpControllerTable 1 } GsmpControllerEntry ::= SEQUENCE { gsmpControllerEntityId GsmpNameType, gsmpControllerMaxVersion GsmpVersion, gsmpControllerTimer Unsigned32, gsmpControllerPort Unsigned32, gsmpControllerInstance Unsigned32, gsmpControllerPartitionType GsmpPartitionType, gsmpControllerPartitionId GsmpPartitionIdType, gsmpControllerDoResync TruthValue, gsmpControllerNotificationMap BITS, gsmpControllerSessionState INTEGER, gsmpControllerStorageType StorageType, gsmpControllerRowStatus RowStatus } gsmpControllerEntityId OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Switch Controller Entity Id is unique within the operational context of the device." ::= { gsmpControllerEntry 1 } gsmpControllerMaxVersion OBJECT-TYPE SYNTAX GsmpVersion MAX-ACCESS read-create STATUS current DESCRIPTION "The max version number of the GSMP protocol being used in this session. The version is negotiated by the adjacency protocol." DEFVAL { 3 } Sjostrand, et. al. Standards Track [Page 12] RFC 3295 GSMP MIB June 2002 ::= { gsmpControllerEntry 2 } gsmpControllerTimer OBJECT-TYPE SYNTAX Unsigned32(1..255) UNITS "100ms" MAX-ACCESS read-create STATUS current DESCRIPTION "The timer specifies the nominal time between periodic adjacency protocol messages. It is a constant for the duration of a GSMP session. The timer is specified in units of 100ms." DEFVAL { 10 } ::= { gsmpControllerEntry 3 } gsmpControllerPort OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The local port number for the Switch Controller Entity." REFERENCE "General Switch Management Protocol V3: Section 3.1.2" ::= { gsmpControllerEntry 4 } gsmpControllerInstance OBJECT-TYPE SYNTAX Unsigned32(1..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The instance number for the Switch Controller Entity. The Instance number is a 24-bit number that should be guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number. " ::= { gsmpControllerEntry 5 } gsmpControllerPartitionType OBJECT-TYPE SYNTAX GsmpPartitionType MAX-ACCESS read-create STATUS current DESCRIPTION "A controller can request the specific partition identifier to the session by setting the Partition Type to fixedPartitionRequest(2). A controller can let the switch decide whether it wants to assign a fixed partition ID or Sjostrand, et. al. Standards Track [Page 13] RFC 3295 GSMP MIB June 2002 not, by setting the Partition Type to noPartition(1)." ::= { gsmpControllerEntry 6 } gsmpControllerPartitionId OBJECT-TYPE SYNTAX GsmpPartitionIdType MAX-ACCESS read-create STATUS current DESCRIPTION "The Id for the specific switch partition that this Switch Controller is concerned with. If partitions are not used or if the controller lets the switch assigns Partition ID, i.e Partition Type = noPartition(1), then this object is undefined." ::= { gsmpControllerEntry 7 } gsmpControllerDoResync OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies whether the controller should resynchronise or reset in case of loss of synchronisation. If this object is set to true then the Controller should resync with PFLAG=2 (recovered adjacency)." DEFVAL { true } ::= { gsmpControllerEntry 8 } gsmpControllerNotificationMap OBJECT-TYPE SYNTAX BITS { sessionDown(0), sessionUp(1), sendFailureIndication(2), receivedFailureIndication(3), portUpEvent(4), portDownEvent(5), invalidLabelEvent(6), newPortEvent(7), deadPortEvent(8), adjacencyUpdateEvent(9) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bitmap defines whether a corresponding SNMP notification should be sent if a GSMP event is received by the Switch Controller. If the bit is set to 1 a notification should be sent. The handling and filtering of the SNMP notifications are then further specified in the Sjostrand, et. al. Standards Track [Page 14] RFC 3295 GSMP MIB June 2002 SNMP notification originator application. " DEFVAL {{ sessionDown, sessionUp, sendFailureIndication, receivedFailureIndication }} ::= { gsmpControllerEntry 9 } gsmpControllerSessionState OBJECT-TYPE SYNTAX INTEGER { null(1), synsent(2), synrcvd(3), estab(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state for the existing or potential session that this entity is concerned with. The NULL state is returned if the proper encapsulation data is not yet configured, if the row is not in active status or if the session is in NULL state as defined in the GSMP specification." ::= { gsmpControllerEntry 10} gsmpControllerStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this controller entity. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { gsmpControllerEntry 11 } gsmpControllerRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention. While the row is in active state it's not possible to modify the value of any object for that row except the gsmpControllerNotificationMap and the gsmpControllerRowStatus objects." ::= { gsmpControllerEntry 12 } Sjostrand, et. al. Standards Track [Page 15] RFC 3295 GSMP MIB June 2002 -- -- Switch Entity table -- gsmpSwitchTable OBJECT-TYPE SYNTAX SEQUENCE OF GsmpSwitchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the Switch Entities. An entry in this table needs to be configured (created) before a GSMP session might be started." ::= { gsmpObjects 2 } gsmpSwitchEntry OBJECT-TYPE SYNTAX GsmpSwitchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the data for a specific Switch Entity. If partitions are used, one entity corresponds to one specific switch partition. Depending of the encapsulation used, a corresponding row in the gsmpAtmEncapTable or the gsmpTcpIpEncapTable may have been created." INDEX { gsmpSwitchEntityId } ::= { gsmpSwitchTable 1 } GsmpSwitchEntry ::= SEQUENCE { gsmpSwitchEntityId GsmpNameType, gsmpSwitchMaxVersion GsmpVersion, gsmpSwitchTimer Unsigned32, gsmpSwitchName GsmpNameType, gsmpSwitchPort Unsigned32, gsmpSwitchInstance Unsigned32, gsmpSwitchPartitionType GsmpPartitionType, gsmpSwitchPartitionId GsmpPartitionIdType, gsmpSwitchNotificationMap BITS, gsmpSwitchSwitchType OCTET STRING, gsmpSwitchWindowSize Unsigned32, gsmpSwitchSessionState INTEGER, gsmpSwitchStorageType StorageType, gsmpSwitchRowStatus RowStatus } gsmpSwitchEntityId OBJECT-TYPE SYNTAX GsmpNameType Sjostrand, et. al. Standards Track [Page 16] RFC 3295 GSMP MIB June 2002 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Switch Entity Id is unique within the operational context of the device. " ::= { gsmpSwitchEntry 1 } gsmpSwitchMaxVersion OBJECT-TYPE SYNTAX GsmpVersion MAX-ACCESS read-create STATUS current DESCRIPTION "The max version number of the GSMP protocol being supported by this Switch. The version is negotiated by the adjacency protocol." DEFVAL { 3 } ::= { gsmpSwitchEntry 2 } gsmpSwitchTimer OBJECT-TYPE SYNTAX Unsigned32(1..255) UNITS "100ms" MAX-ACCESS read-create STATUS current DESCRIPTION "The timer specifies the nominal time between periodic adjacency protocol messages. It is a constant for the duration of a GSMP session. The timer is specified in units of 100ms." DEFVAL { 10 } ::= { gsmpSwitchEntry 3 } gsmpSwitchName OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the Switch. The first three octets must be an Organisationally Unique Identifier (OUI) that identifies the manufacturer of the Switch. This is by default set to the same value as the gsmpSwitchId object if not separately specified. " ::= {gsmpSwitchEntry 4 } gsmpSwitchPort OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION Sjostrand, et. al. Standards Track [Page 17] RFC 3295 GSMP MIB June 2002 "The local port number for this Switch Entity." REFERENCE "General Switch Management Protocol V3: Section 3.1.2" ::= { gsmpSwitchEntry 5 } gsmpSwitchInstance OBJECT-TYPE SYNTAX Unsigned32(1..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The instance number for the Switch Entity. The Instance number is a 24-bit number that should be guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number." ::= { gsmpSwitchEntry 6 } gsmpSwitchPartitionType OBJECT-TYPE SYNTAX GsmpPartitionType MAX-ACCESS read-create STATUS current DESCRIPTION "A switch can assign the specific partition identifier to the session by setting the Partition Type to fixedPartitionAssigned(3). A switch can specify that no partitions are handled in the session by setting the Partition Type to noPartition(1)." ::= { gsmpSwitchEntry 7 } gsmpSwitchPartitionId OBJECT-TYPE SYNTAX GsmpPartitionIdType MAX-ACCESS read-create STATUS current DESCRIPTION "The Id for this specific switch partition that the switch entity represents. If partitions are not used, i.e. Partition Type = noPartition(1), then this object is undefined." ::= { gsmpSwitchEntry 8 } gsmpSwitchNotificationMap OBJECT-TYPE SYNTAX BITS { sessionDown(0), sessionUp(1), sendFailureIndication(2), receivedFailureIndication(3), portUpEvent(4), Sjostrand, et. al. Standards Track [Page 18] RFC 3295 GSMP MIB June 2002 portDownEvent(5), invalidLabelEvent(6), newPortEvent(7), deadPortEvent(8), adjacencyUpdateEvent(9) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bitmap defines whether a corresponding SNMP notification should be sent if an GSMP event is sent by the Switch Entity. If the bit is set to 1 a notification should be sent. The handling and filtering of the SNMP notifications are then further specified in the SNMP notification originator application. " DEFVAL {{ sessionDown, sessionUp, sendFailureIndication, receivedFailureIndication }} ::= { gsmpSwitchEntry 9 } gsmpSwitchSwitchType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-create STATUS current DESCRIPTION "A 16-bit field allocated by the manufacturer of the switch. The Switch Type identifies the product. When the Switch Type is combined with the OUI from the Switch Name the product is uniquely identified. " ::= { gsmpSwitchEntry 10 } gsmpSwitchWindowSize OBJECT-TYPE SYNTAX Unsigned32(1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of unacknowledged request messages that may be transmitted by the controller without the possibility of loss. This field is used to prevent request messages from being lost in the switch because of overflow in the receive buffer. The field is a hint to the controller." ::= { gsmpSwitchEntry 11 } gsmpSwitchSessionState OBJECT-TYPE SYNTAX INTEGER { null(1), synsent(2), Sjostrand, et. al. Standards Track [Page 19] RFC 3295 GSMP MIB June 2002 synrcvd(3), estab(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state for the existing or potential session that this entity is concerned with. The NULL state is returned if the proper encapsulation data is not yet configured, if the row is not in active status or if the session is in NULL state as defined in the GSMP specification." ::= { gsmpSwitchEntry 12} gsmpSwitchStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this switch entity. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { gsmpSwitchEntry 13 } gsmpSwitchRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention. While the row is in active state it's not possible to modify the value of any object for that row except the gsmpSwitchNotificationMap and the gsmpSwitchRowStatus objects." ::= { gsmpSwitchEntry 14 } --************************************************************** -- GSMP Encapsulation Objects --************************************************************** -- -- GSMP ATM Encapsulation Table -- gsmpAtmEncapTable OBJECT-TYPE Sjostrand, et. al. Standards Track [Page 20] RFC 3295 GSMP MIB June 2002 SYNTAX SEQUENCE OF GsmpAtmEncapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the atm encapsulation data for the Controller or Switch that uses atm aal5 as encapsulation. " ::= { gsmpObjects 3 } gsmpAtmEncapEntry OBJECT-TYPE SYNTAX GsmpAtmEncapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the encapsulation data for a specific Switch Controller entity or Switch entity." INDEX { gsmpAtmEncapEntityId } ::= { gsmpAtmEncapTable 1 } GsmpAtmEncapEntry ::= SEQUENCE { gsmpAtmEncapEntityId GsmpNameType, gsmpAtmEncapIfIndex InterfaceIndex, gsmpAtmEncapVpi AtmVpIdentifier, gsmpAtmEncapVci AtmVcIdentifier, gsmpAtmEncapStorageType StorageType, gsmpAtmEncapRowStatus RowStatus } gsmpAtmEncapEntityId OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Controller Id or Switch Id that is unique within the operational context of the device. " ::= { gsmpAtmEncapEntry 1 } gsmpAtmEncapIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The interface index for the virtual channel over which the GSMP session is established, i.e., the GSMP control channel for LLC/SNAP encapsulated GSMP messages on an ATM data link layer." ::= { gsmpAtmEncapEntry 2 } Sjostrand, et. al. Standards Track [Page 21] RFC 3295 GSMP MIB June 2002 gsmpAtmEncapVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION " The VPI value for the virtual channel over which the GSMP session is established, i.e., the GSMP control channel for LLC/SNAP encapsulated GSMP messages on an ATM data link layer." DEFVAL { 0 } ::= { gsmpAtmEncapEntry 3 } gsmpAtmEncapVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION " The VCI value for the virtual channel over which the GSMP session is established, i.e., the GSMP control channel for LLC/SNAP encapsulated GSMP messages on an ATM data link layer." DEFVAL { 15 } ::= { gsmpAtmEncapEntry 4 } gsmpAtmEncapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this entry. It should have the same value as the StorageType in the referring Switch Controller entity or Switch entity." DEFVAL { nonVolatile } ::= { gsmpAtmEncapEntry 5 } gsmpAtmEncapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention. While the row is in active state it's not possible to modify the value of any object for that row except the gsmpAtmEncapRowStatus object." ::= { gsmpAtmEncapEntry 6 } Sjostrand, et. al. Standards Track [Page 22] RFC 3295 GSMP MIB June 2002 -- -- GSMP TCP/IP Encapsulation Table -- gsmpTcpIpEncapTable OBJECT-TYPE SYNTAX SEQUENCE OF GsmpTcpIpEncapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the encapsulation data for the Controller or Switch that uses TCP/IP as encapsulation." ::= { gsmpObjects 4 } gsmpTcpIpEncapEntry OBJECT-TYPE SYNTAX GsmpTcpIpEncapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the encapsulation data for a specific Switch Controller entity or Switch entity." INDEX { gsmpTcpIpEncapEntityId } ::= { gsmpTcpIpEncapTable 1 } GsmpTcpIpEncapEntry ::= SEQUENCE { gsmpTcpIpEncapEntityId GsmpNameType, gsmpTcpIpEncapAddressType InetAddressType, gsmpTcpIpEncapAddress InetAddress, gsmpTcpIpEncapPortNumber InetPortNumber, gsmpTcpIpEncapStorageType StorageType, gsmpTcpIpEncapRowStatus RowStatus } gsmpTcpIpEncapEntityId OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Controller or Switch Id is unique within the operational context of the device. " ::= { gsmpTcpIpEncapEntry 1 } gsmpTcpIpEncapAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION Sjostrand, et. al. Standards Track [Page 23] RFC 3295 GSMP MIB June 2002 "The type of address in gsmpTcpIpEncapAddress." ::= { gsmpTcpIpEncapEntry 2 } gsmpTcpIpEncapAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IPv4 or IPv6 address used for the GSMP session peer." ::= { gsmpTcpIpEncapEntry 3 } gsmpTcpIpEncapPortNumber OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The TCP port number used for the TCP session establishment to the GSMP peer." DEFVAL { 6068 } ::= { gsmpTcpIpEncapEntry 4 } gsmpTcpIpEncapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this entry. It should have the same value as the StorageType in the referring Switch Controller entity or Switch entity." DEFVAL { nonVolatile } ::= { gsmpTcpIpEncapEntry 5 } gsmpTcpIpEncapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "An object that allows entries in this table to be created and deleted using the RowStatus convention. While the row is in active state it's not possible to modify the value of any object for that row except the gsmpTcpIpEncapRowStatus object." ::= { gsmpTcpIpEncapEntry 6 } --************************************************************** -- GSMP Session Objects Sjostrand, et. al. Standards Track [Page 24] RFC 3295 GSMP MIB June 2002 --************************************************************** -- -- GSMP Session table -- gsmpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF GsmpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the sessions between Controller and Switch pairs. " ::= { gsmpObjects 5 } gsmpSessionEntry OBJECT-TYPE SYNTAX GsmpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table showing the session data for a specific Controller and Switch pair. Also, statistics for this specific session is shown." INDEX { gsmpSessionThisSideId, gsmpSessionFarSideId } ::= { gsmpSessionTable 1 } GsmpSessionEntry ::= SEQUENCE { gsmpSessionThisSideId GsmpNameType, gsmpSessionFarSideId GsmpNameType, gsmpSessionVersion GsmpVersion, gsmpSessionTimer Integer32, gsmpSessionPartitionId GsmpPartitionIdType, gsmpSessionAdjacencyCount Unsigned32, gsmpSessionFarSideName GsmpNameType, gsmpSessionFarSidePort Unsigned32, gsmpSessionFarSideInstance Unsigned32, gsmpSessionLastFailureCode Unsigned32, gsmpSessionDiscontinuityTime TimeStamp, gsmpSessionStartUptime TimeStamp, gsmpSessionStatSentMessages ZeroBasedCounter32, gsmpSessionStatFailureInds ZeroBasedCounter32, gsmpSessionStatReceivedMessages ZeroBasedCounter32, gsmpSessionStatReceivedFailures ZeroBasedCounter32, gsmpSessionStatPortUpEvents ZeroBasedCounter32, gsmpSessionStatPortDownEvents ZeroBasedCounter32, gsmpSessionStatInvLabelEvents ZeroBasedCounter32, gsmpSessionStatNewPortEvents ZeroBasedCounter32, Sjostrand, et. al. Standards Track [Page 25] RFC 3295 GSMP MIB June 2002 gsmpSessionStatDeadPortEvents ZeroBasedCounter32, gsmpSessionStatAdjUpdateEvents ZeroBasedCounter32 } gsmpSessionThisSideId OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This side ID uniquely identifies the entity that this session relates to within the operational context of the device. " ::= { gsmpSessionEntry 1 } gsmpSessionFarSideId OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Far side ID uniquely identifies the entity that this session is established against. " ::= { gsmpSessionEntry 2 } gsmpSessionVersion OBJECT-TYPE SYNTAX GsmpVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the GSMP protocol being used in this session. The version is the result of the negotiation by the adjacency protocol." ::= { gsmpSessionEntry 3 } gsmpSessionTimer OBJECT-TYPE SYNTAX Integer32 UNITS "100ms" MAX-ACCESS read-only STATUS current DESCRIPTION "The timer specifies the time remaining until the adjacency timer expires. The object could take negative values since if no valid GSMP messages are received in any period of time in excess of three times the value of the Timer negotiated by the adjacency protocol loss of synchronisation may be declared. The timer is specified in units of 100ms." ::= { gsmpSessionEntry 4 } Sjostrand, et. al. Standards Track [Page 26] RFC 3295 GSMP MIB June 2002 gsmpSessionPartitionId OBJECT-TYPE SYNTAX GsmpPartitionIdType MAX-ACCESS read-only STATUS current DESCRIPTION "The Partition Id for the specific switch partition that this session is concerned with." ::= { gsmpSessionEntry 5 } gsmpSessionAdjacencyCount OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the current number of adjacencies that are established with controllers and the switch partition that is used for this session. The value includes this session." ::= { gsmpSessionEntry 6 } gsmpSessionFarSideName OBJECT-TYPE SYNTAX GsmpNameType MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the far side as advertised in the adjacency message." ::= {gsmpSessionEntry 7} gsmpSessionFarSidePort OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The local port number of the link across which the message is being sent." REFERENCE "General Switch Management Protocol V3: Section 3.1.2" ::= { gsmpSessionEntry 8 } gsmpSessionFarSideInstance OBJECT-TYPE SYNTAX Unsigned32(1..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The instance number used for the link during this session. The Instance number is a 24-bit number that should be guaranteed to be unique within Sjostrand, et. al. Standards Track [Page 27] RFC 3295 GSMP MIB June 2002 the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number." ::= { gsmpSessionEntry 9 } gsmpSessionLastFailureCode OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the last failure code that was received over this session. If no failure code have been received, the value is zero." ::= { gsmpSessionEntry 10 } gsmpSessionDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which one or more of this session's counters suffered a discontinuity. If no such discontinuities have occurred since then, this object contains the same timestamp as gsmpSessionStartUptime ." ::= { gsmpSessionEntry 11 } gsmpSessionStartUptime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION " The value of sysUpTime when the session came to established state." ::= { gsmpSessionEntry 12 } gsmpSessionStatSentMessages OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been sent in this session. All GSMP messages pertaining to this session after the session came to established state SHALL be counted, also including adjacency protocol messages and failure response messages. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it Sjostrand, et. al. Standards Track [Page 28] RFC 3295 GSMP MIB June 2002 happened." ::= { gsmpSessionEntry 13 } gsmpSessionStatFailureInds OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been sent with a failure indication in this session. Warning messages SHALL NOT be counted. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 12.1" ::= { gsmpSessionEntry 14 } gsmpSessionStatReceivedMessages OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been received in this session. All legal GSMP messages pertaining to this session after the session came to established state SHALL be counted, also including adjacency protocol messages and failure response messages. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." ::= { gsmpSessionEntry 15 } gsmpSessionStatReceivedFailures OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that have been received in this session with a failure indication. Warning messages SHALL NOT be counted. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 12.1" ::= { gsmpSessionEntry 16 } Sjostrand, et. al. Standards Track [Page 29] RFC 3295 GSMP MIB June 2002 gsmpSessionStatPortUpEvents OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Port Up events that have been sent or received on this session. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 9.1" ::= { gsmpSessionEntry 17 } gsmpSessionStatPortDownEvents OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Port Down events that have been sent or received on this session. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 9.2" ::= { gsmpSessionEntry 18 } gsmpSessionStatInvLabelEvents OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Invalid label events that have been sent or received on this session. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 9.3" ::= { gsmpSessionEntry 19 } gsmpSessionStatNewPortEvents OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of New Port events that have been sent or Sjostrand, et. al. Standards Track [Page 30] RFC 3295 GSMP MIB June 2002 received on this session. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 9.4" ::= { gsmpSessionEntry 20 } gsmpSessionStatDeadPortEvents OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dead Port events that have been sent or received on this session. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 9.5" ::= { gsmpSessionEntry 21 } gsmpSessionStatAdjUpdateEvents OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Adjacency Update events that have been sent or received on this session. When the counter suffers any discontinuity, then the gsmpSessionDiscontinuityTime object indicates when it happened." REFERENCE "General Switch Management Protocol V3: Section 9.6" ::= { gsmpSessionEntry 22 } -- ************************************************************** -- GSMP Notifications -- ************************************************************** -- -- Notification objects -- gsmpEventPort OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS accessible-for-notify Sjostrand, et. al. Standards Track [Page 31] RFC 3295 GSMP MIB June 2002 STATUS current DESCRIPTION "This object specifies the Port Number that is carried in this event." ::= { gsmpNotificationsObjects 1 } gsmpEventPortSessionNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object specifies the Port Session Number that is carried in this event." ::= { gsmpNotificationsObjects 2 } gsmpEventSequenceNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object specifies the Event Sequence Number that is carried in this event." ::= { gsmpNotificationsObjects 3 } gsmpEventLabel OBJECT-TYPE SYNTAX GsmpLabelType MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object specifies the Label that is carried in this event." ::= { gsmpNotificationsObjects 4 } -- -- Notifications -- gsmpSessionDown NOTIFICATION-TYPE OBJECTS { gsmpSessionStartUptime, gsmpSessionStatSentMessages, gsmpSessionStatFailureInds, gsmpSessionStatReceivedMessages, gsmpSessionStatReceivedFailures, gsmpSessionStatPortUpEvents, gsmpSessionStatPortDownEvents, gsmpSessionStatInvLabelEvents, Sjostrand, et. al. Standards Track [Page 32] RFC 3295 GSMP MIB June 2002 gsmpSessionStatNewPortEvents, gsmpSessionStatDeadPortEvents, gsmpSessionStatAdjUpdateEvents } STATUS current DESCRIPTION "When it has been enabled, this notification is generated whenever a session is taken down, regardless of whether the session went down normally or not. Its purpose is to allow a management application (primarily an accounting application) that is monitoring the session statistics to receive the final values of these counters, so that the application can properly account for the amounts the counters were incremented since the last time the application polled them. The gsmpSessionStartUptime object provides the total amount of time that the session was active. This notification is not a substitute for polling the session statistic counts. In particular, the count values reported in this notification cannot be assumed to be the complete totals for the life of the session, since they may have wrapped while the session was up. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifiers of the objects contained in the notification. An instance of this notification will contain exactly one instance of each of its objects, and these objects will all belong to the same conceptual row of the gsmpSessionTable." ::= { gsmpNotifications 1 } gsmpSessionUp NOTIFICATION-TYPE OBJECTS { gsmpSessionFarSideInstance } STATUS current DESCRIPTION "When it has been enabled, this notification is generated when new session is established. The new session is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifier of the gsmpSessionFarSideInstance object Sjostrand, et. al. Standards Track [Page 33] RFC 3295 GSMP MIB June 2002 contained in the notification." ::= { gsmpNotifications 2 } gsmpSentFailureInd NOTIFICATION-TYPE OBJECTS { gsmpSessionLastFailureCode, gsmpSessionStatFailureInds } STATUS current DESCRIPTION "When it has been enabled, this notification is generated when a message with a failure indication was sent. The notification indicates a change in the value of gsmpSessionStatFailureInds. The gsmpSessionLastFailureCode contains the failure reason. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifiers of the objects contained in the notification." ::= { gsmpNotifications 3 } gsmpReceivedFailureInd NOTIFICATION-TYPE OBJECTS { gsmpSessionLastFailureCode, gsmpSessionStatReceivedFailures } STATUS current DESCRIPTION "When it has been enabled, this notification is generate when a message with a failure indication is received. The notification indicates a change in the value of gsmpSessionStatReceivedFailures. The gsmpSessionLastFailureCode contains the failure reason. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifiers of the objects contained in the notification." ::= { gsmpNotifications 4 } Sjostrand, et. al. Standards Track [Page 34] RFC 3295 GSMP MIB June 2002 gsmpPortUpEvent NOTIFICATION-TYPE OBJECTS { gsmpSessionStatPortUpEvents, gsmpEventPort, gsmpEventPortSessionNumber, gsmpEventSequenceNumber } STATUS current DESCRIPTION "When it has been enabled, this notification is generated when a Port Up Event occurs. The notification indicates a change in the value of gsmpSessionStatPortUpEvents. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifier of the gsmpSessionStatPortUpEvents object contained in the notification." ::= { gsmpNotifications 5 } gsmpPortDownEvent NOTIFICATION-TYPE OBJECTS { gsmpSessionStatPortDownEvents, gsmpEventPort, gsmpEventPortSessionNumber, gsmpEventSequenceNumber } STATUS current DESCRIPTION "When it has been enabled, this notification is generated when a Port Down Event occurs. The notification indicates a change in the value of gsmpSessionStatPortDownEvents. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifier of the gsmpSessionStatPortDownEvents object contained in the notification." ::= { gsmpNotifications 6 } gsmpInvalidLabelEvent NOTIFICATION-TYPE OBJECTS { gsmpSessionStatInvLabelEvents, gsmpEventPort, Sjostrand, et. al. Standards Track [Page 35] RFC 3295 GSMP MIB June 2002 gsmpEventLabel, gsmpEventSequenceNumber } STATUS current DESCRIPTION "When it has been enabled, this notification is generated when an Invalid Label Event occurs. The notification indicates a change in the value of gsmpSessionStatInvLabelEvents. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifier of the gsmpSessionStatInvLabelEvents object contained in the notification." ::= { gsmpNotifications 7 } gsmpNewPortEvent NOTIFICATION-TYPE OBJECTS { gsmpSessionStatNewPortEvents, gsmpEventPort, gsmpEventPortSessionNumber, gsmpEventSequenceNumber } STATUS current DESCRIPTION "When it has been enabled, this notification is generated when a New Port Event occurs. The notification indicates a change in the value of gsmpSessionStatNewPortEvents. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifier of the gsmpSessionStatNewPortEvents object contained in the notification." ::= { gsmpNotifications 8 } gsmpDeadPortEvent NOTIFICATION-TYPE OBJECTS { gsmpSessionStatDeadPortEvents, gsmpEventPort, gsmpEventPortSessionNumber, gsmpEventSequenceNumber } STATUS current Sjostrand, et. al. Standards Track [Page 36] RFC 3295 GSMP MIB June 2002 DESCRIPTION "When it has been enabled, this notification is generated when a Dead Port Event occurs. The notification indicates a change in the value of gsmpSessionStatDeadPortEvents. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifier of the gsmpSessionStatDeadPortEvents object contained in the notification." ::= { gsmpNotifications 9 } gsmpAdjacencyUpdateEvent NOTIFICATION-TYPE OBJECTS { gsmpSessionAdjacencyCount, gsmpSessionStatAdjUpdateEvents, gsmpEventSequenceNumber } STATUS current DESCRIPTION "When it has been enabled, this notification is generated when an Adjacency Update Event occurs. The gsmpSessionAdjacencyCount contains the new value of the number of adjacencies that are established with controllers and the switch partition that is used for this session. The notification indicates a change in the value of gsmpSessionStatAdjUpdateEvents. The session to which this notification applies is identified by the gsmpSessionThisSideId and gsmpSessionFarSideId which could be inferred from the Object Identifier of the gsmpSessionAdjacencyCount or the gsmpSessionStatAdjUpdateEvents object contained in the notification." ::= { gsmpNotifications 10 } Sjostrand, et. al. Standards Track [Page 37] RFC 3295 GSMP MIB June 2002 --************************************************************** -- GSMP Compliance --************************************************************** gsmpGroups OBJECT IDENTIFIER ::= { gsmpConformance 1 } gsmpCompliances OBJECT IDENTIFIER ::= { gsmpConformance 2 } gsmpModuleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the GSMP MIB." MODULE -- this module MANDATORY-GROUPS { gsmpGeneralGroup } GROUP gsmpControllerGroup DESCRIPTION "This group is mandatory for all Switch Controllers" GROUP gsmpSwitchGroup DESCRIPTION "This group is mandatory for all Switches" GROUP gsmpAtmEncapGroup DESCRIPTION "This group must be supported if ATM is used for GSMP encapsulation. " GROUP gsmpTcpIpEncapGroup DESCRIPTION "This group must be supported if TCP/IP is used for GSMP encapsulation. " OBJECT gsmpTcpIpEncapAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "An implementation is only required to support 'unknown(0)', and IPv4 addresses. Supporting addresses with zone index or IPv6 addresses are optional. Defining Internet addresses by using DNS domain names are not allowed." OBJECT gsmpTcpIpEncapAddress SYNTAX InetAddress (SIZE(0|4|8|16|20)) DESCRIPTION "An implementation is only required to support Sjostrand, et. al. Standards Track [Page 38] RFC 3295 GSMP MIB June 2002 IPv4 addresses. Supporting addresses with zone index or IPv6 addresses are optional." GROUP gsmpNotificationObjectsGroup DESCRIPTION "This group must be supported if notifications are supported. " GROUP gsmpNotificationsGroup DESCRIPTION "This group must be supported if notifications are supported. " ::= { gsmpCompliances 1 } -- units of conformance gsmpGeneralGroup OBJECT-GROUP OBJECTS { gsmpSessionVersion, gsmpSessionTimer, gsmpSessionPartitionId, gsmpSessionAdjacencyCount, gsmpSessionFarSideName, gsmpSessionFarSidePort, gsmpSessionFarSideInstance, gsmpSessionLastFailureCode, gsmpSessionDiscontinuityTime, gsmpSessionStartUptime, gsmpSessionStatSentMessages, gsmpSessionStatFailureInds, gsmpSessionStatReceivedMessages, gsmpSessionStatReceivedFailures, gsmpSessionStatPortUpEvents, gsmpSessionStatPortDownEvents, gsmpSessionStatInvLabelEvents, gsmpSessionStatNewPortEvents, gsmpSessionStatDeadPortEvents, gsmpSessionStatAdjUpdateEvents } STATUS current DESCRIPTION "Objects that apply to all GSMP implementations." ::= { gsmpGroups 1 } gsmpControllerGroup OBJECT-GROUP OBJECTS { gsmpControllerMaxVersion, Sjostrand, et. al. Standards Track [Page 39] RFC 3295 GSMP MIB June 2002 gsmpControllerTimer, gsmpControllerPort, gsmpControllerInstance, gsmpControllerPartitionType, gsmpControllerPartitionId, gsmpControllerDoResync, gsmpControllerNotificationMap, gsmpControllerSessionState, gsmpControllerStorageType, gsmpControllerRowStatus } STATUS current DESCRIPTION "Objects that apply GSMP implementations of Switch Controllers." ::= { gsmpGroups 2 } gsmpSwitchGroup OBJECT-GROUP OBJECTS { gsmpSwitchMaxVersion, gsmpSwitchTimer, gsmpSwitchName, gsmpSwitchPort, gsmpSwitchInstance, gsmpSwitchPartitionType, gsmpSwitchPartitionId, gsmpSwitchNotificationMap, gsmpSwitchSwitchType, gsmpSwitchWindowSize, gsmpSwitchSessionState, gsmpSwitchStorageType, gsmpSwitchRowStatus } STATUS current DESCRIPTION "Objects that apply GSMP implementations of Switches." ::= { gsmpGroups 3 } gsmpAtmEncapGroup OBJECT-GROUP OBJECTS { gsmpAtmEncapIfIndex, gsmpAtmEncapVpi, gsmpAtmEncapVci, gsmpAtmEncapStorageType, gsmpAtmEncapRowStatus } STATUS current Sjostrand, et. al. Standards Track [Page 40] RFC 3295 GSMP MIB June 2002 DESCRIPTION "Objects that apply to GSMP implementations that supports ATM for GSMP encapsulation." ::= { gsmpGroups 4 } gsmpTcpIpEncapGroup OBJECT-GROUP OBJECTS { gsmpTcpIpEncapAddressType, gsmpTcpIpEncapAddress, gsmpTcpIpEncapPortNumber, gsmpTcpIpEncapStorageType, gsmpTcpIpEncapRowStatus } STATUS current DESCRIPTION "Objects that apply to GSMP implementations that supports TCP/IP for GSMP encapsulation." ::= { gsmpGroups 5 } gsmpNotificationObjectsGroup OBJECT-GROUP OBJECTS { gsmpEventPort, gsmpEventPortSessionNumber, gsmpEventSequenceNumber, gsmpEventLabel } STATUS current DESCRIPTION "Objects that are contained in the notifications." ::= { gsmpGroups 6 } gsmpNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { gsmpSessionDown, gsmpSessionUp, gsmpSentFailureInd, gsmpReceivedFailureInd, gsmpPortUpEvent, gsmpPortDownEvent, gsmpInvalidLabelEvent, gsmpNewPortEvent, gsmpDeadPortEvent, gsmpAdjacencyUpdateEvent } STATUS current DESCRIPTION "The notifications which indicate specific changes in the value of objects gsmpSessionTable" Sjostrand, et. al. Standards Track [Page 41] RFC 3295 GSMP MIB June 2002 ::= { gsmpGroups 7 } END 5. Acknowledgments The authors would like to thank Avri Doria and Kenneth Sundell for their contributions to this specification. Also thanks to David Partain, Michael MacFaden and Bert Wijnen who have contributed significantly with their SNMP expertise. 6. References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1905] 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] 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. [RFC1987] Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 1.1, RFC 1987, August 1996. [RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. Sjostrand, et. al. Standards Track [Page 42] RFC 3295 GSMP MIB June 2002 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2397] Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 2.0, RFC 2397, March 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs.", BCP 26, RFC 2434, October 1998. [RFC2514] Noto, M., E. Spiegel, K. Tesink, "Definition of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Sjostrand, et. al. Standards Track [Page 43] RFC 3295 GSMP MIB June 2002 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB" RFC 2863, June 2000. [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J., Schoenwaelder "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3292] Doria, A., Hellstrand, F., Sundell, K. and T. Worster, "General Switch Management Protocol V3", RFC 3292, June 2002. [RFC3293] Worster, T., Doria, A. and J. Buerkle, "General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)", RFC 3293, June 2002. 7. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Sjostrand, et. al. Standards Track [Page 44] RFC 3295 GSMP MIB June 2002 8. Security Considerations Assuming that secure network management (such as SNMP v3) is implemented, the objects represented in this MIB do not pose a threat to the security of the network. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information. They are contained in the gsmpControllerTable and gsmpSwitchTable. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects, only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Sjostrand, et. al. Standards Track [Page 45] RFC 3295 GSMP MIB June 2002 9. Authors' Addresses Hans Sjostrand ipUnplugged P.O. Box 101 60 S-121 28 Stockholm, Sweden Phone: +46 8 725 5930 EMail: hans@ipunplugged.com Joachim Buerkle Nortel Networks Germany GmbH & Co. KG Hahnstrasse 37-39 D-60528 Frankfurt am Main, Germany Phone: +49 69 6697 3281 EMail: joachim.buerkle@nortelnetworks.com Balaji Srinivasan CPlane Inc. 897 Kifer Road Sunnyvale, CA 94086 Phone: +1 408 789 4099 EMail: balaji@cplane.com Sjostrand, et. al. Standards Track [Page 46] RFC 3295 GSMP MIB June 2002 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sjostrand, et. al. Standards Track [Page 47] snmp-mibs-downloader-1.1/mibrfcs/rfc3371.txt0000644000000000000000000042130611402176071015565 0ustar Network Working Group E. Caves Request for Comments: 3371 Occam Networks Category: Standards Track P. Calhoun Black Storm Networks R. Wheeler DoubleWide Software August 2002 Layer Two Tunneling Protocol "L2TP" Management Information Base 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol (L2TP). Caves, et. al. Standards Track [Page 1] RFC 3371 L2TP Management Information Base August 2002 Table of Contents 1.0 Introduction .......................................... 2 2.0 The SNMP Management Framework ........................... 2 3.0 Overview ................................................ 4 3.1 Relationship to the Interface MIB........................ 5 3.1.1 Layering Model .......................................... 5 3.1.2 Interface MIB Object..................................... 7 3.1.2.1 L2TP Tunnel Interfaces .................................. 7 3.2 Relationship to other MIBs .............................. 10 3.2.1 Relationship to the IP Tunnel MIB ....................... 10 3.3 L2TP Tunnel Creation .................................... 10 3.4 L2TP Session Mapping .................................... 10 4.0 L2TP Object Definitions ................................. 11 5.0 Security Considerations ................................. 66 6.0 Acknowledgements ........................................ 67 7.0 References .............................................. 67 8.0 Authors' Addresses ...................................... 69 9.0 Full Copyright Statement ................................ 70 1.0 Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it describes managed objects used for managing L2TP devices. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.0 The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Caves, et. al. Standards Track [Page 2] RFC 3371 L2TP Management Information Base August 2002 o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Caves, et. al. Standards Track [Page 3] RFC 3371 L2TP Management Information Base August 2002 3.0 Overview The objects defined in this MIB are to be used when describing Layer Two Tunneling Protocol (L2TP) tunnels. The L2TP protocol is defined in [RFC2661]. This MIB consists of seven groups briefly described below: l2tpConfigGroup l2tpStatsGroup These two groups of objects provide information on the configuration, state and statistics of the L2TP protocol, its tunnels and sessions. These groups are mandatory for implementors of this MIB. l2tpDomainGroup This optional group of objects provides configuration, state and statistical information for L2TP tunnel endpoint domains. A L2TP tunnel endpoint domain is considered to be a collection of L2TP devices typically belonging to a common administrative domain or geographic location. l2tpMappingGroup This optional group contains mapping tables to assist management applications to map between protocol identifiers and table indices. l2tpIpUdpGroup This group provides the state and statistics information for L2TP tunnels which are being transported by UDP/IP. This group is mandatory for L2TP implementations that support L2TP over UDP/IP. l2tpSecurityGroup This group is optional for SNMP agents which support both authentication and privacy of SNMP messages for the management of L2TP keys. l2tpTrapGroup This group contains the notifications that could be generated by a L2TP implementation. l2tpHCPacketGroup This group is optional for L2TP implementations that could potentially overflow the L2TP Domain tables 32-bit statistics counters in less than an hour. Caves, et. al. Standards Track [Page 4] RFC 3371 L2TP Management Information Base August 2002 3.1 Relationship to the Interface MIB This section clarifies the relationship of this MIB to the Interfaces MIB [RFC2863]. Several areas of correlation are addressed in the following subsections. The implementor is referred to the Interfaces MIB document in order to understand the general intent of these areas. 3.1.1 Layering Model This MIB contains several tables which are extensions to the IP Tunnel MIB described in [RFC2667] which itself defines extensions to the Interface MIB [RFC2863]. An L2TP tunnel is represented as a separate identifiable logical interface sub-layer. The tunnel stack layering model is described in [RFC2667]. In addition to that described in [RFC2667] an L2TP tunnel will not be at the top of the ifStack on a L2TP device that is acting as a L2TP Network Server (LNS). In this case PPP interfaces will be layered on top of the tunnel interface. Caves, et. al. Standards Track [Page 5] RFC 3371 L2TP Management Information Base August 2002 In the example diagram below, the interface layering is shown as it might appear at the LNS. +--------------------------------------------+ | Network Layer Protocol | +-+-----------+-------------+--------+-------+ | | | | | +-+--+ | | | |MPPP| | | <=== PPP Multilink I/F | ++--++ | | | | | | | | +--+ +--+ | | | | | | | | +-+-+ +-+-+ +-+-+ +-+-+ | |PPP| |PPP| |PPP| |PPP| <=== PPP I/F | +-+-+ +-+-+ +-+-+ +-+-+ | | | | | | +----+--------+--------+--------+----+ | | L2TP Tunnel I/F | | +------------------+-----------------+ | | +-+---------------------+------+ | Ethernet | +------------------------------+ The ifStackTable is used to describe the layering of the interface sub-layers. For the example given above the ifTable and ifStackTable may appear as follows: ifIndex ifType Tunnel MIB tables Description 1 ethernetCsmacd(6) Ethernet interface 2 tunnel(131) tunnelIfTable Tunnel interface l2tpTunnelConfigTable l2tpTunnelStatsTable 3 ppp(23) PPP interface #1 4 ppp(23) PPP interface #2 5 ppp(23) PPP interface #3 6 ppp(23) PPP interface #4 7 mlppp(108) MLPPP interface Caves, et. al. Standards Track [Page 6] RFC 3371 L2TP Management Information Base August 2002 The corresponding ifStack table entries would then be: ifStackTable Entries HigherLayer LowerLayer 0 5 0 6 0 7 1 0 2 1 3 2 4 2 5 2 6 2 7 3 7 4 L2TP Access Concentrator (LAC) tunnel interfaces on the other hand appear at the top of the interface layering stack. In this case the layering model is as described in [RFC2667]. However in order to support the tunneling of packets received from interfaces carrying framed PPP packets on the LAC to the LNS (and the propagation of decapsulated PPP packets to that interface) additional configuration is required. This is further described in section 3.4. 3.1.2 Interface MIB Objects Except where noted in the tables below, all objects MUST be supported from the ifGeneralInformationGroup and one of the following three groups: o ifPacketGroup OR o ifHCPacketGroup OR o ifVHCPacketGroup depending on the particular implementation. The following tables describe how objects from the ifGeneralInformationGroup and ifPacketGroup (similar support should be provided for the high and very high capacity packet groups) are to be interpreted and supported for L2TP tunnel interfaces. 3.1.2.1 L2TP Tunnel Interfaces All Interface MIB objects not listed in the above groups for L2TP tunnel interfaces MUST be supported as described in [RFC2863]. Caves, et. al. Standards Track [Page 7] RFC 3371 L2TP Management Information Base August 2002 Interface MIB Object Support Description ==================== ======================================== ifTable.ifDescr Refer to the Interface MIB. ifTable.ifType tunnel(131). ifTable.ifMtu Dependent on the tunnel transport layer. For UDP/IP transports the MTU should be 65467 (65535-60(IP)-8(UDP)). ifTable.ifSpeed Return zero. ifTable.ifPhyAddress The assigned tunnel identifier. ifTable.ifAdminStatus Setting ifAdminStatus to 'up' injects a 'Local Open' request into the tunnel FSM. Setting ifAdminStatus to 'down' injects a 'Tunnel Close' event into the tunnel FSM. Setting ifAdminStatus to 'testing' is not currently defined but could be used to test tunnel connectivity. ifTable.ifOperStatus ifOperStatus values are to be interpreted as follows: 'up' - tunnel is established. 'down' - administratively down or peer unreachable. 'testing' - in some test mode. 'unknown' - status cannot be determined for some reason. 'dormant' - operational but waiting for local or remote trigger to bring up the tunnel. 'notPresent' - configuration missing. 'lowerLayerDown' - down due to state of lower-layer interface(s). ifTable.ifInOctets The total number of octets received on the tunnel including control and payload octets. ifTable.ifInUcastPkts The total number of packets received on the tunnel including control and payload packets. Caves, et. al. Standards Track [Page 8] RFC 3371 L2TP Management Information Base August 2002 ifTable.ifInDiscards The total number of received packets that were discarded on both control and payload channels. ifTable.ifInErrors The total number of packets received in error including control and payload packets. ifTable.ifInUnknownProtos Return zero. ifTable.ifOutOctets The total number of octets transmitted from the tunnel including control and payload octets. ifTable.ifOutUcastPkts The total number of packets transmitted from the tunnel including control and payload packets. ifTable.ifOutDiscards The total number of discarded packets that were requested to be transmitted including control and payload packets. ifTable.ifOutErrors The total number of packets that were requested to be transmitted that were in error including control and payload packets. ifXTable.ifName Refer to the Interface MIB. ifXTable.ifInMulticastPkts Return zero. ifXTable.ifInBroadcastPkts Return zero. ifXTable.ifOutMulticastPkts Return zero. ifXTable.ifOutBroadcastPkts Return zero. ifXTable.ifOutBroadcastPkts Return zero. ifXTable.ifLinkUpDownTrapEnable Default set to enabled(1). Caves, et. al. Standards Track [Page 9] RFC 3371 L2TP Management Information Base August 2002 ifXTable.ifHighSpeed Return zero. ifXTable.ifPromiscuousMode Set to false(2). ifXTable.ifConnectorPresent Set to false(2). 3.2 Relationship to other MIBs 3.2.1 Relationship to the IP Tunnel MIB The IP Tunnel MIB [RFC2667] describes tunnel interfaces that have an ifType of tunnel(131). The IP Tunnel MIB is considered to contain a collection of objects common to all IP tunneling protocols, including L2TP. In addition to the IP Tunnel MIB, tunnel encapsulation specific MIBs (like this MIB) extend the IP Tunnel MIB to further describe encapsulation specific information. Implementation of the IP Tunnel MIB is required for L2TP tunnels over IP. 3.3 L2TP Tunnel Creation Tunnel creation is detailed for tunnels over IP in the IP Tunnel MIB. The creation of a tunnelIfEntry in [RFC2667] when the encapsulation method is "l2tp" will have the side effect of creating entries in the l2tpTunnelConfigTable, l2tpTunnelStatsTable and the l2tpUdpStatsTable's. The creation of L2TP tunnel interfaces over transports other than IP is expected to be defined in the MIB definition for that specific L2TP tunnel transport. 3.4 L2TP Session Mapping The l2tpSessionMapTable table allows management applications to determine which session within a tunnel a particular interface (either a PPP or DS0 interface) is mapped to. On the LAC it also provides a management application the ability to map a particular physical or virtual interface terminating a PPP link to a particular L2TP tunnel. This is required since the interface stacking as performed (and instrumented by the ifStackTable) on the LNS cannot be applied at the LAC. Caves, et. al. Standards Track [Page 10] RFC 3371 L2TP Management Information Base August 2002 The following diagram illustrates the conceptual binding that occurs. +---------------------------------------+ | L2TP Session Map Database | +----------+-----------------+----------+ | | +---+---+ +-----+------+ | ds0 | | Tunnel I/F | +---+---+ +-----+------+ | | +---+---+ +-----+------+ | ds1 | | Ethernet | +-------+ +------------+ The stacking of the individual interface stacks would be described by the ifStackTable. 4.0 L2TP Object Definitions L2TP-MIB DEFINITIONS ::= BEGIN IMPORTS Integer32, Unsigned32, Counter32, Gauge32, Counter64, transmission, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TruthValue, StorageType FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB; l2tp MODULE-IDENTITY LAST-UPDATED "200208230000Z" -- 23 August 2002 ORGANIZATION "IETF L2TP Working Group" CONTACT-INFO "Evan Caves Postal: Occam Networks 77 Robin Hill Road Santa Barbara, CA, 93117 Tel: +1 805692 2900 Email: evan@occamnetworks.com Pat R. Calhoun Caves, et. al. Standards Track [Page 11] RFC 3371 L2TP Management Information Base August 2002 Postal: Black Storm Networks 110 Nortech Parkway San Jose, CA, 95143 Tel: +1 408 941-0500 Email: pcalhoun@bstormnetworks.com Ross Wheeler Postal: DoubleWide Software, Inc. 2953 Bunker Hill Lane Suite 101 Santa Clara, CA 95054 Tel: +1 6509260599 Email: ross@doublewidesoft.com Layer Two Tunneling Protocol Extensions WG Working Group Area: Internet Working Group Name: l2tpext General Discussion: l2tp@l2tp.net" DESCRIPTION "The MIB module that describes managed objects of general use by the Layer Two Transport Protocol." -- revision log REVISION "200208230000Z" -- 23 August 2002 DESCRIPTION "First revision, published as RFC 3371." ::= { transmission 95 } -- -- Textual Conventions -- L2tpMilliSeconds ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-3" STATUS current DESCRIPTION "A period of time measured in units of .001 of seconds when used in conjunction with the DISPLAY-HINT will show seconds and fractions of second with a resolution of .001 of a second." SYNTAX Integer32 (0..2147483646) -- -- Definitions of significant branches -- Caves, et. al. Standards Track [Page 12] RFC 3371 L2TP Management Information Base August 2002 l2tpNotifications OBJECT IDENTIFIER ::= { l2tp 0 } l2tpObjects OBJECT IDENTIFIER ::= { l2tp 1 } l2tpTransports OBJECT IDENTIFIER ::= { l2tp 3 } l2tpConformance OBJECT IDENTIFIER ::= { l2tp 4 } -- -- Definitions of significant branches under l2tpObjects -- l2tpScalar OBJECT IDENTIFIER ::= { l2tpObjects 1 } l2tpConfig OBJECT IDENTIFIER ::= { l2tpScalar 1 } l2tpStats OBJECT IDENTIFIER ::= { l2tpScalar 2 } -- -- Definitions of significant branches under l2tpTransports -- -- Note that future transports of L2TP (e.g.: Frame relay) -- should create their own branch under l2tpTransports. l2tpTransportIpUdp OBJECT IDENTIFIER ::= { l2tpTransports 1 } l2tpIpUdpObjects OBJECT IDENTIFIER ::= { l2tpTransportIpUdp 1 } l2tpIpUdpTraps OBJECT IDENTIFIER ::= { l2tpTransportIpUdp 2 } -- -- The L2TP Scalar Configuration Group -- -- This group of objects is used to manage configuration -- of the L2TP protocol environment. l2tpAdminState OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the administrative state of the L2TP protocol. Setting this object to 'disabled' causes all tunnels to be immediately disconnected and no further tunnels to be either initiated or accepted. The value of this object must be maintained in non-volatile memory." ::= { l2tpConfig 1 } l2tpDrainTunnels OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current Caves, et. al. Standards Track [Page 13] RFC 3371 L2TP Management Information Base August 2002 DESCRIPTION "Setting this object to 'true' will prevent any new tunnels and/or sessions to be either initiated or accepted but does NOT disconnect any active tunnels/sessions. Setting this object to true(1) causes all domains and their respective tunnels to transition to the draining state. Note that when this occurs the 'xxxDraining' status objects of the domains and their tunnels should reflect that they are 'draining'. Setting this object has no affect on the domains or their tunnels 'xxxDrainTunnels' configuration objects. To cancel a drain this object should be set to false(2). The object l2tpDrainingTunnels reflects the current L2TP draining state. The value of this object must be maintained in non-volatile memory." ::= { l2tpConfig 2 } -- -- The L2TP Scalar Status and Statistics Group -- -- This group of objects describe the current state and -- statistics of L2TP. l2tpProtocolVersions OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2..256)) MAX-ACCESS read-only STATUS current DESCRIPTION "Vector of supported L2TP protocol version and revision numbers. Supported versions are identified via a two octet pairing where the first octet indicates the version and the second octet contains the revision." ::= { l2tpStats 1 } l2tpVendorName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the Vendor name of the L2TP protocol stack." ::= { l2tpStats 2 } l2tpFirmwareRev OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only Caves, et. al. Standards Track [Page 14] RFC 3371 L2TP Management Information Base August 2002 STATUS current DESCRIPTION "This object defines the firmware revision for the L2TP protocol stack." ::= { l2tpStats 3 } l2tpDrainingTunnels OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if the local L2TP is draining off sessions from all tunnels." ::= { l2tpStats 4 } -- -- The L2TP Domain Configuration Table -- l2tpDomainConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpDomainConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP Domain configuration table. This table contains objects that can be used to configure the operational characteristics of a tunnel domain. There is a 1-1 correspondence between conceptual rows of this table and conceptual rows of the l2tpDomainStatsTable." ::= { l2tpObjects 2 } l2tpDomainConfigEntry OBJECT-TYPE SYNTAX L2tpDomainConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An L2TP Domain configuration entry. An entry in this table may correspond to a single endpoint or a group of tunnel endpoints." INDEX { l2tpDomainConfigId } ::= { l2tpDomainConfigTable 1 } L2tpDomainConfigEntry ::= SEQUENCE { l2tpDomainConfigId SnmpAdminString, l2tpDomainConfigAdminState Caves, et. al. Standards Track [Page 15] RFC 3371 L2TP Management Information Base August 2002 INTEGER, l2tpDomainConfigDrainTunnels TruthValue, l2tpDomainConfigAuth INTEGER, l2tpDomainConfigSecret SnmpAdminString, l2tpDomainConfigTunnelSecurity INTEGER, l2tpDomainConfigTunnelHelloInt Integer32, l2tpDomainConfigTunnelIdleTO Integer32, l2tpDomainConfigControlRWS Integer32, l2tpDomainConfigControlMaxRetx Integer32, l2tpDomainConfigControlMaxRetxTO Integer32, l2tpDomainConfigPayloadSeq INTEGER, l2tpDomainConfigReassemblyTO L2tpMilliSeconds, l2tpDomainConfigProxyPPPAuth TruthValue, l2tpDomainConfigStorageType StorageType, l2tpDomainConfigStatus RowStatus } l2tpDomainConfigId OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..80)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier, usually in the form of a Domain Name (full or partial), describing a single tunnel endpoint or a domain of tunnel endpoints. This is typically used as a 'handle' to identify the tunnel configuration requirements for both incoming and outgoing tunnel connection attempts. Both the LAC and LNS could use information provided in the Host Name AVP attribute however the tunnel initiator could use other means not specified to identify the domain's tunnel configuration requirements. For example; three rows in this table have l2tpDomainConfigId values of 'lac1.isp.com', Caves, et. al. Standards Track [Page 16] RFC 3371 L2TP Management Information Base August 2002 'isp.com' and 'com'. A tunnel endpoint then identifies itself as 'lac1.isp.com' which would match the 'lac1.isp.com' entry in this table. A second tunnel endpoint then identifies itself as 'lac2.isp.com'. This endpoint is then associated with the 'isp.com' entry of this table." ::= { l2tpDomainConfigEntry 1 } l2tpDomainConfigAdminState OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the administrative state of this tunnel domain. Setting this object to disabled(2) causes all tunnels to be immediately disconnected and no further tunnels to be either initiated or accepted. Note that all columnar objects corresponding to this conceptual row cannot be modified when the administrative state is enabled EXCEPT those objects which specifically state otherwise." DEFVAL { enabled } ::= { l2tpDomainConfigEntry 2 } l2tpDomainConfigDrainTunnels OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Setting this object to 'true' will prevent any new tunnels and/or sessions from being either initiated or accepted but does NOT disconnect any active tunnels/sessions for this tunnel domain. Setting this object to true(1) causes all tunnels within this domain to transition to the draining state. Note that when this occurs the l2tpTunnelStatsDrainingTunnel status objects of all of this domain's tunnels should reflect that they are 'draining'. Setting this object has no effect on this domain's associated tunnels l2tpTunnelConfigDrainTunnel configuration objects. To cancel a drain this object should be set to false(2). Setting this object to false(2) when the L2TP object l2tpDrainTunnels is true(1) has no affect, all domains and their tunnels will Caves, et. al. Standards Track [Page 17] RFC 3371 L2TP Management Information Base August 2002 continue to drain." DEFVAL { false } ::= { l2tpDomainConfigEntry 3 } l2tpDomainConfigAuth OBJECT-TYPE SYNTAX INTEGER { none(1), simple(2), challenge(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes how tunnel peers belonging to this domain are to be authenticated. The value simple(2) indicates that peers are authenticated simply by their host name as described in the Host Name AVP. The value challenge(3) indicates that all peers are challenged to prove their identification. This mechanism is described in the L2TP protocol." REFERENCE "RFC 2661 Section 5.1" DEFVAL { none } ::= { l2tpDomainConfigEntry 4 } l2tpDomainConfigSecret OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to configure the shared secret used during the tunnel authentication phase of tunnel establishment. This object MUST be accessible only via requests using both authentication and privacy. The agent MUST report an empty string in response to get, get-next and get-bulk requests." ::= { l2tpDomainConfigEntry 5 } l2tpDomainConfigTunnelSecurity OBJECT-TYPE SYNTAX INTEGER { none(1), other(2), ipSec(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this tunnel domain requires that all tunnels are to be secured. The Caves, et. al. Standards Track [Page 18] RFC 3371 L2TP Management Information Base August 2002 value of ipsec(3) indicates that all tunnel packets, control and session, have IP Security headers. The type of IP Security headers (AH, ESP etc) and how they are further described is outside the scope of this document." DEFVAL { none } ::= { l2tpDomainConfigEntry 6 } l2tpDomainConfigTunnelHelloInt OBJECT-TYPE SYNTAX Integer32 (0..3600) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the interval in which Hello (or keep-alive) packets are to be sent by local peers belonging to this tunnel domain. The value zero effectively disables the sending of Hello packets. This object may be modified when the administrative state is enabled for this conceptual row." DEFVAL { 60 } ::= { l2tpDomainConfigEntry 7 } l2tpDomainConfigTunnelIdleTO OBJECT-TYPE SYNTAX Integer32 (-1..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the period of time that an established tunnel belonging to this tunnel domain with no active sessions will wait before disconnecting the tunnel. A value of zero indicates that the tunnel will disconnect immediately after the last session disconnects. A value of -1 leaves the tunnel up indefinitely. This object may be modified when the administrative state is enabled for this conceptual row." DEFVAL { 0 } ::= { l2tpDomainConfigEntry 8 } l2tpDomainConfigControlRWS OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the control channel receive Caves, et. al. Standards Track [Page 19] RFC 3371 L2TP Management Information Base August 2002 window size for tunnels belonging to this domain. It specifies the maximum number of packets the tunnel peer belonging to this domain can send without waiting for an acknowledgement from this peer." DEFVAL { 4 } ::= { l2tpDomainConfigEntry 9 } l2tpDomainConfigControlMaxRetx OBJECT-TYPE SYNTAX Integer32 (0..32) MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the maximum number of retransmissions which the L2TP stack will attempt for tunnels belonging to this domain before assuming that the peer is no longer responding." DEFVAL { 5 } ::= { l2tpDomainConfigEntry 10 } l2tpDomainConfigControlMaxRetxTO OBJECT-TYPE SYNTAX Integer32 (1..32) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the maximum retransmission timeout interval which the L2TP stack will wait for tunnels belonging to this domain before retransmitting a control packet that has not been acknowledged." DEFVAL { 16 } ::= { l2tpDomainConfigEntry 11 } l2tpDomainConfigPayloadSeq OBJECT-TYPE SYNTAX INTEGER { onDemand(1), never(2), always(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object determines whether or not session payload packets will be requested to be sent with sequence numbers from tunnel peers belonging to this domain. The value onDemand(1) allows the L2TP implementation to initiate payload sequencing when necessary based on local information (e.g: during LCP/NCP negotiations or for CCP). The value never(2) indicates that L2TP Caves, et. al. Standards Track [Page 20] RFC 3371 L2TP Management Information Base August 2002 will never initiate sequencing but will do sequencing if asked. The value always(3) indicates that L2TP will send the Sequencing Required AVP during session establishment." DEFVAL { onDemand } ::= { l2tpDomainConfigEntry 12 } l2tpDomainConfigReassemblyTO OBJECT-TYPE SYNTAX L2tpMilliSeconds MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the number of milliseconds that local peers of this tunnel domain will wait before processing payload packets that were received out of sequence (which are waiting for the packet(s) to put them in sequence). A low value increases the chance of delayed packets to be discarded (which MAY cause the PPP decompression engine to reset) while a high value may cause more queuing and possibly degrade throughput if packets are truly lost. The default value for this object is zero which will result in all delayed packets being lost." DEFVAL { 0 } ::= { l2tpDomainConfigEntry 13 } l2tpDomainConfigProxyPPPAuth OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to configure the sending or acceptance of the PPP Proxy Authentication AVP's on the LAC or LNS." DEFVAL { true } ::= { l2tpDomainConfigEntry 14 } l2tpDomainConfigStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' must allow write-access at a minimum to: - l2tpDomainConfigAdminState and Caves, et. al. Standards Track [Page 21] RFC 3371 L2TP Management Information Base August 2002 l2tpDomainConfigDrainTunnels at all times - l2tpDomainConfigSecret if l2tpDomainConfigAuth has been configured as 'challenge' It is an implementation issue to decide if a SET for a readOnly or permanent row is accepted at all. In some contexts this may make sense, in others it may not. If a SET for a readOnly or permanent row is not accepted at all, then a 'wrongValue' error must be returned." ::= { l2tpDomainConfigEntry 15 } l2tpDomainConfigStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this Domain entry. Columnar objects corresponding to this conceptual row may be modified according to their description clauses when this RowStatus object is 'active'." ::= { l2tpDomainConfigEntry 16 } -- -- The L2TP Domain Status and Statistics Table -- l2tpDomainStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpDomainStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP Domain Status and Statistics table. This table contains objects that can be used to describe the current status and statistics of a tunnel domain. There is a 1-1 correspondence between conceptual rows of this table and conceptual rows of the l2tpDomainConfigTable." ::= { l2tpObjects 3 } l2tpDomainStatsEntry OBJECT-TYPE SYNTAX L2tpDomainStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An L2TP Domain Stats entry. An entry in this table may correspond to a single endpoint or a group of tunnel endpoints." AUGMENTS { l2tpDomainConfigEntry } Caves, et. al. Standards Track [Page 22] RFC 3371 L2TP Management Information Base August 2002 ::= { l2tpDomainStatsTable 1 } L2tpDomainStatsEntry ::= SEQUENCE { l2tpDomainStatsTotalTunnels Counter32, l2tpDomainStatsFailedTunnels Counter32, l2tpDomainStatsFailedAuths Counter32, l2tpDomainStatsActiveTunnels Gauge32, l2tpDomainStatsTotalSessions Counter32, l2tpDomainStatsFailedSessions Counter32, l2tpDomainStatsActiveSessions Gauge32, l2tpDomainStatsDrainingTunnels TruthValue, l2tpDomainStatsControlRxOctets Counter32, l2tpDomainStatsControlRxPkts Counter32, l2tpDomainStatsControlTxOctets Counter32, l2tpDomainStatsControlTxPkts Counter32, l2tpDomainStatsPayloadRxOctets Counter32, l2tpDomainStatsPayloadRxPkts Counter32, l2tpDomainStatsPayloadRxDiscs Counter32, l2tpDomainStatsPayloadTxOctets Counter32, l2tpDomainStatsPayloadTxPkts Counter32, l2tpDomainStatsControlHCRxOctets Counter64, l2tpDomainStatsControlHCRxPkts Counter64, l2tpDomainStatsControlHCTxOctets Counter64, l2tpDomainStatsControlHCTxPkts Counter64, l2tpDomainStatsPayloadHCRxOctets Counter64, Caves, et. al. Standards Track [Page 23] RFC 3371 L2TP Management Information Base August 2002 l2tpDomainStatsPayloadHCRxPkts Counter64, l2tpDomainStatsPayloadHCRxDiscs Counter64, l2tpDomainStatsPayloadHCTxOctets Counter64, l2tpDomainStatsPayloadHCTxPkts Counter64 } l2tpDomainStatsTotalTunnels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the total number of tunnels that have successfully reached the established state for this tunnel domain." ::= { l2tpDomainStatsEntry 1 } l2tpDomainStatsFailedTunnels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of tunnels that failed (eg: connection timeout, unsupported or malformed AVP's etc) to reach the established state for this tunnel domain." ::= { l2tpDomainStatsEntry 2 } l2tpDomainStatsFailedAuths OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of failed tunnel connection attempts for this domain because the tunnel peer failed authentication." ::= { l2tpDomainStatsEntry 3 } l2tpDomainStatsActiveTunnels OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of tunnels that are currently active for this domain." Caves, et. al. Standards Track [Page 24] RFC 3371 L2TP Management Information Base August 2002 ::= { l2tpDomainStatsEntry 4 } l2tpDomainStatsTotalSessions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the total number of sessions that have successfully reached the established state for this tunnel domain." ::= { l2tpDomainStatsEntry 5 } l2tpDomainStatsFailedSessions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of sessions that failed (eg: connection timeout, unsupported or malformed AVP's etc) to reach the established state for this tunnel domain." ::= { l2tpDomainStatsEntry 6 } l2tpDomainStatsActiveSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of sessions that are currently active for this domain." ::= { l2tpDomainStatsEntry 7 } l2tpDomainStatsDrainingTunnels OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if this domain is draining off sessions from all tunnels." ::= { l2tpDomainStatsEntry 8 } l2tpDomainStatsControlRxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of control channel octets received for this tunnel domain." Caves, et. al. Standards Track [Page 25] RFC 3371 L2TP Management Information Base August 2002 ::= { l2tpDomainStatsEntry 9 } l2tpDomainStatsControlRxPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of control packets received for this tunnel domain." ::= { l2tpDomainStatsEntry 10 } l2tpDomainStatsControlTxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of control channel octets that were transmitted to tunnel endpoints for this domain." ::= { l2tpDomainStatsEntry 11 } l2tpDomainStatsControlTxPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of control packets that were transmitted to tunnel endpoints for this domain." ::= { l2tpDomainStatsEntry 12 } l2tpDomainStatsPayloadRxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of payload channel octets that were received for this tunnel domain." ::= { l2tpDomainStatsEntry 13 } l2tpDomainStatsPayloadRxPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of payload packets that were received for this tunnel domain." ::= { l2tpDomainStatsEntry 14 } Caves, et. al. Standards Track [Page 26] RFC 3371 L2TP Management Information Base August 2002 l2tpDomainStatsPayloadRxDiscs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of received payload packets that were discarded by this tunnel domain." ::= { l2tpDomainStatsEntry 15 } l2tpDomainStatsPayloadTxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of payload channel octets that were transmitted to tunnel peers within this tunnel domain." ::= { l2tpDomainStatsEntry 16 } l2tpDomainStatsPayloadTxPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of payload packets that were transmitted to tunnel peers within this tunnel domain." ::= { l2tpDomainStatsEntry 17 } -- -- High Capacity Counter objects. These objects are all -- 64 bit versions of the above 32-bit counters. These -- objects all have the same basic semantics as their -- 32-bit counterparts, however, their syntax has been -- extended to 64 bits. -- l2tpDomainStatsControlHCRxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsControlRxOctets." ::= { l2tpDomainStatsEntry 18 } l2tpDomainStatsControlHCRxPkts OBJECT-TYPE SYNTAX Counter64 Caves, et. al. Standards Track [Page 27] RFC 3371 L2TP Management Information Base August 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsControlRxPkts." ::= { l2tpDomainStatsEntry 19 } l2tpDomainStatsControlHCTxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsControlTxOctets." ::= { l2tpDomainStatsEntry 20 } l2tpDomainStatsControlHCTxPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsControlTxPkts." ::= { l2tpDomainStatsEntry 21 } l2tpDomainStatsPayloadHCRxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsPayloadRxOctets." ::= { l2tpDomainStatsEntry 22 } l2tpDomainStatsPayloadHCRxPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsPayloadRxPkts." ::= { l2tpDomainStatsEntry 23 } l2tpDomainStatsPayloadHCRxDiscs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION Caves, et. al. Standards Track [Page 28] RFC 3371 L2TP Management Information Base August 2002 "This object is a 64-bit version of l2tpDomainStatsPayloadRxDiscs." ::= { l2tpDomainStatsEntry 24 } l2tpDomainStatsPayloadHCTxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsPayloadTxOctets." ::= { l2tpDomainStatsEntry 25 } l2tpDomainStatsPayloadHCTxPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a 64-bit version of l2tpDomainStatsPayloadTxPkts." ::= { l2tpDomainStatsEntry 26 } -- -- The L2TP Tunnel Configuration Table -- l2tpTunnelConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpTunnelConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP tunnel configuration table. This table contains objects that can be used to (re)configure the operational characteristics of a single L2TP tunnel. There is a 1-1 correspondence between conceptual rows of this table and conceptual rows of the l2tpTunnelStatsTable. Entries in this table have the same persistency characteristics as that of the tunnelConfigTable." REFERENCE "RFC 2667" ::= { l2tpObjects 4 } l2tpTunnelConfigEntry OBJECT-TYPE SYNTAX L2tpTunnelConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Caves, et. al. Standards Track [Page 29] RFC 3371 L2TP Management Information Base August 2002 "A L2TP tunnel interface configuration entry. Entries in this table come and go as a result of protocol interactions or on management operations. The latter occurs when a row is instantiated in the tunnelConfigTable row and the encapsulation method is 'l2tp'." REFERENCE "RFC 2667" INDEX { l2tpTunnelConfigIfIndex } ::= { l2tpTunnelConfigTable 1 } L2tpTunnelConfigEntry ::= SEQUENCE { l2tpTunnelConfigIfIndex InterfaceIndex, l2tpTunnelConfigDomainId SnmpAdminString, l2tpTunnelConfigAuth INTEGER, l2tpTunnelConfigSecret SnmpAdminString, l2tpTunnelConfigSecurity INTEGER, l2tpTunnelConfigHelloInterval Integer32, l2tpTunnelConfigIdleTimeout Integer32, l2tpTunnelConfigControlRWS Integer32, l2tpTunnelConfigControlMaxRetx Integer32, l2tpTunnelConfigControlMaxRetxTO Integer32, l2tpTunnelConfigPayloadSeq INTEGER, l2tpTunnelConfigReassemblyTO L2tpMilliSeconds, l2tpTunnelConfigTransport INTEGER, l2tpTunnelConfigDrainTunnel TruthValue, l2tpTunnelConfigProxyPPPAuth TruthValue } l2tpTunnelConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current Caves, et. al. Standards Track [Page 30] RFC 3371 L2TP Management Information Base August 2002 DESCRIPTION "This value for this object is equal to the value of ifIndex of the Interfaces MIB for tunnel interfaces of type L2TP." ::= { l2tpTunnelConfigEntry 1 } l2tpTunnelConfigDomainId OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..80)) MAX-ACCESS read-write STATUS current DESCRIPTION "The tunnel domain that this tunnel belongs to. A LNS tunnel endpoint will typically inherit this value from the endpoint domain table. A LAC may be provided with this information during tunnel setup. When a zero length string is returned this tunnel does not belong belong to any particular domain." ::= { l2tpTunnelConfigEntry 2 } l2tpTunnelConfigAuth OBJECT-TYPE SYNTAX INTEGER { none(1), simple(2), challenge(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object describes how L2TP tunnel peers are to be authenticated. The value 'simple' indicates that peers are authenticated simply by their host name as described in the Host Name AVP. The value 'challenge' indicates that all peers are challenged to prove their identification. This mechanism is described in the L2TP protocol. This object cannot be modified when the tunnel is in a connecting or connected state." DEFVAL { none } ::= { l2tpTunnelConfigEntry 3 } l2tpTunnelConfigSecret OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to configure the shared secret used during the tunnel authentication phase of Caves, et. al. Standards Track [Page 31] RFC 3371 L2TP Management Information Base August 2002 tunnel establishment. This object cannot be modified when the tunnel is in a connecting or connected state. This object MUST be accessible only via requests using both authentication and privacy. The agent MUST report an empty string in response to get, get-next and get-bulk requests." ::= { l2tpTunnelConfigEntry 4 } l2tpTunnelConfigSecurity OBJECT-TYPE SYNTAX INTEGER { none(1), other(2), ipsec(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines whether this tunnel is to be secured. The value of 'ipSec' indicates that all tunnel packets, control and session, have IP Security headers. The type of IP Security headers (AH, ESP etc) and how they are further described is outside the scope of this document. This object cannot be modified when the tunnel is in a connecting or connected state." DEFVAL { none } ::= { l2tpTunnelConfigEntry 5 } l2tpTunnelConfigHelloInterval OBJECT-TYPE SYNTAX Integer32 (0..3600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the interval in which Hello (or keep-alive) packets are to be sent to the tunnel peer. The value zero effectively disables the sending of Hello packets. Modifications to this object have immediate effect." DEFVAL { 60 } ::= { l2tpTunnelConfigEntry 6 } l2tpTunnelConfigIdleTimeout OBJECT-TYPE SYNTAX Integer32 (-1..86400) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION Caves, et. al. Standards Track [Page 32] RFC 3371 L2TP Management Information Base August 2002 "This object defines the period of time that an established tunnel with no sessions will wait before disconnecting the tunnel. A value of zero indicates that the tunnel will disconnect immediately after the last session disconnects. A value of -1 leaves the tunnel up indefinitely. Modifications to this object have immediate effect." DEFVAL { 0 } ::= { l2tpTunnelConfigEntry 7 } l2tpTunnelConfigControlRWS OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the control channel receive window size. It specifies the maximum number of packets the tunnel peer can send without waiting for an acknowledgement from this peer. This object cannot be modified when the tunnel is in a con- necting or connected state." DEFVAL { 4 } ::= { l2tpTunnelConfigEntry 8 } l2tpTunnelConfigControlMaxRetx OBJECT-TYPE SYNTAX Integer32 (0..32) MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the number of retransmissions which the tunnel will attempt before assuming that the peer is no longer responding. A value of zero indicates that this peer will not attempt to retransmit an unacknowledged control packet. Modifications to this object have immediate effect." DEFVAL { 5 } ::= { l2tpTunnelConfigEntry 9 } l2tpTunnelConfigControlMaxRetxTO OBJECT-TYPE SYNTAX Integer32 (1..32) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the maximum retransmission timeout interval which the tunnel will wait before retrans- Caves, et. al. Standards Track [Page 33] RFC 3371 L2TP Management Information Base August 2002 mitting a control packet that has not been acknowledged. Modifications to this object have immediate effect." DEFVAL { 16 } ::= { l2tpTunnelConfigEntry 10 } l2tpTunnelConfigPayloadSeq OBJECT-TYPE SYNTAX INTEGER { onDemand(1), never(2), always(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines whether or not session payload packets will be requested to be sent with sequence numbers from tunnel peers belonging to this domain. The value onDemand(1) allows the L2TP implementation to initiate payload sequencing when necessary based on local information (e.g: during LCP/NCP negotiations or for CCP). The value never(2) indicates that L2TP will never initiate sequencing but will do sequencing if asked. The value always(3) indicates that L2TP will send the Sequencing Required AVP during session establishment. Modifications to this object have immediate effect." DEFVAL { onDemand } ::= { l2tpTunnelConfigEntry 11 } l2tpTunnelConfigReassemblyTO OBJECT-TYPE SYNTAX L2tpMilliSeconds MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the number of milliseconds that this tunnel will wait before processing payload packets that were received out of sequence (which are waiting for the packet(s) to put them in sequence). A low value increases the chance of delayed packets to be discarded (which MAY cause the PPP decompression engine to reset) while a high value may cause more queuing and possibly degrade throughput if packets are truly lost. The default value for this object is zero which will result in all delayed packets being lost. Modifications to this object have immediate effect." DEFVAL { 0 } ::= { l2tpTunnelConfigEntry 12 } Caves, et. al. Standards Track [Page 34] RFC 3371 L2TP Management Information Base August 2002 l2tpTunnelConfigTransport OBJECT-TYPE SYNTAX INTEGER { other(1), none(2), udpIp(3), frameRelay(4), atm(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the underlying transport media that is in use for this tunnel entry. Different tunnel transports may define MIB extensions to the L2TP tunnel table to realize the transport layer. For example if the value of this object is 'udpIp' then the value of ifIndex for this table may be used to determine state from the l2tpUdpStatsTable. This object cannot be modified when the tunnel is in a connecting or connected state." ::= { l2tpTunnelConfigEntry 13 } l2tpTunnelConfigDrainTunnel OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'true' will prevent any new session from being either initiated or accepted but does NOT disconnect any active sessions for this tunnel. Note that when this occurs the l2tpTunnelStatsDrainingTunnel status object of this tunnel should reflect that it is 'draining'. To cancel a drain this object should be set to false(2). Setting this object to false(2) when the L2TP objects l2tpDrainTunnels or l2tpDomainConfigDrainTunnels is true(1) has no affect, this tunnels will continue to drain." DEFVAL { false } ::= { l2tpTunnelConfigEntry 14 } l2tpTunnelConfigProxyPPPAuth OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to configure the sending or acceptance of the session PPP Proxy Authentication AVP's on the LAC or LNS." Caves, et. al. Standards Track [Page 35] RFC 3371 L2TP Management Information Base August 2002 DEFVAL { true } ::= { l2tpTunnelConfigEntry 15 } -- -- The L2TP Tunnel Status and Statisticss Table -- l2tpTunnelStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpTunnelStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP tunnel status and statistics table. This table contains objects that can be used to describe the current status and statistics of a single L2TP tunnel. There is a 1-1 correspondence between conceptual rows of this table and conceptual rows of the l2tpTunnelConfigTable." ::= { l2tpObjects 5 } l2tpTunnelStatsEntry OBJECT-TYPE SYNTAX L2tpTunnelStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An L2TP tunnel interface stats entry." AUGMENTS { l2tpTunnelConfigEntry } ::= { l2tpTunnelStatsTable 1 } L2tpTunnelStatsEntry ::= SEQUENCE { l2tpTunnelStatsLocalTID Integer32, l2tpTunnelStatsRemoteTID Integer32, l2tpTunnelStatsState INTEGER, l2tpTunnelStatsInitiated INTEGER, l2tpTunnelStatsRemoteHostName SnmpAdminString, l2tpTunnelStatsRemoteVendorName SnmpAdminString, l2tpTunnelStatsRemoteFirmwareRev Integer32, l2tpTunnelStatsRemoteProtocolVer OCTET STRING, Caves, et. al. Standards Track [Page 36] RFC 3371 L2TP Management Information Base August 2002 l2tpTunnelStatsInitialRemoteRWS Integer32, l2tpTunnelStatsBearerCaps INTEGER, l2tpTunnelStatsFramingCaps INTEGER, l2tpTunnelStatsControlRxPkts Counter32, l2tpTunnelStatsControlRxZLB Counter32, l2tpTunnelStatsControlOutOfSeq Counter32, l2tpTunnelStatsControlOutOfWin Counter32, l2tpTunnelStatsControlTxPkts Counter32, l2tpTunnelStatsControlTxZLB Counter32, l2tpTunnelStatsControlAckTO Counter32, l2tpTunnelStatsCurrentRemoteRWS Gauge32, l2tpTunnelStatsTxSeq Integer32, l2tpTunnelStatsTxSeqAck Integer32, l2tpTunnelStatsRxSeq Integer32, l2tpTunnelStatsRxSeqAck Integer32, l2tpTunnelStatsTotalSessions Counter32, l2tpTunnelStatsFailedSessions Counter32, l2tpTunnelStatsActiveSessions Gauge32, l2tpTunnelStatsLastResultCode Integer32, l2tpTunnelStatsLastErrorCode Integer32, l2tpTunnelStatsLastErrorMessage SnmpAdminString, l2tpTunnelStatsDrainingTunnel TruthValue } l2tpTunnelStatsLocalTID OBJECT-TYPE SYNTAX Integer32 (0..65535) Caves, et. al. Standards Track [Page 37] RFC 3371 L2TP Management Information Base August 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the local tunnel Identifier." REFERENCE "RFC 2661, Section 3.1" ::= { l2tpTunnelStatsEntry 1 } l2tpTunnelStatsRemoteTID OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the remote tunnel Identifier." REFERENCE "RFC 2661, Section 3.1" ::= { l2tpTunnelStatsEntry 2 } l2tpTunnelStatsState OBJECT-TYPE SYNTAX INTEGER { tunnelIdle(1), tunnelConnecting(2), tunnelEstablished(3), tunnelDisconnecting(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This field contains the current state of the control tunnel." ::= { l2tpTunnelStatsEntry 3 } l2tpTunnelStatsInitiated OBJECT-TYPE SYNTAX INTEGER { locally(1), remotely(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the tunnel was initiated locally or by the remote tunnel peer." ::= { l2tpTunnelStatsEntry 4 } l2tpTunnelStatsRemoteHostName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the host name as discovered Caves, et. al. Standards Track [Page 38] RFC 3371 L2TP Management Information Base August 2002 during the tunnel establishment phase (via the Host Name AVP) of the L2TP peer. If the tunnel is idle this object should maintain its value from the last time it was connected." ::= { l2tpTunnelStatsEntry 5 } l2tpTunnelStatsRemoteVendorName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the vendor name of the peer's L2TP implementation. If the tunnel is idle this object should maintain its value from the last time it was connected." ::= { l2tpTunnelStatsEntry 6 } l2tpTunnelStatsRemoteFirmwareRev OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the tunnel peer's firmware revision number. If the tunnel is idle this object should maintain its value from the last time it was connected." ::= { l2tpTunnelStatsEntry 7 } l2tpTunnelStatsRemoteProtocolVer OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the protocol version and revision of the tunnel peers implementation. The first octet contains the protocol version. The second octet contains the protocol revision." ::= { l2tpTunnelStatsEntry 8 } l2tpTunnelStatsInitialRemoteRWS OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the initial remote peer's receive window size as indicated by the tunnel peer (in the RWS AVP) during the tunnel establishment phase. If the tunnel is idle this object should Caves, et. al. Standards Track [Page 39] RFC 3371 L2TP Management Information Base August 2002 maintain its value from the last time it was connected." ::= { l2tpTunnelStatsEntry 9 } l2tpTunnelStatsBearerCaps OBJECT-TYPE SYNTAX INTEGER { none(1), digital(2), analog(3), digitalAnalog(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the Bearer Capabilities of the tunnel peer. If the tunnel is idle this object should maintain its value from the last time it was connected." ::= { l2tpTunnelStatsEntry 10 } l2tpTunnelStatsFramingCaps OBJECT-TYPE SYNTAX INTEGER { none(1), sync(2), async(3), syncAsync(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the Framing Capabilities of the tunnel peer. If the tunnel is idle this object should maintain its value from the last time it was connected." ::= { l2tpTunnelStatsEntry 11 } l2tpTunnelStatsControlRxPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of control packets received on the tunnel." ::= { l2tpTunnelStatsEntry 12 } l2tpTunnelStatsControlRxZLB OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Caves, et. al. Standards Track [Page 40] RFC 3371 L2TP Management Information Base August 2002 STATUS current DESCRIPTION "This object returns a count of the number of Zero Length Body control packet acknowledgement packets that were received." ::= { l2tpTunnelStatsEntry 13 } l2tpTunnelStatsControlOutOfSeq OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns a count of the number of control packets that were not received in the correct order (as per the sequence number) on this tunnel including out of window packets." ::= { l2tpTunnelStatsEntry 14 } l2tpTunnelStatsControlOutOfWin OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of control packets that were received outside of the offered receive window. It is implementation specific as to whether these packets are queued or discarded." ::= { l2tpTunnelStatsEntry 15 } l2tpTunnelStatsControlTxPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of control packets that were transmitted to the tunnel peer." ::= { l2tpTunnelStatsEntry 16 } l2tpTunnelStatsControlTxZLB OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of Zero Length Body control packets transmitted to the tunnel Caves, et. al. Standards Track [Page 41] RFC 3371 L2TP Management Information Base August 2002 peer." ::= { l2tpTunnelStatsEntry 17 } l2tpTunnelStatsControlAckTO OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns a count of the number of control packet timeouts due to the lack of a timely acknowledgement from the tunnel peer." ::= { l2tpTunnelStatsEntry 18 } l2tpTunnelStatsCurrentRemoteRWS OBJECT-TYPE SYNTAX Gauge32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the current remote receive window size as determined by the local flow control mechanism employed." ::= { l2tpTunnelStatsEntry 19 } l2tpTunnelStatsTxSeq OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next send sequence number for the control channel." ::= { l2tpTunnelStatsEntry 20 } l2tpTunnelStatsTxSeqAck OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the send sequence number that the tunnel peer has acknowledged for the control channel. The flow control state can be determined by subtracting the l2tpTunnelStatsTxSeq from l2tpTunnelStatsTxSeqAck and comparing this value to l2tpTunnelStatsCurrentRemoteRWS (taking into consideration sequence number wraps)." ::= { l2tpTunnelStatsEntry 21 } l2tpTunnelStatsRxSeq OBJECT-TYPE SYNTAX Integer32 (0..65535) Caves, et. al. Standards Track [Page 42] RFC 3371 L2TP Management Information Base August 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next receive sequence number expected to be received on this control channel." ::= { l2tpTunnelStatsEntry 22 } l2tpTunnelStatsRxSeqAck OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the last receive sequence number that was acknowledged back to the tunnel peer for the control channel." ::= { l2tpTunnelStatsEntry 23 } l2tpTunnelStatsTotalSessions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of sessions that this tunnel has successfully connected through to its tunnel peer since this tunnel was created." ::= { l2tpTunnelStatsEntry 24 } l2tpTunnelStatsFailedSessions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of sessions that were initiated but failed to reach the established phase." ::= { l2tpTunnelStatsEntry 25 } l2tpTunnelStatsActiveSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of sessions in the established state for this tunnel." ::= { l2tpTunnelStatsEntry 26 } l2tpTunnelStatsLastResultCode OBJECT-TYPE Caves, et. al. Standards Track [Page 43] RFC 3371 L2TP Management Information Base August 2002 SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the last value of the result code as described in the Result Code AVP which caused the tunnel to disconnect." ::= { l2tpTunnelStatsEntry 27 } l2tpTunnelStatsLastErrorCode OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the last value of the error code as described in the Result Code AVP which caused the tunnel to disconnect." ::= { l2tpTunnelStatsEntry 28 } l2tpTunnelStatsLastErrorMessage OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the last value of the optional message as described in the Result Code AVP which caused the tunnel to disconnect." ::= { l2tpTunnelStatsEntry 29 } l2tpTunnelStatsDrainingTunnel OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if this tunnel is draining off sessions. This object will return false(2) when the tunnel is not draining sessions or after the last session has disconnected when the tunnel is in the draining state." ::= { l2tpTunnelStatsEntry 30 } -- -- { l2tpObjects 6 } reserved for future use -- -- -- The L2TP Session Status and Statistics Table -- Caves, et. al. Standards Track [Page 44] RFC 3371 L2TP Management Information Base August 2002 l2tpSessionStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP session status and statistics table. This table contains the objects that can be used to describe the current status and statistics of a single L2TP tunneled session." ::= { l2tpObjects 7 } l2tpSessionStatsEntry OBJECT-TYPE SYNTAX L2tpSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An L2TP session interface stats entry." INDEX { l2tpSessionStatsTunnelIfIndex, l2tpSessionStatsLocalSID } ::= { l2tpSessionStatsTable 1 } L2tpSessionStatsEntry ::= SEQUENCE { l2tpSessionStatsTunnelIfIndex InterfaceIndex, l2tpSessionStatsIfIndex InterfaceIndex, l2tpSessionStatsLocalSID Integer32, l2tpSessionStatsRemoteSID Integer32, l2tpSessionStatsUserName SnmpAdminString, l2tpSessionStatsState INTEGER, l2tpSessionStatsCallType INTEGER, l2tpSessionStatsCallSerialNumber Unsigned32, l2tpSessionStatsTxConnectSpeed Unsigned32, l2tpSessionStatsRxConnectSpeed Unsigned32, l2tpSessionStatsCallBearerType INTEGER, l2tpSessionStatsFramingType INTEGER, l2tpSessionStatsPhysChanId Caves, et. al. Standards Track [Page 45] RFC 3371 L2TP Management Information Base August 2002 Unsigned32, l2tpSessionStatsDNIS SnmpAdminString, l2tpSessionStatsCLID SnmpAdminString, l2tpSessionStatsSubAddress SnmpAdminString, l2tpSessionStatsPrivateGroupID SnmpAdminString, l2tpSessionStatsProxyLcp TruthValue, l2tpSessionStatsAuthMethod INTEGER, l2tpSessionStatsSequencingState INTEGER, l2tpSessionStatsOutSequence Counter32, l2tpSessionStatsReassemblyTO Counter32, l2tpSessionStatsTxSeq Integer32, l2tpSessionStatsRxSeq Integer32 } l2tpSessionStatsTunnelIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the session's associated L2TP tunnel ifIndex value." ::= { l2tpSessionStatsEntry 1 } l2tpSessionStatsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the ifIndex value of the interface from which PPP packets are being tunneled. For example this could be a DS0 ifIndex on a LAC or it would be the PPP ifIndex on the LNS." ::= { l2tpSessionStatsEntry 2 } l2tpSessionStatsLocalSID OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible Caves, et. al. Standards Track [Page 46] RFC 3371 L2TP Management Information Base August 2002 STATUS current DESCRIPTION "This object contains the local assigned session identifier for this session." REFERENCE "RFC 2661, Section 3.1" ::= { l2tpSessionStatsEntry 3 } l2tpSessionStatsRemoteSID OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the remote assigned session identifier for this session. When a session is starting this value may be zero until the remote tunnel endpoint has responded." REFERENCE "RFC 2661, Section 3.1" ::= { l2tpSessionStatsEntry 4 } l2tpSessionStatsUserName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the peer session name on this interface. This is typically the login name of the remote user. If the user name is unknown to the local tunnel peer then this object will contain a null string." ::= { l2tpSessionStatsEntry 5 } l2tpSessionStatsState OBJECT-TYPE SYNTAX INTEGER { sessionIdle(1), sessionConnecting(2), sessionEstablished(3), sessionDisconnecting(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the current state of the session." ::= { l2tpSessionStatsEntry 6 } l2tpSessionStatsCallType OBJECT-TYPE SYNTAX INTEGER { lacIncoming(1), Caves, et. al. Standards Track [Page 47] RFC 3371 L2TP Management Information Base August 2002 lnsIncoming(2), lacOutgoing(3), lnsOutgoing(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of call and the role this tunnel peer is providing for this session. For example, lacIncoming(1) indicates that this tunnel peer is acting as a LAC and generated a Incoming-Call-Request to the tunnel peer (the LNS). Note that tunnel peers can be both LAC and LNS simultaneously." ::= { l2tpSessionStatsEntry 7 } l2tpSessionStatsCallSerialNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the serial number that has been assigned to this session." ::= { l2tpSessionStatsEntry 8 } l2tpSessionStatsTxConnectSpeed OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the last known transmit baud rate for this session." ::= { l2tpSessionStatsEntry 9 } l2tpSessionStatsRxConnectSpeed OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the last known receive baud rate for this session established." ::= { l2tpSessionStatsEntry 10 } l2tpSessionStatsCallBearerType OBJECT-TYPE SYNTAX INTEGER { none(1), Caves, et. al. Standards Track [Page 48] RFC 3371 L2TP Management Information Base August 2002 digital(2), analog(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the bearer type of this session." ::= { l2tpSessionStatsEntry 11 } l2tpSessionStatsFramingType OBJECT-TYPE SYNTAX INTEGER { none(1), sync(2), async(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the framing type of this session." ::= { l2tpSessionStatsEntry 12 } l2tpSessionStatsPhysChanId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the physical channel identifier for the session." ::= { l2tpSessionStatsEntry 13 } l2tpSessionStatsDNIS OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the Dialed Number Information String that the LAC obtained from the network for the session. If no DNIS was provided then a null string will be returned." ::= { l2tpSessionStatsEntry 14 } l2tpSessionStatsCLID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION Caves, et. al. Standards Track [Page 49] RFC 3371 L2TP Management Information Base August 2002 "This object identifies the Calling Line ID that the LAC obtained from the network for the session. If no CLID was provided then a null string will be returned." ::= { l2tpSessionStatsEntry 15 } l2tpSessionStatsSubAddress OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the Sub Address that the LAC obtained from the network for the session. If no Sub Address was provided then a null string will be returned." ::= { l2tpSessionStatsEntry 16 } l2tpSessionStatsPrivateGroupID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the Private Group Identifier used for this tunneled session. If no Private Group Identifier was provided then a null string will be returned." ::= { l2tpSessionStatsEntry 17 } l2tpSessionStatsProxyLcp OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the LAC performed proxy LCP for this session." ::= { l2tpSessionStatsEntry 18 } l2tpSessionStatsAuthMethod OBJECT-TYPE SYNTAX INTEGER { none(1), text(2), pppChap(3), pppPap(4), pppEap(5), pppMsChapV1(6), pppMsChapV2(7), other(8) } Caves, et. al. Standards Track [Page 50] RFC 3371 L2TP Management Information Base August 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the proxy authentication method employed by the LAC for the session. If l2tpSessionProxyLcp is false(2) this object should not be interpreted." ::= { l2tpSessionStatsEntry 19 } l2tpSessionStatsSequencingState OBJECT-TYPE SYNTAX INTEGER { none(1), remote(2), local(3), both(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object defines which tunnel peers have requested payload sequencing. The value of both(4) indicates that both peers have requested payload sequencing." ::= { l2tpSessionStatsEntry 20 } l2tpSessionStatsOutSequence OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the total number of packets received for this session which were received out of sequence." ::= { l2tpSessionStatsEntry 21 } l2tpSessionStatsReassemblyTO OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of reassembly timeouts that have occurred for this session." ::= { l2tpSessionStatsEntry 22 } l2tpSessionStatsTxSeq OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current Caves, et. al. Standards Track [Page 51] RFC 3371 L2TP Management Information Base August 2002 DESCRIPTION "This object contains the next send sequence number for for this session." ::= { l2tpSessionStatsEntry 23 } l2tpSessionStatsRxSeq OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next receive sequence number expected to be received on this session." ::= { l2tpSessionStatsEntry 24 } -- -- The L2TP Tunnel Mapping Table -- l2tpTunnelMapTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpTunnelMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP Tunnel index mapping table. This table is intended to assist management applications to quickly determine what the ifIndex value is for a given local tunnel identifier." ::= { l2tpObjects 8 } l2tpTunnelMapEntry OBJECT-TYPE SYNTAX L2tpTunnelMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An L2TP tunnel index map entry." INDEX { l2tpTunnelMapLocalTID } ::= { l2tpTunnelMapTable 1 } L2tpTunnelMapEntry ::= SEQUENCE { l2tpTunnelMapLocalTID Integer32, l2tpTunnelMapIfIndex InterfaceIndex } l2tpTunnelMapLocalTID OBJECT-TYPE SYNTAX Integer32 (1..65535) Caves, et. al. Standards Track [Page 52] RFC 3371 L2TP Management Information Base August 2002 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains the local tunnel Identifier." REFERENCE "RFC 2661, Section 3.1" ::= { l2tpTunnelMapEntry 1 } l2tpTunnelMapIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This value for this object is equal to the value of ifIndex of the Interfaces MIB for tunnel interfaces of type L2TP." ::= { l2tpTunnelMapEntry 2 } -- -- The L2TP Session Mapping Table -- l2tpSessionMapTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpSessionMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP Session index mapping table. This table is intended to assist management applications to map interfaces to a tunnel and session identifier." ::= { l2tpObjects 9 } l2tpSessionMapEntry OBJECT-TYPE SYNTAX L2tpSessionMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An L2TP Session index map entry." INDEX { l2tpSessionMapIfIndex } ::= { l2tpSessionMapTable 1 } L2tpSessionMapEntry ::= SEQUENCE { l2tpSessionMapIfIndex InterfaceIndex, l2tpSessionMapTunnelIfIndex InterfaceIndex, l2tpSessionMapLocalSID Caves, et. al. Standards Track [Page 53] RFC 3371 L2TP Management Information Base August 2002 Integer32, l2tpSessionMapStatus RowStatus } l2tpSessionMapIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the ifIndex value of the interface which is receiving or sending its packets over an L2TP tunnel. For example this could be a DS0 ifIndex on a LAC or a PPP ifIndex on the LNS." ::= { l2tpSessionMapEntry 1 } l2tpSessionMapTunnelIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the sessions associated L2TP tunnel ifIndex value. When this object is set it provides a binding between a particular interface identified by l2tpSessionMapIfIndex to a particular tunnel." ::= { l2tpSessionMapEntry 2 } l2tpSessionMapLocalSID OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the local assigned session identifier for this session." REFERENCE "RFC 2661, Section 3.1" ::= { l2tpSessionMapEntry 3 } l2tpSessionMapStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this session map entry." ::= { l2tpSessionMapEntry 4 } -- -- { l2tpIpUdpObjects 1 } reserved for future use Caves, et. al. Standards Track [Page 54] RFC 3371 L2TP Management Information Base August 2002 -- -- The L2TP UDP/IP Transport Status and Statistics Table -- l2tpUdpStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF L2tpUdpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The L2TP UDP/IP transport stats table. This table contains objects that can be used to describe the current status and statistics of the UDP/IP L2TP tunnel transport." ::= { l2tpIpUdpObjects 2 } l2tpUdpStatsEntry OBJECT-TYPE SYNTAX L2tpUdpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An L2TP UDP/IP transport stats entry." INDEX { l2tpUdpStatsIfIndex } ::= { l2tpUdpStatsTable 1 } L2tpUdpStatsEntry ::= SEQUENCE { l2tpUdpStatsIfIndex InterfaceIndex, l2tpUdpStatsPeerPort Integer32, l2tpUdpStatsLocalPort Integer32 } l2tpUdpStatsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value for this object is equal to the value of ifIndex of the Interfaces MIB for tunnel interfaces of type L2TP and which have a L2TP transport of UDP/IP." ::= { l2tpUdpStatsEntry 1 } l2tpUdpStatsPeerPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only Caves, et. al. Standards Track [Page 55] RFC 3371 L2TP Management Information Base August 2002 STATUS current DESCRIPTION "This object reflects the peer's UDP port number used for this tunnel. When not known a value of zero should be returned." ::= { l2tpUdpStatsEntry 2 } l2tpUdpStatsLocalPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the local UDP port number that this tunnel is bound to." ::= { l2tpUdpStatsEntry 3 } -- -- Definition of generic L2TP notifications -- l2tpTunnelAuthFailure NOTIFICATION-TYPE OBJECTS { l2tpTunnelStatsInitiated, l2tpTunnelStatsRemoteHostName } STATUS current DESCRIPTION "A l2tpTunnelAuthFailure trap signifies that an attempt to establish a tunnel to a remote peer has failed authentication." ::= { l2tpNotifications 1 } -- -- conformance information -- l2tpGroups OBJECT IDENTIFIER ::= { l2tpConformance 1 } l2tpCompliances OBJECT IDENTIFIER ::= { l2tpConformance 2 } -- -- compliance statements -- l2tpMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read-create and read-write, then such an Caves, et. al. Standards Track [Page 56] RFC 3371 L2TP Management Information Base August 2002 implementation can claim full compliance. Such an implementation can then be both monitored and configured with this MIB." MODULE -- this module -- unconditionally mandatory groups MANDATORY-GROUPS { l2tpConfigGroup, l2tpStatsGroup, l2tpTrapGroup } -- conditionally mandatory groups GROUP l2tpIpUdpGroup DESCRIPTION "This group is mandatory for implementations that support L2TP over UDP/IP." -- optional groups GROUP l2tpDomainGroup DESCRIPTION "This group is optional for L2TP devices that group tunnel endpoints into tunnel domains." -- optional Mapping Group GROUP l2tpMappingGroup DESCRIPTION "This group is optional for L2TP devices that provide index mapping." -- optional Security Group GROUP l2tpSecurityGroup DESCRIPTION "This group is optional for SNMP agents which support both authentication and privacy of SNMP messages for the management of L2TP keys." -- optional High Capacity Group GROUP l2tpHCPacketGroup DESCRIPTION "This group is mandatory for implementations that support the l2tpDomainGroup AND could potentially overflow the L2TP Domain 32-bit counters is less than one hour." ::= { l2tpCompliances 1 } l2tpMIBReadOnlyCompliance MODULE-COMPLIANCE Caves, et. al. Standards Track [Page 57] RFC 3371 L2TP Management Information Base August 2002 STATUS current DESCRIPTION "When this MIB is implemented without support for read-create and read-write (i.e. in read-only mode), then such an implementation can claim read-only compliance. Such an implementation can then be monitored but can not be configured with this MIB." MODULE -- this module -- unconditionally mandatory groups MANDATORY-GROUPS { l2tpConfigGroup, l2tpStatsGroup, l2tpTrapGroup } OBJECT l2tpAdminState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDrainTunnels MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigDomainId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigHelloInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigIdleTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigControlRWS MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigControlMaxRetx Caves, et. al. Standards Track [Page 58] RFC 3371 L2TP Management Information Base August 2002 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigControlMaxRetxTO MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigPayloadSeq MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigReassemblyTO MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigTransport MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigDrainTunnel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigProxyPPPAuth MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- conditionally mandatory groups GROUP l2tpIpUdpGroup DESCRIPTION "This group is mandatory for implementations that support L2TP over UDP/IP." -- optional groups GROUP l2tpDomainGroup DESCRIPTION "This group is optional for L2TP devices that group tunnel endpoints into tunnel domains." OBJECT l2tpDomainConfigAdminState MIN-ACCESS read-only Caves, et. al. Standards Track [Page 59] RFC 3371 L2TP Management Information Base August 2002 DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigDrainTunnels MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigTunnelHelloInt MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigTunnelIdleTO MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigControlRWS MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigControlMaxRetx MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigControlMaxRetxTO MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigPayloadSeq MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigReassemblyTO MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigProxyPPPAuth MIN-ACCESS read-only DESCRIPTION "Write access is not required." Caves, et. al. Standards Track [Page 60] RFC 3371 L2TP Management Information Base August 2002 OBJECT l2tpDomainConfigStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- optional Mapping Group GROUP l2tpMappingGroup DESCRIPTION "This group is optional for L2TP devices that provide index mapping." OBJECT l2tpSessionMapTunnelIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpSessionMapStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- optional Security Group GROUP l2tpSecurityGroup DESCRIPTION "This group is optional for SNMP agents which support both authentication and privacy of SNMP messages for the management of L2TP keys." OBJECT l2tpDomainConfigAuth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigSecret MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpDomainConfigTunnelSecurity MIN-ACCESS read-only DESCRIPTION "Write access is not required." Caves, et. al. Standards Track [Page 61] RFC 3371 L2TP Management Information Base August 2002 OBJECT l2tpTunnelConfigAuth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigSecret MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT l2tpTunnelConfigSecurity MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- optional High Capacity Group GROUP l2tpHCPacketGroup DESCRIPTION "This group is mandatory for implementations that support the l2tpDomainGroup AND could potentially overflow the L2TP Domain 32-bit counters is less than one hour." ::= { l2tpCompliances 2 } -- units of conformance l2tpConfigGroup OBJECT-GROUP OBJECTS { l2tpAdminState, l2tpDrainTunnels, l2tpTunnelConfigDomainId, l2tpTunnelConfigHelloInterval, l2tpTunnelConfigIdleTimeout, l2tpTunnelConfigControlRWS, l2tpTunnelConfigControlMaxRetx, l2tpTunnelConfigControlMaxRetxTO, l2tpTunnelConfigPayloadSeq, l2tpTunnelConfigReassemblyTO, l2tpTunnelConfigTransport, l2tpTunnelConfigDrainTunnel, l2tpTunnelConfigProxyPPPAuth } STATUS current DESCRIPTION "A collection of objects providing configuration information of the L2TP protocol, tunnels and sessions." Caves, et. al. Standards Track [Page 62] RFC 3371 L2TP Management Information Base August 2002 ::= { l2tpGroups 1 } l2tpStatsGroup OBJECT-GROUP OBJECTS { l2tpProtocolVersions, l2tpVendorName, l2tpFirmwareRev, l2tpDrainingTunnels, l2tpTunnelStatsLocalTID, l2tpTunnelStatsRemoteTID, l2tpTunnelStatsState, l2tpTunnelStatsInitiated, l2tpTunnelStatsRemoteHostName, l2tpTunnelStatsRemoteVendorName, l2tpTunnelStatsRemoteFirmwareRev, l2tpTunnelStatsRemoteProtocolVer, l2tpTunnelStatsInitialRemoteRWS, l2tpTunnelStatsBearerCaps, l2tpTunnelStatsFramingCaps, l2tpTunnelStatsControlRxPkts, l2tpTunnelStatsControlRxZLB, l2tpTunnelStatsControlOutOfSeq, l2tpTunnelStatsControlOutOfWin, l2tpTunnelStatsControlTxPkts, l2tpTunnelStatsControlTxZLB, l2tpTunnelStatsControlAckTO, l2tpTunnelStatsCurrentRemoteRWS, l2tpTunnelStatsTxSeq, l2tpTunnelStatsTxSeqAck, l2tpTunnelStatsRxSeq, l2tpTunnelStatsRxSeqAck, l2tpTunnelStatsTotalSessions, l2tpTunnelStatsFailedSessions, l2tpTunnelStatsActiveSessions, l2tpTunnelStatsLastResultCode, l2tpTunnelStatsLastErrorCode, l2tpTunnelStatsLastErrorMessage, l2tpTunnelStatsDrainingTunnel, l2tpSessionStatsIfIndex, l2tpSessionStatsRemoteSID, l2tpSessionStatsUserName, l2tpSessionStatsState, l2tpSessionStatsCallType, l2tpSessionStatsCallSerialNumber, l2tpSessionStatsTxConnectSpeed, l2tpSessionStatsRxConnectSpeed, l2tpSessionStatsCallBearerType, l2tpSessionStatsFramingType, Caves, et. al. Standards Track [Page 63] RFC 3371 L2TP Management Information Base August 2002 l2tpSessionStatsPhysChanId, l2tpSessionStatsDNIS, l2tpSessionStatsCLID, l2tpSessionStatsSubAddress, l2tpSessionStatsPrivateGroupID, l2tpSessionStatsProxyLcp, l2tpSessionStatsAuthMethod, l2tpSessionStatsSequencingState, l2tpSessionStatsOutSequence, l2tpSessionStatsReassemblyTO, l2tpSessionStatsTxSeq, l2tpSessionStatsRxSeq } STATUS current DESCRIPTION "A collection of objects providing status and statistics of the L2TP protocol, tunnels and sessions." ::= { l2tpGroups 2 } l2tpIpUdpGroup OBJECT-GROUP OBJECTS { l2tpUdpStatsPeerPort, l2tpUdpStatsLocalPort } STATUS current DESCRIPTION "A collection of objects providing status and statistics of the L2TP UDP/IP transport layer." ::= { l2tpGroups 3 } l2tpDomainGroup OBJECT-GROUP OBJECTS { l2tpDomainConfigAdminState, l2tpDomainConfigDrainTunnels, l2tpDomainConfigTunnelHelloInt, l2tpDomainConfigTunnelIdleTO, l2tpDomainConfigControlRWS, l2tpDomainConfigControlMaxRetx, l2tpDomainConfigControlMaxRetxTO, l2tpDomainConfigPayloadSeq, l2tpDomainConfigReassemblyTO, l2tpDomainConfigProxyPPPAuth, l2tpDomainConfigStorageType, l2tpDomainConfigStatus, l2tpDomainStatsTotalTunnels, l2tpDomainStatsFailedTunnels, l2tpDomainStatsFailedAuths, Caves, et. al. Standards Track [Page 64] RFC 3371 L2TP Management Information Base August 2002 l2tpDomainStatsActiveTunnels, l2tpDomainStatsTotalSessions, l2tpDomainStatsFailedSessions, l2tpDomainStatsActiveSessions, l2tpDomainStatsDrainingTunnels, l2tpDomainStatsControlRxOctets, l2tpDomainStatsControlRxPkts, l2tpDomainStatsControlTxOctets, l2tpDomainStatsControlTxPkts, l2tpDomainStatsPayloadRxOctets, l2tpDomainStatsPayloadRxPkts, l2tpDomainStatsPayloadRxDiscs, l2tpDomainStatsPayloadTxOctets, l2tpDomainStatsPayloadTxPkts } STATUS current DESCRIPTION "A collection of objects providing configuration, status and statistics of L2TP tunnel domains." ::= { l2tpGroups 4 } l2tpMappingGroup OBJECT-GROUP OBJECTS { l2tpTunnelMapIfIndex, l2tpSessionMapTunnelIfIndex, l2tpSessionMapLocalSID, l2tpSessionMapStatus } STATUS current DESCRIPTION "A collection of objects providing index mapping." ::= { l2tpGroups 5 } l2tpSecurityGroup OBJECT-GROUP OBJECTS { l2tpDomainConfigAuth, l2tpDomainConfigSecret, l2tpDomainConfigTunnelSecurity, l2tpTunnelConfigAuth, l2tpTunnelConfigSecret, l2tpTunnelConfigSecurity } STATUS current DESCRIPTION "A collection of objects providing L2TP security configuration." ::= { l2tpGroups 6 } Caves, et. al. Standards Track [Page 65] RFC 3371 L2TP Management Information Base August 2002 l2tpTrapGroup NOTIFICATION-GROUP NOTIFICATIONS { l2tpTunnelAuthFailure } STATUS current DESCRIPTION "A collection of L2TP trap events as specified in NOTIFICATION-TYPE constructs." ::= { l2tpGroups 7 } l2tpHCPacketGroup OBJECT-GROUP OBJECTS { l2tpDomainStatsControlHCRxOctets, l2tpDomainStatsControlHCRxPkts, l2tpDomainStatsControlHCTxOctets, l2tpDomainStatsControlHCTxPkts, l2tpDomainStatsPayloadHCRxOctets, l2tpDomainStatsPayloadHCRxPkts, l2tpDomainStatsPayloadHCRxDiscs, l2tpDomainStatsPayloadHCTxOctets, l2tpDomainStatsPayloadHCTxPkts } STATUS current DESCRIPTION "A collection of objects providing High Capacity 64-bit counter objects." ::= { l2tpGroups 8 } END 5.0 Security Considerations This MIB contains readable objects whose values provide information related to L2TP tunnel interfaces. There are also a number of objects that have a MAX-ACCESS clause of read-write and/or read- create, such as those which allow an administrator to dynamically configure tunnels. While unauthorized access to the readable objects is relatively innocuous, unauthorized access to the write-able objects could cause a denial of service, or could cause unauthorized creation and/or manipulation of tunnels. Hence, the support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Caves, et. al. Standards Track [Page 66] RFC 3371 L2TP Management Information Base August 2002 SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec [RFC2401]), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB. If the agent allows configuring keys (for example the l2tpDomainConfigSecret object) via SNMP, for use by L2TP, then the security of L2TP is at best only as secure as SNMP. For this reason, all objects in the l2tpSecurityGroup MUST NOT be accessible via unencrypted messages. It is also recommended that keys not be made visible through SNMP GET (or GET-NEXT or GET-BULK) messages, even if encryption is used. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 6.0 Acknowledgements Many thanks to the L2TP working group members who provided valuable input into the content and structure of this MIB. 7.0 References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Caves, et. al. Standards Track [Page 67] RFC 3371 L2TP Management Information Base August 2002 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] 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. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] 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. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol - L2TP", RFC 2661, August 1999. Caves, et. al. Standards Track [Page 68] RFC 3371 L2TP Management Information Base August 2002 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2667] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 8.0 Authors' Addresses Evan Caves Occam Networks Inc. 77 Robin Hill Road Santa Barbara, CA 93117 EMail: evan@occamnetworks.com Pat Calhoun Black Storm Networks 110 Nortech Parkway San Jose, CA 95134 EMail: pcalhoun@bstormnetworks.com Ross Wheeler DoubleWide Software, Inc. 2953 Bunker Hill Lane Suite 101 Santa Clara, CA 95054 Email: ross@doublewidesoft.com Caves, et. al. Standards Track [Page 69] RFC 3371 L2TP Management Information Base August 2002 9.0 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Caves, et. al. Standards Track [Page 70] snmp-mibs-downloader-1.1/mibrfcs/rfc3411.txt0000644000000000000000000042150011402176071015554 0ustar Network Working Group D. Harrington Request for Comments: 3411 Enterasys Networks STD: 62 R. Presuhn Obsoletes: 2571 BMC Software, Inc. Category: Standards Track B. Wijnen Lucent Technologies December 2002 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. Table of Contents 1. Introduction ................................................ 4 1.1. Overview .................................................. 4 1.2. SNMP ...................................................... 5 1.3. Goals of this Architecture ................................ 6 1.4. Security Requirements of this Architecture ................ 6 1.5. Design Decisions .......................................... 8 2. Documentation Overview ...................................... 10 2.1. Document Roadmap .......................................... 11 2.2. Applicability Statement ................................... 11 Harrington, et al. Standards Track [Page 1] RFC 3411 Architecture for SNMP Management Frameworks December 2002 2.3. Coexistence and Transition ................................ 11 2.4. Transport Mappings ........................................ 12 2.5. Message Processing ........................................ 12 2.6. Security .................................................. 12 2.7. Access Control ............................................ 13 2.8. Protocol Operations ....................................... 13 2.9. Applications .............................................. 14 2.10. Structure of Management Information ...................... 15 2.11. Textual Conventions ...................................... 15 2.12. Conformance Statements ................................... 15 2.13. Management Information Base Modules ...................... 15 2.13.1. SNMP Instrumentation MIBs .............................. 15 2.14. SNMP Framework Documents ................................. 15 3. Elements of the Architecture ................................ 16 3.1. The Naming of Entities .................................... 17 3.1.1. SNMP engine ............................................. 18 3.1.1.1. snmpEngineID .......................................... 18 3.1.1.2. Dispatcher ............................................ 18 3.1.1.3. Message Processing Subsystem .......................... 19 3.1.1.3.1. Message Processing Model ............................ 19 3.1.1.4. Security Subsystem .................................... 20 3.1.1.4.1. Security Model ...................................... 20 3.1.1.4.2. Security Protocol ................................... 20 3.1.2. Access Control Subsystem ................................ 21 3.1.2.1. Access Control Model .................................. 21 3.1.3. Applications ............................................ 21 3.1.3.1. SNMP Manager .......................................... 22 3.1.3.2. SNMP Agent ............................................ 23 3.2. The Naming of Identities .................................. 25 3.2.1. Principal ............................................... 25 3.2.2. securityName ............................................ 25 3.2.3. Model-dependent security ID ............................. 26 3.3. The Naming of Management Information ...................... 26 3.3.1. An SNMP Context ......................................... 28 3.3.2. contextEngineID ......................................... 28 3.3.3. contextName ............................................. 29 3.3.4. scopedPDU ............................................... 29 3.4. Other Constructs .......................................... 29 3.4.1. maxSizeResponseScopedPDU ................................ 29 3.4.2. Local Configuration Datastore ........................... 29 3.4.3. securityLevel ........................................... 29 4. Abstract Service Interfaces ................................. 30 4.1. Dispatcher Primitives ..................................... 30 4.1.1. Generate Outgoing Request or Notification ............... 31 4.1.2. Process Incoming Request or Notification PDU ............ 31 4.1.3. Generate Outgoing Response .............................. 32 4.1.4. Process Incoming Response PDU ........................... 32 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 32 Harrington, et al. Standards Track [Page 2] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.2. Message Processing Subsystem Primitives ................... 33 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 33 4.2.2. Prepare an Outgoing SNMP Response Message ............... 34 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 35 4.3. Access Control Subsystem Primitives ....................... 35 4.4. Security Subsystem Primitives ............................. 36 4.4.1. Generate a Request or Notification Message .............. 36 4.4.2. Process Incoming Message ................................ 36 4.4.3. Generate a Response Message ............................. 37 4.5. Common Primitives ......................................... 37 4.5.1. Release State Reference Information ..................... 37 4.6. Scenario Diagrams ......................................... 38 4.6.1. Command Generator or Notification Originator ............ 38 4.6.2. Scenario Diagram for a Command Responder Application .... 39 5. Managed Object Definitions for SNMP Management Frameworks ... 40 6. IANA Considerations ......................................... 51 6.1. Security Models ........................................... 51 6.2. Message Processing Models ................................. 51 6.3. SnmpEngineID Formats ...................................... 52 7. Intellectual Property ....................................... 52 8. Acknowledgements ............................................ 52 9. Security Considerations ..................................... 54 10. References ................................................. 54 10.1. Normative References ..................................... 54 10.2. Informative References ................................... 56 A. Guidelines for Model Designers .............................. 57 A.1. Security Model Design Requirements ........................ 57 A.1.1. Threats ................................................. 57 A.1.2. Security Processing ..................................... 58 A.1.3. Validate the security-stamp in a received message ....... 59 A.1.4. Security MIBs ........................................... 59 A.1.5. Cached Security Data .................................... 59 A.2. Message Processing Model Design Requirements .............. 60 A.2.1. Receiving an SNMP Message from the Network .............. 60 A.2.2. Sending an SNMP Message to the Network .................. 60 A.3. Application Design Requirements ........................... 61 A.3.1. Applications that Initiate Messages ..................... 61 A.3.2. Applications that Receive Responses ..................... 62 A.3.3. Applications that Receive Asynchronous Messages ......... 62 A.3.4. Applications that Send Responses ........................ 62 A.4. Access Control Model Design Requirements .................. 63 Editors' Addresses ............................................. 63 Full Copyright Statement ....................................... 64 Harrington, et al. Standards Track [Page 3] RFC 3411 Architecture for SNMP Management Frameworks December 2002 1. Introduction 1.1. Overview This document defines a vocabulary for describing SNMP Management Frameworks, and an architecture for describing the major portions of SNMP Management Frameworks. This document does not provide a general introduction to SNMP. Other documents and books can provide a much better introduction to SNMP. Nor does this document provide a history of SNMP. That also can be found in books and other documents. Section 1 describes the purpose, goals, and design decisions of this architecture. Section 2 describes various types of documents which define (elements of) SNMP Frameworks, and how they fit into this architecture. It also provides a minimal road map to the documents which have previously defined SNMP frameworks. Section 3 details the vocabulary of this architecture and its pieces. This section is important for understanding the remaining sections, and for understanding documents which are written to fit within this architecture. Section 4 describes the primitives used for the abstract service interfaces between the various subsystems, models and applications within this architecture. Section 5 defines a collection of managed objects used to instrument SNMP entities within this architecture. Sections 6, 7, 8, 9, 10 and 11 are administrative in nature. Appendix A contains guidelines for designers of Models which are expected to fit within this architecture. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Harrington, et al. Standards Track [Page 4] RFC 3411 Architecture for SNMP Management Frameworks December 2002 1.2. SNMP An SNMP management system contains: - several (potentially many) nodes, each with an SNMP entity containing command responder and notification originator applications, which have access to management instrumentation (traditionally called agents); - at least one SNMP entity containing command generator and/or notification receiver applications (traditionally called a manager) and, - a management protocol, used to convey management information between the SNMP entities. SNMP entities executing command generator and notification receiver applications monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. It is the purpose of this document to define an architecture which can evolve to realize effective management in a variety of configurations and environments. The architecture has been designed to meet the needs of implementations of: - minimal SNMP entities with command responder and/or notification originator applications (traditionally called SNMP agents), - SNMP entities with proxy forwarder applications (traditionally called SNMP proxy agents), - command line driven SNMP entities with command generator and/or notification receiver applications (traditionally called SNMP command line managers), - SNMP entities with command generator and/or notification receiver, plus command responder and/or notification originator applications (traditionally called SNMP mid-level managers or dual-role entities), - SNMP entities with command generator and/or notification receiver and possibly other types of applications for managing a potentially very large number of managed nodes (traditionally called (network) management stations). Harrington, et al. Standards Track [Page 5] RFC 3411 Architecture for SNMP Management Frameworks December 2002 1.3. Goals of this Architecture This architecture was driven by the following goals: - Use existing materials as much as possible. It is heavily based on previous work, informally known as SNMPv2u and SNMPv2*, based in turn on SNMPv2p. - Address the need for secure SET support, which is considered the most important deficiency in SNMPv1 and SNMPv2c. - Make it possible to move portions of the architecture forward in the standards track, even if consensus has not been reached on all pieces. - Define an architecture that allows for longevity of the SNMP Frameworks that have been and will be defined. - Keep SNMP as simple as possible. - Make it relatively inexpensive to deploy a minimal conforming implementation. - Make it possible to upgrade portions of SNMP as new approaches become available, without disrupting an entire SNMP framework. - Make it possible to support features required in large networks, but make the expense of supporting a feature directly related to the support of the feature. 1.4. Security Requirements of this Architecture Several of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to any Security Model used in an SNMP Management Framework. Other threats are not applicable to the management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which any Security Model used within this architecture SHOULD provide protection are: Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object. Harrington, et al. Standards Track [Page 6] RFC 3411 Architecture for SNMP Management Frameworks December 2002 Masquerade The masquerade threat is the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal that has the appropriate authorizations. Secondary threats against which any Security Model used within this architecture SHOULD provide protection are: Message Stream Modification The SNMP protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations. Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines. Protecting against this threat may be required as a matter of local policy. There are at least two threats against which a Security Model within this architecture need not protect, since they are deemed to be of lesser importance in this context: Denial of Service A Security Model need not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable management protocol must cope as a matter of course. Traffic Analysis A Security Model need not attempt to address traffic analysis attacks. Many traffic patterns are predictable - entities may be managed on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis. Harrington, et al. Standards Track [Page 7] RFC 3411 Architecture for SNMP Management Frameworks December 2002 1.5. Design Decisions Various design decisions were made in support of the goals of the architecture and the security requirements: - Architecture An architecture should be defined which identifies the conceptual boundaries between the documents. Subsystems should be defined which describe the abstract services provided by specific portions of an SNMP framework. Abstract service interfaces, as described by service primitives, define the abstract boundaries between documents, and the abstract services that are provided by the conceptual subsystems of an SNMP framework. - Self-contained Documents Elements of procedure plus the MIB objects which are needed for processing for a specific portion of an SNMP framework should be defined in the same document, and as much as possible, should not be referenced in other documents. This allows pieces to be designed and documented as independent and self- contained parts, which is consistent with the general SNMP MIB module approach. As portions of SNMP change over time, the documents describing other portions of SNMP are not directly impacted. This modularity allows, for example, Security Models, authentication and privacy mechanisms, and message formats to be upgraded and supplemented as the need arises. The self-contained documents can move along the standards track on different time-lines. This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation. - Threats The Security Models in the Security Subsystem SHOULD protect against the principal and secondary threats: modification of information, masquerade, message stream modification and disclosure. They do not need to protect against denial of service and traffic analysis. - Remote Configuration The Security and Access Control Subsystems add a whole new set of SNMP configuration parameters. The Security Subsystem also requires frequent changes of secrets at the various SNMP entities. To make this deployable in a large operational environment, these SNMP parameters must be remotely configurable. Harrington, et al. Standards Track [Page 8] RFC 3411 Architecture for SNMP Management Frameworks December 2002 - Controlled Complexity It is recognized that producers of simple managed devices want to keep the resources used by SNMP to a minimum. At the same time, there is a need for more complex configurations which can spend more resources for SNMP and thus provide more functionality. The design tries to keep the competing requirements of these two environments in balance and allows the more complex environments to logically extend the simple environment. Harrington, et al. Standards Track [Page 9] RFC 3411 Architecture for SNMP Management Frameworks December 2002 2. Documentation Overview The following figure shows the set of documents that fit within the SNMP Architecture. +------------------------- Document Set ----------------------------+ | | | +----------+ +-----------------+ +----------------+ | | | Document | | Applicability | | Coexistence | | | | Roadmap | | Statement | | & Transition | | | +----------+ +-----------------+ +----------------+ | | | | +---------------------------------------------------------------+ | | | Message Handling | | | | +----------------+ +-----------------+ +-----------------+ | | | | | Transport | | Message | | Security | | | | | | Mappings | | Processing and | | | | | | | | | | Dispatcher | | | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | PDU Handling | | | | +----------------+ +-----------------+ +-----------------+ | | | | | Protocol | | Applications | | Access | | | | | | Operations | | | | Control | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | Information Model | | | | +--------------+ +--------------+ +---------------+ | | | | | Structure of | | Textual | | Conformance | | | | | | Management | | Conventions | | Statements | | | | | | Information | | | | | | | | | +--------------+ +--------------+ +---------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | MIB Modules written in various formats, e.g.: | | | | +----------------+ +----------------+ | | | | | SMIv1 (STD 18) | | SMIv2 (STD 58) | | | | | | format | | format | | | | | +----------------+ +----------------+ | | | +---------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ Harrington, et al. Standards Track [Page 10] RFC 3411 Architecture for SNMP Management Frameworks December 2002 Each of these documents may be replaced or supplemented. This Architecture document specifically describes how new documents fit into the set of documents in the area of Message and PDU handling. 2.1. Document Roadmap One or more documents may be written to describe how sets of documents taken together form specific Frameworks. The configuration of document sets might change over time, so the "road map" should be maintained in a document separate from the standards documents themselves. An example of such a roadmap is "Introduction and Applicability Statements for the Internet-Standard Management Framework" [RFC3410]. 2.2. Applicability Statement SNMP is used in networks that vary widely in size and complexity, by organizations that vary widely in their requirements of management. Some models will be designed to address specific problems of management, such as message security. One or more documents may be written to describe the environments to which certain versions of SNMP or models within SNMP would be appropriately applied, and those to which a given model might be inappropriately applied. 2.3. Coexistence and Transition The purpose of an evolutionary architecture is to permit new models to replace or supplement existing models. The interactions between models could result in incompatibilities, security "holes", and other undesirable effects. The purpose of Coexistence documents is to detail recognized anomalies and to describe required and recommended behaviors for resolving the interactions between models within the architecture. Coexistence documents may be prepared separately from model definition documents, to describe and resolve interaction anomalies between a model definition and one or more other model definitions. Additionally, recommendations for transitions between models may also be described, either in a coexistence document or in a separate document. Harrington, et al. Standards Track [Page 11] RFC 3411 Architecture for SNMP Management Frameworks December 2002 One such coexistence document is [RFC2576], "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework". 2.4. Transport Mappings SNMP messages are sent over various transports. It is the purpose of Transport Mapping documents to define how the mapping between SNMP and the transport is done. 2.5. Message Processing A Message Processing Model document defines a message format, which is typically identified by a version field in an SNMP message header. The document may also define a MIB module for use in message processing and for instrumentation of version-specific interactions. An SNMP engine includes one or more Message Processing Models, and thus may support sending and receiving multiple versions of SNMP messages. 2.6. Security Some environments require secure protocol interactions. Security is normally applied at two different stages: - in the transmission/receipt of messages, and - in the processing of the contents of messages. For purposes of this document, "security" refers to message-level security; "access control" refers to the security applied to protocol operations. Authentication, encryption, and timeliness checking are common functions of message level security. A security document describes a Security Model, the threats against which the model protects, the goals of the Security Model, the protocols which it uses to meet those goals, and it may define a MIB module to describe the data used during processing, and to allow the remote configuration of message-level security parameters, such as keys. An SNMP engine may support multiple Security Models concurrently. Harrington, et al. Standards Track [Page 12] RFC 3411 Architecture for SNMP Management Frameworks December 2002 2.7. Access Control During processing, it may be required to control access to managed objects for operations. An Access Control Model defines mechanisms to determine whether access to a managed object should be allowed. An Access Control Model may define a MIB module used during processing and to allow the remote configuration of access control policies. 2.8. Protocol Operations SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP PDUs define the operations performed by the receiving SNMP engine. It is the purpose of a Protocol Operations document to define the operations of the protocol with respect to the processing of the PDUs. Every PDU belongs to one or more of the PDU classes defined below: 1) Read Class: The Read Class contains protocol operations that retrieve management information. For example, [RFC3416] defines the following protocol operations for the Read Class: GetRequest- PDU, GetNextRequest-PDU, and GetBulkRequest-PDU. 2) Write Class: The Write Class contains protocol operations which attempt to modify management information. For example, [RFC3416] defines the following protocol operation for the Write Class: SetRequest-PDU. 3) Response Class: The Response Class contains protocol operations which are sent in response to a previous request. For example, [RFC3416] defines the following for the Response Class: Response-PDU, Report-PDU. 4) Notification Class: The Notification Class contains protocol operations which send a notification to a notification receiver application. For example, [RFC3416] defines the following operations for the Notification Class: Trapv2-PDU, InformRequest-PDU. Harrington, et al. Standards Track [Page 13] RFC 3411 Architecture for SNMP Management Frameworks December 2002 5) Internal Class: The Internal Class contains protocol operations which are exchanged internally between SNMP engines. For example, [RFC3416] defines the following operation for the Internal Class: Report-PDU. The preceding five classifications are based on the functional properties of a PDU. It is also useful to classify PDUs based on whether a response is expected: 6) Confirmed Class: The Confirmed Class contains all protocol operations which cause the receiving SNMP engine to send back a response. For example, [RFC3416] defines the following operations for the Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU. 7) Unconfirmed Class: The Unconfirmed Class contains all protocol operations which are not acknowledged. For example, [RFC3416] defines the following operations for the Unconfirmed Class: Report-PDU, Trapv2-PDU, and GetResponse-PDU. An application document defines which Protocol Operations are supported by the application. 2.9. Applications An SNMP entity normally includes a number of applications. Applications use the services of an SNMP engine to accomplish specific tasks. They coordinate the processing of management information operations, and may use SNMP messages to communicate with other SNMP entities. An applications document describes the purpose of an application, the services required of the associated SNMP engine, and the protocol operations and informational model that the application uses to perform management operations. An application document defines which set of documents are used to specifically define the structure of management information, textual conventions, conformance requirements, and operations supported by the application. Harrington, et al. Standards Track [Page 14] RFC 3411 Architecture for SNMP Management Frameworks December 2002 2.10. Structure of Management Information Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. It is the purpose of a Structure of Management Information document to establish the notation for defining objects, modules, and other elements of managed information. 2.11. Textual Conventions When designing a MIB module, it is often useful to define new types similar to those defined in the SMI, but with more precise semantics, or which have special semantics associated with them. These newly defined types are termed textual conventions, and may be defined in separate documents, or within a MIB module. 2.12. Conformance Statements It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of the Conformance Statements document to define the notation used for these purposes. 2.13. Management Information Base Modules MIB documents describe collections of managed objects which instrument some aspect of a managed node. 2.13.1. SNMP Instrumentation MIBs An SNMP MIB document may define a collection of managed objects which instrument the SNMP protocol itself. In addition, MIB modules may be defined within the documents which describe portions of the SNMP architecture, such as the documents for Message processing Models, Security Models, etc. for the purpose of instrumenting those Models, and for the purpose of allowing their remote configuration. 2.14. SNMP Framework Documents This architecture is designed to allow an orderly evolution of portions of SNMP Frameworks. Throughout the rest of this document, the term "subsystem" refers to an abstract and incomplete specification of a portion of a Framework, that is further refined by a model specification. Harrington, et al. Standards Track [Page 15] RFC 3411 Architecture for SNMP Management Frameworks December 2002 A "model" describes a specific design of a subsystem, defining additional constraints and rules for conformance to the model. A model is sufficiently detailed to make it possible to implement the specification. An "implementation" is an instantiation of a subsystem, conforming to one or more specific models. SNMP version 1 (SNMPv1), is the original Internet-Standard Network Management Framework, as described in RFCs 1155, 1157, and 1212. SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580, and STD 62, RFCs 3416, 3417, and 3418. SNMPv2 has no message definition. The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP Framework which supplements the SNMPv2 Framework, as described in [RFC1901]. It adds the SNMPv2c message format, which is similar to the SNMPv1 message format. SNMP version 3 (SNMPv3), is an extensible SNMP Framework which supplements the SNMPv2 Framework, by supporting the following: - a new SNMP message format, - Security for Messages, - Access Control, and - Remote configuration of SNMP parameters. Other SNMP Frameworks, i.e., other configurations of implemented subsystems, are expected to also be consistent with this architecture. 3. Elements of the Architecture This section describes the various elements of the architecture and how they are named. There are three kinds of naming: 1) the naming of entities, 2) the naming of identities, and 3) the naming of management information. Harrington, et al. Standards Track [Page 16] RFC 3411 Architecture for SNMP Management Frameworks December 2002 This architecture also defines some names for other constructs that are used in the documentation. 3.1. The Naming of Entities An SNMP entity is an implementation of this architecture. Each such SNMP entity consists of an SNMP engine and one or more associated applications. The following figure shows details about an SNMP entity and the components within it. +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ Harrington, et al. Standards Track [Page 17] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.1.1. SNMP engine An SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects. There is a one-to-one association between an SNMP engine and the SNMP entity which contains it. The engine contains: 1) a Dispatcher, 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem. 3.1.1.1. snmpEngineID Within an administrative domain, an snmpEngineID is the unique and unambiguous identifier of an SNMP engine. Since there is a one-to- one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within that administrative domain. Note that it is possible for SNMP entities in different administrative domains to have the same value for snmpEngineID. Federation of administrative domains may necessitate assignment of new values. 3.1.1.2. Dispatcher There is only one Dispatcher in an SNMP engine. It allows for concurrent support of multiple versions of SNMP messages in the SNMP engine. It does so by: - sending and receiving SNMP messages to/from the network, - determining the version of an SNMP message and interacting with the corresponding Message Processing Model, - providing an abstract interface to SNMP applications for delivery of a PDU to an application. - providing an abstract interface for SNMP applications that allows them to send a PDU to a remote SNMP entity. Harrington, et al. Standards Track [Page 18] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.1.1.3. Message Processing Subsystem The Message Processing Subsystem is responsible for preparing messages for sending, and extracting data from received messages. The Message Processing Subsystem potentially contains multiple Message Processing Models as shown in the next figure. * One or more Message Processing Models may be present. +------------------------------------------------------------------+ | | | Message Processing Subsystem | | | | +------------+ +------------+ +------------+ +------------+ | | | * | | * | | * | | * | | | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | | | Message | | Message | | Message | | Message | | | | Processing | | Processing | | Processing | | Processing | | | | Model | | Model | | Model | | Model | | | | | | | | | | | | | +------------+ +------------+ +------------+ +------------+ | | | +------------------------------------------------------------------+ 3.1.1.3.1. Message Processing Model Each Message Processing Model defines the format of a particular version of an SNMP message and coordinates the preparation and extraction of each such version-specific message format. Harrington, et al. Standards Track [Page 19] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.1.1.4. Security Subsystem The Security Subsystem provides security services such as the authentication and privacy of messages and potentially contains multiple Security Models as shown in the following figure * One or more Security Models may be present. +------------------------------------------------------------------+ | | | Security Subsystem | | | | +----------------+ +-----------------+ +-------------------+ | | | * | | * | | * | | | | User-Based | | Other | | Other | | | | Security | | Security | | Security | | | | Model | | Model | | Model | | | | | | | | | | | +----------------+ +-----------------+ +-------------------+ | | | +------------------------------------------------------------------+ 3.1.1.4.1. Security Model A Security Model specifies the threats against which it protects, the goals of its services, and the security protocols used to provide security services such as authentication and privacy. 3.1.1.4.2. Security Protocol A Security Protocol specifies the mechanisms, procedures, and MIB objects used to provide a security service such as authentication or privacy. Harrington, et al. Standards Track [Page 20] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.1.2. Access Control Subsystem The Access Control Subsystem provides authorization services by means of one or more (*) Access Control Models. +------------------------------------------------------------------+ | | | Access Control Subsystem | | | | +---------------+ +-----------------+ +------------------+ | | | * | | * | | * | | | | View-Based | | Other | | Other | | | | Access | | Access | | Access | | | | Control | | Control | | Control | | | | Model | | Model | | Model | | | | | | | | | | | +---------------+ +-----------------+ +------------------+ | | | +------------------------------------------------------------------+ 3.1.2.1. Access Control Model An Access Control Model defines a particular access decision function in order to support decisions regarding access rights. 3.1.3. Applications There are several types of applications, including: - command generators, which monitor and manipulate management data, - command responders, which provide access to management data, - notification originators, which initiate asynchronous messages, - notification receivers, which process asynchronous messages, and - proxy forwarders, which forward messages between entities. These applications make use of the services provided by the SNMP engine. Harrington, et al. Standards Track [Page 21] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.1.3.1. SNMP Manager An SNMP entity containing one or more command generator and/or notification receiver applications (along with their associated SNMP engine) has traditionally been called an SNMP manager. (traditional SNMP manager) +-------------------------------------------------------------------+ | +--------------+ +--------------+ +--------------+ SNMP entity | | | NOTIFICATION | | NOTIFICATION | | COMMAND | | | | ORIGINATOR | | RECEIVER | | GENERATOR | | | | applications | | applications | | applications | | | +--------------+ +--------------+ +--------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------+--------+-----------------+ | | ^ | | | +---------------------+ +----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +-------------------+ | +------------+ | | | | | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | | | | | | +------------+ | | | Other | | | | | | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +------------+ | | | | Dispatcher <--------->+ | | | | | | | | | +------------+ | | +------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | Transport | | | +------------+ | | | Security | | | | | Mapping | | | +------------+ | | | Model | | | | | (e.g., RFC 3417) | | +->| otherMP * |<--->| +------------+ | | | +-------------------+ | +------------+ | | | | | ^ +---------------------+ +----------------+ | | | | | v | +-------------------------------------------------------------------+ +-----+ +-----+ +-------+ | UDP | | IPX | . . . | other | +-----+ +-----+ +-------+ ^ ^ ^ | | | * One or more models may be present. v v v +------------------------------+ | Network | +------------------------------+ Harrington, et al. Standards Track [Page 22] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.1.3.2. SNMP Agent An SNMP entity containing one or more command responder and/or notification originator applications (along with their associated SNMP engine) has traditionally been called an SNMP agent. Harrington, et al. Standards Track [Page 23] RFC 3411 Architecture for SNMP Management Frameworks December 2002 * One or more models may be present. +------------------------------+ | Network | +------------------------------+ ^ ^ ^ | | | v v v +-----+ +-----+ +-------+ | UDP | | IPX | . . . | other | +-----+ +-----+ +-------+ (traditional SNMP agent) +-------------------------------------------------------------------+ | ^ | | | +---------------------+ +----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +-------------------+ | +------------+ | | | | | | Transport | | +->| v1MP * |<--->| +------------+ | | | | Mapping | | | +------------+ | | | Other | | | | | (e.g., RFC 3417) | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +------------+ | | | | Dispatcher <--------->| +------------+ | | +------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | | | | +------------+ | | | Security | | | | | PDU Dispatcher | | | +------------+ | | | Model | | | | +-------------------+ | +->| otherMP * |<--->| +------------+ | | | ^ | +------------+ | | | | | | +---------------------+ +----------------+ | | v | | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------------+ +---------+ +--------------+ +-------------+ | | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | | | application | | | | applications | | application | | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | v v | | +----------------------------------------------+ | | | MIB instrumentation | SNMP entity | +-------------------------------------------------------------------+ Harrington, et al. Standards Track [Page 24] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.2. The Naming of Identities principal ^ | | +----------------------------|-------------+ | SNMP engine v | | +--------------+ | | | | | | +-----------------| securityName |---+ | | | Security Model | | | | | | +--------------+ | | | | ^ | | | | | | | | | v | | | | +------------------------------+ | | | | | | | | | | | Model | | | | | | Dependent | | | | | | Security ID | | | | | | | | | | | +------------------------------+ | | | | ^ | | | | | | | | +-------------------------|----------+ | | | | | | | +----------------------------|-------------+ | v network 3.2.1. Principal A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications; and combinations thereof. 3.2.2. securityName A securityName is a human readable string representing a principal. It has a model-independent format, and can be used outside a particular Security Model. Harrington, et al. Standards Track [Page 25] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.2.3. Model-dependent security ID A model-dependent security ID is the model-specific representation of a securityName within a particular Security Model. Model-dependent security IDs may or may not be human readable, and have a model-dependent syntax. Examples include community names, and user names. The transformation of model-dependent security IDs into securityNames and vice versa is the responsibility of the relevant Security Model. 3.3. The Naming of Management Information Management information resides at an SNMP entity where a Command Responder Application has local access to potentially multiple contexts. This application uses a contextEngineID equal to the snmpEngineID of its associated SNMP engine. Harrington, et al. Standards Track [Page 26] RFC 3411 Architecture for SNMP Management Frameworks December 2002 +-----------------------------------------------------------------+ | SNMP entity (identified by snmpEngineID, for example: | | '800002b804616263'H (enterpise 696, string "abc") | | | | +------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | +------------------------------------------------------------+ | | | | +------------------------------------------------------------+ | | | Command Responder Application | | | | (contextEngineID, example: '800002b804616263'H) | | | | | | | | example contextNames: | | | | | | | | "bridge1" "bridge2" "" (default) | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context | | context | | context | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | other MIB | | | | | | | | | | | +------------+ | | | | | | | | | | | | | +-----------------------------------------------------------------+ Harrington, et al. Standards Track [Page 27] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.3.1. An SNMP Context An SNMP context, or just "context" for short, is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts. Typically, there are many instances of each managed object type within a management domain. For simplicity, the method for identifying instances specified by the MIB module does not allow each instance to be distinguished amongst the set of all instances within a management domain; rather, it allows each instance to be identified only within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical device, or perhaps, a logical device, although a context can also encompass multiple devices, or a subset of a single device, or even a subset of multiple devices, but a context is always defined as a subset of a single SNMP entity. Thus, in order to identify an individual item of management information within the management domain, its contextName and contextEngineID must be identified in addition to its object type and its instance. For example, the managed object type ifDescr [RFC2863], is defined as the description of a network interface. To identify the description of device-X's first network interface, four pieces of information are needed: the snmpEngineID of the SNMP entity which provides access to the management information at device-X, the contextName (device-X), the managed object type (ifDescr), and the instance ("1"). Each context has (at least) one unique identification within the management domain. The same item of management information can exist in multiple contexts. An item of management information may have multiple unique identifications. This occurs when an item of management information exists in multiple contexts, and this also occurs when a context has multiple unique identifications. The combination of a contextEngineID and a contextName unambiguously identifies a context within an administrative domain; note that there may be multiple unique combinations of contextEngineID and contextName that unambiguously identify the same context. 3.3.2. contextEngineID Within an administrative domain, a contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName. Harrington, et al. Standards Track [Page 28] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3.3.3. contextName A contextName is used to name a context. Each contextName MUST be unique within an SNMP entity. 3.3.4. scopedPDU A scopedPDU is a block of data containing a contextEngineID, a contextName, and a PDU. The PDU is an SNMP Protocol Data Unit containing information named in the context which is unambiguously identified within an administrative domain by the combination of the contextEngineID and the contextName. See, for example, RFC 3416 for more information about SNMP PDUs. 3.4. Other Constructs 3.4.1. maxSizeResponseScopedPDU The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that a PDU's sender would be willing to accept. Note that the size of a scopedPDU does not include the size of the SNMP message header. 3.4.2. Local Configuration Datastore The subsystems, models, and applications within an SNMP entity may need to retain their own sets of configuration information. Portions of the configuration information may be accessible as managed objects. The collection of these sets of information is referred to as an entity's Local Configuration Datastore (LCD). 3.4.3. securityLevel This architecture recognizes three levels of security: - without authentication and without privacy (noAuthNoPriv) - with authentication but without privacy (authNoPriv) - with authentication and with privacy (authPriv) Harrington, et al. Standards Track [Page 29] RFC 3411 Architecture for SNMP Management Frameworks December 2002 These three values are ordered such that noAuthNoPriv is less than authNoPriv and authNoPriv is less than authPriv. Every message has an associated securityLevel. All Subsystems (Message Processing, Security, Access Control) and applications are REQUIRED to either supply a value of securityLevel or to abide by the supplied value of securityLevel while processing the message and its contents. 4. Abstract Service Interfaces Abstract service interfaces have been defined to describe the conceptual interfaces between the various subsystems within an SNMP entity. The abstract service interfaces are intended to help clarify the externally observable behavior of SNMP entities, and are not intended to constrain the structure or organization of implementations in any way. Most specifically, they should not be interpreted as APIs or as requirements statements for APIs. These abstract service interfaces are defined by a set of primitives that define the services provided and the abstract data elements that are to be passed when the services are invoked. This section lists the primitives that have been defined for the various subsystems. 4.1. Dispatcher Primitives The Dispatcher typically provides services to the SNMP applications via its PDU Dispatcher. This section describes the primitives provided by the PDU Dispatcher. Harrington, et al. Standards Track [Page 30] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.1.1. Generate Outgoing Request or Notification The PDU Dispatcher provides the following primitive for an application to send an SNMP Request or Notification to another SNMP entity: statusInformation = -- sendPduHandle if success -- errorIndication if failure sendPdu( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE ) 4.1.2. Process Incoming Request or Notification PDU The PDU Dispatcher provides the following primitive to pass an incoming SNMP PDU to an application: processPdu( -- process Request/Notification PDU IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size of the Response PDU IN stateReference -- reference to state information ) -- needed when sending a response Harrington, et al. Standards Track [Page 31] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.1.3. Generate Outgoing Response The PDU Dispatcher provides the following primitive for an application to return an SNMP Response PDU to the PDU Dispatcher: result = -- SUCCESS or FAILURE returnResponsePdu( IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size sender can accept IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication ) -- error counter OID/value if error 4.1.4. Process Incoming Response PDU The PDU Dispatcher provides the following primitive to pass an incoming SNMP Response PDU to an application: processResponsePdu( -- process Response PDU IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN statusInformation -- success or errorIndication IN sendPduHandle -- handle from sendPdu ) 4.1.5. Registering Responsibility for Handling SNMP PDUs Applications can register/unregister responsibility for a specific contextEngineID, for specific pduTypes, with the PDU Dispatcher according to the following primitives. The list of particular pduTypes that an application can register for is determined by the Message Processing Model(s) supported by the SNMP entity that contains the PDU Dispatcher. Harrington, et al. Standards Track [Page 32] RFC 3411 Architecture for SNMP Management Frameworks December 2002 statusInformation = -- success or errorIndication registerContextEngineID( IN contextEngineID -- take responsibility for this one IN pduType -- the pduType(s) to be registered ) unregisterContextEngineID( IN contextEngineID -- give up responsibility for this one IN pduType -- the pduType(s) to be unregistered ) Note that realizations of the registerContextEngineID and unregisterContextEngineID abstract service interfaces may provide implementation-specific ways for applications to register/deregister responsibility for all possible values of the contextEngineID or pduType parameters. 4.2. Message Processing Subsystem Primitives The Dispatcher interacts with a Message Processing Model to process a specific version of an SNMP Message. This section describes the primitives provided by the Message Processing Subsystem. 4.2.1. Prepare Outgoing SNMP Request or Notification Message The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Request or Notification Message: statusInformation = -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE IN sendPduHandle -- the handle for matching -- incoming responses OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length ) Harrington, et al. Standards Track [Page 33] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.2.2. Prepare an Outgoing SNMP Response Message The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Response Message: result = -- SUCCESS or FAILURE prepareResponseMessage( IN messageProcessingModel -- typically, SNMP version IN securityModel -- same as on incoming request IN securityName -- same as on incoming request IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size able to accept IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication -- error counter OID/value if error OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length ) Harrington, et al. Standards Track [Page 34] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.2.3. Prepare Data Elements from an Incoming SNMP Message The Message Processing Subsystem provides this service primitive for preparing the abstract data elements from an incoming SNMP message: result = -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for possible Response ) 4.3. Access Control Subsystem Primitives Applications are the typical clients of the service(s) of the Access Control Subsystem. The following primitive is provided by the Access Control Subsystem to check if access is allowed: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) Harrington, et al. Standards Track [Page 35] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.4. Security Subsystem Primitives The Message Processing Subsystem is the typical client of the services of the Security Subsystem. 4.4.1. Generate a Request or Notification Message The Security Subsystem provides the following primitive to generate a Request or Notification message: statusInformation = generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of the generated message ) 4.4.2. Process Incoming Message The Security Subsystem provides the following primitive to process an incoming message: statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response Harrington, et al. Standards Track [Page 36] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.4.3. Generate a Response Message The Security Subsystem provides the following primitive to generate a Response message: statusInformation = generateResponseMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- for the outgoing message IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state -- information from original request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of the generated message ) 4.5. Common Primitives These primitive(s) are provided by multiple Subsystems. 4.5.1. Release State Reference Information All Subsystems which pass stateReference information also provide a primitive to release the memory that holds the referenced state information: stateRelease( IN stateReference -- handle of reference to be released ) Harrington, et al. Standards Track [Page 37] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.6. Scenario Diagrams 4.6.1. Command Generator or Notification Originator This diagram shows how a Command Generator or Notification Originator application requests that a PDU be sent, and how the response is returned (asynchronously) to that application. Command Dispatcher Message Security Generator | Processing Model | | Model | | sendPdu | | | |------------------->| | | | | prepareOutgoingMessage | | : |----------------------->| | : | | generateRequestMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | : | | | : |------------------+ | | : | Send SNMP | | | : | Request Message | | | : | to Network | | | : | v | | : : : : : : : : : : : : : : : : | | | | : | Receive SNMP | | | : | Response Message | | | : | from Network | | | : |<-----------------+ | | : | | | : | prepareDataElements | | : |----------------------->| | : | | processIncomingMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | | processResponsePdu | | | |<-------------------| | | | | | | Harrington, et al. Standards Track [Page 38] RFC 3411 Architecture for SNMP Management Frameworks December 2002 4.6.2. Scenario Diagram for a Command Responder Application This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after an SNMP message is received, and how the Response is (asynchronously) send back to the network. Command Dispatcher Message Security Responder | Processing Model | | Model | | | | | | registerContextEngineID | | | |------------------------>| | | |<------------------------| | | | | | Receive SNMP | | | : | Message | | | : | from Network | | | : |<-------------+ | | : | | | : |prepareDataElements | | : |------------------->| | : | | processIncomingMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | | processPdu | | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu | | | |------------------------>| | | : | prepareResponseMsg | | : |------------------->| | : | |generateResponseMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | : | | | : |--------------+ | | : | Send SNMP | | | : | Message | | | : | to Network | | | : | v | | Harrington, et al. Standards Track [Page 39] RFC 3411 Architecture for SNMP Management Frameworks December 2002 5. Managed Object Definitions for SNMP Management Frameworks SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpFrameworkMIB MODULE-IDENTITY LAST-UPDATED "200210140000Z" ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com Subscribe: snmpv3-request@lists.tislabs.com Co-Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA EMail: mundy@tislabs.com phone: +1 301-947-7107 Co-Chair & Co-editor: David Harrington Enterasys Networks postal: 35 Industrial Way P. O. Box 5005 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com phone: +1 603-337-2614 Co-editor: Randy Presuhn BMC Software, Inc. postal: 2141 North First Street San Jose, California 95131 USA EMail: randy_presuhn@bmc.com phone: +1 408-546-1006 Co-editor: Bert Wijnen Lucent Technologies postal: Schagen 33 3461 GL Linschoten Netherlands Harrington, et al. Standards Track [Page 40] RFC 3411 Architecture for SNMP Management Frameworks December 2002 EMail: bwijnen@lucent.com phone: +31 348-680-485 " DESCRIPTION "The SNMP Management Architecture MIB Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3411; see the RFC itself for full legal notices. " REVISION "200210140000Z" -- 14 October 2002 DESCRIPTION "Changes in this revision: - Updated various administrative information. - Corrected some typos. - Corrected typo in description of SnmpEngineID that led to range overlap for 127. - Changed '255a' to '255t' in definition of SnmpAdminString to align with current SMI. - Reworded 'reserved' for value zero in DESCRIPTION of SnmpSecurityModel. - The algorithm for allocating security models should give 256 per enterprise block, rather than 255. - The example engine ID of 'abcd' is not legal. Replaced with '800002b804616263'H based on example enterprise 696, string 'abc'. - Added clarification that engineID should persist across re-initializations. This revision published as RFC 3411. " REVISION "199901190000Z" -- 19 January 1999 DESCRIPTION "Updated editors' addresses, fixed typos. Published as RFC 2571. " REVISION "199711200000Z" -- 20 November 1997 DESCRIPTION "The initial version, published in RFC 2271. " ::= { snmpModules 10 } -- Textual Conventions used in the SNMP Management Architecture *** SnmpEngineID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP engine's administratively-unique identifier. Objects of this type are for identification, not for addressing, even though it is possible that an address may have been used in the generation of a specific value. Harrington, et al. Standards Track [Page 41] RFC 3411 Architecture for SNMP Management Frameworks December 2002 The value for this object may not be all zeros or all 'ff'H or the empty (zero length) string. The initial value for this object may be configured via an operator console entry or via an algorithmic function. In the latter case, the following example algorithm is recommended. In cases where there are multiple engines on the same system, the use of this algorithm is NOT appropriate, as it would result in all of those engines ending up with the same ID value. 1) The very first bit is used to indicate how the rest of the data is composed. 0 - as defined by enterprise using former methods that existed before SNMPv3. See item 2 below. 1 - as defined by this architecture, see item 3 below. Note that this allows existing uses of the engineID (also known as AgentID [RFC1910]) to co-exist with any new uses. 2) The snmpEngineID has a length of 12 octets. The first four octets are set to the binary equivalent of the agent's SNMP management private enterprise number as assigned by the Internet Assigned Numbers Authority (IANA). For example, if Acme Networks has been assigned { enterprises 696 }, the first four octets would be assigned '000002b8'H. The remaining eight octets are determined via one or more enterprise-specific methods. Such methods must be designed so as to maximize the possibility that the value of this object will be unique in the agent's administrative domain. For example, it may be the IP address of the SNMP entity, or the MAC address of one of the interfaces, with each address suitably padded with random octets. If multiple methods are defined, then it is recommended that the first octet indicate the method being used and the remaining octets be a function of the method. Harrington, et al. Standards Track [Page 42] RFC 3411 Architecture for SNMP Management Frameworks December 2002 3) The length of the octet string varies. The first four octets are set to the binary equivalent of the agent's SNMP management private enterprise number as assigned by the Internet Assigned Numbers Authority (IANA). For example, if Acme Networks has been assigned { enterprises 696 }, the first four octets would be assigned '000002b8'H. The very first bit is set to 1. For example, the above value for Acme Networks now changes to be '800002b8'H. The fifth octet indicates how the rest (6th and following octets) are formatted. The values for the fifth octet are: 0 - reserved, unused. 1 - IPv4 address (4 octets) lowest non-special IP address 2 - IPv6 address (16 octets) lowest non-special IP address 3 - MAC address (6 octets) lowest IEEE MAC address, canonical order 4 - Text, administratively assigned Maximum remaining length 27 5 - Octets, administratively assigned Maximum remaining length 27 6-127 - reserved, unused 128-255 - as defined by the enterprise Maximum remaining length 27 " SYNTAX OCTET STRING (SIZE(5..32)) Harrington, et al. Standards Track [Page 43] RFC 3411 Architecture for SNMP Management Frameworks December 2002 SnmpSecurityModel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An identifier that uniquely identifies a Security Model of the Security Subsystem within this SNMP Management Architecture. The values for securityModel are allocated as follows: - The zero value does not identify any particular security model. - Values between 1 and 255, inclusive, are reserved for standards-track Security Models and are managed by the Internet Assigned Numbers Authority (IANA). - Values greater than 255 are allocated to enterprise-specific Security Models. An enterprise-specific securityModel value is defined to be: enterpriseID * 256 + security model within enterprise For example, the fourth Security Model defined by the enterprise whose enterpriseID is 1 would be 259. This scheme for allocation of securityModel values allows for a maximum of 255 standards- based Security Models, and for a maximum of 256 Security Models per enterprise. It is believed that the assignment of new securityModel values will be rare in practice because the larger the number of simultaneously utilized Security Models, the larger the chance that interoperability will suffer. Consequently, it is believed that such a range will be sufficient. In the unlikely event that the standards committee finds this number to be insufficient over time, an enterprise number can be allocated to obtain an additional 256 possible values. Note that the most significant bit must be zero; hence, there are 23 bits allocated for various organizations to design and define non-standard Harrington, et al. Standards Track [Page 44] RFC 3411 Architecture for SNMP Management Frameworks December 2002 securityModels. This limits the ability to define new proprietary implementations of Security Models to the first 8,388,608 enterprises. It is worthwhile to note that, in its encoded form, the securityModel value will normally require only a single byte since, in practice, the leftmost bits will be zero for most messages and sign extension is suppressed by the encoding rules. As of this writing, there are several values of securityModel defined for use with SNMP or reserved for use with supporting MIB objects. They are as follows: 0 reserved for 'any' 1 reserved for SNMPv1 2 reserved for SNMPv2c 3 User-Based Security Model (USM) " SYNTAX INTEGER(0 .. 2147483647) SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An identifier that uniquely identifies a Message Processing Model of the Message Processing Subsystem within this SNMP Management Architecture. The values for messageProcessingModel are allocated as follows: - Values between 0 and 255, inclusive, are reserved for standards-track Message Processing Models and are managed by the Internet Assigned Numbers Authority (IANA). - Values greater than 255 are allocated to enterprise-specific Message Processing Models. An enterprise messageProcessingModel value is defined to be: enterpriseID * 256 + messageProcessingModel within enterprise For example, the fourth Message Processing Model defined by the enterprise whose enterpriseID Harrington, et al. Standards Track [Page 45] RFC 3411 Architecture for SNMP Management Frameworks December 2002 is 1 would be 259. This scheme for allocating messageProcessingModel values allows for a maximum of 255 standards- based Message Processing Models, and for a maximum of 256 Message Processing Models per enterprise. It is believed that the assignment of new messageProcessingModel values will be rare in practice because the larger the number of simultaneously utilized Message Processing Models, the larger the chance that interoperability will suffer. It is believed that such a range will be sufficient. In the unlikely event that the standards committee finds this number to be insufficient over time, an enterprise number can be allocated to obtain an additional 256 possible values. Note that the most significant bit must be zero; hence, there are 23 bits allocated for various organizations to design and define non-standard messageProcessingModels. This limits the ability to define new proprietary implementations of Message Processing Models to the first 8,388,608 enterprises. It is worthwhile to note that, in its encoded form, the messageProcessingModel value will normally require only a single byte since, in practice, the leftmost bits will be zero for most messages and sign extension is suppressed by the encoding rules. As of this writing, there are several values of messageProcessingModel defined for use with SNMP. They are as follows: 0 reserved for SNMPv1 1 reserved for SNMPv2c 2 reserved for SNMPv2u and SNMPv2* 3 reserved for SNMPv3 " SYNTAX INTEGER(0 .. 2147483647) Harrington, et al. Standards Track [Page 46] RFC 3411 Architecture for SNMP Management Frameworks December 2002 SnmpSecurityLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A Level of Security at which SNMP messages can be sent or with which operations are being processed; in particular, one of: noAuthNoPriv - without authentication and without privacy, authNoPriv - with authentication but without privacy, authPriv - with authentication and with privacy. These three values are ordered such that noAuthNoPriv is less than authNoPriv and authNoPriv is less than authPriv. " SYNTAX INTEGER { noAuthNoPriv(1), authNoPriv(2), authPriv(3) } SnmpAdminString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255t" STATUS current DESCRIPTION "An octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. Harrington, et al. Standards Track [Page 47] RFC 3411 Architecture for SNMP Management Frameworks December 2002 The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. " SYNTAX OCTET STRING (SIZE (0..255)) -- Administrative assignments *************************************** snmpFrameworkAdmin OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } snmpFrameworkMIBObjects OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } snmpFrameworkMIBConformance OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } -- the snmpEngine Group ******************************************** snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } Harrington, et al. Standards Track [Page 48] RFC 3411 Architecture for SNMP Management Frameworks December 2002 snmpEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "An SNMP engine's administratively-unique identifier. This information SHOULD be stored in non-volatile storage so that it remains constant across re-initializations of the SNMP engine. " ::= { snmpEngine 1 } snmpEngineBoots OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the SNMP engine has (re-)initialized itself since snmpEngineID was last configured. " ::= { snmpEngine 2 } snmpEngineTime OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds since the value of the snmpEngineBoots object last changed. When incrementing this object's value would cause it to exceed its maximum, snmpEngineBoots is incremented as if a re-initialization had occurred, and this object's value consequently reverts to zero. " ::= { snmpEngine 3 } snmpEngineMaxMessageSize OBJECT-TYPE SYNTAX INTEGER (484..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum length in octets of an SNMP message which this SNMP engine can send or receive and process, determined as the minimum of the maximum message size values supported among all of the transports available to and supported by the engine. " ::= { snmpEngine 4 } Harrington, et al. Standards Track [Page 49] RFC 3411 Architecture for SNMP Management Frameworks December 2002 -- Registration Points for Authentication and Privacy Protocols ** snmpAuthProtocols OBJECT-IDENTITY STATUS current DESCRIPTION "Registration point for standards-track authentication protocols used in SNMP Management Frameworks. " ::= { snmpFrameworkAdmin 1 } snmpPrivProtocols OBJECT-IDENTITY STATUS current DESCRIPTION "Registration point for standards-track privacy protocols used in SNMP Management Frameworks. " ::= { snmpFrameworkAdmin 2 } -- Conformance information ****************************************** snmpFrameworkMIBCompliances OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} snmpFrameworkMIBGroups OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} -- compliance statements snmpFrameworkMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP Management Framework MIB. " MODULE -- this module MANDATORY-GROUPS { snmpEngineGroup } ::= { snmpFrameworkMIBCompliances 1 } -- units of conformance snmpEngineGroup OBJECT-GROUP OBJECTS { snmpEngineID, snmpEngineBoots, snmpEngineTime, snmpEngineMaxMessageSize } STATUS current DESCRIPTION "A collection of objects for identifying and determining the configuration and current timeliness Harrington, et al. Standards Track [Page 50] RFC 3411 Architecture for SNMP Management Frameworks December 2002 values of an SNMP engine. " ::= { snmpFrameworkMIBGroups 1 } END 6. IANA Considerations This document defines three number spaces administered by IANA, one for security models, another for message processing models, and a third for SnmpEngineID formats. 6.1. Security Models The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are in the range from 0 to 255 inclusive, and are reserved for standards-track Security Models. If this range should in the future prove insufficient, an enterprise number can be allocated to obtain an additional 256 possible values. As of this writing, there are several values of securityModel defined for use with SNMP or reserved for use with supporting MIB objects. They are as follows: 0 reserved for 'any' 1 reserved for SNMPv1 2 reserved for SNMPv2c 3 User-Based Security Model (USM) 6.2. Message Processing Models The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by IANA are in the range 0 to 255, inclusive. Each value uniquely identifies a standards-track Message Processing Model of the Message Processing Subsystem within the SNMP Management Architecture. Should this range prove insufficient in the future, an enterprise number may be obtained for the standards committee to get an additional 256 possible values. As of this writing, there are several values of messageProcessingModel defined for use with SNMP. They are as follows: 0 reserved for SNMPv1 1 reserved for SNMPv2c 2 reserved for SNMPv2u and SNMPv2* 3 reserved for SNMPv3 Harrington, et al. Standards Track [Page 51] RFC 3411 Architecture for SNMP Management Frameworks December 2002 6.3. SnmpEngineID Formats The SnmpEngineID TEXTUAL-CONVENTION's fifth octet contains a format identifier. The values managed by IANA are in the range 6 to 127, inclusive. Each value uniquely identifies a standards-track SnmpEngineID format. 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC 2028. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Acknowledgements This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members: Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) Harrington, et al. Standards Track [Page 52] RFC 3411 Architecture for SNMP Management Frameworks December 2002 David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T.J. Watson Research Center) The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were: David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center) As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Harrington, et al. Standards Track [Page 53] RFC 3411 Architecture for SNMP Management Frameworks December 2002 Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) 9. Security Considerations This document describes how an implementation can include a Security Model to protect management messages and an Access Control Model to control access to management information. The level of security provided is determined by the specific Security Model implementation(s) and the specific Access Control Model implementation(s) used. Applications have access to data which is not secured. Applications SHOULD take reasonable steps to protect the data from disclosure. It is the responsibility of the purchaser of an implementation to ensure that: 1) an implementation complies with the rules defined by this architecture, 2) the Security and Access Control Models utilized satisfy the security and access control needs of the organization, 3) the implementations of the Models and Applications comply with the model and application specifications, 4) and the implementation protects configuration secrets from inadvertent disclosure. This document also contains a MIB definition module. None of the objects defined is writable, and the information they represent is not deemed to be particularly sensitive. However, if they are deemed sensitive in a particular environment, access to them should be restricted through the use of appropriately configured Security and Access Control models. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Harrington, et al. Standards Track [Page 54] RFC 3411 Architecture for SNMP Management Frameworks December 2002 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Harrington, et al. Standards Track [Page 55] RFC 3411 Architecture for SNMP Management Frameworks December 2002 10.2. Informative References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "The Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC 1909, February 1996. [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", RFC 1910, February 1996. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework", RFC 2576, March 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Harrington, et al. Standards Track [Page 56] RFC 3411 Architecture for SNMP Management Frameworks December 2002 Appendix A A. Guidelines for Model Designers This appendix describes guidelines for designers of models which are expected to fit into the architecture defined in this document. SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to provide trivial authentication and access control. SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed according to this architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks could be designed to meet the requirements of this architecture, but this document does not provide guidelines for that coexistence. Within any subsystem model, there should be no reference to any specific model of another subsystem, or to data defined by a specific model of another subsystem. Transfer of data between the subsystems is deliberately described as a fixed set of abstract data elements and primitive functions which can be overloaded to satisfy the needs of multiple model definitions. Documents which define models to be used within this architecture SHOULD use the standard primitives between subsystems, possibly defining specific mechanisms for converting the abstract data elements into model-usable formats. This constraint exists to allow subsystem and model documents to be written recognizing common borders of the subsystem and model. Vendors are not constrained to recognize these borders in their implementations. The architecture defines certain standard services to be provided between subsystems, and the architecture defines abstract service interfaces to request these services. Each model definition for a subsystem SHOULD support the standard service interfaces, but whether, or how, or how well, it performs the service is dependent on the model definition. A.1. Security Model Design Requirements A.1.1. Threats A document describing a Security Model MUST describe how the model protects against the threats described under "Security Requirements of this Architecture", section 1.4. Harrington, et al. Standards Track [Page 57] RFC 3411 Architecture for SNMP Management Frameworks December 2002 A.1.2. Security Processing Received messages MUST be validated by a Model of the Security Subsystem. Validation includes authentication and privacy processing if needed, but it is explicitly allowed to send messages which do not require authentication or privacy. A received message contains a specified securityLevel to be used during processing. All messages requiring privacy MUST also require authentication. A Security Model specifies rules by which authentication and privacy are to be done. A model may define mechanisms to provide additional security features, but the model definition is constrained to using (possibly a subset of) the abstract data elements defined in this document for transferring data between subsystems. Each Security Model may allow multiple security protocols to be used concurrently within an implementation of the model. Each Security Model defines how to determine which protocol to use, given the securityLevel and the security parameters relevant to the message. Each Security Model, with its associated protocol(s) defines how the sending/receiving entities are identified, and how secrets are configured. Authentication and Privacy protocols supported by Security Models are uniquely identified using Object Identifiers. IETF standard protocols for authentication or privacy should have an identifier defined within the snmpAuthProtocols or the snmpPrivProtocols subtrees. Enterprise specific protocol identifiers should be defined within the enterprise subtree. For privacy, the Security Model defines what portion of the message is encrypted. The persistent data used for security should be SNMP-manageable, but the Security Model defines whether an instantiation of the MIB is a conformance requirement. Security Models are replaceable within the Security Subsystem. Multiple Security Model implementations may exist concurrently within an SNMP engine. The number of Security Models defined by the SNMP community should remain small to promote interoperability. Harrington, et al. Standards Track [Page 58] RFC 3411 Architecture for SNMP Management Frameworks December 2002 A.1.3. Validate the security-stamp in a received message A Message Processing Model requests that a Security Model: - verifies that the message has not been altered, - authenticates the identification of the principal for whom the message was generated. - decrypts the message if it was encrypted. Additional requirements may be defined by the model, and additional services may be provided by the model, but the model is constrained to use the following primitives for transferring data between subsystems. Implementations are not so constrained. A Message Processing Model uses the processIncomingMsg primitive as described in section 4.4.2. A.1.4. Security MIBs Each Security Model defines the MIB module(s) required for security processing, including any MIB module(s) required for the security protocol(s) supported. The MIB module(s) SHOULD be defined concurrently with the procedures which use the MIB module(s). The MIB module(s) are subject to normal access control rules. The mapping between the model-dependent security ID and the securityName MUST be able to be determined using SNMP, if the model- dependent MIB is instantiated and if access control policy allows access. A.1.5. Cached Security Data For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response. A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model. The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in section 4.5.1. Harrington, et al. Standards Track [Page 59] RFC 3411 Architecture for SNMP Management Frameworks December 2002 A.2. Message Processing Model Design Requirements An SNMP engine contains a Message Processing Subsystem which may contain multiple Message Processing Models. The Message Processing Model MUST always (conceptually) pass the complete PDU, i.e., it never forwards less than the complete list of varBinds. A.2.1. Receiving an SNMP Message from the Network Upon receipt of a message from the network, the Dispatcher in the SNMP engine determines the version of the SNMP message and interacts with the corresponding Message Processing Model to determine the abstract data elements. A Message Processing Model specifies the SNMP Message format it supports and describes how to determine the values of the abstract data elements (like msgID, msgMaxSize, msgFlags, msgSecurityParameters, securityModel, securityLevel etc). A Message Processing Model interacts with a Security Model to provide security processing for the message using the processIncomingMsg primitive, as described in section 4.4.2. A.2.2. Sending an SNMP Message to the Network The Dispatcher in the SNMP engine interacts with a Message Processing Model to prepare an outgoing message. For that it uses the following primitives: - for requests and notifications: prepareOutgoingMessage, as described in section 4.2.1. - for response messages: prepareResponseMessage, as described in section 4.2.2. A Message Processing Model, when preparing an Outgoing SNMP Message, interacts with a Security Model to secure the message. For that it uses the following primitives: - for requests and notifications: generateRequestMsg, as described in section 4.4.1. - for response messages: generateResponseMsg as described in section 4.4.3. Harrington, et al. Standards Track [Page 60] RFC 3411 Architecture for SNMP Management Frameworks December 2002 Once the SNMP message is prepared by a Message Processing Model, the Dispatcher sends the message to the desired address using the appropriate transport. A.3. Application Design Requirements Within an application, there may be an explicit binding to a specific SNMP message version, i.e., a specific Message Processing Model, and to a specific Access Control Model, but there should be no reference to any data defined by a specific Message Processing Model or Access Control Model. Within an application, there should be no reference to any specific Security Model, or any data defined by a specific Security Model. An application determines whether explicit or implicit access control should be applied to the operation, and, if access control is needed, which Access Control Model should be used. An application has the responsibility to define any MIB module(s) used to provide application-specific services. Applications interact with the SNMP engine to initiate messages, receive responses, receive asynchronous messages, and send responses. A.3.1. Applications that Initiate Messages Applications may request that the SNMP engine send messages containing SNMP commands or notifications using the sendPdu primitive as described in section 4.1.1. If it is desired that a message be sent to multiple targets, it is the responsibility of the application to provide the iteration. The SNMP engine assumes necessary access control has been applied to the PDU, and provides no access control services. The SNMP engine looks at the "expectResponse" parameter, and if a response is expected, then the appropriate information is cached such that a later response can be associated to this message, and can then be returned to the application. A sendPduHandle is returned to the application so it can later correspond the response with this message as well. Harrington, et al. Standards Track [Page 61] RFC 3411 Architecture for SNMP Management Frameworks December 2002 A.3.2. Applications that Receive Responses The SNMP engine matches the incoming response messages to outstanding messages sent by this SNMP engine, and forwards the response to the associated application using the processResponsePdu primitive, as described in section 4.1.4. A.3.3. Applications that Receive Asynchronous Messages When an SNMP engine receives a message that is not the response to a request from this SNMP engine, it must determine to which application the message should be given. An Application that wishes to receive asynchronous messages registers itself with the engine using the primitive registerContextEngineID as described in section 4.1.5. An Application that wishes to stop receiving asynchronous messages should unregister itself with the SNMP engine using the primitive unregisterContextEngineID as described in section 4.1.5. Only one registration per combination of PDU type and contextEngineID is permitted at the same time. Duplicate registrations are ignored. An errorIndication will be returned to the application that attempts to duplicate a registration. All asynchronously received messages containing a registered combination of PDU type and contextEngineID are sent to the application which registered to support that combination. The engine forwards the PDU to the registered application, using the processPdu primitive, as described in section 4.1.2. A.3.4. Applications that Send Responses Request operations require responses. An application sends a response via the returnResponsePdu primitive, as described in section 4.1.3. The contextEngineID, contextName, securityModel, securityName, securityLevel, and stateReference parameters are from the initial processPdu primitive. The PDU and statusInformation are the results of processing. Harrington, et al. Standards Track [Page 62] RFC 3411 Architecture for SNMP Management Frameworks December 2002 A.4. Access Control Model Design Requirements An Access Control Model determines whether the specified securityName is allowed to perform the requested operation on a specified managed object. The Access Control Model specifies the rules by which access control is determined. The persistent data used for access control should be manageable using SNMP, but the Access Control Model defines whether an instantiation of the MIB is a conformance requirement. The Access Control Model must provide the primitive isAccessAllowed. Editors' Addresses Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Phone: +31 348-680-485 EMail: bwijnen@lucent.com David Harrington Enterasys Networks Post Office Box 5005 35 Industrial Way Rochester, New Hampshire 03866-5005 USA Phone: +1 603-337-2614 EMail: dbh@enterasys.com Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, California 95131 USA Phone: +1 408-546-1006 Fax: +1 408-965-0359 EMail: randy_presuhn@bmc.com Harrington, et al. Standards Track [Page 63] RFC 3411 Architecture for SNMP Management Frameworks December 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Harrington, et al. Standards Track [Page 64] snmp-mibs-downloader-1.1/mibrfcs/rfc3412.txt0000644000000000000000000027273611402176071015574 0ustar Network Working Group J. Case Request for Comments: 3412 SNMP Research, Inc. STD: 62 D. Harrington Obsoletes: 2572 Enterasys Networks Category: Standards Track R. Presuhn BMC Software, Inc. B. Wijnen Lucent Technologies December 2002 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. Case, et al. Standards Track [Page 1] RFC 3412 Message Processing and Dispatching for SNMP December 2002 Table of Contents 1. Introduction ................................................ 3 2. Overview .................................................... 4 2.1. The Dispatcher ............................................ 5 2.2. Message Processing Subsystem .............................. 5 3. Elements of Message Processing and Dispatching .............. 6 3.1. messageProcessingModel .................................... 6 3.2. pduVersion ................................................ 6 3.3. pduType ................................................... 7 3.4. sendPduHandle ............................................. 7 4. Dispatcher Elements of Procedure ............................ 7 4.1. Sending an SNMP Message to the Network .................... 7 4.1.1. Sending a Request or Notification ....................... 8 4.1.2. Sending a Response to the Network ....................... 9 4.2. Receiving an SNMP Message from the Network ................ 11 4.2.1. Message Dispatching of received SNMP Messages ........... 11 4.2.2. PDU Dispatching for Incoming Messages ................... 12 4.2.2.1. Incoming Requests and Notifications ................... 13 4.2.2.2. Incoming Responses .................................... 14 4.3. Application Registration for Handling PDU types ........... 15 4.4. Application Unregistration for Handling PDU Types ......... 16 5. Definitions ................................................. 16 5.1. Definitions for SNMP Message Processing and Dispatching ... 16 6. The SNMPv3 Message Format ................................... 19 6.1. msgVersion ................................................ 20 6.2. msgID ..................................................... 20 6.3. msgMaxSize ................................................ 21 6.4. msgFlags .................................................. 21 6.5. msgSecurityModel .......................................... 24 6.6. msgSecurityParameters ..................................... 24 6.7. scopedPduData ............................................. 24 6.8. scopedPDU ................................................. 24 6.8.1. contextEngineID ......................................... 24 6.8.2. contextName ............................................. 25 6.8.3. data .................................................... 25 7. Elements of Procedure for v3MP .............................. 25 7.1. Prepare an Outgoing SNMP Message .......................... 26 7.2. Prepare Data Elements from an Incoming SNMP Message ....... 32 8. Intellectual Property ....................................... 37 9. Acknowledgements ............................................ 38 10. Security Considerations .................................... 39 11. References ................................................. 40 11.1. Normative References ..................................... 40 11.2. Informative References ................................... 41 12. Editors' Addresses ......................................... 42 13. Full Copyright Statement ................................... 43 Case, et al. Standards Track [Page 2] RFC 3412 Message Processing and Dispatching for SNMP December 2002 1. Introduction The Architecture for describing Internet Management Frameworks [RFC3411] describes that an SNMP engine is composed of: 1) a Dispatcher 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem. Applications make use of the services of these subsystems. It is important to understand the SNMP architecture and its terminology to understand where the Message Processing Subsystem and Dispatcher described in this document fit into the architecture and interact with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, defined in [RFC3411]. The Dispatcher in the SNMP engine sends and receives SNMP messages. It also dispatches SNMP PDUs to SNMP applications. When an SNMP message needs to be prepared or when data needs to be extracted from an SNMP message, the Dispatcher delegates these tasks to a message version-specific Message Processing Model within the Message Processing Subsystem. A Message Processing Model is responsible for processing an SNMP version-specific message and for coordinating the interaction with the Security Subsystem to ensure proper security is applied to the SNMP message being handled. Interactions between the Dispatcher, the Message Processing Subsystem, and applications are modeled using abstract data elements and abstract service interface primitives defined by the SNMP architecture. Similarly, interactions between the Message Processing Subsystem and the Security Subsystem are modeled using abstract data elements and abstract service interface primitives as defined by the SNMP architecture. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119. Case, et al. Standards Track [Page 3] RFC 3412 Message Processing and Dispatching for SNMP December 2002 2. Overview The following illustration depicts the Message Processing in relation to SNMP applications, the Security Subsystem and Transport Mappings. +-------------------------------------------------------------------+ | SNMP Entity | | | | +---------------------------------------------------------------+ | | | Applications | | | | +-----------+ +--------------+ | | | | | Command | | Notification | | | | | | Generator | | Originator | +-----------+ +--------------+| | | | +-----------+ +--------------+ | Proxy | | Other || | | | +-----------+ +--------------+ | Forwarder | |Application(s)|| | | | | Command | | Notification | +-----------+ +--------------+| | | | | Responder | | Receiver | | | | | +-----------+ +--------------+ | | | +---------------------------------------------------------------+ | | ^ ^ ^ ^ | | | | | | | | v v v v | | +--------+-------+---------------+-----------+ | | ^ | | | +---------------------+ +-----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +------------------+ | +------------+ | | | | | | PDU Dispatcher | | +->| v1MP * |<--->| +-------------+ | | | | | | | +------------+ | | | Other | | | | | | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +-------------+ | | | | Dispatcher <-------->+ | | | | | | | | | +------------+ | | +-------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | Transport | | | +------------+ | | | Security | | | | | Mapping | | | +------------+ | | | Model | | | | | (e.g., RFC 3417) | | +->| otherMP * |<--->| +-------------+ | | | +------------------+ | +------------+ | | | | | ^ +---------------------+ +-----------------+ | | | | +----------|--------------------------------------------------------+ v +------------------+ | Network | * One or more models may be present. +------------------+ Case, et al. Standards Track [Page 4] RFC 3412 Message Processing and Dispatching for SNMP December 2002 2.1. The Dispatcher The Dispatcher is a key piece of an SNMP engine. There is only one in an SNMP engine, and its job is to dispatch tasks to the multiple version-specific Message Processing Models, and to dispatch PDUs to various applications. For outgoing messages, an application provides a PDU to be sent, plus the data needed to prepare and send the message, and the application specifies which version-specific Message Processing Model will be used to prepare the message with the desired security processing. Once the message is prepared, the Dispatcher sends the message. For incoming messages, the Dispatcher determines the SNMP version of the incoming message and passes the message to the version-specific Message Processing Model to extract the components of the message and to coordinate the processing of security services for the message. After version-specific processing, the PDU Dispatcher determines which application, if any, should receive the PDU for processing and forwards it accordingly. The Dispatcher, while sending and receiving SNMP messages, collects statistics about SNMP messages and the behavior of the SNMP engine in managed objects to make them accessible to remote SNMP entities. This document defines these managed objects, the MIB module which contains them, and how these managed objects might be used to provide useful management. 2.2. Message Processing Subsystem The SNMP Message Processing Subsystem is the part of an SNMP engine which interacts with the Dispatcher to handle the version-specific SNMP messages. It contains one or more Message Processing Models. This document describes one Message Processing Model, the SNMPv3 Message Processing Model, in Section 6. The SNMPv3 Message Processing Model is defined in a separate section to show that multiple (independent) Message Processing Models can exist at the same time and that such Models can be described in different documents. The SNMPv3 Message Processing Model can be replaced or supplemented with other Message Processing Models in the future. Two Message Processing Models which are expected to be developed in the future are the SNMPv1 message format [RFC1157] and the SNMPv2c message format [RFC1901]. Others may be developed as needed. Case, et al. Standards Track [Page 5] RFC 3412 Message Processing and Dispatching for SNMP December 2002 3. Elements of Message Processing and Dispatching See [RFC3411] for the definitions of: contextEngineID contextName scopedPDU maxSizeResponseScopedPDU securityModel securityName securityLevel messageProcessingModel For incoming messages, a version-specific message processing module provides these values to the Dispatcher. For outgoing messages, an application provides these values to the Dispatcher. For some version-specific processing, the values may be extracted from received messages; for other versions, the values may be determined by algorithm, or by an implementation-defined mechanism. The mechanism by which the value is determined is irrelevant to the Dispatcher. The following additional or expanded definitions are for use within the Dispatcher. 3.1. messageProcessingModel The value of messageProcessingModel identifies a Message Processing Model. A Message Processing Model describes the version-specific procedures for extracting data from messages, generating messages, calling upon a securityModel to apply its security services to messages, for converting data from a version-specific message format into a generic format usable by the Dispatcher, and for converting data from Dispatcher format into a version-specific message format. 3.2. pduVersion The value of pduVersion represents a specific version of protocol operation and its associated PDU formats, such as SNMPv1 or SNMPv2 [RFC3416]. The values of pduVersion are specific to the version of the PDU contained in a message, and the PDUs processed by applications. The Dispatcher does not use the value of pduVersion directly. Case, et al. Standards Track [Page 6] RFC 3412 Message Processing and Dispatching for SNMP December 2002 An application specifies the pduVersion when it requests the PDU Dispatcher to send a PDU to another SNMP engine. The Dispatcher passes the pduVersion to a Message Processing Model, so it knows how to handle the PDU properly. For incoming messages, the pduVersion is provided to the Dispatcher by a version-specific Message Processing module. The PDU Dispatcher passes the pduVersion to the application so it knows how to handle the PDU properly. For example, a command responder application needs to know whether to use [RFC3416] elements of procedure and syntax instead of those specified for SNMPv1. 3.3. pduType A value of the pduType represents a specific type of protocol operation. The values of the pduType are specific to the version of the PDU contained in a message. Applications register to support particular pduTypes for particular contextEngineIDs. For incoming messages, pduType is provided to the Dispatcher by a version-specific Message Processing module. It is subsequently used to dispatch the PDU to the application which registered for the pduType for the contextEngineID of the associated scopedPDU. 3.4. sendPduHandle This handle is generated for coordinating the processing of requests and responses between the SNMP engine and an application. The handle must be unique across all version-specific Message Processing Models, and is of local significance only. 4. Dispatcher Elements of Procedure This section describes the procedures followed by the Dispatcher when generating and processing SNMP messages. 4.1. Sending an SNMP Message to the Network This section describes the procedure followed by an SNMP engine whenever it sends an SNMP message. Case, et al. Standards Track [Page 7] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4.1.1. Sending a Request or Notification The following procedures are followed by the Dispatcher when an application wants to send an SNMP PDU to another (remote) application, i.e., to initiate a communication by originating a message, such as one containing a request or a notification. 1) The application requests this using the abstract service primitive: statusInformation = -- sendPduHandle if success -- errorIndication if failure sendPdu( IN transportDomain -- transport domain to be used IN transportAddress -- destination network address IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE ) 2) If the messageProcessingModel value does not represent a Message Processing Model known to the Dispatcher, then an errorIndication (implementation-dependent) is returned to the calling application. No further processing is performed. 3) The Dispatcher generates a sendPduHandle to coordinate subsequent processing. Case, et al. Standards Track [Page 8] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4) The Message Dispatcher sends the request to the version-specific Message Processing module identified by messageProcessingModel using the abstract service primitive: statusInformation = -- success or error indication prepareOutgoingMessage( IN transportDomain -- as specified by application IN transportAddress -- as specified by application IN messageProcessingModel -- as specified by application IN securityModel -- as specified by application IN securityName -- as specified by application IN securityLevel -- as specified by application IN contextEngineID -- as specified by application IN contextName -- as specified by application IN pduVersion -- as specified by application IN PDU -- as specified by application IN expectResponse -- as specified by application IN sendPduHandle -- as determined in step 3. OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the message length ) 5) If the statusInformation indicates an error, the errorIndication is returned to the calling application. No further processing is performed. 6) If the statusInformation indicates success, the sendPduHandle is returned to the application, and the outgoingMessage is sent. The transport used to send the outgoingMessage is returned via destTransportDomain, and the address to which it was sent is returned via destTransportAddress. Outgoing Message Processing is complete. 4.1.2. Sending a Response to the Network The following procedure is followed when an application wants to return a response back to the originator of an SNMP Request. Case, et al. Standards Track [Page 9] RFC 3412 Message Processing and Dispatching for SNMP December 2002 1) An application can request this using the abstract service primitive: result = returnResponsePdu( IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size of Response PDU IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication ) -- (error counter OID and value -- when errorIndication) 2) The Message Dispatcher sends the request to the appropriate Message Processing Model indicated by the received value of messageProcessingModel using the abstract service primitive: result = -- SUCCESS or errorIndication prepareResponseMessage( IN messageProcessingModel -- specified by application IN securityModel -- specified by application IN securityName -- specified by application IN securityLevel -- specified by application IN contextEngineID -- specified by application IN contextName -- specified by application IN pduVersion -- specified by application IN PDU -- specified by application IN maxSizeResponseScopedPDU -- specified by application IN stateReference -- specified by application IN statusInformation -- specified by application OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the message length ) 3) If the result is an errorIndication, the errorIndication is returned to the calling application. No further processing is performed. Case, et al. Standards Track [Page 10] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4) If the result is success, the outgoingMessage is sent. The transport used to send the outgoingMessage is returned via destTransportDomain, and the address to which it was sent is returned via destTransportAddress. Message Processing is complete. 4.2. Receiving an SNMP Message from the Network This section describes the procedure followed by an SNMP engine whenever it receives an SNMP message. Please note, that for the sake of clarity and to prevent the text from being even longer and more complicated, some details were omitted from the steps below. In particular, the elements of procedure do not always explicitly indicate when state information needs to be released. The general rule is that if state information is available when a message is to be "discarded without further processing", then the state information must also be released at that same time. 4.2.1. Message Dispatching of received SNMP Messages 1) The snmpInPkts counter [RFC3418] is incremented. 2) The version of the SNMP message is determined in an implementation-dependent manner. If the packet cannot be sufficiently parsed to determine the version of the SNMP message, then the snmpInASNParseErrs [RFC3418] counter is incremented, and the message is discarded without further processing. If the version is not supported, then the snmpInBadVersions [RFC3418] counter is incremented, and the message is discarded without further processing. 3) The origin transportDomain and origin transportAddress are determined. Case, et al. Standards Track [Page 11] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4) The message is passed to the version-specific Message Processing Model which returns the abstract data elements required by the Dispatcher. This is performed using the abstract service primitive: result = -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin as determined in step 3. IN transportAddress -- origin as determined in step 3. IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model specified OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security specified OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for a matched request OUT maxSizeResponseScopedPDU -- maximum size of Response PDU OUT statusInformation -- success or errorIndication -- (error counter OID and value -- when errorIndication) OUT stateReference -- reference to state information -- to be used for a possible ) -- Response 5) If the result is a FAILURE errorIndication, the message is discarded without further processing. 6) At this point, the abstract data elements have been prepared and processing continues as described in Section 4.2.2, PDU Dispatching for Incoming Messages. 4.2.2. PDU Dispatching for Incoming Messages The elements of procedure for the dispatching of PDUs depends on the value of sendPduHandle. If the value of sendPduHandle is , then this is a request or notification and the procedures specified in Section 4.2.2.1 apply. If the value of snmpPduHandle is not , then this is a response and the procedures specified in Section 4.2.2.2 apply. Case, et al. Standards Track [Page 12] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4.2.2.1. Incoming Requests and Notifications The following procedures are followed for the dispatching of PDUs when the value of sendPduHandle is , indicating this is a request or notification. 1) The combination of contextEngineID and pduType is used to determine which application has registered for this request or notification. 2) If no application has registered for the combination, then: a) The snmpUnknownPDUHandlers counter is incremented. b) A Response message is generated using the abstract service primitive: result = -- SUCCESS or FAILURE prepareResponseMessage( IN messageProcessingModel -- as provided by MP module IN securityModel -- as provided by MP module IN securityName -- as provided by MP module IN securityLevel -- as provided by MP module IN contextEngineID -- as provided by MP module IN contextName -- as provided by MP module IN pduVersion -- as provided by MP module IN PDU -- as provided by MP module IN maxSizeResponseScopedPDU -- as provided by MP module IN stateReference -- as provided by MP module IN statusInformation -- errorIndication plus -- snmpUnknownPDUHandlers OID -- value pair. OUT destTransportDomain -- destination transportDomain OUT destTransportAddress -- destination transportAddress OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length ) c) If the result is SUCCESS, then the prepared message is sent to the originator of the request as identified by the transportDomain and transportAddress. The transport used to send the outgoingMessage is returned via destTransportDomain, and the address to which it was sent is returned via destTransportAddress. d) The incoming message is discarded without further processing. Message Processing for this message is complete. Case, et al. Standards Track [Page 13] RFC 3412 Message Processing and Dispatching for SNMP December 2002 3) The PDU is dispatched to the application, using the abstract service primitive: processPdu( -- process Request/Notification IN messageProcessingModel -- as provided by MP module IN securityModel -- as provided by MP module IN securityName -- as provided by MP module IN securityLevel -- as provided by MP module IN contextEngineID -- as provided by MP module IN contextName -- as provided by MP module IN pduVersion -- as provided by MP module IN PDU -- as provided by MP module IN maxSizeResponseScopedPDU -- as provided by MP module IN stateReference -- as provided by MP module -- needed when sending response ) Message processing for this message is complete. 4.2.2.2. Incoming Responses The following procedures are followed for the dispatching of PDUs when the value of sendPduHandle is not , indicating this is a response. 1) The value of sendPduHandle is used to determine, in an implementation-defined manner, which application is waiting for a response associated with this sendPduHandle. 2) If no waiting application is found, the message is discarded without further processing, and the stateReference is released. The snmpUnknownPDUHandlers counter is incremented. Message Processing is complete for this message. 3) Any cached information, including stateReference, about the message is discarded. Case, et al. Standards Track [Page 14] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4) The response is dispatched to the application using the abstract service primitive: processResponsePdu( -- process Response PDU IN messageProcessingModel -- provided by the MP module IN securityModel -- provided by the MP module IN securityName -- provided by the MP module IN securityLevel -- provided by the MP module IN contextEngineID -- provided by the MP module IN contextName -- provided by the MP module IN pduVersion -- provided by the MP module IN PDU -- provided by the MP module IN statusInformation -- provided by the MP module IN sendPduHandle -- provided by the MP module ) Message Processing is complete for this message. 4.3. Application Registration for Handling PDU types Applications that want to process certain PDUs must register with the PDU Dispatcher. Applications specify the combination of contextEngineID and pduType(s) for which they want to take responsibility. 1) An application registers according to the abstract interface primitive: statusInformation = -- success or errorIndication registerContextEngineID( IN contextEngineID -- take responsibility for this one IN pduType -- the pduType(s) to be registered ) Note: Implementations may provide a means of requesting registration for simultaneous multiple contextEngineID values, e.g., all contextEngineID values, and may also provide a means for requesting simultaneous registration for multiple values of the pduType. 2) The parameters may be checked for validity; if they are not, then an errorIndication (invalidParameter) is returned to the application. 3) Each combination of contextEngineID and pduType can be registered only once. If another application has already registered for the specified combination, then an errorIndication (alreadyRegistered) is returned to the application. Case, et al. Standards Track [Page 15] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4) Otherwise, the registration is saved so that SNMP PDUs can be dispatched to this application. 4.4. Application Unregistration for Handling PDU Types Applications that no longer want to process certain PDUs must unregister with the PDU Dispatcher. 1) An application unregisters using the abstract service primitive: unregisterContextEngineID( IN contextEngineID -- give up responsibility for this IN pduType -- the pduType(s) to be unregistered ) Note: Implementations may provide a means for requesting the unregistration for simultaneous multiple contextEngineID values, e.g., all contextEngineID values, and may also provide a means for requesting simultaneous unregistration for multiple values of pduType. 2) If the contextEngineID and pduType combination has been registered, then the registration is deleted. If no such registration exists, then the request is ignored. 5. Definitions 5.1. Definitions for SNMP Message Processing and Dispatching SNMP-MPD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, snmpModules, Counter32 FROM SNMPv2-SMI; snmpMPDMIB MODULE-IDENTITY LAST-UPDATED "200210140000Z" ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com Subscribe: snmpv3-request@lists.tislabs.com Co-Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA Case, et al. Standards Track [Page 16] RFC 3412 Message Processing and Dispatching for SNMP December 2002 EMail: mundy@tislabs.com phone: +1 301-947-7107 Co-Chair & Co-editor: David Harrington Enterasys Networks postal: 35 Industrial Way P. O. Box 5005 Rochester NH 03866-5005 USA EMail: dbh@enterasys.com phone: +1 603-337-2614 Co-editor: Jeffrey Case SNMP Research, Inc. postal: 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA EMail: case@snmp.com phone: +1 423-573-1434 Co-editor: Randy Presuhn BMC Software, Inc. postal: 2141 North First Street San Jose, CA 95131 USA EMail: randy_presuhn@bmc.com phone: +1 408-546-1006 Co-editor: Bert Wijnen Lucent Technologies postal: Schagen 33 3461 GL Linschoten Netherlands EMail: bwijnen@lucent.com phone: +31 348-680-485 " DESCRIPTION "The MIB for Message Processing and Dispatching Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3412; see the RFC itself for full legal notices. " REVISION "200210140000Z" -- 14 October 2002 DESCRIPTION "Updated addresses, published as RFC 3412." REVISION "199905041636Z" -- 4 May 1999 DESCRIPTION "Updated addresses, published as RFC 2572." Case, et al. Standards Track [Page 17] RFC 3412 Message Processing and Dispatching for SNMP December 2002 REVISION "199709300000Z" -- 30 September 1997 DESCRIPTION "Original version, published as RFC 2272." ::= { snmpModules 11 } -- Administrative assignments *************************************** snmpMPDAdmin OBJECT IDENTIFIER ::= { snmpMPDMIB 1 } snmpMPDMIBObjects OBJECT IDENTIFIER ::= { snmpMPDMIB 2 } snmpMPDMIBConformance OBJECT IDENTIFIER ::= { snmpMPDMIB 3 } -- Statistics for SNMP Messages ************************************* snmpMPDStats OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 } snmpUnknownSecurityModels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they referenced a securityModel that was not known to or supported by the SNMP engine. " ::= { snmpMPDStats 1 } snmpInvalidMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because there were invalid or inconsistent components in the SNMP message. " ::= { snmpMPDStats 2 } snmpUnknownPDUHandlers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because the PDU contained in the packet could not be passed to an application responsible for handling the pduType, e.g. no SNMP application had registered for the proper combination of the contextEngineID and the pduType. " ::= { snmpMPDStats 3 } Case, et al. Standards Track [Page 18] RFC 3412 Message Processing and Dispatching for SNMP December 2002 -- Conformance information ****************************************** snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1} snmpMPDMIBGroups OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2} -- Compliance statements snmpMPDCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SNMP-MPD-MIB. " MODULE -- this module MANDATORY-GROUPS { snmpMPDGroup } ::= { snmpMPDMIBCompliances 1 } snmpMPDGroup OBJECT-GROUP OBJECTS { snmpUnknownSecurityModels, snmpInvalidMsgs, snmpUnknownPDUHandlers } STATUS current DESCRIPTION "A collection of objects providing for remote monitoring of the SNMP Message Processing and Dispatching process. " ::= { snmpMPDMIBGroups 1 } END 6. The SNMPv3 Message Format This section defines the SNMPv3 message format and the corresponding SNMP version 3 Message Processing Model (v3MP). SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN SNMPv3Message ::= SEQUENCE { -- identify the layout of the SNMPv3Message -- this element is in same position as in SNMPv1 -- and SNMPv2c, allowing recognition -- the value 3 is used for snmpv3 msgVersion INTEGER ( 0 .. 2147483647 ), -- administrative parameters msgGlobalData HeaderData, -- security model-specific parameters -- format defined by Security Model Case, et al. Standards Track [Page 19] RFC 3412 Message Processing and Dispatching for SNMP December 2002 msgSecurityParameters OCTET STRING, msgData ScopedPduData } HeaderData ::= SEQUENCE { msgID INTEGER (0..2147483647), msgMaxSize INTEGER (484..2147483647), msgFlags OCTET STRING (SIZE(1)), -- .... ...1 authFlag -- .... ..1. privFlag -- .... .1.. reportableFlag -- Please observe: -- .... ..00 is OK, means noAuthNoPriv -- .... ..01 is OK, means authNoPriv -- .... ..10 reserved, MUST NOT be used. -- .... ..11 is OK, means authPriv msgSecurityModel INTEGER (1..2147483647) } ScopedPduData ::= CHOICE { plaintext ScopedPDU, encryptedPDU OCTET STRING -- encrypted scopedPDU value } ScopedPDU ::= SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data ANY -- e.g., PDUs as defined in [RFC3416] } END 6.1. msgVersion The msgVersion field is set to snmpv3(3) and identifies the message as an SNMP version 3 Message. 6.2. msgID The msgID is used between two SNMP entities to coordinate request messages and responses, and by the v3MP to coordinate the processing of the message by different subsystem models within the architecture. Values for msgID SHOULD be generated in a manner that avoids re-use of any outstanding values. Doing so provides protection against some replay attacks. One possible implementation strategy would be to use the low-order bits of snmpEngineBoots [RFC3411] as the high-order Case, et al. Standards Track [Page 20] RFC 3412 Message Processing and Dispatching for SNMP December 2002 portion of the msgID value and a monotonically increasing integer for the low-order portion of msgID. Note that the request-id in a PDU may be used by SNMP applications to identify the PDU; the msgID is used by the engine to identify the message which carries a PDU. The engine needs to identify the message even if decryption of the PDU (and request-id) fails. No assumption should be made that the value of the msgID and the value of the request-id are equivalent. The value of the msgID field for a response takes the value of the msgID field from the message to which it is a response. By use of the msgID value, an engine can distinguish the (potentially multiple) outstanding requests, and thereby correlate incoming responses with outstanding requests. In cases where an unreliable datagram service is used, the msgID also provides a simple means of identifying messages duplicated by the network. If a request is retransmitted, a new msgID value SHOULD be used for each retransmission. 6.3. msgMaxSize The msgMaxSize field of the message conveys the maximum message size supported by the sender of the message, i.e., the maximum message size that the sender can accept when another SNMP engine sends an SNMP message (be it a response or any other message) to the sender of this message on the transport in use for this message. When an SNMP message is being generated, the msgMaxSize is provided by the SNMP engine which generates the message. At the receiving SNMP engine, the msgMaxSize is used to determine the maximum message size the sender can accommodate. 6.4. msgFlags The msgFlags field of the message contains several bit fields which control processing of the message. The reportableFlag is a secondary aid in determining whether a Report PDU MUST be sent. It is only used in cases where the PDU portion of a message cannot be decoded, due to, for example, an incorrect encryption key. If the PDU can be decoded, the PDU type forms the basis for decisions on sending Report PDUs. When the reportableFlag is used, if its value is one, a Report PDU MUST be returned to the sender under those conditions which can cause the generation of Report PDUs. Similarly, when the reportableFlag is used and its value is zero, then a Report PDU MUST NOT be sent. The reportableFlag MUST always be zero when the message contains a PDU Case, et al. Standards Track [Page 21] RFC 3412 Message Processing and Dispatching for SNMP December 2002 from the Unconfirmed Class, such as a Report PDU, a response-type PDU (such as a Response PDU), or an unacknowledged notification-type PDU (such as an SNMPv2-trap PDU). The reportableFlag MUST always be one for a PDU from the Confirmed Class, including request-type PDUs (such as a Get PDU) and acknowledged notification-type PDUs (such as an Inform PDU). If the reportableFlag is set to one for a message containing a PDU from the Unconfirmed Class, such as a Report PDU, a response-type PDU (such as a Response PDU), or an unacknowledged notification-type PDU (such as an SNMPv2-trap PDU), then the receiver of that message MUST process it as though the reportableFlag had been set to zero. If the reportableFlag is set to zero for a message containing a request-type PDU (such as a Get PDU) or an acknowledged notification-type PDU (such as an Inform PDU), then the receiver of that message MUST process it as though the reportableFlag had been set to one. Report PDUs are generated directly by the SNMPv3 Message Processing Model, and support engine-to-engine communications, but may be passed to applications for processing. An SNMP engine that receives a reportPDU may use it to determine what kind of problem was detected by the remote SNMP engine. It can do so based on the error counter included as the first (and only) varBind of the reportPDU. Based on the detected error, the SNMP engine may try to send a corrected SNMP message. If that is not possible, it may pass an indication of the error to the application on whose behalf the failed SNMP request was issued. The authFlag and privFlag portions of the msgFlags field are set by the sender to indicate the securityLevel that was applied to the message before it was sent on the wire. The receiver of the message MUST apply the same securityLevel when the message is received and the contents are being processed. There are three securityLevels, namely noAuthNoPriv, which is less than authNoPriv, which is in turn less than authPriv. See the SNMP architecture document [RFC3411] for details about the securityLevel. a) authFlag If the authFlag is set to one, then the securityModel used by the SNMP engine which sent the message MUST identify the securityName on whose behalf the SNMP message was generated and MUST provide, in a securityModel-specific manner, sufficient data for the receiver of the message to be able to authenticate that Case, et al. Standards Track [Page 22] RFC 3412 Message Processing and Dispatching for SNMP December 2002 identification. In general, this authentication will allow the receiver to determine with reasonable certainty that the message was: - sent on behalf of the principal associated with the securityName, - was not redirected, - was not modified in transit, and - was not replayed. If the authFlag is zero, then the securityModel used by the SNMP engine which sent the message MUST identify the securityName on whose behalf the SNMP message was generated but it does not need to provide sufficient data for the receiver of the message to authenticate the identification, as there is no need to authenticate the message in this case. b) privFlag If the privFlag is set, then the securityModel used by the SNMP engine which sent the message MUST also protect the scopedPDU in an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the scopedPDU. If the privFlag is zero, then the securityModel in use does not need to protect the data from disclosure. It is an explicit requirement of the SNMP architecture that if privacy is selected, then authentication is also required. That means that if the privFlag is set, then the authFlag MUST also be set to one. The combination of the authFlag and the privFlag comprises a Level of Security as follows: authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv authFlag zero, privFlag one -> invalid combination, see below authFlag one, privFlag zero -> securityLevel is authNoPriv authFlag one, privFlag one -> securityLevel is authPriv The elements of procedure (see below) describe the action to be taken when the invalid combination of authFlag equal to zero and privFlag equal to one is encountered. The remaining bits in msgFlags are reserved, and MUST be set to zero when sending a message and SHOULD be ignored when receiving a message. Case, et al. Standards Track [Page 23] RFC 3412 Message Processing and Dispatching for SNMP December 2002 6.5. msgSecurityModel The v3MP supports the concurrent existence of multiple Security Models to provide security services for SNMPv3 messages. The msgSecurityModel field in an SNMPv3 Message identifies which Security Model was used by the sender to generate the message and therefore which securityModel MUST be used by the receiver to perform security processing for the message. The mapping to the appropriate securityModel implementation within an SNMP engine is accomplished in an implementation-dependent manner. 6.6. msgSecurityParameters The msgSecurityParameters field of the SNMPv3 Message is used for communication between the Security Model modules in the sending and receiving SNMP engines. The data in the msgSecurityParameters field is used exclusively by the Security Model, and the contents and format of the data is defined by the Security Model. This OCTET STRING is not interpreted by the v3MP, but is passed to the local implementation of the Security Model indicated by the msgSecurityModel field in the message. 6.7. scopedPduData The scopedPduData field represents either the plain text scopedPDU if the privFlag in the msgFlags is zero, or it represents an encryptedPDU (encoded as an OCTET STRING) which MUST be decrypted by the securityModel in use to produce a plaintext scopedPDU. 6.8. scopedPDU The scopedPDU contains information to identify an administratively unique context and a PDU. The object identifiers in the PDU refer to managed objects which are (expected to be) accessible within the specified context. 6.8.1. contextEngineID The contextEngineID in the SNMPv3 message uniquely identifies, within an administrative domain, an SNMP entity that may realize an instance of a context with a particular contextName. For incoming messages, the contextEngineID is used in conjunction with the pduType to determine to which application the scopedPDU will be sent for processing. For outgoing messages, the v3MP sets the contextEngineID to the value provided by the application in the request for a message to be sent. Case, et al. Standards Track [Page 24] RFC 3412 Message Processing and Dispatching for SNMP December 2002 6.8.2. contextName The contextName field in an SNMPv3 message, in conjunction with the contextEngineID field, identifies the particular context associated with the management information contained in the PDU portion of the message. The contextName is unique within the SNMP entity specified by the contextEngineID, which may realize the managed objects referenced within the PDU. An application which originates a message provides the value for the contextName field and this value may be used during processing by an application at the receiving SNMP Engine. 6.8.3. data The data field of the SNMPv3 Message contains the PDU. Among other things, the PDU contains the PDU type that is used by the v3MP to determine the type of the incoming SNMP message. The v3MP specifies that the PDU MUST be one of those specified in [RFC3416]. 7. Elements of Procedure for v3MP This section describes the procedures followed by an SNMP engine when generating and processing SNMP messages according to the SNMPv3 Message Processing Model. Please note, that for the sake of clarity and to prevent the text from being even longer and more complicated, some details were omitted from the steps below. a) Some steps specify that when some error conditions are encountered when processing a received message, a message containing a Report PDU is generated and the received message is discarded without further processing. However, a Report-PDU MUST NOT be generated unless the PDU causing generation of the Report PDU can be determined to be a member of the Confirmed Class, or the reportableFlag is set to one and the PDU class cannot be determined. b) The elements of procedure do not always explicitly indicate when state information needs to be released. The general rule is that if state information is available when a message is to be "discarded without further processing", then the state information should also be released at that same time. Case, et al. Standards Track [Page 25] RFC 3412 Message Processing and Dispatching for SNMP December 2002 7.1. Prepare an Outgoing SNMP Message This section describes the procedure followed to prepare an SNMPv3 message from the data elements passed by the Message Dispatcher. 1) The Message Dispatcher may request that an SNMPv3 message containing a Read Class, Write Class, or Notification Class PDU be prepared for sending. a) It makes such a request according to the abstract service primitive: statusInformation = -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- requested transport domain IN transportAddress -- requested destination address IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- version of the PDU * IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE * IN sendPduHandle -- the handle for matching -- incoming responses OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the length of the message ) * The SNMPv3 Message Processing Model does not use the values of expectResponse or pduVersion. b) A unique msgID is generated. The number used for msgID should not have been used recently, and MUST NOT be the same as was used for any outstanding request. 2) The Message Dispatcher may request that an SNMPv3 message containing a Response Class or Internal Class PDU be prepared for sending. Case, et al. Standards Track [Page 26] RFC 3412 Message Processing and Dispatching for SNMP December 2002 a) It makes such a request according to the abstract service primitive: result = -- SUCCESS or FAILURE prepareResponseMessage( IN messageProcessingModel -- typically, SNMP version IN securityModel -- same as on incoming request IN securityName -- same as on incoming request IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size sender can -- accept IN stateReference -- reference to state -- information presented with -- the request IN statusInformation -- success or errorIndication -- error counter OID and value -- when errorIndication OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- the length of the message ) b) The cached information for the original request is retrieved via the stateReference, including: - msgID, - contextEngineID, - contextName, - securityModel, - securityName, - securityLevel, - securityStateReference, - reportableFlag, - transportDomain, and - transportAddress. The SNMPv3 Message Processing Model does not allow cached data to be overridden, except by error indications as detailed in (3) below. Case, et al. Standards Track [Page 27] RFC 3412 Message Processing and Dispatching for SNMP December 2002 3) If statusInformation contains values for an OID/value combination (potentially also containing a securityLevel value, contextEngineID value, or contextName value), then: a) If a PDU is provided, it is the PDU from the original request. If possible, extract the request-id and pduType. b) If the pduType is determined to not be a member of the Confirmed Class, or if the reportableFlag is zero and the pduType cannot be determined, then the original message is discarded, and no further processing is done. A result of FAILURE is returned. SNMPv3 Message Processing is complete. c) A Report PDU is prepared: 1) the varBindList is set to contain the OID and value from the statusInformation. 2) error-status is set to 0. 3) error-index is set to 0. 4) request-id is set to the value extracted in step b). Otherwise, request-id is set to 0. d) The errorIndication in statusInformation may be accompanied by a securityLevel value, a contextEngineID value, or a contextName value. 1) If statusInformation contains a value for securityLevel, then securityLevel is set to that value, otherwise it is set to noAuthNoPriv. 2) If statusInformation contains a value for contextEngineID, then contextEngineID is set to that value, otherwise it is set to the value of this entity's snmpEngineID. 3) If statusInformation contains a value for contextName, then contextName is set to that value, otherwise it is set to the default context of "" (zero-length string). e) PDU is set to refer to the new Report-PDU. The old PDU is discarded. f) Processing continues with step 6) below. Case, et al. Standards Track [Page 28] RFC 3412 Message Processing and Dispatching for SNMP December 2002 4) If the contextEngineID is not yet determined, then the contextEngineID is determined, in an implementation-dependent manner, possibly using the transportDomain and transportAddress. 5) If the contextName is not yet determined, the contextName is set to the default context. 6) A scopedPDU is prepared from the contextEngineID, contextName, and PDU. 7) msgGlobalData is constructed as follows: a) The msgVersion field is set to snmpv3(3). b) msgID is set as determined in step 1 or 2 above. c) msgMaxSize is set to an implementation-dependent value. d) msgFlags are set as follows: - If securityLevel specifies noAuthNoPriv, then authFlag and privFlag are both set to zero. - If securityLevel specifies authNoPriv, then authFlag is set to one and privFlag is set to zero. - If securityLevel specifies authPriv, then authFlag is set to one and privFlag is set to one. - If the PDU is from the Unconfirmed Class, then the reportableFlag is set to zero. - If the PDU is from the Confirmed Class then the reportableFlag is set to one. - All other msgFlags bits are set to zero. e) msgSecurityModel is set to the value of securityModel. Case, et al. Standards Track [Page 29] RFC 3412 Message Processing and Dispatching for SNMP December 2002 8) If the PDU is from the Response Class or the Internal Class, then: a) The specified Security Model is called to generate the message according to the primitive: statusInformation = generateResponseMsg( IN messageProcessingModel -- SNMPv3 Message Processing -- Model IN globalData -- msgGlobalData from step 7 IN maxMessageSize -- from msgMaxSize (step 7c) IN securityModel -- as determined in step 7e IN securityEngineID -- the value of snmpEngineID IN securityName -- on behalf of this principal IN securityLevel -- for the outgoing message IN scopedPDU -- as prepared in step 6) IN securityStateReference -- as determined in step 2 OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message ) If, upon return from the Security Model, the statusInformation includes an errorIndication, then any cached information about the outstanding request message is discarded, and an errorIndication is returned, so it can be returned to the calling application. SNMPv3 Message Processing is complete. b) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 9) If the PDU is from the Confirmed Class or the Notification Class, then: a) If the PDU is from the Unconfirmed Class, then securityEngineID is set to the value of this entity's snmpEngineID. Otherwise, the snmpEngineID of the target entity is determined, in an implementation-dependent manner, possibly using transportDomain and transportAddress. The value of the securityEngineID is set to the value of the target entity's snmpEngineID. Case, et al. Standards Track [Page 30] RFC 3412 Message Processing and Dispatching for SNMP December 2002 b) The specified Security Model is called to generate the message according to the primitive: statusInformation = generateRequestMsg( IN messageProcessingModel -- SNMPv3 Message Processing Model IN globalData -- msgGlobalData, from step 7 IN maxMessageSize -- from msgMaxSize in step 7 c) IN securityModel -- as provided by caller IN securityEngineID -- authoritative SNMP entity -- from step 9 a) IN securityName -- as provided by caller IN securityLevel -- as provided by caller IN scopedPDU -- as prepared in step 6 OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of the generated message ) If, upon return from the Security Model, the statusInformation includes an errorIndication, then the message is discarded, and the errorIndication is returned, so it can be returned to the calling application, and no further processing is done. SNMPv3 Message Processing is complete. c) If the PDU is from the Confirmed Class, information about the outgoing message is cached, and an implementation-specific stateReference is created. Information to be cached includes the values of: - sendPduHandle - msgID - snmpEngineID - securityModel - securityName - securityLevel - contextEngineID - contextName d) A SUCCESS result is returned. SNMPv3 Message Processing is complete. Case, et al. Standards Track [Page 31] RFC 3412 Message Processing and Dispatching for SNMP December 2002 7.2. Prepare Data Elements from an Incoming SNMP Message This section describes the procedure followed to extract data from an SNMPv3 message, and to prepare the data elements required for further processing of the message by the Message Dispatcher. 1) The message is passed in from the Message Dispatcher according to the abstract service primitive: result = -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT statusInformation -- success or errorIndication -- error counter OID and value -- when errorIndication OUT stateReference -- reference to state information -- to be used for a possible ) -- Response 2) If the received message is not the serialization (according to the conventions of [RFC3417]) of an SNMPv3Message value, then the snmpInASNParseErrs counter [RFC3418] is incremented, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. 3) The values for msgVersion, msgID, msgMaxSize, msgFlags, msgSecurityModel, msgSecurityParameters, and msgData are extracted from the message. 4) If the value of the msgSecurityModel component does not match a supported securityModel, then the snmpUnknownSecurityModels counter is incremented, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. Case, et al. Standards Track [Page 32] RFC 3412 Message Processing and Dispatching for SNMP December 2002 5) The securityLevel is determined from the authFlag and the privFlag bits of the msgFlags component as follows: a) If the authFlag is not set and the privFlag is not set, then securityLevel is set to noAuthNoPriv. b) If the authFlag is set and the privFlag is not set, then securityLevel is set to authNoPriv. c) If the authFlag is set and the privFlag is set, then securityLevel is set to authPriv. d) If the authFlag is not set and privFlag is set, then the snmpInvalidMsgs counter is incremented, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. e) Any other bits in the msgFlags are ignored. 6) The security module implementing the Security Model as specified by the securityModel component is called for authentication and privacy services. This is done according to the abstract service primitive: statusInformation = -- errorIndication or success -- error counter OID and -- value if error processIncomingMsg( IN messageProcessingModel -- SNMPv3 Message Processing Model IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT securityStateReference -- reference to security state ) -- information, needed for -- response If an errorIndication is returned by the security module, then: a) If statusInformation contains values for an OID/value pair, then generation of a Report PDU is attempted (see step 3 in section 7.1). Case, et al. Standards Track [Page 33] RFC 3412 Message Processing and Dispatching for SNMP December 2002 1) If the scopedPDU has been returned from processIncomingMsg, then determine contextEngineID, contextName, and PDU. 2) Information about the message is cached and a stateReference is created (implementation-specific). Information to be cached includes the values of: msgVersion, msgID, securityLevel, msgFlags, msgMaxSize, securityModel, maxSizeResponseScopedPDU, securityStateReference 3) Request that a Report-PDU be prepared and sent, according to the abstract service primitive: result = -- SUCCESS or FAILURE returnResponsePdu( IN messageProcessingModel -- SNMPv3(3) IN securityModel -- same as on incoming request IN securityName -- from processIncomingMsg IN securityLevel -- same as on incoming request IN contextEngineID -- from step 6 a) 1) IN contextName -- from step 6 a) 1) IN pduVersion -- SNMPv2-PDU IN PDU -- from step 6 a) 1) IN maxSizeResponseScopedPDU -- from processIncomingMsg IN stateReference -- from step 6 a) 2) IN statusInformation -- from processIncomingMsg ) b) The incoming message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. 7) The scopedPDU is parsed to extract the contextEngineID, the contextName and the PDU. If any parse error occurs, then the snmpInASNParseErrs counter [RFC3418] is incremented, the security state information is discarded, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. Treating an unknown PDU type is treated as a parse error is an implementation option. Case, et al. Standards Track [Page 34] RFC 3412 Message Processing and Dispatching for SNMP December 2002 8) The pduVersion is determined in an implementation-dependent manner. For SNMPv3, the pduVersion would be an SNMPv2-PDU. 9) The pduType is determined, in an implementation-dependent manner. For [RFC3416], the pduTypes include: - GetRequest-PDU, - GetNextRequest-PDU, - GetBulkRequest-PDU, - SetRequest-PDU, - InformRequest-PDU, - SNMPv2-Trap-PDU, - Response-PDU, - Report-PDU. 10) If the pduType is from the Response Class or the Internal Class, then: a) The value of the msgID component is used to find the cached information for a corresponding outstanding Request message. If no such outstanding Request message is found, then the security state information is discarded, the message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. b) sendPduHandle is retrieved from the cached information. Otherwise, sendPduHandle is set to , an implementation defined value. 11) If the pduType is from the Internal Class, then: a) statusInformation is created using the contents of the Report-PDU, in an implementation-dependent manner. This statusInformation will be forwarded to the application associated with the sendPduHandle. b) The cached data for the outstanding message, referred to by stateReference, is retrieved. If the securityModel or securityLevel values differ from the cached ones, it is important to recognize that Internal Class PDUs delivered at the security level of noAuthNoPriv open a window of opportunity for spoofing or replay attacks. If the receiver of such messages is aware of these risks, the use of such unauthenticated messages is acceptable and may provide a useful function for discovering engine IDs or for detecting misconfiguration at remote nodes. Case, et al. Standards Track [Page 35] RFC 3412 Message Processing and Dispatching for SNMP December 2002 When the securityModel or securityLevel values differ from the cached ones, an implementation may retain the cached information about the outstanding Request message, in anticipation of the possibility that the Internal Class PDU received might be illegitimate. Otherwise, any cached information about the outstanding Request message is discarded. c) The security state information for this incoming message is discarded. d) stateReference is set to . e) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 12) If the pduType is from the Response Class, then: a) The cached data for the outstanding request, referred to by stateReference, is retrieved, including: - snmpEngineID - securityModel - securityName - securityLevel - contextEngineID - contextName b) If the values extracted from the incoming message differ from the cached data, then any cached information about the outstanding Request message is discarded, the incoming message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. When the securityModel or securityLevel values differ from the cached ones, an implementation may retain the cached information about the outstanding Request message, in anticipation of the possibility that the Response Class PDU received might be illegitimate. c) Otherwise, any cached information about the outstanding Request message is discarded, and the stateReference is set to . d) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 13) If the pduType is from the Confirmed Class, then: Case, et al. Standards Track [Page 36] RFC 3412 Message Processing and Dispatching for SNMP December 2002 a) If the value of securityEngineID is not equal to the value of snmpEngineID, then the security state information is discarded, any cached information about this message is discarded, the incoming message is discarded without further processing, and a FAILURE result is returned. SNMPv3 Message Processing is complete. b) Information about the message is cached and a stateReference is created (implementation-specific). Information to be cached includes the values of: msgVersion, msgID, securityLevel, msgFlags, msgMaxSize, securityModel, maxSizeResponseScopedPDU, securityStateReference c) A SUCCESS result is returned. SNMPv3 Message Processing is complete. 14) If the pduType is from the Unconfirmed Class, then a SUCCESS result is returned. SNMPv3 Message Processing is complete. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Case, et al. Standards Track [Page 37] RFC 3412 Message Processing and Dispatching for SNMP December 2002 9. Acknowledgements This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members: Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T. J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T. J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T. J. Watson Research Center) Case, et al. Standards Track [Page 38] RFC 3412 Message Processing and Dispatching for SNMP December 2002 The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were: David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center) As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) 10. Security Considerations The Dispatcher coordinates the processing of messages to provide a level of security for management messages and to direct the SNMP PDUs to the proper SNMP application(s). A Message Processing Model, and in particular the v3MP defined in this document, interacts as part of the Message Processing with Security Models in the Security Subsystem via the abstract service interface primitives defined in [RFC3411] and elaborated above. The level of security actually provided is primarily determined by the specific Security Model implementation(s) and the specific SNMP application implementation(s) incorporated into this framework. Applications have access to data which is not secured. Applications should take reasonable steps to protect the data from disclosure, and when they send data across the network, they should obey the securityLevel and call upon the services of an Access Control Model as they apply access control. Case, et al. Standards Track [Page 39] RFC 3412 Message Processing and Dispatching for SNMP December 2002 The values for the msgID element used in communication between SNMP entities MUST be chosen to avoid replay attacks. The values do not need to be unpredictable; it is sufficient that they not repeat. When exchanges are carried out over an insecure network, there is an open opportunity for a third party to spoof or replay messages when any message of an exchange is given at the security level of noAuthNoPriv. For most exchanges, all messages exist at the same security level. In the case where the final message is an Internal Class PDU, this message may be delivered at a level of noAuthNoPriv or authNoPriv, independent of the security level of the preceding messages. Internal Class PDUs delivered at the level of authNoPriv are not considered to pose a security hazard. Internal Class PDUs delivered at the security level of noAuthNoPriv open a window of opportunity for spoofing or replay attacks. If the receiver of such messages is aware of these risks, the use of such unauthenticated messages is acceptable and may provide a useful function for discovering engine IDs or for detecting misconfiguration at remote nodes. This document also contains a MIB definition module. None of the objects defined is writable, and the information they represent is not deemed to be particularly sensitive. However, if they are deemed sensitive in a particular environment, access to them should be restricted through the use of appropriately configured Security and Access Control models. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Case, et al. Standards Track [Page 40] RFC 3412 Message Processing and Dispatching for SNMP December 2002 [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. 11.2. Informative References [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework", RFC 2576, March 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Case, et al. Standards Track [Page 41] RFC 3412 Message Processing and Dispatching for SNMP December 2002 12. Editors' Addresses Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA Phone: +1 423-573-1434 EMail: case@snmp.com David Harrington Enterasys Networks 35 Industrial Way Post Office Box 5005 Rochester, NH 03866-5005 USA Phone: +1 603-337-2614 EMail: dbh@enterasys.com Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA Phone: +1 408-546-1006 EMail: randy_presuhn@bmc.com Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Phone: +31 348-680-485 EMail: bwijnen@lucent.com Case, et al. Standards Track [Page 42] RFC 3412 Message Processing and Dispatching for SNMP December 2002 13. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Case, et al. Standards Track [Page 43] snmp-mibs-downloader-1.1/mibrfcs/rfc3413.txt0000644000000000000000000045416711402176071015575 0ustar Network Working Group D. Levi Request for Comments: 3413 Nortel Networks STD: 62 P. Meyer Obsoletes: 2573 Secure Computing Corporation Category: Standards Track B. Stewart Retired December 2002 Simple Network Management Protocol (SNMP) Applications 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. Abstract This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. Table of Contents 1 Overview ............................................... 2 1.1 Command Generator Applications ......................... 3 1.2 Command Responder Applications ......................... 3 1.3 Notification Originator Applications ................... 3 1.4 Notification Receiver Applications ..................... 3 1.5 Proxy Forwarder Applications ........................... 4 2 Management Targets ..................................... 5 3 Elements Of Procedure .................................. 6 3.1 Command Generator Applications ......................... 6 3.2 Command Responder Applications ......................... 9 3.3 Notification Originator Applications ................... 14 3.4 Notification Receiver Applications ..................... 17 3.5 Proxy Forwarder Applications ........................... 19 3.5.1 Request Forwarding ..................................... 21 Levi, et. al. Standards Track [Page 1] RFC 3413 SNMP Applications December 2002 3.5.1.1 Processing an Incoming Request ......................... 21 3.5.1.2 Processing an Incoming Response ........................ 24 3.5.1.3 Processing an Incoming Internal-Class PDU .............. 25 3.5.2 Notification Forwarding ................................ 26 4 The Structure of the MIB Modules ....................... 29 4.1 The Management Target MIB Module ....................... 29 4.1.1 Tag Lists .....................,........................ 29 4.1.2 Definitions ..................,......................... 30 4.2 The Notification MIB Module ............................ 44 4.2.1 Definitions ............................................ 44 4.3 The Proxy MIB Module ................................... 56 4.3.1 Definitions ............................................ 57 5 Identification of Management Targets in Notification Originators ............................... 63 6 Notification Filtering ................................. 64 7 Management Target Translation in Proxy Forwarder Applications ........................... 65 7.1 Management Target Translation for Request Forwarding ..................................... 65 7.2 Management Target Translation for Notification Forwarding ................................ 66 8 Intellectual Property .................................. 67 9 Acknowledgments ........................................ 67 10 Security Considerations ................................ 69 11 References ............................................. 69 A. Trap Configuration Example ............................. 71 Editors' Addresses ..................................... 73 Full Copyright Statement ............................... 74 1. Overview This document describes five types of SNMP applications: - Applications which initiate SNMP Read-Class, and/or Write-Class requests, called 'command generators.' - Applications which respond to SNMP Read-Class, and/or Write-Class requests, called 'command responders.' - Applications which generate SNMP Notification-Class PDUs, called 'notification originators.' - Applications which receive SNMP Notification-Class PDUs, called 'notification receivers.' - Applications which forward SNMP messages, called 'proxy forwarders.' Levi, et. al. Standards Track [Page 2] RFC 3413 SNMP Applications December 2002 Note that there are no restrictions on which types of applications may be associated with a particular SNMP engine. For example, a single SNMP engine may, in fact, be associated with both command generator and command responder applications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Command Generator Applications A command generator application initiates SNMP Read-Class and/or Write-Class requests, and processes responses to requests which it generated. 1.2. Command Responder Applications A command responder application receives SNMP Read-Class and/or Write-Class requests destined for the local system as indicated by the fact that the contextEngineID in the received request is equal to that of the local engine through which the request was received. The command responder application will perform the appropriate protocol operation, using access control, and will generate a response message to be sent to the request's originator. 1.3. Notification Originator Applications A notification originator application conceptually monitors a system for particular events or conditions, and generates Notification-Class messages based on these events or conditions. A notification originator must have a mechanism for determining where to send messages, and what SNMP version and security parameters to use when sending messages. A mechanism and MIB module for this purpose is provided in this document. Note that Notification-Class PDUs generated by a notification originator may be either Confirmed-Class or Unconfirmed-Class PDU types. 1.4. Notification Receiver Applications A notification receiver application listens for notification messages, and generates response messages when a message containing a Confirmed-Class PDU is received. Levi, et. al. Standards Track [Page 3] RFC 3413 SNMP Applications December 2002 1.5. Proxy Forwarder Applications A proxy forwarder application forwards SNMP messages. Note that implementation of a proxy forwarder application is optional. The sections describing proxy (3.5, 4.3, and 7) may be skipped for implementations that do not include a proxy forwarder application. The term "proxy" has historically been used very loosely, with multiple different meanings. These different meanings include (among others): (1) the forwarding of SNMP requests to other SNMP entities without regard for what managed object types are being accessed; for example, in order to forward an SNMP request from one transport domain to another, or to translate SNMP requests of one version into SNMP requests of another version; (2) the translation of SNMP requests into operations of some non-SNMP management protocol; and (3) support for aggregated managed objects where the value of one managed object instance depends upon the values of multiple other (remote) items of management information. Each of these scenarios can be advantageous; for example, support for aggregation of management information can significantly reduce the bandwidth requirements of large-scale management activities. However, using a single term to cover multiple different scenarios causes confusion. To avoid such confusion, this document uses the term "proxy" with a much more tightly defined meaning. The term "proxy" is used in this document to refer to a proxy forwarder application which forwards either SNMP messages without regard for what managed objects are contained within those messages. This definition is most closely related to the first definition above. Note, however, that in the SNMP architecture [RFC3411], a proxy forwarder is actually an application, and need not be associated with what is traditionally thought of as an SNMP agent. Specifically, the distinction between a traditional SNMP agent and a proxy forwarder application is simple: Levi, et. al. Standards Track [Page 4] RFC 3413 SNMP Applications December 2002 - a proxy forwarder application forwards SNMP messages to other SNMP engines according to the context, and irrespective of the specific managed object types being accessed, and forwards the response to such previously forwarded messages back to the SNMP engine from which the original message was received; - in contrast, the command responder application that is part of what is traditionally thought of as an SNMP agent, and which processes SNMP requests according to the (names of the) individual managed object types and instances being accessed, is NOT a proxy forwarder application from the perspective of this document. Thus, when a proxy forwarder application forwards a request or notification for a particular contextEngineID / contextName pair, not only is the information on how to forward the request specifically associated with that context, but the proxy forwarder application has no need of a detailed definition of a MIB view (since the proxy forwarder application forwards the request irrespective of the managed object types). In contrast, a command responder application must have the detailed definition of the MIB view, and even if it needs to issue requests to other entities, via SNMP or otherwise, that need is dependent on the individual managed object instances being accessed (i.e., not only on the context). Note that it is a design goal of a proxy forwarder application to act as an intermediary between the endpoints of a transaction. In particular, when forwarding Confirmed Notification-Class messages, the associated response is forwarded when it is received from the target to which the Notification-Class message was forwarded, rather than generating a response immediately when the Notification-Class message is received. 2. Management Targets Some types of applications (notification generators and proxy forwarders in particular) require a mechanism for determining where and how to send generated messages. This document provides a mechanism and MIB module for this purpose. The set of information that describes where and how to send a message is called a 'Management Target', and consists of two kinds of information: - Destination information, consisting of a transport domain and a transport address. This is also termed a transport endpoint. - SNMP parameters, consisting of message processing model, security model, security level, and security name information. Levi, et. al. Standards Track [Page 5] RFC 3413 SNMP Applications December 2002 The SNMP-TARGET-MIB module described later in this document contains one table for each of these types of information. There can be a many-to-many relationship in the MIB between these two types of information. That is, there may be multiple transport endpoints associated with a particular set of SNMP parameters, or a particular transport endpoint may be associated with several sets of SNMP parameters. 3. Elements Of Procedure The following sections describe the procedures followed by each type of application when generating messages for transmission or when processing received messages. Applications communicate with the Dispatcher using the abstract service interfaces defined in [RFC3411]. 3.1. Command Generator Applications A command generator initiates an SNMP request by calling the Dispatcher using the following abstract service interface: statusInformation = -- sendPduHandle if success -- errorIndication if failure sendPdu( IN transportDomain -- transport domain to be used IN transportAddress -- destination network address IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE ) Where: - The transportDomain is that of the destination of the message. - The transportAddress is that of the destination of the message. - The messageProcessingModel indicates which Message Processing Model the application wishes to use. - The securityModel is the security model that the application wishes to use. Levi, et. al. Standards Track [Page 6] RFC 3413 SNMP Applications December 2002 - The securityName is the security model independent name for the principal on whose behalf the application wishes the message to be generated. - The securityLevel is the security level that the application wishes to use. - The contextEngineID specifies the location of the management information it is requesting. Note that unless the request is being sent to a proxy, this value will usually be equal to the snmpEngineID value of the engine to which the request is being sent. - The contextName specifies the local context name for the management information it is requesting. - The pduVersion indicates the version of the PDU to be sent. - The PDU is a value constructed by the command generator containing the management operation that the command generator wishes to perform. - The expectResponse argument indicates that a response is expected. The result of the sendPdu interface indicates whether the PDU was successfully sent. If it was successfully sent, the returned value will be a sendPduHandle. The command generator should store the sendPduHandle so that it can correlate a response to the original request. The Dispatcher is responsible for delivering the response to a particular request to the correct command generator application. The abstract service interface used is: processResponsePdu( -- process Response PDU IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN statusInformation -- success or errorIndication IN sendPduHandle -- handle from sendPdu ) Levi, et. al. Standards Track [Page 7] RFC 3413 SNMP Applications December 2002 Where: - The messageProcessingModel is the value from the received response. - The securityModel is the value from the received response. - The securityName is the value from the received response. - The securityLevel is the value from the received response. - The contextEngineID is the value from the received response. - The contextName is the value from the received response. - The pduVersion indicates the version of the PDU in the received response. - The PDU is the value from the received response. - The statusInformation indicates success or failure in receiving the response. - The sendPduHandle is the value returned by the sendPdu call which generated the original request to which this is a response. The procedure when a command generator receives a message is as follows: (1) If the received values of messageProcessingModel, securityModel, securityName, contextEngineID, contextName, and pduVersion are not all equal to the values used in the original request, the response is discarded. (2) The operation type, request-id, error-status, error-index, and variable-bindings are extracted from the PDU and saved. If the request-id is not equal to the value used in the original request, the response is discarded. (3) At this point, it is up to the application to take an appropriate action. The specific action is implementation dependent. If the statusInformation indicates that the request failed, an appropriate action might be to attempt to transmit the request again, or to notify the person operating the application that a failure occurred. Levi, et. al. Standards Track [Page 8] RFC 3413 SNMP Applications December 2002 3.2. Command Responder Applications Before a command responder application can process messages, it must first associate itself with an SNMP engine. The abstract service interface used for this purpose is: statusInformation = -- success or errorIndication registerContextEngineID( IN contextEngineID -- take responsibility for this one IN pduType -- the pduType(s) to be registered ) Where: - The statusInformation indicates success or failure of the registration attempt. - The contextEngineID is equal to the snmpEngineID of the SNMP engine with which the command responder is registering. - The pduType indicates a Read-Class and/or Write-Class PDU. Note that if another command responder application is already registered with an SNMP engine, any further attempts to register with the same contextEngineID and pduType will be denied. This implies that separate command responder applications could register separately for the various pdu types. However, in practice this is undesirable, and only a single command responder application should be registered with an SNMP engine at any given time. A command responder application can disassociate with an SNMP engine using the following abstract service interface: unregisterContextEngineID( IN contextEngineID -- give up responsibility for this one IN pduType -- the pduType(s) to be unregistered ) Where: - The contextEngineID is equal to the snmpEngineID of the SNMP engine with which the command responder is cancelling the registration. - The pduType indicates a Read-Class and/or Write-Class PDU. Levi, et. al. Standards Track [Page 9] RFC 3413 SNMP Applications December 2002 Once the command responder has registered with the SNMP engine, it waits to receive SNMP messages. The abstract service interface used for receiving messages is: processPdu( -- process Request/Notification PDU IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size of the Response PDU IN stateReference -- reference to state information ) -- needed when sending a response Where: - The messageProcessingModel indicates which Message Processing Model received and processed the message. - The securityModel is the value from the received message. - The securityName is the value from the received message. - The securityLevel is the value from the received message. - The contextEngineID is the value from the received message. - The contextName is the value from the received message. - The pduVersion indicates the version of the PDU in the received message. - The PDU is the value from the received message. - The maxSizeResponseScopedPDU is the maximum allowable size of a ScopedPDU containing a Response PDU (based on the maximum message size that the originator of the message can accept). - The stateReference is a value which references cached information about each received request message. This value must be returned to the Dispatcher in order to generate a response. Levi, et. al. Standards Track [Page 10] RFC 3413 SNMP Applications December 2002 The procedure when a message is received is as follows: (1) The operation type is determined from the ASN.1 tag value associated with the PDU parameter. The operation type should always be one of the types previously registered by the application. (2) The request-id is extracted from the PDU and saved. (3) Any PDU type specific parameters are extracted from the PDU and saved (for example, if the PDU type is an SNMPv2 GetBulk PDU, the non-repeaters and max-repetitions values are extracted). (4) The variable-bindings are extracted from the PDU and saved. (5) The management operation represented by the PDU type is performed with respect to the relevant MIB view within the context named by the contextName (for an SNMPv2 PDU type, the operation is performed according to the procedures set forth in [RFC1905]). The relevant MIB view is determined by the securityLevel, securityModel, contextName, securityName, and the class of the PDU type. To determine whether a particular object instance is within the relevant MIB view, the following abstract service interface is called: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) Where: - The securityModel is the value from the received message. - The securityName is the value from the received message. - The securityLevel is the value from the received message. - The viewType indicates whether the PDU type is a Read-Class or Write-Class operation. - The contextName is the value from the received message. Levi, et. al. Standards Track [Page 11] RFC 3413 SNMP Applications December 2002 - The variableName is the object instance of the variable for which access rights are to be checked. Normally, the result of the management operation will be a new PDU value, and processing will continue in step (6) below. However, at any time during the processing of the management operation: - If the isAccessAllowed ASI returns a noSuchView, noAccessEntry, or noGroupName error, processing of the management operation is halted, a PDU value is constructed using the values from the originally received PDU, but replacing the error-status with an authorizationError code, and error-index value of 0, and control is passed to step (6) below. - If the isAccessAllowed ASI returns an otherError, processing of the management operation is halted, a different PDU value is constructed using the values from the originally received PDU, but replacing the error-status with a genError code and the error-index with the index of the failed variable binding, and control is passed to step (6) below. - If the isAccessAllowed ASI returns a noSuchContext error, processing of the management operation is halted, no result PDU is generated, the snmpUnknownContexts counter is incremented, and control is passed to step (6) below for generation of a report message. - If the context named by the contextName parameter is unavailable, processing of the management operation is halted, no result PDU is generated, the snmpUnavailableContexts counter is incremented, and control is passed to step (6) below for generation of a report message. (6) The Dispatcher is called to generate a response or report message. The abstract service interface is: Levi, et. al. Standards Track [Page 12] RFC 3413 SNMP Applications December 2002 returnResponsePdu( IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model in use IN securityName -- on behalf of this principal IN securityLevel -- same as on incoming request IN contextEngineID -- data from/at this SNMP entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size of the Response PDU IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication ) -- error counter OID/value if error Where: - The messageProcessingModel is the value from the processPdu call. - The securityModel is the value from the processPdu call. - The securityName is the value from the processPdu call. - The securityLevel is the value from the processPdu call. - The contextEngineID is the value from the processPdu call. - The contextName is the value from the processPdu call. - The pduVersion indicates the version of the PDU to be returned. If no result PDU was generated, the pduVersion is an undefined value. - The PDU is the result generated in step (5) above. If no result PDU was generated, the PDU is an undefined value. - The maxSizeResponseScopedPDU is a local value indicating the maximum size of a ScopedPDU that the application can accept. - The stateReference is the value from the processPdu call. - The statusInformation either contains an indication that no error occurred and that a response should be generated, or contains an indication that an error occurred along with the OID and counter value of the appropriate error counter object. Levi, et. al. Standards Track [Page 13] RFC 3413 SNMP Applications December 2002 Note that a command responder application should always call the returnResponsePdu abstract service interface, even in the event of an error such as a resource allocation error. In the event of such an error, the PDU value passed to returnResponsePdu should contain appropriate values for errorStatus and errorIndex. Note that the text above describes situations where the snmpUnknownContexts counter is incremented, and where the snmpUnavailableContexts counter is incremented. The difference between these is that the snmpUnknownContexts counter is incremented when a request is received for a context which is unknown to the SNMP entity. The snmpUnavailableContexts counter is incremented when a request is received for a context which is known to the SNMP entity, but is currently unavailable. Determining when a context is unavailable is implementation specific, and some implementations may never encounter this situation, and so may never increment the snmpUnavailableContexts counter. 3.3. Notification Originator Applications A notification originator application generates SNMP messages containing Notification-Class PDUs (for example, SNMPv2-Trap PDUs or Inform PDUs). There is no requirement as to what specific types of Notification-Class PDUs a particular implementation must be capable of generating. Notification originator applications require a mechanism for identifying the management targets to which notifications should be sent. The particular mechanism used is implementation dependent. However, if an implementation makes the configuration of management targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module described in this document. When a notification originator wishes to generate a notification, it must first determine in which context the information to be conveyed in the notification exists, i.e., it must determine the contextEngineID and contextName. It must then determine the set of management targets to which the notification should be sent. The application must also determine, for each management target, what specific PDU type the notification message should contain, and if it is to contain a Confirmed-Class PDU, the number of retries and retransmission algorithm. Levi, et. al. Standards Track [Page 14] RFC 3413 SNMP Applications December 2002 The mechanism by which a notification originator determines this information is implementation dependent. Once the application has determined this information, the following procedure is performed for each management target: (1) Any appropriate filtering mechanisms are applied to determine whether the notification should be sent to the management target. If such filtering mechanisms determine that the notification should not be sent, processing continues with the next management target. Otherwise, (2) The appropriate set of variable-bindings is retrieved from local MIB instrumentation within the relevant MIB view. The relevant MIB view is determined by the securityLevel, securityModel, contextName, and securityName of the management target. To determine whether a particular object instance is within the relevant MIB view, the isAccessAllowed abstract service interface is used, in the same manner as described in the preceding section, except that the viewType indicates a Notification-Class operation. If the statusInformation returned by isAccessAllowed does not indicate accessAllowed, the notification is not sent to the management target. (3) The NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this is the value of the element of the variable bindings whose name is snmpTrapOID.0, i.e., the second variable binding) is checked using the isAccessAllowed abstract service interface, using the same parameters used in the preceding step. If the statusInformation returned by isAccessAllowed does not indicate accessAllowed, the notification is not sent to the management target. (4) A PDU is constructed using a locally unique request-id value, a PDU type as determined by the implementation, an error-status and error-index value of 0, and the variable-bindings supplied previously in step (2). (5) If the notification contains an Unconfirmed-Class PDU, the Dispatcher is called using the following abstract service interface: Levi, et. al. Standards Track [Page 15] RFC 3413 SNMP Applications December 2002 statusInformation = -- sendPduHandle if success -- errorIndication if failure sendPdu( IN transportDomain -- transport domain to be used IN transportAddress -- destination network address IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE ) Where: - The transportDomain is that of the management target. - The transportAddress is that of the management target. - The messageProcessingModel is that of the management target. - The securityModel is that of the management target. - The securityName is that of the management target. - The securityLevel is that of the management target. - The contextEngineID is the value originally determined for the notification. - The contextName is the value originally determined for the notification. - The pduVersion is the version of the PDU to be sent. - The PDU is the value constructed in step (4) above. - The expectResponse argument indicates that no response is expected. Otherwise, Levi, et. al. Standards Track [Page 16] RFC 3413 SNMP Applications December 2002 (6) If the notification contains a Confirmed-Class PDU, then: a) The Dispatcher is called using the sendPdu abstract service interface as described in step (5) above, except that the expectResponse argument indicates that a response is expected. b) The application caches information about the management target. c) If a response is received within an appropriate time interval from the transport endpoint of the management target, the notification is considered acknowledged and the cached information is deleted. Otherwise, d) If a response is not received within an appropriate time period, or if a report indication is received, information about the management target is retrieved from the cache, and steps a) through d) are repeated. The number of times these steps are repeated is equal to the previously determined retry count. If this retry count is exceeded, the acknowledgement of the notification is considered to have failed, and processing of the notification for this management target is halted. Note that some report indications might be considered a failure. Such report indications should be interpreted to mean that the acknowledgement of the notification has failed, and that steps a) through d) need not be repeated. Responses to Confirmed-Class PDU notifications will be received via the processResponsePdu abstract service interface. To summarize, the steps that a notification originator follows when determining where to send a notification are: - Determine the targets to which the notification should be sent. - Apply any required filtering to the list of targets. - Determine which targets are authorized to receive the notification. 3.4. Notification Receiver Applications Notification receiver applications receive SNMP Notification messages from the Dispatcher. Before any messages can be received, the notification receiver must register with the Dispatcher using the registerContextEngineID abstract service interface. The parameters used are: Levi, et. al. Standards Track [Page 17] RFC 3413 SNMP Applications December 2002 - The contextEngineID is an undefined 'wildcard' value. Notifications are delivered to a registered notification receiver regardless of the contextEngineID contained in the notification message. - The pduType indicates the type of notifications that the application wishes to receive (for example, SNMPv2-Trap PDUs or Inform PDUs). Once the notification receiver has registered with the Dispatcher, messages are received using the processPdu abstract service interface. Parameters are: - The messageProcessingModel indicates which Message Processing Model received and processed the message. - The securityModel is the value from the received message. - The securityName is the value from the received message. - The securityLevel is the value from the received message. - The contextEngineID is the value from the received message. - The contextName is the value from the received message. - The pduVersion indicates the version of the PDU in the received message. - The PDU is the value from the received message. - The maxSizeResponseScopedPDU is the maximum allowable size of a ScopedPDU containing a Response PDU (based on the maximum message size that the originator of the message can accept). - If the message contains an Unconfirmed-Class PDU, the stateReference is undefined and unused. Otherwise, the stateReference is a value which references cached information about the notification. This value must be returned to the Dispatcher in order to generate a response. When an Unconfirmed-Class PDU is delivered to a notification receiver application, it first extracts the SNMP operation type, request-id, error-status, error-index, and variable-bindings from the PDU. After this, processing depends on the particular implementation. Levi, et. al. Standards Track [Page 18] RFC 3413 SNMP Applications December 2002 When a Confirmed-Class PDU is received, the notification receiver application follows the following procedure: (1) The PDU type, request-id, error-status, error-index, and variable-bindings are extracted from the PDU. (2) A Response-Class PDU is constructed using the extracted request-id and variable-bindings, and with error-status and error-index both set to 0. (3) The Dispatcher is called to generate a response message using the returnResponsePdu abstract service interface. Parameters are: - The messageProcessingModel is the value from the processPdu call. - The securityModel is the value from the processPdu call. - The securityName is the value from the processPdu call. - The securityLevel is the value from the processPdu call. - The contextEngineID is the value from the processPdu call. - The contextName is the value from the processPdu call. - The pduVersion indicates the version of the PDU to be returned. - The PDU is the result generated in step (2) above. - The maxSizeResponseScopedPDU is a local value indicating the maximum size of a ScopedPDU that the application can accept. - The stateReference is the value from the processPdu call. - The statusInformation indicates that no error occurred and that a response should be generated. (4) After this, processing depends on the particular implementation. 3.5. Proxy Forwarder Applications A proxy forwarder application deals with forwarding SNMP messages. There are four basic types of messages which a proxy forwarder application may need to forward. These are grouped according to the class of PDU type contained in a message. The four basic types of messages are: Levi, et. al. Standards Track [Page 19] RFC 3413 SNMP Applications December 2002 - Those containing Read-Class or Write-Class PDU types (for example, Get, GetNext, GetBulk, and Set PDU types). These deal with requesting or modifying information located within a particular context. - Those containing Notification-Class PDU types (for example, SNMPv2-Trap and Inform PDU types). These deal with notifications concerning information located within a particular context. - Those containing a Response-Class PDU type. Forwarding of Response-Class PDUs always occurs as a result of receiving a response to a previously forwarded message. - Those containing Internal-Class PDU types (for example, a Report PDU). Forwarding of Internal-Class PDU types always occurs as a result of receiving an Internal-Class PDU in response to a previously forwarded message. For the first type, the proxy forwarder's role is to deliver a request for management information to an SNMP engine which is "closer" or "downstream in the path" to the SNMP engine which has access to that information, and to deliver the response containing the information back to the SNMP engine from which the request was received. The context information in a request is used to determine which SNMP engine has access to the requested information, and this is used to determine where and how to forward the request. For the second type, the proxy forwarder's role is to determine which SNMP engines should receive notifications about management information from a particular location. The context information in a notification message determines the location to which the information contained in the notification applies. This is used to determine which SNMP engines should receive notification about this information. For the third type, the proxy forwarder's role is to determine which previously forwarded request or notification (if any) the response matches, and to forward the response back to the initiator of the request or notification. For the fourth type, the proxy forwarder's role is to determine which previously forwarded request or notification (if any) the Internal- Class PDU matches, and to forward the Internal-Class PDU back to the initiator of the request or notification. Levi, et. al. Standards Track [Page 20] RFC 3413 SNMP Applications December 2002 When forwarding messages, a proxy forwarder application must perform a translation of incoming management target information into outgoing management target information. How this translation is performed is implementation specific. In many cases, this will be driven by a preconfigured translation table. If a proxy forwarder application makes the contents of this table SNMP manageable, it MUST use the SNMP-PROXY-MIB module defined in this document. 3.5.1. Request Forwarding There are two phases for request forwarding. First, the incoming request needs to be passed through the proxy application. Then, the resulting response needs to be passed back. These phases are described in the following two sections. 3.5.1.1. Processing an Incoming Request A proxy forwarder application that wishes to forward request messages must first register with the Dispatcher using the registerContextEngineID abstract service interface. The proxy forwarder must register each contextEngineID for which it wishes to forward messages, as well as for each pduType. Note that as the configuration of a proxy forwarder is changed, the particular contextEngineID values for which it is forwarding may change. The proxy forwarder should call the registerContextEngineID and unregisterContextEngineID abstract service interfaces as needed to reflect its current configuration. A proxy forwarder application should never attempt to register a value of contextEngineID which is equal to the snmpEngineID of the SNMP engine to which the proxy forwarder is associated. Once the proxy forwarder has registered for the appropriate contextEngineID values, it can start processing messages. The following procedure is used: (1) A message is received using the processPdu abstract service interface. The incoming management target information received from the processPdu interface is translated into outgoing management target information. Note that this translation may vary for different values of contextEngineID and/or contextName. The translation should result in a single management target. (2) If appropriate outgoing management target information cannot be found, the proxy forwarder increments the snmpProxyDrops counter [RFC1907], and then calls the Dispatcher using the returnResponsePdu abstract service interface. Parameters are: Levi, et. al. Standards Track [Page 21] RFC 3413 SNMP Applications December 2002 - The messageProcessingModel is the value from the processPdu call. - The securityModel is the value from the processPdu call. - The securityName is the value from the processPdu call. - The securityLevel is the value from the processPdu call. - The contextEngineID is the value from the processPdu call. - The contextName is the value from the processPdu call. - The pduVersion is the value from the processPdu call. - The PDU is an undefined value. - The maxSizeResponseScopedPDU is a local value indicating the maximum size of a ScopedPDU that the application can accept. - The stateReference is the value from the processPdu call. - The statusInformation indicates that an error occurred and includes the OID and value of the snmpProxyDrops object. Processing of the message stops at this point. Otherwise, (3) A new PDU is constructed. A unique value of request-id should be used in the new PDU (this value will enable a subsequent response message to be correlated with this request). The remainder of the new PDU is identical to the received PDU, unless the incoming SNMP version and the outgoing SNMP version support different PDU versions, in which case the proxy forwarder may need to perform a translation on the PDU. (A method for performing such a translation is described in [RFC2576].) (4) The proxy forwarder calls the Dispatcher to generate the forwarded message, using the sendPdu abstract service interface. The parameters are: - The transportDomain is that of the outgoing management target. - The transportAddress is that of the outgoing management target. - The messageProcessingModel is that of the outgoing management target. - The securityModel is that of the outgoing management target. Levi, et. al. Standards Track [Page 22] RFC 3413 SNMP Applications December 2002 - The securityName is that of the outgoing management target. - The securityLevel is that of the outgoing management target. - The contextEngineID is the value from the processPdu call. - The contextName is the value from the processPdu call. - The pduVersion is the version of the PDU to be sent. - The PDU is the value constructed in step (3) above. - The expectResponse argument indicates that a response is expected. If the sendPdu call is unsuccessful, the proxy forwarder performs the steps described in (2) above. Otherwise: (5) The proxy forwarder caches the following information in order to match an incoming response to the forwarded request: - The sendPduHandle returned from the call to sendPdu, - The request-id from the received PDU. - The contextEngineID, - The contextName, - The stateReference, - The incoming management target information, - The outgoing management information, - Any other information needed to match an incoming response to the forwarded request. If this information cannot be cached (possibly due to a lack of resources), the proxy forwarder performs the steps described in (2) above. Otherwise: (6) Processing of the request stops until a response to the forwarded request is received, or until an appropriate time interval has expired. If this time interval expires before a response has been received, the cached information about this request is removed. Levi, et. al. Standards Track [Page 23] RFC 3413 SNMP Applications December 2002 3.5.1.2. Processing an Incoming Response A proxy forwarder follows the following procedure when an incoming response is received: (1) The incoming response is received using the processResponsePdu interface. The proxy forwarder uses the received parameters to locate an entry in its cache of pending forwarded requests. This is done by matching the received parameters with the cached values of sendPduHandle, contextEngineID, contextName, outgoing management target information, and the request-id contained in the received PDU (the proxy forwarder must extract the request-id for this purpose). If an appropriate cache entry cannot be found, processing of the response is halted. Otherwise: (2) The cache information is extracted, and removed from the cache. (3) A new Response-Class PDU is constructed, using the request-id value from the original forwarded request (as extracted from the cache). All other values are identical to those in the received Response-Class PDU, unless the incoming SNMP version and the outgoing SNMP version support different PDU versions, in which case the proxy forwarder may need to perform a translation on the PDU. (A method for performing such a translation is described in [RFC2576].) (4) The proxy forwarder calls the Dispatcher using the returnResponsePdu abstract service interface. Parameters are: - The messageProcessingModel indicates the Message Processing Model by which the original incoming message was processed. - The securityModel is that of the original incoming management target extracted from the cache. - The securityName is that of the original incoming management target extracted from the cache. - The securityLevel is that of the original incoming management target extracted from the cache. - The contextEngineID is the value extracted from the cache. - The contextName is the value extracted from the cache. - The pduVersion indicates the version of the PDU to be returned. - The PDU is the (possibly translated) Response PDU. Levi, et. al. Standards Track [Page 24] RFC 3413 SNMP Applications December 2002 - The maxSizeResponseScopedPDU is a local value indicating the maximum size of a ScopedPDU that the application can accept. - The stateReference is the value extracted from the cache. - The statusInformation indicates that no error occurred and that a Response PDU message should be generated. 3.5.1.3. Processing an Incoming Internal-Class PDU A proxy forwarder follows the following procedure when an incoming Internal-Class PDU is received: (1) The incoming Internal-Class PDU is received using the processResponsePdu interface. The proxy forwarder uses the received parameters to locate an entry in its cache of pending forwarded requests. This is done by matching the received parameters with the cached values of sendPduHandle. If an appropriate cache entry cannot be found, processing of the Internal-Class PDU is halted. Otherwise: (2) The cache information is extracted, and removed from the cache. (3) If the original incoming management target information indicates an SNMP version which does not support Report PDUs, processing of the Internal-Class PDU is halted. (4) The proxy forwarder calls the Dispatcher using the returnResponsePdu abstract service interface. Parameters are: - The messageProcessingModel indicates the Message Processing Model by which the original incoming message was processed. - The securityModel is that of the original incoming management target extracted from the cache. - The securityName is that of the original incoming management target extracted from the cache. - The securityLevel is that of the original incoming management target extracted from the cache. - The contextEngineID is the value extracted from the cache. - The contextName is the value extracted from the cache. - The pduVersion indicates the version of the PDU to be returned. Levi, et. al. Standards Track [Page 25] RFC 3413 SNMP Applications December 2002 - The PDU is unused. - The maxSizeResponseScopedPDU is a local value indicating the maximum size of a ScopedPDU that the application can accept. - The stateReference is the value extracted from the cache. - The statusInformation contains values specific to the Internal-Class PDU type (for example, for a Report PDU, the statusInformation contains the contextEngineID, contextName, counter OID, and counter value received in the incoming Report PDU). 3.5.2. Notification Forwarding A proxy forwarder receives notifications in the same manner as a notification receiver application, using the processPdu abstract service interface. The following procedure is used when a notification is received: (1) The incoming management target information received from the processPdu interface is translated into outgoing management target information. Note that this translation may vary for different values of contextEngineID and/or contextName. The translation may result in multiple management targets. (2) If appropriate outgoing management target information cannot be found and the notification was an Unconfirmed-Class PDU, processing of the notification is halted. If appropriate outgoing management target information cannot be found and the notification was a Confirmed-Class PDU, the proxy forwarder increments the snmpProxyDrops object, and calls the Dispatcher using the returnResponsePdu abstract service interface. The parameters are: - The messageProcessingModel is the value from the processPdu call. - The securityModel is the value from the processPdu call. - The securityName is the value from the processPdu call. - The securityLevel is the value from the processPdu call. - The contextEngineID is the value from the processPdu call. - The contextName is the value from the processPdu call. Levi, et. al. Standards Track [Page 26] RFC 3413 SNMP Applications December 2002 - The pduVersion is the value from the processPdu call. - The PDU is an undefined and unused value. - The maxSizeResponseScopedPDU is a local value indicating the maximum size of a ScopedPDU that the application can accept. - The stateReference is the value from the processPdu call. - The statusInformation indicates that an error occurred and that a Report message should be generated. Processing of the message stops at this point. Otherwise, (3) The proxy forwarder generates a notification using the procedures described in the preceding section on Notification Originators, with the following exceptions: - The contextEngineID and contextName values from the original received notification are used. - The outgoing management targets previously determined are used. - No filtering mechanisms are applied. - The variable-bindings from the original received notification are used, rather than retrieving variable-bindings from local MIB instrumentation. In particular, no access-control is applied to these variable-bindings, nor to the value of the variable-binding containing snmpTrapOID.0. - If the original notification contains a Confirmed-Class PDU, then any outgoing management targets for which the outgoing SNMP version does not support any PDU types that are both Notification-Class and Confirmed-Class PDUs will not be used when generating the forwarded notifications. - If, for any of the outgoing management targets, the incoming SNMP version and the outgoing SNMP version support different PDU versions, the proxy forwarder may need to perform a translation on the PDU. (A method for performing such a translation is described in [RFC2576].) (4) If the original received notification contains an Unconfirmed-Class PDU, processing of the notification is now completed. Otherwise, the original received notification must contain Confirmed-Class PDU, and processing continues. Levi, et. al. Standards Track [Page 27] RFC 3413 SNMP Applications December 2002 (5) If the forwarded notifications included any Confirmed-Class PDUs, processing continues when the procedures described in the section for Notification Originators determine that either: - None of the generated notifications containing Confirmed-Class PDUs have been successfully acknowledged within the longest of the time intervals, in which case processing of the original notification is halted, or, - At least one of the generated notifications containing Confirmed-Class PDUs is successfully acknowledged, in which case a response to the original received notification containing an Confirmed-Class PDU is generated as described in the following steps. (6) A Response-Class PDU is constructed, using the values of request-id and variable-bindings from the original received Notification-Class PDU, and error-status and error-index values of 0. (7) The Dispatcher is called using the returnResponsePdu abstract service interface. Parameters are: - The messageProcessingModel is the value from the processPdu call. - The securityModel is the value from the processPdu call. - The securityName is the value from the processPdu call. - The securityLevel is the value from the processPdu call. - The contextEngineID is the value from the processPdu call. - The contextName is the value from the processPdu call. - The pduVersion indicates the version of the PDU constructed in step (6) above. - The PDU is the value constructed in step (6) above. - The maxSizeResponseScopedPDU is a local value indicating the maximum size of a ScopedPDU that the application can accept. - The stateReference is the value from the processPdu call. - The statusInformation indicates that no error occurred and that a Response-Class PDU message should be generated. Levi, et. al. Standards Track [Page 28] RFC 3413 SNMP Applications December 2002 4. The Structure of the MIB Modules There are three separate MIB modules described in this document, the management target MIB, the notification MIB, and the proxy MIB. The following sections describe the structure of these three MIB modules. The use of these MIBs by particular types of applications is described later in this document: - The use of the management target MIB and the notification MIB in notification originator applications is described in section 5. - The use of the notification MIB for filtering notifications in notification originator applications is described in section 6. - The use of the management target MIB and the proxy MIB in proxy forwarding applications is described in section 7. 4.1. The Management Target MIB Module The SNMP-TARGET-MIB module contains objects for defining management targets. It consists of two tables and conformance/compliance statements. The first table, the snmpTargetAddrTable, contains information about transport domains and addresses. It also contains an object, snmpTargetAddrTagList, which provides a mechanism for grouping entries. The second table, the snmpTargetParamsTable, contains information about SNMP version and security information to be used when sending messages to particular transport domains and addresses. The Management Target MIB is intended to provide a general-purpose mechanism for specifying transport address, and for specifying parameters of SNMP messages generated by an SNMP entity. It is used within this document for generation of notifications and for proxy forwarding. However, it may be used for other purposes. If another document makes use of this MIB, that document is responsible for specifying how it is used. For example, [RFC2576] uses this MIB for source address validation of SNMPv1 messages. 4.1.1. Tag Lists The snmpTargetAddrTagList object is used for grouping entries in the snmpTargetAddrTable. The value of this object contains a list of tag values which are used to select target addresses to be used for a particular operation. Levi, et. al. Standards Track [Page 29] RFC 3413 SNMP Applications December 2002 A tag value, which may also be used in MIB objects other than snmpTargetAddrTagList, is an arbitrary string of octets, but may not contain a delimiter character. Delimiter characters are defined to be one of the following characters: - An ASCII space character (0x20). - An ASCII TAB character (0x09). - An ASCII carriage return (CR) character (0x0D). - An ASCII line feed (LF) character (0x0A). In addition, a tag value within a tag list may not have a zero length. Generally, a particular MIB object may contain either - a zero-length octet string representing an empty list, or - a single tag value, in which case the value of the MIB object may not contain a delimiter character, or - a list of tag values, separated by single delimiter characters. For a list of tag values, these constraints imply certain restrictions on the value of a MIB object: - There cannot be a leading or trailing delimiter character. - There cannot be multiple adjacent delimiter characters. 4.1.2. Definitions SNMP-TARGET-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, snmpModules, Counter32, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TDomain, TAddress, TimeInterval, RowStatus, StorageType, Levi, et. al. Standards Track [Page 30] RFC 3413 SNMP Applications December 2002 TestAndIncr FROM SNMPv2-TC SnmpSecurityModel, SnmpMessageProcessingModel, SnmpSecurityLevel, SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpTargetMIB MODULE-IDENTITY LAST-UPDATED "200210140000Z" ORGANIZATION "IETF SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In message body: subscribe snmpv3 Co-Chair: Russ Mundy Network Associates Laboratories Postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA EMail: mundy@tislabs.com Phone: +1 301-947-7107 Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5004 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614 Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, Tennessee 37918 EMail: dlevi@nortelnetworks.com Phone: +1 865 686 0432 Co-editor: Paul Meyer Secure Computing Corporation Postal: 2675 Long Lake Road Levi, et. al. Standards Track [Page 31] RFC 3413 SNMP Applications December 2002 Roseville, Minnesota 55113 EMail: paul_meyer@securecomputing.com Phone: +1 651 628 1592 Co-editor: Bob Stewart Retired" DESCRIPTION "This MIB module defines MIB objects which provide mechanisms to remotely configure the parameters used by an SNMP entity for the generation of SNMP messages. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3413; see the RFC itself for full legal notices. " REVISION "200210140000Z" -- 14 October 2002 DESCRIPTION "Fixed DISPLAY-HINTS for UTF-8 strings, fixed hex value of LF characters, clarified meaning of zero length tag values, improved tag list examples. Published as RFC 3413." REVISION "199808040000Z" -- 4 August 1998 DESCRIPTION "Clarifications, published as RFC 2573." REVISION "199707140000Z" -- 14 July 1997 DESCRIPTION "The initial revision, published as RFC2273." ::= { snmpModules 12 } snmpTargetObjects OBJECT IDENTIFIER ::= { snmpTargetMIB 1 } snmpTargetConformance OBJECT IDENTIFIER ::= { snmpTargetMIB 3 } SnmpTagValue ::= TEXTUAL-CONVENTION DISPLAY-HINT "255t" STATUS current DESCRIPTION "An octet string containing a tag value. Tag values are preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2279. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. The use of control codes should be avoided, and certain Levi, et. al. Standards Track [Page 32] RFC 3413 SNMP Applications December 2002 control codes are not allowed as described below. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 representation is identical to the US-ASCII encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction must be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC1905]. An object of this type contains a single tag value which is used to select a set of entries in a table. A tag value is an arbitrary string of octets, but may not contain a delimiter character. Delimiter characters are defined to be one of the following: - An ASCII space character (0x20). - An ASCII TAB character (0x09). - An ASCII carriage return (CR) character (0x0D). - An ASCII line feed (LF) character (0x0A). Delimiter characters are used to separate tag values in a tag list. An object of this type may only contain a single tag value, and so delimiter characters are not allowed in a value of this type. Note that a tag value of 0 length means that no tag is defined. In other words, a tag value of 0 length would never match anything in a tag list, and would never select any table entries. Some examples of valid tag values are: - 'acme' - 'router' - 'host' Levi, et. al. Standards Track [Page 33] RFC 3413 SNMP Applications December 2002 The use of a tag value to select table entries is application and MIB specific." SYNTAX OCTET STRING (SIZE (0..255)) SnmpTagList ::= TEXTUAL-CONVENTION DISPLAY-HINT "255t" STATUS current DESCRIPTION "An octet string containing a list of tag values. Tag values are preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2279. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. The use of control codes should be avoided, except as described below. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 representation is identical to the US-ASCII encoding. An object of this type contains a list of tag values which are used to select a set of entries in a table. A tag value is an arbitrary string of octets, but may not contain a delimiter character. Delimiter characters are defined to be one of the following: - An ASCII space character (0x20). - An ASCII TAB character (0x09). - An ASCII carriage return (CR) character (0x0D). - An ASCII line feed (LF) character (0x0A). Delimiter characters are used to separate tag values Levi, et. al. Standards Track [Page 34] RFC 3413 SNMP Applications December 2002 in a tag list. Only a single delimiter character may occur between two tag values. A tag value may not have a zero length. These constraints imply certain restrictions on the contents of this object: - There cannot be a leading or trailing delimiter character. - There cannot be multiple adjacent delimiter characters. Some examples of valid tag lists are: - '' -- an empty list - 'acme' -- list of one tag - 'host router bridge' -- list of several tags Note that although a tag value may not have a length of zero, an empty string is still valid. This indicates an empty list (i.e. there are no tag values in the list). The use of the tag list to select table entries is application and MIB specific. Typically, an application will provide one or more tag values, and any entry which contains some combination of these tag values will be selected." SYNTAX OCTET STRING (SIZE (0..255)) -- -- -- The snmpTargetObjects group -- -- snmpTargetSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to facilitate modification of table entries in the SNMP-TARGET-MIB module by multiple managers. In particular, it is useful when modifying the value of the snmpTargetAddrTagList object. The procedure for modifying the snmpTargetAddrTagList object is as follows: Levi, et. al. Standards Track [Page 35] RFC 3413 SNMP Applications December 2002 1. Retrieve the value of snmpTargetSpinLock and of snmpTargetAddrTagList. 2. Generate a new value for snmpTargetAddrTagList. 3. Set the value of snmpTargetSpinLock to the retrieved value, and the value of snmpTargetAddrTagList to the new value. If the set fails for the snmpTargetSpinLock object, go back to step 1." ::= { snmpTargetObjects 1 } snmpTargetAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of transport addresses to be used in the generation of SNMP messages." ::= { snmpTargetObjects 2 } snmpTargetAddrEntry OBJECT-TYPE SYNTAX SnmpTargetAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A transport address to be used in the generation of SNMP operations. Entries in the snmpTargetAddrTable are created and deleted using the snmpTargetAddrRowStatus object." INDEX { IMPLIED snmpTargetAddrName } ::= { snmpTargetAddrTable 1 } SnmpTargetAddrEntry ::= SEQUENCE { snmpTargetAddrName SnmpAdminString, snmpTargetAddrTDomain TDomain, snmpTargetAddrTAddress TAddress, snmpTargetAddrTimeout TimeInterval, snmpTargetAddrRetryCount Integer32, snmpTargetAddrTagList SnmpTagList, snmpTargetAddrParams SnmpAdminString, snmpTargetAddrStorageType StorageType, snmpTargetAddrRowStatus RowStatus } snmpTargetAddrName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) Levi, et. al. Standards Track [Page 36] RFC 3413 SNMP Applications December 2002 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this snmpTargetAddrEntry." ::= { snmpTargetAddrEntry 1 } snmpTargetAddrTDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the transport type of the address contained in the snmpTargetAddrTAddress object." ::= { snmpTargetAddrEntry 2 } snmpTargetAddrTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains a transport address. The format of this address depends on the value of the snmpTargetAddrTDomain object." ::= { snmpTargetAddrEntry 3 } snmpTargetAddrTimeout OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object should reflect the expected maximum round trip time for communicating with the transport address defined by this row. When a message is sent to this address, and a response (if one is expected) is not received within this time period, an implementation may assume that the response will not be delivered. Note that the time interval that an application waits for a response may actually be derived from the value of this object. The method for deriving the actual time interval is implementation dependent. One such method is to derive the expected round trip time based on a particular retransmission algorithm and on the number of timeouts which have occurred. The type of message may also be considered when deriving expected round trip times for retransmissions. For example, if a message is being sent with a securityLevel that indicates both Levi, et. al. Standards Track [Page 37] RFC 3413 SNMP Applications December 2002 authentication and privacy, the derived value may be increased to compensate for extra processing time spent during authentication and encryption processing." DEFVAL { 1500 } ::= { snmpTargetAddrEntry 4 } snmpTargetAddrRetryCount OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a default number of retries to be attempted when a response is not received for a generated message. An application may provide its own retry count, in which case the value of this object is ignored." DEFVAL { 3 } ::= { snmpTargetAddrEntry 5 } snmpTargetAddrTagList OBJECT-TYPE SYNTAX SnmpTagList MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains a list of tag values which are used to select target addresses for a particular operation." DEFVAL { "" } ::= { snmpTargetAddrEntry 6 } snmpTargetAddrParams OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies an entry in the snmpTargetParamsTable. The identified entry contains SNMP parameters to be used when generating messages to be sent to this transport address." ::= { snmpTargetAddrEntry 7 } snmpTargetAddrStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." Levi, et. al. Standards Track [Page 38] RFC 3413 SNMP Applications December 2002 DEFVAL { nonVolatile } ::= { snmpTargetAddrEntry 8 } snmpTargetAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the snmpTargetAddrRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding instances of snmpTargetAddrTDomain, snmpTargetAddrTAddress, and snmpTargetAddrParams have all been set. The following objects may not be modified while the value of this object is active(1): - snmpTargetAddrTDomain - snmpTargetAddrTAddress An attempt to set these objects while the value of snmpTargetAddrRowStatus is active(1) will result in an inconsistentValue error." ::= { snmpTargetAddrEntry 9 } snmpTargetParamsTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetParamsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of SNMP target information to be used in the generation of SNMP messages." ::= { snmpTargetObjects 3 } snmpTargetParamsEntry OBJECT-TYPE SYNTAX SnmpTargetParamsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of SNMP target information. Levi, et. al. Standards Track [Page 39] RFC 3413 SNMP Applications December 2002 Entries in the snmpTargetParamsTable are created and deleted using the snmpTargetParamsRowStatus object." INDEX { IMPLIED snmpTargetParamsName } ::= { snmpTargetParamsTable 1 } SnmpTargetParamsEntry ::= SEQUENCE { snmpTargetParamsName SnmpAdminString, snmpTargetParamsMPModel SnmpMessageProcessingModel, snmpTargetParamsSecurityModel SnmpSecurityModel, snmpTargetParamsSecurityName SnmpAdminString, snmpTargetParamsSecurityLevel SnmpSecurityLevel, snmpTargetParamsStorageType StorageType, snmpTargetParamsRowStatus RowStatus } snmpTargetParamsName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this snmpTargetParamsEntry." ::= { snmpTargetParamsEntry 1 } snmpTargetParamsMPModel OBJECT-TYPE SYNTAX SnmpMessageProcessingModel MAX-ACCESS read-create STATUS current DESCRIPTION "The Message Processing Model to be used when generating SNMP messages using this entry." ::= { snmpTargetParamsEntry 2 } snmpTargetParamsSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The Security Model to be used when generating SNMP messages using this entry. An implementation may choose to return an inconsistentValue error if an attempt is made to set this variable to a value for a security model which the implementation does not support." ::= { snmpTargetParamsEntry 3 } snmpTargetParamsSecurityName OBJECT-TYPE SYNTAX SnmpAdminString Levi, et. al. Standards Track [Page 40] RFC 3413 SNMP Applications December 2002 MAX-ACCESS read-create STATUS current DESCRIPTION "The securityName which identifies the Principal on whose behalf SNMP messages will be generated using this entry." ::= { snmpTargetParamsEntry 4 } snmpTargetParamsSecurityLevel OBJECT-TYPE SYNTAX SnmpSecurityLevel MAX-ACCESS read-create STATUS current DESCRIPTION "The Level of Security to be used when generating SNMP messages using this entry." ::= { snmpTargetParamsEntry 5 } snmpTargetParamsStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { snmpTargetParamsEntry 6 } snmpTargetParamsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the snmpTargetParamsRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, Levi, et. al. Standards Track [Page 41] RFC 3413 SNMP Applications December 2002 snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel have all been set. The following objects may not be modified while the value of this object is active(1): - snmpTargetParamsMPModel - snmpTargetParamsSecurityModel - snmpTargetParamsSecurityName - snmpTargetParamsSecurityLevel An attempt to set these objects while the value of snmpTargetParamsRowStatus is active(1) will result in an inconsistentValue error." ::= { snmpTargetParamsEntry 7 } snmpUnavailableContexts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because the context contained in the message was unavailable." ::= { snmpTargetObjects 4 } snmpUnknownContexts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because the context contained in the message was unknown." ::= { snmpTargetObjects 5 } -- -- -- Conformance information -- -- snmpTargetCompliances OBJECT IDENTIFIER ::= { snmpTargetConformance 1 } snmpTargetGroups OBJECT IDENTIFIER ::= { snmpTargetConformance 2 } -- -- -- Compliance statements Levi, et. al. Standards Track [Page 42] RFC 3413 SNMP Applications December 2002 -- -- snmpTargetCommandResponderCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which include a command responder application." MODULE -- This Module MANDATORY-GROUPS { snmpTargetCommandResponderGroup } ::= { snmpTargetCompliances 1 } snmpTargetBasicGroup OBJECT-GROUP OBJECTS { snmpTargetSpinLock, snmpTargetAddrTDomain, snmpTargetAddrTAddress, snmpTargetAddrTagList, snmpTargetAddrParams, snmpTargetAddrStorageType, snmpTargetAddrRowStatus, snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, snmpTargetParamsSecurityLevel, snmpTargetParamsStorageType, snmpTargetParamsRowStatus } STATUS current DESCRIPTION "A collection of objects providing basic remote configuration of management targets." ::= { snmpTargetGroups 1 } snmpTargetResponseGroup OBJECT-GROUP OBJECTS { snmpTargetAddrTimeout, snmpTargetAddrRetryCount } STATUS current DESCRIPTION "A collection of objects providing remote configuration of management targets for applications which generate SNMP messages for which a response message would be expected." ::= { snmpTargetGroups 2 } snmpTargetCommandResponderGroup OBJECT-GROUP Levi, et. al. Standards Track [Page 43] RFC 3413 SNMP Applications December 2002 OBJECTS { snmpUnavailableContexts, snmpUnknownContexts } STATUS current DESCRIPTION "A collection of objects required for command responder applications, used for counting error conditions." ::= { snmpTargetGroups 3 } END 4.2. The Notification MIB Module The SNMP-NOTIFICATION-MIB module contains objects for the remote configuration of the parameters used by an SNMP entity for the generation of notifications. It consists of three tables and conformance/compliance statements. The first table, the snmpNotifyTable, contains entries which select which entries in the snmpTargetAddrTable should be used for generating notifications, and the type of notifications to be generated. The second table, the snmpNotifyFilterProfileTable, sparsely augments the snmpTargetParamsTable with an object which is used to associate a set of filters with a particular management target. The third table, the snmpNotifyFilterTable, defines filters which are used to limit the number of notifications which are generated using particular management targets. 4.2.1. Definitions SNMP-NOTIFICATION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB SnmpTagValue, Levi, et. al. Standards Track [Page 44] RFC 3413 SNMP Applications December 2002 snmpTargetParamsName FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpNotificationMIB MODULE-IDENTITY LAST-UPDATED "200210140000Z" ORGANIZATION "IETF SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In message body: subscribe snmpv3 Co-Chair: Russ Mundy Network Associates Laboratories Postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA EMail: mundy@tislabs.com Phone: +1 301-947-7107 Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5004 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614 Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, Tennessee 37918 EMail: dlevi@nortelnetworks.com Phone: +1 865 686 0432 Co-editor: Paul Meyer Secure Computing Corporation Postal: 2675 Long Lake Road Roseville, Minnesota 55113 EMail: paul_meyer@securecomputing.com Phone: +1 651 628 1592 Co-editor: Bob Stewart Retired" Levi, et. al. Standards Track [Page 45] RFC 3413 SNMP Applications December 2002 DESCRIPTION "This MIB module defines MIB objects which provide mechanisms to remotely configure the parameters used by an SNMP entity for the generation of notifications. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3413; see the RFC itself for full legal notices. " REVISION "200210140000Z" -- 14 October 2002 DESCRIPTION "Clarifications, published as RFC 3413." REVISION "199808040000Z" -- 4 August 1998 DESCRIPTION "Clarifications, published as RFC 2573." REVISION "199707140000Z" -- 14 July 1997 DESCRIPTION "The initial revision, published as RFC2273." ::= { snmpModules 13 } snmpNotifyObjects OBJECT IDENTIFIER ::= { snmpNotificationMIB 1 } snmpNotifyConformance OBJECT IDENTIFIER ::= { snmpNotificationMIB 3 } -- -- -- The snmpNotifyObjects group -- -- snmpNotifyTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNotifyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to select management targets which should receive notifications, as well as the type of notification which should be sent to each selected management target." ::= { snmpNotifyObjects 1 } snmpNotifyEntry OBJECT-TYPE SYNTAX SnmpNotifyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table selects a set of management targets which should receive notifications, as well as the type of Levi, et. al. Standards Track [Page 46] RFC 3413 SNMP Applications December 2002 notification which should be sent to each selected management target. Entries in the snmpNotifyTable are created and deleted using the snmpNotifyRowStatus object." INDEX { IMPLIED snmpNotifyName } ::= { snmpNotifyTable 1 } SnmpNotifyEntry ::= SEQUENCE { snmpNotifyName SnmpAdminString, snmpNotifyTag SnmpTagValue, snmpNotifyType INTEGER, snmpNotifyStorageType StorageType, snmpNotifyRowStatus RowStatus } snmpNotifyName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this snmpNotifyEntry." ::= { snmpNotifyEntry 1 } snmpNotifyTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains a single tag value which is used to select entries in the snmpTargetAddrTable. Any entry in the snmpTargetAddrTable which contains a tag value which is equal to the value of an instance of this object is selected. If this object contains a value of zero length, no entries are selected." DEFVAL { "" } ::= { snmpNotifyEntry 2 } snmpNotifyType OBJECT-TYPE SYNTAX INTEGER { trap(1), inform(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object determines the type of notification to Levi, et. al. Standards Track [Page 47] RFC 3413 SNMP Applications December 2002 be generated for entries in the snmpTargetAddrTable selected by the corresponding instance of snmpNotifyTag. This value is only used when generating notifications, and is ignored when using the snmpTargetAddrTable for other purposes. If the value of this object is trap(1), then any messages generated for selected rows will contain Unconfirmed-Class PDUs. If the value of this object is inform(2), then any messages generated for selected rows will contain Confirmed-Class PDUs. Note that if an SNMP entity only supports generation of Unconfirmed-Class PDUs (and not Confirmed-Class PDUs), then this object may be read-only." DEFVAL { trap } ::= { snmpNotifyEntry 3 } snmpNotifyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { snmpNotifyEntry 4 } snmpNotifyRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5)." ::= { snmpNotifyEntry 5 } snmpNotifyFilterProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNotifyFilterProfileEntry MAX-ACCESS not-accessible STATUS current Levi, et. al. Standards Track [Page 48] RFC 3413 SNMP Applications December 2002 DESCRIPTION "This table is used to associate a notification filter profile with a particular set of target parameters." ::= { snmpNotifyObjects 2 } snmpNotifyFilterProfileEntry OBJECT-TYPE SYNTAX SnmpNotifyFilterProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table indicates the name of the filter profile to be used when generating notifications using the corresponding entry in the snmpTargetParamsTable. Entries in the snmpNotifyFilterProfileTable are created and deleted using the snmpNotifyFilterProfileRowStatus object." INDEX { IMPLIED snmpTargetParamsName } ::= { snmpNotifyFilterProfileTable 1 } SnmpNotifyFilterProfileEntry ::= SEQUENCE { snmpNotifyFilterProfileName SnmpAdminString, snmpNotifyFilterProfileStorType StorageType, snmpNotifyFilterProfileRowStatus RowStatus } snmpNotifyFilterProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the filter profile to be used when generating notifications using the corresponding entry in the snmpTargetAddrTable." ::= { snmpNotifyFilterProfileEntry 1 } snmpNotifyFilterProfileStorType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { snmpNotifyFilterProfileEntry 2 } snmpNotifyFilterProfileRowStatus OBJECT-TYPE Levi, et. al. Standards Track [Page 49] RFC 3413 SNMP Applications December 2002 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the snmpNotifyFilterProfileRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding instance of snmpNotifyFilterProfileName has been set." ::= { snmpNotifyFilterProfileEntry 3 } snmpNotifyFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNotifyFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of filter profiles. Filter profiles are used to determine whether particular management targets should receive particular notifications. When a notification is generated, it must be compared with the filters associated with each management target which is configured to receive notifications, in order to determine whether it may be sent to each such management target. A more complete discussion of notification filtering can be found in section 6. of [SNMP-APPL]." ::= { snmpNotifyObjects 3 } snmpNotifyFilterEntry OBJECT-TYPE SYNTAX SnmpNotifyFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An element of a filter profile. Entries in the snmpNotifyFilterTable are created and deleted using the snmpNotifyFilterRowStatus object." Levi, et. al. Standards Track [Page 50] RFC 3413 SNMP Applications December 2002 INDEX { snmpNotifyFilterProfileName, IMPLIED snmpNotifyFilterSubtree } ::= { snmpNotifyFilterTable 1 } SnmpNotifyFilterEntry ::= SEQUENCE { snmpNotifyFilterSubtree OBJECT IDENTIFIER, snmpNotifyFilterMask OCTET STRING, snmpNotifyFilterType INTEGER, snmpNotifyFilterStorageType StorageType, snmpNotifyFilterRowStatus RowStatus } snmpNotifyFilterSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MIB subtree which, when combined with the corresponding instance of snmpNotifyFilterMask, defines a family of subtrees which are included in or excluded from the filter profile." ::= { snmpNotifyFilterEntry 1 } snmpNotifyFilterMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The bit mask which, in combination with the corresponding instance of snmpNotifyFilterSubtree, defines a family of subtrees which are included in or excluded from the filter profile. Each bit of this bit mask corresponds to a sub-identifier of snmpNotifyFilterSubtree, with the most significant bit of the i-th octet of this octet string value (extended if necessary, see below) corresponding to the (8*i - 7)-th sub-identifier, and the least significant bit of the i-th octet of this octet string corresponding to the (8*i)-th sub-identifier, where i is in the range 1 through 16. Each bit of this bit mask specifies whether or not the corresponding sub-identifiers must match when determining if an OBJECT IDENTIFIER matches this family of filter subtrees; a '1' indicates that an exact match must occur; a '0' indicates 'wild card', i.e., any sub-identifier value matches. Levi, et. al. Standards Track [Page 51] RFC 3413 SNMP Applications December 2002 Thus, the OBJECT IDENTIFIER X of an object instance is contained in a family of filter subtrees if, for each sub-identifier of the value of snmpNotifyFilterSubtree, either: the i-th bit of snmpNotifyFilterMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of snmpNotifyFilterSubtree. If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of snmpNotifyFilterSubtree, then the bit mask is extended with 1's to be the required length. Note that when the value of this object is the zero-length string, this extension rule results in a mask of all-1's being used (i.e., no 'wild card'), and the family of filter subtrees is the one subtree uniquely identified by the corresponding instance of snmpNotifyFilterSubtree." DEFVAL { ''H } ::= { snmpNotifyFilterEntry 2 } snmpNotifyFilterType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether the family of filter subtrees defined by this entry are included in or excluded from a filter. A more detailed discussion of the use of this object can be found in section 6. of [SNMP-APPL]." DEFVAL { included } ::= { snmpNotifyFilterEntry 3 } snmpNotifyFilterStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not Levi, et. al. Standards Track [Page 52] RFC 3413 SNMP Applications December 2002 allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { snmpNotifyFilterEntry 4 } snmpNotifyFilterRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. To create a row in this table, a manager must set this object to either createAndGo(4) or createAndWait(5)." ::= { snmpNotifyFilterEntry 5 } -- -- -- Conformance information -- -- snmpNotifyCompliances OBJECT IDENTIFIER ::= { snmpNotifyConformance 1 } snmpNotifyGroups OBJECT IDENTIFIER ::= { snmpNotifyConformance 2 } -- -- -- Compliance statements -- -- snmpNotifyBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for minimal SNMP entities which implement only SNMP Unconfirmed-Class notifications and read-create operations on only the snmpTargetAddrTable." MODULE SNMP-TARGET-MIB MANDATORY-GROUPS { snmpTargetBasicGroup } OBJECT snmpTargetParamsMPModel MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required." OBJECT snmpTargetParamsSecurityModel Levi, et. al. Standards Track [Page 53] RFC 3413 SNMP Applications December 2002 MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required." OBJECT snmpTargetParamsSecurityName MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required." OBJECT snmpTargetParamsSecurityLevel MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required." OBJECT snmpTargetParamsStorageType SYNTAX INTEGER { readOnly(5) } MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required. Support of the values other(1), volatile(2), nonVolatile(3), and permanent(4) is not required." OBJECT snmpTargetParamsRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access to the snmpTargetParamsTable is not required. Support of the values notInService(2), notReady(3), createAndGo(4), createAndWait(5), and destroy(6) is not required." MODULE -- This Module MANDATORY-GROUPS { snmpNotifyGroup } OBJECT snmpNotifyTag MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required." OBJECT snmpNotifyType SYNTAX INTEGER { trap(1) } Levi, et. al. Standards Track [Page 54] RFC 3413 SNMP Applications December 2002 MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required. Support of the value notify(2) is not required." OBJECT snmpNotifyStorageType SYNTAX INTEGER { readOnly(5) } MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access is not required. Support of the values other(1), volatile(2), nonVolatile(3), and permanent(4) is not required." OBJECT snmpNotifyRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access to the snmpNotifyTable is not required. Support of the values notInService(2), notReady(3), createAndGo(4), createAndWait(5), and destroy(6) is not required." ::= { snmpNotifyCompliances 1 } snmpNotifyBasicFiltersCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement SNMP Unconfirmed-Class notifications with filtering, and read-create operations on all related tables." MODULE SNMP-TARGET-MIB MANDATORY-GROUPS { snmpTargetBasicGroup } MODULE -- This Module MANDATORY-GROUPS { snmpNotifyGroup, snmpNotifyFilterGroup } ::= { snmpNotifyCompliances 2 } snmpNotifyFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which either implement only SNMP Confirmed-Class notifications, or both SNMP Unconfirmed-Class and Confirmed-Class notifications, Levi, et. al. Standards Track [Page 55] RFC 3413 SNMP Applications December 2002 plus filtering and read-create operations on all related tables." MODULE SNMP-TARGET-MIB MANDATORY-GROUPS { snmpTargetBasicGroup, snmpTargetResponseGroup } MODULE -- This Module MANDATORY-GROUPS { snmpNotifyGroup, snmpNotifyFilterGroup } ::= { snmpNotifyCompliances 3 } snmpNotifyGroup OBJECT-GROUP OBJECTS { snmpNotifyTag, snmpNotifyType, snmpNotifyStorageType, snmpNotifyRowStatus } STATUS current DESCRIPTION "A collection of objects for selecting which management targets are used for generating notifications, and the type of notification to be generated for each selected management target." ::= { snmpNotifyGroups 1 } snmpNotifyFilterGroup OBJECT-GROUP OBJECTS { snmpNotifyFilterProfileName, snmpNotifyFilterProfileStorType, snmpNotifyFilterProfileRowStatus, snmpNotifyFilterMask, snmpNotifyFilterType, snmpNotifyFilterStorageType, snmpNotifyFilterRowStatus } STATUS current DESCRIPTION "A collection of objects providing remote configuration of notification filters." ::= { snmpNotifyGroups 2 } END Levi, et. al. Standards Track [Page 56] RFC 3413 SNMP Applications December 2002 4.3. The Proxy MIB Module The SNMP-PROXY-MIB module, which defines MIB objects that provide mechanisms to remotely configure the parameters used by an SNMP entity for proxy forwarding operations, contains a single table. This table, snmpProxyTable, is used to define translations between management targets for use when forwarding messages. 4.3.1. Definitions SNMP-PROXY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC SnmpEngineID, SnmpAdminString FROM SNMP-FRAMEWORK-MIB SnmpTagValue FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpProxyMIB MODULE-IDENTITY LAST-UPDATED "200210140000Z" ORGANIZATION "IETF SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In message body: subscribe snmpv3 Co-Chair: Russ Mundy Network Associates Laboratories Postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA EMail: mundy@tislabs.com Phone: +1 301-947-7107 Levi, et. al. Standards Track [Page 57] RFC 3413 SNMP Applications December 2002 Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5004 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614 Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, Tennessee 37918 EMail: dlevi@nortelnetworks.com Phone: +1 865 686 0432 Co-editor: Paul Meyer Secure Computing Corporation Postal: 2675 Long Lake Road Roseville, Minnesota 55113 EMail: paul_meyer@securecomputing.com Phone: +1 651 628 1592 Co-editor: Bob Stewart Retired" DESCRIPTION "This MIB module defines MIB objects which provide mechanisms to remotely configure the parameters used by a proxy forwarding application. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3413; see the RFC itself for full legal notices. " REVISION "200210140000Z" -- 14 October 2002 DESCRIPTION "Clarifications, published as RFC 3413." REVISION "199808040000Z" -- 4 August 1998 DESCRIPTION "Clarifications, published as RFC 2573." REVISION "199707140000Z" -- 14 July 1997 DESCRIPTION "The initial revision, published as RFC2273." ::= { snmpModules 14 } snmpProxyObjects OBJECT IDENTIFIER ::= { snmpProxyMIB 1 } snmpProxyConformance OBJECT IDENTIFIER ::= { snmpProxyMIB 3 } -- Levi, et. al. Standards Track [Page 58] RFC 3413 SNMP Applications December 2002 -- -- The snmpProxyObjects group -- -- snmpProxyTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpProxyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of translation parameters used by proxy forwarder applications for forwarding SNMP messages." ::= { snmpProxyObjects 2 } snmpProxyEntry OBJECT-TYPE SYNTAX SnmpProxyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of translation parameters used by a proxy forwarder application for forwarding SNMP messages. Entries in the snmpProxyTable are created and deleted using the snmpProxyRowStatus object." INDEX { IMPLIED snmpProxyName } ::= { snmpProxyTable 1 } SnmpProxyEntry ::= SEQUENCE { snmpProxyName SnmpAdminString, snmpProxyType INTEGER, snmpProxyContextEngineID SnmpEngineID, snmpProxyContextName SnmpAdminString, snmpProxyTargetParamsIn SnmpAdminString, snmpProxySingleTargetOut SnmpAdminString, snmpProxyMultipleTargetOut SnmpTagValue, snmpProxyStorageType StorageType, snmpProxyRowStatus RowStatus } snmpProxyName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this snmpProxyEntry." ::= { snmpProxyEntry 1 } Levi, et. al. Standards Track [Page 59] RFC 3413 SNMP Applications December 2002 snmpProxyType OBJECT-TYPE SYNTAX INTEGER { read(1), write(2), trap(3), inform(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of message that may be forwarded using the translation parameters defined by this entry." ::= { snmpProxyEntry 2 } snmpProxyContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-create STATUS current DESCRIPTION "The contextEngineID contained in messages that may be forwarded using the translation parameters defined by this entry." ::= { snmpProxyEntry 3 } snmpProxyContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The contextName contained in messages that may be forwarded using the translation parameters defined by this entry. This object is optional, and if not supported, the contextName contained in a message is ignored when selecting an entry in the snmpProxyTable." ::= { snmpProxyEntry 4 } snmpProxyTargetParamsIn OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This object selects an entry in the snmpTargetParamsTable. The selected entry is used to determine which row of the snmpProxyTable to use for forwarding received messages." ::= { snmpProxyEntry 5 } Levi, et. al. Standards Track [Page 60] RFC 3413 SNMP Applications December 2002 snmpProxySingleTargetOut OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This object selects a management target defined in the snmpTargetAddrTable (in the SNMP-TARGET-MIB). The selected target is defined by an entry in the snmpTargetAddrTable whose index value (snmpTargetAddrName) is equal to this object. This object is only used when selection of a single target is required (i.e. when forwarding an incoming read or write request)." ::= { snmpProxyEntry 6 } snmpProxyMultipleTargetOut OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object selects a set of management targets defined in the snmpTargetAddrTable (in the SNMP-TARGET-MIB). This object is only used when selection of multiple targets is required (i.e. when forwarding an incoming notification)." ::= { snmpProxyEntry 7 } snmpProxyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { snmpProxyEntry 8 } snmpProxyRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. To create a row in this table, a manager must Levi, et. al. Standards Track [Page 61] RFC 3413 SNMP Applications December 2002 set this object to either createAndGo(4) or createAndWait(5). The following objects may not be modified while the value of this object is active(1): - snmpProxyType - snmpProxyContextEngineID - snmpProxyContextName - snmpProxyTargetParamsIn - snmpProxySingleTargetOut - snmpProxyMultipleTargetOut" ::= { snmpProxyEntry 9 } -- -- -- Conformance information -- -- snmpProxyCompliances OBJECT IDENTIFIER ::= { snmpProxyConformance 1 } snmpProxyGroups OBJECT IDENTIFIER ::= { snmpProxyConformance 2 } -- -- -- Compliance statements -- -- snmpProxyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which include a proxy forwarding application." MODULE SNMP-TARGET-MIB MANDATORY-GROUPS { snmpTargetBasicGroup, snmpTargetResponseGroup } MODULE -- This Module MANDATORY-GROUPS { snmpProxyGroup } ::= { snmpProxyCompliances 1 } snmpProxyGroup OBJECT-GROUP OBJECTS { snmpProxyType, snmpProxyContextEngineID, snmpProxyContextName, snmpProxyTargetParamsIn, Levi, et. al. Standards Track [Page 62] RFC 3413 SNMP Applications December 2002 snmpProxySingleTargetOut, snmpProxyMultipleTargetOut, snmpProxyStorageType, snmpProxyRowStatus } STATUS current DESCRIPTION "A collection of objects providing remote configuration of management target translation parameters for use by proxy forwarder applications." ::= { snmpProxyGroups 3 } END 5. Identification of Management Targets in Notification Originators This section describes the mechanisms used by a notification originator application when using the MIB module described in this document to determine the set of management targets to be used when generating a notification. A notification originator uses all active entries in the snmpNotifyTable to find the management targets to be used for generating notifications. Each active entry in this table selects zero or more entries in the snmpTargetAddrTable. When a notification is generated, it is sent to all of the targets specified by the selected snmpTargetAddrTable entries (subject to the application of access control and notification filtering). Any entry in the snmpTargetAddrTable whose snmpTargetAddrTagList object contains a tag value which is equal to a value of snmpNotifyTag is selected by the snmpNotifyEntry which contains that instance of snmpNotifyTag. Note that a particular snmpTargetAddrEntry may be selected by multiple entries in the snmpNotifyTable, resulting in multiple notifications being generated using that snmpTargetAddrEntry (this allows, for example, both traps and informs to be sent to the same target). Each snmpTargetAddrEntry contains a pointer to the snmpTargetParamsTable (snmpTargetAddrParams). This pointer selects a set of SNMP parameters to be used for generating notifications. If the selected entry in the snmpTargetParamsTable does not exist, the management target is not used to generate notifications. The decision as to whether a notification should contain an Unconfirmed-Class or a Confirmed-Class PDU is determined by the value of the snmpNotifyType object. If the value of this object is trap(1), the notification should contain an Unconfirmed-Class PDU. Levi, et. al. Standards Track [Page 63] RFC 3413 SNMP Applications December 2002 If the value of this object is inform(2), then the notification should contain a Confirmed-Class PDU, and the timeout time and number of retries for the notification are the value of snmpTargetAddrTimeout and snmpTargetAddrRetryCount. Note that the exception to these rules is when the snmpTargetParamsMPModel object indicates an SNMP version which supports a different PDU version. In this case, the notification may be sent using a different PDU type ([RFC2576] defines the PDU type in the case where the outgoing SNMP version is SNMPv1). 6. Notification Filtering This section describes the mechanisms used by a notification originator application when using the MIB module described in this document to filter generation of notifications. A notification originator uses the snmpNotifyFilterTable to filter notifications. A notification filter profile may be associated with a particular entry in the snmpTargetParamsTable. The associated filter profile is identified by an entry in the snmpNotifyFilterProfileTable whose index is equal to the index of the entry in the snmpTargetParamsTable. If no such entry exists in the snmpNotifyFilterProfileTable, no filtering is performed for that management target. If such an entry does exist, the value of snmpNotifyFilterProfileName of the entry is compared with the corresponding portion of the index of all active entries in the snmpNotifyFilterTable. All such entries for which this comparison results in an exact match are used for filtering a notification generated using the associated snmpTargetParamsEntry. If no such entries exist, no filtering is performed, and a notification may be sent to the management target. Otherwise, if matching entries do exist, a notification may be sent if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this is the value of the element of the variable bindings whose name is snmpTrapOID.0, i.e., the second variable binding) is specifically included, and none of the object instances to be included in the variable-bindings of the notification are specifically excluded by the matching entries. Each set of snmpNotifyFilterTable entries is divided into two collections of filter subtrees: the included filter subtrees, and the excluded filter subtrees. The snmpNotifyFilterType object defines the collection to which each matching entry belongs. To determine whether a particular notification name or object instance is excluded by the set of matching entries, compare the Levi, et. al. Standards Track [Page 64] RFC 3413 SNMP Applications December 2002 notification name's or object instance's OBJECT IDENTIFIER with each of the matching entries. For a notification name, if none match, then the notification name is considered excluded, and the notification should not be sent to this management target. For an object instance, if none match, the object instance is considered included, and the notification may be sent to this management target. If one or more match, then the notification name or object instance is included or excluded, according to the value of snmpNotifyFilterType in the entry whose value of snmpNotifyFilterSubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers, then the value of snmpNotifyFilterType, in the entry among those which match, and whose instance is lexicographically the largest, determines the inclusion or exclusion. A notification name or object instance's OBJECT IDENTIFIER X matches an entry in the snmpNotifyFilterTable when the number of sub- identifiers in X is at least as many as in the value of snmpNotifyFilterSubtree for the entry, and each sub-identifier in the value of snmpNotifyFilterSubtree matches its corresponding sub- identifier in X. Two sub-identifiers match either if the corresponding bit of snmpNotifyFilterMask is zero (the 'wild card' value), or if the two sub-identifiers are equal. 7. Management Target Translation in Proxy Forwarder Applications This section describes the mechanisms used by a proxy forwarder application when using the MIB module described in this document to translate incoming management target information into outgoing management target information for the purpose of forwarding messages. There are actually two mechanisms a proxy forwarder may use, one for forwarding request messages, and one for forwarding notification messages. 7.1. Management Target Translation for Request Forwarding When forwarding request messages, the proxy forwarder will select a single entry in the snmpProxyTable. To select this entry, it will perform the following comparisons: - The snmpProxyType must be read(1) if the request is a Read-Class PDU. The snmpProxyType must be write(2) if the request is a Write-Class PDU. - The contextEngineID must equal the snmpProxyContextEngineID object. - If the snmpProxyContextName object is supported, it must equal the contextName. Levi, et. al. Standards Track [Page 65] RFC 3413 SNMP Applications December 2002 - The snmpProxyTargetParamsIn object identifies an entry in the snmpTargetParamsTable. The messageProcessingModel, security model, securityName, and securityLevel must match the values of snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel of the identified entry in the snmpTargetParamsTable. There may be multiple entries in the snmpProxyTable for which these comparisons succeed. The entry whose snmpProxyName has the lexicographically smallest value and for which the comparisons succeed will be selected by the proxy forwarder. The outgoing management target information is identified by the value of the snmpProxySingleTargetOut object of the selected entry. This object identifies an entry in the snmpTargetAddrTable. The identified entry in the snmpTargetAddrTable also contains a reference to the snmpTargetParamsTable (snmpTargetAddrParams). If either the identified entry in the snmpTargetAddrTable does not exist, or the identified entry in the snmpTargetParamsTable does not exist, then this snmpProxyEntry does not identify valid forwarding information, and the proxy forwarder should attempt to identify another row. If there is no entry in the snmpProxyTable for which all of the conditions above may be met, then there is no appropriate forwarding information, and the proxy forwarder should take appropriate actions. Otherwise, The snmpTargetAddrTDomain, snmpTargetAddrTAddress, snmpTargetAddrTimeout, and snmpTargetRetryCount of the identified snmpTargetAddrEntry, and the snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel of the identified snmpTargetParamsEntry are used as the destination management target. 7.2. Management Target Translation for Notification Forwarding When forwarding notification messages, the proxy forwarder will select multiple entries in the snmpProxyTable. To select these entries, it will perform the following comparisons: - The snmpProxyType must be trap(3) if the notification is an Unconfirmed-Class PDU. The snmpProxyType must be inform(4) if the request is a Confirmed-Class PDU. - The contextEngineID must equal the snmpProxyContextEngineID object. - If the snmpProxyContextName object is supported, it must equal the contextName. Levi, et. al. Standards Track [Page 66] RFC 3413 SNMP Applications December 2002 - The snmpProxyTargetParamsIn object identifies an entry in the snmpTargetParamsTable. The messageProcessingModel, security model, securityName, and securityLevel must match the values of snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel of the identified entry in the snmpTargetParamsTable. All entries for which these conditions are met are selected. The snmpProxyMultipleTargetOut object of each such entry is used to select a set of entries in the snmpTargetAddrTable. Any snmpTargetAddrEntry whose snmpTargetAddrTagList object contains a tag value equal to the value of snmpProxyMultipleTargetOut, and whose snmpTargetAddrParams object references an existing entry in the snmpTargetParamsTable, is selected as a destination for the forwarded notification. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Acknowledgments This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members: Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Levi, et. al. Standards Track [Page 67] RFC 3413 SNMP Applications December 2002 Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Enterasys Networks) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (Nortel Networks) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (Lucent Technologies) The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were: David Harrington (Enterasys Networks) Jeff Johnson (Cisco Systems) David Levi (Nortel Networks) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (Lucent Technologies) Levi, et. al. Standards Track [Page 68] RFC 3413 SNMP Applications December 2002 As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Enterasys Networks) David Levi (Nortel Networks) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) 10. Security Considerations The SNMP applications described in this document typically have direct access to MIB instrumentation. Thus, it is very important that these applications be strict in their application of access control as described in this document. In addition, there may be some types of notification generator applications which, rather than accessing MIB instrumentation using access control, will obtain MIB information through other means (such as from a command line). The implementors and users of such applications must be responsible for not divulging MIB information that normally would be inaccessible due to access control. Finally, the MIBs described in this document contain potentially sensitive information. A security administrator may wish to limit access to these MIBs. 11. References 11.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Levi, et. al. Standards Track [Page 69] RFC 3413 SNMP Applications December 2002 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. 11.2 Informative References [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, 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, March 1991. [RFC2576] Frye, R.,Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", RFC 2576, February 1999. Levi, et. al. Standards Track [Page 70] RFC 3413 SNMP Applications December 2002 Appendix A - Trap Configuration Example This section describes an example configuration for a Notification Generator application which implements the snmpNotifyBasicCompliance level. The example configuration specifies that the Notification Generator should send notifications to 3 separate managers, using authentication and no privacy for the first 2 managers, and using both authentication and privacy for the third manager. The configuration consists of three rows in the snmpTargetAddrTable, two rows in the snmpTargetTable, and two rows in the snmpNotifyTable. * snmpTargetAddrName = "addr1" snmpTargetAddrTDomain = snmpUDPDomain snmpTargetAddrTAddress = 128.1.2.3/162 snmpTargetAddrTagList = "group1" snmpTargetAddrParams = "AuthNoPriv-joe" snmpTargetAddrStorageType = readOnly(5) snmpTargetAddrRowStatus = active(1) * snmpTargetAddrName = "addr2" snmpTargetAddrTDomain = snmpUDPDomain snmpTargetAddrTAddress = 128.2.4.6/162 snmpTargetAddrTagList = "group1" snmpTargetAddrParams = "AuthNoPriv-joe" snmpTargetAddrStorageType = readOnly(5) snmpTargetAddrRowStatus = active(1) * snmpTargetAddrName = "addr3" snmpTargetAddrTDomain = snmpUDPDomain snmpTargetAddrTAddress = 128.1.5.9/162 snmpTargetAddrTagList = "group2" snmpTargetAddrParams = "AuthPriv-bob" snmpTargetAddrStorageType = readOnly(5) snmpTargetAddrRowStatus = active(1) * snmpTargetParamsName = "AuthNoPriv-joe" snmpTargetParamsMPModel = 3 snmpTargetParamsSecurityModel = 3 (USM) snmpTargetParamsSecurityName = "joe" snmpTargetParamsSecurityLevel = authNoPriv(2) snmpTargetParamsStorageType = readOnly(5) snmpTargetParamsRowStatus = active(1) Levi, et. al. Standards Track [Page 71] RFC 3413 SNMP Applications December 2002 * snmpTargetParamsName = "AuthPriv-bob" snmpTargetParamsMPModel = 3 snmpTargetParamsSecurityModel = 3 (USM) snmpTargetParamsSecurityName = "bob" snmpTargetParamsSecurityLevel = authPriv(3) snmpTargetParamsStorageType = readOnly(5) snmpTargetParamsRowStatus = active(1) * snmpNotifyName = "group1" snmpNotifyTag = "group1" snmpNotifyType = trap(1) snmpNotifyStorageType = readOnly(5) snmpNotifyRowStatus = active(1) * snmpNotifyName = "group2" snmpNotifyTag = "group2" snmpNotifyType = trap(1) snmpNotifyStorageType = readOnly(5) snmpNotifyRowStatus = active(1) These entries define two groups of management targets. The first group contains two management targets: first target second target ------------ ------------- messageProcessingModel SNMPv3 SNMPv3 securityModel 3 (USM) 3 (USM) securityName "joe" "joe" securityLevel authNoPriv(2) authNoPriv(2) transportDomain snmpUDPDomain snmpUDPDomain transportAddress 128.1.2.3/162 128.2.4.6/162 And the second group contains a single management target: messageProcessingModel SNMPv3 securityLevel authPriv(3) securityModel 3 (USM) securityName "bob" transportDomain snmpUDPDomain transportAddress 128.1.5.9/162 Levi, et. al. Standards Track [Page 72] RFC 3413 SNMP Applications December 2002 Editors' Addresses David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A. Phone: +1 865 686 0432 EMail: dlevi@nortelnetworks.com Paul Meyer Secure Computing Corporation 2675 Long Lake Road Roseville, MN 55113 U.S.A. Phone: +1 651 628 1592 EMail: paul_meyer@securecomputing.com Bob Stewart Retired Levi, et. al. Standards Track [Page 73] RFC 3413 SNMP Applications December 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Levi, et. al. Standards Track [Page 74] snmp-mibs-downloader-1.1/mibrfcs/rfc3414.txt0000644000000000000000000057202611402176071015571 0ustar Network Working Group U. Blumenthal Request for Comments: 3414 B. Wijnen STD: 62 Lucent Technologies Obsoletes: 2574 December 2002 Category: Standards Track User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. Table of Contents 1. Introduction.......................................... 4 1.1. Threats............................................... 4 1.2. Goals and Constraints................................. 6 1.3. Security Services..................................... 6 1.4. Module Organization................................... 7 1.4.1. Timeliness Module..................................... 8 1.4.2. Authentication Protocol............................... 8 1.4.3. Privacy Protocol...................................... 8 1.5. Protection against Message Replay, Delay and Redirection....................................... 9 1.5.1. Authoritative SNMP engine............................. 9 1.5.2. Mechanisms............................................ 9 1.6. Abstract Service Interfaces........................... 11 Blumenthal & Wijnen Standards Track [Page 1] RFC 3414 USM for SNMPv3 December 2002 1.6.1. User-based Security Model Primitives for Authentication.................................... 11 1.6.2. User-based Security Model Primitives for Privacy........................................... 12 2. Elements of the Model................................. 12 2.1. User-based Security Model Users....................... 12 2.2. Replay Protection..................................... 13 2.2.1. msgAuthoritativeEngineID.............................. 14 2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime............................ 14 2.2.3. Time Window........................................... 15 2.3. Time Synchronization.................................. 15 2.4. SNMP Messages Using this Security Model............... 16 2.5. Services provided by the User-based Security Model.... 17 2.5.1. Services for Generating an Outgoing SNMP Message...... 17 2.5.2. Services for Processing an Incoming SNMP Message...... 20 2.6. Key Localization Algorithm............................ 22 3. Elements of Procedure................................. 22 3.1. Generating an Outgoing SNMP Message................... 22 3.2. Processing an Incoming SNMP Message................... 26 4. Discovery............................................. 31 5. Definitions........................................... 32 6. HMAC-MD5-96 Authentication Protocol................... 51 6.1. Mechanisms............................................ 51 6.1.1. Digest Authentication Mechanism....................... 51 6.2. Elements of the Digest Authentication Protocol........ 52 6.2.1. Users................................................. 52 6.2.2. msgAuthoritativeEngineID.............................. 53 6.2.3. SNMP Messages Using this Authentication Protocol...... 53 6.2.4. Services provided by the HMAC-MD5-96 Authentication Module................................. 53 6.2.4.1. Services for Generating an Outgoing SNMP Message...... 53 6.2.4.2. Services for Processing an Incoming SNMP Message...... 54 6.3. Elements of Procedure................................. 55 6.3.1. Processing an Outgoing Message........................ 55 6.3.2. Processing an Incoming Message........................ 56 7. HMAC-SHA-96 Authentication Protocol................... 57 7.1. Mechanisms............................................ 57 7.1.1. Digest Authentication Mechanism....................... 57 7.2. Elements of the HMAC-SHA-96 Authentication Protocol... 58 7.2.1. Users................................................. 58 7.2.2. msgAuthoritativeEngineID.............................. 58 7.2.3. SNMP Messages Using this Authentication Protocol...... 59 7.2.4. Services provided by the HMAC-SHA-96 Authentication Module................................. 59 7.2.4.1. Services for Generating an Outgoing SNMP Message...... 59 7.2.4.2. Services for Processing an Incoming SNMP Message...... 60 7.3. Elements of Procedure................................. 61 Blumenthal & Wijnen Standards Track [Page 2] RFC 3414 USM for SNMPv3 December 2002 7.3.1. Processing an Outgoing Message........................ 61 7.3.2. Processing an Incoming Message........................ 61 8. CBC-DES Symmetric Encryption Protocol................. 63 8.1. Mechanisms............................................ 63 8.1.1. Symmetric Encryption Protocol......................... 63 8.1.1.1. DES key and Initialization Vector..................... 64 8.1.1.2. Data Encryption....................................... 65 8.1.1.3. Data Decryption....................................... 65 8.2. Elements of the DES Privacy Protocol.................. 65 8.2.1. Users................................................. 65 8.2.2. msgAuthoritativeEngineID.............................. 66 8.2.3. SNMP Messages Using this Privacy Protocol............. 66 8.2.4. Services provided by the DES Privacy Module........... 66 8.2.4.1. Services for Encrypting Outgoing Data................. 66 8.2.4.2. Services for Decrypting Incoming Data................. 67 8.3. Elements of Procedure................................. 68 8.3.1. Processing an Outgoing Message........................ 68 8.3.2. Processing an Incoming Message........................ 69 9. Intellectual Property................................. 69 10. Acknowledgements...................................... 70 11. Security Considerations............................... 71 11.1. Recommended Practices................................. 71 11.2. Defining Users........................................ 73 11.3. Conformance........................................... 74 11.4. Use of Reports........................................ 75 11.5. Access to the SNMP-USER-BASED-SM-MIB.................. 75 12. References............................................ 75 A.1. SNMP engine Installation Parameters................... 78 A.2. Password to Key Algorithm............................. 80 A.2.1. Password to Key Sample Code for MD5................... 81 A.2.2. Password to Key Sample Code for SHA................... 82 A.3. Password to Key Sample Results........................ 83 A.3.1. Password to Key Sample Results using MD5.............. 83 A.3.2. Password to Key Sample Results using SHA.............. 83 A.4. Sample encoding of msgSecurityParameters.............. 83 A.5. Sample keyChange Results.............................. 84 A.5.1. Sample keyChange Results using MD5.................... 84 A.5.2. Sample keyChange Results using SHA.................... 85 B. Change Log............................................ 86 Editors' Addresses.................................... 87 Full Copyright Statement.............................. 88 Blumenthal & Wijnen Standards Track [Page 3] RFC 3414 USM for SNMPv3 December 2002 1. Introduction The Architecture for describing Internet Management Frameworks [RFC3411] describes that an SNMP engine is composed of: 1) a Dispatcher, 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem. Applications make use of the services of these subsystems. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Security Model described in this document fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411]. This memo describes the User-based Security Model as it is used within the SNMP Architecture. The main idea is that we use the traditional concept of a user (identified by a userName) with which to associate security information. This memo describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the authentication protocols and the use of CBC-DES as the privacy protocol. The User-based Security Model however allows for other such protocols to be used instead of or concurrent with these protocols. Therefore, the description of HMAC-MD5-96, HMAC-SHA-96 and CBC-DES are in separate sections to reflect their self-contained nature and to indicate that they can be replaced or supplemented in the future. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Threats Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any SNMP Security Model. Other threats are not applicable to the network management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which this SNMP Security Model should provide protection are: Blumenthal & Wijnen Standards Track [Page 4] RFC 3414 USM for SNMPv3 December 2002 - Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object. - Masquerade The masquerade threat is the danger that management operations not authorized for some user may be attempted by assuming the identity of another user that has the appropriate authorizations. Two secondary threats are also identified. The Security Model defined in this memo provides limited protection against: - Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between managed agents and a management station. Protecting against this threat may be required as a matter of local policy. - Message Stream Modification The SNMP protocol is typically based upon a connection-less transport service which may operate over any sub-network service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such sub- network services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a sub-network service, in order to effect unauthorized management operations. There are at least two threats that an SNMP Security Model need not protect against. The security protocols defined in this memo do not provide protection against: - Denial of Service This SNMP Security Model does not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable network management protocol must cope as a matter of course. - Traffic Analysis This SNMP Security Model does not attempt to address traffic analysis attacks. Indeed, many traffic patterns are predictable - devices may be managed on a regular basis by a relatively small number of management applications - and therefore there is no significant advantage afforded by protecting against traffic analysis. Blumenthal & Wijnen Standards Track [Page 5] RFC 3414 USM for SNMPv3 December 2002 1.2. Goals and Constraints Based on the foregoing account of threats in the SNMP network management environment, the goals of this SNMP Security Model are as follows. 1) Provide for verification that each received SNMP message has not been modified during its transmission through the network. 2) Provide for verification of the identity of the user on whose behalf a received SNMP message claims to have been generated. 3) Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent. 4) Provide, when necessary, that the contents of each received SNMP message are protected from disclosure. In addition to the principal goal of supporting secure network management, the design of this SNMP Security Model is also influenced by the following constraints: 1) When the requirements of effective management in times of network stress are inconsistent with those of security, the design of USM has given preference to the former. 2) Neither the security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or key management protocols). 3) A security mechanism should entail no changes to the basic SNMP network management philosophy. 1.3. Security Services The security services necessary to support the goals of this SNMP Security Model are as follows: - Data Integrity is the provision of the property that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non- maliciously. - Data Origin Authentication is the provision of the property that the claimed identity of the user on whose behalf received data was originated is corroborated. Blumenthal & Wijnen Standards Track [Page 6] RFC 3414 USM for SNMPv3 December 2002 - Data Confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. - Message timeliness and limited replay protection is the provision of the property that a message whose generation time is outside of a specified time window is not accepted. Note that message reordering is not dealt with and can occur in normal conditions too. For the protocols specified in this memo, it is not possible to assure the specific originator of a received SNMP message; rather, it is the user on whose behalf the message was originated that is authenticated. For these protocols, it not possible to obtain data integrity without data origin authentication, nor is it possible to obtain data origin authentication without data integrity. Further, there is no provision for data confidentiality without both data integrity and data origin authentication. The security protocols used in this memo are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises. 1.4. Module Organization The security protocols defined in this memo are split in three different modules and each has its specific responsibilities such that together they realize the goals and security services described above: - The authentication module MUST provide for: - Data Integrity, - Data Origin Authentication, - The timeliness module MUST provide for: - Protection against message delay or replay (to an extent greater than can occur through normal operation). - The privacy module MUST provide for - Protection against disclosure of the message payload. Blumenthal & Wijnen Standards Track [Page 7] RFC 3414 USM for SNMPv3 December 2002 The timeliness module is fixed for the User-based Security Model while there is provision for multiple authentication and/or privacy modules, each of which implements a specific authentication or privacy protocol respectively. 1.4.1. Timeliness Module Section 3 (Elements of Procedure) uses the timeliness values in an SNMP message to do timeliness checking. The timeliness check is only performed if authentication is applied to the message. Since the complete message is checked for integrity, we can assume that the timeliness values in a message that passes the authentication module are trustworthy. 1.4.2. Authentication Protocol Section 6 describes the HMAC-MD5-96 authentication protocol which is the first authentication protocol that MUST be supported with the User-based Security Model. Section 7 describes the HMAC-SHA-96 authentication protocol which is another authentication protocol that SHOULD be supported with the User-based Security Model. In the future additional or replacement authentication protocols may be defined as new needs arise. The User-based Security Model prescribes that, if authentication is used, then the complete message is checked for integrity in the authentication module. For a message to be authenticated, it needs to pass authentication check by the authentication module and the timeliness check which is a fixed part of this User-based Security model. 1.4.3. Privacy Protocol Section 8 describes the CBC-DES Symmetric Encryption Protocol which is the first privacy protocol to be used with the User-based Security Model. In the future additional or replacement privacy protocols may be defined as new needs arise. The User-based Security Model prescribes that the scopedPDU is protected from disclosure when a message is sent with privacy. The User-based Security Model also prescribes that a message needs to be authenticated if privacy is in use. Blumenthal & Wijnen Standards Track [Page 8] RFC 3414 USM for SNMPv3 December 2002 1.5. Protection against Message Replay, Delay and Redirection 1.5.1. Authoritative SNMP Engine In order to protect against message replay, delay and redirection, one of the SNMP engines involved in each communication is designated to be the authoritative SNMP engine. When an SNMP message contains a payload which expects a response (those messages that contain a Confirmed Class PDU [RFC3411]), then the receiver of such messages is authoritative. When an SNMP message contains a payload which does not expect a response (those messages that contain an Unconfirmed Class PDU [RFC3411]), then the sender of such a message is authoritative. 1.5.2. Mechanisms The following mechanisms are used: 1) To protect against the threat of message delay or replay (to an extent greater than can occur through normal operation), a set of timeliness indicators (for the authoritative SNMP engine) are included in each message generated. An SNMP engine evaluates the timeliness indicators to determine if a received message is recent. An SNMP engine may evaluate the timeliness indicators to ensure that a received message is at least as recent as the last message it received from the same source. A non-authoritative SNMP engine uses received authentic messages to advance its notion of the timeliness indicators at the remote authoritative source. An SNMP engine MUST also use a mechanism to match incoming Responses to outstanding Requests and it MUST drop any Responses that do not match an outstanding request. For example, a msgID can be inserted in every message to cater for this functionality. These mechanisms provide for the detection of authenticated messages whose time of generation was not recent. This protection against the threat of message delay or replay does not imply nor provide any protection against unauthorized deletion or suppression of messages. Also, an SNMP engine may not be able to detect message reordering if all the messages involved are sent within the Time Window interval. Other mechanisms defined independently of the security protocol can also be used to detect the re-ordering replay, deletion, or suppression of messages containing Set operations (e.g., the MIB variable snmpSetSerialNo [RFC3418]). Blumenthal & Wijnen Standards Track [Page 9] RFC 3414 USM for SNMPv3 December 2002 2) Verification that a message sent to/from one authoritative SNMP engine cannot be replayed to/as-if-from another authoritative SNMP engine. Included in each message is an identifier unique to the authoritative SNMP engine associated with the sender or intended recipient of the message. A message containing an Unconfirmed Class PDU sent by an authoritative SNMP engine to one non-authoritative SNMP engine can potentially be replayed to another non-authoritative SNMP engine. The latter non-authoritative SNMP engine might (if it knows about the same userName with the same secrets at the authoritative SNMP engine) as a result update its notion of timeliness indicators of the authoritative SNMP engine, but that is not considered a threat. In this case, A Report or Response message will be discarded by the Message Processing Model, because there should not be an outstanding Request message. A Trap will possibly be accepted. Again, that is not considered a threat, because the communication was authenticated and timely. It is as if the authoritative SNMP engine was configured to start sending Traps to the second SNMP engine, which theoretically can happen without the knowledge of the second SNMP engine anyway. Anyway, the second SNMP engine may not expect to receive this Trap, but is allowed to see the management information contained in it. 3) Detection of messages which were not recently generated. A set of time indicators are included in the message, indicating the time of generation. Messages without recent time indicators are not considered authentic. In addition, an SNMP engine MUST drop any Responses that do not match an outstanding request. This however is the responsibility of the Message Processing Model. This memo allows the same user to be defined on multiple SNMP engines. Each SNMP engine maintains a value, snmpEngineID, which uniquely identifies the SNMP engine. This value is included in each message sent to/from the SNMP engine that is authoritative (see section 1.5.1). On receipt of a message, an authoritative SNMP engine checks the value to ensure that it is the intended recipient, and a non-authoritative SNMP engine uses the value to ensure that the message is processed using the correct state information. Each SNMP engine maintains two values, snmpEngineBoots and snmpEngineTime, which taken together provide an indication of time at that SNMP engine. Both of these values are included in an authenticated message sent to/received from that SNMP engine. On receipt, the values are checked to ensure that the indicated Blumenthal & Wijnen Standards Track [Page 10] RFC 3414 USM for SNMPv3 December 2002 timeliness value is within a Time Window of the current time. The Time Window represents an administrative upper bound on acceptable delivery delay for protocol messages. For an SNMP engine to generate a message which an authoritative SNMP engine will accept as authentic, and to verify that a message received from that authoritative SNMP engine is authentic, such an SNMP engine must first achieve timeliness synchronization with the authoritative SNMP engine. See section 2.3. 1.6. Abstract Service Interfaces Abstract service interfaces have been defined to describe the conceptual interfaces between the various subsystems within an SNMP entity. Similarly a set of abstract service interfaces have been defined within the User-based Security Model (USM) to describe the conceptual interfaces between the generic USM services and the self-contained authentication and privacy services. These abstract service interfaces are defined by a set of primitives that define the services provided and the abstract data elements that must be passed when the services are invoked. This section lists the primitives that have been defined for the User-based Security Model. 1.6.1. User-based Security Model Primitives for Authentication The User-based Security Model provides the following internal primitives to pass data back and forth between the Security Model itself and the authentication service: statusInformation = authenticateOutgoingMsg( IN authKey -- secret key for authentication IN wholeMsg -- unauthenticated complete message OUT authenticatedWholeMsg -- complete authenticated message ) statusInformation = authenticateIncomingMsg( IN authKey -- secret key for authentication IN authParameters -- as received on the wire IN wholeMsg -- as received on the wire OUT authenticatedWholeMsg -- complete authenticated message ) Blumenthal & Wijnen Standards Track [Page 11] RFC 3414 USM for SNMPv3 December 2002 1.6.2. User-based Security Model Primitives for Privacy The User-based Security Model provides the following internal primitives to pass data back and forth between the Security Model itself and the privacy service: statusInformation = encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU) OUT encryptedData -- encrypted data (encryptedPDU) OUT privParameters -- filled in by service provider ) statusInformation = decryptData( IN decryptKey -- secret key for decrypting IN privParameters -- as received on the wire IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) ) 2. Elements of the Model This section contains definitions required to realize the security model defined by this memo. 2.1. User-based Security Model Users Management operations using this Security Model make use of a defined set of user identities. For any user on whose behalf management operations are authorized at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user. A user and its attributes are defined as follows: userName A string representing the name of the user. securityName A human-readable string representing the user in a format that is Security Model independent. There is a one-to-one relationship between userName and securityName. Blumenthal & Wijnen Standards Track [Page 12] RFC 3414 USM for SNMPv3 December 2002 authProtocol An indication of whether messages sent on behalf of this user can be authenticated, and if so, the type of authentication protocol which is used. Two such protocols are defined in this memo: - the HMAC-MD5-96 authentication protocol. - the HMAC-SHA-96 authentication protocol. authKey If messages sent on behalf of this user can be authenticated, the (private) authentication key for use with the authentication protocol. Note that a user's authentication key will normally be different at different authoritative SNMP engines. The authKey is not accessible via SNMP. The length requirements of the authKey are defined by the authProtocol in use. authKeyChange and authOwnKeyChange The only way to remotely update the authentication key. Does that in a secure manner, so that the update can be completed without the need to employ privacy protection. privProtocol An indication of whether messages sent on behalf of this user can be protected from disclosure, and if so, the type of privacy protocol which is used. One such protocol is defined in this memo: the CBC-DES Symmetric Encryption Protocol. privKey If messages sent on behalf of this user can be en/decrypted, the (private) privacy key for use with the privacy protocol. Note that a user's privacy key will normally be different at different authoritative SNMP engines. The privKey is not accessible via SNMP. The length requirements of the privKey are defined by the privProtocol in use. privKeyChange and privOwnKeyChange The only way to remotely update the encryption key. Does that in a secure manner, so that the update can be completed without the need to employ privacy protection. 2.2. Replay Protection Each SNMP engine maintains three objects: - snmpEngineID, which (at least within an administrative domain) uniquely and unambiguously identifies an SNMP engine. Blumenthal & Wijnen Standards Track [Page 13] RFC 3414 USM for SNMPv3 December 2002 - snmpEngineBoots, which is a count of the number of times the SNMP engine has re-booted/re-initialized since snmpEngineID was last configured; and, - snmpEngineTime, which is the number of seconds since the snmpEngineBoots counter was last incremented. Each SNMP engine is always authoritative with respect to these objects in its own SNMP entity. It is the responsibility of a non- authoritative SNMP engine to synchronize with the authoritative SNMP engine, as appropriate. An authoritative SNMP engine is required to maintain the values of its snmpEngineID and snmpEngineBoots in non-volatile storage. 2.2.1. msgAuthoritativeEngineID The msgAuthoritativeEngineID value contained in an authenticated message is used to defeat attacks in which messages from one SNMP engine to another SNMP engine are replayed to a different SNMP engine. It represents the snmpEngineID at the authoritative SNMP engine involved in the exchange of the message. When an authoritative SNMP engine is first installed, it sets its local value of snmpEngineID according to a enterprise-specific algorithm (see the definition of the Textual Convention for SnmpEngineID in the SNMP Architecture document [RFC3411]). 2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime The msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values contained in an authenticated message are used to defeat attacks in which messages are replayed when they are no longer valid. They represent the snmpEngineBoots and snmpEngineTime values at the authoritative SNMP engine involved in the exchange of the message. Through use of snmpEngineBoots and snmpEngineTime, there is no requirement for an SNMP engine to have a non-volatile clock which ticks (i.e., increases with the passage of time) even when the SNMP engine is powered off. Rather, each time an SNMP engine re-boots, it retrieves, increments, and then stores snmpEngineBoots in non-volatile storage, and resets snmpEngineTime to zero. When an SNMP engine is first installed, it sets its local values of snmpEngineBoots and snmpEngineTime to zero. If snmpEngineTime ever reaches its maximum value (2147483647), then snmpEngineBoots is incremented as if the SNMP engine has re-booted and snmpEngineTime is reset to zero and starts incrementing again. Blumenthal & Wijnen Standards Track [Page 14] RFC 3414 USM for SNMPv3 December 2002 Each time an authoritative SNMP engine re-boots, any SNMP engines holding that authoritative SNMP engine's values of snmpEngineBoots and snmpEngineTime need to re-synchronize prior to sending correctly authenticated messages to that authoritative SNMP engine (see Section 2.3 for (re-)synchronization procedures). Note, however, that the procedures do provide for a notification to be accepted as authentic by a receiving SNMP engine, when sent by an authoritative SNMP engine which has re-booted since the receiving SNMP engine last (re- )synchronized. If an authoritative SNMP engine is ever unable to determine its latest snmpEngineBoots value, then it must set its snmpEngineBoots value to 2147483647. Whenever the local value of snmpEngineBoots has the value 2147483647 it latches at that value and an authenticated message always causes an notInTimeWindow authentication failure. In order to reset an SNMP engine whose snmpEngineBoots value has reached the value 2147483647, manual intervention is required. The engine must be physically visited and re-configured, either with a new snmpEngineID value, or with new secret values for the authentication and privacy protocols of all users known to that SNMP engine. Note that even if an SNMP engine re-boots once a second that it would still take approximately 68 years before the max value of 2147483647 would be reached. 2.2.3. Time Window The Time Window is a value that specifies the window of time in which a message generated on behalf of any user is valid. This memo specifies that the same value of the Time Window, 150 seconds, is used for all users. 2.3. Time Synchronization Time synchronization, required by a non-authoritative SNMP engine in order to proceed with authentic communications, has occurred when the non-authoritative SNMP engine has obtained a local notion of the authoritative SNMP engine's values of snmpEngineBoots and snmpEngineTime from the authoritative SNMP engine. These values must be (and remain) within the authoritative SNMP engine's Time Window. So the local notion of the authoritative SNMP engine's values must be kept loosely synchronized with the values stored at the authoritative SNMP engine. In addition to keeping a local copy of snmpEngineBoots and snmpEngineTime from the authoritative SNMP engine, a non-authoritative SNMP engine must also keep one Blumenthal & Wijnen Standards Track [Page 15] RFC 3414 USM for SNMPv3 December 2002 local variable, latestReceivedEngineTime. This value records the highest value of snmpEngineTime that was received by the non-authoritative SNMP engine from the authoritative SNMP engine and is used to eliminate the possibility of replaying messages that would prevent the non-authoritative SNMP engine's notion of the snmpEngineTime from advancing. A non-authoritative SNMP engine must keep local notions of these values (snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime) for each authoritative SNMP engine with which it wishes to communicate. Since each authoritative SNMP engine is uniquely and unambiguously identified by its value of snmpEngineID, the non-authoritative SNMP engine may use this value as a key in order to cache its local notions of these values. Time synchronization occurs as part of the procedures of receiving an SNMP message (Section 3.2, step 7b). As such, no explicit time synchronization procedure is required by a non-authoritative SNMP engine. Note, that whenever the local value of snmpEngineID is changed (e.g., through discovery) or when secure communications are first established with an authoritative SNMP engine, the local values of snmpEngineBoots and latestReceivedEngineTime should be set to zero. This will cause the time synchronization to occur when the next authentic message is received. 2.4. SNMP Messages Using this Security Model The syntax of an SNMP message using this Security Model adheres to the message format defined in the version-specific Message Processing Model document (for example [RFC3412]). The field msgSecurityParameters in SNMPv3 messages has a data type of OCTET STRING. Its value is the BER serialization of the following ASN.1 sequence: USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN UsmSecurityParameters ::= SEQUENCE { -- global User-based security parameters msgAuthoritativeEngineID OCTET STRING, msgAuthoritativeEngineBoots INTEGER (0..2147483647), msgAuthoritativeEngineTime INTEGER (0..2147483647), msgUserName OCTET STRING (SIZE(0..32)), -- authentication protocol specific parameters msgAuthenticationParameters OCTET STRING, -- privacy protocol specific parameters msgPrivacyParameters OCTET STRING Blumenthal & Wijnen Standards Track [Page 16] RFC 3414 USM for SNMPv3 December 2002 } END The fields of this sequence are: - The msgAuthoritativeEngineID specifies the snmpEngineID of the authoritative SNMP engine involved in the exchange of the message. - The msgAuthoritativeEngineBoots specifies the snmpEngineBoots value at the authoritative SNMP engine involved in the exchange of the message. - The msgAuthoritativeEngineTime specifies the snmpEngineTime value at the authoritative SNMP engine involved in the exchange of the message. - The msgUserName specifies the user (principal) on whose behalf the message is being exchanged. Note that a zero-length userName will not match any user, but it can be used for snmpEngineID discovery. - The msgAuthenticationParameters are defined by the authentication protocol in use for the message, as defined by the usmUserAuthProtocol column in the user's entry in the usmUserTable. - The msgPrivacyParameters are defined by the privacy protocol in use for the message, as defined by the usmUserPrivProtocol column in the user's entry in the usmUserTable). See appendix A.4 for an example of the BER encoding of field msgSecurityParameters. 2.5. Services provided by the User-based Security Model This section describes the services provided by the User-based Security Model with their inputs and outputs. The services are described as primitives of an abstract service interface and the inputs and outputs are described as abstract data elements as they are passed in these abstract service primitives. 2.5.1. Services for Generating an Outgoing SNMP Message When the Message Processing (MP) Subsystem invokes the User-based Security module to secure an outgoing SNMP message, it must use the appropriate service as provided by the Security module. These two services are provided: Blumenthal & Wijnen Standards Track [Page 17] RFC 3414 USM for SNMPv3 December 2002 1) A service to generate a Request message. The abstract service primitive is: statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message ) 2) A service to generate a Response message. The abstract service primitive is: statusInformation = -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state -- information from original -- request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message ) The abstract data elements passed as parameters in the abstract service primitives are as follows: statusInformation An indication of whether the encoding and securing of the message was successful. If not it is an indication of the problem. Blumenthal & Wijnen Standards Track [Page 18] RFC 3414 USM for SNMPv3 December 2002 messageProcessingModel The SNMP version number for the message to be generated. This data is not used by the User-based Security module. globalData The message header (i.e., its administrative information). This data is not used by the User-based Security module. maxMessageSize The maximum message size as included in the message. This data is not used by the User-based Security module. securityParameters These are the security parameters. They will be filled in by the User-based Security module. securityModel The securityModel in use. Should be User-based Security Model. This data is not used by the User-based Security module. securityName Together with the snmpEngineID it identifies a row in the usmUserTablethat is to be used for securing the message. The securityName has a format that is independent of the Security Model. In case of a response this parameter is ignored and the value from the cache is used. securityLevel The Level of Security from which the User-based Security module determines if the message needs to be protected from disclosure and if the message needs to be authenticated. securityEngineID The snmpEngineID of the authoritative SNMP engine to which a dateRequest message is to be sent. In case of a response it is implied to be the processing SNMP engine's snmpEngineID and so if it is specified, then it is ignored. scopedPDU The message payload. The data is opaque as far as the User-based Security Model is concerned. securityStateReference A handle/reference to cachedSecurityData to be used when securing an outgoing Response message. This is the exact same handle/reference as it was generated by the User-based Security module when processing the incoming Request message to which this is the Response message. Blumenthal & Wijnen Standards Track [Page 19] RFC 3414 USM for SNMPv3 December 2002 wholeMsg The fully encoded and secured message ready for sending on the wire. wholeMsgLength The length of the encoded and secured message (wholeMsg). Upon completion of the process, the User-based Security module returns statusInformation. If the process was successful, the completed message with privacy and authentication applied if such was requested by the specified securityLevel is returned. If the process was not successful, then an errorIndication is returned. 2.5.2. Services for Processing an Incoming SNMP Message When the Message Processing (MP) Subsystem invokes the User-based Security module to verify proper security of an incoming message, it must use the service provided for an incoming message. The abstract service primitive is: statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU OUT securityStateReference -- reference to security state ) -- information, needed for response The abstract data elements passed as parameters in the abstract service primitives are as follows: statusInformation An indication of whether the process was successful or not. If not, then the statusInformation includes the OID and the value of the error counter that was incremented. messageProcessingModel The SNMP version number as received in the message. This data is not used by the User-based Security module. Blumenthal & Wijnen Standards Track [Page 20] RFC 3414 USM for SNMPv3 December 2002 maxMessageSize The maximum message size as included in the message. The User-bas User-based Security module uses this value to calculate the maxSizeResponseScopedPDU. securityParameters These are the security parameters as received in the message. securityModel The securityModel in use. Should be the User-based Security Model. This data is not used by the User-based Security module. securityLevel The Level of Security from which the User-based Security module determines if the message needs to be protected from disclosure and if the message needs to be authenticated. wholeMsg The whole message as it was received. wholeMsgLength The length of the message as it was received (wholeMsg). securityEngineID The snmpEngineID that was extracted from the field msgAuthoritativeEngineID and that was used to lookup the secrets in the usmUserTable. securityName The security name representing the user on whose behalf the message was received. The securityName has a format that is independent of the Security Model. scopedPDU The message payload. The data is opaque as far as the User-based Security Model is concerned. maxSizeResponseScopedPDU The maximum size of a scopedPDU to be included in a possible Response message. The User-based Security module calculates this size based on the msgMaxSize (as received in the message) and the space required for the message header (including the securityParameters) for such a Response message. securityStateReference A handle/reference to cachedSecurityData to be used when securing an outgoing Response message. When the Message Processing Subsystem calls the User-based Security module to generate a Blumenthal & Wijnen Standards Track [Page 21] RFC 3414 USM for SNMPv3 December 2002 response to this incoming message it must pass this handle/reference. Upon completion of the process, the User-based Security module returns statusInformation and, if the process was successful, the additional data elements for further processing of the message. If the process was not successful, then an errorIndication, possibly with a OID and value pair of an error counter that was incremented. 2.6. Key Localization Algorithm. A localized key is a secret key shared between a user U and one authoritative SNMP engine E. Even though a user may have only one password and therefore one key for the whole network, the actual secrets shared between the user and each authoritative SNMP engine will be different. This is achieved by key localization [Localized- key]. First, if a user uses a password, then the user's password is converted into a key Ku using one of the two algorithms described in Appendices A.2.1 and A.2.2. To convert key Ku into a localized key Kul of user U at the authoritative SNMP engine E, one appends the snmpEngineID of the authoritative SNMP engine to the key Ku and then appends the key Ku to the result, thus enveloping the snmpEngineID within the two copies of user's key Ku. Then one runs a secure hash function (which one depends on the authentication protocol defined for this user U at authoritative SNMP engine E; this document defines two authentication protocols with their associated algorithms based on MD5 and SHA). The output of the hash-function is the localized key Kul for user U at the authoritative SNMP engine E. 3. Elements of Procedure This section describes the security related procedures followed by an SNMP engine when processing SNMP messages according to the User-based Security Model. 3.1. Generating an Outgoing SNMP Message This section describes the procedure followed by an SNMP engine whenever it generates a message containing a management operation (like a request, a response, a notification, or a report) on behalf of a user, with a particular securityLevel. Blumenthal & Wijnen Standards Track [Page 22] RFC 3414 USM for SNMPv3 December 2002 1) a) If any securityStateReference is passed (Response or Report message), then information concerning the user is extracted from the cachedSecurityData. The cachedSecurityData can now be discarded. The securityEngineID is set to the local snmpEngineID. The securityLevel is set to the value specified by the calling module. Otherwise, b) based on the securityName, information concerning the user at the destination snmpEngineID, specified by the securityEngineID, is extracted from the Local Configuration Datastore (LCD, usmUserTable). If information about the user is absent from the LCD, then an error indication (unknownSecurityName) is returned to the calling module. 2) If the securityLevel specifies that the message is to be protected from disclosure, but the user does not support both an authentication and a privacy protocol then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module. 3) If the securityLevel specifies that the message is to be authenticated, but the user does not support an authentication protocol, then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module. 4) a) If the securityLevel specifies that the message is to be protected from disclosure, then the octet sequence representing the serialized scopedPDU is encrypted according to the user's privacy protocol. To do so a call is made to the privacy module that implements the user's privacy protocol according to the abstract primitive: statusInformation = -- success or failure encryptData( IN encryptKey -- user's localized privKey IN dataToEncrypt -- serialized scopedPDU OUT encryptedData -- serialized encryptedPDU OUT privParameters -- serialized privacy parameters ) statusInformation indicates if the encryption process was successful or not. encryptKey the user's localized private privKey is the secret key that can be used by the encryption algorithm. Blumenthal & Wijnen Standards Track [Page 23] RFC 3414 USM for SNMPv3 December 2002 dataToEncrypt the serialized scopedPDU is the data to be encrypted. encryptedData the encryptedPDU represents the encrypted scopedPDU, encoded as an OCTET STRING. privParameters the privacy parameters, encoded as an OCTET STRING. If the privacy module returns failure, then the message cannot be sent and an error indication (encryptionError) is returned to the calling module. If the privacy module returns success, then the returned privParameters are put into the msgPrivacyParameters field of the securityParameters and the encryptedPDU serves as the payload of the message being prepared. Otherwise, b) If the securityLevel specifies that the message is not to be be protected from disclosure, then a zero-length OCTET STRING is encoded into the msgPrivacyParameters field of the securityParameters and the plaintext scopedPDU serves as the payload of the message being prepared. 5) The securityEngineID is encoded as an OCTET STRING into the msgAuthoritativeEngineID field of the securityParameters. Note that an empty (zero length) securityEngineID is OK for a Request message, because that will cause the remote (authoritative) SNMP engine to return a Report PDU with the proper securityEngineID included in the msgAuthoritativeEngineID in the securityParameters of that returned Report PDU. 6) a) If the securityLevel specifies that the message is to be authenticated, then the current values of snmpEngineBoots and snmpEngineTime corresponding to the securityEngineID from the LCD are used. Otherwise, b) If this is a Response or Report message, then the current value of snmpEngineBoots and snmpEngineTime corresponding to the local snmpEngineID from the LCD are used. Blumenthal & Wijnen Standards Track [Page 24] RFC 3414 USM for SNMPv3 December 2002 Otherwise, c) If this is a Request message, then a zero value is used for both snmpEngineBoots and snmpEngineTime. This zero value gets used if snmpEngineID is empty. The values are encoded as INTEGER respectively into the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields of the securityParameters. 7) The userName is encoded as an OCTET STRING into the msgUserName field of the securityParameters. 8) a) If the securityLevel specifies that the message is to be authenticated, the message is authenticated according to the user's authentication protocol. To do so a call is made to the authentication module that implements the user's authentication protocol according to the abstract service primitive: statusInformation = authenticateOutgoingMsg( IN authKey -- the user's localized authKey IN wholeMsg -- unauthenticated message OUT authenticatedWholeMsg -- authenticated complete message ) statusInformation indicates if authentication was successful or not. authKey the user's localized private authKey is the secret key that can be used by the authentication algorithm. wholeMsg the complete serialized message to be authenticated. authenticatedWholeMsg the same as the input given to the authenticateOutgoingMsg service, but with msgAuthenticationParameters properly filled in. If the authentication module returns failure, then the message cannot be sent and an error indication (authenticationFailure) is returned to the calling module. Blumenthal & Wijnen Standards Track [Page 25] RFC 3414 USM for SNMPv3 December 2002 If the authentication module returns success, then the msgAuthenticationParameters field is put into the securityParameters and the authenticatedWholeMsg represents the serialization of the authenticated message being prepared. Otherwise, b) If the securityLevel specifies that the message is not to be authenticated then a zero-length OCTET STRING is encoded into the msgAuthenticationParameters field of the securityParameters. The wholeMsg is now serialized and then represents the unauthenticated message being prepared. 9) The completed message with its length is returned to the calling module with the statusInformation set to success. 3.2. Processing an Incoming SNMP Message This section describes the procedure followed by an SNMP engine whenever it receives a message containing a management operation on behalf of a user, with a particular securityLevel. To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message gets discarded, the state information should also be released. Also, an error indication can return an OID and value for an incremented counter and optionally a value for securityLevel, and values for contextEngineID or contextName for the counter. In addition, the securityStateReference data is returned if any such information is available at the point where the error is detected. 1) If the received securityParameters is not the serialization (according to the conventions of [RFC3417]) of an OCTET STRING formatted according to the UsmSecurityParameters defined in section 2.4, then the snmpInASNParseErrs counter [RFC3418] is incremented, and an error indication (parseError) is returned to the calling module. Note that we return without the OID and value of the incremented counter, because in this case there is not enough information to generate a Report PDU. 2) The values of the security parameter fields are extracted from the securityParameters. The securityEngineID to be returned to the caller is the value of the msgAuthoritativeEngineID field. The cachedSecurityData is prepared and a securityStateReference is prepared to reference this data. Values to be cached are: msgUserName Blumenthal & Wijnen Standards Track [Page 26] RFC 3414 USM for SNMPv3 December 2002 3) If the value of the msgAuthoritativeEngineID field in the securityParameters is unknown then: a) a non-authoritative SNMP engine that performs discovery may optionally create a new entry in its Local Configuration Datastore (LCD) and continue processing; or b) the usmStatsUnknownEngineIDs counter is incremented, and an error indication (unknownEngineID) together with the OID and value of the incremented counter is returned to the calling module. Note in the event that a zero-length, or other illegally sized msgAuthoritativeEngineID is received, b) should be chosen to facilitate engineID discovery. Otherwise the choice between a) and b) is an implementation issue. 4) Information about the value of the msgUserName and msgAuthoritativeEngineID fields is extracted from the Local Configuration Datastore (LCD, usmUserTable). If no information is available for the user, then the usmStatsUnknownUserNames counter is incremented and an error indication (unknownSecurityName) together with the OID and value of the incremented counter is returned to the calling module. 5) If the information about the user indicates that it does not support the securityLevel requested by the caller, then the usmStatsUnsupportedSecLevels counter is incremented and an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module. 6) If the securityLevel specifies that the message is to be authenticated, then the message is authenticated according to the user's authentication protocol. To do so a call is made to the authentication module that implements the user's authentication protocol according to the abstract service primitive: statusInformation = -- success or failure authenticateIncomingMsg( IN authKey -- the user's localized authKey IN authParameters -- as received on the wire IN wholeMsg -- as received on the wire OUT authenticatedWholeMsg -- checked for authentication ) Blumenthal & Wijnen Standards Track [Page 27] RFC 3414 USM for SNMPv3 December 2002 statusInformation indicates if authentication was successful or not. authKey the user's localized private authKey is the secret key that can be used by the authentication algorithm. wholeMsg the complete serialized message to be authenticated. authenticatedWholeMsg the same as the input given to the authenticateIncomingMsg service, but after authentication has been checked. If the authentication module returns failure, then the message cannot be trusted, so the usmStatsWrongDigests counter is incremented and an error indication (authenticationFailure) together with the OID and value of the incremented counter is returned to the calling module. If the authentication module returns success, then the message is authentic and can be trusted so processing continues. 7) If the securityLevel indicates an authenticated message, then the local values of snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime corresponding to the value of the msgAuthoritativeEngineID field are extracted from the Local Configuration Datastore. a) If the extracted value of msgAuthoritativeEngineID is the same as the value of snmpEngineID of the processing SNMP engine (meaning this is the authoritative SNMP engine), then if any of the following conditions is true, then the message is considered to be outside of the Time Window: - the local value of snmpEngineBoots is 2147483647; - the value of the msgAuthoritativeEngineBoots field differs from the local value of snmpEngineBoots; or, - the value of the msgAuthoritativeEngineTime field differs from the local notion of snmpEngineTime by more than +/- 150 seconds. If the message is considered to be outside of the Time Window then the usmStatsNotInTimeWindows counter is incremented and an error indication (notInTimeWindow) together with the OID, the value of the incremented counter, and an indication that Blumenthal & Wijnen Standards Track [Page 28] RFC 3414 USM for SNMPv3 December 2002 the error must be reported with a securityLevel of authNoPriv, is returned to the calling module b) If the extracted value of msgAuthoritativeEngineID is not the same as the value snmpEngineID of the processing SNMP engine (meaning this is not the authoritative SNMP engine), then: 1) if at least one of the following conditions is true: - the extracted value of the msgAuthoritativeEngineBoots field is greater than the local notion of the value of snmpEngineBoots; or, - the extracted value of the msgAuthoritativeEngineBoots field is equal to the local notion of the value of snmpEngineBoots, and the extracted value of msgAuthoritativeEngineTime field is greater than the value of latestReceivedEngineTime, then the LCD entry corresponding to the extracted value of the msgAuthoritativeEngineID field is updated, by setting: - the local notion of the value of snmpEngineBoots to the value of the msgAuthoritativeEngineBoots field, - the local notion of the value of snmpEngineTime to the value of the msgAuthoritativeEngineTime field, and - the latestReceivedEngineTime to the value of the value of the msgAuthoritativeEngineTime field. 2) if any of the following conditions is true, then the message is considered to be outside of the Time Window: - the local notion of the value of snmpEngineBoots is 2147483647; - the value of the msgAuthoritativeEngineBoots field is less than the local notion of the value of snmpEngineBoots; or, - the value of the msgAuthoritativeEngineBoots field is equal to the local notion of the value of snmpEngineBoots and the value of the msgAuthoritativeEngineTime field is more than 150 seconds less than the local notion of the value of snmpEngineTime. Blumenthal & Wijnen Standards Track [Page 29] RFC 3414 USM for SNMPv3 December 2002 If the message is considered to be outside of the Time Window then an error indication (notInTimeWindow) is returned to the calling module. Note that this means that a too old (possibly replayed) message has been detected and is deemed unauthentic. Note that this procedure allows for the value of msgAuthoritativeEngineBoots in the message to be greater than the local notion of the value of snmpEngineBoots to allow for received messages to be accepted as authentic when received from an authoritative SNMP engine that has re-booted since the receiving SNMP engine last (re-)synchronized. 8) a) If the securityLevel indicates that the message was protected from disclosure, then the OCTET STRING representing the encryptedPDU is decrypted according to the user's privacy protocol to obtain an unencrypted serialized scopedPDU value. To do so a call is made to the privacy module that implements the user's privacy protocol according to the abstract primitive: statusInformation = -- success or failure decryptData( IN decryptKey -- the user's localized privKey IN privParameters -- as received on the wire IN encryptedData -- encryptedPDU as received OUT decryptedData -- serialized decrypted scopedPDU ) statusInformation indicates if the decryption process was successful or not. decryptKey the user's localized private privKey is the secret key that can be used by the decryption algorithm. privParameters the msgPrivacyParameters, encoded as an OCTET STRING. encryptedData the encryptedPDU represents the encrypted scopedPDU, encoded as an OCTET STRING. decryptedData the serialized scopedPDU if decryption is successful. Blumenthal & Wijnen Standards Track [Page 30] RFC 3414 USM for SNMPv3 December 2002 If the privacy module returns failure, then the message can not be processed, so the usmStatsDecryptionErrors counter is incremented and an error indication (decryptionError) together with the OID and value of the incremented counter is returned to the calling module. If the privacy module returns success, then the decrypted scopedPDU is the message payload to be returned to the calling module. Otherwise, b) The scopedPDU component is assumed to be in plain text and is the message payload to be returned to the calling module. 9) The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message. Provision is made for a message header that allows the same securityLevel as the received Request. 10) The securityName for the user is retrieved from the usmUserTable. 11) The security data is cached as cachedSecurityData, so that a possible response to this message can and will use the same authentication and privacy secrets. Information to be saved/cached is as follows: msgUserName, usmUserAuthProtocol, usmUserAuthKey usmUserPrivProtocol, usmUserPrivKey 12) The statusInformation is set to success and a return is made to the calling module passing back the OUT parameters as specified in the processIncomingMsg primitive. 4. Discovery The User-based Security Model requires that a discovery process obtains sufficient information about other SNMP engines in order to communicate with them. Discovery requires an non-authoritative SNMP engine to learn the authoritative SNMP engine's snmpEngineID value before communication may proceed. This may be accomplished by generating a Request message with a securityLevel of noAuthNoPriv, a msgUserName of zero-length, a msgAuthoritativeEngineID value of zero length, and the varBindList left empty. The response to this message will be a Report message containing the snmpEngineID of the authoritative SNMP engine as the value of the msgAuthoritativeEngineID field within the msgSecurityParameters Blumenthal & Wijnen Standards Track [Page 31] RFC 3414 USM for SNMPv3 December 2002 field. It contains a Report PDU with the usmStatsUnknownEngineIDs counter in the varBindList. If authenticated communication is required, then the discovery process should also establish time synchronization with the authoritative SNMP engine. This may be accomplished by sending an authenticated Request message with the value of msgAuthoritativeEngineID set to the newly learned snmpEngineID and with the values of msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime set to zero. For an authenticated Request message, a valid userName must be used in the msgUserName field. The response to this authenticated message will be a Report message containing the up to date values of the authoritative SNMP engine's snmpEngineBoots and snmpEngineTime as the value of the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields respectively. It also contains the usmStatsNotInTimeWindows counter in the varBindList of the Report PDU. The time synchronization then happens automatically as part of the procedures in section 3.2 step 7b. See also section 2.3. 5. Definitions SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules, Counter32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TestAndIncr, RowStatus, RowPointer, StorageType, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString, SnmpEngineID, snmpAuthProtocols, snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; snmpUsmMIB MODULE-IDENTITY LAST-UPDATED "200210160000Z" -- 16 Oct 2002, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3 Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA email: mundy@tislabs.com Blumenthal & Wijnen Standards Track [Page 32] RFC 3414 USM for SNMPv3 December 2002 phone: +1 301-947-7107 Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5004 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614 Co-editor Uri Blumenthal Lucent Technologies postal: 67 Whippany Rd. Whippany, NJ 07981 USA email: uri@lucent.com phone: +1-973-386-2163 Co-editor: Bert Wijnen Lucent Technologies postal: Schagen 33 3461 GL Linschoten Netherlands email: bwijnen@lucent.com phone: +31-348-480-685 " DESCRIPTION "The management information definitions for the SNMP User-based Security Model. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3414; see the RFC itself for full legal notices. " -- Revision history REVISION "200210160000Z" -- 16 Oct 2002, midnight DESCRIPTION "Changes in this revision: - Updated references and contact info. - Clarification to usmUserCloneFrom DESCRIPTION clause - Fixed 'command responder' into 'command generator' in last para of DESCRIPTION clause of usmUserTable. This revision published as RFC3414. " REVISION "199901200000Z" -- 20 Jan 1999, midnight DESCRIPTION "Clarifications, published as RFC2574" Blumenthal & Wijnen Standards Track [Page 33] RFC 3414 USM for SNMPv3 December 2002 REVISION "199711200000Z" -- 20 Nov 1997, midnight DESCRIPTION "Initial version, published as RFC2274" ::= { snmpModules 15 } -- Administrative assignments **************************************** usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 } usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 } -- Identification of Authentication and Privacy Protocols ************ usmNoAuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "No Authentication Protocol." ::= { snmpAuthProtocols 1 } usmHMACMD5AuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol." REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC: Keyed-Hashing for Message Authentication, RFC2104, Feb 1997. - Rivest, R., Message Digest Algorithm MD5, RFC1321. " ::= { snmpAuthProtocols 2 } usmHMACSHAAuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol." REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing for Message Authentication, RFC2104, Feb 1997. - Secure Hash Algorithm. NIST FIPS 180-1. " ::= { snmpAuthProtocols 3 } usmNoPrivProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "No Privacy Protocol." ::= { snmpPrivProtocols 1 } usmDESPrivProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The CBC-DES Symmetric Encryption Protocol." REFERENCE "- Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Blumenthal & Wijnen Standards Track [Page 34] RFC 3414 USM for SNMPv3 December 2002 Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988). - Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980). - DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980). - Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106-1983, (May 1983). " ::= { snmpPrivProtocols 2 } -- Textual Conventions *********************************************** KeyChange ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Every definition of an object with this syntax must identify a protocol P, a secret key K, and a hash algorithm H that produces output of L octets. The object's value is a manager-generated, partially-random value which, when modified, causes the value of the secret key K, to be modified via a one-way function. The value of an instance of this object is the concatenation of two components: first a 'random' component and then a 'delta' component. The lengths of the random and delta components are given by the corresponding value of the protocol P; if P requires K to be a fixed length, the length of both the random and delta components is that fixed length; if P allows the length of K to be variable up to a particular maximum length, the length of the random component is that maximum length and the length of the delta component is any length less than or equal to that maximum length. For example, usmHMACMD5AuthProtocol requires K to be a fixed length of 16 octets and L - of 16 octets. usmHMACSHAAuthProtocol requires K to be a fixed length of 20 octets and L - of 20 octets. Other protocols may define other sizes, as deemed appropriate. Blumenthal & Wijnen Standards Track [Page 35] RFC 3414 USM for SNMPv3 December 2002 When a requester wants to change the old key K to a new key keyNew on a remote entity, the 'random' component is obtained from either a true random generator, or from a pseudorandom generator, and the 'delta' component is computed as follows: - a temporary variable is initialized to the existing value of K; - if the length of the keyNew is greater than L octets, then: - the random component is appended to the value of the temporary variable, and the result is input to the the hash algorithm H to produce a digest value, and the temporary variable is set to this digest value; - the value of the temporary variable is XOR-ed with the first (next) L-octets (16 octets in case of MD5) of the keyNew to produce the first (next) L-octets (16 octets in case of MD5) of the 'delta' component. - the above two steps are repeated until the unused portion of the keyNew component is L octets or less, - the random component is appended to the value of the temporary variable, and the result is input to the hash algorithm H to produce a digest value; - this digest value, truncated if necessary to be the same length as the unused portion of the keyNew, is XOR-ed with the unused portion of the keyNew to produce the (final portion of the) 'delta' component. For example, using MD5 as the hash algorithm H: iterations = (lenOfDelta - 1)/16; /* integer division */ temp = keyOld; for (i = 0; i < iterations; i++) { temp = MD5 (temp || random); delta[i*16 .. (i*16)+15] = temp XOR keyNew[i*16 .. (i*16)+15]; } temp = MD5 (temp || random); delta[i*16 .. lenOfDelta-1] = temp XOR keyNew[i*16 .. lenOfDelta-1]; The 'random' and 'delta' components are then concatenated as described above, and the resulting octet string is sent to the recipient as the new value of an instance of this object. At the receiver side, when an instance of this object is set to a new value, then a new value of K is computed as follows: Blumenthal & Wijnen Standards Track [Page 36] RFC 3414 USM for SNMPv3 December 2002 - a temporary variable is initialized to the existing value of K; - if the length of the delta component is greater than L octets, then: - the random component is appended to the value of the temporary variable, and the result is input to the hash algorithm H to produce a digest value, and the temporary variable is set to this digest value; - the value of the temporary variable is XOR-ed with the first (next) L-octets (16 octets in case of MD5) of the delta component to produce the first (next) L-octets (16 octets in case of MD5) of the new value of K. - the above two steps are repeated until the unused portion of the delta component is L octets or less, - the random component is appended to the value of the temporary variable, and the result is input to the hash algorithm H to produce a digest value; - this digest value, truncated if necessary to be the same length as the unused portion of the delta component, is XOR-ed with the unused portion of the delta component to produce the (final portion of the) new value of K. For example, using MD5 as the hash algorithm H: iterations = (lenOfDelta - 1)/16; /* integer division */ temp = keyOld; for (i = 0; i < iterations; i++) { temp = MD5 (temp || random); keyNew[i*16 .. (i*16)+15] = temp XOR delta[i*16 .. (i*16)+15]; } temp = MD5 (temp || random); keyNew[i*16 .. lenOfDelta-1] = temp XOR delta[i*16 .. lenOfDelta-1]; The value of an object with this syntax, whenever it is retrieved by the management protocol, is always the zero length string. Note that the keyOld and keyNew are the localized keys. Note that it is probably wise that when an SNMP entity sends a SetRequest to change a key, that it keeps a copy of the old key until it has confirmed that the key change actually succeeded. " SYNTAX OCTET STRING Blumenthal & Wijnen Standards Track [Page 37] RFC 3414 USM for SNMPv3 December 2002 -- Statistics for the User-based Security Model ********************** usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 } usmStatsUnsupportedSecLevels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they requested a securityLevel that was unknown to the SNMP engine or otherwise unavailable. " ::= { usmStats 1 } usmStatsNotInTimeWindows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they appeared outside of the authoritative SNMP engine's window. " ::= { usmStats 2 } usmStatsUnknownUserNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they referenced a user that was not known to the SNMP engine. " ::= { usmStats 3 } usmStatsUnknownEngineIDs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they referenced an snmpEngineID that was not known to the SNMP engine. " ::= { usmStats 4 } usmStatsWrongDigests OBJECT-TYPE Blumenthal & Wijnen Standards Track [Page 38] RFC 3414 USM for SNMPv3 December 2002 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they didn't contain the expected digest value. " ::= { usmStats 5 } usmStatsDecryptionErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they could not be decrypted. " ::= { usmStats 6 } -- The usmUser Group ************************************************ usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 } usmUserSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating Command Generator Applications to coordinate their use of facilities to alter secrets in the usmUserTable. " ::= { usmUser 1 } -- The table of valid users for the User-based Security Model ******** usmUserTable OBJECT-TYPE SYNTAX SEQUENCE OF UsmUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of users configured in the SNMP engine's Local Configuration Datastore (LCD). To create a new user (i.e., to instantiate a new conceptual row in this table), it is recommended to follow this procedure: 1) GET(usmUserSpinLock.0) and save in sValue. Blumenthal & Wijnen Standards Track [Page 39] RFC 3414 USM for SNMPv3 December 2002 2) SET(usmUserSpinLock.0=sValue, usmUserCloneFrom=templateUser, usmUserStatus=createAndWait) You should use a template user to clone from which has the proper auth/priv protocol defined. If the new user is to use privacy: 3) generate the keyChange value based on the secret privKey of the clone-from user and the secret key to be used for the new user. Let us call this pkcValue. 4) GET(usmUserSpinLock.0) and save in sValue. 5) SET(usmUserSpinLock.0=sValue, usmUserPrivKeyChange=pkcValue usmUserPublic=randomValue1) 6) GET(usmUserPulic) and check it has randomValue1. If not, repeat steps 4-6. If the new user will never use privacy: 7) SET(usmUserPrivProtocol=usmNoPrivProtocol) If the new user is to use authentication: 8) generate the keyChange value based on the secret authKey of the clone-from user and the secret key to be used for the new user. Let us call this akcValue. 9) GET(usmUserSpinLock.0) and save in sValue. 10) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=akcValue usmUserPublic=randomValue2) 11) GET(usmUserPulic) and check it has randomValue2. If not, repeat steps 9-11. If the new user will never use authentication: 12) SET(usmUserAuthProtocol=usmNoAuthProtocol) Finally, activate the new user: 13) SET(usmUserStatus=active) The new user should now be available and ready to be used for SNMPv3 communication. Note however that access to MIB data must be provided via configuration of the SNMP-VIEW-BASED-ACM-MIB. Blumenthal & Wijnen Standards Track [Page 40] RFC 3414 USM for SNMPv3 December 2002 The use of usmUserSpinlock is to avoid conflicts with another SNMP command generator application which may also be acting on the usmUserTable. " ::= { usmUser 2 } usmUserEntry OBJECT-TYPE SYNTAX UsmUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A user configured in the SNMP engine's Local Configuration Datastore (LCD) for the User-based Security Model. " INDEX { usmUserEngineID, usmUserName } ::= { usmUserTable 1 } UsmUserEntry ::= SEQUENCE { usmUserEngineID SnmpEngineID, usmUserName SnmpAdminString, usmUserSecurityName SnmpAdminString, usmUserCloneFrom RowPointer, usmUserAuthProtocol AutonomousType, usmUserAuthKeyChange KeyChange, usmUserOwnAuthKeyChange KeyChange, usmUserPrivProtocol AutonomousType, usmUserPrivKeyChange KeyChange, usmUserOwnPrivKeyChange KeyChange, usmUserPublic OCTET STRING, usmUserStorageType StorageType, usmUserStatus RowStatus } usmUserEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS not-accessible STATUS current DESCRIPTION "An SNMP engine's administratively-unique identifier. In a simple agent, this value is always that agent's own snmpEngineID value. The value can also take the value of the snmpEngineID of a remote SNMP engine with which this user can communicate. Blumenthal & Wijnen Standards Track [Page 41] RFC 3414 USM for SNMPv3 December 2002 " ::= { usmUserEntry 1 } usmUserName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A human readable string representing the name of the user. This is the (User-based Security) Model dependent security ID. " ::= { usmUserEntry 2 } usmUserSecurityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable string representing the user in Security Model independent format. The default transformation of the User-based Security Model dependent security ID to the securityName and vice versa is the identity function so that the securityName is the same as the userName. " ::= { usmUserEntry 3 } usmUserCloneFrom OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to another conceptual row in this usmUserTable. The user in this other conceptual row is called the clone-from user. When a new user is created (i.e., a new conceptual row is instantiated in this table), the privacy and authentication parameters of the new user must be cloned from its clone-from user. These parameters are: - authentication protocol (usmUserAuthProtocol) - privacy protocol (usmUserPrivProtocol) They will be copied regardless of what the current value is. Cloning also causes the initial values of the secret authentication key (authKey) and the secret encryption Blumenthal & Wijnen Standards Track [Page 42] RFC 3414 USM for SNMPv3 December 2002 key (privKey) of the new user to be set to the same values as the corresponding secrets of the clone-from user to allow the KeyChange process to occur as required during user creation. The first time an instance of this object is set by a management operation (either at or after its instantiation), the cloning process is invoked. Subsequent writes are successful but invoke no action to be taken by the receiver. The cloning process fails with an 'inconsistentName' error if the conceptual row representing the clone-from user does not exist or is not in an active state when the cloning process is invoked. When this object is read, the ZeroDotZero OID is returned. " ::= { usmUserEntry 4 } usmUserAuthProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, can be authenticated, and if so, the type of authentication protocol which is used. An instance of this object is created concurrently with the creation of any other object instance for the same user (i.e., as part of the processing of the set operation which creates the first object instance in the same conceptual row). If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned. The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom. Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoAuthProtocol. If a set operation tries to change the value of an Blumenthal & Wijnen Standards Track [Page 43] RFC 3414 USM for SNMPv3 December 2002 existing instance of this object to any value other than usmNoAuthProtocol, then an 'inconsistentValue' error must be returned. If a set operation tries to set the value to the usmNoAuthProtocol while the usmUserPrivProtocol value in the same row is not equal to usmNoPrivProtocol, then an 'inconsistentValue' error must be returned. That means that an SNMP command generator application must first ensure that the usmUserPrivProtocol is set to the usmNoPrivProtocol value before it can set the usmUserAuthProtocol value to usmNoAuthProtocol. " DEFVAL { usmNoAuthProtocol } ::= { usmUserEntry 5 } usmUserAuthKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5 -- typically (SIZE (0 | 40)) for HMACSHA MAX-ACCESS read-create STATUS current DESCRIPTION "An object, which when modified, causes the secret authentication key used for messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, to be modified via a one-way function. The associated protocol is the usmUserAuthProtocol. The associated secret key is the user's secret authentication key (authKey). The associated hash algorithm is the algorithm used by the user's usmUserAuthProtocol. When creating a new user, it is an 'inconsistentName' error for a set operation to refer to this object unless it is previously or concurrently initialized through a set operation on the corresponding instance of usmUserCloneFrom. When the value of the corresponding usmUserAuthProtocol is usmNoAuthProtocol, then a set is successful, but effectively is a no-op. When this object is read, the zero-length (empty) string is returned. The recommended way to do a key change is as follows: Blumenthal & Wijnen Standards Track [Page 44] RFC 3414 USM for SNMPv3 December 2002 1) GET(usmUserSpinLock.0) and save in sValue. 2) generate the keyChange value based on the old (existing) secret key and the new secret key, let us call this kcValue. If you do the key change on behalf of another user: 3) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=kcValue usmUserPublic=randomValue) If you do the key change for yourself: 4) SET(usmUserSpinLock.0=sValue, usmUserOwnAuthKeyChange=kcValue usmUserPublic=randomValue) If you get a response with error-status of noError, then the SET succeeded and the new key is active. If you do not get a response, then you can issue a GET(usmUserPublic) and check if the value is equal to the randomValue you did send in the SET. If so, then the key change succeeded and the new key is active (probably the response got lost). If not, then the SET request probably never reached the target and so you can start over with the procedure above. " DEFVAL { ''H } -- the empty string ::= { usmUserEntry 6 } usmUserOwnAuthKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5 -- typically (SIZE (0 | 40)) for HMACSHA MAX-ACCESS read-create STATUS current DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one notable difference: in order for the set operation to succeed, the usmUserName of the operation requester must match the usmUserName that indexes the row which is targeted by this operation. In addition, the USM security model must be used for this operation. The idea here is that access to this column can be public, since it will only allow a user to change his own secret authentication key (authKey). Note that this can only be done once the row is active. Blumenthal & Wijnen Standards Track [Page 45] RFC 3414 USM for SNMPv3 December 2002 When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned. When a set is received and the security model in use is not USM, then a 'noAccess' error must be returned. " DEFVAL { ''H } -- the empty string ::= { usmUserEntry 7 } usmUserPrivProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, can be protected from disclosure, and if so, the type of privacy protocol which is used. An instance of this object is created concurrently with the creation of any other object instance for the same user (i.e., as part of the processing of the set operation which creates the first object instance in the same conceptual row). If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned. The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom. Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoPrivProtocol. If a set operation tries to change the value of an existing instance of this object to any value other than usmNoPrivProtocol, then an 'inconsistentValue' error must be returned. Note that if any privacy protocol is used, then you must also use an authentication protocol. In other words, if usmUserPrivProtocol is set to anything else than usmNoPrivProtocol, then the corresponding instance of usmUserAuthProtocol cannot have a value of Blumenthal & Wijnen Standards Track [Page 46] RFC 3414 USM for SNMPv3 December 2002 usmNoAuthProtocol. If it does, then an 'inconsistentValue' error must be returned. " DEFVAL { usmNoPrivProtocol } ::= { usmUserEntry 8 } usmUserPrivKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES MAX-ACCESS read-create STATUS current DESCRIPTION "An object, which when modified, causes the secret encryption key used for messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, to be modified via a one-way function. The associated protocol is the usmUserPrivProtocol. The associated secret key is the user's secret privacy key (privKey). The associated hash algorithm is the algorithm used by the user's usmUserAuthProtocol. When creating a new user, it is an 'inconsistentName' error for a set operation to refer to this object unless it is previously or concurrently initialized through a set operation on the corresponding instance of usmUserCloneFrom. When the value of the corresponding usmUserPrivProtocol is usmNoPrivProtocol, then a set is successful, but effectively is a no-op. When this object is read, the zero-length (empty) string is returned. See the description clause of usmUserAuthKeyChange for a recommended procedure to do a key change. " DEFVAL { ''H } -- the empty string ::= { usmUserEntry 9 } usmUserOwnPrivKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES MAX-ACCESS read-create STATUS current DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one notable difference: in order for the Set operation to succeed, the usmUserName of the operation requester must match the usmUserName that indexes Blumenthal & Wijnen Standards Track [Page 47] RFC 3414 USM for SNMPv3 December 2002 the row which is targeted by this operation. In addition, the USM security model must be used for this operation. The idea here is that access to this column can be public, since it will only allow a user to change his own secret privacy key (privKey). Note that this can only be done once the row is active. When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned. When a set is received and the security model in use is not USM, then a 'noAccess' error must be returned. " DEFVAL { ''H } -- the empty string ::= { usmUserEntry 10 } usmUserPublic OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A publicly-readable value which can be written as part of the procedure for changing a user's secret authentication and/or privacy key, and later read to determine whether the change of the secret was effected. " DEFVAL { ''H } -- the empty string ::= { usmUserEntry 11 } usmUserStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' must allow write-access at a minimum to: - usmUserAuthKeyChange, usmUserOwnAuthKeyChange and usmUserPublic for a user who employs authentication, and - usmUserPrivKeyChange, usmUserOwnPrivKeyChange and usmUserPublic for a user who employs privacy. Blumenthal & Wijnen Standards Track [Page 48] RFC 3414 USM for SNMPv3 December 2002 Note that any user who employs authentication or privacy must allow its secret(s) to be updated and thus cannot be 'readOnly'. If an initial set operation tries to set the value to 'readOnly' for a user who employs authentication or privacy, then an 'inconsistentValue' error must be returned. Note that if the value has been previously set (implicit or explicit) to any value, then the rules as defined in the StorageType Textual Convention apply. It is an implementation issue to decide if a SET for a readOnly or permanent row is accepted at all. In some contexts this may make sense, in others it may not. If a SET for a readOnly or permanent row is not accepted at all, then a 'wrongValue' error must be returned. " DEFVAL { nonVolatile } ::= { usmUserEntry 12 } usmUserStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the usmUserStatus column is 'notReady'. In particular, a newly created row for a user who employs authentication, cannot be made active until the corresponding usmUserCloneFrom and usmUserAuthKeyChange have been set. Further, a newly created row for a user who also employs privacy, cannot be made active until the usmUserPrivKeyChange has been set. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified, except for usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange. For these 2 objects, the Blumenthal & Wijnen Standards Track [Page 49] RFC 3414 USM for SNMPv3 December 2002 value of usmUserStatus MUST be active. " ::= { usmUserEntry 13 } -- Conformance Information ******************************************* usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 } usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 } -- Compliance statements usmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-USER-BASED-SM-MIB. " MODULE -- this module MANDATORY-GROUPS { usmMIBBasicGroup } OBJECT usmUserAuthProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT usmUserPrivProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { usmMIBCompliances 1 } -- Units of compliance usmMIBBasicGroup OBJECT-GROUP OBJECTS { usmStatsUnsupportedSecLevels, usmStatsNotInTimeWindows, usmStatsUnknownUserNames, usmStatsUnknownEngineIDs, usmStatsWrongDigests, usmStatsDecryptionErrors, usmUserSpinLock, usmUserSecurityName, usmUserCloneFrom, usmUserAuthProtocol, usmUserAuthKeyChange, usmUserOwnAuthKeyChange, usmUserPrivProtocol, usmUserPrivKeyChange, usmUserOwnPrivKeyChange, Blumenthal & Wijnen Standards Track [Page 50] RFC 3414 USM for SNMPv3 December 2002 usmUserPublic, usmUserStorageType, usmUserStatus } STATUS current DESCRIPTION "A collection of objects providing for configuration of an SNMP engine which implements the SNMP User-based Security Model. " ::= { usmMIBGroups 1 } END 6. HMAC-MD5-96 Authentication Protocol This section describes the HMAC-MD5-96 authentication protocol. This authentication protocol is the first defined for the User-based Security Model. It uses MD5 hash-function which is described in [RFC1321], in HMAC mode described in [RFC2104], truncating the output to 96 bits. This protocol is identified by usmHMACMD5AuthProtocol. Over time, other authentication protocols may be defined either as a replacement of this protocol or in addition to this protocol. 6.1. Mechanisms - In support of data integrity, a message digest algorithm is required. A digest is calculated over an appropriate portion of an SNMP message and included as part of the message sent to the recipient. - In support of data origin authentication and data integrity, a secret value is prepended to SNMP message prior to computing the digest; the calculated digest is partially inserted into the SNMP message prior to transmission, and the prepended value is not transmitted. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user. 6.1.1. Digest Authentication Mechanism The Digest Authentication Mechanism defined in this memo provides for: - verification of the integrity of a received message, i.e., the message received is the message sent. Blumenthal & Wijnen Standards Track [Page 51] RFC 3414 USM for SNMPv3 December 2002 The integrity of the message is protected by computing a digest over an appropriate portion of the message. The digest is computed by the originator of the message, transmitted with the message, and verified by the recipient of the message. - verification of the user on whose behalf the message was generated. A secret value known only to SNMP engines authorized to generate messages on behalf of a user is used in HMAC mode (see [RFC2104]). It also recommends the hash-function output used as Message Authentication Code, to be truncated. This protocol uses the MD5 [RFC1321] message digest algorithm. A 128-bit MD5 digest is calculated in a special (HMAC) way over the designated portion of an SNMP message and the first 96 bits of this digest is included as part of the message sent to the recipient. The size of the digest carried in a message is 12 octets. The size of the private authentication key (the secret) is 16 octets. For the details see section 6.3. 6.2. Elements of the Digest Authentication Protocol This section contains definitions required to realize the authentication module defined in this section of this memo. 6.2.1. Users Authentication using this authentication protocol makes use of a defined set of userNames. For any user on whose behalf a message must be authenticated at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user. A user and its attributes are defined as follows: A string representing the name of the user. A user's secret key to be used when calculating a digest. It MUST be 16 octets long for MD5. Blumenthal & Wijnen Standards Track [Page 52] RFC 3414 USM for SNMPv3 December 2002 6.2.2. msgAuthoritativeEngineID The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC3411]). The user's (private) authentication key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the authentication process. 6.2.3. SNMP Messages Using this Authentication Protocol Messages using this authentication protocol carry a msgAuthenticationParameters field as part of the msgSecurityParameters. For this protocol, the msgAuthenticationParameters field is the serialized OCTET STRING representing the first 12 octets of the HMAC-MD5-96 output done over the wholeMsg. The digest is calculated over the wholeMsg so if a message is authenticated, that also means that all the fields in the message are intact and have not been tampered with. 6.2.4. Services provided by the HMAC-MD5-96 Authentication Module This section describes the inputs and outputs that the HMAC-MD5-96 Authentication module expects and produces when the User-based Security module calls the HMAC-MD5-96 Authentication module for services. 6.2.4.1. Services for Generating an Outgoing SNMP Message The HMAC-MD5-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used. Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg with the digest inserted at the proper place. The abstract service primitive is: statusInformation = -- success or failure authenticateOutgoingMsg( IN authKey -- secret key for authentication IN wholeMsg -- unauthenticated complete message OUT authenticatedWholeMsg -- complete authenticated message ) Blumenthal & Wijnen Standards Track [Page 53] RFC 3414 USM for SNMPv3 December 2002 The abstract data elements are: statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 16 octets. wholeMsg The message to be authenticated. authenticatedWholeMsg The authenticated message (including inserted digest) on output. Note, that authParameters field is filled by the authentication module and this module and this field should be already present in the wholeMsg before the Message Authentication Code (MAC) is generated. 6.2.4.2. Services for Processing an Incoming SNMP Message The HMAC-MD5-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used. Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg as it was processed. The abstract service primitive is: statusInformation = -- success or failure authenticateIncomingMsg( IN authKey -- secret key for authentication IN authParameters -- as received on the wire IN wholeMsg -- as received on the wire OUT authenticatedWholeMsg -- complete authenticated message ) The abstract data elements are: statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 16 octets. Blumenthal & Wijnen Standards Track [Page 54] RFC 3414 USM for SNMPv3 December 2002 authParameters The authParameters from the incoming message. wholeMsg The message to be authenticated on input and the authenticated message on output. authenticatedWholeMsg The whole message after the authentication check is complete. 6.3. Elements of Procedure This section describes the procedures for the HMAC-MD5-96 authentication protocol. 6.3.1. Processing an Outgoing Message This section describes the procedure followed by an SNMP engine whenever it must authenticate an outgoing message using the usmHMACMD5AuthProtocol. 1) The msgAuthenticationParameters field is set to the serialization, according to the rules in [RFC3417], of an OCTET STRING containing 12 zero octets. 2) From the secret authKey, two keys K1 and K2 are derived: a) extend the authKey to 64 octets by appending 48 zero octets; save it as extendedAuthKey b) obtain IPAD by replicating the octet 0x36 64 times; c) obtain K1 by XORing extendedAuthKey with IPAD; d) obtain OPAD by replicating the octet 0x5C 64 times; e) obtain K2 by XORing extendedAuthKey with OPAD. 3) Prepend K1 to the wholeMsg and calculate MD5 digest over it according to [RFC1321]. 4) Prepend K2 to the result of the step 4 and calculate MD5 digest over it according to [RFC1321]. Take the first 12 octets of the final digest - this is Message Authentication Code (MAC). 5) Replace the msgAuthenticationParameters field with MAC obtained in the step 4. Blumenthal & Wijnen Standards Track [Page 55] RFC 3414 USM for SNMPv3 December 2002 6) The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success. 6.3.2. Processing an Incoming Message This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using the usmHMACMD5AuthProtocol. 1) If the digest received in the msgAuthenticationParameters field is not 12 octets long, then an failure and an errorIndication (authenticationError) is returned to the calling module. 2) The MAC received in the msgAuthenticationParameters field is saved. 3) The digest in the msgAuthenticationParameters field is replaced by the 12 zero octets. 4) From the secret authKey, two keys K1 and K2 are derived: a) extend the authKey to 64 octets by appending 48 zero octets; save it as extendedAuthKey b) obtain IPAD by replicating the octet 0x36 64 times; c) obtain K1 by XORing extendedAuthKey with IPAD; d) obtain OPAD by replicating the octet 0x5C 64 times; e) obtain K2 by XORing extendedAuthKey with OPAD. 5) The MAC is calculated over the wholeMsg: a) prepend K1 to the wholeMsg and calculate the MD5 digest over it; b) prepend K2 to the result of step 5.a and calculate the MD5 digest over it; c) first 12 octets of the result of step 5.b is the MAC. The msgAuthenticationParameters field is replaced with the MAC value that was saved in step 2. Blumenthal & Wijnen Standards Track [Page 56] RFC 3414 USM for SNMPv3 December 2002 6) Then the newly calculated MAC is compared with the MAC saved in step 2. If they do not match, then an failure and an errorIndication (authenticationFailure) is returned to the calling module. 7) The authenticatedWholeMsg and statusInformation indicating success are then returned to the caller. 7. HMAC-SHA-96 Authentication Protocol This section describes the HMAC-SHA-96 authentication protocol. This protocol uses the SHA hash-function which is described in [SHA-NIST], in HMAC mode described in [RFC2104], truncating the output to 96 bits. This protocol is identified by usmHMACSHAAuthProtocol. Over time, other authentication protocols may be defined either as a replacement of this protocol or in addition to this protocol. 7.1. Mechanisms - In support of data integrity, a message digest algorithm is required. A digest is calculated over an appropriate portion of an SNMP message and included as part of the message sent to the recipient. - In support of data origin authentication and data integrity, a secret value is prepended to the SNMP message prior to computing the digest; the calculated digest is then partially inserted into the message prior to transmission. The prepended secret is not transmitted. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user. 7.1.1. Digest Authentication Mechanism The Digest Authentication Mechanism defined in this memo provides for: - verification of the integrity of a received message, i.e., the message received is the message sent. The integrity of the message is protected by computing a digest over an appropriate portion of the message. The digest is computed by the originator of the message, transmitted with the message, and verified by the recipient of the message. Blumenthal & Wijnen Standards Track [Page 57] RFC 3414 USM for SNMPv3 December 2002 - verification of the user on whose behalf the message was generated. A secret value known only to SNMP engines authorized to generate messages on behalf of a user is used in HMAC mode (see [RFC2104]). It also recommends the hash-function output used as Message Authentication Code, to be truncated. This mechanism uses the SHA [SHA-NIST] message digest algorithm. A 160-bit SHA digest is calculated in a special (HMAC) way over the designated portion of an SNMP message and the first 96 bits of this digest is included as part of the message sent to the recipient. The size of the digest carried in a message is 12 octets. The size of the private authentication key (the secret) is 20 octets. For the details see section 7.3. 7.2. Elements of the HMAC-SHA-96 Authentication Protocol This section contains definitions required to realize the authentication module defined in this section of this memo. 7.2.1. Users Authentication using this authentication protocol makes use of a defined set of userNames. For any user on whose behalf a message must be authenticated at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user. A user and its attributes are defined as follows: A string representing the name of the user. A user's secret key to be used when calculating a digest. It MUST be 20 octets long for SHA. 7.2.2. msgAuthoritativeEngineID The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC3411]). The user's (private) authentication key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the authentication process. Blumenthal & Wijnen Standards Track [Page 58] RFC 3414 USM for SNMPv3 December 2002 7.2.3. SNMP Messages Using this Authentication Protocol Messages using this authentication protocol carry a msgAuthenticationParameters field as part of the msgSecurityParameters. For this protocol, the msgAuthenticationParameters field is the serialized OCTET STRING representing the first 12 octets of HMAC-SHA-96 output done over the wholeMsg. The digest is calculated over the wholeMsg so if a message is authenticated, that also means that all the fields in the message are intact and have not been tampered with. 7.2.4. Services Provided by the HMAC-SHA-96 Authentication Module This section describes the inputs and outputs that the HMAC-SHA-96 Authentication module expects and produces when the User-based Security module calls the HMAC-SHA-96 Authentication module for services. 7.2.4.1. Services for Generating an Outgoing SNMP Message HMAC-SHA-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used. Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg with the digest inserted at the proper place. The abstract service primitive is: statusInformation = -- success or failure authenticateOutgoingMsg( IN authKey -- secret key for authentication IN wholeMsg -- unauthenticated complete message OUT authenticatedWholeMsg -- complete authenticated message ) The abstract data elements are: statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 20 octets. Blumenthal & Wijnen Standards Track [Page 59] RFC 3414 USM for SNMPv3 December 2002 wholeMsg The message to be authenticated. authenticatedWholeMsg The authenticated message (including inserted digest) on output. Note, that authParameters field is filled by the authentication module and this field should be already present in the wholeMsg before the Message Authentication Code (MAC) is generated. 7.2.4.2. Services for Processing an Incoming SNMP Message HMAC-SHA-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used. Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg as it was processed. The abstract service primitive is: statusInformation = -- success or failure authenticateIncomingMsg( IN authKey -- secret key for authentication IN authParameters -- as received on the wire IN wholeMsg -- as received on the wire OUT authenticatedWholeMsg -- complete authenticated message ) The abstract data elements are: statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 20 octets. authParameters The authParameters from the incoming message. wholeMsg The message to be authenticated on input and the authenticated message on output. authenticatedWholeMsg The whole message after the authentication check is complete. Blumenthal & Wijnen Standards Track [Page 60] RFC 3414 USM for SNMPv3 December 2002 7.3. Elements of Procedure This section describes the procedures for the HMAC-SHA-96 authentication protocol. 7.3.1. Processing an Outgoing Message This section describes the procedure followed by an SNMP engine whenever it must authenticate an outgoing message using the usmHMACSHAAuthProtocol. 1) The msgAuthenticationParameters field is set to the serialization, according to the rules in [RFC3417], of an OCTET STRING containing 12 zero octets. 2) From the secret authKey, two keys K1 and K2 are derived: a) extend the authKey to 64 octets by appending 44 zero octets; save it as extendedAuthKey b) obtain IPAD by replicating the octet 0x36 64 times; c) obtain K1 by XORing extendedAuthKey with IPAD; d) obtain OPAD by replicating the octet 0x5C 64 times; e) obtain K2 by XORing extendedAuthKey with OPAD. 3) Prepend K1 to the wholeMsg and calculate the SHA digest over it according to [SHA-NIST]. 4) Prepend K2 to the result of the step 4 and calculate SHA digest over it according to [SHA-NIST]. Take the first 12 octets of the final digest - this is Message Authentication Code (MAC). 5) Replace the msgAuthenticationParameters field with MAC obtained in the step 5. 6) The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success. 7.3.2. Processing an Incoming Message This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using the usmHMACSHAAuthProtocol. Blumenthal & Wijnen Standards Track [Page 61] RFC 3414 USM for SNMPv3 December 2002 1) If the digest received in the msgAuthenticationParameters field is not 12 octets long, then an failure and an errorIndication (authenticationError) is returned to the calling module. 2) The MAC received in the msgAuthenticationParameters field is saved. 3) The digest in the msgAuthenticationParameters field is replaced by the 12 zero octets. 4) From the secret authKey, two keys K1 and K2 are derived: a) extend the authKey to 64 octets by appending 44 zero octets; save it as extendedAuthKey b) obtain IPAD by replicating the octet 0x36 64 times; c) obtain K1 by XORing extendedAuthKey with IPAD; d) obtain OPAD by replicating the octet 0x5C 64 times; e) obtain K2 by XORing extendedAuthKey with OPAD. 5) The MAC is calculated over the wholeMsg: a) prepend K1 to the wholeMsg and calculate the SHA digest over it; b) prepend K2 to the result of step 5.a and calculate the SHA digest over it; c) first 12 octets of the result of step 5.b is the MAC. The msgAuthenticationParameters field is replaced with the MAC value that was saved in step 2. 6) The the newly calculated MAC is compared with the MAC saved in step 2. If they do not match, then a failure and an errorIndication (authenticationFailure) are returned to the calling module. 7) The authenticatedWholeMsg and statusInformation indicating success are then returned to the caller. Blumenthal & Wijnen Standards Track [Page 62] RFC 3414 USM for SNMPv3 December 2002 8. CBC-DES Symmetric Encryption Protocol This section describes the CBC-DES Symmetric Encryption Protocol. This protocol is the first privacy protocol defined for the User-based Security Model. This protocol is identified by usmDESPrivProtocol. Over time, other privacy protocols may be defined either as a replacement of this protocol or in addition to this protocol. 8.1. Mechanisms - In support of data confidentiality, an encryption algorithm is required. An appropriate portion of the message is encrypted prior to being transmitted. The User-based Security Model specifies that the scopedPDU is the portion of the message that needs to be encrypted. - A secret value in combination with a timeliness value is used to create the en/decryption key and the initialization vector. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user. 8.1.1. Symmetric Encryption Protocol The Symmetric Encryption Protocol defined in this memo provides support for data confidentiality. The designated portion of an SNMP message is encrypted and included as part of the message sent to the recipient. Two organizations have published specifications defining the DES: the National Institute of Standards and Technology (NIST) [DES-NIST] and the American National Standards Institute [DES-ANSI]. There is a companion Modes of Operation specification for each definition ([DESO-NIST] and [DESO-ANSI], respectively). The NIST has published three additional documents that implementors may find useful. - There is a document with guidelines for implementing and using the DES, including functional specifications for the DES and its modes of operation [DESG-NIST]. - There is a specification of a validation test suite for the DES [DEST-NIST]. The suite is designed to test all aspects of the DES and is useful for pinpointing specific problems. Blumenthal & Wijnen Standards Track [Page 63] RFC 3414 USM for SNMPv3 December 2002 - There is a specification of a maintenance test for the DES [DESM- NIST]. The test utilizes a minimal amount of data and processing to test all components of the DES. It provides a simple yes-or-no indication of correct operation and is useful to run as part of an initialization step, e.g., when a computer re-boots. 8.1.1.1. DES key and Initialization Vector The first 8 octets of the 16-octet secret (private privacy key) are used as a DES key. Since DES uses only 56 bits, the Least Significant Bit in each octet is disregarded. The Initialization Vector for encryption is obtained using the following procedure. The last 8 octets of the 16-octet secret (private privacy key) are used as pre-IV. In order to ensure that the IV for two different packets encrypted by the same key, are not the same (i.e., the IV does not repeat) we need to "salt" the pre-IV with something unique per packet. An 8-octet string is used as the "salt". The concatenation of the generating SNMP engine's 32-bit snmpEngineBoots and a local 32-bit integer, that the encryption engine maintains, is input to the "salt". The 32-bit integer is initialized to an arbitrary value at boot time. The 32-bit snmpEngineBoots is converted to the first 4 octets (Most Significant Byte first) of our "salt". The 32-bit integer is then converted to the last 4 octet (Most Significant Byte first) of our "salt". The resulting "salt" is then XOR-ed with the pre-IV to obtain the IV. The 8-octet "salt" is then put into the privParameters field encoded as an OCTET STRING. The "salt" integer is then modified. We recommend that it be incremented by one and wrap when it reaches the maximum value. How exactly the value of the "salt" (and thus of the IV) varies, is an implementation issue, as long as the measures are taken to avoid producing a duplicate IV. The "salt" must be placed in the privParameters field to enable the receiving entity to compute the correct IV and to decrypt the message. Blumenthal & Wijnen Standards Track [Page 64] RFC 3414 USM for SNMPv3 December 2002 8.1.1.2. Data Encryption The data to be encrypted is treated as sequence of octets. Its length should be an integral multiple of 8 - and if it is not, the data is padded at the end as necessary. The actual pad value is irrelevant. The data is encrypted in Cipher Block Chaining mode. The plaintext is divided into 64-bit blocks. The plaintext for each block is XOR-ed with the ciphertext of the previous block, the result is encrypted and the output of the encryption is the ciphertext for the block. This procedure is repeated until there are no more plaintext blocks. For the very first block, the Initialization Vector is used instead of the ciphertext of the previous block. 8.1.1.3. Data Decryption Before decryption, the encrypted data length is verified. If the length of the OCTET STRING to be decrypted is not an integral multiple of 8 octets, the decryption process is halted and an appropriate exception noted. When decrypting, the padding is ignored. The first ciphertext block is decrypted, the decryption output is XOR-ed with the Initialization Vector, and the result is the first plaintext block. For each subsequent block, the ciphertext block is decrypted, the decryption output is XOR-ed with the previous ciphertext block and the result is the plaintext block. 8.2. Elements of the DES Privacy Protocol This section contains definitions required to realize the privacy module defined by this memo. 8.2.1. Users Data en/decryption using this Symmetric Encryption Protocol makes use of a defined set of userNames. For any user on whose behalf a message must be en/decrypted at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes Blumenthal & Wijnen Standards Track [Page 65] RFC 3414 USM for SNMPv3 December 2002 to communicate with another SNMP engine must also have knowledge of a user known to that SNMP engine, including knowledge of the applicable attributes of that user. A user and its attributes are defined as follows: An octet string representing the name of the user. A user's secret key to be used as input for the DES key and IV. The length of this key MUST be 16 octets. 8.2.2. msgAuthoritativeEngineID The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC3411]). The user's (private) privacy key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the en/decryption process. 8.2.3. SNMP Messages Using this Privacy Protocol Messages using this privacy protocol carry a msgPrivacyParameters field as part of the msgSecurityParameters. For this protocol, the msgPrivacyParameters field is the serialized OCTET STRING representing the "salt" that was used to create the IV. 8.2.4. Services Provided by the DES Privacy Module This section describes the inputs and outputs that the DES Privacy module expects and produces when the User-based Security module invokes the DES Privacy module for services. 8.2.4.1. Services for Encrypting Outgoing Data This DES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used. Upon completion the privacy module returns statusInformation and, if the encryption process was successful, the encryptedPDU and the msgPrivacyParameters encoded as an OCTET STRING. The abstract service primitive is: Blumenthal & Wijnen Standards Track [Page 66] RFC 3414 USM for SNMPv3 December 2002 statusInformation = -- success of failure encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU) OUT encryptedData -- encrypted data (encryptedPDU) OUT privParameters -- filled in by service provider ) The abstract data elements are: statusInformation An indication of the success or failure of the encryption process. In case of failure, it is an indication of the error. encryptKey The secret key to be used by the encryption algorithm. The length of this key MUST be 16 octets. dataToEncrypt The data that must be encrypted. encryptedData The encrypted data upon successful completion. privParameters The privParameters encoded as an OCTET STRING. 8.2.4.2. Services for Decrypting Incoming Data This DES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used. Upon completion the privacy module returns statusInformation and, if the decryption process was successful, the scopedPDU in plain text. The abstract service primitive is: statusInformation = decryptData( IN decryptKey -- secret key for decryption IN privParameters -- as received on the wire IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) ) Blumenthal & Wijnen Standards Track [Page 67] RFC 3414 USM for SNMPv3 December 2002 The abstract data elements are: statusInformation An indication whether the data was successfully decrypted and if not an indication of the error. decryptKey The secret key to be used by the decryption algorithm. The length of this key MUST be 16 octets. privParameters The "salt" to be used to calculate the IV. encryptedData The data to be decrypted. decryptedData The decrypted data. 8.3. Elements of Procedure. This section describes the procedures for the DES privacy protocol. 8.3.1. Processing an Outgoing Message This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usmDESPrivProtocol. 1) The secret cryptKey is used to construct the DES encryption key, the "salt" and the DES pre-IV (from which the IV is computed as described in section 8.1.1.1). 2) The privParameters field is set to the serialization according to the rules in [RFC3417] of an OCTET STRING representing the "salt" string. 3) The scopedPDU is encrypted (as described in section 8.1.1.2) and the encrypted data is serialized according to the rules in [RFC3417] as an OCTET STRING. 4) The serialized OCTET STRING representing the encrypted scopedPDU together with the privParameters and statusInformation indicating success is returned to the calling module. Blumenthal & Wijnen Standards Track [Page 68] RFC 3414 USM for SNMPv3 December 2002 8.3.2. Processing an Incoming Message This section describes the procedure followed by an SNMP engine whenever it must decrypt part of an incoming message using the usmDESPrivProtocol. 1) If the privParameters field is not an 8-octet OCTET STRING, then an error indication (decryptionError) is returned to the calling module. 2) The "salt" is extracted from the privParameters field. 3) The secret cryptKey and the "salt" are then used to construct the DES decryption key and pre-IV (from which the IV is computed as described in section 8.1.1.1). 4) The encryptedPDU is then decrypted (as described in section 8.1.1.3). 5) If the encryptedPDU cannot be decrypted, then an error indication (decryptionError) is returned to the calling module. 6) The decrypted scopedPDU and statusInformation indicating success are returned to the calling module. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Blumenthal & Wijnen Standards Track [Page 69] RFC 3414 USM for SNMPv3 December 2002 10. Acknowledgements This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members: Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation)) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T.J. Watson Research Center) Blumenthal & Wijnen Standards Track [Page 70] RFC 3414 USM for SNMPv3 December 2002 The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were: David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center) As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) 11. Security Considerations 11.1. Recommended Practices This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo. - An SNMP engine must discard SNMP Response messages that do not correspond to any currently outstanding Request message. It is the responsibility of the Message Processing module to take care of this. For example it can use a msgID for that. An SNMP Command Generator Application must discard any Response Class PDU for which there is no currently outstanding Confirmed Class PDU; for example for SNMPv2 [RFC3416] PDUs, the request-id component in the PDU can be used to correlate Responses to outstanding Requests. Blumenthal & Wijnen Standards Track [Page 71] RFC 3414 USM for SNMPv3 December 2002 Although it would be typical for an SNMP engine and an SNMP Command Generator Application to do this as a matter of course, when using these security protocols it is significant due to the possibility of message duplication (malicious or otherwise). - If an SNMP engine uses a msgID for correlating Response messages to outstanding Request messages, then it MUST use different msgIDs in all such Request messages that it sends out during a Time Window (150 seconds) period. A Command Generator or Notification Originator Application MUST use different request-ids in all Request PDUs that it sends out during a TimeWindow (150 seconds) period. This must be done to protect against the possibility of message duplication (malicious or otherwise). For example, starting operations with a msgID and/or request-id value of zero is not a good idea. Initializing them with an unpredictable number (so they do not start out the same after each reboot) and then incrementing by one would be acceptable. - An SNMP engine should perform time synchronization using authenticated messages in order to protect against the possibility of message duplication (malicious or otherwise). - When sending state altering messages to a managed authoritative SNMP engine, a Command Generator Application should delay sending successive messages to that managed SNMP engine until a positive acknowledgement is received for the previous message or until the previous message expires. No message ordering is imposed by the SNMP. Messages may be received in any order relative to their time of generation and each will be processed in the ordered received. Note that when an authenticated message is sent to a managed SNMP engine, it will be valid for a period of time of approximately 150 seconds under normal circumstances, and is subject to replay during this period. Indeed, an SNMP engine and SNMP Command Generator Applications must cope with the loss and re-ordering of messages resulting from anomalies in the network as a matter of course. However, a managed object, snmpSetSerialNo [RFC3418], is specifically defined for use with SNMP Set operations in order to provide a mechanism to ensure that the processing of SNMP messages occurs in a specific order. Blumenthal & Wijnen Standards Track [Page 72] RFC 3414 USM for SNMPv3 December 2002 - The frequency with which the secrets of a User-based Security Model user should be changed is indirectly related to the frequency of their use. Protecting the secrets from disclosure is critical to the overall security of the protocols. Frequent use of a secret provides a continued source of data that may be useful to a cryptanalyst in exploiting known or perceived weaknesses in an algorithm. Frequent changes to the secret avoid this vulnerability. Changing a secret after each use is generally regarded as the most secure practice, but a significant amount of overhead may be associated with that approach. Note, too, in a local environment the threat of disclosure may be less significant, and as such the changing of secrets may be less frequent. However, when public data networks are used as the communication paths, more caution is prudent. 11.2 Defining Users The mechanisms defined in this document employ the notion of users on whose behalf messages are sent. How "users" are defined is subject to the security policy of the network administration. For example, users could be individuals (e.g., "joe" or "jane"), or a particular role (e.g., "operator" or "administrator"), or a combination (e.g., "joe-operator", "jane-operator" or "joe-admin"). Furthermore, a user may be a logical entity, such as an SNMP Application or a set of SNMP Applications, acting on behalf of an individual or role, or set of individuals, or set of roles, including combinations. Appendix A describes an algorithm for mapping a user "password" to a 16/20 octet value for use as either a user's authentication key or privacy key (or both). Note however, that using the same password (and therefore the same key) for both authentication and privacy is very poor security practice and should be strongly discouraged. Passwords are often generated, remembered, and input by a human. Human-generated passwords may be less than the 16/20 octets required by the authentication and privacy protocols, and brute force attacks can be quite easy on a relatively short ASCII character set. Therefore, the algorithm is Appendix A performs a transformation on the password. If the Appendix A algorithm is used, SNMP implementations (and SNMP configuration applications) must ensure that passwords are at least 8 characters in length. Please note that longer passwords with repetitive strings may result in exactly the same key. For example, a password 'bertbert' will result in exactly the same key as password 'bertbertbert'. Blumenthal & Wijnen Standards Track [Page 73] RFC 3414 USM for SNMPv3 December 2002 Because the Appendix A algorithm uses such passwords (nearly) directly, it is very important that they not be easily guessed. It is suggested that they be composed of mixed-case alphanumeric and punctuation characters that don't form words or phrases that might be found in a dictionary. Longer passwords improve the security of the system. Users may wish to input multiword phrases to make their password string longer while ensuring that it is memorable. Since it is infeasible for human users to maintain different passwords for every SNMP engine, but security requirements strongly discourage having the same key for more than one SNMP engine, the User-based Security Model employs a compromise proposed in [Localized-key]. It derives the user keys for the SNMP engines from user's password in such a way that it is practically impossible to either determine the user's password, or user's key for another SNMP engine from any combination of user's keys on SNMP engines. Note however, that if user's password is disclosed, then key localization will not help and network security may be compromised in this case. Therefore a user's password or non-localized key MUST NOT be stored on a managed device/node. Instead the localized key SHALL be stored (if at all), so that, in case a device does get compromised, no other managed or managing devices get compromised. 11.3. Conformance To be termed a "Secure SNMP implementation" based on the User-based Security Model, an SNMP implementation MUST: - implement one or more Authentication Protocol(s). The HMAC-MD5-96 and HMAC-SHA-96 Authentication Protocols defined in this memo are examples of such protocols. - to the maximum extent possible, prohibit access to the secret(s) of each user about which it maintains information in a Local Configuration Datastore (LCD) under all circumstances except as required to generate and/or validate SNMP messages with respect to that user. - implement the key-localization mechanism. - implement the SNMP-USER-BASED-SM-MIB. In addition, an authoritative SNMP engine SHOULD provide initial configuration in accordance with Appendix A.1. Implementation of a Privacy Protocol (the DES Symmetric Encryption Protocol defined in this memo is one such protocol) is optional. Blumenthal & Wijnen Standards Track [Page 74] RFC 3414 USM for SNMPv3 December 2002 11.4. Use of Reports The use of unsecure reports (i.e., sending them with a securityLevel of noAuthNoPriv) potentially exposes a non-authoritative SNMP engine to some form of attacks. Some people consider these denial of service attacks, others don't. An installation should evaluate the risk involved before deploying unsecure Report PDUs. 11.5 Access to the SNMP-USER-BASED-SM-MIB The objects in this MIB may be considered sensitive in many environments. Specifically the objects in the usmUserTable contain information about users and their authentication and privacy protocols. It is important to closely control (both read and write) access to these MIB objects by using appropriately configured Access Control models (for example the View-based Access Control Model as specified in [RFC3415]). 12. References 12.1 Normative References [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Blumenthal & Wijnen Standards Track [Page 75] RFC 3414 USM for SNMPv3 December 2002 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View- based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [DES-NIST] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988). [DESO-NIST] DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980). [SHA-NIST] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.ps (Postscript) Blumenthal & Wijnen Standards Track [Page 76] RFC 3414 USM for SNMPv3 December 2002 12.1 Informative References [Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen "Key Derivation for Network Management Applications" IEEE Network Magazine, April/May issue, 1997. [DES-ANSI] Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980). [DESO-ANSI] Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106- 1983, (May 1983). [DESG-NIST] Guidelines for Implementing and Using the NBS Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 74, (April, 1981). [DEST-NIST] Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-20. [DESM-NIST] Maintenance Testing for the Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-61, (August, 1980). [RFC3174] Eastlake, D. 3rd and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. Blumenthal & Wijnen Standards Track [Page 77] RFC 3414 USM for SNMPv3 December 2002 APPENDIX A - Installation A.1. SNMP engine Installation Parameters During installation, an authoritative SNMP engine SHOULD (in the meaning as defined in [RFC2119]) be configured with several initial parameters. These include: 1) A Security Posture The choice of security posture determines if initial configuration is implemented and if so how. One of three possible choices is selected: minimum-secure, semi-secure, very-secure (i.e., no-initial-configuration) In the case of a very-secure posture, there is no initial configuration, and so the following steps are irrelevant. 2) One or More Secrets These are the authentication/privacy secrets for the first user to be configured. One way to accomplish this is to have the installer enter a "password" for each required secret. The password is then algorithmically converted into the required secret by: - forming a string of length 1,048,576 octets by repeating the value of the password as often as necessary, truncating accordingly, and using the resulting string as the input to the MD5 algorithm [RFC1321]. The resulting digest, termed "digest1", is used in the next step. - a second string is formed by concatenating digest1, the SNMP engine's snmpEngineID value, and digest1. This string is used as input to the MD5 algorithm [RFC1321]. The resulting digest is the required secret (see Appendix A.2). Blumenthal & Wijnen Standards Track [Page 78] RFC 3414 USM for SNMPv3 December 2002 With these configured parameters, the SNMP engine instantiates the following usmUserEntry in the usmUserTable: no privacy support privacy support ------------------ --------------- usmUserEngineID localEngineID localEngineID usmUserName "initial" "initial" usmUserSecurityName "initial" "initial" usmUserCloneFrom ZeroDotZero ZeroDotZero usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol usmUserAuthKeyChange "" "" usmUserOwnAuthKeyChange "" "" usmUserPrivProtocol none usmDESPrivProtocol usmUserPrivKeyChange "" "" usmUserOwnPrivKeyChange "" "" usmUserPublic "" "" usmUserStorageType anyValidStorageType anyValidStorageType usmUserStatus active active It is recommended to also instantiate a set of template usmUserEntries which can be used as clone-from users for newly created usmUserEntries. These are the two suggested entries: no privacy support privacy support ------------------ --------------- usmUserEngineID localEngineID localEngineID usmUserName "templateMD5" "templateMD5" usmUserSecurityName "templateMD5" "templateMD5" usmUserCloneFrom ZeroDotZero ZeroDotZero usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol usmUserAuthKeyChange "" "" usmUserOwnAuthKeyChange "" "" usmUserPrivProtocol none usmDESPrivProtocol usmUserPrivKeyChange "" "" usmUserOwnPrivKeyChange "" "" usmUserPublic "" "" usmUserStorageType permanent permanent usmUserStatus active active Blumenthal & Wijnen Standards Track [Page 79] RFC 3414 USM for SNMPv3 December 2002 no privacy support privacy support ------------------ --------------- usmUserEngineID localEngineID localEngineID usmUserName "templateSHA" "templateSHA" usmUserSecurityName "templateSHA" "templateSHA" usmUserCloneFrom ZeroDotZero ZeroDotZero usmUserAuthProtocol usmHMACSHAAuthProtocol usmHMACSHAAuthProtocol usmUserAuthKeyChange "" "" usmUserOwnAuthKeyChange "" "" usmUserPrivProtocol none usmDESPrivProtocol usmUserPrivKeyChange "" "" usmUserOwnPrivKeyChange "" "" usmUserPublic "" "" usmUserStorageType permanent permanent usmUserStatus active active A.2. Password to Key Algorithm A sample code fragment (section A.2.1) demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key using MD5. The reference source code of MD5 is available in [RFC1321]. Another sample code fragment (section A.2.2) demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key using SHA (documented in SHA- NIST). An example of the results of a correct implementation is provided (section A.3) which an implementor can use to check if his implementation produces the same result. Blumenthal & Wijnen Standards Track [Page 80] RFC 3414 USM for SNMPv3 December 2002 A.2.1. Password to Key Sample Code for MD5 void password_to_key_md5( u_char *password, /* IN */ u_int passwordlen, /* IN */ u_char *engineID, /* IN - pointer to snmpEngineID */ u_int engineLength,/* IN - length of snmpEngineID */ u_char *key) /* OUT - pointer to caller 16-octet buffer */ { MD5_CTX MD; u_char *cp, password_buf[64]; u_long password_index = 0; u_long count = 0, i; MD5Init (&MD); /* initialize MD5 */ /**********************************************/ /* Use while loop until we've done 1 Megabyte */ /**********************************************/ while (count < 1048576) { cp = password_buf; for (i = 0; i < 64; i++) { /*************************************************/ /* Take the next octet of the password, wrapping */ /* to the beginning of the password as necessary.*/ /*************************************************/ *cp++ = password[password_index++ % passwordlen]; } MD5Update (&MD, password_buf, 64); count += 64; } MD5Final (key, &MD); /* tell MD5 we're done */ /*****************************************************/ /* Now localize the key with the engineID and pass */ /* through MD5 to produce final key */ /* May want to ensure that engineLength <= 32, */ /* otherwise need to use a buffer larger than 64 */ /*****************************************************/ memcpy(password_buf, key, 16); memcpy(password_buf+16, engineID, engineLength); memcpy(password_buf+16+engineLength, key, 16); MD5Init(&MD); MD5Update(&MD, password_buf, 32+engineLength); MD5Final(key, &MD); return; } Blumenthal & Wijnen Standards Track [Page 81] RFC 3414 USM for SNMPv3 December 2002 A.2.2. Password to Key Sample Code for SHA void password_to_key_sha( u_char *password, /* IN */ u_int passwordlen, /* IN */ u_char *engineID, /* IN - pointer to snmpEngineID */ u_int engineLength,/* IN - length of snmpEngineID */ u_char *key) /* OUT - pointer to caller 20-octet buffer */ { SHA_CTX SH; u_char *cp, password_buf[72]; u_long password_index = 0; u_long count = 0, i; SHAInit (&SH); /* initialize SHA */ /**********************************************/ /* Use while loop until we've done 1 Megabyte */ /**********************************************/ while (count < 1048576) { cp = password_buf; for (i = 0; i < 64; i++) { /*************************************************/ /* Take the next octet of the password, wrapping */ /* to the beginning of the password as necessary.*/ /*************************************************/ *cp++ = password[password_index++ % passwordlen]; } SHAUpdate (&SH, password_buf, 64); count += 64; } SHAFinal (key, &SH); /* tell SHA we're done */ /*****************************************************/ /* Now localize the key with the engineID and pass */ /* through SHA to produce final key */ /* May want to ensure that engineLength <= 32, */ /* otherwise need to use a buffer larger than 72 */ /*****************************************************/ memcpy(password_buf, key, 20); memcpy(password_buf+20, engineID, engineLength); memcpy(password_buf+20+engineLength, key, 20); SHAInit(&SH); SHAUpdate(&SH, password_buf, 40+engineLength); SHAFinal(key, &SH); return; } Blumenthal & Wijnen Standards Track [Page 82] RFC 3414 USM for SNMPv3 December 2002 A.3. Password to Key Sample Results A.3.1. Password to Key Sample Results using MD5 The following shows a sample output of the password to key algorithm for a 16-octet key using MD5. With a password of "maplesyrup" the output of the password to key algorithm before the key is localized with the SNMP engine's snmpEngineID is: '9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H After the intermediate key (shown above) is localized with the snmpEngineID value of: '00 00 00 00 00 00 00 00 00 00 00 02'H the final output of the password to key algorithm is: '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H A.3.2. Password to Key Sample Results using SHA The following shows a sample output of the password to key algorithm for a 20-octet key using SHA. With a password of "maplesyrup" the output of the password to key algorithm before the key is localized with the SNMP engine's snmpEngineID is: '9f b5 cc 03 81 49 7b 37 93 52 89 39 ff 78 8d 5d 79 14 52 11'H After the intermediate key (shown above) is localized with the snmpEngineID value of: '00 00 00 00 00 00 00 00 00 00 00 02'H the final output of the password to key algorithm is: '66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f'H A.4. Sample Encoding of msgSecurityParameters The msgSecurityParameters in an SNMP message are represented as an OCTET STRING. This OCTET STRING should be considered opaque outside a specific Security Model. Blumenthal & Wijnen Standards Track [Page 83] RFC 3414 USM for SNMPv3 December 2002 The User-based Security Model defines the contents of the OCTET STRING as a SEQUENCE (see section 2.4). Given these two properties, the following is an example of they msgSecurityParameters for the User-based Security Model, encoded as an OCTET STRING: 04 30 04 02 02 04 04 0c 04 08 Here is the example once more, but now with real values (except for the digest in msgAuthenticationParameters and the salt in msgPrivacyParameters, which depend on variable data that we have not defined here): Hex Data Description -------------- ----------------------------------------------- 04 39 OCTET STRING, length 57 30 37 SEQUENCE, length 55 04 0c 80000002 msgAuthoritativeEngineID: IBM 01 IPv4 address 09840301 9.132.3.1 02 01 01 msgAuthoritativeEngineBoots: 1 02 02 0101 msgAuthoritativeEngineTime: 257 04 04 62657274 msgUserName: bert 04 0c 01234567 msgAuthenticationParameters: sample value 89abcdef fedcba98 04 08 01234567 msgPrivacyParameters: sample value 89abcdef A.5. Sample keyChange Results A.5.1. Sample keyChange Results using MD5 Let us assume that a user has a current password of "maplesyrup" as in section A.3.1. and let us also assume the snmpEngineID of 12 octets: '00 00 00 00 00 00 00 00 00 00 00 02'H Blumenthal & Wijnen Standards Track [Page 84] RFC 3414 USM for SNMPv3 December 2002 If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows: '01 ad d2 73 10 7c 4e 59 6b 4b 00 f8 2b 1d 42 a7'H If we localize it for the above snmpEngineID, then the localized new key becomes: '87 02 1d 7b d9 d1 01 ba 05 ea 6e 3b f9 d9 bd 4a'H If we then use a (not so good, but easy to test) random value of: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H Then the value we must send for keyChange is: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 05 61 51 41 67 6c c9 19 61 74 e7 42 a3 25 51'H If this were for the privacy key, then it would be exactly the same. A.5.2. Sample keyChange Results using SHA Let us assume that a user has a current password of "maplesyrup" as in section A.3.2. and let us also assume the snmpEngineID of 12 octets: '00 00 00 00 00 00 00 00 00 00 00 02'H If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows: '3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H If we localize it for the above snmpEngineID, then the localized new key becomes: '78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 91 f1 cd 25'H If we then use a (not so good, but easy to test) random value of: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H Then the value we must send for keyChange is: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c 10 17 f4 fd 48 3d 2d e8 d5 fa db f8 43 92 cb 06 45 70 51' Blumenthal & Wijnen Standards Track [Page 85] RFC 3414 USM for SNMPv3 December 2002 For the key used for privacy, the new nonlocalized key would be: '3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H For the key used for privacy, the new localized key would be (note that they localized key gets truncated to 16 octets for DES): '78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63'H If we then use a (not so good, but easy to test) random value of: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H Then the value we must send for keyChange for the privacy key is: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '7e f8 d8 a4 c9 cd b2 6b 47 59 1c d8 52 ff 88 b5'H B. Change Log Changes made since RFC2574: - Updated references - Updated contact info - Clarifications - to first constraint item 1) on page 6. - to usmUserCloneFrom DESCRIPTION clause - to securityName in section 2.1 - Fixed "command responder" into "command generator" in last para of DESCRIPTION clause of usmUserTable. Changes made since RFC2274: - Fixed msgUserName to allow size of zero and explain that this can be used for snmpEngineID discovery. - Clarified section 3.1 steps 4.b, 5, 6 and 8.b. - Clarified section 3.2 paragraph 2. - Clarified section 3.2 step 7.a last paragraph, step 7.b.1 second bullet and step 7.b.2 third bullet. - Clarified section 4 to indicate that discovery can use a userName of zero length in unAuthenticated messages, whereas a valid userName must be used in authenticated messages. - Added REVISION clauses to MODULE-IDENTITY - Clarified KeyChange TC by adding a note that localized keys must be used when calculating a KeyChange value. - Added clarifying text to the DESCRIPTION clause of usmUserTable. Added text describes a recommended procedure for adding a new user. - Clarified the use of usmUserCloneFrom object. Blumenthal & Wijnen Standards Track [Page 86] RFC 3414 USM for SNMPv3 December 2002 - Clarified how and under which conditions the usmUserAuthProtocol and usmUserPrivProtocol can be initialized and/or changed. - Added comment on typical sizes for usmUserAuthKeyChange and usmUserPrivKeyChange. Also for usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange. - Added clarifications to the DESCRIPTION clauses of usmUserAuthKeyChange, usmUserOwnAuthKeychange, usmUserPrivKeyChange and usmUserOwnPrivKeychange. - Added clarification to DESCRIPTION clause of usmUserStorageType. - Added clarification to DESCRIPTION clause of usmUserStatus. - Clarified IV generation procedure in section 8.1.1.1 and in addition clarified section 8.3.1 step 1 and section 8.3.2. step 3. - Clarified section 11.2 and added a warning that different size passwords with repetitive strings may result in same key. - Added template users to appendix A for cloning process. - Fixed C-code examples in Appendix A. - Fixed examples of generated keys in Appendix A. - Added examples of KeyChange values to Appendix A. - Used PDU Classes instead of RFC1905 PDU types. - Added text in the security section about Reports and Access Control to the MIB. - Removed a incorrect note at the end of section 3.2 step 7. - Added a note in section 3.2 step 3. - Corrected various spelling errors and typos. - Corrected procedure for 3.2 step 2.a) - various clarifications. - Fixed references to new/revised documents - Change to no longer cache data that is not used Editors' Addresses Uri Blumenthal Lucent Technologies 67 Whippany Rd. Whippany, NJ 07981 USA Phone: +1-973-386-2163 EMail: uri@lucent.com Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Phone: +31-348-480-685 EMail: bwijnen@lucent.com Blumenthal & Wijnen Standards Track [Page 87] RFC 3414 USM for SNMPv3 December 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Blumenthal & Wijnen Standards Track [Page 88] snmp-mibs-downloader-1.1/mibrfcs/rfc3415.txt0000644000000000000000000024017611402176071015570 0ustar Network Working Group B. Wijnen Request for Comments: 3415 Lucent Technologies STD: 62 R. Presuhn Obsoletes: 2575 BMC Software, Inc. Category: Standards Track K. McCloghrie Cisco Systems, Inc. December 2002 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View-based Access Control Model. This document obsoletes RFC 2575. Wijnen, et al. Standards Track [Page 1] RFC 3415 VACM for the SNMP December 2002 Table of Contents 1. Introduction ................................................. 2 1.2. Access Control ............................................. 3 1.3. Local Configuration Datastore .............................. 3 2. Elements of the Model ........................................ 4 2.1. Groups ..................................................... 4 2.2. securityLevel .............................................. 4 2.3. Contexts ................................................... 4 2.4. MIB Views and View Families ................................ 5 2.4.1. View Subtree ............................................. 5 2.4.2. ViewTreeFamily ........................................... 6 2.5. Access Policy .............................................. 6 3. Elements of Procedure ........................................ 7 3.1. Overview of isAccessAllowed Process ....................... 8 3.2. Processing the isAccessAllowed Service Request ............. 9 4. Definitions .................................................. 11 5. Intellectual Property ........................................ 28 6. Acknowledgements ............................................. 28 7. Security Considerations ...................................... 30 7.1. Recommended Practices ...................................... 30 7.2. Defining Groups ............................................ 30 7.3. Conformance ................................................ 31 7.4. Access to the SNMP-VIEW-BASED-ACM-MIB ...................... 31 8. References ................................................... 31 A. Installation ................................................. 33 B. Change Log ................................................... 36 Editors' Addresses ............................................... 38 Full Copyright Statement ......................................... 39 1. Introduction The Architecture for describing Internet Management Frameworks [RFC3411] describes that an SNMP engine is composed of: 1) a Dispatcher 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem. Applications make use of the services of these subsystems. It is important to understand the SNMP architecture and its terminology to understand where the View-based Access Control Model described in this document fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description and terminology of the SNMP architecture, as defined in [RFC3411]. Wijnen, et al. Standards Track [Page 2] RFC 3415 VACM for the SNMP December 2002 The Access Control Subsystem of an SNMP engine has the responsibility for checking whether a specific type of access (read, write, notify) to a particular object (instance) is allowed. It is the purpose of this document to define a specific model of the Access Control Subsystem, designated the View-based Access Control Model. Note that this is not necessarily the only Access Control Model. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119. 1.2. Access Control Access Control occurs (either implicitly or explicitly) in an SNMP entity when processing SNMP retrieval or modification request messages from an SNMP entity. For example a Command Responder application applies Access Control when processing requests that it received from a Command Generator application. These requests contain Read Class and Write Class PDUs as defined in [RFC3411]. Access Control also occurs in an SNMP entity when an SNMP notification message is generated (by a Notification Originator application). These notification messages contain Notification Class PDUs as defined in [RFC3411]. The View-based Access Control Model defines a set of services that an application (such as a Command Responder or a Notification Originator application) can use for checking access rights. It is the responsibility of the application to make the proper service calls for access checking. 1.3. Local Configuration Datastore To implement the model described in this document, an SNMP entity needs to retain information about access rights and policies. This information is part of the SNMP engine's Local Configuration Datastore (LCD). See [RFC3411] for the definition of LCD. In order to allow an SNMP entity's LCD to be remotely configured, portions of the LCD need to be accessible as managed objects. A MIB module, the View-based Access Control Model Configuration MIB, which defines these managed object types is included in this document. Wijnen, et al. Standards Track [Page 3] RFC 3415 VACM for the SNMP December 2002 2. Elements of the Model This section contains definitions to realize the access control service provided by the View-based Access Control Model. 2.1. Groups A group is a set of zero or more tuples on whose behalf SNMP management objects can be accessed. A group defines the access rights afforded to all securityNames which belong to that group. The combination of a securityModel and a securityName maps to at most one group. A group is identified by a groupName. The Access Control module assumes that the securityName has already been authenticated as needed and provides no further authentication of its own. The View-based Access Control Model uses the securityModel and the securityName as inputs to the Access Control module when called to check for access rights. It determines the groupName as a function of securityModel and securityName. 2.2. securityLevel Different access rights for members of a group can be defined for different levels of security, i.e., noAuthNoPriv, authNoPriv, and authPriv. The securityLevel identifies the level of security that will be assumed when checking for access rights. See the SNMP Architecture document [RFC3411] for a definition of securityLevel. The View-based Access Control Model requires that the securityLevel is passed as input to the Access Control module when called to check for access rights. 2.3. Contexts An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts. Details about the naming of management information can be found in the SNMP Architecture document [RFC3411]. The View-based Access Control Model defines a vacmContextTable that lists the locally available contexts by contextName. Wijnen, et al. Standards Track [Page 4] RFC 3415 VACM for the SNMP December 2002 2.4. MIB Views and View Families For security reasons, it is often valuable to be able to restrict the access rights of some groups to only a subset of the management information in the management domain. To provide this capability, access to a context is via a "MIB view" which details a specific set of managed object types (and optionally, the specific instances of object types) within that context. For example, for a given context, there will typically always be one MIB view which provides access to all management information in that context, and often there will be other MIB views each of which contains some subset of the information. So, the access allowed for a group can be restricted in the desired manner by specifying its rights in terms of the particular (subset) MIB view it can access within each appropriate context. Since managed object types (and their instances) are identified via the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO- ASN.1, RFC2578], it is convenient to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a subtree within the managed object naming tree. Thus, a simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be defined as a single view subtree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be represented by the union of multiple view subtrees. While any set of managed objects can be described by the union of some number of view subtrees, situations can arise that would require a very large number of view subtrees. This could happen, for example, when specifying all columns in one conceptual row of a MIB table because they would appear in separate subtrees, one per column, each with a very similar format. Because the formats are similar, the required set of subtrees can easily be aggregated into one structure. This structure is named a family of view subtrees after the set of subtrees that it conceptually represents. A family of view subtrees can either be included or excluded from a MIB view. 2.4.1. View Subtree A view subtree is the set of all MIB object instances which have a common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is identified by the OBJECT IDENTIFIER value which is the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree. Wijnen, et al. Standards Track [Page 5] RFC 3415 VACM for the SNMP December 2002 2.4.2. ViewTreeFamily A family of view subtrees is a pairing of an OBJECT IDENTIFIER value (called the family name) together with a bit string value (called the family mask). The family mask indicates which sub-identifiers of the associated family name are significant to the family's definition. For each possible managed object instance, that instance belongs to a particular ViewTreeFamily if both of the following conditions are true: - the OBJECT IDENTIFIER name of the managed object instance contains at least as many sub-identifiers as does the family name, and - each sub-identifier in the OBJECT IDENTIFIER name of the managed object instance matches the corresponding sub-identifier of the family name whenever the corresponding bit of the associated family mask is non-zero. When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name. When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a single view subtree. 2.5. Access Policy The View-based Access Control Model determines the access rights of a group, representing zero or more securityNames which have the same access rights. For a particular context, identified by contextName, to which a group, identified by groupName, has access using a particular securityModel and securityLevel, that group's access rights are given by a read-view, a write-view and a notify-view. The read-view represents the set of object instances authorized for the group when reading objects. Reading objects occurs when processing a retrieval operation (when handling Read Class PDUs). The write-view represents the set of object instances authorized for the group when writing objects. Writing objects occurs when processing a write operation (when handling Write Class PDUs). The notify-view represents the set of object instances authorized for the group when sending objects in a notification, such as when sending a notification (when sending Notification Class PDUs). Wijnen, et al. Standards Track [Page 6] RFC 3415 VACM for the SNMP December 2002 3. Elements of Procedure This section describes the procedures followed by an Access Control module that implements the View-based Access Control Model when checking access rights as requested by an application (for example a Command Responder or a Notification Originator application). The abstract service primitive is: statusInformation = -- success or errorIndication isAccessAllowed( securityModel -- Security Model in use securityName -- principal who wants access securityLevel -- Level of Security viewType -- read, write, or notify view contextName -- context containing variableName variableName -- OID for the managed object ) The abstract data elements are: statusInformation - one of the following: accessAllowed - a MIB view was found and access is granted. notInView - a MIB view was found but access is denied. The variableName is not in the configured MIB view for the specified viewType (e.g., in the relevant entry in the vacmAccessTable). noSuchView - no MIB view found because no view has been configured for specified viewType (e.g., in the relevant entry in the vacmAccessTable). noSuchContext - no MIB view found because of no entry in the vacmContextTable for specified contextName. noGroupName - no MIB view found because no entry has been configured in the vacmSecurityToGroupTable for the specified combination of securityModel and securityName. noAccessEntry - no MIB view found because no entry has been configured in the vacmAccessTable for the specified combination of contextName, groupName (from vacmSecurityToGroupTable), securityModel and securityLevel. otherError - failure, an undefined error occurred. securityModel - Security Model under which access is requested. securityName - the principal on whose behalf access is requested. securityLevel - Level of Security under which access is requested. viewType - view to be checked (read, write or notify). contextName - context in which access is requested. variableName - object instance to which access is requested. Wijnen, et al. Standards Track [Page 7] RFC 3415 VACM for the SNMP December 2002 3.1. Overview of isAccessAllowed Process The following picture shows how the decision for access control is made by the View-based Access Control Model. +--------------------------------------------------------------------+ | | | +-> securityModel -+ | | | (a) | | | who -+ +-> groupName ----+ | | (1) | | (x) | | | +-> securityName --+ | | | (b) | | | | | | where -> contextName ---------------------+ | | (2) (e) | | | | | | | | | +-> securityModel -------------------+ | | | (a) | | | how -+ +-> viewName -+ | | (3) | | (y) | | | +-> securityLevel -------------------+ | | | (c) | +-> yes/no | | | | decision | | why ---> viewType (read/write/notify) ----+ | (z) | | (4) (d) | | | | | | what --> object-type ------+ | | | (5) (m) | | | | +-> variableName (OID) ------+ | | | (f) | | which -> object-instance --+ | | (6) (n) | | | +--------------------------------------------------------------------+ Wijnen, et al. Standards Track [Page 8] RFC 3415 VACM for the SNMP December 2002 How the decision for isAccessAllowed is made. 1) Inputs to the isAccessAllowed service are: (a) securityModel -- Security Model in use (b) securityName -- principal who wants to access (c) securityLevel -- Level of Security (d) viewType -- read, write, or notify view (e) contextName -- context containing variableName (f) variableName -- OID for the managed object -- this is made up of: - object-type (m) - object-instance (n) 2) The partial "who" (1), represented by the securityModel (a) and the securityName (b), are used as the indices (a,b) into the vacmSecurityToGroupTable to find a single entry that produces a group, represented by groupName (x). 3) The "where" (2), represented by the contextName (e), the "who", represented by the groupName (x) from the previous step, and the "how" (3), represented by securityModel (a) and securityLevel (c), are used as indices (e,x,a,c) into the vacmAccessTable to find a single entry that contains three MIB views. 4) The "why" (4), represented by the viewType (d), is used to select the proper MIB view, represented by a viewName (y), from the vacmAccessEntry selected in the previous step. This viewName (y) is an index into the vacmViewTreeFamilyTable and selects the set of entries that define the variableNames which are included in or excluded from the MIB view identified by the viewName (y). 5) The "what" (5) type of management data and "which" (6) particular instance, represented by the variableName (f), is then checked to be in the MIB view or not, e.g., the yes/no decision (z). 3.2. Processing the isAccessAllowed Service Request This section describes the procedure followed by an Access Control module that implements the View-based Access Control Model whenever it receives an isAccessAllowed request. 1) The vacmContextTable is consulted for information about the SNMP context identified by the contextName. If information about this SNMP context is absent from the table, then an errorIndication (noSuchContext) is returned to the calling module. Wijnen, et al. Standards Track [Page 9] RFC 3415 VACM for the SNMP December 2002 2) The vacmSecurityToGroupTable is consulted for mapping the securityModel and securityName to a groupName. If the information about this combination is absent from the table, then an errorIndication (noGroupName) is returned to the calling module. 3) The vacmAccessTable is consulted for information about the groupName, contextName, securityModel and securityLevel. If information about this combination is absent from the table, then an errorIndication (noAccessEntry) is returned to the calling module. 4) a) If the viewType is "read", then the read view is used for checking access rights. b) If the viewType is "write", then the write view is used for checking access rights. c) If the viewType is "notify", then the notify view is used for checking access rights. If the view to be used is the empty view (zero length viewName) then an errorIndication (noSuchView) is returned to the calling module. 5) a) If there is no view configured for the specified viewType, then an errorIndication (noSuchView) is returned to the calling module. b) If the specified variableName (object instance) is not in the MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in section 4), then an errorIndication (notInView) is returned to the calling module. Otherwise, c) The specified variableName is in the MIB view. A statusInformation of success (accessAllowed) is returned to the calling module. Wijnen, et al. Standards Track [Page 10] RFC 3415 VACM for the SNMP December 2002 4. Definitions SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI TestAndIncr, RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpSecurityLevel, SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; snmpVacmMIB MODULE-IDENTITY LAST-UPDATED "200210160000Z" -- 16 Oct 2002, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In message body: subscribe snmpv3 Co-Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA email: mundy@tislabs.com phone: +1 301-947-7107 Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5004 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614 Co-editor: Bert Wijnen Lucent Technologies postal: Schagen 33 3461 GL Linschoten Netherlands email: bwijnen@lucent.com phone: +31-348-480-685 Co-editor: Randy Presuhn BMC Software, Inc. Wijnen, et al. Standards Track [Page 11] RFC 3415 VACM for the SNMP December 2002 postal: 2141 North First Street San Jose, CA 95131 USA email: randy_presuhn@bmc.com phone: +1 408-546-1006 Co-editor: Keith McCloghrie Cisco Systems, Inc. postal: 170 West Tasman Drive San Jose, CA 95134-1706 USA email: kzm@cisco.com phone: +1-408-526-5260 " DESCRIPTION "The management information definitions for the View-based Access Control Model for SNMP. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3415; see the RFC itself for full legal notices. " -- Revision history REVISION "200210160000Z" -- 16 Oct 2002, midnight DESCRIPTION "Clarifications, published as RFC3415" REVISION "199901200000Z" -- 20 Jan 1999, midnight DESCRIPTION "Clarifications, published as RFC2575" REVISION "199711200000Z" -- 20 Nov 1997, midnight DESCRIPTION "Initial version, published as RFC2275" ::= { snmpModules 16 } -- Administrative assignments **************************************** vacmMIBObjects OBJECT IDENTIFIER ::= { snmpVacmMIB 1 } vacmMIBConformance OBJECT IDENTIFIER ::= { snmpVacmMIB 2 } -- Information about Local Contexts ********************************** vacmContextTable OBJECT-TYPE SYNTAX SEQUENCE OF VacmContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of locally available contexts. This table provides information to SNMP Command Wijnen, et al. Standards Track [Page 12] RFC 3415 VACM for the SNMP December 2002 Generator applications so that they can properly configure the vacmAccessTable to control access to all contexts at the SNMP entity. This table may change dynamically if the SNMP entity allows that contexts are added/deleted dynamically (for instance when its configuration changes). Such changes would happen only if the management instrumentation at that SNMP entity recognizes more (or fewer) contexts. The presence of entries in this table and of entries in the vacmAccessTable are independent. That is, a context identified by an entry in this table is not necessarily referenced by any entries in the vacmAccessTable; and the context(s) referenced by an entry in the vacmAccessTable does not necessarily currently exist and thus need not be identified by an entry in this table. This table must be made accessible via the default context so that Command Responder applications have a standard way of retrieving the information. This table is read-only. It cannot be configured via SNMP. " ::= { vacmMIBObjects 1 } vacmContextEntry OBJECT-TYPE SYNTAX VacmContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular context." INDEX { vacmContextName } ::= { vacmContextTable 1 } VacmContextEntry ::= SEQUENCE { vacmContextName SnmpAdminString } vacmContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current Wijnen, et al. Standards Track [Page 13] RFC 3415 VACM for the SNMP December 2002 DESCRIPTION "A human readable name identifying a particular context at a particular SNMP entity. The empty contextName (zero length) represents the default context. " ::= { vacmContextEntry 1 } -- Information about Groups ****************************************** vacmSecurityToGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF VacmSecurityToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maps a combination of securityModel and securityName into a groupName which is used to define an access control policy for a group of principals. " ::= { vacmMIBObjects 2 } vacmSecurityToGroupEntry OBJECT-TYPE SYNTAX VacmSecurityToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table maps the combination of a securityModel and securityName into a groupName. " INDEX { vacmSecurityModel, vacmSecurityName } ::= { vacmSecurityToGroupTable 1 } VacmSecurityToGroupEntry ::= SEQUENCE { vacmSecurityModel SnmpSecurityModel, vacmSecurityName SnmpAdminString, vacmGroupName SnmpAdminString, vacmSecurityToGroupStorageType StorageType, vacmSecurityToGroupStatus RowStatus } vacmSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel(1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Security Model, by which the vacmSecurityName referenced by this entry is provided. Wijnen, et al. Standards Track [Page 14] RFC 3415 VACM for the SNMP December 2002 Note, this object may not take the 'any' (0) value. " ::= { vacmSecurityToGroupEntry 1 } vacmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The securityName for the principal, represented in a Security Model independent format, which is mapped by this entry to a groupName. " ::= { vacmSecurityToGroupEntry 2 } vacmGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the group to which this entry (e.g., the combination of securityModel and securityName) belongs. This groupName is used as index into the vacmAccessTable to select an access control policy. However, a value in this table does not imply that an instance with the value exists in table vacmAccesTable. " ::= { vacmSecurityToGroupEntry 3 } vacmSecurityToGroupStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { vacmSecurityToGroupEntry 4 } vacmSecurityToGroupStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the Wijnen, et al. Standards Track [Page 15] RFC 3415 VACM for the SNMP December 2002 corresponding instance of the vacmSecurityToGroupStatus column is 'notReady'. In particular, a newly created row cannot be made active until a value has been set for vacmGroupName. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { vacmSecurityToGroupEntry 5 } -- Information about Access Rights *********************************** vacmAccessTable OBJECT-TYPE SYNTAX SEQUENCE OF VacmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of access rights for groups. Each entry is indexed by a groupName, a contextPrefix, a securityModel and a securityLevel. To determine whether access is allowed, one entry from this table needs to be selected and the proper viewName from that entry must be used for access control checking. To select the proper entry, follow these steps: 1) the set of possible matches is formed by the intersection of the following sets of entries: the set of entries with identical vacmGroupName the union of these two sets: - the set with identical vacmAccessContextPrefix - the set of entries with vacmAccessContextMatch value of 'prefix' and matching vacmAccessContextPrefix intersected with the union of these two sets: - the set of entries with identical vacmSecurityModel - the set of entries with vacmSecurityModel value of 'any' intersected with the set of entries with vacmAccessSecurityLevel value less than or equal to the requested securityLevel Wijnen, et al. Standards Track [Page 16] RFC 3415 VACM for the SNMP December 2002 2) if this set has only one member, we're done otherwise, it comes down to deciding how to weight the preferences between ContextPrefixes, SecurityModels, and SecurityLevels as follows: a) if the subset of entries with securityModel matching the securityModel in the message is not empty, then discard the rest. b) if the subset of entries with vacmAccessContextPrefix matching the contextName in the message is not empty, then discard the rest c) discard all entries with ContextPrefixes shorter than the longest one remaining in the set d) select the entry with the highest securityLevel Please note that for securityLevel noAuthNoPriv, all groups are really equivalent since the assumption that the securityName has been authenticated does not hold. " ::= { vacmMIBObjects 4 } vacmAccessEntry OBJECT-TYPE SYNTAX VacmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An access right configured in the Local Configuration Datastore (LCD) authorizing access to an SNMP context. Entries in this table can use an instance value for object vacmGroupName even if no entry in table vacmAccessSecurityToGroupTable has a corresponding value for object vacmGroupName. " INDEX { vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel } ::= { vacmAccessTable 1 } VacmAccessEntry ::= SEQUENCE { vacmAccessContextPrefix SnmpAdminString, vacmAccessSecurityModel SnmpSecurityModel, vacmAccessSecurityLevel SnmpSecurityLevel, vacmAccessContextMatch INTEGER, vacmAccessReadViewName SnmpAdminString, vacmAccessWriteViewName SnmpAdminString, Wijnen, et al. Standards Track [Page 17] RFC 3415 VACM for the SNMP December 2002 vacmAccessNotifyViewName SnmpAdminString, vacmAccessStorageType StorageType, vacmAccessStatus RowStatus } vacmAccessContextPrefix OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "In order to gain the access rights allowed by this conceptual row, a contextName must match exactly (if the value of vacmAccessContextMatch is 'exact') or partially (if the value of vacmAccessContextMatch is 'prefix') to the value of the instance of this object. " ::= { vacmAccessEntry 1 } vacmAccessSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel MAX-ACCESS not-accessible STATUS current DESCRIPTION "In order to gain the access rights allowed by this conceptual row, this securityModel must be in use. " ::= { vacmAccessEntry 2 } vacmAccessSecurityLevel OBJECT-TYPE SYNTAX SnmpSecurityLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum level of security required in order to gain the access rights allowed by this conceptual row. A securityLevel of noAuthNoPriv is less than authNoPriv which in turn is less than authPriv. If multiple entries are equally indexed except for this vacmAccessSecurityLevel index, then the entry which has the highest value for vacmAccessSecurityLevel is selected. " ::= { vacmAccessEntry 3 } vacmAccessContextMatch OBJECT-TYPE SYNTAX INTEGER { exact (1), -- exact match of prefix and contextName prefix (2) -- Only match to the prefix } Wijnen, et al. Standards Track [Page 18] RFC 3415 VACM for the SNMP December 2002 MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is exact(1), then all rows where the contextName exactly matches vacmAccessContextPrefix are selected. If the value of this object is prefix(2), then all rows where the contextName whose starting octets exactly match vacmAccessContextPrefix are selected. This allows for a simple form of wildcarding. " DEFVAL { exact } ::= { vacmAccessEntry 4 } vacmAccessReadViewName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes read access. The identified MIB view is that one for which the vacmViewTreeFamilyViewName has the same value as the instance of this object; if the value is the empty string or if there is no active MIB view having this value of vacmViewTreeFamilyViewName, then no access is granted. " DEFVAL { ''H } -- the empty string ::= { vacmAccessEntry 5 } vacmAccessWriteViewName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes write access. The identified MIB view is that one for which the vacmViewTreeFamilyViewName has the same value as the instance of this object; if the value is the empty string or if there is no active MIB view having this value of vacmViewTreeFamilyViewName, then no access is granted. " DEFVAL { ''H } -- the empty string Wijnen, et al. Standards Track [Page 19] RFC 3415 VACM for the SNMP December 2002 ::= { vacmAccessEntry 6 } vacmAccessNotifyViewName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes access for notifications. The identified MIB view is that one for which the vacmViewTreeFamilyViewName has the same value as the instance of this object; if the value is the empty string or if there is no active MIB view having this value of vacmViewTreeFamilyViewName, then no access is granted. " DEFVAL { ''H } -- the empty string ::= { vacmAccessEntry 7 } vacmAccessStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { vacmAccessEntry 8 } vacmAccessStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { vacmAccessEntry 9 } -- Information about MIB views *************************************** Wijnen, et al. Standards Track [Page 20] RFC 3415 VACM for the SNMP December 2002 -- Support for instance-level granularity is optional. -- -- In some implementations, instance-level access control -- granularity may come at a high performance cost. Managers -- should avoid requesting such configurations unnecessarily. vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 } vacmViewSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating SNMP Command Generator applications to coordinate their use of the Set operation in creating or modifying views. When creating a new view or altering an existing view, it is important to understand the potential interactions with other uses of the view. The vacmViewSpinLock should be retrieved. The name of the view to be created should be determined to be unique by the SNMP Command Generator application by consulting the vacmViewTreeFamilyTable. Finally, the named view may be created (Set), including the advisory lock. If another SNMP Command Generator application has altered the views in the meantime, then the spin lock's value will have changed, and so this creation will fail because it will specify the wrong value for the spin lock. Since this is an advisory lock, the use of this lock is not enforced. " ::= { vacmMIBViews 1 } vacmViewTreeFamilyTable OBJECT-TYPE SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about families of subtrees within MIB views. Each MIB view is defined by two sets of view subtrees: - the included view subtrees, and - the excluded view subtrees. Every such view subtree, both the included and the Wijnen, et al. Standards Track [Page 21] RFC 3415 VACM for the SNMP December 2002 excluded ones, is defined in this table. To determine if a particular object instance is in a particular MIB view, compare the object instance's OBJECT IDENTIFIER with each of the MIB view's active entries in this table. If none match, then the object instance is not in the MIB view. If one or more match, then the object instance is included in, or excluded from, the MIB view according to the value of vacmViewTreeFamilyType in the entry whose value of vacmViewTreeFamilySubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers (when wildcarding is specified with the value of vacmViewTreeFamilyMask), then the lexicographically greatest instance of vacmViewTreeFamilyType determines the inclusion or exclusion. An object instance's OBJECT IDENTIFIER X matches an active entry in this table when the number of sub-identifiers in X is at least as many as in the value of vacmViewTreeFamilySubtree for the entry, and each sub-identifier in the value of vacmViewTreeFamilySubtree matches its corresponding sub-identifier in X. Two sub-identifiers match either if the corresponding bit of the value of vacmViewTreeFamilyMask for the entry is zero (the 'wild card' value), or if they are equal. A 'family' of subtrees is the set of subtrees defined by a particular combination of values of vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. In the case where no 'wild card' is defined in the vacmViewTreeFamilyMask, the family of subtrees reduces to a single subtree. When creating or changing MIB views, an SNMP Command Generator application should utilize the vacmViewSpinLock to try to avoid collisions. See DESCRIPTION clause of vacmViewSpinLock. When creating MIB views, it is strongly advised that first the 'excluded' vacmViewTreeFamilyEntries are created and then the 'included' entries. When deleting MIB views, it is strongly advised that first the 'included' vacmViewTreeFamilyEntries are Wijnen, et al. Standards Track [Page 22] RFC 3415 VACM for the SNMP December 2002 deleted and then the 'excluded' entries. If a create for an entry for instance-level access control is received and the implementation does not support instance-level granularity, then an inconsistentName error must be returned. " ::= { vacmMIBViews 2 } vacmViewTreeFamilyEntry OBJECT-TYPE SYNTAX VacmViewTreeFamilyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular family of view subtrees included in or excluded from a particular SNMP context's MIB view. Implementations must not restrict the number of families of view subtrees for a given MIB view, except as dictated by resource constraints on the overall number of entries in the vacmViewTreeFamilyTable. If no conceptual rows exist in this table for a given MIB view (viewName), that view may be thought of as consisting of the empty set of view subtrees. " INDEX { vacmViewTreeFamilyViewName, vacmViewTreeFamilySubtree } ::= { vacmViewTreeFamilyTable 1 } VacmViewTreeFamilyEntry ::= SEQUENCE { vacmViewTreeFamilyViewName SnmpAdminString, vacmViewTreeFamilySubtree OBJECT IDENTIFIER, vacmViewTreeFamilyMask OCTET STRING, vacmViewTreeFamilyType INTEGER, vacmViewTreeFamilyStorageType StorageType, vacmViewTreeFamilyStatus RowStatus } vacmViewTreeFamilyViewName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The human readable name for a family of view subtrees. " Wijnen, et al. Standards Track [Page 23] RFC 3415 VACM for the SNMP December 2002 ::= { vacmViewTreeFamilyEntry 1 } vacmViewTreeFamilySubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MIB subtree which when combined with the corresponding instance of vacmViewTreeFamilyMask defines a family of view subtrees. " ::= { vacmViewTreeFamilyEntry 2 } vacmViewTreeFamilyMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The bit mask which, in combination with the corresponding instance of vacmViewTreeFamilySubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub-identifier of vacmViewTreeFamilySubtree, with the most significant bit of the i-th octet of this octet string value (extended if necessary, see below) corresponding to the (8*i - 7)-th sub-identifier, and the least significant bit of the i-th octet of this octet string corresponding to the (8*i)-th sub-identifier, where i is in the range 1 through 16. Each bit of this bit mask specifies whether or not the corresponding sub-identifiers must match when determining if an OBJECT IDENTIFIER is in this family of view subtrees; a '1' indicates that an exact match must occur; a '0' indicates 'wild card', i.e., any sub-identifier value matches. Thus, the OBJECT IDENTIFIER X of an object instance is contained in a family of view subtrees if, for each sub-identifier of the value of vacmViewTreeFamilySubtree, either: the i-th bit of vacmViewTreeFamilyMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of vacmViewTreeFamilySubtree. If the value of this bit mask is M bits long and Wijnen, et al. Standards Track [Page 24] RFC 3415 VACM for the SNMP December 2002 there are more than M sub-identifiers in the corresponding instance of vacmViewTreeFamilySubtree, then the bit mask is extended with 1's to be the required length. Note that when the value of this object is the zero-length string, this extension rule results in a mask of all-1's being used (i.e., no 'wild card'), and the family of view subtrees is the one view subtree uniquely identified by the corresponding instance of vacmViewTreeFamilySubtree. Note that masks of length greater than zero length do not need to be supported. In this case this object is made read-only. " DEFVAL { ''H } ::= { vacmViewTreeFamilyEntry 3 } vacmViewTreeFamilyType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the corresponding instances of vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask define a family of view subtrees which is included in or excluded from the MIB view. " DEFVAL { included } ::= { vacmViewTreeFamilyEntry 4 } vacmViewTreeFamilyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { vacmViewTreeFamilyEntry 5 } vacmViewTreeFamilyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Wijnen, et al. Standards Track [Page 25] RFC 3415 VACM for the SNMP December 2002 The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { vacmViewTreeFamilyEntry 6 } -- Conformance information ******************************************* vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 } vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 } -- Compliance statements ********************************************* vacmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP View-based Access Control Model configuration MIB. " MODULE -- this module MANDATORY-GROUPS { vacmBasicGroup } OBJECT vacmAccessContextMatch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessReadViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessWriteViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessNotifyViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmAccessStatus MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access to the Wijnen, et al. Standards Track [Page 26] RFC 3415 VACM for the SNMP December 2002 vacmAccessTable is not required. " OBJECT vacmViewTreeFamilyMask WRITE-SYNTAX OCTET STRING (SIZE (0)) MIN-ACCESS read-only DESCRIPTION "Support for configuration via SNMP of subtree families using wild-cards is not required. " OBJECT vacmViewTreeFamilyType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmViewTreeFamilyStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT vacmViewTreeFamilyStatus MIN-ACCESS read-only DESCRIPTION "Create/delete/modify access to the vacmViewTreeFamilyTable is not required. " ::= { vacmMIBCompliances 1 } -- Units of conformance ********************************************** vacmBasicGroup OBJECT-GROUP OBJECTS { vacmContextName, vacmGroupName, vacmSecurityToGroupStorageType, vacmSecurityToGroupStatus, vacmAccessContextMatch, vacmAccessReadViewName, vacmAccessWriteViewName, vacmAccessNotifyViewName, vacmAccessStorageType, vacmAccessStatus, vacmViewSpinLock, vacmViewTreeFamilyMask, vacmViewTreeFamilyType, vacmViewTreeFamilyStorageType, vacmViewTreeFamilyStatus } STATUS current DESCRIPTION "A collection of objects providing for remote configuration of an SNMP engine which implements Wijnen, et al. Standards Track [Page 27] RFC 3415 VACM for the SNMP December 2002 the SNMP View-based Access Control Model. " ::= { vacmMIBGroups 1 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members: Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Wijnen, et al. Standards Track [Page 28] RFC 3415 VACM for the SNMP December 2002 Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T.J. Watson Research Center) The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were: David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center) As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Wijnen, et al. Standards Track [Page 29] RFC 3415 VACM for the SNMP December 2002 Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) 7. Security Considerations 7.1. Recommended Practices This document is meant for use in the SNMP architecture. The View- based Access Control Model described in this document checks access rights to management information based on: - contextName, representing a set of management information at the managed system where the Access Control module is running. - groupName, representing a set of zero or more securityNames. The combination of a securityModel and a securityName is mapped into a group in the View-based Access Control Model. - securityModel under which access is requested. - securityLevel under which access is requested. - operation performed on the management information. - MIB views for read, write or notify access. When the User-based Access Control module is called for checking access rights, it is assumed that the calling module has ensured the authentication and privacy aspects as specified by the securityLevel that is being passed. When creating entries in or deleting entries from the vacmViewTreeFamilyTable it is important to do such in the sequence as recommended in the DESCRIPTION clause of the vacmViewTreeFamilyTable definition. Otherwise unwanted access may be granted while changing the entries in the table. 7.2. Defining Groups The groupNames are used to give access to a group of zero or more securityNames. Within the View-Based Access Control Model, a groupName is considered to exist if that groupName is listed in the vacmSecurityToGroupTable. By mapping the combination of a securityModel and securityName into a groupName, an SNMP Command Generator application can add/delete securityNames to/from a group, if proper access is allowed. Wijnen, et al. Standards Track [Page 30] RFC 3415 VACM for the SNMP December 2002 Further it is important to realize that the grouping of tuples in the vacmSecurityToGroupTable does not take securityLevel into account. It is therefore important that the security administrator uses the securityLevel index in the vacmAccessTable to separate noAuthNoPriv from authPriv and/or authNoPriv access. 7.3. Conformance For an implementation of the View-based Access Control Model to be conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according to the vacmMIBCompliance. It also SHOULD implement the initial configuration, described in appendix A. 7.4. Access to the SNMP-VIEW-BASED-ACM-MIB The objects in this MIB control the access to all MIB data that is accessible via the SNMP engine and they may be considered sensitive in many environments. It is important to closely control (both read and write) access to these to these MIB objects by using appropriately configured Access Control models (for example the View-based Access Control Model as specified in this document). 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Wijnen, et al. Standards Track [Page 31] RFC 3415 VACM for the SNMP December 2002 [SNMP3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 8.2. Informative References [ISO-ASN.1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). Wijnen, et al. Standards Track [Page 32] RFC 3415 VACM for the SNMP December 2002 Appendix A - Installation A.1. Installation Parameters During installation, an authoritative SNMP engine which supports this View-based Access Control Model SHOULD be configured with several initial parameters. These include for the View-based Access Control Model: 1) A security configuration The choice of security configuration determines if initial configuration is implemented and if so how. One of three possible choices is selected: - initial-minimum-security-configuration - initial-semi-security-configuration - initial-no-access-configuration In the case of a initial-no-access-configuration, there is no initial configuration, and so the following steps are irrelevant. 2) A default context One entry in the vacmContextTable with a contextName of "" (the empty string), representing the default context. Note that this table gets created automatically if a default context exists. vacmContextName "" 3) An initial group One entry in the vacmSecurityToGroupTable to allow access to group "initial". vacmSecurityModel 3 (USM) vacmSecurityName "initial" vacmGroupName "initial" vacmSecurityToGroupStorageType anyValidStorageType vacmSecurityToGroupStatus active Wijnen, et al. Standards Track [Page 33] RFC 3415 VACM for the SNMP December 2002 4) Initial access rights Three entries in the vacmAccessTable as follows: - read-notify access for securityModel USM, securityLevel "noAuthNoPriv" on behalf of securityNames that belong to the group "initial" to the MIB view in the default context with contextName "". - read-write-notify access for securityModel USM, securityLevel "authNoPriv" on behalf of securityNames that belong to the group "initial" to the MIB view in the default context with contextName "". - if privacy is supported, read-write-notify access for securityModel USM, securityLevel "authPriv" on behalf of securityNames that belong to the group "initial" to the MIB view in the default context with contextName "". That translates into the following entries in the vacmAccessTable. - One entry to be used for unauthenticated access (noAuthNoPriv): vacmGroupName "initial" vacmAccessContextPrefix "" vacmAccessSecurityModel 3 (USM) vacmAccessSecurityLevel noAuthNoPriv vacmAccessContextMatch exact vacmAccessReadViewName "restricted" vacmAccessWriteViewName "" vacmAccessNotifyViewName "restricted" vacmAccessStorageType anyValidStorageType vacmAccessStatus active - One entry to be used for authenticated access (authNoPriv) with optional privacy (authPriv): vacmGroupName "initial" vacmAccessContextPrefix "" vacmAccessSecurityModel 3 (USM) vacmAccessSecurityLevel authNoPriv vacmAccessContextMatch exact vacmAccessReadViewName "internet" vacmAccessWriteViewName "internet" vacmAccessNotifyViewName "internet" vacmAccessStorageType anyValidStorageType vacmAccessStatus active Wijnen, et al. Standards Track [Page 34] RFC 3415 VACM for the SNMP December 2002 5) Two MIB views, of which the second one depends on the security configuration. - One view, the view, for authenticated access: - the MIB view is the following subtree: "internet" (subtree 1.3.6.1) - A second view, the view, for unauthenticated access. This view is configured according to the selected security configuration: - For the initial-no-access-configuration there is no default initial configuration, so no MIB views are pre-scribed. - For the initial-semi-secure-configuration: the MIB view is the union of these subtrees: (a) "system" (subtree 1.3.6.1.2.1.1) [RFC3918] (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC3918] (c) "snmpEngine" (subtree 1.3.6.1.6.3.10.2.1) [RFC3411] (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.11.2.1) [RFC3412] (e) "usmStats" (subtree 1.3.6.1.6.3.15.1.1) [RFC3414] - For the initial-minimum-secure-configuration: the MIB view is the following subtree. "internet" (subtree 1.3.6.1) This translates into the following "internet" entry in the vacmViewTreeFamilyTable: minimum-secure semi-secure ---------------- --------------- vacmViewTreeFamilyViewName "internet" "internet" vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1 vacmViewTreeFamilyMask "" "" vacmViewTreeFamilyType 1 (included) 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType vacmViewTreeFamilyStatus active active Wijnen, et al. Standards Track [Page 35] RFC 3415 VACM for the SNMP December 2002 In addition it translates into the following "restricted" entries in the vacmViewTreeFamilyTable: minimum-secure semi-secure ---------------- --------------- vacmViewTreeFamilyViewName "restricted" "restricted" vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1 vacmViewTreeFamilyMask "" "" vacmViewTreeFamilyType 1 (included) 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType vacmViewTreeFamilyStatus active active vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.2.1.11 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.6.3.10.2.1 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.6.3.11.2.1 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.6.3.15.1.1 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active B. Change Log Changes made since RFC 2575: - Removed reference from abstract as per RFC-Editor guidelines - Updated references Wijnen, et al. Standards Track [Page 36] RFC 3415 VACM for the SNMP December 2002 Changes made since RFC 2275: - Added text to vacmSecurityToGroupStatus DESCRIPTION clause to clarify under which conditions an entry in the vacmSecurityToGroupTable can be made active. - Added REVISION clauses to MODULE-IDENTITY - Clarified text in vacmAccessTable DESCRIPTION clause. - Added a DEFVAL clause to vacmAccessContextMatch object. - Added missing columns in Appendix A and re-arranged for clarity. - Fixed oids in appendix A. - Use the PDU Class terminology instead of RFC1905 PDU types. - Added section 7.4 about access control to the MIB. - Fixed references to new/revised documents - Fix Editor contact information. - fixed spelling errors - removed one vacmAccesEntry from sample in appendix A. - made some more clarifications. - updated acknowledgement section. Wijnen, et al. Standards Track [Page 37] RFC 3415 VACM for the SNMP December 2002 Editors' Addresses Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Phone: +31-348-480-685 EMail: bwijnen@lucent.com Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA Phone: +1 408-546-1006 EMail: randy_presuhn@bmc.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1-408-526-5260 EMail: kzm@cisco.com Wijnen, et al. Standards Track [Page 38] RFC 3415 VACM for the SNMP December 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Wijnen, et al. Standards Track [Page 39] snmp-mibs-downloader-1.1/mibrfcs/rfc3416.txt0000644000000000000000000021063311402176071015564 0ustar Network Working Group Editor of this version: Request for Comments: 3416 R. Presuhn STD: 62 BMC Software, Inc. Obsoletes: 1905 Authors of previous version: Category: Standards Track J. Case SNMP Research, Inc. K. McCloghrie Cisco Systems, Inc. M. Rose Dover Beach Consulting, Inc. S. Waldbusser International Network Services December 2002 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. Presuhn, et al. Standards Track [Page 1] RFC 3416 Protocol Operations for SNMP December 2002 Table of Contents 1. Introduction ................................................ 3 2. Overview .................................................... 4 2.1. Management Information .................................... 4 2.2. Retransmission of Requests ................................ 4 2.3. Message Sizes ............................................. 4 2.4. Transport Mappings ........................................ 5 2.5. SMIv2 Data Type Mappings .................................. 6 3. Definitions ................................................. 6 4. Protocol Specification ...................................... 9 4.1. Common Constructs ......................................... 9 4.2. PDU Processing ............................................ 10 4.2.1. The GetRequest-PDU ...................................... 10 4.2.2. The GetNextRequest-PDU .................................. 11 4.2.2.1. Example of Table Traversal ............................ 12 4.2.3. The GetBulkRequest-PDU .................................. 14 4.2.3.1. Another Example of Table Traversal .................... 17 4.2.4. The Response-PDU ........................................ 18 4.2.5. The SetRequest-PDU ...................................... 19 4.2.6. The SNMPv2-Trap-PDU ..................................... 22 4.2.7. The InformRequest-PDU ................................... 23 5. Notice on Intellectual Property ............................. 24 6. Acknowledgments ............................................. 24 7. Security Considerations ..................................... 26 8. References .................................................. 26 8.1. Normative References ...................................... 26 8.2. Informative References .................................... 27 9. Changes from RFC 1905 ....................................... 28 10. Editor's Address ........................................... 30 11. Full Copyright Statement ................................... 31 Presuhn, et al. Standards Track [Page 2] RFC 3416 Protocol Operations for SNMP December 2002 1. Introduction The SNMP Management Framework at the time of this writing consists of five major components: - An overall architecture, described in STD 62, RFC 3411 [RFC3411]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and STD 62, RFC 3417 [RFC3417]. The third version of the message protocol is called SNMPv3 and described in STD 62, RFC 3417 [RFC3417], RFC 3412 [RFC3412] and RFC 3414 [RFC3414]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in this document. - A set of fundamental applications described in STD 62, RFC 3413 [RFC3413] and the view-based access control mechanism described in STD 62, RFC 3415 [RFC3415]. A more detailed introduction to the SNMP Management Framework at the time of this writing can be found in RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This document, Version 2 of the Protocol Operations for the Simple Network Management Protocol, defines the operations of the protocol with respect to the sending and receiving of PDUs to be carried by the message protocol. Presuhn, et al. Standards Track [Page 3] RFC 3416 Protocol Operations for SNMP December 2002 2. Overview SNMP entities supporting command generator or notification receiver applications (traditionally called "managers") communicate with SNMP entities supporting command responder or notification originator applications (traditionally called "agents"). The purpose of this protocol is the transport of management information and operations. 2.1. Management Information The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI [RFC2578] or the textual conventions based on the SMI [RFC2579]. The term "variable binding" normally refers to the pairing of the name of a variable and its associated value. However, if certain kinds of exceptional conditions occur during processing of a retrieval request, a variable binding will pair a name and an indication of that exception. A variable-binding list is a simple list of variable bindings. The name of a variable is an OBJECT IDENTIFIER which is the concatenation of the OBJECT IDENTIFIER of the corresponding object- type together with an OBJECT IDENTIFIER fragment identifying the instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable. 2.2. Retransmission of Requests For all types of request in this protocol, the receiver is required under normal circumstances, to generate and transmit a response to the originator of the request. Whether or not a request should be retransmitted if no corresponding response is received in an appropriate time interval, is at the discretion of the application originating the request. This will normally depend on the urgency of the request. However, such an application needs to act responsibly in respect to the frequency and duration of re-transmissions. See BCP 41 [RFC2914] for discussion of relevant congestion control principles. 2.3. Message Sizes The maximum size of an SNMP message is limited to the minimum of: (1) the maximum message size which the destination SNMP entity can accept; and, Presuhn, et al. Standards Track [Page 4] RFC 3416 Protocol Operations for SNMP December 2002 (2) the maximum message size which the source SNMP entity can generate. The former may be known on a per-recipient basis; and in the absence of such knowledge, is indicated by transport domain used when sending the message. The latter is imposed by implementation-specific local constraints. Each transport mapping for the SNMP indicates the minimum message size which a SNMP implementation must be able to produce or consume. Although implementations are encouraged to support larger values whenever possible, a conformant implementation must never generate messages larger than allowed by the receiving SNMP entity. One of the aims of the GetBulkRequest-PDU, specified in this protocol, is to minimize the number of protocol exchanges required to retrieve a large amount of management information. As such, this PDU type allows an SNMP entity supporting command generator applications to request that the response be as large as possible given the constraints on message sizes. These constraints include the limits on the size of messages which the SNMP entity supporting command responder applications can generate, and the SNMP entity supporting command generator applications can receive. However, it is possible that such maximum sized messages may be larger than the Path MTU of the path across the network traversed by the messages. In this situation, such messages are subject to fragmentation. Fragmentation is generally considered to be harmful [FRAG], since among other problems, it leads to a decrease in the reliability of the transfer of the messages. Thus, an SNMP entity which sends a GetBulkRequest-PDU must take care to set its parameters accordingly, so as to reduce the risk of fragmentation. In particular, under conditions of network stress, only small values should be used for max-repetitions. 2.4. Transport Mappings It is important to note that the exchange of SNMP messages requires only an unreliable datagram service, with every message being entirely and independently contained in a single transport datagram. Specific transport mappings and encoding rules are specified elsewhere [RFC3417]. However, the preferred mapping is the use of the User Datagram Protocol [RFC768]. Presuhn, et al. Standards Track [Page 5] RFC 3416 Protocol Operations for SNMP December 2002 2.5. SMIv2 Data Type Mappings The SMIv2 [RFC2578] defines 11 base types (INTEGER, OCTET STRING, OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32, Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct. The SMIv2 base types are mapped to the corresponding selection type in the SimpleSyntax and ApplicationSyntax choices of the ASN.1 SNMP protocol definition. Note that the INTEGER and Integer32 SMIv2 base types are mapped to the integer-value selection type of the SimpleSyntax choice. Similarly, the Gauge32 and Unsigned32 SMIv2 base types are mapped to the unsigned-integer-value selection type of the ApplicationSyntax choice. The SMIv2 BITS construct is mapped to the string-value selection type of the SimpleSyntax choice. A BITS value is encoded as an OCTET STRING, in which all the named bits in (the definition of) the bitstring, commencing with the first bit and proceeding to the last bit, are placed in bits 8 (high order bit) to 1 (low order bit) of the first octet, followed by bits 8 to 1 of each subsequent octet in turn, followed by as many bits as are needed of the final subsequent octet, commencing with bit 8. Remaining bits, if any, of the final octet are set to zero on generation and ignored on receipt. 3. Definitions The PDU syntax is defined using ASN.1 notation [ASN1]. SNMPv2-PDU DEFINITIONS ::= BEGIN ObjectName ::= OBJECT IDENTIFIER ObjectSyntax ::= CHOICE { simple SimpleSyntax, application-wide ApplicationSyntax } SimpleSyntax ::= CHOICE { integer-value INTEGER (-2147483648..2147483647), string-value OCTET STRING (SIZE (0..65535)), objectID-value OBJECT IDENTIFIER } ApplicationSyntax ::= CHOICE { ipAddress-value IpAddress, counter-value Counter32, timeticks-value TimeTicks, arbitrary-value Opaque, big-counter-value Counter64, unsigned-integer-value Unsigned32 } Presuhn, et al. Standards Track [Page 6] RFC 3416 Protocol Operations for SNMP December 2002 IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) Gauge32 ::= Unsigned32 TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING Counter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615) -- protocol data units PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-bulk-request GetBulkRequest-PDU, response Response-PDU, set-request SetRequest-PDU, inform-request InformRequest-PDU, snmpV2-trap SNMPv2-Trap-PDU, report Report-PDU } -- PDUs GetRequest-PDU ::= [0] IMPLICIT PDU GetNextRequest-PDU ::= [1] IMPLICIT PDU Response-PDU ::= [2] IMPLICIT PDU SetRequest-PDU ::= [3] IMPLICIT PDU -- [4] is obsolete GetBulkRequest-PDU ::= [5] IMPLICIT BulkPDU InformRequest-PDU ::= [6] IMPLICIT PDU SNMPv2-Trap-PDU ::= [7] IMPLICIT PDU -- Usage and precise semantics of Report-PDU are not defined -- in this document. Any SNMP administrative framework making -- use of this PDU must define its usage and semantics. Presuhn, et al. Standards Track [Page 7] RFC 3416 Protocol Operations for SNMP December 2002 Report-PDU ::= [8] IMPLICIT PDU max-bindings INTEGER ::= 2147483647 PDU ::= SEQUENCE { request-id INTEGER (-214783648..214783647), error-status -- sometimes ignored INTEGER { noError(0), tooBig(1), noSuchName(2), -- for proxy compatibility badValue(3), -- for proxy compatibility readOnly(4), -- for proxy compatibility genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) }, error-index -- sometimes ignored INTEGER (0..max-bindings), variable-bindings -- values are sometimes ignored VarBindList } BulkPDU ::= -- must be identical in SEQUENCE { -- structure to PDU request-id INTEGER (-214783648..214783647), non-repeaters INTEGER (0..max-bindings), max-repetitions INTEGER (0..max-bindings), variable-bindings -- values are ignored VarBindList } -- variable binding Presuhn, et al. Standards Track [Page 8] RFC 3416 Protocol Operations for SNMP December 2002 VarBind ::= SEQUENCE { name ObjectName, CHOICE { value ObjectSyntax, unSpecified NULL, -- in retrieval requests -- exceptions in responses noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, endOfMibView [2] IMPLICIT NULL } } -- variable-binding list VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind END 4. Protocol Specification 4.1. Common Constructs The value of the request-id field in a Response-PDU takes the value of the request-id field in the request PDU to which it is a response. By use of the request-id value, an application can distinguish the (potentially multiple) outstanding requests, and thereby correlate incoming responses with outstanding requests. In cases where an unreliable datagram service is used, the request-id also provides a simple means of identifying messages duplicated by the network. Use of the same request-id on a retransmission of a request allows the response to either the original transmission or the retransmission to satisfy the request. However, in order to calculate the round trip time for transmission and processing of a request-response transaction, the application needs to use a different request-id value on a retransmitted request. The latter strategy is recommended for use in the majority of situations. A non-zero value of the error-status field in a Response-PDU is used to indicate that an error occurred to prevent the processing of the request. In these cases, a non-zero value of the Response-PDU's error-index field provides additional information by identifying which variable binding in the list caused the error. A variable binding is identified by its index value. The first variable binding in a variable-binding list is index one, the second is index two, etc. Presuhn, et al. Standards Track [Page 9] RFC 3416 Protocol Operations for SNMP December 2002 SNMP limits OBJECT IDENTIFIER values to a maximum of 128 sub- identifiers, where each sub-identifier has a maximum value of 2**32-1. 4.2. PDU Processing In the elements of procedure below, any field of a PDU which is not referenced by the relevant procedure is ignored by the receiving SNMP entity. However, all components of a PDU, including those whose values are ignored by the receiving SNMP entity, must have valid ASN.1 syntax and encoding. For example, some PDUs (e.g., the GetRequest-PDU) are concerned only with the name of a variable and not its value. In this case, the value portion of the variable binding is ignored by the receiving SNMP entity. The unSpecified value is defined for use as the value portion of such bindings. On generating a management communication, the message "wrapper" to encapsulate the PDU is generated according to the "Elements of Procedure" of the administrative framework in use. The definition of "max-bindings" imposes an upper bound on the number of variable bindings. In practice, the size of a message is also limited by constraints on the maximum message size. A compliant implementation must support as many variable bindings in a PDU or BulkPDU as fit into the overall maximum message size limit of the SNMP engine, but no more than 2147483647 variable bindings. On receiving a management communication, the "Elements of Procedure" of the administrative framework in use is followed, and if those procedures indicate that the operation contained within the message is to be performed locally, then those procedures also indicate the MIB view which is visible to the operation. 4.2.1. The GetRequest-PDU A GetRequest-PDU is generated and transmitted at the request of an application. Upon receipt of a GetRequest-PDU, the receiving SNMP entity processes each variable binding in the variable-binding list to produce a Response-PDU. All fields of the Response-PDU have the same values as the corresponding fields of the received request except as indicated below. Each variable binding is processed as follows: (1) If the variable binding's name exactly matches the name of a variable accessible by this request, then the variable binding's value field is set to the value of the named variable. Presuhn, et al. Standards Track [Page 10] RFC 3416 Protocol Operations for SNMP December 2002 (2) Otherwise, if the variable binding's name does not have an OBJECT IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER prefix of any (potential) variable accessible by this request, then its value field is set to "noSuchObject". (3) Otherwise, the variable binding's value field is set to "noSuchInstance". If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetRequest-PDU, with the value of its error-status field set to "genErr", and the value of its error-index field is set to the index of the failed variable binding. Otherwise, the value of the Response-PDU's error-status field is set to "noError", and the value of its error-index field is zero. The generated Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetRequest-PDU. Otherwise, an alternate Response-PDU is generated. This alternate Response-PDU is formatted with the same value in its request-id field as the received GetRequest-PDU, with the value of its error-status field set to "tooBig", the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. 4.2.2. The GetNextRequest-PDU A GetNextRequest-PDU is generated and transmitted at the request of an application. Upon receipt of a GetNextRequest-PDU, the receiving SNMP entity processes each variable binding in the variable-binding list to produce a Response-PDU. All fields of the Response-PDU have the same values as the corresponding fields of the received request except as indicated below. Each variable binding is processed as follows: (1) The variable is located which is in the lexicographically ordered list of the names of all variables which are Presuhn, et al. Standards Track [Page 11] RFC 3416 Protocol Operations for SNMP December 2002 accessible by this request and whose name is the first lexicographic successor of the variable binding's name in the incoming GetNextRequest-PDU. The corresponding variable binding's name and value fields in the Response-PDU are set to the name and value of the located variable. (2) If the requested variable binding's name does not lexicographically precede the name of any variable accessible by this request, i.e., there is no lexicographic successor, then the corresponding variable binding produced in the Response-PDU has its value field set to "endOfMibView", and its name field set to the variable binding's name in the request. If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetNextRequest-PDU, with the value of its error-status field set to "genErr", and the value of its error-index field is set to the index of the failed variable binding. Otherwise, the value of the Response-PDU's error-status field is set to "noError", and the value of its error-index field is zero. The generated Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetNextRequest-PDU. Otherwise, an alternate Response-PDU is generated. This alternate Response-PDU is formatted with the same values in its request-id field as the received GetNextRequest-PDU, with the value of its error-status field set to "tooBig", the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetNextRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. 4.2.2.1. Example of Table Traversal An important use of the GetNextRequest-PDU is the traversal of conceptual tables of information within a MIB. The semantics of this type of request, together with the method of identifying individual instances of objects in the MIB, provides access to related objects in the MIB as if they enjoyed a tabular organization. Presuhn, et al. Standards Track [Page 12] RFC 3416 Protocol Operations for SNMP December 2002 In the protocol exchange sketched below, an application retrieves the media-dependent physical address and the address-mapping type for each entry in the IP net-to-media Address Translation Table [RFC1213] of a particular network element. It also retrieves the value of sysUpTime [RFC3418], at which the mappings existed. Suppose that the command responder's IP net-to-media table has three entries: Interface-Number Network-Address Physical-Address Type 1 10.0.0.51 00:00:10:01:23:45 static 1 9.2.3.4 00:00:10:54:32:10 dynamic 2 10.0.0.15 00:00:10:98:76:54 dynamic The SNMP entity supporting a command generator application begins by sending a GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as the requested variable names: GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress, ipNetToMediaType ) The SNMP entity supporting a command responder application responds with a Response-PDU: Response (( sysUpTime.0 = "123456" ), ( ipNetToMediaPhysAddress.1.9.2.3.4 = "000010543210" ), ( ipNetToMediaType.1.9.2.3.4 = "dynamic" )) The SNMP entity supporting the command generator application continues with: GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress.1.9.2.3.4, ipNetToMediaType.1.9.2.3.4 ) The SNMP entity supporting the command responder application responds with: Response (( sysUpTime.0 = "123461" ), ( ipNetToMediaPhysAddress.1.10.0.0.51 = "000010012345" ), ( ipNetToMediaType.1.10.0.0.51 = "static" )) The SNMP entity supporting the command generator application continues with: GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress.1.10.0.0.51, ipNetToMediaType.1.10.0.0.51 ) Presuhn, et al. Standards Track [Page 13] RFC 3416 Protocol Operations for SNMP December 2002 The SNMP entity supporting the command responder application responds with: Response (( sysUpTime.0 = "123466" ), ( ipNetToMediaPhysAddress.2.10.0.0.15 = "000010987654" ), ( ipNetToMediaType.2.10.0.0.15 = "dynamic" )) The SNMP entity supporting the command generator application continues with: GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress.2.10.0.0.15, ipNetToMediaType.2.10.0.0.15 ) As there are no further entries in the table, the SNMP entity supporting the command responder application responds with the variables that are next in the lexicographical ordering of the accessible object names, for example: Response (( sysUpTime.0 = "123471" ), ( ipNetToMediaNetAddress.1.9.2.3.4 = "9.2.3.4" ), ( ipRoutingDiscards.0 = "2" )) Note how, having reached the end of the column for ipNetToMediaPhysAddress, the second variable binding from the command responder application has now "wrapped" to the first row in the next column. Furthermore, note how, having reached the end of the ipNetToMediaTable for the third variable binding, the command responder application has responded with the next available object, which is outside that table. This response signals the end of the table to the command generator application. 4.2.3. The GetBulkRequest-PDU A GetBulkRequest-PDU is generated and transmitted at the request of an application. The purpose of the GetBulkRequest-PDU is to request the transfer of a potentially large amount of data, including, but not limited to, the efficient and rapid retrieval of large tables. Upon receipt of a GetBulkRequest-PDU, the receiving SNMP entity processes each variable binding in the variable-binding list to produce a Response-PDU with its request-id field having the same value as in the request. For the GetBulkRequest-PDU type, the successful processing of each variable binding in the request generates zero or more variable bindings in the Response-PDU. That is, the one-to-one mapping between the variable bindings of the GetRequest-PDU, GetNextRequest- Presuhn, et al. Standards Track [Page 14] RFC 3416 Protocol Operations for SNMP December 2002 PDU, and SetRequest-PDU types and the resultant Response-PDUs does not apply for the mapping between the variable bindings of a GetBulkRequest-PDU and the resultant Response-PDU. The values of the non-repeaters and max-repetitions fields in the request specify the processing requested. One variable binding in the Response-PDU is requested for the first N variable bindings in the request and M variable bindings are requested for each of the R remaining variable bindings in the request. Consequently, the total number of requested variable bindings communicated by the request is given by N + (M * R), where N is the minimum of: a) the value of the non-repeaters field in the request, and b) the number of variable bindings in the request; M is the value of the max-repetitions field in the request; and R is the maximum of: a) number of variable bindings in the request - N, and b) zero. The receiving SNMP entity produces a Response-PDU with up to the total number of requested variable bindings communicated by the request. The request-id shall have the same value as the received GetBulkRequest-PDU. If N is greater than zero, the first through the (N)-th variable bindings of the Response-PDU are each produced as follows: (1) The variable is located which is in the lexicographically ordered list of the names of all variables which are accessible by this request and whose name is the first lexicographic successor of the variable binding's name in the incoming GetBulkRequest-PDU. The corresponding variable binding's name and value fields in the Response-PDU are set to the name and value of the located variable. (2) If the requested variable binding's name does not lexicographically precede the name of any variable accessible by this request, i.e., there is no lexicographic successor, then the corresponding variable binding produced in the Response-PDU has its value field set to "endOfMibView", and its name field set to the variable binding's name in the request. If M and R are non-zero, the (N + 1)-th and subsequent variable bindings of the Response-PDU are each produced in a similar manner. For each iteration i, such that i is greater than zero and less than or equal to M, and for each repeated variable, r, such that r is greater than zero and less than or equal to R, the (N + ( (i-1) * R ) + r)-th variable binding of the Response-PDU is produced as follows: Presuhn, et al. Standards Track [Page 15] RFC 3416 Protocol Operations for SNMP December 2002 (1) The variable which is in the lexicographically ordered list of the names of all variables which are accessible by this request and whose name is the (i)-th lexicographic successor of the (N + r)-th variable binding's name in the incoming GetBulkRequest-PDU is located and the variable binding's name and value fields are set to the name and value of the located variable. (2) If there is no (i)-th lexicographic successor, then the corresponding variable binding produced in the Response-PDU has its value field set to "endOfMibView", and its name field set to either the last lexicographic successor, or if there are no lexicographic successors, to the (N + r)-th variable binding's name in the request. While the maximum number of variable bindings in the Response-PDU is bounded by N + (M * R), the response may be generated with a lesser number of variable bindings (possibly zero) for either of three reasons. (1) If the size of the message encapsulating the Response-PDU containing the requested number of variable bindings would be greater than either a local constraint or the maximum message size of the originator, then the response is generated with a lesser number of variable bindings. This lesser number is the ordered set of variable bindings with some of the variable bindings at the end of the set removed, such that the size of the message encapsulating the Response-PDU is approximately equal to but no greater than either a local constraint or the maximum message size of the originator. Note that the number of variable bindings removed has no relationship to the values of N, M, or R. (2) The response may also be generated with a lesser number of variable bindings if for some value of iteration i, such that i is greater than zero and less than or equal to M, that all of the generated variable bindings have the value field set to "endOfMibView". In this case, the variable bindings may be truncated after the (N + (i * R))-th variable binding. (3) In the event that the processing of a request with many repetitions requires a significantly greater amount of processing time than a normal request, then a command responder application may terminate the request with less than the full number of repetitions, providing at least one repetition is completed. Presuhn, et al. Standards Track [Page 16] RFC 3416 Protocol Operations for SNMP December 2002 If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetBulkRequest-PDU, with the value of its error-status field set to "genErr", and the value of its error-index field is set to the index of the variable binding in the original request which corresponds to the failed variable binding. Otherwise, the value of the Response-PDU's error-status field is set to "noError", and the value of its error-index field to zero. The generated Response-PDU (possibly with an empty variable-bindings field) is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetBulkRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. 4.2.3.1. Another Example of Table Traversal This example demonstrates how the GetBulkRequest-PDU can be used as an alternative to the GetNextRequest-PDU. The same traversal of the IP net-to-media table as shown in Section 4.2.2.1 is achieved with fewer exchanges. The SNMP entity supporting the command generator application begins by sending a GetBulkRequest-PDU with the modest max-repetitions value of 2, and containing the indicated OBJECT IDENTIFIER values as the requested variable names: GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] ( sysUpTime, ipNetToMediaPhysAddress, ipNetToMediaType ) The SNMP entity supporting the command responder application responds with a Response-PDU: Response (( sysUpTime.0 = "123456" ), ( ipNetToMediaPhysAddress.1.9.2.3.4 = "000010543210" ), ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), ( ipNetToMediaPhysAddress.1.10.0.0.51 = "000010012345" ), ( ipNetToMediaType.1.10.0.0.51 = "static" )) Presuhn, et al. Standards Track [Page 17] RFC 3416 Protocol Operations for SNMP December 2002 The SNMP entity supporting the command generator application continues with: GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] ( sysUpTime, ipNetToMediaPhysAddress.1.10.0.0.51, ipNetToMediaType.1.10.0.0.51 ) The SNMP entity supporting the command responder application responds with: Response (( sysUpTime.0 = "123466" ), ( ipNetToMediaPhysAddress.2.10.0.0.15 = "000010987654" ), ( ipNetToMediaType.2.10.0.0.15 = "dynamic" ), ( ipNetToMediaNetAddress.1.9.2.3.4 = "9.2.3.4" ), ( ipRoutingDiscards.0 = "2" )) Note how, as in the first example, the variable bindings in the response indicate that the end of the table has been reached. The fourth variable binding does so by returning information from the next available column; the fifth variable binding does so by returning information from the first available object lexicographically following the table. This response signals the end of the table to the command generator application. 4.2.4. The Response-PDU The Response-PDU is generated by an SNMP entity only upon receipt of a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this document. If the error-status field of the Response-PDU is non-zero, the value fields of the variable bindings in the variable binding list are ignored. If both the error-status field and the error-index field of the Response-PDU are non-zero, then the value of the error-index field is the index of the variable binding (in the variable-binding list of the corresponding request) for which the request failed. The first variable binding in a request's variable-binding list is index one, the second is index two, etc. A compliant SNMP entity supporting a command generator application must be able to properly receive and handle a Response-PDU with an error-status field equal to "noSuchName", "badValue", or "readOnly". (See sections 1.3 and 4.3 of [RFC2576].) Presuhn, et al. Standards Track [Page 18] RFC 3416 Protocol Operations for SNMP December 2002 Upon receipt of a Response-PDU, the receiving SNMP entity presents its contents to the application which generated the request with the same request-id value. For more details, see [RFC3412]. 4.2.5. The SetRequest-PDU A SetRequest-PDU is generated and transmitted at the request of an application. Upon receipt of a SetRequest-PDU, the receiving SNMP entity determines the size of a message encapsulating a Response-PDU having the same values in its request-id and variable-bindings fields as the received SetRequest-PDU, and the largest possible sizes of the error-status and error-index fields. If the determined message size is greater than either a local constraint or the maximum message size of the originator, then an alternate Response-PDU is generated, transmitted to the originator of the SetRequest-PDU, and processing of the SetRequest-PDU terminates immediately thereafter. This alternate Response-PDU is formatted with the same values in its request-id field as the received SetRequest-PDU, with the value of its error-status field set to "tooBig", the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the SetRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. Regardless, processing of the SetRequest-PDU terminates. Otherwise, the receiving SNMP entity processes each variable binding in the variable-binding list to produce a Response-PDU. All fields of the Response-PDU have the same values as the corresponding fields of the received request except as indicated below. The variable bindings are conceptually processed as a two phase operation. In the first phase, each variable binding is validated; if all validations are successful, then each variable is altered in the second phase. Of course, implementors are at liberty to implement either the first, or second, or both, of these conceptual phases as multiple implementation phases. Indeed, such multiple implementation phases may be necessary in some cases to ensure consistency. Presuhn, et al. Standards Track [Page 19] RFC 3416 Protocol Operations for SNMP December 2002 The following validations are performed in the first phase on each variable binding until they are all successful, or until one fails: (1) If the variable binding's name specifies an existing or non- existent variable to which this request is/would be denied access because it is/would not be in the appropriate MIB view, then the value of the Response-PDU's error-status field is set to "noAccess", and the value of its error-index field is set to the index of the failed variable binding. (2) Otherwise, if there are no variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, and which are able to be created or modified no matter what new value is specified, then the value of the Response-PDU's error-status field is set to "notWritable", and the value of its error-index field is set to the index of the failed variable binding. (3) Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a type which is inconsistent with that required for all variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, then the value of the Response-PDU's error-status field is set to "wrongType", and the value of its error-index field is set to the index of the failed variable binding. (4) Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a length which is inconsistent with that required for all variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, then the value of the Response-PDU's error-status field is set to "wrongLength", and the value of its error-index field is set to the index of the failed variable binding. (5) Otherwise, if the variable binding's value field contains an ASN.1 encoding which is inconsistent with that field's ASN.1 tag, then the value of the Response-PDU's error-status field is set to "wrongEncoding", and the value of its error-index field is set to the index of the failed variable binding. (Note that not all implementation strategies will generate this error.) (6) Otherwise, if the variable binding's value field specifies a value which could under no circumstances be assigned to the variable, then the value of the Response-PDU's error-status field is set to "wrongValue", and the value of its error-index field is set to the index of the failed variable binding. Presuhn, et al. Standards Track [Page 20] RFC 3416 Protocol Operations for SNMP December 2002 (7) Otherwise, if the variable binding's name specifies a variable which does not exist and could not ever be created (even though some variables sharing the same OBJECT IDENTIFIER prefix might under some circumstances be able to be created), then the value of the Response-PDU's error-status field is set to "noCreation", and the value of its error-index field is set to the index of the failed variable binding. (8) Otherwise, if the variable binding's name specifies a variable which does not exist but can not be created under the present circumstances (even though it could be created under other circumstances), then the value of the Response-PDU's error- status field is set to "inconsistentName", and the value of its error-index field is set to the index of the failed variable binding. (9) Otherwise, if the variable binding's name specifies a variable which exists but can not be modified no matter what new value is specified, then the value of the Response-PDU's error-status field is set to "notWritable", and the value of its error-index field is set to the index of the failed variable binding. (10) Otherwise, if the variable binding's value field specifies a value that could under other circumstances be held by the variable, but is presently inconsistent or otherwise unable to be assigned to the variable, then the value of the Response- PDU's error-status field is set to "inconsistentValue", and the value of its error-index field is set to the index of the failed variable binding. (11) When, during the above steps, the assignment of the value specified by the variable binding's value field to the specified variable requires the allocation of a resource which is presently unavailable, then the value of the Response-PDU's error-status field is set to "resourceUnavailable", and the value of its error-index field is set to the index of the failed variable binding. (12) If the processing of the variable binding fails for a reason other than listed above, then the value of the Response-PDU's error-status field is set to "genErr", and the value of its error-index field is set to the index of the failed variable binding. (13) Otherwise, the validation of the variable binding succeeds. Presuhn, et al. Standards Track [Page 21] RFC 3416 Protocol Operations for SNMP December 2002 At the end of the first phase, if the validation of all variable bindings succeeded, then the value of the Response-PDU's error-status field is set to "noError" and the value of its error-index field is zero, and processing continues as follows. For each variable binding in the request, the named variable is created if necessary, and the specified value is assigned to it. Each of these variable assignments occurs as if simultaneously with respect to all other assignments specified in the same request. However, if the same variable is named more than once in a single request, with different associated values, then the actual assignment made to that variable is implementation-specific. If any of these assignments fail (even after all the previous validations), then all other assignments are undone, and the Response-PDU is modified to have the value of its error-status field set to "commitFailed", and the value of its error-index field set to the index of the failed variable binding. If and only if it is not possible to undo all the assignments, then the Response-PDU is modified to have the value of its error-status field set to "undoFailed", and the value of its error-index field is set to zero. Note that implementations are strongly encouraged to take all possible measures to avoid use of either "commitFailed" or "undoFailed" - these two error-status codes are not to be taken as license to take the easy way out in an implementation. Finally, the generated Response-PDU is encapsulated into a message, and transmitted to the originator of the SetRequest-PDU. 4.2.6. The SNMPv2-Trap-PDU An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on behalf of a notification originator application. The SNMPv2-Trap-PDU is often used to notify a notification receiver application at a logically remote SNMP entity that an event has occurred or that a condition is present. There is no confirmation associated with this notification delivery mechanism. The destination(s) to which an SNMPv2-Trap-PDU is sent is determined in an implementation-dependent fashion by the SNMP entity. The first two variable bindings in the variable binding list of an SNMPv2- Trap-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, Presuhn, et al. Standards Track [Page 22] RFC 3416 Protocol Operations for SNMP December 2002 to the variable-bindings field. If any additional variables are being included (at the option of the generating SNMP entity), then each is copied to the variable-bindings field. 4.2.7. The InformRequest-PDU An InformRequest-PDU is generated and transmitted by an SNMP entity on behalf of a notification originator application. The InformRequest-PDU is often used to notify a notification receiver application that an event has occurred or that a condition is present. This is a confirmed notification delivery mechanism, although there is, of course, no guarantee of delivery. The destination(s) to which an InformRequest-PDU is sent is specified by the notification originator application. The first two variable bindings in the variable binding list of an InformRequest-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, to the variable-bindings field. If any additional variables are being included (at the option of the generating SNMP entity), then each is copied to the variable-bindings field. Upon receipt of an InformRequest-PDU, the receiving SNMP entity determines the size of a message encapsulating a Response-PDU with the same values in its request-id, error-status, error-index and variable-bindings fields as the received InformRequest-PDU. If the determined message size is greater than either a local constraint or the maximum message size of the originator, then an alternate Response-PDU is generated, transmitted to the originator of the InformRequest-PDU, and processing of the InformRequest-PDU terminates immediately thereafter. This alternate Response-PDU is formatted with the same values in its request-id field as the received InformRequest-PDU, with the value of its error-status field set to "tooBig", the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the InformRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. Regardless, processing of the InformRequest-PDU terminates. Otherwise, the receiving SNMP entity: (1) presents its contents to the appropriate application; Presuhn, et al. Standards Track [Page 23] RFC 3416 Protocol Operations for SNMP December 2002 (2) generates a Response-PDU with the same values in its request-id and variable-bindings fields as the received InformRequest-PDU, with the value of its error-status field set to "noError" and the value of its error-index field set to zero; and (3) transmits the generated Response-PDU to the originator of the InformRequest-PDU. 5. Notice on Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgments This document is the product of the SNMPv3 Working Group. Some special thanks are in order to the following Working Group members: Randy Bush Jeffrey D. Case Mike Daniele Rob Frye Lauren Heintz Keith McCloghrie Russ Mundy David T. Perkins Randy Presuhn Aleksey Romanov Juergen Schoenwaelder Bert Wijnen Presuhn, et al. Standards Track [Page 24] RFC 3416 Protocol Operations for SNMP December 2002 This version of the document, edited by Randy Presuhn, was initially based on the work of a design team whose members were: Jeffrey D. Case Keith McCloghrie David T. Perkins Randy Presuhn Juergen Schoenwaelder The previous versions of this document, edited by Keith McCloghrie, was the result of significant work by four major contributors: Jeffrey D. Case Keith McCloghrie Marshall T. Rose Steven Waldbusser Additionally, the contributions of the SNMPv2 Working Group to the previous versions are also acknowledged. In particular, a special thanks is extended for the contributions of: Alexander I. Alten Dave Arneson Uri Blumenthal Doug Book Kim Curran Jim Galvin Maria Greene Iain Hanson Dave Harrington Nguyen Hien Jeff Johnson Michael Kornegay Deirdre Kostick David Levi Daniel Mahoney Bob Natale Brian O'Keefe Andrew Pearson Dave Perkins Randy Presuhn Aleksey Romanov Shawn Routhier Jon Saperia Juergen Schoenwaelder Bob Stewart Presuhn, et al. Standards Track [Page 25] RFC 3416 Protocol Operations for SNMP December 2002 Kaj Tesink Glenn Waters Bert Wijnen 7. Security Considerations The protocol defined in this document by itself does not provide a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed access to management information. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity is properly configured so that: - only those principals (users) having legitimate rights can access or modify the values of any MIB objects supported by that entity; - the occurrence of particular events on the entity will be communicated appropriately; - the entity responds appropriately and with due credence to events and information that have been communicated to it. 8. References 8.1. Normative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Presuhn, et al. Standards Track [Page 26] RFC 3416 Protocol Operations for SNMP December 2002 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol", STD 62, RFC 3417, December 2002. [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December 1987. 8.2. Informative References [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful," Proceedings, ACM SIGCOMM '87, Stowe, VT, August 1987. Presuhn, et al. Standards Track [Page 27] RFC 3416 Protocol Operations for SNMP December 2002 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1213] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework", RFC 2576, March 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 9. Changes from RFC 1905 These are the changes from RFC 1905: - Corrected spelling error in copyright statement; - Updated copyright date; - Updated with new editor's name and contact information; - Added notice on intellectual property; Presuhn, et al. Standards Track [Page 28] RFC 3416 Protocol Operations for SNMP December 2002 - Cosmetic fixes to layout and typography; - Added table of contents; - Title changed; - Updated document headers and footers; - Deleted the old clause 2.3, entitled "Access to Management Information"; - Changed the way in which request-id was defined, though with the same ultimate syntax and semantics, to avoid coupling with SMI. This does not affect the protocol in any way; - Replaced the word "exception" with the word "error" in the old clause 4.1. This does not affect the protocol in any way; - Deleted the first two paragraphs of the old clause 4.2; - Clarified the maximum number of variable bindings that an implementation must support in a PDU. This does not affect the protocol in any way; - Replaced occurrences of "SNMPv2 application" with "application"; - Deleted three sentences in old clause 4.2.3 describing the handling of an impossible situation. This does not affect the protocol in any way; - Clarified the use of the SNMPv2-Trap-Pdu in the old clause 4.2.6. This does not affect the protocol in any way; - Aligned description of the use of the InformRequest-Pdu in old clause 4.2.7 with the architecture. This does not affect the protocol in any way; - Updated references; - Re-wrote introduction clause; - Replaced manager/agent/SNMPv2 entity terminology with terminology from RFC 2571. This does not affect the protocol in any way; - Eliminated IMPORTS from the SMI, replaced with equivalent in- line ASN.1. This does not affect the protocol in any way; Presuhn, et al. Standards Track [Page 29] RFC 3416 Protocol Operations for SNMP December 2002 - Added notes calling attention to two different manifestations of reaching the end of a table in the table walk examples; - Added content to security considerations clause; - Updated ASN.1 comment on use of Report-PDU. This does not affect the protocol in any way; - Updated acknowledgments section; - Included information on handling of BITS; - Deleted spurious comma in ASN.1 definition of PDUs; - Added abstract; - Made handling of additional variable bindings in informs consistent with that for traps. This was a correction of an editorial oversight, and reflects implementation practice; - Added reference to RFC 2914. 10. Editor's Address Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA Phone: +1 408 546 1006 EMail: randy_presuhn@bmc.com Presuhn, et al. Standards Track [Page 30] RFC 3416 Protocol Operations for SNMP December 2002 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Presuhn, et al. Standards Track [Page 31] snmp-mibs-downloader-1.1/mibrfcs/rfc3417.txt0000644000000000000000000011337211402176071015567 0ustar Network Working Group Editor of this version: Request for Comments: 3417 R. Presuhn STD: 62 BMC Software, Inc. Obsoletes: 1906 Authors of previous version: Category: Standards Track J. Case SNMP Research, Inc. K. McCloghrie Cisco Systems, Inc. M. Rose Dover Beach Consulting, Inc. S. Waldbusser International Network Services December 2002 Transport Mappings for the Simple Network Management Protocol (SNMP) 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. Presuhn, et al. Standards Track [Page 1] RFC 3417 Transport Mappings for SNMP December 2002 Table of Contents 1. Introduction ................................................ 2 2. Definitions ................................................. 3 3. SNMP over UDP over IPv4 ..................................... 7 3.1. Serialization ............................................. 7 3.2. Well-known Values ......................................... 7 4. SNMP over OSI ............................................... 7 4.1. Serialization ............................................. 7 4.2. Well-known Values ......................................... 8 5. SNMP over DDP ............................................... 8 5.1. Serialization ............................................. 8 5.2. Well-known Values ......................................... 8 5.3. Discussion of AppleTalk Addressing ........................ 9 5.3.1. How to Acquire NBP names ................................ 9 5.3.2. When to Turn NBP names into DDP addresses ............... 10 5.3.3. How to Turn NBP names into DDP addresses ................ 10 5.3.4. What if NBP is broken ................................... 10 6. SNMP over IPX ............................................... 11 6.1. Serialization ............................................. 11 6.2. Well-known Values ......................................... 11 7. Proxy to SNMPv1 ............................................. 12 8. Serialization using the Basic Encoding Rules ................ 12 8.1. Usage Example ............................................. 13 9. Notice on Intellectual Property ............................. 14 10. Acknowledgments ............................................ 14 11. IANA Considerations ........................................ 15 12. Security Considerations .................................... 16 13. References ................................................. 16 13.1. Normative References ..................................... 16 13.2. Informative References ................................... 17 14. Changes from RFC 1906 ...................................... 18 15. Editor's Address ........................................... 18 16. Full Copyright Statement ................................... 19 1. Introduction For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB Presuhn, et al. Standards Track [Page 2] RFC 3417 Transport Mappings for SNMP December 2002 module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. This document, Transport Mappings for the Simple Network Management Protocol, defines how the management protocol [RFC3416] may be carried over a variety of protocol suites. It is the purpose of this document to define how the SNMP maps onto an initial set of transport domains. At the time of this writing, work was in progress to define an IPv6 mapping, described in [RFC3419]. Other mappings may be defined in the future. Although several mappings are defined, the mapping onto UDP over IPv4 is the preferred mapping for systems supporting IPv4. Systems implementing IPv4 MUST implement the mapping onto UDP over IPv4. To maximize interoperability, systems supporting other mappings SHOULD also provide for access via the UDP over IPv4 mapping. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Definitions SNMPv2-TM DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, snmpModules, snmpDomains, snmpProxys FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; snmpv2tm MODULE-IDENTITY LAST-UPDATED "200210160000Z" ORGANIZATION "IETF SNMPv3 Working Group" CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com Subscribe: snmpv3-request@lists.tislabs.com Co-Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA EMail: mundy@tislabs.com phone: +1 301 947-7107 Presuhn, et al. Standards Track [Page 3] RFC 3417 Transport Mappings for SNMP December 2002 Co-Chair: David Harrington Enterasys Networks postal: 35 Industrial Way P. O. Box 5005 Rochester, NH 03866-5005 USA EMail: dbh@enterasys.com phone: +1 603 337-2614 Editor: Randy Presuhn BMC Software, Inc. postal: 2141 North First Street San Jose, CA 95131 USA EMail: randy_presuhn@bmc.com phone: +1 408 546-1006" DESCRIPTION "The MIB module for SNMP transport mappings. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3417; see the RFC itself for full legal notices. " REVISION "200210160000Z" DESCRIPTION "Clarifications, published as RFC 3417." REVISION "199601010000Z" DESCRIPTION "Clarifications, published as RFC 1906." REVISION "199304010000Z" DESCRIPTION "The initial version, published as RFC 1449." ::= { snmpModules 19 } -- SNMP over UDP over IPv4 snmpUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over UDP over IPv4 transport domain. The corresponding transport address is of type SnmpUDPAddress." ::= { snmpDomains 1 } Presuhn, et al. Standards Track [Page 4] RFC 3417 Transport Mappings for SNMP December 2002 SnmpUDPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a UDP over IPv4 address: octets contents encoding 1-4 IP-address network-byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6)) -- SNMP over OSI snmpCLNSDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over CLNS transport domain. The corresponding transport address is of type SnmpOSIAddress." ::= { snmpDomains 2 } snmpCONSDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over CONS transport domain. The corresponding transport address is of type SnmpOSIAddress." ::= { snmpDomains 3 } SnmpOSIAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "*1x:/1x:" STATUS current DESCRIPTION "Represents an OSI transport-address: octets contents encoding 1 length of NSAP 'n' as an unsigned-integer (either 0 or from 3 to 20) 2..(n+1) NSAP concrete binary representation (n+2)..m TSEL string of (up to 64) octets " SYNTAX OCTET STRING (SIZE (1 | 4..85)) Presuhn, et al. Standards Track [Page 5] RFC 3417 Transport Mappings for SNMP December 2002 -- SNMP over DDP snmpDDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over DDP transport domain. The corresponding transport address is of type SnmpNBPAddress." ::= { snmpDomains 4 } SnmpNBPAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents an NBP name: octets contents encoding 1 length of object 'n' as an unsigned integer 2..(n+1) object string of (up to 32) octets n+2 length of type 'p' as an unsigned integer (n+3)..(n+2+p) type string of (up to 32) octets n+3+p length of zone 'q' as an unsigned integer (n+4+p)..(n+3+p+q) zone string of (up to 32) octets For comparison purposes, strings are case-insensitive. All strings may contain any octet other than 255 (hex ff)." SYNTAX OCTET STRING (SIZE (3..99)) -- SNMP over IPX snmpIPXDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over IPX transport domain. The corresponding transport address is of type SnmpIPXAddress." ::= { snmpDomains 5 } SnmpIPXAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" STATUS current DESCRIPTION "Represents an IPX address: octets contents encoding 1-4 network-number network-byte order 5-10 physical-address network-byte order 11-12 socket-number network-byte order " SYNTAX OCTET STRING (SIZE (12)) Presuhn, et al. Standards Track [Page 6] RFC 3417 Transport Mappings for SNMP December 2002 -- for proxy to SNMPv1 (RFC 1157) rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } rfc1157Domain OBJECT-IDENTITY STATUS deprecated DESCRIPTION "The transport domain for SNMPv1 over UDP over IPv4. The corresponding transport address is of type SnmpUDPAddress." ::= { rfc1157Proxy 1 } -- ::= { rfc1157Proxy 2 } this OID is obsolete END 3. SNMP over UDP over IPv4 This is the preferred transport mapping. 3.1. Serialization Each instance of a message is serialized (i.e., encoded according to the convention of [BER]) onto a single UDP [RFC768] over IPv4 [RFC791] datagram, using the algorithm specified in Section 8. 3.2. Well-known Values It is suggested that administrators configure their SNMP entities supporting command responder applications to listen on UDP port 161. Further, it is suggested that SNMP entities supporting notification receiver applications be configured to listen on UDP port 162. When an SNMP entity uses this transport mapping, it must be capable of accepting messages up to and including 484 octets in size. It is recommended that implementations be capable of accepting messages of up to 1472 octets in size. Implementation of larger values is encouraged whenever possible. 4. SNMP over OSI This is an optional transport mapping. 4.1. Serialization Each instance of a message is serialized onto a single TSDU [IS8072] [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), using the algorithm specified in Section 8. Presuhn, et al. Standards Track [Page 7] RFC 3417 Transport Mappings for SNMP December 2002 4.2. Well-known Values It is suggested that administrators configure their SNMP entities supporting command responder applications to listen on transport selector "snmp-l" (which consists of six ASCII characters), when using a CL-mode network service to realize the CLTS. Further, it is suggested that SNMP entities supporting notification receiver applications be configured to listen on transport selector "snmpt-l" (which consists of seven ASCII characters, six letters and a hyphen) when using a CL-mode network service to realize the CLTS. Similarly, when using a CO-mode network service to realize the CLTS, the suggested transport selectors are "snmp-o" and "snmpt-o", for command responders and notification receivers, respectively. When an SNMP entity uses this transport mapping, it must be capable of accepting messages that are at least 484 octets in size. Implementation of larger values is encouraged whenever possible. 5. SNMP over DDP This is an optional transport mapping. 5.1. Serialization Each instance of a message is serialized onto a single DDP datagram [APPLETALK], using the algorithm specified in Section 8. 5.2. Well-known Values SNMP messages are sent using DDP protocol type 8. SNMP entities supporting command responder applications listen on DDP socket number 8, while SNMP entities supporting notification receiver applications listen on DDP socket number 9. Administrators must configure their SNMP entities supporting command responder applications to use NBP type "SNMP Agent" (which consists of ten ASCII characters) while those supporting notification receiver applications must be configured to use NBP type "SNMP Trap Handler" (which consists of seventeen ASCII characters). The NBP name for SNMP entities supporting command responders and notification receivers should be stable - NBP names should not change any more often than the IP address of a typical TCP/IP node. It is suggested that the NBP name be stored in some form of stable storage. When an SNMP entity uses this transport mapping, it must be capable of accepting messages that are at least 484 octets in size. Implementation of larger values is encouraged whenever possible. Presuhn, et al. Standards Track [Page 8] RFC 3417 Transport Mappings for SNMP December 2002 5.3. Discussion of AppleTalk Addressing The AppleTalk protocol suite has certain features not manifest in the TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of address assignment can cause problems for SNMP entities that wish to manage AppleTalk networks. TCP/IP nodes have an associated IP address which distinguishes each from the other. In contrast, AppleTalk nodes generally have no such characteristic. The network- level address, while often relatively stable, can change at every reboot (or more frequently). Thus, when SNMP is mapped over DDP, nodes are identified by a "name", rather than by an "address". Hence, all AppleTalk nodes that implement this mapping are required to respond to NBP lookups and confirms (e.g., implement the NBP protocol stub), which guarantees that a mapping from NBP name to DDP address will be possible. In determining the SNMP identity to register for an SNMP entity, it is suggested that the SNMP identity be a name which is associated with other network services offered by the machine. NBP lookups, which are used to map NBP names into DDP addresses, can cause large amounts of network traffic as well as consume CPU resources. It is also the case that the ability to perform an NBP lookup is sensitive to certain network disruptions (such as zone table inconsistencies) which would not prevent direct AppleTalk communications between two SNMP entities. Thus, it is recommended that NBP lookups be used infrequently, primarily to create a cache of name-to-address mappings. These cached mappings should then be used for any further SNMP traffic. It is recommended that SNMP entities supporting command generator applications should maintain this cache between reboots. This caching can help minimize network traffic, reduce CPU load on the network, and allow for (some amount of) network trouble shooting when the basic name-to-address translation mechanism is broken. 5.3.1. How to Acquire NBP names An SNMP entity supporting command generator applications may have a pre-configured list of names of "known" SNMP entities supporting command responder applications. Similarly, an SNMP entity supporting command generator or notification receiver applications might interact with an operator. Finally, an SNMP entity supporting command generator or notification receiver applications might communicate with all SNMP entities supporting command responder or notification originator applications in a set of zones or networks. Presuhn, et al. Standards Track [Page 9] RFC 3417 Transport Mappings for SNMP December 2002 5.3.2. When to Turn NBP names into DDP addresses When an SNMP entity uses a cache entry to address an SNMP packet, it should attempt to confirm the validity mapping, if the mapping hasn't been confirmed within the last T1 seconds. This cache entry lifetime, T1, has a minimum, default value of 60 seconds, and should be configurable. An SNMP entity supporting a command generator application may decide to prime its cache of names prior to actually communicating with another SNMP entity. In general, it is expected that such an entity may want to keep certain mappings "more current" than other mappings, e.g., those nodes which represent the network infrastructure (e.g., routers) may be deemed "more important". Note that an SNMP entity supporting command generator applications should not prime its entire cache upon initialization - rather, it should attempt resolutions over an extended period of time (perhaps in some pre-determined or configured priority order). Each of these resolutions might, in fact, be a wildcard lookup in a given zone. An SNMP entity supporting command responder applications must never prime its cache. When generating a response, such an entity does not need to confirm a cache entry. An SNMP entity supporting notification originator applications should do NBP lookups (or confirms) only when it needs to send an SNMP trap or inform. 5.3.3. How to Turn NBP names into DDP addresses If the only piece of information available is the NBP name, then an NBP lookup should be performed to turn that name into a DDP address. However, if there is a piece of stale information, it can be used as a hint to perform an NBP confirm (which sends a unicast to the network address which is presumed to be the target of the name lookup) to see if the stale information is, in fact, still valid. An NBP name to DDP address mapping can also be confirmed implicitly using only SNMP transactions. For example, an SNMP entity supporting command generator applications issuing a retrieval operation could also retrieve the relevant objects from the NBP group [RFC1742] for the SNMP entity supporting the command responder application. This information can then be correlated with the source DDP address of the response. 5.3.4. What if NBP is broken Under some circumstances, there may be connectivity between two SNMP entities, but the NBP mapping machinery may be broken, e.g., Presuhn, et al. Standards Track [Page 10] RFC 3417 Transport Mappings for SNMP December 2002 o the NBP FwdReq (forward NBP lookup onto local attached network) mechanism might be broken at a router on the other entity's network; or, o the NBP BrRq (NBP broadcast request) mechanism might be broken at a router on the entity's own network; or, o NBP might be broken on the other entity's node. An SNMP entity supporting command generator applications which is dedicated to AppleTalk management might choose to alleviate some of these failures by directly implementing the router portion of NBP. For example, such an entity might already know all the zones on the AppleTalk internet and the networks on which each zone appears. Given an NBP lookup which fails, the entity could send an NBP FwdReq to the network in which the SNMP entity supporting the command responder or notification originator application was last located. If that failed, the station could then send an NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to each network number on that network. Of the above (single) failures, this combined approach will solve the case where either the local router's BrRq-to-FwdReq mechanism is broken or the remote router's FwdReq-to-LkUp mechanism is broken. 6. SNMP over IPX This is an optional transport mapping. 6.1. Serialization Each instance of a message is serialized onto a single IPX datagram [NOVELL], using the algorithm specified in Section 8. 6.2. Well-known Values SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange Protocol). It is suggested that administrators configure their SNMP entities supporting command responder applications to listen on IPX socket 36879 (900f hexadecimal). Further, it is suggested that those supporting notification receiver applications be configured to listen on IPX socket 36880 (9010 hexadecimal). When an SNMP entity uses this transport mapping, it must be capable of accepting messages that are at least 546 octets in size. Implementation of larger values is encouraged whenever possible. Presuhn, et al. Standards Track [Page 11] RFC 3417 Transport Mappings for SNMP December 2002 7. Proxy to SNMPv1 Historically, in order to support proxy to SNMPv1, as defined in [RFC2576], it was deemed useful to define a transport domain, rfc1157Domain, which indicates the transport mapping for SNMP messages as defined in [RFC1157]. 8. Serialization using the Basic Encoding Rules When the Basic Encoding Rules [BER] are used for serialization: (1) When encoding the length field, only the definite form is used; use of the indefinite form encoding is prohibited. Note that when using the definite-long form, it is permissible to use more than the minimum number of length octets necessary to encode the length field. (2) When encoding the value field, the primitive form shall be used for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT IDENTIFIER (either IMPLICIT or explicit). The constructed form of encoding shall be used only for structured types, i.e., a SEQUENCE or an IMPLICIT SEQUENCE. (3) When encoding an object whose syntax is described using the BITS construct, the value is encoded as an OCTET STRING, in which all the named bits in (the definition of) the bitstring, commencing with the first bit and proceeding to the last bit, are placed in bits 8 (high order bit) to 1 (low order bit) of the first octet, followed by bits 8 to 1 of each subsequent octet in turn, followed by as many bits as are needed of the final subsequent octet, commencing with bit 8. Remaining bits, if any, of the final octet are set to zero on generation and ignored on receipt. These restrictions apply to all aspects of ASN.1 encoding, including the message wrappers, protocol data units, and the data objects they contain. Presuhn, et al. Standards Track [Page 12] RFC 3417 Transport Mappings for SNMP December 2002 8.1. Usage Example As an example of applying the Basic Encoding Rules, suppose one wanted to encode an instance of the GetBulkRequest-PDU [RFC3416]: [5] IMPLICIT SEQUENCE { request-id 1414684022, non-repeaters 1, max-repetitions 2, variable-bindings { { name sysUpTime, value { unSpecified NULL } }, { name ipNetToMediaPhysAddress, value { unSpecified NULL } }, { name ipNetToMediaType, value { unSpecified NULL } } } } Applying the BER, this may be encoded (in hexadecimal) as: [5] IMPLICIT SEQUENCE a5 82 00 39 INTEGER 02 04 54 52 5d 76 INTEGER 02 01 01 INTEGER 02 01 02 SEQUENCE (OF) 30 2b SEQUENCE 30 0b OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 NULL 05 00 SEQUENCE 30 0d OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 NULL 05 00 SEQUENCE 30 0d OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 NULL 05 00 Note that the initial SEQUENCE in this example was not encoded using the minimum number of length octets. (The first octet of the length, 82, indicates that the length of the content is encoded in the next two octets.) Presuhn, et al. Standards Track [Page 13] RFC 3417 Transport Mappings for SNMP December 2002 9. Notice on Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Acknowledgments This document is the product of the SNMPv3 Working Group. Some special thanks are in order to the following Working Group members: Randy Bush Jeffrey D. Case Mike Daniele Rob Frye Lauren Heintz Keith McCloghrie Russ Mundy David T. Perkins Randy Presuhn Aleksey Romanov Juergen Schoenwaelder Bert Wijnen This version of the document, edited by Randy Presuhn, was initially based on the work of a design team whose members were: Jeffrey D. Case Keith McCloghrie David T. Perkins Randy Presuhn Juergen Schoenwaelder Presuhn, et al. Standards Track [Page 14] RFC 3417 Transport Mappings for SNMP December 2002 The previous versions of this document, edited by Keith McCloghrie, was the result of significant work by four major contributors: Jeffrey D. Case Keith McCloghrie Marshall T. Rose Steven Waldbusser Additionally, the contributions of the SNMPv2 Working Group to the previous versions are also acknowledged. In particular, a special thanks is extended for the contributions of: Alexander I. Alten Dave Arneson Uri Blumenthal Doug Book Kim Curran Jim Galvin Maria Greene Iain Hanson Dave Harrington Nguyen Hien Jeff Johnson Michael Kornegay Deirdre Kostick David Levi Daniel Mahoney Bob Natale Brian O'Keefe Andrew Pearson Dave Perkins Randy Presuhn Aleksey Romanov Shawn Routhier Jon Saperia Juergen Schoenwaelder Bob Stewart Kaj Tesink Glenn Waters Bert Wijnen 11. IANA Considerations The SNMPv2-TM MIB module requires the allocation of a single object identifier for its MODULE-IDENTITY. IANA has allocated this object identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB module. Presuhn, et al. Standards Track [Page 15] RFC 3417 Transport Mappings for SNMP December 2002 12. Security Considerations SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change) the objects accessible through a command responder application. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to a MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change) them. 13. References 13.1. Normative References [BER] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8825, December 1987. [IS8072] Information processing systems - Open Systems Interconnection - Transport Service Definition, International Organization for Standardization. International Standard 8072, June 1986. [IS8072A] Information processing systems - Open Systems Interconnection - Transport Service Definition - Addendum 1: Connectionless-mode Transmission, International Organization for Standardization. International Standard 8072/AD 1, December 1986. [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Presuhn, et al. Standards Track [Page 16] RFC 3417 Transport Mappings for SNMP December 2002 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. 13.2. Informative References [APPLETALK] Sidhu, G., Andrews, R. and A. Oppenheimer, Inside AppleTalk (second edition). Addison-Wesley, 1990. [NOVELL] Network System Technical Interface Overview. Novell, Inc., June 1989. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management Information Base II", RFC 1742, January 1995. [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework", RFC 2576, March 2000. Presuhn, et al. Standards Track [Page 17] RFC 3417 Transport Mappings for SNMP December 2002 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, November 2002. 14. Changes from RFC 1906 This document differs from RFC 1906 only in editorial improvements. The protocol is unchanged. 15. Editor's Address Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA Phone: +1 408 546-1006 EMail: randy_presuhn@bmc.com Presuhn, et al. Standards Track [Page 18] RFC 3417 Transport Mappings for SNMP December 2002 16. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Presuhn, et al. Standards Track [Page 19] snmp-mibs-downloader-1.1/mibrfcs/rfc3418.txt0000644000000000000000000013771011402176071015572 0ustar Network Working Group Editor of this version: Request for Comments: 3418 R. Presuhn STD: 62 BMC Software, Inc. Obsoletes: 1907 Authors of previous version: Category: Standards Track J. Case SNMP Research, Inc. K. McCloghrie Cisco Systems, Inc. M. Rose Dover Beach Consulting, Inc. S. Waldbusser International Network Services December 2002 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). Presuhn, et al. Standards Track [Page 1] RFC 3418 MIB for SNMP December 2002 Table of Contents 1. The Internet-Standard Management Framework .................. 2 2. Definitions ................................................. 2 3. Notice on Intellectual Property ............................. 20 4. Acknowledgments ............................................. 21 5. Security Considerations ..................................... 22 6. References .................................................. 23 6.1. Normative References ...................................... 23 6.2. Informative References .................................... 24 7. Changes from RFC 1907 ....................................... 24 8. Editor's Address ............................................ 25 9. Full Copyright Statement .................................... 26 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. It is the purpose of this document to define managed objects which describe the behavior of an SNMP entity, as defined in the SNMP architecture STD 62, [RFC3411]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Definitions SNMPv2-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, TimeTicks, Counter32, snmpModules, mib-2 FROM SNMPv2-SMI DisplayString, TestAndIncr, TimeStamp Presuhn, et al. Standards Track [Page 2] RFC 3418 MIB for SNMP December 2002 FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; snmpMIB MODULE-IDENTITY LAST-UPDATED "200210160000Z" ORGANIZATION "IETF SNMPv3 Working Group" CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com Subscribe: snmpv3-request@lists.tislabs.com Co-Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA EMail: mundy@tislabs.com phone: +1 301 947-7107 Co-Chair: David Harrington Enterasys Networks postal: 35 Industrial Way P. O. Box 5005 Rochester, NH 03866-5005 USA EMail: dbh@enterasys.com phone: +1 603 337-2614 Editor: Randy Presuhn BMC Software, Inc. postal: 2141 North First Street San Jose, CA 95131 USA EMail: randy_presuhn@bmc.com phone: +1 408 546-1006" DESCRIPTION "The MIB module for SNMP entities. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3418; see the RFC itself for full legal notices. " REVISION "200210160000Z" DESCRIPTION "This revision of this MIB module was published as RFC 3418." REVISION "199511090000Z" DESCRIPTION Presuhn, et al. Standards Track [Page 3] RFC 3418 MIB for SNMP December 2002 "This revision of this MIB module was published as RFC 1907." REVISION "199304010000Z" DESCRIPTION "The initial revision of this MIB module was published as RFC 1450." ::= { snmpModules 1 } snmpMIBObjects OBJECT IDENTIFIER ::= { snmpMIB 1 } -- ::= { snmpMIBObjects 1 } this OID is obsolete -- ::= { snmpMIBObjects 2 } this OID is obsolete -- ::= { snmpMIBObjects 3 } this OID is obsolete -- the System group -- -- a collection of objects common to all managed systems. system OBJECT IDENTIFIER ::= { mib-2 1 } sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software." ::= { system 1 } sysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.424242, it could assign the identifier 1.3.6.1.4.1.424242.1.1 to its `Fred Router'." ::= { system 2 } sysUpTime OBJECT-TYPE Presuhn, et al. Standards Track [Page 4] RFC 3418 MIB for SNMP December 2002 SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } sysContact OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "The textual identification of the contact person for this managed node, together with information on how to contact this person. If no contact information is known, the value is the zero-length string." ::= { system 4 } sysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name. If the name is unknown, the value is the zero-length string." ::= { system 5 } sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "The physical location of this node (e.g., 'telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string." ::= { system 6 } sysServices OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "A value which indicates the set of services that this entity may potentially offer. The value is a sum. Presuhn, et al. Standards Track [Page 5] RFC 3418 MIB for SNMP December 2002 This sum initially takes the value zero. Then, for each layer, L, in the range 1 through 7, that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs only routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values should be calculated accordingly: layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 internet (e.g., supports the IP) 4 end-to-end (e.g., supports the TCP) 7 applications (e.g., supports the SMTP) For systems including OSI protocols, layers 5 and 6 may also be counted." ::= { system 7 } -- object resource information -- -- a collection of objects which describe the SNMP entity's -- (statically and dynamically configurable) support of -- various MIB modules. sysORLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the most recent change in state or value of any instance of sysORID." ::= { system 8 } sysORTable OBJECT-TYPE SYNTAX SEQUENCE OF SysOREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the capabilities of the local SNMP application acting as a command responder with respect to various MIB modules. SNMP entities having dynamically-configurable support of MIB modules will have a dynamically-varying number of conceptual rows." ::= { system 9 } Presuhn, et al. Standards Track [Page 6] RFC 3418 MIB for SNMP December 2002 sysOREntry OBJECT-TYPE SYNTAX SysOREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the sysORTable." INDEX { sysORIndex } ::= { sysORTable 1 } SysOREntry ::= SEQUENCE { sysORIndex INTEGER, sysORID OBJECT IDENTIFIER, sysORDescr DisplayString, sysORUpTime TimeStamp } sysORIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used for identifying instances of the columnar objects in the sysORTable." ::= { sysOREntry 1 } sysORID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An authoritative identification of a capabilities statement with respect to various MIB modules supported by the local SNMP application acting as a command responder." ::= { sysOREntry 2 } sysORDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the capabilities identified by the corresponding instance of sysORID." ::= { sysOREntry 3 } sysORUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only Presuhn, et al. Standards Track [Page 7] RFC 3418 MIB for SNMP December 2002 STATUS current DESCRIPTION "The value of sysUpTime at the time this conceptual row was last instantiated." ::= { sysOREntry 4 } -- the SNMP group -- -- a collection of objects providing basic instrumentation and -- control of an SNMP entity. snmp OBJECT IDENTIFIER ::= { mib-2 11 } snmpInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of messages delivered to the SNMP entity from the transport service." ::= { snmp 1 } snmpInBadVersions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of SNMP messages which were delivered to the SNMP entity and were for an unsupported SNMP version." ::= { snmp 3 } snmpInBadCommunityNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of community-based SNMP messages (for example, SNMPv1) delivered to the SNMP entity which used an SNMP community name not known to said entity. Also, implementations which authenticate community-based SNMP messages using check(s) in addition to matching the community name (for example, by also checking whether the message originated from a transport address allowed to use a specified community name) MAY include in this value the number of messages which failed the additional check(s). It is strongly RECOMMENDED that Presuhn, et al. Standards Track [Page 8] RFC 3418 MIB for SNMP December 2002 the documentation for any security model which is used to authenticate community-based SNMP messages specify the precise conditions that contribute to this value." ::= { snmp 4 } snmpInBadCommunityUses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of community-based SNMP messages (for example, SNMPv1) delivered to the SNMP entity which represented an SNMP operation that was not allowed for the SNMP community named in the message. The precise conditions under which this counter is incremented (if at all) depend on how the SNMP entity implements its access control mechanism and how its applications interact with that access control mechanism. It is strongly RECOMMENDED that the documentation for any access control mechanism which is used to control access to and visibility of MIB instrumentation specify the precise conditions that contribute to this value." ::= { snmp 5 } snmpInASNParseErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ASN.1 or BER errors encountered by the SNMP entity when decoding received SNMP messages." ::= { snmp 6 } snmpEnableAuthenTraps OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the SNMP entity is permitted to generate authenticationFailure traps. The value of this object overrides any configuration information; as such, it provides a means whereby all authenticationFailure traps may be disabled. Note that it is strongly recommended that this object be stored in non-volatile memory so that it remains constant across re-initializations of the network management system." Presuhn, et al. Standards Track [Page 9] RFC 3418 MIB for SNMP December 2002 ::= { snmp 30 } snmpSilentDrops OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Confirmed Class PDUs (such as GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-PDUs, SetRequest-PDUs, and InformRequest-PDUs) delivered to the SNMP entity which were silently dropped because the size of a reply containing an alternate Response Class PDU (such as a Response-PDU) with an empty variable-bindings field was greater than either a local constraint or the maximum message size associated with the originator of the request." ::= { snmp 31 } snmpProxyDrops OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Confirmed Class PDUs (such as GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-PDUs, SetRequest-PDUs, and InformRequest-PDUs) delivered to the SNMP entity which were silently dropped because the transmission of the (possibly translated) message to a proxy target failed in a manner (other than a time-out) such that no Response Class PDU (such as a Response-PDU) could be returned." ::= { snmp 32 } -- information for notifications -- -- a collection of objects which allow the SNMP entity, when -- supporting a notification originator application, -- to be configured to generate SNMPv2-Trap-PDUs. snmpTrap OBJECT IDENTIFIER ::= { snmpMIBObjects 4 } snmpTrapOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION Presuhn, et al. Standards Track [Page 10] RFC 3418 MIB for SNMP December 2002 "The authoritative identification of the notification currently being sent. This variable occurs as the second varbind in every SNMPv2-Trap-PDU and InformRequest-PDU." ::= { snmpTrap 1 } -- ::= { snmpTrap 2 } this OID is obsolete snmpTrapEnterprise OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The authoritative identification of the enterprise associated with the trap currently being sent. When an SNMP proxy agent is mapping an RFC1157 Trap-PDU into a SNMPv2-Trap-PDU, this variable occurs as the last varbind." ::= { snmpTrap 3 } -- ::= { snmpTrap 4 } this OID is obsolete -- well-known traps snmpTraps OBJECT IDENTIFIER ::= { snmpMIBObjects 5 } coldStart NOTIFICATION-TYPE STATUS current DESCRIPTION "A coldStart trap signifies that the SNMP entity, supporting a notification originator application, is reinitializing itself and that its configuration may have been altered." ::= { snmpTraps 1 } warmStart NOTIFICATION-TYPE STATUS current DESCRIPTION "A warmStart trap signifies that the SNMP entity, supporting a notification originator application, is reinitializing itself such that its configuration is unaltered." ::= { snmpTraps 2 } -- Note the linkDown NOTIFICATION-TYPE ::= { snmpTraps 3 } -- and the linkUp NOTIFICATION-TYPE ::= { snmpTraps 4 } -- are defined in RFC 2863 [RFC2863] Presuhn, et al. Standards Track [Page 11] RFC 3418 MIB for SNMP December 2002 authenticationFailure NOTIFICATION-TYPE STATUS current DESCRIPTION "An authenticationFailure trap signifies that the SNMP entity has received a protocol message that is not properly authenticated. While all implementations of SNMP entities MAY be capable of generating this trap, the snmpEnableAuthenTraps object indicates whether this trap will be generated." ::= { snmpTraps 5 } -- Note the egpNeighborLoss notification is defined -- as { snmpTraps 6 } in RFC 1213 -- the set group -- -- a collection of objects which allow several cooperating -- command generator applications to coordinate their use of the -- set operation. snmpSet OBJECT IDENTIFIER ::= { snmpMIBObjects 6 } snmpSetSerialNo OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating command generator applications to coordinate their use of the SNMP set operation. This object is used for coarse-grain coordination. To achieve fine-grain coordination, one or more similar objects might be defined within each MIB group, as appropriate." ::= { snmpSet 1 } -- conformance information snmpMIBConformance OBJECT IDENTIFIER ::= { snmpMIB 2 } snmpMIBCompliances OBJECT IDENTIFIER ::= { snmpMIBConformance 1 } snmpMIBGroups OBJECT IDENTIFIER ::= { snmpMIBConformance 2 } -- compliance statements Presuhn, et al. Standards Track [Page 12] RFC 3418 MIB for SNMP December 2002 -- ::= { snmpMIBCompliances 1 } this OID is obsolete snmpBasicCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMPv2 entities which implement the SNMPv2 MIB. This compliance statement is replaced by snmpBasicComplianceRev2." MODULE -- this module MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup, snmpBasicNotificationsGroup } GROUP snmpCommunityGroup DESCRIPTION "This group is mandatory for SNMPv2 entities which support community-based authentication." ::= { snmpMIBCompliances 2 } snmpBasicComplianceRev2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement this MIB module." MODULE -- this module MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup, snmpBasicNotificationsGroup } GROUP snmpCommunityGroup DESCRIPTION "This group is mandatory for SNMP entities which support community-based authentication." GROUP snmpWarmStartNotificationGroup DESCRIPTION "This group is mandatory for an SNMP entity which supports command responder applications, and is able to reinitialize itself such that its configuration is unaltered." ::= { snmpMIBCompliances 3 } -- units of conformance -- ::= { snmpMIBGroups 1 } this OID is obsolete -- ::= { snmpMIBGroups 2 } this OID is obsolete -- ::= { snmpMIBGroups 3 } this OID is obsolete Presuhn, et al. Standards Track [Page 13] RFC 3418 MIB for SNMP December 2002 -- ::= { snmpMIBGroups 4 } this OID is obsolete snmpGroup OBJECT-GROUP OBJECTS { snmpInPkts, snmpInBadVersions, snmpInASNParseErrs, snmpSilentDrops, snmpProxyDrops, snmpEnableAuthenTraps } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation and control of an SNMP entity." ::= { snmpMIBGroups 8 } snmpCommunityGroup OBJECT-GROUP OBJECTS { snmpInBadCommunityNames, snmpInBadCommunityUses } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation of a SNMP entity which supports community-based authentication." ::= { snmpMIBGroups 9 } snmpSetGroup OBJECT-GROUP OBJECTS { snmpSetSerialNo } STATUS current DESCRIPTION "A collection of objects which allow several cooperating command generator applications to coordinate their use of the set operation." ::= { snmpMIBGroups 5 } systemGroup OBJECT-GROUP OBJECTS { sysDescr, sysObjectID, sysUpTime, sysContact, sysName, sysLocation, sysServices, sysORLastChange, sysORID, sysORUpTime, sysORDescr } STATUS current DESCRIPTION "The system group defines objects which are common to all managed systems." ::= { snmpMIBGroups 6 } snmpBasicNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { coldStart, authenticationFailure } Presuhn, et al. Standards Track [Page 14] RFC 3418 MIB for SNMP December 2002 STATUS current DESCRIPTION "The basic notifications implemented by an SNMP entity supporting command responder applications." ::= { snmpMIBGroups 7 } snmpWarmStartNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { warmStart } STATUS current DESCRIPTION "An additional notification for an SNMP entity supporting command responder applications, if it is able to reinitialize itself such that its configuration is unaltered." ::= { snmpMIBGroups 11 } snmpNotificationGroup OBJECT-GROUP OBJECTS { snmpTrapOID, snmpTrapEnterprise } STATUS current DESCRIPTION "These objects are required for entities which support notification originator applications." ::= { snmpMIBGroups 12 } -- definitions in RFC 1213 made obsolete by the inclusion of a -- subset of the snmp group in this MIB snmpOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Messages which were passed from the SNMP protocol entity to the transport service." ::= { snmp 2 } -- { snmp 7 } is not used snmpInTooBigs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field was `tooBig'." ::= { snmp 8 } Presuhn, et al. Standards Track [Page 15] RFC 3418 MIB for SNMP December 2002 snmpInNoSuchNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field was `noSuchName'." ::= { snmp 9 } snmpInBadValues OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field was `badValue'." ::= { snmp 10 } snmpInReadOnlys OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number valid SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field was `readOnly'. It should be noted that it is a protocol error to generate an SNMP PDU which contains the value `readOnly' in the error-status field, as such this object is provided as a means of detecting incorrect implementations of the SNMP." ::= { snmp 11 } snmpInGenErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field was `genErr'." ::= { snmp 12 } snmpInTotalReqVars OBJECT-TYPE Presuhn, et al. Standards Track [Page 16] RFC 3418 MIB for SNMP December 2002 SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of MIB objects which have been retrieved successfully by the SNMP protocol entity as the result of receiving valid SNMP Get-Request and Get-Next PDUs." ::= { snmp 13 } snmpInTotalSetVars OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of MIB objects which have been altered successfully by the SNMP protocol entity as the result of receiving valid SNMP Set-Request PDUs." ::= { snmp 14 } snmpInGetRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Get-Request PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 15 } snmpInGetNexts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Get-Next PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 16 } snmpInSetRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Set-Request PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 17 } Presuhn, et al. Standards Track [Page 17] RFC 3418 MIB for SNMP December 2002 snmpInGetResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Get-Response PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 18 } snmpInTraps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Trap PDUs which have been accepted and processed by the SNMP protocol entity." ::= { snmp 19 } snmpOutTooBigs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field was `tooBig.'" ::= { snmp 20 } snmpOutNoSuchNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status was `noSuchName'." ::= { snmp 21 } snmpOutBadValues OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field was `badValue'." ::= { snmp 22 } Presuhn, et al. Standards Track [Page 18] RFC 3418 MIB for SNMP December 2002 -- { snmp 23 } is not used snmpOutGenErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field was `genErr'." ::= { snmp 24 } snmpOutGetRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Get-Request PDUs which have been generated by the SNMP protocol entity." ::= { snmp 25 } snmpOutGetNexts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Get-Next PDUs which have been generated by the SNMP protocol entity." ::= { snmp 26 } snmpOutSetRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Set-Request PDUs which have been generated by the SNMP protocol entity." ::= { snmp 27 } snmpOutGetResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Get-Response PDUs which have been generated by the SNMP protocol entity." ::= { snmp 28 } Presuhn, et al. Standards Track [Page 19] RFC 3418 MIB for SNMP December 2002 snmpOutTraps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The total number of SNMP Trap PDUs which have been generated by the SNMP protocol entity." ::= { snmp 29 } snmpObsoleteGroup OBJECT-GROUP OBJECTS { snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames, snmpInBadValues, snmpInReadOnlys, snmpInGenErrs, snmpInTotalReqVars, snmpInTotalSetVars, snmpInGetRequests, snmpInGetNexts, snmpInSetRequests, snmpInGetResponses, snmpInTraps, snmpOutTooBigs, snmpOutNoSuchNames, snmpOutBadValues, snmpOutGenErrs, snmpOutGetRequests, snmpOutGetNexts, snmpOutSetRequests, snmpOutGetResponses, snmpOutTraps } STATUS obsolete DESCRIPTION "A collection of objects from RFC 1213 made obsolete by this MIB module." ::= { snmpMIBGroups 10 } END 3. Notice on Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Presuhn, et al. Standards Track [Page 20] RFC 3418 MIB for SNMP December 2002 4. Acknowledgments This document is the product of the SNMPv3 Working Group. Some special thanks are in order to the following Working Group members: Randy Bush Jeffrey D. Case Mike Daniele Rob Frye Lauren Heintz Keith McCloghrie Russ Mundy David T. Perkins Randy Presuhn Aleksey Romanov Juergen Schoenwaelder Bert Wijnen This version of the document, edited by Randy Presuhn, was initially based on the work of a design team whose members were: Jeffrey D. Case Keith McCloghrie David T. Perkins Randy Presuhn Juergen Schoenwaelder The previous versions of this document, edited by Keith McCloghrie, was the result of significant work by four major contributors: Jeffrey D. Case Keith McCloghrie Marshall T. Rose Steven Waldbusser Presuhn, et al. Standards Track [Page 21] RFC 3418 MIB for SNMP December 2002 Additionally, the contributions of the SNMPv2 Working Group to the previous versions are also acknowledged. In particular, a special thanks is extended for the contributions of: Alexander I. Alten Dave Arneson Uri Blumenthal Doug Book Kim Curran Jim Galvin Maria Greene Iain Hanson Dave Harrington Nguyen Hien Jeff Johnson Michael Kornegay Deirdre Kostick David Levi Daniel Mahoney Bob Natale Brian O'Keefe Andrew Pearson Dave Perkins Randy Presuhn Aleksey Romanov Shawn Routhier Jon Saperia Juergen Schoenwaelder Bob Stewart Kaj Tesink Glenn Waters Bert Wijnen 5. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change) the objects in this MIB. Presuhn, et al. Standards Track [Page 22] RFC 3418 MIB for SNMP December 2002 It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change) them. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Presuhn, et al. Standards Track [Page 23] RFC 3418 MIB for SNMP December 2002 6.1. Informative References [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB- II", STD 16, RFC 1213, March 1991. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 7. Changes from RFC 1907 These are the changes from RFC 1907: - Corrected typo in copyright statement; - Updated copyright date; - Updated with new editor's name and contact information; - Cosmetic fixes to layout and typography; - Changed title; - Replace introduction with current MIB boilerplate; - Updated references; - Fixed typo in sysORUpTime; - Re-worded description of snmpSilentDrops; - Updated reference to RFC 1573 to 2863; - Added IPR boilerplate as required by RFC 2026; - Weakened authenticationFailure description from MUST to MAY, clarified that it pertains to all SNMP entities; Presuhn, et al. Standards Track [Page 24] RFC 3418 MIB for SNMP December 2002 - Clarified descriptions of snmpInBadCommunityNames and snmpInBadCommunityUses; - Updated module-identity and contact information; - Updated the acknowledgments section; - Replaced references to "manager role", "agent role" and "SNMPv2 entity" with appropriate terms from RFC 2571; - Updated document headers and footers; - Added security considerations, based on current recommendations for MIB modules; - Added NOTIFICATION-GROUP and OBJECT-GROUP constructs for NOTIFICATION-TYPEs and OBJECT-TYPEs that were left unreferenced in RFC 1907; - Fixed typos in sysServices DESCRIPTION; - Changed description of snmpProxyDrops to use terms from architecture; - Changed value used in example for sysObjectID; - Added an abstract; - Deprecated the snmpBasicCompliance MODULE-COMPLIANCE, and added the snmpBasicComplianceRev2 MODULE-COMPLIANCE to take its place; - Updated working group mailing list address; - Added co-chair's address. 8. Editor's Address Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA Phone: +1 408 546 1006 EMail: randy_presuhn@bmc.com Presuhn, et al. Standards Track [Page 25] RFC 3418 MIB for SNMP December 2002 9. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Presuhn, et al. Standards Track [Page 26] snmp-mibs-downloader-1.1/mibrfcs/rfc3419.txt0000644000000000000000000011113211402176071015561 0ustar Network Working Group M. Daniele Request for Comments: 3419 Consultant Category: Standards Track J. Schoenwaelder TU Braunschweig December 2002 Textual Conventions for Transport Addresses 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . 2 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Relationship to Other MIBs . . . . . . . . . . . . . . . . . 4 3.1.1 SNMPv2-TC (TAddress, TDomain) . . . . . . . . . . . . . . . 4 3.1.2 SNMPv2-TM . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress) . . . . . . 5 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 8. Intellectual Property Notice . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 Daniele & Schoenwaelder Standards Track [Page 1] RFC 3419 Textual Conventions for Transport Addresses December 2002 1. Introduction Several MIB modules need to represent transport-layer addresses in a generic way. Typical examples are MIBs for application protocols that can operate over several different transports or application management MIBs that need to model generic communication endpoints. The SMIv2 in STD 58, RFC 2579 [RFC2579] defines the textual conventions TDomain and TAddress to represent generic transport layer endpoints. A generic TAddress value is interpreted in a given transport domain which is identified by a TDomain value. The TDomain is an object identifier which allows MIB authors to extend the set of supported transport domains by providing suitable definitions in standardized or enterprise specific MIB modules. An initial set of TDomain values and concrete TAddress formats has been standardized in STD 62, RFC 3417 [RFC3417]. These definitions are however mixed up with SNMP semantics. Furthermore, definitions for Internet transport protocols over IPv4 and IPv6 are missing. The purpose of this memo is to introduce a set of well-known textual conventions to represent commonly used transport-layer addressing information which is compatible with the original TDomain and TAddress approach and which includes definitions for additional Internet transport protocols over IPv4 and IPv6. This memo also introduces a new textual convention which enumerates the well-known transport domains since such an enumeration provides in many cases sufficient flexibility and is more efficient compared to object identifiers. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Daniele & Schoenwaelder Standards Track [Page 2] RFC 3419 Textual Conventions for Transport Addresses December 2002 3. Overview This MIB module contains definitions for commonly used transport layer addressing information. In particular, it provides the following definitions: 1. Textual conventions for generic transport addresses (TransportAddress) and generic transport domains (TransportDomain). 2. Object identifier registrations for well-known transport domains. 3. An enumeration of the well-known transport domains, called a transport address type (TransportAddressType). 4. A set of textual conventions for the address formats used by well-known transport domains. The DISPLAY-HINTs are aligned with the formats used in URIs [RFC2396], [RFC3291]. The textual conventions for well-known transport domains support scoped Internet addresses. The scope of an Internet address is a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. A scope zone, or simply a zone, is a concrete connected region of topology of a given scope. Note that a zone is a particular instance of a topological region, whereas a scope is the size of a topological region [SCOPED]. Since Internet addresses on devices that connect multiple zones are not necessarily unique, an additional zone index is needed on these devices to select an interface. The textual conventions TransportAddressIPv4z and TransportAddressIPv6z are provided to support Internet transport addresses that include a zone index. In order to support arbitrary combinations of scoped Internet transport addresses, MIB authors SHOULD use a separate TransportDomain or TransportAddressType objects for each TransportAddress object. There are two different ways how new transport domains and textual conventions for the address formats used by those new transport domains can be defined. 1. The MIB module contained in this memo can be updated and new constants for the TransportDomain and the TransportAddressType enumeration can be assigned. 2. Other MIB modules may define additional transport domains and associated textual conventions. Such an extension can not update the TransportAddressType enumeration. Daniele & Schoenwaelder Standards Track [Page 3] RFC 3419 Textual Conventions for Transport Addresses December 2002 It is therefore a MIB designers choice whether he uses (a) a more compact TransportAddressType object with limited extensibility or (b) a more verbose TransportDomain object which allows arbitrary extensions in other MIB modules. The MIB module contained in this memo does NOT define the transport mappings of any particular protocol. Rather, it defines a set of common identifiers and textual conventions that are intended to be used within various transport mappings documents. 3.1 Relationship to Other MIBs This section discusses how the definitions provided by the MIB module contained in this memo relate to definitions in other MIB modules. 3.1.1 SNMPv2-TC (TAddress, TDomain) The SNMPv2-TC MIB module [RFC2579] defines the textual conventions TAddress and TDomain to represent generic transport addresses. A TAddress is an octet string with a size between 1 and 255 octets. Experience has shown that there is sometimes a need to represent unknown transport addresses. The MIB module contained in this memo therefore introduces a new textual convention TransportAddress which is an octet string with a size between 0 and 255 octets and otherwise identical semantics. In other words, the sub-type TransportAddress (SIZE (1..255)) is identical with the TAddress defined in the SNMPv2-TC MIB module [RFC2579]. This MIB module also introduces a new textual convention TransportDomain which is compatible with the TDomain definition so that a complete set of definitions is contained in a single MIB module. New MIB modules SHOULD use the generic TransportDomain, TransportAddressType and TransportAddress definitions defined in this memo. Existing MIB modules may be updated to use the definitions provided in this memo by replacing TDomain with TransportDomain and TAddress with TransportAddress (SIZE (1..255)). 3.1.2 SNMPv2-TM The transport domain values defined in the SNMPv2-TM MIB module [RFC3417] all contain "snmp" as the prefix in their name and are registered under `snmpDomains' (from RFC 2578 [RFC2578]). They were originally intended to describe SNMP transport domains only - but they were later also used for non-SNMP transport endpoints. These definitions are also incomplete since new transport address domains are needed to support (at least) SNMP over UDP over IPv6. Daniele & Schoenwaelder Standards Track [Page 4] RFC 3419 Textual Conventions for Transport Addresses December 2002 The transport domain values defined in this memo are independent of the protocol running over the transport-layer and SHOULD be used for all transport endpoints not carrying SNMP traffic. Programs that interpret transport domain values should in addition accept the transport domain values defined in the SNMPv2-TM MIB module in order to provide interoperability with existing implementations that use the SNMP specific transport domain values. Transport endpoints which carry SNMP traffic SHOULD continue to use the definitions from the SNMPv2-TM MIB module where applicable. They SHOULD use the transport domain values defined in this memo for SNMP transports not defined in the SNMPv2-TM MIB module, such as SNMP over UDP over IPv6. Programs that interpret transport domain values should in addition accept all the transport domain values defined in this memo in order to provide interoperability in cases where it is not possible or desirable to distinguish the protocols running over a transport endpoint. 3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress) The INET-ADDRESS-MIB MIB module [RFC3291] defines the textual conventions InetAddressType and InetAddress to represent Internet network layer endpoints. Some MIB modules use these textual conventions in conjunction with the InetPortNumber textual convention to represent Internet transport-layer endpoints. This approach is fine as long as a MIB models protocols or applications that are specific to the Internet suite of transport protocols. For protocols or applications that can potentially use other transport protocols, the use of the definitions contained in this memo is more appropriate. 4. Definitions TRANSPORT-ADDRESS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; transportAddressMIB MODULE-IDENTITY LAST-UPDATED "200211010000Z" ORGANIZATION "IETF Operations and Management Area" CONTACT-INFO "Juergen Schoenwaelder (Editor) TU Braunschweig Bueltenweg 74/75 38106 Braunschweig, Germany Daniele & Schoenwaelder Standards Track [Page 5] RFC 3419 Textual Conventions for Transport Addresses December 2002 Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de Send comments to ." DESCRIPTION "This MIB module provides commonly used transport address definitions. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3419; see the RFC itself for full legal notices." -- Revision log REVISION "200211010000Z" DESCRIPTION "Initial version, published as RFC 3419." ::= { mib-2 100 } transportDomains OBJECT IDENTIFIER ::= { transportAddressMIB 1 } transportDomainUdpIpv4 OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4 for global IPv4 addresses." ::= { transportDomains 1 } transportDomainUdpIpv6 OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6 for global IPv6 addresses." ::= { transportDomains 2 } transportDomainUdpIpv4z OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4z for scoped IPv4 addresses with a zone index." ::= { transportDomains 3 } transportDomainUdpIpv6z OBJECT-IDENTITY STATUS current Daniele & Schoenwaelder Standards Track [Page 6] RFC 3419 Textual Conventions for Transport Addresses December 2002 DESCRIPTION "The UDP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6z for scoped IPv6 addresses with a zone index." ::= { transportDomains 4 } transportDomainTcpIpv4 OBJECT-IDENTITY STATUS current DESCRIPTION "The TCP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4 for global IPv4 addresses." ::= { transportDomains 5 } transportDomainTcpIpv6 OBJECT-IDENTITY STATUS current DESCRIPTION "The TCP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6 for global IPv6 addresses." ::= { transportDomains 6 } transportDomainTcpIpv4z OBJECT-IDENTITY STATUS current DESCRIPTION "The TCP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4z for scoped IPv4 addresses with a zone index." ::= { transportDomains 7 } transportDomainTcpIpv6z OBJECT-IDENTITY STATUS current DESCRIPTION "The TCP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6z for scoped IPv6 addresses with a zone index." ::= { transportDomains 8 } transportDomainSctpIpv4 OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4 for global IPv4 addresses. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::= { transportDomains 9 } Daniele & Schoenwaelder Standards Track [Page 7] RFC 3419 Textual Conventions for Transport Addresses December 2002 transportDomainSctpIpv6 OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6 for global IPv6 addresses. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::= { transportDomains 10 } transportDomainSctpIpv4z OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4z for scoped IPv4 addresses with a zone index. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::= { transportDomains 11 } transportDomainSctpIpv6z OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6z for scoped IPv6 addresses with a zone index. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::= { transportDomains 12 } transportDomainLocal OBJECT-IDENTITY STATUS current DESCRIPTION "The Posix Local IPC transport domain. The corresponding transport address is of type TransportAddressLocal. The Posix Local IPC transport domain incorporates the well-known UNIX domain sockets." ::= { transportDomains 13 } transportDomainUdpDns OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP transport domain using fully qualified domain names. The corresponding transport address is of type TransportAddressDns." ::= { transportDomains 14 } Daniele & Schoenwaelder Standards Track [Page 8] RFC 3419 Textual Conventions for Transport Addresses December 2002 transportDomainTcpDns OBJECT-IDENTITY STATUS current DESCRIPTION "The TCP transport domain using fully qualified domain names. The corresponding transport address is of type TransportAddressDns." ::= { transportDomains 15 } transportDomainSctpDns OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP transport domain using fully qualified domain names. The corresponding transport address is of type TransportAddressDns." ::= { transportDomains 16 } TransportDomain ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that represents a transport domain. Some possible values, such as transportDomainUdpIpv4, are defined in this module. Other possible values can be defined in other MIB modules." SYNTAX OBJECT IDENTIFIER -- -- The enumerated values of the textual convention below should -- be identical to the last sub-identifier of the OID registered -- for the same domain. -- TransportAddressType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that represents a transport domain. This is the enumerated version of the transport domain registrations in this MIB module. The enumerated values have the following meaning: unknown(0) unknown transport address type udpIpv4(1) transportDomainUdpIpv4 udpIpv6(2) transportDomainUdpIpv6 udpIpv4z(3) transportDomainUdpIpv4z udpIpv6z(4) transportDomainUdpIpv6z tcpIpv4(5) transportDomainTcpIpv4 tcpIpv6(6) transportDomainTcpIpv6 tcpIpv4z(7) transportDomainTcpIpv4z Daniele & Schoenwaelder Standards Track [Page 9] RFC 3419 Textual Conventions for Transport Addresses December 2002 tcpIpv6z(8) transportDomainTcpIpv6z sctpIpv4(9) transportDomainSctpIpv4 sctpIpv6(10) transportDomainSctpIpv6 sctpIpv4z(11) transportDomainSctpIpv4z sctpIpv6z(12) transportDomainSctpIpv6z local(13) transportDomainLocal udpDns(14) transportDomainUdpDns tcpDns(15) transportDomainTcpDns sctpDns(16) transportDomainSctpDns This textual convention can be used to represent transport domains in situations where a syntax of TransportDomain is unwieldy (for example, when used as an index). The usage of this textual convention implies that additional transport domains can only be supported by updating this MIB module. This extensibility restriction does not apply for the TransportDomain textual convention which allows MIB authors to define additional transport domains independently in other MIB modules." SYNTAX INTEGER { unknown(0), udpIpv4(1), udpIpv6(2), udpIpv4z(3), udpIpv6z(4), tcpIpv4(5), tcpIpv6(6), tcpIpv4z(7), tcpIpv6z(8), sctpIpv4(9), sctpIpv6(10), sctpIpv4z(11), sctpIpv6z(12), local(13), udpDns(14), tcpDns(15), sctpDns(16) } TransportAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a generic transport address. A TransportAddress value is always interpreted within the context of a TransportAddressType or TransportDomain value. Every usage of the TransportAddress textual convention MUST Daniele & Schoenwaelder Standards Track [Page 10] RFC 3419 Textual Conventions for Transport Addresses December 2002 specify the TransportAddressType or TransportDomain object which provides the context. Furthermore, MIB authors SHOULD define a separate TransportAddressType or TransportDomain object for each TransportAddress object. It is suggested that the TransportAddressType or TransportDomain is logically registered before the object(s) which use the TransportAddress textual convention if they appear in the same logical row. The value of a TransportAddress object must always be consistent with the value of the associated TransportAddressType or TransportDomain object. Attempts to set a TransportAddress object to a value which is inconsistent with the associated TransportAddressType or TransportDomain must fail with an inconsistentValue error. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." SYNTAX OCTET STRING (SIZE (0..255)) TransportAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d:2d" STATUS current DESCRIPTION "Represents a transport address consisting of an IPv4 address and a port number (as used for example by UDP, TCP and SCTP): octets contents encoding 1-4 IPv4 address network-byte order 5-6 port number network-byte order This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (6)) TransportAddressIPv6 ::= TEXTUAL-CONVENTION DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x]0a:2d" STATUS current DESCRIPTION "Represents a transport address consisting of an IPv6 address and a port number (as used for example by UDP, Daniele & Schoenwaelder Standards Track [Page 11] RFC 3419 Textual Conventions for Transport Addresses December 2002 TCP and SCTP): octets contents encoding 1-16 IPv6 address network-byte order 17-18 port number network-byte order This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (18)) TransportAddressIPv4z ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d%4d:2d" STATUS current DESCRIPTION "Represents a transport address consisting of an IPv4 address, a zone index and a port number (as used for example by UDP, TCP and SCTP): octets contents encoding 1-4 IPv4 address network-byte order 5-8 zone index network-byte order 9-10 port number network-byte order This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (10)) TransportAddressIPv6z ::= TEXTUAL-CONVENTION DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x%4d]0a:2d" STATUS current DESCRIPTION "Represents a transport address consisting of an IPv6 address, a zone index and a port number (as used for example by UDP, TCP and SCTP): octets contents encoding 1-16 IPv6 address network-byte order 17-20 zone index network-byte order 21-22 port number network-byte order This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. Daniele & Schoenwaelder Standards Track [Page 12] RFC 3419 Textual Conventions for Transport Addresses December 2002 However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (22)) TransportAddressLocal ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a POSIX Local IPC transport address: octets contents encoding all POSIX Local IPC address string The Posix Local IPC transport domain subsumes UNIX domain sockets. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." REFERENCE "Protocol Independent Interfaces (IEEE POSIX 1003.1g)" SYNTAX OCTET STRING (SIZE (1..255)) TransportAddressDns ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a DNS domain name followed by a colon ':' (ASCII character 0x3A) and a port number in ASCII. The name SHOULD be fully qualified whenever possible. Values of this textual convention are not directly useable as transport-layer addressing information, and require runtime resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may Daniele & Schoenwaelder Standards Track [Page 13] RFC 3419 Textual Conventions for Transport Addresses December 2002 have TransportAddressDns values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." SYNTAX OCTET STRING (SIZE (1..255)) END 5. Examples This section shows some examples how transport addresses are encoded and rendered using some of the transport address definitions. Description: Unspecified IPv4 address on port 80. Encoding (hex): 000000000050 Display: 0.0.0.0:80 Description: Global IPv4 address on port 80. Encoding (hex): 86A922010050 Display: 134.169.34.1:80 Description: Unspecified IPv6 address on port 80. Encoding (hex): 000000000000000000000000000000000050 Display: [0:0:0:0:0:0:0:0]:80 Description: Global IPv6 address on port 80. Encoding (hex): 108000000000000000080800200C417A0050 Display: [1080:0:0:0:8:800:200C:417A]:80 Description: Link-local IPv6 address with zone-index 42 on port 80. Encoding (hex): FE8000000000000000010000000002000000002A0050 Display: [FE80:0:0:0:1:0:0:200%42]:80 Description: Posix Local IPC address (UNIX domain). Encoding (hex): 2F7661722F6167656E74782F6D6173746572 Display: /var/agentx/master Daniele & Schoenwaelder Standards Track [Page 14] RFC 3419 Textual Conventions for Transport Addresses December 2002 Description: Fully qualified domain name on port 80. Encoding (hex): 7777772E6578616D706C652E6E65743A3830 Display: www.example.net:80 6. Security Considerations The MIB module contained in this memo does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects. Meaningful security considerations can only be written for MIB modules that define concrete management objects. This document has therefore no impact on the security of the Internet. 7. Acknowledgments This document was produced by the Operations and Management Area "IPv6MIB" design team. The authors would like to thank Mark Ellison, Brian Haberman, Mike Heard, Glenn Mansfield Keeni, Erik Nordmark, Shawn A. Routhier, Bill Strahm, Dave Thaler and Bert Wijnen for their comments and suggestions. 8. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Daniele & Schoenwaelder Standards Track [Page 15] RFC 3419 Textual Conventions for Transport Addresses December 2002 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. Informative References [SCOPED] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A. and B. Zill, "IPv6 Scoped Address Architecture", Work in Progress. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, August 1998. [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, December 2001. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Daniele & Schoenwaelder Standards Track [Page 16] RFC 3419 Textual Conventions for Transport Addresses December 2002 Authors' Addresses Mike Daniele Consultant 19 Pinewood Rd Hudson, NH 03051 USA Phone: +1 603 883-6365 EMail: md@world.std.com Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de Daniele & Schoenwaelder Standards Track [Page 17] RFC 3419 Textual Conventions for Transport Addresses December 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Daniele & Schoenwaelder Standards Track [Page 18] snmp-mibs-downloader-1.1/mibrfcs/rfc3433.txt0000644000000000000000000007616111402176071015571 0ustar Network Working Group A. Bierman Request for Comments: 3433 Cisco Systems, Inc. Category: Standards Track D. Romascanu Avaya Inc. K.C. Norseth L-3 Communications December 2002 Entity Sensor Management Information Base 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). Table of Contents 1 The Internet-Standard Management Framework .................. 2 2 Overview .................................................... 2 2.1 Terms ................................................... 2 2.2 Relationship to the Entity MIB .......................... 2 2.3 Relationship to General Thresholding Mechanisms ......... 3 3 MIB Structure ............................................... 3 4 Definitions ................................................. 4 5 Intellectual Property ....................................... 13 6 Acknowledgements ............................................ 14 7 Normative References ........................................ 14 8 Informative References ...................................... 14 9 Security Considerations ..................................... 15 10 Authors' Addresses .......................................... 16 11 Full Copyright Statement .................................... 17 Bierman, et. al. Standards Track [Page 1] RFC 3433 Entity Sensor MIB December 2002 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview There is a need for a standardized way of obtaining information related to the physical sensors which are commonly found in networking equipment. Information such as the current value of the sensor, the current operational status, and the data units precision associated with the sensor, should be represented in a consistent manner for any type of sensor. Physical sensors are represented in the Entity MIB with entPhysicalEntry and an entPhysicalClass value of 'sensor(8)'. The information provided in the ENTITY-SENSOR-MIB module (defined in this document) defines a sparse augmentation of the entPhysicalTable, for entries which represent physical sensors. 2.1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119. [RFC2119] 2.2. Relationship to the Entity MIB The MIB objects defined in this document provide a sparse augmentation to the entPhysicalTable in the Entity MIB, for entries in which the associated entPhysicalClass object is equal to 'sensor(8)'. An agent is expected to maintain an entPhySensorEntry with the same entPhysicalIndex value for each entPhysicalEntry representing a physical sensor. Therefore, implementation of the entityPhysicalGroup is required for agents that implement the Entity Sensor MIB. Bierman, et. al. Standards Track [Page 2] RFC 3433 Entity Sensor MIB December 2002 2.3. Relationship to General Thresholding Mechanisms There are no specialized sensor value thresholding mechanisms defined in this MIB module. Instead, it is recommended that a generalized thresholding MIB, such as the mechanisms defined by the Alarm and Events groups of the Remote Network Monitoring MIB [RFC2819], be used for this purpose. 3. MIB Structure The Entity Sensor MIB contains a single group called the entitySensorValueGroup, which allows objects to convey the current value and status of a physical sensor. The entitySensorValueGroup contains a single table, called the entPhySensorTable, which provides a small number of read-only objects: entPhySensorType This object identifies the type of data units associated with the sensor value. entPhySensorScale This object identifies the (power of 10) scaling factor associated with the sensor value. entPhySensorPrecision This object identifies the number of decimal places of precision associated with the sensor value. entPhySensorValue This object identifies the current value of the sensor. entPhySensorOperStatus This object identifies the current operational status of the sensor (as it's known to the agent). entPhySensorUnitsDisplay This object provides a textual description of the data units represented by the entPhySensorType and entPhySensorScale objects. entPhySensorValueTimeStamp The object identifies the value of sysUpTime at the time the agent last updated the information in the entry. This object is only relevant if the agent uses a polling implementation strategy, (i.e., the associated entPhySensorValueUpdateRate object is greater than zero). Bierman, et. al. Standards Track [Page 3] RFC 3433 Entity Sensor MIB December 2002 entPhySensorValueUpdateRate This object indicates the nature of the agent implementation of the entPhySensorEntry, and contains the (possibly estimated) number of milliseconds that elapse between polling updates of the information in the associated entry. The value zero indicates that the agent always return current data for the entry (as opposed to the data as it was at the last polling interval). 4. Definitions ENTITY-SENSOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC entPhysicalIndex, entityPhysicalGroup FROM ENTITY-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; entitySensorMIB MODULE-IDENTITY LAST-UPDATED "200212160000Z" ORGANIZATION "IETF Entity MIB Working Group" CONTACT-INFO " Andy Bierman Cisco Systems, Inc. Tel: +1 408-527-3711 E-mail: abierman@cisco.com Postal: 170 West Tasman Drive San Jose, CA USA 95134 Dan Romascanu Avaya Inc. Tel: +972-3-645-8414 Email: dromasca@avaya.com Postal: Atidim technology Park, Bldg. #3 Tel Aviv, Israel, 61131 K.C. Norseth L-3 Communications Tel: +1 801-594-2809 Email: kenyon.c.norseth@L-3com.com Postal: 640 N. 2200 West. Bierman, et. al. Standards Track [Page 4] RFC 3433 Entity Sensor MIB December 2002 Salt Lake City, Utah 84116-0850 Send comments to Mailing list subscription info: http://www.ietf.org/mailman/listinfo/entmib " DESCRIPTION "This module defines Entity MIB extensions for physical sensors. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3433; see the RFC itself for full legal notices." REVISION "200212160000Z" DESCRIPTION "Initial version of the Entity Sensor MIB module, published as RFC 3433." ::= { mib-2 99 } entitySensorObjects OBJECT IDENTIFIER ::= { entitySensorMIB 1 } -- entitySensorNotifications OBJECT IDENTIFIER -- ::= { entitySensorMIB 2 } entitySensorConformance OBJECT IDENTIFIER ::= { entitySensorMIB 3 } -- -- Textual Conventions -- EntitySensorDataType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents the Entity Sensor measurement data type associated with a physical sensor value. The actual data units are determined by examining an object of this type together with the associated EntitySensorDataScale object. An object of this type SHOULD be defined together with objects of type EntitySensorDataScale and EntitySensorPrecision. Together, associated objects of these three types are used to identify the semantics of an object of type EntitySensorValue. Bierman, et. al. Standards Track [Page 5] RFC 3433 Entity Sensor MIB December 2002 Valid values are: other(1): a measure other than those listed below unknown(2): unknown measurement, or arbitrary, relative numbers voltsAC(3): electric potential voltsDC(4): electric potential amperes(5): electric current watts(6): power hertz(7): frequency celsius(8): temperature percentRH(9): percent relative humidity rpm(10): shaft revolutions per minute cmm(11),: cubic meters per minute (airflow) truthvalue(12): value takes { true(1), false(2) } " SYNTAX INTEGER { other(1), unknown(2), voltsAC(3), voltsDC(4), amperes(5), watts(6), hertz(7), celsius(8), percentRH(9), rpm(10), cmm(11), truthvalue(12) } EntitySensorDataScale ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents a data scaling factor, represented with an International System of Units (SI) prefix. The actual data units are determined by examining an object of this type together with the associated EntitySensorDataType object. An object of this type SHOULD be defined together with objects of type EntitySensorDataType and EntitySensorPrecision. Together, associated objects of these three types are used to identify the semantics of an object of type EntitySensorValue." REFERENCE "The International System of Units (SI), Bierman, et. al. Standards Track [Page 6] RFC 3433 Entity Sensor MIB December 2002 National Institute of Standards and Technology, Spec. Publ. 330, August 1991." SYNTAX INTEGER { yocto(1), -- 10^-24 zepto(2), -- 10^-21 atto(3), -- 10^-18 femto(4), -- 10^-15 pico(5), -- 10^-12 nano(6), -- 10^-9 micro(7), -- 10^-6 milli(8), -- 10^-3 units(9), -- 10^0 kilo(10), -- 10^3 mega(11), -- 10^6 giga(12), -- 10^9 tera(13), -- 10^12 exa(14), -- 10^15 peta(15), -- 10^18 zetta(16), -- 10^21 yotta(17) -- 10^24 } EntitySensorPrecision ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents a sensor precision range. An object of this type SHOULD be defined together with objects of type EntitySensorDataType and EntitySensorDataScale. Together, associated objects of these three types are used to identify the semantics of an object of type EntitySensorValue. If an object of this type contains a value in the range 1 to 9, it represents the number of decimal places in the fractional part of an associated EntitySensorValue fixed- point number. If an object of this type contains a value in the range -8 to -1, it represents the number of accurate digits in the associated EntitySensorValue fixed-point number. The value zero indicates the associated EntitySensorValue object is not a fixed-point number. Agent implementors must choose a value for the associated EntitySensorPrecision object so that the precision and Bierman, et. al. Standards Track [Page 7] RFC 3433 Entity Sensor MIB December 2002 accuracy of the associated EntitySensorValue object is correctly indicated. For example, a physical entity representing a temperature sensor that can measure 0 degrees to 100 degrees C in 0.1 degree increments, +/- 0.05 degrees, would have an EntitySensorPrecision value of '1', an EntitySensorDataScale value of 'units(9)', and an EntitySensorValue ranging from '0' to '1000'. The EntitySensorValue would be interpreted as 'degrees C * 10'." SYNTAX Integer32 (-8..9) EntitySensorValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents an Entity Sensor value. An object of this type SHOULD be defined together with objects of type EntitySensorDataType, EntitySensorDataScale and EntitySensorPrecision. Together, associated objects of those three types are used to identify the semantics of an object of this data type. The semantics of an object using this data type are determined by the value of the associated EntitySensorDataType object. If the associated EntitySensorDataType object is equal to 'voltsAC(3)', 'voltsDC(4)', 'amperes(5)', 'watts(6), 'hertz(7)', 'celsius(8)', or 'cmm(11)', then an object of this type MUST contain a fixed point number ranging from -999,999,999 to +999,999,999. The value -1000000000 indicates an underflow error. The value +1000000000 indicates an overflow error. The EntitySensorPrecision indicates how many fractional digits are represented in the associated EntitySensorValue object. If the associated EntitySensorDataType object is equal to 'percentRH(9)', then an object of this type MUST contain a number ranging from 0 to 100. If the associated EntitySensorDataType object is equal to 'rpm(10)', then an object of this type MUST contain a number ranging from -999,999,999 to +999,999,999. If the associated EntitySensorDataType object is equal to 'truthvalue(12)', then an object of this type MUST contain either the value 'true(1)' or the value 'false(2)'. Bierman, et. al. Standards Track [Page 8] RFC 3433 Entity Sensor MIB December 2002 If the associated EntitySensorDataType object is equal to 'other(1)' or unknown(2)', then an object of this type MUST contain a number ranging from -1000000000 to 1000000000." SYNTAX Integer32 (-1000000000..1000000000) EntitySensorStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents the operational status of a physical sensor. The value 'ok(1)' indicates that the agent can obtain the sensor value. The value 'unavailable(2)' indicates that the agent presently cannot obtain the sensor value. The value 'nonoperational(3)' indicates that the agent believes the sensor is broken. The sensor could have a hard failure (disconnected wire), or a soft failure such as out- of-range, jittery, or wildly fluctuating readings." SYNTAX INTEGER { ok(1), unavailable(2), nonoperational(3) } -- -- Entity Sensor Table -- entPhySensorTable OBJECT-TYPE SYNTAX SEQUENCE OF EntPhySensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per physical sensor represented by an associated row in the entPhysicalTable." ::= { entitySensorObjects 1 } entPhySensorEntry OBJECT-TYPE SYNTAX EntPhySensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular physical sensor. Bierman, et. al. Standards Track [Page 9] RFC 3433 Entity Sensor MIB December 2002 An entry in this table describes the present reading of a sensor, the measurement units and scale, and sensor operational status. Entries are created in this table by the agent. An entry for each physical sensor SHOULD be created at the same time as the associated entPhysicalEntry. An entry SHOULD be destroyed if the associated entPhysicalEntry is destroyed." INDEX { entPhysicalIndex } -- SPARSE-AUGMENTS ::= { entPhySensorTable 1 } EntPhySensorEntry ::= SEQUENCE { entPhySensorType EntitySensorDataType, entPhySensorScale EntitySensorDataScale, entPhySensorPrecision EntitySensorPrecision, entPhySensorValue EntitySensorValue, entPhySensorOperStatus EntitySensorStatus, entPhySensorUnitsDisplay SnmpAdminString, entPhySensorValueTimeStamp TimeStamp, entPhySensorValueUpdateRate Unsigned32 } entPhySensorType OBJECT-TYPE SYNTAX EntitySensorDataType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of data returned by the associated entPhySensorValue object. This object SHOULD be set by the agent during entry creation, and the value SHOULD NOT change during operation." ::= { entPhySensorEntry 1 } entPhySensorScale OBJECT-TYPE SYNTAX EntitySensorDataScale MAX-ACCESS read-only STATUS current DESCRIPTION "The exponent to apply to values returned by the associated entPhySensorValue object. This object SHOULD be set by the agent during entry creation, and the value SHOULD NOT change during operation." ::= { entPhySensorEntry 2 } Bierman, et. al. Standards Track [Page 10] RFC 3433 Entity Sensor MIB December 2002 entPhySensorPrecision OBJECT-TYPE SYNTAX EntitySensorPrecision MAX-ACCESS read-only STATUS current DESCRIPTION "The number of decimal places of precision in fixed-point sensor values returned by the associated entPhySensorValue object. This object SHOULD be set to '0' when the associated entPhySensorType value is not a fixed-point type: e.g., 'percentRH(9)', 'rpm(10)', 'cmm(11)', or 'truthvalue(12)'. This object SHOULD be set by the agent during entry creation, and the value SHOULD NOT change during operation." ::= { entPhySensorEntry 3 } entPhySensorValue OBJECT-TYPE SYNTAX EntitySensorValue MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent measurement obtained by the agent for this sensor. To correctly interpret the value of this object, the associated entPhySensorType, entPhySensorScale, and entPhySensorPrecision objects must also be examined." ::= { entPhySensorEntry 4 } entPhySensorOperStatus OBJECT-TYPE SYNTAX EntitySensorStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the sensor." ::= { entPhySensorEntry 5 } entPhySensorUnitsDisplay OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the data units that should be used in the display of entPhySensorValue." ::= { entPhySensorEntry 6 } Bierman, et. al. Standards Track [Page 11] RFC 3433 Entity Sensor MIB December 2002 entPhySensorValueTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the status and/or value of this sensor was last obtained by the agent." ::= { entPhySensorEntry 7 } entPhySensorValueUpdateRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the frequency that the agent updates the associated entPhySensorValue object, representing in milliseconds. The value zero indicates: - the sensor value is updated on demand (e.g., when polled by the agent for a get-request), - the sensor value is updated when the sensor value changes (event-driven), - the agent does not know the update rate. " ::= { entPhySensorEntry 8 } -- -- Conformance Section -- entitySensorCompliances OBJECT IDENTIFIER ::= { entitySensorConformance 1 } entitySensorGroups OBJECT IDENTIFIER ::= { entitySensorConformance 2 } entitySensorCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Entity Sensor MIB module." MODULE -- this module MANDATORY-GROUPS { entitySensorValueGroup } Bierman, et. al. Standards Track [Page 12] RFC 3433 Entity Sensor MIB December 2002 MODULE ENTITY-MIB MANDATORY-GROUPS { entityPhysicalGroup } ::= { entitySensorCompliances 1 } -- Object Groups entitySensorValueGroup OBJECT-GROUP OBJECTS { entPhySensorType, entPhySensorScale, entPhySensorPrecision, entPhySensorValue, entPhySensorOperStatus, entPhySensorUnitsDisplay, entPhySensorValueTimeStamp, entPhySensorValueUpdateRate } STATUS current DESCRIPTION "A collection of objects representing physical entity sensor information." ::= { entitySensorGroups 1 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Bierman, et. al. Standards Track [Page 13] RFC 3433 Entity Sensor MIB December 2002 6. Acknowledgements This memo is a product of the Entity MIB working group. It is based on an existing proprietary MIB module written by Cliff Sojourner. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC 2737, December 1999. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. 8. Informative References [RFC2819] Waldbusser, S., "Remote network Monitoring Management Information Base", RFC 2819, May 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Bierman, et. al. Standards Track [Page 14] RFC 3433 Entity Sensor MIB December 2002 9. Security Considerations There is one managed object in this MIB that may contain sensitive information. This is: entPhySensorValue This object may expose the values of particular physical sensors for a device. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to only the objects, and those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Bierman, et. al. Standards Track [Page 15] RFC 3433 Entity Sensor MIB December 2002 10. Authors' Addresses Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-3711 EMail: abierman@cisco.com Dan Romascanu Avaya Inc. Atidim Technology Park, Bldg. #3 Tel Aviv, 61131, Israel Phone: +972-3-545-8414 EMail: dromasca@avaya.com K.C. Norseth L-3 Communications 640 N. 2200 West. Salt Lake City, Utah 84116-0850 Phone: +1 801-594-2809 EMail: kenyon.c.norseth@L-3com.com Bierman, et. al. Standards Track [Page 16] RFC 3433 Entity Sensor MIB December 2002 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bierman, et. al. Standards Track [Page 17] snmp-mibs-downloader-1.1/mibrfcs/rfc3434.txt0000644000000000000000000014360011402176071015563 0ustar Network Working Group A. Bierman Request for Comments: 3434 K. McCloghrie Category:Standards Track Cisco Systems, Inc. December 2002 Remote Monitoring MIB Extensions for High Capacity Alarms 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. Table of Contents 1 The Internet-Standard Management Framework ................... 2 2 Terms ........................................................ 2 3 Overview ..................................................... 2 3.1 Relationship to the Remote Monitoring MIBs ............... 3 4 MIB Structure ................................................ 4 4.1 MIB Group Overview ....................................... 4 4.1.1 High Capacity Alarm Control Group .................. 5 4.1.2 High Capacity Alarm Capabilities ................... 6 4.1.3 High Capacity Alarm Notifications .................. 6 5 Definitions .................................................. 6 6 Intellectual Property ........................................ 21 7 Acknowledgements ............................................. 21 8 Normative References ......................................... 21 9 Informative References ....................................... 22 Bierman & McCloghrie Standards Track [Page 1] RFC 3434 High Capacity Alarm MIB December 2002 10 Security Considerations ..................................... 22 11 Authors' Addresses .......................................... 23 12 Full Copyright Statement .................................... 24 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119. [RFC2119] 3. Overview There is a need for a standardized way of providing the same type of alarm thresholding capabilities for Counter64 objects, as already exists for Counter32 objects. The RMON-1 alarmTable objects and RMON-1 notification types are specific to 32-bit objects, and cannot be used to properly monitor Counter64-based objects. Extensions to these existing constructs which explicitly support Counter64-based objects are needed. These extensions are completely independent of the existing RMON-1 alarm mechanisms. The usage of Counter64 objects is increasing. One of the causes for this increase is the increasing speeds of network interfaces; RFC 2863 [RFC2863] says: As the speed of network media increase, the minimum time in which a 32 bit counter will wrap decreases. For example, a 10Mbs stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that interfaces be polled frequently enough not to miss a counter wrap is increasingly problematic. Bierman & McCloghrie Standards Track [Page 2] RFC 3434 High Capacity Alarm MIB December 2002 and therefore requires: For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported. Of the variables on which thresholds are set using RMON-1's alarmTable, two of the most popular are: ifInOctets and ifOutOctets. Thus, the increasing usage of the 64-bit versions: ifHCInOctets and ifHCOutOctets means that there is an increasing requirement to use RMON-1's thresholding capability for ifHCInOctets and ifHCOutOctets. The RMON-1 Alarm Group is implemented not only by all RMON probes, but also by the SNMP agents in many other types of devices for the purpose of monitoring any of their (non-RMON) integer-valued MIB objects. The fact that it has been so widely implemented indicates its obvious value. Without this extension, that obvious value is becoming incomplete because of its lack of support for 64-bit integers. This extension is the easiest, simplest, and most compatible way for an implementation to overcome that lack of support. 3.1. Relationship to the Remote Monitoring MIBs This MIB is intended to be implemented in Remote Monitoring (RMON) probes, which may also support the RMON-1 MIB [RFC2819]. Such probes may be stand-alone devices, or may be co-located with other networking devices (e.g., ethernet switches and repeaters). The functionality of the High Capacity Alarm Group is a superset of RMON-1's Alarm Group. Thus, one day in the distant future, it is a possibility that RMON-1's Alarm Group will be deprecated in favor of this MIB's High Capacity Alarm Group. However, that day will not come before this document, or one of its successors, reaches the same standardization state as RMON-1. Bierman & McCloghrie Standards Track [Page 3] RFC 3434 High Capacity Alarm MIB December 2002 4. MIB Structure Figure 1: HC-ALARM MIB Functional Structure +---------------------------------------------+ | | | (RMON-1) (HC-ALARM) | | +-----------+ +-----------+ | | | | | | | | | alarm | | hcAlarm | | | | Table | | Table | | | | | | | | | +-----------+ +-----------+ | | | | | | V (RMON-1) V | | +----------------------------------+ | | | | | | | eventTable | | | | | | | +----------------------------------+ | | | | | | | | | | V V | | +---------------+ +----------------+ | | | risingAlarm | | hcRisingAlarm | | | | fallingAlarm | | hcFallingAlarm | | | | Notifications | | Notifications | | | +---------------+ +----------------+ | | (RMON-1) (HC-ALARM) | +---------------------------------------------+ 4.1. MIB Group Overview The HC-ALARM MIB contains three MIB groups: - hcAlarmControlObjects group Controls the configuration of alarms for high capacity MIB object instances. - hcAlarmCapabilities group Describes the high capacity alarm capabilities provided by the agent. - hcAlarmNotifications group Provide new rising and falling threshold notifications for high capacity objects. Bierman & McCloghrie Standards Track [Page 4] RFC 3434 High Capacity Alarm MIB December 2002 4.1.1. High Capacity Alarm Control Group This group contains one table, which is used by a management station to configure high capacity alarm entries. To configure alarm thresholding for Counter64 or CounterBasedGauge64 objects, a management application must configure the hcAlarmTable in a manner similar to how RMON-1's alarmTable is configured. Because the language in some of the DESCRIPTION clauses of objects in the alarmTable is specific to the alarmTable itself, their defined semantics do not allow them to be used for this MIB also. Therefore, the following objects are essentially cloned from the alarmTable to the hcAlarmTable: alarmTable hcAlarmTable ---------- ------------ alarmIndex hcAlarmIndex alarmInterval hcAlarmInterval alarmVariable hcAlarmVariable alarmSampleType hcAlarmSampleType alarmStartupAlarm hcAlarmStartupAlarm alarmRisingEventIndex hcAlarmRisingEventIndex alarmFallingEventIndex hcAlarmFallingEventIndex alarmOwner hcAlarmOwner alarmStatus hcAlarmStatus In addition, the following hcAlarmTable objects are used as high capacity values instead of the corresponding 32-bit version in the alarmTable. alarmTable hcAlarmTable ---------- ------------ alarmValue hcAlarmAbsValue hcAlarmValueStatus alarmRisingThreshold hcAlarmRisingThreshAbsValueLo hcAlarmRisingThreshAbsValueHi hcAlarmRisingThresholdValStatus alarmFallingThreshold hcAlarmFallingThreshAbsValueLo hcAlarmFallingThreshAbsValueHi hcAlarmFallingThresholdValStatus Nevertheless, the hcAlarmTable does have a few differences from the alarmTable: - Counter64 based objects are thresholded properly - an entry is not destroyed if the instance identified by the hcAlarmVariable is not available during a polling interval. Bierman & McCloghrie Standards Track [Page 5] RFC 3434 High Capacity Alarm MIB December 2002 - the RowStatus textual convention is used instead of EntryStatus for the hcAlarmStatus object. - the non-volatile storage of an HC alarm entry is explicitly controlled with a StorageType parameter. - a counter is provided to indicate the number of times the hcAlarmVariable object value could not be retrieved by the agent. 4.1.2. High Capacity Alarm Capabilities This group contains a single scalar object, called hcAlarmCapabilities. It describes the basic high capacity alarm features supported by the agent. 4.1.3. High Capacity Alarm Notifications This group contains two notifications, hcRisingAlarm and hcFallingAlarm. These are generated for high capacity alarms in the same manner and used to convey essentially the same information as RMON-1's risingAlarm and fallingAlarm notifications do for alarmTable-specified alarms. 5. Definitions HC-ALARM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Counter32, Unsigned32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF RowStatus, VariablePointer, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC CounterBasedGauge64 FROM HCNUM-TC rmon, OwnerString, rmonEventGroup FROM RMON-MIB; hcAlarmMIB MODULE-IDENTITY LAST-UPDATED "200212160000Z" ORGANIZATION "IETF RMONMIB Working Group" CONTACT-INFO " Andy Bierman Cisco Systems, Inc. Tel: +1 408 527-3711 Bierman & McCloghrie Standards Track [Page 6] RFC 3434 High Capacity Alarm MIB December 2002 E-mail: abierman@cisco.com Postal: 170 West Tasman Drive San Jose, CA USA 95134 Keith McCloghrie Cisco Systems, Inc. Tel: +1 408 526-5260 E-mail: kzm@cisco.com Postal: 170 West Tasman Drive San Jose, CA USA 95134 Send comments to Mailing list subscription info: http://www.ietf.org/mailman/listinfo/rmonmib " DESCRIPTION "This module defines Remote Monitoring MIB extensions for High Capacity Alarms. Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3434; see the RFC itself for full legal notices." REVISION "200212160000Z" DESCRIPTION "Initial version of the High Capacity Alarm MIB module. This version published as RFC 3434." ::= { rmon 29 } hcAlarmObjects OBJECT IDENTIFIER ::= { hcAlarmMIB 1 } hcAlarmNotifications OBJECT IDENTIFIER ::= { hcAlarmMIB 2 } hcAlarmConformance OBJECT IDENTIFIER ::= { hcAlarmMIB 3 } hcAlarmControlObjects OBJECT IDENTIFIER ::= { hcAlarmObjects 1 } hcAlarmCapabilitiesObjects OBJECT IDENTIFIER ::= { hcAlarmObjects 2 } -- -- Textual Conventions -- HcValueStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type indicates the validity and sign of the data in associated object instances which represent the absolute value of a high capacity numeric quantity. Such an object may be represented with one or more object instances. An object of type HcValueStatus MUST be defined within the same Bierman & McCloghrie Standards Track [Page 7] RFC 3434 High Capacity Alarm MIB December 2002 structure as the object(s) representing the high capacity absolute value. If the associated object instance(s) representing the high capacity absolute value could not be accessed during the sampling interval, and is therefore invalid, then the associated HcValueStatus object will contain the value 'valueNotAvailable(1)'. If the associated object instance(s) representing the high capacity absolute value are valid and actual value of the sample is greater than or equal to zero, then the associated HcValueStatus object will contain the value 'valuePositive(2)'. If the associated object instance(s) representing the high capacity absolute value are valid and the actual value of the sample is less than zero, then the associated HcValueStatus object will contain the value 'valueNegative(3)'. The associated absolute value should be multiplied by -1 to obtain the true sample value." SYNTAX INTEGER { valueNotAvailable(1), valuePositive(2), valueNegative(3) } -- -- High Capacity Alarm Table -- hcAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF HcAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of entries for the configuration of high capacity alarms." ::= { hcAlarmControlObjects 1 } hcAlarmEntry OBJECT-TYPE SYNTAX HcAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the hcAlarmTable. Entries are usually created in this table by management application action, but may also be created by agent action as well." Bierman & McCloghrie Standards Track [Page 8] RFC 3434 High Capacity Alarm MIB December 2002 INDEX { hcAlarmIndex } ::= { hcAlarmTable 1 } HcAlarmEntry ::= SEQUENCE { hcAlarmIndex Integer32, hcAlarmInterval Integer32, hcAlarmVariable VariablePointer, hcAlarmSampleType INTEGER, hcAlarmAbsValue CounterBasedGauge64, hcAlarmValueStatus HcValueStatus, hcAlarmStartupAlarm INTEGER, hcAlarmRisingThreshAbsValueLo Unsigned32, hcAlarmRisingThreshAbsValueHi Unsigned32, hcAlarmRisingThresholdValStatus HcValueStatus, hcAlarmFallingThreshAbsValueLo Unsigned32, hcAlarmFallingThreshAbsValueHi Unsigned32, hcAlarmFallingThresholdValStatus HcValueStatus, hcAlarmRisingEventIndex Integer32, hcAlarmFallingEventIndex Integer32, hcAlarmValueFailedAttempts Counter32, hcAlarmOwner OwnerString, hcAlarmStorageType StorageType, hcAlarmStatus RowStatus } hcAlarmIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer index value used to uniquely identify this high capacity alarm entry." ::= { hcAlarmEntry 1 } hcAlarmInterval OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval in seconds over which the data is sampled and compared with the rising and falling thresholds. When setting this variable, care should be taken in the case of deltaValue sampling - the interval should be set short enough that the sampled variable is very unlikely to increase or decrease by more than 2^63 - 1 during a single sampling interval. Bierman & McCloghrie Standards Track [Page 9] RFC 3434 High Capacity Alarm MIB December 2002 This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 2 } hcAlarmVariable OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the particular variable to be sampled. Only variables that resolve to an ASN.1 primitive type of INTEGER (INTEGER, Integer32, Counter32, Counter64, Gauge, or TimeTicks) may be sampled. Because SNMP access control is articulated entirely in terms of the contents of MIB views, no access control mechanism exists that can restrict the value of this object to identify only those objects that exist in a particular MIB view. Because there is thus no acceptable means of restricting the read access that could be obtained through the alarm mechanism, the probe must only grant write access to this object in those views that have read access to all objects on the probe. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 3 } hcAlarmSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable and calculating the value to be compared against the thresholds. If the value of this object is absoluteValue(1), the value of the selected variable will be compared directly with the thresholds at the end of the sampling interval. If the value of this object is deltaValue(2), the value of the selected variable at the last sample will be subtracted from the current value, and the difference compared with the thresholds. If the associated hcAlarmVariable instance could not be obtained at the previous sample interval, then a delta Bierman & McCloghrie Standards Track [Page 10] RFC 3434 High Capacity Alarm MIB December 2002 sample is not possible, and the value of the associated hcAlarmValueStatus object for this interval will be valueNotAvailable(1). This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 4 } hcAlarmAbsValue OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "The absolute value (i.e., unsigned value) of the hcAlarmVariable statistic during the last sampling period. The value during the current sampling period is not made available until the period is completed. To obtain the true value for this sampling interval, the associated instance of hcAlarmValueStatus must be checked, and the value of this object adjusted as necessary. If the MIB instance could not be accessed during the sampling interval, then this object will have a value of zero and the associated instance of hcAlarmValueStatus will be set to 'valueNotAvailable(1)'." ::= { hcAlarmEntry 5 } hcAlarmValueStatus OBJECT-TYPE SYNTAX HcValueStatus MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the validity and sign of the data for the hcAlarmAbsValue object, as described in the HcValueStatus textual convention." ::= { hcAlarmEntry 6 } hcAlarmStartupAlarm OBJECT-TYPE SYNTAX INTEGER { risingAlarm(1), fallingAlarm(2), risingOrFallingAlarm(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The alarm that may be sent when this entry is first set to Bierman & McCloghrie Standards Track [Page 11] RFC 3434 High Capacity Alarm MIB December 2002 active. If the first sample after this entry becomes active is greater than or equal to the rising threshold and this object is equal to risingAlarm(1) or risingOrFallingAlarm(3), then a single rising alarm will be generated. If the first sample after this entry becomes valid is less than or equal to the falling threshold and this object is equal to fallingAlarm(2) or risingOrFallingAlarm(3), then a single falling alarm will be generated. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 7 } hcAlarmRisingThreshAbsValueLo OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The lower 32 bits of the absolute value for threshold for the sampled statistic. The actual threshold value is determined by the associated instances of the hcAlarmRisingThreshAbsValueHi and hcAlarmRisingThresholdValStatus objects, as follows: ABS(threshold) = hcAlarmRisingThreshAbsValueLo + (hcAlarmRisingThreshAbsValueHi * 2^^32) The absolute value of the threshold is adjusted as required, as described in the HcValueStatus textual convention. These three object instances are conceptually combined to represent the rising threshold for this entry. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is greater than or equal to this threshold and the associated hcAlarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3). After a rising event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches the threshold identified by the hcAlarmFallingThreshAbsValueLo, hcAlarmFallingThreshAbsValueHi, and hcAlarmFallingThresholdValStatus objects. Bierman & McCloghrie Standards Track [Page 12] RFC 3434 High Capacity Alarm MIB December 2002 This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 8 } hcAlarmRisingThreshAbsValueHi OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The upper 32 bits of the absolute value for threshold for the sampled statistic. The actual threshold value is determined by the associated instances of the hcAlarmRisingThreshAbsValueLo and hcAlarmRisingThresholdValStatus objects, as follows: ABS(threshold) = hcAlarmRisingThreshAbsValueLo + (hcAlarmRisingThreshAbsValueHi * 2^^32) The absolute value of the threshold is adjusted as required, as described in the HcValueStatus textual convention. These three object instances are conceptually combined to represent the rising threshold for this entry. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is greater than or equal to this threshold and the associated hcAlarmStartupAlarm is equal to risingAlarm(1) or risingOrFallingAlarm(3). After a rising event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches the threshold identified by the hcAlarmFallingThreshAbsValueLo, hcAlarmFallingThreshAbsValueHi, and hcAlarmFallingThresholdValStatus objects. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 9 } hcAlarmRisingThresholdValStatus OBJECT-TYPE SYNTAX HcValueStatus MAX-ACCESS read-create STATUS current Bierman & McCloghrie Standards Track [Page 13] RFC 3434 High Capacity Alarm MIB December 2002 DESCRIPTION "This object indicates the sign of the data for the rising threshold, as defined by the hcAlarmRisingThresAbsValueLo and hcAlarmRisingThresAbsValueHi objects, as described in the HcValueStatus textual convention. The enumeration 'valueNotAvailable(1)' is not allowed, and the associated hcAlarmStatus object cannot be equal to 'active(1)' if this object is set to this value. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 10 } hcAlarmFallingThreshAbsValueLo OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The lower 32 bits of the absolute value for threshold for the sampled statistic. The actual threshold value is determined by the associated instances of the hcAlarmFallingThreshAbsValueHi and hcAlarmFallingThresholdValStatus objects, as follows: ABS(threshold) = hcAlarmFallingThreshAbsValueLo + (hcAlarmFallingThreshAbsValueHi * 2^^32) The absolute value of the threshold is adjusted as required, as described in the HcValueStatus textual convention. These three object instances are conceptually combined to represent the falling threshold for this entry. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is less than or equal to this threshold and the associated hcAlarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3). After a falling event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches the threshold identified by the hcAlarmRisingThreshAbsValueLo, hcAlarmRisingThreshAbsValueHi, and hcAlarmRisingThresholdValStatus objects. Bierman & McCloghrie Standards Track [Page 14] RFC 3434 High Capacity Alarm MIB December 2002 This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 11 } hcAlarmFallingThreshAbsValueHi OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The upper 32 bits of the absolute value for threshold for the sampled statistic. The actual threshold value is determined by the associated instances of the hcAlarmFallingThreshAbsValueLo and hcAlarmFallingThresholdValStatus objects, as follows: ABS(threshold) = hcAlarmFallingThreshAbsValueLo + (hcAlarmFallingThreshAbsValueHi * 2^^32) The absolute value of the threshold is adjusted as required, as described in the HcValueStatus textual convention. These three object instances are conceptually combined to represent the falling threshold for this entry. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, a single event will be generated. A single event will also be generated if the first sample after this entry becomes valid is less than or equal to this threshold and the associated hcAlarmStartupAlarm is equal to fallingAlarm(2) or risingOrFallingAlarm(3). After a falling event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches the threshold identified by the hcAlarmRisingThreshAbsValueLo, hcAlarmRisingThreshAbsValueHi, and hcAlarmRisingThresholdValStatus objects. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 12 } hcAlarmFallingThresholdValStatus OBJECT-TYPE SYNTAX HcValueStatus MAX-ACCESS read-create STATUS current DESCRIPTION Bierman & McCloghrie Standards Track [Page 15] RFC 3434 High Capacity Alarm MIB December 2002 "This object indicates the sign of the data for the falling threshold, as defined by the hcAlarmFallingThreshAbsValueLo and hcAlarmFallingThreshAbsValueHi objects, as described in the HcValueStatus textual convention. The enumeration 'valueNotAvailable(1)' is not allowed, and the associated hcAlarmStatus object cannot be equal to 'active(1)' if this object is set to this value. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 13 } hcAlarmRisingEventIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the eventEntry that is used when a rising threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid event index. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 14 } hcAlarmFallingEventIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the eventEntry that is used when a falling threshold is crossed. The eventEntry identified by a particular value of this index is the same as identified by the same value of the eventIndex object. If there is no corresponding entry in the eventTable, then no association exists. In particular, if this value is zero, no associated event will be generated, as zero is not a valid event index. This object may not be modified if the associated hcAlarmStatus object is equal to active(1)." ::= { hcAlarmEntry 15 } hcAlarmValueFailedAttempts OBJECT-TYPE Bierman & McCloghrie Standards Track [Page 16] RFC 3434 High Capacity Alarm MIB December 2002 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated hcAlarmVariable instance was polled on behalf of this hcAlarmEntry, (while in the active state) and the value was not available. This counter may experience a discontinuity if the agent restarts, indicated by the value of sysUpTime." ::= { hcAlarmEntry 16 } hcAlarmOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { hcAlarmEntry 17 } hcAlarmStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of non-volatile storage configured for this entry. If this object is equal to 'permanent(4)', then the associated hcAlarmRisingEventIndex and hcAlarmFallingEventIndex objects must be writable." ::= { hcAlarmEntry 18 } hcAlarmStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry MUST NOT exist in the active state unless all objects in the entry have an appropriate value, as described in the description clause for each writable object. The hcAlarmStatus object may be modified if the associated instance of this object is equal to active(1), notInService(2), or notReady(3). All other writable objects may be modified if the associated instance of this object is equal to notInService(2) or notReady(3)." ::= { hcAlarmEntry 19 } Bierman & McCloghrie Standards Track [Page 17] RFC 3434 High Capacity Alarm MIB December 2002 -- -- Capabilities -- hcAlarmCapabilities OBJECT-TYPE SYNTAX BITS { hcAlarmCreation(0), hcAlarmNvStorage(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the high capacity alarm capabilities supported by this agent. If the 'hcAlarmCreation' BIT is set, then this agent allows NMS applications to create entries in the hcAlarmTable. If the 'hcAlarmNvStorage' BIT is set, then this agent allows entries in the hcAlarmTable which will be recreated after a system restart, as controlled by the hcAlarmStorageType object." ::= { hcAlarmCapabilitiesObjects 1 } -- -- Notifications -- hcAlarmNotifPrefix OBJECT IDENTIFIER ::= { hcAlarmNotifications 0 } hcRisingAlarm NOTIFICATION-TYPE OBJECTS { hcAlarmVariable, hcAlarmSampleType, hcAlarmAbsValue, hcAlarmValueStatus, hcAlarmRisingThreshAbsValueLo, hcAlarmRisingThreshAbsValueHi, hcAlarmRisingThresholdValStatus, hcAlarmRisingEventIndex } STATUS current DESCRIPTION "The SNMP notification that is generated when a high capacity alarm entry crosses its rising threshold and generates an event that is configured for sending SNMP traps. The hcAlarmEntry object instances identified in the OBJECTS Bierman & McCloghrie Standards Track [Page 18] RFC 3434 High Capacity Alarm MIB December 2002 clause are from the entry that causes this notification to be generated." ::= { hcAlarmNotifPrefix 1 } hcFallingAlarm NOTIFICATION-TYPE OBJECTS { hcAlarmVariable, hcAlarmSampleType, hcAlarmAbsValue, hcAlarmValueStatus, hcAlarmFallingThreshAbsValueLo, hcAlarmFallingThreshAbsValueHi, hcAlarmFallingThresholdValStatus, hcAlarmFallingEventIndex } STATUS current DESCRIPTION "The SNMP notification that is generated when a high capacity alarm entry crosses its falling threshold and generates an event that is configured for sending SNMP traps. The hcAlarmEntry object instances identified in the OBJECTS clause are from the entry that causes this notification to be generated." ::= { hcAlarmNotifPrefix 2 } -- -- Conformance Section -- hcAlarmCompliances OBJECT IDENTIFIER ::= { hcAlarmConformance 1 } hcAlarmGroups OBJECT IDENTIFIER ::= { hcAlarmConformance 2 } hcAlarmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the High Capacity Alarm MIB." MODULE -- this module MANDATORY-GROUPS { hcAlarmControlGroup, hcAlarmCapabilitiesGroup, hcAlarmNotificationsGroup } MODULE RMON-MIB MANDATORY-GROUPS { rmonEventGroup } ::= { hcAlarmCompliances 1 } Bierman & McCloghrie Standards Track [Page 19] RFC 3434 High Capacity Alarm MIB December 2002 -- Object Groups hcAlarmControlGroup OBJECT-GROUP OBJECTS { hcAlarmInterval, hcAlarmVariable, hcAlarmSampleType, hcAlarmAbsValue, hcAlarmValueStatus, hcAlarmStartupAlarm, hcAlarmRisingThreshAbsValueLo, hcAlarmRisingThreshAbsValueHi, hcAlarmRisingThresholdValStatus, hcAlarmFallingThreshAbsValueLo, hcAlarmFallingThreshAbsValueHi, hcAlarmFallingThresholdValStatus, hcAlarmRisingEventIndex, hcAlarmFallingEventIndex, hcAlarmValueFailedAttempts, hcAlarmOwner, hcAlarmStorageType, hcAlarmStatus } STATUS current DESCRIPTION "A collection of objects used to configure entries for high capacity alarm threshold monitoring purposes." ::= { hcAlarmGroups 1 } hcAlarmCapabilitiesGroup OBJECT-GROUP OBJECTS { hcAlarmCapabilities } STATUS current DESCRIPTION "A collection of objects used to indicate an agent's high capacity alarm threshold monitoring capabilities." ::= { hcAlarmGroups 2 } hcAlarmNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { hcRisingAlarm, hcFallingAlarm } STATUS current DESCRIPTION "A collection of notifications to deliver information related to a high capacity rising or falling threshold event Bierman & McCloghrie Standards Track [Page 20] RFC 3434 High Capacity Alarm MIB December 2002 to a management application." ::= { hcAlarmGroups 3 } END 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgements This memo is a product of the RMONMIB working group, and is based on existing alarmTable objects in the RMON-1 MIB module [RFC2819]. In order to maintain the RMON 'look-and-feel' and semantic consistency, some of Steve Waldbusser's text from [RFC2819] has been adapted for use in this MIB. 8. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Bierman & McCloghrie Standards Track [Page 21] RFC 3434 High Capacity Alarm MIB December 2002 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. 9. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June, 2000. 10. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information. These are: hcAlarmAbsValue hcAlarmValueStatus Bierman & McCloghrie Standards Track [Page 22] RFC 3434 High Capacity Alarm MIB December 2002 These objects are used together, and may expose the values of particular MIB instances, as identified by associated instances of the hcAlarmVariable object. hcAlarmVariable This object identifies the object instance that the associated hcAlarmEntry will periodically sample. Because SNMP access control is articulated entirely in terms of the contents of MIB views, no access control mechanism exists that can restrict the value of this object to identify only those objects that exist in a particular MIB view. Thus, because there is no acceptable means of restricting the read access that could be obtained through the alarm mechanism, the probe must only grant write access to this object in those views that have read access to all objects on the probe. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to only the objects, and to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. Authors' Addresses Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-3711 EMail: abierman@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com Bierman & McCloghrie Standards Track [Page 23] RFC 3434 High Capacity Alarm MIB December 2002 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bierman & McCloghrie Standards Track [Page 24] snmp-mibs-downloader-1.1/mibrfcs/rfc3440.txt0000644000000000000000000022443211402176071015563 0ustar Network Working Group F. Ly Request for Comments: 3440 Pedestal Networks Category: Standards Track G. Bathrick Nokia December 2002 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). Table of Contents 1. The Internet-Standard Management Framework ................. 2 2. Introduction ............................................... 2 3. Relationship of ADSL LINE EXTENSION MIB with standard MIBs . 2 4. Conventions used in the MIB ................................ 2 5. Conformance and Compliance ................................. 6 6. Definitions ................................................ 6 7. Acknowledgments ............................................31 8. References .................................................31 9. Security Considerations ....................................32 10. Intellectual Property Notice ...............................34 11. Authors' Addresses .........................................35 12. Full Copyright Statement ...................................36 Ly & Bathrick Standards Track [Page 1] RFC 3440 ADSL Line Extension MIB December 2002 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction The purpose of this memo is to define a supplemental set of managed objects that is not covered by the ADSL Line MIB as defined in [RFC2662]. This memo addresses the additional objects defined in ITU G.997.1 [ITU G.997.1]. 3. Relationship of ADSL Line Extension MIB with standard MIBs This section outlines the relationship of the ADSL Line Extension MIB with other MIBs described in RFCs and in their various degrees of standardization. In regards to these relationships, the ADSL Line Extension MIB follows conventions as used by the ADSL Line MIB with one exception. The value of the RFC 2863 object, ifOperstatus, SHALL be down(2) when the ADSL line interface is in power state L3, as defined in ITU G.992.1 [ITU G.992.1], which means no power. Its value shall be up(1) if the ADSL line interface is in power state L0 (power on) [ITU G.992.1] or L1 (reduced power). Power Status L2 [ITU G.992.1] is not applicable. 4. Conventions used in the MIB 4.1 Structure The MIB is organized to follow the same structure of the ADSL Line MIB [RFC2662]. Ly & Bathrick Standards Track [Page 2] RFC 3440 ADSL Line Extension MIB December 2002 4.2 Additional Managed Objects Objects specific to the management of ADSL G.Lite as defined in ITU G.992.2 [ITU G.992.2] are: - ADSL Transceiver Unit - Central Office End (ATU-C) Transmission System and Line Mode - Power Management - Counters for Fast Retrains and Failed Fast Retrains - Counters for Severe Error Second-line and Unavailable Second - Alternative profile configuration for the Dual line mode interface Besides the management of G.Lite, another object has been added in order to manage the ADSL line profile. The object is the line mode configuration. 4.2.1 ATU-C ADSL Transmission System Parameters and Line Mode The adslLineConfigTable needs to be extended to cover control of the ATU-C ADSL Transmission system. Three objects are defined to monitor and configure the transmission mode as well as the actual line mode: - Capability - Configuration - Actual Status Transmission modes can further determine the line mode of the ADSL interface. For example, if g9921PotsNonOverlapped(2) is the actual value of the ADSL interface, the interface is operating in Full rate ADSL. If the interface is set to g9922PotsOverlapped(9), the interface is operating in G.Lite mode. Ly & Bathrick Standards Track [Page 3] RFC 3440 ADSL Line Extension MIB December 2002 The transmission mode and the corresponding line mode are defined as: Transmission mode Line Mode ---------------------------------------------------------- Regional Std. (ANSI T1.413) Full [ANSI T1.413] Regional Std. (ETSI DTS/TM06006) Full [ETSI DTS/TM06006] G.992.1 [ITU G992.1] POTS non-overlapped Full G.992.1 POTS overlapped Full G.992.1 Integrated Services Digital Network (ISDN) non-overlapped Full G.992.1 ISDN overlapped Full G.992.1 TCM-ISDN non-overlapped Full G.992.1 TCM-ISDN overlapped Full G.992.2 POTS non-overlapped G.Lite G.992.2 POTS overlapped G.Lite G.992.2 with TCM-ISDN G.Lite non-overlapped G.992.2 with TCM-ISDN overlapped G.Lite G.992.1 TCM-ISDN symmetric Full Table 1: Transmission Mode and Line Mode In case more than one bit is configured for an ADSL interface and both Full and G.Lite modes are selected, the interface is said to be configured in the dual mode. Only one bit can be set in the Actual object that reflects the actual mode of transmission as well as the line mode. 4.2.2 Power Management There are three possible power states for each managed ADSL interface operating in the G.Lite mode. L0 is power on, L1 is power on but reduced and L3 is power off. Power state cannot be configured by an operator but it can be viewed via the ifOperStatus object for the managed ADSL interface. The value of the object ifOperStatus is set to down(2) if the ADSL interface is in power state L3 and is set to up(1) if the ADSL line interface is in power state L0 or L1. An ADSL line power state, if the interface is operating in the G.Lite mode, can also be monitored by the adslLineGlitePowerState object defined in the ADSL Line Extension table. The value of the object enumerates the three power states attainable by the managed interface. Ly & Bathrick Standards Track [Page 4] RFC 3440 ADSL Line Extension MIB December 2002 4.2.3 Fast Retrain Parameters Section 7.4.15 [ITU G.997.1] specifies fast retrain parameters. Fast retrain parameters include two counters: fast retrain count and failed fast retrain count. These two counters have been added to all performance tables. 4.2.4 Counters for Severely Errored Second-line and Unavailable Seconds-line ITU G.997.1 sections 6.2.1.1.7 and 6.2.1.1.9 specify two counters that are not covered by the ADSL Line MIB [RFC2662]. These two counters (severely errored seconds-line and unavailable seconds-line) are added to all the performance tables. Unavailable seconds counts the cumulative number of seconds in which the interface was unavailable during the measured period. This counter does not include the seconds in which unavailability was caused solely by fast retrains and failed fast retrains. Fast retrains and failed fast retrains are considered to be part of the normal network operation and thus are not counted as unavailable errors. 4.2.5 Counters, Interval Buckets and Thresholds For physical-level events, there are counters, current 15-minute and one (up to 96) 15-minute history bucket(s) of "interval-counters", as well as current and previous 1-day interval-counters. Threshold notification can be configured for each physical-layer current 15- minute bucket. There is no requirement for an agent to ensure fixed relationship between the start of a fifteen minute and any wall clock; however some implementations may align the fifteen-minute intervals with quarter hours. Likewise, an implementation may choose to align one day intervals with start of a day. Separate tables are provided for the 96 interval-counters. They are indexed by {ifIndex, AdslAtu*IntervalNumber}. Counters are not reset when an ATU-C or ATU-R is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB). The 15-minute event counters are of the type PerfCurrentCount and PerfIntervalCount. The 1-day event counters are of the type AdslPerfCurrDayCount and AdslPerfPrevDayCount. Both 15-minute and 1- day time elapsed counters are of the type AdslPerfTimeElapsed. Ly & Bathrick Standards Track [Page 5] RFC 3440 ADSL Line Extension MIB December 2002 4.2.6 Alternative profile configuration for the dual line mode interface The object, adslLineConfProfileDualLite, is used only when the interface (the ADSL line and, if applicable, channel) is configured as dual mode, that is, the object adslLineTransAtucConfig is configured with one or more full-rate modes and one or more G.Lite modes. The object adslLineConfProfile defined in ADSL-MIB [RFC2662] is used as the primary full-rate profile. The newly added object in this MIB module, adslLineConfProfileDualLite, is used to describe and configure the G.Lite profile. Note that if one or more full-rate modes are configured, or only G.Lite modes are configured, only the original full-rate profile is needed. The dual-mode profile object is only needed when both full-rate and G.Lite profiles are needed. In this case, it will be set to the value of adslLineConfProfile when 'dynamic' profiles are implemented. When 'static' profiles are implemented, however, similar to the case of the object, adslLineConfProfileName [RFC2662], this object's value will need to algorithmically represent the line. In this case, the value of the line's ifIndex plus a value indicating the line mode type (e.g., G.Lite, Full-rate) will be used. Therefore, the profile's name is a string of the concatenation of the ifIndex and one of the following values: Full or Lite. This string will be fixed-length (i.e., 14) with leading zero(s). For example, the profile name for ifIndex that equals '15' and is a full rate line will be '0000000015Full'. 5. Conformance and Compliance See the conformance and compliance statements within the information module. 6. Definitions ADSL-LINE-EXT-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Integer32, NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC PerfCurrentCount, Ly & Bathrick Standards Track [Page 6] RFC 3440 ADSL Line Extension MIB December 2002 PerfIntervalCount FROM PerfHist-TC-MIB AdslPerfCurrDayCount, AdslPerfPrevDayCount FROM ADSL-TC-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB adslLineAlarmConfProfileEntry, adslLineConfProfileEntry, adslAturIntervalEntry, adslAturPerfDataEntry, adslAtucIntervalEntry, adslAtucPerfDataEntry, adslLineEntry, adslMIB FROM ADSL-LINE-MIB ; adslExtMIB MODULE-IDENTITY LAST-UPDATED "200212100000Z" -- 10 Dec 2002 ORGANIZATION "IETF ADSL MIB Working Group" CONTACT-INFO " Faye Ly Pedestal Networks 6503 Dumbarton Circle, Fremont, CA 94555 Tel: +1 510-578-0158 Fax: +1 510-744-5152 E-Mail: faye@pedestalnetworks.com Gregory Bathrick Nokia Networks 2235 Mercury Way, Fax: +1 707-535-7300 E-Mail: greg.bathrick@nokia.com General Discussion:adslmib@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/adslmib Archive: https://www1.ietf.org/mailman/listinfo/adslmib " DESCRIPTION "Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3440; see the RFC itself for full legal notices. This MIB Module is a supplement to the ADSL-LINE-MIB [RFC2662]." Ly & Bathrick Standards Track [Page 7] RFC 3440 ADSL Line Extension MIB December 2002 REVISION "200212100000Z" -- 10 dec 2002 DESCRIPTION "Initial Version, published as RFC 3440. This MIB module supplements the ADSL-LINE-MIB [RFC2662]." ::= { adslMIB 3 } adslExtMibObjects OBJECT IDENTIFIER ::= { adslExtMIB 1 } AdslTransmissionModeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of ADSL line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and G.Lite respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) " SYNTAX BITS { ansit1413(0), etsi(1), q9921PotsNonOverlapped(2), q9921PotsOverlapped(3), q9921IsdnNonOverlapped(4), q9921isdnOverlapped(5), q9921tcmIsdnNonOverlapped(6), q9921tcmIsdnOverlapped(7), q9922potsNonOverlapeed(8), q9922potsOverlapped(9), q9922tcmIsdnNonOverlapped(10), q9922tcmIsdnOverlapped(11), q9921tcmIsdnSymmetric(12) } adslLineExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslLineExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Ly & Bathrick Standards Track [Page 8] RFC 3440 ADSL Line Extension MIB December 2002 "This table is an extension of RFC 2662. It contains ADSL line configuration and monitoring information. This includes the ADSL line's capabilities and actual ADSL transmission system." ::= { adslExtMibObjects 17 } adslLineExtEntry OBJECT-TYPE SYNTAX AdslLineExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry extends the adslLineEntry defined in [RFC2662]. Each entry corresponds to an ADSL line." AUGMENTS { adslLineEntry } ::= { adslLineExtTable 1 } AdslLineExtEntry ::= SEQUENCE { adslLineTransAtucCap AdslTransmissionModeType, adslLineTransAtucConfig AdslTransmissionModeType, adslLineTransAtucActual AdslTransmissionModeType, adslLineGlitePowerState INTEGER, adslLineConfProfileDualLite SnmpAdminString } adslLineTransAtucCap OBJECT-TYPE SYNTAX AdslTransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The transmission modes, represented by a bitmask that the ATU-C is capable of supporting. The modes available are limited by the design of the equipment." REFERENCE "Section 7.3.2 ITU G.997.1" ::= { adslLineExtEntry 1 } adslLineTransAtucConfig OBJECT-TYPE SYNTAX AdslTransmissionModeType MAX-ACCESS read-write STATUS current DESCRIPTION "The transmission modes, represented by a bitmask, currently enabled by the ATU-C. The manager can only set those modes that are supported by the Ly & Bathrick Standards Track [Page 9] RFC 3440 ADSL Line Extension MIB December 2002 ATU-C. An ATU-C's supported modes are provided by AdslLineTransAtucCap." REFERENCE "Section 7.3.2 ITU G.997.1" ::= { adslLineExtEntry 2 } adslLineTransAtucActual OBJECT-TYPE SYNTAX AdslTransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The actual transmission mode of the ATU-C. During ADSL line initialization, the ADSL Transceiver Unit - Remote terminal end (ATU-R) will determine the mode used for the link. This value will be limited a single transmission mode that is a subset of those modes enabled by the ATU-C and denoted by adslLineTransAtucConfig. After an initialization has occurred, its mode is saved as the 'Current' mode and is persistence should the link go down. This object returns 0 (i.e. BITS with no mode bit set) if the mode is not known." REFERENCE "Section 7.3.2 ITU G.997.1 " ::= { adslLineExtEntry 3 } adslLineGlitePowerState OBJECT-TYPE SYNTAX INTEGER { none(1), l0(2), -- L0 Power on l1(3), -- L1 Power on but reduced l3(4) -- L3 Power off } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object specifies the power state of this interface. L0 is power on, L1 is power on but reduced and L3 is power off. Power state cannot be configured by an operator but it can be viewed via the ifOperStatus object for the managed ADSL interface. The value of the object ifOperStatus is set to down(2) if the ADSL interface is in power state L3 and is set to up(1) if the ADSL line interface is in power state L0 or L1. If the object adslLineTransAtucActual is set to a G.992.2 (G.Lite)-type transmission mode, the value of this object will be one of the valid power states: L0(2), L1(3), or L3(4). Otherwise, its Ly & Bathrick Standards Track [Page 10] RFC 3440 ADSL Line Extension MIB December 2002 value will be none(1)." ::= { adslLineExtEntry 4 } adslLineConfProfileDualLite OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object extends the definition an ADSL line and associated channels (when applicable) for cases when it is configured in dual mode, and operating in a G.Lite-type mode as denoted by adslLineTransAtucActual. Dual mode exists when the object, adslLineTransAtucConfig, is configured with one or more full-rate modes and one or more G.Lite modes simultaneously. When 'dynamic' profiles are implemented, the value of object is equal to the index of the applicable row in the ADSL Line Configuration Profile Table, AdslLineConfProfileTable defined in ADSL-MIB [RFC2662]. In the case when dual-mode has not been enabled, the value of the object will be equal to the value of the object adslLineConfProfile [RFC2662]. When `static' profiles are implemented, in much like the case of the object, adslLineConfProfileName [RFC2662], this object's value will need to algorithmically represent the characteristics of the line. In this case, the value of the line's ifIndex plus a value indicating the line mode type (e.g., G.Lite, Full-rate) will be used. Therefore, the profile's name is a string concatenating the ifIndex and one of the follow values: Full or Lite. This string will be fixed-length (i.e., 14) with leading zero(s). For example, the profile name for ifIndex that equals '15' and is a full rate line, it will be '0000000015Full'." REFERENCE "Section 5.4 Profiles, RFC 2662" ::= { adslLineExtEntry 5 } adslAtucPerfDataExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucPerfDataExtEntry MAX-ACCESS not-accessible Ly & Bathrick Standards Track [Page 11] RFC 3440 ADSL Line Extension MIB December 2002 STATUS current DESCRIPTION "This table extends adslAtucPerfDataTable [RFC2662] with additional ADSL physical line counter information such as unavailable seconds-line and severely errored seconds-line." ::= { adslExtMibObjects 18 } adslAtucPerfDataExtEntry OBJECT-TYPE SYNTAX AdslAtucPerfDataExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry extends the adslAtucPerfDataEntry defined in [RFC2662]. Each entry corresponds to an ADSL line." AUGMENTS { adslAtucPerfDataEntry } ::= { adslAtucPerfDataExtTable 1 } AdslAtucPerfDataExtEntry ::= SEQUENCE { adslAtucPerfStatFastR Counter32, adslAtucPerfStatFailedFastR Counter32, adslAtucPerfStatSesL Counter32, adslAtucPerfStatUasL Counter32, adslAtucPerfCurr15MinFastR PerfCurrentCount, adslAtucPerfCurr15MinFailedFastR PerfCurrentCount, adslAtucPerfCurr15MinSesL PerfCurrentCount, adslAtucPerfCurr15MinUasL PerfCurrentCount, adslAtucPerfCurr1DayFastR AdslPerfCurrDayCount, adslAtucPerfCurr1DayFailedFastR AdslPerfCurrDayCount, adslAtucPerfCurr1DaySesL AdslPerfCurrDayCount, adslAtucPerfCurr1DayUasL AdslPerfCurrDayCount, adslAtucPerfPrev1DayFastR AdslPerfPrevDayCount, adslAtucPerfPrev1DayFailedFastR AdslPerfPrevDayCount, adslAtucPerfPrev1DaySesL AdslPerfPrevDayCount, adslAtucPerfPrev1DayUasL AdslPerfPrevDayCount } adslAtucPerfStatFastR OBJECT-TYPE SYNTAX Counter32 UNITS "line retrains" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reports the count of the number of fast line bs since last agent reset." Ly & Bathrick Standards Track [Page 12] RFC 3440 ADSL Line Extension MIB December 2002 REFERENCE "ITU G.997.1 Section 7.4.15.1 " ::= { adslAtucPerfDataExtEntry 1 } adslAtucPerfStatFailedFastR OBJECT-TYPE SYNTAX Counter32 UNITS "line retrains" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reports the count of the number of failed fast line retrains since last agent reset." REFERENCE "ITU G.997.1 Section 7.4.15.2 " ::= { adslAtucPerfDataExtEntry 2 } adslAtucPerfStatSesL OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reports the count of the number of severely errored seconds-line since last agent reset." REFERENCE "ITU G.997.1 Section 7.2.1.1.7 " ::= { adslAtucPerfDataExtEntry 3 } adslAtucPerfStatUasL OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reports the count of the number of unavailable seconds-line since last agent reset." REFERENCE "ITU G.997.1 Section 7.2.1.1.9 " ::= { adslAtucPerfDataExtEntry 4 } adslAtucPerfCurr15MinFastR OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current 15-minute interval, adslAtucPerfCurr15MinFastR reports the current number of seconds during which there have been Ly & Bathrick Standards Track [Page 13] RFC 3440 ADSL Line Extension MIB December 2002 fast retrains." REFERENCE "ITU G.997.1 Section 7.4.15.1 " ::= { adslAtucPerfDataExtEntry 5 } adslAtucPerfCurr15MinFailedFastR OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current 15-minute interval, adslAtucPerfCurr15MinFailedFastR reports the current number of seconds during which there have been failed fast retrains." REFERENCE "ITU G.997.1 Section 7.4.15.2 " ::= { adslAtucPerfDataExtEntry 6 } adslAtucPerfCurr15MinSesL OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current 15-minute interval, adslAtucPerfCurr15MinSesL reports the current number of seconds during which there have been severely errored seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.1.7 " ::= { adslAtucPerfDataExtEntry 7 } adslAtucPerfCurr15MinUasL OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current 15-minute interval, adslAtucPerfCurr15MinUasL reports the current number of seconds during which there have been unavailable seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.1.9 " ::= { adslAtucPerfDataExtEntry 8 } adslAtucPerfCurr1DayFastR OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current Ly & Bathrick Standards Track [Page 14] RFC 3440 ADSL Line Extension MIB December 2002 DESCRIPTION "For the current day as measured by adslAtucPerfCurr1DayTimeElapsed [RFC2662], adslAtucPerfCurr1DayFastR reports the number of seconds during which there have been fast retrains." REFERENCE "ITU G.997.1 Section 7.4.15.1 " ::= { adslAtucPerfDataExtEntry 9 } adslAtucPerfCurr1DayFailedFastR OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current day as measured by adslAtucPerfCurr1DayTimeElapsed [RFC2662], adslAtucPerfCurr1DayFailedFastR reports the number of seconds during which there have been failed fast retrains." REFERENCE "ITU G.997.1 Section 7.4.15.2 " ::= { adslAtucPerfDataExtEntry 10 } adslAtucPerfCurr1DaySesL OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current day as measured by adslAtucPerfCurr1DayTimeElapsed [RFC2662], adslAtucPerfCurr1DaySesL reports the number of seconds during which there have been severely errored seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.1.7 " ::= { adslAtucPerfDataExtEntry 11 } adslAtucPerfCurr1DayUasL OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current day as measured by adslAtucPerfCurr1DayTimeElapsed [RFC2662], adslAtucPerfCurr1DayUasL reports the number of seconds during which there have been unavailable seconds-line." Ly & Bathrick Standards Track [Page 15] RFC 3440 ADSL Line Extension MIB December 2002 REFERENCE "ITU G.997.1 Section 7.2.1.1.9 " ::= { adslAtucPerfDataExtEntry 12 } adslAtucPerfPrev1DayFastR OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the previous day, adslAtucPerfPrev1DayFastR reports the number of seconds during which there were fast retrains." REFERENCE "ITU G.997.1 Section 7.4.15.1 " ::= { adslAtucPerfDataExtEntry 13 } adslAtucPerfPrev1DayFailedFastR OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the previous day, adslAtucPerfPrev1DayFailedFastR reports the number of seconds during which there were failed fast retrains." REFERENCE "ITU G.997.1 Section 7.4.15.2 " ::= { adslAtucPerfDataExtEntry 14 } adslAtucPerfPrev1DaySesL OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the previous day, adslAtucPerfPrev1DaySesL reports the number of seconds during which there were severely errored seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.1.7 " ::= { adslAtucPerfDataExtEntry 15 } adslAtucPerfPrev1DayUasL OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the previous day, adslAtucPerfPrev1DayUasL reports the number of seconds during which there Ly & Bathrick Standards Track [Page 16] RFC 3440 ADSL Line Extension MIB December 2002 were unavailable seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.1.9 " ::= { adslAtucPerfDataExtEntry 16 } adslAtucIntervalExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAtucIntervalExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATU-C performance data collection interval for ADSL physical interfaces whose IfEntries' ifType is equal to adsl(94)." ::= { adslExtMibObjects 19 } adslAtucIntervalExtEntry OBJECT-TYPE SYNTAX AdslAtucIntervalExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAtucIntervalExtTable." AUGMENTS { adslAtucIntervalEntry } ::= { adslAtucIntervalExtTable 1 } AdslAtucIntervalExtEntry ::= SEQUENCE { adslAtucIntervalFastR PerfIntervalCount, adslAtucIntervalFailedFastR PerfIntervalCount, adslAtucIntervalSesL PerfIntervalCount, adslAtucIntervalUasL PerfIntervalCount } adslAtucIntervalFastR OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current interval, adslAtucIntervalFastR reports the current number of seconds during which there have been fast retrains." ::= { adslAtucIntervalExtEntry 1 } adslAtucIntervalFailedFastR OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current Ly & Bathrick Standards Track [Page 17] RFC 3440 ADSL Line Extension MIB December 2002 DESCRIPTION "For the each interval, adslAtucIntervalFailedFastR reports the number of seconds during which there have been failed fast retrains." ::= { adslAtucIntervalExtEntry 2 } adslAtucIntervalSesL OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the each interval, adslAtucIntervalSesL reports the number of seconds during which there have been severely errored seconds-line." ::= { adslAtucIntervalExtEntry 3 } adslAtucIntervalUasL OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the each interval, adslAtucIntervalUasL reports the number of seconds during which there have been unavailable seconds-line." ::= { adslAtucIntervalExtEntry 4 } adslAturPerfDataExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturPerfDataExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ADSL physical line counters not defined in the adslAturPerfDataTable from the ADSL-LINE-MIB [RFC2662]." ::= { adslExtMibObjects 20 } adslAturPerfDataExtEntry OBJECT-TYPE SYNTAX AdslAturPerfDataExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry extends the adslAturPerfDataEntry defined in [RFC2662]. Each entry corresponds to an ADSL line." AUGMENTS { adslAturPerfDataEntry } ::= { adslAturPerfDataExtTable 1 } Ly & Bathrick Standards Track [Page 18] RFC 3440 ADSL Line Extension MIB December 2002 AdslAturPerfDataExtEntry ::= SEQUENCE { adslAturPerfStatSesL Counter32, adslAturPerfStatUasL Counter32, adslAturPerfCurr15MinSesL PerfCurrentCount, adslAturPerfCurr15MinUasL PerfCurrentCount, adslAturPerfCurr1DaySesL AdslPerfCurrDayCount, adslAturPerfCurr1DayUasL AdslPerfCurrDayCount, adslAturPerfPrev1DaySesL AdslPerfPrevDayCount, adslAturPerfPrev1DayUasL AdslPerfPrevDayCount } adslAturPerfStatSesL OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reports the count of severely errored second-line since the last agent reset." REFERENCE "ITU G.997.1 Section 7.2.1.1.7 " ::= { adslAturPerfDataExtEntry 1 } adslAturPerfStatUasL OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reports the count of unavailable seconds-line since the last agent reset." REFERENCE "ITU G.997.1 Section 7.2.1.2.9 " ::= { adslAturPerfDataExtEntry 2 } adslAturPerfCurr15MinSesL OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current 15-minute interval, adslAturPerfCurr15MinSesL reports the current number of seconds during which there have been severely errored seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.2.7 " Ly & Bathrick Standards Track [Page 19] RFC 3440 ADSL Line Extension MIB December 2002 ::= { adslAturPerfDataExtEntry 3 } adslAturPerfCurr15MinUasL OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current 15-minute interval, adslAturPerfCurr15MinUasL reports the current number of seconds during which there have been available seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.2.9 " ::= { adslAturPerfDataExtEntry 4 } adslAturPerfCurr1DaySesL OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current day as measured by adslAturPerfCurr1DayTimeElapsed [RFC2662], adslAturPerfCurr1DaySesL reports the number of seconds during which there have been severely errored seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.2.7 " ::= { adslAturPerfDataExtEntry 5 } adslAturPerfCurr1DayUasL OBJECT-TYPE SYNTAX AdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the current day as measured by adslAturPerfCurr1DayTimeElapsed [RFC2662], adslAturPerfCurr1DayUasL reports the number of seconds during which there have been unavailable seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.2.9 " ::= { adslAturPerfDataExtEntry 6 } adslAturPerfPrev1DaySesL OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current Ly & Bathrick Standards Track [Page 20] RFC 3440 ADSL Line Extension MIB December 2002 DESCRIPTION "For the previous day, adslAturPerfPrev1DaySesL reports the number of seconds during which there were severely errored seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.2.7 " ::= { adslAturPerfDataExtEntry 7 } adslAturPerfPrev1DayUasL OBJECT-TYPE SYNTAX AdslPerfPrevDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the previous day, adslAturPerfPrev1DayUasL reports the number of seconds during which there were severely errored seconds-line." REFERENCE "ITU G.997.1 Section 7.2.1.2.9 " ::= { adslAturPerfDataExtEntry 8 } adslAturIntervalExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAturIntervalExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each ATU-R performance data collection interval for ADSL physical interfaces whose IfEntries' ifType is equal to adsl(94)." ::= { adslExtMibObjects 21 } adslAturIntervalExtEntry OBJECT-TYPE SYNTAX AdslAturIntervalExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the adslAturIntervalExtTable." AUGMENTS { adslAturIntervalEntry } ::= { adslAturIntervalExtTable 1 } AdslAturIntervalExtEntry ::= SEQUENCE { adslAturIntervalSesL PerfIntervalCount, adslAturIntervalUasL PerfIntervalCount } adslAturIntervalSesL OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" Ly & Bathrick Standards Track [Page 21] RFC 3440 ADSL Line Extension MIB December 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "For the each interval, adslAturIntervalSesL reports the number of seconds during which there have been severely errored seconds-line." ::= { adslAturIntervalExtEntry 1 } adslAturIntervalUasL OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "For the each interval, adslAturIntervalUasL reports the number of seconds during which there have been unavailable seconds-line." ::= { adslAturIntervalExtEntry 2 } adslConfProfileExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslConfProfileExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The adslConfProfileExtTable extends the ADSL line profile configuration information in the adslLineConfProfileTable from the ADSL-LINE-MIB [RFC2662] by adding the ability to configure the ADSL physical line mode." ::= { adslExtMibObjects 22 } adslConfProfileExtEntry OBJECT-TYPE SYNTAX AdslConfProfileExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry extends the adslLineConfProfileEntry defined in [RFC2662]. Each entry corresponds to an ADSL line profile." AUGMENTS { adslLineConfProfileEntry } ::= { adslConfProfileExtTable 1 } AdslConfProfileExtEntry ::= SEQUENCE { adslConfProfileLineType INTEGER } adslConfProfileLineType OBJECT-TYPE Ly & Bathrick Standards Track [Page 22] RFC 3440 ADSL Line Extension MIB December 2002 SYNTAX INTEGER { noChannel (1), -- no channels exist fastOnly (2), -- only fast channel exists interleavedOnly (3), -- only interleaved channel -- exist fastOrInterleaved (4),-- either fast or interleaved -- channels can exist, but -- only one at any time fastAndInterleaved (5)-- both the fast channel and -- the interleaved channel -- exist } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to configure the ADSL physical line mode. It has following valid values: noChannel(1), when no channels exist. fastOnly(2), when only fast channel exists. interleavedOnly(3), when only interleaved channel exist. fastOrInterleaved(4), when either fast or interleaved channels can exist, but only one at any time. fastAndInterleaved(5), when both the fast channel and the interleaved channel exist. In the case when no value has been set, the default Value is noChannel(1). " DEFVAL { fastOnly } ::= { adslConfProfileExtEntry 1 } adslAlarmConfProfileExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AdslAlarmConfProfileExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table extends the adslLineAlarmConfProfileTable and provides threshold parameters for all the counters defined in this MIB module." ::= { adslExtMibObjects 23 } adslAlarmConfProfileExtEntry OBJECT-TYPE SYNTAX AdslAlarmConfProfileExtEntry MAX-ACCESS not-accessible Ly & Bathrick Standards Track [Page 23] RFC 3440 ADSL Line Extension MIB December 2002 STATUS current DESCRIPTION "An entry extends the adslLineAlarmConfProfileTable defined in [RFC2662]. Each entry corresponds to an ADSL alarm profile." AUGMENTS { adslLineAlarmConfProfileEntry } ::= { adslAlarmConfProfileExtTable 1 } AdslAlarmConfProfileExtEntry ::= SEQUENCE { adslAtucThreshold15MinFailedFastR Integer32, adslAtucThreshold15MinSesL Integer32, adslAtucThreshold15MinUasL Integer32, adslAturThreshold15MinSesL Integer32, adslAturThreshold15MinUasL Integer32 } adslAtucThreshold15MinFailedFastR OBJECT-TYPE SYNTAX Integer32(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The first time the value of the corresponding instance of adslAtucPerfCurr15MinFailedFastR reaches or exceeds this value within a given 15-minute performance data collection period, an adslAtucFailedFastRThreshTrap notification will be generated. The value '0' will disable the notification. The default value of this object is '0'." DEFVAL { 0 } ::= { adslAlarmConfProfileExtEntry 1 } adslAtucThreshold15MinSesL OBJECT-TYPE SYNTAX Integer32(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The first time the value of the corresponding instance of adslAtucPerf15MinSesL reaches or exceeds this value within a given 15-minute performance data collection period, an adslAtucSesLThreshTrap notification will be generated. The value '0' will disable the notification. The default value of this object is '0'." Ly & Bathrick Standards Track [Page 24] RFC 3440 ADSL Line Extension MIB December 2002 DEFVAL { 0 } ::= { adslAlarmConfProfileExtEntry 2 } adslAtucThreshold15MinUasL OBJECT-TYPE SYNTAX Integer32(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The first time the value of the corresponding instance of adslAtucPerf15MinUasL reaches or exceeds this value within a given 15-minute performance data collection period, an adslAtucUasLThreshTrap notification will be generated. The value '0' will disable the notification. The default value of this object is '0'." DEFVAL { 0 } ::= { adslAlarmConfProfileExtEntry 3 } adslAturThreshold15MinSesL OBJECT-TYPE SYNTAX Integer32(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The first time the value of the corresponding instance of adslAturPerf15MinSesL reaches or exceeds this value within a given 15-minute performance data collection period, an adslAturSesLThreshTrap notification will be generated. The value '0' will disable the notification. The default value of this object is '0'." DEFVAL { 0 } ::= { adslAlarmConfProfileExtEntry 4 } adslAturThreshold15MinUasL OBJECT-TYPE SYNTAX Integer32(0..900) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The first time the value of the corresponding instance of adslAturPerf15MinUasL reaches or exceeds this value within a given 15-minute performance data collection period, an Ly & Bathrick Standards Track [Page 25] RFC 3440 ADSL Line Extension MIB December 2002 adslAturUasLThreshTrap notification will be generated. The value '0' will disable the notification. The default value of this object is '0'." DEFVAL { 0 } ::= { adslAlarmConfProfileExtEntry 5 } -- definitions adslExtTraps OBJECT IDENTIFIER ::= { adslExtMibObjects 24 } adslExtAtucTraps OBJECT IDENTIFIER ::= { adslExtTraps 1 } adslExtAtucTrapsPrefix OBJECT IDENTIFIER ::= { adslExtAtucTraps 0 } adslAtucFailedFastRThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinFailedFastR } STATUS current DESCRIPTION "Failed Fast Retrains 15-minute threshold reached." ::= { adslExtAtucTrapsPrefix 1 } adslAtucSesLThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinSesL } STATUS current DESCRIPTION "Severely errored seconds-line 15-minute threshold reached." ::= { adslExtAtucTrapsPrefix 2 } adslAtucUasLThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinUasL } STATUS current DESCRIPTION "Unavailable seconds-line 15-minute threshold reached." ::= { adslExtAtucTrapsPrefix 3 } adslExtAturTraps OBJECT IDENTIFIER ::= { adslExtTraps 2 } adslExtAturTrapsPrefix OBJECT IDENTIFIER ::= { adslExtAturTraps 0 } adslAturSesLThreshTrap NOTIFICATION-TYPE OBJECTS { adslAturPerfCurr15MinSesL } STATUS current DESCRIPTION Ly & Bathrick Standards Track [Page 26] RFC 3440 ADSL Line Extension MIB December 2002 "Severely errored seconds-line 15-minute threshold reached." ::= { adslExtAturTrapsPrefix 1 } adslAturUasLThreshTrap NOTIFICATION-TYPE OBJECTS { adslAturPerfCurr15MinUasL } STATUS current DESCRIPTION "Unavailable seconds-line 15-minute threshold reached." ::= { adslExtAturTrapsPrefix 2 } -- conformance information adslExtConformance OBJECT IDENTIFIER ::= { adslExtMIB 2 } adslExtGroups OBJECT IDENTIFIER ::= { adslExtConformance 1 } adslExtCompliances OBJECT IDENTIFIER ::= { adslExtConformance 2 } -- ATU-C agent compliance statements adslExtLineMibAtucCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which represent ADSL ATU-C interfaces." MODULE -- this module MANDATORY-GROUPS { adslExtLineGroup, adslExtLineConfProfileControlGroup, adslExtLineAlarmConfProfileGroup } GROUP adslExtAtucPhysPerfCounterGroup DESCRIPTION "This group is optional. Implementations which require continuous ATU-C physical event counters should implement this group." GROUP adslExtAturPhysPerfCounterGroup DESCRIPTION "This group is optional. Implementations which require continuous ATU-R physical event counters should implement this group." Ly & Bathrick Standards Track [Page 27] RFC 3440 ADSL Line Extension MIB December 2002 GROUP adslExtNotificationsGroup DESCRIPTION "This group is optional. Implementations which support TCA (Threshold Crossing Alert) should implement this group." OBJECT adslAtucThreshold15MinFailedFastR MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable only when static profiles as defined in ADSL Line MIB [RFC2662] are implemented." OBJECT adslAtucThreshold15MinSesL MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable only when static profiles as defined in ADSL Line MIB [RFC2662] are implemented." OBJECT adslAtucThreshold15MinUasL MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable only when static profiles as defined in ADSL Line MIB [RFC2662] are implemented." OBJECT adslAturThreshold15MinSesL MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable only when static profiles as defined in ADSL Line MIB [RFC2662] are implemented." OBJECT adslAturThreshold15MinUasL MIN-ACCESS read-write DESCRIPTION "Read-write access is applicable only when static profiles as defined in ADSL Line MIB [RFC2662] are implemented." OBJECT adslLineConfProfileDualLite MIN-ACCESS read-only DESCRIPTION "Read-only access is applicable only when static profiles as defined in ADSL Line MIB [RFC2662] are implemented." Ly & Bathrick Standards Track [Page 28] RFC 3440 ADSL Line Extension MIB December 2002 ::= { adslExtCompliances 1 } -- units of conformance adslExtLineGroup OBJECT-GROUP OBJECTS { adslLineConfProfileDualLite, adslLineTransAtucCap, adslLineTransAtucConfig, adslLineTransAtucActual, adslLineGlitePowerState } STATUS current DESCRIPTION "A collection of objects providing extended configuration information about an ADSL Line." ::= { adslExtGroups 1 } adslExtAtucPhysPerfCounterGroup OBJECT-GROUP OBJECTS { adslAtucPerfStatFastR, adslAtucPerfStatFailedFastR, adslAtucPerfCurr15MinFastR, adslAtucPerfCurr15MinFailedFastR, adslAtucPerfCurr1DayFastR, adslAtucPerfCurr1DayFailedFastR, adslAtucPerfPrev1DayFastR, adslAtucPerfPrev1DayFailedFastR, adslAtucPerfStatSesL, adslAtucPerfStatUasL, adslAtucPerfCurr15MinSesL, adslAtucPerfCurr15MinUasL, adslAtucPerfCurr1DaySesL, adslAtucPerfCurr1DayUasL, adslAtucPerfPrev1DaySesL, adslAtucPerfPrev1DayUasL, adslAtucIntervalFastR, adslAtucIntervalFailedFastR, adslAtucIntervalSesL, adslAtucIntervalUasL } STATUS current DESCRIPTION "A collection of objects providing raw performance counts on an ADSL Line (ATU-C end)." ::= { adslExtGroups 2 } adslExtAturPhysPerfCounterGroup OBJECT-GROUP OBJECTS { Ly & Bathrick Standards Track [Page 29] RFC 3440 ADSL Line Extension MIB December 2002 adslAturPerfStatSesL, adslAturPerfStatUasL, adslAturPerfCurr15MinSesL, adslAturPerfCurr15MinUasL, adslAturPerfCurr1DaySesL, adslAturPerfCurr1DayUasL, adslAturPerfPrev1DaySesL, adslAturPerfPrev1DayUasL, adslAturIntervalSesL, adslAturIntervalUasL } STATUS current DESCRIPTION "A collection of objects providing raw performance counts on an ADSL Line (ATU-C end)." ::= { adslExtGroups 3 } adslExtLineConfProfileControlGroup OBJECT-GROUP OBJECTS { adslConfProfileLineType } STATUS current DESCRIPTION "A collection of objects providing profile control for the ADSL system." ::= { adslExtGroups 4 } adslExtLineAlarmConfProfileGroup OBJECT-GROUP OBJECTS { adslAtucThreshold15MinFailedFastR, adslAtucThreshold15MinSesL, adslAtucThreshold15MinUasL, adslAturThreshold15MinSesL, adslAturThreshold15MinUasL } STATUS current DESCRIPTION "A collection of objects providing alarm profile control for the ADSL system." ::= { adslExtGroups 5 } adslExtNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { adslAtucFailedFastRThreshTrap, adslAtucSesLThreshTrap, adslAtucUasLThreshTrap, adslAturSesLThreshTrap, adslAturUasLThreshTrap } Ly & Bathrick Standards Track [Page 30] RFC 3440 ADSL Line Extension MIB December 2002 STATUS current DESCRIPTION "The collection of ADSL extension notifications." ::= { adslExtGroups 6 } END 7. Acknowledgments This document is a product of the ADSL MIB Working Group. 8. References 8.1 Normative References [ANSI T1.413] American National Standards Institute, ANSI T1.413, Issue 2, "Standards Project for Interfaces Relating to Carrier to Customer Connection of ADSL Equipment", 1998. [ETSI DTS/TM06006] European Telecommunications Standards Institute "ADSL European Specific Requirements", November 2000. [ITU G.992.1] ITU-T Telecommunication Standardization Sector, "Asymmetric digital subscriber line (ADSL) transceivers", June 1999. [ITU G.992.2] ITU-T Telecommunication Standardization Sector, "Splitterless asymmetric digital subscriber line (ADSL) transceivers", June 1999. [ITU G.997.1] ITU-T Telecommunication Standardization Sector, "Physical Layer Management of Digital Subscriber Transceivers", June 1999. [RFC2026] Bradner S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC2028] Hovey R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2493] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals" RFC 2493, January 1999. Ly & Bathrick Standards Track [Page 31] RFC 3440 ADSL Line Extension MIB December 2002 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, May 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View- based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. 8.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 9. Security Considerations The following security matters should be considered when implementing this MIB. 1) Blocking unauthorized access to the ADSL MIB via the element management system is outside the scope of this document. It should be noted that access to the MIB permits the unauthorized entity to modify the profiles (section 6.4) such that both subscriber service and network operations can be interfered with. Ly & Bathrick Standards Track [Page 32] RFC 3440 ADSL Line Extension MIB December 2002 Subscriber service can be altered by modifying any of a number of service characteristics such as rate partitioning and maximum transmission rates. Network operations can be impacted by modifying notification thresholds such as Signal-to-Noise Ratio (SNR) margins. 2) SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), there is no control over who on the secure network is allowed to access and GET (read) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to only those objects, and to those principals (users) that have legitimate rights to access them. 3) The profile mechanism presented in this document requires specific attention. The implementor of this MIB has a choice of implementing either 'static' or 'dynamic' profiles. This decision must be consistent with the implementation of RFC 2662. In the case of 'static' profiles, the elements of the profile are read-write, as opposed to read-create when 'dynamic' profiles are implemented: - adslConfProfileLineType, - adslAtucThreshold15MinFailedFastR, - adslAtucThreshold15MinSesL, - adslAtucThreshold15MinUasL, - adslAturThreshold15MinSesL, and - adslAturThreshold15MinUasL. This decision also impacts the mechanics of the index, adslLineConfProfileDualLite. When 'static' profiles are implemented, its value is algorithmically set by the system and its value is based on the ifIndex. Hence it is not guaranteed across system reboots. Similar to the handling of adslLineConfProfile [RFC2662], the implementor of this MIB must ensure that the profile object values associated with these indices are maintained across system reboots. Ly & Bathrick Standards Track [Page 33] RFC 3440 ADSL Line Extension MIB December 2002 In the case of dynamic profiles, this object is set by the SNMP manager. The implementor of this MIB may want to provide a view of the profile on a customer-by-customer standpoint, but should be cautious of the dynamic nature of these objects. 4) ADSL layer connectivity from the ATU-R will permit the subscriber to manipulate both the ADSL link directly and the ADSL overhead control channel(AOC)/embedded operations channel (EOC) for their own loop. For example, unchecked or unfiltered fluctuations initiated by the subscriber could generate sufficient notifications to potentially overwhelm either the management interface to the network or the element manager. Other attacks affecting the ATU-R portions of the MIB may also be possible. 10. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11 [RFC2028]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Ly & Bathrick Standards Track [Page 34] RFC 3440 ADSL Line Extension MIB December 2002 11. Authors' Addresses Faye Ly Pedestal Networks 6503 Dumbarton Circle, Fremont, CA 94555 Phone: +1 510-578-0158 Fax: +1 510-744-5152 EMail: faye@pedestalnetworks.com Gregory Bathrick Nokia Networks 2235 Mercury Way, Santa Rosa, CA 95405 Phone: +1 707-362-1125 Fax: +1 707-535-7300 EMail: greg.bathrick@nokia.com Ly & Bathrick Standards Track [Page 35] RFC 3440 ADSL Line Extension MIB December 2002 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ly & Bathrick Standards Track [Page 36] snmp-mibs-downloader-1.1/mibrfcs/rfc3498.txt0000644000000000000000000023155511402176071015604 0ustar Network Working Group J. Kuhfeld Request for Comments: 3498 J. Johnson Category:Standards Track M. Thatcher Redback Networks March 2003 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. Table of Contents 1. Introduction................................................. 2 2. The Internet-Standard Management Framework................... 2 3. Overview..................................................... 2 4. Definitions.................................................. 4 5. Intellectual Property........................................39 6. Acknowledgments..............................................40 7. Normative References.........................................40 8. Informative References.......................................40 9. Security Considerations......................................41 10. Editors' Addresses...........................................42 11. Full Copyright Statement.....................................43 Kuhfeld, et al. Standards Track [Page 1] RFC 3498 SONET LINEAR APS MIB March 2003 1. Introduction This memo defines a portion of the Management Information Base (MIB) used for managing SONET linear Automatic Protection Switching (APS) architectures. Two linear APS architectures are supported, the 1+1 architecture and the 1:n architecture. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview These objects are used to control and manage SONET linear APS architectures. Ring APS groups are not currently supported by this MIB. The MIB includes three scalars, containing counts of APS groups and SONET LTEs, a notification enable object, and six tables. The apsMapTable contains entries for each SONET LTE interface available on the system. The table serves two purposes. It can be used to locate SONET LTE interfaces that are not currently included in APS groups. It also provides a mapping from InterfaceIndex to group name and channel number for those SONET LTE interfaces that are included in APS groups. Entries in apsMapTable cannot be added or deleted through operations defined in this MIB. However, an apsMapEntry may be added or deleted through other system mechanisms, such as hot swap. Also, existing entries cannot be directly modified and instead, such modifications occur as a result of side-effects of operations on the apsChanConfigTable. The apsChanConfigTable supports addition, modification and deletion of entries representing linear APS channels. Entries are indexed by a text group name and integer channel number. Each entry contains an InterfaceIndex value identifying the SONET LTE used for the channel and the priority of the channel. A side effect of row creation or Kuhfeld, et al. Standards Track [Page 2] RFC 3498 SONET LINEAR APS MIB March 2003 deletion is the setting of map entry fields. Creation of two or more entries in this table with a common group name index and consecutive channel numbers is the first step in the creation and configuration of an APS group. It is not necessary to create channel numbers in order; however, before an APS group is made active, the set of channels must begin with channel number 0 (for architectures other than onePlusOneOptimized) or channel number 1 (for the onePlusOneOptimized architecture) and must have consecutive channel numbers not exceeding 14. Note that the term null channel, which is used throughout this document, refers to the protection line. The apsConfigTable supports addition, modification, and deletion of entries representing linear APS groups. Entries are indexed by a text group name. Each entry contains parameters that specify the configuration of a particular linear APS group. Entries are created in this table after a set of channels are created in the apsChanConfigTable. To successfully set an instance of apsConfigRowStatus to active the apsConfigEntry must contain valid values and all associated apsChanConfigEntry rows must be valid and produce a consecutive set of channels beginning with channel number 0 or 1, depending on the selected architecture. The apsCommandTable provides linear APS commands that support protection switching and the ability to modify APS operation. Entries in this table are created as a side effect of setting the associated apsConfigRowStatus object to active. Entries in this table are deleted if the associated apsConfigRowStatus object is set to any value except active. The apsChanStatusTable provides individual channel statistics. The apsStatusTable provides group level statistics. An APS group is created and configured with the following sequence of events: CHANNEL CONFIGURATION Create an entry in the apsChanConfigTable. Set the apsChanConfigGroupName in an apsChanConfigEntry to a user-friendly text string which will serve as the APS group name. The string must not be equal to the apsConfigName of an existing apsConfigEntry with apsConfigRowStatus set to active, since a channel cannot be added to an active group. The string may be set equal to the apsConfigName of a row which is currently not set to active, or it may be set to a string which does not currently exist in any instance of apsConfigName. A channel number is entered in apsChanConfigNumber. A channel priority is entered in apsChanConfigPriority, if the Kuhfeld, et al. Standards Track [Page 3] RFC 3498 SONET LINEAR APS MIB March 2003 intended architecture is 1:n. apsChanConfigPriority is ignored if the architecture is 1+1. The InterfaceIndex value of a SONET LTE interface is entered in apsChanConfigIfIndex. This step is repeated for all apsChanConfigEntry instances which are to be included in the APS group. ACTIVATING THE GROUP If the apsChanConfigGroupName does not exist in an instance of apsConfigName, an apsConfigEntry is created with the apsChanConfigGroupName value used as the index for the row. The apsConfigRowStatus value may be set to createAndGo. The apsGroupConfigEntry and apsChanConfigEntry instances with matching name fields will be checked for consistency. If any errors in the channel numbers, architecture or configuration are uncovered the apsConfigRowStatus set will return inconsistentValue, otherwise noError is returned. If the apsChanConfigGroupName value used in channel configuration exists in a previously created, inactive apsConfigEntry instance, the apsConfigRowStatus value may be set to active. An agent is not required to process SNMP Set Requests that affect multiple control objects within this MIB. This is intended to simplify the processing of Set Requests for the various control tables by eliminating the possibility that a single Set PDU will contain multiple varbinds which are in conflict, such as a PDU which both activates a given apsConfigEntry while at the same time it deactivates an associated apsChanConfigEntry. 4. Definitions APS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Gauge32, Counter32, Integer32, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, StorageType FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB Kuhfeld, et al. Standards Track [Page 4] RFC 3498 SONET LINEAR APS MIB March 2003 ifIndex, InterfaceIndex FROM IF-MIB MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; apsMIB MODULE-IDENTITY LAST-UPDATED "200302280000Z" -- February 28, 2003 ORGANIZATION "IETF AToMMIB Working Group" CONTACT-INFO " Jim Kuhfeld Postal: RedBack Networks. Inc. 300 Holger Way San Jose, CA 95134-1362 Tel: +1 408 750 5465 Email: jkuhfeld@redback.com Jeff Johnson Postal: RedBack Networks. Inc. 300 Holger Way San Jose, CA 95134-1362 Tel: +1 408 750 5460 Email: jeff@redback.com Michael Thatcher Postal: RedBack Networks. Inc. 300 Holger Way San Jose, CA 95134-1362 Tel: +1 408 750 5449 Email: thatcher@redback.com" DESCRIPTION "This management information module supports the configuration and management of SONET linear APS groups. The definitions and descriptions used in this MIB have been derived from Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria, GR-253-CORE Issue 3, September 2000, section 5.3. The MIB is also consistent with the Multiplex Section Protection (MSP) protocol as specified in ITU-T Recommendation G.783, Characteristics of synchronous digital hierarchy (SDH) equipment function blocks, Annex A and B. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3498; see the RFC itself for full legal notices. " Kuhfeld, et al. Standards Track [Page 5] RFC 3498 SONET LINEAR APS MIB March 2003 REVISION "200302280000Z" -- February 28, 2003 DESCRIPTION "Initial version of this MIB, published as RFC 3498." ::= { transmission 49 } apsMIBObjects OBJECT IDENTIFIER ::= { apsMIB 1 } apsMIBNotifications OBJECT IDENTIFIER ::= { apsMIB 2 } apsMIBConformance OBJECT IDENTIFIER ::= { apsMIB 3 } ApsK1K2 ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This Textual Convention describes an object that stores a SONET K1 and K2 byte APS protocol field. K1 is located in the first octet, K2 is located in the second octet. Bits are numbered from left to right. Bits 1-4 of the K1 byte indicate a request. 1111 Lockout of Protection 1110 Forced Switch 1101 SF - High Priority 1100 SF - Low Priority 1011 SD - High Priority 1010 SD - Low Priority 1001 not used 1000 Manual Switch 0111 not used 0110 Wait-to-Restore 0101 not used 0100 Exercise 0011 not used 0010 Reverse Request 0001 Do Not Revert 0000 No Request Bits 5-8 of the K1 byte indicate the channel associated with the request defined in bits 1-4. 0000 is the Null channel. Kuhfeld, et al. Standards Track [Page 6] RFC 3498 SONET LINEAR APS MIB March 2003 1-14 are working channels. 15 is the extra traffic channel Bits 1-4 of the K2 byte indicate a channel. The channel is defined with the same syntax as K1 Bits 5-8. Bit 5 of the K2 byte indicates the architecture. 0 if the architecture is 1+1 1 if the architecture is 1:n Bits 6-8 of the K2 byte indicates the mode. 000 - 011 are reserved for future use 100 indicates the mode is unidirectional 101 indicates the mode is bidirectional 110 RDI-L 111 AIS-L " REFERENCE "Bellcore (Telcordia Technologies) GR-253-CORE, Issue 3, September 2000, 5.3.5." SYNTAX OCTET STRING (SIZE (2)) ApsSwitchCommand ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An APS switch command allows a user to perform protection switch actions. If the APS switch command cannot be executed because an equal or higher priority request is in effect, an inconsistentValue error is returned. The Switch command values are: noCmd This value should be returned by a read request when no switch command has been written to the object in question since initialization. This value may not be used in a write operation. If noCmd is used in a write operation a wrongValue error is returned. Kuhfeld, et al. Standards Track [Page 7] RFC 3498 SONET LINEAR APS MIB March 2003 clear Clears all of the switch commands listed below for the specified channel. lockoutOfProtection Prevents any of the working channels from switching to the protection line. The specified channel should be the protection channel, otherwise an inconsistentValue error is returned. forcedSwitchWorkToProtect Switches the specified working channel to the protection line. If the protection channel is specified an inconsistentValue error is returned. forcedSwitchProtectToWork Switches the working channel back from the protection line to the working line. The specified channel should be the protection channel, otherwise an inconsistentValue error is returned. manualSwitchWorkToProtect Switches the specified working channel to the protection line. If the protection channel is specified an inconsistentValue error is returned. manualSwitchProtectToWork Switches the working channel back from the protection line to the working line. The specified channel should be the protection channel, otherwise an inconsistentValue error is returned. exercise Exercises the protocol for a protection switch of the specified channel by issuing an Exercise request for that channel and checking the response on the APS channel. " SYNTAX INTEGER { noCmd(1), clear(2), lockoutOfProtection(3), forcedSwitchWorkToProtect(4), forcedSwitchProtectToWork(5), Kuhfeld, et al. Standards Track [Page 8] RFC 3498 SONET LINEAR APS MIB March 2003 manualSwitchWorkToProtect(6), manualSwitchProtectToWork(7), exercise(8) } ApsControlCommand ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An APS control command applies only to LTE that support the 1:n architecture and performs the following actions. The Control command values are: noCmd This value should be returned by a read request when no control command has been written to the object in question since initialization. This value may not be used in a write operation. If noCmd is used in a write operation a wrongValue error is returned. lockoutWorkingChannel Prevents the specified working channel from switching to the protection line. If the protection line is specified an inconsistentValue error is returned. clearLockoutWorkingChannel Clears the lockout a working channel command for the channel specified. If the protection line is specified an inconsistentValue error is returned." SYNTAX INTEGER { noCmd(1), lockoutWorkingChannel(2), clearLockoutWorkingChannel(3) } -- -- APS Configuration Table -- -- This table supports the addition, configuration and deletion of APS -- groups. -- apsConfig OBJECT IDENTIFIER ::= { apsMIBObjects 1 } Kuhfeld, et al. Standards Track [Page 9] RFC 3498 SONET LINEAR APS MIB March 2003 apsConfigGroups OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of APS groups. This count includes all rows in apsConfigTable, regardless of the value of apsConfigRowStatus." ::= { apsConfig 1 } apsConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF ApsConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the APS groups that have been configured on the system." ::= { apsConfig 2 } apsConfigEntry OBJECT-TYPE SYNTAX ApsConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apsConfigTable." INDEX { IMPLIED apsConfigName } ::= { apsConfigTable 1 } ApsConfigEntry ::= SEQUENCE { apsConfigName SnmpAdminString, apsConfigRowStatus RowStatus, apsConfigMode INTEGER, apsConfigRevert INTEGER, apsConfigDirection INTEGER, apsConfigExtraTraffic INTEGER, apsConfigSdBerThreshold Integer32, apsConfigSfBerThreshold Integer32, apsConfigWaitToRestore Integer32, apsConfigCreationTime TimeStamp, apsConfigStorageType StorageType } apsConfigName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A textual name for the APS group." ::= { apsConfigEntry 1 } Kuhfeld, et al. Standards Track [Page 10] RFC 3498 SONET LINEAR APS MIB March 2003 apsConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this APS group entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. Also, all associated apsChanConfigEntry rows must represent a set of consecutive channel numbers beginning with 0 or 1, depending on the selected architecture. When set to notInService changes may be made to apsConfigMode, apsConfigRevert, apsConfigDirection, apsConfigExtraTraffic, apsConfigSdBerThreshold, apsConfigSfBerThreshold, and apsConfigWaitToRestore. Also, associated apsChanConfigTable objects may be added, deleted and modified." ::= { apsConfigEntry 2 } apsConfigMode OBJECT-TYPE SYNTAX INTEGER { onePlusOne(1), oneToN(2), onePlusOneCompatible(3), onePlusOneOptimized(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The architecture of the APS group. onePlusOne The 1+1 architecture permanently bridges the working line to the protection line. oneToN The 1:n architecture allows one protection channel to protect up to n working channels. When a fault is detected on one of the n working channels that channel is bridged over the protection channel. onePlusOneCompatible Kuhfeld, et al. Standards Track [Page 11] RFC 3498 SONET LINEAR APS MIB March 2003 This refers to 1 + 1 bidirectional switching compatible with 1:n bidirectional switching as specified in ITU-T Recommendation G.783 (04/97) section A.3.4.1. Since this mode necessitates bidirectional switching, apsConfigDirection must be set to bidirectional whenever onePlusOneCompatible is set. onePlusOneOptimized This refers to 1 + 1 bidirectional switching optimized for a network using predominantly 1 + 1 bidirectional switching as specified in ITU-T Recommendation G.783 (04/97) section B.1. Since this mode necessitates bidirectional switching, apsConfigDirection must be set to bidirectional whenever onePlusOneOptimized is set. This object may not be modified if the associated apsConfigRowStatus object is equal to active(1)." DEFVAL {onePlusOne} ::= { apsConfigEntry 3 } apsConfigRevert OBJECT-TYPE SYNTAX INTEGER { nonrevertive(1), revertive(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The revertive mode of the APS group. nonrevertive Traffic remains on the protection line until another switch request is received. revertive When the condition that caused a switch to the protection line has been cleared the signal is switched back to the working line. Since switching is revertive with the 1:n architecture, apsConfigRevert must be set to revertive if apsConfigMode is set to oneToN. Switching may optionally be revertive with the 1+1 architecture. This object may not be modified if the associated apsConfigRowStatus object is equal to active(1). " DEFVAL { nonrevertive } ::= { apsConfigEntry 4 } Kuhfeld, et al. Standards Track [Page 12] RFC 3498 SONET LINEAR APS MIB March 2003 apsConfigDirection OBJECT-TYPE SYNTAX INTEGER { unidirectional(1), bidirectional(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The directional mode of the APS group. unidirectional The unidirectional mode provides protection in one direction. bidirectional The bidirectional mode provides protection in both directions. This object may not be modified if the associated apsConfigRowStatus object is equal to active(1). " DEFVAL {unidirectional} ::= { apsConfigEntry 5 } apsConfigExtraTraffic OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables or disables the transfer of extra traffic on the protection channel in a 1:n architecture. This object must be set to disabled if the architecture is 1+1. It may be necessary to disable this in order to interwork with other SONET network elements that don't support extra traffic. This object may not be modified if the associated apsConfigRowStatus object is equal to active(1). " DEFVAL { disabled } ::= { apsConfigEntry 6 } apsConfigSdBerThreshold OBJECT-TYPE SYNTAX Integer32 (5..9) MAX-ACCESS read-create STATUS current DESCRIPTION "The Signal Degrade Bit Error Rate. The negated value of this number is used as the exponent of 10 for computing the threshold value for the Bit Error Rate (BER). For example, a value of 5 indicates a BER threshold of 10^-5. Kuhfeld, et al. Standards Track [Page 13] RFC 3498 SONET LINEAR APS MIB March 2003 This object may be modified if the associated apsConfigRowStatus object is equal to active(1)." DEFVAL { 5 } ::= { apsConfigEntry 7 } apsConfigSfBerThreshold OBJECT-TYPE SYNTAX Integer32 (3..5) MAX-ACCESS read-create STATUS current DESCRIPTION "The Signal Failure Bit Error Rate. The negated value of this number is used as the exponent of 10 for computing the threshold value for the Bit Error Rate (BER). For example, a value of 5 indicates a BER threshold of 10^-5. This object may be modified if the associated apsConfigRowStatus object is equal to active(1)." DEFVAL { 3 } ::= { apsConfigEntry 8 } apsConfigWaitToRestore OBJECT-TYPE SYNTAX Integer32 (0..720) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Wait To Restore period in seconds. After clearing of a condition that necessitated an automatic switch, the wait to restore period must elapse before reverting. This is intended to avoid rapid switch oscillations. GR-253-CORE specifies a Wait To Restore range of 5 to 12 minutes. G.783 defines a 5 to 12 minute Wait To Restore range in section 5.4.1.1.3, but also allows for a shorter WTR period in Table 2-1, WaitToRestore value (MI_WTRtime: 0..(5)..12 minutes). This object may not be modified if the associated apsConfigRowStatus object is equal to active(1)." DEFVAL { 300 } ::= { apsConfigEntry 9 } Kuhfeld, et al. Standards Track [Page 14] RFC 3498 SONET LINEAR APS MIB March 2003 apsConfigCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the row was created" ::= { apsConfigEntry 10 } apsConfigStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { apsConfigEntry 11 } -- -- APS Status Table -- -- This table provides APS group statistics. -- apsStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF ApsStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides status information about APS groups that have been configured on the system." ::= { apsMIBObjects 2 } apsStatusEntry OBJECT-TYPE SYNTAX ApsStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apsStatusTable." AUGMENTS { apsConfigEntry } ::= { apsStatusTable 1 } ApsStatusEntry ::= SEQUENCE { apsStatusK1K2Rcv ApsK1K2, apsStatusK1K2Trans ApsK1K2, apsStatusCurrent BITS, Kuhfeld, et al. Standards Track [Page 15] RFC 3498 SONET LINEAR APS MIB March 2003 apsStatusModeMismatches Counter32, apsStatusChannelMismatches Counter32, apsStatusPSBFs Counter32, apsStatusFEPLFs Counter32, apsStatusSwitchedChannel Integer32, apsStatusDiscontinuityTime TimeStamp } apsStatusK1K2Rcv OBJECT-TYPE SYNTAX ApsK1K2 MAX-ACCESS read-only STATUS current DESCRIPTION "The current value of the K1 and K2 bytes received on the protection channel." ::= { apsStatusEntry 1 } apsStatusK1K2Trans OBJECT-TYPE SYNTAX ApsK1K2 MAX-ACCESS read-only STATUS current DESCRIPTION "The current value of the K1 and K2 bytes transmitted on the protection channel." ::= { apsStatusEntry 2 } apsStatusCurrent OBJECT-TYPE SYNTAX BITS { modeMismatch(0), channelMismatch(1), psbf(2), feplf(3), extraTraffic(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of the APS group. modeMismatch Modes other than 1+1 unidirectional monitor protection line K2 bit 5, which indicates the architecture and K2 bits 6-8, which indicate if the mode is unidirectional or bidirectional. A conflict between the current local mode and the received K2 mode information constitutes a mode mismatch. Kuhfeld, et al. Standards Track [Page 16] RFC 3498 SONET LINEAR APS MIB March 2003 channelMismatch This bit indicates a mismatch between the transmitted K1 channel and the received K2 channel has been detected. psbf This bit indicates a Protection Switch Byte Failure (PSBF) is in effect. This condition occurs when either an inconsistent APS byte or an invalid code is detected. An inconsistent APS byte occurs when no three consecutive K1 bytes of the last 12 successive frames are identical, starting with the last frame containing a previously consistent byte. An invalid code occurs when the incoming K1 byte contains an unused code or a code irrelevant for the specific switching operation (e.g., Reverse Request while no switching request is outstanding) in three consecutive frames. An invalid code also occurs when the incoming K1 byte contains an invalid channel number in three consecutive frames. feplf Modes other than 1+1 unidirectional monitor the K1 byte for Far-End Protection-Line failures. A Far-End Protection-Line defect is declared based on receiving SF on the protection line. extraTraffic This bit indicates whether extra traffic is currently being accepted on the protection line. " ::= { apsStatusEntry 3 } apsStatusModeMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of Mode Mismatch conditions. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsStatusDiscontinuityTime." ::= { apsStatusEntry 4 } Kuhfeld, et al. Standards Track [Page 17] RFC 3498 SONET LINEAR APS MIB March 2003 apsStatusChannelMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of Channel Mismatch conditions. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsStatusDiscontinuityTime." ::= { apsStatusEntry 5 } apsStatusPSBFs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of Protection Switch Byte Failure conditions. This condition occurs when either an inconsistent APS byte or an invalid code is detected. An inconsistent APS byte occurs when no three consecutive K1 bytes of the last 12 successive frames are identical, starting with the last frame containing a previously consistent byte. An invalid code occurs when the incoming K1 byte contains an unused code or a code irrelevant for the specific switching operation (e.g., Reverse Request while no switching request is outstanding) in three consecutive frames. An invalid code also occurs when the incoming K1 byte contains an invalid channel number in three consecutive frames. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsStatusDiscontinuityTime." ::= { apsStatusEntry 6 } apsStatusFEPLFs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of Far-End Protection-Line Failure conditions. This condition is declared based on receiving SF on the protection line in the K1 byte. Kuhfeld, et al. Standards Track [Page 18] RFC 3498 SONET LINEAR APS MIB March 2003 Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsStatusDiscontinuityTime." ::= { apsStatusEntry 7 } apsStatusSwitchedChannel OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is set to the number of the channel that is currently switched to protection. The value 0 indicates no channel is switched to protection. The values 1-14 indicate that working channel is switched to protection." ::= { apsStatusEntry 8 } apsStatusDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this APS group's counters suffered a discontinuity. The relevant counters are the specific instances associated with this APS group of any Counter32 object contained in apsStatusTable. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { apsStatusEntry 9 } -- -- APS Map Group -- -- Lists the SONET LTE interfaces that may be used to create APS groups. -- apsMap OBJECT IDENTIFIER ::= { apsMIBObjects 3 } apsChanLTEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of SONET LTE interfaces on the system. Each interface that is included has an ifType value of sonet(39)." Kuhfeld, et al. Standards Track [Page 19] RFC 3498 SONET LINEAR APS MIB March 2003 ::= { apsMap 1 } apsMapTable OBJECT-TYPE SYNTAX SEQUENCE OF ApsMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the SONET LTE interfaces on the system. Each interface that is listed has an ifType value of sonet(39)." ::= { apsMap 2 } apsMapEntry OBJECT-TYPE SYNTAX ApsMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apsMapTable." INDEX { ifIndex } ::= { apsMapTable 1 } ApsMapEntry ::= SEQUENCE { apsMapGroupName SnmpAdminString, apsMapChanNumber Integer32 } apsMapGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual name for the APS group which this channel is included in. If the channel is not part of an APS group this value is set to a string of size 0. When an instance of apsChanConfigIfIndex is set equal to an instance of ifIndex that has an ifType value of sonet(39), apsMapGroupName is set equal to the corresponding value of apsChanConfigGroupName. If an instance of ifIndex that has an ifType value of sonet(39) ceases to be equal to an instance of apsChanConfigIfIndex, either because of a change in the value of apsChanConfigIfIndex, or because of row deletion in the ApsChanConfigTable, apsMapGroupName is set to a string of size 0." ::= { apsMapEntry 2 } Kuhfeld, et al. Standards Track [Page 20] RFC 3498 SONET LINEAR APS MIB March 2003 apsMapChanNumber OBJECT-TYPE SYNTAX Integer32 (-1..14) MAX-ACCESS read-only STATUS current DESCRIPTION "This field is set to a unique channel number within an APS group. The value 0 indicates the null channel. The values 1-14 define a working channel. If the SONET LTE is not part of an APS group this value is set to -1. When an instance of apsChanConfigIfIndex is set equal to an instance of ifIndex that has an ifType value of sonet(39), apsMapChanNumber is set equal to the corresponding value of apsChanConfigNumber. If an instance of ifIndex that has an ifType value of sonet(39) ceases to be equal to an instance of apsChanConfigIfIndex, either because of a change in the value of apsChanConfigIfIndex, or because of row deletion in the ApsChanConfigTable, apsMapChanNumber is set to -1." ::= { apsMapEntry 3 } -- -- APS Channel Configuration Table -- -- This table supports the addition, configuration and deletion of -- channels in APS groups. -- apsChanConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF ApsChanConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the APS channels that have been configured in APS groups." ::= { apsMIBObjects 4 } apsChanConfigEntry OBJECT-TYPE SYNTAX ApsChanConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apsChanConfigTable." INDEX {apsChanConfigGroupName, apsChanConfigNumber} ::= { apsChanConfigTable 1 } Kuhfeld, et al. Standards Track [Page 21] RFC 3498 SONET LINEAR APS MIB March 2003 ApsChanConfigEntry ::= SEQUENCE { apsChanConfigGroupName SnmpAdminString, apsChanConfigNumber Integer32, apsChanConfigRowStatus RowStatus, apsChanConfigIfIndex InterfaceIndex, apsChanConfigPriority INTEGER, apsChanConfigStorageType StorageType } apsChanConfigGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A textual name for the APS group which this channel is included in." ::= { apsChanConfigEntry 1 } apsChanConfigNumber OBJECT-TYPE SYNTAX Integer32 (0..14) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This field is set to a unique channel number within an APS group. The value 0 indicates the null channel. The values 1-14 define a working channel. This field must be assigned a unique number within the group." ::= { apsChanConfigEntry 2 } apsChanConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this APS channel entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. A row in the apsChanConfigTable may not be created, deleted, set to notInService or otherwise modified if the apsChanConfigGroupName value is equal to an apsConfigName value and the associated apsConfigRowStatus object is equal to active. However, if the apsConfigRowStatus object is equal to notInService, a row may be created, deleted or modified. In other words, a channel may not be added, deleted or modified if the group is active. Kuhfeld, et al. Standards Track [Page 22] RFC 3498 SONET LINEAR APS MIB March 2003 A row may be created with an apsChanConfigGroupName value that is not equal to any existing instance of apsConfigName. This action is the initial step in adding a SONET LTE to a new APS group. If this object is set to destroy, the associated instance of apsMapGroupName will be set to a string of size 0 and the apsMapChanNumber will be set to -1. The channel status entry will also be deleted by this action. apsChanConfigNumber must be set to a unique channel number within the APS group. The value 0 indicates the null channel. The values 1-14 define a working channel. When an attempt is made to set the corresponding apsConfigRowStatus field to active the apsChanConfigNumber values of all entries with equal apsChanConfigGroupName fields must represent a set of consecutive integer values beginning with 0 or 1, depending on the architecture of the group, and ending with n, where n is greater than or equal to 1 and less than or equal to 14. Otherwise, the error inconsistentValue is returned to the apsConfigRowStatus set attempt." ::= { apsChanConfigEntry 3 } apsChanConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The Interface Index assigned to a SONET LTE. This is an interface with ifType sonet(39). The value of this object must be unique among all instances of apsChanConfigIfIndex. In other words, a particular SONET LTE can only be configured in one APS group. This object cannot be set if the apsChanConfigGroupName instance associated with this row is equal to an instance of apsConfigName and the corresponding apsConfigRowStatus object is set to active. In other words this value cannot be changed if the APS group is active. However, this value may be changed if the apsConfigRowStatus value is equal to notInService." ::= { apsChanConfigEntry 4 } apsChanConfigPriority OBJECT-TYPE SYNTAX INTEGER {low(1), high(2)} MAX-ACCESS read-create STATUS current DESCRIPTION "The priority of the channel. Kuhfeld, et al. Standards Track [Page 23] RFC 3498 SONET LINEAR APS MIB March 2003 This field determines whether high or low priority SD and SF codes are used in K1 requests. This field is only applicable if the channel is to be included in a group using the 1:n architecture. It is not applicable if the channel is to be included in a group using the 1+1 architecture, and is ignored in that case. This object cannot be set if the apsChanConfigGroupName instance associated with this row is equal to an instance of apsConfigName and the corresponding apsConfigRowStatus object is set to active. In other words this value cannot be changed if the APS group is active. However, this value may be changed if the apsConfigRowStatus value is equal to notInService." DEFVAL { low } ::= { apsChanConfigEntry 5 } apsChanConfigStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { apsChanConfigEntry 6 } -- -- APS Command Table -- -- This table provides the ability to initiate APS commands. -- apsCommandTable OBJECT-TYPE SYNTAX SEQUENCE OF ApsCommandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table allows commands to be sent to configured APS groups." ::= { apsMIBObjects 5 } apsCommandEntry OBJECT-TYPE SYNTAX ApsCommandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Kuhfeld, et al. Standards Track [Page 24] RFC 3498 SONET LINEAR APS MIB March 2003 "A conceptual row in the apsCommandTable. This row exists only if the associated apsConfigEntry is active." INDEX {apsChanConfigGroupName, apsChanConfigNumber} ::= { apsCommandTable 1 } ApsCommandEntry ::= SEQUENCE { apsCommandSwitch ApsSwitchCommand, apsCommandControl ApsControlCommand } apsCommandSwitch OBJECT-TYPE SYNTAX ApsSwitchCommand MAX-ACCESS read-write STATUS current DESCRIPTION "Allows the initiation of an APS switch command on the APS group and channel specified by the index values. When read this object returns the last command written or noCmd if no command has been written to this channel since initialization. The return of the last command written does not imply that this command is currently in effect. This request may have been preempted by a higher priority local or remote request. In order to determine the current state of the APS group it is necessary to read the objects apsStatusK1K2Rcv and apsStatusK1K2Trans. The value lockoutOfProtection should only be applied to the protection line channel since that switch command prevents any of the working channels from switching to the protection line. Following the same logic, forcedSwitchProtectToWork and manualSwitchProtectToWork should only be applied to the protection line channel. forcedSwitchWorkToProtect and manualSwitchWorkToProtect should only be applied to a working channel." ::= { apsCommandEntry 1 } apsCommandControl OBJECT-TYPE SYNTAX ApsControlCommand MAX-ACCESS read-write STATUS current DESCRIPTION "Allows the initiation of an APS control command on the APS group and channel specified by the index values. Kuhfeld, et al. Standards Track [Page 25] RFC 3498 SONET LINEAR APS MIB March 2003 When read this object returns the last command written or noCmd if no command has been written to this channel since initialization. This object does not apply to the protection line." ::= { apsCommandEntry 2 } -- -- APS Channel Status Table -- -- This table provides APS channel statistics. -- apsChanStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF ApsChanStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains status information for all SONET LTE interfaces that are included in APS groups." ::= { apsMIBObjects 6 } apsChanStatusEntry OBJECT-TYPE SYNTAX ApsChanStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apsChanStatusTable." AUGMENTS { apsChanConfigEntry } ::= { apsChanStatusTable 1 } ApsChanStatusEntry ::= SEQUENCE { apsChanStatusCurrent BITS, apsChanStatusSignalDegrades Counter32, apsChanStatusSignalFailures Counter32, apsChanStatusSwitchovers Counter32, apsChanStatusLastSwitchover TimeStamp, apsChanStatusSwitchoverSeconds Counter32, apsChanStatusDiscontinuityTime TimeStamp } apsChanStatusCurrent OBJECT-TYPE SYNTAX BITS { lockedOut(0), sd(1), sf(2), switched(3), wtr(4) Kuhfeld, et al. Standards Track [Page 26] RFC 3498 SONET LINEAR APS MIB March 2003 } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state of the port. lockedOut This bit, when applied to a working channel, indicates that the channel is prevented from switching to the protection line. When applied to the null channel, this bit indicates that no working channel may switch to the protection line. sd A signal degrade condition is in effect. sf A signal failure condition is in effect. switched The switched bit is applied to a working channel if that channel is currently switched to the protection line. wtr A Wait-to-Restore state is in effect." ::= { apsChanStatusEntry 1 } apsChanStatusSignalDegrades OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of Signal Degrade conditions. This condition occurs when the line Bit Error Rate exceeds the currently configured value of the relevant instance of apsConfigSdBerThreshold. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsChanStatusDiscontinuityTime." ::= { apsChanStatusEntry 2 } Kuhfeld, et al. Standards Track [Page 27] RFC 3498 SONET LINEAR APS MIB March 2003 apsChanStatusSignalFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of Signal Failure conditions that have been detected on the incoming signal. This condition occurs when a loss of signal, loss of frame, AIS-L or a Line bit error rate exceeding the currently configured value of the relevant instance of apsConfigSfBerThreshold. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsChanStatusDiscontinuityTime." ::= { apsChanStatusEntry 3 } apsChanStatusSwitchovers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "When queried with index value apsChanConfigNumber other than 0, this object will return the number of times this channel has switched to the protection line. When queried with index value apsChanConfigNumber set to 0, which is the protection line, this object will return the number of times that any working channel has been switched back to the working line from this protection line. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsChanStatusDiscontinuityTime." ::= { apsChanStatusEntry 4 } apsChanStatusLastSwitchover OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "When queried with index value apsChanConfigNumber other than 0, this object will return the value of sysUpTime when this channel last completed a switch to the protection line. If Kuhfeld, et al. Standards Track [Page 28] RFC 3498 SONET LINEAR APS MIB March 2003 this channel has never switched to the protection line, the value 0 will be returned. When queried with index value apsChanConfigNumber set to 0, which is the protection line, this object will return the value of sysUpTime the last time that a working channel was switched back to the working line from this protection line. If no working channel has ever switched back to the working line from this protection line, the value 0 will be returned." ::= { apsChanStatusEntry 5 } apsChanStatusSwitchoverSeconds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The cumulative Protection Switching Duration (PSD) time in seconds. For a working channel, this is the cumulative number of seconds that service was carried on the protection line. For the protection line, this is the cumulative number of seconds that the protection line has been used to carry any working channel traffic. This information is only valid if revertive switching is enabled. The value 0 will be returned otherwise. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of apsChanStatusDiscontinuityTime. For example, if the value of an instance of apsChanStatusSwitchoverSeconds changes from a non-zero value to zero due to revertive switching being disabled, it is expected that the corresponding value of apsChanStatusDiscontinuityTime will be updated to reflect the time of the configuration change. " ::= { apsChanStatusEntry 6 } apsChanStatusDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this channel's counters suffered a discontinuity. The relevant counters are the specific instances associated with this channel of any Counter32 object contained in apsChanStatusTable. If no such Kuhfeld, et al. Standards Track [Page 29] RFC 3498 SONET LINEAR APS MIB March 2003 discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { apsChanStatusEntry 7 } apsNotificationEnable OBJECT-TYPE SYNTAX BITS { switchover(0), modeMismatch(1), channelMismatch(2), psbf(3), feplf(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Provides the ability to enable and disable notifications defined in this MIB. switchover Indicates apsEventSwitchover notifications should be generated. modeMismatch Indicates apsEventModeMismatch notifications should be generated. channelMismatch Indicates apsEventChannelMismatch notifications should be generated. psbf Indicates apsEventPSBF notifications should be generated. feplf Indicates apsEventFEPLF notifications should be generated. " DEFVAL { { } } ::= { apsMIBObjects 7 } -- -- APS EVENTS Kuhfeld, et al. Standards Track [Page 30] RFC 3498 SONET LINEAR APS MIB March 2003 -- apsNotificationsPrefix OBJECT IDENTIFIER ::= { apsMIBNotifications 0 } apsEventSwitchover NOTIFICATION-TYPE OBJECTS { apsChanStatusSwitchovers, apsChanStatusCurrent } STATUS current DESCRIPTION "An apsEventSwitchover notification is sent when the value of an instance of apsChanStatusSwitchovers increments." ::= { apsNotificationsPrefix 1 } apsEventModeMismatch NOTIFICATION-TYPE OBJECTS { apsStatusModeMismatches, apsStatusCurrent } STATUS current DESCRIPTION "An apsEventModeMismatch notification is sent when the value of an instance of apsStatusModeMismatches increments." ::= { apsNotificationsPrefix 2 } apsEventChannelMismatch NOTIFICATION-TYPE OBJECTS { apsStatusChannelMismatches, apsStatusCurrent } STATUS current DESCRIPTION "An apsEventChannelMismatch notification is sent when the value of an instance of apsStatusChannelMismatches increments." ::= { apsNotificationsPrefix 3 } apsEventPSBF NOTIFICATION-TYPE OBJECTS { apsStatusPSBFs, apsStatusCurrent } STATUS current DESCRIPTION "An apsEventPSBF notification is sent when the value of an instance of apsStatusPSBFs increments." ::= { apsNotificationsPrefix 4 } apsEventFEPLF NOTIFICATION-TYPE OBJECTS { apsStatusFEPLFs, apsStatusCurrent } STATUS current DESCRIPTION "An apsEventFEPLFs notification is sent when the value of an instance of apsStatusFEPLFs increments." ::= { apsNotificationsPrefix 5 } -- conformance information Kuhfeld, et al. Standards Track [Page 31] RFC 3498 SONET LINEAR APS MIB March 2003 apsGroups OBJECT IDENTIFIER ::= { apsMIBConformance 1 } apsCompliances OBJECT IDENTIFIER ::= { apsMIBConformance 2 } apsFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read-create, then such an implementation can claim read/write compliance. Linear APS groups can then be both monitored and configured with this MIB. Note that An agent is not required to process SNMP Set Requests that affect multiple control objects within this MIB. This is intended to simplify the processing of Set Requests for the various control tables by eliminating the possibility that a single Set PDU will contain multiple varbinds which are in conflict. " MODULE MANDATORY-GROUPS { apsConfigGeneral, apsStatusGeneral, apsChanGeneral } OBJECT apsConfigRowStatus SYNTAX INTEGER { active(1) } WRITE-SYNTAX INTEGER { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT apsChanConfigRowStatus SYNTAX INTEGER { active(1) } WRITE-SYNTAX INTEGER { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." GROUP apsConfigWtr DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups supporting a configurable WTR period." GROUP apsCommandOnePlusOne DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups implementing the linear Kuhfeld, et al. Standards Track [Page 32] RFC 3498 SONET LINEAR APS MIB March 2003 APS 1+1 architecture and supporting set operations." GROUP apsCommandOneToN DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups implementing the linear APS 1:n architecture and supporting set operations." GROUP apsChanOneToN DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups implementing the linear APS 1:n architecture." GROUP apsTotalsGroup DESCRIPTION "Implementation of this group is optional for all linear APS implementations." GROUP apsMapGroup DESCRIPTION "Implementation of this group is optional for all linear APS implementations." GROUP apsEventGroup DESCRIPTION "Implementation of this group is optional for all linear APS implementations." ::= { apsCompliances 1 } -- -- Read-Only Compliance -- apsReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read-create (i.e. in read-only mode), then that implementation can claim read-only compliance. In that case, linear APS groups can be monitored but cannot be configured with this MIB." MODULE MANDATORY-GROUPS { apsConfigGeneral, apsStatusGeneral, apsChanGeneral } Kuhfeld, et al. Standards Track [Page 33] RFC 3498 SONET LINEAR APS MIB March 2003 OBJECT apsConfigMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsConfigRevert MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsConfigDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsConfigExtraTraffic MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsConfigSdBerThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsConfigSfBerThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsConfigWaitToRestore MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsConfigRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT apsConfigStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsChanConfigIfIndex Kuhfeld, et al. Standards Track [Page 34] RFC 3498 SONET LINEAR APS MIB March 2003 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsChanConfigPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsChanConfigRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT apsChanConfigStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT apsNotificationEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP apsConfigWtr DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups supporting a configurable WTR period." GROUP apsCommandOnePlusOne DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups implementing the linear APS 1+1 architecture and supporting set operations." GROUP apsCommandOneToN DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups implementing the linear APS 1:n architecture and supporting set operations." GROUP apsChanOneToN Kuhfeld, et al. Standards Track [Page 35] RFC 3498 SONET LINEAR APS MIB March 2003 DESCRIPTION "Implementation of this group is optional for all linear APS implementations. The information is applicable to groups implementing the linear APS 1:n architecture." GROUP apsTotalsGroup DESCRIPTION "Implementation of this group is optional for all linear APS implementations." GROUP apsMapGroup DESCRIPTION "Implementation of this group is optional for all linear APS implementations." GROUP apsEventGroup DESCRIPTION "Implementation of this group is optional for all linear APS implementations." ::= { apsCompliances 2 } -- units of conformance apsConfigGeneral OBJECT-GROUP OBJECTS { apsConfigMode, apsConfigRevert, apsConfigDirection, apsConfigExtraTraffic, apsConfigSdBerThreshold, apsConfigSfBerThreshold, apsConfigCreationTime, apsConfigRowStatus, apsConfigStorageType, apsNotificationEnable } STATUS current DESCRIPTION "A collection of apsConfigTable objects providing configuration information applicable to all linear APS groups." ::= { apsGroups 1 } apsConfigWtr OBJECT-GROUP OBJECTS { Kuhfeld, et al. Standards Track [Page 36] RFC 3498 SONET LINEAR APS MIB March 2003 apsConfigWaitToRestore } STATUS current DESCRIPTION "The apsConfigTable object that provides information which is applicable to groups supporting a configurable WTR period." ::= { apsGroups 2 } -- If set operations are not supported neither of the following two -- groups are implemented. If sets are supported only one of these -- groups is implemented for a linear APS group instance. apsCommandOnePlusOne OBJECT-GROUP OBJECTS { apsCommandSwitch } STATUS current DESCRIPTION "The apsCommandTable object which is applicable to groups implementing the linear APS 1+1 architecture. Also, set operations must be supported." ::= { apsGroups 3 } apsCommandOneToN OBJECT-GROUP OBJECTS { apsCommandSwitch, apsCommandControl } STATUS current DESCRIPTION "A collection of apsCommandTable objects which are applicable to groups implementing the linear APS 1:n architecture. Also, set operations must be supported." ::= { apsGroups 4 } apsStatusGeneral OBJECT-GROUP OBJECTS { apsStatusK1K2Rcv, apsStatusK1K2Trans, apsStatusCurrent, apsStatusModeMismatches, apsStatusChannelMismatches, apsStatusPSBFs, apsStatusFEPLFs, apsStatusSwitchedChannel, Kuhfeld, et al. Standards Track [Page 37] RFC 3498 SONET LINEAR APS MIB March 2003 apsStatusDiscontinuityTime } STATUS current DESCRIPTION "A collection of apsStatusTable objects providing status information applicable to all linear APS groups." ::= { apsGroups 5 } apsChanGeneral OBJECT-GROUP OBJECTS { apsChanConfigIfIndex, apsChanConfigRowStatus, apsChanConfigStorageType, apsChanStatusCurrent, apsChanStatusSignalDegrades, apsChanStatusSignalFailures, apsChanStatusSwitchovers, apsChanStatusLastSwitchover, apsChanStatusSwitchoverSeconds, apsChanStatusDiscontinuityTime } STATUS current DESCRIPTION "A collection of channel objects providing information applicable to all linear APS channels." ::= { apsGroups 6 } apsChanOneToN OBJECT-GROUP OBJECTS { apsChanConfigPriority } STATUS current DESCRIPTION "The apsChanConfigTable object that provides information which is only applicable to groups implementing the linear APS 1:n architecture." ::= { apsGroups 7 } apsTotalsGroup OBJECT-GROUP OBJECTS { apsConfigGroups, apsChanLTEs } STATUS current DESCRIPTION Kuhfeld, et al. Standards Track [Page 38] RFC 3498 SONET LINEAR APS MIB March 2003 "A collection of objects providing optional counts of configured APS groups and SONET LTE interfaces." ::= { apsGroups 8 } apsMapGroup OBJECT-GROUP OBJECTS { apsMapGroupName, apsMapChanNumber } STATUS current DESCRIPTION "A collection of apsMapTable objects providing a mapping from sonet(39) InterfaceIndex to group name and channel number for assigned APS channels and a list of unassigned sonet(39) interfaces." ::= { apsGroups 9 } apsEventGroup NOTIFICATION-GROUP NOTIFICATIONS {apsEventSwitchover, apsEventModeMismatch, apsEventChannelMismatch, apsEventPSBF, apsEventFEPLF } STATUS current DESCRIPTION "A collection of SONET linear APS notifications." ::= { apsGroups 10 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in [BCP11]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Kuhfeld, et al. Standards Track [Page 39] RFC 3498 SONET LINEAR APS MIB March 2003 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgments This document is a product of the AToMMIB Working Group. A number of constructs from a separate draft submission by Ken Chapman have been included here. Suggestions by Orly Nicklass, Faye Ly, Ron Carmona, Kaj Tesink, C. M. Heard, Muly Ilan, and Mickey Spiegel have been incorporated. A quality review was provided by Lauren Heintz and an IESG review by John Flick and Bert Wijnen. 7. Normative References [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [GR253CO] GR-253-CORE Issue 3, September 2000 [G.783] ITU-T Recommendation G.783 (04/97) 8. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [BCP11] Hovey, R, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. Kuhfeld, et al. Standards Track [Page 40] RFC 3498 SONET LINEAR APS MIB March 2003 9. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. In particular, the APS command objects apsCommandSwitch and apsCommandControl and the APS configuration objects apsConfigRowStatus, apsConfigMode, apsConfigRevert, apsConfigDirection, apsConfigExtraTraffic, apsConfigSdBerThreshold, apsConfigSfBerThreshold, apsConfigWaitToRestore, apsConfigStorageType, apsChanConfigRowStatus, apsChanConfigIfIndex, apsChanConfigPriority, apsChanConfigStorageType and apsNotificationEnable have the potential of disrupting APS operations if set operations are performed with malicious intent. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is recommended that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is not recommended. Instead, it is recommended to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that access to an instance of this MIB module is properly configured for only those principals (users) that have legitimate rights to GET or SET object instances. Kuhfeld, et al. Standards Track [Page 41] RFC 3498 SONET LINEAR APS MIB March 2003 10. Editors' Addresses Jim Kuhfeld RedBack Networks. Inc. 300 Holger Way San Jose, CA 95134-1362 Phone: +1 408 750 5465 EMail: jkuhfeld@redback.com Jeff Johnson RedBack Networks. Inc. 300 Holger Way San Jose, CA 95134-1362 Phone: +1 408 750 5460 EMail: jeff@redback.com Michael Thatcher RedBack Networks. Inc. 300 Holger Way San Jose, CA 95134-1362 Phone: +1 408 750 5449 EMail: thatcher@redback.com Kuhfeld, et al. Standards Track [Page 42] RFC 3498 SONET LINEAR APS MIB March 2003 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kuhfeld, et al. Standards Track [Page 43] snmp-mibs-downloader-1.1/mibrfcs/rfc3559.txt0000644000000000000000000020521711402176071015576 0ustar Network Working Group D. Thaler Request for Comments: 3559 Microsoft Category: Standards Track June 2003 Multicast Address Allocation MIB 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. Protocol-independent objects . . . . . . . . . . . . . . 3 3.2. Protocol-specific objects. . . . . . . . . . . . . . . . 3 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 33 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 8. Intellectual Property Statement. . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . 35 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 36 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 37 Thaler Standards Track [Page 1] RFC 3559 Multicast Address Allocation MIB June 2003 1. Introduction This document defines a Management Information Base (MIB) module for managing multicast address allocation in a protocol-independent manner, as well as for managing specific protocols used in allocating multicast addresses. The protocol-independent objects in this MIB apply to all multicast address allocation servers (MAASs) and clients, as described in [ARCH], including those that allocate source-specific multicast addresses for the local machine. The protocol-specific objects in this MIB include objects related to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) [MADCAP]. Interactions with the Multicast-scope Zone Announcement Protocol (MZAP) [MZAP] are also noted where appropriate. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The purpose of this MIB module is to provide the ability to configure and monitor the status of multicast address allocation within the local domain. Some important monitoring questions which can be answered by this MIB module include: o How full is scope X? o Who's using up the space? o Who allocated a given address A? o Are requests being met? Thaler Standards Track [Page 2] RFC 3559 Multicast Address Allocation MIB June 2003 This MIB module is divided into two primary sections: o Protocol-independent objects relevant to all multicast address allocation servers and clients. o Protocol-specific objects related to the MADCAP client-server protocol. 3.1. Protocol-independent objects The protocol-independent objects consist of one "capabilities" scalar and five tables. The tables are: o The Scope Table contains information on the multicast scopes known to a multicast address allocation server. This table allows configuring scopes, and viewing what scopes are known to the local system after being configured elsewhere. o The Scope Name Table contains the names of the multicast scopes. This table logically extends the Scope Table with the list of scope names in various languages for each scope. o The Allocation Range Table contains the address ranges out of which the device may allocate addresses. It also allows answering the questions "How full is scope X?" and "Are requests being met?" o The Request Table contains the requests for address allocations, and allows answering the question "Who's using up the space?" o The Address Table contains the blocks of addresses which have been allocated, and together with the Request Table, allows answering the question "Who allocated a given address A?" 3.2. Protocol-specific objects The MADCAP objects consist of a group of (scalar) configuration parameters, and a group of (scalar) statistics. Thaler Standards Track [Page 3] RFC 3559 Multicast Address Allocation MIB June 2003 4. Definitions MALLOC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, Unsigned32, Gauge32, Counter32 FROM SNMPv2-SMI RowStatus, TruthValue, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddress, InetAddressType FROM INET-ADDRESS-MIB LanguageTag FROM IPMROUTE-STD-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB IANAscopeSource, IANAmallocRangeSource FROM IANA-MALLOC-MIB; mallocMIB MODULE-IDENTITY LAST-UPDATED "200306090000Z" -- June 9, 2003 ORGANIZATION "IETF MALLOC Working Group" CONTACT-INFO " WG-EMail: malloc@catarina.usc.edu Subscribe: malloc-request@catarina.usc.edu Archive: catarina.usc.edu/pub/multicast/malloc/ Co-chair/editor: Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: dthaler@microsoft.com Co-chair: Steve Hanna Sun Microsystems, Inc. One Network Drive Burlington, MA 01803 EMail: steve.hanna@sun.com" DESCRIPTION "The MIB module for management of multicast address allocation. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3559; see the RFC itself for full legal notices." Thaler Standards Track [Page 4] RFC 3559 Multicast Address Allocation MIB June 2003 -- revision log REVISION "200306090000Z" -- June 9, 2003 DESCRIPTION "Initial version, published as RFC 3559." ::= { mib-2 101 } mallocMIBObjects OBJECT IDENTIFIER ::= { mallocMIB 1 } malloc OBJECT IDENTIFIER ::= { mallocMIBObjects 1 } madcap OBJECT IDENTIFIER ::= { mallocMIBObjects 2 } -- -- scalars -- mallocCapabilities OBJECT-TYPE SYNTAX BITS { startTime(0), serverMobility(1), retryAfter(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the capabilities which a client or server supports. The startTime bit indicates that allocations with a future start time are supported. The serverMobility bit indicates that allocations can be renewed or released from a server other than the one granting the original allocation. The retryAfter bit indicates support for a waiting state where the client may check back at a later time to get the status of its request." ::= { malloc 1 } -- -- the Scope Table -- mallocScopeTable OBJECT-TYPE SYNTAX SEQUENCE OF MallocScopeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on multicast scopes from which addresses may be allocated. Entries in this table may be dynamically discovered via some other Thaler Standards Track [Page 5] RFC 3559 Multicast Address Allocation MIB June 2003 protocol, such as MZAP, or may be statically configured, such as in an isolated network environment. Each scope is associated with a range of multicast addresses, and ranges for different rows must be disjoint." ::= { malloc 2 } mallocScopeEntry OBJECT-TYPE SYNTAX MallocScopeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular multicast scope." INDEX { mallocScopeAddressType, mallocScopeFirstAddress } ::= { mallocScopeTable 1 } MallocScopeEntry ::= SEQUENCE { mallocScopeAddressType InetAddressType, mallocScopeFirstAddress InetAddress, mallocScopeLastAddress InetAddress, mallocScopeHopLimit Unsigned32, mallocScopeStatus RowStatus, mallocScopeSource IANAscopeSource, mallocScopeDivisible TruthValue, mallocScopeServerAddressType InetAddressType, mallocScopeServerAddress InetAddress, mallocScopeSSM TruthValue, mallocScopeStorage StorageType } mallocScopeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the addresses in the multicast scope range. Legal values correspond to the subset of address families for which multicast address allocation is supported." ::= { mallocScopeEntry 1 } mallocScopeFirstAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(0..20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first address in the multicast scope range. The type of this address is determined by the value of the mallocScopeAddressType object." Thaler Standards Track [Page 6] RFC 3559 Multicast Address Allocation MIB June 2003 ::= { mallocScopeEntry 2 } mallocScopeLastAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(0..20)) MAX-ACCESS read-create STATUS current DESCRIPTION "The last address in the multicast scope range. The type of this address is determined by the value of the mallocScopeAddressType object." ::= { mallocScopeEntry 3 } mallocScopeHopLimit OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The default IPv4 TTL or IPv6 hop limit which applications should use for groups within the scope." DEFVAL { 255 } ::= { mallocScopeEntry 4 } mallocScopeStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. If write access is supported, the other writable objects in this table may be modified even while the status is `active'." ::= { mallocScopeEntry 5 } mallocScopeSource OBJECT-TYPE SYNTAX IANAscopeSource MAX-ACCESS read-only STATUS current DESCRIPTION "The method by which this entry was learned." ::= { mallocScopeEntry 6 } mallocScopeDivisible OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If false, the server may allocate addresses out of the entire range. If true, the server must not allocate Thaler Standards Track [Page 7] RFC 3559 Multicast Address Allocation MIB June 2003 addresses out of the entire range, but may only allocate addresses out of a subrange learned via another method. Creating or deleting a scope which is not divisible has the side effect of creating or deleting the corresponding entry in the mallocAllocRangeTable. Deleting a scope which is divisible has the side effect of deleting any corresponding entries in the mallocAllocRangeTable, and the mallocRequestTable." DEFVAL { false } ::= { mallocScopeEntry 7 } mallocScopeServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the address of a multicast address allocation server to which a request may be sent." DEFVAL { unknown } ::= { mallocScopeEntry 8 } mallocScopeServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The address of a multicast address allocation server to which a request may be sent. The default value is an zero- length address, indicating that no server is known. The type of this address is determined by the value of the mallocScopeServerAddressType object." DEFVAL { ''h } -- the empty string ::= { mallocScopeEntry 9 } mallocScopeSSM OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the scope is a Source-Specific Multicast (SSM) range." DEFVAL { false } ::= { mallocScopeEntry 10 } mallocScopeStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current Thaler Standards Track [Page 8] RFC 3559 Multicast Address Allocation MIB June 2003 DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mallocScopeEntry 11 } -- -- the Scope Name Table -- mallocScopeNameTable OBJECT-TYPE SYNTAX SEQUENCE OF MallocScopeNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on multicast scope names. Entries in this table may be dynamically discovered via some other protocol, such as MZAP, or may be statically configured, such as in an isolated network environment." ::= { malloc 3 } mallocScopeNameEntry OBJECT-TYPE SYNTAX MallocScopeNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular multicast scope name." INDEX { mallocScopeAddressType, mallocScopeFirstAddress, IMPLIED mallocScopeNameLangName } ::= { mallocScopeNameTable 1 } MallocScopeNameEntry ::= SEQUENCE { mallocScopeNameLangName LanguageTag, mallocScopeNameScopeName SnmpAdminString, mallocScopeNameDefault TruthValue, mallocScopeNameStatus RowStatus, mallocScopeNameStorage StorageType } mallocScopeNameLangName OBJECT-TYPE SYNTAX LanguageTag (SIZE(1..94)) MAX-ACCESS not-accessible STATUS current Thaler Standards Track [Page 9] RFC 3559 Multicast Address Allocation MIB June 2003 DESCRIPTION "The RFC 3066 language tag for the language of the scope name." ::= { mallocScopeNameEntry 1 } mallocScopeNameScopeName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The textual name associated with the multicast scope. The value of this object should be suitable for displaying to end-users, such as when allocating a multicast address in this scope. If the scope is an IPv4 scope, and no name is specified, the default value of this object should be the string 239.x.x.x/y with x and y replaced appropriately to describe the address and mask length associated with the scope. If the scope is an IPv6 scope, and no name is specified, the default value of this object should generically describe the scope level (e.g., site)." ::= { mallocScopeNameEntry 2 } mallocScopeNameDefault OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, indicates a preference that the name in the associated language should be used by applications if no name is available in a desired language." DEFVAL { false } ::= { mallocScopeNameEntry 3 } mallocScopeNameStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. If write access is supported, the other writable objects in this table may be modified even while the status is `active'." ::= { mallocScopeNameEntry 4 } mallocScopeNameStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current Thaler Standards Track [Page 10] RFC 3559 Multicast Address Allocation MIB June 2003 DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mallocScopeNameEntry 5 } -- -- the Allocation Range Table -- mallocAllocRangeTable OBJECT-TYPE SYNTAX SEQUENCE OF MallocAllocRangeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on subranges of addresses from which the device may allocate addresses, if it is a MAAS. If the device is a Prefix Coordinator, any ranges which the device is advertising to MAAS's will be in this table. Note that the device may be both a MAAS and a Prefix Coordinator. Address ranges for different rows must be disjoint, and must be contained with the address range of the corresponding row of the mallocScopeTable. Deleting an allocation range has the side effect of deleting any entries within that range from the mallocAddressTable." ::= { malloc 4 } mallocAllocRangeEntry OBJECT-TYPE SYNTAX MallocAllocRangeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular allocation range." INDEX { mallocScopeAddressType, mallocScopeFirstAddress, mallocAllocRangeFirstAddress } ::= { mallocAllocRangeTable 1 } MallocAllocRangeEntry ::= SEQUENCE { mallocAllocRangeFirstAddress InetAddress, mallocAllocRangeLastAddress InetAddress, mallocAllocRangeStatus RowStatus, mallocAllocRangeSource IANAmallocRangeSource, mallocAllocRangeLifetime Unsigned32, mallocAllocRangeMaxLeaseAddrs Unsigned32, Thaler Standards Track [Page 11] RFC 3559 Multicast Address Allocation MIB June 2003 mallocAllocRangeMaxLeaseTime Unsigned32, mallocAllocRangeNumAllocatedAddrs Gauge32, mallocAllocRangeNumOfferedAddrs Gauge32, mallocAllocRangeNumWaitingAddrs Gauge32, mallocAllocRangeNumTryingAddrs Gauge32, mallocAllocRangeAdvertisable TruthValue, mallocAllocRangeTotalAllocatedAddrs Gauge32, mallocAllocRangeTotalRequestedAddrs Gauge32, mallocAllocRangeStorage StorageType } mallocAllocRangeFirstAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(0..20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first address in the allocation range. The type of this address is determined by the value of the mallocScopeAddressType object." ::= { mallocAllocRangeEntry 1 } mallocAllocRangeLastAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(0..20)) MAX-ACCESS read-create STATUS current DESCRIPTION "The last address in the allocation range. The type of this address is determined by the value of the mallocScopeAddressType object." ::= { mallocAllocRangeEntry 2 } mallocAllocRangeStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. If write access is supported, the other writable objects in this table may be modified even while the status is `active'." ::= { mallocAllocRangeEntry 3 } mallocAllocRangeSource OBJECT-TYPE SYNTAX IANAmallocRangeSource MAX-ACCESS read-only STATUS current DESCRIPTION "The means by which this entry was learned." Thaler Standards Track [Page 12] RFC 3559 Multicast Address Allocation MIB June 2003 ::= { mallocAllocRangeEntry 4 } mallocAllocRangeLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds remaining in the lifetime of the (sub)range out of which addresses are being allocated. A value of 0 indicates that the range is not subject to aging." DEFVAL { 0 } ::= { mallocAllocRangeEntry 5 } mallocAllocRangeMaxLeaseAddrs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of addresses which the server is willing to grant for each future request in this range. A value of 0 means that no specific limit is enforced, as long as the server has valid addresses to allocate." DEFVAL { 0 } ::= { mallocAllocRangeEntry 6 } mallocAllocRangeMaxLeaseTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum lifetime which the server will grant for future requests in this range. A value of 0 means that no additional limit is enforced beyond that of mallocAllocRangeLifetime." DEFVAL { 0 } ::= { mallocAllocRangeEntry 7 } mallocAllocRangeNumAllocatedAddrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses in the range which have been allocated. This value can be used to determine the current address space utilization within the scoped range. This Thaler Standards Track [Page 13] RFC 3559 Multicast Address Allocation MIB June 2003 should match the total number of addresses for this scope covered by entries in the mallocAddressTable." ::= { mallocAllocRangeEntry 8 } mallocAllocRangeNumOfferedAddrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses in the range which have been offered. This number should match the sum of mallocRequestNumAddrs for all entries in the mallocRequestTable in the offered state. Together with mallocAllocRangeNumAllocatedAddrs and mallocAllocRangeNumTryingAddrs, this can be used to determine the address space utilization within the scoped range in the immediate future." ::= { mallocAllocRangeEntry 9 } mallocAllocRangeNumWaitingAddrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses in the range which have been requested, but whose state is waiting, while the server attempts to acquire more address space." ::= { mallocAllocRangeEntry 10 } mallocAllocRangeNumTryingAddrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses in the scope covered by entries in the mallocRequestTable in the trying state." ::= { mallocAllocRangeEntry 11 } mallocAllocRangeAdvertisable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is true if the range is eligible to be advertised to other MAASs. When the row is first created, the default value of this object is true if the scope is divisible, and is false otherwise." ::= { mallocAllocRangeEntry 12 } Thaler Standards Track [Page 14] RFC 3559 Multicast Address Allocation MIB June 2003 mallocAllocRangeTotalAllocatedAddrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The approximate number of addresses in the range which have been allocated by any MAAS, as determined by a Prefix Coordinator. This object need only be present if mallocAllocRangeAdvertisable is true. If the number is unknown, a value of 0 may be reported." ::= { mallocAllocRangeEntry 13 } mallocAllocRangeTotalRequestedAddrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The approximate number of addresses in the range for which there is potential demand among MAASs, as determined by a Prefix Coordinator. This object need only be present if mallocAllocRangeAdvertisable is true. If the number is unknown, a value of 0 may be reported." ::= { mallocAllocRangeEntry 14 } mallocAllocRangeStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mallocAllocRangeEntry 15 } -- -- the Request Table -- mallocRequestTable OBJECT-TYPE SYNTAX SEQUENCE OF MallocRequestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on allocation requests, whether allocated or in progress. This table may also be used to determine which clients are responsible for high address space utilization within a given scope. Thaler Standards Track [Page 15] RFC 3559 Multicast Address Allocation MIB June 2003 Entries in this table reflect requests dynamically received by an address allocation protocol." ::= { malloc 5 } mallocRequestEntry OBJECT-TYPE SYNTAX MallocRequestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular allocation request." INDEX { mallocRequestId } ::= { mallocRequestTable 1 } MallocRequestEntry ::= SEQUENCE { mallocRequestId Unsigned32, mallocRequestScopeAddressType InetAddressType, mallocRequestScopeFirstAddress InetAddress, mallocRequestStartTime Unsigned32, mallocRequestEndTime Unsigned32, mallocRequestNumAddrs Unsigned32, mallocRequestState INTEGER, mallocRequestClientAddressType InetAddressType, mallocRequestClientAddress InetAddress, mallocRequestServerAddressType InetAddressType, mallocRequestServerAddress InetAddress, mallocRequestLeaseIdentifier OCTET STRING } mallocRequestId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary value identifying this row." ::= { mallocRequestEntry 1 } mallocRequestScopeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the first address of the scope to which the request applies. Legal values correspond to the subset of address families for which multicast address allocation is supported." ::= { mallocRequestEntry 2 } Thaler Standards Track [Page 16] RFC 3559 Multicast Address Allocation MIB June 2003 mallocRequestScopeFirstAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The first address of the scope to which the request applies. This must match mallocScopeFirstAddress for some row in the mallocScopeTable. The type of this address is determined by the value of the mallocRequestScopeAddressType object." ::= { mallocRequestEntry 3 } mallocRequestStartTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds remaining before the start time of the request. A value of 0 means that the allocation is currently in effect." ::= { mallocRequestEntry 4 } mallocRequestEndTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds remaining before the end time of the request." ::= { mallocRequestEntry 5 } mallocRequestNumAddrs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses requested. If the addresses have been allocated, this number should match the total number of addresses for this request covered by entries in the mallocAddressTable." ::= { mallocRequestEntry 6 } mallocRequestState OBJECT-TYPE SYNTAX INTEGER { allocated(1), offered(2), -- tentatively allocated Thaler Standards Track [Page 17] RFC 3559 Multicast Address Allocation MIB June 2003 waiting(3), -- waiting for more space trying(4) -- working on allocating } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the request. A value of allocated(1) indicates that one or more entries for this request are present in the mallocAddressTable. A value of offered(2) indicates that addresses have been offered to the client (e.g. via a MADCAP OFFER message), but the allocation has not been committed. A value of waiting(3) indicates that the allocation is blocked while the server attempts to acquire more space from which it can allocate addresses. A value of trying(4) means that no addresses have been offered to the client, but that an attempt to allocate is in progress." ::= { mallocRequestEntry 7 } mallocRequestClientAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the address of the client that (last) requested this allocation." ::= { mallocRequestEntry 8 } mallocRequestClientAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the client that (last) requested this allocation. The type of this address is determined by the value of the mallocRequestClientAddressType object." ::= { mallocRequestEntry 9 } mallocRequestServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the address of the server to which the request was (last) sent." ::= { mallocRequestEntry 10 } Thaler Standards Track [Page 18] RFC 3559 Multicast Address Allocation MIB June 2003 mallocRequestServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the server to which the request was (last) sent. The type of this address is determined by the value of the mallocRequestServerAddressType object." ::= { mallocRequestEntry 11 } mallocRequestLeaseIdentifier OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Lease Identifier of this request. If the allocation mechanism in use does not use Lease Identifiers, then the value is a 0-length string." ::= { mallocRequestEntry 12 } -- -- the Address Table -- mallocAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF MallocAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on blocks of allocated addresses. This table may be used to map a given multicast group address to the associated request." ::= { malloc 6 } mallocAddressEntry OBJECT-TYPE SYNTAX MallocAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular block of allocated addresses. The block of addresses covered by each entry in this table must fall within a range corresponding to an entry in the mallocAllocRangeTable." INDEX { mallocAddressAddressType, mallocAddressFirstAddress } ::= { mallocAddressTable 1 } Thaler Standards Track [Page 19] RFC 3559 Multicast Address Allocation MIB June 2003 MallocAddressEntry ::= SEQUENCE { mallocAddressAddressType InetAddressType, mallocAddressFirstAddress InetAddress, mallocAddressNumAddrs Unsigned32, mallocAddressRequestId Unsigned32 } mallocAddressAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the first address in the allocated block. Legal values correspond to the subset of address families for which multicast address allocation is supported." ::= { mallocAddressEntry 1 } mallocAddressFirstAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(0..20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first address in the allocated block. The type of this address is determined by the value of the mallocAddressAddressType object." ::= { mallocAddressEntry 2 } mallocAddressNumAddrs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses in the allocated block." ::= { mallocAddressEntry 3 } mallocAddressRequestId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the request which caused this block of addresses to be allocated. This value must match the value of mallocRequestId for some entry in the mallocRequestTable." ::= { mallocAddressEntry 4 } -- -- MADCAP-specific objects Thaler Standards Track [Page 20] RFC 3559 Multicast Address Allocation MIB June 2003 -- madcapConfig OBJECT-IDENTITY STATUS current DESCRIPTION "Group of objects that count various MADCAP events." ::= { madcap 1 } madcapConfigExtraAllocationTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of extra time on either side of a lease which the MADCAP server allocates to allow for clock skew among clients." ::= { madcapConfig 1 } madcapConfigNoResponseDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time the MADCAP client allows for receiving a response from a MADCAP server." ::= { madcapConfig 2 } madcapConfigOfferHold OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time the MADCAP server will reserve an address for after sending an OFFER message in anticipation of receiving a REQUEST message." ::= { madcapConfig 3 } madcapConfigResponseCacheInterval OBJECT-TYPE SYNTAX Unsigned32 (0..300) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time the MADCAP server uses to detect duplicate messages." Thaler Standards Track [Page 21] RFC 3559 Multicast Address Allocation MIB June 2003 ::= { madcapConfig 4 } madcapConfigClockSkewAllowance OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The clock skew threshold used by the MADCAP server to generate Excessive Clock Skew errors." ::= { madcapConfig 5 } madcapCounters OBJECT-IDENTITY STATUS current DESCRIPTION "A group of objects that count various MADCAP events." ::= { madcap 2 } madcapTotalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of transactions for which the MADCAP server has detected an error of any type, regardless of whether the server ignored the request or generated a NAK." ::= { madcapCounters 1 } madcapRequestsDenied OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid requests for which the MADCAP server could not complete an allocation, regardless of whether NAKs were sent. This corresponds to the Valid Request Could Not Be Completed error code in MADCAP." ::= { madcapCounters 2 } madcapInvalidRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid requests received by the MADCAP server, regardless of whether NAKs were sent. This corresponds to the Invalid Request error code in MADCAP." ::= { madcapCounters 3 } Thaler Standards Track [Page 22] RFC 3559 Multicast Address Allocation MIB June 2003 madcapExcessiveClockSkews OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests received by the MADCAP server with an excessive clock skew, regardless of whether NAKs were sent. This corresponds to the Excessive Clock Skew error code in MADCAP." ::= { madcapCounters 4 } madcapBadLeaseIds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests received by the MADCAP server with an unrecognized Lease Identifier, regardless of whether NAKs were sent. This corresponds to the Lease Identifier Not Recognized error code in MADCAP." ::= { madcapCounters 5 } madcapDiscovers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of DISCOVER messages received by the MADCAP server." ::= { madcapCounters 6 } madcapInforms OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of INFORM messages received by the MADCAP server." ::= { madcapCounters 7 } madcapRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of REQUEST messages received by the MADCAP server." ::= { madcapCounters 8 } Thaler Standards Track [Page 23] RFC 3559 Multicast Address Allocation MIB June 2003 madcapRenews OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RENEW messages received by the MADCAP server." ::= { madcapCounters 9 } madcapReleases OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RELEASE messages received by the MADCAP server." ::= { madcapCounters 10 } -- conformance information mallocConformance OBJECT IDENTIFIER ::= { mallocMIB 2 } mallocCompliances OBJECT IDENTIFIER ::= { mallocConformance 1 } mallocGroups OBJECT IDENTIFIER ::= { mallocConformance 2 } -- compliance statements mallocServerReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for multicast address allocation servers implementing the MALLOC MIB without support for read-create (i.e., in read-only mode). Such a server can then be monitored but can not be configured with this MIB." MODULE -- this module MANDATORY-GROUPS { mallocBasicGroup, mallocServerGroup } OBJECT mallocScopeLastAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeHopLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." Thaler Standards Track [Page 24] RFC 3559 Multicast Address Allocation MIB June 2003 OBJECT mallocScopeStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeDivisible MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeSSM MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeNameScopeName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeNameDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeNameStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeNameStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeLastAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." Thaler Standards Track [Page 25] RFC 3559 Multicast Address Allocation MIB June 2003 OBJECT mallocAllocRangeStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeMaxLeaseAddrs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeMaxLeaseTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP madcapServerGroup DESCRIPTION "This group is mandatory for servers which implement the MADCAP client-server protocol." OBJECT madcapConfigExtraAllocationTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT madcapConfigOfferHold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT madcapConfigResponseCacheInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." Thaler Standards Track [Page 26] RFC 3559 Multicast Address Allocation MIB June 2003 OBJECT madcapConfigClockSkewAllowance MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mallocCompliances 1 } mallocClientReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for clients implementing the MALLOC MIB without support for read-create (i.e., in read- only mode). Such clients can then be monitored but can not be configured with this MIB." MODULE -- this module MANDATORY-GROUPS { mallocBasicGroup, mallocClientGroup } GROUP mallocClientScopeGroup DESCRIPTION "This group is mandatory for clients which maintain a list of multicast scopes." OBJECT mallocScopeLastAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeHopLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeServerAddressType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeServerAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." Thaler Standards Track [Page 27] RFC 3559 Multicast Address Allocation MIB June 2003 OBJECT mallocScopeSSM MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP madcapClientGroup DESCRIPTION "This group is mandatory for clients which implement the MADCAP client-server protocol." OBJECT madcapConfigNoResponseDelay MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mallocCompliances 2 } mallocPrefixCoordinatorReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for prefix coordinators implementing the MALLOC MIB without support for read-create (i.e., in read-only mode). Such devices can then be monitored but can not be configured with this MIB." MODULE -- this module MANDATORY-GROUPS { mallocBasicGroup, mallocPrefixCoordinatorGroup } OBJECT mallocScopeLastAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocScopeDivisible MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeLastAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." Thaler Standards Track [Page 28] RFC 3559 Multicast Address Allocation MIB June 2003 OBJECT mallocAllocRangeStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeAdvertisable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mallocAllocRangeStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mallocCompliances 3 } mallocServerFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for multicast address allocation servers implementing the MALLOC MIB with support for read- create. Such servers can then be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { mallocBasicGroup, mallocServerGroup } GROUP madcapServerGroup DESCRIPTION "This group is mandatory for servers which implement the MADCAP client-server protocol." ::= { mallocCompliances 4 } mallocClientFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts implementing the MALLOC MIB with support for read-create. Such clients can then be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { mallocBasicGroup, mallocClientGroup } Thaler Standards Track [Page 29] RFC 3559 Multicast Address Allocation MIB June 2003 GROUP mallocClientScopeGroup DESCRIPTION "This group is mandatory for clients which maintain a list of multicast scopes." GROUP madcapClientGroup DESCRIPTION "This group is mandatory for clients which implement the MADCAP client-server protocol." ::= { mallocCompliances 5 } mallocPrefixCoordinatorFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for prefix coordinators implementing the MALLOC MIB with support for read-create. Such devices can then be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { mallocBasicGroup, mallocPrefixCoordinatorGroup } ::= { mallocCompliances 6 } -- units of conformance mallocBasicGroup OBJECT-GROUP OBJECTS { mallocCapabilities, mallocRequestScopeAddressType, mallocRequestScopeFirstAddress, mallocRequestStartTime, mallocRequestEndTime, mallocRequestNumAddrs, mallocRequestState, mallocAddressNumAddrs, mallocAddressRequestId } STATUS current DESCRIPTION "The basic collection of objects providing management of IP multicast address allocation." ::= { mallocGroups 1 } mallocServerGroup OBJECT-GROUP OBJECTS { mallocScopeLastAddress, mallocScopeHopLimit, mallocScopeSSM, mallocScopeStatus, mallocScopeStorage, mallocAllocRangeLastAddress, mallocAllocRangeLifetime, mallocAllocRangeNumAllocatedAddrs, mallocAllocRangeNumOfferedAddrs, mallocAllocRangeNumWaitingAddrs, mallocAllocRangeNumTryingAddrs, mallocAllocRangeMaxLeaseAddrs, Thaler Standards Track [Page 30] RFC 3559 Multicast Address Allocation MIB June 2003 mallocAllocRangeMaxLeaseTime, mallocAllocRangeSource, mallocAllocRangeStatus, mallocAllocRangeStorage, mallocScopeDivisible, mallocScopeSource, mallocScopeNameScopeName, mallocScopeNameDefault, mallocScopeNameStatus, mallocScopeNameStorage, mallocRequestClientAddressType, mallocRequestClientAddress } STATUS current DESCRIPTION "A collection of objects providing management of multicast address allocation in servers." ::= { mallocGroups 2 } mallocClientGroup OBJECT-GROUP OBJECTS { mallocRequestServerAddressType, mallocRequestServerAddress } STATUS current DESCRIPTION "A collection of objects providing management of multicast address allocation in clients." ::= { mallocGroups 3 } madcapServerGroup OBJECT-GROUP OBJECTS { madcapConfigClockSkewAllowance, madcapConfigExtraAllocationTime, madcapConfigOfferHold, madcapConfigResponseCacheInterval, madcapTotalErrors, madcapRequestsDenied, madcapInvalidRequests, madcapBadLeaseIds, madcapExcessiveClockSkews, madcapDiscovers, madcapInforms, madcapRequests, madcapRenews, madcapReleases } STATUS current DESCRIPTION "A collection of objects providing management of MADCAP servers." ::= { mallocGroups 4 } madcapClientGroup OBJECT-GROUP OBJECTS { mallocRequestLeaseIdentifier, madcapConfigNoResponseDelay } STATUS current DESCRIPTION "A collection of objects providing management of MADCAP clients." ::= { mallocGroups 5 } Thaler Standards Track [Page 31] RFC 3559 Multicast Address Allocation MIB June 2003 mallocClientScopeGroup OBJECT-GROUP OBJECTS { mallocScopeLastAddress, mallocScopeHopLimit, mallocScopeStatus, mallocScopeStorage, mallocScopeSource, mallocScopeServerAddressType, mallocScopeServerAddress, mallocScopeSSM, mallocScopeNameScopeName, mallocScopeNameDefault, mallocScopeNameStatus, mallocScopeNameStorage } STATUS current DESCRIPTION "A collection of objects providing management of multicast scope information in clients." ::= { mallocGroups 6 } mallocPrefixCoordinatorGroup OBJECT-GROUP OBJECTS { mallocAllocRangeLastAddress, mallocAllocRangeLifetime, mallocAllocRangeStatus, mallocAllocRangeStorage, mallocAllocRangeSource, mallocAllocRangeTotalAllocatedAddrs, mallocAllocRangeTotalRequestedAddrs, mallocAllocRangeAdvertisable, mallocScopeLastAddress, mallocScopeDivisible, mallocScopeSource } STATUS current DESCRIPTION "A collection of objects for managing Prefix Coordinators." ::= { mallocGroups 7 } END 5. IANA Considerations The IANAscopeSource and IANAmallocRangeSource textual conventions are imported from the IANA-MALLOC-MIB. The purpose of defining these textual conventions in a separate MIB module is to allow additional values to be defined without having to issue a new version of this document. The Internet Assigned Numbers Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers; it will administer the values associated with these textual conventions. The rules for additions or changes to the IANA-MALLOC-MIB are outlined in the DESCRIPTION clause associated with its MODULE- IDENTITY statement. The current versions of the IANA-MALLOC-MIB can be accessed from the IANA home page at: "http://www.iana.org/". Thaler Standards Track [Page 32] RFC 3559 Multicast Address Allocation MIB June 2003 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: mallocScopeTable,mallocAllocRangeTable: Unauthorized modifications to these tables can result in denial of service by not being able to allocate and use multicast addresses, allocating too many addresses, allocating addresses that other organizations are already using, or causing applications to use a hop limit that results in extra bandwidth usage. mallocScopeNameTable: Unauthorized modifications to this table can result in incorrect or misleading scope names being presented to users, resulting in potentially using the wrong scope for application data. madcapConfigExtraAllocationTime,madcapConfigOfferHold: Unauthorized modifications to these objects can result in reservations lasting too long, potentially resulting in denial of service if allocation ranges are small. madcapConfigNoResponseDelay: Unauthorized modifications can result in a client not being able to allocate multicast addresses. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control GET and/or NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: mallocRequestLeaseIdentifier: If address allocation servers are configured to allow renewal or release purely on the basis of knowledge of the Lease Identifier, then unauthorized read access to mallocRequestLeaseIdentifier can be used in a denial-of-service attack. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to Thaler Standards Track [Page 33] RFC 3559 Multicast Address Allocation MIB June 2003 access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured for only those principals (users) with legitimate rights to have access to GET or SET (change/create/delete) objects. 7. Acknowledgements This MIB module was updated based on feedback from the IETF's Multicast Address Allocation (MALLOC) Working Group. Lars Viklund, Frank Strauss, and Mike Heard provided helpful feedback on this document. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Thaler Standards Track [Page 34] RFC 3559 Multicast Address Allocation MIB June 2003 9. References 9.1. Normative References [ARCH] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000. [MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2932] McCloghrie, K., Farinacci, D. and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000. [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 9.2. Informative References [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework", RFC 3410, December 2002. Thaler Standards Track [Page 35] RFC 3559 Multicast Address Allocation MIB June 2003 10. Author's Address Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com Thaler Standards Track [Page 36] RFC 3559 Multicast Address Allocation MIB June 2003 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Thaler Standards Track [Page 37] snmp-mibs-downloader-1.1/mibrfcs/rfc3584.txt0000644000000000000000000034102611402176071015573 0ustar Network Working Group R. Frye Request for Comments: 3584 Vibrant Solutions BCP: 74 D. Levi Obsoletes: 2576 Nortel Networks Category: Best Current Practice S. Routhier Wind River Systems, Inc. B. Wijnen Lucent Technologies August 2003 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. Frye, et al. Best Current Practice [Page 1] RFC 3584 Coexistence between SNMP versions August 2003 Table Of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. SMI and Management Information Mappings. . . . . . . . . . . 5 2.1. MIB Modules. . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Object Definitions . . . . . . . . . . . . . . 6 2.1.2. Trap and Notification Definitions . . . . . . 8 2.2. Compliance Statements. . . . . . . . . . . . . . . . . 9 2.3. Capabilities Statements. . . . . . . . . . . . . . . . 9 3. Translating Notification Parameters. . . . . . . . . . . . . 10 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters . . . . . . . . . . . . 11 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters . . . . . . . . . . . . 12 4. Approaches to Coexistence in a Multi-lingual Network . . . . 14 4.1. SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . . 14 4.2. Multi-lingual implementations. . . . . . . . . . . . . 15 4.2.1. Command Generator. . . . . . . . . . . . . . . 15 4.2.2. Command Responder. . . . . . . . . . . . . . . 16 4.2.2.1. Handling Counter64 . . . . . . . . . 16 4.2.2.2. Mapping SNMPv2 Exceptions. . . . . . 17 4.2.2.2.1. Mapping noSuchObject and noSuchInstance. . . . 18 4.2.2.2.2. Mapping endOfMibView. . . 18 4.2.2.3. Processing An SNMPv1 GetReques . . . 18 4.2.2.4. Processing An SNMPv1 GetNextRequest. 19 4.2.2.5. Processing An SNMPv1 SetRequest. . . 20 4.2.3. Notification Originator. . . . . . . . . . . . 21 4.2.4. Notification Receiver. . . . . . . . . . . . . 21 4.3. Proxy Implementations. . . . . . . . . . . . . . . . . 22 4.3.1. Upstream Version Greater Than Downstream Version. . . . . . . . . . . . . . . . . . . . 22 4.3.2. Upstream Version Less Than Downstream Version. 23 4.4. Error Status Mappings. . . . . . . . . . . . . . . . . 25 5. Message Processing Models and Security Models. . . . . . . . 26 5.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . 26 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model . . . . . . . . . . . . . . . . . . . . 26 5.2.1. Processing An Incoming Request . . . . . . . . 27 5.2.2. Generating An Outgoing Response. . . . . . . . 29 5.2.3. Generating An Outgoing Notification. . . . . . 29 5.2.4. Proxy Forwarding Of Requests . . . . . . . . . 30 5.3. The SNMP Community MIB Module. . . . . . . . . . . . . 30 6. Intellectual Property Statement. . . . . . . . . . . . . . . 42 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 43 Frye, et al. Best Current Practice [Page 2] RFC 3584 Coexistence between SNMP versions August 2003 8. Security Considerations. . . . . . . . . . . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . 44 9.2. Informative References . . . . . . . . . . . . . . . . 46 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 47 A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . . 47 A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . . 49 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 51 1. Overview The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. There are four general aspects of coexistence described in this document. Each of these is described in a separate section: - Conversion of MIB documents between SMIv1 and SMIv2 formats is documented in section 2. - Mapping of notification parameters is documented in section 3. - Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network is documented in section 4. This section addresses the processing of protocol operations in multi-lingual implementations, as well as behaviour of proxy implementations. - The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 into the View-Based Access Control Model (VACM) [20], is documented in section 5 (this section also addresses the SNMPv2c Message Processing Model and Community-Based Security Model). Frye, et al. Best Current Practice [Page 3] RFC 3584 Coexistence between SNMP versions August 2003 1.1. SNMPv1 SNMPv1 is defined by these documents: - STD 15, RFC 1157 [RFC1157] which defines the Simple Network Management Protocol (SNMPv1), the protocol used for network access to managed objects. - STD 16, RFC 1155 [RFC1155] which defines the Structure of Management Information (SMIv1), the mechanisms used for describing and naming objects for the purpose of management. - STD 16, RFC 1212 [RFC1212] which defines a more concise description mechanism, which is wholly consistent with the SMIv1. - RFC 1215 [RFC1215] which defines a convention for defining Traps for use with the SMIv1. Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the information presented in RFC 1155, RFC 1212, and RFC 1215. 1.2. SNMPv2 SNMPv2 is defined by these documents: - STD 58, RFC 2578 which defines Version 2 of the Structure of Management Information (SMIv2) [RFC2578]. - STD 58, RFC 2579 which defines common MIB "Textual Conventions" [RFC2579]. - STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [RFC2580]. - STD 62, RFC 3416 which defines the Protocol Operations used in processing [RFC3416]. - STD 62, RFC 3417 which defines the Transport Mappings used "on the wire" [RFC3417]. - STD 62, RFC 3418 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [RFC3418]. Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580). Frye, et al. Best Current Practice [Page 4] RFC 3584 Coexistence between SNMP versions August 2003 The following document augments the definition of SNMPv2: - RFC 1901 [RFC1901] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This is referred to throughout this document as SNMPv2c. 1.3. SNMPv3 SNMPv3 is defined by these documents: - STD 62, RFC 3411 which defines an Architecture for Describing SNMP Management Frameworks [RFC3411]. - STD 62, RFC 3412 which defines Message Processing and Dispatching [RFC3412]. - STD 62, RFC 3413 which defines various SNMP Applications [RFC3413]. - STD 62, RFC 3414 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [RFC3414]. - STD 62, RFC 3415 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [RFC3415]. SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 and the SMIv2 definitions of 2578 through 2580 described above. Note that text throughout this document that refers to SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3. 2. SMI and Management Information Mappings The SMIv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the SMIv1. For example, both approaches use an adapted subset of ASN.1 [ASN1] as the basis for a formal descriptive notation. Indeed, one might note that the SMIv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SMIv1. The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements. Frye, et al. Best Current Practice [Page 5] RFC 3584 Coexistence between SNMP versions August 2003 2.1. MIB Modules MIB modules defined using the SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for SMIv1 MIB modules to conform to the SMIv2, the following changes SHALL be made: 2.1.1. Object Definitions In general, conversion of a MIB module does not require the deprecation of the objects contained therein. If the definition of an object is truly inadequate for its intended purpose, the object SHALL be deprecated or obsoleted, otherwise deprecation is not required. (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212. (2) The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement. (3) For any object with a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32. (4) For any object with a SYNTAX clause value of Gauge, the object MUST have the value of its SYNTAX clause changed to Gauge32, or Unsigned32 where appropriate. (5) For all objects, the ACCESS clause MUST be replaced by a MAX- ACCESS clause. The value of the MAX-ACCESS clause SHALL be the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, SHALL have a MAX-ACCESS clause of "read-create". If the value of the ACCESS clause is "write-only", then the value of the MAX-ACCESS clause MUST be "read-write", and the DESCRIPTION clause SHALL note that reading this object will result in implementation-specific results. Note that in SMIv1, the ACCESS clause specifies the minimal required access, while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed access. This should be considered when converting an ACCESS clause to a MAX-ACCESS clause. (6) For all objects, if the value of the STATUS clause is "mandatory" or "optional", the value MUST be replaced with "current", "deprecated", or "obsolete" depending on the current usage of such objects. Frye, et al. Best Current Practice [Page 6] RFC 3584 Coexistence between SNMP versions August 2003 (7) For any object not containing a DESCRIPTION clause, the object MUST have a DESCRIPTION clause defined. (8) For any object corresponding to a conceptual row which does not have an INDEX clause, the object MUST have either an INDEX clause or an AUGMENTS clause defined. (9) If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object MUST be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object MUST have a syntax of INTEGER, it MUST be not-accessible, and its value MUST always be 1. The effect of this, and the preceding bullet, is to allow one to convert a MIB module in SMIv1 format to one in SMIv2 format, and then use it with the SNMPv1 protocol with no impact to existing SNMPv1 agents and managers. (10) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress). (11) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub- identifiers, the value MUST be changed to reference a single ASN.1 identifier. This may require defining a series of new administrative assignments (OBJECT IDENTIFIERS) in order to define the single ASN.1 identifier. (12) One or more OBJECT-GROUPS MUST be defined, and related objects MUST be collected into appropriate groups. Note that SMIv2 requires all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP. (13) For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object MUST be changed to "obsolete". (14) For any conceptual row object that is not immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to "obsolete". Frye, et al. Best Current Practice [Page 7] RFC 3584 Coexistence between SNMP versions August 2003 Other changes are desirable, but not necessary: (1) Creation and deletion of conceptual rows is inconsistent using the SMIv1. The SMIv2 corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then the objects relating to those tables MAY be deprecated and replaced with objects defined using the new approach. The approach based on SMIv2 can be found in section 7 of RFC 2578 [RFC2578], and the RowStatus and StorageType TEXTUAL-CONVENTIONs are described in section 2 of RFC 2579 [RFC2579]. (2) For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object SHOULD have the value of its SYNTAX clause changed to Integer32, or have an appropriate range specified. (3) For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper- bounds on its length), the bounds for the size of the object SHOULD be defined. (4) All textual conventions informally defined in the MIB module SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention. (5) For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object. (6) For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause SHOULD be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension. 2.1.2. Trap and Notification Definitions If a MIB module is changed to conform to the SMIv2, then each occurrence of the TRAP-TYPE macro MUST be changed to a corresponding invocation of the NOTIFICATION-TYPE macro: Frye, et al. Best Current Practice [Page 8] RFC 3584 Coexistence between SNMP versions August 2003 (1) The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], and MUST reference SNMPv2-SMI instead. (2) The ENTERPRISE clause MUST be removed. (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. (4) A STATUS clause MUST be added, with an appropriate value. Normally the value should be 'current', although 'deprecated' or 'obsolete' may be used as needed. (5) The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation SHALL be the value of the ENTERPRISE clause extended with two sub- identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause is 'snmp', then the value of the invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the same manner as described in section 3.1 in this document. (6) A DESCRIPTION clause MUST be added, if not already present. (7) One or more NOTIFICATION-GROUPs MUST be defined, and related notifications MUST be collected into those groups. Note that SMIv2 requires that all NOTIFICATION-TYPEs be a member of at least one NOTIFICATION-GROUP. 2.2. Compliance Statements For those information modules which are "standards track", a corresponding invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within the information module (or in a companion information module), and any commentary text in the information module which relates to compliance SHOULD be removed. Typically this editing can occur when the information module undergoes review. Note that a MODULE-COMPLIANCE statement is not required for a MIB document that is not on the standards track (for example, an enterprise MIB), though it may be useful in some circumstances to define a MODULE-COMPLIANCE statement for such a MIB document. 2.3. Capabilities Statements RFC 1303 [RFC1303] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. Frye, et al. Best Current Practice [Page 9] RFC 3584 Coexistence between SNMP versions August 2003 Converting such a description for use with the SMIv2 requires these changes: (1) The macro name AGENT-CAPABILITIES MUST be used instead of MODULE-CONFORMANCE. (2) The STATUS clause MUST be added, with a value of 'current'. (3) All occurrences of the CREATION-REQUIRES clause MUST either be omitted if appropriate, or be changed such that the semantics are consistent with RFC 2580 [RFC2580]. In order to ease coexistence, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDEd. (Note that this method is ambiguous when different revisions of an SMIv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SMIv2 in order to define the object groups unambiguously.) 3. Translating Notification Parameters This section describes how parameters used for generating notifications are translated between the format used for SNMPv1 notification protocol operations and the format used for SNMPv2 notification protocol operations. The parameters used to generate a notification are called 'notification parameters'. The format of parameters used for SNMPv1 notification protocol operations is referred to in this document as 'SNMPv1 notification parameters'. The format of parameters used for SNMPv2 notification protocol operations is referred to in this document as 'SNMPv2 notification parameters'. The situations where notification parameters MUST be translated are: - When an entity generates a set of notification parameters in a particular format, and the configuration of the entity indicates that the notification must be sent using an SNMP message version that requires the other format for notification parameters. - When a proxy receives a notification that was sent using an SNMP message version that requires one format of notification parameters, and must forward the notification using an SNMP message version that requires the other format of notification parameters. Frye, et al. Best Current Practice [Page 10] RFC 3584 Coexistence between SNMP versions August 2003 In addition, it MAY be desirable to translate notification parameters in a notification receiver application in order to present notifications to the end user in a consistent format. Note that for the purposes of this section, the set of notification parameters is independent of whether the notification is to be sent as a trap or an inform. SNMPv1 notification parameters consist of: - An enterprise parameter (OBJECT IDENTIFIER). - An agent-addr parameter (NetworkAddress). - A generic-trap parameter (INTEGER). - A specific-trap parameter (INTEGER). - A time-stamp parameter (TimeTicks). - A list of variable-bindings (VarBindList). SNMPv2 notification parameters consist of: - A sysUpTime parameter (TimeTicks). This appears in the first variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in the second variable-binding in an SNMPv2-Trap-PDU or InformRequest- PDU, and is equal to the value portion of that variable-binding (not the name portion, as both the name and value are OBJECT IDENTIFIERs). - A list of variable-bindings (VarBindList). This refers to all but the first two variable-bindings in an SNMPv2-Trap-PDU or InformRequest-PDU. 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters The following procedure describes how to translate SNMPv1 notification parameters into SNMPv2 notification parameters: (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the SNMPv1 time-stamp parameter. Frye, et al. Best Current Practice [Page 11] RFC 3584 Coexistence between SNMP versions August 2003 (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of the SNMPv1 enterprise parameter and two additional sub- identifiers, '0', and the SNMPv1 specific-trap parameter. (3) If the SNMPv1 generic-trap parameter is not 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the corresponding trap as defined in section 2 of RFC 3418 [RFC3418]: generic-trap parameter snmpTrapOID.0 ============ ============= 0 1.3.6.1.6.3.1.1.5.1 (coldStart) 1 1.3.6.1.6.3.1.1.5.2 (warmStart) 2 1.3.6.1.6.3.1.1.5.3 (linkDown) 3 1.3.6.1.6.3.1.1.5.4 (linkUp) 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable- bindings. In addition, if the translation is being performed by a proxy in order to forward a received trap, three additional variable-bindings will be appended, if these three additional variable-bindings do not already exist in the SNMPv1 variable- bindings. The name portion of the first additional variable binding SHALL contain snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent-addr parameter. The name portion of the second additional variable binding SHALL contain snmpTrapCommunity.0, and the value SHALL contain the value of the community-string field from the received SNMPv1 message which contained the SNMPv1 Trap-PDU. The name portion of the third additional variable binding SHALL contain snmpTrapEnterprise.0 [RFC3418], and the value SHALL be the SNMPv1 enterprise parameter. 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters The following procedure describes how to translate SNMPv2 notification parameters into SNMPv1 notification parameters: (1) The SNMPv1 enterprise parameter SHALL be determined as follows: - If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC 3418 [RFC3418], then the SNMPv1 enterprise parameter SHALL be set to the value of the variable-binding in the SNMPv2 variable-bindings whose name is Frye, et al. Best Current Practice [Page 12] RFC 3584 Coexistence between SNMP versions August 2003 snmpTrapEnterprise.0 if that variable-binding exists. If it does not exist, the SNMPv1 enterprise parameter SHALL be set to the value 'snmpTraps' as defined in RFC 3418 [RFC3418]. - If the SNMPv2 snmpTrapOID parameter is not one of the standard traps as defined in RFC 3418 [RFC3418], then the SNMPv1 enterprise parameter SHALL be determined from the SNMPv2 snmpTrapOID parameter as follows: - If the next-to-last sub-identifier of the snmpTrapOID value is zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value with the last 2 sub-identifiers removed, otherwise - If the next-to-last sub-identifier of the snmpTrapOID value is non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value with the last sub-identifier removed. (2) The SNMPv1 agent-addr parameter SHALL be determined based on the situation in which the translation occurs. - If the translation occurs within a notification originator application, and the notification is to be sent over IP, the SNMPv1 agent-addr parameter SHALL be set to the IP address of the SNMP entity in which the notification originator resides. If the notification is to be sent over some other transport, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. - If the translation occurs within a proxy application, the proxy must attempt to extract the original source of the notification from the variable-bindings. If the SNMPv2 variable-bindings contains a variable binding whose name is snmpTrapAddress.0, the agent-addr parameter SHALL be set to the value of that variable binding. Otherwise, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC 3418 [RFC3418], the SNMPv1 generic-trap parameter SHALL be set as follows: snmpTrapOID.0 parameter generic-trap =============================== ============ 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 Frye, et al. Best Current Practice [Page 13] RFC 3584 Coexistence between SNMP versions August 2003 Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC 3418 [RFC3418], the SNMPv1 specific-trap parameter SHALL be set to zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID parameter. (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the SNMPv2 sysUpTime parameter. (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable- bindings (and note that the SNMPv2 variable-bindings do not include the variable-bindings containing sysUpTime.0, snmpTrapOID.0). Note, however, that if the SNMPv2 variable- bindings contain any objects whose type is Counter64, the translation to SNMPv1 notification parameters cannot be performed. In this case, the notification cannot be encoded in an SNMPv1 packet (and so the notification cannot be sent using SNMPv1, see section 4.2.3 and section 4.3). 4. Approaches to Coexistence in a Multi-lingual Network There are two basic approaches to coexistence in a multi-lingual network, multi-lingual implementations and proxy implementations. Multi-lingual implementations allow elements in a network to communicate with each other using an SNMP version which both elements support. This allows a multi-lingual implementation to communicate with any mono-lingual implementation, regardless of the SNMP version supported by the mono-lingual implementation. Proxy implementations provide a mechanism for translating between SNMP versions using a third party network element. This allows network elements which support only a single, but different, SNMP version to communicate with each other. Proxy implementations are also useful for securing communications over an insecure link between two locally secure networks. 4.1. SNMPv1 and SNMPv2 Access to MIB Data Throughout section 4., this document refers to 'SNMPv1 Access to MIB Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part of an SNMP agent which actually accesses instances of MIB objects, and which actually initiates generation of notifications. Differences between the two types of access to MIB data are: - Error-status values generated. Frye, et al. Best Current Practice [Page 14] RFC 3584 Coexistence between SNMP versions August 2003 - Generation of exception codes. - Use of the Counter64 data type. - The format of parameters provided when a notification is generated. SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Note also that SNMPv1 access to MIB data will actually never generate a readOnly error (a noSuchName error would always occur in the situation where one would expect a readOnly error). SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. Note that SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors. Note that a particular multi-lingual implementation may choose to implement all access to MIB data as SNMPv2 access to MIB data, and perform the translations described herein for SNMPv1-based transactions. Further, note that there is no mention of 'SNMPv3 access to MIB data' in this document, as SNMPv3 uses SNMPv2 PDU types and protocol operations. 4.2. Multi-lingual implementations This approach requires an entity to support multiple SNMP message versions. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 message versions. The behaviour of various types of SNMP applications which support multiple message versions is described in the following sections. This approach allows entities which support multiple SNMP message versions to coexist with and communicate with entities which support only a single SNMP message version. 4.2.1. Command Generator A command generator must select an appropriate message version when sending requests to another entity. One way to achieve this is to consult a local database to select the appropriate message version. In addition, a command generator MUST 'downgrade' GetBulk requests to GetNext requests when selecting SNMPv1 as the message version for an Frye, et al. Best Current Practice [Page 15] RFC 3584 Coexistence between SNMP versions August 2003 outgoing request. This is done by simply changing the operation type to GetNext, ignoring any non-repeaters and max-repetitions values, and setting error-status and error-index to zero. 4.2.2. Command Responder A command responder must be able to deal with both SNMPv1 and SNMPv2 access to MIB data. There are three aspects to dealing with this. A command responder must: - Deal correctly with SNMPv2 access to MIB data that returns a Counter64 value while processing an SNMPv1 message, - Deal correctly with SNMPv2 access to MIB data that returns one of the three exception values while processing an SNMPv1 message, and - Map SNMPv2 error codes returned from SNMPv2 access to MIB data into SNMPv1 error codes when processing an SNMPv1 message. Note that SNMPv1 error codes SHOULD NOT be used without any change when processing SNMPv2c or SNMPv3 messages, except in the case of proxy forwarding. Also, SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages. In the case of proxy forwarding, for backwards compatibility, SNMPv1 error codes may be used without any change in a forwarded SNMPv2c or SNMPv3 message. The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which uses SNMPv2 access to MIB data when processing an SNMPv1 message. 4.2.2.1. Handling Counter64 The SMIv2 [RFC2578] defines one new syntax that is incompatible with SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1. The impact on multi-lingual command responders is that they MUST NOT ever return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message version. Multi-lingual command responders SHALL take the approach that object instances whose type is Counter64 are implicitly excluded from view when processing an SNMPv1 message. So: - On receipt of an SNMPv1 GetRequest-PDU containing a variable binding whose name field points to an object instance of type Counter64, a GetResponsePDU SHALL be returned, with an error- Frye, et al. Best Current Practice [Page 16] RFC 3584 Coexistence between SNMP versions August 2003 status of noSuchName and the error-index set to the variable binding that caused this error. - On an SNMPv1 GetNextRequest-PDU, any object instance which contains a syntax of Counter64 SHALL be skipped, and the next accessible object instance that does not have the syntax of Counter64 SHALL be retrieved. If no such object instance exists, then an error-status of noSuchName SHALL be returned, and the error-index SHALL be set to the variable binding that caused this error. - Any SNMPv1 request which contains a variable binding with a Counter64 value is ill-formed, so the foregoing rules do not apply. If that error is detected, a response SHALL NOT be returned, since it would contain a copy of the ill-formed variable binding. Instead, the offending PDU SHALL be discarded and the counter snmpInASNParseErrs SHALL be incremented. 4.2.2.2. Mapping SNMPv2 Exceptions SNMPv2 provides a feature called exceptions, which allow an SNMPv2 Response PDU to return as much management information as possible, even when an error occurs. However, SNMPv1 does not support exceptions, and so an SNMPv1 Response PDU cannot return any management information, and can only return an error-status and an error-index value. When an SNMPv1 request is received, a command responder MUST check any variable bindings returned using SNMPv2 access to MIB data for exception values, and convert these exception values into SNMPv1 error codes. The type of exception that can be returned when accessing MIB data and the action taken depends on the type of SNMP request. - For a GetRequest, a noSuchObject or noSuchInstance exception may be returned. - For a GetNextRequest, an endOfMibView exception may be returned. - No exceptions will be returned for a SetRequest, and a GetBulkRequest should only be received in an SNMPv2c or SNMPv3 message, so these request types may be ignored when mapping exceptions. Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference. Frye, et al. Best Current Practice [Page 17] RFC 3584 Coexistence between SNMP versions August 2003 4.2.2.2.1. Mapping noSuchObject and noSuchInstance A noSuchObject or noSuchInstance exception generated by an SNMPv2 access to MIB data indicates that the requested object instance can not be returned. The SNMPv1 error code for this condition is noSuchName, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU. 4.2.2.2.2. Mapping endOfMibView When an SNMPv2 access to MIB data returns a variable binding containing an endOfMibView exception, it indicates that there are no object instances available which lexicographically follow the object in the request. In an SNMPv1 agent, this condition normally results in a noSuchName error, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU. 4.2.2.3. Processing An SNMPv1 GetRequest When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data. When such an access to MIB data returns response data using SNMPv2 syntax and error-status values, then: (1) If the error-status is anything other than noError, - The error status SHALL be translated to an SNMPv1 error- status using the table in section 4.4, "Error Status Mappings". - The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request. Frye, et al. Best Current Practice [Page 18] RFC 3584 Coexistence between SNMP versions August 2003 (2) If the error-status is noError, the variable bindings SHALL be checked for any SNMPv2 exception (noSuchObject or noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If there are any such variable bindings, one of those variable bindings SHALL be selected (it is an implementation choice as to which is selected), and: - The error-status SHALL be set to noSuchName, - The error-index SHALL be set to the position (in the variable binding list of the original request) of the selected variable binding, and - The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request. (3) If there are no such variable bindings, then: - The error-status SHALL be set to noError, - The error-index SHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data. 4.2.2.4. Processing An SNMPv1 GetNextRequest When processing an SNMPv1 GetNextRequest, the following procedures MUST be followed when SNMPv2 access to MIB data is used as part of processing the request. There may be repetitive accesses to MIB data to try to find the first object which lexicographically follows each of the objects in the request. This is implementation specific. These procedures are followed only for data returned when using SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB data may be treated in the normal manner for an SNMPv1 request. First, if the access to MIB data returns an error-status of anything other than noError: (1) The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.4, "Error Status Mappings". (2) The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status. Frye, et al. Best Current Practice [Page 19] RFC 3584 Coexistence between SNMP versions August 2003 (3) The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request. Otherwise, if the access to MIB data returns an error-status of noError: (1) Any variable bindings containing an SNMPv2 syntax of Counter64 SHALL be considered to be not in view, and MIB data SHALL be accessed as many times as is required until either a value other than Counter64 is returned, or an error or endOfMibView exception occurs. (2) If there is any variable binding that contains an SNMPv2 exception endOfMibView (if there is more than one then it is an implementation decision as to which is chosen): - The error-status SHALL be set to noSuchName, - The error-index SHALL be set to the position (in the variable binding list of the original request) of the variable binding that returned such an SNMPv2 exception, and - The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request. (3) If there are no such variable bindings, then: - The error-status SHALL be set to noError, - The error-index SHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data. 4.2.2.5. Processing An SNMPv1 SetRequest When processing an SNMPv1 SetRequest, the following procedures MUST be followed when using SNMPv2 access to MIB data. When such MIB access returns response data using SNMPv2 syntax and error-status values, and the error-status is anything other than noError, then: - The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.4, "Error Status Mappings". Frye, et al. Best Current Practice [Page 20] RFC 3584 Coexistence between SNMP versions August 2003 - The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request. 4.2.3. Notification Originator A notification originator must be able to translate between SNMPv1 notification parameters and SNMPv2 notification parameters in order to send a notification using a particular SNMP message version. If a notification is generated using SNMPv1 notification parameters, and configuration information specifies that notifications be sent using SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2 notification parameters. Likewise, if a notification is generated using SNMPv2 notification parameters, and configuration information specifies that notifications be sent using SNMPv1, the notification parameters must be translated to SNMPv1 notification parameters. In this case, if the notification cannot be translated (due to the presence of a Counter64 type), it will not be sent using SNMPv1. When a notification originator generates a notification, using parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- MIB, if the SNMP version used to generate the notification is SNMPv1, the PDU type used will always be a TrapPDU, regardless of whether the value of snmpNotifyType is trap(1) or inform(2). Note also that access control and notification filtering are performed in the usual manner for notifications, regardless of the SNMP message version to be used when sending a notification. The parameters for performing access control are found in the usual manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP- NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in order to perform the access check specified in [RFC3413], section 3.3, bullet (3), the notification originator may need to generate a value for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of this document. If the SNMPv1 notification parameters being used were previously translated from a set of SNMPv2 notification parameters, this value may already be known, in which case it need not be generated. 4.2.4. Notification Receiver There are no special requirements of a notification receiver. However, an implementation may find it useful to allow a higher level application to request whether notifications should be delivered to a Frye, et al. Best Current Practice [Page 21] RFC 3584 Coexistence between SNMP versions August 2003 higher level application using SNMPv1 notification parameter or SNMPv2 notification parameters. The notification receiver would then translate notification parameters when required in order to present a notification using the desired set of parameters. 4.3. Proxy Implementations A proxy implementation may be used to enable communication between entities which support different SNMP message versions. This is accomplished in a proxy forwarder application by performing translations on PDUs. These translations depend on the PDU type, the SNMP version of the packet containing a received PDU, and the SNMP version to be used to forward a received PDU. The following sections describe these translations. In all cases other than those described below, the proxy SHALL forward a received PDU without change, subject to size constraints as defined in section 5.3 (Community MIB) of this document. Note that in the following sections, the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator, regardless of the PDU type or direction. 4.3.1. Upstream Version Greater Than Downstream Version - If a GetBulkRequest-PDU is received and must be forwarded using the SNMPv1 message version, the proxy forwarder SHALL act as if the non-repeaters and max-repetitions fields were both set to 0, and SHALL set the tag of the PDU to GetNextRequest-PDU. - If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request received by the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL remove the contents of the variable-bindings field and ensure that the error-index field is set to 0 before forwarding the response. - If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request received by the proxy was a GetBulkRequest-PDU, the proxy forwarder SHALL re-send the forwarded request (which would have been altered to be a GetNextRequest-PDU) with all but the first variable-binding removed. The proxy forwarder SHALL only re-send such a request a single time. If the resulting GetResponse-PDU also contains an error-status field with a value of 'tooBig', then the proxy forwarder SHALL remove the contents of the variable- Frye, et al. Best Current Practice [Page 22] RFC 3584 Coexistence between SNMP versions August 2003 bindings field, and change the error-status field to 'noError', and ensure that the error-index field is set to 0 before forwarding the response. Note that if the original request only contained a single variable-binding, the proxy may skip re-sending the request and simply remove the variable-bindings and change the error-status to 'noError'. Further note that, while it might have been possible to fit more variable bindings if the proxy only re- sent the request multiple times, and stripped only a single variable binding from the request at a time, this is deemed too expensive. The approach described here preserves the behaviour of a GetBulkRequest as closely as possible, without incurring the cost of re-sending the request multiple times. - If a Trap-PDU is received, and will be forwarded using the SNMPv2c or SNMPv3 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as an SNMPv2-Trap-PDU. Note that when an SNMPv1 agent generates a message containing a Trap-PDU which is subsequently forwarded by one or more proxy forwarders using SNMP versions other than SNMPv1, the community string and agent-addr fields from the original message generated by the SNMPv1 agent will be preserved through the use of the snmpTrapAddress and snmpTrapCommunity objects. 4.3.2. Upstream Version Less Than Downstream Version - If a GetResponse-PDU is received in response to a GetRequest-PDU (previously generated by the proxy) which contains variable- bindings of type Counter64 or which contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error-status value, and containing an error-index value indicating the position of the variable-binding containing the Counter64 type or exception code. - If a GetResponse-PDU is received in response to a GetNextRequest- PDU (previously generated by the proxy) which contains variable- bindings that contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error-status value, and containing an error-index value indicating the position of the variable-binding containing the exception code. Frye, et al. Best Current Practice [Page 23] RFC 3584 Coexistence between SNMP versions August 2003 - If a GetResponse-PDU is received in response to a GetNextRequest- PDU (previously generated by the proxy) which contains variable- bindings of type Counter64, the proxy MUST re-send the entire GetNextRequest-PDU, with the following modifications. For any variable bindings in the received GetResponse which contained Counter64 types, the proxy substitutes the object names of these variable bindings for the corresponding object names in the previously-sent GetNextRequest. The proxy MUST repeat this process until no Counter64 objects are returned. Note that an implementation may attempt to optimize this process of skipping Counter64 objects. One approach to such an optimization would be to replace the last sub-identifier of the object names of varbinds containing a Counter64 type with 65535 if that sub-identifier is less than 65535, or with 4294967295 if that sub-identifier is greater than 65535. This approach should skip multiple instances of the same Counter64 object, while maintaining compatibility with some broken agent implementations (which only use 16-bit integers for sub-identifiers). Deployment Hint: The process of repeated GetNext requests used by a proxy when Counter64 types are returned can be expensive. When deploying a proxy, this can be avoided by configuring the target agents to which the proxy forwards requests in a manner such that any objects of type Counter64 are in fact not-in-view for the principal that the proxy is using when communicating with these agents. However, when using such a configuration, one should be careful to use a different principal for communicating with the target agent when an incoming SNMPv2c or SNMPv3 request is received, to ensure that objects of type Counter64 are properly returned. - If a GetResponse-PDU is received which contains an SNMPv2 error- status value of wrongValue, wrongEncoding, wrongType, wrongLength, inconsistentValue, noAccess, notWritable, noCreation, inconsistentName, resourceUnavailable, commitFailed, undoFailed, or authorizationError, and the message would be forwarded using the SNMPv1 message version, the error-status value is modified using the mappings in section 4.4. - If an SNMPv2-Trap-PDU is received, and will be forwarded using the SNMPv1 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as a Trap-PDU. Note that if the translation fails due to the existence of a Counter64 data-type in the received SNMPv2-Trap- PDU, the trap cannot be forwarded using SNMPv1. Frye, et al. Best Current Practice [Page 24] RFC 3584 Coexistence between SNMP versions August 2003 - If an InformRequest-PDU is received, any configuration information indicating that it would be forwarded using the SNMPv1 message version SHALL be ignored. An InformRequest-PDU can only be forwarded using the SNMPv2c or SNMPv3 message version. The InformRequest-PDU may still be forwarded if there is other configuration information indicating that it should be forwarded using SNMPv2c or SNMPv3. 4.4. Error Status Mappings The following tables shows the mappings of SNMPv1 error-status values into SNMPv2 error-status values, and the mappings of SNMPv2 error- status values into SNMPv1 error-status values. SNMPv1 error-status SNMPv2 error-status =================== =================== noError noError tooBig tooBig noSuchName noSuchName badValue badValue genErr genErr SNMPv2 error-status SNMPv1 error-status =================== =================== noError noError tooBig tooBig genErr genErr wrongValue badValue wrongEncoding badValue wrongType badValue wrongLength badValue inconsistentValue badValue noAccess noSuchName notWritable noSuchName noCreation noSuchName inconsistentName noSuchName resourceUnavailable genErr commitFailed genErr undoFailed genErr authorizationError noSuchName Whenever the SNMPv2 error-status value of authorizationError is translated to an SNMPv1 error-status value of noSuchName, the value of snmpInBadCommunityUses MUST be incremented. Frye, et al. Best Current Practice [Page 25] RFC 3584 Coexistence between SNMP versions August 2003 5. Message Processing Models and Security Models In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, the following Message Processing (MP) models are defined in this document: - The SNMPv1 Message Processing Model - The SNMPv1 Community-Based Security Model - The SNMPv2c Message Processing Model - The SNMPv2c Community-Based Security Model In most respects, the SNMPv1 Message Processing Model and the SNMPv2c Message Processing Model are identical, and so these are not discussed independently in this document. Differences between the two models are described as required. Similarly, the SNMPv1 Community-Based Security Model and the SNMPv2c Community-Based Security Model are nearly identical, and so are not discussed independently. Differences between these two models are also described as required. 5.1. Mappings The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model require mappings between parameters used in SNMPv1 (and SNMPv2c) messages, and the version independent parameters used in the SNMP architecture [RFC3411]. The parameters which MUST be mapped consist of the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and contextEngineID/contextName pair. A MIB module (the SNMP- COMMUNITY-MIB) is provided in this document in order to perform these mappings. This MIB provides mappings in both directions, that is, a community name may be mapped to a securityName, contextEngineID, and contextName, or the combination of securityName, contextEngineID, and contextName may be mapped to a community name. 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model The SNMPv1 Message Processing Model handles processing of SNMPv1 messages. The processing of messages is handled generally in the same manner as described in RFC 1157 [RFC1157], with differences and clarifications as described in the following sections. The SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for SNMPv2c is 1). Frye, et al. Best Current Practice [Page 26] RFC 3584 Coexistence between SNMP versions August 2003 5.2.1. Processing An Incoming Request In RFC 1157 [RFC1157], section 4.1, item (3) for an entity which receives a message, states that various parameters are passed to the "desired authentication scheme". The desired authentication scheme in this case is the SNMPv1 Community-Based Security Model, which will be called using the processIncomingMsg ASI. The parameters passed to this ASI are: - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c). - The maxMessageSize, which should be the maximum size of a message that the receiving entity can generate (since there is no such value in the received message). - The securityParameters, which consist of the community string and the message's source and destination transport domains and addresses. - The securityModel, which will be 1 (or 2 for SNMPv2c). - The securityLevel, which will be noAuthNoPriv. - The wholeMsg and wholeMsgLength. The Community-Based Security Model will attempt to select a row in the snmpCommunityTable. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected: - The community string is equal to the snmpCommunityName value. - If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the transportDomain and transportAddress from which the message was received must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value. The snmpTargetAddrTMask object is used as described in section 5.3 when checking whether the transportDomain and transportAddress matches a entry in the snmpTargetAddrTable. If no such entry can be found, an authentication failure occurs as described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames counter is incremented. Frye, et al. Best Current Practice [Page 27] RFC 3584 Coexistence between SNMP versions August 2003 The parameters returned from the Community-Based Security Model are: - The securityEngineID, which will always be the local value of snmpEngineID.0. - The securityName, which will be the value of snmpCommunitySecurityName from the selected row in the snmpCommunityTable. - The scopedPDU. Note that this parameter will actually consist of three values, the contextSnmpEngineID (which will be the value of snmpCommunityContextEngineID from the selected entry in the snmpCommunityTable), the contextName (which will be the value of snmpCommunityContextName from the selected entry in the snmpCommunityTable), and the PDU. These must be separate values, since the first two do not actually appear in the message. - The maxSizeResponseScopedPDU, which will be derived using the minimum of the maxMessageSize above, and the value of snmpTargetAddrMMS of the selected row in the snmpTargetAddrTable. If no such entry was selected, then this value will be derived from the maxMessageSize only. - The securityStateReference, which MUST contain the community string from the original request. The appropriate SNMP application will then be called (depending on the value of the contextEngineID and the request type in the PDU) using the processPdu ASI. The parameters passed to this ASI are: - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c). - The securityModel, which will be 1 (or 2 for SNMPv2c). - The securityName, which was returned from the call to processIncomingMsg. - The securityLevel, which is noAuthNoPriv. - The contextEngineID, which was returned as part of the ScopedPDU from the call to processIncomingMsg. - The contextName, which was returned as part of the ScopedPDU from the call to processIncomingMsg. - The pduVersion, which should indicate an SNMPv1 version PDU (if the message version was SNMPv2c, this would be an SNMPv2 version PDU). Frye, et al. Best Current Practice [Page 28] RFC 3584 Coexistence between SNMP versions August 2003 - The PDU, which was returned as part of the ScopedPDU from the call to processIncomingMsg. - The maxSizeResponseScopedPDU which was returned from the call to processIncomingMsg. - The stateReference which was returned from the call to processIncomingMsg. The SNMP application should process the request as described previously in this document. Note that access control is applied by an SNMPv3 command responder application as usual. The parameters as passed to the processPdu ASI will be used in calls to the isAccessAllowed ASI. 5.2.2. Generating An Outgoing Response There is no special processing required for generating an outgoing response. However, the community string used in an outgoing response must be the same as the community string from the original request. The original community string MUST be present in the securityStateReference information of the original request. 5.2.3. Generating An Outgoing Notification In a multi-lingual SNMP entity, the parameters used for generating notifications will be obtained by examining the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected: - The securityName must be equal to the snmpCommunitySecurityName value. - The contextEngineID must be equal to the snmpCommunityContextEngineID value. - The contextName must be equal to the snmpCommunityContextName value. Frye, et al. Best Current Practice [Page 29] RFC 3584 Coexistence between SNMP versions August 2003 - If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the transportDomain and transportAddress must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value. If no such entry can be found, the notification is not sent. Otherwise, the community string used in the outgoing notification will be the value of the snmpCommunityName column of the selected row. 5.2.4. Proxy Forwarding Of Requests In a proxy forwarding application, when a received request is to be forwarded using the SNMPv1 Message Processing Model, the parameters used for forwarding will be obtained by examining the SNMP-PROXY-MIB and the SNMP-TARGET-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected: - The securityName must be equal to the snmpCommunitySecurityName value. - The contextEngineID must be equal to the snmpCommunityContextEngineID value. - The contextName must be equal to the snmpCommunityContextName value. If no such entry can be found, the proxy forwarding application should follow the procedure described in RFC 3413 [RFC3413], section 3.5.1.1, item (2). This procedure states that the snmpProxyDrops counter [RFC3418] is incremented, and that a Response-PDU is generated by calling the Dispatcher using the returnResponsePdu abstract service interface. 5.3. The SNMP Community MIB Module The SNMP-COMMUNITY-MIB contains objects for mapping between community strings and version-independent SNMP message parameters. In addition, this MIB provides a mechanism for performing source address validation on incoming requests, and for selecting community strings based on target addresses for outgoing notifications. These two Frye, et al. Best Current Practice [Page 30] RFC 3584 Coexistence between SNMP versions August 2003 features are accomplished by providing a tag in the snmpCommunityTable which selects sets of entries in the snmpTargetAddrTable [RFC3413]. In addition, the SNMP-COMMUNITY-MIB augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value. These values are used only where explicitly stated. In cases where the snmpTargetAddrTable is used without mention of these augmenting values, the augmenting values should be ignored. The mask value, snmpTargetAddrTMask, allows selected entries in the snmpTargetAddrTable to specify multiple addresses (rather than just a single address per entry). This would typically be used to specify a subnet in an snmpTargetAddrTable rather than just a single address. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the transport address to match a particular entry in the snmpTargetAddrTable. The value of an instance of snmpTargetAddrTMask must always be an OCTET STRING whose length is either zero or the same as that of the corresponding instance of snmpTargetAddrTAddress. Note that the snmpTargetAddrTMask object is only used where explicitly stated. In particular, it is not used when generating notifications (i.e., when generating notifications, entries in the snmpTargetAddrTable only specify individual addresses). If use of the snmpTargetAddrTMask object is not mentioned in text describing matching addresses in the snmpTargetAddrTable, then its value MUST be ignored. When checking whether a transport address matches an entry in the snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- length OCTET STRING, the mask value is ignored, and the value of snmpTargetAddrTAddress must exactly match a transport address. Otherwise, each bit of each octet in the snmpTargetAddrTMask value corresponds to the same bit of the same octet in the snmpTargetAddrTAddress value. For bits that are set in the snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding bits in the snmpTargetAddrTAddress value must match the bits in a transport address. If all such bits match, the transport address is matched by that snmpTargetAddrTable entry. Otherwise, the transport address is not matched. The maximum message size value, snmpTargetAddrMMS, is used to determine the maximum message size acceptable to another SNMP entity when the value cannot be determined from the protocol. Frye, et al. Best Current Practice [Page 31] RFC 3584 Coexistence between SNMP versions August 2003 SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN IMPORTS IpAddress, MODULE-IDENTITY, OBJECT-TYPE, Integer32, snmpModules FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB SnmpTagValue, snmpTargetAddrEntry FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpCommunityMIB MODULE-IDENTITY LAST-UPDATED "200308060000Z" -- 06 Aug 2003, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3 Co-Chair: Russ Mundy SPARTA, Inc Postal: 7075 Samuel Morse Drive Columbia, MD 21045 USA EMail: mundy@tislabs.com Phone: +1 410-872-1515 Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5005 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614 Co-editor: Rob Frye Vibrant Solutions Frye, et al. Best Current Practice [Page 32] RFC 3584 Coexistence between SNMP versions August 2003 Postal: 2711 Prosperity Ave Fairfax, Virginia 22031 USA E-mail: rfrye@vibrant-1.com Phone: +1-703-270-2000 Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, Tennessee 37918 E-mail: dlevi@nortelnetworks.com Phone: +1 865 686 0432 Co-editor: Shawn A. Routhier Wind River Systems, Inc. Postal: 500 Wind River Way Alameda, CA 94501 E-mail: sar@epilogue.com Phone: +1 510 749 2095 Co-editor: Bert Wijnen Lucent Technologies Postal: Schagen 33 3461 GL Linschoten Netherlands Email: bwijnen@lucent.com Phone: +31-348-407-775 " DESCRIPTION "This MIB module defines objects to help support coexistence between SNMPv1, SNMPv2c, and SNMPv3. Copyright (C) The Internet Society (2003) This version of this MIB module is part of RFC 3584; see the RFC itself for full legal notices." REVISION "200308060000Z" -- 06 Aug 2003 DESCRIPTION "Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation. Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document. Updated the description of `snmpTargetAddrMMS' to Frye, et al. Best Current Practice [Page 33] RFC 3584 Coexistence between SNMP versions August 2003 clarify that a value of 0 means that the maximum message size is unknown. Changed the name of 'snmpCommunityGroup' to snmpCommunityTableGroup to avoid a name conflict with the SNMPv2-MIB. Updated DESCRIPTION of snmpCommunityName. Updated DESCRIPTION of snmpTrapCommunity. Added snmpCommunityMIBFullCompliance. This version published as RFC 3584." REVISION "200003060000Z" -- 6 Mar 2000 DESCRIPTION "This version published as RFC 2576." ::= { snmpModules 18 } -- Administrative assignments ************************************ snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } -- -- The snmpCommunityTable contains a database of community -- strings. This table provides mappings between community -- strings, and the parameters required for View-based Access -- Control. -- snmpCommunityTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of community strings configured in the SNMP engine's Local Configuration Datastore (LCD)." ::= { snmpCommunityMIBObjects 1 } snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current Frye, et al. Best Current Practice [Page 34] RFC 3584 Coexistence between SNMP versions August 2003 DESCRIPTION "Information about a particular community string." INDEX { IMPLIED snmpCommunityIndex } ::= { snmpCommunityTable 1 } SnmpCommunityEntry ::= SEQUENCE { snmpCommunityIndex SnmpAdminString, snmpCommunityName OCTET STRING, snmpCommunitySecurityName SnmpAdminString, snmpCommunityContextEngineID SnmpEngineID, snmpCommunityContextName SnmpAdminString, snmpCommunityTransportTag SnmpTagValue, snmpCommunityStorageType StorageType, snmpCommunityStatus RowStatus } snmpCommunityIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique index value of a row in this table." ::= { snmpCommunityEntry 1 } snmpCommunityName OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The community string for which a row in this table represents a configuration. There is no SIZE constraint specified for this object because RFC 1157 does not impose any explicit limitation on the length of community strings (their size is constrained indirectly by the SNMP message size)." ::= { snmpCommunityEntry 2 } snmpCommunitySecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A human readable string representing the corresponding value of snmpCommunityName in a Security Model independent format." ::= { snmpCommunityEntry 3 } snmpCommunityContextEngineID OBJECT-TYPE Frye, et al. Best Current Practice [Page 35] RFC 3584 Coexistence between SNMP versions August 2003 SYNTAX SnmpEngineID MAX-ACCESS read-create STATUS current DESCRIPTION "The contextEngineID indicating the location of the context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName. The default value is the snmpEngineID of the entity in which this object is instantiated." ::= { snmpCommunityEntry 4 } snmpCommunityContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName." DEFVAL { ''H } -- the empty string ::= { snmpCommunityEntry 5 } snmpCommunityTransportTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints which are used in two ways: - to specify the transport endpoints from which an SNMP entity will accept management requests, and - to specify the transport endpoints to which a notification may be sent using the community string matching the corresponding instance of snmpCommunityName. In either case, if the value of this object has zero-length, transport endpoints are not checked when either authenticating messages containing this community string, nor when generating notifications. The transports identified by this object are specified in the snmpTargetAddrTable. Entries in that table whose snmpTargetAddrTagList contains this tag value are identified. If a management request containing a community string Frye, et al. Best Current Practice [Page 36] RFC 3584 Coexistence between SNMP versions August 2003 that matches the corresponding instance of snmpCommunityName is received on a transport endpoint other than the transport endpoints identified by this object the request is deemed unauthentic. When a notification is to be sent using an entry in this table, if the destination transport endpoint of the notification does not match one of the transport endpoints selected by this object, the notification is not sent." DEFVAL { ''H } -- the empty string ::= { snmpCommunityEntry 6 } snmpCommunityStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the snmpCommunityTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { snmpCommunityEntry 7 } snmpCommunityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the snmpCommunityTable. An entry in this table is not qualified for activation until instances of all corresponding columns have been initialized, either through default values, or through Set operations. The snmpCommunityName and snmpCommunitySecurityName objects must be explicitly set. There is no restriction on setting columns in this table when the value of snmpCommunityStatus is active(1)." ::= { snmpCommunityEntry 8 } -- -- The snmpTargetAddrExtTable -- snmpTargetAddrExtTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry Frye, et al. Best Current Practice [Page 37] RFC 3584 Coexistence between SNMP versions August 2003 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of mask and maximum message size (mms) values associated with the snmpTargetAddrTable. The snmpTargetAddrExtTable augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value. The transport address mask allows entries in the snmpTargetAddrTable to define a set of addresses instead of just a single address. The maximum message size value allows the maximum message size of another SNMP entity to be configured for use in SNMPv1 (and SNMPv2c) transactions, where the message format does not specify a maximum message size." ::= { snmpCommunityMIBObjects 2 } snmpTargetAddrExtEntry OBJECT-TYPE SYNTAX SnmpTargetAddrExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular mask and mms value." AUGMENTS { snmpTargetAddrEntry } ::= { snmpTargetAddrExtTable 1 } SnmpTargetAddrExtEntry ::= SEQUENCE { snmpTargetAddrTMask OCTET STRING, snmpTargetAddrMMS Integer32 } snmpTargetAddrTMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mask value associated with an entry in the snmpTargetAddrTable. The value of this object must have the same length as the corresponding instance of snmpTargetAddrTAddress, or must have length 0. An attempt to set it to any other value will result in an inconsistentValue error. The value of this object allows an entry in the snmpTargetAddrTable to specify multiple addresses. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the Frye, et al. Best Current Practice [Page 38] RFC 3584 Coexistence between SNMP versions August 2003 transport address to match a particular entry in the snmpTargetAddrTable. Bits which are 1 in the mask value indicate bits in the transport address which must match bits in the snmpTargetAddrTAddress value. Bits which are 0 in the mask indicate bits in the transport address which need not match. If the length of the mask is 0, the mask should be treated as if all its bits were 1 and its length were equal to the length of the corresponding value of snmpTargetAddrTable. This object may not be modified while the value of the corresponding instance of snmpTargetAddrRowStatus is active(1). An attempt to set this object in this case will result in an inconsistentValue error." DEFVAL { ''H } ::= { snmpTargetAddrExtEntry 1 } snmpTargetAddrMMS OBJECT-TYPE SYNTAX Integer32 (0|484..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum message size value associated with an entry in the snmpTargetAddrTable. Note that a value of 0 means that the maximum message size is unknown." DEFVAL { 484 } ::= { snmpTargetAddrExtEntry 2 } -- -- The snmpTrapAddress and snmpTrapCommunity objects are included -- in notifications that are forwarded by a proxy, which were -- originally received as SNMPv1 Trap messages. -- snmpTrapAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the agent-addr field of a Trap PDU which is forwarded by a proxy forwarder application using an SNMP version other than SNMPv1. The value of this object SHOULD contain the value of the agent-addr field from the original Trap PDU as generated by an SNMPv1 agent." ::= { snmpCommunityMIBObjects 3 } Frye, et al. Best Current Practice [Page 39] RFC 3584 Coexistence between SNMP versions August 2003 snmpTrapCommunity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the community string field of an SNMPv1 message containing a Trap PDU which is forwarded by a a proxy forwarder application using an SNMP version other than SNMPv1. The value of this object SHOULD contain the value of the community string field from the original SNMPv1 message containing a Trap PDU as generated by an SNMPv1 agent. There is no SIZE constraint specified for this object because RFC 1157 does not impose any explicit limitation on the length of community strings (their size is constrained indirectly by the SNMP message size)." ::= { snmpCommunityMIBObjects 4 } -- Conformance Information ************************************** snmpCommunityMIBCompliances OBJECT IDENTIFIER ::= { snmpCommunityMIBConformance 1 } snmpCommunityMIBGroups OBJECT IDENTIFIER ::= { snmpCommunityMIBConformance 2 } -- Compliance statements snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB." MODULE -- this module MANDATORY-GROUPS { snmpCommunityTableGroup } OBJECT snmpCommunityName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunitySecurityName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityContextEngineID MIN-ACCESS read-only DESCRIPTION "Write access is not required." Frye, et al. Best Current Practice [Page 40] RFC 3584 Coexistence between SNMP versions August 2003 OBJECT snmpCommunityContextName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityTransportTag MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { snmpCommunityMIBCompliances 1 } snmpProxyTrapForwardCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which contain a proxy forwarding application which is capable of forwarding SNMPv1 traps using SNMPv2c or SNMPv3." MODULE -- this module MANDATORY-GROUPS { snmpProxyTrapForwardGroup } ::= { snmpCommunityMIBCompliances 2 } snmpCommunityMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB with full read-create access." MODULE -- this module MANDATORY-GROUPS { snmpCommunityTableGroup } ::= { snmpCommunityMIBCompliances 3 } snmpCommunityTableGroup OBJECT-GROUP OBJECTS { snmpCommunityName, snmpCommunitySecurityName, snmpCommunityContextEngineID, snmpCommunityContextName, snmpCommunityTransportTag, snmpCommunityStorageType, Frye, et al. Best Current Practice [Page 41] RFC 3584 Coexistence between SNMP versions August 2003 snmpCommunityStatus, snmpTargetAddrTMask, snmpTargetAddrMMS } STATUS current DESCRIPTION "A collection of objects providing for configuration of community strings for SNMPv1 (and SNMPv2c) usage." ::= { snmpCommunityMIBGroups 1 } snmpProxyTrapForwardGroup OBJECT-GROUP OBJECTS { snmpTrapAddress, snmpTrapCommunity } STATUS current DESCRIPTION "Objects which are used by proxy forwarding applications when translating traps between SNMP versions. These are used to preserve SNMPv1-specific information when translating to SNMPv2c or SNMPv3." ::= { snmpCommunityMIBGroups 3 } END 6. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Frye, et al. Best Current Practice [Page 42] RFC 3584 Coexistence between SNMP versions August 2003 7. Acknowledgments This document is the result of the efforts of the SNMPv3 Working Group. The design of the SNMP-COMMUNITY-MIB incorporates work done by the authors of SNMPv2*: Jeff Case (SNMP Research, Inc.) David Harrington (Enterasys Networks) David Levi (Nortel Networks) Brian O'Keefe (Hewlett Packard) Jon Saperia (IronBridge Networks, Inc.) Steve Waldbusser (International Network Services) 8. Security Considerations Although SNMPv1 and SNMPv2 do not provide any security, allowing community names to be mapped into securityName/contextName provides the ability to use view-based access control to limit the access of unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for network administrators to make use of this capability in order to avoid unauthorized access to MIB data that would otherwise be secure. When a proxy implementation translates messages between SNMPv1 (or SNMPv2c) and SNMPv3, there may be a loss of security. For example, an SNMPv3 message received using authentication and privacy which is subsequently forwarded using SNMPv1 will lose the security benefits of using authentication and privacy (also known as confidentiality). Careful configuration of proxies is required to address such situations. One approach to deal with such situations might be to use an encrypted tunnel. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - The snmpCommunityTable allows creation and deletion of community strings, which is potentially a serious security hole. Access to this table should be greatly restricted, preferably by only allowing write access using SNMPv3 VACM and USM, with authentication and privacy. - The snmpTargetAddrExtTable contains write-able objects which may also be considered sensitive, and so access to it should be restricted as well. Frye, et al. Best Current Practice [Page 43] RFC 3584 Coexistence between SNMP versions August 2003 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: - The snmpCommunityTable has the potential to expose community strings which provide access to more information than that which is available using the usual 'public' community string. For this reason, a security administrator may wish to limit accessibility to objects in the snmpCommunityTable, and in particular, to make it inaccessible when using the 'public' community string. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. References 9.1. Normative References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, Eds., "Concise MIB Definitions", STD 16, RFC 1212, March 1991. Frye, et al. Best Current Practice [Page 44] RFC 3584 Coexistence between SNMP versions August 2003 [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1303] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-based Agents", RFC 1303, February 1992. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Frye, et al. Best Current Practice [Page 45] RFC 3584 Coexistence between SNMP versions August 2003 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3416, December 2002. [RFC3417] Presuhn, R., Ed., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002. [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for Version 2 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). 9.2. Informative References [RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [RFC2089] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a bilingual SNMP agent", RFC 2089, January 1997. [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", RFC 2576, March 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Frye, et al. Best Current Practice [Page 46] RFC 3584 Coexistence between SNMP versions August 2003 Appendix A. Change Log A.1. Changes From RFC 2576 Section numbers below refer to the old section numbers from RFC 2576. Some section numbers have changed since RFC 2576. - Added text to abstract about conversion of MIBs from SMIv1 to SMIv2. - Added note at end of section 1.3 that all discussion of SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3. - Added text at end of section 1.4 to clarify that there is no such thing as 'SNMPv3 access to MIB data', as SNMPv3 just uses SNMPv2 PDU types and protocol operations. - Moved section 1.4 to the beginning of section 4. - Changed "MUST" to "SHOULD" in item (3) of the first list in Section 2.1.1 to since unconstrained INTEGER is not actually illegal in SMIv2. - Changed "SHOULD" to "MUST" in item (13) of the first list in Section 2.1.1 to clarify that collecting related objects into groups is required when translating a MIB module from SMIv1 to SMIv2. - Re-organized bullets in section 2.1.1 to improve clarity. - Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3 since those updates are indeed required when translating a capabilities statement from the language defined by RFC 1303 into SMIv2. - In the second bullet of the last part of Section 3 listing the SNMPv2 notification parameters, clarified that the snmpTrapOID parameter refers to the value portion (not the name portion) of the second variable-binding, and changed the wording in the text under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the snmpTrapOID value" to emphasize this point. - In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable- bindings do not include sysUpTime.0 an snmpTrapOID.0. - In Section 4.2 clarified that the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the Frye, et al. Best Current Practice [Page 47] RFC 3584 Coexistence between SNMP versions August 2003 version used between the proxy and the command responder or notification originator. RFC 2576 neglected to mention the notification receiver and notification originator. - In Section 4.1.2 added text noting that SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and re-worded final paragraph to note that the sub-sections that follow are concerned solely with command responders that use SNMPv2 access to MIB data while processing an SNMPv1 request. - Re-worded first bullet, section 4.2.1, to make it more readable. - In Section 4.2.1 clarified that the error-index field must be set to zero in a translated GetResponse-PDU with an error-status of 'tooBig' and made explicit the rationale for retrying a GetBulkRequest-PDU only once. - Added text to the Deployment Hint in Section 4.2.2 to clarify that different principals should be used for SNMPv1 requests and SNMPv2/v3c requests if for SNMPv1 requests a principal for which Counter64 objects are not-in-view is used. - In Section 5.2.1 clarified that the securityName value and the scopedPDU's contextSnmpEngineID and contextName values come from the selected entry in the snmpCommunityTable. Also clarified how maxSizeResponseScopedPDU is determined and that securityStateReference must contain the community string of the original request. - Added Section 5.2.4 on Proxy Forwarding Of Requests. - In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored whenever its use is not explicitly called for. - Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation. - Added text to DESCRIPTION of snmpCommunityName and snmpTrapCommunity to clarify why the object has no size restriction. - Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document. - Updated the description of 'snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown. Frye, et al. Best Current Practice [Page 48] RFC 3584 Coexistence between SNMP versions August 2003 - Changed the name of 'snmpCommunityGroup' to 'snmpCommunityTableGroup' in order to resolve a name conflict with the SNMPv2-MIB. - Added compliance statement to SNMP-COMMUNITY-MIB for full read- create compliance. - Divided references into Normative References and Informative Reference and updated them to point to current documents. - Inserted current year into all copyright notices. - Corrected various typographical and grammatical errors. A.2. Changes Between RFC 1908 and RFC 2576 - Editorial changes to comply with current RFC requirements. - Added/updated copyright statements. - Added Intellectual Property section. - Replaced old introduction with complete new introduction/overview. - Added content for the Security Considerations Section. - Updated References to current documents. - Updated text to use current SNMP terminology. - Added coexistence for/with SNMPv3. - Added description for SNMPv1 and SNMPv2c Message Processing Models and SNMPv1 and SNMPv2c Community-based Security Models. - Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community strings can be mapped into the SNMP Version Independent parameters which can then be used for access control using the standard SNMPv3 View-based Access Control Model and the snmpVacmMIB. - Added two MIB objects such that when an SNMPv1 notification (trap) must be converted into an SNMPv2 notification we add those two objects in order to preserve information about the address and community of the originating SNMPv1 agent. - Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 mapping within a multi-lingual SNMP Engine. Frye, et al. Best Current Practice [Page 49] RFC 3584 Coexistence between SNMP versions August 2003 - Use keywords from RFC 2119 to describe requirements for compliance. - Changed/added some rules for converting a MIB module from SMIv1 to SMIv2. - Extended and improved the description of Proxy Forwarder behaviour when multiple SNMP versions are involved. Editors' Addresses Rob Frye Vibrant Solutions 2711 Prosperity Ave Fairfax, Virginia 22031 U.S.A. Phone: +1 703 270 2000 EMail: rfrye@vibrant-1.com David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A. Phone: +1 865 686 0432 EMail: dlevi@nortelnetworks.com Shawn A. Routhier Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501 U.S.A. Phone: + 1 510 749 2095 EMail: sar@epilogue.com Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Phone: +31 348 407 775 EMail: bwijnen@lucent.com Frye, et al. Best Current Practice [Page 50] RFC 3584 Coexistence between SNMP versions August 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Frye, et al. Best Current Practice [Page 51] snmp-mibs-downloader-1.1/mibrfcs/rfc3591.txt0000644000000000000000000113703711402176071015577 0ustar Network Working Group H-K. Lam Request for Comments: 3591 Lucent Technologies Category: Standards Track M. Stewart Dorado Software A. Huynh Cetus Networks September 2003 Definitions of Managed Objects for the Optical Interface Type 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP- based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. Lam, et al. Standards Track [Page 1] RFC 3591 Optical Interface Type MIB September 2003 Table of Contents 1. The Internet-Standard Management Framework ................. 2 2. Overview ................................................... 3 2.1. Use of the ifTable .................................. 3 2.2. Use of ifTable for OTN OTS/OMS Layer................. 8 2.3. Use of ifTable for OTN OChGroup Layer................ 9 2.4. Use of ifTable for OTN OCh Layer..................... 10 2.5. Use of ifStackTable.................................. 12 2.6. Optical Network Terminology ......................... 13 2.7. Tandem Connection Monitoring (TCM) .................. 20 3. Structure of the MIB........................................ 21 3.1. The optIfOTMn group.................................. 23 3.2. The optIfPerfMon group............................... 24 3.3. The optIfOTSn groups................................. 24 3.4. The optIfOMSn groups................................. 25 3.5. The optIfOChGroup groups............................. 26 3.6. The optIfOCh groups.................................. 27 3.7. The optIfOTUk groups................................. 28 3.8. The optIfODUk groups................................. 29 3.9. The optIfODUkT groups................................ 30 4. Object Definitions ......................................... 30 5. Security Considerations .................................... 167 6. Acknowledgments............................................. 169 7. References ................................................. 169 7.1. Normative References ................................. 169 7.2. Informative References ............................... 171 8. Intellectual Property Statement ............................ 171 9. Authors' Addresses ......................................... 172 10. Full Copyright Statement ................................... 173 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Lam, et al. Standards Track [Page 2] RFC 3591 Optical Interface Type MIB September 2003 2. Overview In this document, the term OTN (Optical Transport Network) system is used to describe devices that are compliant with the requirements specified in the ITU-T Recommendations G.872 [ITU-T G.872], G.709 [ITU-T G.709], G.798 [ITU-T G.798], G.874 [ITU-T G.874], and G.874.1 [ITU-T G.874.1]. The optical objects will be managed using the MIB II ifTable and ifStackTable. Additional tables will also be supported to monitor layer specific status and provide performance monitoring data. In the tables, some entries are required for OTN systems only. A Configuration (Config) table, Current Performance Monitoring (PM) table, and Interval PM table will be maintained for the OTSn, OMSn, OChGroup, and OCh layers on a source and sink trail termination basis. These tables will be linked to the ifTable by using the ifIndex that is associated with that layer. These objects are used when the particular media being used to realize an interface is an Optical Transport interface. At present, this applies to these values of the ifType variable in the Internet- standard MIB: opticalChannel (195), opticalChannelGroup (219), opticalTransport (196) The definitions contained herein are based on the OTN specifications in ITU-T G.872[ITU-T G.872], G.709 [ITU-T G.709], G.798[ITU-T G.798], G.874[ITU-T G.874], and G.874.1 [ITU-T G.874.1]. 2.1. Use of the ifTable This section specifies how the MIB II interfaces group, as defined in RFC 2863 [RFC2863], is used for optical interfaces. Only the ifGeneralInformationGroup will be supported for the ifTable and the ifStackTable to maintain the relationship between the various layers. The OTN layers are managed in the ifTable using IfEntries that correlate to the layers depicted in Figure 1. For example, a DWDM device with an Optical Network Node Interface (ONNI) will have an Optical Transmission Section (OTS) physical layer, an Optical Multiplex Section (OMS) layer (transports multiple optical channels), and an Optical Channel (OCh) layer. There is a one to one relationship between the OMS and OTS layers. The OMS layer has fixed connectivity via the OTS and thus no connectivity flexibility at the OMS layer is supported. Lam, et al. Standards Track [Page 3] RFC 3591 Optical Interface Type MIB September 2003 A device with an ONNI that does not multiplex would consist of the OTS and OCh layers supporting a single channel. MIB-II (RFC 1213) [RFC1213], as amended and extended by RFC 3418 [RFC3418], RFC 2863 [RFC2863], and RFC 2864 [RFC2864], accommodates these cases through appropriate use of the system and interfaces groups. The system group names and describes the type of managed resource. The interfaces group defines which OTN layers exist and how these layers are configured and multiplexed. This is achieved by proper representation of OTN Layers as IfEntries as defined in RFC 2863 [RFC2863], as follows. In the following figures, opticalChannel and opticalTransport are abbreviated as och and otn respectively. _____________________ \ Path Data Unit |\ (ODUk) | \ _____________________| \ ______________________ | | | > Tandem Data Unit | | | | (ODUkT) | | OCh Layer | > n och IfEntries _____________________| | | | | |______________________| > Optical | /| | > Transport Unit | / | | | (OTUk) |/ | OMSn Layer | | _____________________/ | | | |______________________| | Sub-layers in | | > m otn IfEntries the OCh Layer | | | | OTSn Layer | | | | | |______________________| > Figure 1: OTN Layers Since the OMSn and OTSn layers have a one to one relationship, only one otn IfEntry is required to support these two layers. Therefore, each opticalChannel IfEntry may be mapped to m opticalTransport IfEntries, where m is greater than or equal to 1. Conversely, each opticalTransport entry may be mapped to n opticalChannel IfEntries, where n is greater than or equal to 1. There are implementations that have banded amplifers that operate on a group of optical channels separately (e.g., C and L band channels) before finally muxing them together and transporting them over a Lam, et al. Standards Track [Page 4] RFC 3591 Optical Interface Type MIB September 2003 physical layer. For such DWDM system implementations, it is important to have the ability to model each of the groups (or bands) with an ifIndex and measure the pre-OTN PM parameters for each band separately. The OTN layering, as described in Figure 1, can be extended to accomodate such implementations by introducing another layer called the OChGroup Layer. As an example, Figure 2 depicts the OTN layering of a DWDM system with 80 C-band and 80 L-band channels combined into their respective channel band groups before being muxed into the OMS and transported over the OTS. _________ ____________ |O|O| |O | |O |O | |O | > |C|C| |C | |C |C | |C | | |h|h|..|h | |h |h |..|h | > x och IfEntries |1|2| |80| |81|82| |160| | |_|_|__|__| |__|__|__|___| > | | | | > | | | | | |OChGroup1| | OChGroup2 | > n ochgroup IfEntries | | | | | |_________|__|____________| > | | > | | | | OMSn Layer | | | | | |_________________________| | | | > m otn IfEntries | | | | OTSn Layer | | | | | |_________________________| > Figure 2: OTN Layers for a Banded Configuration If an implementation does not wish to model the banded configuration, the OChGroup layer is absent and the OTN layering model degenerates to the description in Figure 1. In other words, when there is an amplifier that covers the whole band, the optIfOMSn objects should be used, rather than using the optIfOChGroup objects with a degenerate group that covers all channels. The design of the Optical Interface MIB provides the option to model an interface either as a single bidirectional object containing both sink and source functions or as a pair of unidirectional objects, one containing sink functions and the other containing source functions. Lam, et al. Standards Track [Page 5] RFC 3591 Optical Interface Type MIB September 2003 If the sink and source for a given protocol layer are to be modelled as separate objects, then there need to be two ifTable entries, one that corresponds to the sink and one that corresponds to the source, where the directionality information is provided in the configuration tables for that layer via the xxxDirectionality objects. The agent is expected to maintain consistent directionality values between ifStackTable layers (e.g., a sink must not be stacked in a 1:1 manner on top of a source, or vice-versa), and all protocol layers that are represented by a given ifTable entry are expected to have the same directionality (i.e., instances of optIfOTSnDirectionality and optIfOMSnDirectionality that correspond to a given ifIndex value must have the same value, and instances of optIfOChDirectionality, optIfOTUkDirectionality, and optIfODUkDirectionality that correspond to a given ifIndex value must have the same value). When separate ifTable entries are used for the source and sink functions of a given physical interface, association between the two uni-directional ifTable entries (one for the source function and the other for the sink functions) should be provided. It is recommended that identical ifName values are used for the two ifTable entries to indicate such association. An implementation shall explicitly state what mechanism is used to indicate the association, if ifName is not used. Example 1: Management of unterminated opticalChannel (och) using passive optics An OTN device connected with two adjacent nodes in a single fiber ring that supports 10 wavelengths per fiber would have 2 opticalTransport IfEntries and 20 opticalChannel IfEntries, as depicted in Figure 3. Thus 10 opticalChannel IfEntries are stacked above the first opticalTransport IfEntry, and the other 10 opticalChannel IfEntries are stacked above the second opticalTransport IfEntry. Note that the optical channels in this example are un-terminated, and thus no OTUk objects will be instantiated for these optical channels. The opticalChannel IfEntries of one otn may be dropped/added from/to the OTN device or cross-connected with the opticalChannel IfEntries of the other otn. Cross-connection from a member of the first 10 opticalChannel IfEntries to a member of the second 10 opticalChannel IfEntries could be modelled by using a cross- connect object, which is not yet defined in this version of the MIB. Lam, et al. Standards Track [Page 6] RFC 3591 Optical Interface Type MIB September 2003 ______________________ ______________________ | | | | | | | | | och1 | ... | och10 | | och11 | ... | och20 | |_______|______|_______| |_______|______|_______| | | | | | otn1 | | otn2 | |______________________| |______________________| ____________ | | ___________________\| OTN |__________________\ /| device | / |____________| Figure 3: Interface stacks when channels are unterminated Example 2: Management of terminated opticalChannel (och) interfaces An OTN device connected with two adjacent nodes in a single fiber ring that supports 10 wavelengths per fiber would have 2 opticalTransport IfEntries and 20 opticalChannel IfEntries, as depicted in Figure 4. Thus 10 opticalChannel IfEntries are stacked above the first opticalTransport IfEntry, and the other 10 opticalChannel IfEntries are stacked above the second opticalTransport IfEntry. As the optical channels in this example are terminated, OTUk objects and possibly ODUk objects will be instantiated for the terminated opticalChannel IfEntries. ______________________ ______________________ | | | | | | | | | och1 | ... | och10 | | och11 | ... | och20 | |_______|______|_______| |_______|______|_______| | | | | | otn1 | | otn2 | |______________________| |______________________| ____________ | | ___________________\| OTN |__________________\ /| device | / |____________| Figure 4: Interface stacks when channels are terminated Note that the two examples described above depict the interface stacks when the banded configuration is not modeled. Lam, et al. Standards Track [Page 7] RFC 3591 Optical Interface Type MIB September 2003 The exact configuration and multiplexing of the layers is maintained in the ifStackTable (RFC 2863) [RFC2863] and in the ifInvStackTable (RFC 2864) [RFC2864]; see section 2.5 for details. 2.2. Use of ifTable for OTN OTS/OMS Layer Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for combined OTN OTS/OMS Layer ===================================================================== ifIndex The interface index. ifDescr Optical Transport Network (OTN) Optical Transmission Section (OTS)/Optical Multiplex Section (OMS) ifType opticalTransport (196) ifSpeed Actual bandwidth of the interface in bits per second. If the bandwidth of the interface is greater than the maximum value of 4,294,967,295, then the maximum value is reported and ifHighSpeed must be used to report the interface's speed. ifPhysAddress An octet string with zero length. (There is no specific address associated with the interface.) ifAdminStatus The desired administrative status of the interface. Supports read-only access. ifOperStatus The operational status of the interface. The value lowerLayerDown(7) is not used, since there is no lower layer interface. This object is set to notPresent(6) if a component is missing, otherwise it is set to down(2) if either of the objects optIfOTSnCurrentStatus or optIfOMSnCurrentStatus indicates that any defect is present. ifLastChange The value of sysUpTime at the last change in ifOperStatus. Lam, et al. Standards Track [Page 8] RFC 3591 Optical Interface Type MIB September 2003 ifName Enterprise-specific convention (e.g., TL-1 AID) to identify the physical or data entity associated with this interface or an OCTET STRING of zero length. The enterprise-specific convention is intended to provide the means to reference one or more enterprise-specific tables. ifLinkUpDownTrapEnable Default value is enabled(1). Supports read-only access. ifHighSpeed Actual bandwidth of the interface in Mega-bits per second. A value of n represents a range of 'n-0.5' to 'n+0.499999'. ifConnectorPresent Set to true(1). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. 2.3. Use of ifTable for OTN OChGroup Layer Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for OTN OChGroup Layer ===================================================================== ifIndex The interface index. ifDescr Optical Transport Network (OTN) Optical Channel Group (OChGroup) ifType opticalChannelGroup(219) ifSpeed Current bandwidth of the interface in bits per second. If the bandwidth of the interface is greater than the maximum value of 4,294,967,295, then the maximum value is reported and ifHighSpeed must be used to report the interface's speed. ifPhysAddress A string that specifies the range of wavelengths in the format of w1-w2, where w1 and w2 are the lower and upper end of the wavelength range, both in ASCII decimal digits expressed in nanometers (e.g., 1350-1650) Lam, et al. Standards Track [Page 9] RFC 3591 Optical Interface Type MIB September 2003 ifAdminStatus The desired administrative status of the interface. Supports read-only access. ifOperStatus The operational status of the interface. This object is set to lowerLayerDown(7) if the ifOperStatus of its otn interface is down(2). Otherwise, it is set to down(2) if the amplifier for this band is unable to carry traffic. ifLastChange The value of sysUpTime at the last change in ifOperStatus. ifName Enterprise-specific convention (e.g., TL-1 AID) to identify the physical or data entity associated with this interface or an OCTET STRING of zero length. The enterprise-specific convention is intended to provide the means to reference one or more enterprise-specific tables. ifLinkUpDownTrapEnable Default value is disabled(2). Supports read-only access. ifHighSpeed Current bandwidth of the interface in Mega-bits per second. A value of n represents a range of 'n-0.5' to 'n+0.499999'. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. 2.4. Use of ifTable for OTN OCh Layer Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for OTN OCh Layer ===================================================================== ifIndex The interface index. ifDescr Optical Transport Network (OTN) Optical Channel (OCh) ifType opticalChannel(195) Lam, et al. Standards Track [Page 10] RFC 3591 Optical Interface Type MIB September 2003 ifSpeed Current bandwidth of the interface in bits per second. If the bandwidth of the interface is greater than the maximum value of 4,294,967,295, then the maximum value is reported and ifHighSpeed must be used to report the interface's speed. ifPhysAddress A string of ASCII decimal digits containing the wavelength of the optical channel, expressed in nanometers (e.g., 1550). ifAdminStatus The desired administrative status of the interface. Supports read-only access. ifOperStatus The operational status of the interface. This object is set to lowerLayerDown(7) if the ifOperStatus of its otn interface or of its OChGroup interface is down(2). Otherwise, it is set to down(2) if one or more of the objects optIfOChCurrentStatus, optIfOTUkCurrentStatus, optIfODUkTCurrentStatus, and optIfODUkTtpCurrentStatus indicates that any defect is present. ifLastChange The value of sysUpTime at the last change in ifOperStatus. ifName Enterprise-specific convention (e.g., TL-1 AID) to identify the physical or data entity associated with this interface or an OCTET STRING of zero length. The enterprise-specific convention is intended to provide the means to reference one or more enterprise-specific tables. ifLinkUpDownTrapEnable Default value is disabled(2). Supports read-only access. ifHighSpeed Current bandwidth of the interface in Mega-bits per second. A value of n represents a range of 'n-0.5' to 'n+0.499999'. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. Lam, et al. Standards Track [Page 11] RFC 3591 Optical Interface Type MIB September 2003 2.5. Use of ifStackTable Use of the ifStackTable and ifInvStackTable to associate the opticalTransport and opticalChannel interface entries is best illustrated by the example shown in Figure 5. The example assumes an otn interface with ifIndex i that carries two multiplexed och interfaces with ifIndex values of j and k, respectively. The example shows that j and k are stacked above (i.e., multiplexed into) i. Furthermore, it shows that there is no layer lower than i and no layer higher than j and/or k. HigherLayer LowerLayer -------------------------- 0 j 0 k j i k i i 0 Figure 5: Use of ifStackTable for an OTN port Figure 6 illustrates an example for a banded configuration. The example assumes an otn interface with ifIndex i that carries two multiplexed och groups with ifIndex values u and v. An och group with ifIndex value u combines two och interfaces with ifIndex values of a and b. An och group with ifIndex value v combines two och interfaces with ifIndex values of c and d. The example show that a and b are stacked above (i.e., multiplexed into) u. Likewise, c and d are stacked above v. u and v are multiplexed into i. Furthermore, it shows that there is no layer lower than i and no layer higher than a, b, c, and/or d. It also shows that u has a and b as its higher layers, and v has c and d as its higher layers. HigherLayer LowerLayer -------------------------- 0 a 0 b 0 c 0 d a u b u c v d v u i v i i 0 Figure 6: Use of ifStackTable for an OTN port for a banded configuration Lam, et al. Standards Track [Page 12] RFC 3591 Optical Interface Type MIB September 2003 For the inverse stack table, it provides the same information as the interface stack table, with the order of the Higher and Lower layer interfaces reversed. 2.6. Optical Network Terminology The terminology used in this document to describe the layers of an optical network and the error conditions and performance monitoring parameters on an optical circuit as monitored by an optical system is listed below. These terms are defined in ITU-T Recommendations G.872 [ITU-T G.872], G.709 [ITU-T G.709], G.798 [ITU-T G.798], G.874 [ITU-T G.874], G.874.1 [ITU-T G.874.1], and G.806 [ITU-T G.806]. Brief definitions of some terms are also included here to facilitate the readability of this document. Degraded Threshold (DEGTHR) - G.806 A threshold level for declaring a performance monitoring (PM) Second (a time period of one second) to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second or the number of errored blocks in that Second is greater than or equal to DEGTHR. DEGM - G.806 A threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if DEGM consecutive bad PM Seconds are detected. Expected Destination Access Point Identifier (ExDAPI) - G.798 The Expected Destination Access Point Identifier (ExDAPI), provisioned by the managing system, to be compared with the TTI accepted at the overhead position of the sink for the purpose of checking the integrity of connectivity. Expected Source Access Point Identifier (ExSAPI) - G.798 The Expected Source Access Point Identifier (ExSAPI), provisioned by the managing system, to be compared with the TTI accepted at the overhead position of the sink for the purpose of checking the integrity of connectivity. Inter-Domain Interface (IrDI) - G.872 A physical interface that represents the boundary between two administrative domains. G.709 defines the requirements for the IrDI at the Network Node Interface (NNI). Intra-Domain Interface (IaDI) - G.872 A physical interface within an administrative domain. Lam, et al. Standards Track [Page 13] RFC 3591 Optical Interface Type MIB September 2003 Optical Channel Layer Network (OCh) - G.872 This layer network provides end-to-end networking of optical channels for transparently conveying client information of varying format (e.g., SDH STM-N, PDH 565 Mbit/s, cell based ATM, etc.). Optical Channel Data Unit Path Layer Network (ODUk) - G.709/Y.1331 This layer network provides functionality for the transport of information structure consisting of the information payload (OPUk) and the related overhead for management of an optical channel. Optical Channel Data Unit Tandem Connection Sub-Layer Network (ODUkT) - G.709/Y.1331 This layer network is a sub-layer of the optical data unit layer, which provides the capability for tandem connection monitoring. One to six nested levels of monitoring are defined for OTN. Optical Channel Payload Unit (OPUk) - G.709/Y.1331 The OPUk is the information structure used to adapt client information for transport over an optical channel. OPUk capacities for k=1, k=2, k=3 are defined in ITU-T. The index "k" is used to represent different versions of OPUk, ODUk and OTUk. k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, and k=3 represents an approximate bit rate of 40 Gbit/s. Optical Multiplex Section Layer Network (OMS) - G.872 This layer network provides functionality for networking of a multi-wavelength optical signal. Note that a "multi- wavelength" signal includes the case of just one optical channel. Optical Transport Module (OTM-n[r].m) - G.872 The OTM is the information structure that is transported across an ONNI. The index n and m define the number of supported wavelengths and bit rates at the interface. Two OTM structures are defined: OTM with full functionality (OTM-n.m) and OTM with reduced functionality (OTM-0.m & OTM- nr.m). The OTM-n.m consists of up to n multiplexed optical channels and an OTM overhead signal to support the non-associated overhead. The OTM-0 consists of a single optical channel Lam, et al. Standards Track [Page 14] RFC 3591 Optical Interface Type MIB September 2003 without a specific color assigned. The OTM-nr.m consists of up to n multiplexed optical channels. Non associated overhead is not supported. Optical Transport Network (OTN) - G.872 A transport network bounded by optical channel access points. The optical transport network layered structure is comprised of the optical channel, optical multiplex section and optical transmission section layer networks. According to G.872, an OTN-compliant interface is an interface of the optical transport network based on the architecture defined in G.872, while an OTN-non-compliant interface is an interface that does not comply with the interface recommendations that will be defined for the optical transport network based on the architecture defined in G.872. Optical Transmission Section Layer Network (OTS) - G.872 This layer network provides functionality for transmission of optical signals on optical media of various types. Optical Channel Transport Unit Section Layer Network (OTUk) - G.709 The OTUk is the layer network that provides for the transport of an ODUk over one or more optical channel link connections. It consists of the optical channel data unit and OTUk related overhead (FEC and overhead for management of an optical channel link connection). It is characterized by its frame structure, bit rate, and bandwidth. Payload Type Mismatch (PLM) The detection of a mismatch of payload type is based on a comparison between the expected Payload Type signal, provisioned via the management interface, and the received Payload Type signal. Trail Trace Identifier Transmitted (TxTI) - G.798 The Trail Trace Identifier (TTI) information, provisioned by the managing system, to be placed in the TTI overhead position of the source of a trail for transmission. Trail Trace Identifier Accepted (AcTI) - G.798 The Trail Trace Identifier (TTI) information accepted from the TTI overhead position at the sink of a trail. Trail Trace Identifier Accepted Status (AcTIStatus) - G.798 The Status of the Trail Trace Identifier (TTI) accepted from the TTI overhead position at the sink of a trail. Lam, et al. Standards Track [Page 15] RFC 3591 Optical Interface Type MIB September 2003 Trace Identifier Mismatch (TIM) - G.798 The detection of TIM is based on a comparison between the expected Trial Trace Identifier (TTI), configured via the management interface, and the received TTI. Trace Identifier Mismatch Consequent Action Enabled (TimActEnabled) - G.798 The Consequent Action function of TIM is disabled. Trace Identifier Mismatch Detection Mode (TimDetMode) - G.798 The mode of detecting Trace Identifier Mismatch (TIM). Possible modes are: (1) off - no checking, (2) SAPI - checking the SAPI only, (3) DAPI - checking the DAPI only, and (4) Both - checking both the SAPI and DAPI. 2.6.1. Defect Conditions The following Defect conditions are defined in G.798 (as fault cause) for OTN monitoring. ais Alarm Indication Signal (AIS) bdi Backward Defect Indication (BDI) bdiO Backward Defect Indication - Overhead (BDI-O) bdiP Backward Defect Indication - Payload (BDI-P) deg Degraded (DEG) lck Locked (LCK) lof Loss of Frame (LOF) lom Loss of Multi Frame los Loss of Signal (LOS) losO Loss of Signal - Overhead (LOS-O) losP Loss of Signal - Payload (LOS-P) oci Open Connection Indication (OCI) plm Payload Mismatch (PLM) ssf Server Signal Failure (SSF) ssfO Server Signal Failure - Overhead (SSF-O) ssfP Server Signal Failure - Payload (SSF-P) tim Trace Identifier Mismatch (TIM) The relationship of these conditions within a network layer and between layers are described in G.798 [ITU-T G.798]. Lam, et al. Standards Track [Page 16] RFC 3591 Optical Interface Type MIB September 2003 2.6.2. Performance Parameters To facilitate identification of equipment and facilities that may require maintenance, it is necessary to monitor parameters such as optical power at each layer. The measurements are taken periodically, and a snapshot of the current value is also made available. More specifically, performance parameters at each layer are maintained for the current 15-minute interval, the current 24- hour interval, N previous 15-minute intervals where 4 <= N <= 96, and one previous 24-hour interval. Note that some of the previous interval data will be unavailable if the agent has restarted within the last 24 hours. There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute or 24-hour interval and any wall clock; however, some agents may align the 15-minute intervals with quarter hours and may align the 24-hour intervals with a particular hour of the day (e.g., 00:00 UTC). Note that some DWDM systems may also monitor the laser temperature of the equipment in addition to monitoring the optical power. However, industry opinions vary widely with respect to laser temperature monitoring, in particular regarding the benefit of the monitoring and which temperatures are to be monitored (i.e., all or only some of the pump lasers). Similarly, there are varying opinions regarding mid- stage power monitoring. Since no consensus was reached, it was decided that the laser temperature monitoring and mid-stage monitoring would not be standardized in the MIB. If an implementation would like to monitor these parameters, one could use a proprietary MIB or the ENTITY-SENSOR-MIB [RFC3433] to capture this information. Lam, et al. Standards Track [Page 17] RFC 3591 Optical Interface Type MIB September 2003 The sink-side monitoring points for the various layers are shown in Figure 7 below. OCh sink pre-OTN PM params | | OChGroup sink pre-OTN params | | | | OMSn sink pre-OTN PM params | | | | | | OTSn sink pre-OTN PM params | | | | V V V V /| ____/|_______/| /| / | \| . / |__________________/ |________________/ |_____ . \ | ____\ | \ | ____/|_______\| | \| ___\ | \| C-Band | Demux | \| | | | | ____/|_______/| | OSC \| . / |_____________| . \ | ____/|_______\| \| L-Band optical optical optical OSC Drop Filter rcvr (O/E) demux demux OCh OChGroup OMSn OTSn Figure 7: Sink-side pre-OTN monitoring points Lam, et al. Standards Track [Page 18] RFC 3591 Optical Interface Type MIB September 2003 The source-side monitoring points for the various layers are shown in Figure 8 below. OCh src pre-OTN PM params | | OChGroup src pre-OTN PM params | | | | OMSn src pre-OTN PM params | | | | | | OTSn src pre-OTN PM params | | | | V V V V |\ ___|\______|\ |\ | \ |/ . | \_________________| \______________| \______ . | / ___| / | / ----|/ | |/ __| / C-Band MUX | Mux | |/ | | | OSC ___|\______|\ | |/ . | \_____________| . | / ----|/ L-Band MUX optical optical optical OSC Add Filter xmtr mux mux (E/O) OCh OChGroup OMSn OTSn Figure 8: Source-side pre-OTN monitoring points Note that optical performance parameters are of type Integer32, rather than Counter32 or Gauge32, because it is possible for these objects to increase or decrease and to assume negative or positive values. Lam, et al. Standards Track [Page 19] RFC 3591 Optical Interface Type MIB September 2003 2.7. Tandem Connection Monitoring (TCM) An ODUk termination can be provisioned to support (0..6) TCM levels. Each TCM field contains the following subfields: - Trail Trace Identifier (TTI) - Bit Interleaved Parity 8 (BIP8) - Backward Defect Indication (BDI) - Backward Error Indication (BEI) - Status bits indicating the presence of TCM overhead, Incoming AlignmentError, or a maintenance signal (STAT). The insertion of these subfields is controlled by: - optIfODUkTSourceMode or otnODUkTsinkMode The detection and corresponding action of these subfields are controlled by: - optIfODUkTTimDetMode - optIfODUkTTimActEnabled The TCM connection is used for monitoring the quality of an end to end connection or any segment, as illustrated in the example: TCM1 used for the end-to-end connection from A1 to A2. TCM2 used for segment B1-B2, then used again for segment B3-B4. TCM3-TCM6 these bytes are not in used in this example. Lam, et al. Standards Track [Page 20] RFC 3591 Optical Interface Type MIB September 2003 The TCM connection can be nested (B1-B2 is nested in A1-A2) or cascaded (B1-B2 and B3-B4). ______ ______ ______ ______ ______ |TCM6| |TCM6| |TCM6| |TCM6| |TCM6| |----| |----| |----| |----| |----| |TCM5| |TCM5| |TCM5| |TCM5| |TCM5| |----| |----| |----| |----| |----| |TCM4| |TCM4| |TCM4| |TCM4| |TCM4| |----| |----| |----| |----| |----| |TCM3| |TCM3| |TCM3| |TCM3| |TCM3| |----| |----| |----| |----| |----| |TCM2| |TCM2| |TCM2| |TCM2| |TCM2| |----| |----| |----| |----| |----| |TCM1| |TCM1| |TCM1| |TCM1| |TCM1| |----| |----| |----| |----| |----| | | | | | | | | | | | | | | | | | | | | | | | | | |\ |\ /| |\ /| /| ----> | \________| \_______/ |_________| \_____ / |______ / | ----> | / | / \ | | / \ | \ | |/ |/ \| |/ \| \| TCM1: A1 <------------------------------------------------> A2 TCM2: B1 <-----> B2 B3 <-----> B4 3. Structure of the MIB The managed Optical Networking interface objects are arranged into the following groups of tables: The optIfOTMn group handles the OTM information structure of an optical interface. optIfOTMnTable The optIfPerfMon group handles the current 15-minute and 24-hour interval elapsed time, as well as the number of 15-minute intervals for all layers. optIfPerfMonIntervalTable Lam, et al. Standards Track [Page 21] RFC 3591 Optical Interface Type MIB September 2003 The optIfOTSn groups handle the configuration and performance monitoring information for OTS layers. optIfOTSnConfigTable optIfOTSnSinkCurrentTable optIfOTSnSinkIntervalTable optIfOTSnSinkCurDayTable optIfOTSnSinkPrevDayTable optIfOTSnSrcCurrentTable optIfOTSnSrcIntervalTable optIfOTSnSrcCurDayTable optIfOTSnSrcPrevDayTable The optIfOMSn groups handle the configuration and performance information for OMS layers. optIfOMSnConfigTable optIfOMSnSinkCurrentTable optIfOMSnSinkIntervalTable optIfOMSnSinkCurDayTable optIfOMSnSinkPrevDayTable optIfOMSnSrcCurrentTable optIfOMSnSrcIntervalTable optIfOMSnSrcCurDayTable optIfOMSnSrcPrevDayTable The optIfOChGroup groups handle the configuration and performance information for OChGroup layers. optIfOChGroupConfigTable optIfOChGroupSinkCurrentTable optIfOChGroupSinkIntervalTable optIfOChGroupSinkCurDayTable optIfOChGroupSinkPrevDayTable optIfOChGroupSrcCurrentTable optIfOChGroupSrcIntervalTable optIfOChGroupSrcCurDayTable optIfOChGroupSrcPrevDayTable Lam, et al. Standards Track [Page 22] RFC 3591 Optical Interface Type MIB September 2003 The optIfOCh groups handle the configuration and performance monitoring information for OCh layers. optIfOChConfigTable optIfOChSinkCurrentTable optIfOChSinkIntervalTable optIfOChSinkCurDayTable optIfOChSinkPrevDayTable optIfOChSrcCurrentTable optIfOChSrcIntervalTable optIfOChSrcCurDayTable optIfOChSrcPrevDayTable The optIfOTUk groups handle configuration information for OTUk. optIfOTUkConfigTable optIfGCC0ConfigTable The optIfODUk groups handle configuration information for ODUk. optIfODUkConfigTable optIfODUkTtpConfigTable optIfODUkPositionSeqTable optIfODUkNimConfigTable optIfGCC12ConfigTable The optIfODUkT groups handle configuration information for ODUkT. optIfODUkTConfigTable optIfODUkTNimConfigTable This memo does not define MIB objects for optical system cross- connects. After a consensus is reached on definitions of the interface MIB objects for optical systems (resulting from resolution of discussions on the objects proposed in this memo), work can progress on the definitions of tables to represent cross-connects (e.g., OCh optical cross-connects and ODUk electrical cross- connects). 3.1. The optIfOTMn group 3.1.1. optIfOTMnTable This table contains the OTM structure information of an optical interface. Lam, et al. Standards Track [Page 23] RFC 3591 Optical Interface Type MIB September 2003 3.2. The optIfPerfMon group 3.2.1. optIf Performance Monitoring Interval Table This table applies to all performance monitoring on an NE. It records on a per-interface basis the elapsed time in the current 15- minute and 24-hour interval, as well as the total number of 15-minute intervals and the number of invalid 15-minute intervals. 3.3. The optIfOTSn groups 3.3.1. optIfOTSn Configuration group 3.3.1.1. optIfOTSn Configuration Table This table contains information on configuration of optIfOTSn interfaces, in addition to the information on such interfaces contained in the ifTable. 3.3.2. optIfOTSn Pre-OTN PM group 3.3.2.1. optIfOTSn Source Current Table This table contains information on current performance of optIfOTSn interfaces contained in the ifTable. 3.3.2.2. optIfOTSn Source Interval Table This table contains information on historic performance of optIfOTSn interfaces contained in the ifTable. 3.3.2.3. optIfOTSn Source Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOTSn interfaces contained in the ifTable. 3.3.2.4. optIfOTSn Source Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOTSn interfaces contained in the ifTable. 3.3.2.5. optIfOTSn Sink Current Table This table contains information on current performance of optIfOTSn interfaces contained in the ifTable. Lam, et al. Standards Track [Page 24] RFC 3591 Optical Interface Type MIB September 2003 3.3.2.6. optIfOTSn Sink Interval Table This table contains information on historic performance of optIfOTSn interfaces contained in the ifTable. 3.3.2.7. optIfOTSn Sink Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOTSn interfaces contained in the ifTable. 3.3.2.8. optIfOTSn Sink Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOTSn interfaces contained in the ifTable. 3.4. The optIfOMSn groups 3.4.1. optIfOMSn Configuration group 3.4.1.1. optIfOMSn Configuration Table This table contains information on configuration of optIfOMSn interfaces, in addition to the information on such interfaces contained in the ifTable. 3.4.2. optIfOMSn Pre-OTN PM group 3.4.2.1. optIfOMSn Source Current Table This table contains information on current performance of optIfOMSn interfaces contained in the ifTable. 3.4.2.2. optIfOMSn Source Interval Table This table contains information on historic performance of optIfOMSn interfaces contained in the ifTable. 3.4.2.3. optIfOMSn Source Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOMSn interfaces contained in the ifTable. 3.4.2.4. optIfOMSn Source Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOMSn interfaces contained in the ifTable. Lam, et al. Standards Track [Page 25] RFC 3591 Optical Interface Type MIB September 2003 3.4.2.5. optIfOMSn Sink Current Table This table contains information on current performance of optIfOMSn interfaces contained in the ifTable. 3.4.2.6. optIfOMSn Sink Interval Table This table contains information on historic performance of optIfOMSn interfaces contained in the ifTable. 3.4.2.7. optIfOMSn Sink Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOMSn interfaces contained in the ifTable. 3.4.2.8. optIfOMSn Sink Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOMSn interfaces contained in the ifTable. 3.5. The optIfOChGroup groups 3.5.1. optIfOChGroup Configuration group 3.5.1.1. optIfOChGroup Configuration Table This table contains information on configuration of optIfOChGroup interfaces, in addition to the information on such interfaces contained in the ifTable. 3.5.2. optIfOChGroup Pre-OTN PM group 3.5.2.1. optIfOChGroup Source Current Table This table contains information on current performance of optIfOChGroup interfaces contained in the ifTable. 3.5.2.2. optIfOChGroup Source Interval Table This table contains information on historic performance of optIfOChGroup interfaces contained in the ifTable. 3.5.2.3. optIfOChGroup Source Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOChGroup interfaces contained in the ifTable. Lam, et al. Standards Track [Page 26] RFC 3591 Optical Interface Type MIB September 2003 3.5.2.4. optIfOChGroup Source Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOChGroup interfaces contained in the ifTable. 3.5.2.5. optIfOChGroup Sink Current Table This table contains information on current performance of optIfOChGroup interfaces contained in the ifTable. 3.5.2.6. optIfOChGroup Sink Interval Table This table contains information on historic performance of optIfOChGroup interfaces contained in the ifTable. 3.5.2.7. optIfOChGroup Sink Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOChGroup interfaces contained in the ifTable. 3.5.2.8. optIfOChGroup Sink Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOChGroup interfaces contained in the ifTable. 3.6. The optIfOCh groups 3.6.1. optIfOCh Configuration group 3.6.1.1. optIfOCh Configuration Table This table contains information on configuration of optIfOCh interfaces, in addition to the information on such interfaces contained in the ifTable. 3.6.2. optIfOCh Pre-OTN PM group 3.6.2.1. optIfOCh Source Current Table This table contains information on current performance of optIfOCh interfaces contained in the ifTable. 3.6.2.2. optIfOCh Source Interval Table This table contains information on historic performance of optIfOCh interfaces contained in the ifTable. Lam, et al. Standards Track [Page 27] RFC 3591 Optical Interface Type MIB September 2003 3.6.2.3. optIfOCh Source Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOCh interfaces contained in the ifTable. 3.6.2.4. optIfOCh Source Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOCh interfaces contained in the ifTable. 3.6.2.5. optIfOCh Sink Current Table This table contains information on current performance of optIfOCh interfaces contained in the ifTable. 3.6.2.6. optIfOCh Sink Interval Table This table contains information on historic performance of optIfOCh interfaces contained in the ifTable. 3.6.2.7. optIfOCh Sink Current Day Table This table contains a snapshot of information for the current 24-hour period for optIfOCh interfaces contained in the ifTable. 3.6.2.8. optIfOCh Sink Previous Day Table This table contains a snapshot of information for the previous 24- hour period for optIfOCh interfaces contained in the ifTable. 3.7. The optIfOTUk groups 3.7.1. optIfOTUk Configuration group 3.7.1.1. optIfOTUk Configuration Table This table contains information on configuration of optIfOTUk interfaces, in addition to the information on such interfaces contained in the ifTable. 3.7.2. optIfGCC0 Configuration group 3.7.2.1. optIfGCC0 Configuration Table This table contains information on configuration of the GCC0 communication channel. Lam, et al. Standards Track [Page 28] RFC 3591 Optical Interface Type MIB September 2003 3.8. The optIfODUk groups 3.8.1. optIfODUk Configuration group 3.8.1.1. optIfODUk Configuration Table This table contains all the objects that are common to endpoints (called trail termination points or TTPs) and connection termination points (CTPs), and also includes a flag stating whether TTP functions are present. 3.8.2. optIfODUkTtp Configuration group 3.8.2.1. optIfODUkTtp Configuration Table This table contains TTP-specific information on configuration of optIfODUk interfaces, in addition to the information on such interfaces contained in the ifTable. 3.8.3. optIfODUk Position Seq group 3.8.3.1. optIfODUk Position Seq Table This table contains information on the position sequence of the TCM function and/or GCC12 access that have been created within the optIfODUk interfaces, in addition to the information on such interfaces contained in the ifTable. 3.8.4. optIfODUk Nim Configuration group 3.8.4.1. optIfODUk Nim Configuration Table This table contains information on configuration of optIfODUk Non- intrusive monitoring. 3.8.5. optIfGCC12 Configuration group 3.8.5.1. optIfGCC12 Configuration Table This table contains information on configuration of the GCC1 and GCC2 communication channels. Lam, et al. Standards Track [Page 29] RFC 3591 Optical Interface Type MIB September 2003 3.9. The optIfODUkT groups 3.9.1. optIfODUkT Configuration group 3.9.1.1. optIfODUkT Configuration Table This table contains information on configuration of optIfODUkT interfaces, in addition to the information on such interfaces contained in the ifTable. 3.9.2. optIfODUkT Nim Configuration group 3.9.2.1. optIfODUkT Nim Configuration Table This table contains information on configuration of optIfODUkT Non- intrusive monitoring. 4. Object Definitions OPT-IF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Gauge32, Integer32, Unsigned32, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowPointer, RowStatus, TruthValue FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB; -- This is the MIB module for the OTN Interface objects. optIfMibModule MODULE-IDENTITY LAST-UPDATED "200308130000Z" ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/atommib-charter.html Mailing Lists: General Discussion: atommib@research.telcordia.com To Subscribe: atommib-request@research.telcordia.com Lam, et al. Standards Track [Page 30] RFC 3591 Optical Interface Type MIB September 2003 Editor: Hing-Kam Lam Postal: Lucent Technologies, Room 4C-616 101 Crawfords Corner Road Holmdel, NJ 07733 Tel: +1 732 949 8338 Email: hklam@lucent.com" DESCRIPTION "The MIB module to describe pre-OTN and OTN interfaces. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3591; see the RFC itself for full legal notices." REVISION "200308130000Z" DESCRIPTION "Initial version, published as RFC 3591." ::={ transmission 133 } -- textual conventions OptIfAcTI ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The trace identifier (TI) accepted at the receiver." SYNTAX OCTET STRING (SIZE(64)) OptIfBitRateK ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the index 'k' that is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. Allowed values of k are defined in ITU-T G.709. Currently allowed values in G.709 are: k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k=3 represents an approximate bit rate of 40 Gbit/s." SYNTAX Integer32 OptIfDEGM ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if OptIfDEGM consecutive bad PM Seconds are detected." SYNTAX Unsigned32 (2..10) Lam, et al. Standards Track [Page 31] RFC 3591 Optical Interface Type MIB September 2003 OptIfDEGThr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to OptIfDEGThr." SYNTAX Unsigned32 (1..100) OptIfDirectionality ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the directionality of an entity." SYNTAX INTEGER { sink(1), source(2), bidirectional(3) } OptIfSinkOrSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the directionality of an entity that is allowed only to be a source or sink." SYNTAX INTEGER { sink(1), source(2) } OptIfExDAPI ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Destination Access Point Identifier (DAPI) expected by the receiver." SYNTAX OCTET STRING (SIZE(16)) OptIfExSAPI ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Source Access Point Identifier (SAPI) expected by the receiver." SYNTAX OCTET STRING (SIZE(16)) OptIfIntervalNumber ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Uniquely identifies a 15-minute interval. The interval identified by 1 is the most recently completed interval, and Lam, et al. Standards Track [Page 32] RFC 3591 Optical Interface Type MIB September 2003 the interval identified by n is the interval immediately preceding the one identified by n-1." SYNTAX Unsigned32 (1..96) OptIfTIMDetMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function." SYNTAX INTEGER { off(1), dapi(2), sapi(3), both(4) } OptIfTxTI ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The trace identifier (TI) transmitted." SYNTAX OCTET STRING (SIZE(64)) -- object groups optIfObjects OBJECT IDENTIFIER ::= { optIfMibModule 1 } optIfConfs OBJECT IDENTIFIER ::= { optIfMibModule 2 } optIfOTMn OBJECT IDENTIFIER ::= { optIfObjects 1 } optIfPerfMon OBJECT IDENTIFIER ::= { optIfObjects 2 } optIfOTSn OBJECT IDENTIFIER ::= { optIfObjects 3 } optIfOMSn OBJECT IDENTIFIER ::= { optIfObjects 4 } optIfOChGroup OBJECT IDENTIFIER ::= { optIfObjects 5 } optIfOCh OBJECT IDENTIFIER ::= { optIfObjects 6 } optIfOTUk OBJECT IDENTIFIER ::= { optIfObjects 7 } optIfODUk OBJECT IDENTIFIER ::= { optIfObjects 8 } optIfODUkT OBJECT IDENTIFIER ::= { optIfObjects 9 } optIfGroups OBJECT IDENTIFIER ::= { optIfConfs 1 } optIfCompl OBJECT IDENTIFIER ::= { optIfConfs 2 } -- the optIfOTMn group -- This group defines the OTM structure information of an -- optical interface. -- OTMn Table optIfOTMnTable OBJECT-TYPE Lam, et al. Standards Track [Page 33] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX SEQUENCE OF OptIfOTMnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTMn structure information." ::= { optIfOTMn 1 } optIfOTMnEntry OBJECT-TYPE SYNTAX OptIfOTMnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains the OTMn structure information of an optical interface." INDEX { ifIndex } ::= { optIfOTMnTable 1 } OptIfOTMnEntry ::= SEQUENCE { optIfOTMnOrder Unsigned32, optIfOTMnReduced TruthValue, optIfOTMnBitRates BITS, optIfOTMnInterfaceType SnmpAdminString, optIfOTMnTcmMax Unsigned32, optIfOTMnOpticalReach INTEGER } optIfOTMnOrder OBJECT-TYPE SYNTAX Unsigned32 (1..900) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the order of the OTM, which represents the maximum number of wavelengths that can be supported at the bit rate(s) supported on the interface." ::= { optIfOTMnEntry 1 } optIfOTMnReduced OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether a reduced or full functionality is supported at the interface. A value of true means reduced. A value of false means full." ::= { optIfOTMnEntry 2 } optIfOTMnBitRates OBJECT-TYPE Lam, et al. Standards Track [Page 34] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX BITS { bitRateK1(0), bitRateK2(1), bitRateK3(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute is a bit map representing the bit rate or set of bit rates supported on the interface. The meaning of each bit position is as follows: bitRateK1(0) is set if the 2.5 Gbit/s rate is supported bitRateK2(1) is set if the 10 Gbit/s rate is supported bitRateK3(2) is set if the 40 Gbit/s rate is supported Note that each bit position corresponds to one possible value of the type OptIfBitRateK. The default value of this attribute is system specific." ::= { optIfOTMnEntry 3 } optIfOTMnInterfaceType OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the type of interface. The value of this attribute will affect the behavior of the OTM with respect to presence/absence of OTM Overhead Signal (OOS) processing and TCM activation. For an IrDI interface, there is no OOS processing and TCM activation is limited to n levels as specified by a TCM level threshold. This object contains two fields that are separated by whitespace. The possible values are: field 1: one of the 4-character ASCII strings 'IrDI' or 'IaDI' field 2: free-form text consisting of printable UTF-8 encoded characters Note that field 2 is optional. If it is not present then there is no requirement for trailing whitespace after field 1. The default values are as follows: field 1: 'IaDI' field 2: an empty string." ::= { optIfOTMnEntry 4 } optIfOTMnTcmMax OBJECT-TYPE SYNTAX Unsigned32 (0..6) MAX-ACCESS read-write STATUS current DESCRIPTION Lam, et al. Standards Track [Page 35] RFC 3591 Optical Interface Type MIB September 2003 "This object identifies the maximum number of TCM levels allowed for any Optical Channel contained in this OTM. A new TCM activation will be rejected if the requested level is greater than the threshold. If InterfaceType object specifies a type of 'IaDI' for this OTM, then this attribute is irrelevant. Possible values: unsigned integers in the range from 0 to 6 inclusive. Default value: 3." ::= { optIfOTMnEntry 5 } optIfOTMnOpticalReach OBJECT-TYPE SYNTAX INTEGER { intraOffice(1), shortHaul(2), longHaul(3), veryLongHaul(4), ultraLongHaul(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the length the optical signal may travel before requiring termination or regeneration. The meaning of the enumeration are: intraOffice(1) - intra-office (as defined in ITU-T G.957) shortHaul(2) - short haul (as defined in ITU-T G.957) longHaul(3) - long haul (as defined in ITU-T G.957) veryLongHaul(4) - very long haul (as defined in ITU-T G.691) ultraLongHaul(5)- ultra long haul (as defined in ITU-T G.691)" ::= { optIfOTMnEntry 6 } -- the optIfPerfMon group -- This group defines performance monitoring objects for all -- layers. -- PM interval table optIfPerfMonIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfPerfMonIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of 15-minute performance monitoring interval information." ::= { optIfPerfMon 1 } optIfPerfMonIntervalEntry OBJECT-TYPE SYNTAX OptIfPerfMonIntervalEntry MAX-ACCESS not-accessible STATUS current Lam, et al. Standards Track [Page 36] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "A conceptual row that contains 15-minute performance monitoring interval information of an interface." INDEX { ifIndex } ::= { optIfPerfMonIntervalTable 1 } OptIfPerfMonIntervalEntry ::= SEQUENCE { optIfPerfMonCurrentTimeElapsed Gauge32, optIfPerfMonCurDayTimeElapsed Gauge32, optIfPerfMonIntervalNumIntervals Unsigned32, optIfPerfMonIntervalNumInvalidIntervals Unsigned32 } optIfPerfMonCurrentTimeElapsed OBJECT-TYPE SYNTAX Gauge32 (0..900) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds elapsed in the current 15-minute performance monitoring interval. If, for some reason, such as an adjustment in the NE's time-of-day clock, the number of seconds elapsed exceeds the maximum value, then the maximum value will be returned." ::= { optIfPerfMonIntervalEntry 1 } optIfPerfMonCurDayTimeElapsed OBJECT-TYPE SYNTAX Gauge32 (0..86400) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds elapsed in the current 24-hour interval performance monitoring period. If, for some reason, such as an adjustment in the NE's time-of-day clock, the number of seconds elapsed exceeds the maximum value, then the maximum value will be returned." ::= { optIfPerfMonIntervalEntry 2 } optIfPerfMonIntervalNumIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 15-minute intervals for which performance monitoring data is available. The number is the same for all the associated sub layers of the interface. Lam, et al. Standards Track [Page 37] RFC 3591 Optical Interface Type MIB September 2003 An optical interface must be capable of supporting at least n intervals, where n is defined as follows: The minimum value of n is 4. The default of n is 32. The maximum value of n is 96. The value of this object will be n unless performance monitoring was (re-)started for the interface within the last (n*15) minutes, in which case the value will be the number of complete 15-minute intervals since measurement was (re-)started." ::= { optIfPerfMonIntervalEntry 3 } optIfPerfMonIntervalNumInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to optIfPerfMonIntervalNumIntervals for which no performance monitoring data is available and/or the data is invalid." ::= { optIfPerfMonIntervalEntry 4 } -- the optIfOTSn group -- This group handles the configuration and performance -- monitoring objects for OTS layers. -- OTSn config table optIfOTSnConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTSn configuration information." ::= { optIfOTSn 1 } optIfOTSnConfigEntry OBJECT-TYPE SYNTAX OptIfOTSnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn configuration information of an interface." INDEX { ifIndex } ::= { optIfOTSnConfigTable 1 } OptIfOTSnConfigEntry ::= Lam, et al. Standards Track [Page 38] RFC 3591 Optical Interface Type MIB September 2003 SEQUENCE { optIfOTSnDirectionality OptIfDirectionality, optIfOTSnAprStatus SnmpAdminString, optIfOTSnAprControl SnmpAdminString, optIfOTSnTraceIdentifierTransmitted OptIfTxTI, optIfOTSnDAPIExpected OptIfExDAPI, optIfOTSnSAPIExpected OptIfExSAPI, optIfOTSnTraceIdentifierAccepted OptIfAcTI, optIfOTSnTIMDetMode OptIfTIMDetMode, optIfOTSnTIMActEnabled TruthValue, optIfOTSnCurrentStatus BITS } optIfOTSnDirectionality OBJECT-TYPE SYNTAX OptIfDirectionality MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the directionality of the entity." ::= { optIfOTSnConfigEntry 1 } optIfOTSnAprStatus OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute indicates the status of the Automatic Power Reduction (APR) function of the entity. Valid values are 'on' and 'off'." ::= { optIfOTSnConfigEntry 2 } optIfOTSnAprControl OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object is a UTF-8 encoded string that specifies Automatic Power Reduction (APR) control actions requested of this entity (when written) and that returns the current APR control state of this entity (when read). The values are implementation-defined. Any implementation that instantiates this object must document the set of values that it allows to be written, the set of values that it will return, and what each of those values means." ::= { optIfOTSnConfigEntry 3 } optIfOTSnTraceIdentifierTransmitted OBJECT-TYPE SYNTAX OptIfTxTI MAX-ACCESS read-write Lam, et al. Standards Track [Page 39] RFC 3591 Optical Interface Type MIB September 2003 STATUS current DESCRIPTION "The trace identifier transmitted. This object is applicable when optIfOTSnDirectionality has the value source(2) or bidirectional(3). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI'). If no value is ever set by a management entity for the object optIfOTSnTraceIdentifierTransmitted, system-specific default value will be used. Any implementation that instantiates this object must document the system-specific default value or how it is derived." ::= { optIfOTSnConfigEntry 4 } optIfOTSnDAPIExpected OBJECT-TYPE SYNTAX OptIfExDAPI MAX-ACCESS read-write STATUS current DESCRIPTION "The DAPI expected by the receiver. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). It has no effect if optIfOTSnTIMDetMode has the value off(1) or sapi(3). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI')." ::= { optIfOTSnConfigEntry 5 } optIfOTSnSAPIExpected OBJECT-TYPE SYNTAX OptIfExSAPI MAX-ACCESS read-write STATUS current DESCRIPTION "The SAPI expected by the receiver. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). It has no effect if optIfOTSnTIMDetMode has the value off(1) or dapi(2). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI')." ::= { optIfOTSnConfigEntry 6 } optIfOTSnTraceIdentifierAccepted OBJECT-TYPE SYNTAX OptIfAcTI Lam, et al. Standards Track [Page 40] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The actual trace identifier received. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). Its value is unspecified if optIfOTSnCurrentStatus has either or both of the losO(5) and los(6) bits set. This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI')." ::= { optIfOTSnConfigEntry 7 } optIfOTSnTIMDetMode OBJECT-TYPE SYNTAX OptIfTIMDetMode MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). The default value is off(1). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI'). The default value of this object is off(1)." ::= { optIfOTSnConfigEntry 8 } optIfOTSnTIMActEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). It has no effect when the value of optIfOTSnTIMDetMode is off(1). This object does not apply to reduced-capability systems (i.e., those for which optIfOTMnReduced has the value true(1)) or at IrDI interfaces (i.e., when optIfOTMnInterfaceType field 1 has the value 'IrDI'). The default value of this object is false(2)." ::= { optIfOTSnConfigEntry 9 } optIfOTSnCurrentStatus OBJECT-TYPE Lam, et al. Standards Track [Page 41] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX BITS { bdiP(0), bdiO(1), bdi(2), tim(3), losP(4), losO(5), los(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the defect condition of the entity, if any. This object is applicable when optIfOTSnDirectionality has the value sink(1) or bidirectional(3). In reduced-capability systems or at IrDI interfaces the only bit position that may be set is los(6)." ::= { optIfOTSnConfigEntry 10 } -- OTSn sink current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOTSnSinkCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTSn sink performance monitoring information for the current 15-minute interval." ::= { optIfOTSn 2 } optIfOTSnSinkCurrentEntry OBJECT-TYPE SYNTAX OptIfOTSnSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn sink performance monitoring information of an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOTSnSinkCurrentTable 1 } OptIfOTSnSinkCurrentEntry ::= SEQUENCE { optIfOTSnSinkCurrentSuspectedFlag TruthValue, optIfOTSnSinkCurrentInputPower Integer32, optIfOTSnSinkCurrentLowInputPower Integer32, Lam, et al. Standards Track [Page 42] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSinkCurrentHighInputPower Integer32, optIfOTSnSinkCurrentLowerInputPowerThreshold Integer32, optIfOTSnSinkCurrentUpperInputPowerThreshold Integer32, optIfOTSnSinkCurrentOutputPower Integer32, optIfOTSnSinkCurrentLowOutputPower Integer32, optIfOTSnSinkCurrentHighOutputPower Integer32, optIfOTSnSinkCurrentLowerOutputPowerThreshold Integer32, optIfOTSnSinkCurrentUpperOutputPowerThreshold Integer32 } optIfOTSnSinkCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSinkCurrentEntry 1 } optIfOTSnSinkCurrentInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the input." ::= { optIfOTSnSinkCurrentEntry 2 } optIfOTSnSinkCurrentLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the current 15-minute interval." ::= { optIfOTSnSinkCurrentEntry 3 } optIfOTSnSinkCurrentHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the current 15-minute interval." ::= { optIfOTSnSinkCurrentEntry 4 } optIfOTSnSinkCurrentLowerInputPowerThreshold OBJECT-TYPE Lam, et al. Standards Track [Page 43] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on input power. If optIfOTSnSinkCurrentInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSinkCurrentEntry 5 } optIfOTSnSinkCurrentUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on input power. If optIfOTSnSinkCurrentInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSinkCurrentEntry 6 } optIfOTSnSinkCurrentOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output." ::= { optIfOTSnSinkCurrentEntry 7 } optIfOTSnSinkCurrentLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 15-minute interval." ::= { optIfOTSnSinkCurrentEntry 8 } optIfOTSnSinkCurrentHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval." Lam, et al. Standards Track [Page 44] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOTSnSinkCurrentEntry 9 } optIfOTSnSinkCurrentLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on output power. If optIfOTSnSinkCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSinkCurrentEntry 10 } optIfOTSnSinkCurrentUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If optIfOTSnSinkCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSinkCurrentEntry 11 } -- OTSn sink interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOTSnSinkIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of historical OTSn sink performance monitoring information." ::= { optIfOTSn 3 } optIfOTSnSinkIntervalEntry OBJECT-TYPE SYNTAX OptIfOTSnSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn sink performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOTSnSinkIntervalNumber } ::= { optIfOTSnSinkIntervalTable 1 } Lam, et al. Standards Track [Page 45] RFC 3591 Optical Interface Type MIB September 2003 OptIfOTSnSinkIntervalEntry ::= SEQUENCE { optIfOTSnSinkIntervalNumber OptIfIntervalNumber, optIfOTSnSinkIntervalSuspectedFlag TruthValue, optIfOTSnSinkIntervalLastInputPower Integer32, optIfOTSnSinkIntervalLowInputPower Integer32, optIfOTSnSinkIntervalHighInputPower Integer32, optIfOTSnSinkIntervalLastOutputPower Integer32, optIfOTSnSinkIntervalLowOutputPower Integer32, optIfOTSnSinkIntervalHighOutputPower Integer32 } optIfOTSnSinkIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOTSnSinkIntervalEntry 1 } optIfOTSnSinkIntervalSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSinkIntervalEntry 2 } optIfOTSnSinkIntervalLastInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the input during the interval." ::= { optIfOTSnSinkIntervalEntry 3 } optIfOTSnSinkIntervalLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the interval." ::= { optIfOTSnSinkIntervalEntry 4 } Lam, et al. Standards Track [Page 46] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSinkIntervalHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the interval." ::= { optIfOTSnSinkIntervalEntry 5 } optIfOTSnSinkIntervalLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the interval." ::= { optIfOTSnSinkIntervalEntry 6 } optIfOTSnSinkIntervalLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the interval." ::= { optIfOTSnSinkIntervalEntry 7 } optIfOTSnSinkIntervalHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the interval." ::= { optIfOTSnSinkIntervalEntry 8 } -- OTSn sink current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOTSnSinkCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSinkCurDayEntry MAX-ACCESS not-accessible STATUS current Lam, et al. Standards Track [Page 47] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "A table of OTSn sink performance monitoring information for the current 24-hour interval." ::= { optIfOTSn 4 } optIfOTSnSinkCurDayEntry OBJECT-TYPE SYNTAX OptIfOTSnSinkCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn sink performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } ::= { optIfOTSnSinkCurDayTable 1 } OptIfOTSnSinkCurDayEntry ::= SEQUENCE { optIfOTSnSinkCurDaySuspectedFlag TruthValue, optIfOTSnSinkCurDayLowInputPower Integer32, optIfOTSnSinkCurDayHighInputPower Integer32, optIfOTSnSinkCurDayLowOutputPower Integer32, optIfOTSnSinkCurDayHighOutputPower Integer32 } optIfOTSnSinkCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSinkCurDayEntry 1 } optIfOTSnSinkCurDayLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the current 24-hour interval." ::= { optIfOTSnSinkCurDayEntry 2 } optIfOTSnSinkCurDayHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current Lam, et al. Standards Track [Page 48] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "The highest optical power monitored at the input during the current 24-hour interval." ::= { optIfOTSnSinkCurDayEntry 3 } optIfOTSnSinkCurDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 24-hour interval." ::= { optIfOTSnSinkCurDayEntry 4 } optIfOTSnSinkCurDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 24-hour interval." ::= { optIfOTSnSinkCurDayEntry 5 } -- OTSn sink previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOTSnSinkPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTSn sink performance monitoring information for the previous 24-hour interval." ::= { optIfOTSn 5 } optIfOTSnSinkPrevDayEntry OBJECT-TYPE SYNTAX OptIfOTSnSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn sink performance monitoring information of an interface for the previous 24-hour interval." INDEX { ifIndex } ::= { optIfOTSnSinkPrevDayTable 1 } Lam, et al. Standards Track [Page 49] RFC 3591 Optical Interface Type MIB September 2003 OptIfOTSnSinkPrevDayEntry ::= SEQUENCE { optIfOTSnSinkPrevDaySuspectedFlag TruthValue, optIfOTSnSinkPrevDayLastInputPower Integer32, optIfOTSnSinkPrevDayLowInputPower Integer32, optIfOTSnSinkPrevDayHighInputPower Integer32, optIfOTSnSinkPrevDayLastOutputPower Integer32, optIfOTSnSinkPrevDayLowOutputPower Integer32, optIfOTSnSinkPrevDayHighOutputPower Integer32 } optIfOTSnSinkPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSinkPrevDayEntry 1 } optIfOTSnSinkPrevDayLastInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the input during the previous 24-hour interval." ::= { optIfOTSnSinkPrevDayEntry 2 } optIfOTSnSinkPrevDayLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the previous 24-hour interval." ::= { optIfOTSnSinkPrevDayEntry 3 } optIfOTSnSinkPrevDayHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the previous 24-hour interval." ::= { optIfOTSnSinkPrevDayEntry 4 } Lam, et al. Standards Track [Page 50] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSinkPrevDayLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the previous 24-hour interval." ::= { optIfOTSnSinkPrevDayEntry 5 } optIfOTSnSinkPrevDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOTSnSinkPrevDayEntry 6 } optIfOTSnSinkPrevDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOTSnSinkPrevDayEntry 7 } -- OTSn source current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOTSnSrcCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTSn source performance monitoring information for the current 15-minute interval." ::= { optIfOTSn 6 } optIfOTSnSrcCurrentEntry OBJECT-TYPE SYNTAX OptIfOTSnSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Lam, et al. Standards Track [Page 51] RFC 3591 Optical Interface Type MIB September 2003 "A conceptual row that contains OTSn source performance monitoring information of an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOTSnSrcCurrentTable 1 } OptIfOTSnSrcCurrentEntry ::= SEQUENCE { optIfOTSnSrcCurrentSuspectedFlag TruthValue, optIfOTSnSrcCurrentOutputPower Integer32, optIfOTSnSrcCurrentLowOutputPower Integer32, optIfOTSnSrcCurrentHighOutputPower Integer32, optIfOTSnSrcCurrentLowerOutputPowerThreshold Integer32, optIfOTSnSrcCurrentUpperOutputPowerThreshold Integer32, optIfOTSnSrcCurrentInputPower Integer32, optIfOTSnSrcCurrentLowInputPower Integer32, optIfOTSnSrcCurrentHighInputPower Integer32, optIfOTSnSrcCurrentLowerInputPowerThreshold Integer32, optIfOTSnSrcCurrentUpperInputPowerThreshold Integer32 } optIfOTSnSrcCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSrcCurrentEntry 1 } optIfOTSnSrcCurrentOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output." ::= { optIfOTSnSrcCurrentEntry 2 } optIfOTSnSrcCurrentLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 15-minute interval." ::= { optIfOTSnSrcCurrentEntry 3 } Lam, et al. Standards Track [Page 52] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSrcCurrentHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval." ::= { optIfOTSnSrcCurrentEntry 4 } optIfOTSnSrcCurrentLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on output power. If optIfOTSnSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSrcCurrentEntry 5 } optIfOTSnSrcCurrentUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If optIfOTSnSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSrcCurrentEntry 6 } optIfOTSnSrcCurrentInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the input." ::= { optIfOTSnSrcCurrentEntry 7 } optIfOTSnSrcCurrentLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION Lam, et al. Standards Track [Page 53] RFC 3591 Optical Interface Type MIB September 2003 "The lowest optical power monitored at the input during the current 15-minute interval." ::= { optIfOTSnSrcCurrentEntry 8 } optIfOTSnSrcCurrentHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the current 15-minute interval." ::= { optIfOTSnSrcCurrentEntry 9 } optIfOTSnSrcCurrentLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on input power. If optIfOTSnSrcCurrentInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSrcCurrentEntry 10 } optIfOTSnSrcCurrentUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on input power. If optIfOTSnSrcCurrentInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOTSnSrcCurrentEntry 11 } -- OTSn source interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOTSnSrcIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of historical OTSn source performance monitoring information." ::= { optIfOTSn 7 } Lam, et al. Standards Track [Page 54] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSrcIntervalEntry OBJECT-TYPE SYNTAX OptIfOTSnSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn source performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOTSnSrcIntervalNumber } ::= { optIfOTSnSrcIntervalTable 1 } OptIfOTSnSrcIntervalEntry ::= SEQUENCE { optIfOTSnSrcIntervalNumber OptIfIntervalNumber, optIfOTSnSrcIntervalSuspectedFlag TruthValue, optIfOTSnSrcIntervalLastOutputPower Integer32, optIfOTSnSrcIntervalLowOutputPower Integer32, optIfOTSnSrcIntervalHighOutputPower Integer32, optIfOTSnSrcIntervalLastInputPower Integer32, optIfOTSnSrcIntervalLowInputPower Integer32, optIfOTSnSrcIntervalHighInputPower Integer32 } optIfOTSnSrcIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOTSnSrcIntervalEntry 1 } optIfOTSnSrcIntervalSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSrcIntervalEntry 2 } optIfOTSnSrcIntervalLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the interval." ::= { optIfOTSnSrcIntervalEntry 3 } Lam, et al. Standards Track [Page 55] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSrcIntervalLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the interval." ::= { optIfOTSnSrcIntervalEntry 4 } optIfOTSnSrcIntervalHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the interval." ::= { optIfOTSnSrcIntervalEntry 5 } optIfOTSnSrcIntervalLastInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the input during the interval." ::= { optIfOTSnSrcIntervalEntry 6 } optIfOTSnSrcIntervalLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the interval." ::= { optIfOTSnSrcIntervalEntry 7 } optIfOTSnSrcIntervalHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the interval." Lam, et al. Standards Track [Page 56] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOTSnSrcIntervalEntry 8 } -- OTSn source current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOTSnSrcCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTSn source performance monitoring information for the current 24-hour interval." ::= { optIfOTSn 8 } optIfOTSnSrcCurDayEntry OBJECT-TYPE SYNTAX OptIfOTSnSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn source performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } ::= { optIfOTSnSrcCurDayTable 1 } OptIfOTSnSrcCurDayEntry ::= SEQUENCE { optIfOTSnSrcCurDaySuspectedFlag TruthValue, optIfOTSnSrcCurDayLowOutputPower Integer32, optIfOTSnSrcCurDayHighOutputPower Integer32, optIfOTSnSrcCurDayLowInputPower Integer32, optIfOTSnSrcCurDayHighInputPower Integer32 } optIfOTSnSrcCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSrcCurDayEntry 1 } optIfOTSnSrcCurDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only Lam, et al. Standards Track [Page 57] RFC 3591 Optical Interface Type MIB September 2003 STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 24-hour interval." ::= { optIfOTSnSrcCurDayEntry 2 } optIfOTSnSrcCurDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 24-hour interval." ::= { optIfOTSnSrcCurDayEntry 3 } optIfOTSnSrcCurDayLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the current 24-hour interval." ::= { optIfOTSnSrcCurDayEntry 4 } optIfOTSnSrcCurDayHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the current 24-hour interval." ::= { optIfOTSnSrcCurDayEntry 5 } -- OTSn source previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOTSnSrcPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTSnSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTSn source performance monitoring information for the previous 24-hour interval." ::= { optIfOTSn 9 } Lam, et al. Standards Track [Page 58] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSrcPrevDayEntry OBJECT-TYPE SYNTAX OptIfOTSnSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTSn source performance monitoring information of an interface for the previous 24-hour interval." INDEX { ifIndex } ::= { optIfOTSnSrcPrevDayTable 1 } OptIfOTSnSrcPrevDayEntry ::= SEQUENCE { optIfOTSnSrcPrevDaySuspectedFlag TruthValue, optIfOTSnSrcPrevDayLastOutputPower Integer32, optIfOTSnSrcPrevDayLowOutputPower Integer32, optIfOTSnSrcPrevDayHighOutputPower Integer32, optIfOTSnSrcPrevDayLastInputPower Integer32, optIfOTSnSrcPrevDayLowInputPower Integer32, optIfOTSnSrcPrevDayHighInputPower Integer32 } optIfOTSnSrcPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOTSnSrcPrevDayEntry 1 } optIfOTSnSrcPrevDayLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the previous 24-hour interval." ::= { optIfOTSnSrcPrevDayEntry 2 } optIfOTSnSrcPrevDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the previous 24-hour interval." Lam, et al. Standards Track [Page 59] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOTSnSrcPrevDayEntry 3 } optIfOTSnSrcPrevDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOTSnSrcPrevDayEntry 4 } optIfOTSnSrcPrevDayLastInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the input during the previous 24-hour interval." ::= { optIfOTSnSrcPrevDayEntry 5 } optIfOTSnSrcPrevDayLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the previous 24-hour interval." ::= { optIfOTSnSrcPrevDayEntry 6 } optIfOTSnSrcPrevDayHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the previous 24-hour interval." ::= { optIfOTSnSrcPrevDayEntry 7 } -- the optIfOMSn group -- This group handles the configuration and performance monitoring -- information for OMS layers. -- OMSn config table Lam, et al. Standards Track [Page 60] RFC 3591 Optical Interface Type MIB September 2003 optIfOMSnConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OMSn configuration information." ::= { optIfOMSn 1 } optIfOMSnConfigEntry OBJECT-TYPE SYNTAX OptIfOMSnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn configuration information of an interface." INDEX { ifIndex } ::= { optIfOMSnConfigTable 1 } OptIfOMSnConfigEntry ::= SEQUENCE { optIfOMSnDirectionality OptIfDirectionality, optIfOMSnCurrentStatus BITS } optIfOMSnDirectionality OBJECT-TYPE SYNTAX OptIfDirectionality MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the directionality of the entity." ::= { optIfOMSnConfigEntry 1 } optIfOMSnCurrentStatus OBJECT-TYPE SYNTAX BITS { ssfP(0), ssfO(1), ssf(2), bdiP(3), bdiO(4), bdi(5), losP(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the defect condition of the entity, if any. This object is applicable only to full capability systems whose interface type is IaDI and for which Lam, et al. Standards Track [Page 61] RFC 3591 Optical Interface Type MIB September 2003 optIfOMSnDirectionality has the value sink(1) or bidirectional(3)." ::= { optIfOMSnConfigEntry 2 } -- OMSn sink current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOMSnSinkCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OMSn sink performance monitoring information for the current 15-minute interval." ::= { optIfOMSn 2 } optIfOMSnSinkCurrentEntry OBJECT-TYPE SYNTAX OptIfOMSnSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn sink performance monitoring information of an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOMSnSinkCurrentTable 1 } OptIfOMSnSinkCurrentEntry ::= SEQUENCE { optIfOMSnSinkCurrentSuspectedFlag TruthValue, optIfOMSnSinkCurrentAggregatedInputPower Integer32, optIfOMSnSinkCurrentLowAggregatedInputPower Integer32, optIfOMSnSinkCurrentHighAggregatedInputPower Integer32, optIfOMSnSinkCurrentLowerInputPowerThreshold Integer32, optIfOMSnSinkCurrentUpperInputPowerThreshold Integer32, optIfOMSnSinkCurrentOutputPower Integer32, optIfOMSnSinkCurrentLowOutputPower Integer32, optIfOMSnSinkCurrentHighOutputPower Integer32, optIfOMSnSinkCurrentLowerOutputPowerThreshold Integer32, optIfOMSnSinkCurrentUpperOutputPowerThreshold Integer32 } optIfOMSnSinkCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Lam, et al. Standards Track [Page 62] RFC 3591 Optical Interface Type MIB September 2003 "If true, the data in this entry may be unreliable." ::= { optIfOMSnSinkCurrentEntry 1 } optIfOMSnSinkCurrentAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The aggregated optical power of all the DWDM input channels." ::= { optIfOMSnSinkCurrentEntry 2 } optIfOMSnSinkCurrentLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels during the current 15-minute interval." ::= { optIfOMSnSinkCurrentEntry 3 } optIfOMSnSinkCurrentHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power of all the DWDM input channels during the current 15-minute interval." ::= { optIfOMSnSinkCurrentEntry 4 } optIfOMSnSinkCurrentLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on aggregated input power. If optIfOMSnSinkCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSinkCurrentEntry 5 } optIfOMSnSinkCurrentUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write Lam, et al. Standards Track [Page 63] RFC 3591 Optical Interface Type MIB September 2003 STATUS current DESCRIPTION "The upper limit threshold on aggregated input power. If optIfOMSnSinkCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSinkCurrentEntry 6 } optIfOMSnSinkCurrentOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output." ::= { optIfOMSnSinkCurrentEntry 7 } optIfOMSnSinkCurrentLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 15-minute interval." ::= { optIfOMSnSinkCurrentEntry 8 } optIfOMSnSinkCurrentHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval." ::= { optIfOMSnSinkCurrentEntry 9 } optIfOMSnSinkCurrentLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on output power. If optIfOMSnSinkCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSinkCurrentEntry 10 } optIfOMSnSinkCurrentUpperOutputPowerThreshold OBJECT-TYPE Lam, et al. Standards Track [Page 64] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If optIfOMSnSinkCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSinkCurrentEntry 11 } -- OMSn sink interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOMSnSinkIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of historical OMSn sink performance monitoring information." ::= { optIfOMSn 3 } optIfOMSnSinkIntervalEntry OBJECT-TYPE SYNTAX OptIfOMSnSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn sink performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOMSnSinkIntervalNumber } ::= { optIfOMSnSinkIntervalTable 1 } OptIfOMSnSinkIntervalEntry ::= SEQUENCE { optIfOMSnSinkIntervalNumber OptIfIntervalNumber, optIfOMSnSinkIntervalSuspectedFlag TruthValue, optIfOMSnSinkIntervalLastAggregatedInputPower Integer32, optIfOMSnSinkIntervalLowAggregatedInputPower Integer32, optIfOMSnSinkIntervalHighAggregatedInputPower Integer32, optIfOMSnSinkIntervalLastOutputPower Integer32, optIfOMSnSinkIntervalLowOutputPower Integer32, optIfOMSnSinkIntervalHighOutputPower Integer32 } optIfOMSnSinkIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber Lam, et al. Standards Track [Page 65] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOMSnSinkIntervalEntry 1 } optIfOMSnSinkIntervalSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOMSnSinkIntervalEntry 2 } optIfOMSnSinkIntervalLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power of all the DWDM input channels during the interval." ::= { optIfOMSnSinkIntervalEntry 3 } optIfOMSnSinkIntervalLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels during the interval." ::= { optIfOMSnSinkIntervalEntry 4 } optIfOMSnSinkIntervalHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power of all the DWDM input channels during the interval." ::= { optIfOMSnSinkIntervalEntry 5 } optIfOMSnSinkIntervalLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only Lam, et al. Standards Track [Page 66] RFC 3591 Optical Interface Type MIB September 2003 STATUS current DESCRIPTION "The last optical power at the output during the interval." ::= { optIfOMSnSinkIntervalEntry 6 } optIfOMSnSinkIntervalLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power at the output during the interval." ::= { optIfOMSnSinkIntervalEntry 7 } optIfOMSnSinkIntervalHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power at the output during the interval." ::= { optIfOMSnSinkIntervalEntry 8 } -- OMSn sink current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOMSnSinkCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSinkCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OMSn sink performance monitoring information for the current 24-hour interval." ::= { optIfOMSn 4 } optIfOMSnSinkCurDayEntry OBJECT-TYPE SYNTAX OptIfOMSnSinkCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn sink performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } Lam, et al. Standards Track [Page 67] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOMSnSinkCurDayTable 1 } OptIfOMSnSinkCurDayEntry ::= SEQUENCE { optIfOMSnSinkCurDaySuspectedFlag TruthValue, optIfOMSnSinkCurDayLowAggregatedInputPower Integer32, optIfOMSnSinkCurDayHighAggregatedInputPower Integer32, optIfOMSnSinkCurDayLowOutputPower Integer32, optIfOMSnSinkCurDayHighOutputPower Integer32 } optIfOMSnSinkCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOMSnSinkCurDayEntry 1 } optIfOMSnSinkCurDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels during the current 24-hour interval." ::= { optIfOMSnSinkCurDayEntry 2 } optIfOMSnSinkCurDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power of all the DWDM input channels during the current 24-hour interval." ::= { optIfOMSnSinkCurDayEntry 3 } optIfOMSnSinkCurDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power at the output during the current 24-hour interval." ::= { optIfOMSnSinkCurDayEntry 4 } Lam, et al. Standards Track [Page 68] RFC 3591 Optical Interface Type MIB September 2003 optIfOMSnSinkCurDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power at the output during the current 24-hour interval." ::= { optIfOMSnSinkCurDayEntry 5 } -- OMSn sink previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOMSnSinkPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OMSn sink performance monitoring information for the previous 24-hour interval." ::= { optIfOMSn 5 } optIfOMSnSinkPrevDayEntry OBJECT-TYPE SYNTAX OptIfOMSnSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn sink performance monitoring information of an interface for the previous 24-hour interval." INDEX { ifIndex } ::= { optIfOMSnSinkPrevDayTable 1 } OptIfOMSnSinkPrevDayEntry ::= SEQUENCE { optIfOMSnSinkPrevDaySuspectedFlag TruthValue, optIfOMSnSinkPrevDayLastAggregatedInputPower Integer32, optIfOMSnSinkPrevDayLowAggregatedInputPower Integer32, optIfOMSnSinkPrevDayHighAggregatedInputPower Integer32, optIfOMSnSinkPrevDayLastOutputPower Integer32, optIfOMSnSinkPrevDayLowOutputPower Integer32, optIfOMSnSinkPrevDayHighOutputPower Integer32 } optIfOMSnSinkPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only Lam, et al. Standards Track [Page 69] RFC 3591 Optical Interface Type MIB September 2003 STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOMSnSinkPrevDayEntry 1 } optIfOMSnSinkPrevDayLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power of all the DWDM input channels during the previous 24-hour interval." ::= { optIfOMSnSinkPrevDayEntry 2 } optIfOMSnSinkPrevDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels during the previous 24-hour interval." ::= { optIfOMSnSinkPrevDayEntry 3 } optIfOMSnSinkPrevDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power of all the DWDM input channels during the previous 24-hour interval." ::= { optIfOMSnSinkPrevDayEntry 4 } optIfOMSnSinkPrevDayLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power at the output during the previous 24-hour interval." ::= { optIfOMSnSinkPrevDayEntry 5 } optIfOMSnSinkPrevDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" Lam, et al. Standards Track [Page 70] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power at the output during the previous 24-hour interval." ::= { optIfOMSnSinkPrevDayEntry 6 } optIfOMSnSinkPrevDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power at the output during the previous 24-hour interval." ::= { optIfOMSnSinkPrevDayEntry 7 } -- OMSn source current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOMSnSrcCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OMSn source performance monitoring information for the current 15-minute interval." ::= { optIfOMSn 6 } optIfOMSnSrcCurrentEntry OBJECT-TYPE SYNTAX OptIfOMSnSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn source performance monitoring information of an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOMSnSrcCurrentTable 1 } OptIfOMSnSrcCurrentEntry ::= SEQUENCE { optIfOMSnSrcCurrentSuspectedFlag TruthValue, optIfOMSnSrcCurrentOutputPower Integer32, optIfOMSnSrcCurrentLowOutputPower Integer32, optIfOMSnSrcCurrentHighOutputPower Integer32, optIfOMSnSrcCurrentLowerOutputPowerThreshold Integer32, Lam, et al. Standards Track [Page 71] RFC 3591 Optical Interface Type MIB September 2003 optIfOMSnSrcCurrentUpperOutputPowerThreshold Integer32, optIfOMSnSrcCurrentAggregatedInputPower Integer32, optIfOMSnSrcCurrentLowAggregatedInputPower Integer32, optIfOMSnSrcCurrentHighAggregatedInputPower Integer32, optIfOMSnSrcCurrentLowerInputPowerThreshold Integer32, optIfOMSnSrcCurrentUpperInputPowerThreshold Integer32 } optIfOMSnSrcCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOMSnSrcCurrentEntry 1 } optIfOMSnSrcCurrentOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output." ::= { optIfOMSnSrcCurrentEntry 2 } optIfOMSnSrcCurrentLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 15-minute interval." ::= { optIfOMSnSrcCurrentEntry 3 } optIfOMSnSrcCurrentHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval." ::= { optIfOMSnSrcCurrentEntry 4 } optIfOMSnSrcCurrentLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" Lam, et al. Standards Track [Page 72] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on output power. If optIfOMSnSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSrcCurrentEntry 5 } optIfOMSnSrcCurrentUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If optIfOMSnSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSrcCurrentEntry 6 } optIfOMSnSrcCurrentAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The aggregated optical power at the input." ::= { optIfOMSnSrcCurrentEntry 7 } optIfOMSnSrcCurrentLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power at the input during the current 15-minute interval." ::= { optIfOMSnSrcCurrentEntry 8 } optIfOMSnSrcCurrentHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power at the input during the current 15-minute interval." ::= { optIfOMSnSrcCurrentEntry 9 } Lam, et al. Standards Track [Page 73] RFC 3591 Optical Interface Type MIB September 2003 optIfOMSnSrcCurrentLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on aggregated input power. If optIfOMSnSrcCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSrcCurrentEntry 10 } optIfOMSnSrcCurrentUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on aggregated input power. If optIfOMSnSrcCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOMSnSrcCurrentEntry 11 } -- OMSn source interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOMSnSrcIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of historical OMSn source performance monitoring information." ::= { optIfOMSn 7 } optIfOMSnSrcIntervalEntry OBJECT-TYPE SYNTAX OptIfOMSnSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn source performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOMSnSrcIntervalNumber } ::= { optIfOMSnSrcIntervalTable 1 } OptIfOMSnSrcIntervalEntry ::= Lam, et al. Standards Track [Page 74] RFC 3591 Optical Interface Type MIB September 2003 SEQUENCE { optIfOMSnSrcIntervalNumber OptIfIntervalNumber, optIfOMSnSrcIntervalSuspectedFlag TruthValue, optIfOMSnSrcIntervalLastOutputPower Integer32, optIfOMSnSrcIntervalLowOutputPower Integer32, optIfOMSnSrcIntervalHighOutputPower Integer32, optIfOMSnSrcIntervalLastAggregatedInputPower Integer32, optIfOMSnSrcIntervalLowAggregatedInputPower Integer32, optIfOMSnSrcIntervalHighAggregatedInputPower Integer32 } optIfOMSnSrcIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOMSnSrcIntervalEntry 1 } optIfOMSnSrcIntervalSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOMSnSrcIntervalEntry 2 } optIfOMSnSrcIntervalLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the interval." ::= { optIfOMSnSrcIntervalEntry 3 } optIfOMSnSrcIntervalLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the interval." ::= { optIfOMSnSrcIntervalEntry 4 } optIfOMSnSrcIntervalHighOutputPower OBJECT-TYPE Lam, et al. Standards Track [Page 75] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the interval." ::= { optIfOMSnSrcIntervalEntry 5 } optIfOMSnSrcIntervalLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power at the input during the interval." ::= { optIfOMSnSrcIntervalEntry 6 } optIfOMSnSrcIntervalLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power at the input during the interval." ::= { optIfOMSnSrcIntervalEntry 7 } optIfOMSnSrcIntervalHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power at the input during the interval." ::= { optIfOMSnSrcIntervalEntry 8 } -- OMSn source current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOMSnSrcCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Lam, et al. Standards Track [Page 76] RFC 3591 Optical Interface Type MIB September 2003 "A table of OMSn source performance monitoring information for the current 24-hour interval." ::= { optIfOMSn 8 } optIfOMSnSrcCurDayEntry OBJECT-TYPE SYNTAX OptIfOMSnSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn source performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } ::= { optIfOMSnSrcCurDayTable 1 } OptIfOMSnSrcCurDayEntry ::= SEQUENCE { optIfOMSnSrcCurDaySuspectedFlag TruthValue, optIfOMSnSrcCurDayLowOutputPower Integer32, optIfOMSnSrcCurDayHighOutputPower Integer32, optIfOMSnSrcCurDayLowAggregatedInputPower Integer32, optIfOMSnSrcCurDayHighAggregatedInputPower Integer32 } optIfOMSnSrcCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOMSnSrcCurDayEntry 1 } optIfOMSnSrcCurDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 24-hour interval." ::= { optIfOMSnSrcCurDayEntry 2 } optIfOMSnSrcCurDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION Lam, et al. Standards Track [Page 77] RFC 3591 Optical Interface Type MIB September 2003 "The highest optical power monitored at the output during the current 24-hour interval." ::= { optIfOMSnSrcCurDayEntry 3 } optIfOMSnSrcCurDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power at the input during the current 24-hour interval." ::= { optIfOMSnSrcCurDayEntry 4 } optIfOMSnSrcCurDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power at the input during the current 24-hour interval." ::= { optIfOMSnSrcCurDayEntry 5 } -- OMSn source previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOMSnSrcPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOMSnSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OMSn source performance monitoring information for the previous 24-hour interval." ::= { optIfOMSn 9 } optIfOMSnSrcPrevDayEntry OBJECT-TYPE SYNTAX OptIfOMSnSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OMSn source performance monitoring information of an interface for the previous 24-hour interval." INDEX { ifIndex } ::= { optIfOMSnSrcPrevDayTable 1 } Lam, et al. Standards Track [Page 78] RFC 3591 Optical Interface Type MIB September 2003 OptIfOMSnSrcPrevDayEntry ::= SEQUENCE { optIfOMSnSrcPrevDaySuspectedFlag TruthValue, optIfOMSnSrcPrevDayLastOutputPower Integer32, optIfOMSnSrcPrevDayLowOutputPower Integer32, optIfOMSnSrcPrevDayHighOutputPower Integer32, optIfOMSnSrcPrevDayLastAggregatedInputPower Integer32, optIfOMSnSrcPrevDayLowAggregatedInputPower Integer32, optIfOMSnSrcPrevDayHighAggregatedInputPower Integer32 } optIfOMSnSrcPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOMSnSrcPrevDayEntry 1 } optIfOMSnSrcPrevDayLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the previous 24-hour interval." ::= { optIfOMSnSrcPrevDayEntry 2 } optIfOMSnSrcPrevDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOMSnSrcPrevDayEntry 3 } optIfOMSnSrcPrevDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOMSnSrcPrevDayEntry 4 } Lam, et al. Standards Track [Page 79] RFC 3591 Optical Interface Type MIB September 2003 optIfOMSnSrcPrevDayLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power at the input during the previous 24-hour interval." ::= { optIfOMSnSrcPrevDayEntry 5 } optIfOMSnSrcPrevDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power at the input during the previous 24-hour interval." ::= { optIfOMSnSrcPrevDayEntry 6 } optIfOMSnSrcPrevDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power at the input during the previous 24-hour interval." ::= { optIfOMSnSrcPrevDayEntry 7 } -- the optIfOChGroup group -- This group handles the configuration and performance monitoring -- information for OChGroup layers. -- OChGroup config table optIfOChGroupConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OChGroup configuration information." ::= { optIfOChGroup 1 } optIfOChGroupConfigEntry OBJECT-TYPE SYNTAX OptIfOChGroupConfigEntry MAX-ACCESS not-accessible STATUS current Lam, et al. Standards Track [Page 80] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "A conceptual row that contains OChGroup configuration information of an interface." INDEX { ifIndex } ::= { optIfOChGroupConfigTable 1 } OptIfOChGroupConfigEntry ::= SEQUENCE { optIfOChGroupDirectionality OptIfDirectionality } optIfOChGroupDirectionality OBJECT-TYPE SYNTAX OptIfDirectionality MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the directionality of the entity." ::= { optIfOChGroupConfigEntry 1 } -- OChGroup sink current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOChGroupSinkCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OChGroup sink performance monitoring information for the current 15-minute interval." ::= { optIfOChGroup 2 } optIfOChGroupSinkCurrentEntry OBJECT-TYPE SYNTAX OptIfOChGroupSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup sink performance monitoring information of an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOChGroupSinkCurrentTable 1 } OptIfOChGroupSinkCurrentEntry ::= SEQUENCE { optIfOChGroupSinkCurrentSuspectedFlag TruthValue, optIfOChGroupSinkCurrentAggregatedInputPower Integer32, optIfOChGroupSinkCurrentLowAggregatedInputPower Integer32, Lam, et al. Standards Track [Page 81] RFC 3591 Optical Interface Type MIB September 2003 optIfOChGroupSinkCurrentHighAggregatedInputPower Integer32, optIfOChGroupSinkCurrentLowerInputPowerThreshold Integer32, optIfOChGroupSinkCurrentUpperInputPowerThreshold Integer32, optIfOChGroupSinkCurrentOutputPower Integer32, optIfOChGroupSinkCurrentLowOutputPower Integer32, optIfOChGroupSinkCurrentHighOutputPower Integer32, optIfOChGroupSinkCurrentLowerOutputPowerThreshold Integer32, optIfOChGroupSinkCurrentUpperOutputPowerThreshold Integer32 } optIfOChGroupSinkCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSinkCurrentEntry 1 } optIfOChGroupSinkCurrentAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The aggregated optical power of all the DWDM input channels in the OChGroup." ::= { optIfOChGroupSinkCurrentEntry 2 } optIfOChGroupSinkCurrentLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the current 15-minute interval." ::= { optIfOChGroupSinkCurrentEntry 3 } optIfOChGroupSinkCurrentHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power of all the DWDM input channels in the OChGroup during the current 15-minute interval." ::= { optIfOChGroupSinkCurrentEntry 4 } Lam, et al. Standards Track [Page 82] RFC 3591 Optical Interface Type MIB September 2003 optIfOChGroupSinkCurrentLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on aggregated input power. If optIfOChGroupSinkCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSinkCurrentEntry 5 } optIfOChGroupSinkCurrentUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on aggregated input power. If optIfOChGroupSinkCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSinkCurrentEntry 6 } optIfOChGroupSinkCurrentOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output in the OChGroup." ::= { optIfOChGroupSinkCurrentEntry 7 } optIfOChGroupSinkCurrentLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output in the OChGroup during the current 15-minute interval." ::= { optIfOChGroupSinkCurrentEntry 8 } optIfOChGroupSinkCurrentHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION Lam, et al. Standards Track [Page 83] RFC 3591 Optical Interface Type MIB September 2003 "The highest optical power monitored at the output in the OChGroup during the current 15-minute interval." ::= { optIfOChGroupSinkCurrentEntry 9 } optIfOChGroupSinkCurrentLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on the output power. If optIfOChGroupSinkCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSinkCurrentEntry 10 } optIfOChGroupSinkCurrentUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on the output power. If optIfOChGroupSinkCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSinkCurrentEntry 11 } -- OChGroup sink interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOChGroupSinkIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of historical OChGroup sink performance monitoring information." ::= { optIfOChGroup 3 } optIfOChGroupSinkIntervalEntry OBJECT-TYPE SYNTAX OptIfOChGroupSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup sink performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOChGroupSinkIntervalNumber } Lam, et al. Standards Track [Page 84] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOChGroupSinkIntervalTable 1 } OptIfOChGroupSinkIntervalEntry ::= SEQUENCE { optIfOChGroupSinkIntervalNumber OptIfIntervalNumber, optIfOChGroupSinkIntervalSuspectedFlag TruthValue, optIfOChGroupSinkIntervalLastAggregatedInputPower Integer32, optIfOChGroupSinkIntervalLowAggregatedInputPower Integer32, optIfOChGroupSinkIntervalHighAggregatedInputPower Integer32, optIfOChGroupSinkIntervalLastOutputPower Integer32, optIfOChGroupSinkIntervalLowOutputPower Integer32, optIfOChGroupSinkIntervalHighOutputPower Integer32 } optIfOChGroupSinkIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOChGroupSinkIntervalEntry 1 } optIfOChGroupSinkIntervalSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSinkIntervalEntry 2 } optIfOChGroupSinkIntervalLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power of all the DWDM input channels in the OChGroup during the interval." ::= { optIfOChGroupSinkIntervalEntry 3 } optIfOChGroupSinkIntervalLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the interval." Lam, et al. Standards Track [Page 85] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOChGroupSinkIntervalEntry 4 } optIfOChGroupSinkIntervalHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power of all the DWDM input channels in the OChGroup during the interval." ::= { optIfOChGroupSinkIntervalEntry 5 } optIfOChGroupSinkIntervalLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output in the OChGroup during the interval." ::= { optIfOChGroupSinkIntervalEntry 6 } optIfOChGroupSinkIntervalLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output in the OChGroup during the interval." ::= { optIfOChGroupSinkIntervalEntry 7 } optIfOChGroupSinkIntervalHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output in the OChGroup during the interval." ::= { optIfOChGroupSinkIntervalEntry 8 } -- OChGroup sink current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOChGroupSinkCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSinkCurDayEntry Lam, et al. Standards Track [Page 86] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OChGroup sink performance monitoring information for the current 24-hour interval." ::= { optIfOChGroup 4 } optIfOChGroupSinkCurDayEntry OBJECT-TYPE SYNTAX OptIfOChGroupSinkCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup sink performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } ::= { optIfOChGroupSinkCurDayTable 1 } OptIfOChGroupSinkCurDayEntry ::= SEQUENCE { optIfOChGroupSinkCurDaySuspectedFlag TruthValue, optIfOChGroupSinkCurDayLowAggregatedInputPower Integer32, optIfOChGroupSinkCurDayHighAggregatedInputPower Integer32, optIfOChGroupSinkCurDayLowOutputPower Integer32, optIfOChGroupSinkCurDayHighOutputPower Integer32 } optIfOChGroupSinkCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSinkCurDayEntry 1 } optIfOChGroupSinkCurDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the current 24-hour interval." ::= { optIfOChGroupSinkCurDayEntry 2 } optIfOChGroupSinkCurDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" Lam, et al. Standards Track [Page 87] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power of all the DWDM input channels in the OChGroup during the current 24-hour interval." ::= { optIfOChGroupSinkCurDayEntry 3 } optIfOChGroupSinkCurDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output in the OChGroup during the current 24-hour interval." ::= { optIfOChGroupSinkCurDayEntry 4 } optIfOChGroupSinkCurDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output in the OChGroup during the current 24-hour interval." ::= { optIfOChGroupSinkCurDayEntry 5 } -- OChGroup sink previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOChGroupSinkPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OChGroup sink performance monitoring information for the previous 24-hour interval." ::= { optIfOChGroup 5 } optIfOChGroupSinkPrevDayEntry OBJECT-TYPE SYNTAX OptIfOChGroupSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup sink performance monitoring information of an interface for the previous 24-hour interval." Lam, et al. Standards Track [Page 88] RFC 3591 Optical Interface Type MIB September 2003 INDEX { ifIndex } ::= { optIfOChGroupSinkPrevDayTable 1 } OptIfOChGroupSinkPrevDayEntry ::= SEQUENCE { optIfOChGroupSinkPrevDaySuspectedFlag TruthValue, optIfOChGroupSinkPrevDayLastAggregatedInputPower Integer32, optIfOChGroupSinkPrevDayLowAggregatedInputPower Integer32, optIfOChGroupSinkPrevDayHighAggregatedInputPower Integer32, optIfOChGroupSinkPrevDayLastOutputPower Integer32, optIfOChGroupSinkPrevDayLowOutputPower Integer32, optIfOChGroupSinkPrevDayHighOutputPower Integer32 } optIfOChGroupSinkPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSinkPrevDayEntry 1 } optIfOChGroupSinkPrevDayLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power of all the DWDM input channels in the OChGroup during the previous 24-hour interval." ::= { optIfOChGroupSinkPrevDayEntry 2 } optIfOChGroupSinkPrevDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power of all the DWDM input channels in the OChGroup during the previous 24-hour interval." ::= { optIfOChGroupSinkPrevDayEntry 3 } optIfOChGroupSinkPrevDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION Lam, et al. Standards Track [Page 89] RFC 3591 Optical Interface Type MIB September 2003 "The highest aggregated optical power of all the DWDM input channels in the OChGroup during the previous 24-hour interval." ::= { optIfOChGroupSinkPrevDayEntry 4 } optIfOChGroupSinkPrevDayLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output in the OChGroup during the previous 24-hour interval." ::= { optIfOChGroupSinkPrevDayEntry 5 } optIfOChGroupSinkPrevDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output in the OChGroup during the previous 24-hour interval." ::= { optIfOChGroupSinkPrevDayEntry 6 } optIfOChGroupSinkPrevDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output in the OChGroup during the previous 24-hour interval." ::= { optIfOChGroupSinkPrevDayEntry 7 } -- OChGroup source current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOChGroupSrcCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OChGroup source performance monitoring information for the current 15-minute interval." ::= { optIfOChGroup 6 } optIfOChGroupSrcCurrentEntry OBJECT-TYPE Lam, et al. Standards Track [Page 90] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX OptIfOChGroupSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup source performance monitoring information of an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOChGroupSrcCurrentTable 1 } OptIfOChGroupSrcCurrentEntry ::= SEQUENCE { optIfOChGroupSrcCurrentSuspectedFlag TruthValue, optIfOChGroupSrcCurrentOutputPower Integer32, optIfOChGroupSrcCurrentLowOutputPower Integer32, optIfOChGroupSrcCurrentHighOutputPower Integer32, optIfOChGroupSrcCurrentLowerOutputPowerThreshold Integer32, optIfOChGroupSrcCurrentUpperOutputPowerThreshold Integer32, optIfOChGroupSrcCurrentAggregatedInputPower Integer32, optIfOChGroupSrcCurrentLowAggregatedInputPower Integer32, optIfOChGroupSrcCurrentHighAggregatedInputPower Integer32, optIfOChGroupSrcCurrentLowerInputPowerThreshold Integer32, optIfOChGroupSrcCurrentUpperInputPowerThreshold Integer32 } optIfOChGroupSrcCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSrcCurrentEntry 1 } optIfOChGroupSrcCurrentOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output." ::= { optIfOChGroupSrcCurrentEntry 2 } optIfOChGroupSrcCurrentLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION Lam, et al. Standards Track [Page 91] RFC 3591 Optical Interface Type MIB September 2003 "The lowest optical power monitored at the output during the current 15-minute interval." ::= { optIfOChGroupSrcCurrentEntry 3 } optIfOChGroupSrcCurrentHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval." ::= { optIfOChGroupSrcCurrentEntry 4 } optIfOChGroupSrcCurrentLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on output power. If optIfOChGroupSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSrcCurrentEntry 5 } optIfOChGroupSrcCurrentUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If optIfOChGroupSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSrcCurrentEntry 6 } optIfOChGroupSrcCurrentAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The aggregated optical power monitored at the input." ::= { optIfOChGroupSrcCurrentEntry 7 } optIfOChGroupSrcCurrentLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" Lam, et al. Standards Track [Page 92] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power monitored at the input during the current 15-minute interval." ::= { optIfOChGroupSrcCurrentEntry 8 } optIfOChGroupSrcCurrentHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power monitored at the input during the current 15-minute interval." ::= { optIfOChGroupSrcCurrentEntry 9 } optIfOChGroupSrcCurrentLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on input power. If optIfOChGroupSrcCurrentAggregatedInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSrcCurrentEntry 10 } optIfOChGroupSrcCurrentUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on input power. If optIfOChGroupSrcCurrentAggregatedInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChGroupSrcCurrentEntry 11 } -- OChGroup source interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOChGroupSrcIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Lam, et al. Standards Track [Page 93] RFC 3591 Optical Interface Type MIB September 2003 "A table of historical OChGroup source performance monitoring information." ::= { optIfOChGroup 7 } optIfOChGroupSrcIntervalEntry OBJECT-TYPE SYNTAX OptIfOChGroupSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup source performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOChGroupSrcIntervalNumber } ::= { optIfOChGroupSrcIntervalTable 1 } OptIfOChGroupSrcIntervalEntry ::= SEQUENCE { optIfOChGroupSrcIntervalNumber OptIfIntervalNumber, optIfOChGroupSrcIntervalSuspectedFlag TruthValue, optIfOChGroupSrcIntervalLastOutputPower Integer32, optIfOChGroupSrcIntervalLowOutputPower Integer32, optIfOChGroupSrcIntervalHighOutputPower Integer32, optIfOChGroupSrcIntervalLastAggregatedInputPower Integer32, optIfOChGroupSrcIntervalLowAggregatedInputPower Integer32, optIfOChGroupSrcIntervalHighAggregatedInputPower Integer32 } optIfOChGroupSrcIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOChGroupSrcIntervalEntry 1 } optIfOChGroupSrcIntervalSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSrcIntervalEntry 2 } optIfOChGroupSrcIntervalLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current Lam, et al. Standards Track [Page 94] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "The last optical power monitored at the output during the interval." ::= { optIfOChGroupSrcIntervalEntry 3 } optIfOChGroupSrcIntervalLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the interval." ::= { optIfOChGroupSrcIntervalEntry 4 } optIfOChGroupSrcIntervalHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the interval." ::= { optIfOChGroupSrcIntervalEntry 5 } optIfOChGroupSrcIntervalLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power monitored at the input during the interval." ::= { optIfOChGroupSrcIntervalEntry 6 } optIfOChGroupSrcIntervalLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power monitored at the input during the interval." ::= { optIfOChGroupSrcIntervalEntry 7 } optIfOChGroupSrcIntervalHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" Lam, et al. Standards Track [Page 95] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power monitored at the input during the interval." ::= { optIfOChGroupSrcIntervalEntry 8 } -- OChGroup source current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOChGroupSrcCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OChGroup source performance monitoring information for the current 24-hour interval." ::= { optIfOChGroup 8 } optIfOChGroupSrcCurDayEntry OBJECT-TYPE SYNTAX OptIfOChGroupSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup source performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } ::= { optIfOChGroupSrcCurDayTable 1 } OptIfOChGroupSrcCurDayEntry ::= SEQUENCE { optIfOChGroupSrcCurDaySuspectedFlag TruthValue, optIfOChGroupSrcCurDayLowOutputPower Integer32, optIfOChGroupSrcCurDayHighOutputPower Integer32, optIfOChGroupSrcCurDayLowAggregatedInputPower Integer32, optIfOChGroupSrcCurDayHighAggregatedInputPower Integer32 } optIfOChGroupSrcCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSrcCurDayEntry 1 } Lam, et al. Standards Track [Page 96] RFC 3591 Optical Interface Type MIB September 2003 optIfOChGroupSrcCurDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 24-hour interval." ::= { optIfOChGroupSrcCurDayEntry 2 } optIfOChGroupSrcCurDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 24-hour interval." ::= { optIfOChGroupSrcCurDayEntry 3 } optIfOChGroupSrcCurDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power monitored at the input during the current 24-hour interval." ::= { optIfOChGroupSrcCurDayEntry 4 } optIfOChGroupSrcCurDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power monitored at the input during the current 24-hour interval." ::= { optIfOChGroupSrcCurDayEntry 5 } -- OChGroup source previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOChGroupSrcPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChGroupSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current Lam, et al. Standards Track [Page 97] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "A table of OChGroup source performance monitoring information for the previous 24-hour interval." ::= { optIfOChGroup 9 } optIfOChGroupSrcPrevDayEntry OBJECT-TYPE SYNTAX OptIfOChGroupSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OChGroup source performance monitoring information of an interface for the previous 24-hour interval." INDEX { ifIndex } ::= { optIfOChGroupSrcPrevDayTable 1 } OptIfOChGroupSrcPrevDayEntry ::= SEQUENCE { optIfOChGroupSrcPrevDaySuspectedFlag TruthValue, optIfOChGroupSrcPrevDayLastOutputPower Integer32, optIfOChGroupSrcPrevDayLowOutputPower Integer32, optIfOChGroupSrcPrevDayHighOutputPower Integer32, optIfOChGroupSrcPrevDayLastAggregatedInputPower Integer32, optIfOChGroupSrcPrevDayLowAggregatedInputPower Integer32, optIfOChGroupSrcPrevDayHighAggregatedInputPower Integer32 } optIfOChGroupSrcPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChGroupSrcPrevDayEntry 1 } optIfOChGroupSrcPrevDayLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the previous 24-hour interval." ::= { optIfOChGroupSrcPrevDayEntry 2 } optIfOChGroupSrcPrevDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" Lam, et al. Standards Track [Page 98] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOChGroupSrcPrevDayEntry 3 } optIfOChGroupSrcPrevDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOChGroupSrcPrevDayEntry 4 } optIfOChGroupSrcPrevDayLastAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last aggregated optical power monitored at the input during the previous 24-hour interval." ::= { optIfOChGroupSrcPrevDayEntry 5 } optIfOChGroupSrcPrevDayLowAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest aggregated optical power monitored at the input during the previous 24-hour interval." ::= { optIfOChGroupSrcPrevDayEntry 6 } optIfOChGroupSrcPrevDayHighAggregatedInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest aggregated optical power monitored at the input during the previous 24-hour interval." ::= { optIfOChGroupSrcPrevDayEntry 7 } -- the optIfOCh group Lam, et al. Standards Track [Page 99] RFC 3591 Optical Interface Type MIB September 2003 -- This group handles the configuration and -- performance monitoring information for OCh layers. -- OCh config table optIfOChConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OCh configuration information." ::= { optIfOCh 1 } optIfOChConfigEntry OBJECT-TYPE SYNTAX OptIfOChConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh configuration information of an interface." INDEX { ifIndex } ::= { optIfOChConfigTable 1 } OptIfOChConfigEntry ::= SEQUENCE { optIfOChDirectionality OptIfDirectionality, optIfOChCurrentStatus BITS } optIfOChDirectionality OBJECT-TYPE SYNTAX OptIfDirectionality MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the directionality of the entity." ::= { optIfOChConfigEntry 1 } optIfOChCurrentStatus OBJECT-TYPE SYNTAX BITS { losP(0), los(1), oci(2), ssfP(3), ssfO(4), ssf(5) } MAX-ACCESS read-only STATUS current Lam, et al. Standards Track [Page 100] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "Indicates the defect condition of the entity, if any. This object is applicable when optIfOChDirectionality has the value sink(1) or bidirectional(3). In full-capability systems the bit position los(1) is not used. In reduced-capability systems or at IrDI interfaces only the bit positions los(1) and ssfP(3) are used." ::= { optIfOChConfigEntry 2 } -- OCh sink current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOChSinkCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OCh sink performance monitoring information for the current 15-minute interval." ::= { optIfOCh 2 } optIfOChSinkCurrentEntry OBJECT-TYPE SYNTAX OptIfOChSinkCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh sink performance monitoring information for an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOChSinkCurrentTable 1 } OptIfOChSinkCurrentEntry ::= SEQUENCE { optIfOChSinkCurrentSuspectedFlag TruthValue, optIfOChSinkCurrentInputPower Integer32, optIfOChSinkCurrentLowInputPower Integer32, optIfOChSinkCurrentHighInputPower Integer32, optIfOChSinkCurrentLowerInputPowerThreshold Integer32, optIfOChSinkCurrentUpperInputPowerThreshold Integer32 } optIfOChSinkCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Lam, et al. Standards Track [Page 101] RFC 3591 Optical Interface Type MIB September 2003 "If true, the data in this entry may be unreliable." ::= { optIfOChSinkCurrentEntry 1 } optIfOChSinkCurrentInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the input." ::= { optIfOChSinkCurrentEntry 2 } optIfOChSinkCurrentLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the current 15-minute interval." ::= { optIfOChSinkCurrentEntry 3 } optIfOChSinkCurrentHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the current 15-minute interval." ::= { optIfOChSinkCurrentEntry 4 } optIfOChSinkCurrentLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on input power. If optIfOChSinkCurrentInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChSinkCurrentEntry 5 } optIfOChSinkCurrentUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current Lam, et al. Standards Track [Page 102] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "The upper limit threshold on input power. If optIfOChSinkCurrentInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChSinkCurrentEntry 6 } -- OCh sink interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOChSinkIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of historical OCh sink performance monitoring information." ::= { optIfOCh 3 } optIfOChSinkIntervalEntry OBJECT-TYPE SYNTAX OptIfOChSinkIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh sink performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOChSinkIntervalNumber } ::= { optIfOChSinkIntervalTable 1 } OptIfOChSinkIntervalEntry ::= SEQUENCE { optIfOChSinkIntervalNumber OptIfIntervalNumber, optIfOChSinkIntervalSuspectedFlag TruthValue, optIfOChSinkIntervalLastInputPower Integer32, optIfOChSinkIntervalLowInputPower Integer32, optIfOChSinkIntervalHighInputPower Integer32 } optIfOChSinkIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOChSinkIntervalEntry 1 } optIfOChSinkIntervalSuspectedFlag OBJECT-TYPE Lam, et al. Standards Track [Page 103] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChSinkIntervalEntry 2 } optIfOChSinkIntervalLastInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the input during the interval." ::= { optIfOChSinkIntervalEntry 3 } optIfOChSinkIntervalLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the interval." ::= { optIfOChSinkIntervalEntry 4 } optIfOChSinkIntervalHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the interval." ::= { optIfOChSinkIntervalEntry 5 } -- OCh sink current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOChSinkCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSinkCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OCh sink performance monitoring information for the current 24-hour interval." Lam, et al. Standards Track [Page 104] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOCh 4 } optIfOChSinkCurDayEntry OBJECT-TYPE SYNTAX OptIfOChSinkCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh sink performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } ::= { optIfOChSinkCurDayTable 1 } OptIfOChSinkCurDayEntry ::= SEQUENCE { optIfOChSinkCurDaySuspectedFlag TruthValue, optIfOChSinkCurDayLowInputPower Integer32, optIfOChSinkCurDayHighInputPower Integer32 } optIfOChSinkCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChSinkCurDayEntry 1 } optIfOChSinkCurDayLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the current 24-hour interval." ::= { optIfOChSinkCurDayEntry 2 } optIfOChSinkCurDayHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the current 24-hour interval." ::= { optIfOChSinkCurDayEntry 3 } Lam, et al. Standards Track [Page 105] RFC 3591 Optical Interface Type MIB September 2003 -- OCh sink previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOChSinkPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OCh sink performance monitoring information for the previous 24-hour interval." ::= { optIfOCh 5 } optIfOChSinkPrevDayEntry OBJECT-TYPE SYNTAX OptIfOChSinkPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh sink performance monitoring information of an interface for the previous 24-hour interval." INDEX { ifIndex } ::= { optIfOChSinkPrevDayTable 1 } OptIfOChSinkPrevDayEntry ::= SEQUENCE { optIfOChSinkPrevDaySuspectedFlag TruthValue, optIfOChSinkPrevDayLastInputPower Integer32, optIfOChSinkPrevDayLowInputPower Integer32, optIfOChSinkPrevDayHighInputPower Integer32 } optIfOChSinkPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChSinkPrevDayEntry 1 } optIfOChSinkPrevDayLastInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the input during the previous 24-hour interval." Lam, et al. Standards Track [Page 106] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOChSinkPrevDayEntry 2 } optIfOChSinkPrevDayLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the previous 24-hour interval." ::= { optIfOChSinkPrevDayEntry 3 } optIfOChSinkPrevDayHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the previous 24-hour interval." ::= { optIfOChSinkPrevDayEntry 4 } -- OCh source current table -- Contains data for the current 15-minute performance monitoring -- interval. optIfOChSrcCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OCh source performance monitoring information for the current 15-minute interval." ::= { optIfOCh 6 } optIfOChSrcCurrentEntry OBJECT-TYPE SYNTAX OptIfOChSrcCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh source performance monitoring information of an interface for the current 15-minute interval." INDEX { ifIndex } ::= { optIfOChSrcCurrentTable 1 } OptIfOChSrcCurrentEntry ::= SEQUENCE { Lam, et al. Standards Track [Page 107] RFC 3591 Optical Interface Type MIB September 2003 optIfOChSrcCurrentSuspectedFlag TruthValue, optIfOChSrcCurrentOutputPower Integer32, optIfOChSrcCurrentLowOutputPower Integer32, optIfOChSrcCurrentHighOutputPower Integer32, optIfOChSrcCurrentLowerOutputPowerThreshold Integer32, optIfOChSrcCurrentUpperOutputPowerThreshold Integer32 } optIfOChSrcCurrentSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChSrcCurrentEntry 1 } optIfOChSrcCurrentOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output." ::= { optIfOChSrcCurrentEntry 2 } optIfOChSrcCurrentLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 15-minute interval." ::= { optIfOChSrcCurrentEntry 3 } optIfOChSrcCurrentHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval." ::= { optIfOChSrcCurrentEntry 4 } optIfOChSrcCurrentLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" Lam, et al. Standards Track [Page 108] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on output power. If optIfOChSrcCurrentOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChSrcCurrentEntry 5 } optIfOChSrcCurrentUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If optIfOChSrcCurrentOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent." ::= { optIfOChSrcCurrentEntry 6 } -- OCh source interval table -- Contains data for previous 15-minute performance monitoring -- intervals. optIfOChSrcIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of historical OCh source performance monitoring information." ::= { optIfOCh 7 } optIfOChSrcIntervalEntry OBJECT-TYPE SYNTAX OptIfOChSrcIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh source performance monitoring information of an interface during a particular historical interval." INDEX { ifIndex, optIfOChSrcIntervalNumber } ::= { optIfOChSrcIntervalTable 1 } OptIfOChSrcIntervalEntry ::= SEQUENCE { optIfOChSrcIntervalNumber OptIfIntervalNumber, optIfOChSrcIntervalSuspectedFlag TruthValue, optIfOChSrcIntervalLastOutputPower Integer32, Lam, et al. Standards Track [Page 109] RFC 3591 Optical Interface Type MIB September 2003 optIfOChSrcIntervalLowOutputPower Integer32, optIfOChSrcIntervalHighOutputPower Integer32 } optIfOChSrcIntervalNumber OBJECT-TYPE SYNTAX OptIfIntervalNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies the interval." ::= { optIfOChSrcIntervalEntry 1 } optIfOChSrcIntervalSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChSrcIntervalEntry 2 } optIfOChSrcIntervalLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the interval." ::= { optIfOChSrcIntervalEntry 3 } optIfOChSrcIntervalLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the interval." ::= { optIfOChSrcIntervalEntry 4 } optIfOChSrcIntervalHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the interval." Lam, et al. Standards Track [Page 110] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfOChSrcIntervalEntry 5 } -- OCh source current day table -- Contains data for the current 24-hour performance -- monitoring interval. optIfOChSrcCurDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OCh source performance monitoring information for the current 24-hour interval." ::= { optIfOCh 8 } optIfOChSrcCurDayEntry OBJECT-TYPE SYNTAX OptIfOChSrcCurDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh source performance monitoring information of an interface for the current 24-hour interval." INDEX { ifIndex } ::= { optIfOChSrcCurDayTable 1 } OptIfOChSrcCurDayEntry ::= SEQUENCE { optIfOChSrcCurDaySuspectedFlag TruthValue, optIfOChSrcCurDayLowOutputPower Integer32, optIfOChSrcCurDayHighOutputPower Integer32 } optIfOChSrcCurDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChSrcCurDayEntry 1 } optIfOChSrcCurDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the Lam, et al. Standards Track [Page 111] RFC 3591 Optical Interface Type MIB September 2003 current 24-hour interval." ::= { optIfOChSrcCurDayEntry 2 } optIfOChSrcCurDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 24-hour interval." ::= { optIfOChSrcCurDayEntry 3 } -- OCh source previous day table -- Contains data for the previous 24-hour performance -- monitoring interval. optIfOChSrcPrevDayTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOChSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OCh source performance monitoring information for the previous 24-hour interval." ::= { optIfOCh 9 } optIfOChSrcPrevDayEntry OBJECT-TYPE SYNTAX OptIfOChSrcPrevDayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OCh source performance monitoring information of an interface for the previous 24-hour interval." INDEX { ifIndex } ::= { optIfOChSrcPrevDayTable 1 } OptIfOChSrcPrevDayEntry ::= SEQUENCE { optIfOChSrcPrevDaySuspectedFlag TruthValue, optIfOChSrcPrevDayLastOutputPower Integer32, optIfOChSrcPrevDayLowOutputPower Integer32, optIfOChSrcPrevDayHighOutputPower Integer32 } optIfOChSrcPrevDaySuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only Lam, et al. Standards Track [Page 112] RFC 3591 Optical Interface Type MIB September 2003 STATUS current DESCRIPTION "If true, the data in this entry may be unreliable." ::= { optIfOChSrcPrevDayEntry 1 } optIfOChSrcPrevDayLastOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The last optical power monitored at the output during the previous 24-hour interval." ::= { optIfOChSrcPrevDayEntry 2 } optIfOChSrcPrevDayLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOChSrcPrevDayEntry 3 } optIfOChSrcPrevDayHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the previous 24-hour interval." ::= { optIfOChSrcPrevDayEntry 4 } -- the optIfOTUk group -- This group handles the configuration -- information for OTUk layers. -- OTUk config table optIfOTUkConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfOTUkConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of OTUk configuration information." ::= { optIfOTUk 1 } Lam, et al. Standards Track [Page 113] RFC 3591 Optical Interface Type MIB September 2003 optIfOTUkConfigEntry OBJECT-TYPE SYNTAX OptIfOTUkConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains OTUk configuration information of an interface." INDEX { ifIndex } ::= { optIfOTUkConfigTable 1 } OptIfOTUkConfigEntry ::= SEQUENCE { optIfOTUkDirectionality OptIfDirectionality, optIfOTUkBitRateK OptIfBitRateK, optIfOTUkTraceIdentifierTransmitted OptIfTxTI, optIfOTUkDAPIExpected OptIfExDAPI, optIfOTUkSAPIExpected OptIfExSAPI, optIfOTUkTraceIdentifierAccepted OptIfAcTI, optIfOTUkTIMDetMode OptIfTIMDetMode, optIfOTUkTIMActEnabled TruthValue, optIfOTUkDEGThr OptIfDEGThr, optIfOTUkDEGM OptIfDEGM, optIfOTUkSinkAdaptActive TruthValue, optIfOTUkSourceAdaptActive TruthValue, optIfOTUkSinkFECEnabled TruthValue, optIfOTUkCurrentStatus BITS } optIfOTUkDirectionality OBJECT-TYPE SYNTAX OptIfDirectionality MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the directionality of the entity." ::= { optIfOTUkConfigEntry 1 } optIfOTUkBitRateK OBJECT-TYPE SYNTAX OptIfBitRateK MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the bit rate of the entity." ::= { optIfOTUkConfigEntry 2 } optIfOTUkTraceIdentifierTransmitted OBJECT-TYPE SYNTAX OptIfTxTI MAX-ACCESS read-write STATUS current Lam, et al. Standards Track [Page 114] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "The trace identifier transmitted. This object is applicable when optIfOTUkDirectionality has the value source(2) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value sink(1). If no value is ever set by a management entity for this object, system-specific default value will be used. Any implementation that instantiates this object must document the system-specific default value or how it is derived." ::= { optIfOTUkConfigEntry 3 } optIfOTUkDAPIExpected OBJECT-TYPE SYNTAX OptIfExDAPI MAX-ACCESS read-write STATUS current DESCRIPTION "The DAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). This object has no effect when optIfOTUkTIMDetMode has the value off(1)." ::= { optIfOTUkConfigEntry 4 } optIfOTUkSAPIExpected OBJECT-TYPE SYNTAX OptIfExSAPI MAX-ACCESS read-write STATUS current DESCRIPTION "The SAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). This object has no effect when optIfOTUkTIMDetMode has the value off(1)." ::= { optIfOTUkConfigEntry 5 } optIfOTUkTraceIdentifierAccepted OBJECT-TYPE SYNTAX OptIfAcTI MAX-ACCESS read-only STATUS current DESCRIPTION "The actual trace identifier accepted. This object is only applicable to the sink function, i.e., Lam, et al. Standards Track [Page 115] RFC 3591 Optical Interface Type MIB September 2003 only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The value of this object is unspecified when optIfOTUkCurrentStatus indicates a near-end defect (i.e., ssf(3), lof(4), ais(5), lom(6)) that prevents extraction of the trace message." ::= { optIfOTUkConfigEntry 6 } optIfOTUkTIMDetMode OBJECT-TYPE SYNTAX OptIfTIMDetMode MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is off(1)." ::= { optIfOTUkConfigEntry 7 } optIfOTUkTIMActEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). This object has no effect when optIfOTUkTIMDetMode has the value off(1). The default value of this object is false(2)." ::= { optIfOTUkConfigEntry 8 } optIfOTUkDEGThr OBJECT-TYPE SYNTAX OptIfDEGThr UNITS "percentage" MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is Lam, et al. Standards Track [Page 116] RFC 3591 Optical Interface Type MIB September 2003 greater than or equal to optIfOTUkDEGThr. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is Severely Errored Second (SES) Estimator (See ITU-T G.7710)." ::= { optIfOTUkConfigEntry 9 } optIfOTUkDEGM OBJECT-TYPE SYNTAX OptIfDEGM MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfOTUkDEGM consecutive bad PM Seconds are detected. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is 7 (See ITU-T G.7710)." ::= { optIfOTUkConfigEntry 10 } optIfOTUkSinkAdaptActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the sink adaptation function is activated or not. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is false(2)." ::= { optIfOTUkConfigEntry 11 } optIfOTUkSourceAdaptActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the source adaptation function is activated or not. This object is only applicable to the source function, i.e., only when optIfOTUkDirectionality has the value source(2) or bidirectional(3). It must not be instantiated in rows Lam, et al. Standards Track [Page 117] RFC 3591 Optical Interface Type MIB September 2003 where optIfOTUkDirectionality has the value sink(1). The default value of this object is false(2)." ::= { optIfOTUkConfigEntry 12 } optIfOTUkSinkFECEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If Forward Error Correction (FEC) is supported, this object indicates whether FEC at the OTUk sink adaptation function is enabled or not. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2). The default value of this object is true(1)." ::= { optIfOTUkConfigEntry 13 } optIfOTUkCurrentStatus OBJECT-TYPE SYNTAX BITS { tim(0), deg(1), bdi(2), ssf(3), lof(4), ais(5), lom(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the defect condition of the entity, if any. This object is only applicable to the sink function, i.e., only when optIfOTUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfOTUkDirectionality has the value source(2)." ::= { optIfOTUkConfigEntry 14 } -- GCC0 config table optIfGCC0ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfGCC0ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of GCC0 configuration information." ::= { optIfOTUk 2 } Lam, et al. Standards Track [Page 118] RFC 3591 Optical Interface Type MIB September 2003 optIfGCC0ConfigEntry OBJECT-TYPE SYNTAX OptIfGCC0ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains GCC0 configuration information of an interface. Each instance must correspond to an instance of optIfOTUkConfigEntry. Separate source and/or sink instances may exist for a given ifIndex value, or a single bidirectional instance may exist, but a bidirectional instance may not coexist with a source or sink instance. Instances of this conceptual row persist across agent restarts." INDEX { ifIndex, optIfGCC0Directionality } ::= { optIfGCC0ConfigTable 1 } OptIfGCC0ConfigEntry ::= SEQUENCE { optIfGCC0Directionality OptIfDirectionality, optIfGCC0Application SnmpAdminString, optIfGCC0RowStatus RowStatus } optIfGCC0Directionality OBJECT-TYPE SYNTAX OptIfDirectionality MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the directionality of the entity. The values source(2) and bidirectional(3) are not allowed if the corresponding instance of optIfOTUkDirectionality has the value sink(1). The values sink(1) and bidirectional(3) are not allowed if the corresponding instance of optIfOTUkDirectionality has the value source(2)." ::= { optIfGCC0ConfigEntry 1 } optIfGCC0Application OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the application transported by the GCC0 entity. Example applications are ECC, User data channel. The value of this object may not be changed when optIfGCC0RowStatus has the value active(1)." Lam, et al. Standards Track [Page 119] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfGCC0ConfigEntry 2 } optIfGCC0RowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This columnar object is used for creating and deleting a conceptual row of the optIfGCC0 config table. It is used to model the addGCC0Access and removeGCC0Access operations of an OTUk_TTP for GCC0 access control as defined in G.874.1. Setting RowStatus to createAndGo or createAndWait implies addGCC0Access. Setting RowStatus to destroy implies removeGCC0Access." ::= { optIfGCC0ConfigEntry 3 } -- the optIfODUk group -- This group handles the configuration information -- for the ODUk layers. -- ODUk config table optIfODUkConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfODUkConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ODUk configuration information." ::= { optIfODUk 1 } optIfODUkConfigEntry OBJECT-TYPE SYNTAX OptIfODUkConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains ODUk configuration information of an interface." INDEX { ifIndex } ::= { optIfODUkConfigTable 1 } OptIfODUkConfigEntry ::= SEQUENCE { optIfODUkDirectionality OptIfDirectionality, optIfODUkBitRateK OptIfBitRateK, optIfODUkTcmFieldsInUse BITS, optIfODUkPositionSeqCurrentSize Unsigned32, optIfODUkTtpPresent TruthValue } Lam, et al. Standards Track [Page 120] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkDirectionality OBJECT-TYPE SYNTAX OptIfDirectionality MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the directionality of the entity." ::= { optIfODUkConfigEntry 1 } optIfODUkBitRateK OBJECT-TYPE SYNTAX OptIfBitRateK MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the bit rate of the entity." ::= { optIfODUkConfigEntry 2 } optIfODUkTcmFieldsInUse OBJECT-TYPE SYNTAX BITS { tcmField1(0), tcmField2(1), tcmField3(2), tcmField4(3), tcmField5(4), tcmField6(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the TCM field(s) that are currently in use. The positions of the bits correspond to the TCM fields. A bit that is set to 1 means that the corresponding TCM field is used. This object will be updated when rows are created in or deleted from the optIfODUkTConfigTable, or the optIfODUkTNimConfigTable." ::= { optIfODUkConfigEntry 3 } optIfODUkPositionSeqCurrentSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the current size of the position sequence (i.e., number of TCM function and/or GCC12 access that have been created in the ODUk interface). When the value of this variable is greater than zero, it means that one or more TCM function and/or GCC12 access have been created in the ODUk interface. In this case, there will be as many rows in the Lam, et al. Standards Track [Page 121] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkPositionSeqTable as the value of optIfODUkPositionSeqCurrentSize corresponding to this ODUk interface, one row for each TCM function or GCC12 access. The position of the TCM function and/or GCC12 access within the sequence is indicated by the optIfODUkPositionSeqPosition variable in optIfODUkPositionSeqTable. The optIfODUkPositionSeqTable also provides pointers to the corresponding TCM function (optIfODUkT) and GCC12 access (optIfGCC12) entities." ::= { optIfODUkConfigEntry 4 } optIfODUkTtpPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object has the value true(1) if the ifEntry under which it is instantiated contains an ODUk Trail Termination Point, i.e., is the endpoint of an ODUk path. In that case there will be a corresponding row in the ODUk TTP config table and it will not be possible to create corresponding rows in the ODUk NIM config table. This object has the value false(2) if the ifEntry under which it is instantiated contains an intermediate ODUk Connection Termination Point. In that case there is no corresponding row in the ODUk TTP config table, but it will be possible to create corresponding rows in the ODUk NIM config table. This object also affects the allowable options in rows created in the GCC12 config table and in the ODUkT config table, as specified in the DESCRIPTION clauses of the columns in those tables." ::= { optIfODUkConfigEntry 5 } -- ODUk Trail Termination Point (TTP) config table optIfODUkTtpConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfODUkTtpConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ODUk TTP configuration information." ::= { optIfODUk 2 } optIfODUkTtpConfigEntry OBJECT-TYPE SYNTAX OptIfODUkTtpConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Lam, et al. Standards Track [Page 122] RFC 3591 Optical Interface Type MIB September 2003 "A conceptual row that contains ODUk TTP configuration information of an interface." INDEX { ifIndex } ::= { optIfODUkTtpConfigTable 1 } OptIfODUkTtpConfigEntry ::= SEQUENCE { optIfODUkTtpTraceIdentifierTransmitted OptIfTxTI, optIfODUkTtpDAPIExpected OptIfExDAPI, optIfODUkTtpSAPIExpected OptIfExSAPI, optIfODUkTtpTraceIdentifierAccepted OptIfAcTI, optIfODUkTtpTIMDetMode OptIfTIMDetMode, optIfODUkTtpTIMActEnabled TruthValue, optIfODUkTtpDEGThr OptIfDEGThr, optIfODUkTtpDEGM OptIfDEGM, optIfODUkTtpCurrentStatus BITS } optIfODUkTtpTraceIdentifierTransmitted OBJECT-TYPE SYNTAX OptIfTxTI MAX-ACCESS read-write STATUS current DESCRIPTION "The trace identifier transmitted. This object is applicable when optIfODUkDirectionality has the value source(2) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value sink(1). If no value is ever set by a management entity for this object, system-specific default value will be used. Any implementation that instantiates this object must document the system-specific default value or how it is derived." ::= { optIfODUkTtpConfigEntry 1 } optIfODUkTtpDAPIExpected OBJECT-TYPE SYNTAX OptIfExDAPI MAX-ACCESS read-write STATUS current DESCRIPTION "The DAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). This object has no effect when optIfODUkTtpTIMDetMode has the value off(1)." ::= { optIfODUkTtpConfigEntry 2 } Lam, et al. Standards Track [Page 123] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkTtpSAPIExpected OBJECT-TYPE SYNTAX OptIfExSAPI MAX-ACCESS read-write STATUS current DESCRIPTION "The SAPI expected by the receiver. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). This object has no effect when optIfODUkTtpTIMDetMode has the value off(1)." ::= { optIfODUkTtpConfigEntry 3 } optIfODUkTtpTraceIdentifierAccepted OBJECT-TYPE SYNTAX OptIfAcTI MAX-ACCESS read-only STATUS current DESCRIPTION "The actual trace identifier accepted. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The value of this object is unspecified when optIfODUkTtpCurrentStatus indicates a near-end defect (i.e., oci(0), lck(1), ssf(5)) that prevents extraction of the trace message." ::= { optIfODUkTtpConfigEntry 4 } optIfODUkTtpTIMDetMode OBJECT-TYPE SYNTAX OptIfTIMDetMode MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The default value of this object is off(1)." ::= { optIfODUkTtpConfigEntry 5 } optIfODUkTtpTIMActEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current Lam, et al. Standards Track [Page 124] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). This object has no effect when optIfODUkTtpTIMDetMode has the value off(1). The default value of this object is false(2)." ::= { optIfODUkTtpConfigEntry 6 } optIfODUkTtpDEGThr OBJECT-TYPE SYNTAX OptIfDEGThr UNITS "percentage" MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfODUkDEGThr. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The default value of this object is Severely Errored Second (SES) Estimator (See ITU-T G.7710)." ::= { optIfODUkTtpConfigEntry 7 } optIfODUkTtpDEGM OBJECT-TYPE SYNTAX OptIfDEGM MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkDEGM consecutive bad PM Seconds are detected. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2). The default value of this object is 7 (See ITU-T G.7710)." ::= { optIfODUkTtpConfigEntry 8 } optIfODUkTtpCurrentStatus OBJECT-TYPE SYNTAX BITS { oci(0), Lam, et al. Standards Track [Page 125] RFC 3591 Optical Interface Type MIB September 2003 lck(1), tim(2), deg(3), bdi(4), ssf(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the defect condition of the entity, if any. This object is only applicable to the sink function, i.e., only when optIfODUkDirectionality has the value sink(1) or bidirectional(3). It must not be instantiated in rows where optIfODUkDirectionality has the value source(2)." ::= { optIfODUkTtpConfigEntry 9 } -- ODUk Position Sequence table optIfODUkPositionSeqTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfODUkPositionSeqEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ODUk Position Sequence information." ::= { optIfODUk 3 } optIfODUkPositionSeqEntry OBJECT-TYPE SYNTAX OptIfODUkPositionSeqEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains ODUk position sequence information of an ODUk interface. The ODUk interface is identified by the ifIndex. Associated with each ODUk interface there may be one of more conceptual rows in the optIfODUkPositionSeqTable. Each row represents a TCM or GCC12 access function within the associated ODUk interface. Rows of the optIfODUkPositionSeqTable table are created/deleted as the result of the creation/deletion of the optIfODUkT or optIfGCC12 entities." INDEX { ifIndex, optIfODUkPositionSeqIndex } ::= { optIfODUkPositionSeqTable 1 } OptIfODUkPositionSeqEntry ::= SEQUENCE { optIfODUkPositionSeqIndex Unsigned32, optIfODUkPositionSeqPosition Unsigned32, Lam, et al. Standards Track [Page 126] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkPositionSeqPointer RowPointer } optIfODUkPositionSeqIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable identifies a row in the optIfODUkPositionSeqTable Table. Each row of the optIfODUkPositionSeqTable Table represents a TCM or GCC12 access function within the associated ODUk interface." ::= { optIfODUkPositionSeqEntry 1 } optIfODUkPositionSeqPosition OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the position of the TCM or GCC12 access function within the sequence of TCMs & GCC12 access functions of the associated ODUk interface. The TCM or GCC12 presented by this row is referenced by the optIfODUkPositionSeqPointer variable." ::= { optIfODUkPositionSeqEntry 2 } optIfODUkPositionSeqPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "This variable identifies the TCM or GCC12 access function by pointing to the corresponding optIfODUkT or optIfGCC12 entity." ::= { optIfODUkPositionSeqEntry 3 } -- ODUk Non-intrusive monitoring (Nim) config table optIfODUkNimConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfODUkNimConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ODUkNim configuration information." ::= { optIfODUk 4 } optIfODUkNimConfigEntry OBJECT-TYPE Lam, et al. Standards Track [Page 127] RFC 3591 Optical Interface Type MIB September 2003 SYNTAX OptIfODUkNimConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains ODUkNim configuration information of an interface. Each instance must correspond to an instance of optIfODUkConfigEntry for which optIfODUkTtpPresent has the value false(2). Instances of this conceptual row persist across agent restarts, and read-create columns other than the status column may be modified while the row is active." INDEX { ifIndex, optIfODUkNimDirectionality } ::= { optIfODUkNimConfigTable 1 } OptIfODUkNimConfigEntry ::= SEQUENCE { optIfODUkNimDirectionality OptIfSinkOrSource, optIfODUkNimDAPIExpected OptIfExDAPI, optIfODUkNimSAPIExpected OptIfExSAPI, optIfODUkNimTraceIdentifierAccepted OptIfAcTI, optIfODUkNimTIMDetMode OptIfTIMDetMode, optIfODUkNimTIMActEnabled TruthValue, optIfODUkNimDEGThr OptIfDEGThr, optIfODUkNimDEGM OptIfDEGM, optIfODUkNimCurrentStatus BITS, optIfODUkNimRowStatus RowStatus } optIfODUkNimDirectionality OBJECT-TYPE SYNTAX OptIfSinkOrSource MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the monitor point for the ODUk Path non-intrusive monitoring function. The value source(2) is not allowed if the corresponding instance of optIfODUkDirectionality has the value sink(1), and the value sink(1) is not allowed if the corresponding instance of optIfODUkDirectionality has the value source(2). Either the value sink(1) or source(2) is allowed if the corresponding instance of optIfODUkDirectionality has the value bidirectional(3). The value sink(1) means monitoring at the sink direction path signal of the ODUk CTP. The value source(2) means monitoring at the source direction Lam, et al. Standards Track [Page 128] RFC 3591 Optical Interface Type MIB September 2003 path signal of the ODUk CTP. Monitoring the source direction of an ODUk CTP is necessary in those cases where the ODUk CTP is at an SNCP (Subnetwork Connection Protection) end (e.g., see Figure I.1.2/G.874.1). If one would like to get the performance of the protected connection, one cannot use the NIM function at both ODUk CTP sinks (before the matrix), instead one should monitor the signal at the source ODUk CTP after the matrix." ::= { optIfODUkNimConfigEntry 1 } optIfODUkNimDAPIExpected OBJECT-TYPE SYNTAX OptIfExDAPI MAX-ACCESS read-create STATUS current DESCRIPTION "The DAPI expected by the receiver. This object has no effect if optIfODUkNimTIMDetMode has the value off(1) or sapi(3)." ::= { optIfODUkNimConfigEntry 2 } optIfODUkNimSAPIExpected OBJECT-TYPE SYNTAX OptIfExSAPI MAX-ACCESS read-create STATUS current DESCRIPTION "The SAPI expected by the receiver. This object has no effect if optIfODUkNimTIMDetMode has the value off(1) or dapi(2)." ::= { optIfODUkNimConfigEntry 3 } optIfODUkNimTraceIdentifierAccepted OBJECT-TYPE SYNTAX OptIfAcTI MAX-ACCESS read-only STATUS current DESCRIPTION "The actual trace identifier accepted. The value of this object is unspecified if optIfODUkNimCurrentStatus has any of the bit positions oci(0), lck(1), or ssf(5) set or if optIfODUkNimRowStatus has any value other than active(1)." ::= { optIfODUkNimConfigEntry 4 } optIfODUkNimTIMDetMode OBJECT-TYPE SYNTAX OptIfTIMDetMode MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function." Lam, et al. Standards Track [Page 129] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfODUkNimConfigEntry 5 } optIfODUkNimTIMActEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled." ::= { optIfODUkNimConfigEntry 6 } optIfODUkNimDEGThr OBJECT-TYPE SYNTAX OptIfDEGThr UNITS "percentage" MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfODUkNimDEGThr." ::= { optIfODUkNimConfigEntry 7 } optIfODUkNimDEGM OBJECT-TYPE SYNTAX OptIfDEGM MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkNimDEGM consecutive bad PM Seconds are detected." ::= { optIfODUkNimConfigEntry 8 } optIfODUkNimCurrentStatus OBJECT-TYPE SYNTAX BITS { oci(0), lck(1), tim(2), deg(3), bdi(4), ssf(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the defect condition of the entity, if any. The value of this object is unspecified if optIfODUkNimRowStatus has any value other than Lam, et al. Standards Track [Page 130] RFC 3591 Optical Interface Type MIB September 2003 active(1)." ::= { optIfODUkNimConfigEntry 9 } optIfODUkNimRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This columnar object is used for creating and deleting a conceptual row of the optIfODUkNim config table. It is used to model the activateNim and deactivateNim operations of an OTUk_CTP for non-intrusive monitoring control as defined in G.874.1. Setting RowStatus to createAndGo or createAndWait implies activateNim. Setting RowStatus to destroy implies deactivateNim." ::= { optIfODUkNimConfigEntry 10 } -- GCC12 config table optIfGCC12ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfGCC12ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of GCC12 configuration information. The GCC function processes the GCC overhead bytes passing through them but leave the remainder of the ODUk overhead and payload data alone." ::= { optIfODUk 5 } optIfGCC12ConfigEntry OBJECT-TYPE SYNTAX OptIfGCC12ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains GCC12 configuration information of an interface. Each instance must correspond to an instance of optIfODUkConfigEntry. Separate instances providing GCC1-only access and GCC2-only access may exist for a given ifIndex value, or a single instance providing GCC1 + GCC2 may exist, but a GCC1 + GCC2 instance may not coexist with a GCC1-only or GCC2-only instance. Instances of this conceptual row persist across agent restarts." INDEX { ifIndex, optIfGCC12Codirectional, optIfGCC12GCCAccess } ::= { optIfGCC12ConfigTable 1 } Lam, et al. Standards Track [Page 131] RFC 3591 Optical Interface Type MIB September 2003 OptIfGCC12ConfigEntry ::= SEQUENCE { optIfGCC12Codirectional TruthValue, optIfGCC12GCCAccess INTEGER, optIfGCC12GCCPassThrough TruthValue, optIfGCC12Application SnmpAdminString, optIfGCC12RowStatus RowStatus } optIfGCC12Codirectional OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the directionality of the GCC12 termination with respect to the associated ODUk CTP. The value true(1) means that the sink part of the GCC12 extracts COMMS data from the signal at the input to the ODUk CTP sink and the source part of the GCC12 inserts COMMS data into the signal at the output of the ODUk CTP source. The value false(2) means that the sink part of the GCC12 extracts COMMS data from the signal at the output of the ODUk CTP source and the source part of the GCC12 inserts COMMS data into the signal at the input of the ODUk CTP sink. This attribute may assume either value when the corresponding instance of optIfODUkTtpPresent has the value false(2). When the value of the corresponding instance of optIfODUkTtpPresent is true(1) then the only value allowed for this attribute is true(1)." ::= { optIfGCC12ConfigEntry 1 } optIfGCC12GCCAccess OBJECT-TYPE SYNTAX INTEGER { gcc1 (1), gcc2 (2), gcc1and2 (3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the GCC access represented by the entity." ::= { optIfGCC12ConfigEntry 2 } optIfGCC12GCCPassThrough OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Controls whether the selected GCC overhead bytes are passed Lam, et al. Standards Track [Page 132] RFC 3591 Optical Interface Type MIB September 2003 through or modified. The value true(1) means that the selected GCC overhead bytes are passed through unmodified from the ODUk CTP input to the ODUk CTP output. The value false(2) means that the selected GCC overhead bytes are set to zero at the ODUk CTP output after the extraction of the COMMS data. This object has no effect if the corresponding instance of optIfODUkTtpPresent has the value true(1). The value of this object may not be changed when optIfGCC12RowStatus has the value active(1)." ::= { optIfGCC12ConfigEntry 3 } optIfGCC12Application OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the application transported by the GCC12 entity. Example applications are ECC, User data channel. The value of this object may not be changed when optIfGCC12RowStatus has the value active(1)." ::= { optIfGCC12ConfigEntry 4 } optIfGCC12RowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This columnar object is used for creating and deleting a conceptual row of the optIfGCC12 config table. It is used to model the addGCC12Access and removeGCC12Access operations of an ODUk_CTP or ODUk_TTP for GCC12 access control as defined in G.874.1. Setting RowStatus to createAndGo or createAndWait implies addGCC12Access. Setting RowStatus to destroy implies removeGCC12Access. Successful addition/removal of the GCC12 access function will result in updating the optIfODUkPositionSeqCurrentSize variable and the optIfODUkPositionSeqTable table of the associated ODUk entry in the optIfODUkConfigTable." ::= { optIfGCC12ConfigEntry 5 } -- the optIfODUkT group -- This group handles the configuration information -- for the ODUkT layers. -- ODUkT config table Lam, et al. Standards Track [Page 133] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkTConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfODUkTConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ODUkT configuration information." ::= { optIfODUkT 1 } optIfODUkTConfigEntry OBJECT-TYPE SYNTAX OptIfODUkTConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains ODUkT configuration information of an interface. Each instance must correspond to an instance of optIfODUkConfigEntry. Rows in this table are mutually exclusive with rows in the ODUkT NIM config table -- in other words, this row object may not be instantiated for a given pair of ifIndex and TCM field values if a corresponding instance of optIfODUkTNimConfigEntry already exists. Instances of this conceptual row persist across agent restarts. Except where noted otherwise, read-create columns other than the status column may be modified while the row is active." INDEX { ifIndex, optIfODUkTTcmField, optIfODUkTCodirectional } ::= { optIfODUkTConfigTable 1 } OptIfODUkTConfigEntry ::= SEQUENCE { optIfODUkTTcmField Unsigned32, optIfODUkTCodirectional TruthValue, optIfODUkTTraceIdentifierTransmitted OptIfTxTI, optIfODUkTDAPIExpected OptIfExDAPI, optIfODUkTSAPIExpected OptIfExSAPI, optIfODUkTTraceIdentifierAccepted OptIfAcTI, optIfODUkTTIMDetMode OptIfTIMDetMode, optIfODUkTTIMActEnabled TruthValue, optIfODUkTDEGThr OptIfDEGThr, optIfODUkTDEGM OptIfDEGM, optIfODUkTSinkMode INTEGER, optIfODUkTSinkLockSignalAdminState INTEGER, optIfODUkTSourceLockSignalAdminState INTEGER, optIfODUkTCurrentStatus BITS, optIfODUkTRowStatus RowStatus } Lam, et al. Standards Track [Page 134] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkTTcmField OBJECT-TYPE SYNTAX Unsigned32 (1..6) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the tandem connection monitoring field of the ODUk OH. Valid values are integers from 1 to 6." ::= { optIfODUkTConfigEntry 1 } optIfODUkTCodirectional OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the directionality of the ODUkT termination point with respect to the associated ODUk CTP. The value true(1) means that the sink part of the ODUkT TP extracts TCM data from the signal at the input to the ODUk CTP sink and the source part of the ODUkT TP inserts TCM data into the signal at the output of the ODUk CTP source. The value false(2) means that the sink part of the ODUkT TP extracts TCM data from the signal at the output of the ODUk CTP source and the source part of the ODUkT TP inserts TCM data into the signal at the input of the ODUk CTP sink. This attribute may assume either value when the corresponding instance of optIfODUkTtpPresent has the value false(2). When the value of the corresponding instance of optIfODUkTtpPresent is true(1) then the only value allowed for this attribute is true(1)." ::= { optIfODUkTConfigEntry 2 } optIfODUkTTraceIdentifierTransmitted OBJECT-TYPE SYNTAX OptIfTxTI MAX-ACCESS read-create STATUS current DESCRIPTION "The trace identifier transmitted. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value false(2), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value true(1). It must not be instantiated in rows for all other cases." ::= { optIfODUkTConfigEntry 3 } optIfODUkTDAPIExpected OBJECT-TYPE SYNTAX OptIfExDAPI Lam, et al. Standards Track [Page 135] RFC 3591 Optical Interface Type MIB September 2003 MAX-ACCESS read-create STATUS current DESCRIPTION "The DAPI expected by the receiver. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. This object has no effect when optIfODUkTTIMDetMode has the value off(1)." ::= { optIfODUkTConfigEntry 4 } optIfODUkTSAPIExpected OBJECT-TYPE SYNTAX OptIfExSAPI MAX-ACCESS read-create STATUS current DESCRIPTION "The SAPI expected by the receiver. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. This object has no effect when optIfODUkTTIMDetMode has the value off(1)." ::= { optIfODUkTConfigEntry 5 } optIfODUkTTraceIdentifierAccepted OBJECT-TYPE SYNTAX OptIfAcTI MAX-ACCESS read-only STATUS current DESCRIPTION "The actual trace identifier accepted. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The value of this object is unspecified when optIfODUkTCurrentStatus indicates a near-end defect (i.e., oci(0), lck(1), ssf(5)) that prevents extraction Lam, et al. Standards Track [Page 136] RFC 3591 Optical Interface Type MIB September 2003 of the trace message." ::= { optIfODUkTConfigEntry 6 } optIfODUkTTIMDetMode OBJECT-TYPE SYNTAX OptIfTIMDetMode MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The default value of this object is off(1)." ::= { optIfODUkTConfigEntry 7 } optIfODUkTTIMActEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. This object has no effect when optIfODUkTTIMDetMode has the value off(1). The default value of this object is false(2)." ::= { optIfODUkTConfigEntry 8 } optIfODUkTDEGThr OBJECT-TYPE SYNTAX OptIfDEGThr UNITS "percentage" MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is Lam, et al. Standards Track [Page 137] RFC 3591 Optical Interface Type MIB September 2003 greater than or equal to optIfODUkTDEGThr. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The default value of this object is Severely Errored Second (SES) Estimator (See ITU-T G.7710)." ::= { optIfODUkTConfigEntry 9 } optIfODUkTDEGM OBJECT-TYPE SYNTAX OptIfDEGM MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkTDEGM consecutive bad PM Seconds are detected. This object is applicable only to the following three cases. (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases. The default value of this object is 7 (See ITU-T G.7710)." ::= { optIfODUkTConfigEntry 10 } optIfODUkTSinkMode OBJECT-TYPE SYNTAX INTEGER { operational (1), monitor (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This variable specifies the TCM mode at the entity. The value operational(1) means that TCM Overhead (TCMOH) processes (see ITU-T G.798) shall be performed and consequent actions for AIS, Trail Signal Fail (TSF), Trail Signal Degraded (TSD) shall be initiated in case of defects. The value monitor(2) means that TCMOH processes shall be performed but consequent actions for AIS, Trail Server Failure (TSF), Trail Server Degraded (TSD) shall _not_ be initiated in case of defects. Lam, et al. Standards Track [Page 138] RFC 3591 Optical Interface Type MIB September 2003 This object is applicable only when the value of optIfODUkTtpPresent is false(2) and also either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases." ::= { optIfODUkTConfigEntry 11 } optIfODUkTSinkLockSignalAdminState OBJECT-TYPE SYNTAX INTEGER { locked(1), normal(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Provides the capability to provision the LOCK signal, which is one of the ODUk maintenance signals, at the ODUKT sink. When a Tandem Connection endpoint is set to admin state locked, it inserts the ODUk-LCK signal in the sink direction. This object is applicable only when the value of optIfODUkTtpPresent is false(2) and also either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases." ::= { optIfODUkTConfigEntry 12 } optIfODUkTSourceLockSignalAdminState OBJECT-TYPE SYNTAX INTEGER { locked(1), normal(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Provides the capability to provision the LOCK signal, which is one of the ODUk maintenance signals, at the source. When a Tandem Connection endpoint is set to admin state locked, it inserts the ODUk-LCK signal in the source direction. Lam, et al. Standards Track [Page 139] RFC 3591 Optical Interface Type MIB September 2003 This object is applicable only when either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value false(2), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value true(1). It must not be instantiated in rows for all other cases." ::= { optIfODUkTConfigEntry 13 } optIfODUkTCurrentStatus OBJECT-TYPE SYNTAX BITS { oci(0), lck(1), tim(2), deg(3), bdi(4), ssf(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the defect condition of the entity, if any. This object is applicable only when either one of the following three cases holds: (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It must not be instantiated in rows for all other cases." ::= { optIfODUkTConfigEntry 14 } optIfODUkTRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This columnar object is used for creating and deleting a conceptual row of the optIfODUkT config table. It is used to model the addTCM and removeTCM operations of an ODUk_CTP or ODUk_TTP for Tandem connection monitoring as defined in ITU-T G.874.1. Setting RowStatus to createAndGo or createAndWait implies addTCM. Setting RowStatus to destroy implies removeTCM. Successful addition/removal of TCM will result in updating the optIfODUkTcmFieldsInUse and optIfODUkPositionSeqCurrentSize variables and the optIfODUkPositionSeqTable table of the Lam, et al. Standards Track [Page 140] RFC 3591 Optical Interface Type MIB September 2003 associated ODUk entry in the optIfODUkConfigTable." ::= { optIfODUkTConfigEntry 15 } -- ODUkT Non-intrusive monitoring (Nim) config table optIfODUkTNimConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF OptIfODUkTNimConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ODUkTNim configuration information." ::= { optIfODUkT 2 } optIfODUkTNimConfigEntry OBJECT-TYPE SYNTAX OptIfODUkTNimConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains ODUkTNim configuration information of an interface. Each instance must correspond to an instance of optIfODUkConfigEntry. Rows in this table are mutually exclusive with rows in the ODUkT config table -- in other words, this row object may not be instantiated for a given pair of ifIndex and TCM field values if a corresponding instance of optIfODUkTConfigEntry already exists. Instances of this conceptual row persist across agent restarts, and read-create columns other than the status column may be modified while the row is active." INDEX {ifIndex, optIfODUkTNimTcmField, optIfODUkTNimDirectionality} ::= { optIfODUkTNimConfigTable 1 } OptIfODUkTNimConfigEntry ::= SEQUENCE { optIfODUkTNimTcmField Unsigned32, optIfODUkTNimDirectionality OptIfSinkOrSource, optIfODUkTNimDAPIExpected OptIfExDAPI, optIfODUkTNimSAPIExpected OptIfExSAPI, optIfODUkTNimTraceIdentifierAccepted OptIfAcTI, optIfODUkTNimTIMDetMode OptIfTIMDetMode, optIfODUkTNimTIMActEnabled TruthValue, optIfODUkTNimDEGThr OptIfDEGThr, optIfODUkTNimDEGM OptIfDEGM, optIfODUkTNimCurrentStatus BITS, optIfODUkTNimRowStatus RowStatus } Lam, et al. Standards Track [Page 141] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkTNimTcmField OBJECT-TYPE SYNTAX Unsigned32 (1..6) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the tandem connection monitoring field of the ODUk OH on which non-intrusive monitoring is performed. Valid values are integers from 1 to 6." ::= { optIfODUkTNimConfigEntry 1 } optIfODUkTNimDirectionality OBJECT-TYPE SYNTAX OptIfSinkOrSource MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the monitor point for the ODUk TCM non-intrusive monitoring function. The value source(2) is not allowed if the corresponding instance of optIfODUkDirectionality has the value sink(1), and the value sink(1) is not allowed if the corresponding instance of optIfODUkDirectionality has the value source(2). Either the value sink(1) or source(2) is allowed if the corresponding instance of optIfODUkDirectionality has the value bidirectional(3). The value sink(1) means monitoring at the sink direction TCM signal of the ODUk CTP. The value source(2) means monitoring at the source direction path signal of the ODUk CTP." ::= { optIfODUkTNimConfigEntry 2 } optIfODUkTNimDAPIExpected OBJECT-TYPE SYNTAX OptIfExDAPI MAX-ACCESS read-create STATUS current DESCRIPTION "The DAPI expected by the receiver. This object has no effect if optIfODUkTNimTIMDetMode has the value off(1) or sapi(3)." ::= { optIfODUkTNimConfigEntry 3 } optIfODUkTNimSAPIExpected OBJECT-TYPE SYNTAX OptIfExSAPI MAX-ACCESS read-create STATUS current DESCRIPTION "The SAPI expected by the receiver. This object has no effect if optIfODUkTNimTIMDetMode has the value off(1) or dapi(2)." Lam, et al. Standards Track [Page 142] RFC 3591 Optical Interface Type MIB September 2003 ::= { optIfODUkTNimConfigEntry 4 } optIfODUkTNimTraceIdentifierAccepted OBJECT-TYPE SYNTAX OptIfAcTI MAX-ACCESS read-only STATUS current DESCRIPTION "The actual trace identifier accepted. The value of this object is unspecified if optIfODUkTNimCurrentStatus has any of the bit positions oci(0), lck(1), or ssf(5) set or if optIfODUkTNimRowStatus has any value other than active(1)." ::= { optIfODUkTNimConfigEntry 5 } optIfODUkTNimTIMDetMode OBJECT-TYPE SYNTAX OptIfTIMDetMode MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the mode of the Trace Identifier Mismatch (TIM) Detection function." ::= { optIfODUkTNimConfigEntry 6 } optIfODUkTNimTIMActEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the Trace Identifier Mismatch (TIM) Consequent Action function is enabled." ::= { optIfODUkTNimConfigEntry 7 } optIfODUkTNimDEGThr OBJECT-TYPE SYNTAX OptIfDEGThr UNITS "percentage" MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the threshold level for declaring a performance monitoring (PM) Second to be bad. A PM Second is declared bad if the percentage of detected errored blocks in that second is greater than or equal to optIfODUkTNimDEGThr." ::= { optIfODUkTNimConfigEntry 8 } optIfODUkTNimDEGM OBJECT-TYPE SYNTAX OptIfDEGM MAX-ACCESS read-create STATUS current Lam, et al. Standards Track [Page 143] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "Indicates the threshold level for declaring a Degraded Signal defect (dDEG). A dDEG shall be declared if optIfODUkTNimDEGM consecutive bad PM Seconds are detected." ::= { optIfODUkTNimConfigEntry 9 } optIfODUkTNimCurrentStatus OBJECT-TYPE SYNTAX BITS { oci(0), lck(1), tim(2), deg(3), bdi(4), ssf(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the defect condition of the entity, if any. The value of this object is unspecified if optIfODUkTNimRowStatus has any value other than active(1)." ::= { optIfODUkTNimConfigEntry 10 } optIfODUkTNimRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This columnar object is used for creating and deleting a conceptual row of the optIfODUkTNim config table. It is used to model the addTCM and removeTCM operations of an ODUk_CTP or ODUk_TTP for non-intrusive Tandem connection monitoring as defined in ITU-T G.874.1. Setting RowStatus to createAndGo or createAndWait implies addTCM. Setting RowStatus to destroy implies removeTCM. Successful addition/removal of Nim TCM will result in updating the optIfODUkPositionSeqCurrentSize variable and the optIfODUkPositionSeqTable table of the associated ODUk entry in the optIfODUkConfigTable." ::= { optIfODUkTNimConfigEntry 11 } -- units of conformance optIfOTMnGroup OBJECT-GROUP OBJECTS { optIfOTMnOrder, optIfOTMnReduced, Lam, et al. Standards Track [Page 144] RFC 3591 Optical Interface Type MIB September 2003 optIfOTMnBitRates, optIfOTMnInterfaceType, optIfOTMnTcmMax, optIfOTMnOpticalReach } STATUS current DESCRIPTION "A collection of OTMn structure information objects." ::= { optIfGroups 1 } optIfPerfMonGroup OBJECT-GROUP OBJECTS { optIfPerfMonCurrentTimeElapsed, optIfPerfMonCurDayTimeElapsed, optIfPerfMonIntervalNumIntervals, optIfPerfMonIntervalNumInvalidIntervals } STATUS current DESCRIPTION "A collection of performance monitoring interval objects." ::= { optIfGroups 2 } optIfOTSnCommonGroup OBJECT-GROUP OBJECTS { optIfOTSnDirectionality } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OTSn interfaces." ::= { optIfGroups 3 } optIfOTSnSourceGroupFull OBJECT-GROUP OBJECTS { optIfOTSnTraceIdentifierTransmitted } STATUS current DESCRIPTION "A collection of configuration objects applicable to full-functionality/IaDI OTSn interfaces that support source functions." ::= { optIfGroups 4 } optIfOTSnAPRStatusGroup OBJECT-GROUP OBJECTS { optIfOTSnAprStatus } STATUS current Lam, et al. Standards Track [Page 145] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "A collection of objects applicable to OTSn interfaces that support Automatic Power Reduction functions." ::= { optIfGroups 5 } optIfOTSnAPRControlGroup OBJECT-GROUP OBJECTS { optIfOTSnAprControl } STATUS current DESCRIPTION "A collection of objects applicable to OTSn interfaces that provide Automatic Power Reduction control functions." ::= { optIfGroups 6 } optIfOTSnSinkGroupBasic OBJECT-GROUP OBJECTS { optIfOTSnCurrentStatus } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OTSn interfaces that support sink functions." ::= { optIfGroups 7 } optIfOTSnSinkGroupFull OBJECT-GROUP OBJECTS { optIfOTSnDAPIExpected, optIfOTSnSAPIExpected, optIfOTSnTraceIdentifierAccepted, optIfOTSnTIMDetMode, optIfOTSnTIMActEnabled } STATUS current DESCRIPTION "A collection of configuration objects applicable to full-functionality/IaDI OTSn interfaces that support sink functions." ::= { optIfGroups 8 } optIfOTSnSinkPreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOTSnSinkCurrentSuspectedFlag, optIfOTSnSinkCurrentInputPower, optIfOTSnSinkCurrentLowInputPower, Lam, et al. Standards Track [Page 146] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSinkCurrentHighInputPower, optIfOTSnSinkCurrentOutputPower, optIfOTSnSinkCurrentLowOutputPower, optIfOTSnSinkCurrentHighOutputPower, optIfOTSnSinkIntervalSuspectedFlag, optIfOTSnSinkIntervalLastInputPower, optIfOTSnSinkIntervalLowInputPower, optIfOTSnSinkIntervalHighInputPower, optIfOTSnSinkIntervalLastOutputPower, optIfOTSnSinkIntervalLowOutputPower, optIfOTSnSinkIntervalHighOutputPower, optIfOTSnSinkCurDaySuspectedFlag, optIfOTSnSinkCurDayLowInputPower, optIfOTSnSinkCurDayHighInputPower, optIfOTSnSinkCurDayLowOutputPower, optIfOTSnSinkCurDayHighOutputPower, optIfOTSnSinkPrevDaySuspectedFlag, optIfOTSnSinkPrevDayLastInputPower, optIfOTSnSinkPrevDayLowInputPower, optIfOTSnSinkPrevDayHighInputPower, optIfOTSnSinkPrevDayLastOutputPower, optIfOTSnSinkPrevDayLowOutputPower, optIfOTSnSinkPrevDayHighOutputPower } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OTSn interfaces that support sink functions." ::= { optIfGroups 9 } optIfOTSnSinkPreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOTSnSinkCurrentLowerInputPowerThreshold, optIfOTSnSinkCurrentUpperInputPowerThreshold, optIfOTSnSinkCurrentLowerOutputPowerThreshold, optIfOTSnSinkCurrentUpperOutputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OTSn interfaces that support sink functions." ::= { optIfGroups 10 } optIfOTSnSourcePreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOTSnSrcCurrentSuspectedFlag, Lam, et al. Standards Track [Page 147] RFC 3591 Optical Interface Type MIB September 2003 optIfOTSnSrcCurrentOutputPower, optIfOTSnSrcCurrentLowOutputPower, optIfOTSnSrcCurrentHighOutputPower, optIfOTSnSrcCurrentInputPower, optIfOTSnSrcCurrentLowInputPower, optIfOTSnSrcCurrentHighInputPower, optIfOTSnSrcIntervalSuspectedFlag, optIfOTSnSrcIntervalLastOutputPower, optIfOTSnSrcIntervalLowOutputPower, optIfOTSnSrcIntervalHighOutputPower, optIfOTSnSrcIntervalLastInputPower, optIfOTSnSrcIntervalLowInputPower, optIfOTSnSrcIntervalHighInputPower, optIfOTSnSrcCurDaySuspectedFlag, optIfOTSnSrcCurDayLowOutputPower, optIfOTSnSrcCurDayHighOutputPower, optIfOTSnSrcCurDayLowInputPower, optIfOTSnSrcCurDayHighInputPower, optIfOTSnSrcPrevDaySuspectedFlag, optIfOTSnSrcPrevDayLastOutputPower, optIfOTSnSrcPrevDayLowOutputPower, optIfOTSnSrcPrevDayHighOutputPower, optIfOTSnSrcPrevDayLastInputPower, optIfOTSnSrcPrevDayLowInputPower, optIfOTSnSrcPrevDayHighInputPower } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OTSn interfaces that support source functions." ::= { optIfGroups 11 } optIfOTSnSourcePreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOTSnSrcCurrentLowerOutputPowerThreshold, optIfOTSnSrcCurrentUpperOutputPowerThreshold, optIfOTSnSrcCurrentLowerInputPowerThreshold, optIfOTSnSrcCurrentUpperInputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OTSn interfaces that support source functions." ::= { optIfGroups 12 } optIfOMSnCommonGroup OBJECT-GROUP Lam, et al. Standards Track [Page 148] RFC 3591 Optical Interface Type MIB September 2003 OBJECTS { optIfOMSnDirectionality } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OMSn interfaces." ::= { optIfGroups 13 } optIfOMSnSinkGroupBasic OBJECT-GROUP OBJECTS { optIfOMSnCurrentStatus } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OMSn interfaces that support sink functions." ::= { optIfGroups 14 } optIfOMSnSinkPreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOMSnSinkCurrentSuspectedFlag, optIfOMSnSinkCurrentAggregatedInputPower, optIfOMSnSinkCurrentLowAggregatedInputPower, optIfOMSnSinkCurrentHighAggregatedInputPower, optIfOMSnSinkCurrentOutputPower, optIfOMSnSinkCurrentLowOutputPower, optIfOMSnSinkCurrentHighOutputPower, optIfOMSnSinkIntervalSuspectedFlag, optIfOMSnSinkIntervalLastAggregatedInputPower, optIfOMSnSinkIntervalLowAggregatedInputPower, optIfOMSnSinkIntervalHighAggregatedInputPower, optIfOMSnSinkIntervalLastOutputPower, optIfOMSnSinkIntervalLowOutputPower, optIfOMSnSinkIntervalHighOutputPower, optIfOMSnSinkCurDaySuspectedFlag, optIfOMSnSinkCurDayLowAggregatedInputPower, optIfOMSnSinkCurDayHighAggregatedInputPower, optIfOMSnSinkCurDayLowOutputPower, optIfOMSnSinkCurDayHighOutputPower, optIfOMSnSinkPrevDaySuspectedFlag, optIfOMSnSinkPrevDayLastAggregatedInputPower, optIfOMSnSinkPrevDayLowAggregatedInputPower, optIfOMSnSinkPrevDayHighAggregatedInputPower, optIfOMSnSinkPrevDayLastOutputPower, optIfOMSnSinkPrevDayLowOutputPower, optIfOMSnSinkPrevDayHighOutputPower Lam, et al. Standards Track [Page 149] RFC 3591 Optical Interface Type MIB September 2003 } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OMSn interfaces that support sink functions." ::= { optIfGroups 15 } optIfOMSnSinkPreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOMSnSinkCurrentLowerInputPowerThreshold, optIfOMSnSinkCurrentUpperInputPowerThreshold, optIfOMSnSinkCurrentLowerOutputPowerThreshold, optIfOMSnSinkCurrentUpperOutputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OMSn interfaces that support sink functions." ::= { optIfGroups 16 } optIfOMSnSourcePreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOMSnSrcCurrentSuspectedFlag, optIfOMSnSrcCurrentOutputPower, optIfOMSnSrcCurrentLowOutputPower, optIfOMSnSrcCurrentHighOutputPower, optIfOMSnSrcCurrentAggregatedInputPower, optIfOMSnSrcCurrentLowAggregatedInputPower, optIfOMSnSrcCurrentHighAggregatedInputPower, optIfOMSnSrcIntervalSuspectedFlag, optIfOMSnSrcIntervalLastOutputPower, optIfOMSnSrcIntervalLowOutputPower, optIfOMSnSrcIntervalHighOutputPower, optIfOMSnSrcIntervalLastAggregatedInputPower, optIfOMSnSrcIntervalLowAggregatedInputPower, optIfOMSnSrcIntervalHighAggregatedInputPower, optIfOMSnSrcCurDaySuspectedFlag, optIfOMSnSrcCurDayLowOutputPower, optIfOMSnSrcCurDayHighOutputPower, optIfOMSnSrcCurDayLowAggregatedInputPower, optIfOMSnSrcCurDayHighAggregatedInputPower, optIfOMSnSrcPrevDaySuspectedFlag, optIfOMSnSrcPrevDayLastOutputPower, optIfOMSnSrcPrevDayLowOutputPower, optIfOMSnSrcPrevDayHighOutputPower, optIfOMSnSrcPrevDayLastAggregatedInputPower, Lam, et al. Standards Track [Page 150] RFC 3591 Optical Interface Type MIB September 2003 optIfOMSnSrcPrevDayLowAggregatedInputPower, optIfOMSnSrcPrevDayHighAggregatedInputPower } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OMSn interfaces that support source functions." ::= { optIfGroups 17 } optIfOMSnSourcePreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOMSnSrcCurrentLowerOutputPowerThreshold, optIfOMSnSrcCurrentUpperOutputPowerThreshold, optIfOMSnSrcCurrentLowerInputPowerThreshold, optIfOMSnSrcCurrentUpperInputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OMSn interfaces that that support source functions." ::= { optIfGroups 18 } optIfOChGroupCommonGroup OBJECT-GROUP OBJECTS { optIfOChGroupDirectionality } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OChGroup interfaces." ::= { optIfGroups 19 } optIfOChGroupSinkPreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOChGroupSinkCurrentSuspectedFlag, optIfOChGroupSinkCurrentAggregatedInputPower, optIfOChGroupSinkCurrentLowAggregatedInputPower, optIfOChGroupSinkCurrentHighAggregatedInputPower, optIfOChGroupSinkCurrentOutputPower, optIfOChGroupSinkCurrentLowOutputPower, optIfOChGroupSinkCurrentHighOutputPower, optIfOChGroupSinkIntervalSuspectedFlag, optIfOChGroupSinkIntervalLastAggregatedInputPower, optIfOChGroupSinkIntervalLowAggregatedInputPower, optIfOChGroupSinkIntervalHighAggregatedInputPower, optIfOChGroupSinkIntervalLastOutputPower, Lam, et al. Standards Track [Page 151] RFC 3591 Optical Interface Type MIB September 2003 optIfOChGroupSinkIntervalLowOutputPower, optIfOChGroupSinkIntervalHighOutputPower, optIfOChGroupSinkCurDaySuspectedFlag, optIfOChGroupSinkCurDayLowAggregatedInputPower, optIfOChGroupSinkCurDayHighAggregatedInputPower, optIfOChGroupSinkCurDayLowOutputPower, optIfOChGroupSinkCurDayHighOutputPower, optIfOChGroupSinkPrevDaySuspectedFlag, optIfOChGroupSinkPrevDayLastAggregatedInputPower, optIfOChGroupSinkPrevDayLowAggregatedInputPower, optIfOChGroupSinkPrevDayHighAggregatedInputPower, optIfOChGroupSinkPrevDayLastOutputPower, optIfOChGroupSinkPrevDayLowOutputPower, optIfOChGroupSinkPrevDayHighOutputPower } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OChGroup interfaces that support sink functions." ::= { optIfGroups 20 } optIfOChGroupSinkPreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOChGroupSinkCurrentLowerInputPowerThreshold, optIfOChGroupSinkCurrentUpperInputPowerThreshold, optIfOChGroupSinkCurrentLowerOutputPowerThreshold, optIfOChGroupSinkCurrentUpperOutputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OChGroup interfaces that support sink functions." ::= { optIfGroups 21 } optIfOChGroupSourcePreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOChGroupSrcCurrentSuspectedFlag, optIfOChGroupSrcCurrentOutputPower, optIfOChGroupSrcCurrentLowOutputPower, optIfOChGroupSrcCurrentHighOutputPower, optIfOChGroupSrcCurrentAggregatedInputPower, optIfOChGroupSrcCurrentLowAggregatedInputPower, optIfOChGroupSrcCurrentHighAggregatedInputPower, optIfOChGroupSrcIntervalSuspectedFlag, optIfOChGroupSrcIntervalLastOutputPower, optIfOChGroupSrcIntervalLowOutputPower, Lam, et al. Standards Track [Page 152] RFC 3591 Optical Interface Type MIB September 2003 optIfOChGroupSrcIntervalHighOutputPower, optIfOChGroupSrcIntervalLastAggregatedInputPower, optIfOChGroupSrcIntervalLowAggregatedInputPower, optIfOChGroupSrcIntervalHighAggregatedInputPower, optIfOChGroupSrcCurDaySuspectedFlag, optIfOChGroupSrcCurDayLowOutputPower, optIfOChGroupSrcCurDayHighOutputPower, optIfOChGroupSrcCurDayLowAggregatedInputPower, optIfOChGroupSrcCurDayHighAggregatedInputPower, optIfOChGroupSrcPrevDaySuspectedFlag, optIfOChGroupSrcPrevDayLastOutputPower, optIfOChGroupSrcPrevDayLowOutputPower, optIfOChGroupSrcPrevDayHighOutputPower, optIfOChGroupSrcPrevDayLastAggregatedInputPower, optIfOChGroupSrcPrevDayLowAggregatedInputPower, optIfOChGroupSrcPrevDayHighAggregatedInputPower } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OChGroup interfaces that support source functions." ::= { optIfGroups 22 } optIfOChGroupSourcePreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOChGroupSrcCurrentLowerOutputPowerThreshold, optIfOChGroupSrcCurrentUpperOutputPowerThreshold, optIfOChGroupSrcCurrentLowerInputPowerThreshold, optIfOChGroupSrcCurrentUpperInputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OChGroup interfaces that that support source functions." ::= { optIfGroups 23 } optIfOChCommonGroup OBJECT-GROUP OBJECTS { optIfOChDirectionality } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OCh interfaces." ::= { optIfGroups 24 } Lam, et al. Standards Track [Page 153] RFC 3591 Optical Interface Type MIB September 2003 optIfOChSinkGroupBasic OBJECT-GROUP OBJECTS { optIfOChCurrentStatus } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OCh interfaces that support sink functions." ::= { optIfGroups 25 } optIfOChSinkPreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOChSinkCurrentSuspectedFlag, optIfOChSinkCurrentInputPower, optIfOChSinkCurrentLowInputPower, optIfOChSinkCurrentHighInputPower, optIfOChSinkIntervalSuspectedFlag, optIfOChSinkIntervalLastInputPower, optIfOChSinkIntervalLowInputPower, optIfOChSinkIntervalHighInputPower, optIfOChSinkCurDaySuspectedFlag, optIfOChSinkCurDayLowInputPower, optIfOChSinkCurDayHighInputPower, optIfOChSinkPrevDaySuspectedFlag, optIfOChSinkPrevDayLastInputPower, optIfOChSinkPrevDayLowInputPower, optIfOChSinkPrevDayHighInputPower } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OCh interfaces that support sink functions." ::= { optIfGroups 26 } optIfOChSinkPreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOChSinkCurrentLowerInputPowerThreshold, optIfOChSinkCurrentUpperInputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OCh interfaces that support sink functions." ::= { optIfGroups 27 } Lam, et al. Standards Track [Page 154] RFC 3591 Optical Interface Type MIB September 2003 optIfOChSourcePreOtnPMGroup OBJECT-GROUP OBJECTS { optIfOChSrcCurrentSuspectedFlag, optIfOChSrcCurrentOutputPower, optIfOChSrcCurrentLowOutputPower, optIfOChSrcCurrentHighOutputPower, optIfOChSrcIntervalSuspectedFlag, optIfOChSrcIntervalLastOutputPower, optIfOChSrcIntervalLowOutputPower, optIfOChSrcIntervalHighOutputPower, optIfOChSrcCurDaySuspectedFlag, optIfOChSrcCurDayLowOutputPower, optIfOChSrcCurDayHighOutputPower, optIfOChSrcPrevDaySuspectedFlag, optIfOChSrcPrevDayLastOutputPower, optIfOChSrcPrevDayLowOutputPower, optIfOChSrcPrevDayHighOutputPower } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring objects applicable to OCh interfaces that support source functions." ::= { optIfGroups 28 } optIfOChSourcePreOtnPMThresholdGroup OBJECT-GROUP OBJECTS { optIfOChSrcCurrentLowerOutputPowerThreshold, optIfOChSrcCurrentUpperOutputPowerThreshold } STATUS current DESCRIPTION "A collection of pre-OTN performance monitoring threshold objects applicable to OCh interfaces that support source functions." ::= { optIfGroups 29 } optIfOTUkCommonGroup OBJECT-GROUP OBJECTS { optIfOTUkDirectionality, optIfOTUkBitRateK } STATUS current DESCRIPTION "A collection of configuration objects applicable to all OTUk interfaces." ::= { optIfGroups 30 } Lam, et al. Standards Track [Page 155] RFC 3591 Optical Interface Type MIB September 2003 optIfOTUkSourceGroup OBJECT-GROUP OBJECTS { optIfOTUkTraceIdentifierTransmitted, optIfOTUkSourceAdaptActive } STATUS current DESCRIPTION "A collection of configuration objects applicable to OTUk interfaces that support source functions." ::= { optIfGroups 31 } optIfOTUkSinkGroup OBJECT-GROUP OBJECTS { optIfOTUkDAPIExpected, optIfOTUkSAPIExpected, optIfOTUkTraceIdentifierAccepted, optIfOTUkTIMDetMode, optIfOTUkTIMActEnabled, optIfOTUkDEGThr, optIfOTUkDEGM, optIfOTUkSinkAdaptActive, optIfOTUkSinkFECEnabled, optIfOTUkCurrentStatus } STATUS current DESCRIPTION "A collection of configuration objects applicable to OTUk interfaces that support sink functions." ::= { optIfGroups 32 } optIfGCC0Group OBJECT-GROUP OBJECTS { optIfGCC0Application, optIfGCC0RowStatus } STATUS current DESCRIPTION "A collection of GCC0 configuration objects." ::= { optIfGroups 33 } optIfODUkGroup OBJECT-GROUP OBJECTS { optIfODUkDirectionality, optIfODUkBitRateK, optIfODUkTcmFieldsInUse, optIfODUkPositionSeqCurrentSize, Lam, et al. Standards Track [Page 156] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkPositionSeqPosition, optIfODUkPositionSeqPointer, optIfODUkTtpPresent } STATUS current DESCRIPTION "A collection of configuration objects applicable to all ODUk interfaces." ::= { optIfGroups 34 } optIfODUkTtpSourceGroup OBJECT-GROUP OBJECTS { optIfODUkTtpTraceIdentifierTransmitted } STATUS current DESCRIPTION "A collection of configuration objects applicable to all interfaces that support ODUk trail termination source functions." ::= { optIfGroups 35 } optIfODUkTtpSinkGroup OBJECT-GROUP OBJECTS { optIfODUkTtpDAPIExpected, optIfODUkTtpSAPIExpected, optIfODUkTtpTraceIdentifierAccepted, optIfODUkTtpTIMDetMode, optIfODUkTtpTIMActEnabled, optIfODUkTtpDEGThr, optIfODUkTtpDEGM, optIfODUkTtpCurrentStatus } STATUS current DESCRIPTION "A collection of ODUk configuration objects applicable to all interfaces that support ODUk trail termination sink functions." ::= { optIfGroups 36 } optIfODUkNimGroup OBJECT-GROUP OBJECTS { optIfODUkNimDAPIExpected, optIfODUkNimSAPIExpected, optIfODUkNimTraceIdentifierAccepted, optIfODUkNimTIMDetMode, optIfODUkNimTIMActEnabled, optIfODUkNimDEGThr, optIfODUkNimDEGM, Lam, et al. Standards Track [Page 157] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkNimCurrentStatus, optIfODUkNimRowStatus } STATUS current DESCRIPTION "A collection of ODUk Nim configuration objects." ::= { optIfGroups 37 } optIfGCC12Group OBJECT-GROUP OBJECTS { optIfGCC12GCCPassThrough, optIfGCC12Application, optIfGCC12RowStatus } STATUS current DESCRIPTION "A collection of GCC12 configuration objects." ::= { optIfGroups 38 } optIfODUkTCommonGroup OBJECT-GROUP OBJECTS { optIfODUkTRowStatus } STATUS current DESCRIPTION "A collection of configuration objects applicable to all ODUkT instances." ::= { optIfGroups 39 } optIfODUkTSourceGroup OBJECT-GROUP OBJECTS { optIfODUkTTraceIdentifierTransmitted, optIfODUkTSourceLockSignalAdminState } STATUS current DESCRIPTION "A collection of configuration objects applicable to all ODUkT instances that provide source functions." ::= { optIfGroups 40 } optIfODUkTSinkGroup OBJECT-GROUP OBJECTS { optIfODUkTDAPIExpected, optIfODUkTSAPIExpected, optIfODUkTTraceIdentifierAccepted, optIfODUkTTIMDetMode, optIfODUkTTIMActEnabled, Lam, et al. Standards Track [Page 158] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkTDEGThr, optIfODUkTDEGM, optIfODUkTCurrentStatus } STATUS current DESCRIPTION "A collection of configuration objects applicable to all ODUkT instances that provide sink functions." ::= { optIfGroups 41 } optIfODUkTSinkGroupCtp OBJECT-GROUP OBJECTS { optIfODUkTSinkMode, optIfODUkTSinkLockSignalAdminState } STATUS current DESCRIPTION "A collection of configuration objects applicable to ODUkT instances not colocated with an ODUk TTP that provide sink functions." ::= { optIfGroups 42 } optIfODUkTNimGroup OBJECT-GROUP OBJECTS { optIfODUkTNimDAPIExpected, optIfODUkTNimSAPIExpected, optIfODUkTNimTraceIdentifierAccepted, optIfODUkTNimTIMDetMode, optIfODUkTNimTIMActEnabled, optIfODUkTNimDEGThr, optIfODUkTNimDEGM, optIfODUkTNimCurrentStatus, optIfODUkTNimRowStatus } STATUS current DESCRIPTION "A collection of ODUkT Nim configuration objects." ::= { optIfGroups 43 } -- compliance specifications optIfOtnConfigCompl MODULE-COMPLIANCE STATUS current DESCRIPTION "Implementation requirements for the OTN configuration functions defined in this MIB module." Lam, et al. Standards Track [Page 159] RFC 3591 Optical Interface Type MIB September 2003 MODULE -- this module MANDATORY-GROUPS { optIfOTMnGroup, optIfOTSnCommonGroup } GROUP optIfOTSnSourceGroupFull DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(196) for which the corresponding instance of optIfOTSnDirectionality has the value source(2) or bidirectional(3), the corresponding instance of optIfOTMnReduced has the value false(2), and the corresponding instance of optIfOTMnInterfaceType specifies an OTMn interface type of 'IaDI'." GROUP optIfOTSnAPRStatusGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(196) that support Automatic Power Reduction functions." GROUP optIfOTSnAPRControlGroup DESCRIPTION "This group is optional, but is recommended for interfaces of ifType opticalTransport(196) that provide Automatic Power Reduction control functions." GROUP optIfOTSnSinkGroupBasic DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(196) for which the corresponding instance of optIfOTSnDirectionality has the value sink(1) or bidirectional(3)." GROUP optIfOTSnSinkGroupFull DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(196) for which the corresponding instance of optIfOTSnDirectionality has the value sink(1) or bidirectional(3), the corresponding instance of optIfOTMnReduced has the value false(2), and the corresponding instance of optIfOTMnInterfaceType specifies an OTMn interface type of 'IaDI'." GROUP optIfOMSnCommonGroup DESCRIPTION Lam, et al. Standards Track [Page 160] RFC 3591 Optical Interface Type MIB September 2003 "This group is mandatory for interfaces of ifType opticalTransport(196) that support access to the OMS overhead information within the OTN Supervisory Channel." GROUP optIfOMSnSinkGroupBasic DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(196) that support access to the OMS Overhead information within the OSC (OTN Supervisory Channel) for which the corresponding instance of optIfOMSnDirectionality has the value sink(1) or bidirectional(3)." GROUP optIfOChGroupCommonGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannelGroup(219)." GROUP optIfOChCommonGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(195)." GROUP optIfOChSinkGroupBasic DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) for which the corresponding instance of optIfOChDirectionality has the value sink(1) or bidirectional(3)." GROUP optIfOTUkCommonGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support OTUk layer functions." GROUP optIfOTUkSourceGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support OTUk layer functions and for which the corresponding instance of optIfOTUkDirectionality has the value source(2) or bidirectional(3)." GROUP optIfOTUkSinkGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support OTUk layer functions and for which the corresponding instance of Lam, et al. Standards Track [Page 161] RFC 3591 Optical Interface Type MIB September 2003 optIfOTUkDirectionality has the value sink(1) or bidirectional(3)." GROUP optIfGCC0Group DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support GCC0 access functions. It may be implemented only if the optIfOTUkCommonGroup is also implemented." GROUP optIfODUkGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support ODUk layer functions." GROUP optIfODUkTtpSourceGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) for which the corresponding instance of optIfODUkTtpPresent has the value true(1) and for which the corresponding instance of optIfODUkDirectionality has the value source(2) or bidirectional(3). It may be implemented only if the optIfODUkGroup is also implemented." GROUP optIfODUkTtpSinkGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) for which the corresponding instance of optIfODUkTtpPresent has the value true(1) and for which the corresponding instance of optIfODUkDirectionality has the value sink(1) or bidirectional(3). It may be implemented only if the optIfODUkGroup is also implemented." GROUP optIfODUkNimGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) for which the corresponding instance of optIfODUkTtpPresent has the value false(2). It may be implemented only if the optIfODUkGroup is also implemented." GROUP optIfGCC12Group DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support GCC12 access functions. It may be implemented only if the optIfODUkGroup Lam, et al. Standards Track [Page 162] RFC 3591 Optical Interface Type MIB September 2003 is also implemented." GROUP optIfODUkTCommonGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support intrusive tandem connection monitoring. It may be implemented only if the optIfODUkGroup is also implemented." GROUP optIfODUkTSourceGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support intrusive tandem connection monitoring and for which (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value false(2), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value true(1). It may be implemented only if the optIfODUkGroup is also implemented." GROUP optIfODUkTSinkGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support intrusive tandem connection monitoring and for which (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It may be implemented only if the optIfODUkGroup is also implemented." GROUP optIfODUkTSinkGroupCtp DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support intrusive tandem connection monitoring and for which optIfODUkTtpPresent is false(2) and (i) optIfODUkDirectionality has the value bidirectional(3), or (ii) optIfODUkDirectionality has the value sink(1) and optIfODUkTCodirectional has the value true(1), or (iii) optIfODUkDirectionality has the value source(3) and optIfODUkTCodirectional has the value false(2). It may be implemented only if the optIfODUkGroup and optIfODUkTSinkGroup are also implemented." Lam, et al. Standards Track [Page 163] RFC 3591 Optical Interface Type MIB September 2003 GROUP optIfODUkTNimGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support non-intrusive tandem connection monitoring. It may be implemented only if the optIfODUkGroup is also implemented." ::= { optIfCompl 1 } optIfPreOtnPMCompl MODULE-COMPLIANCE STATUS current DESCRIPTION "Implementation requirements for Pre-OTN performance monitoring functions defined in this MIB module." MODULE -- this module MANDATORY-GROUPS { optIfPerfMonGroup } GROUP optIfOTSnSinkPreOtnPMGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(196) that support OTSn sink functions (i.e., for which the corresponding instance of optIfOTSnDirectionality -- if implemented -- has the value sink(1) or bidirectional(3))." GROUP optIfOTSnSinkPreOtnPMThresholdGroup DESCRIPTION "This group is mandatory if and only if TCA notifications are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOTSnSinkPreOtnPMGroup is a prerequisite for implementing this group." GROUP optIfOTSnSourcePreOtnPMGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalTransport(196) that support OTSn source functions (i.e., for which the corresponding instance of optIfOTSnDirectionality -- if implemented -- has the value source(2) or bidirectional(3))." GROUP optIfOTSnSourcePreOtnPMThresholdGroup Lam, et al. Standards Track [Page 164] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "This group is mandatory if and only if TCA notifications are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOTSnSourcePreOtnPMGroup is a prerequisite for implementing this group " GROUP optIfOMSnSinkPreOtnPMGroup DESCRIPTION "This group is optional. It may be implemented by systems with the necessary instrumentation on interfaces of ifType opticalTransport(196) that support OMSn sink functions (i.e., for which the corresponding instance of optIfOMSnDirectionality -- if implemented -- has the value sink(1) or bidirectional(3))." GROUP optIfOMSnSinkPreOtnPMThresholdGroup DESCRIPTION "This group is mandatory if and only if TCA notifications are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOMSnSinkPreOtnPMGroup is a prerequisite for implementing this group " GROUP optIfOMSnSourcePreOtnPMGroup DESCRIPTION "This group is optional. It may be implemented by systems with the necessary instrumentation on interfaces of ifType opticalTransport(196) that support OMSn source functions (i.e., for which the corresponding instance of optIfOMSnDirectionality -- if implemented -- has the value source(2) or bidirectional(3))." GROUP optIfOMSnSourcePreOtnPMThresholdGroup DESCRIPTION "This group is mandatory if and only if TCA notifications are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOMSnSourcePreOtnPMGroup is a prerequisite for implementing this group " GROUP optIfOChGroupSinkPreOtnPMGroup Lam, et al. Standards Track [Page 165] RFC 3591 Optical Interface Type MIB September 2003 DESCRIPTION "This group is optional. It may be implemented by systems with the necessary instrumentation on interfaces of ifType opticalChannelGroup(219) that support OChGroup sink functions (i.e., for which the corresponding instance of optIfOChGroupDirectionality -- if implemented -- has the value sink(1) or bidirectional(3))." GROUP optIfOChGroupSinkPreOtnPMThresholdGroup DESCRIPTION "This group is mandatory if and only if TCA notifications are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOChGroupSinkPreOtnPMGroup is a prerequisite for implementing this group " GROUP optIfOChGroupSourcePreOtnPMGroup DESCRIPTION "This group is optional. It may be implemented by systems with the necessary instrumentation on interfaces of ifType opticalChannelGroup(219) that support OChGroup source functions (i.e., for which the corresponding instance of optIfOChGroupDirectionality -- if implemented -- has the value source(2) or bidirectional(3))." GROUP optIfOChGroupSourcePreOtnPMThresholdGroup DESCRIPTION "This group is mandatory if and only if TCA notifications are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOChGroupSourcePreOtnPMGroup is a prerequisite for implementing this group " GROUP optIfOChSinkPreOtnPMGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support OCh sink functions (i.e., for which the corresponding instance of optIfOChDirectionality -- if implemented -- has the value sink(1) or bidirectional(3))." GROUP optIfOChSinkPreOtnPMThresholdGroup DESCRIPTION "This group is mandatory if and only if TCA notifications Lam, et al. Standards Track [Page 166] RFC 3591 Optical Interface Type MIB September 2003 are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOChSinkPreOtnPMGroup is a prerequisite for implementing this group " GROUP optIfOChSourcePreOtnPMGroup DESCRIPTION "This group is mandatory for interfaces of ifType opticalChannel(195) that support OCh source functions (i.e., for which the corresponding instance of optIfOChDirectionality -- if implemented -- has the value source(2) or bidirectional(3))." GROUP optIfOChSourcePreOtnPMThresholdGroup DESCRIPTION "This group is mandatory if and only if TCA notifications are implemented. If the objects of this group are instantiated then the implementation must also provide, in an enterprise MIB, suitable TCA notification definitions and notification control objects. Implementation of the optIfOChSourcePreOtnPMGroup is a prerequisite for implementing this group " ::= { optIfCompl 2 } END 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. It is possible for writes to these objects to have disruptive effects on network operation that range from invalid performance data to traffic interruptions. Users of this MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The most sensitive objects are the read-write and read-create objects listed in the optIfOtnConfigCompl compliance statement that control the maximum number of TCM levels allowed (optIfOTMnTcmMax), automatic power reduction (optIfOTSnAprControl), transmitted trail trace (optIfOTSnTraceIdentifierTransmitted, optIfOTUkTraceIdentifierTransmitted, optIfODUkTtpTraceIdentifierTransmitted, optIfODUkTTraceIdentifierTransmitted), expected source/destination access point identifiers (optIfOTSnDAPIExpected, optIfOTSnSAPIExpected, optIfOTUkDAPIExpected, optIfOTUkSAPIExpected, Lam, et al. Standards Track [Page 167] RFC 3591 Optical Interface Type MIB September 2003 optIfODUkTtpDAPIExpected, optIfODUkTtpSAPIExpected, optIfODUkNimDAPIExpected, optIfODUkNimSAPIExpected, optIfODUkTDAPIExpected, optIfODUkTSAPIExpected, optIfODUkTNimDAPIExpected, optIfODUkTNimSAPIExpected), trace identifier mismatch detection mode (optIfOTSnTIMDetMode, optIfOTUkTIMDetMode, optIfODUkTtpTIMDetMode, optIfODUkNimTIMDetMode, optIfODUkTTIMDetMode, optIfODUkTNimTIMDetMode), trace identifier mismatch consequent action (optIfOTSnTIMActEnabled, optIfOTUkTIMActEnabled, optIfODUkTtpTIMActEnabled, optIfODUkNimTIMActEnabled, optIfODUkTTIMActEnabled, optIfODUkTNimTIMActEnabled), threshold level for declaring a PM Second to be bad (optIfOTUkDEGThr, optIfODUkTtpDEGThr, optIfODUkNimDEGThr, optIfODUkTDEGThr, optIfODUkTNimDEGThr), threshold level for declaring a Degraded Signal defect (optIfOTUkDEGM, optIfODUkTtpDEGM, optIfODUkNimDEGM, optIfODUkTDEGM, optIfODUkTNimDEGM), whether the sink/source adaptation function is activated (optIfOTUkSinkAdaptActive, optIfOTUkSourceAdaptActive), whether Forward Error Correction is supported (optIfOTUkSinkFECEnabled), the application transported by the GCC entities (optIfGCC0Application, optIfGCC12Application), creating and deleting a conceptual row of a config table (optIfGCC0RowStatus, optIfODUkNimRowStatus, optIfGCC12RowStatus, optIfODUkTRowStatus, optIfODUkTNimRowStatus), whether the selected GCC overhead bytes are passed through or modified (optIfGCC12GCCPassThrough), TCM mode (optIfODUkTSinkMode), and provisioning of the sink/source LOCK signal (optIfODUkTSinkLockSignalAdminState, optIfODUkTSourceLockSignalAdminState), as these may cause traffic interruptions if improperly set. The readable objects in this MIB module (i.e., the objects with a MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the performance of interfaces in OTN equipment or networks and can reveal aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) objects in this MIB module. It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Lam, et al. Standards Track [Page 168] RFC 3591 Optical Interface Type MIB September 2003 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and cryptographic security be enabled. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. Acknowledgements Nathan Kohn initiated the concept, then gathered and coordinated the team that led to the initial version of the MIB. Mark Stewart/Brian Teer wrote sections on use of interface tables, reviewed the MIB Object Definitions for SNMP SMIv2 compliance, and wrote the PM sections in working with G.7710/Y.1701. Anni Huynh wrote the initial MIB definitions for the OTN interface. Tom Rutt wrote the summary section on the Structure of the MIB. Rishi Grover contributed to the objects to monitor banded amplifiers. Kam Lam wrote the sections on Optical Networking Terminology and the OTN layers configuration parameters. He was the editor for the last several versions of this document. Thanks to Maarten Vissers for providing insight into Optical Networking concepts. Thanks to Lakshmi Raman and Moshe Rozenblit for reviewing and commenting on a preliminary version of the document. Special thanks to C. Mike Heard for providing a top notch doctor review and many helpful suggestions to improve the MIB. 7. References 7.1. Normative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Lam, et al. Standards Track [Page 169] RFC 3591 Optical Interface Type MIB September 2003 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [ITU-T G.709] ITU-T Recommendation G.709/Y.1331, "Network Node Interface for the Optical Transport Network (OTN)", (2/2001). [ITU-T G.798] ITU-T Recommendation G.798, "Characteristics of Optical Transport Network Hierarchy Equipment Functional Blocks", (1/2002). [ITU-T G.872] ITU-T Recommendation G.872, "Architecture of optical transport networks", (11/2001). [ITU-T G.874] ITU-T Recommendation G.874, "Management aspects of the optical transport network element", (12/2001). [ITU-T G.874.1] ITU-T Recommendation G.874.1, "OTN Protocol-neutral Management Information Model for the NE View", (1/2002). [ITU-T G.7710] ITU-T Recommendation G.7710/Y.1701, "Common Equipment Management Function Requirements", (12/2001) [ITU-T G.806] ITU-T Recommendation G.806, "Characteristics of Transport Equipment - Description methodology and generic functionality", (10/2000). [ITU-T G.957] ITU-T Recommendation G.957, "Optical interfaces for equipments and systems relating to the synchronous digital hierarchy", (7/1999). Lam, et al. Standards Track [Page 170] RFC 3591 Optical Interface Type MIB September 2003 [ITU-T G.691] ITU-T Recommendation G.691, "Optical interfaces for single-channel STM-64, STM-256 and other SDH systems with optical amplifiers", (10/200). 7.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3433] Bierman, A., Romascanu, D. and K. C. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Lam, et al. Standards Track [Page 171] RFC 3591 Optical Interface Type MIB September 2003 9. Authors' Addresses Mark A. Stewart Senior Systems Analyst Raleigh, NC USA EMail: mstewart1@nc.rr.com An-ni Huynh Cetus Networks USA EMail: a_n_huynh@yahoo.com Hing-Kam Lam Lucent Technologies 101 Crawfords Corner Road, Room 4C-616A Holmdel, NJ 07733 USA Phone: +1 732-949-8338 EMail: hklam@lucent.com Lam, et al. Standards Track [Page 172] RFC 3591 Optical Interface Type MIB September 2003 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lam, et al. Standards Track [Page 173] snmp-mibs-downloader-1.1/mibrfcs/rfc3592.txt0000644000000000000000000043034411402176071015574 0ustar Network Working Group K. Tesink Request for Comments: 3592 Telcordia Technologies Obsoletes: 2558 September 2003 Category: Standards Track Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. Table of Contents 1. Conventions .................................................. 2 2. The Internet-Standard Management Framework ................... 3 3. Overview ..................................................... 3 3.1. Use of the ifTable ..................................... 3 3.2. Use of ifTable for SONET/SDH Medium/Section/Line Layer .............................. 5 3.3. Use of ifTable for SONET/SDH Paths ..................... 6 3.4. Use of ifTable for SONET/SDH VTs/VCs ................... 7 3.5. SONET/SDH Terminology .................................. 7 4. Object Definitions ........................................... 15 4.1. The SONET/SDH Medium Group ............................. 19 4.2. The SONET/SDH Section Group ............................ 23 Tesink Standards Track [Page 1] RFC 3592 SONET/SDH Objects September 2003 4.2.1. The SONET/SDH Section Current Group ............ 23 4.2.2. The SONET/SDH Section Interval Group ........... 25 4.3. The SONET/SDH Line Group ............................... 28 4.3.1. The SONET/SDH Line Current Group ............... 28 4.3.2. The SONET/SDH Line Interval Group .............. 30 4.4. The SONET/SDH Far End Line Group ....................... 32 4.4.1. The SONET/SDH Far End Line Current Group ....... 32 4.4.2. The SONET/SDH Far End Line Interval Group ...... 34 4.5. The SONET/SDH Path Group ............................... 37 4.5.1. The SONET/SDH Path Current Group ............... 37 4.5.2. The SONET/SDH Path Interval Group .............. 39 4.6. The SONET/SDH Far End Path Group ....................... 42 4.6.1. The SONET/SDH Far End Path Current Group ....... 42 4.6.2. The SONET/SDH Far End Path Interval Group ...... 44 4.7. The SONET/SDH Virtual Tributary Group .................. 46 4.7.1. The SONET/SDH VT Current Group ................. 46 4.7.2. The SONET/SDH VT Interval Group ................ 49 4.8. The SONET/SDH Far End VT Group ......................... 51 4.8.1. The SONET/SDH Far End VT Current Group ......... 51 4.8.2. The SONET/SDH Far End VT Interval Group......... 53 4.9. Conformance Information ................................ 56 4.10. Compliance Statements .................................. 56 5. Acknowledgments .............................................. 65 6. Security Considerations ...................................... 65 7. References ................................................... 66 7.1. Normative References ................................... 66 7.2. Informative References ................................. 68 8. Intellectual Property Statement .............................. 68 Appendix A: The delay-line approach to statistics collection ..... 69 Appendix B: RFC 1595 SES interpretation .......................... 71 Author's Address ................................................. 72 Full Copyright Statement ......................................... 73 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Tesink Standards Track [Page 2] RFC 3592 SONET/SDH Objects September 2003 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Textual conventions used in this document are defined in RFC 2579 [RFC2579] and RFC 3593 [RFC3593]. 3. Overview These objects are used when the particular media being used to realize an interface is a SONET/SDH interface. At present, this applies to these values of the ifType variable in the Internet- standard MIB: sonet (39), sonetPath (50), sonetVT (51) The definitions contained herein are based on the SONET/SDH specifications in ANSI T1.105 and T1.106-1988 [T1.105a][T1.105b][T1.106] and CCITT G.707, 708, 709, and G.783 [G.707][G.708][G.709][G.783]. 3.1. Use of the ifTable This section specifies how the MIB II interfaces group, as defined in [RFC2863], is used for SONET/SDH interfaces. The SONET/SDH layers support several multiplexing possibilities. For example in SONET, an Synchronous Transport Signal 3 (STS-3) has 3 SONET Paths, and a STS-3c has 1 SONET Path. Another example could be a STS-12 having 4 SONET STS-3c Paths. Similarly, a SONET Synchronous Payload Envelope (SPE) can carry many Virtual Tributaries (VTs), for example, one SONET SPE can carry 28 VT1.5s. It is important to note that an SPE and a VT in SONET is collectively referred to as a Virtual Container (VC) in SDH. Also, an STS is called Synchronous Transport Module (STM) in SDH. Tesink Standards Track [Page 3] RFC 3592 SONET/SDH Objects September 2003 Not all SONET/SDH equipment terminates all SONET/SDH layers. For example, a SONET/SDH STE regenerator terminates SONET/SDH Sections only, and is transparent for all layers above that. SONET/SDH Add- Drop multiplexers and Digital Cross Connect Systems terminate SONET/SDH Lines. SONET/SDH Terminal Multiplexers may also terminate SONET/SDH Paths and VTs/VCs. MIB II [RFC1213], as extended by [RFC2863], accommodates these cases by appropriate use of the MIB II system group, and the interfaces group. The system group can name and describe the type of managed resource. The interfaces group defines which SONET/SDH layers apply, how these layers are configured and multiplexed. This is achieved by proper representation of SONET/SDH Layers by ifEntries as defined in [RFC2863], as follows: _____________________________ | | | | > | | | | | | VT 1 |..........|VT K| > K ifEntries | | | | | |_____________|__________|____| > | | | | > | | | | | | Path 1 |......|Path L| > L ifEntries | | | | | |_______________|______|______| > | | > | | | | Line | | | | | |_____________________________| | | | | | | | | Section Layer | > 1 ifEntry | | | |_____________________________| | | | | | | | | Physical Medium Layer | | | | | |_____________________________| > Use of ifTable for a SONET/SDH port The exact configuration and multiplexing of the layers is maintained in the ifStackTable [RFC2863] and in the ifInvStackTable [RFC2864]. Tesink Standards Track [Page 4] RFC 3592 SONET/SDH Objects September 2003 3.2. Use of ifTable for SONET/SDH Medium/Section/Line Layer Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for combined SONET/SDH Medium/Section/Line Layer ===================================================================== ifIndex Interface index. ifDescr SONET/SDH Medium/Section/Line ifType sonet(39) ifSpeed Speed of line rate for SONET/SDH, (e.g., 155520000 bps). ifPhysAddress The value of the Circuit Identifier. If no Circuit Identifier has been assigned this object should have an octet string with zero length. ifAdminStatus May be implemented with read-only access. The desired administrative status of the interface. ifOperStatus The value testing(3) is not used. This object assumes the value down(2), if the objects sonetSectionCurrentStatus and sonetLineCurrentStatus have any other value than sonetSectionNoDefect(1) and sonetLineNoDefect(1), respectively. ifLastChange sysUpTime at the last change in ifOperStatus. ifName Textual name of the interface or an OCTET STRING of zero length. ifLinkUpDownTrapEnable Default value is enabled(1). May be implemented with read-only access. ifHighSpeed Speed of line in Mega-bits per second (e.g., 155 Mbps) ifConnectorPresent Set to true(1). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. Tesink Standards Track [Page 5] RFC 3592 SONET/SDH Objects September 2003 3.3. Use of ifTable for SONET/SDH Paths Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for SONET/SDH Paths ========================================= ifIndex Interface index. ifDescr SONET/SDH Path ifType sonetPath(50) ifSpeed set to speed of SONET/SDH path (e.g., an STS-1 path has a rate of 50112000 bps.) ifPhysAddress Circuit Identifier or OCTET STRING of zero length. ifAdminStatus May be implemented with read-only access. The desired administrative status of the interface. ifOperStatus This object assumes the value down(2), if the object sonetPathCurrentStatus has any other value than sonetPathNoDefect(1). ifLastChange sysUpTime at the last change in ifOperStatus. ifName Textual name of the interface or an OCTET STRING of zero length. ifLinkUpDownTrapEnable Default value is disabled(2). May be implemented with read-only access. ifHighSpeed Set to rate of SONET/SDH path in Mega-bits per second. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. Tesink Standards Track [Page 6] RFC 3592 SONET/SDH Objects September 2003 3.4. Use of ifTable for SONET/SDH VTs/VCs Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for SONET/SDH VTs/VCs =========================================== ifIndex Interface index. ifDescr SONET/SDH VT/VC ifType sonetVT(51) ifSpeed Set to speed of VT/VC (e.g., a VT1.5 has a rate of 1728000 bps.) ifPhysAddress Circuit Identifier or OCTET STRING of zero length. ifAdminStatus May be implemented with read-only access. The desired administrative status of the interface. ifOperStatus This object assumes the value down(2), if the object sonetVTCurrentStatus has any other value than sonetVTNoDefect(1). ifLastChange sysUpTime at the last change in ifOperStatus. ifName Textual name of the interface or an OCTET STRING of zero length. ifLinkUpDownTrapEnable Default value is disabled(2). May be implemented with read-only access. ifHighSpeed Set to rate of VT in Mega-bits per second. ifConnectorPresent Set to false(2). ifAlias The (non-volatile) alias name for this interface as assigned by the network manager. 3.5. SONET/SDH Terminology The terminology used in this document to describe error conditions on a SONET circuit as monitored by a SONET system are from the T1.231 [T1M1.3][T1.231a][T1.231b]. The terminology used in this document to describe error conditions on a SDH circuit as monitored by a SDH system are from the CCITT G.783 [G.783]. Only the SONET Performance Tesink Standards Track [Page 7] RFC 3592 SONET/SDH Objects September 2003 Monitoring terminology is defined in this document. The definitions for SDH Performance Monitoring terms are similar but not identical, and they can be found in [G.783]. If the definition in this document does not match the definition in the T1.231 document, the implementer should follow the definition described in this document. In some cases other or additional references are used as compared with the ones cited above. This will be indicated in the text. Section Loss Of Frame Failure (Out of Frame Event, Severely Errored Frame Defect) An Out of Frame (OOF) event (or Severely Errored Frame defect) is the occurrence of four contiguous errored frame alignment words. A frame alignment word occupies the A1 and A2 bytes of an STS frame, and is defined in T1.105. The SEF defect is terminated when two contiguous error-free frame words are detected. Any implementation of the frame recovery circuitry which achieves realignment following an OOF within the 250 microsecond (two frames) interval implied by this definition is acceptable. A Loss of Frame (LOF) defect is declared when an OOF/SEF defect persists for a period of 3 milliseconds. The LOF defect is terminated when the incoming signal remains continuously in-frame for a period of 1 ms to 3 ms. A LOF failure is declared when the LOF defect persists for a period of 2.5 +/- 0.5 seconds, except when an LOS defect or failure is present. The LOF failure is cleared when the LOS failure is declared, or when the LOF defect is absent for 10 +/- 0.5 seconds. Loss of Signal The Loss of Signal (LOS) defect is declared when no transitions are detected on the incoming signal (before descrambling). The LOS defect is detected upon observing 2.3 to 100 microseconds of no transitions. The LOS defect is cleared after a 125 microsecond interval (one frame) during which no LOS defect is detected. The LOS failure is declared when the LOS defect persists for a period of 2.5 +/- 0.5 seconds, or if LOS defect is present when the criteria for LOF failure declaration have been met. The LOS failure is cleared when the LOS defect is absent for a period of 10 +/- 0.5 seconds. Declaration of LOS failure clears any existing LOF failure. Clearing the LOS failure allows immediate declaration of the LOF failure if conditions warrant. Tesink Standards Track [Page 8] RFC 3592 SONET/SDH Objects September 2003 STS-Path Loss of Pointer A Loss of Pointer (LOP) defect is declared when either a valid pointer is not detected in eight consecutive frames, or when eight consecutive frames are detected with the New Data Flag (NDF) set to "1001" without a valid concatenation indicator (see ANSI T1.105). A LOP defect is terminated when either a valid pointer with a normal NDF set to "0110", or a valid concatenation indicator is detected for three contiguous frames. Incoming STS- Path AIS shall not result in the declaration of a LOP defect. An STS-Path LOP failure is declared when the STS-Path LOP defect persists for a period of 2.5 +/- 0.5 seconds. A STS-Path LOP failure is cleared when the STS-Path LOP defect is absent for 10 +/- 0.5 seconds. VT Loss of Pointer A VT LOP defect is declared when either a valid pointer is not detected in eight consecutive VT superframes, or when eight consecutive VT superframes are detected with the NDF set to "1001" without a valid concatenation indicator. A VT LOP defect is terminated when either a valid pointer with a normal NDF set to "0110", or a valid concatenation indicator is detected for three contiguous VT superframes. Incoming VT-Path AIS shall not result in declaring a VT LOP defect. A VT LOP failure is declared when the VT LOP defect persists for 2.5 +/- 0.5 seconds. A VT LOP failure is cleared when the VT LOP defect is absent for 10 +/- 0.5 seconds. Line Alarm Indication Signal A Line Alarm Indication Signal (L-AIS) is defined in ANSI T1.105. The following criteria are specific to the L-AIS defect: - Line AIS defect is detected as a "111" pattern in bits 6, 7, and 8 of the K2 byte in five consecutive frames. - Line AIS defect is terminated when bits 6, 7, and 8 of the K2 byte do not contain the code "111" for five consecutive frames. A Line AIS failure is declared when the Line AIS defect persists for a period of 2.5 +/- 0.5 seconds. A Line AIS failure is cleared when the Line AIS defect is absent for 10 +/- 0.5 seconds. STS-Path Alarm Indication Signal The STS-Path Alarm Indication Signal (AIS) is defined in ANSI T1.105 as all ones in bytes H1, H2, and H3 as well as all ones in the entire STS SPE. The following criteria are specific to the STS-Path AIS defect: Tesink Standards Track [Page 9] RFC 3592 SONET/SDH Objects September 2003 - STS-Path AIS defect is detected as all ones in bytes H1 and H2 in three contiguous frames. - The STS-Path AIS defect is terminated when a valid STS Pointer is detected with the NDF set to "1001" (inverted) for one frame, or "0110" (normal) for three contiguous frames. An STS-Path AIS failure is declared when the STS-Path AIS defect persists for 2.5 +/- 0.5 seconds. An STS-Path AIS failure is cleared when the STS-Path AIS defect is absent for 10 +/- 0.5 seconds. VT-Path Alarm Indication Signal The VT-Path Alarm Indication Signal (AIS) is only applicable for VTs in the floating mode of operation. VT-Path AIS is used to alert the downstream VT Path Terminating Entity (PTE) of an upstream failure. Upon detection of a failure, Line AIS, or STS- Path AIS, an STS PTE will generate downstream VT-Path AIS if the STS Synchronous Payload Envelope (SPE) is carrying floating VTs. VT-Path AIS is specified in ANSI T1.105 as all ones in bytes V1, V2, V3, and V4, as well as all ones in the entire VT SPE. The following criteria are specific to VT-Path AIS defect: - VT-Path AIS defect is detected by a VT PTE as all ones in bytes V1 and V2 in three contiguous VT superframes. - VT-Path AIS defect is terminated when valid VT pointer with a valid VT size is detected with the NDF set to "1001" (inverted) for one VT superframe, or "0110" (normal) for three contiguous VT superframes are detected. A VT-Path AIS failure is declared when the VT-Path AIS defect persists for 2.5 +/- 0.5 seconds. A VT-Path AIS failure is cleared when the VT-Path AIS defect is absent for 10 +/- 0.5 seconds. Line Remote Defect Indication Line Remote Defect Indication (RDI) (aka Line FERF) signal is the occurrence of a "110" pattern in bit positions 6, 7, and 8 of the K2 byte in STS-1 #1 of the STS-N signal. Line RDI is defined in ANSI T1.105. The following criteria are specific to Line RDI defect: - Line RDI defect is a "110" code in bits 6, 7, and 8 of the K2 byte of in STS-1 #1 in x consecutive frames, where x = 5 [T1.231a][T1.231b] or 10 [T1.231b]. Tesink Standards Track [Page 10] RFC 3592 SONET/SDH Objects September 2003 - Line RDI defect is terminated when any code other than "110" is detected in bits 6, 7, and 8 of the K2 byte in x consecutive frames, where x = 5 [T1.231a][T1.231b] or 10 [T1.231b]. A Line Remote Failure Indication (RFI) failure is declared when the incoming Line RDI defects lasts for 2.5 +/- 0.5 seconds. The Line RFI failure is cleared when no Line RDI defects are detected for 10 +/- 0.5 seconds. STS-Path Remote Defect Indication STS-Path RDI (aka STS-Path FERF) signal shall be generated within 100 milliseconds by the STS PTE upon detection of an AIS or LOP defect. Transmission of the STS-Path RDI signal shall cease within 100 milliseconds when the STS PTE no longer detects STS- Path AIS or STS-Path LOP defect. The STS-Path RDI shall accurately report the presence or absence of STS-Path AIS or STS- Path LOP defects. STS-Path RDI defect is defined in ANSI T1.105. The following requirements are specific to the STS-Path RDI defect: - STS-Path RDI is detected by all STS PTEs. STS-Path RDI is detected by the upstream STS PTE as a "1" in bit five of the Path Status byte (G1) for x consecutive frames, where x = 5 [T1.231a] or 10 [T1.231b]. - Removal of STS-Path Remote Defect Indication is detected by a "0" in bit 5 of the G1 byte in x consecutive frames, where x = 5 [T1.231a] or 10 [T1.231b]. An STS-Path Remote Failure Indication (RFI) failure is declared when the incoming STS-Path RDI defects lasts for 2.5 +/- 0.5 seconds. The STS-Path RFI failure is cleared when no STS-Path RDI defects are detected for 10 +/- 0.5 seconds. VT-Path Remote Defect Indication VT Path RDI (aka VT Path FERF) signal shall be generated within 100 milliseconds by the VT PTE upon detection of a VT-Path AIS or LOP defect. Transmission of the VT-Path RDI signal shall cease within 100 milliseconds when the VT PTE no longer detects VT-Path AIS or VT-Path LOP defect. The VT-Path RDI shall accurately report the presence or absence of VT-Path AIS or VT-Path LOP defects. VT- Path RDI defect is defined in ANSI T1.105. The following requirements are specific to VT-Path RDI defect: - VT-Path RDI defect is the occurrence of a "1" in bit 4 of the VT-Path Overhead byte (V5) in x consecutive frames, where x = 5 [T1.231a] or 10 [T1.231b]. Tesink Standards Track [Page 11] RFC 3592 SONET/SDH Objects September 2003 - VT-Path RDI defect is terminated when a "0" is detected in bit 4 of the VT-Path Overhead byte (V5) for x consecutive frames, where x = 5 [T1.231a] or 10 [T1.231b]. A VT-Path Remote Failure Indication (RFI) (derived) failure is declared when the incoming VT-Path RDI defects lasts for 2.5 +/- 0.5 seconds. The VT-Path RFI failure is cleared when no VT-Path RDI defects are detected for 10 +/- 0.5 seconds. VT-Path Remote Failure Indication The VT-Path RFI signal is only required for the case of byte synch mapped DS1s where the DS1 frame bit is not mapped. The VT-Path RFI is specified in ANSI T1.105, where it is currently called VT path yellow. When provided, the VT-Path RFI signal is used to indicate the occurrence of far-end failures. When the VT-Path RFI is not provided, far-end failures are derived from local timing of the VT-Path RDI defect. The VT-Path RFI failure is declared within 5 ms of detecting the incoming VT-Path RFI Signal. The VT-Path Remote Failure Indication (RFI) failure is cleared within 50 ms of detecting the removal of the incoming VT-Path RFI signal. Coding Violation Coding Violations (CV) are Bit Interleaved Parity (BIP) errors that are detected in the incoming signal. CV counters are incremented for each BIP error detected. That is, each BIP-8 can detect up to eight errors per STS-N frame, with each error incrementing the CV counter. Section CVs shall be collected using the BIP-8 in the B1 byte located in the Section Overhead of STS-1 #1. Line CVs shall be collected using the BIP-8s in B2 bytes located in the Line Overhead of each STS-1 (since all CVs on an STS-N line are counted together, this is equivalent to counting each error in the BIP-8*N contained in the B2 bytes of the STS-N Line Overhead). Thus, on an STS-N signal, up to 8 x N CVs may occur in each frame. Path CVs shall be collected using the BIP-8 in the B3 byte of the STS-Path Overhead of the STS SPE. VT CVs shall be collected using the BIP-2 in the V5 overhead byte of the floating VT. Errored Seconds At each layer, an Errored Second (ES) is a second with one or more Coding Violations at that layer OR one or more incoming defects (e.g., SEF, LOS, AIS, LOP) at that layer has occurred. Severely Errored Seconds According to [T1M1.3][T1.231a][TR253][GR253][T1.231b] at each layer, an Severely Errored Second (SES) is a second with x or more CVs at that layer, or a second during which at least one or more incoming defects at that layer has occurred. The values of x in Tesink Standards Track [Page 12] RFC 3592 SONET/SDH Objects September 2003 RFC 1595 [RFC1595] were based on [T1M1.3] and [TR253] (see Appendix B). These values have subsequently been relaxed in [T1.231a][GR253][T1.231b]. In addition, according to G.826 [G.826] SESs are measured as a percentage of errored blocks. To deal with these sets of definitions this memo defines an object sonetSESthresholdSet that determines the correct interpretation of SES. For backward compatibility, if this object is not implemented the interpretation of Appendix B shall apply. Otherwise, a more recent interpretation is suggested. An agent is not required to support all sets of definitions. Note that CV counts should be frozen during SESs. Note that if a manager changes the value of this object all SES statistics collected prior to this change shall be invalidated. Severely Errored Framing Seconds A Severely Errored Framing Second (SEFS) is a second containing one or more SEF events. This counter is only counted at the Section Layer. Unavailable Seconds At the Line, Path, and VT layers, an unavailable second is calculated by counting the number of seconds that the interface is unavailable. At each layer, the SONET/SDH interface is said to be unavailable at the onset of 10 contiguous SESs. The 10 SESs are included in unavailable time. Once unavailable, the SONET/SDH interface becomes available at the onset of 10 contiguous seconds with no SESs. The 10 seconds with no SESs are excluded from unavailable time. With respect to the SONET/SDH error counts at each layer, all counters at that layer are incremented while the SONET/SDH interface is deemed available at that layer. While the interface is deemed unavailable at that layer, the only count that is incremented is UASs at that layer. Note that this definition implies that the agent cannot determine until after a ten second interval has passed whether a given one- second interval belongs to available or unavailable time. If the agent chooses to update the various performance statistics in real time then it must be prepared to retroactively reduce the ES, SES, and SEFS counts by 10 and increase the UAS count by 10 when it determines that available time has been entered. It must also be prepared to reduce the CV count by the number of violations counted since the onset of unavailable time. The agent must be similarly prepared to retroactively decrease the UAS count by 10 and increase the ES and CV counts as necessary upon entering available time. A special case exists when the 10 second period Tesink Standards Track [Page 13] RFC 3592 SONET/SDH Objects September 2003 leading to available or unavailable time crosses a 900 second statistics window boundary, as the foregoing description implies that the CV, ES, SES, SEFS, and UAS counts the PREVIOUS interval must be adjusted. In this case successive GETs of the affected sonetPathIntervalSES and sonetPathIntervalUAS objects (and the analogous Line and VT objects also) objects will return differing values if the first GET occurs during the first few seconds of the window. According to ANSI T1.231 unavailable time begins at the _onset_ of 10 contiguous severely errored seconds -- that is, unavailable time starts with the _first_ of the 10 contiguous SESs. Also, while an interface is deemed unavailable all counters for that interface are frozen except for the UAS count. It follows that an implementation which strictly complies with this standard must _not_ increment any counters other than the UAS count -- even temporarily -- as a result of anything that happens during those 10 seconds. Since changes in the signal state lag the data to which they apply by 10 seconds, an ANSI-compliant implementation must pass the one-second statistics through a 10-second delay line prior to updating any counters. That can be done by performing the following steps at the end of each one second interval. i) Read near/far end CV counter and alarm status flags from the hardware. ii) Accumulate the CV counts for the preceding second and compare them to the ES and SES threshold for the layer in question. Update the signal state and shift the one-second CV counts and ES/SES flags into the 10-element delay line. Note that far-end one-second statistics are to be flagged as "absent" during any second in which there is an incoming defect at the layer in question or at any lower layer. iii) Update the current interval statistics using the signal state from the _previous_ update cycle and the one-second CV counts and ES/SES flags shifted out of the 10-element delay line. This approach is further described in Appendix A. An agent may choose to use this approach in lieu of retroactive adjustments to the counters. In any case, a linkDown trap shall be sent only after the agent has determined for certain that the unavailable state has been entered, but the time on the trap will be that of the first UAS (i.e., 10 seconds earlier). A linkUp trap shall be handled similarly. Tesink Standards Track [Page 14] RFC 3592 SONET/SDH Objects September 2003 Unequipped If a Path or VT connection is not provisioned (idle) the SONET equipment will signal this state by transmitting the Path or VT Signal Label as follows: - byte C2 of the STS Path Overhead equal to 0 for an unequipped Path, - byte V5 of the VT Path Overhead equal to 0 for an unequipped VT. Signal Label Mismatch A Path or VT connection is not correctly provisioned if a received Path or VT Signal Label mismatch occurs. A received Signal Label is considered mismatched if it does not equal either the locally provisioned value or the value 'equipped non-specific' (1 hex). Note that any received non-zero Signal Label is considered a locally provisioned value of 'equipped non-specific'. Only in- service, provisioned Path Terminating equipment can detect mismatched Signal labels. It is considered provisioned if it has been configured for a mapping and has been assigned signals to and from which the mapping takes place. While a Path is unequipped or has mismatched signal labels ES/SES counts continue, but these conditions do not themselves contribute to ES/SES. Circuit Identifier This is a character string specified by the circuit vendor, and is useful when communicating with the vendor during the troubleshooting process. 4. Object Definitions SONET-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, transmission FROM SNMPv2-SMI DisplayString, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB PerfCurrentCount, PerfIntervalCount FROM PerfHist-TC-MIB; -- This is the MIB module for the SONET/SDH Interface objects. sonetMIB MODULE-IDENTITY LAST-UPDATED "200308110000Z" ORGANIZATION "IETF AToM MIB Working Group" Tesink Standards Track [Page 15] RFC 3592 SONET/SDH Objects September 2003 CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/atommib-charter.html Mailing Lists: General Discussion: atommib@research.telcordia.com To Subscribe: atommib-request@research.telcordia.com Kaj Tesink Telcordia Technologies Tel: (732) 758-5254 Fax: (732) 758-2269 E-mail: kaj@research.telcordia.com." DESCRIPTION "The MIB module to describe SONET/SDH interface objects. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3592; see the RFC itself for full legal notices." REVISION "200308110000Z" DESCRIPTION "The key changes made to this MIB module since its publication in RFC 2558 are as follows. (1) Corrected typographical error (bellcore1991(2) in sonetSESthresholdSet) (2) Added support for sts192cSTM64(6) and sts768cSTM256(7) in sonetPathCurrentWidth (3) Corrected description of the applicability of VTs for SDH for improved accuracy (4) Added clarification in the SES description that CV counts should be frozen during SESs (5) Corrected typographical errors: - Line Alarm Indication Signal description of the Terminology section (20.5 --> 2.5 seconds) - In the Terminology section sonetSESThresholdSet --> sonetSESthresholdSet " REVISION "199810190000Z" DESCRIPTION "The RFC 2558 version of this MIB module. Tesink Standards Track [Page 16] RFC 3592 SONET/SDH Objects September 2003 The key changes made to this MIB module since its initial publication in RFC 1595 are as follows. (1) The MODULE-IDENTITY has been updated to reflect the changes to the MIB. (2) Where applicable, the textual conventions PerfCurrentCount and PerfIntervalCount from PerfHist-TC-MIB have been used in place of Gauge32. (3) An agent now has the option to delay updates to the various performance counts in lieu of performing retroactive adjustments upon entering into or exiting from unavailable time. This implementation option is described in Appendix A of this memo. (4) In order to make the SONET-MIB more useful for circuit provisioning, the formerly read-only objects sonetMediumType, sonetMediumLineCoding, sonetMediumLineType, and sonetMediumCircuitIdentifier have been given a MAX-ACCESS of read-write. The MIN-ACCESS remains read-only. (5) The DESCRIPTION clause for sonetMediumTimeElapsed has been updated to describe its behaviour if the duration of the current interval exceeds the maximum value. (6) The DESCRIPTION clause for sonetMediumValidIntervals has been updated to describe its behaviour when some intervals may be unavailable, and the object sonetMediumInvalidIntervals has been added to keep count of the number of missing intervals (if any). (7) The object sonetMediumLoopbackConfig has been added to enable or disable loopback configurations. (8) Because the error count thresholds for declaring severely errored seconds that are specified in ANSI T1.231-1993, ITU-T G.826-1995, and ANSI T1.231-1997 are all different from each other and from the thresholds specified in RFC 1595, an enumerated INTEGER object sonetSESthresholdSet has been added to allow an agent to specify which threshold set is in use. Text has been added to Section 3 stating that if this object is not implemented the thresholds specified in RFC 1595 should be assumed, and the table containing those thresholds has been moved to Appendix B of this memo. Tesink Standards Track [Page 17] RFC 3592 SONET/SDH Objects September 2003 (9) A column with SYNTAX TruthValue has been added to each interval table. The purpose of the additional column is to indicate, for each interval, whether the data is valid in the sense intended by ANSI T1.231 clause 9.1.2.2 [T1.231a][T1.231b]. The objects in question are: sonetSectionIntervalValidData sonetLineIntervalValidData sonetFarEndLineIntervalValidData sonetPathIntervalValidData sonetFarEndPathIntervalValidData sonetVTIntervalValidData sonetFarEndVTIntervalValidData (10) The ranges for sonetPathCurrentStatus and sonetVTCurrentStatus have been made consistent with the DESCRIPTION clauses. (11) The conformance information has been updated. Previous conformance information from RFC 1595 has been deprecated. Some typographical errors in the deprecated section have been corrected in order to prevent MIB compilation errors." REVISION "199401030000Z" DESCRIPTION "The RFC 1595 version of this MIB module." ::= { transmission 39 } -- This is the MIB module for the SONET/SDH objects sonetObjects OBJECT IDENTIFIER ::= { sonetMIB 1 } sonetObjectsPath OBJECT IDENTIFIER ::= { sonetMIB 2 } sonetObjectsVT OBJECT IDENTIFIER ::= { sonetMIB 3 } -- groups in the SONET/SDH MIB module sonetMedium OBJECT IDENTIFIER ::= { sonetObjects 1 } sonetSection OBJECT IDENTIFIER ::= { sonetObjects 2 } sonetLine OBJECT IDENTIFIER ::= { sonetObjects 3 } sonetFarEndLine OBJECT IDENTIFIER ::= { sonetObjects 4 } Tesink Standards Track [Page 18] RFC 3592 SONET/SDH Objects September 2003 sonetPath OBJECT IDENTIFIER ::= { sonetObjectsPath 1 } sonetFarEndPath OBJECT IDENTIFIER ::= { sonetObjectsPath 2 } sonetVT OBJECT IDENTIFIER ::= { sonetObjectsVT 1 } sonetFarEndVT OBJECT IDENTIFIER ::= { sonetObjectsVT 2 } -- the SONET/SDH Medium group -- SONET/SDH interfaces for some applications may be electrical -- interfaces and not optical interfaces. This group handles -- the configuration information for both optical SONET/SDH -- interfaces and electrical SONET/SDH interfaces. sonetMediumTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetMediumEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Medium table." ::= { sonetMedium 1 } sonetMediumEntry OBJECT-TYPE SYNTAX SonetMediumEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Medium table." INDEX { ifIndex } ::= { sonetMediumTable 1 } SonetMediumEntry ::= SEQUENCE { sonetMediumType INTEGER, sonetMediumTimeElapsed Integer32, sonetMediumValidIntervals Integer32, sonetMediumLineCoding INTEGER, sonetMediumLineType INTEGER, sonetMediumCircuitIdentifier DisplayString, sonetMediumInvalidIntervals Integer32, sonetMediumLoopbackConfig BITS } sonetMediumType OBJECT-TYPE SYNTAX INTEGER { sonet(1), sdh(2) Tesink Standards Track [Page 19] RFC 3592 SONET/SDH Objects September 2003 } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable identifies whether a SONET or a SDH signal is used across this interface." ::= { sonetMediumEntry 1 } sonetMediumTimeElapsed OBJECT-TYPE SYNTAX Integer32 (1..900) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds, including partial seconds, that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, the agent will return the maximum value." ::= { sonetMediumEntry 2 } sonetMediumValidIntervals OBJECT-TYPE SYNTAX Integer32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous 15-minute intervals for which data was collected. A SONET/SDH interface must be capable of supporting at least n intervals. The minimum value of n is 4. The default of n is 32. The maximum value of n is 96. The value will be unless the measurement was (re-)started within the last (*15) minutes, in which case the value will be the number of complete 15 minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy) it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available. " ::= { sonetMediumEntry 3 } sonetMediumLineCoding OBJECT-TYPE SYNTAX INTEGER { sonetMediumOther(1), sonetMediumB3ZS(2), Tesink Standards Track [Page 20] RFC 3592 SONET/SDH Objects September 2003 sonetMediumCMI(3), sonetMediumNRZ(4), sonetMediumRZ(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable describes the line coding for this interface. The B3ZS and CMI are used for electrical SONET/SDH signals (STS-1 and STS-3). The Non-Return to Zero (NRZ) and the Return to Zero are used for optical SONET/SDH signals." ::= { sonetMediumEntry 4 } sonetMediumLineType OBJECT-TYPE SYNTAX INTEGER { sonetOther(1), sonetShortSingleMode(2), sonetLongSingleMode(3), sonetMultiMode(4), sonetCoax(5), sonetUTP(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable describes the line type for this interface. The line types are Short and Long Range Single Mode fiber or Multi-Mode fiber interfaces, and coax and UTP for electrical interfaces. The value sonetOther should be used when the Line Type is not one of the listed values." ::= { sonetMediumEntry 5 } sonetMediumCircuitIdentifier OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This variable contains the transmission vendor's circuit identifier, for the purpose of facilitating troubleshooting. Note that the circuit identifier, if available, is also represented by ifPhysAddress." ::= { sonetMediumEntry 6 } Tesink Standards Track [Page 21] RFC 3592 SONET/SDH Objects September 2003 sonetMediumInvalidIntervals OBJECT-TYPE SYNTAX Integer32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to sonetMediumValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { sonetMediumEntry 7 } sonetMediumLoopbackConfig OBJECT-TYPE SYNTAX BITS { sonetNoLoop(0), sonetFacilityLoop(1), sonetTerminalLoop(2), sonetOtherLoop(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current loopback state of the SONET/SDH interface. The values mean: sonetNoLoop Not in the loopback state. A device that is not capable of performing a loopback on this interface shall always return this value. sonetFacilityLoop The received signal at this interface is looped back out through the corresponding transmitter in the return direction. sonetTerminalLoop The signal that is about to be transmitted is connected to the associated incoming receiver. sonetOtherLoop Loopbacks that are not defined here." ::= { sonetMediumEntry 8 } sonetSESthresholdSet OBJECT-TYPE SYNTAX INTEGER { other(1), bellcore1991(2), Tesink Standards Track [Page 22] RFC 3592 SONET/SDH Objects September 2003 ansi1993(3), itu1995(4), ansi1997(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "An enumerated integer indicating which recognized set of SES thresholds that the agent uses for determining severely errored seconds and unavailable time. other(1) None of the following. bellcore1991(2) Bellcore TR-NWT-000253, 1991 [TR253], or ANSI T1M1.3/93-005R2, 1993 [T1M1.3]. See also Appendix B. ansi1993(3) ANSI T1.231, 1993 [T1.231a], or Bellcore GR-253-CORE, Issue 2, 1995 [GR253] itu1995(4) ITU Recommendation G.826, 1995 [G.826] ansi1997(5) ANSI T1.231, 1997 [T1.231b] If a manager changes the value of this object then the SES statistics collected prior to this change must be invalidated." ::= { sonetMedium 2 } -- the SONET/SDH Section group -- this group consists of 2 tables: -- - the SONET/SDH Section Current Table -- - the SONET/SDH Section Interval Table -- the SONET/SDH Section Current Table -- The SONET/SDH Section -- current table contains various statistics -- being collected for the current 15 minute interval. Tesink Standards Track [Page 23] RFC 3592 SONET/SDH Objects September 2003 sonetSectionCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetSectionCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Section Current table." ::= { sonetSection 1 } sonetSectionCurrentEntry OBJECT-TYPE SYNTAX SonetSectionCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Section Current table." INDEX { ifIndex } ::= { sonetSectionCurrentTable 1 } SonetSectionCurrentEntry ::= SEQUENCE { sonetSectionCurrentStatus Integer32, sonetSectionCurrentESs PerfCurrentCount, sonetSectionCurrentSESs PerfCurrentCount, sonetSectionCurrentSEFSs PerfCurrentCount, sonetSectionCurrentCVs PerfCurrentCount } sonetSectionCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..6) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the status of the interface. The sonetSectionCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects simultaneously. The sonetSectionNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetSectionNoDefect 2 sonetSectionLOS 4 sonetSectionLOF" ::= { sonetSectionCurrentEntry 1 } Tesink Standards Track [Page 24] RFC 3592 SONET/SDH Objects September 2003 sonetSectionCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 2 } sonetSectionCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 3 } sonetSectionCurrentSEFSs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 4 } sonetSectionCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Section in the current 15 minute interval." ::= { sonetSectionCurrentEntry 5 } -- the SONET/SDH Section Interval Table -- The SONET/SDH Section Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of Tesink Standards Track [Page 25] RFC 3592 SONET/SDH Objects September 2003 -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetSectionIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetSectionIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Section Interval table." ::= { sonetSection 2 } sonetSectionIntervalEntry OBJECT-TYPE SYNTAX SonetSectionIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Section Interval table." INDEX { ifIndex, sonetSectionIntervalNumber } ::= { sonetSectionIntervalTable 1 } SonetSectionIntervalEntry ::= SEQUENCE { sonetSectionIntervalNumber Integer32, sonetSectionIntervalESs PerfIntervalCount, sonetSectionIntervalSESs PerfIntervalCount, sonetSectionIntervalSEFSs PerfIntervalCount, sonetSectionIntervalCVs PerfIntervalCount, sonetSectionIntervalValidData TruthValue } sonetSectionIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetSectionIntervalEntry 1 } Tesink Standards Track [Page 26] RFC 3592 SONET/SDH Objects September 2003 sonetSectionIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." ::= { sonetSectionIntervalEntry 2 } sonetSectionIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." ::= { sonetSectionIntervalEntry 3 } sonetSectionIntervalSEFSs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." ::= { sonetSectionIntervalEntry 4 } sonetSectionIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Section in a particular 15-minute interval in the past 24 hours." ::= { sonetSectionIntervalEntry 5 } Tesink Standards Track [Page 27] RFC 3592 SONET/SDH Objects September 2003 sonetSectionIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { sonetSectionIntervalEntry 6 } -- the SONET/SDH Line group -- this group consists of 2 tables: -- - the SONET/SDH Line Current Table -- - the SONET/SDH Line Interval Table -- the SONET/SDH Line Current Table -- The SONET/SDH Line -- current table contains various statistics -- being collected for the current 15 minute interval. sonetLineCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Line Current table." ::= { sonetLine 1 } sonetLineCurrentEntry OBJECT-TYPE SYNTAX SonetLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Line Current table." INDEX { ifIndex } ::= { sonetLineCurrentTable 1 } SonetLineCurrentEntry ::= SEQUENCE { sonetLineCurrentStatus Integer32, sonetLineCurrentESs PerfCurrentCount, sonetLineCurrentSESs PerfCurrentCount, sonetLineCurrentCVs PerfCurrentCount, sonetLineCurrentUASs PerfCurrentCount } Tesink Standards Track [Page 28] RFC 3592 SONET/SDH Objects September 2003 sonetLineCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..6) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the status of the interface. The sonetLineCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects simultaneously. The sonetLineNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetLineNoDefect 2 sonetLineAIS 4 sonetLineRDI" ::= { sonetLineCurrentEntry 1 } sonetLineCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 2 } sonetLineCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 3 } sonetLineCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current Tesink Standards Track [Page 29] RFC 3592 SONET/SDH Objects September 2003 DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 4 } sonetLineCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a SONET/SDH Line in the current 15 minute interval." ::= { sonetLineCurrentEntry 5 } -- the SONET/SDH Line Interval Table -- The SONET/SDH Line Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetLineIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Line Interval table." ::= { sonetLine 2 } sonetLineIntervalEntry OBJECT-TYPE SYNTAX SonetLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Line Interval table." INDEX { ifIndex, sonetLineIntervalNumber } ::= { sonetLineIntervalTable 1 } Tesink Standards Track [Page 30] RFC 3592 SONET/SDH Objects September 2003 SonetLineIntervalEntry ::= SEQUENCE { sonetLineIntervalNumber Integer32, sonetLineIntervalESs PerfIntervalCount, sonetLineIntervalSESs PerfIntervalCount, sonetLineIntervalCVs PerfIntervalCount, sonetLineIntervalUASs PerfIntervalCount, sonetLineIntervalValidData TruthValue } sonetLineIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetLineIntervalEntry 1 } sonetLineIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." ::= { sonetLineIntervalEntry 2 } sonetLineIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." ::= { sonetLineIntervalEntry 3 } Tesink Standards Track [Page 31] RFC 3592 SONET/SDH Objects September 2003 sonetLineIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." ::= { sonetLineIntervalEntry 4 } sonetLineIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a SONET/SDH Line in a particular 15-minute interval in the past 24 hours." ::= { sonetLineIntervalEntry 5 } sonetLineIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { sonetLineIntervalEntry 6 } -- The SONET/SDH Far End Line group. -- This group may only be implemented by SONET/SDH (LTEs) -- systems that provide for a far end block error (FEBE) -- information at the SONET/SDH Line Layer. -- This group consists of two tables: -- SONET/SDH Far End Line Current Table -- SONET/SDH Far End Line Interval Table -- The SONET/SDH Far End Line Current Table -- The SONET/SDH Far End Line Current table contains -- various statistics being -- collected for the current 15 minute interval. -- The statistics are collected from the far end Tesink Standards Track [Page 32] RFC 3592 SONET/SDH Objects September 2003 -- block error code (FEBE) -- within the third Z2 byte of the Line Overhead -- in Broadband ISDN applications. -- The definitions are the same as described for -- the near-end information. sonetFarEndLineCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Line Current table." ::= { sonetFarEndLine 1 } sonetFarEndLineCurrentEntry OBJECT-TYPE SYNTAX SonetFarEndLineCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Line Current table." INDEX { ifIndex } ::= { sonetFarEndLineCurrentTable 1 } SonetFarEndLineCurrentEntry ::= SEQUENCE { sonetFarEndLineCurrentESs PerfCurrentCount, sonetFarEndLineCurrentSESs PerfCurrentCount, sonetFarEndLineCurrentCVs PerfCurrentCount, sonetFarEndLineCurrentUASs PerfCurrentCount } sonetFarEndLineCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 1 } sonetFarEndLineCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds Tesink Standards Track [Page 33] RFC 3592 SONET/SDH Objects September 2003 encountered by a SONET/SDH Medium/Section/Line interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 2 } sonetFarEndLineCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH Medium/Section/Line interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 3 } sonetFarEndLineCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH Medium/Section/Line interface in the current 15 minute interval." ::= { sonetFarEndLineCurrentEntry 4 } -- The SONET/SDH Far End Line Interval Table -- The SONET/SDH Far End Line Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetFarEndLineIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Line Interval table." Tesink Standards Track [Page 34] RFC 3592 SONET/SDH Objects September 2003 ::= { sonetFarEndLine 2 } sonetFarEndLineIntervalEntry OBJECT-TYPE SYNTAX SonetFarEndLineIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Line Interval table." INDEX { ifIndex, sonetFarEndLineIntervalNumber } ::= { sonetFarEndLineIntervalTable 1 } SonetFarEndLineIntervalEntry ::= SEQUENCE { sonetFarEndLineIntervalNumber Integer32, sonetFarEndLineIntervalESs PerfIntervalCount, sonetFarEndLineIntervalSESs PerfIntervalCount, sonetFarEndLineIntervalCVs PerfIntervalCount, sonetFarEndLineIntervalUASs PerfIntervalCount, sonetFarEndLineIntervalValidData TruthValue } sonetFarEndLineIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetFarEndLineIntervalEntry 1 } sonetFarEndLineIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." Tesink Standards Track [Page 35] RFC 3592 SONET/SDH Objects September 2003 ::= { sonetFarEndLineIntervalEntry 2 } sonetFarEndLineIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndLineIntervalEntry 3 } sonetFarEndLineIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndLineIntervalEntry 4 } sonetFarEndLineIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH Line interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndLineIntervalEntry 5 } sonetFarEndLineIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." Tesink Standards Track [Page 36] RFC 3592 SONET/SDH Objects September 2003 ::= { sonetFarEndLineIntervalEntry 6 } -- the SONET/SDH Path group -- this group consists of 2 tables: -- - the SONET/SDH Path Current Table -- - the SONET/SDH Path Interval Table -- the SONET/SDH Path Current Table -- The SONET/SDH Path -- current table contains various statistics -- being collected for the current 15 minute interval. sonetPathCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Path Current table." ::= { sonetPath 1 } sonetPathCurrentEntry OBJECT-TYPE SYNTAX SonetPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Path Current table." INDEX { ifIndex } ::= { sonetPathCurrentTable 1 } SonetPathCurrentEntry ::= SEQUENCE { sonetPathCurrentWidth INTEGER, sonetPathCurrentStatus Integer32, sonetPathCurrentESs PerfCurrentCount, sonetPathCurrentSESs PerfCurrentCount, sonetPathCurrentCVs PerfCurrentCount, sonetPathCurrentUASs PerfCurrentCount } sonetPathCurrentWidth OBJECT-TYPE SYNTAX INTEGER { sts1(1), sts3cSTM1(2), sts12cSTM4(3), sts24c(4), sts48cSTM16(5), Tesink Standards Track [Page 37] RFC 3592 SONET/SDH Objects September 2003 sts192cSTM64(6), sts768cSTM256(7) } MAX-ACCESS read-write STATUS current DESCRIPTION "A value that indicates the type of the SONET/SDH Path. For SONET, the assigned types are the STS-Nc SPEs, where N = 1, 3, 12, 24, 48, 192 and 768. STS-1 is equal to 51.84 Mbps. For SDH, the assigned types are the STM-Nc VCs, where N = 1, 4, 16, 64 and 256." ::= { sonetPathCurrentEntry 1 } sonetPathCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..62) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the status of the interface. The sonetPathCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects simultaneously. The sonetPathNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetPathNoDefect 2 sonetPathSTSLOP 4 sonetPathSTSAIS 8 sonetPathSTSRDI 16 sonetPathUnequipped 32 sonetPathSignalLabelMismatch" ::= { sonetPathCurrentEntry 2 } sonetPathCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 3 } Tesink Standards Track [Page 38] RFC 3592 SONET/SDH Objects September 2003 sonetPathCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 4 } sonetPathCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 5 } sonetPathCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a Path in the current 15 minute interval." ::= { sonetPathCurrentEntry 6 } -- the SONET/SDH Path Interval Table -- The SONET/SDH Path Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. Tesink Standards Track [Page 39] RFC 3592 SONET/SDH Objects September 2003 sonetPathIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Path Interval table." ::= { sonetPath 2 } sonetPathIntervalEntry OBJECT-TYPE SYNTAX SonetPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Path Interval table." INDEX { ifIndex, sonetPathIntervalNumber } ::= { sonetPathIntervalTable 1 } SonetPathIntervalEntry ::= SEQUENCE { sonetPathIntervalNumber Integer32, sonetPathIntervalESs PerfIntervalCount, sonetPathIntervalSESs PerfIntervalCount, sonetPathIntervalCVs PerfIntervalCount, sonetPathIntervalUASs PerfIntervalCount, sonetPathIntervalValidData TruthValue } sonetPathIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetPathIntervalEntry 1 } sonetPathIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION Tesink Standards Track [Page 40] RFC 3592 SONET/SDH Objects September 2003 "The counter associated with the number of Errored Seconds encountered by a SONET/SDH Path in a particular 15-minute interval in the past 24 hours." ::= { sonetPathIntervalEntry 2 } sonetPathIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH Path in a particular 15-minute interval in the past 24 hours." ::= { sonetPathIntervalEntry 3 } sonetPathIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH Path in a particular 15-minute interval in the past 24 hours." ::= { sonetPathIntervalEntry 4 } sonetPathIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a Path in a particular 15-minute interval in the past 24 hours." ::= { sonetPathIntervalEntry 5 } sonetPathIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this Tesink Standards Track [Page 41] RFC 3592 SONET/SDH Objects September 2003 interval is valid." ::= { sonetPathIntervalEntry 6 } -- The SONET/SDH Far End Path group -- This group consists of two tables: -- - SONET/SDH Far End Path Current Table -- - SONET/SDH Far End Path Interval Table -- The SONET/SDH Far End Path Current Table -- The SONET/SDH Far End Path Current table -- contains various statistics -- being collected for the current 15 minute interval. -- The statistics are collected from -- the far end block error code -- (FEBE) within the G1 byte of the Path Overhead. -- The definitions are the same as described for -- the near-end information. sonetFarEndPathCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Path Current table." ::= { sonetFarEndPath 1 } sonetFarEndPathCurrentEntry OBJECT-TYPE SYNTAX SonetFarEndPathCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Path Current table." INDEX { ifIndex } ::= { sonetFarEndPathCurrentTable 1 } SonetFarEndPathCurrentEntry ::= SEQUENCE { sonetFarEndPathCurrentESs PerfCurrentCount, sonetFarEndPathCurrentSESs PerfCurrentCount, sonetFarEndPathCurrentCVs PerfCurrentCount, sonetFarEndPathCurrentUASs PerfCurrentCount } Tesink Standards Track [Page 42] RFC 3592 SONET/SDH Objects September 2003 sonetFarEndPathCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 1 } sonetFarEndPathCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH Path interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 2 } sonetFarEndPathCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH Path interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 3 } sonetFarEndPathCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH Path interface in the current 15 minute interval." ::= { sonetFarEndPathCurrentEntry 4 } Tesink Standards Track [Page 43] RFC 3592 SONET/SDH Objects September 2003 -- The SONET/SDH Far End Path Interval Table -- The SONET/SDH Far End Path Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetFarEndPathIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End Path Interval table." ::= { sonetFarEndPath 2 } sonetFarEndPathIntervalEntry OBJECT-TYPE SYNTAX SonetFarEndPathIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End Path Interval table." INDEX { ifIndex, sonetFarEndPathIntervalNumber } ::= { sonetFarEndPathIntervalTable 1 } SonetFarEndPathIntervalEntry ::= SEQUENCE { sonetFarEndPathIntervalNumber Integer32, sonetFarEndPathIntervalESs PerfIntervalCount, sonetFarEndPathIntervalSESs PerfIntervalCount, sonetFarEndPathIntervalCVs PerfIntervalCount, sonetFarEndPathIntervalUASs PerfIntervalCount, sonetFarEndPathIntervalValidData TruthValue } sonetFarEndPathIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. Tesink Standards Track [Page 44] RFC 3592 SONET/SDH Objects September 2003 The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetFarEndPathIntervalEntry 1 } sonetFarEndPathIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH Path interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 2 } sonetFarEndPathIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH Path interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 3 } sonetFarEndPathIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH Path interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 4 } Tesink Standards Track [Page 45] RFC 3592 SONET/SDH Objects September 2003 sonetFarEndPathIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH Path interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndPathIntervalEntry 5 } sonetFarEndPathIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { sonetFarEndPathIntervalEntry 6 } -- the SONET/SDH Virtual Tributary group -- this group consists of 2 tables: -- - the SONET/SDH VT Current Table -- - the SONET/SDH VT Interval Table -- Corresponding SDH signals for SONET VTs are -- as follows: -- A VT1.5 = TU11 -- A VT2 = TU12 -- A VT3 = none -- none = TU3 -- A VT6 = TU2 -- the SONET/SDH VT Current Table -- The SONET/SDH VT current table -- contains various statistics -- being collected for the -- current 15 minute interval. Tesink Standards Track [Page 46] RFC 3592 SONET/SDH Objects September 2003 sonetVTCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH VT Current table." ::= { sonetVT 1 } sonetVTCurrentEntry OBJECT-TYPE SYNTAX SonetVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH VT Current table." INDEX { ifIndex } ::= { sonetVTCurrentTable 1 } SonetVTCurrentEntry ::= SEQUENCE { sonetVTCurrentWidth INTEGER, sonetVTCurrentStatus Integer32, sonetVTCurrentESs PerfCurrentCount, sonetVTCurrentSESs PerfCurrentCount, sonetVTCurrentCVs PerfCurrentCount, sonetVTCurrentUASs PerfCurrentCount } sonetVTCurrentWidth OBJECT-TYPE SYNTAX INTEGER { vtWidth15VC11(1), vtWidth2VC12(2), vtWidth3(3), vtWidth6VC2(4), vtWidth6c(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "A value that indicates the type of the SONET VT and SDH VC. Assigned widths are VT1.5/VC11, VT2/VC12, VT3, VT6/VC2, and VT6c." ::= { sonetVTCurrentEntry 1 } Tesink Standards Track [Page 47] RFC 3592 SONET/SDH Objects September 2003 sonetVTCurrentStatus OBJECT-TYPE SYNTAX Integer32 (1..126) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the status of the interface. The sonetVTCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects and failures simultaneously. The sonetVTNoDefect should be set if and only if no other flag is set. The various bit positions are: 1 sonetVTNoDefect 2 sonetVTLOP 4 sonetVTPathAIS 8 sonetVTPathRDI 16 sonetVTPathRFI 32 sonetVTUnequipped 64 sonetVTSignalLabelMismatch" ::= { sonetVTCurrentEntry 2 } sonetVTCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 3 } sonetVTCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 4 } Tesink Standards Track [Page 48] RFC 3592 SONET/SDH Objects September 2003 sonetVTCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 5 } sonetVTCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a VT in the current 15 minute interval." ::= { sonetVTCurrentEntry 6 } -- the SONET/SDH VT Interval Table -- The SONET/SDH VT Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetVTIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH VT Interval table." ::= { sonetVT 2 } sonetVTIntervalEntry OBJECT-TYPE SYNTAX SonetVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH VT Interval table." INDEX { ifIndex, Tesink Standards Track [Page 49] RFC 3592 SONET/SDH Objects September 2003 sonetVTIntervalNumber } ::= { sonetVTIntervalTable 1 } SonetVTIntervalEntry ::= SEQUENCE { sonetVTIntervalNumber Integer32, sonetVTIntervalESs PerfIntervalCount, sonetVTIntervalSESs PerfIntervalCount, sonetVTIntervalCVs PerfIntervalCount, sonetVTIntervalUASs PerfIntervalCount, sonetVTIntervalValidData TruthValue } sonetVTIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetVTIntervalEntry 1 } sonetVTIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Errored Seconds encountered by a SONET/SDH VT in a particular 15-minute interval in the past 24 hours." ::= { sonetVTIntervalEntry 2 } sonetVTIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Seconds encountered by a SONET/SDH VT in a particular 15-minute interval Tesink Standards Track [Page 50] RFC 3592 SONET/SDH Objects September 2003 in the past 24 hours." ::= { sonetVTIntervalEntry 3 } sonetVTIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Coding Violations encountered by a SONET/SDH VT in a particular 15-minute interval in the past 24 hours." ::= { sonetVTIntervalEntry 4 } sonetVTIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by a VT in a particular 15-minute interval in the past 24 hours." ::= { sonetVTIntervalEntry 5 } sonetVTIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { sonetVTIntervalEntry 6 } -- The SONET/SDH Far End VT group -- This group consists of two tables: -- SONET/SDH Far End VT Current Table -- SONET/SDH Far End VT Interval Table -- The SONET/SDH Far End VT Current -- The SONET/SDH Far End VT Current table -- contains various statistics -- being collected for the current 15 minute interval. -- The statistics are collected from -- the far end block error code -- (FEBE) within the G1 byte of the VT Overhead. Tesink Standards Track [Page 51] RFC 3592 SONET/SDH Objects September 2003 -- The definitions are the same as described for -- the near-end information. sonetFarEndVTCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End VT Current table." ::= { sonetFarEndVT 1 } sonetFarEndVTCurrentEntry OBJECT-TYPE SYNTAX SonetFarEndVTCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End VT Current table." INDEX { ifIndex } ::= { sonetFarEndVTCurrentTable 1 } SonetFarEndVTCurrentEntry ::= SEQUENCE { sonetFarEndVTCurrentESs PerfCurrentCount, sonetFarEndVTCurrentSESs PerfCurrentCount, sonetFarEndVTCurrentCVs PerfCurrentCount, sonetFarEndVTCurrentUASs PerfCurrentCount } sonetFarEndVTCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH interface in the current 15 minute interval." ::= { sonetFarEndVTCurrentEntry 1 } sonetFarEndVTCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH VT interface in the current 15 minute interval." Tesink Standards Track [Page 52] RFC 3592 SONET/SDH Objects September 2003 ::= { sonetFarEndVTCurrentEntry 2 } sonetFarEndVTCurrentCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH VT interface in the current 15 minute interval." ::= { sonetFarEndVTCurrentEntry 3 } sonetFarEndVTCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH VT interface in the current 15 minute interval." ::= { sonetFarEndVTCurrentEntry 4 } -- The SONET/SDH Far End VT Interval Table -- The SONET/SDH Far End VT Interval Table -- contains various statistics -- collected by each system over a maximum -- of the previous 24 hours of -- operation. The past 24 hours may be broken into 96 -- completed 15 minute intervals. -- A system is required to store at -- least 4 completed 15 minute interval. -- The default value is 32 intervals. sonetFarEndVTIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF SonetFarEndVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SONET/SDH Far End VT Interval table." ::= { sonetFarEndVT 2 } Tesink Standards Track [Page 53] RFC 3592 SONET/SDH Objects September 2003 sonetFarEndVTIntervalEntry OBJECT-TYPE SYNTAX SonetFarEndVTIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the SONET/SDH Far End VT Interval table." INDEX { ifIndex, sonetFarEndVTIntervalNumber } ::= { sonetFarEndVTIntervalTable 1 } SonetFarEndVTIntervalEntry ::= SEQUENCE { sonetFarEndVTIntervalNumber Integer32, sonetFarEndVTIntervalESs PerfIntervalCount, sonetFarEndVTIntervalSESs PerfIntervalCount, sonetFarEndVTIntervalCVs PerfIntervalCount, sonetFarEndVTIntervalUASs PerfIntervalCount, sonetFarEndVTIntervalValidData TruthValue } sonetFarEndVTIntervalNumber OBJECT-TYPE SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1." ::= { sonetFarEndVTIntervalEntry 1 } sonetFarEndVTIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Errored Seconds encountered by a SONET/SDH VT interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 2 } Tesink Standards Track [Page 54] RFC 3592 SONET/SDH Objects September 2003 sonetFarEndVTIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Severely Errored Seconds encountered by a SONET/SDH VT interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 3 } sonetFarEndVTIntervalCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Coding Violations reported via the far end block error count encountered by a SONET/SDH VT interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 4 } sonetFarEndVTIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End Unavailable Seconds encountered by a SONET/SDH VT interface in a particular 15-minute interval in the past 24 hours." ::= { sonetFarEndVTIntervalEntry 5 } sonetFarEndVTIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { sonetFarEndVTIntervalEntry 6 } Tesink Standards Track [Page 55] RFC 3592 SONET/SDH Objects September 2003 -- conformance information sonetConformance OBJECT IDENTIFIER ::= { sonetMIB 4 } sonetGroups OBJECT IDENTIFIER ::= { sonetConformance 1 } sonetCompliances OBJECT IDENTIFIER ::= { sonetConformance 2 } -- deprecated compliance statement sonetCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SONET/SDH interfaces." MODULE -- this module MANDATORY-GROUPS { sonetMediumStuff, sonetSectionStuff } GROUP sonetLineStuff DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries." GROUP sonetFarEndLineStuff DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries, and that provide for a far end block error (FEBE) information at the SONET/SDH Line Layer." GROUP sonetPathStuff DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries." OBJECT sonetPathCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndPathStuff DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries, and that process Far End information." Tesink Standards Track [Page 56] RFC 3592 SONET/SDH Objects September 2003 GROUP sonetVTStuff DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Virtual Tributaries." OBJECT sonetVTCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndVTStuff DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate the SONET/SDH floating Virtual Tributaries, and that process Far End information." ::= { sonetCompliances 1 } -- current compliance statements sonetCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SONET/SDH interfaces." MODULE -- this module MANDATORY-GROUPS { sonetMediumStuff2, sonetSectionStuff2 } OBJECT sonetMediumType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sonetMediumLineCoding MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sonetMediumLineType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sonetMediumCircuitIdentifier MIN-ACCESS read-only DESCRIPTION Tesink Standards Track [Page 57] RFC 3592 SONET/SDH Objects September 2003 "Write access is not required." OBJECT sonetMediumLoopbackConfig MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT sonetSESthresholdSet MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the enumerated values need be supported." GROUP sonetLineStuff2 DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries." GROUP sonetFarEndLineStuff2 DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Lines, Paths or Virtual Tributaries, and that provide for a far end block error (FEBE) information at the SONET/SDH Line Layer." GROUP sonetPathStuff2 DESCRIPTION "Implementation of this group is mandatory for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries." OBJECT sonetPathCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndPathStuff2 DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate SONET/SDH Paths or Virtual Tributaries, and that process Far End information." GROUP sonetVTStuff2 DESCRIPTION "Implementation of this group is mandatory for all Tesink Standards Track [Page 58] RFC 3592 SONET/SDH Objects September 2003 SONET/SDH systems that terminate SONET/SDH Virtual Tributaries." OBJECT sonetVTCurrentWidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP sonetFarEndVTStuff2 DESCRIPTION "Implementation of this group is optional for all SONET/SDH systems that terminate the SONET/SDH floating Virtual Tributaries, and that process Far End information." ::= { sonetCompliances 2 } -- units of conformance -- deprecated groups sonetMediumStuff OBJECT-GROUP OBJECTS { sonetMediumType, sonetMediumTimeElapsed, sonetMediumValidIntervals, sonetMediumLineCoding, sonetMediumLineType, sonetMediumCircuitIdentifier } STATUS deprecated DESCRIPTION "A collection of objects providing configuration information applicable to all SONET/SDH interfaces." ::= { sonetGroups 1 } sonetSectionStuff OBJECT-GROUP OBJECTS { sonetSectionCurrentStatus, sonetSectionCurrentESs, sonetSectionCurrentSESs, sonetSectionCurrentSEFSs, sonetSectionCurrentCVs, sonetSectionIntervalESs, sonetSectionIntervalSESs, sonetSectionIntervalSEFSs, sonetSectionIntervalCVs } STATUS deprecated DESCRIPTION "A collection of objects providing information Tesink Standards Track [Page 59] RFC 3592 SONET/SDH Objects September 2003 specific to SONET/SDH Section interfaces." ::= { sonetGroups 2 } sonetLineStuff OBJECT-GROUP OBJECTS { sonetLineCurrentStatus, sonetLineCurrentESs, sonetLineCurrentSESs, sonetLineCurrentCVs, sonetLineCurrentUASs, sonetLineIntervalESs, sonetLineIntervalSESs, sonetLineIntervalCVs, sonetLineIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces." ::= { sonetGroups 3 } sonetFarEndLineStuff OBJECT-GROUP OBJECTS { sonetFarEndLineCurrentESs, sonetFarEndLineCurrentSESs, sonetFarEndLineCurrentCVs, sonetFarEndLineCurrentUASs, sonetFarEndLineIntervalESs, sonetFarEndLineIntervalSESs, sonetFarEndLineIntervalCVs, sonetFarEndLineIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces, and maintaining Line Far End information." ::= { sonetGroups 4 } sonetPathStuff OBJECT-GROUP OBJECTS { sonetPathCurrentWidth, sonetPathCurrentStatus, sonetPathCurrentESs, sonetPathCurrentSESs, sonetPathCurrentCVs, sonetPathCurrentUASs, sonetPathIntervalESs, sonetPathIntervalSESs, sonetPathIntervalCVs, sonetPathIntervalUASs } STATUS deprecated DESCRIPTION Tesink Standards Track [Page 60] RFC 3592 SONET/SDH Objects September 2003 "A collection of objects providing information specific to SONET/SDH Path interfaces." ::= { sonetGroups 5 } sonetFarEndPathStuff OBJECT-GROUP OBJECTS { sonetFarEndPathCurrentESs, sonetFarEndPathCurrentSESs, sonetFarEndPathCurrentCVs, sonetFarEndPathCurrentUASs, sonetFarEndPathIntervalESs, sonetFarEndPathIntervalSESs, sonetFarEndPathIntervalCVs, sonetFarEndPathIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH Path interfaces, and maintaining Path Far End information." ::= { sonetGroups 6 } sonetVTStuff OBJECT-GROUP OBJECTS { sonetVTCurrentWidth, sonetVTCurrentStatus, sonetVTCurrentESs, sonetVTCurrentSESs, sonetVTCurrentCVs, sonetVTCurrentUASs, sonetVTIntervalESs, sonetVTIntervalSESs, sonetVTIntervalCVs, sonetVTIntervalUASs } STATUS deprecated DESCRIPTION "A collection of objects providing information specific to SONET/SDH VT interfaces." ::= { sonetGroups 7 } sonetFarEndVTStuff OBJECT-GROUP OBJECTS { sonetFarEndVTCurrentESs, sonetFarEndVTCurrentSESs, sonetFarEndVTCurrentCVs, sonetFarEndVTCurrentUASs, sonetFarEndVTIntervalESs, sonetFarEndVTIntervalSESs, sonetFarEndVTIntervalCVs, sonetFarEndVTIntervalUASs } STATUS deprecated DESCRIPTION Tesink Standards Track [Page 61] RFC 3592 SONET/SDH Objects September 2003 "A collection of objects providing information specific to SONET/SDH VT interfaces, and maintaining VT Far End information." ::= { sonetGroups 8 } -- current groups sonetMediumStuff2 OBJECT-GROUP OBJECTS { sonetMediumType, sonetMediumTimeElapsed, sonetMediumValidIntervals, sonetMediumLineCoding, sonetMediumLineType, sonetMediumCircuitIdentifier, sonetMediumInvalidIntervals, sonetMediumLoopbackConfig, sonetSESthresholdSet } STATUS current DESCRIPTION "A collection of objects providing configuration information applicable to all SONET/SDH interfaces." ::= { sonetGroups 9 } sonetSectionStuff2 OBJECT-GROUP OBJECTS { sonetSectionCurrentStatus, sonetSectionCurrentESs, sonetSectionCurrentSESs, sonetSectionCurrentSEFSs, sonetSectionCurrentCVs, sonetSectionIntervalESs, sonetSectionIntervalSESs, sonetSectionIntervalSEFSs, sonetSectionIntervalCVs, sonetSectionIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Section interfaces." ::= { sonetGroups 10 } sonetLineStuff2 OBJECT-GROUP OBJECTS { sonetLineCurrentStatus, sonetLineCurrentESs, sonetLineCurrentSESs, sonetLineCurrentCVs, sonetLineCurrentUASs, sonetLineIntervalESs, sonetLineIntervalSESs, Tesink Standards Track [Page 62] RFC 3592 SONET/SDH Objects September 2003 sonetLineIntervalCVs, sonetLineIntervalUASs, sonetLineIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces." ::= { sonetGroups 11 } sonetPathStuff2 OBJECT-GROUP OBJECTS { sonetPathCurrentWidth, sonetPathCurrentStatus, sonetPathCurrentESs, sonetPathCurrentSESs, sonetPathCurrentCVs, sonetPathCurrentUASs, sonetPathIntervalESs, sonetPathIntervalSESs, sonetPathIntervalCVs, sonetPathIntervalUASs, sonetPathIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Path interfaces." ::= { sonetGroups 12 } sonetVTStuff2 OBJECT-GROUP OBJECTS { sonetVTCurrentWidth, sonetVTCurrentStatus, sonetVTCurrentESs, sonetVTCurrentSESs, sonetVTCurrentCVs, sonetVTCurrentUASs, sonetVTIntervalESs, sonetVTIntervalSESs, sonetVTIntervalCVs, sonetVTIntervalUASs, sonetVTIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH VT interfaces." ::= { sonetGroups 13 } sonetFarEndLineStuff2 OBJECT-GROUP OBJECTS { sonetFarEndLineCurrentESs, sonetFarEndLineCurrentSESs, Tesink Standards Track [Page 63] RFC 3592 SONET/SDH Objects September 2003 sonetFarEndLineCurrentCVs, sonetFarEndLineCurrentUASs, sonetFarEndLineIntervalESs, sonetFarEndLineIntervalSESs, sonetFarEndLineIntervalCVs, sonetFarEndLineIntervalUASs, sonetFarEndLineIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Line interfaces, and maintaining Line Far End information." ::= { sonetGroups 14 } sonetFarEndPathStuff2 OBJECT-GROUP OBJECTS { sonetFarEndPathCurrentESs, sonetFarEndPathCurrentSESs, sonetFarEndPathCurrentCVs, sonetFarEndPathCurrentUASs, sonetFarEndPathIntervalESs, sonetFarEndPathIntervalSESs, sonetFarEndPathIntervalCVs, sonetFarEndPathIntervalUASs, sonetFarEndPathIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH Path interfaces, and maintaining Path Far End information." ::= { sonetGroups 15 } sonetFarEndVTStuff2 OBJECT-GROUP OBJECTS { sonetFarEndVTCurrentESs, sonetFarEndVTCurrentSESs, sonetFarEndVTCurrentCVs, sonetFarEndVTCurrentUASs, sonetFarEndVTIntervalESs, sonetFarEndVTIntervalSESs, sonetFarEndVTIntervalCVs, sonetFarEndVTIntervalUASs, sonetFarEndVTIntervalValidData } STATUS current DESCRIPTION "A collection of objects providing information specific to SONET/SDH VT interfaces, and maintaining VT Far End information." ::= { sonetGroups 16 } Tesink Standards Track [Page 64] RFC 3592 SONET/SDH Objects September 2003 END 5. Acknowledgments This specification is a product of the AToM MIB Working Group. The author would like to acknowledge Mike Heard for his many valuable contributions to this memo. 6. Security Considerations There are a number of management objects defined in this MIB module that have a MAX-ACCESS clause of read-write: sonetMediumType, sonetMediumLineCoding, sonetMediumLineType, sonetMediumCircuitIdentifier, sonetMediumLoopbackConfig, sonetSESthresholdSet, sonetPathCurrentWidth, and sonetVTCurrentWidth. It is possible for writes to these objects to have disruptive effects on network operation that range from invalid performance data to traffic interruptions. Users of this MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in this MIB module (i.e., the objects with a MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide extensive information about the performance of interfaces in SONET/SDH equipment or networks and can reveal some aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an Tesink Standards Track [Page 65] RFC 3592 SONET/SDH Objects September 2003 instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [T1.105a] American National Standard for Telecommunications - Digital Hierarchy - Optical Interface Rates and Formats Specification, ANSI T1.105-1988. [T1.105b] American National Standard for Telecommunications - Digital Hierarchy - Optical Interface Rates and Formats Specification, ANSI T1.105-1991. [T1.106] American National Standard for Telecommunications - Digital Hierarchy - Optical Interface Specification (Single-Mode), ANSI T1.106-1988. [T1M1.3] Draft American National Standard for Telecommunications - Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring, T1M1.3/93-005R2, July 1993. [G.707] CCITT Recommendation G.707, "Synchronous Digital Hierarchy Bit Rates", June 1992. Tesink Standards Track [Page 66] RFC 3592 SONET/SDH Objects September 2003 [G.708] CCITT Recommendation G.708, "Network Node Interface for the Synchronous Digital Hierarchy", June 1992. [G.709] CCITT Recommendation G.709, "Synchronous Multiplexing Structure", June 1992. [G.783] CCITT Recommendation G.783, "Characteristics of Synchronous Digital Hierarchy (SDH) Multiplexing Equipment Functional Blocks", November 1992. [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB- II", RFC 1213, March 1991. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000. [T1.231a] American National Standard for Telecommunications - Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring, ANSI T1.231-1993, September 1993. [TR253] Bellcore TR-NWT-000253, Issue 1, "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", December 1991. [G.826] ITU Recommendation G.826, "Error Performance Parameters and Objectives for International Constant Bit Rate Digital Paths at or above Primary Rate", September 1995 (COM 13-R57E). [GR253] Bellcore GR-253-CORE, Issue 2, "Synchronous Optical Network (SONET) Transport Systems Common Generic Criteria", December 1995. [T1.231b] American National Standard for Telecommunications - Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring, ANSI T1.231-1997, September 1997. Tesink Standards Track [Page 67] RFC 3592 SONET/SDH Objects September 2003 7.2. Informative References [RFC1595] Brown, T. and K. Tesink, "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC 1595, March 1994. [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999. [RFC2496] Fowler, D., "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 2496, January 1999. [RFC2558] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC 2558, March 1999. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Tesink Standards Track [Page 68] RFC 3592 SONET/SDH Objects September 2003 Appendix A: The delay-line approach to statistics collection. According to ANSI T1.231 unavailable time begins at the onset of 10 contiguous severely errored seconds -- that is, unavailable time starts with the first of the 10 contiguous SESs -- and while an interface is deemed unavailable all counters for that interface are frozen except for the UAS count. Since changes in the signal state lag the data to which they apply by 10 seconds, an implementation which wishes to avoid making retroactive adjustments to the counts must pass the the one-second statistics through a 10-second delay line prior to updating any counters. That can be done by performing the following steps at the end of each one second interval. i) Read near/far end line and path CV counts and alarm status flags from the hardware. ii) Accumulate the CV counts for the preceding second and compare them to the ES and SES threshold for the layer in question. Update the signal state and shift the one-second CV counts and ES/SES flags into the 10-element delay line. Note that far-end one-second statistics are to be flagged as "absent" during any second in which there is an incoming defect at the layer in question or at any lower layer. iii) Update the current interval statistics using the signal state from the previous update cycle and the one-second CV counts and ES/SES flags shifted out of the 10-element delay line. This procedure guarantees that the statistical counters will be correctly updated at all times, although they lag real time by 10 seconds. It is illustrated in the figure below. At the end of each 15 minutes interval the current interval counts are transferred to the most recent interval entry and each interval is shifted up by one position, with the oldest being discarded if necessary in order to make room. The current interval counts then start over from zero. Note, however, that the signal state calculation does not start anew at each interval boundary; rather, signal state information is retained across interval boundaries. Tesink Standards Track [Page 69] RFC 3592 SONET/SDH Objects September 2003 +--------------------------------------------------------------+ | READ COUNTERS & STATUS INFO FROM HARDWARE | | | |LOS OOF/ SECT LINE LINE LINE LINE PATH PATH PATH PATH PATH | | LOF CV AIS CV RDI FEBE AIS LOP CV RDI CV | +--------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V V +--------------------------------------------------------------+ | ACCUM ONE-SEC STATS, CHK ERR THRESHOLDS, & UPDT SIGNAL STATE | | | | | | NEAR END/FAR END NEAR END/FAR END | |SECT SECT SECT LINE LINE LINE LINE PATH PATH PATH PATH | |CV ES SES CV ES SES AVA/UNA CV ES SES AVA/UNA | +--------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | V V V V V V | V V V | +-------------+ +-------------+ | +-------------+ | |ONE-SEC DELAY| |ONE-SEC DELAY| | |ONE-SEC DELAY| | | (1 OF 10) | | (1 OF 10) | | | (1 OF 10) | | |CV ES SES| |CV ES SES| | |CV ES SES| | +-------------+ +-------------+ | +-------------+ | | | | | | | | | | | | / / / / / / / / / / / / / / / / / / / / / / | | | | | | | | | | | V V V V V V | V V V | +-------------+ +-------------+ | +-------------+ | |ONE-SEC DELAY| |ONE-SEC DELAY| | |ONE-SEC DELAY| | | (10 OF 10) | | (10 OF 10) | | | (10 OF 10) | | |CV ES SES| |CV ES SES| | |CV ES SES| | +-------------+ +-------------+ | +-------------+ | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V +--------------------------------------------------------------+ | UPDATE STATISTICS COUNTERS | | | | NEAR END/FAR END NEAR END/FAR END | | SECTION LINE PATH | | CV ES EFS SES CV ES EFS SES AS UAS CV ES EFS SES AS UAS | +--------------------------------------------------------------+ Note that if such a procedure is adopted there is no current interval data for the first ten seconds after a system comes up. Tesink Standards Track [Page 70] RFC 3592 SONET/SDH Objects September 2003 noSuchInstance must be returned if a management station attempts to access the current interval counters during this time. It is an implementation-specific matter whether an agent assumes that the initial state of the interface is available or unavailable. Appendix B - RFC 1595 SES interpretation This appendix contains the values for x for the Section, Line, Path, and VT Layers as used in [T1M1.3][RFC1595][TR253]. Value for x for SONET/SDH Section SES Definition Rate x Minimum Bit Error Rate ======================================================= OC-1 9 1.5 x 10^-7 OC-3 16 1 x 10^-7 OC-9 47 1 x 10^-7 OC-12 63 1 x 10^-7 OC-18 94 1 x 10^-7 OC-24 125 1 x 10^-7 OC-36 187 1 x 10^-7 OC-48 249 1 x 10^-7 Value for x for SONET/SDH Line SES Definition Rate x Minimum Bit Error Rate ======================================================= OC-1 12 2 x 10^-7 OC-3 32 2 x 10^-7 OC-9 47 2 x 10^-7 OC-12 124 2 x 10^-7 OC-18 186 2 x 10^-7 OC-24 248 2 x 10^-7 OC-36 370 2 x 10^-7 OC-48 494 2 x 10^-7 Value for x for SONET/SDH STS-Path SES Definition Rate x Minimum Bit Error Rate ======================================================= STS-1 9 1.5 x 10^-7 STS-3 16 1 x 10^-7 Tesink Standards Track [Page 71] RFC 3592 SONET/SDH Objects September 2003 Value for x for SONET/SDH VT-Path SES Definition Rate x Minimum Bit Error Rate ======================================================= VT1.5 4 2 x 10^-6 VT2 6 2 x 10^-6 VT3 8 2 x 10^-6 VT6 14 2 x 10^-6 Author's Address Kaj Tesink Telcordia Technologies 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (732) 758-5254 EMail: kaj@research.telcordia.com Tesink Standards Track [Page 72] RFC 3592 SONET/SDH Objects September 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Tesink Standards Track [Page 73] snmp-mibs-downloader-1.1/mibrfcs/rfc3593.txt0000644000000000000000000004761311402176071015600 0ustar Network Working Group K. Tesink, Ed. Request for Comments: 3593 Telcordia Technologies Obsoletes: 2493 September 2003 Category: Standards Track Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. Table of Contents 1. Introduction ................................................. 2 2. Note on Invalid Data and Proxies ............................. 2 3. Note on xyzTimeElapsed ....................................... 3 4. Note on xyzValidIntervals .................................... 3 5. Definitions .................................................. 4 6. Acknowledgments .............................................. 8 7. References ................................................... 8 7.1. Normative References ................................... 8 7.2. Informative References ................................. 8 8. Security Considerations ...................................... 9 9. Intellectual Property Statement .............................. 9 10. Editor's Address ............................................. 9 11. Full Copyright Statement ..................................... 10 Tesink Standards Track [Page 1] RFC 3593 15 Minute Based Performance History TCs September 2003 1. Introduction In cases where a manager must obtain performance history data about the behavior of equipment it manages, several strategies can be followed in the design of a MIB that represents the managed equipment, including: 0 The agent counts events on a continuous basis and, whenever desired, the manager obtains the value of the event counter and adjusts its understanding of the history of events at the agent. 0 The agent allocates events to 'buckets' where each bucket represents an interval of time. Telecommunications equipment often makes use of the latter strategy. See [3][4][5][7][8] for examples. In particular, for this equipment it is common that history data is maintained by the agent in terms of fifteen minute intervals. This memo does not attempt to compare the relative merits of different strategies used to obtain history data. Differences may include polling policy, the amount of management traffic between manager and agent, agent simplicity, and 'data currentness' of the data obtained by the manager. MIB designers should consider these aspects when choosing a particular strategy in a MIB design. Instead, this memo provides definitions that can be used in MIB modules that require history data based on fifteen minute intervals. When designing a MIB module, it is often useful to define new types similar to those defined in the SMI [2]. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. This is done through Textual Conventions as defined in RFC 2579 [1]. It is the purpose of this document to define the set of textual conventions to be used when performance history based on 15 minute intervals is kept. The performance history textual conventions defined in this memo are based on 32 bit counts. For high capacity performance history counts see [9]. 2. Note on Invalid Data and Proxies In this document, the word proxy indicates an application which receives SNMP messages and replies to them on behalf of the devices where the actual implementation resides, e.g., DS3/E3 interfaces. The proxy will have already collected the information about the DS3/E3 interfaces into its local database and may not necessarily Tesink Standards Track [Page 2] RFC 3593 15 Minute Based Performance History TCs September 2003 forward requests to the actual DS3/E3 interface. It is expected in such an application that there are periods of time where the proxy is not communicating with the DS3/E3 interfaces. In these instances, the proxy will not necessarily have up-to-date configuration information, and will most likely have missed the collection of some data. Missed data collection may result in some intervals in the interval table being unavailable. 3. Note on xyzTimeElapsed While xyzTimeElapsed is defined as having a maximum, there may be cases (e.g., an adjustment in the system's time-of-day clock) where the actual value of the current interval would exceed this maximum value. Suppose that an agent which aligns its 15-minute measurement intervals to 15-minute time-of-day ("wall clock") boundaries has a time-of-day clock that systematically gains time, and that a manager periodically corrects the clock by setting it back. It is assumed that the agent's time-of-day clock is reasonably accurate, say within a few seconds per day. Thus, the manager's periodic clock adjustments will normally be small, and if done frequently enough, need not ever exceed 10 seconds. In this case, all interval durations will be within the allowed tolerance and none need be marked invalid, _if_ the ANSI procedure of ending measurement intervals at 15-minute time-of-day boundaries is followed [6]. If the time-of-day clock is systematically adjusted in small increments, then always ending measurement intervals at 15-minute time-of-day boundaries will result, in the long term, in the correct number of intervals with the correct average duration, irrespective of whether the clock is moved ahead or moved back. Thus, if for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, it is considered acceptable that the agent will return the maximum value. 4. Note on xyzValidIntervals The overall constraint on is 1 =< n =< 96. Any additional constraints on n must be defined in the DESCRIPTION clause (e.g., see [5]). Tesink Standards Track [Page 3] RFC 3593 15 Minute Based Performance History TCs September 2003 5. Definitions PerfHist-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Gauge32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; perfHistTCMIB MODULE-IDENTITY LAST-UPDATED "200308130000Z" ORGANIZATION "IETF AToM MIB WG" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/atommib-charter.html Mailing Lists: General Discussion: atommib@research.telcordia.com To Subscribe: atommib-request@research.telcordia.com Editor: Kaj Tesink Postal: Telcordia Technologies 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 732 758 5254 E-mail: kaj@research.telcordia.com" DESCRIPTION "This MIB Module provides Textual Conventions to be used by systems supporting 15 minute based performance history counts. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3593; see the RFC itself for full legal notices." REVISION "200308130000Z" DESCRIPTION "Contact information and references updated. No technical changes have been applied. Published as RFC 3593." REVISION "199811071100Z" DESCRIPTION "The RFC 2493 version of this MIB module." ::= { mib-2 58 } Tesink Standards Track [Page 4] RFC 3593 15 Minute Based Performance History TCs September 2003 -- The Textual Conventions defined below are organized -- alphabetically -- Use of these TCs assumes the following: -- 0 The agent supports 15 minute based history -- counters. -- 0 The agent is capable of keeping a history of n -- intervals of 15 minute performance data. The -- value of n is defined by the specific MIB -- module but shall be 0 < n =< 96. -- 0 The agent may optionally support performance -- data aggregating the history intervals. -- 0 The agent will keep separate tables for the -- current interval, the history intervals, and -- the total aggregates. -- 0 The agent will keep the following objects. -- If performance data is kept for multiple instances -- of a measured entity, then -- these objects are applied to each instance of -- the measured entity (e.g., interfaces). -- -- xyzTimeElapsed OBJECT-TYPE -- SYNTAX INTEGER (0..899) -- MAX-ACCESS read-only -- STATUS current -- DESCRIPTION -- "The number of seconds that have elapsed since -- the beginning of the current measurement period. -- If, for some reason, such as an adjustment in the -- system's time-of-day clock, the current interval -- exceeds the maximum value, the agent will return -- the maximum value." -- ::= { xxx } -- xyzValidIntervals OBJECT-TYPE -- SYNTAX INTEGER (0..) -- MAX-ACCESS read-only -- STATUS current -- DESCRIPTION -- "The number of previous near end intervals -- for which data was collected. -- [ The overall constraint on is 1 =< n =< 96; ] -- [ Define any additional constraints on here. ] -- The value will be unless the measurement was -- (re-)started within the last (*15) minutes, in which -- case the value will be the number of complete 15 -- minute intervals for which the agent has at least -- some data. In certain cases (e.g., in the case Tesink Standards Track [Page 5] RFC 3593 15 Minute Based Performance History TCs September 2003 -- where the agent is a proxy) it is possible that some -- intervals are unavailable. In this case, this -- interval is the maximum interval number for -- which data is available." -- ::= { xxx } -- xyzInvalidIntervals OBJECT-TYPE -- SYNTAX INTEGER (0..) -- MAX-ACCESS read-only -- STATUS current -- DESCRIPTION -- "The number of intervals in the range from -- 0 to xyzValidIntervals for which no -- data is available. This object will typically -- be zero except in cases where the data for some -- intervals are not available (e.g., in proxy -- situations)." -- ::= { xxx } PerfCurrentCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A counter associated with a performance measurement in a current 15 minute measurement interval. The value of this counter starts from zero and is increased when associated events occur, until the end of the 15 minute interval. At that time the value of the counter is stored in the first 15 minute history interval, and the CurrentCount is restarted at zero. In the case where the agent has no valid data available for the current interval the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist (for example, a noSuchName error for SNMPv1 and a noSuchInstance for SNMPv2 GET operation)." SYNTAX Gauge32 Tesink Standards Track [Page 6] RFC 3593 15 Minute Based Performance History TCs September 2003 PerfIntervalCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A counter associated with a performance measurement in a previous 15 minute measurement interval. In the case where the agent has no valid data available for a particular interval the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist (for example, a noSuchName error for SNMPv1 and a noSuchInstance for SNMPv2 GET operation). In a system supporting a history of n intervals with IntervalCount(1) and IntervalCount(n) the most and least recent intervals respectively, the following applies at the end of a 15 minute interval: - discard the value of IntervalCount(n) - the value of IntervalCount(i) becomes that of IntervalCount(i-1) for n >= i > 1 - the value of IntervalCount(1) becomes that of CurrentCount - the TotalCount, if supported, is adjusted." SYNTAX Gauge32 PerfTotalCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A counter associated with a performance measurements aggregating the previous valid 15 minute measurement intervals. (Intervals for which no valid data was available are not counted)" SYNTAX Gauge32 END Tesink Standards Track [Page 7] RFC 3593 15 Minute Based Performance History TCs September 2003 6. Acknowledgments This document is a product of the AToM MIB Working Group. The editor would like to acknowledge Mike Heard for his many valuable contributions to this memo. 7. References 7.1. Normative References [1] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 7.2. Informative References [3] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999. [4] Fowler, D., "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 2496, January 1999. [5] Tesink, K., "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", RFC 3592, September 2003. [6] American National Standard for Telecommunications - Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring, ANSI T1.231-1997, September 1997. [7] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, August 1999. [8] Ray, B., and R. Abbi, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", RFC 3276, May 2002. [9] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", Work in Progress. Tesink Standards Track [Page 8] RFC 3593 15 Minute Based Performance History TCs September 2003 8. Security Considerations This memo defines textual conventions for use in other MIB modules. Security issues for these MIB modules are addressed in the memos defining those modules. 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Editor's Address Kaj Tesink Telcordia Technologies 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: +1 732 758 5254 EMail: kaj@research.telcordia.com Tesink Standards Track [Page 9] RFC 3593 15 Minute Based Performance History TCs September 2003 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Tesink Standards Track [Page 10] snmp-mibs-downloader-1.1/mibrfcs/rfc3595.txt0000644000000000000000000002674211402176071015602 0ustar Network Working Group B. Wijnen Request for Comments: 3595 Lucent Technologies Category: Standards Track September 2003 Textual Conventions for IPv6 Flow Label 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Intellectual Property Statement. . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 Wijnen Standards Track [Page 1] RFC 3595 Textual Conventions for IPv6 Flow Label September 2003 1. Introduction Several standards-track MIB modules have defined objects to represent an IPv6 Flow Label (sometimes referred to as Flow ID) [RFC2460] [FLOWLABEL] and IPv6 Flow Label filters. Unfortunately the result is a set of different definitions for the same piece of management information. This may lead to confusion and unnecessary complexity. This document defines a set of textual conventions (TCs) that can and should be (re-)used in MIB modules, so that they all represent an IPv6 Flow Label in the same way. In fact, PIB modules can and should also use these TCs when they need to represent an IPv6 Flow label. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Definitions IPV6-FLOW-LABEL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ipv6FlowLabelMIB MODULE-IDENTITY LAST-UPDATED "200308280000Z" -- 28 August 2003 ORGANIZATION "IETF Operations and Management Area" CONTACT-INFO "Bert Wijnen (Editor) Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Wijnen Standards Track [Page 2] RFC 3595 Textual Conventions for IPv6 Flow Label September 2003 Phone: +31 348-407-775 EMail: bwijnen@lucent.com Send comments to . " DESCRIPTION "This MIB module provides commonly used textual conventions for IPv6 Flow Labels. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3595, see the RFC itself for full legal notices. " -- Revision History REVISION "200308280000Z" -- 28 August 2003 DESCRIPTION "Initial version, published as RFC 3595." ::= { mib-2 103 } IPv6FlowLabel ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier or Flow Label in an IPv6 packet header that may be used to discriminate traffic flows. " REFERENCE "Internet Protocol, Version 6 (IPv6) specification, section 6. RFC 2460. " SYNTAX Integer32 (0..1048575) IPv6FlowLabelOrAny ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier or Flow Label in an IPv6 packet header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 0..1048575) END Wijnen Standards Track [Page 3] RFC 3595 Textual Conventions for IPv6 Flow Label September 2003 4. Security Considerations The MIB module contained in this memo does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects. Meaningful security considerations can only be written for MIB modules that define concrete management objects. This document has therefore no impact on the security of the Internet. 5. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. References 6.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2578] McCloghrie, K., Perkins, D. and Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,"Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Wijnen Standards Track [Page 4] RFC 3595 Textual Conventions for IPv6 Flow Label September 2003 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 6.2. Informative References [FLOWLABEL] Carpenter, B., Conta, A., Deering, S. and J. Rajahalme, "IPv6 Flow Label Specification", Work in Progress. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 7. Acknowledgments This document was produced as a result of a review of the use of FlowID in a PIB module and a MIB module. Further investigation found that FlowID and FlowLabel objects were defined in a few other MIB modules. The editor would like to thank all who contributed to the discussion that resulted in this document, particularly Juergen Schoenwaelder for finding and reporting most of the other MIB modules that were using/defining a FlowLabel object. Juergen also suggested the very first direction for a common TC for these objects. Further contributions were received from Fred Baker, Dan Romascanu, Kwok Ho Chan, Margaret Wasserman, Brian Carpenter, Andy Bierman, Randy Presuhn, Branislav Meandzija, Brian Williams, Ravi Sahita. We also received initial input from 3GPP that expressed the requirement to be able to specify a wildcard for FlowID or FlowLabel. Further helpful review comments were received from Brian Carpenter, John Loughney, Pekka Savola. 8. Author's Address Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Phone: +31-348-407-775 EMail: bwijnen@lucent.com Wijnen Standards Track [Page 5] RFC 3595 Textual Conventions for IPv6 Flow Label September 2003 9. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Wijnen Standards Track [Page 6] snmp-mibs-downloader-1.1/mibrfcs/rfc3606.txt0000644000000000000000000054647211402176071015602 0ustar Network Working Group F. Ly Request for Comments: 3606 Pedestal Networks Category: Standards Track M. Noto Cisco Systems A. Smith Consultant E. Spiegel Cisco Systems K. Tesink Telcordia Technologies November 2003 Definitions of Supplemental Managed Objects for ATM Interface 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs). Ly, et al. Standards Track [Page 1] RFC 3606 Supplemental ATM Managed Objects November 2003 Table of Contents 1. The Internet-Standard Management Framework. . . . . . . . . 3 2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Background. . . . . . . . . . . . . . . . . . . . . . 3 2.2. Important Definitions . . . . . . . . . . . . . . . . 4 3. Conventions used in the MIB . . . . . . . . . . . . . . . . 6 3.1. Structure . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. ATM SVC VP Cross-Connect Table. . . . . . . . 6 3.1.2. ATM SVC VC Cross-Connect Table. . . . . . . . 7 3.1.3. ATM Interface Signalling Statistics Table . . 8 3.1.4. ATM Signalling Capability Support . . . . . . 9 3.1.5. Signalling Descriptor Parameter Table . . . . 10 3.1.6. ATM Interface Registered Address Table. . . . 10 3.1.7. ATM VPI/VCI to Address Mapping Table. . . . . 11 3.1.8. ATM Address to VPI/VCI Mapping Table. . . . . 11 3.1.9. ATM VPL Statistics Table. . . . . . . . . . . 11 3.1.10. ATM VPL Logical Port Table. . . . . . . . . . 12 3.1.11. ATM VCL Statistics Table. . . . . . . . . . . 15 3.1.12. ATM VC General Information Table. . . . . . . 15 3.1.13. ATM Interface Configuration Extension Table . 16 3.1.14. ATM ILMI Service Registry Table . . . . . . . 17 3.1.15. ILMI Network Prefix Table . . . . . . . . . . 19 3.1.16. ATM Switch Address Table. . . . . . . . . . . 19 3.1.17. AAL5 per-VCC Statistics Table . . . . . . . . 19 3.1.18. ATM VP Cross-Connect Extension Table. . . . . 20 3.1.19. ATM VC Cross-Connect Extension Table. . . . . 20 3.1.20. Currently Failing PVPL Table. . . . . . . . . 20 3.1.21. Currently Failing PVCL Table. . . . . . . . . 20 3.1.22. Leaf Initiated Join Counter support . . . . . 20 3.2. Network and User Addresses. . . . . . . . . . . . . . 20 3.3. Configuration of VPLs, VCLs, and Cross-Connects . . . 20 3.4. ATM-related Trap Support. . . . . . . . . . . . . . . 20 4. Conformance and Compliance. . . . . . . . . . . . . . . . . 21 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 89 7. References. . . . . . . . . . . . . . . . . . . . . . . . . 89 7.1. Normative References. . . . . . . . . . . . . . . . . 89 7.2. Informative References. . . . . . . . . . . . . . . . 90 8. Security Considerations . . . . . . . . . . . . . . . . . . 90 9. Intellectual Property Statement . . . . . . . . . . . . . . 92 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 93 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 94 Ly, et al. Standards Track [Page 2] RFC 3606 Supplemental ATM Managed Objects November 2003 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview The purpose of this memo is to provide additional capabilities, not found in the ATM-MIB [RFC2515], which are needed to manage ATM interfaces. This memo addresses the following areas: - ATM Switch Support - ATM Service Support - ATM Host Support In addition, this memo also provides ATM trap support. 2.1. Background In addition to the MIB module defined in this memo, other MIB modules are necessary to manage ATM interfaces, links and cross-connects. Examples include MIB II for general system and interface management ([RFC2863]), the DS3 ([RFC2496]) or SONET MIBs ([RFC3592]) for management of SONET and DS3 physical interfaces, and, as appropriate, MIB modules for applications that make use of ATM, such as SMDS [RFC1694] and LAN Emulation [ATM Forum LANE]. These MIB modules are outside the scope of this specification. This MIB module also requires the use of the ATM-MIB module defined in [RFC2515] and ATM-specific textual conventions defined in [RFC2514]. ATM Endpoint applications such as ATM LAN Emulation or Classical IP- over-ATM Clients and Servers use ATM to establish SVC/PVC connections for exchanging control and data information. The agents of these ATM applications must provide the network manager with information on the SVC/PVCs in use and which applications are using them. The information can be made generic so as to apply to all ATM Ly, et al. Standards Track [Page 3] RFC 3606 Supplemental ATM Managed Objects November 2003 applications. This memo defines extensions to the ATM-MIB [RFC2515] in order to support this. The current specification of this supplemental ATM2-MIB is based on SNMPv2 SMI. 2.2. Important Definitions The following terms are defined here and used throughout this MIB: - Virtual Path Link (VPL) - Virtual Path Connection (VPC) - Virtual Path Segment (VP Segment) - Virtual Channel Link (VCL) - Virtual Channel Connection (VCC) - Virtual Channel Segment (VC Segment). The figures on the next page show how these terms apply in typical ATM network topologies. Additional terms relevant to this MIB are defined and illustrated in the ATM Terminology section 3 of [RFC2515]. _____ _______ _______ _______ _____ | |____| |____| |____| |____| | |Host1| |SwitchA| |SwitchB| |SwitchC| |Host2| | |____| |____| |____| |____| | |_____| |_______| |_______| |_______| |_____| |<-->| |<-->| Virtual Path Link Virtual Path Link |<----------------------------------------->| Virtual Path Connection (between Host1 and Host2) |<--------------->| Virtual Path Segment (between SwitchA and SwitchC) Figure 1: Examples of Virtual Path Links, Virtual Path Connection, and Virtual Path Segment Ly, et al. Standards Track [Page 4] RFC 3606 Supplemental ATM Managed Objects November 2003 _____ _______ _______ _______ _____ | |____| |____| |____| |____| | |Host1|----|SwitchA|----|SwitchB|----|SwitchC|----|Host2| | |____| |____| |____| |____| | |_____| |_______| |_______| |_______| |_____| |<-->| |<-->| Virtual Channel Link Virtual Channel Link |<----------------------------------------->| Virtual Channel Connection (between Host1 and Host2) |<--------------->| Virtual Channel Segment (between SwitchA and SwitchC) Figure 2: Examples of Virtual Channel Links, Virtual Channel Connection, and Virtual Channel Segment Ly, et al. Standards Track [Page 5] RFC 3606 Supplemental ATM Managed Objects November 2003 3. Conventions used in the MIB 3.1. Structure The managed ATM objects are arranged as follows: Table Host Switch Service _____________________________________________________ atmSvcVcCrossConnectTable | | Y | Y | atmSvcVpCrossConnectTable | | Y | Y | atmSigStatTable | Y | Y | Y | atmSigSupportTable | | Y | Y | atmSigDescrParamTable | Y | | | atmIfRegisteredAddrTable | | Y | Y | atmVclAddrTable | Y | | | atmAddrVclTable | Y | | | atmVplStatTable | Y | Y | Y | atmVplLogicalPortTable | Y | Y | Y | atmVclStatTable | Y | Y | Y | atmAal5VclStatTable | Y | | | atmVclGenTable | Y | | | atmInterfaceExtTable | Y | Y | Y | atmIlmiSrvcRegTable | | Y | Y | atmIlmiNetworkPrefixTable | | Y | Y | atmSwitchAddressTable | | Y | | atmVpCrossConnectXTable | | | Y | atmVcCrossConnectXTable | | | Y | atmCurrentlyFailingPVplTable | Y | Y | Y | atmCurrentlyFailingPVclTable | Y | Y | Y | Table 1: MIB structure 3.1.1. ATM SVC VP Cross-Connect Table This table provides the SVC VP Cross-Connect (SVPC) information. The equivalent PVC VP Cross-Connect table is defined in [RFC2515]. This table also includes cross-connect information for Soft PVPs. Ly, et al. Standards Track [Page 6] RFC 3606 Supplemental ATM Managed Objects November 2003 This table contains configuration and state information of all SVC VP point-to-point, point-to-multipoint, or multipoint-to-multipoint VP cross-connects. This table has read-only access and can be used to monitor the cross-connects which connect the VPLs together in an ATM switch or network. The atmSvcVpCrossConnectIndex is used to associate the related SVC VPLs that are cross-connected together. The atmSvcVpCrossConnectRowStatus object has read-write access to allow for tear-down. The ATM SVC VP Cross-Connect Table models each bi-directional Switched Virtual Circuit (SVC) VP cross-connect as a set of entries in the atmSvcVpCrossConnectTable. A point-to-point VPC cross-connect is modeled as one entry; a point-to-multipoint (N leafs) VPC cross- connect as N entries in this table; and a multipoint-to-multipoint (N parties) VPC cross-connect as N(N-1)/2 entries in this table. In the latter cases, all the N (or N(N-1)/2) entries are associated with a single VPC cross-connect by having the same value of atmSvcVpCrossConnectIndex. _________________________________________ | | Low | ATM Switch or Network | High port| | port _____|>> from low to high VPC traffic flow >>|______ |<< from high to low VPC traffic flow <<| |_______________________________________| Figure 3: VPC Cross-Connect Model The terms low and high are chosen to represent numerical ordering of the two interfaces associated with a VPC cross-connect. That is, the ATM interface with the lower value of ifIndex is termed 'low', while the other ATM interface associated with the VPC cross-connect is termed 'high'. 3.1.2. ATM SVC VC Cross-Connect Table This table provides the SVC Cross-Connect (SVCC) information. The equivalent PVC VC Cross-Connect table is defined in [RFC2515]. This table also includes cross-connect information for Soft PVCs. This table is used to model a bi-directional point-to-point, point- to-multipoint or multipoint-to-multipoint SVC VC cross-connect. Ly, et al. Standards Track [Page 7] RFC 3606 Supplemental ATM Managed Objects November 2003 This table has read-only access and is used to monitor the cross- connects which connect the VCLs together in an ATM switch or network that belong to a VC connection. The atmSvcVcCrossConnectIndex is used to associate the related SVC VCLs that are cross-connected together. The atmSvcVcCrossConnectRowStatus object has read-write access to allow for tear-down. The ATM SVC VC Cross-Connect Table models each bi-directional Switched Virtual Circuit (SVC) VC cross-connect as a set of entries in the atmSvcVcCrossConnectTable. A point-to-point VC cross-connect is modeled as one entry; a point-to-multipoint (N leafs) VC cross- connect as N entries in this table; and a multipoint-to-multipoint (N parties) VPC cross-connect as N(N-1)/2 entries in this table. In the latter cases, all the N (or N(N-1)/2) entries are associated with a single VPC cross-connect by having the same value of atmSvcVcCrossConnectIndex. ______________________________________ | | Low | ATM Switch or Network | High port| | port _____|>> from low to high VC traffic flow >>|______ |<< from high to low VC traffic flow <<| |______________________________________| Figure 4: VC Cross-Connect Model The terms low and high are chosen to represent numerical ordering of the two interfaces associated with a VPC cross-connect. That is, the ATM interface with the lower value of ifIndex is termed 'low', while the other ATM interface associated with the VPC cross-connect is termed 'high'. 3.1.3. ATM Interface Signalling Statistics Table This table provides statistical information of the signalling entity. A signalling entity can be deployed over an ATM interface as defined in the atmInterfaceConfTable [RFC2515], a logical ATM interface defined in section 5.1.10.1 in this document, or a proprietary virtual interface as described in the atmInterfaceExtTable. To monitor the signalling entity, a few counters are provided. They are defined as: atmSigSSCOPConEvents atmSigSSCOPErrdPdus atmSigDetectSetupAttempts atmSigEmitSetupAttempts atmSigDetectUnavailRoutes Ly, et al. Standards Track [Page 8] RFC 3606 Supplemental ATM Managed Objects November 2003 atmSigEmitUnavailRoutes atmSigDetectUnavailResrcs atmSigEmitUnavailResrcs atmSigDetectCldPtyEvents atmSigEmitCldPtyEvents atmSigDetectMsgErrors atmSigEmitMsgErrors atmSigDetectClgPtyEvents atmSigEmitClgPtyEvents atmSigDetectTimerExpireds atmSigEmitTimerExpireds atmSigDetectRestarts atmSigEmitRestarts atmSigInEstabls atmSigOutEstabls 3.1.4. ATM Signalling Capability Support A number of Information Elements may or may not be supported by ATM switches or ATM Services. Hence, for trouble isolation it is important to keep track which particular Information Elements are supported. The corresponding group of objects must be supported by switches or services supporting SVCs, and indicate whether the following Information Elements are enabled/disabled: 1) Calling party number 2) Calling party subaddress 3) Called party subaddress 4) Broadband high layer information 5) Broadband low layer information 6) Broadband Repeat Indicator 7) AAL parameters The last parameter, Preferred Carrier Pre-Subscription, identifies the carrier to which intercarrier calls originated from this interface are routed when transit network selection information is not provided by the calling party. Ly, et al. Standards Track [Page 9] RFC 3606 Supplemental ATM Managed Objects November 2003 3.1.5. Signalling Descriptor Parameter Table This table extends the ATM VCL table of the ATM-MIB [RFC2515] to include all other necessary signalling information as specified in the ATM Forum UNI Specifications [ATM Forum 3.0] and [ATM Forum UNI 3.1]. A user can create an entry with all signalling parameters and later use that entry to specify the signalling characteristics of SVCs. Some of the signalling parameters, such as the AAL5 parameters information element, are reflected in the VCL and VPL tables, and this table only contains the remaining AAL5 parameters. Signalling attributes can be grouped into following categories: 1) ATM Adaptation Layer Parameters Information in this group is captured in the ATM Signalling Descriptor Parameter Table defined in this memo. Please refer to section 5.4.5.5 of [ATM Forum 3.0] and [ATM Forum UNI 3.1]. 2) Broadband High Layer Information Information in this group is captured by the ATM Signalling Descriptor Parameter Table defined in this memo. Please refer to section 5.4.5.8 of [ATM Forum 3.0] and [ATM Forum UNI 3.1]. 3) Broadband Low Layer Information Information in this group is captured by the ATM Signalling Descriptor Parameter Table defined in this memo. Please refer to section 5.4.5.9 of [ATM Forum 3.0] and [ATM Forum UNI 3.1]. 3.1.6. ATM Interface Registered Address Table This table contains a list of ATM addresses that can be used for calls to and from a given interface by a switch or service. The ATM addresses are either registered by the endsystem via ILMI or statically configured. This table does not expose PNNI reachability information. This table only applies to switches and network services. See also Section 5.2. Ly, et al. Standards Track [Page 10] RFC 3606 Supplemental ATM Managed Objects November 2003 3.1.7. ATM VPI/VCI to Address Mapping Table In the atmVclAddrTable, the object atmVclAddrAddr can either be an ATM Local Address or an ATM Remote Address which represent the two endpoint addresses of a VCL. ATM Local Address identifies the local endpoint of the VCL represented by this agent. The ATM Remote address represents the address of the ATM application at the other end of the VCL. 3.1.8. ATM Address to VPI/VCI Mapping Table This table provides an alternative way to retrieve the atmVclTable. This table can be used to retrieve the indexing to the atmVclTable by an ATM address. 3.1.9. ATM VPL Statistics Table The atmVplStatTable includes per-VPL cell counters. The VPL cell counters count the valid ATM cells. The valid ATM cells include the user and OAM cells but exclude the physical layer (e.g., idle cells) and unassigned cells. Cells coming into an ATM managed system are counted differently with the high Cell Loss Priority (CLP=0) or low Cell Loss Priority (CLP=1). The cells are tagged, passed or discarded depending on the incoming CLP value and the policed cell rate by the "traffic policing" entity in the ATM managed system. Refer to [ATM Forum 3.0] and [ATM Forum UNI 3.1] for a description of the traffic policing. In the switch where the traffic policing is not supported, cells are passed or discarded depending on the bandwidth and buffering capacity of the switching fabric. The Output Tagged Cells counter, in this case, is always zero. _______________ | ATM Managed | Input | System | Output CLP=0 cells| | CLP=0 cells ---------->| |-----------> CLP=1 cells| (traffic | CLP=1 cells ---------->| policing |-----------> | entity) | Tagged cells (CLP=1) |_____________|-----------> |Discard | Discard |CLP=0 | CLP=1 |cells | cells | | V V Figure 5: ATM Cell Counters per VPL Ly, et al. Standards Track [Page 11] RFC 3606 Supplemental ATM Managed Objects November 2003 In this table, cells coming into and out of the managed ATM system are counted as the total number of cells and the cells with the CLP=0. The CLP=1 counter is derived by subtracting CLP=0 cells from the total cells. In addition, cells that are tagged on the output are also counted. The output CLP=1 cells equals the total cells out count minus both the CLP=0 cells and the tagged cells. 3.1.10. ATM VPL Logical Port Table The ATM VPL Logical Port Table includes all ATM logical port interface configuration information. 3.1.10.1. ATM Logical Port Interface The interface type "ATM Logical Port" (ifType=80) is defined to allow the representation of a VP Tunnel, which is a VPL used as a trunk connection (most likely between devices that are not physically adjacent), providing for multiplexing and demultiplexing of VCs on the VP. Figure 6 illustrates such a VP Tunnel. Note: the "ATM Logical Port" interface is more of a logical port, compared with an interface of type "ATM" which is more of a physical port that provides for the transport of many VP and VC connections between adjacent devices. <------VP Tunnel------> ATM Switch A ATM Switch B ------------ ----------- |ATM |_____________|ATM | |X-Connect | . |X-Connect | VCL1 |Point | VPL1 . VPL2 |Point | VCL4 O---------|----X-----|----- . -----|----X-----|-----O | X-----|----- . -----|----X | | | |_____________| | | ------------ ------------ | VCL2 | VCL3 O O Figure 6: Virtual Path Tunnel In Figure 6, a VP tunnel (denoted as VPL1 by Switch A, and as VPL2 by Switch B) is used to connect VCL1 with VCL4 and VCL2 with VCL3. Figure 6 shows only one VP tunnel, but there can be multiple VP tunnels over the same physical interface. Ly, et al. Standards Track [Page 12] RFC 3606 Supplemental ATM Managed Objects November 2003 A particularly useful VP tunnel scenario is tunneling across a public network that does not support signalling. In Figure 6 above, assume Switches A and B are private switches that signal over the VP to set up connections transparently through the public network. The public network would just transport a PVC VP between the two switches. Because the VP Tunnel constitutes an interface between two ATM devices that are not necessarily physically adjacent, most of the management information pertaining to the interface may differ for the tunnel, including: - active VPI/VCI fields (the tunnel may be a subset of the parent interface). - maximum number of VCCs - configured VCCs - ILMI VPI/VCI values - ATM address type - ATM administrative address - received/transmitted cells. 3.1.10.2. How to create an ATM Logical Port interface On ATM devices supporting VP tunnels, the ATM Logical Port Interface Table can be used to create VP tunnels. To create an ATM Logical Port interface via SNMP: - Create a VPL (e.g., VPI=a on an existing ATM interface which has ifIndex=x) in the atmVplTable. - Set the object atmVplLogicalPortDef to isLogicalIf. A new row in the ifTable is then created by the agent, with ifIndex=y, to represent the ATM Logical Port interface. The object atmVplLogicalPortIndex is also set to y by the agent to represent the ifIndex value of the ATM Logical Port interface. - The ifEntry values are set for the ATM Logical Port interface (ifIndex=y) as discussed in RFC 2515, with the following exceptions: * ifType - a new enumerated value of atmLogical(80) was added to IANAifType, specifying an "ATM Logical Port" interface. * ifSpeed - The total bandwidth in bits per second for use by the ATM layer. Computed from the traffic descriptor for the VPL. Ly, et al. Standards Track [Page 13] RFC 3606 Supplemental ATM Managed Objects November 2003 * ifOperStatus - determined hierarchically, depending on the state of the physical atm-cell layer interface beneath it, and the ILMI on the VP. * ifInOctets, ifOutOctets - support of these objects is not mandatory for ATM Logical Port interfaces. * ifInErrors - always zero, HEC errors are specified for the atm cell-layer interface beneath it. * ifInUnknownProtos - always zero, errors are specified for the atm cell-layer interface beneath it. - The atmInterfaceConfEntry values are set and reported as discussed in [RFC2515], with the following exceptions: * atmInterfaceMaxVpcs - 0. * atmInterfaceConfVpcs - 0. * atmInterfaceIlmiVpi - VPI of the VP tunnel. - The atmInterfaceExtEntry values are set and reported as follows: * atmInterfaceConfMaxSvpcVpi - VPI of the VP tunnel, although VPCs cannot be setup on a VP tunnel. * atmInterfaceCurrentMaxSvpcVpi - VPI of VP tunnel, although VPCs cannot be setup on a VP tunnel. * atmInterfaceConfMaxSvccVpi - VPI of the VP tunnel. * atmInterfaceCurrentMaxSvccVpi - VPI of VP tunnel. * atmIntfPvcFailures - Includes failures of PVCLs within the VP tunnel, but not of the PVPL itself, since those are reported on the atm(37) interface. * atmIntfCurrentlyFailingPVpls - 0. * atmIntfPvcFailuresTrapEnable - Enables traps for PVCL failures within the VP tunnel, but not for the PVPL itself, since the latter are generated on behalf of the atm(37) interface. - An entry is created in the ifStackTable, with values: ifStackHigherLayer=y, ifStackLowerLayer=x. - VCLs defined on the VP tunnel are indexed by ifIndex=y, VPI=a, VCI. Ly, et al. Standards Track [Page 14] RFC 3606 Supplemental ATM Managed Objects November 2003 3.1.11. ATM VCL Statistics Table The atmVclStatTable includes per-VCL cell counters. The VCL cell counters count the valid ATM cells. The valid ATM cells include the user and OAM cells but exclude the physical layer (e.g., idle cells) and unassigned cells. Cells coming into an ATM managed system are counted differently with the high Cell Loss Priority (CLP=0) or low Cell Loss Priority (CLP=1). The cells are tagged, passed or discarded depending on the incoming CLP value and the policed cell rate by the "traffic policing" entity in the ATM managed system. Refer to [ATM Forum 3.0] and [ATM Forum UNI 3.1] for the description of the traffic policing. In a switch where the traffic policing is not supported, cells are passed or discarded depending on the bandwidth and buffering capacity of the switching fabric. The Output Tagged Cells counter, in this case, is always zero. _______________ | ATM Managed | Input | System | Output CLP=0 cells| | CLP=0 cells ---------->| |-----------> CLP=1 cells| (traffic | CLP=1 cells ---------->| policing |-----------> | entity) | Tagged cells (CLP=1) |_____________|-----------> |Discard | Discard |CLP=0 | CLP=1 |cells | cells | | V V Figure 7: ATM Cell Counters per VCL In this table, cells coming into and out of the managed ATM system are counted as the total number of cells and the cells with the CLP=0. The CLP=1 counter is derived by subtracting CLP=0 cells from the total cells. In addition, cells that are tagged on the output are also counted. The output CLP=1 cells equals the total cells out count minus both the CLP=0 cells and the tagged cells. 3.1.12. ATM VC General Information Table This table contains the general information for each VC. It provides an index to the atmSigDescrParamTable defined in this MIB. This table is an extension to the atmVclTable defined in the ATM-MIB [RFC2515]. Ly, et al. Standards Track [Page 15] RFC 3606 Supplemental ATM Managed Objects November 2003 3.1.13. ATM Interface Configuration Extension Table The ATM Interface Configuration Extension Table contains ATM interface information that supplements the atmInterfaceConfTable defined in [RFC2515]. It includes the configuration information of the interface type (i.e., connection setup procedures) and ILMI. A network manager can configure the interface to run a specific type of connection setup procedures (i.e., protocol and version) such as ITU-T DSS2, ATM Forum UNI 3.1, PNNI 1.0 or BICI 2.0. It can also dictate the role of the managed entity as one side of the interface. For example, if an interface is configured to run ATM Forum UNI 3.1, the managed entity has to be told to run as either the network side or the user side of the UNI. The objects atmIntfConfigType and atmIntfConfigSide are used for configuration and the objects atmIntfActualType and atmIntfActualSide are used for reading back the actual interface protocol and version. The following table describes all the valid combinations of configuration of the interface type and side. Note that the value N/A meaning not applicable, should be set to the value other(1) when used. atmIntfConfigType atmIntfConfigSide ----------------- ----------------- autoConfig N/A ituDss2 user/network atmfUni3Dot0 user/network atmfUni3Dot1 user/network atmfUni4Dot0 user/network atmfIispUni3Dot0 user/network atmfIispUni3Dot1 user/network atmfIispUni4Dot0 user/network atmfPnni1Dot0 N/A atmfBici2Dot0 N/A atmfUniPvcOnly user/network atmfNniPvcOnly N/A When the value of the object atmIntfConfigType is configured to autoConfig(2), the interface type is determined via the ATM Forum ILMI auto-configuration procedures [ATM Forum ILMI]. There is no need to set the interface side since it should be a derived value. The PNNI and BICI interfaces are always symmetric so setting the interface side is also not necessary. Ly, et al. Standards Track [Page 16] RFC 3606 Supplemental ATM Managed Objects November 2003 This table also includes the configured and negotiated maximum VPI value per ATM interface, and the configured and negotiated minimum VCI value per ATM interface. Refer to [ATM Forum ILMI] Sections 8.2.3.8 through 8.2.3.10 for a detailed description. The following figure provides an example how the current minimum VCI values are derived from the configured minimum VCI values and the neighboring minimum VCI values: +--------+ +--------+ +--------+ | ATM | ifA ifB | ATM | ifC ifD | ATM | | Device |--------------| Device |--------------| Device | +--------+ +--------+ +--------+ ifA: Configured Min SVCC VCI = 32 (configured) Current Min SVCC VCI = 40 (negotiated) ifB: Configured Min SVCC VCI = 40 (configured) Current Min SVCC VCI = 40 (negotiated) ifC: Configured Min SVCC VCI = 32 (configured) Current Min SVCC VCI = 32 (negotiated) ifD: Configured Min SVCC VCI = 32 (configured) Current Min SVCC VCI = 32 (negotiated) Between ifA and ifB, the maximum of the two vales for atmInterfaceConfMinSvccVci is 40, so both interfaces set their atmInterfaceCurrentMinSvccVci values to 40. On the other hand, since ifC and ifD both are configured with atmInterfaceConfMinSvccVci values of 32, they set their atmInterfaceCurrentMinSvccVci values to 32. Figure 8: Examples of configured vs. negotiated ILMI values 3.1.14. ATM ILMI Service Registry Table This table contains information used by the switch/service to inform ATM hosts of the location of ATM network services such as the LAN Emulation Configuration Server (LECS), the ATM Name Server (ANS), the ATMARP Server, the Multicast Address Resolution Server (MARS), and the NHRP Server (NHS). Entries in this table are exported to adjacent devices via ILMI over either all or a few user selected ATM interfaces. Ly, et al. Standards Track [Page 17] RFC 3606 Supplemental ATM Managed Objects November 2003 As an example, let's assume that: - An ATM switch X has three interfaces if1, if2 and if3. - There are two ATM network services offered, a1.a2...aN and b1.b2...bN, where a1.a2...aN is an object identifier used to identify the first service, and b1.b2...bN is the object identifier for the other service. - The first service is available at the ATM address 'a'. - The second service is available at the ATM address 'b'. - The first service can be used by any device connecting to the switch X. - The second service can be used only by devices that connect to interfaces if1 and if3 on switch X. +------------------+ +------------------+ |service a1.a2...aN| |service b1.b2...bN| | | | | | ATM address = a | | ATM address = b | +--------+---------+ +--------+---------+ | | | | +--------+-----------------------+---------+ | ATM NETWORK | +-----------------+------------------------+ | | +-------------+ | switch X | +-+----+----+-+ | | | | | | if1 if2 if3 (interfaces) Figure 9: ATM topology with registered services The table for switch X will contain three entries: - one entry for the "a1.a2...aN", implicitly available to any devices on switch X. - two entries for the "b1.b2...bN" (one for each interface where this service can be explicitly used). Ly, et al. Standards Track [Page 18] RFC 3606 Supplemental ATM Managed Objects November 2003 The content of the table is: - Service Identifier: a1.a2...aN b1.b2...bN b1.b2...bN - ATM address: a b b - Arbitrary index: m n p - Available interface: 0 1 3 where the Service Identifier values a1.a2...aN and b1.b2...bN are represented by atmIlmiSrvcRegServiceID, the ATM addresses a and b are represented by atmIlmiSrvcRegATMAddress, the values m, n, and p are arbitrary non-zero integer parameters (necessary in this example to differentiate the two entries for b1.b2...bN that are both available at the ATM address 'b') represented by atmIlmiSrvcRegAddressIndex, and the available interfaces are represented by atmIlmiSrvcRegIndex, where the special value 0 indicates any ATM interface. When querying the ILMI service registry table, through the ILMI protocol: - the device attached to interface if1 will obtain the address a and b. - the device attached to interface if2 will obtain the address a only. - the device attached to interface if3 will obtain the address a and b. 3.1.15. ILMI Network Prefix Table A table specifying per-interface network prefix(es) supplied by the network side of the UNI during ILMI address registration. When no network prefixes are specified for a particular interface, one or more network prefixes based on the switch address(es) may be used for ILMI address registration. 3.1.16. ATM Switch Address Table This table contains one or more ATM endsystem addresses on a per- switch basis. These addresses are used to identify the switch. When no ILMI network prefixes are configured for certain interfaces, network prefixes based on the switch address(es) may be used for ILMI address registration. 3.1.17. AAL5 per-VCC Statistics Table This table contains the AAL5 statistics for the VCCs. Ly, et al. Standards Track [Page 19] RFC 3606 Supplemental ATM Managed Objects November 2003 3.1.18. ATM VP Cross-Connect Extension Table This table extends the atmVpCrossConnectTable defined in ATM-MIB [RFC2515]. 3.1.19. ATM VC Cross-Connect Extension Table This table extends the atmVcCrossConnectTable defined in ATM-MIB [RFC2515]. 3.1.20. Currently Failing PVPL Table This table contains all the PVPLs that are in trouble. 3.1.21. Currently Failing PVCL Table This table contains all the PVCLs that are in trouble. 3.1.22. Leaf Initiated Join Counter support Two counter objects are added to count the number of leaf intiated setup requests and setup failures. 3.2. Network and User Addresses At the user side of a given ATM UNI interface there may be an address, "ifPhysAddress", to identify the interface. In addition, there may be several other addresses which can be used to originate and receive calls. These other addresses that are used to receive calls are listed in the "ifRcvAddrTable" defined in RFC 2863. The registered addresses on the network side are listed in the ATM Registered Address Table. The ATM Registered Address Table is supported by switches and network services. It is not supported by hosts. 3.3. Configuration of VPLs, VCLs, and Cross-Connects The ATM Managed Objects needed to support the configuration of VPLs, VCLs, and Cross-Connects of the Permanent VPLs and VCLs are defined in the ATM-MIB [RFC2515]. Cross-Connects of the Switched VPLs and VCLs are defined in this memo. 3.4. ATM-related Trap Support Traps are defined to detect changes in the status of permanent VPLs and VCLs. The current up/down status of each permanent VPL or VCL is indicated by the atmVplOperStatus or atmVclOperStatus object, respectively. Several tables and objects and one trap are defined in Ly, et al. Standards Track [Page 20] RFC 3606 Supplemental ATM Managed Objects November 2003 order to help network managers quickly and efficiently detect changes in the status of permanent virtual links. Through use of these tables, objects, and traps, the time consuming and resource intensive task of continuously polling each row in the entire atmVplTable and atmVclTable can be avoided. The atmIntfPvcFailures counter and the atmIntfCurrentlyFailingPVpls and atmIntfCurrentlyFailingPVcls gauges provide a quick means of determining the status of all PVPLs and PVCLs on an interface. The atmCurrentlyFailingPVplTable and the atmCurrentlyFailingPVclTable list all of the problematic PVPLs and PVCLs, respectively, allowing them to be quickly identified. The atmIntfPvcFailuresTrap is generated just after a PVPL or PVCL on a particular interface leaves the 'up' operational state. Managers can then determine which PVPLs and/or PVCLs are failing by reading the atmCurrentlyFailingPVplTable and the atmCurrentlyFailingPVclTable. Generation of the atmIntfPvcFailuresTrap is rate limited by suppressing all traps that would occur within atmIntfPvcNotificationInterval of a previous trap for the same interface. Managers should continuously poll the tables and objects mentioned above for at least this amount of time in order to keep up with the state of the network. 4. Conformance and Compliance See the conformance and compliance statements within the information module. 5. Definitions ATM2-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Gauge32, Counter32, Integer32 FROM SNMPv2-SMI TruthValue, RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB InterfaceIndex, InterfaceIndexOrZero, ifIndex FROM IF-MIB atmMIBObjects, atmInterfaceConfEntry, atmVplEntry, atmVplVpi, atmVclEntry, atmVclVpi, atmVclVci, Ly, et al. Standards Track [Page 21] RFC 3606 Supplemental ATM Managed Objects November 2003 atmVpCrossConnectEntry, atmVcCrossConnectEntry FROM ATM-MIB AtmAddr, AtmSigDescrParamIndex, AtmInterfaceType, AtmIlmiNetworkPrefix, AtmVcIdentifier, AtmVpIdentifier, AtmTrafficDescrParamIndex FROM ATM-TC-MIB; atm2MIB MODULE-IDENTITY LAST-UPDATED "200309230000Z" ORGANIZATION "IETF AToMMIB Working Group" CONTACT-INFO "AToMMIB WG http://www.ietf.org/html.charters/atommib-charter.html Editors: Faye Ly Postal: Pedestal Networks 6503 Dumbarton Circle Fremont, CA 94555 USA Tel: +1 510 896 2908 E-Mail: faye@pedestalnetworks.com Michael Noto Postal: Cisco Systems 170 W. Tasman Drive San Jose, CA 95134-1706 USA E-mail: mnoto@cisco.com Andrew Smith Postal: Consultant E-Mail: ah_smith@acm.org Ethan Mickey Spiegel Postal: Cisco Systems 170 W. Tasman Drive San Jose, CA 95134-1706 USA Tel: +1 408 526 6408 Fax: +1 408 526 6488 E-Mail: mspiegel@cisco.com Kaj Tesink Postal: Telcordia Technologies 331 Newman Springs Road Ly, et al. Standards Track [Page 22] RFC 3606 Supplemental ATM Managed Objects November 2003 Red Bank, NJ 07701 USA Tel: +1 732 758 5254 E-mail: kaj@research.telcordia.com" DESCRIPTION "Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3606; see the RFC itself for full legal notices. This MIB Module is a supplement to the ATM-MIB defined in RFC 2515." REVISION "200309230000Z" DESCRIPTION "Initial version of this MIB, published as RFC 3606." ::= { atmMIBObjects 14 } atm2MIBObjects OBJECT IDENTIFIER ::= {atm2MIB 1} atm2MIBTraps OBJECT IDENTIFIER ::= {atm2MIB 2} -- This ATM2-MIB Module consists of the following tables, -- plus ATM trap support: -- 1. atmSvcVpCrossConnectTable -- 2. atmSvcVcCrossConnectTable -- 3. atmSigStatTable -- 4. atmSigSupportTable -- 5. atmSigDescrParamTable -- 6. atmIfRegisteredAddrTable -- 7. atmVclAddrTable -- 8. atmAddrVclTable -- 9. atmVplStatTable -- 10. atmVplLogicalPortTable -- 11. atmVclStatTable -- 12. atmAal5VclStatTable -- 13. atmVclGenTable -- 14. atmInterfaceExtTable -- 15. atmIlmiSrvcRegTable -- 16. atmIlmiNetworkPrefixTable -- 17. atmSwitchAddressTable -- 18. atmVpCrossConnectXTable -- 19. atmVcCrossConnectXTable -- 20. atmCurrentlyFailingPVplTable -- 21. atmCurrentlyFailingPVclTable -- 1. ATM VPL SVC Cross-Connect Table atmSvcVpCrossConnectTable OBJECT-TYPE Ly, et al. Standards Track [Page 23] RFC 3606 Supplemental ATM Managed Objects November 2003 SYNTAX SEQUENCE OF AtmSvcVpCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM SVPC Cross-Connect table. A bi-directional VP cross-connect between two switched VPLs is modeled as one entry in this table. A Soft PVPC cross-connect, between a soft permanent VPL and a switched VPL, is also modeled as one entry in this table." ::= { atm2MIBObjects 1 } atmSvcVpCrossConnectEntry OBJECT-TYPE SYNTAX AtmSvcVpCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM SVPC Cross-Connect table. This entry is used to model a bi-directional ATM VP cross-connect between two VPLs." INDEX { atmSvcVpCrossConnectIndex, atmSvcVpCrossConnectLowIfIndex, atmSvcVpCrossConnectLowVpi, atmSvcVpCrossConnectHighIfIndex, atmSvcVpCrossConnectHighVpi } ::= { atmSvcVpCrossConnectTable 1 } AtmSvcVpCrossConnectEntry ::= SEQUENCE { atmSvcVpCrossConnectIndex INTEGER, atmSvcVpCrossConnectLowIfIndex InterfaceIndex, atmSvcVpCrossConnectLowVpi AtmVpIdentifier, atmSvcVpCrossConnectHighIfIndex InterfaceIndex, atmSvcVpCrossConnectHighVpi AtmVpIdentifier, atmSvcVpCrossConnectCreationTime TimeStamp, atmSvcVpCrossConnectRowStatus RowStatus } atmSvcVpCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify this SVPC cross-connect. For each VP associated with this cross-connect, the agent reports this cross-connect index value in the atmVplCrossConnectIdentifer attribute of the Ly, et al. Standards Track [Page 24] RFC 3606 Supplemental ATM Managed Objects November 2003 corresponding atmVplTable entries." ::= { atmSvcVpCrossConnectEntry 1 } atmSvcVpCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the ifIndex value of the ATM interface port for this SVPC cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmSvcVpCrossConnectEntry." ::= { atmSvcVpCrossConnectEntry 2 } atmSvcVpCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VPI value associated with the SVPC cross-connect at the ATM interface that is identified by atmSvcVpCrossConnectLowIfIndex. The VPI value cannot exceed the number supported by the atmInterfaceCurrentMaxSvpcVpi at the low ATM interface port." ::= { atmSvcVpCrossConnectEntry 3 } atmSvcVpCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the ifIndex value of the ATM interface port for this SVC VP cross-connect. The term high implies that this ATM interface has the numerically higher ifIndex value than the other ATM interface identified in the same atmSvcVpCrossConnectEntry." ::= { atmSvcVpCrossConnectEntry 4 } atmSvcVpCrossConnectHighVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current Ly, et al. Standards Track [Page 25] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "The value of this object is equal to the VPI value associated with the SVPC cross-connect at the ATM interface that is identified by atmSvcVpCrossConnectHighIfIndex. The VPI value cannot exceed the number supported by the atmInterfaceCurrentMaxSvpcVpi at the high ATM interface port." ::= { atmSvcVpCrossConnectEntry 5 } atmSvcVpCrossConnectCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object at the time this bi-directional SVPC cross-connect was created. If the current state was entered prior to the last re-initialization of the agent, then this object contains a zero value." ::= { atmSvcVpCrossConnectEntry 6 } atmSvcVpCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to delete rows in the atmSvcVpCrossConnectTable." ::= { atmSvcVpCrossConnectEntry 7 } -- 2. ATM VCL SVC Cross-Connect Table atmSvcVcCrossConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSvcVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM SVCC Cross-Connect table. A bi-directional VC cross-connect between two switched VCLs is modeled as one entry in this table. A Soft PVCC cross-connect, between a soft permanent VCL and a switched VCL, is also modeled as one entry in this table." ::= { atm2MIBObjects 2 } Ly, et al. Standards Track [Page 26] RFC 3606 Supplemental ATM Managed Objects November 2003 atmSvcVcCrossConnectEntry OBJECT-TYPE SYNTAX AtmSvcVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM SVCC Cross-Connect table. This entry is used to model a bi-directional ATM VC cross-connect between two VCLs." INDEX { atmSvcVcCrossConnectIndex, atmSvcVcCrossConnectLowIfIndex, atmSvcVcCrossConnectLowVpi, atmSvcVcCrossConnectLowVci, atmSvcVcCrossConnectHighIfIndex, atmSvcVcCrossConnectHighVpi, atmSvcVcCrossConnectHighVci } ::= { atmSvcVcCrossConnectTable 1 } AtmSvcVcCrossConnectEntry ::= SEQUENCE { atmSvcVcCrossConnectIndex INTEGER, atmSvcVcCrossConnectLowIfIndex InterfaceIndex, atmSvcVcCrossConnectLowVpi AtmVpIdentifier, atmSvcVcCrossConnectLowVci AtmVcIdentifier, atmSvcVcCrossConnectHighIfIndex InterfaceIndex, atmSvcVcCrossConnectHighVpi AtmVpIdentifier, atmSvcVcCrossConnectHighVci AtmVcIdentifier, atmSvcVcCrossConnectCreationTime TimeStamp, atmSvcVcCrossConnectRowStatus RowStatus } atmSvcVcCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify this SVCC cross-connect. For each VP associated with this cross-connect, the agent reports this cross-connect index value in the atmVclCrossConnectIdentifier attribute of the corresponding atmVplTable entries." ::= { atmSvcVcCrossConnectEntry 1 } atmSvcVcCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the ifIndex value of the ATM interface port for this Ly, et al. Standards Track [Page 27] RFC 3606 Supplemental ATM Managed Objects November 2003 SVCC cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmSvcVcCrossConnectEntry." ::= { atmSvcVcCrossConnectEntry 2 } atmSvcVcCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VPI value associated with the SVCC cross-connect at the ATM interface that is identified by atmSvcVcCrossConnectLowIfIndex. The VPI value cannot exceed the number supported by the atmInterfaceCurrentMaxSvccVpi at the low ATM interface port." ::= { atmSvcVcCrossConnectEntry 3 } atmSvcVcCrossConnectLowVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VCI value associated with the SVCC cross-connect at the ATM interface that is identified by atmSvcVcCrossConnectLowIfIndex. The VCI value cannot exceed the number supported by the atmInterfaceCurrentMaxSvccVci at the low ATM interface port." ::= { atmSvcVcCrossConnectEntry 4 } atmSvcVcCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the ifIndex value for the ATM interface port for this SVCC cross-connect. The term high implies that this ATM interface has the numerically higher ifIndex value than the other ATM interface identified in the same atmSvcVcCrossConnectEntry." ::= { atmSvcVcCrossConnectEntry 5 } atmSvcVcCrossConnectHighVpi OBJECT-TYPE Ly, et al. Standards Track [Page 28] RFC 3606 Supplemental ATM Managed Objects November 2003 SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VPI value associated with the SVCC cross-connect at the ATM interface that is identified by atmSvcVcCrossConnectHighIfIndex. The VPI value cannot exceed the number supported by the atmInterfaceCurrentMaxSvccVpi at the high ATM interface port." ::= { atmSvcVcCrossConnectEntry 6 } atmSvcVcCrossConnectHighVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VCI value associated with the SVCC cross-connect at the ATM interface that is identified by atmSvcVcCrossConnectHighIfIndex. The VCI value cannot exceed the number supported by the atmInterfaceMaxVciBits at the high ATM interface port." ::= { atmSvcVcCrossConnectEntry 7 } atmSvcVcCrossConnectCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object at the time this bi-directional SVCC cross-connect was created. If the current state was entered prior to the last re-initialization of the agent, then this object contains a zero value." ::= { atmSvcVcCrossConnectEntry 8 } atmSvcVcCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to delete rows in the atmSvcVcCrossConnectTable." ::= { atmSvcVcCrossConnectEntry 9 } Ly, et al. Standards Track [Page 29] RFC 3606 Supplemental ATM Managed Objects November 2003 -- 3. ATM Interface Signalling Statistics Table -- atmSigStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM interface signalling statistics, one entry per ATM signalling interface." ::= { atm2MIBObjects 3 } atmSigStatEntry OBJECT-TYPE SYNTAX AtmSigStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains signalling statistics variables." INDEX { ifIndex } ::= { atmSigStatTable 1} AtmSigStatEntry ::= SEQUENCE { atmSigSSCOPConEvents Counter32, atmSigSSCOPErrdPdus Counter32, atmSigDetectSetupAttempts Counter32, atmSigEmitSetupAttempts Counter32, atmSigDetectUnavailRoutes Counter32, atmSigEmitUnavailRoutes Counter32, atmSigDetectUnavailResrcs Counter32, atmSigEmitUnavailResrcs Counter32, atmSigDetectCldPtyEvents Counter32, atmSigEmitCldPtyEvents Counter32, atmSigDetectMsgErrors Counter32, atmSigEmitMsgErrors Counter32, atmSigDetectClgPtyEvents Counter32, atmSigEmitClgPtyEvents Counter32, atmSigDetectTimerExpireds Counter32, atmSigEmitTimerExpireds Counter32, atmSigDetectRestarts Counter32, atmSigEmitRestarts Counter32, atmSigInEstabls Counter32, atmSigOutEstabls Counter32 } atmSigSSCOPConEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Ly, et al. Standards Track [Page 30] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "SSCOP Connection Events Counter. This counter counts the sum of the following errors: 1) SSCOP Connection Disconnect Counter The abnormal occurrence of this event is characterized by the expiry of Timer_NO_RESPONSE. (This event is communicated to the layer management with MAA-ERROR code P. See ITU-T Q.2110.) 2) SSCOP Connection Initiation Failure This condition indicates the inability to establish an SSCOP connection. This event occurs whenever the number of expiries of the connection control timer (Timer_CC) equals or exceeds the MaxCC, or upon receipt of a connection reject message BGREJ PDU. (This event is communicated to layer management with MAA-ERROR code O. See ITU-T Q.2110.) 3) SSCOP Connection Re-Establ/Resynch This event occurs upon receipt of a BGN PDU or RS PDU." REFERENCE "ITU-T Recommendation Q.2110, Broadband Integrated Services Digital Network (B-ISDN) - ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) Specification, July 1994." ::= { atmSigStatEntry 1} atmSigSSCOPErrdPdus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "SSCOP Errored PDUs Counter. This counter counts the sum of the following errors: 1) Invalid PDUs. These are defined in SSCOP and consist of PDUs with an incorrect length (MAA-ERROR code U), an undefined PDU type code, or that are not 32-bit aligned. 2) PDUs that result in MAA-ERROR codes and are Ly, et al. Standards Track [Page 31] RFC 3606 Supplemental ATM Managed Objects November 2003 discarded. See MAA-ERROR codes A-D, F-M, and Q-T defined in ITU-T Q.2110." REFERENCE "ITU-T Recommendation Q.2110, Broadband Integrated Services Digital Network (B-ISDN) - ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) Specification, July 1994." ::= { atmSigStatEntry 2 } atmSigDetectSetupAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Call Setup Attempts Counter. This counter counts the number of call setup attempts (both successful and unsuccessful) detected on this interface." ::= { atmSigStatEntry 3 } atmSigEmitSetupAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Call Setup Attempts Counter. This counter counts the number of call setup attempts (both successful and unsuccessful) transmitted on this interface." ::= { atmSigStatEntry 4 } atmSigDetectUnavailRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Route Unavailability detected on this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning Ly, et al. Standards Track [Page 32] RFC 3606 Supplemental ATM Managed Objects November 2003 1 unallocated (unassigned) number 2 no route to specified transit network 3 no route to destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 5 } atmSigEmitUnavailRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Route Unavailability transmitted from this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 1 unallocated (unassigned) number 2 no route to specified transit network 3 no route to destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 6 } atmSigDetectUnavailResrcs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Resource Unavailability detected on this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following Ly, et al. Standards Track [Page 33] RFC 3606 Supplemental ATM Managed Objects November 2003 cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 35 requested VPCI/VCI not available 37 user cell rate not available (UNI3.1 only) 38 network out of order 41 temporary failure 45 no VPCI/VCI available 47 resource unavailable, unspecified 49 Quality of Service unavailable 51 user cell rate not available (UNI3.0 only) 58 bearer capability not presently available 63 Service or option not available, unspecified 92 too many pending add party requests NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 7 } atmSigEmitUnavailResrcs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Resource Unavailability transmitted from this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 35 requested VPCI/VCI not available 37 user cell rate not available (UNI3.1 only) 38 network out of order Ly, et al. Standards Track [Page 34] RFC 3606 Supplemental ATM Managed Objects November 2003 41 temporary failure 45 no VPCI/VCI available 47 resource unavailable, unspecified 49 Quality of Service unavailable 51 user cell rate not available (UNI3.0 only) 58 bearer capability not presently available 63 Service or option not available, unspecified 92 too many pending add party requests NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 8 } atmSigDetectCldPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Called Party Responsible For Unsuccessful Call detected on this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 17 user busy 18 no user responding 21 call rejected 22 number changed 23 user rejects all calls with calling line identification restriction (CLIR) 27 destination out of order 31 normal, unspecified 88 incompatible destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be Ly, et al. Standards Track [Page 35] RFC 3606 Supplemental ATM Managed Objects November 2003 counted. Note: Cause Value #30 'response to STATUS ENQUIRY' was not included in this memo since it did not apply to a hard failure." ::= { atmSigStatEntry 9 } atmSigEmitCldPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Called Party Responsible For Unsuccessful Call transmitted from this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 17 user busy 18 no user responding 21 call rejected 22 number changed 23 user rejects all calls with calling line identification restriction (CLIR) 27 destination out of order 31 normal, unspecified 88 incompatible destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted. Note: Cause Value #30 'response to STATUS ENQUIRY' was not included in this memo since it did not apply to a hard failure." ::= { atmSigStatEntry 10 } atmSigDetectMsgErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Ly, et al. Standards Track [Page 36] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "Number of Incorrect Messages detected on this interface. The Incorrect Messages Counter reflects any sort of incorrect information in a message. This includes: - RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and STATUS messages transmitted, that contain any of the Cause values listed below. - Ignored messages. These messages are dropped because the message was so damaged that it could not be further processed. A list of dropped messages is compiled below: 1. Message with invalid protocol discriminator 2. Message with errors in the call reference I.E. - Bits 5-8 of the first octet not equal to '0000' - Bits 1-4 of the first octet indicating a length other than 3 octets - RELEASE COMPLETE message received with a call reference that does not relate to a call active or in progress - SETUP message received with call reference flag incorrectly set to 1 - SETUP message received with a call reference for a call that is already active or in progress. 3. Message too short The following cause values are monitored by this counter (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 10 VPCI/VCI unacceptable (UNI3.0 only) 36 VPCI/VCI assignment failure (UNI3.1 only) 81 invalid call reference value 82 identified channel does not exist 89 invalid endpoint reference 96 mandatory information element is missing 97 message type non-existent or not implemented 99 information element non-existent or not implemented Ly, et al. Standards Track [Page 37] RFC 3606 Supplemental ATM Managed Objects November 2003 100 invalid information element contents 101 message not compatible with call state 104 incorrect message length 111 protocol error, unspecified NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 11 } atmSigEmitMsgErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Incorrect Messages transmitted on this interface. The Incorrect Messages Counter reflects any sort of incorrect information in a message. This includes: - RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and STATUS messages transmitted or received, that contain any of the Cause values listed below. - Ignored messages. These messages are dropped because the message was so damaged that it could not be further processed. A list of dropped messages is compiled below: 1. Message with invalid protocol discriminator 2. Message with errors in the call reference I.E. - Bits 5-8 of the first octet not equal to '0000' - Bits 1-4 of the first octet indicating a length other than 3 octets - RELEASE COMPLETE message received with a call reference that does not relate to a call active or in progress - SETUP message received with call reference flag incorrectly set to 1 - SETUP message received with a call reference for a call that is already active or in progress. 3. Message too short Ly, et al. Standards Track [Page 38] RFC 3606 Supplemental ATM Managed Objects November 2003 The following cause values are monitored by this counter (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 10 VPCI/VCI unacceptable (UNI3.0 only) 36 VPCI/VCI assignment failure (UNI3.1 only) 81 invalid call reference value 82 identified channel does not exist 89 invalid endpoint reference 96 mandatory information element is missing 97 message type non-existent or not implemented 99 information element non-existent or not implemented 100 invalid information element contents 101 message not compatible with call state 104 incorrect message length 111 protocol error, unspecified NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 12 } atmSigDetectClgPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Calling Party Events detected on this interface. This counter monitors error events that occur due to the originating user doing something wrong. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 28 invalid number format (address incomplete) 43 access information discarded 57 bearer capability not authorized 65 bearer capability not implemented Ly, et al. Standards Track [Page 39] RFC 3606 Supplemental ATM Managed Objects November 2003 73 unsupported combination of traffic parameters 78 AAL parameters cannot be supported (UNI3.1 only) 91 invalid transit network selection 93 AAL parameters cannot be supported (UNI3.0 only) NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 13 } atmSigEmitClgPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Calling Party Events transmitted from this interface. This counter monitors error events that occur due to the originating user doing something wrong. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE message for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 28 invalid number format (address incomplete) 43 access information discarded 57 bearer capability not authorized 65 bearer capability not implemented 73 unsupported combination of traffic parameters 78 AAL parameters cannot be supported (UNI3.1 only) 91 invalid transit network selection 93 AAL parameters cannot be supported (UNI3.0 only) NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." Ly, et al. Standards Track [Page 40] RFC 3606 Supplemental ATM Managed Objects November 2003 ::= { atmSigStatEntry 14 } atmSigDetectTimerExpireds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Timer Expiries detected on this interface. The Timer Expiries Counter provides a count of network timer expiries, and to some extent, host or switch timer expiries. The conditions for incrementing this counter are: - Expiry of any network timer - Receipt of a RELEASE or RELEASE COMPLETE message with Cause #102, 'recovery on timer expiry'. NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 15 } atmSigEmitTimerExpireds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Timer Expiries transmitted from this interface. The Timer Expiries Counter provides a count of network timer expiries, and to some extent, host or switch timer expiries. The conditions for incrementing this counter are: - Expiry of any network timer - Receipt of a RELEASE or RELEASE COMPLETE message with Cause #102, 'recovery on timer expiry'. NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 16 } Ly, et al. Standards Track [Page 41] RFC 3606 Supplemental ATM Managed Objects November 2003 atmSigDetectRestarts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Restart Activity errors detected on this interface. The Restart Activity Counter provides a count of host, switch, or network restart activity. This counter is incremented when receiving a RESTART message." ::= { atmSigStatEntry 17 } atmSigEmitRestarts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Restart Activity errors transmitted from this interface. The Restart Activity Counter provides a count of host, switch, or network restart activity. This counter is incremented when transmitting a RESTART message." ::= { atmSigStatEntry 18 } atmSigInEstabls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SVCs established at this signalling entity for incoming connections." ::= { atmSigStatEntry 19 } atmSigOutEstabls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SVCs established at this signalling entity for outgoing connections." ::= { atmSigStatEntry 20 } -- 4. ATM Interface Signalling Support Table -- -- This table provides information to support -- the signalling process which is used to establish -- ATM Switched Virtual Connections (SVCs). Ly, et al. Standards Track [Page 42] RFC 3606 Supplemental ATM Managed Objects November 2003 atmSigSupportTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigSupportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM local interface configuration parameters, one entry per ATM signalling interface." ::= { atm2MIBObjects 4 } atmSigSupportEntry OBJECT-TYPE SYNTAX AtmSigSupportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains signalling configuration parameters and state variables." INDEX { ifIndex } ::= { atmSigSupportTable 1} AtmSigSupportEntry ::= SEQUENCE { atmSigSupportClgPtyNumDel INTEGER, atmSigSupportClgPtySubAddr INTEGER, atmSigSupportCldPtySubAddr INTEGER, atmSigSupportHiLyrInfo INTEGER, atmSigSupportLoLyrInfo INTEGER, atmSigSupportBlliRepeatInd INTEGER, atmSigSupportAALInfo INTEGER, atmSigSupportPrefCarrier OCTET STRING } atmSigSupportClgPtyNumDel OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the Calling Party Number Information Element is transferred to the called party address. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 1 } atmSigSupportClgPtySubAddr OBJECT-TYPE Ly, et al. Standards Track [Page 43] RFC 3606 Supplemental ATM Managed Objects November 2003 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept and transfer the Calling Party Subaddress Information Element from the calling party to the called party. Calling party subaddress information shall only be transferred to the called party if calling party number delivery is enabled (i.e., atmSigSupportClgPtyNumDel = 'enabled(1)'. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 2 } atmSigSupportCldPtySubAddr OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Called Party Subaddress Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 3 } atmSigSupportHiLyrInfo OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Broadband High Layer Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party Ly, et al. Standards Track [Page 44] RFC 3606 Supplemental ATM Managed Objects November 2003 - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 4 } atmSigSupportLoLyrInfo OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Broadband Low Layer Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 5 } atmSigSupportBlliRepeatInd OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Broadband Repeat Indicator with two or three instances of the Broadband Low Layer Information Element for low layer information selection from the calling party to the called party. This object's value should always be disabled(2) if the value of atmSigSupportLolyrInfo is disabled(2). The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 6 } atmSigSupportAALInfo OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION Ly, et al. Standards Track [Page 45] RFC 3606 Supplemental ATM Managed Objects November 2003 "This object indicates whether to accept, transfer, and deliver the ATM Adaptation Layer Parameters Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 7 } atmSigSupportPrefCarrier OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0|4)) MAX-ACCESS read-write STATUS current DESCRIPTION "This parameter identifies the carrier to which intercarrier calls originated from this interface are routed when transit network selection information is not provided by the calling party. If a Carrier Identification Code (CIC) is used the parameter shall contain the CIC. For three-digit CICs, the first octet shall be '0' and the CIC is contained in the three following octets. If the preferred carrier feature is not supported the value is a zero-length string." ::= { atmSigSupportEntry 8 } -- 5. ATM Signalling Descriptor Parameter Table atmSigDescrParamTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table contains signalling capabilities of VCLs except the Traffic Descriptor. Traffic descriptors are described in the atmTrafficDescrParamTable." REFERENCE "ATM User-Network Interface Specification, Version 3.1 (UNI 3.1), September 1994, Section 5.4.5 Variable Length Information Elements." ::= { atm2MIBObjects 5 } atmSigDescrParamEntry OBJECT-TYPE Ly, et al. Standards Track [Page 46] RFC 3606 Supplemental ATM Managed Objects November 2003 SYNTAX AtmSigDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a set of signalling capabilities that can be applied to a VCL. There is no requirement for unique entries, except that the index must be unique." INDEX { atmSigDescrParamIndex } ::= { atmSigDescrParamTable 1 } AtmSigDescrParamEntry ::= SEQUENCE { atmSigDescrParamIndex AtmSigDescrParamIndex, atmSigDescrParamAalType INTEGER, atmSigDescrParamAalSscsType INTEGER, atmSigDescrParamBhliType INTEGER, atmSigDescrParamBhliInfo OCTET STRING, atmSigDescrParamBbcConnConf INTEGER, atmSigDescrParamBlliLayer2 INTEGER, atmSigDescrParamBlliLayer3 INTEGER, atmSigDescrParamBlliPktSize INTEGER, atmSigDescrParamBlliSnapId INTEGER, atmSigDescrParamBlliOuiPid OCTET STRING, atmSigDescrParamRowStatus RowStatus } atmSigDescrParamIndex OBJECT-TYPE SYNTAX AtmSigDescrParamIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is used by the atmVclGenSigDescrIndex object in the atmVclGenTable to identify a row in this table." ::= { atmSigDescrParamEntry 1 } atmSigDescrParamAalType OBJECT-TYPE SYNTAX INTEGER { other(1), -- not defined aal1(2), -- AAL type 1 aal34(3), -- AAL type 3/4 aal5(4), -- AAL type 5 Ly, et al. Standards Track [Page 47] RFC 3606 Supplemental ATM Managed Objects November 2003 userDefined(5), -- User-Defined AAL aal2(6) -- AAL type 2 } MAX-ACCESS read-create STATUS current DESCRIPTION "The AAL type. The value of this object is set to other(1) when not defined." DEFVAL { other } ::= { atmSigDescrParamEntry 2 } atmSigDescrParamAalSscsType OBJECT-TYPE SYNTAX INTEGER { other(1), -- other, or not used assured(2), -- Data SSCS based on SSCOP -- assured operation nonassured(3), -- Data SSCS based on SSCOP -- non-assured operation frameRelay(4), -- frame relay SSCS null(5) -- null } MAX-ACCESS read-create STATUS current DESCRIPTION "The SSCS type used by this entry." DEFVAL { other } ::= { atmSigDescrParamEntry 3 } atmSigDescrParamBhliType OBJECT-TYPE SYNTAX INTEGER { other(1), -- not defined iso(2), -- ISO user(3), -- User specific hiProfile(4), -- Higher layer profile -- this enum applicable to -- UNI 3.0 only vendorSpecific(5) -- Vender specific -- application identifier } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband high layer type." DEFVAL { other } Ly, et al. Standards Track [Page 48] RFC 3606 Supplemental ATM Managed Objects November 2003 ::= { atmSigDescrParamEntry 4 } atmSigDescrParamBhliInfo OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..8)) MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband high layer information. When atmSigDescrParamBhliType is set to iso(2), the value of this object is a zero length string. When atmSigDescrParamBhliType is set to user(3), the value of this object is an octet string with length ranging from 0 to 8. When atmSigDescrParamBhliType is set to hiProfile(4), the value of this object is a length of 4 octet string containing user to user profile identifier. When atmSigDescrParamBhliType is set to vendorSpecific(5), the value of this object is a length of 7 octet string, where the most significant 3 octets consist of a globally- administered OUI, and the least significant 4 octets are the vender administered application OUI." DEFVAL { ''H } ::= { atmSigDescrParamEntry 5 } atmSigDescrParamBbcConnConf OBJECT-TYPE SYNTAX INTEGER { ptp(1), -- point-to-point ptmp(2) -- point-to-multipoint } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband bearer capability user plane connection configuration parameter." DEFVAL { ptp } ::= { atmSigDescrParamEntry 6 } atmSigDescrParamBlliLayer2 OBJECT-TYPE SYNTAX INTEGER { other(1), -- not specified iso1745(2), -- Basic mode ISO 1745 q921(3), -- CCITT Recommendation Q.921 x25linklayer(4), -- CCITT Recommendation X.25 -- Link Layer x25multilink(5), -- CCITT Recommendation X.25 -- Multilink lapb(6), -- Extended LAPB; for half Ly, et al. Standards Track [Page 49] RFC 3606 Supplemental ATM Managed Objects November 2003 -- duplex operation hdlcArm(7), -- HDLC ARM (ISO 4335) hdlcNrm(8), -- HDLC NRM (ISO 4335) hdlcAbm(9), -- HDLC ABM (ISO 4335) iso88022(10), -- LAN logical link control -- (ISO 8802/2) x75slp(11), -- CCITT Recommendation X.75, -- single link -- procedure (SLP) q922(12), -- CCITT Recommendation Q.922 userDef(13), -- User specified iso7776(14) -- ISO 7776 DTE-DTE operation } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband low layer information, protocol type of layer 2. The value of this object is other(1) if layer 2 protocol is not used." DEFVAL { other } ::= { atmSigDescrParamEntry 7 } atmSigDescrParamBlliLayer3 OBJECT-TYPE SYNTAX INTEGER { other(1), -- not specified x25pkt(2), -- CCITT Recommendation X.25 -- packet layer isoiec8208(3), -- ISO/IEC 8208 (X.25 packet -- level protocol for data -- terminal equipment) x223iso8878(4), -- X.223/ISO 8878 isoiec8473(5), -- ISO/IEC 8473 OSI -- connectionless -- mode protocol t70(6), -- CCITT Recommendation T.70 -- minimum -- network layer tr9577(7), -- ISO/IEC TR 9577 Protocol -- Identification in the -- network layer userDef(8) -- user specified } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband low layer information, protocol type of layer Ly, et al. Standards Track [Page 50] RFC 3606 Supplemental ATM Managed Objects November 2003 3. The value of this object is other(1) if layer 3 protocol is not used." DEFVAL { other } ::= { atmSigDescrParamEntry 8 } atmSigDescrParamBlliPktSize OBJECT-TYPE SYNTAX INTEGER { other(1), -- not used s16(2), -- 16 octets s32(3), -- 32 octets s64(4), -- 64 octets s128(5), -- 128 octets s256(6), -- 256 octets s512(7), -- 512 octets s1024(8), -- 1028 octets s2048(9), -- 2048 octets s4096(10) -- 4096 octets } MAX-ACCESS read-create STATUS current DESCRIPTION "The default packet size defined in B-LLI." DEFVAL { other } ::= { atmSigDescrParamEntry 9 } atmSigDescrParamBlliSnapId OBJECT-TYPE SYNTAX INTEGER { other(1), -- not used true(2), -- SNAP ID is 1 false(3) -- SNAP ID is 0 } MAX-ACCESS read-create STATUS current DESCRIPTION "The SNAP ID used for Broadband low layer protocol layer 3. The value of this object is other(1) if atmSigDescrParamBlliLayer3 is set to other(1)." DEFVAL { other } ::= { atmSigDescrParamEntry 10 } atmSigDescrParamBlliOuiPid OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0|5)) MAX-ACCESS read-create STATUS current DESCRIPTION Ly, et al. Standards Track [Page 51] RFC 3606 Supplemental ATM Managed Objects November 2003 "The OUI/PID encoding for Broadband low layer protocol layer 3. The value of this object is a zero length string if atmSigDescrParamBlliLayer3 is set to other(1). When used, it is always 5 octets with the most significant octet as the OUI Octet 1 and the least significant octet as the PID Octet 2." DEFVAL { ''H } ::= { atmSigDescrParamEntry 11 } atmSigDescrParamRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the atmSigDescrParamTable." ::= { atmSigDescrParamEntry 12 } -- 6. ATM Interface Registered Address Table -- atmIfRegisteredAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmIfRegisteredAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of ATM addresses that can be used for calls to and from a given interface by a switch or service. The ATM addresses are either registered by the endsystem via ILMI or statically configured. This table does not expose PNNI reachability information. ILMI registered addresses cannot be deleted using this table. This table only applies to switches and network services." ::= { atm2MIBObjects 6 } atmIfRegisteredAddrEntry OBJECT-TYPE SYNTAX AtmIfRegisteredAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM Interface Registered Address table." INDEX { ifIndex, atmIfRegAddrAddress } ::= { atmIfRegisteredAddrTable 1} AtmIfRegisteredAddrEntry ::= SEQUENCE { atmIfRegAddrAddress AtmAddr, Ly, et al. Standards Track [Page 52] RFC 3606 Supplemental ATM Managed Objects November 2003 atmIfRegAddrAddressSource INTEGER, atmIfRegAddrOrgScope INTEGER, atmIfRegAddrRowStatus RowStatus } atmIfRegAddrAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "An address registered for a given switch or service interface." ::= { atmIfRegisteredAddrEntry 1} atmIfRegAddrAddressSource OBJECT-TYPE SYNTAX INTEGER { other(1), static(2), dynamic(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address source for a given ATM Address. The value dynamic(3) is indicated when ILMI is used." ::= { atmIfRegisteredAddrEntry 2} atmIfRegAddrOrgScope OBJECT-TYPE SYNTAX INTEGER { localNetwork(1), localNetworkPlusOne(2), localNetworkPlusTwo(3), siteMinusOne(4), intraSite(5), sitePlusOne(6), organizationMinusOne(7), intraOrganization(8), organizationPlusOne(9), communityMinusOne(10), intraCommunity(11), communityPlusOne(12), regional(13), interRegional(14), global(15) } MAX-ACCESS read-create STATUS current DESCRIPTION Ly, et al. Standards Track [Page 53] RFC 3606 Supplemental ATM Managed Objects November 2003 "This object indicates the organizational scope for the referenced address. The information of the referenced address shall not be distributed outside the indicated scope. Refer to Annex 5.3 of ATM Forum UNI Signalling 4.0 for guidelines regarding the use of organizational scopes. This value cannot be configured for ILMI-registered addresses. The default values for organizational scope are localNetwork(1) for ATM group addresses, and global(15) for individual addresses." ::= { atmIfRegisteredAddrEntry 3} atmIfRegAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the atmIfRegisteredAddrTable. Rows created dynamically (e.g., ILMI- registered addresses) cannot be deleted using this object." ::= { atmIfRegisteredAddrEntry 4} -- 7. ATM VPI/VCI to Address Mapping Table atmVclAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a mapping between the atmVclTable and the ATM called party/calling party address. This table can be used to retrieve the calling party and called party ATM address pair for a given VCL. Note that there can be more than one pair of calling party and called party ATM addresses for a VCL in a point to multi-point call." ::= { atm2MIBObjects 7 } atmVclAddrEntry OBJECT-TYPE SYNTAX AtmVclAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a binding between a VCL and an ATM address associated with this call. This ATM Ly, et al. Standards Track [Page 54] RFC 3606 Supplemental ATM Managed Objects November 2003 address can be either the called party address or the calling party address. There can be more than one pair of calling/called party ATM addresses associated with the VCL entry for point to multi-point calls. Objects atmVclAddrType, and atmVclAddrRowStatus are required during row creation." INDEX { ifIndex, atmVclVpi, atmVclVci, atmVclAddrAddr } ::= { atmVclAddrTable 1 } AtmVclAddrEntry ::= SEQUENCE { atmVclAddrAddr AtmAddr, atmVclAddrType INTEGER, atmVclAddrRowStatus RowStatus } atmVclAddrAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ATM address on one end of the VCL. For SVCs, the agent supplies the value of this object at creation time. For PVC VCL, the manager can supply the value of this object during or after the PVC VCL creation." ::= { atmVclAddrEntry 1 } atmVclAddrType OBJECT-TYPE SYNTAX INTEGER { callingParty(1), calledParty(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of ATM Address represented by the object atmVclAddrAddr. Choices are either the calling party ATM address or the called party ATM address." ::= { atmVclAddrEntry 2 } atmVclAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create or destroy an entry from this table. Note that the manager entity Ly, et al. Standards Track [Page 55] RFC 3606 Supplemental ATM Managed Objects November 2003 can only destroy the PVC VCLs." ::= { atmVclAddrEntry 3 } -- 8. ATM Address to VPI/VCI Mapping Table -- -- This table provides an alternative way to access -- a row in the atmVclAddrTable by using -- an ATM address as an index, instead of -- the ifIndex atmAddrVclTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmAddrVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides an alternative way to retrieve the atmVclTable. This table can be used to retrieve the indexing to the atmVclTable by an ATM address." ::= { atm2MIBObjects 8 } atmAddrVclEntry OBJECT-TYPE SYNTAX AtmAddrVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents an entry in the atmVclTable of the ATM-MIB by its ATM address. The ATM address is either the calling or called party ATM address of the call. Entries in this table are read only. They show up when entries are created in the atmVclAddrTable." REFERENCE "Tesink, K., Editor, Definitions of Managed Objects for ATM Management, RFC 2515, Bell Communications Research, February, 1999." INDEX { atmVclAddrAddr, atmAddrVclAtmIfIndex, atmAddrVclVpi, atmAddrVclVci } ::= { atmAddrVclTable 1 } AtmAddrVclEntry ::= SEQUENCE { atmAddrVclAtmIfIndex InterfaceIndex, atmAddrVclVpi AtmVpIdentifier, atmAddrVclVci AtmVcIdentifier, atmAddrVclAddrType INTEGER } Ly, et al. Standards Track [Page 56] RFC 3606 Supplemental ATM Managed Objects November 2003 atmAddrVclAtmIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index of the ATM interface to which this VCL pertains. This object combined with the atmAddrVclVpi and atmAddrVclVci objects serves as an index to the atmVclTable." ::= { atmAddrVclEntry 1 } atmAddrVclVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value of the VCL. This object combined with the atmAddrVclAtmIfIndex and atmAddrVclVci objects serves as an index to the atmVclTable." ::= { atmAddrVclEntry 2 } atmAddrVclVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value of the VCL. This object combined with the atmAddrVclAtmIfIndex and atmAddrVclVpi objects serves as an index to the atmVclTable." ::= { atmAddrVclEntry 3 } atmAddrVclAddrType OBJECT-TYPE SYNTAX INTEGER { callingParty(1), calledParty(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of ATM Address represented by the object atmVclAddrAddr. Choices are either calling party address or called party address." ::= { atmAddrVclEntry 4 } -- 9. ATM VPL Statistics Table atmVplStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVplStatEntry MAX-ACCESS not-accessible Ly, et al. Standards Track [Page 57] RFC 3606 Supplemental ATM Managed Objects November 2003 STATUS current DESCRIPTION "This table contains all statistics counters per VPL. It is used to monitor the usage of the VPL in terms of incoming cells and outgoing cells." ::= { atm2MIBObjects 9 } atmVplStatEntry OBJECT-TYPE SYNTAX AtmVplStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a VPL." INDEX { ifIndex, atmVplVpi } ::= { atmVplStatTable 1 } AtmVplStatEntry ::= SEQUENCE { atmVplStatTotalCellIns Counter32, atmVplStatClp0CellIns Counter32, atmVplStatTotalDiscards Counter32, atmVplStatClp0Discards Counter32, atmVplStatTotalCellOuts Counter32, atmVplStatClp0CellOuts Counter32, atmVplStatClp0Tagged Counter32 } atmVplStatTotalCellIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells received by this VPL including both CLP=0 and CLP=1 cells. The cells are counted prior to the application of the traffic policing." ::= { atmVplStatEntry 1 } atmVplStatClp0CellIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid ATM cells received by this VPL with CLP=0. The cells are counted prior to the application of the traffic policing." ::= { atmVplStatEntry 2 } atmVplStatTotalDiscards OBJECT-TYPE Ly, et al. Standards Track [Page 58] RFC 3606 Supplemental ATM Managed Objects November 2003 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells discarded by the traffic policing entity. This includes cells originally received with CLP=0 and CLP=1." ::= { atmVplStatEntry 3 } atmVplStatClp0Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells received with CLP=0 and discarded by the traffic policing entity." ::= { atmVplStatEntry 4 } atmVplStatTotalCellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells transmitted by this VPL. This includes both CLP=0 and CLP=1 cells." ::= { atmVplStatEntry 5 } atmVplStatClp0CellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells transmitted with CLP=0 by this VPL." ::= { atmVplStatEntry 6 } atmVplStatClp0Tagged OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells tagged by the traffic policing entity from CLP=0 to CLP=1." ::= { atmVplStatEntry 7 } -- 10. ATM Logical Port Configuration Table atmVplLogicalPortTable OBJECT-TYPE Ly, et al. Standards Track [Page 59] RFC 3606 Supplemental ATM Managed Objects November 2003 SYNTAX SEQUENCE OF AtmVplLogicalPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates whether the VPL is an ATM Logical Port interface (ifType=80)." ::= { atm2MIBObjects 10 } atmVplLogicalPortEntry OBJECT-TYPE SYNTAX AtmVplLogicalPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry with information about the ATM Logical Port interface." AUGMENTS { atmVplEntry } ::= { atmVplLogicalPortTable 1 } AtmVplLogicalPortEntry ::= SEQUENCE { atmVplLogicalPortDef INTEGER, atmVplLogicalPortIndex InterfaceIndexOrZero } atmVplLogicalPortDef OBJECT-TYPE SYNTAX INTEGER { notLogicalIf(1), isLogicalIf(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the VPC at this VPL interface is an ATM Logical Port interface." DEFVAL { notLogicalIf } ::= { atmVplLogicalPortEntry 1 } atmVplLogicalPortIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The ifTable index of the ATM logical port interface associated with this VPL. The distinguished value of zero indicates that the agent has not (yet) assigned such an ifTable Index. The zero value must be assigned by the agent if the value of atmVplLogicalPortDef is set to notLogicalIf, or if the VPL row is not active." Ly, et al. Standards Track [Page 60] RFC 3606 Supplemental ATM Managed Objects November 2003 ::= { atmVplLogicalPortEntry 2 } -- 11. ATM VCL Statistics Table atmVclStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all statistics counters per VCL. It is used to monitor the usage of the VCL in terms of incoming cells and outgoing cells." ::= { atm2MIBObjects 11 } atmVclStatEntry OBJECT-TYPE SYNTAX AtmVclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a VCL." INDEX { ifIndex, atmVclVpi, atmVclVci } ::= { atmVclStatTable 1 } AtmVclStatEntry ::= SEQUENCE { atmVclStatTotalCellIns Counter32, atmVclStatClp0CellIns Counter32, atmVclStatTotalDiscards Counter32, atmVclStatClp0Discards Counter32, atmVclStatTotalCellOuts Counter32, atmVclStatClp0CellOuts Counter32, atmVclStatClp0Tagged Counter32 } atmVclStatTotalCellIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells received by this VCL including both CLP=0 and CLP=1 cells. The cells are counted prior to the application of the traffic policing." ::= { atmVclStatEntry 1 } atmVclStatClp0CellIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Ly, et al. Standards Track [Page 61] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "The number of valid ATM cells received by this VCL with CLP=0. The cells are counted prior to the application of the traffic policing." ::= { atmVclStatEntry 2 } atmVclStatTotalDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells discarded by the traffic policing entity. This includes cells originally received with CLP=0 and CLP=1." ::= { atmVclStatEntry 3 } atmVclStatClp0Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells received with CLP=0 and discarded by the traffic policing entity." ::= { atmVclStatEntry 4 } atmVclStatTotalCellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells transmitted by this VCL. This includes both CLP=0 and CLP=1 cells." ::= { atmVclStatEntry 5 } atmVclStatClp0CellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells transmitted with CLP=0 by this VCL." ::= { atmVclStatEntry 6 } atmVclStatClp0Tagged OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Ly, et al. Standards Track [Page 62] RFC 3606 Supplemental ATM Managed Objects November 2003 "The total number of valid ATM cells tagged by the traffic policing entity from CLP=0 to CLP=1." ::= { atmVclStatEntry 7 } -- 12. ATM AAL5 per-VCC Statistics Table atmAal5VclStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmAal5VclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a collection of objects providing AAL5 configuration and performance statistics of a VCL." ::= { atm2MIBObjects 12 } atmAal5VclStatEntry OBJECT-TYPE SYNTAX AtmAal5VclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents an AAL5 VCL, and is indexed by ifIndex values of AAL5 interfaces and the associated VPI/VCI values." INDEX { ifIndex, atmVclVpi, atmVclVci } ::= { atmAal5VclStatTable 1 } AtmAal5VclStatEntry ::= SEQUENCE { atmAal5VclInPkts Counter32, atmAal5VclOutPkts Counter32, atmAal5VclInOctets Counter32, atmAal5VclOutOctets Counter32 } atmAal5VclInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs received on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 1 } atmAal5VclOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Ly, et al. Standards Track [Page 63] RFC 3606 Supplemental ATM Managed Objects November 2003 "The number of AAL5 CPCS PDUs transmitted on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 2 } atmAal5VclInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in AAL5 CPCS PDUs received on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 3 } atmAal5VclOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in AAL5 CPCS PDUs transmitted on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 4 } -- 13. ATM VC General Information Table atmVclGenTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclGenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "General Information for each VC." ::= { atm2MIBObjects 13 } atmVclGenEntry OBJECT-TYPE SYNTAX AtmVclGenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry with general information about the ATM VC." AUGMENTS { atmVclEntry } ::= { atmVclGenTable 1 } AtmVclGenEntry ::= SEQUENCE { atmVclGenSigDescrIndex AtmSigDescrParamIndex } Ly, et al. Standards Track [Page 64] RFC 3606 Supplemental ATM Managed Objects November 2003 atmVclGenSigDescrIndex OBJECT-TYPE SYNTAX AtmSigDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ATM Signalling Descriptor Parameter Table which applies to this VCL." ::= { atmVclGenEntry 1 } -- 14. ATM Interface Configuration Extension Table atmInterfaceExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM interface configuration and monitoring information not defined in the atmInterfaceConfTable from the ATM-MIB. This includes the type of connection setup procedures, ILMI information, and information on the VPI/VCI range." REFERENCE "Tesink, K., Editor, Definitions of Managed Objects for ATM Management, RFC 2515, Bell Communications Research, February, 1999." ::= { atm2MIBObjects 14 } atmInterfaceExtEntry OBJECT-TYPE SYNTAX AtmInterfaceExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry extends the atmInterfaceConfEntry defined in the ATM- MIB. Each entry corresponds to an ATM interface." REFERENCE "Tesink, K., Editor, Definitions of Managed Objects for ATM Management, RFC 2515, Bell Communications Research, February, 1999." AUGMENTS { atmInterfaceConfEntry } ::= { atmInterfaceExtTable 1 } AtmInterfaceExtEntry ::= SEQUENCE { atmIntfConfigType AtmInterfaceType, atmIntfActualType AtmInterfaceType, atmIntfConfigSide INTEGER, atmIntfActualSide INTEGER, atmIntfIlmiAdminStatus BITS, atmIntfIlmiOperStatus BITS, Ly, et al. Standards Track [Page 65] RFC 3606 Supplemental ATM Managed Objects November 2003 atmIntfIlmiFsmState INTEGER, atmIntfIlmiEstablishConPollIntvl Integer32, atmIntfIlmiCheckConPollIntvl Integer32, atmIntfIlmiConPollInactFactor Integer32, atmIntfIlmiPublicPrivateIndctr INTEGER, atmInterfaceConfMaxSvpcVpi INTEGER, atmInterfaceCurrentMaxSvpcVpi INTEGER, atmInterfaceConfMaxSvccVpi INTEGER, atmInterfaceCurrentMaxSvccVpi INTEGER, atmInterfaceConfMinSvccVci INTEGER, atmInterfaceCurrentMinSvccVci INTEGER, atmIntfSigVccRxTrafficDescrIndex AtmTrafficDescrParamIndex, atmIntfSigVccTxTrafficDescrIndex AtmTrafficDescrParamIndex, atmIntfPvcFailures Counter32, atmIntfCurrentlyFailingPVpls Gauge32, atmIntfCurrentlyFailingPVcls Gauge32, atmIntfPvcFailuresTrapEnable TruthValue, atmIntfPvcNotificationInterval INTEGER, atmIntfLeafSetupFailures Counter32, atmIntfLeafSetupRequests Counter32 } atmIntfConfigType OBJECT-TYPE SYNTAX AtmInterfaceType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of connection setup procedures configured for the ATM interface. Setting this variable to a value of 'other' is not allowed." DEFVAL { autoConfig } ::= { atmInterfaceExtEntry 1 } atmIntfActualType OBJECT-TYPE SYNTAX AtmInterfaceType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of connection setup procedures currently being used on the interface. This may reflect a manually configured value for the interface type, or may be determined by other means such as auto-configuration. A value of `autoConfig' indicates that auto-configuration was requested but has not yet been completed." ::= { atmInterfaceExtEntry 2 } atmIntfConfigSide OBJECT-TYPE SYNTAX INTEGER { Ly, et al. Standards Track [Page 66] RFC 3606 Supplemental ATM Managed Objects November 2003 other(1), user(2), network(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The configured role of the managed entity as one side of the ATM interface. This value does not apply when the object atmIntfConfigType is set to `autoConfig', `atmfPnni1Dot0', or `atmfBici2Dot0'." ::= { atmInterfaceExtEntry 3 } atmIntfActualSide OBJECT-TYPE SYNTAX INTEGER { other(1), user(2), network(3), symmetric(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current role used by the managed entity to represent one side of the ATM interface." ::= { atmInterfaceExtEntry 4 } atmIntfIlmiAdminStatus OBJECT-TYPE SYNTAX BITS { ilmi(0), ilmiAddressRegistration(1), ilmiConnectivity(2), ilmiPvcPvpMgmt(3), ilmiSigVccParamNegotiation(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates which components of ILMI are administratively enabled on this interface. If the 'ilmi' bit is not set, then no ILMI components are operational. ILMI components other than auto- configuration that are not represented in the value have their administrative status determined according to the 'ilmi' bit. The ILMI auto-configuration component is enabled/disabled by the atmIntfConfigType object." ::= { atmInterfaceExtEntry 5 } atmIntfIlmiOperStatus OBJECT-TYPE SYNTAX BITS { ilmi(0), ilmiAddressRegistration(1), ilmiConnectivity(2), ilmiPvcPvpMgmt(3), Ly, et al. Standards Track [Page 67] RFC 3606 Supplemental ATM Managed Objects November 2003 ilmiSigVccParamNegotiation(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates which components of ILMI are operational on this interface." ::= { atmInterfaceExtEntry 6 } atmIntfIlmiFsmState OBJECT-TYPE SYNTAX INTEGER { stopped(1), linkFailing(2), establishing(3), configuring(4), retrievingNetworkPrefixes(5), registeringNetworkPrefixes(6), retrievingAddresses(7), registeringAddresses(8), verifying(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the state of the ILMI Finite State Machine associated with this interface." REFERENCE "ATM Forum, Integrated Local Management Interface (ILMI) Specification, Version 4.0, af-ilmi-0065.000, September 1996, Appendix 1" ::= { atmInterfaceExtEntry 7 } atmIntfIlmiEstablishConPollIntvl OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time S between successive transmissions of ILMI messages on this interface for the purpose of detecting establishment of ILMI connectivity." REFERENCE "ATM Forum, Integrated Local Management Interface (ILMI) Specification, Version 4.0, af-ilmi-0065.000, September 1996, Section 8.3.1" DEFVAL { 1 } ::= { atmInterfaceExtEntry 8 } atmIntfIlmiCheckConPollIntvl OBJECT-TYPE SYNTAX Integer32 (0..65535) Ly, et al. Standards Track [Page 68] RFC 3606 Supplemental ATM Managed Objects November 2003 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time T between successive transmissions of ILMI messages on this interface for the purpose of detecting loss of ILMI connectivity. The distinguished value zero disables ILMI connectivity procedures on this interface." REFERENCE "ATM Forum, Integrated Local Management Interface (ILMI) Specification, Version 4.0, af-ilmi-0065.000, September 1996, Section 8.3.1" DEFVAL { 5 } ::= { atmInterfaceExtEntry 9 } atmIntfIlmiConPollInactFactor OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The number K of consecutive polls on this interface for which no ILMI response message is received before ILMI connectivity is declared lost." REFERENCE "ATM Forum, Integrated Local Management Interface (ILMI) Specification, Version 4.0, af-ilmi-0065.000, September 1996, Section 8.3.1" DEFVAL { 4 } ::= { atmInterfaceExtEntry 10 } atmIntfIlmiPublicPrivateIndctr OBJECT-TYPE SYNTAX INTEGER { other(1), public(2), private(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies whether this end of the interface is advertised in ILMI as a device of the `public' or `private' type." DEFVAL { private } ::= { atmInterfaceExtEntry 11 } atmInterfaceConfMaxSvpcVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS read-write STATUS current Ly, et al. Standards Track [Page 69] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface is configured to support for allocation to switched virtual path connections." ::= { atmInterfaceExtEntry 12 } atmInterfaceCurrentMaxSvpcVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface may currently allocate to switched virtual path connections. This value is the minimum of atmInterfaceConfMaxSvpcVpi, and the atmInterfaceMaxSvpcVpi of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the maximum VPI that can be allocated to SVPCs on the interface, then the value of this object must equal atmInterfaceConfMaxSvpcVpi. " ::= { atmInterfaceExtEntry 13 } atmInterfaceConfMaxSvccVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface is configured to support for allocation to switched virtual channel connections." ::= { atmInterfaceExtEntry 14 } atmInterfaceCurrentMaxSvccVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface may currently allocate to switched virtual channel connections. This value is the minimum of atmInterfaceConfMaxSvccVpi, and the atmInterfaceConfMaxSvccVpi of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the maximum VPI that can be allocated to SVCCs on the interface, then the value of this object must equal atmInterfaceConfMaxSvccVpi." ::= { atmInterfaceExtEntry 15 } Ly, et al. Standards Track [Page 70] RFC 3606 Supplemental ATM Managed Objects November 2003 atmInterfaceConfMinSvccVci OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum VCI that the signalling stack on the ATM interface is configured to support for allocation to switched virtual channel connections." ::= { atmInterfaceExtEntry 16 } atmInterfaceCurrentMinSvccVci OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum VCI that the signalling stack on the ATM interface may currently allocate to switched virtual channel connections. This value is the maximum of atmInterfaceConfMinSvccVci, and the atmInterfaceConfMinSvccVci of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the minimum VCI that can be allocated to SVCCs on the interface, then the value of this object must equal atmInterfaceConfMinSvccVci." ::= { atmInterfaceExtEntry 17 } atmIntfSigVccRxTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the row in the atmTrafficDescrParamTable used during ILMI auto-configuration to specify the advertised signalling VCC traffic parameters for the receive direction. The traffic descriptor resulting from ILMI auto-configuration of the signalling VCC is indicated in the atmVclTable." ::= { atmInterfaceExtEntry 18 } atmIntfSigVccTxTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the row in the atmTrafficDescrParamTable used during ILMI auto-configuration to specify the advertised signalling VCC traffic parameters for the transmit direction. The traffic descriptor resulting from ILMI auto-configuration of the signalling VCC is indicated in the atmVclTable." ::= { atmInterfaceExtEntry 19 } Ly, et al. Standards Track [Page 71] RFC 3606 Supplemental ATM Managed Objects November 2003 atmIntfPvcFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the operational status of a PVPL or PVCL on this interface has gone down." ::= { atmInterfaceExtEntry 20 } atmIntfCurrentlyFailingPVpls OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of VPLs on this interface for which there is an active row in the atmVplTable having an atmVplConnKind value of `pvc' and an atmVplOperStatus with a value other than `up'." ::= { atmInterfaceExtEntry 21 } atmIntfCurrentlyFailingPVcls OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of VCLs on this interface for which there is an active row in the atmVclTable having an atmVclConnKind value of `pvc' and an atmVclOperStatus with a value other than `up'." ::= { atmInterfaceExtEntry 22 } atmIntfPvcFailuresTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Allows the generation of traps in response to PVCL or PVPL failures on this interface." DEFVAL { false } ::= { atmInterfaceExtEntry 23 } atmIntfPvcNotificationInterval OBJECT-TYPE SYNTAX INTEGER (1..3600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum interval between the sending of atmIntfPvcFailuresTrap notifications for this interface." DEFVAL { 30 } Ly, et al. Standards Track [Page 72] RFC 3606 Supplemental ATM Managed Objects November 2003 ::= { atmInterfaceExtEntry 24 } atmIntfLeafSetupFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of setup failures. For root, this is the number of rejected setup requests and for leaf, this is the number of setup failure received." ::= { atmInterfaceExtEntry 25 } atmIntfLeafSetupRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of setup requests. For root, this includes both incoming setup request and root intiated setup requests." ::= { atmInterfaceExtEntry 26 } -- 15. ATM ILMI Service Registry Table atmIlmiSrvcRegTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmIlmiSrvcRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of all the ATM network services known by this device. The characteristics of these services are made available through the ILMI, using the ILMI general-purpose service registry MIB. These services may be made available to all ATM interfaces (atmIlmiSrvcRegIndex = 0) or to some specific ATM interfaces only (atmIlmiSrvcRegIndex = ATM interface index)." ::= { atm2MIBObjects 15 } atmIlmiSrvcRegEntry OBJECT-TYPE SYNTAX AtmIlmiSrvcRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single service provider that is available to the user-side of an adjacent device through the ILMI. Implementors need to be aware that if the size of the atmIlmiSrvcRegServiceID exceeds 112 sub-identifiers then OIDs of Ly, et al. Standards Track [Page 73] RFC 3606 Supplemental ATM Managed Objects November 2003 column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2, or SNMPv3." INDEX { atmIlmiSrvcRegIndex, atmIlmiSrvcRegServiceID, atmIlmiSrvcRegAddressIndex } ::= { atmIlmiSrvcRegTable 1 } AtmIlmiSrvcRegEntry ::= SEQUENCE { atmIlmiSrvcRegIndex InterfaceIndexOrZero, atmIlmiSrvcRegServiceID OBJECT IDENTIFIER, atmIlmiSrvcRegAddressIndex INTEGER, atmIlmiSrvcRegATMAddress AtmAddr, atmIlmiSrvcRegParm1 OCTET STRING, atmIlmiSrvcRegRowStatus RowStatus } atmIlmiSrvcRegIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM interface where the service defined in this entry can be made available to an ATM device attached to this interface. The value of 0 has a special meaning: when an ATM service is defined in an entry whose atmIlmiSrvcRegIndex is zero, the ATM service is available to ATM devices connected to any ATM interface. (default value(s)). When the user-side of an adjacent device queries the content of the ILMI service registry MIB (using the ILMI protocol), the local network-side responds with the ATM services defined in atmIlmiSrvcRegTable entries, provided that these entries are indexed by: - the corresponding ifIndex value (atmIlmiSrvcRegIndex equal to the ifIndex of the interface to which the adjacent device is connected) - zero (atmIlmiSrvcRegIndex=0)." ::= { atmIlmiSrvcRegEntry 1 } atmIlmiSrvcRegServiceID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is the service identifier which uniquely identifies the Ly, et al. Standards Track [Page 74] RFC 3606 Supplemental ATM Managed Objects November 2003 type of service at the address provided in the table. The object identifiers for the LAN Emulation Configuration Server (LECS) and the ATM Name Server (ANS) are defined in the ATM Forum ILMI Service Registry MIB. The object identifiers for the ATMARP Server, the Multicast Address Resolution Server (MARS), and the NHRP Server (NHS) are defined in RFC 2601, RFC 2602, and RFC 2603, respectively." ::= { atmIlmiSrvcRegEntry 2 } atmIlmiSrvcRegAddressIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer to differentiate multiple rows containing different ATM addresses for the same service on the same interface. This number need NOT be the same as the corresponding ILMI atmfSrvcRegAddressIndex MIB object." ::= { atmIlmiSrvcRegEntry 3 } atmIlmiSrvcRegATMAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "This is the full address of the service. The user-side of the adjacent device may use this address to establish a connection with the service." ::= { atmIlmiSrvcRegEntry 4 } atmIlmiSrvcRegParm1 OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "An octet string used according to the value of atmIlmiSrvcRegServiceID." ::= { atmIlmiSrvcRegEntry 5 } atmIlmiSrvcRegRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create or destroy an entry from this table." ::= { atmIlmiSrvcRegEntry 6 } Ly, et al. Standards Track [Page 75] RFC 3606 Supplemental ATM Managed Objects November 2003 -- 16. ILMI Network Prefix Table atmIlmiNetworkPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmIlmiNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table specifying per-interface network prefix(es) supplied by the network side of the UNI during ILMI address registration. When no network prefixes are specified for a particular interface, one or more network prefixes based on the switch address(es) may be used for ILMI address registration." ::= { atm2MIBObjects 16 } atmIlmiNetworkPrefixEntry OBJECT-TYPE SYNTAX AtmIlmiNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single network prefix supplied by the network side of the UNI during ILMI address registration. Note that the index variable atmIlmiNetPrefixPrefix is a variable- length string, and as such the rule for variable-length strings in section 7.7 of RFC 2578 applies." INDEX { ifIndex, atmIlmiNetPrefixPrefix } ::= { atmIlmiNetworkPrefixTable 1 } AtmIlmiNetworkPrefixEntry ::= SEQUENCE { atmIlmiNetPrefixPrefix AtmIlmiNetworkPrefix, atmIlmiNetPrefixRowStatus RowStatus } atmIlmiNetPrefixPrefix OBJECT-TYPE SYNTAX AtmIlmiNetworkPrefix MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network prefix specified for use in ILMI address registration." ::= { atmIlmiNetworkPrefixEntry 1 } atmIlmiNetPrefixRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Ly, et al. Standards Track [Page 76] RFC 3606 Supplemental ATM Managed Objects November 2003 "Used to create, delete, activate and de-activate network prefixes used in ILMI address registration." ::= { atmIlmiNetworkPrefixEntry 2 } -- 17. ATM Switch Address Table atmSwitchAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSwitchAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one or more ATM endsystem addresses on a per-switch basis. These addresses are used to identify the switch. When no ILMI network prefixes are configured for certain interfaces, network prefixes based on the switch address(es) may be used for ILMI address registration." ::= { atm2MIBObjects 17 } atmSwitchAddressEntry OBJECT-TYPE SYNTAX AtmSwitchAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM Switch Address table." INDEX { atmSwitchAddressIndex } ::= { atmSwitchAddressTable 1 } AtmSwitchAddressEntry ::= SEQUENCE { atmSwitchAddressIndex Integer32, atmSwitchAddressAddress OCTET STRING, atmSwitchAddressRowStatus RowStatus } atmSwitchAddressIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary index used to enumerate the ATM endsystem addresses for this switch." ::= { atmSwitchAddressEntry 1 } atmSwitchAddressAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(13|20)) MAX-ACCESS read-create STATUS current Ly, et al. Standards Track [Page 77] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "An ATM endsystem address or address prefix used to identify this switch. When no ESI or SEL field is specified, the switch may generate the ESI and SEL fields automatically to obtain a complete 20-byte ATM endsystem address." ::= { atmSwitchAddressEntry 2 } atmSwitchAddressRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used to create, delete, activate, and de-activate addresses used to identify this switch." ::= { atmSwitchAddressEntry 3 } -- 18. ATM VP Cross-Connect Extension Table atmVpCrossConnectXTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVpCrossConnectXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per VP Cross-Connect represented in the atmVpCrossConnectTable." ::= { atm2MIBObjects 18 } atmVpCrossConnectXEntry OBJECT-TYPE SYNTAX AtmVpCrossConnectXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular ATM VP Cross-Connect. Each entry provides an two objects that name the Cross-Connect. One is assigned by the Service User and the other by the Service Provider." AUGMENTS { atmVpCrossConnectEntry } ::= { atmVpCrossConnectXTable 1 } AtmVpCrossConnectXEntry ::= SEQUENCE { atmVpCrossConnectUserName SnmpAdminString, atmVpCrossConnectProviderName SnmpAdminString } atmVpCrossConnectUserName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..255)) MAX-ACCESS read-create STATUS current Ly, et al. Standards Track [Page 78] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "This is a service user assigned textual representation of a VPC PVC." ::= { atmVpCrossConnectXEntry 1 } atmVpCrossConnectProviderName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a system supplied textual representation of VPC PVC. It is assigned by the service provider." ::= { atmVpCrossConnectXEntry 2 } -- 19. ATM VC Cross-Connect Extension Table atmVcCrossConnectXTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVcCrossConnectXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per VC Cross-Connect represented in the atmVcCrossConnectTable." ::= { atm2MIBObjects 19 } atmVcCrossConnectXEntry OBJECT-TYPE SYNTAX AtmVcCrossConnectXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular ATM VC Cross-Connect. Each entry provides an two objects that name the Cross-Connect. One is assigned by the Service User and the other by the Service Provider." AUGMENTS { atmVcCrossConnectEntry } ::= { atmVcCrossConnectXTable 1 } AtmVcCrossConnectXEntry ::= SEQUENCE { atmVcCrossConnectUserName SnmpAdminString, atmVcCrossConnectProviderName SnmpAdminString } atmVcCrossConnectUserName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This is a service user assigned textual representation of a VCC Ly, et al. Standards Track [Page 79] RFC 3606 Supplemental ATM Managed Objects November 2003 PVC." ::= { atmVcCrossConnectXEntry 1 } atmVcCrossConnectProviderName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a system supplied textual representation of VCC PVC. It is assigned by the service provider." ::= { atmVcCrossConnectXEntry 2 } -- 20. Currently Failing PVPL Table atmCurrentlyFailingPVplTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmCurrentlyFailingPVplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table indicating all VPLs for which there is an active row in the atmVplTable having an atmVplConnKind value of `pvc' and an atmVplOperStatus with a value other than `up'." ::= { atm2MIBObjects 20 } atmCurrentlyFailingPVplEntry OBJECT-TYPE SYNTAX AtmCurrentlyFailingPVplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a VPL for which the atmVplRowStatus is `active', the atmVplConnKind is `pvc', and the atmVplOperStatus is other than `up'." INDEX { ifIndex, atmVplVpi } ::= { atmCurrentlyFailingPVplTable 1 } AtmCurrentlyFailingPVplEntry ::= SEQUENCE { atmCurrentlyFailingPVplTimeStamp TimeStamp } atmCurrentlyFailingPVplTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which this PVPL began to fail." ::= { atmCurrentlyFailingPVplEntry 1 } Ly, et al. Standards Track [Page 80] RFC 3606 Supplemental ATM Managed Objects November 2003 -- 21. Currently Failing PVCL Table atmCurrentlyFailingPVclTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmCurrentlyFailingPVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table indicating all VCLs for which there is an active row in the atmVclTable having an atmVclConnKind value of `pvc' and an atmVclOperStatus with a value other than `up'." ::= { atm2MIBObjects 21 } atmCurrentlyFailingPVclEntry OBJECT-TYPE SYNTAX AtmCurrentlyFailingPVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a VCL for which the atmVclRowStatus is `active', the atmVclConnKind is `pvc', and the atmVclOperStatus is other than `up'." INDEX { ifIndex, atmVclVpi, atmVclVci } ::= { atmCurrentlyFailingPVclTable 1 } AtmCurrentlyFailingPVclEntry ::= SEQUENCE { atmCurrentlyFailingPVclTimeStamp TimeStamp } atmCurrentlyFailingPVclTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which this PVCL began to fail." ::= { atmCurrentlyFailingPVclEntry 1 } -- ATM PVC Traps atmPvcTraps OBJECT IDENTIFIER ::= { atm2MIBTraps 1 } atmPvcTrapsPrefix OBJECT IDENTIFIER ::= { atmPvcTraps 0 } atmIntfPvcFailuresTrap NOTIFICATION-TYPE OBJECTS { ifIndex, atmIntfPvcFailures, atmIntfCurrentlyFailingPVpls, atmIntfCurrentlyFailingPVcls } STATUS current DESCRIPTION Ly, et al. Standards Track [Page 81] RFC 3606 Supplemental ATM Managed Objects November 2003 "A notification indicating that one or more PVPLs or PVCLs on this interface has failed since the last atmPvcFailuresTrap was sent. If this trap has not been sent for the last atmIntfPvcNotificationInterval, then it will be sent on the next increment of atmIntfPvcFailures." ::= { atmPvcTrapsPrefix 1 } -- Conformance Information atm2MIBConformance OBJECT IDENTIFIER ::= {atm2MIB 3} atm2MIBGroups OBJECT IDENTIFIER ::= {atm2MIBConformance 1} atm2MIBCompliances OBJECT IDENTIFIER ::= {atm2MIBConformance 2} -- Compliance Statements atm2MIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which represent ATM interfaces. The compliance statements are used to determine if a particular group or object applies to hosts, networks/switches, or both. The Common group is defined as applicable to all three." MODULE -- this module MANDATORY-GROUPS { atmCommonGroup } -- Objects in the ATM Switch/Service/Host Group GROUP atmCommonStatsGroup DESCRIPTION "This group is mandatory for systems that are supporting per-VPC or per-VCC counters." OBJECT atmVplLogicalPortDef MIN-ACCESS read-only DESCRIPTION "This object is mandatory for systems support ATM Logical Port interfaces." OBJECT atmIntfSigVccRxTrafficDescrIndex DESCRIPTION "This object is mandatory for systems that support negotiation of signalling VCC traffic parameters through ILMI." OBJECT atmIntfSigVccTxTrafficDescrIndex Ly, et al. Standards Track [Page 82] RFC 3606 Supplemental ATM Managed Objects November 2003 DESCRIPTION "This object is mandatory for systems that support negotiation of signalling VCC traffic parameters through ILMI." OBJECT atmCurrentlyFailingPVplTimeStamp DESCRIPTION "This object is optional." OBJECT atmCurrentlyFailingPVclTimeStamp DESCRIPTION "This object is optional." OBJECT atmIntfLeafSetupFailures DESCRIPTION "This object is optional." OBJECT atmIntfLeafSetupRequests DESCRIPTION "This object is optional." -- Objects in the ATM Switch/Service Group GROUP atmSwitchServcGroup DESCRIPTION "This group is mandatory for a Switch/Service that implements ATM interfaces." OBJECT atmIfRegAddrRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmSvcVpCrossConnectRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)" OBJECT atmSvcVcCrossConnectRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)" Ly, et al. Standards Track [Page 83] RFC 3606 Supplemental ATM Managed Objects November 2003 -- Objects in the ATM Switch/Service Signalling Group GROUP atmSwitchServcSigGroup DESCRIPTION "This group's write access is not required." -- Objects in the ATM Switch/Service Notifications Group GROUP atmSwitchServcNotifGroup DESCRIPTION "This group is optional for systems implementing support for an ATM Switch or an ATM Network Service." -- Objects in the ATM Switch Group GROUP atmSwitchGroup DESCRIPTION "This group is optional for a switch that implements ATM interfaces." -- Objects in the ATM Service Group GROUP atmServcGroup DESCRIPTION "This group is mandatory for systems implementing support for an ATM Network Service." -- Objects in the ATM Host Group GROUP atmHostGroup DESCRIPTION "This group is mandatory for a Host that implements ATM interfaces." OBJECT atmVclAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclAddrRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- ATM Host Sig Descriptor Parameter Group Ly, et al. Standards Track [Page 84] RFC 3606 Supplemental ATM Managed Objects November 2003 GROUP atmHostSigDescrGroup DESCRIPTION "This group is mandatory for a Host that implements ATM interfaces. Write access is not required for this group." ::= { atm2MIBCompliances 1 } -- ********************************************** -- Units of Conformance -- Mandatory for ATM hosts and switch/service providers atmCommonGroup OBJECT-GROUP OBJECTS { atmSigSSCOPConEvents, atmSigSSCOPErrdPdus, atmSigDetectSetupAttempts, atmSigEmitSetupAttempts, atmSigDetectUnavailRoutes, atmSigEmitUnavailRoutes, atmSigDetectUnavailResrcs, atmSigEmitUnavailResrcs, atmSigDetectCldPtyEvents, atmSigEmitCldPtyEvents, atmSigDetectMsgErrors, atmSigEmitMsgErrors, atmSigDetectClgPtyEvents, atmSigEmitClgPtyEvents, atmSigDetectTimerExpireds, atmSigEmitTimerExpireds, atmSigDetectRestarts, atmSigEmitRestarts, atmSigInEstabls, atmSigOutEstabls, atmVplLogicalPortDef, atmVplLogicalPortIndex, atmInterfaceConfMaxSvpcVpi, atmInterfaceCurrentMaxSvpcVpi, atmInterfaceConfMaxSvccVpi, atmInterfaceCurrentMaxSvccVpi, atmInterfaceConfMinSvccVci, atmInterfaceCurrentMinSvccVci, atmIntfSigVccRxTrafficDescrIndex, atmIntfSigVccTxTrafficDescrIndex, atmIntfPvcFailures, atmIntfCurrentlyFailingPVpls, atmIntfCurrentlyFailingPVcls, Ly, et al. Standards Track [Page 85] RFC 3606 Supplemental ATM Managed Objects November 2003 atmIntfPvcNotificationInterval, atmIntfPvcFailuresTrapEnable, atmIntfLeafSetupFailures, atmIntfLeafSetupRequests, atmIntfConfigType, atmIntfActualType, atmIntfConfigSide, atmIntfActualSide, atmIntfIlmiAdminStatus, atmIntfIlmiOperStatus, atmIntfIlmiFsmState, atmIntfIlmiEstablishConPollIntvl, atmIntfIlmiCheckConPollIntvl, atmIntfIlmiConPollInactFactor, atmIntfIlmiPublicPrivateIndctr, atmCurrentlyFailingPVplTimeStamp, atmCurrentlyFailingPVclTimeStamp } STATUS current DESCRIPTION "A collection of objects providing information for a Switch/Service/Host that implements ATM interfaces." ::= { atm2MIBGroups 1 } atmCommonStatsGroup OBJECT-GROUP OBJECTS { atmVclStatTotalCellIns, atmVclStatClp0CellIns, atmVclStatTotalDiscards, atmVclStatClp0Discards, atmVclStatTotalCellOuts, atmVclStatClp0CellOuts, atmVclStatClp0Tagged, atmVplStatTotalCellIns, atmVplStatClp0CellIns, atmVplStatTotalDiscards, atmVplStatClp0Discards, atmVplStatTotalCellOuts, atmVplStatClp0CellOuts, atmVplStatClp0Tagged } STATUS current DESCRIPTION "A collection of objects providing information Ly, et al. Standards Track [Page 86] RFC 3606 Supplemental ATM Managed Objects November 2003 for a Switch/Service/Host that implements ATM VCL and VPL Statistics" ::= { atm2MIBGroups 2 } atmSwitchServcGroup OBJECT-GROUP OBJECTS { atmIlmiSrvcRegATMAddress, atmIlmiSrvcRegParm1, atmIlmiSrvcRegRowStatus, atmIlmiNetPrefixRowStatus, atmSvcVpCrossConnectCreationTime, atmSvcVpCrossConnectRowStatus, atmSvcVcCrossConnectCreationTime, atmSvcVcCrossConnectRowStatus, atmIfRegAddrAddressSource, atmIfRegAddrOrgScope, atmIfRegAddrRowStatus} STATUS current DESCRIPTION "A collection of objects providing information for a Switch/Service that implements ATM interfaces." ::= { atm2MIBGroups 3 } atmSwitchServcSigGroup OBJECT-GROUP OBJECTS { atmSigSupportClgPtyNumDel, atmSigSupportClgPtySubAddr, atmSigSupportCldPtySubAddr, atmSigSupportHiLyrInfo, atmSigSupportLoLyrInfo, atmSigSupportBlliRepeatInd, atmSigSupportAALInfo, atmSigSupportPrefCarrier} STATUS current DESCRIPTION "A collection of objects providing information for a Switch/Service that implements ATM signalling." ::= { atm2MIBGroups 4 } atmSwitchServcNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { atmIntfPvcFailuresTrap } STATUS current DESCRIPTION "A collection of notifications providing information for a Switch/Service that implements ATM interfaces." Ly, et al. Standards Track [Page 87] RFC 3606 Supplemental ATM Managed Objects November 2003 ::= { atm2MIBGroups 5 } atmSwitchGroup OBJECT-GROUP OBJECTS { atmSwitchAddressAddress, atmSwitchAddressRowStatus } STATUS current DESCRIPTION "A collection of objects providing information for an ATM switch." ::= { atm2MIBGroups 6 } atmServcGroup OBJECT-GROUP OBJECTS { atmVpCrossConnectUserName, atmVpCrossConnectProviderName, atmVcCrossConnectUserName, atmVcCrossConnectProviderName } STATUS current DESCRIPTION "A collection of objects providing information for an ATM Network Service." ::= { atm2MIBGroups 7 } atmHostGroup OBJECT-GROUP OBJECTS { atmAal5VclInPkts, atmAal5VclOutPkts, atmAal5VclInOctets, atmAal5VclOutOctets, atmVclAddrType, atmVclAddrRowStatus, atmAddrVclAddrType, atmVclGenSigDescrIndex} STATUS current DESCRIPTION "A collection of objects providing information for a Host that implements ATM interfaces." ::= { atm2MIBGroups 8 } atmHostSigDescrGroup OBJECT-GROUP OBJECTS { atmSigDescrParamAalType, atmSigDescrParamAalSscsType, atmSigDescrParamBhliType, Ly, et al. Standards Track [Page 88] RFC 3606 Supplemental ATM Managed Objects November 2003 atmSigDescrParamBhliInfo, atmSigDescrParamBbcConnConf, atmSigDescrParamBlliLayer2, atmSigDescrParamBlliLayer3, atmSigDescrParamBlliPktSize, atmSigDescrParamBlliSnapId, atmSigDescrParamBlliOuiPid, atmSigDescrParamRowStatus} STATUS current DESCRIPTION "A collection of objects providing information for a Host that implements ATM interfaces." ::= { atm2MIBGroups 9 } END 6. Acknowledgments This document is a product of the AToMMIB Working Group. Special thanks go to Gary Hanson of ADC Telecommunications for his quality contributions to this specification. The authors also like to acknowledge John Flick of HP for his thorough and valuable review of this memo. 7. References 7.1. Normative References [RFC2515] Tesink, K., Ed., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. [ATM Forum 3.0] ATM Forum, "ATM User-Network Interface Specification, Version 3.0 (UNI 3.0)", September 1993. [ATM Forum UNI 3.1] ATM Forum, "ATM User-Network Interface Specification, Version 3.1 (UNI 3.1)", September 1994. [ATM Forum LANE] ATM Forum, "LAN Emulation Client Management Specification, Version 1.0", af-lane-0038.000, September 1995. [RFC1694] Brown, T. and K. Tesink, "Definitions of Managed Objects for SMDS Interfaces using SMIv2", RFC 1694, August 1994. Ly, et al. Standards Track [Page 89] RFC 3606 Supplemental ATM Managed Objects November 2003 [ATM Forum ILMI] ATM Forum, "Integrated Local Management Interface (ILMI) Specification, Version 4.0", [RFC3592] Tesink, K., "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", RFC 3592, September 2003. [RFC2496] Fowler, D., Ed., "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 2496, January 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. 7.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Ly, et al. Standards Track [Page 90] RFC 3606 Supplemental ATM Managed Objects November 2003 Table Sensitivity/vulnerability 1. atmSvcVpCrossConnectTable Deletion of VP cross-connects 2. atmSvcVcCrossConnectTable Deletion of VC cross-connects 3. atmSigStatTable Signalling read-only statistics 4. atmSigSupportTable Signalling configuration params 5. atmSigDescrParamTable Signalling configuration params 6. atmIfRegisteredAddrTable Interface address table 7. atmVclAddrTable VCL/Address mapping table 8. atmAddrVclTable VCL/Address mapping table (read-only) 9. atmVplStatTable VPL statistics (read-only) 10. atmVplLogicalPortTable VPL logical port configuration 11. atmVclStatTable VCL statistics (read-only) 12. atmAal5VclStatTable AAL5 statistics (read-only) 13. atmVclGenTable Signalling configuration 14. atmInterfaceExtTable Interface configuration 15. atmIlmiSrvcRegTable ILMI config params 16. atmIlmiNetworkPrefixTable ILMI config params 17. atmSwitchAddressTable Switch address info 18. atmVpCrossConnectXTable VP cross-connect params 19. atmVcCrossConnectXTable VC cross-connect params 20. atmCurrentlyFailingPVplTable PVPL status info (read-only) 21. atmCurrentlyFailingPVclTable PVCL status info (read-only) Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an Ly, et al. Standards Track [Page 91] RFC 3606 Supplemental ATM Managed Objects November 2003 instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Ly, et al. Standards Track [Page 92] RFC 3606 Supplemental ATM Managed Objects November 2003 10. Authors' Addresses Faye Ly Pedestal Networks 6503 Dumbarton Circle Fremont, CA 94555 USA Phone (510) 896-2908 EMail: faye@pedestalnetworks.com Michael Noto Cisco Systems 170 W. Tasman Drive San Jose, CA 95134-1706 USA EMail: mnoto@cisco.com Andrew Smith Consultant EMail: ah_smith@acm.org Ethan Mickey Spiegel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134-1706 Phone: (408) 526-6408 EMail: mspiegel@cisco.com Kaj Tesink Telcordia Technologies 331 Newman Springs Road Red Bank, NJ 07701-7020 Phone: (732) 758-5254 EMail: kaj@research.telcordia.com Ly, et al. Standards Track [Page 93] RFC 3606 Supplemental ATM Managed Objects November 2003 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ly, et al. Standards Track [Page 94] snmp-mibs-downloader-1.1/mibrfcs/rfc3621.txt0000644000000000000000000011065611402176071015566 0ustar Network Working Group A. Berger Request for Comments: 3621 PowerDsine Inc. Category: Standards Track D. Romascanu Avaya December 2003 Power Ethernet MIB 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. MIB Structure. . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 17 8. Intellectual Property Statement. . . . . . . . . . . . . . . . 17 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 Berger & Romascanu Standards Track [Page 1] RFC 3621 Power Ethernet MIB December 2003 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of MIB objects to manage Power Ethernet [IEEE-802.3af] Power Sourcing Equipment (PSE). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The emergence of IP telephony as an application that allows voice applications to be run over the same infrastructure as data applications has led to the emergence of Ethernet IP phones, which have similar functions and characteristics as traditional phones. Powering the phone with the same cable used for signal transfer is one of the functions that are being taken as granted. The IEEE 802.3 Working Group has initiated standardization on this subject, currently known as the IEEE 802.3af work [IEEE-802.3af]. The IEEE 802.3af WG did not define a full management interface, but only the hardware registers that will allow for management interfaces to be built for a powered Ethernet device. The MIB module defined in this document extends the Ethernet-like Interfaces MIB [RFC3635] with the management objects required for the management of the powered Ethernet devices and ports. Berger & Romascanu Standards Track [Page 2] RFC 3621 Power Ethernet MIB December 2003 The following abbreviations are defined in [IEEE-802.3af] and will be used with the same significance in this document: PSE - Power Sourcing Equipment; PD - Powered Device 4. MIB Structure These MIB objects are categorized into three MIB groups. The pethPsePortTable defines the objects used for configuring and describing the status of ports on a PSE device. Examples of PSE devices are Ethernet switches that support power Ethernet and mid- span boxes. The pethMainPseObjects MIB group defines the management objects for a managed main power source in a PSE device. Ethernet switches are one example of boxes that would support these objects. The pethNotificationControlTable includes objects that control the transmission of notifications from the agent to a management application. 5. Definitions POWER-ETHERNET-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, OBJECT-TYPE, Integer32, Gauge32, Counter32, NOTIFICATION-TYPE FROM SNMPv2-SMI TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; powerEthernetMIB MODULE-IDENTITY LAST-UPDATED "200311240000Z" -- November 24, 2003 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" Berger & Romascanu Standards Track [Page 3] RFC 3621 Power Ethernet MIB December 2003 CONTACT-INFO " WG Charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-requests@ietf.org In Body: subscribe your_email_address Chair: Dan Romascanu Avaya Tel: +972-3-645-8414 Email: dromasca@avaya.com Editor: Avi Berger PowerDsine Inc. Tel: 972-9-7755100 Ext 307 Fax: 972-9-7755120 E-mail: avib@PowerDsine.com " DESCRIPTION "The MIB module for managing Power Source Equipment (PSE) working according to the IEEE 802.af Powered Ethernet (DTE Power via MDI) standard. The following terms are used throughout this MIB module. For complete formal definitions, the IEEE 802.3 standards should be consulted wherever possible: Group - A recommended, but optional, entity defined by the IEEE 802.3 management standard, in order to support a modular numbering scheme. The classical example allows an implementor to represent field-replaceable units as groups of ports, with the port numbering matching the modular hardware implementation. Port - This entity identifies the port within the group for which this entry contains information. The numbering scheme for ports is implementation specific. Copyright (c) The Internet Society (2003). This version of this MIB module is part of RFC 3621; See the RFC itself for full legal notices." Berger & Romascanu Standards Track [Page 4] RFC 3621 Power Ethernet MIB December 2003 REVISION "200311240000Z" -- November 24, 2003 DESCRIPTION "Initial version, published as RFC 3621." ::= { mib-2 105 } pethNotifications OBJECT IDENTIFIER ::= { powerEthernetMIB 0 } pethObjects OBJECT IDENTIFIER ::= { powerEthernetMIB 1 } pethConformance OBJECT IDENTIFIER ::= { powerEthernetMIB 2 } -- PSE Objects pethPsePortTable OBJECT-TYPE SYNTAX SEQUENCE OF PethPsePortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display and control the power characteristics of power Ethernet ports on a Power Source Entity (PSE) device. This group will be implemented in managed power Ethernet switches and mid-span devices. Values of all read-write objects in this table are persistent at restart/reboot." ::= { pethObjects 1 } pethPsePortEntry OBJECT-TYPE SYNTAX PethPsePortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display and control the power characteristics of a power Ethernet PSE port." INDEX { pethPsePortGroupIndex , pethPsePortIndex } ::= { pethPsePortTable 1 } PethPsePortEntry ::= SEQUENCE { pethPsePortGroupIndex Integer32, pethPsePortIndex Integer32, pethPsePortAdminEnable TruthValue, pethPsePortPowerPairsControlAbility TruthValue, pethPsePortPowerPairs INTEGER, pethPsePortDetectionStatus INTEGER, pethPsePortPowerPriority INTEGER, Berger & Romascanu Standards Track [Page 5] RFC 3621 Power Ethernet MIB December 2003 pethPsePortMPSAbsentCounter Counter32, pethPsePortType SnmpAdminString, pethPsePortPowerClassifications INTEGER, pethPsePortInvalidSignatureCounter Counter32, pethPsePortPowerDeniedCounter Counter32, pethPsePortOverLoadCounter Counter32, pethPsePortShortCounter Counter32 } pethPsePortGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the group containing the port to which a power Ethernet PSE is connected. Group means box in the stack, module in a rack and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethMainPseGroupIndex, and pethNotificationControlGroupIndex to refer to a given box in a stack or module in the rack." ::= { pethPsePortEntry 1 } pethPsePortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the power Ethernet PSE port within group pethPsePortGroupIndex to which the power Ethernet PSE entry is connected." ::= { pethPsePortEntry 2 } pethPsePortAdminEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "true (1) An interface which can provide the PSE functions. false(2) The interface will act as it would if it had no PSE function." Berger & Romascanu Standards Track [Page 6] RFC 3621 Power Ethernet MIB December 2003 REFERENCE "IEEE Std 802.3af Section 30.9.1.1.2 aPSEAdminState" ::= { pethPsePortEntry 3 } pethPsePortPowerPairsControlAbility OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the capability of controlling the power pairs functionality to switch pins for sourcing power. The value true indicate that the device has the capability to control the power pairs. When false the PSE Pinout Alternative used cannot be controlled through the PethPsePortAdminEnable attribute." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.3 aPSEPowerPairsControlAbility" ::= { pethPsePortEntry 4 } pethPsePortPowerPairs OBJECT-TYPE SYNTAX INTEGER { signal(1), spare(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Describes or controls the pairs in use. If the value of pethPsePortPowerPairsControl is true, this object is writable. A value of signal(1) means that the signal pairs only are in use. A value of spare(2) means that the spare pairs only are in use." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.4 aPSEPowerPairs" ::= { pethPsePortEntry 5 } pethPsePortDetectionStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), searching(2), deliveringPower(3), fault(4), test(5), otherFault(6) } Berger & Romascanu Standards Track [Page 7] RFC 3621 Power Ethernet MIB December 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the operational status of the port PD detection. A value of disabled(1)- indicates that the PSE State diagram is in the state DISABLED. A value of deliveringPower(3) - indicates that the PSE State diagram is in the state POWER_ON for a duration greater than tlim max (see IEEE Std 802.3af Table 33-5 tlim). A value of fault(4) - indicates that the PSE State diagram is in the state TEST_ERROR. A value of test(5) - indicates that the PSE State diagram is in the state TEST_MODE. A value of otherFault(6) - indicates that the PSE State diagram is in the state IDLE due to the variable error_conditions. A value of searching(2)- indicates the PSE State diagram is in a state other than those listed above." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.5 aPSEPowerDetectionStatus" ::= { pethPsePortEntry 6 } pethPsePortPowerPriority OBJECT-TYPE SYNTAX INTEGER { critical(1), high(2), low(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the priority of the port from the point of view of a power management algorithm. The priority that is set by this variable could be used by a control mechanism that prevents over current situations by disconnecting first ports with lower power priority. Ports that connect devices critical to the operation of the network - like the E911 telephones ports - should be set to higher priority." ::= { pethPsePortEntry 7 } pethPsePortMPSAbsentCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when the PSE state diagram transitions directly from the state POWER_ON to the Berger & Romascanu Standards Track [Page 8] RFC 3621 Power Ethernet MIB December 2003 state IDLE due to tmpdo_timer_done being asserted." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.11 aPSEMPSAbsentCounter" ::= { pethPsePortEntry 8 } pethPsePortType OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "A manager will set the value of this variable to indicate the type of powered device that is connected to the port. The default value supplied by the agent if no value has ever been set should be a zero-length octet string." ::= { pethPsePortEntry 9 } pethPsePortPowerClassifications OBJECT-TYPE SYNTAX INTEGER { class0(1), class1(2), class2(3), class3(4), class4(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Classification is a way to tag different terminals on the Power over LAN network according to their power consumption. Devices such as IP telephones, WLAN access points and others, will be classified according to their power requirements. The meaning of the classification labels is defined in the IEEE specification. This variable is valid only while a PD is being powered, that is, while the attribute pethPsePortDetectionStatus is reporting the enumeration deliveringPower." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.6 aPSEPowerClassification" ::= { pethPsePortEntry 10 } pethPsePortInvalidSignatureCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Berger & Romascanu Standards Track [Page 9] RFC 3621 Power Ethernet MIB December 2003 DESCRIPTION "This counter is incremented when the PSE state diagram enters the state SIGNATURE_INVALID." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.7 aPSEInvalidSignatureCounter" ::= { pethPsePortEntry 11 } pethPsePortPowerDeniedCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when the PSE state diagram enters the state POWER_DENIED." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.8 aPSEPowerDeniedCounter" ::= { pethPsePortEntry 12 } pethPsePortOverLoadCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when the PSE state diagram enters the state ERROR_DELAY_OVER." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.9 aPSEOverLoadCounter" ::= { pethPsePortEntry 13 } pethPsePortShortCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter is incremented when the PSE state diagram enters the state ERROR_DELAY_SHORT." REFERENCE "IEEE Std 802.3af Section 30.9.1.1.10 aPSEShortCounter" ::= { pethPsePortEntry 14 } -- Main PSE Objects pethMainPseObjects OBJECT IDENTIFIER ::= { pethObjects 3 } Berger & Romascanu Standards Track [Page 10] RFC 3621 Power Ethernet MIB December 2003 pethMainPseTable OBJECT-TYPE SYNTAX SEQUENCE OF PethMainPseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display and control attributes of the main power source in a PSE device. Ethernet switches are one example of boxes that would support these objects. Values of all read-write objects in this table are persistent at restart/reboot." ::= { pethMainPseObjects 1 } pethMainPseEntry OBJECT-TYPE SYNTAX PethMainPseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display and control the Main power of a PSE. " INDEX { pethMainPseGroupIndex } ::= { pethMainPseTable 1 } PethMainPseEntry ::= SEQUENCE { pethMainPseGroupIndex Integer32, pethMainPsePower Gauge32 , pethMainPseOperStatus INTEGER, pethMainPseConsumptionPower Gauge32, pethMainPseUsageThreshold Integer32 } pethMainPseGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the group to which power Ethernet PSE is connected. Group means (box in the stack, module in a rack) and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethPsePortGroupIndex, and pethNotificationControlGroupIndex to refer to a given box in a stack or module in a rack." ::= { pethMainPseEntry 1 } Berger & Romascanu Standards Track [Page 11] RFC 3621 Power Ethernet MIB December 2003 pethMainPsePower OBJECT-TYPE SYNTAX Gauge32 (1..65535) UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "The nominal power of the PSE expressed in Watts." ::= { pethMainPseEntry 2 } pethMainPseOperStatus OBJECT-TYPE SYNTAX INTEGER { on(1), off(2), faulty(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the main PSE." ::= { pethMainPseEntry 3 } pethMainPseConsumptionPower OBJECT-TYPE SYNTAX Gauge32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured usage power expressed in Watts." ::= { pethMainPseEntry 4 } pethMainPseUsageThreshold OBJECT-TYPE SYNTAX Integer32 (1..99) UNITS "%" MAX-ACCESS read-write STATUS current DESCRIPTION "The usage threshold expressed in percents for comparing the measured power and initiating an alarm if the threshold is exceeded." ::= { pethMainPseEntry 5 } -- Notification Control Objects pethNotificationControl OBJECT IDENTIFIER ::= { pethObjects 4 } pethNotificationControlTable OBJECT-TYPE SYNTAX SEQUENCE OF PethNotificationControlEntry MAX-ACCESS not-accessible Berger & Romascanu Standards Track [Page 12] RFC 3621 Power Ethernet MIB December 2003 STATUS current DESCRIPTION "A table of objects that display and control the Notification on a PSE device. Values of all read-write objects in this table are persistent at restart/reboot." ::= { pethNotificationControl 1 } pethNotificationControlEntry OBJECT-TYPE SYNTAX PethNotificationControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that control the Notification events." INDEX { pethNotificationControlGroupIndex } ::= { pethNotificationControlTable 1 } PethNotificationControlEntry ::= SEQUENCE { pethNotificationControlGroupIndex Integer32, pethNotificationControlEnable TruthValue } pethNotificationControlGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the group. Group means box in the stack, module in a rack and the value 1 MUST be used for non-modular devices. Furthermore, the same value MUST be used in this variable, pethPsePortGroupIndex, and pethMainPseGroupIndex to refer to a given box in a stack or module in a rack. " ::= { pethNotificationControlEntry 1 } pethNotificationControlEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls, on a per-group basis, whether or not notifications from the agent are enabled. The value true(1) means that notifications are enabled; the value false(2) means that they are not." ::= { pethNotificationControlEntry 2 } Berger & Romascanu Standards Track [Page 13] RFC 3621 Power Ethernet MIB December 2003 -- -- Notifications Section -- -- pethPsePortOnOffNotification NOTIFICATION-TYPE OBJECTS { pethPsePortDetectionStatus } STATUS current DESCRIPTION " This Notification indicates if Pse Port is delivering or not power to the PD. This Notification SHOULD be sent on every status change except in the searching mode. At least 500 msec must elapse between notifications being emitted by the same object instance." ::= { pethNotifications 1 } pethMainPowerUsageOnNotification NOTIFICATION-TYPE OBJECTS { pethMainPseConsumptionPower } STATUS current DESCRIPTION " This Notification indicate PSE Threshold usage indication is on, the usage power is above the threshold. At least 500 msec must elapse between notifications being emitted by the same object instance." ::= { pethNotifications 2 } pethMainPowerUsageOffNotification NOTIFICATION-TYPE OBJECTS { pethMainPseConsumptionPower } STATUS current DESCRIPTION " This Notification indicates PSE Threshold usage indication off, the usage power is below the threshold. At least 500 msec must elapse between notifications being emitted by the same object instance." ::= { pethNotifications 3 } -- -- Conformance Section -- pethCompliances OBJECT IDENTIFIER ::= { pethConformance 1 } pethGroups OBJECT IDENTIFIER ::= { pethConformance 2 } pethCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Power Ethernet MIB." Berger & Romascanu Standards Track [Page 14] RFC 3621 Power Ethernet MIB December 2003 MODULE -- this module MANDATORY-GROUPS { pethPsePortGroup, pethPsePortNotificationGroup, pethNotificationControlGroup } GROUP pethMainPseGroup DESCRIPTION "The pethMainPseGroup is mandatory for PSE systems that implement a main power supply." GROUP pethMainPowerNotificationGroup DESCRIPTION "The pethMainPowerNotificationGroup is mandatory for PSE systems that implement a main power supply." ::= { pethCompliances 1 } pethPsePortGroup OBJECT-GROUP OBJECTS { pethPsePortAdminEnable, pethPsePortPowerPairsControlAbility, pethPsePortPowerPairs, pethPsePortDetectionStatus, pethPsePortPowerPriority, pethPsePortMPSAbsentCounter, pethPsePortInvalidSignatureCounter, pethPsePortPowerDeniedCounter, pethPsePortOverLoadCounter, pethPsePortShortCounter, pethPsePortType, pethPsePortPowerClassifications } STATUS current DESCRIPTION "PSE Port objects." ::= { pethGroups 1 } pethMainPseGroup OBJECT-GROUP OBJECTS { pethMainPsePower, pethMainPseOperStatus, pethMainPseConsumptionPower, pethMainPseUsageThreshold } STATUS current DESCRIPTION "Main PSE Objects. " ::= { pethGroups 2 } pethNotificationControlGroup OBJECT-GROUP Berger & Romascanu Standards Track [Page 15] RFC 3621 Power Ethernet MIB December 2003 OBJECTS { pethNotificationControlEnable } STATUS current DESCRIPTION "Notification Control Objects. " ::= { pethGroups 3 } pethPsePortNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pethPsePortOnOffNotification} STATUS current DESCRIPTION "Pse Port Notifications." ::= { pethGroups 4 } pethMainPowerNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pethMainPowerUsageOnNotification, pethMainPowerUsageOffNotification} STATUS current DESCRIPTION "Main PSE Notifications." ::= { pethGroups 5 } END 6. Acknowledgements This document is the product of the Ethernet Interfaces and Hub MIB WG. The authors would like to recognize the special contributions of C.M. Heard and David Law. 7. References 7.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Berger & Romascanu Standards Track [Page 16] RFC 3621 Power Ethernet MIB December 2003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [IEEE-802.3af] IEEE 802.3 Working Group, "IEEE Std 802.3af-2003 - Data Terminal Equipment (DTE) Power via Media Dependent Interface (MDI)", July 2003. 7.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Berger & Romascanu Standards Track [Page 17] RFC 3621 Power Ethernet MIB December 2003 9. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Setting the following object to incorrect values can result in improper operation of the PSE, including the possibility that the PD does not receive power from the PSE port: pethPsePortAdminEnable pethPsePortPowerPairs pethPsePortPowerPriority pethPsePortType Setting the following objects to incorrect values can result in an excessive number of traps being sent to network management stations: pethMainPseUsageThreshold pethNotificationControlEnable Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. These are: pethPsePortPowerPairsControlAbility pethPsePortPowerPriority pethPsePortPowerClassifications It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Berger & Romascanu Standards Track [Page 18] RFC 3621 Power Ethernet MIB December 2003 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. Authors' Addresses Avi Berger PowerDsine Inc. 1, Hanagar St., P.O. Box 7220 Hod Hasharon 45421, Israel Phone: +972-9-7755100 Ext 307 Fax: +972-9-7755120 EMail: avib@PowerDsine.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Phone: +972-3-645-8414 EMail: dromasca@avaya.com Berger & Romascanu Standards Track [Page 19] RFC 3621 Power Ethernet MIB December 2003 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Berger & Romascanu Standards Track [Page 20] snmp-mibs-downloader-1.1/mibrfcs/rfc3635.txt0000644000000000000000000045555411402176071015604 0ustar Network Working Group J. Flick Request for Comments: 3635 Hewlett-Packard Company Obsoletes: 2665 September 2003 Category: Standards Track Definitions of Managed Objects for the Ethernet-like Interface Types 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Relation to MIB-2. . . . . . . . . . . . . . . . . . . . 4 3.2. Relation to the Interfaces MIB . . . . . . . . . . . . . 4 3.2.1. Layering Model . . . . . . . . . . . . . . . . . 4 3.2.2. Virtual Circuits . . . . . . . . . . . . . . . . 4 3.2.3. ifRcvAddressTable. . . . . . . . . . . . . . . . 5 3.2.4. ifType . . . . . . . . . . . . . . . . . . . . . 5 3.2.5. ifXxxOctets. . . . . . . . . . . . . . . . . . . 5 3.2.6. ifXxxXcastPkts . . . . . . . . . . . . . . . . . 6 3.2.7. ifMtu. . . . . . . . . . . . . . . . . . . . . . 8 3.2.8. ifSpeed and ifHighSpeed. . . . . . . . . . . . . 8 3.2.9. ifPhysAddress. . . . . . . . . . . . . . . . . . 9 3.2.10. Specific Interface MIB Objects. . . . . . . . . 10 3.3. Relation to the 802.3 MAU MIB. . . . . . . . . . . . . . 13 Flick Standards Track [Page 1] RFC 3635 Ethernet-Like MIB September 2003 3.4. dot3StatsEtherChipSet. . . . . . . . . . . . . . . . . . 13 3.5. Mapping of IEEE 802.3 Managed Objects. . . . . . . . . . 14 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Intellectual Property Statement. . . . . . . . . . . . . . . . 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 7. Normative References . . . . . . . . . . . . . . . . . . . . . 57 8. Informative References . . . . . . . . . . . . . . . . . . . . 58 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 59 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 60 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.1. Changes since RFC 2665 . . . . . . . . . . . . . . . . . 61 A.2. Changes between RFC 2358 and RFC 2665 . . . . . . . . . 62 A.3. Changes between RFC 1650 and RFC 2358. . . . . . . . . . 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 63 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .64 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo also includes a MIB module. This MIB module updates the list of managed objects specified in the earlier version of this MIB, module, RFC 2665 [RFC2665]. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Flick Standards Track [Page 2] RFC 3635 Ethernet-Like MIB September 2003 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview Instances of these object types represent attributes of an interface to an ethernet-like communications medium. At present, ethernet-like media are identified by the value ethernetCsmacd(6) of the ifType object in the Interfaces MIB [RFC2863]. Some older implementations may return the values iso88023Csmacd(7) or starLan(11) for ifType for ethernet-like media. The definitions presented here are based on Section 30, "10 Mb/s, 100 Mb/s 1000 Mb/s and 10 Gb/s Management", and Annex 30A, "GDMO Specification for 802.3 managed object classes" of IEEE Std. 802.3, 2002 Edition [IEEE802.3], amended by IEEE Std. 802.3ae-2002 [IEEE802.3ae], as originally interpreted by Frank Kastenholz, then of Interlan in [KASTEN]. Implementors of these MIB objects should note that IEEE Std. 802.3 [IEEE802.3] explicitly describes (in the form of Pascal pseudocode) when, where, and how various MAC attributes are measured. The IEEE document also describes the effects of MAC actions that may be invoked by manipulating instances of the MIB objects defined here. To the extent that some of the attributes defined in [IEEE802.3] are represented by previously defined objects in MIB-2 [RFC1213] or in the Interfaces MIB [RFC2863], such attributes are not redundantly represented by objects defined in this memo. Among the attributes represented by objects defined in other memos are the number of octets transmitted or received on a particular interface, the number of frames transmitted or received on a particular interface, the promiscuous status of an interface, the MAC address of an interface, and multicast information associated with an interface. Flick Standards Track [Page 3] RFC 3635 Ethernet-Like MIB September 2003 3.1. Relation to MIB-2 This section applies only when this MIB is used in conjunction with the "old" [RFC1213] interface group. The relationship between an ethernet-like interface and an interface in the context of MIB-2 is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein. For agents which implement the (now deprecated) ifSpecific object, an instance of that object that is associated with an ethernet-like interface has the OBJECT IDENTIFIER value: dot3 OBJECT IDENTIFIER ::= { transmission 7 } 3.2. Relation to the Interfaces MIB The Interface MIB [RFC2863] requires that any MIB which is an adjunct of the Interface MIB clarify specific areas within the Interface MIB. These areas were intentionally left vague in the Interface MIB to avoid over constraining the MIB, thereby precluding management of certain media-types. Section 4 of [RFC2863] enumerates several areas which a media-specific MIB must clarify. Each of these areas is addressed in a following subsection. The implementor is referred to [RFC2863] in order to understand the general intent of these areas. 3.2.1. Layering Model Ordinarily, there are no sublayers for an ethernet-like interface. However there may be implementation-specific requirements which require the use of sublayers. One example is the use of 802.3 link aggregation. In this case, Annex 30C of [IEEE802.3] describes the layering model and the use of the ifStackTable for representing aggregated links. Another example is the use of the 802.3 WAN Interface Sublayer. In this case, The 802.3 WIS MIB [RFC3637] describes the layering model and the use of the ifStackTable for representing the WAN sublayer. 3.2.2. Virtual Circuits This medium does not support virtual circuits and this area is not applicable to this MIB. Flick Standards Track [Page 4] RFC 3635 Ethernet-Like MIB September 2003 3.2.3. ifRcvAddressTable This table contains all IEEE 802.3 addresses, unicast, multicast, and broadcast, for which this interface will receive packets and forward them up to a higher layer entity for local consumption. The format of the address, contained in ifRcvAddressAddress, is the same as for ifPhysAddress. In the event that the interface is part of a MAC bridge, this table does not include unicast addresses which are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filtering mechanism. 3.2.4. ifType This MIB applies to interfaces which have the ifType value ethernetCsmacd(6). It is REQUIRED that all ethernet-like interfaces use an ifType of ethernetCsmacd(6) regardless of the speed that the interface is running or the link-layer encapsulation in use. Use of the ifType values iso88023Csmacd(7) and starLan(11) are deprecated, however some older implementations may return these values. Management applications should be prepared to receive these deprecated ifType values from older implementations. There are three other interface types defined in the IANAifType-MIB for Ethernet. They are fastEther(62), fastEtherFX(69), and gigabitEthernet(117). These interface types were registered by individual vendors, not by any IETF working group. A requirement for compliance with this document is that all ethernet-like interfaces MUST return ethernetCsmacd(6) for ifType, and MUST NOT return fastEther(62), fastEtherFX(69), or gigabitEthernet(117). However, as there are fielded implementations that do return these obsolete ifType values, management applications SHOULD be prepared to receive them from older implementations. Information on the particular flavor of Ethernet that an interface is running is available from ifSpeed in the Interfaces MIB, and ifMauType in the 802.3 MAU MIB [RFC3636]. Note that implementation of the 802.3 MAU MIB [RFC3636] is REQUIRED for all ethernet-like interfaces. 3.2.5. ifXxxOctets The Interface MIB octet counters, ifInOctets, ifOutOctets, ifHCInOctets and ifHCOutOctets, MUST include all octets in valid frames sent or received on the interface, including the MAC header and FCS, but not the preamble, start of frame delimiter, or extension octets. This corresponds to the definition of frameSize/8 in section Flick Standards Track [Page 5] RFC 3635 Ethernet-Like MIB September 2003 4.2.7.1 of [IEEE802.3] (frameSize is defined in bits rather than octets, and is defined as 2 x addressSize + lengthOrTypeSize + dataSize + crcSize). They do not include the number of octets in collided or failed transmit attempts, since the MAC layer driver typically does not have visibility to count these octets. They also do not include octets in received invalid frames, since this information is normally not passed to the MAC layer, and since non-promiscuous MAC implementations cannot reliably determine whether an invalid frame was actually addressed to this station. Note that these counters do include octets in valid MAC control frames sent or received on the interface, as well as octets in otherwise valid received MAC frames that are discarded by the MAC layer for some reason (insufficient buffer space, unknown protocol, etc.). Note that the octet counters in IF-MIB do not exactly match the definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK and aOctetsReceivedOK count only the octets in the clientData and Pad fields, whereas ifInOctets and ifOutOctets include the entire MAC frame, including MAC header and FCS. However, the IF-MIB counters can be derived from the IEEE 802.3 counters as follows: ifInOctets = aOctetsReceivedOK + (18 * aFramesReceivedOK) ifOutOctets = aOctetsTransmittedOK + (18 * aFramesTransmittedOK) Another difference to keep in mind between the IF-MIB counters and IEEE 802.3 counters is that in the IEEE 802.3 document, the frame counters and octet counters are always incremented together. aOctetsTransmittedOK counts the number of octets in frames that were counted by aFramesTransmittedOK. aOctetsReceivedOK counts the number of octets in frames that were counted by aFramesReceivedOK. This is not the case with the IF-MIB counters. The IF-MIB octet counters count the number of octets sent to or received from the layer below this interface, whereas the packet counters count the number of packets sent to or received from the layer above. Therefore, received MAC Control frames, ifInDiscards, and ifInUnknownProtos are counted by ifInOctets, but not ifInXcastPkts. Transmitted MAC Control frames are counted by ifOutOctets, but not ifOutXcastPkts. ifOutDiscards and ifOutErrors are counted by ifOutXcastPkts, but not ifOutOctets. 3.2.6. ifXxxXcastPkts The packet counters in the IF-MIB do not exactly match the definition of the frame counters in IEEE 802.3. aFramesTransmittedOK counts the number of frames successfully transmitted on the interface, whereas ifOutUcastPkts, ifOutMulticastPkts and ifOutBroadcastPkts count the Flick Standards Track [Page 6] RFC 3635 Ethernet-Like MIB September 2003 number of transmit requests made from a higher layer, whether or not the transmit attempt was successful. This means that packets counted by ifOutErrors or ifOutDiscards are also counted by ifOutXcastPkts, but are not counted by aFramesTransmittedOK. This also means that, since MAC Control frames are generated by a sublayer internal to the interface layer rather than by a higher layer, they are not counted by ifOutXcastPkts, but are counted by aFramesTransmittedOK. Roughly: aFramesTransmittedOK = ifOutUcastPkts + ifOutMulticastPkts + ifOutBroadcastPkts + dot3OutPauseFrames - (ifOutErrors + ifOutDiscards) Similarly, aFramesReceivedOK counts the number of frames received successfully by the interface, whether or not they are passed to a higher layer, whereas ifInUcastPkts, ifInMulticastPkts and ifInBroadcastPkts count only the number of packets passed to a higher layer. This means that packets counted by ifInDiscards or ifInUnknownProtos are also counted by aFramesReceivedOK, but are not counted by ifInXcastPkts. This also means that, since MAC Control frames are consumed by a sublayer internal to the interface layer and not passed to a higher layer, they are not counted by ifInXcastPkts, but are counted by aFramesReceivedOK. Roughly: aFramesReceivedOK = ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts + dot3InPauseFrames + ifInDiscards + ifInUnknownProtos This specification chooses to treat MAC control frames as being originated and consumed within the interface and not counted by the IF-MIB packet counters. MAC control frames are normally sent as multicast packets. In many network environments, MAC control frames can greatly outnumber multicast frames carrying actual data. If MAC control frames were included in the ifInMulticastPkts and ifOutMulticastPkts, the count of data-carrying multicast packets would tend to be drowned out by the count of MAC control frames, rendering those counters considerably less useful. To better understand the issues surrounding the mapping of the IF-MIB packet and octet counters to an Ethernet interface, it is useful to refer to a Case Diagram [CASE] for the IF-MIB counters, with modifications to show the proper interpretation for the Ethernet interface layer. Flick Standards Track [Page 7] RFC 3635 Ethernet-Like MIB September 2003 layer above -------------------------------------------------------------------- ifInUcastPkts+ ^ | ifOutUcastPkts+ ifInBroadcastPkts+ ----|---- ----|---- ifOutBroadcastPkts+ ifInMulticastPkts | | ifOutMulticastPkts | | dot3InPauseFrames <---| |<--- dot3OutPauseFrames | | ifInDiscards <---| | | | ifInUnknownProtos <---| |---> ifOutDiscards | | ifInOctets ----|---- ----|---- ifOutOctets | | ifInErrors <---| |---> ifOutErrors | V -------------------------------------------------------------------- layer below 3.2.7. ifMtu The defined standard MTU for ethernet-like interfaces is 1500 octets. However, many implementations today support larger packet sizes than the IEEE 802.3 standard. The value of this object MUST reflect the actual MTU in use on the interface, whether it matches the standard MTU or not. This value should reflect the value seen by the MAC client interface. When a higher layer protocol, like IP, is running over Ethernet framing, this is the MTU that will be seen by that higher layer protocol. However, most ethernet-like interfaces today run multiple protocols that use a mix of different framing types. For example, an IEEE 802.2 LLC type 1 client protocol will see an MTU of 1497 octets on an interface using the IEEE standard maximum packet size, and a protocol running over SNAP will see an MTU of 1492 octets on an interface using the IEEE standard maximum packet size. However, since specification mandates using the MTU as seen at the MAC client interface, the value of ifMtu would be reported as 1500 octets in these cases. 3.2.8. ifSpeed and ifHighSpeed For ethernet-like interfaces operating at 1000 Megabits per second (Mb/s) or less, ifSpeed will represent the current operational speed of the interface in bits per second. For current interface types, this will be equal to 1,000,000 (1 million), 10,000,000 (10 million), 100,000,000 (100 million), or 1,000,000,000 (1 billion). ifHighSpeed will represent the current operational speed in millions of bits per Flick Standards Track [Page 8] RFC 3635 Ethernet-Like MIB September 2003 second. For current ethernet-like interfaces, this will be equal to 1, 10, 100, or 1,000. If the interface implements auto-negotiation, auto-negotiation is enabled for this interface, and the interface has not yet negotiated to an operational speed, these objects SHOULD reflect the maximum speed supported by the interface. For ethernet-like interfaces operating at greater than 1000 Mb/s, ifHighSpeed will represent the current operational speed of the interface in millions of bits per second. Note that for WAN implementations, this will be the payload data rate over the WAN interface sublayer. For current implementations, this will be equal to 10,000 for LAN implementations of 10 Gb/s, and 9,294 for WAN implementations of the 10 Gb/s MAC over an OC-192 PHY. For these speeds, ifSpeed should report a maximum unsigned 32-bit value of 4,294,967,295 as specified in [RFC2863]. Note that these object MUST NOT indicate a doubled value when operating in full-duplex mode. It MUST indicate the correct line speed regardless of the current duplex mode. The duplex mode of the interface may be determined by examining either the dot3StatsDuplexStatus object in this MIB module, or the ifMauType object in the 802.3 MAU MIB [RFC3636]. 3.2.9. ifPhysAddress This object contains the IEEE 802.3 address which is placed in the source-address field of any Ethernet, Starlan, or IEEE 802.3 frames that originate at this interface. Usually this will be kept in ROM on the interface hardware. Some systems may set this address via software. In a system where there are several such addresses the designer has a tougher choice. The address chosen should be the one most likely to be of use to network management (e.g. the address placed in ARP responses for systems which are primarily IP systems). If the designer truly can not chose, use of the factory-provided ROM address is suggested. If the address can not be determined, an octet string of zero length should be returned. The address is stored in binary in this object. The address is stored in "canonical" bit order, that is, the Group Bit is positioned as the low-order bit of the first octet. Thus, the first byte of a multicast address would have the bit 0x01 set. Flick Standards Track [Page 9] RFC 3635 Ethernet-Like MIB September 2003 3.2.10. Specific Interface MIB Objects The following table provides specific implementation guidelines for applying the interface group objects to ethernet-like media. Object Guidelines ifIndex Each ethernet-like interface is represented by an ifEntry. The dot3StatsTable in this MIB module is indexed by dot3StatsIndex. The interface identified by a particular value of dot3StatsIndex is the same interface as identified by the same value of ifIndex. ifDescr Refer to [RFC2863]. ifType Refer to section 3.2.4. ifMtu Refer to section 3.2.7. ifSpeed Refer to section 3.2.8. ifPhysAddress Refer to section 3.2.9. ifAdminStatus Write access is not required. Support for 'testing' is not required. ifOperStatus The operational state of the interface. Support for 'testing' is not required. The value 'dormant' has no meaning for an ethernet-like interface. ifLastChange Refer to [RFC2863]. ifInOctets The number of octets in valid MAC frames received on this interface, including the MAC header and FCS. This does include the number of octets in valid MAC Control frames received on this interface. See section 3.2.5. ifInUcastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are consumed by the interface layer and are not passed to any higher layer protocol. See section 3.2.6. Flick Standards Track [Page 10] RFC 3635 Ethernet-Like MIB September 2003 ifInDiscards Refer to [RFC2863]. ifInErrors The sum for this interface of dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsFrameTooLongs, and dot3StatsInternalMacReceiveErrors. ifInUnknownProtos Refer to [RFC2863]. ifOutOctets The number of octets transmitted in valid MAC frames on this interface, including the MAC header and FCS. This does include the number of octets in valid MAC Control frames transmitted on this interface. See section 3.2.5. ifOutUcastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are generated by the interface layer, and are not passed from any higher layer protocol. See section 3.2.6. ifOutDiscards Refer to [RFC2863]. ifOutErrors The sum for this interface of: dot3StatsSQETestErrors, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsInternalMacTransmitErrors and dot3StatsCarrierSenseErrors. ifName Locally-significant textual name for the interface (e.g. lan0). ifInMulticastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are consumed by the interface layer and are not passed to any higher layer protocol. See section 3.2.6. Flick Standards Track [Page 11] RFC 3635 Ethernet-Like MIB September 2003 ifInBroadcastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are consumed by the interface layer, and are not passed to any higher layer protocol. See section 3.2.6. ifOutMulticastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are generated by the interface layer, and are not passed from any higher layer protocol. See section 3.2.6. ifOutBroadcastPkts Refer to [RFC2863]. Note that this does not include MAC Control frames, since MAC Control frames are generated by the interface layer, and are not passed from any higher layer protocol. See section 3.2.6. ifHCInOctets 64-bit versions of counters. Required ifHCOutOctets for ethernet-like interfaces that are capable of operating at 20 Mb/s or faster, even if the interface is currently operating at less than 20 Mb/s. ifHCInUcastPkts 64-bit versions of packet counters. ifHCInMulticastPkts Required for ethernet-like interfaces ifHCInBroadcastPkts that are capable of operating at ifHCOutUcastPkts 640 Mb/s or faster, even if the ifHCOutMulticastPkts interface is currently operating at ifHCOutBroadcastPkts less than 640 Mb/s. ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is 'enabled' ifHighSpeed Refer to section 3.2.8. ifPromiscuousMode Refer to [RFC2863]. ifConnectorPresent This will normally be 'true'. It will be 'false' in the case where this interface uses the WAN Interface Sublayer. See [RFC3637] for details. ifAlias Refer to [RFC2863]. Flick Standards Track [Page 12] RFC 3635 Ethernet-Like MIB September 2003 ifCounterDiscontinuityTime Refer to [RFC2863]. Note that a discontinuity in the Interface MIB counters may also indicate a discontinuity in some or all of the counters in this MIB that are associated with that interface. ifStackHigherLayer Refer to section 3.2.1. ifStackLowerLayer ifStackStatus ifRcvAddressAddress Refer to section 3.2.3. ifRcvAddressStatus ifRcvAddressType 3.3. Relation to the 802.3 MAU MIB Support for the mauModIfCompl3 compliance statement of the MAU-MIB [RFC3636] is REQUIRED for Ethernet-like interfaces. This MIB is needed in order to allow applications to determine the current MAU type in use by the interface, and to control autonegotiation and duplex mode for the interface. Implementing this MIB module without implementing the MAU-MIB would leave applications with no standard way to determine the media type in use, and no standard way to control the duplex mode of the interface. 3.4. dot3StatsEtherChipSet This document defines an object called dot3StatsEtherChipSet, which is used to identify the MAC hardware used to communicate on an interface. Previous versions of this document contained a number of OID assignments for some existing Ethernet chipsets. Maintaining that list as part of this document has proven to be problematic, so the OID assignments contained in previous versions of this document have now been moved to a separate document [RFC2666]. The dot3StatsEtherChipSet object has now been deprecated. Implementation feedback indicates that this object is much more useful in theory than in practice. The object's utility in debugging network problems in the field appears to be limited. In those cases where it may be useful, it is not sufficient, since it identifies only the MAC chip, and not the PHY, PMD, or driver. The administrative overhead involved in maintaining a central registry of chipset OIDs cannot be justified for an object whose usefulness is questionable at best. Flick Standards Track [Page 13] RFC 3635 Ethernet-Like MIB September 2003 Implementations which continue to support this object for the purpose of backwards compatibility may continue to use the values defined in [RFC2666]. For chipsets not listed in [RFC2666], implementors that wish to support this object and return a valid OBJECT IDENTIFIER value may assign OBJECT IDENTIFIERS within that part of the registration tree delegated to individual enterprises. 3.5. Mapping of IEEE 802.3 Managed Objects IEEE 802.3 Managed Object Corresponding SNMP Object oMacEntity .aMACID dot3StatsIndex or IF-MIB - ifIndex .aFramesTransmittedOK IF-MIB - ifOutUCastPkts + ifOutMulticastPkts + ifOutBroadcastPkts* .aSingleCollisionFrames dot3StatsSingleCollisionFrames .aMultipleCollisionFrames dot3StatsMultipleCollisionFrames .aFramesReceivedOK IF-MIB - ifInUcastPkts + ifInMulticastPkts + ifInBroadcastPkts* .aFrameCheckSequenceErrors dot3StatsFCSErrors .aAlignmentErrors dot3StatsAlignmentErrors .aOctetsTransmittedOK IF-MIB - ifOutOctets* .aFramesWithDeferredXmissions dot3StatsDeferredTransmissions .aLateCollisions dot3StatsLateCollisions .aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions .aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors .aCarrierSenseErrors dot3StatsCarrierSenseErrors .aOctetsReceivedOK IF-MIB - ifInOctets* .aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors .aPromiscuousStatus IF-MIB - ifPromiscuousMode .aReadMulticastAddressList IF-MIB - ifRcvAddressTable .aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts* .aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts* .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts* .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts* .aFrameTooLongErrors dot3StatsFrameTooLongs .aReadWriteMACAddress IF-MIB - ifPhysAddress .aCollisionFrames dot3CollFrequencies .aDuplexStatus dot3StatsDuplexStatus .aRateControlAbility dot3StatsRateControlAbility .aRateControlStatus dot3StatsRateControlStatus .acAddGroupAddress IF-MIB - ifRcvAddressTable .acDeleteGroupAddress IF-MIB - ifRcvAddressTable .acExecuteSelfTest dot3TestLoopBack Flick Standards Track [Page 14] RFC 3635 Ethernet-Like MIB September 2003 oPHYEntity .aPHYID dot3StatsIndex or IF-MIB - ifIndex .aSQETestErrors dot3StatsSQETestErrors .aSymbolErrorDuringCarrier dot3StatsSymbolErrors oMACControlEntity .aMACControlID dot3StatsIndex or IF-MIB - ifIndex .aMACControlFunctionsSupported dot3ControlFunctionsSupported and dot3ControlFunctionsEnabled .aUnsupportedOpcodesReceived dot3ControlInUnknownOpcodes oPAUSEEntity .aPAUSEMACCtrlFramesTransmitted dot3OutPauseFrames .aPAUSEMACCtrlFramesReceived dot3InPauseFrames * Note that the octet counters in IF-MIB do not exactly match the definition of the octet counters in IEEE 802.3. See section 3.2.5 for details. Also note that the packet counters in the IF-MIB do not exactly match the definition of the frame counters in IEEE 802.3. See section 3.2.6 for details. The following IEEE 802.3 managed objects have been removed from this MIB module as a result of implementation feedback: oMacEntity .aFramesWithExcessiveDeferral .aInRangeLengthErrors .aOutOfRangeLengthField .aMACEnableStatus .aTransmitEnableStatus .aMulticastReceiveStatus .acInitializeMAC Please see [RFC1369] for the detailed reasoning on why these objects were removed. In addition, the following IEEE 802.3 managed objects have not been included in this MIB for the following reasons. Flick Standards Track [Page 15] RFC 3635 Ethernet-Like MIB September 2003 IEEE 802.3 Managed Object Disposition oMACEntity .aMACCapabilities Can be derived from MAU-MIB - ifMauTypeListBits .aStretchRatio Implementation constant. oPHYEntity .aPhyType Can be derived from MAU-MIB - ifMauType .aPhyTypeList Can be derived from MAU-MIB - ifMauTypeListBits .aMIIDetect Not considered useful. .aPhyAdminState Can already obtain interface state from IF-MIB - ifAdminStatus and MAU state from MAU-MIB - ifMauStatus. Providing an additional state for the PHY was not considered useful. .acPhyAdminControl Can already control interface state from IF-MIB - ifAdminStatus and MAU state from MAU-MIB - ifMauStatus. Providing separate admin control of the PHY was not considered useful. oMACControlEntity .aMACControlFramesTransmitted Can be determined by summing the OutFrames counters for the individual control functions .aMACControlFramesReceived Can be determined by summing the InFrames counters for the individual control functions oPAUSEEntity .aPAUSELinkDelayAllowance Not considered useful. Flick Standards Track [Page 16] RFC 3635 Ethernet-Like MIB September 2003 4. Definitions EtherLike-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Integer32, Counter32, Counter64, mib-2, transmission FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TruthValue FROM SNMPv2-TC ifIndex, InterfaceIndex FROM IF-MIB; etherMIB MODULE-IDENTITY LAST-UPDATED "200309190000Z" -- September 19, 2003 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG E-mail: hubmib@ietf.org To subscribe: hubmib-request@ietf.org Chair: Dan Romascanu Postal: Avaya Inc. Atidum Technology Park, Bldg. 3 Tel Aviv 61131 Israel Tel: +972 3 645 8414 E-mail: dromasca@avaya.com Editor: John Flick Postal: Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557 USA Tel: +1 916 785 4018 Fax: +1 916 785 1199 E-mail: johnf@rose.hp.com" DESCRIPTION "The MIB module to describe generic objects for ethernet-like network interfaces. The following reference is used throughout this MIB module: [IEEE 802.3 Std] refers to: IEEE Std 802.3, 2002 Edition: 'IEEE Standard Flick Standards Track [Page 17] RFC 3635 Ethernet-Like MIB September 2003 for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications', as amended by IEEE Std 802.3ae-2002: 'Amendment: Media Access Control (MAC) Parameters, Physical Layer, and Management Parameters for 10 Gb/s Operation', August, 2002. Of particular interest is Clause 30, '10 Mb/s, 100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC 3635; see the RFC itself for full legal notices." REVISION "200309190000Z" -- September 19, 2003 DESCRIPTION "Updated to include support for 10 Gb/sec interfaces. This resulted in the following revisions: - Updated dot3StatsAlignmentErrors and dot3StatsSymbolErrors DESCRIPTIONs to reflect behaviour at 10 Gb/s - Added dot3StatsRateControlAbility and dot3RateControlStatus for management of the Rate Control function in 10 Gb/s WAN applications - Added 64-bit versions of all counters that are used on high-speed ethernet interfaces - Added object groups to contain the new objects - Deprecated etherStatsBaseGroup and split into etherStatsBaseGroup2 and etherStatsHalfDuplexGroup, so that interfaces which can only operate at full-duplex do not need to implement half-duplex-only statistics - Deprecated dot3Compliance and replaced it with dot3Compliance2, which includes the compliance information for the new object groups Flick Standards Track [Page 18] RFC 3635 Ethernet-Like MIB September 2003 In addition, the dot3Tests and dot3Errors object identities have been deprecated, since there is no longer a standard method for using them. This version published as RFC 3635." REVISION "199908240400Z" -- August 24, 1999 DESCRIPTION "Updated to include support for 1000 Mb/sec interfaces and full-duplex interfaces. This version published as RFC 2665." REVISION "199806032150Z" -- June 3, 1998 DESCRIPTION "Updated to include support for 100 Mb/sec interfaces. This version published as RFC 2358." REVISION "199402030400Z" -- February 3, 1994 DESCRIPTION "Initial version, published as RFC 1650." ::= { mib-2 35 } etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 } dot3 OBJECT IDENTIFIER ::= { transmission 7 } -- the Ethernet-like Statistics group dot3StatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for a collection of ethernet-like interfaces attached to a particular system. There will be one row in this table for each ethernet-like interface in the system." ::= { dot3 2 } dot3StatsEntry OBJECT-TYPE SYNTAX Dot3StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics for a particular interface to an ethernet-like medium." INDEX { dot3StatsIndex } ::= { dot3StatsTable 1 } Dot3StatsEntry ::= SEQUENCE { Flick Standards Track [Page 19] RFC 3635 Ethernet-Like MIB September 2003 dot3StatsIndex InterfaceIndex, dot3StatsAlignmentErrors Counter32, dot3StatsFCSErrors Counter32, dot3StatsSingleCollisionFrames Counter32, dot3StatsMultipleCollisionFrames Counter32, dot3StatsSQETestErrors Counter32, dot3StatsDeferredTransmissions Counter32, dot3StatsLateCollisions Counter32, dot3StatsExcessiveCollisions Counter32, dot3StatsInternalMacTransmitErrors Counter32, dot3StatsCarrierSenseErrors Counter32, dot3StatsFrameTooLongs Counter32, dot3StatsInternalMacReceiveErrors Counter32, dot3StatsEtherChipSet OBJECT IDENTIFIER, dot3StatsSymbolErrors Counter32, dot3StatsDuplexStatus INTEGER, dot3StatsRateControlAbility TruthValue, dot3StatsRateControlStatus INTEGER } dot3StatsIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "An index value that uniquely identifies an interface to an ethernet-like medium. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." REFERENCE "RFC 2863, ifIndex" ::= { dot3StatsEntry 1 } dot3StatsAlignmentErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received on a particular interface that are not an integral number of octets in length and do not pass the FCS check. The count represented by an instance of this object is incremented when the alignmentError status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions pertain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according Flick Standards Track [Page 20] RFC 3635 Ethernet-Like MIB September 2003 to the error status presented to the LLC. This counter does not increment for group encoding schemes greater than 4 bits per group. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCStatsAlignmentErrors object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.7, aAlignmentErrors" ::= { dot3StatsEntry 2 } dot3StatsFCSErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received on a particular interface that are an integral number of octets in length but do not pass the FCS check. This count does not include frames received with frame-too-long or frame-too-short error. The count represented by an instance of this object is incremented when the frameCheckError status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions pertain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC. Note: Coding errors detected by the physical layer for speeds above 10 Mb/s will cause the frame to fail the FCS check. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if Flick Standards Track [Page 21] RFC 3635 Ethernet-Like MIB September 2003 it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCStatsFCSErrors object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.6, aFrameCheckSequenceErrors." ::= { dot3StatsEntry 3 } dot3StatsSingleCollisionFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames that are involved in a single collision, and are subsequently transmitted successfully. A frame that is counted by an instance of this object is also counted by the corresponding instance of either the ifOutUcastPkts, ifOutMulticastPkts, or ifOutBroadcastPkts, and is not counted by the corresponding instance of the dot3StatsMultipleCollisionFrames object. This counter does not increment when the interface is operating in full-duplex mode. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.3, aSingleCollisionFrames." ::= { dot3StatsEntry 4 } dot3StatsMultipleCollisionFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames that are involved in more Flick Standards Track [Page 22] RFC 3635 Ethernet-Like MIB September 2003 than one collision and are subsequently transmitted successfully. A frame that is counted by an instance of this object is also counted by the corresponding instance of either the ifOutUcastPkts, ifOutMulticastPkts, or ifOutBroadcastPkts, and is not counted by the corresponding instance of the dot3StatsSingleCollisionFrames object. This counter does not increment when the interface is operating in full-duplex mode. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.4, aMultipleCollisionFrames." ::= { dot3StatsEntry 5 } dot3StatsSQETestErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of times that the SQE TEST ERROR is received on a particular interface. The SQE TEST ERROR is set in accordance with the rules for verification of the SQE detection mechanism in the PLS Carrier Sense Function as described in IEEE Std. 802.3, 2000 Edition, section 7.2.4.6. This counter does not increment on interfaces operating at speeds greater than 10 Mb/s, or on interfaces operating in full-duplex mode. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 7.2.4.6, also 30.3.2.1.4, aSQETestErrors." ::= { dot3StatsEntry 6 } dot3StatsDeferredTransmissions OBJECT-TYPE SYNTAX Counter32 Flick Standards Track [Page 23] RFC 3635 Ethernet-Like MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames for which the first transmission attempt on a particular interface is delayed because the medium is busy. The count represented by an instance of this object does not include frames involved in collisions. This counter does not increment when the interface is operating in full-duplex mode. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.9, aFramesWithDeferredXmissions." ::= { dot3StatsEntry 7 } dot3StatsLateCollisions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a collision is detected on a particular interface later than one slotTime into the transmission of a packet. A (late) collision included in a count represented by an instance of this object is also considered as a (generic) collision for purposes of other collision-related statistics. This counter does not increment when the interface is operating in full-duplex mode. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.10, aLateCollisions." ::= { dot3StatsEntry 8 } dot3StatsExcessiveCollisions OBJECT-TYPE SYNTAX Counter32 Flick Standards Track [Page 24] RFC 3635 Ethernet-Like MIB September 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames for which transmission on a particular interface fails due to excessive collisions. This counter does not increment when the interface is operating in full-duplex mode. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.11, aFramesAbortedDueToXSColls." ::= { dot3StatsEntry 9 } dot3StatsInternalMacTransmitErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames for which transmission on a particular interface fails due to an internal MAC sublayer transmit error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsLateCollisions object, the dot3StatsExcessiveCollisions object, or the dot3StatsCarrierSenseErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of transmission errors on a particular interface that are not otherwise counted. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCStatsInternalMacTransmitErrors object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can Flick Standards Track [Page 25] RFC 3635 Ethernet-Like MIB September 2003 occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.12, aFramesLostDueToIntMACXmitError." ::= { dot3StatsEntry 10 } dot3StatsCarrierSenseErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the carrier sense condition was lost or never asserted when attempting to transmit a frame on a particular interface. The count represented by an instance of this object is incremented at most once per transmission attempt, even if the carrier sense condition fluctuates during a transmission attempt. This counter does not increment when the interface is operating in full-duplex mode. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.13, aCarrierSenseErrors." ::= { dot3StatsEntry 11 } -- { dot3StatsEntry 12 } is not assigned dot3StatsFrameTooLongs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received on a particular interface that exceed the maximum permitted frame size. The count represented by an instance of this object is incremented when the frameTooLong status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions pertain are, Flick Standards Track [Page 26] RFC 3635 Ethernet-Like MIB September 2003 according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC. For interfaces operating at 10 Gb/s, this counter can roll over in less than 80 minutes if it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCStatsFrameTooLongs object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.25, aFrameTooLongErrors." ::= { dot3StatsEntry 13 } -- { dot3StatsEntry 14 } is not assigned -- { dot3StatsEntry 15 } is not assigned dot3StatsInternalMacReceiveErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsFrameTooLongs object, the dot3StatsAlignmentErrors object, or the dot3StatsFCSErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of receive errors on a particular interface that are not otherwise counted. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if Flick Standards Track [Page 27] RFC 3635 Ethernet-Like MIB September 2003 it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCStatsInternalMacReceiveErrors object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.15, aFramesLostDueToIntMACRcvError." ::= { dot3StatsEntry 16 } dot3StatsEtherChipSet OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS deprecated DESCRIPTION "******** THIS OBJECT IS DEPRECATED ******** This object contains an OBJECT IDENTIFIER which identifies the chipset used to realize the interface. Ethernet-like interfaces are typically built out of several different chips. The MIB implementor is presented with a decision of which chip to identify via this object. The implementor should identify the chip which is usually called the Medium Access Control chip. If no such chip is easily identifiable, the implementor should identify the chip which actually gathers the transmit and receive statistics and error indications. This would allow a manager station to correlate the statistics and the chip generating them, giving it the ability to take into account any known anomalies in the chip. This object has been deprecated. Implementation feedback indicates that it is of limited use for debugging network problems in the field, and the administrative overhead involved in maintaining a registry of chipset OIDs is not justified." Flick Standards Track [Page 28] RFC 3635 Ethernet-Like MIB September 2003 ::= { dot3StatsEntry 17 } dot3StatsSymbolErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For an interface operating at 100 Mb/s, the number of times there was an invalid data symbol when a valid carrier was present. For an interface operating in half-duplex mode at 1000 Mb/s, the number of times the receiving media is non-idle (a carrier event) for a period of time equal to or greater than slotTime, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Data reception error' or 'carrier extend error' on the GMII. For an interface operating in full-duplex mode at 1000 Mb/s, the number of times the receiving media is non-idle (a carrier event) for a period of time equal to or greater than minFrameSize, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Data reception error' on the GMII. For an interface operating at 10 Gb/s, the number of times the receiving media is non-idle (a carrier event) for a period of time equal to or greater than minFrameSize, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Receive Error' on the XGMII. The count represented by an instance of this object is incremented at most once per carrier event, even if multiple symbol errors occur during the carrier event. This count does not increment if a collision is present. This counter does not increment when the interface is operating at 10 Mb/s. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if it is incrementing at its maximum rate. Since that amount of time could be less than a Flick Standards Track [Page 29] RFC 3635 Ethernet-Like MIB September 2003 management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCStatsSymbolErrors object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.2.1.5, aSymbolErrorDuringCarrier." ::= { dot3StatsEntry 18 } dot3StatsDuplexStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), halfDuplex(2), fullDuplex(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current mode of operation of the MAC entity. 'unknown' indicates that the current duplex mode could not be determined. Management control of the duplex mode is accomplished through the MAU MIB. When an interface does not support autonegotiation, or when autonegotiation is not enabled, the duplex mode is controlled using ifMauDefaultType. When autonegotiation is supported and enabled, duplex mode is controlled using ifMauAutoNegAdvertisedBits. In either case, the currently operating duplex mode is reflected both in this object and in ifMauType. Note that this object provides redundant information with ifMauType. Normally, redundant objects are discouraged. However, in this instance, it allows a management application to determine the duplex status of an interface without having to know every possible value of ifMauType. This was felt to be sufficiently valuable to justify the redundancy." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.32, aDuplexStatus." ::= { dot3StatsEntry 19 } Flick Standards Track [Page 30] RFC 3635 Ethernet-Like MIB September 2003 dot3StatsRateControlAbility OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "'true' for interfaces operating at speeds above 1000 Mb/s that support Rate Control through lowering the average data rate of the MAC sublayer, with frame granularity, and 'false' otherwise." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.33, aRateControlAbility." ::= { dot3StatsEntry 20 } dot3StatsRateControlStatus OBJECT-TYPE SYNTAX INTEGER { rateControlOff(1), rateControlOn(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current Rate Control mode of operation of the MAC sublayer of this interface." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.34, aRateControlStatus." ::= { dot3StatsEntry 21 } -- the Ethernet-like Collision Statistics group -- Implementation of this group is optional; it is appropriate -- for all systems which have the necessary metering dot3CollTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3CollEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of collision histograms for a particular set of interfaces." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.30, aCollisionFrames." ::= { dot3 5 } dot3CollEntry OBJECT-TYPE SYNTAX Dot3CollEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A cell in the histogram of per-frame collisions for a particular interface. An Flick Standards Track [Page 31] RFC 3635 Ethernet-Like MIB September 2003 instance of this object represents the frequency of individual MAC frames for which the transmission (successful or otherwise) on a particular interface is accompanied by a particular number of media collisions." INDEX { ifIndex, dot3CollCount } ::= { dot3CollTable 1 } Dot3CollEntry ::= SEQUENCE { dot3CollCount Integer32, dot3CollFrequencies Counter32 } -- { dot3CollEntry 1 } is no longer in use dot3CollCount OBJECT-TYPE SYNTAX Integer32 (1..16) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of per-frame media collisions for which a particular collision histogram cell represents the frequency on a particular interface." ::= { dot3CollEntry 2 } dot3CollFrequencies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of individual MAC frames for which the transmission (successful or otherwise) on a particular interface occurs after the frame has experienced exactly the number of collisions in the associated dot3CollCount object. For example, a frame which is transmitted on interface 77 after experiencing exactly 4 collisions would be indicated by incrementing only dot3CollFrequencies.77.4. No other instance of dot3CollFrequencies would be incremented in this example. This counter does not increment when the interface is operating in full-duplex mode. Discontinuities in the value of this counter can Flick Standards Track [Page 32] RFC 3635 Ethernet-Like MIB September 2003 occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { dot3CollEntry 3 } dot3ControlTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of descriptive and status information about the MAC Control sublayer on the ethernet-like interfaces attached to a particular system. There will be one row in this table for each ethernet-like interface in the system which implements the MAC Control sublayer. If some, but not all, of the ethernet-like interfaces in the system implement the MAC Control sublayer, there will be fewer rows in this table than in the dot3StatsTable." ::= { dot3 9 } dot3ControlEntry OBJECT-TYPE SYNTAX Dot3ControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about the MAC Control sublayer on a single ethernet-like interface." INDEX { dot3StatsIndex } ::= { dot3ControlTable 1 } Dot3ControlEntry ::= SEQUENCE { dot3ControlFunctionsSupported BITS, dot3ControlInUnknownOpcodes Counter32, dot3HCControlInUnknownOpcodes Counter64 } dot3ControlFunctionsSupported OBJECT-TYPE SYNTAX BITS { pause(0) -- 802.3 flow control } MAX-ACCESS read-only STATUS current DESCRIPTION "A list of the possible MAC Control functions implemented for this interface." REFERENCE "[IEEE 802.3 Std.], 30.3.3.2, aMACControlFunctionsSupported." Flick Standards Track [Page 33] RFC 3635 Ethernet-Like MIB September 2003 ::= { dot3ControlEntry 1 } dot3ControlInUnknownOpcodes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of MAC Control frames received on this interface that contain an opcode that is not supported by this device. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCControlInUnknownOpcodes object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.3.5, aUnsupportedOpcodesReceived" ::= { dot3ControlEntry 2 } dot3HCControlInUnknownOpcodes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of MAC Control frames received on this interface that contain an opcode that is not supported by this device. This counter is a 64 bit version of dot3ControlInUnknownOpcodes. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.3.5, aUnsupportedOpcodesReceived" ::= { dot3ControlEntry 3 } Flick Standards Track [Page 34] RFC 3635 Ethernet-Like MIB September 2003 dot3PauseTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3PauseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of descriptive and status information about the MAC Control PAUSE function on the ethernet-like interfaces attached to a particular system. There will be one row in this table for each ethernet-like interface in the system which supports the MAC Control PAUSE function (i.e., the 'pause' bit in the corresponding instance of dot3ControlFunctionsSupported is set). If some, but not all, of the ethernet-like interfaces in the system implement the MAC Control PAUSE function (for example, if some interfaces only support half-duplex), there will be fewer rows in this table than in the dot3StatsTable." ::= { dot3 10 } dot3PauseEntry OBJECT-TYPE SYNTAX Dot3PauseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about the MAC Control PAUSE function on a single ethernet-like interface." INDEX { dot3StatsIndex } ::= { dot3PauseTable 1 } Dot3PauseEntry ::= SEQUENCE { dot3PauseAdminMode INTEGER, dot3PauseOperMode INTEGER, dot3InPauseFrames Counter32, dot3OutPauseFrames Counter32, dot3HCInPauseFrames Counter64, dot3HCOutPauseFrames Counter64 } dot3PauseAdminMode OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabledXmit(2), enabledRcv(3), enabledXmitAndRcv(4) } Flick Standards Track [Page 35] RFC 3635 Ethernet-Like MIB September 2003 MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to configure the default administrative PAUSE mode for this interface. This object represents the administratively-configured PAUSE mode for this interface. If auto-negotiation is not enabled or is not implemented for the active MAU attached to this interface, the value of this object determines the operational PAUSE mode of the interface whenever it is operating in full-duplex mode. In this case, a set to this object will force the interface into the specified mode. If auto-negotiation is implemented and enabled for the MAU attached to this interface, the PAUSE mode for this interface is determined by auto-negotiation, and the value of this object denotes the mode to which the interface will automatically revert if/when auto-negotiation is later disabled. Note that when auto-negotiation is running, administrative control of the PAUSE mode may be accomplished using the ifMauAutoNegCapAdvertisedBits object in the MAU-MIB. Note that the value of this object is ignored when the interface is not operating in full-duplex mode. An attempt to set this object to 'enabledXmit(2)' or 'enabledRcv(3)' will fail on interfaces that do not support operation at greater than 100 Mb/s." ::= { dot3PauseEntry 1 } dot3PauseOperMode OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabledXmit(2), enabledRcv(3), enabledXmitAndRcv(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the PAUSE mode currently Flick Standards Track [Page 36] RFC 3635 Ethernet-Like MIB September 2003 in use on this interface, as determined by either (1) the result of the auto-negotiation function or (2) if auto-negotiation is not enabled or is not implemented for the active MAU attached to this interface, by the value of dot3PauseAdminMode. Interfaces operating at 100 Mb/s or less will never return 'enabledXmit(2)' or 'enabledRcv(3)'. Interfaces operating in half-duplex mode will always return 'disabled(1)'. Interfaces on which auto-negotiation is enabled but not yet completed should return the value 'disabled(1)'." ::= { dot3PauseEntry 2 } dot3InPauseFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of MAC Control frames received on this interface with an opcode indicating the PAUSE operation. This counter does not increment when the interface is operating in half-duplex mode. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCInPauseFrames object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.4.3, aPAUSEMACCtrlFramesReceived." ::= { dot3PauseEntry 3 } dot3OutPauseFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Flick Standards Track [Page 37] RFC 3635 Ethernet-Like MIB September 2003 DESCRIPTION "A count of MAC Control frames transmitted on this interface with an opcode indicating the PAUSE operation. This counter does not increment when the interface is operating in half-duplex mode. For interfaces operating at 10 Gb/s, this counter can roll over in less than 5 minutes if it is incrementing at its maximum rate. Since that amount of time could be less than a management station's poll cycle time, in order to avoid a loss of information, a management station is advised to poll the dot3HCOutPauseFrames object for 10 Gb/s or faster interfaces. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.4.2, aPAUSEMACCtrlFramesTransmitted." ::= { dot3PauseEntry 4 } dot3HCInPauseFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of MAC Control frames received on this interface with an opcode indicating the PAUSE operation. This counter does not increment when the interface is operating in half-duplex mode. This counter is a 64 bit version of dot3InPauseFrames. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.4.3, aPAUSEMACCtrlFramesReceived." ::= { dot3PauseEntry 5 } Flick Standards Track [Page 38] RFC 3635 Ethernet-Like MIB September 2003 dot3HCOutPauseFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of MAC Control frames transmitted on this interface with an opcode indicating the PAUSE operation. This counter does not increment when the interface is operating in half-duplex mode. This counter is a 64 bit version of dot3OutPauseFrames. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.4.2, aPAUSEMACCtrlFramesTransmitted." ::= { dot3PauseEntry 6 } dot3HCStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3HCStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing 64-bit versions of error counters from the dot3StatsTable. The 32-bit versions of these counters may roll over quite quickly on higher speed ethernet interfaces. The counters that have 64-bit versions in this table are the counters that apply to full-duplex interfaces, since 10 Gb/s and faster ethernet-like interfaces do not support half-duplex, and very few 1000 Mb/s ethernet-like interfaces support half-duplex. Entries in this table are recommended for interfaces capable of operating at 1000 Mb/s or faster, and are required for interfaces capable of operating at 10 Gb/s or faster. Lower speed ethernet-like interfaces do not need entries in this table, in which case there may be fewer entries in this table than in the dot3StatsTable. However, implementations containing interfaces with a mix of speeds may choose to implement entries in this table for Flick Standards Track [Page 39] RFC 3635 Ethernet-Like MIB September 2003 all ethernet-like interfaces." ::= { dot3 11 } dot3HCStatsEntry OBJECT-TYPE SYNTAX Dot3HCStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing 64-bit statistics for a single ethernet-like interface." INDEX { dot3StatsIndex } ::= { dot3HCStatsTable 1 } Dot3HCStatsEntry ::= SEQUENCE { dot3HCStatsAlignmentErrors Counter64, dot3HCStatsFCSErrors Counter64, dot3HCStatsInternalMacTransmitErrors Counter64, dot3HCStatsFrameTooLongs Counter64, dot3HCStatsInternalMacReceiveErrors Counter64, dot3HCStatsSymbolErrors Counter64 } dot3HCStatsAlignmentErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received on a particular interface that are not an integral number of octets in length and do not pass the FCS check. The count represented by an instance of this object is incremented when the alignmentError status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions pertain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC. This counter does not increment for group encoding schemes greater than 4 bits per group. This counter is a 64 bit version of dot3StatsAlignmentErrors. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management Flick Standards Track [Page 40] RFC 3635 Ethernet-Like MIB September 2003 system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.7, aAlignmentErrors" ::= { dot3HCStatsEntry 1 } dot3HCStatsFCSErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received on a particular interface that are an integral number of octets in length but do not pass the FCS check. This count does not include frames received with frame-too-long or frame-too-short error. The count represented by an instance of this object is incremented when the frameCheckError status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions pertain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC. Note: Coding errors detected by the physical layer for speeds above 10 Mb/s will cause the frame to fail the FCS check. This counter is a 64 bit version of dot3StatsFCSErrors. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.6, aFrameCheckSequenceErrors." ::= { dot3HCStatsEntry 2 } dot3HCStatsInternalMacTransmitErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames for which transmission on a particular interface fails due to an internal MAC sublayer transmit error. A frame is only Flick Standards Track [Page 41] RFC 3635 Ethernet-Like MIB September 2003 counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsLateCollisions object, the dot3StatsExcessiveCollisions object, or the dot3StatsCarrierSenseErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of transmission errors on a particular interface that are not otherwise counted. This counter is a 64 bit version of dot3StatsInternalMacTransmitErrors. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.12, aFramesLostDueToIntMACXmitError." ::= { dot3HCStatsEntry 3 } dot3HCStatsFrameTooLongs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received on a particular interface that exceed the maximum permitted frame size. The count represented by an instance of this object is incremented when the frameTooLong status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions pertain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC. This counter is a 64 bit version of dot3StatsFrameTooLongs. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can Flick Standards Track [Page 42] RFC 3635 Ethernet-Like MIB September 2003 occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.25, aFrameTooLongErrors." ::= { dot3HCStatsEntry 4 } dot3HCStatsInternalMacReceiveErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the dot3StatsFrameTooLongs object, the dot3StatsAlignmentErrors object, or the dot3StatsFCSErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of receive errors on a particular interface that are not otherwise counted. This counter is a 64 bit version of dot3StatsInternalMacReceiveErrors. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.15, aFramesLostDueToIntMACRcvError." ::= { dot3HCStatsEntry 5 } dot3HCStatsSymbolErrors OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "For an interface operating at 100 Mb/s, the number of times there was an invalid data symbol when a valid carrier was present. Flick Standards Track [Page 43] RFC 3635 Ethernet-Like MIB September 2003 For an interface operating in half-duplex mode at 1000 Mb/s, the number of times the receiving media is non-idle (a carrier event) for a period of time equal to or greater than slotTime, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Data reception error' or 'carrier extend error' on the GMII. For an interface operating in full-duplex mode at 1000 Mb/s, the number of times the receiving media is non-idle (a carrier event) for a period of time equal to or greater than minFrameSize, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Data reception error' on the GMII. For an interface operating at 10 Gb/s, the number of times the receiving media is non-idle (a carrier event) for a period of time equal to or greater than minFrameSize, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Receive Error' on the XGMII. The count represented by an instance of this object is incremented at most once per carrier event, even if multiple symbol errors occur during the carrier event. This count does not increment if a collision is present. This counter is a 64 bit version of dot3StatsSymbolErrors. It should be used on interfaces operating at 10 Gb/s or faster. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE 802.3 Std.], 30.3.2.1.5, aSymbolErrorDuringCarrier." ::= { dot3HCStatsEntry 6 } -- 802.3 Tests dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } Flick Standards Track [Page 44] RFC 3635 Ethernet-Like MIB September 2003 dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } -- TDR Test dot3TestTdr OBJECT-IDENTITY STATUS deprecated DESCRIPTION "******** THIS IDENTITY IS DEPRECATED ******* The Time-Domain Reflectometry (TDR) test is specific to ethernet-like interfaces of type 10Base5 and 10Base2. The TDR value may be useful in determining the approximate distance to a cable fault. It is advisable to repeat this test to check for a consistent resulting TDR value, to verify that there is a fault. A TDR test returns as its result the time interval, measured in 10 MHz ticks or 100 nsec units, between the start of TDR test transmission and the subsequent detection of a collision or deassertion of carrier. On successful completion of a TDR test, the result is stored as the value of an appropriate instance of an appropriate vendor specific MIB object, and the OBJECT IDENTIFIER of that instance is stored in the appropriate instance of the appropriate test result code object (thereby indicating where the result has been stored). This object identity has been deprecated, since the ifTestTable in the IF-MIB was deprecated, and there is no longer a standard mechanism for initiating an interface test. This left no standard way of using this object identity." ::= { dot3Tests 1 } -- Loopback Test dot3TestLoopBack OBJECT-IDENTITY STATUS deprecated DESCRIPTION "******** THIS IDENTITY IS DEPRECATED ******* This test configures the MAC chip and executes an internal loopback test of memory, data paths, and the MAC chip logic. This loopback test can only be executed if the interface is offline. Once the test has completed, the MAC chip should Flick Standards Track [Page 45] RFC 3635 Ethernet-Like MIB September 2003 be reinitialized for network operation, but it should remain offline. If an error occurs during a test, the appropriate test result object will be set to indicate a failure. The two OBJECT IDENTIFIER values dot3ErrorInitError and dot3ErrorLoopbackError may be used to provided more information as values for an appropriate test result code object. This object identity has been deprecated, since the ifTestTable in the IF-MIB was deprecated, and there is no longer a standard mechanism for initiating an interface test. This left no standard way of using this object identity." ::= { dot3Tests 2 } dot3ErrorInitError OBJECT-IDENTITY STATUS deprecated DESCRIPTION "******** THIS IDENTITY IS DEPRECATED ******* Couldn't initialize MAC chip for test. This object identity has been deprecated, since the ifTestTable in the IF-MIB was deprecated, and there is no longer a standard mechanism for initiating an interface test. This left no standard way of using this object identity." ::= { dot3Errors 1 } dot3ErrorLoopbackError OBJECT-IDENTITY STATUS deprecated DESCRIPTION "******** THIS IDENTITY IS DEPRECATED ******* Expected data not received (or not received correctly) in loopback test. This object identity has been deprecated, since the ifTestTable in the IF-MIB was deprecated, and there is no longer a standard mechanism for initiating an interface test. This left no standard way of using this object identity." ::= { dot3Errors 2 } -- { dot3 8 }, the dot3ChipSets tree, is defined in [RFC2666] -- conformance information Flick Standards Track [Page 46] RFC 3635 Ethernet-Like MIB September 2003 etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 } etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 } -- compliance statements etherCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** The compliance statement for managed network entities which have ethernet-like network interfaces. This compliance is deprecated and replaced by dot3Compliance." MODULE -- this module MANDATORY-GROUPS { etherStatsGroup } GROUP etherCollisionTableGroup DESCRIPTION "This group is optional. It is appropriate for all systems which have the necessary metering. Implementation in such systems is highly recommended." ::= { etherCompliances 1 } ether100MbsCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** The compliance statement for managed network entities which have 100 Mb/sec ethernet-like network interfaces. This compliance is deprecated and replaced by dot3Compliance." MODULE -- this module MANDATORY-GROUPS { etherStats100MbsGroup } GROUP etherCollisionTableGroup DESCRIPTION "This group is optional. It is appropriate for all systems which have the necessary metering. Implementation in such systems is highly recommended." ::= { etherCompliances 2 } Flick Standards Track [Page 47] RFC 3635 Ethernet-Like MIB September 2003 dot3Compliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** The compliance statement for managed network entities which have ethernet-like network interfaces. This compliance is deprecated and replaced by dot3Compliance2." MODULE -- this module MANDATORY-GROUPS { etherStatsBaseGroup } GROUP etherDuplexGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating in full-duplex mode. It is highly recommended for all ethernet-like network interfaces." GROUP etherStatsLowSpeedGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating at 10 Mb/s or slower in half-duplex mode." GROUP etherStatsHighSpeedGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating at 100 Mb/s or faster." GROUP etherControlGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces that support the MAC Control sublayer." GROUP etherControlPauseGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces that support the MAC Control PAUSE function." GROUP etherCollisionTableGroup DESCRIPTION "This group is optional. It is appropriate for all ethernet-like network interfaces which are capable of operating in half-duplex mode and have the necessary metering. Implementation in systems with Flick Standards Track [Page 48] RFC 3635 Ethernet-Like MIB September 2003 such interfaces is highly recommended." ::= { etherCompliances 3 } dot3Compliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for managed network entities which have ethernet-like network interfaces. Note that compliance with this MIB module requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB (RFC2863). In addition, compliance with this MIB module requires compliance with the mauModIfCompl3 MODULE-COMPLIANCE statement of the MAU-MIB (RFC3636)." MODULE -- this module MANDATORY-GROUPS { etherStatsBaseGroup2 } GROUP etherDuplexGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating in full-duplex mode. It is highly recommended for all ethernet-like network interfaces." GROUP etherRateControlGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating at speeds faster than 1000 Mb/s. It is highly recommended for all ethernet-like network interfaces." GROUP etherStatsLowSpeedGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating at 10 Mb/s or slower in half-duplex mode." GROUP etherStatsHighSpeedGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating at 100 Mb/s or faster." GROUP etherStatsHalfDuplexGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are Flick Standards Track [Page 49] RFC 3635 Ethernet-Like MIB September 2003 capable of operating in half-duplex mode." GROUP etherHCStatsGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces which are capable of operating at 10 Gb/s or faster. It is recommended for all ethernet-like network interfaces which are capable of operating at 1000 Mb/s or faster." GROUP etherControlGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces that support the MAC Control sublayer." GROUP etherHCControlGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces that support the MAC Control sublayer and are capable of operating at 10 Gb/s or faster." GROUP etherControlPauseGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces that support the MAC Control PAUSE function." GROUP etherHCControlPauseGroup DESCRIPTION "This group is mandatory for all ethernet-like network interfaces that support the MAC Control PAUSE function and are capable of operating at 10 Gb/s or faster." GROUP etherCollisionTableGroup DESCRIPTION "This group is optional. It is appropriate for all ethernet-like network interfaces which are capable of operating in half-duplex mode and have the necessary metering. Implementation in systems with such interfaces is highly recommended." ::= { etherCompliances 4 } -- units of conformance etherStatsGroup OBJECT-GROUP OBJECTS { dot3StatsIndex, dot3StatsAlignmentErrors, dot3StatsFCSErrors, Flick Standards Track [Page 50] RFC 3635 Ethernet-Like MIB September 2003 dot3StatsSingleCollisionFrames, dot3StatsMultipleCollisionFrames, dot3StatsSQETestErrors, dot3StatsDeferredTransmissions, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsInternalMacTransmitErrors, dot3StatsCarrierSenseErrors, dot3StatsFrameTooLongs, dot3StatsInternalMacReceiveErrors, dot3StatsEtherChipSet } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** A collection of objects providing information applicable to all ethernet-like network interfaces. This object group has been deprecated and replaced by etherStatsBaseGroup and etherStatsLowSpeedGroup." ::= { etherGroups 1 } etherCollisionTableGroup OBJECT-GROUP OBJECTS { dot3CollFrequencies } STATUS current DESCRIPTION "A collection of objects providing a histogram of packets successfully transmitted after experiencing exactly N collisions." ::= { etherGroups 2 } etherStats100MbsGroup OBJECT-GROUP OBJECTS { dot3StatsIndex, dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsSingleCollisionFrames, dot3StatsMultipleCollisionFrames, dot3StatsDeferredTransmissions, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsInternalMacTransmitErrors, dot3StatsCarrierSenseErrors, dot3StatsFrameTooLongs, dot3StatsInternalMacReceiveErrors, dot3StatsEtherChipSet, dot3StatsSymbolErrors Flick Standards Track [Page 51] RFC 3635 Ethernet-Like MIB September 2003 } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** A collection of objects providing information applicable to 100 Mb/sec ethernet-like network interfaces. This object group has been deprecated and replaced by etherStatsBaseGroup and etherStatsHighSpeedGroup." ::= { etherGroups 3 } etherStatsBaseGroup OBJECT-GROUP OBJECTS { dot3StatsIndex, dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsSingleCollisionFrames, dot3StatsMultipleCollisionFrames, dot3StatsDeferredTransmissions, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsInternalMacTransmitErrors, dot3StatsCarrierSenseErrors, dot3StatsFrameTooLongs, dot3StatsInternalMacReceiveErrors } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** A collection of objects providing information applicable to all ethernet-like network interfaces. This object group has been deprecated and replaced by etherStatsBaseGroup2 and etherStatsHalfDuplexGroup, to separate objects which must be implemented by all ethernet-like network interfaces from objects that need only be implemented on ethernet-like network interfaces that are capable of half-duplex operation." ::= { etherGroups 4 } etherStatsLowSpeedGroup OBJECT-GROUP OBJECTS { dot3StatsSQETestErrors } STATUS current DESCRIPTION "A collection of objects providing information Flick Standards Track [Page 52] RFC 3635 Ethernet-Like MIB September 2003 applicable to ethernet-like network interfaces capable of operating at 10 Mb/s or slower in half-duplex mode." ::= { etherGroups 5 } etherStatsHighSpeedGroup OBJECT-GROUP OBJECTS { dot3StatsSymbolErrors } STATUS current DESCRIPTION "A collection of objects providing information applicable to ethernet-like network interfaces capable of operating at 100 Mb/s or faster." ::= { etherGroups 6 } etherDuplexGroup OBJECT-GROUP OBJECTS { dot3StatsDuplexStatus } STATUS current DESCRIPTION "A collection of objects providing information about the duplex mode of an ethernet-like network interface." ::= { etherGroups 7 } etherControlGroup OBJECT-GROUP OBJECTS { dot3ControlFunctionsSupported, dot3ControlInUnknownOpcodes } STATUS current DESCRIPTION "A collection of objects providing information about the MAC Control sublayer on ethernet-like network interfaces." ::= { etherGroups 8 } etherControlPauseGroup OBJECT-GROUP OBJECTS { dot3PauseAdminMode, dot3PauseOperMode, dot3InPauseFrames, dot3OutPauseFrames } STATUS current DESCRIPTION "A collection of objects providing information about and control of the MAC Control PAUSE function on ethernet-like network interfaces." ::= { etherGroups 9 } etherStatsBaseGroup2 OBJECT-GROUP OBJECTS { dot3StatsIndex, dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsInternalMacTransmitErrors, Flick Standards Track [Page 53] RFC 3635 Ethernet-Like MIB September 2003 dot3StatsFrameTooLongs, dot3StatsInternalMacReceiveErrors } STATUS current DESCRIPTION "A collection of objects providing information applicable to all ethernet-like network interfaces." ::= { etherGroups 10 } etherStatsHalfDuplexGroup OBJECT-GROUP OBJECTS { dot3StatsSingleCollisionFrames, dot3StatsMultipleCollisionFrames, dot3StatsDeferredTransmissions, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsCarrierSenseErrors } STATUS current DESCRIPTION "A collection of objects providing information applicable only to half-duplex ethernet-like network interfaces." ::= { etherGroups 11 } etherHCStatsGroup OBJECT-GROUP OBJECTS { dot3HCStatsAlignmentErrors, dot3HCStatsFCSErrors, dot3HCStatsInternalMacTransmitErrors, dot3HCStatsFrameTooLongs, dot3HCStatsInternalMacReceiveErrors, dot3HCStatsSymbolErrors } STATUS current DESCRIPTION "A collection of objects providing high-capacity statistics applicable to higher-speed ethernet-like network interfaces." ::= { etherGroups 12 } etherHCControlGroup OBJECT-GROUP OBJECTS { dot3HCControlInUnknownOpcodes } STATUS current DESCRIPTION "A collection of objects providing high-capacity statistics for the MAC Control sublayer on higher-speed ethernet-like network interfaces." ::= { etherGroups 13 } etherHCControlPauseGroup OBJECT-GROUP OBJECTS { dot3HCInPauseFrames, dot3HCOutPauseFrames Flick Standards Track [Page 54] RFC 3635 Ethernet-Like MIB September 2003 } STATUS current DESCRIPTION "A collection of objects providing high-capacity statistics for the MAC Control PAUSE function on higher-speed ethernet-like network interfaces." ::= { etherGroups 14 } etherRateControlGroup OBJECT-GROUP OBJECTS { dot3StatsRateControlAbility, dot3StatsRateControlStatus } STATUS current DESCRIPTION "A collection of objects providing information about the Rate Control function on ethernet-like interfaces." ::= { etherGroups 15 } END 5. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Flick Standards Track [Page 55] RFC 3635 Ethernet-Like MIB September 2003 6. Acknowledgements This document was produced by the IETF Ethernet Interfaces and Hub MIB Working Group, whose efforts were greatly advanced by the contributions of the following people: Ran Atkinson Mike Ayers Mike Heard Jeffrey Johnson Lynn Kubinec Kam Lam Kerry McDonald Steve McRobert K.C. Norseth Dan Romascanu Randy Presuhn Andrew Smith Kaj Tesink Geoff Thompson This document is based on the Proposed Standard Ethernet MIB, RFC 2665 [RFC2665], edited by John Flick of Hewlett-Packard and Jeffrey Johnson of RedBack Networks and produced by the Ethernet Interfaces and Hub MIB Working Group. It extends that document by providing support for 10 Gb/s Ethernet interfaces as defined in [IEEE802.3ae]. RFC 2665, in turn, is based on the Proposed Standard Ethernet MIB, RFC 2358 [RFC2358], edited by John Flick of Hewlett-Packard and Jeffrey Johnson of RedBack Networks and produced by the 802.3 Hub MIB Working Group. It extends that document by providing support for full-duplex Ethernet interfaces and 1000 Mb/sec Ethernet interfaces as outlined in [IEEE802.3]. RFC 2358, in turn, is almost completely based on both the Standard Ethernet MIB, RFC 1643 [RFC1643], and the Proposed Standard Ethernet MIB using the SNMPv2 SMI, RFC 1650 [RFC1650], both of which were edited by Frank Kastenholz of FTP Software and produced by the Interfaces MIB Working Group. RFC 2358 extends those documents by providing support for 100 Mb/sec ethernet interfaces. RFC 1643 and RFC 1650, in turn, are based on the Draft Standard Ethernet MIB, RFC 1398 [RFC1398], also edited by Frank Kastenholz and produced by the Ethernet MIB Working Group. Flick Standards Track [Page 56] RFC 3635 Ethernet-Like MIB September 2003 RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, RFC 1284 [RFC1284], which was edited by John Cook of Chipcom and produced by the Transmission MIB Working Group. The Ethernet MIB Working Group gathered implementation experience of the variables specified in RFC 1284, documented that experience in RFC 1369 [RFC1369], and used that information to develop this revised MIB. RFC 1284, in turn, is based on a document written by Frank Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management Draft M compatible MIB for TCP/IP Networks [KASTEN]. This document was modestly reworked, initially by the SNMP Working Group, and then by the Transmission Working Group, to reflect the current conventions for defining objects for MIB interfaces. James Davin, of the MIT Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN Systems, contributed to later drafts of this memo. Marshall Rose of Performance Systems International, Inc. converted the document into RFC 1212 [RFC1212] concise format. Anil Rijsinghani of DEC contributed text that more adequately describes the TDR test. Thanks to Frank Kastenholz of Interlan and Louis Steinberg of IBM for their experimentation. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2863, June 2000. [IEEE802.3] IEEE, IEEE Std 802.3, 2002 Edition: "Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", March 2002. Flick Standards Track [Page 57] RFC 3635 Ethernet-Like MIB September 2003 [IEEE802.3ae] IEEE, IEEE Std 802.3ae-2002, "Amendment: Media Access Control (MAC) Parameters, Physical Layers, and Management Parameters for 10 Gb/s Operation", August, 2002. [RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2", RFC 3636, September 2003. 8. Informative References [RFC1212] Rose, M. and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1213] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [RFC1284] Cook, J., "Definitions of Managed Objects for Ethernet-Like Interface Types", RFC 1284, December 1991. [RFC1369] Kastenholz, F., "Implementation Notes and Experience for The Internet Ethernet MIB", RFC 1369, October 1992. [RFC1398] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 1398, January 1993. [RFC1643] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", STD 50, RFC 1643, July 1994. [RFC1650] Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2", RFC 1650, August 1994. [RFC2358] Flick, J. and J. Johnson, "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 2358, June 1998. [RFC2665] Flick, J. and J. Johnson, "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 2665, August 1999. [RFC2666] Flick, J., "Definitions of Object Identifiers for Identifying Ethernet Chip Sets", RFC 2666, August 1999. Flick Standards Track [Page 58] RFC 3635 Ethernet-Like MIB September 2003 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Network Management Framework", RFC 3410, December 2002. [CASE] Case, J., and C. Partridge, "Case Diagrams: A First Step to Diagrammed Management Information Bases", Computer Communications Review, 19(1):13-16, January 1989. [RFC3637] Heard, C., "Definitions of Managed Objects for the Ethernet WAN Interface Sublayer", RFC 3637, September 2003. [KASTEN] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB for TCP/IP Networks", electronic mail message to mib-wg@nnsc.nsf.net, 9 June 1989. 9. Security Considerations There is one management object defined in this MIB that has a MAX- ACCESS clause of read-write. That object, dot3PauseAdminMode, may be used to change the flow control configuration on a network interface, which may result in dropped packets, or sending flow control packets on links where the link partner will not understand them. Either action could be detrimental to network performance. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. In particular, the dot3StatsEtherChipSet object may be considered sensitive in many environments, since it would allow an intruder to obtain information about which vendor's equipment is in use on the network. Note that this object has been deprecated. However, some implementors may still choose to implement it for backwards compatability. Most of the objects in this MIB module contain statistical information about particular network links. In some network environments, this information may be considered sensitive. Flick Standards Track [Page 59] RFC 3635 Ethernet-Like MIB September 2003 It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations This document does not define any new name space to be administered by IANA. However, section 3.2.4 does specify that some of the defined values in a current IANA-maintained name space are to be marked as deprecated or obsolete. In particular, the following enumerated values in the IANAifType TEXTUAL-CONVENTION in the IANAifType-MIB module have had an ASN.1 comment added by IANA stating that they have been deprecated: - iso88032Csmacd(7) - starLan(11) In addition, the following enumerated values have had an ASN.1 comment added by IANA stating that they are obsolete: - fastEther(62) - fastEtherFX(69) - gigabitEthernet(117) In all of the above cases, the ASN.1 comment indicates that ethernetCsmacd(6) should be used instead of these values. Flick Standards Track [Page 60] RFC 3635 Ethernet-Like MIB September 2003 A. Change Log A.1. Changes since RFC 2665 This section enumerates changes made to RFC 2665 to produce this document. (1) Updated references to the IEEE 802.3 standard to refer to the 2002 edition. (2) Added reference to IEEE 802.3ae-2002. (3) Updated WG e-mail address. (4) The following DESCRIPTION clauses have been updated to reflect behaviour on 10 Gb/s interfaces: dot3StatsAlignmentErrors and dot3StatsSymbolErrors. (5) The following objects have been added for management of the Rate Control function in WAN applications of ethernet: dot3StatsRateControlAbility and dot3StatsRateControlStatus. (6) The following 64-bit counters have been added to support operation on high-speed ethernet interfaces: dot3HCControlInUnknownOpcodes, dot3HCInPauseFrames, dot3HCOutPauseFrames, dot3HCStatsAlignmentErrors, dot3HCStatsFCSErrors, dot3HCStatsFrameTooLongs, dot3HCStatsInternalMacTransmitErrors, dot3HCStatsInternalMacReceiveErrors, dot3HCStatsSymbolErrors (7) Object groups and compliances have been added to contain the new objects. (8) The MODULE-IDENTITY clause has been updated to reflect the changes in the MIB module. (9) Use of the various ifType values for ethernet has been clarified to emphasize that all ethernet-like interfaces must use the ethernetCsmacd ifType. (10) Several clarifications were made to the section on the mapping of the Interface MIB objects to ethernet. (11) MIB boilerplate in section 2 has been updated to the latest approved text. Flick Standards Track [Page 61] RFC 3635 Ethernet-Like MIB September 2003 A.2. Changes between RFC 2358 and RFC 2665 This section enumerates changes made to RFC 2358 to produce RFC 2665. (1) Section 2 has been replaced with the current SNMP Management Framework boilerplate. (2) The ifMtu mapping has been clarified. (3) The relationship between the IEEE 802.3 octet counters and the IF-MIB octet counters has been clarified. (4) REFERENCE clauses have been updated to reflect the actual IEEE 802.3 managed object that each MIB object is based on. (5) The following object DESCRIPTION clauses have been updated to reflect that they do not increment in full-duplex mode: dot3StatsSingleCollisionFrames, dot3StatsMultipleCollisionFrames, dot3StatsSQETestErrors, dot3StatsDeferredTransmissions, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsCarrierSenseErrors, dot3CollFrequencies. (6) The following object DESCRIPTION clauses have been updated to reflect behaviour on full-duplex and 1000 Mb/s interfaces: dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsSQETestErrors, dot3StatsLateCollisions, dot3StatsSymbolErrors. (7) Two new tables, dot3ControlTable and dot3PauseTable, have been added. (8) A new object, dot3StatsDuplexStatus, has been added. (9) The object groups and compliances have been restructured. (10) The dot3StatsEtherChipSet object has been deprecated. (11) The dot3ChipSets have been moved to a separate document. A.3. Changes between RFC 1650 and RFC 2358 This section enumerates changes made to RFC 1650 to produce RFC 2358. (1) The MODULE-IDENTITY has been updated to reflect the changes in the MIB. Flick Standards Track [Page 62] RFC 3635 Ethernet-Like MIB September 2003 (2) A new object, dot3StatsSymbolErrors, has been added. (3) The definition of the object dot3StatsIndex has been converted to use the SMIv2 OBJECT-TYPE macro. (4) A new conformance group, etherStats100MbsGroup, has been added. (5) A new compliance statement, ether100MbsCompliance, has been added. (6) The Acknowledgements were extended to provide a more complete history of the origin of this document. (7) The discussion of ifType has been expanded. (8) A section on mapping of Interfaces MIB objects has been added. (9) A section defining the relationship of this MIB to the MAU MIB has been added. (10) A section on the mapping of IEEE 802.3 managed objects to this MIB and the Interfaces MIB has been added. (11) Converted the dot3Tests, dot3Errors, and dot3ChipSets OIDs to use the OBJECT-IDENTITY macro. (12) Added to the list of registered dot3ChipSets. (13) An intellectual property notice and copyright notice were added, as required by RFC 2026. Author's Address John Flick Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557 Phone: +1 916 785 4018 EMail: johnf@rose.hp.com Flick Standards Track [Page 63] RFC 3635 Ethernet-Like MIB September 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Flick Standards Track [Page 64] snmp-mibs-downloader-1.1/mibrfcs/rfc3705.txt0000644000000000000000000005713611402176071015574 0ustar Network Working Group B. Ray Request for Comments: 3705 PESA Switching Systems Category: Standards Track R. Abbi Alcatel February 2004 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Intellectual Property Statement. . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . 9 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 Ray & Abbi Standards Track [Page 1] RFC 3705 High Capacity Perfhist TC MIB February 2004 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Overview In cases where a manager must obtain performance history data about the behavior of equipment it manages, several strategies can be followed in the design of a MIB module that represents the managed equipment, including: - The agent counts events on a continuous basis and, whenever desired, the manager obtains the value of the event counter and adjusts its understanding of the history of events at the agent. - The agent allocates events to 'buckets' where each bucket represents an interval of time. Telecommunications equipment often makes use of the latter strategy. For such equipment the standard practice is that history data is maintained by the agent in terms of 15-minute intervals [T1.231]. MIB modules for collecting performance history based on 15-minute intervals have been defined for the DS1/E1 [RFC2495], DS3/E3 [RFC2496], SONET/SDH [RFC3592], ADSL [RFC2662], HDLS2 and SHDSL [RFC3276] interface types. These MIB modules use a common set of textual conventions defined in [RFC3593]. A need has arisen to define 64-bit versions of the textual conventions in [RFC3593]. Ideally, these high-capacity textual conventions would be based on a Gauge64 or Unsigned64 data type, but unfortunately no such types exist in SMIv2. The next best choice would be to base them on the CounterBasedGauge64 textual convention Ray & Abbi Standards Track [Page 2] RFC 3705 High Capacity Perfhist TC MIB February 2004 presented in [RFC2856], but that is not possible either since SMIv2 allows only base types to be used in defining textual conventions. Therefore, the textual conventions presented in this memo are based directly on the Counter64 type, like those in [RFC2856]. They are subject to the following limitations: - The MAX-ACCESS of objects defined using these textual conventions must be read-only, because the MAX-ACCESS of the underlying Counter64 type is read-only. - No sub-range can be specified in object definitions using these textual conventions, because sub-ranges are not allowed on Counter64 objects. - No DEFVAL clause can be specified in object definitions using these textual conventions, because DEFVALs are not allowed on Counter64 objects. - Objects defined using these textual conventions cannot be used in an INDEX clause, because there is no INDEX clause mapping defined for objects of type Counter64. Use of the textual conventions presented in this memo assumes the following: - The agent supports 15 minute based history counters. - The agent is capable of keeping a history of 96 intervals of 15 minute performance data. - The agent may optionally support performance data aggregating the history intervals. - The agent will keep separate tables for the current interval, the history intervals, and the total aggregates. 3. Definitions HC-PerfHist-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Counter64, Unsigned32, Integer32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; Ray & Abbi Standards Track [Page 3] RFC 3705 High Capacity Perfhist TC MIB February 2004 hcPerfHistTCMIB MODULE-IDENTITY LAST-UPDATED "200402030000Z" -- February 3, 2004 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-7324 USA Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-editor: Bob Ray PESA Switching Systems, Inc. Postal: 330-A Wynn Drive Huntsville, AL 35805 USA Email: rray@pesa.com Phone: +1 256 726 9200 ext. 142 Co-editor: Rajesh Abbi Alcatel USA Postal: 2301 Sugar Bush Road Raleigh, NC 27612-3339 USA Email: Rajesh.Abbi@alcatel.com Phone: +1 919 850 6194 " DESCRIPTION "This MIB Module provides Textual Conventions to be used by systems supporting 15 minute based performance history counts that require high-capacity counts. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3705: see the RFC itself for full legal notices." REVISION "200402030000Z" -- February 3, 2004 DESCRIPTION "Initial version, published as RFC 3705." ::= { mib-2 107 } HCPerfValidIntervals ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The number of near end intervals for which data was Ray & Abbi Standards Track [Page 4] RFC 3705 High Capacity Perfhist TC MIB February 2004 collected. The value of an object with an HCPerfValidIntervals syntax will be 96 unless the measurement was (re-)started within the last 1440 minutes, in which case the value will be the number of complete 15 minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy) it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." SYNTAX Integer32 (0..96) HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The number of near end intervals for which no data is available. The value of an object with an HCPerfInvalidIntervals syntax will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." SYNTAX Integer32 (0..96) HCPerfTimeElapsed ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock or the addition of a leap second, the duration of the current interval exceeds the maximum value, the agent will return the maximum value. For 15 minute intervals, the range is limited to (0..899). For 24 hour intervals, the range is limited to (0..86399)." SYNTAX Integer32 (0..86399) HCPerfIntervalThreshold ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm." SYNTAX Unsigned32 (0..900) HCPerfCurrentCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Ray & Abbi Standards Track [Page 5] RFC 3705 High Capacity Perfhist TC MIB February 2004 "A gauge associated with a performance measurement in a current 15 minute measurement interval. The value of an object with an HCPerfCurrentCount syntax starts from zero and is increased when associated events occur, until the end of the 15 minute interval. At that time the value of the gauge is stored in the first 15 minute history interval, and the gauge is restarted at zero. In the case where the agent has no valid data available for the current interval, the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist. This count represents a non-negative integer, which may increase or decrease, but shall never exceed 2^64-1 (18446744073709551615 decimal), nor fall below 0. The value of an object with HCPerfCurrentCount syntax assumes its maximum value whenever the underlying count exceeds 2^64-1. If the underlying count subsequently decreases below 2^64-1 (due, e.g., to a retroactive adjustment as a result of entering or exiting unavailable time), then the object's value also decreases. Note that this TC is not strictly supported in SMIv2, because the 'always increasing' and 'counter wrap' semantics associated with the Counter64 base type are not preserved. It is possible that management applications which rely solely upon the (Counter64) ASN.1 tag to determine object semantics will mistakenly operate upon objects of this type as they would for Counter64 objects. This textual convention represents a limited and short- term solution, and may be deprecated as a long term solution is defined and deployed to replace it." SYNTAX Counter64 HCPerfIntervalCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A gauge associated with a performance measurement in a previous 15 minute measurement interval. In the case where the agent has no valid data available for a particular interval, the corresponding object instance is not available and upon a retrieval request a corresponding error message shall be returned to indicate that this instance does not exist. Let X be an object with HCPerfIntervalCount syntax. Ray & Abbi Standards Track [Page 6] RFC 3705 High Capacity Perfhist TC MIB February 2004 Let Y be an object with HCPerfCurrentCount syntax. Let Z be an object with HCPerfTotalCount syntax. Then, in a system supporting a history of n intervals with X(1) and X(n) the most and least recent intervals respectively, the following applies at the end of a 15 minute interval: - discard the value of X(n) - the value of X(i) becomes that of X(i-1) for n >= i > 1 - the value of X(1) becomes that of Y. - the value of Z, if supported, is adjusted. This count represents a non-negative integer, which may increase or decrease, but shall never exceed 2^64-1 (18446744073709551615 decimal), nor fall below 0. The value of an object with HCPerfIntervalCount syntax assumes its maximum value whenever the underlying count exceeds 2^64-1. If the underlying count subsequently decreases below 2^64-1 (due, e.g., to a retroactive adjustment as a result of entering or exiting unavailable time), then the value of the object also decreases. Note that this TC is not strictly supported in SMIv2, because the 'always increasing' and 'counter wrap' semantics associated with the Counter64 base type are not preserved. It is possible that management applications which rely solely upon the (Counter64) ASN.1 tag to determine object semantics will mistakenly operate upon objects of this type as they would for Counter64 objects. This textual convention represents a limited and short- term solution, and may be deprecated as a long term solution is defined and deployed to replace it." SYNTAX Counter64 HCPerfTotalCount ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A gauge representing the aggregate of previous valid 15 minute measurement intervals. Intervals for which no valid data was available are not counted. This count represents a non-negative integer, which may increase or decrease, but shall never exceed 2^64-1 (18446744073709551615 decimal), nor fall below 0. The value of an object with HCPerfTotalCount syntax assumes its maximum value whenever the underlying count Ray & Abbi Standards Track [Page 7] RFC 3705 High Capacity Perfhist TC MIB February 2004 exceeds 2^64-1. If the underlying count subsequently decreases below 2^64-1 (due, e.g., to a retroactive adjustment as a result of entering or exiting unavailable time), then the object's value also decreases. Note that this TC is not strictly supported in SMIv2, because the 'always increasing' and 'counter wrap' semantics associated with the Counter64 base type are not preserved. It is possible that management applications which rely solely upon the (Counter64) ASN.1 tag to determine object semantics will mistakenly operate upon objects of this type as they would for Counter64 objects. This textual convention represents a limited and short- term solution, and may be deprecated as a long term solution is defined and deployed to replace it." SYNTAX Counter64 END 4. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Ray & Abbi Standards Track [Page 8] RFC 3705 High Capacity Perfhist TC MIB February 2004 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 5.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [T1.231] American National Standard for Telecommunications - Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring, ANSI T1.231-1997, September 1997. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999. [RFC2496] Fowler, D., "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 2496, January 1999. [RFC3592] Tesink, K., "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", RFC 3592, November 2003. [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, August 1999. [RFC2856] Bierman, A., McCloghrie, K. and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC3276] Ray, B. and R. Abbi, "Definitions of Managed Objects for High Bit-rate DSL - 2nd Generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", RFC 3276, May 2002. Ray & Abbi Standards Track [Page 9] RFC 3705 High Capacity Perfhist TC MIB February 2004 [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, November 2003. 6. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. This document has therefore no impact on the security of the Internet. 7. Acknowledgements This document borrows tremendously from [RFC3593] and [RFC2856]. As such, any credit for the text found within should be fully attributed to the authors of those documents. 8. Authors' Addresses Bob Ray PESA Switching Systems, Inc. 330-A Wynn Drive Huntsville, AL 35805 USA Phone: +1 256 726 9200 ext. 142 Fax: +1 256 726 9271 EMail: rray@pesa.com Rajesh Abbi Alcatel USA 2301 Sugar Bush Road Raleigh, NC 27612-3339 USA Phone: +1 919 850 6194 EMail: Rajesh.Abbi@alcatel.com Ray & Abbi Standards Track [Page 10] RFC 3705 High Capacity Perfhist TC MIB February 2004 9. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ray & Abbi Standards Track [Page 11] snmp-mibs-downloader-1.1/mibrfcs/rfc3728.txt0000644000000000000000000043744011402176071015601 0ustar Network Working Group B. Ray Request for Comments: 3728 PESA Switching Systems Category: Standards Track R. Abbi Alcatel February 2004 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Relationship of the VDSL Line MIB Module to other MIB Modules. . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2. Conventions used in the MIB Module . . . . . . . . . . . 4 2.3. Structure. . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Counters, Interval Buckets and Thresholds. . . . . . . . 7 2.5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Notifications. . . . . . . . . . . . . . . . . . . . . . 9 2.7. Persistence. . . . . . . . . . . . . . . . . . . . . . . 10 3. Conformance and Compliance . . . . . . . . . . . . . . . . . . 11 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 72 6.2. Informative References . . . . . . . . . . . . . . . . . 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74 Ray & Abbi Standards Track [Page 1] RFC 3728 VDSL-LINE MIB February 2004 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 75 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 76 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Overview This document describes an SNMP MIB module for managing VDSL Lines. These definitions are based upon the specifications for VDSL as defined in T1E1, ETSI, and ITU documentation [T1E1311, T1E1011, T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971]. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of this document. 2.1. Relationship of the VDSL Line MIB Module to other MIB Modules This section outlines the relationship of this MIB with other MIBs described in RFCs. Specifically, IF-MIB as presented in RFC 2863 [RFC2863] is discussed. 2.1.1. General IF-MIB Integration (RFC 2863) The VDSL Line MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with RFC 2863 [RFC2863]. The IANA has assigned the following ifType to VDSL: Ray & Abbi Standards Track [Page 2] RFC 3728 VDSL-LINE MIB February 2004 IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... vdsl(97), -- Very H-speed Digital Subscrib. Loop ... } Additionally, a VDSL line may contain an optional fast channel and an optional interleaved channel which also integrate into RFC 2863 [RFC2863]. The IANA has assigned the following ifTypes to these channels: IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... interleave (124), -- Interleave channel fast (125), -- Fast channel ... } 2.1.2. Usage of ifTable The MIB branch identified by this ifType contains tables appropriate for this interface type. Most tables extend the ifEntry table, and are indexed by ifIndex. For interfaces in systems implementing this MIB, those table entries indexed by ifIndex MUST be persistent. The following attributes are part of the mandatory ifGeneral group in RFC 2863 [RFC2863], and are not duplicated in the VDSL Line MIB. =================================================================== ifIndex Interface index. ifDescr See interfaces MIB [RFC2863]. ifType vdsl(97), interleave(124), or fast(125) ifSpeed Set as appropriate. ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB [RFC2863]. Ray & Abbi Standards Track [Page 3] RFC 3728 VDSL-LINE MIB February 2004 ifOperStatus See interfaces MIB [RFC2863]. ifLastChange See interfaces MIB [RFC2863]. ifName See interfaces MIB [RFC2863]. ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. ifLinkUpDownTrapEnable Default to enabled(1). =================================================================== Figure 1: Use of ifTable Objects Section 2.3, below, describes the structure of this MIB in relation to ifEntry in greater detail. 2.2. Conventions used in the MIB Module 2.2.1. Naming Conventions A. Vtuc -- (VTUC) transceiver at near (Central) end of line B. Vtur -- (VTUR) transceiver at Remote end of line C. Vtu -- One of either Vtuc or Vtur D. Curr -- Current E. Prev -- Previous F. Atn -- Attenuation G. ES -- Errored Second H. SES -- Severely Errored Second I. UAS -- Unavailable Second J. LCS -- Line Code Specific K. Lof -- Loss of Frame L. Lol -- Loss of Link M. Los -- Loss of Signal N. Lpr -- Loss of Power O. xxxs -- Sum of Seconds in which xxx has occured (e.g., xxx = Lof, Los, Lpr, Lol) P. Max -- Maximum Q. Mgn -- Margin R. Min -- Minimum S. Psd -- Power Spectral Density T. Snr -- Signal to Noise Ratio U. Tx -- Transmit V. Blks -- Blocks Ray & Abbi Standards Track [Page 4] RFC 3728 VDSL-LINE MIB February 2004 2.2.2. Textual Conventions The following textual conventions are defined to reflect the line topology in the MIB (further discussed in the following section) and to define the behavior of the statistics to be maintained by an agent. o VdslLineCodingType : Attributes with this syntax identify the line coding used. Specified as an INTEGER, the three values are: other(1) -- none of the following mcm(2) -- Multiple Carrier Modulation scm(3) -- Single Carrier Modulation o VdslLineEntity : Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: vtuc(1) -- central site transceiver vtur(2) -- remote site transceiver 2.3 Structure The MIB is structured into the following MIB groups: o vdslGroup : This group supports all line code independent MIB objects found in this MIB. The following tables contain objects permitted for ifType vdsl(97): - vdslLineTable - vdslPhysTable - vdslPerfDataTable - vdslPerfIntervalTable - vdslPerf1DayIntervalTable - vdslLineConfProfileTable - vdslLineAlarmConfProfileTable Ray & Abbi Standards Track [Page 5] RFC 3728 VDSL-LINE MIB February 2004 The following tables contain objects permitted for ifTypes interleave(124) and (fast): - vdslChanTable - vdslChanPerfDataTable - vdslChanPerfIntervalTable - vdslChanPerf1DayIntervalTable Figure 2, below, displays the relationship of the tables in the vdslGroup to ifEntry (and each other): ifEntry(ifType=97) ---> vdslLineTableEntry 1:(0 to 1) vdslLineTableEntry ---> vdslPhysTableEntry 1:(0 to 2) ---> vdslPerfDataEntry 1:(0 to 2) ---> vdslLineConfProfileEntry 1:(0 to 1) ---> vdslLineAlarmConfProfileEntry 1:(0 to 1) vdslPhysTableEntry ---> vdslPerfIntervalEntry 1:(0 to 96) ---> vdslPerf1DayIntervalEntry 1:(0 to 30) ifEntry(ifType=124) ---> vdslChanEntry 1:(0 to 2) ---> vdslChanPerfDataEntry 1:(0 to 2) ifEntry(ifType=125) ---> vdslChanEntry 1:(0 to 2) ---> vdslChanPerfDataEntry 1:(0 to 2) vdslChanEntry ---> vdslchanPerfIntervalEntry 1:(0 to 96) ---> vdslchan1DayPerfIntervalEntry 1:(0 to 30) Figure 2: Table Relationships o vdslNotificationGroup : This group contains definitions of VDSL line notifications. Section 2.6, below, presents greater detail on the notifications defined within the MIB module. Ray & Abbi Standards Track [Page 6] RFC 3728 VDSL-LINE MIB February 2004 2.3.1. Line Topology A VDSL Line consists of two units - a Vtuc (the central transceiver unit) and a Vtur (the remote transceiver unit). <-- Network Side Customer Side --> || +-------+ +-------+ | | | | | Vtuc +------------------+ Vtur | | | | | +-------+ +-------+ Figure 3: General topology for a VDSL Line 2.4. Counters, Interval Buckets and Thresholds For Loss of Frame (lof), Loss of Link (lol), Loss of Signal (los), and Loss of Power (lpr), Errored Seconds (ES), Severely Errored Seconds (SES), and Unavailable Seconds (UAS) there are event counters, current 15-minute, 0 to 96 15-minute history bucket(s), and 0 to 30 1-day history bucket(s) of "interval-counters". Each current 15-minute event bucket has an associated threshold notification. Each of these counters uses the textual conventions defined in the HC-PerfHist-TC-MIB [RFC3705]. The HC-PerfHist-TC-MIB defines 64-bit versions of the textual conventions found in RFC 3593 [RFC3593]. There is no requirement for an agent to ensure a fixed relationship between the start of a fifteen minute interval and any wall clock; however, some implementations may align the fifteen minute intervals with quarter hours. Likewise, an implementation may choose to align one day intervals with the start of a day. Counters are not reset when a Vtu is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module). Ray & Abbi Standards Track [Page 7] RFC 3728 VDSL-LINE MIB February 2004 2.5. Profiles As a managed node can handle a large number of Vtus, (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on every Vtu may become burdensome. Moreover, most lines are provisioned identically with the same set of parameters. To simplify the provisioning process, this MIB makes use of profiles. A profile is a set of parameters that can be shared by multiple lines using the same configuration. The following profiles are used in this MIB module: o Line Configuration Profiles - Line configuration profiles contain parameters for configuring VDSL lines. They are defined in the vdslLineConfProfileTable. o Alarm Configuration Profiles - These profiles contain parameters for configuring alarm thresholds for VDSL transceivers. These profiles are defined in the vdslLineAlarmConfProfileTable. One or more lines may be configured to share parameters of a single profile by setting their vdslLineConfProfile objects to the value of this profile. If a change is made to the profile, all lines that refer to it will be reconfigured to the changed parameters. Before a profile can be deleted or taken out of service it must be first unreferenced from all associated lines. Implementations MUST provide a default profile with an index value of 'DEFVAL' for each profile type. The values of the associated parameters will be vendor specific unless otherwise indicated in this document. Before a line's profiles have been set, these profiles will be automatically used by setting vdslLineConfProfile and vdslLineAlarmConfProfile to 'DEFVAL' where appropriate. This default profile name, 'DEFVAL', is considered reserved in the context of profiles defined in this MIB module. Profiles are created, assigned, and deleted dynamically using the profile name and profile row status in each of the ten profile tables (nine line configuration tables and one alarm configuration table). Profile changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line. Ray & Abbi Standards Track [Page 8] RFC 3728 VDSL-LINE MIB February 2004 2.6. Notifications The ability to generate the SNMP notifications coldStart/WarmStart (per [RFC3418]) which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/linkDown (per [RFC2863]) which are per interface (i.e., VDSL line) is required. The notifications defined in this MIB are for initialization failure and for the threshold crossings associated with the following events: lof, lol, los, lpr, ES, SES, and UAS. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. A linkDown notification MAY be generated whenever any of lof, lol, los, lpr, ES, SES, or UAS threshold crossing event (as defined in this MIB module) occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The vdslPhysCurrStatus is a bitmask representing all outstanding error conditions associated with a particular VDSL transceiver. Note that since status of remote transceivers is obtained via the EOC, this information may be unavailable for units that are unreachable via the EOC during a line error condition. Therefore, not all conditions may always be included in its current status. Notifications corresponding to the bit fields in this object are defined. A threshold notification occurs whenever the corresponding current 15-minute interval error counter becomes equal to, or exceeds the threshold value. One notification may be sent per interval per interface. Since the current 15-minute counters are reset to 0 every 15 minutes, if the condition persists, the notification may recur as often as every 15 minutes. For example, to get a notification whenever a "loss of" event occurs (but at most once every 15 minutes), set the corresponding threshold to 1. The agent will generate a notification when the event originally occurs. Note that the Network Management System, or NMS, may receive a linkDown notification, as well, if enabled (via ifLinkUpDownTrapEnable [RFC2863]). At the beginning of the next 15 minute interval, the counter is reset. When the first second goes by and the event occurs, the current interval bucket will be 1, which equals the threshold and the notification will be sent again. Ray & Abbi Standards Track [Page 9] RFC 3728 VDSL-LINE MIB February 2004 2.7. Persistence All read-write and read-create objects defined in this MIB module SHOULD be stored persistently. Following is an exhaustive list of these persistent objects: - vdslLineConfProfile - vdslLineAlarmConfProfile - vdslLineConfProfileName - vdslLineConfDownRateMode - vdslLineConfUpRateMode - vdslLineConfDownMaxPwr - vdslLineConfUpMaxPwr - vdslLineConfDownMaxSnrMgn - vdslLineConfDownMinSnrMgn - vdslLineConfDownTargetSnrMgn - vdslLineConfUpMaxSnrMgn - vdslLineConfUpMinSnrMgn - vdslLineConfUpTargetSnrMgn - vdslLineConfDownFastMaxDataRate - vdslLineConfDownFastMinDataRate - vdslLineConfDownSlowMaxDataRate - vdslLineConfDownSlowMinDataRate - vdslLineConfUpFastMaxDataRate - vdslLineConfUpFastMinDataRate - vdslLineConfUpSlowMaxDataRate - vdslLineConfUpSlowMinDataRate - vdslLineConfDownRateRatio - vdslLineConfUpRateRatio - vdslLineConfDownMaxInterDelay - vdslLineConfUpMaxInterDelay - vdslLineConfDownPboControl - vdslLineConfUpPboControl - vdslLineConfDownPboLevel - vdslLineConfUpPboLevel - vdslLineConfDeploymentScenario - vdslLineConfAdslPresence - vdslLineConfApplicableStandard - vdslLineConfBandPlan - vdslLineConfBandPlanFx - vdslLineConfBandOptUsage - vdslLineConfUpPsdTemplate - vdslLineConfDownPsdTemplate - vdslLineConfHamBandMask - vdslLineConfCustomNotch1Start - vdslLineConfCustomNotch1Stop - vdslLineConfCustomNotch2Start - vdslLineConfCustomNotch2Stop Ray & Abbi Standards Track [Page 10] RFC 3728 VDSL-LINE MIB February 2004 - vdslLineConfDownTargetSlowBurst - vdslLineConfUpTargetSlowBurst - vdslLineConfDownMaxFastFec - vdslLineConfUpMaxFastFec - vdslLineConfLineType - vdslLineConfProfRowStatus - vdslLineAlarmConfProfileName - vdslLineAlarmConfThresh15MinLofs - vdslLineAlarmConfThresh15MinLoss - vdslLineAlarmConfThresh15MinLprs - vdslLineAlarmConfThresh15MinLols - vdslLineAlarmConfThresh15MinESs - vdslLineAlarmConfThresh15MinSESs - vdslLineAlarmConfThresh15MinUASs - vdslLineAlarmConfInitFailure - vdslLineAlarmConfProfRowStatus It should also be noted that interface indices in this MIB are maintained persistently. VACM data relating to these SHOULD be stored persistently as well [RFC3415]. 3. Conformance and Compliance For VDSL lines, the following groups are mandatory: - vdslGroup - vdslNotificationGroup 4. Definitions VDSL-LINE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Gauge32, Integer32, Unsigned32, NOTIFICATION-TYPE, transmission FROM SNMPv2-SMI -- [RFC2578] ZeroBasedCounter64 FROM HCNUM-TC -- [RFC2856] TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC -- [RFC2579] HCPerfValidIntervals, HCPerfInvalidIntervals, HCPerfTimeElapsed, Ray & Abbi Standards Track [Page 11] RFC 3728 VDSL-LINE MIB February 2004 HCPerfIntervalThreshold, HCPerfCurrentCount, HCPerfIntervalCount FROM HC-PerfHist-TC-MIB -- [RFC3705] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] ifIndex FROM IF-MIB -- [RFC2863] SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] vdslMIB MODULE-IDENTITY LAST-UPDATED "200402190000Z" -- February 19, 2004 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh, NC 27627-7324 USA Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-editor: Bob Ray PESA Switching Systems, Inc. Postal: 330-A Wynn Drive Huntsville, AL 35805 USA Email: rray@pesa.com Phone: +1 256 726 9200 ext. 142 Co-editor: Rajesh Abbi Alcatel USA Postal: 2301 Sugar Bush Road Raleigh, NC 27612-3339 USA Email: Rajesh.Abbi@alcatel.com Phone: +1 919 850 6194 " DESCRIPTION "The MIB module defining objects for the management of a pair of VDSL transceivers at each end of the VDSL line. Each such line has an entry in an ifTable which may include multiple transceiver lines. An agent may reside at either end of the VDSL line. However, the MIB is designed to require no management communication between them beyond that inherent in the low-level VDSL line protocol. The agent may monitor and control this protocol for its needs. Ray & Abbi Standards Track [Page 12] RFC 3728 VDSL-LINE MIB February 2004 VDSL lines may support optional Fast or Interleaved channels. If these are supported, additional entries corresponding to the supported channels must be created in the ifTable. Thus a VDSL line that supports both channels will have three entries in the ifTable, one for each physical, fast, and interleaved, whose ifType values are equal to vdsl(97), fast(125), and interleaved(124), respectively. The ifStackTable is used to represent the relationship between the entries. Naming Conventions: Vtuc -- (VTUC) transceiver at near (Central) end of line Vtur -- (VTUR) transceiver at Remote end of line Vtu -- One of either Vtuc or Vtur Curr -- Current Prev -- Previous Atn -- Attenuation ES -- Errored Second. SES -- Severely Errored Second UAS -- Unavailable Second LCS -- Line Code Specific Lof -- Loss of Frame Lol -- Loss of Link Los -- Loss of Signal Lpr -- Loss of Power xxxs -- Sum of Seconds in which xxx has occured (e.g., xxx = Lof, Los, Lpr, Lol) Max -- Maximum Mgn -- Margin Min -- Minimum Psd -- Power Spectral Density Snr -- Signal to Noise Ratio Tx -- Transmit Blks -- Blocks Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3728: see the RFC itself for full legal notices." REVISION "200402190000Z" -- February 19, 2004 DESCRIPTION "Initial version, published as RFC 3728." ::= { transmission 97 } vdslLineMib OBJECT IDENTIFIER ::= { vdslMIB 1 } vdslMibObjects OBJECT IDENTIFIER ::= { vdslLineMib 1 } -- -- textual conventions used in this MIB -- Ray & Abbi Standards Track [Page 13] RFC 3728 VDSL-LINE MIB February 2004 VdslLineCodingType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax for the VDSL Line Code. Attributes with this syntax identify the line coding used. Specified as an INTEGER, the three values are: other(1) -- none of the following mcm(2) -- Multiple Carrier Modulation scm(3) -- Single Carrier Modulation" SYNTAX INTEGER { other(1), mcm(2), scm(3) } VdslLineEntity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a transceiver as being either Vtuc or Vtur. A VDSL line consists of two transceivers, a Vtuc and a Vtur. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: vtuc(1) -- central site transceiver vtur(2) -- remote site transceiver" SYNTAX INTEGER { vtuc(1), vtur(2) } -- -- objects -- vdslLineTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes common attributes describing both ends of the line. It is required for all VDSL physical interfaces. VDSL physical interfaces are those ifEntries where ifType is equal to vdsl(97)." ::= { vdslMibObjects 1 } Ray & Abbi Standards Track [Page 14] RFC 3728 VDSL-LINE MIB February 2004 vdslLineEntry OBJECT-TYPE SYNTAX VdslLineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslLineTable." INDEX { ifIndex } ::= { vdslLineTable 1 } VdslLineEntry ::= SEQUENCE { vdslLineCoding VdslLineCodingType, vdslLineType INTEGER, vdslLineConfProfile SnmpAdminString, vdslLineAlarmConfProfile SnmpAdminString } vdslLineCoding OBJECT-TYPE SYNTAX VdslLineCodingType MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the VDSL coding type used on this line." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslLineEntry 1 } vdslLineType OBJECT-TYPE SYNTAX INTEGER { noChannel(1), -- no channels exist fastOnly(2), -- only fast channel exists interleavedOnly(3), -- only interleaved channel exists fastOrInterleaved(4), -- either fast or interleaved channel -- exist, but only one at a time fastAndInterleaved(5) -- both fast and interleaved channels -- exist } MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the type of VDSL physical line entity that exists, by defining whether and how the line is channelized. If Ray & Abbi Standards Track [Page 15] RFC 3728 VDSL-LINE MIB February 2004 the line is channelized, the value will be other than noChannel(1). This object defines which channel type(s) are supported. Defined values are: noChannel(1) -- no channels exist fastOnly(2) -- only fast channel exists interleavedOnly(3) -- only interleaved channel exists fastOrInterleaved(4) -- either fast or interleaved channel -- exist, but only one at a time fastAndInterleaved(5) -- both fast and interleaved channels -- exist Note that 'slow' and 'interleaved' refer to the same channel. In the case that the line is channelized, the manager can use the ifStackTable to determine the ifIndex for the associated channel(s)." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslLineEntry 2 } vdslLineConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL Line Configuration Profile Table, vdslLineConfProfileTable, which applies for this VDSL line, and channels if applicable. This object MUST be maintained in a persistent manner." DEFVAL { "DEFVAL" } ::= { vdslLineEntry 3 } vdslLineAlarmConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL Line Alarm Configuration Profile Table, vdslLineAlarmConfProfileTable, which applies to this VDSL line, and channels if applicable. This object MUST be maintained in a persistent manner." DEFVAL { "DEFVAL" } ::= { vdslLineEntry 4 } vdslPhysTable OBJECT-TYPE Ray & Abbi Standards Track [Page 16] RFC 3728 VDSL-LINE MIB February 2004 SYNTAX SEQUENCE OF VdslPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu. Each row contains the Physical Layer Parameters table for that Vtu. VDSL physical interfaces are those ifEntries where ifType is equal to vdsl(97)." ::= { vdslMibObjects 2 } vdslPhysEntry OBJECT-TYPE SYNTAX VdslPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslPhysTable." INDEX { ifIndex, vdslPhysSide } ::= { vdslPhysTable 1 } VdslPhysEntry ::= SEQUENCE { vdslPhysSide VdslLineEntity, vdslPhysInvSerialNumber SnmpAdminString, vdslPhysInvVendorID SnmpAdminString, vdslPhysInvVersionNumber SnmpAdminString, vdslPhysCurrSnrMgn Integer32, vdslPhysCurrAtn Gauge32, vdslPhysCurrStatus BITS, vdslPhysCurrOutputPwr Integer32, vdslPhysCurrAttainableRate Gauge32, vdslPhysCurrLineRate Gauge32 } vdslPhysSide OBJECT-TYPE SYNTAX VdslLineEntity MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies whether the transceiver is the Vtuc or Vtur." ::= { vdslPhysEntry 1 } vdslPhysInvSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString(SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific string that identifies the Ray & Abbi Standards Track [Page 17] RFC 3728 VDSL-LINE MIB February 2004 vendor equipment." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 2 } vdslPhysInvVendorID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor ID code is a copy of the binary vendor identification field expressed as readable characters in hexadecimal notation." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 3 } vdslPhysInvVersionNumber OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific version number sent by this Vtu as part of the initialization messages. It is a copy of the binary version number field expressed as readable characters in hexadecimal notation." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 4 } vdslPhysCurrSnrMgn OBJECT-TYPE SYNTAX Integer32 (-127..127) UNITS "0.25dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Noise Margin as seen by this Vtu with respect to its received signal in 0.25dB. The effective range is -31.75 to +31.75 dB." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 5 } vdslPhysCurrAtn OBJECT-TYPE SYNTAX Gauge32 (0..255) UNITS "0.25dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured difference in the total power transmitted by the peer Vtu and the total power received by this Vtu. The effective range is 0 to +63.75 dB." Ray & Abbi Standards Track [Page 18] RFC 3728 VDSL-LINE MIB February 2004 REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 6 } vdslPhysCurrStatus OBJECT-TYPE SYNTAX BITS { noDefect(0), lossOfFraming(1), lossOfSignal(2), lossOfPower(3), lossOfSignalQuality(4), lossOfLink(5), dataInitFailure(6), configInitFailure(7), protocolInitFailure(8), noPeerVtuPresent(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state of the Vtu line. This is a bit-map of possible conditions. The various bit positions are: 0 noDefect There are no defects on the line. 1 lossOfFraming Vtu failure due to not receiving a valid frame. 2 lossOfSignal Vtu failure due to not receiving signal. 3 lossOfPower Vtu failure due to loss of power. 4 lossOfSignalQuality Loss of Signal Quality is declared when the Noise Margin falls below the Minimum Noise Margin, or the bit-error-rate exceeds 10^-7. 5 lossOfLink Vtu failure due to inability to link with peer Vtu. Set whenever the transceiver is in the 'Warm Start' state. 6 dataInitFailure Vtu failure during initialization due to bit errors corrupting startup exchange data. Ray & Abbi Standards Track [Page 19] RFC 3728 VDSL-LINE MIB February 2004 7 configInitFailure Vtu failure during initialization due to peer Vtu not able to support requested configuration. 8 protocolInitFailure Vtu failure during initialization due to incompatible protocol used by the peer Vtu. 9 noPeerVtuPresent Vtu failure during initialization due to no activation sequence detected from peer Vtu. This is intended to supplement ifOperStatus." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 7 } vdslPhysCurrOutputPwr OBJECT-TYPE SYNTAX Integer32 (0..160) UNITS "0.1dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured total output power transmitted by this VTU. This is the measurement that was reported during the last activation sequence." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 8 } vdslPhysCurrAttainableRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kbps" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the maximum currently attainable data rate in steps of 1000 bits/second by the Vtu. This value will be equal to or greater than vdslPhysCurrLineRate. Note that for SCM, the minimum and maximum data rates are equal. Note: 1 kbps = 1000 bps." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 9 } vdslPhysCurrLineRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kbps" MAX-ACCESS read-only STATUS current DESCRIPTION Ray & Abbi Standards Track [Page 20] RFC 3728 VDSL-LINE MIB February 2004 "Indicates the current data rate in steps of 1000 bits/second by the Vtu. This value will be less than or equal to vdslPhysCurrAttainableRate. Note: 1 kbps = 1000 bps." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPhysEntry 10 } vdslChanTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu channel. VDSL channel interfaces are those ifEntries where ifType is equal to interleave(124) or fast(125)." ::= { vdslMibObjects 3 } vdslChanEntry OBJECT-TYPE SYNTAX VdslChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslChanTable." INDEX { ifIndex, vdslPhysSide } ::= { vdslChanTable 1 } VdslChanEntry ::= SEQUENCE { vdslChanInterleaveDelay Gauge32, vdslChanCrcBlockLength Gauge32, vdslChanCurrTxRate Gauge32, vdslChanCurrTxSlowBurstProtect Gauge32, vdslChanCurrTxFastFec Gauge32 } vdslChanInterleaveDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Interleave Delay for this channel. Interleave delay applies only to the interleave (slow) channel and defines the mapping (relative spacing) between subsequent input bytes at the Ray & Abbi Standards Track [Page 21] RFC 3728 VDSL-LINE MIB February 2004 interleaver input and their placement in the bit stream at the interleaver output. Larger numbers provide greater separation between consecutive input bytes in the output bit stream allowing for improved impulse noise immunity at the expense of payload latency. In the case where the ifType is fast(125), return a value of zero." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanEntry 1 } vdslChanCrcBlockLength OBJECT-TYPE SYNTAX Gauge32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the length of the channel data-block on which the CRC operates." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanEntry 2 } vdslChanCurrTxRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kbps" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual transmit data rate on this channel. Note: 1 kbps = 1000 bps." ::= { vdslChanEntry 3 } vdslChanCurrTxSlowBurstProtect OBJECT-TYPE SYNTAX Gauge32 (0..1275) UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual level of impulse noise (burst) protection for an interleaved (slow) channel. This parameter is not applicable to fast channels. For fast channels, a value of zero shall be returned." REFERENCE "ITU-T G.997.1, section 7.3.2.3" ::= { vdslChanEntry 4 } vdslChanCurrTxFastFec OBJECT-TYPE SYNTAX Gauge32 (0..50) Ray & Abbi Standards Track [Page 22] RFC 3728 VDSL-LINE MIB February 2004 UNITS "%" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Forward Error Correction (FEC) redundancy related overhead for a fast channel. This parameter is not applicable to an interleaved (slow) channel. For interleaved channels, a value of zero shall be returned." ::= { vdslChanEntry 5 } vdslPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each VDSL physical interface. VDSL physical interfaces are those ifEntries where ifType is equal to vdsl(97)." ::= { vdslMibObjects 4 } vdslPerfDataEntry OBJECT-TYPE SYNTAX VdslPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslPerfDataTable." INDEX { ifIndex, vdslPhysSide } ::= { vdslPerfDataTable 1 } VdslPerfDataEntry ::= SEQUENCE { vdslPerfDataValidIntervals HCPerfValidIntervals, vdslPerfDataInvalidIntervals HCPerfInvalidIntervals, vdslPerfDataLofs Unsigned32, vdslPerfDataLoss Unsigned32, vdslPerfDataLprs Unsigned32, vdslPerfDataLols Unsigned32, vdslPerfDataESs Unsigned32, vdslPerfDataSESs Unsigned32, vdslPerfDataUASs Unsigned32, vdslPerfDataInits Unsigned32, vdslPerfDataCurr15MinTimeElapsed HCPerfTimeElapsed, vdslPerfDataCurr15MinLofs HCPerfCurrentCount, vdslPerfDataCurr15MinLoss HCPerfCurrentCount, vdslPerfDataCurr15MinLprs HCPerfCurrentCount, Ray & Abbi Standards Track [Page 23] RFC 3728 VDSL-LINE MIB February 2004 vdslPerfDataCurr15MinLols HCPerfCurrentCount, vdslPerfDataCurr15MinESs HCPerfCurrentCount, vdslPerfDataCurr15MinSESs HCPerfCurrentCount, vdslPerfDataCurr15MinUASs HCPerfCurrentCount, vdslPerfDataCurr15MinInits HCPerfCurrentCount, vdslPerfData1DayValidIntervals HCPerfValidIntervals, vdslPerfData1DayInvalidIntervals HCPerfInvalidIntervals, vdslPerfDataCurr1DayTimeElapsed HCPerfTimeElapsed, vdslPerfDataCurr1DayLofs Unsigned32, vdslPerfDataCurr1DayLoss Unsigned32, vdslPerfDataCurr1DayLprs Unsigned32, vdslPerfDataCurr1DayLols Unsigned32, vdslPerfDataCurr1DayESs Unsigned32, vdslPerfDataCurr1DaySESs Unsigned32, vdslPerfDataCurr1DayUASs Unsigned32, vdslPerfDataCurr1DayInits Unsigned32 } vdslPerfDataValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals UNITS "intervals" MAX-ACCESS read-only STATUS current DESCRIPTION "Valid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslPerfDataEntry 1 } vdslPerfDataInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals UNITS "intervals" MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslPerfDataEntry 2 } vdslPerfDataLofs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there was Loss of Framing." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 3 } Ray & Abbi Standards Track [Page 24] RFC 3728 VDSL-LINE MIB February 2004 vdslPerfDataLoss OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there was Loss of Signal." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 4 } vdslPerfDataLprs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there was Loss of Power." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 5 } vdslPerfDataLols OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there was Loss of Link." ::= { vdslPerfDataEntry 6 } vdslPerfDataESs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds since the unit was last reset. An Errored Second is a one-second interval containing one or more CRC anomalies, or one or more LOS or LOF defects." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 7 } vdslPerfDataSESs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" Ray & Abbi Standards Track [Page 25] RFC 3728 VDSL-LINE MIB February 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds since the unit was last reset." ::= { vdslPerfDataEntry 8 } vdslPerfDataUASs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds since the unit was last reset." ::= { vdslPerfDataEntry 9 } vdslPerfDataInits OBJECT-TYPE SYNTAX Unsigned32 UNITS "occurrences" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts since the unit was last reset. This count includes both successful and failed attempts." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 10 } vdslPerfDataCurr15MinTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { vdslPerfDataEntry 11 } vdslPerfDataCurr15MinLofs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was Loss of Framing." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 12 } Ray & Abbi Standards Track [Page 26] RFC 3728 VDSL-LINE MIB February 2004 vdslPerfDataCurr15MinLoss OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was Loss of Signal." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 13 } vdslPerfDataCurr15MinLprs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was Loss of Power." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 14 } vdslPerfDataCurr15MinLols OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was Loss of Link." ::= { vdslPerfDataEntry 15 } vdslPerfDataCurr15MinESs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds during this interval. An Errored Second is a one-second interval containing one or more CRC anomalies, or one or more LOS or LOF defects." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 16 } vdslPerfDataCurr15MinSESs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only Ray & Abbi Standards Track [Page 27] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "Count of Severely Errored Seconds during this interval." ::= { vdslPerfDataEntry 17 } vdslPerfDataCurr15MinUASs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds during this interval." ::= { vdslPerfDataEntry 18 } vdslPerfDataCurr15MinInits OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "occurrences" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts during this interval. This count includes both successful and failed attempts." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfDataEntry 19 } vdslPerfData1DayValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals UNITS "intervals" MAX-ACCESS read-only STATUS current DESCRIPTION "Valid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslPerfDataEntry 20 } vdslPerfData1DayInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals UNITS "intervals" MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslPerfDataEntry 21 } vdslPerfDataCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed Ray & Abbi Standards Track [Page 28] RFC 3728 VDSL-LINE MIB February 2004 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 22 } vdslPerfDataCurr1DayLofs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Framing (LOF) Seconds since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 23 } vdslPerfDataCurr1DayLoss OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Signal (LOS) Seconds since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 24 } vdslPerfDataCurr1DayLprs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Power (LPR) Seconds since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 25 } vdslPerfDataCurr1DayLols OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Link (LOL) Seconds since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 26 } Ray & Abbi Standards Track [Page 29] RFC 3728 VDSL-LINE MIB February 2004 vdslPerfDataCurr1DayESs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 27 } vdslPerfDataCurr1DaySESs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 28 } vdslPerfDataCurr1DayUASs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) since the beginning of the current 1-day interval." ::= { vdslPerfDataEntry 29 } vdslPerfDataCurr1DayInits OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts since the beginning of the current 1-day interval. This count includes both successful and failed attempts." ::= { vdslPerfDataEntry 30 } vdslPerfIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu performance data collection interval. VDSL physical interfaces are Ray & Abbi Standards Track [Page 30] RFC 3728 VDSL-LINE MIB February 2004 those ifEntries where ifType is equal to vdsl(97)." ::= { vdslMibObjects 5 } vdslPerfIntervalEntry OBJECT-TYPE SYNTAX VdslPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslPerfIntervalTable." INDEX { ifIndex, vdslPhysSide, vdslPerfIntervalNumber } ::= { vdslPerfIntervalTable 1 } VdslPerfIntervalEntry ::= SEQUENCE { vdslPerfIntervalNumber Unsigned32, vdslPerfIntervalLofs HCPerfIntervalCount, vdslPerfIntervalLoss HCPerfIntervalCount, vdslPerfIntervalLprs HCPerfIntervalCount, vdslPerfIntervalLols HCPerfIntervalCount, vdslPerfIntervalESs HCPerfIntervalCount, vdslPerfIntervalSESs HCPerfIntervalCount, vdslPerfIntervalUASs HCPerfIntervalCount, vdslPerfIntervalInits HCPerfIntervalCount } vdslPerfIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number 1 is the most recent previous interval; interval 96 is 24 hours ago. Intervals 2 to 96 are optional." ::= { vdslPerfIntervalEntry 1 } vdslPerfIntervalLofs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Framing." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfIntervalEntry 2 } Ray & Abbi Standards Track [Page 31] RFC 3728 VDSL-LINE MIB February 2004 vdslPerfIntervalLoss OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Signal." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfIntervalEntry 3 } vdslPerfIntervalLprs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Power." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfIntervalEntry 4 } vdslPerfIntervalLols OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Link." ::= { vdslPerfIntervalEntry 5 } vdslPerfIntervalESs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) in the interval. An Errored Second is a one-second interval containing one or more CRC anomalies, one or more LOS or LOF defects." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfIntervalEntry 6 } vdslPerfIntervalSESs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only Ray & Abbi Standards Track [Page 32] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "Count of Severely Errored Seconds in the interval." ::= { vdslPerfIntervalEntry 7 } vdslPerfIntervalUASs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds in the interval." ::= { vdslPerfIntervalEntry 8 } vdslPerfIntervalInits OBJECT-TYPE SYNTAX HCPerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts during this interval. This count includes both successful and failed attempts." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerfIntervalEntry 9 } vdslPerf1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each VDSL performance data collection interval. This table contains live data from equipment. As such, it is NOT persistent." ::= { vdslMibObjects 6 } vdslPerf1DayIntervalEntry OBJECT-TYPE SYNTAX VdslPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslPerf1DayIntervalTable." INDEX { ifIndex, vdslPhysSide, vdslPerf1DayIntervalNumber } ::= { vdslPerf1DayIntervalTable 1 } VdslPerf1DayIntervalEntry ::= SEQUENCE Ray & Abbi Standards Track [Page 33] RFC 3728 VDSL-LINE MIB February 2004 { vdslPerf1DayIntervalNumber Unsigned32, vdslPerf1DayIntervalMoniSecs HCPerfTimeElapsed, vdslPerf1DayIntervalLofs Unsigned32, vdslPerf1DayIntervalLoss Unsigned32, vdslPerf1DayIntervalLprs Unsigned32, vdslPerf1DayIntervalLols Unsigned32, vdslPerf1DayIntervalESs Unsigned32, vdslPerf1DayIntervalSESs Unsigned32, vdslPerf1DayIntervalUASs Unsigned32, vdslPerf1DayIntervalInits Unsigned32 } vdslPerf1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "History Data Interval number. Interval 1 is the most recent previous day; interval 30 is 30 days ago. Intervals 2 to 30 are optional." ::= { vdslPerf1DayIntervalEntry 1 } vdslPerf1DayIntervalMoniSecs OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::= { vdslPerf1DayIntervalEntry 2 } vdslPerf1DayIntervalLofs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Frame (LOF) Seconds during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerf1DayIntervalEntry 3 } vdslPerf1DayIntervalLoss OBJECT-TYPE Ray & Abbi Standards Track [Page 34] RFC 3728 VDSL-LINE MIB February 2004 SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Signal (LOS) Seconds during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerf1DayIntervalEntry 4 } vdslPerf1DayIntervalLprs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Power (LPR) Seconds during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerf1DayIntervalEntry 5 } vdslPerf1DayIntervalLols OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Link (LOL) Seconds during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs." ::= { vdslPerf1DayIntervalEntry 6 } vdslPerf1DayIntervalESs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerf1DayIntervalEntry 7 } vdslPerf1DayIntervalSESs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Ray & Abbi Standards Track [Page 35] RFC 3728 VDSL-LINE MIB February 2004 "Count of Severely Errored Seconds (SES) during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs." ::= { vdslPerf1DayIntervalEntry 8 } vdslPerf1DayIntervalUASs OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs." ::= { vdslPerf1DayIntervalEntry 9 } vdslPerf1DayIntervalInits OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts during the 1-day interval as measured by vdslPerf1DayIntervalMoniSecs. This count includes both successful and failed attempts." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslPerf1DayIntervalEntry 10 } vdslChanPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu channel. VDSL channel interfaces are those ifEntries where ifType is equal to interleave(124) or fast(125)." ::= { vdslMibObjects 7 } vdslChanPerfDataEntry OBJECT-TYPE SYNTAX VdslChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslChanPerfDataTable." INDEX { ifIndex, vdslPhysSide } ::= { vdslChanPerfDataTable 1 } VdslChanPerfDataEntry ::= SEQUENCE Ray & Abbi Standards Track [Page 36] RFC 3728 VDSL-LINE MIB February 2004 { vdslChanValidIntervals HCPerfValidIntervals, vdslChanInvalidIntervals HCPerfInvalidIntervals, vdslChanFixedOctets ZeroBasedCounter64, vdslChanBadBlks ZeroBasedCounter64, vdslChanCurr15MinTimeElapsed HCPerfTimeElapsed, vdslChanCurr15MinFixedOctets HCPerfCurrentCount, vdslChanCurr15MinBadBlks HCPerfCurrentCount, vdslChan1DayValidIntervals HCPerfValidIntervals, vdslChan1DayInvalidIntervals HCPerfInvalidIntervals, vdslChanCurr1DayTimeElapsed HCPerfTimeElapsed, vdslChanCurr1DayFixedOctets HCPerfCurrentCount, vdslChanCurr1DayBadBlks HCPerfCurrentCount } vdslChanValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals UNITS "intervals" MAX-ACCESS read-only STATUS current DESCRIPTION "Valid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslChanPerfDataEntry 1 } vdslChanInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals UNITS "intervals" MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslChanPerfDataEntry 2 } vdslChanFixedOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of corrected octets since the unit was last reset." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanPerfDataEntry 3 } vdslChanBadBlks OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "blocks" Ray & Abbi Standards Track [Page 37] RFC 3728 VDSL-LINE MIB February 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of uncorrectable blocks since the unit was last reset." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanPerfDataEntry 4 } vdslChanCurr15MinTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { vdslChanPerfDataEntry 5 } vdslChanCurr15MinFixedOctets OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of corrected octets in this interval." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanPerfDataEntry 6 } vdslChanCurr15MinBadBlks OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "blocks" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of uncorrectable blocks in this interval." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanPerfDataEntry 7 } vdslChan1DayValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION "Valid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslChanPerfDataEntry 8 } vdslChan1DayInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals Ray & Abbi Standards Track [Page 38] RFC 3728 VDSL-LINE MIB February 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid Intervals per definition found in HC-PerfHist-TC-MIB." ::= { vdslChanPerfDataEntry 9 } vdslChanCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::= { vdslChanPerfDataEntry 10 } vdslChanCurr1DayFixedOctets OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of corrected octets since the beginning of the current 1-day interval." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanPerfDataEntry 11 } vdslChanCurr1DayBadBlks OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "blocks" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of uncorrectable blocks since the beginning of the current 1-day interval." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanPerfDataEntry 12 } vdslChanIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu channel data collection interval. VDSL channel interfaces are those ifEntries where ifType is equal to interleave(124) or fast(125)." Ray & Abbi Standards Track [Page 39] RFC 3728 VDSL-LINE MIB February 2004 ::= { vdslMibObjects 8 } vdslChanIntervalEntry OBJECT-TYPE SYNTAX VdslChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslChanIntervalTable." INDEX { ifIndex, vdslPhysSide, vdslChanIntervalNumber } ::= { vdslChanIntervalTable 1 } VdslChanIntervalEntry ::= SEQUENCE { vdslChanIntervalNumber Unsigned32, vdslChanIntervalFixedOctets HCPerfIntervalCount, vdslChanIntervalBadBlks HCPerfIntervalCount } vdslChanIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number 1 is the most recent previous interval; interval 96 is 24 hours ago. Intervals 2 to 96 are optional." ::= { vdslChanIntervalEntry 1 } vdslChanIntervalFixedOctets OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of corrected octets in this interval." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanIntervalEntry 2 } vdslChanIntervalBadBlks OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "blocks" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of uncorrectable blocks in this interval." Ray & Abbi Standards Track [Page 40] RFC 3728 VDSL-LINE MIB February 2004 REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChanIntervalEntry 3 } vdslChan1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChan1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each VDSL performance data collection interval. This table contains live data from equipment. As such, it is NOT persistent." ::= { vdslMibObjects 9 } vdslChan1DayIntervalEntry OBJECT-TYPE SYNTAX VdslChan1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslChan1DayIntervalTable." INDEX { ifIndex, vdslPhysSide, vdslChan1DayIntervalNumber } ::= { vdslChan1DayIntervalTable 1 } VdslChan1DayIntervalEntry ::= SEQUENCE { vdslChan1DayIntervalNumber Unsigned32, vdslChan1DayIntervalMoniSecs HCPerfTimeElapsed, vdslChan1DayIntervalFixedOctets HCPerfCurrentCount, vdslChan1DayIntervalBadBlks HCPerfCurrentCount } vdslChan1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "History Data Interval number. Interval 1 is the most recent previous day; interval 30 is 30 days ago. Intervals 2 to 30 are optional." ::= { vdslChan1DayIntervalEntry 1 } vdslChan1DayIntervalMoniSecs OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current Ray & Abbi Standards Track [Page 41] RFC 3728 VDSL-LINE MIB February 2004 DESCRIPTION "The amount of time in the 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::= { vdslChan1DayIntervalEntry 2 } vdslChan1DayIntervalFixedOctets OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of corrected octets in this interval." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChan1DayIntervalEntry 3 } vdslChan1DayIntervalBadBlks OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "blocks" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of uncorrectable blocks in this interval." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" ::= { vdslChan1DayIntervalEntry 4 } -- -- profile tables -- vdslLineConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the VDSL line configuration. One entry in this table reflects a profile defined by a manager which can be used to configure the VDSL line. Entries in this table MUST be maintained in a persistent manner." ::= { vdslMibObjects 11 } vdslLineConfProfileEntry OBJECT-TYPE SYNTAX VdslLineConfProfileEntry Ray & Abbi Standards Track [Page 42] RFC 3728 VDSL-LINE MIB February 2004 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of a VDSL line. A default profile with an index of 'DEFVAL', will always exist and its parameters will be set to vendor specific values, unless otherwise specified in this document." INDEX { vdslLineConfProfileName } ::= { vdslLineConfProfileTable 1 } VdslLineConfProfileEntry ::= SEQUENCE { vdslLineConfProfileName SnmpAdminString, vdslLineConfDownRateMode INTEGER, vdslLineConfUpRateMode INTEGER, vdslLineConfDownMaxPwr Unsigned32, vdslLineConfUpMaxPwr Unsigned32, vdslLineConfDownMaxSnrMgn Unsigned32, vdslLineConfDownMinSnrMgn Unsigned32, vdslLineConfDownTargetSnrMgn Unsigned32, vdslLineConfUpMaxSnrMgn Unsigned32, vdslLineConfUpMinSnrMgn Unsigned32, vdslLineConfUpTargetSnrMgn Unsigned32, vdslLineConfDownFastMaxDataRate Unsigned32, vdslLineConfDownFastMinDataRate Unsigned32, vdslLineConfDownSlowMaxDataRate Unsigned32, vdslLineConfDownSlowMinDataRate Unsigned32, vdslLineConfUpFastMaxDataRate Unsigned32, vdslLineConfUpFastMinDataRate Unsigned32, vdslLineConfUpSlowMaxDataRate Unsigned32, vdslLineConfUpSlowMinDataRate Unsigned32, vdslLineConfDownRateRatio Unsigned32, vdslLineConfUpRateRatio Unsigned32, vdslLineConfDownMaxInterDelay Unsigned32, vdslLineConfUpMaxInterDelay Unsigned32, vdslLineConfDownPboControl INTEGER, vdslLineConfUpPboControl INTEGER, vdslLineConfDownPboLevel Unsigned32, vdslLineConfUpPboLevel Unsigned32, vdslLineConfDeploymentScenario INTEGER, vdslLineConfAdslPresence INTEGER, vdslLineConfApplicableStandard INTEGER, vdslLineConfBandPlan INTEGER, vdslLineConfBandPlanFx Unsigned32, Ray & Abbi Standards Track [Page 43] RFC 3728 VDSL-LINE MIB February 2004 vdslLineConfBandOptUsage INTEGER, vdslLineConfUpPsdTemplate INTEGER, vdslLineConfDownPsdTemplate INTEGER, vdslLineConfHamBandMask BITS, vdslLineConfCustomNotch1Start Unsigned32, vdslLineConfCustomNotch1Stop Unsigned32, vdslLineConfCustomNotch2Start Unsigned32, vdslLineConfCustomNotch2Stop Unsigned32, vdslLineConfDownTargetSlowBurst Unsigned32, vdslLineConfUpTargetSlowBurst Unsigned32, vdslLineConfDownMaxFastFec Unsigned32, vdslLineConfUpMaxFastFec Unsigned32, vdslLineConfLineType INTEGER, vdslLineConfProfRowStatus RowStatus } vdslLineConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table. A default profile with an index of 'DEFVAL', will always exist and its parameters will be set to vendor specific values, unless otherwise specified in this document." ::= { vdslLineConfProfileEntry 1 } vdslLineConfDownRateMode OBJECT-TYPE SYNTAX INTEGER { manual(1), adaptAtInit(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the rate selection behavior for the line in the downstream direction. manual(1) forces the rate to the configured rate adaptAtInit(2) adapts the line based upon line quality." DEFVAL { adaptAtInit } ::= { vdslLineConfProfileEntry 2 } vdslLineConfUpRateMode OBJECT-TYPE SYNTAX INTEGER Ray & Abbi Standards Track [Page 44] RFC 3728 VDSL-LINE MIB February 2004 { manual(1), adaptAtInit(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the rate selection behavior for the line in the upstream direction. manual(1) forces the rate to the configured rate adaptAtInit(2) adapts the line based upon line quality." DEFVAL { adaptAtInit } ::= { vdslLineConfProfileEntry 3 } vdslLineConfDownMaxPwr OBJECT-TYPE SYNTAX Unsigned32 (0..58) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum aggregate downstream power level in the range 0 to 14.5 dBm." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 4 } vdslLineConfUpMaxPwr OBJECT-TYPE SYNTAX Unsigned32 (0..58) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum aggregate upstream power level in the range 0 to 14.5 dBm." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 5 } vdslLineConfDownMaxSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum downstream Signal/Noise Margin in units of 0.25 dB, for a range of 0 to 31.75 dB." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" Ray & Abbi Standards Track [Page 45] RFC 3728 VDSL-LINE MIB February 2004 DEFVAL { 0 } ::= { vdslLineConfProfileEntry 6 } vdslLineConfDownMinSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum downstream Signal/Noise Margin in units of 0.25 dB, for a range of 0 to 31.75 dB." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 7 } vdslLineConfDownTargetSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target downstream Signal/Noise Margin in units of 0.25 dB, for a range of 0 to 31.75 dB. This is the Noise Margin the transceivers must achieve with a BER of 10^-7 or better to successfully complete initialization." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 8 } vdslLineConfUpMaxSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum upstream Signal/Noise Margin in units of 0.25 dB, for a range of 0 to 31.75 dB." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 9 } vdslLineConfUpMinSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION Ray & Abbi Standards Track [Page 46] RFC 3728 VDSL-LINE MIB February 2004 "Specifies the minimum upstream Signal/Noise Margin in units of 0.25 dB, for a range of 0 to 31.75 dB." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 10 } vdslLineConfUpTargetSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target upstream Signal/Noise Margin in units of 0.25 dB, for a range of 0 to 31.75 dB. This is the Noise Margin the transceivers must achieve with a BER of 10^-7 or better to successfully complete initialization." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 11 } vdslLineConfDownFastMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum downstream fast channel data rate in steps of 1000 bits/second." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 12 } vdslLineConfDownFastMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum downstream fast channel data rate in steps of 1000 bits/second." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 13 } vdslLineConfDownSlowMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current Ray & Abbi Standards Track [Page 47] RFC 3728 VDSL-LINE MIB February 2004 DESCRIPTION "Specifies the maximum downstream slow channel data rate in steps of 1000 bits/second. The maximum aggregate downstream transmit speed of the line can be derived from the sum of maximum downstream fast and slow channel data rates." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 14 } vdslLineConfDownSlowMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum downstream slow channel data rate in steps of 1000 bits/second. The minimum aggregate downstream transmit speed of the line can be derived from the sum of minimum downstream fast and slow channel data rates." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 15 } vdslLineConfUpFastMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum upstream fast channel data rate in steps of 1000 bits/second. The maximum aggregate upstream transmit speed of the line can be derived from the sum of maximum upstream fast and slow channel data rates." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 16 } vdslLineConfUpFastMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum upstream fast channel data rate in steps of 1000 bits/second. Ray & Abbi Standards Track [Page 48] RFC 3728 VDSL-LINE MIB February 2004 The minimum aggregate upstream transmit speed of the line can be derived from the sum of minimum upstream fast and slow channel data rates." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 17 } vdslLineConfUpSlowMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum upstream slow channel data rate in steps of 1000 bits/second." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 18 } vdslLineConfUpSlowMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum upstream slow channel data rate in steps of 1000 bits/second." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 19 } vdslLineConfDownRateRatio OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "For dynamic rate adaptation at startup, the allocation of data rate in excess of the minimum data rate for each channel is controlled by the object. This object specifies the ratio of the allocation of the excess data rate between the fast and the slow channels. This allocation represents downstream Fast Channel Allocation / Slow Channel Allocation." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 20 } vdslLineConfUpRateRatio OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percent" MAX-ACCESS read-create Ray & Abbi Standards Track [Page 49] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "For dynamic rate adaptation at startup, the allocation of data rate in excess of the minimum data rate for each channel is controlled by the object. This object specifies the ratio of the allocation of the excess data rate between the fast and the slow channels. This allocation represents upstream Fast Channel Allocation/Slow Channel Allocation." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 21 } vdslLineConfDownMaxInterDelay OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum interleave delay for the downstream slow channel." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 22 } vdslLineConfUpMaxInterDelay OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum interleave delay for the upstream slow channel." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 23 } vdslLineConfDownPboControl OBJECT-TYPE SYNTAX INTEGER { disabled(1), auto(2), manual(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Downstream power backoff (PBO) control for this line. For transceivers which do not support downstream PBO control, this object MUST be fixed at disabled(1). If auto(2) is selected, the transceiver will automatically adjust the power backoff. If manual(3) is selected, Ray & Abbi Standards Track [Page 50] RFC 3728 VDSL-LINE MIB February 2004 then the transceiver will use the value from vdslLineConfDownPboLevel." DEFVAL { disabled } ::= { vdslLineConfProfileEntry 24 } vdslLineConfUpPboControl OBJECT-TYPE SYNTAX INTEGER { disabled(1), auto(2), manual(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Upstream power backoff (PBO) control for this line. For transceivers which do not support upstream PBO control, this object MUST be fixed at disabled(1). If auto(2) is selected, the transceiver will automatically adjust the power backoff. If manual(3) is selected, then the transceiver will use the value from vdslLineConfUpPboLevel." DEFVAL { disabled } ::= { vdslLineConfProfileEntry 25 } vdslLineConfDownPboLevel OBJECT-TYPE SYNTAX Unsigned32 (0..160) UNITS "0.25dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the downstream backoff level to be used when vdslLineConfDownPboControl = manual(3)." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 26 } vdslLineConfUpPboLevel OBJECT-TYPE SYNTAX Unsigned32 (0..160) UNITS "0.25dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the upstream backoff level to be used when vdslLineConfUpPboControl = manual(3)." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 27 } vdslLineConfDeploymentScenario OBJECT-TYPE Ray & Abbi Standards Track [Page 51] RFC 3728 VDSL-LINE MIB February 2004 SYNTAX INTEGER { fttCab(1), fttEx(2), other(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The VDSL line deployment scenario. When using fttCab(1), the VTU-C is located in a street cabinet. When using fttEx(2), the VTU-C is located at the central office. Changes to this value will have no effect on the transceiver." REFERENCE "DSL Forum TR-057" DEFVAL { fttCab } ::= { vdslLineConfProfileEntry 28 } vdslLineConfAdslPresence OBJECT-TYPE SYNTAX INTEGER { none(1), adslOverPots(2), adslOverISDN(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates presence of ADSL service in the associated cable bundle/binder. none(1) indicates no ADSL service in the bundle adslOverPots(2) indicates ADSL service over POTS is present in the bundle adslOverISDN(3) indicates ADSL service over ISDN is present in the bundle" DEFVAL { none } ::= { vdslLineConfProfileEntry 29 } vdslLineConfApplicableStandard OBJECT-TYPE SYNTAX INTEGER { ansi(1), etsi(2), itu(3), other(4) } MAX-ACCESS read-create Ray & Abbi Standards Track [Page 52] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "The VDSL standard to be used for the line. ansi(1) indicates ANSI standard etsi(2) indicates ETSI standard itu(3) indicates ITU standard other(4) indicates a standard other than the above." DEFVAL { ansi } ::= { vdslLineConfProfileEntry 30 } vdslLineConfBandPlan OBJECT-TYPE SYNTAX INTEGER { bandPlan997(1), bandPlan998(2), bandPlanFx(3), other(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The VDSL band plan to be used for the line. bandPlan997(1) is to be used for ITU-T G.993.1 Bandplan-B ETSI Bandplan ANSI Plan 997 bandPlan998(2) is to be used for ITU-T G.993.1 Bandplan-A ANSI Plan 998 bandPlanFx(3) is to be used for ITU-T G.993.1 Bandplan-C. other(4) is to be used for non-standard bandplans. If this object is set to bandPlanFx(3), then the object vdslLineConfBandPlanFx MUST also be set." DEFVAL { bandPlan997 } ::= { vdslLineConfProfileEntry 31 } vdslLineConfBandPlanFx OBJECT-TYPE SYNTAX Unsigned32 (3750..12000) UNITS "kHz" MAX-ACCESS read-create Ray & Abbi Standards Track [Page 53] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "The frequency limit between bands D2 and U2 when vdslLineConfBandPlan is set to bandPlanFx(3)." DEFVAL { 3750 } ::= { vdslLineConfProfileEntry 32 } vdslLineConfBandOptUsage OBJECT-TYPE SYNTAX INTEGER { unused(1), upstream(2), downstream(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the VDSL link use of the optional frequency range [25kHz - 138kHz] (Opt). unused(1) indicates Opt is unused upstream(2) indicates Opt usage is for upstream downstream(3) indicates Opt usage is for downstream." REFERENCE "ITU-T G.993.1, section 6.1" DEFVAL { unused } ::= { vdslLineConfProfileEntry 33 } vdslLineConfUpPsdTemplate OBJECT-TYPE SYNTAX INTEGER { templateMask1(1), templateMask2(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The upstream PSD template to be used for the line. Here, templateMask1(1) refers to a notched mask that limits the transmitted PSD within the internationally standardized HAM (Handheld Amateur Radio) radio bands, while templateMask2(2) refers to an unnotched mask. The masks themselves depend upon the applicable standard being used (vdslLineConfApplicableStandard)." REFERENCE "DSL TR-057" DEFVAL { templateMask1 } ::= { vdslLineConfProfileEntry 34 } Ray & Abbi Standards Track [Page 54] RFC 3728 VDSL-LINE MIB February 2004 vdslLineConfDownPsdTemplate OBJECT-TYPE SYNTAX INTEGER { templateMask1(1), templateMask2(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The downstream PSD template to be used for the line. Here, templateMask1(1) refers to a notched mask that limits the transmitted PSD within the internationally standardized HAM (Handheld Amateur Radio) radio bands, while templateMask2(2) refers to an unnotched mask. The masks themselves depend upon the applicable standard being used (vdslLineConfApplicableStandard)." REFERENCE "DSL TR-057" DEFVAL { templateMask1 } ::= { vdslLineConfProfileEntry 35 } vdslLineConfHamBandMask OBJECT-TYPE SYNTAX BITS { customNotch1(0), -- custom (region-specific) notch customNotch2(1), -- custom (region-specific) notch amateurBand30m(2), -- amateur radio band notch amateurBand40m(3), -- amateur radio band notch amateurBand80m(4), -- amateur radio band notch amateurBand160m(5) -- amateur radio band notch } MAX-ACCESS read-create STATUS current DESCRIPTION "The transmit power spectral density mask code, used to avoid interference with HAM (Handheld Amateur Radio) radio bands by introducing power control (notching) in one or more of these bands. Amateur radio band notching is defined in the VDSL spectrum as follows: Band Start Frequency Stop Frequency ---- ------------------ -------------------------------- 30m 1810 kHz 2000 kHz 40m 3500 kHz 3800 kHz (ETSI); 4000 kHz (ANSI) 80m 7000 kHz 7100 kHz (ETSI); 7300 kHz (ANSI) 160m 10100 kHz 10150 kHz Ray & Abbi Standards Track [Page 55] RFC 3728 VDSL-LINE MIB February 2004 Notching for each standard band can be enabled or disabled via the bit mask. Two custom notches may be specified. If either of these are enabled via the bit mask, then the following objects MUST be specified: If customNotch1 is enabled, then both vdslLineConfCustomNotch1Start vdslLineConfCustomNotch1Stop MUST be specified. If customNotch2 is enabled, then both vdslLineConfCustomNotch2Start vdslLineConfCustomNotch2Stop MUST be specified." REFERENCE "DSLF TR-057, section 2.6" DEFVAL { { } } ::= { vdslLineConfProfileEntry 36 } vdslLineConfCustomNotch1Start OBJECT-TYPE SYNTAX Unsigned32 UNITS "kHz" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the start frequency of custom HAM (Handheld Amateur Radio) notch 1. vdslLineConfCustomNotch1Start MUST be less than or equal to vdslLineConfCustomNotch1Stop." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 37 } vdslLineConfCustomNotch1Stop OBJECT-TYPE SYNTAX Unsigned32 UNITS "kHz" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the stop frequency of custom HAM (Handheld Amateur Radio) notch 1. vdslLineConfCustomNotch1Stop MUST be greater than or equal to vdslLineConfCustomNotch1Start." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 38 } vdslLineConfCustomNotch2Start OBJECT-TYPE SYNTAX Unsigned32 UNITS "kHz" MAX-ACCESS read-create Ray & Abbi Standards Track [Page 56] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "Specifies the start frequency of custom HAM (Handheld Amateur Radio) notch 2. vdslLineConfCustomNotch2Start MUST be less than or equal to vdslLineConfCustomNotch2Stop." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 39 } vdslLineConfCustomNotch2Stop OBJECT-TYPE SYNTAX Unsigned32 UNITS "kHz" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the stop frequency of custom HAM (Handheld Amateur Radio) notch 2. vdslLineConfCustomNotch2Stop MUST be greater than or equal to vdslLineConfCustomNotch2Start." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 40 } vdslLineConfDownTargetSlowBurst OBJECT-TYPE SYNTAX Unsigned32 (0..1275) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target level of impulse noise (burst) protection for an interleaved (slow) channel." REFERENCE "ITU-T G.997.1, section 7.3.2.3" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 41 } vdslLineConfUpTargetSlowBurst OBJECT-TYPE SYNTAX Unsigned32 (0..1275) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target level of impulse noise (burst) protection for an interleaved (slow) channel." REFERENCE "ITU-T G.997.1, section 7.3.2.3" DEFVAL { 0 } ::= { vdslLineConfProfileEntry 42 } vdslLineConfDownMaxFastFec OBJECT-TYPE SYNTAX Unsigned32 (0..50) UNITS "%" MAX-ACCESS read-create Ray & Abbi Standards Track [Page 57] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "This parameter provisions the maximum level of Forward Error Correction (FEC) redundancy related overhead to be maintained for a fast channel." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 43 } vdslLineConfUpMaxFastFec OBJECT-TYPE SYNTAX Unsigned32 (0..50) UNITS "%" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter provisions the maximum level of Forward Error Correction (FEC) redundancy related overhead to be maintained for a fast channel." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 44 } vdslLineConfLineType OBJECT-TYPE SYNTAX INTEGER { noChannel(1), -- no channels exist fastOnly(2), -- only fast channel exists interleavedOnly(3), -- only interleaved channel exists fastOrInterleaved(4), -- either fast or interleaved channel -- exist, but only one at a time fastAndInterleaved(5) -- both fast and interleaved channels -- exist } MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter provisions the VDSL physical entity at start-up by defining whether and how the line will be channelized, i.e., which channel type(s) are supported. If the line is to be channelized, the value will be other than noChannel(1). This configuration can be activated only during start-up. Afterwards, the value of vdslLineType coincides with the value of vdslLineConfLineType. Depending on this value, the corresponding entries in the ifTable for the interleaved and the fast channels are enabled or disabled according to the value of their ifOperStatus. Defined values are: Ray & Abbi Standards Track [Page 58] RFC 3728 VDSL-LINE MIB February 2004 noChannel(1) -- no channels exist fastOnly(2) -- only fast channel exists interleavedOnly(3) -- only interleaved channel exists fastOrInterleaved(4) -- either fast or interleaved channel -- exists, but only one at a time fastAndInterleaved(5) -- both fast and interleaved channels -- exist Note that 'slow' and 'interleaved' refer to the same channel." REFERENCE "T1E1.4/2000-009R3, Part 1, common spec" DEFVAL { noChannel } ::= { vdslLineConfProfileEntry 45 } vdslLineConfProfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile activated by setting this object to 'active'. When 'active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'outOfService'), it must be first unreferenced from all associated lines. An 'active' profile may be modified at any time. Note that some changes may require that any referenced lines be restarted (e.g., vdslLineConfLineType)." ::= { vdslLineConfProfileEntry 46 } -- -- Alarm configuration profile table -- vdslLineAlarmConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the VDSL line alarm configuration. One entry in this table reflects a profile defined by a manager which can be used to configure the VDSL line alarm thresholds. Ray & Abbi Standards Track [Page 59] RFC 3728 VDSL-LINE MIB February 2004 Entries in this table MUST be maintained in a persistent manner." ::= { vdslMibObjects 20 } vdslLineAlarmConfProfileEntry OBJECT-TYPE SYNTAX VdslLineAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of a VDSL line alarm profile. A default profile with an index of 'DEFVAL', will always exist and its parameters will be set to vendor specific values, unless otherwise specified in this document." INDEX { vdslLineAlarmConfProfileName } ::= { vdslLineAlarmConfProfileTable 1 } VdslLineAlarmConfProfileEntry ::= SEQUENCE { vdslLineAlarmConfProfileName SnmpAdminString, vdslLineAlarmConfThresh15MinLofs HCPerfIntervalThreshold, vdslLineAlarmConfThresh15MinLoss HCPerfIntervalThreshold, vdslLineAlarmConfThresh15MinLprs HCPerfIntervalThreshold, vdslLineAlarmConfThresh15MinLols HCPerfIntervalThreshold, vdslLineAlarmConfThresh15MinESs HCPerfIntervalThreshold, vdslLineAlarmConfThresh15MinSESs HCPerfIntervalThreshold, vdslLineAlarmConfThresh15MinUASs HCPerfIntervalThreshold, vdslLineAlarmConfInitFailure TruthValue, vdslLineAlarmConfProfRowStatus RowStatus } vdslLineAlarmConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name for this profile as specified by an administrator." ::= { vdslLineAlarmConfProfileEntry 1 } vdslLineAlarmConfThresh15MinLofs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create Ray & Abbi Standards Track [Page 60] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "This object configures the threshold for the number of loss of frame seconds (lofs) within any given 15-minute performance data collection interval. If the value of loss of frame seconds in a particular 15-minute collection interval reaches/exceeds this value, a vdslPerfLofsThreshNotification notification will be generated. No more than one notification will be sent per interval." DEFVAL { 0 } ::= { vdslLineAlarmConfProfileEntry 2 } vdslLineAlarmConfThresh15MinLoss OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of loss of signal seconds (loss) within any given 15-minute performance data collection interval. If the value of loss of signal seconds in a particular 15-minute collection interval reaches/exceeds this value, a vdslPerfLossThreshNotification notification will be generated. One notification will be sent per interval per endpoint." DEFVAL { 0 } ::= { vdslLineAlarmConfProfileEntry 3 } vdslLineAlarmConfThresh15MinLprs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of loss of power seconds (lprs) within any given 15-minute performance data collection interval. If the value of loss of power seconds in a particular 15-minute collection interval reaches/exceeds this value, a vdslPerfLprsThreshNotification notification will be generated. No more than one notification will be sent per interval." DEFVAL { 0 } ::= { vdslLineAlarmConfProfileEntry 4 } vdslLineAlarmConfThresh15MinLols OBJECT-TYPE Ray & Abbi Standards Track [Page 61] RFC 3728 VDSL-LINE MIB February 2004 SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of loss of link seconds (lols) within any given 15-minute performance data collection interval. If the value of loss of power seconds in a particular 15-minute collection interval reaches/exceeds this value, a vdslPerfLolsThreshNotification notification will be generated. No more than one notification will be sent per interval." DEFVAL { 0 } ::= { vdslLineAlarmConfProfileEntry 5 } vdslLineAlarmConfThresh15MinESs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of errored seconds (ESs) within any given 15-minute performance data collection interval. If the value of errored seconds in a particular 15-minute collection interval reaches/exceeds this value, a vdslPerfESsThreshNotification notification will be generated. No more than one notification will be sent per interval." DEFVAL { 0 } ::= { vdslLineAlarmConfProfileEntry 6 } vdslLineAlarmConfThresh15MinSESs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of severely errored seconds (SESs) within any given 15-minute performance data collection interval. If the value of severely errored seconds in a particular 15-minute collection interval reaches/exceeds this value, a vdslPerfSESsThreshNotification notification will be generated. No more than one notification will be sent per interval." DEFVAL { 0 } Ray & Abbi Standards Track [Page 62] RFC 3728 VDSL-LINE MIB February 2004 ::= { vdslLineAlarmConfProfileEntry 7 } vdslLineAlarmConfThresh15MinUASs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of unavailable seconds (UASs) within any given 15-minute performance data collection interval. If the value of unavailable seconds in a particular 15-minute collection interval reaches/exceeds this value, a vdslPerfUASsThreshNotification notification will be generated. No more than one notification will be sent per interval." DEFVAL { 0 } ::= { vdslLineAlarmConfProfileEntry 8 } vdslLineAlarmConfInitFailure OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies if a vdslInitFailureNotification notification will be generated if an initialization failure occurs." DEFVAL { false } ::= { vdslLineAlarmConfProfileEntry 9 } vdslLineAlarmConfProfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile activated by setting this object to 'active'. When 'active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service, (by setting this object to 'destroy' or 'outOfService') it must be first unreferenced from all associated lines. An 'active' profile may be modified at any time." ::= { vdslLineAlarmConfProfileEntry 10 } Ray & Abbi Standards Track [Page 63] RFC 3728 VDSL-LINE MIB February 2004 -- Notification definitions vdslNotifications OBJECT IDENTIFIER ::= { vdslLineMib 0 } vdslPerfLofsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfDataCurr15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold (vdslLineAlarmConfThresh15MinLofs) reached." ::= { vdslNotifications 1 } vdslPerfLossThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfDataCurr15MinLoss } STATUS current DESCRIPTION "Loss of Signal 15-minute interval threshold (vdslLineAlarmConfThresh15MinLoss) reached." ::= { vdslNotifications 2 } vdslPerfLprsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfDataCurr15MinLprs } STATUS current DESCRIPTION "Loss of Power 15-minute interval threshold (vdslLineAlarmConfThresh15MinLprs) reached." ::= { vdslNotifications 3 } vdslPerfLolsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfDataCurr15MinLols } STATUS current DESCRIPTION "Loss of Link 15-minute interval threshold (vdslLineAlarmConfThresh15MinLols) reached." ::= { vdslNotifications 4 } vdslPerfESsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfDataCurr15MinESs } Ray & Abbi Standards Track [Page 64] RFC 3728 VDSL-LINE MIB February 2004 STATUS current DESCRIPTION "Errored Seconds 15-minute interval threshold (vdslLineAlarmConfThresh15MinESs) reached." ::= { vdslNotifications 5 } vdslPerfSESsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfDataCurr15MinSESs } STATUS current DESCRIPTION "Severely Errored Seconds 15-minute interval threshold (vdslLineAlarmConfThresh15MinSESs) reached." ::= { vdslNotifications 6 } vdslPerfUASsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfDataCurr15MinUASs } STATUS current DESCRIPTION "Unavailable Seconds 15-minute interval threshold (vdslLineAlarmConfThresh15MinUASs) reached." ::= { vdslNotifications 7 } vdslDownMaxSnrMgnNotification NOTIFICATION-TYPE OBJECTS { vdslPhysCurrSnrMgn } STATUS current DESCRIPTION "The downstream Signal to Noise Margin exceeded vdslLineConfDownMaxSnrMgn. The object vdslPhysCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-R." ::= { vdslNotifications 8 } vdslDownMinSnrMgnNotification NOTIFICATION-TYPE OBJECTS { vdslPhysCurrSnrMgn } STATUS current DESCRIPTION "The downstream Signal to Noise Margin fell below vdslLineConfDownMinSnrMgn. The object vdslPhysCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-R." Ray & Abbi Standards Track [Page 65] RFC 3728 VDSL-LINE MIB February 2004 ::= { vdslNotifications 9 } vdslUpMaxSnrMgnNotification NOTIFICATION-TYPE OBJECTS { vdslPhysCurrSnrMgn } STATUS current DESCRIPTION "The upstream Signal to Noise Margin exceeded vdslLineConfUpMaxSnrMgn. The object vdslPhysCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-C." ::= { vdslNotifications 10 } vdslUpMinSnrMgnNotification NOTIFICATION-TYPE OBJECTS { vdslPhysCurrSnrMgn } STATUS current DESCRIPTION "The upstream Signal to Noise Margin fell below vdslLineConfUpMinSnrMgn. The object vdslPhysCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-C." ::= { vdslNotifications 11 } vdslInitFailureNotification NOTIFICATION-TYPE OBJECTS { vdslPhysCurrStatus } STATUS current DESCRIPTION "Vtu initialization failed. See vdslPhysCurrStatus for potential reasons." ::= { vdslNotifications 12 } -- conformance information vdslConformance OBJECT IDENTIFIER ::= { vdslLineMib 3 } vdslGroups OBJECT IDENTIFIER ::= { vdslConformance 1 } vdslCompliances OBJECT IDENTIFIER ::= { vdslConformance 2 } vdslLineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which manage VDSL interfaces." Ray & Abbi Standards Track [Page 66] RFC 3728 VDSL-LINE MIB February 2004 MODULE -- this module MANDATORY-GROUPS { vdslGroup, vdslNotificationGroup } ::= { vdslCompliances 1 } -- units of conformance vdslGroup OBJECT-GROUP OBJECTS { vdslLineCoding, vdslLineType, vdslLineConfProfile, vdslLineAlarmConfProfile, vdslPhysInvSerialNumber, vdslPhysInvVendorID, vdslPhysInvVersionNumber, vdslPhysCurrSnrMgn, vdslPhysCurrAtn, vdslPhysCurrStatus, vdslPhysCurrOutputPwr, vdslPhysCurrAttainableRate, vdslPhysCurrLineRate, vdslChanInterleaveDelay, vdslChanCrcBlockLength, vdslChanCurrTxRate, vdslChanCurrTxSlowBurstProtect, vdslChanCurrTxFastFec, vdslPerfDataValidIntervals, vdslPerfDataInvalidIntervals, vdslPerfDataLofs, vdslPerfDataLoss, vdslPerfDataLprs, vdslPerfDataLols, vdslPerfDataESs, vdslPerfDataSESs, vdslPerfDataUASs, vdslPerfDataInits, vdslPerfDataCurr15MinTimeElapsed, vdslPerfDataCurr15MinLofs, vdslPerfDataCurr15MinLoss, vdslPerfDataCurr15MinLprs, vdslPerfDataCurr15MinLols, vdslPerfDataCurr15MinESs, vdslPerfDataCurr15MinSESs, Ray & Abbi Standards Track [Page 67] RFC 3728 VDSL-LINE MIB February 2004 vdslPerfDataCurr15MinUASs, vdslPerfDataCurr15MinInits, vdslPerfData1DayValidIntervals, vdslPerfData1DayInvalidIntervals, vdslPerfDataCurr1DayTimeElapsed, vdslPerfDataCurr1DayLofs, vdslPerfDataCurr1DayLoss, vdslPerfDataCurr1DayLprs, vdslPerfDataCurr1DayLols, vdslPerfDataCurr1DayESs, vdslPerfDataCurr1DaySESs, vdslPerfDataCurr1DayUASs, vdslPerfDataCurr1DayInits, vdslPerfIntervalLofs, vdslPerfIntervalLoss, vdslPerfIntervalLprs, vdslPerfIntervalLols, vdslPerfIntervalESs, vdslPerfIntervalSESs, vdslPerfIntervalUASs, vdslPerfIntervalInits, vdslPerf1DayIntervalMoniSecs, vdslPerf1DayIntervalLofs, vdslPerf1DayIntervalLoss, vdslPerf1DayIntervalLprs, vdslPerf1DayIntervalLols, vdslPerf1DayIntervalESs, vdslPerf1DayIntervalSESs, vdslPerf1DayIntervalUASs, vdslPerf1DayIntervalInits, vdslChanValidIntervals, vdslChanInvalidIntervals, vdslChanFixedOctets, vdslChanBadBlks, vdslChanCurr15MinTimeElapsed, vdslChanCurr15MinFixedOctets, vdslChanCurr15MinBadBlks, vdslChan1DayValidIntervals, vdslChan1DayInvalidIntervals, vdslChanCurr1DayTimeElapsed, vdslChanCurr1DayFixedOctets, vdslChanCurr1DayBadBlks, vdslChanIntervalFixedOctets, vdslChanIntervalBadBlks, vdslChan1DayIntervalMoniSecs, vdslChan1DayIntervalFixedOctets, vdslChan1DayIntervalBadBlks, vdslLineConfDownRateMode, Ray & Abbi Standards Track [Page 68] RFC 3728 VDSL-LINE MIB February 2004 vdslLineConfUpRateMode, vdslLineConfDownMaxPwr, vdslLineConfUpMaxPwr, vdslLineConfDownMaxSnrMgn, vdslLineConfDownMinSnrMgn, vdslLineConfDownTargetSnrMgn, vdslLineConfUpMaxSnrMgn, vdslLineConfUpMinSnrMgn, vdslLineConfUpTargetSnrMgn, vdslLineConfDownFastMaxDataRate, vdslLineConfDownFastMinDataRate, vdslLineConfDownSlowMaxDataRate, vdslLineConfDownSlowMinDataRate, vdslLineConfUpFastMaxDataRate, vdslLineConfUpFastMinDataRate, vdslLineConfUpSlowMaxDataRate, vdslLineConfUpSlowMinDataRate, vdslLineConfDownRateRatio, vdslLineConfUpRateRatio, vdslLineConfDownMaxInterDelay, vdslLineConfUpMaxInterDelay, vdslLineConfDownPboControl, vdslLineConfUpPboControl, vdslLineConfDownPboLevel, vdslLineConfUpPboLevel, vdslLineConfDeploymentScenario, vdslLineConfAdslPresence, vdslLineConfApplicableStandard, vdslLineConfBandPlan, vdslLineConfBandPlanFx, vdslLineConfBandOptUsage, vdslLineConfUpPsdTemplate, vdslLineConfDownPsdTemplate, vdslLineConfHamBandMask, vdslLineConfCustomNotch1Start, vdslLineConfCustomNotch1Stop, vdslLineConfCustomNotch2Start, vdslLineConfCustomNotch2Stop, vdslLineConfDownTargetSlowBurst, vdslLineConfUpTargetSlowBurst, vdslLineConfDownMaxFastFec, vdslLineConfUpMaxFastFec, vdslLineConfLineType, vdslLineConfProfRowStatus, vdslLineAlarmConfThresh15MinLofs, vdslLineAlarmConfThresh15MinLoss, vdslLineAlarmConfThresh15MinLprs, vdslLineAlarmConfThresh15MinLols, Ray & Abbi Standards Track [Page 69] RFC 3728 VDSL-LINE MIB February 2004 vdslLineAlarmConfThresh15MinESs, vdslLineAlarmConfThresh15MinSESs, vdslLineAlarmConfThresh15MinUASs, vdslLineAlarmConfInitFailure, vdslLineAlarmConfProfRowStatus } STATUS current DESCRIPTION "A collection of objects providing information about a VDSL Line." ::= { vdslGroups 1 } vdslNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { vdslPerfLofsThreshNotification, vdslPerfLossThreshNotification, vdslPerfLprsThreshNotification, vdslPerfLolsThreshNotification, vdslPerfESsThreshNotification, vdslPerfSESsThreshNotification, vdslPerfUASsThreshNotification, vdslDownMaxSnrMgnNotification, vdslDownMinSnrMgnNotification, vdslUpMaxSnrMgnNotification, vdslUpMinSnrMgnNotification, vdslInitFailureNotification } STATUS current DESCRIPTION "This group supports notifications of significant conditions associated with VDSL Lines." ::= { vdslGroups 2 } END Ray & Abbi Standards Track [Page 70] RFC 3728 VDSL-LINE MIB February 2004 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. VDSL layer connectivity from the Vtur will permit the subscriber to manipulate both the VDSL link directly and the VDSL embedded operations channel (EOC) for their own loop. For example, unchecked or unfiltered fluctuations initiated by the subscriber could generate sufficient notifications to potentially overwhelm either the management interface to the network or the element manager. Additionally, allowing write access to configuration data may allow an end-user to increase their service levels or affect other end- users in either a positive or negative manner. For this reason, the following tables should be considered to contain sensitive information: - vdslLineTable - vdslLineConfProfileTable - vdslLineAlarmConfProfileTable Individual line utilization information, available via the performance tables, may be considered sensitive. For example, if an end-user has a far lower line utilization during certain periods of the day, it may indicate an empty office or residence. For these reasons, the following tables should be considered to contain sensitive information: - vdslPerfDataTable - vdslPerfIntervalTable - vdslPerf1DayIntervalTable Further, notifications generated by agents implementing this MIB will contain threshold and performance information. Ray & Abbi Standards Track [Page 71] RFC 3728 VDSL-LINE MIB February 2004 It is thus important to control even GET access to the objects within these tables and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. References 6.1. Normative References [DSLFTR057] DSL Forum TR-057, "VDSL Network Element Management", February 2003. [ETSI2701] ETSI TS 101 270-1 V1.2.1 "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements", October 1999. [ETSI2702] ETSI TS 101 270-2 V1.1.1 "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Transceiver specification", February 2001. [ITU9931] ITU-T G.993.1 "Very-high-speed digital subscriber line foundation", November 2001. [ITU9971] ITU-T G.997.1 "Physical layer management for Digital Subscriber Line (DSL) Transceivers", July 1999. Ray & Abbi Standards Track [Page 72] RFC 3728 VDSL-LINE MIB February 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2856] Bierman, A., McCloghrie, K. and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, February 2004. [T1E1311] ANSI T1E1.4/2001-311, "Very-high-bit-rate Digital Subscriber Line (VDSL) Metallic Interface, Part 1: Functional Requirements and Common Specification", February 2001. [T1E1011] ANSI T1E1.4/2001-011R3, "VDSL Metallic Interface, Part 2: Technical Specification for a Single-Carrier Modulation (SCM) Transceiver", November 2001. Ray & Abbi Standards Track [Page 73] RFC 3728 VDSL-LINE MIB February 2004 [T1E1013] ANSI T1E1.4/2001-013R4, "VDSL Metallic Interface, Part 3: Technical Specification for a Multi-Carrier Modulation (MCM) Transceiver", November 2000. 6.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. 7. Acknowledgements Greg Bathrick (Texas Instruments) Umberto Bonollo (NEC) Andrew Cheers (NEC) Felix Flemisch (Siemens) David Horton (CiTR) Travis Levin (Paradyne) Moti Morgenstern (Inovia) Randy Presuhn (BMC) Say Sabit (NLC) Bert Wijnen (Lucent) Ray & Abbi Standards Track [Page 74] RFC 3728 VDSL-LINE MIB February 2004 8. Authors' Addresses Bob Ray PESA Switching Systems, Inc. 330-A Wynn Drive Huntsville, AL 35805 USA Phone: +1 256 726 9200 ext. 142 Fax: +1 256 726 9271 EMail: rray@pesa.com Rajesh Abbi Alcatel USA 2301 Sugar Bush Road Raleigh, NC 27612-3339 USA Phone: +1 919 850 6194 EMail: Rajesh.Abbi@alcatel.com Ray & Abbi Standards Track [Page 75] RFC 3728 VDSL-LINE MIB February 2004 9. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ray & Abbi Standards Track [Page 76] snmp-mibs-downloader-1.1/mibrfcs/rfc3729.txt0000644000000000000000000040043311402176071015572 0ustar Network Working Group S. Waldbusser Request for Comments: 3729 March 2004 Category: Standards Track Application Performance Measurement MIB 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for measuring the application performance as experienced by end-users. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Report Aggregation . . . . . . . . . . . . . . . . . . . 4 2.2. AppLocalIndex Linkages . . . . . . . . . . . . . . . . . 8 2.3. Measurement Methodology. . . . . . . . . . . . . . . . . 10 2.4. Instrumentation Architectures. . . . . . . . . . . . . . 10 2.4.1. Application Directory Caching. . . . . . . . . . 10 2.4.2. Push Model . . . . . . . . . . . . . . . . . . . 11 2.5. Structure of this MIB Module . . . . . . . . . . . . . . 12 2.5.1. The APM Application Directory Group. . . . . . . 13 2.5.2. The APM User Defined Applications Group. . . . . 13 2.5.3. The APM Report Group . . . . . . . . . . . . . . 13 2.5.4. The APM Transaction Group. . . . . . . . . . . . 13 2.5.5. The APM Exception Group. . . . . . . . . . . . . 14 2.5.6. The APM Notification Group . . . . . . . . . . . 14 3. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 60 5.2. Informative References . . . . . . . . . . . . . . . . . 60 Waldbusser Standards Track [Page 1] RFC 3729 APM MIB March 2004 6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 60 7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 61 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [8]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3]. 2. Overview This document continues the architecture created in the RMON MIB [7] by providing analysis of application performance as experienced by end-users. Application performance measurement measures the quality of service delivered to end-users by applications. With this perspective, a true end-to-end view of the IT infrastructure results, combining the performance of the application, desktop, network, and server, as well as any positive or negative interactions between these components. Despite all the technically sophisticated ways in which networking and system resources can be measured, human end-users perceive only two things about an application: availability and responsiveness. Availability - The percentage of the time that the application is ready to give a user service. Responsiveness - The speed at which the application delivers the requested service. A transaction is an action initiated by a user that starts and completes a distributed processing function. A transaction begins when a user initiates a request for service (i.e., pushing a submit button) and ends when the work is completed (i.e., information is provided or a confirmation is delivered). A transaction is the fundamental item measured by the APM MIB. Waldbusser Standards Track [Page 2] RFC 3729 APM MIB March 2004 A failed transaction is a transaction that fails to provide the service requested by the end user, regardless of whether it is due to a processing failure or transport failure. An application protocol (e.g., POP3) may implement different commands or application "verbs" (e.g., POP3 Login and POP3 Retrieval). It will often be interesting to monitor these verbs separately because: 1) The verbs may have widely differing performance characteristics (in fact some may be response time oriented while others are throughput oriented) 2) The verbs have varying business significance 3) It provides more granularity of exactly what might be performing poorly This MIB Module allows the measurement of a parent application, its component verbs, or both. If monitoring both, one can watch the top-level application and then drill down to the verbs when trouble is spotted to learn which subcomponents are in trouble. Each application verb is registered separately in the Protocol Directory [5] [6] as a child of its parent application. Application protocols implement one of three different types of transactions: transaction-oriented, throughput-oriented, or streaming-oriented. While the availability metric is the same for all three types, the responsiveness metric varies: Transaction-Oriented: These transactions have a fairly constant workload to perform for all transactions. In particular, to the degree that the workload may vary, it doesn't vary based on the amount of data to be transferred but based on the parameters of the transaction. The responsiveness metric for transaction- oriented applications is application response time, the elapsed time between the user's request for service (e.g., pushing the submit button) and the completion of the request (e.g., displaying the results) and is measured in milliseconds. This is commonly referred to as end-user response time. Throughput-Oriented: These transactions have widely varying workloads based on the amount of data requested. The responsiveness metric for throughput-oriented applications is kilobits per second. Streaming-Oriented: These transactions deliver data at a constant metered rate of speed regardless of excess capacity in the networking and computing infrastructure. However, when the infrastructures cannot deliver data at this speed, interruption of service or degradation of service can result. The responsiveness Waldbusser Standards Track [Page 3] RFC 3729 APM MIB March 2004 metric for streaming-oriented applications is the signal quality ratio of time that the service is degraded or interrupted to the total service time. This metric is measured in parts per million. 2.1. Report Aggregation This MIB Module provides functions to aggregate measurements into higher level summaries. Every transaction is identified by its application, server, and client and has an availability measure as well as a responsiveness measure. The appropriate responsiveness measure is context-sensitive depending on whether the application is transaction-oriented, throughput-oriented, or streaming- oriented. For example, in a 5 minute period several transactions might be recorded: Application Client Server Successful Responsiveness HTTP Jim Sales 1 6 sec. SAP/R3 Jane Finance 1 17 sec. HTTP Joe HR 0 - FTP Jim FTP 1 212 Kbps HTTP Joe HR 1 25 sec. RealVideo Joe Videoconf 1 100.0% HTTP Jane HR 1 5 sec. These transactions can be aggregated in several ways, providing statistical summaries - for example summarizing all HTTP transactions, or all HTTP transactions to the HR Server. Note that data from different applications may not be summarized because: 1. The performance characteristics of different applications differ widely enough to render statistical analysis meaningless. 2. The responsiveness metrics of different applications may be different, making a statistical analysis impossible (in other words, one application may be transaction-oriented, while another is throughput-oriented). Aggregating transactions collected over a period requires an aggregation algorithm. In this MIB Module, transaction aggregation always results in the following statistics: TransactionCount The total number of transactions during this period Waldbusser Standards Track [Page 4] RFC 3729 APM MIB March 2004 SuccessfulTransactions The total number of transactions that were successful. The management station can derive the percent success by dividing SuccessfulTransactions by the TransactionCount. ResponsivenessMean The average of the responsiveness metric for all aggregated transactions that completed successfully. ResponsivenessMin The minimum responsiveness metric for all aggregated transactions that completed successfully. ResponsivenessMax The maximum responsiveness metric for all aggregated transactions that completed successfully. ResponsivenessBx The count of successful transactions whose responsiveness metric fell into the range specified for Bx. There are 7 buckets specified. Because the performance of different applications varies widely, the bucket ranges are specified separately for each application (in the apmAppDirTable) so that they may be tuned to typical performance of each application. For example, when aggregating the previous set of transactions by application we get (for simplicity the example only shows TransactionCount, SuccessfulTransactions, and ResponsivenessMean): Application Count Successful ResponsivenessMean HTTP 4 3 12 sec. SAP/R3 1 1 17 sec. FTP 1 1 212 Kbps. RealVideo 1 1 100.0% There are four different types of aggregation. The flows(1) aggregation is the simplest. All transactions that share common application/server/client 3-tuples are aggregated together, resulting in a set of metrics for all such unique 3- tuples. The clients(2) aggregation results in somewhat more aggregation (i.e., fewer resulting records). All transactions that share common application/client tuples are aggregated together, resulting in a set of metrics for all such unique tuples. Waldbusser Standards Track [Page 5] RFC 3729 APM MIB March 2004 The servers(3) aggregation usually results in still more aggregation (i.e., fewer resulting records). All transactions that share common application/server tuples are aggregated together, resulting in a set of metrics for all such unique tuples. The applications(4) aggregation results in the most aggregation (i.e., the fewest resulting records). All transactions that share a common application are aggregated together, resulting in a set of metrics for all such unique applications. For example, if in a 5 minute period the following transactions occurred: Actual Transactions: # App Client Server Successful Responsiveness 1 HTTP Jim CallCtr N - 2 HTTP Jim HR Y 12 sec. 3 HTTP Jim Sales Y 7 sec. 4 HTTP Jim CallCtr Y 5 sec. 5 Email Jim Pop3 Y 12 sec. 6 HTTP Jane CallCtr Y 3 sec. 7 SAP/R3 Jane Finance Y 19 sec. 8 Email Jane Pop3 Y 16 sec. 9 HTTP Joe HR Y 18 sec. The flows(1) aggregation results in the following table. Note that the first record (HTTP/Jim/CallCtr) is the aggregation of transactions #1 and #4: Flow Aggregation: App Client Server Count Succe- Rsp Rsp Rsp RspB1 RspB2 ssful Mean Min Max HTTP Jim CallCtr 2 1 5 5 5 1 0 HTTP Jim HR 1 1 12 12 12 0 1 HTTP Jim Sales 1 1 7 7 7 1 0 Email Jim Pop3 1 1 12 12 12 0 1 HTTP Jane CallCtr 1 1 3 3 3 1 0 SAP/R3 Jane Finance 1 1 19 19 19 0 1 Email Jane Pop3 1 1 16 16 16 0 1 HTTP Joe HR 1 1 18 18 18 0 1 (Note: Columns above such as RspMean and RspB1 are abbreviations for objects in the apmReportTable) The clients(2) aggregation results in the following table. Note that the first record (HTTP/Jim) is the aggregate of transactions #1, #2, #3 and #4: Waldbusser Standards Track [Page 6] RFC 3729 APM MIB March 2004 Client Aggregation: App Client Count Succe- Rsp Rsp Rsp RspB1 RspB2 ... ssful Mean Min Max HTTP Jim 4 3 8 5 12 2 1 Email Jim 1 1 12 12 12 0 1 HTTP Jane 1 1 3 3 3 1 0 SAP/R3 Jane 1 1 19 19 19 0 1 Email Jane 1 1 16 16 16 0 1 HTTP Joe 1 1 18 18 18 0 1 The servers(3) aggregation results in the following table. Note that the first record (HTTP/CallCtr) is the aggregation of transactions #1, #4 and #6: Server Aggregation: App Server Count Succe- Rsp Rsp Rsp RspB1 RspB2 ... ssful Mean Min Max HTTP CallCtr 3 2 4 3 5 2 0 HTTP HR 2 2 15 12 18 0 2 HTTP Sales 1 1 7 7 7 1 0 Email Pop3 2 2 14 12 16 0 2 SAP/R3 Finance 1 1 19 19 19 0 1 The applications(4) aggregation results in the following table. Note that the first record (HTTP) is the aggregate of transactions #1, #2, #3, #5, #6 and #9: Application Aggregation: App Count Succe- Rsp Rsp Rsp RspB1 RspB2 ... ssful Mean Min Max HTTP 6 5 9 3 18 3 2 Email 2 2 14 12 16 0 2 SAP/R3 1 1 19 19 19 0 1 The apmReportControlTable provides for a historical set of the last 'X' reports, combining the historical records found in history tables with the periodic snapshots found in TopN tables. Conceptually the components are: apmReportControlTable Specifies data collection and summarization parameters, including the number of reports to keep and the size of each report. apmReport Each APM Report contains an aggregated list of records that represent data collected during a specific time period. Waldbusser Standards Track [Page 7] RFC 3729 APM MIB March 2004 An apmReportControlEntry causes a family of APM Reports to be created, where each report summarizes different, successive, contiguous periods of time. While the conceptual model of APM Reports shows them as distinct entities, they are all entries in a single apmReportTable, where entries in report 'A' are separated from entries in report 'B' by different values of the apmReportIndex. +-----------------------+ | | | apmReportControlTable | | | +-----------+ +-----------------------+ | | +-----------+ | | | | +-----------+ |---+ | | | +----------+ |---+ | | | apmReport |apmReport |----+ +-----------------------+ | | |Thu Mar 30 12-1PM | +----------+ | | |CLNT SERV PROT stats | | | |Joe News HTTP data | |Jan POP POP3 data | |Jan POP SMTP data | |Bob HR PSOFT data | |... | |... | +-----------------------+ 2.2. AppLocalIndex Linkages The following set of example tables illustrates a few points: 1. How protocolDirEntries, apmHttpFilterEntries and apmUserDefinedAppEntries(not shown) all result in entries in the apmAppDirTable. 2. How a single appLocalIndex may be represented multiple times in the apmAppDirTable and apmReportTable if the agent measures multiple responsiveness types for that application. A convention in the formatting of these tables is that the columns to the left of the '|' separator are index columns for the table. Waldbusser Standards Track [Page 8] RFC 3729 APM MIB March 2004 Assuming the following entries in the RMON2 protocolDirectory: protocolDirectory ID (*) Parameters | LocalIndex ... WWW None | 1 WWW Get None | 2 SAP/R3 None | 3 (*) These IDs are represented here symbolically. Consult [5] for more detail in their format and the following entry in the apmHttpFilterTable: ApmHttpFilterTable Index | AppLocalIndex ServerAddress URLPath MatchType ... 5 | 20 hr.example.com /expense prefix(3) ... the apmAppDirTable would be populated with the following entries: apmAppDir AppLocalIndex ResponsivenessType | Config ... 1 transaction(1) | On ... 1 throughput(2) | On ... 2 transaction(1) | On ... 2 throughput(2) | On ... 3 transaction(1) | On ... 20 transaction(1) | On ... 20 throughput(2) | On ... The entries in the apmAppDirTable with an appLocalIndex of 1, 2 and 3 correspond to the identically named entries in the protocolDirectory table. appLocalIndex #1 results in 2 entries, one to measure the transaction responsiveness of WWW and one to measure its throughput responsiveness. In contrast, appLocalIndex #3 results in only a transaction entry because the agent does not measure the throughput responsiveness for SAP/R3 (probably because it isn't very meaningful). Finally, appLocalIndex #20 corresponds to the entry in the apmHttpFilterTable and has transaction responsiveness and throughput responsiveness measurements available. If a report was configured using application aggregation, entries in that report might look like: Waldbusser Standards Track [Page 9] RFC 3729 APM MIB March 2004 apmReportTable CtlIndex Index AppLocalIdx ResponsivenessType | TransactionCount ... 1 1 1 transaction(1) | counters... 1 1 1 throughput(2) | counters... 1 1 2 transaction(1) | counters... 1 1 2 throughput(2) | counters... 1 1 3 transaction(1) | counters... 1 1 20 transaction(1) | counters... 1 1 20 throughput(2) | counters... Note that the index items protocolDirLocalIndex, apmReportServerAddress and apmReportClientID were omitted from apmReportTable example for brevity because they would have been equal to zero due to the use of the application aggregation in this example. 2.3. Measurement Methodology There are many different measurement methodologies available for measuring application performance (e.g., probe-based, client-based, synthetic-transaction, etc.). This specification does not mandate a particular methodology - it is open to any that meet the minimum requirements. Conformance to this specification requires that the collected data match the semantics described herein. In particular, a data collection methodology must be able to measure response time, throughput, streaming responsiveness and availability as specified. Note that in some cases a transaction may run for a long time but ultimately be successful. The measurement software shouldn't prematurely classify lengthy transactions as failures but should wait as long as the client application will wait for a successful response. 2.4. Instrumentation Architectures Different architectural approaches and deployment strategies may be taken towards implementation of this specification. If a highly distributed approach is desired (e.g., an agent per desktop), one or both of the two approaches below may be used to make it more practical. 2.4.1. Application Directory Caching It is necessary for the manager to have a copy of the tables that define the Application Directory in order to interpret APM measurements. It is likely that in a highly distributed network of Waldbusser Standards Track [Page 10] RFC 3729 APM MIB March 2004 thousands of APM agents, this Application Directory will be the same on many, if not all of the agents. Repeated downloads of the Application Directory may be inefficient. The apmAppDirID object is a single object that identifies the configuration of all aspects of the Application Directory when it is equal to a well-known, registered configuration. Thus, when a manager sees an apmAppDirID value that it recognizes, it need not download the Application Directory from that agent. In fact, the manager may discover a new registered Application Directory configuration on one agent and then re-use that configuration on another agent that shares the same apmAppDirID value. Application directory registrations are unique within an administrative domain, allowing an administrator to create a custom application directory configuration without the need to assign it a globally-unique registration. 2.4.2. Push Model When APM agents are installed on "desktops" (including laptops), a few issues make polling difficult: 1. Desktops often have dynamically-assigned addresses so there is no long-lived address to poll. 2. Desktops are not available as much as infrastructure components due to crashes, user-initiated reboots and shutdowns and user control over monitoring software. Thus a desktop may not be available to answer a poll at the moment when the manager is scheduled to poll that desktop. 3. Laptops that are connected via dialup connections are only sporadically connected and will routinely be unreachable when the manager is scheduled to poll. As a consequence, a push model is usually more appropriate for desktop-based agents. To achieve this, the agent should follow the following rules in deciding what data to send in notifications. Waldbusser Standards Track [Page 11] RFC 3729 APM MIB March 2004 APM Reports If an agent wishes to push APM reports to a manager, it must send: apmAppDirID apmNameTable (any data updated since the last push) For each report the agent wishes to upload, it must send the entire apmReportControlEntry associated with that report and the associated entries in the apmReportTable that have changed since the last report. APM Transactions If an agent wishes to push APM transactions to a manager, it must send: apmAppDirID apmNameTable (any data updated since the last push) apmTransactionTable (relevant entries) APM Exceptions The agent must send: apmAppDirID apmNameTable (any data updated since the last push) apmTransactionEntry (of exception transaction) apmExceptionEntry (entry that generated exception) [Note that this list supersedes the information in the OBJECTS clauses of the apmTransactionResponsivenessAlarm and apmTransactionUnsuccessfulAlarm when the agent is using a push model. This additional information eliminates the need for the manager to request additional data to understand the exception.] The order of varbinds and where to segment varbinds into PDUs is at the discretion of the agent. 2.5. Structure of this MIB Module The objects are arranged into the following groups: - APM Application Directory Group - APM User Defined Applications Group - APM Report Group - APM Transaction Group - APM Exception Group - APM Notification Group Waldbusser Standards Track [Page 12] RFC 3729 APM MIB March 2004 These groups are the basic unit of conformance. If an agent implements a group, then it must implement all objects in that group. While this section provides an overview of grouping and conformance information for this MIB Module, the authoritative reference for such information is contained in the MODULE-COMPLIANCE and OBJECT-GROUP macros later in this MIB Module. These groups are defined to provide a means of assigning object identifiers, and to provide a method for implementors of managed agents to know which objects they must implement. 2.5.1. The APM Application Directory Group The APM Application Directory group contains configuration objects for every application or application verb monitored on this system. This group consists of the apmAppDirTable. 2.5.2. The APM User Defined Applications Group The APM User Defined Applications Group contains objects that allow for the tracking of applications or application verbs that aren't registered in the protocolDirTable. This group consists of the apmHttpFilterTable and the apmUserDefinedAppTable. 2.5.3. The APM Report Group The APM Report Group is used to prepare regular reports that aggregate application performance by flow, by client, by server, or by application. This group consists of the apmReportControlTable and the apmReportTable. 2.5.4. The APM Transaction Group The APM Transaction Group is used to show transactions that are currently in progress and ones that have ended recently, along with their responsiveness metric. Because many transactions last a very short time and because an agent may not retain completed transactions very long, transactions may exist in this table for a very short time. Thus, polling this table isn't an effective mechanism for retrieving all transactions unless the value of apmTransactionsHistorySize is suitably large for the transactions being monitored. One important benefit of this table is that it allows a management station to check on the status of long-lived transactions. Because the apmReport and apmException mechanisms act only on transactions that have finished, a network manager may not have visibility for Waldbusser Standards Track [Page 13] RFC 3729 APM MIB March 2004 some time into the performance of long-lived transactions such as streaming applications, large data transfers, or (very) poorly performing transactions. In fact, by their very definition, the apmReport and apmException mechanisms only provide visibility into a problem after nothing can be done about it. This group consists primarily of the apmTransactionTable. 2.5.5. The APM Exception Group The APM Exception Group is used to generate immediate notifications of transactions that cross certain thresholds. The apmExceptionTable is used to configure which thresholds are to be checked for which types of transactions. The apmTransactionResponsivenessAlarm notification is sent when a transaction occurs with a responsiveness that crosses a threshold. The apmTransactionUnsuccessfulAlarm notification is sent when a transaction fails for which exception checking was configured. This group consists primarily of the apmExceptionTable. 2.5.6. The APM Notification Group The APM Notification Group contains 2 notifications that are sent when thresholds in the APM Exception Table are exceeded. 3. Definitions APM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, TimeInterval, TruthValue, DateAndTime, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB rmon, OwnerString FROM RMON-MIB protocolDirLocalIndex FROM RMON2-MIB; -- Application Performance Measurement MIB apm MODULE-IDENTITY LAST-UPDATED "200402190000Z" -- February 19, 2004 ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "Author: Steve Waldbusser Waldbusser Standards Track [Page 14] RFC 3729 APM MIB March 2004 Phone: +1-650-948-6500 Fax : +1-650-745-0671 Email: waldbusser@nextbeacon.com Working Group Chair: Andy Bierman Cisco Systems, Inc. Postal: 170 West Tasman Drive San Jose, CA USA 95134 Tel: +1 408 527-3711 E-mail: abierman@cisco.com Working Group Mailing List: To subscribe send email to: " DESCRIPTION "The MIB module for measuring application performance as experienced by end-users. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3729; see the RFC itself for full legal notices." REVISION "200402190000Z" -- February 19, 2004 DESCRIPTION "The original version of this MIB Module, published as RFC3729." ::= { rmon 23 } apmMibObjects OBJECT IDENTIFIER ::= { apm 1 } apmConformance OBJECT IDENTIFIER ::= { apm 2 } apmCompliances OBJECT IDENTIFIER ::= { apmConformance 1 } apmGroups OBJECT IDENTIFIER ::= { apmConformance 2 } AppLocalIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A locally arbitrary unique identifier associated with an application or application verb. All objects of type AppLocalIndex are assigned by the agent out of a common number space. In other words, AppLocalIndex values assigned to entries in one table must not overlap with AppLocalIndex values assigned to entries in another table. Further, every protocolDirLocalIndex value registered by the agent automatically assigns the same value out of the Waldbusser Standards Track [Page 15] RFC 3729 APM MIB March 2004 AppLocalIndex number space. For example, if the protocolDirLocalIndex values { 1, 3, 5, 7 } have been assigned, and the apmHttpFilterAppLocalIndex values { 6, 8, 9 } have been assigned: - Assignment of new AppLocalIndex values must not use the values { 1, 3, 5, 6, 7, 8, 9 }. - AppLocalIndex values { 1, 3, 5, 7 } are automatically assigned and are associated with the identical value of protocolDirLocalIndex. In particular, an entry in the apmAppDirTable indexed by a value provides further information about a protocol indexed by the same value in the protocolDirTable of RMON2. The value for each supported application must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization, except that if an application is deleted and re-created, it must be re-created with a new value that has not been used since the last re-initialization. The specific value is meaningful only within a given SNMP entity. An AppLocalIndex value must not be re-used until the next agent restart." SYNTAX Unsigned32 (1..2147483647) ProtocolDirNetworkAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A network level address whose semantics and encoding are specified by an associated protocolDirLocalIndex value. Objects of this type must specify which protocolDirLocalIndex value is used. This value is encoded according to the encoding rules for the identified protocolDirectory entry. For example, if the associated protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order. Objects of this type may allow this value to be the zero length string. If so, they must identify they meaning of this value." SYNTAX OCTET STRING (SIZE(0..255)) DataSourceOrZero ::= TEXTUAL-CONVENTION Waldbusser Standards Track [Page 16] RFC 3729 APM MIB March 2004 STATUS current DESCRIPTION "Identifies the source of the data that the associated function is configured to analyze. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in [4], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. If the source of the data isn't an interface or cannot be localized to an interface, this object would be set to 0.0" REFERENCE "The DataSource textual convention is defined in RFC 2021 [5]." SYNTAX OBJECT IDENTIFIER RmonClientID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A long-lived unique ID assigned to an end-system. This ID is assigned by the agent using an implementation-specific algorithm. Because a client machine may be assigned multiple addresses over any time period it can be difficult to attribute behavior to a particular client based solely on its address. A ClientID may be assigned to provide a more stable handle for referencing that client. The entity that assigns the ClientID may use various implementation techniques to keep track of a client but if the assigning entity is unable to track client address mappings, it may map client identifiers to client addresses rather than to distinct client machines. This is named ClientID because it helps to solve a problem seen in network clients (servers usually have well-known, long-lived addresses). However, ClientID's may be assigned to any end-system regardless of its role on the network." SYNTAX Unsigned32 (0..4294967295) TransactionAggregationType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Waldbusser Standards Track [Page 17] RFC 3729 APM MIB March 2004 "Specifies one of 4 different techniques for aggregating transactions. The metrics for a single transaction are the responsiveness of the transaction and whether the transaction succeeded (a boolean). When such metrics are aggregated in this MIB Module, these metrics are replaced by averages and distributions of responsiveness and availability. The metrics describing aggregates are constant no matter which type of aggregation is being performed. These metrics may be found in the apmReportTable. The flows(1) aggregation is the simplest. All transactions that share common application/server/client 3-tuples are aggregated together, resulting in a set of metrics for all such unique 3-tuples. The clients(2) aggregation results in somewhat more aggregation (i.e., fewer resulting records). All transactions that share common application/client tuples are aggregated together, resulting in a set of metrics for all such unique tuples. The servers(3) aggregation usually results in still more aggregation (i.e., fewer resulting records). All transactions that share common application/server tuples are aggregated together, resulting in a set of metrics for all such unique tuples. The applications(4) aggregation results in the most aggregation (i.e., the fewest resulting records). All transactions that share a common application are aggregated together, resulting in a set of metrics for all such unique applications. Note that it is not meaningful to aggregate applications, as different applications have widely varying characteristics. As a result, this set of aggregations is complete." SYNTAX INTEGER { flows(1), -- Least Aggregation clients(2), servers(3), applications(4) -- Most Aggregation } -- The APM Application Directory Group -- The Application Directory Table contains a record for every Waldbusser Standards Track [Page 18] RFC 3729 APM MIB March 2004 -- application monitored by this agent. This table is also used to -- configure whether or not an application will be measured and which -- bucket boundaries will be used for the application. -- -- The bucket boundaries define the break-points between bins of a -- histogram analysis for that application. As an example of how this -- works, consider an entry representing response-time for http. -- If the boundaries are set as follows: -- Boundary1: 500 milliseconds -- Boundary2: 1 second -- Boundary3: 2 seconds -- Boundary4: 5 -- Boundary5: 15 -- Boundary6: 60 -- -- If the following measurements are made (all in milliseconds): -- 377, 8645, 1300, 487, 1405, 775, 1115, 850, 945, 1054, 7745, 9380 -- -- A report run during this interval would report the following -- counts: -- Bucket1: 2 -- Bucket2: 3 -- Bucket3: 4 -- Bucket4: 0 -- Bucket5: 3 -- Bucket6: 0 -- Bucket7: 0 apmAppDirTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmAppDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The APM MIB directory of applications and application verbs. The agent will populate this table with all applications/verbs of any responsivenessType it has the capability to monitor. Since the agent populates this table with every entry it has the capability to monitor, the entries in this table are read-write, allowing the management station to modify parameters in this table but not to add new entries or delete entries (however, entries may be disabled). If new entries are added to the apmHttpFilterTable or the apmUserDefinedAppTable, the agent will add the corresponding entries to this table. It is an implementation-dependent matter as to how the agent sets these default parameters. For example, it may leave certain entries in this table 'off(0)' if the agent developer Waldbusser Standards Track [Page 19] RFC 3729 APM MIB March 2004 believes that combination will be infrequently used, allowing a manager that needs that capability to set it to 'on(1)'. Some applications are registered in the RMON2 protocol directory and some are registered in other tables in this MIB Module. Regardless of where an application is originally registered, it is assigned an AppLocalIndex value that is the primary index for this table. The contents of this table affect all reports and exceptions generated by this agent. Accordingly, modification of this table should be performed by a manager acting in the role of administrator. In particular, management software should not require or enforce particular configuration of this table - it should reflect the preferences of the site administrator, not the software author. As a practical matter, this requires management software to allow the administrator to configure the values it will use so that it can be adapted to the site policy." ::= { apmMibObjects 1 } apmAppDirEntry OBJECT-TYPE SYNTAX ApmAppDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The APM MIB directory of applications and application verbs. An entry will exist in this table for all applications for which application performance measurement is supported." INDEX { apmAppDirAppLocalIndex, apmAppDirResponsivenessType } ::= { apmAppDirTable 1 } ApmAppDirEntry ::= SEQUENCE { apmAppDirAppLocalIndex AppLocalIndex, apmAppDirResponsivenessType INTEGER, apmAppDirConfig INTEGER, apmAppDirResponsivenessBoundary1 Unsigned32, apmAppDirResponsivenessBoundary2 Unsigned32, apmAppDirResponsivenessBoundary3 Unsigned32, apmAppDirResponsivenessBoundary4 Unsigned32, apmAppDirResponsivenessBoundary5 Unsigned32, apmAppDirResponsivenessBoundary6 Unsigned32 } apmAppDirAppLocalIndex OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS not-accessible Waldbusser Standards Track [Page 20] RFC 3729 APM MIB March 2004 STATUS current DESCRIPTION "The AppLocalIndex assigned for this application Directory entry." ::= { apmAppDirEntry 1 } apmAppDirResponsivenessType OBJECT-TYPE SYNTAX INTEGER { transactionOriented(1), throughputOriented(2), streamingOriented(3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object describes and configures the agent's support for application performance measurement for this application. There are 3 types of measurements for different types of applications: Transaction-Oriented applications have a fairly constant workload to perform for all transactions. The responsiveness metric for transaction-oriented applications is application response time (from first request to final delivery of service) and is measured in milliseconds. This is commonly referred to as end-user response time. Throughput-Oriented applications have widely varying workloads based on the nature of the client request. In particular, throughput-oriented applications vary widely in the amount of data that must be transported to satisfy the request. The responsiveness metric for throughput-oriented applications is kilobits per second. Streaming-Oriented applications deliver data at a constant metered rate of speed regardless of the responsiveness of the networking and computing infrastructure. This constant rate of speed is generally specified to be below (sometimes well below) the nominal capability of the infrastructure. However, when the infrastructures cannot deliver data at this speed, interruption of service or degradation of service can result. The responsiveness metric for streaming-oriented applications is the ratio of time that the service is degraded or interrupted to the total service time. This metric is measured in parts per million. Note that for some applications, measuring more than one responsiveness type may be interesting. For agents that wish Waldbusser Standards Track [Page 21] RFC 3729 APM MIB March 2004 to support more than one measurement for a application, they will populate this table with multiple entries for that application, one for each type." ::= { apmAppDirEntry 2 } apmAppDirConfig OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object describes and configures support for application performance measurement for this application. If the value of this object is on(2), the agent supports measurement of application performance metrics for this application and is configured to measure such metrics for all APM MIB functions and all interfaces. If the value of this object is off(1), the agent supports measurement of application performance for this application but is configured to not measure these metrics for any APM MIB functions or interfaces. Whenever this value changes from on(2) to off(1), the agent shall delete all related entries in all tables in this MIB Module. The value of this object must persist across reboots." ::= { apmAppDirEntry 3 } apmAppDirResponsivenessBoundary1 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The boundary value between bucket1 and bucket 2. If this value is modified, all entries in the apmReportTable must be deleted by the agent. The value of this object must persist across reboots." ::= { apmAppDirEntry 4 } apmAppDirResponsivenessBoundary2 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The boundary value between bucket2 and bucket 3. If this Waldbusser Standards Track [Page 22] RFC 3729 APM MIB March 2004 value is modified, all entries in the apmReportTable must be deleted by the agent. The value of this object must persist across reboots." ::= { apmAppDirEntry 5 } apmAppDirResponsivenessBoundary3 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The boundary value between bucket3 and bucket 4. If this value is modified, all entries in the apmReportTable must be deleted by the agent. The value of this object must persist across reboots." ::= { apmAppDirEntry 6 } apmAppDirResponsivenessBoundary4 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The boundary value between bucket4 and bucket 5. If this value is modified, all entries in the apmReportTable must be deleted by the agent. The value of this object must persist across reboots." ::= { apmAppDirEntry 7 } apmAppDirResponsivenessBoundary5 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The boundary value between bucket5 and bucket 6. If this value is modified, all entries in the apmReportTable must be deleted by the agent. The value of this object must persist across reboots." ::= { apmAppDirEntry 8 } apmAppDirResponsivenessBoundary6 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The boundary value between bucket6 and bucket 7. If this Waldbusser Standards Track [Page 23] RFC 3729 APM MIB March 2004 value is modified, all entries in the apmReportTable must be deleted by the agent. The value of this object must persist across reboots." ::= { apmAppDirEntry 9 } -- Scalars related to the Application Directory table apmBucketBoundaryLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time that any bucket boundary in any appDirEntry was changed. This object can help to determine if two managers are both trying to enforce different configurations of this table." ::= { apmMibObjects 2 } apmAppDirID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows managers to avoid downloading application directory information when the directory is set to a known (usually fixed) configuration. If the value of this object isn't 0.0, it signifies that the entire contents of the apmAppDirTable, apmHttpFilterTable, apmUserDefinedAppTable and protocolDirTable are equal to a known state identified by the value of this object. If a manager recognizes this value as identifying a directory configuration it has a local copy of, it may use this local copy rather than downloading these tables. Note that it may have downloaded this local copy (and the ID) from another agent and used this copy for all other agents that advertised the same ID. If an agent recognizes that the entire contents of the apmAppDirTable, apmHttpFilterTable, apmUserDefinedAppTable and protocolDirTable are equal to a known state to which an ID has been assigned, it should set this object to that ID. In many cases when this feature is used, the application directory information will be in read-only memory and thus the tables may not be modified via SNMP requests. In the event Waldbusser Standards Track [Page 24] RFC 3729 APM MIB March 2004 that the tables are writable and a modification is made, the agent is responsible for setting this object to 0.0 if it cannot determine that the state is equal to a known state. An agent is not obligated to recognize and advertise all such registered states as it may not have knowledge of all states. Thus, a manager may encounter agents whose DirectoryID value is 0.0 even though the contents of the directory were equal to a registered state. Note that the contents of those tables includes the protocolDirLocalIndex and appLocalIndex values. In other words, these values can't be assigned randomly on each agent, but must be equal to values that are part of the known state. While it is possible for a manager to download application directory details using SNMP and to set the appropriate directoryID, the manager would need to have some scheme to ensure consistent values of LocalIndex variables from agent to agent. Such schemes are outside the scope of this specification. Application directory registrations are unique within an administrative domain. Typically these registrations will be made by an agent software developer who will set the application directory tables to a read-only state and assign a DirectoryID to that state. Thus, all agents running this software would share the same DirectoryID. As the application directory might change from one software release to the next, the developer may register different DirectoryID's for each software release. A customer could also create a site-wide application directory configuration and assign a DirectoryID to that configuration as long as consistent values of LocalIndex variables can be ensured. The value of this object must persist across reboots." ::= { apmMibObjects 3 } -- APM HTTP Filter Table -- The HTTP Filter Table creates virtual applications which measure the -- performance of certain web pages or sets of web pages. Some -- circumstances where this is particularly useful are: -- -- - An Intranet or ASP scenario where a business application is -- running on one or more web pages or scripts. Waldbusser Standards Track [Page 25] RFC 3729 APM MIB March 2004 -- (i.e., /expense/submit.cgi?employeeID=3426&...) -- - A web-hosting scenario where one wants to measure the -- service level for a particular customer -- - An e-commerce scenario where the performance of certain -- pages needs to be monitored more closely. -- (i.e., shopping cart, shipping, credit card authorization) apmHttpFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmHttpFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that creates virtual applications which measure the performance of certain web pages or sets of web pages. When an entry is added to this table, the agent will automatically create one or more entries in the apmAppDirTable (one for each responsivenessType it is capable of measuring). Note that when entries exist in this table some HTTP transactions will be summarized twice: in applications represented here as well as the HTTP application. If entries in this table overlap, these transactions may be summarized additional times. The contents of this table affect all reports and exceptions generated by this agent. Accordingly, modification of this table should be performed by a manager acting in the role of administrator. In particular, management software should not require or enforce particular configuration of this table - it should reflect the preferences of the site administrator, not the software author." ::= { apmMibObjects 4 } apmHttpFilterEntry OBJECT-TYPE SYNTAX ApmHttpFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A virtual application which measure the performance of certain web pages or sets of web pages." INDEX { apmHttpFilterIndex } ::= { apmHttpFilterTable 1 } ApmHttpFilterEntry ::= SEQUENCE { apmHttpFilterIndex Unsigned32, apmHttpFilterAppLocalIndex AppLocalIndex, Waldbusser Standards Track [Page 26] RFC 3729 APM MIB March 2004 apmHttpFilterServerProtocol Unsigned32, apmHttpFilterServerAddress ProtocolDirNetworkAddress, apmHttpFilterURLPath OCTET STRING, apmHttpFilterMatchType INTEGER, apmHttpFilterOwner OwnerString, apmHttpFilterStorageType StorageType, apmHttpFilterRowStatus RowStatus } apmHttpFilterIndex OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the apmHttpFilterTable." ::= { apmHttpFilterEntry 1 } apmHttpFilterAppLocalIndex OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The AppLocalIndex that represents HTTP transactions that match this entry. This object is read-only. A value is created by the agent from an unused AppLocalIndex value when this apmHttpFilterEntry is created." ::= { apmHttpFilterEntry 2 } apmHttpFilterServerProtocol OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The protocolDirLocalIndex value of the network level protocol of the apmHttpFilterServerAddress." ::= { apmHttpFilterEntry 3 } apmHttpFilterServerAddress OBJECT-TYPE SYNTAX ProtocolDirNetworkAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This entry will only represent transactions coming from the network address specified in this object. Waldbusser Standards Track [Page 27] RFC 3729 APM MIB March 2004 This is represented as an octet string with specific semantics and length as identified by the associated apmHttpFilterServerProtocol object. If this object is the zero-length string, then this entry will match one of the addresses represented by the 'host' component of the associated apmHttpFilterURLPath object, where the format if a URL [9] is http://:/?." ::= { apmHttpFilterEntry 4 } apmHttpFilterURLPath OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..65535)) MAX-ACCESS read-create STATUS current DESCRIPTION "This entry will only represent HTTP transactions where the URL path component in the request matches this value. This value represents the requested path regardless of any substitution that the server might perform. Prior to the matching, the URL is stripped of any server address or DNS name and consists solely of the path name on that server. If the length of this object is zero, then this entry will match if the associated apmHttpFilterServerAddress match. If the length of that object is also zero, then this entry will match nothing. The value of the associated apmHttpFilterMatchType dictates the type of matching that will be attempted." ::= { apmHttpFilterEntry 5 } apmHttpFilterMatchType OBJECT-TYPE SYNTAX INTEGER { exact(1), stripTrailingSlash(2), prefix(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The matching algorithm used to compare the URL pathname. If the value is exact(1), then the pathname component will be compared with the associated apmHttpFilterURLPath and will only be associated with this entry if it matches exactly. Waldbusser Standards Track [Page 28] RFC 3729 APM MIB March 2004 If the value is stripTrailingSlash(2), then the pathname component will be compared with the associated apmHttpFilterURLPath and will only be associated with this entry if it matches exactly or if the pathname ends with a '/' symbol and matches apmHttpFilterURLPath if the '/' symbol is removed from the pathname. This option exists for those paths where an optional trailing slash is possible but for which a prefix match would be too broad. If the value is prefix(3), then the pathname component will be compared with the associated apmHttpFilterURLPath and will only be associated with this entry if the beginning of the pathname matches every octet of this value. Octets that extend beyond the length of this value are ignored." ::= { apmHttpFilterEntry 6 } apmHttpFilterOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { apmHttpFilterEntry 7 } apmHttpFilterStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this apmHttpFilterEntry. If the value of this object is 'permanent', no objects in this row need to be writable." ::= { apmHttpFilterEntry 8 } apmHttpFilterRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this apmHttpFilterEntry. No objects in this row may be modified while the row's status is 'active'." ::= { apmHttpFilterEntry 9 } apmHttpIgnoreUnregisteredURLs OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current Waldbusser Standards Track [Page 29] RFC 3729 APM MIB March 2004 DESCRIPTION "When true, APM measurements of HTTP transactions will only measure transactions relating to URLs that match a filter in the apmHttpFilterTable. Thus, measurements for the HTTP application will present aggregated statistics for URL-matching HTTP transactions and measurements for the HTTP GET application verb will present aggregated statistics for URL-matching HTTP GET transactions. This will be used in environments that wish to monitor only targeted URLs and to ignore large volumes of internet web browsing traffic. This object affects all APM reports and exceptions generated by this agent. Accordingly, modification of this object should be performed by a manager acting in the role of administrator. In particular, management software should not require or enforce particular configuration of this object - it should reflect the preferences of the site administrator, not the software author. The value of this object must persist across reboots." ::= { apmMibObjects 5 } apmHttp4xxIsFailure OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When true, this agent will recognize HTTP errors in the range of 400 through 499 and will treat them as unavailable transactions. When false or when this object isn't supported, they will be treated as successful transactions. This object allows such error pages to be tracked at the possible expense of having user typos treated as poor service on the part of the web server. This object affects all reports and exceptions generated by this agent. Accordingly, modification of this object should be performed by a manager acting in the role of administrator. In particular, management software should not require or enforce particular configuration of this object - it should reflect the preferences of the site administrator, not the software author. The value of this object must persist across reboots." ::= { apmMibObjects 6 } Waldbusser Standards Track [Page 30] RFC 3729 APM MIB March 2004 -- The APM User-Defined Application Table -- Many application protocols will never be registered with a -- standards body (and thus included in a protocol directory standard) -- because they are custom, in-house or proprietary -- applications. Nevertheless, implementation strategies exist for -- monitoring the end-user experience of these applications. -- -- This read-only table provides a means for the agent to advertise -- which user-defined applications it is monitoring and to associate -- each with an AppLocalIndex value. It is an implementation-dependent -- matter as to how the agent learns how to monitor these -- applications. apmUserDefinedAppTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmUserDefinedAppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that advertises user-defined applications that the agent is measuring. The agent will automatically create one or more entries in the apmAppDirTable (one for each responsivenessType it is capable of measuring) for each entry in this table. Note that when entries exist in this table some transactions can be summarized more than once if there is overlap between applications defined here and applications defined in the protocol directory or in the httpFilter table." ::= { apmMibObjects 7 } apmUserDefinedAppEntry OBJECT-TYPE SYNTAX ApmUserDefinedAppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A user-defined application that the agent is measuring, along with its AppLocalIndex assignment. The apmAppDirAppLocalIndex value in the index identifies the agent-assigned AppLocalIndex value for this user-defined application." INDEX { apmAppDirAppLocalIndex } ::= { apmUserDefinedAppTable 1 } ApmUserDefinedAppEntry ::= SEQUENCE { apmUserDefinedAppParentIndex Unsigned32, Waldbusser Standards Track [Page 31] RFC 3729 APM MIB March 2004 apmUserDefinedAppApplication SnmpAdminString } apmUserDefinedAppParentIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex value of the highest-layer protocol defined in the protocolDirTable that this application is a child of." ::= { apmUserDefinedAppEntry 1 } apmUserDefinedAppApplication OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable descriptive tag for this application." ::= { apmUserDefinedAppEntry 2 } -- The APM Name Table apmNameTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A client machine may have multiple addresses during a period of monitoring. The apmNameTable assigns a long-lived identifier to a client and records what addresses were assigned to that client for periods of time. Various implementation techniques exist for tracking this mapping but if an agent is unable to track client address mappings, it may map client identifiers to client addresses rather than to distinct client machines. A particular apmNameClientID should be a constant attribute of a particular client. When available, the agent may also record the machine name and/or user name which may be valuable for displaying to humans. The apmNameMachineName and apmNameUserName are relatively constant, changing only if these attributes actually change on the client. The agent will store a historical log of these entries, aging out old entries as the log becomes too large. Since this table contains information vital to the interpretation of other tables (e.g., the apmReportTable), the agent should ensure that Waldbusser Standards Track [Page 32] RFC 3729 APM MIB March 2004 the log doesn't age out entries that would be referenced by data in those tables. Note that an entry for a clientID is active from its StartTime until the StartTime of another entry (for the same clientID) that supersedes it, or 'now' if none supersede it. Therefore, if a clientID only has a single entry, it is by definition very new and should never be aged out. No entry for a clientID should be aged out unless it has been updated by a new entry for the client (i.e., with an updated address) and only if the new entry is 'old' enough. To determine how old is old enough, compute the maximum value of Interval * (NumReports + 1) of all entries in the apmReportControlTable (the '+ 1' is to allow a reasonable period of time for the report to be downloaded). Then take the larger of this value and the age in seconds of the oldest entry in the current transaction table. If an entry for a clientID is superseded by another entry whose StartTime is more than this many seconds ago, then the older entry may be deleted." ::= { apmMibObjects 8 } apmNameEntry OBJECT-TYPE SYNTAX ApmNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the APM name table. An entry exists for each period of time that a client has been associated with a particular address. The protocolDirLocalIndex value in the index identifies the network layer protocol for the ClientAddress for this entry. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { apmNameClientID, protocolDirLocalIndex, apmNameClientAddress, apmNameMappingStartTime } ::= { apmNameTable 1 } ApmNameEntry ::= SEQUENCE { apmNameClientID RmonClientID, apmNameClientAddress ProtocolDirNetworkAddress, Waldbusser Standards Track [Page 33] RFC 3729 APM MIB March 2004 apmNameMappingStartTime DateAndTime, apmNameMachineName SnmpAdminString, apmNameUserName SnmpAdminString } apmNameClientID OBJECT-TYPE SYNTAX RmonClientID MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique ID assigned to the machine represented by this mapping. This ID is assigned by the agent using an implementation-specific algorithm." ::= { apmNameEntry 1 } apmNameClientAddress OBJECT-TYPE SYNTAX ProtocolDirNetworkAddress (SIZE(1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network client address for this client when this mapping was active. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. This object may not be the zero length string. Since this object is an index variable, it is encoded in the index according to the index encoding rules. For example, if the protocolDirLocalIndex component of the index indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order. Care should be taken to avoid values of this object that, in conjunction with the other index variables, would result in an index longer than SNMP's maximum of 128 subidentifiers." ::= { apmNameEntry 2 } apmNameMappingStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time that the agent first discovered this mapping as active." ::= { apmNameEntry 3 } Waldbusser Standards Track [Page 34] RFC 3729 APM MIB March 2004 apmNameMachineName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable name of the client machine. If the client has no machine name or the agent is unable to learn the machine name, this object will be a zero-length string." ::= { apmNameEntry 4 } apmNameUserName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The human readable name of a human user using the client machine. If more than one user name are available simultaneously, it is an implementation-dependent matter as to which is used here. However, if the user name changes, this object should change to reflect that change. Non-human user names like 'root' or 'administrator' aren't intended as values for this object. If the client has no recorded user name or the agent is unable to learn a user name, this object will be a zero-length string." ::= { apmNameEntry 5 } -- The APM Report Group apmReportControlTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmReportControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Parameters that control the creation of a set of reports that aggregate application performance." ::= { apmMibObjects 9 } apmReportControlEntry OBJECT-TYPE SYNTAX ApmReportControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apmReportControlTable. An example of the indexing of this table is Waldbusser Standards Track [Page 35] RFC 3729 APM MIB March 2004 apmReportControlInterval.3" INDEX { apmReportControlIndex } ::= { apmReportControlTable 1 } ApmReportControlEntry ::= SEQUENCE { apmReportControlIndex Unsigned32, apmReportControlDataSource DataSourceOrZero, apmReportControlAggregationType TransactionAggregationType, apmReportControlInterval Unsigned32, apmReportControlRequestedSize Unsigned32, apmReportControlGrantedSize Unsigned32, apmReportControlRequestedReports Unsigned32, apmReportControlGrantedReports Unsigned32, apmReportControlStartTime TimeStamp, apmReportControlReportNumber Unsigned32, apmReportControlDeniedInserts Counter32, apmReportControlDroppedFrames Counter32, apmReportControlOwner OwnerString, apmReportControlStorageType StorageType, apmReportControlStatus RowStatus } apmReportControlIndex OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the apmReportControlTable. Each such entry defines a unique report whose results are placed in the apmReportTable on behalf of this apmReportControlEntry." ::= { apmReportControlEntry 1 } apmReportControlDataSource OBJECT-TYPE SYNTAX DataSourceOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The source of the data for APM Reports generated on behalf of this apmReportControlEntry. If the measurement is being performed by a probe, this should be set to interface or port where data was received for analysis. If the measurement isn't being performed by a probe, this should be set to the primary interface over which the measurement is being performed. If the measurement isn't being performed by a probe and there is no primary interface or this Waldbusser Standards Track [Page 36] RFC 3729 APM MIB March 2004 information isn't known, this object should be set to 0.0. This object may not be modified if the associated apmReportControlStatus object is equal to active(1)." ::= { apmReportControlEntry 2 } apmReportControlAggregationType OBJECT-TYPE SYNTAX TransactionAggregationType -- INTEGER { -- flows(1), -- clients(2), -- servers(3), -- applications(4) -- } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of aggregation being performed for this set of reports. The metrics for a single transaction are the responsiveness of the transaction and whether the transaction succeeded (a boolean). When such metrics are aggregated in this MIB Module, these metrics are replaced by averages and distributions of responsiveness and availability. The metrics describing aggregates are constant no matter which type of aggregation is being performed. These metrics may be found in the apmReportTable. The flows(1) aggregation is the simplest. All transactions that share common application/server/client 3-tuples are aggregated together, resulting in a set of metrics for all such unique 3-tuples. The clients(2) aggregation results in somewhat more aggregation (i.e., fewer resulting records). All transactions that share common application/client tuples are aggregated together, resulting in a set of metrics for all such unique tuples. The servers(3) aggregation usually results in still more aggregation (i.e., fewer resulting records). All transactions that share common application/server tuples are aggregated together, resulting in a set of metrics for all such unique tuples. The applications(4) aggregation results in the most aggregation (i.e., the fewest resulting records). All Waldbusser Standards Track [Page 37] RFC 3729 APM MIB March 2004 transactions that share a common application are aggregated together, resulting in a set of metrics for all such unique applications. Note that it is not meaningful to aggregate applications, as different applications have widely varying characteristics. As a result, this set of aggregations is complete. This object may not be modified if the associated apmReportControlStatus object is equal to active(1)." ::= { apmReportControlEntry 3 } apmReportControlInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval in seconds over which data is accumulated before being aggregated into a report in the apmReportTable. All reports with the same apmReportControlIndex will be based on the same interval. This object must be greater than zero. Many users desire that these reports be synchronized to within seconds of the beginning of the hour because the results may be correlated more meaningfully to business behavior and so that data from multiple agents is aggregated over the same time periods. Thus management software may take extra effort to synchronize reports to the beginning of the hour and to one another. However, the agent must not allow reports to 'drift' over time as they will quickly become unsynchronized. In particular, if there is any fixed processing delay between reports, the reports should deduct this time from the interval so that reports don't drift. This object may not be modified if the associated apmReportControlStatus object is equal to active(1)." DEFVAL { 3600 } ::= { apmReportControlEntry 4 } apmReportControlRequestedSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of entries requested to be allocated for each report generated on behalf of this entry." ::= { apmReportControlEntry 5 } Waldbusser Standards Track [Page 38] RFC 3729 APM MIB March 2004 apmReportControlGrantedSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries per report the agent has allocated based on the requested amount in apmReportControlRequestedSize. Since multiple reports are saved, the total number of entries allocated will be this number multiplied by the value of apmReportControlGrantedReports, or 1 if that object doesn't exist. When the associated apmReportControlRequestedSize object is created or modified, the agent should set this object as closely to the requested value as is possible for the particular implementation and available resources. When considering resources available, the agent must consider its ability to allocate this many entries for all reports. Note that while the actual number of entries stored in the reports may fluctuate due to changing conditions, the agent must continue to have storage available to satisfy the full report size for all reports when necessary. Further, the agent must not lower this value except as a result of a set to the associated apmReportControlRequestedSize object." ::= { apmReportControlEntry 6 } apmReportControlRequestedReports OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of saved reports requested to be allocated on behalf of this entry." ::= { apmReportControlEntry 7 } apmReportControlGrantedReports OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of saved reports the agent has allocated based on the requested amount in apmReportControlRequestedReports. Since each report can have many entries, the total number of entries allocated will be this number multiplied by the value of apmReportControlGrantedSize, or 1 if that object doesn't exist. Waldbusser Standards Track [Page 39] RFC 3729 APM MIB March 2004 When the associated apmReportControlRequestedReports object is created or modified, the agent should set this object as closely to the requested value as is possible for the particular implementation and available resources. When considering resources available, the agent must consider its ability to allocate this many reports each with the number of entries represented by apmReportControlGrantedSize, or 1 if that object doesn't exist. Note that while the storage required for each report may fluctuate due to changing conditions, the agent must continue to have storage available to satisfy the full report size for all reports when necessary. Further, the agent must not lower this value except as a result of a set to the associated apmReportControlRequestedSize object." ::= { apmReportControlEntry 8 } apmReportControlStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the system began processing the report in progress. Note that the report in progress is not available. This object may be used by the management station to figure out the start time for all previous reports saved for this apmReportControlEntry, as reports are started at fixed intervals." ::= { apmReportControlEntry 9 } apmReportControlReportNumber OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the report in progress. When an apmReportControlEntry is activated, the first report will be numbered one." ::= { apmReportControlEntry 10 } apmReportControlDeniedInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed attempts to add an entry to reports for Waldbusser Standards Track [Page 40] RFC 3729 APM MIB March 2004 this apmReportControlEntry because the number of entries would have exceeded apmReportControlGrantedSize. This number is valuable in determining if enough entries have been allocated for reports in light of fluctuating network usage. Note that since an entry that is denied will often be attempted again, this number will not predict the exact number of additional entries needed, but can be used to understand the relative magnitude of the problem. Also note that there is no ordering specified for the entries in the report, thus there are no rules for which entries will be omitted when not enough entries are available. As a consequence, the agent is not required to delete 'least valuable' entries first." ::= { apmReportControlEntry 11 } apmReportControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the agent and therefore not accounted for in the *StatsDropEvents, but for which the agent chose not to count for this entry for whatever reason. Most often, this event occurs when the agent is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. This counter is only relevant if this apm report is based on a data source whose collection methodology is based on analyzing network traffic. Note that if the apmReportTables are inactive because no applications are enabled in the application directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { apmReportControlEntry 12 } apmReportControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current Waldbusser Standards Track [Page 41] RFC 3729 APM MIB March 2004 DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { apmReportControlEntry 13 } apmReportControlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this apmReportControlEntry. If the value of this object is 'permanent', no objects in this row need to be writable." ::= { apmReportControlEntry 14 } apmReportControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this apmReportControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. The only objects in the entry that may be modified while the entry is in the active state are apmReportControlRequestedSize and apmReportControlRequestedReports. If this object is not equal to active(1), all associated entries in the apmReportTable shall be deleted by the agent." ::= { apmReportControlEntry 15 } -- The APM Report Table apmReportTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The data resulting from aggregated APM reports. Consult the definition of apmReportControlAggregationType for the definition of the various types of aggregations." ::= { apmMibObjects 10 } apmReportEntry OBJECT-TYPE SYNTAX ApmReportEntry MAX-ACCESS not-accessible Waldbusser Standards Track [Page 42] RFC 3729 APM MIB March 2004 STATUS current DESCRIPTION "A conceptual row in the apmReportTable. The apmReportControlIndex value in the index identifies the apmReportControlEntry on whose behalf this entry was created. The apmReportIndex value in the index identifies which report (in the series of reports) this entry is a part of. The apmAppDirAppLocalIndex value in the index identifies the common application of the transactions aggregated in this entry. The apmAppDirResponsivenessType value in the index identifies the type of responsiveness metric reported by this entry and uniquely identifies this entry when more than one responsiveness metric is measured for a flow. Entries will only exist in this table for those combinations of AppLocalIndex and ResponsivenessType that are configured 'on(1)'. The protocolDirLocalIndex value in the index identifies the network layer protocol of the apmReportServerAddress. When the associated apmReportControlAggregationType value is equal to applications(4) or clients(2), this protocolDirLocalIndex value will equal 0. The apmReportServerAddress value in the index identifies the network layer address of the server in transactions aggregated in this entry. The apmNameClientID value in the index identifies the client in transactions aggregated in this entry. If the associated apmReportControlAggregationType is equal to applications(4) or servers(3), then this protocolDirLocalIndex value will equal 0. An example of the indexing of this entry is apmReportTransactionCount.3.15.3.1.8.4.192.168.1.2.3232235788 Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { apmReportControlIndex, apmReportIndex, apmAppDirAppLocalIndex, apmAppDirResponsivenessType, protocolDirLocalIndex, apmReportServerAddress, apmNameClientID } ::= { apmReportTable 1 } ApmReportEntry ::= SEQUENCE { apmReportIndex Unsigned32, apmReportServerAddress ProtocolDirNetworkAddress, Waldbusser Standards Track [Page 43] RFC 3729 APM MIB March 2004 apmReportTransactionCount Unsigned32, apmReportSuccessfulTransactions Unsigned32, apmReportResponsivenessMean Unsigned32, apmReportResponsivenessMin Unsigned32, apmReportResponsivenessMax Unsigned32, apmReportResponsivenessB1 Unsigned32, apmReportResponsivenessB2 Unsigned32, apmReportResponsivenessB3 Unsigned32, apmReportResponsivenessB4 Unsigned32, apmReportResponsivenessB5 Unsigned32, apmReportResponsivenessB6 Unsigned32, apmReportResponsivenessB7 Unsigned32 } apmReportIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of apmReportControlReportNumber for the report to which this entry belongs." ::= { apmReportEntry 1 } apmReportServerAddress OBJECT-TYPE SYNTAX ProtocolDirNetworkAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network server address for this apmReportEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. Since this object is an index variable, it is encoded in the index according to the index encoding rules. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order. Care should be taken to avoid values of this object that, in conjunction with the other index variables, would result in an index longer than SNMP's maximum of 128 subidentifiers. If the associated apmReportControlAggregationType is equal to applications(4) or clients(2), then this object will be a null string and will be encoded simply as a length octet of 0." ::= { apmReportEntry 2 } Waldbusser Standards Track [Page 44] RFC 3729 APM MIB March 2004 apmReportTransactionCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of transactions aggregated into this record." ::= { apmReportEntry 3 } apmReportSuccessfulTransactions OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of successful transactions aggregated into this record." ::= { apmReportEntry 4 } apmReportResponsivenessMean OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The arithmetic mean of the responsiveness metrics for all successful transactions aggregated into this record." ::= { apmReportEntry 5 } apmReportResponsivenessMin OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum of the responsiveness metrics for all successful transactions aggregated into this record." ::= { apmReportEntry 6 } apmReportResponsivenessMax OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum of the responsiveness metrics for all successful transactions aggregated into this record." ::= { apmReportEntry 7 } -- Note that when updating a report entry, a transaction will not be -- counted in more than 1 bucket in an entry. It will be counted in -- the first bucket that matches, starting with Bucket 1 (B1). Note -- that if a transaction matches 2 application types, it will update Waldbusser Standards Track [Page 45] RFC 3729 APM MIB March 2004 -- one bucket in each of 2 entries in this table. apmReportResponsivenessB1 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful transactions aggregated into this record whose responsiveness was less than boundary1 value for this application." ::= { apmReportEntry 8 } apmReportResponsivenessB2 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful transactions aggregated into this record whose responsiveness did not fall into Bucket 1 and was greater than or equal to the boundary1 value for this application and less than the boundary2 value for this application." ::= { apmReportEntry 9 } apmReportResponsivenessB3 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful transactions aggregated into this record whose responsiveness did not fall into Bucket 1 or 2 and as greater than or equal to the boundary2 value for this application and less than the boundary3 value for this application." ::= { apmReportEntry 10 } apmReportResponsivenessB4 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful transactions aggregated into this record whose responsiveness did not fall into Buckets 1 through 3 and was greater than or equal to the boundary3 value for this application and less than the boundary4 value for this application." ::= { apmReportEntry 11 } Waldbusser Standards Track [Page 46] RFC 3729 APM MIB March 2004 apmReportResponsivenessB5 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful transactions aggregated into this record whose responsiveness did not fall into Buckets 1 through 4 and was greater than or equal to the boundary4 value for this application and less than the boundary5 value for this application." ::= { apmReportEntry 12 } apmReportResponsivenessB6 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful transactions aggregated into this record whose responsiveness did not fall into Buckets 1 through 5 and was greater than or equal to the boundary5 value for this application and less than the boundary6 value for this application." ::= { apmReportEntry 13 } apmReportResponsivenessB7 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful transactions aggregated into this record whose responsiveness did not fall into Buckets 1 through 6 and was greater than or equal to the boundary6 value for this application." ::= { apmReportEntry 14 } -- APM Transaction Table apmTransactionTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmTransactionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains transactions that are currently running or have recently finished." ::= { apmMibObjects 11 } apmTransactionEntry OBJECT-TYPE SYNTAX ApmTransactionEntry Waldbusser Standards Track [Page 47] RFC 3729 APM MIB March 2004 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apmTransactionTable. The apmAppDirAppLocalIndex value in the index identifies the application of the transaction represented by this entry. The apmAppDirResponsivenessType value in the index identifies the type of responsiveness metric reported by this entry and uniquely identifies this entry when more than one responsiveness metric is measured for a flow. Entries will only exist in this table for those combinations of AppLocalIndex and ResponsivenessType that are configured 'on(1)'. The protocolDirLocalIndex value in the index identifies the network layer protocol of the apmTransactionServerAddress. The apmTransactionServerAddress value in the index identifies the network layer address of the server in the transaction represented by this entry. The apmNameClientID value in the index identifies the client in the transaction represented by this entry. An example of the indexing of this entry is apmTransactionCount.3.1.8.4.192.168.1.2.3232235788.2987 Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { apmAppDirAppLocalIndex, apmAppDirResponsivenessType, protocolDirLocalIndex, apmTransactionServerAddress, apmNameClientID, apmTransactionID } ::= { apmTransactionTable 1 } ApmTransactionEntry ::= SEQUENCE { apmTransactionServerAddress ProtocolDirNetworkAddress, apmTransactionID Unsigned32, apmTransactionResponsiveness Unsigned32, apmTransactionAge TimeInterval, apmTransactionSuccess TruthValue } apmTransactionServerAddress OBJECT-TYPE SYNTAX ProtocolDirNetworkAddress (SIZE (1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Waldbusser Standards Track [Page 48] RFC 3729 APM MIB March 2004 "The network server address for this apmTransactionEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. This object may not be the zero length string. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order. Care should be taken to avoid values of this object that, in conjunction with the other index variables, would result in an index longer than SNMP's maximum of 128 subidentifiers." ::= { apmTransactionEntry 1 } apmTransactionID OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for this transaction amongst other transactions sharing the same application layer protocol and server and client addresses. Implementations may choose to use the value of the client's source port, when possible." ::= { apmTransactionEntry 2 } apmTransactionResponsiveness OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current value of the responsiveness metric for this transaction. If this transaction has completed, the final value of the metric will be available. Note that this value may change over the lifetime of the transaction and it is the final value of this metric that is recorded as the responsiveness of the transaction for use in other APM MIB functions." ::= { apmTransactionEntry 3 } apmTransactionAge OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "If this transaction is still executing, this value shall be Waldbusser Standards Track [Page 49] RFC 3729 APM MIB March 2004 the length of time since it was started. If it has completed, this value shall be the length of time it was executing." ::= { apmTransactionEntry 4 } apmTransactionSuccess OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The success of this transaction up to this time. Once a transaction has been marked as failed, it cannot move back into the successful state." ::= { apmTransactionEntry 5 } apmTransactionsRequestedHistorySize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of completed transactions desired to be retained in the apmTransactionTable. If the agent doesn't have enough resources to retain this many, it will retain as many as possible. Regardless of this value, the agent must attempt to keep records for all current transactions it is monitoring. The value of this object must persist across reboots." ::= { apmMibObjects 12 } -- The APM Exception table -- The APM Exception Table creates filters so that a management -- station can get immediate notification of a transaction that has -- had poor availability or responsiveness. -- -- This function is particularly helpful in unaggregated situations -- where the numbers of agents is relatively high and the transaction -- rate per agent is relatively low (such as agents for desktops or -- dedicated to small workgroups). Polling agents in such an -- environment would either cause scalability problems (high rate) or -- lead to long notification delays (low rate). apmExceptionTable OBJECT-TYPE SYNTAX SEQUENCE OF ApmExceptionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table creates filters so that a management station can get immediate notification of a transaction that has had poor Waldbusser Standards Track [Page 50] RFC 3729 APM MIB March 2004 availability or responsiveness. Each apmExceptionEntry is associated with a particular type of transaction and is applied to all transactions of that type. Multiple apmExceptionEntries may be associated with a particular type of transaction. A transaction type is identified by the value of the apmAppDirAppLocalIndex component of the index. Because the quality of a transaction is not known until it is completed, these thresholds are only applied after the transaction has completed." ::= { apmMibObjects 13 } apmExceptionEntry OBJECT-TYPE SYNTAX ApmExceptionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the apmExceptionTable. The apmAppDirAppLocalIndex value in the index identifies the application this entry will monitor. The apmAppDirResponsivenessType value in the index identifies the type of responsiveness metric this entry will monitor." INDEX { apmAppDirAppLocalIndex, apmAppDirResponsivenessType, apmExceptionIndex } ::= { apmExceptionTable 1 } ApmExceptionEntry ::= SEQUENCE { apmExceptionIndex Unsigned32, apmExceptionResponsivenessComparison INTEGER, apmExceptionResponsivenessThreshold Unsigned32, apmExceptionUnsuccessfulException INTEGER, apmExceptionResponsivenessEvents Counter32, apmExceptionUnsuccessfulEvents Counter32, apmExceptionOwner OwnerString, apmExceptionStorageType StorageType, apmExceptionStatus RowStatus } apmExceptionIndex OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION Waldbusser Standards Track [Page 51] RFC 3729 APM MIB March 2004 "An index that uniquely identifies an entry in the apmExceptionTable amongst other entries with equivalent index values for apmAppDirAppLocalIndex and apmAppDirResponsivenessType. Each such entry sets up thresholds for a particular measurement of a particular application." ::= { apmExceptionEntry 1 } apmExceptionResponsivenessComparison OBJECT-TYPE SYNTAX INTEGER { none(1), greater(2), less(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "If this value is greater(2) or less(3), the associated apmExceptionResponsivenessThreshold will be compared to this value and an exception will be created if the responsiveness is greater than the threshold (greater(2)) or less than the threshold (less(3))." ::= { apmExceptionEntry 2 } apmExceptionResponsivenessThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The threshold that responsiveness metrics are compared to." ::= { apmExceptionEntry 3 } apmExceptionUnsuccessfulException OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "If this value is on(2), an exception will be created if a transaction of the associated type is unsuccessful." ::= { apmExceptionEntry 4 } apmExceptionResponsivenessEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Waldbusser Standards Track [Page 52] RFC 3729 APM MIB March 2004 DESCRIPTION "The total number of responsiveness exceptions generated. This counter will be incremented even if no notification was sent due to notifications not being configured or due to exceeding the apmNotificationMaxRate value." ::= { apmExceptionEntry 5 } apmExceptionUnsuccessfulEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of unsuccessful exceptions generated. This counter will be incremented even if no notification was sent due to notifications not being configured or due to exceeding the apmNotificationMaxRate value." ::= { apmExceptionEntry 6 } apmExceptionOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { apmExceptionEntry 7 } apmExceptionStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this apmReportControlEntry. If the value of this object is 'permanent', no objects in this row need to be writable." ::= { apmExceptionEntry 8 } apmExceptionStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this apmExceptionEntry. The only objects in the entry that may be modified while the entry is in the active state are apmExceptionResponsivenessComparison, apmExceptionResponsivenessThreshold and apmExceptionUnsuccessfulException." ::= { apmExceptionEntry 9 } Waldbusser Standards Track [Page 53] RFC 3729 APM MIB March 2004 apmThroughputExceptionMinTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Because the responsiveness for throughput-oriented transactions is divided by the elapsed time, it can be very sensitive to short-term performance variations for transactions that take a short period of time. For example, when downloading a very short file, a single dropped packet could double or triple the total response time. Further, throughput is usually examined for applications that transfer a lot of data, and when doing so it is helpful to conceptualize transaction costs that are proportional to the amount of data separately from those costs that are relatively fixed (i.e., independent of the amount of data). For very short transactions, these fixed transaction costs (handshake, setup time, authentication, round-trip time) may dominate the total response time for the transaction, resulting in throughput measurements that aren't really proportional to the network's, server's and client's combined data throughput capability. This object controls the minimum number of seconds that an throughput-based transaction must exceed before an exception can be generated for it. If this object is set to zero, then all throughput-based transactions are candidates for exceptions. The value of this object must persist across reboots." DEFVAL { 10 } ::= { apmMibObjects 14 } apmNotificationMaxRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notifications that can be generated from this agent by the apmExceptionTable in any 60 second period. The value of this object must persist across reboots." DEFVAL { 1 } ::= { apmMibObjects 15 } Waldbusser Standards Track [Page 54] RFC 3729 APM MIB March 2004 -- APM Notifications apmNotifications OBJECT IDENTIFIER ::= { apm 0 } apmTransactionResponsivenessAlarm NOTIFICATION-TYPE OBJECTS { apmExceptionResponsivenessThreshold, apmTransactionResponsiveness } STATUS current DESCRIPTION "Notification sent when a transaction exceeds a threshold defined in the apmException table. The index of the included apmExceptionResponsivenessThreshold object identifies the apmExceptionEntry that specified the threshold. The apmTransactionResponsiveness variable identifies the actual transaction and its responsiveness. Agent implementors are urged to include additional data objects in the alarm that may explain the reason for the alarm. It is helpful to include such data in the alarm because it describes the situation at the time the alarm was generated, where polls after the fact may not provide meaningful information. Examples of such information are CPU load, memory utilization, network utilization, and transaction statistics." ::= { apmNotifications 1 } apmTransactionUnsuccessfulAlarm NOTIFICATION-TYPE OBJECTS { apmExceptionResponsivenessThreshold } STATUS current DESCRIPTION "Notification sent when a transaction is unsuccessful. The index of the included apmExceptionResponsivenessThreshold object identifies both the type of the transaction that caused this notification as well as the apmExceptionEntry that specified the threshold. Agent implementors are urged to include additional data objects in the alarm that may explain the reason for the alarm. It is helpful to include such data in the alarm because it describes the situation at the time the alarm was generated, where polls after the fact may not provide meaningful information. Examples of such information are CPU load, memory utilization, network utilization, and transaction statistics." ::= { apmNotifications 2 } apmCompliance MODULE-COMPLIANCE STATUS current Waldbusser Standards Track [Page 55] RFC 3729 APM MIB March 2004 DESCRIPTION "Describes the requirements for conformance to the APM MIB" MODULE -- this module MANDATORY-GROUPS { apmAppDirGroup, apmReportGroup } GROUP apmUserDefinedApplicationsGroup DESCRIPTION "Implementation of the apmUserDefinedApplicationsGroup is optional." GROUP apmTransactionGroup DESCRIPTION "Implementation of the apmTransactionGroup is optional." GROUP apmExceptionGroup DESCRIPTION "Implementation of the apmExceptionGroup is optional." GROUP apmNotificationGroup DESCRIPTION "Implementation of the apmNotificationGroup is optional." ::= { apmCompliances 1 } apmAppDirGroup OBJECT-GROUP OBJECTS { apmAppDirConfig, apmAppDirResponsivenessBoundary1, apmAppDirResponsivenessBoundary2, apmAppDirResponsivenessBoundary3, apmAppDirResponsivenessBoundary4, apmAppDirResponsivenessBoundary5, apmAppDirResponsivenessBoundary6, apmBucketBoundaryLastChange, apmAppDirID, apmNameMachineName, apmNameUserName } STATUS current DESCRIPTION "The APM MIB directory of applications and application verbs." ::= { apmGroups 1 } apmUserDefinedApplicationsGroup OBJECT-GROUP OBJECTS { apmHttpFilterAppLocalIndex, apmHttpFilterServerProtocol, apmHttpFilterServerAddress, apmHttpFilterURLPath, apmHttpFilterMatchType, apmHttpFilterOwner, apmHttpFilterStorageType, apmHttpFilterRowStatus, apmHttpIgnoreUnregisteredURLs, apmHttp4xxIsFailure, apmUserDefinedAppParentIndex, Waldbusser Standards Track [Page 56] RFC 3729 APM MIB March 2004 apmUserDefinedAppApplication } STATUS current DESCRIPTION "Objects used for creating and managing user-defined applications." ::= { apmGroups 2 } apmReportGroup OBJECT-GROUP OBJECTS { apmReportControlDataSource, apmReportControlAggregationType, apmReportControlInterval, apmReportControlRequestedSize, apmReportControlGrantedSize, apmReportControlRequestedReports, apmReportControlGrantedReports, apmReportControlStartTime, apmReportControlReportNumber, apmReportControlDeniedInserts, apmReportControlDroppedFrames, apmReportControlOwner, apmReportControlStorageType, apmReportControlStatus, apmReportTransactionCount, apmReportSuccessfulTransactions, apmReportResponsivenessMean, apmReportResponsivenessMin, apmReportResponsivenessMax, apmReportResponsivenessB1, apmReportResponsivenessB2, apmReportResponsivenessB3, apmReportResponsivenessB4, apmReportResponsivenessB5, apmReportResponsivenessB6, apmReportResponsivenessB7 } STATUS current DESCRIPTION "The apm report group controls the creation and retrieval of reports that aggregate application performance." ::= { apmGroups 3 } apmTransactionGroup OBJECT-GROUP OBJECTS { apmTransactionResponsiveness, apmTransactionAge, apmTransactionSuccess, apmTransactionsRequestedHistorySize } STATUS current DESCRIPTION "The apm transaction group contains statistics for individual transactions." Waldbusser Standards Track [Page 57] RFC 3729 APM MIB March 2004 ::= { apmGroups 4 } apmExceptionGroup OBJECT-GROUP OBJECTS { apmExceptionResponsivenessComparison, apmExceptionResponsivenessThreshold, apmExceptionUnsuccessfulException, apmExceptionResponsivenessEvents, apmExceptionUnsuccessfulEvents, apmExceptionOwner, apmExceptionStorageType, apmExceptionStatus, apmThroughputExceptionMinTime, apmNotificationMaxRate } STATUS current DESCRIPTION "The apm exception group causes notifications to be sent whenever transactions are detected that had poor availability or responsiveness." ::= { apmGroups 5 } apmNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { apmTransactionResponsivenessAlarm, apmTransactionUnsuccessfulAlarm } STATUS current DESCRIPTION "Notifications sent by an APM MIB agent." ::= { apmGroups 6 } END 4. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Specifically, most of the read-write and read-create objects in this MIB module may be used to configure an agent to reveal network addresses, application usage information and conversation statistics that may be considered sensitive in some environments. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Waldbusser Standards Track [Page 58] RFC 3729 APM MIB March 2004 Specifically, this MIB contains network addresses, machines names, user names, application usage information, and conversation statistics. Data of this nature should be considered sensitive and the privacy of the users from whom it was gathered protected. Administrators should restrict read access to this data to specifically authorized individuals or agents that recognize the privacy implications of its release. In situations where read access to this data cannot be restricted, it should not be gathered. Systems that implement the objects in this MIB module have the capability of measuring the time taken to execute transactions. Depending on the transaction type, some or all of this transaction time may be associated with the time taken to perform security calculations. Such data may help an attacker to use timing attacks to extract secrets from the systems involved in the transactions. See [10] for more information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [8], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Waldbusser Standards Track [Page 59] RFC 3729 APM MIB March 2004 5. References 5.1. Normative References [1] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [4] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [5] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [6] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2895, August 2000. [7] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. 5.2. Informative References [8] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [9] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [10] Boneh, D. and D. Brumley, "Remote timing attacks are practical", Proceedings of 12th USENIX Security Symposium, August 2003. 6. Author's Address Steven Waldbusser EMail: waldbusser@nextbeacon.com Waldbusser Standards Track [Page 60] RFC 3729 APM MIB March 2004 7. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Waldbusser Standards Track [Page 61] snmp-mibs-downloader-1.1/mibrfcs/rfc3747.txt0000644000000000000000000014471311402176071015600 0ustar Network Working Group H. Hazewinkel, Ed. Request for Comments: 3747 I.Net Category: Standards Track D. Partain, Ed. Ericsson April 2004 The Differentiated Services Configuration MIB 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. Hazewinkel & Partain Standards Track [Page 1] RFC 3747 Differentiated Services Configuration MIB April 2004 Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Other Documents. . . . . . . . . . . . . . . . . . . . . . . . 3 4. Relationship to other MIBs . . . . . . . . . . . . . . . . . . 3 4.1. The Policy-based Management MIB Module . . . . . . . . . 3 4.2. The Differentiated Services MIB Module . . . . . . . . . 4 5. The Differentiated Services Configuration MIB Module Design. . 5 6. Template Cloning . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. An Approach to Template Cloning. . . . . . . . . . . . . 6 6.2. Example. . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2.1. The Initial Situation. . . . . . . . . . . . . . 8 6.2.2. The Configuration Template . . . . . . . . . . . 9 6.2.3. Applying the Template. . . . . . . . . . . . . . 11 6.2.4. Applying the Template Using SNMP Messages. . . . 14 7. Managed Objects Definitions (MIB Module) . . . . . . . . . . . 15 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23 11. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction This memo defines a MIB module that can be used to convey management information about desired network-wide Differentiated Services based policy behavior. This module is designed to integrate with the Differentiated Services MIB module [RFC3289] in order to provide template configurations for the Differentiated Services MIB module. The MIB module defined in this memo (the DIFFSERV-CONFIG-MIB) may be Hazewinkel & Partain Standards Track [Page 2] RFC 3747 Differentiated Services Configuration MIB April 2004 used in combination with the Policy-based Management MIB module [PMMIBDR], but that is not a requirement. Without the Policy-based Management MIB module, a management application must emulate behavior provided by the Policy-based Management MIB using equivalent "low- level" SNMP operations in normal manager/agent communication. Together, this memo, [RFC3289], and [PMMIBDR] represent an instance of an integrated architecture for both device-specific and network- wide policy (configuration) management, which is fully integrated with the Internet Standard Management Framework. The Differentiated Services MIB module [RFC3289] operates on a device level. The MIB module in this memo, the DIFFSERV-CONFIG-MIB, creates a coherent configuration management view as an umbrella over [RFC3289]. That is, the DIFFSERV-CONFIG-MIB provides a conceptual Application Program Interface (API) for configuration of the Differentiated Services parameters. Since the Differentiated Services MIB module is able to maintain configuration information, the DIFFSERV-CONFIG-MIB configuration API consists only of configuration template information and the start of the so-called functional datapath. 3. Other Documents It is assumed that the reader is familiar with Differentiated Services ([RFC2474] and [RFC2475]), the Policy-based Management MIB ([PMMIBDR]), and "Configuring Networks and Devices With SNMP" ([RFC3512]). These documents include all of the necessary terminology for understanding this memo. However, note that use of the MIB module in this memo does not require the use of [PMMIBDR]. [RFC3512] also provides an example MIB module which may help in understanding the relationship between DIFFSERV-CONFIG-MIB and the Differentiated Services MIB in [RFC3289]. 4. Relationship to other MIBs In this section, we describe the relationship of this MIB module to other MIB modules. The overall architecture used for policy configuration management is described in [PMMIBDR]. 4.1. The Policy-based Management MIB Module [PMMIBDR] defines a MIB module that enables policy-based configuration management of infrastructure using the Internet Standard Management Framework. The document includes a table for configuring policies to be implemented, tables for storing the roles of elements on a particular device, a table for representing the capabilities of a device with respect to policy management, a table Hazewinkel & Partain Standards Track [Page 3] RFC 3747 Differentiated Services Configuration MIB April 2004 for referencing elements affected by a policy, as well as other infrastructure. There is no requirement that [PMMIBDR] be used in conjunction with the MIB module defined in this memo. See [PMMIBDR] for a full description of the policy-based configuration framework it provides. 4.2. The Differentiated Services MIB Module The Differentiated Services MIB module [RFC3289] provides a common set of managed objects useful for configuring Differentiated Services parameters on a Differentiated Services capable device. This is what is referred to as instance-level configuration. It is the alteration of the instance-level information in that MIB module which may be done using the objects in the MIB module defined in this memo. It is recognized that vendors may include additional managed objects in their devices (via vendor-specific MIB modules) for configuring Differentiated Services parameters. If a vendor chooses to use the objects defined in this memo for configuration, the vendor should provide additional managed objects in a similar approach as defined for the Differentiated Services MIB module. Since the managed objects of the Differentiated Services MIB [RFC3289] are not directly associated with an instance (interface and interface direction), the same managed objects can be used for traffic treatment configuration templates in a Differentiated Services capable device and can then be applied on multiple instances. Therefore, the tables as defined in the Differentiated Services MIB can be used directly for template configuration purposes. Those tables are: - diffServClfrTable - diffServClfrElementTable - diffServMultiFieldClfrTable - diffServMeterTable - diffServTBParamTable - diffServActionTable - diffServDscpMarkActTable - diffServCountActTable - diffServAlgDropTable - diffServRandomDropTable - diffServQTable - diffServSchedulerTable - diffServMinRateTable - diffServMaxRateTable Hazewinkel & Partain Standards Track [Page 4] RFC 3747 Differentiated Services Configuration MIB April 2004 Readers familiar with the Differentiated Services MIB will notice that these are all templates. Only the diffServDataPathTable defines a managed instance for Differentiated Services traffic treatment by its indexes of the interface and its direction. This also allows the tables mentioned above to be used as a configuration template without defining anything directly related to a managed instance. 5. The Differentiated Services Configuration MIB Module Design The Differentiated Services Configuration MIB module (in this memo) of the SNMP-based configuration management framework is positioned between the Policy-based Management MIB module and the instance- specific Differentiated Services MIB module as described above. The MIB module found in this memo is designed to maintain configuration templates for the Differentiated Services MIB [RFC3289] module. The module only has a template table that describes a Differentiated Services traffic treatment by providing the starting pointer of the functional datapath. The templates represent a specific configuration of traffic treatment in a functional datapath of a Differentiated Services capable device. To avoid duplication of managed objects, the actual templates defining the functional datapath are defined in the Differentiated Services MIB module. These are also used for the management of the instances. Therefore, the implementation of the DIFFSERV-CONFIG-MIB module uses the tables defined in the Differentiated Services MIB. As soon as a configuration is made active via the POLICY-MANAGEMENT-MIB or using normal SNMP operations, the configuration defined within this MIB module will be instantiated in the DIFFSERV-MIB. Note that this is a conceptual process. That is, the configuration may not actually go through an API available in the subsystem which implements the DIFFSERV-MIB module. However, configuration via the DIFFSERV-CONFIG-MIB module will alter the same instrumentation as the DIFFSERV-MIB module whether it does it via the DIFFSERV-MIB module or not. The Differentiated Services Configuration MIB module only needs to define a starting point of a traffic treatment configuration template. This table is similar to the diffServDataPathTable [RFC3289]. However, it has a semantic difference in that the diffServDataPathTable is associated with an instance (interface and interface direction), whereas the diffServConfigTable in this memo is not. Hazewinkel & Partain Standards Track [Page 5] RFC 3747 Differentiated Services Configuration MIB April 2004 Unlike most MIB modules, changes to the managed objects in this MIB module do not cause a change in the external/traffic behavior of the device. This MIB module is used to set up per-hop-behavior configurations. As soon as configurations are made active via the POLICY-MANAGEMENT-MIB or SNMP operations, the configurations defined within this MIB module will be instantiated in the DIFFSERV-MIB. The only table in this MIB module is the diffServConfigTable, which provides managed objects for registering traffic treatment configurations used in differentiated services. The sole purpose of this table is to provide the starting point for a traffic treatment configuration template. The traffic treatment itself is performed by functional datapath elements [RFC3289]. 6. Template Cloning The concept of the DIFFSERV-CONFIG-MIB is based on having traffic treatment configuration templates. The templates provide a set of configuration values that provide a particular behavior, such as Expedited Forwarding traffic treatment, in the functional datapath. The template (or functional datapath) is similar to a linked list from a starting point and each (functional datapath) element is connected to the next element via the so-called next RowPointer. The moment a template is activated (instantiated) on an interface and its interface direction, the template needs to be copied/cloned, so that the template remains as a template. Note that the template is logically "locked" through the cloning process. That is, the template cannot be changed part way through the cloning process. With the exception of the indices, the cloned template will be identical to the source template. A literal copy/clone of the template is not possible, since the same indices inside the element tables cannot be re-used. The instantiation process must therefore generate a new index for each element. As a result of this, the 'NEXT' pointers also need to be updated. Otherwise, those will point to the template. 6.1. An Approach to Template Cloning What should a system containing Differentiated Services capabilities and Differentiated Services configuration capabilities do conceptually at the moment a template is activated on an interface? The following approach should not be considered implementation guidelines, but rather a conceptual explanation of what should be done. Hazewinkel & Partain Standards Track [Page 6] RFC 3747 Differentiated Services Configuration MIB April 2004 1) Get the index of the template to be activated 2) Get RowPointer (current) from diffServConfigStart.index of the diffServConfigTable 3) Check if RowPointer (current) exists 4) Logically "lock" the entry (current) pointed to by RowPointer so that its values are not changed part way through the cloning process. 5) Copy/Clone the entry (current) pointed to by RowPointer a) Get a new index for the entry b) Configure the new entry with the values of the entry to be cloned c) Update the NEXT pointer with a new RowPointer that pointed to the previous entry that was copied part of this template 6) Store RowPointer of cloned entry as (previous) in order to update the NEXT pointer with the next cloned entry. 7) Get the RowPointer of the next element in the template as (current) 8) If (current) RowPointer does not equal zeroDotZero go to 4 9) Logically "unlock" all the locked entries done by step 4). If a configuration/template is activated via a means other than a direct SNMP SET request, such as via the Policy-based Management MIB, the handling of the activation and potential error response code must be provided via that mechanism. If a configuration/template is activated using SNMP SET requests, an accurate error response value must be returned. For example, if a configuration/template has inconsistent values, the SNMP SET should return an error. Whether the configuration is already finished is not of direct importance, since the SNMP SET response must be accurate. On systems where the activation may take a long time, a response may be given prior to completion, but extra mechanisms must be provided to detect any errors. 6.2. Example This section provides an example of the process described in the previous section. This example will show a Differentiated Services capable incoming (ingress) interface that only counts the traffic stream. Then, with the policy-based configuration concept as defined in this document and in [PMMIBDR], a traffic marking configuration will be applied. The example will walk the reader through all of the steps involved in this process. Again, the use of [PMMIBDR] is simply an example and is not required. Hazewinkel & Partain Standards Track [Page 7] RFC 3747 Differentiated Services Configuration MIB April 2004 NOTE WELL: For brevity and clarity, the example does not always show the complete entry (row) of a table. The only objects shown are those needed for creating the row pointers to the next functional datapath element or needed to provide information about the specific parameters of the functional datapath elements. The column named 'INDEX' always defines the complete index as defined for the associated entry. In some cases, this is a combined index of multiple components. Therefore, the names of the columns are omitted. Also note that the values Assured Forwarding and Expedited Forwarding are abstracted as DSCP(AF) and DSCP(EF) (respectively) or simply as AF and EF. For the actual values refer to [RFC3289]. 6.2.1. The Initial Situation The initial configuration is the existing configuration of an ingress interface. +------------------------------------------------------------+ | ingress functional datapath | | +----------+ | -->|----------->----------->| count |----------->----------->|--> | +----------+ | +------------------------------------------------------------+ This figure depicts a simple traffic treatment functional datapath for an ingress interface. The functional datapath only consists of a count action. Within the DIFFSERV-MIB, this would be instantiated as follows. Note that RowPointer objects must point to the first accessible columnar object in the conceptual row. Thus, while perhaps more instructive to use the index value for the RowPointer object's value (e.g., diffServCountActId.1) in the example, it would nonetheless be incorrect, and the first accessible columnar object has been used as should be done (e.g., diffServCountActOctets.1). diffServDataPathTable +-----------------+-----------------------------+-- | INDEX | diffServDataPathStart | +-----------------+-----------------------------+-- | ifIndex.ingress | diffServActionNext.1 | +-----------------+-----------------------------+-- Hazewinkel & Partain Standards Track [Page 8] RFC 3747 Differentiated Services Configuration MIB April 2004 diffServActionTable +-------+--------------------+-------------------------+-- | INDEX | diffServActionNext |diffServActionSpecific | +-------+--------------------+-------------------------+-- | 1 | 0.0 |diffServCountActOctets.1 | +-------+--------------------+-------------------------+-- diffServCountActTable +-------+------------------------+-- | INDEX | diffServCountActOctets | +-------+------------------------+-- | 1 | | +-------+------------------------+-- 6.2.2. The Configuration Template The following provides an example of a policy configuration in which traffic is classified by a specific IP filter, that results in two classifiers (one for the IP filter and one for match all). Both streams are then metered, marked, and counted. This is an example of usage on the edge (an ingress interface) of a Differentiated Services domain that wants to have Expedited Forwarding and Assured Forwarding marked traffic within the Differentiated Services domain. +------------------------------------------------------------+ | ingress functional datapath | | +------------+ +-------+ +---------+ +---------+ | | | | | | | action: | | action: | | -->|-->| classifier |-->| meter |-->| mark EF |-->| count |-->|-----> | | match | | | | | | | | | +------------+ +-------+ +---------+ +---------+ | | | \ | | | \ +---------+ | | | \ | action: | |routing | | * -->| dropper | |core | | / | | | | | / +---------+ | | V / | | +------------+ +-------+ +---------+ +---------+ | | | | | | | action: | | action: | | | | classifier |-->| meter |-->| mark AF |-->| count |-->|-----> | | match all | | | | | | | | | +------------+ +-------+ +---------+ +---------+ | +------------------------------------------------------------+ This figure depicts a policy configuration for ingress traffic treatment in a Differentiated Services capable device. The Hazewinkel & Partain Standards Track [Page 9] RFC 3747 Differentiated Services Configuration MIB April 2004 configuration is represented as follows in the DIFFSERV-CONFIG-MIB module and the DIFFSERV-MIB module. Note that the original (existing) traffic treatment described in 6.2.1 is also in the tables. Note also that in the diffServDscpMarkActTable, DSCP(EF) represents the DSCP value for Expedited Forwarding and DSCP(AF) represents the DSCP value for Assured Forwarding. diffServConfigTable (in the MIB module in this memo) +-------+-------------------------+---------------------------+-- | INDEX | diffServConfigStart | diffServConfigDescr | +-------+-------------------------+---------------------------+-- | "foo" | diffServClfrStorage.1 | Example traffic treatment | +-------+-------------------------+---------------------------+-- diffServClfrTable +-------+---------------------+--------------------+ | INDEX | diffServClfrStorage | diffServClfrStatus | +-------+---------------------+--------------------+ | 1 | | | +-------+---------------------+--------------------+ diffServClfrElementTable (shares index with diffServClfrTable) +-------+---------------------------+-------------------------------+-- | INDEX | diffServClfrElementNext | diffServClfrElementPrecedence | +-------+---------------------------+-------------------------------+-- | 1.1 |diffServMeterSucceedNext.1 | 1 | | 1.2 |diffServMeterSucceedNext.2 | 2 | +-------+---------------------------+-------------------------------+-- diffServMeterTable +-------+--------------------------+-----------------------+-- | INDEX | diffServMeterSucceedNext |diffServMeterFailNext | +-------+--------------------------+-----------------------+-- | 1 | diffServActionNext.2 | diffServAlgDropType.1 | | 2 | diffServActionNext.3 | diffServAlgDropType.1 | +-------+--------------------------+-----------------------+-- Hazewinkel & Partain Standards Track [Page 10] RFC 3747 Differentiated Services Configuration MIB April 2004 diffServActionTable +-------+----------------------+----------------------------+-- | INDEX | diffServActionNext | diffServActionSpecific | +-------+----------------------+----------------------------+-- | 1 | 0.0 | diffServCountActOctets.1 | | 2 | diffServActionNext.4 | diffServDscpMarkActDscp.EF | | 3 | diffServActionNext.5 | diffServDscpMarkActDscp.AF | | 4 | 0.0 | diffServCountActOctets.2 | | 5 | 0.0 | diffServCountActOctets.3 | +-------+----------------------+----------------------------+-- diffServCountActTable +-------+------------------------+-- | INDEX | diffServCountActOctets | +-------+------------------------+-- | 1 | | | 2 | | | 3 | | +-------+------------------------+-- diffServAlgDropTable +-------+---------------------+-------------------------+-- | INDEX | diffServAlgDropType | diffServAlgDropSpecific | +-------+---------------------+-------------------------+-- | 1 | alwaysDrop(5) | 0.0 | +-------+---------------------+-------------------------+-- diffServDscpMarkActTable +-------------------------+ | diffServDscpMarkActDscp | +-------------------------+ | DSCP(EF) | | DSCP(AF) | +-------------------------+ 6.2.3. Applying the Template Now we have the original ingress interface configuration and the policy configuration we want to apply to the actual interface. The example policy must provide the required Differentiated Services traffic treatment to all interfaces used by system administrators. The traffic treatment required is described in 6.2.2 above. Therefore, we have the following example policy which is configured via the POLICY-BASED-MANAGEMENT-MIB module (see [PMMIBDR]): if ( roleMatch("Administrator") ) Hazewinkel & Partain Standards Track [Page 11] RFC 3747 Differentiated Services Configuration MIB April 2004 then /* * The $0 gets the "element" returned from the previous * statement. the .1 at the end is the ingress interface * This sets, for example, diffServDataPathStart.3.1 to be * "diffServConfigStart.3.f.o.o" if interface 3 has the role * "Administrator". */ setVar("diffServDataPathStart.$0.1", "diffServConfigStart.3.f.o.o", Oid) For our purposes, we only apply this on the inbound (ingress) direction of the interface. Note that although object descriptors are used in this PolicyScript example, the object identifiers must be used in the running script. For more information on policies and their syntax refer to [PMMIBDR]. The following tables in this section provide the cloned entries in the tables of the DIFFSERV-MIB module. All tables may have columns that contain contents or administrative objects that are not shown. These columns do not determine a function in the datapath and they are not shown for clarity of the cloning mechanism. Note that the original (existing) traffic treatment of 6.2.1 and 6.2.2 are also in the tables. diffServConfigTable +-------+-------------------------+---------------------------+-- | INDEX | diffServConfigStart | diffServConfigDescr | +-------+-------------------------+---------------------------+-- | "foo" | diffServClfrStorage.1 | Example traffic treatment | +-------+-------------------------+---------------------------+-- diffServDataPathTable +-----------------+-----------------------------+-- | INDEX | diffServDataPathStart | +-----------------+-----------------------------+-- | ifIndex.ingress | diffServActionNext.2 | +-----------------+-----------------------------+-- Hazewinkel & Partain Standards Track [Page 12] RFC 3747 Differentiated Services Configuration MIB April 2004 diffServClfrTable +-------+---------------------+--------------------+ | INDEX | diffServClfrStorage | diffServClfrStatus | +-------+---------------------+--------------------+ | 1 | | | | 2 | | | +-------+---------------------+--------------------+ diffServClfrElementTable +-------+----------------------------+-------------------------------+-- | INDEX | diffServClfrElementNext | diffServClfrElementPrecedence | +-------+----------------------------+-------------------------------+-- | 1.1 | diffServMeterSucceedNext.1 | 1 | | 1.2 | diffServMeterSucceedNext.2 | 2 | | 2.3 | diffServMeterSucceedNext.3 | 1 | | 2.4 | diffServMeterSucceedNext.4 | 2 | +-------+----------------------------+-------------------------------+-- diffServMeterTable +-------+--------------------------+-----------------------+-- | INDEX | diffServMeterSucceedNext | diffServMeterFailNext | +-------+--------------------------+-----------------------+-- | 1 | diffServActionNext.2 | diffServAlgDropType.1 | | 2 | diffServActionNext.3 | diffServAlgDropType.1 | | 3 | diffServActionNext.6 | diffServAlgDropType.2 | | 4 | diffServActionNext.7 | diffServAlgDropType.2 | +-------+--------------------------+-----------------------+-- diffServActionTable +-------+----------------------+----------------------------+-- | INDEX | diffServActionNext | diffServActionSpecific | +-------+----------------------+----------------------------+-- | 1 | 0.0 | diffServCountActOctets.1 | | 2 | diffServActionNext.4 | diffServDscpMarkActDscp.EF | | 3 | diffServActionNext.5 | diffServDscpMarkActDscp.AF | | 4 | 0.0 | diffServCountActOctets.2 | | 5 | 0.0 | diffServCountActOctets.3 | | 6 | diffServActionNext.8 | diffServDscpMarkActDscp.EF | | 7 | diffServActionNext.9 | diffServDscpMarkActDscp.AF | | 8 | 0.0 | diffServCountActOctets.4 | | 9 | 0.0 | diffServCountActOctets.5 | +-------+----------------------+----------------------------+-- Hazewinkel & Partain Standards Track [Page 13] RFC 3747 Differentiated Services Configuration MIB April 2004 diffServCountActTable +-------+------------------------+-- | INDEX | diffServActCountOctets | +-------+------------------------+-- | 1 | | | 2 | | | 3 | | | 4 | | | 5 | | +-------+------------------------+-- diffServAlgDropTable +-------+---------------------+-------------------------+-- | INDEX | diffServAlgDropType | diffServAlgDropSpecific | +-------+---------------------+-------------------------+-- | 1 | alwaysDrop(5) | 0.0 | +-------+---------------------+-------------------------+-- diffServDscpMarkActTable +-------------------------+ | diffServDscpMarkActDscp | +-------------------------+ | DSCP(EF) | | DSCP(AF) | +-------------------------+ As one can see in the example, the main elements from which a functional datapath is constructed are duplicated/copied/cloned. That process is needed in order to preserve the policy configuration for reuse at a later time. It is up to the SNMP agent to keep track of which network interfaces are under policy control and which policy rules are being used. This avoids duplication of policy enforcement. How the agent does this is an implementation issue. One can see that the old functional datapath configurations stay in the MIB module tables. It is up to the SNMP agent implementation to decide whether to delete stale entries or keep them. Garbage collection of stale entries is an implementation issue. 6.2.4. Applying the Template Using SNMP Messages In this section, the above example is explained by using SNMP communication between the SNMP "manager" and the SNMP "agent". Hazewinkel & Partain Standards Track [Page 14] RFC 3747 Differentiated Services Configuration MIB April 2004 In order to apply the template to all interfaces that have a role match of "Administrator," the SNMP manager must have a list of the roles of the interface. This means the SNMP manager must do an SNMP-SET for all those interfaces. This is expressed in the following pseudo code function. set_template_if_administrator_interface( , ) { template_oid = SNMP-GET("diffServConfigStart."); foreach interface () { if (interface.role == "Administrator") { SNMP-SET("diffServDataPathStart.$interface.1", Oid, template_oid); } } } For example, on a system with 3 interfaces, the following list would be known to the manager. The first value indicates the interface number (ifIndex) and the second value is its role. interface_list IF_LIST = { { 1, ... , "Administrator", ... }, { 2, ... , "User", ... }, { 3, ... , "Administrator", ... } } This will result in the communication between a manager and agent of 1 SNMP-GET and 2 SNMP-SETs: - SNMP-GET("diffServConfigStart.3.f.o.o") - SNMP-SET("diffServDataPathStart.1.1", Oid, "diffServActionNext.1") - SNMP-SET("diffServDataPathStart.3.1", Oid, "diffServActionNext.1") 7. Managed Objects Definitions (MIB Module) DIFFSERV-CONFIG-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, zeroDotZero, mib-2 FROM SNMPv2-SMI -- [RFC2578] RowStatus, StorageType, RowPointer, DateAndTime FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] Hazewinkel & Partain Standards Track [Page 15] RFC 3747 Differentiated Services Configuration MIB April 2004 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] diffServConfigMib MODULE-IDENTITY LAST-UPDATED "200401220000Z" -- 22 January 2004 ORGANIZATION "SNMPCONF WG" CONTACT-INFO "SNMPCONF Working Group http://www.ietf.org/html.charters/snmpconf-charter.html WG mailing list: snmpconf@snmp.com Editors: Harrie Hazewinkel I.Net via Darwin 85 20019 - Settimo Milanese (MI) Italy EMail: harrie@inet.it David Partain Ericsson AB P.O. Box 1248 SE-581 12 Linkoping Sweden E-mail: David.Partain@ericsson.com" DESCRIPTION "This MIB module contains differentiated services specific managed objects to perform higher-level configuration management. This MIB allows policies to use 'templates' to instantiate Differentiated Services functional datapath configurations to be assigned (associated with an interface and direction) when a policy is activated. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3747; see the RFC itself for full legal notices." REVISION "200401220000Z" -- 22 January 2004 DESCRIPTION "Initial version published as RFC 3747" ::= { mib-2 108 } diffServConfigMIBObjects OBJECT IDENTIFIER ::= { diffServConfigMib 1 } diffServConfigMIBConformance OBJECT IDENTIFIER ::= { diffServConfigMib 2 } -- -- The Differentiated Services configuration objects -- Hazewinkel & Partain Standards Track [Page 16] RFC 3747 Differentiated Services Configuration MIB April 2004 diffServConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF DiffServConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table which defines the various per-hop-behaviors for which the system has default 'templates'." ::= { diffServConfigMIBObjects 2 } diffServConfigEntry OBJECT-TYPE SYNTAX DiffServConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry defining a per-hop-behavior. Each entry in this table combines the various parameters (entries) into a specific per-hop-behavior. Entries in this table might be defined by a vendor (pre-configured) or defined by a management application." INDEX { diffServConfigId } ::= { diffServConfigTable 1 } DiffServConfigEntry ::= SEQUENCE { diffServConfigId SnmpAdminString, diffServConfigDescr SnmpAdminString, diffServConfigOwner SnmpAdminString, diffServConfigLastChange DateAndTime, diffServConfigStart RowPointer, diffServConfigStorage StorageType, diffServConfigStatus RowStatus } diffServConfigId OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..116)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique id for the per-hop-behavior policy for at least the SNMP agent. For ease of administration the value may be unique within an administrative domain, but this is not required. The range of up to 116 octets is chosen to stay within the SMI limit of 128 sub-identifiers in an object identifier." ::= { diffServConfigEntry 1 } diffServConfigDescr OBJECT-TYPE Hazewinkel & Partain Standards Track [Page 17] RFC 3747 Differentiated Services Configuration MIB April 2004 SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A human-readable description to identify this defined per-hop-behavior. Note that this is an SnmpAdminString, which permits UTF-8 strings. An administratively assigned identifier for a template that would be unique within an administrative domain. It is up to the management applications to agree how these are assigned within the administrative domain. Once a description, such as 'EF' is assigned, that has a certain set of parameters that achieve 'EF' from box to box. Management application code or script code can then scan the table to find the proper template and then assign it." ::= { diffServConfigEntry 2 } diffServConfigOwner OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner who created this entry." ::= { diffServConfigEntry 3 } diffServConfigLastChange OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when this entry was last changed." ::= { diffServConfigEntry 4 } diffServConfigStart OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "The pointer to a functional datapath configuration template as set up in the DIFFSERV-MIB. This RowPointer should point to an instance of one of: diffServClfrEntry diffServMeterEntry diffServActionEntry diffServAlgDropEntry diffServQEntry Hazewinkel & Partain Standards Track [Page 18] RFC 3747 Differentiated Services Configuration MIB April 2004 A value of zeroDotZero in this attribute indicates no further Diffserv treatment is performed on traffic of this functional datapath. This also means that the template described by this row is not defined. If the row pointed to does not exist, the treatment is as if this attribute contains a value of zeroDotZero." REFERENCE "Differentiated Services MIB module" DEFVAL { zeroDotZero } ::= { diffServConfigEntry 5 } diffServConfigStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of storage used for this row. Since an entry in this table serves as a starting point for a configuration, it is recommended that all entries comprising the configuration started by diffServConfigStart follow the storage type of this entry. Otherwise, after agent reboots a configuration may differ. It may very well be that the agent is not capable of detecting such changes and therefore, the management application should verify the correct configuration after a reboot. Rows with a StorageType of 'permanent' do not need to allow write access to any of the columnar objects in that row." DEFVAL { nonVolatile } ::= { diffServConfigEntry 6 } diffServConfigStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "RowStatus object used for creation and deletion of rows in this table. All writable objects in this row may be modified at any time." DEFVAL { notInService } ::= { diffServConfigEntry 7 } -- -- MIB Compliance statements. -- Hazewinkel & Partain Standards Track [Page 19] RFC 3747 Differentiated Services Configuration MIB April 2004 diffServConfigMIBCompliances OBJECT IDENTIFIER ::= { diffServConfigMIBConformance 1 } diffServConfigMIBGroups OBJECT IDENTIFIER ::= { diffServConfigMIBConformance 2 } diffServConfigMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The full compliance for this MIB module. For this compliance level the 'diffServMIBFullCompliance' must be met, since this MIB module depends on it in order to provide the configuration entries. " MODULE -- This module MANDATORY-GROUPS { diffServConfigMIBConfigGroup } OBJECT diffServConfigStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." ::= { diffServConfigMIBCompliances 1 } diffServConfigMIBConfigGroup OBJECT-GROUP OBJECTS { diffServConfigDescr, diffServConfigOwner, diffServConfigLastChange, diffServConfigStart, diffServConfigStorage, diffServConfigStatus } STATUS current DESCRIPTION "The per-hop-behavior Group defines the MIB objects that describe the configuration template for the per-hop-behavior." ::= { diffServConfigMIBGroups 1 } END 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These managed objects are: Hazewinkel & Partain Standards Track [Page 20] RFC 3747 Differentiated Services Configuration MIB April 2004 - The diffServConfigDescr, diffServConfigOwner, and diffServConfigStatus are not security sensitive since these three objects do not affect any direct operational behavior of a diffserv capable device. - Unauthorized change of the diffServConfigStart could lead to a different configuration, and the 'changed' configuration could lead to different traffic treatment for the diffserv capable device than desired. - Unauthorized change of the diffServConfigStorage could lead to unknown behavior of the diffserv capable device after a reboot of the SNMP agent. This may be caused by 'not having saved changes of the configuration' or unavailable configurations. In addition, the managed objects of the DIFFSERV-MIB are also security sensitive, since unauthorized changes may cause configuration changes. For more detail, refer to [RFC3289]. Allowing read access to objects in this MIB module is generally not considered sensitive, as read access only provides information that a template exists. This is due to the fact that the managed objects that actually instantiate the template are in the DIFFSERV-MIB [RFC3289]. However, in environments where the template description (diffServConfigDescr) or owner (diffServConfigOwner) is considered sensitive information, appropriate access control should be exercised for these objects. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, deployment of SNMPv3 with cryptographic security enabled is RECOMMENDED. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to GET or SET (change/create/delete) them. Hazewinkel & Partain Standards Track [Page 21] RFC 3747 Differentiated Services Configuration MIB April 2004 9. Acknowledgments The editors gratefully acknowledge the significant contributions to this work made by several members of both the SNMPCONF and DiffServ working groups. 10. References 10.1. Normative References [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3289] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Hazewinkel & Partain Standards Track [Page 22] RFC 3747 Differentiated Services Configuration MIB April 2004 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC3512] MacFaden, M., Partain, D., Saperia, J. and W. Tackabury, "Configuring Networks and Devices with Simple Network Management Protocol (SNMP)", RFC 3512, April 2003. [PMMIBDR] Waldbusser, S., Saperia, J. and T. Hongal, "Policy-based Management MIB", Work in Progress. 11. Editors' Addresses Harrie Hazewinkel I.Net via Darwin 85 20019 - Settimo Milanese (MI) Italy EMail: harrie@inet.it David Partain Ericsson AB P.O. Box 1248 SE-581 12 Linkoping Sweden EMail: David.Partain@ericsson.com Hazewinkel & Partain Standards Track [Page 23] RFC 3747 Differentiated Services Configuration MIB April 2004 12. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hazewinkel & Partain Standards Track [Page 24] snmp-mibs-downloader-1.1/mibrfcs/rfc3805.txt0000644000000000000000000131455011402176071015572 0ustar Network Working Group R. Bergman Request for Comments: 3805 Hitachi Printing Solutions Obsoletes: 1759 H. Lewis Category: Standards Track IBM Corporation I. McDonald High North Inc. June 2004 Printer MIB v2 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. Bergman, et al. Standards Track [Page 1] RFC 3805 Printer MIB v2 June 2004 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Network Printing Environment. . . . . . . . . . . . . . 4 1.2. Printer Device Overview . . . . . . . . . . . . . . . . 6 1.3. Categories of Printer Information . . . . . . . . . . . 6 1.3.1. Descriptions. . . . . . . . . . . . . . . . . . 6 1.3.2. Status. . . . . . . . . . . . . . . . . . . . . 6 1.3.3. Alerts. . . . . . . . . . . . . . . . . . . . . 6 1.4. The Internet-Standard Management Framework. . . . . . . 7 1.5. Requirement Levels. . . . . . . . . . . . . . . . . . . 7 2. Printer Model . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Overview of the Printer Model . . . . . . . . . . . . . 10 2.2. Printer Sub-Units . . . . . . . . . . . . . . . . . . . 10 2.2.1. General Printer . . . . . . . . . . . . . . . . 10 2.2.1.1. International Considerations. . . . . 10 2.2.2. Inputs. . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Media . . . . . . . . . . . . . . . . . . . . . 12 2.2.4. Outputs . . . . . . . . . . . . . . . . . . . . 12 2.2.5. Finishers . . . . . . . . . . . . . . . . . . . 12 2.2.6. Markers . . . . . . . . . . . . . . . . . . . . 13 2.2.7. Media Paths . . . . . . . . . . . . . . . . . . 13 2.2.8. System Controller . . . . . . . . . . . . . . . 14 2.2.9. Interfaces. . . . . . . . . . . . . . . . . . . 14 2.2.10. Print Job Delivery Channels . . . . . . . . . . 14 2.2.11. Interpreters. . . . . . . . . . . . . . . . . . 15 2.2.12. Console . . . . . . . . . . . . . . . . . . . . 15 2.2.13. Alerts. . . . . . . . . . . . . . . . . . . . . 15 2.2.13.1. Status and Alerts . . . . . . . . . . 16 2.2.13.2. Overall Printer Status. . . . . . . . 16 2.2.13.2.1. Host Resources MIB Printer Status. . . . . . 18 2.2.13.2.2. Sub-unit Status . . . . . 20 2.2.13.3. Alert Tables. . . . . . . . . . . . . 21 2.2.13.4. Alert Table Management. . . . . . . . 21 2.3. Read-Write Objects. . . . . . . . . . . . . . . . . . . 23 2.4. Enumerations. . . . . . . . . . . . . . . . . . . . . . 24 2.4.1. Registering Additional Enumerated Values. . . . 25 3. Groups from other MIB Specifications. . . . . . . . . . . . . 25 3.1. System Group. . . . . . . . . . . . . . . . . . . . . . 25 3.2. System Controller . . . . . . . . . . . . . . . . . . . 25 3.3. Interface Group objects . . . . . . . . . . . . . . . . 26 3.3.1. Interface Types . . . . . . . . . . . . . . . . 26 4. Differences from RFC 1759 . . . . . . . . . . . . . . . . . . 26 5. The IANA Printer MIB. . . . . . . . . . . . . . . . . . . . . 29 6. The Printer MIB . . . . . . . . . . . . . . . . . . . . . . . 56 -- Textual conventions for this MIB module. . . . . . . . . . 59 -- The General Printer Group. . . . . . . . . . . . . . . . . 67 Bergman, et al. Standards Track [Page 2] RFC 3805 Printer MIB v2 June 2004 -- The Responsible Party group. . . . . . . . . . . . . . . . 70 -- The Auxiliary Sheet Group. . . . . . . . . . . . . . . . . 73 -- Administrative section (The General V2 Group) . . . . . . 74 -- General alert table section (Alert Table V2 Group). . . . 74 -- The Cover Table. . . . . . . . . . . . . . . . . . . . . . 75 -- The Localization Table . . . . . . . . . . . . . . . . . . 76 -- The System Resources Tables. . . . . . . . . . . . . . . . 78 -- The Input Group. . . . . . . . . . . . . . . . . . . . . . 81 -- The Extended Input Group . . . . . . . . . . . . . . . . . 86 -- The Input Media Group. . . . . . . . . . . . . . . . . . . 87 -- The Input Switching Group. . . . . . . . . . . . . . . . . 89 -- The Output Group . . . . . . . . . . . . . . . . . . . . . 90 -- The Extended Output Group. . . . . . . . . . . . . . . . . 93 -- The Output Dimensions Group. . . . . . . . . . . . . . . . 95 -- The Output Features Group. . . . . . . . . . . . . . . . . 97 -- The Marker Group . . . . . . . . . . . . . . . . . . . . . 98 -- The Marker Supplies Group. . . . . . . . . . . . . . . . . 104 -- The Marker Colorant Group. . . . . . . . . . . . . . . . . 107 -- The Media Path Group . . . . . . . . . . . . . . . . . . . 109 -- The Print Job Delivery Channel Group . . . . . . . . . . . 113 -- The Interpreter Group. . . . . . . . . . . . . . . . . . . 115 -- The Console Group. . . . . . . . . . . . . . . . . . . . . 120 -- The Alerts Group . . . . . . . . . . . . . . . . . . . . . 125 -- Conformance Information. . . . . . . . . . . . . . . . . . 129 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147 8. Internationalization Considerations . . . . . . . . . . . . . 147 9. Security Considerations . . . . . . . . . . . . . . . . . . . 148 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 150 10.1. Normative References. . . . . . . . . . . . . . . . . . 150 10.2. Informative References. . . . . . . . . . . . . . . . . 151 Appendix A - Glossary of Terms. . . . . . . . . . . . . . . . . . 153 Appendix B - Media Size Names . . . . . . . . . . . . . . . . . . 156 Appendix C - Media Names. . . . . . . . . . . . . . . . . . . . . 158 Appendix D - Roles of Users . . . . . . . . . . . . . . . . . . . 162 Appendix E - Overall Printer Status Table . . . . . . . . . . . . 165 Appendix F - Participants . . . . . . . . . . . . . . . . . . . . 166 Significant Contributors. . . . . . . . . . . . . . . . . . . . . 168 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 170 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 171 Bergman, et al. Standards Track [Page 3] RFC 3805 Printer MIB v2 June 2004 1. Introduction 1.1. Network Printing Environment The management of producing a printed document, in any computer environment, is a complex subject. Basically, the task can be divided into two overlapping pieces, the management of printing and the management of the printer. Printing encompasses the entire process of producing a printed document from generation of the file to be printed, selection of a printer, choosing printing properties, routing, queuing, resource management, scheduling, and final printing including notifying the user. Most of the printing process is outside the scope of the model presented here; only the management of the printer is covered. Bergman, et al. Standards Track [Page 4] RFC 3805 Printer MIB v2 June 2004 Figure 1 - One Printer's View of the Network system printer asset user user user manager operator manager O O O O O O /|\ /|\ /|\ /|\ /|\ /|\ / \ / \ / \ / \ / \ / \ | | | | | | +---------+ +-------+ +-------+ +-------+ +-----------+ +-----------+ |configur-| |printer| | asset | |printer| | user | | user | |ator | |manager| |manager| |browser| |application| |application| +---------+ +-------+ +-------+ +-------+ +-----------+ +-----------+ ^ ^ ^ ^ | | |R/W |R/W |R |R +-----------+ +-----------+ | | | | | spooler | | spooler | | | | | +-----------+ +-----------+ | | | | | | | | | | +-----------+ +-----------+ | | | | |supervisor | |supervisor | | | | | +-----------+ +-----------+ | | | | ^ ^ ^ ^ | | | | |R |R/W |R |R/W v v | | | | | | ================================================== | ===== | | print| print| |SNMP data| data| +-----+ +-------+ PCL| PCL| | MIB |<------>| agent | PostScript| PostScript| +-----+ +-------+ NPAP| NPAP| |unspecified etc.| etc.| +=============+ +-----------------+ | | | |--|channel/interface|<--+ | | | +-----------------+ | | PRINTER | | | | +-----------------+ | | |--|channel/interface|<----------------+ +=============+ +-----------------+ Bergman, et al. Standards Track [Page 5] RFC 3805 Printer MIB v2 June 2004 1.2. Printer Device Overview A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. Printers are complex devices that consume supplies, produce waste and may have mechanical problems. In the management of the physical device the description, status and alert information concerning the printer and its various subparts has to be made available to the management application so that it can be reported to the end user, key operators for the replenishment of supplies or the repair or maintenance of the device. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. 1.3. Categories of Printer Information Information about printers is classified into three basic categories: descriptions, status and alerts. 1.3.1. Descriptions Descriptions convey information about the configuration and capabilities of the printer and its various sub-units. This information is largely static information and does not generally change during the operation of the system but may change as the printer is repaired, reconfigured or upgraded. The descriptions are one part of the visible state of the printer where state means the condition of being of the printer at any point in time. 1.3.2. Status Status is the information regarding the current operating state of the printer and its various sub-units. As an example of the use of status, a management application must be able to determine if the various sub-units are ready to print or are in some state that prevents printing or may prevent printing in the future. 1.3.3. Alerts An Alert is the representation of a reportable event in the printer. An event is a change in the state of the printer. Some of those state changes are of interest to a management application and are therefore reportable. Typically, these are the events that affect the printer's ability to print. Alerts usually occur asynchronously to the operation of the computer system(s) to which the printer is Bergman, et al. Standards Track [Page 6] RFC 3805 Printer MIB v2 June 2004 attached. For convenience below, "alert" will be used for both the event caused by a change in the printer's state and for the representation of that event. Alerts can be classified into two basic categories, critical and non- critical. A critical alert is one that is triggered by entry into a state in which the printer is stopped and printing can not continue until the condition that caused the critical alert is eliminated. "Out of paper", "toner empty" and "output bin full" are examples of critical alerts. Non-critical alerts are triggered by those events that enter a state in which printing is not stopped. Such a non- critical state may, at some future time, lead to a state in which printing may be stopped. Examples of these kinds of non-critical alerts are "input media low", "toner low" and "output bin nearly full". Or, a non-critical alert may simply provide information, such as signaling a configuration changed in the printer. Description, status and alert information about the printer can be thought of as a database describing the printer. The management application for a printer will want to view the printer data base differently depending on how and for what purposes the information in the database is needed. 1.4. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.5. Requirement Levels The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Compliant implementations must follow this specification. Bergman, et al. Standards Track [Page 7] RFC 3805 Printer MIB v2 June 2004 2. Printer Model In order to accomplish the management of the printer, an abstract model of the printer is needed to represent the sub-units from which the printer is composed. A printer can be described as consisting of 13 types of sub-units. It is important to note that the sub-units of a printer do not necessarily relate directly to any physically identifiable mechanism. Sub-units can also be a set of definable logical processes, such as interpreters for page description languages or command processors that set various operating modes of the printer. Figure 2 shows a block diagram of the printer and its basic 13 sub- units. Bergman, et al. Standards Track [Page 8] RFC 3805 Printer MIB v2 June 2004 Figure 2 - Printer Block Diagram Physical Connections | +-----------+ | | +-------------+ | | Interface |-+ | MIB-II | +-------------+ | +-----------+ | | +-------------+ | +-----------+ | Channel |-+ | Operator | | | | Console | +-------------+ +-----------+ | +-----------+ +---------+ | | | | +-----------+ +-------------+ | +-----------+ | | General | | Interpreter |-+ | Alerts |-+ | Printer | | | | | +-----------+ +-------------+ +-----------+ | +-------------------------------+ | System Controller | | HOST-RESOURCES-MIB | +-------------------------------+ +------+ +--------+ +--------+ | | | | | | +-------+ | +-------+ +---------+ | +-------+ +--------+ | | Input |-+ +--------+| | Marker |-+ +--------+| | Output |-+ | |===>| |+<==>| |<==>| |+==>| | +-------+ +--+ +--+ +---------+ +--+ +--+ +--------+ \ | || | || \ \ | || | || \ \ | || | || \ +--------+ | |+-------------------------| || +---------+ | | | +--------------------------+ || | | +----------+ | | Media Path |+ +----------+ | | Media |-+ +--------------------------------+ | Finisher |-+ |(optional)| |(optional)| +----------+ +----------+ Bergman, et al. Standards Track [Page 9] RFC 3805 Printer MIB v2 June 2004 2.1. Overview of the Printer Model The model has three basic parts: (1) the flow of a print file into an interpreter and onto the marker, (2) the flow of media through the marker and (3) the auxiliary sub-units that control and facilitate the two prior flows. The flow of the print data comes through a physical connection on which some form of transport protocol stack is running. The data provided by the transport protocol (interface) appears on a channel, which is the input to an interpreter. The interpreter converts the print data into a form suitable for marking on the media. The media resides in Input sub-units from which the media is selected and then transported via a Media Path first to a Marking sub-unit and then onto an Output sub-unit with (optionally) some finishing operations being performed. The auxiliary sub-units facilitate control of the printer, inquiry/control of the operator panel, reporting of alerts and the adaptation of the printer to various natural languages and characters sets. All the software sub-units run on the System Controller that represents the processor, memory and storage systems of the Printer. Each of the sub-units is discussed in more detail below. All of the sub-units other than the Alerts report only state information, either a description or a status. The Alerts sub-unit reports event information. 2.2. Printer Sub-Units A printer is composed of 13 types of sub-units, called groups. The following sections describe the different types of sub-units. 2.2.1. General Printer The general printer sub-unit is responsible for the overall control and status of the printer. There is exactly one general printer sub- unit in a printer. The General Printer Group in the model represents the general printer sub-unit. In addition to the providing the status of the whole printer and allowing the printer to be reset, this Group provides information on the status of the packaging of the printer, in particular, the covers. The general printer sub-unit is usually implemented on the system controller. 2.2.1.1. International Considerations The localization portion of the general printer sub-unit is responsible for identifying the natural language, country, and character set in which certain character strings are expressed in Bergman, et al. Standards Track [Page 10] RFC 3805 Printer MIB v2 June 2004 this MIB. Character sets are identified in this MIB using the IANACharset textual convention imported from the IANA Character Set MIB [CHARMIB]. There may be one or more localizations supported per printer. The available localizations are specified in the Localization table. Localization SHOULD only be performed on string objects which are named 'xxxDescription' (sub-unit descriptions) or 'prtConsoleDisplayBufferText' (local console text). The agent SHALL return all other character strings in coded character sets in which code positions 0-127 (decimal) are US-ASCII [ASCII]. The agent SHOULD return all other character strings in the UTF-8 [RFC3629] transform of ISO 10646 [ISO10646], to conform with the IETF Policy on Character Sets and Languages [RFC2277]. Control codes (code positions 0-31 and 127 decimal) SHALL NOT be used unless specifically required in the DESCRIPTION of an object. The character set portion of the general printer Localization table is responsible for identifying the possible character sets for the operator console, and network management requests for display objects. There may be one or more character sets per printer. Default coded character sets for interpreter unit and output octets are described in the interpreter sub-unit by prtInterpreterDefaultCharSetIn and prtInterpreterDefaultCharSetOut. These input/output character sets may be overridden by commands in the interpreter language itself. 2.2.2. Inputs Input sub-units are mechanisms that feed media to be marked on into the printer. A printer contains one or more input sub-units. The Input Group in the model represents these. The model does not distinguish fixed input bins from removable trays, except to report when a removable tray has been removed. There are as many input sub-units as there are distinctly selectable input "addresses". For example, if one tray has both a manual and auto feeding option, then this is two input sub-units if these two sources can be (must be) separately selected. However, the above would be considered one input sub-unit if putting a sheet in the manual feed slot overrides feeding from the contents of the tray. In the second case there is no way to separately select or address the manual feed slot. Bergman, et al. Standards Track [Page 11] RFC 3805 Printer MIB v2 June 2004 2.2.3. Media An input sub-unit can hold one or more instances of the media on which marking is to be done. Typically, there is a large set of possible media that can be associated with an input. The Media Group is an extension of the Input Group, which represents media in an input sub-unit. The Media Group only describes the current contents of each input and not the possible content of the input sub-unit. 2.2.4. Outputs Output sub-units are mechanisms that receive media that has been marked on. The Output Group in the model represents the one or more output mechanisms contained by a printer. The model does not distinguish fixed output bins from removable output bins, except to report when a removable bin has been removed. There are as many output sub-units as there are distinctly selectable output "addresses". Output sub-units can be addressed in two different ways: (1) as a set of "mailboxes" which are addressed by a specific mailbox selector such as a bin number or a bin name, or (2) as a set of "slots" into which multiple copies are collated. Sometimes both modes of using the output sub-units can be used on the same printer. All that is important from the viewpoint of the model is that the output units can be separately selected. 2.2.5. Finishers A finisher is a sub-unit that performs some operations on the media other than marking. The Finisher Group in the model represents the finisher sub-units. Some examples of finishing processes are stapling, punching, binding, inserting, or folding. Finishing processes may have supplies associated with the process. Stapling, binding, and punching are examples of processes that have supplies. A printer may have more than one finishing sub-unit and each finishing sub-unit may be associated with one or more output sub- units. Finishers are described in the companion Finisher MIB [RFC3806]. The model does not specify the exact interaction and sequencing between an output device and its associated finisher. It depends on the type of finishing process and the exact implementation of the printer system. This standard allows for the logical association of a finishing process with an output device but does not put any restrictions on the exact sequence or interaction with the associated output device. The output and finisher sub-units may or may not be separate identifiable physical mechanisms depending on the exact Bergman, et al. Standards Track [Page 12] RFC 3805 Printer MIB v2 June 2004 implementation of a printer. In addition, a single output device may be associated with multiple finishing sub-units and a single finishing sub-unit may be associated with multiple output devices. 2.2.6. Markers A marker is the mechanism that produces marks on the print media. The Marker Group in the model represents the marker sub-units and their associated supplies. A printer can contain one or more marking mechanisms. Some examples of multiple marker sub-units are a printer with separate markers for normal and magnetic ink or an image setter that can output to both a proofing device and final film. Each marking device can have its own set of characteristics associated with it, such as marking technology and resolution. In this model the marker sub-unit is viewed as very generalized and encompasses all aspects of a marking process. For example, in a xerographic process, the marking process as well as the fusing process would be included in the generalized concept of the marker. With the generalized concept of a marking process, the concept of multiple marking supplies associated with a single marking sub-unit results. For example, in the xerographic process, there is not only a supply of toner, but there can also be other supplies such as a fuser supply (e.g., fuser oil) that can be consumed and replaced separately. In addition there can be multiple supplies of toner for a single marker device, as in a color process. 2.2.7. Media Paths The media paths encompass the mechanisms in the printer that move the media through the printer and connect all other media related sub- units: inputs, outputs, markers and finishers. A printer contains one or more media paths. The Media Path Group in the model represents these. The Media Path group has some objects that apply to all paths plus a table of the separate media paths. In general, the design of the media paths determines the maximum speed of the printer as well as the maximum media size that the printer can handle. Media paths are complex mechanisms and can contain many different identifiable sub-mechanisms such as media movement devices, media buffers, duplex units and interlocks. Not all of the various sub-mechanisms reside on every media path. For example, one media path may provide printing only on one surface of the media (a simplex path) and another media path may have a sub- mechanism that turns the media over and feeds it a second time through the marker sub-unit (a duplex path). The duplex path may Bergman, et al. Standards Track [Page 13] RFC 3805 Printer MIB v2 June 2004 even have a buffer sub-mechanism that allows multiple copies of the obverse side to be held before the reverse side of all the copies is marked. 2.2.8. System Controller The System Controller is the sub-unit upon which the software components of the Printer run. The Host Resources MIB [RFC2790] represents the System Controller in the model. The Host Resources MIB allows for the specification of the processor(s), memory, disk storage, file system and other underlying sub-mechanisms of the printer. The controller can range from simple single processor systems to multiprocessor systems. In addition, controllers can have a full range of resources such as hard disks. The printer is modeled to have one system controller even though it may have more than one processor and multiple other resources associated with it. 2.2.9. Interfaces An interface is the communications port and associated protocols that are responsible for the transport of data to the printer. A printer has one or more interface sub-units. The interfaces are represented by the Interfaces Group of MIB-II [RFC1213], [RFC2863]. Some examples of interfaces are serial ports (with little or no protocol) and Ethernet ports on which one might run Internet IP, Novell IPX, etc. 2.2.10. Print Job Delivery Channels The print job delivery channel sub-units identify the independent sources of print data (here print data is the information that is used to construct printed pages and may have both data and control aspects). A printer may have one or more channels. The channel sub- units are represented by the Print Job Delivery Channel Group in the Model. The electronic path typically identifies each channel and service protocol used to deliver print data to the printer. A channel sub-unit may be independently enabled (allowing print data to flow) or disabled (stopping the flow of print data). It has a current Control Language that can be used to specify which interpreter is to be used for the print data and to query and change environment variables used by the interpreters (and SNMP). There is also a default interpreter that is to be used if an interpreter is not explicitly specified using the Control Language. Print Job Delivery Channel sub-units can, and usually are, based on an underlying interface. Bergman, et al. Standards Track [Page 14] RFC 3805 Printer MIB v2 June 2004 2.2.11. Interpreters The interpreter sub-units are responsible for the conversion of a description of intended print instances into images that are to be marked on the media. A printer may have one or more interpreters. The Interpreter Group in the Model represents the interpreter sub- units. Each interpreter is generally implemented with software running on the System Controller sub-unit. The Interpreter Table has one entry per interpreter where the interpreters include both Page Description Language (PDL) Interpreters and Control Language Interpreters. 2.2.12. Console Many printers have a console on the printer, the operator console that is used to display and modify the state of the printer. The console can be as simple as a few indicators and switches or as complicated as full screen displays and keyboards. There can be at most one such console. The Console Group in the model represents this console sub-unit. Although most of the information displayed there is also available in the state of the printer as represented by the various Groups, it is useful to be able to query and modify the operator console remotely. For example, a management application might like to display to its user the current message on the operator console of the remote printer or the management application user might like to modify the current message on the operators console of the remote printer. As another example, one might have a remote application that puts up a pseudo console on a workstation screen. Since the rules by which the printer state is mapped onto the console and vice versa are not standardized, it is not possible to reproduce the console state or the action of console buttons and menus. Therefore, the Console Group provides access to the console. The operator console is usually implemented on the system controller with additional hardware for input and display. 2.2.13. Alerts The alert sub-unit is responsible for detecting reportable events, making an entry in the alert table and, if and only if the event is a critical event, initiating a trap. The exception to this rule is when the "alertRemovalofBinaryChangeEntry" trap is generated. The alert sub-unit is represented by the Alerts Group and, in particular, the Alert Table. This table contains information on the severity, sub- unit, and detailed location within the sub-unit, alert code and description of each alert that is currently active within the printer. Each reportable event causes an entry to be made in the Alert Table. Bergman, et al. Standards Track [Page 15] RFC 3805 Printer MIB v2 June 2004 2.2.13.1. Status and Alerts Summary information about the state of the printer is reported at three separate levels: (1) The status of the printer as a whole is reported in the Host Resources MIB, (2) The status of various sub- units is reported in the principle table of the Group that represents the sub-unit, and (3) Alert codes are reported in the Alert Table. 2.2.13.2. Overall Printer Status Of the many states a printer can be in, certain states are more "interesting" because of the distinct actions they are likely to provoke in the administrator. These states may be applied to the printer as a whole, or to a particular sub-unit of the printer. These named states are: Non Critical Alert Active - For the printer this means that one or more sub-units have a non-critical alert active. For a sub-unit, this means that the sub-unit has a non-critical alert active. Critical Alert Active - For the printer this means that one or more sub-units have a critical alert active. For a sub-unit, this means that the sub-unit has a critical alert active. Unavailable - The printer or sub-unit is unavailable for use (this is the same as "broken" or "down" in other terminology). A trained service person is typically necessary to make it available. Moving on-line or off-line - The printer is either off-line, in the process of moving off-line or moving back on-line. For example, on printers with motorized hoppers, reloading paper involves a transition to off-line to open the paper bin, filling the hopper and, finally, a transition back to on-line as the paper bin is repositioned for printing. Standby - The printer or sub-unit is not immediately available but can accept new instructions. Available - The printer or subunit is functioning normally. Idle - The printer or subunit is immediately available. Active - The printer or subunit is performing its primary function. Busy - The printer or subunit is performing a function (not necessarily its primary function) and is not immediately available for its primary function. Bergman, et al. Standards Track [Page 16] RFC 3805 Printer MIB v2 June 2004 The Host Resources MIB [RFC2790] provides three status objects that can be used to describe the status of a printer: (1) hrDeviceStatus in the entry in the hrDeviceTable; (2) hrPrinterStatus in the hrPrinterTable; and (3) hrPrinterDetectedErrorState in the hrPrinterTable. These objects describe many of the states that a printer can be in. The following table shows how the values of the three printer-related objects in the Host Resources MIB relate to the states named above: Printer hrDeviceStatus hrPrinterStatus hrPrinterDetected- Status ErrorState Idle running(2) idle(3) none set Busy/ running(2) printing(4) Active Non Critical warning(3) idle(3) or could be: lowPaper, Alert Active printing(4) lowToner, or serviceRequested Critical down(5) other(1) could be: jammed, Alert Active noPaper, noToner, coverOpen, or serviceRequested Unavailable down(5) other(1) Moving off- warning(3) idle(3) or offline line printing(4) Off-line down(5) other(1) offline Moving down(5) warmup(5) on-line Standby running(2) other(1) These named states are only a subset of the possible states - they are not an exhaustive list of the possible states. Nevertheless, several things should be noted. When using these states, it is not possible to detect when both critical and non-critical alerts are pending - if both are pending, the Critical Alert Active state will prevail. In addition, a printer in the Standby state will be represented in the Host Resources MIB with a device status of running(2) and a printer status of other(1), a set of states that don't uniquely distinguish this important printer state. Bergman, et al. Standards Track [Page 17] RFC 3805 Printer MIB v2 June 2004 Detailed status per sub-unit is reported in the sub-unit status fields. 2.2.13.2.1. Host Resources MIB Printer Status For completeness, the definitions of the Printer Status objects of the Host Resources MIB [RFC2790] are given below: hrDeviceStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), running(2), warning(3), testing(4), down(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The current operational state of the device described by this row of the table. A value unknown(1) indicates that the current state of the device is unknown. running(2) indicates that the device is up and running and that no unusual error conditions are known. The warning(3) state indicates that agent has been informed of an unusual error condition by the operational software (e.g., a disk device driver) but that the device is still 'operational'. An example would be high number of soft errors on a disk. A value of testing(4), indicates that the device is not available for use because it is in the testing state. The state of down(5) is used only when the agent has been informed that the device is not available for any use." ::= { hrDeviceEntry 5 } hrPrinterStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), idle(3), printing(4), warmup(5) } ACCESS read-only STATUS mandatory DESCRIPTION Bergman, et al. Standards Track [Page 18] RFC 3805 Printer MIB v2 June 2004 "The current status of this printer device. When in the idle(3), printing(4), or warmup(5) state, the corresponding hrDeviceStatus should be running(2) or warning(3). When in the unknown(2) state, the corresponding hrDeviceStatus should be unknown(1)." ::= { hrPrinterEntry 1 } hrPrinterDetectedErrorState OBJECT-TYPE SYNTAX OCTET STRING (0..128) ACCESS read-only STATUS mandatory DESCRIPTION "This object represents any error conditions detected by the printer. The error conditions are encoded as an OCTET STRING with the following definitions: Condition Bit # lowPaper 0 noPaper 1 lowToner 2 noToner 3 doorOpen 4 jammed 5 offline 6 serviceRequested 7 inputTrayMissing 8 outputTrayMissing 9 markerSupplyMissing 10 outputNearFull 11 outputFull 12 inputTrayEmpty 13 overduePreventMaint 14 Bit # 15 is not assigned. If multiple conditions are currently detected and the hrDeviceStatus would not otherwise be unknown(1) or testing(4), the hrDeviceStatus shall correspond to the worst state of those indicated, where down(5) is worse than warning(3), which is worse than running(2). Bits are numbered starting with the most significant bit of the first byte being bit 0, the least significant bit of the first byte being bit 7, the most significant bit of the second byte being bit 8, and so on. A one bit encodes that the condition was detected, while a zero bit encodes that Bergman, et al. Standards Track [Page 19] RFC 3805 Printer MIB v2 June 2004 the condition was not detected. This object is useful for alerting an operator to specific warning or error conditions that may occur, especially those requiring human intervention." ::= { hrPrinterEntry 2 } 2.2.13.2.2. Sub-unit Status Sub-unit status is reported in the entries of the principle table in the Group that represents the sub-unit. For sub-units that report a status, there is a status column in the table and the value of this column is always an integer formed in the following way. The PrtSubUnitStatusTC is an integer that is the sum of 5 distinct values, Availability, Non-Critical, Critical, On-line, and Transitioning. These values are: Availability value Available and Idle 0 000'b Available and Standby 2 010'b Available and Active 4 100'b Available and Busy 6 110'b Unavailable and OnRequest 1 001'b Unavailable because Broken 3 011'b Unknown 5 101'b Non-Critical No Non-Critical Alerts 0 Non-Critical Alerts 8 Critical No Critical Alerts 0 Critical Alerts 16 On-Line State is On-Line 0 State is Off-Line 32 Transitioning At intended state 0 Transitioning to intended state 64 Bergman, et al. Standards Track [Page 20] RFC 3805 Printer MIB v2 June 2004 For example, an input (tray) that jammed on the next to the last page may show a status of 27 (unavailable because broken (3) + a critical state (16), jammed, and a noncritical state (8), low paper). 2.2.13.3. Alert Tables The Alert Group consists of a single table in which all active alerts are represented. This section provides an overview of the table and a description of how it is managed. The basic content of the alert table is the severity (critical or non-critical) of the alert, the Group and entry where a state change caused the alert, additional information about the alert (a more detailed location, an alert code, and a description), and an indication of the level of training needed to service the alert. The Alert Table contains some information that is redundant, for example that an event has occurred, and some information that is only represented in the Alert Table, for example the additional information. A single table was used because a single entry in a group could cause more than one alert, for example paper jams in more than one place in a media path. Associating the additional information with the entry in the affected group would only allow one report where associating the additional information with the alert makes multiple reports possible. Every time an alert occurs in the printer, the printer makes one or more entries into the Alert Table. The printer determines if an event is to be classified as critical or non-critical. If the severity of the Alert is "critical", the printer sends a trap or event notification to the host indicating that the table has changed. Whether or not a trap is sent, the management application is expected to poll the printer on a regular basis and to read and parse the table to determine what conditions have changed, in order to provide reliable information to the management application user. 2.2.13.4. Alert Table Management The alert tables are sparsely populated tables. This means the tables will only contain entries of the alerts that are currently active and the number of rows, or entries in the table will be dynamic. More than one event can be added or removed from the event tables at a time depending on the implementation of the printer. There are basically two kinds of events that produce alerts: binary change events and unary change events. Binary change events come in pairs: the leading edge event and the trailing edge event. The leading edge event enters a state from which there is only one exit; for example, going from running to stopped with a paper jam. The only exit from this state is fixing the paper jam and it is clear Bergman, et al. Standards Track [Page 21] RFC 3805 Printer MIB v2 June 2004 when that is accomplished. The trailing edge event exits the state that was entered by the leading edge event. In the example above, fixing the paper jam is the trailing edge event. It is relatively straightforward to manage binary change events in the Alert Table. Only the leading edge event makes an entry in the alert table. This entry persists in the Alert Table until the trailing edge event occurs at which point this event is signaled by the removal of the leading edge event entry in the Alert Table. That is, a trailing edge event does not create an entry; it removes the corresponding leading edge event. Removing the leading edge entry may cause the unary change event "alertRemovalofBinaryChangeEntry" to be added to the table. With binary change events it is possible to compute the maximum number that can occur at the same time and construct an Alert Table that would hold that many events. There would be no possibility of table overflow and no information about outstanding events would be lost. Unfortunately, there are some events that are not binary changes. This other category of event, the unary change event, is illustrated by the configuration change event. With this kind of event the state of the machine has changed, but to a state which is (often) just as valid as the state that was left and from which no return is necessary. For example, an operator may change the paper that is in the primary input source from letter to legal. At some time in the future the paper may be changed back to letter, but it might be changed to executive instead. This is where the problem occurs. It is not obvious how long to keep unary change event entries in the Alert Table. If they were never removed, the Alert Table would continue to grow indefinitely. The agent needs to have an algorithm implemented for the management of the alert table, especially in the face of combinations of binary and unary alerts that would overflow the storage capacity of the table. When the table is full and new alerts need to be added, an old alert to be deleted should be chosen using the following rules: 1. Find a non-critical unary alert and delete it. If there are multiple non-critical unary alerts, it is suggested that the oldest one is chosen. If there are no non-critical unary alerts, then, 2. Find a non-critical binary alert and delete it. If there are multiple non-critical binary alerts, it is suggested that the oldest one is chosen. If there are no non-critical binary alerts, then, Bergman, et al. Standards Track [Page 22] RFC 3805 Printer MIB v2 June 2004 3. Find a critical (binary) alert and delete it. If there are multiple critical alerts, it is suggested that the oldest one be chosen. Agent implementers are encouraged to provide at least enough storage space for the maximum number of critical alerts that could occur simultaneously. Note that all critical alerts are binary. In the event that a critical binary alert has been deleted out of the alert table; when space allows and the alert condition still exists, the alert should be re-added to the alert table even if there was no subsequent transition into the associated state. It is recommended that this be done for non-critical binary alerts as well. Note that the new alert entry will not have the same index as the original entry that was moved out of the table. Note that because the Alert Index is a monotonically increasing integer there will be gaps in the values in the table when an alert is deleted. The management application may want to re-acquire the Printer state and check for state changes that it did not observe in the Alert Table if such gaps are detected. 2.3. Read-Write Objects Some objects in the printer MIB reflect the existence or amount of a given resource within the printer. Some examples of such resources are the size and number of sheets in a paper tray or the existence of certain output options. Some printers have automatic sensors for these resources. Most printers lack sensors for every property of every resource. The management application is allowed to write into objects that hold descriptive or existence values for printers that cannot sense these values. The ability to change the value of a read- write object may depend on the implementation of the agent. Many objects in the MIB are given read-write access, but a printer implementation might only permit a management application to change the value if the printer can not sense the value itself. Note that even though some objects explicitly state the behavior of conditional ability to change values, any read-write object may act this way. Generally, an object is given read-write access in the Printer MIB specification if: 1. The object involves installation of a resource that some printers cannot themselves detect. Therefore, external means are needed to inform the printer of the installation. (Here external means include using the operator console, or remote management application) and Bergman, et al. Standards Track [Page 23] RFC 3805 Printer MIB v2 June 2004 2. The printer will behave differently if the installation of the resource is reported than the printer would if the installation were not reported; that is, the object is not to be used as a place to put information not used by the printer, i.e., not a "sticky-note". Another way of saying this is that the printer believes that information given it and acts as if the information were true. For example, on a printer that cannot sense the size, if one paper size is loaded, but another size is set into the paper size object, then the printer will use the size that was set as its current paper size in its imaging and paper handling. 3. The printer may get hints that it may not know about the existence or properties of certain resources. For example, a paper tray may be removed and re-inserted. When this removal and insertion happens, the printer may either assume that a property, such as the size of paper in the tray, has not changed or the printer may change the value of the associated object to "unknown", as might be done for the amount of paper in the tray. As long as the printer acts according to the value in the object either strategy is acceptable. 4. It is an implementation-specific matter as to whether or not MIB object values are persistent across power cycles or cold starts. It is particularly important that the values of the prtMarkerLifeCount object persist throughout the lifetime of the printer. Therefore, if the value of any MIB object persists across power cycles, then the prtMarkerLifeCount object must also persist. 2.4. Enumerations Enumerations (enums) are sets of symbolic values defined for use with one or more objects. Commonly used enumeration sets are assigned a symbolic data type name (textual convention), rather than being specified in the SYNTAX clause of each individual object definition. Textual conventions defined in the Printer MIB or the companion IANA Printer MIB are extensible by RFC publication or by Designated Expert Review (see the 'IANA Considerations' section of this Printer MIB and the DESCRIPTION clause in MODULE-IDENTITY of IANA Printer MIB). All of these textual conventions are: a) used more than once in the Printer MIB itself; or b) imported and used in the companion Finisher MIB; or c) imported and used in any other, including vendor private, MIB modules. Bergman, et al. Standards Track [Page 24] RFC 3805 Printer MIB v2 June 2004 The Printer MIB has also defined the following special values for use with objects of the syntax "Integer32" to define conditions that are outside of the normal numeric range: other(-1), unknown(-2), and partial(-3). The 'partial' value means that there is some supply remaining (but the amount is indeterminate) or there is some capacity remaining (but the amount is indeterminate). The Integer32 range field indicates in which objects these special values are valid. 2.4.1. Registering Additional Enumerated Values The Printer MIB and the companion IANA Printer MIB each defines one category of textual convention, according to the process employed to control the addition of new enumerations: Type 1 - All of the legal values are defined in the Printer MIB. Additional enumerated values require the publication of a new Printer MIB. Type 2 - All of the legal values are registered in the IANA Printer MIB. Additional enumerated values require a Designated Expert Review defined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434]. The Designated Expert will be selected by the IETF Area Director(s) of the Applications Area. 3. Groups from other MIB Specifications This section identifies the groups from other MIBs that shall be supported to supplement and complete a printer MIB implementation. The section also describes some of the less obvious characteristics of the Printer MIB structure that are related to the inclusion of these other MIB groups. 3.1. System Group All objects in the system group of MIB-II [RFC1213] shall be implemented; however, as described in paragraph 2.4, implementers should carefully consider what constitutes the "system". 3.2. System Controller The storage and device groups of the Host Resources MIB [RFC2790] shall be implemented to support the printer(s) system controller, and any supporting devices. If deemed appropriate by the implementer, other groups of the Host Resources MIB (System, Running Software, Running Software Performance, and Installed Software) may be implemented. Because of the structure of the Host Resources MIB, the devices constituting the system controller are at the same level as the printer. Bergman, et al. Standards Track [Page 25] RFC 3805 Printer MIB v2 June 2004 3.3. Interface Group objects All objects in the Interfaces Group of MIB-II [RFC1213] shall be implemented for all print information interfaces to the printer, including non-network interfaces. 3.3.1. Interface Types The interfaces group of RFC 1213 [RFC1213] contains only a partial list of interface types that can be specified in the "ifType" object. For a complete list of interface types, refer to the IANA registry at "ftp://ftp.isi.edu/mib/iana.mib/ianaiftype.mib" 4. Differences from RFC 1759 This document supersedes and replaces RFC 1759. However, a compliant implementation of RFC 1759 is also compliant with this document. The following changes to RFC 1759 are included: (See the printmib REVISION/DESCRIPTION clause for additional details of changes.) - Minor editorial corrections and changes. Updated the cover page and added the "SNMP Management Framework" boilerplate to section 1. - Updated figure 2 to use MIB names instead of RFC numbers. - Updated Coded Character Set description and IANA registration process. - Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to "doorOpen" per RFC 2790. - Added second octet of hrPrinterDetectedErrorState as partially described and assigned in the updated Host Resources MIB (RFC 2790). - Remove fixed association of hrDeviceStatus (warning/down) from hrPrinterDetetctedErrorState per RFC 2790. - Instead of showing bit 15 as "not assigned" in the quote from RFC 2790 in the hrPrinterDetectedErrorState object, removed that from the tabular form and added it as a sentence, because the RFC doesn't show bit 15 in the tabular form. - Clarified the international considerations. Bergman, et al. Standards Track [Page 26] RFC 3805 Printer MIB v2 June 2004 - Added prtChannelInformation to the Channel Group textual- conventions on a per channel basis to clarify the channel description and enhance interoperability. - Deprecated some obsolete channel types. - Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual conventions to include values from the Finisher MIB. - Clarified alerts based on unary vs. binary change events. - Added (optional) unary change event alertRemovalOfBinaryChangeEntry(1801). - Establish a convention for contact information for prtGeneralCurrentOperator and prtGeneralServicePerson. - Added prtAuxiliarySheetStartupPage PresentOnOff - Added prtAuxiliarySheetBannerPage PresentOnOff - Added prtGeneralPrinterName OCTET STRING - Added prtGeneralSerialNumber OCTET STRING - Added prtInputNextIndex Integer32 - Added the Input Switching Group - Added prtAlertCriticalEvents Counter32 - Added prtAlertAllEvents Counter32 - Updated PrtAlertCode enums including generic alert codes. - Created five OBJECT-GROUPs (prtAuxilliarySheetGroup, prtInputSwitchingGroup, prtGeneralV2Group, prtAlertTableV2Group, prtChannelV2Group). Added the nine new objects to them (prtAuxiliarySheetStartupPage, prtAuxiliarySheetBannerPage, prtGeneralPrinterName, prtGeneralSerialNumber, prtAlertCriticalEvents, prtAlertAllEvents, prtInputMediaLoadTimeout, prtInputNextIndex, prtChannelInformation). Created one new NOTIFICATION-GROUP (prtAlertTrapGroup) to contain printerV2Alert. Included the new OBJECT-GROUPs and the NOTIFICATION_GROUP in prtMIBCompliance, all in GROUP (not MANDATORY-GROUP) clauses. The nine new objects are optional, i.e., this document is backward compatible with RFC 1759. Bergman, et al. Standards Track [Page 27] RFC 3805 Printer MIB v2 June 2004 - prtAlertTime is strongly recommended. - Deprecated the use of alert codes doorOpen(501) and doorClosed(502), in favor of coverOpened(3) and coverClosed(4). - Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC textual conventions, and changed the PrtConsoleDisable and PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs to reflect the new syntax. - Added textual conventions "PrtLocalizedDescriptionStringTC" and "PrtConsoleDescriptionStringTC" and updated several objects to use them. - Changed most enumerations to textual conventions and therefore changed the SYNTAX of many objects from RFC 1759 to specify the appropriate textual conventions. (28 TCs were added.) - Changed the TC names "MediaUnit" to "PrtMediaUnitTC", "CapacityUnit" to "PrtCapacityUnitTC", and "SubUnitStatus" to "PrtSubUnitStatusTC" - All objects with a MAX-ACCESS of read-write now have a MIN-ACCESS of read-only. - Added 'IANA Considerations' and 'Internationalization Considerations' as top level sections, per IETF guidelines. - Updated Security and Copyright sections. - Updated references and split into Normative and Informative groups. - Added Appendix E - Overall Printer Status Table. - Updated participant and contact information. - Removed CodedCharSet Textual Convention, replaced with an import of the IANACharset. - Removed all comment statements that indicated objects or groups are mandatory or optional. Avoids any potential conflicts with the conformance section. Bergman, et al. Standards Track [Page 28] RFC 3805 Printer MIB v2 June 2004 - Added text to empty description clauses. (prtStorageRefTable, prtDeviceRefTable, prtMarkerTable, prtMediaPathTable, prtChannelTable, prtInterpreterTable, prtConsoleLightTable, and prtAlertTable) - Added "DEFVAL { unknown }" to prtInterpreterDefaultCharSetIn and prtInterpreterDefaultCharSetOut. - Changed "...values are expected to remain stable..." to "...values SHOULD remain stable..." in the description clauses for the index object in all tables. - Added ranges to all objects with a syntax of Integer32. - Revised the description clause for prtAlertGroupIndex. - Added additional text to the description clause for prtMediaPathEntry, prtChannelEntry, prtInterpreterEntry, and printerV2Alert. - Added text to section 2.4 to explain the usage of textual conventions in this MIB and others. Also added a note defining the common usage of the enumerations 'other(-1)' and 'unknown(-2)' - Changed range of prtStorageRefSeqNumber, prtDeviceRefSeqNumber, and prtConsoleLightIndex from (0..65535) to (1..65535) since index values cannot be zero. (Typo in RFC 1759) - The PWG Standard for Standardized Media Names is now recommended for the objects prtInputMediaName, prtInputMediaColor, and prtInputMediaType. - Added chSMTP(45) to prtChannelTypeTC. 5. The IANA Printer MIB IANA-PRINTER-MIB DEFINITIONS ::= BEGIN -- http://www.iana.org/assignments/ianaprinter-mib IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ianaPrinterMIB MODULE-IDENTITY LAST-UPDATED "200406020000Z" -- June 2, 2004 Bergman, et al. Standards Track [Page 29] RFC 3805 Printer MIB v2 June 2004 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana@iana.org" DESCRIPTION "This MIB module defines a set of printing-related TEXTUAL-CONVENTIONs for use in Printer MIB (RFC 3805), Finisher MIB (RFC 3806), and other MIBs which need to specify printing mechanism details. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Applications Area. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3805. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" REVISION "200406020000Z" -- June 2, 2004 DESCRIPTION "Original version, published in coordination with Printer MIB (RFC 3805)." ::= { mib-2 109 } -- -- Generic TEXTUAL-CONVENTIONs -- PrtCoverStatusTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtCoverStatus in RFC 1759. STATUS current DESCRIPTION "Values for encoding the state of a particular cover or access panel on the printer case or enclosure." SYNTAX INTEGER { other(1), coverOpen(3), coverClosed(4), interlockOpen(5), interlockClosed(6) Bergman, et al. Standards Track [Page 30] RFC 3805 Printer MIB v2 June 2004 } -- -- General Group TEXTUAL-CONVENTIONs -- PrtGeneralResetTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtGeneralReset in RFC 1759. STATUS current DESCRIPTION "Values for reading and writing the prtGeneralReset object. If a device does not have NVRAM, the device shall none the less respond to a SET with the value resetToNVRAM(5) with a sort of warm reset that resets the device to implementation- defined state that is preferably under control of the system administrator by some means outside the scope of the Printer MIB specification." SYNTAX INTEGER { notResetting(3), powerCycleReset(4), -- Cold Start resetToNVRAM(5), -- Warm Start resetToFactoryDefaults(6) -- Reset contents of -- NVRAM to factory -- defaults } -- -- Channel Group TEXTUAL-CONVENTIONs -- PrtChannelTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtChannelType in RFC 1759. STATUS current DESCRIPTION "This enumeration indicates the type of channel that is receiving jobs." SYNTAX INTEGER { other(1), chSerialPort(3), chParallelPort(4), chIEEE1284Port(5), chSCSIPort(6), chAppleTalkPAP(7), -- AppleTalk Printer -- Access Protocol (PAP) -- -- prtChannelInformation entry: Bergman, et al. Standards Track [Page 31] RFC 3805 Printer MIB v2 June 2004 -- -- Printer Name -- Keyword: Name -- Syntax: Name -- Status: Optional -- Multiplicity: Single -- Description: The name of the printer -- within the AppleTalk naming scope chLPDServer(8), -- prtChannelInformation entry: -- -- Printer queue name -- Keyword: Queue -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: queue name as -- defined in [RFC1179]. chNetwareRPrinter(9), -- Novell, Inc. -- For each entry of this type, the -- prtChannelInformation must have a pair of -- keywords. For Netware 3.x channels this must -- be a (PServer, Printer) pair. For Netware -- 4.x channels and for IntranetWare channels -- this must be a (NDSTree, NDSPrinter) pair. -- -- prtChannelInformation entries: -- Print Server Name -- Keyword: PServer -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The Pserver's SAP name -- -- Printer Number -- Keyword: Printer -- Syntax: Integer -- Status: Mandatory -- Multiplicity: Single -- Description: The printer number -- -- NDSTree -- Keyword: NDSTree -- Syntax: Name -- Multiplicity: Single -- Description: The tree's SAP name Bergman, et al. Standards Track [Page 32] RFC 3805 Printer MIB v2 June 2004 -- -- NDS Printer object -- Keyword: NDSPrinter -- Syntax: Text (Unicode) -- Status: Mandatory -- Multiplicity: Single -- Description: The fully qualified -- name of the Printer -- -- In the Netware 3.x environment, the -- client checks the Bindery object -- representing the named PServer. The -- client then checks for queues which -- are associated with the numbered -- printer. In the 4.x and IntraNetware -- environment, the client looks up the -- queues which are associated with the -- NDS Printer Object in the named Tree. -- Depending on client access rights to -- those queues, the client submits jobs -- to the appropriate queue. chNetwarePServer(10), -- Novell,Inc. -- For each entry of this type, the -- prtChannelInformation must have a pair -- of keywords. For Netware 3.x channels -- this must be a (Server, PServer) pair. -- For Netware 4.x and IntranetWare -- channels, this must be a -- (NDSTree, NDSPServer) pair. -- -- prtChannelInformation entries: -- -- Server Name -- Keyword: Server -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The SAP name of the -- server for which the PServer is defined. -- -- PServer -- Keyword: PServer -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The bindery name of -- the PServer Bergman, et al. Standards Track [Page 33] RFC 3805 Printer MIB v2 June 2004 -- -- NDS Tree -- Keyword: NDSTree -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The NDS Tree name -- -- PServer -- Keyword: NDSPServer -- Syntax: Text (Unicode) -- Status: Mandatory -- Multiplicity: Single -- Description: The fully qualified -- name of the PServer object in the tree. -- -- In the 3.x environment, the client -- checks the bindery object -- representing the named PServer on the -- named Server. In the 4.x and -- IntranetWare environment, -- the client checks the NDS object -- representing the named PServer in the -- named Tree. In either case, the -- client then checks for all queues -- associated with the Pserver object. -- Depending on client access rights -- to those queues, the client submits -- jobs to the appropriate queue. chPort9100(11), -- DEPRECATED -- (see chPortTCP - 37; chBidirPortTCP - 38) chAppSocket(12), -- A bi-directional, LPD-like, protocol using -- 9101 for control and 9100 for data. -- Adobe Systems, Inc. chFTP(13), -- [RFC959] chTFTP(14), -- [RFC1350] chDLCLLCPort(15), chIBM3270(16), -- IBM Coax chIBM5250(17), -- IBM Twinax chFax(18), chIEEE1394(19), chTransport1(20), -- TCP port 35, for reserved TCP port list see -- [RFC3232]. This RFC should also be -- referenced for other channel -- enumerations utilizing TCP port Bergman, et al. Standards Track [Page 34] RFC 3805 Printer MIB v2 June 2004 -- numbers 0 through 1024. chCPAP(21), -- TCP port 170 -- Digital Equipment Corp. chDCERemoteProcCall(22), -- OSF -- DEPRECATED chONCRemoteProcCall(23), -- SUN Microsystems -- DEPRECATED chOLE(24), -- Microsoft -- DEPRECATED chNamedPipe(25), chPCPrint(26), -- Banyan chServerMessageBlock(27), -- File/Print sharing protocol used by -- various network operating systems -- from IBM 3Com, Microsoft and others -- -- prtChannelInformation entry: -- -- Service Name -- Keyword: Name -- Syntax: Name -- Status: Optional -- Multiplicity: Single -- Description: The service name of -- the printer chDPMF(28), -- IBM Infoprint chDLLAPI(29), -- Microsoft -- DEPRECATED chVxDAPI(30), -- Microsoft -- DEPRECATED chSystemObjectManager(31), -- IBM chDECLAT(32), -- Digital Equipment Corp. -- -- prtChannelInformation entries: -- -- Port Name -- Keyword: Port -- Syntax: Name -- Status: Conditionally -- Mandatory -- (see note below) -- Multiplicity: Single -- Description: LAT port name -- -- Service Name -- Keyword: Service -- Syntax: Name Bergman, et al. Standards Track [Page 35] RFC 3805 Printer MIB v2 June 2004 -- Status: Conditionally -- Mandatory -- Multiplicity: Single -- Description: LAT service name -- -- The LAT channel may be -- identified by either a port or -- service, so either a -- Port or Service entry must be -- specified, but not both. chNPAP(33), chUSB(34), -- Not in RFC 1759 -- Universal Serial Bus chIRDA(35), -- Not in RFC 1759 -- Infrared Data Assoc. Prot. chPrintXChange(36), -- Not in RFC 1759 -- PrintXChange Protocol chPortTCP(37), -- Not in RFC 1759 -- A unidirectional "raw" TCP -- channel that uses an administratively -- assigned TCP port address. -- -- prtChannelInformation entry: -- -- Port Number -- Keyword: Port -- Syntax: decimal number -- Status: Mandatory -- Multiplicity: Single -- Description: TCP port number chBidirPortTCP(38), -- Not in RFC 1759 -- A bi-directional version of chPortTCP -- -- prtChannelInformation entries: -- (See chPortTCP) chUNPP(39), -- Not in RFC 1759 -- Universal Network Printing -- Protocol(UNPP). A bi-directional, -- multiport network printing -- application protocol available on -- multiple transport protocols. -- Underscore, Inc. -- Contact: info@underscore.com chAppleTalkADSP(40), -- Not in RFC 1759 -- AppleTalk Data Stream Protocol. -- ADSP is part of the AppleTalk -- suite of protocols. -- It is a symmetric, connection- Bergman, et al. Standards Track [Page 36] RFC 3805 Printer MIB v2 June 2004 -- oriented protocol that makes -- possible the establishment -- and maintenance of full-duplex -- streams of data bytes between -- two sockets in an AppleTalk -- internet. -- See [APPLEMAC]. chPortSPX(41), -- Not in RFC 1759 -- Sequenced Packet Exchange (SPX) -- socket. -- Novell, Inc. Similar to TCP, a -- bi-directional data pipe using -- Novell SPX as a transport. -- -- prtChannelInformation entries: -- -- Network Number -- Keyword: Net -- Syntax: HexString -- Status: Mandatory -- Multiplicity: Single -- Description: The network number -- -- Node Number -- Keyword: Node -- Syntax: HexString -- Status: Mandatory -- Multiplicity: Single -- Description: The node number -- -- Socket Number -- Keyword: Socket -- Syntax: HexString -- Status: Mandatory -- Multiplicity: Single -- Description: The SPX socket number -- -- There must be exactly one "Net" and -- one "Node" and one "Socket" entry. A -- HexString is a binary value -- represented as a string of -- ASCII characters using hexadecimal -- notation. chPortHTTP(42), -- Not in RFC 1759 -- Hypertext Transfer Protocol. See [RFC1945] -- and [RFC2616]. chNDPS(43), -- Not in RFC 1759 -- Novell, Inc. Bergman, et al. Standards Track [Page 37] RFC 3805 Printer MIB v2 June 2004 -- -- prtChannelInformation entry: -- -- Printer Agent Name -- Keyword: PA -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Description: The NDPS Printer -- Agent Name chIPP(44), -- Not in RFC 1759 -- Internet Printing Protocol (IPP), -- (IPP/1.1 - see [RFC2910] and [RFC2911]) -- also applies to all future versions of IPP. -- -- IPP Printer URI -- Keyword: URI -- Syntax: URI (Unicode UTF-8 per -- [RFC2396]) -- Status: Mandatory -- Multiplicity: Single -- Default: not applicable -- Description: URI of this IPP Printer -- within Internet naming scope. Unicode -- UTF-8 [RFC3629] string with -- hexadecimal escapes for any non-ASCII -- characters (per [RFC2396]). -- Conformance: An IPP Printer shall list all -- IPP URI it supports (one per IPP Channel -- entry). If a URI contains the 'http:' -- scheme it must have an explicit port. -- See: [RFC3629], [RFC2396], [RFC2910], -- [RFC2911]. -- -- IPP Printer Client Authentication -- Keyword: Auth -- Syntax: Keyword -- Status: Optional -- Multiplicity: Single -- Default: 'none' -- Description: A client authentication -- mechanism supported for this IPP Printer -- URI: -- 'none' -- no client authentication mechanism -- 'requesting-user-name' -- authenticated user in 'requesting- -- user-name' Bergman, et al. Standards Track [Page 38] RFC 3805 Printer MIB v2 June 2004 -- 'basic' -- authenticated user via HTTP Basic -- mechanism -- 'digest' -- authenticated user via HTTP Digest -- mechanism -- 'certificate' -- authenticated user via certificate -- mechanism -- Conformance: An IPP Printer should list -- all IPP client authentication mechanisms -- it supports (one per IPP Channel entry). -- See: [RFC2911] and [RFC2910]. -- -- IPP Printer Security -- Keyword: Security -- Syntax: Keyword -- Status: Optional -- Multiplicity: Single -- Default: 'none' -- Description: A security mechanism -- supported for this IPP Printer URI: -- 'none' -- no security mechanism -- 'ssl3' -- SSL3 secure communications channel -- protocol -- 'tls' -- TLS secure communications channel -- protocol -- Conformance: An IPP Printer should list -- all IPP security mechanisms it supports -- (one per IPP Channel entry). -- See: [RFC2246], [RFC2911]. -- -- IPP Printer Protocol Version -- Keyword: Version -- Syntax: Keyword -- Status: Optional -- Multiplicity: Multiple -- Default: '1.1' -- Description: All of the IPP protocol -- versions (major.minor) supported for -- this IPP Printer URI: -- '1.0' -- IPP/1.0 conforming Printer -- '1.1' -- IPP/1.1 conforming Printer Bergman, et al. Standards Track [Page 39] RFC 3805 Printer MIB v2 June 2004 -- Conformance: An IPP Printer should list -- all IPP versions it supports (all listed -- in each IPP Channel entry). An IPP -- Client should select the highest -- numbered version the IPP Client supports -- for use in all IPP Requests (for optimum -- interworking). -- See: [RFC2911]. chSMTP(45) -- Print Job submission via Simple Mail -- Transfer Protocol (SMTP) - see [RFC2821] -- -- prtChannelInformation entry: -- -- Keyword: Mailto -- Syntax: Name -- Status: Mandatory -- Multiplicity: Single -- Default: not applicable -- Description: The SMTP URL of the printer. } -- -- Interpreter Group TEXTUAL-CONVENTIONs -- PrtInterpreterLangFamilyTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtInterpreterLangFamily in RFC 1759. STATUS current DESCRIPTION "This enumeration indicates the type of interpreter that is receiving jobs." SYNTAX INTEGER { other(1), unknown(2), -- Not in RFC 1759 langPCL(3), -- PCL. Starting with PCL version 5, -- HP-GL/2 is included as part of the -- PCL language. -- PCL and HP-GL/2 are registered -- trademarks of Hewlett-Packard -- Company. langHPGL(4), -- Hewlett-Packard Graphics Language. -- HP-GL is a registered trademark of -- Hewlett-Packard Company. langPJL(5), -- Peripheral Job Language. Appears in -- the data stream between data intended -- for a page description language. -- Hewlett-Packard Co. Bergman, et al. Standards Track [Page 40] RFC 3805 Printer MIB v2 June 2004 langPS(6), -- PostScript (tm) Language -- Postscript - a trademark of Adobe -- Systems Incorporated which may be -- registered in certain jurisdictions langIPDS(7), -- Intelligent Printer Data Stream -- Bi-directional print data stream for -- documents consisting of data objects -- (text, image, graphics, bar codes), -- resources (fonts, overlays) and page, -- form and finishing instructions. -- Facilitates system level device -- control, document tracking and error -- recovery throughout the print -- process. -- IBM Corporation. langPPDS(8), -- IBM Personal Printer Data Stream. -- Originally called IBM ASCII, the name -- was changed to PPDS when the Laser -- Printer was introduced in 1989. -- Lexmark International, Inc. langEscapeP(9), -- Epson Corp. langEpson(10), langDDIF(11), -- Digital Document Interchange Format -- Digital Equipment Corp., Maynard MA langInterpress(12), -- Xerox Corp. langISO6429(13), -- ISO 6429. Control functions for -- Coded Character Sets (has ASCII -- control characters, plus additional -- controls for -- character imaging devices.) langLineData(14), -- line-data: Lines of data as -- separate ASCII or EBCDIC records -- and containing no control functions -- (no CR, LF, HT, FF, etc.) -- For use with traditional line -- printers. May use CR and/or LF to -- delimit lines, instead of records. -- See ISO 10175 Document Printing -- Application (DPA) [ISO10175]. langMODCA(15), -- Mixed Object Document Content -- Architecture -- Definitions that allow the -- composition, interchange, and -- presentation of final form -- documents as a collection of data -- objects (text, image, graphics, bar -- codes), resources (fonts, overlays) Bergman, et al. Standards Track [Page 41] RFC 3805 Printer MIB v2 June 2004 -- and page, form and finishing -- instructions. -- IBM Corporation. langREGIS(16), -- Remote Graphics Instruction Set, -- Digital Equipment Corp., Maynard MA langSCS(17), -- SNA Character String -- Bi-directional print data stream for -- SNA LU-1 mode of communication. -- IBM langSPDL(18), -- ISO 10180 Standard Page Description -- Language -- ISO Standard langTEK4014(19), -- Tektronix Corp. langPDS(20), langIGP(21), -- Printronix Corp. langCodeV(22), -- Magnum Code-V, Image and printer -- control language used to control -- impact/dot-matrix printers. -- QMS, Inc., Mobile AL langDSCDSE(23), -- DSC-DSE: Data Stream Compatible and -- Emulation Bi-directional print data -- stream for non-SNA (DSC) and SNA LU-3 -- 3270 controller (DSE) communications -- IBM langWPS(24), -- Windows Printing System, Resource -- based command/data stream used by -- Microsoft At Work Peripherals. -- Developed by the Microsoft -- Corporation. langLN03(25), -- Early DEC-PPL3, Digital Equipment -- Corp. langCCITT(26), langQUIC(27), -- QUIC (Quality Information Code), Page -- Description Language for laser -- printers. Included graphics, printer -- control capability and emulation of -- other well-known printer. -- QMS, Inc. langCPAP(28), -- Common Printer Access Protocol -- Digital Equipment Corp. langDecPPL(29), -- Digital ANSI-Compliant Printing -- Protocol -- (DEC-PPL) -- Digital Equipment Corp. langSimpleText(30), -- simple-text: character coded data, -- including NUL, CR , LF, HT, and FF -- control characters. See ISO 10175 Bergman, et al. Standards Track [Page 42] RFC 3805 Printer MIB v2 June 2004 -- Document Printing Application (DPA) -- [ISO10175]. langNPAP(31), -- Network Printer Alliance Protocol -- (NPAP). This protocol has been -- superseded by the IEEE 1284.1 TIPSI -- Std (ref. LangTIPSI(49)). langDOC(32), -- Document Option Commands, Appears in -- the data stream between data -- intended for a page description. -- QMS, Inc. langimPress(33), -- imPRESS, Page description language -- originally developed for the -- ImageServer product line. A binary -- language providing representations -- of text, simple graphics, and some -- large forms (simple -- bit-map and CCITT group 3/4 -- encoded).The -- language was intended to be sent over -- an 8-bit channel and supported early -- document preparation languages (e.g., -- TeX and TROFF). -- QMS, Inc. langPinwriter(34), -- 24 wire dot matrix printer for -- USA, Europe, and Asia except -- Japan. -- More widely used in Germany, and -- some Asian countries than in US. -- NEC langNPDL(35), -- Page printer for Japanese market. -- NEC langNEC201PL(36), -- Serial printer language used in -- the Japanese market. -- NEC langAutomatic(37), -- Automatic PDL sensing. Automatic -- sensing of the interpreter -- language family by the printer -- examining the document content. -- Which actual interpreter language -- families are sensed depends on -- the printer implementation. langPages(38), -- Page printer Advanced Graphic -- Escape Set -- IBM Japan langLIPS(39), -- LBP Image Processing System langTIFF(40), -- Tagged Image File Format (Aldus) Bergman, et al. Standards Track [Page 43] RFC 3805 Printer MIB v2 June 2004 langDiagnostic(41), -- A hex dump of the input to the -- interpreter langPSPrinter(42), -- The PostScript Language used for -- control (with any PDLs) -- Adobe Systems Incorporated langCaPSL(43), -- Canon Print Systems Language langEXCL(44), -- Extended Command Language -- Talaris Systems Inc. langLCDS(45), -- Line Conditioned Data Stream -- Xerox Corporation langXES(46), -- Xerox Escape Sequences -- Xerox Corporation langPCLXL(47), -- Not in RFC 1759 -- Printer Control Language. Extended -- language features for printing, and -- printer control. -- Hewlett-Packard Co. langART(48), -- Not in RFC 1759 -- Advanced Rendering Tools (ART). -- Page Description language -- originally developed for the Laser -- Press printers. -- Technical reference manual: "ART IV -- Reference Manual", No F33M. -- Fuji Xerox Co., Ltd. langTIPSI(49), -- Not in RFC 1759 -- Transport Independent Printer -- System Interface (ref. IEEE Std. -- 1284.1) langPrescribe(50), -- Not in RFC 1759 -- Page description and printer -- control language. It can be -- described with ordinary ASCII -- Technical reference manual: -- "PRESCRIBE II Programming Manual" langLinePrinter(51), -- Not in RFC 1759 -- A simple-text character stream which -- supports the control codes LF, VT, -- FF, and plus Centronics or -- Dataproducts Vertical Format Unit -- (VFU) language is commonly used on -- many older model line and matrix -- printers. langIDP(52), -- Not in RFC 1759 -- Imaging Device Protocol -- Apple Computer. Bergman, et al. Standards Track [Page 44] RFC 3805 Printer MIB v2 June 2004 langXJCL(53), -- Not in RFC 1759 -- Xerox Job Control Language (JCL). -- A Job Control language originally -- developed for the LaserPress printers -- and is capable of switching PDLs. -- Technical reference manual: -- "ART IV Reference Manual", No F33M. -- Fuji Xerox Co., Ltd. langPDF(54), -- Not in RFC 1759 -- Adobe Portable Document Format -- Adobe Systems, Inc. langRPDL(55), -- Not in RFC 1759 -- Ricoh Page Description Language for -- printers. -- Technical manual "RPDL command -- reference" No.307029 -- RICOH, Co. LTD langIntermecIPL(56), -- Not in RFC 1759 -- Intermec Printer Language for label -- printers. -- Technical Manual: "IPL Programmers -- Reference Manual" -- Intermec Corporation langUBIFingerprint(57), -- Not in RFC 1759 -- An intelligent basic-like programming -- language for label printers. -- Reference Manual: "UBI Fingerprint -- 7.1", No. 1-960434-00 -- United Barcode Industries langUBIDirectProtocol(58), -- Not in RFC 1759 -- An intelligent control language for -- label printers. -- Programmers guide: " UBI Direct -- Protocol", No. 1-960419-00 -- United Barcode Industries langFujitsu(59), -- Not in RFC 1759 -- Fujitsu Printer Language -- Reference Manual: -- "FM Printer Sequence" No. 80HP-0770 -- FUJITSU LIMITED langCGM(60), -- Not in RFC 1759 -- Computer Graphics Metafile -- MIME type 'image/cgm' langJPEG(61), -- Not in RFC 1759 -- Joint Photographic Experts Group -- MIME type 'image/jpeg' langCALS1(62), -- Not in RFC 1759 -- US DOD CALS1 (see MIL-STD-1840) Bergman, et al. Standards Track [Page 45] RFC 3805 Printer MIB v2 June 2004 -- MIME type 'application/cals-1840' langCALS2(63), -- Not in RFC 1759 -- US DOD CALS2 (see MIL-STD-1840) -- MIME type 'application/cals-1840' langNIRS(64), -- Not in RFC 1759 -- US DOD NIRS (see MIL-STD-1840) -- MIME type 'application/cals-1840' langC4(65) -- Not in RFC 1759 -- US DOD C4 (see MIL-STD-1840) -- MIME type 'application/cals-1840' } -- -- Input/Output Group TEXTUAL-CONVENTIONs -- PrtInputTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtInputType in RFC 1759. STATUS current DESCRIPTION "The type of technology (discriminated primarily according to feeder mechanism type) employed by a specific component or components." SYNTAX INTEGER { other(1), unknown(2), sheetFeedAutoRemovableTray(3), sheetFeedAutoNonRemovableTray(4), sheetFeedManual(5), continuousRoll(6), continuousFanFold(7) } PrtOutputTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtOutputType in RFC 1759. STATUS current DESCRIPTION "The Type of technology supported by this output subunit." SYNTAX INTEGER { other(1), unknown(2), removableBin(3), unRemovableBin(4), continuousRollDevice(5), mailBox(6), continuousFanFold(7) } Bergman, et al. Standards Track [Page 46] RFC 3805 Printer MIB v2 June 2004 -- -- Marker Group TEXTUAL-CONVENTIONs -- PrtMarkerMarkTechTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerMarkTech in RFC 1759. STATUS current DESCRIPTION "The type of marking technology used for this marking subunit." SYNTAX INTEGER { other(1), unknown(2), electrophotographicLED(3), electrophotographicLaser(4), electrophotographicOther(5), impactMovingHeadDotMatrix9pin(6), impactMovingHeadDotMatrix24pin(7), impactMovingHeadDotMatrixOther(8), impactMovingHeadFullyFormed(9), impactBand(10), impactOther(11), inkjetAqueous(12), inkjetSolid(13), inkjetOther(14), pen(15), thermalTransfer(16), thermalSensitive(17), thermalDiffusion(18), thermalOther(19), electroerosion(20), electrostatic(21), photographicMicrofiche(22), photographicImagesetter(23), photographicOther(24), ionDeposition(25), eBeam(26), typesetter(27) } PrtMarkerSuppliesTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerSuppliesType in RFC 1759. STATUS current DESCRIPTION "The type of this supply." SYNTAX INTEGER { other(1), unknown(2), Bergman, et al. Standards Track [Page 47] RFC 3805 Printer MIB v2 June 2004 -- Values for Printer MIB toner(3), wasteToner(4), ink(5), inkCartridge(6), inkRibbon(7), wasteInk(8), opc(9), -- photo conductor developer(10), fuserOil(11), solidWax(12), ribbonWax(13), wasteWax(14), fuser(15), -- Not in RFC 1759 coronaWire(16), -- Not in RFC 1759 fuserOilWick(17), -- Not in RFC 1759 cleanerUnit(18), -- Not in RFC 1759 fuserCleaningPad(19), -- Not in RFC 1759 transferUnit(20), -- Not in RFC 1759 tonerCartridge(21), -- Not in RFC 1759 fuserOiler(22), -- Not in RFC 1759 -- End of values for Printer MIB -- Values for Finisher MIB water(23), -- Not in RFC 1759 wasteWater(24), -- Not in RFC 1759 glueWaterAdditive(25),-- Not in RFC 1759 wastePaper(26), -- Not in RFC 1759 bindingSupply(27), -- Not in RFC 1759 bandingSupply(28), -- Not in RFC 1759 stitchingWire(29), -- Not in RFC 1759 shrinkWrap(30), -- Not in RFC 1759 paperWrap(31), -- Not in RFC 1759 staples(32), -- Not in RFC 1759 inserts(33), -- Not in RFC 1759 covers(34) -- Not in RFC 1759 -- End of values for Finisher MIB } -- -- Media Path TEXTUAL-CONVENTIONs -- PrtMediaPathTypeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMediaPathType in RFC 1759. STATUS current DESCRIPTION "The type of the media path for this media path." SYNTAX INTEGER { Bergman, et al. Standards Track [Page 48] RFC 3805 Printer MIB v2 June 2004 other(1), unknown(2), longEdgeBindingDuplex(3), shortEdgeBindingDuplex(4), simplex(5) } -- -- Console Group TEXTUAL-CONVENTIONs -- PrtConsoleColorTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtConsoleColor in RFC 1759. STATUS current DESCRIPTION "The color of this light." SYNTAX INTEGER { other(1), unknown(2), white(3), red(4), green(5), blue(6), cyan(7), magenta(8), yellow(9), orange(10) -- Not in RFC 1759 } PrtConsoleDisableTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtConsoleDisable in RFC 1759. STATUS current DESCRIPTION "This value indicates whether or not input is accepted from the operator console. A value of 'enabled' indicates that input is accepted from the console, and a value of 'disabled' indicates that input is not accepted from the console. " SYNTAX INTEGER { enabled(3), disabled(4) } -- -- Alert Group TEXTUAL-CONVENTIONs -- PrtAlertTrainingLevelTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtAlertTrainingLevel in RFC 1759. Bergman, et al. Standards Track [Page 49] RFC 3805 Printer MIB v2 June 2004 STATUS current DESCRIPTION "The level of training required to handle this alert, if human intervention is required. The noInterventionRequired value should be used if the event does not require any human intervention. The training level is an enumeration that is determined and assigned by the printer manufacturer based on the information or training required to handle this alert. The printer will break alerts into these different training levels. It is the responsibility of a management application in the system to determine how a particular alert is handled and how and to whom that alert is routed. The following are the four training levels of alerts: Field Service - Alerts that typically require advanced training and technical knowledge of the printer and its subunits. An example of a technical person would be a manufacturer's Field Service representative, or other person formally trained by the manufacturer or similar representative. Trained - Alerts that require an intermediate or moderate knowledge of the printer and its subunits. A typical example of such an alert is replacing a toner cartridge. Untrained - Alerts that can be fixed without prior training either because the action to correct the alert is obvious or the printer can help the untrained person fix the problem. A typical example of such an alert is reloading paper trays or emptying output bins on a low end printer. Management - Alerts that have to do with overall operation of and configuration of the printer. Examples of such management events are configuration change of subunits." SYNTAX INTEGER { other(1), unknown(2), untrained(3), trained(4), fieldService(5), management(6), noInterventionRequired(7) -- Not in RFC 1759 } PrtAlertGroupTC ::= TEXTUAL-CONVENTION -- Values in the range 1 to 29 must not be IANA-assigned without -- re-publishing Printer MIB. -- Values of 30 and greater are for use in MIBs that augment -- the Printer MIB, such as the Finisher MIB. -- This TC extracted from prtAlertGroup in RFC 1759. Bergman, et al. Standards Track [Page 50] RFC 3805 Printer MIB v2 June 2004 STATUS current DESCRIPTION "The type of subunit within the printer model that this alert is related. Input, output, and markers are examples of printer model groups, i.e., examples of types of subunits. Wherever possible, the enumerations match the sub-identifier that identifies the relevant table in the Printer MIB. NOTE: Alert type codes have been added for the Host Resources MIB storage table and device table. These additional types are for situations in which the printer's storage and device objects must generate alerts (and possibly traps for critical alerts)." SYNTAX INTEGER { other(1), -- (2) is reserved for conformance information -- Values for Host Resources MIB hostResourcesMIBStorageTable(3), hostResourcesMIBDeviceTable(4), -- Values for Printer MIB generalPrinter(5), cover(6), localization(7), input(8), output(9), marker(10), markerSupplies(11), markerColorant(12), mediaPath(13), channel(14), interpreter(15), consoleDisplayBuffer(16), consoleLights(17), alert(18), -- Not in RFC 1759 -- Values (5) to (29) reserved for Printer MIB -- Values for Finisher MIB finDevice(30), -- Not in RFC 1759 finSupply(31), -- Not in RFC 1759 finSupplyMediaInput(32), -- Not in RFC 1759 finAttribute(33) -- Not in RFC 1759 -- Values (30) to (39) reserved for Finisher MIB } PrtAlertCodeTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtAlertCode in RFC 1759. STATUS current DESCRIPTION "The code that describes the type of alert for this entry in Bergman, et al. Standards Track [Page 51] RFC 3805 Printer MIB v2 June 2004 the table. Binary change event alerts describe states of the subunit while unary change event alerts describe a single event. The same alert code can be used for a binary change event or a unary change event, depending on implementation. Also, the same alert code can be used to indicate a critical or non-critical (warning) alert, depending on implementation. The value of prtAlertSeverityLevel specifies binary vs. unary and critical vs. non-critical for each event for the implementation. While there are some specific codes for many subunits, the generic codes should be used for most subunit alerts. The network management station can then query the subunit specified by prtAlertGroup to determine further subunit status and other subunit information. An agent shall not add two entries to the alert table for the same event, one containing a generic event code and the other containing a specific event code; the agent shall add only one entry in the alert table for each event; either generic (preferred) or specific, not both. Implementation of the unary change event alertRemovalOfBinaryChangeEntry(1801) is optional. When implemented, this alert code shall indicate to network management stations that the trailing edge of a binary change event has occurred and the corresponding alert entry has been removed from the alert table. As with all events, the alertRemovalOfBinaryChangeEntry(1801) alert shall be placed at the end of the alert table. Such an alert table entry shall specify the following information: prtAlertSeverityLevel warningUnaryChangeEvent(4) prtAlertTrainingLevel noInterventionRequired(7) prtAlertGroup alert(18) prtAlertGroupIndex the index of the row in the alert table of the binary change event that this event has removed. prtAlertLocation unknown (-2) prtAlertCode alertRemovalOfBinaryChangeEntry(1801) prtAlertDescription prtAlertTime the value of sysUpTime at the time of the removal of the binary change event from the alert table. Optionally, the agent may generate a trap coincident with Bergman, et al. Standards Track [Page 52] RFC 3805 Printer MIB v2 June 2004 removing the binary change event and placing the unary change event alertRemovalOfBinaryChangeEntry(1801) in the alert table. For such a trap, the prtAlertIndex sent with the above trap parameters shall be the index of the alertRemovalOfBinaryChangeEvent row that was added to the prtAlertTable; not the index of the row that was removed from the prtAlertTable." SYNTAX INTEGER { other(1), -- an event that is not represented -- by one of the alert codes -- specified below. unknown(2), -- The following generic codes are common to -- multiple groups. The NMS may examine the -- prtAlertGroup object to determine what group -- to query for further information. coverOpen(3), coverClosed(4), interlockOpen(5), interlockClosed(6), configurationChange(7), jam(8), subunitMissing(9), -- Not in RFC 1759 -- The subunit tray, bin, etc. -- has been removed. subunitLifeAlmostOver(10), -- Not in RFC 1759 subunitLifeOver(11), -- Not in RFC 1759 subunitAlmostEmpty(12), -- Not in RFC 1759 subunitEmpty(13), -- Not in RFC 1759 subunitAlmostFull(14), -- Not in RFC 1759 subunitFull(15), -- Not in RFC 1759 subunitNearLimit(16), -- Not in RFC 1759 subunitAtLimit(17), -- Not in RFC 1759 subunitOpened(18), -- Not in RFC 1759 subunitClosed(19), -- Not in RFC 1759 subunitTurnedOn(20), -- Not in RFC 1759 subunitTurnedOff(21), -- Not in RFC 1759 subunitOffline(22), -- Not in RFC 1759 subunitPowerSaver(23), -- Not in RFC 1759 subunitWarmingUp(24), -- Not in RFC 1759 subunitAdded(25), -- Not in RFC 1759 subunitRemoved(26), -- Not in RFC 1759 subunitResourceAdded(27), -- Not in RFC 1759 subunitResourceRemoved(28), -- Not in RFC 1759 subunitRecoverableFailure(29), -- Not in RFC 1759 subunitUnrecoverableFailure(30), Bergman, et al. Standards Track [Page 53] RFC 3805 Printer MIB v2 June 2004 -- Not in RFC 1759 subunitRecoverableStorageError(31), -- Not in RFC 1759 subunitUnrecoverableStorageError(32), -- Not in RFC 1759 subunitMotorFailure(33), -- Not in RFC 1759 subunitMemoryExhausted(34), -- Not in RFC 1759 subunitUnderTemperature(35), -- Not in RFC 1759 subunitOverTemperature(36), -- Not in RFC 1759 subunitTimingFailure(37), -- Not in RFC 1759 subunitThermistorFailure(38), -- Not in RFC 1759 -- General Printer group doorOpen(501), -- DEPRECATED -- Use coverOpened(3) doorClosed(502), -- DEPRECATED -- Use coverClosed(4) powerUp(503), powerDown(504), printerNMSReset(505), -- Not in RFC 1759 -- The printer has been reset by some -- network management station(NMS) -- writing into 'prtGeneralReset'. printerManualReset(506), -- Not in RFC 1759 -- The printer has been reset manually. printerReadyToPrint(507), -- Not in RFC 1759 -- The printer is ready to print. (i.e., -- not warming up, not in power save -- state, not adjusting print quality, -- etc.). -- Input Group inputMediaTrayMissing(801), inputMediaSizeChange(802), inputMediaWeightChange(803), inputMediaTypeChange(804), inputMediaColorChange(805), inputMediaFormPartsChange(806), inputMediaSupplyLow(807), inputMediaSupplyEmpty(808), inputMediaChangeRequest(809), -- Not in RFC 1759 -- An interpreter has detected that a -- different medium is need in this input -- tray subunit. The prtAlertDescription may -- be used to convey a human readable -- description of the medium required to -- satisfy the request. inputManualInputRequest(810), -- Not in RFC 1759 Bergman, et al. Standards Track [Page 54] RFC 3805 Printer MIB v2 June 2004 -- An interpreter has detected that manual -- input is required in this subunit. The -- prtAlertDescription may be used to convey -- a human readable description of the medium -- required to satisfy the request. inputTrayPositionFailure(811), -- Not in RFC 1759 -- The input tray failed to position correctly. inputTrayElevationFailure(812), -- Not in RFC 1759 inputCannotFeedSizeSelected(813), -- Not in RFC 1759 -- Output Group outputMediaTrayMissing(901), outputMediaTrayAlmostFull(902), outputMediaTrayFull(903), outputMailboxSelectFailure(904), -- Not in RFC 1759 -- Marker group markerFuserUnderTemperature(1001), markerFuserOverTemperature(1002), markerFuserTimingFailure(1003), -- Not in RFC 1759 markerFuserThermistorFailure(1004), -- Not in RFC 1759 markerAdjustingPrintQuality(1005), -- Not in RFC 1759 -- Marker Supplies group markerTonerEmpty(1101), markerInkEmpty(1102), markerPrintRibbonEmpty(1103), markerTonerAlmostEmpty(1104), markerInkAlmostEmpty(1105), markerPrintRibbonAlmostEmpty(1106), markerWasteTonerReceptacleAlmostFull(1107), markerWasteInkReceptacleAlmostFull(1108), markerWasteTonerReceptacleFull(1109), markerWasteInkReceptacleFull(1110), markerOpcLifeAlmostOver(1111), markerOpcLifeOver(1112), markerDeveloperAlmostEmpty(1113), markerDeveloperEmpty(1114), markerTonerCartridgeMissing(1115), -- Not in RFC 1759 -- Media Path Device Group mediaPathMediaTrayMissing(1301), mediaPathMediaTrayAlmostFull(1302), mediaPathMediaTrayFull(1303), mediaPathCannotDuplexMediaSelected(1304), Bergman, et al. Standards Track [Page 55] RFC 3805 Printer MIB v2 June 2004 -- Not in RFC 1759 -- Interpreter Group interpreterMemoryIncrease(1501), interpreterMemoryDecrease(1502), interpreterCartridgeAdded(1503), interpreterCartridgeDeleted(1504), interpreterResourceAdded(1505), interpreterResourceDeleted(1506), interpreterResourceUnavailable(1507), interpreterComplexPageEncountered(1509), -- Not in RFC 1759 -- The interpreter has encountered a page -- that is too complex for the resources that -- are available. -- Alert Group alertRemovalOfBinaryChangeEntry(1801) -- Not in RFC 1759 -- A binary change event entry has been -- removed from the alert table. This unary -- change alert table entry is added to the -- end of the alert table. } END 6. The Printer MIB Printer-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, TimeTicks, NOTIFICATION-TYPE, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] hrDeviceIndex, hrStorageIndex FROM HOST-RESOURCES-MIB -- [RFC2790] InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] PrtCoverStatusTC, PrtGeneralResetTC, PrtChannelTypeTC, PrtInterpreterLangFamilyTC, PrtInputTypeTC, PrtOutputTypeTC, PrtMarkerMarkTechTC, PrtMarkerSuppliesTypeTC, PrtConsoleColorTC, PrtConsoleDisableTC, PrtMediaPathTypeTC, PrtAlertGroupTC, PrtAlertTrainingLevelTC, PrtAlertCodeTC FROM IANA-PRINTER-MIB IANACharset FROM IANA-CHARSET-MIB; printmib MODULE-IDENTITY LAST-UPDATED "200406020000Z" ORGANIZATION "PWG IEEE/ISTO Printer Working Group" Bergman, et al. Standards Track [Page 56] RFC 3805 Printer MIB v2 June 2004 CONTACT-INFO "Harry Lewis IBM Phone (303) 924-5337 Email: harryl@us.ibm.com http://www.pwg.org/index.html Send comments to the printmib WG using the Printer MIB Project (PMP) Mailing List: pmp@pwg.org For further information, access the PWG web page under 'Printer MIB': http://www.pwg.org/ Implementers of this specification are encouraged to join the pmp mailing list in order to participate in discussions on any clarifications needed and registration proposals being reviewed in order to achieve consensus." DESCRIPTION "The MIB module for management of printers. Copyright (C) The Internet Society (2004). This version of this MIB module was published in RFC 3805. For full legal notices see the RFC itself." REVISION "200406020000Z" DESCRIPTION "Printer MIB v2. Moved all enum groups to be maintained by IANA into new TCs within the ianaPrinterMIB, which is contained in this document. New TCs created from enums defined within RFC 1759 Objects: PrtPrintOrientationTC, PrtLocalizedDescriptionStringTC, PrtConsoleDescriptionStringTC, PrtChannelStateTC, PrtOutputStackingOrderTC, PrtOutputPageDeliveryOrientationTC, PrtMarkerCounterUnitTC, PrtMarkerSuppliesSupplyUnitTC, PrtMarkerSuppliesClassTC, PrtMarkerAddressabilityUnitTC, PrtMarkerColorantRoleTC, PrtMediaPathMaxSpeedPrintUnitTC, PrtInterpreterTwoWayTC, and PrtAlertSeverityLevelTC. The following four TCs have been deprecated: MediaUnit (replaced by PrtMediaUnitTC), CapacityUnit (replaced by PrtCapacityUnitTC), SubUnitStatus (replaced by PrtSubUnitStatusTC), CodedCharSet (replaced by IANACharset in IANA Charset MIB) Five new OBJECT-GROUPs: prtAuxilliarySheetGroup, prtInputSwitchingGroup, prtGeneralV2Group, prtAlertTableV2Group, prtChannelV2Group. Nine new objects added to those groups: prtAuxiliarySheetStartupPage, prtAuxiliarySheetBannerPage, prtGeneralPrinterName, prtGeneralSerialNumber, prtAlertCriticalEvents, prtAlertAllEvents, Bergman, et al. Standards Track [Page 57] RFC 3805 Printer MIB v2 June 2004 prtInputMediaLoadTimeout, prtInputNextIndex, prtChannelInformation. SYNTAX range changed from (0..65535) to (1..65535) for the index objects prtStorageRefSeqNumber, prtDeviceRefSeqNumber, and prtConsoleLightIndex. SYNTAX range changed from (0..65535) to (0..2147483647) for the objects prtStorageRefIndex and prtDeviceRefIndex to agree with the Host Resources MIB. Defined a range for the objects with a SYNTAX of Integer32: prtOutputDefaultIndex, prtInputMediaDimFeedDirDeclared, prtInputMediaDimXFeedDirDeclared, prtInputMaxCapacity, prtInputCurrentLevel, prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaFormParts, prtOutputIndex, prtOutputMaxCapacity, prtOutputRemainingCapacity, prtOutputMaxDimFeedDir, prtOutputMaxDimXFeedDir, prtOutputMinDimFeedDir, prtOutputMinDimXFeedDir, prtMarkerAddressibilityFeedDir, prtMarkerAddressibilityXFeedDir, prtMarkerNorthMargin, prtMarkerSouthMargin, prtMarkerWestMargin, prtMarkerEastMargin, prtMarkerSuppliesMaxCapacity, prtMarkerSuppliesLevel, prtMarkerColorantTonality, prtMediaPathMaxSpeed, prtMediaPathMaxMediaFeedDir, prtMediaPathMaxMediaXFeedDir, prtMediaPathMinMediaFeedDir, prtMediaPathMinMediaXFeedDir, prtChannelIndex, prtChannelCurrentJobCntlLangIndex, prtInterpreterIndex, prtChannelDefaultPageDescLangIndex, prtConsoleOnTime, prtInterpreterFeedAddressibility, prtConsoleOffTime, prtInterpreterXFeedAddressibility, prtAlertIndex, prtAlertGroupIndex, prtAlertLocation. Changed SYNTAX from Integer32 to InterfaceIndexOrZero for prtChannelIfIndex. Changed MAX-ACCESS of prtAlertIndex from not-accessible to Read-only and added a compliance statement to allow a MIN-ACCESS of accessible-for-notify. One new NOTIFICATION-GROUP: prtAlertTrapGroup which contains printerV2Alert. In MODULE-COMPLIANCE prtMIBCompliance, new OBJECT-GROUPs and the NOTIFICATION_GROUP, all in GROUP (not MANDATORY-GROUP) clauses. The nine new objects are optional, i.e., this document is backward compatible with RFC 1759." REVISION "199411250000Z" DESCRIPTION "The original version of this MIB, published as RFC1759." ::= { mib-2 43 } Bergman, et al. Standards Track [Page 58] RFC 3805 Printer MIB v2 June 2004 -- TEXTUAL-CONVENTIONs for this MIB module -- -- Generic unspecific TEXTUAL-CONVENTIONs -- PrtMediaUnitTC ::= TEXTUAL-CONVENTION -- Replaces MediaUnit in RFC 1759. STATUS current DESCRIPTION "Units of measure for media dimensions." SYNTAX INTEGER { tenThousandthsOfInches(3), -- .0001 micrometers(4) } MediaUnit ::= TEXTUAL-CONVENTION -- Replaced by PrtMediaUnitTC. STATUS deprecated DESCRIPTION "Units of measure for media dimensions." SYNTAX INTEGER { tenThousandthsOfInches(3), -- .0001 micrometers(4) } PrtCapacityUnitTC ::= TEXTUAL-CONVENTION -- Replaces CapacityUnit in RFC 1759. STATUS current DESCRIPTION "Units of measure for media capacity." SYNTAX INTEGER { other(1), -- New, not in RFC 1759 unknown(2), -- New, not in RFC 1759 tenThousandthsOfInches(3), -- .0001 micrometers(4), sheets(8), feet(16), meters(17), -- Values for Finisher MIB items(18), -- New, not in RFC 1759 percent(19) -- New, not in RFC 1759 } CapacityUnit ::= TEXTUAL-CONVENTION -- Replaced by PrtCapacityUnitTC. STATUS deprecated DESCRIPTION "Units of measure for media capacity." Bergman, et al. Standards Track [Page 59] RFC 3805 Printer MIB v2 June 2004 SYNTAX INTEGER { tenThousandthsOfInches(3), -- .0001 micrometers(4), sheets(8), feet(16), meters(17) } PrtPrintOrientationTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtInterpreterDefaultOrientation in -- RFC 1759. STATUS current DESCRIPTION "A generic representation for printing orientation on a 'page'." SYNTAX INTEGER { other(1), portrait(3), landscape(4) } PrtSubUnitStatusTC ::= TEXTUAL-CONVENTION -- Replaces SubUnitStatus in RFC 1759. STATUS current DESCRIPTION "Status of a printer sub-unit. The SubUnitStatus is an integer that is the sum of 5 distinct values, Availability, Non-Critical, Critical, On-line, and Transitioning. These values are: Availability Value Available and Idle 0 0000'b Available and Standby 2 0010'b Available and Active 4 0100'b Available and Busy 6 0110'b Unavailable and OnRequest 1 0001'b Unavailable because Broken 3 0011'b Unknown 5 0101'b Non-Critical No Non-Critical Alerts 0 0000'b Non-Critical Alerts 8 1000'b Critical No Critical Alerts 0 0000'b Bergman, et al. Standards Track [Page 60] RFC 3805 Printer MIB v2 June 2004 Critical Alerts 16 1 0000'b On-Line State is On-Line 0 0000'b State is Off-Line 32 10 0000'b Transitioning At intended state 0 0000'b Transitioning to intended state 64 100 0000'b" SYNTAX INTEGER (0..126) SubUnitStatus ::= TEXTUAL-CONVENTION -- Replaced by PrtSubUnitStatusTC. STATUS deprecated DESCRIPTION "Status of a printer sub-unit. The SubUnitStatus is an integer that is the sum of 5 distinct values, Availability, Non-Critical, Critical, On-line, and Transitioning. These values are: Availability Value Available and Idle 0 0000'b Available and Standby 2 0010'b Available and Active 4 0100'b Available and Busy 6 0110'b Unavailable and OnRequest 1 0001'b Unavailable because Broken 3 0011'b Unknown 5 0101'b Non-Critical No Non-Critical Alerts 0 0000'b Non-Critical Alerts 8 1000'b Critical No Critical Alerts 0 0000'b Critical Alerts 16 1 0000'b On-Line State is On-Line 0 0000'b State is Off-Line 32 10 0000'b Transitioning Bergman, et al. Standards Track [Page 61] RFC 3805 Printer MIB v2 June 2004 At intended state 0 0000'b Transitioning to intended state 64 100 0000'b" SYNTAX INTEGER (0..126) PresentOnOff ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Presence and configuration of a device or feature." SYNTAX INTEGER { other(1), on(3), off(4), notPresent(5) } PrtLocalizedDescriptionStringTC ::= TEXTUAL-CONVENTION -- This TC did not appear in RFC 1759. STATUS current DESCRIPTION "An object MUST use this TEXTUAL-CONVENTION when its 'charset' is controlled by the value of prtGeneralCurrentLocalization." SYNTAX OCTET STRING (SIZE(0..255)) PrtConsoleDescriptionStringTC ::= TEXTUAL-CONVENTION -- This TC did not appear in RFC 1759. STATUS current DESCRIPTION "An object MUST use this TEXTUAL-CONVENTION when its 'charset' is controlled by the value of prtConsoleLocalization." SYNTAX OCTET STRING (SIZE(0..255)) CodedCharSet ::= TEXTUAL-CONVENTION -- Replaced by IANACharset TEXTUAL-CONVENTION in IANA Charset MIB. STATUS deprecated DESCRIPTION "The original description clause from RFC 1759 [RFC1759] was technically inaccurate and therefore has been deleted." SYNTAX INTEGER { other(1) -- used if the designated coded -- character set is not currently in -- the enumeration } -- Bergman, et al. Standards Track [Page 62] RFC 3805 Printer MIB v2 June 2004 -- Channel Group TEXTUAL-CONVENTIONs -- PrtChannelStateTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtChannelState in RFC 1759. STATUS current DESCRIPTION "The state of this print job delivery channel. The value determines whether print data is allowed through this channel." SYNTAX INTEGER { other(1), printDataAccepted(3), noDataAccepted(4) } -- -- Input/Output Group TEXTUAL-CONVENTIONs -- PrtOutputStackingOrderTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtOutputStackingOrder in RFC 1759. STATUS current DESCRIPTION "The current state of the stacking order for the associated output sub-unit. 'firstToLast' means that as pages are output, the front of the next page is placed against the back of the previous page. 'lastToFirst' means that as pages are output, the back of the next page is placed against the front of the previous page." SYNTAX INTEGER { unknown(2), firstToLast(3), lastToFirst(4) } PrtOutputPageDeliveryOrientationTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtOutputPageDeliveryOrientation -- in RFC 1759. STATUS current DESCRIPTION "The reading surface that will be 'up' when pages are delivered to the associated output sub-unit. Values are Face-Up and Face Down (Note: interpretation of these values is, in general, context-dependent based on locale; presentation of these values to an end-user should be normalized to the expectations of the user." SYNTAX INTEGER { faceUp(3), Bergman, et al. Standards Track [Page 63] RFC 3805 Printer MIB v2 June 2004 faceDown(4) } -- -- Marker Group TEXTUAL-CONVENTIONs -- PrtMarkerCounterUnitTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerCounterUnit in RFC 1759. STATUS current DESCRIPTION "The unit that will be used by the printer when reporting counter values for this marking sub-unit. The time units of measure are provided for a device like a strip recorder that does not or cannot track the physical dimensions of the media and does not use characters, lines or sheets." SYNTAX INTEGER { tenThousandthsOfInches(3), -- .0001 micrometers(4), characters(5), lines(6), impressions(7), sheets(8), dotRow(9), hours(11), feet(16), meters(17) } PrtMarkerSuppliesSupplyUnitTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerSuppliesSupplyUnit -- in RFC 1759. STATUS current DESCRIPTION "Unit of this marker supply container/receptacle." SYNTAX INTEGER { other(1), -- New, not in RFC 1759 unknown(2), -- New, not in RFC 1759 tenThousandthsOfInches(3), -- .0001 micrometers(4), impressions(7), -- New, not in RFC 1759 sheets(8), -- New, not in RFC 1759 hours(11), -- New, not in RFC 1759 thousandthsOfOunces(12), tenthsOfGrams(13), hundrethsOfFluidOunces(14), Bergman, et al. Standards Track [Page 64] RFC 3805 Printer MIB v2 June 2004 tenthsOfMilliliters(15), feet(16), -- New, not in RFC 1759 meters(17), -- New, not in RFC 1759 -- Values for Finisher MIB items(18), -- e.g., #staples. New, not in RFC 1759 percent(19) -- New, not in RFC 1759 } PrtMarkerSuppliesClassTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerSuppliesClass in RFC 1759. STATUS current DESCRIPTION "Indicates whether this supply entity represents a supply that is consumed or a receptacle that is filled." SYNTAX INTEGER { other(1), supplyThatIsConsumed(3), receptacleThatIsFilled(4) } PrtMarkerColorantRoleTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerColorantRole in RFC 1759. STATUS current DESCRIPTION "The role played by this colorant." SYNTAX INTEGER { -- Colorant Role other(1), process(3), spot(4) } PrtMarkerAddressabilityUnitTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtMarkerAddressabilityUnit -- in RFC 1759. STATUS current DESCRIPTION "The unit of measure of distances, as applied to the marker's resolution." SYNTAX INTEGER { tenThousandthsOfInches(3), -- .0001 micrometers(4) } -- -- Media Path TEXTUAL-CONVENTIONs -- PrtMediaPathMaxSpeedPrintUnitTC ::= TEXTUAL-CONVENTION Bergman, et al. Standards Track [Page 65] RFC 3805 Printer MIB v2 June 2004 -- This TC was extracted from prtMediaPathMaxSpeedPrintUnit -- in RFC 1759. STATUS current DESCRIPTION "The unit of measure used in specifying the speed of all media paths in the printer." SYNTAX INTEGER { tenThousandthsOfInchesPerHour(3),-- .0001/hour micrometersPerHour(4), charactersPerHour(5), linesPerHour(6), impressionsPerHour(7), sheetsPerHour(8), dotRowPerHour(9), feetPerHour(16), metersPerHour(17) } -- -- Interpreter Group TEXTUAL-CONVENTIONs -- PrtInterpreterTwoWayTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtInterpreterTwoWay in RFC 1759. STATUS current DESCRIPTION "Indicates whether or not this interpreter returns information back to the host." SYNTAX INTEGER { yes(3), no(4) } -- -- Alert Group TEXTUAL-CONVENTIONs -- PrtAlertSeverityLevelTC ::= TEXTUAL-CONVENTION -- This TC was extracted from prtAlertSeverityLevel in RFC 1759. STATUS current DESCRIPTION "The level of severity of this alert table entry. The printer determines the severity level assigned to each entry in the table. A critical alert is binary by nature and definition. A warning is defined to be a non-critical alert. The original and most common warning is unary. The binary warning was added later and given a more distinguished name." SYNTAX INTEGER { Bergman, et al. Standards Track [Page 66] RFC 3805 Printer MIB v2 June 2004 other(1), critical(3), warning(4), warningBinaryChangeEvent(5) -- New, not in RFC 1759 } -- The General Printer Group -- -- The general printer sub-unit is responsible for the overall -- control and status of the printer. There is exactly one -- general printer sub-unit in a printer. prtGeneral OBJECT IDENTIFIER ::= { printmib 5 } prtGeneralTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtGeneralEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of general information per printer. Objects in this table are defined in various places in the MIB, nearby the groups to which they apply. They are all defined here to minimize the number of tables that would otherwise need to exist." ::= { prtGeneral 1 } prtGeneralEntry OBJECT-TYPE SYNTAX PrtGeneralEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry exists in this table for each device entry in the host resources MIB device table with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex } ::= { prtGeneralTable 1 } PrtGeneralEntry ::= SEQUENCE { -- Note that not all of the objects in this sequence are in -- the general printer group. The group to which an -- object belongs is tagged with a label "General", "Input" -- "Output", etc. after each entry in the following sequence. -- prtGeneralConfigChanges Counter32, -- General Bergman, et al. Standards Track [Page 67] RFC 3805 Printer MIB v2 June 2004 prtGeneralCurrentLocalization Integer32, -- General prtGeneralReset PrtGeneralResetTC, -- General prtGeneralCurrentOperator OCTET STRING, -- Responsible Party prtGeneralServicePerson OCTET STRING, -- Responsible Party prtInputDefaultIndex Integer32, -- Input prtOutputDefaultIndex Integer32, -- Output prtMarkerDefaultIndex Integer32, -- Marker prtMediaPathDefaultIndex Integer32, -- Media Path prtConsoleLocalization Integer32, -- Console prtConsoleNumberOfDisplayLines Integer32, -- Console prtConsoleNumberOfDisplayChars Integer32, -- Console prtConsoleDisable PrtConsoleDisableTC, -- Console, prtAuxiliarySheetStartupPage PresentOnOff, -- AuxiliarySheet prtAuxiliarySheetBannerPage PresentOnOff, -- AuxiliarySheet prtGeneralPrinterName OCTET STRING, -- General V2 prtGeneralSerialNumber OCTET STRING, -- General V2 prtAlertCriticalEvents Counter32, -- Alert V2 prtAlertAllEvents Counter32 -- Alert V2 } prtGeneralConfigChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Counts configuration changes within the printer. A configuration change is defined to be an action that results in a change to any MIB object other than those that reflect status or level, or those that act as counters or gauges. In addition, any action that results in a row being added or deleted from any table in the Printer MIB is considered a configuration change. Such changes will often affect the capability of the printer to service certain types of print jobs. Management applications may cache infrequently changed configuration information about sub units within the printer. This object should be incremented whenever the agent wishes to notify management applications that any cached configuration information for this device is to be considered 'stale'. At this point, the management application should flush any configuration information cached about this device and fetch Bergman, et al. Standards Track [Page 68] RFC 3805 Printer MIB v2 June 2004 new configuration information. The following are examples of actions that would cause the prtGeneralConfigChanges object to be incremented: - Adding an output bin - Changing the media in a sensing input tray - Changing the value of prtInputMediaType Note that the prtGeneralConfigChanges counter would not be incremented when an input tray is temporarily removed to load additional paper or when the level of an input device changes. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtGeneralEntry 1 } prtGeneralCurrentLocalization OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of the prtLocalizationIndex corresponding to the current language, country, and character set to be used for localized string values that are identified as being dependent on the value of this object. Note that this object does not apply to localized strings in the prtConsole group or to any object that is not explicitly identified as being localized according to prtGeneralCurrentLocalization. When an object's 'charset' is controlled by the value of prtGeneralCurrentLocalization, it MUST specify PrtLocalizedDescriptionStringTC as its syntax. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtGeneralEntry 2 } prtGeneralReset OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly defined -- by this object. SYNTAX PrtGeneralResetTC MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this value to 'powerCycleReset', 'resetToNVRAM', or 'resetToFactoryDefaults' will result in the resetting of the printer. When read, this object will always have the value Bergman, et al. Standards Track [Page 69] RFC 3805 Printer MIB v2 June 2004 'notResetting(3)', and a SET of the value 'notResetting' shall have no effect on the printer. Some of the defined values are optional. However, every implementation must support at least the values 'notResetting' and 'resetToNVRAM'." ::= { prtGeneralEntry 3 } -- The Responsible Party group prtGeneralCurrentOperator OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..127)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name of the person who is responsible for operating this printer. It is suggested that this string include information that would enable other humans to reach the operator, such as a phone number. As a convention to facilitate automatic notification of the operator by the agent or network management station, the phone number, fax number or email address should be indicated by the URL schemes 'tel:', 'fax:' and 'mailto:', respectively. If either the phone, fax, or email information is not available, then a line should not be included for this information. NOTE: For interoperability purposes, it is advisable to use email addresses formatted according to [RFC2822] requirements. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtGeneralEntry 4 } prtGeneralServicePerson OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..127)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name of the person responsible for servicing this printer. It is suggested that this string include information that would enable other humans to reach the service person, such as a phone number. As a convention to facilitate automatic notification of the operator by the agent or network management station, the phone number, fax number or email address should be indicated by the URL schemes 'tel:', 'fax:' and 'mailto:', respectively. If either the phone, fax, or email information is not available, then a line should not Bergman, et al. Standards Track [Page 70] RFC 3805 Printer MIB v2 June 2004 be included for this information. NOTE: For interoperability purposes, it is advisable to use email addresses formatted per [RFC2822] requirements. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtGeneralEntry 5 } -- Default indexes section -- -- The following four objects are used to specify the indexes of -- certain subunits used as defaults during the printing process. prtInputDefaultIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtInputIndex corresponding to the default input sub-unit: that is, this object selects the default source of input media." ::= { prtGeneralEntry 6 } prtOutputDefaultIndex OBJECT-TYPE -- A range has been added to the SYNTAX clause that was not in -- RFC 1759. Although this violates SNMP compatibility rules, -- it provides a more reasonable guide for SNMP managers. SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtOutputIndex corresponding to the default output sub-unit; that is, this object selects the default output destination." ::= { prtGeneralEntry 7 } prtMarkerDefaultIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtMarkerIndex corresponding to the default marker sub-unit; that is, this object selects the default marker." ::= { prtGeneralEntry 8 } Bergman, et al. Standards Track [Page 71] RFC 3805 Printer MIB v2 June 2004 prtMediaPathDefaultIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtMediaPathIndex corresponding to the default media path; that is, the selection of the default media path." ::= { prtGeneralEntry 9 } -- Console general section -- -- The following four objects describe overall parameters of the -- printer console subsystem. prtConsoleLocalization OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of the prtLocalizationIndex corresponding to the language, country, and character set to be used for the console. This localization applies both to the actual display on the console as well as the encoding of these console objects in management operations. When an object's 'charset' is controlled by the value of prtConsoleLocalization, it MUST specify PrtConsoleDescriptionStringTC as its syntax. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtGeneralEntry 10 } prtConsoleNumberOfDisplayLines OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of lines on the printer's physical display. This value is 0 if there are no lines on the physical display or if there is no physical display" ::= { prtGeneralEntry 11 } prtConsoleNumberOfDisplayChars OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of characters per line displayed on the physical Bergman, et al. Standards Track [Page 72] RFC 3805 Printer MIB v2 June 2004 display. This value is 0 if there are no lines on the physical display or if there is no physical display" ::= { prtGeneralEntry 12 } prtConsoleDisable OBJECT-TYPE -- In RFC 1759, the enumeration values were implicitly defined -- by this object. SYNTAX PrtConsoleDisableTC MAX-ACCESS read-write STATUS current DESCRIPTION "This value indicates how input is (or is not) accepted from the operator console. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtGeneralEntry 13 } -- The Auxiliary Sheet Group -- -- The auxiliary sheet group allows the administrator to control -- the production of auxiliary sheets by the printer. This group -- contains only the "prtAuxiliarySheetStartupPage" and -- "prtAuxiliarySheetBannerPage" objects. prtAuxiliarySheetStartupPage OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "Used to enable or disable printing a startup page. If enabled, a startup page will be printed shortly after power-up, when the device is ready. Typical startup pages include test patterns and/or printer configuration information." ::= { prtGeneralEntry 14 } prtAuxiliarySheetBannerPage OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "Used to enable or disable printing banner pages at the beginning of jobs. This is a master switch which applies to all jobs, regardless of interpreter." ::= { prtGeneralEntry 15 } Bergman, et al. Standards Track [Page 73] RFC 3805 Printer MIB v2 June 2004 -- Administrative section (The General V2 Group) -- -- The following two objects are used to specify administrative -- information assigned to the printer. prtGeneralPrinterName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..127)) MAX-ACCESS read-write STATUS current DESCRIPTION "An administrator-specified name for this printer. Depending upon implementation of this printer, the value of this object may or may not be same as the value for the MIB-II 'SysName' object." ::= { prtGeneralEntry 16 } prtGeneralSerialNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "A recorded serial number for this device that indexes some type device catalog or inventory. This value is usually set by the device manufacturer but the MIB supports the option of writing for this object for site-specific administration of device inventory or tracking." ::= { prtGeneralEntry 17 } -- General alert table section (Alert Table V2 Group) -- -- The following two objects are used to specify counters -- associated with the Alert Table. prtAlertCriticalEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A running counter of the number of critical alert events that have been recorded in the alert table. The value of this object is RESET in the event of a power cycle operation (i.e., the value is not persistent." ::= { prtGeneralEntry 18 } prtAlertAllEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Bergman, et al. Standards Track [Page 74] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "A running counter of the total number of alert event entries (critical and non-critical) that have been recorded in the alert table" ::= { prtGeneralEntry 19 } -- The Cover Table -- -- The cover portion of the General print sub-unit describes the -- covers and interlocks of the printer. The Cover Table has an -- entry for each cover and interlock. prtCover OBJECT IDENTIFIER ::= { printmib 6 } prtCoverTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtCoverEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the covers and interlocks of the printer." ::= { prtCover 1 } prtCoverEntry OBJECT-TYPE SYNTAX PrtCoverEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a cover or interlock. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtCoverIndex } ::= { prtCoverTable 1 } PrtCoverEntry ::= SEQUENCE { prtCoverIndex Integer32, prtCoverDescription PrtLocalizedDescriptionStringTC, prtCoverStatus PrtCoverStatusTC } prtCoverIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this Cover sub Bergman, et al. Standards Track [Page 75] RFC 3805 Printer MIB v2 June 2004 unit. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new cover sub-units to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtCoverEntry 1 } prtCoverDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturer provided cover sub-mechanism name in the localization specified by prtGeneralCurrentLocalization." ::= { prtCoverEntry 2 } prtCoverStatus OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly defined -- by this object and are now defined in the IANA-PRINTER-MIB. The -- new TC has defined "coverOpen" and "coverClosed" to replace -- "doorOpen" and "doorClosed" in RFC 1759. A name change is not -- formally allowed per SMI rules, but was agreed to by the WG group -- since a door has a more restrictive meaning than a cover and -- Cover group is intended to support doors as a subset of covers. SYNTAX PrtCoverStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The status of this cover sub-unit." ::= { prtCoverEntry 3 } -- The Localization Table -- -- The localization portion of the General printer sub-unit is -- responsible for identifying the natural language, country, and -- character set in which character strings are expressed. There -- may be one or more localizations supported per printer. The -- available localizations are represented by the Localization -- table. prtLocalization OBJECT IDENTIFIER ::= { printmib 7 } prtLocalizationTable OBJECT-TYPE Bergman, et al. Standards Track [Page 76] RFC 3805 Printer MIB v2 June 2004 SYNTAX SEQUENCE OF PrtLocalizationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The available localizations in this printer." ::= { prtLocalization 1 } prtLocalizationEntry OBJECT-TYPE SYNTAX PrtLocalizationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A description of a localization. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtLocalizationIndex } ::= { prtLocalizationTable 1 } PrtLocalizationEntry ::= SEQUENCE { prtLocalizationIndex Integer32, prtLocalizationLanguage OCTET STRING, prtLocalizationCountry OCTET STRING, prtLocalizationCharacterSet IANACharset } prtLocalizationIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this localization entry. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new localization data to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtLocalizationEntry 1 } prtLocalizationLanguage OBJECT-TYPE -- Note: The size is fixed, was incorrectly 0..2 in RFC 1759. SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-only STATUS current Bergman, et al. Standards Track [Page 77] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "A two character language code from ISO 639. Examples en, es, fr, de. NOTE: These examples were shown as upper case in RFC 1759 and are now shown as lower case to agree with ISO 639." ::= { prtLocalizationEntry 2 } prtLocalizationCountry OBJECT-TYPE -- Note: The size is fixed, was incorrectly 0..2 in RFC 1759. SYNTAX OCTET STRING (SIZE(2)) MAX-ACCESS read-only STATUS current DESCRIPTION "A two character country code from ISO 3166, a blank string (two space characters) shall indicate that the country is not defined. Examples: US, GB, FR, DE, ..." ::= { prtLocalizationEntry 3 } prtLocalizationCharacterSet OBJECT-TYPE SYNTAX IANACharset MAX-ACCESS read-only STATUS current DESCRIPTION "The coded character set used for this localization." ::= { prtLocalizationEntry 4 } -- The System Resources Tables -- -- The Printer MIB makes use of the Host Resources MIB to -- define system resources by referencing the storage -- and device groups of the print group. prtStorageRefTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtStorageRefEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines which printer, amongst multiple printers serviced by one agent, owns which storage units. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtGeneral 2 } prtStorageRefEntry OBJECT-TYPE SYNTAX PrtStorageRefEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Bergman, et al. Standards Track [Page 78] RFC 3805 Printer MIB v2 June 2004 "This table will have an entry for each entry in the Host Resources MIB storage table that represents storage associated with a printer managed by this agent. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrStorageIndex, prtStorageRefSeqNumber } ::= { prtStorageRefTable 1 } PrtStorageRefEntry ::= SEQUENCE { prtStorageRefSeqNumber Integer32, prtStorageRefIndex Integer32 } prtStorageRefSeqNumber OBJECT-TYPE -- NOTE: The range has been changed from RFC 1759, which allowed a -- minumum value of zero. This was incorrect, since zero is not a -- valid index. SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value will be unique amongst all entries with a common value of hrStorageIndex. This object allows a storage entry to point to the multiple printer devices with which it is associated." ::= { prtStorageRefEntry 1 } prtStorageRefIndex OBJECT-TYPE -- NOTE: The range has been changed from RFC 1759 to be compatible -- with the defined range of hrDeviceIndex. SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the hrDeviceIndex of the printer device that this storageEntry is associated with." ::= { prtStorageRefEntry 2 } prtDeviceRefTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtDeviceRefEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines which printer, amongst multiple printers serviced by one agent, is associated with which devices. NOTE: The above description has been modified from RFC 1759 Bergman, et al. Standards Track [Page 79] RFC 3805 Printer MIB v2 June 2004 for clarification." ::= { prtGeneral 3 } prtDeviceRefEntry OBJECT-TYPE SYNTAX PrtDeviceRefEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table will have an entry for each entry in the Host Resources MIB device table that represents a device associated with a printer managed by this agent. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtDeviceRefSeqNumber } ::= { prtDeviceRefTable 1 } PrtDeviceRefEntry ::= SEQUENCE { prtDeviceRefSeqNumber Integer32, prtDeviceRefIndex Integer32 } prtDeviceRefSeqNumber OBJECT-TYPE -- NOTE: The range has been changed from RFC 1759, which allowed a -- minumum value of zero. This was incorrect, since zero is not a -- valid index. SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value will be unique amongst all entries with a common value of hrDeviceIndex. This object allows a device entry to point to the multiple printer devices with which it is associated." ::= { prtDeviceRefEntry 1 } prtDeviceRefIndex OBJECT-TYPE -- NOTE: The range has been changed from RFC 1759 to be compatible -- with the defined range of hrDeviceIndex. SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the hrDeviceIndex of the printer device that this deviceEntry is associated with." ::= { prtDeviceRefEntry 2 } Bergman, et al. Standards Track [Page 80] RFC 3805 Printer MIB v2 June 2004 -- The Input Group -- -- Input sub-units are managed as a tabular, indexed collection -- of possible devices capable of providing media for input to -- the printing process. Input sub-units typically have a -- location, a type, an identifier, a set of constraints on -- possible media sizes and potentially other media -- characteristics, and may be capable of indicating current -- status or capacity. prtInput OBJECT IDENTIFIER ::= { printmib 8 } prtInputTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the devices capable of providing media for input to the printing process." ::= { prtInput 2 } prtInputEntry OBJECT-TYPE SYNTAX PrtInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of a device capable of providing media for input to the printing process. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtInputIndex } ::= { prtInputTable 1 } PrtInputEntry ::= SEQUENCE { prtInputIndex Integer32, prtInputType PrtInputTypeTC, prtInputDimUnit PrtMediaUnitTC, prtInputMediaDimFeedDirDeclared Integer32, prtInputMediaDimXFeedDirDeclared Integer32, prtInputMediaDimFeedDirChosen Integer32, prtInputMediaDimXFeedDirChosen Integer32, prtInputCapacityUnit PrtCapacityUnitTC, prtInputMaxCapacity Integer32, prtInputCurrentLevel Integer32, prtInputStatus PrtSubUnitStatusTC, prtInputMediaName OCTET STRING, Bergman, et al. Standards Track [Page 81] RFC 3805 Printer MIB v2 June 2004 prtInputName OCTET STRING, prtInputVendorName OCTET STRING, prtInputModel OCTET STRING, prtInputVersion OCTET STRING, prtInputSerialNumber OCTET STRING, prtInputDescription PrtLocalizedDescriptionStringTC, prtInputSecurity PresentOnOff, prtInputMediaWeight Integer32, prtInputMediaType OCTET STRING, prtInputMediaColor OCTET STRING, prtInputMediaFormParts Integer32, prtInputMediaLoadTimeout Integer32, prtInputNextIndex Integer32 } prtInputIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this input sub-unit. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new input sub-units to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtInputEntry 1 } prtInputType OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInputTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of technology (discriminated primarily according to feeder mechanism type) employed by the input sub-unit. Note, the Input Class provides for a descriptor field to further qualify the other choice." ::= { prtInputEntry 2 } prtInputDimUnit OBJECT-TYPE SYNTAX PrtMediaUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION Bergman, et al. Standards Track [Page 82] RFC 3805 Printer MIB v2 June 2004 "The unit of measurement for use calculating and relaying dimensional values for this input sub-unit." ::= { prtInputEntry 3 } prtInputMediaDimFeedDirDeclared OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the value of the declared dimension, in the feed direction, of the media that is (or, if empty, was or will be) in this input sub-unit. The feed direction is the direction in which the media is fed on this sub-unit. This dimension is measured in input sub-unit dimensional units (controlled by prtInputDimUnit, which uses PrtMediaUnitTC). If this input sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests. Otherwise, the value may be changed. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (-2) indicates unknown." ::= { prtInputEntry 4 } prtInputMediaDimXFeedDirDeclared OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the value of the declared dimension, in the cross feed direction, of the media that is (or, if empty, was or will be) in this input sub-unit. The cross feed direction is ninety degrees relative to the feed direction associated with this sub-unit. This dimension is measured in input sub-unit dimensional units (controlled by prtInputDimUnit,which uses PrtMediaUnitTC). If this input sub- unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests. Otherwise, the value may be changed. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (-2) indicates unknown." ::= { prtInputEntry 5 } prtInputMediaDimFeedDirChosen OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only Bergman, et al. Standards Track [Page 83] RFC 3805 Printer MIB v2 June 2004 STATUS current DESCRIPTION "The printer will act as if media of the chosen dimension (in the feed direction) is present in this input source. Note that this value will be used even if the input tray is empty. Feed dimension measurements are taken relative to the feed direction associated with that sub-unit and are in input sub-unit dimensional units (controlled by prtInputDimUnit, which uses PrtMediaUnitTC). If the printer supports the declared dimension,the granted dimension is the same as the declared dimension. If not, the granted dimension is set to the closest dimension that the printer supports when the declared dimension is set. The value (-1) means other and specifically indicates that this sub-unit places no restriction on this parameter. The value (-2)indicates unknown." ::= { prtInputEntry 6 } prtInputMediaDimXFeedDirChosen OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The printer will act as if media of the chosen dimension (in the cross feed direction) is present in this input source. Note that this value will be used even if the input tray is empty. The cross feed direction is ninety degrees relative to the feed direction associated with this sub-unit. This dimension is measured in input sub-unit dimensional units (controlled by prtInputDimUnit, which uses PrtMediaUnitTC). If the printer supports the declare dimension, the granted dimension is the same as the declared dimension. If not, the granted dimension is set to the closest dimension that the printer supports when the declared dimension is set. The value (-1) means other and specifically indicates that this sub-unit places no restriction on this parameter. The value (-2) indicates unknown." ::= { prtInputEntry 7 } prtInputCapacityUnit OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtCapacityUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measurement for use in calculating and relaying capacity values for this input sub-unit." ::= { prtInputEntry 8 } Bergman, et al. Standards Track [Page 84] RFC 3805 Printer MIB v2 June 2004 prtInputMaxCapacity OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum capacity of the input sub-unit in input sub-unit capacity units (PrtCapacityUnitTC). There is no convention associated with the media itself so this value reflects claimed capacity. If this input sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown." ::= { prtInputEntry 9 } prtInputCurrentLevel OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-3..2147483647) -- in capacity units -- (PrtCapacityUnitTC). MAX-ACCESS read-write STATUS current DESCRIPTION "The current capacity of the input sub-unit in input sub-unit capacity units (PrtCapacityUnitTC). If this input sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. The value (-3) means that the printer knows that at least one unit remains." ::= { prtInputEntry 10 } prtInputStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of this input sub-unit." ::= { prtInputEntry 11 } prtInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current Bergman, et al. Standards Track [Page 85] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "A description of the media contained in this input sub-unit; This description is to be used by a client to format and Localize a string for display to a human operator. This description is not processed by the printer. It is used to provide information not expressible in terms of the other media attributes (e.g., prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputMediaWeight, prtInputMediaType)." -- The following reference was not included in RFC 1759. REFERENCE "The PWG Standardized Media Names specification [PWGMEDIA] contains the recommended values for this object. See also RFC 3805 Appendix C,'Media Names', which lists the values Of standardized media names defined in ISO/IEC 10175." ::= { prtInputEntry 12 } -- INPUT MEASUREMENT -- -- _______ | | -- ^ | | -- | | | | -- | |_ _ _ _ _ _ _ _| _______________ |direction -- | | | ^ v -- MaxCapacity | Sheets | | -- | | left | CurrentLevel -- | | in | | -- v | tray | v -- _______ +_______________+ _______ -- The Extended Input Group prtInputName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name assigned to this input sub-unit." ::= { prtInputEntry 13 } prtInputVendorName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor name of this input sub-unit." ::= { prtInputEntry 14 } Bergman, et al. Standards Track [Page 86] RFC 3805 Printer MIB v2 June 2004 prtInputModel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The model name of this input sub-unit." ::= { prtInputEntry 15 } prtInputVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of this input sub-unit." ::= { prtInputEntry 16 } prtInputSerialNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The serial number assigned to this input sub-unit." ::= { prtInputEntry 17 } prtInputDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "A free-form text description of this input sub-unit in the localization specified by prtGeneralCurrentLocalization." ::= { prtInputEntry 18 } prtInputSecurity OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if this input sub-unit has some security associated with it." ::= { prtInputEntry 19 } -- The Input Media Group -- -- The Input Media Group supports identification of media -- installed or available for use on a printing device. Bergman, et al. Standards Track [Page 87] RFC 3805 Printer MIB v2 June 2004 -- Medium resources are identified by name, and include a -- collection of characteristic attributes that may further be -- used for selection and management of them. -- The Input Media group consists of a set of optional -- "columns" in the Input Table. In this manner, a minimally -- conforming implementation may choose to not support reporting -- of media resources if it cannot do so. prtInputMediaWeight OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The weight of the medium associated with this input sub-unit in grams / per meter squared. The value (-2) means unknown." ::= { prtInputEntry 20 } prtInputMediaType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name of the type of medium associated with this input sub unit. This name need not be processed by the printer; it might simply be displayed to an operator. NOTE: The above description has been modified from RFC 1759." -- The following reference was not included in RFC 1759. REFERENCE "The PWG Standardized Media Names specification [PWGMEDIA], section 3 Media Type Names, contains the recommended values for this object. Implementers may add additional string values. The naming conventions in ISO 9070 are recommended in order to avoid potential name clashes." ::= { prtInputEntry 21 } prtInputMediaColor OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name of the color of the medium associated with this input sub-unit using standardized string values. NOTE: The above description has been modified from RFC 1759." -- The following reference was not included in RFC 1759. REFERENCE Bergman, et al. Standards Track [Page 88] RFC 3805 Printer MIB v2 June 2004 "The PWG Standardized Media Names specification [PWGMEDIA], section 4 Media Color Names, contains the recommended values for this object. Implementers may add additional string values. The naming conventions in ISO 9070 are recommended in order to avoid potential name clashes." ::= { prtInputEntry 22 } prtInputMediaFormParts OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The number of parts associated with the medium associated with this input sub-unit if the medium is a multi-part form. The value (-1) means other and specifically indicates that the device places no restrictions on this parameter. The value (-2) means unknown." ::= { prtInputEntry 23 } -- The Input Switching Group -- -- The input switching group allows the administrator to set the -- input subunit time-out for the printer and to control the -- automatic input subunit switching by the printer when an input -- subunit becomes empty. prtInputMediaLoadTimeout OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "When the printer is not able to print due to a subunit being empty or the requested media must be manually loaded, the printer will wait for the duration (in seconds) specified by this object. Upon expiration of the time-out, the printer will take the action specified by prtInputNextIndex. The event which causes the printer to enter the waiting state is product specific. If the printer is not waiting for manually fed media, it may switch from an empty subunit to a different subunit without waiting for the time-out to expire. A value of (-1) implies 'other' or 'infinite' which translates to 'wait forever'. The action which causes printing to continue is product specific. A value of (-2) implies 'unknown'." ::= { prtInputEntry 24 } Bergman, et al. Standards Track [Page 89] RFC 3805 Printer MIB v2 June 2004 prtInputNextIndex OBJECT-TYPE SYNTAX Integer32 (-3..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtInputIndex corresponding to the input subunit which will be used when this input subunit is emptied and the time-out specified by prtInputMediaLoadTimeout expires. A value of zero(0) indicates that auto input switching will not occur when this input subunit is emptied. If the time-out specified by prtInputLoadMediaTimeout expires and this value is zero(0), the job will be aborted. A value of (-1) means other. The value (-2)means 'unknown' and specifically indicates that an implementation specific method will determine the next input subunit to use at the time this subunit is emptied and the time out expires. The value(-3) means input switching is not supported for this subunit." ::= { prtInputEntry 25 } -- The Output Group -- -- Output sub-units are managed as a tabular, indexed collection -- of possible devices capable of receiving media delivered from -- the printing process. Output sub-units typically have a -- location, a type, an identifier, a set of constraints on -- possible media sizes and potentially other characteristics, -- and may be capable of indicating current status or capacity. prtOutput OBJECT IDENTIFIER ::= { printmib 9 } prtOutputTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtOutputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the devices capable of receiving media delivered from the printing process." ::= { prtOutput 2 } prtOutputEntry OBJECT-TYPE SYNTAX PrtOutputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of a device capable of receiving media delivered from the printing process. Entries may exist in the table for each device index with a device type of 'printer'. Bergman, et al. Standards Track [Page 90] RFC 3805 Printer MIB v2 June 2004 NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtOutputIndex } ::= { prtOutputTable 1 } PrtOutputEntry ::= SEQUENCE { prtOutputIndex Integer32, prtOutputType PrtOutputTypeTC, prtOutputCapacityUnit PrtCapacityUnitTC, prtOutputMaxCapacity Integer32, prtOutputRemainingCapacity Integer32, prtOutputStatus PrtSubUnitStatusTC, prtOutputName OCTET STRING, prtOutputVendorName OCTET STRING, prtOutputModel OCTET STRING, prtOutputVersion OCTET STRING, prtOutputSerialNumber OCTET STRING, prtOutputDescription PrtLocalizedDescriptionStringTC, prtOutputSecurity PresentOnOff, prtOutputDimUnit PrtMediaUnitTC, prtOutputMaxDimFeedDir Integer32, prtOutputMaxDimXFeedDir Integer32, prtOutputMinDimFeedDir Integer32, prtOutputMinDimXFeedDir Integer32, prtOutputStackingOrder PrtOutputStackingOrderTC, prtOutputPageDeliveryOrientation PrtOutputPageDeliveryOrientationTC, prtOutputBursting PresentOnOff, prtOutputDecollating PresentOnOff, prtOutputPageCollated PresentOnOff, prtOutputOffsetStacking PresentOnOff } prtOutputIndex OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by this printer to identify this output sub-unit. Although these values may change due to a major reconfiguration of the sub-unit (e.g., the addition of new output devices to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtOutputEntry 1 } Bergman, et al. Standards Track [Page 91] RFC 3805 Printer MIB v2 June 2004 prtOutputType OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly defined -- by this object. SYNTAX PrtOutputTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of technology supported by this output sub-unit." ::= { prtOutputEntry 2 } prtOutputCapacityUnit OBJECT-TYPE SYNTAX PrtCapacityUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measurement for use in calculating and relaying capacity values for this output sub-unit." ::= { prtOutputEntry 3 } prtOutputMaxCapacity OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum capacity of this output sub-unit in output sub- unit capacity units (PrtCapacityUnitTC). There is no convention associated with the media itself so this value essentially reflects claimed capacity. If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown." ::= { prtOutputEntry 4 } prtOutputRemainingCapacity OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-3..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The remaining capacity of the possible output sub-unit capacity in output sub-unit capacity units (PrtCapacityUnitTC)of this output sub-unit. If this output sub- unit can reliably sense this value, the value is sensed by the printer and may not be modified by management requests; Bergman, et al. Standards Track [Page 92] RFC 3805 Printer MIB v2 June 2004 otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. The value (-3) means that the printer knows that there remains capacity for at least one unit." ::= { prtOutputEntry 5 } prtOutputStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of this output sub-unit." ::= { prtOutputEntry 6 } -- OUTPUT MEASUREMENT -- -- _______ | | ________ -- ^ | | ^ -- | | | | -- | | |RemainingCapacity -- MaxCapacity| | | -- | | | v ^ -- | |_ _ _ _ _ _ _ _ | _______________ |direction -- | | Sheets | | -- | | in | -- v | Output | -- _______ +________________+ -- The Extended Output Group prtOutputName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name assigned to this output sub-unit." ::= { prtOutputEntry 7 } prtOutputVendorName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor name of this output sub-unit." ::= { prtOutputEntry 8 } Bergman, et al. Standards Track [Page 93] RFC 3805 Printer MIB v2 June 2004 prtOutputModel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The model name assigned to this output sub-unit. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtOutputEntry 9 } prtOutputVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of this output sub-unit." ::= { prtOutputEntry 10 } prtOutputSerialNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The serial number assigned to this output sub-unit." ::= { prtOutputEntry 11 } prtOutputDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "A free-form text description of this output sub-unit in the localization specified by prtGeneralCurrentLocalization." ::= { prtOutputEntry 12 } prtOutputSecurity OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if this output sub-unit has some security associated with it and if that security is enabled or not." ::= { prtOutputEntry 13 } Bergman, et al. Standards Track [Page 94] RFC 3805 Printer MIB v2 June 2004 -- The Output Dimensions Group prtOutputDimUnit OBJECT-TYPE SYNTAX PrtMediaUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measurement for use in calculating and relaying dimensional values for this output sub-unit." ::= { prtOutputEntry 14 } prtOutputMaxDimFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum dimensions supported by this output sub-unit for measurements taken parallel relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2)." ::= { prtOutputEntry 15 } prtOutputMaxDimXFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum dimensions supported by this output sub-unit for measurements taken ninety degrees relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. Bergman, et al. Standards Track [Page 95] RFC 3805 Printer MIB v2 June 2004 NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2)." ::= { prtOutputEntry 16 } prtOutputMinDimFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum dimensions supported by this output sub-unit for measurements taken parallel relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2)." ::= { prtOutputEntry 17 } prtOutputMinDimXFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum dimensions supported by this output sub-unit for measurements taken ninety degrees relative to the feed direction associated with that sub-unit in output sub-unit dimensional units (controlled by prtOutputDimUnit, which uses PrtMediaUnitTC). If this output sub-unit can reliably sense this value, the value is sensed by the printer and may not be changed with management protocol operations. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification and to explain the purpose of (-1) and (-2)." ::= { prtOutputEntry 18 } Bergman, et al. Standards Track [Page 96] RFC 3805 Printer MIB v2 June 2004 -- The Output Features Group prtOutputStackingOrder OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtOutputStackingOrderTC MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the stacking order for the associated output sub-unit. 'FirstToLast' means that as pages are output the front of the next page is placed against the back of the previous page. 'LasttoFirst' means that as pages are output the back of the next page is placed against the front of the previous page." ::= { prtOutputEntry 19 } prtOutputPageDeliveryOrientation OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtOutputPageDeliveryOrientationTC MAX-ACCESS read-write STATUS current DESCRIPTION "The reading surface that will be 'up' when pages are delivered to the associated output sub-unit. Values are faceUp and faceDown. (Note: interpretation of these values is in general context-dependent based on locale; presentation of these values to an end-user should be normalized to the expectations of the user)." ::= { prtOutputEntry 20 } prtOutputBursting OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates that the outputting sub-unit supports bursting, and if so, whether the feature is enabled. Bursting is the process by which continuous media is separated into individual sheets, typically by bursting along pre-formed perforations." ::= { prtOutputEntry 21 } prtOutputDecollating OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write Bergman, et al. Standards Track [Page 97] RFC 3805 Printer MIB v2 June 2004 STATUS current DESCRIPTION "This object indicates that the output supports decollating, and if so, whether the feature is enabled. Decollating is the process by which the individual parts within a multi-part form are separated and sorted into separate stacks for each part." ::= { prtOutputEntry 22 } prtOutputPageCollated OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates that the output sub-unit supports page collation, and if so, whether the feature is enabled. See RFC 3805 Appendix A, Glossary Of Terms, for definition of how this document defines collation. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtOutputEntry 23 } prtOutputOffsetStacking OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates that the output supports offset stacking,and if so, whether the feature is enabled. See RFC 3805 Appendix A, Glossary Of Terms, for how Offset Stacking is defined by this document. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtOutputEntry 24 } -- The Marker Group -- -- A marker is the mechanism that produces marks on the print -- media. The marker sub-units and their associated supplies are -- represented by the Marker Group in the model. A printer can -- contain one or more marking mechanisms. Some examples of -- multiple marker sub-units are: a printer -- with separate markers for normal and magnetic ink or an -- imagesetter that can output to both a proofing device and -- final film. Each marking device can have its own set of -- characteristics associated with it, such as marking technology -- and resolution. Bergman, et al. Standards Track [Page 98] RFC 3805 Printer MIB v2 June 2004 prtMarker OBJECT IDENTIFIER ::= { printmib 10 } -- The printable area margins as listed below define an area of -- the print media which is guaranteed to be printable for all -- combinations of input, media paths, and interpreters for this -- marker. prtMarkerTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtMarkerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The marker table provides a description of each marker sub-unit contained within the printer. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarker 2 } prtMarkerEntry OBJECT-TYPE SYNTAX PrtMarkerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table define the characteristics and status of each marker sub-unit in the printer. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtMarkerIndex } ::= { prtMarkerTable 1 } PrtMarkerEntry ::= SEQUENCE { prtMarkerIndex Integer32, prtMarkerMarkTech PrtMarkerMarkTechTC, prtMarkerCounterUnit PrtMarkerCounterUnitTC, prtMarkerLifeCount Counter32, prtMarkerPowerOnCount Counter32, prtMarkerProcessColorants Integer32, prtMarkerSpotColorants Integer32, prtMarkerAddressabilityUnit PrtMarkerAddressabilityUnitTC, prtMarkerAddressabilityFeedDir Integer32, prtMarkerAddressabilityXFeedDir Integer32, prtMarkerNorthMargin Integer32, prtMarkerSouthMargin Integer32, prtMarkerWestMargin Integer32, prtMarkerEastMargin Integer32, prtMarkerStatus PrtSubUnitStatusTC Bergman, et al. Standards Track [Page 99] RFC 3805 Printer MIB v2 June 2004 } prtMarkerIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this marking SubUnit. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new marking sub-units to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerEntry 1 } prtMarkerMarkTech OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMarkerMarkTechTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of marking technology used for this marking sub-unit." ::= { prtMarkerEntry 2 } prtMarkerCounterUnit OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMarkerCounterUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit that will be used by the printer when reporting counter values for this marking sub-unit. The time units of measure are provided for a device like a strip recorder that does not or cannot track the physical dimensions of the media and does not use characters, lines or sheets." ::= { prtMarkerEntry 3 } prtMarkerLifeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the number of units of measure counted during the Bergman, et al. Standards Track [Page 100] RFC 3805 Printer MIB v2 June 2004 life of printer using units of measure as specified by prtMarkerCounterUnit. Note: This object should be implemented as a persistent object with a reliable value throughout the lifetime of the printer." ::= { prtMarkerEntry 4 } prtMarkerPowerOnCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the number of units of measure counted since the equipment was most recently powered on using units of measure as specified by prtMarkerCounterUnit." ::= { prtMarkerEntry 5 } prtMarkerProcessColorants OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of process colors supported by this marker. A process color of 1 implies monochrome. The value of this object and prtMarkerSpotColorants cannot both be 0. The value of prtMarkerProcessColorants must be 0 or greater. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerEntry 6 } prtMarkerSpotColorants OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of spot colors supported by this marker. The value of this object and prtMarkerProcessColorants cannot both be 0. Must be 0 or greater. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerEntry 7 } prtMarkerAddressabilityUnit OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMarkerAddressabilityUnitTC Bergman, et al. Standards Track [Page 101] RFC 3805 Printer MIB v2 June 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measure of distances, as applied to the marker's resolution. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerEntry 8 } prtMarkerAddressabilityFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of addressable marking positions in the feed direction per 10000 units of measure specified by prtMarkerAddressabilityUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerEntry 9 } prtMarkerAddressabilityXFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of addressable marking positions in the cross feed direction in 10000 units of measure specified by prtMarkerAddressabilityUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerEntry 10 } prtMarkerNorthMargin OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The margin, in units identified by prtMarkerAddressabilityUnit, from the leading edge of the medium as the medium flows through Bergman, et al. Standards Track [Page 102] RFC 3805 Printer MIB v2 June 2004 the marking engine with the side to be imaged facing the observer. The leading edge is the North edge and the other edges are defined by the normal compass layout of directions with the compass facing the observer. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown." ::= { prtMarkerEntry 11 } prtMarkerSouthMargin OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The margin from the South edge (see prtMarkerNorthMargin) of the medium in units identified by prtMarkerAddressabilityUnit. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown." ::= { prtMarkerEntry 12 } prtMarkerWestMargin OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The margin from the West edge (see prtMarkerNorthMargin) of the medium in units identified by prtMarkerAddressabilityUnit. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown." ::= { prtMarkerEntry 13 } prtMarkerEastMargin OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The margin from the East edge (see prtMarkerNorthMargin) of the medium in units identified by prtMarkerAddressabilityUnit. Printing within the area bounded by all four margins is guaranteed for all interpreters. The value (-2) means unknown." ::= { prtMarkerEntry 14 } prtMarkerStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current Bergman, et al. Standards Track [Page 103] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "The current status of this marker sub-unit." ::= { prtMarkerEntry 15 } -- The Marker Supplies Group prtMarkerSupplies OBJECT IDENTIFIER ::= { printmib 11 } prtMarkerSuppliesTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtMarkerSuppliesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the marker supplies available on this printer." ::= { prtMarkerSupplies 1 } prtMarkerSuppliesEntry OBJECT-TYPE SYNTAX PrtMarkerSuppliesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of a marker supply. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtMarkerSuppliesIndex } ::= { prtMarkerSuppliesTable 1 } PrtMarkerSuppliesEntry ::= SEQUENCE { prtMarkerSuppliesIndex Integer32, prtMarkerSuppliesMarkerIndex Integer32, prtMarkerSuppliesColorantIndex Integer32, prtMarkerSuppliesClass PrtMarkerSuppliesClassTC, prtMarkerSuppliesType PrtMarkerSuppliesTypeTC, prtMarkerSuppliesDescription PrtLocalizedDescriptionStringTC, prtMarkerSuppliesSupplyUnit PrtMarkerSuppliesSupplyUnitTC, prtMarkerSuppliesMaxCapacity Integer32, prtMarkerSuppliesLevel Integer32 } prtMarkerSuppliesIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this marker supply. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new marker Bergman, et al. Standards Track [Page 104] RFC 3805 Printer MIB v2 June 2004 supplies to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerSuppliesEntry 1 } prtMarkerSuppliesMarkerIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of prtMarkerIndex corresponding to the marking sub unit with which this marker supply sub-unit is associated." ::= { prtMarkerSuppliesEntry 2 } prtMarkerSuppliesColorantIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of prtMarkerColorantIndex corresponding to the colorant with which this marker supply sub-unit is associated. This value shall be 0 if there is no colorant table or if this supply does not depend on a single specified colorant. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerSuppliesEntry 3 } prtMarkerSuppliesClass OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMarkerSuppliesClassTC MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this supply entity represents a supply that is consumed or a receptacle that is filled. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerSuppliesEntry 4 } prtMarkerSuppliesType OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMarkerSuppliesTypeTC MAX-ACCESS read-only Bergman, et al. Standards Track [Page 105] RFC 3805 Printer MIB v2 June 2004 STATUS current DESCRIPTION "The type of this supply." ::= { prtMarkerSuppliesEntry 5 } prtMarkerSuppliesDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "The description of this supply container/receptacle in the localization specified by prtGeneralCurrentLocalization." ::= { prtMarkerSuppliesEntry 6 } prtMarkerSuppliesSupplyUnit OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMarkerSuppliesSupplyUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "Unit of measure of this marker supply container/receptacle. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerSuppliesEntry 7 } prtMarkerSuppliesMaxCapacity OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum capacity of this supply container/receptacle expressed in prtMarkerSuppliesSupplyUnit. If this supply container/receptacle can reliably sense this value, the value is reported by the printer and is read-only; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown." ::= { prtMarkerSuppliesEntry 8 } prtMarkerSuppliesLevel OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-3..2147483647) Bergman, et al. Standards Track [Page 106] RFC 3805 Printer MIB v2 June 2004 MAX-ACCESS read-write STATUS current DESCRIPTION "The current level if this supply is a container; the remaining space if this supply is a receptacle. If this supply container/receptacle can reliably sense this value, the value is reported by the printer and is read-only; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. A value of (-3) means that the printer knows that there is some supply/remaining space, respectively." ::= { prtMarkerSuppliesEntry 9 } -- The Marker Colorant Group prtMarkerColorant OBJECT IDENTIFIER ::= { printmib 12 } prtMarkerColorantTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtMarkerColorantEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of all of the colorants available on the printer." ::= { prtMarkerColorant 1 } prtMarkerColorantEntry OBJECT-TYPE SYNTAX PrtMarkerColorantEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of a colorant available on the printer. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtMarkerColorantIndex } ::= { prtMarkerColorantTable 1 } PrtMarkerColorantEntry ::= SEQUENCE { prtMarkerColorantIndex Integer32, prtMarkerColorantMarkerIndex Integer32, prtMarkerColorantRole PrtMarkerColorantRoleTC, prtMarkerColorantValue OCTET STRING, prtMarkerColorantTonality Integer32 } Bergman, et al. Standards Track [Page 107] RFC 3805 Printer MIB v2 June 2004 prtMarkerColorantIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this colorant. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new colorants to the printer) , values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMarkerColorantEntry 1 } prtMarkerColorantMarkerIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of prtMarkerIndex corresponding to the marker sub unit with which this colorant entry is associated." ::= { prtMarkerColorantEntry 2 } prtMarkerColorantRole OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMarkerColorantRoleTC MAX-ACCESS read-only STATUS current DESCRIPTION "The role played by this colorant." ::= { prtMarkerColorantEntry 3 } prtMarkerColorantValue OBJECT-TYPE -- NOTE: The string length range has been increased from RFC 1759. SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the color of this colorant using standardized string names from ISO 10175 (DPA) and ISO 10180 (SPDL) such as: other unknown white red green blue Bergman, et al. Standards Track [Page 108] RFC 3805 Printer MIB v2 June 2004 cyan magenta yellow black Implementers may add additional string values. The naming conventions in ISO 9070 are recommended in order to avoid potential name clashes" ::= { prtMarkerColorantEntry 4 } prtMarkerColorantTonality OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The distinct levels of tonality realizable by a marking sub unit when using this colorant. This value does not include the number of levels of tonal difference that an interpreter can obtain by techniques such as half toning. This value must be at least 2." ::= { prtMarkerColorantEntry 5 } -- The Media Path Group -- -- The media paths encompass the mechanisms in the printer that -- move the media through the printer and connect all other media -- related sub-units: inputs, outputs, markers and finishers. A -- printer contains one or more media paths. These are -- represented by the Media Path Group in the model. prtMediaPath OBJECT IDENTIFIER ::= { printmib 13 } prtMediaPathTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtMediaPathEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The media path table includes both physical and logical paths within the printer. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMediaPath 4 } prtMediaPathEntry OBJECT-TYPE SYNTAX PrtMediaPathEntry MAX-ACCESS not-accessible STATUS current Bergman, et al. Standards Track [Page 109] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "Entries may exist in the table for each device index with a device type of 'printer' Each entry defines the physical characteristics of and the status of the media path. The data provided indicates the maximum throughput and the media size limitations of these subunits. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtMediaPathIndex } ::= { prtMediaPathTable 1 } PrtMediaPathEntry ::= SEQUENCE { prtMediaPathIndex Integer32, prtMediaPathMaxSpeedPrintUnit PrtMediaPathMaxSpeedPrintUnitTC, prtMediaPathMediaSizeUnit PrtMediaUnitTC, prtMediaPathMaxSpeed Integer32, prtMediaPathMaxMediaFeedDir Integer32, prtMediaPathMaxMediaXFeedDir Integer32, prtMediaPathMinMediaFeedDir Integer32, prtMediaPathMinMediaXFeedDir Integer32, prtMediaPathType PrtMediaPathTypeTC, prtMediaPathDescription PrtLocalizedDescriptionStringTC, prtMediaPathStatus PrtSubUnitStatusTC } prtMediaPathIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this media path. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new media paths to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMediaPathEntry 1 } prtMediaPathMaxSpeedPrintUnit OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMediaPathMaxSpeedPrintUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION Bergman, et al. Standards Track [Page 110] RFC 3805 Printer MIB v2 June 2004 "The unit of measure used in specifying the speed of all media paths in the printer." ::= { prtMediaPathEntry 2 } prtMediaPathMediaSizeUnit OBJECT-TYPE SYNTAX PrtMediaUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The units of measure of media size for use in calculating and relaying dimensional values for all media paths in the printer." ::= { prtMediaPathEntry 3 } prtMediaPathMaxSpeed OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum printing speed of this media path expressed in prtMediaPathMaxSpeedUnit's. A value of (-1) implies 'other'." ::= { prtMediaPathEntry 4 } prtMediaPathMaxMediaFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum physical media size in the feed direction of this media path expressed in units of measure specified by PrtMediaPathMediaSizeUnit. A value of (-1) implies 'unlimited' a value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMediaPathEntry 5 } prtMediaPathMaxMediaXFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum physical media size across the feed direction of this media path expressed in units of measure specified by prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'. Bergman, et al. Standards Track [Page 111] RFC 3805 Printer MIB v2 June 2004 NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMediaPathEntry 6 } prtMediaPathMinMediaFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum physical media size in the feed direction of this media path expressed in units of measure specified by prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMediaPathEntry 7 } prtMediaPathMinMediaXFeedDir OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum physical media size across the feed direction of this media path expressed in units of measure specified by prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtMediaPathEntry 8 } prtMediaPathType OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtMediaPathTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the media path for this media path." ::= { prtMediaPathEntry 9 } prtMediaPathDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current Bergman, et al. Standards Track [Page 112] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "The manufacturer-provided description of this media path in the localization specified by prtGeneralCurrentLocalization." ::= { prtMediaPathEntry 10 } prtMediaPathStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of this media path." ::= { prtMediaPathEntry 11 } -- The Print Job Delivery Channel Group -- -- Print Job Delivery Channels are independent sources of print -- data. Here, print data is the term used for the information -- that is used to construct printed pages and may have both data -- and control aspects. The output of a channel is in a form -- suitable for input to one of the interpreters as a -- stream. A channel may be independently enabled (allowing -- print data to flow) or disabled (stopping the flow of -- print data). A printer may have one or more channels. -- -- The Print Job Delivery Channel table describes the -- capabilities of the printer and not what is currently being -- performed by the printer -- -- Basically, the print job delivery channel abstraction -- describes the final processing step of getting the print data -- to an interpreter. It might include some level of -- decompression or decoding of print stream data. -- channel. All of these aspects are hidden in the channel -- abstraction. -- -- There are many kinds of print job delivery channels; some of -- which are based on networks and others which are not. For -- example, a channel can be a serial (or parallel) connection; -- it can be a service, such as the UNIX Line Printer Daemon -- (LPD), offering services over a network connection; or -- it could be a disk drive into which a floppy disk with -- the print data is inserted. Each print job delivery channel is -- identified by the electronic path and/or service protocol -- used to deliver print data to a print data interpreter. -- -- Channel example Implementation -- -- serial port channel bi-directional data channel Bergman, et al. Standards Track [Page 113] RFC 3805 Printer MIB v2 June 2004 -- parallel port channel often uni-directional channel -- IEEE 1284 port channel bi-directional channel -- SCSI port channel bi-directional -- Apple PAP channel may be based on LocalTalk, -- Ethernet or Tokentalk -- LPD Server channel TCP/IP based, port 515 -- Netware Remote Printer SPX/IPX based channel -- Netware Print Server SPX/IPX based channel -- -- It is easy to note that this is a mixed bag. There are -- some physical connections over which no (or very meager) -- protocols are run (e.g., the serial or old parallel ports) -- and there are services which often have elaborate -- protocols that run over a number of protocol stacks. In -- the end, what is important is the delivery of print data -- through the channel. -- -- The print job delivery channel sub-units are represented by -- the Print Job Delivery Channel Group in the Model. It has a -- current print job control language, which can be used to -- specify which interpreter is to be used for the print data and -- to query and change environment variables used by the -- interpreters (and Management Applications). There is also a -- default interpreter that is to be used if an interpreter is -- not explicitly specified using the Control Language. -- The first seven items in the Print Job Delivery Channel Table -- define the "channel" itself. A channel typically depends on -- other protocols and interfaces to provide the data that flows -- through the channel. -- -- Control of a print job delivery channel is largely limited to -- enabling or disabling the entire channel itself. It is likely -- that more control of the process of accessing print data -- will be needed over time. Thus, the ChannelType will -- allow type-specific data to be associated with each -- channel (using ChannelType specific groups in a fashion -- analogous to the media specific MIBs that are associated -- with the IANAIfType in the Interfaces Table). As a first -- step in this direction, each channel will identify the -- underlying Interface on which it is based. This is the -- eighth object in each row of the table. Bergman, et al. Standards Track [Page 114] RFC 3805 Printer MIB v2 June 2004 -- The Print Job Delivery Channel Table prtChannel OBJECT IDENTIFIER ::= { printmib 14 } prtChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The channel table represents the set of input data sources which can provide print data to one or more of the interpreters available on a printer. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtChannel 1 } prtChannelEntry OBJECT-TYPE SYNTAX PrtChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each device index with a device type of 'printer'. Each channel table entry is characterized by a unique protocol stack and/or addressing. The channel may also have printer dependent features that are associated with a printing language. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtChannelIndex } ::= { prtChannelTable 1 } PrtChannelEntry ::= SEQUENCE { prtChannelIndex Integer32, prtChannelType PrtChannelTypeTC, prtChannelProtocolVersion OCTET STRING, prtChannelCurrentJobCntlLangIndex Integer32, prtChannelDefaultPageDescLangIndex Integer32, prtChannelState PrtChannelStateTC, prtChannelIfIndex InterfaceIndexOrZero, prtChannelStatus PrtSubUnitStatusTC, prtChannelInformation OCTET STRING } prtChannelIndex OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (1..65535) Bergman, et al. Standards Track [Page 115] RFC 3805 Printer MIB v2 June 2004 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this data channel. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new data channels to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtChannelEntry 1 } prtChannelType OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtChannelTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this print data channel. This object provides the linkage to ChannelType-specific groups that may (conceptually) extend the prtChannelTable with additional details about that channel." ::= { prtChannelEntry 2 } prtChannelProtocolVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the protocol used on this channel. The format used for version numbering depends on prtChannelType." ::= { prtChannelEntry 3 } prtChannelCurrentJobCntlLangIndex OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtInterpreterIndex corresponding to the Control Language Interpreter for this channel. This interpreter defines the syntax used for control functions, such as querying or changing environment variables and identifying job boundaries (e.g., PJL, PostScript, NPAP). A value of zero indicates that there is no current Job Control Language Interpreter for this channel. Bergman, et al. Standards Track [Page 116] RFC 3805 Printer MIB v2 June 2004 NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtChannelEntry 4 } prtChannelDefaultPageDescLangIndex OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of prtInterpreterIndex corresponding to the Page Description Language Interpreter for this channel. This interpreter defines the default Page Description Language interpreter to be used for the print data unless the Control Language is used to select a specific interpreter (e.g., PCL, PostScript Language, auto-sense). A value of zero indicates that there is no default page description language interpreter for this channel. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtChannelEntry 5 } prtChannelState OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtChannelStateTC MAX-ACCESS read-write STATUS current DESCRIPTION "The state of this print data channel. The value determines whether control information and print data is allowed through this channel or not." ::= { prtChannelEntry 6 } prtChannelIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero -- Was Integer32 in RFC 1759. MAX-ACCESS read-write STATUS current DESCRIPTION "The value of ifIndex in the ifTable; see the Interfaces Group MIB [RFC2863] which corresponds to this channel. When more than one row of the ifTable is relevant, this is the index of the row representing the topmost layer in the interface hierarchy. A value of zero indicates that no interface is associated with this channel. NOTE: The above description has been modified from RFC 1759 Bergman, et al. Standards Track [Page 117] RFC 3805 Printer MIB v2 June 2004 for clarification." ::= { prtChannelEntry 7 } prtChannelStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of the channel." ::= { prtChannelEntry 8 } prtChannelInformation OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Auxiliary information to allow a printing application to use the channel for data submission to the printer. An application capable of using a specific PrtChannelType should be able to use the combined information from the prtChannelInformation and other channel and interface group objects to 'bootstrap' its use of the channel. prtChannelInformation is not intended to provide a general channel description, nor to provide information that is available once the channel is in use. The encoding and interpretation of the prtChannelInformation object is specific to channel type. The description of each PrtChannelType enum value for which prtChannelInformation is defined specifies the appropriate encoding and interpretation, including interaction with other objects. For channel types that do not specify a prtChannelInformation value, its value shall be null (0 length). When a new PrtChannelType enumeration value is registered, its accompanying description must specify the encoding and interpretation of the prtChannelInformation value for the channel type. prtChannelInformation semantics for an existing PrtChannelType may be added or amended in the same manner as described in section 2.4.1 for type 2 enumeration values. The prtChannelInformation specifies values for a collection of channel attributes, represented as text according to the following rules: 1. The prtChannelInformation is not affected by localization. 2. The prtChannelInformation is a list of entries representing the attribute values. Each entry consists of the following Bergman, et al. Standards Track [Page 118] RFC 3805 Printer MIB v2 June 2004 items, in order: a. A keyword, composed of alphabetic characters (A-Z, a-z) represented by their NVT ASCII [RFC854] codes, that identifies a channel attribute, b. The NVT ASCII code for an Equals Sign (=) (code 61) to delimit the keyword, c. A data value encoded using rules specific to the PrtChannelType to with the prtChannelInformation applies which must in no case allow an octet with value 10 (the NVT ASCII Line Feed code), d. the NVT ASCII code for a Line Feed character (code 10) to delimit the data value. No other octets shall be present. Keywords are case-sensitive. Conventionally, keywords are capitalized (including each word of a multi-word keyword) and since they occupy space in the prtChannelInformation, they are kept short. 3. If a channel attribute has multiple values, it is represented by multiple entries with the same keyword, each specifying one value. Otherwise, there shall be at most one entry for each attribute. 4. By default, entries may appear in any order. If there are ordering constraints for particular entries, these must be specified in their definitions. 5. The prtChannelInformation value by default consists of text represented by NVT ASCII graphics character codes. However, other representations may be specified: a. In cases where the prtChannelInformation value contains information not normally coded in textual form, whatever symbolic representation is conventionally used for the information should be used for encoding the prtChannelInformation value. (For instance, a binary port value might be represented as a decimal number using NVT ASCII codes.) Such encoding must be specified in the definition of the value. b. The value may contain textual information in a character set other than NVT ASCII graphics characters. (For instance, an Bergman, et al. Standards Track [Page 119] RFC 3805 Printer MIB v2 June 2004 identifier might consist of ISO 10646 text encoded using the UTF-8 encoding scheme.) Such a character set and its encoding must be specified in the definition of the value. 6. For each PrtChannelType for which prtChannelInformation entries are defined, the descriptive text associated with the PrtChannelType enumeration value shall specify the following information for each entry: Title: Brief description phrase, e.g.: 'Port name', 'Service Name', etc. Keyword: The keyword value, e.g.: 'Port' or 'Service' Syntax: The encoding of the entry value if it cannot be directly represented by NVT ASCII. Status: 'Mandatory', 'Optional', or 'Conditionally Mandatory' Multiplicity: 'Single' or 'Multiple' to indicate whether the entry may be present multiple times. Description: Description of the use of the entry, other information required to complete the definition (e.g.: ordering constraints, interactions between entries). Applications that interpret prtChannelInformation should ignore unrecognized entries, so they are not affected if new entry types are added." ::= { prtChannelEntry 9 } -- The Interpreter Group -- -- The interpreter sub-units are responsible for the conversion -- of a description of intended print instances into images that -- are to be marked on the media. A printer may have one or more -- interpreters. The interpreter sub-units are represented by the -- Interpreter Group in the Model. Each interpreter is generally -- implemented with software running on the System Controller -- sub-unit. The Interpreter Table has one entry per interpreter -- where the interpreters include both Page Description Language -- (PDL) Interpreters and Control Language Interpreters. prtInterpreter OBJECT IDENTIFIER ::= { printmib 15 } Bergman, et al. Standards Track [Page 120] RFC 3805 Printer MIB v2 June 2004 -- Interpreter Table prtInterpreterTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtInterpreterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interpreter table is a table representing the interpreters in the printer. An entry shall be placed in the interpreter table for each interpreter on the printer. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtInterpreter 1 } prtInterpreterEntry OBJECT-TYPE SYNTAX PrtInterpreterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each device index with a device type of 'printer'. Each table entry provides a complete description of the interpreter, including version information, rendering resolutions, default character sets, output orientation, and communication capabilities. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtInterpreterIndex } ::= { prtInterpreterTable 1 } PrtInterpreterEntry ::= SEQUENCE { prtInterpreterIndex Integer32, prtInterpreterLangFamily PrtInterpreterLangFamilyTC, prtInterpreterLangLevel OCTET STRING, prtInterpreterLangVersion OCTET STRING, prtInterpreterDescription PrtLocalizedDescriptionStringTC, prtInterpreterVersion OCTET STRING, prtInterpreterDefaultOrientation PrtPrintOrientationTC, prtInterpreterFeedAddressability Integer32, prtInterpreterXFeedAddressability Integer32, prtInterpreterDefaultCharSetIn IANACharset, prtInterpreterDefaultCharSetOut IANACharset, prtInterpreterTwoWay PrtInterpreterTwoWayTC } prtInterpreterIndex OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. Bergman, et al. Standards Track [Page 121] RFC 3805 Printer MIB v2 June 2004 SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for each PDL or control language for which there exists an interpreter or emulator in the printer. The value is used to identify this interpreter. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new interpreters to the printer), values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtInterpreterEntry 1 } prtInterpreterLangFamily OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Page Description Language (PDL) or control language which this interpreter in the printer can interpret or emulate. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtInterpreterEntry 2 } prtInterpreterLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the language which this interpreter is interpreting or emulating. This might contain a value like '5e'for an interpreter which is emulating level 5e of the PCL language. It might contain '2' for an interpreter which is emulating level 2 of the PostScript language. Similarly it might contain '2' for an interpreter which is emulating level 2 of the HPGL language." ::= { prtInterpreterEntry 3 } prtInterpreterLangVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current Bergman, et al. Standards Track [Page 122] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "The date code or version of the language which this interpreter is interpreting or emulating." ::= { prtInterpreterEntry 4 } prtInterpreterDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "A string to identify this interpreter in the localization specified by prtGeneralCurrentLocalization as opposed to the language which is being interpreted. It is anticipated that this string will allow manufacturers to unambiguously identify their interpreters." ::= { prtInterpreterEntry 5 } prtInterpreterVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The date code, version number, or other product specific information tied to this interpreter. This value is associated with the interpreter, rather than with the version of the language which is being interpreted or emulated." ::= { prtInterpreterEntry 6 } prtInterpreterDefaultOrientation OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtPrintOrientationTC MAX-ACCESS read-write STATUS current DESCRIPTION "The current orientation default for this interpreter. This value may be overridden for a particular job (e.g., by a command in the input data stream)." ::= { prtInterpreterEntry 7 } prtInterpreterFeedAddressability OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION Bergman, et al. Standards Track [Page 123] RFC 3805 Printer MIB v2 June 2004 "The maximum interpreter addressability in the feed direction in 10000 prtMarkerAddressabilityUnits (as specified by prtMarkerDefaultIndex) for this interpreter. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtInterpreterEntry 8 } prtInterpreterXFeedAddressability OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum interpreter addressability in the cross feed direction in 10000 prtMarkerAddressabilityUnits (as specified by prtMarkerDefaultIndex) for this interpreter. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtInterpreterEntry 9 } prtInterpreterDefaultCharSetIn OBJECT-TYPE SYNTAX IANACharset MAX-ACCESS read-write STATUS current DESCRIPTION "The default coded character set for input octets encountered outside a context in which the Page Description Language established the interpretation of the octets. (Input octets are presented to the interpreter through a path defined in the channel group.)" ::= { prtInterpreterEntry 10 } prtInterpreterDefaultCharSetOut OBJECT-TYPE SYNTAX IANACharset MAX-ACCESS read-write STATUS current DESCRIPTION "The default character set for data coming from this interpreter through the printer's output channel (i.e. the 'backchannel')." Bergman, et al. Standards Track [Page 124] RFC 3805 Printer MIB v2 June 2004 ::= { prtInterpreterEntry 11 } prtInterpreterTwoWay OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtInterpreterTwoWayTC MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether or not this interpreter returns information back to the host." ::= { prtInterpreterEntry 12 } -- The Console Group -- -- Many printers have a console on the printer, the operator -- console, that is used to display and modify the state of the -- printer. The console can be as simple as a few indicators and -- switches or as complicated as full screen displays and -- keyboards. There can be at most one such console. -- The Display Buffer Table prtConsoleDisplayBuffer OBJECT IDENTIFIER ::= { printmib 16 } prtConsoleDisplayBufferTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtConsoleDisplayBufferEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Physical display buffer for printer console display or operator panel NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtConsoleDisplayBuffer 5 } prtConsoleDisplayBufferEntry OBJECT-TYPE SYNTAX PrtConsoleDisplayBufferEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one entry for each physical line on the display. Lines cannot be added or deleted. Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 Bergman, et al. Standards Track [Page 125] RFC 3805 Printer MIB v2 June 2004 for clarification." INDEX { hrDeviceIndex, prtConsoleDisplayBufferIndex } ::= { prtConsoleDisplayBufferTable 1 } PrtConsoleDisplayBufferEntry ::= SEQUENCE { prtConsoleDisplayBufferIndex Integer32, prtConsoleDisplayBufferText PrtConsoleDescriptionStringTC } prtConsoleDisplayBufferIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for each console line in the printer. The value is used to identify this console line. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new console lines to the printer). Values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtConsoleDisplayBufferEntry 1 } prtConsoleDisplayBufferText OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtConsoleDescriptionStringTC MAX-ACCESS read-write STATUS current DESCRIPTION "The content of a line in the logical display buffer of the operator's console of the printer. When a write operation occurs, normally a critical message, to one of the LineText strings, the agent should make that line displayable if a physical display is present. Writing a zero length string clears the line. It is an implementation- specific matter as to whether the agent allows a line to be overwritten before it has been cleared. Printer generated strings shall be in the localization specified by prtConsoleLocalization.Management Application generated strings should be localized by the Management Application." ::= { prtConsoleDisplayBufferEntry 2 } -- The Console Light Table prtConsoleLights OBJECT IDENTIFIER ::= { printmib 17 } Bergman, et al. Standards Track [Page 126] RFC 3805 Printer MIB v2 June 2004 prtConsoleLightTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtConsoleLightEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The console light table provides a description and state information for each light present on the printer console. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtConsoleLights 6 } prtConsoleLightEntry OBJECT-TYPE SYNTAX PrtConsoleLightEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtConsoleLightIndex } ::= { prtConsoleLightTable 1 } PrtConsoleLightEntry ::= SEQUENCE { prtConsoleLightIndex Integer32, prtConsoleOnTime Integer32, prtConsoleOffTime Integer32, prtConsoleColor PrtConsoleColorTC, prtConsoleDescription PrtConsoleDescriptionStringTC } prtConsoleLightIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) -- Lower limit invalid in RFC 1759 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the printer to identify this light. Although these values may change due to a major reconfiguration of the device (e.g., the addition of new lights to the printer). Values SHOULD remain stable across successive printer power cycles. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtConsoleLightEntry 1 } Bergman, et al. Standards Track [Page 127] RFC 3805 Printer MIB v2 June 2004 prtConsoleOnTime OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object, in conjunction with prtConsoleOffTime, defines the current status of the light. If both prtConsoleOnTime and prtConsoleOffTime are non-zero, the lamp is blinking and the values presented define the on time and off time, respectively, in milliseconds. If prtConsoleOnTime is zero and prtConsoleOffTime is non-zero, the lamp is off. If prtConsoleOffTime is zero and prtConsoleOnTime is non-zero, the lamp is on. If both values are zero the lamp is off. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtConsoleLightEntry 2 } prtConsoleOffTime OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object, in conjunction with prtConsoleOnTime, defines the current status of the light. If both prtConsoleOnTime and prtConsoleOffTime are non-zero, the lamp is blinking and the values presented define the on time and off time, respectively, in milliseconds. If prtConsoleOnTime is zero and prtConsoleOffTime is non-zero, the lamp is off. If prtConsoleOffTime is zero and prtConsoleOnTime is non-zero, the lamp is on. If both values are zero the lamp is off. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtConsoleLightEntry 3 } prtConsoleColor OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtConsoleColorTC MAX-ACCESS read-only STATUS current DESCRIPTION "The color of this light." ::= { prtConsoleLightEntry 4 } Bergman, et al. Standards Track [Page 128] RFC 3805 Printer MIB v2 June 2004 prtConsoleDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtConsoleDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor description or label of this light in the localization specified by prtConsoleLocalization." ::= { prtConsoleLightEntry 5 } -- The Alerts Group -- -- The table contains information on the severity, component, -- detail location within the component, alert code and -- description of each critical alert that is currently active -- within the printer. See 2.2.13 for a more complete -- description of the alerts table and its management. -- -- Each parameter in the Trap PDU is a full OID which itself is -- indexed by the host resources MIB "hrDeviceIndex" object. In -- order for a management station to obtain the correct -- "hrDeviceIndex" associated with a particular Trap PDU, the -- "hrDeviceIndex" value can be extracted from the returned OID -- value in the Trap PDU when the PDU is received by the -- Management station. prtAlert OBJECT IDENTIFIER ::= { printmib 18 } prtAlertTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtAlertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The prtAlertTable lists all the critical and non-critical alerts currently active in the printer. A critical alert is one that stops the printer from printing immediately and printing can not continue until the critical alert condition is eliminated. Non-critical alerts are those items that do not stop printing but may at some future time. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtAlert 1 } prtAlertEntry OBJECT-TYPE SYNTAX PrtAlertEntry MAX-ACCESS not-accessible Bergman, et al. Standards Track [Page 129] RFC 3805 Printer MIB v2 June 2004 STATUS current DESCRIPTION "Entries may exist in the table for each device index with a device type of 'printer'. NOTE: The above description has been modified from RFC 1759 for clarification." INDEX { hrDeviceIndex, prtAlertIndex } ::= { prtAlertTable 1 } PrtAlertEntry ::= SEQUENCE { prtAlertIndex Integer32, prtAlertSeverityLevel PrtAlertSeverityLevelTC, prtAlertTrainingLevel PrtAlertTrainingLevelTC, prtAlertGroup PrtAlertGroupTC, prtAlertGroupIndex Integer32, prtAlertLocation Integer32, prtAlertCode PrtAlertCodeTC, prtAlertDescription PrtLocalizedDescriptionStringTC, prtAlertTime TimeTicks } prtAlertIndex OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. The MAX-ACCESS has -- been changed from not accessible to allow the object to be -- included (as originally in RFC 1759) in the trap bindings. SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index value used to determine which alerts have been added or removed from the alert table. This is an incrementing integer initialized to 1 when the printer is reset. (i.e., The first event placed in the alert table after a reset of the printer shall have an index value of 1.) When the printer adds an alert to the table, that alert is assigned the next higher integer value from the last item entered into the table. If the index value reaches its maximum value, the next index value used must be 1. NOTE: The management application will read the alert table when a trap or event notification occurs or at a periodic rate and then parse the table to determine if any new entries were added by comparing the last known index value with the current highest index value. The management application will then update its copy of the alert table. When the printer discovers that an alert is no longer active, the printer shall remove the Bergman, et al. Standards Track [Page 130] RFC 3805 Printer MIB v2 June 2004 row for that alert from the table and shall reduce the number of rows in the table. The printer may add or delete any number of rows from the table at any time. The management station can detect when binary change alerts have been deleted by requesting an attribute of each alert, and noting alerts as deleted when that retrieval is not possible. The objects 'prtAlertCriticalEvents'and 'prtAlertAllEvents' in the 'prtGeneralTable' reduce the need for management applications to scan the 'prtAlertTable'. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtAlertEntry 1 } prtAlertSeverityLevel OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtAlertSeverityLevelTC MAX-ACCESS read-only STATUS current DESCRIPTION "The level of severity of this alert table entry. The printer determines the severity level assigned to each entry into the table." ::= { prtAlertEntry 2 } prtAlertTrainingLevel OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtAlertTrainingLevelTC MAX-ACCESS read-only STATUS current DESCRIPTION "See TEXTUAL-CONVENTION PrtAlertTrainingLevelTC. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtAlertEntry 3 } prtAlertGroup OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtAlertGroupTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of sub-unit within the printer model that this alert is related. Input, output, and markers are examples of printer Bergman, et al. Standards Track [Page 131] RFC 3805 Printer MIB v2 June 2004 model groups, i.e., examples of types of sub-units. Wherever possible, these enumerations match the sub-identifier that identifies the relevant table in the printmib." ::= { prtAlertEntry 4 } prtAlertGroupIndex OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The low-order index of the row within the table identified by prtAlertGroup that represents the sub-unit of the printer that caused this alert, or -1 if not applicable. The combination of the prtAlertGroup and the prtAlertGroupIndex defines exactly which printer sub-unit caused the alert; for example, Input #3, Output#2, and Marker #1. Every object in this MIB is indexed with hrDeviceIndex and optionally, another index variable. If this other index variable is present in the table that generated the alert, it will be used as the value for this object. Otherwise, this value shall be -1. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtAlertEntry 5 } prtAlertLocation OBJECT-TYPE -- NOTE: In RFC 1759, the range was not defined. SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The sub-unit location that is defined by the printer manufacturer to further refine the location of this alert within the designated sub-unit. The location is used in conjunction with the Group and GroupIndex values; for example, there is an alert in Input #2 at location number 7. The value (-2) indicates unknown. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtAlertEntry 6 } prtAlertCode OBJECT-TYPE -- NOTE: In RFC 1759, the enumeration values were implicitly -- defined by this object. SYNTAX PrtAlertCodeTC MAX-ACCESS read-only Bergman, et al. Standards Track [Page 132] RFC 3805 Printer MIB v2 June 2004 STATUS current DESCRIPTION "See associated TEXTUAL-CONVENTION PrtAlertCodeTC. NOTE: The above description has been modified from RFC 1759 for clarification." ::= { prtAlertEntry 7 } prtAlertDescription OBJECT-TYPE -- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed -- to a TC to better support localization of the object. SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "A description of this alert entry in the localization specified by prtGeneralCurrentLocalization. The description is provided by the printer to further elaborate on the enumerated alert or provide information in the case where the code is classified as 'other' or 'unknown'. The printer is required to return a description string but the string may be a null string." ::= { prtAlertEntry 8 } prtAlertTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time that this alert was generated." ::= { prtAlertEntry 9 } printerV1Alert OBJECT-IDENTITY STATUS current DESCRIPTION "The value of the enterprise-specific OID in an SNMPv1 trap sent signaling a critical event in the prtAlertTable." ::= { prtAlert 2 } printerV2AlertPrefix OBJECT IDENTIFIER ::= { printerV1Alert 0 } printerV2Alert NOTIFICATION-TYPE OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup, prtAlertGroupIndex, prtAlertLocation, prtAlertCode } STATUS current DESCRIPTION "This trap is sent whenever a critical event is added to the Bergman, et al. Standards Track [Page 133] RFC 3805 Printer MIB v2 June 2004 prtAlertTable. NOTE: The prtAlertIndex object was redundantly included in the bindings of the 'printerV2Alert' notification in RFC 1759, even though the value exists in the instance qualifier of all the other bindings. This object has been retained to provide compatiblity with existing RFC 1759 implementaions." ::= { printerV2AlertPrefix 1 } -- Note that the SNMPv2 to SNMPv1 translation rules dictate that -- the preceding structure will result in SNMPv1 traps of the -- following form: -- -- printerAlert TRAP-TYPE -- ENTERPRISE printerV1Alert -- VARIABLES { prtAlertIndex, prtAlertSeverityLevel, -- prtAlertGroup, prtAlertGroupIndex, -- prtAlertLocation, prtAlertCode } -- DESCRIPTION -- "This trap is sent whenever a critical event is added -- to the prtAlertTable." -- ::= 1 -- Conformance Information prtMIBConformance OBJECT IDENTIFIER ::= { printmib 2 } -- compliance statements prtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the printer MIB as defined by RFC 1759." MODULE -- this module MANDATORY-GROUPS { prtGeneralGroup, prtInputGroup, prtOutputGroup, prtMarkerGroup, prtMediaPathGroup, prtChannelGroup, prtInterpreterGroup, prtConsoleGroup, prtAlertTableGroup } OBJECT prtGeneralReset SYNTAX INTEGER { notResetting(3), resetToNVRAM(5) } DESCRIPTION "It is conformant to implement just these two states in this Bergman, et al. Standards Track [Page 134] RFC 3805 Printer MIB v2 June 2004 object. Any additional states are optional." OBJECT prtConsoleOnTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtConsoleOffTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" ::= { prtMIBConformance 1 } prtMIB2Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the printer MIB V2." -- The changes from RFC 1759 fall into 2 categories: -- 1. New objects plus existing objects with a MIN-ACCESS of -- read-only are included. Existing objects have been added -- to this category due to feedback from implementers and -- interoperability testing. This allows products to be -- be designed with a higher degree of SNMP security. -- 2. New object groups have been added to include all new -- objects in this MIB. All new object groups are optional. -- Any MIB that is compliant with RFC 1759 will also be -- compliant with this version of the MIB. MODULE -- this module MANDATORY-GROUPS { prtGeneralGroup, prtInputGroup, prtOutputGroup, prtMarkerGroup, prtMediaPathGroup, prtChannelGroup, prtInterpreterGroup, prtConsoleGroup, prtAlertTableGroup } OBJECT prtGeneralReset SYNTAX INTEGER { notResetting(3), resetToNVRAM(5) } DESCRIPTION "It is conformant to implement just these two states in this object. Any additional states are optional." OBJECT prtGeneralCurrentLocalization MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" Bergman, et al. Standards Track [Page 135] RFC 3805 Printer MIB v2 June 2004 OBJECT prtGeneralCurrentOperator MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtGeneralServicePerson MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtGeneralPrinterName MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtGeneralSerialNumber MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputDefaultIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputMediaDimFeedDirDeclared MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputMaxCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputCurrentLevel MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputMediaName MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputName MIN-ACCESS read-only DESCRIPTION Bergman, et al. Standards Track [Page 136] RFC 3805 Printer MIB v2 June 2004 "It is conformant to implement this object as read-only" OBJECT prtInputSecurity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputMediaWeight MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputMediaType MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputMediaColor MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputMediaFormParts MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputDefaultIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputMaxCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputRemainingCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputName MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputSecurity Bergman, et al. Standards Track [Page 137] RFC 3805 Printer MIB v2 June 2004 MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputMaxDimFeedDir MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputMaxDimXFeedDir MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputMinDimFeedDir MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputMinDimXFeedDir MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputStackingOrder MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputPageDeliveryOrientation MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputBursting MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputDecollating MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtOutputPageCollated MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" Bergman, et al. Standards Track [Page 138] RFC 3805 Printer MIB v2 June 2004 OBJECT prtOutputOffsetStacking MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtMarkerDefaultIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtMarkerSuppliesMaxCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtMarkerSuppliesLevel MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtMediaPathDefaultIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtChannelCurrentJobCntlLangIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtChannelDefaultPageDescLangIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtChannelState MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtChannelIfIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInterpreterDefaultOrientation MIN-ACCESS read-only DESCRIPTION Bergman, et al. Standards Track [Page 139] RFC 3805 Printer MIB v2 June 2004 "It is conformant to implement this object as read-only" OBJECT prtInterpreterDefaultCharSetIn MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInterpreterDefaultCharSetOut MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtConsoleLocalization MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtConsoleDisable MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtConsoleDisplayBufferText MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtConsoleOnTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtConsoleOffTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtAlertIndex MIN-ACCESS accessible-for-notify DESCRIPTION "It is conformant to implement this object as accessible-for-notify " GROUP prtResponsiblePartyGroup DESCRIPTION "This group is unconditionally optional." GROUP prtExtendedInputGroup Bergman, et al. Standards Track [Page 140] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "This group is unconditionally optional." GROUP prtInputMediaGroup DESCRIPTION "This group is unconditionally optional." GROUP prtExtendedOutputGroup DESCRIPTION "This group is unconditionally optional." GROUP prtOutputDimensionsGroup DESCRIPTION "This group is unconditionally optional." GROUP prtOutputFeaturesGroup DESCRIPTION "This group is unconditionally optional." GROUP prtMarkerSuppliesGroup DESCRIPTION "This group is unconditionally optional." GROUP prtMarkerColorantGroup DESCRIPTION "This group is unconditionally optional." GROUP prtAlertTimeGroup DESCRIPTION "This group is unconditionally optional." -- the prtResponsiblePartyGroup, prtExtendedInputGroup, -- prtInputMediaGroup, prtExtendedOutputGroup, -- prtOutputDimensionsGroup, prtOutputFeaturesGroup, -- prtMarkerSuppliesGroup, prtMarkerColorantGroup, and the -- prtAlertTimeGroup are completely optional. However, it is -- strongly RECOMMENDED that the prtAlertTimeGroup be implemented. -- New to version 2 of this printer MIB: OBJECT prtAuxiliarySheetStartupPage MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtAuxiliarySheetBannerPage MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" Bergman, et al. Standards Track [Page 141] RFC 3805 Printer MIB v2 June 2004 OBJECT prtInputMediaLoadTimeout MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT prtInputNextIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" GROUP prtAuxiliarySheetGroup DESCRIPTION "This group is unconditionally optional." GROUP prtInputSwitchingGroup DESCRIPTION "This group is unconditionally optional." GROUP prtGeneralV2Group DESCRIPTION "This group is unconditionally optional." GROUP prtAlertTableV2Group DESCRIPTION "This group is unconditionally optional." GROUP prtChannelV2Group DESCRIPTION "This group is unconditionally optional." GROUP prtAlertTrapGroup DESCRIPTION "This group is unconditionally optional." ::= { prtMIBConformance 3 } prtMIBGroups OBJECT IDENTIFIER ::= { prtMIBConformance 2 } -- These groups are from RFC 1759 and are applicable to Printer MIB V2 prtGeneralGroup OBJECT-GROUP OBJECTS { prtGeneralConfigChanges, prtGeneralCurrentLocalization, prtGeneralReset, prtCoverDescription, prtCoverStatus, prtLocalizationLanguage, prtLocalizationCountry, prtLocalizationCharacterSet, prtStorageRefIndex, prtDeviceRefIndex } STATUS current DESCRIPTION Bergman, et al. Standards Track [Page 142] RFC 3805 Printer MIB v2 June 2004 "The general printer group." ::= { prtMIBGroups 1 } prtResponsiblePartyGroup OBJECT-GROUP OBJECTS { prtGeneralCurrentOperator, prtGeneralServicePerson } STATUS current DESCRIPTION "The responsible party group contains contact information for humans responsible for the printer." ::= { prtMIBGroups 2 } prtInputGroup OBJECT-GROUP OBJECTS { prtInputDefaultIndex, prtInputType, prtInputDimUnit, prtInputMediaDimFeedDirDeclared, prtInputMediaDimXFeedDirDeclared, prtInputMediaDimFeedDirChosen, prtInputMediaDimXFeedDirChosen, prtInputCapacityUnit, prtInputMaxCapacity, prtInputCurrentLevel, prtInputStatus, prtInputMediaName } STATUS current DESCRIPTION "The input group." ::= { prtMIBGroups 3 } prtExtendedInputGroup OBJECT-GROUP OBJECTS { prtInputName, prtInputVendorName, prtInputModel, prtInputVersion, prtInputSerialNumber, prtInputDescription, prtInputSecurity } STATUS current DESCRIPTION "The extended input group." ::= { prtMIBGroups 4 } prtInputMediaGroup OBJECT-GROUP OBJECTS { prtInputMediaWeight, prtInputMediaType, prtInputMediaColor, prtInputMediaFormParts } STATUS current DESCRIPTION "The input media group." ::= { prtMIBGroups 5 } prtOutputGroup OBJECT-GROUP OBJECTS { prtOutputDefaultIndex, prtOutputType, prtOutputCapacityUnit, prtOutputMaxCapacity, prtOutputRemainingCapacity, prtOutputStatus } STATUS current DESCRIPTION "The output group." Bergman, et al. Standards Track [Page 143] RFC 3805 Printer MIB v2 June 2004 ::= { prtMIBGroups 6 } prtExtendedOutputGroup OBJECT-GROUP OBJECTS { prtOutputName, prtOutputVendorName, prtOutputModel, prtOutputVersion, prtOutputSerialNumber, prtOutputDescription, prtOutputSecurity } STATUS current DESCRIPTION "The extended output group." ::= { prtMIBGroups 7 } prtOutputDimensionsGroup OBJECT-GROUP OBJECTS { prtOutputDimUnit, prtOutputMaxDimFeedDir, prtOutputMaxDimXFeedDir, prtOutputMinDimFeedDir, prtOutputMinDimXFeedDir } STATUS current DESCRIPTION "The output dimensions group" ::= { prtMIBGroups 8 } prtOutputFeaturesGroup OBJECT-GROUP OBJECTS { prtOutputStackingOrder, prtOutputPageDeliveryOrientation, prtOutputBursting, prtOutputDecollating, prtOutputPageCollated, prtOutputOffsetStacking } STATUS current DESCRIPTION "The output features group." ::= { prtMIBGroups 9 } prtMarkerGroup OBJECT-GROUP OBJECTS { prtMarkerDefaultIndex, prtMarkerMarkTech, prtMarkerCounterUnit, prtMarkerLifeCount, prtMarkerPowerOnCount, prtMarkerProcessColorants, prtMarkerSpotColorants, prtMarkerAddressabilityUnit, prtMarkerAddressabilityFeedDir, prtMarkerAddressabilityXFeedDir, prtMarkerNorthMargin, prtMarkerSouthMargin, prtMarkerWestMargin, prtMarkerEastMargin, prtMarkerStatus } STATUS current DESCRIPTION "The marker group." ::= { prtMIBGroups 10 } prtMarkerSuppliesGroup OBJECT-GROUP OBJECTS { prtMarkerSuppliesMarkerIndex, prtMarkerSuppliesColorantIndex, prtMarkerSuppliesClass, prtMarkerSuppliesType, prtMarkerSuppliesDescription, Bergman, et al. Standards Track [Page 144] RFC 3805 Printer MIB v2 June 2004 prtMarkerSuppliesSupplyUnit, prtMarkerSuppliesMaxCapacity, prtMarkerSuppliesLevel } STATUS current DESCRIPTION "The marker supplies group." ::= { prtMIBGroups 11 } prtMarkerColorantGroup OBJECT-GROUP OBJECTS { prtMarkerColorantMarkerIndex, prtMarkerColorantRole, prtMarkerColorantValue, prtMarkerColorantTonality } STATUS current DESCRIPTION "The marker colorant group." ::= { prtMIBGroups 12 } prtMediaPathGroup OBJECT-GROUP OBJECTS { prtMediaPathDefaultIndex, prtMediaPathMaxSpeedPrintUnit, prtMediaPathMediaSizeUnit, prtMediaPathMaxSpeed, prtMediaPathMaxMediaFeedDir, prtMediaPathMaxMediaXFeedDir, prtMediaPathMinMediaFeedDir, prtMediaPathMinMediaXFeedDir, prtMediaPathType, prtMediaPathDescription, prtMediaPathStatus} STATUS current DESCRIPTION "The media path group." ::= { prtMIBGroups 13 } prtChannelGroup OBJECT-GROUP OBJECTS { prtChannelType, prtChannelProtocolVersion, prtChannelCurrentJobCntlLangIndex, prtChannelDefaultPageDescLangIndex, prtChannelState, prtChannelIfIndex, prtChannelStatus } STATUS current DESCRIPTION "The channel group." ::= { prtMIBGroups 14 } prtInterpreterGroup OBJECT-GROUP OBJECTS { prtInterpreterLangFamily, prtInterpreterLangLevel, prtInterpreterLangVersion, prtInterpreterDescription, prtInterpreterVersion, prtInterpreterDefaultOrientation, prtInterpreterFeedAddressability, prtInterpreterXFeedAddressability, prtInterpreterDefaultCharSetIn, prtInterpreterDefaultCharSetOut, prtInterpreterTwoWay } STATUS current Bergman, et al. Standards Track [Page 145] RFC 3805 Printer MIB v2 June 2004 DESCRIPTION "The interpreter group." ::= { prtMIBGroups 15 } prtConsoleGroup OBJECT-GROUP OBJECTS { prtConsoleLocalization, prtConsoleNumberOfDisplayLines, prtConsoleNumberOfDisplayChars, prtConsoleDisable, prtConsoleDisplayBufferText, prtConsoleOnTime, prtConsoleOffTime, prtConsoleColor, prtConsoleDescription } STATUS current DESCRIPTION "The console group." ::= { prtMIBGroups 16 } prtAlertTableGroup OBJECT-GROUP OBJECTS { prtAlertSeverityLevel, prtAlertTrainingLevel, prtAlertGroup, prtAlertGroupIndex, prtAlertLocation, prtAlertCode, prtAlertDescription } STATUS current DESCRIPTION "The alert table group." ::= { prtMIBGroups 17 } prtAlertTimeGroup OBJECT-GROUP OBJECTS { prtAlertTime } STATUS current DESCRIPTION "The alert time group. Implementation of prtAlertTime is strongly RECOMMENDED." ::= { prtMIBGroups 18 } prtMIB2Groups OBJECT IDENTIFIER ::= { prtMIBConformance 4 } -- These groups are unique to Printer MIB V2 prtAuxiliarySheetGroup OBJECT-GROUP OBJECTS { prtAuxiliarySheetStartupPage, prtAuxiliarySheetBannerPage } STATUS current DESCRIPTION "The auxiliary sheet group." ::= { prtMIBGroups 19 } prtInputSwitchingGroup OBJECT-GROUP OBJECTS { prtInputMediaLoadTimeout, prtInputNextIndex } STATUS current DESCRIPTION "The input switching group." Bergman, et al. Standards Track [Page 146] RFC 3805 Printer MIB v2 June 2004 ::= { prtMIBGroups 20 } prtGeneralV2Group OBJECT-GROUP OBJECTS { prtGeneralPrinterName, prtGeneralSerialNumber } STATUS current DESCRIPTION "The general printer group with new v2 objects." ::= { prtMIBGroups 21 } prtAlertTableV2Group OBJECT-GROUP OBJECTS { prtAlertIndex, prtAlertCriticalEvents, prtAlertAllEvents } STATUS current DESCRIPTION "The alert table group with new v2 objects and prtAlertIndex changed to MAX-ACCESS of 'read-only' for inclusion in the trap bindings (as originally defined in RFC 1759)." ::= { prtMIBGroups 22 } prtChannelV2Group OBJECT-GROUP OBJECTS { prtChannelInformation } STATUS current DESCRIPTION "The channel group with a new v2 object." ::= { prtMIBGroups 23 } prtAlertTrapGroup NOTIFICATION-GROUP NOTIFICATIONS { printerV2Alert } STATUS current DESCRIPTION "The alert trap group." ::= { prtMIBGroups 24 } END 7. IANA Considerations The initial version the IANA Printer MIB defined in section 5 of this document is to be archived by IANA and subsequently maintained according to the Process specified in section 2.4.1 of this document. The most current and authoritative version of the IANA Printer MIB is available at: http://www.iana.org/assignments/ianaprinter-mib 8. Internationalization Considerations See section 2.2.1.1, 'International Considerations'. Bergman, et al. Standards Track [Page 147] RFC 3805 Printer MIB v2 June 2004 9. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: prtGeneralTable: prtGeneralCurrentLocalization - Possible data loss prtGeneralReset - Possible data loss prtGeneralCurrentOperator - Possible severe inconvenience prtGeneralServicePerson - Possible severe inconvenience prtInputDefaultIndex - Possible data loss prtOutputDefaultIndex - Possible minor inconvenience prtMarkerDefaultIndex - Possible minor inconvenience prtMediaPathDefaultIndex - Possible minor inconvenience prtConsoleLocalization - Possible severe inconvenience prtConsoleDisable - Possible severe inconvenience prtAuxiliarySheetStartupPage - Possible minor inconvenience prtAuxiliarySheetBannerPage - Possible minor inconvenience prtGeneralPrinterName - Possible severe inconvenience prtGeneralSerialNumber - Possible severe inconvenience prtInputTable: prtInputMediaDimFeedDirDeclared - Possible data loss prtInputMediaDimXFeedDirDeclared - Possible data loss prtInputMaxCapacity - Possible minor inconvenience prtInputCurrentLevel - Possible minor inconvenience prtInputMediaName - Possible minor inconvenience prtInputName - Possible minor inconvenience prtInputSecurity - Possible minor inconvenience prtInputMediaWeight - Possible minor inconvenience prtInputMediaType - Possible minor inconvenience prtInputMediaColor - Possible minor inconvenience prtInputMediaFormParts - Possible minor inconvenience prtInputMediaLoadTimeout - Possible minor inconvenience prtInputNextIndex - Possible minor inconvenience prtOutputTable prtOutputMaxCapacity - Possible minor inconvenience prtOutputRemainingCapacity - Possible minor inconvenience prtOutputName - Possible minor inconvenience prtOutputSecurity - Possible minor inconvenience prtOutputMaxDimFeedDir - Possible minor inconvenience prtOutputMaxDimXFeedDir - Possible minor inconvenience prtOutputMinDimFeedDir - Possible minor inconvenience prtOutputMinDimXFeedDir - Possible minor inconvenience Bergman, et al. Standards Track [Page 148] RFC 3805 Printer MIB v2 June 2004 prtOutputStackingOrder - Possible minor inconvenience prtOutputPageDeliveryOrientation - Possible minor inconvenience prtOutputBursting - Possible minor inconvenience prtOutputDecollating - Possible minor inconvenience prtOutputPageCollated - Possible minor inconvenience prtOutputOffsetStacking - Possible minor inconvenience prtMarkerSuppliesTable prtMarkerSuppliesMaxCapacity - Possible minor inconvenience prtMarkerSuppliesLevel - Possible minor inconvenience prtChannelTable prtChannelCurrentJobCntlLangIndex - Possible data loss prtChannelDefaultPageDescLangIndex - Possible data loss prtChannelState - Possible minor inconvenience prtChannelIfIndex - Possible minor inconvenience prtInterpreterTable prtInterpreterDefaultOrientation - Possible data loss prtInterpreterDefaultCharSetIn - Possible data loss prtInterpreterDefaultCharSetOut - Possible minor inconvenience prtConsoleDisplayBufferTable prtConsoleDisplayBufferText - Possible minor inconvenience prtConsoleLightTable prtConsoleOnTime - Possible minor inconvenience prtConsoleOffTime - Possible minor inconvenience SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Where the operational capability of the printing device are especially vulnerable or difficult to administer, certain objects within this MIB have been tagged as READ-ONLY, preventing modification. Further, for all READ-WRITE objects within the MIB, the working group has included specific conformance guidelines Bergman, et al. Standards Track [Page 149] RFC 3805 Printer MIB v2 June 2004 stating that vendors are free to implement these objects as READ- ONLY. This conformance allowance should cover cases where specific vendor vulnerabilities may differ from product to product. (See conformance section with regards to MIN-ACCESS clauses). 10. References 10.1. Normative References [ASCII] ANSI, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4-1986. [CHARSET] IANA Character Set Registry: http://www.iana.org/assignments/character-sets [CHARMIB] IANA Character Set MIB: http://www.iana.org/assignments/ianacharset-mib [ISO10175] ISO, "Document Printing Application (DPA)", ISO 10175, 1996. [ISO10646] ISO, "Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO 10646-1, September 2000. ISO, "Universal Multiple-Octet Coded Character Set (UCS) - Part 2: Supplemental Planes", ISO 10646-2, January 2001. [PWGMEDIA] IEEE-ISTO PWG "The Printer Working Group Standard for Media Standardized Names", IEEE-ISTO PWG 5101.1-2002. [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. Bergman, et al. Standards Track [Page 150] RFC 3805 Printer MIB v2 June 2004 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3806] Bergman, R., Lewis, H., and I. McDonald, "Printer Finishing MIB", RFC 3806, June 2004. 10.2. Informative References [APPLEMAC] Apple staff, "Inside MacIntosh: Networking", 1994. [RFC854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, August 1990. [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol - HTTP/1.0", RFC 1945, May 1996. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 1999. Bergman, et al. Standards Track [Page 151] RFC 3805 Printer MIB v2 June 2004 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999. [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000. [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000. [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC3285] Gahrns, M. and T. Hain, "Using Microsoft Word to create Internet Drafts and RFCs", RFC 3285, May 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Bergman, et al. Standards Track [Page 152] RFC 3805 Printer MIB v2 June 2004 Appendix A - Glossary of Terms Addressability - On the marker, the number of distinct marking units (pels) per unit of addressability unit that can be set; for example, 300 dots per inch is expressed as 300 per 1000 Thousandths Of Inches and 4 dots per millimeter is 4 per 1000 Micrometers. Addressability is not resolution because marks that are one addressability position apart may not be independently resolvable by the eye due to factors such as gain in the area of marks so they overlap or nearly touch. Alert - A reportable event for which there is an entry in the alert table. Bin - An output sub-unit which may or may not be removable. Binary Change Event - An event which comes in pairs; the leading edge event and the trailing edge event. The leading edge event enters a state from which there is only one exit. A binary change event may be critical or non-critical. See unary change event. Bursting - The process by which continuous media is separated into individual sheets, typically by bursting along pre-formed perforations. Channel - A term used to describe a single source of data which is presented to a printer. The model that we use in describing a printer allows for an arbitrary number of channels. Multiple channels can exist on the same physical port. This is commonly done over Ethernet ports where EtherTalk, TCP/IP, and SPX/IPX protocols can be supplying different data streams simultaneously to a single printer on the same physical port. Collation - In multiple copy output, placing the pages from separate copies into separate ordered sets, ready for binding. Control Language - A data syntax or language for controlling the printer through the print data channel. Critical Alert - An alert triggered by an event which leads to a state in which printing is no longer possible; the printer is stopped. Decollating - The process by which the individual parts within a multi-part form are separated and sorted into separate stacks for each part. Description - Information about the configuration and capabilities of the printer and its various sub-units. Bergman, et al. Standards Track [Page 153] RFC 3805 Printer MIB v2 June 2004 DPA - ISO 10175 Document Printing Application standard. A standard for a client server protocol for a print system, including (1) submitting print jobs to and (2) managing print jobs in a spooler. Event - A state change in the printer. Group - A collection of objects that represent a type of sub-unit of the printer. Host Resources MIB - See [RFC2790]. IANA - Internet Assigned Numbers Authority. See [RFC3232]. Idempotent - Idempotence is the property of an operation that results in the same state no matter how many times it is executed (at least once). This is a property that is shared by true databases in which operations on data items only change the state of the data item and do not have other side effects. Because the SNMP data model is that of operations on a database, SNMP MIB objects should be assumed to be idempotent. If a MIB object is defined in a non-idempotent way, the this data model can break in subtle ways when faced with packet loss, multiple managers, and other common conditions. In order to fulfill the common need for actions to result from SNMP Set operations, SNMP MIB objects can be modeled such that the change in state from one state to another has the side effect of causing an action. It is important to note that with this model, an SNMP operation that sets a value equal to its current value will cause no action. This retains the idempotence of a single command, while allowing actions to be initiated by SNMP SET requests. Input - A tray or bin from which instances of the media are obtained and fed into the Media Path. Interpreter - The embodiment of an algorithm that processes a data stream consisting of a Page Description Language (PDL) and/or a Control Language. Localization - The specification of human language, country, and character set needed to present information to people in their native languages. Management Application (a.k.a. Manager) - A program which queries and controls one or more managed nodes. Management Station - A physical computer on which one or more management applications can run. Bergman, et al. Standards Track [Page 154] RFC 3805 Printer MIB v2 June 2004 Media Path - The mechanisms that transport instances of the media from an input, through the marker, possibly through media buffers and duplex pathways, out to the output with optional finishing applied. The inputs and outputs are not part of the Media Path. Non-critical Alert - An alert triggered by a reportable event which does not lead to a state in which printing is no longer possible; such an alert may lead to a state from which printing may no longer be possible in the future, such as the low toner state or the alert may be pure informational, such as a configuration change at the printer. Output - A bin or stacker which accepts instances of media that have been processed by a printer. Page Description Language (PDL) - A data syntax or language for the electronic representation of a document as a sequence of page images. Printer - A physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. Printing - The entire process of producing a printed document from generation of the file to be printed, choosing printing properties, selection of a printer, routing, queuing, resource management, scheduling, and finally printing including notifying the user. Reportable event - An event that is deemed of interest to a management station watching the printer. Status - Information regarding the current operating state of the printer and its various sub-units. This is an abstraction of the exact physical condition of the printer. Sub-mechanism - A distinguishable part of a sub-unit. Sub-unit - A part of the printer which may be a physical part, such as one of the input sources or a logical part such as an interpreter. Tray - An input sub-unit which is typically removable. Unary Change Event - An event that indicates a change of state of the printer, but to a state which is (often) just as valid as the state that was left, and from which no return is necessary. See binary change event. Bergman, et al. Standards Track [Page 155] RFC 3805 Printer MIB v2 June 2004 Visible state - The portion of the state of the printer that can be examined by a management application. Warning - A non-critical alert. See non-critical alert. Appendix B - Media Size Names The PWG Standardized Media Names specification [PWGMEDIA], section 5 Self Describing Names, contains the currently recommended media size names. This appendix lists the standardized media size names from ISO/IEC 10175 Document Printing Application (DPA), [ISO10175] as presented in RFC 1759. Management applications are encouraged to use the names from the PWG standard. However, many legacy systems exist that use the DPA names and they are presented here for the convenience of developers. A printer implementing the Printer MIB has no knowledge of these names, however; all media sizes in the MIB are given in terms of media dimensions as the values of prtInputMediaDimFeedDirChosen and prtInputMediaDimXFeedDirChosen. String name Description other unknown na-letter or letter North American letter size: 8.5 by 11 inches na-legal or legal North American legal size: 8.5 by 14 inches na-10x13-envelope North American 10x13 envelope size: 10 by 13 inches na-9x12-envelope North American 9x12 envelope size: 9 by 12 inches na-number-10-envelope North American number 10 business envelope size: 4.125 by 9.5 inches na-7x9-envelope North American 7x9 size: 7 by 9 inches na-9x11-envelope North American 9x11 size: 9 by 11 inches na-10x14-envelope North American 10x14 envelope size: 10 by 14 inches na-number-9-envelope North American number 9 business envelope size: 3.875 by 8.875 inches na-6x9-envelope North American 6x9 envelope size: 6 by 9 inches na-10x15-envelope North American 10x15 envelope size: 10 by 15 inches a engineering A size 8.5 inches by 11 inches b engineering B size 11 inches by 17 inches c engineering C size 17 inches by 22 inches d engineering D size 22 inches by 34 inches Bergman, et al. Standards Track [Page 156] RFC 3805 Printer MIB v2 June 2004 e engineering E size 34 inches by 44 inches iso-a0 ISO A0 size: 841 mm by 1189 mm iso-a1 ISO A1 size: 594 mm by 841 mm iso-a2 ISO A2 size: 420 mm by 594 mm iso-a3 ISO A3 size: 297 mm by 420 mm iso-a4 ISO A4 size: 210 mm by 297 mm iso-a5 ISO A5 size: 148 mm by 210 mm iso-a6 ISO A6 size: 105 mm by 148 mm iso-a7 ISO A7 size: 74 mm by 105 mm iso-a8 ISO A8 size: 52 mm by 74 mm iso-a9 ISO A9 size: 37 mm by 52 mm iso-a10 ISO A10 size: 26 mm by 37 mm iso-b0 ISO B0 size: 1000 mm by 1414 mm iso-b1 ISO B1 size: 707 mm by 1000 mm iso-b2 ISO B2 size: 500 mm by 707 mm iso-b3 ISO B3 size: 353 mm by 500 mm iso-b4 ISO B4 size: 250 mm by 353 mm iso-b5 ISO B5 size: 176 mm by 250 mm iso-b6 ISO B6 size: 125 mm by 176 mm iso-b7 ISO B7 size: 88 mm by 125 mm iso-b8 ISO B8 size: 62 mm by 88 mm iso-b9 ISO B9 size: 44 mm by 62 mm iso-b10 ISO B10 size: 31 mm by 44 mm iso-c0 ISO C0 size: 917 mm by 1297 mm iso-c1 ISO C1 size: 648 mm by 917 mm iso-c2 ISO C2 size: 458 mm by 648 mm iso-c3 ISO C3 size: 324 mm by 458 mm iso-c4 ISO C4 size: 229 mm by 324 mm iso-c5 ISO C5 size: 162 mm by 229 mm iso-c6 ISO C6 size: 114 mm by 162 mm iso-c7 ISO C7 size: 81 mm by 114 mm iso-c8 ISO C8 size: 57 mm by 81 mm iso-designated ISO Designated Long size: 110 mm by 220 mm jis-b0 JIS B0 size 1030 mm by 1456 mm jis-b1 JIS B1 size 728 mm by 1030 mm jis-b2 JIS B2 size 515 mm by 728 mm jis-b3 JIS B3 size 364 mm by 515 mm jis-b4 JIS B4 size 257 mm by 364 mm jis-b5 JIS B5 size 182 mm by 257 mm jis-b6 JIS B6 size 128 mm by 182 mm jis-b7 JIS B7 size 91 mm by 128 mm jis-b8 JIS B8 size 64 mm by 91 mm jis-b9 JIS B9 size 45 mm by 64 mm jis-b10 JIS B10 size 32 mm by 45 mm Bergman, et al. Standards Track [Page 157] RFC 3805 Printer MIB v2 June 2004 Appendix C - Media Names For the convenience of management application developers, this appendix lists the standardized media names from ISO/IEC 10175 Document Printing Application (DPA), [ISO10175]. Management applications that present a dialogue for choosing media may wish to use these names as an alternative to separately specifying, size, color, and/or type. New names may also be created using this format and the names defined in the PWG Standardized Media Names specification [PWGMEDIA]. Using standard media names will mean that a single management application dealing with printers from different vendors and under different system mangers will tend to use the same names for the same media. If selection of media by name is used, the attributes (size, type or color) implied by the name must be explicitly mapped to the appropriate object (prtInputMediaDimFeedDirDeclared, prtInputMediaDimXFeedDirDeclared, prtInputMediaType and prtInputMediaColor) in the MIB. The object prtInputMediaName is intended for display to an operator and is purely descriptive. The value in prtInputMediaName is not interpreted by the printer so using a standard name for this value will not change any of the other media attributes nor will it cause an alert if the media in the input sub- unit does not match the name. Simple Name Descriptor Text other unknown iso-a4-white Specifies the ISO A4 white medium with size: 210 mm by 297 mm as defined in ISO 216 iso-a4-coloured Specifies the ISO A4 colored medium with size: 210 mm by 297 mm as defined in ISO 216 iso-a4-transparent Specifies the ISO A4 transparent medium with size: 210 mm by 297 mm as defined in ISO 216 iso-a3-white Specifies the ISO A3 white medium with size: 297 mm by 420 mm as defined in ISO 216 iso-a3-coloured Specifies the ISO A3 colored medium with size: 297 mm by 420 mm as defined in ISO 216 iso-a5-white Specifies the ISO A5 white medium with size: 148 mm by 210 mm as defined in ISO 216 iso-a5-coloured Specifies the ISO A5 colored medium with size: 148 mm by 210 mm as defined in ISO 216 iso-b4-white Specifies the ISO B4 white medium with size: 250 mm by 353 mm as defined in ISO 216 iso-b4-coloured Specifies the ISO B4 colored medium with size: 250 mm by 353 mm as defined in ISO 216 Bergman, et al. Standards Track [Page 158] RFC 3805 Printer MIB v2 June 2004 iso-b5-white Specifies the ISO B5 white medium with size: 176 mm by 250 mm as defined in ISO 216 iso-b5-coloured Specifies the ISO B5 colored medium with size: 176 mm by 250 mm as defined in ISO 216 jis-b4-white Specifies the JIS B4 white medium with size: 257 mm by 364 mm as defined in JIS P0138 jis-b4-coloured Specifies the JIS B4 colored medium with size: 257 mm by 364 mm as defined in JIS P0138 jis-b5-white Specifies the JIS B5 white medium with size: 182 mm by 257 mm as defined in JIS P0138 jis-b5-coloured Specifies the JIS B5 colored medium with size: 182 mm by 257 mm as defined in JIS P0138 The following standard values are defined for North American media: na-letter-white Specifies the North American letter white medium with size: 8.5 inches by 11 inches na-letter-coloured Specifies the North American letter colored medium with size: 8.5 inches by 11 inches na-letter-transparent Specifies the North American letter transparent medium with size: 8.5 inches by 11 inches na-legal-white Specifies the North American legal white medium with size: 8.5 inches by 14 inches na-legal-coloured Specifies the North American legal colored medium with size: 8.5 inches by 14 inches The following standard values are defined for envelopes: iso-b5-envelope Specifies the ISO B5 envelope medium with size: 176 mm by 250 mm as defined in ISO 216 and ISO 269 iso-b4-envelope Specifies the ISO B4 envelope medium with size: 250 mm by 353 mm as defined in ISO 216 iso-c4-envelope Specifies the ISO C4 envelope medium with size: 229 mm by 324 mm as defined in ISO 216 and ISO 269 iso-c5-envelope Specifies the ISO C5 envelope medium with size: 162 mm by 229 mm as defined in ISO 269 iso-designated-long-envelope Specifies the ISO Designated Long envelope medium with size: 110 mm by 220 mm as defined in ISO 269 Bergman, et al. Standards Track [Page 159] RFC 3805 Printer MIB v2 June 2004 na-10x13-envelope Specifies the North American 10x13 envelope medium with size: 10 inches by 13 inches na-9x12-envelope Specifies the North American 9x12 envelope medium with size: 9 inches by 12 inches na-number-10-envelope Specifies the North American number 10 business envelope medium with size: 4.125 inches by 9.5 inches na-7x9-envelope Specifies the North American 7x9 inch envelope na-9x11-envelope Specifies the North American 9x11 inch envelope na-10x14-envelope Specifies the North American 10x14 inch envelope na-number-9-envelope Specifies the North American number 9 business envelope 3.875 by 8.875 inches na-6x9-envelope Specifies the North American 6x9 inch envelope na-10x15-envelope Specifies the North American 10x15 inch envelope The following standard values are defined for the less commonly used media (white-only): iso-a0-white Specifies the ISO A0 white medium with size: 841 mm by 1189 mm as defined in ISO 216 iso-a1-white Specifies the ISO A1 white medium with size: 594 mm by 841 mm as defined in ISO 216 iso-a2-white Specifies the ISO A2 white medium with size: 420 mm by 594 mm as defined in ISO 216 iso-a6-white Specifies the ISO A6 white medium with size: 105 mm by 148 mm as defined in ISO 216 iso-a7-white Specifies the ISO A7 white medium with size: 74 mm by 105 mm as defined in ISO 216 iso-a8-white Specifies the ISO A8 white medium with size: 52 mm by 74 mm as defined in ISO 216 iso-a9-white Specifies the ISO A9 white medium with size: 39 mm by 52 mm as defined in ISO 216 iso-a10-white Specifies the ISO A10 white medium with size: 26 mm by 37 mm as defined in ISO 216 Bergman, et al. Standards Track [Page 160] RFC 3805 Printer MIB v2 June 2004 iso-b0-white Specifies the ISO B0 white medium with size: 1000 mm by 1414 mm as defined in ISO 216 iso-b1-white Specifies the ISO B1 white medium with size: 707 mm by 1000 mm as defined in ISO 216 iso-b2-white Specifies the ISO B2 white medium with size: 500 mm by 707 mm as defined in ISO 216 iso-b3-white Specifies the ISO B3 white medium with size: 353 mm by 500 mm as defined in ISO 216 iso-b6-white Specifies the ISO B6 white medium with size: 125 mm by 176 mm i as defined in ISO 216 iso-b7-white Specifies the ISO B7 white medium with size: 88 mm by 125 mm as defined in ISO 216 iso-b8-white Specifies the ISO B8 white medium with size: 62 mm by 88 mm as defined in ISO 216 iso-b9-white Specifies the ISO B9 white medium with size: 44 mm by 62 mm as defined in ISO 216 iso-b10-white Specifies the ISO B10 white medium with size: 31 mm by 44 mm as defined in ISO 216 jis-b0-white Specifies the JIS B0 white medium with size: 1030 mm by 1456 mm jis-b1-white Specifies the JIS B1 white medium with size: 728 mm by 1030 mm jis-b2-white Specifies the JIS B2 white medium with size: 515 mm by 728 mm jis-b3-white Specifies the JIS B3 white medium with size: 364 mm by 515 mm jis-b6-white Specifies the JIS B6 white medium with size: 257 mm by 364 mm jis-b7-white Specifies the JIS B7 white medium with size: 182 mm by 257 mm jis-b8-white Specifies the JIS B8 white medium with size: 128 mm by 182 mm jis-b9-white Specifies the JIS B9 white medium with size: 91 mm by 128 mm jis-b10-white Specifies the JIS B10 white medium with size: 64 mm by 91 mm Bergman, et al. Standards Track [Page 161] RFC 3805 Printer MIB v2 June 2004 The following standard values are defined for engineering media: a Specifies the engineering A size medium with size: 8.5 inches by 11 inches b Specifies the engineering B size medium with size: 11 inches by 17 inches c Specifies the engineering C size medium with size: 17 inches by 22 inches d Specifies the engineering D size medium with size: 22 inches by 34 inches e Specifies the engineering E size medium with size: 34 inches by 44 inches Appendix D - Roles of Users Background The need for "Role Models" stemmed in large part from the need to understand the importance of any given proposed object for the MIB. Many times the real world need for a proposed object would be debated within the group; the debate would typically result in the need to describe the potential usage of the object in terms of a "live" person performing some type of printing-related task. Determining the value of a proposed object through identification of the associated human users was found to be so common that a more formalized model was required for consistent analysis. The model describing categories of human-oriented tasks is called "Role Models" in this document. In developing the Role Models it was necessary to identify the common, primary tasks that humans typically face when interacting with a printer and its related printing system(s). It was expected that certain kinds of tasks would serve to identify the various Role Models. In presenting the set of Role Models, the set of "Common Print System Tasks" are first presented, followed by the set of Role Model definitions. Finally, a simple matrix is presented in which Role Models and Tasks are cross-compared. Common Print System Tasks Upon researching the many tasks encountered by humans in dealing with printers and printing systems, the following were found to be pervasive within any operating environment: Printer job state - Determine the status of a job without a printer. Bergman, et al. Standards Track [Page 162] RFC 3805 Printer MIB v2 June 2004 Printer capabilities - Determine the current capabilities of a printer, for example, the available media sizes, two-sided printing, a particular type of interpreter, etc. Printer job submission - Submit a print job to a printer. Printer job removal - Remove a job from a printer. Notification of events - Receive notification of the existence of a defined printer event. An event can be of many types, including warnings, errors, job stage completion (e.g., "job done"), etc. Printer configuration - Query the current configuration of a printer. Printer consumables - Determine the current state of any and all consumables within a printer. Print job identification - Determine the identification of a job within a printer. Internal printer status - Determine the current status of the printer. Printer identification - Determine the identity of a printer. Printer location - Determine the physical location of a printer. Local system configuration - Determine various aspects of the current configuration of the local system involved with the operation of a printer. These "tasks" cover a large spectrum of requirements surrounding the operation of a printer in a network environment. This list serves as the basis for defining the various Role Models described below. Proposed Role Models Following is the list of "Role Models" used to evaluate the requirements for any given Printer MIB object. Note that the keyword enclosed in parentheses represents an abbreviation for the particular Role Model in the matrix described later in this document. User (USER) - A person or application that submits print jobs to the printer; typically viewed as the "end user" within the overall printing environment. Bergman, et al. Standards Track [Page 163] RFC 3805 Printer MIB v2 June 2004 Operator (OP) - A person responsible for maintaining a printer on a day-to-day basis, including such tasks as filling empty media trays, emptying full output trays, replacing toner cartridges, clearing simple paper jams, etc. Technician (TECH) - A person responsible for repairing a malfunctioning printer, performing routine preventive maintenance, and other tasks that typically require advanced training on the printer internals. An example of a "technician" would be a manufacturer's Field Service representative, or other person formally trained by the manufacturer or similar representative. System Manager (MGR) - A person responsible for configuration and troubleshooting of components involved in the overall printing environment, including printers, print queues and network connectivity issues. This person is typically responsible for ensuring the overall operational integrity of the print system components, and is typically viewed as the central point of coordination among all other Role Models. Help Desk (HELP) - A person responsible for supporting Users in their printing needs, including training Users and troubleshooting Users' printing problems. Asset Manager (AM) - A person responsible for managing an organization's printing system assets (primarily printers). Such a person needs to be able to identify and track the location of printing assets on an ongoing basis. Capacity Planner (CP) - A person responsible for tracking the usage of printing resources on an ongoing basis for the purpose of planning printer acquisitions and/or placement of printers based on usage trends. Installer (INST) - A person or application responsible for installing or configuring printing system components on a local system. Accountant (ACCT) - A person responsible for tracking the usage of printing resources on an ongoing basis for the purpose of charging Users for resources used. Matrix of Common Print System Tasks and Role Models To better understand the relationship between the set of defined "Common Print System Tasks" and the various "Role Models," the following matrix is provided. Bergman, et al. Standards Track [Page 164] RFC 3805 Printer MIB v2 June 2004 It is important to recognize that many of the tasks will appear to be applicable to many of the Role Models. However, when considering the actual context of a task, it is very important to realize that often the actual context of a task is such that the Role Model can change. For example, it is obvious that a "System Manager" must be able to submit print jobs to a printer; however, when submitting a print job, a person identified as a "System Manager" is actually operating in the context of a "User" in this case; hence, the requirement to submit a print job is not listed as a requirement for a System Manager. Conversely, while a "User" must be able to remove a job previously submitted to a printer, an "Operator" is often expected to be able to remove any print job from any printer; hence, print job removal is a (subtly different) requirement for both the "User" and "Operator" Role Models. Role Models ----------- Requirement Area USER OP TECH MGR HELP AM CP INST ACCT Print job status xx xx xx xx xx Printer capabilities xx xx xx Print job submission xx Print job removal xx xx Notification of events xx xx Printer configuration xx xx Printer consumables xx xx xx Print job identification xx xx xx xx xx Internal printer status xx xx xx Printer identification xx xx xx xx xx xx xx Printer location xx Local system configuration xx xx Appendix E - Overall Printer Status Table The Status Table establishes a convention for the top 25 printer errors. The table defines a suggested relationship between various printer states and the variables Printer hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState, prtAlertGroup, prtAlertCode and various sub-unit status variables (prtInputStatus, prtOutputStatus, prtMarkerStatus, prtMediaPathStatus and prtChannelStatus). This table is the recommended implementation of these variables. It is provided to guide implementors of this MIB and users of the MIB by providing a sample set of states and the variable values that are expected to be produced as result of that state. This information supplements that provided in Section Bergman, et al. Standards Track [Page 165] RFC 3805 Printer MIB v2 June 2004 2.2.13.2 "Overall Printer Status". This is not an exhaustive list rather it is a guideline. The definition of PrtSubUnitStatusTC specifies that SubUnitStatus is an integer that is the sum of 5 distinct values/states: Availability, Critical, Non-Critical, On-line and Transitioning. Thus when a non- critical alert or alerts are present the values for Availability, On-Line and Transitioning will be summed with the Non- Critical Alerts (8) value. The table was generated in landscape format and is located at ftp://ftp.pwg.org/pub/pwg/pmp/contributions/Top25Errors.pdf. Appendix F - Participants The Printer MIB Working Group would like to extend a special thank you to the following individuals that put forth a significant effort to review this document and provide numerous suggestions for improvement. David Harrington - Enterasys Networks Juergen Schoenwaelder - TU Braunschweig Bert Wijnen - Lucent Technologies and IETF Op & Mngmt, Area Director This version of the Printer MIB would not be possible without the previous work that resulted in RFC 1759. The authors of the Printer MIB version 2 would like to acknowledge the following individuals for their efforts in developing the base for this document. A special recognition is also extended to Steve Waldbusser, who provided significant technical guidance in the development of the architecture of the Printer MIB. Joel Gyllenskog - Microworks Tom Hastings - Xerox Jay Martin - Underscore, Inc. Ron Smith - Texas Instruments Steve Waldbusser - Lucent Technologies Don Wright - Lexmark Steve Zilles - Adobe The following people attended at least one meeting of the Printer MIB Working Group for version 2; many attended most meetings. Ron Bergman - Hitachi Printing Solutions Luis Cubero - Hewlett-Packard Jay Cummings - Novell Andy Davidson - Tektronix Lee Farrell - Canon Bergman, et al. Standards Track [Page 166] RFC 3805 Printer MIB v2 June 2004 Tom Hastings - Xerox Scott Isaacson - Novell Binnur Al-Kazily - Hewlett-Packard Rick Landau - Digital Equipment Corporation David Kellerman - Northlake Software Harry Lewis - IBM Pete Loya - Hewlett-Packard Jay Martin - Underscore, Inc. Bob Pentecost - Hewlett-Packard Dave Roach - Unisys Stuart Rowley - Kyocera Bob Setterbo - Adobe Mike Timperman - Lexmark Randy Turner - 2Wire, Inc. Bill Wagner - NETsilicon, Inc. Chris Wellens - Interworking Labs Craig Whittle - Sharp Labs Don Wright - Lexmark Lloyd Young - Lexmark Atsushi Yuki - Kyocera Steve Zilles - Adobe Bergman, et al. Standards Track [Page 167] RFC 3805 Printer MIB v2 June 2004 Significant Contributors Ray Casterline Lighthouse Solutions, LLC Phone: (716) 218-9910 EMail: RayCasterline@lhsolutions.com Gary Gocek Phone: (585) 223-3826 EMail: gary@gocek.org Thomas N. Hastings Xerox Corporation Phone: (310) 333-6413 EMail: hastings@cp10.es.xerox.com Scott Isaacson Novell Phone: (801) 861-7366 EMail: sisaacson@novell.com Binnur Al-Kazily Hewlett-Packard, Inc. Phone: (208) 396-6372 EMail: binnur_al-kazily@hp.com David Kellerman Northlake Software Phone: (503) 228-3383 EMail: kellerman@nls.com Matt King Lexmark International Phone: (859) 232-6907 EMail: emking@lexmark.com Jay Martin Underscore, Inc. Phone: (603) 889-7000 EMail: jkm@underscore.com Bergman, et al. Standards Track [Page 168] RFC 3805 Printer MIB v2 June 2004 Mike McKay Novell, Inc. Bob Pentecost Hewlett-Packard Phone: (208) 396-3312 EMail: bpenteco@boi.hp.com Stuart Rowley Kyocera Phone: (510) 299-7206 EMail: stuart.rowley@kyocera.com Gail Songer Peerless Systems Networking Phone: (650) 569-4414 EMail: gsonger@peerless.com Randy Turner 2Wire, Inc. Phone (408) 895-1216 EMail: rturner@2wire.com William Wagner NETsilicon, Inc. Phone: (781) 398-4588 EMail: WWagner@NetSilicon.com Chris Wellens Interworking Labs Phone: (408) 685-3190 EMail: chrisw@iwl.com F.D. Wright Lexmark International Phone: (859) 232-4808 EMail: don@lexmark.com Bergman, et al. Standards Track [Page 169] RFC 3805 Printer MIB v2 June 2004 Lloyd Young Lexmark International Phone: (859) 232-5150 EMail: lpyoung@lexmark.com Stephen N. Zilles Adobe Systems, Inc. Phone: (415) 962-4766 EMail: szilles@adobe.com Authors' Addresses Ron Bergman (Chairman) Hitachi Printing Solutions America 2635 Park Center Drive Simi Valley, CA 93065-6209 Phone: (805) 578-4421 EMail: Ron.Bergman@hitachi-ps.us Harry Lewis IBM 6300 Diagonal Hwy. Boulder, CO 80301 Phone (303) 924-5337 EMail: harryl@us.ibm.com Ira McDonald High North Inc P.O. Box 221 Grand Marais, MI 49839 Phone: (906) 494-2434 or (906) 494-2697 EMail: imcdonald@sharplabs.com Bergman, et al. Standards Track [Page 170] RFC 3805 Printer MIB v2 June 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bergman, et al. Standards Track [Page 171] snmp-mibs-downloader-1.1/mibrfcs/rfc3806.txt0000644000000000000000000032612611402176071015574 0ustar Network Working Group R. Bergman Request for Comments: 3806 Hitachi Printing Solutions Category: Informational H. Lewis IBM Corporation I. McDonald High North Inc. June 2004 Printer Finishing MIB Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a Printer System. Bergman, et al. Informational [Page 1] RFC 3806 Printer Finishing MIB June 2004 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Rational. . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. The Internet-Standard Management Framework. . . . . . . 4 1.4. Read-Write Objects. . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. General Terminology . . . . . . . . . . . . . . . . . . 5 2.2. Process Specific Terminology. . . . . . . . . . . . . . 9 3. Finisher Subunits Integrated into the Printer Model . . . . . 12 4. Finishing Specifications. . . . . . . . . . . . . . . . . . . 12 4.1. Multiple finDeviceTable Entries . . . . . . . . . . . . 13 4.2. Implicit Parameters . . . . . . . . . . . . . . . . . . 13 4.2.1. FinPunchPatternTC . . . . . . . . . . . . . . . 14 4.2.2. FinPunchHoleTypeTC, punchHoleSizeMaxDim, punchHoleSizeMinDim . . . . . . . . . . . . . . 15 5. The Attribute Mechanism . . . . . . . . . . . . . . . . . . . 15 5.1. Conformance of Attribute Implementation . . . . . . . . 16 5.2. Useful, 'Unknown', and 'Other' Values for Objects and Attributes. . . . . . . . . . . . . . . . . . . . . 16 5.3. Data Sub-types and Attribute Naming Conventions . . . . 17 5.4. Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes. . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Linked MUTI-ROW Values. . . . . . . . . . . . . . . . . 17 5.6. Index Value Attributes. . . . . . . . . . . . . . . . . 17 5.7. Attribute Specifications. . . . . . . . . . . . . . . . 18 6. Enumerations. . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Registering Additional Enumerated Values. . . . . . . . 23 7. IANA Printer Finishing MIB Specification. . . . . . . . . . . 24 8. Printer Finishing MIB Specification . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. Internationalization Considerations . . . . . . . . . . . . . 48 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 48 11.1. Normative References. . . . . . . . . . . . . . . . . . 48 11.2. Informative References. . . . . . . . . . . . . . . . . 49 12. Security Considerations . . . . . . . . . . . . . . . . . . . 49 13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 51 14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 52 15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 53 Bergman, et al. Informational [Page 2] RFC 3806 Printer Finishing MIB June 2004 1. Introduction This document describes an SNMP Management Information Base (MIB) to provide for the management of in-line post-processing in a fashion that is currently provided for printers, using the Printer MIB [RFC3805]. The Printer Finishing MIB includes the following features: - Provides the status of the finishing device. - Queries and controls the features and configuration of the finishing device. - Enables and disables the finishing processes. - Allows unsolicited status from the finishing device. The Finisher MIB is defined as an extension of the Printer MIB [RFC3805] and it is expected that the information defined in this document will be incorporated into a future update of the Printer MIB. 1.1. Scope This document provides a robust set of finishing devices, features, and functions, based upon today's state of the art of in-line finishing. Since finishing typically accompanies higher speed network printers and copiers, in contrast to simple desktop devices, no attempt is made to limit the scope to "bare minimum". On the other hand, the Printer Finishing MIB does not duplicate the production mail preparation, custom insertion, franking, and reprints that are covered by the DMTF Large Mailing Operations standard [LMO]. Information supplied by the Printer Finishing MIB may be utilized by printer and finisher management applications engaged in monitoring status and managing configuration, and also used by print and finishing submission applications which are engaged in: - print-job-level finishing processes that are applied to a complete print job, - document-level finishing processes that are applied individually to each document in the print job, - document-level finishing processes that are applied to a selected document in the print job. Note that not all combinations of finishing processes are permitted. Compatible combinations of finishing processes are implementation specific. The MIB allows invalid combinations to be identified. Bergman, et al. Informational [Page 3] RFC 3806 Printer Finishing MIB June 2004 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Rational The Printer MIB [RFC3805] is now successfully deployed in a large segment of the network printer market. SNMP and/or HTTP enabled printers and software management applications are growing in numbers. There is an increase in the availability of network printers and copiers that include in-line finishing processes. Thus a well defined and ordered set of finishing objects is now necessary for printer management. The printer model defined in the Printer MIB includes finishing processes and the MIB was designed to later incorporate finisher objects or to be referenced by a future Finisher MIB. 1.3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.4. Read-Write Objects Some objects in the Finisher MIB reflect the existence or amount of a given resource within the finisher. Some examples of such resources are the size and number of sheets in an inserter tray or the existence of certain finisher options. Some finishers have automatic sensors for these resources. Most finishers lack sensors for every property of every resource. The management application is allowed to write into objects that hold descriptive or existence values for finishers that cannot sense these values. The ability to change the value of a read-write object may depend on the implementation of the agent. Many objects in the MIB are given read-write access, but an implementation might only permit a management application to change Bergman, et al. Informational [Page 4] RFC 3806 Printer Finishing MIB June 2004 the value if the finisher can not sense the value itself. Note that even though some objects explicitly state the behavior of conditional ability to change values, any read-write object may act this way. Generally, an object is given read-write access in the Finisher MIB specification if: 1. The object involves installation of a resource that some finishers cannot themselves detect. Therefore, external means are needed to inform the device of the installation. (Here external means include using the operator console, or remote management application) and 2. The finisher will behave differently if the installation of the resource is reported than if the installation were not reported; that is, the object is not to be used as a place to put information not used by the finisher, i.e., not a "sticky-note". Another way of saying this is that the finisher believes that information given it and acts as if the information were true. 3. The finisher may get hints that it may not know about the existence or properties of certain resources. For example, a paper tray may be removed and re-inserted. When this removal and insertion happens, the finisher may either assume that a property, such as the size of paper in the tray, has not changed or the finisher may change the value of the associated object to "unknown", as might be done for the amount of paper in the tray. As long as the finisher acts according to the value in the object either strategy is acceptable. 4. It is an implementation-specific matter as to whether or not MIB object values are persistent across power cycles or cold starts. 2. Terminology Where appropriate, the Printer Finishing MIB will conform to the terminology, syntax, and semantics from the DMTF Large Mailing Operations standard [LMO], the Internet Printing Protocol [RFC2911], and/or the ISO Document Printing Application [DPA]. 2.1. General Terminology Finisher Input: An input tray on the finisher and not otherwise associated with the printer. An example of a finisher input is a tray that holds finishing "inserts". Bergman, et al. Informational [Page 5] RFC 3806 Printer Finishing MIB June 2004 ^ Y | |<---- Reference Edge | | |<--- Finishing Process Axis | | --->| |<--- Finishing Process Offset | | Head +=========================+ (X2,Y4) Locations # | # +-----#----+ # -----Y3--|-----#--O | <--+- Head # ^ +-----#----+ | Mechanisms # | # | | # | # | | # | # | | # | # | | # | +-----#----+ | # | ---Y2--|-----#--O | <--+ # | ^ +-----#----+ | # | | # | | # | | # | | # | | # | | # | | # | | # | | +-----#----+ | # | | -Y1--|-----#--O | <--+ # | | ^ +-----#----+ bottom right # | | | # | corner # X --------------- +==+======================+ ----> (0,0) (X1,0) Figure 1 - Finishing Process Axis Parallel to Y Axis Bergman, et al. Informational [Page 6] RFC 3806 Printer Finishing MIB June 2004 ^ Y | Head Locations |<---------------->|---X2 |<---->|---X1 | | | | | +-|-+ +-|-+ | | | | | | | (X3,Y2) +======|===========|======+ # | | | | | | # Finishing Process Axis #----| O |-------| O |----#----- Y1 # +---+ +---+ # ^ # ^ ^ # | # | | # | # +-----------+ # | # | # | # Head # | # Mechanisms # | # # | # # Finishing Process Offset # # | # # | # # | # # | # # | # # | # bottom right # | # corner # v X +=========================+ ------> (0,0) Reference Edge Figure 2 - Finishing Process Axis Parallel to X Axis Finisher Output: The output of the finisher. Because processing is in-line, the finisher outputs are a direct extension of the set of printer outputs. Media Orientation: All Finishing Processes are defined relative to a portrait orientation of the medium, regardless of the orientation of the printed image or the direction of feed. The 'X' and 'Y' axis, therefore, will always reference the medium as shown in figures 1 and 2, with the 'X' axis always along the short edge of the medium. All edges and corners are also defined with the medium orientation as shown using the syntax top, bottom, left, and right. Thus the bottom edge of the medium is at Y = 0, the left edge is at X = 0, and the bottom right corner is at (X2,0) as shown in the figure 1 and at (X3,0) as shown in figure 2. Bergman, et al. Informational [Page 7] RFC 3806 Printer Finishing MIB June 2004 Finishing: Defined by DPA as an operation on a document following the completion of the image process. Finishing processes defined within this document are those applied to one or more instances of rectangular paper sheet media. Finishing Process: Defined by DPA as an operation applied by a machine such as trimming a document, folding the sheets in a document, and applying a binding to a document. Finishing Specification: Defined by DPA as the specific sequence of operations for a serial combination of finishing processes. The exact sequential order of the processes, in many cases, is critical to the obtaining the desired result. For example, a folding operation followed by trimming could provide a very different result than if the trimming was followed by the folding. Finishing Process Parameters: This parameter set is used to create a detailed definition of the finishing process. Generic Finishing Process Parameters are applicable to any Finishing Specification. - Head Mechanism: Defined by DPA as the physical mechanism that is used to perform a finishing process. The head position may be fixed or variable depending upon the capabilities of the device. - Reference Edge: Defined by DPA as the edge of the document relative to the axis to which the finishing process is applied. The edge of the medium defined to be the Reference Edge may be either the 'X' or the 'Y' axis, depending upon the finishing process to be performed. Note that the Reference Edge may change from one finishing process to another for one of two reasons. First, a subsequent process may require a different Reference Edge. Second, the actual dimensions of the document may change, for example as a result of a folding or a trimming operation. - Jog Edge: Defined by DPA as one of the two edges that is perpendicular to the Reference Edge. Specifying the Jog Edge parameter indicates the edges of all sheets which correspond to the Jog Edge are aligned. - Finishing Process Axis: Defined by DPA as the axis which some finishing processes are applied to or referenced from by the Head Mechanism. Examples are the axis for a fold process or the axis for a punch process. - Head Locations: Defined by DPA as the position of the Heads on the Finishing Process Axis. Bergman, et al. Informational [Page 8] RFC 3806 Printer Finishing MIB June 2004 - Finishing Process Offset: The offset from the Reference Edge to the Finishing Process Axis at which the finishing process takes place or is applied. 2.2. Process Specific Terminology FOLDING: Z Fold: A fold in which two folds are placed in the sheet in opposite directions. The first fold is located at 25% of the sheet length, and the second is located at 50% of the sheet length (i.e., the center of the sheet). Z Folding is often used on 11x17 inch or A3 size sheets, when they are included in sets containing 8.5x11 inch or A4 size sheets. Half Fold: To fold a sheet in half so that one of the resulting dimensions are exactly half the original sheet. Often used for signatures or booklets. Letter Fold: Folding a sheet roughly in thirds. Usually performed on 8.5x11 inch or A4 size sheets for insertion into an envelope. Signature: The process by which images are placed on a large sheet of paper in correct panel areas and in the proper orientation such that when the sheet is folded it will produce a booklet with each page in the proper order and orientation. BINDING: Adhesive Binding: A method of attaching sheets together to form a book or booklet using glue or adhesive. Some adhesive binding methods apply the glue to sheets individually, before merging them together for form a book, but most methods involve the application of adhesive to an entire book of sheets. Comb Binding: A method of binding in which a series of small rectangular holes is placed along the bind edge of the sheets. The sheets are then held together using a tube shaped plastic binding strip with comb like fingers that fit through the holes in the sheets. Spiral Binding: Sometimes referred to as wire binding, this binding method is a mechanical bind in which the individual leaves are held together by a wire or plastic spiral that is fed through small holes in the paper binding edge. Bergman, et al. Informational [Page 9] RFC 3806 Printer Finishing MIB June 2004 Padding: Applying a non-penetrating adhesive to the edge of a stack of sheets such that the sheets can be easily peeled off one at a time. Frequently used for forms. Velo Binding: A bind formed by punching holes into the edge of the sheets, placing a two piece plastic strip (one side formed with plastic pins that pass through the holes) along the edge and then staking the two pieces together. Perfect Binding: A method of binding in which all pages are cut and roughed up at the back or binding edge and held together by an adhesive. Tape Binding: The act of placing tape over the bind edge of a set. Sometimes contains adhesive to provide a functional bind to the set, and sometimes done for decorative purposes on a set that has been edge stapled. SLITTING/CUTTING/TRIMMING: Trim: To cut the edges of a sheet or set of sheets. Face Trim: To cut the edges of a set of sheets on a booklet of sheets that have been folded to eliminate the "creep" or edge shingling that results from the folding process. Gutter Trim: To cut a larger sheet into smaller sheets eliminating the gutter between adjacent images. This operation requires a minimum of two cuts for each gutter. Tab Cutting: The act of cutting the edge of a sheet to form an index tab, thereby allowing quick identification and access. The external tabs are sequentially placed along the book edge for visibility and ease of grasping. Perforating: The act of cutting a series of very small, closely spaced holes or slots into a sheet to allow for ease of separation of a portion of the sheet. Sometimes also used to ease bending/hinging of heavy weight papers. Scoring: A means of applying small linear grooves or impressions along a sheet to allow easy folding. Often used on heavy weight sheets and book covers. Slitting: The action of cutting apart a large sheet to form smaller sheets. Usually done using a sharp circular roll system. Bergman, et al. Informational [Page 10] RFC 3806 Printer Finishing MIB June 2004 STITCHING/STAPLING: Staple: The process of binding a set of sheets together using a 'U' shaped piece of metal wire that is punched through the set. The ends of the metal staple are then bent over, or 'clinched' to hold the staple in place. Technically the term 'stapler' refers to devices that use pre-cut metal staples, but the term is also commonly used to refer to devices that use wire spools and then cut/form the staple. (see the definition of Stitch) Stitch: The process of binding a set of sheets together using a 'U' shaped piece of metal wire that is punched through the set. The wire used to form the staple is cut and formed into a 'U' shape in the stitcher head, and the staple 'leg' length is often varied depending on the number of sheets to be bound together. The ends of the metal staple are bent over, or 'clinched' to hold the staple in place. Stitching can also refer to the process of sewing the edges of the signatures of a book together. Saddle Stitch: The process of stapling a set along its center line as part of a booklet making process. Usually 2 or 3 staples are used. Dual Stapling: The process of placing 2 staples along the bind edge of a set. The staples are typically located at 25% and 75% of the length of the bind edge. Although dual stapling is often performed on the long edge of a set, legal documents are frequently dual stapled along the top, or short edge of the set. Triple Stapling: Same as above, but using 3 staples along the bind edge, and usually applies to the long edge only. WRAPPING: Shrink Wrap: A wrap of thin plastic which when heated will shrink and wrap tightly around the stack thus preparing it for shipment. BANDING: Band Wrap: Bundling a finished stack to prepare for shipment. Also known as Strap Wrap. ROTATING: Sheet Rotator: A device that rotates each sheet as received from the Media Path to the proper orientation for the finisher processing. Bergman, et al. Informational [Page 11] RFC 3806 Printer Finishing MIB June 2004 3. Finisher Subunits Integrated Into The Printer Model The Printer Finisher Device subunits receive media from one or more Printer Media Path subunits and deliver the media to one or more Printer Output subunits after the completion of the finishing processes. The Printer Model, as described in the Printer MIB [RFC3805], is modified adding the finisher subunit(s) and finisher supplies between the media path and output subunits as follows: +----------+ +----------+ | | Marker | | | Supplies |-+ +----------+ \ +-----+ \ +------+ +--------+ +------+ | | \| | | | | | +-----+ | +-----+ +------+ | +------+ +--------+ | +------+ | |Input|-+ +------+| |Marker|-+ +------+| |Finisher|-+ |Output|-+ | |===>| |+<==>| |<==>| |+==>| |===>| | +-----+ +-+ +-+ +------+ +-+ +-+ +--------+ +------+ \ | || | || \ \ | || | || \ \ | || | || +----------+ +-------+ | |+--------------------| || | Finisher |-+ | | | +---------------------+ || | Supplies | | +-------+ | | Media Path |+ +----------+ | | Media |-+ +---------------------------+ | | |(opt.) | +----------+ +-------+ 4. Finishing Specifications The Finisher MIB is able to provide most of the information that is required to generate a Finishing Specification. This includes; 1. Finishing operations that can be performed on media that are associated with a specific printer media path and output subunit. 2. Combinations of operations that cannot be performed. 3. The location of the operation on the medium, if applicable. 4. The physical characteristics of the result of the operation. For example, the size and shape of a punched hole, or if a fold operation creates a letter fold or a "Z" fold. Bergman, et al. Informational [Page 12] RFC 3806 Printer Finishing MIB June 2004 The Finisher MIB permits an agent to describe the order that operations can be performed. 4.1. Multiple finDeviceTable Entries Each finishing operation supported by the printer is represented by one or more entries in the finDeviceTable. Each entry in this table defines a "logical" finishing device, since the function of several table entries may be performed by a single finisher mechanism. Multiple entries may also exist in the table as a result of the existence of multiple finisher mechanisms that perform the same type of operation. One example of possible multiple entries for a single finisher device, is a hole punch operation that creates more than one hole. This could be performed using a single die punch that moves to each required position or a multi-die punch that simultaneously creates all holes. In either case, each defined hole position may be defined as a separate table entry. In both cases, if the punch positions can be individually selected, a table entry for each position would be necessary. For the multi-die punch, each head mechanism may have a different hole pattern or size. If these differences are to be properly disclosed, a table entry for each head mechanism would be required. 4.2. Implicit Parameters Finishing operations that are specified by an enum define a standard operation and in many cases an implicit set of physical characteristics is to be included when specifying the enum. If explicit values for these characteristics are not provided in the attributes table, the values defined in this section are to be implied. Bergman, et al. Informational [Page 13] RFC 3806 Printer Finishing MIB June 2004 4.2.1. FinPunchPatternTC enum pattern |Reference| Reference | Hole spacing | Edge |Axis Offset| (see note 1) -------------------+---------+-----------+--------------------------- twoHoleUSTop(4) | topEdge | note 2 | 2.75 inches threeHoleUS(5) | note 3 | note 2 | 4.25 inches twoHoleDIN(6) | note 4 | note 5 | 80 mm fourHoleDIN(7) | note 4 | note 5 | 80 mm twentyTwoHoleUS(8) | note 3 | note 2 | .5 inches nineteenHoleUS(9) | note 3 | note 9 | .5625 inches twoHoleMetric(10) | note 6 | note 5 | 80 mm swedish4Hole(11) | note 4 | note 5 | 21, 70, 21 mm twoHoleUSSide(12) | note 3 | note 2 | 2.75 inches fiveHoleUS(13) | note 3 | note 2 | 2, 2.25, 2.25, 2 in sevenHoleUS(14) | note 3 | note 2 | 1, 1, 2.25, 2.25, 1, 1 in mixed7H4S(15) | note 4 | note 5 | note 7 norweg6Hole(16) | note 4 | note 5 | note 8 metric26Hole(17) | note 6 | note 5 | 9.5 mm metric30Hole(18) | note 4 | note 5 | 9.5 mm Notes: 1. All hole to hole patterns are centered along the process edge. 2. Offset is 0.18 inches to 0.51 inches. 3. Reference edge is leftEdge(5) for letter and topEdge(3) for ledger. 4. Reference edge is leftEdge(5) for A4 and topEdge(3) for A3. 5. Offset is 4.5 mm to 13 mm. 6. Reference edge is leftEdge(5) for B5 and topEdge(3) for B4. 7. 7 holes and 4 slots are punched in a H-S-H-H-S-H-S-H-H-S-H pattern with 15, 25, 23, 20, 37, 37, 20, 23, 25, 15 mm spacing. 8. 4 holes and 2 slots are punched in a H-H-S-S-H-H pattern with a 64, 18.5, 75, 18.5, 64 mm spacing. 9. Offset is .188 inches. Bergman, et al. Informational [Page 14] RFC 3806 Printer Finishing MIB June 2004 4.2.2 FinPunchHoleTypeTC, punchHoleSizeMaxDim, punchHoleSizeMinDim enum pattern | Hole Description -------------------+---------------------------------------- twoHoleUSTop(4) | round(3), .2 - .32 inch diameter threeHoleUS(5) | round(3), .2 - .32 inch diameter twoHoleDIN(6) | round(3), 5 - 8 mm diameter fourHoleDIN(7) | round(3), 5 - 8 mm diameter twentyTwoHoleUS(8) | round(3), .2 - .32 inch diameter nineteenHoleUS(9) | rectang(6), .313 inches X .125 inches twoHoleMetric(10) | round(3), 5 - 8 mm diameter swedish4Hole(11) | round(3), 5 - 8 mm diameter twoHoleUSSide(12) | round(3), .2 - .32 inch diameter fiveHoleUS(13) | round(3), .2 - .32 inch diameter sevenHoleUS(14) | round(3), .2 - .32 inch diameter mixed7H4S(15) | round(3), 5 - 8 mm diameter | rectang(6), 12 mm X 6 mm norweg6Hole(16) | round(3), 5 - 8 mm diameter | rectang(6), 10 mm X 5.5 mm metric26Hole(17) | round(3), 5 - 8 mm metric30Hole(18) | round(3), 5 - 8 mm Note: Hole size ranges are typical and are provided as a reference only. Exact tolerances should be site defined. 5. The Attribute Mechanism Attributes provide a function similar to information objects, except that attributes are identified by an enum, instead of an OID. Thus new attributes may be registered without requiring a change to the MIB. In addition, an implementation that does not have the functionality represented by the attribute can omit the attribute entirely, rather than having to return a distinguished value. The agent is free to create an attribute in the Attribute Table as soon as the agent is aware of the value of the attribute. The agent materializes finishing subunit attributes in a four-indexed finDeviceAttributeTable: 1. hrDeviceIndex - which device in the host 2. finDeviceIndex - which finisher subunit in the printer device 3. finDeviceAttributeTypeIndex - which attribute 4. finDeviceAttributeInstanceIndex - which attribute instance for those attributes that can have multiple values per finishing subunit. Bergman, et al. Informational [Page 15] RFC 3806 Printer Finishing MIB June 2004 5.1. Conformance of Attribute Implementation An agent SHALL implement any attribute if (1) the device supports the functionality represented by the attribute and (2) the information is available to the agent. The agent MAY create the attribute row in the finDeviceAttributeTable when the information is available or MAY create the row earlier with the designated 'unknown' value appropriate for that attribute. See next section. If the device does not implement or does not provide access to the information about an attribute, the agent SHOULD NOT create the corresponding row in the finDeviceAttributeTable. 5.2. Useful, 'Unknown', and 'Other' Values for Objects and Attributes Some attributes have a 'useful' Integer32 value, some have a 'useful' OCTET STRING value, some MAY have either or both depending on implementation, and some MUST have both. See the finDeviceAttributeTypeTC textual convention for the specification of each attribute. NOTE: In some instances, objects with a MAX-ACCESS of read-write will result in an SNMPv1 error or SNMPv2 exception during a write operation. The administrative security policy may restrict a class of users to read-only or, more importantly, the implementation may implement a subset of read-write objects as read-only. This should be expected to be the case for a device that can properly sense the value of an object and does not want the value to be externally modified. In general, values for objects and attributes have been chosen so that a management application will be able to determine whether a 'useful', 'unknown', or 'other' value is available. When a useful value is not available for an object that agent SHALL return a zero- length string for octet strings, the value 'unknown(2)' for enums, a '0' value for an object that represents an index in another table, and a value '-2' for counting integers. Since each attribute is represented by a row consisting of both the finDeviceAttributeValueAsInteger and finDeviceAttributeValueAsOctets MANDATORY objects, SNMP requires that the agent SHALL always create an attribute row with both objects specified. However, for most attributes the agent SHALL return a "useful" value for one of the objects and SHALL return the 'other' value for the other object. For integer only attributes, the agent SHALL always return a zero-length string value for the finDeviceAttributeValueAsOctets object. For octet string only attributes, the agent SHALL always return a '-1' value for the finDeviceAttributeValueAsInteger object. Bergman, et al. Informational [Page 16] RFC 3806 Printer Finishing MIB June 2004 5.3. Data Sub-types and Attribute Naming Conventions Many attributes are sub-typed to give a more specific data type than Integer32 or OCTET STRING. The data sub-type of each attribute is indicated on the first line(s) of the description. Some attributes have several different data sub-type representations. When an attribute has both an Integer32 data sub-type and an OCTET STRING data sub-type, the attribute can be represented in a single row in the finDeviceAttributeTable. In this case, the data sub-type name is not included as the last part of the name of the attribute. When the data sub-types cannot be represented by a single row in the finDeviceAttributeTable, each such representation is considered a separate attribute and is assigned a separate name and enum value. For these attributes, the name of the data sub-type is the last part of the name of the attribute. 5.4. Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes Most attributes shall have only one row per finishing subunit. However, a few attributes can have multiple values per finishing subunit, where each value is a separate row in the finDeviceAttributeTable. Unless indicated with 'MULTI-ROW:' in the finDeviceAttributeTypeTC description, an agent SHALL ensure that each attribute occurs only once in the finDeviceAttributeTable for a finishing subunit. Most of the 'MULTI-ROW' attributes do not allow duplicate values, i.e., the agent SHALL ensure that each value occurs only once for a finishing subunit. Only if the specification of the 'MULTI-ROW' attribute also says "There is no restriction on the same xxx occurring in multiple rows" can the agent allow duplicate values to occur for a single finishing subunit. 5.5. Linked MUTI-ROW Values Some MULTI-ROW attributes are intended to go together. Thus a set of value instances represent a single instance. For example, the puncher attributes indicate the location, maximum size, minimum size and shape of the various holes that the puncher can produce. So the first set of values could represent one kind of hole, and the second set another kind of hole, etc. 5.6. Index Value Attributes A number of attributes are indexes in other tables. Such attribute names end with the word 'Index'. If the agent has not (yet) assigned an index value for a particular index attribute for a finishing subunit, the agent shall either: (1) return the value 0 or (2) not add this attribute to the finDeviceAttributeTable until the index Bergman, et al. Informational [Page 17] RFC 3806 Printer Finishing MIB June 2004 value is assigned. In the interests of brevity, the semantics for 0 is specified once here and is not repeated for each index attribute specification and a DEFVAL of 0 is indicated. 5.7. Attribute Specifications This section specifies the set of attributes that are enumerated in finAttributeTypeTC. The data type tag definitions 'INTEGER:' or 'OCTETS', indicate if the attribute can be represented using the object finDeviceAttributeAsInteger or the object finDeviceAttributeAsOctets, respectively. In some cases, a choice between the two data types is possible and for a few attributes both objects may be required at the same time to properly present the value. NOTE - The enum assignments are grouped logically with values assigned in groups of 10, so that additional values may be registered in the future and assigned a value that is part of their logical grouping. Values in the range 2**30 to 2**31-1 are reserved for private or experimental usage. This range corresponds to the same range reserved in IPP. Implementers are warned that use of such values may conflict with other implementations. Implementers are encouraged to request registration of enum values following the procedures in Section 6.1. The attribute types defined at the time of completion of this specification are: finAttributeTypeIndex Data type --------------------- --------- other(1), Integer32 AND/OR OCTET STRING (SIZE(0..63)) INTEGER: and/or OCTETS: An attribute that is not currently approved and registered. A. Generic finisher subunit attributes that apply to all finisher subunit types. (3..) deviceName(3), OCTET STRING (SIZE(0..63)) OCTETS: The name assigned to this finisher device subunit. deviceVendorName(4), OCTET STRING (SIZE(0..63)) OCTETS: The name of the vendor of this finisher device subunit. Bergman, et al. Informational [Page 18] RFC 3806 Printer Finishing MIB June 2004 deviceModel(5), OCTET STRING (SIZE(0..63)) OCTETS: The model name of this finisher device subunit. deviceVersion(6), OCTET STRING (SIZE(0..63)) OCTETS: The version string for this finisher device subunit. deviceSerialNumber(7), OCTET STRING (SIZE(0..63)) OCTETS: The serial number assigned to this finisher device subunit. maximumSheets(8), Integer32 (-2..32767) INTEGER: Defines the maximum number of media sheets that a finisher device is able to process. finProcessOffsetUnits(9), PrtMediaUnitTC INTEGER: An enumeration which defines the units of measure for the attributes finAxisOffset, finHeadLocation, punchHoleSizeLongDim, and punchHoleSizeShortDim. finReferenceEdge(10), FinEdgeTC INTEGER: An enumeration which defines which edge of the form is the reference for this finishing process. The Finishing Process Axis will be parallel to this axis. finAxisOffset(11), Integer32 (-2..2147483647) INTEGER: Defines the offset of the Finishing Process Axis from the parallel Reference Edge. For a value of finEdgeTC equal to TopEdge or RightEdge, the value given is to interpreted as a negative offset from the reference edge. The units of measure are defined by the attribute finProcessOffsetUnits. finJogEdge(12), FinEdgeTC INTEGER: An enumeration which defines a second edge of the document to which the media is aligned. The jog edge must be perpendicular to the edge defined by finReferenceEdge. finHeadLocation(13), Integer32 (-2..2147483647) INTEGER: MULTI-ROW: Defines the position of the Head Mechanism relative to the axis, 'X' or 'Y', that is perpendicular to the Process Axis. The units of measure are defined by the attribute finProcessOffsetUnits. finOperationRestrictions(14), Integer32 (0..65535) INTEGER: MULTI-ROW: Defines the finDeviceIndex of a finishing process which cannot be combined with the process defined by the finDeviceIndex for this Bergman, et al. Informational [Page 19] RFC 3806 Printer Finishing MIB June 2004 finDeviceAttributeTable instance. When this condition occurs this attribute SHALL be presented in the attribute tables for both finishing processes that cannot be combined. finNumberOfPositions(15), Integer32 (0..65535) INTEGER: Defines the total number of head positions for this finishing process. Each position many be realized by a unique head mechanism or a single head mechanism may be automatically moved to each position. namedConfiguration(16), OCTET STRING (SIZE(0..63)) OCTETS: Contains an administratively define name to define the finishing specification configured for this device. finMediaTypeRestriction(17), OCTET STRING (SIZE(0..63)) OCTETS: MULTI-ROW: Defines the media type which cannot be combined with the process defined by the finDeviceIndex for this finDeviceAttributeTable instance. Values are the same as defined for finSupplyMediaInputMediaName. finPrinterInputTraySupported(18), Integer32 (0..65535) INTEGER: MULTI-ROW: Defines the value of prtInputIndex corresponding to the printer input tray that can be used with the process defined by the finDeviceIndex for this finDeviceAttributeTable instance. If this attribute is not present, this process can be used with any input tray in the printer. For example, this attribute can indicate the current stapling capabilities for a stapler device for the input trays that depend upon the size and feed orientation. So if there were two letter trays, one with A size and the other with B size, a two position stapler might specify in one row: upper-left and upper-right for the input tray with A size, but only upper-left for the one with B size. finPreviousFinishingOperation(19), Integer32 (0..65535) INTEGER: Defines the finDeviceIndex of the previous finishing process for implementations in which the finishing processes are performed in a prescribed order. Each finishing process in the fixed sequence is either performed or not performed according to the finishing instructions submitted with the job. A value of 0 indicates that this finishing process is the first in a sequence. Finishing processes which are not part of a fixed sequence SHALL NOT have this attribute. Bergman, et al. Informational [Page 20] RFC 3806 Printer Finishing MIB June 2004 finNextFinishingOperation(20), Integer32 (0..65535) INTEGER: Defines the finDeviceIndex of the next finishing process for implementations in which the finishing processes are performed in a prescribed order. Each finishing process in the fixed sequence is either performed or not performed according to the finishing instructions submitted with the job. A value of 0 indicates that this finishing process is the last in a sequence. Finishing processes which are not part of a fixed sequence SHALL NOT have this attribute. B. Stitcher type-specific attributes (30..) stitchingType(30), FinStitchingTypeTC INTEGER: MULTI-ROW: Provides additional information regarding the stitching operation. stitchingDirection(31), FinStitchingDirTypeTC INTEGER: Defines the orientation of the stitching process. stitchingAngle(32), FinStitchingAngleTypeTC INTEGER: Defines enumerations that describe the angular orientation of the stitching process relative to the 'X' axis. C. Folder type-specific attributes (40..) foldingType(40), FinFoldingTypeTC INTEGER: Provides additional information regarding the folding process. D. Binder type-specific attributes (50..) bindingType(50), FinBindingTypeTC INTEGER: Provides additional information regarding the binding process. E. Trimmer type-specific attributes (60..) F. Die cutter type-specific attributes (70..) G. Puncher type-specific attributes (80..) punchHoleType(80), FinPunchHoleTypeTC INTEGER: Provides information regarding the shape of the punched hole. Bergman, et al. Informational [Page 21] RFC 3806 Printer Finishing MIB June 2004 punchHoleSizeLongDim(81), Integer32 (-2..2147483647) INTEGER: Defines the size of the punched hole in the longest dimension. This dimension is typically measured parallel to either the long edge or the short edge of the media and the longest dimension will always be measured 90 degrees from the shortest dimension. For a symmetrical hole, such as a round or square hole, the shortest and longest dimensions will be identical. The units of measure are defined by the attribute finProcessOffsetUnits. punchHoleSizeShortDim(82), Integer32 (-2..2147483647) INTEGER: Defines the size of the punched hole in the shortest dimension. This dimension is typically measured parallel to either the long edge or the short edge of the media and the shortest dimension will always be measured 90 degrees from the longest dimension. For a symmetrical hole, such as a round or square hole, the shortest and longest dimensions will be identical. The units of measure are defined by the attribute finProcessOffsetUnits. punchPattern(83), FinPunchPatternTC INTEGER: Defines the hole pattern produced by the punch process. H. Perforator type-specific attributes (90..) I. Slitter type-specific attributes (100..) slittingType(100), FinSlittingTypeTC INTEGER: Provides additional information regarding the slitting process. J. Separation cutter type-specific attributes (110..) K. Imprinter type-specific attributes (120..) L. Wrapper type-specific attributes (130..) wrappingType(130), FinWrappingTypeTC INTEGER: Provides additional information regarding the wrapping process. M. Bander type-specific attributes (140..) N. Make Envelopes type-specific attributes (150..) O. Stacker type-specific attributes (160..) Bergman, et al. Informational [Page 22] RFC 3806 Printer Finishing MIB June 2004 stackOutputType(160) FinStackOutputTypeTC INTEGER: Defines the job-to-job orientation produced by the stacker. stackOffset(161) Integer32 (-2..2147483647) INTEGER: Defines the copy-to-copy output stack offset as a positive offset distance. The units of measure are defined by finProcessOffsetUnits. stackRotation(162) Integer32 (-2..180) INTEGER: Defines the copy-to-copy output stack rotation measured in degrees. The value is the positive copy-to-copy rotation." 6. Enumerations Enumerations (enums) are sets of symbolic values defined for use with one or more objects. Commonly used enumeration sets are assigned a symbolic data type name (textual convention), rather than being specified in the SYNTAX clause of each individual object definition. Textual conventions defined in the Finisher MIB or the companion IANA Finisher MIB are extensible by RFC publication or Designated Expert Review (see 'IANA Considerations' section of this Finisher MIB and the DESCRIPTION clause in MODULE-IDENTITY of IANA Finisher MIB). All of these textual conventions are: a) used more than once in the Finisher MIB itself; or b) imported and used in any other, including vendor private, MIB modules. The Finisher MIB has also defined the following special values for use with objects of the syntax "Integer32" to define conditions that are outside of the normal numeric range: other(-1), unknown(-2), and partial(-3). The 'partial' value means that there is some supply remaining (but the amount is indeterminate) or there is some capacity remaining (but the amount is indeterminate). The Integer32 range field indicates in which objects these special values are valid. 6.1. Registering Additional Enumerated Values The Finisher MIB and the companion IANA Finisher MIB each defines one category of textual convention, according to the process employed to control the addition of new enumerations: Bergman, et al. Informational [Page 23] RFC 3806 Printer Finishing MIB June 2004 Type 1 - All of the legal values are defined in the Finisher MIB. Additional enumerated values require the publication of a new Finisher MIB. Type 2 - All of the legal values are registered in the IANA Finisher MIB. Additional enumerated values require a Designated Expert Review defined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434]. The Designated Expert will be selected by the IETF Area Director(s) of the Applications Area. 7. IANA Printer Finishing MIB Specification IANA-FINISHER-MIB DEFINITIONS ::= BEGIN -- http://www.iana.org/assignments/ianafinisher-mib IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ianafinisherMIB MODULE-IDENTITY LAST-UPDATED "200406020000Z" -- June 2, 2004 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana@iana.org" DESCRIPTION "This MIB module defines a set of finishing-related TEXTUAL-CONVENTIONs for use in Finisher MIB (RFC 3806) and other MIBs which need to specify finishing mechanism details. Any additions or changes to the contents of this MIB module require either publication of an RFC, or Designated Expert Review as defined in RFC 2434, Guidelines for Writing an IANA Considerations Section in RFCs. The Designated Expert will be selected by the IESG Area Director(s) of the Applications Area. Copyright (C) The Internet Society (2004). The Bergman, et al. Informational [Page 24] RFC 3806 Printer Finishing MIB June 2004 initial version of this MIB module was published in RFC 3806. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" REVISION "200406020000Z" -- June 2, 2004 DESCRIPTION "Original version, published in coordination with Finisher MIB (RFC 3806)." ::= { mib-2 110 } -- TEXTUAL-CONVENTIONs for this MIB module FinDeviceTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined finishing device subunit process enumerations." SYNTAX INTEGER { other(1), unknown(2), stitcher(3), folder(4), binder(5), trimmer(6), dieCutter(7), puncher(8), perforater(9), slitter(10), separationCutter(11), imprinter(12), wrapper(13), bander(14), makeEnvelope(15), stacker(16), sheetRotator(17), inserter(18) } FinAttributeTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TEXTUAL-CONVENTION defines the set of enums for use in the finDeviceAttributeTable. See section 5.7 for the complete specification of each attribute." SYNTAX INTEGER { other(1), deviceName(3), Bergman, et al. Informational [Page 25] RFC 3806 Printer Finishing MIB June 2004 deviceVendorName(4), deviceModel(5), deviceVersion(6), deviceSerialNumber(7), maximumSheets(8), finProcessOffsetUnits(9), finReferenceEdge(10), finAxisOffset(11), finJogEdge(12), finHeadLocation(13), finOperationRestrictions(14), finNumberOfPositions(15), namedConfiguration(16), finMediaTypeRestriction(17), finPrinterInputTraySupported(18), finPreviousFinishingOperation(19), finNextFinishingOperation(20), stitchingType(30), stitchingDirection(31), foldingType(40), bindingType(50), punchHoleType(80), punchHoleSizeLongDim(81), punchHoleSizeShortDim(82), punchPattern(83), slittingType(100), wrappingType(130), stackOutputType(160), stackOffset(161), stackRotation(162) } FinEdgeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies an edge for a Finishing Process." SYNTAX INTEGER { topEdge(3), bottomEdge(4), leftEdge(5), rightEdge(6) } FinStitchingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined stitching type enumerations. For the edgeStitch and stapleDual enums, the finReferenceEdge attribute is recommended Bergman, et al. Informational [Page 26] RFC 3806 Printer Finishing MIB June 2004 to define the edge to which the operation applies." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), stapleTopLeft(4), stapleBottomLeft(5), stapleTopRight(6), stapleBottomRight(7), saddleStitch(8), edgeStitch(9), stapleDual(10) } FinStitchingDirTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Defines the direction, relative to the top sheet in the output subunit, that the stitching operation was performed. For a topDown(3) process, the staple will be clinched on the bottom of the stack. This parameter can be used to determine what order the pages of a booklet are to be printed such that the staple clinch will be on the inside of the resulting booklet." SYNTAX INTEGER { unknown(2), topDown(3), bottomUp(4) } FinStitchingAngleTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This enumeration provides a description of the angular orientation of each stitch in a single or multiple stitching operation, relative to the 'X' axis. As with all finishing operations, the 'X' axis is always relative to the portrait orientation of the document regardless of the orientation of the printed image. This enum is primarily applicable to corner stitching operations." SYNTAX INTEGER { unknown(2), horizontal(3), vertical(4), slanted(5) } FinFoldingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Bergman, et al. Informational [Page 27] RFC 3806 Printer Finishing MIB June 2004 "The defined folding device process enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), zFold(3), halfFold(4), letterFold(5) } FinBindingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined binding type enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), tape(4), plastic(5), velo(6), perfect(7), spiral(8), adhesive(9), comb(10), padding(11) } FinPunchHoleTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined hole type punch process enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), round(3), oblong(4), square(5), rectangular(6), star(7) } FinPunchPatternTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined hole pattern punch process enumerations." SYNTAX INTEGER { other(1), --Pattern to be defined in other attributes unknown(2), twoHoleUSTop(4), --Letter/legal, 8.5 inch edge Bergman, et al. Informational [Page 28] RFC 3806 Printer Finishing MIB June 2004 threeHoleUS(5), --Letter/ledger, 11 inch edge twoHoleDIN(6), --A4/A3, 297 mm edge fourHoleDIN(7), --A4/A3, 297 mm edge twentyTwoHoleUS(8), --Letter/ledger, 11 inch edge nineteenHoleUS(9), --Letter/ledger, 11 inch edge twoHoleMetric(10), --B5/B4, 257 mm edge swedish4Hole(11), --A4/A3, 297 mm edge twoHoleUSSide(12), --Letter/ledger, 11 inch edge fiveHoleUS(13), --Letter/ledger, 11 inch edge sevenHoleUS(14), --Letter/ledger, 11 inch edge mixed7H4S(15), --A4/A3, 297 mm edge norweg6Hole(16), --A4/A3, 297 mm edge metric26Hole(17), --B5/B4, 257 mm edge metric30Hole(18) --A4/A3, 297 mm edge } FinSlittingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined slitting type enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), slitAndSeparate(4), slitAndMerge(5) } FinWrappingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined wrapping device process enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), shrinkWrap(4), paperWrap(5) } FinStackOutputTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The defined stack output type enumerations." SYNTAX INTEGER { other(1), -- More information in other attributes unknown(2), straight(4), -- No offset, one on top of another offset(5), crissCross(6) -- Rotated Bergman, et al. Informational [Page 29] RFC 3806 Printer Finishing MIB June 2004 } END 8. Printer Finishing MIB Specification Finisher-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] hrDeviceIndex FROM HOST-RESOURCES-MIB -- [RFC2790] PrtInputTypeTC, PrtMarkerSuppliesTypeTC FROM IANA-PRINTER-MIB -- [RFC3805] printmib, PrtSubUnitStatusTC, PrtLocalizedDescriptionStringTC, PrtMarkerSuppliesSupplyUnitTC, PrtMediaUnitTC, PrtCapacityUnitTC, PrtMarkerSuppliesClassTC, PresentOnOff, prtMIBConformance FROM Printer-MIB -- [RFC3805] FinDeviceTypeTC, FinAttributeTypeTC FROM IANA-FINISHER-MIB; finisherMIB MODULE-IDENTITY LAST-UPDATED "200406020000Z" ORGANIZATION "PWG IEEE/ISTO Printer Working Group" CONTACT-INFO "Harry Lewis IBM Phone (303) 924-5337 Email: harryl@us.ibm.com Send comments to the printmib WG using the Finisher MIB Project (FIN) Mailing List: fin@pwg.org For further information, access the PWG web page under 'Finisher MIB': http://www.pwg.org/ Implementers of this specification are encouraged to join the fin mailing list in order to participate in discussions on any clarifications needed and registration proposals being reviewed in order to achieve consensus." DESCRIPTION "The MIB module for management of printers. Copyright (C) The Internet Society (2004). This version of this MIB module was published Bergman, et al. Informational [Page 30] RFC 3806 Printer Finishing MIB June 2004 in RFC 3806. For full legal notices see the RFC itself." REVISION "200406020000Z" DESCRIPTION "The original version of this MIB." ::= { mib-2 111 } -- Finisher Device Group (Mandatory) -- -- A printer may support zero or more finishing subunits. A -- finishing device subunit may be associated with one or more -- output subunits and one or more media path subunits. finDevice OBJECT IDENTIFIER ::= { printmib 30 } finDeviceTable OBJECT-TYPE SYNTAX SEQUENCE OF FinDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the finishing device subunits, including information regarding possible configuration options and the status for each finisher device subunit." ::= { finDevice 1 } finDeviceEntry OBJECT-TYPE SYNTAX FinDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There is an entry in the finishing device table for each possible finisher process. Each individual finisher process is implemented by a finishing device represented in this table." INDEX { hrDeviceIndex, finDeviceIndex } ::= { finDeviceTable 1 } FinDeviceEntry ::= SEQUENCE { finDeviceIndex Integer32, finDeviceType FinDeviceTypeTC, finDevicePresentOnOff PresentOnOff, finDeviceCapacityUnit PrtCapacityUnitTC, finDeviceMaxCapacity Integer32, finDeviceCurrentCapacity Integer32, finDeviceAssociatedMediaPaths OCTET STRING, finDeviceAssociatedOutputs OCTET STRING, finDeviceStatus PrtSubUnitStatusTC, finDeviceDescription PrtLocalizedDescriptionStringTC } Bergman, et al. Informational [Page 31] RFC 3806 Printer Finishing MIB June 2004 finDeviceIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used to identify a finisher process. Although these values may change due to a major reconfiguration of the printer system (e.g., the addition of new finishing processes), the values are normally expected to remain stable across successive power cycles." ::= { finDeviceEntry 1 } finDeviceType OBJECT-TYPE SYNTAX FinDeviceTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the type of finishing process associated with this table row entry." ::= { finDeviceEntry 2 } finDevicePresentOnOff OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if this finishing device subunit is available and whether the device subunit is enabled." DEFVAL { notPresent } ::= { finDeviceEntry 3 } finDeviceCapacityUnit OBJECT-TYPE SYNTAX PrtCapacityUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measure for specifying the capacity of this finisher device subunit." ::= { finDeviceEntry 4 } finDeviceMaxCapacity OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum capacity of this finisher device subunit in finDeviceCapacityUnits. If the device can reliably sense this value, the value is sensed by the finisher device Bergman, et al. Informational [Page 32] RFC 3806 Printer Finishing MIB June 2004 and is read-only: otherwise the value may be written by a management or control console application. The value (-1) means other and specifically indicates that the device places no restrictions on this parameter. The value (-2) means unknown." DEFVAL { -2 } -- unknown ::= { finDeviceEntry 5 } finDeviceCurrentCapacity OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The current capacity of this finisher device subunit in finDeviceCapacityUnits. If the device can reliably sense this value, the value is sensed by the finisher and is read-only: otherwise the value may be written by a management or control console application. The value (-1) means other and specifically indicates that the device places no restrictions on this parameter. The value (-2) means unknown." DEFVAL { -2 } -- unknown ::= { finDeviceEntry 6 } finDeviceAssociatedMediaPaths OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the media paths which can supply media for this finisher device. The value of this object is a bit map in an octet string with each position representing the value of a prtMediaPathIndex. For a media path that can be a source for this finisher device subunit, the bit position equal to one less than the value of prtMediaPathIndex will be set. The bits are numbered starting with the most significant bit of the first byte being bit 0, the least significant bit of the first byte being bit 7, the most significant of the second byte being bit 8, and so on." ::= { finDeviceEntry 7 } finDeviceAssociatedOutputs OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the printer output subunits this finisher device subunit services. The value of this object is a bit map in an Bergman, et al. Informational [Page 33] RFC 3806 Printer Finishing MIB June 2004 octet string with each position representing the value of a prtOutputIndex. For an output subunit that is serviced by this finisher device subunit, the bit position equal to one less than the value of prtOutputIndex will be set. The bits are numbered starting with the most significant bit of the first byte being bit 0, the least significant bit of the first byte being bit 7, the most significant of the second byte being bit 8, and so on." ::= { finDeviceEntry 8 } finDeviceStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current status of this finisher device subunit." DEFVAL { 5 } -- unknown ::= { finDeviceEntry 9 } finDeviceDescription OBJECT-TYPE SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "A free form text description of this device subunit in the localization specified by prtGeneralCurrentLocalization." ::= { finDeviceEntry 10 } -- Finisher Supply Group (Mandatory) -- -- A finisher device, but not all finisher devices, may have one or more -- supplies associated with it. For example a finisher may use both -- binding tape and stitching wire supplies. A finisher may also have -- more than one source for a given type of supply e.g., multiple supply -- sources of ink for imprinters. finSupply OBJECT IDENTIFIER ::= { printmib 31 } finSupplyTable OBJECT-TYPE SYNTAX SEQUENCE OF FinSupplyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each unique source of supply is an entry in the finisher supply table. Each supply entry has its own characteristics associated with it such as colorant and Bergman, et al. Informational [Page 34] RFC 3806 Printer Finishing MIB June 2004 current supply level." ::= { finSupply 1 } finSupplyEntry OBJECT-TYPE SYNTAX FinSupplyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of finisher devices, with their associated supplies and supplies characteristics." INDEX { hrDeviceIndex, finSupplyIndex } ::= { finSupplyTable 1 } FinSupplyEntry ::= SEQUENCE { finSupplyIndex Integer32, finSupplyDeviceIndex Integer32, finSupplyClass PrtMarkerSuppliesClassTC, finSupplyType PrtMarkerSuppliesTypeTC, finSupplyDescription PrtLocalizedDescriptionStringTC, finSupplyUnit PrtMarkerSuppliesSupplyUnitTC, finSupplyMaxCapacity Integer32, finSupplyCurrentLevel Integer32, finSupplyColorName OCTET STRING } finSupplyIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by a finisher to identify this supply container/receptacle. Although these values may change due to a major reconfiguration of the finisher (e.g., the addition of new supply sources to the finisher), values are normally expected to remain stable across successive power cycles." ::= { finSupplyEntry 1 } finSupplyDeviceIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of finDeviceIndex corresponding to the finishing device subunit with which this finisher supply is associated. The value zero indicates the associated finishing device is Unknown." ::= { finSupplyEntry 2 } Bergman, et al. Informational [Page 35] RFC 3806 Printer Finishing MIB June 2004 finSupplyClass OBJECT-TYPE SYNTAX PrtMarkerSuppliesClassTC MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates whether this supply entity represents a supply that is consumed or a container that is filled." ::= { finSupplyEntry 3 } finSupplyType OBJECT-TYPE SYNTAX PrtMarkerSuppliesTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this supply." ::= { finSupplyEntry 4 } finSupplyDescription OBJECT-TYPE SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "The description of this supply/receptacle in text useful for operators and management applications and in the localization specified by prtGeneralCurrentLocalization." ::= { finSupplyEntry 5 } finSupplyUnit OBJECT-TYPE SYNTAX PrtMarkerSuppliesSupplyUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "Unit of measure of this finisher supply container or receptacle." ::= { finSupplyEntry 6 } finSupplyMaxCapacity OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum capacity of this supply container/receptacle expressed in Supply Units. If this supply container/ receptacle can reliably sense this value, the value is sensed and is read-only; otherwise the value may be written by a control panel or management application. The value (-1) means other and places no restrictions on this Bergman, et al. Informational [Page 36] RFC 3806 Printer Finishing MIB June 2004 parameter. The value (-2) means unknown." DEFVAL { -2 } -- unknown ::= { finSupplyEntry 7 } finSupplyCurrentLevel OBJECT-TYPE SYNTAX Integer32 (-3..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The current level if this supply is a container; the remaining space if this supply is a receptacle. If this supply container/receptacle can reliably sense this value, the value is sensed and is read-only; otherwise the value may be written by a control panel or management application. The value (-1) means other and places no restrictions on this parameter. The value (-2) means unknown. A value of (-3) means that the printer knows there is some supply or remaining space." DEFVAL { -2 } -- unknown ::= { finSupplyEntry 8 } -- Capacity Attribute Relationships -- -- MEDIA INPUT MEASUREMENT -- -- _______ | | -- | | | -- | | | | -- | |_ _ _ _ _ _ _ _ _ _| ________________ |direction -- | | | | v -- MaxCapacity | | | -- | | Sheets remaining | CurrentLevel -- | | | | -- v | | v -- _______ +___________________+ _______ finSupplyColorName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the color associated with this supply." REFERENCE "The PWG Standardized Media Names specification [PWGMEDIA], section 4 Media Color Names, contains the recommended values Bergman, et al. Informational [Page 37] RFC 3806 Printer Finishing MIB June 2004 for this object. Implementers may add additional string values. The naming conventions in ISO 9070 are recommended in order to avoid potential name clashes." ::= { finSupplyEntry 9 } -- Finisher Supply, Media Input Group (Conditionally Mandatory) -- -- A finisher device may have one or more associated supply media -- inputs. Each entry in this table defines an input for a -- supply media type such as inserts, covers, etc. -- -- This group is mandatory only if the printer system contains a -- finisher device that requires a media supply used exclusively by a -- finishing process. Examples are inserts or covers that are not -- supplied by an input subunit that provides media to the marker. finSupplyMediaInput OBJECT IDENTIFIER ::= { printmib 32 } finSupplyMediaInputTable OBJECT-TYPE SYNTAX SEQUENCE OF FinSupplyMediaInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The input subunits associated with a finisher supply media are each represented by an entry in this table." ::= { finSupplyMediaInput 1 } finSupplyMediaInputEntry OBJECT-TYPE SYNTAX FinSupplyMediaInputEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of finisher supply media input subunit features and characteristics." INDEX { hrDeviceIndex, finSupplyMediaInputIndex } ::= { finSupplyMediaInputTable 1 } FinSupplyMediaInputEntry ::= SEQUENCE { finSupplyMediaInputIndex Integer32, finSupplyMediaInputDeviceIndex Integer32, finSupplyMediaInputSupplyIndex Integer32, finSupplyMediaInputType PrtInputTypeTC, finSupplyMediaInputDimUnit PrtMediaUnitTC, finSupplyMediaInputMediaDimFeedDir Integer32, finSupplyMediaInputMediaDimXFeedDir Integer32, finSupplyMediaInputStatus PrtSubUnitStatusTC, finSupplyMediaInputMediaName OCTET STRING, Bergman, et al. Informational [Page 38] RFC 3806 Printer Finishing MIB June 2004 finSupplyMediaInputName OCTET STRING, finSupplyMediaInputDescription PrtLocalizedDescriptionStringTC, finSupplyMediaInputSecurity PresentOnOff, finSupplyMediaInputMediaWeight Integer32, finSupplyMediaInputMediaThickness Integer32, finSupplyMediaInputMediaType OCTET STRING } finSupplyMediaInputIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by a finisher to identify this supply media input subunit. Although these values may change due to a major reconfiguration of the finisher (e.g., the addition of new supply media input sources to the finisher), values are normally expected to remain stable across successive power cycles." ::= { finSupplyMediaInputEntry 1 } finSupplyMediaInputDeviceIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of finDeviceIndex corresponding to the finishing device subunit with which this finisher media supply is associated. The value zero indicates the associated device is unknown." ::= { finSupplyMediaInputEntry 2 } finSupplyMediaInputSupplyIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of finSupplyIndex corresponding to the finishing supply subunit with which this finisher media supply is associated. The value zero indicates the associated finishing supply is unknown or there is no applicable finisher supply table entry." ::= { finSupplyMediaInputEntry 3 } finSupplyMediaInputType OBJECT-TYPE SYNTAX PrtInputTypeTC MAX-ACCESS read-only STATUS current Bergman, et al. Informational [Page 39] RFC 3806 Printer Finishing MIB June 2004 DESCRIPTION "The type of technology (discriminated primarily according to the feeder mechanism type) employed by the input subunit." ::= { finSupplyMediaInputEntry 4 } finSupplyMediaInputDimUnit OBJECT-TYPE SYNTAX PrtMediaUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measure for specifying dimensional values for this input device." ::= { finSupplyMediaInputEntry 5 } finSupplyMediaInputMediaDimFeedDir OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the value of the dimension in the feed direction of the media that is placed or will be placed in this input device. Feed dimension measurements are taken parallel to the feed direction of the device and measured in finSupplyMediaInputDimUnits. If this input device can reliably sense this value, the value is sensed and is read-only access. Otherwise the value is read-write access and may be written by management or control panel applications. The value (-1) means other and specifically indicates that this device places no restrictions on this parameter. The value (-2) indicates unknown. " ::= { finSupplyMediaInputEntry 6 } finSupplyMediaInputMediaDimXFeedDir OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the value of the dimension across the feed direction of the media that is placed or will be placed in this input device. The cross feed direction is ninety degrees relative to the feed direction on this device and measured in finSupplyMediaInputDimUnits. If this input device can reliably sense this value, the value is sensed and is read-only access. Otherwise the value is read-write access and may be written by management or control panel applications. The value (-1) means other and specifically indicates that this device places no Bergman, et al. Informational [Page 40] RFC 3806 Printer Finishing MIB June 2004 restrictions on this parameter. The value (-2) indicates unknown. " ::= { finSupplyMediaInputEntry 7 } finSupplyMediaInputStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the current status of this input device." DEFVAL { 5 } -- unknown ::= { finSupplyMediaInputEntry 8 } finSupplyMediaInputMediaName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name of the current media contained in this input device. Examples are Engineering Manual Cover, Section A Tab Divider or any ISO standard names." ::= { finSupplyMediaInputEntry 9 } finSupplyMediaInputName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name assigned to this input subunit." ::= { finSupplyMediaInputEntry 10 } finSupplyMediaInputDescription OBJECT-TYPE SYNTAX PrtLocalizedDescriptionStringTC MAX-ACCESS read-only STATUS current DESCRIPTION "A free form text description of this input subunit in the localization specified by prtGeneralCurrentLocalization." ::= { finSupplyMediaInputEntry 11 } finSupplyMediaInputSecurity OBJECT-TYPE SYNTAX PresentOnOff MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if this subunit has some security associated with it." Bergman, et al. Informational [Page 41] RFC 3806 Printer Finishing MIB June 2004 ::= { finSupplyMediaInputEntry 12 } finSupplyMediaInputMediaWeight OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The weight of the media associated with this Input device in grams per meter squared. The value (-1) means other and specifically indicates that the device places no restriction on this parameter. The value (-2) means unknown. This object can be used to calculate the weight of individual pages processed by the document finisher. This value, when multiplied by the number of pages in a finished set, can be used to calculate the weight of a set before it is inserted into a mailing envelope." ::= { finSupplyMediaInputEntry 13 } finSupplyMediaInputMediaThickness OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the thickness of the input media processed by this document input subunit measured in micrometers. This value may be used by devices (or operators) to set up proper machine tolerances for the feeder operation. The value (-2) indicates that the media thickness is unknown or not used in the setup for this input subunit." ::= { finSupplyMediaInputEntry 14 } finSupplyMediaInputMediaType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name of the type of medium associated with this input subunit. " REFERENCE "The PWG Standardized Media Names specification [PWGMEDIA], section 3 Media Type Names, contains the recommended values for this object. Implementers may add additional string values. The naming conventions in ISO 9070 are recommended in order to avoid potential name clashes." ::= { finSupplyMediaInputEntry 15 } Bergman, et al. Informational [Page 42] RFC 3806 Printer Finishing MIB June 2004 -- Finisher Device Attribute Group (Mandatory) -- -- A finisher device subunit may have one or more parameters that -- cannot be specified by any other objects in the MIB. The -- Device Attribute group facilitates the definition of these -- parameters. The objects which define the attributes are -- read-write, to allow both Set and Get operations. -- -- At least one table entry must exist for each finisher device defined -- by the MIB. If no other entry is possible for a finisher device, the -- deviceName(3) attribute MUST be returned. finDeviceAttribute OBJECT IDENTIFIER ::= { printmib 33 } finDeviceAttributeTable OBJECT-TYPE SYNTAX SEQUENCE OF FinDeviceAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The attribute table defines special parameters that are applicable only to a minority of the finisher devices. An attribute table entry is used, rather than unique objects, to minimize the number of MIB objects and to allow for expansion without the addition of MIB objects. Each finisher device is represented by a separate row in the device subunit attribute table." ::= { finDeviceAttribute 1 } finDeviceAttributeEntry OBJECT-TYPE SYNTAX FinDeviceAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines a finisher function parameter that cannot be represented by an object in the finisher device subunit table." INDEX { hrDeviceIndex, finDeviceIndex, finDeviceAttributeTypeIndex, finDeviceAttributeInstanceIndex } ::= { finDeviceAttributeTable 1 } FinDeviceAttributeEntry ::= SEQUENCE { finDeviceAttributeTypeIndex FinAttributeTypeTC, finDeviceAttributeInstanceIndex Integer32, finDeviceAttributeValueAsInteger Integer32, finDeviceAttributeValueAsOctets OCTET STRING } Bergman, et al. Informational [Page 43] RFC 3806 Printer Finishing MIB June 2004 finDeviceAttributeTypeIndex OBJECT-TYPE SYNTAX FinAttributeTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the attribute type represented by this row." ::= { finDeviceAttributeEntry 1 } finDeviceAttributeInstanceIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that allows the discrimination of an attribute instance when the same attribute occurs multiple times for a specific instance of a finisher function. The value of this index shall be 1 if only a single instance of the attribute occurs for the specific finisher function. Additional values shall be assigned in a contiguous manner." ::= { finDeviceAttributeEntry 2 } finDeviceAttributeValueAsInteger OBJECT-TYPE SYNTAX Integer32 (-2..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "Defines the integer value of the attribute. The value of the attribute is represented as an integer if the finAttributeTypeTC description for the attribute has the tag 'INTEGER:'. Depending upon the attribute enum definition, this object may be either an integer, a counter, an index, or an enum. Attributes for which the concept of an integer value is not meaningful SHALL return a value of -1 for this attribute." DEFVAL { -2 } -- unknown ::= { finDeviceAttributeEntry 3 } finDeviceAttributeValueAsOctets OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-write STATUS current DESCRIPTION "Contains the octet string value of the attribute. The value of the attribute is represented as a string if the finAttributeTypeTC description for the attribute has the tag 'OCTETS:'. Bergman, et al. Informational [Page 44] RFC 3806 Printer Finishing MIB June 2004 Depending upon the attribute enum definition, this object may be either a coded character set string (text) or a binary octet string. Attributes for which the concept of an octet string value is not meaningful SHALL contain a zero length string." DEFVAL { ''H } -- empty string ::= { finDeviceAttributeEntry 4 } -- Conformance Information -- compliance statements finMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the finisher MIB." MODULE -- this module MANDATORY-GROUPS { finDeviceGroup, finSupplyGroup, finDeviceAttributeGroup } OBJECT finDevicePresentOnOff MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finDeviceMaxCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finDeviceCurrentCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMaxCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyCurrentLevel MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputMediaDimFeedDir Bergman, et al. Informational [Page 45] RFC 3806 Printer Finishing MIB June 2004 MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputMediaDimXFeedDir MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputMediaName MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputName MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputSecurity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputMediaWeight MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputMediaThickness MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finSupplyMediaInputMediaType MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finDeviceAttributeValueAsInteger MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT finDeviceAttributeValueAsOctets MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." Bergman, et al. Informational [Page 46] RFC 3806 Printer Finishing MIB June 2004 GROUP finSupplyMediaInputGroup DESCRIPTION "This group is conditionally mandatory and must be included if a finisher device requires a media supply that is used exclusively by a finishing process." ::= { prtMIBConformance 5 } finMIBGroups OBJECT IDENTIFIER ::= { prtMIBConformance 6 } finDeviceGroup OBJECT-GROUP OBJECTS { finDeviceType, finDevicePresentOnOff, finDeviceCapacityUnit, finDeviceMaxCapacity, finDeviceCurrentCapacity, finDeviceAssociatedMediaPaths, finDeviceAssociatedOutputs, finDeviceStatus, finDeviceDescription } STATUS current DESCRIPTION "The finisher device group." ::= { finMIBGroups 1 } finSupplyGroup OBJECT-GROUP OBJECTS { finSupplyDeviceIndex, finSupplyClass, finSupplyType, finSupplyDescription, finSupplyUnit, finSupplyMaxCapacity, finSupplyCurrentLevel, finSupplyColorName } STATUS current DESCRIPTION "The finisher supply group." ::= { finMIBGroups 2 } finSupplyMediaInputGroup OBJECT-GROUP OBJECTS { finSupplyMediaInputDeviceIndex, finSupplyMediaInputSupplyIndex, finSupplyMediaInputType, finSupplyMediaInputDimUnit, finSupplyMediaInputMediaDimFeedDir, finSupplyMediaInputMediaDimXFeedDir, finSupplyMediaInputStatus, finSupplyMediaInputMediaName, finSupplyMediaInputName, finSupplyMediaInputDescription, finSupplyMediaInputSecurity, finSupplyMediaInputMediaWeight, finSupplyMediaInputMediaThickness, finSupplyMediaInputMediaType } STATUS current DESCRIPTION "The finisher supply, media input group." ::= { finMIBGroups 3 } Bergman, et al. Informational [Page 47] RFC 3806 Printer Finishing MIB June 2004 finDeviceAttributeGroup OBJECT-GROUP OBJECTS { finDeviceAttributeValueAsInteger, finDeviceAttributeValueAsOctets } STATUS current DESCRIPTION "The finisher device attribute group. This group is mandatory for a finisher device that contains an inserter subunit." ::= { finMIBGroups 4 } END 9. IANA Considerations The initial version of the IANA Finisher MIB defined in section 7 of this document is to be archived by IANA and subsequently maintained according to the Process specified in section 6.1 of this document. The most current and authoritative version of the IANA Finisher MIB is available at: http://www.iana.org/assignments/ianafinisher-mib 10. Internationalization Considerations See the Printer MIB [RFC3805] section 2.2.1.1, 'International Considerations'. 11. References 11.1. Normative References [DPA] ISO/IEC 10175 Document Printing Application (DPA). See ftp://ftp.pwg.org/pub/pwg/dpa/ [LMO] Large Mailing Operations Specification, DMTF. See http://www.dmtf.org/tech/apps.html [PWGMEDIA] IEEE-ISTO PWG "The Printer Working Group Standard for Media Standardized Names", IEEE-ISTO PWG 5101.1-2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Bergman, et al. Informational [Page 48] RFC 3806 Printer Finishing MIB June 2004 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. [RFC3805] Bergman, R., Lewis, H., and I. McDonald, "The Printer MIB v2", RFC 3805, June 2004. 11.2. Informative References [RFC2911] Hastings, T. Ed., Herriot, R., deBry, R., Issacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 12. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: finDeviceTable: finDevicePresentOnOff -Possible severe inconvenience finDeviceMaxCapacity -Possible minor inconvenience finDeviceCurrentCapacity -Possible minor inconvenience finSupplyTable: finSupplyMaxCapacity -Possible minor inconvenience Bergman, et al. Informational [Page 49] RFC 3806 Printer Finishing MIB June 2004 finSupplyCurrentLevel -Possible minor inconvenience finSupplyMediaInputTable finSupplyMediaInputMediaDimFeedDir -Possible severe inconvenience finSupplyMediaInputMediaDimXFeedDir -Possible severe inconvenience finSupplyMediaInputMediaName -Possible Minor inconvenience finSupplyMediaInputName -Possible Minor inconvenience finSupplyMediaInputSecurity -Possible Minor inconvenience finSupplyMediaInputMediaWeight -Possible Minor inconvenience finSupplyMediaInputMediaThickness -Possible Minor inconvenience finSupplyMediaInputMediaType -Possible Minor inconvenience finDeviceAttributeTable finDeviceAttributeValueAsInteger -Possible Minor inconvenience finDeviceAttributeValueAsOctets -Possible Minor inconvenience SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Where the operational capability of the printing device are especially vulnerable or difficult to administer, certain objects within this MIB have been tagged as READ-ONLY, preventing modification. Further, for all READ-WRITE objects within the MIB, the working group has included specific conformance guidelines stating that vendors are free to implement certain objects as READ-ONLY. This conformance allowance should cover cases where specific vendor vulnerabilities may differ from product to product. (See conformance section with regards to MIN-ACCESS clauses). Bergman, et al. Informational [Page 50] RFC 3806 Printer Finishing MIB June 2004 13. Acknowledgements The Printer MIB Working Group would like to extend a special thank you to the following individuals that put forth a significant effort to review this document and provide numerous suggestions for improvement. David Harrington - Enterasys Networks Juergen Schoenwaelder - TU Braunschweig Bert Wijnen - Lucent Technologies and IETF Op & Mngmt, Area Director Other Participants: Chuck Adams - Tektronix Carlos Becerra - HP Andy Davidson - Tektronix Mabry Dozier - QMS Lee Farrell - Canon Jennifer Gattis - Duplo USA Paul Gloger - Xerox Richard Hart - Digital Tom Hastings - Xerox Scott Isaacson - Novell David Kellerman - Northlake Software Henrik Holst - i-data International Rick Landau - Digital Jay Martin - Underscore Gary Padlipski - Xerox Kevin Palmer - Duplo USA Bob Pentecost - HP Stuart Rowley - Kyocera Yuki Sacchi - Japan Computer Industry Philip Thambidunai - Okidata William Wagner - DPI/Osicom Chris Wellens - Interworking Labs Don Wright - Lexmark Lloyd Young - Lexmark Bergman, et al. Informational [Page 51] RFC 3806 Printer Finishing MIB June 2004 14. Authors' Addresses Ron Bergman (Editor) Hitachi Printing Solutions America 2635 Park Center Drive Simi Valley, CA 93065-6209 Phone: 805-578-4421 Fax: 805-578-4001 EMail: Ron.Bergman@hitachi-ps.us Harry Lewis (Chairman) IBM Corporation 6300 Diagonal Hwy Boulder, CO 80301 Phone: (303) 924-5337 EMail: harryl@us.ibm.com Ira McDonald High North Inc. P.O. Box 221 Grand Marais, MI 49839 Phone: (906) 494-2434 or (906) 494-2697 EMail: imcdonald@sharplabs.com Send comments to the Printer Working Group (PWG) using the Finisher MIB Project (FIN) Mailing List: fin@pwg.org Implementers of this specification are encouraged to join this email distribution list in order to participate in any discussions of clarification issues and review registration proposals for additional attributes and enum values. For further information, access the PWG web page under "FIN": http://www.pwg.org/ Bergman, et al. Informational [Page 52] RFC 3806 Printer Finishing MIB June 2004 15. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bergman, et al. Informational [Page 53] snmp-mibs-downloader-1.1/mibrfcs/rfc3811.txt0000644000000000000000000011664111402176071015567 0ustar Network Working Group T. Nadeau, Ed. Request for Comments: 3811 Cisco Systems, Inc. Category: Standards Track J. Cucchiara, Ed. Marconi Communications, Inc. June 2004 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework. . . . . . . . . . 2 3. MPLS Textual Conventions MIB Definitions. . . . . . . . . . . 2 4. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Normative References. . . . . . . . . . . . . . . . . . 16 4.2. Informative References. . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 18 8 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 19 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 20 Nadeau & Cucchiara Standards Track [Page 1] RFC 3811 MPLS TC MIB June 2004 1. Introduction This document defines a MIB module which contains Textual Conventions for Multiprotocol Label Switching (MPLS) networks. These Textual Conventions should be imported by MIB modules which manage MPLS networks. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. For an introduction to the concepts of MPLS, see [RFC3031]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. MPLS Textual Conventions MIB Definitions MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Unsigned32, Integer32, transmission FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] mplsTCStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "IETF Multiprotocol Label Switching (MPLS) Working Group." CONTACT-INFO " Thomas D. Nadeau Nadeau & Cucchiara Standards Track [Page 2] RFC 3811 MPLS TC MIB June 2004 Cisco Systems, Inc. tnadeau@cisco.com Joan Cucchiara Marconi Communications, Inc. jcucchiara@mindspring.com Cheenu Srinivasan Bloomberg L.P. cheenu@bloomberg.net Arun Viswanathan Force10 Networks, Inc. arunv@force10networks.com Hans Sjostrand ipUnplugged hans@ipunplugged.com Kireeti Kompella Juniper Networks kireeti@juniper.net Email comments to the MPLS WG Mailing List at mpls@uu.net." DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3811. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB module defines TEXTUAL-CONVENTIONs for concepts used in Multiprotocol Label Switching (MPLS) networks." REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version published as part of RFC 3811." ::= { mplsStdMIB 1 } mplsStdMIB OBJECT IDENTIFIER ::= { transmission 166 } MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" Nadeau & Cucchiara Standards Track [Page 3] RFC 3811 MPLS TC MIB June 2004 STATUS current DESCRIPTION "A Label Switching Router (LSR) that creates LDP sessions on ATM interfaces uses the VCI or VPI/VCI field to hold the LDP Label. VCI values MUST NOT be in the 0-31 range. The values 0 to 31 are reserved for other uses by the ITU and ATM Forum. The value of 32 can only be used for the Control VC, although values greater than 32 could be configured for the Control VC. If a value from 0 to 31 is used for a VCI the management entity controlling the LDP subsystem should reject this with an inconsistentValue error. Also, if the value of 32 is used for a VC which is NOT the Control VC, this should result in an inconsistentValue error." REFERENCE "MPLS using LDP and ATM VC Switching, RFC3035." SYNTAX Integer32 (32..65535) MplsBitRate ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "If the value of this object is greater than zero, then this represents the bandwidth of this MPLS interface (or Label Switched Path) in units of '1,000 bits per second'. The value, when greater than zero, represents the bandwidth of this MPLS interface (rounded to the nearest 1,000) in units of 1,000 bits per second. If the bandwidth of the MPLS interface is between ((n * 1000) - 500) and ((n * 1000) + 499), the value of this object is n, such that n > 0. If the value of this object is 0 (zero), this means that the traffic over this MPLS interface is considered to be best effort." SYNTAX Unsigned32 (0|1..4294967295) MplsBurstSize ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" Nadeau & Cucchiara Standards Track [Page 4] RFC 3811 MPLS TC MIB June 2004 STATUS current DESCRIPTION "The number of octets of MPLS data that the stream may send back-to-back without concern for policing. The value of zero indicates that an implementation does not support Burst Size." SYNTAX Unsigned32 (0..4294967295) MplsExtendedTunnelId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for an MPLS Tunnel. This may represent an IPv4 address of the ingress or egress LSR for the tunnel. This value is derived from the Extended Tunnel Id in RSVP or the Ingress Router ID for CR-LDP." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209]. Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX Unsigned32(0..4294967295) MplsLabel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This value represents an MPLS label as defined in [RFC3031], [RFC3032], [RFC3034], [RFC3035] and [RFC3471]. The label contents are specific to the label being represented, such as: * The label carried in an MPLS shim header (for LDP this is the Generic Label) is a 20-bit number represented by 4 octets. Bits 0-19 contain a label or a reserved label value. Bits 20-31 MUST be zero. The following is quoted directly from [RFC3032]. There are several reserved label values: i. A value of 0 represents the 'IPv4 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the Nadeau & Cucchiara Standards Track [Page 5] RFC 3811 MPLS TC MIB June 2004 IPv4 header. ii. A value of 1 represents the 'Router Alert Label'. This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual forwarding of the packet is determined by the label beneath it in the stack. However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the 'Router Alert Option' in IP packets [RFC2113]. Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol. iii. A value of 2 represents the 'IPv6 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header. iv. A value of 3 represents the 'Implicit NULL Label'. This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is 'Implicit NULL', the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is reserved. v. Values 4-15 are reserved. * The frame relay label can be either 10-bits or Nadeau & Cucchiara Standards Track [Page 6] RFC 3811 MPLS TC MIB June 2004 23-bits depending on the DLCI field size and the upper 22-bits or upper 9-bits must be zero, respectively. * For an ATM label the lower 16-bits represents the VCI, the next 12-bits represents the VPI and the remaining bits MUST be zero. * The Generalized-MPLS (GMPLS) label contains a value greater than 2^24-1 and used in GMPLS as defined in [RFC3471]." REFERENCE "Multiprotocol Label Switching Architecture, RFC3031. MPLS Label Stack Encoding, [RFC3032]. Use of Label Switching on Frame Relay Networks, RFC3034. MPLS using LDP and ATM VC Switching, RFC3035. Generalized Multiprotocol Label Switching (GMPLS) Architecture, [RFC3471]." SYNTAX Unsigned32 (0..4294967295) MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The label distribution method which is also called the label advertisement mode [RFC3036]. Each interface on an LSR is configured to operate in either Downstream Unsolicited or Downstream on Demand." REFERENCE "Multiprotocol Label Switching Architecture, RFC3031. LDP Specification, RFC3036, Section 2.6.3." SYNTAX INTEGER { downstreamOnDemand(1), downstreamUnsolicited(2) } MplsLdpIdentifier ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d:2d" STATUS current DESCRIPTION "The LDP identifier is a six octet Nadeau & Cucchiara Standards Track [Page 7] RFC 3811 MPLS TC MIB June 2004 quantity which is used to identify a Label Switching Router (LSR) label space. The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router ID assigned to the LSR, and the last two octets identify a specific label space within the LSR." SYNTAX OCTET STRING (SIZE (6)) MplsLsrIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Label Switching Router (LSR) identifier is the first 4 bytes of the Label Distribution Protocol (LDP) identifier." SYNTAX OCTET STRING (SIZE (4)) MplsLdpLabelType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Layer 2 label types which are defined for MPLS LDP and/or CR-LDP are generic(1), atm(2), or frameRelay(3)." SYNTAX INTEGER { generic(1), atm(2), frameRelay(3) } MplsLSPID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier within an MPLS network that is assigned to each LSP. This is assigned at the head end of the LSP and can be used by all LSRs to identify this LSP. This value is piggybacked by the signaling protocol when this LSP is signaled within the network. This identifier can then be used at each LSR to identify which labels are being swapped to other labels for this LSP. This object can also be used to disambiguate LSPs that share the same RSVP sessions between the same source and destination. For LSPs established using CR-LDP, the LSPID is composed of the ingress LSR Router ID (or any of its own IPv4 addresses) and a locally unique CR-LSP ID to that LSR. The first two bytes carry Nadeau & Cucchiara Standards Track [Page 8] RFC 3811 MPLS TC MIB June 2004 the CR-LSPID, and the remaining 4 bytes carry the Router ID. The LSPID is useful in network management, in CR-LSP repair, and in using an already established CR-LSP as a hop in an ER-TLV. For LSPs signaled using RSVP-TE, the LSP ID is defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. The length of this object should only be 2 or 6 bytes. If the length of this octet string is 2 bytes, then it must identify an RSVP-TE LSPID, or it is 6 bytes, it must contain a CR-LDP LSPID." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209]. Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX OCTET STRING (SIZE (2|6)) MplsLspType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Types of Label Switch Paths (LSPs) on a Label Switching Router (LSR) or a Label Edge Router (LER) are: unknown(1) -- if the LSP is not known to be one of the following. terminatingLsp(2) -- if the LSP terminates on the LSR/LER, then this is an egressing LSP which ends on the LSR/LER, originatingLsp(3) -- if the LSP originates from this LSR/LER, then this is an ingressing LSP which is the head-end of the LSP, crossConnectingLsp(4) -- if the LSP ingresses and egresses on the LSR, then it is cross-connecting on that Nadeau & Cucchiara Standards Track [Page 9] RFC 3811 MPLS TC MIB June 2004 LSR." SYNTAX INTEGER { unknown(1), terminatingLsp(2), originatingLsp(3), crossConnectingLsp(4) } MplsOwner ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This object indicates the local network management subsystem that originally created the object(s) in question. The values of this enumeration are defined as follows: unknown(1) - the local network management subsystem cannot discern which component created the object. other(2) - the local network management subsystem is able to discern which component created the object, but the component is not listed within the following choices, e.g., command line interface (cli). snmp(3) - The Simple Network Management Protocol was used to configure this object initially. ldp(4) - The Label Distribution Protocol was used to configure this object initially. crldp(5) - The Constraint-Based Label Distribution Protocol was used to configure this object initially. rsvpTe(6) - The Resource Reservation Protocol was used to configure this object initially. policyAgent(7) - A policy agent (perhaps in combination with one of the above protocols) was used to configure this object initially. An object created by any of the above choices MAY be modified or destroyed by the same or a different choice." SYNTAX INTEGER { unknown(1), Nadeau & Cucchiara Standards Track [Page 10] RFC 3811 MPLS TC MIB June 2004 other(2), snmp(3), ldp(4), crldp(5), rsvpTe(6), policyAgent(7) } MplsPathIndexOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier used to identify a specific path used by a tunnel. A value of 0 (zero) means that no path is in use." SYNTAX Unsigned32(0..4294967295) MplsPathIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique value to index (by Path number) an entry in a table." SYNTAX Unsigned32(1..4294967295) MplsRetentionMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The label retention mode which specifies whether an LSR maintains a label binding for a FEC learned from a neighbor that is not its next hop for the FEC. If the value is conservative(1) then advertised label mappings are retained only if they will be used to forward packets, i.e., if label came from a valid next hop. If the value is liberal(2) then all advertised label mappings are retained whether they are from a valid next hop or not." REFERENCE "Multiprotocol Label Switching Architecture, RFC3031. LDP Specification, RFC3036, Section 2.6.2." SYNTAX INTEGER { conservative(1), liberal(2) } Nadeau & Cucchiara Standards Track [Page 11] RFC 3811 MPLS TC MIB June 2004 MplsTunnelAffinity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Describes the configured 32-bit Include-any, include-all, or exclude-all constraint for constraint-based link selection." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC3209, Section 4.7.4." SYNTAX Unsigned32(0..4294967295) MplsTunnelIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique index into mplsTunnelTable. For tunnels signaled using RSVP, this value should correspond to the RSVP Tunnel ID used for the RSVP-TE session." SYNTAX Unsigned32 (0..65535) MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The tunnel entry with instance index 0 should refer to the configured tunnel interface (if one exists). Values greater than 0, but less than or equal to 65535, should be used to indicate signaled (or backup) tunnel LSP instances. For tunnel LSPs signaled using RSVP, this value should correspond to the RSVP LSP ID used for the RSVP-TE LSP. Values greater than 65535 apply to FRR detour instances." SYNTAX Unsigned32(0|1..65535|65536..4294967295) TeHopAddressType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that represents a type of address for a Traffic Engineered (TE) Tunnel hop. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding TeHopAddress object is a Nadeau & Cucchiara Standards Track [Page 12] RFC 3811 MPLS TC MIB June 2004 zero-length string. It may also be used to indicate a TeHopAddress which is not in one of the formats defined below. ipv4(1) An IPv4 network address as defined by the InetAddressIPv4 TEXTUAL-CONVENTION [RFC3291]. ipv6(2) A global IPv6 address as defined by the InetAddressIPv6 TEXTUAL-CONVENTION [RFC3291]. asnumber(3) An Autonomous System (AS) number as defined by the TeHopAddressAS TEXTUAL-CONVENTION. unnum(4) An unnumbered interface index as defined by the TeHopAddressUnnum TEXTUAL-CONVENTION. lspid(5) An LSP ID for TE Tunnels (RFC3212) as defined by the MplsLSPID TEXTUAL-CONVENTION. Each definition of a concrete TeHopAddressType value must be accompanied by a definition of a TEXTUAL-CONVENTION for use with that TeHopAddress. To support future extensions, the TeHopAddressType TEXTUAL-CONVENTION SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that TeHopAddressType objects and any dependent objects (e.g., TeHopAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change a TeHopAddressType object would, for example, lead to an undefined TeHopAddress value that is not defined herein. In particular, TeHopAddressType/TeHopAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1))." Nadeau & Cucchiara Standards Track [Page 13] RFC 3811 MPLS TC MIB June 2004 REFERENCE "TEXTUAL-CONVENTIONs for Internet Network Addresses, RFC3291. Constraint-Based LSP Setup using LDP, [RFC3212]" SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2), asnumber(3), unnum(4), lspid(5) } TeHopAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a generic Tunnel hop address, that is, the address of a node which an LSP traverses, including the source and destination nodes. An address may be very concrete, for example, an IPv4 host address (i.e., with prefix length 32); if this IPv4 address is an interface address, then that particular interface must be traversed. An address may also specify an 'abstract node', for example, an IPv4 address with prefix length less than 32, in which case, the LSP can traverse any node whose address falls in that range. An address may also specify an Autonomous System (AS), in which case the LSP can traverse any node that falls within that AS. A TeHopAddress value is always interpreted within the context of an TeHopAddressType value. Every usage of the TeHopAddress TEXTUAL-CONVENTION is required to specify the TeHopAddressType object which provides the context. It is suggested that the TeHopAddressType object is logically registered before the object(s) which use the TeHopAddress TEXTUAL-CONVENTION if they appear in the same logical row. The value of a TeHopAddress object must always be Nadeau & Cucchiara Standards Track [Page 14] RFC 3811 MPLS TC MIB June 2004 consistent with the value of the associated TeHopAddressType object. Attempts to set a TeHopAddress object to a value which is inconsistent with the associated TeHopAddressType must fail with an inconsistentValue error." SYNTAX OCTET STRING (SIZE (0..32)) TeHopAddressAS ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a two or four octet AS number. The AS number is represented in network byte order (MSB first). A two-octet AS number has the two MSB octets set to zero." REFERENCE "Textual Conventions for Internet Network Addresses, [RFC3291]. The InetAutonomousSystemsNumber TEXTUAL-CONVENTION has a SYNTAX of Unsigned32, whereas this TC has a SYNTAX of OCTET STRING (SIZE (4)). Both TCs represent an autonomous system number but use different syntaxes to do so." SYNTAX OCTET STRING (SIZE (4)) TeHopAddressUnnum ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents an unnumbered interface: octets contents encoding 1-4 unnumbered interface network-byte order The corresponding TeHopAddressType value is unnum(5)." SYNTAX OCTET STRING(SIZE(4)) END Nadeau & Cucchiara Standards Track [Page 15] RFC 3811 MPLS TC MIB June 2004 4. References 4.1. Normative References [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP: 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Federokow, G., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Nadeau & Cucchiara Standards Track [Page 16] RFC 3811 MPLS TC MIB June 2004 [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3471, January 2003. 4.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 5. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MPLS MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet. 6. IANA Considerations IANA has made a MIB OID assignment under the transmission branch, that is, assigned the mplsStdMIB under { transmission 166 }. This sub-id is requested because 166 is the ifType for mpls(166) and is available under transmission. In the future, MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. The IANA is requested to manage that namespace. New assignments can only be made via a Standards Action as specified in [RFC2434]. The IANA has also assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB specified in this document. Nadeau & Cucchiara Standards Track [Page 17] RFC 3811 MPLS TC MIB June 2004 7. Contributors This document was created by combining TEXTUAL-CONVENTIONS from current MPLS MIBs and a TE-WG MIB. Co-authors on each of these MIBs contributed to the TEXTUAL-CONVENTIONS contained in this MIB and also contributed greatly to the revisions of this document. These co- authors addresses are included here because they are useful future contacts for information about this document. These co-authors are: Cheenu Srinivasan Bloomberg L.P. 499 Park Ave. New York, NY 10022 Phone: +1-212-893-3682 EMail: cheenu@bloomberg.net Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Phone: +1-408-571-3516 EMail: arunv@force10networks.com Hans Sjostrand ipUnplugged P.O. Box 101 60 S-121 28 Stockholm, Sweden Phone: +46-8-725-5900 EMail: hans@ipunplugged.com Kireeti Kompella Juniper Networks 1194 Mathilda Ave Sunnyvale, CA 94089 Phone: +1-408-745-2000 EMail: kireeti@juniper.net Nadeau & Cucchiara Standards Track [Page 18] RFC 3811 MPLS TC MIB June 2004 8. Acknowledgements This document is a product of the MPLS Working Group. The editors and contributors would like to thank Mike MacFadden and Adrian Farrel for their helpful comments on several reviews. Also, the editors and contributors would like to give a special acknowledgement to Bert Wijnen for his many detailed reviews. Bert's assistance and guidance is greatly appreciated. 9. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. BXB300/2/ 300 Beaver Brook Road Boxborough, MA 01719 Phone: +1-978-936-1470 EMail: tnadeau@cisco.com Joan E. Cucchiara Marconi Communications, Inc. 900 Chelmsford Street Lowell, MA 01851 Phone: +1-978-275-7400 EMail: jcucchiara@mindspring.com Nadeau & Cucchiara Standards Track [Page 19] RFC 3811 MPLS TC MIB June 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nadeau & Cucchiara Standards Track [Page 20] snmp-mibs-downloader-1.1/mibrfcs/rfc3812.txt0000644000000000000000000041243311402176071015566 0ustar Network Working Group C. Srinivasan Request for Comments: 3812 Bloomberg L.P. Category: Standards Track A. Viswanathan Force10 Networks, Inc. T. Nadeau Cisco Systems, Inc. June 2004 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The Internet-Standard Management Framework . . . . . . . . . . 3 4. Feature List . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Summary of Traffic Engineering MIB Module. . . . . . . . 4 6. Brief Description of MIB Objects . . . . . . . . . . . . . . . 4 6.1. mplsTunnelTable. . . . . . . . . . . . . . . . . . . . . 4 6.2. mplsTunnelResourceTable. . . . . . . . . . . . . . . . . 5 6.3. mplsTunnelHopTable . . . . . . . . . . . . . . . . . . . 5 6.4. mplsTunnelARHopTable . . . . . . . . . . . . . . . . . . 5 6.5. mplsTunnelCHoptable. . . . . . . . . . . . . . . . . . . 5 6.6. mplsTunnelPerfTable. . . . . . . . . . . . . . . . . . . 6 6.7. mplsTunnelCRLDPResTable. . . . . . . . . . . . . . . . . 6 7. Use of 32-bit and 64-bit Counters. . . . . . . . . . . . . . . 6 Srinivasan, et al. Standards Track [Page 1] RFC 3812 MPLS-TE-STD-MIB June 2004 8. Application of the Interface Group to MPLS Tunnels . . . . . . 6 8.1. Support of the MPLS Tunnel Interface by ifTable. . . . . 7 9. Example of Tunnel Setup. . . . . . . . . . . . . . . . . . . . 8 10. The Use of RowPointer. . . . . . . . . . . . . . . . . . . . . 11 11. MPLS Traffic Engineering MIB Definitions . . . . . . . . . . . 11 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 63 13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 64 14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 64 14.1. IANA Considerations for MPLS-TE-STD-MIB. . . . . . . . . 65 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 15.1. Normative References . . . . . . . . . . . . . . . . . . 65 15.2. Informative References . . . . . . . . . . . . . . . . . 66 16. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 67 17. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 68 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Multiprotocol Label Switching (MPLS) [RFC3031] based traffic engineering. This MIB module should be used in conjunction with the companion document [RFC3813] for MPLS based traffic engineering configuration and management. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119, reference [RFC2119]. 2. Terminology This document uses terminology from the MPLS architecture document [RFC3031] and MPLS Label Switch Router MIB [RFC3813]. Some frequently used terms are described next. An explicitly routed LSP (ERLSP) is referred to as an MPLS tunnel. It consists of in-segment(s) and/or out-segment(s) at the egress/ingress LSRs, each segment being associated with one MPLS interface. These are also referred to as tunnel segments. Additionally, at an intermediate LSR, we model a connection as consisting of one or more in-segments and/or one or more out- segments. The binding or interconnection between in-segments and out-segments is performed using a cross-connect. These objects are defined in the MPLS Label Switch Router MIB [RFC3813]. Srinivasan, et al. Standards Track [Page 2] RFC 3812 MPLS-TE-STD-MIB June 2004 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Feature List The MPLS traffic engineering MIB module is designed to satisfy the following requirements and constraints: - The MIB module supports configuration of point-to-point unidirectional tunnels. - MPLS tunnels need not be interfaces, but it is possible to configure a tunnel as an interface. - The MIB module supports tunnel establishment via an MPLS signalling protocol wherein the tunnel parameters are specified using this MIB module at the head end of the LSP, and end-to-end tunnel LSP establishment is accomplished via signalling. The MIB module also supports manually configured tunnels, i.e., those for which label associations at each hop of the tunnel LSP are provisioned by the administrator via the LSR MIB [RFC3813]. - The MIB module supports persistent, as well as non-persistent tunnels. 5. Outline Traffic engineering support for MPLS tunnels requires the following configuration: - Setting up MPLS tunnels along with appropriate configuration parameters. - Configuring tunnel for loose and strict source routed hops. Srinivasan, et al. Standards Track [Page 3] RFC 3812 MPLS-TE-STD-MIB June 2004 These actions may need to be accompanied by corresponding actions using [RFC3813] to establish and configure tunnel segments, if this is done manually. Also, the in-segment and out-segment performance tables, mplsInSegmentPerfTable, and mplsOutSegmentPerfTable [RFC3813], should be used to determine performance of the tunnels and tunnel segments, in addition to mplsTunnelPerfTable in this MIB module. 5.1. Summary of Traffic Engineering MIB Module The MIB module objects for performing these actions consist of the following tables: - Tunnel table (mplsTunnelTable) for setting up MPLS tunnels. - Resource table (mplsTunnelResourceTable) for setting up the tunnel resources. - Tunnel specified, actual, and computed hop tables (mplsTunnelHopTable, mplsTunnelARHopTable, and mplsTunnelCHopTable) for strict and loose source routed MPLS tunnel hops. - Tunnel performance table (mplsTunnelPerfTable) for measuring tunnel performance. - CRLDP resource table (mplsTunnelCRLDPResTable) for specifying resource objects applicable to tunnels signaled using CRLDP. These tables are described in the subsequent sections. 6. Brief Description of MIB Objects The objects described in this section support the functionality described in documents [RFC3209] and [RFC3212]. The tables support both manually configured and signaled tunnels. 6.1. mplsTunnelTable The mplsTunnelTable allows new MPLS tunnels to be created between an MPLS LSR and a remote endpoint, and existing tunnels to be reconfigured or removed. Note that we only support point-to-point tunnels, although multipoint-to-point and point-to-multipoint connections are supported by an LSR acting as a cross-connect. Each MPLS tunnel can thus have one out-segment originating at an LSR and/or one in-segment terminating at that LSR. Srinivasan, et al. Standards Track [Page 4] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelTable does not define the in and out segments forming the tunnel. Instead, these are defined by creating rows in the in- segment and out-segment tables, defining relationships in the cross- connect table, and referring to these rows in the mplsTunnelTable using a cross-connect index, mplsTunnelXCIndex. These segment and cross-connect related objects are defined in [RFC3813]. 6.2. mplsTunnelResourceTable mplsTunnelResourceTable is used to indicate the resources required for a tunnel. Multiple tunnels may share the same resources by pointing to the same entry in this table. Tunnels that do not share resources must point to separate entries in this table. 6.3. mplsTunnelHopTable mplsTunnelHopTable is used to indicate the hops, strict or loose, for an MPLS tunnel defined in mplsTunnelTable, when it is established via signalling. Multiple tunnels may share the same hops by pointing to the same entry in this table. Each row also has a secondary index, mplsTunnelHopIndex, corresponding to the next hop of this tunnel. The scalar mplsTunnelMaxHops indicates the maximum number of hops that can be specified on each tunnel supported by this LSR. At transit LSRs, this table contains the hops, strict or loose, that apply to the downstream part of this tunnel only. This corresponds to the requested path received through the signaling protocol. 6.4. mplsTunnelARHopTable mplsTunnelARHopTable is used to indicate the actual hops traversed by a tunnel as reported by the MPLS signalling protocol after the tunnel is setup. The support of this table is optional since not all MPLS signalling protocols may support this feature. At transit LSRs, this table contains the actual hops traversed by the tunnel along its entire length if that information is available. This corresponds to the recorded path reported by the MPLS signalling protocol, possibly derived from multiple signaling messages. 6.5. mplsTunnelCHoptable mplsTunnelCHopTable lists the actual hops computed by a constraint- based routing algorithm based on the mplsTunnelHopTable for the MPLS signalling protocol in use. The support of this table is optional since not all implementations may support computation of hop lists using a constraint-based routing protocol. Srinivasan, et al. Standards Track [Page 5] RFC 3812 MPLS-TE-STD-MIB June 2004 At transit LSRs, this table contains the hops computed to apply to the downstream part of this tunnel. This corresponds to the requested path signaled from this LSR through the signaling protocol. 6.6. mplsTunnelPerfTable mplsTunnelPerfTable provides several counters to measure the performance of the MPLS tunnels. This table augments mplsTunnelTable. 6.7. mplsTunnelCRLDPResTable mplsTunnelCRLDPResTable contains resource information for those tunnels that are signaled using CRLDP [RFC3212]. This is a sparse extension to mplsTunnelResourceTable and is also indexed by mplsTunnelResourceIndex. As with mplsTunnelResourceTable, multiple tunnels may share the same resources by pointing to the same entry in this table. Tunnels that do not share resources must point to separate entries in this table. The mplsTunnelCRLDPResTable may be supported only by implementations that support the CR-LDP signaling protocol. 7. Use of 32-bit and 64-bit Counters 64-bit counters are provided in this MIB module for high-speed interfaces where the use of 32-bit counters might be impractical. The requirements on the use of 32-bit and 64-bit counters (copied verbatim from [RFC2863]) are as follows: For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported. 8. Application of the Interface Group to MPLS Tunnels The Interfaces Group of MIB II defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing MPLS Tunnels as logical interfaces. This memo assumes the interpretation of the Interfaces Group to be in accordance with [RFC2863] which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network Srinivasan, et al. Standards Track [Page 6] RFC 3812 MPLS-TE-STD-MIB June 2004 interface is considered an interface. Thus, the MPLS interface is represented as an entry in the ifTable. The inter-relation of entries in the ifTable is defined by the Interfaces Stack Group defined in [RFC2863]. When using MPLS Tunnels as interfaces, the interface stack table might appear as follows: +------------------------------------------------+ | MPLS tunnel interface ifType = mplsTunnel(150) | +------------------------------------------------+ | MPLS interface ifType = mpls(166) | +------------------------------------------------+ | Underlying layer | +------------------------------------------------+ In the above diagram, "Underlying Layer" refers to the ifIndex of any interface type for which MPLS internetworking has been defined. Examples include ATM, Frame Relay, and Ethernet. 8.1. Support of the MPLS Tunnel Interface by ifTable Some specific interpretations of the ifTable for those MPLS tunnels represented as interfaces follow: Object Use for the MPLS tunnel. ifIndex Each MPLS tunnel is represented by an ifEntry. ifDescr Description of the MPLS tunnel. ifType The value that is allocated for the MPLS tunnel is 150. ifSpeed The total bandwidth in bits per second for use by the MPLS tunnel. ifPhysAddress Unused. ifAdminStatus See [RFC2863]. ifOperStatus This value reflects the actual operational status of the MPLS tunnel. Assumes the value down(2) if the MPLS tunnel is down. ifLastChange See [RFC2863]. Srinivasan, et al. Standards Track [Page 7] RFC 3812 MPLS-TE-STD-MIB June 2004 ifInOctets The number of octets received over the MPLS tunnel. ifOutOctets The number of octets transmitted over the MPLS tunnel. ifInErrors The number of labeled packets dropped due to uncorrectable errors. ifInUnknownProtos The number of received packets discarded during packet header validation, including packets with unrecognized label values. ifOutErrors See [RFC2863]. ifName Textual name (unique on this system) of the MPLS tunnel or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). ifConnectorPresent Set to false (2). ifHighSpeed See [RFC2863]. ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in [RFC2863]. ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in [RFC2863]. ifAlias The non-volatile 'alias' name for the MPLS tunnel as specified by a network manager. 9. Example of Tunnel Setup This section contains an example of which MIB objects should be modified if one would like to create a best effort, loosely routed, unidirectional traffic engineered tunnel, which spans two hops of a simple network. Note that these objects should be created on the "head-end" LSR. Those objects relevant to illustrating the relationships amongst different tables are shown here. Other objects may be needed before conceptual row activation can happen. Srinivasan, et al. Standards Track [Page 8] RFC 3812 MPLS-TE-STD-MIB June 2004 The RowStatus values shown in this section are those to be used in the set request, typically createAndGo(4) which is used to create the conceptual row and have its status immediately set to active. A subsequent retrieval operation on the conceptual row will return a different value, such as active(1). Please see [RFC2579] for a detailed discussion on the use of RowStatus. In mplsTunnelResourceTable: { mplsTunnelResourceIndex = 5, mplsTunnelResourceMaxRate = 0, mplsTunnelResourceMeanRate = 0, mplsTunnelResourceMaxBurstSize = 0, mplsTunnelResourceMeanBurstSize = 0, mplsTunnelResourceExBurstSize = 0, mplsTunnelResourceExBurstSize = unspecified (1), mplsTunnelResourceWeight = 0, -- Mandatory parameters needed to activate the row go here mplsTunnelResourceRowStatus = createAndGo (4) } The next two instances of mplsTunnelHopEntry are used to denote the hops this tunnel will take across the network. The following denotes the beginning of the tunnel, or the first hop. We have used the fictitious LSR identified by "192.168.100.1" as our example head-end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex = 1, mplsTunnelPathOptionIndex = 1, mplsTunnelHopIndex = 1, mplsTunnelHopAddrType = ipv4 (1), mplsTunnelHopIpAddr = "192.168.100.1", mplsTunnelHopIpPrefixLen = 32, mplsTunnelHopType = strict (2), mplsTunnelHopInclude = true (1), mplsTunnelHopPathOptionName = "Here to there", mplsTunnelHopEntryPathComp = explicit (2), -- Mandatory parameters needed to activate the row go here mplsTunnelHopRowStatus = createAndGo (4) } Srinivasan, et al. Standards Track [Page 9] RFC 3812 MPLS-TE-STD-MIB June 2004 The following denotes the end of the tunnel, or the last hop in our example. We have used the fictitious LSR identified by "192.168.101.1" as our end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex = 1, mplsTunnelPathOptionIndex = 1, mplsTunnelHopIndex = 2, mplsTunnelHopAddrType = ipv4 (1), mplsTunnelHopIpAddr = "192.168.101.1", mplsTunnelHopIpPrefixLen = 32, mplsTunnelHopType = loose (2), mplsTunnelHopInclude = true (1), mplsTunnelHopPathOptionName = "Here to there", mplsTunnelHopEntryPathComp = explicit (2), -- Mandatory parameters needed to activate the row go here mplsTunnelHopRowStatus = createAndGo (4) } The following denotes the configured tunnel "head" entry: In mplsTunnelTable: { mplsTunnelIndex = 1, mplsTunnelInstance = 0, mplsTunnelIngressLSRId = 192.168.100.1, mplsTunnelEgressLSRId = 192.168.101.1, mplsTunnelName = "My first tunnel", mplsTunnelDescr = "Here to there", mplsTunnelIsIf = true (1), -- RowPointer MUST point to the first accessible column mplsTunnelXCPointer = 0.0, mplsTunnelSignallingProto = none (1), mplsTunnelSetupPrio = 0, mplsTunnelHoldingPrio = 0, mplsTunnelSessionAttributes = 0, mplsTunnelLocalProtectInUse = false (0), -- RowPointer MUST point to the first accessible column mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, mplsTunnelInstancePriority = 1, mplsTunnelHopTableIndex = 1, mplsTunnelIncludeAnyAffinity = 0, mplsTunnelIncludeAllAffinity = 0, mplsTunnelExcludeAnyAffinity = 0, mplsTunnelPathInUse = 1, Srinivasan, et al. Standards Track [Page 10] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelRole = head (1), -- Mandatory parameters needed to activate the row go here mplsTunnelRowStatus = createAndGo (4) } Note that any active or signaled instances of the above tunnel would appear with the same primary mplsTunnelIndex, but would have values greater than 0 for mplsTunnelInstance. They would also have other objects such as the mplsTunnelXCPointer set accordingly. 10. The Use of RowPointer RowPointer is a textual convention used to identify a conceptual row in a conceptual table in a MIB by pointing to the first accessible object. In this MIB module, in mplsTunnelTable, the objects mplsTunnelXCPointer and mplsTunnelResourcePointer are of type RowPointer. The object mplsTunnelXCPointer points to a specific entry in the mplsXCTable [RFC3813]. This entry in the mplsXCTable is the associated LSP for the given MPLS tunnel entry. The object mplsTunnelResourcePointer points to a specific entry in a traffic parameter table. An example of such a traffic parameter table is mplsTunnelResourceTable. It indicates a specific instance of a traffic parameter entry that is associated with a given MPLS tunnel entry. These RowPointer objects MUST point to the first instance of the first accessible columnar object in the appropriate conceptual row in order to allow the manager to find the appropriate corresponding entry in either MPLS-LSR-STD-MIB [RFC3813] or MPLS-TE- STD-MIB. If object mplsTunnelXCPointer returns zeroDotZero, it implies that there is no LSP associated with that particular instance of tunnel entry. If object mplsTunnelResourcePointer returns zeroDotZero, it implies that there is no QoS resource associated with that particular instance of tunnel entry. 11. MPLS Traffic Engineering MIB Definitions MPLS-TE-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, Counter64, TimeTicks, zeroDotZero FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TruthValue, RowStatus, RowPointer, StorageType, TimeStamp FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero, ifGeneralInformationGroup, Srinivasan, et al. Standards Track [Page 11] RFC 3812 MPLS-TE-STD-MIB June 2004 ifCounterDiscontinuityGroup FROM IF-MIB -- [RFC2863] mplsStdMIB, MplsBitRate, MplsBurstSize, MplsLSPID, MplsTunnelIndex, MplsTunnelInstanceIndex, MplsTunnelAffinity, MplsExtendedTunnelId, MplsPathIndex, MplsPathIndexOrZero, MplsOwner, TeHopAddressType, TeHopAddress, TeHopAddressAS, TeHopAddressUnnum FROM MPLS-TC-STD-MIB -- [RFC3811] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] IndexIntegerNextFree FROM DIFFSERV-MIB -- [RFC3289] InetAddressPrefixLength FROM INET-ADDRESS-MIB -- [RFC3291] ; mplsTeStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Cheenu Srinivasan Bloomberg L.P. Email: cheenu@bloomberg.net Arun Viswanathan Force10 Networks, Inc. Email: arunv@force10networks.com Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Comments about this document should be emailed directly to the MPLS working group mailing list at mpls@uu.net." DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3812. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB module contains managed object definitions for MPLS Traffic Engineering (TE) as defined in: 1. Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Constraint-Based LSP Setup using LDP, Jamoussi Srinivasan, et al. Standards Track [Page 12] RFC 3812 MPLS-TE-STD-MIB June 2004 (Editor), RFC 3212, January 2002 3. Requirements for Traffic Engineering Over MPLS, Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, [RFC2702], September 1999" -- Revision history. REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version issued as part of RFC 3812." ::= { mplsStdMIB 3 } -- Top level components of this MIB module. -- traps mplsTeNotifications OBJECT IDENTIFIER ::= { mplsTeStdMIB 0 } -- tables, scalars mplsTeScalars OBJECT IDENTIFIER ::= { mplsTeStdMIB 1 } mplsTeObjects OBJECT IDENTIFIER ::= { mplsTeStdMIB 2 } -- conformance mplsTeConformance OBJECT IDENTIFIER ::= { mplsTeStdMIB 3 } -- MPLS Tunnel scalars. mplsTunnelConfigured OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of tunnels configured on this device. A tunnel is considered configured if the mplsTunnelRowStatus is active(1)." ::= { mplsTeScalars 1 } mplsTunnelActive OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of tunnels active on this device. A tunnel is considered active if the mplsTunnelOperStatus is up(1)." ::= { mplsTeScalars 2 } mplsTunnelTEDistProto OBJECT-TYPE Srinivasan, et al. Standards Track [Page 13] RFC 3812 MPLS-TE-STD-MIB June 2004 SYNTAX BITS { other (0), ospf (1), isis (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The traffic engineering distribution protocol(s) used by this LSR. Note that an LSR may support more than one distribution protocol simultaneously." ::= { mplsTeScalars 3 } mplsTunnelMaxHops OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of hops that can be specified for a tunnel on this device." ::= { mplsTeScalars 4 } mplsTunnelNotificationMaxRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the maximum number of notifications issued per second. If events occur more rapidly, the implementation may simply fail to emit these notifications during that period, or may queue them until an appropriate time. A value of 0 means no throttling is applied and events may be notified at the rate at which they occur." DEFVAL { 0 } ::= { mplsTeScalars 5 } -- End of MPLS Tunnel scalars. -- MPLS tunnel table. mplsTunnelIndexNext OBJECT-TYPE SYNTAX IndexIntegerNextFree (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for Srinivasan, et al. Standards Track [Page 14] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelIndex, or a zero to indicate that none exist. Negative values are not allowed, as they do not correspond to valid values of mplsTunnelIndex. Note that this object offers an unused value for an mplsTunnelIndex value at the ingress side of a tunnel. At other LSRs the value of mplsTunnelIndex SHOULD be taken from the value signaled by the MPLS signaling protocol. " ::= { mplsTeObjects 1 } mplsTunnelTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mplsTunnelTable allows new MPLS tunnels to be created between an LSR and a remote endpoint, and existing tunnels to be reconfigured or removed. Note that only point-to-point tunnel segments are supported, although multipoint-to-point and point- to-multipoint connections are supported by an LSR acting as a cross-connect. Each MPLS tunnel can thus have one out-segment originating at this LSR and/or one in-segment terminating at this LSR." ::= { mplsTeObjects 2 } mplsTunnelEntry OBJECT-TYPE SYNTAX MplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents an MPLS tunnel. An entry can be created by a network administrator or by an SNMP agent as instructed by an MPLS signalling protocol. Whenever a new entry is created with mplsTunnelIsIf set to true(1), then a corresponding entry is created in ifTable as well (see RFC 2863). The ifType of this entry is mplsTunnel(150). A tunnel entry needs to be uniquely identified across a MPLS network. Indices mplsTunnelIndex and mplsTunnelInstance uniquely identify a tunnel on the LSR originating the tunnel. To uniquely identify a tunnel across an MPLS network requires Srinivasan, et al. Standards Track [Page 15] RFC 3812 MPLS-TE-STD-MIB June 2004 index mplsTunnelIngressLSRId. The last index mplsTunnelEgressLSRId is useful in identifying all instances of a tunnel that terminate on the same egress LSR." REFERENCE "1. RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000 " INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } ::= { mplsTunnelTable 1 } MplsTunnelEntry ::= SEQUENCE { mplsTunnelIndex MplsTunnelIndex, mplsTunnelInstance MplsTunnelInstanceIndex, mplsTunnelIngressLSRId MplsExtendedTunnelId, mplsTunnelEgressLSRId MplsExtendedTunnelId, mplsTunnelName SnmpAdminString, mplsTunnelDescr SnmpAdminString, mplsTunnelIsIf TruthValue, mplsTunnelIfIndex InterfaceIndexOrZero, mplsTunnelOwner MplsOwner, mplsTunnelRole INTEGER, mplsTunnelXCPointer RowPointer, mplsTunnelSignallingProto INTEGER, mplsTunnelSetupPrio Integer32, mplsTunnelHoldingPrio Integer32, mplsTunnelSessionAttributes BITS, mplsTunnelLocalProtectInUse TruthValue, mplsTunnelResourcePointer RowPointer, mplsTunnelPrimaryInstance MplsTunnelInstanceIndex, mplsTunnelInstancePriority Unsigned32, mplsTunnelHopTableIndex MplsPathIndexOrZero, mplsTunnelPathInUse MplsPathIndexOrZero, mplsTunnelARHopTableIndex MplsPathIndexOrZero, mplsTunnelCHopTableIndex MplsPathIndexOrZero, mplsTunnelIncludeAnyAffinity MplsTunnelAffinity, mplsTunnelIncludeAllAffinity MplsTunnelAffinity, mplsTunnelExcludeAnyAffinity MplsTunnelAffinity, mplsTunnelTotalUpTime TimeTicks, mplsTunnelInstanceUpTime TimeTicks, mplsTunnelPrimaryUpTime TimeTicks, mplsTunnelPathChanges Counter32, mplsTunnelLastPathChange TimeTicks, mplsTunnelCreationTime TimeStamp, mplsTunnelStateTransitions Counter32, Srinivasan, et al. Standards Track [Page 16] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelAdminStatus INTEGER, mplsTunnelOperStatus INTEGER, mplsTunnelRowStatus RowStatus, mplsTunnelStorageType StorageType } mplsTunnelIndex OBJECT-TYPE SYNTAX MplsTunnelIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies a set of tunnel instances between a pair of ingress and egress LSRs. Managers should obtain new values for row creation in this table by reading mplsTunnelIndexNext. When the MPLS signalling protocol is rsvp(2) this value SHOULD be equal to the value signaled in the Tunnel Id of the Session object. When the MPLS signalling protocol is crldp(3) this value SHOULD be equal to the value signaled in the LSP ID." ::= { mplsTunnelEntry 1 } mplsTunnelInstance OBJECT-TYPE SYNTAX MplsTunnelInstanceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies a particular instance of a tunnel between a pair of ingress and egress LSRs. It is useful to identify multiple instances of tunnels for the purposes of backup and parallel tunnels. When the MPLS signaling protocol is rsvp(2) this value SHOULD be equal to the LSP Id of the Sender Template object. When the signaling protocol is crldp(3) there is no equivalent signaling object." ::= { mplsTunnelEntry 2 } mplsTunnelIngressLSRId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identity of the ingress LSR associated with this tunnel instance. When the MPLS signalling protocol is rsvp(2) this value SHOULD be equal to the Tunnel Srinivasan, et al. Standards Track [Page 17] RFC 3812 MPLS-TE-STD-MIB June 2004 Sender Address in the Sender Template object and MAY be equal to the Extended Tunnel Id field in the SESSION object. When the MPLS signalling protocol is crldp(3) this value SHOULD be equal to the Ingress LSR Router ID field in the LSPID TLV object." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Constraint-Based LSP Setup using LDP, Jamoussi (Editor), RFC 3212, January 2002" ::= { mplsTunnelEntry 3 } mplsTunnelEgressLSRId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identity of the egress LSR associated with this tunnel instance." ::= { mplsTunnelEntry 4 } mplsTunnelName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The canonical name assigned to the tunnel. This name can be used to refer to the tunnel on the LSR's console port. If mplsTunnelIsIf is set to true then the ifName of the interface corresponding to this tunnel should have a value equal to mplsTunnelName. Also see the description of ifName in RFC 2863." REFERENCE "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000" DEFVAL {""} ::= { mplsTunnelEntry 5 } mplsTunnelDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A textual string containing information about the tunnel. If there is no description this object contains a zero length string. This object is may not be signaled by MPLS signaling protocols, Srinivasan, et al. Standards Track [Page 18] RFC 3812 MPLS-TE-STD-MIB June 2004 consequentally the value of this object at transit and egress LSRs MAY be automatically generated or absent." DEFVAL {""} ::= { mplsTunnelEntry 6 } mplsTunnelIsIf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether or not this tunnel corresponds to an interface represented in the interfaces group table. Note that if this variable is set to true then the ifName of the interface corresponding to this tunnel should have a value equal to mplsTunnelName. Also see the description of ifName in RFC 2863. This object is meaningful only at the ingress and egress LSRs." REFERENCE "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000" DEFVAL { false } ::= { mplsTunnelEntry 7 } mplsTunnelIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "If mplsTunnelIsIf is set to true, then this value contains the LSR-assigned ifIndex which corresponds to an entry in the interfaces table. Otherwise this variable should contain the value of zero indicating that a valid ifIndex was not assigned to this tunnel interface." REFERENCE "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000" DEFVAL { 0 } ::= { mplsTunnelEntry 8 } mplsTunnelOwner OBJECT-TYPE SYNTAX MplsOwner MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes the entity that created and is responsible Srinivasan, et al. Standards Track [Page 19] RFC 3812 MPLS-TE-STD-MIB June 2004 for managing this tunnel. This column is automatically filled by the agent on creation of a row." ::= { mplsTunnelEntry 9 } mplsTunnelRole OBJECT-TYPE SYNTAX INTEGER { head(1), transit(2), tail(3), headTail(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This value signifies the role that this tunnel entry/instance represents. This value MUST be set to head(1) at the originating point of the tunnel. This value MUST be set to transit(2) at transit points along the tunnel, if transit points are supported. This value MUST be set to tail(3) at the terminating point of the tunnel if tunnel tails are supported. The value headTail(4) is provided for tunnels that begin and end on the same LSR." DEFVAL { head } ::= { mplsTunnelEntry 10 } mplsTunnelXCPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This variable points to a row in the mplsXCTable. This table identifies the segments that compose this tunnel, their characteristics, and relationships to each other. A value of zeroDotZero indicates that no LSP has been associated with this tunnel yet." REFERENCE "Srinivasan, C., Viswanathan, A., and T. Nadeau, Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813, June 2004" DEFVAL { zeroDotZero } ::= { mplsTunnelEntry 11 } mplsTunnelSignallingProto OBJECT-TYPE SYNTAX INTEGER { Srinivasan, et al. Standards Track [Page 20] RFC 3812 MPLS-TE-STD-MIB June 2004 none(1), rsvp(2), crldp(3), other(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The signalling protocol, if any, used to setup this tunnel." DEFVAL { none } ::= { mplsTunnelEntry 12 } mplsTunnelSetupPrio OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the setup priority of this tunnel." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Constraint-Based LSP Setup using LDP, Jamoussi (Editor), RFC 3212, January 2002" DEFVAL { 0 } ::= { mplsTunnelEntry 13 } mplsTunnelHoldingPrio OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the holding priority for this tunnel." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Constraint-Based LSP Setup using LDP, Jamoussi (Editor), RFC 3212, January 2002" DEFVAL { 0 } ::= { mplsTunnelEntry 14 } mplsTunnelSessionAttributes OBJECT-TYPE SYNTAX BITS { fastReroute (0), mergingPermitted (1), isPersistent (2), isPinned (3), Srinivasan, et al. Standards Track [Page 21] RFC 3812 MPLS-TE-STD-MIB June 2004 recordRoute(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bit mask indicates optional session values for this tunnel. The following describes these bit fields: fastRerouteThis flag indicates that the any tunnel hop may choose to reroute this tunnel without tearing it down. This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit routing of this tunnel. When a fault is detected on an adjacent downstream link or node, a transit router can re-route traffic for fast service restoration. mergingPermitted This flag permits transit routers to merge this session with other RSVP sessions for the purpose of reducing resource overhead on downstream transit routers, thereby providing better network scaling. isPersistent Indicates whether this tunnel should be restored automatically after a failure occurs. isPinned This flag indicates whether the loose- routed hops of this tunnel are to be pinned. recordRouteThis flag indicates whether or not the signalling protocol should remember the tunnel path after it has been signaled." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001." ::= { mplsTunnelEntry 15 } mplsTunnelLocalProtectInUse OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates that the local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over)." DEFVAL { false } ::= { mplsTunnelEntry 16 } Srinivasan, et al. Standards Track [Page 22] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelResourcePointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This variable represents a pointer to the traffic parameter specification for this tunnel. This value may point at an entry in the mplsTunnelResourceEntry to indicate which mplsTunnelResourceEntry is to be assigned to this LSP instance. This value may optionally point at an externally defined traffic parameter specification table. A value of zeroDotZero indicates best-effort treatment. By having the same value of this object, two or more LSPs can indicate resource sharing." DEFVAL { zeroDotZero } ::= { mplsTunnelEntry 17 } mplsTunnelPrimaryInstance OBJECT-TYPE SYNTAX MplsTunnelInstanceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the instance index of the primary instance of this tunnel. More details of the definition of tunnel instances and the primary tunnel instance can be found in the description of the TEXTUAL-CONVENTION MplsTunnelInstanceIndex." DEFVAL { 0 } ::= { mplsTunnelEntry 18 } mplsTunnelInstancePriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This value indicates which priority, in descending order, with 0 indicating the lowest priority, within a group of tunnel instances. A group of tunnel instances is defined as a set of LSPs with the same mplsTunnelIndex in this table, but with a different mplsTunnelInstance. Tunnel instance priorities are used to denote the priority at which a particular tunnel instance will supercede another. Instances of tunnels containing the same mplsTunnelInstancePriority will be used for load sharing." Srinivasan, et al. Standards Track [Page 23] RFC 3812 MPLS-TE-STD-MIB June 2004 DEFVAL { 0 } ::= { mplsTunnelEntry 19 } mplsTunnelHopTableIndex OBJECT-TYPE SYNTAX MplsPathIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Index into the mplsTunnelHopTable entry that specifies the explicit route hops for this tunnel. This object is meaningful only at the head-end of the tunnel." DEFVAL { 0 } ::= { mplsTunnelEntry 20 } mplsTunnelPathInUse OBJECT-TYPE SYNTAX MplsPathIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This value denotes the configured path that was chosen for this tunnel. This value reflects the secondary index into mplsTunnelHopTable. This path may not exactly match the one in mplsTunnelARHopTable due to the fact that some CSPF modification may have taken place. See mplsTunnelARHopTable for the actual path being taken by the tunnel. A value of zero denotes that no path is currently in use or available." DEFVAL { 0 } ::= { mplsTunnelEntry 21 } mplsTunnelARHopTableIndex OBJECT-TYPE SYNTAX MplsPathIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Index into the mplsTunnelARHopTable entry that specifies the actual hops traversed by the tunnel. This is automatically updated by the agent when the actual hops becomes available." DEFVAL { 0 } ::= { mplsTunnelEntry 22 } mplsTunnelCHopTableIndex OBJECT-TYPE SYNTAX MplsPathIndexOrZero MAX-ACCESS read-only STATUS current Srinivasan, et al. Standards Track [Page 24] RFC 3812 MPLS-TE-STD-MIB June 2004 DESCRIPTION "Index into the mplsTunnelCHopTable entry that specifies the computed hops traversed by the tunnel. This is automatically updated by the agent when computed hops become available or when computed hops get modified." DEFVAL { 0 } ::= { mplsTunnelEntry 23 } mplsTunnelIncludeAnyAffinity OBJECT-TYPE SYNTAX MplsTunnelAffinity MAX-ACCESS read-create STATUS current DESCRIPTION "A link satisfies the include-any constraint if and only if the constraint is zero, or the link and the constraint have a resource class in common." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001." ::= { mplsTunnelEntry 24 } mplsTunnelIncludeAllAffinity OBJECT-TYPE SYNTAX MplsTunnelAffinity MAX-ACCESS read-create STATUS current DESCRIPTION "A link satisfies the include-all constraint if and only if the link contains all of the administrative groups specified in the constraint." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001." ::= { mplsTunnelEntry 25 } mplsTunnelExcludeAnyAffinity OBJECT-TYPE SYNTAX MplsTunnelAffinity MAX-ACCESS read-create STATUS current DESCRIPTION "A link satisfies the exclude-any constraint if and only if the link contains none of the administrative groups specified in the constraint." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001." DEFVAL { 0 } ::= { mplsTunnelEntry 26 } Srinivasan, et al. Standards Track [Page 25] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelTotalUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the aggregate up time for all instances of this tunnel, if available. If this value is unavailable, it MUST return a value of 0." ::= { mplsTunnelEntry 27 } mplsTunnelInstanceUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the total time that this tunnel instance's operStatus has been Up(1)." ::= { mplsTunnelEntry 28 } mplsTunnelPrimaryUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the total time the primary instance of this tunnel has been active. The primary instance of this tunnel is defined in mplsTunnelPrimaryInstance." ::= { mplsTunnelEntry 29 } mplsTunnelPathChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of times the actual path for this tunnel instance has changed." ::= { mplsTunnelEntry 30 } mplsTunnelLastPathChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the time since the last change to the actual path for this tunnel instance." ::= { mplsTunnelEntry 31 } Srinivasan, et al. Standards Track [Page 26] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the value of SysUpTime when the first instance of this tunnel came into existence. That is, when the value of mplsTunnelOperStatus was first set to up(1)." ::= { mplsTunnelEntry 32 } mplsTunnelStateTransitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of times the state (mplsTunnelOperStatus) of this tunnel instance has changed." ::= { mplsTunnelEntry 33 } mplsTunnelAdminStatus OBJECT-TYPE SYNTAX INTEGER { -- ready to pass packets up(1), down(2), -- in some test mode testing(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the desired operational status of this tunnel." ::= { mplsTunnelEntry 34 } mplsTunnelOperStatus OBJECT-TYPE SYNTAX INTEGER { -- ready to pass packets up(1), down(2), -- in some test mode testing(3), -- status cannot be determined unknown(4), dormant(5), -- some component is missing notPresent(6), Srinivasan, et al. Standards Track [Page 27] RFC 3812 MPLS-TE-STD-MIB June 2004 -- down due to the state of -- lower layer interfaces lowerLayerDown(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the actual operational status of this tunnel, which is typically but not limited to, a function of the state of individual segments of this tunnel." ::= { mplsTunnelEntry 35 } mplsTunnelRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. When a row in this table is in active(1) state, no objects in that row can be modified by the agent except mplsTunnelAdminStatus, mplsTunnelRowStatus and mplsTunnelStorageType." ::= { mplsTunnelEntry 36 } mplsTunnelStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this tunnel entry. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { volatile } ::= { mplsTunnelEntry 37 } -- End of mplsTunnelTable mplsTunnelHopListIndexNext OBJECT-TYPE SYNTAX MplsPathIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for mplsTunnelHopListIndex when creating entries in the mplsTunnelHopTable. If the number of unassigned entries is exhausted, a retrieval Srinivasan, et al. Standards Track [Page 28] RFC 3812 MPLS-TE-STD-MIB June 2004 operation will return a value of 0. This object may also return a value of 0 when the LSR is unable to accept conceptual row creation, for example, if the mplsTunnelHopTable is implemented as read-only. To obtain the value of mplsTunnelHopListIndex for a new entry in the mplsTunnelHopTable, the manager issues a management protocol retrieval operation to obtain the current value of mplsTunnelHopIndex. When the SET is performed to create a row in the mplsTunnelHopTable, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET succeeds and the Command Responder (agent) changes the value of this object, according to an implementation-specific algorithm. If the value is in use, however, the SET fails. The Network Management Application must then re-read this variable to obtain a new usable value." ::= { mplsTeObjects 3 } mplsTunnelHopTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsTunnelHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mplsTunnelHopTable is used to indicate the hops, strict or loose, for an instance of an MPLS tunnel defined in mplsTunnelTable, when it is established via signalling, for the outgoing direction of the tunnel. Thus at a transit LSR, this table contains the desired path of the tunnel from this LSR onwards. Each row in this table is indexed by mplsTunnelHopListIndex which corresponds to a group of hop lists or path options. Each row also has a secondary index mplsTunnelHopIndex, which indicates a group of hops (also known as a path option). Finally, the third index, mplsTunnelHopIndex indicates the specific hop information for a path option. In case we want to specify a particular interface on the originating LSR of an outgoing tunnel by which we want packets to exit the LSR, we specify this as the first hop for this tunnel in mplsTunnelHopTable." ::= { mplsTeObjects 4 } Srinivasan, et al. Standards Track [Page 29] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelHopEntry OBJECT-TYPE SYNTAX MplsTunnelHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a tunnel hop. An entry is created by a network administrator for signaled ERLSP set up by an MPLS signalling protocol." INDEX { mplsTunnelHopListIndex, mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex } ::= { mplsTunnelHopTable 1 } MplsTunnelHopEntry ::= SEQUENCE { mplsTunnelHopListIndex MplsPathIndex, mplsTunnelHopPathOptionIndex MplsPathIndex, mplsTunnelHopIndex MplsPathIndex, mplsTunnelHopAddrType TeHopAddressType, mplsTunnelHopIpAddr TeHopAddress, mplsTunnelHopIpPrefixLen InetAddressPrefixLength, mplsTunnelHopAsNumber TeHopAddressAS, mplsTunnelHopAddrUnnum TeHopAddressUnnum, mplsTunnelHopLspId MplsLSPID, mplsTunnelHopType INTEGER, mplsTunnelHopInclude TruthValue, mplsTunnelHopPathOptionName SnmpAdminString, mplsTunnelHopEntryPathComp INTEGER, mplsTunnelHopRowStatus RowStatus, mplsTunnelHopStorageType StorageType } mplsTunnelHopListIndex OBJECT-TYPE SYNTAX MplsPathIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Primary index into this table identifying a particular explicit route object." ::= { mplsTunnelHopEntry 1 } mplsTunnelHopPathOptionIndex OBJECT-TYPE SYNTAX MplsPathIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION Srinivasan, et al. Standards Track [Page 30] RFC 3812 MPLS-TE-STD-MIB June 2004 "Secondary index into this table identifying a particular group of hops representing a particular configured path. This is otherwise known as a path option." ::= { mplsTunnelHopEntry 2 } mplsTunnelHopIndex OBJECT-TYPE SYNTAX MplsPathIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Tertiary index into this table identifying a particular hop." ::= { mplsTunnelHopEntry 3 } mplsTunnelHopAddrType OBJECT-TYPE SYNTAX TeHopAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The Hop Address Type of this tunnel hop. The value of this object cannot be changed if the value of the corresponding mplsTunnelHopRowStatus object is 'active'. Note that lspid(5) is a valid option only for tunnels signaled via CRLDP. " DEFVAL { ipv4 } ::= { mplsTunnelHopEntry 4 } mplsTunnelHopIpAddr OBJECT-TYPE SYNTAX TeHopAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Tunnel Hop Address for this tunnel hop. The type of this address is determined by the value of the corresponding mplsTunnelHopAddrType. The value of this object cannot be changed if the value of the corresponding mplsTunnelHopRowStatus object is 'active'. " DEFVAL { '00000000'h } -- IPv4 address 0.0.0.0 ::= { mplsTunnelHopEntry 5 } mplsTunnelHopIpPrefixLen OBJECT-TYPE Srinivasan, et al. Standards Track [Page 31] RFC 3812 MPLS-TE-STD-MIB June 2004 SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is set to ipv4(1) or ipv6(2), then this value will contain an appropriate prefix length for the IP address in object mplsTunnelHopIpAddr. Otherwise this value is irrelevant and should be ignored. " DEFVAL { 32 } ::= { mplsTunnelHopEntry 6 } mplsTunnelHopAsNumber OBJECT-TYPE SYNTAX TeHopAddressAS MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is set to asnumber(3), then this value will contain the AS number of this hop. Otherwise the agent should set this object to zero- length string and the manager should ignore this." ::= { mplsTunnelHopEntry 7 } mplsTunnelHopAddrUnnum OBJECT-TYPE SYNTAX TeHopAddressUnnum MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is set to unnum(4), then this value will contain the interface identifier of the unnumbered interface for this hop. This object should be used in conjunction with mplsTunnelHopIpAddress which would contain the LSR Router ID in this case. Otherwise the agent should set this object to zero-length string and the manager should ignore this." ::= { mplsTunnelHopEntry 8 } mplsTunnelHopLspId OBJECT-TYPE SYNTAX MplsLSPID MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is set to lspid(5), then this value will contain the LSPID of a tunnel of this hop. The present tunnel being configured is tunneled through this hop (using label stacking). This object is otherwise insignificant and should Srinivasan, et al. Standards Track [Page 32] RFC 3812 MPLS-TE-STD-MIB June 2004 contain a value of 0 to indicate this fact." ::= { mplsTunnelHopEntry 9 } mplsTunnelHopType OBJECT-TYPE SYNTAX INTEGER { strict(1), loose(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether this tunnel hop is routed in a strict or loose fashion. The value of this object has no meaning if the mplsTunnelHopInclude object is set to 'false'." ::= { mplsTunnelHopEntry 10 } mplsTunnelHopInclude OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If this value is set to true, then this indicates that this hop must be included in the tunnel's path. If this value is set to 'false', then this hop must be avoided when calculating the path for this tunnel. The default value of this object is 'true', so that by default all indicated hops are included in the CSPF path computation. If this object is set to 'false' the value of mplsTunnelHopType should be ignored." DEFVAL { true } ::= { mplsTunnelHopEntry 11 } mplsTunnelHopPathOptionName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The description of this series of hops as they relate to the specified path option. The value of this object SHOULD be the same for each hop in the series that comprises a path option." ::= { mplsTunnelHopEntry 12 } mplsTunnelHopEntryPathComp OBJECT-TYPE SYNTAX INTEGER { Srinivasan, et al. Standards Track [Page 33] RFC 3812 MPLS-TE-STD-MIB June 2004 dynamic(1), -- CSPF computed explicit(2) -- strict hop } MAX-ACCESS read-create STATUS current DESCRIPTION "If this value is set to dynamic, then the user should only specify the source and destination of the path and expect that the CSPF will calculate the remainder of the path. If this value is set to explicit, the user should specify the entire path for the tunnel to take. This path may contain strict or loose hops. Each hop along a specific path SHOULD have this object set to the same value" ::= { mplsTunnelHopEntry 13 } mplsTunnelHopRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. When a row in this table is in active(1) state, no objects in that row can be modified by the agent except mplsTunnelHopRowStatus and mplsTunnelHopStorageType." ::= { mplsTunnelHopEntry 14 } mplsTunnelHopStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this Hop entry. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { volatile } ::= { mplsTunnelHopEntry 15 } -- End of mplsTunnelHopTable -- Begin of mplsTunnelResourceTable mplsTunnelResourceIndexNext OBJECT-TYPE SYNTAX Unsigned32 (0.. 2147483647) MAX-ACCESS read-only Srinivasan, et al. Standards Track [Page 34] RFC 3812 MPLS-TE-STD-MIB June 2004 STATUS current DESCRIPTION "This object contains the next appropriate value to be used for mplsTunnelResourceIndex when creating entries in the mplsTunnelResourceTable. If the number of unassigned entries is exhausted, a retrieval operation will return a value of 0. This object may also return a value of 0 when the LSR is unable to accept conceptual row creation, for example, if the mplsTunnelTable is implemented as read-only. To obtain the mplsTunnelResourceIndex value for a new entry, the manager must first issue a management protocol retrieval operation to obtain the current value of this object. When the SET is performed to create a row in the mplsTunnelResourceTable, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET succeeds and the Command Responder (agent) changes the value of this object, according to an implementation-specific algorithm. If the value is in use, however, the SET fails. The Network Management Application must then re-read this variable to obtain a new usable value." ::= { mplsTeObjects 5 } mplsTunnelResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsTunnelResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mplsTunnelResourceTable allows a manager to specify which resources are desired for an MPLS tunnel. This table also allows several tunnels to point to a single entry in this table, implying that these tunnels should share resources." ::= { mplsTeObjects 6 } mplsTunnelResourceEntry OBJECT-TYPE SYNTAX MplsTunnelResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a set of resources for an MPLS tunnel. An entry can be created by a Srinivasan, et al. Standards Track [Page 35] RFC 3812 MPLS-TE-STD-MIB June 2004 network administrator or by an SNMP agent as instructed by any MPLS signalling protocol. An entry in this table referenced by a tunnel instance with zero mplsTunnelInstance value indicates a configured set of resource parameter. An entry referenced by a tunnel instance with a non-zero mplsTunnelInstance reflects the in-use resource parameters for the tunnel instance which may have been negotiated or modified by the MPLS signaling protocols." INDEX { mplsTunnelResourceIndex } ::= { mplsTunnelResourceTable 1 } MplsTunnelResourceEntry ::= SEQUENCE { mplsTunnelResourceIndex Unsigned32, mplsTunnelResourceMaxRate MplsBitRate, mplsTunnelResourceMeanRate MplsBitRate, mplsTunnelResourceMaxBurstSize MplsBurstSize, mplsTunnelResourceMeanBurstSize MplsBurstSize, mplsTunnelResourceExBurstSize MplsBurstSize, mplsTunnelResourceFrequency INTEGER, mplsTunnelResourceWeight Unsigned32, mplsTunnelResourceRowStatus RowStatus, mplsTunnelResourceStorageType StorageType } mplsTunnelResourceIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies this row." ::= { mplsTunnelResourceEntry 1 } mplsTunnelResourceMaxRate OBJECT-TYPE SYNTAX MplsBitRate UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum rate in bits/second. Note that setting mplsTunnelResourceMaxRate, mplsTunnelResourceMeanRate, and mplsTunnelResourceMaxBurstSize to 0 indicates best- effort treatment." ::= { mplsTunnelResourceEntry 2 } mplsTunnelResourceMeanRate OBJECT-TYPE Srinivasan, et al. Standards Track [Page 36] RFC 3812 MPLS-TE-STD-MIB June 2004 SYNTAX MplsBitRate UNITS "kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "This object is copied into an instance of mplsTrafficParamMeanRate in the mplsTrafficParamTable. The OID of this table entry is then copied into the corresponding mplsInSegmentTrafficParamPtr." ::= { mplsTunnelResourceEntry 3 } mplsTunnelResourceMaxBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum burst size in bytes." ::= { mplsTunnelResourceEntry 4 } mplsTunnelResourceMeanBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The mean burst size in bytes. The implementations which do not implement this variable must return a noSuchObject exception for this object and must not allow a user to set this object." ::= { mplsTunnelResourceEntry 5 } mplsTunnelResourceExBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The Excess burst size in bytes. The implementations which do not implement this variable must return noSuchObject exception for this object and must not allow a user to set this value." REFERENCE "CR-LDP Specification, Section 4.3." ::= { mplsTunnelResourceEntry 6 } mplsTunnelResourceFrequency OBJECT-TYPE Srinivasan, et al. Standards Track [Page 37] RFC 3812 MPLS-TE-STD-MIB June 2004 SYNTAX INTEGER { unspecified(1), frequent(2), veryFrequent(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The granularity of the availability of committed rate. The implementations which do not implement this variable must return unspecified(1) for this value and must not allow a user to set this value." REFERENCE "CR-LDP Specification, Section 4.3." ::= { mplsTunnelResourceEntry 7 } mplsTunnelResourceWeight OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The relative weight for using excess bandwidth above its committed rate. The value of 0 means that weight is not applicable for the CR-LSP." REFERENCE "CR-LDP Specification, Section 4.3." ::= { mplsTunnelResourceEntry 8 } mplsTunnelResourceRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. When a row in this table is in active(1) state, no objects in that row can be modified by the agent except mplsTunnelResourceRowStatus and mplsTunnelResourceStorageType." ::= { mplsTunnelResourceEntry 9 } mplsTunnelResourceStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this Hop entry. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects Srinivasan, et al. Standards Track [Page 38] RFC 3812 MPLS-TE-STD-MIB June 2004 in the row." DEFVAL { volatile } ::= { mplsTunnelResourceEntry 10 } -- End mplsTunnelResourceTable -- Tunnel Actual Route Hop table. mplsTunnelARHopTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mplsTunnelARHopTable is used to indicate the hops for an MPLS tunnel defined in mplsTunnelTable, as reported by the MPLS signalling protocol. Thus at a transit LSR, this table (if the table is supported and if the signaling protocol is recording actual route information) contains the actual route of the whole tunnel. If the signaling protocol is not recording the actual route, this table MAY report the information from the mplsTunnelHopTable or the mplsTunnelCHopTable. Each row in this table is indexed by mplsTunnelARHopListIndex. Each row also has a secondary index mplsTunnelARHopIndex, corresponding to the next hop that this row corresponds to. Please note that since the information necessary to build entries within this table is not provided by some MPLS signalling protocols, implementation of this table is optional. Furthermore, since the information in this table is actually provided by the MPLS signalling protocol after the path has been set-up, the entries in this table are provided only for observation, and hence, all variables in this table are accessible exclusively as read- only. Note also that the contents of this table may change while it is being read because of re-routing activities. A network administrator may verify that the actual route read is consistent by reference to the mplsTunnelLastPathChange object." ::= { mplsTeObjects 7 } Srinivasan, et al. Standards Track [Page 39] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelARHopEntry OBJECT-TYPE SYNTAX MplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a tunnel hop. An entry is created by the agent for signaled ERLSP set up by an MPLS signalling protocol." INDEX { mplsTunnelARHopListIndex, mplsTunnelARHopIndex } ::= { mplsTunnelARHopTable 1 } MplsTunnelARHopEntry ::= SEQUENCE { mplsTunnelARHopListIndex MplsPathIndex, mplsTunnelARHopIndex MplsPathIndex, mplsTunnelARHopAddrType TeHopAddressType, mplsTunnelARHopIpAddr TeHopAddress, mplsTunnelARHopAddrUnnum TeHopAddressUnnum, mplsTunnelARHopLspId MplsLSPID } mplsTunnelARHopListIndex OBJECT-TYPE SYNTAX MplsPathIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Primary index into this table identifying a particular recorded hop list." ::= { mplsTunnelARHopEntry 1 } mplsTunnelARHopIndex OBJECT-TYPE SYNTAX MplsPathIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Secondary index into this table identifying the particular hop." ::= { mplsTunnelARHopEntry 2 } mplsTunnelARHopAddrType OBJECT-TYPE SYNTAX TeHopAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The Hop Address Type of this tunnel hop. Note that lspid(5) is a valid option only for tunnels signaled via CRLDP." DEFVAL { ipv4 } Srinivasan, et al. Standards Track [Page 40] RFC 3812 MPLS-TE-STD-MIB June 2004 ::= { mplsTunnelARHopEntry 3 } mplsTunnelARHopIpAddr OBJECT-TYPE SYNTAX TeHopAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Tunnel Hop Address for this tunnel hop. The type of this address is determined by the value of the corresponding mplsTunnelARHopAddrType. If mplsTunnelARHopAddrType is set to unnum(4), then this value contains the LSR Router ID of the unnumbered interface. Otherwise the agent SHOULD set this object to the zero-length string and the manager should ignore this object." DEFVAL { '00000000'h } -- IPv4 address 0.0.0.0 ::= { mplsTunnelARHopEntry 4 } mplsTunnelARHopAddrUnnum OBJECT-TYPE SYNTAX TeHopAddressUnnum MAX-ACCESS read-only STATUS current DESCRIPTION "If mplsTunnelARHopAddrType is set to unnum(4), then this value will contain the interface identifier of the unnumbered interface for this hop. This object should be used in conjunction with mplsTunnelARHopIpAddr which would contain the LSR Router ID in this case. Otherwise the agent should set this object to zero-length string and the manager should ignore this." ::= { mplsTunnelARHopEntry 5 } mplsTunnelARHopLspId OBJECT-TYPE SYNTAX MplsLSPID MAX-ACCESS read-only STATUS current DESCRIPTION "If mplsTunnelARHopAddrType is set to lspid(5), then this value will contain the LSP ID of this hop. This object is otherwise insignificant and should contain a value of 0 to indicate this fact." ::= { mplsTunnelARHopEntry 6 } -- End of mplsTunnelARHopTable Srinivasan, et al. Standards Track [Page 41] RFC 3812 MPLS-TE-STD-MIB June 2004 -- Tunnel Computed Hop table. mplsTunnelCHopTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mplsTunnelCHopTable is used to indicate the hops, strict or loose, for an MPLS tunnel defined in mplsTunnelTable, as computed by a constraint- based routing protocol, based on the mplsTunnelHopTable for the outgoing direction of the tunnel. Thus at a transit LSR, this table (if the table is supported) MAY contain the path computed by the CSPF engine on (or on behalf of) this LSR. Each row in this table is indexed by mplsTunnelCHopListIndex. Each row also has a secondary index mplsTunnelCHopIndex, corresponding to the next hop that this row corresponds to. In case we want to specify a particular interface on the originating LSR of an outgoing tunnel by which we want packets to exit the LSR, we specify this as the first hop for this tunnel in mplsTunnelCHopTable. Please note that since the information necessary to build entries within this table may not be supported by some LSRs, implementation of this table is optional. Furthermore, since the information in this table describes the path computed by the CSPF engine the entries in this table are read-only." ::= { mplsTeObjects 8 } mplsTunnelCHopEntry OBJECT-TYPE SYNTAX MplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a tunnel hop. An entry in this table is created by a path computation engine using CSPF techniques applied to the information collected by routing protocols and the hops specified in the corresponding mplsTunnelHopTable." INDEX { mplsTunnelCHopListIndex, mplsTunnelCHopIndex } ::= { mplsTunnelCHopTable 1 } Srinivasan, et al. Standards Track [Page 42] RFC 3812 MPLS-TE-STD-MIB June 2004 MplsTunnelCHopEntry ::= SEQUENCE { mplsTunnelCHopListIndex MplsPathIndex, mplsTunnelCHopIndex MplsPathIndex, mplsTunnelCHopAddrType TeHopAddressType, mplsTunnelCHopIpAddr TeHopAddress, mplsTunnelCHopIpPrefixLen InetAddressPrefixLength, mplsTunnelCHopAsNumber TeHopAddressAS, mplsTunnelCHopAddrUnnum TeHopAddressUnnum, mplsTunnelCHopLspId MplsLSPID, mplsTunnelCHopType INTEGER } mplsTunnelCHopListIndex OBJECT-TYPE SYNTAX MplsPathIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Primary index into this table identifying a particular computed hop list." ::= { mplsTunnelCHopEntry 1 } mplsTunnelCHopIndex OBJECT-TYPE SYNTAX MplsPathIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Secondary index into this table identifying the particular hop." ::= { mplsTunnelCHopEntry 2 } mplsTunnelCHopAddrType OBJECT-TYPE SYNTAX TeHopAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The Hop Address Type of this tunnel hop. Note that lspid(5) is a valid option only for tunnels signaled via CRLDP." DEFVAL { ipv4 } ::= { mplsTunnelCHopEntry 3 } mplsTunnelCHopIpAddr OBJECT-TYPE SYNTAX TeHopAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Tunnel Hop Address for this tunnel hop. Srinivasan, et al. Standards Track [Page 43] RFC 3812 MPLS-TE-STD-MIB June 2004 The type of this address is determined by the value of the corresponding mplsTunnelCHopAddrType. If mplsTunnelCHopAddrType is set to unnum(4), then this value will contain the LSR Router ID of the unnumbered interface. Otherwise the agent should set this object to the zero-length string and the manager SHOULD ignore this object." DEFVAL { '00000000'h } -- IPv4 address 0.0.0.0 ::= { mplsTunnelCHopEntry 4 } mplsTunnelCHopIpPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "If mplsTunnelCHopAddrType is set to ipv4(1) or ipv6(2), then this value will contain an appropriate prefix length for the IP address in object mplsTunnelCHopIpAddr. Otherwise this value is irrelevant and should be ignored. " DEFVAL { 32 } ::= { mplsTunnelCHopEntry 5 } mplsTunnelCHopAsNumber OBJECT-TYPE SYNTAX TeHopAddressAS MAX-ACCESS read-only STATUS current DESCRIPTION "If mplsTunnelCHopAddrType is set to asnumber(3), then this value will contain the AS number of this hop. Otherwise the agent should set this object to zero-length string and the manager should ignore this." ::= { mplsTunnelCHopEntry 6 } mplsTunnelCHopAddrUnnum OBJECT-TYPE SYNTAX TeHopAddressUnnum MAX-ACCESS read-only STATUS current DESCRIPTION "If mplsTunnelCHopAddrType is set to unnum(4), then this value will contain the unnumbered interface identifier of this hop. This object should be used in conjunction with mplsTunnelCHopIpAddr which would contain the LSR Router ID in this case. Srinivasan, et al. Standards Track [Page 44] RFC 3812 MPLS-TE-STD-MIB June 2004 Otherwise the agent should set this object to zero- length string and the manager should ignore this." ::= { mplsTunnelCHopEntry 7 } mplsTunnelCHopLspId OBJECT-TYPE SYNTAX MplsLSPID MAX-ACCESS read-only STATUS current DESCRIPTION "If mplsTunnelCHopAddrType is set to lspid(5), then this value will contain the LSP ID of this hop. This object is otherwise insignificant and should contain a value of 0 to indicate this fact." ::= { mplsTunnelCHopEntry 8 } mplsTunnelCHopType OBJECT-TYPE SYNTAX INTEGER { strict(1), loose(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes whether this is tunnel hop is routed in a strict or loose fashion." ::= { mplsTunnelCHopEntry 9 } -- End of mplsTunnelCHopTable -- MPLS Tunnel Performance Table. mplsTunnelPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsTunnelPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides per-tunnel instance MPLS performance information." ::= { mplsTeObjects 9 } mplsTunnelPerfEntry OBJECT-TYPE SYNTAX MplsTunnelPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the LSR for every tunnel. Its is an extension to mplsTunnelEntry." Srinivasan, et al. Standards Track [Page 45] RFC 3812 MPLS-TE-STD-MIB June 2004 AUGMENTS { mplsTunnelEntry } ::= { mplsTunnelPerfTable 1 } MplsTunnelPerfEntry ::= SEQUENCE { mplsTunnelPerfPackets Counter32, mplsTunnelPerfHCPackets Counter64, mplsTunnelPerfErrors Counter32, mplsTunnelPerfBytes Counter32, mplsTunnelPerfHCBytes Counter64 } mplsTunnelPerfPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets forwarded by the tunnel. This object should represents the 32-bit value of the least significant part of the 64-bit value if both mplsTunnelPerfHCPackets is returned." ::= { mplsTunnelPerfEntry 1 } mplsTunnelPerfHCPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High capacity counter for number of packets forwarded by the tunnel. " ::= { mplsTunnelPerfEntry 2 } mplsTunnelPerfErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets dropped because of errors or for other reasons." ::= { mplsTunnelPerfEntry 3 } mplsTunnelPerfBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bytes forwarded by the tunnel. This object should represents the 32-bit Srinivasan, et al. Standards Track [Page 46] RFC 3812 MPLS-TE-STD-MIB June 2004 value of the least significant part of the 64-bit value if both mplsTunnelPerfHCBytes is returned." ::= { mplsTunnelPerfEntry 4 } mplsTunnelPerfHCBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High capacity counter for number of bytes forwarded by the tunnel." ::= { mplsTunnelPerfEntry 5 } -- End of mplsTunnelPerfTable -- CR-LDP Tunnel Resource Table mplsTunnelCRLDPResTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsTunnelCRLDPResEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mplsTunnelCRLDPResTable allows a manager to specify which CR-LDP-specific resources are desired for an MPLS tunnel if that tunnel is signaled using CR-LDP. Note that these attributes are in addition to those specified in mplsTunnelResourceTable. This table also allows several tunnels to point to a single entry in this table, implying that these tunnels should share resources." ::= { mplsTeObjects 10 } mplsTunnelCRLDPResEntry OBJECT-TYPE SYNTAX MplsTunnelCRLDPResEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a set of resources for an MPLS tunnel established using CRLDP (mplsTunnelSignallingProto equal to crldp (3)). An entry can be created by a network administrator or by an SNMP agent as instructed by any MPLS signalling protocol." INDEX { mplsTunnelResourceIndex } ::= { mplsTunnelCRLDPResTable 1 } Srinivasan, et al. Standards Track [Page 47] RFC 3812 MPLS-TE-STD-MIB June 2004 MplsTunnelCRLDPResEntry ::= SEQUENCE { mplsTunnelCRLDPResMeanBurstSize MplsBurstSize, mplsTunnelCRLDPResExBurstSize MplsBurstSize, mplsTunnelCRLDPResFrequency INTEGER, mplsTunnelCRLDPResWeight Unsigned32, mplsTunnelCRLDPResFlags Unsigned32, mplsTunnelCRLDPResRowStatus RowStatus, mplsTunnelCRLDPResStorageType StorageType } mplsTunnelCRLDPResMeanBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The mean burst size in bytes." ::= { mplsTunnelCRLDPResEntry 1 } mplsTunnelCRLDPResExBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The Excess burst size in bytes." REFERENCE "CR-LDP Specification, Section 4.3." ::= { mplsTunnelCRLDPResEntry 2 } mplsTunnelCRLDPResFrequency OBJECT-TYPE SYNTAX INTEGER { unspecified(1), frequent(2), veryFrequent(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The granularity of the availability of committed rate." REFERENCE "CR-LDP Specification, Section 4.3." ::= { mplsTunnelCRLDPResEntry 3 } mplsTunnelCRLDPResWeight OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-create Srinivasan, et al. Standards Track [Page 48] RFC 3812 MPLS-TE-STD-MIB June 2004 STATUS current DESCRIPTION "The relative weight for using excess bandwidth above its committed rate. The value of 0 means that weight is not applicable for the CR-LSP." REFERENCE "CR-LDP Specification, Section 4.3." DEFVAL { 0 } ::= { mplsTunnelCRLDPResEntry 4 } mplsTunnelCRLDPResFlags OBJECT-TYPE SYNTAX Unsigned32 (0..63) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the 1 byte Flags conveyed as part of the traffic parameters during the establishment of the CRLSP. The bits in this object are to be interpreted as follows. +--+--+--+--+--+--+--+--+ | Res |F6|F5|F4|F3|F2|F1| +--+--+--+--+--+--+--+--+ Res - These bits are reserved. Zero on transmission. Ignored on receipt. F1 - Corresponds to the PDR. F2 - Corresponds to the PBS. F3 - Corresponds to the CDR. F4 - Corresponds to the CBS. F5 - Corresponds to the EBS. F6 - Corresponds to the Weight. Each flag if is a Negotiable Flag corresponding to a Traffic Parameter. The Negotiable Flag value zero denotes Not Negotiable and value one denotes Negotiable." REFERENCE "1. Section 4.3, Constraint-Based LSP Setup using LDP, Jamoussi (Editor), RFC 3212, January 2002" DEFVAL { 0 } ::= { mplsTunnelCRLDPResEntry 5 } mplsTunnelCRLDPResRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Srinivasan, et al. Standards Track [Page 49] RFC 3812 MPLS-TE-STD-MIB June 2004 "This variable is used to create, modify, and/or delete a row in this table. When a row in this table is in active(1) state, no objects in that row can be modified by the agent except mplsTunnelCRLDPResRowStatus and mplsTunnelCRLDPResStorageType." ::= { mplsTunnelCRLDPResEntry 6 } mplsTunnelCRLDPResStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this CR-LDP Resource entry. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { volatile } ::= { mplsTunnelCRLDPResEntry 7 } -- Notifications. mplsTunnelNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true, then it enables the generation of mplsTunnelUp and mplsTunnelDown traps, otherwise these traps are not emitted." DEFVAL { false } ::= { mplsTeObjects 11 } mplsTunnelUp NOTIFICATION-TYPE OBJECTS { mplsTunnelAdminStatus, mplsTunnelOperStatus } STATUS current DESCRIPTION "This notification is generated when a mplsTunnelOperStatus object for one of the configured tunnels is about to leave the down state and transition into some other state (but not into the notPresent state). This other state is indicated by the included value of mplsTunnelOperStatus." Srinivasan, et al. Standards Track [Page 50] RFC 3812 MPLS-TE-STD-MIB June 2004 ::= { mplsTeNotifications 1 } mplsTunnelDown NOTIFICATION-TYPE OBJECTS { mplsTunnelAdminStatus, mplsTunnelOperStatus } STATUS current DESCRIPTION "This notification is generated when a mplsTunnelOperStatus object for one of the configured tunnels is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of mplsTunnelOperStatus." ::= { mplsTeNotifications 2 } mplsTunnelRerouted NOTIFICATION-TYPE OBJECTS { mplsTunnelAdminStatus, mplsTunnelOperStatus } STATUS current DESCRIPTION "This notification is generated when a tunnel is rerouted. If the mplsTunnelARHopTable is used, then this tunnel instance's entry in the mplsTunnelARHopTable MAY contain the new path for this tunnel some time after this trap is issued by the agent." ::= { mplsTeNotifications 3 } mplsTunnelReoptimized NOTIFICATION-TYPE OBJECTS { mplsTunnelAdminStatus, mplsTunnelOperStatus } STATUS current DESCRIPTION "This notification is generated when a tunnel is reoptimized. If the mplsTunnelARHopTable is used, then this tunnel instance's entry in the mplsTunnelARHopTable MAY contain the new path for this tunnel some time after this trap is issued by the agent." ::= { mplsTeNotifications 4 } -- End of notifications. Srinivasan, et al. Standards Track [Page 51] RFC 3812 MPLS-TE-STD-MIB June 2004 -- Module compliance. mplsTeGroups OBJECT IDENTIFIER ::= { mplsTeConformance 1 } mplsTeCompliances OBJECT IDENTIFIER ::= { mplsTeConformance 2 } -- Compliance requirement for fully compliant implementations. mplsTeModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support the MPLS-TE-STD-MIB module." MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE -- this module -- The mandatory group has to be implemented by all -- LSRs that originate/terminate ESLSPs/tunnels. -- In addition, depending on the type of tunnels -- supported, other groups become mandatory as -- explained below. MANDATORY-GROUPS { mplsTunnelGroup, mplsTunnelScalarGroup } GROUP mplsTunnelManualGroup DESCRIPTION "This group is mandatory for devices which support manual configuration of tunnels." GROUP mplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices which support signaled tunnel set up." GROUP mplsTunnelIsNotIntfcGroup DESCRIPTION "This group is mandatory for devices which support Srinivasan, et al. Standards Track [Page 52] RFC 3812 MPLS-TE-STD-MIB June 2004 tunnels that are not interfaces." GROUP mplsTunnelIsIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are interfaces." GROUP mplsTunnelCRLDPResOptionalGroup DESCRIPTION "Objects in this group are required by implementations supporting the CR-LDP protocol for signalling of TE tunnels." GROUP mplsTeNotificationGroup DESCRIPTION "This group is mandatory for those implementations which can implement the notifications contained in this group." OBJECT mplsTunnelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." OBJECT mplsTunnelHopRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." OBJECT mplsTunnelCRLDPResRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." ::= { mplsTeCompliances 1 } -- Compliance requirement for read-only implementations. mplsTeModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current Srinivasan, et al. Standards Track [Page 53] RFC 3812 MPLS-TE-STD-MIB June 2004 DESCRIPTION "Compliance requirement for implementations that only provide read-only support for MPLS-TE-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB modules." MODULE -- this module -- mplsTunnelTable MANDATORY-GROUPS { mplsTunnelGroup, mplsTunnelScalarGroup } GROUP mplsTunnelManualGroup DESCRIPTION "This group is mandatory for devices which support manual configuration of tunnels." GROUP mplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices which support signaled tunnel set up." GROUP mplsTunnelIsNotIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are not interfaces." GROUP mplsTunnelIsIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are interfaces." GROUP mplsTunnelCRLDPResOptionalGroup DESCRIPTION "Objects in this group are required by implementations supporting the CR-LDP protocol for signalling of TE tunnels." GROUP mplsTeNotificationGroup DESCRIPTION "This group is mandatory for those implementations which can implement the notifications contained in this group." -- mplsTunnelTable Srinivasan, et al. Standards Track [Page 54] RFC 3812 MPLS-TE-STD-MIB June 2004 OBJECT mplsTunnelName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelIsIf MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelIfIndex DESCRIPTION "Write access is not required." OBJECT mplsTunnelXCPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelSignallingProto MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelSetupPrio MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHoldingPrio MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelSessionAttributes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelLocalProtectInUse MIN-ACCESS read-only DESCRIPTION "Write access is not required." Srinivasan, et al. Standards Track [Page 55] RFC 3812 MPLS-TE-STD-MIB June 2004 OBJECT mplsTunnelResourcePointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelInstancePriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopTableIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelIncludeAnyAffinity MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelIncludeAllAffinity MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelExcludeAnyAffinity MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelPathInUse MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelRole MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelAdminStatus SYNTAX INTEGER { up (1), down (2) } MIN-ACCESS read-only DESCRIPTION "Only up and down states must be supported. Write access is not required." OBJECT mplsTunnelRowStatus Srinivasan, et al. Standards Track [Page 56] RFC 3812 MPLS-TE-STD-MIB June 2004 SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- mplsTunnelHopTable OBJECT mplsTunnelHopAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopIpAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopIpPrefixLen MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopAddrUnnum MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopAsNumber MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopLspId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopType SYNTAX INTEGER { strict(1) } MIN-ACCESS read-only DESCRIPTION "loose(2) need not be supported. Write access is not required." OBJECT mplsTunnelHopInclude MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopPathOptionName MIN-ACCESS read-only DESCRIPTION "Write access is not required." Srinivasan, et al. Standards Track [Page 57] RFC 3812 MPLS-TE-STD-MIB June 2004 OBJECT mplsTunnelHopEntryPathComp MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelHopStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- mplsTunnelResourceTable OBJECT mplsTunnelResourceMaxRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelResourceMeanRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelResourceMaxBurstSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelResourceMeanBurstSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelResourceExBurstSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelResourceFrequency MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelResourceWeight MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelResourceRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." Srinivasan, et al. Standards Track [Page 58] RFC 3812 MPLS-TE-STD-MIB June 2004 OBJECT mplsTunnelResourceStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- mplsTunnelCRLDPResTable OBJECT mplsTunnelCRLDPResMeanBurstSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelCRLDPResExBurstSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelCRLDPResFrequency MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelCRLDPResWeight MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelCRLDPResFlags MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelCRLDPResRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsTunnelCRLDPResStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mplsTeCompliances 2 } -- Units of conformance. mplsTunnelGroup OBJECT-GROUP OBJECTS { mplsTunnelIndexNext, mplsTunnelName, mplsTunnelDescr, mplsTunnelOwner, mplsTunnelXCPointer, mplsTunnelIfIndex, Srinivasan, et al. Standards Track [Page 59] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelHopTableIndex, mplsTunnelARHopTableIndex, mplsTunnelCHopTableIndex, mplsTunnelAdminStatus, mplsTunnelOperStatus, mplsTunnelRowStatus, mplsTunnelNotificationEnable, mplsTunnelStorageType, mplsTunnelConfigured, mplsTunnelActive, mplsTunnelPrimaryInstance, mplsTunnelPrimaryUpTime, mplsTunnelPathChanges, mplsTunnelLastPathChange, mplsTunnelCreationTime, mplsTunnelStateTransitions, mplsTunnelIncludeAnyAffinity, mplsTunnelIncludeAllAffinity, mplsTunnelExcludeAnyAffinity, mplsTunnelPerfPackets, mplsTunnelPerfHCPackets, mplsTunnelPerfErrors, mplsTunnelPerfBytes, mplsTunnelPerfHCBytes, mplsTunnelResourcePointer, mplsTunnelInstancePriority, mplsTunnelPathInUse, mplsTunnelRole, mplsTunnelTotalUpTime, mplsTunnelInstanceUpTime, mplsTunnelResourceIndexNext, mplsTunnelResourceMaxRate, mplsTunnelResourceMeanRate, mplsTunnelResourceMaxBurstSize, mplsTunnelResourceMeanBurstSize, mplsTunnelResourceExBurstSize, mplsTunnelResourceFrequency, mplsTunnelResourceWeight, mplsTunnelResourceRowStatus, mplsTunnelResourceStorageType, mplsTunnelARHopAddrType, mplsTunnelARHopIpAddr, mplsTunnelARHopAddrUnnum, mplsTunnelARHopLspId, mplsTunnelCHopAddrType, mplsTunnelCHopIpAddr, mplsTunnelCHopIpPrefixLen, mplsTunnelCHopAsNumber, Srinivasan, et al. Standards Track [Page 60] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTunnelCHopAddrUnnum, mplsTunnelCHopLspId, mplsTunnelCHopType } STATUS current DESCRIPTION "Necessary, but not sufficient, set of objects to implement tunnels. In addition, depending on the type of the tunnels supported (for example, manually configured or signaled, persistent or non- persistent, etc.), the following other groups defined below are mandatory: mplsTunnelManualGroup and/or mplsTunnelSignaledGroup, mplsTunnelIsNotIntfcGroup and/or mplsTunnelIsIntfcGroup." ::= { mplsTeGroups 1 } mplsTunnelManualGroup OBJECT-GROUP OBJECTS { mplsTunnelSignallingProto } STATUS current DESCRIPTION "Object(s) needed to implement manually configured tunnels." ::= { mplsTeGroups 2 } mplsTunnelSignaledGroup OBJECT-GROUP OBJECTS { mplsTunnelSetupPrio, mplsTunnelHoldingPrio, mplsTunnelSignallingProto, mplsTunnelLocalProtectInUse, mplsTunnelSessionAttributes, mplsTunnelHopListIndexNext, mplsTunnelHopAddrType, mplsTunnelHopIpAddr, mplsTunnelHopIpPrefixLen, mplsTunnelHopAddrUnnum, mplsTunnelHopAsNumber, mplsTunnelHopLspId, mplsTunnelHopType, mplsTunnelHopInclude, mplsTunnelHopPathOptionName, mplsTunnelHopEntryPathComp, mplsTunnelHopRowStatus, mplsTunnelHopStorageType } STATUS current DESCRIPTION Srinivasan, et al. Standards Track [Page 61] RFC 3812 MPLS-TE-STD-MIB June 2004 "Objects needed to implement signaled tunnels." ::= { mplsTeGroups 3 } mplsTunnelScalarGroup OBJECT-GROUP OBJECTS { mplsTunnelConfigured, mplsTunnelActive, mplsTunnelTEDistProto, mplsTunnelMaxHops, mplsTunnelNotificationMaxRate } STATUS current DESCRIPTION "Scalar object needed to implement MPLS tunnels." ::= { mplsTeGroups 4 } mplsTunnelIsIntfcGroup OBJECT-GROUP OBJECTS { mplsTunnelIsIf } STATUS current DESCRIPTION "Objects needed to implement tunnels that are interfaces." ::= { mplsTeGroups 5 } mplsTunnelIsNotIntfcGroup OBJECT-GROUP OBJECTS { mplsTunnelIsIf } STATUS current DESCRIPTION "Objects needed to implement tunnels that are not interfaces." ::= { mplsTeGroups 6 } mplsTunnelCRLDPResOptionalGroup OBJECT-GROUP OBJECTS { mplsTunnelCRLDPResMeanBurstSize, mplsTunnelCRLDPResExBurstSize, mplsTunnelCRLDPResFrequency, mplsTunnelCRLDPResWeight, mplsTunnelCRLDPResFlags, mplsTunnelCRLDPResRowStatus, mplsTunnelCRLDPResStorageType } STATUS current DESCRIPTION "Set of objects implemented for resources applicable for tunnels signaled using CR-LDP." ::= { mplsTeGroups 7 } Srinivasan, et al. Standards Track [Page 62] RFC 3812 MPLS-TE-STD-MIB June 2004 mplsTeNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mplsTunnelUp, mplsTunnelDown, mplsTunnelRerouted, mplsTunnelReoptimized } STATUS current DESCRIPTION "Set of notifications implemented in this module. None is mandatory." ::= { mplsTeGroups 8 } END 12. Security Considerations It is clear that this MIB module is potentially useful for the monitoring of MPLS TE tunnels. This MIB module can also be used for the configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - the mplsTunnelTable, mplsTunnelHopTable, mplsTunnelResourceTable, and mplsTunnelCRLDPResTable collectively contain objects to provision MPLS tunnels, tunnel hops, and tunnel resources. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if a tunnel has been established. The use of stronger mechanisms, such as SNMPv3 security, should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly Srinivasan, et al. Standards Track [Page 63] RFC 3812 MPLS-TE-STD-MIB June 2004 to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: - the mplsTunnelTable, mplsTunnelHopTable, mplsTunnelResourceTable, mplsTunnelARHopTable, mplsTunnelCHopTable, mplsTunnelPerfTable, and mplsTunnelCRLDPResTable collectively show the MPLS-TE tunnel network topology and its performance characteristics. If an Administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and cryptographic security enabled. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to only those principals (users) that have legitimate rights to those objects. 13. Acknowledgments We wish to thank Adrian Farrel, Bert Wijnen, Eric Gray, Joan Cucchiara, Patrick Kerharo, Paul Langille, Marcus Brunner, Mike MacFaden, and Mike Piecuch for their comments on this document. Comments should be made directly to the MPLS mailing list at mpls@uu.net. 14. IANA Considerations As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB [RFC3811], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There are 4 MPLS MIB Modules contained in this document, each of the following "IANA Considerations" subsections requests IANA for a new assignment under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. Srinivasan, et al. Standards Track [Page 64] RFC 3812 MPLS-TE-STD-MIB June 2004 14.1. IANA Considerations for MPLS-TE-STD-MIB The IANA has assigned { mplsStdMIB 3 } to the MPLS-TE-STD-MIB module specified in this document. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB ", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R, Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. Srinivasan, et al. Standards Track [Page 65] RFC 3812 MPLS-TE-STD-MIB June 2004 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "TextualConventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching (LSR) Router Management Information Base (MIB)", RFC 3813, June 2004. 15.2. Informative References [MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", Work in Progress, September 2003. [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statement for Internet Standard Management Framework", RFC 3410, December 2002. Srinivasan, et al. Standards Track [Page 66] RFC 3812 MPLS-TE-STD-MIB June 2004 16. Authors' Addresses Cheenu Srinivasan Bloomberg L.P. 499 Park Ave., New York, NY 10022 Phone: +1-212-893-3682 EMail: cheenu@bloomberg.net Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Phone: +1-408-571-3516 EMail: arunv@force10networks.com Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 EMail: tnadeau@cisco.com Srinivasan, et al. Standards Track [Page 67] RFC 3812 MPLS-TE-STD-MIB June 2004 17. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Srinivasan, et al. Standards Track [Page 68] snmp-mibs-downloader-1.1/mibrfcs/rfc3813.txt0000644000000000000000000034263011402176071015570 0ustar Network Working Group C. Srinivasan Request for Comments: 3813 Bloomberg L.P. Category: Standard Track A. Viswanathan Force10 Networks, Inc. T. Nadeau Cisco Systems, Inc. June 2004 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). Srinivasan, et al. Standards Track [Page 1] RFC 3813 MPLS LSR MIB June 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The SNMP Management Framework. . . . . . . . . . . . . . . . . 3 4. Outline. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Summary of LSR MIB Module. . . . . . . . . . . . . . . . 4 5. Brief Description of MIB Module Objects. . . . . . . . . . . . 4 5.1. mplsInterfaceTable . . . . . . . . . . . . . . . . . . . 4 5.2. mplsInterfacePerfTable . . . . . . . . . . . . . . . . . 4 5.3. mplsInSegmentTable . . . . . . . . . . . . . . . . . . . 5 5.4. mplsInSegmentPerfTable . . . . . . . . . . . . . . . . . 5 5.5. mplsOutSegmentTable. . . . . . . . . . . . . . . . . . . 5 5.6. mplsOutSegmentPerfTable. . . . . . . . . . . . . . . . . 5 5.7. mplsXCTable. . . . . . . . . . . . . . . . . . . . . . . 5 5.8. mplsLabelStackTable. . . . . . . . . . . . . . . . . . . 6 5.9. mplsInSegmentMapTable. . . . . . . . . . . . . . . . . . 6 6. Use of 32-bit and 64-bit Counters. . . . . . . . . . . . . . . 6 7. Example of LSP Setup . . . . . . . . . . . . . . . . . . . . . 6 8. Application of the Interface Group to MPLS . . . . . . . . . . 8 8.1. Support of the MPLS Layer by ifTable . . . . . . . . . . 9 9. The Use of RowPointer. . . . . . . . . . . . . . . . . . . . . 10 10. MPLS Label Switching Router MIB Module Definitions . . . . . . 11 11. Security Considerations. . . . . . . . . . . . . . . . . . . . 55 12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 56 13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 56 13.1. IANA Considerations for MPLS-LSR-STD-MIB . . . . . . . . 56 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 14.1. Normative References . . . . . . . . . . . . . . . . . . 57 14.2. Informative References . . . . . . . . . . . . . . . . . 58 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 59 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 60 1. Introduction This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Multiprotocol Label Switching (MPLS) [RFC3031] Label Switching Router (LSR). Comments should be made directly to the MPLS mailing list at mpls@uu.net. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119, reference [RFC2119]. Srinivasan, et al. Standards Track [Page 2] RFC 3813 MPLS LSR MIB June 2004 2. Terminology This document uses terminology from the document describing the MPLS architecture [RFC3031]. A label switched path (LSP) is modeled as a connection consisting of one or more incoming segments (in-segments) and/or one or more outgoing segments (out-segments) at a LSR. The association or interconnection of the in-segments and out-segments is accomplished by using a cross-connect. We use the terminology "connection" and "LSP" interchangeably where the meaning is clear from the context. in-segment This is analogous to an MPLS label. out-segment This is analogous to an MPLS label. cross-connect This describes the conceptual connection between a set of in-segments and out-segments. Note that either set may be 0; that is, a cross-connect may connect only out-segments together with no in-segments in the case where an LSP is originating on an LSR. 3. The SNMP Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Outline Configuring LSPs through an LSR involves the following steps: - Enabling MPLS on MPLS capable interfaces. - Configuring in-segments and out-segments. - Setting up the cross-connect table to associate segments and/or to indicate connection origination and termination. - Optionally specifying label stack actions. Srinivasan, et al. Standards Track [Page 3] RFC 3813 MPLS LSR MIB June 2004 - Optionally specifying segment traffic parameters. 4.1. Summary of LSR MIB Module The MIB objects for performing these actions consist of the following tables: - The interface table (mplsInterfaceTable), which is used for revealing the MPLS protocol on MPLS-capable interfaces. - The in-segment (mplsInSegmentTable) and out-segment (mplsOutSegmentTable) tables, which are used for configuring LSP segments at an LSR. - The cross-connect table (mplsXCTable), which is used to associate in and out segments together, in order to form a cross-connect. - The label stack table (mplsLabelStackTable), which is used for specifying label stack operations. Further, the MPLS in-segment and out-segment performance tables, mplsInSegmentPerfTable and mplsOutSegmentPerfTable, contain the objects necessary to measure the performance of LSPs, and mplsInterfacePerfTable has objects to measure MPLS performance on a per-interface basis. These tables are described in the subsequent sections. 5. Brief Description of MIB Module Objects Sections 5.1-5.2 describe objects pertaining to MPLS-capable interfaces of an LSR. The objects described in Sections 5.3-5.8, were derived from the Incoming Label Map (ILM) and Next Hop Label Forwarding Entry (NHLFE) as specified in the MPLS architecture document [RFC3031]. It is appropriate to note that the in-segment, out-segment, and cross-connect tables were modeled after similar tables found in [RFC2515]. 5.1. mplsInterfaceTable This table represents the interfaces that are MPLS capable. An LSR creates an entry in this table for every MPLS capable interface on that LSR. 5.2. mplsInterfacePerfTable This table contains objects to measure the MPLS performance of MPLS capable interfaces and is an AUGMENT to mplsInterfaceTable. Srinivasan, et al. Standards Track [Page 4] RFC 3813 MPLS LSR MIB June 2004 5.3. mplsInSegmentTable This table contains a description of the incoming MPLS segments to an LSR and their associated parameters. This index for this table is mplsInSegmentIndex. The index structure of this table is specifically designed to handle many different MPLS implementations that manage their labels both in a distributed and centralized manner. The table is designed to handle existing MPLS labels as well as future label strategies that may require labels longer than the ones defined in RFC3031. In these cases, the object mplsInSegmentLabelPtr may be used indicate the first accessible object in a separate table that can be used to represent the label because it is too long to be represented in a single 32-bit value (mplsInSegmentLabel). 5.4. mplsInSegmentPerfTable The MPLS in-Segment Performance Table has objects to measure the performance of an incoming segment configured on an LSR. It is an AUGMENT to mplsInSegmentTable. High capacity counters are provided for objects that are likely to wrap around quickly on high-speed interfaces. 5.5. mplsOutSegmentTable The out-Segment Table contains a description of the outgoing MPLS segments at an LSR and their associated parameters. 5.6. mplsOutSegmentPerfTable The MPLS out-Segment Table contains objects to measure the performance of an outgoing segment configured on an LSR. It is an AUGMENT to mplsOutSegmentTable. High capacity counters are provided for objects that are likely to wrap around quickly on high-speed interfaces. 5.7. mplsXCTable The mplsXCTable specifies information for associating segments together in order to instruct the LSR to switch between the specified segments. It supports point-to-point, point-to-multipoint and multipoint-to-point connections. Srinivasan, et al. Standards Track [Page 5] RFC 3813 MPLS LSR MIB June 2004 The operational status object indicates the packet forwarding state of a cross-connect entry. For example, when the operational status objects is 'down' it indicates that the specified cross-connect entry will not forward packets. Likewise, when it is set to 'up' it indicates that packets will be forwarded. The administrative status object indicates the forwarding state desired by the operator. 5.8. mplsLabelStackTable The mplsLabelStackTable specifies the label stack to be pushed onto a packet, beneath the top label. Entries to this table are referred to from mplsXCTable. 5.9 mplsInSegmentMapTable The mplsInSegmentMapTable specifies the mapping from the mplsInSegmentIndex to the corresponding mplsInSegmentInterface and mplsInSegmentLabel objects. The purpose of this table is to provide the manager with an alternative means by which to locate in-segments. For instance, this table can be useful when tracing LSPs from LSR to LSR by first following the in-segment to out-segment, retrieving the outgoing label and out-going interface, and then proceeding to interrogate this table at the next-hop LSR to continue the trace. 6. Use of 32-bit and 64-bit Counters 64-bit counters are provided in this MIB module for high speed interfaces where the use of 32-bit counters might be impractical. The requirements on the use of 32-bit and 64-bit counters (copied verbatim from [RFC2863]) are as follows. For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported. 7. Example of LSP Setup In this section we provide a brief example of setting up an LSP using this MIB module's objects. While this example is not meant to illustrate every nuance of the MIB module, it is intended as an aid to understanding some of the key concepts. It is meant to be read after going through the MIB module itself. Srinivasan, et al. Standards Track [Page 6] RFC 3813 MPLS LSR MIB June 2004 Suppose that one would like to manually create a best-effort, unidirectional LSP. Assume that the LSP enters the LSR via MPLS interface A with ifIndex 12 and exits the LSR via MPLS interface B with ifIndex 13. Let us assume that we do not wish to impose any additional label stack beneath the top label on the outgoing labeled packets. The following example illustrates which rows and corresponding objects might be created to accomplish this. Those objects relevant to illustrating the relationships amongst different tables are shown here. Other objects may be needed before conceptual row activation can happen. The RowStatus values shown in this section are those to be used in the set request, typically createAndGo(4) which is used to create the conceptual row and have its status immediately set to active. Note that the proper use of createAndGo(4) requires that all columns that do not have a DEFVAL to be specified in order for the SET to succeed. In the example below we have not specify all such columns for the sake of keeping the example short. Please keep in mind that all such fields must be send during a real SET operation. A subsequent retrieval operation on the conceptual row will return a different value, such as active(1). Please see [RFC2579] for a detailed discussion on the use of RowStatus. We first create a cross-connect entry that associates the desired segments together. In mplsXCTable: { mplsXCIndex = 0x02, mplsXCInSegmentIndex = 0x00000015, mplsXCOutSegmentIndex = 0x01, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single -- outgoing label mplsXCRowStatus = createAndGo(4) } Next, we create the appropriate in-segment and out-segment entries based on the cross-connect. Note that some agents may wish to automatically create the in and out-segments based on the cross- connect creation. In mplsInSegmentTable: { mplsInSegmentIndex = 0x00000015 mplsInSegmentLabel = 21, -- incoming label Srinivasan, et al. Standards Track [Page 7] RFC 3813 MPLS LSR MIB June 2004 mplsInSegmentNPop = 1, mplsInSegmentInterface = 12, -- incoming interface -- RowPointer MUST point to the first accessible column. mplsInSegmentLabelPtr = 0.0, mplsInSegmentTrafficParamPtr = 0.0, mplsInSegmentRowStatus = createAndGo(4) } In mplsOutSegmentTable: { mplsOutSegmentIndex = 0x01, mplsOutSegmentInterface = 13, -- outgoing interface mplsOutSegmentPushTopLabel = true(1), mplsOutSegmentTopLabel = 22, -- outgoing label -- RowPointer MUST point to the first accessible column. mplsOutSegmentTrafficParamPtr = 0.0, mplsOutSegmentLabelPtr = 0.0, mplsOutSegmentRowStatus = createAndGo(4) } Note that the mplsInSegmentXCIndex and mplsOutSegmentXCIndex objects will automatically be populated with the string 0x02 when these segments are referred to from the corresponding cross-connect entry. 8. Application of the Interface Group to MPLS RFC2863 defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing MPLS interfaces. This memo assumes the interpretation of the Interfaces Group to be in accordance with [RFC2863] which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Thus, the MPLS interface is represented as an entry in the ifTable. The inter-relation of entries in the ifTable is defined by Interfaces Stack Group defined in [RFC2863]. Srinivasan, et al. Standards Track [Page 8] RFC 3813 MPLS LSR MIB June 2004 When using MPLS interfaces, the interface stack table might appear as follows: +----------------------------------------+ | MPLS interface; ifType = mpls(166) + +----------------------------------------+ | Underlying Layer + +----------------------------------------+ In the above diagram, "Underlying Layer" refers to the ifIndex of any interface type for which MPLS interworking has been defined. Examples include ATM, Frame Relay, Ethernet, etc. 8.1. Support of the MPLS Layer by ifTable Some specific interpretations of ifTable for the MPLS layer follow. Object Use for the MPLS layer ifIndex Each MPLS interface is represented by an ifEntry. ifDescr Description of the MPLS interface. ifType The value that is allocated for MPLS is 166. ifSpeed The total bandwidth in bits per second for use by the MPLS layer. ifPhysAddress Unused. ifAdminStatus This variable indicates the administrator's intent as to whether MPLS should be enabled, disabled, or running in some diagnostic testing mode on this interface. Also see [RFC2863]. ifOperStatus This value reflects the actual operational status of MPLS on this interface. ifLastChange See [RFC2863]. ifInOctets The number of received octets over the interface, i.e., the number of received, octets received as labeled packets. ifOutOctets The number of transmitted octets over the interface, i.e., the number of octets transmitted as labeled packets. Srinivasan, et al. Standards Track [Page 9] RFC 3813 MPLS LSR MIB June 2004 ifInErrors The number of labeled packets dropped due to uncorrectable errors. ifInUnknownProtos The number of received packets discarded during packet header validation, including packets with unrecognized label values. ifOutErrors See [RFC2863]. ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). ifConnectorPresent Set to false (2). ifHighSpeed See [RFC2863]. ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in [RFC2863]. ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in [RFC2863]. ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. ifCounterDiscontinuityTime See [RFC2863]. 9. The Use of RowPointer RowPointer is a textual convention used to identify a conceptual row in a MIB Table by pointing to the first accessible object in that row. In this MIB module, the trafficParamPtr object from either the mplsInSegmentTable or mplsOutSegmentTable SHOULD indicate the first accessible column in an entry in the MplsTunnelResourceEntry in the MPLS-TE-STD-MIB [RFC3812] to indicate the traffic parameter settings for this segment, if it represents an LSP used for a TE tunnel. The trafficParamPtr object may optionally point at an externally defined traffic parameter specification table. A value of zeroDotZero indicates best-effort treatment. By having the same value of this object, two or more segments can indicate resource sharing of such things as LSP queue space, etc. Srinivasan, et al. Standards Track [Page 10] RFC 3813 MPLS LSR MIB June 2004 10. MPLS Label Switching Router MIB Module Definitions MPLS-LSR-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Counter32, Unsigned32, Counter64, Gauge32, zeroDotZero FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TruthValue, RowStatus, StorageType, RowPointer, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero, ifGeneralInformationGroup, ifCounterDiscontinuityGroup FROM IF-MIB -- [RFC2863] mplsStdMIB, MplsLSPID, MplsLabel, MplsBitRate, MplsOwner FROM MPLS-TC-STD-MIB -- [RFC3811] AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB -- [IANAFamily] InetAddress, InetAddressType FROM INET-ADDRESS-MIB -- [RFC3291] ; mplsLsrStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Cheenu Srinivasan Bloomberg L.P. Email: cheenu@bloomberg.net Arun Viswanathan Force10 Networks, Inc. Email: arunv@force10networks.com Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Comments about this document should be emailed directly to the MPLS working group mailing list at mpls@uu.net." DESCRIPTION "This MIB module contains managed object definitions for the Multiprotocol Label Switching (MPLS) Router as Srinivasan, et al. Standards Track [Page 11] RFC 3813 MPLS LSR MIB June 2004 defined in: Rosen, E., Viswanathan, A., and R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, January 2001. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3812. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" -- Revision history. REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial revision, published as part of RFC 3813." ::= { mplsStdMIB 2 } -- TEXTUAL-CONVENTIONs MplsIndexType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is an octet string that can be used as a table index in cases where a large addressable space is required such as on an LSR where many applications may be provisioning labels. Note that the string containing the single octet with the value 0x00 is a reserved value used to represent special cases. When this TEXTUAL-CONVENTION is used as the SYNTAX of an object, the DESCRIPTION clause MUST specify if this special value is valid and if so what the special meaning is. In systems that provide write access to the MPLS-LSR-STD MIB, mplsIndexType SHOULD be used as a simple multi-digit integer encoded as an octet string. No further overloading of the meaning of an index SHOULD be made. In systems that do not offer write access to the MPLS-LSR-STD MIB, the mplsIndexType may contain implicit formatting that is specific to the implementation to convey additional information such as interface index, physical card or device, or application id. The interpretation of this additional formatting is implementation dependent and not covered in this document. Such formatting MUST Srinivasan, et al. Standards Track [Page 12] RFC 3813 MPLS LSR MIB June 2004 NOT impact the basic functionality of read-only access to the MPLS-LSR-STD MIB by management applications that are not aware of the formatting rules." SYNTAX OCTET STRING (SIZE(1..24)) MplsIndexNextType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "When a MIB module is used for configuration, an object with this SYNTAX always contains a legal value (a non-zero-length string) for an index that is not currently used in the relevant table. The Command Generator (Network Management Application) reads this variable and uses the (non-zero-length string) value read when creating a new row with an SNMP SET. When the SET is performed, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET succeeds and the Command Responder (agent) changes the value of this object, according to an implementation-specific algorithm. If the value is in use, however, the SET fails. The Network Management Application must then re-read this variable to obtain a new usable value. Note that the string containing the single octet with the value 0x00 is a reserved value used to represent the special case where no additional indexes can be provisioned, or in systems that do not offer write access, objects defined using this TEXTUAL-CONVENTION MUST return the string containing the single octet with the value 0x00." SYNTAX OCTET STRING (SIZE(1..24)) -- Top level components of this MIB module. -- Notifications mplsLsrNotifications OBJECT IDENTIFIER ::= { mplsLsrStdMIB 0 } -- Tables, Scalars mplsLsrObjects OBJECT IDENTIFIER ::= { mplsLsrStdMIB 1 } -- Conformance mplsLsrConformance OBJECT IDENTIFIER ::= { mplsLsrStdMIB 2 } -- MPLS Interface Table. mplsInterfaceTable OBJECT-TYPE Srinivasan, et al. Standards Track [Page 13] RFC 3813 MPLS LSR MIB June 2004 SYNTAX SEQUENCE OF MplsInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface MPLS capability and associated information." ::= { mplsLsrObjects 1 } mplsInterfaceEntry OBJECT-TYPE SYNTAX MplsInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in this table is created automatically by an LSR for every interface capable of supporting MPLS and which is configured to do so. A conceptual row in this table will exist if and only if a corresponding entry in ifTable exists with ifType = mpls(166). If this associated entry in ifTable is operationally disabled (thus removing MPLS capabilities on that interface), the corresponding entry in this table MUST be deleted shortly thereafter. An conceptual row with index 0 is created if the LSR supports per-platform labels. This conceptual row represents the per-platform label space and contains parameters that apply to all interfaces that participate in the per-platform label space. Other conceptual rows in this table represent MPLS interfaces that may participate in either the per-platform or per- interface label spaces, or both. Implementations that either only support per-platform labels, or have only them configured, may choose to return just the mplsInterfaceEntry of 0 and not return the other rows. This will greatly reduce the number of objects returned. Further information about label space participation of an interface is provided in the DESCRIPTION clause of mplsInterfaceLabelParticipationType." INDEX { mplsInterfaceIndex } ::= { mplsInterfaceTable 1 } MplsInterfaceEntry ::= SEQUENCE { mplsInterfaceIndex InterfaceIndexOrZero, mplsInterfaceLabelMinIn MplsLabel, mplsInterfaceLabelMaxIn MplsLabel, mplsInterfaceLabelMinOut MplsLabel, mplsInterfaceLabelMaxOut MplsLabel, mplsInterfaceTotalBandwidth MplsBitRate, Srinivasan, et al. Standards Track [Page 14] RFC 3813 MPLS LSR MIB June 2004 mplsInterfaceAvailableBandwidth MplsBitRate, mplsInterfaceLabelParticipationType BITS } mplsInterfaceIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a unique index for an entry in the MplsInterfaceTable. A non-zero index for an entry indicates the ifIndex for the corresponding interface entry of the MPLS-layer in the ifTable. The entry with index 0 represents the per-platform label space and contains parameters that apply to all interfaces that participate in the per-platform label space. Other entries defined in this table represent additional MPLS interfaces that may participate in either the per-platform or per-interface label spaces, or both." REFERENCE "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000" ::= { mplsInterfaceEntry 1 } mplsInterfaceLabelMinIn OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-only STATUS current DESCRIPTION "This is the minimum value of an MPLS label that this LSR is willing to receive on this interface." ::= { mplsInterfaceEntry 2 } mplsInterfaceLabelMaxIn OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-only STATUS current DESCRIPTION "This is the maximum value of an MPLS label that this LSR is willing to receive on this interface." ::= { mplsInterfaceEntry 3 } mplsInterfaceLabelMinOut OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-only STATUS current DESCRIPTION "This is the minimum value of an MPLS label that this Srinivasan, et al. Standards Track [Page 15] RFC 3813 MPLS LSR MIB June 2004 LSR is willing to send on this interface." ::= { mplsInterfaceEntry 4 } mplsInterfaceLabelMaxOut OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-only STATUS current DESCRIPTION "This is the maximum value of an MPLS label that this LSR is willing to send on this interface." ::= { mplsInterfaceEntry 5 } mplsInterfaceTotalBandwidth OBJECT-TYPE SYNTAX MplsBitRate UNITS "kilobits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the total amount of usable bandwidth on this interface and is specified in kilobits per second (Kbps). This variable is not applicable when applied to the interface with index 0. When this value cannot be measured, this value should contain the nominal bandwidth." ::= { mplsInterfaceEntry 6 } mplsInterfaceAvailableBandwidth OBJECT-TYPE SYNTAX MplsBitRate MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the total amount of available bandwidth available on this interface and is specified in kilobits per second (Kbps). This value is calculated as the difference between the amount of bandwidth currently in use and that specified in mplsInterfaceTotalBandwidth. This variable is not applicable when applied to the interface with index 0. When this value cannot be measured, this value should contain the nominal bandwidth." ::= { mplsInterfaceEntry 7 } mplsInterfaceLabelParticipationType OBJECT-TYPE SYNTAX BITS { perPlatform (0), perInterface (1) } MAX-ACCESS read-only Srinivasan, et al. Standards Track [Page 16] RFC 3813 MPLS LSR MIB June 2004 STATUS current DESCRIPTION "If the value of the mplsInterfaceIndex for this entry is zero, then this entry corresponds to the per-platform label space for all interfaces configured to use that label space. In this case the perPlatform(0) bit MUST be set; the perInterface(1) bit is meaningless and MUST be ignored. The remainder of this description applies to entries with a non-zero value of mplsInterfaceIndex. If the perInterface(1) bit is set then the value of mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for this entry reflect the label ranges for this interface. If only the perPlatform(0) bit is set, then the value of mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, and mplsInterfaceLabelMaxOut for this entry MUST be identical to the instance of these objects with index 0. These objects may only vary from the entry with index 0 if both the perPlatform(0) and perInterface(1) bits are set. In all cases, at a minimum one of the perPlatform(0) or perInterface(1) bits MUST be set to indicate that at least one label space is in use by this interface. In all cases, agents MUST ensure that label ranges are specified consistently and MUST return an inconsistentValue error when they do not." REFERENCE "Rosen, E., Viswanathan, A., and R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, January 2001." ::= { mplsInterfaceEntry 8 } -- End of mplsInterfaceTable -- MPLS Interface Performance Table. mplsInterfacePerfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsInterfacePerfEntry MAX-ACCESS not-accessible STATUS current Srinivasan, et al. Standards Track [Page 17] RFC 3813 MPLS LSR MIB June 2004 DESCRIPTION "This table provides MPLS performance information on a per-interface basis." ::= { mplsLsrObjects 2 } mplsInterfacePerfEntry OBJECT-TYPE SYNTAX MplsInterfacePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the LSR for every interface capable of supporting MPLS. Its is an extension to the mplsInterfaceEntry table. Note that the discontinuity behavior of entries in this table MUST be based on the corresponding ifEntry's ifDiscontinuityTime." AUGMENTS { mplsInterfaceEntry } ::= { mplsInterfacePerfTable 1 } MplsInterfacePerfEntry ::= SEQUENCE { -- incoming direction mplsInterfacePerfInLabelsInUse Gauge32, mplsInterfacePerfInLabelLookupFailures Counter32, -- outgoing direction mplsInterfacePerfOutLabelsInUse Gauge32, mplsInterfacePerfOutFragmentedPkts Counter32 } mplsInterfacePerfInLabelsInUse OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of labels that are in use at this point in time on this interface in the incoming direction. If the interface participates in only the per-platform label space, then the value of the instance of this object MUST be identical to the value of the instance with index 0. If the interface participates in the per-interface label space, then the instance of this object MUST represent the number of per-interface labels that are in use on this interface." ::= { mplsInterfacePerfEntry 1 } mplsInterfacePerfInLabelLookupFailures OBJECT-TYPE SYNTAX Counter32 Srinivasan, et al. Standards Track [Page 18] RFC 3813 MPLS LSR MIB June 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of labeled packets that have been received on this interface and which were discarded because there was no matching cross- connect entry. This object MUST count on a per- interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 2 } mplsInterfacePerfOutLabelsInUse OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of top-most labels in the outgoing label stacks that are in use at this point in time on this interface. This object MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 3 } mplsInterfacePerfOutFragmentedPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of outgoing MPLS packets that required fragmentation before transmission on this interface. This object MUST count on a per-interface basis regardless of which label space the interface participates in." ::= { mplsInterfacePerfEntry 4 } -- mplsInterfacePerf Table end. mplsInSegmentIndexNext OBJECT-TYPE SYNTAX MplsIndexNextType MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next available value to be used for mplsInSegmentIndex when creating entries in the mplsInSegmentTable. The special value of a string containing the single octet 0x00 indicates that no new entries can be created in this table. Agents not allowing managers to create entries Srinivasan, et al. Standards Track [Page 19] RFC 3813 MPLS LSR MIB June 2004 in this table MUST set this object to this special value." ::= { mplsLsrObjects 3 } -- in-segment table. mplsInSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsInSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a description of the incoming MPLS segments (labels) to an LSR and their associated parameters. The index for this table is mplsInSegmentIndex. The index structure of this table is specifically designed to handle many different MPLS implementations that manage their labels both in a distributed and centralized manner. The table is also designed to handle existing MPLS labels as defined in RFC3031 as well as longer ones that may be necessary in the future. In cases where the label cannot fit into the mplsInSegmentLabel object, the mplsInSegmentLabelPtr will indicate this by being set to the first accessible column in the appropriate extension table's row. In this case an additional table MUST be provided and MUST be indexed by at least the indexes used by this table. In all other cases when the label is represented within the mplsInSegmentLabel object, the mplsInSegmentLabelPtr MUST be set to 0.0. Due to the fact that MPLS labels may not exceed 24 bits, the mplsInSegmentLabelPtr object is only a provision for future-proofing the MIB module. Thus, the definition of any extension tables is beyond the scope of this MIB module." ::= { mplsLsrObjects 4 } mplsInSegmentEntry OBJECT-TYPE SYNTAX MplsInSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents one incoming segment as is represented in an LSR's LFIB. An entry can be created by a network administrator or an SNMP agent, or an MPLS signaling protocol. The creator of the entry is denoted by mplsInSegmentOwner. Srinivasan, et al. Standards Track [Page 20] RFC 3813 MPLS LSR MIB June 2004 The value of mplsInSegmentRowStatus cannot be active(1) unless the ifTable entry corresponding to mplsInSegmentInterface exists. An entry in this table must match any incoming packets, and indicates an instance of mplsXCEntry based on which forwarding and/or switching actions are taken." INDEX { mplsInSegmentIndex } ::= { mplsInSegmentTable 1 } MplsInSegmentEntry ::= SEQUENCE { mplsInSegmentIndex MplsIndexType, mplsInSegmentInterface InterfaceIndexOrZero, mplsInSegmentLabel MplsLabel, mplsInSegmentLabelPtr RowPointer, mplsInSegmentNPop Integer32, mplsInSegmentAddrFamily AddressFamilyNumbers, mplsInSegmentXCIndex MplsIndexType, mplsInSegmentOwner MplsOwner , mplsInSegmentTrafficParamPtr RowPointer, mplsInSegmentRowStatus RowStatus, mplsInSegmentStorageType StorageType } mplsInSegmentIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this in-segment. The string containing the single octet 0x00 MUST not be used as an index." ::= { mplsInSegmentEntry 1 } mplsInSegmentInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the interface index for the incoming MPLS interface. A value of zero represents all interfaces participating in the per-platform label space. This may only be used in cases where the incoming interface and label are associated with the same mplsXCEntry. Specifically, given a label and any incoming interface pair from the per-platform label space, the outgoing label/interface mapping remains the same. If this is not the case, then individual entries MUST exist that Srinivasan, et al. Standards Track [Page 21] RFC 3813 MPLS LSR MIB June 2004 can then be mapped to unique mplsXCEntries." ::= { mplsInSegmentEntry 2 } mplsInSegmentLabel OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-create STATUS current DESCRIPTION "If the corresponding instance of mplsInSegmentLabelPtr is zeroDotZero then this object MUST contain the incoming label associated with this in-segment. If not this object SHOULD be zero and MUST be ignored." ::= { mplsInSegmentEntry 3 } mplsInSegmentLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the label for this segment cannot be represented fully within the mplsInSegmentLabel object, this object MUST point to the first accessible column of a conceptual row in an external table containing the label. In this case, the mplsInSegmentTopLabel object SHOULD be set to 0 and ignored. This object MUST be set to zeroDotZero otherwise." DEFVAL { zeroDotZero } ::= { mplsInSegmentEntry 4 } mplsInSegmentNPop OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of labels to pop from the incoming packet. Normally only the top label is popped from the packet and used for all switching decisions for that packet. This is indicated by setting this object to the default value of 1. If an LSR supports popping of more than one label, this object MUST be set to that number. This object cannot be modified if mplsInSegmentRowStatus is active(1)." DEFVAL { 1 } ::= { mplsInSegmentEntry 5 } mplsInSegmentAddrFamily OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create Srinivasan, et al. Standards Track [Page 22] RFC 3813 MPLS LSR MIB June 2004 STATUS current DESCRIPTION "The IANA address family [IANAFamily] of packets received on this segment, which is used at an egress LSR to deliver them to the appropriate layer 3 entity. A value of other(0) indicates that the family type is either unknown or undefined; this SHOULD NOT be used at an egress LSR. This object cannot be modified if mplsInSegmentRowStatus is active(1)." REFERENCE "Internet Assigned Numbers Authority (IANA), ADDRESS FAMILY NUMBERS, (http://www.iana.org/assignments/ address-family-numbers), for MIB see: http://www.iana.org/assignments/ ianaaddressfamilynumbers-mib " DEFVAL { other } ::= { mplsInSegmentEntry 6 } mplsInSegmentXCIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "Index into mplsXCTable which identifies which cross- connect entry this segment is part of. The string containing the single octet 0x00 indicates that this entry is not referred to by any cross-connect entry. When a cross-connect entry is created which this in-segment is a part of, this object is automatically updated to reflect the value of mplsXCIndex of that cross-connect entry." ::= { mplsInSegmentEntry 7 } mplsInSegmentOwner OBJECT-TYPE SYNTAX MplsOwner MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes the entity that created and is responsible for managing this segment." ::= { mplsInSegmentEntry 8 } mplsInSegmentTrafficParamPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION Srinivasan, et al. Standards Track [Page 23] RFC 3813 MPLS LSR MIB June 2004 "This variable represents a pointer to the traffic parameter specification for this in-segment. This value may point at an entry in the mplsTunnelResourceTable in the MPLS-TE-STD-MIB (RFC3812) to indicate which traffic parameter settings for this segment if it represents an LSP used for a TE tunnel. This value may optionally point at an externally defined traffic parameter specification table. A value of zeroDotZero indicates best-effort treatment. By having the same value of this object, two or more segments can indicate resource sharing of such things as LSP queue space, etc. This object cannot be modified if mplsInSegmentRowStatus is active(1). For entries in this table that are preserved after a re-boot, the agent MUST ensure that their integrity be preserved, or this object should be set to 0.0 if it cannot." DEFVAL { zeroDotZero } ::= { mplsInSegmentEntry 9 } mplsInSegmentRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. When a row in this table has a row in the active(1) state, no objects in this row can be modified except the mplsInSegmentRowStatus and mplsInSegmentStorageType." ::= { mplsInSegmentEntry 10 } mplsInSegmentStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this object. The agent MUST ensure that this object's value remains consistent with the associated mplsXCEntry. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." REFERENCE "See RFC2579." DEFVAL { volatile } Srinivasan, et al. Standards Track [Page 24] RFC 3813 MPLS LSR MIB June 2004 ::= { mplsInSegmentEntry 11 } -- End of mplsInSegmentTable -- in-segment performance table. mplsInSegmentPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsInSegmentPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistical information for incoming MPLS segments to an LSR." ::= { mplsLsrObjects 5 } mplsInSegmentPerfEntry OBJECT-TYPE SYNTAX MplsInSegmentPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table contains statistical information about one incoming segment which is configured in the mplsInSegmentTable. The counters in this entry should behave in a manner similar to that of the interface. mplsInSegmentPerfDiscontinuityTime indicates the time of the last discontinuity in all of these objects." AUGMENTS { mplsInSegmentEntry } ::= { mplsInSegmentPerfTable 1 } MplsInSegmentPerfEntry ::= SEQUENCE { mplsInSegmentPerfOctets Counter32, mplsInSegmentPerfPackets Counter32, mplsInSegmentPerfErrors Counter32, mplsInSegmentPerfDiscards Counter32, -- high capacity counter mplsInSegmentPerfHCOctets Counter64, mplsInSegmentPerfDiscontinuityTime TimeStamp } mplsInSegmentPerfOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Srinivasan, et al. Standards Track [Page 25] RFC 3813 MPLS LSR MIB June 2004 "This value represents the total number of octets received by this segment. It MUST be equal to the least significant 32 bits of mplsInSegmentPerfHCOctets if mplsInSegmentPerfHCOctets is supported according to the rules spelled out in RFC2863." ::= { mplsInSegmentPerfEntry 1 } mplsInSegmentPerfPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of packets received by this segment." ::= { mplsInSegmentPerfEntry 2 } mplsInSegmentPerfErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of errored packets received on this segment." ::= { mplsInSegmentPerfEntry 3 } mplsInSegmentPerfDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of labeled packets received on this in- segment, which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a labeled packet could be to free up buffer space." ::= { mplsInSegmentPerfEntry 4 } mplsInSegmentPerfHCOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received. This is the 64 bit version of mplsInSegmentPerfOctets, if mplsInSegmentPerfHCOctets is supported according to the rules spelled out in RFC2863." ::= { mplsInSegmentPerfEntry 5 } Srinivasan, et al. Standards Track [Page 26] RFC 3813 MPLS LSR MIB June 2004 mplsInSegmentPerfDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this segment's Counter32 or Counter64 suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { mplsInSegmentPerfEntry 6 } -- End of mplsInSegmentPerfTable. -- out-segment table. mplsOutSegmentIndexNext OBJECT-TYPE SYNTAX MplsIndexNextType MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next available value to be used for mplsOutSegmentIndex when creating entries in the mplsOutSegmentTable. The special value of a string containing the single octet 0x00 indicates that no new entries can be created in this table. Agents not allowing managers to create entries in this table MUST set this object to this special value." ::= { mplsLsrObjects 6 } mplsOutSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsOutSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a representation of the outgoing segments from an LSR." ::= { mplsLsrObjects 7 } mplsOutSegmentEntry OBJECT-TYPE SYNTAX MplsOutSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents one outgoing Srinivasan, et al. Standards Track [Page 27] RFC 3813 MPLS LSR MIB June 2004 segment. An entry can be created by a network administrator, an SNMP agent, or an MPLS signaling protocol. The object mplsOutSegmentOwner indicates the creator of this entry. The value of mplsOutSegmentRowStatus cannot be active(1) unless the ifTable entry corresponding to mplsOutSegmentInterface exists. Note that the indexing of this table uses a single, arbitrary index (mplsOutSegmentIndex) to indicate which out-segment (i.e.: label) is being switched to from which in-segment (i.e: label) or in-segments. This is necessary because it is possible to have an equal-cost multi-path situation where two identical out-going labels are assigned to the same cross-connect (i.e.: they go to two different neighboring LSRs); thus, requiring two out-segments. In order to preserve the uniqueness of the references by the mplsXCEntry, an arbitrary integer must be used as the index for this table." INDEX { mplsOutSegmentIndex } ::= { mplsOutSegmentTable 1 } MplsOutSegmentEntry ::= SEQUENCE { mplsOutSegmentIndex MplsIndexType, mplsOutSegmentInterface InterfaceIndexOrZero, mplsOutSegmentPushTopLabel TruthValue, mplsOutSegmentTopLabel MplsLabel, mplsOutSegmentTopLabelPtr RowPointer, mplsOutSegmentNextHopAddrType InetAddressType, mplsOutSegmentNextHopAddr InetAddress, mplsOutSegmentXCIndex MplsIndexType, mplsOutSegmentOwner MplsOwner, mplsOutSegmentTrafficParamPtr RowPointer, mplsOutSegmentRowStatus RowStatus, mplsOutSegmentStorageType StorageType } mplsOutSegmentIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value contains a unique index for this row. While a value of a string containing the single octet 0x00 is not valid as an index for entries in this table, it can be supplied as a valid value to index the mplsXCTable to represent entries for Srinivasan, et al. Standards Track [Page 28] RFC 3813 MPLS LSR MIB June 2004 which no out-segment has been configured or exists." ::= { mplsOutSegmentEntry 1 } mplsOutSegmentInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This value must contain the interface index of the outgoing interface. This object cannot be modified if mplsOutSegmentRowStatus is active(1). The mplsOutSegmentRowStatus cannot be set to active(1) until this object is set to a value corresponding to a valid ifEntry." ::= { mplsOutSegmentEntry 2 } mplsOutSegmentPushTopLabel OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This value indicates whether or not a top label should be pushed onto the outgoing packet's label stack. The value of this variable MUST be set to true(1) if the outgoing interface does not support pop-and-go (and no label stack remains). For example, on ATM interface, or if the segment represents a tunnel origination. Note that it is considered an error in the case that mplsOutSegmentPushTopLabel is set to false, but the cross-connect entry which refers to this out-segment has a non-zero mplsLabelStackIndex. The LSR MUST ensure that this situation does not happen. This object cannot be modified if mplsOutSegmentRowStatus is active(1)." DEFVAL { true } ::= { mplsOutSegmentEntry 3 } mplsOutSegmentTopLabel OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsOutSegmentPushTopLabel is true then this represents the label that should be pushed onto the top of the outgoing packet's label stack. Otherwise this value SHOULD be set to 0 by the management station and MUST be ignored by the agent. This Srinivasan, et al. Standards Track [Page 29] RFC 3813 MPLS LSR MIB June 2004 object cannot be modified if mplsOutSegmentRowStatus is active(1)." DEFVAL { 0 } ::= { mplsOutSegmentEntry 4 } mplsOutSegmentTopLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the label for this segment cannot be represented fully within the mplsOutSegmentLabel object, this object MUST point to the first accessible column of a conceptual row in an external table containing the label. In this case, the mplsOutSegmentTopLabel object SHOULD be set to 0 and ignored. This object MUST be set to zeroDotZero otherwise." DEFVAL { zeroDotZero } ::= { mplsOutSegmentEntry 5 } mplsOutSegmentNextHopAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the next hop Internet address type. Only values unknown(0), ipv4(1) or ipv6(2) have to be supported. A value of unknown(0) is allowed only when the outgoing interface is of type point-to-point. If any other unsupported values are attempted in a set operation, the agent MUST return an inconsistentValue error." REFERENCE "See RFC3291." ::= { mplsOutSegmentEntry 6 } mplsOutSegmentNextHopAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The internet address of the next hop. The type of this address is determined by the value of the mplslOutSegmentNextHopAddrType object. This object cannot be modified if Srinivasan, et al. Standards Track [Page 30] RFC 3813 MPLS LSR MIB June 2004 mplsOutSegmentRowStatus is active(1)." ::= { mplsOutSegmentEntry 7 } mplsOutSegmentXCIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "Index into mplsXCTable which identifies which cross- connect entry this segment is part of. A value of the string containing the single octet 0x00 indicates that this entry is not referred to by any cross-connect entry. When a cross-connect entry is created which this out-segment is a part of, this object MUST be updated by the agent to reflect the value of mplsXCIndex of that cross-connect entry." ::= { mplsOutSegmentEntry 8 } mplsOutSegmentOwner OBJECT-TYPE SYNTAX MplsOwner MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes the entity which created and is responsible for managing this segment." ::= { mplsOutSegmentEntry 9 } mplsOutSegmentTrafficParamPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This variable represents a pointer to the traffic parameter specification for this out-segment. This value may point at an entry in the MplsTunnelResourceEntry in the MPLS-TE-STD-MIB (RFC3812) RFC Editor: Please fill in RFC number. to indicate which traffic parameter settings for this segment if it represents an LSP used for a TE tunnel. This value may optionally point at an externally defined traffic parameter specification table. A value of zeroDotZero indicates best-effort treatment. By having the same value of this object, two or more segments can indicate resource sharing Srinivasan, et al. Standards Track [Page 31] RFC 3813 MPLS LSR MIB June 2004 of such things as LSP queue space, etc. This object cannot be modified if mplsOutSegmentRowStatus is active(1). For entries in this table that are preserved after a re-boot, the agent MUST ensure that their integrity be preserved, or this object should be set to 0.0 if it cannot." DEFVAL { zeroDotZero } ::= { mplsOutSegmentEntry 10 } mplsOutSegmentRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "For creating, modifying, and deleting this row. When a row in this table has a row in the active(1) state, no objects in this row can be modified except the mplsOutSegmentRowStatus or mplsOutSegmentStorageType." ::= { mplsOutSegmentEntry 11 } mplsOutSegmentStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this object. The agent MUST ensure that this object's value remains consistent with the associated mplsXCEntry. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { volatile } ::= { mplsOutSegmentEntry 12 } -- End of mplsOutSegmentTable -- out-segment performance table. mplsOutSegmentPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsOutSegmentPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistical information about Srinivasan, et al. Standards Track [Page 32] RFC 3813 MPLS LSR MIB June 2004 outgoing segments from an LSR. The counters in this entry should behave in a manner similar to that of the interface." ::= { mplsLsrObjects 8 } mplsOutSegmentPerfEntry OBJECT-TYPE SYNTAX MplsOutSegmentPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table contains statistical information about one outgoing segment configured in mplsOutSegmentTable. The object mplsOutSegmentPerfDiscontinuityTime indicates the time of the last discontinuity in these objects. " AUGMENTS { mplsOutSegmentEntry } ::= { mplsOutSegmentPerfTable 1 } MplsOutSegmentPerfEntry ::= SEQUENCE { mplsOutSegmentPerfOctets Counter32, mplsOutSegmentPerfPackets Counter32, mplsOutSegmentPerfErrors Counter32, mplsOutSegmentPerfDiscards Counter32, -- HC counter mplsOutSegmentPerfHCOctets Counter64, mplsOutSegmentPerfDiscontinuityTime TimeStamp } mplsOutSegmentPerfOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value contains the total number of octets sent on this segment. It MUST be equal to the least significant 32 bits of mplsOutSegmentPerfHCOctets if mplsOutSegmentPerfHCOctets is supported according to the rules spelled out in RFC2863." ::= { mplsOutSegmentPerfEntry 1 } mplsOutSegmentPerfPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value contains the total number of packets sent Srinivasan, et al. Standards Track [Page 33] RFC 3813 MPLS LSR MIB June 2004 on this segment." ::= { mplsOutSegmentPerfEntry 2 } mplsOutSegmentPerfErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets that could not be sent due to errors on this segment." ::= { mplsOutSegmentPerfEntry 3 } mplsOutSegmentPerfDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of labeled packets attempted to be transmitted on this out-segment, which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a labeled packet could be to free up buffer space." ::= { mplsOutSegmentPerfEntry 4 } mplsOutSegmentPerfHCOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of octets sent. This is the 64 bit version of mplsOutSegmentPerfOctets, if mplsOutSegmentPerfHCOctets is supported according to the rules spelled out in RFC2863." ::= { mplsOutSegmentPerfEntry 5 } mplsOutSegmentPerfDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this segment's Counter32 or Counter64 suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { mplsOutSegmentPerfEntry 6 } Srinivasan, et al. Standards Track [Page 34] RFC 3813 MPLS LSR MIB June 2004 -- End of mplsOutSegmentPerfTable. -- Cross-connect table. mplsXCIndexNext OBJECT-TYPE SYNTAX MplsIndexNextType MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next available value to be used for mplsXCIndex when creating entries in the mplsXCTable. A special value of the zero length string indicates that no more new entries can be created in the relevant table. Agents not allowing managers to create entries in this table MUST set this value to the zero length string." ::= { mplsLsrObjects 9 } mplsXCTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsXCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies information for switching between LSP segments. It supports point-to-point, point-to-multipoint and multipoint-to-point connections. mplsLabelStackTable specifies the label stack information for a cross-connect LSR and is referred to from mplsXCTable." ::= { mplsLsrObjects 10 } mplsXCEntry OBJECT-TYPE SYNTAX MplsXCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table represents one cross-connect entry. It is indexed by the following objects: - cross-connect index mplsXCIndex that uniquely identifies a group of cross-connect entries - in-segment index, mplsXCInSegmentIndex - out-segment index, mplsXCOutSegmentIndex Srinivasan, et al. Standards Track [Page 35] RFC 3813 MPLS LSR MIB June 2004 LSPs originating at this LSR: These are represented by using the special of value of mplsXCInSegmentIndex set to the string containing a single octet 0x00. In this case the mplsXCOutSegmentIndex MUST not be the string containing a single octet 0x00. LSPs terminating at this LSR: These are represented by using the special value mplsXCOutSegmentIndex set to the string containing a single octet 0x00. Special labels: Entries indexed by the strings containing the reserved MPLS label values as a single octet 0x00 through 0x0f (inclusive) imply LSPs terminating at this LSR. Note that situations where LSPs are terminated with incoming label equal to the string containing a single octet 0x00 can be distinguished from LSPs originating at this LSR because the mplsXCOutSegmentIndex equals the string containing the single octet 0x00. An entry can be created by a network administrator or by an SNMP agent as instructed by an MPLS signaling protocol." INDEX { mplsXCIndex, mplsXCInSegmentIndex, mplsXCOutSegmentIndex } ::= { mplsXCTable 1 } MplsXCEntry ::= SEQUENCE { mplsXCIndex MplsIndexType, mplsXCInSegmentIndex MplsIndexType, mplsXCOutSegmentIndex MplsIndexType, mplsXCLspId MplsLSPID, mplsXCLabelStackIndex MplsIndexType, mplsXCOwner MplsOwner , mplsXCRowStatus RowStatus, mplsXCStorageType StorageType, mplsXCAdminStatus INTEGER, mplsXCOperStatus INTEGER } mplsXCIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current Srinivasan, et al. Standards Track [Page 36] RFC 3813 MPLS LSR MIB June 2004 DESCRIPTION "Primary index for the conceptual row identifying a group of cross-connect segments. The string containing a single octet 0x00 is an invalid index." ::= { mplsXCEntry 1 } mplsXCInSegmentIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Incoming label index. If this object is set to the string containing a single octet 0x00, this indicates a special case outlined in the table's description above. In this case no corresponding mplsInSegmentEntry shall exist." ::= { mplsXCEntry 2 } mplsXCOutSegmentIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of out-segment for LSPs not terminating on this LSR if not set to the string containing the single octet 0x00. If the segment identified by this entry is terminating, then this object MUST be set to the string containing a single octet 0x00 to indicate that no corresponding mplsOutSegmentEntry shall exist." ::= { mplsXCEntry 3 } mplsXCLspId OBJECT-TYPE SYNTAX MplsLSPID MAX-ACCESS read-create STATUS current DESCRIPTION "This value identifies the label switched path that this cross-connect entry belongs to. This object cannot be modified if mplsXCRowStatus is active(1) except for this object." ::= { mplsXCEntry 4 } mplsXCLabelStackIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS read-create STATUS current Srinivasan, et al. Standards Track [Page 37] RFC 3813 MPLS LSR MIB June 2004 DESCRIPTION "Primary index into mplsLabelStackTable identifying a stack of labels to be pushed beneath the top label. Note that the top label identified by the out- segment ensures that all the components of a multipoint-to-point connection have the same outgoing label. A value of the string containing the single octet 0x00 indicates that no labels are to be stacked beneath the top label. This object cannot be modified if mplsXCRowStatus is active(1)." ::= { mplsXCEntry 5 } mplsXCOwner OBJECT-TYPE SYNTAX MplsOwner MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes the entity that created and is responsible for managing this cross-connect." ::= { mplsXCEntry 6 } mplsXCRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "For creating, modifying, and deleting this row. When a row in this table has a row in the active(1) state, no objects in this row except this object and the mplsXCStorageType can be modified. " ::= { mplsXCEntry 7 } mplsXCStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this object. The agent MUST ensure that the associated in and out segments also have the same StorageType value and are restored consistently upon system restart. This value SHOULD be set to permanent(4) if created as a result of a static LSP configuration. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." Srinivasan, et al. Standards Track [Page 38] RFC 3813 MPLS LSR MIB June 2004 DEFVAL { volatile } ::= { mplsXCEntry 8 } mplsXCAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of this segment." DEFVAL { up } ::= { mplsXCEntry 9 } mplsXCOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3), -- in some test mode unknown(4), -- status cannot be determined -- for some reason. dormant(5), notPresent(6), -- some component is missing lowerLayerDown(7) -- down due to the state of -- lower layer interfaces } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of this cross- connect." ::= { mplsXCEntry 10 } -- End of mplsXCTable -- Label stack table. mplsMaxLabelStackDepth OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum stack depth supported by this LSR." ::= { mplsLsrObjects 11 } Srinivasan, et al. Standards Track [Page 39] RFC 3813 MPLS LSR MIB June 2004 mplsLabelStackIndexNext OBJECT-TYPE SYNTAX MplsIndexNextType MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next available value to be used for mplsLabelStackIndex when creating entries in the mplsLabelStackTable. The special string containing the single octet 0x00 indicates that no more new entries can be created in the relevant table. Agents not allowing managers to create entries in this table MUST set this value to the string containing the single octet 0x00." ::= { mplsLsrObjects 12 } mplsLabelStackTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLabelStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the label stack to be pushed onto a packet, beneath the top label. Entries into this table are referred to from mplsXCTable." ::= { mplsLsrObjects 13 } mplsLabelStackEntry OBJECT-TYPE SYNTAX MplsLabelStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents one label which is to be pushed onto an outgoing packet, beneath the top label. An entry can be created by a network administrator or by an SNMP agent as instructed by an MPLS signaling protocol." INDEX { mplsLabelStackIndex, mplsLabelStackLabelIndex } ::= { mplsLabelStackTable 1 } MplsLabelStackEntry ::= SEQUENCE { mplsLabelStackIndex MplsIndexType, mplsLabelStackLabelIndex Unsigned32, mplsLabelStackLabel MplsLabel, mplsLabelStackLabelPtr RowPointer, mplsLabelStackRowStatus RowStatus, mplsLabelStackStorageType StorageType } mplsLabelStackIndex OBJECT-TYPE Srinivasan, et al. Standards Track [Page 40] RFC 3813 MPLS LSR MIB June 2004 SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Primary index for this row identifying a stack of labels to be pushed on an outgoing packet, beneath the top label. An index containing the string with a single octet 0x00 MUST not be used." ::= { mplsLabelStackEntry 1 } mplsLabelStackLabelIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Secondary index for this row identifying one label of the stack. Note that an entry with a smaller mplsLabelStackLabelIndex would refer to a label higher up the label stack and would be popped at a downstream LSR before a label represented by a higher mplsLabelStackLabelIndex at a downstream LSR." ::= { mplsLabelStackEntry 2 } mplsLabelStackLabel OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-create STATUS current DESCRIPTION "The label to pushed." ::= { mplsLabelStackEntry 3 } mplsLabelStackLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the label for this segment cannot be represented fully within the mplsLabelStackLabel object, this object MUST point to the first accessible column of a conceptual row in an external table containing the label. In this case, the mplsLabelStackLabel object SHOULD be set to 0 and ignored. This object MUST be set to zeroDotZero otherwise." DEFVAL { zeroDotZero } ::= { mplsLabelStackEntry 4 } mplsLabelStackRowStatus OBJECT-TYPE Srinivasan, et al. Standards Track [Page 41] RFC 3813 MPLS LSR MIB June 2004 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "For creating, modifying, and deleting this row. When a row in this table has a row in the active(1) state, no objects in this row except this object and the mplsLabelStackStorageType can be modified." ::= { mplsLabelStackEntry 5 } mplsLabelStackStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this object. This object cannot be modified if mplsLabelStackRowStatus is active(1). No objects are required to be writable for rows in this table with this object set to permanent(4). The agent MUST ensure that all related entries in this table retain the same value for this object. Agents MUST ensure that the storage type for all entries related to a particular mplsXCEntry retain the same value for this object as the mplsXCEntry's StorageType." DEFVAL { volatile } ::= { mplsLabelStackEntry 6 } -- End of mplsLabelStackTable -- Begin mplsInSegmentMapTable mplsInSegmentMapTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsInSegmentMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the mapping from the mplsInSegmentIndex to the corresponding mplsInSegmentInterface and mplsInSegmentLabel objects. The purpose of this table is to provide the manager with an alternative means by which to locate in-segments." ::= { mplsLsrObjects 14 } Srinivasan, et al. Standards Track [Page 42] RFC 3813 MPLS LSR MIB June 2004 mplsInSegmentMapEntry OBJECT-TYPE SYNTAX MplsInSegmentMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents one interface and incoming label pair. In cases where the label cannot fit into the mplsInSegmentLabel object, the mplsInSegmentLabelPtr will indicate this by being set to the first accessible column in the appropriate extension table's row, and the mplsInSegmentLabel SHOULD be set to 0. In all other cases when the label is represented within the mplsInSegmentLabel object, the mplsInSegmentLabelPtr MUST be 0.0. Implementors need to be aware that if the value of the mplsInSegmentMapLabelPtrIndex (an OID) has more that 111 sub-identifiers, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { mplsInSegmentMapInterface, mplsInSegmentMapLabel, mplsInSegmentMapLabelPtrIndex } ::= { mplsInSegmentMapTable 1 } MplsInSegmentMapEntry ::= SEQUENCE { mplsInSegmentMapInterface InterfaceIndexOrZero, mplsInSegmentMapLabel MplsLabel, mplsInSegmentMapLabelPtrIndex RowPointer, mplsInSegmentMapIndex MplsIndexType } mplsInSegmentMapInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index contains the same value as the mplsInSegmentIndex in the mplsInSegmentTable." ::= { mplsInSegmentMapEntry 1 } mplsInSegmentMapLabel OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS not-accessible STATUS current Srinivasan, et al. Standards Track [Page 43] RFC 3813 MPLS LSR MIB June 2004 DESCRIPTION "This index contains the same value as the mplsInSegmentLabel in the mplsInSegmentTable." ::= { mplsInSegmentMapEntry 2 } mplsInSegmentMapLabelPtrIndex OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index contains the same value as the mplsInSegmentLabelPtr. If the label for the InSegment cannot be represented fully within the mplsInSegmentLabel object, this index MUST point to the first accessible column of a conceptual row in an external table containing the label. In this case, the mplsInSegmentTopLabel object SHOULD be set to 0 and ignored. This object MUST be set to zeroDotZero otherwise." ::= { mplsInSegmentMapEntry 3 } mplsInSegmentMapIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "The mplsInSegmentIndex that corresponds to the mplsInSegmentInterface and mplsInSegmentLabel, or the mplsInSegmentInterface and mplsInSegmentLabelPtr, if applicable. The string containing the single octet 0x00 MUST not be returned." ::= { mplsInSegmentMapEntry 4 } -- End mplsInSegmentMapTable -- Notification Configuration mplsXCNotificationsEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is set to true(1), then it enables the emission of mplsXCUp and mplsXCDown notifications; otherwise these notifications are not Srinivasan, et al. Standards Track [Page 44] RFC 3813 MPLS LSR MIB June 2004 emitted." REFERENCE "See also RFC3413 for explanation that notifications are under the ultimate control of the MIB module in this document." DEFVAL { false } ::= { mplsLsrObjects 15 } -- Cross-connect. mplsXCUp NOTIFICATION-TYPE OBJECTS { mplsXCOperStatus, -- start of range mplsXCOperStatus -- end of range } STATUS current DESCRIPTION "This notification is generated when the mplsXCOperStatus object for one or more contiguous entries in mplsXCTable are about to enter the up(1) state from some other state. The included values of mplsXCOperStatus MUST both be set equal to this new state (i.e: up(1)). The two instances of mplsXCOperStatus in this notification indicate the range of indexes that are affected. Note that all the indexes of the two ends of the range can be derived from the instance identifiers of these two objects. For cases where a contiguous range of cross-connects have transitioned into the up(1) state at roughly the same time, the device SHOULD issue a single notification for each range of contiguous indexes in an effort to minimize the emission of a large number of notifications. If a notification has to be issued for just a single cross-connect entry, then the instance identifier (and values) of the two mplsXCOperStatus objects MUST be the identical." ::= { mplsLsrNotifications 1 } mplsXCDown NOTIFICATION-TYPE OBJECTS { mplsXCOperStatus, -- start of range mplsXCOperStatus -- end of range } STATUS current DESCRIPTION "This notification is generated when the mplsXCOperStatus object for one or more contiguous entries in mplsXCTable are about to enter the down(2) state from some other state. The included values Srinivasan, et al. Standards Track [Page 45] RFC 3813 MPLS LSR MIB June 2004 of mplsXCOperStatus MUST both be set equal to this down(2) state. The two instances of mplsXCOperStatus in this notification indicate the range of indexes that are affected. Note that all the indexes of the two ends of the range can be derived from the instance identifiers of these two objects. For cases where a contiguous range of cross-connects have transitioned into the down(2) state at roughly the same time, the device SHOULD issue a single notification for each range of contiguous indexes in an effort to minimize the emission of a large number of notifications. If a notification has to be issued for just a single cross-connect entry, then the instance identifier (and values) of the two mplsXCOperStatus objects MUST be identical." ::= { mplsLsrNotifications 2 } -- End of notifications. -- Module compliance. mplsLsrGroups OBJECT IDENTIFIER ::= { mplsLsrConformance 1 } mplsLsrCompliances OBJECT IDENTIFIER ::= { mplsLsrConformance 2 } -- Compliance requirement for fully compliant implementations. mplsLsrModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for MPLS-LSR-STD-MIB. Such devices can then be monitored and also be configured using this MIB module." MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE -- This module. MANDATORY-GROUPS { mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, Srinivasan, et al. Standards Track [Page 46] RFC 3813 MPLS LSR MIB June 2004 mplsXCGroup, mplsPerfGroup } GROUP mplsLabelStackGroup DESCRIPTION "This group is only mandatory for LSRs that wish to support the modification of LSP label stacks. " GROUP mplsHCInSegmentPerfGroup DESCRIPTION "This group is mandatory for those in-segment entries for which the object mplsInSegmentOutOctets wraps around too quickly based on the criteria specified in RFC 2863 for high-capacity counters. " GROUP mplsHCOutSegmentPerfGroup DESCRIPTION "This group is mandatory for those out-segment entries for which the object mplsOutSegmentPerfOctets wraps around too quickly based on the criteria specified in RFC 2863 for high-capacity counters. " GROUP mplsLsrNotificationGroup DESCRIPTION "This group is only mandatory for those implementations which can efficiently implement the notifications contained in this group." OBJECT mplsInSegmentRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." OBJECT mplsOutSegmentNextHopAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "Only unknown(0), ipv4(1) and ipv6(2) support is required." OBJECT mplsOutSegmentNextHopAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support unknown(0), ipv4(1) and ipv6(2) sizes." OBJECT mplsOutSegmentRowStatus SYNTAX RowStatus { active(1), notInService(2) } Srinivasan, et al. Standards Track [Page 47] RFC 3813 MPLS LSR MIB June 2004 WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." OBJECT mplsLabelStackRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." OBJECT mplsXCRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." ::= { mplsLsrCompliances 1 } -- Compliance requirement for read-only implementations. mplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for MPLS-LSR-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB module. " MODULE IF-MIB -- The interfaces Group MIB, RFC 2863 MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE -- This module MANDATORY-GROUPS { mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsPerfGroup } Srinivasan, et al. Standards Track [Page 48] RFC 3813 MPLS LSR MIB June 2004 GROUP mplsLabelStackGroup DESCRIPTION "This group is only mandatory for LSRs that wish to support the modification of LSP label stacks. " GROUP mplsHCInSegmentPerfGroup DESCRIPTION "This group is mandatory for those in-segment entries for which the object mplsInSegmentOutOctets wraps around too quickly based on the criteria specified in RFC 2863 for high-capacity counters. " GROUP mplsHCOutSegmentPerfGroup DESCRIPTION "This group is mandatory for those out-segment entries for which the object mplsOutSegmentPerfOctets wraps around too quickly based on the criteria specified in RFC 2863 for high-capacity counters. " GROUP mplsLsrNotificationGroup DESCRIPTION "This group is only mandatory for those implementations which can efficiently implement the notifications contained in this group. " -- mplsInSegmentTable OBJECT mplsInSegmentLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsInSegmentLabelPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsInSegmentNPop SYNTAX Integer32 (1..1) MIN-ACCESS read-only DESCRIPTION "Write access is not required. This object SHOULD be set to 1 if it is read-only. " OBJECT mplsInSegmentAddrFamily MIN-ACCESS read-only DESCRIPTION "Write access is not required. A value of other(0) should be supported because there may be cases where the agent may not know about or support any address types. " Srinivasan, et al. Standards Track [Page 49] RFC 3813 MPLS LSR MIB June 2004 OBJECT mplsInSegmentRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsInSegmentStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- mplsOutSegmentTable OBJECT mplsOutSegmentInterface MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsOutSegmentPushTopLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsOutSegmentTopLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsOutSegmentTopLabelPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsOutSegmentNextHopAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only unknown(0), ipv4(1) and ipv6(2) support is required. " OBJECT mplsOutSegmentNextHopAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support unknown(0), ipv4(1) and ipv6(2) sizes." OBJECT mplsOutSegmentRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsOutSegmentStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Srinivasan, et al. Standards Track [Page 50] RFC 3813 MPLS LSR MIB June 2004 -- mplsXCTable OBJECT mplsXCLabelStackIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsXCAdminStatus MIN-ACCESS read-only DESCRIPTION "Read only support is required." OBJECT mplsXCRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsXCStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLabelStackLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLabelStackLabelPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLabelStackRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLabelStackStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mplsLsrCompliances 2 } -- Units of conformance. mplsInterfaceGroup OBJECT-GROUP OBJECTS { mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn, mplsInterfaceLabelMinOut, mplsInterfaceLabelMaxOut, mplsInterfaceTotalBandwidth, mplsInterfaceAvailableBandwidth, mplsInterfaceLabelParticipationType } Srinivasan, et al. Standards Track [Page 51] RFC 3813 MPLS LSR MIB June 2004 STATUS current DESCRIPTION "Collection of objects needed for MPLS interface and interface performance information." ::= { mplsLsrGroups 1 } mplsInSegmentGroup OBJECT-GROUP OBJECTS { mplsInSegmentIndexNext, mplsInSegmentInterface, mplsInSegmentLabel, mplsInSegmentLabelPtr, mplsInSegmentNPop, mplsInSegmentAddrFamily, mplsInSegmentXCIndex, mplsInSegmentOwner, mplsInSegmentRowStatus, mplsInSegmentStorageType, mplsInSegmentTrafficParamPtr, mplsInSegmentMapIndex } STATUS current DESCRIPTION "Collection of objects needed to implement an in- segment." ::= { mplsLsrGroups 2 } mplsOutSegmentGroup OBJECT-GROUP OBJECTS { mplsOutSegmentIndexNext, mplsOutSegmentInterface, mplsOutSegmentPushTopLabel, mplsOutSegmentTopLabel, mplsOutSegmentTopLabelPtr, mplsOutSegmentNextHopAddrType, mplsOutSegmentNextHopAddr, mplsOutSegmentXCIndex, mplsOutSegmentOwner, mplsOutSegmentPerfOctets, mplsOutSegmentPerfDiscards, mplsOutSegmentPerfErrors, mplsOutSegmentRowStatus, mplsOutSegmentStorageType, mplsOutSegmentTrafficParamPtr } STATUS current DESCRIPTION "Collection of objects needed to implement an out- Srinivasan, et al. Standards Track [Page 52] RFC 3813 MPLS LSR MIB June 2004 segment." ::= { mplsLsrGroups 3 } mplsXCGroup OBJECT-GROUP OBJECTS { mplsXCIndexNext, mplsXCLspId, mplsXCLabelStackIndex, mplsXCOwner, mplsXCStorageType, mplsXCAdminStatus, mplsXCOperStatus, mplsXCRowStatus, mplsXCNotificationsEnable } STATUS current DESCRIPTION "Collection of objects needed to implement a cross-connect entry." ::= { mplsLsrGroups 4 } mplsPerfGroup OBJECT-GROUP OBJECTS { mplsInSegmentPerfOctets, mplsInSegmentPerfPackets, mplsInSegmentPerfErrors, mplsInSegmentPerfDiscards, mplsInSegmentPerfDiscontinuityTime, mplsOutSegmentPerfOctets, mplsOutSegmentPerfPackets, mplsOutSegmentPerfDiscards, mplsOutSegmentPerfDiscontinuityTime, mplsInterfacePerfInLabelsInUse, mplsInterfacePerfInLabelLookupFailures, mplsInterfacePerfOutFragmentedPkts, mplsInterfacePerfOutLabelsInUse } STATUS current DESCRIPTION "Collection of objects providing performance information about an LSR." ::= { mplsLsrGroups 5 } mplsHCInSegmentPerfGroup OBJECT-GROUP OBJECTS { mplsInSegmentPerfHCOctets } STATUS current Srinivasan, et al. Standards Track [Page 53] RFC 3813 MPLS LSR MIB June 2004 DESCRIPTION "Object(s) providing performance information specific to out-segments for which the object mplsInterfaceInOctets wraps around too quickly." ::= { mplsLsrGroups 6 } mplsHCOutSegmentPerfGroup OBJECT-GROUP OBJECTS { mplsOutSegmentPerfHCOctets } STATUS current DESCRIPTION "Object(s) providing performance information specific to out-segments for which the object mplsInterfaceOutOctets wraps around too quickly." ::= { mplsLsrGroups 7 } mplsLabelStackGroup OBJECT-GROUP OBJECTS { mplsLabelStackLabel, mplsLabelStackLabelPtr, mplsLabelStackRowStatus, mplsLabelStackStorageType, mplsMaxLabelStackDepth, mplsLabelStackIndexNext } STATUS current DESCRIPTION "Objects needed to support label stacking." ::= { mplsLsrGroups 8 } mplsLsrNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mplsXCUp, mplsXCDown } STATUS current DESCRIPTION "Set of notifications implemented in this module." ::= { mplsLsrGroups 9 } END Srinivasan, et al. Standards Track [Page 54] RFC 3813 MPLS LSR MIB June 2004 11. Security Considerations It is clear that this MIB module is potentially useful for monitoring of MPLS LSRs. This MIB can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsLsrInSegmentTable, mplsLsrOutSegmentTable, mplsXCTable, mplsOutSegmentPerfTable, mplsInterfacePerfTable, and mplsInSegmentPerfTable collectively contain objects to provision MPLS interfaces, LSPs and their associated parameters on an Label Switching Router (LSR). Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LSP has been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module "i.e., objects with a MAX-ACCESS other than not-accessible" may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the mplsLsrInSegmentTable, mplsLsrOutSegmentTable, mplsXCTable, mplsOutSegmentPerfTable, mplsInterfacePerfTable, and mplsInSegmentPerfTable collectively show the LSP network topology and its performance characteristics. If an Administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. Srinivasan, et al. Standards Track [Page 55] RFC 3813 MPLS LSR MIB June 2004 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure "for example by using IPSec", even then, there is no control as to who on the secure network is allowed to access and GET/SET "read/change/create/delete" the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework "see [RFC3410], section 8", including full support for the SNMPv3 cryptographic mechanisms "for authentication and privacy". Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals "users" that have legitimate rights to indeed GET or SET "change/create/delete" them. 12. Acknowledgments We wish to thank Ron Bonica, Adrian Farrel, Eric Gray, Tim Mancour, Keith McCloghrie, Bala Rajagopalan, Dan Tappan, Vasanthi Thirumalai, Joseph Benoit, Mike Piecuch, Joan Cucchiara. A special thanks to Bert Wijnen and Mike MacFaden for really getting the MIB module into shape. 13. IANA Considerations As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB [RFC3811], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There are 4 MPLS MIB Modules contained in this document, each of the following "IANA Considerations" subsections requests IANA for a new assignment under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. 13.1. IANA Considerations for MPLS-LSR-STD-MIB The IANA has assigned { mplsStdMIB 2 } to the MPLS-LSR-STD-MIB module specified in this document. Srinivasan, et al. Standards Track [Page 56] RFC 3813 MPLS LSR MIB June 2004 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2515] Tesink, K., Ed., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3811] Nadeau, T. and J. Cucchiara, Eds., "Definition of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. Srinivasan, et al. Standards Track [Page 57] RFC 3813 MPLS LSR MIB June 2004 [IANAFamiy] Internet Assigned Numbers Authority (IANA), ADDRESS FAMILY NUMBERS, (http://www.iana.org/assignments/address-family- numbers), for MIB see: http://www.iana.org/assignments/ ianaaddressfamilynumbers-mib 14.2. Informative References [MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", Work in Progress, September 2003. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Srinivasan, et al. Standards Track [Page 58] RFC 3813 MPLS LSR MIB June 2004 15. Authors' Addresses Cheenu Srinivasan Bloomberg L.P. 499 Park Ave., New York, NY 10022 Phone: +1-212-893-3682 EMail: cheenu@bloomberg.net Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Phone: +1-408-571-3516 EMail: arunv@force10networks.com Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719 Phone: +1-978-936-1470 EMail: tnadeau@cisco.com Srinivasan, et al. Standards Track [Page 59] RFC 3813 MPLS LSR MIB June 2004 16. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Srinivasan, et al. Standards Track [Page 60] snmp-mibs-downloader-1.1/mibrfcs/rfc3814.txt0000644000000000000000000025273611402176071015600 0ustar Network Working Group T. Nadeau Request for Comments: 3814 Cisco Systems, Inc. Category: Standards Track C. Srinivasan Bloomberg L.P. A. Viswanathan Force10 Networks, Inc. June 2004 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used In This Document. . . . . . . . . . . . . . . 3 4. The Internet-Standard Management Framework . . . . . . . . . . 3 5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. mplsFTNTable . . . . . . . . . . . . . . . . . . . . . . 4 5.1.1. Advantages of Address Ranges Over CIDR Prefixes. 4 5.2. mplsFTNMapTable. . . . . . . . . . . . . . . . . . . . . 5 5.2.1. Indexing Requirements. . . . . . . . . . . . . . 5 5.2.2. How the Current Indexing Works . . . . . . . . . 5 5.3. mplsFTNPerfTable . . . . . . . . . . . . . . . . . . . . 7 6. Avoiding Retrieval-Modification Interactions . . . . . . . . . 7 Nadeau, et al. Standards Track [Page 1] RFC 3814 MPLS FTN MIB June 2004 7. Example Illustrating MIB Module Components . . . . . . . . . . 8 7.1. Sample FTN Rules . . . . . . . . . . . . . . . . . . . . 8 7.2. Creating FTN Entries and Applying them to Interfaces . . 9 7.3. Mapping an FTN Entry to Multiple Interfaces. . . . . . . 10 7.4. Inserting an Entry Into Existing List. . . . . . . . . . 11 7.5. Pictorial Tabular Relationship . . . . . . . . . . . . . 13 7.6. Deleting an Entry. . . . . . . . . . . . . . . . . . . . 14 8. The Use of RowPointer. . . . . . . . . . . . . . . . . . . . . 16 9. MPLS-FTN-STD-MIB Definitions . . . . . . . . . . . . . . . . . 16 10. Security Considerations. . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39 11.1. IANA Considerations for MPLS-FTN-STD-MIB . . . . . . . . 39 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 12.2. Informative References . . . . . . . . . . . . . . . . . 40 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for specifying Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for Multiprotocol Label Switching (MPLS). At the ingress of an MPLS network, packets entering the MPLS domain are assigned to an FEC. Those packets belonging to an FEC are associated with an NHLFE (i.e., MPLS label) via the FEC-to-NHLFE (FTN) mapping [RFC3031]. This relationship defines how ingress LSRs will impose MPLS labels onto incoming packets. It also defines how egress LSRs will decapsulate the MPLS shim header from MPLS packets. Conceptually, some of the FTN table functionality could be implemented using the Forwarding Information Base (FIB) to map all packets destined for a prefix to an LSP. However, this mapping is coarse in nature. Similar functionality is already being used in other contexts such as security filters, access filters, and RSVP flow identification. All of these require various combinations of matching based on IP header and upper-layer header information to identify packets for a particular treatment. When packets match a particular rule, a corresponding action is executed on those packets. For example, two popular actions to take when a successful match is identified are allowing the packet to be forwarded or to discard it. However, other Nadeau, et al. Standards Track [Page 2] RFC 3814 MPLS FTN MIB June 2004 actions are possible, such as modifying the TOS byte, or redirecting a packet to a particular outgoing interface. In the context of MPLS, the possible actions performed by an NHLFE are to redirect packets to either an MPLS Label Switched Path (LSP) or an MPLS Traffic Engineered (TE) Tunnel. This document attempts to consolidate the various matching requirements and associated action options needed for MPLS into a single specification. 2. Terminology Although all of the terminology used in this document is either covered in the MPLS Architecture [RFC3031] or in the SNMP Architecture [RFC3411], it is informational to define some immediately pertinent acronyms/terminology here. MPLS Multiprotocol Label Switching FEC Forwarding Equivalence Class NHLFE Next-Hop Label Forwarding Entry FTN FEC-to-NHLFE MIB Management Information Base 3. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 4. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Nadeau, et al. Standards Track [Page 3] RFC 3814 MPLS FTN MIB June 2004 5. Outline This MIB module resides on any LSR which does the FEC-to-NHLFE mapping in order to map traffic into the MPLS domain. This MIB module consists of three tables: - mplsFTNTable defines the rule base against which incoming packets are matched and defines the actions to be taken on matching packets; - mplsFTNMapTable defines the application of these rules to specific interfaces; - mplsFTNPerfTable provides performance counters for every entry in mplsFTNTable that is active on one or more interfaces, on a per- interface basis. 5.1. mplsFTNTable This table allows FEC to NHLFE mappings to be specified. Each entry in this table (also referred to as an "FTN entry" in this document) defines a rule to be applied to incoming packets (on interfaces that the entry is activated on using mplsFTNMapTable as explained in Section 5.2) and an action to be taken on matching packets. mplsFTNTable allows 6-tuple matching rules based on one or more of source address range, destination address range, source port range, destination port range, IPv4 Protocol field [RFC791] or IPv6 next- header field [RFC2460], and the DiffServ Code Point (DSCP, [RFC2474]) to be specified. Packet redirection is based on an action pointer which points either at an mplsXCEntry in MPLS-LSR-STD-MIB [RFC3813] when the NHLFE is a non-TE LSP, or at an mplsTunnelEntry in MPLS-TE- STD-MIB [RFC3812] when the NHLFE is the origin of a TE tunnel. 5.1.1. Advantages of Address Ranges Over CIDR Prefixes One possible way of specifying a set of addresses as part of an FTN rule is to use CIDR prefixes [RFC1519]. We have instead chosen to allow FTN rules to be expressed in terms of address ranges in mplsFTNTable because they have the following advantages. - The number of CIDR prefixes needed to represent some address ranges is very large. For example, we need the following 6 CIDR prefixes to represent the range of addresses [192.0.2.0- 192.0.2.62]: 192.0.2.0/27, 192.0.2.32/28, 192.0.2.48/29, 192.0.2.56/30, 192.0.2.60/31, and 192.0.2.62/32. A rule such as "redirect all packets with a source address in the range [192.0.2.0-192.0.2.62] and destination address in the range [192.0.2.128-192.0.2.190] to tunnel #2" would require the creation Nadeau, et al. Standards Track [Page 4] RFC 3814 MPLS FTN MIB June 2004 of 36 conceptual rows in mplsFTNTable if the rules were expressed as CIDR prefixes, but only a single conceptual row would be required if we used address ranges instead. - Every CIDR prefix can be expressed as a single equivalent address range. - A particular implementation is free to translate the address ranges specified in mplsFTNTable internally to equivalent CIDR prefixes, if it so chooses. However, given that powerful range matching algorithms are available, many implementations may prefer to implement these directly. 5.2. mplsFTNMapTable This table provides the capability to activate or map FTN entries defined in mplsFTNTable to specific interfaces in the system. Packets received on an interface are compared against FTN entries in the order in which entries are applied to the interface. 5.2.1. Indexing Requirements The indexing structure of mplsFTNMapTable was designed to satisfy the following requirements. - We must be able to insert a new entry into an existing list of entries on an interface with a single SET operation. Thus, we must be able to support an insertion operation that does not require manual reindexing of existing entries. - A management application must be able to traverse entries that have been applied to a particular interface in the order of application. The number of (non-bulk) retrieval operations to obtain this information as dictated by the particular indexing scheme that we choose for mplsFTNMapTable must be no more than that dictated by any other indexing scheme. For example, the indexing scheme must not force the Network Management Application to retrieve all the entries in the table and sift through them offline to obtain this information. 5.2.2. How the Current Indexing Works The natural data-structure for implementing constant time insertions between two existing entries and for supporting in-order traversals is a linked-list. The chosen indexing structure of mplsFTNMapTable makes the entries in the table behave like items in a linked-list. Each conceptual row Nadeau, et al. Standards Track [Page 5] RFC 3814 MPLS FTN MIB June 2004 has an object, mplsFTNMapPrevIndex, which is a pointer to the previous entry that is applied to a particular interface. This object is self-adjusting, i.e., its value is automatically adjusted by the agent, if necessary, after an insertion or deletion operation. This indexing scheme provides a mechanism to 'insert' an FTN entry between two existing entries already applied on an interface. This is done by specifying the entry after which a new entry should be inserted in mplsFTNMapPrevIndex. Using this linked-list structure, one can retrieve FTN entries in the order of application on a per-interface basis as follows: - To determine the first FTN entry on an interface with index ifIndex, perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.0.0; the returned object, if one exists, is (say) mplsFTNMapRowStatus.ifIndex.0.n (mplsFTNMapRowStatus is the first accessible columnar object in the conceptual row). Then, the index of the first FTN entry applied on this interface is n. - To determine the FTN entry applied to an interface after the one indexed by n, perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.n.0. If such an entry exists, the returned object would be of the form mplsFTNMapRowStatus.ifIndex.n.m. Then, the index of the next FTN entry applied on this interface is m. - If the FTN entry indexed by n is the last entry applied to the interface with index ifIndex, then the object returned would either be: 1. mplsFTNMapRowStatus.ifIndexNext.0.k, where ifIndexNext is the index of the next interface in ifTable to which an FTN entry has been applied, in which case k is the index of the first FTN entry applied to the interface with index ifIndexNext; or: 2. mplsFTNMapStorageType.firstIfIndex.0.p, if there are no more entries in mplsFTNMapTable, where firstIfIndex is the first entry in ifTable to which an FTN entry has been mapped. The above steps can be used to retrieve all the applied entries on a per-interface basis in application order. Note that the number of retrieval operations is equal to the number of applied FTN entries (i.e., the minimum number of GETNEXT operations needed using any indexing scheme). Nadeau, et al. Standards Track [Page 6] RFC 3814 MPLS FTN MIB June 2004 Also note that we could not have created this linked-list structure using a 'next' pointer object instead of the 'previous' pointer object that we chose because this would not allow us to determine the first FTN entry that has been mapped to a specific interface using a single SNMP (non-bulk) retrieval operation. The use of this indexing structure is further illustrated using an example in Section 7. 5.3. mplsFTNPerfTable If an FTN entry has been applied to one or more interfaces, this table provides high-capacity performance counters to monitor each such FTN entry on a per-interface basis. 6. Avoiding Retrieval-Modification Interactions The problem of an ongoing traversal or retrieval operation on an SNMP table being affected by a concurrent modification operation on that table is not unique to this MIB module. However, it is useful to note that a cautious application can keep track of the state of the modifiable tables in this MIB module using the objects mplsFTNTableLastChanged and mplsFTNMapTableLastChanged. For instance, before performing a traversal of mplsFTNMapTable, the application should retrieve the value of mplsFTNMapTableLastChanged. Each subsequent GETNEXT operation on the table should include this object as well. For example, GETNEXT(mplsFTNMapTableLastChanged.0, mplsFTNMapRowStatus.ifIndex.n.0) can be used to: - Determine the FTN entry after the one indexed by n (in linked-list order) mapped to the interface with index ifIndex, as explained in Section 5.2.2; - Verify that the value of mplsFTNMapTable has not been modified during the retrieval process by comparing the value of mplsFTNMapTableLastChanged retrieved by this operation with the value retrieved before the traversal was begun. Using this technique, an application can ensure the validity of the retrieved information with minimal overhead. This is particularly important while retrieving information from frequently modified tables. Nadeau, et al. Standards Track [Page 7] RFC 3814 MPLS FTN MIB June 2004 7. Example Illustrating MIB Module Components In this section, we use an example to illustrate how the objects defined in MPLS-FTN-STD-MIB work together to perform FEC to NHLFE mapping. Note that for the various table entries involved in this example, we only show the objects that help illustrate each case. 7.1. Sample FTN Rules Suppose that we wish to activate the following two FTN rules. Rule #1: On interface ifIndex = 1, redirect packets with source IPv4 address matching 192.0.2.63 to an LSP with outgoing ifIndex = 50 and outgoing label = 150 where the specified LSP is represented by the following entries in mplsXCTable and mplsOutSegmentTable. In mplsXCTable: { mplsXCIndex = 0x02, mplsXCInSegmentIndex = 0x00, mplsXCOutSegmentIndex = 0x03, mplsXCLabelStackIndex = 0 } The value 0x00 for mplsXCInSegmentIndex represents an originating LSP [RFC3813]. In mplsOutSegmentTable: { mplsOutSegmentIndex = 0x03, mplsOutSegmentIfIndex = 50, mplsOutSegmentPushTopLabel = true, mplsOutSegmentTopLabel = 150 } Rule #2: On interface ifIndex = 1, redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4, where the specified tunnel is represented by the following entry in mplsTunnelTable: Nadeau, et al. Standards Track [Page 8] RFC 3814 MPLS FTN MIB June 2004 { mplsTunnelIndex = 4, -- primary tunnel mplsTunnelInstance = 0, mplsTunnelIngressLSRID = 192.0.2.1, mplsTunnelEgressLSRID = 192.0.2.2 } 7.2. Creating FTN Entries and Applying them to Interfaces The action "redirect packets with source IPv4 address matching 192.0.2.63 to an LSP with outgoing ifIndex = 50 and outgoing label = 150" in Rule #1 can be implemented by the following entry in mplsFTNTable: { mplsFTNIndex = 1, mplsFTNDescr = "Rule #1", -- source address only mplsFTNMask = 0x80, mplsFTNAddrType = ipv4, mplsFTNSourceAddrMin = 192.0.2.63, mplsFTNSourceAddrMax = 192.0.2.63, mplsFTNActionType = redirectLsp(1), mplsFTNActionPointer = mplsXCLspId.1.2.1.0.1.3 } This indicates to which LSP the LSR should redirect packets by setting mplsFTNActionPointer to the first accessible columnar object instance in mplsXCEntry that corresponds of the LSP to use, in this case mplsXCLspId.1.2.1.0.1.3. This action is then activated on "interface ifIndex = 1" by the following entry in mplsFTNMapTable to complete the implementation of Rule #1: { -- apply rule to interface ifIndex = 1 mplsFTNMapIndex = 1, -- first FTN entry on this interface mplsFTNPrevIndex = 0, -- index of current entry in mplsFTNTable, i.e., Rule #1 mplsFTNMapCurrIndex = 1 } The action "redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4" in Rule #2 can be implemented by the following entry in mplsFTNTable: Nadeau, et al. Standards Track [Page 9] RFC 3814 MPLS FTN MIB June 2004 { mplsFTNIndex = 2, mplsFTNDescr = "Rule #2", -- destination address only mplsFTNMask = 0x40, mplsFTNAddrType = ipv4, mplsFTNDestAddrMin = 192.0.2.32, mplsFTNDestAddrMax = 192.0.2.96, mplsFTNActionType = redirectTunnel(2), mplsFTNActionPointer = mplsTunnelName.4.0.3221225985.3221225986 } where 3221225985 and 3221225986 are representations of the addresses 192.0.2.1 and 192.0.2.2, respectively, as Unsigned32 (the underlying data type) entities. This rule needs to be activated on "interface ifIndex = 1" after Rule #1 which was previously activated on this interface. This is done by the following entry in mplsFTNMapTable to complete the implementation of Rule #2: { -- apply rule to interface ifIndex = 1 mplsFTNMapIndex = 1, -- insert after Rule #1 (mplsFTNIndex = 1) mplsFTNPrevIndex = 1, -- index of current entry in mplsFTNTable, i.e., Rule #2 mplsFTNMapCurrIndex = 2 } 7.3. Mapping an FTN Entry to Multiple Interfaces Suppose we now wish to activate the following rule: Rule #2b: On interface ifIndex = 2, redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4. Notice that the FEC and corresponding action associated with this rule (i.e., "redirect packets with destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4") are the same as that associated with Rule #2. Hence, we can reuse the existing entry with mplsFTNIndex = 2 from mplsFTNTable. However, we have to create the following new entry in mplsFTNMapTable to activate this FTN entry as the first one on the interface with ifIndex = 2. Nadeau, et al. Standards Track [Page 10] RFC 3814 MPLS FTN MIB June 2004 { -- apply rule to interface ifIndex = 2 mplsFTNMapIndex = 2, -- first FTN entry on this interface mplsFTNPrevIndex = 0, -- index of current entry in mplsFTNTable mplsFTNMapCurrIndex = 2 } 7.4. Inserting an Entry Into Existing List At a later point, suppose that we wish to introduce the following Rule between Rules #1 and #2. Rule #3: On interface ifIndex = 1, redirect all packets with destination IPv4 address matching the prefix 192.0.2.32/28 to tunnel #3, where the tunnel we wish to redirect traffic to is represented by the following entry in mplsTunnelTable: { mplsTunnelIndex = 3, -- primary tunnel mplsTunnelInstance = 0, mplsTunnelIngressLSRID = 192.0.2.3, mplsTunnelEgressLSRID = 192.0.2.4 } Note that the ordering of the rules on a particular interface is critical since the range of addresses specified in Rule #3 is a subset of the ones specified in Rule #2. Without the linked-list style insertion feature supported by mplsFTNMapTable, we would possibly have had to reindex existing entries (or plan for such changes by leaving sufficient gaps between indexes, something that only postpones the problem). With the existing tables, we solve this problem by creating the following entries. We implement the phrase "redirect all packets with destination IPv4 address matching the prefix 1.4.0.0/16 to tunnel #3" in Rule #3 by creating the following entry in mplsFTNTable: Nadeau, et al. Standards Track [Page 11] RFC 3814 MPLS FTN MIB June 2004 { mplsFTNIndex = 3, mplsFTNDescr = "Rule #3", -- destination address only mplsFTNMask = 0x40, mplsFTNAddrType = ipv4, -- address range equivalent to CIDR prefix 192.0.2.32/28 mplsFTNDestAddrMin = 192.0.2.32, mplsFTNDestAddrMax = 192.0.2.47, mplsFTNActionType = redirectTunnel, mplsFTNActionPointer = mplsTunnelName.3.0.3221225987.3221225988 } where 3221225987 and 3221225988 are representations of the addresses 192.0.2.3 and 192.0.2.4, respectively, as Unsigned32 (the underlying data type) entities. We next insert this rule in mplsFTNMapTable just after Rule #1 as follows: { -- apply rule to interface ifIndex = 1 mplsFTNMapIndex = 1, -- insert after Rule #1 (mplsFTNIndex = 1) mplsFTNPrevIndex = 1, -- index of current entry in mplsFTNTable i.e., Rule #3 mplsFTNMapCurrIndex = 3 } After the insertion of Rule #3 in mplsFTNMapTable, the 'previous' pointer object mplsFTNMapPrevIndex of the next entry (corresponding to Rule #2) adjusts automatically to point to this entry. Note that, of the existing entries in the table, the only one that is impacted by an insertion operation is the entry on that particular interface immediately after the newly inserted one, if one exists. None of the other entries in mplsFTNMapTable are impacted. For instance, in this particular example, when the entry for Rule #3 was inserted between those for Rules #1 and #2, the entries for Rules #1 and #2b were not impacted. Nadeau, et al. Standards Track [Page 12] RFC 3814 MPLS FTN MIB June 2004 7.5. Pictorial Tabular Relationship At this point, the relationship between different table entries can be represented pictorially as follows. For each conceptual row instance, we show the table that it belongs to, along with its indices in parentheses. (Note that various conceptual rows are depicted in a way that is convenient for showing the interrelationships and are not necessarily in lexicographical order.) ifTable, The Interfaces Group MIB [RFC2863]: +-> ifEntry (1) | (ifIndex = 1) | | mplsFTNMapTable: | mplsFTNMapEntry (1.0.1): <--------------------+ +<-- (mplsFTNMapIndex = 1, | | mplsFTNMapPrevIndex = 0, ---> (NULL) | | mplsFTNMapCurrIndex = 1) ------------+ | | | | | mplsFTNMapEntry (1.1.3): <------------------+ | +<-- (mplsFTNMapIndex = 1, | | | | mplsFTNMapPrevIndex = 1, ----------->+ | | | mplsFTNMapCurrIndex = 3) ---------+ | | | | | | | | | mplsFTNMapEntry (1.3.2): <----------------+ | | +<-- (mplsFTNMapIndex = 1, | | | | | mplsFTNMapPrevIndex = 3, -------->+ | | | | mplsFTNMapCurrIndex = 2) ----+ | | | | | | | | | | | mplsFTNTable: | | | | | | mplsFTNEntry (2): | | | | | | +--> (mplsFTNIndex = 2) <----------+ | | | | | | | | | | | | mplsFTNEntry (3): | | | | | | (mplsFTNIndex = 3) <---------------+ | | | | | | | | | | mplsFTNEntry (1): | | | | | (mplsFTNIndex = 1) <------------------+ | | | | | | | | mplsFTNPerfTable: | | | | mplsFTNPerfEntry (1.2): | | | | (mplsFTNPerfIndex = 1, | | | | mplsFTNPerfCurrIndex = 2) --------------+ | | | | | | mplsFTNPerfEntry (1.3): | | | (mplsFTNPerfIndex = 1, | | | mplsFTNPerfCurrIndex = 3) ---------------+ | | | Nadeau, et al. Standards Track [Page 13] RFC 3814 MPLS FTN MIB June 2004 | mplsFTNPerfEntry (1.1): | | (mplsFTNPerfIndex = 1, | | mplsFTNPerfCurrIndex = 1) ------------------+ | | mplsFTNPerfEntry (2.2): | (mplsFTNPerfIndex = 2, | mplsFTNPerfCurrIndex = 2) ------------------+ | | | ifTable, The Interfaces Group MIB [RFC2863]: | +---> ifEntry (2): | | | (ifIndex = 2) | | | | | | mplsFTNMapEntry (2.1.2): <--------------------+ +----- (mplsFTNMapIndex = 2 | mplsFTNMapPrevIndex = 0 ---> (NULL) +---- mplsFTNMapCurrIndex = 2) 7.6. Deleting an Entry Let us next look at how we can remove the recently applied Rule #3 and how the existing conceptual rows behave in this situation. The conceptual row corresponding to the application of Rule #3 to interface ifIndex = 1 has the following index values: mplsFTNMapIndex = 1, mplsFTNMapPrevIndex = 1, and mplsFTNMapCurrIndex = 3. To delete this conceptual row, the Network Management Application performs a SET operation setting the object instance mplsFTNMapRowStatus.1.1.3 to the value destroy(6). The agent then destroys this conceptual row. It also automatically adjusts the object instance of mplsFTNMapPrevIndex corresponding to Rule #2 from the value 3 (i.e., pointing to the recently destroyed Rule #3) to the value 1 (i.e., to Rule #1). At this point, the rules applied to interface ifIndex = 1 are Rule #1 and Rule #2, in that order. The relationship between different table entries can be represented pictorially as follows. Nadeau, et al. Standards Track [Page 14] RFC 3814 MPLS FTN MIB June 2004 ifTable, The Interfaces Group MIB [RFC2863]: +-> ifEntry (1) | (ifIndex = 1) | | mplsFTNMapTable: | mplsFTNMapEntry (1.0.1): <--------------------+ +<-- (mplsFTNMapIndex = 1, | | mplsFTNMapPrevIndex = 0, ---> (NULL) | | mplsFTNMapCurrIndex = 1) ------------+ | | | | | mplsFTNMapEntry (1.1.2): <----------------+ | +<-- (mplsFTNMapIndex = 1, | | | mplsFTNMapPrevIndex = 1, ------------+ | | mplsFTNMapCurrIndex = 2) ----+ | | | | | | | mplsFTNTable: | | | | mplsFTNEntry (2): | | | | +--> (mplsFTNIndex = 2) <----------+ | | | | | | | | mplsFTNEntry (3): | | | | (mplsFTNIndex = 3) | | | | | | | | mplsFTNEntry (1): | | | | (mplsFTNIndex = 1) <------------------+ | | | | | | mplsFTNPerfTable: | | | mplsFTNPerfEntry (1.2): | | | (mplsFTNPerfIndex = 1, | | | mplsFTNPerfCurrIndex = 2) --------------+ | | | | mplsFTNPerfEntry (1.1): | | (mplsFTNPerfIndex = 1, | | mplsFTNPerfCurrIndex = 1) ------------------+ | | mplsFTNPerfEntry (2.2): | (mplsFTNPerfIndex = 2, | mplsFTNPerfCurrIndex = 2) ------------------+ | | | ifTable, The Interfaces Group MIB [RFC2863]: | +---> ifEntry (2): | | | (ifIndex = 2) | | | | | | mplsFTNMapEntry (2.1.2): <--------------------+ +----- (mplsFTNMapIndex = 2 | mplsFTNMapPrevIndex = 0 ---> (NULL) +---- mplsFTNMapCurrIndex = 2) Nadeau, et al. Standards Track [Page 15] RFC 3814 MPLS FTN MIB June 2004 Note that the FTN entry for Rule #3 still exists in mplsFTNTable at this point but is not referenced by any conceptual row in mplsFTNMapTable or mplsFTNPerfTable. Also note that the deletion of an entry from mplsFTNMapTable only impacts the entry on that particular interface immediately after the deleted entry, if one exists. None of the other conceptual rows in mplsFTNMapTable are impacted. For instance, in this particular example, when the entry for Rule #3 was deleted, the entries for Rules #1 and #2b were not impacted. 8. The Use of RowPointer RowPointer is a textual convention used to identify a conceptual row in a conceptual table in a MIB by pointing to the first accessible object. In this MIB module, in mplsFTNTable, the RowPointer object mplsFTNActionPointer indicates the LSP or TE Tunnel to redirect packets matching an FTN entry to. This object MUST point to the first instance of the first accessible columnar object in the appropriate conceptual row in order to allow the manager to find the appropriate corresponding entry in either MPLS-LSR-STD-MIB [RFC3813] or MPLS-TE-STD-MIB [RFC3812]. If this object returns zeroDotZerok, it implies that there is no currently defined action that is associated with that particular FTN entry. 9. MPLS-FTN-STD-MIB Definitions MPLS-FTN-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter64, Integer32 FROM SNMPv2-SMI -- [RFC2578] RowStatus, StorageType, RowPointer, TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndexOrZero, ifGeneralInformationGroup, ifCounterDiscontinuityGroup FROM IF-MIB -- [RFC2863] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] Dscp FROM DIFFSERV-DSCP-TC -- [RFC3289] InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- [RFC3291] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] Nadeau, et al. Standards Track [Page 16] RFC 3814 MPLS FTN MIB June 2004 ; mplsFTNStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 6, 2004 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Thomas D. Nadeau Postal: Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Tel: +1-978-244-3051 Email: tnadeau@cisco.com Cheenu Srinivasan Postal: Bloomberg L.P. 499 Park Avenue New York, NY 10022 Tel: +1-212-893-3682 Email: cheenu@bloomberg.net Arun Viswanathan Postal: Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Tel: +1-408-571-3516 Email: arunv@force10networks.com IETF MPLS Working Group email: mpls@uu.net" DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3814. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB module contains managed object definitions for specifying FEC to NHLFE (FTN) mappings and corresponding performance for MPLS." -- Revision history. REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version issued as part of RFC 3814." Nadeau, et al. Standards Track [Page 17] RFC 3814 MPLS FTN MIB June 2004 ::= { mplsStdMIB 8 } -- TEXTUAL-CONVENTIONs used in this MIB. MplsFTNEntryIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Index for an entry in mplsFTNTable." SYNTAX Unsigned32 (1..4294967295) MplsFTNEntryIndexOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Index for an entry in mplsFTNTable or the special value zero. The value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations when none or all entries in mplsFTNTable need to be referenced." SYNTAX Unsigned32 (0..4294967295) -- Top-Level Components of this MIB. mplsFTNNotifications OBJECT IDENTIFIER ::= { mplsFTNStdMIB 0 } mplsFTNObjects OBJECT IDENTIFIER ::= { mplsFTNStdMIB 1 } mplsFTNConformance OBJECT IDENTIFIER ::= { mplsFTNStdMIB 2 } -- Next free index in mplsFTNTable. mplsFTNIndexNext OBJECT-TYPE SYNTAX MplsFTNEntryIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the next available valid value to be used for mplsFTNIndex when creating entries in the mplsFTNTable. When creating a new conceptual row (configuration entry) in mplsFTNTable with an SNMP SET operation the command generator (Network Management Application) must first issue a management protocol retrieval operation to obtain the current value of this object. If the command responder (agent) does not wish to allow creation of more entries in mplsFTNTable, possibly because of resource exhaustion, this object MUST return a value of 0. If a non-zero value is returned the Network Management Nadeau, et al. Standards Track [Page 18] RFC 3814 MPLS FTN MIB June 2004 Application must determine whether the value is indeed still unused since two Network Management Applications may attempt to create a row simultaneously and use the same value. If it is currently unused and the SET succeeds, the agent MUST change the value of this object to a currently unused non-zero value (according to an implementation specific algorithm) or zero (if no further row creation will be permitted). If the value is in use, however, the SET fails and the Network Management Application must then reread this object to obtain a new usable value." ::= { mplsFTNObjects 1 } -- Last time an object in mplsFTNTable changed. mplsFTNTableLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the last time an entry was added, deleted or modified in mplsFTNTable. Management stations should consult this object to determine if mplsFTNTable requires their attention. This object is particularly useful for applications performing a retrieval on mplsFTNTable to ensure that the table is not modified during the retrieval operation." ::= { mplsFTNObjects 2 } -- Table of FTN entries. mplsFTNTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFTNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the currently defined FTN entries. This table allows FEC to NHLFE mappings to be specified. Each entry in this table defines a rule to be applied to incoming packets (on interfaces that the FTN entry is activated on using mplsFTNMapTable) and an action to be taken on matching packets (mplsFTNActionPointer). This table supports 6-tuple matching rules based on one or more of source address range, destination address range, source port range, destination port range, IPv4 Nadeau, et al. Standards Track [Page 19] RFC 3814 MPLS FTN MIB June 2004 Protocol field or IPv6 next-header field and the DiffServ Code Point (DSCP) to be specified. The action pointer points either to instance of mplsXCEntry in MPLS-LSR-STD-MIB when the NHLFE is a non- TE LSP, or to an instance of mplsTunnelEntry in the MPLS-TE-STD-MIB when the NHLFE is an originating TE tunnel." REFERENCE "J. Postel, Internet Protocol, RFC 791, STD 5, September 1981 Deering, S., and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998 Nichols, K, Blake, S., Baker, F. and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998 Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS Label Switch Router Management Information Base, RFC 3813 Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS Traffic Engineering Management Information Base, RFC 3812" ::= { mplsFTNObjects 3 } mplsFTNEntry OBJECT-TYPE SYNTAX MplsFTNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents one FTN entry which defines a rule to compare incoming packets with and an action to be taken on matching packets." INDEX { mplsFTNIndex } ::= { mplsFTNTable 1 } MplsFTNEntry ::= SEQUENCE { mplsFTNIndex MplsFTNEntryIndex, mplsFTNRowStatus RowStatus, mplsFTNDescr SnmpAdminString, mplsFTNMask BITS, mplsFTNAddrType InetAddressType, mplsFTNSourceAddrMin InetAddress, mplsFTNSourceAddrMax InetAddress, Nadeau, et al. Standards Track [Page 20] RFC 3814 MPLS FTN MIB June 2004 mplsFTNDestAddrMin InetAddress, mplsFTNDestAddrMax InetAddress, mplsFTNSourcePortMin InetPortNumber, mplsFTNSourcePortMax InetPortNumber, mplsFTNDestPortMin InetPortNumber, mplsFTNDestPortMax InetPortNumber, mplsFTNProtocol Integer32, mplsFTNDscp Dscp, mplsFTNActionType INTEGER, mplsFTNActionPointer RowPointer, mplsFTNStorageType StorageType } mplsFTNIndex OBJECT-TYPE SYNTAX MplsFTNEntryIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is the unique index for a conceptual row in mplsFTNTable. To create a new conceptual row in mplsFTNTable a Network Management Application SHOULD retrieve the current value of mplsFTNIndexNext to determine the next valid available value of mplsFTNIndex." ::= { mplsFTNEntry 1 } mplsFTNRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used for controlling the creation and deletion of this row. All writeable objects in this row may be modified at any time. If a Network Management Application attempts to delete a conceptual row by setting this object to 'destroy' and there are one or more entries in mplsFTNMapTable pointing to the row (i.e., when mplsFTNIndex of the conceptual row being deleted is equal to mplsFTNMapCurrIndex for one or more entries in mplsFTNMapTable), the agent MUST also destroy the corresponding entries in mplsFTNMapTable." ::= { mplsFTNEntry 2 } mplsFTNDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current Nadeau, et al. Standards Track [Page 21] RFC 3814 MPLS FTN MIB June 2004 DESCRIPTION "The description of this FTN entry. Since the index for this table has no particular significance or meaning, this object should contain some meaningful text that an operator could use to further distinguish entries in this table." ::= { mplsFTNEntry 3 } mplsFTNMask OBJECT-TYPE SYNTAX BITS { sourceAddr(0), destAddr(1), sourcePort(2), destPort(3), protocol(4), dscp(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bit map indicates which of the fields described next, namely source address range, destination address range, source port range, destination port range, IPv4 Protocol field or IPv6 next-header field and Differentiated Services Code Point (DSCP) is active for this FTN entry. If a particular bit is set to zero then the corresponding field in the packet MUST be ignored for comparison purposes." ::= { mplsFTNEntry 4 } mplsFTNAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This object determines the type of address contained in the source and destination address objects (mplsFTNSourceAddrMin, mplsFTNSourceAddrMax, mplsFTNDestAddrMin and mplsFTNDestAddrMax) of a conceptual row. This object MUST NOT be set to unknown(0) when mplsFTNMask has bit positions sourceAddr(0) or destAddr(1) set to one. When both these bit positions of mplsFTNMask are set to zero the value of mplsFTNAddrType SHOULD be set to unknown(0) and the corresponding source and destination Nadeau, et al. Standards Track [Page 22] RFC 3814 MPLS FTN MIB June 2004 address objects SHOULD be set to zero-length strings." ::= { mplsFTNEntry 5 } mplsFTNSourceAddrMin OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The lower end of the source address range. The type of this object is determined by the corresponding mplsFTNAddrType object." ::= { mplsFTNEntry 6 } mplsFTNSourceAddrMax OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The upper end of the source address range. The type of this object is determined by the corresponding mplsFTNAddrType object." ::= { mplsFTNEntry 7 } mplsFTNDestAddrMin OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The lower end of the destination address range. The type of this object is determined by the corresponding mplsFTNAddrType object." ::= { mplsFTNEntry 8 } mplsFTNDestAddrMax OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The higher end of the destination address range. The type of this object is determined by the corresponding mplsFTNAddrType object." ::= { mplsFTNEntry 9 } mplsFTNSourcePortMin OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION Nadeau, et al. Standards Track [Page 23] RFC 3814 MPLS FTN MIB June 2004 "The lower end of the source port range." DEFVAL { 0 } ::= { mplsFTNEntry 10 } mplsFTNSourcePortMax OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The higher end of the source port range " DEFVAL { 65535 } ::= { mplsFTNEntry 11 } mplsFTNDestPortMin OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The lower end of the destination port range." DEFVAL { 0 } ::= { mplsFTNEntry 12 } mplsFTNDestPortMax OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The higher end of the destination port range." DEFVAL { 65535 } ::= { mplsFTNEntry 13 } mplsFTNProtocol OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The IP protocol to match against the IPv4 protocol number or IPv6 Next-Header number in the packet. A value of 255 means match all. Note that the protocol number of 255 is reserved by IANA, and Next-Header number of 0 is used in IPv6." DEFVAL { 255 } ::= { mplsFTNEntry 14 } mplsFTNDscp OBJECT-TYPE SYNTAX Dscp MAX-ACCESS read-create STATUS current Nadeau, et al. Standards Track [Page 24] RFC 3814 MPLS FTN MIB June 2004 DESCRIPTION "The contents of the DSCP field." REFERENCE "Nichols, K., Blake, S., Baker, F. and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998." ::= { mplsFTNEntry 15 } mplsFTNActionType OBJECT-TYPE SYNTAX INTEGER { redirectLsp(1), -- redirect into LSP redirectTunnel(2) -- redirect into tunnel } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of action to be taken on packets matching this FTN entry." ::= { mplsFTNEntry 16 } mplsFTNActionPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsFTNActionType is redirectLsp(1), then this object MUST contain zeroDotZero or point to a instance of mplsXCEntry indicating the LSP to redirect matching packets to. If mplsFTNActionType is redirectTunnel(2), then this object MUST contain zeroDotZero or point to a instance of mplsTunnelEntry indicating the MPLS TE tunnel to redirect matching packets to. If this object points to a conceptual row instance in a table consistent with mplsFTNActionType but this instance does not currently exist then no action will be taken on packets matching such an FTN entry till this instance comes into existence. If this object contains zeroDotZero then no action will be taken on packets matching such an FTN entry till it is populated with a valid pointer consistent with the value of mplsFTNActionType as explained above." ::= { mplsFTNEntry 17 } Nadeau, et al. Standards Track [Page 25] RFC 3814 MPLS FTN MIB June 2004 mplsFTNStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this FTN entry. Conceptual rows having the value 'permanent' need not allow write- access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsFTNEntry 18 } -- End of mplsFTNTable. -- Last time an object in mplsFTNMapTable changed. mplsFTNMapTableLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the last time an entry was added, deleted or modified in mplsFTNMapTable. Management stations should consult this object to determine if the table requires their attention. This object is particularly useful for applications performing a retrieval on mplsFTNMapTable to ensure that the table is not modified during the retrieval operation." ::= { mplsFTNObjects 4 } -- FTN to interface mapping table. mplsFTNMapTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFTNMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects which provide the capability to apply or map FTN rules as defined by entries in mplsFTNTable to specific interfaces in the system. FTN rules are compared with incoming packets in the order in which they are applied on an interface. The indexing structure of mplsFTNMapTable is as follows. - mplsFTNMapIndex indicates the interface to which the rule is being applied. A value of 0 represents the application of the rule to all interfaces. Nadeau, et al. Standards Track [Page 26] RFC 3814 MPLS FTN MIB June 2004 - mplsFTNMapPrevIndex specifies the rule on the interface prior to the one being applied. A value of 0 specifies that the rule is being inserted at the head of the list of rules currently applied to the interface. - mplsFTNMapCurrIndex is the index in mplsFTNTable corresponding to the rule being applied. This indexing structure makes the entries in the table behave like items in a linked-list. The object mplsFTNMapPrevIndex in each conceptual row is a pointer to the previous entry that is applied to a particular interface. This allows a new entry to be 'inserted' at an arbitrary position in a list of entries currently applied to an interface. This object is self- adjusting, i.e., its value is automatically adjusted by the agent, if necessary, after an insertion or deletion operation. Using this linked-list structure, one can retrieve FTN entries in the order of application on a per-interface basis as follows: - To determine the first FTN entry on an interface with index ifIndex perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.0.0; the returned object, if one exists, is (say) mplsFTNMapRowStatus.ifIndex.0.n (mplsFTNMapRowStatus is the first accessible columnar object in the conceptual row). Then the index of the first FTN entry applied on this interface is n. - To determine the FTN entry applied to an interface after the one indexed by n perform a GETNEXT retrieval operation on mplsFTNMapRowStatus.ifIndex.n.0. If such an entry exists the returned object would be of the form mplsFTNMapRowStatus.ifIndex.n.m. Then the index of the next FTN entry applied on this interface is m. - If the FTN entry indexed by n is the last entry applied to the interface with index ifIndex then the object returned would either be: 1.mplsFTNMapRowStatus.ifIndexNext.0.k, where ifIndexNext is the index of the next interface in Nadeau, et al. Standards Track [Page 27] RFC 3814 MPLS FTN MIB June 2004 ifTable to which an FTN entry has been applied, in which case k is the index of the first FTN entry applied to the interface with index ifIndexNext; or: 2.mplsFTNMapStorageType.firstIfIndex.0.p, if there are no more entries in mplsFTNMapTable, where firstIfIndex is the first entry in ifTable to which an FTN entry has been mapped. Use the above steps to retrieve all the applied FTN entries on a per-interface basis in application order. Note that the number of retrieval operations is the same as the number of applied FTN entries (i.e., the minimum number of GETNEXT operations needed using any indexing scheme). Agents MUST NOT allow the same FTN entry as specified by mplsFTNMapCurrIndex to be applied multiple times to the same interface. Agents MUST NOT allow the creation of rows in this table until the corresponding rows are created in the mplsFTNTable. If a row in mplsFTNTable is destroyed, the agent MUST destroy the corresponding entries (i.e., ones with a matching value of mplsFTNCurrIndex) in this table as well." ::= { mplsFTNObjects 5 } mplsFTNMapEntry OBJECT-TYPE SYNTAX MplsFTNMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each conceptual row represents the application of an FTN rule at a specific position in the list of FTN rules applied on an interface. " INDEX { mplsFTNMapIndex, mplsFTNMapPrevIndex, mplsFTNMapCurrIndex } ::= { mplsFTNMapTable 1 } MplsFTNMapEntry ::= SEQUENCE { Nadeau, et al. Standards Track [Page 28] RFC 3814 MPLS FTN MIB June 2004 mplsFTNMapIndex InterfaceIndexOrZero, mplsFTNMapPrevIndex MplsFTNEntryIndexOrZero, mplsFTNMapCurrIndex MplsFTNEntryIndex, mplsFTNMapRowStatus RowStatus, mplsFTNMapStorageType StorageType } mplsFTNMapIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index that this FTN entry is being applied to. A value of zero indicates an entry that is applied all interfaces. Entries mapped to an interface by specifying its (non- zero) interface index in mplsFTNMapIndex are applied ahead of entries with mplsFTNMapIndex equal to zero." ::= { mplsFTNMapEntry 1 } mplsFTNMapPrevIndex OBJECT-TYPE SYNTAX MplsFTNEntryIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the previous FTN entry that was applied to this interface. The special value zero indicates that this should be the first FTN entry in the list." ::= { mplsFTNMapEntry 2 } mplsFTNMapCurrIndex OBJECT-TYPE SYNTAX MplsFTNEntryIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the current FTN entry that is being applied to this interface." ::= { mplsFTNMapEntry 3 } mplsFTNMapRowStatus OBJECT-TYPE SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } MAX-ACCESS read-create STATUS current Nadeau, et al. Standards Track [Page 29] RFC 3814 MPLS FTN MIB June 2004 DESCRIPTION "Used for controlling the creation and deletion of this row. All writable objects in this row may be modified at any time. If a conceptual row in mplsFTNMapTable points to a conceptual row in mplsFTNTable which is subsequently deleted, the corresponding conceptual row in mplsFTNMapTable MUST also be deleted by the agent." ::= { mplsFTNMapEntry 4 } mplsFTNMapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this entry. Conceptual rows having the value 'permanent' need not allow write- access to any columnar objects in this row." DEFVAL { nonVolatile } ::= { mplsFTNMapEntry 5 } -- End of mplsFTNMapTable -- FTN entry performance table mplsFTNPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFTNPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains performance statistics on FTN entries on a per-interface basis." ::= { mplsFTNObjects 6 } mplsFTNPerfEntry OBJECT-TYPE SYNTAX MplsFTNPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains performance information for the specified interface and an FTN entry mapped to this interface." INDEX { mplsFTNPerfIndex, mplsFTNPerfCurrIndex } ::= { mplsFTNPerfTable 1 } Nadeau, et al. Standards Track [Page 30] RFC 3814 MPLS FTN MIB June 2004 MplsFTNPerfEntry ::= SEQUENCE { mplsFTNPerfIndex InterfaceIndexOrZero, mplsFTNPerfCurrIndex MplsFTNEntryIndex, mplsFTNPerfMatchedPackets Counter64, mplsFTNPerfMatchedOctets Counter64, mplsFTNPerfDiscontinuityTime TimeStamp } mplsFTNPerfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index of an interface that an FTN entry has been applied/mapped to. Each instance of this object corresponds to an instance of mplsFTNMapIndex." ::= { mplsFTNPerfEntry 1 } mplsFTNPerfCurrIndex OBJECT-TYPE SYNTAX MplsFTNEntryIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of an FTN entry that has been applied/mapped to the specified interface. Each instance of this object corresponds to an instance of mplsFTNMapCurrIndex." ::= { mplsFTNPerfEntry 2 } mplsFTNPerfMatchedPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets that matched the specified FTN entry if it is applied/mapped to the specified interface. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsFTNDiscontinuityTime." ::= { mplsFTNPerfEntry 3 } mplsFTNPerfMatchedOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of octets that matched the specified FTN entry if it is applied/mapped to the specified interface. Nadeau, et al. Standards Track [Page 31] RFC 3814 MPLS FTN MIB June 2004 Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsFTNDiscontinuityTime." ::= { mplsFTNPerfEntry 4 } mplsFTNPerfDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this entry's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsFTNPerfEntry 5 } -- End of mplsFTNPerfTable -- Module compliance. -- Top level object IDs. mplsFTNGroups OBJECT IDENTIFIER ::= { mplsFTNConformance 1 } mplsFTNCompliances OBJECT IDENTIFIER ::= { mplsFTNConformance 2 } -- Compliance requirement for fully compliant implementations. mplsFTNModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for MPLS-FTN-STD-MIB." MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE -- This module. MANDATORY-GROUPS { mplsFTNRuleGroup, mplsFTNMapGroup, mplsFTNPerfGroup Nadeau, et al. Standards Track [Page 32] RFC 3814 MPLS FTN MIB June 2004 } OBJECT mplsFTNAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR." OBJECT mplsFTNSourceAddrMin SYNTAX InetAddress (SIZE (4 | 20)) DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR." OBJECT mplsFTNSourceAddrMax SYNTAX InetAddress (SIZE (4 | 20)) DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR." OBJECT mplsFTNDestAddrMin SYNTAX InetAddress (SIZE (4 | 20)) DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR." OBJECT mplsFTNDestAddrMax SYNTAX InetAddress (SIZE (4 | 20)) DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation is only required to support the address types that are actually supported on the LSR." ::= { mplsFTNCompliances 1 } -- Compliance requirement for read-only implementations. mplsFTNModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only Nadeau, et al. Standards Track [Page 33] RFC 3814 MPLS FTN MIB June 2004 provide read-only support for MPLS-FTN-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB module." MODULE IF-MIB -- The interfaces Group MIB, RFC 2863 MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE -- This module MANDATORY-GROUPS { mplsFTNRuleGroup, mplsFTNMapGroup, mplsFTNPerfGroup } OBJECT mplsFTNIndexNext MIN-ACCESS not-accessible DESCRIPTION "This object is not needed when mplsFTNTable is implemented as read-only." OBJECT mplsFTNRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT mplsFTNDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNMask MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT mplsFTNSourceAddrMin Nadeau, et al. Standards Track [Page 34] RFC 3814 MPLS FTN MIB June 2004 SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT mplsFTNSourceAddrMax SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT mplsFTNDestAddrMin SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT mplsFTNDestAddrMax SYNTAX InetAddress (SIZE (4 | 20)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT mplsFTNSourcePortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNSourcePortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNDestPortMin MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNDestPortMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNProtocol Nadeau, et al. Standards Track [Page 35] RFC 3814 MPLS FTN MIB June 2004 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNActionType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNActionPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNDscp MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFTNMapRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported." OBJECT mplsFTNMapStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mplsFTNCompliances 2 } -- Units of conformance. mplsFTNRuleGroup OBJECT-GROUP OBJECTS { mplsFTNIndexNext, mplsFTNTableLastChanged, mplsFTNRowStatus, mplsFTNDescr, mplsFTNMask, mplsFTNAddrType, mplsFTNSourceAddrMin, mplsFTNSourceAddrMax, Nadeau, et al. Standards Track [Page 36] RFC 3814 MPLS FTN MIB June 2004 mplsFTNDestAddrMin, mplsFTNDestAddrMax, mplsFTNSourcePortMin, mplsFTNSourcePortMax, mplsFTNDestPortMin, mplsFTNDestPortMax, mplsFTNProtocol, mplsFTNActionType, mplsFTNActionPointer, mplsFTNDscp, mplsFTNStorageType } STATUS current DESCRIPTION "Collection of objects that implement MPLS FTN rules." ::= { mplsFTNGroups 1 } mplsFTNMapGroup OBJECT-GROUP OBJECTS { mplsFTNMapTableLastChanged, mplsFTNMapRowStatus, mplsFTNMapStorageType } STATUS current DESCRIPTION "Collection of objects that implement activation of MPLS FTN entries on interfaces." ::= { mplsFTNGroups 2 } mplsFTNPerfGroup OBJECT-GROUP OBJECTS { mplsFTNPerfMatchedPackets, mplsFTNPerfMatchedOctets, mplsFTNPerfDiscontinuityTime } STATUS current DESCRIPTION "Collection of objects providing MPLS FTN performance information." ::= { mplsFTNGroups 3 } END Nadeau, et al. Standards Track [Page 37] RFC 3814 MPLS FTN MIB June 2004 10. Security Considerations This MIB module can be used to configure LSRs to redirect non-MPLS traffic into an MPLS cloud. As such, improper manipulation of the objects represented in this MIB module may result in traffic being redirected to unintended destinations, potentially resulting in denial of service to end-users. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - mplsFTNTable and mplsFTNMapTable can be used to create packet matching rules for classifying IPv4 or IPv6 traffic and redirecting matched packets into the MPLS cloud. Modifying objects in these tables can result in the misdirection of traffic and potential denial of service to end-users. It may also result in traffic which was intended to be redirected into the MPLS cloud being routed through the IP network instead, potentially resulting in degradation of service quality or outright denial of service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: - mplsFTNPerfTable provides counters for monitoring the performance of packet classification rules defined in mplsFTNTable and mplsFTNMapTable. Unauthorized read access to objects in these tables may be used to gain traffic flow information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Nadeau, et al. Standards Track [Page 38] RFC 3814 MPLS FTN MIB June 2004 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and cryptographic security be enabled. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects to only those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. IANA Considerations As described in [MPLSMGMT] and as requested in [RFC3811], MPLS related standards-track MIB modules should be rooted under the mplsStdMIB subtree. New assignments can only be made by a standards action as specified in [RFC2434]. 11.1. IANA Considerations for MPLS-FTN-STD-MIB The IANA has assigned mplsStdMIB 8 to the MPLS-FTN-STD-MIB module specified in this document. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. Nadeau, et al. Standards Track [Page 39] RFC 3814 MPLS FTN MIB June 2004 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC3811] Nadeau, T., and J. Cucchiara, J., Editors, "Definition of Textual Conventions (TCs) for Multi-Protocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. 12.2. Informative References [MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", Work in Progress, September 2003. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Nadeau, et al. Standards Track [Page 40] RFC 3814 MPLS FTN MIB June 2004 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 13. Acknowledgements We would particularly like to thank Bert Wijnen for the substantial time and effort he spent in helping us improve this document. We would also like to thank David Perkins, Joan Cucchiara, Mike Piecuch, and Adrien Grise for their insightful comments and additions to this document. 14. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 EMail: tnadeau@cisco.com Cheenu Srinivasan Bloomberg L.P. 499 Park Avenue New York, NY 10022 Phone: +1-212-893-3682 EMail: cheenu@bloomberg.net Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035 Phone: +1-408-571-3516 EMail: arunv@force10networks.com Nadeau, et al. Standards Track [Page 41] RFC 3814 MPLS FTN MIB June 2004 15. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nadeau, et al. Standards Track [Page 42] snmp-mibs-downloader-1.1/mibrfcs/rfc3815.txt0000644000000000000000000064555411402176071015605 0ustar Network Working Group J. Cucchiara Request for Comments: 3815 Marconi Communications, Inc. Category: Standards Track H. Sjostrand ipUnplugged J. Luciani Marconi Communications, Inc. June 2004 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework. . . . . . . . . . 3 3. Structure of the MIB Modules. . . . . . . . . . . . . . . . . 3 3.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Future Considerations . . . . . . . . . . . . . . . . . 4 3.3. Interface Indexing. . . . . . . . . . . . . . . . . . . 4 3.4. Differences from the LDP Specification. . . . . . . . . 4 3.5. The MPLS-LDP-STD-MIB Module . . . . . . . . . . . . . . 5 3.5.1. LDP Scalar Objects. . . . . . . . . . . . . . . 5 3.5.2. The LDP Entity Table. . . . . . . . . . . . . . 6 3.5.2.1. Changing Values After Session Establishment . . . . . . . . . . . . 6 3.5.3. The LDP Entity Statistics Table . . . . . . . . 7 Cucchiara, et al. Standards Track [Page 1] RFC 3815 MPLS LDP MIB June 2004 3.5.4. The LDP Peer Table. . . . . . . . . . . . . . . 7 3.5.5. The LDP Session Table . . . . . . . . . . . . . 8 3.5.6. The LDP Session Statistics Table. . . . . . . . 8 3.5.7. The LDP Hello Adjacency Table . . . . . . . . . 8 3.5.8. The LDP LSP Tables. . . . . . . . . . . . . . . 8 3.5.9. The FEC Tables. . . . . . . . . . . . . . . . . 9 3.5.10. The LDP Session Peer Address Table. . . . . . . 9 3.6. LDP Notifications . . . . . . . . . . . . . . . . . . . 9 3.7. LDP Notification Frequency. . . . . . . . . . . . . . . 10 4. MPLS Label Distribution Protocol MIB Definitions. . . . . . . 10 4.1. The MPLS-LDP-ATM-STD-MIB Module . . . . . . . . . . . . 60 4.1.1. The LDP Entity ATM Table. . . . . . . . . . . . 61 4.1.2. The LDP Entity ATM Label Range Table. . . . . . 61 4.1.3. The LDP ATM Session Table . . . . . . . . . . . 61 4.2. The MPLS-LDP-FRAME-RELAY-STD-MIB Module . . . . . . . . 77 4.2.1. The LDP Entity Frame Relay Table. . . . . . . . 77 4.2.2. The LDP Entity Frame Relay Label Range Table. . 77 4.2.3. The LDP Frame Relay Session Table . . . . . . . 77 4.3. The MPLS-LDP-GENERIC-STD-MIB Module . . . . . . . . . . 91 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 98 6. References. . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.1. Normative References. . . . . . . . . . . . . . . . . . 98 6.2. Informative References. . . . . . . . . . . . . . . . .100 7. Security Considerations . . . . . . . . . . . . . . . . . . .100 7.1. Security Considerations for MPLS-LDP-STD-MIB. . . . . .100 7.2. Security Considerations for MPLS-LDP-ATM-STD-MIB. . . .101 7.3. Security Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB. . . . . . . . . . . . . .102 7.4. Security Considerations for MPLS-LDP-GENERIC-STD-MIB. .103 7.5. Additional Security Considerations. . . . . . . . . . .103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .104 8.1. IANA Considerations for MPLS-LDP-STD-MIB. . . . . . . .104 8.2. IANA Considerations for MPLS-LDP-ATM-STD-MIB. . . . . .104 8.3. IANA Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB. .104 8.4. IANA Considerations for MPLS-LDP-GENERIC-STD-MIB. . . .104 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .105 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .106 1. Introduction This document defines 4 MIB Modules which together support the configuration and monitoring of the Label Distribution Protocol (LDP). The Label Distribution Protocol (LDP) [RFC3036] is one type of Multiprotocol Label Switching (MPLS) protocols described in [RFC3031] and [RFC3032]. Utilizing all 4 MIB Modules allows an operator to configure LDP sessions using 3 different Layer 2 media. The Layer 2 media supported by the MIB Modules are Ethernet, ATM and Frame Relay as described in [RFC3036], [RFC3034] and [RFC3035]. Cucchiara, et al. Standards Track [Page 2] RFC 3815 MPLS LDP MIB June 2004 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. For an introduction to the concepts of MPLS, see [RFC3031]. For further on LDP refer to [RFC3037] and [RFC3215]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Structure of the MIB Modules This section describes the structure of the LDP MIB Modules. 3.1. Overview There are 4 MIB Modules in this document. These MIB Modules are the MPLS-LDP-STD-MIB, the MPLS-LDP-GENERIC-STD-MIB, the MPLS-LDP-ATM-STD- MIB and the MPLS-LDP-FRAME-RELAY-STD-MIB. The MPLS-LDP-STD-MIB defines objects which are common to all LDP implementations. The MPLS-LDP-GENERIC-STD-MIB defines Layer 2 Per Platform Label Space objects for use with the MPLS-LDP-STD-MIB. The MPLS-LDP-ATM-STD-MIB defines Layer 2 Asynchronous Transfer Mode (ATM) objects for use with the MPLS-LDP-STD-MIB. The MPLS-LDP-FRAME-RELAY-STD-MIB defines Layer 2 FRAME-RELAY objects for use with the MPLS-LDP-STD-MIB. The MPLS-LDP-STD-MIB Module MUST be implemented and at least one of the Layer 2 MIB Modules MUST be implemented by an Agent developer on an Label Switching Router (LSR) or Label Edge Router (LER). As an example, if a Label Switching Router (LSR) or Label Edge Router (LER) implementation intends to support LDP utilizing a Layer 2 of Ethernet, then the MPLS-LDP-STD-MIB and the MPLS-LDP-GENERIC-STD-MIB Modules MUST implemented. If an LSR/LER implementation intends to support LDP utilizing a Layer 2 of ATM, then the MPLS-LDP-STD-MIB Module and the MPLS-LDP-ATM-MIB Module MUST be implemented. If an LSR/LER implementation intends to support LDP utilizing a Layer 2 of Cucchiara, et al. Standards Track [Page 3] RFC 3815 MPLS LDP MIB June 2004 FRAME-RELAY, then the MPLS-LDP-STD-MIB Module and the MPLS-LDP-FRAME- RELAY-STD-MIB Module MUST be implemented. An LDP implementation that utilizes all three Layer 2 media (Ethernet, Frame-Relay, ATM) MUST support all 4 MIB Modules. Each of the Modules will be discussed in detail in the following sections. There are 2 compliance statements for each MIB Module. One compliance statement is for full compliance which allows both configuration and monitoring via SNMP. The other compliance statement is for read-only compliance which allows only monitoring via SNMP. 3.2. Future Considerations The LDP Specification [RFC3036] does not specify the use of VPNs or multicast for LDP, and thus, objects related to these areas have not been included. [RFC2684] does not describe VP merge capability and so this feature has not been included. These areas need to be specified in the LDP Specification or other specifications prior to being added in this or any other MIB document. 3.3. Interface Indexing Interface Indexes as specified in [RFC2863] are used in these MIB Modules. The descriptions of the ifIndexes denote which ifIndex is being used. The use of ifIndex is for actual existing connections. 3.4. Differences from the LDP Specification Currently, there are 3 differences between this specification and the LDP Specification. As described in the Introduction, this document is almost entirely based on the LDP specification. The differences are documented here. The first difference is that the LDP Entity Table contains some DEFVAL clauses which are not specified explicitly in the LDP Specification. These values, although not documented in the LDP Specification, are widely used by existing LDP MIB implementations and thus, have been adopted within this MPLS-LDP-STD-MIB module. Please note, they can certainly be changed during row creation or a subsequent SET request. Cucchiara, et al. Standards Track [Page 4] RFC 3815 MPLS LDP MIB June 2004 A second difference is the mplsLdpEntityGenericLRTable in the MPLS- LDP-GENERIC-STD-MIB Module. This table, although provided as a way to reserve a range of generic labels, does not exist in the LDP Specification. It was added to the MIB due to a request from the working group and because this table was considered useful for reserving a range of generic labels. The third difference is documented by the TEXTUAL-CONVENTION, MplsAtmVcIdentifier which is in the MPLS-TC-STD-MIB [RFC3811]. This TC was added to restrict vci values to be greater than 31 as described in RFC 3035 [RFC3035]. 3.5. The MPLS-LDP-STD-MIB Module This MIB Module contains objects which are common to all LDP implementations. This MIB Module MUST always be implemented along with one or more of the Layer 2 MIB Modules. This MIB Module IMPORTS IndexInteger and IndexIntegerNextFree TEXTUAL-CONVENTIONs from [RFC3289], and IMPORTS InetAddressPrefixLength, InetAddressType, InetAddressInetPortNumber TEXTUAL-CONVENTIONs from [RFC3291]. The mplsLdpEntityTable table allows the Label Edge Router (LER) or the Label Switching Router (LSR) to initiate and/or receive requests to establish LDP sessions. As the LDP protocol distributes labels and establishes sessions with Peers most of the tables in this module are populated by the agent as instructed by the LDP protocol. The exception is the mplsFecTable and the mplsLdpLspFecTable which can be configured by the operator to specify Forwarding Equivalence Class information for an LSP. Some scalars and each table in the MPLS-LDP-STD-MIB Module are described in the following subsections. 3.5.1. LDP Scalar Objects There are several scalar objects in the LDP MIB module. The mplsLdpLsrId is a read-only scalar object which reports Label Switching Router's (LSR's) Identifier. This MUST be a globally unique value, such as the 32-bit router ID assigned to the LSR. The mplsLdpLsrLoopDetectionCapable scalar object denotes whether the LSR is capable of supporting loop detection and if so, which form of loop detection. Cucchiara, et al. Standards Track [Page 5] RFC 3815 MPLS LDP MIB June 2004 There are two LastChange scalar objects, mplsLdpEntityLastChange and mplsLdpPeerLastChange. These objects give an indication of there was a change in the number of entries in the table, or if any of the values in the respective tables changed. Please see the object's description for more details. The mplsLdpEntityIndexNext scalar object is described in the next section. 3.5.2. The LDP Entity Table The MPLS-LDP-STD-MIB provides objects to configure/set-up potential LDP sessions on a specific LSR/LER. The mplsLdpEntityTable is used to configure information which is used by the LDP protocol to setup potential LDP Sessions. Each entry/row in this table represents a single LDP Entity. There is no maximum number of LDP Entities specified. However, there is an mplsLdpEntityIndexNext object which should be retrieved by the command generator prior to creating an LDP Entity. If the mplsLdpEntityIndexNext object is zero, this indicates that the LSR/LER is not able to create another LDP Entity at that time. 3.5.2.1. Changing Values After Session Establishment One way to manually modify a session's parameters is by using SNMP to change the MIB objects related to that session. Please note, special care should be taken if MIB objects which are used in the MPLS LDP Session Initialization need to be modified. If the modification of any of these MIB variables takes place anytime after the start of session intialization, then the entire session must be halted. Any information learned by that session must be discarded. The objects should then be modified, and session initialization started. Assuming that the configuration was done correctly, then a new session will be created. For example, assume that an operator wishes to change the configuration of a Label Range which is used by a Session that has already been established. The operator should change the mplsLdpEntityAdminStatus to "disable(2)". Setting the mplsLdpEntityAdminStatus to "disable(2)" will cause the session to be torn down (i.e., this will signal to LDP that it should send out tear down messages for that session). Also, all information related to that session should be removed from this MIB by the Agent. This includes Peer information (i.e., relevant row in the mplsPeerTable) and Session statistics (i.e., relevant row in the mplsLdpSessionTable). Also, if the MPLS-LSR-STD-MIB module [RFC3813] is implemented and the optional Mapping Table objects are Cucchiara, et al. Standards Track [Page 6] RFC 3815 MPLS LDP MIB June 2004 implemented, then all information related to the LSPs in this session should be removed from these MIB modules. [For more information please see the section on "The Mapping Tables".] At this point, the operator could modify the Label Range. Lastly, the operator should set the mplsLdpEntityAdminStatus to "enable(1)". At this point session initialization should occur. The LDP Entity goes through the Session Initialization in order to communicate the new Label Ranges to the Peer and establish new LSPs. 3.5.3. The LDP Entity Statistics Table The mplsLpdEntityStatsTable is a read-only table which contains statistical information related to failed attempts to establish sessions. Each row in this table AUGMENTS an mplsLdpEntityEntry. This table could be used to give insight into how to reconfigure values so that a session could be successfully established. For example, if the mplsLdpEntityStatsSessionRejectedLRErrors Counter object was increasing, then this would indicate that the Label Range (LR) may need to be adjusted. 3.5.4. The LDP Peer Table The mplsLdpPeerTable is a read-only table which contains information about LDP Peers known to LDP Entities. In other words, the Peer information is learned by LDP through initialization or discovery. This table should be populated by the agent as directed by the LDP protocol. A row in this table is related to one or more rows in the Hello Adjacency Table and related to a single row in the Session Table. The values in the Peer table are specific to a Peer and may or may not be the same values used in the session. The reason is that the Peer and Entity negotiate certain values. The Entity's values are configured in the mplsLdpEntityTable and the Peer's values are learned (and placed into the mplsLdpPeerTable). The mplsLdpSessionTable shows the values used in establishing the session. One example, of when the Peer's values and the Session's values may differ is with the Peer's Path Limit information. The Peer's Path Limit information is learned from the session initialization phase. The actual value for the Path Vector Limit is the Peer's value and may not be the same value that appears in the session. There could be a mismatch in this value between the Entity and the Peer. In the event of a mismatch, then the session will use the Path Limit set by the Entity (and not the Peer). Cucchiara, et al. Standards Track [Page 7] RFC 3815 MPLS LDP MIB June 2004 The Peer Table information was placed in a separate table from the Session information to allow for a more comprehensive and coherent MIB model. 3.5.5. The LDP Session Table The mplsLdpSessionTable is a read-only table. Each entry in this table represents a single session between an LDP Entity and a Peer. The mplsLdpSessionEntry AUGMENTS the mplsLdpPeerEntry. The information in this table is learned during session establishment. NOTE: rows in this table will appear during session intialization. 3.5.6. The LDP Session Statistics Table The mplsLdpSessionStatsTable is a read-only table which contains statistical information on sessions. This table AUGMENTS the mplsLdpPeerTable. 3.5.7. The LDP Hello Adjacency Table This is a table of all adjacencies between all LDP Entities and all LDP Peers. A Session may have one or more adjacencies. A session should not have zero adjacencies, because this indicates that the session has lost contact with the Peer. A session which has zero Hello Adjacencies should be removed. 3.5.8. The LDP LSP Tables The Label Information Base (LIB) contains information about labels learned by the LSR. The LIB for LDP, CR-LDP and MPLS-RSVP (i.e., all currently defined MPLS protocols) is represented in the LSR MIB [RFC3813]. The LIB is represented by the LSR MIB's mplsXCTable (mpls Cross Connect Table), mplsInSegmentTable (mpls In Segment Table) and the mplsOutSegmentTable (mpls Out Segment Table). The mplsXCTable models the cross-connection of the incoming label with a specific outgoing label. The mplsInSegmentTable stores the incoming label's information, and the mplsOutSegmentTable stores the outgoing label's information. The LDP Session that created the LSP and the LSP's (incoming label, outgoing label) pair along with other information is contained in the MPLS-LSR-STD-MIB module's mplsXCTable, the mplsInSegmentTable and the mplsOutSegmentTable. Cucchiara, et al. Standards Track [Page 8] RFC 3815 MPLS LDP MIB June 2004 In order to utilize the MPLS-LSR-STD-MIB module's mplsXCTable, mplsInSegmentTable and mplsOutSegmentTable for LDP LSPs, there needs to be a mechanism to associate LDP sessions with LDP LSPs created as a result of those LDP sessions. The mplsInSegmentLdpLspTable and mplsOutSegmentLdpLspTable in this MIB contain information to find the LDP LSP entries in the mplsInSegmentTable, mplsOutSegmentTable and the mplsXCTable. These two tables, the mplsInSegmentLdpLspTable and mplsOutSegmentLdpLspTable, have been made optional in the conformance section of the MIB. They only need to be supported if the LSR MIBs mplsInSegmentTable, mplsOutSegmentTable and mplsXCTable are implemented. As discussed in the section, "Changing Values after Session Establishment", if a session is torn down, then all the information related to this session, must be removed from the both LDP MIB and, if implemented, from the LSR MIB. 3.5.9. The FEC Tables The mplsLdpFecTable is a table which contains FEC (Forwarding Equivalence Class) information. Each entry/row represents a single FEC Element. There is also an LDP LSP FEC Table, mplsLdpLspFecTable, which associates FECs with the LSPs. 3.5.10. The LDP Session Peer Address Table The mplsLdpSessionPeerAddrTable is a table which extends the mplsLdpSessionTable. This table is a read-only table which stores Addresses learned after session initialization via Address Message advertisement. 3.6. LDP Notifications Currently, there are several notifications which are specific for LDP. These are described in this section. There are no objects which enable or disable notifications from being generated. RFC 3413 [RFC3413] contains MIB modules which can be implemented that will enable or disable these notifications from being generated. The mplsLdpInitSessionThresholdExceeded notification indicates to the operator that there may be a misconfigured mplsLdpEntityEntry because the session associated with this Entity is not being established, and the Entity keeps trying to establish the session. A side effect of this situation is that a row in the mplsLdpSessionTable may not be reaching the operational state as indicated by the mplsLdpSessionState object. If the value of Cucchiara, et al. Standards Track [Page 9] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityInitSessionThreshold is 0 (zero) then this is equal to specifying the value of infinity for the threshold, and the mplsLdpInitSessionThresholdExceeded notification will never be sent. The mplsLdpPathVectorLimitMismatch notification is generated when there is a mismatch in the Path Vector Limits between the Entity and Peer during session initialization. The session uses the value which is configured as the Entity's Path Vector Limit. However, a notification should be generated to indicate that a mismatch occurred. For further details, please see Section 3.5.3 of the LDP Specification [RFC3036]. The mplsLdpSessionUp and mplsLdpSessionDown notifications are generated when there is an appropriate change in the mplsLdpSessionState object, e.g., when sessions change state (Up to Down for the mplsLdpSessionDown notification, or Down to Up for the mplsLdpSessionUp notification). There was discussion about combining these two notifications into a single notification, however, some NMS applications can utilize two different notifications, rather than having to parse the varbind list of a single notification. For example, the SessionDown is matched to a SessionUp notification more easily by some NMS applications, than having to parse a Varbind list in a SessionChange type of notification. 3.7. LDP Notification Frequency LDP Notifications are expected to be few in number when LDP is ubiquitously deployed in a relatively stable network. A notification receiver, e.g., an NMS, that receives these notifications should not be overwhelmed by the frequency of LDP notifications. If this assertion proves to be inaccurate, then a throttling object to throttle these notifications may be added to future versions of the MPLS-LDP-STD-MIB. 4. MPLS Label Distribution Protocol MIB Definitions MPLS-LDP-STD-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, Integer32, Counter32, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, TimeInterval, TruthValue, TimeStamp, StorageType Cucchiara, et al. Standards Track [Page 10] RFC 3815 MPLS LDP MIB June 2004 FROM SNMPv2-TC -- [RFC2579] InetAddressPrefixLength, InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- [RFC3291] IndexInteger, IndexIntegerNextFree FROM DIFFSERV-MIB -- [RFC3289] mplsStdMIB, MplsLabelDistributionMethod, MplsLdpIdentifier, MplsLdpLabelType, MplsLspType, MplsLsrIdentifier, MplsRetentionMode FROM MPLS-TC-STD-MIB -- [RFC3811] MplsIndexType FROM MPLS-LSR-STD-MIB; -- [RFC3813] mplsLdpStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "Multiprotocol Label Switching (mpls) Working Group" CONTACT-INFO "Joan Cucchiara (jcucchiara@mindspring.com) Marconi Communications, Inc. Hans Sjostrand (hans@ipunplugged.com) ipUnplugged James V. Luciani (james_luciani@mindspring.com) Marconi Communications, Inc. Working Group Chairs: George Swallow, email: swallow@cisco.com Loa Andersson, email: loa@pi.se MPLS Working Group, email: mpls@uu.net" DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published Cucchiara, et al. Standards Track [Page 11] RFC 3815 MPLS LDP MIB June 2004 in RFC 3815. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB contains managed object definitions for the 'Multiprotocol Label Switching, Label Distribution Protocol, LDP' document." REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version published as part of RFC 3815." ::= { mplsStdMIB 4 } --**************************************************************** mplsLdpNotifications OBJECT IDENTIFIER ::= { mplsLdpStdMIB 0 } mplsLdpObjects OBJECT IDENTIFIER ::= { mplsLdpStdMIB 1 } mplsLdpConformance OBJECT IDENTIFIER ::= { mplsLdpStdMIB 2 } --**************************************************************** -- MPLS LDP Objects --**************************************************************** mplsLdpLsrObjects OBJECT IDENTIFIER ::= { mplsLdpObjects 1 } mplsLdpEntityObjects OBJECT IDENTIFIER ::= { mplsLdpObjects 2 } -- -- The MPLS Label Distribution Protocol's -- Label Switching Router Objects -- mplsLdpLsrId OBJECT-TYPE SYNTAX MplsLsrIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The Label Switching Router's Identifier." ::= { mplsLdpLsrObjects 1 } mplsLdpLsrLoopDetectionCapable OBJECT-TYPE SYNTAX INTEGER { none(1), other(2), hopCount(3), pathVector(4), hopCountAndPathVector(5) Cucchiara, et al. Standards Track [Page 12] RFC 3815 MPLS LDP MIB June 2004 } MAX-ACCESS read-only STATUS current DESCRIPTION "A indication of whether this Label Switching Router supports loop detection. none(1) -- Loop Detection is not supported on this LSR. other(2) -- Loop Detection is supported but by a method other than those listed below. hopCount(3) -- Loop Detection is supported by Hop Count only. pathVector(4) -- Loop Detection is supported by Path Vector only. hopCountAndPathVector(5) -- Loop Detection is supported by both Hop Count And Path Vector. Since Loop Detection is determined during Session Initialization, an individual session may not be running with loop detection. This object simply gives an indication of whether or not the LSR has the ability to support Loop Detection and which types." ::= { mplsLdpLsrObjects 2 } -- -- The MPLS Label Distribution Protocol Entity Objects -- mplsLdpEntityLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the most recent addition or deletion of an entry to/from the mplsLdpEntityTable/mplsLdpEntityStatsTable, or the most recent change in value of any objects in the mplsLdpEntityTable. Cucchiara, et al. Standards Track [Page 13] RFC 3815 MPLS LDP MIB June 2004 If no such changes have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsLdpEntityObjects 1 } mplsLdpEntityIndexNext OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for mplsLdpEntityIndex when creating entries in the mplsLdpEntityTable. The value 0 indicates that no unassigned entries are available." ::= { mplsLdpEntityObjects 2 } mplsLdpEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about the MPLS Label Distribution Protocol Entities which exist on this Label Switching Router (LSR) or Label Edge Router (LER)." ::= { mplsLdpEntityObjects 3 } mplsLdpEntityEntry OBJECT-TYPE SYNTAX MplsLdpEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents an LDP entity. An entry can be created by a network administrator or by an SNMP agent as instructed by LDP." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex } ::= { mplsLdpEntityTable 1 } MplsLdpEntityEntry ::= SEQUENCE { mplsLdpEntityLdpId MplsLdpIdentifier, mplsLdpEntityIndex IndexInteger, mplsLdpEntityProtocolVersion Unsigned32, mplsLdpEntityAdminStatus INTEGER, mplsLdpEntityOperStatus INTEGER, mplsLdpEntityTcpPort InetPortNumber, mplsLdpEntityUdpDscPort InetPortNumber, Cucchiara, et al. Standards Track [Page 14] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityMaxPduLength Unsigned32, mplsLdpEntityKeepAliveHoldTimer Unsigned32, mplsLdpEntityHelloHoldTimer Unsigned32, mplsLdpEntityInitSessionThreshold Integer32, mplsLdpEntityLabelDistMethod MplsLabelDistributionMethod, mplsLdpEntityLabelRetentionMode MplsRetentionMode, mplsLdpEntityPathVectorLimit Integer32, mplsLdpEntityHopCountLimit Integer32, mplsLdpEntityTransportAddrKind INTEGER, mplsLdpEntityTargetPeer TruthValue, mplsLdpEntityTargetPeerAddrType InetAddressType, mplsLdpEntityTargetPeerAddr InetAddress, mplsLdpEntityLabelType MplsLdpLabelType, mplsLdpEntityDiscontinuityTime TimeStamp, mplsLdpEntityStorageType StorageType, mplsLdpEntityRowStatus RowStatus } mplsLdpEntityLdpId OBJECT-TYPE SYNTAX MplsLdpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The LDP identifier." REFERENCE "RFC3036, LDP Specification, Section on LDP Identifiers." ::= { mplsLdpEntityEntry 1 } mplsLdpEntityIndex OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index is used as a secondary index to uniquely identify this row. Before creating a row in this table, the 'mplsLdpEntityIndexNext' object should be retrieved. That value should be used for the value of this index when creating a row in this table. NOTE: if a value of zero (0) is retrieved, that indicates that no rows can be created in this table at this time. A secondary index (this object) is meaningful to some but not all, LDP implementations. For example an LDP implementation which uses PPP would use this index to differentiate PPP sub-links. Another way to use this index is to give this the value of ifIndex. However, this is dependant Cucchiara, et al. Standards Track [Page 15] RFC 3815 MPLS LDP MIB June 2004 on the implementation." ::= { mplsLdpEntityEntry 2 } mplsLdpEntityProtocolVersion OBJECT-TYPE SYNTAX Unsigned32(1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The version number of the LDP protocol which will be used in the session initialization message. Section 3.5.3 in the LDP Specification specifies that the version of the LDP protocol is negotiated during session establishment. The value of this object represents the value that is sent in the initialization message." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Initialization Message." DEFVAL { 1 } ::= { mplsLdpEntityEntry 3 } mplsLdpEntityAdminStatus OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative status of this LDP Entity. If this object is changed from 'enable' to 'disable' and this entity has already attempted to establish contact with a Peer, then all contact with that Peer is lost and all information from that Peer needs to be removed from the MIB. (This implies that the network management subsystem should clean up any related entry in the mplsLdpPeerTable. This further implies that a 'tear-down' for that session is issued and the session and all information related to that session cease to exist). At this point the operator is able to change values which are related to this entity. When the admin status is set back to 'enable', then this Entity will attempt to establish a new session with the Peer." Cucchiara, et al. Standards Track [Page 16] RFC 3815 MPLS LDP MIB June 2004 DEFVAL { enable } ::= { mplsLdpEntityEntry 4 } mplsLdpEntityOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), enabled(2), disabled(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this LDP Entity. The value of unknown(1) indicates that the operational status cannot be determined at this time. The value of unknown should be a transient condition before changing to enabled(2) or disabled(3)." ::= { mplsLdpEntityEntry 5 } mplsLdpEntityTcpPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The TCP Port for LDP. The default value is the well-known value of this port." REFERENCE "RFC3036, LDP Specification, Section 3.10, Well-known Numbers, and Section 3.10.1. UDP and TCP Ports." DEFVAL { 646 } ::= { mplsLdpEntityEntry 6 } mplsLdpEntityUdpDscPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The UDP Discovery Port for LDP. The default value is the well-known value for this port." REFERENCE "RFC3036, LDP Specification, Section 2.4.1, Basic Discovery Mechanism, Section 2.4.2, Extended Discovery Mechanism, Section 3.10, Well-known Numbers, and Section 3.10.1. Cucchiara, et al. Standards Track [Page 17] RFC 3815 MPLS LDP MIB June 2004 UDP and TCP Ports." DEFVAL { 646 } ::= { mplsLdpEntityEntry 7 } mplsLdpEntityMaxPduLength OBJECT-TYPE SYNTAX Unsigned32 (256..65535) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum PDU Length that is sent in the Common Session Parameters of an Initialization Message. According to the LDP Specification [RFC3036] a value of 255 or less specifies the default maximum length of 4096 octets, this is why the value of this object starts at 256. The operator should explicitly choose the default value (i.e., 4096), or some other value. The receiving LSR MUST calculate the maximum PDU length for the session by using the smaller of its and its peer's proposals for Max PDU Length." REFERENCE "RFC3036, LDP Specification, Section 3.5.3. Initialization Message." DEFVAL { 4096 } ::= { mplsLdpEntityEntry 8 } mplsLdpEntityKeepAliveHoldTimer OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The 16-bit integer value which is the proposed keep alive hold timer for this LDP Entity." DEFVAL { 40 } ::= { mplsLdpEntityEntry 9 } mplsLdpEntityHelloHoldTimer OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The 16-bit integer value which is the proposed Hello hold timer for this LDP Entity. The Hello Hold time in seconds. Cucchiara, et al. Standards Track [Page 18] RFC 3815 MPLS LDP MIB June 2004 An LSR maintains a record of Hellos received from potential peers. This object represents the Hold Time in the Common Hello Parameters TLV of the Hello Message. A value of 0 is a default value and should be interpretted in conjunction with the mplsLdpEntityTargetPeer object. If the value of this object is 0: if the value of the mplsLdpEntityTargetPeer object is false(2), then this specifies that the Hold Time's actual default value is 15 seconds (i.e., the default Hold time for Link Hellos is 15 seconds). Otherwise if the value of the mplsLdpEntityTargetPeer object is true(1), then this specifies that the Hold Time's actual default value is 45 seconds (i.e., the default Hold time for Targeted Hellos is 45 seconds). A value of 65535 means infinite (i.e., wait forever). All other values represent the amount of time in seconds to wait for a Hello Message. Setting the hold time to a value smaller than 15 is not recommended, although not forbidden according to RFC3036." REFERENCE "RFC3036, LDP Specification, Section 3.5.2., Hello Message." DEFVAL { 0 } ::= { mplsLdpEntityEntry 10 } mplsLdpEntityInitSessionThreshold OBJECT-TYPE SYNTAX Integer32(0..100) MAX-ACCESS read-create STATUS current DESCRIPTION "When attempting to establish a session with a given Peer, the given LDP Entity should send out the SNMP notification, 'mplsLdpInitSessionThresholdExceeded', when the number of Session Initialization messages sent exceeds this threshold. The notification is used to notify an operator when this Entity and its Peer are possibly engaged in an endless sequence of messages as each NAKs the other's Cucchiara, et al. Standards Track [Page 19] RFC 3815 MPLS LDP MIB June 2004 Initialization messages with Error Notification messages. Setting this threshold which triggers the notification is one way to notify the operator. The notification should be generated each time this threshold is exceeded and for every subsequent Initialization message which is NAK'd with an Error Notification message after this threshold is exceeded. A value of 0 (zero) for this object indicates that the threshold is infinity, thus the SNMP notification will never be generated." REFERENCE "RFC3036, LDP Specification, Section 2.5.3 Session Initialization." DEFVAL { 8 } ::= { mplsLdpEntityEntry 11 } mplsLdpEntityLabelDistMethod OBJECT-TYPE SYNTAX MplsLabelDistributionMethod MAX-ACCESS read-create STATUS current DESCRIPTION "For any given LDP session, the method of label distribution must be specified." ::= { mplsLdpEntityEntry 12 } mplsLdpEntityLabelRetentionMode OBJECT-TYPE SYNTAX MplsRetentionMode MAX-ACCESS read-create STATUS current DESCRIPTION "The LDP Entity can be configured to use either conservative or liberal label retention mode. If the value of this object is conservative(1) then advertized label mappings are retained only if they will be used to forward packets, i.e., if label came from a valid next hop. If the value of this object is liberal(2) then all advertized label mappings are retained whether they are from a valid next hop or not." ::= { mplsLdpEntityEntry 13 } mplsLdpEntityPathVectorLimit OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create Cucchiara, et al. Standards Track [Page 20] RFC 3815 MPLS LDP MIB June 2004 STATUS current DESCRIPTION "If the value of this object is 0 (zero) then Loop Detection for Path Vectors is disabled. Otherwise, if this object has a value greater than zero, then Loop Dection for Path Vectors is enabled, and the Path Vector Limit is this value. Also, the value of the object, 'mplsLdpLsrLoopDetectionCapable', must be set to either 'pathVector(4)' or 'hopCountAndPathVector(5)', if this object has a value greater than 0 (zero), otherwise it is ignored." REFERENCE "RFC3036, LDP Specification, Section 2.8 Loop Dection, Section 3.4.5 Path Vector TLV." ::= { mplsLdpEntityEntry 14 } mplsLdpEntityHopCountLimit OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is 0 (zero), then Loop Detection using Hop Counters is disabled. If the value of this object is greater than 0 (zero) then Loop Detection using Hop Counters is enabled, and this object specifies this Entity's maximum allowable value for the Hop Count. Also, the value of the object mplsLdpLsrLoopDetectionCapable must be set to either 'hopCount(3)' or 'hopCountAndPathVector(5)' if this object has a value greater than 0 (zero), otherwise it is ignored." DEFVAL { 0 } ::= { mplsLdpEntityEntry 15 } mplsLdpEntityTransportAddrKind OBJECT-TYPE SYNTAX INTEGER { interface(1), loopback(2) } MAX-ACCESS read-create STATUS current Cucchiara, et al. Standards Track [Page 21] RFC 3815 MPLS LDP MIB June 2004 DESCRIPTION "This specifies whether the loopback or interface address is to be used as the transport address in the transport address TLV of the hello message. If the value is interface(1), then the IP address of the interface from which hello messages are sent is used as the transport address in the hello message. Otherwise, if the value is loopback(2), then the IP address of the loopback interface is used as the transport address in the hello message." DEFVAL { loopback } ::= { mplsLdpEntityEntry 16 } mplsLdpEntityTargetPeer OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If this LDP entity uses targeted peer then set this to true." DEFVAL { false } ::= { mplsLdpEntityEntry 17 } mplsLdpEntityTargetPeerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the internetwork layer address used for the Extended Discovery. This object indicates how the value of mplsLdpEntityTargetPeerAddr is to be interpreted." ::= { mplsLdpEntityEntry 18 } mplsLdpEntityTargetPeerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the internetwork layer address used for the Extended Discovery. The value of mplsLdpEntityTargetPeerAddrType specifies how this address is to be interpreted." ::= { mplsLdpEntityEntry 19 } Cucchiara, et al. Standards Track [Page 22] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityLabelType OBJECT-TYPE SYNTAX MplsLdpLabelType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the optional parameters for the LDP Initialization Message. If the value is generic(1) then no optional parameters will be sent in the LDP Initialization message associated with this Entity. If the value is atmParameters(2) then a row must be created in the mplsLdpEntityAtmTable, which corresponds to this entry. If the value is frameRelayParameters(3) then a row must be created in the mplsLdpEntityFrameRelayTable, which corresponds to this entry." REFERENCE "RFC3036, LDP Specification, Section 3.5.3., Initialization Message." ::= { mplsLdpEntityEntry 20 } mplsLdpEntityDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this entity's counters suffered a discontinuity. The relevant counters are the specific instances associated with this entity of any Counter32 object contained in the 'mplsLdpEntityStatsTable'. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsLdpEntityEntry 21 } mplsLdpEntityStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current Cucchiara, et al. Standards Track [Page 23] RFC 3815 MPLS LDP MIB June 2004 DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL{ nonVolatile } ::= { mplsLdpEntityEntry 22 } mplsLdpEntityRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time, however, as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object, if a session has been initiated with a Peer, changing objects in this table will wreak havoc with the session and interrupt traffic. To repeat again: the recommended procedure is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. Then, change objects in this entry, then set the mplsLdpEntityAdminStatus to enable, which enables a new session to be initiated." ::= { mplsLdpEntityEntry 23 } -- -- The MPLS LDP Entity Statistics Table -- mplsLdpEntityStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is a read-only table which augments the mplsLdpEntityTable. The purpose of this table is to keep statistical information about the LDP Entities on the LSR." ::= { mplsLdpEntityObjects 4 } mplsLdpEntityStatsEntry OBJECT-TYPE SYNTAX MplsLdpEntityStatsEntry Cucchiara, et al. Standards Track [Page 24] RFC 3815 MPLS LDP MIB June 2004 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table contains statistical information about an LDP Entity. Some counters contained in a row are for fatal errors received during a former LDP Session associated with this entry. For example, an LDP PDU received on a TCP connection during an LDP Session contains a fatal error. That error is counted here, because the session is terminated. If the error is NOT fatal (i.e., the Session remains), then the error is counted in the mplsLdpSessionStatsEntry." AUGMENTS { mplsLdpEntityEntry } ::= { mplsLdpEntityStatsTable 1 } MplsLdpEntityStatsEntry ::= SEQUENCE { mplsLdpEntityStatsSessionAttempts Counter32, mplsLdpEntityStatsSessionRejectedNoHelloErrors Counter32, mplsLdpEntityStatsSessionRejectedAdErrors Counter32, mplsLdpEntityStatsSessionRejectedMaxPduErrors Counter32, mplsLdpEntityStatsSessionRejectedLRErrors Counter32, mplsLdpEntityStatsBadLdpIdentifierErrors Counter32, mplsLdpEntityStatsBadPduLengthErrors Counter32, mplsLdpEntityStatsBadMessageLengthErrors Counter32, mplsLdpEntityStatsBadTlvLengthErrors Counter32, mplsLdpEntityStatsMalformedTlvValueErrors Counter32, mplsLdpEntityStatsKeepAliveTimerExpErrors Counter32, mplsLdpEntityStatsShutdownReceivedNotifications Counter32, mplsLdpEntityStatsShutdownSentNotifications Counter32 } mplsLdpEntityStatsSessionAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the Session Initialization messages which were sent or received by this LDP Entity and were NAK'd. In other words, this counter counts the number of session initializations that failed. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." Cucchiara, et al. Standards Track [Page 25] RFC 3815 MPLS LDP MIB June 2004 ::= { mplsLdpEntityStatsEntry 1 } mplsLdpEntityStatsSessionRejectedNoHelloErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the Session Rejected/No Hello Error Notification Messages sent or received by this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 2 } mplsLdpEntityStatsSessionRejectedAdErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the Session Rejected/Parameters Advertisement Mode Error Notification Messages sent or received by this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 3 } mplsLdpEntityStatsSessionRejectedMaxPduErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the Session Rejected/Parameters Max Pdu Length Error Notification Messages sent or received by this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 4 } Cucchiara, et al. Standards Track [Page 26] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityStatsSessionRejectedLRErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the Session Rejected/Parameters Label Range Notification Messages sent or received by this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 5 } mplsLdpEntityStatsBadLdpIdentifierErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Bad LDP Identifier Fatal Errors detected by the session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." REFERENCE "RFC3036, LDP Specification, Section 3.5.1.2." ::= { mplsLdpEntityStatsEntry 6 } mplsLdpEntityStatsBadPduLengthErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Bad PDU Length Fatal Errors detected by the session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." REFERENCE "RFC3036, LDP Specification, Section 3.5.1.2." ::= { mplsLdpEntityStatsEntry 7 } Cucchiara, et al. Standards Track [Page 27] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityStatsBadMessageLengthErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Bad Message Length Fatal Errors detected by the session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." REFERENCE "RFC3036, LDP Specification, Section 3.5.1.2." ::= { mplsLdpEntityStatsEntry 8 } mplsLdpEntityStatsBadTlvLengthErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Bad TLV Length Fatal Errors detected by the session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." REFERENCE "RFC3036, LDP Specification, Section 3.5.1.2." ::= { mplsLdpEntityStatsEntry 9 } mplsLdpEntityStatsMalformedTlvValueErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Malformed TLV Value Fatal Errors detected by the session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." Cucchiara, et al. Standards Track [Page 28] RFC 3815 MPLS LDP MIB June 2004 REFERENCE "RFC3036, LDP Specification, Section 3.5.1.2." ::= { mplsLdpEntityStatsEntry 10 } mplsLdpEntityStatsKeepAliveTimerExpErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Session Keep Alive Timer Expired Errors detected by the session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." REFERENCE "RFC3036, LDP Specification, Section 3.5.1.2." ::= { mplsLdpEntityStatsEntry 11 } mplsLdpEntityStatsShutdownReceivedNotifications OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Shutdown Notifications received related to session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 12 } mplsLdpEntityStatsShutdownSentNotifications OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Shutdown Notfications sent related to session(s) (past and present) associated with this LDP Entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Cucchiara, et al. Standards Track [Page 29] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityDiscontinuityTime." ::= { mplsLdpEntityStatsEntry 13 } -- -- The MPLS LDP Peer Table -- mplsLdpSessionObjects OBJECT IDENTIFIER ::= { mplsLdpObjects 3 } mplsLdpPeerLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the most recent addition or deletion to/from the mplsLdpPeerTable/mplsLdpSessionTable." ::= { mplsLdpSessionObjects 1 } mplsLdpPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about LDP peers known by Entities in the mplsLdpEntityTable. The information in this table is based on information from the Entity-Peer interaction during session initialization but is not appropriate for the mplsLdpSessionTable, because objects in this table may or may not be used in session establishment." ::= { mplsLdpSessionObjects 2 } mplsLdpPeerEntry OBJECT-TYPE SYNTAX MplsLdpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single Peer which is related to a Session. This table is augmented by the mplsLdpSessionTable." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId } ::= { mplsLdpPeerTable 1 } MplsLdpPeerEntry ::= SEQUENCE { mplsLdpPeerLdpId MplsLdpIdentifier, mplsLdpPeerLabelDistMethod MplsLabelDistributionMethod, Cucchiara, et al. Standards Track [Page 30] RFC 3815 MPLS LDP MIB June 2004 mplsLdpPeerPathVectorLimit Integer32, mplsLdpPeerTransportAddrType InetAddressType, mplsLdpPeerTransportAddr InetAddress } mplsLdpPeerLdpId OBJECT-TYPE SYNTAX MplsLdpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The LDP identifier of this LDP Peer." ::= { mplsLdpPeerEntry 1 } mplsLdpPeerLabelDistMethod OBJECT-TYPE SYNTAX MplsLabelDistributionMethod MAX-ACCESS read-only STATUS current DESCRIPTION "For any given LDP session, the method of label distribution must be specified." ::= { mplsLdpPeerEntry 2 } mplsLdpPeerPathVectorLimit OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of this object is 0 (zero) then Loop Dection for Path Vectors for this Peer is disabled. Otherwise, if this object has a value greater than zero, then Loop Dection for Path Vectors for this Peer is enabled and the Path Vector Limit is this value." REFERENCE "RFC3036, LDP Specification, Section 2.8 Loop Dection, Section 3.4.5 Path Vector TLV." ::= { mplsLdpPeerEntry 3 } mplsLdpPeerTransportAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the Internet address for the mplsLdpPeerTransportAddr object. The LDP specification describes this as being either an IPv4 Transport Address or IPv6 Transport Cucchiara, et al. Standards Track [Page 31] RFC 3815 MPLS LDP MIB June 2004 Address which is used in opening the LDP session's TCP connection, or if the optional TLV is not present, then this is the IPv4/IPv6 source address for the UPD packet carrying the Hellos. This object specifies how the value of the mplsLdpPeerTransportAddr object should be interpreted." REFERENCE "RFC3036, LDP Specification, Section 2.5.2 Transport Connection Establishment and Section 3.5.2.1 Hello Message Procedures." ::= { mplsLdpPeerEntry 4 } mplsLdpPeerTransportAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet address advertised by the peer in the Hello Message or the Hello source address. The type of this address is specified by the value of the mplsLdpPeerTransportAddrType object." REFERENCE "RFC3036, LDP Specification, Section 2.5.2 Transport Connection Establishment and Section 3.5.2.1 Hello Message Procedures." ::= { mplsLdpPeerEntry 5 } -- -- The MPLS LDP Sessions Table -- mplsLdpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Sessions between the LDP Entities and LDP Peers. This table AUGMENTS the mplsLdpPeerTable. Each row in this table represents a single session." ::= { mplsLdpSessionObjects 3 } mplsLdpSessionEntry OBJECT-TYPE SYNTAX MplsLdpSessionEntry Cucchiara, et al. Standards Track [Page 32] RFC 3815 MPLS LDP MIB June 2004 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single session between an LDP Entity and LDP Peer. The information contained in a row is read-only. Please note: the Path Vector Limit for the Session is the value which is configured in the corresponding mplsLdpEntityEntry. The Peer's Path Vector Limit is in the mplsLdpPeerPathVectorLimit object in the mplsLdpPeerTable. Values which may differ from those configured are noted in the objects of this table, the mplsLdpAtmSessionTable and the mplsLdpFrameRelaySessionTable. A value will differ if it was negotiated between the Entity and the Peer. Values may or may not be negotiated. For example, if the values are the same then no negotiation takes place. If they are negotiated, then they may differ." AUGMENTS { mplsLdpPeerEntry } ::= { mplsLdpSessionTable 1 } MplsLdpSessionEntry ::= SEQUENCE { mplsLdpSessionStateLastChange TimeStamp, mplsLdpSessionState INTEGER, mplsLdpSessionRole INTEGER, mplsLdpSessionProtocolVersion Unsigned32, mplsLdpSessionKeepAliveHoldTimeRem TimeInterval, mplsLdpSessionKeepAliveTime Unsigned32, mplsLdpSessionMaxPduLength Unsigned32, mplsLdpSessionDiscontinuityTime TimeStamp } mplsLdpSessionStateLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this Session entered its current state as denoted by the mplsLdpSessionState object." ::= { mplsLdpSessionEntry 1 } Cucchiara, et al. Standards Track [Page 33] RFC 3815 MPLS LDP MIB June 2004 mplsLdpSessionState OBJECT-TYPE SYNTAX INTEGER { nonexistent(1), initialized(2), openrec(3), opensent(4), operational(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the session, all of the states 1 to 5 are based on the state machine for session negotiation behavior." REFERENCE "RFC3036, LDP Specification, Section 2.5.4, Initialization State Machine." ::= { mplsLdpSessionEntry 2 } mplsLdpSessionRole OBJECT-TYPE SYNTAX INTEGER { unknown(1), active(2), passive(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "During session establishment the LSR/LER takes either the active role or the passive role based on address comparisons. This object indicates whether this LSR/LER was behaving in an active role or passive role during this session's establishment. The value of unknown(1), indicates that the role is not able to be determined at the present time." REFERENCE "RFC3036, LDP Specification, Section 2.5.3., Session Initialization" ::= { mplsLdpSessionEntry 3 } mplsLdpSessionProtocolVersion OBJECT-TYPE SYNTAX Unsigned32(1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the LDP Protocol which this session is using. This is the version of Cucchiara, et al. Standards Track [Page 34] RFC 3815 MPLS LDP MIB June 2004 the LDP protocol which has been negotiated during session initialization." REFERENCE "RFC3036, LDP Specification, Section 3.5.3, Initialization Message." ::= { mplsLdpSessionEntry 4 } mplsLdpSessionKeepAliveHoldTimeRem OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "The keep alive hold time remaining for this session." ::= { mplsLdpSessionEntry 5 } mplsLdpSessionKeepAliveTime OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The negotiated KeepAlive Time which represents the amount of seconds between keep alive messages. The mplsLdpEntityKeepAliveHoldTimer related to this Session is the value that was proposed as the KeepAlive Time for this session. This value is negotiated during session initialization between the entity's proposed value (i.e., the value configured in mplsLdpEntityKeepAliveHoldTimer) and the peer's proposed KeepAlive Hold Timer value. This value is the smaller of the two proposed values." REFERENCE "RFC3036, LDP Specification, Section 3.5.3, Initialization Message." ::= { mplsLdpSessionEntry 6 } mplsLdpSessionMaxPduLength OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "octets" MAX-ACCESS read-only Cucchiara, et al. Standards Track [Page 35] RFC 3815 MPLS LDP MIB June 2004 STATUS current DESCRIPTION "The value of maximum allowable length for LDP PDUs for this session. This value may have been negotiated during the Session Initialization. This object is related to the mplsLdpEntityMaxPduLength object. The mplsLdpEntityMaxPduLength object specifies the requested LDP PDU length, and this object reflects the negotiated LDP PDU length between the Entity and the Peer." REFERENCE "RFC3036, LDP Specification, Section 3.5.3, Initialization Message." ::= { mplsLdpSessionEntry 7 } mplsLdpSessionDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this session's counters suffered a discontinuity. The relevant counters are the specific instances associated with this session of any Counter32 object contained in the mplsLdpSessionStatsTable. The initial value of this object is the value of sysUpTime when the entry was created in this table. Also, a command generator can distinguish when a session between a given Entity and Peer goes away and a new session is established. This value would change and thus indicate to the command generator that this is a different session." ::= { mplsLdpSessionEntry 8 } -- -- The MPLS LDP Session Statistics Table -- mplsLdpSessionStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of statistics for Sessions between LDP Entities and LDP Peers. This table AUGMENTS Cucchiara, et al. Standards Track [Page 36] RFC 3815 MPLS LDP MIB June 2004 the mplsLdpPeerTable." ::= { mplsLdpSessionObjects 4 } mplsLdpSessionStatsEntry OBJECT-TYPE SYNTAX MplsLdpSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents statistical information on a single session between an LDP Entity and LDP Peer." AUGMENTS { mplsLdpPeerEntry } ::= { mplsLdpSessionStatsTable 1 } MplsLdpSessionStatsEntry ::= SEQUENCE { mplsLdpSessionStatsUnknownMesTypeErrors Counter32, mplsLdpSessionStatsUnknownTlvErrors Counter32 } mplsLdpSessionStatsUnknownMesTypeErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Unknown Message Type Errors detected by this LSR/LER during this session. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpSessionDiscontinuityTime." ::= { mplsLdpSessionStatsEntry 1 } mplsLdpSessionStatsUnknownTlvErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Unknown TLV Errors detected by this LSR/LER during this session. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsLdpSessionDiscontinuityTime." ::= { mplsLdpSessionStatsEntry 2 } Cucchiara, et al. Standards Track [Page 37] RFC 3815 MPLS LDP MIB June 2004 -- -- The MPLS LDP Hello Adjacency Table -- mplsLdpHelloAdjacencyObjects OBJECT IDENTIFIER ::= { mplsLdpSessionObjects 5 } mplsLdpHelloAdjacencyTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpHelloAdjacencyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Hello Adjacencies for Sessions." ::= { mplsLdpHelloAdjacencyObjects 1 } mplsLdpHelloAdjacencyEntry OBJECT-TYPE SYNTAX MplsLdpHelloAdjacencyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row represents a single LDP Hello Adjacency. An LDP Session can have one or more Hello Adjacencies." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpHelloAdjacencyIndex } ::= { mplsLdpHelloAdjacencyTable 1 } MplsLdpHelloAdjacencyEntry ::= SEQUENCE { mplsLdpHelloAdjacencyIndex Unsigned32, mplsLdpHelloAdjacencyHoldTimeRem TimeInterval, mplsLdpHelloAdjacencyHoldTime Unsigned32, mplsLdpHelloAdjacencyType INTEGER } mplsLdpHelloAdjacencyIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier for this specific adjacency." ::= { mplsLdpHelloAdjacencyEntry 1 } mplsLdpHelloAdjacencyHoldTimeRem OBJECT-TYPE SYNTAX TimeInterval UNITS "seconds" MAX-ACCESS read-only Cucchiara, et al. Standards Track [Page 38] RFC 3815 MPLS LDP MIB June 2004 STATUS current DESCRIPTION "If the value of this object is 65535, this means that the hold time is infinite (i.e., wait forever). Otherwise, the time remaining for this Hello Adjacency to receive its next Hello Message. This interval will change when the 'next' Hello Message which corresponds to this Hello Adjacency is received unless it is infinite." ::= { mplsLdpHelloAdjacencyEntry 2 } mplsLdpHelloAdjacencyHoldTime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The Hello hold time which is negotiated between the Entity and the Peer. The entity associated with this Hello Adjacency issues a proposed Hello Hold Time value in the mplsLdpEntityHelloHoldTimer object. The peer also proposes a value and this object represents the negotiated value. A value of 0 means the default, which is 15 seconds for Link Hellos and 45 seconds for Targeted Hellos. A value of 65535 indicates an infinite hold time." REFERENCE "RFC3036, LDP Specification, Section 3.5.2 Hello Message" ::= { mplsLdpHelloAdjacencyEntry 3 } mplsLdpHelloAdjacencyType OBJECT-TYPE SYNTAX INTEGER { link(1), targeted(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This adjacency is the result of a 'link' hello if the value of this object is link(1). Cucchiara, et al. Standards Track [Page 39] RFC 3815 MPLS LDP MIB June 2004 Otherwise, it is a result of a 'targeted' hello, targeted(2)." ::= { mplsLdpHelloAdjacencyEntry 4 } -- -- Session Label (LSP) Mapping to LSR MIB's -- In Segment LIB Information. -- -- -- NOTE: the next 2 tables map to the -- MPLS-LSR-STD-MIB's MplsInSegmentTable -- and MplsOutSegmentTable. The -- cross-connect (XC) information is not -- represented here as it can be gleaned -- from the MPLS-LSR-STD-MIB. -- mplsInSegmentLdpLspTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsInSegmentLdpLspEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of LDP LSP's which map to the mplsInSegmentTable in the MPLS-LSR-STD-MIB module." ::= { mplsLdpSessionObjects 6 } mplsInSegmentLdpLspEntry OBJECT-TYPE SYNTAX MplsInSegmentLdpLspEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single LDP LSP which is represented by a session's index triple (mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId) AND the index for the mplsInSegmentTable (mplsInSegmentLdpLspLabelIndex) from the MPLS-LSR-STD-MIB. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsInSegmentLdpLspIndex } ::= { mplsInSegmentLdpLspTable 1 } Cucchiara, et al. Standards Track [Page 40] RFC 3815 MPLS LDP MIB June 2004 MplsInSegmentLdpLspEntry ::= SEQUENCE { mplsInSegmentLdpLspIndex MplsIndexType, mplsInSegmentLdpLspLabelType MplsLdpLabelType, mplsInSegmentLdpLspType MplsLspType } mplsInSegmentLdpLspIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This contains the same value as the mplsInSegmentIndex in the MPLS-LSR-STD-MIB's mplsInSegmentTable." ::= { mplsInSegmentLdpLspEntry 1 } mplsInSegmentLdpLspLabelType OBJECT-TYPE SYNTAX MplsLdpLabelType MAX-ACCESS read-only STATUS current DESCRIPTION "The Layer 2 Label Type." ::= { mplsInSegmentLdpLspEntry 2 } mplsInSegmentLdpLspType OBJECT-TYPE SYNTAX MplsLspType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of LSP connection." ::= { mplsInSegmentLdpLspEntry 3 } -- -- Session Label (LSP) Mapping to LSR MIB's -- Out Segment LIB Information. -- mplsOutSegmentLdpLspTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsOutSegmentLdpLspEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of LDP LSP's which map to the mplsOutSegmentTable in the MPLS-LSR-STD-MIB." ::= { mplsLdpSessionObjects 7 } mplsOutSegmentLdpLspEntry OBJECT-TYPE Cucchiara, et al. Standards Track [Page 41] RFC 3815 MPLS LDP MIB June 2004 SYNTAX MplsOutSegmentLdpLspEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single LDP LSP which is represented by a session's index triple (mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId) AND the index (mplsOutSegmentLdpLspIndex) for the mplsOutSegmentTable. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsOutSegmentLdpLspIndex } ::= { mplsOutSegmentLdpLspTable 1 } MplsOutSegmentLdpLspEntry ::= SEQUENCE { mplsOutSegmentLdpLspIndex MplsIndexType, mplsOutSegmentLdpLspLabelType MplsLdpLabelType, mplsOutSegmentLdpLspType MplsLspType } mplsOutSegmentLdpLspIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This contains the same value as the mplsOutSegmentIndex in the MPLS-LSR-STD-MIB's mplsOutSegmentTable." ::= { mplsOutSegmentLdpLspEntry 1 } mplsOutSegmentLdpLspLabelType OBJECT-TYPE SYNTAX MplsLdpLabelType MAX-ACCESS read-only STATUS current DESCRIPTION "The Layer 2 Label Type." ::= { mplsOutSegmentLdpLspEntry 2 } mplsOutSegmentLdpLspType OBJECT-TYPE SYNTAX MplsLspType MAX-ACCESS read-only STATUS current DESCRIPTION Cucchiara, et al. Standards Track [Page 42] RFC 3815 MPLS LDP MIB June 2004 "The type of LSP connection." ::= { mplsOutSegmentLdpLspEntry 3 } -- -- Mpls FEC Table -- mplsFecObjects OBJECT IDENTIFIER ::= { mplsLdpSessionObjects 8 } mplsFecLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the most recent addition/deletion of an entry to/from the mplsLdpFectTable or the most recent change in values to any objects in the mplsLdpFecTable. If no such changes have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsFecObjects 1 } mplsFecIndexNext OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for mplsFecIndex when creating entries in the mplsFecTable. The value 0 indicates that no unassigned entries are available." ::= { mplsFecObjects 2 } mplsFecTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the FEC (Forwarding Equivalence Class) Information associated with an LSP." ::= { mplsFecObjects 3 } Cucchiara, et al. Standards Track [Page 43] RFC 3815 MPLS LDP MIB June 2004 mplsFecEntry OBJECT-TYPE SYNTAX MplsFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row represents a single FEC Element." INDEX { mplsFecIndex } ::= { mplsFecTable 1 } MplsFecEntry ::= SEQUENCE { mplsFecIndex IndexInteger, mplsFecType INTEGER, mplsFecAddrType InetAddressType, mplsFecAddr InetAddress, mplsFecAddrPrefixLength InetAddressPrefixLength, mplsFecStorageType StorageType, mplsFecRowStatus RowStatus } mplsFecIndex OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index which uniquely identifies this entry." ::= { mplsFecEntry 1 } mplsFecType OBJECT-TYPE SYNTAX INTEGER { prefix(1), hostAddress(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the FEC. If the value of this object is 'prefix(1)' then the FEC type described by this row is an address prefix. If the value of this object is 'hostAddress(2)' then the FEC type described by this row is a host address." REFERENCE "RFC3036, Section 3.4.1. FEC TLV." ::= { mplsFecEntry 2 } mplsFecAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create Cucchiara, et al. Standards Track [Page 44] RFC 3815 MPLS LDP MIB June 2004 STATUS current DESCRIPTION "The value of this object is the type of the Internet address. The value of this object, decides how the value of the mplsFecAddr object is interpreted." REFERENCE "RFC3036, Section 3.4.1. FEC TLV." ::= { mplsFecEntry 4 } mplsFecAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is interpreted based on the value of the 'mplsFecAddrType' object. This address is then further interpretted as an being used with the address prefix, or as the host address. This further interpretation is indicated by the 'mplsFecType' object. In other words, the FEC element is populated according to the Prefix FEC Element value encoding, or the Host Address FEC Element encoding." REFERENCE "RFC3036, Section 3.4.1 FEC TLV." ::= { mplsFecEntry 5 } mplsFecAddrPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the 'mplsFecType' is 'hostAddress(2)' then this object is undefined. If the value of 'mplsFecType' is 'prefix(1)' then the value of this object is the length in bits of the address prefix represented by 'mplsFecAddr', or zero. If the value of this object is zero, this indicates that the prefix matches all addresses. In this case the address prefix MUST also be zero (i.e., 'mplsFecAddr' should have the value of zero.)" REFERENCE "RFC3036, Section 3.4.1. FEC TLV." DEFVAL { 0 } Cucchiara, et al. Standards Track [Page 45] RFC 3815 MPLS LDP MIB June 2004 ::= { mplsFecEntry 3 } mplsFecStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsFecEntry 6 } mplsFecRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. If the value of this object is 'active(1)', then none of the writable objects of this entry can be modified, except to set this object to 'destroy(6)'. NOTE: if this row is being referenced by any entry in the mplsLdpLspFecTable, then a request to destroy this row, will result in an inconsistentValue error." ::= { mplsFecEntry 7 } -- -- LDP LSP FEC Table -- mplsLdpLspFecLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the most recent addition/deletion of an entry to/from the mplsLdpLspFecTable or the most recent change in values to any objects in the mplsLdpLspFecTable. If no such changes have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsLdpSessionObjects 9 } Cucchiara, et al. Standards Track [Page 46] RFC 3815 MPLS LDP MIB June 2004 mplsLdpLspFecTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpLspFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table which shows the relationship between LDP LSPs and FECs. Each row represents a single LDP LSP to FEC association." ::= { mplsLdpSessionObjects 10 } mplsLdpLspFecEntry OBJECT-TYPE SYNTAX MplsLdpLspFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry represents a LDP LSP to FEC association." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpLspFecSegment, mplsLdpLspFecSegmentIndex, mplsLdpLspFecIndex } ::= { mplsLdpLspFecTable 1 } MplsLdpLspFecEntry ::= SEQUENCE { mplsLdpLspFecSegment INTEGER, mplsLdpLspFecSegmentIndex MplsIndexType, mplsLdpLspFecIndex IndexInteger, mplsLdpLspFecStorageType StorageType, mplsLdpLspFecRowStatus RowStatus } mplsLdpLspFecSegment OBJECT-TYPE SYNTAX INTEGER { inSegment(1), outSegment(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value is inSegment(1), then this indicates that the following index, mplsLdpLspFecSegmentIndex, contains the same value as the mplsInSegmentLdpLspIndex. Otherwise, if the value of this object is Cucchiara, et al. Standards Track [Page 47] RFC 3815 MPLS LDP MIB June 2004 outSegment(2), then this indicates that following index, mplsLdpLspFecSegmentIndex, contains the same value as the mplsOutSegmentLdpLspIndex." ::= { mplsLdpLspFecEntry 1 } mplsLdpLspFecSegmentIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index is interpretted by using the value of the mplsLdpLspFecSegment. If the mplsLdpLspFecSegment is inSegment(1), then this index has the same value as mplsInSegmentLdpLspIndex. If the mplsLdpLspFecSegment is outSegment(2), then this index has the same value as mplsOutSegmentLdpLspIndex." ::= { mplsLdpLspFecEntry 2 } mplsLdpLspFecIndex OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index identifies the FEC entry in the mplsFecTable associated with this session. In other words, the value of this index is the same as the value of the mplsFecIndex that denotes the FEC associated with this Session." ::= { mplsLdpLspFecEntry 3 } mplsLdpLspFecStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLdpLspFecEntry 4 } Cucchiara, et al. Standards Track [Page 48] RFC 3815 MPLS LDP MIB June 2004 mplsLdpLspFecRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. If the value of this object is 'active(1)', then none of the writable objects of this entry can be modified. The Agent should delete this row when the session ceases to exist. If an operator wants to associate the session with a different FEC, the recommended procedure is (as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object) is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. This will also cause this entry to be deleted. Then, set the mplsLdpEntityAdminStatus to enable which enables a new session to be initiated. Once the session is initiated, an entry may be added to this table to associate the new session with a FEC." ::= { mplsLdpLspFecEntry 5 } -- -- Address Message/Address Withdraw Message Information -- -- This information is associated with a specific Session -- because Label Address Messages are sent after session -- initialization has taken place. -- mplsLdpSessionPeerAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpSessionPeerAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table 'extends' the mplsLdpSessionTable. This table is used to store Label Address Information from Label Address Messages received by this LSR from Peers. This table is read-only and should be updated Cucchiara, et al. Standards Track [Page 49] RFC 3815 MPLS LDP MIB June 2004 when Label Withdraw Address Messages are received, i.e., Rows should be deleted as appropriate. NOTE: since more than one address may be contained in a Label Address Message, this table 'sparse augments', the mplsLdpSessionTable's information." ::= { mplsLdpSessionObjects 11 } mplsLdpSessionPeerAddrEntry OBJECT-TYPE SYNTAX MplsLdpSessionPeerAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a session's single next hop address which was advertised in an Address Message from the LDP peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpSessionPeerAddrIndex } ::= { mplsLdpSessionPeerAddrTable 1 } MplsLdpSessionPeerAddrEntry ::= SEQUENCE { mplsLdpSessionPeerAddrIndex Unsigned32, mplsLdpSessionPeerNextHopAddrType InetAddressType, mplsLdpSessionPeerNextHopAddr InetAddress } mplsLdpSessionPeerAddrIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index which uniquely identifies this entry within a given session." ::= { mplsLdpSessionPeerAddrEntry 1 } mplsLdpSessionPeerNextHopAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The internetwork layer address type of this Next Hop Address as specified in the Label Address Message associated with this Session. The value of this object indicates how to interpret the value of Cucchiara, et al. Standards Track [Page 50] RFC 3815 MPLS LDP MIB June 2004 mplsLdpSessionPeerNextHopAddr." ::= { mplsLdpSessionPeerAddrEntry 2 } mplsLdpSessionPeerNextHopAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The next hop address. The type of this address is specified by the value of the mplsLdpSessionPeerNextHopAddrType." REFERENCE "RFC3036, Section 2.7. LDP Identifiers and Next Hop Addresses" ::= { mplsLdpSessionPeerAddrEntry 3 } --- --- Notifications --- mplsLdpInitSessionThresholdExceeded NOTIFICATION-TYPE OBJECTS { mplsLdpEntityInitSessionThreshold } STATUS current DESCRIPTION "This notification is generated when the value of the 'mplsLdpEntityInitSessionThreshold' object is not zero, and the number of Session Initialization messages exceeds the value of the 'mplsLdpEntityInitSessionThreshold' object." ::= { mplsLdpNotifications 1 } mplsLdpPathVectorLimitMismatch NOTIFICATION-TYPE OBJECTS { mplsLdpEntityPathVectorLimit, mplsLdpPeerPathVectorLimit } STATUS current DESCRIPTION "This notification is sent when the 'mplsLdpEntityPathVectorLimit' does NOT match the value of the 'mplsLdpPeerPathVectorLimit' for a specific Entity." REFERENCE "RFC3036, LDP Specification, Section 3.5.3." ::= { mplsLdpNotifications 2 } Cucchiara, et al. Standards Track [Page 51] RFC 3815 MPLS LDP MIB June 2004 mplsLdpSessionUp NOTIFICATION-TYPE OBJECTS { mplsLdpSessionState, mplsLdpSessionDiscontinuityTime, mplsLdpSessionStatsUnknownMesTypeErrors, mplsLdpSessionStatsUnknownTlvErrors } STATUS current DESCRIPTION "If this notification is sent when the value of 'mplsLdpSessionState' enters the 'operational(5)' state." ::= { mplsLdpNotifications 3 } mplsLdpSessionDown NOTIFICATION-TYPE OBJECTS { mplsLdpSessionState, mplsLdpSessionDiscontinuityTime, mplsLdpSessionStatsUnknownMesTypeErrors, mplsLdpSessionStatsUnknownTlvErrors } STATUS current DESCRIPTION "This notification is sent when the value of 'mplsLdpSessionState' leaves the 'operational(5)' state." ::= { mplsLdpNotifications 4 } --**************************************************************** -- Module Conformance Statement --**************************************************************** mplsLdpGroups OBJECT IDENTIFIER ::= { mplsLdpConformance 1 } mplsLdpCompliances OBJECT IDENTIFIER ::= { mplsLdpConformance 2 } -- -- Full Compliance -- mplsLdpModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-create and read-write. In other Cucchiara, et al. Standards Track [Page 52] RFC 3815 MPLS LDP MIB June 2004 words, both monitoring and configuration are available when using this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { mplsLdpGeneralGroup, mplsLdpNotificationsGroup } GROUP mplsLdpLspGroup DESCRIPTION "This group must be supported if the LSR MIB is implemented, specifically the mplsInSegmentTable, the mplsOutSegmentTable or the mplsXCTable." OBJECT mplsLdpEntityTargetPeerAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support 'unknown(0)', IPv4 and globally unique IPv6 addresses." OBJECT mplsLdpEntityTargetPeerAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT mplsLdpEntityRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT mplsFecAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support 'unknown(0)', IPv4 and globally unique IPv6 addresses." OBJECT mplsFecAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT mplsFecRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION Cucchiara, et al. Standards Track [Page 53] RFC 3815 MPLS LDP MIB June 2004 "Support for createAndWait and notInService is not required." OBJECT mplsLdpLspFecRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT mplsLdpSessionPeerNextHopAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support 'unknown(0)', IPv4 and globally unique IPv6 addresses." OBJECT mplsLdpSessionPeerNextHopAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." ::= { mplsLdpCompliances 1 } -- -- Read-Only Compliance -- mplsLdpModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-only. In other words, only monitoring is available by implementing this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { mplsLdpGeneralGroup, mplsLdpNotificationsGroup } GROUP mplsLdpLspGroup DESCRIPTION "This group must be supported if the LSR MIB is implemented, specifically the mplsInSegmentTable, the mplsOutSegmentTable or the mplsXCTable." OBJECT mplsLdpEntityProtocolVersion MIN-ACCESS read-only Cucchiara, et al. Standards Track [Page 54] RFC 3815 MPLS LDP MIB June 2004 DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityTcpPort MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityUdpDscPort MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityMaxPduLength MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityKeepAliveHoldTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityHelloHoldTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityInitSessionThreshold MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityLabelDistMethod MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityLabelRetentionMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." Cucchiara, et al. Standards Track [Page 55] RFC 3815 MPLS LDP MIB June 2004 OBJECT mplsLdpEntityPathVectorLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityHopCountLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityTransportAddrKind MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityTargetPeer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityTargetPeerAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support 'unknown(0)', IPv4 and globally unique IPv6 addresses." OBJECT mplsLdpEntityTargetPeerAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT mplsLdpEntityLabelType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityRowStatus SYNTAX RowStatus { active(1) } Cucchiara, et al. Standards Track [Page 56] RFC 3815 MPLS LDP MIB June 2004 MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT mplsFecType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFecAddrPrefixLength MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFecAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support 'unknown(0)', IPv4 and globally unique IPv6 addresses." OBJECT mplsFecAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT mplsFecStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsFecRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT mplsLdpLspFecStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Cucchiara, et al. Standards Track [Page 57] RFC 3815 MPLS LDP MIB June 2004 OBJECT mplsLdpLspFecRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT mplsLdpSessionPeerNextHopAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support 'unknown(0)', IPv4 and globally unique IPv6 addresses." OBJECT mplsLdpSessionPeerNextHopAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." ::= { mplsLdpCompliances 2 } -- units of conformance mplsLdpGeneralGroup OBJECT-GROUP OBJECTS { mplsLdpLsrId, mplsLdpLsrLoopDetectionCapable, mplsLdpEntityLastChange, mplsLdpEntityIndexNext, mplsLdpEntityProtocolVersion, mplsLdpEntityAdminStatus, mplsLdpEntityOperStatus, mplsLdpEntityTcpPort, mplsLdpEntityUdpDscPort, mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldTimer, mplsLdpEntityHelloHoldTimer, mplsLdpEntityInitSessionThreshold, mplsLdpEntityLabelDistMethod, mplsLdpEntityLabelRetentionMode, mplsLdpEntityPathVectorLimit, mplsLdpEntityHopCountLimit, mplsLdpEntityTransportAddrKind, mplsLdpEntityTargetPeer, mplsLdpEntityTargetPeerAddrType, mplsLdpEntityTargetPeerAddr, mplsLdpEntityLabelType, Cucchiara, et al. Standards Track [Page 58] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityDiscontinuityTime, mplsLdpEntityStorageType, mplsLdpEntityRowStatus, mplsLdpEntityStatsSessionAttempts, mplsLdpEntityStatsSessionRejectedNoHelloErrors, mplsLdpEntityStatsSessionRejectedAdErrors, mplsLdpEntityStatsSessionRejectedMaxPduErrors, mplsLdpEntityStatsSessionRejectedLRErrors, mplsLdpEntityStatsBadLdpIdentifierErrors, mplsLdpEntityStatsBadPduLengthErrors, mplsLdpEntityStatsBadMessageLengthErrors, mplsLdpEntityStatsBadTlvLengthErrors, mplsLdpEntityStatsMalformedTlvValueErrors, mplsLdpEntityStatsKeepAliveTimerExpErrors, mplsLdpEntityStatsShutdownReceivedNotifications, mplsLdpEntityStatsShutdownSentNotifications, mplsLdpPeerLastChange, mplsLdpPeerLabelDistMethod, mplsLdpPeerPathVectorLimit, mplsLdpPeerTransportAddrType, mplsLdpPeerTransportAddr, mplsLdpHelloAdjacencyHoldTimeRem, mplsLdpHelloAdjacencyHoldTime, mplsLdpHelloAdjacencyType, mplsLdpSessionStateLastChange, mplsLdpSessionState, mplsLdpSessionRole, mplsLdpSessionProtocolVersion, mplsLdpSessionKeepAliveHoldTimeRem, mplsLdpSessionKeepAliveTime, mplsLdpSessionMaxPduLength, mplsLdpSessionDiscontinuityTime, mplsLdpSessionStatsUnknownMesTypeErrors, mplsLdpSessionStatsUnknownTlvErrors, mplsLdpSessionPeerNextHopAddrType, mplsLdpSessionPeerNextHopAddr, mplsFecLastChange, mplsFecIndexNext, mplsFecType, mplsFecAddrType, mplsFecAddr, mplsFecAddrPrefixLength, mplsFecStorageType, mplsFecRowStatus } STATUS current DESCRIPTION "Objects that apply to all MPLS LDP implementations." Cucchiara, et al. Standards Track [Page 59] RFC 3815 MPLS LDP MIB June 2004 ::= { mplsLdpGroups 1 } mplsLdpLspGroup OBJECT-GROUP OBJECTS { mplsInSegmentLdpLspLabelType, mplsInSegmentLdpLspType, mplsOutSegmentLdpLspLabelType, mplsOutSegmentLdpLspType, mplsLdpLspFecLastChange, mplsLdpLspFecStorageType, mplsLdpLspFecRowStatus } STATUS current DESCRIPTION "These objects are for LDP implementations which interface to the Label Information Base (LIB) in the MPLS-LSR-STD-MIB. The LIB is represented in the mplsInSegmentTable, mplsOutSegmentTable and mplsXCTable." ::= { mplsLdpGroups 2 } mplsLdpNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { mplsLdpInitSessionThresholdExceeded, mplsLdpPathVectorLimitMismatch, mplsLdpSessionUp, mplsLdpSessionDown } STATUS current DESCRIPTION "The notification for an MPLS LDP implementation." ::= { mplsLdpGroups 3 } END 4.1. The MPLS-LDP-ATM-STD-MIB Module This MIB Module MUST be supported if LDP uses ATM as the Layer 2 medium. There are three tables in this MIB Module. Two tables are for configuring LDP to use ATM. These tables are the mplsLdpEntityAtmTable and the mplsLdpEntityAtmLRTable. The third table is the mplsLdpAtmSessionTable which is a read-only table. This MIB Module IMPORTS the AtmVpIdentifier TEXTUAL-CONVENTION from [RFC2514]. Cucchiara, et al. Standards Track [Page 60] RFC 3815 MPLS LDP MIB June 2004 4.1.1. The LDP Entity ATM Table The mplsLdpEntityAtmTable provides a way to configure information which would be contained in the "Optional Parameter" portion of an LDP PDU Initialization Message. 4.1.2. The LDP Entity ATM Label Range Table The mplsLdpEntityAtmLRTable provides a way to configure information which would be contained in the "ATM Label Range Components" portion of an LDP PDU Intialization Message, see [RFC3035] and [RFC3036]. 4.1.3. The LDP ATM Session Table The MPLS LDP ATM Session Table is a read-only table which contains session information specific to ATM. MPLS-LDP-ATM-STD-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero FROM IF-MIB -- [RFC2020] AtmVpIdentifier FROM ATM-TC-MIB -- [RFC2514] mplsStdMIB, MplsAtmVcIdentifier FROM MPLS-TC-STD-MIB -- [RFC3811] mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId FROM MPLS-LDP-STD-MIB -- [RFC3813] ; mplsLdpAtmStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 Cucchiara, et al. Standards Track [Page 61] RFC 3815 MPLS LDP MIB June 2004 ORGANIZATION "Multiprotocol Label Switching (mpls) Working Group" CONTACT-INFO "Joan Cucchiara (jcucchiara@mindspring.com) Marconi Communications, Inc. Hans Sjostrand (hans@ipunplugged.com) ipUnplugged James V. Luciani (james_luciani@mindspring.com) Marconi Communications, Inc. Working Group Chairs: George Swallow, email: swallow@cisco.com Loa Andersson, email: loa@pi.se MPLS Working Group, email: mpls@uu.net " DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3815. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB contains managed object definitions for configuring and monitoring the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP), utilizing Asynchronous Transfer Mode (ATM) as the Layer 2 media." REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version published as part of RFC 3815." ::= { mplsStdMIB 5 } --**************************************************************** mplsLdpAtmObjects OBJECT IDENTIFIER ::= { mplsLdpAtmStdMIB 1 } mplsLdpAtmConformance OBJECT IDENTIFIER ::= { mplsLdpAtmStdMIB 2 } --**************************************************************** -- MPLS LDP ATM Objects --**************************************************************** -- -- Ldp Entity Objects for ATM Cucchiara, et al. Standards Track [Page 62] RFC 3815 MPLS LDP MIB June 2004 -- mplsLdpEntityAtmObjects OBJECT IDENTIFIER ::= { mplsLdpAtmObjects 1 } mplsLdpEntityAtmTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityAtmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM specific information which could be used in the 'Optional Parameters' and other ATM specific information. This table 'sparse augments' the mplsLdpEntityTable when ATM is the Layer 2 medium." ::= { mplsLdpEntityAtmObjects 1 } mplsLdpEntityAtmEntry OBJECT-TYPE SYNTAX MplsLdpEntityAtmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents the ATM parameters and ATM information for this LDP entity." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex } ::= { mplsLdpEntityAtmTable 1 } MplsLdpEntityAtmEntry ::= SEQUENCE { mplsLdpEntityAtmIfIndexOrZero InterfaceIndexOrZero, mplsLdpEntityAtmMergeCap INTEGER, mplsLdpEntityAtmLRComponents Unsigned32, mplsLdpEntityAtmVcDirectionality INTEGER, mplsLdpEntityAtmLsrConnectivity INTEGER, mplsLdpEntityAtmDefaultControlVpi AtmVpIdentifier, mplsLdpEntityAtmDefaultControlVci MplsAtmVcIdentifier, mplsLdpEntityAtmUnlabTrafVpi AtmVpIdentifier, mplsLdpEntityAtmUnlabTrafVci MplsAtmVcIdentifier, mplsLdpEntityAtmStorageType StorageType, mplsLdpEntityAtmRowStatus RowStatus } mplsLdpEntityAtmIfIndexOrZero OBJECT-TYPE SYNTAX InterfaceIndexOrZero Cucchiara, et al. Standards Track [Page 63] RFC 3815 MPLS LDP MIB June 2004 MAX-ACCESS read-create STATUS current DESCRIPTION "This value represents either the InterfaceIndex or 0 (zero). The value of zero means that the InterfaceIndex is not known. However, if the InterfaceIndex is known, then it must be represented by this value. If an InterfaceIndex becomes known, then the network management entity (e.g., SNMP agent) responsible for this object MUST change the value from 0 (zero) to the value of the InterfaceIndex. If an ATM Label is being used in forwarding data, then the value of this object MUST be the InterfaceIndex." ::= { mplsLdpEntityAtmEntry 1 } mplsLdpEntityAtmMergeCap OBJECT-TYPE SYNTAX INTEGER { notSupported(0), vpMerge(1), vcMerge(2), vpAndVcMerge(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes the Merge Capability of this Entity. This is the EXACT value for the ATM Session Parameter, field M (for ATM Merge Capabilities). The ATM Session Parameter is an optional parameter in the Initialization Message. The description from rfc3036.txt is: 'M, ATM Merge Capabilities Specifies the merge capabilities of an ATM switch. The following values are supported in this version of the specification: Value Meaning 0 Merge not supported 1 VP Merge supported 2 VC Merge supported 3 VP & VC Merge supported Cucchiara, et al. Standards Track [Page 64] RFC 3815 MPLS LDP MIB June 2004 If the merge capabilities of the LSRs differ, then: - Non-merge and VC-merge LSRs may freely interoperate. - The interoperability of VP-merge-capable switches with non-VP-merge-capable switches is a subject for future study. When the LSRs differ on the use of VP-merge, the session is established, but VP merge is not used.' Please refer to the following reference for a complete description of this feature." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Initialization Message." ::= { mplsLdpEntityAtmEntry 2 } mplsLdpEntityAtmLRComponents OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Label Range Components in the Initialization message. This also represents the number of entries in the mplsLdpEntityAtmLRTable which correspond to this entry. This is the EXACT value for the ATM Session Parameter, field N (for Number of label range components). The ATM Session Parameter is an optional parameter in the Initialization Message. The description from rfc3036.txt is: 'N, Number of label range components Specifies the number of ATM Label Range Components included in the TLV.' Please refer to the following reference for a complete description of this feature." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Initialization Message." ::= { mplsLdpEntityAtmEntry 3 } mplsLdpEntityAtmVcDirectionality OBJECT-TYPE SYNTAX INTEGER { bidirectional(0), Cucchiara, et al. Standards Track [Page 65] RFC 3815 MPLS LDP MIB June 2004 unidirectional(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is 'bidirectional(0)', a given VCI, within a given VPI, is used as a label for both directions independently. If the value of this object is 'unidirectional(1)', a given VCI within a VPI designates one direction. This is the EXACT value for the ATM Session Parameter, field D (for VC Directionality). The ATM Session Parameter is an optional parameter in the Initialization Message. The description from rfc3036.txt is: 'D, VC Directionality A value of 0 specifies bidirectional VC capability, meaning the LSR can (within a given VPI) support the use of a given VCI as a label for both link directions independently. A value of 1 specifies unidirectional VC capability, meaning (within a given VPI) a given VCI may appear in a label mapping for one direction on the link only. When either or both of the peers specifies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP Identifier may assign only odd-numbered VCIs in the VPI/VCI range as labels. The system with the smaller LDP Identifier may assign only even-numbered VCIs in the VPI/VCI range as labels.' Please refer to the following reference for a complete description of this feature." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Initialization Message." ::= { mplsLdpEntityAtmEntry 4 } mplsLdpEntityAtmLsrConnectivity OBJECT-TYPE SYNTAX INTEGER { direct(1), Cucchiara, et al. Standards Track [Page 66] RFC 3815 MPLS LDP MIB June 2004 indirect(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The peer LSR may be connected indirectly by means of an ATM VP so that the VPI values may be different on either endpoint so the label MUST be encoded entirely within the VCI field." DEFVAL { direct } ::= { mplsLdpEntityAtmEntry 5 } mplsLdpEntityAtmDefaultControlVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The default VPI value for the non-MPLS connection. The default value of this is 0 (zero) but other values may be configured. This object allows a different value to be configured." DEFVAL { 0 } ::= { mplsLdpEntityAtmEntry 6 } mplsLdpEntityAtmDefaultControlVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The Default VCI value for a non-MPLS connection. The default value of this is 32 but other values may be configured. This object allows a different value to be configured." DEFVAL { 32 } ::= { mplsLdpEntityAtmEntry 7 } mplsLdpEntityAtmUnlabTrafVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "VPI value of the VCC supporting unlabeled traffic. This non-MPLS connection is used to carry unlabeled (IP) packets. The default value is the same as the default value of the 'mplsLdpEntityAtmDefaultControlVpi', however another value may be configured." DEFVAL { 0 } ::= { mplsLdpEntityAtmEntry 8 } Cucchiara, et al. Standards Track [Page 67] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityAtmUnlabTrafVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "VCI value of the VCC supporting unlabeled traffic. This non-MPLS connection is used to carry unlabeled (IP) packets. The default value is the same as the default value of the 'mplsLdpEntityAtmDefaultControlVci', however another value may be configured." DEFVAL { 32 } ::= { mplsLdpEntityAtmEntry 9 } mplsLdpEntityAtmStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLdpEntityAtmEntry 10 } mplsLdpEntityAtmRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time, however, as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object, if a session has been initiated with a Peer, changing objects in this table will wreak havoc with the session and interrupt traffic. To repeat again: the recommended procedure is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. Then, change objects in this entry, then set the mplsLdpEntityAdminStatus to enable which enables a new session to be initiated." ::= { mplsLdpEntityAtmEntry 11 } -- Cucchiara, et al. Standards Track [Page 68] RFC 3815 MPLS LDP MIB June 2004 -- The MPLS LDP Entity ATM Label Range Table -- mplsLdpEntityAtmLRTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityAtmLREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MPLS LDP Entity ATM Label Range (LR) Table. The purpose of this table is to provide a mechanism for configuring a contiguous range of vpi's with a contiguous range of vci's, or a 'label range' for LDP Entities. LDP Entities which use ATM must have at least one entry in this table. There must exist at least one entry in this table for every LDP Entity that has 'mplsLdpEntityOptionalParameters' object with a value of 'atmSessionParameters'." ::= { mplsLdpEntityAtmObjects 2 } mplsLdpEntityAtmLREntry OBJECT-TYPE SYNTAX MplsLdpEntityAtmLREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the LDP Entity ATM Label Range Table. One entry in this table contains information on a single range of labels represented by the configured Upper and Lower Bounds VPI/VCI pairs. These are the same data used in the Initialization Message. NOTE: The ranges for a specific LDP Entity are UNIQUE and non-overlapping. For example, for a specific LDP Entity index, there could be one entry having LowerBound vpi/vci == 0/32, and UpperBound vpi/vci == 0/100, and a second entry for this same interface with LowerBound vpi/vci == 0/101 and UpperBound vpi/vci == 0/200. However, there could not be a third entry with LowerBound vpi/vci == 0/200 and UpperBound vpi/vci == 0/300 because this label range overlaps with the second entry (i.e., both entries now have 0/200). Cucchiara, et al. Standards Track [Page 69] RFC 3815 MPLS LDP MIB June 2004 A row will not become active unless a unique and non-overlapping range is specified. At least one label range entry for a specific LDP Entity MUST include the default VPI/VCI values denoted in the LDP Entity Table. A request to create a row with an overlapping range should result in an inconsistentValue error." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpEntityAtmLRMinVpi, mplsLdpEntityAtmLRMinVci } ::= { mplsLdpEntityAtmLRTable 1 } MplsLdpEntityAtmLREntry ::= SEQUENCE { mplsLdpEntityAtmLRMinVpi AtmVpIdentifier, mplsLdpEntityAtmLRMinVci MplsAtmVcIdentifier, mplsLdpEntityAtmLRMaxVpi AtmVpIdentifier, mplsLdpEntityAtmLRMaxVci MplsAtmVcIdentifier, mplsLdpEntityAtmLRStorageType StorageType, mplsLdpEntityAtmLRRowStatus RowStatus } mplsLdpEntityAtmLRMinVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum VPI number configured for this range. The value of zero is a valid value for the VPI portion of the label." ::= { mplsLdpEntityAtmLREntry 1 } mplsLdpEntityAtmLRMinVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum VCI number configured for this range." ::= { mplsLdpEntityAtmLREntry 2 } mplsLdpEntityAtmLRMaxVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create Cucchiara, et al. Standards Track [Page 70] RFC 3815 MPLS LDP MIB June 2004 STATUS current DESCRIPTION "The maximum VPI number configured for this range." ::= { mplsLdpEntityAtmLREntry 3 } mplsLdpEntityAtmLRMaxVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum VCI number configured for this range." ::= { mplsLdpEntityAtmLREntry 4 } mplsLdpEntityAtmLRStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLdpEntityAtmLREntry 5 } mplsLdpEntityAtmLRRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time, however, as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object, if a session has been initiated with a Peer, changing objects in this table will wreak havoc with the session and interrupt traffic. To repeat again: the recommended procedure is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. Then, change objects in this entry, then set the mplsLdpEntityAdminStatus to enable which enables a new session to be initiated." ::= { mplsLdpEntityAtmLREntry 6 } Cucchiara, et al. Standards Track [Page 71] RFC 3815 MPLS LDP MIB June 2004 -- -- MPLS LDP ATM Session Information -- mplsLdpAtmSessionObjects OBJECT IDENTIFIER ::= { mplsLdpAtmObjects 2 } mplsLdpAtmSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpAtmSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table which relates sessions in the 'mplsLdpSessionTable' and their label range intersections. There could be one or more label range intersections between an LDP Entity and LDP Peer using ATM as the underlying media. Each row represents a single label range intersection. This table cannot use the 'AUGMENTS' clause because there is not necessarily a one-to-one mapping between this table and the mplsLdpSessionTable." ::= { mplsLdpAtmSessionObjects 1 } mplsLdpAtmSessionEntry OBJECT-TYPE SYNTAX MplsLdpAtmSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single label range intersection between an LDP Entity and LDP Peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpSessionAtmLRLowerBoundVpi, mplsLdpSessionAtmLRLowerBoundVci } ::= { mplsLdpAtmSessionTable 1 } MplsLdpAtmSessionEntry ::= SEQUENCE { mplsLdpSessionAtmLRLowerBoundVpi AtmVpIdentifier, mplsLdpSessionAtmLRLowerBoundVci MplsAtmVcIdentifier, mplsLdpSessionAtmLRUpperBoundVpi AtmVpIdentifier, Cucchiara, et al. Standards Track [Page 72] RFC 3815 MPLS LDP MIB June 2004 mplsLdpSessionAtmLRUpperBoundVci MplsAtmVcIdentifier } mplsLdpSessionAtmLRLowerBoundVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum VPI number for this range." ::= { mplsLdpAtmSessionEntry 1 } mplsLdpSessionAtmLRLowerBoundVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum VCI number for this range." ::= { mplsLdpAtmSessionEntry 2 } mplsLdpSessionAtmLRUpperBoundVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum VPI number for this range." ::= { mplsLdpAtmSessionEntry 3 } mplsLdpSessionAtmLRUpperBoundVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum VCI number for this range." ::= { mplsLdpAtmSessionEntry 4 } --************************************************************** -- Module Conformance Statement --************************************************************** mplsLdpAtmGroups OBJECT IDENTIFIER ::= { mplsLdpAtmConformance 1 } mplsLdpAtmCompliances OBJECT IDENTIFIER ::= { mplsLdpAtmConformance 2 } -- -- Full Compliance -- Cucchiara, et al. Standards Track [Page 73] RFC 3815 MPLS LDP MIB June 2004 mplsLdpAtmModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-create and read-write. In other words, both monitoring and configuration are available when using this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { mplsLdpAtmGroup } OBJECT mplsLdpEntityAtmRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT mplsLdpEntityAtmLRRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." ::= { mplsLdpAtmCompliances 1 } -- -- Read-Only Compliance -- mplsLdpAtmModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-only. In other words, only monitoring is available by implementing this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { mplsLdpAtmGroup } OBJECT mplsLdpEntityAtmIfIndexOrZero MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmMergeCap Cucchiara, et al. Standards Track [Page 74] RFC 3815 MPLS LDP MIB June 2004 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmVcDirectionality MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmLsrConnectivity MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmDefaultControlVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmDefaultControlVci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmUnlabTrafVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmUnlabTrafVci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT mplsLdpEntityAtmLRMaxVpi MIN-ACCESS read-only Cucchiara, et al. Standards Track [Page 75] RFC 3815 MPLS LDP MIB June 2004 DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmLRMaxVci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmLRStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityAtmLRRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." ::= { mplsLdpAtmCompliances 2 } -- -- units of conformance -- mplsLdpAtmGroup OBJECT-GROUP OBJECTS { mplsLdpEntityAtmIfIndexOrZero, mplsLdpEntityAtmMergeCap, mplsLdpEntityAtmLRComponents, mplsLdpEntityAtmVcDirectionality, mplsLdpEntityAtmLsrConnectivity, mplsLdpEntityAtmDefaultControlVpi, mplsLdpEntityAtmDefaultControlVci, mplsLdpEntityAtmUnlabTrafVpi, mplsLdpEntityAtmUnlabTrafVci, mplsLdpEntityAtmStorageType, mplsLdpEntityAtmRowStatus, mplsLdpEntityAtmLRMaxVpi, mplsLdpEntityAtmLRMaxVci, mplsLdpEntityAtmLRStorageType, mplsLdpEntityAtmLRRowStatus, mplsLdpSessionAtmLRUpperBoundVpi, mplsLdpSessionAtmLRUpperBoundVci } STATUS current Cucchiara, et al. Standards Track [Page 76] RFC 3815 MPLS LDP MIB June 2004 DESCRIPTION "Objects that apply to all MPLS LDP implementations using ATM as the Layer 2." ::= { mplsLdpAtmGroups 1 } END 4.2. The MPLS-LDP-FRAME-RELAY-STD-MIB Module This MIB Module MUST be supported if LDP uses FRAME RELAY as the Layer 2 medium. There are three tables in this MIB Module. Two tables are to configure LDP for using Frame Relay. These tables are the mplsLdpEntityFrameRelayTable and the mplsLdpEntityFrameRelayLRTable. The third table, mplsLdpFrameRelaySessionTable, is a read-only table. This MIB Module IMPORTS the DLCI TEXTUAL-CONVENTION from [RFC2115]. 4.2.1. The LDP Entity Frame Relay Table The mplsLdpEntityFrameRelayTable provides a way to configure information which would be contained in the "Optional Parameter" portion of an LDP PDU Initialization Message. 4.2.2. The LDP Entity Frame Relay Label Range Table The mplsLdpEntityFrameRelayLRTable provides a way to configure information which would be contained in the "Frame Relay Label Range Components" portion of an LDP PDU Intialization Message, see [RFC3034] and [RFC3036]. 4.2.3. The LDP Frame Relay Session Table The mplsLdpFrameRelaySessionTable is a table which contains session information specific to Frame Relay. MPLS-LDP-FRAME-RELAY-STD-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, StorageType Cucchiara, et al. Standards Track [Page 77] RFC 3815 MPLS LDP MIB June 2004 FROM SNMPv2-TC -- [RFC2579] DLCI FROM FRAME-RELAY-DTE-MIB -- [RFC2115] InterfaceIndexOrZero FROM IF-MIB -- [RFC2020] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId FROM MPLS-LDP-STD-MIB -- [RFC3813] ; mplsLdpFrameRelayStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "Multiprotocol Label Switching (mpls) Working Group" CONTACT-INFO "Joan Cucchiara (jcucchiara@mindspring.com) Marconi Communications, Inc. Hans Sjostrand (hans@ipunplugged.com) ipUnplugged James V. Luciani (james_luciani@mindspring.com) Marconi Communications, Inc. Working Group Chairs: George Swallow, email: swallow@cisco.com Loa Andersson, email: loa@pi.se MPLS Working Group, email: mpls@uu.net " DESCRIPTION "Copyright (C) The Internet Society (year). The initial version of this MIB module was published in RFC 3815. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB contains managed object definitions for configuring and monitoring the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP), utilizing Frame Relay as the Layer 2 media." Cucchiara, et al. Standards Track [Page 78] RFC 3815 MPLS LDP MIB June 2004 REVISION "200406030000Z" -- June 6, 2004 DESCRIPTION "Initial version published as part of RFC 3815." ::= { mplsStdMIB 6 } --**************************************************************** mplsLdpFrameRelayObjects OBJECT IDENTIFIER ::= { mplsLdpFrameRelayStdMIB 1 } mplsLdpFrameRelayConformance OBJECT IDENTIFIER ::= { mplsLdpFrameRelayStdMIB 2 } --**************************************************************** -- MPLS LDP Frame Relay Objects --**************************************************************** -- -- Ldp Entity Objects for Frame Relay -- mplsLdpEntityFrameRelayObjects OBJECT IDENTIFIER ::= { mplsLdpFrameRelayObjects 1 } mplsLdpEntityFrameRelayTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityFrameRelayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains Frame Relay specific information which could be used in the 'Optional Parameters' and other Frame Relay specific information. This table 'sparse augments' the mplsLdpEntityTable when Frame Relay is the Layer 2 medium." ::= { mplsLdpEntityFrameRelayObjects 1 } mplsLdpEntityFrameRelayEntry OBJECT-TYPE SYNTAX MplsLdpEntityFrameRelayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents the Frame Relay optional parameters associated with the LDP entity." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex Cucchiara, et al. Standards Track [Page 79] RFC 3815 MPLS LDP MIB June 2004 } ::= { mplsLdpEntityFrameRelayTable 1 } MplsLdpEntityFrameRelayEntry ::= SEQUENCE { mplsLdpEntityFrameRelayIfIndexOrZero InterfaceIndexOrZero, mplsLdpEntityFrameRelayMergeCap INTEGER, mplsLdpEntityFrameRelayLRComponents Unsigned32, mplsLdpEntityFrameRelayVcDirectionality INTEGER, mplsLdpEntityFrameRelayStorageType StorageType, mplsLdpEntityFrameRelayRowStatus RowStatus } mplsLdpEntityFrameRelayIfIndexOrZero OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This value represents either the InterfaceIndex of the 'ifLayer' where the Frame Relay Labels 'owned' by this entry were created, or 0 (zero). The value of zero means that the InterfaceIndex is not known. For example, if the InterfaceIndex is created subsequent to the Frame Relay Label's creation, then it would not be known. However, if the InterfaceIndex is known, then it must be represented by this value. If an InterfaceIndex becomes known, then the network management entity (e.g., SNMP agent) responsible for this object MUST change the value from 0 (zero) to the value of the InterfaceIndex. If an Frame Relay Label is being used in forwarding data, then the value of this object MUST be the InterfaceIndex." ::= { mplsLdpEntityFrameRelayEntry 1 } mplsLdpEntityFrameRelayMergeCap OBJECT-TYPE SYNTAX INTEGER { notSupported(0), supported(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "This represents whether or not the Frame Relay merge capability is supported. This is the EXACT value for the Frame Relay Session Parameter, field M (for Frame Relay Merge Capabilities). The Frame Relay Session Parameter is an optional parameter in the Initialization Message. Cucchiara, et al. Standards Track [Page 80] RFC 3815 MPLS LDP MIB June 2004 The description from rfc3036.txt is: 'M, Frame Relay Merge Capabilities Specifies the merge capabilities of a Frame Relay switch. The following values are supported in this version of the specification: Value Meaning 0 Merge not supported 1 Merge supported Non-merge and merge Frame Relay LSRs may freely interoperate.' Please refer to the following reference for a complete description of this feature." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Initialization Message." ::= { mplsLdpEntityFrameRelayEntry 2 } mplsLdpEntityFrameRelayLRComponents OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Label Range Components in the Initialization message. This also represents the number of entries in the mplsLdpEntityFrameRelayLRTable which correspond to this entry. This is the EXACT value for the Frame Relay Session Parameter, field N (for Number of label range components). The Frame Relay Session Parameter is an optional parameter in the Initialization Message. The description from rfc3036.txt is: 'N, Number of label range components Specifies the number of Frame Relay Label Range Components included in the TLV.' Please refer to the following reference for a complete description of this feature." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Cucchiara, et al. Standards Track [Page 81] RFC 3815 MPLS LDP MIB June 2004 Initialization Message." ::= { mplsLdpEntityFrameRelayEntry 3 } mplsLdpEntityFrameRelayVcDirectionality OBJECT-TYPE SYNTAX INTEGER { bidirectional(0), unidirection(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is 'bidirectional(0)', then the LSR supports the use of a given DLCI as a label for both directions independently. If the value of this object is 'unidirectional(1)', then the LSR uses the given DLCI as a label in only one direction. This is the EXACT value for the Frame Relay Session Parameter, field D (for VC Directionality). The Frame Relay Session Parameter is an optional parameter in the Initialization Message. The description from rfc3036.txt is: 'D, VC Directionality A value of 0 specifies bidirectional VC capability, meaning the LSR can support the use of a given DLCI as a label for both link directions independently. A value of 1 specifies unidirectional VC capability, meaning a given DLCI may appear in a label mapping for one direction on the link only. When either or both of the peers specifies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP Identifier may assign only odd-numbered DLCIs in the range as labels. The system with the smaller LDP Identifier may assign only even-numbered DLCIs in the range as labels.' Please refer to the following reference for a complete description of this feature." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Initialization Message." ::= { mplsLdpEntityFrameRelayEntry 4 } Cucchiara, et al. Standards Track [Page 82] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityFrameRelayStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLdpEntityFrameRelayEntry 5 } mplsLdpEntityFrameRelayRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time, however, as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object, if a session has been initiated with a Peer, changing objects in this table will wreak havoc with the session and interrupt traffic. To repeat again: the recommended procedure is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. Then, change objects in this entry, then set the mplsLdpEntityAdminStatus to enable which enables a new session to be initiated." ::= { mplsLdpEntityFrameRelayEntry 6 } -- -- Frame Relay Label Range Components -- mplsLdpEntityFrameRelayLRTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityFrameRelayLREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about the Cucchiara, et al. Standards Track [Page 83] RFC 3815 MPLS LDP MIB June 2004 Optional Parameters for the Frame Relay Session in the LDP Initialization Message, specifically it contains information about the Frame Relay Label Range Components. If the value of the object 'mplsLdpEntityOptionalParameters' contains the value of 'frameRelaySessionParameters(3)' then there must be at least one corresponding entry in this table." ::= { mplsLdpEntityFrameRelayObjects 2 } mplsLdpEntityFrameRelayLREntry OBJECT-TYPE SYNTAX MplsLdpEntityFrameRelayLREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents the Frame Relay Label Range Component associated with the LDP entity." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpEntityFrameRelayLRMinDlci } ::= { mplsLdpEntityFrameRelayLRTable 1 } MplsLdpEntityFrameRelayLREntry ::= SEQUENCE { mplsLdpEntityFrameRelayLRMinDlci DLCI, mplsLdpEntityFrameRelayLRMaxDlci DLCI, mplsLdpEntityFrameRelayLRLen INTEGER, mplsLdpEntityFrameRelayLRStorageType StorageType, mplsLdpEntityFrameRelayLRRowStatus RowStatus } mplsLdpEntityFrameRelayLRMinDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS not-accessible STATUS current DESCRIPTION "The lower bound which is supported. This value should be the same as that in the Frame Relay Label Range Component's Minimum DLCI field. The value of zero is valid for the minimum DLCI field of the label." REFERENCE "RFC3034, Use of Label Switching on Frame Relay Networks Specification." ::= { mplsLdpEntityFrameRelayLREntry 1 } Cucchiara, et al. Standards Track [Page 84] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityFrameRelayLRMaxDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-create STATUS current DESCRIPTION "The upper bound which is supported. This value should be the same as that in the Frame Relay Label Range Component's Maximum DLCI field." ::= { mplsLdpEntityFrameRelayLREntry 2 } mplsLdpEntityFrameRelayLRLen OBJECT-TYPE SYNTAX INTEGER { tenDlciBits(0), twentyThreeDlciBits(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the length of the DLCI bits. This is the EXACT value for the Len field of the Frame Relay Label Range Component. The description from rfc3036.txt is: 'Len This field specifies the number of bits of the DLCI. The following values are supported: Len DLCI bits 0 10 2 23 Len values 1 and 3 are reserved.' Please refer to the following reference for a complete description of this feature." REFERENCE "RFC3036, LDP Specification, Section 3.5.3 Initialization Message." ::= { mplsLdpEntityFrameRelayLREntry 3 } mplsLdpEntityFrameRelayLRStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION Cucchiara, et al. Standards Track [Page 85] RFC 3815 MPLS LDP MIB June 2004 "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLdpEntityFrameRelayLREntry 4 } mplsLdpEntityFrameRelayLRRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time, however, as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object, if a session has been initiated with a Peer, changing objects in this table will wreak havoc with the session and interrupt traffic. To repeat again: the recommended procedure is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. Then, change objects in this entry, then set the mplsLdpEntityAdminStatus to enable which enables a new session to be initiated." ::= { mplsLdpEntityFrameRelayLREntry 5 } -- -- MPLS LDP Frame Relay Session Information -- mplsLdpFrameRelaySessionObjects OBJECT IDENTIFIER ::= { mplsLdpFrameRelayObjects 2 } mplsLdpFrameRelaySessionTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpFrameRelaySessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Frame Relay label range intersections between the LDP Entities and LDP Peers. Each row represents a single label range intersection. NOTE: this table cannot use the 'AUGMENTS' Cucchiara, et al. Standards Track [Page 86] RFC 3815 MPLS LDP MIB June 2004 clause because there is not necessarily a one-to-one mapping between this table and the mplsLdpSessionTable." ::= { mplsLdpFrameRelaySessionObjects 1 } mplsLdpFrameRelaySessionEntry OBJECT-TYPE SYNTAX MplsLdpFrameRelaySessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single label range intersection between an LDP Entity and LDP Peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpFrameRelaySessionMinDlci } ::= { mplsLdpFrameRelaySessionTable 1 } MplsLdpFrameRelaySessionEntry ::= SEQUENCE { mplsLdpFrameRelaySessionMinDlci DLCI, mplsLdpFrameRelaySessionMaxDlci DLCI, mplsLdpFrameRelaySessionLen INTEGER } mplsLdpFrameRelaySessionMinDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS not-accessible STATUS current DESCRIPTION "The lower bound of DLCIs which are supported. The value of zero is a valid value for the minimum DLCI field of the label." REFERENCE "RFC3034, Use of Label Switching on Frame Relay Networks Specification." ::= { mplsLdpFrameRelaySessionEntry 1 } mplsLdpFrameRelaySessionMaxDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-only STATUS current DESCRIPTION "The upper bound of DLCIs which are supported." ::= { mplsLdpFrameRelaySessionEntry 2 } Cucchiara, et al. Standards Track [Page 87] RFC 3815 MPLS LDP MIB June 2004 mplsLdpFrameRelaySessionLen OBJECT-TYPE SYNTAX INTEGER { tenDlciBits(0), twentyThreeDlciBits(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the DLCI bits." ::= { mplsLdpFrameRelaySessionEntry 3 } --**************************************************************** -- Module Conformance Statement --**************************************************************** mplsLdpFrameRelayGroups OBJECT IDENTIFIER ::= { mplsLdpFrameRelayConformance 1 } mplsLdpFrameRelayCompliances OBJECT IDENTIFIER ::= { mplsLdpFrameRelayConformance 2 } -- -- Full Compliance -- mplsLdpFrameRelayModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-create and read-write. In other words, both monitoring and configuration are available when using this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { mplsLdpFrameRelayGroup } OBJECT mplsLdpEntityFrameRelayRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT mplsLdpEntityFrameRelayLRRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." Cucchiara, et al. Standards Track [Page 88] RFC 3815 MPLS LDP MIB June 2004 ::= { mplsLdpFrameRelayCompliances 1 } -- -- Read-Only Compliance -- mplsLdpFrameRelayModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-only. In other words, only monitoring is available by implementing this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { mplsLdpFrameRelayGroup } OBJECT mplsLdpEntityFrameRelayIfIndexOrZero MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityFrameRelayMergeCap MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityFrameRelayVcDirectionality MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityFrameRelayStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityFrameRelayRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT mplsLdpEntityFrameRelayLRMaxDlci MIN-ACCESS read-only DESCRIPTION "Write access is not required." Cucchiara, et al. Standards Track [Page 89] RFC 3815 MPLS LDP MIB June 2004 OBJECT mplsLdpEntityFrameRelayLRLen MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityFrameRelayLRStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityFrameRelayLRRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." ::= { mplsLdpFrameRelayCompliances 2 } -- -- units of conformance -- mplsLdpFrameRelayGroup OBJECT-GROUP OBJECTS { mplsLdpEntityFrameRelayIfIndexOrZero, mplsLdpEntityFrameRelayMergeCap, mplsLdpEntityFrameRelayLRComponents, mplsLdpEntityFrameRelayVcDirectionality, mplsLdpEntityFrameRelayStorageType, mplsLdpEntityFrameRelayRowStatus, mplsLdpEntityFrameRelayLRMaxDlci, mplsLdpEntityFrameRelayLRLen, mplsLdpEntityFrameRelayLRStorageType, mplsLdpEntityFrameRelayLRRowStatus, mplsLdpFrameRelaySessionMaxDlci, mplsLdpFrameRelaySessionLen } STATUS current DESCRIPTION "Objects that apply to all MPLS LDP implementations using Frame Relay as the Layer 2." ::= { mplsLdpFrameRelayGroups 1 } END Cucchiara, et al. Standards Track [Page 90] RFC 3815 MPLS LDP MIB June 2004 4.3. The MPLS-LDP-GENERIC-STD-MIB Module This MIB Module MUST be supported if LDP uses a Per Platform Label Space. This MIB Module contains a Label Range (LR) table for configuring MPLS Generic Label Ranges. This table is mplsLdpEntityGenericLRTable. Although the LDP Specification does not provide a way for configuring Label Ranges for Generic Labels, the MIB does provide a way to reserve a range of generic labels because this was thought to be useful by the working group. MPLS-LDP-GENERIC-STD-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero FROM IF-MIB -- [RFC2020] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] mplsLdpEntityLdpId, mplsLdpEntityIndex FROM MPLS-LDP-STD-MIB -- [RFC3813] ; mplsLdpGenericStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 6, 2004 ORGANIZATION "Multiprotocol Label Switching (mpls) Working Group" CONTACT-INFO "Joan Cucchiara (jcucchiara@mindspring.com) Marconi Communications, Inc. Hans Sjostrand (hans@ipunplugged.com) ipUnplugged Cucchiara, et al. Standards Track [Page 91] RFC 3815 MPLS LDP MIB June 2004 James V. Luciani (james_luciani@mindspring.com) Marconi Communications, Inc. Working Group Chairs: George Swallow, email: swallow@cisco.com Loa Andersson, email: loa@pi.se MPLS Working Group, email: mpls@uu.net " DESCRIPTION "Copyright (C) The Internet Society (year). The initial version of this MIB module was published in RFC 3815. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB contains managed object definitions for configuring and monitoring the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP), utilizing ethernet as the Layer 2 media." REVISION "200406030000Z" -- June 6, 2004 DESCRIPTION "Initial version published as part of RFC 3815." ::= { mplsStdMIB 7 } --**************************************************************** mplsLdpGenericObjects OBJECT IDENTIFIER ::= { mplsLdpGenericStdMIB 1 } mplsLdpGenericConformance OBJECT IDENTIFIER ::= { mplsLdpGenericStdMIB 2 } --**************************************************************** -- MPLS LDP GENERIC Objects --**************************************************************** -- -- Ldp Entity Objects for Generic Labels -- mplsLdpEntityGenericObjects OBJECT IDENTIFIER ::= { mplsLdpGenericObjects 1 } -- -- The MPLS LDP Entity Generic Label Range Table -- Cucchiara, et al. Standards Track [Page 92] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityGenericLRTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpEntityGenericLREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MPLS LDP Entity Generic Label Range (LR) Table. The purpose of this table is to provide a mechanism for configurating a contiguous range of generic labels, or a 'label range' for LDP Entities. LDP Entities which use Generic Labels must have at least one entry in this table. In other words, this table 'extends' the mpldLdpEntityTable for Generic Labels." ::= { mplsLdpEntityGenericObjects 1 } mplsLdpEntityGenericLREntry OBJECT-TYPE SYNTAX MplsLdpEntityGenericLREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the LDP Entity Generic Label Range (LR) Table. One entry in this table contains information on a single range of labels represented by the configured Upper and Lower Bounds pairs. NOTE: there is NO corresponding LDP message which relates to the information in this table, however, this table does provide a way for a user to 'reserve' a generic label range. NOTE: The ranges for a specific LDP Entity are UNIQUE and non-overlapping. A row will not be created unless a unique and non-overlapping range is specified." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpEntityGenericLRMin, mplsLdpEntityGenericLRMax } ::= { mplsLdpEntityGenericLRTable 1 } MplsLdpEntityGenericLREntry ::= SEQUENCE { mplsLdpEntityGenericLRMin Unsigned32, mplsLdpEntityGenericLRMax Unsigned32, mplsLdpEntityGenericLabelSpace INTEGER, Cucchiara, et al. Standards Track [Page 93] RFC 3815 MPLS LDP MIB June 2004 mplsLdpEntityGenericIfIndexOrZero InterfaceIndexOrZero, mplsLdpEntityGenericLRStorageType StorageType, mplsLdpEntityGenericLRRowStatus RowStatus } mplsLdpEntityGenericLRMin OBJECT-TYPE SYNTAX Unsigned32(0..1048575) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum label configured for this range." ::= { mplsLdpEntityGenericLREntry 1 } mplsLdpEntityGenericLRMax OBJECT-TYPE SYNTAX Unsigned32(0..1048575) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The maximum label configured for this range." ::= { mplsLdpEntityGenericLREntry 2 } mplsLdpEntityGenericLabelSpace OBJECT-TYPE SYNTAX INTEGER { perPlatform(1), perInterface(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This value of this object is perPlatform(1), then this means that the label space type is per platform. If this object is perInterface(2), then this means that the label space type is per Interface." REFERENCE "RFC3036, LDP Specification, Section 2.2.1, Label Spaces." DEFVAL { perPlatform } ::= { mplsLdpEntityGenericLREntry 3 } mplsLdpEntityGenericIfIndexOrZero OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This value represents either the InterfaceIndex of the 'ifLayer' where these Generic Label would be created, Cucchiara, et al. Standards Track [Page 94] RFC 3815 MPLS LDP MIB June 2004 or 0 (zero). The value of zero means that the InterfaceIndex is not known. However, if the InterfaceIndex is known, then it must be represented by this value. If an InterfaceIndex becomes known, then the network management entity (e.g., SNMP agent) responsible for this object MUST change the value from 0 (zero) to the value of the InterfaceIndex." ::= { mplsLdpEntityGenericLREntry 4 } mplsLdpEntityGenericLRStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLdpEntityGenericLREntry 5 } mplsLdpEntityGenericLRRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time, however, as described in detail in the section entitled, 'Changing Values After Session Establishment', and again described in the DESCRIPTION clause of the mplsLdpEntityAdminStatus object, if a session has been initiated with a Peer, changing objects in this table will wreak havoc with the session and interrupt traffic. To repeat again: the recommended procedure is to set the mplsLdpEntityAdminStatus to down, thereby explicitly causing a session to be torn down. Then, change objects in this entry, then set the mplsLdpEntityAdminStatus to enable which enables a new session to be initiated. There must exist at least one entry in this table for every LDP Entity that has a generic label configured." Cucchiara, et al. Standards Track [Page 95] RFC 3815 MPLS LDP MIB June 2004 ::= { mplsLdpEntityGenericLREntry 6 } --**************************************************************** -- Module Conformance Statement --**************************************************************** mplsLdpGenericGroups OBJECT IDENTIFIER ::= { mplsLdpGenericConformance 1 } mplsLdpGenericCompliances OBJECT IDENTIFIER ::= { mplsLdpGenericConformance 2 } -- -- Full Compliance -- mplsLdpGenericModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-create and read-write. In other words, both monitoring and configuration are available when using this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { mplsLdpGenericGroup } OBJECT mplsLdpEntityGenericLRRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." ::= { mplsLdpGenericCompliances 1 } -- -- Read-Only Compliance -- mplsLdpGenericModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The Module is implemented with support for read-only. In other words, only monitoring is available by implementing this MODULE-COMPLIANCE." MODULE -- this module MANDATORY-GROUPS { Cucchiara, et al. Standards Track [Page 96] RFC 3815 MPLS LDP MIB June 2004 mplsLdpGenericGroup } OBJECT mplsLdpEntityGenericLabelSpace MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityGenericIfIndexOrZero MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityGenericLRStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLdpEntityGenericLRRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." ::= { mplsLdpGenericCompliances 2 } -- -- units of conformance -- mplsLdpGenericGroup OBJECT-GROUP OBJECTS { mplsLdpEntityGenericLabelSpace, mplsLdpEntityGenericIfIndexOrZero, mplsLdpEntityGenericLRStorageType, mplsLdpEntityGenericLRRowStatus } STATUS current DESCRIPTION "Objects that apply to all MPLS LDP implementations using Generic Labels as the Layer 2." ::= { mplsLdpGenericGroups 1 } END Cucchiara, et al. Standards Track [Page 97] RFC 3815 MPLS LDP MIB June 2004 5. Acknowledgments This document is a product of the MPLS Working Group. The authors would like to thank Mike MacFadden and Adrian Farrel for their helpful comments on several reviews. Also, the authors would like to give a special acknowledgement to Bert Wijnen for his many detailed reviews. Bert's assistance and guidance is greatly appreciated. We would also like to thank Cheenu Srinivasan, Arun Viswanathan and Thomas D. Nadeau, the authors of the MPLS-LSR-STD-MIB [RFC3813], for their assistance. Additionally, there have been other members of the working group that have been very helpful: Alan Kullberg from NetPlane Systems gave input on earlier versions of this document, and more recently, Riza Cetin of Alcatel and Neil Jerram of Data Connection who both provided MIB objects. Early versions of this document were also reviewed by colleagues at Nortel Networks and Ericsson. The authors would like to thank the following people: Leigh McLellan, Geetha Brown, Geping Chen and Charlan Zhou from Nortel Networks, and Zoltan Takacs and Bo Augustsson from Ericsson. 6. References 6.1. Normative References [RFC2115] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP: 26, RFC 2434, October 1998. [RFC2514] Noto, M., Spiegel, E., and K. Tesink, editors, "Definition of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Cucchiara, et al. Standards Track [Page 98] RFC 3815 MPLS LDP MIB June 2004 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001. [RFC3215] Boscher, C., Cheval, P., Wu, L., and E. Gray, "LDP State Machine", RFC 3215, January 2002. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Coventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3413] Levi, D., Meyers, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. Cucchiara, et al. Standards Track [Page 99] RFC 3815 MPLS LDP MIB June 2004 [RFC3811] Nadeau, T. and J. Cucchiara, Editors "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3813] Srinivansan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004 6.2. Informative References [MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", Work in Progress, September 2003. [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 7. Security Considerations This Security Considerations section consists of 4 subsections, one for each of the MIB Modules in this document. 7.1. Security Considerations for MPLS-LDP-STD-MIB There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityTable contains objects to provision potential LDP sessions on the Label Switching Router (LSR) or Label Edge Router (LER). The mplsLdpLspFecTable contains objects which associate an LSP with a FEC. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LDP session has been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB. Administrators should consider whether Cucchiara, et al. Standards Track [Page 100] RFC 3815 MPLS LDP MIB June 2004 read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module i.e., (objects with a MAX-ACCESS other than not-accessible), may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityTable, mplsLdpPeerTable, mplsLdpSessionTable and mplsLdpSessionStatsTable collectively show the LDP LSP network topology. If an Administrator does not want to reveal the LDP LSP topology of the network, then these tables should be considered sensitive/vulnerable. 7.2. Security Considerations for MPLS-LDP-ATM-STD-MIB There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityAtmTable and mplsLdpEntityAtmLRTable contain objects to provision potential LDP sessions on the Label Switching Router (LSR) or Label Edge Router (LER) over Layer 2 of ATM. These tables extend the mplsLdpEntityTable in the MPLS- LDP-MIB. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LDP session has been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module i.e., (objects with a MAX-ACCESS other than not-accessible), may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Cucchiara, et al. Standards Track [Page 101] RFC 3815 MPLS LDP MIB June 2004 o the mplsLdpEntityAtmTable and mplsLdpEntityAtmLRTable show the Label Ranges for ATM. If an Administrator does not want to reveal this information then these tables should be considered sensitive/vulnerable and treated accordingly. 7.3. Security Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityFrameRelayTable and mplsLdpEntityFrameRelayLRTable contain objects to provision potential LDP sessions on the Label Switching Router (LSR) or Label Edge Router (LER) over Layer 2 of Frame Relay. These tables extend the mplsLdpEntityTable in the MPLS-LDP-MIB. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LDP session has been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module i.e., (objects with a MAX-ACCESS other than not-accessible), may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityFrameRelayTable and mplsLdpEntityFrameRelayLRTable show the Label Ranges for Frame Relay. If an Administrator does not want to reveal this information then these tables should be considered sensitive/vulnerable and treated accordingly. Cucchiara, et al. Standards Track [Page 102] RFC 3815 MPLS LDP MIB June 2004 7.4. Security Considerations for MPLS-LDP-GENERIC-STD-MIB There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityGenericLRTable contains objects to provision potential LDP sessions on the Label Switching Router (LSR) or Label Edge Router (LER) over Layer 2 of Ethernet. This table extends the mplsLdpEntityTable in the MPLS-LDP-MIB. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LDP session has been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module i.e., (objects with a MAX-ACCESS other than not-accessible), may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityGenericLRTable shows the Label Ranges for ethernet. If an Administrator does not want to reveal this information then these tables should be considered sensitive/vulnerable and treated accordingly. 7.5. Additional Security Considerations The following paragraphs describe additional security considerations which are applicable to all 4 of the MIB Modules in this document. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Cucchiara, et al. Standards Track [Page 103] RFC 3815 MPLS LDP MIB June 2004 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB [MPLSTCMIB], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There are 4 MPLS MIB Modules contained in this document, each of the following "IANA Considerations" subsections lists new IANA assignments under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. 8.1. IANA Considerations for MPLS-LDP-STD-MIB The IANA has assigned { mplsStdMIB 4 } to the MPLS-LDP-STD-MIB module specified in this document. 8.2. IANA Considerations for MPLS-LDP-ATM-STD-MIB The IANA has assigned { mplsStdMIB 5 } to the MPLS-LDP-ATM-STD-MIB module specified in this document. 8.3. IANA Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB The IANA has assigned { mplsStdMIB 6 } to the MPLS-LDP-FRAME-RELAY- STD-MIB module specified in this document. 8.4. IANA Considerations for MPLS-LDP-GENERIC-STD-MIB The IANA has assigned { mplsStdMIB 7 } to the MPLS-LDP-GENERIC-STD- MIB module specified in this document. Cucchiara, et al. Standards Track [Page 104] RFC 3815 MPLS LDP MIB June 2004 9. Authors' Addresses James V. Luciani Marconi Communications, Inc. 900 Chelmsford Street Lowell, MA 01851 EMail: james_luciani@mindspring.com Hans Sjostrand ipUnplugged P.O. Box 101 60 S-121 28 Stockholm, Sweden Phone: +46 8 725 5900 EMail: hans@ipunplugged.com Joan E. Cucchiara Marconi Communications, Inc. 900 Chelmsford Street Lowell, MA 01851 Phone: +1 978 275 7400 EMail: jcucchiara@mindspring.com Cucchiara, et al. Standards Track [Page 105] RFC 3815 MPLS LDP MIB June 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Cucchiara, et al. Standards Track [Page 106] snmp-mibs-downloader-1.1/mibrfcs/rfc3816.txt0000644000000000000000000031476311402176071015601 0ustar Network Working Group J. Quittek Request for Comments: 3816 M. Stiemerling Category: Standards Track NEC H. Hartenstein University of Karlsruhe June 2004 Definitions of Managed Objects for RObust Header Compression (ROHC) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. Quittek, et al. Standards Track [Page 1] RFC 3816 ROHC MIB June 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Structure of the MIB modules . . . . . . . . . . . . . . . . . 3 4.1. The ROHC-MIB module . . . . . . . . . . . . . . . . . . . 4 4.1.1. rohcChannelTable . . . . . . . . . . . . . . . . . 5 4.1.2. rohcInstanceTable. . . . . . . . . . . . . . . . . 5 4.1.3. rohcProfileTable . . . . . . . . . . . . . . . . . 6 4.1.4. rohcContextTable . . . . . . . . . . . . . . . . . 7 4.2. The ROHC-UNCOMPRESSED-MIB module. . . . . . . . . . . . . 8 4.2.1. rohcUncmprContextTable . . . . . . . . . . . . . . 8 4.3. The ROHC-RTP-MIB module . . . . . . . . . . . . . . . . . 8 4.3.1. rohcRtpContextTable. . . . . . . . . . . . . . . . 8 4.3.2. rohcPacketSizeTable. . . . . . . . . . . . . . . . 9 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 50 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1. Normative References. . . . . . . . . . . . . . . . . . . 51 8.2. Informative References. . . . . . . . . . . . . . . . . . 52 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of robust header compression. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB Quittek, et al. Standards Track [Page 2] RFC 3816 ROHC MIB June 2004 module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview This section describes the basic model of RObust Header Compression (ROHC, [RFC3095]) used when developing the MIB modules for ROHC described in the following sections. ROHC presents a framework for IP header compression that allows flexible adjustment of compression efficiency versus robustness against channel errors depending on the underlying channel characteristics. ROHC introduces header compressors/decompressors at the end-points (interfaces) of (wireless) channels on which packets with compressed headers are transferred. ROHC exploits the temporal redundancy in successive packet headers of a packet flow by storing non-changing fields of the headers as well as reference values of predictably changing fields as context information. When the context information for a packet flow is also established at the decompressor, only delta-information and unpredictably changing header fields have to be sent over the channel. This document specifies MIB modules in order to provide a means for managing ROHC implementations via SNMP and within the IETF management framework. The objects defined support configuration management, fault management and performance monitoring. For configuration management implementation parameters (see Section 6.3 of [RFC3095]) and configuration parameters (including the ones specified in Section 5.1.1 of [RFC3095] and in Section 5.1.1 of [RFC3242]) can be verified by using the MIB modules specified below. For fault management compressor/decompressor state and mode can be checked. For performance management a set of statistics is provided including the number of flows that have used ROHC, the current and long term compression ratio, the number of reinitializations and the number of packets sent or received with different header types. 4. Structure of the MIB modules This section presents the structure of the MIB modules that are specified in Section 5. Basically, the MIB is structured according to the ROHC architecture described in [RFC3759]. Quittek, et al. Standards Track [Page 3] RFC 3816 ROHC MIB June 2004 ROHC is an evolving technology. [RFC3095] specifies the header compression framework and four profiles: uncompressed, RTP, UDP, and ESP (Real-Time Transport Protocol, User Datagram Protocol, Encapsulating Security Payload). [RFC3242] specifies a profile with additional link layer assistance called LLA (Link Layer Assisted). A profile for compression of TCP (Transmission Control Protocol) flows is under development within the ROHC working group and SCTP (Stream Control Transmission Protocol) compression is being discussed as potential next candidate. Therefore, the managed objects defined below are structured into three MIB modules: the general ROHC-MIB module and the profile-specific ROHC-UNCOMPRESSED-MIB and ROHC-RTP- MIB modules. This flexible approach allows to support future profiles each by its own profile-specific module. The ROHC-MIB module defines properties of information on ROHC instances, ROHC channels, ROHC profiles, and ROHC compressor and decompressor contexts. All managed objects in this module are assumed to be shared by all profiles. The ROHC-UNCOMPRESSED-MIB module extends the ROHC-MIB by managed objects that are specific to the ROHC uncompressed profile 0x0000 defined in [RFC3095]. The ROHC-RTP-MIB module extends the ROHC-MIB by managed objects that are specific to the three profiles defined in [RFC3095] (ROHC RTP profile 0x0001, ROHC UDP profile 0x0002, and ROHC ESP profile 0x0003), and to the ROHC LLA profile 0x0005 defined in [RFC3242]. An analysis of these profiles showed that they are tightly related and can share most of the managed objects in the ROHC-UNCOMPRESSED-MIB module. Therefore, a joint module for all of them was preferred to individual modules. The number of managed objects in the ROHC-UNCOMPRESSED-MIB Module and the ROHC-RTP-MIB Module is rather small. They contain context state and context mode, and profile-specific context statistics. It is assumed that MIB modules for future profiles, such as TCP and SCTP, will be similarly small and easy to design. 4.1. The ROHC-MIB module The ROHC-MIB module defines managed objects that are expected to be useful for all current and future ROHC profiles. Objects in the ROHC-MIB module are arranged into four tables: the rohcChannelTable, the rohcInstanceTable, the rohcProfileTable, and the rohcContextTable. The managed objects in the first three tables are rather static (except for provided statistics), while the objects in the rohcContextTable are more dynamic. Quittek, et al. Standards Track [Page 4] RFC 3816 ROHC MIB June 2004 All tables are indexed by the IP interface number and by a numeric channel identifier. The channel identifier is used for channels to which compressors and decompressors are attached (called ROHC channels in [RFC3759]), as well as for dedicated feedback channels (called ROHC feedback channels in [RFC3759]). Compressor and decompressor instances are further indexed by their type (either compressor or decompressor). Contexts are indexed by the same index as their corresponding instance and their individual context identifier (CID). 4.1.1. rohcChannelTable The rohcChannelTable lists all channels used by ROHC instances for transferring compressed packets and/or for giving feedback from the decompressor to the compressor. Listed channels are either ROHC channels or feedback channels as defined in [RFC3759]. The channels are listed per IP interface. The information per channel in the rohcChannelTable includes o the channel ID, o the channel type, either 'notInUse', 'rohc', or 'dedicatedFeedback', o the channel for which feedback is provided by this channel (if applicable), o a string for describing the channel, and o the status of the channel being either 'enabled' or 'disabled'. 4.1.2. rohcInstanceTable The rohcInstanceTable defines properties of ROHC compressor instances and ROHC decompressor instances. As described in [RFC3759], an instance is associated with exactly one channel and only one instance can be associated with the same channel. Therefore, the same index consisting of ifIndex and rohcChannelID could have been used for both tables. But when accessing the rohcInstanceTable (and the rohcContextTable that shares a part of its index with the rohcInstanceTable) there are many cases where either a compressor contexts or a decompressor contexts are of interest. Therefore, the rohcInstanceType indicating either a compressor or a decompressor was added to the table's index. This allows listing all compressors without accessing any decompressor. Quittek, et al. Standards Track [Page 5] RFC 3816 ROHC MIB June 2004 Note that still the combination of ifIndex and rohcChannelID uniquely identifies an instance. It is always possible to directly identify and access the channel corresponding to a given instance. The set of instance properties in the rochInstanceTable includes o the vendor of the implementation, version number and description, o the channels used for compressed packets and for feedback, o implementation and configuration properties including clock resolution, maximum context identifier number (MAX_CID), the LARGE_CIDS flag, and the Maximum Reconstructed Reception Unit (MRRU), o the storage time for contexts created by this instance, o the status of the instance (operational or not). Optionally, the rohcInstanceTable also contains instance statistics including o the total number of compressed flows, o the current number of compressed flows, o the total number of packets passing this instance o the total number of static Initialization and Refreshes (IRs) passing this instance o the total number of dynamic Initialization and Refreshes (IR-DYNs) passing this instance, and o the total compression ratio achieved on the channel. Instances are listed per IP interface. 4.1.3. rohcProfileTable The rohcProfileTable lists available profiles per instance including information on o the profile number, o the vendor and version number, and o a string describing the profile. Quittek, et al. Standards Track [Page 6] RFC 3816 ROHC MIB June 2004 o a flag indicating whether or not using this profile has been negotiated with the corresponding (de)compressor. 4.1.4. rohcContextTable The rohcContextTable lists compressor contexts or decompressor contexts per instance and context identifier (CID). Each row of this table represents a context. If a new context is created, also a new row in this table is created. After expiration or termination of a context, the row will continue to exist until the context's storage time expires or until the CID is re-used. Then the row will be deleted. For each context, the following attributes are listed: o the type of context ('compressor' or 'decompressor'), also used as part of the table index, o the CID, o the state of the CID ('unused', 'active', 'expired', or 'terminated'), also used as part of the table index, o the used profile, o in case of a decompressor: the decompressor depth, and o the storage time. Optionally, context statistics is provided including o activation and deactivation time of the context, o the number of packets sent or received, respectively, o the numbers of IRs and IR-DYNs sent or received, respectively, o the number of feedbacks sent or received, respectively, o in case of a decompressor context: the numbers of decompressor failures and repairs, o the total compression ratio of all packets passing this context, o the total compression ratio of all packet headers compressed in this context, Quittek, et al. Standards Track [Page 7] RFC 3816 ROHC MIB June 2004 o the mean compressed packet size of all packets passing this context, o the mean header size of all compressed headers passing this context, o the compression ratio of the last 16 packets passing this context, o the compression ratio of the last 16 packet headers compressed in this context, o the mean compressed packet size of the last 16 packets passing this context, o the mean header size of the last 16 compressed headers passing this context. 4.2. The ROHC-UNCOMPRESSED-MIB module The ROHC-UNCOMPRESSED-MIB module defines managed objects that are specific to ROHC uncompressed profile (0x0000) specified in [RFC3095]. 4.2.1. rohcUncmprContextTable The rohcUncmprContextTable extends the rohcContextTable. It provides information on state and mode of the compressor for profile 0x0000. Optionally, it also provides a counter of ACK feedbacks sent or received by the context, respectively. 4.3. The ROHC-RTP-MIB module The ROHC-RTP-MIB module defines managed objects that are specific to three profiles specified in [RFC3095] (ROHC RTP profile 0x0001, ROHC UDP profile 0x0002, and ROHC ESP profile 0x0003) and to the ROHC LLA profile 0x0005 specified in [RFC3242]. The ROHC-RTP-MIB contains two tables, the rohcRtpContextTable and the rohcRtpPacketSizeTable. 4.3.1. rohcRtpContextTable The rohcRtpContextTable extends the rohcContextTable. It provides information on context state and context mode for profiles 0x0001 - 0x0003 and 0x0005. For compressor contexts it optionally contains managed object containing the numbers of allowed and used packet sizes. As further option, counters of the numbers of ACKs, NACKs, and SNACKs in this context are specified. Quittek, et al. Standards Track [Page 8] RFC 3816 ROHC MIB June 2004 4.3.2. rohcPacketSizeTable The optional rohcPacketSizeTable lists per compressor context the allowed packet sizes for profiles ROHC RTP, ROHC UDP, ROHC ESP, or the preferred packet sizes for ROHC LLA, respectively. Allowed packet sizes are marked if they are used. For preferred packet sizes, it is indicated whether the preferred size applies to NHP only, to RHP only or to all packets. 5. Definitions ROHC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, TruthValue, TimeInterval, DateAndTime FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] ifIndex FROM IF-MIB; -- [RFC2863] rohcMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "IETF Robust Header Compression Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/rohc-charter.html Mailing Lists: General Discussion: rohc@ietf.org To Subscribe: rohc-request@ietf.org In Body: subscribe your_email_address Editor: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 Quittek, et al. Standards Track [Page 9] RFC 3816 ROHC MIB June 2004 69221 Heidelberg Germany Tel: +49 6221 90511-15 EMail: quittek@netlab.nec.de" DESCRIPTION "This MIB module defines a set of basic objects for monitoring and configuring robust header compression. The module covers information about running instances of ROHC (compressors or decompressors) at IP interfaces. Information about compressor contexts and decompressor contexts has different structure for different profiles. Therefore it is not provided by this MIB module, but by individual modules for different profiles. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3816. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version, published as RFC 3816." ::= { mib-2 112 } RohcChannelIdentifier ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A number identifying a channel. The value of 0 must not be used as identifier of an existing channel." SYNTAX Unsigned32 (1..4294967295) RohcChannelIdentifierOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A number identifying a channel. The value of 0 is indicates that no channel is identified." SYNTAX Unsigned32 (0..4294967295) RohcCompressionRatio ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A number indicating a compression ratio over Quittek, et al. Standards Track [Page 10] RFC 3816 ROHC MIB June 2004 a set of bytes. The value is defined as 1000 * bytes(compressed) / bytes(original) rounded to the next integer value. Note that compressed sets of bytes can be larger than the corresponding uncompressed ones. Therefore, the number can be greater than 1000." SYNTAX Unsigned32 -- -- The groups defined within this MIB module: -- rohcObjects OBJECT IDENTIFIER ::= { rohcMIB 1 } rohcConformance OBJECT IDENTIFIER ::= { rohcMIB 2 } -- -- The ROHC Instance group lists properties of ROHC -- instances in the rohcInstanceTable, about the channels used -- by the instances in the rohcChanneltable and about the profiles -- available at the instances in the rohcProfileTable. -- rohcInstanceObjects OBJECT IDENTIFIER ::= { rohcObjects 1 } -- -- Channel Table -- -- Listing all channels used for ROHC data channel -- and/or as feedback channel. -- rohcChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF RohcChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes all ROHC channels per interface." ::= { rohcInstanceObjects 1 } rohcChannelEntry OBJECT-TYPE SYNTAX RohcChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular script. Every script that is stored in non-volatile memory is required to appear in Quittek, et al. Standards Track [Page 11] RFC 3816 ROHC MIB June 2004 this script table. Note, that the rohcChannelID identifies the channel uniquely. The ifIndex is part of the index of this table just in order to allow addressing channels per interface." INDEX { ifIndex, rohcChannelID } ::= { rohcChannelTable 1 } RohcChannelEntry ::= SEQUENCE { rohcChannelID RohcChannelIdentifier, rohcChannelType INTEGER, rohcChannelFeedbackFor RohcChannelIdentifierOrZero, rohcChannelDescr SnmpAdminString, rohcChannelStatus INTEGER } rohcChannelID OBJECT-TYPE SYNTAX RohcChannelIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this channel. The value is REQUIRED to be unique per ROHC MIB implementation independent of the associated interface. The value is REQUIRED to remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. It is RECOMMENDED that the value persist across such re-initializations." REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcChannelEntry 2 } rohcChannelType OBJECT-TYPE SYNTAX INTEGER { notInUse(1), rohc(2), dedicatedFeedback(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Type of usage of the channel. A channel might be currently not in use for ROHC or feedback, it might be in use as a ROHC channel carrying packets and optional piggy-backed feedback, or it might be used as a dedicated feedback channel exclusively carrying feedback." Quittek, et al. Standards Track [Page 12] RFC 3816 ROHC MIB June 2004 ::= { rohcChannelEntry 3 } rohcChannelFeedbackFor OBJECT-TYPE SYNTAX RohcChannelIdentifierOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The index of another channel of this interface for which the channel serves as feedback channel. If no feedback information is transferred on this channel, then the value of this ID is 0. If the channel type is set to notInUse(1), then the value of this object must be 0. If the channel type is rohc(2) and the value of this object is a valid channel ID, then feedback information is piggy-backed on the ROHC channel. If the channel type is dedicatedFeedback(3), then feedback is transferred on this channel and the value of this object MUST be different from 0 and MUST identify an existing ROHC channel." REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcChannelEntry 4 } rohcChannelDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the channel." ::= { rohcChannelEntry 5 } rohcChannelStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Status of the channel." ::= { rohcChannelEntry 6 } -- -- Instances of ROHC -- -- This table lists properties of running instances of ROHC -- compressors and decompressors at the managed node. -- Quittek, et al. Standards Track [Page 13] RFC 3816 ROHC MIB June 2004 rohcInstanceTable OBJECT-TYPE SYNTAX SEQUENCE OF RohcInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists properties of running instances of robust header compressors and decompressors at IP interfaces. It is indexed by interface number, the type of instance (compressor or decompressor), and the ID of the channel used by the instance as ROHC channel. Note that the rohcChannelID uniquely identifies an instance. The ifIndex and rohcInstanceType are part of the index, because it simplifies accessing instances per interface and for addressing either compressors or decompressors only." ::= { rohcInstanceObjects 2 } rohcInstanceEntry OBJECT-TYPE SYNTAX RohcInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular instance of a robust header compressor or decompressor." INDEX { ifIndex, rohcInstanceType, rohcChannelID } ::= { rohcInstanceTable 1 } RohcInstanceEntry ::= SEQUENCE { rohcInstanceType INTEGER, rohcInstanceFBChannelID RohcChannelIdentifierOrZero, rohcInstanceVendor OBJECT IDENTIFIER, rohcInstanceVersion SnmpAdminString, rohcInstanceDescr SnmpAdminString, rohcInstanceClockRes Unsigned32, rohcInstanceMaxCID Unsigned32, rohcInstanceLargeCIDs TruthValue, rohcInstanceMRRU Unsigned32, rohcInstanceContextStorageTime TimeInterval, rohcInstanceStatus INTEGER, rohcInstanceContextsTotal Counter32, rohcInstanceContextsCurrent Unsigned32, rohcInstancePackets Counter32, rohcInstanceIRs Counter32, rohcInstanceIRDYNs Counter32, rohcInstanceFeedbacks Counter32, Quittek, et al. Standards Track [Page 14] RFC 3816 ROHC MIB June 2004 rohcInstanceCompressionRatio RohcCompressionRatio } rohcInstanceType OBJECT-TYPE SYNTAX INTEGER { compressor(1), decompressor(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "Type of the instance of ROHC. It is either a compressor instance or a decompressor instance." ::= { rohcInstanceEntry 2 } rohcInstanceFBChannelID OBJECT-TYPE SYNTAX RohcChannelIdentifierOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Identifier of the channel used for feedback. If no feedback channel is used, the value of this object is 0 ." REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcInstanceEntry 4 } rohcInstanceVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object identifier that identifies the vendor who provides the implementation of robust header description. This object identifier SHALL point to the object identifier directly below the enterprise object identifier {1 3 6 1 4 1} allocated for the vendor. The value must be the object identifier {0 0} if the vendor is not known." ::= { rohcInstanceEntry 5 } rohcInstanceVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the implementation of robust header compression. The zero-length string shall be used if the implementation does not have a version number. Quittek, et al. Standards Track [Page 15] RFC 3816 ROHC MIB June 2004 It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { rohcInstanceEntry 6 } rohcInstanceDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the implementation." ::= { rohcInstanceEntry 7 } rohcInstanceClockRes OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the system clock resolution in units of milliseconds. A zero (0) value means that there is no clock available." ::= { rohcInstanceEntry 8 } rohcInstanceMaxCID OBJECT-TYPE SYNTAX Unsigned32 (1..16383) MAX-ACCESS read-only STATUS current DESCRIPTION "The highest context ID number to be used by the compressor. Note that this parameter is not coupled to, but in effect further constrained by, rohcChannelLargeCIDs." REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcInstanceEntry 9 } rohcInstanceLargeCIDs OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When retrieved, this boolean object returns false if the short CID representation (0 bytes or 1 prefix byte, covering CID 0 to 15) is used; it returns true, if the embedded CID representation (1 or 2 embedded CID bytes covering CID 0 to 16383) is used." Quittek, et al. Standards Track [Page 16] RFC 3816 ROHC MIB June 2004 REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcInstanceEntry 10 } rohcInstanceMRRU OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum reconstructed reception unit. This is the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments (see RFC 3095, Section 5.2.5). Note that this size includes the CRC. If MRRU is negotiated to be 0, no segment headers are allowed on the channel." REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcInstanceEntry 11 } rohcInstanceContextStorageTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the default maximum amount of time information on a context belonging to this instance is kept as entry in the rohcContextTable after the context is expired or terminated. The value of this object is used to initialize rohcContexStorageTime object when a new context is created. Changing the value of an rohcInstanceContextStorageTime instance does not affect any entry of the rohcContextTable created previously. ROHC-MIB implementations SHOULD store the set value of this object persistently." DEFVAL { 360000 } ::= { rohcInstanceEntry 12 } rohcInstanceStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Status of the instance of ROHC." Quittek, et al. Standards Track [Page 17] RFC 3816 ROHC MIB June 2004 ::= { rohcInstanceEntry 13 } rohcInstanceContextsTotal OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Counter of all contexts created by this instance. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { rohcInstanceEntry 14 } rohcInstanceContextsCurrent OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of currently active contexts created by this instance." ::= { rohcInstanceEntry 15 } rohcInstancePackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Counter of all packets passing this instance. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { rohcInstanceEntry 16 } rohcInstanceIRs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all IR packets that are either sent or received by this instance. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the Quittek, et al. Standards Track [Page 18] RFC 3816 ROHC MIB June 2004 value of ifCounterDiscontinuityTime." REFERENCE "RFC 3095, Section 5.7.7.1" ::= { rohcInstanceEntry 17 } rohcInstanceIRDYNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all IR-DYN packets that are either sent or received by this instance. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "RFC 3095, Section 5.7.7.2" ::= { rohcInstanceEntry 18 } rohcInstanceFeedbacks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all feedbacks that are either sent or received by this instance. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { rohcInstanceEntry 19 } rohcInstanceCompressionRatio OBJECT-TYPE SYNTAX RohcCompressionRatio MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the compression ratio so far over all packets on the channel served by this instance. The compression is computed over all bytes of the IP packets including the IP header but excluding all lower layer headers." ::= { rohcInstanceEntry 20 } -- Quittek, et al. Standards Track [Page 19] RFC 3816 ROHC MIB June 2004 -- Profile Table -- rohcProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF RohcProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists a set of profiles supported by the instance." REFERENCE "RFC 3095, Section 5.1.1" ::= { rohcInstanceObjects 3 } rohcProfileEntry OBJECT-TYPE SYNTAX RohcProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular profile supported by the instance. It is indexed by the rohcChannelID identifying the instance and by the rohcProfile." INDEX { rohcChannelID, rohcProfile } ::= { rohcProfileTable 1 } RohcProfileEntry ::= SEQUENCE { rohcProfile Unsigned32, rohcProfileVendor OBJECT IDENTIFIER, rohcProfileVersion SnmpAdminString, rohcProfileDescr SnmpAdminString, rohcProfileNegotiated TruthValue } rohcProfile OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifier of a profile supported. For a listing of possible profile values, see the IANA registry for 'RObust Header Compression (ROHC) Profile Identifiers' at http://www.iana.org/assignments/rohc-pro-ids" ::= { rohcProfileEntry 2 } rohcProfileVendor OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current Quittek, et al. Standards Track [Page 20] RFC 3816 ROHC MIB June 2004 DESCRIPTION "An object identifier that identifies the vendor who provides the implementation of robust header description. This object identifier SHALL point to the object identifier directly below the enterprise object identifier {1 3 6 1 4 1} allocated for the vendor. The value must be the object identifier {0 0} if the vendor is not known." ::= { rohcProfileEntry 3 } rohcProfileVersion OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the implementation of robust header compression. The zero-length string shall be used if the implementation does not have a version number. It is suggested that the version number consist of one or more decimal numbers separated by dots, where the first number is called the major version number." ::= { rohcProfileEntry 4 } rohcProfileDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the implementation." ::= { rohcProfileEntry 5 } rohcProfileNegotiated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When retrieved, this boolean object returns true if the profile has been negotiated to be used at the instance, i.e., is supported also be the corresponding compressor/decompressor." ::= { rohcProfileEntry 6 } -- -- Context Table -- rohcContextTable OBJECT-TYPE SYNTAX SEQUENCE OF RohcContextEntry Quittek, et al. Standards Track [Page 21] RFC 3816 ROHC MIB June 2004 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes all compressor contexts per instance." ::= { rohcObjects 2 } rohcContextEntry OBJECT-TYPE SYNTAX RohcContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular compressor context." INDEX { rohcChannelID, rohcContextCID } ::= { rohcContextTable 1 } RohcContextEntry ::= SEQUENCE { rohcContextCID Unsigned32, rohcContextCIDState INTEGER, rohcContextProfile Unsigned32, rohcContextDecompressorDepth Unsigned32, rohcContextStorageTime TimeInterval, rohcContextActivationTime DateAndTime, rohcContextDeactivationTime DateAndTime, rohcContextPackets Counter32, rohcContextIRs Counter32, rohcContextIRDYNs Counter32, rohcContextFeedbacks Counter32, rohcContextDecompressorFailures Counter32, rohcContextDecompressorRepairs Counter32, rohcContextAllPacketsRatio RohcCompressionRatio, rohcContextAllHeadersRatio RohcCompressionRatio, rohcContextAllPacketsMeanSize Unsigned32, rohcContextAllHeadersMeanSize Unsigned32, rohcContextLastPacketsRatio RohcCompressionRatio, rohcContextLastHeadersRatio RohcCompressionRatio, rohcContextLastPacketsMeanSize Unsigned32, rohcContextLastHeadersMeanSize Unsigned32 } rohcContextCID OBJECT-TYPE SYNTAX Unsigned32 (0..16383) MAX-ACCESS not-accessible STATUS current DESCRIPTION Quittek, et al. Standards Track [Page 22] RFC 3816 ROHC MIB June 2004 "The context identifier (CID) of this context." REFERENCE "RFC 3095, Sections 5.1.1 and 5.1.3" ::= { rohcContextEntry 2 } rohcContextCIDState OBJECT-TYPE SYNTAX INTEGER { unused(1), active(2), expired(3), terminated(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "State of the CID. When a CID is assigned to a context, its state changes from `unused' to `active'. The active context may stop operation due to some explicit signalling or after observing no packet for some specified time. In the first case then the CID state changes to `terminated', in the latter case it changes to `expired'. If the CID is re-used again for another context, the state changes back to `active'." ::= { rohcContextEntry 3 } rohcContextProfile OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifier of the profile for this context. The profile is identified by its index in the rohcProfileTable for this instance. There MUST exist a corresponding entry in the rohcProfileTable using the value of rohcContextProfile as second part of the index (and using the same rohcChannelID as first part of the index)." ::= { rohcContextEntry 4 } rohcContextDecompressorDepth OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether reverse decompression, for example as described in RFC 3095, Section 6.1, is used on this channel or not, and if used, to what extent. Quittek, et al. Standards Track [Page 23] RFC 3816 ROHC MIB June 2004 Its value is only valid for decompressor contexts, i.e., if rohcInstanceType has the value decompressor(2). For compressor contexts where rohcInstanceType has the value compressor(1), the value of this object is irrelevant and MUST be set to zero (0). The value of the reverse decompression depth indicates the maximum number of packets that are buffered, and thus possibly be reverse decompressed by the decompressor. A zero (0) value means that reverse decompression is not used." ::= { rohcContextEntry 5 } rohcContextStorageTime OBJECT-TYPE SYNTAX TimeInterval UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object specifies how long this row can exist in the rohcContextTable after the rohcContextCIDState switched to expired(3) or terminated(4). This object returns the remaining time that the row may exist before it is aged out. The object is initialized with the value of the associated rohcContextStorageTime object. After expiration or termination of the context, the value of this object ticks backwards. The entry in the rohcContextTable is destroyed when the value reaches 0. The value of this object may be set in order to increase or reduce the remaining time that the row may exist. Setting the value to 0 will destroy this entry as soon as the rochContextCIDState has the value expired(3) or terminated(4). Note that there is no guarantee that the row is stored as long as this object indicates. In case of limited CID space, the instance may re-use a CID before the storage time of the corresponding row in rohcContextTable reaches the value of 0. In this case the information stored in this row is not anymore available." ::= { rohcContextEntry 6 } rohcContextActivationTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current Quittek, et al. Standards Track [Page 24] RFC 3816 ROHC MIB June 2004 DESCRIPTION "The date and time when the context started to be able to compress packets or decompress packets, respectively. The value '0000000000000000'H is returned if the context has not been activated yet." DEFVAL { '0000000000000000'H } ::= { rohcContextEntry 7 } rohcContextDeactivationTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the context stopped being able to compress packets or decompress packets, respectively, because it expired or was terminated for other reasons. The value '0000000000000000'H is returned if the context has not been deactivated yet." DEFVAL { '0000000000000000'H } ::= { rohcContextEntry 8 } rohcContextPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all packets passing this context. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable." ::= { rohcContextEntry 9 } rohcContextIRs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all IR packets sent or received, respectively, by this context. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the Quittek, et al. Standards Track [Page 25] RFC 3816 ROHC MIB June 2004 value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable." REFERENCE "RFC 3095, Section 5.7.7.1" ::= { rohcContextEntry 10 } rohcContextIRDYNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all IR-DYN packets sent or received, respectively, by this context. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable." REFERENCE "RFC 3095, Section 5.7.7.2" ::= { rohcContextEntry 11 } rohcContextFeedbacks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all feedbacks sent or received, respectively, by this context. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable." ::= { rohcContextEntry 12 } rohcContextDecompressorFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Quittek, et al. Standards Track [Page 26] RFC 3816 ROHC MIB June 2004 DESCRIPTION "The number of all decompressor failures so far in this context. The number is only valid for decompressor contexts, i.e., if rohcInstanceType has the value decompressor(2). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable." ::= { rohcContextEntry 13 } rohcContextDecompressorRepairs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all context repairs so far in this context. The number is only valid for decompressor contexts, i.e., if rohcInstanceType has the value decompressor(2). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable." ::= { rohcContextEntry 14 } rohcContextAllPacketsRatio OBJECT-TYPE SYNTAX RohcCompressionRatio MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the compression ratio so far over all packets passing this context. The compression is computed over all bytes of the IP packets including the IP header but excluding all lower layer headers." ::= { rohcContextEntry 15 } rohcContextAllHeadersRatio OBJECT-TYPE SYNTAX RohcCompressionRatio MAX-ACCESS read-only Quittek, et al. Standards Track [Page 27] RFC 3816 ROHC MIB June 2004 STATUS current DESCRIPTION "This object indicates the compression ratio so far over all packet headers passing this context. The compression is computed over all bytes of all headers that are subject to compression for the used profile." ::= { rohcContextEntry 16 } rohcContextAllPacketsMeanSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the mean compressed packet size of all packets passing this context. The packet size includes the IP header and payload but excludes all lower layer headers. The mean value is given in byte rounded to the next integer value." ::= { rohcContextEntry 17 } rohcContextAllHeadersMeanSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the mean compressed packet header size of all packets passing this context. The packet header size is the sum of the size of all headers of a packet that are subject to compression for the used profile. The mean value is given in byte rounded to the next integer value." ::= { rohcContextEntry 18 } rohcContextLastPacketsRatio OBJECT-TYPE SYNTAX RohcCompressionRatio MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the compression ratio concerning the last 16 packets passing this context or concerning all packets passing this context if they are less than 16, so far. The compression is computed over all bytes of the IP packets including the IP header but excluding all lower layer headers." ::= { rohcContextEntry 19 } rohcContextLastHeadersRatio OBJECT-TYPE SYNTAX RohcCompressionRatio MAX-ACCESS read-only Quittek, et al. Standards Track [Page 28] RFC 3816 ROHC MIB June 2004 STATUS current DESCRIPTION "This object indicates the compression ratio concerning the headers of the last 16 packets passing this context or concerning the headers of all packets passing this context if they are less than 16, so far. The compression is computed over all bytes of all headers that are subject to compression for the used profile." ::= { rohcContextEntry 20 } rohcContextLastPacketsMeanSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the mean compressed packet size concerning the last 16 packets passing this context or concerning all packets passing this context if they are less than 16, so far. The packet size includes the IP header and payload but excludes all lower layer headers. The mean value is given in byte rounded to the next integer value." ::= { rohcContextEntry 21 } rohcContextLastHeadersMeanSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the mean compressed packet header size concerning the last 16 packets passing this context or concerning all packets passing this context if they are less than 16, so far. The packet header size is the sum of the size of all headers of a packet that are subject to compression for the used profile. The mean value is given in byte rounded to the next integer value." ::= { rohcContextEntry 22 } -- -- conformance information -- rohcCompliances OBJECT IDENTIFIER ::= { rohcConformance 1 } rohcGroups OBJECT IDENTIFIER ::= { rohcConformance 2 } -- -- compliance statements -- Quittek, et al. Standards Track [Page 29] RFC 3816 ROHC MIB June 2004 rohcCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the ROHC-MIB. Note that compliance with this compliance statement requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB (RFC2863)." MODULE -- this module MANDATORY-GROUPS { rohcInstanceGroup, rohcContextGroup } GROUP rohcStatisticsGroup DESCRIPTION "A compliant implementation does not have to implement the rohcStatisticsGroup." GROUP rohcTimerGroup DESCRIPTION "A compliant implementation does not have to implement the rohcTimerGroup." OBJECT rohcInstanceContextStorageTime MIN-ACCESS read-only DESCRIPTION "A compliant implementation does not have to support changing the value of object rohcInstanceContextStorageTime." OBJECT rohcContextStorageTime MIN-ACCESS read-only DESCRIPTION "A compliant implementation does not have to support changing the value of object rohcContextStorageTime." GROUP rohcContextStatisticsGroup DESCRIPTION "A compliant implementation does not have to implement the rohcContextStatisticsGroup." ::= { rohcCompliances 1 } rohcInstanceGroup OBJECT-GROUP OBJECTS { rohcChannelType, rohcChannelFeedbackFor, rohcChannelDescr, rohcChannelStatus, rohcInstanceFBChannelID, rohcInstanceVendor, Quittek, et al. Standards Track [Page 30] RFC 3816 ROHC MIB June 2004 rohcInstanceVersion, rohcInstanceDescr, rohcInstanceClockRes, rohcInstanceMaxCID, rohcInstanceLargeCIDs, rohcInstanceMRRU, rohcInstanceStatus, rohcProfileVendor, rohcProfileVersion, rohcProfileDescr, rohcProfileNegotiated } STATUS current DESCRIPTION "A collection of objects providing information about ROHC instances, used channels and available profiles." ::= { rohcGroups 2 } rohcStatisticsGroup OBJECT-GROUP OBJECTS { rohcInstanceContextsTotal, rohcInstanceContextsCurrent, rohcInstancePackets, rohcInstanceIRs, rohcInstanceIRDYNs, rohcInstanceFeedbacks, rohcInstanceCompressionRatio } STATUS current DESCRIPTION "A collection of objects providing ROHC statistics." ::= { rohcGroups 4 } rohcContextGroup OBJECT-GROUP OBJECTS { rohcContextCIDState, rohcContextProfile, rohcContextDecompressorDepth } STATUS current DESCRIPTION "A collection of objects providing information about ROHC compressor contexts and decompressor contexts." ::= { rohcGroups 5 } rohcTimerGroup OBJECT-GROUP OBJECTS { rohcInstanceContextStorageTime, Quittek, et al. Standards Track [Page 31] RFC 3816 ROHC MIB June 2004 rohcContextStorageTime, rohcContextActivationTime, rohcContextDeactivationTime } STATUS current DESCRIPTION "A collection of objects providing statistical information about ROHC compressor contexts and decompressor contexts." ::= { rohcGroups 6 } rohcContextStatisticsGroup OBJECT-GROUP OBJECTS { rohcContextPackets, rohcContextIRs, rohcContextIRDYNs, rohcContextFeedbacks, rohcContextDecompressorFailures, rohcContextDecompressorRepairs, rohcContextAllPacketsRatio, rohcContextAllHeadersRatio, rohcContextAllPacketsMeanSize, rohcContextAllHeadersMeanSize, rohcContextLastPacketsRatio, rohcContextLastHeadersRatio, rohcContextLastPacketsMeanSize, rohcContextLastHeadersMeanSize } STATUS current DESCRIPTION "A collection of objects providing statistical information about ROHC compressor contexts and decompressor contexts." ::= { rohcGroups 7 } END ROHC-UNCOMPRESSED-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] rohcChannelID, rohcContextCID FROM ROHC-MIB; Quittek, et al. Standards Track [Page 32] RFC 3816 ROHC MIB June 2004 rohcUncmprMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "IETF Robust Header Compression Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/rohc-charter.html Mailing Lists: General Discussion: rohc@ietf.org To Subscribe: rohc-request@ietf.org In Body: subscribe your_email_address Editor: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69221 Heidelberg Germany Tel: +49 6221 90511-15 EMail: quittek@netlab.nec.de" DESCRIPTION "This MIB module defines a set of objects for monitoring and configuring RObust Header Compression (ROHC). The objects are specific to ROHC uncompressed (profile 0x0000). Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3816. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version, published as RFC 3816." ::= { mib-2 113 } -- -- The groups defined within this MIB module: -- rohcUncmprObjects OBJECT IDENTIFIER ::= { rohcUncmprMIB 1 } rohcUncmprConformance OBJECT IDENTIFIER ::= { rohcUncmprMIB 2 } -- -- Context Table -- -- The rohcUncmprContextTable lists all contexts per interface Quittek, et al. Standards Track [Page 33] RFC 3816 ROHC MIB June 2004 -- and instance. It extends the rohcContextTable. -- rohcUncmprContextTable OBJECT-TYPE SYNTAX SEQUENCE OF RohcUncmprContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes ROHC uncompressed profile specific properties of compressor contexts and decompressor contexts. It extends the rohcContextTable of the ROHC-MIB module." ::= { rohcUncmprObjects 1 } rohcUncmprContextEntry OBJECT-TYPE SYNTAX RohcUncmprContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular context." INDEX { rohcChannelID, rohcContextCID } ::= { rohcUncmprContextTable 1 } RohcUncmprContextEntry ::= SEQUENCE { rohcUncmprContextState INTEGER, rohcUncmprContextMode INTEGER, rohcUncmprContextACKs Counter32 } rohcUncmprContextState OBJECT-TYPE SYNTAX INTEGER { initAndRefresh(1), normal(2), noContext(3), fullContext(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "State of the context. States initAndRefresh(1) and normal(2) are states of compressor contexts, states noContext(3) and fullContext(4) are states of decompressor contexts." REFERENCE "RFC 3095, Section 5.10.3" Quittek, et al. Standards Track [Page 34] RFC 3816 ROHC MIB June 2004 ::= { rohcUncmprContextEntry 3 } rohcUncmprContextMode OBJECT-TYPE SYNTAX INTEGER { unidirectional(1), bidirectional(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Mode of the context." REFERENCE "RFC 3095, Section 5.10.3" ::= { rohcUncmprContextEntry 4 } rohcUncmprContextACKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all positive feedbacks (ACK) sent or received in this context, respectively. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB." REFERENCE "RFC 3095, Section 5.2.1" ::= { rohcUncmprContextEntry 5 } -- -- conformance information -- rohcUncmprCompliances OBJECT IDENTIFIER ::= { rohcUncmprConformance 1 } rohcUncmprGroups OBJECT IDENTIFIER ::= { rohcUncmprConformance 2 } -- -- compliance statements -- rohcUncmprCompliance MODULE-COMPLIANCE Quittek, et al. Standards Track [Page 35] RFC 3816 ROHC MIB June 2004 STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the ROHC-UNCOMPRESSED-MIB. Note that compliance with this compliance statement requires compliance with the rohcCompliance MODULE-COMPLIANCE statement of the ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB (RFC2863)." MODULE -- this module MANDATORY-GROUPS { rohcUncmprContextGroup } GROUP rohcUncmprStatisticsGroup DESCRIPTION "A compliant implementation does not have to implement the rohcUncmprStatisticsGroup." ::= { rohcUncmprCompliances 1 } rohcUncmprContextGroup OBJECT-GROUP OBJECTS { rohcUncmprContextState, rohcUncmprContextMode } STATUS current DESCRIPTION "A collection of objects providing information about ROHC uncompressed compressors and decompressors." ::= { rohcUncmprGroups 1 } rohcUncmprStatisticsGroup OBJECT-GROUP OBJECTS { rohcUncmprContextACKs } STATUS current DESCRIPTION "An object providing context statistics." ::= { rohcUncmprGroups 2 } END ROHC-RTP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] Quittek, et al. Standards Track [Page 36] RFC 3816 ROHC MIB June 2004 TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] rohcChannelID, rohcContextCID FROM ROHC-MIB; -- [RFC3816] rohcRtpMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "IETF Robust Header Compression Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/rohc-charter.html Mailing Lists: General Discussion: rohc@ietf.org To Subscribe: rohc-request@ietf.org In Body: subscribe your_email_address Editor: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69221 Heidelberg Germany Tel: +49 6221 90511-15 EMail: quittek@netlab.nec.de" DESCRIPTION "This MIB module defines a set of objects for monitoring and configuring RObust Header Compression (ROHC). The objects are specific to ROHC RTP (profile 0x0001), ROHC UDP (profile 0x0002), and ROHC ESP (profile 0x0003) defined in RFC 3095 and for the ROHC LLA profile (profile 0x0005) defined in RFC 3242. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3816. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html" REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version, published as RFC 3816." ::= { mib-2 114 } Quittek, et al. Standards Track [Page 37] RFC 3816 ROHC MIB June 2004 -- -- The groups defined within this MIB module: -- rohcRtpObjects OBJECT IDENTIFIER ::= { rohcRtpMIB 1 } rohcRtpConformance OBJECT IDENTIFIER ::= { rohcRtpMIB 2 } -- -- Context Table -- -- The rohcRtpContextTable lists all contexts per interface -- and instance. It extends the rohcContextTable. -- rohcRtpContextTable OBJECT-TYPE SYNTAX SEQUENCE OF RohcRtpContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists and describes RTP profile specific properties of compressor contexts and decompressor contexts. It extends the rohcContextTable of the ROHC-MIB module." ::= { rohcRtpObjects 1 } rohcRtpContextEntry OBJECT-TYPE SYNTAX RohcRtpContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular context." INDEX { rohcChannelID, rohcContextCID } ::= { rohcRtpContextTable 1 } RohcRtpContextEntry ::= SEQUENCE { rohcRtpContextState INTEGER, rohcRtpContextMode INTEGER, rohcRtpContextAlwaysPad TruthValue, rohcRtpContextLargePktsAllowed TruthValue, rohcRtpContextVerifyPeriod Unsigned32, rohcRtpContextSizesAllowed Unsigned32, rohcRtpContextSizesUsed Unsigned32, rohcRtpContextACKs Counter32, rohcRtpContextNACKs Counter32, rohcRtpContextSNACKs Counter32, Quittek, et al. Standards Track [Page 38] RFC 3816 ROHC MIB June 2004 rohcRtpContextNHPs Counter32, rohcRtpContextCSPs Counter32, rohcRtpContextCCPs Counter32, rohcRtpContextPktsLostPhysical Counter32, rohcRtpContextPktsLostPreLink Counter32 } rohcRtpContextState OBJECT-TYPE SYNTAX INTEGER { initAndRefresh(1), firstOrder(2), secondOrder(3), noContext(4), staticContext(5), fullContext(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "State of the context as defined in RFC 3095. States initAndRefresh(1), firstOrder(2), and secondOrder(3) are states of compressor contexts, states noContext(4), staticContext(5) and fullContext(6) are states of decompressor contexts." REFERENCE "RFC 3095" ::= { rohcRtpContextEntry 3 } rohcRtpContextMode OBJECT-TYPE SYNTAX INTEGER { unidirectional(1), optimistic(2), reliable(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Mode of the context." REFERENCE "RFC 3095, Section 4.4" ::= { rohcRtpContextEntry 4 } rohcRtpContextAlwaysPad OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Boolean, only applicable to compressor contexts using the Quittek, et al. Standards Track [Page 39] RFC 3816 ROHC MIB June 2004 LLA profile. If its value is true, the compressor must pad every RHP packet with a minimum of one octet ROHC padding. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 5.1.1" DEFVAL { false } ::= { rohcRtpContextEntry 5 } rohcRtpContextLargePktsAllowed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Boolean, only applicable to compressor contexts using the LLA profile. It specifies how to handle packets that do not fit any of the preferred packet sizes specified. If its value is true, the compressor must deliver the larger packet as-is and must not use segmentation. If it is set to false, the ROHC segmentation scheme must be used to split the packet into two or more segments, and each segment must further be padded to fit one of the preferred packet sizes. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 5.1.1" DEFVAL { true } ::= { rohcRtpContextEntry 6 } rohcRtpContextVerifyPeriod OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to compressor contexts using the LLA profile. It specifies the minimum frequency with which a packet validating the context must be sent. This tells the compressor that a packet containing a CRC Quittek, et al. Standards Track [Page 40] RFC 3816 ROHC MIB June 2004 field must be sent at least once every N packets, where N is the value of the object. A value of 0 indicates that periodical verifications are disabled. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 5.1.1" DEFVAL { 0 } ::= { rohcRtpContextEntry 7 } rohcRtpContextSizesAllowed OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is only valid for decompressor contexts, i.e., if rohcInstanceType of the corresponding rohcContextEntry has the value decompressor(2). For compressor contexts where rohcInstanceType has the value compressor(1), this object MUST NOT be instantiated. This object contains the number of different packet sizes that may be used in the context." REFERENCE "RFC 3095, Section 6.3.1" ::= { rohcRtpContextEntry 8 } rohcRtpContextSizesUsed OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is only valid for decompressor contexts, i.e., if rohcInstanceType of the corresponding rohcContextEntry has the value decompressor(2). For compressor contexts where rohcInstanceType has the value compressor(1), this object MUST NOT be instantiated. This object contains the number of different packet sizes that are used in the context." REFERENCE "RFC 3095, Section 6.3.1" ::= { rohcRtpContextEntry 9 } Quittek, et al. Standards Track [Page 41] RFC 3816 ROHC MIB June 2004 rohcRtpContextACKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all positive feedbacks (ACK) sent or received in this context, respectively. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB." REFERENCE "RFC 3095, Section 5.2.1." ::= { rohcRtpContextEntry 10 } rohcRtpContextNACKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all dynamic negative feedbacks (ACK) sent or received in this context, respectively. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB." REFERENCE "RFC 3095, Section 5.2.1." ::= { rohcRtpContextEntry 11 } rohcRtpContextSNACKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of all static negative feedbacks (ACK) sent or received in this context, respectively. Discontinuities in the value of this counter can occur at re-initialization of the management Quittek, et al. Standards Track [Page 42] RFC 3816 ROHC MIB June 2004 system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB." REFERENCE "RFC 3095, Section 5.2.1." ::= { rohcRtpContextEntry 12 } rohcRtpContextNHPs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to contexts using the LLA profile. It contains the number of all no-header packets (NHP) sent or received in this context, respectively. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 4.1.1." ::= { rohcRtpContextEntry 13 } rohcRtpContextCSPs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to contexts using the LLA profile. It contains the number of all context synchronization packets (CSP) sent or received in this context, respectively. Discontinuities in the value of this counter can occur at re-initialization of the management Quittek, et al. Standards Track [Page 43] RFC 3816 ROHC MIB June 2004 system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 4.1.2." ::= { rohcRtpContextEntry 14 } rohcRtpContextCCPs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to contexts using the LLA profile. It contains the number of all context check packets (CCP) sent or received in this context, respectively. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 4.1.3." ::= { rohcRtpContextEntry 15 } rohcRtpContextPktsLostPhysical OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to decompressor contexts Quittek, et al. Standards Track [Page 44] RFC 3816 ROHC MIB June 2004 using the LLA profile. It contains the number of physical packet losses on the link between compressor and decompressor, that have been indicated to the decompressor. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 5.1.2." ::= { rohcRtpContextEntry 16 } rohcRtpContextPktsLostPreLink OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to decompressor contexts using the LLA profile. It contains the number of pre-link packet losses on the link between compressor and decompressor, that have been indicated to the decompressor. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. For checking ifCounterDiscontinuityTime, the interface index is required. It can be determined by reading the rohcChannelTable of the ROHC-MIB. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 5.1.2." ::= { rohcRtpContextEntry 17 } Quittek, et al. Standards Track [Page 45] RFC 3816 ROHC MIB June 2004 -- -- Packet Sizes Table -- -- The rohcPacketSizeTable lists allowed, preferred, and used -- packet sizes per compressor context. rohcRtpPacketSizeTable OBJECT-TYPE SYNTAX SEQUENCE OF RohcRtpPacketSizeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all allowed, preferred, and used packet sizes per compressor context and channel. Note, that the sizes table represents implementation parameters that are suggested by RFC 3095 and/or RFC 3242, but that are not mandatory." ::= { rohcRtpObjects 2 } rohcRtpPacketSizeEntry OBJECT-TYPE SYNTAX RohcRtpPacketSizeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of a particular packet size." INDEX { rohcChannelID, rohcContextCID, rohcRtpPacketSize } ::= { rohcRtpPacketSizeTable 1 } RohcRtpPacketSizeEntry ::= SEQUENCE { rohcRtpPacketSize Unsigned32, rohcRtpPacketSizePreferred TruthValue, rohcRtpPacketSizeUsed TruthValue, rohcRtpPacketSizeRestrictedType INTEGER } rohcRtpPacketSize OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A packet size used as index." ::= { rohcRtpPacketSizeEntry 3 } rohcRtpPacketSizePreferred OBJECT-TYPE Quittek, et al. Standards Track [Page 46] RFC 3816 ROHC MIB June 2004 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to compressor contexts using the LLA profile. When retrieved, it will have the value true(1) if the packet size is preferred. Otherwise, its value will be false(2). The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 5.1.1" ::= { rohcRtpPacketSizeEntry 4 } rohcRtpPacketSizeUsed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to compressor contexts using the UDP, RTP, or ESP profile. When retrieved, it will have the value true(1) if the packet size is used. Otherwise, its value will be false(2). The value of this object is only valid for UDP, RTP, and ESP profiles, i.e., if the corresponding rohcProfile has a value of either 0x0001, 0x0002 or 0x0003. If the corresponding rohcProfile has a value other than 0x0001, 0x0002 or 0x0003, then this object MUST NOT be instantiated." REFERENCE "RFC 3095, Section 6.3.1" ::= { rohcRtpPacketSizeEntry 5 } rohcRtpPacketSizeRestrictedType OBJECT-TYPE SYNTAX INTEGER { nhpOnly(1), rhpOnly(2), noRestrictions(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object is only applicable to preferred packet Quittek, et al. Standards Track [Page 47] RFC 3816 ROHC MIB June 2004 sizes of compressor contexts using the LLA profile. When retrieved, it will indicate whether the packet size is preferred for NHP only, for RHP only, or for both of them. The value of this object is only valid for LLA profiles, i.e., if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." REFERENCE "RFC 3242, Section 5.1.1" ::= { rohcRtpPacketSizeEntry 6 } -- -- conformance information -- rohcRtpCompliances OBJECT IDENTIFIER ::= { rohcRtpConformance 1 } rohcRtpGroups OBJECT IDENTIFIER ::= { rohcRtpConformance 2 } -- -- compliance statements -- rohcRtpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the ROHC-RTP-MIB. Note that compliance with this compliance statement requires compliance with the rohcCompliance MODULE-COMPLIANCE statement of the ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB (RFC2863)." MODULE -- this module MANDATORY-GROUPS { rohcRtpContextGroup } GROUP rohcRtpPacketSizesGroup DESCRIPTION "A compliant implementation does not have to implement the rohcRtpPacketSizesGroup." GROUP rohcRtpStatisticsGroup DESCRIPTION "A compliant implementation does not have to implement the rohcRtpStatisticsGroup." ::= { rohcRtpCompliances 1 } Quittek, et al. Standards Track [Page 48] RFC 3816 ROHC MIB June 2004 rohcRtpContextGroup OBJECT-GROUP OBJECTS { rohcRtpContextState, rohcRtpContextMode, rohcRtpContextAlwaysPad, rohcRtpContextLargePktsAllowed, rohcRtpContextVerifyPeriod } STATUS current DESCRIPTION "A collection of objects providing information about ROHC RTP compressors and decompressors." ::= { rohcRtpGroups 1 } rohcRtpPacketSizesGroup OBJECT-GROUP OBJECTS { rohcRtpContextSizesAllowed, rohcRtpContextSizesUsed, rohcRtpPacketSizePreferred, rohcRtpPacketSizeUsed, rohcRtpPacketSizeRestrictedType } STATUS current DESCRIPTION "A collection of objects providing information about allowed and used packet sizes at a ROHC RTP compressor." ::= { rohcRtpGroups 2 } rohcRtpStatisticsGroup OBJECT-GROUP OBJECTS { rohcRtpContextACKs, rohcRtpContextNACKs, rohcRtpContextSNACKs, rohcRtpContextNHPs, rohcRtpContextCSPs, rohcRtpContextCCPs, rohcRtpContextPktsLostPhysical, rohcRtpContextPktsLostPreLink } STATUS current DESCRIPTION "A collection of objects providing ROHC compressor and decompressor statistics." ::= { rohcRtpGroups 3 } END Quittek, et al. Standards Track [Page 49] RFC 3816 ROHC MIB June 2004 6. Security Considerations The managed objects defined by the ROHC-MIB module, the ROHC- UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not have a MAX-ACCESS value of read-write and/or read-create except rohcInstanceContextStorageTime and rohcContextStorageTime, both of which have a MAX-ACCESS value of read-write. These objects determine how long context information is stored after its termination. Unauthorized access to these objects can have one of two negative effects. If they are set to a value lower than required, e.g., to zero, then context information about past contexts might get lost. If they are set to a very high value, then context information will not be deleted and memory consumption of the agent implementation might become very high. However, unauthorized access to these objects cannot cause harm to existing ROHC connections nor can it allow manipulation of running instances of ROHC in a malicious way. Another security issue is unauthorized access to readable objects in the MIB modules for getting information about existing communication sessions. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. However, the only information that might be disclosed is the use of channels. Users and their addresses are not visible in the MIB. This information can only be mis-used in conjunction with the mis-use of further information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Quittek, et al. Standards Track [Page 50] RFC 3816 ROHC MIB June 2004 7. Acknowledgements Many thanks to Lars-Erik Jonsson and Mark West for their guidance through the ROHC world and to Ghyslain Pelletier for explaining how the ROHC LLA profile works. Further thanks to Frank Strauss for his advice on tricky SMI issues. Special thanks to Mike Heard who acted as MIB doctor. He studied every tiny detail, raised a long list of issues and helped to significantly improve this document. 8. References 8.1. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3242] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3759] Jonsson, L., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004. Quittek, et al. Standards Track [Page 51] RFC 3816 ROHC MIB June 2004 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 9. Authors' Addresses Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de Martin Stiemerling NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-13 EMail: stiemerling@netlab.nec.de Hannes Hartenstein University of Karlsruhe Computing Center and Institute of Telematics 76128 Karlsruhe Germany Phone: +49 721 608 8104 EMail: hartenstein@rz.uni-karlsruhe.de Quittek, et al. Standards Track [Page 52] RFC 3816 ROHC MIB June 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Quittek, et al. Standards Track [Page 53] snmp-mibs-downloader-1.1/mibrfcs/rfc3826.txt0000644000000000000000000010006511402176071015566 0ustar Network Working Group U. Blumenthal Request for Comments: 3826 Lucent Technologies Category: Standards Track F. Maino Andiamo Systems, Inc. K. McCloghrie Cisco Systems, Inc. June 2004 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Goals and Constraints. . . . . . . . . . . . . . . . . 2 1.2. Key Localization . . . . . . . . . . . . . . . . . . . 3 1.3. Password Entropy and Storage . . . . . . . . . . . . . 3 2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . 4 3. CFB128-AES-128 Symmetric Encryption Protocol . . . . . . . . 5 3.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. The AES-based Symmetric Encryption Protocol . . 6 3.1.2. Localized Key, AES Encryption Key and Initialization Vector . . . . . . . . . . . . . 7 3.1.3. Data Encryption . . . . . . . . . . . . . . . . 8 3.1.4. Data Decryption . . . . . . . . . . . . . . . . 8 Blumenthal, et al. Standards Track [Page 1] RFC 3826 AES for SNMP's USM June 2004 3.2. Elements of the AES Privacy Protocol . . . . . . . . . 9 3.2.1. Users . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. msgAuthoritativeEngineID. . . . . . . . . . . . 9 3.2.3. SNMP Messages Using this Privacy Protocol . . . 10 3.2.4. Services provided by the AES Privacy Modules. . 10 3.3. Elements of Procedure. . . . . . . . . . . . . . . . . 11 3.3.1. Processing an Outgoing Message. . . . . . . . . 12 3.3.2. Processing an Incoming Message. . . . . . . . . 12 4. Security Considerations. . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . 14 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 1. Introduction Within the Architecture for describing Internet Management Frameworks [RFC3411], the User-based Security Model (USM) [RFC3414] for SNMPv3 is defined as a Security Subsystem within an SNMP engine. RFC 3414 describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the initial authentication protocols, and the use of CBC-DES as the initial privacy protocol. The User-based Security Model, however, allows for other such protocols to be used instead of, or concurrently with, these protocols. This memo describes the use of CFB128-AES-128 as an alternative privacy protocol for the User-based Security Model. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Goals and Constraints The main goal of this memo is to provide a new privacy protocol for the USM based on the Advanced Encryption Standard (AES) [FIPS-AES]. The major constraint is to maintain a complete interchangeability of the new protocol defined in this memo with existing authentication and privacy protocols already defined in USM. For a given user, the AES-based privacy protocol MUST be used with one of the authentication protocols defined in RFC 3414 or an algorithm/protocol providing equivalent functionality. Blumenthal, et al. Standards Track [Page 2] RFC 3826 AES for SNMP's USM June 2004 1.2. Key Localization As defined in [RFC3414], a localized key is a secret key shared between a user U and one authoritative SNMP engine E. Even though a user may have only one pair of authentication and privacy passwords (and consequently only one pair of keys) for the entire network, the actual secrets shared between the user and each authoritative SNMP engine will be different. This is achieved by key localization. If the authentication protocol defined for a user U at the authoritative SNMP engine E is one of the authentication protocols defined in [RFC3414], the key localization is performed according to the two-step process described in section 2.6 of [RFC3414]. 1.3. Password Entropy and Storage The security of various cryptographic functions lies both in the strength of the functions themselves against various forms of attack, and also, perhaps more importantly, in the keying material that is used with them. While theoretical attacks against cryptographic functions are possible, it is more probable that key guessing is the main threat. The following are recommended in regard to user passwords: - Password length SHOULD be at least 12 octets. - Password sharing SHOULD be prohibited so that passwords are not shared among multiple SNMP users. - Implementations SHOULD support the use of randomly generated passwords as a stronger form of security. It is worth remembering that, as specified in [RFC3414], if a user's password or a non-localized key is disclosed, then key localization will not help and network security may be compromised. Therefore, a user's password or non-localized key MUST NOT be stored on a managed device/node. Instead, the localized key SHALL be stored (if at all) so that, in case a device does get compromised, no other managed or managing devices get compromised. Blumenthal, et al. Standards Track [Page 3] RFC 3826 AES for SNMP's USM June 2004 2. Definitions This MIB is written in SMIv2 [RFC2578]. SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, snmpModules FROM SNMPv2-SMI -- [RFC2578] snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] snmpUsmAesMIB MODULE-IDENTITY LAST-UPDATED "200406140000Z" ORGANIZATION "IETF" CONTACT-INFO "Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd. 14D-318 Whippany, NJ 07981, USA 973-386-2163 uri@bell-labs.com Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA 95134, USA 408-853-7530 fmaino@andiamo.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706, USA 408-526-5260 kzm@cisco.com" DESCRIPTION "Definitions of Object Identities needed for the use of AES by SNMP's User-based Security Model. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3826; see the RFC itself for full legal notices. Supplementary information may be available on http://www.ietf.org/copyrights/ianamib.html." Blumenthal, et al. Standards Track [Page 4] RFC 3826 AES for SNMP's USM June 2004 REVISION "200406140000Z" DESCRIPTION "Initial version, published as RFC3826" ::= { snmpModules 20 } usmAesCfb128Protocol OBJECT-IDENTITY STATUS current DESCRIPTION "The CFB128-AES-128 Privacy Protocol." REFERENCE "- Specification for the ADVANCED ENCRYPTION STANDARD. Federal Information Processing Standard (FIPS) Publication 197. (November 2001). - Dworkin, M., NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques. NIST Special Publication 800-38A (December 2001). " ::= { snmpPrivProtocols 4 } END 3. CFB128-AES-128 Symmetric Encryption Protocol This section describes a Symmetric Encryption Protocol based on the AES cipher algorithm [FIPS-AES], used in Cipher Feedback Mode as described in [AES-MODE], using encryption keys with a size of 128 bits. This protocol is identified by usmAesCfb128PrivProtocol. The protocol usmAesCfb128PrivProtocol is an alternative to the privacy protocol defined in [RFC3414]. 3.1. Mechanisms In support of data confidentiality, an encryption algorithm is required. An appropriate portion of the message is encrypted prior to being transmitted. The User-based Security Model specifies that the scopedPDU is the portion of the message that needs to be encrypted. A secret value is shared by all SNMP engines which can legitimately originate messages on behalf of the appropriate user. This secret value, in combination with a timeliness value and a 64-bit integer, is used to create the (localized) en/decryption key and the initialization vector. Blumenthal, et al. Standards Track [Page 5] RFC 3826 AES for SNMP's USM June 2004 3.1.1. The AES-based Symmetric Encryption Protocol The Symmetric Encryption Protocol defined in this memo provides support for data confidentiality. The designated portion of an SNMP message is encrypted and included as part of the message sent to the recipient. The AES (Advanced Encryption Standard) is the symmetric cipher algorithm that the NIST (National Institute of Standards and Technology) has selected in a four-year competitive process as Replacement for DES (Data Encryption Standard). The AES homepage, http://www.nist.gov/aes, contains a wealth of information on AES including the Federal Information Processing Standard [FIPS-AES] that fully specifies the Advanced Encryption Standard. The following subsections contain descriptions of the relevant characteristics of the AES ciphers used in the symmetric encryption protocol described in this memo. 3.1.1.1. Mode of operation The NIST Special Publication 800-38A [AES-MODE] recommends five confidentiality modes of operation for use with AES: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR). The symmetric encryption protocol described in this memo uses AES in CFB mode with the parameter S (number of bits fed back) set to 128 according to the definition of CFB mode given in [AES-MODE]. This mode requires an Initialization Vector (IV) that is the same size as the block size of the cipher algorithm. 3.1.1.2. Key Size In the encryption protocol described by this memo AES is used with a key size of 128 bits, as recommended in [AES-MODE]. 3.1.1.3. Block Size and Padding The block size of the AES cipher algorithms used in the encryption protocol described by this memo is 128 bits, as recommended in [AES- MODE]. Blumenthal, et al. Standards Track [Page 6] RFC 3826 AES for SNMP's USM June 2004 3.1.1.4. Rounds This parameter determines how many times a block is encrypted. The encryption protocol described in this memo uses 10 rounds, as recommended in [AES-MODE]. 3.1.2. Localized Key, AES Encryption Key, and Initialization Vector The size of the Localized Key (Kul) of an SNMP user, as described in [RFC3414], depends on the authentication protocol defined for that user U at the authoritative SNMP engine E. The encryption protocol defined in this memo MUST be used with an authentication protocol that generates a localized key with at least 128 bits. The authentication protocols described in [RFC3414] satisfy this requirement. 3.1.2.1. AES Encryption Key and IV The first 128 bits of the localized key Kul are used as the AES encryption key. The 128-bit IV is obtained as the concatenation of the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64- bit integer is initialized to a pseudo-random value at boot time. The IV is concatenated as follows: the 32-bit snmpEngineBoots is converted to the first 4 octets (Most Significant Byte first), the 32-bit snmpEngineTime is converted to the subsequent 4 octets (Most Significant Byte first), and the 64-bit integer is then converted to the last 8 octets (Most Significant Byte first). The 64-bit integer is then put into the msgPrivacyParameters field encoded as an OCTET STRING of length 8 octets. The integer is then modified for the subsequent message. We recommend that it is incremented by one until it reaches its maximum value, at which time it is wrapped. An implementation can use any method to vary the value of the local 64-bit integer, providing the chosen method never generates a duplicate IV for the same key. A duplicated IV can result in the very unlikely event that multiple managers, communicating with a single authoritative engine, both accidentally select the same 64-bit integer within a second. The probability of such an event is very low, and does not significantly affect the robustness of the mechanisms proposed. Blumenthal, et al. Standards Track [Page 7] RFC 3826 AES for SNMP's USM June 2004 The 64-bit integer must be placed in the privParameters field to enable the receiving entity to compute the correct IV and to decrypt the message. This 64-bit value is called the "salt" in this document. Note that the sender and receiver must use the same IV value, i.e., they must both use the same values of the individual components used to create the IV. In particular, both sender and receiver must use the values of snmpEngineBoots, snmpEngineTime, and the 64-bit integer which are contained in the relevant message (in the msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime, and privParameters fields respectively). 3.1.3. Data Encryption The data to be encrypted is treated as a sequence of octets. The data is encrypted in Cipher Feedback mode with the parameter s set to 128 according to the definition of CFB mode given in Section 6.3 of [AES-MODE]. A clear diagram of the encryption and decryption process is given in Figure 3 of [AES-MODE]. The plaintext is divided into 128-bit blocks. The last block may have fewer than 128 bits, and no padding is required. The first input block is the IV, and the forward cipher operation is applied to the IV to produce the first output block. The first ciphertext block is produced by exclusive-ORing the first plaintext block with the first output block. The ciphertext block is also used as the input block for the subsequent forward cipher operation. The process is repeated with the successive input blocks until a ciphertext segment is produced from every plaintext segment. The last ciphertext block is produced by exclusive-ORing the last plaintext segment of r bits (r is less than or equal to 128) with the segment of the r most significant bits of the last output block. 3.1.4. Data Decryption In CFB decryption, the IV is the first input block, the first ciphertext is used for the second input block, the second ciphertext is used for the third input block, etc. The forward cipher function is applied to each input block to produce the output blocks. The output blocks are exclusive-ORed with the corresponding ciphertext blocks to recover the plaintext blocks. Blumenthal, et al. Standards Track [Page 8] RFC 3826 AES for SNMP's USM June 2004 The last ciphertext block (whose size r is less than or equal to 128) is exclusive-ORed with the segment of the r most significant bits of the last output block to recover the last plaintext block of r bits. 3.2. Elements of the AES Privacy Protocol This section contains definitions required to realize the privacy modules defined by this memo. 3.2.1. Users Data en/decryption using this Symmetric Encryption Protocol makes use of a defined set of userNames. For any user on whose behalf a message must be en/decrypted at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that needs to communicate with another SNMP engine must also have knowledge of a user known to that SNMP engine, including knowledge of the applicable attributes of that user. A user and its attributes are defined as follows: An octet string representing the name of the user. The algorithm used to protect messages generated on behalf of the user from disclosure. The user's secret key to be used as input to the generation of the localized key for encrypting/decrypting messages generated on behalf of the user. The length of this key MUST be greater than or equal to 128 bits (16 octets). The algorithm used to authenticate messages generated on behalf of the user, which is also used to generate the localized version of the secret key. 3.2.2. msgAuthoritativeEngineID The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC3411]). Blumenthal, et al. Standards Track [Page 9] RFC 3826 AES for SNMP's USM June 2004 The user's (private) privacy key is different at each authoritative SNMP engine, and so the snmpEngineID is used to select the proper key for the en/decryption process. 3.2.3. SNMP Messages Using this Privacy Protocol Messages using this privacy protocol carry a msgPrivacyParameters field as part of the msgSecurityParameters. For this protocol, the privParameters field is the serialized OCTET STRING representing the "salt" that was used to create the IV. 3.2.4. Services provided by the AES Privacy Modules This section describes the inputs and outputs that the AES Privacy module expects and produces when the User-based Security module invokes one of the AES Privacy modules for services. 3.2.4.1. Services for Encrypting Outgoing Data The AES privacy protocol assumes that the selection of the privKey is done by the caller, and that the caller passes the localized secret key to be used. Upon completion, the privacy module returns statusInformation and, if the encryption process was successful, the encryptedPDU and the msgPrivacyParameters encoded as an OCTET STRING. The abstract service primitive is: statusInformation = -- success or failure encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU) OUT encryptedData -- encrypted data (encryptedPDU) OUT privParameters -- filled in by service provider ) The abstract data elements are: statusInformation An indication of the success or failure of the encryption process. In case of failure, it is an indication of the error. encryptKey The secret key to be used by the encryption algorithm. The length of this key MUST be 16 octets. dataToEncrypt The data that must be encrypted. Blumenthal, et al. Standards Track [Page 10] RFC 3826 AES for SNMP's USM June 2004 encryptedData The encrypted data upon successful completion. privParameters The privParameters encoded as an OCTET STRING. 3.2.4.2. Services for Decrypting Incoming Data This AES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the localized secret key to be used. Upon completion the privacy module returns statusInformation and, if the decryption process was successful, the scopedPDU in plain text. The abstract service primitive is: statusInformation = decryptData( IN decryptKey -- secret key for decryption IN privParameters -- as received on the wire IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) ) The abstract data elements are: statusInformation An indication of whether the data was successfully decrypted, and if not, an indication of the error. decryptKey The secret key to be used by the decryption algorithm. The length of this key MUST be 16 octets. privParameters The 64-bit integer to be used to calculate the IV. encryptedData The data to be decrypted. decryptedData The decrypted data. 3.3. Elements of Procedure This section describes the procedures for the AES privacy protocol for SNMP's User-based Security Model. Blumenthal, et al. Standards Track [Page 11] RFC 3826 AES for SNMP's USM June 2004 3.3.1. Processing an Outgoing Message This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usmAesCfb128PrivProtocol. 1) The secret encryptKey is used to construct the AES encryption key, as described in section 3.1.2.1. 2) The privParameters field is set to the serialization according to the rules in [RFC3417] of an OCTET STRING representing the 64-bit integer that will be used in the IV as described in section 3.1.2.1. 3) The scopedPDU is encrypted (as described in section 3.1.3) and the encrypted data is serialized according to the rules in [RFC3417] as an OCTET STRING. 4) The serialized OCTET STRING representing the encrypted scopedPDU together with the privParameters and statusInformation indicating success is returned to the calling module. 3.3.2. Processing an Incoming Message This section describes the procedure followed by an SNMP engine whenever it must decrypt part of an incoming message using the usmAesCfb128PrivProtocol. 1) If the privParameters field is not an 8-octet OCTET STRING, then an error indication (decryptionError) is returned to the calling module. 2) The 64-bit integer is extracted from the privParameters field. 3) The secret decryptKey and the 64-bit integer are then used to construct the AES decryption key and the IV that is computed as described in section 3.1.2.1. 4) The encryptedPDU is then decrypted (as described in section 3.1.4). 5) If the encryptedPDU cannot be decrypted, then an error indication (decryptionError) is returned to the calling module. 6) The decrypted scopedPDU and statusInformation indicating success are returned to the calling module. Blumenthal, et al. Standards Track [Page 12] RFC 3826 AES for SNMP's USM June 2004 4. Security Considerations The security of the cryptographic functions defined in this document lies both in the strength of the functions themselves against various forms of attack, and also, perhaps more importantly, in the keying material that is used with them. The recommendations in Section 1.3 SHOULD be followed to ensure maximum entropy to the selected passwords, and to protect the passwords while stored. The security of the CFB mode relies upon the use of a unique IV for each message encrypted with the same key [CRYPTO-B]. If the IV is not unique, a cryptanalyst can recover the corresponding plaintext. Section 3.1.2.1 defines a procedure to derive the IV from a local 64-bit integer (the salt) initialized to a pseudo-random value at boot time. An implementation can use any method to vary the value of the local 64-bit integer, providing the chosen method never generates a duplicate IV for the same key. The procedure of section 3.1.2.1 suggests a method to vary the local 64-bit integer value that generates unique IVs for every message. This method can result in a duplicated IV in the very unlikely event that multiple managers, communicating with a single authoritative engine, both accidentally select the same 64-bit integer within a second. The probability of such an event is very low, and does not significantly affect the robustness of the mechanisms proposed. This AES-based privacy protocol MUST be used with one of the authentication protocols defined in RFC 3414 or with an algorithm/protocol providing equivalent functionality (including integrity), because CFB encryption mode does not detect ciphertext modifications. For further security considerations, the reader is encouraged to read [RFC3414], and the documents that describe the actual cipher algorithms. 5. IANA Considerations IANA has assigned OID 20 for the snmpUsmAesMIB module under the snmpModules subtree, maintained in the registry at http://www.iana.org/assignments/smi-numbers. IANA has assigned OID 4 for the usmAesCfb128Protocol under the snmpPrivProtocols registration point, as defined in RFC 3411 [RFC3411]. Blumenthal, et al. Standards Track [Page 13] RFC 3826 AES for SNMP's USM June 2004 6. Acknowledgements Portions of this text, as well as its general structure, were unabashedly lifted from [RFC3414]. The authors are grateful to many of the SNMPv3 WG members for their help, especially Wes Hardaker, Steve Moulton, Randy Presuhn, David Town, and Bert Wijnen. Security discussions with Steve Bellovin helped to streamline this protocol. 7. References 7.1. Normative References [AES-MODE] Dworkin, M., "NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques", NIST Special Publication 800-38A, December 2001. [FIPS-AES] "Specification for the ADVANCED ENCRYPTION STANDARD (AES)", Federal Information Processing Standard (FIPS) Publication 197, November 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 7.2. Informative References [CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997. Blumenthal, et al. Standards Track [Page 14] RFC 3826 AES for SNMP's USM June 2004 8. Authors' Addresses Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd. 14D-318 Whippany, NJ 07981, USA Phone: +1-973-386-2163 EMail: uri@bell-labs.com Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA. 95134 USA Phone: +1-408-853-7530 EMail: fmaino@andiamo.com Keith McCloghrie Cisco Systems, Inc. 170 East Tasman Drive San Jose, CA. 95134-1706 USA Phone: +1-408-526-5260 EMail: kzm@cisco.com Blumenthal, et al. Standards Track [Page 15] RFC 3826 AES for SNMP's USM June 2004 9. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Blumenthal, et al. Standards Track [Page 16] snmp-mibs-downloader-1.1/mibrfcs/rfc3872.txt0000644000000000000000000030046611402176071015576 0ustar Network Working Group D. Zinman Request for Comments: 3872 D. Walker Category: Standards Track J. Jiang September 2004 Management Information Base for Telephony Routing over IP (TRIP) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Conventions used in this document. . . . . . . . . . . . . . . 2 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 5. Structure of TRIP MIB. . . . . . . . . . . . . . . . . . . . . 2 5.1. Textual Conventions. . . . . . . . . . . . . . . . . . . 3 6. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. TRIP Textual Conventions . . . . . . . . . . . . . . . . 4 6.2. TRIP MIB . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 48 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.1. Normative References . . . . . . . . . . . . . . . . . . 50 8.2. Informative References . . . . . . . . . . . . . . . . . 51 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53 Zinman, et al. Standards Track [Page 1] RFC 3872 MIB for TRIP September 2004 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB module objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in this MIB module are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. 2. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. Since TRIP [RFC3219] is modeled after the Border Gateway Protocol (BGP-4) [RFC1771], the managed objects for TRIP are also modeled after RFC1657 - Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 [RFC1657]. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 4. Overview This MIB module provides managed objects for TRIP devices defined in Telephony Routing over IP [RFC3219]. TRIP is an inter-domain application-layer control protocol that exchanges information between TRIP location servers (LS) to provide efficient IP telephony routing. 5. Structure of TRIP MIB This MIB module utilizes the framework described in RFC 2788 [RFC2788] for management of multiple instances of TRIP from a single entity. The Network Services Monitoring MIB module applTable will be populated with entries corresponding to each TRIP Location Server Zinman, et al. Standards Track [Page 2] RFC 3872 MIB for TRIP September 2004 in the system. Each TRIP Location Server will then have an applIndex associated with it. The value assigned to applIndex will represent the distinct instance of TRIP. The TRIP MIB module contains the following groups of objects with each group as part of the management of a singular TRIP entity. Each group covers a section of functionality of TRIP: o The tripConfigGroup contains the common configuration objects applicable to all TRIP applications referenced by the applIndex. o The tripPeerTableConfigGroup contains the configuration objects applicable to all TRIP peers of the Location Server referenced by the applIndex. o The tripRouteGroup contains the configuration objects related to the routes of all TRIBs of this Location Server. o The tripItadTopologyGroup contains information about the topology of the TRIP ITADs concerning this Location Server. o The tripPeerTableStatsGroup contains the statistical objects applicable to all TRIP peers of the Location Server referenced by the applIndex. o The tripNotificationGroup contains notifications that the TRIP application can generate. o The tripNotifObjectGroup contains the objects needed by one or more of the notifications. 5.1. Textual Conventions The data types TripItad and TripId are used as textual conventions in this document. A TRIP ITAD (IP Telephony Administrative Domain) is described in [RFC3219]. A TRIP ID is used as a distinct identifier for a TRIP Location Server. A TripAppProtocol is used to identify an application protocol. A TripAddressFamily is used to define an address family. TripCommunityId is used as a distinct identifier for a TRIP community. TripProtocolVersion depicts the version number of the TRIP protocol. TripSendReceiveMode describes the operational mode of the TRIP application. Zinman, et al. Standards Track [Page 3] RFC 3872 MIB for TRIP September 2004 6. Definitions 6.1. TRIP Textual Conventions TRIP-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Unsigned32, Integer32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] tripTC MODULE-IDENTITY LAST-UPDATED "200409020000Z" -- Sep 02, 2004 ORGANIZATION "IETF IPTel Working Group. Mailing list: iptel@lists.bell-labs.com" CONTACT-INFO "Co-editor David Zinman postal: 265 Ridley Blvd. Toronto ON, M5M 4N8 Canada email: dzinman@rogers.com phone: +1 416 433 4298 Co-editor: David Walker Sedna Wireless Inc. postal: 495 March Road, Suite 500 Ottawa, ON K2K 3G1 Canada email: david.walker@sedna-wireless.com phone: +1 613 878 8142 Co-editor Jianping Jiang Syndesis Limited postal: 30 Fulton Way Richmond Hill, ON L4B 1J5 Canada email: jjiang@syndesis.com phone: +1 905 886-7818 x2515 " DESCRIPTION "Initial version of TRIP (Telephony Routing Over IP) MIB Textual Conventions module used by other Zinman, et al. Standards Track [Page 4] RFC 3872 MIB for TRIP September 2004 TRIP-related MIB Modules. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3872, see the RFC itself for full legal notices." REVISION "200409020000Z" -- Sep 02, 2004 DESCRIPTION "The initial version, Published as RFC 3872." ::= { mib-2 115 } -- -- Textual Conventions -- TripItad ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The values for identifying the IP Telephony Administrative Domain (ITAD)." SYNTAX Unsigned32 (0..4294967295) TripId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The TRIP Identifier uniquely identifies a LS within its ITAD. It is a 4 octet unsigned integer that may, but not necessarily, represent the IPv4 address of a Location Server. Where bytes 1-4 of the Unsigned32 represent 1-4 bytes of the IPv4 address in network-byte order. For an IPv6 network, TripId will not represent the IPv6 address." SYNTAX Unsigned32 (0..4294967295) TripAddressFamily ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A type of address for a TRIP route. Address families defined within this MIB module are: Code Address Family 1 Decimal Routing Numbers 2 PentaDecimal Routing Numbers 3 E.164 Numbers 255 An other type of address family" SYNTAX INTEGER { decimal(1), pentadecimal(2), e164(3), other(255) } Zinman, et al. Standards Track [Page 5] RFC 3872 MIB for TRIP September 2004 TripAppProtocol ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The application protocol used for communication with TRIP Location Servers. Protocols defined in this MIB Module are: Code Protocol 1 SIP 2 H.323-H.225.0-Q.931 3 H.323-H.225.0-RAS 4 H.323-H.225.0-Annex-G 255 An other type of application protocol" SYNTAX INTEGER { sip(1), q931(2), ras(3), annexG(4), other(255) } TripCommunityId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The range of legal values for a TRIP Community Identifier." SYNTAX Unsigned32 (0..4294967295) TripProtocolVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The version number of the TRIP protocol." SYNTAX Integer32 (1..255) TripSendReceiveMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The operational mode of the TRIP application. Possible values are: 1 - Send Receive mode 2 - Send only mode 3 - Receive Only mode" SYNTAX INTEGER { sendReceive(1), sendOnly(2), receiveOnly(3) } END Zinman, et al. Standards Track [Page 6] RFC 3872 MIB for TRIP September 2004 6.2. TRIP MIB TRIP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Integer32, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] DateAndTime, TimeInterval, TruthValue, TimeStamp, StorageType, RowStatus FROM SNMPv2-TC -- [RFC2579] OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- [RFC3291] applIndex, applRFC2788Group FROM NETWORK-SERVICES-MIB -- [RFC2788] TripItad, TripId, TripAppProtocol, TripAddressFamily, TripCommunityId, TripProtocolVersion, TripSendReceiveMode FROM TRIP-TC-MIB; -- [RFC3872] tripMIB MODULE-IDENTITY LAST-UPDATED "200409020000Z" -- Sep 02, 2004 ORGANIZATION "IETF IPTel Working Group. Zinman, et al. Standards Track [Page 7] RFC 3872 MIB for TRIP September 2004 Mailing list: iptel@lists.bell-labs.com" CONTACT-INFO "Co-editor David Zinman postal: 265 Ridley Blvd. Toronto ON, M5M 4N8 Canada email: dzinman@rogers.com phone: +1 416 433 4298 Co-editor: David Walker Sedna Wireless Inc. postal: 495 March Road, Suite 500 Ottawa, ON K2K 3G1 Canada email: david.walker@sedna-wireless.com phone: +1 613 878 8142 Co-editor Jianping Jiang Syndesis Limited postal: 30 Fulton Way Richmond Hill, ON L4B 1J5 Canada email: jjiang@syndesis.com phone: +1 905 886-7818 x2515 " DESCRIPTION "The MIB module describing Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers (LS), and for advertising attributes of the routes to those destinations. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3872, see the RFC itself for full legal notices." REVISION "200409020000Z" -- Sep 02, 2004 DESCRIPTION "The initial version, Published as RFC 3872." ::= { mib-2 116 } tripMIBNotifications OBJECT IDENTIFIER ::= { tripMIB 0 } tripMIBObjects OBJECT IDENTIFIER ::= { tripMIB 1 } tripMIBConformance OBJECT IDENTIFIER ::= { tripMIB 2 } tripMIBNotifObjects OBJECT IDENTIFIER ::= { tripMIB 3 } Zinman, et al. Standards Track [Page 8] RFC 3872 MIB for TRIP September 2004 tripMIBCompliances OBJECT IDENTIFIER ::= { tripMIBConformance 1 } tripMIBGroups OBJECT IDENTIFIER ::= { tripMIBConformance 2 } -- -- tripCfgTable -- tripCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF TripCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the common configuration objects applicable to all TRIP applications referenced by the applIndex. Each row represents those objects for a particular TRIP LS present in this system. The instances of TRIP LS's are uniquely identified by the applIndex. The objects in this table SHOULD be nonVolatile and survive a reboot." ::= { tripMIBObjects 1 } tripCfgEntry OBJECT-TYPE SYNTAX TripCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common configuration." INDEX { applIndex } ::= { tripCfgTable 1 } TripCfgEntry ::= SEQUENCE { tripCfgProtocolVersion TripProtocolVersion, tripCfgItad TripItad, tripCfgIdentifier TripId, tripCfgAdminStatus INTEGER, tripCfgOperStatus INTEGER, tripCfgAddrIAddrType InetAddressType, tripCfgAddr InetAddress, tripCfgPort InetPortNumber, tripCfgMinItadOriginationInterval Unsigned32, tripCfgMinRouteAdvertisementInterval Unsigned32, tripCfgMaxPurgeTime Unsigned32, tripCfgDisableTime Unsigned32, tripCfgSendReceiveMode TripSendReceiveMode, tripCfgStorage StorageType } Zinman, et al. Standards Track [Page 9] RFC 3872 MIB for TRIP September 2004 tripCfgProtocolVersion OBJECT-TYPE SYNTAX TripProtocolVersion MAX-ACCESS read-only STATUS current DESCRIPTION "This object will reflect the version of TRIP supported by this system. It follows the same format as TRIP version information contained in the TRIP messages generated by this TRIP entity." REFERENCE "RFC 3219, section 4.2." ::= { tripCfgEntry 1 } tripCfgItad OBJECT-TYPE SYNTAX TripItad MAX-ACCESS read-write STATUS current DESCRIPTION "The Internet Telephony Administrative domain (ITAD) of this LS." ::= { tripCfgEntry 2 } tripCfgIdentifier OBJECT-TYPE SYNTAX TripId MAX-ACCESS read-only STATUS current DESCRIPTION "The object that identifies this TRIP Client." ::= { tripCfgEntry 3 } tripCfgAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired TRIP state. up(1) : Set the application to normal operation. down(2): Set the application to a state where it will not process TRIP messages. Setting this object should be reflected in tripCfgOperStatus. If an unknown error occurs tripCfgOperStatus will return unknown(0)." Zinman, et al. Standards Track [Page 10] RFC 3872 MIB for TRIP September 2004 ::= { tripCfgEntry 4 } tripCfgOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(0), up(1), down(2), faulty(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the TRIP protocol. unknown(0): The operating status of the application is unknown. up(1): The application is operating normally, and is ready to process (receive and issue) TRIP requests and responses. down(2): The application is currently not processing TRIP messages. This occurs if the TRIP application is in an initialization state or if tripCfgAdminStatus is set to down(2). faulty(3): The application is not operating normally due to a fault in the system. If tripCfgAdminStatus is down(2) then tripOperStatus SHOULD be down(2). If tripAdminStatus is changed to up(1) then tripOperStatus SHOULD change to up(1) if there is no fault that prevents the TRIP protocol from moving to the up(1) state." ::= { tripCfgEntry 5 } tripCfgAddrIAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet Address of the tripAddr." REFERENCE "RFC 3291, section 3." ::= { tripCfgEntry 6 } tripCfgAddr OBJECT-TYPE SYNTAX InetAddress Zinman, et al. Standards Track [Page 11] RFC 3872 MIB for TRIP September 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "The network address of the local LS that the peer connects to. The type of address depends on the object tripCfgAddrIAddrType. The type of this address is determined by the value of the tripCfgAddrIAddrType object." REFERENCE "RFC 3291, section 3." ::= { tripCfgEntry 7 } tripCfgPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-write STATUS current DESCRIPTION "The local tcp/udp port on the local LS that the peer connects to." ::= { tripCfgEntry 8 } tripCfgMinItadOriginationInterval OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum amount of time that MUST elapse between advertisement of the update message that reports changes within the LS's own ITAD." DEFVAL { 30 } ::= { tripCfgEntry 9 } tripCfgMinRouteAdvertisementInterval OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies minimal interval between successive advertisements to a particular destination from an LS." DEFVAL { 30 } ::= { tripCfgEntry 10 } tripCfgMaxPurgeTime OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) UNITS "Seconds" MAX-ACCESS read-write Zinman, et al. Standards Track [Page 12] RFC 3872 MIB for TRIP September 2004 STATUS current DESCRIPTION "Indicates the interval that the LS MUST maintain routes marked as withdrawn in its database." DEFVAL { 10 } ::= { tripCfgEntry 11 } tripCfgDisableTime OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the interval that the TRIP module of the LS MUST be disabled while routes originated by this LS with high sequence numbers can be removed." DEFVAL { 180 } ::= { tripCfgEntry 12 } tripCfgSendReceiveMode OBJECT-TYPE SYNTAX TripSendReceiveMode MAX-ACCESS read-only STATUS current DESCRIPTION "The operational mode of the TRIP entity running on this system." ::= { tripCfgEntry 13 } tripCfgStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { tripCfgEntry 14 } -- -- TripRouteTypeTable -- tripRouteTypeTable OBJECT-TYPE SYNTAX SEQUENCE OF TripRouteTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Zinman, et al. Standards Track [Page 13] RFC 3872 MIB for TRIP September 2004 "The TRIP peer Route Type table contains one entry per supported protocol - address family pair. The objects in this table are volatile and are refreshed after a reboot." ::= { tripMIBObjects 2 } tripRouteTypeEntry OBJECT-TYPE SYNTAX TripRouteTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information about the route type that a particular TRIP entity supports. Each entry represents information about either the local or a remote LS peer. The object tripRouteTypePeer is used to distinguish this. In the case of a local LS, the address/port information will reflect the values configured in tripCfgTable. In the case of a remote peer, the address/port information will reflect the values of an entry in the tripPeerTable. Implementation need to be aware that if the size of tripRouteTypeAddr exceeds 111 sub-IDs, then OIDs of column instances in this table will have more than 128 sub-IDs and cannot be accessed using SNMPv1, SNMPv2c, or snmpv3." INDEX { applIndex, tripRouteTypeAddrInetType, tripRouteTypeAddr, tripRouteTypePort, tripRouteTypeProtocolId, tripRouteTypeAddrFamilyId } ::= { tripRouteTypeTable 1 } TripRouteTypeEntry ::= SEQUENCE { tripRouteTypeAddrInetType InetAddressType, tripRouteTypeAddr InetAddress, tripRouteTypePort InetPortNumber, tripRouteTypeProtocolId TripAppProtocol, tripRouteTypeAddrFamilyId TripAddressFamily, tripRouteTypePeer INTEGER } tripRouteTypeAddrInetType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of Inet Address of the tripRouteTypeAddr." REFERENCE Zinman, et al. Standards Track [Page 14] RFC 3872 MIB for TRIP September 2004 "RFC 3291, section 3." ::= { tripRouteTypeEntry 1 } tripRouteTypeAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address of this entry's TRIP peer LS. The type of this address is determined by the value of the tripRouteTypeAddrInetType object." REFERENCE "RFC 3291, section 3." ::= { tripRouteTypeEntry 2 } tripRouteTypePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The port for the TCP connection between this and an associated TRIP peer." ::= { tripRouteTypeEntry 3 } tripRouteTypeProtocolId OBJECT-TYPE SYNTAX TripAppProtocol MAX-ACCESS not-accessible STATUS current DESCRIPTION "The object identifier of a protocol that the associated peer is using." ::= { tripRouteTypeEntry 4 } tripRouteTypeAddrFamilyId OBJECT-TYPE SYNTAX TripAddressFamily MAX-ACCESS not-accessible STATUS current DESCRIPTION "The object identifier of an address family that the associated peer belongs to." ::= { tripRouteTypeEntry 5 } tripRouteTypePeer OBJECT-TYPE SYNTAX INTEGER { local(1), remote(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this entry is Zinman, et al. Standards Track [Page 15] RFC 3872 MIB for TRIP September 2004 associated with a 'local' or 'remote' LS peer." ::= { tripRouteTypeEntry 6 } -- -- tripSupportedCommunityTable -- tripSupportedCommunityTable OBJECT-TYPE SYNTAX SEQUENCE OF TripSupportedCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The list of TRIP communities that this LS supports. A TRIP community is a group of destinations that share common properties. The TRIP Supported Communities entry is used to group destinations so that the routing decision can be based on the identity of the group." REFERENCE "RFC 3219, section 5.9" ::= { tripMIBObjects 3 } tripSupportedCommunityEntry OBJECT-TYPE SYNTAX TripSupportedCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information about a community. A TRIP community is a group of destinations that share some common property. This attribute is used so that routing decisions can be based on the identity of the group." INDEX { applIndex, tripSupportedCommunityId } ::= { tripSupportedCommunityTable 1 } TripSupportedCommunityEntry ::= SEQUENCE { tripSupportedCommunityId TripCommunityId, tripSupportedCommunityItad TripItad, tripSupportedCommunityStorage StorageType, tripSupportedCommunityRowStatus RowStatus } tripSupportedCommunityId OBJECT-TYPE SYNTAX TripCommunityId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the supported Community." Zinman, et al. Standards Track [Page 16] RFC 3872 MIB for TRIP September 2004 ::= { tripSupportedCommunityEntry 1 } tripSupportedCommunityItad OBJECT-TYPE SYNTAX TripItad MAX-ACCESS read-create STATUS current DESCRIPTION "The ITAD of the community." ::= { tripSupportedCommunityEntry 2 } tripSupportedCommunityStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write- access to any columnar objects in the row. It is not a requirement that this storage be non volatile." DEFVAL { nonVolatile } ::= { tripSupportedCommunityEntry 3 } tripSupportedCommunityRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status of the entry. This object is REQUIRED to create or delete rows by a manager. A value for tripSupportedCommunityItad MUST be set for row creation to be successful. If the instance already exists for a particular applIndex, the row create operation will fail. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { tripSupportedCommunityEntry 4 } -- -- TripPeerTable -- tripPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF TripPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The TRIP peer table. This table contains one entry per TRIP peer, and information about the connection with Zinman, et al. Standards Track [Page 17] RFC 3872 MIB for TRIP September 2004 the peer." ::= { tripMIBObjects 4 } tripPeerEntry OBJECT-TYPE SYNTAX TripPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information about the connection with a TRIP peer. Implementation need to be aware that if the size of tripPeerRemoteAddr exceeds 113 sub-IDs, then OIDs of column instances in this table will have more than 128 sub-IDs and cannot be accessed using SNMPv1, SNMPv2c, or snmpv3." INDEX { applIndex, tripPeerRemoteAddrInetType, tripPeerRemoteAddr, tripPeerRemotePort } ::= {tripPeerTable 1} TripPeerEntry ::= SEQUENCE { tripPeerRemoteAddrInetType InetAddressType, tripPeerRemoteAddr InetAddress, tripPeerRemotePort InetPortNumber, tripPeerIdentifier TripId, tripPeerState INTEGER, tripPeerAdminStatus INTEGER, tripPeerNegotiatedVersion TripProtocolVersion, tripPeerSendReceiveMode TripSendReceiveMode, tripPeerRemoteItad TripItad, tripPeerConnectRetryInterval Unsigned32, tripPeerMaxRetryInterval Unsigned32, tripPeerHoldTime Unsigned32, tripPeerKeepAlive Unsigned32, tripPeerHoldTimeConfigured Unsigned32, tripPeerKeepAliveConfigured Unsigned32, tripPeerMaxPurgeTime Unsigned32, tripPeerDisableTime Unsigned32, tripPeerLearned TruthValue, tripPeerStorage StorageType, tripPeerRowStatus RowStatus } tripPeerRemoteAddrInetType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible Zinman, et al. Standards Track [Page 18] RFC 3872 MIB for TRIP September 2004 STATUS current DESCRIPTION "The type of Inet Address of the tripPeerRemoteAddr." REFERENCE "RFC 3291, section 3." ::= { tripPeerEntry 1 } tripPeerRemoteAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of this entry's TRIP peer LS. The type of this address is determined by the value of the tripPeerRemoteAddrInetType object." REFERENCE "RFC 3291, section 3." ::= { tripPeerEntry 2 } tripPeerRemotePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port for the TCP connection between the TRIP peers." ::= { tripPeerEntry 3 } tripPeerIdentifier OBJECT-TYPE SYNTAX TripId MAX-ACCESS read-only STATUS current DESCRIPTION "TRIP identifier of the peer." ::= { tripPeerEntry 4 } tripPeerState OBJECT-TYPE SYNTAX INTEGER { idle(1), connect(2), active(3), openSent(4), openConfirm(5), established(6) } MAX-ACCESS read-only STATUS current DESCRIPTION Zinman, et al. Standards Track [Page 19] RFC 3872 MIB for TRIP September 2004 "TRIP Peer Finite State Machine state. idle(1) : The initial state. Local LS refuses all incoming connections. No application resources are allocated to processing information about the remote peer. connect(2) : Local LS waiting for a transport protocol connection to be completed to the peer, and is listening for inbound transport connections from the peer. active(3) : Local LS is listening for an inbound connection from the peer, but is not in the process of initiating a connection to the remote peer. openSent(4) : Local LS has sent an OPEN message to its peer and is waiting for an OPEN message from the remote peer. openConfirm(5): Local LS has sent an OPEN message to the remote peer, received an OPEN message from the remote peer, and sent a KEEPALIVE message in response to the OPEN. The local LS is now waiting for a KEEPALIVE message or a NOTIFICATION message in response to its OPEN message. established(6): LS can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer." ::= { tripPeerEntry 5 } tripPeerAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to affect the TRIP connection state. up(1) : Allow a connection with the peer LS. down(2) : disconnect the connection from the peer LS and do not allow any further connections to this Zinman, et al. Standards Track [Page 20] RFC 3872 MIB for TRIP September 2004 peer. If this value is set to down(2) then tripPeerState will have the value of idle(1)." DEFVAL { up } ::= { tripPeerEntry 6 } tripPeerNegotiatedVersion OBJECT-TYPE SYNTAX TripProtocolVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The negotiated version of TRIP running between this local entity and this peer." ::= { tripPeerEntry 7 } tripPeerSendReceiveMode OBJECT-TYPE SYNTAX TripSendReceiveMode MAX-ACCESS read-only STATUS current DESCRIPTION "The operational mode of this peer." ::= { tripPeerEntry 8 } tripPeerRemoteItad OBJECT-TYPE SYNTAX TripItad MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet Telephony Administrative domain of this peer." ::= { tripPeerEntry 9 } tripPeerConnectRetryInterval OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the initial amount of time that will elapse between connection retry. This value SHOULD double after each attempt up to the value of tripPeerMaxRetryInterval. This value MUST always be less than or equal to the value of tripPeerMaxRetryInterval. Attempts to set this value higher than the max retry will not be allowed." DEFVAL { 120 } ::= { tripPeerEntry 10 } Zinman, et al. Standards Track [Page 21] RFC 3872 MIB for TRIP September 2004 tripPeerMaxRetryInterval OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum amount of time that will elapse between connection retries. Once the value of tripPeerConnectRetryInterval has reached this value, no more retries will be attempted. Attempts to set this value lower than the retry interval SHOULD not be allowed." DEFVAL { 360 } ::= { tripPeerEntry 11 } tripPeerHoldTime OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) UNITS "Seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time interval in seconds for the hold timer that is established with the peer. The value of this object is the smaller of the values in tripPeerHoldTimeConfigured and the hold time received in the open message." ::= { tripPeerEntry 12 } tripPeerKeepAlive OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) UNITS "Seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the amount of time that MUST elapse between keep alive messages. This value is negotiated with the remote when a connection is established." ::= { tripPeerEntry 13 } tripPeerHoldTimeConfigured OBJECT-TYPE SYNTAX Unsigned32 (0 | 3..65535) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum time that MAY elapse between the receipt of successive keepalive or update message. A value of 0 means that keepalive or update messages will not be Zinman, et al. Standards Track [Page 22] RFC 3872 MIB for TRIP September 2004 sent." DEFVAL { 240 } ::= { tripPeerEntry 14 } tripPeerKeepAliveConfigured OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the amount of time that MUST elapse between keep alive messages." DEFVAL { 30 } ::= { tripPeerEntry 15 } tripPeerMaxPurgeTime OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the interval that the LS MUST maintain routes marked as withdrawn in its database." DEFVAL { 10 } ::= { tripPeerEntry 16 } tripPeerDisableTime OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Indicate the interval that the TRIP module of the remote peer LS MUST be disabled while routes originated by the local LS with high sequence numbers can be removed." DEFVAL { 180 } ::= { tripPeerEntry 17 } tripPeerLearned OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this entry was learned or configured." DEFVAL { false } ::= { tripPeerEntry 18 } Zinman, et al. Standards Track [Page 23] RFC 3872 MIB for TRIP September 2004 tripPeerStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write- access to any columnar objects in the row. It is not a requirement that this storage be non volatile." DEFVAL { nonVolatile } ::= { tripPeerEntry 19 } tripPeerRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status of the entry. This object is REQUIRED to create or delete rows remotely by a manager. If the instance already exists for a particular applIndex, the row create operation will fail. The value of this object has no effect on whether other objects in this conceptual row can be modified. Entries in this table can be learned by the TRIP application, or provisioned through this table." ::= { tripPeerEntry 20 } -- -- TripPeerStatisticsTable -- tripPeerStatisticsTable OBJECT-TYPE SYNTAX SEQUENCE OF TripPeerStatisticsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The TRIP peer stats table. This table contains one entry per remote TRIP peer, and statistics related to the connection with the remote peer. The objects in this table are volatile." ::= { tripMIBObjects 5 } tripPeerStatisticsEntry OBJECT-TYPE SYNTAX TripPeerStatisticsEntry MAX-ACCESS not-accessible STATUS current Zinman, et al. Standards Track [Page 24] RFC 3872 MIB for TRIP September 2004 DESCRIPTION "Entry containing information about the connection with a TRIP peer." AUGMENTS { tripPeerEntry } ::= { tripPeerStatisticsTable 1 } TripPeerStatisticsEntry ::= SEQUENCE { tripPeerInUpdates Counter32, tripPeerOutUpdates Counter32, tripPeerInTotalMessages Counter32, tripPeerOutTotalMessages Counter32, tripPeerFsmEstablishedTransitions Counter32, tripPeerFsmEstablishedTime DateAndTime, tripPeerInUpdateElapsedTime TimeInterval, tripPeerStateChangeTime TimeStamp } tripPeerInUpdates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of TRIP update messages received from this remote peer since the last restart of this location server." ::= { tripPeerStatisticsEntry 1 } tripPeerOutUpdates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of TRIP update messages sent to this remote peer since the last restart of this LS." ::= { tripPeerStatisticsEntry 2 } tripPeerInTotalMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of TRIP messages received from the remote peer on this connection since the last restart of this LS." ::= { tripPeerStatisticsEntry 3 } tripPeerOutTotalMessages OBJECT-TYPE SYNTAX Counter32 Zinman, et al. Standards Track [Page 25] RFC 3872 MIB for TRIP September 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of outgoing TRIP messages sent to the remote peer since the last restart of this LS." ::= { tripPeerStatisticsEntry 4 } tripPeerFsmEstablishedTransitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the remote peer has transitioned into the established state since the last restart of this LS." ::= { tripPeerStatisticsEntry 5 } tripPeerFsmEstablishedTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the time and date that this remote peer entered the 'established' state." ::= { tripPeerStatisticsEntry 6 } tripPeerInUpdateElapsedTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Elapsed time in hundredths of seconds since the last TRIP update message was received from this remote peer." ::= { tripPeerStatisticsEntry 7 } tripPeerStateChangeTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last state change of tripPeerState took place." ::= { tripPeerStatisticsEntry 8 } -- TRIP Received Route Table. This table contains -- all routes from all sources. Each entry consists -- of a route and its associated path attributes. Zinman, et al. Standards Track [Page 26] RFC 3872 MIB for TRIP September 2004 tripRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF TripRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The TRIP route table containing information about reachable routes that are to be added to service by the receiving LS. The objects in this table are volatile and are refreshed when this LS rediscovers its route table." ::= { tripMIBObjects 6 } tripRouteEntry OBJECT-TYPE SYNTAX TripRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a route to a called destination." INDEX { applIndex, tripRouteAppProtocol, tripRouteAddressFamily, tripRouteAddress, tripRoutePeer } ::= { tripRouteTable 1 } TripRouteEntry ::= SEQUENCE { tripRouteAppProtocol TripAppProtocol, tripRouteAddressFamily TripAddressFamily, tripRouteAddress OCTET STRING, tripRoutePeer TripId, tripRouteTRIBMask BITS, tripRouteAddressSequenceNumber Unsigned32, tripRouteAddressOriginatorId TripId, tripRouteNextHopServerIAddrType InetAddressType, tripRouteNextHopServer InetAddress, tripRouteNextHopServerPort InetPortNumber, tripRouteNextHopServerItad TripItad, tripRouteMultiExitDisc Unsigned32, tripRouteLocalPref Unsigned32, tripRouteAdvertisementPath OCTET STRING, tripRouteRoutedPath OCTET STRING, tripRouteAtomicAggregate TruthValue, tripRouteUnknown OCTET STRING, tripRouteWithdrawn TruthValue, tripRouteConverted TruthValue, tripRouteReceivedTime TimeStamp } Zinman, et al. Standards Track [Page 27] RFC 3872 MIB for TRIP September 2004 tripRouteAppProtocol OBJECT-TYPE SYNTAX TripAppProtocol MAX-ACCESS not-accessible STATUS current DESCRIPTION "The protocol for which this entry of the routing table is maintained." ::= { tripRouteEntry 1 } tripRouteAddressFamily OBJECT-TYPE SYNTAX TripAddressFamily MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the type of address for the destination route." ::= { tripRouteEntry 2 } tripRouteAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..105)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is the address (prefix) of the family type given by Address Family of the destination. It is the prefix of addresses reachable from this gateway via the next hop server. The SIZE value of 105 has been assigned due to the sub identifier of object types length limitation as defined in SMIv2." REFERENCE "RFC 3219, section 5.1.1.1." ::= { tripRouteEntry 3 } tripRoutePeer OBJECT-TYPE SYNTAX TripId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the peer where the route information was learned." ::= { tripRouteEntry 4 } tripRouteTRIBMask OBJECT-TYPE SYNTAX BITS { adjTribIns(0), extTrib(1), locTrib(2), adjTribOut(3) Zinman, et al. Standards Track [Page 28] RFC 3872 MIB for TRIP September 2004 } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates which Telephony Routing Information Base (TRIB) this entry belongs to. This is a bit-map of possible types. If the bit has a value of 1, then the entry is a member of the corresponding TRIB type. If the bit has a value of 0 then the entry is not a member of the TRIP type. The various bit positions are: 0 adjTribIns The entry is of type adj-TRIBs-ins, stores routing information that has been learned from inbound UPDATE messages. 1 extTrib The entry is of type ext-TRIB, the best route for a given destination. 2 locTrib The entry is of type loc-TRIB contains the local TRIP routing information that the LS has selected. 3 adjTribOut The entry is of type adj-TRIBs-out, stores the information that the local LS has selected for advertisement to its external peers." REFERENCE "RFC 3291, section 3.5." ::= { tripRouteEntry 5 } tripRouteAddressSequenceNumber OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the version of the destination route originated by the LS identified by tripRouteAddressOriginatorId intra-domain attribute." ::= { tripRouteEntry 6 } tripRouteAddressOriginatorId OBJECT-TYPE SYNTAX TripId MAX-ACCESS read-only STATUS current DESCRIPTION "This is an intra-domain attribute indicating the internal LS that originated the route into the ITAD." ::= { tripRouteEntry 7 } Zinman, et al. Standards Track [Page 29] RFC 3872 MIB for TRIP September 2004 tripRouteNextHopServerIAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet Address of the tripRouteNextHopServer." REFERENCE "RFC 3291, section 3." ::= { tripRouteEntry 8 } tripRouteNextHopServer OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the next hop that messages of a given protocol destined for tripRouteAddress SHOULD be sent to. The type of this address is determined by the value of the tripRouteNextHopServerIAddrType object." ::= { tripRouteEntry 9 } tripRouteNextHopServerPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The port of the next hop server that this route will use." ::= { tripRouteEntry 10 } tripRouteNextHopServerItad OBJECT-TYPE SYNTAX TripItad MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the domain of the next hop." ::= { tripRouteEntry 11 } tripRouteMultiExitDisc OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The Multiple Exit Discriminator allows an LS to discriminate between, and indicate preference for, otherwise similar routes to a neighbouring domain. A higher value represents a more preferred routing object." Zinman, et al. Standards Track [Page 30] RFC 3872 MIB for TRIP September 2004 REFERENCE "RFC 3219, section 5.8" ::= { tripRouteEntry 12 } tripRouteLocalPref OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicated the local LS's degree of preference for an advertised route destination." REFERENCE "RFC 3219, section 4.3.4.7" ::= { tripRouteEntry 13 } tripRouteAdvertisementPath OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..252)) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the sequence of domains through which this advertisement has passed. This object is probably best represented as sequence of TripItads. For SMI compatibility, though, it is represented as an OCTET STRING. This object is a sequence of ITADs where each set of 4 octets corresponds to a TRIP ITAD in network byte order." REFERENCE "RFC 3219, section 4.3.4.4" ::= { tripRouteEntry 14 } tripRouteRoutedPath OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4..252)) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the ITADs through which messages sent using this route would pass. These are a subset of tripRouteAdvertisementPath. This object is probably best represented as sequence of TripItads. For SMI compatibility, though, it is represented as OCTET STRING. This object is a sequence of ITADs where each set of 4 octets corresponds to a TRIP ITAD in network byte order." REFERENCE "RFC 3219, section 4.3.4.5" Zinman, et al. Standards Track [Page 31] RFC 3872 MIB for TRIP September 2004 ::= { tripRouteEntry 15 } tripRouteAtomicAggregate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates that a route MAY traverse domains not listed in tripRouteRoutedPath. If an LS selects the less specific route from a set of overlapping routes, then this value returns TRUE." REFERENCE "RFC 3219, section 4.3.4.6" ::= { tripRouteEntry 16 } tripRouteUnknown OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains one or more attributes that were not understood, and because they were transitive, were dropped during aggregation. They take the format of a triple , of variable length. If no attributes were dropped, this returns an OCTET STRING of size 0." REFERENCE "RFC 3219, sections 4.3.1, 4.3.2.3" ::= { tripRouteEntry 17 } tripRouteWithdrawn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates if this route is to be removed from service by the receiving LS." ::= { tripRouteEntry 18 } tripRouteConverted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates if this route has been converted to a different application protocol than it had originally." ::= { tripRouteEntry 19 } Zinman, et al. Standards Track [Page 32] RFC 3872 MIB for TRIP September 2004 tripRouteReceivedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this route was received." ::= { tripRouteEntry 20 } -- -- TRIP Received Route Community Table. -- tripRouteCommunityTable OBJECT-TYPE SYNTAX SEQUENCE OF TripRouteCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing a list of TRIP communities associated with a route. Each instance of tripRouteTypeEntry that has the tripRouteTypePeer object set to remote(2) has an instance in the tripRouteTable as a parent. The objects in this table are volatile and are refreshed after a reboot." REFERENCE "RFC 3219, section 5.9." ::= { tripMIBObjects 7 } tripRouteCommunityEntry OBJECT-TYPE SYNTAX TripRouteCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about communities associated with a route. An entry with a tripRouteAddress of 00 and a tripRoutePeer of 0 refers to the local LS." INDEX { applIndex, tripRouteAppProtocol, tripRouteAddressFamily, tripRouteAddress, tripRoutePeer, tripRouteCommunityId } ::= { tripRouteCommunityTable 1 } TripRouteCommunityEntry ::= SEQUENCE { tripRouteCommunityId TripCommunityId, tripRouteCommunityItad TripItad } Zinman, et al. Standards Track [Page 33] RFC 3872 MIB for TRIP September 2004 tripRouteCommunityId OBJECT-TYPE SYNTAX TripCommunityId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The community identifier." ::= { tripRouteCommunityEntry 1 } tripRouteCommunityItad OBJECT-TYPE SYNTAX TripItad MAX-ACCESS read-only STATUS current DESCRIPTION "The ITAD associated with this community." ::= { tripRouteCommunityEntry 2 } -- -- tripItadTopologyTable -- tripItadTopologyTable OBJECT-TYPE SYNTAX SEQUENCE OF TripItadTopologyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The sequence of link connections between peers within an ITAD. The objects in this table are volatile and are refreshed after a reboot." ::= { tripMIBObjects 8 } tripItadTopologyEntry OBJECT-TYPE SYNTAX TripItadTopologyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a peer of the LS identified by tripItadTopologyOrigId." INDEX { applIndex, tripItadTopologyOrigId } ::= { tripItadTopologyTable 1 } TripItadTopologyEntry ::= SEQUENCE { tripItadTopologyOrigId TripId, tripItadTopologySeqNum Unsigned32 } tripItadTopologyOrigId OBJECT-TYPE SYNTAX TripId MAX-ACCESS not-accessible Zinman, et al. Standards Track [Page 34] RFC 3872 MIB for TRIP September 2004 STATUS current DESCRIPTION "Indicates the internal LS that originated the ITAD topology information into the ITAD." ::= { tripItadTopologyEntry 1 } tripItadTopologySeqNum OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the version of the ITAD topology originated by the LS identified by tripItadTopologyOrigId." ::= { tripItadTopologyEntry 2 } -- -- tripItadTopologyIdTable -- tripItadTopologyIdTable OBJECT-TYPE SYNTAX SEQUENCE OF TripItadTopologyIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The list of other LS's within the ITAD domain that the LS identified by tripItadTopologyOrigId is currently peering. Each instance of tripItadTopologyIdEntry has an instance in the tripItadTopologyTable as a parent. The objects in this table are volatile and are refreshed after a reboot." ::= { tripMIBObjects 9 } tripItadTopologyIdEntry OBJECT-TYPE SYNTAX TripItadTopologyIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a peer to the LS identified by tripItadTopologyOrigId." INDEX { applIndex, tripItadTopologyOrigId, tripItadTopologyId } ::= { tripItadTopologyIdTable 1 } TripItadTopologyIdEntry ::= SEQUENCE { tripItadTopologyId TripId } Zinman, et al. Standards Track [Page 35] RFC 3872 MIB for TRIP September 2004 tripItadTopologyId OBJECT-TYPE SYNTAX TripId MAX-ACCESS read-only STATUS current DESCRIPTION "The index into this entry. Indicates the other location servers within the ITAD domain that this LS identified by tripItadTopologyOrigId is currently peering." ::= { tripItadTopologyIdEntry 1 } -- -- Notification objects -- tripNotifApplIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the application Index. It is used to bind this notification with a specific instance of TRIP entity." REFERENCE "RFC 2788, section 3." ::= { tripMIBNotifObjects 1 } tripNotifPeerAddrInetType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The type of Inet Address of the tripNotifPeerAddr." REFERENCE "RFC 3291, section 3." ::= { tripMIBNotifObjects 2 } tripNotifPeerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The IP address of this entry's TRIP peer LS. This object contains the value of tripPeerRemoteAddr. The type of this address is determined by the value of the tripNotifPeerAddrInetType object." REFERENCE "RFC 3291, section 3." ::= { tripMIBNotifObjects 3 } Zinman, et al. Standards Track [Page 36] RFC 3872 MIB for TRIP September 2004 tripNotifPeerErrCode OBJECT-TYPE SYNTAX INTEGER { messageHeader(1), openMessage(2), updateMessage(3), holdTimerExpired(4), finiteStateMachine(5), cease(6), tripNotification(7) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Notification message of TRIP error. The meaning of this value is applicable to the following functions: messageHeader(1) - All errors detected while processing the TRIP message header. openMessage(2) - All errors detected while processing the OPEN message. updateMessage(3) - All errors detected while processing the UPDATE message. holdTimerExpired(4) - A notification generated when the hold timer expires. finiteStateMachine(5) - All errors detected by the TRIP Finite State Machine. cease(6) - Any fatal error condition that the rest of the values do not cover. tripNotification(7) - Any error encountered while sending a notification message." ::= { tripMIBNotifObjects 4 } tripNotifPeerErrSubcode OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The sub error code associated with error code. The Zinman, et al. Standards Track [Page 37] RFC 3872 MIB for TRIP September 2004 meaning of this value is dependent on the value of tripNotifPeerErrCode. Message Header (1) Error Subcodes: 1 - Bad Message Length. 2 - Bad Message Type. OPEN Message (2) Error Subcodes: 1 - Unsupported Version Number. 2 - Bad Peer ITAD. 3 - Bad TRIP Identifier. 4 - Unsupported Optional Parameter. 5 - Unacceptable Hold Time. 6 - Unsupported Capability. 7 - Capability Mismatch. UPDATE Message (3) Error Subcodes: 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Mandatory Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid Attribute." ::= { tripMIBNotifObjects 5 } -- -- Notifications -- tripConnectionEstablished NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr } STATUS current DESCRIPTION "The TRIP Connection Established event is generated when the TRIP finite state machine enters the ESTABLISHED state." ::= { tripMIBNotifications 1 } tripConnectionDropped NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr } STATUS current DESCRIPTION "The TRIP Connection Dropped event is generated when the Zinman, et al. Standards Track [Page 38] RFC 3872 MIB for TRIP September 2004 TRIP finite state machine leaves the ESTABLISHED state." ::= { tripMIBNotifications 2 } tripFSM NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr, tripNotifPeerErrCode, tripNotifPeerErrSubcode, tripPeerState } STATUS current DESCRIPTION "The trip FSM Event is generated when any error is detected by the TRIP Finite State Machine." ::= { tripMIBNotifications 3 } tripOpenMessageError NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr, tripNotifPeerErrCode, tripNotifPeerErrSubcode, tripPeerState } STATUS current DESCRIPTION "Errors detected while processing the OPEN message." ::= { tripMIBNotifications 4 } tripUpdateMessageError NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr, tripNotifPeerErrCode, tripNotifPeerErrSubcode, tripPeerState } STATUS current DESCRIPTION "Errors detected while processing the UPDATE message." ::= { tripMIBNotifications 5 } tripHoldTimerExpired NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr, tripNotifPeerErrCode, Zinman, et al. Standards Track [Page 39] RFC 3872 MIB for TRIP September 2004 tripNotifPeerErrSubcode, tripPeerState } STATUS current DESCRIPTION "The system does not receive successive messages within the period specified by the negotiated Hold Time." ::= { tripMIBNotifications 6 } tripConnectionCollision NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex } STATUS current DESCRIPTION "A pair of LSs tried to simultaneously to establish a transport connection to each other." ::= { tripMIBNotifications 7 } tripCease NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr, tripNotifPeerErrCode, tripNotifPeerErrSubcode, tripPeerState } STATUS current DESCRIPTION "A TRIP peer MAY choose at any given time to close its TRIP connection by sending this notification message. However, the Cease notification message MUST NOT be used when a fatal error occurs." ::= { tripMIBNotifications 8 } tripNotificationErr NOTIFICATION-TYPE OBJECTS { tripNotifApplIndex } STATUS current DESCRIPTION "Generated if there is an error detected in a TRIP notification message sent with another cause. Note that the TRIP notification referred to in this object is not an SNMP notification, it is a specific message described in the TRIP specification." REFERENCE "RFC 3219, section 6.4." ::= { tripMIBNotifications 9 } -- Zinman, et al. Standards Track [Page 40] RFC 3872 MIB for TRIP September 2004 -- Compliance Statements -- tripMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for TRIP entities that implement this MIB module in read-write mode, such that it can be used for both monitoring and configuring the TRIP entity. There is one INDEX object that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there is a compliance requirement, expressed in OBJECT clause form in this description: -- OBJECT tripRouteTypeAddrInetType -- SYNTAX InetAddressType (ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)) -- DESCRIPTION -- This MIB requires support for global and -- non-global ipv4 and ipv6 addresses. -- -- OBJECT tripRouteTypeAddr -- SYNTAX InetAddress (SIZE (4 | 8 | 16 | 20)) -- DESCRIPTION -- This MIB requires support for global and -- non-global IPv4 and IPv6 addresses. -- " MODULE -- this module MANDATORY-GROUPS { tripConfigGroup, tripPeerTableConfigGroup, tripRouteGroup, tripItadTopologyGroup, tripPeerTableStatsGroup } GROUP tripNotificationGroup DESCRIPTION "This group is OPTIONAL. A TRIP entity can choose not to send any notifications. If this group is implemented, the tripNotifObjectGroup MUST also be implemented." GROUP tripNotifObjectGroup DESCRIPTION "This group is OPTIONAL. A TRIP entity can choose not to send any notifications. If this group is implemented, Zinman, et al. Standards Track [Page 41] RFC 3872 MIB for TRIP September 2004 the tripNotificationGroup MUST also be implemented." OBJECT tripSupportedCommunityRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT tripPeerRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." MODULE NETWORK-SERVICES-MIB MANDATORY-GROUPS { applRFC2788Group } ::= { tripMIBCompliances 1 } tripMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for TRIP entities that implement this MIB module in read only mode. Such TRIP entities can then only be monitored, but not be configured via this MIB module. In read-only mode, the manager will not be able to add, remove or modify rows to any table, however the TRIP application may modify, remove or add rows to a table. There is one INDEX object that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there is a compliance requirement, expressed in OBJECT clause form in this description: -- OBJECT tripRouteTypeAddrInetType -- SYNTAX InetAddressType (ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)) -- DESCRIPTION -- This MIB requires support for global and -- non-global ipv4 and ipv6 addresses. -- -- OBJECT tripRouteTypeAddr -- SYNTAX InetAddress (SIZE (4 | 8 | 16 | 20)) -- DESCRIPTION -- This MIB requires support for global and Zinman, et al. Standards Track [Page 42] RFC 3872 MIB for TRIP September 2004 -- non-global IPv4 and IPv6 addresses. -- " MODULE -- this module MANDATORY-GROUPS { tripConfigGroup, tripPeerTableConfigGroup, tripRouteGroup, tripItadTopologyGroup, tripPeerTableStatsGroup } GROUP tripNotificationGroup DESCRIPTION "This group is OPTIONAL. A TRIP entity can choose not to send any notifications. If this group is implemented, the tripNotifObjectGroup MUST also be implemented." GROUP tripNotifObjectGroup DESCRIPTION "This group is OPTIONAL. A TRIP entity can choose not to send any notifications. If this group is implemented, the tripNotificationGroup MUST also be implemented." OBJECT tripCfgItad MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripCfgAdminStatus MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when implemented in read-only mode." OBJECT tripCfgPort MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripCfgMinItadOriginationInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripCfgMinRouteAdvertisementInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripCfgMaxPurgeTime Zinman, et al. Standards Track [Page 43] RFC 3872 MIB for TRIP September 2004 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripCfgDisableTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripCfgStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripSupportedCommunityItad MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripSupportedCommunityStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripSupportedCommunityRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT tripPeerAdminStatus MIN-ACCESS not-accessible DESCRIPTION "Object is not needed when implemented in read-only mode." OBJECT tripPeerConnectRetryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripPeerMaxRetryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripPeerHoldTimeConfigured MIN-ACCESS read-only Zinman, et al. Standards Track [Page 44] RFC 3872 MIB for TRIP September 2004 DESCRIPTION "Write access is not required." OBJECT tripPeerKeepAliveConfigured MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripPeerMaxPurgeTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripPeerDisableTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripPeerStorage MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tripPeerRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." MODULE NETWORK-SERVICES-MIB MANDATORY-GROUPS { applRFC2788Group } ::= { tripMIBCompliances 2 } -- -- Object and event conformance groups -- tripConfigGroup OBJECT-GROUP OBJECTS { tripCfgProtocolVersion, tripCfgItad, tripCfgIdentifier, tripCfgOperStatus, tripCfgAdminStatus, tripCfgAddrIAddrType, tripCfgAddr, tripCfgPort, Zinman, et al. Standards Track [Page 45] RFC 3872 MIB for TRIP September 2004 tripCfgMinItadOriginationInterval, tripCfgMinRouteAdvertisementInterval, tripCfgMaxPurgeTime, tripCfgDisableTime, tripCfgSendReceiveMode, tripCfgStorage, tripSupportedCommunityItad, tripSupportedCommunityStorage, tripRouteTypePeer, tripSupportedCommunityRowStatus } STATUS current DESCRIPTION "The global objects for configuring trip." ::= { tripMIBGroups 1 } tripPeerTableConfigGroup OBJECT-GROUP OBJECTS { tripPeerIdentifier, tripPeerState, tripPeerAdminStatus, tripPeerNegotiatedVersion, tripPeerSendReceiveMode, tripPeerRemoteItad, tripPeerConnectRetryInterval, tripPeerMaxRetryInterval, tripPeerHoldTime, tripPeerKeepAlive, tripPeerHoldTimeConfigured, tripPeerKeepAliveConfigured, tripPeerMaxPurgeTime, tripPeerDisableTime, tripPeerLearned, tripPeerStorage, tripPeerRowStatus } STATUS current DESCRIPTION "The global objects for configuring the TRIP peer table." ::= { tripMIBGroups 2 } tripPeerTableStatsGroup OBJECT-GROUP OBJECTS { tripPeerInUpdates, tripPeerOutUpdates, tripPeerInTotalMessages, Zinman, et al. Standards Track [Page 46] RFC 3872 MIB for TRIP September 2004 tripPeerOutTotalMessages, tripPeerFsmEstablishedTransitions, tripPeerFsmEstablishedTime, tripPeerInUpdateElapsedTime, tripPeerStateChangeTime } STATUS current DESCRIPTION "The global statistics the TRIP peer table." ::= { tripMIBGroups 3 } tripRouteGroup OBJECT-GROUP OBJECTS { tripRouteTRIBMask, tripRouteAddressSequenceNumber, tripRouteAddressOriginatorId, tripRouteNextHopServerIAddrType, tripRouteNextHopServer, tripRouteNextHopServerPort, tripRouteNextHopServerItad, tripRouteMultiExitDisc, tripRouteLocalPref, tripRouteAdvertisementPath, tripRouteRoutedPath, tripRouteAtomicAggregate, tripRouteUnknown, tripRouteWithdrawn, tripRouteConverted, tripRouteReceivedTime, tripRouteCommunityItad } STATUS current DESCRIPTION "The global objects for configuring route attribute." ::= { tripMIBGroups 4 } tripItadTopologyGroup OBJECT-GROUP OBJECTS { tripItadTopologySeqNum, tripItadTopologyId } STATUS current DESCRIPTION "The objects that define the TRIP ITAD topology." ::= { tripMIBGroups 5 } tripNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { Zinman, et al. Standards Track [Page 47] RFC 3872 MIB for TRIP September 2004 tripConnectionEstablished, tripConnectionDropped, tripFSM, tripOpenMessageError, tripUpdateMessageError, tripHoldTimerExpired, tripConnectionCollision, tripCease, tripNotificationErr } STATUS current DESCRIPTION "A collection of notifications defined for TRIP." ::= { tripMIBGroups 6 } tripNotifObjectGroup OBJECT-GROUP OBJECTS { tripNotifApplIndex, tripNotifPeerAddrInetType, tripNotifPeerAddr, tripNotifPeerErrCode, tripNotifPeerErrSubcode } STATUS current DESCRIPTION "The collection of objects that specify information for TRIP notifications." ::= { tripMIBGroups 7 } END 7. Security Considerations The managed objects in this MIB module contain sensitive information since, collectively, they allow tracing and influencing of connections in TRIP devices and provide information of their connection characteristics. As such, improper manipulation of the objects represented by this MIB module MAY result in denial of service to a large number of available routes. There are a number of management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. Such objects MAY be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects include: Zinman, et al. Standards Track [Page 48] RFC 3872 MIB for TRIP September 2004 tripCfgItad: Improper setting of tripCfgItad value can make all peer connections drop and not be re-established. tripCfgAdminStatus: Improper setting of tripCfgAdminStatus from up to down will cause the TRIP Location Server stop processing TRIP messages. tripCfgPort: Improper setting of tripCfgPort can cause the failure of a peer establishing a connection. tripCfgMinItadOriginationInterval, tripCfgMinRouteAdvertisementInterval: Improper configuration of these values MAY adversely affect local and global convergence of the routes advertised by this TRIP Location Server. tripPeerAdminStatus: Improper setting of tripPeerAdminStatus from up to down can cause significant disruption of the connectivity to the destination via the applicable remote TRIP Location Server peer. tripPeerConnectRetryInterval,tripPeerMaxRetryInterval: Improper configuration of these values can cause connections to be disrupted for extremely long time periods when otherwise they would be restored in a relatively short period of time. tripPeerHoldTimeConfigured, tripPeerKeepAliveConfigured: Improper configuration of these value can make TRIP peer sessions more fragile and less resilient to denial of service attacks. There are a number of managed objects in this MIB module that contain sensitive information regarding the operation of a network. For example, a TRIP Location Server peer's local and remote addresses might be sensitive for ISPs who want to keep interface addresses on TRIP Location Server confidential so as to prevent TRIP Location Server addresses used for a denial of service attack or address spoofing. Therefore, it is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. Zinman, et al. Standards Track [Page 49] RFC 3872 MIB for TRIP September 2004 SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that the implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2788] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC 2788, March 2000. [RFC3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002. [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Zinman, et al. Standards Track [Page 50] RFC 3872 MIB for TRIP September 2004 8.2. Informative References [RFC1657] Willis, S., Burruss, J., and J. Chu, Ed., "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. [RFC1771] Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 9. Acknowledgments The authors wish to thank Bert Wijnen, Dan Romascanu, and Jonathan Rosenberg for their insightful comments and suggestions. Thanks to Kevin Lingle for his invaluable comments, help with MIB things and great ideas. Zinman, et al. Standards Track [Page 51] RFC 3872 MIB for TRIP September 2004 10. Authors' Addresses David Zinman Editor 265 Ridley Blvd Toronto ON M5M 4N8 Canada Phone: +1 416 433 4298 EMail: dzinman@rogers.com David Walker Sedna Wireless Inc. 495 March Road, Suite 500 Ottawa, ON K2K 3G1 Canada Phone: +1 613 878 8142 EMail: david.walker@sedna-wireless.com Jianping Jiang Syndesis Limited 30 Fulton Way Richmond Hill, ON L4B 1J5 Canada Phone: +1 905 886-7818 x2515 EMail: jjiang@syndesis.com Zinman, et al. Standards Track [Page 52] RFC 3872 MIB for TRIP September 2004 11. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Zinman, et al. Standards Track [Page 53] snmp-mibs-downloader-1.1/mibrfcs/rfc3873.txt0000644000000000000000000024074311402176071015600 0ustar Network Working Group J. Pastor Request for Comments: 3873 M. Belinchon Category: Standards Track Ericsson September 2004 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications. This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. MIB Structure. . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. SCTP Objects . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. SCTP Statistics. . . . . . . . . . . . . . . . . 4 3.1.2. SCTP Parameters. . . . . . . . . . . . . . . . . 5 3.1.3. MIB Tables . . . . . . . . . . . . . . . . . . . 5 3.1.3.1. Association Table. . . . . . . . . . . 5 3.1.3.2. Reverse Lookup Table . . . . . . . . . 8 3.2. Conformance. . . . . . . . . . . . . . . . . . . . . . . 9 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 9 Pastor & Belinchon Standards Track [Page 1] RFC 3873 SCTP MIB using SMIv2 September 2004 5. Compiling Notes. . . . . . . . . . . . . . . . . . . . . . . . 42 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Normative References . . . . . . . . . . . . . . . . . . 42 6.2. Informative References . . . . . . . . . . . . . . . . . 43 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 44 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 45 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 46 1. Introduction This memo defines the Management Information Base (MIB) module which describes managed objects for implementations of the SCTP. The document starts with a brief description of the SNMP framework and continues with the MIB explanation and security consideration sections among others. The managed objects in this MIB module are based on [RFC2012] update: "Management Information Base for the Transmission Control Protocol (TCP)" referred as [TCPMIB] (work in progress), and RFC 3291 "Textual Conventions for Internet Network Addresses" [RFC3291]. Terms related to the SCTP architecture are explained in [RFC2960]. Other specific abbreviations are listed below. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Abbreviations DNS - Domain Name System IANA - Internet Assigned Numbers Authority IETF - Internet Engineering Task Force IP - Internet Protocol MIB - Management Information Base RFC - Request For Comments RTO - Retransmission Time Out SCTP - Stream Control Transmission Protocol SMI - Structure of Management Information SNMP - Simple Network Management Protocol TCB - Transmission Control Block TCP - Transmission Control Protocol Pastor & Belinchon Standards Track [Page 2] RFC 3873 SCTP MIB using SMIv2 September 2004 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. MIB Structure This chapter explains the main objects this MIB defines. A detailed view of the MIB structure with the OID values is below. MIB-2 {1 3 6 1 2 1} +--(104)sctpMIB | +--(1) sctpObjects | | | +--(1) sctpStats | | | | | +-- | | | +--(2)sctpParameters | | | | | +-- | | | +--(3) sctpAssocTable | | | +--(4) sctpAssocLocalAddrTable | | | +--(5) sctpAssocRemAddrTable | | | +--(6) sctpLookupLocalPortTable | | | +--(7) sctpLookupRemPortTable | | | +--(8) sctpLookupRemHostNameTable | | | +--(9) sctpLookupRemPrimIPAddrTable | | | +--(10) sctpLookupRemIPAddrTable Pastor & Belinchon Standards Track [Page 3] RFC 3873 SCTP MIB using SMIv2 September 2004 | | +--(2)sctpMibConformance | +--(1) sctpMibCompliances | | | +--(1) sctpMibCompliance | +--(2) sctpMibGroups | +--(1) sctpLayerParamsGroup | +--(2) sctpStatsGroup | +--(3) sctpPerAssocParamsGroup | +--(4) sctpInverseGroup The main groups are explained further in the MIB definition. 3.1. SCTP Objects This branch contains the SCTP statistics and general parameters (both of them scalars) and the SCTP MIB tables. 3.1.1. SCTP Statistics The SCTP MIB includes both Counter32s and Counter64s to deal with statistics. Counter64s are used for those counters, which are likely to wrap around in less than one hour, according to [RFC2863]. In addition Gauge32 is also used. 3.1.1.1. State-Related Statistics These statistics are based on the TCP model, but adapted to the SCTP states. They store the number of successful association attempts, how many associations have been initiated by the local or the remote SCTP layer, and the number of associations terminated in a graceful (by means of SHUTDOWN procedure) or ungraceful way (by means of CLOSE procedure). 3.1.1.2. Statistics for traffic Measurements This set of objects specifies statistics related to the whole SCTP layer. There are, e.g., statistics related to both SCTP packets and SCTP chunks. Pastor & Belinchon Standards Track [Page 4] RFC 3873 SCTP MIB using SMIv2 September 2004 Statistics related to a specific association, or local/remote IP addresses are defined inside their associated table. 3.1.2. SCTP Parameters This section of the MIB contains the general variables for the SCTP protocol. Maximum, minimum, initial and default values are listed here. SCTP RTO mechanism definition is based on the TCP MIB [TCPMIB]. In SCTP, only options 'other' and 'vanj' are valid since SCTP defines Van Jacobson's algorithm (vanj) as the one to be used to calculate RTO. 'Other' is left for future use. 3.1.3. MIB Tables There are several tables included in the SCTP MIB. The first group deals with the SCTP association variables and is composed of a main and two extended tables. The second group is a bunch of tables used to perform reverse lookups. It is NOT possible to create rows in any table (sctpAssocTable, sctpAssocLocalAddrTable, sctpRemAddrTable and Reverse Lookup tables) using SNMP. It is NOT possible to delete rows in any table using SNMP except in sctpAssocTable under the particular conditions explained below. 3.1.3.1. Association Table The sctpAssocTable is the main MIB table, where all the association related information is stored on a per association basis. It is structured according to expanded tables. The main table is called sctpAssocTable and is indexed by sctpAssocId (the association identification). This is a value that uniquely identifies an association. The MIB does not restrict what value must be written here, however it must be unique within the table. The sctpAssoc index is also shared by two more tables: - sctpAssocLocalAddrTable: to store the local IP address(es). - sctpAssocRemAddrTable: to store the remote addresses and the per-remote-address related information. Entries in the sctpAssocTable are created when trying to establish the association, i.e., when sending the COOKIE-ECHO message (originating side) or the COOKIE-ACK message (server side). At this point, i.e., at established state, all entry fields are filled in with valid values. Pastor & Belinchon Standards Track [Page 5] RFC 3873 SCTP MIB using SMIv2 September 2004 Note: The following representation is a conceptual mode of describing the relationship between the tables in this MIB. Note that the real relationship of the tables is by sharing an index, so tables are not truly within tables. Every entry is explained when defining the corresponding objects in the MIB. mib-2 {1 3 6 1 2 1} +--(104)sctpMIB | +--(1) sctpObjects | | . . . . | +--(3) sctpAssocTable | | | +--(1) sctpAssocId (index) | | | +--(2) sctpAssocRemHostName | | | +--(3) sctpAssocLocalPort | | | +--(4) sctpAssocRemPort | | | +--(5) sctpAssocRemPrimAddrType | | | +--(6) sctpAssocRemPrimAddr | | | +--(7) sctpAssocHeartBeatInterval | | | +--(8) sctpAssocState | | | +--(9) sctpAssocInStreams | | | +--(10) sctpAssocOutStreams | | | +--(11) sctpAssocMaxRetr | | | +--(12) sctpAssocPrimProcess | | | +--(13) sctpAssocT1expireds | | | +--(14) sctpAssocT2expireds | | | +--(15) sctpAssocRtxChunks | | | +--(16) sctpAssocStartTime | | Pastor & Belinchon Standards Track [Page 6] RFC 3873 SCTP MIB using SMIv2 September 2004 | +--(17) sctpAssocDiscontinuityTime | | +--(4) sctpAssocLocalAddrTable | | | |--(-) sctpAssocId (shared index) | | | +--(1) sctpAssocLocalAddrType(index) | | | +--(2) sctpAssocLocalAddr (index) | | | +--(3) sctpAssocLocalAddrStartTime | | +--(5) sctpAssocRemAddrTable | | | |--(-) sctpAssocId (shared index) | | | +--(1) sctpAssocRemAddrType (index) . | . +--(2) sctpAssocRemAddr (index) . | +--(3) sctpAssocRemAddrActive | +--(4) sctpAssocRemAddrHBActive | +--(5) sctpAssocRemAddrRTO | +--(6) sctpAssocRemAddrMaxPathRtx | +--(7) sctpAssocRemAddrRtx | +--(8) sctpAssocRemAddrStartTime Both sctpAssocLocalAddrTable and sctpAssocRemAddrTable are indexed by addresses. 'Addr' and 'AddrType' use the syntax InetAddress and InetAddressType defined in the Textual Conventions for Internet Network Address (RFC3291). The InetAddressType TC has codepoints for unknown, IPv4, IPv6, non-global IPv4, non-global IPv6, and DNS addresses, but only the IPv4 and IPv6 address types are required to be supported by implementations of this MIB module. Implementations that connect multiple zones are expected to support the non-global IPv4 and non-global IPv6 address types as well. Note that DNS addresses are not used in this MIB module. They are always resolved to the on-the-wire form prior to connection setup, and the on-the-wire form is what appears in the MIB objects. Pastor & Belinchon Standards Track [Page 7] RFC 3873 SCTP MIB using SMIv2 September 2004 The sctpAssocLocalAddrTable table will have as many entries as local IP addresses have been defined for the association. The sctpAssocRemAddrTable table will contain as many entries as remote IP addresses are known to reach the peer. For the multihoming concept see reference RFC2960. To keep the name of the remote peer (when provided by the peer at initialization time), an entry has been created in the sctpAssocTable called sctpAssocRemHostName. When no DNS name is provided by the remote endpoint, this value will be NULL (zero-length string). Otherwise, the received DNS name will be stored here. If it is necessary to abort an existing association, the value deleteTCB(9) must be written in the variable sctpAssocState. That is the only way to delete rows in any of the mentioned tables. 3.1.3.2. Reverse Lookup Table There are five reverse lookup tables to help management applications efficiently access conceptual rows in other tables. These tables allow management applications to avoid expensive tree walks through large numbers of associations. All of these tables are optional. If these tables are implemented, an entry in them must be created after the entry in the main table (sctpAssocTable) associated with it has been created. This ensures that the field indexing the lookup table exists. The defined reverse lookup tables allow for performing a lookup using the following variables: - Local Port: It allows a management application to find all the associations that use a specific local port - Remote Port: It allows a management application to find all the associations that use a specific remote port - Remote Host Name: It allows a management application to find all the associations with a specific host name. - Remote Primary IP Address: It allows a management application to find all the associations that use a specific remote IP address as primary. - Remote IP address: a management application to find all the associations that use a specific remote IP address. As an example the picture below shows the table to look up by local port. Pastor & Belinchon Standards Track [Page 8] RFC 3873 SCTP MIB using SMIv2 September 2004 MIB-2 {1 3 6 1 2 1} +--(104)sctpMIB | +--(1) sctpObjects | | . . . . | | | +--(6) sctpLookupLocalPortTable | | | . . +--(-) sctpAssocLocalPort (shared index) . . | +--(-) sctpAssocId (shared index) | +--(1) sctpLookupLocalPortStartTime It is not possible for the operator to either create or delete rows in these tables. The rows in this table will dynamically appear and be removed as the corresponding entries in sctpAssocTable are. 3.2. Conformance The conformance section recommends all the inverse lookup tables in this MIB as optional. General layer and per association parameters and statistics are considered mandatory. IP addresses use the global IPv4 and global IPv6 address formats. Unknown value and DNS name formats are not used. Names, if present, are stored in the sctpRemoteHostName variable. 4. Definitions SCTP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Gauge32, Counter32, Counter64, mib-2 FROM SNMPv2-SMI -- [RFC2578] TimeStamp, TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC3291] Pastor & Belinchon Standards Track [Page 9] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpMIB MODULE-IDENTITY LAST-UPDATED "200409020000Z" -- 2nd September 2004 ORGANIZATION "IETF SIGTRAN Working Group" CONTACT-INFO " WG EMail: sigtran@ietf.org Web Page: http://www.ietf.org/html.charters/sigtran-charter.html Chair: Lyndon Ong Ciena Corporation 0480 Ridgeview Drive Cupertino, CA 95014 USA Tel: Email: lyong@ciena.com Editors: Maria-Carmen Belinchon R&D Department Ericsson Espana S. A. Via de los Poblados, 13 28033 Madrid Spain Tel: +34 91 339 3535 Email: Maria.C.Belinchon@ericsson.com Jose-Javier Pastor-Balbas R&D Department Ericsson Espana S. A. Via de los Poblados, 13 28033 Madrid Spain Tel: +34 91 339 1397 Email: J.Javier.Pastor@ericsson.com " DESCRIPTION "The MIB module for managing SCTP implementations. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3873; see the RFC itself for full legal notices. " REVISION "200409020000Z" -- 2nd September 2004 DESCRIPTION " Initial version, published as RFC 3873" ::= { mib-2 104 } Pastor & Belinchon Standards Track [Page 10] RFC 3873 SCTP MIB using SMIv2 September 2004 -- the SCTP base variables group sctpObjects OBJECT IDENTIFIER ::= { sctpMIB 1 } sctpStats OBJECT IDENTIFIER ::= { sctpObjects 1 } sctpParams OBJECT IDENTIFIER ::= { sctpObjects 2 } -- STATISTICS -- ********** -- STATE-RELATED STATISTICS sctpCurrEstab OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of associations for which the current state is either ESTABLISHED, SHUTDOWN-RECEIVED or SHUTDOWN-PENDING." REFERENCE "Section 4 in RFC2960 covers the SCTP Association state diagram." ::= { sctpStats 1 } sctpActiveEstabs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that associations have made a direct transition to the ESTABLISHED state from the COOKIE-ECHOED state: COOKIE-ECHOED -> ESTABLISHED. The upper layer initiated the association attempt." REFERENCE "Section 4 in RFC2960 covers the SCTP Association state diagram." ::= { sctpStats 2 } Pastor & Belinchon Standards Track [Page 11] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpPassiveEstabs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that associations have made a direct transition to the ESTABLISHED state from the CLOSED state: CLOSED -> ESTABLISHED. The remote endpoint initiated the association attempt." REFERENCE "Section 4 in RFC2960 covers the SCTP Association state diagram." ::= { sctpStats 3 } sctpAborteds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that associations have made a direct transition to the CLOSED state from any state using the primitive 'ABORT': AnyState --Abort--> CLOSED. Ungraceful termination of the association." REFERENCE "Section 4 in RFC2960 covers the SCTP Association state diagram." ::= { sctpStats 4 } sctpShutdowns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that associations have made a direct transition to the CLOSED state from either the SHUTDOWN-SENT state or the SHUTDOWN-ACK-SENT state. Graceful termination of the association." REFERENCE "Section 4 in RFC2960 covers the SCTP Association state diagram." ::= { sctpStats 5 } Pastor & Belinchon Standards Track [Page 12] RFC 3873 SCTP MIB using SMIv2 September 2004 -- OTHER LAYER STATISTICS sctpOutOfBlues OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of out of the blue packets received by the host. An out of the blue packet is an SCTP packet correctly formed, including the proper checksum, but for which the receiver was unable to identify an appropriate association." REFERENCE "Section 8.4 in RFC2960 deals with the Out-Of-The-Blue (OOTB) packet definition and procedures." ::= { sctpStats 6 } sctpChecksumErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP packets received with an invalid checksum." REFERENCE "The checksum is located at the end of the SCTP packet as per Section 3.1 in RFC2960. RFC3309 updates SCTP to use a 32 bit CRC checksum." ::= { sctpStats 7 } sctpOutCtrlChunks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP control chunks sent (retransmissions are not included). Control chunks are those chunks different from DATA." REFERENCE "Sections 1.3.5 and 1.4 in RFC2960 refer to control chunk as those chunks different from those that contain user information, i.e., DATA chunks." ::= { sctpStats 8 } Pastor & Belinchon Standards Track [Page 13] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpOutOrderChunks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP ordered data chunks sent (retransmissions are not included)." REFERENCE "Section 3.3.1 in RFC2960 defines the ordered data chunk." ::= { sctpStats 9 } sctpOutUnorderChunks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP unordered chunks (data chunks in which the U bit is set to 1) sent (retransmissions are not included)." REFERENCE "Section 3.3.1 in RFC2960 defines the unordered data chunk." ::= { sctpStats 10 } sctpInCtrlChunks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP control chunks received (no duplicate chunks included)." REFERENCE "Sections 1.3.5 and 1.4 in RFC2960 refer to control chunk as those chunks different from those that contain user information, i.e., DATA chunks." ::= { sctpStats 11 } sctpInOrderChunks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP ordered data chunks received (no duplicate chunks included)." Pastor & Belinchon Standards Track [Page 14] RFC 3873 SCTP MIB using SMIv2 September 2004 REFERENCE "Section 3.3.1 in RFC2960 defines the ordered data chunk." ::= { sctpStats 12 } sctpInUnorderChunks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP unordered chunks (data chunks in which the U bit is set to 1) received (no duplicate chunks included)." REFERENCE "Section 3.3.1 in RFC2960 defines the unordered data chunk." ::= { sctpStats 13 } sctpFragUsrMsgs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user messages that have to be fragmented because of the MTU." ::= { sctpStats 14 } sctpReasmUsrMsgs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user messages reassembled, after conversion into DATA chunks." REFERENCE "Section 6.9 in RFC2960 includes a description of the reassembly process." ::= { sctpStats 15 } Pastor & Belinchon Standards Track [Page 15] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpOutSCTPPacks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP packets sent. Retransmitted DATA chunks are included." ::= { sctpStats 16 } sctpInSCTPPacks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCTP packets received. Duplicates are included." ::= { sctpStats 17 } sctpDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this general statistics counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or Counter64 object contained in the SCTP layer statistics (defined below sctpStats branch). If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." REFERENCE "The inclusion of this object is recommended by RFC2578." ::= { sctpStats 18 } -- PROTOCOL GENERAL VARIABLES -- ************************** sctpRtoAlgorithm OBJECT-TYPE SYNTAX INTEGER { other(1), -- Other new one. Future use vanj(2) -- Van Jacobson's algorithm } Pastor & Belinchon Standards Track [Page 16] RFC 3873 SCTP MIB using SMIv2 September 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "The algorithm used to determine the timeout value (T3-rtx) used for re-transmitting unacknowledged chunks." REFERENCE "Section 6.3.1 and 6.3.2 in RFC2960 cover the RTO calculation and retransmission timer rules." DEFVAL {vanj} -- vanj(2) ::= { sctpParams 1 } sctpRtoMin OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum value permitted by a SCTP implementation for the retransmission timeout value, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout value. A retransmission time value of zero means immediate retransmission. The value of this object has to be lower than or equal to stcpRtoMax's value." DEFVAL {1000} -- milliseconds ::= { sctpParams 2 } sctpRtoMax OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value permitted by a SCTP implementation for the retransmission timeout value, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout value. A retransmission time value of zero means immediate re- transmission. Pastor & Belinchon Standards Track [Page 17] RFC 3873 SCTP MIB using SMIv2 September 2004 The value of this object has to be greater than or equal to stcpRtoMin's value." DEFVAL {60000} -- milliseconds ::= { sctpParams 3 } sctpRtoInitial OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The initial value for the retransmission timer. A retransmission time value of zero means immediate re- transmission." DEFVAL {3000} -- milliseconds ::= { sctpParams 4 } sctpMaxAssocs OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The limit on the total number of associations the entity can support. In entities where the maximum number of associations is dynamic, this object should contain the value -1." ::= { sctpParams 5 } sctpValCookieLife OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Valid cookie life in the 4-way start-up handshake procedure." REFERENCE "Section 5.1.3 in RFC2960 explains the cookie generation process. Recommended value is per section 14 in RFC2960." DEFVAL {60000} -- milliseconds ::= { sctpParams 6 } Pastor & Belinchon Standards Track [Page 18] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpMaxInitRetr OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of retransmissions at the start-up phase (INIT and COOKIE ECHO chunks). " REFERENCE "Section 5.1.4, 5.1.6 in RFC2960 refers to Max.Init.Retransmit parameter. Recommended value is per section 14 in RFC2960." DEFVAL {8} -- number of attempts ::= { sctpParams 7 } -- TABLES -- ****** -- the SCTP Association TABLE -- The SCTP association table contains information about each -- association in which the local endpoint is involved. sctpAssocTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpAssocEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing SCTP association-specific information." ::= { sctpObjects 3 } sctpAssocEntry OBJECT-TYPE SYNTAX SctpAssocEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "General common variables and statistics for the whole association." INDEX { sctpAssocId } ::= { sctpAssocTable 1 } Pastor & Belinchon Standards Track [Page 19] RFC 3873 SCTP MIB using SMIv2 September 2004 SctpAssocEntry ::= SEQUENCE { sctpAssocId Unsigned32, sctpAssocRemHostName OCTET STRING, sctpAssocLocalPort InetPortNumber, sctpAssocRemPort InetPortNumber, sctpAssocRemPrimAddrType InetAddressType, sctpAssocRemPrimAddr InetAddress, sctpAssocHeartBeatInterval Unsigned32, sctpAssocState INTEGER, sctpAssocInStreams Unsigned32, sctpAssocOutStreams Unsigned32, sctpAssocMaxRetr Unsigned32, sctpAssocPrimProcess Unsigned32, sctpAssocT1expireds Counter32, -- Statistic sctpAssocT2expireds Counter32, -- Statistic sctpAssocRtxChunks Counter32, -- Statistic sctpAssocStartTime TimeStamp, sctpAssocDiscontinuityTime TimeStamp } sctpAssocId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Association Identification. Value identifying the association. " ::= { sctpAssocEntry 1 } sctpAssocRemHostName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The peer's DNS name. This object needs to have the same format as the encoding in the DNS protocol. This implies that the domain name can be up to 255 octets long, each octet being 0<=x<=255 as value with US-ASCII A-Z having a case insensitive matching. If no DNS domain name was received from the peer at init time (embedded in the INIT or INIT-ACK chunk), this object is meaningless. In such cases the object MUST contain a zero- length string value. Otherwise, it contains the remote host name received at init time." Pastor & Belinchon Standards Track [Page 20] RFC 3873 SCTP MIB using SMIv2 September 2004 ::= { sctpAssocEntry 2 } sctpAssocLocalPort OBJECT-TYPE SYNTAX InetPortNumber (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The local SCTP port number used for this association." ::= { sctpAssocEntry 3 } sctpAssocRemPort OBJECT-TYPE SYNTAX InetPortNumber (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote SCTP port number used for this association." ::= { sctpAssocEntry 4 } sctpAssocRemPrimAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The internet type of primary remote IP address. " ::= { sctpAssocEntry 5 } sctpAssocRemPrimAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The primary remote IP address. The type of this address is determined by the value of sctpAssocRemPrimAddrType. The client side will know this value after INIT_ACK message reception, the server side will know this value when sending INIT_ACK message. However, values will be filled in at established(4) state." ::= { sctpAssocEntry 6 } Pastor & Belinchon Standards Track [Page 21] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpAssocHeartBeatInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The current heartbeat interval.. Zero value means no HeartBeat, even when the concerned sctpAssocRemAddrHBFlag object is true." DEFVAL {30000} -- milliseconds ::= { sctpAssocEntry 7 } sctpAssocState OBJECT-TYPE SYNTAX INTEGER { closed(1), cookieWait(2), cookieEchoed(3), established(4), shutdownPending(5), shutdownSent(6), shutdownReceived(7), shutdownAckSent(8), deleteTCB(9) } MAX-ACCESS read-write STATUS current DESCRIPTION "The state of this SCTP association. As in TCP, deleteTCB(9) is the only value that may be set by a management station. If any other value is received, then the agent must return a wrongValue error. If a management station sets this object to the value deleteTCB(9), then this has the effect of deleting the TCB (as defined in SCTP) of the corresponding association on the managed node, resulting in immediate termination of the association. As an implementation-specific option, an ABORT chunk may be sent from the managed node to the other SCTP endpoint as a result of setting the deleteTCB(9) value. The ABORT chunk implies an ungraceful association shutdown." Pastor & Belinchon Standards Track [Page 22] RFC 3873 SCTP MIB using SMIv2 September 2004 REFERENCE "Section 4 in RFC2960 covers the SCTP Association state diagram." ::= { sctpAssocEntry 8 } sctpAssocInStreams OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Inbound Streams according to the negotiation at association start up." REFERENCE "Section 1.3 in RFC2960 includes a definition of stream. Section 5.1.1 in RFC2960 covers the streams negotiation process." ::= { sctpAssocEntry 9 } sctpAssocOutStreams OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Outbound Streams according to the negotiation at association start up. " REFERENCE "Section 1.3 in RFC2960 includes a definition of stream. Section 5.1.1 in RFC2960 covers the streams negotiation process." ::= { sctpAssocEntry 10 } sctpAssocMaxRetr OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of data retransmissions in the association context. This value is specific for each association and the upper layer can change it by calling the appropriate primitives. This value has to be smaller than the addition of all the maximum number for all the paths (sctpAssocRemAddrMaxPathRtx). Pastor & Belinchon Standards Track [Page 23] RFC 3873 SCTP MIB using SMIv2 September 2004 A value of zero value means no retransmissions." DEFVAL {10} -- number of attempts ::= { sctpAssocEntry 11 } sctpAssocPrimProcess OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the system level process which holds primary responsibility for the SCTP association. Wherever possible, this should be the system's native unique identification number. The special value 0 can be used to indicate that no primary process is known. Note that the value of this object can be used as a pointer into the swRunTable of the HOST-RESOURCES-MIB(if the value is smaller than 2147483647) or into the sysApplElmtRunTable of the SYSAPPL-MIB." ::= { sctpAssocEntry 12 } -- Association Statistics sctpAssocT1expireds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The T1 timer determines how long to wait for an acknowledgement after sending an INIT or COOKIE-ECHO chunk. This object reflects the number of times the T1 timer expires without having received the acknowledgement. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime." REFERENCE "Section 5 in RFC2960." ::= { sctpAssocEntry 13 } sctpAssocT2expireds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Pastor & Belinchon Standards Track [Page 24] RFC 3873 SCTP MIB using SMIv2 September 2004 STATUS current DESCRIPTION "The T2 timer determines how long to wait for an acknowledgement after sending a SHUTDOWN or SHUTDOWN-ACK chunk. This object reflects the number of times that T2- timer expired. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime." REFERENCE "Section 9.2 in RFC2960." ::= { sctpAssocEntry 14 } sctpAssocRtxChunks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "When T3-rtx expires, the DATA chunks that triggered the T3 timer will be re-sent according with the retransmissions rules. Every DATA chunk that was included in the SCTP packet that triggered the T3-rtx timer must be added to the value of this counter. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime." REFERENCE "Section 6 in RFC2960 covers the retransmission process and rules." ::= { sctpAssocEntry 15 } sctpAssocStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time that the association represented by this row enters the ESTABLISHED state, i.e., the sctpAssocState object is set to established(4). The value of this object will be zero: - before the association enters the established(4) state, or Pastor & Belinchon Standards Track [Page 25] RFC 3873 SCTP MIB using SMIv2 September 2004 - if the established(4) state was entered prior to the last re-initialization of the local network management subsystem." ::= { sctpAssocEntry 16 } sctpAssocDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this SCTP association counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or Counter64 object contained in the sctpAssocTable or sctpLocalAddrTable or sctpRemAddrTable. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value. " REFERENCE "The inclusion of this object is recommended by RFC2578." ::= { sctpAssocEntry 17 } -- Expanded tables: Including Multi-home feature -- Local Address TABLE -- ******************* sctpAssocLocalAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpAssocLocalAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Expanded table of sctpAssocTable based on the AssocId index. This table shows data related to each local IP address which is used by this association." ::= { sctpObjects 4 } sctpAssocLocalAddrEntry OBJECT-TYPE SYNTAX SctpAssocLocalAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Local information about the available addresses. There will be an entry for every local IP address defined for this Pastor & Belinchon Standards Track [Page 26] RFC 3873 SCTP MIB using SMIv2 September 2004 association. Implementors need to be aware that if the size of sctpAssocLocalAddr exceeds 114 octets then OIDs of column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { sctpAssocId, -- shared index sctpAssocLocalAddrType, sctpAssocLocalAddr } ::= { sctpAssocLocalAddrTable 1 } SctpAssocLocalAddrEntry ::= SEQUENCE { sctpAssocLocalAddrType InetAddressType, sctpAssocLocalAddr InetAddress, sctpAssocLocalAddrStartTime TimeStamp } sctpAssocLocalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Internet type of local IP address used for this association." ::= { sctpAssocLocalAddrEntry 1 } sctpAssocLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of a local IP address available for this association. The type of this address is determined by the value of sctpAssocLocalAddrType." ::= { sctpAssocLocalAddrEntry 2 } Pastor & Belinchon Standards Track [Page 27] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpAssocLocalAddrStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time that this row was created." ::= { sctpAssocLocalAddrEntry 3 } -- Remote Addresses TABLE -- ********************** sctpAssocRemAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpAssocRemAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Expanded table of sctpAssocTable based on the AssocId index. This table shows data related to each remote peer IP address which is used by this association." ::= { sctpObjects 5 } sctpAssocRemAddrEntry OBJECT-TYPE SYNTAX SctpAssocRemAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the most important variables for every remote IP address. There will be an entry for every remote IP address defined for this association. Implementors need to be aware that if the size of sctpAssocRemAddr exceeds 114 octets then OIDs of column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { sctpAssocId, -- shared index sctpAssocRemAddrType, sctpAssocRemAddr } ::= { sctpAssocRemAddrTable 1 } Pastor & Belinchon Standards Track [Page 28] RFC 3873 SCTP MIB using SMIv2 September 2004 SctpAssocRemAddrEntry ::= SEQUENCE { sctpAssocRemAddrType InetAddressType, sctpAssocRemAddr InetAddress, sctpAssocRemAddrActive TruthValue, sctpAssocRemAddrHBActive TruthValue, sctpAssocRemAddrRTO Unsigned32, sctpAssocRemAddrMaxPathRtx Unsigned32, sctpAssocRemAddrRtx Counter32, -- Statistic sctpAssocRemAddrStartTime TimeStamp } sctpAssocRemAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Internet type of a remote IP address available for this association." ::= { sctpAssocRemAddrEntry 1 } sctpAssocRemAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of a remote IP address available for this association. The type of this address is determined by the value of sctpAssocLocalAddrType." ::= { sctpAssocRemAddrEntry 2 } sctpAssocRemAddrActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object gives information about the reachability of this specific remote IP address. When the object is set to 'true' (1), the remote IP address is understood as Active. Active means that the threshold of no answers received from this IP address has not been reached. Pastor & Belinchon Standards Track [Page 29] RFC 3873 SCTP MIB using SMIv2 September 2004 When the object is set to 'false' (2), the remote IP address is understood as Inactive. Inactive means that either no heartbeat or any other message was received from this address, reaching the threshold defined by the protocol." REFERENCE "The remote transport states are defined as Active and Inactive in the SCTP, RFC2960." ::= { sctpAssocRemAddrEntry 3 } sctpAssocRemAddrHBActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the optional Heartbeat check associated to one destination transport address is activated or not (value equal to true or false, respectively). " ::= { sctpAssocRemAddrEntry 4 } sctpAssocRemAddrRTO OBJECT-TYPE -- T3-rtx- Timer SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The current Retransmission Timeout. T3-rtx timer as defined in the protocol SCTP." REFERENCE "Section 6.3 in RFC2960 deals with the Retransmission Timer Management." ::= { sctpAssocRemAddrEntry 5 } sctpAssocRemAddrMaxPathRtx OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum number of DATA chunks retransmissions allowed to a remote IP address before it is considered inactive, as defined in RFC2960." Pastor & Belinchon Standards Track [Page 30] RFC 3873 SCTP MIB using SMIv2 September 2004 REFERENCE "Section 8.2, 8.3 and 14 in RFC2960." DEFVAL {5} -- number of attempts ::= { sctpAssocRemAddrEntry 6 } -- Remote Address Statistic sctpAssocRemAddrRtx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of DATA chunks retransmissions to this specific IP address. When T3-rtx expires, the DATA chunk that triggered the T3 timer will be re-sent according to the retransmissions rules. Every DATA chunk that is included in a SCTP packet and was transmitted to this specific IP address before, will be included in this counter. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime." ::= { sctpAssocRemAddrEntry 7 } sctpAssocRemAddrStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time that this row was created." ::= { sctpAssocRemAddrEntry 8 } -- ASSOCIATION INVERSE TABLE -- ************************* -- BY LOCAL PORT sctpLookupLocalPortTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpLookupLocalPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "With the use of this table, a list of associations which are Pastor & Belinchon Standards Track [Page 31] RFC 3873 SCTP MIB using SMIv2 September 2004 using the specified local port can be retrieved." ::= { sctpObjects 6 } sctpLookupLocalPortEntry OBJECT-TYPE SYNTAX SctpLookupLocalPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by local port and association ID. Specifying a local port, we would get a list of the associations whose local port is the one specified." INDEX { sctpAssocLocalPort, sctpAssocId } ::= { sctpLookupLocalPortTable 1 } SctpLookupLocalPortEntry::= SEQUENCE { sctpLookupLocalPortStartTime TimeStamp } sctpLookupLocalPortStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table." ::= { sctpLookupLocalPortEntry 1 } -- BY REMOTE PORT sctpLookupRemPortTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpLookupRemPortEntry MAX-ACCESS not-accessible STATUS current Pastor & Belinchon Standards Track [Page 32] RFC 3873 SCTP MIB using SMIv2 September 2004 DESCRIPTION "With the use of this table, a list of associations which are using the specified remote port can be got" ::= { sctpObjects 7 } sctpLookupRemPortEntry OBJECT-TYPE SYNTAX SctpLookupRemPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by remote port and association ID. Specifying a remote port we would get a list of the associations whose local port is the one specified " INDEX { sctpAssocRemPort, sctpAssocId } ::= { sctpLookupRemPortTable 1 } SctpLookupRemPortEntry::= SEQUENCE { sctpLookupRemPortStartTime TimeStamp } sctpLookupRemPortStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table." ::= { sctpLookupRemPortEntry 1 } -- BY REMOTE HOST NAME sctpLookupRemHostNameTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpLookupRemHostNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "With the use of this table, a list of associations with that particular host can be retrieved." Pastor & Belinchon Standards Track [Page 33] RFC 3873 SCTP MIB using SMIv2 September 2004 ::= { sctpObjects 8 } sctpLookupRemHostNameEntry OBJECT-TYPE SYNTAX SctpLookupRemHostNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by remote host name and association ID. Specifying a host name we would get a list of the associations specifying that host name as the remote one. Implementors need to be aware that if the size of sctpAssocRemHostName exceeds 115 octets then OIDs of column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { sctpAssocRemHostName, sctpAssocId } ::= { sctpLookupRemHostNameTable 1 } SctpLookupRemHostNameEntry::= SEQUENCE { sctpLookupRemHostNameStartTime TimeStamp } sctpLookupRemHostNameStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table." ::= { sctpLookupRemHostNameEntry 1 } Pastor & Belinchon Standards Track [Page 34] RFC 3873 SCTP MIB using SMIv2 September 2004 -- BY REMOTE PRIMARY IP ADDRESS sctpLookupRemPrimIPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpLookupRemPrimIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "With the use of this table, a list of associations that have the specified IP address as primary within the remote set of active addresses can be retrieved." ::= { sctpObjects 9 } sctpLookupRemPrimIPAddrEntry OBJECT-TYPE SYNTAX SctpLookupRemPrimIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by primary address and association ID. Specifying a primary address, we would get a list of the associations that have the specified remote IP address marked as primary. Implementors need to be aware that if the size of sctpAssocRemPrimAddr exceeds 114 octets then OIDs of column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { sctpAssocRemPrimAddrType, sctpAssocRemPrimAddr, sctpAssocId } ::= { sctpLookupRemPrimIPAddrTable 1 } SctpLookupRemPrimIPAddrEntry::= SEQUENCE { sctpLookupRemPrimIPAddrStartTime TimeStamp } sctpLookupRemPrimIPAddrStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current Pastor & Belinchon Standards Track [Page 35] RFC 3873 SCTP MIB using SMIv2 September 2004 DESCRIPTION "The value of SysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table." ::= { sctpLookupRemPrimIPAddrEntry 1 } -- BY REMOTE IP ADDRESS sctpLookupRemIPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF SctpLookupRemIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "With the use of this table, a list of associations that have the specified IP address as one of the remote ones can be retrieved. " ::= { sctpObjects 10 } sctpLookupRemIPAddrEntry OBJECT-TYPE SYNTAX SctpLookupRemIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by a remote IP address and association ID. Specifying an IP address we would get a list of the associations that have the specified IP address included within the set of remote IP addresses." INDEX { sctpAssocRemAddrType, sctpAssocRemAddr, sctpAssocId } ::= { sctpLookupRemIPAddrTable 1 } SctpLookupRemIPAddrEntry::= SEQUENCE { sctpLookupRemIPAddrStartTime TimeStamp } Pastor & Belinchon Standards Track [Page 36] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpLookupRemIPAddrStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table." ::= { sctpLookupRemIPAddrEntry 1 } -- 4.1 Conformance Information sctpMibConformance OBJECT IDENTIFIER ::= { sctpMIB 2 } sctpMibCompliances OBJECT IDENTIFIER ::= { sctpMibConformance 1 } sctpMibGroups OBJECT IDENTIFIER ::= { sctpMibConformance 2 } -- 4.1.1 Units of conformance -- -- MODULE GROUPS -- sctpLayerParamsGroup OBJECT-GROUP OBJECTS { sctpRtoAlgorithm, sctpRtoMin, sctpRtoMax, sctpRtoInitial, sctpMaxAssocs, sctpValCookieLife, sctpMaxInitRetr } STATUS current DESCRIPTION "Common parameters for the SCTP layer, i.e., for all the associations. They can usually be referred to as configuration parameters." ::= { sctpMibGroups 1 } Pastor & Belinchon Standards Track [Page 37] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpStatsGroup OBJECT-GROUP OBJECTS { sctpCurrEstab, sctpActiveEstabs, sctpPassiveEstabs, sctpAborteds, sctpShutdowns, sctpOutOfBlues, sctpChecksumErrors, sctpOutCtrlChunks, sctpOutOrderChunks, sctpOutUnorderChunks, sctpInCtrlChunks, sctpInOrderChunks, sctpInUnorderChunks, sctpFragUsrMsgs, sctpReasmUsrMsgs, sctpOutSCTPPacks, sctpInSCTPPacks, sctpDiscontinuityTime, sctpAssocT1expireds, sctpAssocT2expireds, sctpAssocRtxChunks, sctpAssocRemAddrRtx } STATUS current DESCRIPTION "Statistics group. It includes the objects to collect state changes in the SCTP protocol local layer and flow control statistics." ::= { sctpMibGroups 2 } sctpPerAssocParamsGroup OBJECT-GROUP OBJECTS { sctpAssocRemHostName, sctpAssocLocalPort, sctpAssocRemPort, sctpAssocRemPrimAddrType, sctpAssocRemPrimAddr, sctpAssocHeartBeatInterval, sctpAssocState, sctpAssocInStreams, sctpAssocOutStreams, sctpAssocMaxRetr, sctpAssocPrimProcess, sctpAssocStartTime, sctpAssocDiscontinuityTime, Pastor & Belinchon Standards Track [Page 38] RFC 3873 SCTP MIB using SMIv2 September 2004 sctpAssocLocalAddrStartTime, sctpAssocRemAddrActive, sctpAssocRemAddrHBActive, sctpAssocRemAddrRTO, sctpAssocRemAddrMaxPathRtx, sctpAssocRemAddrStartTime } STATUS current DESCRIPTION "The SCTP group of objects to manage per-association parameters. These variables include all the SCTP basic features." ::= { sctpMibGroups 3 } sctpPerAssocStatsGroup OBJECT-GROUP OBJECTS { sctpAssocT1expireds, sctpAssocT2expireds, sctpAssocRtxChunks, sctpAssocRemAddrRtx } STATUS current DESCRIPTION "Per Association Statistics group. It includes the objects to collect flow control statistics per association." ::= { sctpMibGroups 4 } sctpInverseGroup OBJECT-GROUP OBJECTS { sctpLookupLocalPortStartTime, sctpLookupRemPortStartTime, sctpLookupRemHostNameStartTime, sctpLookupRemPrimIPAddrStartTime, sctpLookupRemIPAddrStartTime } STATUS current DESCRIPTION "Objects used in the inverse lookup tables." ::= { sctpMibGroups 5 } Pastor & Belinchon Standards Track [Page 39] RFC 3873 SCTP MIB using SMIv2 September 2004 -- 4.1.2 Compliance Statements -- -- MODULE COMPLIANCES -- sctpMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement this SCTP MIB Module. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which we have the following compliance requirements, expressed in OBJECT clause form in this description clause: -- OBJECT sctpAssocLocalAddrType -- SYNTAX InetAddressType {ipv4(1), ipv6(2)} -- DESCRIPTION -- It is only required to have IPv4 and IPv6 addresses without -- zone indices. -- The address with zone indices is required if an -- implementation can connect multiple zones. -- -- OBJECT sctpAssocLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- An implementation is only required to support globally -- unique IPv4 and IPv6 addresses. -- -- OBJECT sctpAssocRemAddrType -- SYNTAX InetAddressType {ipv4(1), ipv6(2)} -- DESCRIPTION -- It is only required to have IPv4 and IPv6 addresses without -- zone indices. -- The address with zone indices is required if an -- implementation can connect multiple zones. -- -- OBJECT sctpAssocRemAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- An implementation is only required to support globally -- unique IPv4 and IPv6 addresses. -- " -- closes DESCRIPTION clause of MODULE-COMPLIANCE MODULE -- this module Pastor & Belinchon Standards Track [Page 40] RFC 3873 SCTP MIB using SMIv2 September 2004 MANDATORY-GROUPS { sctpLayerParamsGroup, sctpPerAssocParamsGroup, sctpStatsGroup, sctpPerAssocStatsGroup } OBJECT sctpAssocRemPrimAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "It is only required to have IPv4 and IPv6 addresses without zone indices. The address with zone indices is required if an implementation can connect multiple zones." OBJECT sctpAssocRemPrimAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is only required to support globally unique IPv4 and globally unique IPv6 addresses." OBJECT sctpAssocState WRITE-SYNTAX INTEGER { deleteTCB(9) } MIN-ACCESS read-only DESCRIPTION "Only the deleteTCB(9) value MAY be set by a management station at most. A read-only option is also considered to be compliant with this MIB module description." GROUP sctpInverseGroup DESCRIPTION "Objects used in inverse lookup tables. This should be implemented, at the discretion of the implementers, for easier lookups in the association tables" ::= { sctpMibCompliances 1 } END Pastor & Belinchon Standards Track [Page 41] RFC 3873 SCTP MIB using SMIv2 September 2004 5. Compiling Notes When compiling the MIB module warnings similar to the following may occur: - warning: index of row `sctpAssocLocalAddrEntry' can exceed OID size limit by 141 subidentifier(s) - warning: index of row `sctpAssocRemAddrEntry' can exceed OID size limit by 141 subidentifier(s) - warning: index of row `sctpLookupRemHostNameEntry' can exceed OID size limit by 140 subidentifier(s) - warning: index of row `sctpLookupRemPrimIPAddrEntry' can exceed OID size limit by 141 subidentifier(s) - warning: index of row `sctpLookupRemIPAddrEntry' can exceed OID size limit by 141 subidentifier(s) These warnings are due to the fact that the row objects have index objects of type InetAddress or OCTET STRING whose size limit is 255 octets, and if that size limit were reached the names of column instances in those rows would exceed the 128 sub-identifier limit imposed by current versions of the SNMP. Actual limitations for the index object sizes are noted in the conceptual row DESCRIPTION clauses. For the InetAddress index objects these size limits will not be reached with any of the address types in current use. 6. References 6.1. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. Pastor & Belinchon Standards Track [Page 42] RFC 3873 SCTP MIB using SMIv2 September 2004 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002. 6.2. Informative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB- II", STD 17, RFC 1213, March 1991. [RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2", RFC 2012, November 1996. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [VANJ] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988, Stanford, California. [IPv6ARCH] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A., and B. Zill, "IPv6 Scoped Address Architecture", Work in Progress, December 2002. [sctpImplem] Stewart, R., Ong, L., Arias-Rodriguez, I., Caro, A., and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Implementers Guide", Work in Progress, January 2002. [TCPMIB] Fenner, B., McCloghrie, K., Raghunarayan, R., and J. Schoenwalder, "Management Information Base for the Transmission Control Protocol (TCP)", Work in Progress, November 2002. [UDPMIB] Fenner, B., "Management Information Base for User Datagram Protocol (UDP)", Work in Progress, June 2002. [MIBGUIDE] Heard, C.M., "Guidelines for MIB Authors and Reviewers", Work in Progress, February 2003. Pastor & Belinchon Standards Track [Page 43] RFC 3873 SCTP MIB using SMIv2 September 2004 7. Security Considerations There are management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The sctpAssocState object has a MAX-ACCESS clause of read-write, which allows termination of an arbitrary connection. Unauthorized access could cause a denial of service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. Thus, it is important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o The sctpAssocTable, sctpAssocLocalAddressTable, sctpAssocRemAddressTable and the lookup tables contain objects providing information on the active associations on the device, local and peer's IP addresses, the status of these associations and the associated processes. This information may be used by an attacker to launch attacks against known/unknown weakness in certain protocols/applications. o The sctpAssocTable contains objects providing information on local and remote ports objects, that can be used to identify what ports are open on the machine and can thus suggest what attacks are likely to succeed, without the attacker having to run a port scanner. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Pastor & Belinchon Standards Track [Page 44] RFC 3873 SCTP MIB using SMIv2 September 2004 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. The above objects also have privacy implications, i.e., they disclose who is connecting to what hosts. These are sensitive from a perspective of preventing traffic analysis, and also to protect individual privacy. 8. Acknowledgments The authors wish to thank Juergen Schoenwaelder, David Partain, Shawn A. Routhier, Ed Yarwood, John Linton, Shyamal Prasad, Juan-Francisco Martin, Dave Thaler, and Bert Wijnen for their invaluable comments. 9. Authors' Addresses Javier Pastor-Balbas Ericsson Espana S.A. Network Signaling System Management Via de los Poblados 13 Madrid, 28033 Spain Phone: +34-91-339-1397 EMail: J.Javier.Pastor@ericsson.com Maria-Carmen Belinchon Ericsson Espana S.A. Network Signaling System Management Via de los Poblados 13 Madrid, 28033 Spain Phone: +34-91-339-3535 EMail: maria.carmen.belinchon@ericsson.com Pastor & Belinchon Standards Track [Page 45] RFC 3873 SCTP MIB using SMIv2 September 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Pastor & Belinchon Standards Track [Page 46] snmp-mibs-downloader-1.1/mibrfcs/rfc3877.txt0000644000000000000000000044442711402176071015611 0ustar Network Working Group S. Chisholm Request for Comments: 3877 Nortel Networks Category: Standards Track D. Romascanu Avaya September 2004 Alarm Management Information Base (MIB) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. Chisholm & Romascanu Standards Track [Page 1] RFC 3877 Alarm MIB September 2004 Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Alarm Management Framework . . . . . . . . . . . . . . . . . . 4 3.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Alarm Management Architecture. . . . . . . . . . . . . . 5 3.3. Features of this Architecture. . . . . . . . . . . . . . 5 3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Relationship between Alarm and Notifications . . . . . . 9 3.6. Notification Varbind Storage and Reference . . . . . . . 9 3.7. Relation to Notification Log MIB . . . . . . . . . . . . 10 3.8. Relation to Event MIB. . . . . . . . . . . . . . . . . . 10 4. Generic Alarm MIB. . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Definitions. . . . . . . . . . . . . . . . . . . . . . . 15 5. ITU Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2. IANA Considerations. . . . . . . . . . . . . . . . . . . 39 5.3. Textual Conventions. . . . . . . . . . . . . . . . . . . 47 5.4. Definitions. . . . . . . . . . . . . . . . . . . . . . . 49 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.1. Alarms Based on linkUp/linkDown Notifications. . . . . . 59 6.2. Temperature Alarm using generic Notifications. . . . . . 62 6.3. Temperature Alarm without Notifications. . . . . . . . . 63 6.4. Printer MIB Alarm Example. . . . . . . . . . . . . . . . 65 6.5. Rmon Alarm Example . . . . . . . . . . . . . . . . . . . 66 6.6. The Lifetime of an Alarm . . . . . . . . . . . . . . . . 67 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 72 9.2. Informative References . . . . . . . . . . . . . . . . . 73 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 74 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 75 Chisholm & Romascanu Standards Track [Page 2] RFC 3877 Alarm MIB September 2004 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction In traditional SNMP management, problems are detected on an entity either through polling interesting MIB variables, waiting for the entity to send a Notification for a problem, or some combination of the two. This method is somewhat successful, but experience has shown some problems with this approach. Managers monitoring large numbers of entities cannot afford to be polling large numbers of objects on each device. Managers trying to ensure high reliability are unable to accurately determine whether any problems had occurred when they were not monitoring an entity. Finally, it can be time consuming for managers to try to understand the relationships between the various objects they poll, the Notifications they receive and the problems occurring on the entity. Even after detailed analysis they may still be left with an incomplete picture of what problems are occurring. But, it is important for an operator to be able to determine current problems on a system, so they can be fixed. This memo describes a method of using alarm management in SNMP to address these problems. It also provides the necessary MIB objects to support this method. Alarms and other terms related to alarm management are defined in the following sections. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Chisholm & Romascanu Standards Track [Page 3] RFC 3877 Alarm MIB September 2004 3. Alarm Management Framework 3.1. Terminology Error A deviation of a system from normal operation. Fault Lasting error or warning condition. Event Something that happens which may be of interest. A fault, a change in status, crossing a threshold, or an external input to the system, for example. Notification Unsolicited transmission of management information. Alarm Persistent indication of a fault. Alarm State A condition or stage in the existence of an alarm. As a minimum, alarms states are raise and clear. They could also include severity information such as defined by perceived severity in the International Telecommunications Union (ITU) model [M.3100] - cleared, indeterminate, critical, major, minor and warning. Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear. Alarm Clear The detection that the fault indicated by an alarm no longer exists. Active Alarm An alarm which has an alarm state that has been raised, but not cleared. Alarm Detection Point The entity that detected the alarm. Perceived Severity The severity of the alarm as determined by the alarm detection point using the information it has available. Chisholm & Romascanu Standards Track [Page 4] RFC 3877 Alarm MIB September 2004 3.2. Alarm Management Architecture +------------------------------------------------+ | | | +------------------------------------+ | | | Notification Management | | | +------------------------------------+ | | | | +------------------------------------------------+ | | | |<----------------------------------------------+ | | +------------------V-------------+ | | +---------------V-----------+ | | | | RFC 3413 | | | | | SNMP-NOTIFICATION-MIB | | | | +--------+--------------+-+-+ | | | | | | | | | | | +------------------+ | | | | | | | | | | | +----------V--------------+ | | | | | | +--------V---------+ | | | +---------V------------+ | | | | Alarm Modelling | | | | | RFC 3014 | | | | | (descriptions) | | | | | NOTIFICATION-LOG-MIB | | | | +--------+---------+ | | | +----------------------+ | | | | | | | | | | +--------V------------+ | | | +------------------------V-+ | | | Generic: Model- | | | | | RFC 3413 | | | | Active : Specific | | | | | SNMP-TARGET-MIB | | | | Alarms : Extensions | | | | +----------+---------------+ | | +--------+------------+ | | | | | | | | | +------------|-------------------+ +----------|--------------+ | | | | | +------------------+ V Informs & Traps 3.3. Features of this Architecture 3.3.1. Modular Alarm Architecture The subject of alarm management can potentially cover a large number of topics including real-time alarms, historical alarms, alarm correlation, and alarm suppression, to name a few. Within each of these topics, there are a number of established models that could be Chisholm & Romascanu Standards Track [Page 5] RFC 3877 Alarm MIB September 2004 supported. This memo focuses on a subset of this problem space, but describes a modular SNMP alarm management framework. Alarms SHOULD be modelled so Notifications are sent on alarm Clear. The framework defines a generic Alarm MIB that can be supported on its own, or with additional alarm modelling information such as the provided ITU Alarm MIB. In addition, the active alarm tables could also be extended to support additional information about active alarm instances. This framework can also be expanded in the future to support such features as alarm correlation and alarm suppression. This modular architecture means that the cost of supporting alarm management features is proportional to the number of features an implementation supports. 3.3.2. Flexible Alarm Modelling Alarm models document an understanding between a manager and an agent as to what problems will be reported on a system, how these problems will be reported, and what might possibly happen over the lifetime of this problem. The alarm modelling method provided in this memo provides flexibility to support implementations with different modelling requirements. All alarms are modelled as a series of states that are related together using an alarm ID. Alarm states can be modelled using traditional Notifications, generic alarm Notifications, or without the use of Notifications. Alarm states modelled using traditional Notifications would specify a Notification Object Identifier, and optionally an (offset, value) pair of one of the Notification varbinds to identify the state. This alarm state would be entered when the entity generated a Notification that matched this information and the alarm would be added to the active alarm table. This Notification would also get sent on the wire to any destinations, as indicated in the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413]. Alarm states modelled using generic Notifications use the alarmActiveState or alarmClearState Notifications defined in this memo. These alarm states would be entered after being triggered by a stimulus outside the scope of this memo, the alarm would be added to the active alarm table and these generic Notifications would then be sent on the wire to any destinations, as indicated in the SNMP- TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413]. Chisholm & Romascanu Standards Track [Page 6] RFC 3877 Alarm MIB September 2004 Alarm states modelled without any Notifications would be triggered by some stimulus outside the scope of this memo, the alarm would be added to the active alarm table, but no Notifications would be sent to interested managers. 3.3.3. Problem Indication The Alarm MIB provides a means to determine whether a given notification is of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition, information in the alarm model, such as the Notification ID and the description tell exactly what error or warning condition this alarm is indicating. If the ITU-ALARM-MIB is also supported, additional information is provided via the probable cause. 3.3.5. Identifying Resource under Alarm An important goal of alarm management is to ensure that any detected problems get fixed, so it is necessary to know exactly where this problem is occurring. In addition, it is necessary to be able to tell when alarm instances are raised against the same component, as well as to be able to tell what instance of an alarm is cleared by an instance of an alarm clear. The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. It records the relevant information needed to locate the source of the alarm. 3.3.6. Means of obtaining ITU alarm information Alarm Information, as defined in ITU alarm models [M.3100], is optionally available to implementations through the optional support of the ITU-ALARM-MIB. 3.3.7. Configuration of Alarm Models An alarm model can be added and removed during runtime. It can be modified assuming it is not being referenced by any active alarm instance. 3.3.8. Active Alarm Management A list of currently active alarms and supporting statistics on the SNMP entity can be obtained. Chisholm & Romascanu Standards Track [Page 7] RFC 3877 Alarm MIB September 2004 This allows the network management station to find out about any problems that may have occurred before it started managing a particular network element, or while it was out of contact with it. 3.3.9. Distributed Alarm Management All aspects of the Alarm MIB can be supported both on the device experiencing the alarms and on any mid-level managers that might be monitoring such devices. 3.3.10. Historical Alarm Management Some systems may have a requirement that information on alarms that are no longer active is available. This memo provides a clear table to support this requirement. This can also be achieved through the support of the Notification Log MIB [RFC3014] to store alarm state transitions. 3.4. Security Given the nature of VACM, security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC3411] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC3413]. The Alarm MIB has the notion of a named alarm list. By using alarm list names and view-based access control [RFC3415] a network administrator can provide different access for different users. When an application creates an alarm model (indexed in part by the alarm list name) the security credentials of the creator remain associated with that alarm model and constrain what information is allowed to be placed in the active alarm table, the active alarm variable table, the cleared alarm table, and the ITU alarm table. When processing locally-generated Notifications, the managed system MUST use the security credentials associated with each alarm model respectively, and MUST apply the same access control rules as described for a Notification Originator in [RFC3413]. Chisholm & Romascanu Standards Track [Page 8] RFC 3877 Alarm MIB September 2004 The managed system SHOULD NOT apply access control when processing remotely-generated Notifications using the alarm models. In those cases the security of the information in the alarm tables SHOULD be left to the normal, overall access control for those tables. 3.5. Relationship between Alarm and Notifications It is important to understand the relationship between alarms and Notifications, as both are traditional fault management methods. This relationship is modelled using the alarmModelTable to define the alarmModelNotificationId for each alarm state. Not all Notifications signal an alarm state transition. Some Notifications are simply informational in nature, such as those that indicate that a configuration operation has been performed on an entity. These sorts of Notifications would not be represented in the Alarm MIB. The Alarm MIB allows the use of the Notification space as defined in [RFC2578] in order to identify the Notifications that are related with the specific alarm state transitions. However there is no assumption that the respective Notifications must be sent for all or any of the alarm state transitions. It is also possible to model alarms using no Notifications at all. This architecture allows for both the efficient exploitation of the body of defined Notification and for the use of non-Notification based systems. 3.6. Notification Varbind Storage and Reference In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined [RFC1215]. In the case of linkDown trap, the first varbind can unambiguously be identified as ifIndex. With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, which send sysUptime and snmpTrapOID as the first two varbinds, while the SMI in the MIB where the Notification is defined only lists additional varbinds, the meaning of "first varbind" becomes less clear. In the case of the linkDown Notification, referring to the first varbind could potentially be interpreted as either the sysUptime or ifIndex. The varbind storage approach taken in the Alarm MIB is that sysUptime and snmpTrapOID SHALL always be stored in the active alarm variable table as entry 1 and 2 respectively, regardless of whether the transport was the Trap-PDU, the InformRequest-PDU or the SNMPv2- Trap-PDU. If the incoming Notification is an SNMPv1 Trap-PDU then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]. Chisholm & Romascanu Standards Track [Page 9] RFC 3877 Alarm MIB September 2004 The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU need to be considered so the index values of the Trap-PDU and the SMI need be adjusted by two. In the case of linkDown, the third varbind would always be ifIndex. 3.7. Relation to Notification Log MIB The Alarm MIB is intended to complement the Notification Log MIB [RFC3014], but can be used independently. The alarmActiveTable is defined in manner similar to that of the nlmLogTable. This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP. Using the same format as the Notification Log MIB also simplifies operations for systems choosing to implement both MIBs. The object alarmActiveLogPointer points, for each entry in the alarmActiveLogTable, to the log index in the Notification Log MIB, if used. If the Notification Log MIB is supported, it can be monitored by a management system as a hedge against lost alarms. The Notification Log can also be used to support historical alarm management. 3.8. Relationship with the Event MIB During the work and discussions in the Working Group, the issue of the relationship between the MIB modules and the Event MIB [RFC2981] was raised. There is no direct relation or dependency between the Alarm MIB and the Event MIB. Some common terms (like 'event') are being used in both MIB modules, and the user is directed to the sections that define terminology in the two documents for clarification. 4. Generic Alarm MIB 4.1. Overview The ALARM-MIB consists of alarm models and lists of active and cleared alarms. The alarmModelTable contains information that is applicable to all instances of an alarm. It can be populated at start-up with all alarms that could happen on a system or later configured by a management application. It contains all the alarms for a given system. If a Notification is not represented in the alarmModelTable, it is not an alarm state transition. The alarmModelTable provides a Chisholm & Romascanu Standards Track [Page 10] RFC 3877 Alarm MIB September 2004 means of defining the raise/clear and other state transition relationships between alarm states. The alarmModelIndex acts as a unique identifier for an alarm. An alarm model consists of definitions of the possible states an alarm can assume as well as the Object Identifier (OID) of the Notification associated with this alarm state. The object alarmModelState defines the states of an alarm. The alarmActiveTable contains a list of alarms that are currently occurring on a system. It is intended that this table be queried upon device discovery and rediscovery to determine which alarms are currently active on the device. The alarmActiveVariableTable contains the Notification variable bindings associated with the alarms in the alarmActiveTable. The alarmActiveStatsTable contains current and total raised alarm counts as well as the time of the last alarm raise and alarm clears per named alarm list. The alarmClearTable contains recently cleared alarms. It contains up to alarmClearMaximum cleared alarms. The MIB also defines generic alarm Notifications that can be used when there is not an existing applicable Notification to signal the alarm state transition - alarmActiveState and alarmClearState. 4.1.1. Extensibility The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model. Chisholm & Romascanu Standards Track [Page 11] RFC 3877 Alarm MIB September 2004 4.1.2. Problem Indication The problem that each alarm indicates is identified through the Object Identifier of the NotificationId of the state transition, and, optionally, the ITU parameters. alarmModelDescription provides a description of the alarm state suitable for displaying to an operator. 4.1.3. Alarm State Transition Notification The SNMP-TARGET-MIB [RFC3413] provides the ability to specify which managers, if any, receive Notifications of problems. Solutions can therefore use the features of this MIB to change the Notification behaviour of their implementations. Specifying target hosts in this MIB along with specifying notifications in the alarmModelNotificationId would allow Notifications to be logged and sent out to management stations in an architecture as described in section 3.2. Specifying no target hosts in this MIB along with specifying notifications in the alarmModelNotificationId would allow Notifications to be logged but not sent out to management stations in an architecture as described in section 3.2. Regardless of what is defined in the SNMP-TARGET-MIB, specifying { 0 0 } in the alarmModelNotificationId would result in no notifications being logged or sent to management stations as a consequence of this particular alarm state transition. Alarms are modelled by defining all possible states in the alarmModelTable, as well as defining alarmModelNotificationId, alarmModelVarbindIndex, and alarmModelVarbindValue for each of the possible alarm states. Optionally, ituAlarmPerceivedSeverity models the states in terms of ITU perceived severity. 4.1.4. Active Alarm Resource Identifier Resources under alarm can be identified using the alarmActiveResourceId. This OBJECT IDENTIFIER points to an appropriate object to identify the given resource, depending on the type of the resource. The consumer of the alarmActiveResourceId does not necessarily need to know the type of the resource in the resource ID, but if they want to know this, examining the content of the resource ID can derive it - 1.3.6.1.2.1.2.2.1.1.something is an interface, for example. It is therefore good practice to use resource IDs that can be consistently used across technologies, such as ifIndex, entPhysicalIndex or sysApplRunIndex, to minimize the number of resource prefixes a manager interested in a resource type needs to learn. Chisholm & Romascanu Standards Track [Page 12] RFC 3877 Alarm MIB September 2004 Resource ID can be calculated using the alarmModelResourcePrefix, alarmModelVarbindSubtree and the Notification varbinds. This allows for both the managed element to be able to compute and populate the alarmActiveResourceId object and for the manager to be able to determine when two separate alarm instances are referring to the same resource. If alarmModelResourcePrefix has a value of 0.0, then alarmActiveResourceId is simply the variable identifier of the first Notification varbind that matches the prefix defined in alarmModelVarbindSubtree. Otherwise, alarmActiveResourceId is calculated by appending the instance information from the first Notification varbind that matches alarmModelVarbindSubtree to the prefix defined in alarmModelResourcePrefix. The instance information is the portion of the variable identifier following the part that matched alarmModelVarbindSubtree. If no match is found, then alarmActiveResourceId is simply the value of alarmModelResourcePrefix. In addition to this, the variable bindings from the Notifications that signal the alarm state transitions are stored in the active alarm variable table. This allows for implementations familiar with the particular Notifications to implement other forms of resource identification. For Example: A) Consider an alarm modelled using the authenticationFailure [RFC3418] Notification. authenticationFailure NOTIFICATION-TYPE STATUS current DESCRIPTION "An authenticationFailure trap signifies that the SNMPv2 entity, acting in an agent role, has received a protocol message that is not properly authenticated. While all implementations of the SNMPv2 must be capable of generating this trap, the snmpEnableAuthenTraps object indicates whether this trap will be generated." ::= { snmpTraps 5 } To set the resource ID to be usmStats, 1.3.6.1.6.3.15.1.1, configure as follows: alarmModelVarbindSubtree = 0.0 alarmModelResourcePrefix = usmStats (1.3.6.1.6.3.15.1.1) Chisholm & Romascanu Standards Track [Page 13] RFC 3877 Alarm MIB September 2004 B) Consider an alarm modelled using linkDown [RFC2863] linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "" ::= { snmpTraps 3 } To set the resource Id to be the ifIndex, configure as follows: alarmModelVarbindSubtree = ifIndex (1.3.6.1.2.1.2.2.1.1) alarmModelResourcePrefix = 0.0 Alternatively, since ifIndex is the first varbind, the following would also work, but might be less meaningful to a human reader of the MIB table: alarmModelVarbindSubtree = 0.0 alarmModelResourcePrefix = 0.0 C) Consider an alarm modelled using the bgpBackwardTransition [RFC1657] Notification. bgpBackwardTransition NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGPBackwardTransition Event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state." ::= { bgpTraps 2 } To set the resource Id to be the bgpPeerRemoteAddr, the index to the bgpTable, where bgpPeerState resides, configure as follows: alarmModelVarbindSubtree = bgpPeerState (1.3.6.1.2.1.15.3.1.2) alarmModelResourcePrefix = bgpPeerRemoteAddr (1.3.6.1.2.1.15.3.1.7) 4.1.5. Configurable Alarm Models The alarm model table SHOULD be initially populated by the system. The objects in alarmModelTable and ituAlarmTable have a MAX-ACCESS of read-create, which allows managers to modify the alarm models to suit their requirements. Chisholm & Romascanu Standards Track [Page 14] RFC 3877 Alarm MIB September 2004 4.1.6. Active Alarm Management Lists of alarms currently active on an SNMP entity are stored in the alarmActiveTable and, optionally, a model specific alarmTable, e.g., the ituAlarmActiveTable. 4.1.7. Distributed Alarm Management Distributed alarm management can be achieved by support of the Alarm MIB on both the alarm detection point and on the mid-level manager. This is facilitated by the ability to be able to store different named alarm lists. A mid-level manager could create an alarmListName for each of the devices it manages and therefore store separate lists for each device. In addition, the context and IP addresses of the alarm detection point are stored in the alarmActiveTable. 4.2. Definitions ALARM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Gauge32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2, zeroDotZero FROM SNMPv2-SMI -- [RFC2578] DateAndTime, RowStatus, RowPointer, TEXTUAL-CONVENTION FROM SNMPv2-TC -- [RFC2579] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC3291] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] ZeroBasedCounter32 FROM RMON2-MIB; -- [RFC2021] alarmMIB MODULE-IDENTITY LAST-UPDATED "200409090000Z" -- September 09, 2004 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "WG EMail: disman@ietf.org Subscribe: disman-request@ietf.org http://www.ietf.org/html.charters/disman-charter.html Chisholm & Romascanu Standards Track [Page 15] RFC 3877 Alarm MIB September 2004 Chair: Randy Presuhn randy_presuhn@mindspring.com Editors: Sharon Chisholm Nortel Networks PO Box 3511 Station C Ottawa, Ont. K1Y 4H7 Canada schishol@nortelnetworks.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Tel: +972-3-645-8414 Email: dromasca@avaya.com" DESCRIPTION "The MIB module describes a generic solution to model alarms and to store the current list of active alarms. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3877. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html" REVISION "200409090000Z" -- September 09, 2004 DESCRIPTION "Initial version, published as RFC 3877." ::= { mib-2 118 } alarmObjects OBJECT IDENTIFIER ::= { alarmMIB 1 } alarmNotifications OBJECT IDENTIFIER ::= { alarmMIB 0 } alarmModel OBJECT IDENTIFIER ::= { alarmObjects 1 } alarmActive OBJECT IDENTIFIER ::= { alarmObjects 2 } alarmClear OBJECT IDENTIFIER ::= { alarmObjects 3 } -- Textual Conventions -- ResourceId is intended to be a general textual convention -- that can be used outside of the set of MIBs related to -- Alarm Management. Chisholm & Romascanu Standards Track [Page 16] RFC 3877 Alarm MIB September 2004 ResourceId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for this resource. The type of the resource can be determined by looking at the OID that describes the resource. Resources must be identified in a consistent manner. For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity [RFC2737], then this MUST point to an entPhysicalDescr, given that entPhysicalIndex is not accessible. In general, the value is the name of the instance of the first accessible columnar object in the conceptual row of a table that is meaningful for this resource type, which SHOULD be defined in an IETF standard MIB." SYNTAX OBJECT IDENTIFIER -- LocalSnmpEngineOrZeroLenStr is intended to be a general -- textual convention that can be used outside of the set of -- MIBs related to Alarm Management. LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero-length string. The instantiation of this textual convention will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OCTET STRING (SIZE(0 | 5..32)) -- Alarm Model alarmModelLastChanged OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last creation, deletion or modification of an entry in the alarmModelTable. If the number and content of entries has been unchanged since the last re-initialization of the local network management subsystem, then the value of this object MUST be zero." Chisholm & Romascanu Standards Track [Page 17] RFC 3877 Alarm MIB September 2004 ::= { alarmModel 1 } alarmModelTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmModelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about possible alarms on the system, and how they have been modelled." ::= { alarmModel 2 } alarmModelEntry OBJECT-TYPE SYNTAX AlarmModelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm state. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, alarmModelState } ::= { alarmModelTable 1 } AlarmModelEntry ::= SEQUENCE { alarmModelIndex Unsigned32, alarmModelState Unsigned32, alarmModelNotificationId OBJECT IDENTIFIER, alarmModelVarbindIndex Unsigned32, alarmModelVarbindValue Integer32, alarmModelDescription SnmpAdminString, alarmModelSpecificPointer RowPointer, alarmModelVarbindSubtree OBJECT IDENTIFIER, alarmModelResourcePrefix OBJECT IDENTIFIER, alarmModelRowStatus RowStatus } alarmModelIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer that acts as an alarm Id to uniquely identify each alarm within the named alarm list. " ::= { alarmModelEntry 1 } alarmModelState OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current Chisholm & Romascanu Standards Track [Page 18] RFC 3877 Alarm MIB September 2004 DESCRIPTION "A value of 1 MUST indicate a clear alarm state. The value of this object MUST be less than the alarmModelState of more severe alarm states for this alarm. The value of this object MUST be more than the alarmModelState of less severe alarm states for this alarm." ::= { alarmModelEntry 2 } alarmModelNotificationId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifier of this alarm state transition. If there is no notification associated with this alarm state, the value of this object MUST be '0.0'" DEFVAL { zeroDotZero } ::= { alarmModelEntry 3 } alarmModelVarbindIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. Note that the value of alarmModelVarbindIndex acknowledges the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 2 refers to the snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]" DEFVAL { 0 } ::= { alarmModelEntry 4 } alarmModelVarbindValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create Chisholm & Romascanu Standards Track [Page 19] RFC 3877 Alarm MIB September 2004 STATUS current DESCRIPTION "The value that the varbind indicated by alarmModelVarbindIndex takes to indicate that the alarm has entered this state. If alarmModelVarbindIndex has a value of 0, so MUST alarmModelVarbindValue. " DEFVAL { 0 } ::= { alarmModelEntry 5 } alarmModelDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A brief description of this alarm and state suitable to display to operators." DEFVAL { "" } ::= { alarmModelEntry 6 } alarmModelSpecificPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If no additional, model-specific Alarm MIB is supported by the system the value of this object is `0.0'and attempts to set it to any other value MUST be rejected appropriately. When a model-specific Alarm MIB is supported, this object MUST refer to the first accessible object in a corresponding row of the model definition in one of these model-specific MIB and attempts to set this object to { 0 0 } or any other value MUST be rejected appropriately." DEFVAL { zeroDotZero } ::= { alarmModelEntry 7 } alarmModelVarbindSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The name portion of each VarBind in the notification, in order, is compared to the value of this object. If the name is equal to or a subtree of the value of this object, for purposes of computing the value Chisholm & Romascanu Standards Track [Page 20] RFC 3877 Alarm MIB September 2004 of AlarmActiveResourceID the 'prefix' will be the matching portion, and the 'indexes' will be any remainder. The examination of varbinds ends with the first match. If the value of this object is 0.0, then the first varbind, or in the case of v2, the first varbind after the timestamp and the trap OID, will always be matched. " DEFVAL { zeroDotZero } ::= { alarmModelEntry 8 } alarmModelResourcePrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The value of AlarmActiveResourceId is computed by appending any indexes extracted in accordance with the description of alarmModelVarbindSubtree onto the value of this object. If this object's value is 0.0, then the 'prefix' extracted is used instead. " DEFVAL { zeroDotZero } ::= { alarmModelEntry 9 } alarmModelRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. Alarms whose alarmModelRowStatus is not active will not appear in either the alarmActiveTable or the alarmClearTable. Setting this object to notInService cannot be used as an alarm suppression mechanism. Entries that are notInService will disappear as described in RFC2579. This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via an alarmActiveModelPointer. Chisholm & Romascanu Standards Track [Page 21] RFC 3877 Alarm MIB September 2004 As all read-create objects in this table have a DEFVAL clause, there is no requirement that any object be explicitly set before this row can become active. Note that a row consisting only of default values is not very meaningful." ::= { alarmModelEntry 10 } -- Active Alarm Table -- alarmActiveLastChanged OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last creation or deletion of an entry in the alarmActiveTable. If the number of entries has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { alarmActive 1 } alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 UNITS "active alarms" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } alarmActiveTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Active Alarms entries." ::= { alarmActive 2 } alarmActiveEntry OBJECT-TYPE SYNTAX AlarmActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to Chisholm & Romascanu Standards Track [Page 22] RFC 3877 Alarm MIB September 2004 add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." INDEX { alarmListName, alarmActiveDateAndTime, alarmActiveIndex } ::= { alarmActiveTable 1 } AlarmActiveEntry ::= SEQUENCE { alarmListName SnmpAdminString, alarmActiveDateAndTime DateAndTime, alarmActiveIndex Unsigned32, alarmActiveEngineID LocalSnmpEngineOrZeroLenStr, alarmActiveEngineAddressType InetAddressType, alarmActiveEngineAddress InetAddress, alarmActiveContextName SnmpAdminString, alarmActiveVariables Unsigned32, alarmActiveNotificationID OBJECT IDENTIFIER, alarmActiveResourceId ResourceId, alarmActiveDescription SnmpAdminString, alarmActiveLogPointer RowPointer, alarmActiveModelPointer RowPointer, alarmActiveSpecificPointer RowPointer } alarmListName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the list of alarms. This SHOULD be the same as nlmLogName if the Notification Log MIB [RFC3014] is supported. This SHOULD be the same as, or contain as a prefix, the applicable snmpNotifyFilterProfileName if the SNMP-NOTIFICATION-MIB DEFINITIONS [RFC3413] is supported. An implementation may allow multiple named alarm lists, up to some implementation-specific limit (which may be none). A zero-length list name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named alarm lists." ::= { alarmActiveEntry 1 } alarmActiveDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local date and time when the error occurred. This object facilitates retrieving all instances of Chisholm & Romascanu Standards Track [Page 23] RFC 3877 Alarm MIB September 2004 alarms that have been raised or have changed state since a given point in time. Implementations MUST include the offset from UTC, if available. Implementation in environments in which the UTC offset is not available is NOT RECOMMENDED." ::= { alarmActiveEntry 2 } alarmActiveIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A strictly monotonically increasing integer which acts as the index of entries within the named alarm list. It wraps back to 1 after it reaches its maximum value." ::= { alarmActiveEntry 3 } alarmActiveEngineID OBJECT-TYPE SYNTAX LocalSnmpEngineOrZeroLenStr MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the alarm originated. If the alarm is from an SNMPv1 system this object is a zero length string." ::= { alarmActiveEntry 4 } alarmActiveEngineAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates what type of address is stored in the alarmActiveEngineAddress object - IPv4, IPv6, DNS, etc." ::= { alarmActiveEntry 5 } alarmActiveEngineAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the SNMP engine on which the alarm is occurring. This object MUST always be instantiated, even if the list can contain alarms from only one engine." Chisholm & Romascanu Standards Track [Page 24] RFC 3877 Alarm MIB September 2004 ::= { alarmActiveEntry 6 } alarmActiveContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the alarm came. For SNMPv1 alarms this is the community string from the Trap. Note that care MUST be taken when selecting community strings to ensure that these can be represented as a well-formed SnmpAdminString. Community or Context names that are not well-formed SnmpAdminStrings will be mapped to zero length strings. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." ::= { alarmActiveEntry 7 } alarmActiveVariables OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of variables in alarmActiveVariableTable for this alarm." ::= { alarmActiveEntry 8 } alarmActiveNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifier of the alarm state transition that is occurring." ::= { alarmActiveEntry 9 } alarmActiveResourceId OBJECT-TYPE SYNTAX ResourceId MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the resource under alarm. If there is no corresponding resource, then the value of this object MUST be 0.0." ::= { alarmActiveEntry 10 } Chisholm & Romascanu Standards Track [Page 25] RFC 3877 Alarm MIB September 2004 alarmActiveDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides a textual description of the active alarm. This text is generated dynamically by the notification generator to provide useful information to the human operator. This information SHOULD provide information allowing the operator to locate the resource for which this alarm is being generated. This information is not intended for consumption by automated tools." ::= { alarmActiveEntry 11 } alarmActiveLogPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the corresponding row in a notification logging MIB where the state change notification for this active alarm is logged. If no log entry applies to this active alarm, then this object MUST have the value of 0.0" ::= { alarmActiveEntry 12 } alarmActiveModelPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the corresponding row in the alarmModelTable for this active alarm. This points not only to the alarm model being instantiated, but also to the specific alarm state that is active." ::= { alarmActiveEntry 13 } alarmActiveSpecificPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If no additional, model-specific, Alarm MIB is supported by the system this object is `0.0'. When a model-specific Alarm MIB is supported, this object is the instance pointer to the specific model-specific active alarm list." Chisholm & Romascanu Standards Track [Page 26] RFC 3877 Alarm MIB September 2004 ::= { alarmActiveEntry 14 } -- Active Alarm Variable Table -- alarmActiveVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmActiveVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with active alarm entries." ::= { alarmActive 3 } alarmActiveVariableEntry OBJECT-TYPE SYNTAX AlarmActiveVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table when there are variables in the varbind list of a corresponding alarm in alarmActiveTable. Entries appear in this table as though the trap/notification had been transported using a SNMPv2-Trap-PDU, as defined in [RFC3416] - i.e., the alarmActiveVariableIndex 1 will always be sysUpTime and alarmActiveVariableIndex 2 will always be snmpTrapOID. If the incoming notification is instead an SNMPv1 Trap-PDU and the value of alarmModelVarbindIndex is 1 or 2, an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]." INDEX { alarmListName, alarmActiveIndex, alarmActiveVariableIndex } ::= { alarmActiveVariableTable 1 } AlarmActiveVariableEntry ::= SEQUENCE { alarmActiveVariableIndex Unsigned32, alarmActiveVariableID OBJECT IDENTIFIER, alarmActiveVariableValueType INTEGER, alarmActiveVariableCounter32Val Counter32, alarmActiveVariableUnsigned32Val Unsigned32, alarmActiveVariableTimeTicksVal TimeTicks, alarmActiveVariableInteger32Val Integer32, alarmActiveVariableOctetStringVal OCTET STRING, alarmActiveVariableIpAddressVal IpAddress, alarmActiveVariableOidVal OBJECT IDENTIFIER, alarmActiveVariableCounter64Val Counter64, Chisholm & Romascanu Standards Track [Page 27] RFC 3877 Alarm MIB September 2004 alarmActiveVariableOpaqueVal Opaque } alarmActiveVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A strictly monotonically increasing integer, starting at 1 for a given alarmActiveIndex, for indexing variables within the active alarm variable list. " ::= { alarmActiveVariableEntry 1 } alarmActiveVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The alarm variable's object identifier." ::= { alarmActiveVariableEntry 2 } alarmActiveVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow is used for a given row in this table, based on this type." ::= { alarmActiveVariableEntry 3 } alarmActiveVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'counter32'." ::= { alarmActiveVariableEntry 4 } Chisholm & Romascanu Standards Track [Page 28] RFC 3877 Alarm MIB September 2004 alarmActiveVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'unsigned32'." ::= { alarmActiveVariableEntry 5 } alarmActiveVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'timeTicks'." ::= { alarmActiveVariableEntry 6 } alarmActiveVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'integer32'." ::= { alarmActiveVariableEntry 7 } alarmActiveVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'octetString'." ::= { alarmActiveVariableEntry 8 } alarmActiveVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'ipAddress'." ::= { alarmActiveVariableEntry 9 } alarmActiveVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'objectId'." ::= { alarmActiveVariableEntry 10 } Chisholm & Romascanu Standards Track [Page 29] RFC 3877 Alarm MIB September 2004 alarmActiveVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'counter64'." ::= { alarmActiveVariableEntry 11 } alarmActiveVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque (SIZE(0..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value when alarmActiveVariableType is 'opaque'. Note that although RFC2578 [RFC2578] forbids the use of Opaque in 'standard' MIB modules, this particular usage is driven by the need to be able to accurately represent any well-formed notification, and justified by the need for backward compatibility." ::= { alarmActiveVariableEntry 12 } -- Statistics -- alarmActiveStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmActiveStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the alarm statistics information." ::= { alarmActive 4 } alarmActiveStatsEntry OBJECT-TYPE SYNTAX AlarmActiveStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics on the current active alarms." INDEX { alarmListName } ::= { alarmActiveStatsTable 1 } AlarmActiveStatsEntry ::= SEQUENCE { alarmActiveStatsActiveCurrent Gauge32, alarmActiveStatsActives ZeroBasedCounter32, alarmActiveStatsLastRaise TimeTicks, Chisholm & Romascanu Standards Track [Page 30] RFC 3877 Alarm MIB September 2004 alarmActiveStatsLastClear TimeTicks } alarmActiveStatsActiveCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of currently active alarms on the system." ::= { alarmActiveStatsEntry 1 } alarmActiveStatsActives OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of active alarms since system restarted." ::= { alarmActiveStatsEntry 2 } alarmActiveStatsLastRaise OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last alarm raise for this alarm list. If no alarm raises have occurred since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { alarmActiveStatsEntry 3 } alarmActiveStatsLastClear OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last alarm clear for this alarm list. If no alarm clears have occurred since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { alarmActiveStatsEntry 4 } -- Alarm Clear alarmClearMaximum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write Chisholm & Romascanu Standards Track [Page 31] RFC 3877 Alarm MIB September 2004 STATUS current DESCRIPTION "This object specifies the maximum number of cleared alarms to store in the alarmClearTable. When this number is reached, the cleared alarms with the earliest clear time will be removed from the table." ::= { alarmClear 1 } alarmClearTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmClearEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on cleared alarms." ::= { alarmClear 2 } alarmClearEntry OBJECT-TYPE SYNTAX AlarmClearEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a cleared alarm." INDEX { alarmListName, alarmClearDateAndTime, alarmClearIndex } ::= { alarmClearTable 1 } AlarmClearEntry ::= SEQUENCE { alarmClearIndex Unsigned32, alarmClearDateAndTime DateAndTime, alarmClearEngineID LocalSnmpEngineOrZeroLenStr, alarmClearEngineAddressType InetAddressType, alarmClearEngineAddress InetAddress, alarmClearContextName SnmpAdminString, alarmClearNotificationID OBJECT IDENTIFIER, alarmClearResourceId ResourceId, alarmClearLogIndex Unsigned32, alarmClearModelPointer RowPointer } alarmClearIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer which acts as the index of entries within Chisholm & Romascanu Standards Track [Page 32] RFC 3877 Alarm MIB September 2004 the named alarm list. It wraps back to 1 after it reaches its maximum value. This object has the same value as the alarmActiveIndex that this alarm instance had when it was active." ::= { alarmClearEntry 1 } alarmClearDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local date and time when the alarm cleared. This object facilitates retrieving all instances of alarms that have been cleared since a given point in time. Implementations MUST include the offset from UTC, if available. Implementation in environments in which the UTC offset is not available is NOT RECOMMENDED." ::= { alarmClearEntry 2 } alarmClearEngineID OBJECT-TYPE SYNTAX LocalSnmpEngineOrZeroLenStr MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the alarm originated. If the alarm is from an SNMPv1 system this object is a zero length string." ::= { alarmClearEntry 3 } alarmClearEngineAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates what type of address is stored in the alarmActiveEngineAddress object - IPv4, IPv6, DNS, etc." ::= { alarmClearEntry 4 } alarmClearEngineAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Address of the SNMP engine on which the alarm was occurring. This is used to identify the source of an SNMPv1 Chisholm & Romascanu Standards Track [Page 33] RFC 3877 Alarm MIB September 2004 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU. This object MUST always be instantiated, even if the list can contain alarms from only one engine." ::= { alarmClearEntry 5 } alarmClearContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the alarm came. For SNMPv1 traps this is the community string from the Trap. Note that care needs to be taken when selecting community strings to ensure that these can be represented as a well-formed SnmpAdminString. Community or Context names that are not well-formed SnmpAdminStrings will be mapped to zero length strings. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." ::= { alarmClearEntry 6 } alarmClearNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifier of the alarm clear." ::= { alarmClearEntry 7 } alarmClearResourceId OBJECT-TYPE SYNTAX ResourceId MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the resource that was under alarm. If there is no corresponding resource, then the value of this object MUST be 0.0." ::= { alarmClearEntry 8 } alarmClearLogIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current Chisholm & Romascanu Standards Track [Page 34] RFC 3877 Alarm MIB September 2004 DESCRIPTION "This number MUST be the same as the log index of the applicable row in the notification log MIB, if it exists. If no log index applies to the trap, then this object MUST have the value of 0." ::= { alarmClearEntry 9 } alarmClearModelPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the corresponding row in the alarmModelTable for this cleared alarm." ::= { alarmClearEntry 10 } -- Notifications alarmActiveState NOTIFICATION-TYPE OBJECTS { alarmActiveModelPointer, alarmActiveResourceId } STATUS current DESCRIPTION "An instance of the alarm indicated by alarmActiveModelPointer has been raised against the entity indicated by alarmActiveResourceId. The agent must throttle the generation of consecutive alarmActiveState traps so that there is at least a two-second gap between traps of this type against the same alarmActiveModelPointer and alarmActiveResourceId. When traps are throttled, they are dropped, not queued for sending at a future time. A management application should periodically check the value of alarmActiveLastChanged to detect any missed alarmActiveState notification-events, e.g., due to throttling or transmission loss." ::= { alarmNotifications 2 } alarmClearState NOTIFICATION-TYPE OBJECTS { alarmActiveModelPointer, alarmActiveResourceId } STATUS current DESCRIPTION "An instance of the alarm indicated by alarmActiveModelPointer has been cleared against Chisholm & Romascanu Standards Track [Page 35] RFC 3877 Alarm MIB September 2004 the entity indicated by alarmActiveResourceId. The agent must throttle the generation of consecutive alarmActiveClear traps so that there is at least a two-second gap between traps of this type against the same alarmActiveModelPointer and alarmActiveResourceId. When traps are throttled, they are dropped, not queued for sending at a future time. A management application should periodically check the value of alarmActiveLastChanged to detect any missed alarmClearState notification-events, e.g., due to throttling or transmission loss." ::= { alarmNotifications 3 } -- Conformance alarmConformance OBJECT IDENTIFIER ::= { alarmMIB 2 } alarmCompliances OBJECT IDENTIFIER ::= { alarmConformance 1 } alarmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems supporting the Alarm MIB." MODULE -- this module MANDATORY-GROUPS { alarmActiveGroup, alarmModelGroup } GROUP alarmActiveStatsGroup DESCRIPTION "This group is optional." GROUP alarmClearGroup DESCRIPTION "This group is optional." GROUP alarmNotificationsGroup DESCRIPTION "This group is optional." ::= { alarmCompliances 1 } alarmGroups OBJECT IDENTIFIER ::= { alarmConformance 2 } alarmModelGroup OBJECT-GROUP OBJECTS { alarmModelLastChanged, alarmModelNotificationId, Chisholm & Romascanu Standards Track [Page 36] RFC 3877 Alarm MIB September 2004 alarmModelVarbindIndex, alarmModelVarbindValue, alarmModelDescription, alarmModelSpecificPointer, alarmModelVarbindSubtree, alarmModelResourcePrefix, alarmModelRowStatus } STATUS current DESCRIPTION "Alarm model group." ::= { alarmGroups 1} alarmActiveGroup OBJECT-GROUP OBJECTS { alarmActiveLastChanged, alarmActiveOverflow, alarmActiveEngineID, alarmActiveEngineAddressType, alarmActiveEngineAddress, alarmActiveContextName, alarmActiveVariables, alarmActiveNotificationID, alarmActiveResourceId, alarmActiveDescription, alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, alarmActiveVariableID, alarmActiveVariableValueType, alarmActiveVariableCounter32Val, alarmActiveVariableUnsigned32Val, alarmActiveVariableTimeTicksVal, alarmActiveVariableInteger32Val, alarmActiveVariableOctetStringVal, alarmActiveVariableIpAddressVal, alarmActiveVariableOidVal, alarmActiveVariableCounter64Val, alarmActiveVariableOpaqueVal } STATUS current DESCRIPTION "Active Alarm list group." ::= { alarmGroups 2} alarmActiveStatsGroup OBJECT-GROUP OBJECTS { alarmActiveStatsActives, Chisholm & Romascanu Standards Track [Page 37] RFC 3877 Alarm MIB September 2004 alarmActiveStatsActiveCurrent, alarmActiveStatsLastRaise, alarmActiveStatsLastClear } STATUS current DESCRIPTION "Active alarm summary group." ::= { alarmGroups 3} alarmClearGroup OBJECT-GROUP OBJECTS { alarmClearMaximum, alarmClearEngineID, alarmClearEngineAddressType, alarmClearEngineAddress, alarmClearContextName, alarmClearNotificationID, alarmClearResourceId, alarmClearLogIndex, alarmClearModelPointer } STATUS current DESCRIPTION "Cleared alarm group." ::= { alarmGroups 4} alarmNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { alarmActiveState, alarmClearState } STATUS current DESCRIPTION "The collection of notifications that can be used to model alarms for faults lacking pre-existing notification definitions." ::= { alarmGroups 6 } END 5. ITU Alarm 5.1. Overview This MIB module defines alarm information specific to the alarm model defined in ITU M.3100 [M.3100], X.733 [X.733], and X.736 [X.736]. This MIB module follows the modular architecture defined by the Alarm MIB, in which the generic Alarm MIB can be augmented by other alarm information defined according to more specific models that define additional behaviour and characteristics. Chisholm & Romascanu Standards Track [Page 38] RFC 3877 Alarm MIB September 2004 The ituAlarmTable contains information from the ITU Alarm Model about possible alarms in the system. The ituAlarmActiveTable contains information from the ITU Alarm Model about alarms modelled using the ituAlarmTable that are currently occurring on the system. The ituAlarmActiveStatsTable provides statistics on current and total alarms. 5.2. IANA Considerations Over time, there will be a need to add new IANAITUEventType and IANAItuProbableCause enumerated values. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in these TCs. IANAItuProbableCause value of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come basis, with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new enumerations do not conceptually duplicate existing enumerations it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the OPS Area Director will appoint one or more experts to help review requests. See http://www.iana.org The following shall be used as the initial values, but the latest values for these textual conventions should be obtained from IANA: IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] Chisholm & Romascanu Standards Track [Page 39] RFC 3877 Alarm MIB September 2004 ianaItuAlarmNumbers MODULE-IDENTITY LAST-UPDATED "200409090000Z" -- September 09, 2004 ORGANIZATION "IANA" CONTACT-INFO "Postal: Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6601 USA Tel: +1 310-823-9358 E-Mail: iana@iana.org" DESCRIPTION "The MIB module defines the ITU Alarm textual convention for objects expected to require regular extension. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3877. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html" REVISION "200409090000Z" -- September 09, 2004 DESCRIPTION "Initial version, published as RFC 3877." ::= { mib-2 119 } IANAItuProbableCause ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in this TC. IANAItuProbableCause value of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed Chisholm & Romascanu Standards Track [Page 40] RFC 3877 Alarm MIB September 2004 SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the OPS Area Director will appoint one or more experts to help review requests. See http://www.iana.org" REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992 ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" SYNTAX INTEGER { -- The following probable causes were defined in M.3100 aIS (1), callSetUpFailure (2), degradedSignal (3), farEndReceiverFailure (4), framingError (5), lossOfFrame (6), lossOfPointer (7), lossOfSignal (8), payloadTypeMismatch (9), transmissionError (10), remoteAlarmInterface (11), excessiveBER (12), pathTraceMismatch (13), unavailable (14), signalLabelMismatch (15), lossOfMultiFrame (16), receiveFailure (17), transmitFailure (18), modulationFailure (19), demodulationFailure (20), broadcastChannelFailure (21), Chisholm & Romascanu Standards Track [Page 41] RFC 3877 Alarm MIB September 2004 connectionEstablishmentError (22), invalidMessageReceived (23), localNodeTransmissionError (24), remoteNodeTransmissionError (25), routingFailure (26), --Values 27-50 are reserved for communications alarm related --probable causes -- The following are used with equipment alarm. backplaneFailure (51), dataSetProblem (52), equipmentIdentifierDuplication (53), externalIFDeviceProblem (54), lineCardProblem (55), multiplexerProblem (56), nEIdentifierDuplication (57), powerProblem (58), processorProblem (59), protectionPathFailure (60), receiverFailure (61), replaceableUnitMissing (62), replaceableUnitTypeMismatch (63), synchronizationSourceMismatch (64), terminalProblem (65), timingProblem (66), transmitterFailure (67), trunkCardProblem (68), replaceableUnitProblem (69), realTimeClockFailure (70), --An equipment alarm to be issued if the system detects that the --real time clock has failed antennaFailure (71), batteryChargingFailure (72), diskFailure (73), frequencyHoppingFailure (74), iODeviceError (75), lossOfSynchronisation (76), lossOfRedundancy (77), powerSupplyFailure (78), signalQualityEvaluationFailure (79), tranceiverFailure (80), protectionMechanismFailure (81), protectingResourceFailure (82), -- Values 83-100 are reserved for equipment alarm related probable -- causes -- The following are used with environmental alarm. airCompressorFailure (101), Chisholm & Romascanu Standards Track [Page 42] RFC 3877 Alarm MIB September 2004 airConditioningFailure (102), airDryerFailure (103), batteryDischarging (104), batteryFailure (105), commercialPowerFailure (106), coolingFanFailure (107), engineFailure (108), fireDetectorFailure (109), fuseFailure (110), generatorFailure (111), lowBatteryThreshold (112), pumpFailure (113), rectifierFailure (114), rectifierHighVoltage (115), rectifierLowFVoltage (116), ventilationsSystemFailure (117), enclosureDoorOpen (118), explosiveGas (119), fire (120), flood (121), highHumidity (122), highTemperature (123), highWind (124), iceBuildUp (125), intrusionDetection (126), lowFuel (127), lowHumidity (128), lowCablePressure (129), lowTemperatue (130), lowWater (131), smoke (132), toxicGas (133), coolingSystemFailure (134), externalEquipmentFailure (135), externalPointFailure (136), -- Values 137-150 are reserved for environmental alarm related -- probable causes -- The following are used with Processing error alarm. storageCapacityProblem (151), memoryMismatch (152), corruptData (153), outOfCPUCycles (154), sfwrEnvironmentProblem (155), sfwrDownloadFailure (156), lossOfRealTimel (157), --A processing error alarm to be issued after the system has --reinitialised. This will indicate --to the management systems that the view they have of the managed Chisholm & Romascanu Standards Track [Page 43] RFC 3877 Alarm MIB September 2004 --system may no longer --be valid. Usage example: The managed --system issues this alarm after a reinitialization with severity --warning to inform the --management system about the event. No clearing notification will --be sent. applicationSubsystemFailure (158), configurationOrCustomisationError (159), databaseInconsistency (160), fileError (161), outOfMemory (162), softwareError (163), timeoutExpired (164), underlayingResourceUnavailable (165), versionMismatch (166), --Values 168-200 are reserved for processing error alarm related -- probable causes. bandwidthReduced (201), congestion (202), excessiveErrorRate (203), excessiveResponseTime (204), excessiveRetransmissionRate (205), reducedLoggingCapability (206), systemResourcesOverload (207 ), -- The following were defined X.733 adapterError (500), applicationSubsystemFailture (501), bandwidthReducedX733 (502), callEstablishmentError (503), communicationsProtocolError (504), communicationsSubsystemFailure (505), configurationOrCustomizationError (506), congestionX733 (507), coruptData (508), cpuCyclesLimitExceeded (509), dataSetOrModemError (510), degradedSignalX733 (511), dteDceInterfaceError (512), enclosureDoorOpenX733 (513), equipmentMalfunction (514), excessiveVibration (515), fileErrorX733 (516), fireDetected (517), framingErrorX733 (518), heatingVentCoolingSystemProblem (519), humidityUnacceptable (520), inputOutputDeviceError (521), inputDeviceError (522), Chisholm & Romascanu Standards Track [Page 44] RFC 3877 Alarm MIB September 2004 lanError (523), leakDetected (524), localNodeTransmissionErrorX733 (525), lossOfFrameX733 (526), lossOfSignalX733 (527), materialSupplyExhausted (528), multiplexerProblemX733 (529), outOfMemoryX733 (530), ouputDeviceError (531), performanceDegraded (532), powerProblems (533), pressureUnacceptable (534), processorProblems (535), pumpFailureX733 (536), queueSizeExceeded (537), receiveFailureX733 (538), receiverFailureX733 (539), remoteNodeTransmissionErrorX733 (540), resourceAtOrNearingCapacity (541), responseTimeExecessive (542), retransmissionRateExcessive (543), softwareErrorX733 (544), softwareProgramAbnormallyTerminated (545), softwareProgramError (546), storageCapacityProblemX733 (547), temperatureUnacceptable (548), thresholdCrossed (549), timingProblemX733 (550), toxicLeakDetected (551), transmitFailureX733 (552), transmiterFailure (553), underlyingResourceUnavailable (554), versionMismatchX733 (555), -- The following are defined in X.736 authenticationFailure (600), breachOfConfidentiality (601), cableTamper (602), delayedInformation (603), denialOfService (604), duplicateInformation (605), informationMissing (606), informationModificationDetected (607), informationOutOfSequence (608), keyExpired (609), nonRepudiationFailure (610), outOfHoursActivity (611), outOfService (612), proceduralError (613), Chisholm & Romascanu Standards Track [Page 45] RFC 3877 Alarm MIB September 2004 unauthorizedAccessAttempt (614), unexpectedInformation (615), other (1024) } IANAItuEventType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ITU event Type values. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in this TC. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. See http://www.iana.org " REFERENCE "ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" SYNTAX INTEGER { other (1), communicationsAlarm (2), qualityOfServiceAlarm (3), processingErrorAlarm (4), equipmentAlarm (5), environmentalAlarm (6), integrityViolation (7), operationalViolation (8), physicalViolation (9), securityServiceOrMechanismViolation (10), timeDomainViolation (11) } END Chisholm & Romascanu Standards Track [Page 46] RFC 3877 Alarm MIB September 2004 5.3. Textual Conventions ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ituAlarmTc MODULE-IDENTITY LAST-UPDATED "200409090000Z" -- September 09, 2004 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO " WG EMail: disman@ietf.org Subscribe: disman-request@ietf.org http://www.ietf.org/html.charters/disman-charter.html Chair: Randy Presuhn randy_presuhn@mindspring.com Editors: Sharon Chisholm Nortel Networks PO Box 3511 Station C Ottawa, Ont. K1Y 4H7 Canada schishol@nortelnetworks.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Tel: +972-3-645-8414 Email: dromasca@avaya.com" DESCRIPTION "This MIB module defines the ITU Alarm textual convention for objects not expected to require regular extension. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3877. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html" REVISION "200409090000Z" -- September 09, 2004 DESCRIPTION "Initial version, published as RFC 3877." Chisholm & Romascanu Standards Track [Page 47] RFC 3877 Alarm MIB September 2004 ::= { mib-2 120 } ItuPerceivedSeverity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ITU perceived severity values" REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992" SYNTAX INTEGER { cleared (1), indeterminate (2), critical (3), major (4), minor (5), warning (6) } ItuTrendIndication ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ITU trend indication values for alarms." REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992" SYNTAX INTEGER { moreSevere (1), noChange (2), lessSevere (3) } END Chisholm & Romascanu Standards Track [Page 48] RFC 3877 Alarm MIB September 2004 5.4. Definitions ITU-ALARM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Gauge32, mib-2 FROM SNMPv2-SMI -- [RFC2578] AutonomousType, RowPointer FROM SNMPv2-TC -- [RFC2579] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] alarmListName, alarmModelIndex, alarmActiveDateAndTime, alarmActiveIndex FROM ALARM-MIB -- [RFC3877] ItuPerceivedSeverity, ItuTrendIndication FROM ITU-ALARM-TC-MIB -- [RFC3877] IANAItuProbableCause, IANAItuEventType FROM IANA-ITU-ALARM-TC-MIB -- [RFC3877] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] ZeroBasedCounter32 FROM RMON2-MIB; -- [RFC2021] ituAlarmMIB MODULE-IDENTITY LAST-UPDATED "200409090000Z" -- September 09, 2004 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "WG EMail: disman@ietf.org Subscribe: disman-request@ietf.org http://www.ietf.org/html.charters/disman-charter.html Chair: Randy Presuhn randy_presuhn@mindspring.com Editors: Sharon Chisholm Nortel Networks PO Box 3511 Station C Ottawa, Ont. K1Y 4H7 Canada schishol@nortelnetworks.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Chisholm & Romascanu Standards Track [Page 49] RFC 3877 Alarm MIB September 2004 Israel Tel: +972-3-645-8414 Email: dromasca@avaya.com" DESCRIPTION "The MIB module describes ITU Alarm information as defined in ITU Recommendation M.3100 [M.3100], X.733 [X.733] and X.736 [X.736]. Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3877. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html" REVISION "200409090000Z" -- September 09, 2004 DESCRIPTION "Initial version, published as RFC 3877." ::= { mib-2 121 } ituAlarmObjects OBJECT IDENTIFIER ::= { ituAlarmMIB 1 } ituAlarmModel OBJECT IDENTIFIER ::= { ituAlarmObjects 1 } ituAlarmActive OBJECT IDENTIFIER ::= { ituAlarmObjects 2 } ituAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ITU Alarm information for possible alarms on the system." ::= { ituAlarmModel 1 } ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table whenever an entry is created in the alarmModelTable with a value of alarmModelState in the range from 1 to 6. Entries disappear from this table whenever the corresponding entries are deleted from the alarmModelTable, including in cases where those entries have been deleted due to local system action. The value of alarmModelSpecificPointer has no effect on the creation or deletion of entries in this table. Values of alarmModelState map to values of ituAlarmPerceivedSeverity as follows: Chisholm & Romascanu Standards Track [Page 50] RFC 3877 Alarm MIB September 2004 alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) All other values of alarmModelState MUST NOT appear in this table. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } ItuAlarmEntry ::= SEQUENCE { ituAlarmPerceivedSeverity ItuPerceivedSeverity, ituAlarmEventType IANAItuEventType, ituAlarmProbableCause IANAItuProbableCause, ituAlarmAdditionalText SnmpAdminString, ituAlarmGenericModel RowPointer } ituAlarmPerceivedSeverity OBJECT-TYPE SYNTAX ItuPerceivedSeverity MAX-ACCESS not-accessible STATUS current DESCRIPTION "ITU perceived severity values." REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992" ::= { ituAlarmEntry 1 } ituAlarmEventType OBJECT-TYPE SYNTAX IANAItuEventType MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the event type values for the alarms" REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Chisholm & Romascanu Standards Track [Page 51] RFC 3877 Alarm MIB September 2004 Reporting Function', 1992 ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" ::= { ituAlarmEntry 2 } ituAlarmProbableCause OBJECT-TYPE SYNTAX IANAItuProbableCause MAX-ACCESS read-write STATUS current DESCRIPTION "ITU probable cause values." REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992 ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" ::= { ituAlarmEntry 3 } ituAlarmAdditionalText OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the additional text field for the alarm." REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992" ::= { ituAlarmEntry 4} ituAlarmGenericModel OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-write STATUS current DESCRIPTION "This object points to the corresponding row in the alarmModelTable for this alarm severity. This corresponding entry to alarmModelTable could also be derived by performing the reverse of the mapping from alarmModelState to ituAlarmPerceivedSeverity defined Chisholm & Romascanu Standards Track [Page 52] RFC 3877 Alarm MIB September 2004 in the description of ituAlarmEntry to determine the appropriate { alarmListName, alarmModelIndex, alarmModelState } for this { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity }." ::= { ituAlarmEntry 5 } -- ITU Active Alarm Table -- ituAlarmActiveTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ITU information for active alarms entries." ::= { ituAlarmActive 1 } ituAlarmActiveEntry OBJECT-TYPE SYNTAX ItuAlarmActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table when alarms are active. They are removed when the alarm is no longer occurring." INDEX { alarmListName, alarmActiveDateAndTime, alarmActiveIndex } ::= { ituAlarmActiveTable 1 } ItuAlarmActiveEntry ::= SEQUENCE { ituAlarmActiveTrendIndication ItuTrendIndication, ituAlarmActiveDetector AutonomousType, ituAlarmActiveServiceProvider AutonomousType, ituAlarmActiveServiceUser AutonomousType } ituAlarmActiveTrendIndication OBJECT-TYPE SYNTAX ItuTrendIndication MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the trend indication values for the alarms." REFERENCE "ITU Recommendation M.3100, 'Generic Network Information Model', 1995 ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992" ::= { ituAlarmActiveEntry 1 } Chisholm & Romascanu Standards Track [Page 53] RFC 3877 Alarm MIB September 2004 ituAlarmActiveDetector OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the SecurityAlarmDetector object." REFERENCE "ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" ::= { ituAlarmActiveEntry 2 } ituAlarmActiveServiceProvider OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the ServiceProvider object." REFERENCE "ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" ::= { ituAlarmActiveEntry 3 } ituAlarmActiveServiceUser OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the ServiceUser object." REFERENCE "ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" ::= { ituAlarmActiveEntry 4 } -- Statistics and Counters ituAlarmActiveStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmActiveStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the ITU alarm statistics information." ::= { ituAlarmActive 2 } Chisholm & Romascanu Standards Track [Page 54] RFC 3877 Alarm MIB September 2004 ituAlarmActiveStatsEntry OBJECT-TYPE SYNTAX ItuAlarmActiveStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics on the current active ITU alarms." INDEX { alarmListName } ::= { ituAlarmActiveStatsTable 1 } ItuAlarmActiveStatsEntry ::= SEQUENCE { ituAlarmActiveStatsIndeterminateCurrent Gauge32, ituAlarmActiveStatsCriticalCurrent Gauge32, ituAlarmActiveStatsMajorCurrent Gauge32, ituAlarmActiveStatsMinorCurrent Gauge32, ituAlarmActiveStatsWarningCurrent Gauge32, ituAlarmActiveStatsIndeterminates ZeroBasedCounter32, ituAlarmActiveStatsCriticals ZeroBasedCounter32, ituAlarmActiveStatsMajors ZeroBasedCounter32, ituAlarmActiveStatsMinors ZeroBasedCounter32, ituAlarmActiveStatsWarnings ZeroBasedCounter32 } ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the current number of active alarms with a ituAlarmPerceivedSeverity of indeterminate." ::= { ituAlarmActiveStatsEntry 1 } ituAlarmActiveStatsCriticalCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the current number of active alarms with a ituAlarmPerceivedSeverity of critical." ::= { ituAlarmActiveStatsEntry 2 } ituAlarmActiveStatsMajorCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the current number of active alarms with a Chisholm & Romascanu Standards Track [Page 55] RFC 3877 Alarm MIB September 2004 ituAlarmPerceivedSeverity of major." ::= { ituAlarmActiveStatsEntry 3 } ituAlarmActiveStatsMinorCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the current number of active alarms with a ituAlarmPerceivedSeverity of minor." ::= { ituAlarmActiveStatsEntry 4 } ituAlarmActiveStatsWarningCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the current number of active alarms with a ituAlarmPerceivedSeverity of warning." ::= { ituAlarmActiveStatsEntry 5 } ituAlarmActiveStatsIndeterminates OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of active alarms with a ituAlarmPerceivedSeverity of indeterminate since system restart." ::= { ituAlarmActiveStatsEntry 6 } ituAlarmActiveStatsCriticals OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of active alarms with a ituAlarmPerceivedSeverity of critical since system restart." ::= { ituAlarmActiveStatsEntry 7 } ituAlarmActiveStatsMajors OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of active alarms with a ituAlarmPerceivedSeverity of major since system restart." ::= { ituAlarmActiveStatsEntry 8 } Chisholm & Romascanu Standards Track [Page 56] RFC 3877 Alarm MIB September 2004 ituAlarmActiveStatsMinors OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of active alarms with a ituAlarmPerceivedSeverity of minor since system restart." ::= { ituAlarmActiveStatsEntry 9 } ituAlarmActiveStatsWarnings OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of active alarms with a ituAlarmPerceivedSeverity of warning since system restart." ::= { ituAlarmActiveStatsEntry 10 } -- Conformance ituAlarmConformance OBJECT IDENTIFIER ::= { ituAlarmMIB 2 } ituAlarmCompliances OBJECT IDENTIFIER ::= { ituAlarmConformance 1 } ituAlarmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems supporting the ITU Alarm MIB." MODULE -- this module MANDATORY-GROUPS { ituAlarmGroup } GROUP ituAlarmServiceUserGroup DESCRIPTION "This group is optional." GROUP ituAlarmSecurityGroup DESCRIPTION "This group is optional." GROUP ituAlarmStatisticsGroup DESCRIPTION "This group is optional." ::= { ituAlarmCompliances 1 } ituAlarmGroups OBJECT IDENTIFIER ::= { ituAlarmConformance 2 } ituAlarmGroup OBJECT-GROUP OBJECTS { ituAlarmEventType, Chisholm & Romascanu Standards Track [Page 57] RFC 3877 Alarm MIB September 2004 ituAlarmProbableCause, ituAlarmGenericModel } STATUS current DESCRIPTION "ITU alarm details list group." ::= { ituAlarmGroups 1} ituAlarmServiceUserGroup OBJECT-GROUP OBJECTS { ituAlarmAdditionalText, ituAlarmActiveTrendIndication } STATUS current DESCRIPTION "The use of these parameters is a service-user option." ::= { ituAlarmGroups 2 } ituAlarmSecurityGroup OBJECT-GROUP OBJECTS { ituAlarmActiveDetector, ituAlarmActiveServiceProvider, ituAlarmActiveServiceUser } STATUS current DESCRIPTION "Security Alarm Reporting Function" REFERENCE "ITU Recommendation X.736, 'Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function', 1992" ::= { ituAlarmGroups 3 } ituAlarmStatisticsGroup OBJECT-GROUP OBJECTS { ituAlarmActiveStatsIndeterminateCurrent, ituAlarmActiveStatsCriticalCurrent, ituAlarmActiveStatsMajorCurrent, ituAlarmActiveStatsMinorCurrent, ituAlarmActiveStatsWarningCurrent, ituAlarmActiveStatsIndeterminates, ituAlarmActiveStatsCriticals, ituAlarmActiveStatsMajors, ituAlarmActiveStatsMinors, ituAlarmActiveStatsWarnings } STATUS current DESCRIPTION Chisholm & Romascanu Standards Track [Page 58] RFC 3877 Alarm MIB September 2004 "ITU Active Alarm Statistics." ::= { ituAlarmGroups 4 } END 6. Examples 6.1. Alarms Based on linkUp/linkDown Notifications This example demonstrates an interface-based alarm that goes into a state of "warning" when a linkDown Notification [RFC2863] occurs but the ifAdminStatus indicates the interface was taken down administratively. If IfAdminStatus is "up" when the linkDown Notification occurs, then there is a problem, so the state of the alarm is critical. A linkUp alarm clears the alarm. linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "" ::= { snmpTraps 3 } linkUp NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "" ::= { snmpTraps 4 } alarmModelIndex 3 alarmModelState 1 alarmModelNotificationId linkUp alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "linkUp" alarmModelSpecificPointer ituAlarmEntry.3.1 alarmModelVarbindSubtree ifIndex (1.3.6.1.2.1.2.2.1.1) alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity cleared (1) ituAlarmGenericModel alarmModelEntry.3.1 alarmModelIndex 3 alarmModelState 2 alarmModelNotificationId linkDown alarmModelVarbindIndex 2 Chisholm & Romascanu Standards Track [Page 59] RFC 3877 Alarm MIB September 2004 alarmModelVarbindValue down (2) alarmModelDescription "linkDown administratively" alarmModelSpecificPointer ituAlarmEntry.3.6 alarmModelVarbindSubtree ifIndex (1.3.6.1.2.1.2.2.1.1) alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity warning (6) ituAlarmGenericModel alarmModelEntry.3.2 alarmModelIndex 3 alarmModelState 3 alarmModelNotificationId linkDown alarmModelVarbindIndex 2 alarmModelVarbindValue up (1) alarmModelDescription "linkDown - confirmed problem" alarmModelSpecificPointer ituAlarmEntry.3.3 alarmModelVarbindSubtree ifIndex (1.3.6.1.2.1.2.2.1.1) alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity critical (3) ituAlarmGenericModel alarmModelEntry.3.3 alarmActiveIndex 1 alarmActiveDateAndTime 2342464573 alarmActiveDateAndTime DateAndTime, alarmActiveEngineID SnmpEngineID, alarmActiveEngineAddressType ipV4 alarmActiveEngineAddress 10.10.10.10 alarmActiveContextName SnmpAdminString, alarmActiveVariables 3 alarmActiveNotificationID 1.3.6.1.6.3.1.1.5.3 alarmActiveResourceId 1.3.6.1.2.1.2.2.1.1.346 alarmActiveLogPointer 0.0 alarmActiveModelPointer alarmModelEntry.3.3 alarmActiveSpecificPointer ituAlarmActiveEntry.1.3 ituAlarmActiveTrendIndication moreSevere (1) ituAlarmDetector 0.0 ituAlarmServiceProvider 0.0 ituAlarmServiceUser 0.0 alarmActiveVariableIndex 1 alarmActiveVariableID sysUpTime.0 alarmActiveVariableValueType timeTicks(3) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 46754 Chisholm & Romascanu Standards Track [Page 60] RFC 3877 Alarm MIB September 2004 alarmActiveVariableInteger32Val 0 alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 2 alarmActiveVariableID snmpTrapOID.0 alarmActiveVariableValueType objectId(7) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val 0 alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 1.3.6.1.6.3.1.1.5.3 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 3 alarmActiveVariableID ifIndex alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val 346 alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 4 alarmActiveVariableID ifAdminStatus alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val up (1) alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 5 alarmActiveVariableID ifOperStatus alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val down(2) alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0 Chisholm & Romascanu Standards Track [Page 61] RFC 3877 Alarm MIB September 2004 alarmActiveVariableCounter64Val 0 alarmActiveVariableOpaqueVal 6.2. Temperature Alarms Using Generic Notifications Consider a system able to detect four different temperature states for a widget - normal, minor, major, critical. The system does not have any Notification definitions for these alarm states. A temperature alarm can be modelled using the generic alarm Notifications of alarmClearState and alarmActive. alarmModelIndex 5 alarmModelState 1 alarmModelNotificationId alarmClearState alarmModelVarbindIndex 2 alarmModelVarbindValue cleared (1) alarmModelDescription "Acme Widget Temperature Normal" alarmModelSpecificPointer ituAlarmEntry.5.1 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity cleared (1) ituAlarmGenericModel alarmModelEntry.5.1 alarmModelIndex 5 alarmModelState 2 alarmModelNotificationId alarmActiveState alarmModelVarbindIndex 2 alarmModelVarbindValue minor (5) alarmModelDescription "Acme Widget Temperature Minor" alarmModelSpecificPointer ituAlarmEntry.5.5 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventState environmentalAlarm (6) ituPerceivedSeverity minor (5) ituAlarmGenericModel alarmModelEntry.5.2 alarmModelIndex 5 alarmModelState 3 alarmModelNotificationId alarmActiveState alarmModelVarbindIndex 2 alarmModelVarbindValue major (4) alarmModelDescription "Acme Widget Temperature Major" alarmModelSpecificPointer ituAlarmEntry.5.4 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0 Chisholm & Romascanu Standards Track [Page 62] RFC 3877 Alarm MIB September 2004 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity major (4) ituAlarmGenericModel alarmModelEntry.5.3 alarmModelIndex 5 alarmModelState 4 alarmModelNotificationId alarmActiveState alarmModelVarbindIndex 2 alarmModelVarbindValue critical (3) alarmModelDescription "Acme Widget Temperature Critical" alarmModelSpecificPointer ituAlarmEntry.5.3 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity critical (3) ituAlarmGenericModel alarmModelEntry.5.4 6.3. Temperature Alarms Without Notifications Consider a system able to detect four different temperature states for a widget - normal, minor, major, critical. The system does not have any Notification definitions for these alarm states. A temperature alarm can be modelled without specifying any Notifications in the alarm model. When a temperature state other than normal is detected, an instance of this alarm would be added to the active alarm table, but no Notifications would be sent out. This could alternatively be accomplished using the models from example 6.2 and by not specifying any target managers in the SNMP- TARGET-MIB, which would allow the alarm state Notifications to be logged in the Notification Log while still preventing Notifications from being transmitted on the wire. alarmModelIndex 6 alarmModelState 1 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature" alarmModelSpecificPointer ituAlarmEntry.6.1 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity cleared (1) ituAlarmGenericModel alarmModelEntry.6.1 Chisholm & Romascanu Standards Track [Page 63] RFC 3877 Alarm MIB September 2004 alarmModelIndex 6 alarmModelState 2 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature" alarmModelSpecificPointer ituAlarmEntry.6.5 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventState environmentalAlarm (6) ituAlarmPerceivedSeverity minor (5) ituAlarmGenericModel alarmModelEntry.6.2 alarmModelIndex 6 alarmModelState 3 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature" alarmModelSpecificPointer ituAlarmEntry.6.4 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity major (4) ituAlarmGenericModel alarmModelEntry.6.3 alarmModelIndex 6 alarmModelState 4 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature Severe" alarmModelSpecificPointer ituAlarmEntry.6.3 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity critical (3) ituAlarmGenericModel alarmModelEntry.6.4 Chisholm & Romascanu Standards Track [Page 64] RFC 3877 Alarm MIB September 2004 6.4. Printer MIB Alarm Example Consider the following Notifications defined in the printer MIB [RFC3805]: prtAlertSeverityLevel OBJECT-TYPE -- This value is a type 1 enumeration SYNTAX INTEGER { other(1), critical(3), warning(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The level of severity of this alert table entry. The printer determines the severity level assigned to each entry into the table." ::= { prtAlertEntry 2 } printerV2Alert NOTIFICATION-TYPE OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup, prtAlertGroupIndex, prtAlertLocation, prtAlertCode } STATUS current DESCRIPTION "This trap is sent whenever a critical event is added to the prtAlertTable." ::= { printerV2AlertPrefix 1 } These Notifications can be used to model a printer alarm as follows: alarmModelIndex 9 alarmModelState 1 alarmModelNotificationId alarmClearState alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Printer Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) alarmModelIndex 9 alarmModelState 2 alarmModelNotificationId printerV2Alert alarmModelVarbindIndex 2 alarmModelVarbindValue warning (4) alarmModelDescription "Printer Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) alarmModelIndex 9 alarmModelState 3 Chisholm & Romascanu Standards Track [Page 65] RFC 3877 Alarm MIB September 2004 alarmModelNotificationId printerV2Alert alarmModelVarbindIndex 2 alarmModelVarbindValue other (1) alarmModelDescription "Printer Alarm - unknown severity" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) alarmModelIndex 9 alarmModelState 4 alarmModelNotificationId printerV2Alert alarmModelVarbindIndex 2 alarmModelVarbindValue critical (3) alarmModelDescription "Printer Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) 6.5. RMON Alarm Example The RMON MIB [RFC2819] defines a mechanism for generating threshold alarms. When the thresholds are crossed, RisingAlarm and FallingAlarm Notifications are generated as appropriate. These Notifications can be used to model an upper threshold alarm as follows: alarmModelIndex 6 alarmModelState 1 alarmModelNotificationId FallingAlarm alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "RMON Rising Clear Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree alarmIndex alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) alarmModelIndex 6 alarmModelState 2 alarmModelNotificationId RisingAlarm alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "RMON Rising Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree alarmIndex alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) Chisholm & Romascanu Standards Track [Page 66] RFC 3877 Alarm MIB September 2004 6.6. The Lifetime of an Alarm The following example demonstrates the relationship between the active alarm table, the clear alarm table and the Notification Log MIB. Consider a system with alarms modelled as in example 1 and which also supports the informational Notification dsx3LineStatusChange. dsx3LineStatusChange NOTIFICATION-TYPE OBJECTS { dsx3LineStatus, dsx3LineStatusLastChange } STATUS current DESCRIPTION "A dsx3LineStatusChange trap is sent when the value of an instance of dsx3LineStatus changes. It can be utilized by an NMS to trigger polls. When the line status change results in a lower level line status change (i.e., ds1), then no traps for the lower level are sent." ::= { ds3Traps 0 1 } 0. At system start, the active alarm table, alarm clear table and the Notification Log are all empty. ___________________________ _______________________ | alarmActiveTable | | nlmLogTable | |---------------------------| |-----------------------| | alarmActiveIndex | alarm | | nlmLogPointer | notif.| |---------------------------| |-----------------------| |___________________________| |_______________________| __________________________________________________ | alarmClearTable | |--------------------------------------------------| | alarmClear Index | alarm | |--------------------------------------------------| | | | |__________________________________________________| Chisholm & Romascanu Standards Track [Page 67] RFC 3877 Alarm MIB September 2004 1. Some time later, a link goes down generating a linkDown Notification, which is sent out and logged in the Notification Log. As this Notification is modelled as an alarm state, an entry is added to the active alarm table. __________________________________________________ | alarmActiveTable | |--------------------------------------------------| | alarmActiveIndex | alarm | |--------------------------------------------------| | 1 | link down - problem confirmed | |__________________________________________________| _______________________________________________ | nlmLogTable | |-----------------------------------------------| | nlmLogPointer | Notification | |-----------------------------------------------| | 1 | linkdown | |_______________________________________________| __________________________________________________ | alarmClearTable | |--------------------------------------------------| | alarmClear Index | alarm | |--------------------------------------------------| | | | |__________________________________________________| Chisholm & Romascanu Standards Track [Page 68] RFC 3877 Alarm MIB September 2004 2. Some time later, the value of an instance of dsx3LineStatus changes. This Notification is sent out and logged. As this is not modelled into an alarm state, the active alarm table remains unchanged. __________________________________________________ | alarmActiveTable | |--------------------------------------------------| | alarmActiveIndex | alarm | |--------------------------------------------------| | 1 | linkDown - problem confirmed | |__________________________________________________| _____________________________________________ | nlmLogTable | |---------------------------------------------| | nlmLogPointer | Notification | |---------------------------------------------| | 1 | linkDown | | 2 | dsx3LineStatusChange | |_____________________________________________| __________________________________________________ | alarmClearTable | |--------------------------------------------------| | alarmClear Index | alarm | |--------------------------------------------------| | | | |__________________________________________________| Chisholm & Romascanu Standards Track [Page 69] RFC 3877 Alarm MIB September 2004 3. Some time later, the link goes back up. A linkUp Notification is sent out and logged. As this Notification models the clear alarm for this alarm, the alarm entry is remove from the active alarm table. An entry is added to the clear alarm table. __________________________________________________ | alarmActiveTable | |--------------------------------------------------| | alarmActiveIndex | alarm | |--------------------------------------------------| |__________________________________________________| _____________________________________________ | nlmLogTable | |---------------------------------------------| | nlmLogPointer | Notification | |---------------------------------------------| | 1 | linkDown | | 2 | dsx3LineStatusChange | | 3 | linkUp | |_____________________________________________| __________________________________________________ | alarmClearTable | |--------------------------------------------------| | alarmClear Index | alarm | |--------------------------------------------------| | 1 | linkDown - confirmed problem | |__________________________________________________| 7. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The following objects are defined with a MAX-ACCESS clause of read- write or read-create: alarmModelNotificationId, alarmModelVarbindIndex, alarmModelVarbindValue, alarmModelDescription, alarmModelSpecificPointer, alarmModelVarbindSubtree, alarmModelResourcePrefix, alarmModelRowStatus, alarmClearMaximum, ituAlarmEventType, ituAlarmProbableCause, ituAlarmAdditionalText, and ituAlarmGenericModel. Chisholm & Romascanu Standards Track [Page 70] RFC 3877 Alarm MIB September 2004 Note that setting the value of alarmClearMaximum too low may result in security related alarms history being prematurely lost. Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model's related alarms in the system. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network. Although the use of community strings in SNMPv1 is not considered an effective means of providing security, security administrators SHOULD consider whether the fact that alarmActiveContextName can reveal community string values would make this object sensitive in their environment. This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects Chisholm & Romascanu Standards Track [Page 71] RFC 3877 Alarm MIB September 2004 alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource. For further discussion of security, see section 3.4. 8. Acknowledgements This document is a product of the DISMAN Working Group. 9. References 9.1. Normative References [M.3100] ITU Recommendation M.3100, "Generic Network Information Model", 1995 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC1215] Rose, M., "A Convention for defining traps for use with the SNMP", RFC 1215, March 1991. [RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Chisholm & Romascanu Standards Track [Page 72] RFC 3877 Alarm MIB September 2004 [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. [X.733] ITU Recommendation X.733, "Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function", 1992. [X.736] ITU Recommendation X.736, "Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function", 1992. 9.2 Informative References [RFC1657] Willis, S., Burruss, J. and J. Chu, Ed., "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. [RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (version 2)", RFC 2737, December 1999. [RFC2819] Waldbusser, S. "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. Chisholm & Romascanu Standards Track [Page 73] RFC 3877 Alarm MIB September 2004 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2863, June 2000. [RFC2981] Kavasseri, R., Ed., "Event MIB", RFC 2981, October 2000. [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3805] Bergman, R., Lewis, H. and I. McDonald, "Printer MIB v2", RFC 3805, June 2004. 10. Authors' Addresses Sharon Chisholm Nortel Networks PO Box 3511, Station C Ottawa, Ontario, K1Y 4H7 Canada EMail: schishol@nortelnetworks.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Phone: +972-3-645-8414 EMail: dromasca@avaya.com Chisholm & Romascanu Standards Track [Page 74] RFC 3877 Alarm MIB September 2004 11. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Chisholm & Romascanu Standards Track [Page 75] snmp-mibs-downloader-1.1/mibrfcs/rfc3878.txt0000644000000000000000000007456511402176071015614 0ustar Network Working Group H. Lam Request for Comments: 3878 Lucent Technologies Category: Standards Track A. Huynh Cetus Networks D. Perkins SNMPinfo September 2004 Alarm Reporting Control Management Information Base (MIB) 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. ARC MIB Overview . . . . . . . . . . . . . . . . . . . . . . . 2 4.1. Relationship between ARC mode and Alarm Reporting. . . . 4 5. ARC MIB Object Definitions . . . . . . . . . . . . . . . . . . 4 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 Lam, et al. Standards Track [Page 1] RFC 3878 Alarm Reporting Control MIB September 2004 1. Introduction The scope of this MIB is targeted for network operators responsible for managing the operations of network resources. This document defines an alarm reporting control (ARC) MIB module, which provides a mechanism for a manager to suppress or defer the reporting of alarm conditions based on the resource ID and alarm condition type. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 4. ARC MIB Overview There is a need to provide a mechanism for controlling the reporting of alarm conditions of resources in a network device. For example, (a) inhibiting the reporting of alarm conditions of a resource until the resource is problem-free, (b) inhibiting the reporting of alarm conditions of a resource for a specified time period, or (c) inhibiting the reporting of alarm conditions of a resource indefinitely until explicitly allowed by the managing system at a later time. The alarm reporting control (ARC) feature provides an automatic in- service provisioning capability. It allows sufficient time for service setup, customer testing, and other maintenance activities in an "alarm-free" state. Once a resource is "problem-free", alarm reporting can be automatically or manually turned on (i.e., allowed). Lam, et al. Standards Track [Page 2] RFC 3878 Alarm Reporting Control MIB September 2004 By putting a network resource in ARC mode, (i.e., in nalm, nalmTI, nalmQI, or nalmQICD states, as described in the MIB), the technicians and managing systems will not be flooded with unnecessary work items during operations activities such as service provisioning and network setup/teardown. This will reduce maintenance costs and improve the operation and maintenance of these systems. Putting a network resource in ARC mode shall not affect the availability of active alarm condition information for potential retrieval. ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3] provides the business requirements, analysis, and design of the Alarm Reporting Control feature. This document defines the MIB objects to support a subset of the ARC functions described in M.3100 Amd3. In particular, it defines a table that can be used to specify the ARC settings for the resources in a system. Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The ARC MIB module defined in this document provides a way to control the reporting of alarm conditions. A set of applicable alarm conditions is defined in ITU-T Recommendation M.3100 [M.3100] and is named "probable causes". These probable causes (alarm conditions) have been included in the IANAItuProbableCause TC, which is defined in the IANA-ITU-ALARM-TC MIB module [RFC3877]. The IANA-ITU-ALARM-TC MIB module is maintained in the IANA web-site [ITUALARMTC]. [RFC3877]. The ARC MIB module defines an IANAItuProbableCauseOrZero TC which can take any value of IANAItuProbableCause or 0. The ARC MIB module further uses IANAItuProbableCauseOrZero to define the ARC settings for the managed resource in the network elements. Specification of objects for defining and storing alarms, including active and history alarms, standing and transient alarms, and alarm notifications are out of the scope of this document. Lam, et al. Standards Track [Page 3] RFC 3878 Alarm Reporting Control MIB September 2004 4.1. Relationship between ARC mode and alarm reporting When the ARC MIB module is used in a managed system, the following rules apply: For alarm condition raised prior to entering ARC mode, reporting of alarm raised and alarm cleared will be sent as usual. For alarm condition raised after entering ARC mode and also cleared before exiting ARC mode, no reporting of alarm raised will be sent and no reporting of alarm cleared will be sent. For alarm condition raised after entering ARC mode and not cleared when exiting ARC mode, the reporting of alarm raised will be deferred until the moment of exiting ARC mode. The reporting of alarm cleared will be sent as usual (i.e., at the time of alarm cleared). Further details of the ARC function can be found in M.3100 Amd3 [M.3100 Amd3]. 5. ARC MIB Object Definition ARC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] ResourceId FROM ALARM-MIB; -- [RFC3877] arcMibModule MODULE-IDENTITY LAST-UPDATED "200409090000Z" -- September 09, 2004 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "WG EMail: disman@ietf.org Subscribe: disman-request@ietf.org http://www.ietf.org/html.charters/disman-charter.html Chair: Randy Presuhn E-mail: randy_presuhn@mindspring.com Editor: Hing-Kam Lam Lucent Technologies, 4C-616 101 Crawfords Corner Road Lam, et al. Standards Track [Page 4] RFC 3878 Alarm Reporting Control MIB September 2004 Holmdel, NJ 07733 USA Tel: +1 732 949 8338 E-mail: hklam@lucent.com" DESCRIPTION "The MIB module describes the objects for controlling a resource in reporting alarm conditions that it detects. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3878; see the RFC itself for full legal notices." REVISION "200409090000Z" -- September 09, 2004 DESCRIPTION "Initial version, published as RFC 3878." ::={ mib-2 117 } ------------------ -- TEXTUAL-CONVENTION ------------------ IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC can take any value of IANAItuProbableCause or 0. IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC module, which is maintained at the IANA web site and published in the Alarm MIB document (see RFC 3877)." REFERENCE "IANA-ITU-ALARM-TC MIB module as maintained at the IANA web site. The initial module was also published in RFC 3877." -- SYNTAX INTEGER (0..2147483647) ------------------ -- MIB Objects ------------------ arcTimeIntervals OBJECT IDENTIFIER ::= { arcMibModule 1 } arcObjects OBJECT IDENTIFIER ::= { arcMibModule 2 } arcTITimeInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION Lam, et al. Standards Track [Page 5] RFC 3878 Alarm Reporting Control MIB September 2004 "This variable indicates the time interval used for the nalmTI state, in units of second. It is a pre-defined length of time in which the resource will stay in the nalmTI state before transition into the alm state. Instances of this object SHOULD persist across agent restarts." ::= { arcTimeIntervals 1 } arcCDTimeInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the time interval used for the nalmQICD state, in units of second. It is a pre-defined length of time in which the resource will stay in the nalmQICD state before transition into the alm state after it is problem-free. Instances of this object SHOULD persist across agent restarts." ::= { arcTimeIntervals 2 } arcTable OBJECT-TYPE SYNTAX SEQUENCE OF ArcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." REFERENCE "ITU Recommendation M.3100 Amendment 3, 'Generic Network Information Model', January 2001." ::= { arcObjects 1 } arcEntry OBJECT-TYPE SYNTAX ArcEntry Lam, et al. Standards Track [Page 6] RFC 3878 Alarm Reporting Control MIB September 2004 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row that contains information about an ARC setting of a resource in the system. Implementation need to be aware that if the total size of arcIndex and arcNotificationId exceeds 114 sub-IDs, then OIDs of column instances in this table will have more than 128 sub-IDs and cannot be access using SNMPv1, SNMPv2c, or snmpv3." INDEX { arcIndex, arcAlarmType, arcNotificationId } ::= { arcTable 1 } ArcEntry ::= SEQUENCE { arcIndex ResourceId, arcAlarmType IANAItuProbableCauseOrZero, arcNotificationId OBJECT IDENTIFIER, arcState INTEGER, arcNalmTimeRemaining Unsigned32, arcRowStatus RowStatus, arcStorageType StorageType } arcIndex OBJECT-TYPE SYNTAX ResourceId MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a resource, which is under the arcState's control for the associated arcAlarmType. For example, if the resource is an interface, this object will point to an instance of interface, e.g., ifIndex.1." ::= { arcEntry 1 } arcAlarmType OBJECT-TYPE SYNTAX IANAItuProbableCauseOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the alarm condition type controlled by the arcState. It specifies the value 0 or a value of IANAItuProbableCause that is applicable to the resource. IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC module in the Alarm MIB document. Lam, et al. Standards Track [Page 7] RFC 3878 Alarm Reporting Control MIB September 2004 The value of zero (0) implies any probable causes that are applicable to the resource. Usually, the applicable probable causes of a resource are specified in the resource-specific mib." ::= { arcEntry 2 } arcNotificationId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the type of notification to be suppressed. The notification type identified should be the one normally used by the resource for reporting its alarms. When the value of 0.0 is specified for this object, it implies all applicable notification types." ::= { arcEntry 3 } arcState OBJECT-TYPE SYNTAX INTEGER { nalm (1), nalmQI (2), nalmTI (3), nalmQICD (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. Lam, et al. Standards Track [Page 8] RFC 3878 Alarm Reporting Control MIB September 2004 nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." ::= { arcEntry 4 } arcNalmTimeRemaining OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the time remaining in the nalmTI state or the nalmQICD state, in units of second. At the moment the resource enters the nalmTI state, this variable will have the initial value equal to the value of Lam, et al. Standards Track [Page 9] RFC 3878 Alarm Reporting Control MIB September 2004 arcNalmTITimeInterval and then starts decrementing as time goes by. Similarly at the moment the resource enters the nalmQICD state, this variable will have the initial value equal to the value of arcNalmCDTimeInterval and then starts decrementing as time goes by. This variable is read-create and thus will allow the manager to write (extend or shorten), as needed, the remaining time when the resource is in the nalmTI or nalmQICD state. If this variable is supported and the resource is currently not in the nalmTI nor nalmQICD state, the value of this variable shall equal to zero." ::= { arcEntry 5 } arcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This columnar object is used for creating and deleting a conceptual row of the arcTable. It is used to create and delete an arc setting. Setting RowStatus to createAndGo or createAndWait implies creating a new ARC setting for the specified resource and alarm type. Setting RowStatus to destroy implies removing the ARC setting and thus has the effect of resuming normal reporting behaviour of the resource for the alarm type. Only the objects arcState, arcNalmTimeRemaining, and arcRowStatus can be updated when a row is active. All the objects, except arcNalmTimeRemaining, must be set before the row can be activated." ::= { arcEntry 6 } arcStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' must allow write-access at a minimum to arcState. Note that arcState must allow change by management request. Therefore, no row can be created with 'readOnly'. If a set operation tries to set the value to 'readOnly', then an 'inconsistentValue' error must be returned." DEFVAL { nonVolatile } Lam, et al. Standards Track [Page 10] RFC 3878 Alarm Reporting Control MIB September 2004 ::= { arcEntry 7} -------------------------- -- conformance information -------------------------- arcConformance OBJECT IDENTIFIER ::= { arcMibModule 3 } arcCompliances OBJECT IDENTIFIER ::= { arcConformance 1 } arcCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems supporting the ARC MIB module." MODULE -- this module MANDATORY-GROUPS { arcSettingGroup } OBJECT arcStorageType WRITE-SYNTAX StorageType { volatile(2), nonVolatile(3), permanent(4) } DESCRIPTION "Support for value 'other' is not required. The arcState object must allow change by management request. Therefore, no row can be created with 'readOnly'." GROUP arcTIGroup DESCRIPTION "This group is REQUIRED for ARC settings that provide the Time Inhibit (TI) function." GROUP arcQICDGroup DESCRIPTION "This group is REQUIRED for ARC settings that provide the Quality Inhibit (QI) Count Down (CD) function." ::= { arcCompliances 1 } arcGroups OBJECT IDENTIFIER ::= { arcConformance 2 } Lam, et al. Standards Track [Page 11] RFC 3878 Alarm Reporting Control MIB September 2004 arcSettingGroup OBJECT-GROUP OBJECTS { arcState, arcRowStatus, arcStorageType } STATUS current DESCRIPTION "A collection of objects applicable to basic ARC setting." ::= { arcGroups 1} arcTIGroup OBJECT-GROUP OBJECTS { arcTITimeInterval, arcNalmTimeRemaining } STATUS current DESCRIPTION "A collection of objects applicable to ARC setting that support the Time Inhibit (TI) function." ::= { arcGroups 2} arcQICDGroup OBJECT-GROUP OBJECTS { arcCDTimeInterval, arcNalmTimeRemaining } STATUS current DESCRIPTION "A collection of objects applicable to ARC setting that support the Quality Inhibit (QI) Count Down (CD) function." ::= { arcGroups 3} END Lam, et al. Standards Track [Page 12] RFC 3878 Alarm Reporting Control MIB September 2004 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: arcTITimeInterval, arcCDTimeInterval, arcState, arcNalmTimeRemaining, arcRowStatus, arcStorageType. Setting these objects may have disruptive effects on network operation that range from omission of alarm notifications to flooding of unwanted alarm notifications from the network. The consequence of suppressing or deferring the reporting of an alarm can prevent the timely delivery of important diagnostic information, including information that can help identify an attack. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: arcTITimeInterval, arcCDTimeInterval, arcState, arcNalmTimeRemaining, arcRowStatus, arcStorageType. Reading these objects will provide information about the setting which affects alarm notification generation. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Lam, et al. Standards Track [Page 13] RFC 3878 Alarm Reporting Control MIB September 2004 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Acknowledgements The authors wish to thank Brian Teer and Sharon Chisholm for reviewing and commenting on this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004. [ITUALARMTC] http://www.iana.org/assignments/ianaitualarmtc-mib [M.3100] ITU Recommendation M.3100, "Generic Network Information Model", July 1995. [M.3100 Amd3] ITU Recommendation M.3100 Amendment 3, "Generic Network Information Model", January 2001. Lam, et al. Standards Track [Page 14] RFC 3878 Alarm Reporting Control MIB September 2004 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 9. Authors' Addresses Hing-Kam Lam Lucent Technologies 101 Crawfords Corner Road, Room 4C-616 Holmdel, NJ 07733 USA Phone: +1 732-949-8338 EMail: hklam@lucent.com An-ni Huynh Cetus Networks USA EMail: a_n_huynh@yahoo.com David T. Perkins 548 Quailbrook Ct San Jose, CA 95110 USA Phone: +1 408-394-8702 EMail: dperkins@snmpinfo.com Lam, et al. Standards Track [Page 15] RFC 3878 Alarm Reporting Control MIB September 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lam, et al. Standards Track [Page 16] snmp-mibs-downloader-1.1/mibrfcs/rfc3896.txt0000644000000000000000000037501311402176071015604 0ustar Network Working Group O. Nicklass, Ed. Request for Comments: 3896 RAD Data Communications, Ltd. Obsoletes: 2496 September 2004 Category: Standards Track Definitions of Managed Objects for the DS3/E3 Interface Type 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2496. Table of Contents 1. The Internet Standard Management Framework. . . . . . . . . . 2 1.1. Changes from RFC 2496 . . . . . . . . . . . . . . . . . 2 1.2. Changes from RFC 1407 . . . . . . . . . . . . . . . . . 3 1.3. Companion Documents . . . . . . . . . . . . . . . . . . 4 2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Use of ifTable for DS3 Layer . . . . . . . . . . . . . 4 2.2. Usage Guidelines. . . . . . . . . . . . . . . . . . . . 5 2.2.1. Usage of ifStackTable . . . . . . . . . . . . . 5 2.2.2. Usage of Channelization for DS3, DS1, DS0 . . . 7 2.2.3. Usage of Channelization for DS3, DS2, DS1 . . . 8 2.2.4. Usage of Loopbacks . . . . . . . . . . . . . . 9 2.3. Objectives of this MIB Module . . . . . . . . . . . . . 10 2.4. DS3/E3 Terminology . . . . . . . . . . . . . . . . . . 10 2.4.1. Error Events. . . . . . . . . . . . . . . . . . 10 2.4.2. Performance Parameters. . . . . . . . . . . . . 11 2.4.3. Performance Defects . . . . . . . . . . . . . . 14 Nicklass Standards Track [Page 1] RFC 3896 DS3/E3 MIB September 2004 2.4.4. Other Terms . . . . . . . . . . . . . . . . . . 16 3. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 16 4. Appendix A - Use of the dsx3IfIndex and dsx3LineIndex. . . . . 54 5. Appendix B - The delay approach to Unavailable Seconds . . . . 56 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 58 7.2. Informative References . . . . . . . . . . . . . . . . . 59 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 60 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 62 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 63 1. The Internet Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.1. Changes from RFC 2496 The changes from [RFC2496] are the following: (1) The dsx3FracIfIndex SYNTAX matches the description range. (2) Reference was added to Circuit Identifier object. (3) Usage of ifStackTable section was updated. (4) Align the DESCRIPTION clauses of few statistic objects with the near end definition, the far end definition and with [RFC3593]. (5) Add new value, dsx3M13, to dsx3LineType. Nicklass Standards Track [Page 2] RFC 3896 DS3/E3 MIB September 2004 1.2. Changes from RFC 1407 The changes from RFC 1407 are the following: (1) The Fractional Table has been deprecated. (2) This document uses SMIv2. (3) Values are given for ifTable and ifXTable. (4) Example usage of ifStackTable is included. (5) dsx3IfIndex has been deprecated. (6) The definition of valid intervals has been clarified for the case where the agent proxied for other devices. In particular, the treatment of missing intervals has been clarified. (7) An inward loopback has been added. (8) Additional lineStatus bits have been added for Near End in Unavailable Signal State, Carrier Equipment Out of Service. (9) A read-write line Length object has been added. (10) Added a lineStatus last change, trap and enabler. (11) Textual Conventions for statistics objects have been used. (12) A new object, dsx3LoopbackStatus, has been introduced to reflect the loopbacks established on a DS3/E3 interface and the source to the requests. dsx3LoopbackConfig continues to be the desired loopback state while dsx3LoopbackStatus reflects the actual state. (13) A dual loopback has been added to allow the setting of an inward loopback and a line loopback at the same time. (14) An object has been added to indicated whether or not this is a channelized DS3/E3. (15) A new object has been added to indicate which DS1 is to set for remote loopback. Nicklass Standards Track [Page 3] RFC 3896 DS3/E3 MIB September 2004 1.3. Companion Documents This document is a companion to the documents that define Managed Objects for the DS0 [RFC2494], DS1/E1/DS2/E2 [RFC3895], and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) [RFC3592] Interface Types. 2. Overview These objects are used when the particular media being used to realize an interface is a DS3/E3 interface. At present, this applies to these values of the ifType variable in the Internet-standard MIB: ds3 (30) The DS3 definitions contained herein are based on the DS3 specifications in ANSI T1.102-1987 [ANSI-T1.102], ANSI T1.107-1988 [ANSI-T1.107], ANSI T1.107a-1990 [ANSI-T1.107a], and ANSI T1.404-1989 [ANSI-T1.404]. The E3 definitions contained herein are based on the E3 specifications in CCITT G.751 [CCITT-G.751] and ETSI T/NA(91)18 [ETSI-T/NA(91)18]. 2.1. Use of ifTable for DS3 Layer Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for DS3 Layer =================================================================== ifIndex Interface index. ifDescr See interfaces MIB [RFC2863] ifType ds3(30) ifSpeed Speed of line rate DS3 - 44736000 E3 - 34368000 ifPhysAddress The value of the Circuit Identifier. If no Circuit Identifier has been assigned this object should have an octet string with zero length. ifAdminStatus See interfaces MIB [RFC2863] ifOperStatus See interfaces MIB [RFC2863] ifLastChange See interfaces MIB [RFC2863] Nicklass Standards Track [Page 4] RFC 3896 DS3/E3 MIB September 2004 ifName See interfaces MIB [RFC2863] ifLinkUpDownTrapEnable Set to enabled(1). ifHighSpeed Speed of line in Mega-bits per second (either 45 or 34) ifConnectorPresent Set to true(1) normally, except for cases such as DS3/E3 over AAL1/ATM where false(2) is appropriate 2.2. Usage Guidelines 2.2.1. Usage of ifStackTable The object dsx3IfIndex has been deprecated. This object previously allowed a very special proxy situation to exist for Routers and CSUs. This section now describes how to use ifStackTable to represent this relationship. The paragraphs discussing dsx3IfIndex and dsx3LineIndex have been preserved in Appendix A for informational purposes. The ifStackTable is used in the proxy case to represent the association between pairs of interfaces, e.g., this DS3 is attached to that DS3. This use is consistent with the use of the ifStackTable to show the association between various sub-layers of an interface. In both cases entire PDUs are exchanged between the interface pairs - in the case of a DS3, entire DS3 frames are exchanged; in the case of PPP and HDLC, entire HDLC frames are exchanged. This usage is not meant to suggest the use of the ifStackTable to represent Time Division Multiplexing (TDM) connections in general. External&Internal interface scenario: the SNMP Agent resides on a host external from the device supporting DS3/E3 interfaces (e.g., a router). The Agent represents both the host and the DS3/E3 device. Nicklass Standards Track [Page 5] RFC 3896 DS3/E3 MIB September 2004 Example: A shelf full of CSUs connected to a Router. An SNMP Agent residing on the router proxies for itself and the CSU. The router has also an Ethernet interface: +-----+ | | | | | | +---------------------+ |E | | 44.736 MBPS | ds3 M13 Line#A | ds3 C-bit Parity |t | R |---------------+ - - - - - - - - - +------> |h | | | | |e | O | 44.736 MBPS | ds3 M13 Line#B | ds3 C-bit Parity |r | |---------------+ - - - - - - - - - - +------> |n | U | | | |e | | 44.736 MBPS | ds3 M13 Line#C | ds3 C-bit Parity |t | T |---------------+ - - - -- -- - - - - +------> | | | | | |-----| E | 44.736 MBPS | ds3 M13 Line#D | ds3 C-bit Parity | | |---------------+ - - - - -- - - - - +------> | | R | |_____________________| | | | | +-----+ The assignment of the index values could for example be: ifIndex Description 1 Ethernet 2 Line#A Router 3 Line#B Router 4 Line#C Router 5 Line#D Router 6 Line#A CSU Router 7 Line#B CSU Router 8 Line#C CSU Router 9 Line#D CSU Router 10 Line#A CSU Network 11 Line#B CSU Network 12 Line#C CSU Network 13 Line#D CSU Network Nicklass Standards Track [Page 6] RFC 3896 DS3/E3 MIB September 2004 The ifStackTable is then used to show the relationships between the various DS3 interfaces. ifStackTable Entries HigherLayer LowerLayer 2 6 3 7 4 8 5 9 6 10 7 11 8 12 9 13 If the CSU shelf is managed by itself by a local SNMP Agent, the situation would be identical, except the Ethernet and the 4 router interfaces are deleted. Interfaces would also be numbered from 1 to 8. ifIndex Description 1 Line#A CSU Router 2 Line#B CSU Router 3 Line#C CSU Router 4 Line#D CSU Router 5 Line#A CSU Network 6 Line#B CSU Network 7 Line#C CSU Network 8 Line#D CSU Network ifStackTable Entries HigherLayer LowerLayer 1 5 2 6 3 7 4 8 2.2.2. Usage of Channelization for DS3, DS1, DS0 An example is given here to explain the channelization objects in the DS3, DS1, and DS0 MIBs to help the implementor use the objects correctly. Treatment of E3 and E1 would be similar, with the number of DS0s being different depending on the framing of the E1. Nicklass Standards Track [Page 7] RFC 3896 DS3/E3 MIB September 2004 Assume that a DS3 (with ifIndex 1) is Channelized into DS1s (without DS2s). The object dsx3Channelization is set to enabledDs1. When this object is set to enabledDS1, 28 ifEntries of type DS1 will be created by the agent. If dsx3Channelization is set to disabled, then the DS1s are destroyed. Assume the entries in the ifTable for the DS1s are created in channel order and the ifIndex values are 2 through 29. In the DS1 MIB, there will be an entry in the dsx1ChanMappingTable for each ds1. The entries will be as follows: dsx1ChanMappingTable Entries ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex 1 1 2 1 2 3 ...... 1 28 29 In addition, the DS1s are channelized into DS0s. The object dsx1Channelization is set to enabledDS0 for each DS1. There will be 24 DS0s in the ifTable for each DS1. Assume the entries in the ifTable are created in channel order and the ifIndex values for the DS0s in the first DS1 are 30 through 53. In the DS0 MIB [RFC2494], there will be an entry in the dsx0ChanMappingTable for each DS0. The entries will be as follows: dsx0ChanMappingTable Entries ifIndex dsx0Ds0ChannelNumber dsx0ChanMappedIfIndex 2 1 30 2 2 31 ...... 2 24 53 2.2.3. Usage of Channelization for DS3, DS2, DS1 An example is given here to explain the channelization objects in the DS3 and DS1 MIBs to help the implementor use the objects correctly. Assume that a DS3 (with ifIndex 1) is Channelized into DS2s. The object dsx3Channelization is set to enabledDs2. There will be 7 DS2s (ifType of DS1) in the ifTable. Assume the entries in the ifTable for the DS2s are created in channel order and the ifIndex values are 2 through 8. In the DS1 MIB [RFC3895], there will be an entry in the dsx1ChanMappingTable for each DS2. The entries will be as follows: Nicklass Standards Track [Page 8] RFC 3896 DS3/E3 MIB September 2004 dsx1ChanMappingTable Entries ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex 1 1 2 1 2 3 ...... 1 7 8 In addition, the DS2s are channelized into DS1s. The object dsx1Channelization is set to enabledDS1 for each DS2. There will be 4 DS1s in the ifTable for each DS2. Assume the entries in the ifTable are created in channel order and the ifIndex values for the DS1s in the first DS2 are 9 through 12, then 13 through 16 for the second DS2, and so on. In the DS1 MIB, there will be an entry in the dsx1ChanMappingTable for each DS1. The entries will be as follows: dsx1ChanMappingTable Entries ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex 2 1 9 2 2 10 2 3 11 2 4 12 3 1 13 3 2 14 ... 8 4 36 2.2.4. Usage of Loopbacks This section discusses the behaviour of objects related to loopbacks. The object dsx3LoopbackConfig represents the desired state of loopbacks on this interface. Using this object a Manager can request: LineLoopback PayloadLoopback (if ESF framing) InwardLoopback DualLoopback (Line + Inward) NoLoopback The remote end can also request lookbacks either through the FDL channel if ESF or inband if D4. The loopbacks that can be requested this way are: LineLoopback PayloadLoopback (if ESF framing) NoLoopback Nicklass Standards Track [Page 9] RFC 3896 DS3/E3 MIB September 2004 To model the current state of loopbacks on a DS3 interface, the object dsx3LoopbackStatus defines which loopback is currently applied to an interface. This object, which is a bitmap, will have bits turned on which reflect the currently active loopbacks on the interface as well as the source of those loopbacks. The following restrictions/rules apply to loopbacks: The far end cannot undo loopbacks set by a manager. A manager can undo loopbacks set by the far end. Both a line loopback and an inward loopback can be set at the same time. Only these two loopbacks can co-exist and either one may be set by the manager or the far end. A LineLoopback request from the far end is incremental to an existing Inward loopback established by a manager. When a NoLoopback is received from the far end in this case, the InwardLoopback remains in place. 2.3. Objectives of this MIB Module There are numerous things that could be included in a MIB for DS3/E3 signals: the management of multiplexors, CSUs, DSUs, and the like. The intent of this document is to facilitate the common management of all devices with DS3/E3 interfaces. As such, a design decision was made up front to very closely align the MIB with the set of objects that can generally be read from DS3/E3 devices that are currently deployed. 2.4. DS3/E3 Terminology The terminology used in this document to describe error conditions on a DS3 interface as monitored by a DS3 device are based on the late but not final draft of what became the ANSI T1.231 standard [ANSI- T1.231]. If the definition in this document does not match the definition in the ANSI T1.231 document, the implementer should follow the definition described in this document. 2.4.1. Error Events Bipolar Violation (BPV) Error Event A bipolar violation error event, for B3ZS(HDB3)-coded signals, is the occurrence of a pulse of the same polarity as the previous pulse without being part of the zero substitution code, B3ZS(HDB3). For B3ZS(HDB3)-coded signals, a bipolar violation error event may also include other error patterns such as: three(four) or more consecutive zeros and incorrect polarity (See T1.231 section 7.1.1.1.1). Nicklass Standards Track [Page 10] RFC 3896 DS3/E3 MIB September 2004 Excessive Zeros (EXZ) Error Event An EXZ is the occurrence of any zero string length equal to or greater than 3 for B3ZS, or greater than 4 for HDB3 (See T1.231 section 7.1.1.1.2). Line Coding Violation (LCV) Error Event This parameter is a count of both BPVs and EXZs occurring over the accumulation period. An EXZ increments the LCV by one regardless of the length of the zero string. (Also known as CV-L. See T1.231 section 7.4.1.1.) P-bit Coding Violation (PCV) Error Event For all DS3 applications, a coding violation error event is a P-bit Parity Error event. A P-bit Parity Error event is the occurrence of a received P-bit code on the DS3 M-frame that is not identical to the corresponding locally-calculated code (See T1.231 section 7.1.1.2.1). C-bit Coding Violation (CCV) Error Event For C-bit Parity and SYNTRAN DS3 applications, this is the count of coding violations reported via the C-bits. For C-bit Parity, it is a count of CP-bit parity errors occurring in the accumulation interval. For SYNTRAN, it is a count of CRC-9 errors occurring in the accumulation interval (See T1.231 section 7.1.1.2.2). 2.4.2. Performance Parameters All performance parameters are accumulated in fifteen minute intervals and up to 96 intervals (24 hours worth) are kept by an agent. Fewer than 96 intervals of data will be available if the agent has been restarted within the last 24 hours. In addition, there is a rolling 24-hour total of each performance parameter. There is no requirement for an agent to ensure fixed relationship between the start of a fifteen minute interval and any wall clock; however some agents may align the fifteen minute intervals with quarter hours. Performance parameters are of types PerfCurrentCount, PerfIntervalCount and PerfTotalCount. These textual conventions are all Gauge32, and they are used because it is possible for these objects to decrease. Objects may decrease when Unavailable Seconds occurs across a fifteen minutes interval boundary. See Unavailable Seconds discussion later in this section. Nicklass Standards Track [Page 11] RFC 3896 DS3/E3 MIB September 2004 Line Errored Seconds (LES) A Line Errored Second is a second in which one or more CV occurred OR one or more LOS defects. (Also known as ES-L. See T1.231 section 7.4.1.2.) P-bit Errored Seconds (PES) An PES is a second with one or more PCVs OR one or more Out of Frame defects OR a detected incoming AIS. This gauge is not incremented when UASs are counted. (Also known as ESP-P. See T1.231 section 7.4.2.2.) P-bit Severely Errored Seconds (PSES) A PSES is a second with 44 or more PCVs OR one or more Out of Frame defects OR a detected incoming AIS. This gauge is not incremented when UASs are counted. (Also known as SESP-P. See T1.231 section 7.4.2.5.) C-bit Errored Seconds (CES) An CES is a second with one or more CCVs OR one or more Out of Frame defects OR a detected incoming AIS. This count is only for the SYNTRAN and C-bit Parity DS3 applications. This gauge is not incremented when UASs are counted. (Also known as ESCP-P. See T1.231 section 7.4.2.2.) C-bit Severely Errored Seconds (CSES) A CSES is a second with 44 or more CCVs OR one or more Out of Frame defects OR a detected incoming AIS. This count is only for the SYNTRAN and C-bit Parity DS3 applications. This gauge is not incremented when UASs are counted. (Also known as SESCP-P. See T1.231 section 7.4.2.5.) Severely Errored Framing Seconds (SEFS) A SEFS is a second with one or more Out of Frame defects OR a detected incoming AIS. This item is not incremented during unavailable seconds. (Also known as SAS-P. See T1.231 section 7.4.2.6.) Unavailable Seconds (UAS) UAS are calculated by counting the number of seconds that the interface is unavailable. The DS3 interface is said to be unavailable from the onset of 10 contiguous PSESs, or the onset of the condition leading to a failure (see Failure States). If the condition leading to the failure was immediately preceded by one or more contiguous PSESs, then the DS3 interface unavailability starts from the onset of these PSESs. Once unavailable, and if no failure is present, the DS3 interface becomes available at the onset of 10 contiguous seconds with no PSESs. Once unavailable, and if a Nicklass Standards Track [Page 12] RFC 3896 DS3/E3 MIB September 2004 failure is present, the DS3 interface becomes available at the onset of 10 contiguous seconds with no PSESs, if the failure clearing time is less than or equal to 10 seconds. If the failure clearing time is more than 10 seconds, the DS3 interface becomes available at the onset of 10 contiguous seconds with no PSESs, or the onset period leading to the successful clearing condition, whichever occurs later. With respect to the DS3 error counts, all counters are incremented while the DS3 interface is deemed available. While the interface is deemed unavailable, the only count that is incremented is UASs. Note that this definition implies that the agent cannot determine until after a ten second interval has passed whether a given one-second interval belongs to available or unavailable time. If the agent chooses to update the various performance statistics in real time then it must be prepared to retroactively reduce the PES, PSES, CES, and CSES counts by 10 and increase the UAS count by 10 when it determines that available time has been entered. It must also be prepared to adjust the PCV, CCV, and SEFS count as necessary since these parameters are not accumulated during unavailable time. Similarly, it must be prepared to retroactively decrease the UAS count by 10 and increase the PES, CES, PCV, and CCV counts as necessary upon entering available time. A special case exists when the 10 second period leading to available or unavailable time crosses a 900 second statistics window boundary, as the foregoing description implies that the PCV, CCV, PES, CES, PSES, CSEC, SEFS, and UAS counts for the PREVIOUS interval must be adjusted. In this case successive GETs of the affected dsx3IntervalPSESs and dsx3IntervalUASs objects will return differing values if the first GET occurs during the first few seconds of the window. The agent may instead choose to delay updates to the various statistics by 10 seconds in order to avoid retroactive adjustments to the counters. A way to do this is sketched in Appendix B. In any case, a linkDown trap shall be sent only after the agent has determined for certain that the unavailable state has been entered, but the time on the trap will be that of the first UAS (i.e., 10 seconds earlier). A linkUp trap shall be handled similarly. According to [ANSI-T1.231] unavailable time begins at the _onset_ of 10 contiguous severely errored seconds -- that is, unavailable time starts with the _first_ of the 10 contiguous SESs. Also, while an interface is deemed unavailable all counters for that interface are Nicklass Standards Track [Page 13] RFC 3896 DS3/E3 MIB September 2004 frozen except for the UAS count. It follows that an implementation which strictly complies with this standard must _not_ increment any counters other than the UAS count -- even temporarily -- as a result of anything that happens during those 10 seconds. Since changes in the signal state lag the data to which they apply by 10 seconds, an ANSI-compliant implementation must pass the one-second statistics through a 10-second delay line prior to updating any counters. That can be done by performing the following steps at the end of each one second interval. i) Read near/far end CV counter and alarm status flags from the hardware. ii) Accumulate the CV counts for the preceding second and compare them to the ES and SES threshold for the layer in question. Update the signal state and shift the one-second CV counts and ES/SES flags into the 10-element delay line. Note that far-end one-second statistics are to be flagged as "absent" during any second in which there is an incoming defect at the layer in question or at any lower layer. iii) Update the current interval statistics using the signal state from the _previous_ update cycle and the one-second CV counts and ES/SES flags shifted out of the 10-element delay line. This approach is further described in Appendix B. 2.4.3. Performance Defects Failure States: The Remote Alarm Indication (RAI) failure, in SYNTRAN applications, is declared after detecting the Yellow Alarm Signal on the alarm channel. See ANSI T1.107a-1990 [ANSI- T1.107a]. The Remote Alarm Indication failure, in C-bit Parity DS3 applications, is declared as soon as the presence of either one or two alarm signals are detected on the Far End Alarm Channel. See [ANSI-T1.107]. The Remote Alarm Indication failure may also be declared after detecting the far-end SEF/AIS defect (aka yellow). The Remote Alarm Indication failure is cleared as soon as the presence of the any of the above alarms are removed. Also, the incoming failure state is declared when a defect persists for at least 2-10 seconds. The defects are the following: Loss of Signal (LOS), an Out of Frame (OOF) or an incoming Alarm Indication Signal (AIS). The Failure State is cleared when the defect is absent for less than or equal to 20 seconds. Nicklass Standards Track [Page 14] RFC 3896 DS3/E3 MIB September 2004 Far End SEF/AIS defect (aka yellow) A Far End SEF/AIS defect is the occurrence of the two X-bits in a M-frame set to zero. The Far End SEF/AIS defect is terminated when the two X-bits in a M-frame are set to one. (Also known as SASCP-PFE. See T1.231 section 7.4.4.2.6) Out of Frame (OOF) defect A DS3 OOF defect is detected when any three or more errors in sixteen or fewer consecutive F-bits occur within a DS3 M- frame. An OOF defect may also be called a Severely Errored Frame (SEF) defect. An OOF defect is cleared when reframe occurs. A DS3 Loss of Frame (LOF) failure is declared when the DS3 OOF defect is consistent for 2 to 10 seconds. The DS3 OOF defect ends when reframe occurs. The DS3 LOF failure is cleared when the DS3 OOF defect is absent for 10 to 20 seconds. (See T1.231 section 7.1.2.2.1) An E3 OOF defect is detected when four consecutive frame alignment signals have been incorrectly received in there predicted positions in an E3 signal. E3 frame alignment occurs when the presence of three consecutive frame alignment signals have been detected. Loss of Signal (LOS) defect The DS3 LOS defect is declared upon observing 175 +/- 75 contiguous pulse positions with no pulses of either positive or negative polarity. The DS3 LOS defect is terminated upon observing an average pulse density of at least 33% over a period of 175 +/- 75 contiguous pulse positions starting with the receipt of a pulse. (See T1.231 section 7.1.2.1.1) Alarm Indication Signal (AIS) defect The DS3 AIS is framed with "stuck stuffing." This implies that it has a valid M-subframe alignments bits, M-frame alignment bits, and P bits. The information bits are set to a 1010... sequence, starting with a one (1) after each M- subframe alignment bit, M-frame alignment bit, X bit, P bit, and C bit. The C bits are all set to zero giving what is called "stuck stuffing." The X bits are set to one. The DS3 AIS defect is declared after DS3 AIS is present in contiguous M-frames for a time equal to or greater than T, where 0.2 ms <= T <= 100 ms. The DS3 AIS defect is terminated after AIS is absent in contiguous M-frames for a time equal to or greater than T. (See T1.231 section 7.1.2.2.3) Nicklass Standards Track [Page 15] RFC 3896 DS3/E3 MIB September 2004 The E3 binary content of the AIS is nominally a continuous stream of ones. AIS detection and the application of consequent actions, should be completed within a time limit of 1 ms. 2.4.4. Other Terms Circuit Identifier This is a character string specified by the circuit vendor, and is useful when communicating with the vendor during the troubleshooting process (see M.1400 [ITU-T-M.1400] for additional information). Proxy In this document, the word proxy is meant to indicate an application which receives SNMP messages and replies to them on behalf of the devices which implement the actual DS3/E3 interfaces. The proxy may have already collected the information about the DS3/E3 interfaces into its local database and may not necessarily forward the requests to the actual DS3/E3 interface. It is expected in such an application that there are periods of time where the proxy is not communicating with the DS3/E3 interfaces. In these instances the proxy will not necessarily have up-to-date configuration information and will most likely have missed the collection of some statistics data. Missed statistics data collection will result in invalid data in the interval table. 3. Object Definitions DS3-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, transmission FROM SNMPv2-SMI -- [RFC2578] DisplayString, TimeStamp, TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndex FROM IF-MIB -- [RFC2863] PerfCurrentCount, PerfIntervalCount, PerfTotalCount FROM PerfHist-TC-MIB; -- [RFC3593] Nicklass Standards Track [Page 16] RFC 3896 DS3/E3 MIB September 2004 ds3 MODULE-IDENTITY LAST-UPDATED "200409080000Z" -- September 08, 2004 ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/atommib-charter.html Mailing Lists: General Discussion: atommib@research.telcordia.com To Subscribe: atommib-request@research.telcordia.com Editor: Orly Nicklass Postal: RAD Data Communications, Ltd. Ziv Tower, 24 Roul Walenberg Tel Aviv, Israel, 69719 Tel: +9723 765 9969 E-mail: orly_n@rad.com" DESCRIPTION "The is the MIB module that describes DS3 and E3 interfaces objects. Copyright (c) The Internet Society (2004). This version of this MIB module is part of RFC 3896; see the RFC itself for full legal notices." REVISION "200409080000Z" -- September 08, 2004 DESCRIPTION "The RFC 3896 version of this MIB module. The key changes made to this MIB module since its publication in RFC 2496 are as follows: (1) The dsx3FracIfIndex SYNTAX matches the description range. (2) Reference was added to Circuit Identifier object. (3) Usage of ifStackTable section was updated. (4) Align the DESCRIPTION clauses of few statistic objects with thenear end definition, the far end definition and with RFC 3593. (5) Add new value, dsx3M13, to dsx3LineType." REVISION "199808012130Z" Nicklass Standards Track [Page 17] RFC 3896 DS3/E3 MIB September 2004 DESCRIPTION "The RFC 2496 version of this MIB module. The key changes made to this MIB module since its publication in RFC 1407 are as follows: (1) The Fractional Table has been deprecated. (2) This document uses SMIv2. (3) Values are given for ifTable and ifXTable. (4) Example usage of ifStackTable is included. (5) dsx3IfIndex has been deprecated. (6) The definition of valid intervals has been clarified for the case where the agent proxied for other devices. In particular, the treatment of missing intervals has been clarified. (7) An inward loopback has been added. (8) Additional lineStatus bits have been added for Near End in Unavailable Signal State, Carrier Equipment Out of Service. (9) A read-write line Length object has been added. (10) Added a lineStatus last change, trap and enabler. (11) Textual Conventions for statistics objects have been used. (12) A new object, dsx3LoopbackStatus, has been introduced to reflect the loopbacks established on a DS3/E3 interface and the source to the requests. dsx3LoopbackConfig continues to be the desired loopback state while dsx3LoopbackStatus reflects the actual state. (13) A dual loopback has been added to allow the setting of an inward loopback and a line loopback at the same time. (14) An object has been added to indicated whether or not this is a channelized DS3/E3. (15) A new object has been added to indicate which DS1 is to set for remote loopback." Nicklass Standards Track [Page 18] RFC 3896 DS3/E3 MIB September 2004 REVISION "199301252028Z" DESCRIPTION "Initial version, published as RFC 1407." ::= { transmission 30 } -- The DS3/E3 Near End Group -- The DS3/E3 Near End Group consists of four tables: -- DS3/E3 Configuration -- DS3/E3 Current -- DS3/E3 Interval -- DS3/E3 Total -- the DS3/E3 Configuration Table dsx3ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3/E3 Configuration table." ::= { ds3 5 } dsx3ConfigEntry OBJECT-TYPE SYNTAX Dsx3ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3/E3 Configuration table." INDEX { dsx3LineIndex } ::= { dsx3ConfigTable 1 } Dsx3ConfigEntry ::= SEQUENCE { dsx3LineIndex InterfaceIndex, dsx3IfIndex InterfaceIndex, dsx3TimeElapsed INTEGER, dsx3ValidIntervals INTEGER, dsx3LineType INTEGER, dsx3LineCoding INTEGER, dsx3SendCode INTEGER, dsx3CircuitIdentifier DisplayString, dsx3LoopbackConfig INTEGER, dsx3LineStatus INTEGER, dsx3TransmitClockSource INTEGER, dsx3InvalidIntervals INTEGER, dsx3LineLength INTEGER, dsx3LineStatusLastChange TimeStamp, Nicklass Standards Track [Page 19] RFC 3896 DS3/E3 MIB September 2004 dsx3LineStatusChangeTrapEnable INTEGER, dsx3LoopbackStatus INTEGER, dsx3Channelization INTEGER, dsx3Ds1ForRemoteLoop INTEGER } dsx3LineIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This object should be made equal to ifIndex. The next paragraph describes its previous usage. Making the object equal to ifIndex allows proper use of ifStackTable. Previously, this object was the identifier of a DS3/E3 Interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS3/E3 interface, it should have the same value as ifIndex. Otherwise, number the dsx3LineIndices with an unique identifier following the rules of choosing a number that is greater than ifNumber and numbering the inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g., network side) with odd numbers." ::= { dsx3ConfigEntry 1 } dsx3IfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This value for this object is equal to the value of ifIndex from the Interfaces table of MIB II (RFC 1213)." ::= { dsx3ConfigEntry 2 } dsx3TimeElapsed OBJECT-TYPE SYNTAX INTEGER (0..899) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that have elapsed since the Nicklass Standards Track [Page 20] RFC 3896 DS3/E3 MIB September 2004 beginning of the near end current error- measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, the agent will return the maximum value." ::= { dsx3ConfigEntry 3 } dsx3ValidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous near end intervals for which data was collected. The value will be 96 unless the interface was brought online within the last 24 hours, in which case the value will be the number of complete 15 minute near end intervals since the interface has been online. In the case where the agent is a proxy, it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { dsx3ConfigEntry 4 } dsx3LineType OBJECT-TYPE SYNTAX INTEGER { dsx3other(1), dsx3M23(2), dsx3SYNTRAN(3), dsx3CbitParity(4), dsx3ClearChannel(5), e3other(6), e3Framed(7), e3Plcp(8), dsx3M13(9) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the variety of DS3 C-bit or E3 application implementing this interface. The type of interface affects the interpretation of the usage and error statistics. The rate of DS3 is 44.736 Mbps and E3 is 34.368 Mbps. The dsx3ClearChannel value means that the C-bits are not used except for sending/receiving AIS. The values, in sequence, describe: Nicklass Standards Track [Page 21] RFC 3896 DS3/E3 MIB September 2004 TITLE: SPECIFICATION: dsx3M23 ANSI T1.107-1988 dsx3SYNTRAN ANSI T1.107-1988 dsx3CbitParity ANSI T1.107a-1990 dsx3ClearChannel ANSI T1.102-1987 e3Framed CCITT G.751 e3Plcp ETSI T/NA(91)18 dsx3M13 ANSI T1.107a-1990." REFERENCE "American National Standard for telecommunications - digital hierarchy - formats specification, ANSI T1.107- 1988. ANSI T1.107a-1990. American National Standard for telecommunications - digital hierarchy - electrical interfaces, ANSI T1.102- 1987. CCITT - Digital Multiplex Equipment Operating at the Third Order Bit Rate of 34 368 Kbit/s and the Forth Order Bit Rate of 139 264 Kbit/s and Using Positive Justification, G.751 European Telecommunications Standards Institute -- ETS '34M' -- Metropolitan Area Network Physical Convergence Layer Procedure for 34.368 Megabits per Second, T/NA(91)18, May 1991." ::= { dsx3ConfigEntry 5 } dsx3LineCoding OBJECT-TYPE SYNTAX INTEGER { dsx3Other(1), dsx3B3ZS(2), e3HDB3(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable describes the variety of Zero Code Suppression used on this interface, which in turn affects a number of its characteristics. dsx3B3ZS and e3HDB3 refer to the use of specified patterns of normal bits and bipolar violations which are used to replace sequences of zero bits of a specified length." ::= { dsx3ConfigEntry 6 } dsx3SendCode OBJECT-TYPE Nicklass Standards Track [Page 22] RFC 3896 DS3/E3 MIB September 2004 SYNTAX INTEGER { dsx3SendNoCode(1), dsx3SendLineCode(2), dsx3SendPayloadCode(3), dsx3SendResetCode(4), dsx3SendDS1LoopCode(5), dsx3SendTestPattern(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates what type of code is being sent across the DS3/E3 interface by the device. (These are optional for E3 interfaces.) Setting this variable causes the interface to begin sending the code requested. The values mean: dsx3SendNoCode sending looped or normal data dsx3SendLineCode sending a request for a line loopback dsx3SendPayloadCode sending a request for a payload loopback (i.e., all DS1/E1s in a DS3/E3 frame) dsx3SendResetCode sending a loopback deactivation request dsx3SendDS1LoopCode requesting to loopback a particular DS1/E1 within a DS3/E3 frame. The DS1/E1 is indicated in dsx3Ds1ForRemoteLoop. dsx3SendTestPattern sending a test pattern." ::= { dsx3ConfigEntry 7 } dsx3CircuitIdentifier OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This variable contains the transmission vendor's circuit identifier, for the purpose of facilitating troubleshooting." Nicklass Standards Track [Page 23] RFC 3896 DS3/E3 MIB September 2004 REFERENCE "ITU-T M.1400" ::= { dsx3ConfigEntry 8 } dsx3LoopbackConfig OBJECT-TYPE SYNTAX INTEGER { dsx3NoLoop(1), dsx3PayloadLoop(2), dsx3LineLoop(3), dsx3OtherLoop(4), dsx3InwardLoop(5), dsx3DualLoop(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable represents the desired loopback configuration of the DS3/E3 interface. The values mean: dsx3NoLoop Not in the loopback state. A device that is not capable of performing a loopback on the interface shall always return this as its value. dsx3PayloadLoop The received signal at this interface is looped through the device. Typically the received signal is looped back for retransmission after it has passed through the device's framing function. dsx3LineLoop The received signal at this interface does not go through the device (minimum penetration) but is looped back out. dsx3OtherLoop Loopbacks that are not defined here. dsx3InwardLoop The sent signal at this interface is looped back through the device. dsx3DualLoop Both dsx1LineLoop and dsx1InwardLoop will be active simultaneously." ::= { dsx3ConfigEntry 9 } Nicklass Standards Track [Page 24] RFC 3896 DS3/E3 MIB September 2004 dsx3LineStatus OBJECT-TYPE SYNTAX INTEGER (1..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the Line Status of the interface. It contains loopback state information and failure state information. The dsx3LineStatus is a bit map represented as a sum, therefore, it can represent multiple failures and a loopback (see dsx3LoopbackConfig object for the type of loopback) simultaneously. The dsx3NoAlarm must be set if and only if no other flag is set. If the dsx3loopbackState bit is set, the loopback in effect can be determined from the dsx3loopbackConfig object. The various bit positions are: 1 dsx3NoAlarm No alarm present 2 dsx3RcvRAIFailure Receiving Yellow/Remote Alarm Indication 4 dsx3XmitRAIAlarm Transmitting Yellow/Remote Alarm Indication 8 dsx3RcvAIS Receiving AIS failure state 16 dsx3XmitAIS Transmitting AIS 32 dsx3LOF Receiving LOF failure state 64 dsx3LOS Receiving LOS failure state 128 dsx3LoopbackState Looping the received signal 256 dsx3RcvTestCode Receiving a Test Pattern 512 dsx3OtherFailure any line status not defined here 1024 dsx3UnavailSigState Near End in Unavailable Signal State 2048 dsx3NetEquipOOS Carrier Equipment Out of Service" ::= { dsx3ConfigEntry 10 } dsx3TransmitClockSource OBJECT-TYPE SYNTAX INTEGER { loopTiming(1), localTiming(2), throughTiming(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The source of Transmit Clock. Nicklass Standards Track [Page 25] RFC 3896 DS3/E3 MIB September 2004 loopTiming indicates that the recovered receive clock is used as the transmit clock. localTiming indicates that a local clock source is used or that an external clock is attached to the box containing the interface. throughTiming indicates that transmit clock is derived from the recovered receive clock of another DS3 interface." ::= { dsx3ConfigEntry 11 } dsx3InvalidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION " The number of intervals in the range from 0 to dsx3ValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { dsx3ConfigEntry 12 } dsx3LineLength OBJECT-TYPE SYNTAX INTEGER (0..64000) UNITS "meters" MAX-ACCESS read-write STATUS current DESCRIPTION "The length of the ds3 line in meters. This object provides information for line build out circuitry if it exists and can use this object to adjust the line build out." ::= { dsx3ConfigEntry 13 } dsx3LineStatusLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of MIB II's sysUpTime object at the time this DS3/E3 entered its current line status state. If the current state was entered prior to the last re-initialization of the proxy-agent, then this object contains a zero value." ::= { dsx3ConfigEntry 14 } Nicklass Standards Track [Page 26] RFC 3896 DS3/E3 MIB September 2004 dsx3LineStatusChangeTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether dsx3LineStatusChange traps should be generated for this interface." DEFVAL { disabled } ::= { dsx3ConfigEntry 15 } dsx3LoopbackStatus OBJECT-TYPE SYNTAX INTEGER (1..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable represents the current state of the loopback on the DS3 interface. It contains information about loopbacks established by a manager and remotely from the far end. The dsx3LoopbackStatus is a bit map represented as a sum, therefore is can represent multiple loopbacks simultaneously. The various bit positions are: 1 dsx3NoLoopback 2 dsx3NearEndPayloadLoopback 4 dsx3NearEndLineLoopback 8 dsx3NearEndOtherLoopback 16 dsx3NearEndInwardLoopback 32 dsx3FarEndPayloadLoopback 64 dsx3FarEndLineLoopback" ::= { dsx3ConfigEntry 16 } dsx3Channelization OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabledDs1(2), enabledDs2(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether this ds3/e3 is channelized or unchannelized. The value of enabledDs1 indicates Nicklass Standards Track [Page 27] RFC 3896 DS3/E3 MIB September 2004 that this is a DS3 channelized into DS1s. The value of enabledDs3 indicated that this is a DS3 channelized into DS2s. Setting this object will cause the creation or deletion of DS2 or DS1 entries in the ifTable. " ::= { dsx3ConfigEntry 17 } dsx3Ds1ForRemoteLoop OBJECT-TYPE SYNTAX INTEGER (0..29) MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates which DS1/E1 on this DS3/E3 will be indicated in the remote ds1 loopback request. A value of 0 means no DS1 will be looped. A value of 29 means all DS1s/E1s will be looped." ::= { dsx3ConfigEntry 18 } -- the DS3/E3 Current Table dsx3CurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3CurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3/E3 current table contains various statistics being collected for the current 15 minute interval." ::= { ds3 6 } dsx3CurrentEntry OBJECT-TYPE SYNTAX Dsx3CurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3/E3 Current table." INDEX { dsx3CurrentIndex } ::= { dsx3CurrentTable 1 } Dsx3CurrentEntry ::= SEQUENCE { dsx3CurrentIndex InterfaceIndex, dsx3CurrentPESs PerfCurrentCount, dsx3CurrentPSESs PerfCurrentCount, dsx3CurrentSEFSs PerfCurrentCount, dsx3CurrentUASs PerfCurrentCount, dsx3CurrentLCVs PerfCurrentCount, Nicklass Standards Track [Page 28] RFC 3896 DS3/E3 MIB September 2004 dsx3CurrentPCVs PerfCurrentCount, dsx3CurrentLESs PerfCurrentCount, dsx3CurrentCCVs PerfCurrentCount, dsx3CurrentCESs PerfCurrentCount, dsx3CurrentCSESs PerfCurrentCount } dsx3CurrentIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3CurrentEntry 1 } dsx3CurrentPESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Errored Seconds." ::= { dsx3CurrentEntry 2 } dsx3CurrentPSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Severely Errored Seconds." ::= { dsx3CurrentEntry 3 } dsx3CurrentSEFSs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds." ::= { dsx3CurrentEntry 4 } Nicklass Standards Track [Page 29] RFC 3896 DS3/E3 MIB September 2004 dsx3CurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds." ::= { dsx3CurrentEntry 5 } dsx3CurrentLCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Line Coding Violations." ::= { dsx3CurrentEntry 6 } dsx3CurrentPCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Coding Violations." ::= { dsx3CurrentEntry 7 } dsx3CurrentLESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Errored Seconds." ::= { dsx3CurrentEntry 8 } dsx3CurrentCCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Coding Violations." ::= { dsx3CurrentEntry 9 } dsx3CurrentCESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION Nicklass Standards Track [Page 30] RFC 3896 DS3/E3 MIB September 2004 "The number of C-bit Errored Seconds." ::= { dsx3CurrentEntry 10 } dsx3CurrentCSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Severely Errored Seconds." ::= { dsx3CurrentEntry 11 } -- the DS3/E3 Interval Table dsx3IntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3IntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3/E3 Interval Table contains various statistics collected by each DS3/E3 Interface over the previous 24 hours of operation. The past 24 hours are broken into 96 completed 15 minute intervals. Each row in this table represents one such interval (identified by dsx3IntervalNumber) and for one specific interface (identified by dsx3IntervalIndex)." ::= { ds3 7 } dsx3IntervalEntry OBJECT-TYPE SYNTAX Dsx3IntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3/E3 Interval table." INDEX { dsx3IntervalIndex, dsx3IntervalNumber } ::= { dsx3IntervalTable 1 } Dsx3IntervalEntry ::= SEQUENCE { dsx3IntervalIndex InterfaceIndex, dsx3IntervalNumber INTEGER, dsx3IntervalPESs PerfIntervalCount, dsx3IntervalPSESs PerfIntervalCount, dsx3IntervalSEFSs PerfIntervalCount, dsx3IntervalUASs PerfIntervalCount, dsx3IntervalLCVs PerfIntervalCount, dsx3IntervalPCVs PerfIntervalCount, dsx3IntervalLESs PerfIntervalCount, Nicklass Standards Track [Page 31] RFC 3896 DS3/E3 MIB September 2004 dsx3IntervalCCVs PerfIntervalCount, dsx3IntervalCESs PerfIntervalCount, dsx3IntervalCSESs PerfIntervalCount, dsx3IntervalValidData TruthValue } dsx3IntervalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3IntervalEntry 1 } dsx3IntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..96) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "A number between 1 and 96, where 1 is the most recently completed 15 minute interval and 96 is the 15 minutes interval completed 23 hours and 45 minutes prior to interval 1." ::= { dsx3IntervalEntry 2 } dsx3IntervalPESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Errored Seconds." ::= { dsx3IntervalEntry 3 } dsx3IntervalPSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Severely Errored Seconds." Nicklass Standards Track [Page 32] RFC 3896 DS3/E3 MIB September 2004 ::= { dsx3IntervalEntry 4 } dsx3IntervalSEFSs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds." ::= { dsx3IntervalEntry 5 } dsx3IntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds. This object may decrease if the occurrence of unavailable seconds occurs across an interval boundary." ::= { dsx3IntervalEntry 6 } dsx3IntervalLCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Line Coding Violations." ::= { dsx3IntervalEntry 7 } dsx3IntervalPCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Coding Violations." ::= { dsx3IntervalEntry 8 } dsx3IntervalLESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Errored Seconds (BPVs or illegal zero sequences)." ::= { dsx3IntervalEntry 9 } Nicklass Standards Track [Page 33] RFC 3896 DS3/E3 MIB September 2004 dsx3IntervalCCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Coding Violations." ::= { dsx3IntervalEntry 10 } dsx3IntervalCESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Errored Seconds." ::= { dsx3IntervalEntry 11 } dsx3IntervalCSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Severely Errored Seconds." ::= { dsx3IntervalEntry 12 } dsx3IntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION " This variable indicates if the data for this interval is valid." ::= { dsx3IntervalEntry 13 } -- the DS3/E3 Total dsx3TotalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3TotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3/E3 Total Table contains the cumulative sum of the various statistics for the 24 hour period preceding the current interval." ::= { ds3 8 } dsx3TotalEntry OBJECT-TYPE SYNTAX Dsx3TotalEntry MAX-ACCESS not-accessible Nicklass Standards Track [Page 34] RFC 3896 DS3/E3 MIB September 2004 STATUS current DESCRIPTION "An entry in the DS3/E3 Total table." INDEX { dsx3TotalIndex } ::= { dsx3TotalTable 1 } Dsx3TotalEntry ::= SEQUENCE { dsx3TotalIndex InterfaceIndex, dsx3TotalPESs PerfTotalCount, dsx3TotalPSESs PerfTotalCount, dsx3TotalSEFSs PerfTotalCount, dsx3TotalUASs PerfTotalCount, dsx3TotalLCVs PerfTotalCount, dsx3TotalPCVs PerfTotalCount, dsx3TotalLESs PerfTotalCount, dsx3TotalCCVs PerfTotalCount, dsx3TotalCESs PerfTotalCount, dsx3TotalCSESs PerfTotalCount } dsx3TotalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3TotalEntry 1 } dsx3TotalPESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Errored Seconds, encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 2 } dsx3TotalPSESs OBJECT-TYPE SYNTAX PerfTotalCount Nicklass Standards Track [Page 35] RFC 3896 DS3/E3 MIB September 2004 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Severely Errored Seconds, encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 3 } dsx3TotalSEFSs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds, encountered by a DS3/E3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 4 } dsx3TotalUASs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds, encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 5 } dsx3TotalLCVs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Line Coding Violations encountered by a DS3/E3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 6 } dsx3TotalPCVs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of P-bit Nicklass Standards Track [Page 36] RFC 3896 DS3/E3 MIB September 2004 Coding Violations, encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 7 } dsx3TotalLESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Errored Seconds (BPVs or illegal zero sequences) encountered by a DS3/E3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 8 } dsx3TotalCCVs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Coding Violations encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 9 } dsx3TotalCESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Errored Seconds encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 10 } dsx3TotalCSESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of C-bit Severely Errored Seconds encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3TotalEntry 11 } Nicklass Standards Track [Page 37] RFC 3896 DS3/E3 MIB September 2004 -- The DS3 Far End Group -- The DS3 Far End Group consists of four tables : -- DS3 Far End Configuration -- DS3 Far End Current -- DS3 Far End Interval -- DS3 Far End Total -- The DS3 Far End Configuration Table dsx3FarEndConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3FarEndConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3 Far End Configuration Table contains configuration information reported in the C-bits from the remote end." ::= { ds3 9 } dsx3FarEndConfigEntry OBJECT-TYPE SYNTAX Dsx3FarEndConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3 Far End Configuration table." INDEX { dsx3FarEndLineIndex } ::= { dsx3FarEndConfigTable 1 } Dsx3FarEndConfigEntry ::= SEQUENCE { dsx3FarEndLineIndex InterfaceIndex, dsx3FarEndEquipCode DisplayString, dsx3FarEndLocationIDCode DisplayString, dsx3FarEndFrameIDCode DisplayString, dsx3FarEndUnitCode DisplayString, dsx3FarEndFacilityIDCode DisplayString } dsx3FarEndLineIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value which uniquely identifies the DS3 interface to which this entry is applicable. The interface identified by a particular value of this Nicklass Standards Track [Page 38] RFC 3896 DS3/E3 MIB September 2004 index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3FarEndConfigEntry 1 } dsx3FarEndEquipCode OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the Far End Equipment Identification code that describes the specific piece of equipment. It is sent within the Path Identification Message." ::= { dsx3FarEndConfigEntry 2 } dsx3FarEndLocationIDCode OBJECT-TYPE SYNTAX DisplayString (SIZE (0..11)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the Far End Location Identification code that describes the specific location of the equipment. It is sent within the Path Identification Message." ::= { dsx3FarEndConfigEntry 3 } dsx3FarEndFrameIDCode OBJECT-TYPE SYNTAX DisplayString (SIZE (0..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the Far End Frame Identification code that identifies where the equipment is located within a building at a given location. It is sent within the Path Identification Message." ::= { dsx3FarEndConfigEntry 4 } dsx3FarEndUnitCode OBJECT-TYPE SYNTAX DisplayString (SIZE (0..6)) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the Far End code that identifies the equipment location within a bay. It is sent within the Path Identification Message." ::= { dsx3FarEndConfigEntry 5 } dsx3FarEndFacilityIDCode OBJECT-TYPE Nicklass Standards Track [Page 39] RFC 3896 DS3/E3 MIB September 2004 SYNTAX DisplayString (SIZE (0..38)) MAX-ACCESS read-write STATUS current DESCRIPTION "This code identifies a specific Far End DS3 path. It is sent within the Path Identification Message." ::= { dsx3FarEndConfigEntry 6 } -- The DS3 Far End Current dsx3FarEndCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3FarEndCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3 Far End Current table contains various statistics being collected for the current 15 minute interval. The statistics are collected from the far end block error code within the C- bits." ::= { ds3 10 } dsx3FarEndCurrentEntry OBJECT-TYPE SYNTAX Dsx3FarEndCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3 Far End Current table." INDEX { dsx3FarEndCurrentIndex } ::= { dsx3FarEndCurrentTable 1 } Dsx3FarEndCurrentEntry ::= SEQUENCE { dsx3FarEndCurrentIndex InterfaceIndex, dsx3FarEndTimeElapsed INTEGER, dsx3FarEndValidIntervals INTEGER, dsx3FarEndCurrentCESs PerfCurrentCount, dsx3FarEndCurrentCSESs PerfCurrentCount, dsx3FarEndCurrentCCVs PerfCurrentCount, dsx3FarEndCurrentUASs PerfCurrentCount, dsx3FarEndInvalidIntervals INTEGER } dsx3FarEndCurrentIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index Nicklass Standards Track [Page 40] RFC 3896 DS3/E3 MIB September 2004 STATUS current DESCRIPTION "The index value which uniquely identifies the DS3 interface to which this entry is applicable. The interface identified by a particular value of this index is identical to the interface identified by the same value of dsx3LineIndex." ::= { dsx3FarEndCurrentEntry 1 } dsx3FarEndTimeElapsed OBJECT-TYPE SYNTAX INTEGER (0..899) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that have elapsed since the beginning of the far end current error-measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, the agent will return the maximum value." ::= { dsx3FarEndCurrentEntry 2 } dsx3FarEndValidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous far end intervals for which data was collected. The value will be 96 unless the interface was brought online within the last 24 hours, in which case the value will be the number of complete 15 minute far end intervals since the interface has been online. In the case where the agent is a proxy, it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { dsx3FarEndCurrentEntry 3 } dsx3FarEndCurrentCESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Errored Seconds." ::= { dsx3FarEndCurrentEntry 4 } Nicklass Standards Track [Page 41] RFC 3896 DS3/E3 MIB September 2004 dsx3FarEndCurrentCSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Severely Errored Seconds." ::= { dsx3FarEndCurrentEntry 5 } dsx3FarEndCurrentCCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Coding Violations reported via the far end block error count." ::= { dsx3FarEndCurrentEntry 6 } dsx3FarEndCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End unavailable seconds." ::= { dsx3FarEndCurrentEntry 7 } dsx3FarEndInvalidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION " The number of intervals in the range from 0 to dsx3FarEndValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { dsx3FarEndCurrentEntry 8 } -- The DS3 Far End Interval Table dsx3FarEndIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3FarEndIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3 Far End Interval Table contains various Nicklass Standards Track [Page 42] RFC 3896 DS3/E3 MIB September 2004 statistics collected by each DS3 interface over the previous 24 hours of operation. The past 24 hours are broken into 96 completed 15 minute intervals." ::= { ds3 11 } dsx3FarEndIntervalEntry OBJECT-TYPE SYNTAX Dsx3FarEndIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3 Far End Interval table." INDEX { dsx3FarEndIntervalIndex, dsx3FarEndIntervalNumber } ::= { dsx3FarEndIntervalTable 1 } Dsx3FarEndIntervalEntry ::= SEQUENCE { dsx3FarEndIntervalIndex InterfaceIndex, dsx3FarEndIntervalNumber INTEGER, dsx3FarEndIntervalCESs PerfIntervalCount, dsx3FarEndIntervalCSESs PerfIntervalCount, dsx3FarEndIntervalCCVs PerfIntervalCount, dsx3FarEndIntervalUASs PerfIntervalCount, dsx3FarEndIntervalValidData TruthValue } dsx3FarEndIntervalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value which uniquely identifies the DS3 interface to which this entry is applicable. The interface identified by a particular value of this index is identical to the interface identified by the same value of dsx3LineIndex." ::= { dsx3FarEndIntervalEntry 1 } dsx3FarEndIntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..96) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "A number between 1 and 96, where 1 is the most recently completed 15 minute interval and 96 is Nicklass Standards Track [Page 43] RFC 3896 DS3/E3 MIB September 2004 the 15 minutes interval completed 23 hours and 45 minutes prior to interval 1." ::= { dsx3FarEndIntervalEntry 2 } dsx3FarEndIntervalCESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Errored Seconds encountered by a DS3 interface in one of the previous 96, individual 15 minute, intervals. In the case where the agent is a proxy and data is not available, return noSuchInstance." ::= { dsx3FarEndIntervalEntry 3 } dsx3FarEndIntervalCSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Severely Errored Seconds." ::= { dsx3FarEndIntervalEntry 4 } dsx3FarEndIntervalCCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Coding Violations reported via the far end block error count." ::= { dsx3FarEndIntervalEntry 5 } dsx3FarEndIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End unavailable seconds." ::= { dsx3FarEndIntervalEntry 6 } dsx3FarEndIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only Nicklass Standards Track [Page 44] RFC 3896 DS3/E3 MIB September 2004 STATUS current DESCRIPTION " This variable indicates if the data for this interval is valid." ::= { dsx3FarEndIntervalEntry 7 } -- The DS3 Far End Total dsx3FarEndTotalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3FarEndTotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3 Far End Total Table contains the cumulative sum of the various statistics for the 24 hour period preceding the current interval." ::= { ds3 12 } dsx3FarEndTotalEntry OBJECT-TYPE SYNTAX Dsx3FarEndTotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3 Far End Total table." INDEX { dsx3FarEndTotalIndex } ::= { dsx3FarEndTotalTable 1 } Dsx3FarEndTotalEntry ::= SEQUENCE { dsx3FarEndTotalIndex InterfaceIndex, dsx3FarEndTotalCESs PerfTotalCount, dsx3FarEndTotalCSESs PerfTotalCount, dsx3FarEndTotalCCVs PerfTotalCount, dsx3FarEndTotalUASs PerfTotalCount } dsx3FarEndTotalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value which uniquely identifies the DS3 interface to which this entry is applicable. The interface identified by a particular value of this index is identical to the interface identified by the same value of dsx3LineIndex." ::= { dsx3FarEndTotalEntry 1 } Nicklass Standards Track [Page 45] RFC 3896 DS3/E3 MIB September 2004 dsx3FarEndTotalCESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Errored Seconds encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3FarEndTotalEntry 2 } dsx3FarEndTotalCSESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Severely Errored Seconds encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3FarEndTotalEntry 3 } dsx3FarEndTotalCCVs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End C-bit Coding Violations reported via the far end block error count encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3FarEndTotalEntry 4 } dsx3FarEndTotalUASs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Far End unavailable seconds encountered by a DS3 interface in the previous 24 hour interval. Invalid 15 minute intervals count as 0." ::= { dsx3FarEndTotalEntry 5 } -- the DS3/E3 Fractional Table -- This table is deprecated. Nicklass Standards Track [Page 46] RFC 3896 DS3/E3 MIB September 2004 dsx3FracTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3FracEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table is deprecated in favour of using ifStackTable. Implementation of this table was optional. It was designed for those systems dividing a DS3/E3 into channels containing different data streams that are of local interest. The DS3/E3 fractional table identifies which DS3/E3 channels associated with a CSU are being used to support a logical interface, i.e., an entry in the interfaces table from the Internet- standard MIB. For example, consider a DS3 device with 4 high speed links carrying router traffic, a feed for voice, a feed for video, and a synchronous channel for a non-routed protocol. We might describe the allocation of channels, in the dsx3FracTable, as follows: dsx3FracIfIndex.2. 1 = 3 dsx3FracIfIndex.2.15 = 4 dsx3FracIfIndex.2. 2 = 3 dsx3FracIfIndex.2.16 = 6 dsx3FracIfIndex.2. 3 = 3 dsx3FracIfIndex.2.17 = 6 dsx3FracIfIndex.2. 4 = 3 dsx3FracIfIndex.2.18 = 6 dsx3FracIfIndex.2. 5 = 3 dsx3FracIfIndex.2.19 = 6 dsx3FracIfIndex.2. 6 = 3 dsx3FracIfIndex.2.20 = 6 dsx3FracIfIndex.2. 7 = 4 dsx3FracIfIndex.2.21 = 6 dsx3FracIfIndex.2. 8 = 4 dsx3FracIfIndex.2.22 = 6 dsx3FracIfIndex.2. 9 = 4 dsx3FracIfIndex.2.23 = 6 dsx3FracIfIndex.2.10 = 4 dsx3FracIfIndex.2.24 = 6 dsx3FracIfIndex.2.11 = 4 dsx3FracIfIndex.2.25 = 6 dsx3FracIfIndex.2.12 = 5 dsx3FracIfIndex.2.26 = 6 dsx3FracIfIndex.2.13 = 5 dsx3FracIfIndex.2.27 = 6 dsx3FracIfIndex.2.14 = 5 dsx3FracIfIndex.2.28 = 6 For dsx3M23, dsx3 SYNTRAN, dsx3CbitParity, and dsx3ClearChannel there are 28 legal channels, numbered 1 through 28. For e3Framed there are 16 legal channels, numbered 1 through 16. The channels (1..16) correspond directly to the equivalently numbered time-slots." ::= { ds3 13 } Nicklass Standards Track [Page 47] RFC 3896 DS3/E3 MIB September 2004 dsx3FracEntry OBJECT-TYPE SYNTAX Dsx3FracEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the DS3 Fractional table." INDEX { dsx3FracIndex, dsx3FracNumber } ::= { dsx3FracTable 1 } Dsx3FracEntry ::= SEQUENCE { dsx3FracIndex INTEGER, dsx3FracNumber INTEGER, dsx3FracIfIndex INTEGER } dsx3FracIndex OBJECT-TYPE SYNTAX INTEGER (1..'7fffffff'h) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "The index value which uniquely identifies the DS3 interface to which this entry is applicable The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3FracEntry 1 } dsx3FracNumber OBJECT-TYPE SYNTAX INTEGER (1..31) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "The channel number for this entry." ::= { dsx3FracEntry 2 } dsx3FracIfIndex OBJECT-TYPE SYNTAX INTEGER (0..'7fffffff'h) MAX-ACCESS read-write STATUS deprecated DESCRIPTION "An index value that uniquely identifies an interface. The interface identified by a particular value of this index is the same interface as identified by the same value an Nicklass Standards Track [Page 48] RFC 3896 DS3/E3 MIB September 2004 ifIndex object instance. If no interface is currently using a channel, the value should be zero. If a single interface occupies more than one time slot, that ifIndex value will be found in multiple time slots." ::= { dsx3FracEntry 3 } -- DS3 TRAPS ds3Traps OBJECT IDENTIFIER ::= { ds3 15 } dsx3LineStatusChange NOTIFICATION-TYPE OBJECTS { dsx3LineStatus, dsx3LineStatusLastChange } STATUS current DESCRIPTION "A dsx3LineStatusChange trap is sent when the value of an instance of dsx3LineStatus changes. It can be utilized by an NMS to trigger polls. When the line status change results in a lower level line status change (i.e., ds1), then no traps for the lower level are sent." ::= { ds3Traps 0 1 } -- conformance information ds3Conformance OBJECT IDENTIFIER ::= { ds3 14 } ds3Groups OBJECT IDENTIFIER ::= { ds3Conformance 1 } ds3Compliances OBJECT IDENTIFIER ::= { ds3Conformance 2 } -- compliance statements ds3Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DS3/E3 interfaces." MODULE -- this module MANDATORY-GROUPS { ds3NearEndConfigGroup, ds3NearEndStatisticsGroup } GROUP ds3FarEndGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS3 Interface. However, only C-bit Parity and SYNTRAN DS3 applications have the capability (option) of providing this information." GROUP ds3NearEndOptionalTrapGroup Nicklass Standards Track [Page 49] RFC 3896 DS3/E3 MIB September 2004 DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS3 Interface. If it is implemented then ds3NearEndOptionalConfigGroup should also be implemented." GROUP ds3NearEndOptionalConfigGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS3 interface." OBJECT dsx3LineType MIN-ACCESS read-only DESCRIPTION "Write access for the line type is not required." OBJECT dsx3LineCoding MIN-ACCESS read-only DESCRIPTION "Write access for the line coding is not required." OBJECT dsx3SendCode MIN-ACCESS read-only DESCRIPTION "Write access for the send code is not required." OBJECT dsx3LoopbackConfig MIN-ACCESS read-only DESCRIPTION "Write access for loopbacks is not required." OBJECT dsx3TransmitClockSource MIN-ACCESS read-only DESCRIPTION "Write access for the transmit clock source is not required." OBJECT dsx3LineLength MIN-ACCESS read-only DESCRIPTION "Write access for the line length is not required." OBJECT dsx3Channelization MIN-ACCESS read-only DESCRIPTION "Write access for the channelization is not required." Nicklass Standards Track [Page 50] RFC 3896 DS3/E3 MIB September 2004 ::= { ds3Compliances 1 } -- units of conformance ds3NearEndConfigGroup OBJECT-GROUP OBJECTS { dsx3LineIndex, dsx3TimeElapsed, dsx3ValidIntervals, dsx3LineType, dsx3LineCoding, dsx3SendCode, dsx3CircuitIdentifier, dsx3LoopbackConfig, dsx3LineStatus, dsx3TransmitClockSource, dsx3InvalidIntervals, dsx3LineLength, dsx3LoopbackStatus, dsx3Channelization, dsx3Ds1ForRemoteLoop} STATUS current DESCRIPTION "A collection of objects providing configuration information applicable to all DS3/E3 interfaces." ::= { ds3Groups 1 } ds3NearEndStatisticsGroup OBJECT-GROUP OBJECTS { dsx3CurrentIndex, dsx3CurrentPESs, dsx3CurrentPSESs, dsx3CurrentSEFSs, dsx3CurrentUASs, dsx3CurrentLCVs, dsx3CurrentPCVs, dsx3CurrentLESs, dsx3CurrentCCVs, dsx3CurrentCESs, dsx3CurrentCSESs, dsx3IntervalIndex, dsx3IntervalNumber, dsx3IntervalPESs, dsx3IntervalPSESs, dsx3IntervalSEFSs, dsx3IntervalUASs, dsx3IntervalLCVs, dsx3IntervalPCVs, dsx3IntervalLESs, dsx3IntervalCCVs, Nicklass Standards Track [Page 51] RFC 3896 DS3/E3 MIB September 2004 dsx3IntervalCESs, dsx3IntervalCSESs, dsx3IntervalValidData, dsx3TotalIndex, dsx3TotalPESs, dsx3TotalPSESs, dsx3TotalSEFSs, dsx3TotalUASs, dsx3TotalLCVs, dsx3TotalPCVs, dsx3TotalLESs, dsx3TotalCCVs, dsx3TotalCESs, dsx3TotalCSESs } STATUS current DESCRIPTION "A collection of objects providing statistics information applicable to all DS3/E3 interfaces." ::= { ds3Groups 2 } ds3FarEndGroup OBJECT-GROUP OBJECTS { dsx3FarEndLineIndex, dsx3FarEndEquipCode, dsx3FarEndLocationIDCode, dsx3FarEndFrameIDCode, dsx3FarEndUnitCode, dsx3FarEndFacilityIDCode, dsx3FarEndCurrentIndex, dsx3FarEndTimeElapsed, dsx3FarEndValidIntervals, dsx3FarEndCurrentCESs, dsx3FarEndCurrentCSESs, dsx3FarEndCurrentCCVs, dsx3FarEndCurrentUASs, dsx3FarEndInvalidIntervals, dsx3FarEndIntervalIndex, dsx3FarEndIntervalNumber, dsx3FarEndIntervalCESs, dsx3FarEndIntervalCSESs, dsx3FarEndIntervalCCVs, dsx3FarEndIntervalUASs, dsx3FarEndIntervalValidData, dsx3FarEndTotalIndex, dsx3FarEndTotalCESs, dsx3FarEndTotalCSESs, dsx3FarEndTotalCCVs, dsx3FarEndTotalUASs } STATUS current Nicklass Standards Track [Page 52] RFC 3896 DS3/E3 MIB September 2004 DESCRIPTION "A collection of objects providing remote configuration and statistics information applicable to C-bit Parity and SYNTRAN DS3 interfaces." ::= { ds3Groups 3 } ds3DeprecatedGroup OBJECT-GROUP OBJECTS { dsx3IfIndex, dsx3FracIndex, dsx3FracNumber, dsx3FracIfIndex } STATUS deprecated DESCRIPTION "A collection of obsolete objects that may be implemented for backwards compatibility." ::= { ds3Groups 4 } ds3NearEndOptionalConfigGroup OBJECT-GROUP OBJECTS { dsx3LineStatusLastChange, dsx3LineStatusChangeTrapEnable } STATUS current DESCRIPTION "A collection of objects that may be implemented on DS3/E3 interfaces." ::= { ds3Groups 5 } ds3NearEndOptionalTrapGroup NOTIFICATION-GROUP NOTIFICATIONS { dsx3LineStatusChange } STATUS current DESCRIPTION "A collection of notifications that may be implemented on DS3/E3 interfaces." ::= { ds3Groups 6 } END Nicklass Standards Track [Page 53] RFC 3896 DS3/E3 MIB September 2004 4. Appendix A - Use of dsx3IfIndex and dsx3LineIndex This Appendix exists to document the previous use if dsx3IfIndex and dsx3LineIndex and to clarify the relationship of dsx3LineIndex as defined in RFC 1407 with the dsx3LineIndex as defined in this document. The following shows the old and new definitions and the relationship: [New Definition]: "This object should be made equal to ifIndex. The next paragraph describes its previous usage. Making the object equal to ifIndex allows proper use of ifStackTable. [Old Definition]: "this object is the identifier of a DS3/E3 Interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS3/E3 interface, it should have the same value as ifIndex. Otherwise, number the dsx3LineIndices with an unique identifier following the rules of choosing a number that is greater than ifNumber and numbering the inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g, network side) with odd numbers." When the "Old Definition" was created, it was described this way to allow a manager to treat the value _as if_ it were an ifIndex, i.e., the value would either be: 1) an ifIndex value or 2) a value that was guaranteed to be different from all valid ifIndex values. The new definition is a subset of that definition, i.e., the value is always an ifIndex value. The following is Section 3.1 from [RFC1407]: Different physical configurations for the support of SNMP with DS3/E3 equipment exist. To accommodate these scenarios, two different indices for DS3/E3 interfaces are introduced in this MIB. These indices are dsx3IfIndex and dsx3LineIndex. External interface scenario: the SNMP Agent represents all managed DS3/E3 lines as external interfaces (for example, an Agent residing on the device supporting DS3/E3 interfaces directly): Nicklass Standards Track [Page 54] RFC 3896 DS3/E3 MIB September 2004 For this scenario, all interfaces are assigned an integer value equal to ifIndex, and the following applies: ifIndex=dsx3IfIndex=dsx3LineIndex for all interfaces. The dsx3IfIndex column of the DS3/E3 Configuration table relates each DS3/E3 interface to its corresponding interface (ifIndex) in the Internet-standard MIB (MIB-II STD 17, [RFC1213]). External&Internal interface scenario: the SNMP Agents resides on an host external from the device supporting DS3/E3 interfaces (e.g., a router). The Agent represents both the host and the DS3/E3 device. The index dsx3LineIndex is used to not only represent the DS3/E3 interfaces external from the host/DS3/E3-device combination, but also the DS3/E3 interfaces connecting the host and the DS3/E3 device. The index dsx3IfIndex is always equal to ifIndex. Example: A shelf full of CSUs connected to a Router. An SNMP Agent residing on the router proxies for itself and the CSU. The router has also an Ethernet interface: +-----+ | | | | | | +---------------------+ |E | | 44.736 MBPS | ds3 M13 Line#A | ds3 C-bit Parity |t | R |---------------+ - - - - - - - - - +------> |h | | | | |e | O | 44.736 MBPS | ds3 M13 Line#B | ds3 C-bit Parity |r | |---------------+ - - - - - - - - - - +------> |n | U | | | |e | | 44.736 MBPS | ds3 M13 Line#C | ds3 C-bit Parity |t | T |---------------+ - - - -- -- - - - - +------> | | | | | |-----| E | 44.736 MBPS | ds3 M13 Line#D | ds3 C-bit Parity | | |---------------+ - - - - -- - - - - +------> | | R | |_____________________| | | | | +-----+ Nicklass Standards Track [Page 55] RFC 3896 DS3/E3 MIB September 2004 The assignment of the index values could for example be: ifIndex (= dsx3IfIndex) dsx3LineIndex 1 NA NA (Ethernet) 2 Line#A Router Side 6 2 Line#A Network Side 7 3 Line#B Router Side 8 3 Line#B Network Side 9 4 Line#C Router Side 10 4 Line#C Network Side 11 5 Line#D Router Side 12 5 Line#D Network Side 13 For this example, ifNumber is equal to 5. Note the following description of dsx3LineIndex: the dsx3LineIndex identifies a DS3/E3 Interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS3/E3 interface, it should have the same value as ifIndex. Otherwise, number the dsx3LineIndices with an unique identifier following the rules of choosing a number greater than ifNumber and numbering inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g., network side) with odd numbers. If the CSU shelf is managed by itself by a local SNMP Agent, the situation would be: ifIndex (= dsx3IfIndex) dsx3LineIndex 1 Line#A Network Side 1 2 Line#A RouterSide 2 3 Line#B Network Side 3 4 Line#B RouterSide 4 5 Line#C Network Side 5 6 Line#C Router Side 6 7 Line#D Network Side 7 8 Line#D Router Side 8 5. Appendix B - The delay approach to Unavialable Seconds. This procedure is illustrated below for a DS3 C-Bit parity application. Similar rules would apply for other interfaces covered by this MIB. The procedure guarantees that the statistical counters are correctly updated at all times, although they lag real time by 10 seconds. At the end of each 15 minutes interval the current interval counts are transferred to the most recent interval entry and each interval is shifted up by one position, with the oldest being discarded if necessary in order to make room. The current interval Nicklass Standards Track [Page 56] RFC 3896 DS3/E3 MIB September 2004 counts then start over from zero. Note, however, that the signal state calculation does not start afresh at each interval boundary; rather, signal state information is retained across interval boundaries. +----------------------------------------------------------------+ | READ COUNTERS & STATUS INFO FROM HARDWARE | | | |BPV EXZ LOS PCV CCV AIS SEF OOF LOF FEBE RAI | +----------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V +----------------------------------------------------------------+ | ACCUM ONE-SEC STATS, CHK ERR THRESHOLDS, & UPDT SIGNAL STATE | | | |<------------- NEAR END ---------------->| |<---- FAR END ----->| | | |LCV LES PCV CCV PES CES PSES CSES SEFS A/U CCV CES CSES SEFS A/U| +----------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V | V V V V | +--------------------------------------+ | +-----------------+ | | ONE-SEC DELAY | | | ONE-SEC DELAY | | | (1 OF 10) | | | (1 OF 10) | | +--------------------------------------+ | +-----------------+ | | | | | | | | | | | | | | | | / / / / / / / / / / / / / / / | | | | | | | | | | | | | | | V V V V V V V V V | V V V V | +--------------------------------------+ | +-----------------+ | | ONE-SEC DELAY | | | ONE-SEC DELAY | | | (10 OF 10) | | | (10 OF 10) | | +--------------------------------------+ | +-----------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V V V V V +----------------------------------------------------------------+ | UPDATE STATISTICS COUNTERS | | | |<------------- NEAR END ---------------->| |<---- FAR END ----->| | | |LCV LES PCV CCV PES CES PSES CSES SEFS UAS CCV CES CSES SEFS UAS| +----------------------------------------------------------------+ Note that if such a procedure is adopted there is no current interval data for the first ten seconds after a system comes up. Nicklass Standards Track [Page 57] RFC 3896 DS3/E3 MIB September 2004 noSuchInstance must be returned if a management station attempts to access the current interval counters during this time. It is an implementation-specific matter whether an agent assumes that the initial state of the interface is available or unavailable. 6. Acknowledgments This document was produced by the AToM MIB Working Group. The Editor would like to dedicate a special thanks to C. Mike Heard for providing a top notch doctor review and many helpful suggestions, and to acknowledge D. Fowler, Editor of RFC 2496, T. Cox and K. Tesink Editors of RFC 1407. 7. References 7.1. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [ANSI-T1.102] American National Standard for telecommunications - digital hierarchy - electrical interfaces, ANSI T1.102-1987. [ANSI-T1.107] American National Standard for telecommunications - digital hierarchy - formats specification, ANSI T1.107- 1988. [ANSI-T1.107a] ANSI T1.107a-1990. [ANSI-T1.404] American National Standard for telecommunications - Carrier-to-Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989. Nicklass Standards Track [Page 58] RFC 3896 DS3/E3 MIB September 2004 [ANSI-T1.231] American National Standard for Telecommunications -- Layer 1 In- Service Digital Transmission Performance Monitoring T1.231, Sept 1993. [CCITT-G.751] CCITT - Digital Multiplex Equipment Operating at the Third Order Bit Rate of 34 368 Kbit/s and the Forth Order Bit Rate of 139 264 Kbit/s and Using Positive Justification, G.751 [ETSI-T/NA(91)18] European Telecommunications Standards Institute -- ETS "34M" -- Metropolitan Area Network Physical Convergence Layer Procedure for 34.368 Megabits per Second, T/NA(91)18, May 1991. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [ITU-T-M.1400] ITU-T M.1400: Designation For Interconnections Among Network Operators, October 2001. 7.2. Informative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [RFC1407] Cox, T. and K. Tesink, "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 1407, January 1993. [RFC2496] Fowler, D., "Definitions of Managed Object for the DS3/E3 Interface Type", RFC 2496, January 1999. [RFC3895] Nicklass, O., Ed., "Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types", RFC 3895, September 2004. [RFC3592] Tesink, K., "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", RFC 3592, September 2003. [RFC2494] Fowler, D., "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type", RFC 2494, January 1999. Nicklass Standards Track [Page 59] RFC 3896 DS3/E3 MIB September 2004 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The specific the objects and their sensitivities/vulnerabilities are as follows. Setting the following objects to incorrect values may result in traffic interruptions: dsx3LineType dsx3LineCoding dsx3SendCode dsx3LoopbackConfig dsx3TransmitClockSource dsx3LineLength dsx3Channelization dsx3Ds1ForRemoteLoop In the case of dsx3LineType, for example, both ends of a DS3/E3 must have the same value in order for traffic to flow. In the case of dsx3SendCode and dsx3LoopbackConfig, for another example, traffic may stop transmitting when particular loopbacks are applied. Setting the following objects to an incorrect value will result in the remote end receiving an incorrect Path Identification message, which may result in a connectivity inconsistency: dsx3FarEndEquipCode dsx3FarEndLocationIDCode dsx3FarEndFrameIDCode dsx3FarEndUnitCode dsx3FarEndFacilityIDCode Nicklass Standards Track [Page 60] RFC 3896 DS3/E3 MIB September 2004 Setting the following object to an incorrect value will not harm the traffic, but it may cause a circuit to be mis-identified and thereby create difficulties for service personnel when attempting to troubleshoot a problem: dsx3CircuitIdentifier Setting the following object can cause an increase in the number of traps received by the network management station: dsx3LineStatusChangeTrapEnable The readable objects in this MIB module (i.e., the objects with a MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide extensive information about the performance of interfaces in DS3/E3 equipment or networks and can reveal some aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Nicklass Standards Track [Page 61] RFC 3896 DS3/E3 MIB September 2004 9. Author's Address Orly Nicklass (editor) RAD Data Communications, Ltd. Ziv Tower, 24 Roul Walenberg Tel Aviv, Israel, 69719 Phone: 9723-765-9969 EMail: orly_n@rad.com Nicklass Standards Track [Page 62] RFC 3896 DS3/E3 MIB September 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nicklass Standards Track [Page 63] snmp-mibs-downloader-1.1/mibrfcs/rfc3970.txt0000644000000000000000000025540111402176071015573 0ustar Network Working Group K. Kompella Request for Comments: 3970 Juniper Networks Category: Standards Track January 2005 A Traffic Engineering (TE) MIB 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Specification of Requirements. . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Overview of the MIB Module . . . . . . . . . . . . . . . . . . 2 3.1. Traffic Engineering Information. . . . . . . . . . . . . 3 3.2. Traffic Tunnel Information . . . . . . . . . . . . . . . 3 3.3. Path Information . . . . . . . . . . . . . . . . . . . . 3 3.4. Hop Information. . . . . . . . . . . . . . . . . . . . . 4 3.5. Relationship with Other MIB Modules. . . . . . . . . . . 4 4. Creating, Modifying, and Deleting a TE Tunnel. . . . . . . . . 4 5. MIB Specification. . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1. Normative References . . . . . . . . . . . . . . . . . . 40 6.2. Informative References . . . . . . . . . . . . . . . . . 40 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 41 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 44 Kompella Standards Track [Page 1] RFC 3970 A Traffic Engineering (TE) MIB January 2005 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths ([7], [8]). The MIB module defined by this memo allows one to configure TE Tunnels, to assign one or more paths to a Tunnel, and to monitor operational aspects of the Tunnel, such as the number of octets and packets that have passed through the Tunnel. As it stands, this MIB module can only be used to configure or monitor a TE Tunnel at its ingress. The ingress is then expected to use some protocol (such as RSVP-TE) to signal the other routers in the path the information they need to set up the tunnel. The extension of this module for use at other points of a Tunnel is for further study. 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [8]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4]. 3. Overview of the MIB Module The Traffic Engineering MIB module consists of four parts: 1) Traffic Engineering information, 2) a table of Traffic Engineering Tunnels, 3) a table of Paths that tunnels take, and 4) a table of Hops that make up a tunnel path. The MIB module also has statements for minimal and full compliance. Kompella Standards Track [Page 2] RFC 3970 A Traffic Engineering (TE) MIB January 2005 The following subsections give an overview of each part. All objects are mandatory. For minimal compliance, all objects MAY be implemented read-only; for full compliance, all objects must be implemented to their stated MAX-ACCESS capabilities. Notifications are optional. 3.1. Traffic Engineering Information This part contains information about the Link State Protocols used to carry TE information, the signaling protocols used to set up Traffic Tunnels, the number of Traffic Tunnels that have been configured and that are operational, and a mapping of Administrative Group (called Resource Classes in [7]) numbers to names. 3.2. Traffic Tunnel Information This part contains a table of Traffic Tunnels and information about each one. This information includes the Tunnel name, its configuration information, its operational information, and the active path(s) that the Tunnel takes. Configuration information includes the end points of the Traffic Tunnel, and the number of configured paths for the Traffic Tunnel. Operational information includes the current state (up/down), the count of octets and packets sent on the Traffic Tunnel, how long it has been up, and how many state transitions the Traffic Tunnel has had. Operational path information includes the number of operational paths, the number of path changes, and when the last path change was. 3.3. Path Information A Tunnel is a logical entity. An instantiation of a Tunnel is one or more Paths; each Path has a route (also called Explicit Route) or sequence of hops. A Path is indexed by a dual index: The primary index is that of the Tunnel to which the Path belongs; the secondary index is that of the Path itself. The configured information for a Path consists of the constraints for the Path and a configured route. The operational information consists of the Path status, the computed route (i.e., the route that was computed to satisfy the constraints), and the actual path as recorded by the signaling protocol. Kompella Standards Track [Page 3] RFC 3970 A Traffic Engineering (TE) MIB January 2005 3.4. Hop Information A path consists of a sequence of hops. A hop can be loose (meaning that the path eventually traverses the specified node) or strict (meaning that the specified node and possibly the link must be the next node in the path). A hop can be specified as an IPv4 address, an IPv6 address, an Autonomous System number or an unnumbered interface index [5]. The Hop Table contains all hops for all paths on a given router. It is organized as follows. There is a primary index that identifies a list of hops and a secondary index that identifies individual hops. Thus, to get the sequence of recorded hops for a path, one looks up the path's tePathRecordedRoute, which is a primary index into the Hop Table. Then to get the list of actual hops in order for the recorded path, one uses a secondary index of 1, 2, .... 3.5. Relationship with Other MIB Modules A TE Tunnel can extend objects from two other MIB modules; one is the Interfaces MIB [10], and the other is the IP Tunnel MIB [11]. The mechanism for doing so is to assign the TE Tunnel index (teTunnelIndex) with a valid ifIndex value in ifTable. If a TE Tunnel is deemed an interface, a new interface object is created and assigned an ifIndex value in ifTable. Then a TE Tunnel object is created, setting teTunnelIndex to the same value as the interface index. If (and only if) a TE Tunnel is considered an interface, it may also be considered an IP tunnel (if the encapsulation of the TE Tunnel is IP). In that case, the interface associated with the TE Tunnel should have its ifType set to tunnel(131). If a TE Tunnel is not considered an interface, then the TE Tunnel index (teTunnelIndex) SHOULD be set to a value at least 2^24, so that it is distinct from normal interfaces. 4. Creating, Modifying, and Deleting a TE Tunnel To create a TE Tunnel, one first obtains a free Tunnel index by using the object teNextTunnelIndex. One then creates the Tunnel, including all parameters, either as createAndGo or createAndWait. Then, TE Paths for this Tunnel can be created by using the teTunnelNextPathIndex object, again as createAndGo or createAndWait. A particular Path is computed and signaled when both the Path and the enclosing Tunnel have RowStatus 'active'. Kompella Standards Track [Page 4] RFC 3970 A Traffic Engineering (TE) MIB January 2005 To build a Path's configured route, one first gets a free PathHop index by using teNextPathHopIndex, and then builds the route hop-by- hop using the secondary index, setting the AddrType, Address, and HopType for each Hop. Finally, one sets the tePathConfiguredRoute in the Path to the PathHop index obtained. Modifying certain properties of a TE Tunnel or a TE Path may require setting the RowStatus of the Tunnel (or Path) to 'notInService' before making the changes and then setting the RowStatus of the Tunnel (or Path) back to 'active' to re-signal all Paths of the Tunnel (or the modified Path). A TE Tunnel and all its Paths can be deleted by setting the Tunnel's RowStatus to 'destroy'. A specific Path within a Tunnel can be destroyed by setting that Path's RowStatus to 'destroy'. 5. MIB Specification This MIB module IMPORTs objects from RFCs 2578 [2], 2579 [3], 2580 [3], 3411 [6], and 3811 [5] and it also has REFERENCE clauses to RFCs 3209 [8] and 3212 [12]. TE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, Gauge32, Counter32, Counter64, Unsigned32, TimeTicks FROM SNMPv2-SMI RowStatus, StorageType, TimeStamp, TruthValue FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF TeHopAddress, TeHopAddressType, MplsBitRate FROM MPLS-TC-STD-MIB; teMIB MODULE-IDENTITY LAST-UPDATED "200501040000Z" -- 01 January 2005 ORGANIZATION "IETF Traffic Engineering Working Group" CONTACT-INFO " Editor: Kireeti Kompella Postal: Juniper Networks, Inc. 1194 Mathilda Ave Kompella Standards Track [Page 5] RFC 3970 A Traffic Engineering (TE) MIB January 2005 Sunnyvale, CA 94089 Tel: +1 408 745 2000 E-mail: kireeti@juniper.net The IETF Traffic Engineering Working Group is chaired by Jim Boyle and Ed Kern. WG Mailing List information: General Discussion: te-wg@ops.ietf.org To Subscribe: te-wg-request@ops.ietf.org In Body: subscribe Archive: ftp://ops.ietf.org/pub/lists Comments on the MIB module should be sent to the mailing list. The archives for this mailing list should be consulted for previous discussion on this MIB. " DESCRIPTION "The Traffic Engineering MIB module. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 3970; see the RFC itself for full legal notices. " -- revision history REVISION "200501040000Z" -- 01 January 2005 DESCRIPTION "Initial version, published as RFC 3970." ::= { mib-2 122 } -- Top level objects teMIBNotifications OBJECT IDENTIFIER ::= { teMIB 0 } teMIBObjects OBJECT IDENTIFIER ::= { teMIB 1 } teMIBConformance OBJECT IDENTIFIER ::= { teMIB 2 } -- **************************************************************** -- -- TE MIB Objects -- -- TE Info teInfo OBJECT IDENTIFIER ::= { teMIBObjects 1 } teDistProtocol OBJECT-TYPE Kompella Standards Track [Page 6] RFC 3970 A Traffic Engineering (TE) MIB January 2005 SYNTAX BITS { other(0), isis(1), ospf(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "IGP used to distribute Traffic Engineering information and topology to each device for the purpose of automatic path computation. More than one IGP may be used to distribute TE information. " ::= { teInfo 1 } teSignalingProto OBJECT-TYPE SYNTAX BITS { other(0), rsvpte(1), crldp(2), static(3) -- static configuration } MAX-ACCESS read-only STATUS current DESCRIPTION "Traffic Engineering signaling protocols supported by this device. More than one protocol may be supported. " REFERENCE "For a description of RSVP-TE, see RFC 3209; for CR-LDP, see RFC 3212. " ::= { teInfo 2 } teNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true, then it enables the generation of notifications from this MIB module. Otherwise notifications are not generated. " DEFVAL { false } ::= { teInfo 3 } teNextTunnelIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "An integer that may be used as a new Index in the Kompella Standards Track [Page 7] RFC 3970 A Traffic Engineering (TE) MIB January 2005 teTunnelTable. The special value of 0 indicates that no more new entries can be created in that table. When this MIB module is used for configuration, this object always contains a legal value (if non-zero) for an index that is not currently used in that table. The Command Generator (Network Management Application) reads this variable and uses the (non-zero) value read when creating a new row with an SNMP SET. When the SET is performed, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET succeeds, and the Command Responder (agent) changes the value of this object according to an implementation-specific algorithm. If the value is in use, however, the SET fails. The Network Management Application must then re-read this variable to obtain a new usable value. " ::= { teInfo 4 } teNextPathHopIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "An integer that may be used as a new Index in the tePathHopTable. The special value of 0 indicates that no more new entries can be created in that table. When this MIB module is used for configuration, this object always contains a legal value (if non-zero) for an index that is not currently used in that table. The Command Generator (Network Management Application) reads this variable and uses the (non-zero) value read when creating a new row with an SNMP SET. When the SET is performed, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET Kompella Standards Track [Page 8] RFC 3970 A Traffic Engineering (TE) MIB January 2005 succeeds, and the Command Responder (agent) changes the value of this object according to an implementation-specific algorithm. If the value is in use, however, the SET fails. The Network Management Application must then re-read this variable to obtain a new usable value. " ::= { teInfo 5 } teConfiguredTunnels OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of currently configured Tunnels." ::= { teInfo 6 } teActiveTunnels OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of currently active Tunnels." ::= { teInfo 7 } tePrimaryTunnels OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of currently active Tunnels running on their primary paths. " ::= { teInfo 8 } teAdminGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF TeAdminGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A mapping of configured administrative groups. Each entry represents an Administrative Group and provides a name and index for the group. Administrative groups are used to label links in the Traffic Engineering topology in order to place constraints (include and exclude) on Tunnel paths. A groupName can only be linked to one group number. The groupNumber is the number assigned to the administrative group used in constraints, such as tePathIncludeAny or tePathIncludeAll. " Kompella Standards Track [Page 9] RFC 3970 A Traffic Engineering (TE) MIB January 2005 ::= { teInfo 9 } teAdminGroupEntry OBJECT-TYPE SYNTAX TeAdminGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A mapping between a configured group number and its human-readable name. The group number should be between 1 and 32, inclusive. Group number n represents bit number (n-1) in the bit vector for Include/Exclude constraints. All entries in this table MUST be kept in stable storage so that they will re-appear in case of a restart/reboot. " INDEX { teAdminGroupNumber } ::= { teAdminGroupTable 1 } TeAdminGroupEntry ::= SEQUENCE { teAdminGroupNumber Integer32, teAdminGroupName SnmpAdminString, teAdminGroupRowStatus RowStatus } teAdminGroupNumber OBJECT-TYPE SYNTAX Integer32 (1..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the administrative group." ::= { teAdminGroupEntry 1 } teAdminGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "Name of the administrative group." ::= { teAdminGroupEntry 2 } teAdminGroupRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The value of this object has no effect on whether other objects in this conceptual row can be Kompella Standards Track [Page 10] RFC 3970 A Traffic Engineering (TE) MIB January 2005 modified. " ::= { teAdminGroupEntry 3 } -- Tunnel Table teTunnelTable OBJECT-TYPE SYNTAX SEQUENCE OF TeTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of Configured Traffic Tunnels." ::= { teMIBObjects 2 } teTunnelEntry OBJECT-TYPE SYNTAX TeTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information about a particular Traffic Tunnel. " INDEX { teTunnelIndex } ::= { teTunnelTable 1 } TeTunnelEntry ::= SEQUENCE { teTunnelIndex Unsigned32, teTunnelName SnmpAdminString, teTunnelNextPathIndex Unsigned32, -- Conceptual row information: teTunnelRowStatus RowStatus, teTunnelStorageType StorageType, -- Address information: teTunnelSourceAddressType TeHopAddressType, teTunnelSourceAddress TeHopAddress, teTunnelDestinationAddressType TeHopAddressType, teTunnelDestinationAddress TeHopAddress, -- State/performance information: teTunnelState INTEGER, teTunnelDiscontinuityTimer TimeStamp, teTunnelOctets Counter64, teTunnelPackets Counter64, teTunnelLPOctets Counter32, teTunnelLPPackets Counter32, teTunnelAge TimeTicks, teTunnelTimeUp TimeTicks, teTunnelPrimaryTimeUp TimeTicks, teTunnelTransitions Counter32, teTunnelLastTransition TimeTicks, Kompella Standards Track [Page 11] RFC 3970 A Traffic Engineering (TE) MIB January 2005 teTunnelPathChanges Counter32, teTunnelLastPathChange TimeTicks, teTunnelConfiguredPaths Gauge32, teTunnelStandbyPaths Gauge32, teTunnelOperationalPaths Gauge32 } teTunnelIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index that identifies a Tunnel. If the TE Tunnel is considered an interface, then this index must match the interface index of the corresponding interface. Otherwise, this index must be at least 2^24, so that it does not overlap with any existing interface index. " ::= { teTunnelEntry 1 } teTunnelName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "Name of the Traffic Tunnel. Note that the name of a Tunnel MUST be unique. When a SET request contains a name that is already in use for another entry, then the implementation must return an inconsistentValue error. The value of this object cannot be changed if the if the value of the corresponding teTunnelRowStatus object is 'active'. " ::= { teTunnelEntry 2 } teTunnelNextPathIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "An integer that may be used as a new Index for the next Path in this Tunnel. The special value of 0 indicates that no more Paths can be created for this Tunnel, or that no more new entries can be created in tePathTable. Kompella Standards Track [Page 12] RFC 3970 A Traffic Engineering (TE) MIB January 2005 When this MIB module is used for configuration, this object always contains a legal value (if non-zero) for an index that is not currently used in that table. The Command Generator (Network Management Application) reads this variable and uses the (non-zero) value read when creating a new row with an SNMP SET. When the SET is performed, the Command Responder (agent) must determine whether the value is indeed still unused; Two Network Management Applications may attempt to create a row (configuration entry) simultaneously and use the same value. If it is currently unused, the SET succeeds, and the Command Responder (agent) changes the value of this object according to an implementation-specific algorithm. If the value is in use, however, the SET fails. The Network Management Application must then re-read this variable to obtain a new usable value. " ::= { teTunnelEntry 3 } teTunnelRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. When the value of this object is 'active', then the values for the corresponding objects teTunnelName, teTunnelSourceAddressType, teTunnelSourceAddress, teTunnelDestinationAddressType, and teTunnelDestinationAddress cannot be changed. " ::= { teTunnelEntry 4 } teTunnelStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " ::= { teTunnelEntry 5 } Kompella Standards Track [Page 13] RFC 3970 A Traffic Engineering (TE) MIB January 2005 teTunnelSourceAddressType OBJECT-TYPE SYNTAX TeHopAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Traffic Engineered Tunnel hop address for the source of this Tunnel. Typically, this address type is IPv4 or IPv6, with a prefix length of 32 or 128, respectively. If the TE Tunnel path is being computed by a path computation server, however, it is possible to use more flexible source address types, such as AS numbers or prefix lengths less than host address lengths. The value of this object cannot be changed if the value of the corresponding teTunnelRowStatus object is 'active'. " ::= { teTunnelEntry 6 } teTunnelSourceAddress OBJECT-TYPE SYNTAX TeHopAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Source Traffic Engineered Tunnel hop address of this Tunnel. The type of this address is determined by the value of the corresponding teTunnelSourceAddressType. Note that the source and destination addresses of a Tunnel can be different address types. The value of this object cannot be changed if the value of the corresponding teTunnelRowStatus object is 'active'. " ::= { teTunnelEntry 7 } teTunnelDestinationAddressType OBJECT-TYPE SYNTAX TeHopAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Traffic Engineered Tunnel hop address for the destination of this Tunnel. The value of this object cannot be changed if the value of the corresponding teTunnelRowStatus object is 'active'. Kompella Standards Track [Page 14] RFC 3970 A Traffic Engineering (TE) MIB January 2005 " ::= { teTunnelEntry 8 } teTunnelDestinationAddress OBJECT-TYPE SYNTAX TeHopAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Destination Traffic Engineered Tunnel hop address of this Tunnel. The type of this address is determined by the value of the corresponding teTunnelDestinationAddressType. Note that source and destination addresses of a Tunnel can be different address types. The value of this object cannot be changed if the value of the corresponding teTunnelRowStatus object is 'active'. " ::= { teTunnelEntry 9 } teTunnelState OBJECT-TYPE SYNTAX INTEGER { unknown(1), up(2), down(3), testing(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state of the Tunnel." ::= { teTunnelEntry 10 } teTunnelDiscontinuityTimer OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this tunnel's counters suffered a discontinuity. The relevant counters are teTunnelOctets, teTunnelPackets, teTunnelLPOctets, and teTunnelLPPackets. If no such discontinuities have occurred since the last re-initialization of the local management subsystem then this object contains a zero value. " ::= { teTunnelEntry 11 } Kompella Standards Track [Page 15] RFC 3970 A Traffic Engineering (TE) MIB January 2005 teTunnelOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been forwarded over the Tunnel. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times, as indicated by the value of teTunnelDiscontinuityTimer. " ::= { teTunnelEntry 12 } teTunnelPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that have been forwarded over the Tunnel. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of teTunnelDiscontinuityTimer. " ::= { teTunnelEntry 13 } teTunnelLPOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been forwarded over the Tunnel. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of teTunnelDiscontinuityTimer. " ::= { teTunnelEntry 14 } teTunnelLPPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that have been forwarded over the Tunnel. Kompella Standards Track [Page 16] RFC 3970 A Traffic Engineering (TE) MIB January 2005 Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of teTunnelDiscontinuityTimer. " ::= { teTunnelEntry 15 } teTunnelAge OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The age (i.e., time from creation of this conceptual row till now) of this Tunnel in hundredths of a second. Note that because TimeTicks wrap in about 16 months, this value is best used in interval measurements. " ::= { teTunnelEntry 16 } teTunnelTimeUp OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The total time in hundredths of a second that this Tunnel has been operational. Note that because TimeTicks wrap in about 16 months, this value is best used in interval measurements. An example of usage of this object would be to compute the percentage up time over a period of time by obtaining values of teTunnelAge and teTunnelTimeUp at two points in time and computing the following ratio: ((teTunnelTimeUp2 - teTunnelTimeUp1)/ (teTunnelAge2 - teTunnelAge1)) * 100 %. In doing so, the management station must account for wrapping of the values of teTunnelAge and teTunnelTimeUp between the two measurements. " ::= { teTunnelEntry 17 } teTunnelPrimaryTimeUp OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The total time in hundredths of a second that this Tunnel's primary path has been operational. Note that because TimeTicks wrap in about 16 months, this Kompella Standards Track [Page 17] RFC 3970 A Traffic Engineering (TE) MIB January 2005 value is best used in interval measurements. An example of usage of this field would be to compute what percentage of time that a TE Tunnel was on the primary path over a period of time by computing ((teTunnelPrimaryTimeUp2 - teTunnelPrimaryTimeUp1)/ (teTunnelTimeUp2 - teTunnelTimeUp1))*100 %. In doing so, the management station must account for wrapping of the values of teTunnelPrimaryTimeUp and teTunnelTimeUp between the two measurements. " ::= { teTunnelEntry 18 } teTunnelTransitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of operational state transitions (up -> down and down -> up) this Tunnel has undergone. " ::= { teTunnelEntry 19 } teTunnelLastTransition OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time in hundredths of a second since the last operational state transition occurred on this Tunnel. Note that if the last transition was over 16 months ago, this value will be inaccurate. " ::= { teTunnelEntry 20 } teTunnelPathChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of path changes this Tunnel has had." ::= { teTunnelEntry 21 } teTunnelLastPathChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current Kompella Standards Track [Page 18] RFC 3970 A Traffic Engineering (TE) MIB January 2005 DESCRIPTION "The time in hundredths of a second since the last path change occurred on this Tunnel. Note that if the last transition was over 16 months ago, this value will be inaccurate. Path changes may be caused by network events or by reconfiguration that affects the path. " ::= { teTunnelEntry 22 } teTunnelConfiguredPaths OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of paths configured for this Tunnel." ::= { teTunnelEntry 23 } teTunnelStandbyPaths OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of standby paths configured for this Tunnel. " ::= { teTunnelEntry 24 } teTunnelOperationalPaths OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of operational paths for this Tunnel. This includes the path currently active, as well as operational standby paths. " ::= { teTunnelEntry 25 } -- **************************************************************** -- -- Tunnel Path Table -- tePathTable OBJECT-TYPE SYNTAX SEQUENCE OF TePathEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of Configured Traffic Tunnels." ::= { teMIBObjects 3 } Kompella Standards Track [Page 19] RFC 3970 A Traffic Engineering (TE) MIB January 2005 tePathEntry OBJECT-TYPE SYNTAX TePathEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information about a particular Traffic Tunnel. Each Traffic Tunnel can have zero or more Traffic Paths. As a Traffic Path can only exist over an existing Traffic Tunnel, all tePathEntries with a value of n for teTunnelIndex MUST be removed by the implementation when the corresponding teTunnelEntry with a value of n for teTunnelIndex is removed. " INDEX { teTunnelIndex, tePathIndex } ::= { tePathTable 1 } TePathEntry ::= SEQUENCE { tePathIndex Unsigned32, tePathName SnmpAdminString, -- Conceptual row information tePathRowStatus RowStatus, tePathStorageType StorageType, -- Path properties tePathType INTEGER, tePathConfiguredRoute Unsigned32, tePathBandwidth MplsBitRate, tePathIncludeAny Unsigned32, tePathIncludeAll Unsigned32, tePathExclude Unsigned32, tePathSetupPriority Integer32, tePathHoldPriority Integer32, tePathProperties BITS, -- Path status tePathOperStatus INTEGER, tePathAdminStatus INTEGER, tePathComputedRoute Unsigned32, tePathRecordedRoute Unsigned32 } tePathIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies a path within a Tunnel. Kompella Standards Track [Page 20] RFC 3970 A Traffic Engineering (TE) MIB January 2005 The combination of thus uniquely identifies a path among all paths on this router. " ::= { tePathEntry 1 } tePathName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The name of this path. A pathName must be unique within the set of paths over a single tunnel. If a SET request is received with a duplicate name, then the implementation MUST return an inconsistentValue error. The value of this object cannot be changed if the value of the corresponding teTunnelRowStatus object is 'active'. " ::= { tePathEntry 2 } tePathRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. When the value of this object is 'active', then the value of tePathName cannot be changed. All other writable objects may be changed; however, these changes may affect traffic going over the TE tunnel or require the path to be computed and/or re-signaled. " ::= { tePathEntry 3 } tePathStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " Kompella Standards Track [Page 21] RFC 3970 A Traffic Engineering (TE) MIB January 2005 ::= { tePathEntry 4 } tePathType OBJECT-TYPE SYNTAX INTEGER { other(1), primary(2), standby(3), secondary(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type for this PathEntry; i.e., whether this path is a primary path, a standby path, or a secondary path. " ::= { tePathEntry 5 } tePathConfiguredRoute OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The route that this TE path is configured to follow; i.e., an ordered list of hops. The value of this object gives the primary index into the Hop Table. The secondary index is the hop count in the path, so to get the route, one could get the first hop with index in the Hop Table and do a getnext to get subsequent hops. " ::= { tePathEntry 6 } tePathBandwidth OBJECT-TYPE SYNTAX MplsBitRate UNITS "Kilobits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The configured bandwidth for this Tunnel, in units of thousands of bits per second (Kbps). " DEFVAL { 0 } ::= { tePathEntry 7 } tePathIncludeAny OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a configured set of administrative groups specified as a bit vector (i.e., bit n is 1 if group Kompella Standards Track [Page 22] RFC 3970 A Traffic Engineering (TE) MIB January 2005 n is in the set, where n = 0 is the LSB). For each link that this path goes through, the link must have at least one of the groups specified in IncludeAny to be acceptable. If IncludeAny is zero, all links are acceptable. " DEFVAL { 0 } ::= { tePathEntry 8 } tePathIncludeAll OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a configured set of administrative groups specified as a bit vector (i.e., bit n is 1 if group n is in the set, where n = 0 is the LSB). For each link that this path goes through, the link must have all of the groups specified in IncludeAll to be acceptable. If IncludeAll is zero, all links are acceptable. " DEFVAL { 0 } ::= { tePathEntry 9 } tePathExclude OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This is a configured set of administrative groups specified as a bit vector (i.e., bit n is 1 if group n is in the set, where n = 0 is the LSB). For each link that this path goes through, the link MUST have groups associated with it, and the intersection of the link's groups and the 'exclude' set MUST be null. " DEFVAL { 0 } ::= { tePathEntry 10 } tePathSetupPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "The setup priority configured for this path, with 0 as the highest priority and 7 as the lowest. " DEFVAL { 7 } Kompella Standards Track [Page 23] RFC 3970 A Traffic Engineering (TE) MIB January 2005 ::= { tePathEntry 11 } tePathHoldPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "The hold priority configured for this path, with 0 as the highest priority and 7 as the lowest. " DEFVAL { 0 } ::= { tePathEntry 12 } tePathProperties OBJECT-TYPE SYNTAX BITS { recordRoute(0), cspf(1), makeBeforeBreak(2), mergeable(3), fastReroute(4), protected(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The set of configured properties for this path, expressed as a bit map. For example, if the path supports 'make before break', then bit 2 is set. " ::= { tePathEntry 13 } tePathOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(0), down(1), testing(2), dormant(3), ready(4), operational(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the path: unknown: down: Signaling failed. testing: Administratively set aside for testing. dormant: Not signaled (for a backup tunnel). ready: Signaled but not yet carrying traffic. operational: Signaled and carrying traffic. " Kompella Standards Track [Page 24] RFC 3970 A Traffic Engineering (TE) MIB January 2005 ::= { tePathEntry 14 } tePathAdminStatus OBJECT-TYPE SYNTAX INTEGER { normal(1), testing(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The operational status of the path: normal: Used normally for forwarding. testing: Administratively set aside for testing. " ::= { tePathEntry 15 } tePathComputedRoute OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The route computed for this path, perhaps using some form of Constraint-based Routing. The algorithm is implementation dependent. This object returns the computed route as an ordered list of hops. The value of this object gives the primary index into the Hop Table. The secondary index is the hop count in the path, so to get the route, one could get the first hop with index in the Hop Table and do a getnext to get subsequent hops. A value of zero (0) means there is no computedRoute. " ::= { tePathEntry 16 } tePathRecordedRoute OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The route actually used for this path, as recorded by the signaling protocol. This is again an ordered list of hops; each hop is expected to be strict. The value of this object gives the primary index into the Hop Table. The secondary index is the hop count in the path, so to get the route, one can get the first hop with index in the Hop Table and do a getnext to get subsequent Kompella Standards Track [Page 25] RFC 3970 A Traffic Engineering (TE) MIB January 2005 hops. A value of zero (0) means there is no recordedRoute. " ::= { tePathEntry 17 } -- **************************************************************** -- -- Tunnel Path Hop Table -- tePathHopTable OBJECT-TYPE SYNTAX SEQUENCE OF TePathHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of Tunnel Path Hops." ::= { teMIBObjects 4 } tePathHopEntry OBJECT-TYPE SYNTAX TePathHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information about a particular hop. " INDEX { teHopListIndex, tePathHopIndex } ::= { tePathHopTable 1 } TePathHopEntry ::= SEQUENCE { teHopListIndex Unsigned32, tePathHopIndex Unsigned32, -- Conceptual row information tePathHopRowStatus RowStatus, tePathHopStorageType StorageType, tePathHopAddrType TeHopAddressType, tePathHopAddress TeHopAddress, tePathHopType INTEGER } teHopListIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that identifies a list of hops. This is the primary index to access hops. " ::= { tePathHopEntry 1 } Kompella Standards Track [Page 26] RFC 3970 A Traffic Engineering (TE) MIB January 2005 tePathHopIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that identifies a particular hop among the list of hops for a path. An index of i identifies the ith hop. This is the secondary index for a hop entry. " ::= { tePathHopEntry 2 } tePathHopRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Any field in this table can be changed, even if the value of this object is 'active'. However, such a change may cause traffic to be rerouted or even disrupted. " ::= { tePathHopEntry 3 } tePathHopStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " ::= { tePathHopEntry 4 } tePathHopAddrType OBJECT-TYPE SYNTAX TeHopAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Traffic Engineered Tunnel hop Address of this hop. The value of this object cannot be changed if the value of the corresponding tePathRowStatus object is 'active'. " ::= { tePathHopEntry 5 } Kompella Standards Track [Page 27] RFC 3970 A Traffic Engineering (TE) MIB January 2005 tePathHopAddress OBJECT-TYPE SYNTAX TeHopAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Traffic Engineered Tunnel hop Address of this hop. The type of this address is determined by the value of the corresponding tePathHopAddressType. The value of this object cannot be changed if the value of the corresponding teTunnelRowStatus object is 'active'. " ::= { tePathHopEntry 6 } tePathHopType OBJECT-TYPE SYNTAX INTEGER { unknown(0), loose(1), strict(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of hop: unknown: loose: This hop is a LOOSE hop. strict: This hop is a STRICT hop. " ::= { tePathHopEntry 7 } -- **************************************************************** -- -- TE Notifications -- teTunnelUp NOTIFICATION-TYPE OBJECTS { teTunnelName, tePathName } -- TunnelPath STATUS current DESCRIPTION "A teTunnelUp notification is generated when the Tunnel indexed by teTunnelName transitions to the 'up' state. A tunnel is up when at least one of its paths is up. The tePathName is the name of the path whose transition to up made the tunnel go up. Kompella Standards Track [Page 28] RFC 3970 A Traffic Engineering (TE) MIB January 2005 This notification MUST be limited to at most one every minute, in case the tunnel flaps up and down. " ::= { teMIBNotifications 1 } teTunnelDown NOTIFICATION-TYPE OBJECTS { teTunnelName, tePathName } -- TunnelPath STATUS current DESCRIPTION "A teTunnelDown notification is generated when the Tunnel indexed by teTunnelName transitions to the 'down' state. A tunnel is up when at least one of its paths is up. The tePathName is the name of the path whose transition to down made the tunnel go down. This notification MUST be limited to at most one every minute, in case the tunnel flaps up and down. " ::= { teMIBNotifications 2 } teTunnelChanged NOTIFICATION-TYPE OBJECTS { teTunnelName, tePathName } -- toTunnelPath STATUS current DESCRIPTION "A teTunnelChanged notification is generated when an active path on the Tunnel indexed by teTunnelName changes or a new path becomes active. The value of tePathName is the new active path. This notification MUST be limited to at most one every minute, in case the tunnel changes quickly. " ::= { teMIBNotifications 3 } teTunnelRerouted NOTIFICATION-TYPE OBJECTS { teTunnelName, tePathName } -- toTunnelPath STATUS current DESCRIPTION "A teTunnelRerouted notification is generated when an active path for the Tunnel indexed by teTunnelName stays the same, but its route changes. This notification MUST be limited to at most one every minute, in case the tunnel reroutes quickly. " ::= { teMIBNotifications 4 } Kompella Standards Track [Page 29] RFC 3970 A Traffic Engineering (TE) MIB January 2005 -- End of TE-MIB objects -- **************************************************************** -- -- TE Compliance Statements -- teGroups OBJECT IDENTIFIER ::= { teMIBConformance 1 } teModuleCompliance OBJECT IDENTIFIER ::= { teMIBConformance 2 } -- **************************************************************** -- -- TE object groups -- teTrafficEngineeringGroup OBJECT-GROUP OBJECTS { teTunnelName, teTunnelNextPathIndex, teTunnelRowStatus, teTunnelStorageType, teTunnelSourceAddressType, teTunnelSourceAddress, teTunnelDestinationAddressType, teTunnelDestinationAddress, teTunnelState, teTunnelDiscontinuityTimer, teTunnelOctets, teTunnelPackets, teTunnelLPOctets, teTunnelLPPackets, teTunnelAge, teTunnelTimeUp, teTunnelPrimaryTimeUp, teTunnelTransitions, teTunnelLastTransition, teTunnelPathChanges, teTunnelLastPathChange, teTunnelConfiguredPaths, teTunnelStandbyPaths, teTunnelOperationalPaths, tePathBandwidth, tePathIncludeAny, tePathIncludeAll, tePathExclude, Kompella Standards Track [Page 30] RFC 3970 A Traffic Engineering (TE) MIB January 2005 tePathSetupPriority, tePathHoldPriority, tePathProperties, tePathOperStatus, tePathAdminStatus, tePathComputedRoute, tePathRecordedRoute, teDistProtocol, teSignalingProto, teNotificationEnable, teNextTunnelIndex, teNextPathHopIndex, teAdminGroupName, teAdminGroupRowStatus, teConfiguredTunnels, teActiveTunnels, tePrimaryTunnels, tePathName, tePathType, tePathRowStatus, tePathStorageType, tePathConfiguredRoute, tePathHopRowStatus, tePathHopStorageType, tePathHopAddrType, tePathHopAddress, tePathHopType } STATUS current DESCRIPTION "Objects for Traffic Engineering in this MIB module." ::= { teGroups 1 } teNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { teTunnelUp, teTunnelDown, teTunnelChanged, teTunnelRerouted } STATUS current DESCRIPTION "Notifications specified in this MIB module." ::= { teGroups 2 } -- **************************************************************** -- -- TE compliance statements -- -- There are four compliance statements: read-only and full Kompella Standards Track [Page 31] RFC 3970 A Traffic Engineering (TE) MIB January 2005 -- compliance for regular TE devices, and read-only and full -- compliance for path computation servers. -- teModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB module is implemented without support for read-create (i.e., in read-only mode), then such an implementation can claim read-only compliance. Such a device can be monitored but cannot be configured with this MIB module. " MODULE -- enclosing module, i.e., TE-MIB MANDATORY-GROUPS { teTrafficEngineeringGroup } GROUP teNotificationGroup DESCRIPTION "Implementation of this group is optional." OBJECT teNotificationEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teAdminGroupName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teAdminGroupRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Kompella Standards Track [Page 32] RFC 3970 A Traffic Engineering (TE) MIB January 2005 OBJECT teTunnelSourceAddressType SYNTAX TeHopAddressType { ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and IPv6 host addresses." OBJECT teTunnelSourceAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelDestinationAddressType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelDestinationAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathConfiguredRoute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathBandwidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathIncludeAny MIN-ACCESS read-only DESCRIPTION "Write access is not required." Kompella Standards Track [Page 33] RFC 3970 A Traffic Engineering (TE) MIB January 2005 OBJECT tePathIncludeAll MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathExclude MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathSetupPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHoldPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathProperties MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { teModuleCompliance 1 } teModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB module is implemented with support for read-create, then the implementation can claim full compliance. Such devices can be both Kompella Standards Track [Page 34] RFC 3970 A Traffic Engineering (TE) MIB January 2005 monitored and configured with this MIB module. " MODULE -- enclosing module, i.e., TE-MIB MANDATORY-GROUPS { teTrafficEngineeringGroup } GROUP teNotificationGroup DESCRIPTION "Implementation of this group is optional." OBJECT teAdminGroupRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for notInService, createAndWait and notReady is not required. " OBJECT teTunnelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required. " OBJECT teTunnelSourceAddressType SYNTAX TeHopAddressType { ipv4(1), ipv6(2) } DESCRIPTION "Write access is required. An implementation is only required to support IPv4 and IPv6 host addresses. " OBJECT tePathRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required. " OBJECT tePathHopRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), Kompella Standards Track [Page 35] RFC 3970 A Traffic Engineering (TE) MIB January 2005 createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required. " ::= { teModuleCompliance 2 } teModuleServerReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB module is implemented by a path computation server without support for read-create (i.e., in read-only mode), then the implementation can claim read-only compliance. Such a device can be monitored but cannot be configured with this MIB module. " MODULE -- enclosing module, i.e., TE-MIB MANDATORY-GROUPS { teTrafficEngineeringGroup } GROUP teNotificationGroup DESCRIPTION "Implementation of this group is optional." OBJECT teNotificationEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teAdminGroupName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teAdminGroupRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." Kompella Standards Track [Page 36] RFC 3970 A Traffic Engineering (TE) MIB January 2005 OBJECT teTunnelStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelSourceAddressType MIN-ACCESS read-only DESCRIPTION "Write access is not required. A path computation server SHOULD implement all types of tunnel source address types. " OBJECT teTunnelSourceAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelDestinationAddressType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teTunnelDestinationAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathConfiguredRoute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathBandwidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." Kompella Standards Track [Page 37] RFC 3970 A Traffic Engineering (TE) MIB January 2005 OBJECT tePathIncludeAny MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathIncludeAll MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathExclude MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathSetupPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHoldPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathProperties MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tePathHopAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { teModuleCompliance 3 } teModuleServerFullCompliance MODULE-COMPLIANCE Kompella Standards Track [Page 38] RFC 3970 A Traffic Engineering (TE) MIB January 2005 STATUS current DESCRIPTION "When this MIB module is implemented by a path computation server with support for read-create, then the implementation can claim full compliance. " MODULE -- enclosing module, i.e., TE-MIB MANDATORY-GROUPS { teTrafficEngineeringGroup } GROUP teNotificationGroup DESCRIPTION "Implementation of this group is optional." OBJECT teAdminGroupRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for notInService, createAndWait, and notReady is not required. " OBJECT teTunnelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required. " OBJECT teTunnelSourceAddressType DESCRIPTION "Write access is required. An implementation of a path computation server SHOULD support all types of tunnel source address types. " OBJECT tePathRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required. " OBJECT tePathHopRowStatus Kompella Standards Track [Page 39] RFC 3970 A Traffic Engineering (TE) MIB January 2005 SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required. " ::= { teModuleCompliance 4 } END 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [5] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [6] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [7] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. 6.2. Informative References [8] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Kompella Standards Track [Page 40] RFC 3970 A Traffic Engineering (TE) MIB January 2005 [9] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [11] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999. [12] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint- Based LSP Setup using LDP", RFC 3212, January 2002. 7. Security Considerations This MIB module relates to the configuration and management of Traffic Engineering tunnels. The unauthorized manipulation of fields in the tables teAdminGroupTable, teTunnelTable, tePathTable, and tePathHopTable may lead to tunnel flapping, tunnel paths being changed, or traffic being disrupted. In addition, if these tables are read by unauthorized parties, the information can be used to trace traffic patterns, traffic volumes, and tunnel paths. This may be considered proprietary and confidential information by some providers. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: teAdminGroupTable: Changing this will affect the semantics of include and exclude constraints, and thus traffic takes unintended routes. teTunnelTable: Changing this affects many properties of traffic tunnels. tePathTable: Changing this affects the constraints (including bandwidth) of tunnel paths, as well as the status of the path. tePathHopTable: Changing this affects the route followed by a traffic tunnel path. Kompella Standards Track [Page 41] RFC 3970 A Traffic Engineering (TE) MIB January 2005 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: teTunnelTable: Describes tunnel endpoints and traffic volumes. tePathTable: Describes path properties. tePathHopTable: Describes path routes. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [9], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Acknowledgments It was Tony Li's suggestion that the author embark on this MIB. Many thanks to him and to Der-Hwa Gan for their input and help. Many thanks, too, to Bert Wijnen for his incredible help, both with improving the correctness, structure, and readability of the MIB module, and with the text of the RFC. Thanks also to Adrian Farrel for his detailed review. Kompella Standards Track [Page 42] RFC 3970 A Traffic Engineering (TE) MIB January 2005 Author's Address Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net Kompella Standards Track [Page 43] RFC 3970 A Traffic Engineering (TE) MIB January 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kompella Standards Track [Page 44] snmp-mibs-downloader-1.1/mibrfcs/rfc4001.txt0000644000000000000000000013141411402176071015552 0ustar Network Working Group M. Daniele Request for Comments: 4001 SyAM Software, Inc. Obsoletes: 3291 B. Haberman Category: Standards Track Johns Hopkins University S. Routhier Wind River Systems, Inc. J. Schoenwaelder International University Bremen February 2005 Textual Conventions for Internet Network Addresses 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. Daniele, et al. Standards Track [Page 1] RFC 4001 Internet Network Address Conventions February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Table Indexing . . . . . . . . . . . . . . . . . . . . . 14 4.2. Uniqueness of Addresses . . . . . . . . . . . . . . . . 14 4.3. Multiple Addresses per Host . . . . . . . . . . . . . . 15 4.4. Resolving DNS Names . . . . . . . . . . . . . . . . . . 15 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Changes from RFC 3291 to RFC 4001 . . . . . . . . . . . . . . 18 9. Changes from RFC 2851 to RFC 3291 . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Several standards-track MIB modules use the IpAddress SMIv2 base type. This limits the applicability of these MIB modules to IP Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become problematic with the introduction of IP Version 6 (IPv6) addresses [RFC3513]. This document defines multiple textual conventions (TCs) as a means to express generic Internet network layer addresses within MIB module specifications. The solution is compatible with SMIv2 (STD 58) and SMIv1 (STD 16). New MIB definitions that have to express network layer Internet addresses SHOULD use the textual conventions defined in this memo. New MIB modules SHOULD NOT use the SMIv2 IpAddress base type anymore. A generic Internet address consists of two objects: one whose syntax is InetAddressType, and another whose syntax is InetAddress. The value of the first object determines how the value of the second is encoded. The InetAddress textual convention represents an opaque Internet address value. The InetAddressType enumeration is used to "cast" the InetAddress value into a concrete textual convention for the address type. This usage of multiple textual conventions allows expression of the display characteristics of each address type and makes the set of defined Internet address types extensible. Daniele, et al. Standards Track [Page 2] RFC 4001 Internet Network Address Conventions February 2005 The textual conventions for well-known transport domains support scoped Internet addresses. The scope of an Internet address is a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. A scope zone (or, simply, a zone) is a concrete connected region of topology of a given scope. Note that a zone is a particular instance of a topological region, whereas a scope is the size of a topological region [RFC4007]. Since Internet addresses on devices that connect multiple zones are not necessarily unique, an additional zone index is needed on these devices to select an interface. The textual conventions InetAddressIPv4z and InetAddressIPv6z are provided to support Internet addresses that include a zone index. To support arbitrary combinations of scoped Internet addresses, MIB authors SHOULD use a separate InetAddressType object for each InetAddress object. The textual conventions defined in this document can also be used to represent generic Internet subnets and Internet address ranges. A generic Internet subnet is represented by three objects: one whose syntax is InetAddressType, a second one whose syntax is InetAddress, and a third one whose syntax is InetAddressPrefixLength. The InetAddressType value again determines the concrete format of the InetAddress value, whereas the InetAddressPrefixLength identifies the Internet network address prefix. A generic range of consecutive Internet addresses is represented by three objects. The first one has the syntax InetAddressType, and the remaining objects have the syntax InetAddress and specify the start and end of the address range. Again, the InetAddressType value determines the format of the InetAddress values. The textual conventions defined in this document can be used to define Internet addresses by using DNS domain names in addition to IPv4 and IPv6 addresses. A MIB designer can write compliance statements to express that only a subset of the possible address types must be supported by a compliant implementation. MIB developers who need to represent Internet addresses SHOULD use these definitions whenever applicable, as opposed to defining their own constructs. Even MIB modules that only need to represent IPv4 or IPv6 addresses SHOULD use the InetAddressType/InetAddress textual conventions defined in this memo. There are many widely deployed MIB modules that use IPv4 addresses and that have to be revised to support IPv6. These MIB modules can be categorized as follows: Daniele, et al. Standards Track [Page 3] RFC 4001 Internet Network Address Conventions February 2005 1. MIB modules that define management information that is, in principle, IP version neutral, but the MIB currently uses addressing constructs specific to a certain IP version. 2. MIB modules that define management information that is specific to a particular IP version (either IPv4 or IPv6) and that is very unlikely to ever be applicable to another IP version. MIB modules of the first type SHOULD provide object definitions (e.g., tables) that work with all versions of IP. In particular, when revising a MIB module that contains IPv4 specific tables, it is suggested to define new tables using the textual conventions defined in this memo that support all versions of IP. The status of the new tables SHOULD be "current", whereas the status of the old IP version specific tables SHOULD be changed to "deprecated". The other approach, of having multiple similar tables for different IP versions, is strongly discouraged. MIB modules of the second type, which are inherently IP version specific, do not need to be redefined. Note that even in this case, any additions to these MIB modules or to new IP version specific MIB modules SHOULD use the textual conventions defined in this memo. MIB developers SHOULD NOT use the textual conventions defined in this document to represent generic transport layer addresses. A special set of textual conventions for this purpose is defined in RFC 3419 [RFC3419]. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY", in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Daniele, et al. Standards Track [Page 4] RFC 4001 Internet Network Address Conventions February 2005 3. Definitions INET-ADDRESS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; inetAddressMIB MODULE-IDENTITY LAST-UPDATED "200502040000Z" ORGANIZATION "IETF Operations and Management Area" CONTACT-INFO "Juergen Schoenwaelder (Editor) International University Bremen P.O. Box 750 561 28725 Bremen, Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Send comments to ." DESCRIPTION "This MIB module defines textual conventions for representing Internet addresses. An Internet address can be an IPv4 address, an IPv6 address, or a DNS domain name. This module also defines textual conventions for Internet port numbers, autonomous system numbers, and the length of an Internet address prefix. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4001, see the RFC itself for full legal notices." REVISION "200502040000Z" DESCRIPTION "Third version, published as RFC 4001. This revision introduces the InetZoneIndex, InetScopeType, and InetVersion textual conventions." REVISION "200205090000Z" DESCRIPTION "Second version, published as RFC 3291. This revision contains several clarifications and introduces several new textual conventions: InetAddressPrefixLength, InetPortNumber, InetAutonomousSystemNumber, InetAddressIPv4z, and InetAddressIPv6z." REVISION "200006080000Z" Daniele, et al. Standards Track [Page 5] RFC 4001 Internet Network Address Conventions February 2005 DESCRIPTION "Initial version, published as RFC 2851." ::= { mib-2 76 } InetAddressType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In Daniele, et al. Standards Track [Page 6] RFC 4001 Internet Network Address Conventions February 2005 particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1))." SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4), dns(16) } InetAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate." SYNTAX OCTET STRING (SIZE (0..255)) InetAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents an IPv4 network address: Daniele, et al. Standards Track [Page 7] RFC 4001 Internet Network Address Conventions February 2005 Octets Contents Encoding 1-4 IPv4 address network-byte order The corresponding InetAddressType value is ipv4(1). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (4)) InetAddressIPv6 ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x" STATUS current DESCRIPTION "Represents an IPv6 network address: Octets Contents Encoding 1-16 IPv6 address network-byte order The corresponding InetAddressType value is ipv6(2). This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (16)) InetAddressIPv4z ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d%4d" STATUS current DESCRIPTION "Represents a non-global IPv4 network address, together with its zone index: Octets Contents Encoding 1-4 IPv4 address network-byte order 5-8 zone index network-byte order The corresponding InetAddressType value is ipv4z(3). The zone index (bytes 5-8) is used to disambiguate identical address values on nodes that have interfaces attached to different zones of the same scope. The zone index may contain the special value 0, which refers to the default zone for each scope. This textual convention SHOULD NOT be used directly in object Daniele, et al. Standards Track [Page 8] RFC 4001 Internet Network Address Conventions February 2005 definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (8)) InetAddressIPv6z ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" STATUS current DESCRIPTION "Represents a non-global IPv6 network address, together with its zone index: Octets Contents Encoding 1-16 IPv6 address network-byte order 17-20 zone index network-byte order The corresponding InetAddressType value is ipv6z(4). The zone index (bytes 17-20) is used to disambiguate identical address values on nodes that have interfaces attached to different zones of the same scope. The zone index may contain the special value 0, which refers to the default zone for each scope. This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (20)) InetAddressDNS ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents a DNS domain name. The name SHOULD be fully qualified whenever possible. The corresponding InetAddressType is dns(16). The DESCRIPTION clause of InetAddress objects that may have InetAddressDNS values MUST fully describe how (and when) these names are to be resolved to IP addresses. The resolution of an InetAddressDNS value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS record takes precedence depends on the configuration of the resolver. Daniele, et al. Standards Track [Page 9] RFC 4001 Internet Network Address Conventions February 2005 This textual convention SHOULD NOT be used directly in object definitions, as it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with InetAddressType, as a pair." SYNTAX OCTET STRING (SIZE (1..255)) InetAddressPrefixLength ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Denotes the length of a generic Internet network address prefix. A value of n corresponds to an IP address mask that has n contiguous 1-bits from the most significant bit (MSB), with all other bits set to 0. An InetAddressPrefixLength value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddressPrefixLength textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddressPrefixLength textual convention, if they appear in the same logical row. InetAddressPrefixLength values larger than the maximum length of an IP address for a specific InetAddressType are treated as the maximum significant value applicable for the InetAddressType. The maximum significant value is 32 for the InetAddressType 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value for the InetAddressType 'dns(16)' is 0. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the Internet network address prefix is unknown or does not apply. The upper bound of the prefix length has been chosen to be consistent with the maximum size of an InetAddress." SYNTAX Unsigned32 (0..2040) InetPortNumber ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents a 16 bit port number of an Internet transport Daniele, et al. Standards Track [Page 10] RFC 4001 Internet Network Address Conventions February 2005 layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from . The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter." REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" SYNTAX Unsigned32 (0..65535) InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents an autonomous system number that identifies an Autonomous System (AS). An AS is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes'. IANA maintains the AS number space and has delegated large parts to the regional registries. Autonomous system numbers are currently limited to 16 bits (0..65535). There is, however, work in progress to enlarge the autonomous system number space to 32 bits. Therefore, this textual convention uses an Unsigned32 value without a range restriction in order to support a larger autonomous system number space." REFERENCE "RFC 1771, RFC 1930" SYNTAX Unsigned32 InetScopeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a scope type. This textual convention can be used in cases where a MIB has to represent different scope types and there is no context information, such as an InetAddress object, that implicitly defines the scope type. Note that not all possible values have been assigned yet, but they may be assigned in future revisions of this specification. Applications should therefore be able to deal with values not yet assigned." REFERENCE "RFC 3513" SYNTAX INTEGER { -- reserved(0), Daniele, et al. Standards Track [Page 11] RFC 4001 Internet Network Address Conventions February 2005 interfaceLocal(1), linkLocal(2), subnetLocal(3), adminLocal(4), siteLocal(5), -- site-local unicast addresses -- have been deprecated by RFC 3879 -- unassigned(6), -- unassigned(7), organizationLocal(8), -- unassigned(9), -- unassigned(10), -- unassigned(11), -- unassigned(12), -- unassigned(13), global(14) -- reserved(15) } InetZoneIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A zone index identifies an instance of a zone of a specific scope. The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured. The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known." REFERENCE "RFC4007" SYNTAX Unsigned32 InetVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value representing a version of the IP protocol. unknown(0) An unknown or unspecified version of the IP protocol. Daniele, et al. Standards Track [Page 12] RFC 4001 Internet Network Address Conventions February 2005 ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5). ipv6(2) The IPv6 protocol as defined in RFC 2460. Note that this textual convention SHOULD NOT be used to distinguish different address types associated with IP protocols. The InetAddressType has been designed for this purpose." REFERENCE "RFC 791, RFC 2460" SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } END 4. Usage Hints The InetAddressType and InetAddress textual conventions have been introduced to avoid over-constraining an object definition by the use of the IpAddress SMI base type, which is IPv4 specific. An InetAddressType/InetAddress pair can represent IP addresses in various formats. The InetAddressType and InetAddress objects SHOULD NOT be sub-typed in object definitions. Sub-typing binds the MIB module to specific address formats, which may cause serious problems if new address formats need to be introduced. Note that it is possible to write compliance statements indicating that only a subset of the defined address types must be implemented to be compliant. Every usage of the InetAddress or InetAddressPrefixLength textual conventions must specify which InetAddressType object provides the context for the interpretation of the InetAddress or InetAddressPrefixLength textual convention. It is suggested that the InetAddressType object is logically registered before the object(s) that use(s) the InetAddress or InetAddressPrefixLength textual convention. An InetAddressType object is logically registered before an InetAddress or InetAddressPrefixLength object if it appears before the InetAddress or InetAddressPrefixLength object in the conceptual row (which includes any index objects). This rule allows programs such as MIB compilers to identify the InetAddressType of a given InetAddress or InetAddressPrefixLength object by searching for the InetAddressType object, which precedes an InetAddress or InetAddressPrefixLength object. Daniele, et al. Standards Track [Page 13] RFC 4001 Internet Network Address Conventions February 2005 4.1. Table Indexing When a generic Internet address is used as an index, both the InetAddressType and InetAddress objects MUST be used. The InetAddressType object MUST be listed before the InetAddress object in the INDEX clause. The IMPLIED keyword MUST NOT be used for an object of type InetAddress in an INDEX clause. Instance sub-identifiers are then of the form T.N.O1.O2...On, where T is the value of the InetAddressType object, O1...On are the octets in the InetAddress object, and N is the number of those octets. There is a meaningful lexicographical ordering to tables indexed in this fashion. Command generator applications may look up specific addresses of known type and value, issue GetNext requests for addresses of a single type, or issue GetNext requests for a specific type and address prefix. 4.2. Uniqueness of Addresses IPv4 addresses were intended to be globally unique, current usage notwithstanding. IPv6 addresses were architected to have different scopes and hence uniqueness [RFC3513]. In particular, IPv6 "link- local" unicast addresses are not guaranteed to be unique on any particular node. In such cases, the duplicate addresses must be configured on different interfaces. So the combination of an IPv6 address and a zone index is unique [RFC4007]. The InetAddressIPv6 textual convention has been defined to represent global IPv6 addresses and non-global IPv6 addresses in cases where no zone index is needed (e.g., on end hosts with a single interface). The InetAddressIPv6z textual convention has been defined to represent non-global IPv6 addresses in cases where a zone index is needed (e.g., a router connecting multiple zones). Therefore, MIB designers who use InetAddressType/InetAddress pairs do not need to define additional objects in order to support non-global addresses on nodes that connect multiple zones. The InetAddressIPv4z is intended for use in MIB modules (such as the TCP-MIB) which report addresses in the address family used on the wire, but where the entity instrumented obtains these addresses from applications or administrators in a form that includes a zone index, such as v4-mapped IPv6 addresses. Daniele, et al. Standards Track [Page 14] RFC 4001 Internet Network Address Conventions February 2005 The size of the zone index has been chosen so that it is consistent with (i) the numerical zone index, defined in [RFC4007], and (ii) the sin6_scope_id field of the sockaddr_in6 structure, defined in RFC 2553 [RFC2553]. 4.3. Multiple Addresses per Host A single host system may be configured with multiple addresses (IPv4 or IPv6), and possibly with multiple DNS names. Thus it is possible for a single host system to be accessible by multiple InetAddressType/InetAddress pairs. If this could be an implementation or usage issue, the DESCRIPTION clause of the relevant objects must fully describe which address is reported in a given InetAddressType/InetAddress pair. 4.4. Resolving DNS Names DNS names MUST be resolved to IP addresses when communication with the named host is required. This raises a temporal aspect to defining MIB objects whose value is a DNS name: When is the name translated to an address? For example, consider an object defined to indicate a forwarding destination, and whose value is a DNS name. When does the forwarding entity resolve the DNS name? Each time forwarding occurs, or just once when the object was instantiated? The DESCRIPTION clause of these objects SHOULD precisely define how and when any required name to address resolution is done. Similarly, the DESCRIPTION clause of these objects SHOULD precisely define how and when a reverse lookup is being done, if an agent has accessed instrumentation that knows about an IP address, and if the MIB module or implementation requires it to map the IP address to a DNS name. 5. Table Indexing Example This example shows a table listing communication peers that are identified by either an IPv4 address, an IPv6 address, or a DNS name. The table definition also prohibits entries with an empty address (whose type would be "unknown"). The size of a DNS name is limited to 64 characters in order to satisfy OID length constraints. Daniele, et al. Standards Track [Page 15] RFC 4001 Internet Network Address Conventions February 2005 peerTable OBJECT-TYPE SYNTAX SEQUENCE OF PeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of communication peers." ::= { somewhere 1 } peerEntry OBJECT-TYPE SYNTAX PeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information about a particular peer." INDEX { peerAddressType, peerAddress } ::= { peerTable 1 } PeerEntry ::= SEQUENCE { peerAddressType InetAddressType, peerAddress InetAddress, peerStatus INTEGER } peerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of Internet address by which the peer is reachable." ::= { peerEntry 1 } peerAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (1..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Internet address for the peer. The type of this address is determined by the value of the peerAddressType object. Note that implementations must limit themselves to a single entry in this table per reachable peer. The peerAddress may not be empty due to the SIZE restriction. If a row is created administratively by an SNMP operation and the address type value is dns(16), then the agent stores the DNS name internally. A DNS name Daniele, et al. Standards Track [Page 16] RFC 4001 Internet Network Address Conventions February 2005 lookup must be performed on the internally stored DNS name whenever it is being used to contact the peer. If a row is created by the managed entity itself and the address type value is dns(16), then the agent stores the IP address internally. A DNS reverse lookup must be performed on the internally stored IP address whenever the value is retrieved via SNMP." ::= { peerEntry 2 } The following compliance statement specifies that compliant implementations need only support IPv4/IPv6 addresses without zone indices. Support for DNS names or IPv4/IPv6 addresses with zone indices is not required. peerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement of the peer MIB." MODULE -- this module MANDATORY-GROUPS { peerGroup } OBJECT peerAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and IPv6 addresses without zone indices." ::= { somewhere 2 } Note that the SMIv2 does not permit inclusion of objects that are not accessible in an object group (see section 3.1 in STD 58, RFC 2580 [RFC2580]). It is therefore not possible to refine the syntax of auxiliary objects that are not accessible. It is suggested that the refinement be expressed informally in the DESCRIPTION clause of the MODULE-COMPLIANCE macro invocation. 6. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects. Daniele, et al. Standards Track [Page 17] RFC 4001 Internet Network Address Conventions February 2005 Meaningful security considerations can only be written in the MIB modules that define management objects. This document has therefore no impact on the security of the Internet. 7. Acknowledgments This document was produced by the Operations and Management Area "IPv6MIB" design team. For their comments and suggestions, the authors would like to thank Fred Baker, Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Mike Heard, Tim Jenkins, Allison Mankin, Glenn Mansfield, Keith McCloghrie, Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill. 8. Changes from RFC 3291 to RFC 4001 The following changes have been made relative to RFC 3291: o Added a range restriction to the InetAddressPrefixLength textual convention. o Added new textual conventions InetZoneIndex, InetScopeType, and InetVersion. o Added explicit "d" DISPLAY-HINTs for textual conventions that did not have them. o Updated boilerplate text and references. 9. Changes from RFC 2851 to RFC 3291 The following changes have been made relative to RFC 2851: o Added new textual conventions InetAddressPrefixLength, InetPortNumber, and InetAutonomousSystemNumber. o Rewrote the introduction to say clearly that, in general, one should define MIB tables that work with all versions of IP. The other approach of multiple tables for different IP versions is strongly discouraged. o Added text to the InetAddressType and InetAddress descriptions requiring that implementations must reject set operations with an inconsistentValue error if they lead to inconsistencies. o Removed the strict ordering constraints. Description clauses now must explain which InetAddressType object provides the context for an InetAddress or InetAddressPrefixLength object. Daniele, et al. Standards Track [Page 18] RFC 4001 Internet Network Address Conventions February 2005 o Aligned wordings with the IPv6 scoping architecture document. o Split the InetAddressIPv6 textual convention into the two textual conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced a new textual convention InetAddressIPv4z. Added ipv4z(3) and ipv6z(4) named numbers to the InetAddressType enumeration. Motivations for this change: (i) to enable the introduction of a textual conventions for non-global IPv4 addresses, (ii) alignment with the textual conventions for transport addresses, (iii) simpler compliance statements in cases where support for IPv6 addresses with zone indices is not required, and (iv) to simplify implementations for host systems that will never have to report zone indices. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, February 2005. Daniele, et al. Standards Track [Page 19] RFC 4001 Internet Network Address Conventions February 2005 10.2. Informative References [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002. Daniele, et al. Standards Track [Page 20] RFC 4001 Internet Network Address Conventions February 2005 Authors' Addresses Michael Daniele SyAM Software, Inc. 1 Chestnut St, Suite 3-I Nashua, NH 03060 USA Phone: +1 603 598-9575 EMail: michael.daniele@syamsoftware.com Brian Haberman Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA Phone: +1-443-778-1319 EMail: brian@innovationslab.net Shawn A. Routhier Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501 USA Phone: +1 510 749-2095 EMail: shawn.routhier@windriver.com Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Daniele, et al. Standards Track [Page 21] RFC 4001 Internet Network Address Conventions February 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Daniele, et al. Standards Track [Page 22] snmp-mibs-downloader-1.1/mibrfcs/rfc4008.txt0000644000000000000000000036540011402176071015565 0ustar Network Working Group R. Rohit Request for Comments: 4008 Mascon Global Limited Category: Standards Track P. Srisuresh Caymas Systems, Inc. R. Raghunarayan N. Pai Cisco Systems, Inc. C. Wang Bank One Corp March 2005 Definitions of Managed Objects for Network Address Translators (NAT) 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. Rohit, et al. Standards Track [Page 1] RFC 4008 NAT MIB March 2005 Table of Contents 1. Introduction ................................................. 2 2. The Internet-Standard Management Framework ................... 2 3. Terminology .................................................. 3 4. Overview ..................................................... 4 4.1. natInterfaceTable....................................... 4 4.2. natAddrMapTable......................................... 5 4.3. Default Timeouts, Protocol Table, and Other Scalars..... 6 4.4. natAddrBindTable and natAddrPortBindTable............... 6 4.5. natSessionTable......................................... 6 4.6. RFC 3489 NAPT Variations, NAT Session and Bind Tables... 7 4.7. Notifications........................................... 7 4.8. Relation Among Tables................................... 8 4.9. Configuration via the MIB............................... 8 4.10. Relationship to Interface MIB........................... 9 5. Definitions .................................................. 9 6. Acknowledgements ............................................. 59 7. Security Considerations ...................................... 59 8. References ................................................... 60 Authors' Addresses ............................................... 62 Full Copyright Statement.......................................... 64 1. Introduction This memo defines a portion of the Management Information Base (MIB) for devices implementing NAT function. This MIB module may be used for configuration and monitoring of a device capable of NAT function. NAT types and their characteristics are defined in[RFC2663]. Traditional NAT function, in particular is defined in [RFC3022]. This MIB does not address the firewall functions and must not be used for configuring or monitoring these. Section 2 provides references to the SNMP management framework, which was used as the basis for the MIB module definition. Section 3 describes the terms used throughout the document. Section 4 provides an overview of the key objects, their inter-relationship, and how the MIB module may be used to configure and monitor a NAT device. Lastly, section 5 has the complete NAT MIB definition. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Rohit, et al. Standards Track [Page 2] RFC 4008 NAT MIB March 2005 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Terminology Definitions for a majority of the terms used throughout the document may be found in RFC 2663 [RFC2663]. Additional terms that further classify NAPT implementations are defined in RFC 3489 [RFC3489]. Listed below are terms used in this document. Address realm - An address realm is a realm of unique network addresses that are routable within the realm. For example, an enterprise address realm could be constituted of private IP addresses in the ranges specified in RFC 1918 [RFC1918], which are routable within the enterprise, but not across the Internet. A public realm is constituted of globally unique network addresses. Symmetric NAT - Symmetric NAT, as defined in RFC 3489 [RFC3489], is a variation of Network Address Port Translator (NAPT). Symmetric NAT does not use port bind for translation across all sessions originating from the same private host. Instead, it assigns a new public port to each new session, irrespective of whether the new session used the same private end-point as before. Bind or Binding - Several variations of the term 'Bind' (or 'Binding') are used throughout the document. Address Bind (or Address Binding) is a tuple of (Private IP address, Public IP Address) used for translating an IP address end-point in IP packets. Port Bind (or, Port Binding, or Address Port Bind, or Address Port Binding) is a tuple of (transport protocol, Private IP address, Private port, Public IP Address, Public port) used for translating a port end-point tuple of (transport protocol, IP address, port). Bind is used to refer to either Address Bind or Port Bind. Bind Mode identifies whether a bind is Address Bind or Port Bind. NAT Session - A NAT session is an association between a session as seen in the private realm and a session as seen in the public realm, by virtue of NAT translation. If a session in the private realm were to be represented as (PrivateSrcAddr, PrivateDstAddr, TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same session in the public realm were to be represented as (PublicSrcAddr, Rohit, et al. Standards Track [Page 3] RFC 4008 NAT MIB March 2005 PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the NAT session will provide the translation glue between the two session representations. NAT sessions in the document are restricted to sessions based on TCP and UDP only. In the future, NAT sessions may be extended to be based on other transport protocols such as SCTP, UDP-lite and DCCP. The terms 'local' and 'private' are used interchangeably throughout the document when referring to private networks, IP addresses, and ports. Likewise, the terms 'global' and 'public' are used interchangeably when referring to public networks, IP addresses, and ports. 4. Overview NAT MIB is configurable on a per-interface basis and depends in several parts on the IF-MIB [RFC2863]. NAT MIB requires that an interface for which NAT is configured be connected to either a private or a public realm. The realm association of the interface plays an important role in the definition of address maps for the interface. An address map entry identifies the orientation of the session (inbound or outbound to the interface) for which the entry may be used for NAT translation. The address map entry also identifies the end-point of the session that must be subject to translation. An SNMP Textual-Convention 'NatTranslationEntity' is defined to capture this important characteristic that combines session orientation and applicable session endpoint for translation. An address map may consist of static or dynamic entries. NAT creates static binds from a static address map entry. Each static bind has a direct one-to-one relationship with a static address map entry. NAT creates dynamic binds from a dynamic address map entry upon seeing the first packet of a new session. The following subsections define the key objects used in NAT MIB, their inter-relationship, and how to configure a NAT device using the MIB module. 4.1. natInterfaceTable natInterfaceTable is defined in the MIB module to configure interface specific realm type and the NAT services enabled for the interface. natInterfaceTable is indexed by ifIndex and also includes interface specific NAT statistics. Rohit, et al. Standards Track [Page 4] RFC 4008 NAT MIB March 2005 The first step for an operator in configuring a NAT device is determining the interface over which NAT service is to be configured. When NAT service is operational, translated packets traverse the NAT device by ingressing on a private interface and egressing on a public interface or vice versa. An operator may configure the NAT service on either the public interface or the private interface in the traversal path. As the next step, the operator must identify the NAT service(s) desired for the interface. The operator may configure one or more NAT services on the same interface. The MIB module identifies four types of NAT services: Basic NAT, NAPT, twice NAT and bidirectional NAT. These are NAT varieties as defined in RFC 2663 [RFC2663]. Note that RFC 3489 [RFC3489] further classifies NAPT implementations based on the behavior exhibited by the NAPT devices from different vendors. However, the MIB module does not explicitly distinguish between the NAPT implementations. NAPT implementations may be distinguished between one another by monitoring the BIND and NAT Session objects generated by the NAT device as described in section 4.6. 4.2. natAddrMapTable natAddrMapTable is defined in the MIB module to configure address maps on a per-interface basis. natAddrMapTable is indexed by the tuple of (ifIndex, natAddrMapIndex). The same table is also used to collect Statistics for the address map entries. Address maps are key to NAT configuration. An operator may configure one or more address map entries per interface. NAT looks up address map entries in the order in which they are defined to determine the translation function at the start of each new session traversing the interface. An address map may consist of static or dynamic entries. A static address map entry has a direct one-to-one relationship with binds. NAT will dynamically create binds from a dynamic address map entry. The operator must be careful in selecting address map entries for an interface based on the interface realm-type and the type of NAT service desired. The operator can be amiss in the selection of address map entries when not paying attention to the associated interface characteristics defined in natInterfaceTable (described in section 4.1). For example, say the operator wishes to configure a NAPT map entry on an interface of a NAT device. If the operator chooses to configure the NAPT map entry on a public interface (i.e., interface realm-type is public), the operator should set the TranslationEntity of the NAPT address map entry to be outboundSrcEndPoint. On the other hand, if the operator chooses to configure the NAPT map entry on a private interface (i.e., interface realm-type is private), the operator should set the TranslationEntity of the NAPT address map entry to be InboundSrcEndPoint. Rohit, et al. Standards Track [Page 5] RFC 4008 NAT MIB March 2005 4.3. Default Timeouts, Protocol Table, and Other Scalars DefTimeouts is defined in the MIB module to configure idle Bind timeout and IP protocol specific idle NAT session timeouts. The timeouts defined are global to the system and are not interface specific. Protocol specific statistics are maintained in natProtocolTable, which is indexed by the protocol type. The scalars natAddrBindNumberOfEntries and natAddrPortBindNumberOfEntries hold the number of entries that currently exist in the Address Bind and the Address Port Bind tables, respectively. The generation of natPacketDiscard notifications can be configured by using the natNotifThrottlingInterval scalar MIB object. 4.4. natAddrBindTable and natAddrPortBindTable Two Bind tables, natAddrBindTable and natAddrPortBindTable, are defined to hold the bind entries. Entries are derived from the address map table and are not configurable. natAddrBindTable contains Address Binds, and natAddrPortBindTable contains Address Port Binds. natAddrBindTable is indexed by the tuple of (ifIndex, LocalAddrType, LocalAddr). natAddrPortBindTable is indexed by the tuple of (ifIndex, LocalAddrType, LocalAddr, LocalPort, Protocol). These tables also maintain bind specific statistics. A Symmetric NAT will have no entries in the Bind tables. 4.5. natSessionTable natSessionTable is defined to hold NAT session entries. NAT session entries are derived from NAT Binds (except in the case of Symmetric NAT) and are not configurable. The NAT session provides the necessary translation glue between two session representations of the same end-to-end session; that is, a session as seen in the private realm and in the public realm. Session orientation (inbound or outbound) is determined from the orientation of the first packet traversing the NAT interface. Address map entries and bind entries on the interface determine whether a session is subject to NAT translation. One or both endpoints of a session may be subject to translation. With the exception of symmetric NAT, all other NAT functions use end-point specific bind to perform individual end-point translations. Multiple NAT sessions would use the same bind as long as they share Rohit, et al. Standards Track [Page 6] RFC 4008 NAT MIB March 2005 the same endpoint. Symmetric NAT does not retain a consistent port bind across multiple sessions using the same endpoint. For this reason, the bind identifier for a NAT session in symmetric NAT is set to zero. natSessionTable is indexed by the tuple of (ifIndex, natSessionIndex). Statistics for NAT sessions are also maintained in the same table. 4.6. RFC 3489 NAPT Variations, NAT Session and Bind Tables [RFC3489] defines four variations of NAPT - Full Cone, Restricted Cone, Port Restricted Cone, and Symmetric NAT. These can be differentiated in the NAT MIB based on different values for the objects in the session and the bind tables, as indicated below. In a Port Restricted Cone NAT, NAT Session objects will contain a non-zero PrivateSrcEPBindId object. Further, all address and port objects within a NAT session will have non-zero values (i.e., no wildcard matches). An Address Restricted Cone NAT may have been implemented in the same way as a Port Restricted Cone NAT, except that the UDP NAT Sessions may use ANY match on PrivateDstPort and PublicDstPort objects; i.e., PrivateDstPort and PublicDstPort objects within a NAT session may be set to zero. A Full Cone NAT may have also been implemented in the same way as a Port Restricted Cone NAT, except that the UDP NAT Sessions may use ANY match on PrivateDstAddr, PrivateDstPort, PublicDstAddr, and PublicDstPort objects. Within a NAT Session, all four of these objects may be set to zero. Alternately, all address and port objects within a NAT Session may have non-zero values, yet the TranslationEntity of the PrivateSrcEPBindId for the NAT Sessions may be set bi-directionally, i.e., as a bit mask of (outboundSrcEndPoint and inboundDstEndPoint) or (inboundSrcEndPoint and outboundDstEndPoint), depending on the interface realm type. Lastly, a Symmetric NAT does not maintain Port Bindings. As such, the NAT Session objects will have the PrivateSrcEPBindId set to zero. 4.7. Notifications natPacketDiscard notifies the end user/manager of packets being discarded due to lack of address mappings. Rohit, et al. Standards Track [Page 7] RFC 4008 NAT MIB March 2005 4.8. Relation Among Tables The association between the various NAT tables can be represented as follows: Interface | | | Address map | | | ---------------------------------------------- | | | | | | Address Bind Port Bind | | | | | | ---------------------------------------------- | | | NAT Session All NAT functions, with the exception of Symmetric NAT, use Bind(s) to provide the glue necessary for a NAT Session. natSessionPrivateSrcEPBindId and natSessionPrivateDstEPBindId objects represent the endpoint Binds used by NAT Sessions. 4.9. Configuration via the MIB Sections 4.1 and 4.2 and part of section 4.3 refer to objects that are configurable on a NAT device. NAT derives Address Bind and Address Port Bind entries from the Address Map table. Hence, an Address Bind or an Address Port Bind entry must not exist without an associated entry in the Address Map table. Further, NAT derives NAT session entries from NAT Binds, except in the case of symmetric NAT, which derives translation parameters for a NAT session directly from an address map entry. Hence, with the exception of Symmetric NAT, a NAT session entry must not exist in the NAT Session table without a corresponding bind. Rohit, et al. Standards Track [Page 8] RFC 4008 NAT MIB March 2005 A Management station may use the following steps to configure entries in the NAT-MIB: - Create an entry in the natInterfaceTable specifying the value of ifIndex as the interface index of the interface on which NAT is being configured. Specify appropriate values, as applicable, for the other objects (e.g., natInterfaceRealm, natInterfaceServiceType) in the table (refer to Section 4.1). - Create one or more address map entries sequentially in reduced order of priority in the natAddrMapTable, specifying the value of ifIndex to be the same for all entries. The ifIndex specified would be the same as that specified for natInterfaceTable (refer to Section 4.2). - Configure the maximum permitted idle time duration for BINDs and TCP, UDP, and ICMP protocol sessions by setting the relevant scalars in natDefTimeouts object (refer to Section 4.3). 4.10. Relationship to Interface MIB The natInterfaceTable specifies the NAT configuration attributes on each interface. The concept of "interface" is as defined by InterfaceIndex/ifIndex of the IETF Interfaces MIB [RFC2863]. 5. Definitions This MIB module IMPORTs objects from RFCs 2578 [RFC2578], 2579 [RFC2579], 2580 [RFC2580], 2863 [RFC2863], 3411 [RFC3411], and 4001 [RFC4001]. It also refers to information in RFCs 792 [RFC792], 2463 [RFC2463], and 3413 [RFC3413]. NAT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Gauge32, Counter64, TimeTicks, mib-2, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, StorageType, RowStatus Rohit, et al. Standards Track [Page 9] RFC 4008 NAT MIB March 2005 FROM SNMPv2-TC MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, ifCounterDiscontinuityGroup FROM IF-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB; natMIB MODULE-IDENTITY LAST-UPDATED "200503210000Z" ORGANIZATION "IETF Transport Area" CONTACT-INFO " Rohit Mascon Global Limited #59/2 100 ft Ring Road Banashankari II Stage Bangalore 560 070 India Phone: +91 80 2679 6227 Email: rrohit74@hotmail.com P. Srisuresh Caymas Systems, Inc. 1179-A North McDowell Blvd. Petaluma, CA 94954 Tel: (707) 283-5063 Email: srisuresh@yahoo.com Rajiv Raghunarayan Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408 853 9612 Email: raraghun@cisco.com Nalinaksh Pai Cisco Systems, Inc. Prestige Waterford No. 9, Brunton Road Bangalore - 560 025 Rohit, et al. Standards Track [Page 10] RFC 4008 NAT MIB March 2005 India Phone: +91 80 532 1300 Email: npai@cisco.com Cliff Wang Information Security Bank One Corp 1111 Polaris Pkwy Columbus, OH 43240 Phone: +1 614 213 6117 Email: cliffwang2000@yahoo.com " DESCRIPTION "This MIB module defines the generic managed objects for NAT. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4008; see the RFC itself for full legal notices." REVISION "200503210000Z" -- 21th March 2005 DESCRIPTION "Initial version, published as RFC 4008." ::= { mib-2 123 } natMIBObjects OBJECT IDENTIFIER ::= { natMIB 1 } NatProtocolType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of protocols that support the network address translation. Inclusion of the values is not intended to imply that those protocols need to be supported. Any change in this TEXTUAL-CONVENTION should also be reflected in the definition of NatProtocolMap, which is a BITS representation of this." SYNTAX INTEGER { none (1), -- not specified other (2), -- none of the following icmp (3), udp (4), tcp (5) } NatProtocolMap ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A bitmap of protocol identifiers that support Rohit, et al. Standards Track [Page 11] RFC 4008 NAT MIB March 2005 the network address translation. Any change in this TEXTUAL-CONVENTION should also be reflected in the definition of NatProtocolType." SYNTAX BITS { other (0), icmp (1), udp (2), tcp (3) } NatAddrMapId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique id that is assigned to each address map by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatBindIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique id that is assigned to each bind by a NAT enabled device. The bind id will be zero in the case of a Symmetric NAT." SYNTAX Unsigned32 (0..4294967295) NatBindId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique id that is assigned to each bind by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatSessionId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique id that is assigned to each session by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatBindMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An indication of whether the bind is an address bind or an address port bind." Rohit, et al. Standards Track [Page 12] RFC 4008 NAT MIB March 2005 SYNTAX INTEGER { addressBind (1), addressPortBind (2) } NatAssociationType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An indication of whether the association is static or dynamic." SYNTAX INTEGER { static (1), dynamic (2) } NatTranslationEntity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An indication of a) the direction of a session for which an address map entry, address bind or port bind is applicable, and b) the entity (source or destination) within the session that is subject to translation." SYNTAX BITS { inboundSrcEndPoint (0), outboundDstEndPoint(1), inboundDstEndPoint (2), outboundSrcEndPoint(3) } -- -- Default Values for the Bind and NAT Protocol Timers -- natDefTimeouts OBJECT IDENTIFIER ::= { natMIBObjects 1 } natNotifCtrl OBJECT IDENTIFIER ::= { natMIBObjects 2 } -- -- Address Bind and Port Bind related NAT configuration -- natBindDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 13] RFC 4008 NAT MIB March 2005 "The default Bind (Address Bind or Port Bind) idle timeout parameter. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 0 } ::= { natDefTimeouts 1 } -- -- UDP related NAT configuration -- natUdpDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default UDP idle timeout parameter. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 300 } ::= { natDefTimeouts 2 } -- -- ICMP related NAT configuration -- natIcmpDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default ICMP idle timeout parameter. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 300 } ::= { natDefTimeouts 3 } Rohit, et al. Standards Track [Page 14] RFC 4008 NAT MIB March 2005 -- -- Other protocol parameters -- natOtherDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default idle timeout parameter for protocols represented by the value other (2) in NatProtocolType. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 60 } ::= { natDefTimeouts 4 } -- -- TCP related NAT Timers -- natTcpDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default time interval that a NAT session for an established TCP connection is allowed to remain valid without any activity on the TCP connection. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 86400 } ::= { natDefTimeouts 5 } natTcpDefNegTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 15] RFC 4008 NAT MIB March 2005 "The default time interval that a NAT session for a TCP connection that is not in the established state is allowed to remain valid without any activity on the TCP connection. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 60 } ::= { natDefTimeouts 6 } natNotifThrottlingInterval OBJECT-TYPE SYNTAX Integer32 (0 | 5..3600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the generation of the natPacketDiscard notification. If this object has a value of zero, then no natPacketDiscard notifications will be transmitted by the agent. If this object has a non-zero value, then the agent must not generate more than one natPacketDiscard 'notification-event' in the indicated period, where a 'notification-event' is the generation of a single notification PDU type to a list of notification destinations. If additional NAT packets are discarded within the throttling period, then notification-events for these changes must be suppressed by the agent until the current throttling period expires. If natNotifThrottlingInterval notification generation is enabled, the suggested default throttling period is 60 seconds, but generation of the natPacketDiscard notification should be disabled by default. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system. The actual transmission of notifications is controlled via the MIB modules in RFC 3413." DEFVAL { 0 } Rohit, et al. Standards Track [Page 16] RFC 4008 NAT MIB March 2005 ::= { natNotifCtrl 1 } -- -- The NAT Interface Table -- natInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF NatInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the attributes for interfaces on a device supporting NAT function." ::= { natMIBObjects 3 } natInterfaceEntry OBJECT-TYPE SYNTAX NatInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in the natInterfaceTable holds a set of parameters for an interface, instantiated by ifIndex. Therefore, the interface index must have been assigned, according to the applicable procedures, before it can be meaningfully used. Generally, this means that the interface must exist. When natStorageType is of type nonVolatile, however, this may reflect the configuration for an interface whose ifIndex has been assigned but for which the supporting implementation is not currently present." INDEX { ifIndex } ::= { natInterfaceTable 1 } NatInterfaceEntry ::= SEQUENCE { natInterfaceRealm INTEGER, natInterfaceServiceType BITS, natInterfaceInTranslates Counter64, natInterfaceOutTranslates Counter64, natInterfaceDiscards Counter64, natInterfaceStorageType StorageType, natInterfaceRowStatus RowStatus } natInterfaceRealm OBJECT-TYPE SYNTAX INTEGER { private (1), public (2) Rohit, et al. Standards Track [Page 17] RFC 4008 NAT MIB March 2005 } MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies whether this interface is connected to the private or the public realm." DEFVAL { public } ::= { natInterfaceEntry 1 } natInterfaceServiceType OBJECT-TYPE SYNTAX BITS { basicNat (0), napt (1), bidirectionalNat (2), twiceNat (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of the direction in which new sessions are permitted and the extent of translation done within the IP and transport headers." ::= { natInterfaceEntry 2 } natInterfaceInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets received on this interface that were translated. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natInterfaceEntry 3 } natInterfaceOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of translated packets that were sent out this interface. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of Rohit, et al. Standards Track [Page 18] RFC 4008 NAT MIB March 2005 ifCounterDiscontinuityTime on the relevant interface." ::= { natInterfaceEntry 4 } natInterfaceDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets that had to be rejected/dropped due to a lack of resources for this interface. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natInterfaceEntry 5 } natInterfaceStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." REFERENCE "Textual Conventions for SMIv2, Section 2." DEFVAL { nonVolatile } ::= { natInterfaceEntry 6 } natInterfaceRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the natInterfaceRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding instance of natInterfaceServiceType has been set. Rohit, et al. Standards Track [Page 19] RFC 4008 NAT MIB March 2005 None of the objects in this row may be modified while the value of this object is active(1)." REFERENCE "Textual Conventions for SMIv2, Section 2." ::= { natInterfaceEntry 7 } -- -- The Address Map Table -- natAddrMapTable OBJECT-TYPE SYNTAX SEQUENCE OF NatAddrMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists address map parameters for NAT." ::= { natMIBObjects 4 } natAddrMapEntry OBJECT-TYPE SYNTAX NatAddrMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry represents an address map to be used for NAT and contributes to the dynamic and/or static address mapping tables of the NAT device." INDEX { ifIndex, natAddrMapIndex } ::= { natAddrMapTable 1 } NatAddrMapEntry ::= SEQUENCE { natAddrMapIndex NatAddrMapId, natAddrMapName SnmpAdminString, natAddrMapEntryType NatAssociationType, natAddrMapTranslationEntity NatTranslationEntity, natAddrMapLocalAddrType InetAddressType, natAddrMapLocalAddrFrom InetAddress, natAddrMapLocalAddrTo InetAddress, natAddrMapLocalPortFrom InetPortNumber, natAddrMapLocalPortTo InetPortNumber, natAddrMapGlobalAddrType InetAddressType, natAddrMapGlobalAddrFrom InetAddress, natAddrMapGlobalAddrTo InetAddress, natAddrMapGlobalPortFrom InetPortNumber, natAddrMapGlobalPortTo InetPortNumber, natAddrMapProtocol NatProtocolMap, natAddrMapInTranslates Counter64, natAddrMapOutTranslates Counter64, natAddrMapDiscards Counter64, Rohit, et al. Standards Track [Page 20] RFC 4008 NAT MIB March 2005 natAddrMapAddrUsed Gauge32, natAddrMapStorageType StorageType, natAddrMapRowStatus RowStatus } natAddrMapIndex OBJECT-TYPE SYNTAX NatAddrMapId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Along with ifIndex, this object uniquely identifies an entry in the natAddrMapTable. Address map entries are applied in the order specified by natAddrMapIndex." ::= { natAddrMapEntry 1 } natAddrMapName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "Name identifying all map entries in the table associated with the same interface. All map entries with the same ifIndex MUST have the same map name." ::= { natAddrMapEntry 2 } natAddrMapEntryType OBJECT-TYPE SYNTAX NatAssociationType MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter can be used to set up static or dynamic address maps." ::= { natAddrMapEntry 3 } natAddrMapTranslationEntity OBJECT-TYPE SYNTAX NatTranslationEntity MAX-ACCESS read-create STATUS current DESCRIPTION "The end-point entity (source or destination) in inbound or outbound sessions (i.e., first packets) that may be translated by an address map entry. Session direction (inbound or outbound) is derived from the direction of the first packet of a session traversing a NAT interface. NAT address (and Transport-ID) maps may be defined Rohit, et al. Standards Track [Page 21] RFC 4008 NAT MIB March 2005 to effect inbound or outbound sessions. Traditionally, address maps for Basic NAT and NAPT are configured on a public interface for outbound sessions, effecting translation of source end-point. The value of this object must be set to outboundSrcEndPoint for those interfaces. Alternately, if address maps for Basic NAT and NAPT were to be configured on a private interface, the desired value for this object for the map entries would be inboundSrcEndPoint (i.e., effecting translation of source end-point for inbound sessions). If TwiceNAT were to be configured on a private interface, the desired value for this object for the map entries would be a bitmask of inboundSrcEndPoint and inboundDstEndPoint." ::= { natAddrMapEntry 4 } natAddrMapLocalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the address type used for natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo." ::= { natAddrMapEntry 5 } natAddrMapLocalAddrFrom OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the first IP address of the range of IP addresses mapped by this translation entry. The value of this object must be less than or equal to the value of the natAddrMapLocalAddrTo object. The type of this address is determined by the value of the natAddrMapLocalAddrType object." ::= { natAddrMapEntry 6 } natAddrMapLocalAddrTo OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 22] RFC 4008 NAT MIB March 2005 "This object specifies the last IP address of the range of IP addresses mapped by this translation entry. If only a single address is being mapped, the value of this object is equal to the value of natAddrMapLocalAddrFrom. For a static NAT, the number of addresses in the range defined by natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo must be equal to the number of addresses in the range defined by natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo. The value of this object must be greater than or equal to the value of the natAddrMapLocalAddrFrom object. The type of this address is determined by the value of the natAddrMapLocalAddrType object." ::= { natAddrMapEntry 7 } natAddrMapLocalPortFrom OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of this object specifies the first port number in the range of ports being mapped. The value of this object must be less than or equal to the value of the natAddrMapLocalPortTo object. If the translation specifies a single port, then the value of this object is equal to the value of natAddrMapLocalPortTo." DEFVAL { 0 } ::= { natAddrMapEntry 8 } natAddrMapLocalPortTo OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of this object specifies the last port number in the range of ports being mapped. The value of this object must be greater than or equal to the value of the natAddrMapLocalPortFrom object. If the translation specifies a single port, then the value of this object is equal to the value of natAddrMapLocalPortFrom." Rohit, et al. Standards Track [Page 23] RFC 4008 NAT MIB March 2005 DEFVAL { 0 } ::= { natAddrMapEntry 9 } natAddrMapGlobalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the address type used for natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo." ::= { natAddrMapEntry 10 } natAddrMapGlobalAddrFrom OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the first IP address of the range of IP addresses being mapped to. The value of this object must be less than or equal to the value of the natAddrMapGlobalAddrTo object. The type of this address is determined by the value of the natAddrMapGlobalAddrType object." ::= { natAddrMapEntry 11 } natAddrMapGlobalAddrTo OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the last IP address of the range of IP addresses being mapped to. If only a single address is being mapped to, the value of this object is equal to the value of natAddrMapGlobalAddrFrom. For a static NAT, the number of addresses in the range defined by natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo must be equal to the number of addresses in the range defined by natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo. The value of this object must be greater than or equal to the value of the natAddrMapGlobalAddrFrom object. The type of this address is determined by the value of the natAddrMapGlobalAddrType object." ::= { natAddrMapEntry 12 } natAddrMapGlobalPortFrom OBJECT-TYPE SYNTAX InetPortNumber Rohit, et al. Standards Track [Page 24] RFC 4008 NAT MIB March 2005 MAX-ACCESS read-create STATUS current DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of this object specifies the first port number in the range of ports being mapped to. The value of this object must be less than or equal to the value of the natAddrMapGlobalPortTo object. If the translation specifies a single port, then the value of this object is equal to the value natAddrMapGlobalPortTo." DEFVAL { 0 } ::= { natAddrMapEntry 13 } natAddrMapGlobalPortTo OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of this object specifies the last port number in the range of ports being mapped to. The value of this object must be greater than or equal to the value of the natAddrMapGlobalPortFrom object. If the translation specifies a single port, then the value of this object is equal to the value of natAddrMapGlobalPortFrom." DEFVAL { 0 } ::= { natAddrMapEntry 14 } natAddrMapProtocol OBJECT-TYPE SYNTAX NatProtocolMap MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a bitmap of protocol identifiers." ::= { natAddrMapEntry 15 } natAddrMapInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 25] RFC 4008 NAT MIB March 2005 "The number of inbound packets pertaining to this address map entry that were translated. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrMapEntry 16 } natAddrMapOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets pertaining to this address map entry that were translated. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrMapEntry 17 } natAddrMapDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets pertaining to this address map entry that were dropped due to lack of addresses in the address pool identified by this address map. The value of this object must always be zero in case of static address map. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrMapEntry 18 } natAddrMapAddrUsed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses pertaining to this address map that are currently being used from the NAT pool. The value of this object must always be zero in the case Rohit, et al. Standards Track [Page 26] RFC 4008 NAT MIB March 2005 of a static address map." ::= { natAddrMapEntry 19 } natAddrMapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." REFERENCE "Textual Conventions for SMIv2, Section 2." DEFVAL { nonVolatile } ::= { natAddrMapEntry 20 } natAddrMapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the natAddrMapRowStatus column is 'notReady'. None of the objects in this row may be modified while the value of this object is active(1)." REFERENCE "Textual Conventions for SMIv2, Section 2." ::= { natAddrMapEntry 21 } -- -- Address Bind section -- natAddrBindNumberOfEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object maintains a count of the number of entries that currently exist in the natAddrBindTable." ::= { natMIBObjects 5 } Rohit, et al. Standards Track [Page 27] RFC 4008 NAT MIB March 2005 -- -- The NAT Address BIND Table -- natAddrBindTable OBJECT-TYPE SYNTAX SEQUENCE OF NatAddrBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table holds information about the currently active NAT BINDs." ::= { natMIBObjects 6 } natAddrBindEntry OBJECT-TYPE SYNTAX NatAddrBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table holds information about an active address BIND. These entries are lost upon agent restart. This row has indexing which may create variables with more than 128 subidentifiers. Implementers of this table must be careful not to create entries that would result in OIDs which exceed the 128 subidentifier limit. Otherwise, the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." INDEX { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr } ::= { natAddrBindTable 1 } NatAddrBindEntry ::= SEQUENCE { natAddrBindLocalAddrType InetAddressType, natAddrBindLocalAddr InetAddress, natAddrBindGlobalAddrType InetAddressType, natAddrBindGlobalAddr InetAddress, natAddrBindId NatBindId, natAddrBindTranslationEntity NatTranslationEntity, natAddrBindType NatAssociationType, natAddrBindMapIndex NatAddrMapId, natAddrBindSessions Gauge32, natAddrBindMaxIdleTime TimeTicks, natAddrBindCurrentIdleTime TimeTicks, natAddrBindInTranslates Counter64, natAddrBindOutTranslates Counter64 } Rohit, et al. Standards Track [Page 28] RFC 4008 NAT MIB March 2005 natAddrBindLocalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the address type used for natAddrBindLocalAddr." ::= { natAddrBindEntry 1 } natAddrBindLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the private-realm specific network layer address, which maps to the public-realm address represented by natAddrBindGlobalAddr. The type of this address is determined by the value of the natAddrBindLocalAddrType object." ::= { natAddrBindEntry 2 } natAddrBindGlobalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the address type used for natAddrBindGlobalAddr." ::= { natAddrBindEntry 3 } natAddrBindGlobalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the public-realm network layer address that maps to the private-realm network layer address represented by natAddrBindLocalAddr. The type of this address is determined by the value of the natAddrBindGlobalAddrType object." ::= { natAddrBindEntry 4 } natAddrBindId OBJECT-TYPE SYNTAX NatBindId MAX-ACCESS read-only STATUS current Rohit, et al. Standards Track [Page 29] RFC 4008 NAT MIB March 2005 DESCRIPTION "This object represents a bind id that is dynamically assigned to each bind by a NAT enabled device. Each bind is represented by a bind id that is unique across both, the natAddrBindTable and the natAddrPortBindTable." ::= { natAddrBindEntry 5 } natAddrBindTranslationEntity OBJECT-TYPE SYNTAX NatTranslationEntity MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the direction of sessions for which this bind is applicable and the endpoint entity (source or destination) within the sessions that is subject to translation using the BIND. Orientation of the bind can be a superset of translationEntity of the address map entry which forms the basis for this bind. For example, if the translationEntity of an address map entry is outboundSrcEndPoint, the translationEntity of a bind derived from this map entry may either be outboundSrcEndPoint or it may be bidirectional (a bitmask of outboundSrcEndPoint and inboundDstEndPoint)." ::= { natAddrBindEntry 6 } natAddrBindType OBJECT-TYPE SYNTAX NatAssociationType MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the bind is static or dynamic." ::= { natAddrBindEntry 7 } natAddrBindMapIndex OBJECT-TYPE SYNTAX NatAddrMapId MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a pointer to the natAddrMapTable entry (and the parameters of that entry) which was used in creating this BIND. This object, in conjunction with the ifIndex (which identifies a unique addrMapName) points to Rohit, et al. Standards Track [Page 30] RFC 4008 NAT MIB March 2005 a unique entry in the natAddrMapTable." ::= { natAddrBindEntry 8 } natAddrBindSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of sessions currently using this BIND." ::= { natAddrBindEntry 9 } natAddrBindMaxIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum time for which this bind can be idle with no sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrBindEntry 10 } natAddrBindCurrentIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "At any given instance, this object indicates the time that this bind has been idle without any sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrBindEntry 11 } natAddrBindInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound packets that were successfully translated by using this bind entry. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of Rohit, et al. Standards Track [Page 31] RFC 4008 NAT MIB March 2005 ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrBindEntry 12 } natAddrBindOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets that were successfully translated using this bind entry. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrBindEntry 13 } -- -- Address Port Bind section -- natAddrPortBindNumberOfEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object maintains a count of the number of entries that currently exist in the natAddrPortBindTable." ::= { natMIBObjects 7 } -- -- The NAT Address Port Bind Table -- natAddrPortBindTable OBJECT-TYPE SYNTAX SEQUENCE OF NatAddrPortBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table holds information about the currently active NAPT BINDs." ::= { natMIBObjects 8 } natAddrPortBindEntry OBJECT-TYPE SYNTAX NatAddrPortBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 32] RFC 4008 NAT MIB March 2005 "Each entry in the this table holds information about a NAPT bind that is currently active. These entries are lost upon agent restart. This row has indexing which may create variables with more than 128 subidentifiers. Implementers of this table must be careful not to create entries which would result in OIDs that exceed the 128 subidentifier limit. Otherwise, the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." INDEX { ifIndex, natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr, natAddrPortBindLocalPort, natAddrPortBindProtocol } ::= { natAddrPortBindTable 1 } NatAddrPortBindEntry ::= SEQUENCE { natAddrPortBindLocalAddrType InetAddressType, natAddrPortBindLocalAddr InetAddress, natAddrPortBindLocalPort InetPortNumber, natAddrPortBindProtocol NatProtocolType, natAddrPortBindGlobalAddrType InetAddressType, natAddrPortBindGlobalAddr InetAddress, natAddrPortBindGlobalPort InetPortNumber, natAddrPortBindId NatBindId, natAddrPortBindTranslationEntity NatTranslationEntity, natAddrPortBindType NatAssociationType, natAddrPortBindMapIndex NatAddrMapId, natAddrPortBindSessions Gauge32, natAddrPortBindMaxIdleTime TimeTicks, natAddrPortBindCurrentIdleTime TimeTicks, natAddrPortBindInTranslates Counter64, natAddrPortBindOutTranslates Counter64 } natAddrPortBindLocalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the address type used for natAddrPortBindLocalAddr." ::= { natAddrPortBindEntry 1 } natAddrPortBindLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 33] RFC 4008 NAT MIB March 2005 "This object represents the private-realm specific network layer address which, in conjunction with natAddrPortBindLocalPort, maps to the public-realm network layer address and transport id represented by natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort respectively. The type of this address is determined by the value of the natAddrPortBindLocalAddrType object." ::= { natAddrPortBindEntry 2 } natAddrPortBindLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "For a protocol value TCP or UDP, this object represents the private-realm specific port number. On the other hand, for ICMP a bind is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the private-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. This object, together with natAddrPortBindProtocol, natAddrPortBindLocalAddrType, and natAddrPortBindLocalAddr, constitutes a session endpoint in the private realm. A bind entry binds a private realm specific endpoint to a public realm specific endpoint, as represented by the tuple of (natAddrPortBindGlobalPort, natAddrPortBindProtocol, natAddrPortBindGlobalAddrType, and natAddrPortBindGlobalAddr)." ::= { natAddrPortBindEntry 3 } natAddrPortBindProtocol OBJECT-TYPE SYNTAX NatProtocolType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies a protocol identifier. If the value of this object is none(1), then this bind entry applies to all IP traffic. Any other value of this object specifies the class of IP traffic to which this BIND applies." ::= { natAddrPortBindEntry 4 } Rohit, et al. Standards Track [Page 34] RFC 4008 NAT MIB March 2005 natAddrPortBindGlobalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the address type used for natAddrPortBindGlobalAddr." ::= { natAddrPortBindEntry 5 } natAddrPortBindGlobalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the public-realm specific network layer address that, in conjunction with natAddrPortBindGlobalPort, maps to the private-realm network layer address and transport id represented by natAddrPortBindLocalAddr and natAddrPortBindLocalPort, respectively. The type of this address is determined by the value of the natAddrPortBindGlobalAddrType object." ::= { natAddrPortBindEntry 6 } natAddrPortBindGlobalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "For a protocol value TCP or UDP, this object represents the public-realm specific port number. On the other hand, for ICMP a bind is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the public-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. This object, together with natAddrPortBindProtocol, natAddrPortBindGlobalAddrType, and natAddrPortBindGlobalAddr, constitutes a session endpoint in the public realm. A bind entry binds a public realm specific endpoint to a private realm specific endpoint, as represented by the tuple of (natAddrPortBindLocalPort, natAddrPortBindProtocol, natAddrPortBindLocalAddrType, and Rohit, et al. Standards Track [Page 35] RFC 4008 NAT MIB March 2005 natAddrPortBindLocalAddr)." ::= { natAddrPortBindEntry 7 } natAddrPortBindId OBJECT-TYPE SYNTAX NatBindId MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents a bind id that is dynamically assigned to each bind by a NAT enabled device. Each bind is represented by a unique bind id across both the natAddrBindTable and the natAddrPortBindTable." ::= { natAddrPortBindEntry 8 } natAddrPortBindTranslationEntity OBJECT-TYPE SYNTAX NatTranslationEntity MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the direction of sessions for which this bind is applicable and the entity (source or destination) within the sessions that is subject to translation with the BIND. Orientation of the bind can be a superset of the translationEntity of the address map entry that forms the basis for this bind. For example, if the translationEntity of an address map entry is outboundSrcEndPoint, the translationEntity of a bind derived from this map entry may either be outboundSrcEndPoint or may be bidirectional (a bitmask of outboundSrcEndPoint and inboundDstEndPoint)." ::= { natAddrPortBindEntry 9 } natAddrPortBindType OBJECT-TYPE SYNTAX NatAssociationType MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the bind is static or dynamic." ::= { natAddrPortBindEntry 10 } natAddrPortBindMapIndex OBJECT-TYPE SYNTAX NatAddrMapId MAX-ACCESS read-only Rohit, et al. Standards Track [Page 36] RFC 4008 NAT MIB March 2005 STATUS current DESCRIPTION "This object is a pointer to the natAddrMapTable entry (and the parameters of that entry) used in creating this BIND. This object, in conjunction with the ifIndex (which identifies a unique addrMapName), points to a unique entry in the natAddrMapTable." ::= { natAddrPortBindEntry 11 } natAddrPortBindSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of sessions currently using this BIND." ::= { natAddrPortBindEntry 12 } natAddrPortBindMaxIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum time for which this bind can be idle without any sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrPortBindEntry 13 } natAddrPortBindCurrentIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "At any given instance, this object indicates the time that this bind has been idle without any sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrPortBindEntry 14 } natAddrPortBindInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 37] RFC 4008 NAT MIB March 2005 "The number of inbound packets that were translated as per this bind entry. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrPortBindEntry 15 } natAddrPortBindOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets that were translated as per this bind entry. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrPortBindEntry 16 } -- -- The Session Table -- natSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF NatSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing one entry for each NAT session currently active on this NAT device." ::= { natMIBObjects 9 } natSessionEntry OBJECT-TYPE SYNTAX NatSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing information about an active NAT session on this NAT device. These entries are lost upon agent restart." INDEX { ifIndex, natSessionIndex } ::= { natSessionTable 1 } NatSessionEntry ::= SEQUENCE { Rohit, et al. Standards Track [Page 38] RFC 4008 NAT MIB March 2005 natSessionIndex NatSessionId, natSessionPrivateSrcEPBindId NatBindIdOrZero, natSessionPrivateSrcEPBindMode NatBindMode, natSessionPrivateDstEPBindId NatBindIdOrZero, natSessionPrivateDstEPBindMode NatBindMode, natSessionDirection INTEGER, natSessionUpTime TimeTicks, natSessionAddrMapIndex NatAddrMapId, natSessionProtocolType NatProtocolType, natSessionPrivateAddrType InetAddressType, natSessionPrivateSrcAddr InetAddress, natSessionPrivateSrcPort InetPortNumber, natSessionPrivateDstAddr InetAddress, natSessionPrivateDstPort InetPortNumber, natSessionPublicAddrType InetAddressType, natSessionPublicSrcAddr InetAddress, natSessionPublicSrcPort InetPortNumber, natSessionPublicDstAddr InetAddress, natSessionPublicDstPort InetPortNumber, natSessionMaxIdleTime TimeTicks, natSessionCurrentIdleTime TimeTicks, natSessionInTranslates Counter64, natSessionOutTranslates Counter64 } natSessionIndex OBJECT-TYPE SYNTAX NatSessionId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The session ID for this NAT session." ::= { natSessionEntry 1 } natSessionPrivateSrcEPBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The bind id associated between private and public source end points. In the case of Symmetric-NAT, this should be set to zero." ::= { natSessionEntry 2 } natSessionPrivateSrcEPBindMode OBJECT-TYPE SYNTAX NatBindMode MAX-ACCESS read-only STATUS current DESCRIPTION Rohit, et al. Standards Track [Page 39] RFC 4008 NAT MIB March 2005 "This object indicates whether the bind indicated by the object natSessionPrivateSrcEPBindId is an address bind or an address port bind." ::= { natSessionEntry 3 } natSessionPrivateDstEPBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The bind id associated between private and public destination end points." ::= { natSessionEntry 4 } natSessionPrivateDstEPBindMode OBJECT-TYPE SYNTAX NatBindMode MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the bind indicated by the object natSessionPrivateDstEPBindId is an address bind or an address port bind." ::= { natSessionEntry 5 } natSessionDirection OBJECT-TYPE SYNTAX INTEGER { inbound (1), outbound (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The direction of this session with respect to the local network. 'inbound' indicates that this session was initiated from the public network into the private network. 'outbound' indicates that this session was initiated from the private network into the public network." ::= { natSessionEntry 6 } natSessionUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The up time of this session in one-hundredths of a second." Rohit, et al. Standards Track [Page 40] RFC 4008 NAT MIB March 2005 ::= { natSessionEntry 7 } natSessionAddrMapIndex OBJECT-TYPE SYNTAX NatAddrMapId MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a pointer to the natAddrMapTable entry (and the parameters of that entry) used in creating this session. This object, in conjunction with the ifIndex (which identifies a unique addrMapName), points to a unique entry in the natAddrMapTable." ::= { natSessionEntry 8 } natSessionProtocolType OBJECT-TYPE SYNTAX NatProtocolType MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol type of this session." ::= { natSessionEntry 9 } natSessionPrivateAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the address type used for natSessionPrivateSrcAddr and natSessionPrivateDstAddr." ::= { natSessionEntry 10 } natSessionPrivateSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The source IP address of the session endpoint that lies in the private network. The value of this object must be zero only when the natSessionPrivateSrcEPBindId object has a zero value. When the value of this object is zero, the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPrivateAddrType object." ::= { natSessionEntry 11 } Rohit, et al. Standards Track [Page 41] RFC 4008 NAT MIB March 2005 natSessionPrivateSrcPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "When the value of protocol is TCP or UDP, this object represents the source port in the first packet of session while in private-realm. On the other hand, when the protocol is ICMP, a NAT session is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the private-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. The value of this object must be zero when the natSessionPrivateSrcEPBindId object has zero value and value of natSessionPrivateSrcEPBindMode is addressPortBind(2). In such a case, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort, or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 12 } natSessionPrivateDstAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The destination IP address of the session endpoint that lies in the private network. The value of this object must be zero when the natSessionPrivateDstEPBindId object has a zero value. In such a scenario, the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPrivateAddrType object." ::= { natSessionEntry 13 } natSessionPrivateDstPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current Rohit, et al. Standards Track [Page 42] RFC 4008 NAT MIB March 2005 DESCRIPTION "When the value of protocol is TCP or UDP, this object represents the destination port in the first packet of session while in private-realm. On the other hand, when the protocol is ICMP, this object is not relevant and should be set to zero. The value of this object must be zero when the natSessionPrivateDstEPBindId object has a zero value and natSessionPrivateDstEPBindMode is set to addressPortBind(2). In such a case, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort, or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 14 } natSessionPublicAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the address type used for natSessionPublicSrcAddr and natSessionPublicDstAddr." ::= { natSessionEntry 15 } natSessionPublicSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The source IP address of the session endpoint that lies in the public network. The value of this object must be zero when the natSessionPrivateSrcEPBindId object has a zero value. In such a scenario, the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPublicAddrType object." ::= { natSessionEntry 16 } natSessionPublicSrcPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only Rohit, et al. Standards Track [Page 43] RFC 4008 NAT MIB March 2005 STATUS current DESCRIPTION "When the value of protocol is TCP or UDP, this object represents the source port in the first packet of session while in public-realm. On the other hand, when protocol is ICMP, a NAT session is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the public-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. The value of this object must be zero when the natSessionPrivateSrcEPBindId object has a zero value and natSessionPrivateSrcEPBindMode is set to addressPortBind(2). In such a scenario, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 17 } natSessionPublicDstAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The destination IP address of the session endpoint that lies in the public network. The value of this object must be non-zero when the natSessionPrivateDstEPBindId object has a non-zero value. If the value of this object and the corresponding natSessionPrivateDstEPBindId object value is zero, then the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPublicAddrType object." ::= { natSessionEntry 18 } natSessionPublicDstPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current Rohit, et al. Standards Track [Page 44] RFC 4008 NAT MIB March 2005 DESCRIPTION "When the value of protocol is TCP or UDP, this object represents the destination port in the first packet of session while in public-realm. On the other hand, when the protocol is ICMP, this object is not relevant for translation and should be zero. The value of this object must be zero when the natSessionPrivateDstEPBindId object has a zero value and natSessionPrivateDstEPBindMode is addressPortBind(2). In such a scenario, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort, or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 19 } natSessionMaxIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The max time for which this session can be idle without detecting a packet." ::= { natSessionEntry 20 } natSessionCurrentIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since a packet belonging to this session was last detected." ::= { natSessionEntry 21 } natSessionInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound packets that were translated for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other Rohit, et al. Standards Track [Page 45] RFC 4008 NAT MIB March 2005 times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natSessionEntry 22 } natSessionOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets that were translated for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natSessionEntry 23 } -- -- The Protocol table -- natProtocolTable OBJECT-TYPE SYNTAX SEQUENCE OF NatProtocolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing per protocol NAT statistics." ::= { natMIBObjects 10 } natProtocolEntry OBJECT-TYPE SYNTAX NatProtocolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing NAT statistics pertaining to a particular protocol." INDEX { natProtocol } ::= { natProtocolTable 1 } NatProtocolEntry ::= SEQUENCE { natProtocol NatProtocolType, natProtocolInTranslates Counter64, natProtocolOutTranslates Counter64, natProtocolDiscards Counter64 } Rohit, et al. Standards Track [Page 46] RFC 4008 NAT MIB March 2005 natProtocol OBJECT-TYPE SYNTAX NatProtocolType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the protocol pertaining to which parameters are reported." ::= { natProtocolEntry 1 } natProtocolInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound packets pertaining to the protocol identified by natProtocol that underwent NAT. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natProtocolEntry 2 } natProtocolOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets pertaining to the protocol identified by natProtocol that underwent NAT. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natProtocolEntry 3 } natProtocolDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets pertaining to the protocol identified by natProtocol that had to be rejected/dropped due to lack of resources. These rejections could be due to session timeout, resource unavailability, lack of address space, etc. Rohit, et al. Standards Track [Page 47] RFC 4008 NAT MIB March 2005 Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natProtocolEntry 4 } -- -- Notifications section -- natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } -- -- Notifications -- natPacketDiscard NOTIFICATION-TYPE OBJECTS { ifIndex } STATUS current DESCRIPTION "This notification is generated when IP packets are discarded by the NAT function; e.g., due to lack of mapping space when NAT is out of addresses or ports. Note that the generation of natPacketDiscard notifications is throttled by the agent, as specified by the 'natNotifThrottlingInterval' object." ::= { natMIBNotifications 1 } -- -- Conformance information. -- natMIBConformance OBJECT IDENTIFIER ::= { natMIB 2 } natMIBGroups OBJECT IDENTIFIER ::= { natMIBConformance 1 } natMIBCompliances OBJECT IDENTIFIER ::= { natMIBConformance 2 } -- -- Units of conformance -- natConfigGroup OBJECT-GROUP OBJECTS { natInterfaceRealm, natInterfaceServiceType, natInterfaceStorageType, natInterfaceRowStatus, natAddrMapName, Rohit, et al. Standards Track [Page 48] RFC 4008 NAT MIB March 2005 natAddrMapEntryType, natAddrMapTranslationEntity, natAddrMapLocalAddrType, natAddrMapLocalAddrFrom, natAddrMapLocalAddrTo, natAddrMapLocalPortFrom, natAddrMapLocalPortTo, natAddrMapGlobalAddrType, natAddrMapGlobalAddrFrom, natAddrMapGlobalAddrTo, natAddrMapGlobalPortFrom, natAddrMapGlobalPortTo, natAddrMapProtocol, natAddrMapStorageType, natAddrMapRowStatus, natBindDefIdleTimeout, natUdpDefIdleTimeout, natIcmpDefIdleTimeout, natOtherDefIdleTimeout, natTcpDefIdleTimeout, natTcpDefNegTimeout, natNotifThrottlingInterval } STATUS current DESCRIPTION "A collection of configuration-related information required to support management of devices supporting NAT." ::= { natMIBGroups 1 } natTranslationGroup OBJECT-GROUP OBJECTS { natAddrBindNumberOfEntries, natAddrBindGlobalAddrType, natAddrBindGlobalAddr, natAddrBindId, natAddrBindTranslationEntity, natAddrBindType, natAddrBindMapIndex, natAddrBindSessions, natAddrBindMaxIdleTime, natAddrBindCurrentIdleTime, natAddrBindInTranslates, natAddrBindOutTranslates, natAddrPortBindNumberOfEntries, natAddrPortBindGlobalAddrType, natAddrPortBindGlobalAddr, natAddrPortBindGlobalPort, natAddrPortBindId, natAddrPortBindTranslationEntity, Rohit, et al. Standards Track [Page 49] RFC 4008 NAT MIB March 2005 natAddrPortBindType, natAddrPortBindMapIndex, natAddrPortBindSessions, natAddrPortBindMaxIdleTime, natAddrPortBindCurrentIdleTime, natAddrPortBindInTranslates, natAddrPortBindOutTranslates, natSessionPrivateSrcEPBindId, natSessionPrivateSrcEPBindMode, natSessionPrivateDstEPBindId, natSessionPrivateDstEPBindMode, natSessionDirection, natSessionUpTime, natSessionAddrMapIndex, natSessionProtocolType, natSessionPrivateAddrType, natSessionPrivateSrcAddr, natSessionPrivateSrcPort, natSessionPrivateDstAddr, natSessionPrivateDstPort, natSessionPublicAddrType, natSessionPublicSrcAddr, natSessionPublicSrcPort, natSessionPublicDstAddr, natSessionPublicDstPort, natSessionMaxIdleTime, natSessionCurrentIdleTime, natSessionInTranslates, natSessionOutTranslates } STATUS current DESCRIPTION "A collection of BIND-related objects required to support management of devices supporting NAT." ::= { natMIBGroups 2 } natStatsInterfaceGroup OBJECT-GROUP OBJECTS { natInterfaceInTranslates, natInterfaceOutTranslates, natInterfaceDiscards } STATUS current DESCRIPTION "A collection of NAT statistics associated with the interface on which NAT is configured, to aid troubleshooting/monitoring of the NAT operation." ::= { natMIBGroups 3 } natStatsProtocolGroup OBJECT-GROUP Rohit, et al. Standards Track [Page 50] RFC 4008 NAT MIB March 2005 OBJECTS { natProtocolInTranslates, natProtocolOutTranslates, natProtocolDiscards } STATUS current DESCRIPTION "A collection of protocol specific NAT statistics, to aid troubleshooting/monitoring of NAT operation." ::= { natMIBGroups 4 } natStatsAddrMapGroup OBJECT-GROUP OBJECTS { natAddrMapInTranslates, natAddrMapOutTranslates, natAddrMapDiscards, natAddrMapAddrUsed } STATUS current DESCRIPTION "A collection of address map specific NAT statistics, to aid troubleshooting/monitoring of NAT operation." ::= { natMIBGroups 5 } natMIBNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { natPacketDiscard } STATUS current DESCRIPTION "A collection of notifications generated by devices supporting this MIB." ::= { natMIBGroups 6 } -- -- Compliance statements -- natMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB. The following index objects cannot be added as OBJECT clauses but nevertheless have the compliance requirements: " -- OBJECT natAddrBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support Rohit, et al. Standards Track [Page 51] RFC 4008 NAT MIB March 2005 -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrPortBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrPortBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." MODULE IF-MIB -- The interfaces MIB, RFC2863 MANDATORY-GROUPS { ifCounterDiscontinuityGroup } MODULE -- this module MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, natStatsInterfaceGroup } GROUP natStatsProtocolGroup DESCRIPTION "This group is optional." GROUP natStatsAddrMapGroup DESCRIPTION "This group is optional." GROUP natMIBNotificationGroup DESCRIPTION "This group is optional." OBJECT natAddrMapLocalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support Rohit, et al. Standards Track [Page 52] RFC 4008 NAT MIB March 2005 for IPv4 and IPv6." OBJECT natAddrMapLocalAddrFrom SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapLocalAddrTo SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrFrom SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrTo SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 Rohit, et al. Standards Track [Page 53] RFC 4008 NAT MIB March 2005 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrPortBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrPortBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateSrcAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicSrcAddr SYNTAX InetAddress (SIZE(4|16)) Rohit, et al. Standards Track [Page 54] RFC 4008 NAT MIB March 2005 DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." ::= { natMIBCompliances 1 } natMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read-create (i.e., in read-only mode), then such an implementation can claim read-only compliance. Such a device can then be monitored but cannot be configured with this MIB. The following index objects cannot be added as OBJECT clauses but nevertheless have the compliance requirements: " -- OBJECT natAddrBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrPortBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." Rohit, et al. Standards Track [Page 55] RFC 4008 NAT MIB March 2005 -- OBJECT natAddrPortBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." MODULE IF-MIB -- The interfaces MIB, RFC2863 MANDATORY-GROUPS { ifCounterDiscontinuityGroup } MODULE -- this module MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, natStatsInterfaceGroup } GROUP natStatsProtocolGroup DESCRIPTION "This group is optional." GROUP natStatsAddrMapGroup DESCRIPTION "This group is optional." GROUP natMIBNotificationGroup DESCRIPTION "This group is optional." OBJECT natInterfaceRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT natAddrMapLocalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapLocalAddrFrom SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." Rohit, et al. Standards Track [Page 56] RFC 4008 NAT MIB March 2005 OBJECT natAddrMapLocalAddrTo SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrFrom SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrTo SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT natAddrBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) Rohit, et al. Standards Track [Page 57] RFC 4008 NAT MIB March 2005 DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrPortBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrPortBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateSrcAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicSrcAddr Rohit, et al. Standards Track [Page 58] RFC 4008 NAT MIB March 2005 SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." ::= { natMIBCompliances 2 } END 6. Acknowledgements The authors of the document would like to thank Randy Turner, Ashwini S.T., Kevin Luehrs, Sam Sankoorikal, and Juergen Quittek for their valuable feedback. The authors would like to especially thank Juergen Schoenwaelder for his patient and fine-combed review and detailed comments as a MIB doctor. The NAT MIB is much clearer and flatter as a result of Juergen's suggestions. 7. Security Considerations It is clear that this MIB can potentially be useful for configuration. Unauthorized access to the write-able objects could cause a denial of service and/or widespread network disturbance. Hence, the support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. At this writing, no security holes have been identified beyond those that SNMP Security is itself intended to address. These relate primarily to controlled access to sensitive information and the ability to configure a device - or which might result from operator error, which is beyond the scope of any security architecture. There are a number of managed objects in this MIB that may contain information that may be sensitive from a business perspective, in that they may represent NAT bind and session information. The NAT bind and session objects reveal the identity of private hosts that are engaged in a session with external end nodes. A curious outsider Rohit, et al. Standards Track [Page 59] RFC 4008 NAT MIB March 2005 could monitor these two objects to assess the number of private hosts being supported by the NAT device. Further, a disgruntled former employee of an enterprise could use the NAT bind and session information to break into specific private hosts by intercepting the existing sessions or originating new sessions into the host. There are no objects that are sensitive in their own right, such as passwords or monetary amounts. It may even be important to control GET access to these objects and possibly to encrypt the values of these objects when they are sent over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. References 8.1. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. Rohit, et al. Standards Track [Page 60] RFC 4008 NAT MIB March 2005 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC4001] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. 8.2. Informative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Rohit, et al. Standards Track [Page 61] RFC 4008 NAT MIB March 2005 Authors' Addresses R. Rohit Mascon Global Limited #59/2 100 ft Ring Road Banashankari II Stage Bangalore 560 070 India Phone: +91 80 679 6227 EMail: rrohit74@hotmail.com P. Srisuresh Caymas Systems, Inc. 1179-A North McDowell Blvd. Petaluma, CA 94954 Phone: (707) 283-5063 EMail: srisuresh@yahoo.com Rajiv Raghunarayan Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408 853 9612 EMail: raraghun@cisco.com Nalinaksh Pai Cisco Systems, Inc. Prestige Waterford No. 9, Brunton Road Bangalore - 560 025 India Phone: +91 80 532 1300 extn. 6354 EMail: npai@cisco.com Rohit, et al. Standards Track [Page 62] RFC 4008 NAT MIB March 2005 Cliff Wang Information Security Bank One Corp 1111 Polaris Pkwy Columbus, OH 43240 Phone: +1 614 213 6117 EMail: cliffwang2000@yahoo.com Rohit, et al. Standards Track [Page 63] RFC 4008 NAT MIB March 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rohit, et al. Standards Track [Page 64] snmp-mibs-downloader-1.1/mibrfcs/rfc4011.txt0000644000000000000000000100732611402176071015560 0ustar Network Working Group S. Waldbusser Request for Comments: 4011 Nextbeacon Category: Standards Track J. Saperia JDS Consulting, Inc. T. Hongal Riverstone Networks, Inc. March 2005 Policy Based Management MIB 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. Table of Contents 1. The Internet-Standard Management Framework .................. 3 2. Overview .................................................... 4 3. Policy-Based Management Architecture ........................ 4 4. Policy-Based Management Execution Environment ............... 10 4.1. Terminology ........................................... 10 4.2. Execution Environment - Elements of Procedure ......... 10 4.3. Element Discovery ..................................... 11 4.3.1. Implementation Notes .......................... 12 4.4. Element Filtering ..................................... 13 4.4.1. Implementation Notes .......................... 13 4.5. Policy Enforcement .................................... 13 4.5.1. Implementation Notes .......................... 14 5. The PolicyScript Language ................................... 14 5.1. Formal Definition ..................................... 15 Waldbusser, et al. Standards Track [Page 1] RFC 4011 Policy Based Management MIB March 2005 5.2. Variables ............................................. 18 5.2.1. The Var Class ................................. 19 5.3. PolicyScript QuickStart Guide ......................... 23 5.3.1. Quickstart for C Programmers .................. 25 5.3.2. Quickstart for Perl Programmers ............... 25 5.3.3. Quickstart for TCL Programmers ................ 25 5.3.4. Quickstart for Python Programmers ............. 26 5.3.5. Quickstart for JavaScript/ECMAScript/JScript Programmers ................................... 26 5.4. PolicyScript Script Return Values ..................... 26 6. Index Information for `this element' ........................ 27 7. Library Functions ........................................... 28 8. Base Function Library ....................................... 29 8.1. SNMP Library Functions ................................ 29 8.1.1. SNMP Operations on Non-Local Systems .......... 30 8.1.2. Form of SNMP Values ........................... 32 8.1.3. Convenience SNMP Functions .................... 34 8.1.3.1. getVar() ............................ 34 8.1.3.2. exists() ............................ 34 8.1.3.3. setVar() ............................ 35 8.1.3.4. searchColumn() ...................... 36 8.1.3.5. setRowStatus() ...................... 38 8.1.3.6. createRow() ......................... 39 8.1.3.7. counterRate() ....................... 42 8.1.4. General SNMP Functions ........................ 44 8.1.4.1. newPDU() ............................ 45 8.1.4.2. writeVar() .......................... 45 8.1.4.3. readVar() ........................... 46 8.1.4.4. snmpSend() .......................... 47 8.1.4.5. readError() ......................... 48 8.1.4.6. writeBulkParameters() ............... 48 8.1.5. Constants for SNMP Library Functions .......... 49 8.2. Policy Library Functions .............................. 51 8.2.1. elementName() ................................. 51 8.2.2. elementAddress() .............................. 51 8.2.3. elementContext() .............................. 52 8.2.4. ec() .......................................... 52 8.2.5. ev() .......................................... 52 8.2.6. roleMatch() ................................... 52 8.2.7. Scratchpad Functions .......................... 53 8.2.8. setScratchpad() ............................... 55 8.2.9. getScratchpad() ............................... 56 8.2.10. signalError() ................................. 57 8.2.11. defer() ....................................... 57 8.2.12. fail() ........................................ 58 8.2.13. getParameters() ............................... 58 8.3. Utility Library Functions ............................. 59 8.3.1. regexp() ...................................... 59 Waldbusser, et al. Standards Track [Page 2] RFC 4011 Policy Based Management MIB March 2005 8.3.2. regexpReplace() ............................... 60 8.3.3. oidlen() ...................................... 60 8.3.4. oidncmp() ..................................... 60 8.3.5. inSubtree() ................................... 60 8.3.6. subid() ....................................... 61 8.3.7. subidWrite() .................................. 61 8.3.8. oidSplice() ................................... 61 8.3.9. parseIndex() .................................. 62 8.3.10. stringToDotted() .............................. 63 8.3.11. integer() ..................................... 64 8.3.12. string() ...................................... 64 8.3.13. type() ........................................ 64 8.3.14. chr() ......................................... 64 8.3.15. ord() ......................................... 64 8.3.16. substr() ...................................... 65 8.4. General Functions ..................................... 65 9. International String Library ................................ 65 9.1. stringprep() .......................................... 66 9.1.1. Stringprep Profile ............................ 66 9.2. utf8Strlen() .......................................... 67 9.3. utf8Chr() ............................................. 68 9.4. utf8Ord() ............................................. 68 9.5. utf8Substr() .......................................... 68 10. Schedule Table .............................................. 69 11. Definitions ................................................. 70 12. Relationship to Other MIB Modules ........................... 113 13. Security Considerations ..................................... 114 14. IANA Considerations ......................................... 117 15. Acknowledgements ............................................ 118 16. References .................................................. 118 16.1. Normative References .................................. 118 16.2. Informative References ................................ 119 Authors' Addresses .............................................. 120 Full Copyright Statement ........................................ 121 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [2], STD 58, RFC 2579 [3], and STD 58, RFC 2580 [4]. Waldbusser, et al. Standards Track [Page 3] RFC 4011 Policy Based Management MIB March 2005 2. Overview Large IT organizations have developed management strategies to cope with the extraordinarily large scale and complexity of today's networks. In particular, they have tried to configure the network as a whole by describing and implementing high-level business policies, rather than manage device by device, where orders of magnitude more decisions (and mistakes) may be made. The following are examples of "business policies": - All routers will run code version 6.2. - On-site contractors will only be connected to ports that are configured with special security restrictions. - All voice over cable ports in California must provide free local calling. - Apply special forwarding to all ports whose customers have paid for premium service. Each of these policies could represent an action applied to hundreds of thousands of variables. To automate this practice, customers need software tools that will implement business policies across their networks, as well as standard protocols that will ensure that policies can be applied to all of their devices, regardless of the vendor. This practice is called Policy-Based Management. This document defines managed objects for the Simple Network Management Protocol that are used to distribute policies in a common form throughout the network. 3. Policy-Based Management Architecture Policy-based management is the practice of applying management operations globally on all managed elements that share certain attributes. Policies are intended to express a notion of: if (an element has certain characteristics) then (apply an operation to that element) Waldbusser, et al. Standards Track [Page 4] RFC 4011 Policy Based Management MIB March 2005 Policies take the following normal form: if (policyCondition) then (policyAction) A policyCondition is a script that results in a boolean to determine whether an element is a member of a set of elements upon which an action is to be performed. A policyAction is an operation performed on an element or a set of elements. These policies are most often executed on or near managed devices where the elements live (and thus their characteristics may be easily inspected) and where operations on those elements will be performed. A management station is responsible for distributing an organization's policies to all the managed devices in the infrastructure. The pmPolicyTable provides managed objects for representing a policy on a managed device. An element is an instance of a physical or logical entity and is embodied by a group of related MIB variables, such as all the variables for interface 7. This enables policies to be expressed more efficiently and concisely. Elements can also model circuits, CPUs, queues, processes, systems, etc. Conceptually, policies are executed in the following manner: for each element for which policyCondition returns true, execute policyAction on that element For example: If (interface is fast ethernet) then (apply full-duplex mode) If (interface is access) then (apply security filters) If (circuit w/gold service paid for) then (apply special queuing) Each unique combination of policy and element is called an execution context. Within a particular execution context, the phrase 'this element' is often used to refer to the associated element, as most policy operations will be applied to 'this element'. The address of 'this element' contains the object identifier of any attribute of the element, the SNMP context the element was discovered in, and the address of the system on which the element was discovered. Waldbusser, et al. Standards Track [Page 5] RFC 4011 Policy Based Management MIB March 2005 Policies can manage elements on the same system: ----------------------------------------------------- | | | Managed System | | | | | | ------------------ Managed Elements | | | | interfaces | | | Policy Manager | manages... circuits | | | | queues | | ------------------ processes | | ... | | | ----------------------------------------------------- or they can manage elements on other systems: -------------------------- | Managed System | -------------------------- | Managed Elements | | | | interfaces | | Management Station or | | circuits | | Mid-Level Manager | | ... | | | -------------------------- | ------------------ | manages... | | Policy Manager | | -------------------------- | ------------------ | | Managed System | | | | Managed Elements | -------------------------- | interfaces | | circuits | | ... | -------------------------- ... PolicyConditions have the capability of performing comparison operations on SNMP variables, logical expressions, and other functions. Many device characteristics are already defined in MIB Modules and are easy to include in policyCondition expressions (ifType == ethernet, frCircuitCommittedBurst < 128K, etc). However, there are important characteristics that aren't currently in MIB objects, and, worse, it is not current practice to store this information on managed devices. Therefore, this document defines MIB objects for this information. To meet today's needs there are three missing areas: roles, capabilities, and time. Waldbusser, et al. Standards Track [Page 6] RFC 4011 Policy Based Management MIB March 2005 Roles A role is an administratively specified characteristic of a managed element. As a selector for policies, it determines the applicability of the policy to a particular managed element. Some examples of roles are political, financial, legal, geographical, or architectural characteristics, typically not directly derivable from information stored on the managed system. For example, "paid for premium service" or "is plugged into a UPS" are examples of roles, whereas the "percent utilization of a link" would not be. Some types of information one would put into a role include the following: political - describes the role of a person or group of people, or of a service that a group of people uses. Examples: executive, sales, outside-contractor, customer. If (attached user is executive) then (apply higher bandwidth) If (attached user is outside-contractor) then (restrict access) financial/legal - describes what financial consideration was received. Could also include contractual or legal considerations. Examples: paid, gold, free, trial, demo, lifeline. If (gold service paid for) then (apply special queuing) geographical - describes the location of an element. Examples: California, Headquarters, insecure conduit. If (interface leaves the building) then (apply special security) architectural - describes the network architects "intent" for an element. Examples: backup, trunk. If (interface is backup) then (set ifAdminStatus = down) Roles in this model are human-defined strings that can be referenced by policy code. The role table in this MIB may be used to assign role strings to elements and to view all role string assignments. Implementation-specific mechanisms may also be used to assign role strings; however, these assignments must be visible in the role table. Multiple roles may be assigned to each element. Because policy code has access to data in MIB objects that represent the current state of the system and (in contrast) role strings are more static, it is recommended that role strings not duplicate information available in MIB objects. Role strings generally should be used to describe information not accessible in MIB objects. Waldbusser, et al. Standards Track [Page 7] RFC 4011 Policy Based Management MIB March 2005 Policy scripts may inspect role assignments to make decisions based on whether an element has a particular role assigned to it. The pmRoleTable allows a management station to learn what roles exist on a managed system. The management station may choose not to install policies that depend on a role that does not exist on any elements in the system. The management station can then register for notifications of new roles. Upon receipt of a pmNewRoleNotification, it may choose to install new policies that make use of that new role. Capabilities The capabilities table allows a management station to learn what capabilities exist on a managed system. The management station may choose not to install policies that depend on a capability that does not exist on any elements in the system. The management station can then register for notifications of new capabilities. Upon receipt of a pmNewCapabilityNotification, it may choose to install new policies that make use of that new capability. Time Managers may wish to define policies that are intended to apply for certain periods of time. This might mean that a policy is installed and is dormant for a period of time, becomes ready, and then later goes dormant again. Sometimes these time periods will be regular (Monday-Friday 9-5), and sometimes ad hoc. This MIB provides a schedule table that can schedule when a policy is ready and when it is dormant. Waldbusser, et al. Standards Track [Page 8] RFC 4011 Policy Based Management MIB March 2005 A policy manager contains the following: ------------------------------------------------------- | Policy Manager | | | | ---------------------------------------- | | | Agent | | | | | | | | --------------------------------- | | | | | Policy Download and Control | | | | | | pmPolicyTable | | | | | | pmElementTypeRegTable | | | | | | pmSchedTable | | | | | --------------------------------- | | | | | | | | --------------------------------- | | | | | Policy Environment Control | | | | | | pmRoleTable | | | | | | pmCapabilitiesTables | | | | | --------------------------------- | | | | | | | | --------------------------------- | | | | | Policy Monitoring | | | | | | pmTrackingTables | | | | | | pmDebuggingTable | | | | | --------------------------------- | | | ---------------------------------------- | | | | -------------------------------- | | | Execution Environment | | | | | | | | ----------------------- | | | | | Policy Scheduler | | | | | ----------------------- | | | | ----------------------- | | | | | Language | | | | | ----------------------- | | | | ----------------------- | | | | | Function Library | | | | | ----------------------- | | | -------------------------------- | ------------------------------------------------------- Waldbusser, et al. Standards Track [Page 9] RFC 4011 Policy Based Management MIB March 2005 4. Policy-Based Management Execution Environment 4.1. Terminology Active Schedule - A schedule specifies certain times that it will be considered active. A schedule is active during those times. Valid Policy - A valid policy is a policy that is fully configured and enabled to run. A valid policy may run unless it is linked to a schedule entry that says the policy is not currently active. Ready Policy - A ready policy is a valid policy that either has no schedule or is linked to a schedule that is currently active. Precedence Group - Multiple policies can be assigned to a precedence group with the resulting behavior that for each element, of the ready policies that match the condition, only the one with the highest precedence value will be active. For example, if there is a default bronze policy that applies to any interface and a special policy for gold interfaces, the higher precedence of the gold policy will ensure that it is run on gold ports and that the bronze policy isn't. Active Execution Context - An active execution context is a pairing of a ready policy with an element that matches the element type filter and the policy condition. If there are multiple policies in the precedence group, it is also necessary that no higher precedence policy in the group match the policy condition. Run-Time Exception (RTE) - A run-time exception is a fatal error caused in language or function processing. If, during the invocation of a script, a run-time exception occurs, execution of that script is immediately terminated. If a policyCondition experiences a run-time exception while processing an element, the element is not matched by the condition and the associated action will not be run on that element. A run-time exception can cause an entry to be added to the pmDebuggingTable and will be reflected in the pmTrackingPEInfo object. 4.2. Execution Environment - Elements of Procedure There are several steps performed in order to execute policies in this environment: - Element Discovery - Element Filtering - Policy Enforcement Waldbusser, et al. Standards Track [Page 10] RFC 4011 Policy Based Management MIB March 2005 4.3. Element Discovery An element is an instance of a physical or logical entity. Examples of elements include interfaces, circuits, queues, CPUs, and processes. Sometimes various attributes of an entity will be described through tables in several standard and proprietary MIB Modules. As long as the indexing is consistent between these tables, the entity can be modeled as one element. For example, the ifTable and the dot3Stats table both contain attributes of interfaces and share the same index (ifIndex), therefore they can be modeled as one element type. The Element Type Registration table allows the manager to learn what element types are being managed by the system and to register new types, if necessary. An element type is registered by providing the OID of an SNMP object (i.e., without the instance). Each SNMP instance that exists under that object is a distinct element. The index part of the discovered OID will be supplied to policy conditions and actions so that this code can inspect and configure the element. The agent can determine the index portion of discovered OIDs based on the length of the pmElementTypeRegOIDPrefix for the portion of the MIB that is being retrieved. For example, if the OIDPrefix is 'ifEntry', which has 9 subids, the index starts on the 11th subid (skipping the subidentifier for the column; e.g., ifSpeed). For each element that is discovered, the policy condition is called with the element's name as an argument to see whether the element is a member of the set the policy acts upon. Note that agents may automatically configure entries in this table for frequently used element types (interfaces, circuits, etc.). In particular, it may configure elements for which discovery is optimized in one or both of the following ways: 1. The agent may discover elements by scanning internal data structures as opposed to issuing local SNMP requests. It is possible to recreate the exact semantics described in this table even if local SNMP requests are not issued. 2. The agent may receive asynchronous notification of new elements (for example, "card inserted") and use that information to create elements instantly rather than through polling. A similar feature might be available for the deletion of elements. Note that upon restart, the disposition of agent-installed entries is described by the pmPolicyStorageType object. Waldbusser, et al. Standards Track [Page 11] RFC 4011 Policy Based Management MIB March 2005 A special element type "0.0" represents the "system element". "0.0" represents the single instance of the system itself and provides an execution context for policies to operate on "the system" and on MIB objects modeled as scalars. For example, "0.0" gives an execution context for policy-based selection of the operating system code version (likely modeled as a scalar MIB object). The element type "0.0" always exists. As a consequence, no actual discovery will take place and the pmElementTypeRegMaxLatency object will have no effect for the "0.0" element type. However, if the "0.0" element type is not registered in the table, policies will not be executed on the "0.0" element. If the agent is discovering elements by polling, it should check for new elements no less frequently than pmElementTypeRegMaxLatency would dictate. When an element is first discovered, all policyConditions are run immediately, and policyConditions that match will have the associated policyAction run immediately. Subsequently, the policyCondition will be run regularly for the element, with no more than pmPolicyConditionMaxLatency milliseconds elapsing between each invocation. Note that if an implementation has the ability to be alerted immediately when a particular type of element is created, it is urged to discover that type of element in this fashion rather than through polling, resulting in immediate configuration of the discovered element. 4.3.1. Implementation Notes Note that although the external behavior of this registration process is defined in terms of the walking of MIB tables, implementation strategies may differ. For example, commonly used element types (such as interface) may have purpose-built element discovery capability built-in and advertised to managers through an entry in the pmElementTypeRegTable. Before registering an element type, a manager is responsible for inspecting the table to see whether it is already registered (either by the agent or by another manager). Note that entries that differ only in the last subid (which specifies which object is an entry) are effectively duplicates and should be treated as such by the manager. The system that implements the Policy-Based Management MIB may not have knowledge of the format of object identifiers in other MIB Modules. Therefore it is inappropriate for it to check these OIDs for errors. It is the responsibility of the management station to register well-formed object identifiers. For example, if an extra sub-identifier is supplied when the ifTable is registered, no Waldbusser, et al. Standards Track [Page 12] RFC 4011 Policy Based Management MIB March 2005 elements will be discovered. Similarly, if a sub-identifier is missing, every element will be discovered numerous times (once per column) and none of the element addresses will be well formed. 4.4. Element Filtering The first step in executing a policy is to see whether the policy is ready to run based on its schedule. If the pmPolicySchedule object is equal to zero, there is no schedule defined, and the policy is always ready. If the pmPolicySchedule object is non-zero, then the policy is ready only if the referenced schedule group contains at least one valid schedule entry that is active at the current time. If the policy is ready, the next step in executing a policy is to see which elements match the policy condition. The policy condition is called once for each element and runs to completion. The element's name is the only argument that is passed to the condition code for each invocation. No state is remembered within the policy script from the previous invocation of 'this element' or from the previous invocation of the policy condition, except for state accessible through library functions. Two notable examples of these are the scratchpad functions, which explicitly provide for storing state, and the SNMP functions, which can store state in local or remote MIB objects. If any run-time exception occurs, the condition will terminate immediately for 'this element'. If the condition returns non-zero, the corresponding policy action will be executed for 'this element'. If an element matches a condition and it had not matched that condition the last time it was checked (or if it is a newly discovered element), the associated policyAction will be executed immediately. If the element had matched the condition at the last check, it will remain in the set of elements whose policyAction will be run within the policyActionMaxLatency. 4.4.1. Implementation Notes Whether policy conditions are multi-tasked is an implementation- dependent matter. Each condition/element combination is conceptually its own process and can be scheduled sequentially, or two or more could be run simultaneously. 4.5. Policy Enforcement For each element that has returned non-zero from the policy condition, the corresponding policy action is called. The element's name is the only argument that is passed to the policy action for each invocation. Except for state accessible from library functions, Waldbusser, et al. Standards Track [Page 13] RFC 4011 Policy Based Management MIB March 2005 no state is remembered from the policy condition evaluation, or from the previous condition/action invocation of 'this element' or from the previous invocation of the policy condition or action on any other element. If any run-time exception occurs, the action will terminate immediately for 'this element'. 4.5.1. Implementation Notes How policy actions are multi-tasked is an implementation-dependent matter. Each condition/element combination is conceptually its own process and can be scheduled sequentially, or two or more could be run simultaneously. 5. The PolicyScript Language Policy conditions and policy actions are expressed with the PolicyScript language. The PolicyScript language is designed to be a small interpreted language that is simple to understand and implement; it is designed to be appropriate for writing small scripts that make up policy conditions and actions. PolicyScript is intended to be familiar to programmers that know one of several common languages, including Perl and C. Nominally, policyScript is a subset of the C language; however, it was desirable to have access to C++'s operator overloading (solely to aid in documenting the language). Therefore, PolicyScript is defined formally as a subset of the C++ language in which many of the operators are overloaded as part of the "var" class. Note, however, that a PolicyScript program cannot further overload operators, as the syntax to specify overloading is not part of the PolicyScript syntax. A subset was used to provide for easy development of low-cost interpreters of PolicyScript and to take away language constructs that are peculiar to the C/C++ languages. For example, it is expected that both C and Perl programmers will understand the constructs allowed in PolicyScript. Some examples of the C/C++ features that are not available are function definitions, pointer variables, structures, enums, typedefs, floating point and pre-processor functions (except for comments). This language is formally defined as a subset of ISO C++ [10] but only allows constructs that may be expressed in the Extended Backus- Naur Form (EBNF) documented here. This is because although EBNF doesn't fully specify syntactical rules (it allows constructs that are invalid) and doesn't specify semantic rules, it can successfully be used to define the subset of the language that is required for Waldbusser, et al. Standards Track [Page 14] RFC 4011 Policy Based Management MIB March 2005 conformance to this specification. Unless explicitly described herein, the meaning of any construct expressed in the EBNF can be found by reference to the ISO C++ standard. The use of comments and newlines are allowed and encouraged in order to promote readability of PolicyScript code. Comments begin with '/*' and end with '*/' or begin with '//' and go until the end of the line. One subset is not expressible in the EBNF syntax: all variables within an instance of a PolicyScript script are within the same scope. In other words, variables defined in a block delimited with '{' and '}' are not in a separate scope from variables in the enclosing block. PolicyScript code must be expressed in the ASCII character set. In the EBNF used here, terminals are character set members (singly or in a sequence) that are enclosed between two single-quote characters or described as a phrase between '<' and '>' characters. Nonterminals are a sequence of letters and underscore characters. A colon (:) following a nonterminal introduces its definition, a production. In a production, a '|' character separates alternatives. The '(' and ')' symbols group the enclosed items. The '[' and ']' symbols indicate that the enclosed items are optional. A '?' symbol following an item indicates that the item is optional. A '*' symbol following an item indicates that the item is repeated zero, one, or more times. A '+' symbol following an item indicates that the item is repeated one or more times. The symbol '--' begins a comment that ends at the end of the line. 5.1. Formal Definition The PolicyScript language follows the syntax and semantics of ISO C++ [10], but is limited to that which can be expressed in the EBNF below. The following keywords are reserved words and cannot be used in any policy script. This prevents someone from using a common keyword in another language as an identifier in a script, thereby confusing the meaning of the script. The reserved words are: auto, case, char, const, default, do, double, enum, extern, float, goto, inline, int, long, register, short, signed, sizeof, static, struct, switch, typedef, union, unsigned, void, and volatile. Waldbusser, et al. Standards Track [Page 15] RFC 4011 Policy Based Management MIB March 2005 Any syntax error, use of a reserved keyword, reference to an unknown identifier, improper number of function arguments, error in coercing an argument to the proper type, exceeding local limitations on string length, or exceeding local limitations on the total amount of storage used by local variables will cause an RTE. PolicyScript permits comments using the comment delimiters, '/*' to '*/', or the start of comment symbol '//'. -- Lexical Grammar letter: '_' | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' digit: '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' non_zero: '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' oct_digit: '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' hex_digit: digit | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' escape_seq: '\'' | '\"' | '\?' | '\\' | '\a' | '\b' | '\f' | '\n' | '\r' | '\t' | '\v' | '\' oct_digit+ | '\x' hex_digit+ non_quote: Any character in the ASCII character set except single quote ('), double quote ("), backslash ('\'), or newline. c_char: non_quote | '"' | escape_seq string_literal: '"' s_char* '"' s_char: non_quote | ''' | escape_seq char_constant: ''' c_char ''' decimal_constant: non_zero digit* Waldbusser, et al. Standards Track [Page 16] RFC 4011 Policy Based Management MIB March 2005 octal_constant: '0' oct_digit* hex_constant: ( '0x' | '0X' ) hex_digit+ integer_constant: decimal_constant | octal_constant | hex_constant identifier: letter ( letter | digit )* -- Phrase Structure Grammar -- Expressions primary_expr: identifier | integer_constant | char_constant | string_literal | '(' expression ')' postfix_expr: primary_expr | identifier '(' argument_expression_list? ')' | postfix_expr '++' | postfix_expr '--' | postfix_expr '[' expression ']' argument_expression_list: assignment_expr | argument_expression_list ',' assignment_expr unary_expr: postfix_expr | unary_op unary_expr unary_op: '+' | '-' | '~' | '!' | '++' | '--' binary_expr: unary_expr | binary_expr binary_op unary_expr binary_op: '||' | '&&' | '|' | '^' | '&' | '!=' | '==' | '>=' | '<=' | '>' | '<' | '>>' | '<<' | '-' | '+' | '%' | '/' | '*' assignment_expr: binary_expr | unary_expr assignment_op assignment_expr assignment_op: '=' | '*=' | '/=' | '%=' | '+=' | '-=' | '<<=' | '>>=' | '&=' | '^=' | '|=' expression: assignment_expr | expression ',' assignment_expr -- Declarations declaration: 'var' declarator_list ';' Waldbusser, et al. Standards Track [Page 17] RFC 4011 Policy Based Management MIB March 2005 declarator_list: init_declarator | declarator_list ',' init_declarator init_declarator: identifier [ '=' assignment_expr ] -- Statements statement: declaration | compound_statement | expression_statement | selection_statement | iteration_statement | jump_statement compound_statement: '{' statement* '}' expression_statement: expression? ';' selection_statement: 'if' '(' expression ')' statement | 'if' '(' expression ')' statement 'else' statement iteration_statement: 'while' '(' expression ')' statement | 'for' '(' expression? ';' expression? ';' expression? ')' statement jump_statement: 'continue' ';' | 'break' ';' | 'return' expression? ';' -- Root production PolicyScript: statement* 5.2. Variables To promote shorter scripts and ease in writing them, PolicyScript provides a loosely typed data class, "var", that can store both integer and string values. The native C++ types (char, int, etc.) are thus unnecessary and have not been carried into the subset that comprises this language. The semantics of the "var" type are modeled after those of ECMAScript[17]. For example: var number = 0, name = "IETF"; Waldbusser, et al. Standards Track [Page 18] RFC 4011 Policy Based Management MIB March 2005 This language will be executed in an environment where the following typedef is declared. (Note that this typedef will not be visible in the policyCondition or policyAction code.) typedef ... var; Although this declaration is expressed here as a typedef, the 'typedef' keyword itself is not available to be used in PolicyScript code. 5.2.1. The Var Class A value is an entity that takes on one of two types: string or integer. The String type is the set of all finite ordered sequences of zero or more 8-bit unsigned integer values ("elements"). The string type can store textual data as well as binary data sequences. Each element is considered to occupy a position within the sequence. These positions are indexed with nonnegative integers. The first element (if any) is at position 0, the next element (if any) at position 1, and so on. The length of a string is the number of elements (i.e., 8-bit values) within it. The empty string has length zero and therefore contains no elements. The integer type is the set of all integer values in the range -9223372036854775808 (-2^63) to 18446744073709551615 (2^64-1). If an integer operation would cause a (positive) overflow, then the result is returned modulo 2^64. If an integer operation would cause a (negative) underflow, then the result is undefined. Integer division rounds toward zero. Prior to initialization, a var object has type String and a length of zero. The policy script runtime system performs automatic type conversion as needed. To clarify the semantics of certain constructs it is useful to define a set of conversion operators: ToInteger(), ToString(), ToBoolean(), and Type(). These operators are not a part of the language; they are defined here to aid the specification of the semantics of the language. The conversion operators are polymorphic; that is, they can accept a value of any standard type. Waldbusser, et al. Standards Track [Page 19] RFC 4011 Policy Based Management MIB March 2005 ToInteger The operator ToInteger converts its argument to a value of type Integer according to the following table: Integer The result equals the input argument (no conversion). String See grammar and note below. integer_constant The result equals the input argument (no conversion). string_literal See grammar and note below. char_constant See grammar and note below. ToInteger Applied to Strings ToInteger applied to the String Type string_literal and to char_constants applies the following grammar to the input. If the grammar cannot interpret the string as an expansion of numeric_string, then an RTE is generated. Note that a numeric_string that is empty or contains only white space is converted to 0. -- EBNF for numeric_string numeric_string : white_space* numeric? white_space* white_space : | | | | | | | | | numeric : signed_decimal | hex_constant | octal_constant | enum_decimal signed_decimal: [ '-' | '+' ] decimal_constant enum_decimal: [ letter | digit | '-' ]* '(' decimal_constant ')' -- decimal_constant, hex_constant, and octal_constant are defined -- in the PolicyScript EBNF described earlier. Note that when the enum_decimal form is converted, the sequence of characters before the parenthesis and the pair of parenthesis themselves are completely ignored, and the decimal_constant inside the parenthesis is converted. Thus, "frame-relay(32)" translates to the integer 32. Although this will make the script more readable than using the constant "32", the burden is on the code writer to be accurate, as "ethernet-csmacd(32)" and "frame-relay(999)" will also be accepted. Waldbusser, et al. Standards Track [Page 20] RFC 4011 Policy Based Management MIB March 2005 ToString The operator ToString converts its argument to a value of type String according to the following table: Integer Return the string containing the decimal representation of the input argument in the form of signed_decimal, except that no leading '+' will be used. String Return the input argument (no conversion) integer_constant Return the string containing the decimal representation of the input argument in the form of signed_decimal except that no leading '+' will be used. string_literal Return the input argument (no conversion) char_constant Return the string of length one containing the value of the input argument. ToBoolean The operator ToBoolean converts its argument to a value of type Integer according to the following table: Integer The result is 0 if the argument is 0. Otherwise the result is 1. String The results is 0 if the argument is the empty string. Otherwise the result is 1. integer_constant The result is 0 if the argument is 0. Otherwise the result is 1. string_literal The result is 0 if the argument is the empty string. Otherwise the result is 1. char_constant The result is 1. Operators The rules below specify the type conversion rules for the various operators. A++: A = ToInteger(A); A++; A--: A = ToInteger(A); A--; ++A: A = ToInteger(A); ++A; --A: A = ToInteger(A); --A; +A: ToInteger(A); -A: -1 * ToInteger(A); ~A: ToInteger(A); !A: !ToBoolean(A); A * B, A - B, A & B, A ^ B , A | B, A << B, A >> B: ToInteger(A) ToInteger(B) Waldbusser, et al. Standards Track [Page 21] RFC 4011 Policy Based Management MIB March 2005 A / B, A % B: if (ToInteger(B) == 0) RTE, terminate; else ToInteger(A) ToInteger(B) A + B: if (Type(A) == String || Type(B) == String) ToString(A) concatenated with ToString(B) else A + B Compound Assignment (=): Simply follow rules above. Note that type of LHS (Left Hand Side) may be changed as a result. A < B, A > B, A <= B, A >= B, A == B, A != B: if (Type(A) == String && Type(B) == String) lexically compare strings with strcmp() logic else ToInteger(A) ToInteger(B) A && B: if (ToBoolean(A)) ToBoolean(B); else false; A || B: if (ToBoolean(A)) true; else ToBoolean(B); if(A): if (ToBoolean(A)) while(A): while(ToBoolean(A)) for(...; A; ...): for(...; ToBoolean(A); ...) A[B] as a RHS (Right Hand Side) value: if (Type(A) != String || ToInteger(B) >= strlen(A)) RTE, terminate; A[ ToInteger(B) ] The contents are returned as a string of length one A[B] = C as a LHS value: if (Type(A) != String || ToInteger(B) >= strlen(A)) Waldbusser, et al. Standards Track [Page 22] RFC 4011 Policy Based Management MIB March 2005 RTE, terminate; if (strlen(ToString(C)) == 0) RTE, terminate A[ ToInteger(B) ] = First octet of ToString(C) Note that this is only applicable in a simple assignment. For example, in the expression "getVar("ifSpeed.1") < 128000" getVar always returns a string and '128000' is implicitly an integer. The rules for '<' dictate that if either argument is an integer then a 'numeric less than' is performed on ToInteger(A) and ToInteger(B). If "getVar("ifSpeed.1")" returns "64000", the expression can be translated to: ToInteger("64000") < ToInteger(128000); or, 64000 < 128000; or, True 5.3. PolicyScript QuickStart Guide PolicyScript is designed so that programmers fluent in other languages can quickly begin to write scripts. One way to become familiar with a language is to see it in action. The following nonsensical script exercises most of the PolicyScript constructs (though it skips some usage options and many arithmetic operators). var x, index = 7, str = "Hello World", oid = "ifSpeed."; x = 0; while(x < 10){ if (str < "Goodbye") /* string comparison */ continue; else break; x++; } if (oidlen(oid) == 10) oid += "." + index; // append index to oid for(x = 0; x < 7; x++){ str += "a"; Waldbusser, et al. Standards Track [Page 23] RFC 4011 Policy Based Management MIB March 2005 var y = 12; index = ((x * 7) + y) % 3; if (str[6] == 'W') return index; } return; The following examples are more practical: For a condition: // Return 1 if this is an interface and it is tagged // with the role "gold" return (inSubtree(elementName(), "ifEntry") && roleMatch("gold")) A condition/action pair: First, register the Host Resources MIB hrSWRunEntry as a new element in the pmElementTypeRegTable. This will cause the policy to run for every process on the system. The token '$*' will be replaced by the script interpreter with a process index (see Section 7 for a definition of the '$*' token). The condition: // if it's a process and it's an application and it's // consumed more than 5 minutes of CPU time return (inSubtree(elementName(), "hrSWRunEntry") && getVar("hrSWRunType.$*") == 4 // app, not OS or driver && getVar("hrSWRunPerfCPU.$*") > 30000) // 300 seconds The action: // Kill it setVar("hrSWRunStatus.$*", 4, Integer); // invalid(4) kills it A more substantial action to start an RMON2 host table on interfaces that match the condition: var pdu, index; pdu = newPDU(); writeVar(pdu, 0, "hlHostControlDataSource.*", "ifIndex." + ev(0), Oid); writeVar(pdu, 1, "hlHostControlNlMaxDesiredEntries.*", 1000, Integer); writeVar(pdu, 2, "hlHostControlAlMaxDesiredEntries.*", 1000, Integer); writeVar(pdu, 3, "hlHostControlOwner.*", "policy", String); Waldbusser, et al. Standards Track [Page 24] RFC 4011 Policy Based Management MIB March 2005 writeVar(pdu, 4, "hlHostControlStatus.*", "active(1)", Integer); if (createRow(pdu, 5, 4, 20, 65535, index) == 0 || index == -1) return; Because PolicyScript is a least common denominator, it contains nothing that would astonish programmers familiar with C, C++, Perl, Tcl, JavaScript, or Python. Although a new programmer may attempt to use language constructs that aren't available in PolicyScript, s/he should be able to understand any existing PolicyScript and will likely know how to use anything that is valid in PolicyScript. The lists below quickly enumerate the changes of note for programmers coming from some particular languages. These lists won't describe the unavailable constructs, but it is easy to see from the definition above what is available. 5.3.1. Quickstart for C Programmers - Character constants (i.e., 'c') are treated as one-character strings, not as integers. So operations such as ('M' - 'A') or (x + 'A') will not perform as expected. - Functions can change the value of arguments even though they are not pointers (or called like '&arg'). - All variables are in the same scope. 5.3.2. Quickstart for Perl Programmers - Comments are '/* comment */' and '// till end of line', not '#'. - No need to put a '$' in front of variables. - Strings are compared with ==, <=, <, etc. (details in Sec. 6.2.1). - Strings are concatenated with '+' (details in Sec. 6.2.1). - No variable substitution in "" strings. '' strings are 1 char only. - Variables must be declared before use (but no type is necessary). - All variables are in the same scope. 5.3.3. Quickstart for TCL Programmers - Comments are '/* comment */' and '// till end of line', not '#'. - No need to put a '$' in front of variables. - Function calls are func-name(arg1, arg2, ...). - Square braces [] don't interpret their contents. - Double quotes "" surround a string, but no substitutions are performed ("" is like { } in TCL ). - Statements are terminated by a semicolon (;). - Instead of "Set a b", use "b = a;". - Strings are concatenated with '+' (details in Sec. 6.2.1). - All variables are in the same scope. Waldbusser, et al. Standards Track [Page 25] RFC 4011 Policy Based Management MIB March 2005 5.3.4. Quickstart for Python Programmers - Comments are '/* comment */' and '// till end of line', not '#'. - Single quotes can be used only for single-character strings ('a'). - Indentation doesn't matter. Braces { } define blocks. - Variables must be declared before use (but no type is necessary). - The expressions for if and while are always surrounded by parenthesis, as in "if (x < 5)". - 'for' syntax is "for(expression; expression; expression)" (see EBNF). - All variables are in the same scope. 5.3.5. Quickstart for JavaScript/ECMAScript/JScript Programmers - Variables must be declared before use. - Functions can change the value of arguments. - All variables are in the same scope. 5.4. PolicyScript Script Return Values A PolicyScript script execution is normally ended by the execution of a return statement, or by having the flow of execution reach the end of the final statement in the script. A normal script execution always returns a Boolean value. If no explicit value is specified in the return statement, or if the flow of control proceeds through the end of the script, the return value is implicitly zero. If an expression is provided with the return statement, the expression is evaluated, and the result of the expression is implicitly converted with the ToBoolean operator before being returned to the script execution environment. The return value of a policyCondition script is used to determine whether the associated policyAction script is executed. If the returned value is zero, the associated policyAction script is not executed. If the returned value is one, the associated policyAction script will be executed. The return value of a policyAction script is ignored. An RTE or invocation of the fail() function will cause the return value of the script to be set to zero. Note however, that execution of the defer() or fail() functions may set the defer attribute so that the lower precedence script may be executed. This is independent of the return value of the policy script execution. Waldbusser, et al. Standards Track [Page 26] RFC 4011 Policy Based Management MIB March 2005 6. Index Information for 'this element' PolicyScript code needs a convenient way to get the components of the index for 'this element' so that they can perform SNMP operations on it or on related elements. Two mechanisms are provided. 1. For all OID input parameters to all SNMP Library Functions (but not OID utility functions), the token "$n" ('$' followed by an integer between 0 and 128) can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the nth subid of the index for the current element. For example, if the element is interface 7, and the objectIdentifier is "1.3.6.1.2.1.2.2.1.3.$0", it will be expanded to "1.3.6.1.2.1.2.2.1.3.7". The special token "$*" is expanded to contain all of the subidentifiers of the index of the current element, separated by '.' characters. It is an RTE if a token is specified that is beyond the length of the index for the current element. Note that the "$n" convention is only active within strings. 2. The ec() and ev() functions allow access to the components of the index for 'this element'. ec() takes no argument and returns the number of index components that exist. ev() takes an integer argument specifying which component of the index (numbered starting at 0) and returns an integer containing the value of the n'th subidentifier. Refer to the Library functions section for the complete definition of ec() and ev(). For example, if 'this element' is frCircuitDLCI.5.57 (ifIndex = 5, DLCI = 57) then ec() returns 2 ev(0) returns 5 ev(1) returns 57 This is helpful when one wishes to address a related element. Extending the previous example, to find the port speed of the port, the circuit (above) runs over: portSpeed = getVar("ifSpeed." + ev(0)); A script may check the type of 'this element' by calling the elementName() function. Although it is possible to write a script that will work with different types of elements, many scripts will Waldbusser, et al. Standards Track [Page 27] RFC 4011 Policy Based Management MIB March 2005 assume a particular element type and will work incorrectly if used on different element types. 7. Library Functions Library functions are built-in functions available primarily to provide access to information on the local system or to manipulate this information more efficiently. A group of functions is organized into a library, the unit of conformance for function implementation. In order to claim conformance to a library, an implementation must implement all functions in a library to the specifications of the library. In order for a management station or a condition or action to understand whether a certain library of functions is implemented, each library will have a name that it registers in the role table as a characteristic of the system element ("0.0") in the default SNMP context. Thus, conformance to a library can be tested with the roleMatch library function (in the base library) with the call roleMatch ("libraryName", "0.0"). Note that in the descriptions of these functions below, the function prototype describes the type of argument expected. Even though variables are not declared with a particular type, their contents must be appropriate for each function argument. If the type is variable, the keyword 'var' will be used. If only a string is appropriate, the keyword 'string' will be used. If only an integer is appropriate, the keyword 'integer' will be used. If the argument is declared as 'string' or 'integer' and a value of a different type is passed, the argument will be coerced with ToInteger() or ToString(). Any failure of this coercion will cause an RTE (in particular for ToInteger(), which will fail if its string-valued argument is not a well-formed integer). In the function prototype, if the '&' character precedes the identifier for an argument, that argument may be modified by the function (e.g., "integer &result, ...)"). Arguments without the '&' character cannot be modified by the function. In a script, modifiable arguments don't have to be preceded by a '&'. It is an RTE if a constant is passed to a modifiable function argument (regardless of whether the function actually writes to the argument). In the function prototype, the '[' and ']' characters surround arguments that are optional. In PolicyScript code, the optional argument may only be included if all optional arguments to the left of it are included. The function may place restrictions on when an optional argument must, or must not, be included. Waldbusser, et al. Standards Track [Page 28] RFC 4011 Policy Based Management MIB March 2005 In the function prototype, if a type is listed before the name of the function, the function returns a value of that type. If no type is listed, the function returns no value. 8. Base Function Library A standard base library of functions is available to all systems that implement this specification. This library is registered with the name "pmBaseFunctionLibrary". Although the specification of this library is modularized into 4 separate sections, conformance to the library requires implementation of all functions in all sections. The sections are: - SNMP library functions - Policy library functions - Utility functions - Library Functions 8.1. SNMP Library Functions Two sets of SNMP Library functions are available with different situations in mind: - Convenience SNMP Functions In an effort to keep simple things simple, these functions are easy to use and code that is easy to understand. These functions will suffice for the majority of situations, where a single variable is referenced and the desired error recovery is simply (and immediately) to give up (and move to the next policy-element combination). In more complex cases, the General SNMP Functions can be used at the cost of several times the code complexity. The convenience SNMP functions are getVar, exists, setVar, setRowStatus, createRow, counterRate, and searchColumn. - General SNMP Functions The General SNMP functions allow nearly any legal SNMP Message to be generated, including those with multiple varbinds, getNext operations, notifications, and messages with explicit addressing or security specifications. The general SNMP functions are writeVar, readVar, snmpSend, readError, and writeBulkParameters. Waldbusser, et al. Standards Track [Page 29] RFC 4011 Policy Based Management MIB March 2005 8.1.1. SNMP Operations on Non-Local Systems From time to time, a script may have to perform an operation on a different SNMP system than that on which 'this element' resides. Scripts may also have to specify the use of alternate security parameters. In order to do this, the following optional arguments are provided for the SNMP library functions: snmp-function(...[, integer mPModel, string tDomain, string tAddress, integer secModel, string secName, integer secLevel, string contextEngineID ]) For example: getVar("sysDescr.0", "", SNMPv3, "transportDomainUdpIpv4", "192.168.1.1:161", USM, "joe", NoAuthNoPriv); The use of these arguments is denoted in function definitions by the keyword 'NonLocalArgs'. The definitions of these arguments are as follows: 'mPModel' is the integer value of the SnmpMessageProcessingModel to use for this operation. 'tDomain' is a string containing an ASCII dotted-decimal object identifier representing the transport domain to use for this operation. 'tAddress' is a string containing the transport address formatted according to the 'tDomain' argument. The ASCII formats for various values of 'tDomain' are defined by the DISPLAY-HINT for a TEXTUAL-CONVENTION that represents an address of that type. The DISPLAY-HINTs used are: tDomain Source of DISPLAY-HINT [5] [11] ------- ---------------------- transportDomainUdpIpv4 TransportAddressIPv4 transportDomainUdpIpv6 TransportAddressIPv6 transportDomainUdpDns TransportAddressDns snmpCLNSDomain snmpOSIAddress snmpCONSDomain snmpOSIAddress snmpDDPDomain snmpNBPAddress snmpIPXDomain snmpIPXAddress rfc1157Domain snmpUDPAddress Other Use DISPLAY-HINT "1x:" Waldbusser, et al. Standards Track [Page 30] RFC 4011 Policy Based Management MIB March 2005 'secModel' is the integer value of the SnmpSecurityModel to use for this operation. 'secName' is a string value representing the SnmpSecurityName to use for this operation. 'secLevel' is the integer value of the SnmpSecurityLevel to use for this operation. An SNMP operation will be sent to the target system by using security parameters retrieved from a local configuration datastore based on 'secModel', 'secName', and 'secLevel'. It is the responsibility of the agent to ensure that sensitive information in the local configuration datastore is used on behalf of the correct principals, as identified by the security credentials of the last entity to modify the pmPolicyAdminStatus for a policy. To illustrate how this must be configured, consider an example in which 'joe' installs a policy on 'PMAgent' that will periodically configure objects on 'TargetAgent' with the credentials of 'Operator'. The following conditions must be true for this policy to execute with the proper privileges: - 'Operator's security credentials for TargetAgent must be installed in PMAgent's local configuration datastore (e.g., usmUserTable [6]) indexed by TargetAgent's engineID and 'Operator'. - VACM [9] must be configured on PMAgent so that 'joe' has access to the above entry in the appropriate MIB for the local configuration datastore (e.g., usmUserTable). - 'joe' must be the last user to modify the pmPolicyAdminStatus object for the policy. See the Security Considerations section for more information. For convenience, constants for 'mPModel', 'secModel', and 'secLevel' are defined in the "Constants" section below. 'contextEngineID' is a string representing the contextEngineID of the SNMP entity targeted by this operation. It is encoded as a pair of hex digits (upper- and lowercase are valid) for each octet of the contextEngineID. If 'tDomain' and 'tAddress' are provided but 'contextEngineID' is not, then the operation will be directed to the SNMP entity reachable at 'tDomain' and 'tAddress'. In order for PolicyScript code to use any of these arguments, all optional arguments to the left must be included. 'mPModel', 'tDomain', 'tAddress', 'secModel', 'secName', and 'secLevel' must Waldbusser, et al. Standards Track [Page 31] RFC 4011 Policy Based Management MIB March 2005 be used as a group; if one is specified, they must all be. 'contextEngineID' may only be specified if all others are specified. Note that a function that uses NonLocalArgs must provide a parameter for the contextName that will be required when the NonLocalArgs are present. Many functions will have the following logic: ContextName NonLocalArgs Supplied Supplied No No Addressed to default context on local system. Yes No Addressed to named context on local system. Yes Yes Addressed to named context on potentially remote system. No Yes Not allowed. 8.1.2. Form of SNMP Values Many of the library functions have input or output parameters that may be one of the many SMI data types. The actual type is not encoded in the value but is specified elsewhere, possibly by nature of the situation in which it is used. The exact usage for input and output is as follows: Any Integer value (INTEGER, Integer32, Counter32, Counter64, Gauge32, Unsigned32, TimeTicks, Counter64): On input: An Integer or a String that can be successfully coerced to an Integer with the ToInteger() operator. It is an RTE if a string is passed that cannot be converted by ToInteger() into an integer. A string of the form enum_decimal: [ letter | digit | '-' ]* '(' decimal_constant ')' will also be accepted. In this case the sequence of characters before the parentheses and the parentheses themselves are completely ignored, and the decimal_constant inside the parentheses is converted. Thus, "frame-relay(32)" translates to the integer 32. Waldbusser, et al. Standards Track [Page 32] RFC 4011 Policy Based Management MIB March 2005 On output: An Integer containing the returned value. Octet String On input: Either a String or an Integer. If an Integer, it will be coerced to a String with the ToString() function. This string will be used as an unencoded representation of the octet string value. On output: A String containing the unencoded value of the octet string. Object Identifier On input and on output: A String containing a decimal ASCII encoded object identifier of the following form: oid: subid [ '.' subid ]* [ '.' ] subid: '0' | decimal_constant It is an RTE if an Object Identifier argument is not in the form above. Note that a trailing '.' is acceptable and will simply be ignored. (Note, however, that a trailing dot could cause a strncmp() comparison of two otherwise-identical OIDs to fail; instead, use oidncmp().) Note that ASCII descriptors (e.g., "ifIndex") are never used in these encodings "over the wire". They are never returned from library functions; nor are they ever accepted by them. NMS user interfaces are encouraged to allow humans to view object identifiers with ASCII descriptors, but they must translate those descriptors to dotted-decimal format before sending them in MIB objects to policy agents. Null On input: The input is ignored. On output: A zero length string. Waldbusser, et al. Standards Track [Page 33] RFC 4011 Policy Based Management MIB March 2005 8.1.3. Convenience SNMP Functions 8.1.3.1. getVar() The getVar() function is used to retrieve the value of an SNMP MIB object instance. string getVar(string oid [, string contextName, NonLocalArgs]) 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier (e.g., "1.3.6.1.2.1.1.1.0"). The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. The optional 'NonLocalArgs' provide addressing and security information to perform an SNMP operation on a system different from that of 'this element'. It is an RTE if the queried object identifier value does not exist. This function returns a string containing the returned value, encoded according to the returned type. Note that no actual SNMP PDU has to be generated and parsed when the policy MIB agent resides on the same system as the managed elements. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values, followed by the index in dotted-decimal form (e.g., "ifType.7"). 8.1.3.2. exists() The exists() function is used to verify the existence of an SNMP MIB object instance. integer exists(string oid [, string contextName, NonLocalArgs]) 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier (e.g., "1.3.6.1.2.1.1.1.0"). Waldbusser, et al. Standards Track [Page 34] RFC 4011 Policy Based Management MIB March 2005 The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. The optional 'NonLocalArgs' provide addressing and security information to perform an SNMP operation on a system different from that of 'this element'. This function returns the value 1 if the SNMP instance exists and 0 if it doesn't exist. Note that no actual SNMP PDU has to be generated and parsed when the policy MIB agent resides on the same system as the managed elements. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values, followed by the index in dotted-decimal form (e.g., "ifType.7"). 8.1.3.3. setVar() The setVar() function is used to set a MIB object instance to a certain value. The setVar() function is only valid in policyActions. setVar(string oid, var value, integer type [, string contextName, NonLocalArgs] ) 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier (e.g., "1.3.6.1.2.1.1.1.0"). 'value' is a string encoded in the format appropriate to the 'type' parameter. The agent will set the variable specified by 'oid' to the value specified by 'value'. 'type' will be the type of the 'value' parameter and will be set to one of the values for DataType Constants. The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero length string, the default context is used. The optional 'NonLocalArgs' provide addressing and security information to perform an SNMP operation on a system different from that of 'this element'. Note that no actual SNMP PDU has to be generated and parsed when the policy MIB agent resides on the same system as the managed elements. Waldbusser, et al. Standards Track [Page 35] RFC 4011 Policy Based Management MIB March 2005 It is an RTE if the set encounters any error. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values, followed by the index in dotted-decimal form (e.g., "ifType.7"). 8.1.3.4. searchColumn() integer searchColumn(string columnoid, string &oid, string pattern, integer mode [, string contextName, NonLocalArgs]) searchColumn performs an SNMP walk on a portion of the MIB searching for objects with values equal to the 'pattern' parameter. 'columnoid' constrains the search to those variables that share the same OID prefix (i.e., those that are beneath it in the OID tree). A getnext request will be sent requesting the object identifier 'oid'. If 'oid' is an empty string, the value of 'columnoid' will be sent. The value returned in each response packet will be transformed to a string representation of the value of the returned variable. The string representation of the value will be formed by putting the value in the form dictated by the "Form of SNMP Values" rules, and then by performing the ToString() function on this value, forming 'SearchString'. The 'mode' value controls what type of match to perform on this 'SearchString' value. There are 6 possibilities for mode: Mode Search Action ExactMatch Case sensitive exact match of 'pattern' and 'SearchString'. ExactCaseMatch Case insensitive exact match of 'pattern' and 'SearchString'. SubstringMatch Case sensitive substring match, finding 'pattern' in 'SearchString'. SubstringCaseMatch Case insensitive substring match, finding 'pattern' in 'SearchString'. RegexpMatch Case sensitive regular expression match, searching 'SearchString' for the regular expression given in 'pattern'. Waldbusser, et al. Standards Track [Page 36] RFC 4011 Policy Based Management MIB March 2005 RegexpCaseMatch Case insensitive regular expression match, searching 'SearchString' for the regular expression given in 'pattern'. Constants for the values of 'mode' are defined in the 'Constants' section below. searchColumn uses the POSIX extended regular expressions defined in POSIX 1003.2. The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. The optional 'NonLocalArgs' provide addressing and security information to perform SNMP operations on a system different from that of 'this element'. If a match is found, 'oid' is set to the OID of the matched value, and 1 is returned. If the search traverses beyond columnoid or returns an error without finding a match, zero is returned, and 'oid' isn't modified. To find the first match, the caller should set 'oid' to the empty string. To find additional matches, subsequent calls to searchColumn should have 'oid' set to the OID of the last match, an operation that searchColumn performs automatically. For example: To find an ethernet interface oid = ""; searchColumn("ifType", oid, "6", 0); This sends a getnext request for ifType and continues to walk the tree until a value matching 6 is found or a variable returns that is not in the 'ifType' subtree. To find the next ethernet interface, assuming that interface 3 was discovered to be the first: oid = "ifType.3"; searchColumn("ifType", oid, "6", 0); Waldbusser, et al. Standards Track [Page 37] RFC 4011 Policy Based Management MIB March 2005 In a loop to determine all the ethernet interfaces, this looks as follows: oid = ""; while(searchColumn("ifType", oid, "6", 0)){ /* Do something with oid */ } Note that in the preceding examples, "ifType" is used as a notational convenience, and the actual code downloaded to the policy MIB agent must use the string "1.3.6.1.2.1.2.2.1.3" as there may be no MIB compiler (or MIB file) available on the policy MIB agent. Note that if the value of 'columnoid' is too short and thus references too much of the object identifier tree (e.g., "1.3.6"), 'columnoid' could end up searching a huge number of variables (if the value was "1.3.6", it would search ALL variables on the agent). It is the responsibility of the caller to make sure that 'columnoid' is set appropriately. 8.1.3.5. setRowStatus() integer setRowStatus(string oid, integer maxTries [, integer freeOnException , integer seed , string contextName, NonLocalArgs]) setRowStatus is used to automate the process of finding an unused row in a read-create table that uses RowStatus whose index contains an arbitrary integer component for uniqueness. 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier, with one of the subids replaced with a '*' character (e.g., "1.3.6.1.3.1.99.1.2.1.9.*"). 'oid' must reference an 'instance' of the RowStatus object, and the '*' must replace any integer index item that may be set to some random value. setRowStatus will come up with a number for the selected index item and will attempt to create the instance with the createAndWait state. If the attempt fails, it will retry with a different random index value. It will attempt this no more than 'maxTries' times. If the optional 'freeOnException' argument is present and equal to 1, the agent will free this row by setting RowStatus to 'destroy' if, later in the same script invocation, this script Waldbusser, et al. Standards Track [Page 38] RFC 4011 Policy Based Management MIB March 2005 dies with a run-time exception or by a call to fail(). Note that this does not apply to exceptions experienced in subsequent invocations of the script. If the optional 'seed' argument is present, the initial index will be set to 'seed'. Otherwise it will be random. 'seed' may not be present if the 'freeOnException' argument is not present. The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. The optional 'NonLocalArgs' provide addressing and security information to perform an SNMP operation on a system different from that of 'this element'. setRowStatus returns the successful integer value for the index. If it is unsuccessful after 'maxTries', or if zero or more than one '*' is in OID, -1 will be returned. The createRow function (below) can also be used when adding rows to tables. Although createRow has more functionality, setRowStatus may be preferable in certain situations (for example, to have the opportunity to inspect default values created by the agent). 8.1.3.6. createRow() integer createRow(integer reqPDU, integer reqNumVarbinds, integer statusColumn, integer maxTries, integer indexRange, integer &respPDU, integer &respNumVarbinds, integer &index [, integer freeOnException, string contextName, NonLocalArgs]) createRow is used to automate the process of creating a row in a read-create table whose index contains an arbitrary integer component for uniqueness. In particular, it encapsulates the algorithm behind either the createAndWait or createAndGo mechanism and the algorithm for finding an unused row in the table. createRow is not useful for creating rows in tables whose indexes don't contain an arbitrary integer component. createRow will perform the operation by sending 'reqPDU' and returning the results in 'respPDU'. Both 'reqPDU' and Waldbusser, et al. Standards Track [Page 39] RFC 4011 Policy Based Management MIB March 2005 'respPDU' must previously have been allocated with newPDU. 'reqPDU' and 'respPDU' may both contain the same PDU handle, in which case the 'reqPDU' is sent and then replaced with the contents of the received PDU. 'reqNumVarbinds' is an integer greater than zero that specifies which varbinds in the PDU will be used in this operation. The first 'reqNumVarbinds' in the PDU are used. Each such varbind must be of a special form in which the object name must have one of its subids replaced with a '*' character (e.g., "1.3.6.1.3.1.99.1.2.1.9.*"). The subid selected to be replaced will be an integer index item that may be set to some random value. The same subid should be selected in each varbind in the PDU. 'respNumVarbinds' will be modified to contain the number of varbinds received in the last response PDU. 'statusColumn' identifies which varbind in 'pdu' should be treated as the RowStatus column, where 0 identifies the 1st varbind. createRow will come up with a random integer index value and will substitute that value in place of the '*' subid in each varbind. It will then set the value of the RowStatus column to select the 'createAndGo' mechanism and execute the set. If the attempt fails due to the unavailability of the 'createAndGo' mechanism, it will retry with the 'createAndWait' mechanism selected. If the attempt fails because the chosen index value is already in use, the operation will be retried with a different random index value. It will continue to retry different index values until it succeeds, until it has made 'maxTries' attempts, or until it encounters an error. The value of 'maxTries' should be chosen to be high enough to minimize the chance that as the table fills up an attempt to create a new entry will 'collide' too often and fail. All random index values must be between 1 and 'indexRange', inclusive. This is so that values are not attempted for an index that fall outside of that index's restricted range (e.g., 1..65535). If the optional 'freeOnException' argument is present and equal to 1, the agent will free this row by setting RowStatus to 'destroy' if, later in the same script invocation, this script dies with a run-time exception or by a call to fail(). Note that this does not apply to exceptions experienced in subsequent invocations of the script. Waldbusser, et al. Standards Track [Page 40] RFC 4011 Policy Based Management MIB March 2005 The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. The optional 'NonLocalArgs' provide addressing and security information to perform an SNMP operation on a system different from that of 'this element'. Note that no actual SNMP PDU has to be generated and parsed when the policy MIB agent resides on the same system as the managed elements. If no PDU is generated, the agent must correctly simulate the behavior of the SNMP Response PDU, particularly in case of an error. This function returns zero unless an error occurs, in which case it returns the proper SNMP Error Constant. If an error occurred, respPDU will contain the last response PDU as received from the agent unless no response PDU was received, in which case respNumVarbinds will be 0. In any event, readError may be called on the PDU to determine error information for the transaction. The 'index' parameter returns the chosen index. If successful, 'index' will be set to the successful integer index. If no SNMP error occurs but the operation does not succeed due to the following reasons, 'index' will be set to -1: 1) Unsuccessful after 'maxTries'. 2) An object name had no '*' in it. 3) An object name had more than one '*' in it. For example, createRow() might be used as follows: var index, pdu = newPDU(), nVars = 0; writeVar(pdu, nVars++, "hlHostControlDataSource.*", "ifIndex." + ev(0), Oid); writeVar(pdu, nVars++, "hlHostControlNlMaxDesiredEntries.*", 1000, Integer); writeVar(pdu, nVars++, "hlHostControlAlMaxDesiredEntries.*", 1000, Integer); writeVar(pdu, nVars++, "hlHostControlOwner.*", "policy", String); writeVar(pdu, nVars++, "hlHostControlStatus.*", "active(1)", Integer); if (createRow(pdu, nVars, 4, 20, 65535, pdu, nVars, index) != 0 Waldbusser, et al. Standards Track [Page 41] RFC 4011 Policy Based Management MIB March 2005 || index == -1) return; // index now contains index of new row 8.1.3.7. counterRate() When a policy wishes to make a decision based on the rate of a counter, it faces a couple of problems: 1. It may have to run every X minutes but have to make decisions on rates calculated over at least Y minutes, where Y > X. This would require the complexity of managing a queue of old counter values. 2. The policy script has no control over exactly when it will run. The counterRate() function is designed to surmount these problems easily. integer counterRate(string oid, integer minInterval [, integer 64bit, string discOid, integer discMethod, string contextName, NonLocalArgs]) 'counterRate' retrieves the variable specified by oid once per invocation. It keeps track of timestamped values retrieved on previous invocations by this execution context so that it can calculate a rate over a period longer than that since the last invocation. 'oid' is the object identifier of the counter value that will be retrieved. The most recent previously saved value of the same object identifier that is at least 'minInterval' seconds old will be subtracted from the newly retrieved value, yielding a delta. If 'minInterval' is zero, this delta will be returned. Otherwise, this delta will be divided by the number of seconds elapsed between the two retrievals, and the integer-valued result will be returned (rounding down when necessary). If there was no previously saved retrieval older than 'minInterval' seconds, then -1 will be returned. It is an RTE if the query returns noSuchName, noSuchInstance, or noSuchObject or an object that is not of type Counter32 or Counter64. Waldbusser, et al. Standards Track [Page 42] RFC 4011 Policy Based Management MIB March 2005 The delta calculation will allow for 32-bit counter semantics if it encounters rollover between the two retrievals, unless the optional argument '64bit' is present and equal to 1, in which case it will allow for 64-bit counter semantics. 'discOid' and 'discMethod' may only be present together. 'discOid' contains an object identifier of a discontinuity indicator value that will be retrieved simultaneously with each counter value: 1. If 'discMethod' is equal to 1 and the discontinuity indicator is less than the last one retrieved, then a discontinuity is indicated. 2. If 'discMethod' is equal to 2 and the discontinuity indicated is different from the last one retrieved, then a discontinuity is indicated. If this value indicates a discontinuity, this counter value (and its timestamp) will be stored, but all previously stored counter values will be invalidated and -1 will be returned. The implementation will have to store a number of timestamped counter values. The implementation must keep all values that are newer than minInterval seconds, plus the newest value that is older than minInterval seconds. Other than this one value that is older than minInterval seconds, the implementation should discard any older values. For example: Policy that executes every 60 seconds: rate = counterRate("ifInOctets.$*", 300); if (rate > 1000000) ... Another example, with a discontinuity indicator: Policy that executes every 60 seconds: rate = counterRate("ifInOctets.$*", 300, 0, "sysUpTime.0", 1); if (rate > 1000000) ... Another example, with zero minInterval: Policy that executes every 60 seconds: delta = counterRate("ifInErrors.$*", 0); if (delta > 100) ... Waldbusser, et al. Standards Track [Page 43] RFC 4011 Policy Based Management MIB March 2005 The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. 8.1.4. General SNMP Functions It is desirable that a general SNMP interface have the ability to perform SNMP operations on multiple variables at once and that it allow multiple varbind lists to exist at once. The newPdu, readVar, and writeVar functions exist to provide these facilities in a language without pointers, arrays, and memory allocators. newPDU is called to allocate a PDU and return an integer handle to it. As PDUs are automatically freed when the script exits and can be reused during execution, there is no freePDU(). readVar and writeVar access a variable length varbind list for a PDU. The PDU handle and the index of the variable within that PDU are specified in every readVar and writeVar operation. Once a PDU has been fully specified by one or more calls to writeVar, it is passed to snmpSend (by referencing the PDU handle) and the number of varbinds to be included in the operation. When a response is returned, the contents of the response are returned in another PDU and may be read by one or more calls to readVar. Error information may be read from the PDU with the readError function. Because GetBulk PDUs send additional information in the SNMP header, the writeBulkParameters function is provided to configure these parameters. Varbinds in this data store are created automatically whenever they are written by any writeVar or snmpSend operation. For example: var pdu = newPDU(); var nVars = 0, oid, type, value; writeVar(pdu, nVars++, "sysDescr.0", "", Null); writeVar(pdu, nVars++, "sysOID.0", "", Null); writeVar(pdu, nVars++, "ifNumber.0", "", Null); if (snmpSend(pdu, nVars, Get, pdu, nVars)) return; readVar(pdu, 0, oid, value, type); readVar(pdu, 1, oid, value, type); readVar(pdu, 2, oid, value, type); ... Waldbusser, et al. Standards Track [Page 44] RFC 4011 Policy Based Management MIB March 2005 or, var pdu = newPDU(); var nVars = 0, oid1, oid2; writeVar(pdu, nVars++, "ifIndex", "", Null); writeVar(pdu, nVars++, "ifType", "", Null); while(!done){ if (snmpSend(pdu, nVars, Getnext, pdu, nVars)) continue; readVar(pdu, 0, oid1, value, type); readVar(pdu, 1, oid2, value, type); /* leave OIDs alone, now PDU #0 is set up for next step in table walk. */ if (oidncmp(oid1, "ifIndex", oidlen("ifIndex"))) done = 0; ... } Note that in the preceding examples, descriptors such as ifType and sysDescr are used in object identifiers solely as a notational convenience. The actual code downloaded to the policy MIB agent must use a dotted decimal notation only, as there may be no MIB compiler (or MIB file) available on the policy MIB agent. To conform to this specification, implementations must allow each policy script invocation to allocate at least 5 PDUs with at least 64 varbinds per list. It is suggested that implementations limit the total number of PDUs per invocation to protect other script invocations from a malfunctioning script (e.g., a script that calls newPDU() in a loop). 8.1.4.1. newPDU() integer newPDU() newPDU will allocate a new PDU and return a handle to the PDU. If no PDU could be allocated, -1 will be returned. The PDU's initial values of nonRepeaters and maxRepetitions will be zero. 8.1.4.2. writeVar() writeVar(integer pdu, integer varBindIndex, string oid, var value, integer type) writeVar will store 'oid', 'value', and 'type' in the specified varbind. 'pdu' is the handle to a PDU allocated by newPDU(). Waldbusser, et al. Standards Track [Page 45] RFC 4011 Policy Based Management MIB March 2005 'varBindIndex' is a non-negative integer that identifies the varbind within the specified PDU modified by this call. The first varbind is number 0. 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier (e.g., "1.3.6.1.2.1.1.1.0"). 'value' is the value to be stored, of a type appropriate to the 'type' parameter. 'type' will be the type of the value parameter and will be set to one of the values for DataType Constants. It is an RTE if any of the parameters don't conform to the rules above. 8.1.4.3. readVar() readVar(integer pdu, integer varBindIndex, string &oid, var &value, integer &type) readVar will retrieve the oid, the value, and its type from the specified varbind. 'pdu' is the handle to a PDU allocated by newPDU(). 'varBindIndex' is a non-negative integer that identifies the varbind within the specified PDU read by this call. The first varbind is number 0. The object identifier value of the referenced varbind will be copied into the 'oid' parameter, formatted in an ASCII dotted- decimal representation (e.g., "1.3.6.1.2.1.1.1.0"). 'value' is the value retrieved, of a type appropriate to the 'type' parameter. 'type' is the type of the value parameter and will be set to one of the values for DataType Constants. It is an RTE if 'pdu' doesn't reference a valid PDU or 'varBindIndex' doesn't reference a valid varbind. Waldbusser, et al. Standards Track [Page 46] RFC 4011 Policy Based Management MIB March 2005 8.1.4.4. snmpSend() integer snmpSend(integer reqPDU, integer reqNumVarbinds, integer opcode, integer &respPDU, integer &respNumVarbinds, [, string contextName , NonLocalArgs] ) snmpSend will perform an SNMP operation by sending 'reqPDU' and returning the results in 'respPDU'. Both 'reqPDU' and 'respPDU' must previously have been allocated with newPDU. 'reqPDU' and 'respPDU' may both contain the same PDU handle, in which case the 'reqPDU' is sent and then replaced with the contents of the received PDU. If the opcode specifies a Trap or V2trap, 'respPDU' will not be modified. 'reqNumVarbinds' is an integer greater than zero that specifies which varbinds in the PDU will be used in this operation. The first 'reqNumVarbinds' in the PDU are used. 'respNumVarbinds' will be modified to contain the number of varbinds received in the response PDU, which, in the case of GetBulk or an error, may be substantially different from reqNumVarbinds. 'opcode' is the type of SNMP operation to perform and must be one of the values for SNMP Operation Constants listed in the 'Constants' section below. The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. Note that no actual SNMP PDU has to be generated and parsed when the policy MIB agent resides on the same system as the managed elements. If no PDU is generated, the agent must correctly simulate the behavior of the SNMP Response PDU, particularly in case of an error. This function returns zero unless an error occurs, in which case it returns the proper SNMP Error Constant. If an error occurred, respPDU will contain the response PDU as received from the agent, unless no response PDU was received, in which case respNumVarbinds will be 0. In any event, readError may be called on the PDU to determine error information for the transaction. If an SNMP Version 1 trap is requested (the opcode is Trap(4)), then SNMP Version 2 trap parameters are supplied and converted according to the rules of RFC 3584 [8], section 3.2. The first Waldbusser, et al. Standards Track [Page 47] RFC 4011 Policy Based Management MIB March 2005 variable binding must be sysUpTime.0, and the second must be snmpTrapOID.0, as per RFC 3416 [7], section 4.2.6. Subsequent variable bindings are copied to the SNMP Version 1 trap PDU in the usual fashion. 8.1.4.5. readError() readError(integer pdu, integer numVarbinds, integer &errorStatus, integer &errorIndex, integer &hasException) Returns the error information in a PDU. 'errorStatus' contains the error-status field from the response PDU or a local error constant if the error was generated locally. If no error was experienced or no PDU was ever copied into this PDU, this value will be 0. 'errorIndex' contains the error-index field from the response PDU. If no PDU was ever copied into this PDU, this value will be 0. 'hasException' will be 1 if any of the first 'numVarbinds' varbinds in the PDU contain an exception (Nosuchobject, Nosuchinstance, Endofmibview); otherwise it will be 0. It is an RTE if 'pdu' does not reference a valid PDU or if 'numVarbinds' references varbinds that aren't valid. 8.1.4.6. writeBulkParameters() writeBulkParameters(integer pdu, integer nonRepeaters, integer maxRepetitions) Modifies the parameters in a PDU in any subsequent GetBulk operation sent by the PDU. 'nonRepeaters' will be copied into the PDU's non-repeaters field, and 'maxRepetitions' into the max-repetitions field. This function may be called before or after writeVar is called to add varbinds to the PDU, but it must be called before the PDU is sent; otherwise, it will have no effect. A new PDU is initialized with nonRepeaters set to zero and maxRepetitions set to zero. If a Bulk PDU is sent before writeBulkParameters is called, these default values will be used. If writeBulkParameters is called to modify a PDU, it is acceptable if this PDU is later sent as a type other than bulk. The writeBulkParameters call will only affect subsequent sends of Bulk PDUs. If a PDU is used to receive the contents of a Waldbusser, et al. Standards Track [Page 48] RFC 4011 Policy Based Management MIB March 2005 response, the values of nonRepeaters and maxRepetitions are never modified. 8.1.5. Constants for SNMP Library Functions The following constants are defined for use with all SNMP Library Functions. Policy code will be executed in an environment where the following constants are declared. (Note that the constant declarations below will not be visible in the policyCondition or policyAction code.) These constants are reserved words and cannot be used for any variable or function name. Although these declarations are expressed here as C 'const's, the 'const' construct itself is not available to be used in policy code. // Datatype Constants // From RFC 2578 [2] const integer Integer = 2; const integer Integer32 = 2; const integer String = 4; const integer Bits = 4; const integer Null = 5; const integer Oid = 6; const integer IpAddress = 64; const integer Counter32 = 65; const integer Gauge32 = 66; const integer Unsigned32 = 66; const integer TimeTicks = 67; const integer Opaque = 68; const integer Counter64 = 70; // SNMP Exceptions from RFC 3416 [7] const integer NoSuchObject = 128; const integer NoSuchInstance = 129; const integer EndOfMibView = 130; // SNMP Error Constants from RFC 3416 [7] const integer NoError = 0; const integer TooBig = 1; const integer NoSuchName = 2; const integer BadValue = 3; const integer ReadOnly = 4; const integer GenErr = 5; const integer NoAccess = 6; const integer WrongType = 7; const integer WrongLength = 8; const integer WrongEncoding = 9; Waldbusser, et al. Standards Track [Page 49] RFC 4011 Policy Based Management MIB March 2005 const integer WrongValue = 10; const integer NoCreation = 11; const integer InconsistentValue = 12; const integer ResourceUnavailable = 13; const integer CommitFailed = 14; const integer UndoFailed = 15; const integer AuthorizationError = 16; const integer NotWritable = 17; const integer InconsistentName = 18; // "Local" Errors // These are also possible choices for errorStatus returns // For example: unknown PDU, maxVarbinds is bigger than number // written with writeVar, unknown opcode, etc. const integer BadParameter = 1000; // Request would have created a PDU larger than local limitations const integer TooLong = 1001; // A response to the request was received but errors were encountered // when parsing it. const integer ParseError = 1002; // Local system has complained of an authentication failure const integer AuthFailure = 1003; // No valid response was received in a timely fashion const integer TimedOut = 1004; // General local failure including lack of resources const integer GeneralFailure = 1005; // SNMP Operation Constants from RFC 3416 [7] const integer Get = 0; const integer Getnext = 1; const integer Set = 3; const integer Trap = 4; const integer Getbulk = 5; const integer Inform = 6; const integer V2trap = 7; // Constants from RFC 3411 [1] for SnmpMessageProcessingModel const integer SNMPv1 = 0; const integer SNMPv2c = 1; const integer SNMPv3 = 3; Waldbusser, et al. Standards Track [Page 50] RFC 4011 Policy Based Management MIB March 2005 // Constants from RFC 3411 [1] for SnmpSecurityModel const integer SNMPv1 = 1; const integer SNMPv2c = 2; const integer USM = 3; // SnmpSecurityLevel Constants from RFC 3411 [1] const integer NoAuthNoPriv = 1; const integer AuthNoPriv = 2; const integer AuthPriv = 3; // Constants for use with searchColumn const integer ExactMatch = 0; const integer ExactCaseMatch = 1; const integer SubstringMatch = 2; const integer SubstringCaseMatch = 3; const integer RegexpMatch = 4; const integer RegexpCaseMatch = 5; 8.2. Policy Library Functions Policy Library Functions provide access to information specifically related to the execution of policies. 8.2.1. elementName() The elementName() function is used to determine what the current element is and can be used to provide information about the type of element and how it is indexed. string elementName() elementName returns a string containing an ASCII dotted-decimal representation of an object identifier (e.g., 1.3.6.1.2.1.1.1.0). This object identifier identifies an instance of a MIB object that is an attribute of 'this element'. 8.2.2. elementAddress() elementAddress(&tDomain, &tAddress) elementAddress finds a domain/address pair that can be used to access 'this element' and returns the values in 'tDomain' and 'tAddress'. Waldbusser, et al. Standards Track [Page 51] RFC 4011 Policy Based Management MIB March 2005 8.2.3. elementContext() string elementContext() elementContext() returns a string containing the SNMP contextName of 'this element'. 8.2.4. ec() The ec() (element count) and ev() (element value) functions provide convenient access to the components of the index for 'this element'. Typical uses will be in creating the index to other, related elements. integer ec() ec() returns an integer count of the number of index subidentifiers that exist in the index for 'this element'. 8.2.5. ev() integer ev(integer n) ev() returns the value of the nth subidentifier in the index for 'this element'. The first subidentifier is indexed at 0. It is an RTE if n specifies a subidentifier beyond the last subidentifier. 8.2.6. roleMatch() The roleMatch() function is used to check whether an element has been assigned a particular role. integer roleMatch(string roleString [, string element, string contextName, string contextEngineID]) 'roleString' is a string. The optional argument 'element' contains the OID name of an element, defaulting to the current element if 'element' is not supplied. If roleString exactly matches (content and length) any role assigned to the specified element, the function returns 1. If no roles match, the function returns 0. The optional 'contextName' argument contains the SNMP context on which to operate. If 'contextName' is not present, the contextName of 'this element' will be used. If 'contextName' is the zero-length string, the default context is used. Waldbusser, et al. Standards Track [Page 52] RFC 4011 Policy Based Management MIB March 2005 'contextEngineID' contains the contextEngineID of the remote system on which 'element' resides. It is encoded as a pair of hex digits (upper- and lowercase are valid) for each octet of the contextEngineID. If 'contextEngineID' is not present, the contextEngineID of 'this element' will be used. 'contextEngineID' may only be present if the 'element' and 'context' arguments are present. 8.2.7. Scratchpad Functions Every maxLatency time period, every policy runs once for each element. When the setScratchpad function executes, it stores a value named by a string that can be retrieved with getScratchpad() even after this policy execution code exits. This allows sharing of data between a condition and an action, two conditions executing on different elements, or even different policies altogether. The value of 'scope' controls which policy/element combinations can retrieve this 'varName'/'value' pair. The following are options for 'scope': Global The 'varName'/'value' combination will be available in the condition or action of any policy while it is executing on any element. Note that any information placed here will be visible to all other scripts on this system regardless of their authority. Sensitive information should not be placed in global scratchpad variables. Policy The 'varName'/'value' combination will be available in any future execution of the condition or action of the current policy (regardless of what element the policy is executing on). If a policy is ever deleted, or if its condition or action code is modified, all values in its 'Policy' scope will be deleted. PolicyElement The 'varName'/'value' combination will be available in future executions of the condition or action of the current policy, but only when the policy is executing on the current element. If a policy is ever deleted, or if its condition or action code is modified, all values in its 'PolicyElement' scope will be deleted. The agent may also periodically delete values in a 'PolicyElement' scope if the corresponding element does not exist (in other words, if an element disappears for a period and reappears, values in its 'PolicyElement' scope may or may not be deleted). Waldbusser, et al. Standards Track [Page 53] RFC 4011 Policy Based Management MIB March 2005 setScratchpad's 'storageType' argument allows the script to control the lifetime of a variable stored in the scratchpad. If the storageType is equal to the constant 'volatile', then this variable must be deleted on a reboot. If it is equal to 'nonVolatile', then this variable should be stored in non-volatile storage, where it will be available after a reboot. If the 'storageType' argument is not present, the variable will be volatile and will be erased on reboot. If the optional 'freeOnException' argument is present and equal to 1, the agent will free this variable if, later in the same script invocation, this script dies with a run-time exception or by a call to fail(). (Note that this does not apply to exceptions experienced in subsequent invocations of the script.) Note that there may be implementation-specific limits on the number of scratchpad variables that can be allocated. The limit of unique scratchpad variables may be different for each scope or storageType. It is suggested that implementations limit the total number of scratchpad variables per script to protect other scripts from a malfunctioning script. In addition, compliant implementations must support at least 50 Global variables, 5 Policy variables per policy, and 5 PolicyElement variables per policy-element pair. Scratchpad Usage Examples Policy Element Action A ifIndex.1 setScratchpad(Global, "foo", "55") A ifIndex.1 getScratchpad(Global, "foo", val) --> 55 A ifIndex.2 getScratchpad(Global, "foo", val) --> 55 B ifIndex.2 getScratchpad(Global, "foo", val) --> 55 B ifIndex.2 setScratchpad(Global, "foo", "16") A ifIndex.1 getScratchpad(Global, "foo", val) --> 16 Policy Element Action A ifIndex.1 setScratchpad(Policy, "bar", "75") A ifIndex.1 getScratchpad(Policy, "bar", val) --> 75 A ifIndex.2 getScratchpad(Policy, "bar", val) --> 75 B ifIndex.1 getScratchpad(Policy, "bar", val) not found B ifIndex.1 setScratchpad(Policy, "bar", "20") A ifIndex.2 getScratchpad(Policy, "bar", val) --> 75 B ifIndex.2 getScratchpad(Policy, "bar", val) --> 20 Policy Element Action A ifIndex.1 setScratchpad(PolicyElement, "baz", "43") A ifIndex.1 getScratchpad(PolicyElement, "baz", val) --> 43 A ifIndex.2 getScratchpad(PolicyElement, "baz", val) not found B ifIndex.1 getScratchpad(PolicyElement, "baz", val) not found A ifIndex.2 setScratchpad(PolicyElement, "baz", "54") Waldbusser, et al. Standards Track [Page 54] RFC 4011 Policy Based Management MIB March 2005 B ifIndex.1 setScratchpad(PolicyElement, "baz", "65") A ifIndex.1 getScratchpad(PolicyElement, "baz", val) --> 43 A ifIndex.2 getScratchpad(PolicyElement, "baz", val) --> 54 B ifIndex.1 getScratchpad(PolicyElement, "baz", val) --> 65 Policy Element Action A ifIndex.1 setScratchpad(PolicyElement, "foo", "11") A ifIndex.1 setScratchpad(Global, "foo", "22") A ifIndex.1 getScratchpad(PolicyElement, "foo", val) --> 11 A ifIndex.1 getScratchpad(Global, "foo", val) --> 22 Constants The following constants are defined for use with the scratchpad functions. Policy code will be executed in an environment where the following constants are declared. (Note that these constant declarations will not be visible in the policyCondition or policyAction MIB objects.) Although these declarations are expressed here as C 'const's, the 'const' construct itself is not available to be used inside of policy code. // Scratchpad Constants // Values of scope const integer Global = 0; const integer Policy = 1; const integer PolicyElement = 2; // Values of storageType const integer Volatile = 0; const integer NonVolatile = 1; 8.2.8. setScratchpad() setScratchpad(integer scope, string varName [, string value, integer storageType, integer freeOnException ]) The setScratchpad function stores a value that can be retrieved even after this policy execution code exits. The value of 'scope' controls which policy/element combinations can retrieve this 'varName'/'value' pair. The options for 'scope' are Global, Policy, and PolicyElement. Waldbusser, et al. Standards Track [Page 55] RFC 4011 Policy Based Management MIB March 2005 'varName' is a string used to identify the value. Subsequent retrievals of the same 'varName' in the proper scope will return the value stored. Note that the namespace for 'varName' is distinct for each scope. 'varName' is case sensitive. 'value' is a string containing the value to be stored. ToString(value) is called on 'value' to convert it to a string before storage. If the 'value' argument is missing, the 'varName' in scope 'scope' will be deleted if it exists. If the optional 'storageType' argument is present and is equal to the constant 'Volatile', then this variable must be deleted on a reboot. If it is equal to 'NonVolatile', then this variable should be stored in non-volatile storage, where it will be available after a reboot. If the 'storageType' argument is not present, the variable will be volatile and will be erased on reboot. 'storageType' may not be present if the 'value' argument is not present. If the variable already existed, its previous storageType is updated according to the current 'storageType' argument. If the optional 'freeOnException' argument is present and equal to 1, the agent will free this variable if, later in the same script invocation, this script dies with a run-time exception or by a call to fail(). (Note that this does not apply to exceptions experienced in subsequent invocations of the script.) 8.2.9. getScratchpad() integer getScratchpad(integer scope, string varName, string &value) The getScratchpad function allows the retrieval of values that were stored previously in this execution context or in other execution contexts. The value of 'scope' controls which execution contexts can pass a value to this execution context. The options for 'scope' are Global, Policy, and PolicyElement. 'varName' is a string used to identify the value. Subsequent retrievals of the same 'varName' in the proper scope will return the value stored. Note that the namespace for varName is distinct for each scope. As a result, getScratchpad cannot force access to a variable in an inaccessible scope; it can only retrieve variables by referencing the proper scope in which they were set. 'varName' is case sensitive. Waldbusser, et al. Standards Track [Page 56] RFC 4011 Policy Based Management MIB March 2005 On successful return, 'value' will be set to the value that was previously stored; otherwise, 'value' will not be modified. This function returns 1 if a value was previously stored and 0 otherwise. 8.2.10. signalError() The signalError() function is used by the script to indicate to a management station that it is experiencing abnormal behavior. signalError() turns on the conditionUserSignal(3) or actionUserSignal(5) bit in the associated pmTrackingPEInfo object (subsequent calls to signalError() have no additional effect). This bit is initially cleared at the beginning of each execution. If, upon a subsequent execution, the script finishes without calling signalError, the bit will be cleared. signalError() The signalException function takes no arguments and returns no value. 8.2.11. defer() Precedence groups enforce the rule that for each element, of the ready policies that match the condition, only the one with the highest precedence value will be active. Unfortunately, once the winning policy has been selected and the action begins running, situations can occur in which the policy script determines that it cannot complete its task. In many such cases, it is desirable that the next runner-up ready policy be executed. In the previous example, it would be desirable that at least bronze behavior be configured if gold is appropriate but gold isn't possible. When a policy defers, it exits, and the ready, condition-matching policy with the next-highest precedence is immediately run. Because this might also defer, the execution environment must remember where it is in the precedence chain so that it can continue going down the chain until an action completes without deferring, or until no policies are left in the precedence group. Once a policy finishes successfully, the next iteration will begin at the top of the precedence chain. There are two ways to defer. A script can exit by calling fail() and specify that it should defer immediately. Alternately, a script can instruct the execution environment to defer automatically in the event of a run-time exception. Waldbusser, et al. Standards Track [Page 57] RFC 4011 Policy Based Management MIB March 2005 defer(integer deferOnRTE) The defer function changes the run-time exception behavior of a script. By default, a script will not defer when it encounters an RTE. If defer(1) is called, the exit behavior is changed so that the script will defer when it is terminated due to an RTE. If defer(0) is called, the script is reset to its default behavior and will not defer. Note that calling defer doesn't cause the script to exit. Defer only changes the default behavior if an RTE occurs later in this invocation. 8.2.12. fail() fail(integer defer, integer free [, string message] ) The fail function causes the script to optionally perform certain functions and then exit. If 'defer' is 1, this script will defer to the next lower precedence ready policy in the same precedence group whose condition matches. If 'defer' isn't 1, it will not defer. Note that if a condition defers, it is functionally equivalent to the condition returning false. If 'free' is 1, certain registered resources will be freed. If, earlier in this script invocation, any rows were created by createRow with the 'freeOnException' option, the execution environment will set the RowStatus of each row to 'destroy' to delete the row. Further, if earlier in this script invocation any scratchpad variables were created or modified with the 'freeOnException' option, they will be deleted. If the optional 'message' argument is present, it will be logged to the debugging table if pmPolicyDebugging is turned on for this policy. This function does not return. Instead, the script will terminate. 8.2.13. getParameters() From time to time, policy scripts may be parameterized so that they are supplied with one or more parameters (e.g., site-specific constants). These parameters may be installed in the pmPolicyParameters object and are accessible to the script via the getParameters() function. If it is necessary for multiple parameters Waldbusser, et al. Standards Track [Page 58] RFC 4011 Policy Based Management MIB March 2005 to be passed to the script, the script can choose whatever encoding/delimiting mechanism is most appropriate so that the multiple parameters can be stored in the associated instance of pmPolicyParameters. string getParameters() The getParameters function takes no arguments. It returns a string containing the value of the pmPolicyParameters object for the running policy. For example, if a policy is to apply to "slow speed interfaces" and the cutoff point for slow speed should be parameterized, the policy filter should be: getVar("ifSpeed.$*") == getParameters() In this example, one can store the string "128000" in the policy's pmPolicyParameters object to cause this policy to act on all 128 Kbps interfaces. 8.3. Utility Library Functions Utility Library Functions are provided to enable more efficient policy scripts. 8.3.1. regexp() integer regexp(string pattern, string str, integer case [, string &match]) regexp searches 'str' for matches to the regular expression given in `pattern`. regexp uses the POSIX extended regular expressions defined in POSIX 1003.2. If `case` is 0, the search will be case insensitive; otherwise, it will be case sensitive. If a match is found, 1 is returned, otherwise 0 is returned. If the optional argument 'match' is provided and a match is found, 'match' will be replaced with the text of the first substring of 'str' that matches 'pattern'. If no match is found, it will be unchanged. Waldbusser, et al. Standards Track [Page 59] RFC 4011 Policy Based Management MIB March 2005 8.3.2. regexpReplace() string regexpReplace(string pattern, string replacement, string str, integer case) regexpReplace searches 'str' for matches to the regular expression given in 'pattern', replacing each occurrence of matched text with 'replacement'. regexpReplace uses the POSIX extended regular expressions defined in POSIX 1003.2. If `case` is 0, the search will be case insensitive; otherwise, it will be case sensitive. The modified string is returned (it would be the same as the original string if no matches were found). 8.3.3. oidlen() integer oidlen(string oid) oidlen returns the number of subidentifiers in 'oid'. 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier (e.g., "1.3.6.1.2.1.1.1.0"). 8.3.4. oidncmp() integer oidncmp(string oid1, string oid2, integer n) Arguments 'oid1' and 'oid2' are strings containing ASCII dotted-decimal representations of object identifiers (e.g., "1.3.6.1.2.1.1.1.0"). oidcmp compares not more than n subidentifiers of 'oid1' and 'oid2' and returns -1 if 'oid1' is less than 'oid2', 0 if they are equal, and 1 if 'oid1' is greater than 'oid2'. 8.3.5. inSubtree() integer inSubtree(string oid, string prefix) Arguments 'oid' and 'prefix' are strings containing ASCII dotted-decimal representations of object identifiers (e.g., "1.3.6.1.2.1.1.1.0"). inSubtree returns 1 if every subidentifier in 'prefix' equals the corresponding subidentifier in 'oid', otherwise it returns 0. The is equivalent to oidncmp(oid1, prefix, oidlen(prefix)) Waldbusser, et al. Standards Track [Page 60] RFC 4011 Policy Based Management MIB March 2005 is provided because this is an idiom and because it avoids evaluating 'prefix' twice if it is an expression. 8.3.6. subid() integer subid(string oid, integer n) subid returns the value of the nth (starting at zero) subidentifier of 'oid'. 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier (e.g., "1.3.6.1.2.1.1.1.0"). If n specifies a subidentifier beyond the length of 'oid', a value of -1 is returned. 8.3.7. subidWrite() integer subidWrite(string oid, integer n, integer subid) subidWrite sets the value of the nth (starting at zero) subidentifier of 'oid' to 'subid'. 'oid' is a string containing an ASCII dotted-decimal representation of an object identifier (e.g., "1.3.6.1.2.1.1.1.0"). If n specifies a subidentifier beyond the length of 'oid', a value of -1 is returned. Note that appending subidentifiers can be accomplished with the string concatenation '+' operator. If no error occurs, zero is returned. 8.3.8. oidSplice() string oidSplice(string oid1, integer offset, integer len, string oid2) oidSplice returns an OID formed by replacing 'len' subidentifiers in 'oid1' with all of the subidentifiers from 'oid2', starting at 'offset' in 'oid1' (the first subidentifier is at offset 0). The OID length will be extended, if necessary, if 'offset' + 'len' extends beyond the end of 'oid1'. If 'offset' is larger than the length of oid1, then an RTE will occur. The resulting OID is returned. For example: oidSplice("1.3.6.1.2.1", 5, 1, "7") => "1.3.6.1.2.7" oidSplice("1.3.6.1.2.1", 4, 2, "7.7") => "1.3.6.1.7.7" oidSplice("1.3.6.1.2.1", 4, 3, "7.7.7") => "1.3.6.1.7.7.7" Waldbusser, et al. Standards Track [Page 61] RFC 4011 Policy Based Management MIB March 2005 8.3.9. parseIndex() ParseIndex is provided to make it easy to pull index values from OIDs into variables. var parseIndex(string oid, integer &index, integer type, integer len) parseIndex pulls values from the instance identification portion of 'oid', encoded as per Section 7.7, "Mapping of the INDEX Clause", of the SMIv2 [2]. 'oid' is the OID to be parsed. 'index' describes which subid to begin parsing at. 'index' will be modified to indicate the subid after the last one parsed (even if this points past the last subid). The first subid is index 0. If any error occurs, 'index' will be set to -1 on return. If the input index is less than 0 or refers past the end of the OID, 'index' will be set to -1 on return and the function will return 0. If 'type' is Integer, 'len' will not be consulted. The return value is the integer value of the next subid. If 'type' is String and 'len' is greater than zero, 'len' subids will be parsed. For each subid parsed, the chr() value of the subid will be appended to the returned string. If any subid is greater than 255, 'index' will be set to -1 on return, and an empty string will be returned. If there are fewer than 'len' subids left in 'oid', 'index' will be set to -1 on return, but a string will be returned containing a character for each subid that was left. If 'type' is String and 'len' is zero, the next subid will be parsed to find N, the length of the string. Then, that many subids will be parsed. For each subid parsed, the chr() value of the subid will be appended to the returned string. If any subid is greater than 255, 'index' will be set to -1 on return, and an empty string will be returned. If there are fewer than N subids left in 'oid', 'index' will be set to -1 on return, but a string will be returned containing a character for each subid that was left. If 'type' is String and 'len' is -1, subids will be parsed until the end of 'oid'. For each subid parsed, the chr() value of the subid will be appended to the returned string. If any Waldbusser, et al. Standards Track [Page 62] RFC 4011 Policy Based Management MIB March 2005 subid is greater than 255, 'index' will be set to -1 on return, and an empty string will be returned. If 'type' is Oid and 'len' is greater than zero, 'len' subids will be parsed. For each subid parsed, the decimal-encoded value of the subid will be appended to the returned string, with a '.' character appended between each output subid, but not after the last subid. If there are fewer than 'len' subids left in 'oid', 'index' will be set to -1 on return, but a string will be returned containing an encoding for each subid that was left. If 'type' is Oid and 'len' is zero, the next subid will be parsed to find N, the number of subids to parse. For each subid parsed, the decimal-encoded value of the subid will be appended to the returned string, with a '.' character appended between each output subid but not after the last subid. If there are fewer than N subids left in 'oid', 'index' will be set to -1 on return, but a string will be returned containing an encoding for each subid that was left. If 'type' is Oid and 'len' is -1, subids will be parsed until the end of 'oid'. For each subid parsed, the decimal-encoded value of the subid will be appended to the returned string, with a '.' character appended between each output subid, but not after the last subid. For example, to decode the index component of an instance of the ipForward table: oid = "ipForwardIfIndex.0.0.0.0.13.0.192.168.1.1"; index = 11; dest = parseIndex(oid, index, String, 4); proto = parseIndex(oid, index, Integer, 0); policy = parseIndex(oid, index, Integer, 0); nextHop = parseIndex(oid, index, String, 4); // proto and policy now contain integer values // dest and nextHop now contain 4 byte IP addresses. Use // stringToDotted to get them to dotted decimal notation: // e.g.: stringToDotted(nextHop) => "192.168.1.1" 8.3.10. stringToDotted() stringToDotted() is provided to encode strings suitable for the index portion of an OID or to convert the binary encoding of an IP address to a dotted-decimal encoding. Waldbusser, et al. Standards Track [Page 63] RFC 4011 Policy Based Management MIB March 2005 string stringToDotted(string value) If 'value' is the zero-length string, the zero-length string is returned. The decimal encoding of the first byte of 'value' is appended to the output string. Then, for each additional byte in 'value', a '.' is appended to the output string, followed by the decimal encoding of the additional byte. 8.3.11. integer() integer integer(var input) integer converts 'input' into an integer by using the rules specified for ToInteger(), returning the integer-typed results. 8.3.12. string() string string(var input) string converts 'input' into a string by using the rules specified for ToString(), returning the string-typed results. 8.3.13. type() string type(var variable) type returns the type of its argument as either the string 'String' or the string 'Integer'. 8.3.14. chr() string chr(integer char) Returns a one-character string containing the character specified by the ASCII code contained in 'char'. 8.3.15. ord() integer ord(string str) Returns the ASCII value of the first character of 'str'. This function complements chr(). Waldbusser, et al. Standards Track [Page 64] RFC 4011 Policy Based Management MIB March 2005 8.3.16. substr() string substr(string &str, integer offset [, integer len, string replacement]) Extracts a substring out of 'str' and returns it. The first octet is at offset 0. If the offset is negative, the returned string starts that far from the end of 'str'. If 'len' is positive, the returned string contains up to 'len' octets, up to the end of the string. If 'len' is omitted, the returned string includes everything to the end of 'str'. If 'len' is negative, abs(len) octets are left off the end of the string. If a substring is specified that is partly outside the string, the part within the string is returned. If the substring is totally outside the string, a zero-length string is produced. If the optional 'replacement' argument is included, 'str' is modified. 'offset' and 'len' act as above to select a range of octets in 'str'. These octets are replaced with octets from 'replacement'. If the replacement string is shorter or longer than the number of octets selected, 'str' will shrink or grow, respectively. If 'replacement' is included, the 'len' argument must also be included. Note that to replace everything from offset to the end of the string, substr() should be called as follows: substr(str, offset, strlen(str) - offset, replacement) 8.4. General Functions The following POSIX standard library functions are provided: strncmp() strncasecmp() strlen() random() sprintf() sscanf() 9. International String Library This library is optional for systems that wish to have support for collating (sorting) and verifying equality of international strings in a manner that will be least surprising to humans. International Waldbusser, et al. Standards Track [Page 65] RFC 4011 Policy Based Management MIB March 2005 strings are encoded in the UTF-8 transformation format described in [14]. This library is registered with the name "pmInternationalStringLibrary". When verifying equality of international strings in the Unicode character set, it is recommended to normalize the strings with the stringprep() function before checking for equality. When attempting to sort international strings in the Unicode character set, normalization should also be performed, but note that the result is highly context dependent and hard to implement correctly. Just ordering by Unicode Codepoint Value is in many cases not what the end user expects. See Unicode technical note 9 for more information about sorting. 9.1. stringprep() integer stringprep(string utf8Input, string &utf8Output) Performs the Stringprep [13] transformation for appropriate comparison of internationalized strings. The transformation is performed on 'utf8Input'; if the transformation finishes without error, the resulting string is written to utf8Output. The stringprep profile used is specified below in Section 9. If it is successful, the function returns 1. If the stringprep transformation encounters an error, 0 is returned, and the utf8Output parameter remains unchanged. For example, to compare UTF8 strings 'one' and 'two': if (stringprep(one, a) && stringprep(two, b)){ if (a == b){ // strings are identical } else { // strings are different } } else { // strings couldn't be transformed for comparison } See Stringprep [13] for more information. 9.1.1. Stringprep Profile The Stringprep specification [13] describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical Waldbusser, et al. Standards Track [Page 66] RFC 4011 Policy Based Management MIB March 2005 users throughout the world. Specifications that specify stringprep (as this one does) are required to fully specify stringprep's processing options by documenting a stringprep profile. This profile defines the following, as required by Stringprep: - The intended applicability of the profile: internationalized network management information. - The character repertoire that is the input and output to stringprep: Unicode 3.2, as defined in Stringprep [13], Appendix A.1. - The mapping tables used: Table B.1 from Stringprep [13]. - Any additional mapping tables specific to the profile: None. - The Unicode normalization used: Form KC, as described in Stringprep [13]. - The characters that are prohibited as output: As specified in the following tables from Stringprep [13]: Table C.2 Table C.3 Table C.4 Table C.5 Table C.6 Table C.7 Table C.8 Table C.9 - Bidirectional character handling: not performed. - Any additional characters that are prohibited as output: None. 9.2. utf8Strlen() integer utf8Strlen(string str) Returns the number of UTF-8 characters in 'str', which may be less than the number of octets in 'str' if one or more characters are multi-byte characters. Waldbusser, et al. Standards Track [Page 67] RFC 4011 Policy Based Management MIB March 2005 9.3. utf8Chr() string utf8Chr(integer utf8) Returns a one-character string containing the character specified by the UTF-8 code contained in 'utf8'. Although it contains only 1 UTF-8 character, the resulting string may be more than 1 octet in length. 9.4. utf8Ord() integer utf8Ord(string str) Returns the UTF-8 code-point value of the first character of 'str'. Note that the first UTF-8 character in 'str' may be more than 1 octet in length. This function complements chr(). 9.5. utf8Substr() string utf8Substr(string &str, integer offset [, integer len, string replacement]) Extracts a substring out of 'str' and returns it, keeping track of UTF-8 character boundaries and using them, instead of octets, as the basis for offset and length calculations. The first character is at offset 0. If offset is negative, the returned string starts that far from the end of 'str'. If 'len' is positive, the returned string contains up to 'len' characters, up to the end of the string. If 'len' is omitted, the returned string includes everything to the end of 'str'. If 'len' is negative, abs(len) characters are left off the end of the string. If you specify a substring that is partly outside the string, the part within the string is returned. If the substring is totally outside the string, a zero-length string is produced. If the optional 'replacement' argument is included, 'str' is modified. 'offset' and 'len' act as above to select a range of characters in 'str'. These characters are replaced with characters from 'replacement'. If the replacement string is shorter or longer than the number of characters selected, 'str' will shrink or grow, respectively. If 'replacement' is included, the 'len' argument must also be included. Waldbusser, et al. Standards Track [Page 68] RFC 4011 Policy Based Management MIB March 2005 Note that to replace everything from offset to the end of the string, substr() should be called as follows: substr(str, offset, strlen(str) - offset, replacement) 10. Schedule Table This table is an adapted form of the policyTimePeriodCondition class defined in the Policy Core Information Model, RFC 3060 [18]. Some of the objects describing a schedule are expressed in formats defined in the iCalendar specification [15]. The policy schedule table allows control over when a valid policy will be ready, based on the date and time. A policy's pmPolicySchedule variable refers to a group of one or more schedules in the schedule table. At any given time, if any of these schedules are active, the policy will be ready (assuming that it is enabled and thus valid), and its conditions and actions will be executed, as appropriate. At times when none of these schedules are active, the policy will not be ready and will have no effect. A policy will always be ready if its pmPolicySchedule variable is 0. If a policy has a non-zero pmPolicySchedule that doesn't refer to a group that includes an active schedule, then the policy will not be ready, even if this is due to a misconfiguration of the pmPolicySchedule object or the pmSchedTable. A policy that is controlled by a schedule group immediately executes its policy condition (and conditionally the policyAction) when the schedule group becomes active, periodically re-executing these scripts as appropriate until the schedule group becomes inactive (i.e., all schedules are inactive). An individual schedule item is active at those times that match all the variables that define the schedule: pmSchedTimePeriod, pmSchedMonth, pmSchedDay, pmSchedWeekDay, and pmSchedTimeOfDay. It is possible to specify multiple values for each schedule item. This provides a mechanism for defining complex schedules. For example, a schedule that is active the entire workday each weekday could be defined. Months, days, and weekdays are specified by using the objects pmSchedMonth, pmSchedDay, and pmSchedWeekDay of type BITS. Setting multiple bits in these objects causes an OR operation. For example, setting the bits monday(1) and friday(5) in pmSchedWeekDay restricts the schedule to Mondays and Fridays. Waldbusser, et al. Standards Track [Page 69] RFC 4011 Policy Based Management MIB March 2005 The matched times for pmSchedTimePeriod, pmSchedMonth, pmSchedDay pmSchedWeekDay, and pmSchedTimeOfDay are ANDed together to determine the time periods when the schedule will be active; in other words, the schedule is only active for those times when ALL of these schedule attributes match. For example, a schedule with an overall validity range of January 1, 2000, through December 31, 2000; a month mask that selects March and April; a day-of-the-week mask that selects Fridays; and a time-of-day range of 0800 through 1600 would represent the following time periods: Friday, March 5, 2000, from 0800 through 1600 Friday, March 12, 2000, from 0800 through 1600 Friday, March 19, 2000, from 0800 through 1600 Friday, March 26, 2000, from 0800 through 1600 Friday, April 2, 2000, from 0800 through 1600 Friday, April 9, 2000, from 0800 through 1600 Friday, April 16, 2000, from 0800 through 1600 Friday, April 23, 2000, from 0800 through 1600 Friday, April 30, 2000, from 0800 through 1600 Wildcarding of schedule attributes of type BITS is achieved by setting all bits to one. It is possible to define schedules that will never cause a policy to be activated. For example, one can define a schedule that should be active on February 31st. 11. Definitions POLICY-BASED-MANAGEMENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Gauge32, Unsigned32, mib-2 FROM SNMPv2-SMI RowStatus, RowPointer, TEXTUAL-CONVENTION, DateAndTime, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- Policy-Based Management MIB pmMib MODULE-IDENTITY LAST-UPDATED "200502070000Z" -- February 7, 2005 ORGANIZATION "IETF SNMP Configuration Working Group" CONTACT-INFO " Waldbusser, et al. Standards Track [Page 70] RFC 4011 Policy Based Management MIB March 2005 Steve Waldbusser Phone: +1-650-948-6500 Fax: +1-650-745-0671 Email: waldbusser@nextbeacon.com Jon Saperia (WG Co-chair) JDS Consulting, Inc. 84 Kettell Plain Road. Stow MA 01775 USA Phone: +1-978-461-0249 Fax: +1-617-249-0874 Email: saperia@jdscons.com Thippanna Hongal Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA, 95054 USA Phone: +1-408-878-6562 Fax: +1-408-878-6501 Email: hongal@riverstonenet.com David Partain (WG Co-chair) Postal: Ericsson AB P.O. Box 1248 SE-581 12 Linkoping Sweden Tel: +46 13 28 41 44 E-mail: David.Partain@ericsson.com Any questions or comments about this document can also be directed to the working group at snmpconf@snmp.com." DESCRIPTION "The MIB module for policy-based configuration of SNMP infrastructures. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4011; see the RFC itself for full legal notices." REVISION "200502070000Z" -- February 7, 2005 DESCRIPTION "The original version of this MIB, published as RFC4011." ::= { mib-2 124 } Waldbusser, et al. Standards Track [Page 71] RFC 4011 Policy Based Management MIB March 2005 PmUTF8String ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An octet string containing information typically in human-readable form. To facilitate internationalization, this information is represented by using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in RFC 3629. As additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x10FFFF. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or that are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character/code point; thus, the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by Waldbusser, et al. Standards Track [Page 72] RFC 4011 Policy Based Management MIB March 2005 RFC 3416. Note that the size of PmUTF8String object is measured in octets, not characters." SYNTAX OCTET STRING (SIZE (0..65535)) -- The policy table pmPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The policy table. A policy is a pairing of a policyCondition and a policyAction that is used to apply the action to a selected set of elements." ::= { pmMib 1 } pmPolicyEntry OBJECT-TYPE SYNTAX PmPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the policy table representing one policy." INDEX { pmPolicyAdminGroup, pmPolicyIndex } ::= { pmPolicyTable 1 } PmPolicyEntry ::= SEQUENCE { pmPolicyAdminGroup PmUTF8String, pmPolicyIndex Unsigned32, pmPolicyPrecedenceGroup PmUTF8String, pmPolicyPrecedence Unsigned32, pmPolicySchedule Unsigned32, pmPolicyElementTypeFilter PmUTF8String, pmPolicyConditionScriptIndex Unsigned32, pmPolicyActionScriptIndex Unsigned32, pmPolicyParameters OCTET STRING, pmPolicyConditionMaxLatency Unsigned32, pmPolicyActionMaxLatency Unsigned32, pmPolicyMaxIterations Unsigned32, pmPolicyDescription PmUTF8String, pmPolicyMatches Gauge32, pmPolicyAbnormalTerminations Gauge32, pmPolicyExecutionErrors Counter32, pmPolicyDebugging INTEGER, pmPolicyAdminStatus INTEGER, pmPolicyStorageType StorageType, pmPolicyRowStatus RowStatus Waldbusser, et al. Standards Track [Page 73] RFC 4011 Policy Based Management MIB March 2005 } pmPolicyAdminGroup OBJECT-TYPE SYNTAX PmUTF8String (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An administratively assigned string that can be used to group policies for convenience, for readability, or to simplify configuration of access control. The value of this string does not affect policy processing in any way. If grouping is not desired or necessary, this object may be set to a zero-length string." ::= { pmPolicyEntry 1 } pmPolicyIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this policy entry, unique among all policies regardless of administrative group." ::= { pmPolicyEntry 2 } pmPolicyPrecedenceGroup OBJECT-TYPE SYNTAX PmUTF8String (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively assigned string that is used to group policies. For each element, only one policy in the same precedence group may be active on that element. If multiple policies would be active on an element (because their conditions return non-zero), the execution environment will only allow the policy with the highest value of pmPolicyPrecedence to be active. All values of this object must have been successfully transformed by Stringprep RFC 3454. Management stations must perform this translation and must only set this object to string values that have been transformed." ::= { pmPolicyEntry 3 } pmPolicyPrecedence OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current Waldbusser, et al. Standards Track [Page 74] RFC 4011 Policy Based Management MIB March 2005 DESCRIPTION "If, while checking to see which policy conditions match an element, 2 or more ready policies in the same precedence group match the same element, the pmPolicyPrecedence object provides the rule to arbitrate which single policy will be active on 'this element'. Of policies in the same precedence group, only the ready and matching policy with the highest precedence value (e.g., 2 is higher than 1) will have its policy action periodically executed on 'this element'. When a policy is active on an element but the condition ceases to match the element, its action (if currently running) will be allowed to finish and then the condition-matching ready policy with the next-highest precedence will immediately become active (and have its action run immediately). If the condition of a higher-precedence ready policy suddenly begins matching an element, the previously-active policy's action (if currently running) will be allowed to finish and then the higher precedence policy will immediately become active. Its action will run immediately, and any lower-precedence matching policy will not be active anymore. In the case where multiple ready policies share the highest value, it is an implementation-dependent matter as to which single policy action will be chosen. Note that if it is necessary to take certain actions after a policy is no longer active on an element, these actions should be included in a lower-precedence policy that is in the same precedence group." ::= { pmPolicyEntry 4 } pmPolicySchedule OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "This policy will be ready if any of the associated schedule entries are active. If the value of this object is 0, this policy is always ready. If the value of this object is non-zero but doesn't refer to a schedule group that includes an active schedule, then the policy will not be ready, even if this is due to a misconfiguration of this object or the pmSchedTable." ::= { pmPolicyEntry 5 } Waldbusser, et al. Standards Track [Page 75] RFC 4011 Policy Based Management MIB March 2005 pmPolicyElementTypeFilter OBJECT-TYPE SYNTAX PmUTF8String (SIZE (0..128)) MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the element types for which this policy can be executed. The format of this object will be a sequence of pmElementTypeRegOIDPrefix values, encoded in the following BNF form: elementTypeFilter: oid [ ';' oid ]* oid: subid [ '.' subid ]* subid: '0' | decimal_constant For example, to register for the policy to be run on all interface elements, the 'ifEntry' element type will be registered as '1.3.6.1.2.1.2.2.1'. If a value is included that does not represent a registered pmElementTypeRegOIDPrefix, then that value will be ignored." ::= { pmPolicyEntry 6 } pmPolicyConditionScriptIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the row or rows in the pmPolicyCodeTable that contain the condition code for this policy. When a policy entry is created, a pmPolicyCodeIndex value unused by this policy's adminGroup will be assigned to this object. A policy condition is one or more PolicyScript statements that result(s) in a boolean value that represents whether an element is a member of a set of elements upon which an action is to be performed. If a policy is ready and the condition returns true for an element of a proper element type, and if no higher-precedence policy should be active, then the policy is active on that element. Condition evaluation stops immediately when any run-time exception is detected, and the policyAction is not executed. The policyCondition is evaluated for various elements. Any element for which the policyCondition returns any nonzero value will match the condition and will have the associated Waldbusser, et al. Standards Track [Page 76] RFC 4011 Policy Based Management MIB March 2005 policyAction executed on that element unless a higher-precedence policy in the same precedence group also matches 'this element'. If the condition object is empty (contains no code) or otherwise does not return a value, the element will not be matched. When this condition is executed, if SNMP requests are made to the local system and secModel/secName/secLevel aren't specified, access to objects is under the security credentials of the requester who most recently modified the associated pmPolicyAdminStatus object. If SNMP requests are made in which secModel/secName/secLevel are specified, then the specified credentials are retrieved from the local configuration datastore only if VACM is configured to allow access to the requester who most recently modified the associated pmPolicyAdminStatus object. See the Security Considerations section for more information." ::= { pmPolicyEntry 7 } pmPolicyActionScriptIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the row or rows in the pmPolicyCodeTable that contain the action code for this policy. When a policy entry is created, a pmPolicyCodeIndex value unused by this policy's adminGroup will be assigned to this object. A PolicyAction is an operation performed on a set of elements for which the policy is active. Action evaluation stops immediately when any run-time exception is detected. When this condition is executed, if SNMP requests are made to the local system and secModel/secName/secLevel aren't specified, access to objects is under the security credentials of the requester who most recently modified the associated pmPolicyAdminStatus object. If SNMP requests are made in which secModel/secName/secLevel are specified, then the specified credentials are retrieved from the local configuration datastore only if VACM is configured to allow access to the requester who most recently modified the associated pmPolicyAdminStatus object. See the Security Considerations section for more information." Waldbusser, et al. Standards Track [Page 77] RFC 4011 Policy Based Management MIB March 2005 ::= { pmPolicyEntry 8 } pmPolicyParameters OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..65535)) MAX-ACCESS read-create STATUS current DESCRIPTION "From time to time, policy scripts may seek one or more parameters (e.g., site-specific constants). These parameters may be installed with the script in this object and are accessible to the script via the getParameters() function. If it is necessary for multiple parameters to be passed to the script, the script can choose whatever encoding/delimiting mechanism is most appropriate." ::= { pmPolicyEntry 9 } pmPolicyConditionMaxLatency OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Every element under the control of this agent is re-checked periodically to see whether it is under control of this policy by re-running the condition for this policy. This object lets the manager control the maximum amount of time that may pass before an element is re-checked. In other words, in any given interval of this duration, all elements must be re-checked. Note that how the policy agent schedules the checking of various elements within this interval is an implementation-dependent matter. Implementations may wish to re-run a condition more quickly if they note a change to the role strings for an element." ::= { pmPolicyEntry 10 } pmPolicyActionMaxLatency OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Every element that matches this policy's condition and is therefore under control of this policy will have this policy's action executed periodically to ensure that the element remains in the state dictated by the policy. This object lets the manager control the maximum amount of Waldbusser, et al. Standards Track [Page 78] RFC 4011 Policy Based Management MIB March 2005 time that may pass before an element has the action run on it. In other words, in any given interval of this duration, all elements under control of this policy must have the action run on them. Note that how the policy agent schedules the policy action on various elements within this interval is an implementation-dependent matter." ::= { pmPolicyEntry 11 } pmPolicyMaxIterations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "If a condition or action script iterates in loops too many times in one invocation, the execution environment may consider it in an infinite loop or otherwise not acting as intended and may be terminated by the execution environment. The execution environment will count the cumulative number of times all 'for' or 'while' loops iterated and will apply a threshold to determine when to terminate the script. What threshold the execution environment uses is an implementation-dependent manner, but the value of this object SHOULD be the basis for choosing the threshold for each script. The value of this object represents a policy-specific threshold and can be tuned for policies of varying workloads. If this value is zero, no threshold will be enforced except for any implementation-dependent maximum. Regardless of this value, the agent is allowed to terminate any script invocation that exceeds a local CPU or memory limitation. Note that the condition and action invocations are tracked separately." ::= { pmPolicyEntry 12 } pmPolicyDescription OBJECT-TYPE SYNTAX PmUTF8String MAX-ACCESS read-create STATUS current DESCRIPTION "A description of this rule and its significance, typically provided by a human." ::= { pmPolicyEntry 13 } pmPolicyMatches OBJECT-TYPE SYNTAX Gauge32 Waldbusser, et al. Standards Track [Page 79] RFC 4011 Policy Based Management MIB March 2005 UNITS "elements" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of elements that, in their most recent execution of the associated condition, were matched by the condition." ::= { pmPolicyEntry 14 } pmPolicyAbnormalTerminations OBJECT-TYPE SYNTAX Gauge32 UNITS "elements" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of elements that, in their most recent execution of the associated condition or action, have experienced a run-time exception and terminated abnormally. Note that if a policy was experiencing a run-time exception while processing a particular element but runs normally on a subsequent invocation, this number can decline." ::= { pmPolicyEntry 15 } pmPolicyExecutionErrors OBJECT-TYPE SYNTAX Counter32 UNITS "errors" MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times that execution of this policy's condition or action has been terminated due to run-time exceptions." ::= { pmPolicyEntry 16 } pmPolicyDebugging OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The status of debugging for this policy. If this is turned on(2), log entries will be created in the pmDebuggingTable for each run-time exception that is experienced by this policy." DEFVAL { off } ::= { pmPolicyEntry 17 } Waldbusser, et al. Standards Track [Page 80] RFC 4011 Policy Based Management MIB March 2005 pmPolicyAdminStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabled(2), enabledAutoRemove(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative status of this policy. The policy will be valid only if the associated pmPolicyRowStatus is set to active(1) and this object is set to enabled(2) or enabledAutoRemove(3). If this object is set to enabledAutoRemove(3), the next time the associated schedule moves from the active state to the inactive state, this policy will immediately be deleted, including any associated entries in the pmPolicyCodeTable. The following related objects may not be changed unless this object is set to disabled(1): pmPolicyPrecedenceGroup, pmPolicyPrecedence, pmPolicySchedule, pmPolicyElementTypeFilter, pmPolicyConditionScriptIndex, pmPolicyActionScriptIndex, pmPolicyParameters, and any pmPolicyCodeTable row referenced by this policy. In order to change any of these parameters, the policy must be moved to the disabled(1) state, changed, and then re-enabled. When this policy moves to either enabled state from the disabled state, any cached values of policy condition must be erased, and any Policy or PolicyElement scratchpad values for this policy should be removed. Policy execution will begin by testing the policy condition on all appropriate elements." ::= { pmPolicyEntry 18 } pmPolicyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this policy and any associated entries in the pmPolicyCodeTable are kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. Waldbusser, et al. Standards Track [Page 81] RFC 4011 Policy Based Management MIB March 2005 If the value of this object is 'permanent', the values for the associated pmPolicyAdminStatus object must remain writable." ::= { pmPolicyEntry 19 } pmPolicyRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status of this pmPolicyEntry. The status may not be set to active if any of the related entries in the pmPolicyCode table do not have a status of active or if any of the objects in this row are not set to valid values. Only the following objects may be modified while in the active state: pmPolicyParameters pmPolicyConditionMaxLatency pmPolicyActionMaxLatency pmPolicyDebugging pmPolicyAdminStatus If this row is deleted, any associated entries in the pmPolicyCodeTable will be deleted as well." ::= { pmPolicyEntry 20 } -- Policy Code Table pmPolicyCodeTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPolicyCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmPolicyCodeTable stores the code for policy conditions and actions. An example of the relationships between the code table and the policy table follows: pmPolicyTable AdminGroup Index ConditionScriptIndex ActionScriptIndex A '' 1 1 2 B 'oper' 1 1 2 C 'oper' 2 3 4 pmPolicyCodeTable AdminGroup ScriptIndex Segment Note Waldbusser, et al. Standards Track [Page 82] RFC 4011 Policy Based Management MIB March 2005 '' 1 1 Filter for policy A '' 2 1 Action for policy A 'oper' 1 1 Filter for policy B 'oper' 2 1 Action 1/2 for policy B 'oper' 2 2 Action 2/2 for policy B 'oper' 3 1 Filter for policy C 'oper' 4 1 Action for policy C In this example, there are 3 policies: 1 in the '' adminGroup, and 2 in the 'oper' adminGroup. Policy A has been assigned script indexes 1 and 2 (these script indexes are assigned out of a separate pool per adminGroup), with 1 code segment each for the filter and the action. Policy B has been assigned script indexes 1 and 2 (out of the pool for the 'oper' adminGroup). While the filter has 1 segment, the action is longer and is loaded into 2 segments. Finally, Policy C has been assigned script indexes 3 and 4, with 1 code segment each for the filter and the action." ::= { pmMib 2 } pmPolicyCodeEntry OBJECT-TYPE SYNTAX PmPolicyCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the policy code table representing one code segment. Entries that share a common AdminGroup/ScriptIndex pair make up a single script. Valid values of ScriptIndex are retrieved from pmPolicyConditionScriptIndex and pmPolicyActionScriptIndex after a pmPolicyEntry is created. Segments of code can then be written to this table with the learned ScriptIndex values. The StorageType of this entry is determined by the value of the associated pmPolicyStorageType. The pmPolicyAdminGroup element of the index represents the administrative group of the policy of which this code entry is a part." INDEX { pmPolicyAdminGroup, pmPolicyCodeScriptIndex, pmPolicyCodeSegment } ::= { pmPolicyCodeTable 1 } PmPolicyCodeEntry ::= SEQUENCE { pmPolicyCodeScriptIndex Unsigned32, pmPolicyCodeSegment Unsigned32, pmPolicyCodeText PmUTF8String, pmPolicyCodeStatus RowStatus Waldbusser, et al. Standards Track [Page 83] RFC 4011 Policy Based Management MIB March 2005 } pmPolicyCodeScriptIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for each policy condition or action. The code for each such condition or action may be composed of multiple entries in this table if the code cannot fit in one entry. Values of pmPolicyCodeScriptIndex may not be used unless they have previously been assigned in the pmPolicyConditionScriptIndex or pmPolicyActionScriptIndex objects." ::= { pmPolicyCodeEntry 1 } pmPolicyCodeSegment OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for each segment of a policy condition or action. When a policy condition or action spans multiple entries in this table, the code of that policy starts from the lowest-numbered segment and continues with increasing segment values until it ends with the highest-numbered segment." ::= { pmPolicyCodeEntry 2 } pmPolicyCodeText OBJECT-TYPE SYNTAX PmUTF8String (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "A segment of policy code (condition or action). Lengthy Policy conditions or actions may be stored in multiple segments in this table that share the same value of pmPolicyCodeScriptIndex. When multiple segments are used, it is recommended that each segment be as large as is practical. Entries in this table are associated with policies by values of the pmPolicyConditionScriptIndex and pmPolicyActionScriptIndex objects. If the status of the related policy is active, then this object may not be modified." ::= { pmPolicyCodeEntry 3 } Waldbusser, et al. Standards Track [Page 84] RFC 4011 Policy Based Management MIB March 2005 pmPolicyCodeStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this code entry. Entries in this table are associated with policies by values of the pmPolicyConditionScriptIndex and pmPolicyActionScriptIndex objects. If the status of the related policy is active, then this object can not be modified (i.e., deleted or set to notInService), nor may new entries be created. If the status of this object is active, no objects in this row may be modified." ::= { pmPolicyCodeEntry 4 } -- Element Type Registration Table pmElementTypeRegTable OBJECT-TYPE SYNTAX SEQUENCE OF PmElementTypeRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A registration table for element types managed by this system. The Element Type Registration table allows the manager to learn what element types are being managed by the system and to register new types, if necessary. An element type is registered by providing the OID of an SNMP object (i.e., without the instance). Each SNMP instance that exists under that object is a distinct element. The index of the element is the index part of the discovered OID. This index will be supplied to policy conditions and actions so that this code can inspect and configure the element. For example, this table might contain the following entries. The first three are agent-installed, and the 4th was downloaded by a management station: OIDPrefix MaxLatency Description StorageType ifEntry 100 mS interfaces - builtin readOnly 0.0 100 mS system element - builtin readOnly frCircuitEntry 100 mS FR Circuits - builtin readOnly hrSWRunEntry 60 sec Running Processes volatile Waldbusser, et al. Standards Track [Page 85] RFC 4011 Policy Based Management MIB March 2005 Note that agents may automatically configure elements in this table for frequently used element types (interfaces, circuits, etc.). In particular, it may configure elements for whom discovery is optimized in one or both of the following ways: 1. The agent may discover elements by scanning internal data structures as opposed to issuing local SNMP requests. It is possible to recreate the exact semantics described in this table even if local SNMP requests are not issued. 2. The agent may receive asynchronous notification of new elements (for example, 'card inserted') and use that information to instantly create elements rather than through polling. A similar feature might be available for the deletion of elements. Note that the disposition of agent-installed entries is described by the pmPolicyStorageType object." ::= { pmMib 3 } pmElementTypeRegEntry OBJECT-TYPE SYNTAX PmElementTypeRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A registration of an element type. Note that some values of this table's index may result in an instance name that exceeds a length of 128 sub-identifiers, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such values." INDEX { pmElementTypeRegOIDPrefix } ::= { pmElementTypeRegTable 1 } PmElementTypeRegEntry ::= SEQUENCE { pmElementTypeRegOIDPrefix OBJECT IDENTIFIER, pmElementTypeRegMaxLatency Unsigned32, pmElementTypeRegDescription PmUTF8String, pmElementTypeRegStorageType StorageType, pmElementTypeRegRowStatus RowStatus } pmElementTypeRegOIDPrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "This OBJECT IDENTIFIER value identifies a table in which all Waldbusser, et al. Standards Track [Page 86] RFC 4011 Policy Based Management MIB March 2005 elements of this type will be found. Every row in the referenced table will be treated as an element for the period of time that it remains in the table. The agent will then execute policy conditions and actions as appropriate on each of these elements. This object identifier value is specified down to the 'entry' component (e.g., ifEntry) of the identifier. The index of each discovered row will be passed to each invocation of the policy condition and policy action. The actual mechanism by which instances are discovered is implementation dependent. Periodic walks of the table to discover the rows in the table is one such mechanism. This mechanism has the advantage that it can be performed by an agent with no knowledge of the names, syntax, or semantics of the MIB objects in the table. This mechanism also serves as the reference design. Other implementation-dependent mechanisms may be implemented that are more efficient (perhaps because they are hard coded) or that don't require polling. These mechanisms must discover the same elements as would the table-walking reference design. This object can contain a OBJECT IDENTIFIER, '0.0'. '0.0' represents the single instance of the system itself and provides an execution context for policies to operate on the 'system element' and on MIB objects modeled as scalars. For example, '0.0' gives an execution context for policy-based selection of the operating system code version (likely modeled as a scalar MIB object). The element type '0.0' always exists; as a consequence, no actual discovery will take place, and the pmElementTypeRegMaxLatency object will have no effect for the '0.0' element type. However, if the '0.0' element type is not registered in the table, policies will not be executed on the '0.0' element. When a policy is invoked on behalf of a '0.0' entry in this table, the element name will be '0.0', and there is no index of 'this element' (in other words, it has zero length). As this object is used in the index for the pmElementTypeRegTable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmElementTypeRegEntry 2 } Waldbusser, et al. Standards Track [Page 87] RFC 4011 Policy Based Management MIB March 2005 pmElementTypeRegMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The PM agent is responsible for discovering new elements of types that are registered. This object lets the manager control the maximum amount of time that may pass between the time an element is created and when it is discovered. In other words, in any given interval of this duration, all new elements must be discovered. Note that how the policy agent schedules the checking of various elements within this interval is an implementation-dependent matter." ::= { pmElementTypeRegEntry 3 } pmElementTypeRegDescription OBJECT-TYPE SYNTAX PmUTF8String (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "A descriptive label for this registered type." ::= { pmElementTypeRegEntry 4 } pmElementTypeRegStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row is kept in volatile storage and lost upon reboot or backed up by non-volatile or permanent storage. If the value of this object is 'permanent', no values in the associated row have to be writable." ::= { pmElementTypeRegEntry 5 } pmElementTypeRegRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this registration entry. If the value of this object is active, no objects in this row may be modified." ::= { pmElementTypeRegEntry 6 } Waldbusser, et al. Standards Track [Page 88] RFC 4011 Policy Based Management MIB March 2005 -- Role Table pmRoleTable OBJECT-TYPE SYNTAX SEQUENCE OF PmRoleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmRoleTable is a read-create table that organizes role strings sorted by element. This table is used to create and modify role strings and their associations, as well as to allow a management station to learn about the existence of roles and their associations. It is the responsibility of the agent to keep track of any re-indexing of the underlying SNMP elements and to continue to associate role strings with the element with which they were initially configured. Policy MIB agents that have elements in multiple local SNMP contexts have to allow some roles to be assigned to elements in particular contexts. This is particularly true when some elements have the same names in different contexts and the context is required to disambiguate them. In those situations, a value for the pmRoleContextName may be provided. When a pmRoleContextName value is not provided, the assignment is to the element in the default context. Policy MIB agents that discover elements on other systems and execute policies on their behalf need to have access to role information for these remote elements. In such situations, role assignments for other systems can be stored in this table by providing values for the pmRoleContextEngineID parameters. For example: Example: element role context ctxEngineID #comment ifindex.1 gold local, default context ifindex.2 gold local, default context repeaterid.1 foo rptr1 local, rptr1 context repeaterid.1 bar rptr2 local, rptr2 context ifindex.1 gold '' A different system ifindex.1 gold '' B different system The agent must store role string associations in non-volatile storage." ::= { pmMib 4 } Waldbusser, et al. Standards Track [Page 89] RFC 4011 Policy Based Management MIB March 2005 pmRoleEntry OBJECT-TYPE SYNTAX PmRoleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A role string entry associates a role string with an individual element. Note that some combinations of index values may result in an instance name that exceeds a length of 128 sub-identifiers, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { pmRoleElement, pmRoleContextName, pmRoleContextEngineID, pmRoleString } ::= { pmRoleTable 1 } PmRoleEntry ::= SEQUENCE { pmRoleElement RowPointer, pmRoleContextName SnmpAdminString, pmRoleContextEngineID OCTET STRING, pmRoleString PmUTF8String, pmRoleStatus RowStatus } pmRoleElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "The element with which this role string is associated. For example, if the element is interface 3, then this object will contain the OID for 'ifIndex.3'. If the agent assigns new indexes in the MIB table to represent the same underlying element (re-indexing), the agent will modify this value to contain the new index for the underlying element. As this object is used in the index for the pmRoleTable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmRoleEntry 1 } Waldbusser, et al. Standards Track [Page 90] RFC 4011 Policy Based Management MIB March 2005 pmRoleContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is not in the default SNMP context for the target system, this object is used to identify the context. If the element is in the default context, this object is equal to the empty string." ::= { pmRoleEntry 2 } pmRoleContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 5..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is on a remote system, this object is used to identify the remote system. This object contains the contextEngineID of the system for which this role string assignment is valid. If the element is on the local system this object will be the empty string." ::= { pmRoleEntry 3 } pmRoleString OBJECT-TYPE SYNTAX PmUTF8String (SIZE (0..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The role string that is associated with an element through this table. All role strings must have been successfully transformed by Stringprep RFC 3454. Management stations must perform this translation and must only set this object to string values that have been transformed. A role string is an administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules, that determines the applicability of the rule to a particular managed element." ::= { pmRoleEntry 4 } pmRoleStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this role string. Waldbusser, et al. Standards Track [Page 91] RFC 4011 Policy Based Management MIB March 2005 If the value of this object is active, no object in this row may be modified." ::= { pmRoleEntry 5 } -- Capabilities table pmCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF PmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmCapabilitiesTable contains a description of the inherent capabilities of the system so that management stations can learn of an agent's capabilities and differentially install policies based on the capabilities. Capabilities are expressed at the system level. There can be variation in how capabilities are realized from one vendor or model to the next. Management systems should consider these differences before selecting which policy to install in a system." ::= { pmMib 5 } pmCapabilitiesEntry OBJECT-TYPE SYNTAX PmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A capabilities entry holds an OID indicating support for a particular capability. Capabilities may include hardware and software functions and the implementation of MIB Modules. The semantics of the OID are defined in the description of pmCapabilitiesType. Entries appear in this table if any element in the system has a specific capability. A capability should appear in this table only once, regardless of the number of elements in the system with that capability. An entry is removed from this table when the last element in the system that has the capability is removed. In some cases, capabilities are dynamic and exist only in software. This table should have an entry for the capability even if there are no current instances. Examples include systems with database or WEB services. While the system has the ability to create new databases or WEB services, the entry should exist. In these cases, the ability to create these services could come from other processes that are running in the system, even though there are no currently open databases or WEB servers running. Waldbusser, et al. Standards Track [Page 92] RFC 4011 Policy Based Management MIB March 2005 Capabilities may include the implementation of MIB Modules but need not be limited to those that represent MIB Modules with one or more configurable objects. It may also be valuable to include entries for capabilities that do not include configuration objects, as that information, in combination with other entries in this table, might be used by the management software to determine whether to install a policy. Vendor software may also add entries in this table to express capabilities from their private branch. Note that some values of this table's index may result in an instance name that exceeds a length of 128 sub-identifiers, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such values." INDEX { pmCapabilitiesType } ::= { pmCapabilitiesTable 1 } PmCapabilitiesEntry ::= SEQUENCE { pmCapabilitiesType OBJECT IDENTIFIER } pmCapabilitiesType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "There are three types of OIDs that may be present in the pmCapabilitiesType object: 1) The OID of a MODULE-COMPLIANCE macro that represents the highest level of compliance realized by the agent for that MIB Module. For example, an agent that implements the OSPF MIB Module at the highest level of compliance would have the value of '1.3.6.1.2.1.14.15.2' in the pmCapabilitiesType object. For software that realizes standard MIB Modules that do not have compliance statements, the base OID of the MIB Module should be used instead. If the OSPF MIB Module had not been created with a compliance statement, then the correct value of the pmCapabilitiesType would be '1.3.6.1.2.1.14'. In the cases where multiple compliance statements in a MIB Module are supported by the agent, and where one compliance statement does not by definition include the other, each of the compliance OIDs would have entries in this table. Waldbusser, et al. Standards Track [Page 93] RFC 4011 Policy Based Management MIB March 2005 MIB Documents can contain more than one MIB Module. In the case of OSPF, there is a second MIB Module that describes notifications for the OSPF Version 2 Protocol. If the agent also realizes these functions, an entry will also exist for those capabilities in this table. 2) Vendors should install OIDs in this table that represent vendor-specific capabilities. These capabilities can be expressed just as those described above for MIB Modules on the standards track. In addition, vendors may install any OID they desire from their registered branch. The OIDs may be at any level of granularity, from the root of their entire branch to an instance of a single OID. There is no restriction on the number of registrations they may make, though care should be taken to avoid unnecessary entries. 3) OIDs that represent one capability or a collection of capabilities that could be any collection of MIB Objects or hardware or software functions may be created in working groups and registered in a MIB Module. Other entities (e.g., vendors) may also make registrations. Software will register these standard capability OIDs, as well as vendor specific OIDs. If the OID for a known capability is not present in the table, then it should be assumed that the capability is not implemented. As this object is used in the index for the pmCapabilitiesTable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmCapabilitiesEntry 1 } -- Capabilities override table pmCapabilitiesOverrideTable OBJECT-TYPE SYNTAX SEQUENCE OF PmCapabilitiesOverrideEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmCapabilitiesOverrideTable allows management stations to override pmCapabilitiesTable entries that have been registered by the agent. This facility can be used to avoid situations in which managers in the network send policies to a system that has advertised a capability in the pmCapabilitiesTable but that should not be installed on this particular system. One example could be newly deployed Waldbusser, et al. Standards Track [Page 94] RFC 4011 Policy Based Management MIB March 2005 equipment that is still in a trial state in a trial state or resources reserved for some other administrative reason. This table can also be used to override entries in the pmCapabilitiesTable through the use of the pmCapabilitiesOverrideState object. Capabilities can also be declared available in this table that were not registered in the pmCapabilitiesTable. A management application can make an entry in this table for any valid OID and declare the capability available by setting the pmCapabilitiesOverrideState for that row to valid(1)." ::= { pmMib 6 } pmCapabilitiesOverrideEntry OBJECT-TYPE SYNTAX PmCapabilitiesOverrideEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table indicates whether a particular capability is valid or invalid. Note that some values of this table's index may result in an instance name that exceeds a length of 128 sub-identifiers, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such values." INDEX { pmCapabilitiesOverrideType } ::= { pmCapabilitiesOverrideTable 1 } PmCapabilitiesOverrideEntry ::= SEQUENCE { pmCapabilitiesOverrideType OBJECT IDENTIFIER, pmCapabilitiesOverrideState INTEGER, pmCapabilitiesOverrideRowStatus RowStatus } pmCapabilitiesOverrideType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is the OID of the capability that is declared valid or invalid by the pmCapabilitiesOverrideState value for this row. Any valid OID, as described in the pmCapabilitiesTable, is permitted in the pmCapabilitiesOverrideType object. This means that capabilities can be expressed at any level, from a specific instance of an object to a table or entire module. There are no restrictions on whether these objects are from standards track MIB documents or in the private branch of the MIB. Waldbusser, et al. Standards Track [Page 95] RFC 4011 Policy Based Management MIB March 2005 If an entry exists in this table for which there is a corresponding entry in the pmCapabilitiesTable, then this entry shall have precedence over the entry in the pmCapabilitiesTable. All entries in this table must be preserved across reboots. As this object is used in the index for the pmCapabilitiesOverrideTable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmCapabilitiesOverrideEntry 1 } pmCapabilitiesOverrideState OBJECT-TYPE SYNTAX INTEGER { invalid(1), valid(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "A pmCapabilitiesOverrideState of invalid indicates that management software should not send policies to this system for the capability identified in the pmCapabilitiesOverrideType for this row of the table. This behavior is the same whether the capability represented by the pmCapabilitiesOverrideType exists only in this table (that is, it was installed by an external management application) or exists in this table as well as the pmCapabilitiesTable. This would be the case when a manager wanted to disable a capability that the native management system found and registered in the pmCapabilitiesTable. An entry in this table that has a pmCapabilitiesOverrideState of valid should be treated as though it appeared in the pmCapabilitiesTable. If the entry also exists in the pmCapabilitiesTable in the pmCapabilitiesType object, and if the value of this object is valid, then the system shall operate as though this entry did not exist and policy installations and executions will continue in a normal fashion." ::= { pmCapabilitiesOverrideEntry 2 } pmCapabilitiesOverrideRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status of this pmCapabilitiesOverrideEntry. Waldbusser, et al. Standards Track [Page 96] RFC 4011 Policy Based Management MIB March 2005 If the value of this object is active, no object in this row may be modified." ::= { pmCapabilitiesOverrideEntry 3 } -- The Schedule Group pmSchedLocalTime OBJECT-TYPE SYNTAX DateAndTime (SIZE (11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The local time used by the scheduler. Schedules that refer to calendar time will use the local time indicated by this object. An implementation MUST return all 11 bytes of the DateAndTime textual-convention so that a manager may retrieve the offset from GMT time." ::= { pmMib 7 } -- -- The schedule table that controls the scheduler. -- pmSchedTable OBJECT-TYPE SYNTAX SEQUENCE OF PmSchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines schedules for policies." ::= { pmMib 8 } pmSchedEntry OBJECT-TYPE SYNTAX PmSchedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular schedule. Unless noted otherwise, writable objects of this row can be modified independently of the current value of pmSchedRowStatus, pmSchedAdminStatus and pmSchedOperStatus. In particular, it is legal to modify pmSchedWeekDay, pmSchedMonth, and pmSchedDay when pmSchedRowStatus is active." INDEX { pmSchedIndex } ::= { pmSchedTable 1 } Waldbusser, et al. Standards Track [Page 97] RFC 4011 Policy Based Management MIB March 2005 PmSchedEntry ::= SEQUENCE { pmSchedIndex Unsigned32, pmSchedGroupIndex Unsigned32, pmSchedDescr PmUTF8String, pmSchedTimePeriod PmUTF8String, pmSchedMonth BITS, pmSchedDay BITS, pmSchedWeekDay BITS, pmSchedTimeOfDay PmUTF8String, pmSchedLocalOrUtc INTEGER, pmSchedStorageType StorageType, pmSchedRowStatus RowStatus } pmSchedIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The locally unique, administratively assigned index for this scheduling entry." ::= { pmSchedEntry 1 } pmSchedGroupIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The locally unique, administratively assigned index for the schedule group this scheduling entry belongs to. To assign multiple schedule entries to the same group, the pmSchedGroupIndex of each entry in the group will be set to the same value. This pmSchedGroupIndex value must be equal to the pmSchedIndex of one of the entries in the group. If the entry whose pmSchedIndex equals the pmSchedGroupIndex for the group is deleted, the agent will assign a new pmSchedGroupIndex to all remaining members of the group. If an entry is not a member of a group, its pmSchedGroupIndex must be assigned to the value of its pmSchedIndex. Policies that are controlled by a group of schedule entries are active when any schedule in the group is active." ::= { pmSchedEntry 2 } Waldbusser, et al. Standards Track [Page 98] RFC 4011 Policy Based Management MIB March 2005 pmSchedDescr OBJECT-TYPE SYNTAX PmUTF8String MAX-ACCESS read-create STATUS current DESCRIPTION "The human-readable description of the purpose of this scheduling entry." DEFVAL { ''H } ::= { pmSchedEntry 3 } pmSchedTimePeriod OBJECT-TYPE SYNTAX PmUTF8String (SIZE (0..31)) MAX-ACCESS read-create STATUS current DESCRIPTION "The overall range of calendar dates and times over which this schedule is active. It is stored in a slightly extended version of the format for a 'period-explicit' defined in RFC 2445. This format is expressed as a string representing the starting date and time, in which the character 'T' indicates the beginning of the time portion, followed by the solidus character, '/', followed by a similar string representing an end date and time. The start of the period MUST be before the end of the period. Date-Time values are expressed as substrings of the form 'yyyymmddThhmmss'. For example: 20000101T080000/20000131T130000 January 1, 2000, 0800 through January 31, 2000, 1PM The 'Date with UTC time' format defined in RFC 2445 in which the Date-Time string ends with the character 'Z' is not allowed. This 'period-explicit' format is also extended to allow two special cases in which one of the Date-Time strings is replaced with a special string defined in RFC 2445: 1. If the first Date-Time value is replaced with the string 'THISANDPRIOR', then the value indicates that the schedule is active at any time prior to the Date-Time that appears after the '/'. 2. If the second Date-Time is replaced with the string 'THISANDFUTURE', then the value indicates that the schedule is active at any time after the Date-Time that appears before the '/'. Waldbusser, et al. Standards Track [Page 99] RFC 4011 Policy Based Management MIB March 2005 Note that although RFC 2445 defines these two strings, they are not specified for use in the 'period-explicit' format. The use of these strings represents an extension to the 'period-explicit' format." ::= { pmSchedEntry 4 } pmSchedMonth OBJECT-TYPE SYNTAX BITS { january(0), february(1), march(2), april(3), may(4), june(5), july(6), august(7), september(8), october(9), november(10), december(11) } MAX-ACCESS read-create STATUS current DESCRIPTION "Within the overall time period specified in the pmSchedTimePeriod object, the value of this object specifies the specific months within that time period when the schedule is active. Setting all bits will cause the schedule to act independently of the month." DEFVAL { { january, february, march, april, may, june, july, august, september, october, november, december } } ::= { pmSchedEntry 5 } pmSchedDay OBJECT-TYPE SYNTAX BITS { d1(0), d2(1), d3(2), d4(3), d5(4), d6(5), d7(6), d8(7), d9(8), d10(9), d11(10), d12(11), d13(12), d14(13), d15(14), d16(15), d17(16), d18(17), d19(18), d20(19), d21(20), d22(21), d23(22), d24(23), d25(24), d26(25), d27(26), d28(27), d29(28), d30(29), d31(30), r1(31), r2(32), r3(33), r4(34), r5(35), r6(36), r7(37), r8(38), r9(39), r10(40), r11(41), r12(42), r13(43), r14(44), r15(45), r16(46), r17(47), r18(48), r19(49), r20(50), r21(51), r22(52), r23(53), r24(54), r25(55), Waldbusser, et al. Standards Track [Page 100] RFC 4011 Policy Based Management MIB March 2005 r26(56), r27(57), r28(58), r29(59), r30(60), r31(61) } MAX-ACCESS read-create STATUS current DESCRIPTION "Within the overall time period specified in the pmSchedTimePeriod object, the value of this object specifies the specific days of the month within that time period when the schedule is active. There are two sets of bits one can use to define the day within a month: Enumerations starting with the letter 'd' indicate a day in a month relative to the first day of a month. The first day of the month can therefore be specified by setting the bit d1(0), and d31(30) means the last day of a month with 31 days. Enumerations starting with the letter 'r' indicate a day in a month in reverse order, relative to the last day of a month. The last day in the month can therefore be specified by setting the bit r1(31), and r31(61) means the first day of a month with 31 days. Setting multiple bits will include several days in the set of possible days for this schedule. Setting all bits starting with the letter 'd' or all bits starting with the letter 'r' will cause the schedule to act independently of the day of the month." DEFVAL { { d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12, r13, r14, r15, r16, r17, r18, r19, r20, r21, r22, r23, r24, r25, r26, r27, r28, r29, r30, r31 } } ::= { pmSchedEntry 6 } pmSchedWeekDay OBJECT-TYPE SYNTAX BITS { sunday(0), monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), Waldbusser, et al. Standards Track [Page 101] RFC 4011 Policy Based Management MIB March 2005 saturday(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "Within the overall time period specified in the pmSchedTimePeriod object, the value of this object specifies the specific days of the week within that time period when the schedule is active. Setting all bits will cause the schedule to act independently of the day of the week." DEFVAL { { sunday, monday, tuesday, wednesday, thursday, friday, saturday } } ::= { pmSchedEntry 7 } pmSchedTimeOfDay OBJECT-TYPE SYNTAX PmUTF8String (SIZE (0..15)) MAX-ACCESS read-create STATUS current DESCRIPTION "Within the overall time period specified in the pmSchedTimePeriod object, the value of this object specifies the range of times in a day when the schedule is active. This value is stored in a format based on the RFC 2445 format for 'time': The character 'T' followed by a 'time' string, followed by the solidus character, '/', followed by the character 'T', followed by a second time string. The first time indicates the beginning of the range, and the second time indicates the end. Thus, this value takes the following form: 'Thhmmss/Thhmmss'. The second substring always identifies a later time than the first substring. To allow for ranges that span midnight, however, the value of the second string may be smaller than the value of the first substring. Thus, 'T080000/T210000' identifies the range from 0800 until 2100, whereas 'T210000/T080000' identifies the range from 2100 until 0800 of the following day. When a range spans midnight, by definition it includes parts of two successive days. When one of these days is also selected by either the MonthOfYearMask, DayOfMonthMask, and/or DayOfWeekMask, but the other day is not, then the policy is active only during the portion of the range that falls on the selected day. For example, if the range extends from 2100 Waldbusser, et al. Standards Track [Page 102] RFC 4011 Policy Based Management MIB March 2005 until 0800, and the day of week mask selects Monday and Tuesday, then the policy is active during the following three intervals: From midnight Sunday until 0800 Monday From 2100 Monday until 0800 Tuesday From 2100 Tuesday until 23:59:59 Tuesday Setting this value to 'T000000/T235959' will cause the schedule to act independently of the time of day." DEFVAL { '543030303030302F54323335393539'H } -- T000000/T235959 ::= { pmSchedEntry 8 } pmSchedLocalOrUtc OBJECT-TYPE SYNTAX INTEGER { localTime(1), utcTime(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether the times represented in the TimePeriod object and in the various Mask objects represent local times or UTC times." DEFVAL { utcTime } ::= { pmSchedEntry 9 } pmSchedStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this schedule entry is kept in volatile storage and lost upon reboot or backed up by non-volatile or permanent storage. Conceptual rows having the value 'permanent' must allow write access to the columnar objects pmSchedDescr, pmSchedWeekDay, pmSchedMonth, and pmSchedDay. If the value of this object is 'permanent', no values in the associated row have to be writable." DEFVAL { volatile } ::= { pmSchedEntry 10 } Waldbusser, et al. Standards Track [Page 103] RFC 4011 Policy Based Management MIB March 2005 pmSchedRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this schedule entry. If the value of this object is active, no object in this row may be modified." ::= { pmSchedEntry 11 } -- Policy Tracking -- The "policy to element" (PE) table and the "element to policy" (EP) -- table track the status of execution contexts grouped by policy and -- element respectively. pmTrackingPETable OBJECT-TYPE SYNTAX SEQUENCE OF PmTrackingPEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmTrackingPETable describes what elements are active (under control of) a policy. This table is indexed in order to optimize retrieval of the entire status for a given policy." ::= { pmMib 9 } pmTrackingPEEntry OBJECT-TYPE SYNTAX PmTrackingPEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmTrackingPETable. The pmPolicyIndex in the index specifies the policy tracked by this entry. Note that some combinations of index values may result in an instance name that exceeds a length of 128 sub-identifiers, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { pmPolicyIndex, pmTrackingPEElement, pmTrackingPEContextName, pmTrackingPEContextEngineID } ::= { pmTrackingPETable 1 } Waldbusser, et al. Standards Track [Page 104] RFC 4011 Policy Based Management MIB March 2005 PmTrackingPEEntry ::= SEQUENCE { pmTrackingPEElement RowPointer, pmTrackingPEContextName SnmpAdminString, pmTrackingPEContextEngineID OCTET STRING, pmTrackingPEInfo BITS } pmTrackingPEElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "The element that is acted upon by the associated policy. As this object is used in the index for the pmTrackingPETable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmTrackingPEEntry 1 } pmTrackingPEContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is not in the default SNMP context for the target system, this object is used to identify the context. If the element is in the default context, this object is equal to the empty string." ::= { pmTrackingPEEntry 2 } pmTrackingPEContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 5..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is on a remote system, this object is used to identify the remote system. This object contains the contextEngineID of the system on which the associated element resides. If the element is on the local system, this object will be the empty string." ::= { pmTrackingPEEntry 3 } pmTrackingPEInfo OBJECT-TYPE SYNTAX BITS { actionSkippedDueToPrecedence(0), conditionRunTimeException(1), conditionUserSignal(2), Waldbusser, et al. Standards Track [Page 105] RFC 4011 Policy Based Management MIB March 2005 actionRunTimeException(3), actionUserSignal(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns information about the previous policy script executions. If the actionSkippedDueToPrecedence(1) bit is set, the last execution of the associated policy condition returned non-zero, but the action is not active, because it was trumped by a matching policy condition in the same precedence group with a higher precedence value. If the conditionRunTimeException(2) bit is set, the last execution of the associated policy condition encountered a run-time exception and aborted. If the conditionUserSignal(3) bit is set, the last execution of the associated policy condition called the signalError() function. If the actionRunTimeException(4) bit is set, the last execution of the associated policy action encountered a run-time exception and aborted. If the actionUserSignal(5) bit is set, the last execution of the associated policy action called the signalError() function. Entries will only exist in this table of one or more bits are set. In particular, if an entry does not exist for a particular policy/element combination, it can be assumed that the policy's condition did not match 'this element'." ::= { pmTrackingPEEntry 4 } -- Element to Policy Table pmTrackingEPTable OBJECT-TYPE SYNTAX SEQUENCE OF PmTrackingEPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmTrackingEPTable describes what policies are controlling an element. This table is indexed in order to optimize retrieval of the status of all policies active for a given element." Waldbusser, et al. Standards Track [Page 106] RFC 4011 Policy Based Management MIB March 2005 ::= { pmMib 10 } pmTrackingEPEntry OBJECT-TYPE SYNTAX PmTrackingEPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmTrackingEPTable. Entries exist for all element/policy combinations for which the policy's condition matches and only if the schedule for the policy is active. The pmPolicyIndex in the index specifies the policy tracked by this entry. Note that some combinations of index values may result in an instance name that exceeds a length of 128 sub-identifiers, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { pmTrackingEPElement, pmTrackingEPContextName, pmTrackingEPContextEngineID, pmPolicyIndex } ::= { pmTrackingEPTable 1 } PmTrackingEPEntry ::= SEQUENCE { pmTrackingEPElement RowPointer, pmTrackingEPContextName SnmpAdminString, pmTrackingEPContextEngineID OCTET STRING, pmTrackingEPStatus INTEGER } pmTrackingEPElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "The element acted upon by the associated policy. As this object is used in the index for the pmTrackingEPTable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmTrackingEPEntry 1 } pmTrackingEPContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is not in the default SNMP context Waldbusser, et al. Standards Track [Page 107] RFC 4011 Policy Based Management MIB March 2005 for the target system, this object is used to identify the context. If the element is in the default context, this object is equal to the empty string." ::= { pmTrackingEPEntry 2 } pmTrackingEPContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 5..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is on a remote system, this object is used to identify the remote system. This object contains the contextEngineID of the system on which the associated element resides. If the element is on the local system, this object will be the empty string." ::= { pmTrackingEPEntry 3 } pmTrackingEPStatus OBJECT-TYPE SYNTAX INTEGER { on(1), forceOff(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This entry will only exist if the calendar for the policy is active and if the associated policyCondition returned 1 for 'this element'. A policy can be forcibly disabled on a particular element by setting this value to forceOff(2). The agent should then act as though the policyCondition failed for 'this element'. The forceOff(2) state will persist (even across reboots) until this value is set to on(1) by a management request. The forceOff(2) state may be set even if the entry does not previously exist so that future policy invocations can be avoided. Unless forcibly disabled, if this entry exists, its value will be on(1)." ::= { pmTrackingEPEntry 4 } -- Policy Debugging Table pmDebuggingTable OBJECT-TYPE SYNTAX SEQUENCE OF PmDebuggingEntry MAX-ACCESS not-accessible STATUS current Waldbusser, et al. Standards Track [Page 108] RFC 4011 Policy Based Management MIB March 2005 DESCRIPTION "Policies that have debugging turned on will generate a log entry in the policy debugging table for every runtime exception that occurs in either the condition or action code. The pmDebuggingTable logs debugging messages when policies experience run-time exceptions in either the condition or action code and the associated pmPolicyDebugging object has been turned on. The maximum number of debugging entries that will be stored and the maximum length of time an entry will be kept are an implementation-dependent manner. If entries must be discarded to make room for new entries, the oldest entries must be discarded first. If the system restarts, all debugging entries may be deleted." ::= { pmMib 11 } pmDebuggingEntry OBJECT-TYPE SYNTAX PmDebuggingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmDebuggingTable. The pmPolicyIndex in the index specifies the policy that encountered the exception that led to this log entry. Note that some combinations of index values may result in an instance name that exceeds a length of 128 sub-identifiers, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { pmPolicyIndex, pmDebuggingElement, pmDebuggingContextName, pmDebuggingContextEngineID, pmDebuggingLogIndex } ::= { pmDebuggingTable 1 } PmDebuggingEntry ::= SEQUENCE { pmDebuggingElement RowPointer, pmDebuggingContextName SnmpAdminString, pmDebuggingContextEngineID OCTET STRING, pmDebuggingLogIndex Unsigned32, pmDebuggingMessage PmUTF8String } Waldbusser, et al. Standards Track [Page 109] RFC 4011 Policy Based Management MIB March 2005 pmDebuggingElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "The element the policy was executing on when it encountered the error that led to this log entry. For example, if the element is interface 3, then this object will contain the OID for 'ifIndex.3'. As this object is used in the index for the pmDebuggingTable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmDebuggingEntry 1 } pmDebuggingContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is not in the default SNMP context for the target system, this object is used to identify the context. If the element is in the default context, this object is equal to the empty string." ::= { pmDebuggingEntry 2 } pmDebuggingContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 5..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the associated element is on a remote system, this object is used to identify the remote system. This object contains the contextEngineID of the system on which the associated element resides. If the element is on the local system, this object will be the empty string." ::= { pmDebuggingEntry 3 } pmDebuggingLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this log entry among other log entries for this policy/element combination." ::= { pmDebuggingEntry 4 } Waldbusser, et al. Standards Track [Page 110] RFC 4011 Policy Based Management MIB March 2005 pmDebuggingMessage OBJECT-TYPE SYNTAX PmUTF8String (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "An error message generated by the policy execution environment. It is recommended that this message include the time of day when the message was generated, if known." ::= { pmDebuggingEntry 5 } -- Notifications pmNotifications OBJECT IDENTIFIER ::= { pmMib 0 } pmNewRoleNotification NOTIFICATION-TYPE OBJECTS { pmRoleStatus } STATUS current DESCRIPTION "The pmNewRoleNotification is sent when an agent is configured with its first instance of a previously unused role string (not every time a new element is given a particular role). An instance of the pmRoleStatus object is sent containing the new roleString in its index. In the event that two or more elements are given the same role simultaneously, it is an implementation-dependent matter as to which pmRoleTable instance will be included in the notification." ::= { pmNotifications 1 } pmNewCapabilityNotification NOTIFICATION-TYPE OBJECTS { pmCapabilitiesType } STATUS current DESCRIPTION "The pmNewCapabilityNotification is sent when an agent gains a new capability that did not previously exist in any element on the system (not every time an element gains a particular capability). An instance of the pmCapabilitiesType object is sent containing the identity of the new capability. In the event that two or more elements gain the same capability simultaneously, it is an implementation-dependent matter as to which pmCapabilitiesType instance will be included in the notification." ::= { pmNotifications 2 } pmAbnormalTermNotification NOTIFICATION-TYPE OBJECTS { pmTrackingPEInfo } STATUS current Waldbusser, et al. Standards Track [Page 111] RFC 4011 Policy Based Management MIB March 2005 DESCRIPTION "The pmAbnormalTermNotification is sent when a policy's pmPolicyAbnormalTerminations gauge value changes from zero to any value greater than zero and no such notification has been sent for that policy in the last 5 minutes. The notification contains an instance of the pmTrackingPEInfo object where the pmPolicyIndex component of the index identifies the associated policy and the rest of the index identifies an element on which the policy failed." ::= { pmNotifications 3 } -- Compliance Statements pmConformance OBJECT IDENTIFIER ::= { pmMib 12 } pmCompliances OBJECT IDENTIFIER ::= { pmConformance 1 } pmGroups OBJECT IDENTIFIER ::= { pmConformance 2 } pmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Policy-Based Management MIB" MODULE -- this module MANDATORY-GROUPS { pmPolicyManagementGroup, pmSchedGroup, pmNotificationGroup } ::= { pmCompliances 1 } pmPolicyManagementGroup OBJECT-GROUP OBJECTS { pmPolicyPrecedenceGroup, pmPolicyPrecedence, pmPolicySchedule, pmPolicyElementTypeFilter, pmPolicyConditionScriptIndex, pmPolicyActionScriptIndex, pmPolicyParameters, pmPolicyConditionMaxLatency, pmPolicyActionMaxLatency, pmPolicyMaxIterations, pmPolicyDescription, pmPolicyMatches, pmPolicyAbnormalTerminations, pmPolicyExecutionErrors, pmPolicyDebugging, pmPolicyStorageType, pmPolicyAdminStatus, pmPolicyRowStatus, pmPolicyCodeText, pmPolicyCodeStatus, pmElementTypeRegMaxLatency, pmElementTypeRegDescription, pmElementTypeRegStorageType, pmElementTypeRegRowStatus, pmRoleStatus, pmCapabilitiesType, pmCapabilitiesOverrideState, pmCapabilitiesOverrideRowStatus, pmTrackingPEInfo, pmTrackingEPStatus, pmDebuggingMessage } Waldbusser, et al. Standards Track [Page 112] RFC 4011 Policy Based Management MIB March 2005 STATUS current DESCRIPTION "Objects that allow for the creation and management of configuration policies." ::= { pmGroups 1 } pmSchedGroup OBJECT-GROUP OBJECTS { pmSchedLocalTime, pmSchedGroupIndex, pmSchedDescr, pmSchedTimePeriod, pmSchedMonth, pmSchedDay, pmSchedWeekDay, pmSchedTimeOfDay, pmSchedLocalOrUtc, pmSchedStorageType, pmSchedRowStatus } STATUS current DESCRIPTION "Objects that allow for the scheduling of policies." ::= { pmGroups 2 } pmNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pmNewRoleNotification, pmNewCapabilityNotification, pmAbnormalTermNotification } STATUS current DESCRIPTION "Notifications sent by an Policy MIB agent." ::= { pmGroups 3 } pmBaseFunctionLibrary OBJECT IDENTIFIER ::= { pmGroups 4 } END 12. Relationship to Other MIB Modules When policy-based management is used specifically for (policy-based) configuration, the "Configuring Networks and Devices With SNMP" RFC 3512 [19] document describes configuration management practices, terminology, and an example of a MIB Module that may be helpful to those developing and using this technology. The Policy MIB accesses system instrumentation for the purposes of policy evaluation, control, notification, monitoring, and error reporting. This information is available to managers in the form of MIB objects. Information about system configuration is modified by the Policy MIB through MIB objects defined in other MIB Modules. Details about the operational or configuration details of a system are retrieved by the manager via access to the specific MIB objects available in a network element. As such, the Policy MIB can use any Waldbusser, et al. Standards Track [Page 113] RFC 4011 Policy Based Management MIB March 2005 standard or vendor-defined object that exists on a managed system. In particular, the Policy MIB may access standard or vendor specific objects that are instance-specific such as BGP timeout parameters and specific interface counters. 13. Security Considerations This MIB contains no objects for which read access would disclose sensitive information. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. With the exception of pmPolicyDescription, pmPolicyDebugging, pmElementTypeRegDescription, and pmSchedDescr, EVERY read-create and read-write object in this MIB should be considered sensitive because if an unauthorized user could manipulate these objects, s/he could cause the Policy MIB system to use the stored credentials of an authorized user to perform unauthorized and potentially harmful operations. There are no read-only objects in this MIB that contain sensitive information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [16], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Waldbusser, et al. Standards Track [Page 114] RFC 4011 Policy Based Management MIB March 2005 An implementation must ensure that access control rules are applied when SNMP operations are performed in policy scripts. To ensure this, an implementation must record and maintain the security credentials of the last entity to modify each policy's pmPolicyAdminStatus object. The credentials to store are the securityModel, securityName, and securityLevel and will be used as input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks [1]. This mechanism was first introduced in the DISMAN-SCHEDULE-MIB [12]. SNMP requests made when secModel, secName, and secLevel are specified use credentials stored in the local configuration datastore. Access to these credentials depends on the security credentials of the last entity to modify the policy's pmPolicyAdminStatus object. To determine whether the credentials can be accessed, the isAccessAllowed abstract service interface defined in RFC 3411 [1] is called: statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model used IN securityName -- principal who wants to access IN securityLevel -- Level of Security used IN viewType -- write IN contextName -- context containing variableName IN variableName -- OID for an object in the proper -- LCD entry ) The securityModel, securityName, and securityLevel parameters are set to the values that were recorded when the policy was modified. The viewType is set to write, and the contextName and variableName are set to select any read-create object in the appropriate LCD entry. Proper configuration of VACM requires that write access to an LCD entry not be given to entities that aren't authorized to use the credentials therein. Access control for SNMP requests made to the local system where secModel, secName, and secLevel aren't specified depends on the security credentials of the last entity to modify the policy's pmPolicyAdminStatus object. To determine whether the operation should succeed, the isAccessAllowed abstract service interface defined in RFC 3411 [1] is called: Waldbusser, et al. Standards Track [Page 115] RFC 4011 Policy Based Management MIB March 2005 statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context as specified IN variableName -- OID for the managed object ) The securityModel, securityName, and securityLevel parameters are set to the values that were recorded when the policy was modified. The viewType, contextName, and variableName parameters are set as appropriate for the requested SNMP operation. Unless all users who have write access to the pmPolicyTable and pmPolicyCodeTable have equivalent access to the managed system, policy scripts could be used by a user to gain the privileges of another user. Therefore, when policy users have different access, access control should be applied so that a user's policies cannot be modified by another user. To make this more convenient, a user can place all of his or her policies in the same pmPolicyAdminGroup so that a single access control view can apply to all of them. Some policies may be designed to ensure the security of a network. If these policies have not been installed pending the appearance of a role or capability, some delay will occur in their activation policies when the role or capability appears because a responsible manager must notice the change and install the policy. This delay may expose the device or the network to unacceptable security vulnerabilities during this delay. If the role or capability appears during a time of network stress or when the management station is unavailable, this delay could be extensive, further increasing the exposure. It is recommended that management stations install any security-related policies that might ever be needed on a particular managed device, even if a nonexistent role or capability suggests that it is not needed at a given time. This MIB allows the delegation of access rights so that a user ("Joe") can instruct a Policy MIB agent to execute remote operations on his behalf that are authorized by keys stored by "Joe" into the usmUserTable. Care needs to be taken to ensure that unauthorized users are unable to configure their policies to use Joe's keys. Although there are theoretically many ways to configure SNMP security, users are advised to follow the most straightforward way outlined below to minimize complexity and the resulting opportunity for errors. Waldbusser, et al. Standards Track [Page 116] RFC 4011 Policy Based Management MIB March 2005 Assume that Joe has credentials that give him authority to manage agents A, B, and C, as well as the Policy MIB agent "P". Joe will store credentials for Joe@A, Joe@B, and Joe@C in the usmUserTable of the Policy MIB agent. Then the following VACM configuration will be used: VACM securityToGroupTable A single entry mapping user Joe@P to group JoesGroup VACM accessTable A single entry mapping group JoesGroup to write view JoesView VACM viewTreeFamilyTable ViewName Subtree Type JoesView points to Joe@A in usmUserTable included JoesView points to Joe@B in usmUserTable included JoesView points to Joe@C in usmUserTable included In the preceding examples, the notation Joe@A represents the entry indexed by usmUserEngineID and usmUserName, where the SnmpEngineID is that of system A and the usmUserName is "Joe". 14. IANA Considerations This is a profile of stringprep. It has been registered by the IANA in the stringprep profile registry located at: http://www.iana.org/assignments/stringprep-profiles Name of this profile: Policy MIB Stringprep. RFC in which the profile is defined: This document. Indicator whether this is the newest version of the profile: This is the first version of Policy MIB Stringprep. Waldbusser, et al. Standards Track [Page 117] RFC 4011 Policy Based Management MIB March 2005 15. Acknowledgements The authors gratefully acknowledge the significant contributions to this work made by Jeff Case, Patrik Falstrom, Joel Halpern, Pablo Halpern, Bob Moore, Steve Moulton, David Partain, and Walter Weiss. This MIB uses a security delegation mechanism that was first introduced in the DISMAN-SCHEDULE-MIB [12]. The Schedule table of this MIB borrows heavily from the PolicyTimePeriodCondition of the Policy Core Information Model (PCIM) [18] and from the DISMAN- SCHEDULE-MIB [12]. 16. References 16.1. Normative References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [5] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [6] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [7] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [8] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet- standard Network Management Framework", BCP 74, RFC 3584, August 2003. Waldbusser, et al. Standards Track [Page 118] RFC 4011 Policy Based Management MIB March 2005 [9] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [10] International Standards Organization, "Information Technology - Programming Languages - C++", ISO/IEC 14882-1998 [11] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002. [12] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 3231, January 2002. [13] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [15] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. 16.2. Informative References [16] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [17] ECMA, "ECMAScript Language Specification", ECMA-262, December 1999 [18] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [19] MacFaden, M., Partain, D., Saperia, J., and W. Tackabury, "Configuring Networks and Devices with Simple Network Management Protocol (SNMP)", RFC 3512, April 2003. Waldbusser, et al. Standards Track [Page 119] RFC 4011 Policy Based Management MIB March 2005 Author's Addresses Steve Waldbusser Phone: +1-650-948-6500 Fax: +1-650-745-0671 EMail: waldbusser@nextbeacon.com Jon Saperia (WG Co-chair) JDS Consulting, Inc. 84 Kettell Plain Road. Stow MA 01775 USA Phone: +1-978-461--0249 Fax: +1-617-249-0874 EMail: saperia@jdscons.com Thippanna Hongal Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA, 95054 USA Phone: +1-408-878-6562 Fax: +1-408-878-6501 EMail: hongal@riverstonenet.com Waldbusser, et al. Standards Track [Page 120] RFC 4011 Policy Based Management MIB March 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Waldbusser, et al. Standards Track [Page 121] snmp-mibs-downloader-1.1/mibrfcs/rfc4022.txt0000644000000000000000000013440011402176072015554 0ustar Network Working Group R. Raghunarayan, Ed. Request for Comments: 4022 Cisco Systems Obsoletes: 2452, 2012 March 2005 Category: Standards Track Management Information Base for the Transmission Control Protocol (TCP) 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . 2 2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Relationship to Other MIBs. . . . . . . . . . . . . . . 2 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 20 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Normative References. . . . . . . . . . . . . . . . . . 20 5.2. Informative References. . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 23 Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 23 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 24 Raghunarayan Standards Track [Page 1] RFC 4022 MIB for TCP March 2005 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview The current TCP-MIB defined in this memo consists of two tables and a group of scalars: - The tcp group of scalars includes two sets of objects: o Parameters of a TCP protocol engine. These include parameters such as the retransmission algorithm in use (e.g., vanj [VANJ]) and the retransmission timeout values. o Statistics of a TCP protocol engine. These include counters for the number of active/passive opens, input/output segments, and errors. Discontinuities in the stats are identified identified via the sysUpTime object, defined in [RFC3418]. - The tcpConnectionTable provides access to status information for all TCP connections handled by a TCP protocol engine. In addition, the table reports identification of the operating system level processes that handle the TCP connections. - The tcpListenerTable provides access to information about all TCP listening endpoints known by a TCP protocol engine. And as with the connection table, the tcpListenerTable also reports the identification of the operating system level processes that handle this listening TCP endpoint. 2.1. Relationship to Other MIBs This section discusses the relationship of this TCP-MIB module to other MIB modules. Raghunarayan Standards Track [Page 2] RFC 4022 MIB for TCP March 2005 2.1.1. Relationship to RFC1213-MIB TCP related MIB objects were originally defined as part of the RFC1213-MIB defined in RFC 1213 [RFC1213]. The TCP related objects of the RFC1213-MIB were later copied into a separate MIB module and published in RFC 2012 [RFC2012] in SMIv2 format. The previous versions of the TCP-MIB both defined the tcpConnTable, which has been deprecated basically for two reasons: (1) The tcpConnTable only supports IPv4. The current approach in the IETF is to write IP version neutral MIBs, based on the InetAddressType and InetAddress constructs defined in [RFC4001], rather than to have different definitions for various version of IP. This reduces the amount of overhead when new objects are introduced, as there is only one place to add them. Hence, the approach taken in [RFC2452], of having separate tables, is not continued. (2) The tcpConnTable mixes listening endpoints with connections. It turns out that connections tend to have a different behaviour and management access pattern than listening endpoints. Therefore, splitting the original tcpConnTable into two tables allows for the addition of specific status and statistics objects for listening endpoints and connections. 2.1.2. Relationship to IPV6-TCP-MIB The IPV6-TCP-MIB defined in RFC 2452 has been moved to Historic status because the approach of having separate IP version specific tables is not followed anymore. Implementation of RFC 2452 is no longer suggested. 2.1.3. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB The tcpConnectionTable and the tcpListenerTable report the identification of the operating system level process that handles a connection or a listening endpoint. The value is reported as an Unsigned32, which is expected to be the same as the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] (if the value is smaller than 2147483647) or the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287]. This allows management applications to identify the TCP connections that belong to an operating system level process, which has proven to be valuable in operational environments. Raghunarayan Standards Track [Page 3] RFC 4022 MIB for TCP March 2005 3. Definitions TCP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Gauge32, Counter32, Counter64, IpAddress, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddress, InetAddressType, InetPortNumber FROM INET-ADDRESS-MIB; tcpMIB MODULE-IDENTITY LAST-UPDATED "200502180000Z" -- 18 February 2005 ORGANIZATION "IETF IPv6 MIB Revision Team http://www.ietf.org/html.charters/ipv6-charter.html" CONTACT-INFO "Rajiv Raghunarayan (editor) Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408 853 9612 Email: Send comments to " DESCRIPTION "The MIB module for managing TCP implementations. Copyright (C) The Internet Society (2005). This version of this MIB module is a part of RFC 4022; see the RFC itself for full legal notices." REVISION "200502180000Z" -- 18 February 2005 DESCRIPTION "IP version neutral revision, published as RFC 4022." REVISION "9411010000Z" DESCRIPTION "Initial SMIv2 version, published as RFC 2012." REVISION "9103310000Z" DESCRIPTION "The initial revision of this MIB module was part of MIB-II." ::= { mib-2 49 } -- the TCP base variables group Raghunarayan Standards Track [Page 4] RFC 4022 MIB for TCP March 2005 tcp OBJECT IDENTIFIER ::= { mib-2 6 } -- Scalars tcpRtoAlgorithm OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following constant(2), -- a constant rto rsre(3), -- MIL-STD-1778, Appendix B vanj(4), -- Van Jacobson's algorithm rfc2988(5) -- RFC 2988 } MAX-ACCESS read-only STATUS current DESCRIPTION "The algorithm used to determine the timeout value used for retransmitting unacknowledged octets." ::= { tcp 1 } tcpRtoMin OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend on the algorithm used to determine the retransmission timeout; in particular, the IETF standard algorithm rfc2988(5) provides a minimum value." ::= { tcp 2 } tcpRtoMax OBJECT-TYPE SYNTAX Integer32 (0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend on the algorithm used to determine the retransmission timeout; in particular, the IETF standard algorithm rfc2988(5) provides an upper bound (as part of an adaptive backoff algorithm)." ::= { tcp 3 } Raghunarayan Standards Track [Page 5] RFC 4022 MIB for TCP March 2005 tcpMaxConn OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The limit on the total number of TCP connections the entity can support. In entities where the maximum number of connections is dynamic, this object should contain the value -1." ::= { tcp 4 } tcpActiveOpens OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 5 } tcpPassiveOpens OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 6 } tcpAttemptFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times that TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." Raghunarayan Standards Track [Page 6] RFC 4022 MIB for TCP March 2005 ::= { tcp 7 } tcpEstabResets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 8 } tcpCurrEstab OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT." ::= { tcp 9 } tcpInSegs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments received, including those received in error. This count includes segments received on currently established connections. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 10 } tcpOutSegs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." Raghunarayan Standards Track [Page 7] RFC 4022 MIB for TCP March 2005 ::= { tcp 11 } tcpRetransSegs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments retransmitted; that is, the number of TCP segments transmitted containing one or more previously transmitted octets. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 12 } tcpInErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments received in error (e.g., bad TCP checksums). Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 14 } tcpOutRsts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of TCP segments sent containing the RST flag. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 15 } -- { tcp 16 } was used to represent the ipv6TcpConnTable in RFC 2452, -- which has since been obsoleted. It MUST not be used. tcpHCInSegs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments received, including those received in error. This count includes segments received Raghunarayan Standards Track [Page 8] RFC 4022 MIB for TCP March 2005 on currently established connections. This object is the 64-bit equivalent of tcpInSegs. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 17 } tcpHCOutSegs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets. This object is the 64-bit equivalent of tcpOutSegs. Discontinuities in the value of this counter are indicated via discontinuities in the value of sysUpTime." ::= { tcp 18 } -- The TCP Connection table tcpConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about existing TCP connections. Note that unlike earlier TCP MIBs, there is a separate table for connections in the LISTEN state." ::= { tcp 19 } tcpConnectionEntry OBJECT-TYPE SYNTAX TcpConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the tcpConnectionTable containing information about a particular current TCP connection. Each row of this table is transient in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state." INDEX { tcpConnectionLocalAddressType, tcpConnectionLocalAddress, tcpConnectionLocalPort, tcpConnectionRemAddressType, Raghunarayan Standards Track [Page 9] RFC 4022 MIB for TCP March 2005 tcpConnectionRemAddress, tcpConnectionRemPort } ::= { tcpConnectionTable 1 } TcpConnectionEntry ::= SEQUENCE { tcpConnectionLocalAddressType InetAddressType, tcpConnectionLocalAddress InetAddress, tcpConnectionLocalPort InetPortNumber, tcpConnectionRemAddressType InetAddressType, tcpConnectionRemAddress InetAddress, tcpConnectionRemPort InetPortNumber, tcpConnectionState INTEGER, tcpConnectionProcess Unsigned32 } tcpConnectionLocalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of tcpConnectionLocalAddress." ::= { tcpConnectionEntry 1 } tcpConnectionLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local IP address for this TCP connection. The type of this address is determined by the value of tcpConnectionLocalAddressType. As this object is used in the index for the tcpConnectionTable, implementors should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; otherwise the information cannot be accessed by using SNMPv1, SNMPv2c, or SNMPv3." ::= { tcpConnectionEntry 2 } tcpConnectionLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local port number for this TCP connection." ::= { tcpConnectionEntry 3 } tcpConnectionRemAddressType OBJECT-TYPE Raghunarayan Standards Track [Page 10] RFC 4022 MIB for TCP March 2005 SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of tcpConnectionRemAddress." ::= { tcpConnectionEntry 4 } tcpConnectionRemAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote IP address for this TCP connection. The type of this address is determined by the value of tcpConnectionRemAddressType. As this object is used in the index for the tcpConnectionTable, implementors should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; otherwise the information cannot be accessed by using SNMPv1, SNMPv2c, or SNMPv3." ::= { tcpConnectionEntry 5 } tcpConnectionRemPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port number for this TCP connection." ::= { tcpConnectionEntry 6 } tcpConnectionState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) } MAX-ACCESS read-write STATUS current Raghunarayan Standards Track [Page 11] RFC 4022 MIB for TCP March 2005 DESCRIPTION "The state of this TCP connection. The value listen(2) is included only for parallelism to the old tcpConnTable and should not be used. A connection in LISTEN state should be present in the tcpListenerTable. The only value that may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then the TCB (as defined in [RFC793]) of the corresponding connection on the managed node is deleted, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note, however, that RST segments are not sent reliably)." ::= { tcpConnectionEntry 7 } tcpConnectionProcess OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The system's process ID for the process associated with this connection, or zero if there is no such process. This value is expected to be the same as HOST-RESOURCES-MIB:: hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for some row in the appropriate tables." ::= { tcpConnectionEntry 8 } -- The TCP Listener table tcpListenerTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpListenerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about TCP listeners. A listening application can be represented in three possible ways: 1. An application that is willing to accept both IPv4 and IPv6 datagrams is represented by Raghunarayan Standards Track [Page 12] RFC 4022 MIB for TCP March 2005 a tcpListenerLocalAddressType of unknown (0) and a tcpListenerLocalAddress of ''h (a zero-length octet-string). 2. An application that is willing to accept only IPv4 or IPv6 datagrams is represented by a tcpListenerLocalAddressType of the appropriate address type and a tcpListenerLocalAddress of '0.0.0.0' or '::' respectively. 3. An application that is listening for data destined only to a specific IP address, but from any remote system, is represented by a tcpListenerLocalAddressType of an appropriate address type, with tcpListenerLocalAddress as the specific local address. NOTE: The address type in this table represents the address type used for the communication, irrespective of the higher-layer abstraction. For example, an application using IPv6 'sockets' to communicate via IPv4 between ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use InetAddressType ipv4(1))." ::= { tcp 20 } tcpListenerEntry OBJECT-TYPE SYNTAX TcpListenerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the tcpListenerTable containing information about a particular TCP listener." INDEX { tcpListenerLocalAddressType, tcpListenerLocalAddress, tcpListenerLocalPort } ::= { tcpListenerTable 1 } TcpListenerEntry ::= SEQUENCE { tcpListenerLocalAddressType InetAddressType, tcpListenerLocalAddress InetAddress, tcpListenerLocalPort InetPortNumber, tcpListenerProcess Unsigned32 } tcpListenerLocalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION Raghunarayan Standards Track [Page 13] RFC 4022 MIB for TCP March 2005 "The address type of tcpListenerLocalAddress. The value should be unknown (0) if connection initiations to all local IP addresses are accepted." ::= { tcpListenerEntry 1 } tcpListenerLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local IP address for this TCP connection. The value of this object can be represented in three possible ways, depending on the characteristics of the listening application: 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding tcpListenerLocalAddressType object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with tcpListenerLocalAddressType representing the appropriate address type. 3. For an application which is listening for data destined only to a specific IP address, the value of this object is the specific local address, with tcpListenerLocalAddressType representing the appropriate address type. As this object is used in the index for the tcpListenerTable, implementors should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; otherwise the information cannot be accessed, using SNMPv1, SNMPv2c, or SNMPv3." ::= { tcpListenerEntry 2 } tcpListenerLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local port number for this TCP connection." ::= { tcpListenerEntry 3 } Raghunarayan Standards Track [Page 14] RFC 4022 MIB for TCP March 2005 tcpListenerProcess OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The system's process ID for the process associated with this listener, or zero if there is no such process. This value is expected to be the same as HOST-RESOURCES-MIB:: hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for some row in the appropriate tables." ::= { tcpListenerEntry 4 } -- The deprecated TCP Connection table tcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A table containing information about existing IPv4-specific TCP connections or listeners. This table has been deprecated in favor of the version neutral tcpConnectionTable." ::= { tcp 13 } tcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A conceptual row of the tcpConnTable containing information about a particular current IPv4 TCP connection. Each row of this table is transient in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state." INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 } TcpConnEntry ::= SEQUENCE { tcpConnState INTEGER, tcpConnLocalAddress IpAddress, tcpConnLocalPort Integer32, tcpConnRemAddress IpAddress, tcpConnRemPort Integer32 Raghunarayan Standards Track [Page 15] RFC 4022 MIB for TCP March 2005 } tcpConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The state of this TCP connection. The only value that may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then the TCB (as defined in [RFC793]) of the corresponding connection on the managed node is deleted, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note, however, that RST segments are not sent reliably)." ::= { tcpConnEntry 1 } tcpConnLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The local IP address for this TCP connection. In the case of a connection in the listen state willing to accept connections for any IP interface associated with the node, the value 0.0.0.0 is used." ::= { tcpConnEntry 2 } Raghunarayan Standards Track [Page 16] RFC 4022 MIB for TCP March 2005 tcpConnLocalPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The local port number for this TCP connection." ::= { tcpConnEntry 3 } tcpConnRemAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The remote IP address for this TCP connection." ::= { tcpConnEntry 4 } tcpConnRemPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The remote port number for this TCP connection." ::= { tcpConnEntry 5 } -- conformance information tcpMIBConformance OBJECT IDENTIFIER ::= { tcpMIB 2 } tcpMIBCompliances OBJECT IDENTIFIER ::= { tcpMIBConformance 1 } tcpMIBGroups OBJECT IDENTIFIER ::= { tcpMIBConformance 2 } -- compliance statements tcpMIBCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems that implement TCP. A number of INDEX objects cannot be represented in the form of OBJECT clauses in SMIv2 but have the following compliance requirements, expressed in OBJECT clause form in this description clause: -- OBJECT tcpConnectionLocalAddressType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- This MIB requires support for only global IPv4 Raghunarayan Standards Track [Page 17] RFC 4022 MIB for TCP March 2005 -- and IPv6 address types. -- -- OBJECT tcpConnectionRemAddressType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- This MIB requires support for only global IPv4 -- and IPv6 address types. -- -- OBJECT tcpListenerLocalAddressType -- SYNTAX InetAddressType { unknown(0), ipv4(1), -- ipv6(2) } -- DESCRIPTION -- This MIB requires support for only global IPv4 -- and IPv6 address types. The type unknown also -- needs to be supported to identify a special -- case in the listener table: a listen using -- both IPv4 and IPv6 addresses on the device. -- " MODULE -- this module MANDATORY-GROUPS { tcpBaseGroup, tcpConnectionGroup, tcpListenerGroup } GROUP tcpHCGroup DESCRIPTION "This group is mandatory for systems that are capable of receiving or transmitting more than 1 million TCP segments per second. 1 million segments per second will cause a Counter32 to wrap in just over an hour." OBJECT tcpConnectionState SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, nor is support for the value deleteTCB (12)." ::= { tcpMIBCompliances 2 } tcpMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for IPv4-only systems that implement TCP. In order to be IP version independent, this compliance statement is deprecated in favor of tcpMIBCompliance2. However, agents are still encouraged to implement these objects in order to interoperate with the deployed base of managers." Raghunarayan Standards Track [Page 18] RFC 4022 MIB for TCP March 2005 MODULE -- this module MANDATORY-GROUPS { tcpGroup } OBJECT tcpConnState MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { tcpMIBCompliances 1 } -- units of conformance tcpGroup OBJECT-GROUP OBJECTS { tcpRtoAlgorithm, tcpRtoMin, tcpRtoMax, tcpMaxConn, tcpActiveOpens, tcpPassiveOpens, tcpAttemptFails, tcpEstabResets, tcpCurrEstab, tcpInSegs, tcpOutSegs, tcpRetransSegs, tcpConnState, tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort, tcpInErrs, tcpOutRsts } STATUS deprecated DESCRIPTION "The tcp group of objects providing for management of TCP entities." ::= { tcpMIBGroups 1 } tcpBaseGroup OBJECT-GROUP OBJECTS { tcpRtoAlgorithm, tcpRtoMin, tcpRtoMax, tcpMaxConn, tcpActiveOpens, tcpPassiveOpens, tcpAttemptFails, tcpEstabResets, tcpCurrEstab, tcpInSegs, tcpOutSegs, tcpRetransSegs, tcpInErrs, tcpOutRsts } STATUS current DESCRIPTION "The group of counters common to TCP entities." ::= { tcpMIBGroups 2 } tcpConnectionGroup OBJECT-GROUP OBJECTS { tcpConnectionState, tcpConnectionProcess } STATUS current DESCRIPTION "The group provides general information about TCP connections." ::= { tcpMIBGroups 3 } tcpListenerGroup OBJECT-GROUP OBJECTS { tcpListenerProcess } Raghunarayan Standards Track [Page 19] RFC 4022 MIB for TCP March 2005 STATUS current DESCRIPTION "This group has objects providing general information about TCP listeners." ::= { tcpMIBGroups 4 } tcpHCGroup OBJECT-GROUP OBJECTS { tcpHCInSegs, tcpHCOutSegs } STATUS current DESCRIPTION "The group of objects providing for counters of high speed TCP implementations." ::= { tcpMIBGroups 5 } END 4. Acknowledgements This document contains a modified subset of RFC 1213 and updates RFC 2012 and RFC 2452. Acknowledgements are therefore due to the authors and editors of these documents for their excellent work. Several useful comments regarding usability and design were also received from Kristine Adamson. The authors would like to thank all these people for their contribution to this effort. 5. References 5.1. Normative References [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DARPA, September 1981. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. Raghunarayan Standards Track [Page 20] RFC 4022 MIB for TCP March 2005 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 5.2. Informative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, March 1991. [RFC2012] McCloghrie, K., Ed., "SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2", RFC 2012, November 1996. [RFC2452] Daniele, M., "IP Version 6 Management Information Base for the Transmission Control Protocol", RFC 2452, December 1998. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", RFC 3418, December 2002. [VANJ] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988, Stanford, California. 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The tcpConnectionState and tcpConnState objects have a MAX-ACCESS clause of read-write, which allows termination of an arbitrary connection. Unauthorized access could cause a denial of service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to Raghunarayan Standards Track [Page 21] RFC 4022 MIB for TCP March 2005 control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o The tcpConnectionTable and the tcpConnTable contain objects providing information about the active connections on the device, the status of these connections, and the associated processes. This information may be used by an attacker to launch attacks against known/unknown weakness in certain protocols/applications. In addition, access to the connection table could also have privacy implications, as it provides detailed information on active connections. o The tcpListenerTable and the tcpConnTable contain objects providing information about listeners on an entity. For example, the tcpListenerLocalPort and tcpConnLocalPort objects can be used to identify what ports are open on the machine and what attacks are likely to succeed, without the attacker having to run a port scanner. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Raghunarayan Standards Track [Page 22] RFC 4022 MIB for TCP March 2005 7. Contributors This document is an output of the IPv6 MIB revision team, and contributors to earlier versions of this document include: Bill Fenner, AT&T Labs -- Research EMail: fenner@research.att.com Brian Haberman EMail: brian@innovationslab.net Shawn A. Routhier, Wind River EMail: shawn.routhier@windriver.com Juergen Schoenwalder, TU Braunschweig EMail: schoenw@ibr.cs.tu-bs.de Dave Thaler, Microsoft EMail: dthaler@windows.microsoft.com This document updates parts of the MIBs from several documents. RFC 2012 has been the base document for these updates, and RFC 2452 was the first document to define the managed objects for implementations of TCP over IPv6. RFC 2012: Keith McCloghrie, Cisco Systems (Editor) EMail: kzm@cisco.com RFC 2452: Mike Daniele, Compaq Computer Corporation EMail: daniele@zk3.dec.com Editor's Address Rajiv Raghunarayan Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: raraghun@cisco.com Raghunarayan Standards Track [Page 23] RFC 4022 MIB for TCP March 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Raghunarayan Standards Track [Page 24] snmp-mibs-downloader-1.1/mibrfcs/rfc4036.txt0000644000000000000000000016113211402176072015563 0ustar Network Working Group W. Sawyer Request for Comments: 4036 April 2005 Category: Standards Track Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. Table of Contents 1. The Internet-Standard Management Framework.................... 2 2. Conventions................................................... 2 3. Overview...................................................... 2 3.1. Structure of the MIB.................................... 4 3.1.1. docsSubMgtFilterGroupTable...................... 4 3.1.2. IPv4 Compliance................................. 5 3.2. Management Requirements................................. 5 3.2.1. Interaction with DOCSIS Provisioning for CPE Address Control................................. 6 3.2.2. Interaction with DOCSIS Provisioning for Filtering....................................... 6 3.2.3. Distinguishing Modem from Subscriber Traffic.... 7 Sawyer Standards Track [Page 1] RFC 4036 DOCSIS Subscriber Management MIB April 2005 3.3. Relationship to the Differentiated Services MIB [RFC3289]............................................... 7 3.3.1. Using the Filter Group to Extend Packet Classification.................................. 8 3.3.2. Interface Usage................................. 8 3.4. Filtering and the Tiny Fragment Attack.................. 9 4. Definitions................................................... 9 5. Acknowledgements.............................................. 23 6. IANA Considerations........................................... 23 7. Normative References.......................................... 23 8. Informative References........................................ 24 9. Security Considerations....................................... 25 Author's Address.................................................. 26 Full Copyright Statement.......................................... 27 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Overview This MIB module provides a set of objects required for the management of DOCSIS Cable Modem Termination Systems (CMTS). The specification is derived in part from the operational model described in the DOCSIS Radio Frequency Interface Specification [ITU-T-J122]. These managed objects facilitate protection of the cable network from misuse by subscribers. This misuse might include, for example, address spoofing, service spoofing, or operation of unauthorized services. Sawyer Standards Track [Page 2] RFC 4036 DOCSIS Subscriber Management MIB April 2005 The following figure illustrates the operational and physical deployment relationships between elements in a cable modem network. This MIB module resides at the CMTS, which is the first point in the public data network at which the cable operator controls physical access. The CMTS (possibly assisted by other IP service devices) acts as a network edge, separating the physical outside-plant cable television network from the operator's IP network. | operator's IP network +------+ --------------------- | CMTS | operator's cable head-end +------+ --------------------- | +--------+--------+ CATV physical network | | | +----+ +----+ +----+ ------------------ | CM | | CM | | CM | subscriber premises +----+ +----+ +----+ ------------------ | | | subscriber host or network This MIB module controls IP packet forwarding to and from each cable modem, at the CMTS. Different modems may be accorded different treatment. Much of this module duplicates capabilities found in the DOCSIS Cable Device MIB [RFC2669]. Although it is expected that the Cable Device MIB will be used to prevent unwanted traffic from entering the cable network, it is also possible that a malicious user might tamper with cable modem software, disabling its filtering policies. This MIB provides a more secure mechanism, as physical access to the CMTS is controlled by the network operator. In particular, this MIB provides two capabilities: first, to limit the IP addresses behind a modem, and second, to provide address and protocol filtering to and from a modem. The first duplicates the capabilities of the docsDevCpe group [RFC2669]. This provides for either learned or provisioned subscriber premises host IP addresses behind a cable modem. The address and protocol filtering capability is similar to that performed by the cable modem itself. It differs in several respects because it is intended to control subscriber traffic at the CMTS, rather than at the individual CM. First, the MIB structure must be indexed appropriately at the CMTS to indicate which cable modem subscriber is intended. Second, rather than maintaining a separate list of filters for each modem at the CMTS, it is assumed that large numbers of modems will share filtering characteristics. Therefore, modems are grouped so as to share common filter lists. Sawyer Standards Track [Page 3] RFC 4036 DOCSIS Subscriber Management MIB April 2005 The filtering capability is implemented using the Classification, Counting, and Drop facilities of the Differentiated Services MIB [RFC3289]. In order to provide different filtering for various classes of subscribers, this MIB defines the docsSubMgtFilterGroupTable, which specifies which filters apply to each subscriber packet. This table is used by RFC 3289 as a first pass of classification, and also to choose a second pass of classification using the diffServMultiFieldClfrTable: diffServDataPathStart --> diffServClfrEntry(1) diffServClfrElementSpecific(1) --> docsSubMgtFilterGroupIndex diffServClfrElementNext(1) --> diffServClfrEntry(2) diffServClfrElementSpecific(2)--> diffServMultiFieldClfrEntry diffServClfrElementNext(2) --> difServActionEntry (count or algDrop) Because it is assumed that large numbers of modems will share filtering characteristics, DOCSIS signaling defines filter groups according to which cable modems share common filter lists. The operator creates references to these groups in the diffServClfrElementSpecific(1) entries above. 3.1. Structure of the MIB This MIB is structured in four tables: o The docsSubMgtCpeControlTable controls the acceptance of subscriber host addresses behind a cable modem. o The docsSubMgtCpeIpTable monitors the subscriber host addresses that the CMTS believes exist behind the cable modem. o The docsSubMgtCmFilterTable binds a cable modem to a set of filters in diffServMultiFieldClfrTable. o The docsSubMgtFilterGroupTable provides the OIDs by which the diffServClfrElementTable selects a filter group. The docsSubMgtCpeControlTable and docsSubMgtCmFilterTable AUGMENT the docsIfCmtsCmStatusTable from [RFC2670]. Similarly, docsSubMgtCpeIpTable expands this table (an additional index is used). As such, each entry in these tables is bound to a registered cable modem, as perceived by the CMTS. 3.1.1. docsSubMgtFilterGroupTable The docsSubMgtFilterGroupTable links the filter group (signaled by DOCSIS as a small integer) to the diffServClfrElementEntry for the first pass of filter classification. diffServClfrElementSpecific Sawyer Standards Track [Page 4] RFC 4036 DOCSIS Subscriber Management MIB April 2005 requires a RowPointer. Thus, this table exists to provide referenced objects for diffServClfrElementSpecific. The classification method is as follows: o Use the DOCSIS filter group, as inferred from the sending or receiving modem, as the classification criterion. o Use docsSubMgtFilterGroupIndex as the value to match. An entry exists in this Table if a reference to it exists in diffServClfrElementSpecific. As such, contrary to common practice, the index for the table is read-only and is both the Entry's index and its only value. 3.1.2. IPv4 Compliance Please note that the compliance statements in this version of the MIB module require support only for IPv4 addresses. That is because the current version of the DOCSIS protocols (1.0, 1.1, and 2.0) are not IPv6 capable. Although support for IPv6 will require changes to the DOCSIS protocols, it is expected that the only changes to the MIB module itself will be the addition of new compliance statements that mandate support for IPv6 addresses. All IP addresses that appear in this document conform to the textual conventions specified in [RFC4001]. 3.2. Management Requirements The DOCSIS cable modem provisioning model [ITU-T-J122] requires that cable modems use TFTP to acquire a list of parameters. The modem then passes many of these parameters to the CMTS in the DOCSIS Registration message. The parameter values are digitally signed by the creator of the TFTP contents, and the signature is verified by the CMTS. In general, then, the CMTS itself need not be configured with the attributes of its cable modems. It will acquire these values through the Registration process that is secured by the digital signature. Cable modem subscriber management, as described here, modifies this process slightly to reduce data and to ease administrative control. Filtering criteria, for example, are maintained through SNMP at the CMTS, and the modem registration merely signals the index values for the rows that apply to that modem. Sawyer Standards Track [Page 5] RFC 4036 DOCSIS Subscriber Management MIB April 2005 3.2.1. Interaction with DOCSIS Provisioning for CPE Address Control The CMTS creates rows in docsSubMgtCpeControlTable for each modem as a result of the DOCSIS registration process. The DOCSIS registration attributes may include items semantically equivalent to those in the docsDevCpe section of the DOCSIS Cable Device MIB [RFC2669]: o docsDevCpeEnroll o docsDevCpeIpMax o docsDevCpeIp Successful DOCSIS registration will have the effect of setting the corresponding fields in the docsSubMgtCpeControlTable and the docsSubMgtCpeIpTable. If they are not present at modem registration, the CMTS shall apply the following: o docsSubMgtCpeControlActive <-- docsSubMgtCpeActiveDefault o docsSubMgtCpeControlMaxCpeIp <-- docsSubMgtCpeMaxIpDefault o docsSubMgtCpeControlLearnable <-- docsSubMgtCpeLearnableDefault Rows in docsSubMgtCpeIpTable are created through any of three ways: DOCSIS registration (as described above), learning by the CMTS, or some unspecified administrative mechanism on the CMTS. The docsDevCpeIpMax table bound applies only to the first two. The CMTS may learn addresses simply by snooping source IP addresses from traffic originating from each cable modem. Other learning mechanisms (for example, ARP snooping) may be used. The learning mechanism is not defined by this document. 3.2.2. Interaction with DOCSIS Provisioning for Filtering Rows in docsSubMgtCmFilterTable are created by the CMTS for each modem as a result of the DOCSIS registration process. The DOCSIS registration attributes may include four indices (see section C.1.1.18.3 of [ITU-T-J122]): o One identifying the upstream (ingress with respect to the CMTS interface) filter group for packets originating from the cable modem (i.e., those packets whose source MAC address matches that of the cable modem). o One identifying the upstream filter group for packets originating from subscribers attached to the cable modem (i.e., those packets whose source MAC address does not match that of the cable modem). Sawyer Standards Track [Page 6] RFC 4036 DOCSIS Subscriber Management MIB April 2005 o One identifying the downstream (egress with respect to the CMTS interface) filter group for packets destined to the cable modem (i.e., those packets whose destination MAC address matches that of the cable modem). o One identifying the downstream filter group for packets destined to subscribers attached to the cable modem (i.e., those packets whose destination MAC address does not match that of the cable modem). Successful registration will have the effect of setting docsSubMgtCmFilterCmDownstream, docsSubMgtCmFilterCmUpstream, docsSubMgtCmFilterSubDownstream, and docsSubMgtCmFilterSubUpstream, for that modem (just as if they were set through the SNMP protocol). If the DOCSIS attributes are not present, the four values are set to zero. The effect will be to use the default entry (diffServClfrElementSpecific=zeroDotZero) specified in the diffServClfrElementTable. Note that omission of the DOCSIS-signaled values results in application of the default filtering entry, not in omission of filtering. 3.2.3. Distinguishing Modem from Subscriber Traffic All traffic originating from or destined to a subscriber site is potentially suspect and subject to suppression by the network operator. This is true even if the traffic is ostensibly sourced or sunk by the cable modem itself, rather than by the subscriber hosts behind the modem. To provide more nuanced administrative control, this document allows separate filter policies for modems and hosts. For example, modem policies may limit modems to server subnet - only access while allowing a different scope to subscribers. The CMTS chooses the filter set to apply based solely on the MAC address (source MAC upstream, destination MAC downstream). If the MAC address matches that of the modem, then the docsSubMgtCmFilterCmUp/Downstream pair is used; otherwise, the docsSubMgtCmFilterSubUp/Downstream pair is applied. If the CM acts as a router rather than as a DOCSIS bridging forwarder, then the network operator will only use the docsSubMgtCmFilterCmUp/Downstream pair. 3.3. Relationship to the Differentiated Services MIB [RFC3289] DOCSIS CMTSes rely on the classification, counting, and drop facilities of the Differentiated Services MIB to screen subscriber packets for IP, TCP, and UDP characteristics. It is expected that Sawyer Standards Track [Page 7] RFC 4036 DOCSIS Subscriber Management MIB April 2005 any implementation of this MIB also includes at least the following from RFC 3289: o diffServDataPathTable o diffServClfrTable o diffServClfrElementTable o diffServMultiFieldClfrTable o diffServActionTable o diffServCountActTable o diffServAlgDropTable (diffServAlgDropType=alwaysDrop) The corresponding "next-free" objects are also required. The use of other facilities from RFC 3289 is not precluded but is beyond the scope of this specification. 3.3.1. Using the Filter Group to Extend Packet Classification The base capability of RFC 3289 assumes that all packets on the same direction of the same interface will be classified by the same criteria. Filter Groups, which are introduced in this document, expand on RFC 3289 to allow various subscribers to receive different classification (filtering) treatment. One way to view filter groups is as sub-interfaces within the physical DOCSIS channel. Another way to view them is as values of a field logically prepended to the packet prior to classification: [filter group][DOCSIS MAC header][IP header]... Of course this 'logical' field has no existence outside of the CMTS. The diffServClfrTable and diffServClfrElementTable are then used twice: the first classifiers select among filter groups, using OIDs from docsSubMgtFilterGroupTable. The 'next' action on matching a filter group is to select a diffServClfrEntry that now classifies on IP/TCP/UDP criteria (the diffServMultiFieldClfrTable). The 'next' action on this second match may be a 'count' (and accept), a 'drop', or some other feature from RFC 3289. 3.3.2. Interface Usage For the purposes of DOCSIS subscriber management, only the DOCSIS MAC cable interface(s) are used. The interface appears as the index to diffServDataPathEntry, which is the starting point for diffserv MIB table traversal. Sawyer Standards Track [Page 8] RFC 4036 DOCSIS Subscriber Management MIB April 2005 The use of the diffserv MIB for other purposes, both on the DOCSIS MAC interfaces and on other network interfaces, is not precluded by this document. 3.4. Filtering and the Tiny Fragment Attack It is recommended that the implementers prevent the "tiny fragment" and "overlapping fragment" attacks for the TCP filtering tables in this MIB, as discussed in RFC 1858 [RFC1858] and RFC 3128 [RFC3128]. Prevention of these attacks can be implemented with the following rules, when filtering is enabled: o Admit all packets with fragment offset >= 2. o Discard all packets with fragment offset = 1, or with fragment offset = 0 AND fragment payload length < 16. o Apply filtering rules to all packets with fragment offset = 0. 4. Definitions DOCS-IETF-SUBMGT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, mib-2 FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp, StorageType FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF InetAddressType, InetAddress FROM INET-ADDRESS-MIB docsIfCmtsCmStatusIndex, docsIfCmtsCmStatusEntry FROM DOCS-IF-MIB -- RFC2670 diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, Sawyer Standards Track [Page 9] RFC 4036 DOCSIS Subscriber Management MIB April 2005 diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBCounterGroup, diffServDataPathStatus, diffServClfrStatus, diffServClfrElementStatus, diffServMultiFieldClfrAddrType, diffServMultiFieldClfrSrcAddr, diffServMultiFieldClfrDstAddr, diffServAlgDropStatus, diffServDataPathStorage, diffServClfrStorage, diffServClfrElementStorage, diffServMultiFieldClfrStorage, diffServActionStorage, diffServCountActStorage, diffServAlgDropStorage, diffServAlgDropType FROM DIFFSERV-MIB -- RFC3289 ; docsSubMgt MODULE-IDENTITY LAST-UPDATED "200503290000Z" -- March 29, 2005 ORGANIZATION "IETF IP over Cable Data Network (IPCDN) Working Group" CONTACT-INFO " Wilson Sawyer Postal: 50 Kelly Brook Lane East Hampstead, NH 03826 U.S.A. Phone: +1 603 382 7080 E-mail: wsawyer@ieee.org IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, Richard_Woundy@cable.comcast.com Jean-Francois Mule, jf.mule@cablelabs.com" DESCRIPTION "This is the CMTS centric subscriber management MIB for DOCSIS-compliant CMTS. It provides the objects to allow a Cable Modem Termination operator to control the IP addresses and protocols associated with subscribers' cable modems. Sawyer Standards Track [Page 10] RFC 4036 DOCSIS Subscriber Management MIB April 2005 Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4036; see the RFC itself for full legal notices." REVISION "200503290000Z" -- March 29, 2005 DESCRIPTION "Initial version, published as RFC 4036. Note that the compliance statements in this version apply only to implementations that support DOCSIS 1.0/1.1/2.0, which are not IPv6-capable." ::= { mib-2 125 } docsSubMgtObjects OBJECT IDENTIFIER ::= { docsSubMgt 1 } docsSubMgtCpeControlTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtCpeControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table AUGMENTs the docsIfCmtsCmStatusTable, adding four WRITEable objects, as well as a read-only object, all of which reflect the state of subscriber management on a particular CM." ::= { docsSubMgtObjects 1 } docsSubMgtCpeControlEntry OBJECT-TYPE SYNTAX DocsSubMgtCpeControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the docsSubMgtCpeControlTable. All values are set at successful modem registration, either from the system default, or from objects included in the DOCSIS registration request sent upstream to the CMTS from the CM. The contents of this entry are meaningless unless the corresponding docsIfCmtsCmStatusValue (see reference) is registrationComplete(6). The persistence of this row is determined solely by the lifespan of the corresponding docsIfCmtsCmStatusEntry (normally StorageType=volatile)." REFERENCE "RFC 2670" AUGMENTS { docsIfCmtsCmStatusEntry } ::= {docsSubMgtCpeControlTable 1 } DocsSubMgtCpeControlEntry ::= SEQUENCE { docsSubMgtCpeControlMaxCpeIp Integer32, docsSubMgtCpeControlActive TruthValue, docsSubMgtCpeControlLearnable TruthValue, Sawyer Standards Track [Page 11] RFC 4036 DOCSIS Subscriber Management MIB April 2005 docsSubMgtCpeControlReset TruthValue, docsSubMgtCpeControlLastReset TimeStamp } docsSubMgtCpeControlMaxCpeIp OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The number of simultaneous IP addresses permitted behind the CM. If this is set to zero, all CPE traffic from the CM is dropped. If the provisioning object corresponding to docsSubMgtCpeIpTable includes more CPE IP address entries for this modem than the value of this object, then this object is set to the count of the number of rows in docsSubMgtCpeIpTable that have the same docsIfCmtsCmStatusIndex value. (For example, if the CM has 5 IP addresses specified for it, this value is 5.) This limit applies to learned and DOCSIS-provisioned entries but not to entries added through some administrative process at the CMTS. If not set through DOCSIS provisioning, this object defaults to docsSubMgtCpeMaxIpDefault. Note that this object is only meaningful if docsSubMgtCpeControlActive is true." ::= { docsSubMgtCpeControlEntry 1 } docsSubMgtCpeControlActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the application of subscriber management to this cable modem. If this is set to true, CMTS-based CPE control is active, and all the actions required by the various filter tables and controls apply at the CMTS. If this is set to false, no subscriber management filtering is done at the CMTS (but other filters may apply). If not set through DOCSIS provisioning, this object defaults to docsSubMgtCpeActiveDefault." ::= { docsSubMgtCpeControlEntry 2 } docsSubMgtCpeControlLearnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Controls whether the CMTS may learn (and pass traffic for) CPE IP addresses associated with a cable modem. If this is set to true, the CMTS may learn up to docsSubMgtMaxCpeIp Sawyer Standards Track [Page 12] RFC 4036 DOCSIS Subscriber Management MIB April 2005 addresses (less any DOCSIS-provisioned entries) related to this CM. Those IP addresses are added (by internal process) to the docsSubMgtCpeIpTable. The nature of the learning mechanism is not specified here. If not set through DOCSIS provisioning, this object defaults to docsSubMgtCpeLearnableDefault. Note that this object is only meaningful if docsSubMgtCpeControlActive is true." ::= { docsSubMgtCpeControlEntry 3 } docsSubMgtCpeControlReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object always returns false on read. If this object is set to true, the rows with 'learned' addresses in docsSubMgtCpeIpTable for this CM are deleted from that table." ::= { docsSubMgtCpeControlEntry 4 } docsSubMgtCpeControlLastReset OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when docsSubMgtCpeControlReset was last set true. Zero if never reset." DEFVAL { 0 } ::= { docsSubMgtCpeControlEntry 5 } docsSubMgtCpeMaxIpDefault OBJECT-TYPE SYNTAX Integer32(0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "The default value for docsSubMgtCpeControlMaxCpeIp if not signaled in the DOCSIS Registration request. This value should be treated as nonvolatile; if set, its value should persist across device resets." DEFVAL { 16 } ::= { docsSubMgtObjects 2 } docsSubMgtCpeActiveDefault OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The default value for docsSubMgtCpeControlActive if not Sawyer Standards Track [Page 13] RFC 4036 DOCSIS Subscriber Management MIB April 2005 signaled in the DOCSIS Registration request. This value should be treated as nonvolatile; if set, its value should persist across device resets." DEFVAL { false } ::= { docsSubMgtObjects 3 } docsSubMgtCpeLearnableDefault OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The default value for docsSubMgtCpeControlLearnable if not signaled in the DOCSIS Registration request. This value should be treated as nonvolatile; if set, its value should persist across device resets." DEFVAL { true } ::= { docsSubMgtObjects 4 } docsSubMgtCpeIpTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtCpeIpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of CPE IP addresses known on a per-CM basis." ::= { docsSubMgtObjects 5 } docsSubMgtCpeIpEntry OBJECT-TYPE SYNTAX DocsSubMgtCpeIpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the docsSubMgtCpeIpTable. The first index is the specific modem we're referring to, and the second index is the specific CPE IP entry." INDEX { docsIfCmtsCmStatusIndex, docsSubMgtCpeIpIndex } ::= {docsSubMgtCpeIpTable 1 } DocsSubMgtCpeIpEntry ::= SEQUENCE { docsSubMgtCpeIpIndex Integer32, docsSubMgtCpeIpAddressType InetAddressType, docsSubMgtCpeIpAddr InetAddress, docsSubMgtCpeIpLearned TruthValue } docsSubMgtCpeIpIndex OBJECT-TYPE SYNTAX Integer32(1..2147483647) Sawyer Standards Track [Page 14] RFC 4036 DOCSIS Subscriber Management MIB April 2005 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this CPE IP address relative to the indexed CM. An entry is created either through the included CPE IP addresses in the provisioning object, or via learning. If docsSubMgtCpeControlActive is true and a CMTS receives an IP packet from a CM that contains a source IP address that does not match one of the docsSubMgtCpeIpAddr entries for this CM, one of two things occurs. If the number of entries is less than docsSubMgtCpeControlMaxCpeIp, the source address is added to the table and the packet is forwarded. If the number of entries equals the docsSubMgtCpeControlMaxCpeIp, then the packet is dropped." ::= { docsSubMgtCpeIpEntry 1 } docsSubMgtCpeIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of internet address of docsSubMgtCpeIpAddr." ::= { docsSubMgtCpeIpEntry 2 } docsSubMgtCpeIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address either set from provisioning or learned via address gleaning or other forwarding means. See docsSubMgtCpeIpIndex for the mechanism. The type of this address is determined by the value of docsSubMgtCpeIpAddressType." ::= { docsSubMgtCpeIpEntry 3 } docsSubMgtCpeIpLearned OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true, this entry was learned from IP packets sent upstream rather than from the provisioning objects." ::= { docsSubMgtCpeIpEntry 4 } docsSubMgtCmFilterTable OBJECT-TYPE Sawyer Standards Track [Page 15] RFC 4036 DOCSIS Subscriber Management MIB April 2005 SYNTAX SEQUENCE OF DocsSubMgtCmFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Binds filter groups to modems, identifying for each modem the upstream and downstream filter groups that apply to packets for that modem. Normally, this table reflects the filter group values signaled by DOCSIS Registration, although values may be overridden by management action. For each of the columns in this table, zero is a distinguished value, indicating that the default filtering action is to be taken rather than that associated with a filter group number. Zero is used if the filter group is not signaled by DOCSIS registration." ::= { docsSubMgtObjects 6 } docsSubMgtCmFilterEntry OBJECT-TYPE SYNTAX DocsSubMgtCmFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Binds a filter group to each direction of traffic for a modem. The filters in this entry apply if docsSubMgtCpeControlActive is true. The contents of this entry are meaningless unless the corresponding docsIfCmtsCmStatusValue (see reference) is registrationComplete(6). The persistence of this row is determined solely by the lifespan of the corresponding docsIfCmtsCmStatusEntry (normally StorageType=volatile)." REFERENCE "RFC 2670" AUGMENTS { docsIfCmtsCmStatusEntry } ::= {docsSubMgtCmFilterTable 1 } DocsSubMgtCmFilterEntry ::= SEQUENCE { docsSubMgtCmFilterSubDownstream Integer32, docsSubMgtCmFilterSubUpstream Integer32, docsSubMgtCmFilterCmDownstream Integer32, docsSubMgtCmFilterCmUpstream Integer32 } docsSubMgtCmFilterSubDownstream OBJECT-TYPE SYNTAX Integer32(0..65535) MAX-ACCESS read-write STATUS current Sawyer Standards Track [Page 16] RFC 4036 DOCSIS Subscriber Management MIB April 2005 DESCRIPTION "The filter group applied to traffic destined for subscribers attached to the referenced CM. Upon row creation, this is set either to zero (use default classification, the diffServClfrElementSpecific=zeroDotZero row of diffServClfrElementTable) or to the value in the provisioning object sent upstream from the CM to the CMTS during registration. The value of this object is the same as that of the filter group index appearing as docsSubMgtFilterGroupIndex." ::= { docsSubMgtCmFilterEntry 1 } docsSubMgtCmFilterSubUpstream OBJECT-TYPE SYNTAX Integer32(0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The filter group applied to traffic originating from subscribers attached to the referenced CM. Upon row creation this is set to either zero (use default classification, the diffServClfrElementSpecific=zeroDotZero row of diffServClfrElementTable), or to the value in the provisioning object sent upstream from the CM to the CMTS. The value of this object is the same as that of the filter group index appearing as docsSubMgtFilterGroupIndex." ::= { docsSubMgtCmFilterEntry 2 } docsSubMgtCmFilterCmDownstream OBJECT-TYPE SYNTAX Integer32(0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The filter group applied to traffic destined for the referenced CM itself. Upon row creation this is set either to zero (use default classification, the diffServClfrElementSpecific=zeroDotZero row of diffServClfrElementTable), or to the value in the provisioning object sent upstream from the CM to the CMTS during registration. The value of this object is the same as that of the filter group index appearing as docsSubMgtFilterGroupIndex." ::= { docsSubMgtCmFilterEntry 3 } docsSubMgtCmFilterCmUpstream OBJECT-TYPE SYNTAX Integer32(0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The filter group applied to traffic originating from the referenced CM itself. This is set upon row creation to either Sawyer Standards Track [Page 17] RFC 4036 DOCSIS Subscriber Management MIB April 2005 zero (use default classification, the diffServClfrElementSpecific=zeroDotZero row of diffServClfrElementTable), or to the value in the provisioning object sent upstream from the CM to the CMTS during registration. The value of this object is the same as the filter group index appearing as docsSubMgtFilterGroupIndex." ::= { docsSubMgtCmFilterEntry 4 } docsSubMgtFilterGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtFilterGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides a collection of referenceable entries to which diffServClfrElementSpecific refers. This table provides filter group indices that can be compared with those signaled during DOCSIS registration. A packet matches an entry from this table if the packet originated from or is destined to a cable modem that registered this index as one of its four filter groups (see docsSubMgtCmFilterTable), and if the packet direction and MAC address select the use of this index among the four." ::= { docsSubMgtObjects 7 } docsSubMgtFilterGroupEntry OBJECT-TYPE SYNTAX DocsSubMgtFilterGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry only exists if needed by the diffServClfrElementEntry. A packet matches this entry if the packet's cable modem registered this index as one of its four filter groups (see docsSubMgtCmFilterTable) and if the packet direction and MAC address select the use of this index among the four." INDEX { docsSubMgtFilterGroupIndex } ::= { docsSubMgtFilterGroupTable 1 } DocsSubMgtFilterGroupEntry ::= SEQUENCE { docsSubMgtFilterGroupIndex Integer32 } docsSubMgtFilterGroupIndex OBJECT-TYPE SYNTAX Integer32(1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The filter group index, from the set signaled at DOCSIS Sawyer Standards Track [Page 18] RFC 4036 DOCSIS Subscriber Management MIB April 2005 Registration. Provides a referenceable entry to which diffServClfrElementSpecific points. A packet matches this classifier entry if the packet's cable modem registered this index value as one of its four filter groups, and if the packet direction and MAC address select the use of this index among the four. Because this is the only field in this table, it is read-only, contrary to the usual SMI custom of making indices not-accessible. Note that although zero may be signaled (or defaulted) at DOCSIS Registration to indicate a default filtering group, no such entry appears in this table, as diffServClfrElementSpecific will use a zeroDotZero pointer for that classification." ::= { docsSubMgtFilterGroupEntry 1 } docsSubMgtConformance OBJECT IDENTIFIER ::= { docsSubMgt 2 } docsSubMgtCompliances OBJECT IDENTIFIER ::= { docsSubMgtConformance 1 } docsSubMgtGroups OBJECT IDENTIFIER ::= { docsSubMgtConformance 2 } docsSubMgtBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CMTS devices that implement CMTS centric subscriber management. This compliance statement applies to implementations that support DOCSIS 1.0/1.1/2.0, which are not IPv6 capable." MODULE DIFFSERV-MIB -- RFC3289 MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBCounterGroup } OBJECT diffServDataPathStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." Sawyer Standards Track [Page 19] RFC 4036 DOCSIS Subscriber Management MIB April 2005 OBJECT diffServClfrStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServClfrElementStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServMultiFieldClfrAddrType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServMultiFieldClfrSrcAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServMultiFieldClfrDstAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServAlgDropStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServDataPathStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServClfrStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." Sawyer Standards Track [Page 20] RFC 4036 DOCSIS Subscriber Management MIB April 2005 OBJECT diffServClfrElementStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServMultiFieldClfrStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServActionStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServCountActStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServAlgDropStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServAlgDropType SYNTAX INTEGER { alwaysDrop(5) } DESCRIPTION "For DOCSIS subscriber management, this object is only used to provide packet filtering. Implementations need not support other values of this enumeration." MODULE -- This module i.e., DOCS-IETF-SUBMGT-MIB MANDATORY-GROUPS { docsSubMgtGroup } OBJECT docsSubMgtCpeControlMaxCpeIp SYNTAX Integer32(0..16) DESCRIPTION "An implementation is only required to support up to sixteen addresses per modem." Sawyer Standards Track [Page 21] RFC 4036 DOCSIS Subscriber Management MIB April 2005 OBJECT docsSubMgtCpeMaxIpDefault SYNTAX Integer32(0..16) DESCRIPTION "An implementation is only required to support up to sixteen addresses per modem." OBJECT docsSubMgtCpeIpAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtCpeIpAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtCmFilterSubDownstream SYNTAX Integer32(0..30) DESCRIPTION "An implementation is only required to support thirty filter groups." OBJECT docsSubMgtCmFilterSubUpstream SYNTAX Integer32(0..30) DESCRIPTION "An implementation is only required to support thirty filter groups." OBJECT docsSubMgtCmFilterCmDownstream SYNTAX Integer32(0..30) DESCRIPTION "An implementation is only required to support thirty filter groups." OBJECT docsSubMgtCmFilterCmUpstream SYNTAX Integer32(0..30) DESCRIPTION "An implementation is only required to support thirty filter groups." ::= { docsSubMgtCompliances 1 } docsSubMgtGroup OBJECT-GROUP OBJECTS { docsSubMgtCpeControlMaxCpeIp, docsSubMgtCpeControlActive, Sawyer Standards Track [Page 22] RFC 4036 DOCSIS Subscriber Management MIB April 2005 docsSubMgtCpeControlLearnable, docsSubMgtCpeControlReset, docsSubMgtCpeControlLastReset, docsSubMgtCpeMaxIpDefault, docsSubMgtCpeActiveDefault, docsSubMgtCpeLearnableDefault, docsSubMgtCpeIpAddressType, docsSubMgtCpeIpAddr, docsSubMgtCpeIpLearned, docsSubMgtCmFilterSubDownstream, docsSubMgtCmFilterSubUpstream, docsSubMgtCmFilterCmDownstream, docsSubMgtCmFilterCmUpstream, docsSubMgtFilterGroupIndex } STATUS current DESCRIPTION "The objects used to manage host-based cable modems via a set of CMTS enforced controls." ::= { docsSubMgtGroups 1 } END 5. Acknowledgements This document is based on work by Michael St. Johns, then at Excite@Home. Thanks to Guenter Roeck and Julie McGray for reviewing earlier versions. Thanks to Bert Wijnen, Mike Heard, and Harrie Hazewinkel for extensive later review. Thanks to the working group chairs, Richard Woundy and Jean-Francois Mule, for their extensive support. 6. IANA Considerations The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- docsSubMgt { mib-2 125} 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Sawyer Standards Track [Page 23] RFC 4036 DOCSIS Subscriber Management MIB April 2005 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [ITU-T-J122] Second-Generation Transmission Systems for Interactive Cable Television Services, J.122, ITU-T, December, 2002. [RFC2670] St. Johns, M., "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 8. Informative References [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC2669] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Sawyer Standards Track [Page 24] RFC 4036 DOCSIS Subscriber Management MIB April 2005 [DOCSBPI] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification SP-BPI+- I11-040407", DOCSIS, April 2004, available at http://www.cablemodem.com/ and at http://www.cablelabs.com/specifications/archives. 9. Security Considerations This MIB is intended to limit certain kinds of network behavior by subscriber hosts attached to cable modems, including, for example, IP spoofing. These limitations may be compromised, however, if the cable modem's identity or registration process is spoofed. The DOCSIS RFI and privacy specifications [ITU-T-J122] and [DOCSBPI] define a number of mechanisms for assuring modem identity. For network filtering of TCP traffic to be effective, implementors MUST follow the recommendations in section 3.4. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. These objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Unauthorized SETs to this MIB can permit two major security problems with public cable network operation: IP address spoofing, and defeat of operator-defined packet filtering. The following objects, if SET maliciously, would evade controls on address spoofing: docsSubMgtCpeControlMaxCpeIp docsSubMgtCpeControlActive docsSubMgtCpeControlLearnable docsSubMgtCpeControlReset docsSubMgtCpeMaxIpDefault docsSubMgtCpeActiveDefault docsSubMgtCpeLearnableDefault The following objects could also permit packet filtering to be defeated: docsSubMgtCmFilterSubDownstream docsSubMgtCmFilterSubUpstream docsSubMgtCmFilterCmDownstream docsSubMgtCmFilterCmUpstream Sawyer Standards Track [Page 25] RFC 4036 DOCSIS Subscriber Management MIB April 2005 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET access to these objects and possibly even to encrypt the values of these objects when they are sent over the network via SNMP. The most sensitive is docsSubMgtCpeIpAddr within docsSubMgtCpeIpTable. Although docsSubMgtCpeIpTable is intended to control address spoofing, it includes information about the current subscriber address pool. This information may in itself be valuable to would-be spoofers. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) who have legitimate rights to GET or SET (change/create/delete) them. Author's Address Wilson Sawyer 50 Kelly Brook Lane East Hampstead NH 03826 Phone: +1 603 382 7080 EMail: wsawyer@ieee.org Sawyer Standards Track [Page 26] RFC 4036 DOCSIS Subscriber Management MIB April 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sawyer Standards Track [Page 27] snmp-mibs-downloader-1.1/mibrfcs/rfc4044.txt0000644000000000000000000037025411402176072015571 0ustar Network Working Group K. McCloghrie Request for Comments: 4044 Cisco Systems, Inc Obsoletes: 2837 May 2005 Category: Standards Track Fibre Channel Management MIB 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. Table of Contents 1. Introduction ................................................. 2 2. The Internet-Standard Management Framework ................... 2 3. Short Overview of the Fibre Channel .......................... 2 4. MIB Overview ................................................. 3 4.1. The fcmInstanceBasicGroup Group ........................ 3 4.2. The fcmSwitchBasicGroup Group .......................... 4 4.3. The fcmPortBasicGroup Group ............................ 4 4.4. The fcmPortStatsGroup Group ............................ 4 4.5. The fcmPortClass23StatsGroup Group ..................... 4 4.6. The fcmPortLcStatsGroup Group .......................... 4 4.7. The fcmPortClassFStatsGroup Group ...................... 4 4.8. The fcmPortErrorsGroup Group ........................... 4 4.9. The fcmSwitchPortGroup Group ........................... 5 4.10. The fcmSwitchLoginGroup Group .......................... 5 4.11. The fcmLinkBasicGroup Group ............................ 5 5. Relationship to Other MIBs ................................... 5 5.1. The Interfaces Group MIB ............................... 5 5.2. Entity MIB ............................................. 8 5.3. Host Resources MIB ..................................... 9 McCloghrie Standards Track [Page 1] RFC 4044 Fibre Channel Management MIB May 2005 6. Definitions .................................................. 9 7. Acknowledgements ............................................. 57 8. Normative References ......................................... 57 9. Informative References ....................................... 58 10. Security Considerations ...................................... 59 11. IANA Considerations .......................................... 60 11.1. OID Assignment ......................................... 60 11.2. FC Port Type Registry .................................. 60 12. Comparison to the Fibre Channel Management Integration MIB ... 62 12.1. Problems with the Fibre Channel Management Integration MIB .................................................... 62 12.2. Detailed Changes ....................................... 62 13. Comparison to RFC 2837 ....................................... 67 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of the Fibre Channel The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance capability. The Fibre Channel provides a general transport vehicle for higher level protocols such as Intelligent Peripheral Interface (IPI) and Small Computer System Interface (SCSI) command sets, the High-Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, the Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a McCloghrie Standards Track [Page 2] RFC 4044 Fibre Channel Management MIB May 2005 switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port refers to either an N_Port or an NL_port. The term Fx_Port refers to either an F_Port or an FL_port. A switch port, which is interconnected to another switch port via an Inter Element Link (IEL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the fabric, each node, and most ports, have globally-unique names. These globally-unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [WWN1] and [WWN2]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has an address identifier and a WWN. When a fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. 4. MIB Overview This MIB contains the notion of a Fibre Channel management instance, which is defined as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. To represent such multiple Fibre Channel management instances within the same SNMP context (see section 3.3.1 of [RFC3411]), all tables in this MIB are INDEX-ed by fcmInstanceIndex, which is defined as an arbitrary integer to uniquely identify a particular Fibre Channel management instance. This MIB contains eleven MIB groups, as follows. 4.1. The fcmInstanceBasicGroup Group This group contains basic information about a Fibre Channel managed instance, including its name and description, the Fibre Channel function(s) it performs, and optional pointers to hardware and/or software components. McCloghrie Standards Track [Page 3] RFC 4044 Fibre Channel Management MIB May 2005 4.2. The fcmSwitchBasicGroup Group This group contains basic information about a Fibre Channel switch, including its domain-id and whether it is the principal switch of its fabric. 4.3. The fcmPortBasicGroup Group This group contains basic information about a Fibre Channel port, including its port name (WWN), the name of the node (if any) of which it is a part, the type of port, the classes of service it supports, its transmitter and connector types, and the higher level protocols it supports. Each Fibre Channel port is represented by an entry in the ifTable (see below). The tables relating to ports in this MIB are indexed by the port's value of ifIndex. 4.4. The fcmPortStatsGroup Group This group contains traffic statistics, which are not specific to any particular class of service, for Fibre Channel ports. 4.5. The fcmPortClass23StatsGroup Group This group contains traffic statistics that are specific to Class 2 or Class 3 traffic on Fibre Channel ports, including class-specific frame and octet counters and counters of busy and reject frames. 4.6. The fcmPortLcStatsGroup Group Some of the statistics in the fcmPortClass23StatsGroup can increase rapidly enough to warrant them being defined using the Counter64 syntax. However, some old SNMP systems do not (yet) support Counter64 objects. Thus, this group defines low-capacity (Counter32-based) equivalents for the Counter64-based statistics in the fcmPortClass23StatsGroup group. 4.7. The fcmPortClassFStatsGroup Group This group contains traffic statistics that are specific to Class F traffic on the E_Ports of a Fibre Channel switch. 4.8. The fcmPortErrorsGroup Group This group contains counters of various error conditions that can occur on Fibre Channel ports. McCloghrie Standards Track [Page 4] RFC 4044 Fibre Channel Management MIB May 2005 4.9. The fcmSwitchPortGroup Group This group contains information about ports on a Fibre Channel switch. For an Fx_Port, it includes the port's timeout values, its hold-time, and its capabilities in terms of maximum and minimum buffer-to-buffer credit allocations, maximum and minimum data field sizes, and support for class 2 and class 3 sequenced delivery. For an E_Port or B_Port, it includes the buffer-to-buffer credit allocation and data field size. 4.10. The fcmSwitchLoginGroup Group This group contains information, known to a Fibre Channel switch, about its attached/logged-in Nx_Ports and the service parameters that have been agreed with them. 4.11. The fcmLinkBasicGroup Group This group contains information known to a local Fibre Channel management instance, and concerning Fibre Channel links including those which terminate locally. 5. Relationship to Other MIBs This MIB is a replacement for two other MIBs: RFC 2837, and the Fibre Channel Management Integration MIB which was originally submitted as an Internet Draft to the IETF's IPFC Working Group, and is now available as [MIB-FA]. 5.1. The Interfaces Group MIB The Interfaces Group MIB [RFC2863] contains generic information about all lower layer interfaces, i.e., interfaces which are (potentially) below the internet layer. Thus, each Fibre Channel port should have its own row in the ifTable, and that row will contain the generic information about the interface/port. The Interfaces Group MIB specifies that additional information which is specific to a particular type of interface media, should be defined in a media- specific MIB. This MIB is the media-specific MIB for Fibre Channel ports/interfaces. Section 4 of [RFC2863] requires that a media-specific MIB clarify how the generic definitions apply for the particular type of media. The clarifications for Fibre Channel interfaces are as follows. McCloghrie Standards Track [Page 5] RFC 4044 Fibre Channel Management MIB May 2005 5.1.1. Layering Model The Interfaces Group MIB permits multiple ifTable entries to be defined for interface sub-layers, and for those multiple entries to be arranged in a stack. For Fibre Channel interfaces, no sublayers are defined and a Fibre Channel interface will typically have no other ifTable rows stacked on top of it, nor underneath it. 5.1.2. Virtual Circuits This Fibre Channel MIB does not deal with virtual circuits. 5.1.3. ifRcvAddressTable The ifRcvAddressTable does not apply to Fibre Channel interfaces. 5.1.4. ifType The value of ifType for a Fibre Channel interface is 56. 5.1.5. ifXxxOctets The definitions of ifInOctets and ifOutOctets (and similarly, ifHCInOctets and ifHCOutOctets) specify that their values include framing characters. For Fibre Channel interfaces, they include all the octets contained in frames between the Start-of-Frame and End- of-Frame delimiters (excluding the delimiters). 5.1.6. Specific Interface Group MIB Objects The following table provides specific implementation guidelines for applying the objects defined in the Interfaces Group MIB to Fibre Channel interfaces. For those objects not listed here, refer to their generic definitions in [RFC2863]. (RFC 2863 takes precedence over these guidelines in the event of any conflict.) Object Guidelines ifType 56 ifMtu The MTU as seen by a higher layer protocol, like IP. That is, when IP is running over the interface, this object is the size of the largest IP datagram that can be sent/received over the interface. McCloghrie Standards Track [Page 6] RFC 4044 Fibre Channel Management MIB May 2005 ifSpeed For 1Gbs, this will be 1,000,000,000; for 2Gbs, it will be 2,000,000,000. If auto-negotiation is implemented and enabled on an interface, and the interface has not yet negotiated an operational speed, this object SHOULD reflect the maximum speed supported by the interface. ifPhysAddress The interface's 24-bit Fibre Channel Address Identifier, or the zero-length string if no Address Identifier has been assigned to the interface. ifAdminStatus Write access is not required, and support for 'testing' is not required. ifOperStatus Support for 'testing' is not required. The value 'dormant' has no meaning for Fibre Channel interfaces. ifInOctets The number of octets of information ifHCInOctets contained in received frames between the Start-of-Frame and End-of-Frame delimiters (excluding the delimiters). ifInUcastPkts The number of unicast frames received, ifHCInUcastPkts i.e., the number of Start-of-Frame delimiters received for unicast frames. ifInErrors The sum for this interface of fcmPortLossofSynchs fcmPortLossofSignals fcmPortPrimSeqProtocolErrors fcmPortInvalidTxWords fcmPortInvalidCRCs fcmPortAddressErrors fcmPortDelimiterErrors fcmPortTruncatedFrames fcmPortEncodingDisparityErrors plus any errors in fcmPortOtherErrors that were input errors. McCloghrie Standards Track [Page 7] RFC 4044 Fibre Channel Management MIB May 2005 ifOutOctets The number of octets of information ifHCOutOctets contained in transmitted frames between the Start-of-Frame and End-of-Frame delimiters (excluding the delimiters). ifOutUcastPkts The number of frames transmitted, ifHCOutUcastPkts i.e., the number of start-of-frame delimiters transmitted for unicast frames. ifOutErrors This is the number of errors in fcmPortOtherErrors that were output errors. ifInMulticastPkts These counters are not incremented ifInBroadcastPkts (unless a proprietary mechanism for ifOutMulticastPkts multicast/broadcast is supported). ifOutBroadcastPkts ifHCInMulticastPkts ifHCInBroadcastPkts ifHCOutMulticastPkts ifHCOutBroadcastPkts ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is 'enabled' ifHighSpeed The current operational speed of the interface in millions of bits per second. For 1Gbs, this will be 1000; for 2Gbs, it will be 2000. If auto-negotiation is implemented and enabled on an interface, and the interface has not yet negotiated an operational speed, this object SHOULD reflect the maximum speed supported by the interface. ifPromiscuousMode This will normally be 'false' ifConnectorPresent This will normally be 'true'. 5.2. Entity MIB The Entity MIB [RFC2737] contains information about individual physical components and any hierarchical relationship that may exist between them. Any Fibre Channel management instance with a relationship to a physical component (or to a hierarchy of physical components) will have its value of the fcmInstancePhysicalIndex object contain a pointer to the relevant row in the Entity MIB. If McCloghrie Standards Track [Page 8] RFC 4044 Fibre Channel Management MIB May 2005 there is no correspondence with a physical component (or said component does not have a row in the Entity MIB), then the value of fcmInstancePhysicalIndex is zero. (Note that an implementation is not required to support a non-zero value of fcmInstancePhysicalIndex.) 5.3. Host Resources MIB The Host Resources MIB [RFC2790] includes information about installed software modules. Any Fibre Channel management instance with a correspondence to a software module, will have its value of the fcmInstanceSoftwareIndex object contain a pointer to the relevant row in the Host Resources MIB. If there is no correspondence to a software module (or said software module does not have a row in the Host Resources MIB), then the value of fcmInstanceSoftwareIndex is zero. (Note that an agent implementation is not required to support a non-zero value of fcmInstanceSoftwareIndex.) 6. Definitions FC-MGMT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Counter32, Counter64, transmission FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC ifIndex FROM IF-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; fcMgmtMIB MODULE-IDENTITY LAST-UPDATED "200504260000Z" -- 26 April 2005 ORGANIZATION "IETF IPS (IP-Storage) Working Group" CONTACT-INFO " Keith McCloghrie Cisco Systems, Inc. Tel: +1 408 526-5260 E-mail: kzm@cisco.com Postal: 170 West Tasman Drive San Jose, CA USA 95134 " DESCRIPTION "This module defines management information specific to Fibre Channel-attached devices. McCloghrie Standards Track [Page 9] RFC 4044 Fibre Channel Management MIB May 2005 Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4044; see the RFC itself for full legal notices." REVISION "200504260000Z" -- 26 April 2005 DESCRIPTION "Initial version of the Fibre Channel Mgmt MIB module." ::= { transmission 56 } fcmgmtObjects OBJECT IDENTIFIER ::= { fcMgmtMIB 1 } fcmgmtNotifications OBJECT IDENTIFIER ::= { fcMgmtMIB 2 } fcmgmtNotifPrefix OBJECT IDENTIFIER ::= { fcmgmtNotifications 0 } fcmgmtConformance OBJECT IDENTIFIER ::= { fcMgmtMIB 3 } --******************************** -- Textual Conventions -- FcNameIdOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The World Wide Name (WWN) associated with a Fibre Channel (FC) entity. WWNs were initially defined as 64-bits in length. The latest definition (for future use) is 128-bits long. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown." SYNTAX OCTET STRING (SIZE(0 | 8 | 16)) FcAddressIdOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown." SYNTAX OCTET STRING (SIZE(0 | 3)) FcDomainIdOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Domain Id (of an FC switch), or zero if the no Domain Id has been assigned." SYNTAX Integer32 (0..239) McCloghrie Standards Track [Page 10] RFC 4044 Fibre Channel Management MIB May 2005 FcPortType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of a Fibre Channel port, as indicated by the use of the appropriate value assigned by IANA." REFERENCE "The IANA-maintained registry for Fibre Channel port types (http://www.iana.org/)." SYNTAX Unsigned32 FcClasses ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of Fibre Channel classes of service." REFERENCE "Classes of service are described in FC-FS Section 13." SYNTAX BITS { classF(0), class1(1), class2(2), class3(3), class4(4), class5(5), class6(6) } FcBbCredit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The buffer-to-buffer credit of an FC port." SYNTAX Integer32 (0..32767) FcBbCreditModel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The buffer-to-buffer credit model of an Fx_Port." SYNTAX INTEGER { regular(1), alternate (2) } FcDataFieldSize ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Receive Data Field Size associated with an FC port." SYNTAX Integer32 (128..2112) McCloghrie Standards Track [Page 11] RFC 4044 Fibre Channel Management MIB May 2005 FcUnitFunctions ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of functions that a Fibre Channel Interconnect Element or Platform might perform. A value with no bits set indicates the function(s) are unknown. The individual bits have the following meanings: other - none of the following. hub - a device that interconnects L_Ports, but does not operate as an FL_Port. switch - a fabric element conforming to the Fibre Channel switch fabric set of standards (e.g., [FC-SW-3]). bridge - a device that encapsulates Fibre Channel frames within another protocol (e.g., [FC-BB], FC-BB-2). gateway - a device that converts an FC-4 to another protocol (e.g., FCP to iSCSI). host - a computer system that provides end users with services such as computation and storage access. storageSubsys - an integrated collection of storage controllers, storage devices, and necessary software that provides storage services to one or more hosts. storageAccessDev - a device that provides storage management and access for heterogeneous hosts and heterogeneous devices (e.g., medium changer). nas - a device that connects to a network and provides file access services. wdmux - a device that modulates/demodulates each of several data streams (e.g., Fibre Channel protocol data streams) onto/from a different part of the light spectrum in an optical fiber. storageDevice - a disk/tape/etc. device (without the controller and/or software required for it to be a 'storageSubsys')." SYNTAX BITS { other(0), -- none of the following hub(1), switch(2), McCloghrie Standards Track [Page 12] RFC 4044 Fibre Channel Management MIB May 2005 bridge(3), gateway(4), host(5), storageSubsys(6), storageAccessDev(7), nas(8), wdmux(9), storageDevice(10) } --******************************** -- MIB object definitions -- fcmInstanceTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the local Fibre Channel management instances." ::= { fcmgmtObjects 1 } fcmInstanceEntry OBJECT-TYPE SYNTAX FcmInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of attributes for a particular local Fibre Channel management instance." INDEX { fcmInstanceIndex } ::= { fcmInstanceTable 1 } FcmInstanceEntry ::= SEQUENCE { fcmInstanceIndex Unsigned32, fcmInstanceWwn FcNameIdOrZero, fcmInstanceFunctions FcUnitFunctions, fcmInstancePhysicalIndex Integer32, fcmInstanceSoftwareIndex Integer32, fcmInstanceStatus INTEGER, fcmInstanceTextName SnmpAdminString, fcmInstanceDescr SnmpAdminString, fcmInstanceFabricId FcNameIdOrZero } McCloghrie Standards Track [Page 13] RFC 4044 Fibre Channel Management MIB May 2005 fcmInstanceIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer value that uniquely identifies this instance amongst all local Fibre Channel management instances. It is mandatory to keep this value constant between restarts of the agent, and to make every possible effort to keep it constant across restarts (but note, it is unrealistic to expect it to remain constant across all re-configurations of the local system, e.g., across the replacement of all non- volatile storage)." ::= { fcmInstanceEntry 1 } fcmInstanceWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "If the instance has one (or more) WWN(s), then this object contains that (or one of those) WWN(s). If the instance does not have a WWN associated with it, then this object contains the zero-length string." ::= { fcmInstanceEntry 2 } fcmInstanceFunctions OBJECT-TYPE SYNTAX FcUnitFunctions MAX-ACCESS read-only STATUS current DESCRIPTION "One (or more) Fibre Channel unit functions being performed by this instance." ::= { fcmInstanceEntry 3 } fcmInstancePhysicalIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "If this management instance corresponds to a physical component (or to a hierarchy of physical components) identified by the Entity-MIB, then this object's value is the value of the entPhysicalIndex of that component (or of the component at the root of that hierarchy). If there is McCloghrie Standards Track [Page 14] RFC 4044 Fibre Channel Management MIB May 2005 no correspondence to a physical component (or no component that has an entPhysicalIndex value), then the value of this object is zero." REFERENCE "entPhysicalIndex is defined in the Entity MIB, RFC 2737." ::= { fcmInstanceEntry 4 } fcmInstanceSoftwareIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "If this management instance corresponds to an installed software module identified in the Host Resources MIB, then this object's value is the value of the hrSWInstalledIndex of that module. If there is no correspondence to an installed software module (or no module that has a hrSWInstalledIndex value), then the value of this object is zero." REFERENCE "hrSWInstalledIndex is defined in the Host Resources MIB, RFC 2790" ::= { fcmInstanceEntry 5 } fcmInstanceStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), ok(2), -- able to operate correctly warning(3), -- needs attention failed(4) -- something has failed } MAX-ACCESS read-only STATUS current DESCRIPTION "Overall status of the Fibre Channel entity/entities managed by this management instance. The value should reflect the most serious status of such entities." ::= { fcmInstanceEntry 6 } fcmInstanceTextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..79)) MAX-ACCESS read-write STATUS current DESCRIPTION "A textual name for this management instance and the Fibre Channel entity/entities that it is managing." ::= { fcmInstanceEntry 7 } McCloghrie Standards Track [Page 15] RFC 4044 Fibre Channel Management MIB May 2005 fcmInstanceDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "A textual description of this management instance and the Fibre Channel entity/entities that it is managing." ::= { fcmInstanceEntry 8 } fcmInstanceFabricId OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The globally unique Fabric Identifier that identifies the fabric to which the Fibre Channel entity/entities managed by this management instance are connected, or, of which they are a part. This is typically the Node WWN of the principal switch of a Fibre Channel fabric. The zero-length string indicates that the fabric identifier is unknown (or not applicable). In the event that the Fibre Channel entity/entities managed by this management instance is/are connected to multiple fabrics, then this object records the first (known) one." ::= { fcmInstanceEntry 9 } --******************************** -- The Fibre Channel Switch Table -- fcmSwitchTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmSwitchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches." ::= { fcmgmtObjects 2 } fcmSwitchEntry OBJECT-TYPE SYNTAX FcmSwitchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular Fibre Channel switch that is McCloghrie Standards Track [Page 16] RFC 4044 Fibre Channel Management MIB May 2005 managed by the management instance given by fcmInstanceIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex } ::= { fcmSwitchTable 1 } FcmSwitchEntry ::= SEQUENCE { fcmSwitchIndex Unsigned32, fcmSwitchDomainId FcDomainIdOrZero, fcmSwitchPrincipal TruthValue, fcmSwitchWWN FcNameIdOrZero } fcmSwitchIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies a Fibre Channel switch amongst those managed by one Fibre Channel management instance. It is mandatory to keep this value constant between restarts of the agent, and to make every possible effort to keep it constant across restarts." ::= { fcmSwitchEntry 1 } fcmSwitchDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "The Domain Id of this switch. A value of zero indicates that a switch has not (yet) been assigned a Domain Id." ::= { fcmSwitchEntry 2 } fcmSwitchPrincipal OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this switch is the principal switch within its fabric." ::= { fcmSwitchEntry 3 } McCloghrie Standards Track [Page 17] RFC 4044 Fibre Channel Management MIB May 2005 fcmSwitchWWN OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The World Wide Name of this switch." ::= { fcmSwitchEntry 4 } --******************************** -- The Fibre Channel Port Table -- fcmPortTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about Fibre Channel ports. Each Fibre Channel port is represented by one entry in the IF-MIB's ifTable." REFERENCE "RFC 2863, The Interfaces Group MIB, June 2000." ::= { fcmgmtObjects 3 } fcmPortEntry OBJECT-TYPE SYNTAX FcmPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a specific port." INDEX { ifIndex } ::= { fcmPortTable 1 } FcmPortEntry ::= SEQUENCE { fcmPortInstanceIndex Unsigned32, fcmPortWwn FcNameIdOrZero, fcmPortNodeWwn FcNameIdOrZero, fcmPortAdminType FcPortType, fcmPortOperType FcPortType, fcmPortFcCapClass FcClasses, fcmPortFcOperClass FcClasses, fcmPortTransmitterType INTEGER, fcmPortConnectorType INTEGER, fcmPortSerialNumber SnmpAdminString, fcmPortPhysicalNumber Unsigned32, fcmPortAdminSpeed INTEGER, fcmPortCapProtocols BITS, fcmPortOperProtocols BITS McCloghrie Standards Track [Page 18] RFC 4044 Fibre Channel Management MIB May 2005 } fcmPortInstanceIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of fcmInstanceIndex by which the Fibre Channel management instance, which manages this port, is identified in the fcmInstanceTable." ::= { fcmPortEntry 1 } fcmPortWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The World Wide Name of the port, or the zero-length string if the port does not have a WWN." ::= { fcmPortEntry 2 } fcmPortNodeWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The World Wide Name of the Node that contains this port, or the zero-length string if the port does not have a node WWN." ::= { fcmPortEntry 3 } fcmPortAdminType OBJECT-TYPE SYNTAX FcPortType MAX-ACCESS read-write STATUS current DESCRIPTION "The administratively desired type of this port." ::= { fcmPortEntry 4 } fcmPortOperType OBJECT-TYPE SYNTAX FcPortType MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational type of this port." ::= { fcmPortEntry 5 } McCloghrie Standards Track [Page 19] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortFcCapClass OBJECT-TYPE SYNTAX FcClasses MAX-ACCESS read-only STATUS current DESCRIPTION "The classes of service capability of this port." ::= { fcmPortEntry 6 } fcmPortFcOperClass OBJECT-TYPE SYNTAX FcClasses MAX-ACCESS read-only STATUS current DESCRIPTION "The classes of service that are currently operational on this port. For an FL_Port, this is the union of the classes being supported across all attached NL_Ports." ::= { fcmPortEntry 7 } fcmPortTransmitterType OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), shortwave850nm(3), longwave1550nm(4), longwave1310nm(5), electrical(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The technology of the port transceiver." REFERENCE "FC-GS-3, section 6.1.2.2.3" ::= { fcmPortEntry 8 } fcmPortConnectorType OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), gbic(3), embedded(4), glm(5), gbicSerialId(6), gbicNoSerialId(7), sfpSerialId(8), sfpNoSerialId(9) } MAX-ACCESS read-only McCloghrie Standards Track [Page 20] RFC 4044 Fibre Channel Management MIB May 2005 STATUS current DESCRIPTION "The module type of the port connector. This object refers to the hardware implementation of the port. It will be 'embedded' if the hardware equivalent to Gigabit interface card (GBIC) is part of the line card and is unremovable. It will be 'glm' if it's a gigabit link module (GLM). It will be 'gbicSerialId' if the GBIC serial id can be read, else it will be 'gbicNoSerialId'. It will be 'sfpSerialId' if the small form factor (SFP) pluggable GBICs serial id can be read, else it will be 'sfpNoSerialId'." REFERENCE "FC-GS-3, section 6.1.2.2.4" ::= { fcmPortEntry 9 } fcmPortSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The serial number associated with the port (e.g., for a GBIC). If not applicable, the object's value is a zero- length string." REFERENCE "FC-GS-3, section 6.1.2.2.4" ::= { fcmPortEntry 10 } fcmPortPhysicalNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is the port's 'Physical Port Number' as defined by GS-3." REFERENCE "FC-GS-3, section 6.1.2.2.5" ::= { fcmPortEntry 11 } fcmPortAdminSpeed OBJECT-TYPE SYNTAX INTEGER { auto(1), eighthGbs(2), -- 125Mbs quarterGbs(3), -- 250Mbs halfGbs(4), -- 500Mbs oneGbs(5), -- 1Gbs twoGbs(6), -- 2Gbs fourGbs(7), -- 4Gbs tenGbs(8) -- 10Gbs McCloghrie Standards Track [Page 21] RFC 4044 Fibre Channel Management MIB May 2005 } MAX-ACCESS read-write STATUS current DESCRIPTION "The speed of the interface: 'auto' - auto-negotiation 'tenGbs' - 10Gbs 'fourGbs' - 4Gbs 'twoGbs' - 2Gbs 'oneGbs' - 1Gbs 'halfGbs' - 500Mbs 'quarterGbs' - 250Mbs 'eighthGbs' - 125Mbs" ::= { fcmPortEntry 12 } fcmPortCapProtocols OBJECT-TYPE SYNTAX BITS { unknown(0), loop(1), fabric(2), scsi(3), tcpIp(4), vi(5), ficon(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "A bit mask specifying the higher level protocols that are capable of running over this port. Note that for generic Fx_Ports, E_Ports, and B_Ports, this object will indicate all protocols." ::= { fcmPortEntry 13 } fcmPortOperProtocols OBJECT-TYPE SYNTAX BITS { unknown(0), loop(1), fabric(2), scsi(3), tcpIp(4), vi(5), ficon(6) } MAX-ACCESS read-only STATUS current DESCRIPTION McCloghrie Standards Track [Page 22] RFC 4044 Fibre Channel Management MIB May 2005 "A bit mask specifying the higher level protocols that are currently operational on this port. For Fx_Ports, E_Ports, and B_Ports, this object will typically have the value 'unknown'." ::= { fcmPortEntry 14 } --******************************** -- Port Statistics -- fcmPortStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmPortStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of statistics for Fibre Channel ports." ::= { fcmgmtObjects 4 } fcmPortStatsEntry OBJECT-TYPE SYNTAX FcmPortStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing statistics for a Fibre Channel port. If any counter in this table suffers a discontinuity, the value of ifCounterDiscontinuityTime (defined in the IF-MIB) must be updated." REFERENCE "The Interfaces Group MIB, RFC 2863, June 2000." AUGMENTS { fcmPortEntry } ::= { fcmPortStatsTable 1 } FcmPortStatsEntry ::= SEQUENCE { fcmPortBBCreditZeros Counter64, fcmPortFullInputBuffers Counter64, fcmPortClass2RxFrames Counter64, fcmPortClass2RxOctets Counter64, fcmPortClass2TxFrames Counter64, fcmPortClass2TxOctets Counter64, fcmPortClass2Discards Counter64, fcmPortClass2RxFbsyFrames Counter64, fcmPortClass2RxPbsyFrames Counter64, fcmPortClass2RxFrjtFrames Counter64, fcmPortClass2RxPrjtFrames Counter64, fcmPortClass2TxFbsyFrames Counter64, fcmPortClass2TxPbsyFrames Counter64, fcmPortClass2TxFrjtFrames Counter64, fcmPortClass2TxPrjtFrames Counter64, McCloghrie Standards Track [Page 23] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortClass3RxFrames Counter64, fcmPortClass3RxOctets Counter64, fcmPortClass3TxFrames Counter64, fcmPortClass3TxOctets Counter64, fcmPortClass3Discards Counter64, fcmPortClassFRxFrames Counter32, fcmPortClassFRxOctets Counter32, fcmPortClassFTxFrames Counter32, fcmPortClassFTxOctets Counter32, fcmPortClassFDiscards Counter32 } fcmPortBBCreditZeros OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transitions in/out of the buffer-to-buffer credit zero state. The other side is not providing any credit." ::= { fcmPortStatsEntry 1 } fcmPortFullInputBuffers OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of occurrences when all input buffers of a port were full and outbound buffer-to-buffer credit transitioned to zero, i.e., there became no credit to provide to other side." ::= { fcmPortStatsEntry 2 } fcmPortClass2RxFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames received at this port." ::= { fcmPortStatsEntry 3 } fcmPortClass2RxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 2 frames received at this port." McCloghrie Standards Track [Page 24] RFC 4044 Fibre Channel Management MIB May 2005 ::= { fcmPortStatsEntry 4 } fcmPortClass2TxFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames transmitted out of this port." ::= { fcmPortStatsEntry 5 } fcmPortClass2TxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 2 frames transmitted out of this port." ::= { fcmPortStatsEntry 6 } fcmPortClass2Discards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames that were discarded upon reception at this port." ::= { fcmPortStatsEntry 7 } fcmPortClass2RxFbsyFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_BSY was returned to this port as a result of a Class 2 frame that could not be delivered to the other end of the link. This can occur when either the fabric or the destination port is temporarily busy. Note that this counter will never increment for an F_Port." ::= { fcmPortStatsEntry 8 } fcmPortClass2RxPbsyFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_BSY was returned to this port as a result of a Class 2 frame that could not be delivered to the other end of the link. This can occur when the McCloghrie Standards Track [Page 25] RFC 4044 Fibre Channel Management MIB May 2005 destination port is temporarily busy." ::= { fcmPortStatsEntry 9 } fcmPortClass2RxFrjtFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_RJT was returned to this port as a result of a Class 2 frame that was rejected by the fabric. Note that this counter will never increment for an F_Port." ::= { fcmPortStatsEntry 10 } fcmPortClass2RxPrjtFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_RJT was returned to this port as a result of a Class 2 frame that was rejected at the destination N_Port." ::= { fcmPortStatsEntry 11 } fcmPortClass2TxFbsyFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_BSY was generated by this port as a result of a Class 2 frame that could not be delivered because either the Fabric or the destination port was temporarily busy. Note that this counter will never increment for an N_Port." ::= { fcmPortStatsEntry 12 } fcmPortClass2TxPbsyFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_BSY was generated by this port as a result of a Class 2 frame that could not be delivered because the destination port was temporarily busy. Note that this counter will never increment for an F_Port." ::= { fcmPortStatsEntry 13 } McCloghrie Standards Track [Page 26] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortClass2TxFrjtFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_RJT was generated by this port as a result of a Class 2 frame being rejected by the fabric. Note that this counter will never increment for an N_Port." ::= { fcmPortStatsEntry 14 } fcmPortClass2TxPrjtFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_RJT was generated by this port as a result of a Class 2 frame being rejected at the destination N_Port. Note that this counter will never increment for an F_Port." ::= { fcmPortStatsEntry 15 } fcmPortClass3RxFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames received at this port." ::= { fcmPortStatsEntry 16 } fcmPortClass3RxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 3 frames received at this port." ::= { fcmPortStatsEntry 17 } fcmPortClass3TxFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames transmitted out of this port." ::= { fcmPortStatsEntry 18 } McCloghrie Standards Track [Page 27] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortClass3TxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 3 frames transmitted out of this port." ::= { fcmPortStatsEntry 19 } fcmPortClass3Discards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames that were discarded upon reception at this port." ::= { fcmPortStatsEntry 20 } fcmPortClassFRxFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class F frames received at this port." ::= { fcmPortStatsEntry 21 } fcmPortClassFRxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class F frames received at this port." ::= { fcmPortStatsEntry 22 } fcmPortClassFTxFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class F frames transmitted out of this port." ::= { fcmPortStatsEntry 23 } McCloghrie Standards Track [Page 28] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortClassFTxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class F frames transmitted out of this port." ::= { fcmPortStatsEntry 24 } fcmPortClassFDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class F frames that were discarded upon reception at this port." ::= { fcmPortStatsEntry 25 } --******************************** -- Port Low-capacity Statistics -- -- these are Counter32 "low-capacity" counters for systems -- that do not support Counter64's fcmPortLcStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmPortLcStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Counter32-based statistics for systems that do not support Counter64." ::= { fcmgmtObjects 5 } fcmPortLcStatsEntry OBJECT-TYPE SYNTAX FcmPortLcStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing low-capacity (i.e., based on Counter32) statistics for a Fibre Channel port. If any counter in this table suffers a discontinuity, the value of ifCounterDiscontinuityTime (defined in the IF-MIB) must be updated." REFERENCE "The Interfaces Group MIB, RFC 2863, June 2000." AUGMENTS { fcmPortEntry } ::= { fcmPortLcStatsTable 1 } McCloghrie Standards Track [Page 29] RFC 4044 Fibre Channel Management MIB May 2005 FcmPortLcStatsEntry ::= SEQUENCE { fcmPortLcBBCreditZeros Counter32, fcmPortLcFullInputBuffers Counter32, fcmPortLcClass2RxFrames Counter32, fcmPortLcClass2RxOctets Counter32, fcmPortLcClass2TxFrames Counter32, fcmPortLcClass2TxOctets Counter32, fcmPortLcClass2Discards Counter32, fcmPortLcClass2RxFbsyFrames Counter32, fcmPortLcClass2RxPbsyFrames Counter32, fcmPortLcClass2RxFrjtFrames Counter32, fcmPortLcClass2RxPrjtFrames Counter32, fcmPortLcClass2TxFbsyFrames Counter32, fcmPortLcClass2TxPbsyFrames Counter32, fcmPortLcClass2TxFrjtFrames Counter32, fcmPortLcClass2TxPrjtFrames Counter32, fcmPortLcClass3RxFrames Counter32, fcmPortLcClass3RxOctets Counter32, fcmPortLcClass3TxFrames Counter32, fcmPortLcClass3TxOctets Counter32, fcmPortLcClass3Discards Counter32 } fcmPortLcBBCreditZeros OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transitions in/out of the buffer-to-buffer credit zero state. The other side is not providing any credit." ::= { fcmPortLcStatsEntry 1 } fcmPortLcFullInputBuffers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of occurrences when all input buffers of a port were full and outbound buffer-to-buffer credit transitioned to zero, i.e., there became no credit to provide to other side." ::= { fcmPortLcStatsEntry 2 } McCloghrie Standards Track [Page 30] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortLcClass2RxFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames received at this port." ::= { fcmPortLcStatsEntry 3 } fcmPortLcClass2RxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 2 frames received at this port." ::= { fcmPortLcStatsEntry 4 } fcmPortLcClass2TxFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames transmitted out of this port." ::= { fcmPortLcStatsEntry 5 } fcmPortLcClass2TxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 2 frames transmitted out of this port." ::= { fcmPortLcStatsEntry 6 } fcmPortLcClass2Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 2 frames that were discarded upon reception at this port." ::= { fcmPortLcStatsEntry 7 } McCloghrie Standards Track [Page 31] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortLcClass2RxFbsyFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_BSY was returned to this port as a result of a Class 2 frame that could not be delivered to the other end of the link. This can occur when either the fabric or the destination port is temporarily busy. Note that this counter will never increment for an F_Port." ::= { fcmPortLcStatsEntry 8 } fcmPortLcClass2RxPbsyFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_BSY was returned to this port as a result of a Class 2 frame that could not be delivered to the other end of the link. This can occur when the destination port is temporarily busy." ::= { fcmPortLcStatsEntry 9 } fcmPortLcClass2RxFrjtFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_RJT was returned to this port as a result of a Class 2 frame that was rejected by the fabric. Note that this counter will never increment for an F_Port." ::= { fcmPortLcStatsEntry 10 } fcmPortLcClass2RxPrjtFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_RJT was returned to this port as a result of a Class 2 frame that was rejected at the destination N_Port." ::= { fcmPortLcStatsEntry 11 } McCloghrie Standards Track [Page 32] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortLcClass2TxFbsyFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_BSY was generated by this port as a result of a Class 2 frame that could not be delivered because either the Fabric or the destination port was temporarily busy. Note that this counter will never increment for an N_Port." ::= { fcmPortLcStatsEntry 12 } fcmPortLcClass2TxPbsyFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_BSY was generated by this port as a result of a Class 2 frame that could not be delivered because the destination port was temporarily busy. Note that this counter will never increment for an F_Port." ::= { fcmPortLcStatsEntry 13 } fcmPortLcClass2TxFrjtFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that F_RJT was generated by this port as a result of a Class 2 frame being rejected by the fabric. Note that this counter will never increment for an N_Port." ::= { fcmPortLcStatsEntry 14 } fcmPortLcClass2TxPrjtFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that P_RJT was generated by this port as a result of a Class 2 frame being rejected at the destination N_Port. Note that this counter will never increment for an F_Port." ::= { fcmPortLcStatsEntry 15 } McCloghrie Standards Track [Page 33] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortLcClass3RxFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames received at this port." ::= { fcmPortLcStatsEntry 16 } fcmPortLcClass3RxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 3 frames received at this port." ::= { fcmPortLcStatsEntry 17 } fcmPortLcClass3TxFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames transmitted out of this port." ::= { fcmPortLcStatsEntry 18 } fcmPortLcClass3TxOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in Class 3 frames transmitted out of this port." ::= { fcmPortLcStatsEntry 19 } fcmPortLcClass3Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Class 3 frames that were discarded upon reception at this port." ::= { fcmPortLcStatsEntry 20 } McCloghrie Standards Track [Page 34] RFC 4044 Fibre Channel Management MIB May 2005 --******************************** -- Port Error Counters -- fcmPortErrorsTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmPortErrorsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Error counters for Fibre Channel ports." ::= { fcmgmtObjects 6 } fcmPortErrorsEntry OBJECT-TYPE SYNTAX FcmPortErrorsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Error counters for a Fibre Channel port. If any counter in this table suffers a discontinuity, the value of ifCounterDiscontinuityTime (defined in the IF-MIB) must be updated." REFERENCE "The Interfaces Group MIB, RFC 2863, June 2000." AUGMENTS { fcmPortEntry } ::= { fcmPortErrorsTable 1 } FcmPortErrorsEntry ::= SEQUENCE { fcmPortRxLinkResets Counter32, fcmPortTxLinkResets Counter32, fcmPortLinkResets Counter32, fcmPortRxOfflineSequences Counter32, fcmPortTxOfflineSequences Counter32, fcmPortLinkFailures Counter32, fcmPortLossofSynchs Counter32, fcmPortLossofSignals Counter32, fcmPortPrimSeqProtocolErrors Counter32, fcmPortInvalidTxWords Counter32, fcmPortInvalidCRCs Counter32, fcmPortInvalidOrderedSets Counter32, fcmPortFrameTooLongs Counter32, fcmPortTruncatedFrames Counter32, fcmPortAddressErrors Counter32, fcmPortDelimiterErrors Counter32, fcmPortEncodingDisparityErrors Counter32, fcmPortOtherErrors Counter32 } McCloghrie Standards Track [Page 35] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortRxLinkResets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Link Reset (LR) Primitive Sequences received." ::= { fcmPortErrorsEntry 1 } fcmPortTxLinkResets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Link Reset (LR) Primitive Sequences transmitted." ::= { fcmPortErrorsEntry 2 } fcmPortLinkResets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the reset link protocol was initiated on this port. This includes the number of Loop Initialization Primitive (LIP) events on an arbitrated loop port." ::= { fcmPortErrorsEntry 3 } fcmPortRxOfflineSequences OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Offline (OLS) Primitive Sequences received at this port." ::= { fcmPortErrorsEntry 4 } fcmPortTxOfflineSequences OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Offline (OLS) Primitive Sequences transmitted by this port." ::= { fcmPortErrorsEntry 5 } McCloghrie Standards Track [Page 36] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortLinkFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of link failures. This count is part of FC-PH's Link Error Status Block (LESB)." REFERENCE "FC-PH, rev 4.3, 1 June 1994, section 29.8 [FC-PH]." ::= { fcmPortErrorsEntry 6 } fcmPortLossofSynchs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of instances of synchronization loss detected at this port. This count is part of FC-PH's Link Error Status Block (LESB)." REFERENCE "FC-PH, rev 4.3, 1 June 1994, section 29.8." ::= { fcmPortErrorsEntry 7 } fcmPortLossofSignals OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of instances of signal loss detected at this port. This count is part of FC-PH's Link Error Status Block (LESB)." REFERENCE "FC-PH, rev 4.3, 1 June 1994, section 29.8." ::= { fcmPortErrorsEntry 8 } fcmPortPrimSeqProtocolErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of primitive sequence protocol errors detected at this port. This count is part of FC-PH's Link Error Status Block (LESB)." REFERENCE "FC-PH, rev 4.3, 1 June 1994, section 29.8." ::= { fcmPortErrorsEntry 9 } McCloghrie Standards Track [Page 37] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortInvalidTxWords OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid transmission words received at this port. This count is part of FC-PH's Link Error Status Block (LESB)." REFERENCE "FC-PH, rev 4.3, 1 June 1994, section 29.8." ::= { fcmPortErrorsEntry 10 } fcmPortInvalidCRCs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received with an invalid CRC. This count is part of FC-PH's Link Error Status Block (LESB)." REFERENCE "FC-PH, rev 4.3, 1 June 1994, section 29.8." ::= { fcmPortErrorsEntry 11 } fcmPortInvalidOrderedSets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid ordered sets received at this port." ::= { fcmPortErrorsEntry 12 } fcmPortFrameTooLongs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received at this port for which the frame length was greater than what was agreed to in FLOGI/PLOGI. This could be caused by losing the end of frame delimiter." ::= { fcmPortErrorsEntry 13 } fcmPortTruncatedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received at this port for which the McCloghrie Standards Track [Page 38] RFC 4044 Fibre Channel Management MIB May 2005 frame length was less than the minimum indicated by the frame header - normally 24 bytes, but it could be more if the DFCTL field indicates an optional header should have been present." ::= { fcmPortErrorsEntry 14 } fcmPortAddressErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received with unknown addressing; for example, an unknown SID or DID." ::= { fcmPortErrorsEntry 15 } fcmPortDelimiterErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid frame delimiters received at this port. An example is a frame with a class 2 start and a class 3 at the end." ::= { fcmPortErrorsEntry 16 } fcmPortEncodingDisparityErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of encoding disparity errors received at this port." ::= { fcmPortErrorsEntry 17 } fcmPortOtherErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of errors that were detected on this port but not counted by any other error counter in this row." ::= { fcmPortErrorsEntry 18 } McCloghrie Standards Track [Page 39] RFC 4044 Fibre Channel Management MIB May 2005 --******************************** -- The Fibre Channel Fx_Port Table -- fcmFxPortTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmFxPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Additional information about Fibre Channel ports that is specific to Fx_Ports. This table will contain one entry for each fcmPortTable entry that represents an Fx_Port." ::= { fcmgmtObjects 7 } fcmFxPortEntry OBJECT-TYPE SYNTAX FcmFxPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a specific Fx_Port." INDEX { ifIndex } ::= { fcmFxPortTable 1 } FcmFxPortEntry ::= SEQUENCE { fcmFxPortRatov Unsigned32, fcmFxPortEdtov Unsigned32, fcmFxPortRttov Unsigned32, fcmFxPortHoldTime Unsigned32, fcmFxPortCapBbCreditMax FcBbCredit, fcmFxPortCapBbCreditMin FcBbCredit, fcmFxPortCapDataFieldSizeMax FcDataFieldSize, fcmFxPortCapDataFieldSizeMin FcDataFieldSize, fcmFxPortCapClass2SeqDeliv TruthValue, fcmFxPortCapClass3SeqDeliv TruthValue, fcmFxPortCapHoldTimeMax Unsigned32, fcmFxPortCapHoldTimeMin Unsigned32 } fcmFxPortRatov OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The Resource_Allocation_Timeout Value configured for this Fx_Port. This is used as the timeout value for determining when to reuse an Nx_Port resource such as a McCloghrie Standards Track [Page 40] RFC 4044 Fibre Channel Management MIB May 2005 Recovery_Qualifier. It represents the Error_Detect_Timeout value (see fcmFxPortEdtov) plus twice the maximum time that a frame may be delayed within the Fabric and still be delivered." ::= { fcmFxPortEntry 1 } fcmFxPortEdtov OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The Error_Detect_Timeout value configured for this Fx_Port. This is used as the timeout value for detecting an error condition." ::= { fcmFxPortEntry 2 } fcmFxPortRttov OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The Receiver_Transmitter_Timeout value of this Fx_Port. This is used by the receiver logic to detect a Loss of Synchronization." ::= { fcmFxPortEntry 3 } fcmFxPortHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum time that this Fx_Port shall hold a frame before discarding the frame if it is unable to deliver the frame. The value 0 means that this Fx_Port does not support this parameter." ::= { fcmFxPortEntry 4 } fcmFxPortCapBbCreditMax OBJECT-TYPE SYNTAX FcBbCredit UNITS "buffers" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of receive buffers that this port is capable of making available for holding frames from attached McCloghrie Standards Track [Page 41] RFC 4044 Fibre Channel Management MIB May 2005 Nx_Port(s)." ::= { fcmFxPortEntry 5 } fcmFxPortCapBbCreditMin OBJECT-TYPE SYNTAX FcBbCredit UNITS "buffers" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum number of receive buffers that this port is capable of making available for holding frames from attached Nx_Port(s)." ::= { fcmFxPortEntry 6 } fcmFxPortCapDataFieldSizeMax OBJECT-TYPE SYNTAX FcDataFieldSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum size in bytes of the Data Field in a frame that this Fx_Port is capable of receiving from an attached Nx_Port." ::= { fcmFxPortEntry 7 } fcmFxPortCapDataFieldSizeMin OBJECT-TYPE SYNTAX FcDataFieldSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum size in bytes of the Data Field in a frame that this Fx_Port is capable of receiving from an attached Nx_Port." ::= { fcmFxPortEntry 8 } fcmFxPortCapClass2SeqDeliv OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this Fx_Port is capable of supporting Class 2 Sequential Delivery." ::= { fcmFxPortEntry 9 } McCloghrie Standards Track [Page 42] RFC 4044 Fibre Channel Management MIB May 2005 fcmFxPortCapClass3SeqDeliv OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this Fx_Port is capable of supporting Class 3 Sequential Delivery." ::= { fcmFxPortEntry 10 } fcmFxPortCapHoldTimeMax OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum holding time that this Fx_Port is capable of supporting." ::= { fcmFxPortEntry 11 } fcmFxPortCapHoldTimeMin OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum holding time that this Fx_Port is capable of supporting." ::= { fcmFxPortEntry 12 } --******************************** -- The Fibre Channel Inter-Switch Port Table -- fcmISPortTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmISPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Additional information about E_Ports, B_Ports, and any other type of Fibre Channel port to which inter-switch links can be connected. This table will contain one entry for each fcmPortTable entry that represents such a port." ::= { fcmgmtObjects 8 } McCloghrie Standards Track [Page 43] RFC 4044 Fibre Channel Management MIB May 2005 fcmISPortEntry OBJECT-TYPE SYNTAX FcmISPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a specific port connected to an inter-switch link." INDEX { ifIndex } ::= { fcmISPortTable 1 } FcmISPortEntry ::= SEQUENCE { fcmISPortClassFCredit FcBbCredit, fcmISPortClassFDataFieldSize FcDataFieldSize } fcmISPortClassFCredit OBJECT-TYPE SYNTAX FcBbCredit MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of Class F data frames that can be transmitted by the inter-switch port without receipt of ACK or Link_Response frames." ::= { fcmISPortEntry 1 } fcmISPortClassFDataFieldSize OBJECT-TYPE SYNTAX FcDataFieldSize UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The Receive Data Field Size that the inter-switch port has agreed to support for Class F frames to/from this port. The size specifies the largest Data Field Size for an FT_1 frame." ::= { fcmISPortEntry 2 } McCloghrie Standards Track [Page 44] RFC 4044 Fibre Channel Management MIB May 2005 --******************************** -- The Fabric Login table -- -- This table contains the information held by FC switches -- about the Nx_Ports that are logged-in/attached to their -- Fx_Ports fcmFLoginTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmFLoginEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains one entry for each Nx_Port logged- in/attached to a particular Fx_Port in the switch. Each entry contains the services parameters established during the most recent Fabric Login, explicit or implicit. Note that an Fx_Port may have one or more Nx_Ports attached to it." ::= { fcmgmtObjects 9 } fcmFLoginEntry OBJECT-TYPE SYNTAX FcmFLoginEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing service parameters established from a successful Fabric Login." INDEX { ifIndex, fcmFLoginNxPortIndex } ::= { fcmFLoginTable 1 } FcmFLoginEntry ::= SEQUENCE { fcmFLoginNxPortIndex Unsigned32, fcmFLoginPortWwn FcNameIdOrZero, fcmFLoginNodeWwn FcNameIdOrZero, fcmFLoginBbCreditModel FcBbCreditModel, fcmFLoginBbCredit FcBbCredit, fcmFLoginClassesAgreed FcClasses, fcmFLoginClass2SeqDelivAgreed TruthValue, fcmFLoginClass2DataFieldSize FcDataFieldSize, fcmFLoginClass3SeqDelivAgreed TruthValue, fcmFLoginClass3DataFieldSize FcDataFieldSize } McCloghrie Standards Track [Page 45] RFC 4044 Fibre Channel Management MIB May 2005 fcmFLoginNxPortIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an Nx_Port amongst all those attached to the Fx_Port indicated by ifIndex. After a value of this object is assigned to a particular Nx_Port, that value can be re-used when and only when it is assigned to the same Nx_Port, or, after a reset of the value of the relevant instance of ifCounterDiscontinuityTime." REFERENCE "The Interfaces Group MIB, RFC 2863, June 2000." ::= { fcmFLoginEntry 1 } fcmFLoginPortWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The port name of the attached Nx_Port, or the zero-length string if unknown." ::= { fcmFLoginEntry 2 } fcmFLoginNodeWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The node name of the attached Nx_Port, or the zero-length string if unknown." ::= { fcmFLoginEntry 3 } fcmFLoginBbCreditModel OBJECT-TYPE SYNTAX FcBbCreditModel MAX-ACCESS read-only STATUS current DESCRIPTION "The buffer-to-buffer credit model in use by the Fx_Port." ::= { fcmFLoginEntry 4 } fcmFLoginBbCredit OBJECT-TYPE SYNTAX FcBbCredit MAX-ACCESS read-only STATUS current DESCRIPTION "The number of buffers available for holding frames to be McCloghrie Standards Track [Page 46] RFC 4044 Fibre Channel Management MIB May 2005 transmitted to the attached Nx_Port. These buffers are for buffer-to-buffer flow control in the direction from Fx_Port to Nx_Port." ::= { fcmFLoginEntry 5 } fcmFLoginClassesAgreed OBJECT-TYPE SYNTAX FcClasses MAX-ACCESS read-only STATUS current DESCRIPTION "The Classes of Service that the Fx_Port has agreed to support for this Nx_Port." ::= { fcmFLoginEntry 6 } fcmFLoginClass2SeqDelivAgreed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the Fx_Port has agreed to support Class 2 sequential delivery for this Nx_Port. This is only meaningful if Class 2 service has been agreed upon." ::= { fcmFLoginEntry 7 } fcmFLoginClass2DataFieldSize OBJECT-TYPE SYNTAX FcDataFieldSize MAX-ACCESS read-only STATUS current DESCRIPTION "The Receive Data Field Size that the Fx_Port has agreed to support for Class 2 frames to/from this Nx_Port. The size specifies the largest Data Field Size for an FT_1 frame. This is only meaningful if Class 2 service has been agreed upon." ::= { fcmFLoginEntry 8 } fcmFLoginClass3SeqDelivAgreed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the Fx_Port has agreed to support Class 3 sequential delivery for this Nx_Port. This is only meaningful if Class 3 service has been agreed upon." ::= { fcmFLoginEntry 9 } McCloghrie Standards Track [Page 47] RFC 4044 Fibre Channel Management MIB May 2005 fcmFLoginClass3DataFieldSize OBJECT-TYPE SYNTAX FcDataFieldSize MAX-ACCESS read-only STATUS current DESCRIPTION "The Receive Data Field Size that the Fx_Port has agreed to support for Class 3 frames to/from this Nx_Port. The size specifies the largest Data Field Size for an FT_1 frame. This is only meaningful if Class 3 service has been agreed upon." ::= { fcmFLoginEntry 10 } --******************************** -- The Link table -- -- This table is intended to assist management applications -- in determining the topology of the network. The table -- contains any recent information the known to the agent -- about Fibre Channel links, not only those that terminate at -- a local port but also any others for which information -- is known. fcmLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF FcmLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing any Fibre Channel link information that is known to local Fibre Channel managed instances. One end of such a link is typically at a local port, but the table can also contain information on links for which neither end is a local port. If one end of a link terminates locally, then that end is termed 'end1'; the other end is termed 'end2'." ::= { fcmgmtObjects 10 } fcmLinkEntry OBJECT-TYPE SYNTAX FcmLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information that a particular Fibre Channel managed instance has about a Fibre Channel link. The two ends of the link are called 'end1' and 'end2'." INDEX { fcmInstanceIndex, fcmLinkIndex } ::= { fcmLinkTable 1 } McCloghrie Standards Track [Page 48] RFC 4044 Fibre Channel Management MIB May 2005 FcmLinkEntry ::= SEQUENCE { fcmLinkIndex Unsigned32, fcmLinkEnd1NodeWwn FcNameIdOrZero, fcmLinkEnd1PhysPortNumber Unsigned32, fcmLinkEnd1PortWwn FcNameIdOrZero, fcmLinkEnd2NodeWwn FcNameIdOrZero, fcmLinkEnd2PhysPortNumber Unsigned32, fcmLinkEnd2PortWwn FcNameIdOrZero, fcmLinkEnd2AgentAddress SnmpAdminString, fcmLinkEnd2PortType FcPortType, fcmLinkEnd2UnitType FcUnitFunctions, fcmLinkEnd2FcAddressId FcAddressIdOrZero } fcmLinkIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies one link within the set of links about which a particular managed instance has information." ::= { fcmLinkEntry 1 } fcmLinkEnd1NodeWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The node name of end1, or the zero-length string if unknown." ::= { fcmLinkEntry 2 } fcmLinkEnd1PhysPortNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The physical port number of end1, or zero if unknown." REFERENCE "FC-GS-3, section 6.1.2.2.5" ::= { fcmLinkEntry 3 } McCloghrie Standards Track [Page 49] RFC 4044 Fibre Channel Management MIB May 2005 fcmLinkEnd1PortWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The port WWN of end1, or the zero-length string if unknown. ('end1' is local if this value is equal to the value of fcmPortWwn in one of the rows of the fcmPortTable.)" ::= { fcmLinkEntry 4 } fcmLinkEnd2NodeWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The node name of end2, or the zero-length string if unknown." ::= { fcmLinkEntry 5 } fcmLinkEnd2PhysPortNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The physical port number of end2, or zero if unknown." REFERENCE "FC-GS-3, section 6.1.2.2.5" ::= { fcmLinkEntry 6 } fcmLinkEnd2PortWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The port WWN of end2, or the zero-length string if unknown." ::= { fcmLinkEntry 7 } fcmLinkEnd2AgentAddress OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the management agent for the Fibre Channel Interconnect Element or Platform of which end2 is a part. The GS-4 specification provides some information about management agents. If the address is unknown, the value of this object is the zero-length string." McCloghrie Standards Track [Page 50] RFC 4044 Fibre Channel Management MIB May 2005 REFERENCE "FC-GS-3, section 6.1.2.1.7" ::= { fcmLinkEntry 8 } fcmLinkEnd2PortType OBJECT-TYPE SYNTAX FcPortType MAX-ACCESS read-only STATUS current DESCRIPTION "The port type of end2." REFERENCE "FC-GS-3, section 6.1.2.2.2" ::= { fcmLinkEntry 9 } fcmLinkEnd2UnitType OBJECT-TYPE SYNTAX FcUnitFunctions MAX-ACCESS read-only STATUS current DESCRIPTION "The type of/function(s) performed by the Fibre Channel Interconnect Element or Platform of which end2 is a part." REFERENCE "FC-GS-3, sections 6.1.2.1.2 and 6.1.2.3.2" ::= { fcmLinkEntry 10 } fcmLinkEnd2FcAddressId OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Fibre Channel Address ID of end2, or the zero-length string if unknown." ::= { fcmLinkEntry 11 } McCloghrie Standards Track [Page 51] RFC 4044 Fibre Channel Management MIB May 2005 --******************************** -- Conformance Section -- fcmgmtCompliances OBJECT IDENTIFIER ::= { fcmgmtConformance 1 } fcmgmtGroups OBJECT IDENTIFIER ::= { fcmgmtConformance 2 } fcmgmtCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for compliance to this Fibre Channel Management MIB." MODULE -- this module MANDATORY-GROUPS { fcmInstanceBasicGroup, fcmPortBasicGroup, fcmPortErrorsGroup } GROUP fcmPortStatsGroup DESCRIPTION "This group is mandatory for all systems that are able to support the Counter64 date type." GROUP fcmPortClass23StatsGroup DESCRIPTION "This group is mandatory only for systems that keep class-specific traffic statistics on Class 2 and Class 3 traffic and are able to support the Counter64 date type." GROUP fcmPortClassFStatsGroup DESCRIPTION "This group is mandatory only for FC switches that keep statistics on Class F traffic." GROUP fcmPortLcStatsGroup DESCRIPTION "This group is mandatory only for agents that can not support the Counter64 data type and/or need to provide information accessible by SNMPv1 applications." GROUP fcmSwitchBasicGroup DESCRIPTION "This group is mandatory only for Fibre Channel managed instances that manage Fibre Channel switches." GROUP fcmSwitchPortGroup DESCRIPTION McCloghrie Standards Track [Page 52] RFC 4044 Fibre Channel Management MIB May 2005 "This group is mandatory only for Fibre Channel managed instances that manage Fibre Channel switches." GROUP fcmSwitchLoginGroup DESCRIPTION "This group is mandatory only for Fibre Channel managed instances that manage Fibre Channel switches." GROUP fcmLinkBasicGroup DESCRIPTION "This group is optional." OBJECT fcmInstancePhysicalIndex SYNTAX Integer32 (0) DESCRIPTION "Implementation of a non-zero value is not required." OBJECT fcmInstanceSoftwareIndex SYNTAX Integer32 (0) DESCRIPTION "Implementation of a non-zero value is not required." OBJECT fcmInstanceTextName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcmInstanceDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcmPortAdminType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcmPortAdminSpeed MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT fcmSwitchDomainId MIN-ACCESS read-only DESCRIPTION "Write access is not required." McCloghrie Standards Track [Page 53] RFC 4044 Fibre Channel Management MIB May 2005 OBJECT fcmISPortClassFCredit MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { fcmgmtCompliances 1 } --******************************** -- Object Groups -- fcmInstanceBasicGroup OBJECT-GROUP OBJECTS { fcmInstanceWwn, fcmInstanceFunctions, fcmInstancePhysicalIndex, fcmInstanceSoftwareIndex, fcmInstanceStatus, fcmInstanceTextName, fcmInstanceDescr, fcmInstanceFabricId } STATUS current DESCRIPTION "Basic information about Fibre Channel managed instances." ::= { fcmgmtGroups 1 } fcmSwitchBasicGroup OBJECT-GROUP OBJECTS { fcmSwitchDomainId, fcmSwitchPrincipal, fcmSwitchWWN } STATUS current DESCRIPTION "Basic information about Fibre Channel switches." ::= { fcmgmtGroups 2 } fcmPortBasicGroup OBJECT-GROUP OBJECTS { fcmPortInstanceIndex, fcmPortWwn, fcmPortNodeWwn, fcmPortAdminType, fcmPortOperType, fcmPortFcCapClass, fcmPortFcOperClass, fcmPortTransmitterType, fcmPortConnectorType, fcmPortSerialNumber, fcmPortPhysicalNumber, fcmPortAdminSpeed, fcmPortCapProtocols, fcmPortOperProtocols } STATUS current DESCRIPTION "Basic information about Fibre Channel ports." ::= { fcmgmtGroups 3 } fcmPortStatsGroup OBJECT-GROUP OBJECTS { fcmPortBBCreditZeros, fcmPortFullInputBuffers } STATUS current DESCRIPTION "Traffic statistics, which are not specific to any one class of service, for Fibre Channel ports." ::= { fcmgmtGroups 4 } McCloghrie Standards Track [Page 54] RFC 4044 Fibre Channel Management MIB May 2005 fcmPortClass23StatsGroup OBJECT-GROUP OBJECTS { fcmPortClass2RxFrames, fcmPortClass2RxOctets, fcmPortClass2TxFrames, fcmPortClass2TxOctets, fcmPortClass2Discards, fcmPortClass2RxFbsyFrames, fcmPortClass2RxPbsyFrames, fcmPortClass2RxFrjtFrames, fcmPortClass2RxPrjtFrames, fcmPortClass2TxFbsyFrames, fcmPortClass2TxPbsyFrames, fcmPortClass2TxFrjtFrames, fcmPortClass2TxPrjtFrames, fcmPortClass3RxFrames, fcmPortClass3RxOctets, fcmPortClass3TxFrames, fcmPortClass3TxOctets, fcmPortClass3Discards } STATUS current DESCRIPTION "Traffic statistics for Class 2 and Class 3 traffic on Fibre Channel ports." ::= { fcmgmtGroups 5 } fcmPortClassFStatsGroup OBJECT-GROUP OBJECTS { fcmPortClassFRxFrames, fcmPortClassFRxOctets, fcmPortClassFTxFrames, fcmPortClassFTxOctets, fcmPortClassFDiscards } STATUS current DESCRIPTION "Traffic statistics for Class F traffic on Fibre Channel ports." ::= { fcmgmtGroups 6 } fcmPortLcStatsGroup OBJECT-GROUP OBJECTS { fcmPortLcBBCreditZeros, fcmPortLcFullInputBuffers, fcmPortLcClass2RxFrames, fcmPortLcClass2RxOctets, fcmPortLcClass2TxFrames, fcmPortLcClass2TxOctets, fcmPortLcClass2Discards, fcmPortLcClass3Discards, fcmPortLcClass3RxFrames, fcmPortLcClass3RxOctets, fcmPortLcClass3TxFrames, fcmPortLcClass3TxOctets, fcmPortLcClass2RxFbsyFrames, fcmPortLcClass2RxPbsyFrames, fcmPortLcClass2RxFrjtFrames, fcmPortLcClass2RxPrjtFrames, fcmPortLcClass2TxFbsyFrames, fcmPortLcClass2TxPbsyFrames, fcmPortLcClass2TxFrjtFrames, fcmPortLcClass2TxPrjtFrames } STATUS current DESCRIPTION McCloghrie Standards Track [Page 55] RFC 4044 Fibre Channel Management MIB May 2005 "Low-capacity (32-bit) statistics for Fibre Channel ports." ::= { fcmgmtGroups 7 } fcmPortErrorsGroup OBJECT-GROUP OBJECTS { fcmPortRxLinkResets, fcmPortTxLinkResets, fcmPortLinkResets, fcmPortRxOfflineSequences, fcmPortTxOfflineSequences, fcmPortLinkFailures, fcmPortLossofSynchs, fcmPortLossofSignals, fcmPortPrimSeqProtocolErrors, fcmPortInvalidTxWords, fcmPortInvalidCRCs, fcmPortInvalidOrderedSets, fcmPortFrameTooLongs, fcmPortTruncatedFrames, fcmPortAddressErrors, fcmPortDelimiterErrors, fcmPortEncodingDisparityErrors, fcmPortOtherErrors } STATUS current DESCRIPTION "Error statistics for Fibre Channel ports." ::= { fcmgmtGroups 8 } fcmSwitchPortGroup OBJECT-GROUP OBJECTS { fcmFxPortRatov, fcmFxPortEdtov, fcmFxPortRttov, fcmFxPortHoldTime, fcmFxPortCapBbCreditMax, fcmFxPortCapBbCreditMin, fcmFxPortCapDataFieldSizeMax, fcmFxPortCapDataFieldSizeMin, fcmFxPortCapClass2SeqDeliv, fcmFxPortCapClass3SeqDeliv, fcmFxPortCapHoldTimeMax, fcmFxPortCapHoldTimeMin, fcmISPortClassFCredit, fcmISPortClassFDataFieldSize } STATUS current DESCRIPTION "Information about ports on a Fibre Channel switch." ::= { fcmgmtGroups 9 } fcmSwitchLoginGroup OBJECT-GROUP OBJECTS { fcmFLoginPortWwn, fcmFLoginNodeWwn, fcmFLoginBbCreditModel, fcmFLoginBbCredit, fcmFLoginClassesAgreed, fcmFLoginClass2SeqDelivAgreed, fcmFLoginClass2DataFieldSize, fcmFLoginClass3SeqDelivAgreed, fcmFLoginClass3DataFieldSize } STATUS current DESCRIPTION "Information known to a Fibre Channel switch about attached/logged-in Nx_Ports." McCloghrie Standards Track [Page 56] RFC 4044 Fibre Channel Management MIB May 2005 ::= { fcmgmtGroups 10 } fcmLinkBasicGroup OBJECT-GROUP OBJECTS { fcmLinkEnd1NodeWwn , fcmLinkEnd1PhysPortNumber, fcmLinkEnd1PortWwn, fcmLinkEnd2NodeWwn , fcmLinkEnd2PhysPortNumber, fcmLinkEnd2PortWwn, fcmLinkEnd2AgentAddress, fcmLinkEnd2PortType, fcmLinkEnd2UnitType, fcmLinkEnd2FcAddressId } STATUS current DESCRIPTION "Information about Fibre Channel links." ::= { fcmgmtGroups 11 } END 7. Acknowledgements This memo is partly based on the information contained in the original submission of the Fibre Channel Management Integration MIB to the IETF's IPFC Working Group (now available as [MIB-FA]) and obsoletes RFC 2837. Feedback has been incorporated into this document based on comments from the following: Sudhir Pendse, SimpleSoft; Steve Senum, Cisco Systems; and Kha Sin Teow, Brocade. 8. Normative References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC 2737, December 1999. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. McCloghrie Standards Track [Page 57] RFC 4044 Fibre Channel Management MIB May 2005 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [FC-AL-2] "Fibre Channel - Arbitrated Loop (FC-AL-2)", ANSI INCITS 332-1999, 1999. [FC-BB] "Fibre Channel - Backbone (FC-BB)" ANSI INCITS 342-2001, 2001. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)" ANSI INCITS 373-2003, April 2003. [FC-GS-3] "Fibre Channel - Generic Services - 3 (FC-GS-3)" ANSI INCITS 348-2001, 2001. [FC-MI] "Fibre Channel - Methodologies for Interconnects Technical Report (FC-MI)" INCITS TR-30-2002, 2002. [FC-PH] "Information Technology - Fibre Channel Physical and Signaling Interface (FC-PH)", ANSI X3.230, 1994. [FC-SW-3] "Fibre Channel - Switch Fabric - 3 (FC-SW-3)", ANSI INCITS 384-2004, June 2004. 9. Informative References [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. McCloghrie Standards Track [Page 58] RFC 4044 Fibre Channel Management MIB May 2005 [MIB-FA] "INCITS Technical Report for Information Technology - Fibre Channel - Management Information Base - FA (MIB-FA)", INCITS, TR-32-2003. [WWN1] Snively, R., "New identifier formats based on IEEE registration", http://standards.ieee.org/regauth/oui/ tutorials/fibreformat.html, 16 January 2001. [WWN2] Snively, R., "Use of the IEEE Registration Authority assigned 'company_id' with the ANSI X3.230 FC-PH Fibre Channel specification and its extensions", http://standards.ieee.org/regauth/oui/tutorials/ fibrecomp_id.html, 24 February 1997. 10. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write: fcmInstanceTextName fcmInstanceDescr fcmSwitchDomainId fcmPortAdminType fcmPortAdminSpeed fcmISPortClassFCredit Such objects may be considered sensitive or vulnerable in some network environments. For example, the ability to change network topology or network speed may afford an attacker the ability to obtain better performance at the expense of other network users; setting fcmSwitchDomainId to an invalid value could lead to denial of service in some configurations. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. In particular, these objects provide information on network topology: fcmLinkEnd1NodeWwn fcmLinkEnd1PhysPortNumber fcmLinkEnd1PortWwn fcmLinkEnd2NodeWwn fcmLinkEnd2PhysPortNumber McCloghrie Standards Track [Page 59] RFC 4044 Fibre Channel Management MIB May 2005 fcmLinkEnd2PortWwn fcmLinkEnd2AgentAddress fcmLinkEnd2PortType fcmLinkEnd2UnitType fcmLinkEnd2FcAddressId SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. IANA Considerations 11.1. OID Assignment IANA has made a MIB OID assignment under the transmission branch. Specifically, transmission 56 has been assigned as the OID for fcMgmtMIB. This sub-identifier was requested because this MIB contains the media-specific definitions that correspond to the ifType value of fibreChannel(56). 11.2. FC Port Type Registry IANA has established a registry for Fibre Channel Port Types. The registry is split into disjointed subset ranges: 1) a 'standard' range for Fibre Channel Port Types that have been standardized by the InterNational Committee for Information Technology Standards (INCITS)'s Technical Committee T11. This range will be subject to the 'Expert Review' and 'Specification Required' policies described in [RFC2434], with the following provisions: - the Expert Reviewer is to be appointed by the IESG. McCloghrie Standards Track [Page 60] RFC 4044 Fibre Channel Management MIB May 2005 - the Expert Reviewer shall obtain approval (or rejection) from INCITS Technical Committee T11 via the chair of that Committee. Rejected values shall not be added to the registry. - if the addition is approved, the Expert shall advise IANA of how to record the reference to the T11 specification document that describes the newly added port type(s), and that is considered to be the "other permanent and readily available reference" required by [RFC2434]. The initial assignments in the 'standard' range will be as follows: Assigned Value Type Meaning -------- ------ ------- 1 unknown for use when the type is not known, or is "unidentified" as specified in section 5.1.2.10 of [FC-GS-3] 2 other used for types without assigned values 3 -- an obsolete value, not to be re-assigned 4 N_Port see [FC-FS] 5 NL_Port see [FC-FS] 6 F_Port see [FC-FS] 7 FL_Port see [FC-FS] 8 E_Port see [FC-FS] 9 B_Port see [FC-FS] 10 G_Port see [FC-SW-3] 11 GL_Port see [FC-SW-3] 12 F/NL_Port see [FC-AL-2] The above range extends up to a maximum of 9,999. 2) a range assigned under the "Private Use" policy described in [RFC2434] for values intended for private use by one party or among mutually consenting parties. Values in this range extend from 10,000 to 99,999. IANA will not make any allocations from this range. 3) values larger than 99,999 are RESERVED. McCloghrie Standards Track [Page 61] RFC 4044 Fibre Channel Management MIB May 2005 12. Comparison to the Fibre Channel Management Integration MIB 12.1. Problems with the Fibre Channel Management Integration MIB The Fibre Channel Management Integration MIB [MIB-FA] had the following major problems: - It wasn't formatted using SMIv2, which is mandatory. - The MIB seemed to have been defined with the notion that it would be the only MIB that a Fibre Channel product will require. The notion of an agent implementing just a single MIB was abandoned by the IETF in 1992 as being non-scalable. Rather, a Fibre Channel MIB needed to be another MIB in the continuing series of MIBs defined by the IETF, and thus, it needed to be consistent with its predecessors. In other words, there are existing MIBs that all SNMP agents must support, even if the support of Fibre Channel interfaces is the only functionality that they have. Thus, it was essential that the Fibre Channel Integration MIB contained only objects for information that is specific to Fibre Channel. All objects relevant to non-Fibre Channel environments needed to be removed. This issue applied to a large fraction of the objects defined in the MIB. - The MIB had some but not complete overlap in functionality with RFC 2837. - Every SNMP agent must implement the ifTable. The ifTable counters are the MIB objects most well-used by administrators in SNMP management. SNMP agents need to implement a row in the ifTable for each of their network interfaces, including their Fibre Channel interfaces. The IF-MIB requires a media-specific MIB to specify how that type of interface uses the ifTable (see section 4 in RFC 2863). [RFC2837] doesn't do that, nor did the Fibre Channel Integration MIB. - It incorrectly used the OCTET STRING syntax (instead of Counter32 or Counter64) for counters. 12.2. Detailed Changes 12.2.1. Removal of Sensor-Related Objects Information about sensors is not specific to Fibre Channel, and therefore should not be in this MIB. (At the time of writing, the IETF's ENTITY MIB Working Group has produced a first draft of a Sensor MIB, see [RFC3433].) This removed the need for: McCloghrie Standards Track [Page 62] RFC 4044 Fibre Channel Management MIB May 2005 connUnitSensorTable (and all its contents) connUnitNumSensors connUnitSensorStatusChange 12.2.2. Removal of Trap-registration Objects Information about registering "traps" is not specific to Fibre Channel, and therefore should not be in this MIB. (For similar functionality, see SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB in RFC 2573). This removed the need for: trapMaxClients trapClientCount trapRegTable (and all its contents) 12.2.3. Removal of Event-Related Objects Information about generic events is not specific to Fibre Channel, and therefore should not be in this MIB. (For similar functionality, see the Event group in RFC 2819 and the Notification Log MIB in RFC 3014; the SNMP-NOTIFICATION-MIB provides for the filtering of notifications.) This removed the need for: connUnitEventTable (and all its contents) connUnitEventFilter connUnitNumEvents connUnitMaxEvents connUnitEventCurrID connUnitEventTrap 12.2.4. Removal of Inventory-Related Information Aspects of hardware (physical) components are represented in the Entity MIB (RFC 2737); aspects of software modules are represented in the Host Resources MIB (RFC 2790). Two new objects provide indexing from this MIB into those MIBs: one having the value of PhysicalIndex (or zero) and the other having the value of hrSWInstalledIndex (or zero). These replaced the need for: connUnitNumports connUnitRevsTable (and all its contents) connUnitNumRevs connUnitPortRevision connUnitPortVendor connUnitProduct connUnitInfo connUnitSn connUnitModuleId McCloghrie Standards Track [Page 63] RFC 4044 Fibre Channel Management MIB May 2005 connUnitVendorId connUnitDeletedTrap 12.2.5. Removal of Revision Numbers The forward/backward compatibility rules of how to evolve MIBs are designed such that MIBs do not have revision numbers. This removed the need for: revisionNumber 12.2.6. Removal of Other Not FC-Specific Information Other information was removed because it was not specific to Fibre Channel: systemURL statusChangeTime configurationChangeTime connUnitUrl connUnitUpTime connUnitState connUnitContact connUnitLocation connUnitProxyMaster connUnitControl connUnitStatus connUnitStatusChange 12.2.7. Clean-up of Ambiguous/Obsolete Definitions Some information in the FC Management integration was obsolete or ambiguous: statusChangeTime (obsolete) configurationChangeTime (obsolete) connUnitTableChangeTime (obsolete) connUnitStatusChangeTime (obsolete) connUnitConfigurationChangeTime (obsolete) connUnitNumZones (obsolete) connUnitZoneTable (referenced but not defined) connUnitLinkCurrIndex (badly defined) 12.2.8. Use of an ifTable Entry The following objects were removed because they duplicated existing IF-MIB objects: McCloghrie Standards Track [Page 64] RFC 4044 Fibre Channel Management MIB May 2005 redundant object existing object(s) ---------------- ------------------ connUnitPortStatCountError ifInErrors & ifOutErrors connUnitPortStatCountTxObjects ifOutUcastPkts & ifHCOutUcastPkts connUnitPortStatCountRxObjects ifInUcastPkts & ifHCInUcastPkts connUnitPortStatCountTxElements ifOutOctets & ifHCOutOctets connUnitPortStatCountRxElements ifInOctets & ifHCInOctets connUnitPortStatCountRxMulticastObjects ifInMulticastPkts & ifHCInMulticastPkts connUnitPortStatCountTxMulticastObjects ifOutMulticastPkts & ifHCOutMulticastPkts connUnitPortStatCountRxBroadcastObjects ifInBroadcastPkts & ifHCInBroadcastPkts connUnitPortStatCountTxBroadcastObjects ifOutBroadcastPkts & ifHCOutBroadcastPkts connUnitPortFCId ifPhysAddress connUnitPortControl ifAdminStatus connUnitPortState ifAdminStatus connUnitPortHWState ifOperStatus connUnitPortStatus ifOperStatus connUnitPortName ifAlias connUnitPortStatObject ifSpecific connUnitNumports ifNumber connUnitPortStatusChange linkUp/linkDown 12.2.9. Removed Because of AgentX Difficulty An AgentX environment [RFC2741] consists of a master agent and several sub-agents. It is not difficult to implement the same MIB in several such sub-agents if all of the MIB's tables have a common index variable as the first auxiliary object in their INDEX clauses. However, any scalars that the MIB contains pose a problem for the AgentX environment. All the (remaining) scalars were therefore removed: revisionNumber uNumber systemURL McCloghrie Standards Track [Page 65] RFC 4044 Fibre Channel Management MIB May 2005 12.2.10. FC Management Instance The term "connectivity unit" was changed to "FC management instance". The term "connectivity unit" was not properly defined in [MIB-FA], and its usage provided a confused mixture of indications to the implementor: - the definition of FcUnitType suggested it was functional; - the definition of uNumber suggested it was physical; - the definition of connUnitProduct suggested it was a vendor's product; - etc. The common implementation strategy for the "connectivity unit" was which ever grouping provided access to the management functionality the easiest. (One such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, each supporting a separate implementation of the MIB.) In fact, this scenario is not new; in practice, a "connectivity unit" will have the same semantics as a management "instance" in other MIBs, e.g., the IPS WG's own iSCSI MIB. For this MIB, its meaning is: "a separable managed instance of Fibre Channel functionality". Given this definition, the "FC management instance" is a better name because it is more accurate and more representative of the definition than is "connectivity unit". 12.2.11. Counter Syntax All packet and octet counters have been changed to be Counter64's (but Counter32 versions of them are also included for use by old agents). The error counters have been changed to Counter32's. (In the probably impossible, and at most improbable, circumstances that the rate of occurrence of errors, even on a 10Gbs Fibre Channel interface, might wrap faster than an hour, the fact that errors are occurring will almost certainly be apparent from other MIB objects.) 12.2.12. Obsolete/Little-Used Fibre Channel Features Information relating to Fibre Channel features that are obsolete or not widely-implemented has been deleted. (For more information, see section 6.2.1 and section 6.2.2 of [FC-MI].) McCloghrie Standards Track [Page 66] RFC 4044 Fibre Channel Management MIB May 2005 - Class 1 service, - Intermix Mode, - Stacked Conn Mode. - PH version numbers Note that with support for Class 1 service being deleted, only class 2 now needs F_BSY, F_RJT, P_BSY, and P_RJT counters, and thus they no longer need to be counted for all classes as well as for class 2, and therefore the following objects have been deleted: connUnitPortStatCountFBSYFrames connUnitPortStatCountPBSYFrames connUnitPortStatCountFRJTFrames connUnitPortStatCountPRJTFrames 12.3. Name Server Objects A table of Name Server information was present in the Fibre Channel Management Integration MIB [MIB-FA]. That information is not currently represented in this MIB because this MIB is already quite large, and a set of Name Server objects are expected to be defined in a separate (new) MIB. 12.4. Additional Objects Support for Class F traffic, including 32-bit octet and frame counters, has been added. 13. Comparison to RFC 2837 This MIB is a superset of RFC 2837, except for the following: - the fcFeClass1AccountingGroup group is obsolete, - fcFxPortConnectedNxPort, fcFxPortFcphVersionHigh, fcFxPortFcphVersionLow, fcFxPortFcphVersionAgreed, fcFxPortStackedConnModeAgreed, fcFxPortIntermixSuppAgreed, fcFxPortCapStackedConnMode, and fcFxPortCapIntermix are obsolete, - fcFxPortBbCredit and fcFxPortRxBufSize are per attached Nx_Port, - fcFxPortBbCreditAvailable is ephemeral, - fcFeModuleTable is mostly contained in the entPhysicalTable, - fcFxPortPhysAdminStatus, fcFxPortPhysOperStatus, and fcFxPortPhysLastChange have equivalents in the ifTable. McCloghrie Standards Track [Page 67] RFC 4044 Fibre Channel Management MIB May 2005 Author's Address Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com McCloghrie Standards Track [Page 68] RFC 4044 Fibre Channel Management MIB May 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McCloghrie Standards Track [Page 69] snmp-mibs-downloader-1.1/mibrfcs/rfc4069.txt0000644000000000000000000010560011402176072015567 0ustar Network Working Group M. Dodge Request for Comments: 4069 ECI Telecom Category: Standards Track B. Ray PESA Switching Systems May 2005 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. Dodge & Ray Standards Track [Page 1] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 Table of Contents 1. The Internet-Standard Management Framework .............. .... 2 2. Overview ..................................................... 2 2.1. Relationship of this MIB Module to Other MIB Modules ... 3 2.2. Conventions Used in the MIB Module ..................... 3 2.3. Structure .......................... .................. 3 2.4. Persistence ............................................ 4 3. Conformance and Compliance ................................... 5 4. Definitions .................................................. 5 5. Acknowledgements ............................................. 14 6. Security Considerations ...................................... 14 7. IANA Considerations .......................................... 16 8. References ................................................... 16 8.1. Normative References ................................... 16 8.2. Informative References ................................. 17 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This document describes an SNMP MIB module for managing the Line Code Dependent, Physical Medium Dependent (PMD) Layer of SCM VDSL Lines. These definitions are based upon the specifications for VDSL as defined in T1E1, European Telecommunications Standards Institute (ETSI), and International Telecommunication Union (ITU) documentation [T1E1311, T1E1011, T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971]. Additionally the protocol-dependent (and line-code dependent) management framework for VDSL lines specified by the Digital Subscriber Line Forum (DSLF) has been taken into consideration [DSLFTR57] and [DSLFWT96]. Dodge & Ray Standards Track [Page 2] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 The MIB module is located in the MIB tree under MIB-2 transmission. The key words "MUST", "MUST NOT", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119]. 2.1. Relationship of this MIB Module to Other MIB Modules The relationship of the VDSL Line MIB module to other MIB modules, in particular to the IF-MIB presented in RFC 2863 [RFC2863], is discussed in the VDSL-LINE-MIB, RFC 3728 [RFC3728]. This section outlines the relationship of this VDSL Line Extension MIB to the VDSL-LINE-MIB, RFC 3728 [RFC3728]. 2.2. Conventions Used in the MIB Module 2.2.1. Naming Conventions A. Vtuc -- VDSL transceiver unit at near (Central) end of line B. Vtur -- VDSL transceiver unit at Remote end of line C. Vtu -- One of either Vtuc or Vtur D. Curr -- Current F. Atn -- Attenuation J. LCS -- Line Code Specific K. Max -- Maximum Q. Mgn -- Margin S. PSD -- Power Spectral Density T. Rx -- Receive T. Snr -- Signal to Noise Ratio U. Tx -- Transmit 2.3. Structure The SCM VDSL Line Extension MIB contains the following MIB group: o vdslSCMGroup : This group supports MIB objects for defining configuration profiles and for monitoring individual bands of Single Carrier Modulation (SCM) VDSL modems. It contains the following tables: - vdslLineSCMConfProfileTxBandTable - vdslSCMPhysBandTable If the SCM VDSL Line Extension MIB is implemented then all objects in this group MUST be implemented. Figure 1 below displays the relationship of the tables in the vdslSCMGroup to the vdslGroup and to the ifEntry: Dodge & Ray Standards Track [Page 3] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 ifEntry(ifType=97) ----> vdslLineTableEntry 1:(0..1) vdslLineTableEntry (vdslLineCoding=SCM) ----> vdslPhysTableEntry 1:(0..2) ----> vdslSCMPhysBandTable 1:(0..5) vdslLineConfProfileEntry(vdslLineConfProfileName) ----> vdslLineSCMConfProfileBandTable 1:(0..5) Figure 1: Table Relationships When the object vdslLineCoding is set to SCM, vdslLineConfProfileName is used as the index to vdslLineSCMConfProfileBandTable. The existence of an entry in any of the tables of the vdslSCMGroup is optional. 2.4. Persistence All read-create objects defined in this MIB module SHOULD be stored persistently. Following is an exhaustive list of these persistent objects: vdslLineSCMConfProfileBandId vdslLineSCMConfProfileBandUsage vdslLineSCMConfProfileBandCenterFrequency vdslLineSCMConfProfileBandSymbolRate vdslLineSCMConfProfileBandConstellationSize vdslLineSCMConfProfileBandTransmitPSDLevel vdslLineSCMConfProfileBandRowStatus vdslLineSCMPhysBandId vdslLineSCMPhysBandUsage vdslLineSCMPhysBandCurrPSDLevel vdslLineSCMPhysBandCurrSymbolRate vdslLineSCMPhysBandCurrConstellationSize vdslLineSCMPhysBandCurrCenterFrequency vdslLineSCMPhysBandPerformanceBandId vdslLineSCMPhysBandPerformanceBandUsage vdslLineSCMPhysBandPerformanceBandSnrMgn vdslLineSCMPhysBandPerformanceBandAtn Note also that the interface indices in this MIB are maintained persistently. View-based Access Control Model (VACM) data relating to these SHOULD be stored persistently as well [RFC3415]. Dodge & Ray Standards Track [Page 4] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 3. Conformance and Compliance An SCM based VDSL agent does not have to implement this MIB to be compliant with RFC 3728 [RFC3728]. If the SCM VDSL Line Extension MIB is implemented then the following group is mandatory: - vdslSCMGroup 4. Definitions VDSL-LINE-EXT-SCM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, transmission, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, TruthValue, RowStatus FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] ifIndex FROM IF-MIB -- [RFC2863] vdslLineConfProfileName FROM VDSL-LINE-MIB; -- [RFC3728] vdslExtSCMMIB MODULE-IDENTITY LAST-UPDATED "200504280000Z" -- April 28, 2005 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair/Co-editor: Bob Ray PESA Switching Systems, Inc. Postal: 330-A Wynn Drive Huntsville, AL 35805 USA Email: rray@pesa.com Phone: +1 256 726 9200 ext. 142 Dodge & Ray Standards Track [Page 5] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 Co-editor: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel Email: mbdodge@ieee.org Phone: +972 3 926 8421 " DESCRIPTION "The VDSL-LINE-MIB found in RFC 3728 defines objects for the management of a pair of VDSL transceivers at each end of the VDSL line. The VDSL-LINE-MIB configures and monitors the line code independent parameters (TC layer) of the VDSL line. This MIB module is an optional extension of the VDSL-LINE-MIB and defines objects for configuration and monitoring of the line code specific (LCS) elements (PMD layer) for VDSL lines using SCM coding. The objects in this extension MIB MUST NOT be used for VDSL lines using Multiple Carrier Modulation (MCM) line coding. If an object in this extension MIB is referenced by a line which does not use SCM, it has no effect on the operation of that line. Naming Conventions: Vtuc -- VDSL transceiver at near (Central) end of line Vtur -- VDSL transceiver at Remote end of line Vtu -- One of either Vtuc or Vtur Curr -- Current Atn -- Attenuation LCS -- Line Code Specific Max -- Maximum Mgn -- Margin PSD -- Power Spectral Density Rx -- Receive Snr -- Signal to Noise Ratio Tx -- Transmit Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4069: see the RFC itself for full legal notices." REVISION "200504280000Z" -- April 28, 2005 DESCRIPTION "Initial version, published as RFC 4069." ::= { transmission 228 } vdslLineExtSCMMib OBJECT IDENTIFIER ::= { vdslExtSCMMIB 1 } vdslLineExtSCMMibObjects OBJECT IDENTIFIER ::= { vdslLineExtSCMMib 1 } -- Dodge & Ray Standards Track [Page 6] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 -- textual conventions used in this MIB -- VdslSCMBandId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax for the VDSL SCM Band Identity. Attributes with this syntax identify the SCM Band referred to. Specified as an INTEGER, the possible values are: optionalBand (1) -- the optional Band range [25kHz - 138kHz] firstDownstreamBand (2) -- first Downstream Band firstUpstreamBand (3) -- first Upstream Band secondDownstreamBand (4) -- second Downstream Band secondUpstreamBand (5) -- second Upstream Band thirdDownstreamBand (6) -- third Downstream Band thirdUpstreamBand (7) -- third Upstream Band" SYNTAX INTEGER { optionalBand (1), firstDownstreamBand (2), firstUpstreamBand (3), secondDownstreamBand (4), secondUpstreamBand (5), thirdDownstreamBand (6), thirdUpstreamBand(7) } -- -- Single carrier modulation (SCM) configuration profile tables -- vdslLineSCMConfProfileBandTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineSCMConfProfileBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains transmit band descriptor configuration information for a VDSL line. Each entry in this table reflects the configuration for one of possibly many bands of a single carrier modulation (SCM) VDSL line. For each profile which is associated with a VDSL line using SCM line coding, five entries in this table will exist, one for each of the five bands. Bands which are not in use will be marked as unused. These entries are defined by a manager and can be used to configure the VDSL line. If an entry in Dodge & Ray Standards Track [Page 7] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 this table is referenced by a line which does not use SCM, it has no effect on the operation of that line." ::= { vdslLineExtSCMMibObjects 1 } vdslLineSCMConfProfileBandEntry OBJECT-TYPE SYNTAX VdslLineSCMConfProfileBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of a single carrier modulation VDSL modem transmit band. A default profile with an index of 'DEFVAL', will always exist and its parameters will be set to vendor specific values, unless otherwise specified in this document. All read-create objects defined in this MIB module SHOULD be stored persistently." INDEX { vdslLineConfProfileName, vdslLineSCMConfProfileBandId } ::= { vdslLineSCMConfProfileBandTable 1 } VdslLineSCMConfProfileBandEntry ::= SEQUENCE { vdslLineSCMConfProfileBandId VdslSCMBandId, vdslLineSCMConfProfileBandInUse TruthValue, vdslLineSCMConfProfileBandCenterFrequency Unsigned32, vdslLineSCMConfProfileBandSymbolRate Unsigned32, vdslLineSCMConfProfileBandConstellationSize Unsigned32, vdslLineSCMConfProfileBandTransmitPSDLevel Unsigned32, vdslLineSCMConfProfileBandRowStatus RowStatus } vdslLineSCMConfProfileBandId OBJECT-TYPE SYNTAX VdslSCMBandId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The BandId for this entry, which specifies which band is being referred to." ::= { vdslLineSCMConfProfileBandEntry 1 } Dodge & Ray Standards Track [Page 8] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 vdslLineSCMConfProfileBandInUse OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether this band is in use. If set to True this band is in use." ::= { vdslLineSCMConfProfileBandEntry 2 } vdslLineSCMConfProfileBandCenterFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the center frequency in Hz" REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMConfProfileBandEntry 3 } vdslLineSCMConfProfileBandSymbolRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "baud" MAX-ACCESS read-create STATUS current DESCRIPTION "The requested symbol rate in baud." REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMConfProfileBandEntry 4 } vdslLineSCMConfProfileBandConstellationSize OBJECT-TYPE SYNTAX Unsigned32 (0..16) UNITS "log2" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the constellation size." REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMConfProfileBandEntry 5 } Dodge & Ray Standards Track [Page 9] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 vdslLineSCMConfProfileBandTransmitPSDLevel OBJECT-TYPE SYNTAX Unsigned32 UNITS "-0.25 dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "The requested transmit power spectral density for the VDSL modem. The Actual value in -0.25 dBm/Hz." REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMConfProfileBandEntry 6 } vdslLineSCMConfProfileBandRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile activated by setting this object to `active'. When `active' is set, the system will validate the profile. None of the columns in this row may be modified while the row is in the `active' state. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `notInService') it must be first unreferenced from all associated lines." ::= { vdslLineSCMConfProfileBandEntry 7 } -- -- SCM physical band -- vdslLineSCMPhysBandTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineSCMPhysBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each SCM Vtu band. This table is read only as it reflects the current physical parameters of each band. For each ifIndex which is associated with a VDSL line using SCM line coding, five entries in this table will exist, one for each of the five bands. Bands which are not in use will be marked as unused." Dodge & Ray Standards Track [Page 10] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 ::= { vdslLineExtSCMMibObjects 2 } vdslLineSCMPhysBandEntry OBJECT-TYPE SYNTAX VdslLineSCMPhysBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslLineSCMPhysBandTable." INDEX { ifIndex, vdslLineSCMPhysBandId } ::= { vdslLineSCMPhysBandTable 1 } VdslLineSCMPhysBandEntry ::= SEQUENCE { vdslLineSCMPhysBandId VdslSCMBandId, vdslLineSCMPhysBandInUse TruthValue, vdslLineSCMPhysBandCurrCenterFrequency Unsigned32, vdslLineSCMPhysBandCurrSymbolRate Unsigned32, vdslLineSCMPhysBandCurrConstellationSize Unsigned32, vdslLineSCMPhysBandCurrPSDLevel Unsigned32, vdslLineSCMPhysBandCurrSnrMgn Integer32, vdslLineSCMPhysBandCurrAtn Unsigned32 } vdslLineSCMPhysBandId OBJECT-TYPE SYNTAX VdslSCMBandId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The BandId for this entry, which specifies which band is being referred to." ::= { vdslLineSCMPhysBandEntry 1 } vdslLineSCMPhysBandInUse OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether this band is in use. If set to True this band is in use." ::= { vdslLineSCMPhysBandEntry 2 } Dodge & Ray Standards Track [Page 11] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 vdslLineSCMPhysBandCurrCenterFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "Hz" MAX-ACCESS read-only STATUS current DESCRIPTION "The current center frequency in Hz for this band." REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMPhysBandEntry 3 } vdslLineSCMPhysBandCurrSymbolRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "baud" MAX-ACCESS read-only STATUS current DESCRIPTION "The current value of the symbol rate in baud for this band." REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMPhysBandEntry 4 } vdslLineSCMPhysBandCurrConstellationSize OBJECT-TYPE SYNTAX Unsigned32 (0..16) UNITS "log2" MAX-ACCESS read-only STATUS current DESCRIPTION "The current constellation size on this band." REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMPhysBandEntry 5 } vdslLineSCMPhysBandCurrPSDLevel OBJECT-TYPE SYNTAX Unsigned32 UNITS "- 0.25 dBm/Hz" MAX-ACCESS read-only STATUS current DESCRIPTION "The transmit power spectral density for the VDSL modem." REFERENCE "T1E1.4/2000-011R3" -- Part 2, SCM ::= { vdslLineSCMPhysBandEntry 6 } Dodge & Ray Standards Track [Page 12] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 vdslLineSCMPhysBandCurrSnrMgn OBJECT-TYPE SYNTAX Integer32 UNITS "0.25 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Noise margin as seen by this Vtu and band with respect to its received signal in 0.25 dB." ::= { vdslLineSCMPhysBandEntry 7 } vdslLineSCMPhysBandCurrAtn OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "0.25 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured difference in the total power transmitted by the peer Vtu on this band and the total power received by this Vtu on this band in 0.25 dB." ::= { vdslLineSCMPhysBandEntry 8 } -- conformance information vdslLineExtSCMConformance OBJECT IDENTIFIER ::= { vdslLineExtSCMMib 2 } vdslLineExtSCMGroups OBJECT IDENTIFIER ::= { vdslLineExtSCMConformance 1 } vdslLineExtSCMCompliances OBJECT IDENTIFIER ::= { vdslLineExtSCMConformance 2 } vdslLineExtSCMMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which manage VDSL interfaces." MODULE -- this module MANDATORY-GROUPS { vdslLineExtSCMGroup } ::= { vdslLineExtSCMCompliances 1 } Dodge & Ray Standards Track [Page 13] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 -- units of conformance vdslLineExtSCMGroup OBJECT-GROUP OBJECTS { vdslLineSCMConfProfileBandInUse, vdslLineSCMConfProfileBandTransmitPSDLevel, vdslLineSCMConfProfileBandSymbolRate, vdslLineSCMConfProfileBandConstellationSize, vdslLineSCMConfProfileBandCenterFrequency, vdslLineSCMConfProfileBandRowStatus, vdslLineSCMPhysBandInUse, vdslLineSCMPhysBandCurrPSDLevel, vdslLineSCMPhysBandCurrSymbolRate, vdslLineSCMPhysBandCurrConstellationSize, vdslLineSCMPhysBandCurrCenterFrequency, vdslLineSCMPhysBandCurrSnrMgn, vdslLineSCMPhysBandCurrAtn } STATUS current DESCRIPTION "A collection of objects providing configuration information for a VDSL line based upon single carrier modulation modem." ::= { vdslLineExtSCMGroups 1 } END 5. Acknowledgments This document contains many definitions taken from an early version of the VDSL MIB [RFC3728]. As such, any credit for the text found within should be fully attributed to the authors of that document. 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: vdslLineSCMConfProfileBandTable vdslLineSCMConfProfileBandInUse, vdslLineSCMConfProfileBandTransmitPSDLevel, vdslLineSCMConfProfileBandSymbolRate, Dodge & Ray Standards Track [Page 14] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 vdslLineSCMConfProfileBandConstellationSize, vdslLineSCMConfProfileBandCenterFrequency, vdslLineSCMConfProfileBandRowStatus VDSL layer connectivity from the Vtur will permit the subscriber to manipulate both the VDSL link directly and the VDSL embedded operations channel (EOC) for their own loop. For example, unchecked or unfiltered fluctuations initiated by the subscriber could generate sufficient notifications to potentially overwhelm either the management interface to the network or the element manager. Additionally, allowing write access to configuration data may allow an end-user to increase their service levels or affect other end- users in either a positive or negative manner. For this reason, the tables and objects listed above should be considered to contain sensitive information. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: vdslLineSCMPhysBandInUse, vdslLineSCMPhysBandCurrPSDLevel, vdslLineSCMPhysBandCurrSymbolRate, vdslLineSCMPhysBandCurrConstellationSize, vdslLineSCMPhysBandCurrCenterFrequency, vdslLineSCMPhysBandCurrSnrMgn, vdslLineSCMPhysBandCurrAtn Read access of the physical band parameters may provide knowledge to an end-user that would allow malicious behavior, for example the application of an intentional interference on one or all of the physical bands in use. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Dodge & Ray Standards Track [Page 15] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of a MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations The IANA has assigned the transmission value 228 to VDSL-LINE-EXT- SCM-MIB. 8. References 8.1. Normative References [DSLFTR57] DSL Forum TR-057, "VDSL Network Element Management", February 2003. [DSLFWT96] DSL Forum WT-096, "SCM Specific Managed Objects In VDSL Network Elements". [ETSI2701] ETSI TS 101 270-1 V1.2.1, "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements", October 1999. [ETSI2702] ETSI TS 101 270-2 V1.1.1, "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Transceiver specification", February 2001. [ITU9931] ITU-T G.993.1, "Very-high-speed digital subscriber line foundation", November 2001. [ITU9971] ITU-T G.997.1, "Physical layer management for Digital Subscriber Line (DSL) Transceivers", July 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Dodge & Ray Standards Track [Page 16] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3728] Ray, B. and R. Abbi, "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", RFC 3728, February 2004. [T1E1311] ANSI T1E1.4/2001-311, "Very-high-bit-rate Digital Subscriber Line (VDSL) Metallic Interface, Part 1: Functional Requirements and Common Specification", February 2001. [T1E1011] ANSI T1E1.4/2001-011R3, "VDSL Metallic Interface, Part 2: Technical Specification for a Single-Carrier Modulation (SCM) Transceiver", November 2001. [T1E1013] ANSI T1E1.4/2001-013R4, "VDSL Metallic Interface, Part 3: Technical Specification for a Multi-Carrier Modulation (MCM) Transceiver", November 2000. 8.2. Informative References [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Dodge & Ray Standards Track [Page 17] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 Authors' Addresses Menachem Dodge ECI Telecom Ltd. 30 Hasivim St. Petach Tikva 49517, Israel Phone: +972 3 926 8421 Fax: +972 3 928 7342 EMail: mbdodge@ieee.org Bob Ray PESA Switching Systems, Inc. 330-A Wynn Drive Huntsville, AL 35805 USA Phone: +1 256 726 9200 ext. 142 Fax: +1 256 726 9271 EMail: rray@pesa.com Dodge & Ray Standards Track [Page 18] RFC 4069 VDSL-LINE-EXT-SCM-MIB May 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Dodge & Ray Standards Track [Page 19] snmp-mibs-downloader-1.1/mibrfcs/rfc4070.txt0000644000000000000000000013666111402176072015572 0ustar Network Working Group M. Dodge Request for Comments: 4070 ECI Telecom Category: Standards Track B. Ray PESA Switching Systems May 2005 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. Dodge & Ray Standards Track [Page 1] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 2.1. Relationship of this MIB Module to other MIB Modules .......3 2.2. Conventions used in the MIB Module .........................3 2.3. Structure ..................................................3 2.4. Persistence ................................................4 3. Conformance and Compliance ......................................5 4. Definitions .....................................................5 5. Acknowledgments ................................................19 6. Security Considerations ........................................19 7. IANA Considerations ............................................21 8. References .....................................................21 8.1. Normative References ......................................21 8.2. Informative References ....................................23 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This document describes an SNMP MIB module for managing the Line Code Dependent, Physical Medium Dependent (PMD), Layer of MCM VDSL Lines. These definitions are based upon the specifications for VDSL as defined in T1E1, European Telecommunications Standards Institute (ETSI), and International Telecommunication Union (ITU) documentation [T1E1311, T1E1011, T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971]. Additionally the protocol-dependent (and line-code dependent) management framework for VDSL lines specified by the Digital Subscriber Line Forum (DSLF) has been taken into consideration [DSLFTR57]. Dodge & Ray Standards Track [Page 2] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 The MIB module is located in the MIB tree under MIB-2 transmission. The key words "MUST", "MUST NOT", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119]. 2.1. Relationship of this MIB Module to other MIB Modules The relationship of the VDSL Line MIB module to other MIB modules and in particular to the IF-MIB, as presented in RFC 2863 [RFC2863], is discussed in the VDSL-LINE-MIB, RFC 3728 [RFC3728]. This section outlines the relationship of this VDSL Line Extension MIB to the VDSL-LINE-MIB, RFC 3728 [RFC3728]. 2.2. Conventions used in the MIB Module 2.2.1. Naming Conventions A. Vtuc -- (VTUC) transceiver at near (Central) end of line B. Vtur -- (VTUR) transceiver at Remote end of line C. Vtu -- One of either Vtuc or Vtur D. Curr -- Current E. LCS -- Line Code Specific F. Max -- Maximum G. PSD -- Power Spectral Density H. Rx -- Receive I. Tx -- Transmit 2.3. Structure The MCM VDSL Line Extension MIB contains the following MIB group: o vdslMCMGroup : This group supports MIB objects for defining configuration profiles and for monitoring individual bands of Multiple Carrier Modulation (MCM) VDSL modems. It contains the following tables: - vdslLineMCMConfProfileTable - vdslLineMCMConfProfileTxBandTable - vdslLineMCMConfProfileRxBandTable - vdslLineMCMConfProfileTxPSDTable - vdslLineMCMConfProfileMaxTxPSDTable - vdslLineMCMConfProfileMaxRxPSDTable If the MCM VDSL Line Extension MIB is implemented then all of the objects in this group MUST be implemented. Dodge & Ray Standards Track [Page 3] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 Figure 1, below, displays the relationship of the tables in the vdslMCMGroup to the vdslGroup and to the ifEntry: ifEntry(ifType=97) ----> vdslLineTableEntry 1:(0..1) vdslLineTableEntry (vdslLineCoding=MCM) vdslLineConfProfileEntry(vdslLineConfProfileName) ----> vdslLineMCMConfProfileTable 1:(0..1) ----> vdslLineMCMConfProfileTxBandTable 1:(0..n) ----> vdslLineMCMConfProfileRxBandTable 1:(0..n) ----> vdslLineMCMConfProfileTxPSDTable 1:(0..n) ----> vdslLineMCMConfProfileMaxTxPSDTable 1:(0..n) ----> vdslLineMCMConfProfileMaxRxPSDTable 1:(0..n) Figure 1: Table Relationships When the object vdslLineCoding is set to MCM, vdslLineConfProfileName is used as the index to each of the six vdslLineMCMConfProfile Tables. The existence of an entry in any of the tables of the vdslMCMGroup is optional. 2.4. Persistence All read-create objects defined in this MIB module SHOULD be stored persistently. Following is an exhaustive list of these persistent objects: vdslMCMConfProfileTxWindowLength vdslMCMConfProfileRowStatus vdslMCMConfProfileTxBandNumber vdslMCMConfProfileTxBandStart vdslMCMConfProfileTxBandStop vdslMCMConfProfileTxBandRowStatus vdslMCMConfProfileRxBandStart vdslMCMConfProfileRxBandStop vdslMCMConfProfileRxBandRowStatus vdslMCMConfProfileTxPSDTone vdslMCMConfProfileTxPSDPSD vdslMCMConfProfileTxPSDRowStatus vdslMCMConfProfileMaxTxPSDTone vdslMCMConfProfileMaxTxPSDPSD vdslMCMConfProfileMaxTxPSDRowStatus vdslMCMConfProfileMaxRxPSDTone vdslMCMConfProfileMaxRxPSDPSD vdslMCMConfProfileMaxRxPSDRowStatus Dodge & Ray Standards Track [Page 4] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 Note also that the interface indices in this MIB are maintained persistently. View-based Access Control Model (VACM) data relating to these SHOULD be stored persistently as well [RFC3415]. 3. Conformance and Compliance An MCM based VDSL agent does not have to implement this MIB to be compliant with RFC 3728 [RFC3728]. If the MCM VDSL Line Extension MIB is implemented then the following group is mandatory: - vdslMCMGroup 4. Definitions VDSL-LINE-EXT-MCM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] RowStatus FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] vdslLineConfProfileName FROM VDSL-LINE-MIB; -- [RFC3728] vdslExtMCMMIB MODULE-IDENTITY LAST-UPDATED "200504280000Z" -- April 28, 2005 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair/Co-editor: Bob Ray PESA Switching Systems, Inc. Postal: 330-A Wynn Drive Huntsville, AL 35805 USA Email: rray@pesa.com Phone: +1 256 726 9200 ext. 142 Dodge & Ray Standards Track [Page 5] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 Co-editor: Menachem Dodge ECI Telecom Ltd. Postal: 30 hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 " DESCRIPTION "The VDSL-LINE-MIB found in RFC 3728 defines objects for the management of a pair of VDSL transceivers at each end of the VDSL line. The VDSL-LINE-MIB configures and monitors the line code independent parameters (TC layer) of the VDSL line. This MIB module is an optional extension of the VDSL-LINE-MIB and defines objects for configuration and monitoring of the line code specific (LCS) elements (PMD layer) for VDSL lines using MCM coding. The objects in this extension MIB MUST NOT be used for VDSL lines using Single Carrier Modulation (SCM) line coding. If an object in this extension MIB is referenced by a line which does not use MCM, it has no effect on the operation of that line. Naming Conventions: Vtuc -- (VTUC) transceiver at near (Central) end of line Vtur -- (VTUR) transceiver at Remote end of line Vtu -- One of either Vtuc or Vtur Curr -- Current LCS -- Line Code Specific Max -- Maximum PSD -- Power Spectral Density Rx -- Receive Tx -- Transmit Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4070: see the RFC itself for full legal notices." REVISION "200504280000Z" -- April 28, 2005 DESCRIPTION "Initial version, published as RFC 4070." ::= { transmission 229 } vdslLineExtMCMMib OBJECT IDENTIFIER ::= { vdslExtMCMMIB 1 } vdslLineExtMCMMibObjects OBJECT IDENTIFIER ::= {vdslLineExtMCMMib 1} -- -- Multiple carrier modulation (MCM) configuration profile tables -- Dodge & Ray Standards Track [Page 6] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 vdslLineMCMConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineMCMConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains additional information on multiple carrier VDSL lines. One entry in this table reflects a profile defined by a manager which can be used to configure the VDSL line. If an entry in this table is referenced by a line which does not use MCM, it has no effect on the operation of that line. All read-create-objects defined in this table SHOULD be stored persistently." ::= { vdslLineExtMCMMibObjects 1 } vdslLineMCMConfProfileEntry OBJECT-TYPE SYNTAX VdslLineMCMConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of a multiple carrier modulation VDSL modem." INDEX { vdslLineConfProfileName } ::= { vdslLineMCMConfProfileTable 1 } VdslLineMCMConfProfileEntry ::= SEQUENCE { vdslLineMCMConfProfileTxWindowLength Unsigned32, vdslLineMCMConfProfileRowStatus RowStatus } vdslLineMCMConfProfileTxWindowLength OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "samples" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the length of the transmit window, counted in samples at the sampling rate corresponding to the negotiated value of N." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileEntry 1 } Dodge & Ray Standards Track [Page 7] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 vdslLineMCMConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile is activated by setting this object to `active'. When `active' is set, the system will validate the profile. None of the columns in this row may be modified while the row is in the 'active' state. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `notInService') it must first be unreferenced from all associated lines." ::= { vdslLineMCMConfProfileEntry 2 } vdslLineMCMConfProfileTxBandTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineMCMConfProfileTxBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains transmit band descriptor configuration information for a VDSL line. Each entry in this table reflects the configuration for one of possibly many bands with a multiple carrier modulation (MCM) VDSL line. These entries are defined by a manager and can be used to configure the VDSL line. If an entry in this table is referenced by a line which does not use MCM, it has no effect on the operation of that line. All read-create-objects defined in this table SHOULD be stored persistently." ::= { vdslLineExtMCMMibObjects 2 } vdslLineMCMConfProfileTxBandEntry OBJECT-TYPE SYNTAX VdslLineMCMConfProfileTxBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a transmit band descriptor, which is defined by a start and a stop tone index." INDEX { vdslLineConfProfileName, Dodge & Ray Standards Track [Page 8] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 vdslLineMCMConfProfileTxBandNumber } ::= { vdslLineMCMConfProfileTxBandTable 1 } VdslLineMCMConfProfileTxBandEntry ::= SEQUENCE { vdslLineMCMConfProfileTxBandNumber Unsigned32, vdslLineMCMConfProfileTxBandStart Unsigned32, vdslLineMCMConfProfileTxBandStop Unsigned32, vdslLineMCMConfProfileTxBandRowStatus RowStatus } vdslLineMCMConfProfileTxBandNumber OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this band descriptor entry." ::= { vdslLineMCMConfProfileTxBandEntry 1 } vdslLineMCMConfProfileTxBandStart OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS read-create STATUS current DESCRIPTION "Start tone index for this band." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileTxBandEntry 2 } vdslLineMCMConfProfileTxBandStop OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS read-create STATUS current DESCRIPTION "Stop tone index for this band." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileTxBandEntry 3 } vdslLineMCMConfProfileTxBandRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile is activated by setting this object to `active'. When `active' is set, the system will validate the profile. Dodge & Ray Standards Track [Page 9] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 Each entry must be internally consistent, the Stop Tone must be greater than the Start Tone. Each entry must also be externally consistent, all entries indexed by a specific profile must not overlap. Validation of the profile will check both internal and external consistency. None of the columns in this row may be modified while the row is in the 'active' state. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `notInService') it must be first unreferenced from all associated lines." ::= { vdslLineMCMConfProfileTxBandEntry 4 } vdslLineMCMConfProfileRxBandTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineMCMConfProfileRxBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains receive band descriptor configuration information for a VDSL line. Each entry in this table reflects the configuration for one of possibly many bands with a multiple carrier modulation (MCM) VDSL line. These entries are defined by a manager and can be used to configure the VDSL line. If an entry in this table is referenced by a line which does not use MCM, it has no effect on the operation of that line. All read-create-objects defined in this table SHOULD be stored persistently." ::= { vdslLineExtMCMMibObjects 3 } vdslLineMCMConfProfileRxBandEntry OBJECT-TYPE SYNTAX VdslLineMCMConfProfileRxBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a transmit band descriptor, which is defined by a start and a stop tone index." INDEX { vdslLineConfProfileName, vdslLineMCMConfProfileRxBandNumber } ::= { vdslLineMCMConfProfileRxBandTable 1 } VdslLineMCMConfProfileRxBandEntry ::= Dodge & Ray Standards Track [Page 10] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 SEQUENCE { vdslLineMCMConfProfileRxBandNumber Unsigned32, vdslLineMCMConfProfileRxBandStart Unsigned32, vdslLineMCMConfProfileRxBandStop Unsigned32, vdslLineMCMConfProfileRxBandRowStatus RowStatus } vdslLineMCMConfProfileRxBandNumber OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this band descriptor entry." ::= { vdslLineMCMConfProfileRxBandEntry 1 } vdslLineMCMConfProfileRxBandStart OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS read-create STATUS current DESCRIPTION "Start tone index for this band." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileRxBandEntry 2 } vdslLineMCMConfProfileRxBandStop OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS read-create STATUS current DESCRIPTION "Stop tone index for this band." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileRxBandEntry 3 } vdslLineMCMConfProfileRxBandRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile is activated by setting this object to `active'. When `active' is set, the system will validate the profile. Each entry must be internally consistent, the Stop Tone must be greater than the Start Tone. Each entry must also be externally consistent, all entries indexed by a specific Dodge & Ray Standards Track [Page 11] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 profile must not overlap. Validation of the profile will check both internal and external consistency. None of the columns in this row may be modified while the row is in the 'active' state. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `notInService') it must be first unreferenced from all associated lines." ::= { vdslLineMCMConfProfileRxBandEntry 4 } vdslLineMCMConfProfileTxPSDTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineMCMConfProfileTxPSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains transmit PSD mask descriptor configuration information for a VDSL line. Each entry in this table reflects the configuration for one tone within a multiple carrier modulation (MCM) VDSL line. These entries are defined by a manager and can be used to configure the VDSL line. If an entry in this table is referenced by a line which does not use MCM, it has no effect on the operation of that line. All read-create-objects defined in this table SHOULD be stored persistently." ::= { vdslLineExtMCMMibObjects 4 } vdslLineMCMConfProfileTxPSDEntry OBJECT-TYPE SYNTAX VdslLineMCMConfProfileTxPSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a transmit PSD mask descriptor, which defines the power spectral density (PSD) for a tone." INDEX { vdslLineConfProfileName, vdslLineMCMConfProfileTxPSDNumber } ::= { vdslLineMCMConfProfileTxPSDTable 1 } VdslLineMCMConfProfileTxPSDEntry ::= SEQUENCE { vdslLineMCMConfProfileTxPSDNumber Unsigned32, Dodge & Ray Standards Track [Page 12] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 vdslLineMCMConfProfileTxPSDTone Unsigned32, vdslLineMCMConfProfileTxPSDPSD Unsigned32, vdslLineMCMConfProfileTxPSDRowStatus RowStatus } vdslLineMCMConfProfileTxPSDNumber OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this mask descriptor entry." ::= { vdslLineMCMConfProfileTxPSDEntry 1 } vdslLineMCMConfProfileTxPSDTone OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS read-create STATUS current DESCRIPTION "The tone index for which the PSD is being specified." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileTxPSDEntry 2 } vdslLineMCMConfProfileTxPSDPSD OBJECT-TYPE SYNTAX Unsigned32 UNITS "0.5dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "Power Spectral Density level in steps of 0.5dBm/Hz with an offset of -140dBm/Hz." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileTxPSDEntry 3 } vdslLineMCMConfProfileTxPSDRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile is activated by setting this object to `active'. When `active' is set, the system will validate the profile. None of the columns in this row may be modified while the row is in the 'active' state. Before a profile can be deleted or taken out of Dodge & Ray Standards Track [Page 13] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 service, (by setting this object to `destroy' or `notInService') it must be first unreferenced from all associated lines." ::= { vdslLineMCMConfProfileTxPSDEntry 4 } vdslLineMCMConfProfileMaxTxPSDTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineMCMConfProfileMaxTxPSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains transmit maximum PSD mask descriptor configuration information for a VDSL line. Each entry in this table reflects the configuration for one tone within a multiple carrier modulation (MCM) VDSL modem. These entries are defined by a manager and can be used to configure the VDSL line. If an entry in this table is referenced by a line which does not use MCM, it has no effect on the operation of that line. All read-create-objects defined in this table SHOULD be stored persistently." ::= { vdslLineExtMCMMibObjects 5 } vdslLineMCMConfProfileMaxTxPSDEntry OBJECT-TYPE SYNTAX VdslLineMCMConfProfileMaxTxPSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a transmit PSD mask descriptor, which defines the maximum power spectral density (PSD) for a tone." INDEX { vdslLineConfProfileName, vdslLineMCMConfProfileMaxTxPSDNumber } ::= { vdslLineMCMConfProfileMaxTxPSDTable 1 } VdslLineMCMConfProfileMaxTxPSDEntry ::= SEQUENCE { vdslLineMCMConfProfileMaxTxPSDNumber Unsigned32, vdslLineMCMConfProfileMaxTxPSDTone Unsigned32, vdslLineMCMConfProfileMaxTxPSDPSD Unsigned32, vdslLineMCMConfProfileMaxTxPSDRowStatus RowStatus } vdslLineMCMConfProfileMaxTxPSDNumber OBJECT-TYPE SYNTAX Unsigned32 (1..4096) Dodge & Ray Standards Track [Page 14] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this band descriptor entry." ::= { vdslLineMCMConfProfileMaxTxPSDEntry 1 } vdslLineMCMConfProfileMaxTxPSDTone OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS read-create STATUS current DESCRIPTION "The tone index for which the PSD is being specified. There must not be multiple rows defined, for a particular profile, with the same value for this field." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileMaxTxPSDEntry 2 } vdslLineMCMConfProfileMaxTxPSDPSD OBJECT-TYPE SYNTAX Unsigned32 UNITS "0.5dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "Power Spectral Density level in steps of 0.5dBm/Hz with an offset of -140dBm/Hz." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileMaxTxPSDEntry 3 } vdslLineMCMConfProfileMaxTxPSDRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile is activated by setting this object to `active'. When `active' is set, the system will validate the profile. There must be only one entry in this table for each tone associated with a specific profile. This will be checked during the validation process. None of the columns in this row may be modified while the row is in the 'active' state. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `notInService') it must be first unreferenced from all associated lines." Dodge & Ray Standards Track [Page 15] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 ::= { vdslLineMCMConfProfileMaxTxPSDEntry 4 } vdslLineMCMConfProfileMaxRxPSDTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineMCMConfProfileMaxRxPSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains maximum receive PSD mask descriptor configuration information for a VDSL line. Each entry in this table reflects the configuration for one tone within a multiple carrier modulation (MCM) VDSL modem. These entries are defined by a manager and can be used to configure the VDSL line. If an entry in this table is referenced by a line which does not use MCM, it has no effect on the operation of that line. All read-create-objects defined in this table SHOULD be stored persistently." ::= { vdslLineExtMCMMibObjects 6 } vdslLineMCMConfProfileMaxRxPSDEntry OBJECT-TYPE SYNTAX VdslLineMCMConfProfileMaxRxPSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a transmit PSD mask descriptor, which defines the power spectral density (PSD) for a tone." INDEX { vdslLineConfProfileName, vdslLineMCMConfProfileMaxRxPSDNumber } ::= { vdslLineMCMConfProfileMaxRxPSDTable 1 } VdslLineMCMConfProfileMaxRxPSDEntry ::= SEQUENCE { vdslLineMCMConfProfileMaxRxPSDNumber Unsigned32, vdslLineMCMConfProfileMaxRxPSDTone Unsigned32, vdslLineMCMConfProfileMaxRxPSDPSD Unsigned32, vdslLineMCMConfProfileMaxRxPSDRowStatus RowStatus } vdslLineMCMConfProfileMaxRxPSDNumber OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS not-accessible STATUS current Dodge & Ray Standards Track [Page 16] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 DESCRIPTION "The index for this band descriptor entry." ::= { vdslLineMCMConfProfileMaxRxPSDEntry 1 } vdslLineMCMConfProfileMaxRxPSDTone OBJECT-TYPE SYNTAX Unsigned32 (1..4096) MAX-ACCESS read-create STATUS current DESCRIPTION "The tone index for which the PSD is being specified. There must not be multiple rows defined, for a particular profile, with the same value for this field." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileMaxRxPSDEntry 2 } vdslLineMCMConfProfileMaxRxPSDPSD OBJECT-TYPE SYNTAX Unsigned32 UNITS "0.5dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "Power Spectral Density level in steps of 0.5dBm/Hz with an offset of -140dBm/Hz." REFERENCE "T1E1.4/2000-013R4" -- Part 3, MCM ::= { vdslLineMCMConfProfileMaxRxPSDEntry 3 } vdslLineMCMConfProfileMaxRxPSDRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile is activated by setting this object to `active'. When `active' is set, the system will validate the profile. There must be only one entry in this table for each tone associated with a specific profile. This will be checked during the validation process. None of the columns in this row may be modified while the row is in the 'active' state. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `notInService') it must be first unreferenced from all associated lines." ::= { vdslLineMCMConfProfileMaxRxPSDEntry 4 } Dodge & Ray Standards Track [Page 17] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 -- conformance information vdslLineExtMCMConformance OBJECT IDENTIFIER ::= { vdslLineExtMCMMib 2 } vdslLineExtMCMGroups OBJECT IDENTIFIER ::= { vdslLineExtMCMConformance 1 } vdslLineExtMCMCompliances OBJECT IDENTIFIER ::= { vdslLineExtMCMConformance 2 } vdslLineExtMCMMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which manage VDSL interfaces." MODULE -- this module MANDATORY-GROUPS { vdslLineExtMCMGroup } ::= { vdslLineExtMCMCompliances 1 } -- units of conformance vdslLineExtMCMGroup OBJECT-GROUP OBJECTS { vdslLineMCMConfProfileTxWindowLength, vdslLineMCMConfProfileRowStatus, vdslLineMCMConfProfileTxBandStart, vdslLineMCMConfProfileTxBandStop, vdslLineMCMConfProfileTxBandRowStatus, vdslLineMCMConfProfileRxBandStart, vdslLineMCMConfProfileRxBandStop, vdslLineMCMConfProfileRxBandRowStatus, vdslLineMCMConfProfileTxPSDTone, vdslLineMCMConfProfileTxPSDPSD, vdslLineMCMConfProfileTxPSDRowStatus, vdslLineMCMConfProfileMaxTxPSDTone, vdslLineMCMConfProfileMaxTxPSDPSD, vdslLineMCMConfProfileMaxTxPSDRowStatus, vdslLineMCMConfProfileMaxRxPSDTone, vdslLineMCMConfProfileMaxRxPSDPSD, vdslLineMCMConfProfileMaxRxPSDRowStatus } STATUS current DESCRIPTION "A collection of objects providing configuration Dodge & Ray Standards Track [Page 18] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 information for a VDSL line based upon multiple carrier modulation modem." ::= { vdslLineExtMCMGroups 1 } END 5. Acknowledgments This document contains many definitions taken from an early version of the VDSL MIB [RFC3728]. As such any credit for the text found within should be fully attributed to the authors of that document. 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: vdslLineMCMConfProfileTable, vdslLineMCMConfProfileTxWindowLength, vdslLineMCMConfProfileRowStatus, vdslLineMCMConfProfileTxBandTable, vdslLineMCMConfProfileTxBandStart, vdslLineMCMConfProfileTxBandStop, vdslLineMCMConfProfileTxBandRowStatus, vdslLineMCMConfProfileRxBandTable, vdslLineMCMConfProfileRxBandStart, vdslLineMCMConfProfileRxBandStop, vdslLineMCMConfProfileRxBandRowStatus, vdslLineMCMConfProfileTxPSDTable, vdslLineMCMConfProfileTxPSDTone, vdslLineMCMConfProfileTxPSDPSD, vdslLineMCMConfProfileTxPSDRowStatus, vdslLineMCMConfProfileMaxTxPSDTable vdslLineMCMConfProfileMaxTxPSDTone, vdslLineMCMConfProfileMaxTxPSDPSD, vdslLineMCMConfProfileMaxTxPSDRowStatus, vdslLineMCMConfProfileMaxRxPSDTable vdslLineMCMConfProfileMaxRxPSDTone, vdslLineMCMConfProfileMaxRxPSDPSD, vdslLineMCMConfProfileMaxRxPSDRowStatus Dodge & Ray Standards Track [Page 19] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 VDSL layer connectivity from the Vtur will permit the subscriber to manipulate both the VDSL link directly and the VDSL embedded operations channel (EOC) for their own loop. For example, unchecked or unfiltered fluctuations initiated by the subscriber could generate sufficient notifications to potentially overwhelm either the management interface to the network or the element manager. Additionally, allowing write access to configuration data may allow an end-user to increase their service levels or affect other end- users in either a positive or negative manner. For this reason, the tables and objects listed above should be considered to contain sensitive information. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: vdslLineMCMConfProfileTable, vdslLineMCMConfProfileTxWindowLength, vdslLineMCMConfProfileRowStatus, vdslLineMCMConfProfileTxBandTable, vdslLineMCMConfProfileTxBandStart, vdslLineMCMConfProfileTxBandStop, vdslLineMCMConfProfileTxBandRowStatus, vdslLineMCMConfProfileRxBandTable, vdslLineMCMConfProfileRxBandStart, vdslLineMCMConfProfileRxBandStop, vdslLineMCMConfProfileRxBandRowStatus, vdslLineMCMConfProfileTxPSDTable, vdslLineMCMConfProfileTxPSDTone, vdslLineMCMConfProfileTxPSDPSD, vdslLineMCMConfProfileTxPSDRowStatus, vdslLineMCMConfProfileMaxTxPSDTable vdslLineMCMConfProfileMaxTxPSDTone, vdslLineMCMConfProfileMaxTxPSDPSD, vdslLineMCMConfProfileMaxTxPSDRowStatus, vdslLineMCMConfProfileMaxRxPSDTable vdslLineMCMConfProfileMaxRxPSDTone, vdslLineMCMConfProfileMaxRxPSDPSD, vdslLineMCMConfProfileMaxRxPSDRowStatus Dodge & Ray Standards Track [Page 20] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 Read access of the physical band parameters may provide knowledge to an end-user that would allow malicious behavior, for example the application of an intentional interference on one or all of the physical bands in use. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of a MIB module which utilizes the textual conventions defined in this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations The IANA has assigned the transmission value 229 to VDSL-LINE-EXT- MCM-MIB. 8. References 8.1. Normative References [DSLFTR57] DSL Forum TR-057, "VDSL Network Element Management", February 2003. [ETSI2701] ETSI TS 101 270-1 V1.2.1, "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements", October 1999. [ETSI2702] ETSI TS 101 270-2 V1.1.1, "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Transceiver specification", February 2001. Dodge & Ray Standards Track [Page 21] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 [ITU9931] ITU-T G.993.1, "Very-high-speed digital subscriber line foundation", November 2001. [ITU9971] ITU-T G.997.1, "Physical layer management for Digital Subscriber Line (DSL) Transceivers", July 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3728] Ray, B. and R. Abbi, "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", RFC 3728, February 2004. [T1E1311] ANSI T1E1.4/2001-311, "Very-high-bit-rate Digital Subscriber Line (VDSL) Metallic Interface, Part 1: Functional Requirements and Common Specification", February 2001. [T1E1011] ANSI T1E1.4/2001-011R3, "VDSL Metallic Interface, Part 2: Technical Specification for a Single-Carrier Modulation (SCM) Transceiver", November 2001. [T1E1013] ANSI T1E1.4/2001-013R4, "VDSL Metallic Interface, Part 3: Technical Specification for a Multi-Carrier Modulation (MCM) Transceiver", November 2000. 8.2. Informative References [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Dodge & Ray Standards Track [Page 22] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Authors' Addresses Menachem Dodge ECI Telecom Ltd. 30 Hasivim St. Petach Tikva 49517, Israel Phone: +972 3 926 8421 Fax: +972 3 928 7342 EMail: mbdodge@ieee.org Bob Ray PESA Switching Systems, Inc. 330-A Wynn Drive Huntsville, AL 35805 USA Phone: +1 256 726 9200 ext. 142 Fax: +1 256 726 9271 EMail: rray@pesa.com Dodge & Ray Standards Track [Page 23] RFC 4070 VDSL-LINE-EXT-MCM-MIB May 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Dodge & Ray Standards Track [Page 24] snmp-mibs-downloader-1.1/mibrfcs/rfc4087.txt0000644000000000000000000014772611402176072015606 0ustar Network Working Group D. Thaler Request for Comments: 4087 Microsoft Obsoletes: 2667 June 2005 Category: Standards Track IP Tunnel MIB 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. 1. Introduction Over the past several years, there has been a number of "tunneling" protocols specified by the IETF (see [RFC1241] for an early discussion of the model and examples). This document describes a Management Information Base (MIB) module used for managing tunnels of any type over IPv4 and IPv6 networks, including Generic Routing Encapsulation (GRE) [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal Encapsulation [RFC2004], Layer 2 Tunneling Protocol (L2TP) [RFC2661], Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 Forwarding (L2F) [RFC2341], UDP (e.g., [RFC1234]), Ascend Tunnel Management Protocol (ATMP) [RFC2107], and IPv6-in-IPv4 [RFC2893] tunnels, among others. Thaler Standards Track [Page 1] RFC 4087 IP Tunnel MIB June 2005 Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects (e.g., IPsec [RFC2401]), and traffic conditioner [RFC2474] objects. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview This MIB module contains two current tables and one deprecated table. The current tables are: o the Tunnel Interface Table, containing information on the tunnels known to a router; and o the Tunnel Inet Config Table, which can be used for dynamic creation of tunnels, and also provides a mapping from endpoint addresses to the current interface index value. The version of this MIB module that appeared in RFC 2667 contained the Tunnel Config Table, which mapped IPv4 endpoint addresses to interface indexes. It is now deprecated in favor of the Tunnel Inet Config Table. 3.1. Relationship to the Interfaces MIB This section clarifies the relationship of this MIB module to the Interfaces MIB [RFC2863]. Several areas of correlation are addressed in the following subsections. The implementor is referred to the Interfaces MIB document in order to understand the general intent of these areas. Thaler Standards Track [Page 2] RFC 4087 IP Tunnel MIB June 2005 3.1.1. Layering Model Each logical interface (physical or virtual) has an ifEntry in the Interfaces MIB [RFC2863]. Tunnels are handled by creating a logical interface (ifEntry) for each tunnel. These are then correlated, using the ifStack table of the Interfaces MIB, to those interfaces on which the local IPv4 or IPv6 addresses of the tunnels are configured. The basic model, therefore, looks something like this (for example): | | | | | | +--+ +---+ +--+ +---+ | | |IP-in-IP| | GRE | | | | tunnel | | tunnel | | | +--+ +---+ +--+ +---+ | | | | | | | | <== attachment to underlying +--+ +---------+ +----------+ +--+ interfaces, to be provided | Physical interface | by ifStack table +--------------------------------+ 3.1.2. ifRcvAddressTable The ifRcvAddressTable usage can be defined in the MIB modules defining the encapsulation below the network layer, and holds the local IP addresses on which decapsulation will occur. For example, if IP-in-IP encapsulation is being used, the ifRcvAddressTable can be defined by IP-in-IP. If it is not specified, the default is that one entry will exist for the tunnel interface, where ifRcvAddressAddress contains the local IP address used for encapsulation/decapsulation (i.e., tunnelIfLocalInetAddress in the Tunnel Interface Table). 3.1.3. ifEntry IfEntries are defined in the MIB modules defining the encapsulation below the network layer. For example, if IP-in-IP encapsulation [20] is being used, the ifEntry is defined by IP-in-IP. The ifType of a tunnel should be set to "tunnel" (131). An entry in the IP Tunnel MIB module will exist for every ifEntry with this ifType. An implementation of the IP Tunnel MIB module may allow ifEntries to be created via the tunnelConfigTable. Creating a tunnel will also add an entry in the ifTable and in the tunnelIfTable, and deleting a tunnel will likewise delete the entry in the ifTable and the tunnelIfTable. The use of two different tables in this MIB module was an important design decision. Traditionally, ifIndex values are chosen by agents, and are permitted to change across restarts. Allowing row creation directly in the Tunnel Interface Table, indexed by ifIndex, would Thaler Standards Track [Page 3] RFC 4087 IP Tunnel MIB June 2005 complicate row creation and/or cause interoperability problems (if each agent had special restrictions on ifIndex). Instead, a separate table is used that is indexed only by objects over which the manager has control. Namely, these are the addresses of the tunnel endpoints and the encapsulation protocol. Finally, an additional manager- chosen ID is used in the index to support protocols such as L2F which allow multiple tunnels between the same endpoints. 4. Definitions TUNNEL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578] RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595] ifIndex, InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE] tunnelMIB MODULE-IDENTITY LAST-UPDATED "200505160000Z" -- May 16, 2005 ORGANIZATION "IETF IP Version 6 (IPv6) Working Group" CONTACT-INFO " Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: dthaler@microsoft.com" DESCRIPTION "The MIB module for management of IP Tunnels, independent of the specific encapsulation scheme in use. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4087; see the RFC itself for full legal notices." Thaler Standards Track [Page 4] RFC 4087 IP Tunnel MIB June 2005 REVISION "200505160000Z" -- May 16, 2005 DESCRIPTION "IPv4-specific objects were deprecated, including tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelConfigTable, and the tunnelMIBBasicGroup. Added IP version-agnostic objects that should be used instead, including tunnelIfAddressType, tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the tunnelIMIBInetGroup. The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects are read-write, rather than read-only. Updated DESCRIPTION clauses of existing version- agnostic objects (e.g., tunnelIfTOS) that contained IPv4-specific text to cover IPv6 as well. Added tunnelIfFlowLabel for tunnels over IPv6. The encapsulation method was previously an INTEGER type, and is now an IANA-maintained textual convention. Published as RFC 4087." REVISION "199908241200Z" -- August 24, 1999 DESCRIPTION "Initial version, published as RFC 2667." ::= { transmission 131 } tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 } tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 } -- the IP Tunnel MIB-Group -- -- a collection of objects providing information about -- IP Tunnels tunnelIfTable OBJECT-TYPE SYNTAX SEQUENCE OF TunnelIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on configured tunnels." Thaler Standards Track [Page 5] RFC 4087 IP Tunnel MIB June 2005 ::= { tunnel 1 } tunnelIfEntry OBJECT-TYPE SYNTAX TunnelIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular configured tunnel." INDEX { ifIndex } ::= { tunnelIfTable 1 } TunnelIfEntry ::= SEQUENCE { tunnelIfLocalAddress IpAddress, -- deprecated tunnelIfRemoteAddress IpAddress, -- deprecated tunnelIfEncapsMethod IANAtunnelType, tunnelIfHopLimit Integer32, tunnelIfSecurity INTEGER, tunnelIfTOS Integer32, tunnelIfFlowLabel IPv6FlowLabelOrAny, tunnelIfAddressType InetAddressType, tunnelIfLocalInetAddress InetAddress, tunnelIfRemoteInetAddress InetAddress, tunnelIfEncapsLimit Integer32 } tunnelIfLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The address of the local endpoint of the tunnel (i.e., the source address used in the outer IP header), or 0.0.0.0 if unknown or if the tunnel is over IPv6. Since this object does not support IPv6, it is deprecated in favor of tunnelIfLocalInetAddress." ::= { tunnelIfEntry 1 } tunnelIfRemoteAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The address of the remote endpoint of the tunnel (i.e., the destination address used in the outer IP header), or 0.0.0.0 if unknown, or an IPv6 address, or Thaler Standards Track [Page 6] RFC 4087 IP Tunnel MIB June 2005 the tunnel is not a point-to-point link (e.g., if it is a 6to4 tunnel). Since this object does not support IPv6, it is deprecated in favor of tunnelIfRemoteInetAddress." ::= { tunnelIfEntry 2 } tunnelIfEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelType MAX-ACCESS read-only STATUS current DESCRIPTION "The encapsulation method used by the tunnel." ::= { tunnelIfEntry 3 } tunnelIfHopLimit OBJECT-TYPE SYNTAX Integer32 (0 | 1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The IPv4 TTL or IPv6 Hop Limit to use in the outer IP header. A value of 0 indicates that the value is copied from the payload's header." ::= { tunnelIfEntry 4 } tunnelIfSecurity OBJECT-TYPE SYNTAX INTEGER { none(1), -- no security ipsec(2), -- IPsec security other(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The method used by the tunnel to secure the outer IP header. The value ipsec indicates that IPsec is used between the tunnel endpoints for authentication or encryption or both. More specific security-related information may be available in a MIB module for the security protocol in use." ::= { tunnelIfEntry 5 } tunnelIfTOS OBJECT-TYPE SYNTAX Integer32 (-2..63) MAX-ACCESS read-write STATUS current DESCRIPTION "The method used to set the high 6 bits (the Thaler Standards Track [Page 7] RFC 4087 IP Tunnel MIB June 2005 differentiated services codepoint) of the IPv4 TOS or IPv6 Traffic Class in the outer IP header. A value of -1 indicates that the bits are copied from the payload's header. A value of -2 indicates that a traffic conditioner is invoked and more information may be available in a traffic conditioner MIB module. A value between 0 and 63 inclusive indicates that the bit field is set to the indicated value. Note: instead of the name tunnelIfTOS, a better name would have been tunnelIfDSCPMethod, but the existing name appeared in RFC 2667 and existing objects cannot be renamed." ::= { tunnelIfEntry 6 } tunnelIfFlowLabel OBJECT-TYPE SYNTAX IPv6FlowLabelOrAny MAX-ACCESS read-write STATUS current DESCRIPTION "The method used to set the IPv6 Flow Label value. This object need not be present in rows where tunnelIfAddressType indicates the tunnel is not over IPv6. A value of -1 indicates that a traffic conditioner is invoked and more information may be available in a traffic conditioner MIB. Any other value indicates that the Flow Label field is set to the indicated value." ::= { tunnelIfEntry 7 } tunnelIfAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of address in the corresponding tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects." ::= { tunnelIfEntry 8 } tunnelIfLocalInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The address of the local endpoint of the tunnel (i.e., the source address used in the outer IP header). If the address is unknown, the value is Thaler Standards Track [Page 8] RFC 4087 IP Tunnel MIB June 2005 0.0.0.0 for IPv4 or :: for IPv6. The type of this object is given by tunnelIfAddressType." ::= { tunnelIfEntry 9 } tunnelIfRemoteInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The address of the remote endpoint of the tunnel (i.e., the destination address used in the outer IP header). If the address is unknown or the tunnel is not a point-to-point link (e.g., if it is a 6to4 tunnel), the value is 0.0.0.0 for tunnels over IPv4 or :: for tunnels over IPv6. The type of this object is given by tunnelIfAddressType." ::= { tunnelIfEntry 10 } tunnelIfEncapsLimit OBJECT-TYPE SYNTAX Integer32 (-1 | 0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of additional encapsulations permitted for packets undergoing encapsulation at this node. A value of -1 indicates that no limit is present (except as a result of the packet size)." REFERENCE "RFC 2473, section 4.1.1" ::= { tunnelIfEntry 11 } tunnelConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF TunnelConfigEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table containing information on configured tunnels. This table can be used to map a set of tunnel endpoints to the associated ifIndex value. It can also be used for row creation. Note that every row in the tunnelIfTable with a fixed IPv4 destination address should have a corresponding row in the tunnelConfigTable, regardless of whether it was created via SNMP. Since this table does not support IPv6, it is deprecated in favor of tunnelInetConfigTable." ::= { tunnel 2 } Thaler Standards Track [Page 9] RFC 4087 IP Tunnel MIB June 2005 tunnelConfigEntry OBJECT-TYPE SYNTAX TunnelConfigEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) containing the information on a particular configured tunnel. Since this entry does not support IPv6, it is deprecated in favor of tunnelInetConfigEntry." INDEX { tunnelConfigLocalAddress, tunnelConfigRemoteAddress, tunnelConfigEncapsMethod, tunnelConfigID } ::= { tunnelConfigTable 1 } TunnelConfigEntry ::= SEQUENCE { tunnelConfigLocalAddress IpAddress, tunnelConfigRemoteAddress IpAddress, tunnelConfigEncapsMethod IANAtunnelType, tunnelConfigID Integer32, tunnelConfigIfIndex InterfaceIndexOrZero, tunnelConfigStatus RowStatus } tunnelConfigLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The address of the local endpoint of the tunnel, or 0.0.0.0 if the device is free to choose any of its addresses at tunnel establishment time. Since this object does not support IPv6, it is deprecated in favor of tunnelInetConfigLocalAddress." ::= { tunnelConfigEntry 1 } tunnelConfigRemoteAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The address of the remote endpoint of the tunnel. Since this object does not support IPv6, it is deprecated in favor of tunnelInetConfigRemoteAddress." ::= { tunnelConfigEntry 2 } Thaler Standards Track [Page 10] RFC 4087 IP Tunnel MIB June 2005 tunnelConfigEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelType MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The encapsulation method used by the tunnel. Since this object does not support IPv6, it is deprecated in favor of tunnelInetConfigEncapsMethod." ::= { tunnelConfigEntry 3 } tunnelConfigID OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An identifier used to distinguish between multiple tunnels of the same encapsulation method, with the same endpoints. If the encapsulation protocol only allows one tunnel per set of endpoint addresses (such as for GRE or IP-in-IP), the value of this object is 1. For encapsulation methods (such as L2F) which allow multiple parallel tunnels, the manager is responsible for choosing any ID which does not conflict with an existing row, such as choosing a random number. Since this object does not support IPv6, it is deprecated in favor of tunnelInetConfigID." ::= { tunnelConfigEntry 4 } tunnelConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS deprecated DESCRIPTION "If the value of tunnelConfigStatus for this row is active, then this object contains the value of ifIndex corresponding to the tunnel interface. A value of 0 is not legal in the active state, and means that the interface index has not yet been assigned. Since this object does not support IPv6, it is deprecated in favor of tunnelInetConfigIfIndex." ::= { tunnelConfigEntry 5 } tunnelConfigStatus OBJECT-TYPE SYNTAX RowStatus Thaler Standards Track [Page 11] RFC 4087 IP Tunnel MIB June 2005 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. The agent need not support setting this object to createAndWait or notInService since there are no other writable objects in this table, and writable objects in rows of corresponding tables such as the tunnelIfTable may be modified while this row is active. To create a row in this table for an encapsulation method which does not support multiple parallel tunnels with the same endpoints, the management station should simply use a tunnelConfigID of 1, and set tunnelConfigStatus to createAndGo. For encapsulation methods such as L2F which allow multiple parallel tunnels, the management station may select a pseudo-random number to use as the tunnelConfigID and set tunnelConfigStatus to createAndGo. In the event that this ID is already in use and an inconsistentValue is returned in response to the set operation, the management station should simply select a new pseudo-random number and retry the operation. Creating a row in this table will cause an interface index to be assigned by the agent in an implementation-dependent manner, and corresponding rows will be instantiated in the ifTable and the tunnelIfTable. The status of this row will become active as soon as the agent assigns the interface index, regardless of whether the interface is operationally up. Deleting a row in this table will likewise delete the corresponding row in the ifTable and in the tunnelIfTable. Since this object does not support IPv6, it is deprecated in favor of tunnelInetConfigStatus." ::= { tunnelConfigEntry 6 } tunnelInetConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF TunnelInetConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Thaler Standards Track [Page 12] RFC 4087 IP Tunnel MIB June 2005 "The (conceptual) table containing information on configured tunnels. This table can be used to map a set of tunnel endpoints to the associated ifIndex value. It can also be used for row creation. Note that every row in the tunnelIfTable with a fixed destination address should have a corresponding row in the tunnelInetConfigTable, regardless of whether it was created via SNMP." ::= { tunnel 3 } tunnelInetConfigEntry OBJECT-TYPE SYNTAX TunnelInetConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular configured tunnel. Note that there is a 128 subid maximum for object OIDs. Implementers need to be aware that if the total number of octets in tunnelInetConfigLocalAddress and tunnelInetConfigRemoteAddress exceeds 110 then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. In practice this is not expected to be a problem since IPv4 and IPv6 addresses will not cause the limit to be reached, but if other types are supported by an agent, care must be taken to ensure that the sum of the lengths do not cause the limit to be exceeded." INDEX { tunnelInetConfigAddressType, tunnelInetConfigLocalAddress, tunnelInetConfigRemoteAddress, tunnelInetConfigEncapsMethod, tunnelInetConfigID } ::= { tunnelInetConfigTable 1 } TunnelInetConfigEntry ::= SEQUENCE { tunnelInetConfigAddressType InetAddressType, tunnelInetConfigLocalAddress InetAddress, tunnelInetConfigRemoteAddress InetAddress, tunnelInetConfigEncapsMethod IANAtunnelType, tunnelInetConfigID Integer32, tunnelInetConfigIfIndex InterfaceIndexOrZero, tunnelInetConfigStatus RowStatus, tunnelInetConfigStorageType StorageType } tunnelInetConfigAddressType OBJECT-TYPE Thaler Standards Track [Page 13] RFC 4087 IP Tunnel MIB June 2005 SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type over which the tunnel encapsulates packets." ::= { tunnelInetConfigEntry 1 } tunnelInetConfigLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the local endpoint of the tunnel, or 0.0.0.0 (for IPv4) or :: (for IPv6) if the device is free to choose any of its addresses at tunnel establishment time." ::= { tunnelInetConfigEntry 2 } tunnelInetConfigRemoteAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the remote endpoint of the tunnel." ::= { tunnelInetConfigEntry 3 } tunnelInetConfigEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The encapsulation method used by the tunnel." ::= { tunnelInetConfigEntry 4 } tunnelInetConfigID OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier used to distinguish between multiple tunnels of the same encapsulation method, with the same endpoints. If the encapsulation protocol only allows one tunnel per set of endpoint addresses (such as for GRE or IP-in-IP), the value of this object is 1. For encapsulation methods (such as L2F) which allow multiple parallel tunnels, the manager is responsible for choosing any ID which does not Thaler Standards Track [Page 14] RFC 4087 IP Tunnel MIB June 2005 conflict with an existing row, such as choosing a random number." ::= { tunnelInetConfigEntry 5 } tunnelInetConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of tunnelInetConfigStatus for this row is active, then this object contains the value of ifIndex corresponding to the tunnel interface. A value of 0 is not legal in the active state, and means that the interface index has not yet been assigned." ::= { tunnelInetConfigEntry 6 } tunnelInetConfigStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. The agent need not support setting this object to createAndWait or notInService since there are no other writable objects in this table, and writable objects in rows of corresponding tables such as the tunnelIfTable may be modified while this row is active. To create a row in this table for an encapsulation method which does not support multiple parallel tunnels with the same endpoints, the management station should simply use a tunnelInetConfigID of 1, and set tunnelInetConfigStatus to createAndGo. For encapsulation methods such as L2F which allow multiple parallel tunnels, the management station may select a pseudo-random number to use as the tunnelInetConfigID and set tunnelInetConfigStatus to createAndGo. In the event that this ID is already in use and an inconsistentValue is returned in response to the set operation, the management station should simply select a new pseudo-random number and retry the operation. Creating a row in this table will cause an interface index to be assigned by the agent in an implementation-dependent manner, and corresponding rows will be instantiated in the ifTable and the Thaler Standards Track [Page 15] RFC 4087 IP Tunnel MIB June 2005 tunnelIfTable. The status of this row will become active as soon as the agent assigns the interface index, regardless of whether the interface is operationally up. Deleting a row in this table will likewise delete the corresponding row in the ifTable and in the tunnelIfTable." ::= { tunnelInetConfigEntry 7 } tunnelInetConfigStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this row. If the row is permanent(4), no objects in the row need be writable." ::= { tunnelInetConfigEntry 8 } -- conformance information tunnelMIBConformance OBJECT IDENTIFIER ::= { tunnelMIB 2 } tunnelMIBCompliances OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 } tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 } -- compliance statements tunnelMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The (deprecated) IPv4-only compliance statement for the IP Tunnel MIB. This is deprecated in favor of tunnelMIBInetFullCompliance and tunnelMIBInetReadOnlyCompliance." MODULE -- this module MANDATORY-GROUPS { tunnelMIBBasicGroup } OBJECT tunnelIfHopLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tunnelIfTOS MIN-ACCESS read-only Thaler Standards Track [Page 16] RFC 4087 IP Tunnel MIB June 2005 DESCRIPTION "Write access is not required." OBJECT tunnelConfigStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { tunnelMIBCompliances 1 } tunnelMIBInetFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The full compliance statement for the IP Tunnel MIB." MODULE -- this module MANDATORY-GROUPS { tunnelMIBInetGroup } OBJECT tunnelIfAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation only needs to support the addresses it actually supports on the device." ::= { tunnelMIBCompliances 2 } tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The read-only compliance statement for the IP Tunnel MIB." MODULE -- this module MANDATORY-GROUPS { tunnelMIBInetGroup } OBJECT tunnelIfHopLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tunnelIfTOS MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tunnelIfFlowLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." Thaler Standards Track [Page 17] RFC 4087 IP Tunnel MIB June 2005 OBJECT tunnelIfAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 and/or IPv6 addresses. An implementation only needs to support the addresses it actually supports on the device." OBJECT tunnelIfLocalInetAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tunnelIfRemoteInetAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tunnelIfEncapsLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT tunnelInetConfigStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT tunnelInetConfigStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { tunnelMIBCompliances 3 } -- units of conformance tunnelMIBBasicGroup OBJECT-GROUP OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress, tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS, tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus } STATUS deprecated DESCRIPTION "A collection of objects to support basic management Thaler Standards Track [Page 18] RFC 4087 IP Tunnel MIB June 2005 of IPv4 Tunnels. Since this group cannot support IPv6, it is deprecated in favor of tunnelMIBInetGroup." ::= { tunnelMIBGroups 1 } tunnelMIBInetGroup OBJECT-GROUP OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelIfEncapsMethod, tunnelIfEncapsLimit, tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel, tunnelIfSecurity, tunnelInetConfigIfIndex, tunnelInetConfigStatus, tunnelInetConfigStorageType } STATUS current DESCRIPTION "A collection of objects to support basic management of IPv4 and IPv6 Tunnels." ::= { tunnelMIBGroups 2 } END 5. IANA Considerations This document introduces a new IANA-maintained textual convention (TC) which has been added to the IANAifType-MIB [IFTYPE]. The initial version of this IANAtunnelType TC can be found in Appendix A. The current version of the textual convention can be accessed at http://www.iana.org/assignments/ianaiftype-mib The assignment policy for IANAtunnelType values should always be identical to the policy for assigning IANAifType values. New types of tunnels over IPv4 or IPv6 should not be assigned IANAifType values. Instead, they should be assigned IANAtunnelType values and hence reuse the interface type tunnel(131). (Note this restriction does not apply to "tunnels" which are not over IPv4 or IPv6.) Previously, tunnel types that were not point-to-point tunnels were problematic in that they could not be properly expressed in the tunnel MIB, and hence were assigned IANAifType values. This document now corrects this problem, and as a result, IANA has deprecated the sixToFour(215) IANAifType value in favor of the sixToFour(11) IANAtunnelType value. Thaler Standards Track [Page 19] RFC 4087 IP Tunnel MIB June 2005 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Unauthorized write access to any of the writable objects could cause unauthorized creation and/or manipulation of tunnels, resulting in a denial of service, or redirection of packets to an arbitrary destination. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Unauthorized read access to tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelIfLocalAddress, tunnelIfRemoteAddress, or any object in the tunnelConfigTable or tunnelInetConfigTable would reveal information about the tunnel topology. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Thaler Standards Track [Page 20] RFC 4087 IP Tunnel MIB June 2005 7. Changes Since RFC 2667 IPv4-specific objects were deprecated, including tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelConfigTable, and the tunnelMIBBasicGroup. Added IP version-agnostic objects that should be used instead, including tunnelIfAddressType, tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the tunnelIMIBInetGroup. The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects are read-write, rather than read-only. Updated DESCRIPTION clauses of existing version-agnostic objects (e.g., tunnelIfTOS) that contained IPv4-specific text to cover IPv6 as well. Added tunnelIfFlowLabel for tunnels over IPv6. The encapsulation method was previously an INTEGER type, and is now an IANA-maintained textual convention. 8. Acknowledgements This MIB module was updated based on feedback from the IETF's Interfaces MIB (IF-MIB), Point-to-Point Protocol Extensions (PPPEXT), and IPv6 Working Groups. Mike Heard and Ville Nuorvala also provided valuable MIB guidance on this version. Thaler Standards Track [Page 21] RFC 4087 IP Tunnel MIB June 2005 Appendix A: IANA Tunnel Type TC This appendix defines the initial content of the IANAtunnelType textual convention. The most up-to-date and current version is maintained in the IANAifType-MIB. IANAtunnelType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The encapsulation method used by a tunnel. The value direct indicates that a packet is encapsulated directly within a normal IP header, with no intermediate header, and unicast to the remote tunnel endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC 1933 IPv6-in-IPv4 tunnel). The value minimal indicates that a Minimal Forwarding Header (RFC 2004) is inserted between the outer header and the payload packet. The value UDP indicates that the payload packet is encapsulated within a normal UDP packet (e.g., RFC 1234). The values sixToFour, sixOverFour, and isatap indicates that an IPv6 packet is encapsulated directly within an IPv4 header, with no intermediate header, and unicast to the destination determined by the 6to4, 6over4, or ISATAP protocol. The remaining protocol-specific values indicate that a header of the protocol of that name is inserted between the outer header and the payload header. The assignment policy for IANAtunnelType values is identical to the policy for assigning IANAifType values." SYNTAX INTEGER { other(1), -- none of the following direct(2), -- no intermediate header gre(3), -- GRE encapsulation minimal(4), -- Minimal encapsulation l2tp(5), -- L2TP encapsulation pptp(6), -- PPTP encapsulation l2f(7), -- L2F encapsulation udp(8), -- UDP encapsulation atmp(9), -- ATMP encapsulation msdp(10), -- MSDP encapsulation sixToFour(11), -- 6to4 encapsulation sixOverFour(12), -- 6over4 encapsulation isatap(13), -- ISATAP encapsulation Thaler Standards Track [Page 22] RFC 4087 IP Tunnel MIB June 2005 teredo(14) -- Teredo encapsulation } Normative References [IFTYPE] Internet Assigned Numbers Authority, "IANAifType-MIB", http://www.iana.org/assignments/ianaiftype-mib. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC 3595, September 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. Informative References [RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks", RFC 1234, June 1991. [RFC1241] Woodburn, R. and D. Mills, "A Scheme for an Internet Encapsulation Protocol: Version 1", RFC 1241, July 1991. [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. Thaler Standards Track [Page 23] RFC 4087 IP Tunnel MIB June 2005 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997. [RFC2341] Valencia, A., Littlewood, M., and T. Kolar. "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black. "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2637] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2893] Gilligan, R. and E. Nordmark. "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Author's Address Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com Thaler Standards Track [Page 24] RFC 4087 IP Tunnel MIB June 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Thaler Standards Track [Page 25] snmp-mibs-downloader-1.1/mibrfcs/rfc4113.txt0000644000000000000000000011660311402176072015562 0ustar Network Working Group B. Fenner Request for Comments: 4113 AT&T Labs - Research Obsoletes: 2454, 2013 J. Flick Category: Standards Track Hewlett-Packard Company June 2005 Management Information Base for the User Datagram Protocol (UDP) 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Relationship to Other MIBs . . . . . . . . . . . . . . . 3 2.1.1. Relationship to RFC1213-MIB . . . . . . . . . . 3 2.1.2. Relationship to the IPV6-UDP-MIB . . . . . . . . 3 2.1.3. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB. . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18 Fenner & Flick Standards [Page 1] RFC 4113 UDP MIB June 2005 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP), as defined in RFC 768 [RFC0768], in an IP version independent manner. The current UDP-MIB defined in this memo consists of one table and a group of scalars: o The udp group of scalars reports parameters and statistics of a UDP protocol engine. Two scalars, udpHCInDatagrams and udpHCOutDatagrams, have been added to this group since the publication of RFC 2013 [RFC2013] in order to provide high- capacity counters for fast networks. Discontinuities in the values of the counters in this group are indicated by discontinuities in the value of the sysUpTime object, which is defined in RFC 3418 [RFC3418]. o The udpEndpointTable provides access to status information for all UDP endpoints handled by a UDP protocol engine. The table provides for strictly listening endpoints, as with the historical udpTable, and also for "connected" UDP endpoints, which only accept packets from a given remote system. It also reports identification of the operating system level processes that handle UDP connections. Addresses and ports of UDP endpoints in this table are represented using the InetAddressType, InetAddress, and InetPortNumber textual conventions defined in RFC 4001 [RFC4001]. Fenner & Flick Standards [Page 2] RFC 4113 UDP MIB June 2005 2.1. Relationship to Other MIBs This section discusses the relationship of this UDP-MIB module to other MIB modules. 2.1.1. Relationship to RFC1213-MIB UDP related MIB objects were originally defined as part of the RFC1213-MIB, defined in RFC 1213 [RFC1213]. The UDP related objects of the RFC1213-MIB were later copied into a separate MIB module and published in RFC 2013 [RFC2013] in SMIv2 format. The previous versions of the UDP-MIB both defined the udpTable, which has been deprecated for basically two reasons: (1) The udpTable only supports IPv4. The current approach in the IETF is to write IP version neutral MIBs rather than have different definitions for various version of IP. This reduces the amount of overhead when new objects are introduced, since there is only one place to add them. Hence, the approach taken in RFC 2454 [RFC2454] of having separate tables is not continued. (2) The udpTable does not permit describing "connected" UDP endpoints. It turns out that "connected" endpoints tend to have a different behaviour and management access pattern from those of listening endpoints. Adding remote endpoint information to the udpEndpointTable thus allows for the addition of specific status and statistic objects for "connected" endpoints and connections. 2.1.2. Relationship to the IPV6-UDP-MIB The IPV6-UDP-MIB, defined in RFC 2454 [RFC2454], has been moved to Historic because the approach of having separate IP version specific tables is not followed anymore. Implementation of RFC 2454 is thus not suggested anymore. Note that because scoped addresses are now represented using the IPv4z and IPv6z address types, there is no longer a need to explicitly include the ifIndex in the index clause of the udpEndpointTable. This is a change from the use of ipv6UdpIfIndex in RFC 2454. Fenner & Flick Standards [Page 3] RFC 4113 UDP MIB June 2005 2.1.3. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB The udpEndpointTable reports the identification of the operating system level process that handles a connection or a listening endpoint. The value is reported as an Unsigned32, which is expected to be the same as the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] (if the value is smaller than 2147483647) or the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287]. This allows management applications to identify the UDP connections that belong to an operating system level process, which has proven valuable in operational environments. 3. Definitions UDP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Counter64, Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddress, InetAddressType, InetPortNumber FROM INET-ADDRESS-MIB; udpMIB MODULE-IDENTITY LAST-UPDATED "200505200000Z" -- May 20, 2005 ORGANIZATION "IETF IPv6 Working Group http://www.ietf.org/html.charters/ipv6-charter.html" CONTACT-INFO "Bill Fenner (editor) AT&T Labs -- Research 75 Willow Rd. Menlo Park, CA 94025 Phone: +1 650 330-7893 Email: John Flick (editor) Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747 Phone: +1 916 785 4018 Email: Send comments to " Fenner & Flick Standards [Page 4] RFC 4113 UDP MIB June 2005 DESCRIPTION "The MIB module for managing UDP implementations. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4113; see the RFC itself for full legal notices." REVISION "200505200000Z" -- May 20, 2005 DESCRIPTION "IP version neutral revision, incorporating the following revisions: - Added udpHCInDatagrams and udpHCOutDatagrams in order to provide high-capacity counters for fast networks. - Added text to the descriptions of all counter objects to indicate how discontinuities are detected. - Deprecated the IPv4-specific udpTable and replaced it with the version neutral udpEndpointTable. This table includes support for connected UDP endpoints and support for identification of the operating system process associated with a UDP endpoint. - Deprecated the udpGroup and replaced it with object groups representing the current set of objects. - Deprecated udpMIBCompliance and replaced it with udpMIBCompliance2, which includes the compliance information for the new object groups. This version published as RFC 4113." REVISION "199411010000Z" -- November 1, 1994 DESCRIPTION "Initial SMIv2 version, published as RFC 2013." REVISION "199103310000Z" -- March 31, 1991 DESCRIPTION "The initial revision of this MIB module was part of MIB-II, published as RFC 1213." ::= { mib-2 50 } -- the UDP group udp OBJECT IDENTIFIER ::= { mib-2 7 } udpInDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of UDP datagrams delivered to UDP users. Fenner & Flick Standards [Page 5] RFC 4113 UDP MIB June 2005 Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 1 } udpNoPorts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of received UDP datagrams for which there was no application at the destination port. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 2 } udpInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 3 } udpOutDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of UDP datagrams sent from this entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 4 } Fenner & Flick Standards [Page 6] RFC 4113 UDP MIB June 2005 udpHCInDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of UDP datagrams delivered to UDP users, for devices that can receive more than 1 million UDP datagrams per second. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 8 } udpHCOutDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of UDP datagrams sent from this entity, for devices that can transmit more than 1 million UDP datagrams per second. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 9 } -- -- { udp 6 } was defined as the ipv6UdpTable in RFC2454's -- IPV6-UDP-MIB. This RFC obsoletes RFC 2454, so { udp 6 } is -- obsoleted. -- -- The UDP "Endpoint" table. udpEndpointTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about this entity's UDP endpoints on which a local application is currently accepting or sending datagrams. Fenner & Flick Standards [Page 7] RFC 4113 UDP MIB June 2005 The address type in this table represents the address type used for the communication, irrespective of the higher-layer abstraction. For example, an application using IPv6 'sockets' to communicate via IPv4 between ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use InetAddressType ipv4(1). Unlike the udpTable in RFC 2013, this table also allows the representation of an application that completely specifies both local and remote addresses and ports. A listening application is represented in three possible ways: 1) An application that is willing to accept both IPv4 and IPv6 datagrams is represented by a udpEndpointLocalAddressType of unknown(0) and a udpEndpointLocalAddress of ''h (a zero-length octet-string). 2) An application that is willing to accept only IPv4 or only IPv6 datagrams is represented by a udpEndpointLocalAddressType of the appropriate address type and a udpEndpointLocalAddress of '0.0.0.0' or '::' respectively. 3) An application that is listening for datagrams only for a specific IP address but from any remote system is represented by a udpEndpointLocalAddressType of the appropriate address type, with udpEndpointLocalAddress specifying the local address. In all cases where the remote is a wildcard, the udpEndpointRemoteAddressType is unknown(0), the udpEndpointRemoteAddress is ''h (a zero-length octet-string), and the udpEndpointRemotePort is 0. If the operating system is demultiplexing UDP packets by remote address and port, or if the application has 'connected' the socket specifying a default remote address and port, the udpEndpointRemote* values should be used to reflect this." ::= { udp 7 } udpEndpointEntry OBJECT-TYPE SYNTAX UdpEndpointEntry MAX-ACCESS not-accessible STATUS current Fenner & Flick Standards [Page 8] RFC 4113 UDP MIB June 2005 DESCRIPTION "Information about a particular current UDP endpoint. Implementers need to be aware that if the total number of elements (octets or sub-identifiers) in udpEndpointLocalAddress and udpEndpointRemoteAddress exceeds 111, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { udpEndpointLocalAddressType, udpEndpointLocalAddress, udpEndpointLocalPort, udpEndpointRemoteAddressType, udpEndpointRemoteAddress, udpEndpointRemotePort, udpEndpointInstance } ::= { udpEndpointTable 1 } UdpEndpointEntry ::= SEQUENCE { udpEndpointLocalAddressType InetAddressType, udpEndpointLocalAddress InetAddress, udpEndpointLocalPort InetPortNumber, udpEndpointRemoteAddressType InetAddressType, udpEndpointRemoteAddress InetAddress, udpEndpointRemotePort InetPortNumber, udpEndpointInstance Unsigned32, udpEndpointProcess Unsigned32 } udpEndpointLocalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of udpEndpointLocalAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all local IP addresses are accepted." ::= { udpEndpointEntry 1 } udpEndpointLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local IP address for this UDP endpoint. The value of this object can be represented in three Fenner & Flick Standards [Page 9] RFC 4113 UDP MIB June 2005 possible ways, depending on the characteristics of the listening application: 1. For an application that is willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding instance of the udpEndpointLocalAddressType object being unknown(0). 2. For an application that is willing to accept only IPv4 or only IPv6 datagrams, the value of this object must be '0.0.0.0' or '::', respectively, while the corresponding instance of the udpEndpointLocalAddressType object represents the appropriate address type. 3. For an application that is listening for data destined only to a specific IP address, the value of this object is the specific IP address for which this node is receiving packets, with the corresponding instance of the udpEndpointLocalAddressType object representing the appropriate address type. As this object is used in the index for the udpEndpointTable, implementors of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { udpEndpointEntry 2 } udpEndpointLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local port number for this UDP endpoint." ::= { udpEndpointEntry 3 } udpEndpointRemoteAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of udpEndpointRemoteAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all remote IP addresses are accepted. Also, note that some combinations of Fenner & Flick Standards [Page 10] RFC 4113 UDP MIB June 2005 udpEndpointLocalAdressType and udpEndpointRemoteAddressType are not supported. In particular, if the value of this object is not unknown(0), it is expected to always refer to the same IP version as udpEndpointLocalAddressType." ::= { udpEndpointEntry 4 } udpEndpointRemoteAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote IP address for this UDP endpoint. If datagrams from any remote system are to be accepted, this value is ''h (a zero-length octet-string). Otherwise, it has the type described by udpEndpointRemoteAddressType and is the address of the remote system from which datagrams are to be accepted (or to which all datagrams will be sent). As this object is used in the index for the udpEndpointTable, implementors of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { udpEndpointEntry 5 } udpEndpointRemotePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port number for this UDP endpoint. If datagrams from any remote system are to be accepted, this value is zero." ::= { udpEndpointEntry 6 } udpEndpointInstance OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of this tuple. This object is used to distinguish among multiple processes 'connected' to the same UDP endpoint. For example, on a system implementing the BSD sockets interface, this would be used to support the SO_REUSEADDR and SO_REUSEPORT socket options." Fenner & Flick Standards [Page 11] RFC 4113 UDP MIB June 2005 ::= { udpEndpointEntry 7 } udpEndpointProcess OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The system's process ID for the process associated with this endpoint, or zero if there is no such process. This value is expected to be the same as HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB:: sysApplElmtRunIndex for some row in the appropriate tables." ::= { udpEndpointEntry 8 } -- The deprecated UDP Listener table -- The deprecated UDP listener table only contains information -- about this entity's IPv4 UDP end-points on which a local -- application is currently accepting datagrams. It does not -- provide more detailed connection information, or information -- about IPv6 endpoints. udpTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A table containing IPv4-specific UDP listener information. It contains information about all local IPv4 UDP end-points on which an application is currently accepting datagrams. This table has been deprecated in favor of the version neutral udpEndpointTable." ::= { udp 5 } udpEntry OBJECT-TYPE SYNTAX UdpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Information about a particular current UDP listener." INDEX { udpLocalAddress, udpLocalPort } ::= { udpTable 1 } UdpEntry ::= SEQUENCE { udpLocalAddress IpAddress, udpLocalPort Integer32 Fenner & Flick Standards [Page 12] RFC 4113 UDP MIB June 2005 } udpLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The local IP address for this UDP listener. In the case of a UDP listener that is willing to accept datagrams for any IP interface associated with the node, the value 0.0.0.0 is used." ::= { udpEntry 1 } udpLocalPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The local port number for this UDP listener." ::= { udpEntry 2 } -- conformance information udpMIBConformance OBJECT IDENTIFIER ::= { udpMIB 2 } udpMIBCompliances OBJECT IDENTIFIER ::= { udpMIBConformance 1 } udpMIBGroups OBJECT IDENTIFIER ::= { udpMIBConformance 2 } -- compliance statements udpMIBCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems that implement UDP. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which we have the following compliance requirements, expressed in OBJECT clause form in this description clause: -- OBJECT udpEndpointLocalAddressType -- SYNTAX InetAddressType { unknown(0), ipv4(1), -- ipv6(2), ipv4z(3), -- ipv6z(4) } -- DESCRIPTION -- Support for dns(5) is not required. -- OBJECT udpEndpointLocalAddress Fenner & Flick Standards [Page 13] RFC 4113 UDP MIB June 2005 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION -- Support is only required for zero-length -- octet-strings, and for scoped and unscoped -- IPv4 and IPv6 addresses. -- OBJECT udpEndpointRemoteAddressType -- SYNTAX InetAddressType { unknown(0), ipv4(1), -- ipv6(2), ipv4z(3), -- ipv6z(4) } -- DESCRIPTION -- Support for dns(5) is not required. -- OBJECT udpEndpointRemoteAddress -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION -- Support is only required for zero-length -- octet-strings, and for scoped and unscoped -- IPv4 and IPv6 addresses. " MODULE -- this module MANDATORY-GROUPS { udpBaseGroup, udpEndpointGroup } GROUP udpHCGroup DESCRIPTION "This group is mandatory for systems that are capable of receiving or transmitting more than 1 million UDP datagrams per second. 1 million datagrams per second will cause a Counter32 to wrap in just over an hour." ::= { udpMIBCompliances 2 } udpMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for IPv4-only systems that implement UDP. For IP version independence, this compliance statement is deprecated in favor of udpMIBCompliance2. However, agents are still encouraged to implement these objects in order to interoperate with the deployed base of managers." MODULE -- this module MANDATORY-GROUPS { udpGroup } ::= { udpMIBCompliances 1 } -- units of conformance udpGroup OBJECT-GROUP OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams, udpLocalAddress, udpLocalPort } Fenner & Flick Standards [Page 14] RFC 4113 UDP MIB June 2005 STATUS deprecated DESCRIPTION "The deprecated group of objects providing for management of UDP over IPv4." ::= { udpMIBGroups 1 } udpBaseGroup OBJECT-GROUP OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams } STATUS current DESCRIPTION "The group of objects providing for counters of UDP statistics." ::= { udpMIBGroups 2 } udpHCGroup OBJECT-GROUP OBJECTS { udpHCInDatagrams, udpHCOutDatagrams } STATUS current DESCRIPTION "The group of objects providing for counters of high speed UDP implementations." ::= { udpMIBGroups 3 } udpEndpointGroup OBJECT-GROUP OBJECTS { udpEndpointProcess } STATUS current DESCRIPTION "The group of objects providing for the IP version independent management of UDP 'endpoints'." ::= { udpMIBGroups 4 } END 4. Acknowledgements This document contains a modified subset of RFC 1213 and replaces RFCs 2013 and 2454. Acknowledgments are therefore due to the authors and editors of these documents for their excellent work. 5. Contributors This document is an output of the IPv6 MIB revision team, and contributors to earlier versions of this document include: Bill Fenner, AT&T Labs -- Research Email: fenner@research.at.com Fenner & Flick Standards [Page 15] RFC 4113 UDP MIB June 2005 Brian Haberman Email: brian@innovationslab.net Shawn A. Routhier, Wind River Email: sar@epilogue.com Juergen Schoenwalder, TU Braunschweig Email: schoenw@ibr.cs.tu-bs.de Dave Thaler, Microsoft Email: dthaler@windows.microsoft.com Much of Keith McCloghrie's text from RFC1213/RFC2013 remains in this document, and the structure of the MIB is due to him. Mike Daniele wrote the original IPv6 UDP MIB in RFC2454. Juergen Schoenwalder provided much of the text for section 2. 6. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: The indices of the udpEndpointTable and udpTable contain information on the listeners on an entity. In particular, the udpEndpointLocalPort and udpLocalPort objects in the indices can be used to identify what ports are open on the machine and what attacks are likely to succeed, without the attacker having to run a port scanner. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Fenner & Flick Standards [Page 16] RFC 4113 UDP MIB June 2005 It is recommended that the implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry: +------------+-------------------------+ | Descriptor | OBJECT IDENTIFIER value | +------------+-------------------------+ | udp | { mib-2 7} | | udpMIB | { mib-2 50 } | +------------+-------------------------+ 8. References 8.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Fenner & Flick Standards [Page 17] RFC 4113 UDP MIB June 2005 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 8.2. Informative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [RFC2013] McCloghrie, K., "SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2", RFC 2013, November 1996. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [RFC2454] Daniele, M., "IP Version 6 Management Information Base for the User Datagram Protocol", RFC 2454, December 1998. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Authors' Addresses Bill Fenner AT&T Labs -- Research 75 Willow Rd Menlo Park, CA 94025 USA EMail: fenner@research.att.com John Flick Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557 USA EMail: john.flick@hp.com Fenner & Flick Standards [Page 18] RFC 4113 UDP MIB June 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Fenner & Flick Standards [Page 19] snmp-mibs-downloader-1.1/mibrfcs/rfc4131.txt0000644000000000000000000054546311402176072015574 0ustar Network Working Group S. Green Request for Comments: 4131 Consultant Category: Standards Track K. Ozawa Toshiba E. Cardona, Ed. CableLabs A. Katsnelson September 2005 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. Table of Contents 1. The Internet-Standard Management Framework..................... 2 2. Overview....................................................... 2 2.1. Structure of the MIB...................................... 3 2.2. Relationship of BPI+ and BPI MIB Modules.................. 4 2.3. BPI+ MIB Module Relationship with The Interfaces Group MIB 5 3. Definitions.................................................... 5 4. Acknowledgements............................................... 77 5. Normative References........................................... 77 6. Informative References......................................... 78 7. Security Considerations........................................ 79 8. IANA Considerations............................................ 83 Green, et al. Standards Track [Page 1] RFC 4131 DOCSIS BPI Plus MIB September 2005 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This MIB module (BPI+ MIB) provides a set of objects required for the management of the Baseline Privacy Interface Plus features of DOCSIS 1.1 and DOCSIS 2.0 Cable Modem (CM) and Cable Modem Termination System (CMTS). The specification is derived from the operational model described in the DOCSIS Baseline Privacy Interface Plus Specification [DOCSIS]. DOCSIS Baseline Privacy Plus is composed of four distinct functional and manageable areas: o Key exchange and data encryption o Cable modem authentication o Multicast encryption o Authentication of downloaded software images This MIB module is an extension of the DOCSIS 1.0 Baseline Privacy MIB module [RFC3083] (BPI MIB), which is derived from the Operational model described in the DOCSIS Baseline Privacy Interface Specification [DOCSIS-1.0]. The original Baseline Privacy MIB structure has mostly been preserved in the Baseline Privacy Plus MIB. Please note that the referenced DOCSIS specifications only require that Cable Modems process IPv4 customer traffic. Design choices in this MIB module reflect those requirements. Future versions of the DOCSIS specifications are expected to require support for IPv6 as well. Green, et al. Standards Track [Page 2] RFC 4131 DOCSIS BPI Plus MIB September 2005 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2.1. Structure of the MIB This MIB module is structured into several tables and objects. 2.1.1. Cable Modem o The docsBpi2CmBaseTable contains authorization key exchange information for one CM MAC interface. o The docsBpi2CmTEKTable contains traffic key exchange and data encryption information for a particular security association ID of the cable modem. o Multicast Encryption information is maintained under Docsbpi2CmMulticastObjects. There is currently one multicast table object that manages IP multicast encryption, docsBpi2CmIpMulticastMapTable. o Digital certificates used for cable modem authentication are accessible via docsBpi2CmDeviceCertTable. o Cryptographic suite capabilities for a CM MAC are maintained in the docsBpi2CmCryptoSuiteTable. 2.1.2. Cable Modem Termination System o The docsBpi2CmtsBaseTable contains default settings and summary counters for the cable modem termination system. o The DocsBpi2CmtsAuthTable contains Authorization Key Exchange information for each CM MAC interface, as well as data from CM certificates used in cable modem authentication. o The docsBpi2CmtsTEKTable contains traffic key exchange and data encryption information for a particular security association ID. o Multicast Encryption information is maintained under Docsbpi2CmtsMulticastObjects. There are currently two multicast table objects. The Table docsBpi2CmtsIpMulticastMapTable is Green, et al. Standards Track [Page 3] RFC 4131 DOCSIS BPI Plus MIB September 2005 specifically designed for IP multicast encryption, whereas docsBpi2CmtsMulticastAuthTable is meant to manage all multicast security associations. In particular, the table docsBpi2CmtsIpMulticastMapTable defines the object docsBpi2CmtsIpMulticastMask, which could be a non-contiguous netmask; this is why the object syntax is based on the INET-ADDRESS-MIB MIB Module [RFC4001] Textual Convention InetAddress instead of InetAddressPrefixLength. This is to facilitate the assignment of same DOCSIS Security Association ID (SAID) to one or more IPv6 multicast group IDs matching one or more IPv6 multicast scope types within an entry in this table. For example, multicast scopes labeled "unassigned" [RFC3513] may be allocated by administrators to a particular SAID, regardless of their multicast scope; such mapping transient multicast group 'Y' to SAID 'z' for ANY multicast scope. The non-contiguous netmask will be FF10:Y. See [RFC3513] for details on IPv6 multicast addressing. o DocsBpi2CmtsCertObjects contains 2 manageable tables: one for provisioned cable modem certificates and one for certification authority certificates. 2.1.3. Common o The docsBpi2CodeDownloadControl objects manage the authenticated software download process for a given device. 2.2. Relationship of BPI+ and BPI MIB Modules This section describes the relationship between the BPI+ MIB module defined in this document and the BPI MIB module defined in RFC 3083 [RFC3083]. The BPI+ protocol interface is an enhancement to the BPI protocol, and it is a distinct protocol from BPI. The associated BPI+ managed objects should be considered separate from the BPI MIB objects defined in RFC 3083. DOCSIS 1.1 and 2.0 systems implement both the BPI+ and BPI protocols to be backward compatible with 1.0 systems. For more information regarding the interoperability between BPI and BPI+ compliant systems, refer to appendix C of the DOCSIS BPI+ specification [DOCSIS]. For MIB modules requirements, refer to section 4.6.1, Figure 9, of the DOCSIS 1.1 OSSI specification [DOCSIS-1.1] and to section 7.6.1, Tables 7-9, of the DOCSIS 2.0 OSSI specification [DOCSIS-2.0]. Green, et al. Standards Track [Page 4] RFC 4131 DOCSIS BPI Plus MIB September 2005 2.3. BPI+ MIB Module Relationship with the Interfaces Group MIB The BPI+ MIB module is the management framework of Baseline Privacy Plus Interface Specification [DOCSIS], which provides the MAC layer (Media Access Control) security services of DOCSIS through the Baseline Privacy Key Management (BPKM) protocol. The BPI+ MIB module objects are organized as extensions of the Radio Frequency (RF) Interface Management [RFC2670]. The MIB table structures of this MIB Module are extensions of the DOCSIS CATV (Community Antenna Television) MAC layer interface (DocsCableMaclayer by [IANA]). In particular, the provisions of the Interface Group MIB [RFC2863] for counter discontinuities and system re-initialization apply to CM and CMTS to validate the difference between two consecutive counter polls. All BPI+ MIB module counters are 32 bits and are based on the minimum time to wrap up considerations of [RFC2863] and their possible frequency occurrence as BPI+ FSM (Finite State Machine) event counters. See [DOCSIS] for BPI+ FSM parameter guidelines. 3. Definitions DOCS-IETF-BPI2-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] TEXTUAL-CONVENTION, MacAddress, RowStatus, TruthValue, DateAndTime, StorageType FROM SNMPv2-TC -- [RFC2579] OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF -- [RFC2580] ifIndex FROM IF-MIB -- [RFC2863] InetAddressType, InetAddress Green, et al. Standards Track [Page 5] RFC 4131 DOCSIS BPI Plus MIB September 2005 FROM INET-ADDRESS-MIB; -- [RFC4001] docsBpi2MIB MODULE-IDENTITY LAST-UPDATED "200507200000Z" -- July 20, 2005 ORGANIZATION "IETF IP over Cable Data Network (IPCDN) Working Group" CONTACT-INFO "--------------------------------------- Stuart M. Green E-mail: rubbersoul3@yahoo.com --------------------------------------- Kaz Ozawa Automotive Systems Development Center TOSHIBA CORPORATION 1-1, Shibaura 1-Chome Minato-ku, Tokyo 105-8001 Japan Phone: +81-3-3457-8569 Fax: +81-3-5444-9325 E-mail: Kazuyoshi.Ozawa@toshiba.co.jp --------------------------------------- Alexander Katsnelson Postal: Tel: +1-303-680-3924 E-mail: katsnelson6@peoplepc.com --------------------------------------- Eduardo Cardona Postal: Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80027- 9750 U.S.A. Tel: +1 303 661 9100 Fax: +1 303 661 9199 E-mail: e.cardona@cablelabs.com --------------------------------------- IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn. Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn. Co-chairs: Richard Woundy, rwoundy@cisco.com Jean-Francois Mule, jfm@cablelabs.com" DESCRIPTION "This is the MIB module for the DOCSIS Baseline Privacy Plus Interface (BPI+) at cable modems (CMs) and cable modem termination systems (CMTSs). Copyright (C) The Internet Society (2005). This Green, et al. Standards Track [Page 6] RFC 4131 DOCSIS BPI Plus MIB September 2005 version of this MIB module is part of RFC 4131; see the RFC itself for full legal notices." REVISION "200507200000Z" -- July 20, 2005 DESCRIPTION "Initial version of the IETF BPI+ MIB module. This version published as RFC 4131." ::= { mib-2 126 } -- Textual conventions DocsX509ASN1DEREncodedCertificate ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An X509 digital certificate encoded as an ASN.1 DER object." SYNTAX OCTET STRING (SIZE (0..4096)) DocsSAId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Security Association identifier (SAID)." REFERENCE "DOCSIS Baseline Privacy Plus Interface specification, Section 2.1.3, BPI+ Security Associations" SYNTAX Integer32 (1..16383) DocsSAIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Security Association identifier (SAID). The value zero indicates that the SAID is yet to be determined." REFERENCE "DOCSIS Baseline Privacy Plus Interface specification, Section 2.1.3, BPI+ Security Associations" SYNTAX Unsigned32 (0 | 1..16383) DocsBpkmSAType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of security association (SA). The values of the named-numbers are associated with the BPKM SA-Type attributes: 'primary' corresponds to code '1', 'static' to code '2', Green, et al. Standards Track [Page 7] RFC 4131 DOCSIS BPI Plus MIB September 2005 and 'dynamic' to code '3'. The 'none' value must only be used if the SA type has yet to be determined." REFERENCE "DOCSIS Baseline Privacy Plus Interface specification, Section 4.2.2.24" SYNTAX INTEGER { none(0), primary(1), static(2), dynamic(3) } DocsBpkmDataEncryptAlg ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The list of data encryption algorithms defined for the DOCSIS interface in the BPKM cryptographic-suite parameter. The value 'none' indicates that the SAID being referenced has no data encryption." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." SYNTAX INTEGER { none(0), des56CbcMode(1), des40CbcMode(2), t3Des128CbcMode(3), aes128CbcMode(4), aes256CbcMode(5) } DocsBpkmDataAuthentAlg ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The list of data integrity algorithms defined for the DOCSIS interface in the BPKM cryptographic-suite parameter. The value 'none' indicates that no data integrity is used for the SAID being referenced." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." SYNTAX INTEGER { none(0), hmacSha196(1) } docsBpi2MIBObjects OBJECT IDENTIFIER ::= { docsBpi2MIB 1 } Green, et al. Standards Track [Page 8] RFC 4131 DOCSIS BPI Plus MIB September 2005 -- Cable Modem Group docsBpi2CmObjects OBJECT IDENTIFIER ::= { docsBpi2MIBObjects 1 } -- -- The BPI+ base and authorization table for CMs, -- indexed by ifIndex -- docsBpi2CmBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic and authorization- related Baseline Privacy Plus attributes of each CM MAC interface." ::= { docsBpi2CmObjects 1 } docsBpi2CmBaseEntry OBJECT-TYPE SYNTAX DocsBpi2CmBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CM MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpi2CmBaseTable 1 } DocsBpi2CmBaseEntry ::= SEQUENCE { docsBpi2CmPrivacyEnable TruthValue, docsBpi2CmPublicKey OCTET STRING, docsBpi2CmAuthState INTEGER, docsBpi2CmAuthKeySequenceNumber Integer32, docsBpi2CmAuthExpiresOld DateAndTime, docsBpi2CmAuthExpiresNew DateAndTime, docsBpi2CmAuthReset TruthValue, docsBpi2CmAuthGraceTime Integer32, docsBpi2CmTEKGraceTime Integer32, docsBpi2CmAuthWaitTimeout Integer32, docsBpi2CmReauthWaitTimeout Integer32, docsBpi2CmOpWaitTimeout Integer32, docsBpi2CmRekeyWaitTimeout Integer32, docsBpi2CmAuthRejectWaitTimeout Integer32, docsBpi2CmSAMapWaitTimeout Integer32, docsBpi2CmSAMapMaxRetries Integer32, docsBpi2CmAuthentInfos Counter32, Green, et al. Standards Track [Page 9] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmAuthRequests Counter32, docsBpi2CmAuthReplies Counter32, docsBpi2CmAuthRejects Counter32, docsBpi2CmAuthInvalids Counter32, docsBpi2CmAuthRejectErrorCode INTEGER, docsBpi2CmAuthRejectErrorString SnmpAdminString, docsBpi2CmAuthInvalidErrorCode INTEGER, docsBpi2CmAuthInvalidErrorString SnmpAdminString } docsBpi2CmPrivacyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies whether this CM is provisioned to run Baseline Privacy Plus." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1." ::= { docsBpi2CmBaseEntry 1 } docsBpi2CmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..524)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1), corresponding to the public key of the CM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.4." ::= { docsBpi2CmBaseEntry 2 } docsBpi2CmAuthState OBJECT-TYPE SYNTAX INTEGER { start(1), authWait(2), authorized(3), reauthWait(4), authRejectWait(5), silent(6) } MAX-ACCESS read-only STATUS current Green, et al. Standards Track [Page 10] RFC 4131 DOCSIS BPI Plus MIB September 2005 DESCRIPTION "The value of this object is the state of the CM authorization FSM. The start state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.1." ::= { docsBpi2CmBaseEntry 3 } docsBpi2CmAuthKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the most recent authorization key sequence number for this FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.2 and 4.2.2.10." ::= { docsBpi2CmBaseEntry 4 } docsBpi2CmAuthExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent authorization key for this FSM. If this FSM has only one authorization key, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpi2CmBaseEntry 5 } docsBpi2CmAuthExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent authorization key for this FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpi2CmBaseEntry 6 } Green, et al. Standards Track [Page 11] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'true' generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE. This object is for testing purposes only, and therefore it is not required to be associated with a last reset object." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } docsBpi2CmAuthGraceTime OBJECT-TYPE SYNTAX Integer32 (1..6047999) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for an authorization key in seconds. A CM is expected to start trying to get a new authorization key beginning AuthGraceTime seconds before the most recent authorization key actually expires." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.3." ::= { docsBpi2CmBaseEntry 8 } docsBpi2CmTEKGraceTime OBJECT-TYPE SYNTAX Integer32 (1..302399) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the grace time for the TEK in seconds. The CM is expected to start trying to acquire a new TEK beginning TEK GraceTime seconds before the expiration of the most recent TEK." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.6." ::= { docsBpi2CmBaseEntry 9 } Green, et al. Standards Track [Page 12] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmAuthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorize Wait Timeout in seconds." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.1." ::= { docsBpi2CmBaseEntry 10 } docsBpi2CmReauthWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..30) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Reauthorize Wait Timeout in seconds." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.2." ::= { docsBpi2CmBaseEntry 11 } docsBpi2CmOpWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Operational Wait Timeout in seconds." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.4." ::= { docsBpi2CmBaseEntry 12 } docsBpi2CmRekeyWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Rekey Wait Timeout in seconds." REFERENCE Green, et al. Standards Track [Page 13] RFC 4131 DOCSIS BPI Plus MIB September 2005 "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.5." ::= { docsBpi2CmBaseEntry 13 } docsBpi2CmAuthRejectWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..600) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Authorization Reject Wait Timeout in seconds." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.7." ::= { docsBpi2CmBaseEntry 14 } docsBpi2CmSAMapWaitTimeout OBJECT-TYPE SYNTAX Integer32 (1..10) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the retransmission interval, in seconds, of SA Map Requests from the MAP Wait state." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.8." ::= { docsBpi2CmBaseEntry 15 } docsBpi2CmSAMapMaxRetries OBJECT-TYPE SYNTAX Integer32 (0..10) UNITS "count" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the maximum number of Map Request retries allowed." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.1.1.1.9." ::= { docsBpi2CmBaseEntry 16 } docsBpi2CmAuthentInfos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Green, et al. Standards Track [Page 14] RFC 4131 DOCSIS BPI Plus MIB September 2005 DESCRIPTION "The value of this object is the number of times the CM has transmitted an Authentication Information message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.9." ::= { docsBpi2CmBaseEntry 17 } docsBpi2CmAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has transmitted an Authorization Request message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.1." ::= { docsBpi2CmBaseEntry 18 } docsBpi2CmAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has received an Authorization Reply message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.2." ::= { docsBpi2CmBaseEntry 19 } docsBpi2CmAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Green, et al. Standards Track [Page 15] RFC 4131 DOCSIS BPI Plus MIB September 2005 DESCRIPTION "The value of this object is the number of times the CM has received an Authorization Reject message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.3." ::= { docsBpi2CmBaseEntry 20 } docsBpi2CmAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times the CM has received an Authorization Invalid message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.7." ::= { docsBpi2CmBaseEntry 21 } docsBpi2CmAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSaid(4), permanentAuthorizationFailure(8), timeOfDayNotAcquired(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Authorization Reject message received by the CM. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no Authorization Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Green, et al. Standards Track [Page 16] RFC 4131 DOCSIS BPI Plus MIB September 2005 Sections 4.2.1.3 and 4.2.2.15." ::= { docsBpi2CmBaseEntry 22 } docsBpi2CmAuthRejectErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent Authorization Reject message received by the CM. This is a zero length string if no Authorization Reject message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpi2CmBaseEntry 23 } docsBpi2CmAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Authorization Invalid message received by the CM. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no Authorization Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.7 and 4.2.2.15." ::= { docsBpi2CmBaseEntry 24 } docsBpi2CmAuthInvalidErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent Authorization Invalid message received by the CM. This is a zero length string if no Authorization Green, et al. Standards Track [Page 17] RFC 4131 DOCSIS BPI Plus MIB September 2005 Invalid message has been received since reboot." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpi2CmBaseEntry 25 } -- -- The CM TEK Table, indexed by ifIndex and SAID -- docsBpi2CmTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM Traffic Encryption Key (TEK) association. The CM maintains (no more than) one TEK association per SAID per CM MAC interface." ::= { docsBpi2CmObjects 2 } docsBpi2CmTEKEntry OBJECT-TYPE SYNTAX DocsBpi2CmTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the TEK association attributes of one SAID. The CM MUST create one entry per SAID, regardless of whether the SAID was obtained from a Registration Response message, from an Authorization Reply message, or from any dynamic SAID establishment mechanisms." INDEX { ifIndex, docsBpi2CmTEKSAId } ::= { docsBpi2CmTEKTable 1 } DocsBpi2CmTEKEntry ::= SEQUENCE { docsBpi2CmTEKSAId DocsSAId, docsBpi2CmTEKSAType DocsBpkmSAType, docsBpi2CmTEKDataEncryptAlg DocsBpkmDataEncryptAlg, docsBpi2CmTEKDataAuthentAlg DocsBpkmDataAuthentAlg, docsBpi2CmTEKState INTEGER, docsBpi2CmTEKKeySequenceNumber Integer32, docsBpi2CmTEKExpiresOld DateAndTime, docsBpi2CmTEKExpiresNew DateAndTime, docsBpi2CmTEKKeyRequests Counter32, docsBpi2CmTEKKeyReplies Counter32, docsBpi2CmTEKKeyRejects Counter32, docsBpi2CmTEKInvalids Counter32, Green, et al. Standards Track [Page 18] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmTEKAuthPends Counter32, docsBpi2CmTEKKeyRejectErrorCode INTEGER, docsBpi2CmTEKKeyRejectErrorString SnmpAdminString, docsBpi2CmTEKInvalidErrorCode INTEGER, docsBpi2CmTEKInvalidErrorString SnmpAdminString } docsBpi2CmTEKSAId OBJECT-TYPE SYNTAX DocsSAId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is the DOCSIS Security Association ID (SAID)." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.12." ::= { docsBpi2CmTEKEntry 1 } docsBpi2CmTEKSAType OBJECT-TYPE SYNTAX DocsBpkmSAType MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the type of security association." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 2.1.3." ::= { docsBpi2CmTEKEntry 2 } docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE SYNTAX DocsBpkmDataEncryptAlg MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the data encryption algorithm for this SAID." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." ::= { docsBpi2CmTEKEntry 3 } docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE SYNTAX DocsBpkmDataAuthentAlg MAX-ACCESS read-only STATUS current DESCRIPTION Green, et al. Standards Track [Page 19] RFC 4131 DOCSIS BPI Plus MIB September 2005 "The value of this object is the data authentication algorithm for this SAID." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." ::= { docsBpi2CmTEKEntry 4 } docsBpi2CmTEKState OBJECT-TYPE SYNTAX INTEGER { start(1), opWait(2), opReauthWait(3), operational(4), rekeyWait(5), rekeyReauthWait(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the indicated TEK FSM. The start(1) state indicates that the FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.3.1." ::= { docsBpi2CmTEKEntry 5 } docsBpi2CmTEKKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the most recent TEK key sequence number for this TEK FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.2.10 and 4.2.2.13." ::= { docsBpi2CmTEKEntry 6 } docsBpi2CmTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." Green, et al. Standards Track [Page 20] RFC 4131 DOCSIS BPI Plus MIB September 2005 REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpi2CmTEKEntry 7 } docsBpi2CmTEKExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpi2CmTEKEntry 8 } docsBpi2CmTEKKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has transmitted a Key Request message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.4." ::= { docsBpi2CmTEKEntry 9 } docsBpi2CmTEKKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has received a Key Reply message, including a message whose authentication failed. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Green, et al. Standards Track [Page 21] RFC 4131 DOCSIS BPI Plus MIB September 2005 Section 4.2.1.5." ::= { docsBpi2CmTEKEntry 10 } docsBpi2CmTEKKeyRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has received a Key Reject message, including a message whose authentication failed. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.6." ::= { docsBpi2CmTEKEntry 11 } docsBpi2CmTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has received a TEK Invalid message, including a message whose authentication failed. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.8." ::= { docsBpi2CmTEKEntry 12 } docsBpi2CmTEKAuthPends OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the count of times an Authorization Pending (Auth Pend) event occurred in this FSM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Green, et al. Standards Track [Page 22] RFC 4131 DOCSIS BPI Plus MIB September 2005 ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.3.3.3." ::= { docsBpi2CmTEKEntry 13 } docsBpi2CmTEKKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSaid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Key Reject message received by the CM. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no Key Reject message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.1.2.6 and 4.2.2.15." ::= { docsBpi2CmTEKEntry 14 } docsBpi2CmTEKKeyRejectErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent Key Reject message received by the CM. This is a zero length string if no Key Reject message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.1.2.6 and 4.2.2.6." ::= { docsBpi2CmTEKEntry 15 } docsBpi2CmTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION Green, et al. Standards Track [Page 23] RFC 4131 DOCSIS BPI Plus MIB September 2005 "The value of this object is the enumerated description of the Error-Code in the most recent TEK Invalid message received by the CM. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no TEK Invalid message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.1.2.8 and 4.2.2.15." ::= { docsBpi2CmTEKEntry 16 } docsBpi2CmTEKInvalidErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent TEK Invalid message received by the CM. This is a zero length string if no TEK Invalid message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.1.2.8 and 4.2.2.6." ::= { docsBpi2CmTEKEntry 17 } -- -- The CM Multicast Objects Group -- docsBpi2CmMulticastObjects OBJECT IDENTIFIER ::= { docsBpi2CmObjects 3 } -- -- The CM Dynamic IP Multicast Mapping Table, indexed by -- docsBpi2CmIpMulticastIndex and by ifIndex -- docsBpi2CmIpMulticastMapTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maps multicast IP addresses to SAIDs per CM MAC Interface. It is intended to map multicast IP addresses associated with SA MAP Request messages." ::= { docsBpi2CmMulticastObjects 1 } docsBpi2CmIpMulticastMapEntry OBJECT-TYPE Green, et al. Standards Track [Page 24] RFC 4131 DOCSIS BPI Plus MIB September 2005 SYNTAX DocsBpi2CmIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the mapping of one multicast IP address to one SAID, as well as associated state, message counters, and error information. An entry may be removed from this table upon the reception of an SA Map Reject." INDEX { ifIndex, docsBpi2CmIpMulticastIndex } ::= { docsBpi2CmIpMulticastMapTable 1 } DocsBpi2CmIpMulticastMapEntry ::= SEQUENCE { docsBpi2CmIpMulticastIndex Unsigned32, docsBpi2CmIpMulticastAddressType InetAddressType, docsBpi2CmIpMulticastAddress InetAddress, docsBpi2CmIpMulticastSAId DocsSAIdOrZero, docsBpi2CmIpMulticastSAMapState INTEGER, docsBpi2CmIpMulticastSAMapRequests Counter32, docsBpi2CmIpMulticastSAMapReplies Counter32, docsBpi2CmIpMulticastSAMapRejects Counter32, docsBpi2CmIpMulticastSAMapRejectErrorCode INTEGER, docsBpi2CmIpMulticastSAMapRejectErrorString SnmpAdminString } docsBpi2CmIpMulticastIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this row." ::= { docsBpi2CmIpMulticastMapEntry 1 } docsBpi2CmIpMulticastAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet address for docsBpi2CmIpMulticastAddress." ::= { docsBpi2CmIpMulticastMapEntry 2 } docsBpi2CmIpMulticastAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION Green, et al. Standards Track [Page 25] RFC 4131 DOCSIS BPI Plus MIB September 2005 "This object represents the IP multicast address to be mapped. The type of this address is determined by the value of the docsBpi2CmIpMulticastAddressType object." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 5.4." ::= { docsBpi2CmIpMulticastMapEntry 3 } docsBpi2CmIpMulticastSAId OBJECT-TYPE SYNTAX DocsSAIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the SAID to which the IP multicast address has been mapped. If no SA Map Reply has been received for the IP address, this object should have the value 0." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.12." ::= { docsBpi2CmIpMulticastMapEntry 4 } docsBpi2CmIpMulticastSAMapState OBJECT-TYPE SYNTAX INTEGER { start(1), mapWait(2), mapped(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the SA Mapping FSM for this IP." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 5.3.1." ::= { docsBpi2CmIpMulticastMapEntry 5 } docsBpi2CmIpMulticastSAMapRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has transmitted an SA Map Request message for this IP. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Green, et al. Standards Track [Page 26] RFC 4131 DOCSIS BPI Plus MIB September 2005 ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.10." ::= { docsBpi2CmIpMulticastMapEntry 6 } docsBpi2CmIpMulticastSAMapReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has received an SA Map Reply message for this IP. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.11." ::= { docsBpi2CmIpMulticastMapEntry 7 } docsBpi2CmIpMulticastSAMapRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CM has received an SA MAP Reject message for this IP. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.12." ::= { docsBpi2CmIpMulticastMapEntry 8 } docsBpi2CmIpMulticastSAMapRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), noAuthForRequestedDSFlow(9), dsFlowNotMappedToSA(10) } MAX-ACCESS read-only STATUS current DESCRIPTION Green, et al. Standards Track [Page 27] RFC 4131 DOCSIS BPI Plus MIB September 2005 "The value of this object is the enumerated description of the Error-Code in the most recent SA Map Reject message sent in response to an SA Map Request for This IP. It has the value none(1) if no SA MAP Reject message has been received since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.12 and 4.2.2.15." ::= { docsBpi2CmIpMulticastMapEntry 9 } docsBpi2CmIpMulticastSAMapRejectErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent SA Map Reject message sent in response to an SA Map Request for this IP. It is a zero length string if no SA Map Reject message has been received since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.12 and 4.2.2.6." ::= { docsBpi2CmIpMulticastMapEntry 10 } -- -- CM Cert Objects -- docsBpi2CmCertObjects OBJECT IDENTIFIER ::= { docsBpi2CmObjects 4 } -- -- CM Device Cert Table -- docsBpi2CmDeviceCertTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmDeviceCertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the Baseline Privacy Plus device certificates for each CM MAC interface." ::= { docsBpi2CmCertObjects 1 } docsBpi2CmDeviceCertEntry OBJECT-TYPE SYNTAX DocsBpi2CmDeviceCertEntry MAX-ACCESS not-accessible Green, et al. Standards Track [Page 28] RFC 4131 DOCSIS BPI Plus MIB September 2005 STATUS current DESCRIPTION "Each entry contains the device certificates of one CM MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpi2CmDeviceCertTable 1 } DocsBpi2CmDeviceCertEntry ::= SEQUENCE { docsBpi2CmDeviceCmCert DocsX509ASN1DEREncodedCertificate, docsBpi2CmDeviceManufCert DocsX509ASN1DEREncodedCertificate } docsBpi2CmDeviceCmCert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-write STATUS current DESCRIPTION "The X509 DER-encoded cable modem certificate. Note: This object can be set only when the value is the zero-length OCTET STRING; otherwise, an error of 'inconsistentValue' is returned. Once the object contains the certificate, its access MUST be read-only and persists after re-initialization of the managed system." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.1." ::= { docsBpi2CmDeviceCertEntry 1 } docsBpi2CmDeviceManufCert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-only STATUS current DESCRIPTION "The X509 DER-encoded manufacturer certificate that signed the cable modem certificate." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.1." ::= { docsBpi2CmDeviceCertEntry 2 } -- -- CM Crypto Suite Table -- Green, et al. Standards Track [Page 29] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmCryptoSuiteTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmCryptoSuiteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the Baseline Privacy Plus cryptographic suite capabilities for each CM MAC interface." ::= { docsBpi2CmObjects 5 } docsBpi2CmCryptoSuiteEntry OBJECT-TYPE SYNTAX DocsBpi2CmCryptoSuiteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains a cryptographic suite pair that this CM MAC supports." INDEX { ifIndex, docsBpi2CmCryptoSuiteIndex } ::= { docsBpi2CmCryptoSuiteTable 1 } DocsBpi2CmCryptoSuiteEntry ::= SEQUENCE { docsBpi2CmCryptoSuiteIndex Unsigned32, docsBpi2CmCryptoSuiteDataEncryptAlg DocsBpkmDataEncryptAlg, docsBpi2CmCryptoSuiteDataAuthentAlg DocsBpkmDataAuthentAlg } docsBpi2CmCryptoSuiteIndex OBJECT-TYPE SYNTAX Unsigned32 (1..1000) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for a cryptographic suite row." ::= { docsBpi2CmCryptoSuiteEntry 1 } docsBpi2CmCryptoSuiteDataEncryptAlg OBJECT-TYPE SYNTAX DocsBpkmDataEncryptAlg MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the data encryption algorithm for this cryptographic suite capability." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." ::= { docsBpi2CmCryptoSuiteEntry 2 } Green, et al. Standards Track [Page 30] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmCryptoSuiteDataAuthentAlg OBJECT-TYPE SYNTAX DocsBpkmDataAuthentAlg MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the data authentication algorithm for this cryptographic suite capability." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." ::= { docsBpi2CmCryptoSuiteEntry 3 } -- Cable Modem Termination System Group docsBpi2CmtsObjects OBJECT IDENTIFIER ::= { docsBpi2MIBObjects 2 } -- -- SPECIAL NOTE: For the following CMTS tables, when a CM is -- running in BPI mode, replace SAID (Security Association ID) -- with SID (Service ID). The CMTS is required to map SAIDs and -- SIDs to one contiguous space. -- -- -- The BPI+ base table for CMTSs, indexed by ifIndex -- docsBpi2CmtsBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the basic Baseline Privacy attributes of each CMTS MAC interface." ::= { docsBpi2CmtsObjects 1 } docsBpi2CmtsBaseEntry OBJECT-TYPE SYNTAX DocsBpi2CmtsBaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one CMTS MAC interface. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsBpi2CmtsBaseTable 1 } DocsBpi2CmtsBaseEntry ::= SEQUENCE { Green, et al. Standards Track [Page 31] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsDefaultAuthLifetime Integer32, docsBpi2CmtsDefaultTEKLifetime Integer32, docsBpi2CmtsDefaultSelfSignedManufCertTrust INTEGER, docsBpi2CmtsCheckCertValidityPeriods TruthValue, docsBpi2CmtsAuthentInfos Counter32, docsBpi2CmtsAuthRequests Counter32, docsBpi2CmtsAuthReplies Counter32, docsBpi2CmtsAuthRejects Counter32, docsBpi2CmtsAuthInvalids Counter32, docsBpi2CmtsSAMapRequests Counter32, docsBpi2CmtsSAMapReplies Counter32, docsBpi2CmtsSAMapRejects Counter32 } docsBpi2CmtsDefaultAuthLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, that the CMTS assigns to a new authorization key. This object value persists after re-initialization of the managed system." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.2." DEFVAL { 604800 } ::= { docsBpi2CmtsBaseEntry 1 } docsBpi2CmtsDefaultTEKLifetime OBJECT-TYPE SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the default lifetime, in seconds, that the CMTS assigns to a new Traffic Encryption Key (TEK). This object value persists after re-initialization of the managed system." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Appendix A.2." DEFVAL { 43200 } ::= { docsBpi2CmtsBaseEntry 2 } docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE Green, et al. Standards Track [Page 32] RFC 4131 DOCSIS BPI Plus MIB September 2005 SYNTAX INTEGER { trusted (1), untrusted (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines the default trust of self-signed manufacturer certificate entries, contained in docsBpi2CmtsCACertTable, and created after this object is set. This object need not persist after re-initialization of the managed system." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.1" ::= { docsBpi2CmtsBaseEntry 3 } docsBpi2CmtsCheckCertValidityPeriods OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'true' causes all chained and root certificates in the chain to have their validity periods checked against the current time of day, when the CMTS receives an Authorization Request from the CM. A 'false' setting causes all certificates in the chain not to have their validity periods checked against the current time of day. This object need not persist after re-initialization of the managed system." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.2" ::= { docsBpi2CmtsBaseEntry 4 } docsBpi2CmtsAuthentInfos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has received an Authentication Information message from any CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other Green, et al. Standards Track [Page 33] RFC 4131 DOCSIS BPI Plus MIB September 2005 times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.9." ::= { docsBpi2CmtsBaseEntry 5 } docsBpi2CmtsAuthRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has received an Authorization Request message from any CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.1." ::= { docsBpi2CmtsBaseEntry 6 } docsBpi2CmtsAuthReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an Authorization Reply message to any CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.2." ::= { docsBpi2CmtsBaseEntry 7 } docsBpi2CmtsAuthRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an Authorization Reject message to any Green, et al. Standards Track [Page 34] RFC 4131 DOCSIS BPI Plus MIB September 2005 CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.3." ::= { docsBpi2CmtsBaseEntry 8 } docsBpi2CmtsAuthInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an Authorization Invalid message to any CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.7." ::= { docsBpi2CmtsBaseEntry 9 } docsBpi2CmtsSAMapRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has received an SA Map Request message from any CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.10." ::= { docsBpi2CmtsBaseEntry 10 } docsBpi2CmtsSAMapReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Green, et al. Standards Track [Page 35] RFC 4131 DOCSIS BPI Plus MIB September 2005 "The value of this object is the number of times the CMTS has transmitted an SA Map Reply message to any CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.11." ::= { docsBpi2CmtsBaseEntry 11 } docsBpi2CmtsSAMapRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an SA Map Reject message to any CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.12." ::= { docsBpi2CmtsBaseEntry 12 } -- -- The CMTS Authorization Table, indexed by ifIndex and CM MAC -- address -- docsBpi2CmtsAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmtsAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each CM authorization association. The CMTS maintains one authorization association with each Baseline Privacy- enabled CM, registered on each CMTS MAC interface, regardless of whether the CM is authorized or rejected." ::= { docsBpi2CmtsObjects 2 } docsBpi2CmtsAuthEntry OBJECT-TYPE SYNTAX DocsBpi2CmtsAuthEntry MAX-ACCESS not-accessible STATUS current Green, et al. Standards Track [Page 36] RFC 4131 DOCSIS BPI Plus MIB September 2005 DESCRIPTION "Each entry contains objects describing attributes of one authorization association. The CMTS MUST create one entry per CM per MAC interface, based on the receipt of an Authorization Request message, and MUST not delete the entry until the CM loses registration." INDEX { ifIndex, docsBpi2CmtsAuthCmMacAddress } ::= { docsBpi2CmtsAuthTable 1 } DocsBpi2CmtsAuthEntry ::= SEQUENCE { docsBpi2CmtsAuthCmMacAddress MacAddress, docsBpi2CmtsAuthCmBpiVersion INTEGER, docsBpi2CmtsAuthCmPublicKey OCTET STRING, docsBpi2CmtsAuthCmKeySequenceNumber Integer32, docsBpi2CmtsAuthCmExpiresOld DateAndTime, docsBpi2CmtsAuthCmExpiresNew DateAndTime, docsBpi2CmtsAuthCmLifetime Integer32, docsBpi2CmtsAuthCmReset INTEGER, docsBpi2CmtsAuthCmInfos Counter32, docsBpi2CmtsAuthCmRequests Counter32, docsBpi2CmtsAuthCmReplies Counter32, docsBpi2CmtsAuthCmRejects Counter32, docsBpi2CmtsAuthCmInvalids Counter32, docsBpi2CmtsAuthRejectErrorCode INTEGER, docsBpi2CmtsAuthRejectErrorString SnmpAdminString, docsBpi2CmtsAuthInvalidErrorCode INTEGER, docsBpi2CmtsAuthInvalidErrorString SnmpAdminString, docsBpi2CmtsAuthPrimarySAId DocsSAIdOrZero, docsBpi2CmtsAuthBpkmCmCertValid INTEGER, docsBpi2CmtsAuthBpkmCmCert DocsX509ASN1DEREncodedCertificate, docsBpi2CmtsAuthCACertIndexPtr Unsigned32 } docsBpi2CmtsAuthCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is the physical address of the CM to which the authorization association applies." ::= { docsBpi2CmtsAuthEntry 1 } docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE SYNTAX INTEGER { bpi (0), bpiPlus (1) } Green, et al. Standards Track [Page 37] RFC 4131 DOCSIS BPI Plus MIB September 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the version of Baseline Privacy for which this CM has registered. The value 'bpiplus' represents the value of BPI-Version Attribute of the Baseline Privacy Key Management BPKM attribute BPI-Version (1). The value 'bpi' is used to represent the CM registered using DOCSIS 1.0 Baseline Privacy." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.22; ANSI/SCTE 22-2 2002(formerly DSS 02-03) Data-Over-Cable Service Interface Specification DOCSIS 1.0 Baseline Privacy Interface (BPI)" ::= { docsBpi2CmtsAuthEntry 2 } docsBpi2CmtsAuthCmPublicKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..524)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is a DER-encoded RSAPublicKey ASN.1 type string, as defined in the RSA Encryption Standard (PKCS #1), corresponding to the public key of the CM. This is the zero-length OCTET STRING if the CMTS does not retain the public key." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.4." ::= { docsBpi2CmtsAuthEntry 3 } docsBpi2CmtsAuthCmKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the most recent authorization key sequence number for this CM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.2 and 4.2.2.10." ::= { docsBpi2CmtsAuthEntry 4 } docsBpi2CmtsAuthCmExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION Green, et al. Standards Track [Page 38] RFC 4131 DOCSIS BPI Plus MIB September 2005 "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent authorization key for this FSM. If this FSM has only one authorization key, then the value is the time of activation of this FSM. Note: This object has no meaning for CMs running in BPI mode; therefore, this object is not instantiated for entries associated to those CMs." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpi2CmtsAuthEntry 5 } docsBpi2CmtsAuthCmExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent authorization key for this FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.2 and 4.2.2.9." ::= { docsBpi2CmtsAuthEntry 6 } docsBpi2CmtsAuthCmLifetime OBJECT-TYPE SYNTAX Integer32 (1..6048000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, that the CMTS assigns to an authorization key for this CM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.2 and Appendix A.2." ::= { docsBpi2CmtsAuthEntry 7 } docsBpi2CmtsAuthCmReset OBJECT-TYPE SYNTAX INTEGER { noResetRequested(1), invalidateAuth(2), sendAuthInvalid(3), invalidateTeks(4) } MAX-ACCESS read-write STATUS current Green, et al. Standards Track [Page 39] RFC 4131 DOCSIS BPI Plus MIB September 2005 DESCRIPTION "Setting this object to invalidateAuth(2) causes the CMTS to invalidate the current CM authorization key(s), but not to transmit an Authorization Invalid message nor to invalidate the primary SAID's TEKs. Setting this object to sendAuthInvalid(3) causes the CMTS to invalidate the current CM authorization key(s), and to transmit an Authorization Invalid message to the CM, but not to invalidate the primary SAID's TEKs. Setting this object to invalidateTeks(4) causes the CMTS to invalidate the current CM authorization key(s), to transmit an Authorization Invalid message to the CM, and to invalidate the TEKs associated with this CM's primary SAID. For BPI mode, substitute all of the CM's unicast TEKs for the primary SAID's TEKs in the previous paragraph. Reading this object returns the most recently set value of this object or, if the object has not been set since entry creation, returns noResetRequested(1)." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.1.2.3.4, 4.1.2.3.5, and 4.1.3.3.5." ::= { docsBpi2CmtsAuthEntry 8 } docsBpi2CmtsAuthCmInfos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has received an Authentication Information message from this CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.9." ::= { docsBpi2CmtsAuthEntry 9 } docsBpi2CmtsAuthCmRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has received an Authorization Request message from Green, et al. Standards Track [Page 40] RFC 4131 DOCSIS BPI Plus MIB September 2005 this CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.1." ::= { docsBpi2CmtsAuthEntry 10 } docsBpi2CmtsAuthCmReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an Authorization Reply message to this CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.2." ::= { docsBpi2CmtsAuthEntry 11 } docsBpi2CmtsAuthCmRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an Authorization Reject message to this CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.3." ::= { docsBpi2CmtsAuthEntry 12 } docsBpi2CmtsAuthCmInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Green, et al. Standards Track [Page 41] RFC 4131 DOCSIS BPI Plus MIB September 2005 DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an Authorization Invalid message to this CM. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.7." ::= { docsBpi2CmtsAuthEntry 13 } docsBpi2CmtsAuthRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSaid(4), permanentAuthorizationFailure(8), timeOfDayNotAcquired(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Authorization Reject message transmitted to the CM. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no Authorization Reject message has been transmitted to the CM since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.3 and 4.2.2.15." ::= { docsBpi2CmtsAuthEntry 14 } docsBpi2CmtsAuthRejectErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent Authorization Reject message transmitted to the CM. This is a zero length string if no Authorization Reject message has been transmitted to the CM since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Green, et al. Standards Track [Page 42] RFC 4131 DOCSIS BPI Plus MIB September 2005 Sections 4.2.1.3 and 4.2.2.6." ::= { docsBpi2CmtsAuthEntry 15 } docsBpi2CmtsAuthInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Authorization Invalid message transmitted to the CM. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no Authorization Invalid message has been transmitted to the CM since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.7 and 4.2.2.15." ::= { docsBpi2CmtsAuthEntry 16 } docsBpi2CmtsAuthInvalidErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent Authorization Invalid message transmitted to the CM. This is a zero length string if no Authorization Invalid message has been transmitted to the CM since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.7 and 4.2.2.6." ::= { docsBpi2CmtsAuthEntry 17 } docsBpi2CmtsAuthPrimarySAId OBJECT-TYPE SYNTAX DocsSAIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the Primary Security Association identifier. For BPI mode, the value must be Green, et al. Standards Track [Page 43] RFC 4131 DOCSIS BPI Plus MIB September 2005 any unicast SID." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 2.1.3." ::= { docsBpi2CmtsAuthEntry 18 } docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE SYNTAX INTEGER { unknown (0), validCmChained (1), validCmTrusted (2), invalidCmUntrusted (3), invalidCAUntrusted (4), invalidCmOther (5), invalidCAOther (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the reason why a CM's certificate is deemed valid or invalid. Return unknown(0) if the CM is running BPI mode. ValidCmChained(1) means the certificate is valid because it chains to a valid certificate. ValidCmTrusted(2) means the certificate is valid because it has been provisioned (in the docsBpi2CmtsProvisionedCmCert table) to be trusted. InvalidCmUntrusted(3) means the certificate is invalid because it has been provisioned (in the docsBpi2CmtsProvisionedCmCert table) to be untrusted. InvalidCAUntrusted(4) means the certificate is invalid because it chains to an untrusted certificate. InvalidCmOther(5) and InvalidCAOther(6) refer to errors in parsing, validity periods, etc., which are attributable to the CM certificate or its chain, respectively; additional information may be found in docsBpi2AuthRejectErrorString for these types of errors." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.2." ::= { docsBpi2CmtsAuthEntry 19 } docsBpi2CmtsAuthBpkmCmCert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-only STATUS current DESCRIPTION Green, et al. Standards Track [Page 44] RFC 4131 DOCSIS BPI Plus MIB September 2005 "The X509 CM Certificate sent as part of a BPKM Authorization Request. Note: The zero-length OCTET STRING must be returned if the Entire certificate is not retained in the CMTS." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.2." ::= { docsBpi2CmtsAuthEntry 20 } docsBpi2CmtsAuthCACertIndexPtr OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A row index into docsBpi2CmtsCACertTable. Returns the index in docsBpi2CmtsCACertTable to which CA certificate this CM is chained to. A value of 0 means it could not be found or not applicable." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.2." ::= { docsBpi2CmtsAuthEntry 21 } -- -- The CMTS TEK Table, indexed by ifIndex and SAID -- docsBpi2CmtsTEKTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmtsTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of each Traffic Encryption Key (TEK) association. The CMTS Maintains one TEK association per SAID on each CMTS MAC interface." ::= { docsBpi2CmtsObjects 3 } docsBpi2CmtsTEKEntry OBJECT-TYPE SYNTAX DocsBpi2CmtsTEKEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing attributes of one TEK association on a particular CMTS MAC interface. The CMTS MUST create one entry per SAID per MAC interface, based on the receipt of a Key Request message, and MUST not delete the entry before the CM authorization for the SAID Green, et al. Standards Track [Page 45] RFC 4131 DOCSIS BPI Plus MIB September 2005 permanently expires." INDEX { ifIndex, docsBpi2CmtsTEKSAId } ::= { docsBpi2CmtsTEKTable 1 } DocsBpi2CmtsTEKEntry ::= SEQUENCE { docsBpi2CmtsTEKSAId DocsSAId, docsBpi2CmtsTEKSAType DocsBpkmSAType, docsBpi2CmtsTEKDataEncryptAlg DocsBpkmDataEncryptAlg, docsBpi2CmtsTEKDataAuthentAlg DocsBpkmDataAuthentAlg, docsBpi2CmtsTEKLifetime Integer32, docsBpi2CmtsTEKKeySequenceNumber Integer32, docsBpi2CmtsTEKExpiresOld DateAndTime, docsBpi2CmtsTEKExpiresNew DateAndTime, docsBpi2CmtsTEKReset TruthValue, docsBpi2CmtsKeyRequests Counter32, docsBpi2CmtsKeyReplies Counter32, docsBpi2CmtsKeyRejects Counter32, docsBpi2CmtsTEKInvalids Counter32, docsBpi2CmtsKeyRejectErrorCode INTEGER, docsBpi2CmtsKeyRejectErrorString SnmpAdminString, docsBpi2CmtsTEKInvalidErrorCode INTEGER, docsBpi2CmtsTEKInvalidErrorString SnmpAdminString } docsBpi2CmtsTEKSAId OBJECT-TYPE SYNTAX DocsSAId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is the DOCSIS Security Association ID (SAID)." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.12." ::= { docsBpi2CmtsTEKEntry 1 } docsBpi2CmtsTEKSAType OBJECT-TYPE SYNTAX DocsBpkmSAType MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the type of security association. 'dynamic' does not apply to CMs running in BPI mode. Unicast BPI TEKs must utilize the 'primary' encoding, and multicast BPI TEKs must utilize the 'static' encoding." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Green, et al. Standards Track [Page 46] RFC 4131 DOCSIS BPI Plus MIB September 2005 Section 2.1.3." ::= { docsBpi2CmtsTEKEntry 2 } docsBpi2CmtsTEKDataEncryptAlg OBJECT-TYPE SYNTAX DocsBpkmDataEncryptAlg MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the data encryption algorithm for this SAID." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." ::= { docsBpi2CmtsTEKEntry 3 } docsBpi2CmtsTEKDataAuthentAlg OBJECT-TYPE SYNTAX DocsBpkmDataAuthentAlg MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the data authentication algorithm for this SAID." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." ::= { docsBpi2CmtsTEKEntry 4 } docsBpi2CmtsTEKLifetime OBJECT-TYPE SYNTAX Integer32 (1..604800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object is the lifetime, in seconds, that the CMTS assigns to keys for this TEK association." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.5 and Appendix A.2." ::= { docsBpi2CmtsTEKEntry 5 } docsBpi2CmtsTEKKeySequenceNumber OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the most recent TEK Green, et al. Standards Track [Page 47] RFC 4131 DOCSIS BPI Plus MIB September 2005 key sequence number for this SAID." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.2.10 and 4.2.2.13." ::= { docsBpi2CmtsTEKEntry 6 } docsBpi2CmtsTEKExpiresOld OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the immediate predecessor of the most recent TEK for this FSM. If this FSM has only one TEK, then the value is the time of activation of this FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpi2CmtsTEKEntry 7 } docsBpi2CmtsTEKExpiresNew OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the actual clock time for expiration of the most recent TEK for this FSM." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.5 and 4.2.2.9." ::= { docsBpi2CmtsTEKEntry 8 } docsBpi2CmtsTEKReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'true' causes the CMTS to invalidate all currently active TEKs and to generate new TEKs for the associated SAID; the CMTS MAY also generate unsolicited TEK Invalid messages, to optimize the TEK synchronization between the CMTS and the CM(s). Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.3.3.5." ::= { docsBpi2CmtsTEKEntry 9 } Green, et al. Standards Track [Page 48] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsKeyRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has received a Key Request message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.4." ::= { docsBpi2CmtsTEKEntry 10 } docsBpi2CmtsKeyReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted a Key Reply message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.5." ::= { docsBpi2CmtsTEKEntry 11 } docsBpi2CmtsKeyRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted a Key Reject message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.6." ::= { docsBpi2CmtsTEKEntry 12 } Green, et al. Standards Track [Page 49] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsTEKInvalids OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted a TEK Invalid message. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.8." ::= { docsBpi2CmtsTEKEntry 13 } docsBpi2CmtsKeyRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), unauthorizedSaid(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent Key Reject message sent in response to a Key Request for this SAID. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no Key Reject message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.6 and 4.2.2.15." ::= { docsBpi2CmtsTEKEntry 14 } docsBpi2CmtsKeyRejectErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent Key Reject message sent in response to a Key Request for this SAID. This is a zero length string if no Key Reject message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Green, et al. Standards Track [Page 50] RFC 4131 DOCSIS BPI Plus MIB September 2005 Sections 4.2.1.6 and 4.2.2.6." ::= { docsBpi2CmtsTEKEntry 15 } docsBpi2CmtsTEKInvalidErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent TEK Invalid message sent in association with this SAID. This has the value unknown(2) if the last Error-Code value was 0 and none(1) if no TEK Invalid message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.8 and 4.2.2.15." ::= { docsBpi2CmtsTEKEntry 16 } docsBpi2CmtsTEKInvalidErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent TEK Invalid message sent in association with this SAID. This is a zero length string if no TEK Invalid message has been received since registration." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.8 and 4.2.2.6." ::= { docsBpi2CmtsTEKEntry 17 } -- -- The CMTS Multicast Objects Group -- docsBpi2CmtsMulticastObjects OBJECT IDENTIFIER ::= { docsBpi2CmtsObjects 4 } -- -- The CMTS IP Multicast Mapping Table, indexed by -- docsBpi2CmtsIpMulticastIndex, and by ifIndex -- Green, et al. Standards Track [Page 51] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsIpMulticastMapTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmtsIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maps multicast IP addresses to SAIDs. If a multicast IP address is mapped by multiple rows in the table, the row with the lowest docsBpi2CmtsIpMulticastIndex must be utilized for the mapping." ::= { docsBpi2CmtsMulticastObjects 1 } docsBpi2CmtsIpMulticastMapEntry OBJECT-TYPE SYNTAX DocsBpi2CmtsIpMulticastMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the mapping of a set of multicast IP address and the mask to one SAID associated to a CMTS MAC Interface, as well as associated message counters and error information." INDEX { ifIndex, docsBpi2CmtsIpMulticastIndex } ::= { docsBpi2CmtsIpMulticastMapTable 1 } DocsBpi2CmtsIpMulticastMapEntry ::= SEQUENCE { docsBpi2CmtsIpMulticastIndex Unsigned32, docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastMask InetAddress, docsBpi2CmtsIpMulticastSAId DocsSAIdOrZero, docsBpi2CmtsIpMulticastSAType DocsBpkmSAType, docsBpi2CmtsIpMulticastDataEncryptAlg DocsBpkmDataEncryptAlg, docsBpi2CmtsIpMulticastDataAuthentAlg DocsBpkmDataAuthentAlg, docsBpi2CmtsIpMulticastSAMapRequests Counter32, docsBpi2CmtsIpMulticastSAMapReplies Counter32, docsBpi2CmtsIpMulticastSAMapRejects Counter32, docsBpi2CmtsIpMulticastSAMapRejectErrorCode INTEGER, docsBpi2CmtsIpMulticastSAMapRejectErrorString SnmpAdminString, docsBpi2CmtsIpMulticastMapControl RowStatus, docsBpi2CmtsIpMulticastMapStorageType StorageType } docsBpi2CmtsIpMulticastIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) Green, et al. Standards Track [Page 52] RFC 4131 DOCSIS BPI Plus MIB September 2005 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." ::= { docsBpi2CmtsIpMulticastMapEntry 1 } docsBpi2CmtsIpMulticastAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address for docsBpi2CmtsIpMulticastAddress and docsBpi2CmtsIpMulticastMask." DEFVAL { ipv4 } ::= { docsBpi2CmtsIpMulticastMapEntry 2 } docsBpi2CmtsIpMulticastAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the IP multicast address to be mapped, in conjunction with docsBpi2CmtsIpMulticastMask. The type of this address is determined by the value of the object docsBpi2CmtsIpMulticastAddressType." ::= { docsBpi2CmtsIpMulticastMapEntry 3 } docsBpi2CmtsIpMulticastMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the IP multicast address mask for this row. An IP multicast address matches this row if the logical AND of the address with docsBpi2CmtsIpMulticastMask is identical to the logical AND of docsBpi2CmtsIpMulticastAddr with docsBpi2CmtsIpMulticastMask. The type of this address is determined by the value of the object docsBpi2CmtsIpMulticastAddressType. Note: For IPv6, this object need not represent a contiguous netmask; e.g., to associate a SAID to a multicast group matching 'any' multicast scope. The TC Green, et al. Standards Track [Page 53] RFC 4131 DOCSIS BPI Plus MIB September 2005 InetAddressPrefixLength is not used, as it only represents contiguous netmask." ::= { docsBpi2CmtsIpMulticastMapEntry 4 } docsBpi2CmtsIpMulticastSAId OBJECT-TYPE SYNTAX DocsSAIdOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the multicast SAID to be used in this IP multicast address mapping entry." ::= { docsBpi2CmtsIpMulticastMapEntry 5 } docsBpi2CmtsIpMulticastSAType OBJECT-TYPE SYNTAX DocsBpkmSAType MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is the type of security association. 'dynamic' does not apply to CMs running in BPI mode. Unicast BPI TEKs must utilize the 'primary' encoding, and multicast BPI TEKs must utilize the 'static' encoding. By default, SNMP created entries set this object to 'static' if not set at row creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 2.1.3." ::= { docsBpi2CmtsIpMulticastMapEntry 6 } docsBpi2CmtsIpMulticastDataEncryptAlg OBJECT-TYPE SYNTAX DocsBpkmDataEncryptAlg MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is the data encryption algorithm for this IP." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." DEFVAL { des56CbcMode } ::= { docsBpi2CmtsIpMulticastMapEntry 7 } docsBpi2CmtsIpMulticastDataAuthentAlg OBJECT-TYPE SYNTAX DocsBpkmDataAuthentAlg MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is the data authentication Green, et al. Standards Track [Page 54] RFC 4131 DOCSIS BPI Plus MIB September 2005 algorithm for this IP." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.2.20." DEFVAL { none } ::= { docsBpi2CmtsIpMulticastMapEntry 8 } docsBpi2CmtsIpMulticastSAMapRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has received an SA Map Request message for this IP. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.10." ::= { docsBpi2CmtsIpMulticastMapEntry 9 } docsBpi2CmtsIpMulticastSAMapReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an SA Map Reply message for this IP. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.11." ::= { docsBpi2CmtsIpMulticastMapEntry 10 } docsBpi2CmtsIpMulticastSAMapRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the number of times the CMTS has transmitted an SA Map Reject message for this IP. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other Green, et al. Standards Track [Page 55] RFC 4131 DOCSIS BPI Plus MIB September 2005 times as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.2.1.12." ::= { docsBpi2CmtsIpMulticastMapEntry 11 } docsBpi2CmtsIpMulticastSAMapRejectErrorCode OBJECT-TYPE SYNTAX INTEGER { none(1), unknown(2), noAuthForRequestedDSFlow(9), dsFlowNotMappedToSA(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the enumerated description of the Error-Code in the most recent SA Map Reject message sent in response to an SA Map Request for this IP. It has the value unknown(2) if the last Error-Code Value was 0 and none(1) if no SA MAP Reject message has been received since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.12 and 4.2.2.15." ::= { docsBpi2CmtsIpMulticastMapEntry 12 } docsBpi2CmtsIpMulticastSAMapRejectErrorString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the text string in the most recent SA Map Reject message sent in response to an SA Map Request for this IP. It is a zero length string if no SA Map Reject message has been received since entry creation." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections 4.2.1.12 and 4.2.2.6." ::= { docsBpi2CmtsIpMulticastMapEntry 13 } docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Green, et al. Standards Track [Page 56] RFC 4131 DOCSIS BPI Plus MIB September 2005 "This object controls and reflects the IP multicast address mapping entry. There is no restriction on the ability to change values in this row while the row is active. A created row can be set to active only after the Corresponding instances of docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId, and docsBpi2CmtsIpMulticastSAType have all been set." ::= { docsBpi2CmtsIpMulticastMapEntry 14 } docsBpi2CmtsIpMulticastMapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." ::= { docsBpi2CmtsIpMulticastMapEntry 15 } -- -- The CMTS Multicast SAID Authorization Table, -- indexed by ifIndex by -- multicast SAID by CM MAC address -- docsBpi2CmtsMulticastAuthTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmtsMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the multicast SAID authorization for each CM on each CMTS MAC interface." ::= { docsBpi2CmtsMulticastObjects 2 } docsBpi2CmtsMulticastAuthEntry OBJECT-TYPE SYNTAX DocsBpi2CmtsMulticastAuthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains objects describing the key authorization of one cable modem for one multicast SAID for one CMTS MAC interface. Row entries persist after re-initialization of the managed system." INDEX { ifIndex, docsBpi2CmtsMulticastAuthSAId, docsBpi2CmtsMulticastAuthCmMacAddress } ::= { docsBpi2CmtsMulticastAuthTable 1 } Green, et al. Standards Track [Page 57] RFC 4131 DOCSIS BPI Plus MIB September 2005 DocsBpi2CmtsMulticastAuthEntry ::= SEQUENCE { docsBpi2CmtsMulticastAuthSAId DocsSAId, docsBpi2CmtsMulticastAuthCmMacAddress MacAddress, docsBpi2CmtsMulticastAuthControl RowStatus } docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE SYNTAX DocsSAId MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the multicast SAID for authorization." ::= { docsBpi2CmtsMulticastAuthEntry 1 } docsBpi2CmtsMulticastAuthCmMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the MAC address of the CM to which the multicast SAID authorization applies." ::= { docsBpi2CmtsMulticastAuthEntry 2 } docsBpi2CmtsMulticastAuthControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row for the authorization of multicast SAIDs to CMs." ::= { docsBpi2CmtsMulticastAuthEntry 3 } -- -- CMTS Cert Objects -- docsBpi2CmtsCertObjects OBJECT IDENTIFIER ::= { docsBpi2CmtsObjects 5 } -- -- CMTS Provisioned CM Cert Table -- docsBpi2CmtsProvisionedCmCertTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmtsProvisionedCmCertEntry Green, et al. Standards Track [Page 58] RFC 4131 DOCSIS BPI Plus MIB September 2005 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of CM certificate trust entries provisioned to the CMTS. The trust object for a certificate in this table has an overriding effect on the validity object of a certificate in the authorization table, as long as the entire contents of the two certificates are identical." ::= { docsBpi2CmtsCertObjects 1 } docsBpi2CmtsProvisionedCmCertEntry OBJECT-TYPE SYNTAX DocsBpi2CmtsProvisionedCmCertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the CMTS's provisioned CM certificate table. Row entries persist after re-initialization of the managed system." REFERENCE "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I05-040407, Section 6.2.14" INDEX { docsBpi2CmtsProvisionedCmCertMacAddress } ::= { docsBpi2CmtsProvisionedCmCertTable 1 } DocsBpi2CmtsProvisionedCmCertEntry ::= SEQUENCE { docsBpi2CmtsProvisionedCmCertMacAddress MacAddress, docsBpi2CmtsProvisionedCmCertTrust INTEGER, docsBpi2CmtsProvisionedCmCertSource INTEGER, docsBpi2CmtsProvisionedCmCertStatus RowStatus, docsBpi2CmtsProvisionedCmCert DocsX509ASN1DEREncodedCertificate } docsBpi2CmtsProvisionedCmCertMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this row." ::= { docsBpi2CmtsProvisionedCmCertEntry 1 } docsBpi2CmtsProvisionedCmCertTrust OBJECT-TYPE SYNTAX INTEGER { trusted(1), untrusted(2) } Green, et al. Standards Track [Page 59] RFC 4131 DOCSIS BPI Plus MIB September 2005 MAX-ACCESS read-create STATUS current DESCRIPTION "Trust state for the provisioned CM certificate entry. Note: Setting this object need only override the validity of CM certificates sent in future authorization requests; instantaneous effect need not occur." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.1." DEFVAL { untrusted } ::= { docsBpi2CmtsProvisionedCmCertEntry 2 } docsBpi2CmtsProvisionedCmCertSource OBJECT-TYPE SYNTAX INTEGER { snmp(1), configurationFile(2), externalDatabase(3), other(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates how the certificate reached the CMTS. Other(4) means that it originated from a source not identified above." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.1." ::= { docsBpi2CmtsProvisionedCmCertEntry 3 } docsBpi2CmtsProvisionedCmCertStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. Values in this row cannot be changed while the row is 'active'." ::= { docsBpi2CmtsProvisionedCmCertEntry 4 } docsBpi2CmtsProvisionedCmCert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-create STATUS current DESCRIPTION "An X509 DER-encoded Certificate Authority certificate. Note: The zero-length OCTET STRING must be returned, on Green, et al. Standards Track [Page 60] RFC 4131 DOCSIS BPI Plus MIB September 2005 reads, if the entire certificate is not retained in the CMTS." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.2." ::= { docsBpi2CmtsProvisionedCmCertEntry 5 } -- -- CMTS CA Cert Table -- docsBpi2CmtsCACertTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsBpi2CmtsCACertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of known Certificate Authority certificates acquired by this device." ::= { docsBpi2CmtsCertObjects 2 } docsBpi2CmtsCACertEntry OBJECT-TYPE SYNTAX DocsBpi2CmtsCACertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the Certificate Authority certificate table. Row entries with the trust status 'trusted', 'untrusted', or 'root' persist after re-initialization of the managed system." REFERENCE "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I05-040407, Section 6.2.14" INDEX { docsBpi2CmtsCACertIndex } ::= {docsBpi2CmtsCACertTable 1 } DocsBpi2CmtsCACertEntry ::= SEQUENCE { docsBpi2CmtsCACertIndex Unsigned32, docsBpi2CmtsCACertSubject SnmpAdminString, docsBpi2CmtsCACertIssuer SnmpAdminString, docsBpi2CmtsCACertSerialNumber OCTET STRING, docsBpi2CmtsCACertTrust INTEGER, docsBpi2CmtsCACertSource INTEGER, docsBpi2CmtsCACertStatus RowStatus, docsBpi2CmtsCACert DocsX509ASN1DEREncodedCertificate, docsBpi2CmtsCACertThumbprint OCTET STRING } Green, et al. Standards Track [Page 61] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsCACertIndex OBJECT-TYPE SYNTAX Unsigned32 (1.. 4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this row." ::= { docsBpi2CmtsCACertEntry 1 } docsBpi2CmtsCACertSubject OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The subject name exactly as it is encoded in the X509 certificate. The organizationName portion of the certificate's subject name must be present. All other fields are optional. Any optional field present must be prepended with (carriage return, U+000D) (line feed, U+000A). Ordering of fields present must conform to the following: organizationName countryName stateOrProvinceName localityName organizationalUnitName organizationalUnitName= commonName" REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.2.4" ::= { docsBpi2CmtsCACertEntry 2 } docsBpi2CmtsCACertIssuer OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The issuer name exactly as it is encoded in the X509 certificate. The commonName portion of the certificate's issuer name must be present. All other fields are optional. Any optional field present must be prepended with (carriage return, U+000D) (line feed, U+000A). Ordering of fields present must conform to the following: CommonName countryName Green, et al. Standards Track [Page 62] RFC 4131 DOCSIS BPI Plus MIB September 2005 stateOrProvinceName localityName organizationName organizationalUnitName organizationalUnitName=" REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.2.4" ::= { docsBpi2CmtsCACertEntry 3 } docsBpi2CmtsCACertSerialNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "This CA certificate's serial number, represented as an octet string." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.2.2" ::= { docsBpi2CmtsCACertEntry 4 } docsBpi2CmtsCACertTrust OBJECT-TYPE SYNTAX INTEGER { trusted (1), untrusted (2), chained (3), root (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the trust status of this certificate. Root certificates must be given root(4) trust; manufacturer certificates must not be given root(4) trust. Trust on root certificates must not change. Note: Setting this object need only affect the validity of CM certificates sent in future authorization requests; instantaneous effect need not occur." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.1" DEFVAL { chained } ::= { docsBpi2CmtsCACertEntry 5 } docsBpi2CmtsCACertSource OBJECT-TYPE SYNTAX INTEGER { snmp (1), Green, et al. Standards Track [Page 63] RFC 4131 DOCSIS BPI Plus MIB September 2005 configurationFile (2), externalDatabase (3), other (4), authentInfo (5), compiledIntoCode (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates how the certificate reached the CMTS. Other(4) means that it originated from a source not identified above." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.1" ::= { docsBpi2CmtsCACertEntry 6 } docsBpi2CmtsCACertStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. An attempt to set writable columnar values while this row is active behaves as follows: - Sets to the object docsBpi2CmtsCACertTrust are allowed. - Sets to the object docsBpi2CmtsCACert will return an error of 'inconsistentValue'. A newly created entry cannot be set to active until the value of docsBpi2CmtsCACert is being set." ::= { docsBpi2CmtsCACertEntry 7 } docsBpi2CmtsCACert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-create STATUS current DESCRIPTION "An X509 DER-encoded Certificate Authority certificate. To help identify certificates, either this object or docsBpi2CmtsCACertThumbprint must be returned by a CMTS for self-signed CA certificates. Note: The zero-length OCTET STRING must be returned, on reads, if the entire certificate is not retained in the CMTS." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Green, et al. Standards Track [Page 64] RFC 4131 DOCSIS BPI Plus MIB September 2005 Section 9.2." ::= { docsBpi2CmtsCACertEntry 8 } docsBpi2CmtsCACertThumbprint OBJECT-TYPE SYNTAX OCTET STRING (SIZE (20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SHA-1 hash of a CA certificate. To help identify certificates, either this object or docsBpi2CmtsCACert must be returned by a CMTS for self-signed CA certificates. Note: The zero-length OCTET STRING must be returned, on reads, if the CA certificate thumb print is not retained in the CMTS." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 9.4.3" ::= { docsBpi2CmtsCACertEntry 9 } -- -- Authenticated Software Download Objects -- -- -- Note: the authenticated software download objects are a -- CM requirement only. -- docsBpi2CodeDownloadControl OBJECT IDENTIFIER ::= { docsBpi2MIBObjects 4 } docsBpi2CodeDownloadStatusCode OBJECT-TYPE SYNTAX INTEGER { configFileCvcVerified (1), configFileCvcRejected (2), snmpCvcVerified (3), snmpCvcRejected (4), codeFileVerified (5), codeFileRejected (6), other (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value indicates the result of the latest config file CVC verification, SNMP CVC verification, or code file Green, et al. Standards Track [Page 65] RFC 4131 DOCSIS BPI Plus MIB September 2005 verification." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Sections D.3.3.2 and D.3.5.1." ::= { docsBpi2CodeDownloadControl 1 } docsBpi2CodeDownloadStatusString OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the additional information to the status code. The value will include the error code and error description, which will be defined separately." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.7" ::= { docsBpi2CodeDownloadControl 2 } docsBpi2CodeMfgOrgName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the device manufacturer's organizationName." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.2.2." ::= { docsBpi2CodeDownloadControl 3 } docsBpi2CodeMfgCodeAccessStart OBJECT-TYPE SYNTAX DateAndTime (SIZE(11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the device manufacturer's current codeAccessStart value. This value will always refer to Greenwich Mean Time (GMT), and the value format must contain TimeZone information (fields 8-10)." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.2.2." ::= { docsBpi2CodeDownloadControl 4 } docsBpi2CodeMfgCvcAccessStart OBJECT-TYPE SYNTAX DateAndTime (SIZE(11)) Green, et al. Standards Track [Page 66] RFC 4131 DOCSIS BPI Plus MIB September 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the device manufacturer's current cvcAccessStart value. This value will always refer to Greenwich Mean Time (GMT), and the value format must contain TimeZone information (fields 8-10)." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.2.2." ::= { docsBpi2CodeDownloadControl 5 } docsBpi2CodeCoSignerOrgName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the co-signer's organizationName. The value is a zero length string if the co-signer is not specified." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.2.2." ::= { docsBpi2CodeDownloadControl 6 } docsBpi2CodeCoSignerCodeAccessStart OBJECT-TYPE SYNTAX DateAndTime (SIZE(11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the co-signer's current codeAccessStart value. This value will always refer to Greenwich Mean Time (GMT), and the value format must contain TimeZone information (fields 8-10). If docsBpi2CodeCoSignerOrgName is a zero length string, the value of this object is meaningless." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.2.2." ::= { docsBpi2CodeDownloadControl 7 } docsBpi2CodeCoSignerCvcAccessStart OBJECT-TYPE SYNTAX DateAndTime (SIZE(11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the co-signer's current cvcAccessStart value. This value will always refer to Green, et al. Standards Track [Page 67] RFC 4131 DOCSIS BPI Plus MIB September 2005 Greenwich Mean Time (GMT), and the value format must contain TimeZone information (fields 8-10). If docsBpi2CodeCoSignerOrgName is a zero length string, the value of this object is meaningless." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.2.2." ::= { docsBpi2CodeDownloadControl 8 } docsBpi2CodeCvcUpdate OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-write STATUS current DESCRIPTION "Setting a CVC to this object triggers the device to verify the CVC and update the cvcAccessStart values. The content of this object is then discarded. If the device is not enabled to upgrade codefiles, or if the CVC verification fails, the CVC will be rejected. Reading this object always returns the zero-length OCTET STRING." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section D.3.3.2.2." ::= { docsBpi2CodeDownloadControl 9 } -- -- The BPI+ MIB Conformance Statements (with a placeholder for -- notifications) -- docsBpi2Notification OBJECT IDENTIFIER ::= { docsBpi2MIB 0 } docsBpi2Conformance OBJECT IDENTIFIER ::= { docsBpi2MIB 2 } docsBpi2Compliances OBJECT IDENTIFIER ::= { docsBpi2Conformance 1 } docsBpi2Groups OBJECT IDENTIFIER ::= { docsBpi2Conformance 2 } docsBpi2CmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This is the compliance statement for CMs that implement the DOCSIS Baseline Privacy Interface Plus." MODULE -- docsBpi2MIB Green, et al. Standards Track [Page 68] RFC 4131 DOCSIS BPI Plus MIB September 2005 -- unconditionally mandatory group MANDATORY-GROUPS { docsBpi2CmGroup, docsBpi2CodeDownloadGroup } -- constrain on Encryption algorithms OBJECT docsBpi2CmTEKDataEncryptAlg SYNTAX DocsBpkmDataEncryptAlg { none(0), des56CbcMode(1), des40CbcMode(2) } DESCRIPTION "It is compliant to support des56CbcMode(1) and des40CbcMode(2) for data encryption algorithms." -- constrain on Integrity algorithms OBJECT docsBpi2CmTEKDataAuthentAlg SYNTAX DocsBpkmDataAuthentAlg { none(0) } DESCRIPTION "It is compliant to not support data message authentication algorithms." -- constrain on IP addressing OBJECT docsBpi2CmIpMulticastAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses. Support for other address types may be defined in future versions of this MIB module." -- constrain on IP addressing OBJECT docsBpi2CmIpMulticastAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses Other address types support may be defined in future versions of this MIB module." -- constrain on Encryption algorithms OBJECT docsBpi2CmCryptoSuiteDataEncryptAlg SYNTAX DocsBpkmDataEncryptAlg { none(0), des56CbcMode(1), des40CbcMode(2) Green, et al. Standards Track [Page 69] RFC 4131 DOCSIS BPI Plus MIB September 2005 } DESCRIPTION "It is compliant to only support des56CbcMode(1) and des40CbcMode(2) for data encryption algorithms." -- constrain on Integrity algorithms OBJECT docsBpi2CmCryptoSuiteDataAuthentAlg SYNTAX DocsBpkmDataAuthentAlg { none(0) } DESCRIPTION "It is compliant to not support data message authentication algorithms." ::= { docsBpi2Compliances 1 } docsBpi2CmtsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This is the compliance statement for CMTSs that implement the DOCSIS Baseline Privacy Interface Plus." MODULE -- docsBpi2MIB -- unconditionally mandatory group MANDATORY-GROUPS { docsBpi2CmtsGroup } -- unconditionally optional group GROUP docsBpi2CodeDownloadGroup DESCRIPTION "This group is optional for CMTSes. The implementation decision of this group is left to the vendor" -- constrain on mandatory range OBJECT docsBpi2CmtsDefaultAuthLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks." -- constrain on mandatory range OBJECT docsBpi2CmtsDefaultTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION Green, et al. Standards Track [Page 70] RFC 4131 DOCSIS BPI Plus MIB September 2005 "The refined range corresponds to the minimum and maximum values in operational networks." -- constrain on mandatory range OBJECT docsBpi2CmtsAuthCmLifetime SYNTAX Integer32 (86400..6048000) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks." -- constrain on Encryption algorithms OBJECT docsBpi2CmtsTEKDataEncryptAlg SYNTAX DocsBpkmDataEncryptAlg { none(0), des56CbcMode(1), des40CbcMode(2) } DESCRIPTION "It is compliant to only support des56CbcMode(1) and des40CbcMode(2) for data encryption." -- constrain on Integrity algorithms OBJECT docsBpi2CmtsTEKDataAuthentAlg SYNTAX DocsBpkmDataAuthentAlg { none(0) } DESCRIPTION "It is compliant to not support data message authentication algorithms." -- constrain on mandatory range OBJECT docsBpi2CmtsTEKLifetime SYNTAX Integer32 (1800..604800) DESCRIPTION "The refined range corresponds to the minimum and maximum values in operational networks." -- constrain on access -- constrain on IP Addressing OBJECT docsBpi2CmtsIpMulticastAddressType SYNTAX InetAddressType { ipv4(1) } MIN-ACCESS read-only DESCRIPTION Green, et al. Standards Track [Page 71] RFC 4131 DOCSIS BPI Plus MIB September 2005 "Write access is not required. An implementation is only required to support IPv4 addresses. Support for other address types may be defined in future versions of this MIB module." OBJECT docsBpi2CmtsIpMulticastAddress SYNTAX InetAddress (SIZE(4)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 addresses. Support for other address types may be defined in future versions of this MIB module." OBJECT docsBpi2CmtsIpMulticastMask SYNTAX InetAddress (SIZE(4)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support IPv4 addresses. Support for other address types may be defined in future versions of this MIB module." -- constrain on access OBJECT docsBpi2CmtsIpMulticastSAId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT docsBpi2CmtsIpMulticastSAType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- constrain on access -- constrain on Encryption algorithms OBJECT docsBpi2CmtsIpMulticastDataEncryptAlg SYNTAX DocsBpkmDataEncryptAlg { none(0), des56CbcMode(1), des40CbcMode(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. It is compliant to only support des56CbcMode(1) Green, et al. Standards Track [Page 72] RFC 4131 DOCSIS BPI Plus MIB September 2005 and des40CbcMode(2) for data encryption" -- constrain on access -- constrain on Integrity algorithms OBJECT docsBpi2CmtsIpMulticastDataAuthentAlg SYNTAX DocsBpkmDataAuthentAlg { none(0) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. It is compliant to not support data message authentication algorithms." -- constrain on access OBJECT docsBpi2CmtsMulticastAuthControl MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { docsBpi2Compliances 2 } docsBpi2CmGroup OBJECT-GROUP OBJECTS { docsBpi2CmPrivacyEnable, docsBpi2CmPublicKey, docsBpi2CmAuthState, docsBpi2CmAuthKeySequenceNumber, docsBpi2CmAuthExpiresOld, docsBpi2CmAuthExpiresNew, docsBpi2CmAuthReset, docsBpi2CmAuthGraceTime, docsBpi2CmTEKGraceTime, docsBpi2CmAuthWaitTimeout, docsBpi2CmReauthWaitTimeout, docsBpi2CmOpWaitTimeout, docsBpi2CmRekeyWaitTimeout, docsBpi2CmAuthRejectWaitTimeout, docsBpi2CmSAMapWaitTimeout, docsBpi2CmSAMapMaxRetries, docsBpi2CmAuthentInfos, docsBpi2CmAuthRequests, docsBpi2CmAuthReplies, docsBpi2CmAuthRejects, docsBpi2CmAuthInvalids, docsBpi2CmAuthRejectErrorCode, Green, et al. Standards Track [Page 73] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmAuthRejectErrorString, docsBpi2CmAuthInvalidErrorCode, docsBpi2CmAuthInvalidErrorString, docsBpi2CmTEKSAType, docsBpi2CmTEKDataEncryptAlg, docsBpi2CmTEKDataAuthentAlg, docsBpi2CmTEKState, docsBpi2CmTEKKeySequenceNumber, docsBpi2CmTEKExpiresOld, docsBpi2CmTEKExpiresNew, docsBpi2CmTEKKeyRequests, docsBpi2CmTEKKeyReplies, docsBpi2CmTEKKeyRejects, docsBpi2CmTEKInvalids, docsBpi2CmTEKAuthPends, docsBpi2CmTEKKeyRejectErrorCode, docsBpi2CmTEKKeyRejectErrorString, docsBpi2CmTEKInvalidErrorCode, docsBpi2CmTEKInvalidErrorString, docsBpi2CmIpMulticastAddressType, docsBpi2CmIpMulticastAddress, docsBpi2CmIpMulticastSAId, docsBpi2CmIpMulticastSAMapState, docsBpi2CmIpMulticastSAMapRequests, docsBpi2CmIpMulticastSAMapReplies, docsBpi2CmIpMulticastSAMapRejects, docsBpi2CmIpMulticastSAMapRejectErrorCode, docsBpi2CmIpMulticastSAMapRejectErrorString, docsBpi2CmDeviceCmCert, docsBpi2CmDeviceManufCert, docsBpi2CmCryptoSuiteDataEncryptAlg, docsBpi2CmCryptoSuiteDataAuthentAlg } STATUS current DESCRIPTION "This collection of objects provides CM BPI+ status and control." ::= { docsBpi2Groups 1 } docsBpi2CmtsGroup OBJECT-GROUP OBJECTS { docsBpi2CmtsDefaultAuthLifetime, docsBpi2CmtsDefaultTEKLifetime, docsBpi2CmtsDefaultSelfSignedManufCertTrust, docsBpi2CmtsCheckCertValidityPeriods, docsBpi2CmtsAuthentInfos, docsBpi2CmtsAuthRequests, docsBpi2CmtsAuthReplies, Green, et al. Standards Track [Page 74] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsAuthRejects, docsBpi2CmtsAuthInvalids, docsBpi2CmtsSAMapRequests, docsBpi2CmtsSAMapReplies, docsBpi2CmtsSAMapRejects, docsBpi2CmtsAuthCmBpiVersion, docsBpi2CmtsAuthCmPublicKey, docsBpi2CmtsAuthCmKeySequenceNumber, docsBpi2CmtsAuthCmExpiresOld, docsBpi2CmtsAuthCmExpiresNew, docsBpi2CmtsAuthCmLifetime, docsBpi2CmtsAuthCmReset, docsBpi2CmtsAuthCmInfos, docsBpi2CmtsAuthCmRequests, docsBpi2CmtsAuthCmReplies, docsBpi2CmtsAuthCmRejects, docsBpi2CmtsAuthCmInvalids, docsBpi2CmtsAuthRejectErrorCode, docsBpi2CmtsAuthRejectErrorString, docsBpi2CmtsAuthInvalidErrorCode, docsBpi2CmtsAuthInvalidErrorString, docsBpi2CmtsAuthPrimarySAId, docsBpi2CmtsAuthBpkmCmCertValid, docsBpi2CmtsAuthBpkmCmCert, docsBpi2CmtsAuthCACertIndexPtr, docsBpi2CmtsTEKSAType, docsBpi2CmtsTEKDataEncryptAlg, docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsTEKLifetime, docsBpi2CmtsTEKKeySequenceNumber, docsBpi2CmtsTEKExpiresOld, docsBpi2CmtsTEKExpiresNew, docsBpi2CmtsTEKReset, docsBpi2CmtsKeyRequests, docsBpi2CmtsKeyReplies, docsBpi2CmtsKeyRejects, docsBpi2CmtsTEKInvalids, docsBpi2CmtsKeyRejectErrorCode, docsBpi2CmtsKeyRejectErrorString, docsBpi2CmtsTEKInvalidErrorCode, docsBpi2CmtsTEKInvalidErrorString, docsBpi2CmtsIpMulticastAddressType, docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId, docsBpi2CmtsIpMulticastSAType, docsBpi2CmtsIpMulticastDataEncryptAlg, docsBpi2CmtsIpMulticastDataAuthentAlg, Green, et al. Standards Track [Page 75] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsIpMulticastSAMapRequests, docsBpi2CmtsIpMulticastSAMapReplies, docsBpi2CmtsIpMulticastSAMapRejects, docsBpi2CmtsIpMulticastSAMapRejectErrorCode, docsBpi2CmtsIpMulticastSAMapRejectErrorString, docsBpi2CmtsIpMulticastMapControl, docsBpi2CmtsIpMulticastMapStorageType, docsBpi2CmtsMulticastAuthControl, docsBpi2CmtsProvisionedCmCertTrust, docsBpi2CmtsProvisionedCmCertSource, docsBpi2CmtsProvisionedCmCertStatus, docsBpi2CmtsProvisionedCmCert, docsBpi2CmtsCACertSubject, docsBpi2CmtsCACertIssuer, docsBpi2CmtsCACertSerialNumber, docsBpi2CmtsCACertTrust, docsBpi2CmtsCACertSource, docsBpi2CmtsCACertStatus, docsBpi2CmtsCACert, docsBpi2CmtsCACertThumbprint } STATUS current DESCRIPTION "This collection of objects provides CMTS BPI+ status and control." ::= { docsBpi2Groups 2 } docsBpi2CodeDownloadGroup OBJECT-GROUP OBJECTS { docsBpi2CodeDownloadStatusCode, docsBpi2CodeDownloadStatusString, docsBpi2CodeMfgOrgName, docsBpi2CodeMfgCodeAccessStart, docsBpi2CodeMfgCvcAccessStart, docsBpi2CodeCoSignerOrgName, docsBpi2CodeCoSignerCodeAccessStart, docsBpi2CodeCoSignerCvcAccessStart, docsBpi2CodeCvcUpdate } STATUS current DESCRIPTION "This collection of objects provides authenticated software download support." ::= { docsBpi2Groups 3 } END Green, et al. Standards Track [Page 76] RFC 4131 DOCSIS BPI Plus MIB September 2005 4. Acknowledgements Kaz Ozawa: Authenticated Software Download objects and general suggestions. Rich Woundy: BPI MIB and general MIB expertise. Mike St. Johns: BPI MIB and first version of BPI+ MIB. Bert Wijnen: Extensive comments in MIB syntax and accuracy. Thanks to Mike Sabin and Manson Wong for reviewing early BPI+ MIB drafts and to Jean-Francois Mule for contributing to the last versions. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Green, et al. Standards Track [Page 77] RFC 4131 DOCSIS BPI Plus MIB September 2005 [RFC2670] St. Johns, M., "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [DOCSIS] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification SP-BPI+- I11-040407", DOCSIS, April 2004, available at http://www.cablemodem.com. http://www.cablelabs.com/specifications/archives. 6. Informative References [RFC3083] Woundy, R., "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", RFC 3083, March 2001. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [DOCSIS-1.0] "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface (BPI) ANSI/SCTE 22-2 2202, Available at http://www.scte.org. [DOCSIS-1.1] "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP- OSSIv1.1-I07-030730", DOCSIS 1.1 July 2003, available at http://www.cablemodem.com. http://www.cablelabs.com/specifications/archives. [DOCSIS-2.0] "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP- OSSIv2.0-I05-040407", DOCSIS 2.0 April 2004, http://www.cablemodem.com. http://www.cablelabs.com/specifications/archives. [IANA] "Protocol Numbers and Assignment Services", IANA, http://www.iana.org/assignments/ianaiftype-mib. Green, et al. Standards Track [Page 78] RFC 4131 DOCSIS BPI Plus MIB September 2005 7. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - The following objects, if SNMP SET maliciously, could constitute denial of service or theft of service attacks or compromise the intended data privacy of users: Objects related to the Baseline Privacy Key Management (BPKM) docsBpi2CmAuthReset, docsBpi2CmtsAuthCmReset, docsBpi2CmtsTEKReset: These objects are used for initiating a re-key process. A malicious massive SET attack may cause CMTS processing overload and may compromise the service. docsBpi2CmtsDefaultAuthLifetime, docsBpi2CmtsDefaultTEKLifetime, docsBpi2CmtsAuthCmLifetime, docsBpi2CmtsTEKLifetime: To minimize the risk of malicious or unintended short periods of time when key updates may lead to degradation or denial of service, implementers are encouraged to follow these objects' range constraints, as defined in the docsBpi2CmtsCompliance MODULE-COMPLIANCE clause for operational deployments. docsBpi2CmtsDefaultSelfSignedManufCertTrust: A malicious SET in a self-signed certificate as reject message, which may constitute denial of service. This object is designed for testing purposes; therefore, it is not RECOMMENDED for use in commercial deployments [DOCSIS]. Administrators can make use of View-based Access Control (VACM) introduced in section 7.9 of [RFC3410] to restrict write access to this object. docsBpi2CmtsCheckCertValidityPeriods: A malicious SET in this object that enables the period validity and a wrong clock time in the CMTS could cause denial of service, as CM authorization requests will be rejected. Green, et al. Standards Track [Page 79] RFC 4131 DOCSIS BPI Plus MIB September 2005 For more details in the validation of CM certificates, refer to section 9 of [DOCSIS] . Objects related to the CM only: Objects in docsBpi2CmDeviceCertTable docsBpi2CmDeviceCmCert: This object is not harmful, considering that a CM received a Certificate during the manufacturing process. Therefore, the object access becomes read-only. See the object DESCRIPTION clause in section 3 for details. Objects for Secure Software Download in table docsBpi2CodeDownloadControl: docsBpi2CodeCvcUpdate: A malicious SET on this object may not constitute a risk, since the CM holds the DOCSIS root key to verify the CVC authenticity. The operator, if configured, could receive a notification for event occurrences, which may lead to detecting the source of the attack. Moreover, [DOCSIS] recommends that CMs CVC be regularly updated to minimize the risk of potential code-signing keys being compromised (e.g., by configuration file). Objects related to the CMTS only: Objects in docsBpi2CmtsProvisionedCmCertTable and docsBpi2CmtsCACertTable containing CM Certificates and Certificate Authority information, respectively: docsBpi2CmtsProvisionedCmCertTrust, docsBpi2CmtsProvisionedCmCertStatus, docsBpi2CmtsProvisionedCmCert, docsBpi2CmtsCACertStatus, docsBpi2CmtsCACert: A malicious SET on these objects may constitute a denial of service attack that will be experienced after the CMs perform authorization requests. It does not affect CMs in the authorized state. Objects in multicast tables docsBpi2CmtsIpMulticastMapTable and docsBpi2CmtsMulticastAuthTable: docsBpi2CmtsIpMulticastAddressType, docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMaskType, Green, et al. Standards Track [Page 80] RFC 4131 DOCSIS BPI Plus MIB September 2005 docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId, docsBpi2CmtsIpMulticastSAType: Malicious SET on these objects may cause misconfiguration, causing interruption of the users' active multicast applications. docsBpi2CmtsIpMulticastDataEncryptAlg, docsBpi2CmtsIpMulticastDataAuthentAlg: Malicious SETs on these objects may create service misconfiguration, causing service interruption or theft of service if encryption algorithms are removed for the multicast groups. docsBpi2CmtsIpMulticastMapControl, docsBpi2CmtsMulticastAuthControl: Malicious SETs on these objects may remove and/or disable customers and/or multicast groups, causing service disruption. This may also constitute theft of service by authorizing non- subscribed users to multicast groups or by adding other multicast groups in the forward path. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Objects in docsBpi2CmBaseTable, docsBpi2CmTEKTable, docsBpi2CmtsBaseTable, docsBpi2CmtsAuthTable, docsBpi2CmtsTEKTable, docsBpi2CmtsProvisionedCmCertTable, and docsBpi2CmtsCACertTable: If this information is accessible, attackers may use it to distinguish users configured to work without data encryption (e.g., docsBpi2CmPrivacyEnable) and to know current Baseline Privacy parameters in the network. Objects in docsBpi2CmIpMulticastMapTable and docsBpi2CmtsMulticastAuthTable: In addition to the vulnerabilities around BPI plus multicast objects described in the previous part, the read-only objects of this table may help attackers monitor the status of the intrusion. Green, et al. Standards Track [Page 81] RFC 4131 DOCSIS BPI Plus MIB September 2005 Objects in docsBpi2CodeDownloadControl: In addition to the vulnerability of the read-write object docsBpi2CodeCvcUpdate, attackers may be able to monitor the status of a denial of service using Secure Software Download. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. BPI+ Encryption Algorithms: The BPI+ Traffic Encryption Keys (TEK) defined in the DOCSIS BPI+ specification [DOCSIS] use 40-bit or 56-bit DES for encryption (DES CBC mode). Currently, there is no mechanism or algorithm defined for data integrity. Due to the DES cryptographic weaknesses, future revisions of the DOCSIS BPI+ specification should introduce more advanced encryption algorithms, as proposed in the DocsBpkmDataEncryptAlg textual convention, to overcome the progress in cheaper and faster hardware or software decryption tools. Future revisions of the DOCSIS BPI+ specification [DOCSIS] should also adopt authentication algorithms, as described in the DocsBpkmDataAuthentAlg textual convention. It is important to note that frequent key changes do not necessarily help in mitigating or reducing the risks of a DES attack. Indeed, the traffic encryption keys, which are configured on a per cable modem basis and per BPI+ multicast group, can be utilized to decrypt old traffic, even when they are no longer in active use. Green, et al. Standards Track [Page 82] RFC 4131 DOCSIS BPI Plus MIB September 2005 Note that, not exempt to the same recommendations above, the CM BPI+ authorization protocol uses triple DES encryption, which offers improved robustness in comparison to DES for CM authorization and TEK re-key management. 8. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value, recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER Value ---------- ----------------------- docsBpi2MIB { mib-2 126 } Green, et al. Standards Track [Page 83] RFC 4131 DOCSIS BPI Plus MIB September 2005 Authors' Addresses Stuart M. Green EMail: rubbersoul3@yahoo.com Kaz Ozawa Automotive Systems Development Center TOSHIBA CORPORATION 1-1, Shibaura 1-Chome Minato-ku, Tokyo 105-8001 Japan Phone: +81-3-3457-8569 Fax: +81-3-5444-9325 EMail: Kazuyoshi.Ozawa@toshiba.co.jp Alexander Katsnelson Phone: +1-303-680-3924 EMail: katsnelson6@peoplepc.com Eduardo Cardona Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80027- 9750 U.S.A. Phone: +1 303 661 9100 EMail: e.cardona@cablelabs.com Green, et al. Standards Track [Page 84] RFC 4131 DOCSIS BPI Plus MIB September 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Green, et al. Standards Track [Page 85] snmp-mibs-downloader-1.1/mibrfcs/rfc4133.txt0000644000000000000000000041300711402176072015562 0ustar Network Working Group A. Bierman Request for Comments: 4133 K. McCloghrie Obsoletes: 2737 Cisco Systems, Inc. Category: Standards Track August 2005 Entity MIB (Version 3) 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). Bierman & McCloghrie Standards Track [Page 1] RFC 4133 Entity MIB (Version 3) August 2005 Table of Contents 1. The SNMP Management Framework ...................................3 2. Overview ........................................................3 2.1. Terms ......................................................4 2.2. Relationship to Community Strings ..........................5 2.3. Relationship to SNMP Contexts ..............................5 2.4. Relationship to Proxy Mechanisms ...........................6 2.5. Relationship to a Chassis MIB ..............................6 2.6. Relationship to the Interfaces MIB .........................6 2.7. Relationship to the Other MIBs .............................7 2.8. Relationship to Naming Scopes ..............................7 2.9. Multiple Instances of the Entity MIB .......................7 2.10. Re-Configuration of Entities ..............................8 2.11. Textual Convention Change .................................8 2.12. MIB Structure .............................................8 2.12.1. entityPhysical Group ..............................9 2.12.2. entityLogical Group ..............................11 2.12.3. entityMapping Group ..............................11 2.12.4. entityGeneral Group ..............................12 2.12.5. entityNotifications Group ........................12 2.13. Multiple Agents ..........................................12 2.14. Changes Since RFC 2037 ...................................12 2.14.1. Textual Conventions ..............................12 2.14.2. New entPhysicalTable Objects .....................13 2.14.3. New entLogicalTable Objects ......................13 2.14.4. Bug Fixes ........................................13 2.15. Changes Since RFC 2737 ...................................13 2.15.1. Textual Conventions ..............................13 2.15.2. New Objects ......................................14 2.15.3. Bug Fixes ........................................14 3. Definitions ....................................................14 4. Usage Examples .................................................44 4.1. Router/Bridge .............................................44 4.2. Repeaters .................................................50 5. Security Considerations ........................................57 6. IANA Considerations ............................................58 7. Acknowledgements ...............................................59 8. References .....................................................59 8.1. Normative References ......................................59 8.2. Informative References ....................................59 Bierman & McCloghrie Standards Track [Page 2] RFC 4133 Entity MIB (Version 3) August 2005 1. The SNMP Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview There is a need for a standardized way of representing a single agent, which supports multiple instances of one MIB. This is presently true for at least 3 standard MIBs, and is likely to become true for more and more MIBs as time passes. For example: - multiple instances of a bridge supported within a single device that has a single agent; - multiple repeaters supported by a single agent; - multiple OSPF backbone areas, each operating as part of its own Autonomous System, and each identified by the same area-id (e.g., 0.0.0.0), supported inside a single router with one agent. The single agent present in each of these cases implies a relationship binds these entities. Effectively, there is some "overall" physical entity which houses the sum of the things managed by that one agent, i.e., there are multiple "logical" entities within a single physical entity. Sometimes, the overall physical entity contains multiple (smaller) physical entities, and each logical entity is associated with a particular physical entity. Sometimes, the overall physical entity is a "compound" of multiple physical entities (e.g., a stack of stackable hubs). What is needed is a way to determine exactly which logical entities are managed by the agent (with some version of SNMP) in order to communicate with the agent about a particular logical entity. When different logical entities are associated with different physical entities within the overall physical entity, it is also useful to be able to use this information to distinguish between logical entities. Bierman & McCloghrie Standards Track [Page 3] RFC 4133 Entity MIB (Version 3) August 2005 In these situations, there is no need for varbinds for multiple logical entities to be referenced in the same SNMP message (although that might be useful in the future). Rather, it is sufficient, and in some situations preferable, to have the context/community in the message identify the logical entity to which the varbinds apply. Version 2 of this MIB addresses new requirements, which have emerged since the publication of the first Entity MIB (RFC 2037 [RFC2037]). There is a need for a standardized way of providing non-volatile, administratively-assigned identifiers for physical components represented with the Entity MIB. There is also a need to align the Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 3411 [RFC3411]). Implementation experience has shown that additional physical component attributes are also desirable. Version 3 of this MIB addresses new requirements, which have emerged since the publication of the second Entity MIB (RFC 2737 [RFC2737]). There is a need to identify physical entities that are central processing units (CPUs) and a need to provide a textual convention that identifies an entPhysicalIndex value or zero, where the value zero has application-specific semantics. Two new objects have been added to the entPhysicalTable to identify the manufacturing date and provide additional URIs for a particular physical entity. 2.1. Terms Some new terms are used throughout this document: - Naming Scope A "naming scope" represents the set of information that may be potentially accessed through a single SNMP operation. All instances within the naming scope share the same unique identifier space. For SNMPv1, a naming scope is identified by the value of the associated 'entLogicalCommunity' instance. For SNMPv3, the term 'context' is used instead of 'naming scope'. The complete definition of an SNMP context can be found in section 3.3.1 of RFC 3411 [RFC3411]. - Multi-Scoped Object A MIB object, for which identical instance values identify different managed information in different naming scopes, is called a "multi-scoped" MIB object. - Single-Scoped Object A MIB object, for which identical instance values identify the same managed information in different naming scopes, is called a "single-scoped" MIB object. Bierman & McCloghrie Standards Track [Page 4] RFC 4133 Entity MIB (Version 3) August 2005 - Logical Entity A managed system contains one or more logical entities, each represented by at most one instantiation of each of a particular set of MIB objects. A set of management functions is associated with each logical entity. Examples of logical entities include routers, bridges, print-servers, etc. - Physical Entity A "physical entity" or "physical component" represents an identifiable physical resource within a managed system. Zero or more logical entities may utilize a physical resource at any given time. Determining which physical components are represented by an agent in the EntPhysicalTable is an implementation-specific matter. Typically, physical resources (e.g., communications ports, backplanes, sensors, daughter-cards, power supplies, the overall chassis), which can be managed via functions associated with one or more logical entities, are included in the MIB. - Containment Tree Each physical component may be modeled as 'contained' within another physical component. A "containment-tree" is the conceptual sequence of entPhysicalIndex values that uniquely specifies the exact physical location of a physical component within the managed system. It is generated by 'following and recording' each 'entPhysicalContainedIn' instance 'up the tree towards the root', until a value of zero indicating no further containment is found. 2.2. Relationship to Community Strings For community-based SNMP, differentiating logical entities is one (but not the only) purpose of the community string (RFC 1157 [RFC1157]). This is accommodated by representing each community string as a logical entity. Note that different logical entities may share the same naming scope and, therefore, the same values of entLogicalCommunity. This is possible, providing they have no need for the same instance of a MIB object to represent different managed information. 2.3. Relationship to SNMP Contexts Version 2 of the Entity MIB contains support for associating SNMPv3 contexts with logical entities. Two new MIB objects, defining an SnmpEngineID and ContextName pair, are used together to identify an SNMP context associated with a logical entity. This context can be used (in conjunction with the entLogicalTAddress and entLogicalTDomain MIB objects) to send SNMPv3 messages on behalf of a particular logical entity. Bierman & McCloghrie Standards Track [Page 5] RFC 4133 Entity MIB (Version 3) August 2005 2.4. Relationship to Proxy Mechanisms The Entity MIB is designed to allow functional component discovery. The administrative relationships between different logical entities are not visible in any Entity MIB tables. A Network Management System (NMS) cannot determine whether MIB instances in different naming scopes are realized locally or remotely (e.g., via some proxy mechanism) by examining any particular Entity MIB objects. The management of administrative framework functions is not an explicit goal of the Entity MIB WG at this time. This new area of functionality may be revisited after some operational experience with the Entity MIB is gained. Note that for community-based versions of SNMP, a network administrator will likely be able to associate community strings with naming scopes that have proprietary mechanisms, as a matter of configuration. There are no mechanisms for managing naming scopes defined in this MIB. 2.5. Relationship to a Chassis MIB Some readers may recall that a previous IETF working group attempted to define a Chassis MIB. No consensus was reached by that working group, possibly because its scope was too broad. As such, it is not the purpose of this MIB to be a "Chassis MIB replacement", nor is it within the scope of this MIB to contain all the information which might be necessary to manage a "chassis". On the other hand, the entities represented by an implementation of this MIB might well be contained in a chassis. 2.6. Relationship to the Interfaces MIB The Entity MIB contains a mapping table identifying physical components that have 'external values' (e.g., ifIndex) associated with them within a given naming scope. This table can be used to identify the physical location of each interface in the ifTable (RFC 2863 [RFC2863]). Because ifIndex values in different contexts are not related to one another, the interface to physical component associations are relative to the same logical entity within the agent. The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias' objects, which approximate the semantics of the 'ifName' and 'ifAlias' objects (respectively) from the Interfaces MIB [RFC2863], for all types of physical components. Bierman & McCloghrie Standards Track [Page 6] RFC 4133 Entity MIB (Version 3) August 2005 2.7. Relationship to the Other MIBs The Entity MIB contains a mapping table identifying physical components that have identifiers from other standard MIBs associated with them. For example, this table can be used along with the physical mapping table to identify the physical location of each repeater port in the rptrPortTable, or each interface in the ifTable. 2.8. Relationship to Naming Scopes There is some question as to which MIB objects may be returned within a given naming scope. MIB objects which are not multi-scoped within a managed system are likely to ignore context information in implementation. In such a case, it is likely such objects will be returned in all naming scopes (e.g., not just the 'default' naming scope or the SNMPv3 default context). For example, a community string used to access the management information for logical device 'bridge2' may allow access to all the non-bridge related objects in the 'default' naming scope, as well as a second instance of the Bridge MIB (RFC 1493 [RFC1493]). The isolation of single-scoped MIB objects by the agent is an implementation-specific matter. An agent may wish to limit the objects returned in a particular naming scope to only the multi- scoped objects in that naming scope (e.g., system group and the Bridge MIB). In this case, all single-scoped management information would belong to a common naming scope (e.g., 'default'), which itself may contain some multi-scoped objects (e.g., system group). 2.9. Multiple Instances of the Entity MIB It is possible that more than one agent may exist in a managed system. In such cases, multiple instances of the Entity MIB (representing the same managed objects) may be available to an NMS. In order to reduce complexity for agent implementation, multiple instances of the Entity MIB are not required to be equivalent or even consistent. An NMS may be able to 'align' instances returned by different agents by examining the columns of each table, but vendor- specific identifiers and (especially) index values are likely to be different. Each agent may be managing different subsets of the entire chassis as well. When all of a physically-modular device is represented by a single agent, the entry (for which entPhysicalContainedIn has the value zero) would likely have 'chassis' as the value of its entPhysicalClass. Alternatively, for an agent on a module where the Bierman & McCloghrie Standards Track [Page 7] RFC 4133 Entity MIB (Version 3) August 2005 agent represents only the physical entities on that module (not those on other modules), the entry (for which entPhysicalContainedIn has the value zero) would likely have 'module' as the value of its entPhysicalClass. An agent implementation of the entLogicalTable is not required to contain information about logical entities managed primarily by other agents. That is, the entLogicalTAddress and entLogicalTDomain objects in the entLogicalTable are provided to support an historical multiplexing mechanism, not to identify other SNMP agents. Note that the Entity MIB is a single-scoped MIB, in the event an agent represents the MIB in different naming scopes. 2.10. Re-Configuration of Entities Most of the MIB objects defined in this MIB have, at most, a read- only MAX-ACCESS clause. This is a conscious decision by the working group to limit this MIB's scope. The second version of the Entity MIB allows a network administrator to configure some common attributes of physical components. 2.11. Textual Convention Change Version 1 of the Entity MIB contains three MIB objects defined with the (now obsolete) DisplayString textual convention. In version 2 of the Entity MIB, the syntax for these objects has been updated to use the (now preferred) SnmpAdminString textual convention. The working group realizes that this change is not strictly supported by SMIv2. In our judgment, the alternative of deprecating the old objects and defining new objects would have a more adverse impact on backward compatibility and interoperability, given the particular semantics of these objects. 2.12. MIB Structure The Entity MIB contains five groups of MIB objects: - entityPhysical group Describes the physical entities managed by a single agent. - entityLogical group Describes the logical entities managed by a single agent. Bierman & McCloghrie Standards Track [Page 8] RFC 4133 Entity MIB (Version 3) August 2005 - entityMapping group Describes the associations between the physical entities, logical entities, interfaces, and non-interface ports managed by a single agent. - entityGeneral group Describes general system attributes shared by potentially all types of entities managed by a single agent. - entityNotifications group Contains status indication notifications. 2.12.1. entityPhysical Group This group contains a single table to identify physical system components, called the entPhysicalTable. The entPhysicalTable contains one row per physical entity, and must always contain at least one row for an "overall" physical entity, which should have an entPhysicalClass value of 'stack(11)', 'chassis(3)' or 'module(9)'. Each row is indexed by an arbitrary, small integer, and contains a description and type of the physical entity. It also optionally contains the index number of another entPhysicalEntry, indicating a containment relationship between the two. Version 2 of the Entity MIB provides additional MIB objects for each physical entity. Some common read-only attributes have been added, as well as three writable string objects. - entPhysicalAlias This string can be used by an NMS as a non-volatile identifier for the physical component. Maintaining a non-volatile string for every physical component represented in the entPhysicalTable can be costly and unnecessary. An agent may algorithmically generate 'entPhysicalAlias' strings for particular entries (e.g., based on the entPhysicalClass value). - entPhysicalAssetID This string is provided to store a user-specific asset identifier for removable physical components. In order to reduce the non- volatile storage needed by a particular agent, a network administrator should only assign asset identifiers to physical entities that are field-replaceable (i.e., not permanently contained within another physical entity). Bierman & McCloghrie Standards Track [Page 9] RFC 4133 Entity MIB (Version 3) August 2005 - entPhysicalSerialNum This string is provided to store a vendor-specific serial number string for physical components. This writable object is used when an agent cannot identify the serial numbers of all installed physical entities, and a network administrator wishes to configure the non-volatile serial number strings manually (via an NMS application). Version 3 of the Entity MIB provides two additional MIB objects for each physical entity: - entPhysicalMfgDate This object contains the date of manufacturing of the managed entity. If the manufacturing date is unknown or not supported the object is not instantiated. The special value '0000000000000000'H may also be returned in this case. - entPhysicalUris This object provides additional identification information about the physical entity. This object contains one or more Uniform Resource Identifiers (URIs) and, therefore, the syntax of this object must conform to RFC 3986 [RFC3986] section 2. Uniform Resource Names (URNs), RFC 3406 [RFC3406], are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. URNs are part of the larger URI family with the specific goal of providing persistent naming of resources. URI schemes and URN name spaces are registered by IANA (see http://www.iana.org/assignments/uri-schemes and http://www.iana.org/assignments/urn-namespaces). For example, the entPhysicalUris object may be used to encode a URI containing a Common Language Equipment Identifier (CLEI) URN for the managed physical entity. The URN name space for CLEIs is defined in [RFC4152], and the CLEI format is defined in [T1.213][T1.213a]. For example, an entPhysicalUris instance may have the value of URN:CLEI:D4CE18B7AA [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN name space. The specific CLEI code, D4CE18B7AA, is based on the example provided in [T1.213a]. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. Bierman & McCloghrie Standards Track [Page 10] RFC 4133 Entity MIB (Version 3) August 2005 If no additional identification information is known about the physical entity or supported, the object is not instantiated. 2.12.2. entityLogical Group This group contains a single table to identify logical entities, called the entLogicalTable. The entLogicalTable contains one row per logical entity. Each row is indexed by an arbitrary, small integer and contains a name, description, and type of the logical entity. It also contains information to allow access to the MIB information for the logical entity. This includes SNMP versions that use a community name (with some form of implied context representation) and SNMP versions that use the SNMP ARCH [RFC3411] method of context identification. If an agent represents multiple logical entities with this MIB, then this group must be implemented for all logical entities known to the agent. If an agent represents a single logical entity, or multiple logical entities within a single naming scope, then implementation of this group may be omitted by the agent. 2.12.3. entityMapping Group This group contains three tables to identify associations between different system components. - entLPMappingTable This table contains mappings between entLogicalIndex values (logical entities) and entPhysicalIndex values (the physical components supporting that entity). A logical entity can map to more than one physical component, and more than one logical entity can map to (share) the same physical component. If an agent represents a single logical entity, or multiple logical entities within a single naming scope, then implementation of this table may be omitted by the agent. - entAliasMappingTable This table contains mappings between entLogicalIndex, entPhysicalIndex pairs, and 'alias' object identifier values. This allows resources managed with other MIBs (e.g., repeater ports, bridge ports, physical and logical interfaces) to be identified in the physical entity hierarchy. Note that each alias identifier is only relevant in a particular naming scope. If an agent represents Bierman & McCloghrie Standards Track [Page 11] RFC 4133 Entity MIB (Version 3) August 2005 a single logical entity, or multiple logical entities within a single naming scope, then implementation of this table may be omitted by the agent. - entPhysicalContainsTable This table contains simple mappings between 'entPhysicalContainedIn' values for each container/'containee' relationship in the managed system. The indexing of this table allows an NMS to quickly discover the 'entPhysicalIndex' values for all children of a given physical entity. 2.12.4. entityGeneral Group This group contains general information relating to the other object groups. At this time, the entGeneral group contains a single scalar object (entLastChangeTime), which represents the value of sysUptime when any part of the Entity MIB configuration last changed. 2.12.5. entityNotifications Group This group contains notification definitions relating to the overall status of the Entity MIB instantiation. 2.13. Multiple Agents Even though a primary motivation for this MIB is to represent the multiple logical entities supported by a single agent, another motivation is to represent multiple logical entities supported by multiple agents (in the same "overall" physical entity). Indeed, it is implicit in the SNMP architecture that the number of agents is transparent to a network management station. However, there is no agreement at this time as to the degree of cooperation that should be expected for agent implementations. Therefore, multiple agents within the same managed system are free to implement the Entity MIB independently. (For more information, refer to Section 2.9, "Multiple Instances of the Entity MIB".) 2.14. Changes Since RFC 2037 2.14.1. Textual Conventions The PhysicalClass TC text has been clarified, and a new enumeration to support 'stackable' components has been added. The SnmpEngineIdOrNone TC has been added to support SNMPv3. Bierman & McCloghrie Standards Track [Page 12] RFC 4133 Entity MIB (Version 3) August 2005 2.14.2. New entPhysicalTable Objects The entPhysicalHardwareRev, entPhysicalFirmwareRev, and entPhysicalSoftwareRev objects have been added for revision identification. The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, and entPhysicalIsFru objects have been added for better vendor identification for physical components. In the event the agent cannot identify this information, the entPhysicalSerialNum object can be set by a management station. The entPhysicalAlias and entPhysicalAssetID objects have been added for better user component identification. These objects are intended to be set by a management station and preserved by the agent across restarts. 2.14.3. New entLogicalTable Objects The entLogicalContextEngineID and entLogicalContextName objects have been added to provide an SNMP context for SNMPv3 access on behalf of a logical entity. 2.14.4. Bug Fixes A bug was fixed in the entLogicalCommunity object. The subrange was incorrect (1..255) and is now (0..255). The description clause has also been clarified. This object is now deprecated. The entLastChangeTime object description has been changed to generalize the events that cause an update to the last change timestamp. The syntax was changed from DisplayString to SnmpAdminString for the entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. 2.15. Changes Since RFC 2737 2.15.1. Textual Conventions The PhysicalIndexOrZero TC has been added to allow objects to reference an entPhysicalIndex value or zero. The PhysicalClass TC has been extended to support a new enumeration for central processing units. Bierman & McCloghrie Standards Track [Page 13] RFC 4133 Entity MIB (Version 3) August 2005 2.15.2. New Objects The entPhysicalMfgDate object has been added to the entPhysicalTable to provide the date of manufacturing of the managed entity. The entPhysicalUris object has been added to the entPhysicalTable to provide additional identification information about the physical entity, such as a Common Language Equipment Identifier (CLEI) URN. 2.15.3. Bug Fixes The syntax was changed from INTEGER to Integer32 for the entPhysicalParentRelPos, entLogicalIndex, and entAliasLogicalIndexOrZero objects, and from INTEGER to PhysicalIndexOrZero for the entPhysicalContainedIn object. 3. Definitions ENTITY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, Integer32 FROM SNMPv2-SMI TDomain, TAddress, TEXTUAL-CONVENTION, AutonomousType, RowPointer, TimeStamp, TruthValue, DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; entityMIB MODULE-IDENTITY LAST-UPDATED "200508100000Z" ORGANIZATION "IETF ENTMIB Working Group" CONTACT-INFO " WG E-mail: entmib@ietf.org Mailing list subscription info: http://www.ietf.org/mailman/listinfo/entmib Andy Bierman ietf@andybierman.com Keith McCloghrie Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 Bierman & McCloghrie Standards Track [Page 14] RFC 4133 Entity MIB (Version 3) August 2005 +1 408-526-5260 kzm@cisco.com" DESCRIPTION "The MIB module for representing multiple logical entities supported by a single SNMP agent. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4133; see the RFC itself for full legal notices." REVISION "200508100000Z" DESCRIPTION "Initial Version of Entity MIB (Version 3). This revision obsoletes RFC 2737. Additions: - cpu(12) enumeration added to PhysicalClass TC - DISPLAY-HINT clause to PhysicalIndex TC - PhysicalIndexOrZero TC - entPhysicalMfgDate object - entPhysicalUris object Changes: - entPhysicalContainedIn SYNTAX changed from INTEGER to PhysicalIndexOrZero This version published as RFC 4133." REVISION "199912070000Z" DESCRIPTION "Initial Version of Entity MIB (Version 2). This revision obsoletes RFC 2037. This version published as RFC 2737." REVISION "199610310000Z" DESCRIPTION "Initial version (version 1), published as RFC 2037." ::= { mib-2 47 } entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } -- MIB contains four groups entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } Bierman & McCloghrie Standards Track [Page 15] RFC 4133 Entity MIB (Version 3) August 2005 -- Textual Conventions PhysicalIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An arbitrary value that uniquely identifies the physical entity. The value should be a small, positive integer. Index values for different physical entities are not necessarily contiguous." SYNTAX Integer32 (1..2147483647) PhysicalIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the PhysicalIndex convention, which defines a greater than zero value used to identify a physical entity. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) PhysicalClass ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An enumerated value which provides an indication of the general hardware type of a particular physical entity. There are no restrictions as to the number of entPhysicalEntries of each entPhysicalClass, which must be instantiated by an agent. The enumeration 'other' is applicable if the physical entity class is known, but does not match any of the supported values. The enumeration 'unknown' is applicable if the physical entity class is unknown to the agent. The enumeration 'chassis' is applicable if the physical entity class is an overall container for networking equipment. Any class of physical entity, except a stack, may be contained within a chassis; and a chassis may only be contained within a stack. Bierman & McCloghrie Standards Track [Page 16] RFC 4133 Entity MIB (Version 3) August 2005 The enumeration 'backplane' is applicable if the physical entity class is some sort of device for aggregating and forwarding networking traffic, such as a shared backplane in a modular ethernet switch. Note that an agent may model a backplane as a single physical entity, which is actually implemented as multiple discrete physical components (within a chassis or stack). The enumeration 'container' is applicable if the physical entity class is capable of containing one or more removable physical entities, possibly of different types. For example, each (empty or full) slot in a chassis will be modeled as a container. Note that all removable physical entities should be modeled within a container entity, such as field-replaceable modules, fans, or power supplies. Note that all known containers should be modeled by the agent, including empty containers. The enumeration 'powerSupply' is applicable if the physical entity class is a power-supplying component. The enumeration 'fan' is applicable if the physical entity class is a fan or other heat-reduction component. The enumeration 'sensor' is applicable if the physical entity class is some sort of sensor, such as a temperature sensor within a router chassis. The enumeration 'module' is applicable if the physical entity class is some sort of self-contained sub-system. If the enumeration 'module' is removable, then it should be modeled within a container entity, otherwise it should be modeled directly within another physical entity (e.g., a chassis or another module). The enumeration 'port' is applicable if the physical entity class is some sort of networking port, capable of receiving and/or transmitting networking traffic. The enumeration 'stack' is applicable if the physical entity class is some sort of super-container (possibly virtual), intended to group together multiple chassis entities. A stack may be realized by a 'virtual' cable, a real interconnect cable, attached to multiple chassis, or may in fact be comprised of multiple interconnect cables. A stack should not be modeled within any other physical entities, but a stack may be contained within another stack. Only chassis entities should be contained within a stack. Bierman & McCloghrie Standards Track [Page 17] RFC 4133 Entity MIB (Version 3) August 2005 The enumeration 'cpu' is applicable if the physical entity class is some sort of central processing unit." SYNTAX INTEGER { other(1), unknown(2), chassis(3), backplane(4), container(5), -- e.g., chassis slot or daughter-card holder powerSupply(6), fan(7), sensor(8), module(9), -- e.g., plug-in card or daughter-card port(10), stack(11), -- e.g., stack of multiple chassis entities cpu(12) } SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A specially formatted SnmpEngineID string for use with the Entity MIB. If an instance of an object of SYNTAX SnmpEngineIdOrNone has a non-zero length, then the object encoding and semantics are defined by the SnmpEngineID textual convention (see STD 62, RFC 3411 [RFC3411]). If an instance of an object of SYNTAX SnmpEngineIdOrNone contains a zero-length string, then no appropriate SnmpEngineID is associated with the logical entity (i.e., SNMPv3 is not supported)." SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID -- The Physical Entity Table entPhysicalTable OBJECT-TYPE SYNTAX SEQUENCE OF EntPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per physical entity. There is always at least one row for an 'overall' physical entity." ::= { entityPhysical 1 } entPhysicalEntry OBJECT-TYPE SYNTAX EntPhysicalEntry MAX-ACCESS not-accessible Bierman & McCloghrie Standards Track [Page 18] RFC 4133 Entity MIB (Version 3) August 2005 STATUS current DESCRIPTION "Information about a particular physical entity. Each entry provides objects (entPhysicalDescr, entPhysicalVendorType, and entPhysicalClass) to help an NMS identify and characterize the entry, and objects (entPhysicalContainedIn and entPhysicalParentRelPos) to help an NMS relate the particular entry to other entries in this table." INDEX { entPhysicalIndex } ::= { entPhysicalTable 1 } EntPhysicalEntry ::= SEQUENCE { entPhysicalIndex PhysicalIndex, entPhysicalDescr SnmpAdminString, entPhysicalVendorType AutonomousType, entPhysicalContainedIn PhysicalIndexOrZero, entPhysicalClass PhysicalClass, entPhysicalParentRelPos Integer32, entPhysicalName SnmpAdminString, entPhysicalHardwareRev SnmpAdminString, entPhysicalFirmwareRev SnmpAdminString, entPhysicalSoftwareRev SnmpAdminString, entPhysicalSerialNum SnmpAdminString, entPhysicalMfgName SnmpAdminString, entPhysicalModelName SnmpAdminString, entPhysicalAlias SnmpAdminString, entPhysicalAssetID SnmpAdminString, entPhysicalIsFRU TruthValue, entPhysicalMfgDate DateAndTime, entPhysicalUris OCTET STRING } entPhysicalIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this entry." ::= { entPhysicalEntry 1 } entPhysicalDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION Bierman & McCloghrie Standards Track [Page 19] RFC 4133 Entity MIB (Version 3) August 2005 "A textual description of physical entity. This object should contain a string that identifies the manufacturer's name for the physical entity, and should be set to a distinct value for each version or model of the physical entity." ::= { entPhysicalEntry 2 } entPhysicalVendorType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the vendor-specific hardware type of the physical entity. Note that this is different from the definition of MIB-II's sysObjectID. An agent should set this object to an enterprise-specific registration identifier value indicating the specific equipment type in detail. The associated instance of entPhysicalClass is used to indicate the general type of hardware device. If no vendor-specific registration identifier exists for this physical entity, or the value is unknown by this agent, then the value { 0 0 } is returned." ::= { entPhysicalEntry 3 } entPhysicalContainedIn OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The value of entPhysicalIndex for the physical entity which 'contains' this physical entity. A value of zero indicates this physical entity is not contained in any other physical entity. Note that the set of 'containment' relationships define a strict hierarchy; that is, recursion is not allowed. In the event that a physical entity is contained by more than one physical entity (e.g., double-wide modules), this object should identify the containing entity with the lowest value of entPhysicalIndex." ::= { entPhysicalEntry 4 } entPhysicalClass OBJECT-TYPE SYNTAX PhysicalClass MAX-ACCESS read-only Bierman & McCloghrie Standards Track [Page 20] RFC 4133 Entity MIB (Version 3) August 2005 STATUS current DESCRIPTION "An indication of the general hardware type of the physical entity. An agent should set this object to the standard enumeration value that most accurately indicates the general class of the physical entity, or the primary class if there is more than one entity. If no appropriate standard registration identifier exists for this physical entity, then the value 'other(1)' is returned. If the value is unknown by this agent, then the value 'unknown(2)' is returned." ::= { entPhysicalEntry 5 } entPhysicalParentRelPos OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the relative position of this 'child' component among all its 'sibling' components. Sibling components are defined as entPhysicalEntries that share the same instance values of each of the entPhysicalContainedIn and entPhysicalClass objects. An NMS can use this object to identify the relative ordering for all sibling components of a particular parent (identified by the entPhysicalContainedIn instance in each sibling entry). If possible, this value should match any external labeling of the physical component. For example, for a container (e.g., card slot) labeled as 'slot #3', entPhysicalParentRelPos should have the value '3'. Note that the entPhysicalEntry for the module plugged in slot 3 should have an entPhysicalParentRelPos value of '1'. If the physical position of this component does not match any external numbering or clearly visible ordering, then user documentation or other external reference material should be used to determine the parent-relative position. If this is not possible, then the agent should assign a consistent (but possibly arbitrary) ordering to a given set of 'sibling' components, perhaps based on internal representation of the components. Bierman & McCloghrie Standards Track [Page 21] RFC 4133 Entity MIB (Version 3) August 2005 If the agent cannot determine the parent-relative position for some reason, or if the associated value of entPhysicalContainedIn is '0', then the value '-1' is returned. Otherwise, a non-negative integer is returned, indicating the parent-relative position of this physical entity. Parent-relative ordering normally starts from '1' and continues to 'N', where 'N' represents the highest positioned child entity. However, if the physical entities (e.g., slots) are labeled from a starting position of zero, then the first sibling should be associated with an entPhysicalParentRelPos value of '0'. Note that this ordering may be sparse or dense, depending on agent implementation. The actual values returned are not globally meaningful, as each 'parent' component may use different numbering algorithms. The ordering is only meaningful among siblings of the same parent component. The agent should retain parent-relative position values across reboots, either through algorithmic assignment or use of non-volatile storage." ::= { entPhysicalEntry 6 } entPhysicalName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The textual name of the physical entity. The value of this object should be the name of the component as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name (e.g., `console') or a simple component number (e.g., port or module number, such as `1'), depending on the physical component naming syntax of the device. If there is no local name, or if this object is otherwise not applicable, then this object contains a zero-length string. Note that the value of entPhysicalName for two physical entities will be the same in the event that the console interface does not distinguish between them, e.g., slot-1 and the card in slot-1." ::= { entPhysicalEntry 7 } Bierman & McCloghrie Standards Track [Page 22] RFC 4133 Entity MIB (Version 3) August 2005 entPhysicalHardwareRev OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor-specific hardware revision string for the physical entity. The preferred value is the hardware revision identifier actually printed on the component itself (if present). Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific hardware revision string is associated with the physical component, or if this information is unknown to the agent, then this object will contain a zero-length string." ::= { entPhysicalEntry 8 } entPhysicalFirmwareRev OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor-specific firmware revision string for the physical entity. Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific firmware programs are associated with the physical component, or if this information is unknown to the agent, then this object will contain a zero-length string." ::= { entPhysicalEntry 9 } entPhysicalSoftwareRev OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor-specific software revision string for the physical entity. Note that if revision information is stored internally in a Bierman & McCloghrie Standards Track [Page 23] RFC 4133 Entity MIB (Version 3) August 2005 non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific software programs are associated with the physical component, or if this information is unknown to the agent, then this object will contain a zero-length string." ::= { entPhysicalEntry 10 } entPhysicalSerialNum OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The vendor-specific serial number string for the physical entity. The preferred value is the serial number string actually printed on the component itself (if present). On the first instantiation of an physical entity, the value of entPhysicalSerialNum associated with that entity is set to the correct vendor-assigned serial number, if this information is available to the agent. If a serial number is unknown or non-existent, the entPhysicalSerialNum will be set to a zero-length string instead. Note that implementations that can correctly identify the serial numbers of all installed physical entities do not need to provide write access to the entPhysicalSerialNum object. Agents which cannot provide non-volatile storage for the entPhysicalSerialNum strings are not required to implement write access for this object. Not every physical component will have a serial number, or even need one. Physical entities for which the associated value of the entPhysicalIsFRU object is equal to 'false(2)' (e.g., the repeater ports within a repeater module), do not need their own unique serial number. An agent does not have to provide write access for such entities, and may return a zero-length string. If write access is implemented for an instance of entPhysicalSerialNum, and a value is written into the instance, the agent must retain the supplied value in the entPhysicalSerialNum instance (associated with the same physical entity) for as long as that entity remains instantiated. This includes instantiations across all re-initializations/reboots of the network management system, including those resulting in a change of the physical Bierman & McCloghrie Standards Track [Page 24] RFC 4133 Entity MIB (Version 3) August 2005 entity's entPhysicalIndex value." ::= { entPhysicalEntry 11 } entPhysicalMfgName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the manufacturer of this physical component. The preferred value is the manufacturer name string actually printed on the component itself (if present). Note that comparisons between instances of the entPhysicalModelName, entPhysicalFirmwareRev, entPhysicalSoftwareRev, and the entPhysicalSerialNum objects, are only meaningful amongst entPhysicalEntries with the same value of entPhysicalMfgName. If the manufacturer name string associated with the physical component is unknown to the agent, then this object will contain a zero-length string." ::= { entPhysicalEntry 12 } entPhysicalModelName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor-specific model name identifier string associated with this physical component. The preferred value is the customer-visible part number, which may be printed on the component itself. If the model name string associated with the physical component is unknown to the agent, then this object will contain a zero-length string." ::= { entPhysicalEntry 13 } entPhysicalAlias OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is an 'alias' name for the physical entity, as specified by a network manager, and provides a non-volatile 'handle' for the physical entity. On the first instantiation of a physical entity, the value Bierman & McCloghrie Standards Track [Page 25] RFC 4133 Entity MIB (Version 3) August 2005 of entPhysicalAlias associated with that entity is set to the zero-length string. However, the agent may set the value to a locally unique default value, instead of a zero-length string. If write access is implemented for an instance of entPhysicalAlias, and a value is written into the instance, the agent must retain the supplied value in the entPhysicalAlias instance (associated with the same physical entity) for as long as that entity remains instantiated. This includes instantiations across all re-initializations/reboots of the network management system, including those resulting in a change of the physical entity's entPhysicalIndex value." ::= { entPhysicalEntry 14 } entPhysicalAssetID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is a user-assigned asset tracking identifier (as specified by a network manager) for the physical entity, and provides non-volatile storage of this information. On the first instantiation of a physical entity, the value of entPhysicalAssetID associated with that entity is set to the zero-length string. Not every physical component will have an asset tracking identifier, or even need one. Physical entities for which the associated value of the entPhysicalIsFRU object is equal to 'false(2)' (e.g., the repeater ports within a repeater module), do not need their own unique asset tracking identifier. An agent does not have to provide write access for such entities, and may instead return a zero-length string. If write access is implemented for an instance of entPhysicalAssetID, and a value is written into the instance, the agent must retain the supplied value in the entPhysicalAssetID instance (associated with the same physical entity) for as long as that entity remains instantiated. This includes instantiations across all re-initializations/reboots of the network management system, including those resulting in a change of the physical entity's entPhysicalIndex value. Bierman & McCloghrie Standards Track [Page 26] RFC 4133 Entity MIB (Version 3) August 2005 If no asset tracking information is associated with the physical component, then this object will contain a zero-length string." ::= { entPhysicalEntry 15 } entPhysicalIsFRU OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not this physical entity is considered a 'field replaceable unit' by the vendor. If this object contains the value 'true(1)' then this entPhysicalEntry identifies a field replaceable unit. For all entPhysicalEntries that represent components permanently contained within a field replaceable unit, the value 'false(2)' should be returned for this object." ::= { entPhysicalEntry 16 } entPhysicalMfgDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the date of manufacturing of the managed entity. If the manufacturing date is unknown or not supported, the object is not instantiated. The special value '0000000000000000'H may also be returned in this case." ::= { entPhysicalEntry 17 } entPhysicalUris OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains URIs and, therefore, the syntax of this object must conform to RFC 3986, section 2. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. If no additional identification information is known about the physical entity or supported, the object is not instantiated. A zero length octet string may also be Bierman & McCloghrie Standards Track [Page 27] RFC 4133 Entity MIB (Version 3) August 2005 returned in this case." REFERENCE "RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998." ::= { entPhysicalEntry 18 } -- The Logical Entity Table entLogicalTable OBJECT-TYPE SYNTAX SEQUENCE OF EntLogicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per logical entity. For agents that implement more than one naming scope, at least one entry must exist. Agents which instantiate all MIB objects within a single naming scope are not required to implement this table." ::= { entityLogical 1 } entLogicalEntry OBJECT-TYPE SYNTAX EntLogicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular logical entity. Entities may be managed by this agent or other SNMP agents (possibly) in the same chassis." INDEX { entLogicalIndex } ::= { entLogicalTable 1 } EntLogicalEntry ::= SEQUENCE { entLogicalIndex Integer32, entLogicalDescr SnmpAdminString, entLogicalType AutonomousType, entLogicalCommunity OCTET STRING, entLogicalTAddress TAddress, entLogicalTDomain TDomain, entLogicalContextEngineID SnmpEngineIdOrNone, entLogicalContextName SnmpAdminString } entLogicalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION Bierman & McCloghrie Standards Track [Page 28] RFC 4133 Entity MIB (Version 3) August 2005 "The value of this object uniquely identifies the logical entity. The value should be a small positive integer; index values for different logical entities are not necessarily contiguous." ::= { entLogicalEntry 1 } entLogicalDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the logical entity. This object should contain a string that identifies the manufacturer's name for the logical entity, and should be set to a distinct value for each version of the logical entity." ::= { entLogicalEntry 2 } entLogicalType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the type of logical entity. This will typically be the OBJECT IDENTIFIER name of the node in the SMI's naming hierarchy which represents the major MIB module, or the majority of the MIB modules, supported by the logical entity. For example: a logical entity of a regular host/router -> mib-2 a logical entity of a 802.1d bridge -> dot1dBridge a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt If an appropriate node in the SMI's naming hierarchy cannot be identified, the value 'mib-2' should be used." ::= { entLogicalEntry 3 } entLogicalCommunity OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "An SNMPv1 or SNMPv2C community-string, which can be used to access detailed management information for this logical entity. The agent should allow read access with this community string (to an appropriate subset of all managed objects) and may also return a community string based on the privileges of the request used to read this object. Note that an agent may return a community string with read-only privileges, even if this object is accessed with a read-write community string. However, the agent must take Bierman & McCloghrie Standards Track [Page 29] RFC 4133 Entity MIB (Version 3) August 2005 care not to return a community string that allows more privileges than the community string used to access this object. A compliant SNMP agent may wish to conserve naming scopes by representing multiple logical entities in a single 'default' naming scope. This is possible when the logical entities, represented by the same value of entLogicalCommunity, have no object instances in common. For example, 'bridge1' and 'repeater1' may be part of the main naming scope, but at least one additional community string is needed to represent 'bridge2' and 'repeater2'. Logical entities 'bridge1' and 'repeater1' would be represented by sysOREntries associated with the 'default' naming scope. For agents not accessible via SNMPv1 or SNMPv2C, the value of this object is the empty string. This object may also contain an empty string if a community string has not yet been assigned by the agent, or if no community string with suitable access rights can be returned for a particular SNMP request. Note that this object is deprecated. Agents which implement SNMPv3 access should use the entLogicalContextEngineID and entLogicalContextName objects to identify the context associated with each logical entity. SNMPv3 agents may return a zero-length string for this object, or may continue to return a community string (e.g., tri-lingual agent support)." ::= { entLogicalEntry 4 } entLogicalTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport service address by which the logical entity receives network management traffic, formatted according to the corresponding value of entLogicalTDomain. For snmpUDPDomain, a TAddress is 6 octets long: the initial 4 octets contain the IP-address in network-byte order and the last 2 contain the UDP port in network-byte order. Consult 'Transport Mappings for the Simple Network Management Protocol' (STD 62, RFC 3417 [RFC3417]) for further information on snmpUDPDomain." Bierman & McCloghrie Standards Track [Page 30] RFC 4133 Entity MIB (Version 3) August 2005 ::= { entLogicalEntry 5 } entLogicalTDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the kind of transport service by which the logical entity receives network management traffic. Possible values for this object are presently found in the Transport Mappings for Simple Network Management Protocol' (STD 62, RFC 3417 [RFC3417])." ::= { entLogicalEntry 6 } entLogicalContextEngineID OBJECT-TYPE SYNTAX SnmpEngineIdOrNone MAX-ACCESS read-only STATUS current DESCRIPTION "The authoritative contextEngineID that can be used to send an SNMP message concerning information held by this logical entity, to the address specified by the associated 'entLogicalTAddress/entLogicalTDomain' pair. This object, together with the associated entLogicalContextName object, defines the context associated with a particular logical entity, and allows access to SNMP engines identified by a contextEngineId and contextName pair. If no value has been configured by the agent, a zero-length string is returned, or the agent may choose not to instantiate this object at all." ::= { entLogicalEntry 7 } entLogicalContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The contextName that can be used to send an SNMP message concerning information held by this logical entity, to the address specified by the associated 'entLogicalTAddress/entLogicalTDomain' pair. This object, together with the associated entLogicalContextEngineID object, defines the context associated with a particular logical entity, and allows Bierman & McCloghrie Standards Track [Page 31] RFC 4133 Entity MIB (Version 3) August 2005 access to SNMP engines identified by a contextEngineId and contextName pair. If no value has been configured by the agent, a zero-length string is returned, or the agent may choose not to instantiate this object at all." ::= { entLogicalEntry 8 } entLPMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF EntLPMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains zero or more rows of logical entity to physical equipment associations. For each logical entity known by this agent, there are zero or more mappings to the physical resources, which are used to realize that logical entity. An agent should limit the number and nature of entries in this table such that only meaningful and non-redundant information is returned. For example, in a system that contains a single power supply, mappings between logical entities and the power supply are not useful and should not be included. Also, only the most appropriate physical component, which is closest to the root of a particular containment tree, should be identified in an entLPMapping entry. For example, suppose a bridge is realized on a particular module, and all ports on that module are ports on this bridge. A mapping between the bridge and the module would be useful, but additional mappings between the bridge and each of the ports on that module would be redundant (because the entPhysicalContainedIn hierarchy can provide the same information). On the other hand, if more than one bridge were utilizing ports on this module, then mappings between each bridge and the ports it used would be appropriate. Also, in the case of a single backplane repeater, a mapping for the backplane to the single repeater entity is not necessary." ::= { entityMapping 1 } entLPMappingEntry OBJECT-TYPE SYNTAX EntLPMappingEntry MAX-ACCESS not-accessible Bierman & McCloghrie Standards Track [Page 32] RFC 4133 Entity MIB (Version 3) August 2005 STATUS current DESCRIPTION "Information about a particular logical entity to physical equipment association. Note that the nature of the association is not specifically identified in this entry. It is expected that sufficient information exists in the MIBs used to manage a particular logical entity to infer how physical component information is utilized." INDEX { entLogicalIndex, entLPPhysicalIndex } ::= { entLPMappingTable 1 } EntLPMappingEntry ::= SEQUENCE { entLPPhysicalIndex PhysicalIndex } entLPPhysicalIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the index value of a particular entPhysicalEntry associated with the indicated entLogicalEntity." ::= { entLPMappingEntry 1 } -- logical entity/component to alias table entAliasMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF EntAliasMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains zero or more rows, representing mappings of logical entity and physical component to external MIB identifiers. Each physical port in the system may be associated with a mapping to an external identifier, which itself is associated with a particular logical entity's naming scope. A 'wildcard' mechanism is provided to indicate that an identifier is associated with more than one logical entity." ::= { entityMapping 2 } entAliasMappingEntry OBJECT-TYPE SYNTAX EntAliasMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular physical equipment, logical Bierman & McCloghrie Standards Track [Page 33] RFC 4133 Entity MIB (Version 3) August 2005 entity to external identifier binding. Each logical entity/physical component pair may be associated with one alias mapping. The logical entity index may also be used as a 'wildcard' (refer to the entAliasLogicalIndexOrZero object DESCRIPTION clause for details.) Note that only entPhysicalIndex values that represent physical ports (i.e., associated entPhysicalClass value is 'port(10)') are permitted to exist in this table." INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } ::= { entAliasMappingTable 1 } EntAliasMappingEntry ::= SEQUENCE { entAliasLogicalIndexOrZero Integer32, entAliasMappingIdentifier RowPointer } entAliasLogicalIndexOrZero OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object identifies the logical entity that defines the naming scope for the associated instance of the 'entAliasMappingIdentifier' object. If this object has a non-zero value, then it identifies the logical entity named by the same value of entLogicalIndex. If this object has a value of zero, then the mapping between the physical component and the alias identifier for this entAliasMapping entry is associated with all unspecified logical entities. That is, a value of zero (the default mapping) identifies any logical entity that does not have an explicit entry in this table for a particular entPhysicalIndex/entAliasMappingIdentifier pair. For example, to indicate that a particular interface (e.g., physical component 33) is identified by the same value of ifIndex for all logical entities, the following instance might exist: entAliasMappingIdentifier.33.0 = ifIndex.5 In the event an entPhysicalEntry is associated differently for some logical entities, additional entAliasMapping entries may exist, e.g.: Bierman & McCloghrie Standards Track [Page 34] RFC 4133 Entity MIB (Version 3) August 2005 entAliasMappingIdentifier.33.0 = ifIndex.6 entAliasMappingIdentifier.33.4 = ifIndex.1 entAliasMappingIdentifier.33.5 = ifIndex.1 entAliasMappingIdentifier.33.10 = ifIndex.12 Note that entries with non-zero entAliasLogicalIndexOrZero index values have precedence over zero-indexed entries. In this example, all logical entities except 4, 5, and 10, associate physical entity 33 with ifIndex.6." ::= { entAliasMappingEntry 1 } entAliasMappingIdentifier OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies a particular conceptual row associated with the indicated entPhysicalIndex and entLogicalIndex pair. Because only physical ports are modeled in this table, only entries that represent interfaces or ports are allowed. If an ifEntry exists on behalf of a particular physical port, then this object should identify the associated 'ifEntry'. For repeater ports, the appropriate row in the 'rptrPortGroupTable' should be identified instead. For example, suppose a physical port was represented by entPhysicalEntry.3, entLogicalEntry.15 existed for a repeater, and entLogicalEntry.22 existed for a bridge. Then there might be two related instances of entAliasMappingIdentifier: entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 entAliasMappingIdentifier.3.22 == ifIndex.17 It is possible that other mappings (besides interfaces and repeater ports) may be defined in the future, as required. Bridge ports are identified by examining the Bridge MIB and appropriate ifEntries associated with each 'dot1dBasePort', and are thus not represented in this table." ::= { entAliasMappingEntry 2 } -- physical mapping table entPhysicalContainsTable OBJECT-TYPE SYNTAX SEQUENCE OF EntPhysicalContainsEntry MAX-ACCESS not-accessible STATUS current Bierman & McCloghrie Standards Track [Page 35] RFC 4133 Entity MIB (Version 3) August 2005 DESCRIPTION "A table that exposes the container/'containee' relationships between physical entities. This table provides all the information found by constructing the virtual containment tree for a given entPhysicalTable, but in a more direct format. In the event a physical entity is contained by more than one other physical entity (e.g., double-wide modules), this table should include these additional mappings, which cannot be represented in the entPhysicalTable virtual containment tree." ::= { entityMapping 3 } entPhysicalContainsEntry OBJECT-TYPE SYNTAX EntPhysicalContainsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single container/'containee' relationship." INDEX { entPhysicalIndex, entPhysicalChildIndex } ::= { entPhysicalContainsTable 1 } EntPhysicalContainsEntry ::= SEQUENCE { entPhysicalChildIndex PhysicalIndex } entPhysicalChildIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of entPhysicalIndex for the contained physical entity." ::= { entPhysicalContainsEntry 1 } -- last change time stamp for the whole MIB entLastChangeTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time a conceptual row is created, modified, or deleted in any of these tables: - entPhysicalTable - entLogicalTable - entLPMappingTable - entAliasMappingTable Bierman & McCloghrie Standards Track [Page 36] RFC 4133 Entity MIB (Version 3) August 2005 - entPhysicalContainsTable " ::= { entityGeneral 1 } -- Entity MIB Trap Definitions entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } entConfigChange NOTIFICATION-TYPE STATUS current DESCRIPTION "An entConfigChange notification is generated when the value of entLastChangeTime changes. It can be utilized by an NMS to trigger logical/physical entity table maintenance polls. An agent should not generate more than one entConfigChange 'notification-event' in a given time interval (five seconds is the suggested default). A 'notification-event' is the transmission of a single trap or inform PDU to a list of notification destinations. If additional configuration changes occur within the throttling period, then notification-events for these changes should be suppressed by the agent until the current throttling period expires. At the end of a throttling period, one notification-event should be generated if any configuration changes occurred since the start of the throttling period. In such a case, another throttling period is started right away. An NMS should periodically check the value of entLastChangeTime to detect any missed entConfigChange notification-events, e.g., due to throttling or transmission loss." ::= { entityMIBTrapPrefix 1 } -- conformance information entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } -- compliance statements entityCompliance MODULE-COMPLIANCE STATUS deprecated Bierman & McCloghrie Standards Track [Page 37] RFC 4133 Entity MIB (Version 3) August 2005 DESCRIPTION "The compliance statement for SNMP entities that implement version 1 of the Entity MIB." MODULE -- this module MANDATORY-GROUPS { entityPhysicalGroup, entityLogicalGroup, entityMappingGroup, entityGeneralGroup, entityNotificationsGroup } ::= { entityCompliances 1 } entity2Compliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMP entities that implement version 2 of the Entity MIB." MODULE -- this module MANDATORY-GROUPS { entityPhysicalGroup, entityPhysical2Group, entityGeneralGroup, entityNotificationsGroup } GROUP entityLogical2Group DESCRIPTION "Implementation of this group is not mandatory for agents that model all MIB object instances within a single naming scope." GROUP entityMappingGroup DESCRIPTION "Implementation of the entPhysicalContainsTable is mandatory for all agents. Implementation of the entLPMappingTable and entAliasMappingTables are not mandatory for agents that model all MIB object instances within a single naming scope. Note that the entAliasMappingTable may be useful for all agents; however, implementation of the entityLogicalGroup or entityLogical2Group is required to support this table." OBJECT entPhysicalSerialNum MIN-ACCESS not-accessible DESCRIPTION "Read and write access is not required for agents that cannot identify serial number information for physical entities, and/or cannot provide non-volatile storage for Bierman & McCloghrie Standards Track [Page 38] RFC 4133 Entity MIB (Version 3) August 2005 NMS-assigned serial numbers. Write access is not required for agents that can identify serial number information for physical entities, but cannot provide non-volatile storage for NMS-assigned serial numbers. Write access is not required for physical entities for which the associated value of the entPhysicalIsFRU object is equal to 'false(2)'." OBJECT entPhysicalAlias MIN-ACCESS read-only DESCRIPTION "Write access is required only if the associated entPhysicalClass value is equal to 'chassis(3)'." OBJECT entPhysicalAssetID MIN-ACCESS not-accessible DESCRIPTION "Read and write access is not required for agents that cannot provide non-volatile storage for NMS-assigned asset identifiers. Write access is not required for physical entities for which the associated value of the entPhysicalIsFRU object is equal to 'false(2)'." OBJECT entPhysicalClass SYNTAX INTEGER { other(1), unknown(2), chassis(3), backplane(4), container(5), powerSupply(6), fan(7), sensor(8), module(9), port(10), stack(11) } DESCRIPTION "Implementation of the 'cpu(12)' enumeration is not required." ::= { entityCompliances 2 } Bierman & McCloghrie Standards Track [Page 39] RFC 4133 Entity MIB (Version 3) August 2005 entity3Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement version 3 of the Entity MIB." MODULE -- this module MANDATORY-GROUPS { entityPhysicalGroup, entityPhysical2Group, entityPhysical3Group, entityGeneralGroup, entityNotificationsGroup } GROUP entityLogical2Group DESCRIPTION "Implementation of this group is not mandatory for agents that model all MIB object instances within a single naming scope." GROUP entityMappingGroup DESCRIPTION "Implementation of the entPhysicalContainsTable is mandatory for all agents. Implementation of the entLPMappingTable and entAliasMappingTables are not mandatory for agents that model all MIB object instances within a single naming scope. Note that the entAliasMappingTable may be useful for all agents; however, implementation of the entityLogicalGroup or entityLogical2Group is required to support this table." OBJECT entPhysicalSerialNum MIN-ACCESS not-accessible DESCRIPTION "Read and write access is not required for agents that cannot identify serial number information for physical entities, and/or cannot provide non-volatile storage for NMS-assigned serial numbers. Write access is not required for agents that can identify serial number information for physical entities, but cannot provide non-volatile storage for NMS-assigned serial numbers. Write access is not required for physical entities for which the associated value of the entPhysicalIsFRU object is equal to 'false(2)'." OBJECT entPhysicalAlias Bierman & McCloghrie Standards Track [Page 40] RFC 4133 Entity MIB (Version 3) August 2005 MIN-ACCESS read-only DESCRIPTION "Write access is required only if the associated entPhysicalClass value is equal to 'chassis(3)'." OBJECT entPhysicalAssetID MIN-ACCESS not-accessible DESCRIPTION "Read and write access is not required for agents that cannot provide non-volatile storage for NMS-assigned asset identifiers. Write access is not required for physical entities for which the associated value of entPhysicalIsFRU is equal to 'false(2)'." ::= { entityCompliances 3 } -- MIB groupings entityPhysicalGroup OBJECT-GROUP OBJECTS { entPhysicalDescr, entPhysicalVendorType, entPhysicalContainedIn, entPhysicalClass, entPhysicalParentRelPos, entPhysicalName } STATUS current DESCRIPTION "The collection of objects used to represent physical system components, for which a single agent provides management information." ::= { entityGroups 1 } entityLogicalGroup OBJECT-GROUP OBJECTS { entLogicalDescr, entLogicalType, entLogicalCommunity, entLogicalTAddress, entLogicalTDomain } STATUS deprecated DESCRIPTION "The collection of objects used to represent the list of logical entities, for which a single agent provides management information." Bierman & McCloghrie Standards Track [Page 41] RFC 4133 Entity MIB (Version 3) August 2005 ::= { entityGroups 2 } entityMappingGroup OBJECT-GROUP OBJECTS { entLPPhysicalIndex, entAliasMappingIdentifier, entPhysicalChildIndex } STATUS current DESCRIPTION "The collection of objects used to represent the associations between multiple logical entities, physical components, interfaces, and port identifiers, for which a single agent provides management information." ::= { entityGroups 3 } entityGeneralGroup OBJECT-GROUP OBJECTS { entLastChangeTime } STATUS current DESCRIPTION "The collection of objects used to represent general entity information, for which a single agent provides management information." ::= { entityGroups 4 } entityNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { entConfigChange } STATUS current DESCRIPTION "The collection of notifications used to indicate Entity MIB data consistency and general status information." ::= { entityGroups 5 } entityPhysical2Group OBJECT-GROUP OBJECTS { entPhysicalHardwareRev, entPhysicalFirmwareRev, entPhysicalSoftwareRev, entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, entPhysicalAlias, entPhysicalAssetID, entPhysicalIsFRU } STATUS current Bierman & McCloghrie Standards Track [Page 42] RFC 4133 Entity MIB (Version 3) August 2005 DESCRIPTION "The collection of objects used to represent physical system components, for which a single agent provides management information. This group augments the objects contained in the entityPhysicalGroup." ::= { entityGroups 6 } entityLogical2Group OBJECT-GROUP OBJECTS { entLogicalDescr, entLogicalType, entLogicalTAddress, entLogicalTDomain, entLogicalContextEngineID, entLogicalContextName } STATUS current DESCRIPTION "The collection of objects used to represent the list of logical entities, for which a single SNMP entity provides management information." ::= { entityGroups 7 } entityPhysical3Group OBJECT-GROUP OBJECTS { entPhysicalMfgDate, entPhysicalUris } STATUS current DESCRIPTION "The collection of objects used to represent physical system components, for which a single agent provides management information. This group augments the objects contained in the entityPhysicalGroup." ::= { entityGroups 8 } END Bierman & McCloghrie Standards Track [Page 43] RFC 4133 Entity MIB (Version 3) August 2005 4. Usage Examples The following sections iterate the instance values for two example networking devices. These examples are kept simple to make them more understandable. Auxiliary components such as fans, sensors, empty slots, and sub-modules are not shown, but might be modeled in real implementations. 4.1. Router/Bridge The first example is a router containing two slots. Each slot contains a 3 port router/bridge module. Each port is represented in the ifTable. There are two logical instances of OSPF running and two logical bridges: Physical entities -- entPhysicalTable: 1 Field-replaceable physical chassis: entPhysicalDescr.1 == 'Acme Chassis Model 100' entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 entPhysicalContainedIn.1 == 0 entPhysicalClass.1 == chassis(3) entPhysicalParentRelPos.1 == 0 entPhysicalName.1 == '100-A' entPhysicalHardwareRev.1 == 'A(1.00.02)' entPhysicalSoftwareRev.1 == '' entPhysicalFirmwareRev.1 == '' entPhysicalSerialNum.1 == 'C100076544' entPhysicalMfgName.1 == 'Acme' entPhysicalModelName.1 == '100' entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' entPhysicalAssetID.1 == '0007372293' entPhysicalIsFRU.1 == true(1) entPhysicalMfgDate.1 == '2002-5-26,13:30:30.0,-4:0' entPhysicalUris.1 == 'URN:CLEI:CNME120ARA' 2 slots within the chassis: entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' entPhysicalVendorType.2 == acmeProducts.slotTypes.1 entPhysicalContainedIn.2 == 1 entPhysicalClass.2 == container(5) entPhysicalParentRelPos.2 == 1 entPhysicalName.2 == 'S1' entPhysicalHardwareRev.2 == 'B(1.00.01)' entPhysicalSoftwareRev.2 == '' entPhysicalFirmwareRev.2 == '' entPhysicalSerialNum.2 == '' entPhysicalMfgName.2 == 'Acme' entPhysicalModelName.2 == 'AA' entPhysicalAlias.2 == '' Bierman & McCloghrie Standards Track [Page 44] RFC 4133 Entity MIB (Version 3) August 2005 entPhysicalAssetID.2 == '' entPhysicalIsFRU.2 == false(2) entPhysicalMfgDate.2 == '2002-7-26,12:22:12.0,-4:0' entPhysicalUris.2 == 'URN:CLEI:CNME123ARA' entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' entPhysicalVendorType.3 = acmeProducts.slotTypes.1 entPhysicalContainedIn.3 == 1 entPhysicalClass.3 == container(5) entPhysicalParentRelPos.3 == 2 entPhysicalName.3 == 'S2' entPhysicalHardwareRev.3 == '1.00.07' entPhysicalSoftwareRev.3 == '' entPhysicalFirmwareRev.3 == '' entPhysicalSerialNum.3 == '' entPhysicalMfgName.3 == 'Acme' entPhysicalModelName.3 == 'AA' entPhysicalAlias.3 == '' entPhysicalAssetID.3 == '' entPhysicalIsFRU.3 == false(2) entPhysicalMfgDate.3 == '2002-7-26,12:12:12.0,-4:0' entPhysicalUris.3 == 'URN:CLEI:CNME123ARA' 2 Field-replaceable modules: Slot 1 contains a module with 3 ports: entPhysicalDescr.4 == 'Acme Router-100' entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 entPhysicalContainedIn.4 == 2 entPhysicalClass.4 == module(9) entPhysicalParentRelPos.4 == 1 entPhysicalName.4 == 'M1' entPhysicalHardwareRev.4 == '1.00.07' entPhysicalSoftwareRev.4 == '1.4.1' entPhysicalFirmwareRev.4 == 'A(1.1)' entPhysicalSerialNum.4 == 'C100087363' entPhysicalMfgName.4 == 'Acme' entPhysicalModelName.4 == 'R100-FE' entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' entPhysicalAssetID.4 == '0007372462' entPhysicalIsFRU.4 == true(1) entPhysicalMfgDate.4 == '2003-7-18,13:30:30.0,-4:0' entPhysicalUris.4 == 'URN:CLEI:CNRU123CAA' entPhysicalDescr.5 == 'Acme Ethernet-100 Port' entPhysicalVendorType.5 == acmeProducts.portTypes.2 entPhysicalContainedIn.5 == 4 entPhysicalClass.5 == port(10) entPhysicalParentRelPos.5 == 1 Bierman & McCloghrie Standards Track [Page 45] RFC 4133 Entity MIB (Version 3) August 2005 entPhysicalName.5 == 'P1' entPhysicalHardwareRev.5 == 'G(1.02)' entPhysicalSoftwareRev.5 == '' entPhysicalFirmwareRev.5 == '1.1' entPhysicalSerialNum.5 == '' entPhysicalMfgName.5 == 'Acme' entPhysicalModelName.5 == 'FE-100' entPhysicalAlias.5 == '' entPhysicalAssetID.5 == '' entPhysicalIsFRU.5 == false(2) entPhysicalMfgDate.5 == '2003-7-18,14:20:22.0,-4:0' entPhysicalUris.5 == 'URN:CLEI:CNMES23ARA' entPhysicalDescr.6 == 'Acme Ethernet-100 Port' entPhysicalVendorType.6 == acmeProducts.portTypes.2 entPhysicalContainedIn.6 == 4 entPhysicalClass.6 == port(10) entPhysicalParentRelPos.6 == 2 entPhysicalName.6 == 'P2' entPhysicalHardwareRev.6 == 'G(1.02)' entPhysicalSoftwareRev.6 == '' entPhysicalFirmwareRev.6 == '1.1' entPhysicalSerialNum.6 == '' entPhysicalMfgName.6 == 'Acme' entPhysicalModelName.6 == 'FE-100' entPhysicalAlias.6 == '' entPhysicalAssetID.6 == '' entPhysicalIsFRU.6 == false(2) entPhysicalMfgDate.6 == '2003-7-19,10:15:15.0,-4:0' entPhysicalUris.6 == 'URN:CLEI:CNMES23ARA' entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' entPhysicalVendorType.7 == acmeProducts.portTypes.3 entPhysicalContainedIn.7 == 4 entPhysicalClass.7 == port(10) entPhysicalParentRelPos.7 == 3 entPhysicalName.7 == 'P3' entPhysicalHardwareRev.7 == 'B(1.03)' entPhysicalSoftwareRev.7 == '2.5.1' entPhysicalFirmwareRev.7 == '2.5F' entPhysicalSerialNum.7 == '' entPhysicalMfgName.7 == 'Acme' entPhysicalModelName.7 == 'FDDI-100' entPhysicalAlias.7 == '' entPhysicalAssetID.7 == '' entPhysicalIsFRU.7 == false(2) Bierman & McCloghrie Standards Track [Page 46] RFC 4133 Entity MIB (Version 3) August 2005 Slot 2 contains another 3-port module: entPhysicalDescr.8 == 'Acme Router-100 Comm Module' entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 entPhysicalContainedIn.8 == 3 entPhysicalClass.8 == module(9) entPhysicalParentRelPos.8 == 1 entPhysicalName.8 == 'M2' entPhysicalHardwareRev.8 == '2.01.00' entPhysicalSoftwareRev.8 == '3.0.7' entPhysicalFirmwareRev.8 == 'A(1.2)' entPhysicalSerialNum.8 == 'C100098732' entPhysicalMfgName.8 == 'Acme' entPhysicalModelName.8 == 'C100' entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' entPhysicalAssetID.8 == '0007373982' entPhysicalIsFRU.8 == true(1) entPhysicalMfgDate.8 == '2002-5-26,13:30:15.0,-4:0' entPhysicalUris.8 == 'URN:CLEI:CNRT321MAA' entPhysicalDescr.9 == 'Acme Fddi-100 Port' entPhysicalVendorType.9 == acmeProducts.portTypes.5 entPhysicalContainedIn.9 == 8 entPhysicalClass.9 == port(10) entPhysicalParentRelPos.9 == 1 entPhysicalName.9 == 'FDDI Primary' entPhysicalHardwareRev.9 == 'CC(1.07)' entPhysicalSoftwareRev.9 == '2.0.34' entPhysicalFirmwareRev.9 == '1.1' entPhysicalSerialNum.9 == '' entPhysicalMfgName.9 == 'Acme' entPhysicalModelName.9 == 'FDDI-100' entPhysicalAlias.9 == '' entPhysicalAssetID.9 == '' entPhysicalIsFRU.9 == false(2) entPhysicalDescr.10 == 'Acme Ethernet-100 Port' entPhysicalVendorType.10 == acmeProducts.portTypes.2 entPhysicalContainedIn.10 == 8 entPhysicalClass.10 == port(10) entPhysicalParentRelPos.10 == 2 entPhysicalName.10 == 'Ethernet A' entPhysicalHardwareRev.10 == 'G(1.04)' entPhysicalSoftwareRev.10 == '' entPhysicalFirmwareRev.10 == '1.3' entPhysicalSerialNum.10 == '' entPhysicalMfgName.10 == 'Acme' entPhysicalModelName.10 == 'FE-100' entPhysicalAlias.10 == '' Bierman & McCloghrie Standards Track [Page 47] RFC 4133 Entity MIB (Version 3) August 2005 entPhysicalAssetID.10 == '' entPhysicalIsFRU.10 == false(2) entPhysicalMfgDate.10 == '2002-7-26,13:30:15.0,-4:0' entPhysicalUris.10 == 'URN:CLEI:CNMES23ARA' entPhysicalDescr.11 == 'Acme Ethernet-100 Port' entPhysicalVendorType.11 == acmeProducts.portTypes.2 entPhysicalContainedIn.11 == 8 entPhysicalClass.11 == port(10) entPhysicalParentRelPos.11 == 3 entPhysicalName.11 == 'Ethernet B' entPhysicalHardwareRev.11 == 'G(1.04)' entPhysicalSoftwareRev.11 == '' entPhysicalFirmwareRev.11 == '1.3' entPhysicalSerialNum.11 == '' entPhysicalMfgName.11 == 'Acme' entPhysicalModelName.11 == 'FE-100' entPhysicalAlias.11 == '' entPhysicalAssetID.11 == '' entPhysicalIsFRU.11 == false(2) entPhysicalMfgDate.11 == '2002-8-16,15:35:15.0,-4:0' entPhysicalUris.11 == 'URN:CLEI:CNMES23ARA' Logical entities -- entLogicalTable; no SNMPv3 support 2 OSPF instances: entLogicalDescr.1 == 'Acme OSPF v1.1' entLogicalType.1 == ospf entLogicalCommunity.1 == 'public-ospf1' entLogicalTAddress.1 == 192.0.2.1:161 entLogicalTDomain.1 == snmpUDPDomain entLogicalContextEngineID.1 == '' entLogicalContextName.1 == '' entLogicalDescr.2 == 'Acme OSPF v1.1' entLogicalType.2 == ospf entLogicalCommunity.2 == 'public-ospf2' entLogicalTAddress.2 == 192.0.2.1:161 entLogicalTDomain.2 == snmpUDPDomain entLogicalContextEngineID.2 == '' entLogicalContextName.2 == '' 2 logical bridges: entLogicalDescr.3 == 'Acme Bridge v2.1.1' entLogicalType.3 == dot1dBridge entLogicalCommunity.3 == 'public-bridge1' entLogicalTAddress.3 == 192.0.2.1:161 entLogicalTDomain.3 == snmpUDPDomain entLogicalContextEngineID.3 == '' Bierman & McCloghrie Standards Track [Page 48] RFC 4133 Entity MIB (Version 3) August 2005 entLogicalContextName.3 == '' entLogicalDescr.4 == 'Acme Bridge v2.1.1' entLogicalType.4 == dot1dBridge entLogicalCommunity.4 == 'public-bridge2' entLogicalTAddress.4 == 192.0.2.1:161 entLogicalTDomain.4 == snmpUDPDomain entLogicalContextEngineID.4 == '' entLogicalContextName.4 == '' Logical to Physical Mappings: 1st OSPF instance: uses module 1-port 1 entLPPhysicalIndex.1.5 == 5 2nd OSPF instance: uses module 2-port 1 entLPPhysicalIndex.2.9 == 9 1st bridge group: uses module 1, all ports [ed. -- Note that these mappings are included in the table because another logical entity (1st OSPF) utilizes one of the ports. If this were not the case, then a single mapping to the module (e.g., entLPPhysicalIndex.3.4) would be present instead.] entLPPhysicalIndex.3.5 == 5 entLPPhysicalIndex.3.6 == 6 entLPPhysicalIndex.3.7 == 7 2nd bridge group: uses module 2, all ports entLPPhysicalIndex.4.9 == 9 entLPPhysicalIndex.4.10 == 10 entLPPhysicalIndex.4.11 == 11 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: Example 1: ifIndex values are global to all logical entities entAliasMappingIdentifier.5.0 == ifIndex.1 entAliasMappingIdentifier.6.0 == ifIndex.2 entAliasMappingIdentifier.7.0 == ifIndex.3 entAliasMappingIdentifier.9.0 == ifIndex.4 entAliasMappingIdentifier.10.0 == ifIndex.5 entAliasMappingIdentifier.11.0 == ifIndex.6 Example 2: ifIndex values are not shared by all logical entities; (Bridge-1 uses ifIndex values 101 - 103 and Bridge-2 uses ifIndex values 204-206.) entAliasMappingIdentifier.5.0 == ifIndex.1 entAliasMappingIdentifier.5.3 == ifIndex.101 entAliasMappingIdentifier.6.0 == ifIndex.2 Bierman & McCloghrie Standards Track [Page 49] RFC 4133 Entity MIB (Version 3) August 2005 entAliasMappingIdentifier.6.3 == ifIndex.102 entAliasMappingIdentifier.7.0 == ifIndex.3 entAliasMappingIdentifier.7.3 == ifIndex.103 entAliasMappingIdentifier.9.0 == ifIndex.4 entAliasMappingIdentifier.9.4 == ifIndex.204 entAliasMappingIdentifier.10.0 == ifIndex.5 entAliasMappingIdentifier.10.4 == ifIndex.205 entAliasMappingIdentifier.11.0 == ifIndex.6 entAliasMappingIdentifier.11.4 == ifIndex.206 Physical Containment Tree -- entPhysicalContainsTable chassis has two containers: entPhysicalChildIndex.1.2 == 2 entPhysicalChildIndex.1.3 == 3 container 1 has a module: entPhysicalChildIndex.2.4 == 4 container 2 has a module: entPhysicalChildIndex.3.8 == 8 module 1 has 3 ports: entPhysicalChildIndex.4.5 == 5 entPhysicalChildIndex.4.6 == 6 entPhysicalChildIndex.4.7 == 7 module 2 has 3 ports: entPhysicalChildIndex.8.9 == 9 entPhysicalChildIndex.8.10 == 10 entPhysicalChildIndex.8.11 == 11 4.2. Repeaters The second example is a 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, and the remaining slots contain ethernet repeater modules. Note that this example assumes an older Repeater MIB implementation, (RFC 1516 [RFC1516]) rather than the new Repeater MIB (RFC 2108 [RFC2108]). The new version contains an object called 'rptrPortRptrId', which should be used to identify repeater port groupings, rather than using community strings or contexts. Physical entities -- entPhysicalTable: 1 Field-replaceable physical chassis: entPhysicalDescr.1 == 'Acme Chassis Model 110' entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 entPhysicalContainedIn.1 == 0 Bierman & McCloghrie Standards Track [Page 50] RFC 4133 Entity MIB (Version 3) August 2005 entPhysicalClass.1 == chassis(3) entPhysicalParentRelPos.1 ==0 entPhysicalName.1 == '110-B' entPhysicalHardwareRev.1 == 'A(1.02.00)' entPhysicalSoftwareRev.1 == '' entPhysicalFirmwareRev.1 == '' entPhysicalSerialNum.1 == 'C100079294' entPhysicalMfgName.1 == 'Acme' entPhysicalModelName.1 == '110' entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' entPhysicalAssetID.1 == '0007386327' entPhysicalIsFRU.1 == true(1) 2 Chassis Ethernet Backplanes: entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 entPhysicalContainedIn.2 == 1 entPhysicalClass.2 == backplane(4) entPhysicalParentRelPos.2 == 1 entPhysicalName.2 == 'B1' entPhysicalHardwareRev.2 == 'A(2.04.01)' entPhysicalSoftwareRev.2 == '' entPhysicalFirmwareRev.2 == '' entPhysicalSerialNum.2 == '' entPhysicalMfgName.2 == 'Acme' entPhysicalModelName.2 == 'BK-A' entPhysicalAlias.2 == '' entPhysicalAssetID.2 == '' entPhysicalIsFRU.2 == false(2) entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 entPhysicalContainedIn.3 == 1 entPhysicalClass.3 == backplane(4) entPhysicalParentRelPos.3 == 2 entPhysicalName.3 == 'B2' entPhysicalHardwareRev.3 == 'A(2.04.01)' entPhysicalSoftwareRev.3 == '' entPhysicalFirmwareRev.3 == '' entPhysicalSerialNum.3 == '' entPhysicalMfgName.3 == 'Acme' entPhysicalModelName.3 == 'BK-A' entPhysicalAlias.3 == '' entPhysicalAssetID.3 == '' entPhysicalIsFRU.3 == false(2) Bierman & McCloghrie Standards Track [Page 51] RFC 4133 Entity MIB (Version 3) August 2005 3 slots within the chassis: entPhysicalDescr.4 == 'Acme Hub Slot Type RB' entPhysicalVendorType.4 == acmeProducts.slotTypes.5 entPhysicalContainedIn.4 == 1 entPhysicalClass.4 == container(5) entPhysicalParentRelPos.4 == 1 entPhysicalName.4 == 'Slot 1' entPhysicalHardwareRev.4 == 'B(1.00.03)' entPhysicalSoftwareRev.4 == '' entPhysicalFirmwareRev.4 == '' entPhysicalSerialNum.4 == '' entPhysicalMfgName.4 == 'Acme' entPhysicalModelName.4 == 'RB' entPhysicalAlias.4 == '' entPhysicalAssetID.4 == '' entPhysicalIsFRU.4 == false(2) entPhysicalDescr.5 == 'Acme Hub Slot Type RB' entPhysicalVendorType.5 == acmeProducts.slotTypes.5 entPhysicalContainedIn.5 == 1 entPhysicalClass.5 == container(5) entPhysicalParentRelPos.5 == 2 entPhysicalName.5 == 'Slot 2' entPhysicalHardwareRev.5 == 'B(1.00.03)' entPhysicalSoftwareRev.5 == '' entPhysicalFirmwareRev.5 == '' entPhysicalSerialNum.5 == '' entPhysicalMfgName.5 == 'Acme' entPhysicalModelName.5 == 'RB' entPhysicalAlias.5 == '' entPhysicalAssetID.5 == '' entPhysicalIsFRU.5 == false(2) entPhysicalDescr.6 == 'Acme Hub Slot Type RB' entPhysicalVendorType.6 == acmeProducts.slotTypes.5 entPhysicalContainedIn.6 == 1 entPhysicalClass.6 == container(5) entPhysicalParentRelPos.6 == 3 entPhysicalName.6 == 'Slot 3' entPhysicalHardwareRev.6 == 'B(1.00.03)' entPhysicalSoftwareRev.6 == '' entPhysicalFirmwareRev.6 == '' entPhysicalSerialNum.6 == '' entPhysicalMfgName.6 == 'Acme' entPhysicalModelName.6 == 'RB' entPhysicalAlias.6 == '' entPhysicalAssetID.6 == '' entPhysicalIsFRU.6 == false(2) Bierman & McCloghrie Standards Track [Page 52] RFC 4133 Entity MIB (Version 3) August 2005 Slot 1 contains a plug-in module with 4 10-BaseT ports: entPhysicalDescr.7 == 'Acme 10Base-T Module 114' entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 entPhysicalContainedIn.7 == 4 entPhysicalClass.7 == module(9) entPhysicalParentRelPos.7 == 1 entPhysicalName.7 == 'M1' entPhysicalHardwareRev.7 == 'A(1.02.01)' entPhysicalSoftwareRev.7 == '1.7.2' entPhysicalFirmwareRev.7 == 'A(1.5)' entPhysicalSerialNum.7 == 'C100096244' entPhysicalMfgName.7 == 'Acme' entPhysicalModelName.7 = '114' entPhysicalAlias.7 == 'bldg09:floor1:eng' entPhysicalAssetID.7 == '0007962951' entPhysicalIsFRU.7 == true(1) entPhysicalDescr.8 == 'Acme 10Base-T Port RB' entPhysicalVendorType.8 == acmeProducts.portTypes.10 entPhysicalContainedIn.8 == 7 entPhysicalClass.8 == port(10) entPhysicalParentRelPos.8 == 1 entPhysicalName.8 == 'Ethernet-A' entPhysicalHardwareRev.8 == 'A(1.04F)' entPhysicalSoftwareRev.8 == '' entPhysicalFirmwareRev.8 == '1.4' entPhysicalSerialNum.8 == '' entPhysicalMfgName.8 == 'Acme' entPhysicalModelName.8 == 'RB' entPhysicalAlias.8 == '' entPhysicalAssetID.8 == '' entPhysicalIsFRU.8 == false(2) entPhysicalDescr.9 == 'Acme 10Base-T Port RB' entPhysicalVendorType.9 == acmeProducts.portTypes.10 entPhysicalContainedIn.9 == 7 entPhysicalClass.9 == port(10) entPhysicalParentRelPos.9 == 2 entPhysicalName.9 == 'Ethernet-B' entPhysicalHardwareRev.9 == 'A(1.04F)' entPhysicalSoftwareRev.9 == '' entPhysicalFirmwareRev.9 == '1.4' entPhysicalSerialNum.9 == '' entPhysicalMfgName.9 == 'Acme' entPhysicalModelName.9 = 'RB' entPhysicalAlias.9 == '' entPhysicalAssetID.9 == '' entPhysicalIsFRU.9 == false(2) Bierman & McCloghrie Standards Track [Page 53] RFC 4133 Entity MIB (Version 3) August 2005 entPhysicalDescr.10 == 'Acme 10Base-T Port RB' entPhysicalVendorType.10 == acmeProducts.portTypes.10 entPhysicalContainedIn.10 == 7 entPhysicalClass.10 == port(10) entPhysicalParentRelPos.10 == 3 entPhysicalName.10 == 'Ethernet-C' entPhysicalHardwareRev.10 == 'B(1.02.07)' entPhysicalSoftwareRev.10 == '' entPhysicalFirmwareRev.10 == '1.4' entPhysicalSerialNum.10 == '' entPhysicalMfgName.10 == 'Acme' entPhysicalModelName.10 == 'RB' entPhysicalAlias.10 == '' entPhysicalAssetID.10 == '' entPhysicalIsFRU.10 == false(2) entPhysicalDescr.11 == 'Acme 10Base-T Port RB' entPhysicalVendorType.11 == acmeProducts.portTypes.10 entPhysicalContainedIn.11 == 7 entPhysicalClass.11 == port(10) entPhysicalParentRelPos.11 == 4 entPhysicalName.11 == 'Ethernet-D' entPhysicalHardwareRev.11 == 'B(1.02.07)' entPhysicalSoftwareRev.11 == '' entPhysicalFirmwareRev.11 == '1.4' entPhysicalSerialNum.11 == '' entPhysicalMfgName.11 == 'Acme' entPhysicalModelName.11 == 'RB' entPhysicalAlias.11 == '' entPhysicalAssetID.11 == '' entPhysicalIsFRU.11 == false(2) Slot 2 contains another ethernet module with 2 ports. entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 entPhysicalContainedIn.12 = 5 entPhysicalClass.12 == module(9) entPhysicalParentRelPos.12 == 1 entPhysicalName.12 == 'M2' entPhysicalHardwareRev.12 == 'A(1.01.07)' entPhysicalSoftwareRev.12 == '1.8.4' entPhysicalFirmwareRev.12 == 'A(1.8)' entPhysicalSerialNum.12 == 'C100102384' entPhysicalMfgName.12 == 'Acme' entPhysicalModelName.12 == '4' entPhysicalAlias.12 == 'bldg09:floor1:devtest' entPhysicalAssetID.12 == '0007968462' entPhysicalIsFRU.12 == true(1) Bierman & McCloghrie Standards Track [Page 54] RFC 4133 Entity MIB (Version 3) August 2005 entPhysicalDescr.13 == 'Acme 802.3 AUI Port' entPhysicalVendorType.13 == acmeProducts.portTypes.11 entPhysicalContainedIn.13 == 12 entPhysicalClass.13 == port(10) entPhysicalParentRelPos.13 == 1 entPhysicalName.13 == 'AUI' entPhysicalHardwareRev.13 == 'A(1.06F)' entPhysicalSoftwareRev.13 == '' entPhysicalFirmwareRev.13 == '1.5' entPhysicalSerialNum.13 == '' entPhysicalMfgName.13 == 'Acme' entPhysicalModelName.13 == '' entPhysicalAlias.13 == '' entPhysicalAssetID.13 == '' entPhysicalIsFRU.13 == false(2) entPhysicalDescr.14 == 'Acme 10Base-T Port RD' entPhysicalVendorType.14 == acmeProducts.portTypes.14 entPhysicalContainedIn.14 == 12 entPhysicalClass.14 == port(10) entPhysicalParentRelPos.14 == 2 entPhysicalName.14 == 'E2' entPhysicalHardwareRev.14 == 'B(1.01.02)' entPhysicalSoftwareRev.14 == '' entPhysicalFirmwareRev.14 == '2.1' entPhysicalSerialNum.14 == '' entPhysicalMfgName.14 == 'Acme' entPhysicalModelName.14 == '' entPhysicalAlias.14 == '' entPhysicalAssetID.14 == '' entPhysicalIsFRU.14 == false(2) Logical entities -- entLogicalTable; with SNMPv3 support Repeater 1--comprised of any ports attached to backplane 1 entLogicalDescr.1 == 'Acme repeater v3.1' entLogicalType.1 == snmpDot3RptrMgt entLogicalCommunity.1 'public-repeater1' entLogicalTAddress.1 == 192.0.2.1:161 entLogicalTDomain.1 == snmpUDPDomain entLogicalContextEngineID.1 == '80000777017c7d7e7f'H entLogicalContextName.1 == 'repeater1' Repeater 2--comprised of any ports attached to backplane 2: entLogicalDescr.2 == 'Acme repeater v3.1' entLogicalType.2 == snmpDot3RptrMgt entLogicalCommunity.2 == 'public-repeater2' entLogicalTAddress.2 == 192.0.2.1:161 entLogicalTDomain.2 == snmpUDPDomain Bierman & McCloghrie Standards Track [Page 55] RFC 4133 Entity MIB (Version 3) August 2005 entLogicalContextEngineID.2 == '80000777017c7d7e7f'H entLogicalContextName.2 == 'repeater2' Logical to Physical Mappings -- entLPMappingTable: repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 [ed. -- Note that a mapping to the module is not included, because this example represents a port-switchable hub. Even though all ports on the module could belong to the same repeater as a matter of configuration, the LP port mappings should not be replaced dynamically with a single mapping for the module (e.g., entLPPhysicalIndex.1.7). If all ports on the module shared a single backplane connection, then a single mapping for the module would be more appropriate.] entLPPhysicalIndex.1.2 == 2 entLPPhysicalIndex.1.8 == 8 entLPPhysicalIndex.1.9 == 9 entLPPhysicalIndex.1.13 == 13 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 entLPPhysicalIndex.2.3 == 3 entLPPhysicalIndex.2.10 == 10 entLPPhysicalIndex.2.11 == 11 entLPPhysicalIndex.2.14 == 14 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: Repeater Port Identifier values are shared by both repeaters: entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 Physical Containment Tree -- entPhysicalContainsTable chassis has two backplanes and three containers: entPhysicalChildIndex.1.2 == 2 entPhysicalChildIndex.1.3 == 3 entPhysicalChildIndex.1.4 == 4 entPhysicalChildIndex.1.5 == 5 entPhysicalChildIndex.1.6 == 6 container 1 has a module: entPhysicalChildIndex.4.7 == 7 container 2 has a module entPhysicalChildIndex.5.12 == 12 Bierman & McCloghrie Standards Track [Page 56] RFC 4133 Entity MIB (Version 3) August 2005 [ed. -- in this example, container 3 is empty.] module 1 has 4 ports: entPhysicalChildIndex.7.8 == 8 entPhysicalChildIndex.7.9 == 9 entPhysicalChildIndex.7.10 == 10 entPhysicalChildIndex.7.11 == 11 module 2 has 2 ports: entPhysicalChildIndex.12.13 == 13 entPhysicalChildIndex.12.14 == 14 5. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information. These are: entPhysicalDescr entPhysicalVendorType entPhysicalHardwareRev entPhysicalFirmwareRev entPhysicalSoftwareRev entPhysicalSerialNum entPhysicalMfgName entPhysicalModelName These objects expose information about the physical entities within a managed system, which may be used to identify the vendor, model, and version information of each system component. entPhysicalAssetID This object can allow asset identifiers for various system components to be exposed, in the event this MIB object is actually configured by an NMS application. entLogicalDescr entLogicalType These objects expose the type of logical entities present in the managed system. Bierman & McCloghrie Standards Track [Page 57] RFC 4133 Entity MIB (Version 3) August 2005 entLogicalCommunity This object exposes community names associated with particular logical entities within the system. entLogicalTAddress entLogicalTDomain These objects expose network addresses that can be used to communicate with an SNMP agent on behalf of particular logical entities within the system. entLogicalContextEngineID entLogicalContextName These objects identify the authoritative SNMP engine that contains information on behalf of particular logical entities within the system. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View-based Access Control Model RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- entityMIB { mib-2 47 } Bierman & McCloghrie Standards Track [Page 58] RFC 4133 Entity MIB (Version 3) August 2005 7. Acknowledgements This memo has been produced by the IETF's Entity MIB working group. 8. References 8.1. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 8.2. Informative References [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [RFC1516] McMaster, D. and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices", RFC 1516, September 1993. Bierman & McCloghrie Standards Track [Page 59] RFC 4133 Entity MIB (Version 3) August 2005 [RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2", RFC 2037, October 1996. [RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997. [RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC 2737, December 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the CLEI Code", RFC 4152, August 2005. [T1.213] ATIS T1.213-2001, "Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange", 2001, www.ansi.org. [T1.213a] ATIS T1.213a, "Supplement to T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, to correct the representation of the Basic Code in Figure B.1", 2001, www.ansi.org. Bierman & McCloghrie Standards Track [Page 60] RFC 4133 Entity MIB (Version 3) August 2005 Authors' Addresses Andy Bierman EMail: ietf@andybierman.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408-526-5260 EMail: kzm@cisco.com Bierman & McCloghrie Standards Track [Page 61] RFC 4133 Entity MIB (Version 3) August 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bierman & McCloghrie Standards Track [Page 62] snmp-mibs-downloader-1.1/mibrfcs/rfc4149.txt0000644000000000000000000023134011402176072015567 0ustar Network Working Group C. Kalbfleisch Request for Comments: 4149 Consultant Category: Standards Track R. Cole JHU/APL D. Romascanu Avaya August 2005 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. Kalbfleisch, et al. Standards Track [Page 1] RFC 4149 SSPM-MIB August 2005 Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Overview ........................................................3 3.1. Terms ......................................................3 4. Relationship to Other MIB modules ...............................4 5. Relationship to Other Work ......................................4 5.1. IPPM .......................................................4 5.2. DISMAN .....................................................5 5.3. RMON .......................................................6 5.4. ApplMIB ....................................................6 5.5. SNMPCONF ...................................................7 5.6. RTFM .......................................................8 5.7. Relationship to Other Work: Summary ........................8 6. MIB Structure ...................................................9 6.1. General Information .......................................10 6.2. Source Configuration ......................................10 6.3. Sink Configuration ........................................10 7. Definitions ....................................................10 8. Security Considerations ........................................32 9. Acknowledgements ...............................................34 10. Normative References ..........................................34 11. Informative References ........................................36 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a method of describing Synthetic Sources for Performance Monitoring (SSPM). This is useful within the Remote Monitoring (RMON) framework [RFC3577] for performance monitoring in the cases where it is desirable to inject packets into the network for the purpose of monitoring their performance with the other MIBs in that framework. This memo also includes a MIB module. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Kalbfleisch, et al. Standards Track [Page 2] RFC 4149 SSPM-MIB August 2005 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview This document defines a MIB module for the purpose of remotely controlling synthetic sources (or 'active' probes) and sinks in order to enhance remote performance monitoring capabilities within IP networks and services. Much work within the IETF exists related to performance monitoring. One interesting aspect of this body of work is that it does not explicitly define an 'active' probe capability. An active probe capability is complimentary to existing capabilities, and this MIB module is developed to fill this void. 3.1. Terms The following definitions apply throughout this document: o 'Performance monitoring' is the act of monitoring traffic for the purpose of evaluating a statistic of a metric related to the performance of the system. A performance monitoring system is comprised of a) traffic generators, b) measurement, c) data reduction, and d) reporting. The traffic generators may be natural sources, synthetic sources, or intrusive sources. o A 'synthetic source' is a device or an embedded software program that generates a data packet (or packets) and injects it (or them) onto the path to a corresponding probe or existing server solely in support of a performance monitoring function. A synthetic source may talk intrusively to existing application servers. The design goals for this MIB module are: o Complementing the overall performance management architecture being defined within the RMONMIB WG; refer to the RMONMIB framework document [RFC3577]. This MIB module is defined within the context of the APM-MIB [RFC3729]. o Extensibility: the MIB module should be easily extended to include a greater set of protocols and applications for performance monitoring purposes. Kalbfleisch, et al. Standards Track [Page 3] RFC 4149 SSPM-MIB August 2005 o Flexibility: the module should support both round-trip and one- way measurements. o Security: the control of the source and sink of traffic is handled by a management application, and communication is recommended via SNMPv3. This document is organized as follows. The next section discusses the relationship of this MIB module to others from the RMONMIB and Distributed Management (DISMAN) working groups. Then the structure of the MIB module is discussed. Finally, the MIB module definitions are given. 4. Relationship to Other MIB modules This MIB module is designed to be used in conjunction with the RMON MIB Working Group's two other MIB modules for application performance measurement: Application Performance Measurement MIB [RFC3729] and Transport Performance Metrics MIB [RFC4150]. These MIB modules define reporting capabilities for that framework. The intent of this MIB module is to define a method for injecting packets into the network utilizing probe capabilities defined in the base MIB modules and measured with the reporting MIB modules. Other reporting MIB modules may be used as well. Specifically, this MIB module uses the AppLocalIndex as defined in the APM-MIB to map measurement configuration information to definition and reporting structures defined in the APM-MIB. 5. Relationship to Other Work Much work has already been done within the IETF that has a direct bearing on the development of active performance probe definitions. This body of work has been addressed in various working groups over the years. In this section, we focus on the work of a) the IP Performance Metrics (IPPM) working group, b) the DISMAN working group, c) the RMON working group, d) the Application MIB (ApplMIB) working group, and e) the Realtime Traffic Flow Measurement (RTFM) working group. 5.1. IPPM The IPPM working group has defined in detail a set of performance metrics, sampling techniques, and associated statistics for transport-level or connectivity-level measurements. The IPPM framework document [RFC2330] discusses numerous issues concerning sampling techniques, clock accuracy, resolution and skew, wire time versus host time, error analysis, etc. Many of these are Kalbfleisch, et al. Standards Track [Page 4] RFC 4149 SSPM-MIB August 2005 considerations for configuration and implementation issues discussed below. The IPPM working group has defined several metrics and their associated statistics, including + a connectivity metric [RFC2678], + one-way delay metric [RFC2679], + one-way loss metric [RFC2680], + round-trip delay and loss metrics [RFC2681], + delay variation metric [RFC3393], + a streaming media metric [RFC3432], + a throughput metric [EBT] and [TBT], and + others are under development. These (or a subset) could form the basis for a set of active, connectivity-level, probe types designed for monitoring the quality of transport services. A consideration of some of these metrics may form a set of work activities and a set of early deliverables for a group developing an active probe capability. During the early development of the SSPM-MIB, it became apparent that a one-way measurement protocol was required in order for the SSPM-MIB to control a one-way measurement. This led to the current work with the IPPM WG on the development of the One-Way Measurement Protocol (OWDP) [ODP]. This work includes both the measurement protocol itself, as well as the development of a separate control protocol. This later control protocol is redundant with the current work on the SSPM-MIB. The SSPM-MIB could be used as an alternative to the one- way delay control protocol. 5.2. DISMAN The DISMAN working group has defined a set of 'active' tools for remote management. Of relevance to this document are: + the pingMIB [RFC2925], + the DNS Lookup MIB [RFC2925], + the tracerouteMIB [RFC2925], Kalbfleisch, et al. Standards Track [Page 5] RFC 4149 SSPM-MIB August 2005 + the scriptMIB [RFC3165], and + the expressionMIB [RFC2982]. The pingMIB and tracerouteMIB define an active probe capability, primarily for the remote determination of path and path connectivity. There are some performance-related metrics collected from the pingMIB, and one could conceivably use these measurements for the evaluation of a limited set of performance statistics. But there is a fundamental difference between determining connectivity and determining the quality of that connectivity. However, in the context of performance monitoring, a fault can be viewed as not performing at all. Therefore, both should be monitored with the same probes to reduce network traffic. The DNS Lookup MIB also includes some probe-like capabilities and performance time measurements for the DNS lookup. This could be used to suggest details of a related session-level, active probe. The scriptMIB allows a network management application to distribute and manage scripts to remote devices. Conceivably, these scripts could be designed to run a set of active probe monitors on remote devices. 5.3. RMON The RMON working group has developed an extensive, passive monitoring capability defined in RFC 2819 [RFC2819] and RFC 2021 [RFC2021] as well as additional MIB modules. Initially, the monitors collected statistics at the MAC layer, but the capability has now been extended to higher-layer statistics. Higher-layer statistics are identified through the definition of a Protocol Directory [RFC2021]. See the RMONMIB framework document [RFC3577] for an overview of the RMONMIB capabilities. Within this context, the development of an active traffic source for performance monitoring fits well within the overall performance monitoring architecture being defined within the RMON WG. 5.4. ApplMIB The ApplMIB working group defined a series of MIB modules that monitor various aspects of applications, processes, and services. The System Application MIB [RFC2287] describes a basic set of managed objects for fault, configuration, and performance management of applications from a systems perspective. More specifically, the managed objects it defines are restricted to information that can be Kalbfleisch, et al. Standards Track [Page 6] RFC 4149 SSPM-MIB August 2005 determined from the system itself and that does not require special instrumentation within the applications to make the information available. The Application MIB [RFC2564] complements the System Application MIB, providing for the management of applications' common attributes, which could not typically be observed without the cooperation of the software being managed. There are attributes that provide information on application and communication performance. The WWW MIB [RFC2594] describes a set of objects for managing networked services in the Internet Community, particularly World Wide Web (WWW) services. Performance attributes are available for the information about each WWW service, each type of request, each type of response, and top-accessed documents. In the development of synthetic application-level probes, consideration should be given to the relationship of the application MIB modules to the measurements being performed through a synthetic application-level probe. Similar, cross-indexing issues arise within the context of the RMON monitoring and synthetic application-level active probes. 5.5. SNMPCONF The Configuration Management with SNMP (SNMPCONF) working group has created the informational RFC 3512 [RFC3512], which outlines the most effective methods for using the SNMP Framework to accomplish configuration management. This work includes recommendations for device-specific as well as network-wide (Policy) configuration. The group is also chartered to write any MIB modules necessary to facilitate configuration management. Specifically, they will write a MIB module that describes a network entity's capabilities and capacities, which can be used by management entities making policy decisions at a network level or device-specific level. Currently, the SNMPCONF working group is focused on the SNMP Configuration MIB for policy [RFC4011]. It is conceivable that one would want to monitor the performance of newly configured policies as they are implemented within networks. This would require correlation of the implemented policy and a related performance monitoring policy that would specify synthetic probe definitions. For synthetic probes, there would be a need for a configuration of a) a single probe, b) several probes, c) source and destination probes, and d) intermediate probes. In addition, it may be necessary to configure any or all of these combinations simultaneously. It is hoped that the work of SNMPCONF will suffice. The scripting language defined by the SNMP Configuration MIB could allow for active monitoring to be Kalbfleisch, et al. Standards Track [Page 7] RFC 4149 SSPM-MIB August 2005 activated and configured from a policy management script. Further, the results of active monitoring could become arguments in further policy decisions. This notion is reflected in the decision flow outlined in Figure 1 below. 5.6. RTFM The Realtime Traffic Flow Measurement (RTFM) working group is concerned with issues relating to traffic flow measurements and usage reporting for network traffic and Internet accounting. Various documents exist that describe requirements [RFC1272], traffic flow measurement architectures [RFC2722], and a traffic flow MIB [RFC2720]. The work in this group is focused on passive measurements of user traffic. As such, its work is related to the monitoring work within the RMON WG. Fundamentally, their attention has not been concerned with methods of active traffic generation. 5.7. Relationship to Other Work: Summary In summary, the development of an active traffic generation capability (primarily for the purpose of performance monitoring) should draw upon various activities, both past and present, within the IETF. Figure 1 shows the relationship of the various work activities briefly touched upon in this section. Horizontally, across the top of the figure are overall control functions, which would coordinate the various aspects of the performance monitoring systems. Vertically at the bottom of the figure are the functions which comprise the minimum performance monitoring capability; i.e., traffic generation, monitoring and measurements, and data reduction. Traffic generation is addressed in this MIB module. Monitoring and measurement is addressed in the APM-MIB [RFC3729] and TPM-MIB [RFC4150] modules. Data reduction is not yet addressed within the IETF. But data reduction could include both spatial and temporal aggregations at different levels of reduction. This is indicated in the figure by the arrow labeled "Various levels and span". Kalbfleisch, et al. Standards Track [Page 8] RFC 4149 SSPM-MIB August 2005 +-----------------------------------+ | | V | +------------------------------------------+ | +------| Application [script], [expr], [snmpconf],|---+ | | | [apmmib] | | | | +------------------------------------------+ | | | | | | +--------------------------------+ | | | Synchronization Control | | | +--------------------------------+ | | | | | | V V V | +----------------+ +----------------------+ +-------------------+ | | Traffic | |Monitoring Metrics | |Data Reduction | | | Generation | |Control [rmon],[ippm],| |Control [applmib], | | | Control [sspm]| | [applmib] | |[wwwservmib],[expr]| | +----------------+ +----------------------+ +-------------------+ | | | | | | | | | V V V | +------------------+ +-------------------+ +----------------+ | |Traffic Generation| |Monitoring Metrics | |Data Reduction | | | Instrumentation| | Instrumentation | +-->| Instrumentation| | +------------------+ +-------------------+ | +----------------+ | | | | | | | Various levels | | | and span +--------------| | | | | | V | Reports ---+ Figure 1: Coverage for an overall performance monitoring system 6. MIB Structure This section presents the structure of the MIB module. The objects are arranged into the following groups: o general information o source configuration o sink configuration Kalbfleisch, et al. Standards Track [Page 9] RFC 4149 SSPM-MIB August 2005 6.1. General Information This section provides general information about the capabilities of the probe. Currently, this information is related to the resolution of the probe clock and its source. 6.2. Source Configuration The source is configured with a pair of tables. The first, sspmSourceProfileTable, defines a set of profiles for monitoring. These profiles are then used by the second table, sspmSourceControlTable, to instantiate a specific measurement. This MIB module takes an IP-centric view of the configuration of the measurement. 6.3. Sink Configuration Configures the sink for measurements. If the test is round-trip, then this table is on the same probe as the source configuration. If the test is one-way, then the table is on a different probe. The sspmSinkInstance is a unique identifier for the entry per probe. Additional attributes are provided for test type and test source to identify entries in the table uniquely. 7. Definitions SSPM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Unsigned32 FROM SNMPv2-SMI --[RFC2578] TEXTUAL-CONVENTION, StorageType, TruthValue, RowStatus FROM SNMPv2-TC --[RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF --[RFC2578, -- RFC2579, -- RFC2580] OwnerString, rmon FROM RMON-MIB --[RFC2819] InetAddressType, InetAddress FROM INET-ADDRESS-MIB --[RFC3291] Kalbfleisch, et al. Standards Track [Page 10] RFC 4149 SSPM-MIB August 2005 InterfaceIndexOrZero FROM IF-MIB --[RFC2863] AppLocalIndex FROM APM-MIB --[RFC3729] Utf8String FROM SYSAPPL-MIB; --[RFC2287] sspmMIB MODULE-IDENTITY LAST-UPDATED "200507280000Z" -- July 28, 2005 ORGANIZATION "IETF RMON MIB working group" CONTACT-INFO " Carl W. Kalbfleisch Consultant E-mail: ietf@kalbfleisch.us Working group mailing list: rmonmib@ietf.org To subscribe send email to rmonmib-request@ietf.org" DESCRIPTION "This SSPM MIB module is applicable to probes implementing Synthetic Source for Performance Monitoring functions. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4149; see the RFC itself for full legal notices." -- revision history REVISION "200507280000Z" -- July 28, 2005 DESCRIPTION "The original version of this MIB module, was published as RFC4149." ::= { rmon 28 } -- -- Object Identifier Assignments -- sspmMIBObjects OBJECT IDENTIFIER ::= { sspmMIB 1 } sspmMIBNotifications OBJECT IDENTIFIER ::= { sspmMIB 2 } sspmMIBConformance OBJECT IDENTIFIER ::= { sspmMIB 3 } -- -- Textual Conventions -- Kalbfleisch, et al. Standards Track [Page 11] RFC 4149 SSPM-MIB August 2005 SspmMicroSeconds ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unit of time with resolution of MicroSeconds." SYNTAX Unsigned32 SspmClockSource ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An indication of the source of the clock as defined by the NTP specification RFC1305 [RFC1305] definition of stratum: Stratum (sys.stratum, peer.stratum, pkt.stratum): This is an integer indicating the stratum of the local clock, with values defined as follows: 0 unspecified 1 primary reference (e.g., calibrated atomic clock, radio clock) 2-255 secondary reference (via NTP)." REFERENCE "RFC1305." SYNTAX Integer32 (0..255) SspmClockMaxSkew ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current -- UNITS "Seconds" DESCRIPTION "An indication of the accuracy of the clock as defined by RFC1305. This variable indicates the maximum offset error due to skew of the local clock over the time interval 86400 seconds, in seconds." REFERENCE "RFC1305." SYNTAX Integer32 (1..65535) -- -- sspmGeneral -- sspmGeneral OBJECT IDENTIFIER ::= { sspmMIBObjects 1 } sspmGeneralClockResolution OBJECT-TYPE SYNTAX SspmMicroSeconds MAX-ACCESS read-only Kalbfleisch, et al. Standards Track [Page 12] RFC 4149 SSPM-MIB August 2005 STATUS current -- UNITS Microseconds DESCRIPTION "A read-only variable indicating the resolution of the measurements possible by this device." ::= { sspmGeneral 1 } sspmGeneralClockMaxSkew OBJECT-TYPE SYNTAX SspmClockMaxSkew MAX-ACCESS read-only STATUS current -- UNITS Seconds DESCRIPTION "A read-only variable indicating the maximum offset error due to skew of the local clock over the time interval 86400 seconds, in seconds." ::= { sspmGeneral 2 } sspmGeneralClockSource OBJECT-TYPE SYNTAX SspmClockSource MAX-ACCESS read-only STATUS current DESCRIPTION "A read-only variable indicating the source of the clock. This is provided to allow a user to determine how accurate the timing mechanism is compared with other devices. This is needed for the coordination of time values between probes for one-way measurements." ::= { sspmGeneral 3 } sspmGeneralMinFrequency OBJECT-TYPE SYNTAX SspmMicroSeconds MAX-ACCESS read-only -- units MicroSeconds STATUS current DESCRIPTION "A read-only variable that indicates the devices' capability for the minimum supported sspmSourceFrequency. If sspmSourceFrequency is set to a value lower than the value reported by this attribute, then the set of sspmSourceFrequency will fail with an inconsistent value error." ::= { sspmGeneral 4 } -- -- sspmCapabilities -- Kalbfleisch, et al. Standards Track [Page 13] RFC 4149 SSPM-MIB August 2005 -- Describes the capabilities of the SSPM device. -- sspmCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF SspmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of SSPM capabilities." ::= { sspmGeneral 5 } sspmCapabilitiesEntry OBJECT-TYPE SYNTAX SspmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Details about a particular SSPM capability." INDEX { sspmCapabilitiesInstance } ::= { sspmCapabilitiesTable 1 } SspmCapabilitiesEntry ::= SEQUENCE { sspmCapabilitiesInstance AppLocalIndex } sspmCapabilitiesInstance OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether SSPM configuration of the corresponding AppLocalIndex is supported by this device. Generally, entries in this table are only made by the device when the configuration of the measurement is available." ::= { sspmCapabilitiesEntry 1 } -- -- sspmSource -- -- Contains the details of the source of the -- Synthetic Sources for Performance Monitoring algorithms. -- This information is split into two tables. The first defines -- profiles that can be applied to specific sources in the -- control table. -- sspmSource OBJECT IDENTIFIER ::= { sspmMIBObjects 2 } -- -- sspmSourceProfileTable -- Defines template profiles for measurements. Kalbfleisch, et al. Standards Track [Page 14] RFC 4149 SSPM-MIB August 2005 -- sspmSourceProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF SspmSourceProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of SSPM Source Profiles configured." ::= { sspmSource 1 } sspmSourceProfileEntry OBJECT-TYPE SYNTAX SspmSourceProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Details about a particular SSPM Source Profile configuration. Entries must exist in this table in order to be referenced by rows in the sspmSourceControlTable." INDEX { sspmSourceProfileInstance } ::= { sspmSourceProfileTable 1 } SspmSourceProfileEntry ::= SEQUENCE { sspmSourceProfileInstance Unsigned32, sspmSourceProfileType AppLocalIndex, sspmSourceProfilePacketSize Unsigned32, sspmSourceProfilePacketFillType INTEGER, sspmSourceProfilePacketFillValue OCTET STRING, sspmSourceProfileTOS Integer32, sspmSourceProfileFlowLabel Integer32, sspmSourceProfileLooseSrcRteFill OCTET STRING, sspmSourceProfileLooseSrcRteLen Integer32, sspmSourceProfileTTL Integer32, sspmSourceProfileNoFrag TruthValue, sspmSourceProfile8021Tagging Integer32, sspmSourceProfileUsername Utf8String, sspmSourceProfilePassword Utf8String, sspmSourceProfileParameter OCTET STRING, sspmSourceProfileOwner OwnerString, sspmSourceProfileStorageType StorageType, sspmSourceProfileStatus RowStatus } sspmSourceProfileInstance OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary index." Kalbfleisch, et al. Standards Track [Page 15] RFC 4149 SSPM-MIB August 2005 ::= { sspmSourceProfileEntry 1 } sspmSourceProfileType OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The AppLocalIndex value that uniquely identifies the measurement per the APM-MIB. In order to create a row in this table, there must be a corresponding row in the sspmCapabilitiesTable. When attempting to set this object, if no corresponding row exists in the sspmCapabilitiesTable, then the agent should return a 'badValue' error." ::= { sspmSourceProfileEntry 2} sspmSourceProfilePacketSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The size of packet to be transmitted in bytes. The size accounts for all data within the IPv4 or IPv6 payloads, excluding the IP headers, IP header options and link-level protocol headers. If the size is set smaller than the minimum allowed packet size or greater than the maximum allowed packet size, then the set should fail, and the agent should return a 'badValue' error." ::= { sspmSourceProfileEntry 3 } sspmSourceProfilePacketFillType OBJECT-TYPE SYNTAX INTEGER { random (1), pattern (2), url(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates how the packet is filled. 'random' indicates that the packet contains random data patterns. This is probe and implementation dependent. Kalbfleisch, et al. Standards Track [Page 16] RFC 4149 SSPM-MIB August 2005 'pattern' indicates that the pattern defined in the sspmSourceProfilePacketFillValue attribute is used to fill the packet. 'url' indicates that the value of sspmSourceProfilePacketFillValue should contain a URL. The contents of the document at that URL are retrieved when sspmSourceStatus becomes active and utilized in the packet. If the attempt to access that URL fails, then the row status is set to 'notReady', and the set should fail with 'inconsistentValue'. This value must contain a dereferencable URL of the type 'http:', 'https:', or 'ftp:' only." ::= { sspmSourceProfileEntry 4 } sspmSourceProfilePacketFillValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "The string value with which to fill the packet. If sspmSourceProfilePacketFillType is set to 'pattern', then this pattern is repeated until the packet is sspmSourcePacketSize in bytes. Note that if the length of the octet string specified for this value does not divide evenly into the packet size, then an incomplete last copy of this data may be copied into the packet. If the value of sspmSourceProfilePacketFillType is set to 'random', then this attribute is unused. If the value of the sspmSourceProfilePacketFillType is set to 'url', then the URL specified in this attribute is retrieved and used by the probe. In the case of a URL, this value must contain a dereferencable URL of the type 'http:', 'https:', or 'ftp:' only." ::= { sspmSourceProfileEntry 5 } sspmSourceProfileTOS OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the TOS field in the IP packet header. The value of this object defaults to zero if not set." DEFVAL { 0 } ::= { sspmSourceProfileEntry 6 } Kalbfleisch, et al. Standards Track [Page 17] RFC 4149 SSPM-MIB August 2005 sspmSourceProfileFlowLabel OBJECT-TYPE SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to specify the Flow Label in a IPv6 packet (RFC 2460) to force special handling by the IPv6 routers; e.g., non-default quality-of-service handling. This object is meaningful only when the object sspmSourceDestAddressType is IPv6(2). The value of this object defaults to zero if not set." DEFVAL { 0 } ::= { sspmSourceProfileEntry 7 } sspmSourceProfileLooseSrcRteFill OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..240)) MAX-ACCESS read-create STATUS current DESCRIPTION "In the event that the test should run over a specific route, the intent is to force the route using the Loose Source Route option in IPv4 [RFC791] and IPv6 [RFC2460]. This object contains a series of IP addresses along the path that would be put into the loose source route option in the IP header. The IPv4 addresses are to be listed as 32-bit address values, and the IPv6 addresses are to be listed as a string of 128-bit addresses. The maximum length allowed within the IPv4 source route option is 63 addresses. To simply account for IPv6 addresses as well, the maximum length of the octet string is 240. This allows up to 60 IPv4 addresses or up to 15 IPv6 addresses in the string." ::= { sspmSourceProfileEntry 8 } sspmSourceProfileLooseSrcRteLen OBJECT-TYPE SYNTAX Integer32(0..240) MAX-ACCESS read-create STATUS current DESCRIPTION "In the event that the test should run over a specific route, the intent is to force the route. This attribute specifies the length of data to be copied from the sspmSourceProfileLooseSrcRteFill into the route data fields of the loose source route Kalbfleisch, et al. Standards Track [Page 18] RFC 4149 SSPM-MIB August 2005 options in the IPv4 or IPv6 headers." ::= { sspmSourceProfileEntry 9 } sspmSourceProfileTTL OBJECT-TYPE SYNTAX Integer32(1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "If non-zero, this specifies the value to place into the TTL field on transmission." ::= { sspmSourceProfileEntry 10 } sspmSourceProfileNoFrag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "When true, the 'Don't Fragment Bit' should be set on the packet header." ::= { sspmSourceProfileEntry 11 } sspmSourceProfile8021Tagging OBJECT-TYPE SYNTAX Integer32 (-1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "IEEE 802.1Q tagging used in IEEE 802.1D bridged environments. A value of -1 indicates that the packets are untagged. A value of 0 to 65535 is the value of the tag to be inserted in the tagged packets. Note that according to IEEE 802.1Q, VLAN-ID tags with a value of 4095 shall not be transmitted on the wire. As the VLAN-ID is encoded in the 12 least significant bits on the tag, values that translate in a binary representation of all 1's in the last 12 bits SHALL NOT be configured. In this case, the set should fail, and return an error-status of 'inconsistentValue'." ::= { sspmSourceProfileEntry 12 } sspmSourceProfileUsername OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-create STATUS current DESCRIPTION Kalbfleisch, et al. Standards Track [Page 19] RFC 4149 SSPM-MIB August 2005 "An optional username used by the application protocol." ::= { sspmSourceProfileEntry 13 } sspmSourceProfilePassword OBJECT-TYPE SYNTAX Utf8String MAX-ACCESS read-create STATUS current DESCRIPTION "An optional password used by the application protocol." ::= { sspmSourceProfileEntry 14 } sspmSourceProfileParameter OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..65535)) MAX-ACCESS read-create STATUS current DESCRIPTION "An optional parameter used by the application protocol. For DNS, this would be the hostname or IP. For HTTP, this would be the URL. For nntp, this would be the news group. For TCP, this would be the port number. For SMTP, this would be the recipient (and could assume the message is predefined)." ::= { sspmSourceProfileEntry 15 } sspmSourceProfileOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Name of the management station/application that set up the profile." ::= { sspmSourceProfileEntry 16 } sspmSourceProfileStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this sspmSourceProfileEntry. If the value of this object is 'permanent', no objects in this row need to be writable." ::= { sspmSourceProfileEntry 17 } sspmSourceProfileStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Kalbfleisch, et al. Standards Track [Page 20] RFC 4149 SSPM-MIB August 2005 "Status of this profile. An entry may not exist in the active state unless all objects in the entry have an appropriate value. Once this object is set to active(1), no objects in the sspmSourceProfileTable can be changed." ::= { sspmSourceProfileEntry 18 } -- -- sspmSourceControlTable -- Defines specific measurement instances based on template -- profiles in the sspmSourceProfileTable which must be -- pre-configured. -- sspmSourceControlTable OBJECT-TYPE SYNTAX SEQUENCE OF SspmSourceControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of SSPM measurements configured." ::= { sspmSource 2 } sspmSourceControlEntry OBJECT-TYPE SYNTAX SspmSourceControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Details about a particular SSPM configuration." INDEX { sspmSourceControlInstance } ::= { sspmSourceControlTable 1 } SspmSourceControlEntry ::= SEQUENCE { sspmSourceControlInstance Unsigned32, sspmSourceControlProfile Integer32, sspmSourceControlSrc InterfaceIndexOrZero, sspmSourceControlDestAddrType InetAddressType, sspmSourceControlDestAddr InetAddress, sspmSourceControlEnabled TruthValue, sspmSourceControlTimeOut SspmMicroSeconds, sspmSourceControlSamplingDist INTEGER, sspmSourceControlFrequency SspmMicroSeconds, sspmSourceControlFirstSeqNum Unsigned32, sspmSourceControlLastSeqNum Unsigned32, sspmSourceControlOwner OwnerString, sspmSourceControlStorageType StorageType, sspmSourceControlStatus RowStatus Kalbfleisch, et al. Standards Track [Page 21] RFC 4149 SSPM-MIB August 2005 } sspmSourceControlInstance OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary index." ::= { sspmSourceControlEntry 1 } sspmSourceControlProfile OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to the profile (sspmSourceProfileEntry) that this control entry uses to define the test being performed." ::= { sspmSourceControlEntry 2 } sspmSourceControlSrc OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex where the packet should originate from the probe (if it matters). A value of zero indicates that it does not matter and that the device decides." ::= { sspmSourceControlEntry 3 } sspmSourceControlDestAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address by which the destination is accessed." ::= { sspmSourceControlEntry 4 } sspmSourceControlDestAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Internet address for the destination. The formatting of this object is controlled by the sspmSourceControlDestAddrType object above. Kalbfleisch, et al. Standards Track [Page 22] RFC 4149 SSPM-MIB August 2005 When this object contains a DNS name, then the name is resolved to an address each time measurement is to be made. Further, the agent should not cache this address, but instead should perform the resolution prior to each measurement." ::= { sspmSourceControlEntry 5 } sspmSourceControlEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "When set to 'true', this test is enabled. When set to 'false', it is disabled." ::= { sspmSourceControlEntry 6 } sspmSourceControlTimeOut OBJECT-TYPE SYNTAX SspmMicroSeconds MAX-ACCESS read-create STATUS current DESCRIPTION "Timeout value for the measurement response. If no response is received in the time specified, then the test fails." ::= { sspmSourceControlEntry 7 } sspmSourceControlSamplingDist OBJECT-TYPE SYNTAX INTEGER { deterministic(1), poisson(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "When this attribute is set to 'deterministic', then packets are generated at with a fixed inter-packet injection time specified by sspmSourceFrequency. When this attribute is set to 'Poisson', then packets are generated with inter-packet injection times sampled from an exponential distribution with the single distributional parameter determined by the inverse frequency)." ::= { sspmSourceControlEntry 8 } sspmSourceControlFrequency OBJECT-TYPE SYNTAX SspmMicroSeconds MAX-ACCESS read-create Kalbfleisch, et al. Standards Track [Page 23] RFC 4149 SSPM-MIB August 2005 STATUS current DESCRIPTION "The inverse of this value is the rate at which packets are generated. Refer to sspmSourceSamplingDistribution. If the value set is less than the value of sspmGeneralMinFrequency, then the set will fail with an error-status of 'inconsistentValue'." ::= { sspmSourceControlEntry 9 } sspmSourceControlFirstSeqNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The first sequence number of packets to be transmitted." ::= { sspmSourceControlEntry 10 } sspmSourceControlLastSeqNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The last sequence number transmitted. This value is updated by the agent after packet generation." ::= { sspmSourceControlEntry 11 } sspmSourceControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Name of the management station/application that set up the test." ::= { sspmSourceControlEntry 12 } sspmSourceControlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this sspmSourceControlEntry. If the value of this object is 'permanent', no objects in this row need to be writable." ::= { sspmSourceControlEntry 13 } sspmSourceControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Kalbfleisch, et al. Standards Track [Page 24] RFC 4149 SSPM-MIB August 2005 STATUS current DESCRIPTION "Status of this source control entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. When this attribute has the value of 'active', none of the read-write or read-create attributes in this table may be modified, with the exception of sspmSourceControlEnabled." ::= { sspmSourceControlEntry 14 } -- -- sspmSinkTable -- -- Contains attributes for configuration of Synthetic -- Sources for Performance Monitoring sinks, i.e., -- sinks for receipt of one-way delay measurements. -- sspmSink OBJECT IDENTIFIER ::= { sspmMIBObjects 5 } sspmSinkTable OBJECT-TYPE SYNTAX SEQUENCE OF SspmSinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table configuring the sink for measurements." ::= { sspmSink 1 } sspmSinkEntry OBJECT-TYPE SYNTAX SspmSinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The details of a particular sink entry. If the measurement is a round-trip type, then the sink entry will be on the same probe as the corresponding sspmSourceEntry. If the measurement is a one-way, type then the sink entry will be on a different probe." INDEX { sspmSinkInstance } ::= { sspmSinkTable 1} SspmSinkEntry ::= SEQUENCE { sspmSinkInstance Unsigned32, sspmSinkType AppLocalIndex, sspmSinkSourceAddressType InetAddressType, sspmSinkSourceAddress InetAddress, Kalbfleisch, et al. Standards Track [Page 25] RFC 4149 SSPM-MIB August 2005 sspmSinkExpectedRate SspmMicroSeconds, sspmSinkEnable TruthValue, sspmSinkExpectedFirstSequenceNum Unsigned32, sspmSinkLastSequenceNumber Unsigned32, sspmSinkLastSequenceInvalid Counter32, sspmSinkStorageType StorageType, sspmSinkStatus RowStatus } sspmSinkInstance OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index. When the measurement is for a round-trip measurement, then this table entry is on the same probe as the corresponding sspmSourceEntry, and the value of this attribute should correspond to the value of sspmSourceInstance. Management applications configuring sinks for one-way measurements could define some scheme whereby the sspmSinkInstance is unique across all probes. Note that the unique key to this entry is also constructed with sspmSinkType, sspmSinkSourceAddressType, and sspmSinkSourceAddress. To make the implementation simpler, those other attributes are not included in the index but uniqueness is still needed to receive all the packets." ::= { sspmSinkEntry 1 } sspmSinkType OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The AppLocalIndex value that uniquely identifies the measurement per the APM-MIB. In order to create a row in this table, there must be a corresponding row in the sspmCapabilitiesTable. If there is no corresponding row in the sspmCapabilitiestable, then the agent will return an error-status of 'inconsistentValue'." ::= { sspmSinkEntry 2} sspmSinkSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address of the source." Kalbfleisch, et al. Standards Track [Page 26] RFC 4149 SSPM-MIB August 2005 ::= { sspmSinkEntry 3 } sspmSinkSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Internet address of the source. The formatting of this object is controlled by the sspmSinkSourceAddressType object above. This object should be set only to a valid device address that has been administratively configured into the device. If a set attempts to set this object to an address that does not belong (i.e., is not administratively configured into the device), the set should fail, and the agent should return a error-status of 'inconsistentValue'." ::= { sspmSinkEntry 4 } sspmSinkExpectedRate OBJECT-TYPE SYNTAX SspmMicroSeconds MAX-ACCESS read-create STATUS current DESCRIPTION "The expected rate at which packets will arrive." ::= { sspmSinkEntry 5 } sspmSinkEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates if the sink is enabled or not." ::= { sspmSinkEntry 6 } sspmSinkExpectedFirstSequenceNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The expected first sequence number of packets. This is used by the sink to determine if packets were lost at the initiation of the test." ::= { sspmSinkEntry 7 } sspmSinkLastSequenceNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Kalbfleisch, et al. Standards Track [Page 27] RFC 4149 SSPM-MIB August 2005 STATUS current DESCRIPTION "The last sequence number received." ::= { sspmSinkEntry 8 } sspmSinkLastSequenceInvalid OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that arrived whose sequence number was not one plus the value of sspmSinkLastSequenceNumber." ::= { sspmSinkEntry 9 } sspmSinkStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this sspmSinkEntry. If the value of this object is 'permanent', no objects in this row need to be writable." ::= { sspmSinkEntry 10 } sspmSinkStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Status of this conceptual row. An entry may not exist in the active state unless all objects in the entry have an appropriate value. Once this object is set to active(1), no objects with MAX-ACCESS of read-create in the sspmSinkTable can be changed." ::= { sspmSinkEntry 11 } -- -- Notifications -- -- -- Conformance information -- sspmCompliances OBJECT IDENTIFIER ::= { sspmMIBConformance 1 } sspmGroups OBJECT IDENTIFIER ::= { sspmMIBConformance 2 } Kalbfleisch, et al. Standards Track [Page 28] RFC 4149 SSPM-MIB August 2005 -- Compliance Statements sspmGeneralCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A general compliance that allows all things to be optional." MODULE -- this module MANDATORY-GROUPS { sspmGeneralGroup } GROUP sspmSourceGroup DESCRIPTION "The SSPM Source Group is optional." GROUP sspmSinkGroup DESCRIPTION "The SSPM Sink Group is optional." GROUP sspmUserPassGroup DESCRIPTION "The SSPM User Pass Group is optional." ::= { sspmCompliances 1 } -- -- SSPM Source Compliance -- sspmSourceFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A source compliance. Use this compliance when implementing a traffic-source-only device. This is useful for implementing devices that probe other devices for intrusive application monitoring. It is also useful for implementing the source of one-way tests used with a sink-only device." MODULE -- this module MANDATORY-GROUPS { sspmGeneralGroup, sspmSourceGroup } GROUP sspmUserPassGroup DESCRIPTION "The SSPM User Pass Group is optional." ::= { sspmCompliances 2 } -- -- SSPM Sink Compliance -- sspmSinkFullCompliance MODULE-COMPLIANCE STATUS current Kalbfleisch, et al. Standards Track [Page 29] RFC 4149 SSPM-MIB August 2005 DESCRIPTION "A sink-only compliance. Use this compliance when implementing a sink-only device. This is useful for devices to receive one-way measurements." MODULE -- this module MANDATORY-GROUPS { sspmGeneralGroup, sspmSinkGroup } ::= { sspmCompliances 3 } -- -- Groups -- sspmGeneralGroup OBJECT-GROUP OBJECTS { sspmGeneralClockResolution, sspmGeneralClockMaxSkew, sspmGeneralClockSource, sspmGeneralMinFrequency, sspmCapabilitiesInstance } STATUS current DESCRIPTION "The objects in the SSPM General Group." ::= { sspmGroups 1 } sspmSourceGroup OBJECT-GROUP OBJECTS { sspmSourceProfileType, sspmSourceProfilePacketSize, sspmSourceProfilePacketFillType, sspmSourceProfilePacketFillValue, sspmSourceProfileTOS, sspmSourceProfileFlowLabel, sspmSourceProfileLooseSrcRteFill, sspmSourceProfileLooseSrcRteLen, sspmSourceProfileTTL, sspmSourceProfileNoFrag, sspmSourceProfile8021Tagging, sspmSourceProfileUsername, sspmSourceProfilePassword, sspmSourceProfileParameter, sspmSourceProfileOwner, sspmSourceProfileStorageType, sspmSourceProfileStatus, sspmSourceControlProfile, sspmSourceControlSrc, sspmSourceControlDestAddrType, Kalbfleisch, et al. Standards Track [Page 30] RFC 4149 SSPM-MIB August 2005 sspmSourceControlDestAddr, sspmSourceControlEnabled, sspmSourceControlTimeOut, sspmSourceControlSamplingDist, sspmSourceControlFrequency, sspmSourceControlFirstSeqNum, sspmSourceControlLastSeqNum, sspmSourceControlOwner, sspmSourceControlStorageType, sspmSourceControlStatus } STATUS current DESCRIPTION "The objects in the SSPM Source Group." ::= { sspmGroups 2 } sspmUserPassGroup OBJECT-GROUP OBJECTS { sspmSourceProfileUsername, sspmSourceProfilePassword } STATUS current DESCRIPTION "The objects in the SSPM Username and password group." ::= { sspmGroups 3 } sspmSinkGroup OBJECT-GROUP OBJECTS { sspmSinkType, sspmSinkSourceAddressType, sspmSinkSourceAddress, sspmSinkExpectedRate, sspmSinkEnable, sspmSinkExpectedFirstSequenceNum, sspmSinkLastSequenceNumber, sspmSinkLastSequenceInvalid, sspmSinkStorageType, sspmSinkStatus } STATUS current DESCRIPTION "The objects in the SSPM Sink Group." ::= { sspmGroups 4 } END Kalbfleisch, et al. Standards Track [Page 31] RFC 4149 SSPM-MIB August 2005 8. Security Considerations This MIB module defines objects that allow packets to be injected into the network for the purpose of measuring some performance characteristics. As such, the MIB module may contain sensitive network and application data; e.g., user IDs and passwords. Further, if security is compromised, this MIB module could provide a source for denial-of-service, and potential other, attacks. These issues will be addressed within this section. There are a number of management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: + The sspmSourceProfileTable contains objects that configure link- level, IP, and application-level data used within test suites. These objects with a MAX-ACCESS clause of read-write and/or read- create are: o sspmSourcePacketSize - configures the overall size of the test packets, o sspmSourceProfileTOS - sets the TOS field in the IPv4 and IPv6 headers, o sspmSourceProfileLooseSrcRteFill and sspmSourceProfileLooseSrcRteLen - give a list of IPv4 or IPv6 addresses for the loose source route options in the IP headers, o sspmSourceProfileFlowLabel - sets the Flow Label in the IPv6 header, o sspmSourceProfileTTL - sets the TTL field in the packet headers, o sspmSourceProfileNoFrag - sets the No Fragment bit in the packet headers, o sspmSourceProfile8021Tagging - sets the Tag field in the 802.1 headers, and Kalbfleisch, et al. Standards Track [Page 32] RFC 4149 SSPM-MIB August 2005 o sspmSourceProfileUsername and sspmSourceProfilePassword - these hold the ID and passwords specific to an application test profile., + The sspmSourceControlTable contains objects that configure IP and application-level data used within a given test. These objects with a MAX-ACCESS clause of read-write and/or read- create are: o sspmSourceControlSrc - controls the source IP address used on the test packets, o sspmSourceControlDestAddr - holds the destination address for the specific test packet, o sspmSourceControlTimeout, sspmSourceControlSamplingDist, and sspmSourceControlFrequency - control the nature and frequency of the test packet injection onto the network, and o sspmSourceControlFirstSeqNum and sspmSourceControlLastSeqNum - set the first and last sequence numbers for the specific test. + The sspmSinkTable contains objects that configure the recipient of the test packets. As such, the objects in this table have no security issues related to them. Some attributes configure username and password information for some application-level protocols as indicated above. Access to these attributes may provide unauthorized use of resources. These attributes are: sspmSourceProfileUsername and sspmSourceProfilePassword. Some attributes configure the size and rate of traffic flows for the purpose of performance measurements. Access to these attributes may exacerbate the use of this MIB module in denial-of-service attacks. It is possible to define a maximum packet rate on the device and to indicate this rate through the sspmSourceFrequency object. This object reflects the maximum acceptable packet rate that a device supporting this MIB module is willing to generate. This places a bound on setting the test packet rate through the sspmSourceControlFrequency object. Other objects that control aspects of the test packets related to packet size and rate are sspmSourceControlTimeOut, sspmSourceControlSamplingDist and sspmSourceControlFrequency. Kalbfleisch, et al. Standards Track [Page 33] RFC 4149 SSPM-MIB August 2005 The objects sspmSourceControlSrc, sspmSourceControlDestAddr, sspmSourceControlLooseSrcRteFill, and sspmSourceControlLooseSrcRteLen control the setting of the source and destination addresses on the packet headers and the routing of the packets. The device should not allow the setting of source addresses on the test packets other than those that are administratively configured onto the device. This is controlled by using the syntax InterfaceIndexOrZero for the control of the source address through the sspmSourceControlSrc object. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Acknowledgements This document was produced by the IETF Remote Network Monitoring Working Group. The editors gratefully acknowledge the comments of the following individuals: Andy Bierman, Lester D'Souza, Jim McQuaid, and Steven Waldbusser. 10. Normative References [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. Kalbfleisch, et al. Standards Track [Page 34] RFC 4149 SSPM-MIB August 2005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-Way Packet Loss Metric for IPPM" RFC 2680, September 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses ", RFC 3291, May 2002. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network Performance Measurement with Periodic Streams", RFC 3432, November 2002. [RFC3577] Waldbusser, S., Cole, R.G., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003. [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004. Kalbfleisch, et al. Standards Track [Page 35] RFC 4149 SSPM-MIB August 2005 [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005. 11. Informative References [RFC1272] Mills, C., Hirsch, G., and G. Ruth, "Internet Accounting Background", RFC 1272, November 1991. [RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [RFC2722] Browlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999. [RFC2720] Brownlee, N. "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. Saperia, "Application Management MIB", RFC 2564, May 1999. [RFC2594] Hazewinkel, H., Kalbfleisch, C., and J. Schoenwaelder, "Definitions of Managed Objects for WWW Services", RFC 2594, May 1999. [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001. [RFC2678] Mahdavi, J. and V. Paxson, "IPPM metrics for Measuring Connectivity", RFC 2678, September 1999. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-Trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, February 1995. Kalbfleisch, et al. Standards Track [Page 36] RFC 4149 SSPM-MIB August 2005 [RFC2925] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000. [RFC2982] Kavasseri, R., "Distributed Management Expression MIB", RFC 2982, October 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3512] MacFaden, M., Partain, D., Saperia, J., and W. Tackabury, "Configuring Networks and Devices with Simple Network Management Protocol (SNMP)", RFC 3512, April 2003. [EBT] Mathis, M. and M. Allman, "Empirical Bulk Transfer Capacity", Work in Progress, October 1999. [ODP] Shalunov, S., Teitelbaum, B., and M. Zekauskas, "A One- Way Delay Protocol for IP Performance Measurements", Work in Progress, December 2000. [RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based Management MIB", RFC 4011, March 2005. [TBT] Mathis, M., "TReno Bulk transfer Capacity", Work in Progress, February 1999. Kalbfleisch, et al. Standards Track [Page 37] RFC 4149 SSPM-MIB August 2005 Authors' Addresses Carl W. Kalbfleisch Consultant EMail: ietf@kalbfleisch.us Robert G. Cole Johns Hopkins University Applied Physics Laboratory MP2-170 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA Tel: +1 443-778-6951 EMail: robert.cole@jhuapl.edu Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Tel: +972-3-645-8414 EMail: dromasca@avaya.com Kalbfleisch, et al. Standards Track [Page 38] RFC 4149 SSPM-MIB August 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kalbfleisch, et al. Standards Track [Page 39] snmp-mibs-downloader-1.1/mibrfcs/rfc4150.txt0000644000000000000000000036041011402176072015560 0ustar Network Working Group R. Dietz Request for Comments: 4150 Hifn, Inc. Category: Standards Track R. Cole JHU/APL August 2005 Transport Performance Metrics MIB 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. Dietz & Cole Standards Track [Page 1] RFC 4150 TPM-MIB August 2005 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 2.1. Terms ......................................................5 2.2. Report Aggregation .........................................5 2.3. Structure of the MIB .......................................6 2.4. Statistics for Aggregation of Data: Conventions ............7 2.5. Relationship to the Remote Monitoring MIB ..................7 2.6. Relationship to RMON2-MIB Protocol Identifier Reference ....7 2.7. Relationship to Standards-Based Performance Metrics ........7 2.8. Relationship to Application Performance Measurement MIB ....8 3. Statistics Perspective ..........................................8 3.1. Statistics Structure ......................................10 3.2. Statistics Analysis .......................................11 4. Definitions ....................................................11 5. Acknowledgements ...............................................51 6. Security Considerations ........................................52 7. Normative References ...........................................53 8. Informative References .........................................54 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This document continues the architecture created in the RMON2-MIB [RFC2021] by providing a major feature upgrade, primarily by providing new metrics and studies to assist in the analysis of performance for sub-application transaction flows in the network, in direct relationship to the transport of application layer protocols. Performance-monitoring agents have been widely used to analyze the parameters and metrics related to the perceived performance of distributed applications and services in networks. The metrics collected by these agents have ranged from basic response time to a Dietz & Cole Standards Track [Page 2] RFC 4150 TPM-MIB August 2005 combination of metrics related to the loss and re-transmission of datagrams and PDUs. Although the metrics are becoming more useful in the implementation of service-level monitoring and troubleshooting tools, the lack of a standard method to report these has limited the deployment to very specific customer needs and areas. This document is intended to create a general framework for the collection and reporting of performance-related metrics on sub- application level transaction flows in a network. The MIB in this document is directly linked to the current RMON2-MIB [RFC2021], and uses the Protocol Directory as a key component in reporting the layering involved in the sub-application level transaction flows. The specific objectives of this document are to: + Provide a drill-down capability to complement the user-perceived monitoring defined within the Application Performance Measurement MIB (APM-MIB) [RFC3729]. This capability is intended to support trouble resolution, further characterization of performance, and a finer granularity of monitoring capabilities. The APM-MIB provides a method for retrieving aggregated measurement data of the end-user's perception of application-level performance. APM additionally provides thresholding and associated alarms if the end-user perceived performance degrades below defined thresholds. The Transport Performance Metrics MIB (TPM-MIB) complements the APM-MIB capabilities by monitoring sub-application level transaction aspects not typically perceived by the end-user. As an example, APM-MIB provides response time statistics of a typical web- browser application. This application typically consists of DNS transactions, TCP connection establishment (or multiple establishments), HTTP download of the base page, and multiple downloads of the various embedded objects. Ideally, TPM-MIB would provide statistics on the performance aspects of these multiple sub-application level transactions. + Provide additional performance metrics and related statistics. For troubleshooting and a finer granularity of performance monitoring, it is useful to provide measurements of additional metrics beyond those supported by the APM-MIB. + Support standards-based metrics and associated statistical aggregation by defining methods to reference those standards. The TPM-MIB provides a capability to describe metrics by reference to appropriate IETF, ITU, or other standards bodies defining metrics, including enterprise-specific standards bodies. This capability is provided through the tpmMetricsDefTable. Dietz & Cole Standards Track [Page 3] RFC 4150 TPM-MIB August 2005 Specifically, this MIB itself does not make references to metric specifications of the IETF, ITU and other organizations. Instead, it allows for the setup of the tpmMetricDefTable that does reference such IETF, ITU, and other metric specifications, and it allows pointers to such specifications to be dynamically listed in this table. The following objects allow for that, and the DESCRIPTION clauses (of the objects below) explain how this is done: tpmMetricDefName OBJECT-TYPE tpmMetricDefReference OBJECT-TYPE tpmMetricDefGlobalID OBJECT-TYPE The tpmMetricDefGlobalID object contains a reference to the Object ID in a metrics registration MIB being developed in the IP Performance Metrics (IPPM) Working Group at the IETF; e.g., the IPPM-REGISTRY-MIB [RFC4148], which defines the metric. For metrics defined within the IPPM Working Group, which are included in the IPPM-REGISTRY-MIB, this object is used to reference those metrics directly. For metrics not included within the IPPM-REGISTRY-MIB, the value of this object is set to 0.0 for none. Examples of appropriate references include the ITU-T Recommendation Y.1540 [Y.1540] on IP packet transfer performance metrics, and the IETF documents from the IPPM WG; e.g., RFC 2681 on the round trip delay metric [RFC2681] or RFC3393 on the delay variation metric [RFC3393]. Others include RFC 2679 [RFC2679], RFC2680 [RFC2680], and RFC3432 [RFC3432]. Although no specific metric is mandatory, implementations should, at a minimum, support a round-trip delay and a round-trip loss metric. + Provide (as an option) a table storing the measurements of the metrics on a transaction by transaction basis. There are times when it is useful to have access to the raw measurements. The tpmCurReportTable optionally provides access to this capability. Although this document outlines the basic measurements of performance in regard to the transport of application flows, it does not attempt to measure or provide a means to measure the actual perceived performance of the application transactions or quality. The detailed measurements of end-user-perceived performance are directly related to this document and may be found in the APM-MIB [RFC3729]. The objects defined in this document are intended as an interface between an RMON agent and an RMON management application and are not intended for direct manipulation by humans. Although some users may tolerate the direct display of some of these objects, few will Dietz & Cole Standards Track [Page 4] RFC 4150 TPM-MIB August 2005 tolerate the complexity of manually manipulating objects to accomplish row creation. These functions should be handled by the management application. 2.1. Terms This document uses some terms that need introduction: DataSource A source of data for monitoring purposes. This term is used exactly as defined in the RMON2-MIB [RFC2021]. protocol A specific protocol encapsulation, as identified for monitoring purposes. This term is used exactly as defined in the RMON Protocol Identifiers document [RFC2895]. performance metric A specific, measured reporting metric, as identified for monitoring purposes. There can be several metrics reported by an agent in the same implementation. The metrics are extensible based on the agent implementation. application A network-based, high-level protocol performing useful work to an end-user of an end-system. Typically, the application performs multiple request/response transactions to complete its work. E.g., a web application downloading a web page completes DNS, TCP-connect, and multiple HTTP GET transactions prior to completing its task. transactions Elemental request/response transactions comprising more complex network-based applications. E.g., a transaction may include an ftp get request and the file download in response. 2.2. Report Aggregation This MIB module provides functions that aggregate measurements into higher-level summaries identical to the aggregation defined in the APM-MIB [RFC3729]. In addition to temporal aggregation of data, the Textual Convention, TransactionAggregationType, is imported from the APM-MIB, which specifies the nature of the spatial aggregation employed. Dietz & Cole Standards Track [Page 5] RFC 4150 TPM-MIB August 2005 2.3. Structure of the MIB The objects are arranged in the following groups: -- tpmCapabilitiesGroup -- tpmAggregateReportsGroup -- tpmCurrentReportsGroup -- tpmExceptionReportsGroup These groups are the basic units of conformance. If an agent implements a group, then it must implement all objects in that group. Although this section provides an overview of grouping and conformance information for this MIB module, the authoritative reference for such information is contained in the MODULE-COMPLIANCE and OBJECT-GROUP macros later in this MIB module. These groups are defined to provide a means of assigning object identifiers, and to provide a method for implementers of managed agents to know which objects they must implement. 2.3.1. The tpmCapabilitiesGroup The tpmCapabilitiesGroup contains objects and tables that show the measurement protocol and metric capabilities of the agent. This group primarily consists of the tpmTransMetricDirTable and the tpmMetricDefTable. 2.3.2. The tpmAggregateReportsGroup The tpmAggregateReportsGroup is used to provide the collection of aggregated statistical measurements for the configured report intervals. The tpmAggregateReportsGroup consists of the tpmAggrReportCntrlTable and the tpmAggrReportTable. 2.3.3. The tpmCurrentReportsGroup The tpmCurrentReportsGroup is used to provide the collection of uncompleted measurements for the current configured report for those transactions caught in progress. A history of these transactions is also maintained once the current transaction has been completed. The tpmCurrentReportsGroup consists of the tpmCurReportTable and the tpmCurReportSize object. Dietz & Cole Standards Track [Page 6] RFC 4150 TPM-MIB August 2005 2.3.4. The tpmExceptionReportsGroup The tpmExceptionReportsGroup is used to link immediate notifications of transactions that exceed certain thresholds defined in the apmExceptionGroup [RFC3729]. This group reports the aggregated sub- application measurements for those applications exceeding thresholds. The tpmExceptionReportsGroup consists of the tpmExcpReportTable. 2.4. Statistics for Aggregation of Data: Conventions In order to measure the performance of traffic flows in a network, the proper analysis of a set of statistics is required. Because a large majority of the statistics have a basis of time, the use of a simple statistical model is feasible. Therefore, the MIB definitions within this document all use a basic set of statistical computed values to assist in further analysis by a management application. The remaining subsections in this section detail the common structured features the are applied to the performance metrics in the statistical format described above. The tpmMetricsDefTable (discussed below) describes the set of metrics supported in this MIB module. 2.5. Relationship to the Remote Monitoring MIB This document describes the implementation of an additional MIB for the support of performance-related metrics within the framework of the RMON2-MIB [RFC2021]. The objects and table defined in this MIB module are an extension to the existing framework for the support of both Client/Server and Server push-related applications and services. 2.6. Relationship to RMON2-MIB Protocol Identifier Reference This document uses the Protocol Identifiers outlined in the current Protocol Identifier Reference document, RFC 2895 [RFC2895]. The protocol index values throughout the document are a direct reference to the same relationship that exists between the RMON2-MIB [RFC2021] and the Protocol Identifier Reference document, RFC 2895 [RFC2895]. An important extension of the Protocol Identification to application- level verbs is found in RFC 3395 [RFC3395]. 2.7. Relationship to Standards-Based Performance Metrics This document uses the tpmMetricsDefTable to describe the metrics supported by an instance of the TPM-MIB. The performance metric index values throughout the document are a direct reference to the Dietz & Cole Standards Track [Page 7] RFC 4150 TPM-MIB August 2005 metrics defined in that table. The table defines metrics by directly referencing other standards that provide definitive descriptions of the metric. 2.8. Relationship to Application Performance Measurement MIB This document uses the apmReportControlIndex, appLocalIndex, and apmReportIndex, as outlined in the current Application Performance Measurement MIB [RFC3729]. These objects are used to create a reference link for the purpose of reporting transaction flow details on application-level measurements. As such, the TPM-MIB is designed to provide a drill-down extension to the APM-MIB. Further, it draws heavily on the ideas and designs laid out in the APM-MIB. 3. Statistics Perspective When dealing with time-based measurements on application data packets, ideally all the timestamps and related data could be stored and forwarded for later analysis. However, when faced with thousands of conversations per second on ever-faster networks, storing all the data, even if compressed, would take too much processing, memory, and manager download time to be practical. It is important to note that in dealing with network data we will be dealing with statistical populations and not samples. Statistics books deal with both because the math is similar. In collecting agent data, a population (i.e., all the data) must be processed. Because of the nature of application protocols, just sampling some of the packets will not give good results. Missing just one critical packet, such as one that specified an ephemeral port on which data will be transmitted or what application will be run, can cause much valid data to be lost. The time-based measurements the agent collects will come from examining the entire group of data, i.e., the population. The population will be finite. The agent will seek only to provide information that will describe the actual data. Analysis of that data will be left to the management station. The simplest form of representing a group of data is by frequency distributions, i.e., buckets. Statistics provides a great many ways of analyzing this type of data, and there are some rules in creating the buckets. First, the range needs to be known. Second, a bucket size needs to be determined. Fixed bucket sizes are best, although variable may be used if needed. However, the statistics texts tend only to refer to operations of fixed-size buckets. This method of describing data is expensive for an agent to implement. First, the Dietz & Cole Standards Track [Page 8] RFC 4150 TPM-MIB August 2005 agent must process a great amount of data at a time. Storing the data, determining the range, locating the buckets, and then filling in the data after the fact takes a fair amount of storage and time. Fixing the range and bucket sizes in the beginning can be problematic, as the agent may have to adjust the values for each of the applications it collects data on. Such numbers can be in the thousands. Additional complexity arises in adding new protocols and even in describing the buckets themselves to the management application. This is the approach taken in the APM-MIB. A complimentary approach is to provide frequency distribution statistics. They describe aggregation such as mean and standard deviation that can be obtained by summation functions on the individual data elements in a population. Analysis of the data described by these functions has been thoroughly studied, and interpretation of these values is available to anyone with an introduction to statistics. In fact, frequency distributions are routinely analyzed to generate these varied numbers, which are then used for further analysis. Note that frequency distributions, by their very nature, provide an exact characterization of the data. Whereas buckets will introduce error factors that are not present with direct analysis by summation-type formulas. Because the TPM-MIB provides a drill-down capability to the APM MIB, it has to measure and store much more information than the APM-MIB. For this reason, and in order to complement the APM-MIB, the TPM-MIB relies on statistical descriptions rather than a bucket description of the measurement data. The agent will provide data that can be used to calculate the most basic and useful statistical aggregates. The agent will not perform the calculations and will not provide the statistical measurement directly. There are several reasons why this is not desired. The first is that finding the final measurement can be expensive in terms of computation and representation. There are divisions and square roots, and the measurements are expressed as floating point values. The second is that by providing the variables to the statistical functions, those variables are scalable. It is possible to combine smaller intervals into larger ones. An example is the arithmetic mean or average. This is the sum of the data divided by the number of data elements. The agent will provide the sum of the x and the number of elements N. The management station can perform the division to obtain the average. Given two samples, they can be combined by adding the sum of the x's and by adding the number of elements to get a combined sum and number of elements. The average formula then works just the same. Also, the sum of the x and the number of element variables are used in calculating other statistical measurement values. Dietz & Cole Standards Track [Page 9] RFC 4150 TPM-MIB August 2005 3.1. Statistics Structure The data statistical elements, datum, of the metric have been chosen to maximize the amount of data available while minimizing the amount of memory needed to store the statistic and minimizing the CPU processing requirement needed to generate the statistic. The statistic data structure contains five unsigned integer datum. N count of the number of data points for the metric S(X) sum of all the data point values for the metric S(X2) sum of all the data point values squared for the metric Xmax maximum data point value for the metric Xmin minimum data point value for the metric S(I*X) sum of the data points multiplied by their order, i.e., = SUM from i=1 to N { i*X sub i} A performance metric is used to describe events over a time interval. The measurement points can be processed immediately into the statistic and do not have to be stored for later processing. For example, to count the number of events in a time interval, it is sufficient to increment a counter for each event. It is not necessary to cache all the events and then to count them at the end of the interval. The statistic is also designed to be easily scalable in terms of combining adjacent intervals. For example, if an agent created a specific statistic every 30 seconds and a user table interval was set to 60 seconds, the 60-second statistic could be obtained by combining the two 30-second statistics. The following rules will be applied when combining adjacent statistics. N S(N) S(X) S(S(X)) S(X2) S(S(X2)) Xmax MAX(Xmax) Xmin MIN(Xmin) S(I*X) S(I*X) + N*S(X) +S(I*X) where the last two terms refer to the statistics from the later 30 second period and N is the count from the former 30 second period. This structure gives a generic framework upon which the actual performance statistics will be defined. Each specific statistical definition must address the specific significance, if any, given to each metric datum. While a specific metric definition should try to conform to the generic framework, it is acceptable for a metric datum to not be used, and to have no meaning, for a specific metric. In such cases the datum will default to a 0 value. Dietz & Cole Standards Track [Page 10] RFC 4150 TPM-MIB August 2005 3.2. Statistics Analysis The actual meaning of a specific statistical datum is determined by the definition of the specific statistic. The following is a discussion of the operations and observations that can be performed on a generic metric. This means that the following may or may not apply and/or have meaning when applied to any specific metric. The following observations and analysis techniques are not all inclusive. Rather these are the ones we have come up with at the time of writing this document. + Number. + Frequency. + The time interval is that specified in the control table. It is not a metric datum, but it is associated with the metric sample. + Maximum + Minimum + Range + Arithmetic Mean + Root Mean Square + Variance + Standard Deviation + Slope of a least-squares line These are accessible from the statistical datum provided by this MIB module. 4. Definitions -- -- RMON2-MIB extensions for the monitoring metrics related to the -- performance of transporting traffic in networks. -- -- TPM Metric Collection -- * Application-to-Protocol transaction linkage -- * Metric-to-Protocol linkage Dietz & Cole Standards Track [Page 11] RFC 4150 TPM-MIB August 2005 -- * Metric study control -- * Metrics for Client/Server Conversations -- TPM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32 FROM SNMPv2-SMI --[RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF --[RFC2580] SnmpAdminString FROM SNMP-FRAMEWORK-MIB --[RFC3411] RowStatus, TEXTUAL-CONVENTION, TimeStamp, StorageType FROM SNMPv2-TC --[RFC2579] rmon, OwnerString FROM RMON-MIB --[RFC2819] protocolDirLocalIndex, ZeroBasedCounter32 FROM RMON2-MIB --[RFC2021] ZeroBasedCounter64 FROM HCNUM-TC --[RFC2856] AppLocalIndex, TransactionAggregationType, RmonClientID, DataSourceOrZero, apmAppDirAppLocalIndex, apmExceptionIndex, apmReportGroup, apmExceptionGroup, apmAppDirResponsivenessType FROM APM-MIB --[RFC3729] SspmClockSource, SspmClockMaxSkew, SspmMicroSeconds FROM SSPM-MIB; --[RFC4149] -- Transaction Performance Monitoring MIB tpmMIB MODULE-IDENTITY LAST-UPDATED "200507280000Z" -- 28 July 2005 ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "E-mail: rmonmib@ietf.org Subscribe: rmonmib-request@ietf.org w/ msg body: subscribe rmonmib Russell Dietz Hifn, Inc. Postal: 750 University Ave Los Gatos, CA 95032-7695 Dietz & Cole Standards Track [Page 12] RFC 4150 TPM-MIB August 2005 USA Tel: +1 408 399-3623 Fax: +1 408 399-3501 E-mail: rdietz@hifn.com Robert G. Cole Johns Hopkins University Applied Physics Laboratory Postal: MP2-170 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA Tel: +1 443 778-6951 E-mail: robert.cole@jhuapl.edu" DESCRIPTION "This module defines extensions to the RMON2-MIB module for the collection of Performance Metrics related to application traffic in a network. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. In order to maintain the RMON 'look-and-feel', some of the text from the RMON2 [RFC2021] and HC-RMON [RFC3273] MIBs by Steve Waldbusser have been used in this MIB module. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4150; see the RFC itself for full legal notices." REVISION "200507280000Z" -- 28 July 2005 DESCRIPTION "The original version of this MIB module, published as RFC 4150." ::= { rmon 30 } -- -- Object Identifier Assignments -- tpmCapabilities OBJECT IDENTIFIER ::= { tpmMIB 1 } tpmReports OBJECT IDENTIFIER ::= { tpmMIB 2 } tpmConformance OBJECT IDENTIFIER ::= { tpmMIB 3 } -- tpmAggrReportCntrlTable OBJECT IDENTIFIER ::= { tpmReports 1 } -- tpmAggrReportTable OBJECT IDENTIFIER ::= { tpmReports 2 } -- tpmCurReportTable OBJECT IDENTIFIER ::= { tpmReports 3 } -- tpmCurReportSize OBJECT IDENTIFIER ::= { tpmReports 4 } Dietz & Cole Standards Track [Page 13] RFC 4150 TPM-MIB August 2005 -- tpmExcpReportTable OBJECT IDENTIFIER ::= { tpmReports 5 } -- -- Textual Conventions -- TpmTransactionMetricIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An index used to identify an entry in the tpmTransMetricDir table uniquely. Each such entry defines the protocol transaction and metric instance to be monitored for a specific application." SYNTAX Unsigned32 (1..65535) TpmMetricDefID ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An index that identifies through reference to a specific performance metrics. The metrics are referenced through their type (connect, delay, loss, etc.), their directional characteristics (one-way, round trip, etc.), their name, and their reference to a documented definition." SYNTAX Unsigned32 (1..2147483647) -- -- The tpmCapabilitiesGroup -- tpmClockResolution OBJECT-TYPE SYNTAX SspmMicroSeconds MAX-ACCESS read-only STATUS current -- UNITS Microseconds DESCRIPTION "A read-only variable indicating the resolution of the measurements possible by this device." ::= { tpmCapabilities 1 } tpmClockMaxSkew OBJECT-TYPE SYNTAX SspmClockMaxSkew MAX-ACCESS read-only STATUS current -- UNITS Seconds DESCRIPTION "A read-only variable indicating the maximum Dietz & Cole Standards Track [Page 14] RFC 4150 TPM-MIB August 2005 offset error due to skew of the local clock over the time interval 86400 seconds, in seconds." ::= { tpmCapabilities 2 } tpmClockSource OBJECT-TYPE SYNTAX SspmClockSource MAX-ACCESS read-only STATUS current DESCRIPTION "A read-only variable indicating the source of the clock. This is provided to allow a user to determine how accurate the timing mechanism is compared with other devices." ::= { tpmCapabilities 3 } tpmTransMetricDirLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the tpmTransMetricDirTable was last modified, through modifications of the tpmTransMetricDirConfig object." ::= { tpmCapabilities 4 } tpmTransMetricDirTable OBJECT-TYPE SYNTAX SEQUENCE OF TpmTransMetricDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to describe and link sets of performance metrics and protocols to an entry in the application directory. This table, with the tpmMetricDefTable, describes the capability of the agent to collection sub-application level data related to each entry in the apmAppDirectoryTable. This table lists the protocol transactions and their corresponding performance metrics that this agent has the capability to compute and collect, for the specified application. There is one entry in this table for each such application, protocol transaction, and metric combination supported by this agent. The entries in this table represent the metrics that are collected for each protocol transaction that comprise the application. The agent should boot up with this table pre-configured with those combinations of applications, protocol transactions, and metrics that it knows about and wishes to Dietz & Cole Standards Track [Page 15] RFC 4150 TPM-MIB August 2005 monitor. Implementations must populate the table with all possible application, protocol transaction, and metric combinations and have the default configuration objects set to supportedOff(2). This table does not support the creation of new combinations by the management application. The deletion of an entry in the apmAppDirectoryTable will cause the removal of entries from this table. These entries must be removed because the appLocalIndex value will no longer be visible in the apmAppDirectoryTable. When an entry is created in the apmAppDirectoryTable and the agent has the ability to support metrics for these protocol transactions, the appropriate entries must be made in the tpmTransMetricDefTable." ::= { tpmCapabilities 5 } tpmTransMetricDirEntry OBJECT-TYPE SYNTAX TpmTransMetricDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the tpmTransMetricDirTable. An example of the indexing of this entry is tpmTransMetricDirConfig.5.2 where 5 is the value of a valid and visible appLocalIndex object in the appLocalDir table. The entries describe the transaction and metric pairs monitored for this application. The tpmTransMetricProtocolIndex identifies the protocol transaction and the tpmMetricDefIndex describes the metric monitored." INDEX { tpmTransMetricAppLocalIndex, -- Application Index tpmTransMetricIndex -- (Protocol,Metric) Index } ::= { tpmTransMetricDirTable 1 } TpmTransMetricDirEntry ::= SEQUENCE { tpmTransMetricAppLocalIndex AppLocalIndex, tpmTransMetricIndex TpmTransactionMetricIndex, tpmTransMetricProtocolIndex Unsigned32, tpmTransMetricMetricIndex Unsigned32, tpmTransMetricDirConfig INTEGER } tpmTransMetricAppLocalIndex OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS not-accessible STATUS current Dietz & Cole Standards Track [Page 16] RFC 4150 TPM-MIB August 2005 DESCRIPTION "An index used to uniquely identify the application with which the entries in the tpmTransMetricDir table are associated." ::= { tpmTransMetricDirEntry 1 } tpmTransMetricIndex OBJECT-TYPE SYNTAX TpmTransactionMetricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index used to uniquely identify an entry in the tpmTransMetricDir table. Each such entry defines protocol transaction and metric instance to be monitored for a specific application." ::= { tpmTransMetricDirEntry 2 } tpmTransMetricProtocolIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex of the particular transaction to be analyzed when computing and generating the selected metric for a specific application." ::= { tpmTransMetricDirEntry 3 } tpmTransMetricMetricIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The tpmMetricDefinitionID of the particular metric to be generated." ::= { tpmTransMetricDirEntry 4 } tpmTransMetricDirConfig OBJECT-TYPE SYNTAX INTEGER { notSupported(1), supportedOff(2), supportedOn(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object describes and configures the probe's support for this performance metric in relationship to the specified transaction and application. The agent Dietz & Cole Standards Track [Page 17] RFC 4150 TPM-MIB August 2005 creates entries in this table for all metric and transaction combinations that it can generate. Because the probe will only populate this table with supported entries, and the table cannot have entries added, the notSupported(1) setting is only used to signify that other configuration parameters are causing the agent currently not to support the generation and collection of this metric for the specified protocol and application. Also, the status of this object will not change to notSupported(1) due to a change to supportedOff(2) in the tpmMetricDir table. If the value of this object is notSupported(1), the probe will not perform computations for this performance metric and transaction combination and will not allow this object to be changed to any other value. If the value of this object is supportedOn(3), the probe supports computations for this performance metric and protocol and is configured to perform the computations for this performance metric and protocol combination for the application for all interfaces. If the value of this object is supportedOff(2), the probe supports computations for this performance metric for the specified protocol, but is configured not to perform the computations for this performance metric and protocol for the application for any interfaces. Whenever this value changes from supportedOn(3) to supportedOff(2), the probe shall cause the deletion of all entries in the tpmReportGroup tables, for all appropriate studies configured in the tpmAggrReportCntrlTable. The value of this object must persist across reboots." ::= { tpmTransMetricDirEntry 5 } -- -- TPM Metric Definitions Table -- tpmMetricDefTable OBJECT-TYPE SYNTAX SEQUENCE OF TpmMetricDefEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The tpmMetricDefTable describes the metrics available to the TPM-MIB. The tpmMetricDefTable can define metrics by referencing existing IETF, ITU, and other standards organizations' documents, including enterprise-specific documents. Dietz & Cole Standards Track [Page 18] RFC 4150 TPM-MIB August 2005 Examples of appropriate references include the ITU-T Recommendation Y.1540 [Y.1540] on IP packet transfer performance metrics and the IETF documents from the IPPM WG; e.g., RFC2681 on the round trip delay metric [RFC2681] or RFC3393 on the delay variation metric [RFC3393]. Other examples include RFC2679 [RFC2679], RFC2680 [RFC2680], and RFC3432 [RFC3432]. Although no specific metric is mandatory, implementations should, at a minimum, support a round-trip delay and a round-trip loss metric. This table contains one row per metric supported by this agent, and it should be populated during system initialization." ::= { tpmCapabilities 6 } tpmMetricDefEntry OBJECT-TYPE SYNTAX TpmMetricDefEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular metric." INDEX { tpmMetricDefinitionID } ::= { tpmMetricDefTable 1 } TpmMetricDefEntry ::= SEQUENCE { tpmMetricDefinitionID TpmMetricDefID, tpmMetricDefType INTEGER, tpmMetricDefDirType INTEGER, tpmMetricDefName SnmpAdminString, tpmMetricDefReference SnmpAdminString, tpmMetricDefGlobalID OBJECT IDENTIFIER } tpmMetricDefinitionID OBJECT-TYPE SYNTAX TpmMetricDefID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this entry. This object identifies the particular metric in this MIB module." ::= { tpmMetricDefEntry 1 } tpmMetricDefType OBJECT-TYPE SYNTAX INTEGER { other(1), connectMetric(2), Dietz & Cole Standards Track [Page 19] RFC 4150 TPM-MIB August 2005 delayMetric(3), lossMetric(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The basic type of metric indicated by this entry. The value 'other(1)' indicates that this metric cannot be characterized by any of the remaining enumerations specified for this object. The value 'connectMetric(2)' indicates that this metric measures connectivity characteristics. The value 'delayMetric(3)' indicates that this metric measures delay characteristics. The value 'lossMetric(4)' indicates that this metric measures loss characteristics." ::= { tpmMetricDefEntry 2 } tpmMetricDefDirType OBJECT-TYPE SYNTAX INTEGER { oneWay(1), twoWay(2), multiWay(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The directional characteristics of the this metric. The value 'oneWay(1)' indicates that this metric is measured with some sort of unidirectional test. The value 'twoWay(2)' indicates that this metric is measured with some sort of bidirectional test. The value 'multiWay(3)' indicates that this metric is measured with some combination of unidirectional and/or bidirectional tests." ::= { tpmMetricDefEntry 3 } tpmMetricDefName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current Dietz & Cole Standards Track [Page 20] RFC 4150 TPM-MIB August 2005 DESCRIPTION "The textual name of this metric. For example, if this tpmMetricDefEntry identified the IPPM metric for round trip delay, then this object should contain the value, e.g., 'Type-P-Round-Trip-Delay'." ::= { tpmMetricDefEntry 4 } tpmMetricDefReference OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a reference to the document that defines this metric. If this document is available online via electronic download, then a de-referencable URL should be specified in this object. The implementation must support an HTTP URL type and may support additional types of de-referencable URLs such as an FTP type. For example, if this tpmMetricDefName identified the IPPM metric 'Type-P-Round-Trip-Delay', then this object should contain the value, e.g., 'http://www.ietf.org/rfc/rfc2681.txt'." ::= { tpmMetricDefEntry 5 } tpmMetricDefGlobalID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a reference to the Object ID in a metrics registration MIB being developed in the IPPM WG at the IETF; e.g., the IPPM-REGISTRY-MIB [RFC4148], which defines the metric. In the event that this metric has no corresponding object identifier (OID) or until the IPPM-REGISTRY-MIB is defined, then the value should be set to 0.0 for none." ::= { tpmMetricDefEntry 6 } -- -- The tpmAggregateReportsGroup -- tpmAggrReportCntrlTable OBJECT-TYPE SYNTAX SEQUENCE OF TpmAggrReportCntrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Dietz & Cole Standards Track [Page 21] RFC 4150 TPM-MIB August 2005 "The tpmAggrReportCntrlTable is the controlling entry that manages the population of studies in the Transport Aggregate Report for selected interfaces, metrics, and transaction protocols and applications. Note that this is not like the typical RMON controlTable and dataTable in which each entry creates its own data table. Each entry in this table enables the creation of multiple data tables on a study basis. For each interval, the study is updated in place, and the current data content of the table becomes invalid. The control table entries are persistent across system reboots." ::= { tpmReports 1 } tpmAggrReportCntrlEntry OBJECT-TYPE SYNTAX TpmAggrReportCntrlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the tpmAggrReportCntrlTable. An example of the indexing of this entry is tpmAggrReportCntrlDataSource.1" INDEX { tpmAggrReportCntrlIndex } ::= { tpmAggrReportCntrlTable 1 } TpmAggrReportCntrlEntry ::= SEQUENCE { tpmAggrReportCntrlIndex Unsigned32, tpmAggrReportCntrlApmCntrlIndex Unsigned32, tpmAggrReportCntrlDataSource DataSourceOrZero, tpmAggrReportCntrlAggrType TransactionAggregationType, tpmAggrReportCntrlInterval Unsigned32, tpmAggrReportCntrlReqSize Unsigned32, tpmAggrReportCntrlGrantedSize Unsigned32, tpmAggrReportCntrlReqReports Unsigned32, tpmAggrReportCntrlGrantedReports Unsigned32, tpmAggrReportCntrlStartTime TimeStamp, tpmAggrReportCntrlReportNumber Unsigned32, tpmAggrReportCntrlInsertsDenied Counter32, tpmAggrReportCntrlDroppedFrames Counter32, tpmAggrReportCntrlOwner OwnerString, tpmAggrReportCntrlStorageType StorageType, tpmAggrReportCntrlStatus RowStatus } tpmAggrReportCntrlIndex OBJECT-TYPE Dietz & Cole Standards Track [Page 22] RFC 4150 TPM-MIB August 2005 SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the tpmAggrReportCntrlTable. Each such entry defines a unique report whose results are placed in the tpmAggrReportTable on behalf of this tpmAggrReportCntrlEntry." ::= { tpmAggrReportCntrlEntry 1 } tpmAggrReportCntrlApmCntrlIndex OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This index associates this TpmAggrReportCntrlEntry directly with an existing ApmReportControlEntry. This link is used to synchronize reports in the associated tpmAggrReportTable. A value of 0 (zero) enables an independent control table that will report entries to tpmAggrReportTable based only on the other objects in this table. A non-zero value indicates that this row is defined through the APM-MIB. In this case, all row objects are set to their corresponding values in the APM-MIB. In the event that a SET is issued to a row object, while the value of the tpmAggrReportCntrlApmCntrlIndex is non-zero, the agent MUST respond as if the object of the SET command had MAX-ACCESS of read-only. This object may not be modified if the associated tpmAggrReportCntrlStatus object is equal to active(1)." DEFVAL { 0 } ::= { tpmAggrReportCntrlEntry 2 } tpmAggrReportCntrlDataSource OBJECT-TYPE SYNTAX DataSourceOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The source of the data for TPM Reports generated on behalf of this tpmAggrReportCntrlEntry. If the measurement is being performed by a probe, this should be set to the interface or port where data was received for analysis. If the measurement isn't being performed by a probe this should be set to the primary interface over which Dietz & Cole Standards Track [Page 23] RFC 4150 TPM-MIB August 2005 the measurement is being performed. If the measurement isn't being performed by a probe and there is no primary interface, or if this information isn't known, this object should be set to 0.0. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object is set to the corresponding apmReportControlTable object in the APM-MIB [RFC3729]. This object may not be modified if the associated tpmAggrReportCntrlStatus object is equal to active(1)." ::= { tpmAggrReportCntrlEntry 3 } tpmAggrReportCntrlAggrType OBJECT-TYPE SYNTAX TransactionAggregationType -- INTEGER { -- flows(1), -- clients(2), -- servers(3), -- applications(4) -- } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of aggregation being performed for this set of reports. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object should be set by the agent to the value of the apmReportControlAggregationType object. This object may not be modified if the associated tpmAggrReportCntrlStatus object is equal to active(1)." ::= { tpmAggrReportCntrlEntry 4 } tpmAggrReportCntrlInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval in seconds over which data is accumulated before being aggregated into a report in the tpmAggrReportTable. All reports with the same tpmAggrReportCntrlIndex will be based on the same interval. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object should be set by the agent to the value Dietz & Cole Standards Track [Page 24] RFC 4150 TPM-MIB August 2005 of the apmReportControlControlInterval object. This object may not be modified if the associated tpmReportAggregateCntrlStatus object is equal to active(1)." DEFVAL { 3600 } ::= { tpmAggrReportCntrlEntry 5 } tpmAggrReportCntrlReqSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of Client and Server combination entries requested for this report. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object should be set by the agent to the value of the apmReportControlRequestedSize object. When this object is created or modified, the probe should set tpmReportCntrlGrantedSize as closely to this object as is possible for the particular probe implementation and available resources. It is important to note that this value is the number of requested entries in the tpmAggrReportTable only. Because the probe can derive this table from the apmReportTable, the probe must make sure that sufficient resources exist to support the creation of the apmReportTable, plus any additional resources required to convert or support this table. This object may not be modified if the associated tpmReportAggregateCntrlStatus object is equal to active(1)." ::= { tpmAggrReportCntrlEntry 6 } tpmAggrReportCntrlGrantedSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of performance entries in this report. When the associated tpmAggrReportCntrlReqSize object is created or modified, the probe should set this object as closely to the requested value as is possible for the particular implementation and available resources. The probe must not lower this Dietz & Cole Standards Track [Page 25] RFC 4150 TPM-MIB August 2005 value except as a result of a set to the associated tpmAggrReportCntrlReqSize object. It is an implementation-specific matter as to whether zero-valued entries are available." ::= { tpmAggrReportCntrlEntry 7 } tpmAggrReportCntrlReqReports OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of saved reports requested to be allocated on behalf of this entry. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object should be set by the agent to the value of the apmReportControlcwRequestedReportsDataSource object. This object may not be modified if the associated tpmReportAggregateCntrlStatus object is equal to active(1)." ::= { tpmAggrReportCntrlEntry 8 } tpmAggrReportCntrlGrantedReports OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of saved reports the agent has allocated based on the requested amount in tpmAggrReportCntrlReqReports. Because each report can have many entries, the total number of entries allocated will be this number multiplied by the value of tpmAggrReportCntrlGrantedSize, or by 1 if that object doesn't exist. When the associated tpmAggrReportCntrlReqReports object is created or modified, the agent should set this object as closely to the requested value as is possible for the particular implementation and available resources. When considering available resources, the agent must consider its ability to allocate this many reports, each with the number of entries represented by tpmAggrReportCntrlGrantedSize, or by 1 if that object doesn't exist. Note that although the storage required for each report may fluctuate due to changing conditions, the agent must continue to have storage available to satisfy the full report size for all reports, when necessary. Further, the agent must not Dietz & Cole Standards Track [Page 26] RFC 4150 TPM-MIB August 2005 lower this value except as a result of a set to the associated tpmAggrReportCntrlReqSize object." ::= { tpmAggrReportCntrlEntry 9 } tpmAggrReportCntrlStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the system began processing the report in progress. Note that the report in progress is not available. This object may be used by the management station to figure out the start time for all previous reports saved for this tpmAggrReportCntrlEntry, as reports are started at fixed intervals. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object is set to the corresponding apmReportControlTable object in the APM-MIB defined in the IETF's RMONMIB WG." ::= { tpmAggrReportCntrlEntry 10 } tpmAggrReportCntrlReportNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of the report in progress. When an tpmAggrReportCntrlEntry is activated, the first report will be numbered zero. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object should be set by the agent to the value of the apmReportControlReportNumber object." ::= { tpmAggrReportCntrlEntry 11 } tpmAggrReportCntrlInsertsDenied OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of attempts to add an entry to reports for this TpmAggrReportCntrlEntry that failed because the number of entries would have exceeded tpmAggrReportCntrlGrantedSize. This number is valuable in determining if enough entries have Dietz & Cole Standards Track [Page 27] RFC 4150 TPM-MIB August 2005 been allocated for reports in light of fluctuating network usage. Note that an entry that is denied will often be attempted again, so this number will not predict the exact number of additional entries needed, but it can be used to understand the relative magnitude of the problem. Also note that there is no ordering specified for the entries in the report; thus, there are no rules for which entries will be omitted when not enough entries are available. As a consequence, the agent is not required to delete 'least valuable' entries first." ::= { tpmAggrReportCntrlEntry 12 } tpmAggrReportCntrlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the agent and therefore not accounted for in the *StatsDropEvents, but for which the agent chose not to count for this entry for whatever reason. Most often, this event occurs when the agent is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the alMatrixTables are not implemented or are inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { tpmAggrReportCntrlEntry 13 } tpmAggrReportCntrlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object should be set by the agent to the value of the apmReportControlReportNumber object. Dietz & Cole Standards Track [Page 28] RFC 4150 TPM-MIB August 2005 This object may not be modified if the associated tpmReportAggregateCntrlStatus object is equal to active(1)." ::= { tpmAggrReportCntrlEntry 14 } tpmAggrReportCntrlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this tpmAggrReportCntrlEntry. If the value of this object is 'permanent', no objects in this row need to be writable." ::= { tpmAggrReportCntrlEntry 15 } tpmAggrReportCntrlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this performance control entry. An entry may not exist in the active state unless each object in the entry has an appropriate value. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object should be set by the agent to the value of the apmReportControlReportNumber object. Once this object is set to active(1), no objects in the tpmAggrReportCntrlTable can be changed. If this object is not equal to active(1), all associated entries in the tpmAggrReportTable shall be deleted." ::= { tpmAggrReportCntrlEntry 16 } -- -- Transport Aggregate Report Table -- tpmAggrReportTable OBJECT-TYPE SYNTAX SEQUENCE OF TpmAggrReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains transport performance metric studies for each of the control table entries in tpmAggrReportCntrlTable. These studies are Dietz & Cole Standards Track [Page 29] RFC 4150 TPM-MIB August 2005 provided based on the selections and parameters found for the entry in the tpmAggregateReportCntrlTable. The performance statistics are specified in the tpmTransMetricDirTable associated with the application in question and indexed by appLocalIndex and tpmTransMetricIndex." ::= { tpmReports 2 } tpmAggrReportEntry OBJECT-TYPE SYNTAX TpmAggrReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the tpmAggrReportTable. The tpmAggrReportCntrlIndex value in the index identifies the tpmAggrReportCntrlEntry on whose behalf this entry was created. The tpmAggrReportIndex value in the index identifies which report (in the series of reports) this entry is a part of. The tpmAggrReportAppLocalIndex value in the index identifies the application protocol that is being reported. The tpmTransMetricIndex value in the index identifies the transaction protocol-metric pair for the traffic flows aggregated in this entry. The protocolDirLocalIndex value in the index identifies the network layer protocol of the tpmAggrReportServerAddress. When the associated tpmAggrReportCntrlAggrType value is equal to applications(4) or clients(2), this value will equal 0. The tpmAggrReportServerAddress value in the index identifies the network layer address of the server in traffic flows aggregated in this entry. The tpmAggrReportApmNameClientID value in the index identifies the client in traffic flows aggregated in this entry. If the associated tpmAggrReportCntrlAggrType is equal to applications(4) or servers(3), then this object will be set to 0. An example of the indexing of this entry is tpmAggrReportStatN.3.15.34.262.18.4.128.2.6.7.3256521" Dietz & Cole Standards Track [Page 30] RFC 4150 TPM-MIB August 2005 INDEX { tpmAggrReportCntrlIndex, tpmAggrReportIndex, tpmAggrReportAppLocalIndex, -- Application Layer tpmAggrReportTransMetricIndex, -- Metric and Protocol protocolDirLocalIndex, -- Network Layer tpmAggrReportServerAddress, tpmAggrReportApmNameClientID } ::= { tpmAggrReportTable 1 } TpmAggrReportEntry ::= SEQUENCE { tpmAggrReportIndex Unsigned32, tpmAggrReportAppLocalIndex AppLocalIndex, tpmAggrReportTransMetricIndex TpmTransactionMetricIndex, tpmAggrReportServerAddress OCTET STRING, tpmAggrReportApmNameClientID RmonClientID, tpmAggrReportStatN ZeroBasedCounter32, tpmAggrReportOverflowStatN ZeroBasedCounter32, tpmAggrReportHCStatN ZeroBasedCounter64, tpmAggrReportStatSumX ZeroBasedCounter32, tpmAggrReportOverflowStatSumX ZeroBasedCounter32, tpmAggrReportHCStatSumX ZeroBasedCounter64, tpmAggrReportStatMaximum ZeroBasedCounter32, tpmAggrReportStatMinimum ZeroBasedCounter32, tpmAggrReportStatSumSq ZeroBasedCounter32, tpmAggrReportOverflowStatSumSq ZeroBasedCounter32, tpmAggrReportHCStatSumSq ZeroBasedCounter64, tpmAggrReportStatSumIX ZeroBasedCounter32, tpmAggrReportOverflowStatSumIX ZeroBasedCounter32, tpmAggrReportHCStatSumIX ZeroBasedCounter64, tpmAggrReportStatSumIXSq ZeroBasedCounter32, tpmAggrReportOverflowStatSumIXSq ZeroBasedCounter32, tpmAggrReportHCStatSumIXSq ZeroBasedCounter64 } tpmAggrReportIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of tpmAggrReportCntrlNumber for the report to which this entry belongs." ::= { tpmAggrReportEntry 1 } tpmAggrReportAppLocalIndex OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS not-accessible STATUS current Dietz & Cole Standards Track [Page 31] RFC 4150 TPM-MIB August 2005 DESCRIPTION "The common application of the transactions aggregated in this entry." ::= { tpmAggrReportEntry 2 } tpmAggrReportTransMetricIndex OBJECT-TYPE SYNTAX TpmTransactionMetricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index that identifies the transaction and metric associated with the statistics reported here." ::= { tpmAggrReportEntry 3 } tpmAggrReportServerAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..108)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network layer address of the server host in this conversation. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. Because this object is an index variable, it is encoded in the index according to the index encoding rules. For example, if the protocolDirLocalIndex indicates an encapsulation of IPv4, this object is encoded as a length octet of 4, followed by the 4 octets of the IPv4 address, in network byte order. If the associated tpmAggrReportCntrlAggrType is equal to application(4) or client(2), then this object will be a null string and will be encoded simply as a length octet of 0." ::= { tpmAggrReportEntry 4 } tpmAggrReportApmNameClientID OBJECT-TYPE SYNTAX RmonClientID MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique ID assigned to the machine represented by this mapping. This ID is assigned by the agent using an implementation-specific algorithm." ::= { tpmAggrReportEntry 5 } Dietz & Cole Standards Track [Page 32] RFC 4150 TPM-MIB August 2005 tpmAggrReportStatN OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the total number of data points for the specified metric. This number always represents the total size of the statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results for one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmAggrReportEntry 6 } tpmAggrReportOverflowStatN OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmAggrReportStatN counter has overflowed. Note that this object will only be instantiated if the associated tpmAggrReportHCStatN object is also instantiated for a particular dataSource." ::= { tpmAggrReportEntry 7 } tpmAggrReportHCStatN OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmAggrReportStatN. Note that this object will only be instantiated if the agent supports high-capacity monitoring for a particular dataSource." ::= { tpmAggrReportEntry 8 } tpmAggrReportStatSumX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of all the data point values for the specified metric. This number always represents the total values of the statistical datum analyzed. Each metric specifies the exact meaning of this object. Dietz & Cole Standards Track [Page 33] RFC 4150 TPM-MIB August 2005 This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmAggrReportEntry 9 } tpmAggrReportOverflowStatSumX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmAggrReportStatSumX counter has overflowed. Note that this object will only be instantiated if the associated tpmAggrReportHCStatSumX object is also instantiated for a particular dataSource." ::= { tpmAggrReportEntry 10 } tpmAggrReportHCStatSumX OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmAggrReportStatSumX. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmAggrReportEntry 11 } tpmAggrReportStatMaximum OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The single maximum data point value observed during the study period for the specified metric. This number always represents the maximum value of any single statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmAggrReportEntry 12 } tpmAggrReportStatMinimum OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current Dietz & Cole Standards Track [Page 34] RFC 4150 TPM-MIB August 2005 DESCRIPTION "The single minimum data point value observed during the study period for the specified metric. This number always represents the minimum value of any single statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmAggrReportEntry 13 } tpmAggrReportStatSumSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of all the squared data point values for the specified metric. This number always represents the total of the squared values of the statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmAggrReportEntry 14 } tpmAggrReportOverflowStatSumSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmAggrReportStatSumSq counter has overflowed. Note that this object will only be instantiated if the associated tpmAggrReportHCStatSumSq object is also instantiated for a particular dataSource." ::= { tpmAggrReportEntry 15 } tpmAggrReportHCStatSumSq OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmAggrReportStatSumSq. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular Dietz & Cole Standards Track [Page 35] RFC 4150 TPM-MIB August 2005 dataSource." ::= { tpmAggrReportEntry 16 } tpmAggrReportStatSumIX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For each interval, each data point is associated with a value I, I = 1..N where N is the number of data points; tpmAggrReportStatSumIX is the multiplication of the data point value with the current I. This value along with the other statistics values allow the calculation of the slope of the least-squares line through the data points." ::= { tpmAggrReportEntry 17 } tpmAggrReportOverflowStatSumIX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmAggrReportStatSumIX counter has overflowed. Note that this object will only be instantiated if the associated tpmAggrReportHCStatSumIX object is also instantiated for a particular dataSource." ::= { tpmAggrReportEntry 18 } tpmAggrReportHCStatSumIX OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmAggrReportStatSumIX. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmAggrReportEntry 19 } tpmAggrReportStatSumIXSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For each interval, each data point is associated with a value I, I = 1..N where N is the number of data points; tpmAggrReportStatSumIXSq is the multiplication Dietz & Cole Standards Track [Page 36] RFC 4150 TPM-MIB August 2005 of the data point value with the current I. This value along with the other statistics values allow the calculation of the slope of the least-squares line through the data points." ::= { tpmAggrReportEntry 20 } tpmAggrReportOverflowStatSumIXSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmAggrReportStatSumIXSq counter has overflowed. Note that this object will only be instantiated if the associated tpmAggrReportHCStatSumIXSq object is also instantiated for a particular dataSource." ::= { tpmAggrReportEntry 21 } tpmAggrReportHCStatSumIXSq OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmAggrReportStatSumIXSq. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmAggrReportEntry 22 } -- -- The tpmCurrentReportsGroup -- tpmCurReportTable OBJECT-TYPE SYNTAX SEQUENCE OF TpmCurReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table will contain entries associated with an apmReportControlEntry that consitute a current 'snapshot' of the metrics being collected in association with a set of TPM-related application transactions. This table contains all sub-flow metrics for transactions that have been started but have not yet finished (i.e., current) and a history of those that have finished (i.e., completed). It may not always be obvious from the context whether a transaction is currently in-progress or has been completed. Therefore, the completion status of a Dietz & Cole Standards Track [Page 37] RFC 4150 TPM-MIB August 2005 transaction is indicated by the value of the tpmCurReportCompletion object." ::= { tpmReports 3 } tpmCurReportEntry OBJECT-TYPE SYNTAX TpmCurReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the tpmCurReportTable. The tpmAggrReportControlIndex value in the index identifies the tpmAggrReportCntrlEntry on whose behalf this entry was created. The tpmCurReportAppLocalIndex value in the index identifies the application protocol that is being reported. The protocolDirLocalIndex value in the index identifies the network layer protocol of the tpmAggrReportServerAddress. When the associated tpmAggrReportCntrlAggrType value is equal to applications(4), this value will equal 0. The tpmCurReportServerAddress value in the index identifies the network layer address of the server in traffic flows aggregated in this entry. The tpmCurReportCurrentApmNameClientID value in the index identifies the network layer address of the client in traffic flows aggregated in this entry. The tpmCurReportCurrentMetricIndex value in the index identifies the transported application protocol of the traffic flows aggregated in this entry. Note that the order of protocolDirLocalIndex variables is the opposite of that in the RMON2 MIB (application.network instead of network.application); the report entries are sorted by application first, server second, and client third. The tpmCurReportCntrIndex value in the index identifies the tpmAggrReportCntrlEntry on whose behalf this entry was created. The tpmCurReportMetricIndex value in the index identifies the metric and protocol of the tpmCurReportServerAddress, via the tpmTransMetricDir table. An example of the indexing of this table is tpmCurReportStatisticN.3.34.262.18.4.128.2.6.6.3256521.29667" INDEX { tpmAggrReportCntrlIndex, tpmCurReportAppLocalIndex, -- Application Layer tpmCurReportTransMetricIndex, -- Metric and Protocol protocolDirLocalIndex, -- Network Layer tpmCurReportServerAddress, Dietz & Cole Standards Track [Page 38] RFC 4150 TPM-MIB August 2005 tpmCurReportApmNameClientID, tpmCurReportApmTransactionID } ::= { tpmCurReportTable 1 } TpmCurReportEntry ::= SEQUENCE { tpmCurReportAppLocalIndex AppLocalIndex, tpmCurReportTransMetricIndex TpmTransactionMetricIndex, tpmCurReportServerAddress OCTET STRING, tpmCurReportApmNameClientID RmonClientID, tpmCurReportApmTransactionID Unsigned32, tpmCurReportMetricValue ZeroBasedCounter32, tpmCurReportCompletion INTEGER } tpmCurReportAppLocalIndex OBJECT-TYPE SYNTAX AppLocalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The common application of the transactions reported in this entry." ::= { tpmCurReportEntry 1 } tpmCurReportTransMetricIndex OBJECT-TYPE SYNTAX TpmTransactionMetricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index that identifies the transaction and metric associated with the statistics reported here." ::= { tpmCurReportEntry 2 } tpmCurReportServerAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..108)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network server address for this tpmCurReportEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IPv4, this object is encoded as a length octet of 4, followed by the 4 octets of the IPv4 address, in network byte order." Dietz & Cole Standards Track [Page 39] RFC 4150 TPM-MIB August 2005 ::= { tpmCurReportEntry 3 } tpmCurReportApmNameClientID OBJECT-TYPE SYNTAX RmonClientID MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique ID assigned to the machine represented by this mapping. This ID is assigned by the agent using an implementation-specific algorithm." ::= { tpmCurReportEntry 4 } tpmCurReportApmTransactionID OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for this transaction amongst other transactions sharing the same application, transaction-layer protocol and metric, and server and client addresses. Implementations may choose to use the value of the client's source port, when possible. If the tpmAggrReportCntrlApmCntrlIndex is non-zero, then this object is set to the corresponding apmTransactionID object in the APM-MIB developed in the IETF's RMONMIB WG." ::= { tpmCurReportEntry 5 } tpmCurReportMetricValue OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current value of the metric being evaluated. For some transaction types this value may be 0, e.g., the current round-trip time for a DNS query. For other transaction types, this will represent the current value of a continuously measured metric, e.g., the current throughput of an FTP transaction." ::= { tpmCurReportEntry 6 } tpmCurReportCompletion OBJECT-TYPE SYNTAX INTEGER { current(1), completed(2) } MAX-ACCESS read-only Dietz & Cole Standards Track [Page 40] RFC 4150 TPM-MIB August 2005 STATUS current DESCRIPTION "The status of this transaction. It is not always obvious from context whether a transaction is ongoing or completed. E.g., an ftp-GET transaction may last several minutes or hours, and a value found in the tpmCurReportMetricValue object lists to observed throughput for the transaction up to this point in time. The value of the tpmCurReportCompletion indicates whether the transaction has been completed." ::= { tpmCurReportEntry 7 } tpmCurReportSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of completed transactions desired to be retained in the tpmCurReportTable. If the agent doesn't have enough resources to retain this many, it will retain as many as possible. Regardless of this value, the agent must attempt to keep records for all current transactions it is monitoring. The agent should consider this value to give a hint as to how many transactions to save. This is not a hard limit, just a hint to a maximum value of interest. If this value is reduced by the management station, the agent can take note, it may free some records, or it may do nothing. The value of this object must persist across reboots." ::= { tpmReports 4 } -- -- The tpmExceptionReportsGroup -- tpmExcpReportTable OBJECT-TYPE SYNTAX SEQUENCE OF TpmExcpReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all sub-flow metrics for transactions that have been tagged by the apmExceptionTable filter as having had poor performance." ::= { tpmReports 5 } tpmExcpReportEntry OBJECT-TYPE Dietz & Cole Standards Track [Page 41] RFC 4150 TPM-MIB August 2005 SYNTAX TpmExcpReportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the tpmExcpReportTable. This table contains aggregated information associated with exceptions counted in the apmExceptionTable. The information is aggregated in a manner identical to the aggregation in the tpmAggrReportTable, with the exception that data only from transactions associated with a flagged application is included. The indexing into this table follows the indexing in the APM-MIB but adds the tpmTransMetricIndex to identify the sub-application transaction and metric pair." INDEX { apmAppDirAppLocalIndex, -- Application apmAppDirResponsivenessType, -- Responsiveness Type apmExceptionIndex, -- Linkage to ApmExceptions tpmExcpReportTransMetricIndex -- Metric and Protocol } ::= { tpmExcpReportTable 1 } TpmExcpReportEntry ::= SEQUENCE { tpmExcpReportTransMetricIndex TpmTransactionMetricIndex, tpmExcpReportStatN ZeroBasedCounter32, tpmExcpReportOverflowStatN ZeroBasedCounter32, tpmExcpReportHCStatN ZeroBasedCounter64, tpmExcpReportStatSumX ZeroBasedCounter32, tpmExcpReportOverflowStatSumX ZeroBasedCounter32, tpmExcpReportHCStatSumX ZeroBasedCounter64, tpmExcpReportStatMaximum ZeroBasedCounter32, tpmExcpReportStatMinimum ZeroBasedCounter32, tpmExcpReportStatSumSq ZeroBasedCounter32, tpmExcpReportOverflowStatSumSq ZeroBasedCounter32, tpmExcpReportHCStatSumSq ZeroBasedCounter64, tpmExcpReportStatSumIX ZeroBasedCounter32, tpmExcpReportOverflowStatSumIX ZeroBasedCounter32, tpmExcpReportHCStatSumIX ZeroBasedCounter64, tpmExcpReportStatSumIXSq ZeroBasedCounter32, tpmExcpReportOverflowStatSumIXSq ZeroBasedCounter32, tpmExcpReportHCStatSumIXSq ZeroBasedCounter64 } tpmExcpReportTransMetricIndex OBJECT-TYPE SYNTAX TpmTransactionMetricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION Dietz & Cole Standards Track [Page 42] RFC 4150 TPM-MIB August 2005 "A unique index that identifies the transaction and metric associated with the data reported here." ::= { tpmExcpReportEntry 1 } tpmExcpReportStatN OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the total number of data points for the specified metric. This number always represents the total size of the statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmExcpReportEntry 2 } tpmExcpReportOverflowStatN OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmExcpReportStatN counter has overflowed. Note that this object will only be instantiated if the associated tpmExcpReportHCStatN object is also instantiated for a particular dataSource." ::= { tpmExcpReportEntry 3 } tpmExcpReportHCStatN OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmExcpReportStatN. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmExcpReportEntry 4 } tpmExcpReportStatSumX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of all the data point values for the specified metric. This number always represents the total values Dietz & Cole Standards Track [Page 43] RFC 4150 TPM-MIB August 2005 of the statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmExcpReportEntry 5 } tpmExcpReportOverflowStatSumX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmExcpReportStatSumX counter has overflowed. Note that this object will only be instantiated if the associated tpmExcpReportHCStatSumX object is also instantiated for a particular dataSource." ::= { tpmExcpReportEntry 6 } tpmExcpReportHCStatSumX OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmExcpReportStatSumX. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmExcpReportEntry 7 } tpmExcpReportStatMaximum OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The single maximum data point value observed during the study period for the specified metric. This number always represents the maximum value of any single statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmExcpReportEntry 8 } tpmExcpReportStatMinimum OBJECT-TYPE Dietz & Cole Standards Track [Page 44] RFC 4150 TPM-MIB August 2005 SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The single minimum data point value observed during the study period for the specified metric. This number always represents the minimum value of any single statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmExcpReportEntry 9 } tpmExcpReportStatSumSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of all the squared data point values for the specified metric. This number always represents the total of the squared values of the statistical datum analyzed. Each metric specifies the exact meaning of this object. This value represents the results of one metric and is related directly to the specific parameters of the metric and the Server and Client addresses involved." ::= { tpmExcpReportEntry 10 } tpmExcpReportOverflowStatSumSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmExcpReportStatSumSq counter has overflowed. Note that this object will only be instantiated if the associated tpmExcpReportHCStatSumSq object is also instantiated for a particular dataSource." ::= { tpmExcpReportEntry 11 } tpmExcpReportHCStatSumSq OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION Dietz & Cole Standards Track [Page 45] RFC 4150 TPM-MIB August 2005 "The high-capacity version of tpmExcpReportStatSumSq. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmExcpReportEntry 12 } tpmExcpReportStatSumIX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For each interval, each data point is associated with a value I, I = 1..N where N is the number of data points; tpmExcpReportStatSumIX is the multiplication of the data point value with the current I. This value along with the other statistics values allow the calculation of the slope of the least-squares line through the data points." ::= { tpmExcpReportEntry 13 } tpmExcpReportOverflowStatSumIX OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmExcpReportStatSumIX counter has overflowed. Note that this object will only be instantiated if the associated tpmExcpReportHCStatSumIX object is also instantiated for a particular dataSource." ::= { tpmExcpReportEntry 14 } tpmExcpReportHCStatSumIX OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmExcpReportStatSumIX. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmExcpReportEntry 15 } tpmExcpReportStatSumIXSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For each interval, each data point is associated with a Dietz & Cole Standards Track [Page 46] RFC 4150 TPM-MIB August 2005 value I, I = 1..N where N is the number of data points; tpmExcpReportStatSumIXSq is the multiplication of the data point value with the current I. This value along with the other statistics values allow the calculation of the slope of the least-squares line through the data points." ::= { tpmExcpReportEntry 16 } tpmExcpReportOverflowStatSumIXSq OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated tpmExcpReportStatSumIXSq counter has overflowed. Note that this object will only be instantiated if the associated tpmExcpReportHCStatSumIXSq object is also instantiated for a particular dataSource." ::= { tpmExcpReportEntry 17 } tpmExcpReportHCStatSumIXSq OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The high-capacity version of tpmExcpReportStatSumIXSq. Note that this object will only be instantiated if the agent supports High Capacity monitoring for a particular dataSource." ::= { tpmExcpReportEntry 18 } -- -- TPM Conformance -- tpmMIBCompliances OBJECT IDENTIFIER ::= { tpmConformance 1 } tpmGroups OBJECT IDENTIFIER ::= { tpmConformance 2 } -- -- TPM Compliance Statement -- tpmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the TPM-MIB. This compliance statement defines the following Dietz & Cole Standards Track [Page 47] RFC 4150 TPM-MIB August 2005 TPM-MIB implementation: - tpmCapabilitiesGroup (minimum) - tpmAggregateReportsGroup (minimum) - tpmCurrentReportsGroup (optional) - tpmExceptionReportsGroup (optional). In order to implement the (optional) tpmExceptionReportsGroup, it is necessary to implement pieces of the APM-MIB as described in the tpmApmMIBCompliance MODULE below. Further, in the event that the TPM-MIB is used to provide a drill-down capability, which is the true value of this MIB, then the tpmApmReportControlGroup must be implemented." MODULE -- this module MANDATORY-GROUPS { tpmCapabilitiesGroup, tpmAggregateReportsGroup } GROUP tpmCurrentReportsGroup DESCRIPTION "The implementation of this group is optional." GROUP tpmExceptionReportsGroup DESCRIPTION "The implementation of this group is optional. However, because the control for this reporting group resides with the APM-MIB module, the apmReportGroup and the apmExceptionGroup must also be implemented." ::= { tpmMIBCompliances 1 } -- -- tpmCurrentReportsGroup Compliance -- tpmCurrentReportsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This defines the Current Reports compliance. This is useful when information on in-progress and historical transaction-level data is desired." MODULE -- this module MANDATORY-GROUPS { tpmCapabilitiesGroup, Dietz & Cole Standards Track [Page 48] RFC 4150 TPM-MIB August 2005 tpmAggregateReportsGroup, tpmCurrentReportsGroup } ::= { tpmMIBCompliances 2 } -- -- tpmExceptionReportsGroup Compliance -- tpmExceptionReportsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This defines the Exception Reports compliance. This is useful when information on transactions whose performance is deemed out-of-bounds." MODULE -- this module MANDATORY-GROUPS { tpmCapabilitiesGroup, tpmAggregateReportsGroup, tpmExceptionReportsGroup } MODULE APM-MIB MANDATORY-GROUPS { apmReportGroup, apmExceptionGroup } ::= { tpmMIBCompliances 3 } -- -- TPM-MIB Groups -- tpmCapabilitiesGroup OBJECT-GROUP OBJECTS { tpmClockResolution, tpmClockMaxSkew, tpmClockSource, tpmTransMetricDirLastChange, tpmTransMetricProtocolIndex, tpmTransMetricMetricIndex, tpmTransMetricDirConfig, tpmMetricDefType, tpmMetricDefDirType, tpmMetricDefName, tpmMetricDefReference, tpmMetricDefGlobalID } Dietz & Cole Standards Track [Page 49] RFC 4150 TPM-MIB August 2005 STATUS current DESCRIPTION "The tpmCapabilitiesGroup specifies various capabilities associated with the monitoring agent." ::= { tpmGroups 1 } tpmAggregateReportsGroup OBJECT-GROUP OBJECTS { tpmAggrReportCntrlApmCntrlIndex, tpmAggrReportCntrlDataSource, tpmAggrReportCntrlAggrType, tpmAggrReportCntrlInterval, tpmAggrReportCntrlReqSize, tpmAggrReportCntrlGrantedSize, tpmAggrReportCntrlReqReports, tpmAggrReportCntrlGrantedReports, tpmAggrReportCntrlStartTime, tpmAggrReportCntrlReportNumber, tpmAggrReportCntrlInsertsDenied, tpmAggrReportCntrlDroppedFrames, tpmAggrReportCntrlOwner, tpmAggrReportCntrlStorageType, tpmAggrReportCntrlStatus, tpmAggrReportStatN, tpmAggrReportOverflowStatN, tpmAggrReportHCStatN, tpmAggrReportStatSumX, tpmAggrReportOverflowStatSumX, tpmAggrReportHCStatSumX, tpmAggrReportStatMaximum, tpmAggrReportStatMinimum, tpmAggrReportStatSumSq, tpmAggrReportOverflowStatSumSq, tpmAggrReportHCStatSumSq, tpmAggrReportStatSumIX, tpmAggrReportOverflowStatSumIX, tpmAggrReportHCStatSumIX, tpmAggrReportStatSumIXSq, tpmAggrReportOverflowStatSumIXSq, tpmAggrReportHCStatSumIXSq } STATUS current DESCRIPTION "The tpmAggregateReportsGroup provides control and reporting of aggregate measurement statistics." ::= { tpmGroups 2 } tpmCurrentReportsGroup OBJECT-GROUP OBJECTS { tpmCurReportMetricValue, Dietz & Cole Standards Track [Page 50] RFC 4150 TPM-MIB August 2005 tpmCurReportCompletion, tpmCurReportSize } STATUS current DESCRIPTION "The tpmCurrentReportsGroup contains metric information relating to ongoing measurements as well as historical values." ::= { tpmGroups 3 } tpmExceptionReportsGroup OBJECT-GROUP OBJECTS { tpmExcpReportStatN, tpmExcpReportOverflowStatN, tpmExcpReportHCStatN, tpmExcpReportStatSumX, tpmExcpReportOverflowStatSumX, tpmExcpReportHCStatSumX, tpmExcpReportStatMaximum, tpmExcpReportStatMinimum, tpmExcpReportStatSumSq, tpmExcpReportOverflowStatSumSq, tpmExcpReportHCStatSumSq, tpmExcpReportStatSumIX, tpmExcpReportOverflowStatSumIX, tpmExcpReportHCStatSumIX, tpmExcpReportStatSumIXSq, tpmExcpReportOverflowStatSumIXSq, tpmExcpReportHCStatSumIXSq } STATUS current DESCRIPTION "The tpmExceptionReportsGroup reports sub-application level statistics associated with errant applications." ::= { tpmGroups 4 } END 5. Acknowledgements This memo has been produced with a great deal of assistance from David Craver, Joseph Maixner, and John Metzger of Hifn, Inc. The authors also gratefully acknowledge the beneficial discussions they have had with Carter Bullard of QoSient, LLC. The tpmMetricDefTable was taken from Andy Bierman's performance management capabilities document, which was proposed early on in the RMON WG during the formation of the TPM and APM MIB work. Finally, this MIB module draws heavily from the work of Steve Waldbusser and his APM-MIB [RFC3729]. Dietz & Cole Standards Track [Page 51] RFC 4150 TPM-MIB August 2005 6. Security Considerations This MIB relates to a system that provides a passive monitoring capability of a broadcast subnet, a switched subnet, or point-to- point subnets. As such, it collects information relating to network layer addresses and traffic statistics relating to conversations and to application-level activities. These statistics could be deemed sensitive in certain networking environments. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: + The tpmTransMetricDirConfig object describes and configures the probe's support for a given performance metric in relation to a specified transaction and application. The agent creates entries in this table for all metric and transaction combinations that it can generate, and this object controls the on/off switch for this capability. If certain statistics for a supported transaction are deemed sensitive, then access to SET operations on this object should be protected. + The tpmAggrReportCntrlDataSource sets the interface on which the network addresses and conversational and application-level statistics will be collected. + The tpmAggrReportCntrlAggrType object controls the level of data aggregation implemented in the report tables. For example, this object could be set to allow client-level information to be exposed. In order to implement this MIB module, an agent must make certain management information available about protocols and network addresses used within a managed system, which may be considered sensitive in some network environments. Therefore some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Dietz & Cole Standards Track [Page 52] RFC 4150 TPM-MIB August 2005 + The tpmAggrReportTable contains the statistical studies which the probe was configured to generate. These tables contain the historical, aggregated data providing information on the network address and traffic statistics related to their conversations. + The tpmCurReportTable contains information on current transaction flows. This table provides a view of the current activity on a subnet or a client machine. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Normative References [RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Dietz & Cole Standards Track [Page 53] RFC 4150 TPM-MIB August 2005 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring MIB", STD 59, RFC 2819, May 2000. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC2895] Bierman, A., Bucci, C., and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2895, August 2000. [RFC3273] Waldbusser, S., "Remote Network Monitoring Management Information Base for High Capacity Networks", RFC 3273, July 2002. [RFC3395] Bierman, A., Bucci, C., Dietz, R., and A. Warth "Remote Network Monitoring MIB Protocol Identifiers Reference Extensions", RFC 3395, September 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004. [RFC4149] Kalbfleisch, K., Cole, R., and D. Romascanu, "Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms", RFC 4149, August 2005. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", RFC 4148, August 2005. 8. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [Y.1540] The ITU-T Recommendation Y.1540, "IP Data Transport Service - IP packet transfer performance metrics", ITU-T Rec. Y.1540, December 2002. Dietz & Cole Standards Track [Page 54] RFC 4150 TPM-MIB August 2005 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-Way Packet Loss Metric for IPPM" RFC 2680, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-Trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network Performance Measurement with Periodic Streams", RFC 3432, November 2002. Dietz & Cole Standards Track [Page 55] RFC 4150 TPM-MIB August 2005 Authors' Addresses Russell Dietz Hifn, Inc. 750 University Ave Los Gatos, CA, USA 95032-7695 Tel: +1 408 399-3623 Fax: +1 408 399-3501 EMail: rdietz@hifn.com Robert Cole Johns Hopkins University Applied Physics Laboratory MP2-170 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA Tel: +1 443-778-6951 EMail: robert.cole@jhuapl.edu Dietz & Cole Standards Track [Page 56] RFC 4150 TPM-MIB August 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Dietz & Cole Standards Track [Page 57] snmp-mibs-downloader-1.1/mibrfcs/rfc4188.txt0000644000000000000000000025153511402176072015602 0ustar Network Working Group K. Norseth, Ed. Request for Comments: 4188 L-3 Communications Obsoletes: 1493 E. Bell, Ed. Category: Standards Track 3Com Europe Limited September 2005 Definitions of Managed Objects for Bridges 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax. This memo obsoletes RFC 1493. Norseth & Bell, Eds. Standards Track [Page 1] RFC 4188 Bridge MIB September 2005 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Conventions .....................................................2 3. Overview ........................................................3 3.1. Structure of the MIB Module ................................3 3.1.1. The dot1dBase Subtree ...............................6 3.1.2. The dot1dStp Subtree ................................6 3.1.3. The dot1dSr Subtree .................................6 3.1.4. The dot1dTp Subtree .................................6 3.1.5. The dot1dStatic Subtree .............................6 3.2. Relationship to Other MIB Modules ..........................6 3.2.1. Relationship to the SNMPv2-MIB ......................7 3.2.2. Relationship to the IF-MIB ..........................7 4. Definitions .....................................................8 5. IANA Considerations ............................................39 6. Security Considerations ........................................39 7. Acknowledgements ...............................................40 8. Contact Information ............................................41 9. Changes from RFC 1493 ..........................................42 10. References ....................................................42 10.1. Normative References .....................................42 10.2. Informative References ...................................43 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Norseth & Bell, Eds. Standards Track [Page 2] RFC 4188 Bridge MIB September 2005 3. Overview A common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the network layer. There are two major modes defined for this bridging: transparent and source route. The transparent method of bridging is defined in the IEEE 802.1D specification [IEEE8021D]. This memo defines those objects needed for the management of a bridging entity that operates in the transparent mode, as well as some objects that apply to all types of bridges. To be consistent with IAB directives and good engineering practices, an explicit attempt was made to keep this MIB module as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: 1. Start with a small set of essential objects and add only as further objects are needed. 2. Require that objects be essential for either fault or configuration management. 3. Consider evidence of current use and/or utility. 4. Limit the total number of objects. 5. Exclude objects that are simply derivable from others in this or other MIB modules. 6. Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. 3.1 Structure of the MIB Module Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees is shown below. Where appropriate, the corresponding IEEE 802.1D [IEEE8021D] management object name is also included. Norseth & Bell, Eds. Standards Track [Page 3] RFC 4188 Bridge MIB September 2005 Bridge MIB Name IEEE 802.1D Name dot1dBridge dot1dBase BridgeAddress Bridge.BridgeAddress NumPorts Bridge.NumberOfPorts Type PortTable Port BridgePort.PortNumber IfIndex Circuit DelayExceededDiscards .DiscardTransitDelay MtuExceededDiscards .DiscardOnError dot1dStp ProtocolSpecification Priority SpanningTreeProtocol .BridgePriority TimeSinceTopologyChange .TimeSinceTopologyChange TopChanges .TopologyChangeCount DesignatedRoot .DesignatedRoot RootCost .RootCost RootPort .RootPort MaxAge .MaxAge HelloTime .HelloTime HoldTime .HoldTime ForwardDelay .ForwardDelay BridgeMaxAge .BridgeMaxAge BridgeHelloTime .BridgeHelloTime BridgeForwardDelay .BridgeForwardDelay PortTable Port SpanningTreeProtocolPort .PortNumber Priority .PortPriority State .SpanningTreeState Enable PathCost .PortPathCost DesignatedRoot .DesignatedRoot DesignatedCost .DesignatedCost DesignatedBridge .DesignatedBridge DesignatedPort .DesignatedPort ForwardTransitions Norseth & Bell, Eds. Standards Track [Page 4] RFC 4188 Bridge MIB September 2005 dot1dTp LearnedEntryDiscards BridgeFilter.DatabaseSize .NumDynamic,NumStatic AgingTime BridgeFilter.AgingTime FdbTable Address Port Status PortTable Port MaxInfo InFrames BridgePort.FramesReceived OutFrames .ForwardOutbound InDiscards .DiscardInbound dot1dStatic StaticTable Address ReceivePort AllowedToGoTo Status The following IEEE 802.1D management objects have not been included in the BRIDGE-MIB module for the indicated reasons. IEEE 802.1D Object Disposition Bridge.BridgeName Same as sysDescr (SNMPv2-MIB) Bridge.BridgeUpTime Same as sysUpTime (SNMPv2-MIB) Bridge.PortAddresses Same as ifPhysAddress (IF-MIB) BridgePort.PortName Same as ifDescr (IF-MIB) BridgePort.PortType Same as ifType (IF-MIB) BridgePort.RoutingType Derivable from the implemented subtrees SpanningTreeProtocol .BridgeIdentifier Combination of dot1dStpPriority and dot1dBaseBridgeAddress .TopologyChange Since this is transitory, it is not considered useful. SpanningTreeProtocolPort .Uptime Same as ifLastChange (IF-MIB) .PortIdentifier Combination of dot1dStpPort and dot1dStpPortPriority .TopologyChangeAcknowledged Since this is transitory, it is not considered useful. .DiscardLackOfBuffers Redundant Norseth & Bell, Eds. Standards Track [Page 5] RFC 4188 Bridge MIB September 2005 Transmission Priority These objects are not required as per the Pics Proforma and are not considered useful. .TransmissionPriorityName .OutboundUserPriority .OutboundAccessPriority 3.1.1 The dot1dBase Subtree This subtree contains the objects that are applicable to all types of bridges. 3.1.2 The dot1dStp Subtree This subtree contains the objects that denote the bridge's state with respect to the Spanning Tree Protocol. If a node does not implement the Spanning Tree Protocol, this subtree will not be implemented. 3.1.3 The dot1dSr Subtree This subtree contains the objects that describe the entity's state with respect to source route bridging. This subtree described in RFC 1525 [RFC1525] is applicable only to source route bridging. 3.1.4 The dot1dTp Subtree This subtree contains objects that describe the entity's state with respect to transparent bridging. If transparent bridging is not supported, this subtree will not be implemented. This subtree is applicable to transparent-only and SRT bridges. 3.1.5 The dot1dStatic Subtree This subtree contains objects that describe the entity's state with respect to destination-address filtering. If destination-address filtering is not supported, this subtree will not be implemented. This subtree is applicable to any type of bridge that performs destination-address filtering. 3.2 Relationship to Other MIB Modules As described above, some IEEE 802.1D management objects have not been included in this MIB module because they overlap with objects in other MIB modules that are applicable to a bridge implementing this MIB module. Norseth & Bell, Eds. Standards Track [Page 6] RFC 4188 Bridge MIB September 2005 3.2.1 Relationship to the SNMPv2-MIB The SNMPv2-MIB [RFC3418] defines objects that are generally applicable to managed devices. These objects apply to the device as a whole, irrespective of whether the device's sole functionality is bridging, or whether bridging is only a subset of the device's functionality. As explained in Section 3.1, full support for the 802.1D management objects requires that the SNMPv2-MIB objects sysDescr and sysUpTime be implemented. Note that compliance with the current SNMPv2-MIB module requires additional objects and notifications to be implemented, as specified in RFC 3418 [RFC3418]. 3.2.2 Relationship to the IF-MIB The IF-MIB [RFC2863] defines managed objects for managing network interfaces. A network interface is thought of as being attached to a `subnetwork'. Note that this term is not to be confused with `subnet', which refers to an addressing partitioning scheme used in the Internet suite of protocols. The term 'segment' is used in this memo to refer to such a subnetwork, whether it be an Ethernet segment, a 'ring', a WAN link, or even an X.25 virtual circuit. As explained in Section 3.1, full support for the 802.1D management objects requires that the IF-MIB objects ifIndex, ifType, ifDescr, ifPhysAddress, and ifLastChange are implemented. Note that compliance to the current IF-MIB module requires additional objects and notifications to be implemented as specified in RFC 2863 [RFC2863]. Implicit in this BRIDGE-MIB is the notion of ports on a bridge. Each of these ports is associated with one interface of the 'interfaces' subtree, and in most situations, each port is associated with a different interface. However, there are situations in which multiple ports are associated with the same interface. An example of such a situation would be several ports, each corresponding, one-to-one, with several X.25 virtual circuits that are all on the same interface. Each port is uniquely identified by a port number. A port number has no mandatory relationship to an interface number, but in the simple case, a port number will have the same value as the corresponding interface's interface number. Port numbers are in the range (1..dot1dBaseNumPorts). Norseth & Bell, Eds. Standards Track [Page 7] RFC 4188 Bridge MIB September 2005 Some entities perform other functionalities as well as bridging through the sending and receiving of data on their interfaces. In such situations, only a subset of the data sent/received on an interface is within the domain of the entity's bridging functionality. This subset is considered to be delineated according to a set of protocols, with some protocols being bridged, and other protocols not being bridged. For example, in an entity that exclusively performs bridging, all protocols would be considered as bridged, whereas in an entity that performs IP routing on IP datagrams and only bridges other protocols, only the non-IP data would be considered as having been bridged. Thus, this BRIDGE-MIB (and in particular, its counters) are applicable only to that subset of the data on an entity's interfaces that is sent/received for a protocol being bridged. All such data is sent/received via the ports of the bridge. 4. Definitions BRIDGE-MIB DEFINITIONS ::= BEGIN -- ---------------------------------------------------------- -- -- MIB for IEEE 802.1D devices -- ---------------------------------------------------------- -- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, TimeTicks, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, MacAddress FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB ; dot1dBridge MODULE-IDENTITY LAST-UPDATED "200509190000Z" ORGANIZATION "IETF Bridge MIB Working Group" CONTACT-INFO "Email: bridge-mib@ietf.org K.C. Norseth (Editor) L-3 Communications Tel: +1 801-594-2809 Email: kenyon.c.norseth@L-3com.com Postal: 640 N. 2200 West. Salt Lake City, Utah 84116-0850 Norseth & Bell, Eds. Standards Track [Page 8] RFC 4188 Bridge MIB September 2005 Les Bell (Editor) 3Com Europe Limited Phone: +44 1442 438025 Email: elbell@ntlworld.com Postal: 3Com Centre, Boundary Way Hemel Hempstead Herts. HP2 7YU UK Send comments to " DESCRIPTION "The Bridge MIB module for managing devices that support IEEE 802.1D. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4188; see the RFC itself for full legal notices." REVISION "200509190000Z" DESCRIPTION "Third revision, published as part of RFC 4188. The MIB module has been converted to SMIv2 format. Conformance statements have been added and some description and reference clauses have been updated. The object dot1dStpPortPathCost32 was added to support IEEE 802.1t and the permissible values of dot1dStpPriority and dot1dStpPortPriority have been clarified for bridges supporting IEEE 802.1t or IEEE 802.1w. The interpretation of dot1dStpTimeSinceTopologyChange has been clarified for bridges supporting the Rapid Spanning Tree Protocol (RSTP)." REVISION "199307310000Z" DESCRIPTION "Second revision, published as part of RFC 1493." REVISION "199112310000Z" DESCRIPTION "Initial revision, published as part of RFC 1286." ::= { mib-2 17 } -- ---------------------------------------------------------- -- -- Textual Conventions -- ---------------------------------------------------------- -- BridgeId ::= TEXTUAL-CONVENTION Norseth & Bell, Eds. Standards Track [Page 9] RFC 4188 Bridge MIB September 2005 STATUS current DESCRIPTION "The Bridge-Identifier, as used in the Spanning Tree Protocol, to uniquely identify a bridge. Its first two octets (in network byte order) contain a priority value, and its last 6 octets contain the MAC address used to refer to a bridge in a unique fashion (typically, the numerically smallest MAC address of all ports on the bridge)." SYNTAX OCTET STRING (SIZE (8)) Timeout ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A Spanning Tree Protocol (STP) timer in units of 1/100 seconds. Several objects in this MIB module represent values of timers used by the Spanning Tree Protocol. In this MIB, these timers have values in units of hundredths of a second (i.e., 1/100 secs). These timers, when stored in a Spanning Tree Protocol's BPDU, are in units of 1/256 seconds. Note, however, that 802.1D-1998 specifies a settable granularity of no more than one second for these timers. To avoid ambiguity, a conversion algorithm is defined below for converting between the different units, which ensures a timer's value is not distorted by multiple conversions. To convert a Timeout value into a value in units of 1/256 seconds, the following algorithm should be used: b = floor( (n * 256) / 100) where: floor = quotient [ignore remainder] n is the value in 1/100 second units b is the value in 1/256 second units To convert the value from 1/256 second units back to 1/100 seconds, the following algorithm should be used: n = ceiling( (b * 100) / 256) where: ceiling = quotient [if remainder is 0], or quotient + 1 [if remainder is nonzero] n is the value in 1/100 second units Norseth & Bell, Eds. Standards Track [Page 10] RFC 4188 Bridge MIB September 2005 b is the value in 1/256 second units Note: it is important that the arithmetic operations are done in the order specified (i.e., multiply first, divide second)." SYNTAX Integer32 -- ---------------------------------------------------------- -- -- subtrees in the Bridge MIB -- ---------------------------------------------------------- -- dot1dNotifications OBJECT IDENTIFIER ::= { dot1dBridge 0 } dot1dBase OBJECT IDENTIFIER ::= { dot1dBridge 1 } dot1dStp OBJECT IDENTIFIER ::= { dot1dBridge 2 } dot1dSr OBJECT IDENTIFIER ::= { dot1dBridge 3 } -- documented in RFC 1525 dot1dTp OBJECT IDENTIFIER ::= { dot1dBridge 4 } dot1dStatic OBJECT IDENTIFIER ::= { dot1dBridge 5 } -- Subtrees used by Bridge MIB Extensions: -- pBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 6 } -- qBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 7 } -- Note that the practice of registering related MIB modules -- below dot1dBridge has been discouraged since there is no -- robust mechanism to track such registrations. dot1dConformance OBJECT IDENTIFIER ::= { dot1dBridge 8 } -- ---------------------------------------------------------- -- -- the dot1dBase subtree -- ---------------------------------------------------------- -- -- Implementation of the dot1dBase subtree is mandatory for all -- bridges. -- ---------------------------------------------------------- -- dot1dBaseBridgeAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC address used by this bridge when it must be referred to in a unique fashion. It is recommended that this be the numerically smallest MAC address of all ports that belong to this bridge. However, it is only Norseth & Bell, Eds. Standards Track [Page 11] RFC 4188 Bridge MIB September 2005 required to be unique. When concatenated with dot1dStpPriority, a unique BridgeIdentifier is formed, which is used in the Spanning Tree Protocol." REFERENCE "IEEE 802.1D-1998: clauses 14.4.1.1.3 and 7.12.5" ::= { dot1dBase 1 } dot1dBaseNumPorts OBJECT-TYPE SYNTAX Integer32 UNITS "ports" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ports controlled by this bridging entity." REFERENCE "IEEE 802.1D-1998: clause 14.4.1.1.3" ::= { dot1dBase 2 } dot1dBaseType OBJECT-TYPE SYNTAX INTEGER { unknown(1), transparent-only(2), sourceroute-only(3), srt(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates what type of bridging this bridge can perform. If a bridge is actually performing a certain type of bridging, this will be indicated by entries in the port table for the given type." ::= { dot1dBase 3 } -- ---------------------------------------------------------- -- -- The Generic Bridge Port Table -- ---------------------------------------------------------- -- dot1dBasePortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dBasePortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains generic information about every port that is associated with this bridge. Transparent, source-route, and srt ports are included." ::= { dot1dBase 4 } Norseth & Bell, Eds. Standards Track [Page 12] RFC 4188 Bridge MIB September 2005 dot1dBasePortEntry OBJECT-TYPE SYNTAX Dot1dBasePortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information for each port of the bridge." REFERENCE "IEEE 802.1D-1998: clause 14.4.2, 14.6.1" INDEX { dot1dBasePort } ::= { dot1dBasePortTable 1 } Dot1dBasePortEntry ::= SEQUENCE { dot1dBasePort Integer32, dot1dBasePortIfIndex InterfaceIndex, dot1dBasePortCircuit OBJECT IDENTIFIER, dot1dBasePortDelayExceededDiscards Counter32, dot1dBasePortMtuExceededDiscards Counter32 } dot1dBasePort OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The port number of the port for which this entry contains bridge management information." ::= { dot1dBasePortEntry 1 } dot1dBasePortIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the instance of the ifIndex object, defined in IF-MIB, for the interface corresponding to this port." ::= { dot1dBasePortEntry 2 } dot1dBasePortCircuit OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only Norseth & Bell, Eds. Standards Track [Page 13] RFC 4188 Bridge MIB September 2005 STATUS current DESCRIPTION "For a port that (potentially) has the same value of dot1dBasePortIfIndex as another port on the same bridge. This object contains the name of an object instance unique to this port. For example, in the case where multiple ports correspond one-to-one with multiple X.25 virtual circuits, this value might identify an (e.g., the first) object instance associated with the X.25 virtual circuit corresponding to this port. For a port which has a unique value of dot1dBasePortIfIndex, this object can have the value { 0 0 }." ::= { dot1dBasePortEntry 3 } dot1dBasePortDelayExceededDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames discarded by this port due to excessive transit delay through the bridge. It is incremented by both transparent and source route bridges." REFERENCE "IEEE 802.1D-1998: clause 14.6.1.1.3" ::= { dot1dBasePortEntry 4 } dot1dBasePortMtuExceededDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames discarded by this port due to an excessive size. It is incremented by both transparent and source route bridges." REFERENCE "IEEE 802.1D-1998: clause 14.6.1.1.3" ::= { dot1dBasePortEntry 5 } -- ---------------------------------------------------------- -- -- the dot1dStp subtree -- ---------------------------------------------------------- -- -- Implementation of the dot1dStp subtree is optional. It is -- implemented by those bridges that support the Spanning Tree -- Protocol. -- ---------------------------------------------------------- -- Norseth & Bell, Eds. Standards Track [Page 14] RFC 4188 Bridge MIB September 2005 dot1dStpProtocolSpecification OBJECT-TYPE SYNTAX INTEGER { unknown(1), decLb100(2), ieee8021d(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of what version of the Spanning Tree Protocol is being run. The value 'decLb100(2)' indicates the DEC LANbridge 100 Spanning Tree protocol. IEEE 802.1D implementations will return 'ieee8021d(3)'. If future versions of the IEEE Spanning Tree Protocol that are incompatible with the current version are released a new value will be defined." ::= { dot1dStp 1 } dot1dStpPriority OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of the write-able portion of the Bridge ID (i.e., the first two octets of the (8 octet long) Bridge ID). The other (last) 6 octets of the Bridge ID are given by the value of dot1dBaseBridgeAddress. On bridges supporting IEEE 802.1t or IEEE 802.1w, permissible values are 0-61440, in steps of 4096." REFERENCE "IEEE 802.1D-1998 clause 8.10.2, Table 8-4, IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3." ::= { dot1dStp 2 } dot1dStpTimeSinceTopologyChange OBJECT-TYPE SYNTAX TimeTicks UNITS "centi-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the last time a topology change was detected by the bridge entity. For RSTP, this reports the time since the tcWhile timer for any port on this Bridge was nonzero." REFERENCE "IEEE 802.1D-1998 clause 14.8.1.1., IEEE 802.1w clause 14.8.1.1." Norseth & Bell, Eds. Standards Track [Page 15] RFC 4188 Bridge MIB September 2005 ::= { dot1dStp 3 } dot1dStpTopChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of topology changes detected by this bridge since the management entity was last reset or initialized." REFERENCE "IEEE 802.1D-1998 clause 14.8.1.1." ::= { dot1dStp 4 } dot1dStpDesignatedRoot OBJECT-TYPE SYNTAX BridgeId MAX-ACCESS read-only STATUS current DESCRIPTION "The bridge identifier of the root of the spanning tree, as determined by the Spanning Tree Protocol, as executed by this node. This value is used as the Root Identifier parameter in all Configuration Bridge PDUs originated by this node." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.1" ::= { dot1dStp 5 } dot1dStpRootCost OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The cost of the path to the root as seen from this bridge." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.2" ::= { dot1dStp 6 } dot1dStpRootPort OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The port number of the port that offers the lowest cost path from this bridge to the root bridge." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.3" Norseth & Bell, Eds. Standards Track [Page 16] RFC 4188 Bridge MIB September 2005 ::= { dot1dStp 7 } dot1dStpMaxAge OBJECT-TYPE SYNTAX Timeout UNITS "centi-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum age of Spanning Tree Protocol information learned from the network on any port before it is discarded, in units of hundredths of a second. This is the actual value that this bridge is currently using." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.4" ::= { dot1dStp 8 } dot1dStpHelloTime OBJECT-TYPE SYNTAX Timeout UNITS "centi-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time between the transmission of Configuration bridge PDUs by this node on any port when it is the root of the spanning tree, or trying to become so, in units of hundredths of a second. This is the actual value that this bridge is currently using." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.5" ::= { dot1dStp 9 } dot1dStpHoldTime OBJECT-TYPE SYNTAX Integer32 UNITS "centi-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This time value determines the interval length during which no more than two Configuration bridge PDUs shall be transmitted by this node, in units of hundredths of a second." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.14" ::= { dot1dStp 10 } dot1dStpForwardDelay OBJECT-TYPE SYNTAX Timeout UNITS "centi-seconds" Norseth & Bell, Eds. Standards Track [Page 17] RFC 4188 Bridge MIB September 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "This time value, measured in units of hundredths of a second, controls how fast a port changes its spanning state when moving towards the Forwarding state. The value determines how long the port stays in each of the Listening and Learning states, which precede the Forwarding state. This value is also used when a topology change has been detected and is underway, to age all dynamic entries in the Forwarding Database. [Note that this value is the one that this bridge is currently using, in contrast to dot1dStpBridgeForwardDelay, which is the value that this bridge and all others would start using if/when this bridge were to become the root.]" REFERENCE "IEEE 802.1D-1998: clause 8.5.3.6" ::= { dot1dStp 11 } dot1dStpBridgeMaxAge OBJECT-TYPE SYNTAX Timeout (600..4000) UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value that all bridges use for MaxAge when this bridge is acting as the root. Note that 802.1D-1998 specifies that the range for this parameter is related to the value of dot1dStpBridgeHelloTime. The granularity of this timer is specified by 802.1D-1998 to be 1 second. An agent may return a badValue error if a set is attempted to a value that is not a whole number of seconds." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.8" ::= { dot1dStp 12 } dot1dStpBridgeHelloTime OBJECT-TYPE SYNTAX Timeout (100..1000) UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value that all bridges use for HelloTime when this bridge is acting as the root. The granularity of this timer is specified by 802.1D-1998 to be 1 second. An agent may return a badValue error if a set is attempted Norseth & Bell, Eds. Standards Track [Page 18] RFC 4188 Bridge MIB September 2005 to a value that is not a whole number of seconds." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.9" ::= { dot1dStp 13 } dot1dStpBridgeForwardDelay OBJECT-TYPE SYNTAX Timeout (400..3000) UNITS "centi-seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value that all bridges use for ForwardDelay when this bridge is acting as the root. Note that 802.1D-1998 specifies that the range for this parameter is related to the value of dot1dStpBridgeMaxAge. The granularity of this timer is specified by 802.1D-1998 to be 1 second. An agent may return a badValue error if a set is attempted to a value that is not a whole number of seconds." REFERENCE "IEEE 802.1D-1998: clause 8.5.3.10" ::= { dot1dStp 14 } -- ---------------------------------------------------------- -- -- The Spanning Tree Port Table -- ---------------------------------------------------------- -- dot1dStpPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dStpPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains port-specific information for the Spanning Tree Protocol." ::= { dot1dStp 15 } dot1dStpPortEntry OBJECT-TYPE SYNTAX Dot1dStpPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information maintained by every port about the Spanning Tree Protocol state for that port." INDEX { dot1dStpPort } ::= { dot1dStpPortTable 1 } Dot1dStpPortEntry ::= SEQUENCE { Norseth & Bell, Eds. Standards Track [Page 19] RFC 4188 Bridge MIB September 2005 dot1dStpPort Integer32, dot1dStpPortPriority Integer32, dot1dStpPortState INTEGER, dot1dStpPortEnable INTEGER, dot1dStpPortPathCost Integer32, dot1dStpPortDesignatedRoot BridgeId, dot1dStpPortDesignatedCost Integer32, dot1dStpPortDesignatedBridge BridgeId, dot1dStpPortDesignatedPort OCTET STRING, dot1dStpPortForwardTransitions Counter32, dot1dStpPortPathCost32 Integer32 } dot1dStpPort OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The port number of the port for which this entry contains Spanning Tree Protocol management information." REFERENCE "IEEE 802.1D-1998: clause 14.8.2.1.2" ::= { dot1dStpPortEntry 1 } dot1dStpPortPriority OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of the priority field that is contained in the first (in network byte order) octet of the (2 octet long) Port ID. The other octet of the Port ID is given by the value of dot1dStpPort. On bridges supporting IEEE 802.1t or IEEE 802.1w, permissible values are 0-240, in steps of 16." REFERENCE "IEEE 802.1D-1998 clause 8.10.2, Table 8-4, Norseth & Bell, Eds. Standards Track [Page 20] RFC 4188 Bridge MIB September 2005 IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3." ::= { dot1dStpPortEntry 2 } dot1dStpPortState OBJECT-TYPE SYNTAX INTEGER { disabled(1), blocking(2), listening(3), learning(4), forwarding(5), broken(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port's current state, as defined by application of the Spanning Tree Protocol. This state controls what action a port takes on reception of a frame. If the bridge has detected a port that is malfunctioning, it will place that port into the broken(6) state. For ports that are disabled (see dot1dStpPortEnable), this object will have a value of disabled(1)." REFERENCE "IEEE 802.1D-1998: clause 8.5.5.2" ::= { dot1dStpPortEntry 3 } dot1dStpPortEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The enabled/disabled status of the port." REFERENCE "IEEE 802.1D-1998: clause 8.5.5.2" ::= { dot1dStpPortEntry 4 } dot1dStpPortPathCost OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The contribution of this port to the path cost of paths towards the spanning tree root which include this port. 802.1D-1998 recommends that the default value of this parameter be in inverse proportion to Norseth & Bell, Eds. Standards Track [Page 21] RFC 4188 Bridge MIB September 2005 the speed of the attached LAN. New implementations should support dot1dStpPortPathCost32. If the port path costs exceeds the maximum value of this object then this object should report the maximum value, namely 65535. Applications should try to read the dot1dStpPortPathCost32 object if this object reports the maximum value." REFERENCE "IEEE 802.1D-1998: clause 8.5.5.3" ::= { dot1dStpPortEntry 5 } dot1dStpPortDesignatedRoot OBJECT-TYPE SYNTAX BridgeId MAX-ACCESS read-only STATUS current DESCRIPTION "The unique Bridge Identifier of the Bridge recorded as the Root in the Configuration BPDUs transmitted by the Designated Bridge for the segment to which the port is attached." REFERENCE "IEEE 802.1D-1998: clause 8.5.5.4" ::= { dot1dStpPortEntry 6 } dot1dStpPortDesignatedCost OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The path cost of the Designated Port of the segment connected to this port. This value is compared to the Root Path Cost field in received bridge PDUs." REFERENCE "IEEE 802.1D-1998: clause 8.5.5.5" ::= { dot1dStpPortEntry 7 } dot1dStpPortDesignatedBridge OBJECT-TYPE SYNTAX BridgeId MAX-ACCESS read-only STATUS current DESCRIPTION "The Bridge Identifier of the bridge that this port considers to be the Designated Bridge for this port's segment." REFERENCE "IEEE 802.1D-1998: clause 8.5.5.6" ::= { dot1dStpPortEntry 8 } Norseth & Bell, Eds. Standards Track [Page 22] RFC 4188 Bridge MIB September 2005 dot1dStpPortDesignatedPort OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Port Identifier of the port on the Designated Bridge for this port's segment." REFERENCE "IEEE 802.1D-1998: clause 8.5.5.7" ::= { dot1dStpPortEntry 9 } dot1dStpPortForwardTransitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this port has transitioned from the Learning state to the Forwarding state." ::= { dot1dStpPortEntry 10 } dot1dStpPortPathCost32 OBJECT-TYPE SYNTAX Integer32 (1..200000000) MAX-ACCESS read-write STATUS current DESCRIPTION "The contribution of this port to the path cost of paths towards the spanning tree root which include this port. 802.1D-1998 recommends that the default value of this parameter be in inverse proportion to the speed of the attached LAN. This object replaces dot1dStpPortPathCost to support IEEE 802.1t." REFERENCE "IEEE 802.1t clause 8.10.2, Table 8-5." ::= { dot1dStpPortEntry 11 } -- ---------------------------------------------------------- -- -- the dot1dTp subtree -- ---------------------------------------------------------- -- -- Implementation of the dot1dTp subtree is optional. It is -- implemented by those bridges that support the transparent -- bridging mode. A transparent or SRT bridge will implement -- this subtree. -- ---------------------------------------------------------- -- dot1dTpLearnedEntryDiscards OBJECT-TYPE SYNTAX Counter32 Norseth & Bell, Eds. Standards Track [Page 23] RFC 4188 Bridge MIB September 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Forwarding Database entries that have been or would have been learned, but have been discarded due to a lack of storage space in the Forwarding Database. If this counter is increasing, it indicates that the Forwarding Database is regularly becoming full (a condition that has unpleasant performance effects on the subnetwork). If this counter has a significant value but is not presently increasing, it indicates that the problem has been occurring but is not persistent." REFERENCE "IEEE 802.1D-1998: clause 14.7.1.1.3" ::= { dot1dTp 1 } dot1dTpAgingTime OBJECT-TYPE SYNTAX Integer32 (10..1000000) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The timeout period in seconds for aging out dynamically-learned forwarding information. 802.1D-1998 recommends a default of 300 seconds." REFERENCE "IEEE 802.1D-1998: clause 14.7.1.1.3" ::= { dot1dTp 2 } -- ---------------------------------------------------------- -- -- The Forwarding Database for Transparent Bridges -- ---------------------------------------------------------- -- dot1dTpFdbTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dTpFdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains information about unicast entries for which the bridge has forwarding and/or filtering information. This information is used by the transparent bridging function in determining how to propagate a received frame." ::= { dot1dTp 3 } dot1dTpFdbEntry OBJECT-TYPE Norseth & Bell, Eds. Standards Track [Page 24] RFC 4188 Bridge MIB September 2005 SYNTAX Dot1dTpFdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a specific unicast MAC address for which the bridge has some forwarding and/or filtering information." INDEX { dot1dTpFdbAddress } ::= { dot1dTpFdbTable 1 } Dot1dTpFdbEntry ::= SEQUENCE { dot1dTpFdbAddress MacAddress, dot1dTpFdbPort Integer32, dot1dTpFdbStatus INTEGER } dot1dTpFdbAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A unicast MAC address for which the bridge has forwarding and/or filtering information." REFERENCE "IEEE 802.1D-1998: clause 7.9.1, 7.9.2" ::= { dot1dTpFdbEntry 1 } dot1dTpFdbPort OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Either the value '0', or the port number of the port on which a frame having a source address equal to the value of the corresponding instance of dot1dTpFdbAddress has been seen. A value of '0' indicates that the port number has not been learned, but that the bridge does have some forwarding/filtering information about this address (e.g., in the dot1dStaticTable). Implementors are encouraged to assign the port value to this object whenever it is learned, even for addresses for which the corresponding value of dot1dTpFdbStatus is not learned(3)." ::= { dot1dTpFdbEntry 2 } Norseth & Bell, Eds. Standards Track [Page 25] RFC 4188 Bridge MIB September 2005 dot1dTpFdbStatus OBJECT-TYPE SYNTAX INTEGER { other(1), invalid(2), learned(3), self(4), mgmt(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The status of this entry. The meanings of the values are: other(1) - none of the following. This would include the case where some other MIB object (not the corresponding instance of dot1dTpFdbPort, nor an entry in the dot1dStaticTable) is being used to determine if and how frames addressed to the value of the corresponding instance of dot1dTpFdbAddress are being forwarded. invalid(2) - this entry is no longer valid (e.g., it was learned but has since aged out), but has not yet been flushed from the table. learned(3) - the value of the corresponding instance of dot1dTpFdbPort was learned, and is being used. self(4) - the value of the corresponding instance of dot1dTpFdbAddress represents one of the bridge's addresses. The corresponding instance of dot1dTpFdbPort indicates which of the bridge's ports has this address. mgmt(5) - the value of the corresponding instance of dot1dTpFdbAddress is also the value of an existing instance of dot1dStaticAddress." ::= { dot1dTpFdbEntry 3 } -- ---------------------------------------------------------- -- -- Port Table for Transparent Bridges -- ---------------------------------------------------------- -- dot1dTpPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dTpPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains information about every port that is associated with this transparent bridge." Norseth & Bell, Eds. Standards Track [Page 26] RFC 4188 Bridge MIB September 2005 ::= { dot1dTp 4 } dot1dTpPortEntry OBJECT-TYPE SYNTAX Dot1dTpPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information for each port of a transparent bridge." INDEX { dot1dTpPort } ::= { dot1dTpPortTable 1 } Dot1dTpPortEntry ::= SEQUENCE { dot1dTpPort Integer32, dot1dTpPortMaxInfo Integer32, dot1dTpPortInFrames Counter32, dot1dTpPortOutFrames Counter32, dot1dTpPortInDiscards Counter32 } dot1dTpPort OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The port number of the port for which this entry contains Transparent bridging management information." ::= { dot1dTpPortEntry 1 } -- It would be nice if we could use ifMtu as the size of the -- largest INFO field, but we can't because ifMtu is defined -- to be the size that the (inter-)network layer can use, which -- can differ from the MAC layer (especially if several layers -- of encapsulation are used). dot1dTpPortMaxInfo OBJECT-TYPE SYNTAX Integer32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum size of the INFO (non-MAC) field that Norseth & Bell, Eds. Standards Track [Page 27] RFC 4188 Bridge MIB September 2005 this port will receive or transmit." ::= { dot1dTpPortEntry 2 } dot1dTpPortInFrames OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been received by this port from its segment. Note that a frame received on the interface corresponding to this port is only counted by this object if and only if it is for a protocol being processed by the local bridging function, including bridge management frames." REFERENCE "IEEE 802.1D-1998: clause 14.6.1.1.3" ::= { dot1dTpPortEntry 3 } dot1dTpPortOutFrames OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been transmitted by this port to its segment. Note that a frame transmitted on the interface corresponding to this port is only counted by this object if and only if it is for a protocol being processed by the local bridging function, including bridge management frames." REFERENCE "IEEE 802.1D-1998: clause 14.6.1.1.3" ::= { dot1dTpPortEntry 4 } dot1dTpPortInDiscards OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of received valid frames that were discarded (i.e., filtered) by the Forwarding Process." REFERENCE "IEEE 802.1D-1998: clause 14.6.1.1.3" ::= { dot1dTpPortEntry 5 } -- ---------------------------------------------------------- -- Norseth & Bell, Eds. Standards Track [Page 28] RFC 4188 Bridge MIB September 2005 -- The Static (Destination-Address Filtering) Database -- ---------------------------------------------------------- -- -- Implementation of this subtree is optional. -- ---------------------------------------------------------- -- dot1dStaticTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing filtering information configured into the bridge by (local or network) management specifying the set of ports to which frames received from specific ports and containing specific destination addresses are allowed to be forwarded. The value of zero in this table, as the port number from which frames with a specific destination address are received, is used to specify all ports for which there is no specific entry in this table for that particular destination address. Entries are valid for unicast and for group/broadcast addresses." REFERENCE "IEEE 802.1D-1998: clause 14.7.2" ::= { dot1dStatic 1 } dot1dStaticEntry OBJECT-TYPE SYNTAX Dot1dStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Filtering information configured into the bridge by (local or network) management specifying the set of ports to which frames received from a specific port and containing a specific destination address are allowed to be forwarded." REFERENCE "IEEE 802.1D-1998: clause 14.7.2" INDEX { dot1dStaticAddress, dot1dStaticReceivePort } ::= { dot1dStaticTable 1 } Dot1dStaticEntry ::= SEQUENCE { dot1dStaticAddress MacAddress, dot1dStaticReceivePort Integer32, dot1dStaticAllowedToGoTo OCTET STRING, dot1dStaticStatus INTEGER } Norseth & Bell, Eds. Standards Track [Page 29] RFC 4188 Bridge MIB September 2005 dot1dStaticAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The destination MAC address in a frame to which this entry's filtering information applies. This object can take the value of a unicast address, a group address, or the broadcast address." REFERENCE "IEEE 802.1D-1998: clause 7.9.1, 7.9.2" ::= { dot1dStaticEntry 1 } dot1dStaticReceivePort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Either the value '0', or the port number of the port from which a frame must be received in order for this entry's filtering information to apply. A value of zero indicates that this entry applies on all ports of the bridge for which there is no other applicable entry." ::= { dot1dStaticEntry 2 } dot1dStaticAllowedToGoTo OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..512)) MAX-ACCESS read-create STATUS current DESCRIPTION "The set of ports to which frames received from a specific port and destined for a specific MAC address, are allowed to be forwarded. Each octet within the value of this object specifies a set of eight ports, with the first octet specifying ports 1 through 8, the second octet specifying ports 9 through 16, etc. Within each octet, the most significant bit represents the lowest numbered port, and the least significant bit represents the highest numbered port. Thus, each port of the bridge is represented by a single bit within the value of this object. If that bit has a value of '1', then that port is included in the set of ports; the port is not included if its bit has a value of '0'. (Note that the setting of the bit corresponding to the port from which a frame is received is irrelevant.) The default value of this object is a string of ones of appropriate length. Norseth & Bell, Eds. Standards Track [Page 30] RFC 4188 Bridge MIB September 2005 The value of this object may exceed the required minimum maximum message size of some SNMP transport (484 bytes, in the case of SNMP over UDP, see RFC 3417, section 3.2). SNMP engines on bridges supporting a large number of ports must support appropriate maximum message sizes." ::= { dot1dStaticEntry 3 } dot1dStaticStatus OBJECT-TYPE SYNTAX INTEGER { other(1), invalid(2), permanent(3), deleteOnReset(4), deleteOnTimeout(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the status of this entry. The default value is permanent(3). other(1) - this entry is currently in use but the conditions under which it will remain so are different from each of the following values. invalid(2) - writing this value to the object removes the corresponding entry. permanent(3) - this entry is currently in use and will remain so after the next reset of the bridge. deleteOnReset(4) - this entry is currently in use and will remain so until the next reset of the bridge. deleteOnTimeout(5) - this entry is currently in use and will remain so until it is aged out." ::= { dot1dStaticEntry 4 } -- ---------------------------------------------------------- -- -- Notifications for use by Bridges -- ---------------------------------------------------------- -- -- Notifications for the Spanning Tree Protocol -- ---------------------------------------------------------- -- newRoot NOTIFICATION-TYPE -- OBJECTS { } STATUS current DESCRIPTION "The newRoot trap indicates that the sending agent has become the new root of the Spanning Tree; the trap is sent by a bridge soon after its election as the new Norseth & Bell, Eds. Standards Track [Page 31] RFC 4188 Bridge MIB September 2005 root, e.g., upon expiration of the Topology Change Timer, immediately subsequent to its election. Implementation of this trap is optional." ::= { dot1dNotifications 1 } topologyChange NOTIFICATION-TYPE -- OBJECTS { } STATUS current DESCRIPTION "A topologyChange trap is sent by a bridge when any of its configured ports transitions from the Learning state to the Forwarding state, or from the Forwarding state to the Blocking state. The trap is not sent if a newRoot trap is sent for the same transition. Implementation of this trap is optional." ::= { dot1dNotifications 2 } -- ---------------------------------------------------------- -- -- IEEE 802.1D MIB - Conformance Information -- ---------------------------------------------------------- -- dot1dGroups OBJECT IDENTIFIER ::= { dot1dConformance 1 } dot1dCompliances OBJECT IDENTIFIER ::= { dot1dConformance 2 } -- ---------------------------------------------------------- -- -- units of conformance -- ---------------------------------------------------------- -- -- ---------------------------------------------------------- -- -- the dot1dBase group -- ---------------------------------------------------------- -- dot1dBaseBridgeGroup OBJECT-GROUP OBJECTS { dot1dBaseBridgeAddress, dot1dBaseNumPorts, dot1dBaseType } STATUS current DESCRIPTION "Bridge level information for this device." ::= { dot1dGroups 1 } dot1dBasePortGroup OBJECT-GROUP OBJECTS { dot1dBasePort, dot1dBasePortIfIndex, dot1dBasePortCircuit, Norseth & Bell, Eds. Standards Track [Page 32] RFC 4188 Bridge MIB September 2005 dot1dBasePortDelayExceededDiscards, dot1dBasePortMtuExceededDiscards } STATUS current DESCRIPTION "Information for each port on this device." ::= { dot1dGroups 2 } -- ---------------------------------------------------------- -- -- the dot1dStp group -- ---------------------------------------------------------- -- dot1dStpBridgeGroup OBJECT-GROUP OBJECTS { dot1dStpProtocolSpecification, dot1dStpPriority, dot1dStpTimeSinceTopologyChange, dot1dStpTopChanges, dot1dStpDesignatedRoot, dot1dStpRootCost, dot1dStpRootPort, dot1dStpMaxAge, dot1dStpHelloTime, dot1dStpHoldTime, dot1dStpForwardDelay, dot1dStpBridgeMaxAge, dot1dStpBridgeHelloTime, dot1dStpBridgeForwardDelay } STATUS current DESCRIPTION "Bridge level Spanning Tree data for this device." ::= { dot1dGroups 3 } dot1dStpPortGroup OBJECT-GROUP OBJECTS { dot1dStpPort, dot1dStpPortPriority, dot1dStpPortState, dot1dStpPortEnable, dot1dStpPortPathCost, dot1dStpPortDesignatedRoot, dot1dStpPortDesignatedCost, dot1dStpPortDesignatedBridge, dot1dStpPortDesignatedPort, dot1dStpPortForwardTransitions } STATUS current Norseth & Bell, Eds. Standards Track [Page 33] RFC 4188 Bridge MIB September 2005 DESCRIPTION "Spanning Tree data for each port on this device." ::= { dot1dGroups 4 } dot1dStpPortGroup2 OBJECT-GROUP OBJECTS { dot1dStpPort, dot1dStpPortPriority, dot1dStpPortState, dot1dStpPortEnable, dot1dStpPortDesignatedRoot, dot1dStpPortDesignatedCost, dot1dStpPortDesignatedBridge, dot1dStpPortDesignatedPort, dot1dStpPortForwardTransitions, dot1dStpPortPathCost32 } STATUS current DESCRIPTION "Spanning Tree data for each port on this device." ::= { dot1dGroups 5 } dot1dStpPortGroup3 OBJECT-GROUP OBJECTS { dot1dStpPortPathCost32 } STATUS current DESCRIPTION "Spanning Tree data for devices supporting 32-bit path costs." ::= { dot1dGroups 6 } -- ---------------------------------------------------------- -- -- the dot1dTp group -- ---------------------------------------------------------- -- dot1dTpBridgeGroup OBJECT-GROUP OBJECTS { dot1dTpLearnedEntryDiscards, dot1dTpAgingTime } STATUS current DESCRIPTION "Bridge level Transparent Bridging data." ::= { dot1dGroups 7 } dot1dTpFdbGroup OBJECT-GROUP OBJECTS { Norseth & Bell, Eds. Standards Track [Page 34] RFC 4188 Bridge MIB September 2005 dot1dTpFdbAddress, dot1dTpFdbPort, dot1dTpFdbStatus } STATUS current DESCRIPTION "Filtering Database information for the Bridge." ::= { dot1dGroups 8 } dot1dTpGroup OBJECT-GROUP OBJECTS { dot1dTpPort, dot1dTpPortMaxInfo, dot1dTpPortInFrames, dot1dTpPortOutFrames, dot1dTpPortInDiscards } STATUS current DESCRIPTION "Dynamic Filtering Database information for each port of the Bridge." ::= { dot1dGroups 9 } -- ---------------------------------------------------------- -- -- The Static (Destination-Address Filtering) Database -- ---------------------------------------------------------- -- dot1dStaticGroup OBJECT-GROUP OBJECTS { dot1dStaticAddress, dot1dStaticReceivePort, dot1dStaticAllowedToGoTo, dot1dStaticStatus } STATUS current DESCRIPTION "Static Filtering Database information for each port of the Bridge." ::= { dot1dGroups 10 } -- ---------------------------------------------------------- -- -- The Trap Notification Group -- ---------------------------------------------------------- -- dot1dNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { newRoot, Norseth & Bell, Eds. Standards Track [Page 35] RFC 4188 Bridge MIB September 2005 topologyChange } STATUS current DESCRIPTION "Group of objects describing notifications (traps)." ::= { dot1dGroups 11 } -- ---------------------------------------------------------- -- -- compliance statements -- ---------------------------------------------------------- -- bridgeCompliance1493 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for device support of bridging services, as per RFC1493." MODULE MANDATORY-GROUPS { dot1dBaseBridgeGroup, dot1dBasePortGroup } GROUP dot1dStpBridgeGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the Spanning Tree Protocol." GROUP dot1dStpPortGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the Spanning Tree Protocol." GROUP dot1dTpBridgeGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the transparent bridging mode. A transparent or SRT bridge will implement this group." GROUP dot1dTpFdbGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the transparent bridging mode. A transparent or SRT bridge will implement this group." GROUP dot1dTpGroup DESCRIPTION "Implementation of this group is mandatory for bridges Norseth & Bell, Eds. Standards Track [Page 36] RFC 4188 Bridge MIB September 2005 that support the transparent bridging mode. A transparent or SRT bridge will implement this group." GROUP dot1dStaticGroup DESCRIPTION "Implementation of this group is optional." GROUP dot1dNotificationGroup DESCRIPTION "Implementation of this group is optional." ::= { dot1dCompliances 1 } bridgeCompliance4188 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for device support of bridging services. This supports 32-bit Path Cost values and the more restricted bridge and port priorities, as per IEEE 802.1t. Full support for the 802.1D management objects requires that the SNMPv2-MIB [RFC3418] objects sysDescr, and sysUpTime, as well as the IF-MIB [RFC2863] objects ifIndex, ifType, ifDescr, ifPhysAddress, and ifLastChange are implemented." MODULE MANDATORY-GROUPS { dot1dBaseBridgeGroup, dot1dBasePortGroup } GROUP dot1dStpBridgeGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the Spanning Tree Protocol." OBJECT dot1dStpPriority SYNTAX Integer32 (0|4096|8192|12288|16384|20480|24576 |28672|32768|36864|40960|45056|49152 |53248|57344|61440) DESCRIPTION "The possible values defined by IEEE 802.1t." GROUP dot1dStpPortGroup2 DESCRIPTION "Implementation of this group is mandatory for bridges that support the Spanning Tree Protocol." Norseth & Bell, Eds. Standards Track [Page 37] RFC 4188 Bridge MIB September 2005 GROUP dot1dStpPortGroup3 DESCRIPTION "Implementation of this group is mandatory for bridges that support the Spanning Tree Protocol and 32-bit path costs. In particular, this includes devices supporting IEEE 802.1t and IEEE 802.1w." OBJECT dot1dStpPortPriority SYNTAX Integer32 (0|16|32|48|64|80|96|112|128 |144|160|176|192|208|224|240) DESCRIPTION "The possible values defined by IEEE 802.1t." GROUP dot1dTpBridgeGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the transparent bridging mode. A transparent or SRT bridge will implement this group." GROUP dot1dTpFdbGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the transparent bridging mode. A transparent or SRT bridge will implement this group." GROUP dot1dTpGroup DESCRIPTION "Implementation of this group is mandatory for bridges that support the transparent bridging mode. A transparent or SRT bridge will implement this group." GROUP dot1dStaticGroup DESCRIPTION "Implementation of this group is optional." GROUP dot1dNotificationGroup DESCRIPTION "Implementation of this group is optional." ::= { dot1dCompliances 2 } END Norseth & Bell, Eds. Standards Track [Page 38] RFC 4188 Bridge MIB September 2005 5. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values that are recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- dot1dBridge { mib-2 17 } 6. Security Considerations There are a number of management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o The writable objects dot1dStpPriority, dot1dStpBridgeMaxAge, dot1dStpBridgeHelloTime, dot1dStpBridgeForwardDelay, dot1dStpPortPriority, dot1dStpPortEnable, dot1dStpPortPathCost, and dot1dStpPortPathCost32 influence the spanning tree protocol. Unauthorized write access to these objects can cause the spanning tree protocol to compute other default topologies or it can change the speed in which the spanning tree protocol reacts to failures. o The writable object dot1dTpAgingTime controls how fast dynamically-learned forwarding information is aged out. Setting this object to a large value may simplify forwarding table overflow attacks. o The writable dot1dStaticTable provides a filtering mechanism controlling to which ports frames originating from a specific source may be forwarded. Write access to this table can be used to turn provisioned filtering off or to add filters to prevent rightful use of the network. Norseth & Bell, Eds. Standards Track [Page 39] RFC 4188 Bridge MIB September 2005 o The readable objects defined in the BRIDGE-MIB module provide information about the topology of a bridged network and the attached active stations. The addresses listed in the dot1dTpFdbTable usually reveal information about the manufacturer of the MAC hardware, which can be useful information for mounting other specific attacks. o The two notifications newRoot and topologyChange are emitted during spanning tree computation and may trigger management systems to inspect the status of bridges and to recompute internal topology information. Hence, forged notifications may cause management systems to perform unnecessary computations and to generate additional SNMP traffic directed to the bridges in a network. Therefore, forged notifications may be part of a denial of service attack. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Acknowledgements The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in [RFC1493] to the SMIv2 syntax. The original authors of the SMIv1 module were E. Decker, P. Langille, A. Rijsinghani, and K. McCloghrie. Further acknowledgement is given to the members of the original Bridge Working Group in [RFC1493]. This document was produced on behalf of the Bridge MIB Working Group in the Operations and Management area of the Internet Engineering Task Force. The editors wish to thank the members of the Bridge MIB Working Group, especially Mike MacFadden, John Flick, and Bert Visscher for their many comments and suggestions that improved this Norseth & Bell, Eds. Standards Track [Page 40] RFC 4188 Bridge MIB September 2005 effort. Juergen Schoenwaelder helped in finalizing the document for publication. 8. Contact Information The original version of this document was the result of significant work by four major contributors: E. Decker P. Langille A. Rijsinghan Accton Technology Corporation 5 Mount Royal Ave Marlboro, MA 01752 USA K. McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA The conversion to the SMIv2 format is based on work done by the following two contributors: Kenyon C. Norseth L-3 Communications 640 N. 2200 West Salt Lake City, Utah 84116-0850 USA E. Bell 3Com Europe Limited 3Com Centre, Boundary Way Hemel Hempstead Herts. HP2 7YU UK Norseth & Bell, Eds. Standards Track [Page 41] RFC 4188 Bridge MIB September 2005 9. Changes from RFC 1493 The following changes have been made from RFC 1493. 1. Translated the MIB definitions to use SMIv2. This includes the introduction of conformance statements. ASN.1 type definitions have been converted into textual-conventions and several UNITS clauses were added. 2. The object dot1dStpPortPathCost32 was added to support IEEE 802.1t. 3. Permissible values for dot1dStpPriority and dot1dStpPortPriority have been clarified for bridges supporting IEEE 802.1t or IEEE 802.1w. 4. Interpretation of dot1dStpTimeSinceTopologyChange has been clarified for bridges supporting the rapid spanning tree protocol (RSTP). 5. Updated the introductory boilerplate text, the security considerations section, and the references to comply with the current IETF standards and guidelines. 6. Updated references to point to newer IEEE 802.1d documents. 7. Additions and clarifications in various description clauses. 10. References 10.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Norseth & Bell, Eds. Standards Track [Page 42] RFC 4188 Bridge MIB September 2005 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [IEEE8021D] IEEE Project 802 Local and Metropolitan Area Networks, "ANSI/IEEE Standard 802.1D-1998 MAC Bridges", March 1998. 10.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, September 1993. Authors' Addresses Kenyon C. Norseth (editor) L-3 Communications 640 N. 2200 West Salt Lake City, Utah 84116-0850 USA Phone: +1 801-594-2809 EMail: kenyon.c.norseth@L-3com.com E. Bell (editor) 3Com Europe Limited 3Com Centre, Boundary Way Hemel Hempstead Herts. HP2 7YU UK Phone: +44 1442 438025 EMail: elbell@ntlworld.com Norseth & Bell, Eds. Standards Track [Page 43] RFC 4188 Bridge MIB September 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Norseth & Bell, Eds. Standards Track [Page 44] snmp-mibs-downloader-1.1/mibrfcs/rfc4220.txt0000644000000000000000000031416611402176072015565 0ustar Network Working Group M. Dubuc Request for Comments: 4220 Consultant Category: Standards Track T. Nadeau Cisco Systems J. Lang Sonos, Inc. November 2005 Traffic Engineering Link Management Information Base 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. Dubuc, et al. Standards Track [Page 1] RFC 4220 MPLS TE Link MIB Module November 2005 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Introduction ....................................................3 3. Terminology .....................................................3 4. Feature Checklist ...............................................4 5. Outline .........................................................4 6. Brief Description of MIB Objects ................................4 6.1. teLinkTable ................................................4 6.2. teLinkDescriptorTable ......................................4 6.3. teLinkSrlgTable ............................................5 6.4. teLinkBandwidthTable .......................................5 6.5. componentLinkTable .........................................5 6.6. componentLinkDescriptorTable ...............................5 6.7. componentLinkBandwidthTable ................................5 7. Example of Bundled Link Setup ...................................5 8. Application of the Interfaces Group to TE Links .................9 8.1. Support of the TE Link Layer by ifTable ....................9 8.2. Using ifStackTable ........................................11 8.3. Applicability of ifRcvAddressTable ........................13 9. TE Link MIB Module Definitions .................................13 10. Security Considerations .......................................50 11. Contributors ..................................................51 12. Acknowledgements ..............................................51 13. IANA Considerations ...........................................51 13.1. IANA Considerations for the TE-LINK-STD-MIB .............51 14. References ....................................................51 14.1. Normative References ....................................51 14.2. Informative References ..................................52 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Dubuc, et al. Standards Track [Page 2] RFC 4220 MPLS TE Link MIB Module November 2005 2. Introduction OSPF [RFC3630], Generalized MPLS (GMPLS) [RFC3471], and the Link Management Protocol (LMP) [RFC4204] use the concept of traffic engineering (TE) links to abstract link properties. The effect of this approach is a reduction in the amount of routing information exchanged in the network, which improves routing scalability. In addition, the use of TE links allows the implementation of new capabilities such as link protection. In this document, we present a MIB module that can be used to manage TE links and their extension, the bundled link. This MIB module enables both the configuration and the performance monitoring of TE links and the bundled link. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Terminology This document uses terminology from the documents describing link bundling [RFC4201] and GMPLS [RFC3945]. The link bundling feature is designed to aggregate one or more similar entities between a node pair into a bundled link [RFC4201]. In RFC 4201, those entities are referred to as TE links. A TE link is a subinterface capable of carrying MPLS traffic engineered traffic. A TE Link may be comprised of only one underlying component link. In cases where more than one component links are to be combined, multiple component links should be created with differing priorities to indicate hot-standby or parallel utilization. A bundled link is another kind of Traffic Engineering (TE) link (see [RFC4203]). A link bundle is a subinterface that binds the traffic of a group of one or more TE links. There should be more than one TE Link in a link bundle, but this is not a requirement. Furthermore, if there are more than one TE links in a link bundle at some time, and at some point later, all but one of the links are deleted, the agent may choose to either delete the link bundle, or it may choose to leave it intact. Traffic counters on a link bundle are cumulative for all subinterfaces that it binds together. Dubuc, et al. Standards Track [Page 3] RFC 4220 MPLS TE Link MIB Module November 2005 4. Feature Checklist The TE Link MIB module (TE-LINK-STD-MIB) is designed to satisfy the following requirements and constraints: - The MIB module supports the management of TE links, including bundled links. - Support is provided for configuration of traffic engineering parameters associated with TE links. - The MIB module is used to monitor the priority-based component link and TE link bandwidth values. 5. Outline Configuring bundled links involves the following steps: - Creating a bundled link. - Creating TE links. - Optionally specifying the shared risk link groups associated with the TE links. - Configuring the component links including the bandwidth parameters and associating the component links with the appropriate TE link. - Associating the TE links with the appropriate bundled link. 6. Brief Description of MIB Objects Sections 6.1 - 6.4 describe objects pertaining to TE links while Sections 6.5 - 6.7 describe objects pertaining to component links. The MIB objects were derived from the link bundling document [RFC4201]. 6.1. teLinkTable This table represents the TE links, including bundled links, and their generic traffic engineering parameters. 6.2. teLinkDescriptorTable This table represents the TE link interface switching capability descriptors. Dubuc, et al. Standards Track [Page 4] RFC 4220 MPLS TE Link MIB Module November 2005 6.3. teLinkSrlgTable This table represents the shared risk link groups (SRLGs) associated with TE links. 6.4. teLinkBandwidthTable This table specifies the priority-based bandwidth traffic engineering parameters associated with TE links. 6.5. componentLinkTable This table enumerates the component links and their generic traffic engineering parameters. 6.6. componentLinkDescriptorTable This table enumerates the interface switching capability descriptors that each component link supports. 6.7. componentLinkBandwidthTable The component link bandwidth table specifies the priority-based bandwidth values associated with the component links. Component links that belong to the same TE link must be compatible. If these two tables are managed independently, mechanisms should be put in place to ensure consistency between the two tables. TE links that form a bundled link must have compatible traffic engineering parameters (resource class, link metric, and protection type). The link descriptors of the teLinkDescriptorTable can be derived from the link descriptors of the componentLinkDescrTable. Some of the bandwidth parameters of the teLinkTable, teLinkDescriptorTable, teLinkBandwidthTable are derived from the bandwidth parameters of the componentLinkTable, componentLinkDescriptorTable, and componentLinkBandwidthTable (maximum reservable bandwidth, minimum LSP bandwidth, maximum LSP bandwidth at specified priority, and unreserved bandwidth). 7. Example of Bundled Link Setup In this section, we provide a brief example of using the MIB objects described in section 10 to set up a bundled link. While this example is not meant to illustrate every nuance of the MIB module, it is intended as an aid to understanding some of the key concepts. It is meant to be read after going through the MIB module itself. Section Dubuc, et al. Standards Track [Page 5] RFC 4220 MPLS TE Link MIB Module November 2005 8.2 provides more details on the use of the ifStackTable to establish relationships between bundled links, TE links, and component links. Suppose that one would like to manually create a bundled link out of two 1:1 TE links, as depicted in the figure in Section 8.2. Assume that the bundled link is associated with SRLGs 10 and 50. Finally, let the component links be port entity interfaces (lambdas). The following example illustrates which rows and corresponding objects might be created to accomplish this. First, a bundled link entry is created. An ifEntry with the same ifIndex and with ifType teLink needs to be created beforehand. In teLinkTable: { ifIndex = 2, teLinkAddressType = unknown(0), teLinkLocalIpAddr = ''H, teLinkRemoteIpAddr = ''H, teLinkMetric = 5, teLinkProtectionType = dedicated1For1(4), teLinkWorkingPriority = 7, teLinkResourceClass = 3, teLinkIncomingIfId = 0, teLinkOutgoingIfId = 2, teLinkRowStatus = createAndGo(4), teLinkStorageType = nonVolatile(3) } In ifStackTable: { ifStackHigherLayer = 0, ifStackLowerLayer = 2, ifStackStatus = createAndGo(4) } Next, the two TE links are created. In teLinkTable: { ifIndex = 3, teLinkAddressType = unknown(0), teLinkLocalIpAddr = ''H, teLinkRemoteIpAddr = ''H, teLinkMetric = 5, teLinkProtectionType = unprotected(2), teLinkWorkingPriority = 7, teLinkResourceClass = 3, Dubuc, et al. Standards Track [Page 6] RFC 4220 MPLS TE Link MIB Module November 2005 teLinkIncomingIfId = 0, teLinkOutgoingIfId = 3, teLinkRowStatus = createAndGo(4), teLinkStorageType = nonVolatile(3) } In ifStackTable: { ifStackHigherLayer = 2, ifStackLowerLayer = 3, ifStackStatus = createAndGo(4) } In teLinkTable: { ifIndex = 4, teLinkAddressType = unknown(0), teLinkLocalIpAddr = ''H, teLinkRemoteIpAddr = ''H, teLinkMetric = 5, teLinkProtectionType = unprotected(2), teLinkWorkingPriority = 7, teLinkResourceClass = 3, teLinkIncomingIfId = 0, teLinkOutgoingIfId = 4, teLinkRowStatus = createAndGo(4), teLinkStorageType = nonVolatile(3) } In ifStackTable: { ifStackHigherLayer = 2, ifStackLowerLayer = 4, ifStackStatus = createAndGo(4) } We assign SRLGs to the TE links. In the teLinkSrlgTable: { ifIndex = 3, teLinkSrlg = 10, teLinkSrlgRowStatus = createAndGo(4), teLinkSrlgStorageType = nonVolatile(3) } In the teLinkSrlgTable: { Dubuc, et al. Standards Track [Page 7] RFC 4220 MPLS TE Link MIB Module November 2005 ifIndex = 4, teLinkSrlg = 50, teLinkSrlgRowStatus = createAndGo(4), teLinkSrlgStorageType = nonVolatile(3) } The bundled link inherits the SRLG properties from the associated TE links. Next, for each unbundled TE link, a component link is created. An ifEntry with the same ifIndex needs to be created beforehand. In componentLinkTable: { ifIndex = 5, componentLinkPreferredProtection = primary(1), componentLinkRowStatus = createAndGo(4), componentLinkStorageType = nonVolatile(3) } In ifStackTable: { ifStackHigherLayer = 3, ifStackLowerLayer = 5, ifStackStatus = createAndGo(4) } In componentLinkTable: { ifIndex = 6, componentLinkPreferredProtection = secondary(2), componentLinkRowStatus = createAndGo(4) componentLinkStorageType = nonVolatile(3) } In ifStackTable: { ifStackHigherLayer = 4, ifStackLowerLayer = 6, ifStackStatus = createAndGo(4) } In this example, once a component link is added to the componentLinkTable, the associated link descriptors are implicitly added to the componentLinkDescriptorTable. TE link link descriptors are derived from their component link descriptors. Dubuc, et al. Standards Track [Page 8] RFC 4220 MPLS TE Link MIB Module November 2005 Note that the bandwidth attributes in teLinkDescriptorTable, componentLinkDescriptorTable, teLinkBandwidthTable, and componentLinkBandwidthTable are maintained by the device according to LSP creation/deletion at different priorities. The values in the teLinkBandwidthTable are an aggregation of the values for the component links of the TE links and the TE links of the bundled link. 8. Application of the Interfaces Group to TE Links The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing TE Link interfaces as logical interfaces. This memo assumes the interpretation of the Interfaces Group to be in accordance with [RFC2863], which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Thus, the TE Link interface is represented as an entry in the ifTable. The interrelation of entries in the ifTable is defined by Interfaces Stack Group, as defined in [RFC2863]. When using TE Link interfaces, the interface stack table might appear as follows: +----------------------------------------+ | TE link-interface ifType = teLink(200) + +----------------------------------------+ | Underlying Layer... + +----------------------------------------+ In the above diagram, "Underlying Layer..." refers to the ifIndex of any interface type, which has been defined for TE Link interworking. Examples include ATM, Frame Relay, Ethernet, etc. 8.1. Support of the TE Link Layer by ifTable Some specific interpretations of ifTable for the TE Link layer follow. Object Use for the TE Link layer ifIndex Each TE Link interface is represented by an ifEntry. ifDescr Description of the TE Link interface. Dubuc, et al. Standards Track [Page 9] RFC 4220 MPLS TE Link MIB Module November 2005 ifType The value that is allocated for TE Link is 200 [IANAifType]. ifSpeed The total bandwidth in bits per second for use by the TE Link layer. ifPhysAddress Unused. ifAdminStatus This variable indicates the administrator's intent as to whether TE Link should be enabled, disabled, or running in some diagnostic testing mode on this interface. Also see [RFC2863]. ifOperStatus This value reflects the actual or operational status of the TE Link on this interface. ifLastChange See [RFC2863]. ifInOctets The number of received octets over the interface, i.e., the number of received octets in all component links associated with the interface. ifOutOctets The number of transmitted octets over the interface, i.e., the number of octets transmitted over all component links associated with the interface. ifInErrors The number of packets dropped due to uncorrectable errors. ifInUnknownProtos The number of received packets discarded during packet header validation. ifOutErrors See [RFC2863]. ifName Textual name (unique on this system) of the interface, or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). ifConnectorPresent Set to false (2). ifHighSpeed See [RFC2863]. Dubuc, et al. Standards Track [Page 10] RFC 4220 MPLS TE Link MIB Module November 2005 ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in [RFC2863]. ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in [RFC2863]. ifAlias The non-volatile 'alias' name for the interface, as specified by a network manager. ifCounterDiscontinuityTime See [RFC2863]. Support for ifInOctets, ifOutOctets, ifInErrors, ifInUnknownProtos, ifOutErrors, ifHCInOctets, and ifHCOutOctets objects is not required if the encoding type is clear. For other encoding types, traffic counters on a TE link are cumulative for all subinterfaces that it binds together. 8.2. Using ifStackTable This section describes, by example, how to use the ifStackTable to represent the relationship of TE links with underlying TE-enabled interfaces. Implementors of the stack table for TE link interfaces should look at the appropriate RFC for the service being stacked on TE links. The examples given below are for illustration purposes only. Example: MPLS is being carried on a bundled TE link. The bundled TE link represents a 1:1 optical transport interface. In this example, the component link is a TE link. The two component links/TE links are grouped in a bundled link. +-------------------------------------------------------------------+ | MPLS interface ifType = mpls(166) | | ifIndex = 1 | +-------------------------------------------------------------------+ | TE link (bundled link) ifType = teLink(200) | | ifIndex = 2 | +--------------------------------+-+--------------------------------+ | TE link ifType = teLink(200) | | TE link ifType = teLink(200) | | ifIndex = 3 | | ifIndex = 4 | +--------------------------------+ +--------------------------------+ | Component link | | Component link | | ifType = opticalTransport(196) | | ifType = opticalTransport(196) | | ifIndex = 5 | | ifIndex = 6 | +--------------------------------+ +--------------------------------+ Dubuc, et al. Standards Track [Page 11] RFC 4220 MPLS TE Link MIB Module November 2005 The assignment of the index values could, for example, be: ifIndex Description 1 mpls (type 166) 2 teLink (type 200) 3 teLink (type 200) 4 teLink (type 200) 5 opticalTransport (type 196) 6 opticalTransport (type 196) The ifStackTable is then used to show the relationships between the various interfaces. ifStackTable Entries HigherLayer LowerLayer 0 1 1 2 2 3 2 4 3 5 4 6 5 0 6 0 In the case where MPLS is using a single TE link, then the upper TE link layer (link bundle) is not required. +-----------------------------------+ | MPLS interface ifType = mpls(166) | +-----------------------------------+ | TE link ifType = teLink(200) | +-----------------------------------+ | Component link | | ifType = opticalTransport(196) | +-----------------------------------+ The assignment of the index values could for example be: ifIndex Description 1 mpls (type 166) 2 teLink (type 200) 3 opticalTransport (type 196) Dubuc, et al. Standards Track [Page 12] RFC 4220 MPLS TE Link MIB Module November 2005 The ifStackTable is then used to show the relationships between the various interfaces. ifStackTable Entries HigherLayer LowerLayer 0 1 1 2 2 3 3 0 8.3. Applicability of ifRcvAddressTable TE link interfaces are logical interfaces with no media-level addresses. As such, the ifRcvAddressTable is not applicable to these interfaces. 9. TE Link MIB Module Definitions TE-LINK-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Integer32, Unsigned32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, RowStatus, StorageType FROM SNMPv2-TC InterfaceIndexOrZero, ifIndex FROM IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB; teLinkStdMIB MODULE-IDENTITY LAST-UPDATED "200510110000Z" -- 11 October 2005 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Martin Dubuc Email: mdubuc@ncf.ca Thomas D. Nadeau Email: tnadeau@cisco.com Dubuc, et al. Standards Track [Page 13] RFC 4220 MPLS TE Link MIB Module November 2005 Jonathan P. Lang Email: jplang@ieee.org Comments about this document should be emailed directly to the MPLS working group mailing list at mpls@uu.net." DESCRIPTION "Copyright (C) 2005 The Internet Society. This version of this MIB module is part of RFC 4220; see the RFC itself for full legal notices. This MIB module contains managed object definitions for MPLS traffic engineering links as defined in 'Link Bundling in MPLS Traffic Engineering (TE)'." -- Revision history. REVISION "200510110000Z" -- 11 October 2005 DESCRIPTION "Initial version published as RFC 4220." ::= { transmission 200 } -- Textual Conventions TeLinkBandwidth ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to represent link bandwidth in bps. This value is represented using a 4 octet IEEE floating point format [IEEE]. The floating point representation is not used to represent fractional value but rather to allow specification of large numbers that cannot be expressed with 32-bit integers." REFERENCE "IEEE Standard for Binary Floating-Point Arithmetic, Standard 754-1985" SYNTAX OCTET STRING (SIZE(4)) TeLinkPriority ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This type is used to represent a priority. Each connection is assigned a priority. This priority is used when accounting for bandwidth on TE links or component links, for resource allocation and for rerouting purposes. Value 0 is the highest priority. Value 7 is the lowest priority." Dubuc, et al. Standards Track [Page 14] RFC 4220 MPLS TE Link MIB Module November 2005 SYNTAX Unsigned32 (0..7) TeLinkProtection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Link protection." SYNTAX INTEGER { primary(1), secondary(2) } TeLinkSwitchingCapability ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Switching capability as specified in the 'OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)' document. The values specified in this document are not contiguous." SYNTAX INTEGER { packetSwitch1(1), packetSwitch2(2), packetSwitch3(3), packetSwitch4(4), layer2Switch(51), tdm(100), lambdaSwitch(150), fiberSwitch(200) } TeLinkEncodingType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Link encoding type as specified in 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description' document. The values specified in this document are not contiguous." SYNTAX INTEGER { packet(1), ethernet(2), ansiEtsiPdh(3), sdhItuSonetAnsi(5), digitalWrapper(7), lambda(8), fiber(9), fiberChannel(11) } TeLinkSonetSdhIndication ::= TEXTUAL-CONVENTION Dubuc, et al. Standards Track [Page 15] RFC 4220 MPLS TE Link MIB Module November 2005 STATUS current DESCRIPTION "This convention is used to indicate whether the interface supports Standard or Arbitrary SONET/SDH. To simplify the mapping process, the values used in this textual convention match the values specified in the interface switching capability specific information field, i.e., 0 for Standard SONET/SDH and 1 for Arbitrary SONET/SDH." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" SYNTAX INTEGER { standard(0), arbitrary(1) } -- Top level components of this MIB module -- Notifications teLinkNotifications OBJECT IDENTIFIER ::= { teLinkStdMIB 0 } -- Tables, Scalars teLinkObjects OBJECT IDENTIFIER ::= { teLinkStdMIB 1 } -- Conformance teLinkConformance OBJECT IDENTIFIER ::= { teLinkStdMIB 2 } -- TE Link Table teLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF TeLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the grouping of component links into TE links and the grouping of TE links into bundled links." ::= { teLinkObjects 1 } teLinkEntry OBJECT-TYPE SYNTAX TeLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table exists for each ifEntry with an ifType of teLink(200), i.e., for every TE link. An ifEntry in the ifTable must exist before a teLinkEntry is created with the corresponding ifIndex. If a TE link entry in the ifTable is destroyed, then so is the corresponding entry in the teLinkTable. The administrative and operational status values are controlled from the ifEntry." Dubuc, et al. Standards Track [Page 16] RFC 4220 MPLS TE Link MIB Module November 2005 INDEX { ifIndex } ::= { teLinkTable 1 } TeLinkEntry ::= SEQUENCE { teLinkAddressType InetAddressType, teLinkLocalIpAddr InetAddress, teLinkRemoteIpAddr InetAddress, teLinkMetric Unsigned32, teLinkMaximumReservableBandwidth TeLinkBandwidth, teLinkProtectionType INTEGER, teLinkWorkingPriority TeLinkPriority, teLinkResourceClass Unsigned32, teLinkIncomingIfId Integer32, teLinkOutgoingIfId InterfaceIndexOrZero, teLinkRowStatus RowStatus, teLinkStorageType StorageType } teLinkAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address for the TE link." ::= { teLinkEntry 1 } teLinkLocalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The local Internet address for numbered links. The type of this address is determined by the value of the teLinkAddressType object. For IPv4 and IPv6 numbered links, this object represents the local IP address associated with the TE link. For an unnumbered link, the local address is of type unknown, this object is set to the zero length string, and the teLinkOutgoingIfId object then identifies the unnumbered address. If the TE link is a Forwarding Adjacency (FA), the local IP address is set to the head-end address of the FA-LSP. If ipAddrTable is implemented, this object must have the same value as the ipAdEntAddr object that belongs to the row in ipAddrTable where ipAdEntIfIndex is equal to Dubuc, et al. Standards Track [Page 17] RFC 4220 MPLS TE Link MIB Module November 2005 ifIndex." ::= { teLinkEntry 2 } teLinkRemoteIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The remote Internet address for numbered links. The type of this address is determined by the value of the teLinkAddressType object. The remote IP address associated with the TE link (IPv4 and IPv6 numbered links). For an unnumbered link, the remote address is of type unknown, this object is set to the zero length string, and the teLinkIncomingIfId object then identifies the unnumbered address. If the TE link is a Forwarding Adjacency, the remote IP address is set to the tail-end address of the FA-LSP." ::= { teLinkEntry 3 } teLinkMetric OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The traffic engineering metric for the TE link is derived from its component links. All component links within the TE link must have the same traffic engineering metric." REFERENCE "Link Bundling in MPLS Traffic Engineering (TE), RFC 4201" ::= { teLinkEntry 4 } teLinkMaximumReservableBandwidth OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute specifies the maximum reservable bandwidth on the TE link. This is the union of the maximum reservable bandwidth of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" Dubuc, et al. Standards Track [Page 18] RFC 4220 MPLS TE Link MIB Module November 2005 ::= { teLinkEntry 5 } teLinkProtectionType OBJECT-TYPE SYNTAX INTEGER { extraTraffic(1), unprotected(2), shared(3), dedicated1For1(4), dedicated1Plus1(5), enhanced(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the link protection type of the TE link. Descriptions of the different protection types can be found in the 'Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)' document." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203 and Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4202" ::= { teLinkEntry 6 } teLinkWorkingPriority OBJECT-TYPE SYNTAX TeLinkPriority MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents a priority value such that a new connection with a higher priority, i.e., numerically lower than this value, is guaranteed to be setup on a primary link and not on a secondary link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkEntry 7 } teLinkResourceClass OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the TE link resource class. The resource class is a 32 bit bitfield. The resource class for a link bundle is derived from the resource class of its Dubuc, et al. Standards Track [Page 19] RFC 4220 MPLS TE Link MIB Module November 2005 TE links. All TE links within a link bundle must have the same resource class. Encoding of the resource class is described in the 'Traffic Engineering (TE) Extensions to OSPF Version 2' document." REFERENCE "Link Bundling in MPLS Traffic Engineering (TE), RFC 4201 and Traffic Engineering (TE) Extensions to OSPF Version 2, RFC 3630" ::= { teLinkEntry 8 } teLinkIncomingIfId OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "For unnumbered links, the incoming interface is set to the outgoing interface identifier chosen by the neighboring LSR for the reverse link corresponding to this TE link. If the link is numbered, the value of this object is 0 and the address is stored in the teLinkRemoteIpAddr instead." REFERENCE "Link Bundling in MPLS Traffic Engineering (TE), RFC 4201" ::= { teLinkEntry 9 } teLinkOutgoingIfId OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "If the link is unnumbered, the outgoing interface identifier is set to the outgoing interface identifier chosen for the TE link by the advertising LSR. If the link is numbered, the value of this object is 0 and the address is stored in the teLinkLocalIpAddr instead." REFERENCE "Link Bundling in MPLS Traffic Engineering (TE), RFC 4201" ::= { teLinkEntry 10 } teLinkRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. None of the writable objects in a row can be changed if status is active(1)." ::= { teLinkEntry 11 } Dubuc, et al. Standards Track [Page 20] RFC 4220 MPLS TE Link MIB Module November 2005 teLinkStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the teLinkTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { teLinkEntry 12 } -- End of teLinkTable -- TE Link Descriptor Table teLinkDescriptorTable OBJECT-TYPE SYNTAX SEQUENCE OF TeLinkDescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the interface switching capability descriptors associated with the TE links." ::= { teLinkObjects 2 } teLinkDescriptorEntry OBJECT-TYPE SYNTAX TeLinkDescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created for every TE link interface switching capability descriptor. An ifEntry in the ifTable must exist before a teLinkDescriptorEntry using the same ifIndex is created. ifType of ifEntry must be teLink(200). If a TE link entry in the ifTable is destroyed, then so are all of the entries in the teLinkDescriptorTable that use the ifIndex of this TE link." INDEX { ifIndex, teLinkDescriptorId } ::= { teLinkDescriptorTable 1 } TeLinkDescriptorEntry ::= SEQUENCE { teLinkDescriptorId Unsigned32, teLinkDescrSwitchingCapability TeLinkSwitchingCapability, teLinkDescrEncodingType TeLinkEncodingType, teLinkDescrMinLspBandwidth TeLinkBandwidth, teLinkDescrMaxLspBandwidthPrio0 TeLinkBandwidth, teLinkDescrMaxLspBandwidthPrio1 TeLinkBandwidth, teLinkDescrMaxLspBandwidthPrio2 TeLinkBandwidth, Dubuc, et al. Standards Track [Page 21] RFC 4220 MPLS TE Link MIB Module November 2005 teLinkDescrMaxLspBandwidthPrio3 TeLinkBandwidth, teLinkDescrMaxLspBandwidthPrio4 TeLinkBandwidth, teLinkDescrMaxLspBandwidthPrio5 TeLinkBandwidth, teLinkDescrMaxLspBandwidthPrio6 TeLinkBandwidth, teLinkDescrMaxLspBandwidthPrio7 TeLinkBandwidth, teLinkDescrInterfaceMtu Unsigned32, teLinkDescrIndication TeLinkSonetSdhIndication, teLinkDescrRowStatus RowStatus, teLinkDescrStorageType StorageType } teLinkDescriptorId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the link descriptor identifier." ::= { teLinkDescriptorEntry 1 } teLinkDescrSwitchingCapability OBJECT-TYPE SYNTAX TeLinkSwitchingCapability MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies interface switching capability of the TE link, which is derived from its component links." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 2 } teLinkDescrEncodingType OBJECT-TYPE SYNTAX TeLinkEncodingType MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the TE link encoding type." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471" ::= { teLinkDescriptorEntry 3 } teLinkDescrMinLspBandwidth OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION Dubuc, et al. Standards Track [Page 22] RFC 4220 MPLS TE Link MIB Module November 2005 "This attribute specifies the minimum LSP bandwidth on the TE link. This is derived from the union of the minimum LSP bandwidth of all the component links associated with the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 4 } teLinkDescrMaxLspBandwidthPrio0 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 0 on the TE link. This is the union of the maximum LSP bandwidth at priority 0 of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 5 } teLinkDescrMaxLspBandwidthPrio1 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 1 on the TE link. This is the union of the maximum LSP bandwidth at priority 1 of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 6 } teLinkDescrMaxLspBandwidthPrio2 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 2 on the TE link. This is the union of the maximum Dubuc, et al. Standards Track [Page 23] RFC 4220 MPLS TE Link MIB Module November 2005 LSP bandwidth at priority 2 of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 7 } teLinkDescrMaxLspBandwidthPrio3 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 3 on the TE link. This is the union of the maximum LSP bandwidth at priority 3 of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 8 } teLinkDescrMaxLspBandwidthPrio4 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 4 on the TE link. This is the union of the maximum LSP bandwidth at priority 4 of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 9 } teLinkDescrMaxLspBandwidthPrio5 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 5 on the TE link. This is the union of the maximum LSP bandwidth at priority 5 of all the component links within the TE link that can be used to carry live traffic." REFERENCE Dubuc, et al. Standards Track [Page 24] RFC 4220 MPLS TE Link MIB Module November 2005 "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 10 } teLinkDescrMaxLspBandwidthPrio6 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 6 on the TE link. This is the union of the maximum LSP bandwidth at priority 6 of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 11 } teLinkDescrMaxLspBandwidthPrio7 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 7 on the TE link. This is the union of the maximum LSP bandwidth at priority 7 of all the component links within the TE link that can be used to carry live traffic." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 12 } teLinkDescrInterfaceMtu OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the interface MTU for the TE link descriptor." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 13 } teLinkDescrIndication OBJECT-TYPE SYNTAX TeLinkSonetSdhIndication Dubuc, et al. Standards Track [Page 25] RFC 4220 MPLS TE Link MIB Module November 2005 MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies whether this interface supports Standard or Arbitrary SONET/SDH." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkDescriptorEntry 14 } teLinkDescrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. No read-create object can be changed if teLinkDescrRowStatus is in the active(1) state." ::= { teLinkDescriptorEntry 15 } teLinkDescrStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the teLinkDescriptorTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { teLinkDescriptorEntry 16 } -- End of teLinkDescriptorTable -- TE Link Shared Risk Link Group Table teLinkSrlgTable OBJECT-TYPE SYNTAX SEQUENCE OF TeLinkSrlgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the SRLGs associated with TE links." ::= { teLinkObjects 3 } teLinkSrlgEntry OBJECT-TYPE SYNTAX TeLinkSrlgEntry MAX-ACCESS not-accessible Dubuc, et al. Standards Track [Page 26] RFC 4220 MPLS TE Link MIB Module November 2005 STATUS current DESCRIPTION "An entry in this table contains information about an SRLG associated with a TE link. An ifEntry in the ifTable must exist before a teLinkSrlgEntry using the same ifIndex is created. The ifType of ifEntry must be teLink(200). If a TE link entry in the ifTable is destroyed, then so are all of the entries in the teLinkSrlgTable that use the ifIndex of this TE link." INDEX { ifIndex, teLinkSrlg } ::= { teLinkSrlgTable 1 } TeLinkSrlgEntry ::= SEQUENCE { teLinkSrlg Unsigned32, teLinkSrlgRowStatus RowStatus, teLinkSrlgStorageType StorageType } teLinkSrlg OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This identifies an SRLG supported by the TE link. An SRLG is identified with a 32-bit number that is unique within an IGP domain. Zero is a valid SRLG number." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { teLinkSrlgEntry 1 } teLinkSrlgRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. No read-create object can be modified if teLinkSrlgRowStatus is active(1)." ::= { teLinkSrlgEntry 2 } teLinkSrlgStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the Dubuc, et al. Standards Track [Page 27] RFC 4220 MPLS TE Link MIB Module November 2005 teLinkSrlgTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { teLinkSrlgEntry 3 } -- End of teLinkSrlgTable -- TE Link Bandwidth Table teLinkBandwidthTable OBJECT-TYPE SYNTAX SEQUENCE OF TeLinkBandwidthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the priority-based bandwidth table for TE links." ::= { teLinkObjects 4 } teLinkBandwidthEntry OBJECT-TYPE SYNTAX TeLinkBandwidthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table contains information about the priority-based bandwidth of TE links. An ifEntry in the ifTable must exist before a teLinkBandwidthEntry using the same ifIndex is created. The ifType of ifEntry must be teLink(200). If a TE link entry in the ifTable is destroyed, then so are all of the entries in the teLinkBandwidthTable that use the ifIndex of this TE link." INDEX { ifIndex, teLinkBandwidthPriority } ::= { teLinkBandwidthTable 1 } TeLinkBandwidthEntry ::= SEQUENCE { teLinkBandwidthPriority TeLinkPriority, teLinkBandwidthUnreserved TeLinkBandwidth, teLinkBandwidthRowStatus RowStatus, teLinkBandwidthStorageType StorageType } teLinkBandwidthPriority OBJECT-TYPE SYNTAX TeLinkPriority MAX-ACCESS not-accessible STATUS current DESCRIPTION "This attribute specifies the priority. A value of 0 is valid as specified in the 'Traffic Engineering (TE) Extensions to Dubuc, et al. Standards Track [Page 28] RFC 4220 MPLS TE Link MIB Module November 2005 OSPF Version 2' document." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203 and Traffic Engineering (TE) Extensions to OSPF Version 2, RFC 3630" ::= { teLinkBandwidthEntry 1 } teLinkBandwidthUnreserved OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute specifies the TE link unreserved bandwidth at priority p. It is the sum of the unreserved bandwidths at priority p of all component links associated with the TE link (excluding all links that are strictly used as protecting links)." REFERENCE "Link Bundling in MPLS Traffic Engineering (TE), RFC 4201" ::= { teLinkBandwidthEntry 2 } teLinkBandwidthRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. No read-create object can be modified when teLinkBandwidthRowStatus is active(1)." ::= { teLinkBandwidthEntry 3 } teLinkBandwidthStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the teLinkBandwidthTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { teLinkBandwidthEntry 4 } -- End of teLinkBandwidthTable -- Component Link Table Dubuc, et al. Standards Track [Page 29] RFC 4220 MPLS TE Link MIB Module November 2005 componentLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF ComponentLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the component link parameters." ::= { teLinkObjects 5 } componentLinkEntry OBJECT-TYPE SYNTAX ComponentLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table exists for each ifEntry that represents a component link. An ifEntry must exist in the ifTable before a componentLinkEntry is created with the corresponding ifIndex. ifEntry's ifType can be of any interface type that has been defined for TE Link interworking. Examples include ATM, Frame Relay, Ethernet, etc. If an entry representing a component link is destroyed in the ifTable, then so is the corresponding entry in the componentLinkTable. The administrative and operational status values are controlled from the ifEntry." INDEX { ifIndex } ::= { componentLinkTable 1 } ComponentLinkEntry ::= SEQUENCE { componentLinkMaxResBandwidth TeLinkBandwidth, componentLinkPreferredProtection TeLinkProtection, componentLinkCurrentProtection TeLinkProtection, componentLinkRowStatus RowStatus, componentLinkStorageType StorageType } componentLinkMaxResBandwidth OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum reservable bandwidth on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkEntry 1 } componentLinkPreferredProtection OBJECT-TYPE Dubuc, et al. Standards Track [Page 30] RFC 4220 MPLS TE Link MIB Module November 2005 SYNTAX TeLinkProtection MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies whether this component link is a primary or secondary entity." ::= { componentLinkEntry 2 } componentLinkCurrentProtection OBJECT-TYPE SYNTAX TeLinkProtection MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute specifies whether this component link is currently used as primary or secondary link." ::= { componentLinkEntry 3 } componentLinkRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. No read-create object can be modified when componentLinkRowStatus is active(1)." ::= { componentLinkEntry 4 } componentLinkStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the componentLinkTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { componentLinkEntry 5 } -- End of componentLinkTable -- Component Link Descriptor Table componentLinkDescriptorTable OBJECT-TYPE SYNTAX SEQUENCE OF ComponentLinkDescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Dubuc, et al. Standards Track [Page 31] RFC 4220 MPLS TE Link MIB Module November 2005 "This table specifies the interface switching capability descriptors associated with the component links." ::= { teLinkObjects 6 } componentLinkDescriptorEntry OBJECT-TYPE SYNTAX ComponentLinkDescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created for every component link descriptor. An ifEntry in the ifTable must exist before a componentLinkDescriptorEntry using the same ifIndex is created. ifEntry's ifType can be of any interface type that has been defined for TE Link interworking. Examples include ATM, Frame Relay, Ethernet, etc. If a component link entry in the ifTable is destroyed, then so are all entries in the componentLinkDescriptorTable that use the ifIndex of this component link." INDEX { ifIndex, componentLinkDescrId } ::= { componentLinkDescriptorTable 1 } ComponentLinkDescriptorEntry ::= SEQUENCE { componentLinkDescrId Unsigned32, componentLinkDescrSwitchingCapability TeLinkSwitchingCapability, componentLinkDescrEncodingType TeLinkEncodingType, componentLinkDescrMinLspBandwidth TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio0 TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio1 TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio2 TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio3 TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio4 TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio5 TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio6 TeLinkBandwidth, componentLinkDescrMaxLspBandwidthPrio7 TeLinkBandwidth, componentLinkDescrInterfaceMtu Unsigned32, componentLinkDescrIndication TeLinkSonetSdhIndication, componentLinkDescrRowStatus RowStatus, componentLinkDescrStorageType StorageType } componentLinkDescrId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the link descriptor identifier." ::= { componentLinkDescriptorEntry 1 } Dubuc, et al. Standards Track [Page 32] RFC 4220 MPLS TE Link MIB Module November 2005 componentLinkDescrSwitchingCapability OBJECT-TYPE SYNTAX TeLinkSwitchingCapability MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies link multiplexing capabilities of the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 2 } componentLinkDescrEncodingType OBJECT-TYPE SYNTAX TeLinkEncodingType MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the component link encoding type." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471" ::= { componentLinkDescriptorEntry 3 } componentLinkDescrMinLspBandwidth OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the minimum LSP bandwidth on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 4 } componentLinkDescrMaxLspBandwidthPrio0 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 0 on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 5 } Dubuc, et al. Standards Track [Page 33] RFC 4220 MPLS TE Link MIB Module November 2005 componentLinkDescrMaxLspBandwidthPrio1 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 1 on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 6 } componentLinkDescrMaxLspBandwidthPrio2 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 2 on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 7 } componentLinkDescrMaxLspBandwidthPrio3 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 3 on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 8 } componentLinkDescrMaxLspBandwidthPrio4 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 4 on the component link." REFERENCE Dubuc, et al. Standards Track [Page 34] RFC 4220 MPLS TE Link MIB Module November 2005 "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 9 } componentLinkDescrMaxLspBandwidthPrio5 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "thousand bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 5 on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 10 } componentLinkDescrMaxLspBandwidthPrio6 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 6 on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 11 } componentLinkDescrMaxLspBandwidthPrio7 OBJECT-TYPE SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the maximum LSP bandwidth at priority 7 on the component link." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 12 } componentLinkDescrInterfaceMtu OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION Dubuc, et al. Standards Track [Page 35] RFC 4220 MPLS TE Link MIB Module November 2005 "This attribute specifies the interface MTU for the component link descriptor." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 13 } componentLinkDescrIndication OBJECT-TYPE SYNTAX TeLinkSonetSdhIndication MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies whether this interface supports Standard or Arbitrary SONET/SDH." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkDescriptorEntry 14 } componentLinkDescrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. No read-create object can be modified when componentLinkDescrRowStatus is active(1)." ::= { componentLinkDescriptorEntry 15 } componentLinkDescrStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the componentLinkDescriptorTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { componentLinkDescriptorEntry 16 } -- End of componentLinkDescriptorTable -- Component Link Bandwidth Table componentLinkBandwidthTable OBJECT-TYPE SYNTAX SEQUENCE OF ComponentLinkBandwidthEntry Dubuc, et al. Standards Track [Page 36] RFC 4220 MPLS TE Link MIB Module November 2005 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the priority-based bandwidth for component links." ::= { teLinkObjects 7 } componentLinkBandwidthEntry OBJECT-TYPE SYNTAX ComponentLinkBandwidthEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table contains information about the priority-based bandwidth on component links. An ifEntry in the ifTable must exist before a componentLinkBandwidthEntry using the same ifIndex is created. ifEntry's ifType can be of any interface type that has been defined for TE Link interworking. Examples include ATM, Frame Relay, Ethernet, etc. If a component link entry in the ifTable is destroyed, then so are all entries in the componentLinkBandwidthTable that use the ifIndex of this component link." INDEX { ifIndex, componentLinkBandwidthPriority } ::= { componentLinkBandwidthTable 1 } ComponentLinkBandwidthEntry ::= SEQUENCE { componentLinkBandwidthPriority TeLinkPriority, componentLinkBandwidthUnreserved TeLinkBandwidth, componentLinkBandwidthRowStatus RowStatus, componentLinkBandwidthStorageType StorageType } componentLinkBandwidthPriority OBJECT-TYPE SYNTAX TeLinkPriority MAX-ACCESS not-accessible STATUS current DESCRIPTION "This attribute specifies the priority. A value of 0 is valid as specified in the 'Traffic Engineering (TE) Extensions to OSPF Version 2' document." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203 and Traffic Engineering (TE) Extensions to OSPF Version 2, RFC 3630" ::= { componentLinkBandwidthEntry 1 } componentLinkBandwidthUnreserved OBJECT-TYPE Dubuc, et al. Standards Track [Page 37] RFC 4220 MPLS TE Link MIB Module November 2005 SYNTAX TeLinkBandwidth UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute specifies the component link unreserved bandwidth at priority p." REFERENCE "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4203" ::= { componentLinkBandwidthEntry 2 } componentLinkBandwidthRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. No read-create object can be modified when componentLinkBandwidthRowStatus is active(1)." ::= { componentLinkBandwidthEntry 3 } componentLinkBandwidthStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the componentLinkBandwidthTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { componentLinkBandwidthEntry 4 } -- End of componentLinkBandwidthTable -- Module compliance teLinkCompliances OBJECT IDENTIFIER ::= { teLinkConformance 1 } teLinkGroups OBJECT IDENTIFIER ::= { teLinkConformance 2 } teLinkModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Dubuc, et al. Standards Track [Page 38] RFC 4220 MPLS TE Link MIB Module November 2005 "Compliance statement for agents that support read-create so that both configuration and monitoring of TE links can be accomplished via this MIB module." MODULE -- this module MANDATORY-GROUPS { teLinkGroup, teLinkBandwidthGroup, componentLinkBandwidthGroup } GROUP teLinkSrlgGroup DESCRIPTION "This group is mandatory for GMPLS enabled devices." GROUP teLinkPscGroup DESCRIPTION "This group is mandatory for devices that support the packet switching capability." GROUP teLinkTdmGroup DESCRIPTION "This group is mandatory for devices that support the TDM switching capability." -- teLinkTable OBJECT teLinkAddressType SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "Only ipv4(1) and ipv6(2) address types need to be supported for numbered links. For unnumbered links, the unknown(0) address type needs to be supported." OBJECT teLinkLocalIpAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "Size of TE link IP address depends on type of TE link. TE link IP address size is zero if the link is unnumbered, four if the link IP address is IPv4, and sixteen if the link IP address is IPv6." OBJECT teLinkRemoteIpAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "Size of TE link IP address depends on type of TE link. TE link IP address size is zero if the link is unnumbered, four if the link IP address is IPv4, and sixteen if the link IP address is IPv6." Dubuc, et al. Standards Track [Page 39] RFC 4220 MPLS TE Link MIB Module November 2005 OBJECT teLinkRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." -- teLinkDescriptorTable OBJECT teLinkDescrRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." -- teLinkSrlgTable OBJECT teLinkSrlgRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." -- teLinkBandwidthTable OBJECT teLinkBandwidthRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." -- componentLinkTable OBJECT componentLinkRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." Dubuc, et al. Standards Track [Page 40] RFC 4220 MPLS TE Link MIB Module November 2005 -- componentLinkDescriptorTable OBJECT componentLinkDescrRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." -- componentLinkBandwidthTable OBJECT componentLinkBandwidthRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." ::= { teLinkCompliances 1 } teLinkModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that support the monitoring of the TE link MIB module." MODULE -- this module MANDATORY-GROUPS { teLinkGroup, teLinkBandwidthGroup, componentLinkBandwidthGroup } GROUP teLinkSrlgGroup DESCRIPTION "This group is mandatory for GMPLS enabled devices." GROUP teLinkPscGroup DESCRIPTION "This group is mandatory for devices that support the packet switching capability." GROUP teLinkTdmGroup DESCRIPTION "This group is mandatory for devices that support the TDM switching capability." -- teLinkTable Dubuc, et al. Standards Track [Page 41] RFC 4220 MPLS TE Link MIB Module November 2005 OBJECT teLinkAddressType SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Only ipv4(1) and ipv6(2) address types need to be supported for numbered links. For unnumbered links, the unknown(0) address type needs to be supported." OBJECT teLinkLocalIpAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Size of TE link IP address depends on type of TE link. TE link IP address size is zero if the link is unnumbered, four if the link IP address is IPv4, and sixteen if the link IP address is IPv6." OBJECT teLinkRemoteIpAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Size of TE link IP address depends on type of TE link. TE link IP address size is zero if the link is unnumbered, four if the link IP address is IPv4, and sixteen if the link IP address is IPv6." OBJECT teLinkProtectionType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkWorkingPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required and active(1) is the only status that needs to be supported." OBJECT teLinkStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Dubuc, et al. Standards Track [Page 42] RFC 4220 MPLS TE Link MIB Module November 2005 -- teLinkDescriptorTable OBJECT teLinkDescrSwitchingCapability MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrEncodingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMinLspBandwidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio0 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio1 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio6 Dubuc, et al. Standards Track [Page 43] RFC 4220 MPLS TE Link MIB Module November 2005 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrMaxLspBandwidthPrio7 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT teLinkDescrRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required and active(1) is the only status that needs to be supported." OBJECT teLinkDescrStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- teLinkSrlgTable OBJECT teLinkSrlgRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required and active(1) is the only status that needs to be supported." OBJECT teLinkSrlgStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- teLinkBandwidthTable OBJECT teLinkBandwidthRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required and active(1) is the only status that needs to be supported." OBJECT teLinkBandwidthStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Dubuc, et al. Standards Track [Page 44] RFC 4220 MPLS TE Link MIB Module November 2005 -- componentLinkTable OBJECT componentLinkMaxResBandwidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkPreferredProtection MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required and active(1) is the only status that needs to be supported." OBJECT componentLinkStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- componentLinkDescriptorTable OBJECT componentLinkDescrSwitchingCapability MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrEncodingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMinLspBandwidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio0 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio1 MIN-ACCESS read-only Dubuc, et al. Standards Track [Page 45] RFC 4220 MPLS TE Link MIB Module November 2005 DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio6 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrMaxLspBandwidthPrio7 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrInterfaceMtu MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrIndication MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT componentLinkDescrRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required and active(1) is the Dubuc, et al. Standards Track [Page 46] RFC 4220 MPLS TE Link MIB Module November 2005 only status that needs to be supported." OBJECT componentLinkDescrStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- componentLinkBandwidthTable OBJECT componentLinkBandwidthRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required and active(1) is the only status that needs to be supported." OBJECT componentLinkBandwidthStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { teLinkCompliances 2 } -- Units of conformance teLinkGroup OBJECT-GROUP OBJECTS { teLinkAddressType, teLinkLocalIpAddr, teLinkRemoteIpAddr, teLinkMetric, teLinkProtectionType, teLinkWorkingPriority, teLinkResourceClass, teLinkIncomingIfId, teLinkOutgoingIfId, teLinkRowStatus, teLinkStorageType, teLinkDescrSwitchingCapability, teLinkDescrEncodingType, teLinkDescrRowStatus, teLinkDescrStorageType, componentLinkPreferredProtection, componentLinkCurrentProtection, componentLinkRowStatus, componentLinkStorageType, componentLinkDescrSwitchingCapability, componentLinkDescrEncodingType, componentLinkDescrRowStatus, Dubuc, et al. Standards Track [Page 47] RFC 4220 MPLS TE Link MIB Module November 2005 componentLinkDescrStorageType } STATUS current DESCRIPTION "Collection of objects needed for the management of resources associated with TE links." ::= { teLinkGroups 1 } teLinkSrlgGroup OBJECT-GROUP OBJECTS { teLinkSrlgRowStatus, teLinkSrlgStorageType } STATUS current DESCRIPTION "Collection of objects needed for the management of SRLG resources associated with TE links." ::= { teLinkGroups 2 } teLinkBandwidthGroup OBJECT-GROUP OBJECTS { teLinkMaximumReservableBandwidth, teLinkDescrMaxLspBandwidthPrio0, teLinkDescrMaxLspBandwidthPrio1, teLinkDescrMaxLspBandwidthPrio2, teLinkDescrMaxLspBandwidthPrio3, teLinkDescrMaxLspBandwidthPrio4, teLinkDescrMaxLspBandwidthPrio5, teLinkDescrMaxLspBandwidthPrio6, teLinkDescrMaxLspBandwidthPrio7, teLinkBandwidthUnreserved, teLinkBandwidthRowStatus, teLinkBandwidthStorageType } STATUS current DESCRIPTION "Collection of objects needed for the management of the bandwidth resources associated with TE links and component links." ::= { teLinkGroups 3 } componentLinkBandwidthGroup OBJECT-GROUP OBJECTS { componentLinkMaxResBandwidth, componentLinkDescrMaxLspBandwidthPrio0, componentLinkDescrMaxLspBandwidthPrio1, componentLinkDescrMaxLspBandwidthPrio2, componentLinkDescrMaxLspBandwidthPrio3, Dubuc, et al. Standards Track [Page 48] RFC 4220 MPLS TE Link MIB Module November 2005 componentLinkDescrMaxLspBandwidthPrio4, componentLinkDescrMaxLspBandwidthPrio5, componentLinkDescrMaxLspBandwidthPrio6, componentLinkDescrMaxLspBandwidthPrio7, componentLinkBandwidthUnreserved, componentLinkBandwidthRowStatus, componentLinkBandwidthStorageType } STATUS current DESCRIPTION "Collection of objects needed for the management of the bandwidth parameters associated with component links." ::= { teLinkGroups 4 } teLinkPscGroup OBJECT-GROUP OBJECTS { teLinkDescrMinLspBandwidth, teLinkDescrInterfaceMtu, componentLinkDescrMinLspBandwidth, componentLinkDescrInterfaceMtu } STATUS current DESCRIPTION "Collection of objects needed for devices that are packet switch capable." ::= { teLinkGroups 5 } teLinkTdmGroup OBJECT-GROUP OBJECTS { teLinkDescrMinLspBandwidth, teLinkDescrIndication, componentLinkDescrMinLspBandwidth, componentLinkDescrIndication } STATUS current DESCRIPTION "Collection of objects needed for devices that are TDM switching capable." ::= { teLinkGroups 6 } -- End of TE-LINK-STD-MIB END Dubuc, et al. Standards Track [Page 49] RFC 4220 MPLS TE Link MIB Module November 2005 10. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - All the tables in this MIB module have routing information in them, so they all have the same security attributes. Unauthorized changes to attributes of these tables can disrupt resource allocation in the network. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: - IP address entries in the teLinkTable (teLinkLocalIpAddr and teLinkRemoteIpAddr) may reveal the internals of a network provider IP address space. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Dubuc, et al. Standards Track [Page 50] RFC 4220 MPLS TE Link MIB Module November 2005 11. Contributors Sudheer Dharanikota EMail: sudheer@ieee.org 12. Acknowledgements The authors would like to acknowledge the contribution of Dmitry Ryumkin. 13. IANA Considerations The following "IANA Considerations" subsection requests IANA for a new assignment. New assignments can only be made via Standards Action as specified in [RFC2434]. 13.1. IANA Considerations for the TE-LINK-STD-MIB The TE-LINK-STD-MIB should be rooted under the transmission subtree. The IANA has assigned { transmission 200 } to the TE-LINK-STD-MIB module specified in this document. 14. References 14.1. Normative References [IANAifType] "IANAifType MIB Module", http://www.iana.org/assignments/ianaiftype-mib. [IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653- 8). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Dubuc, et al. Standards Track [Page 51] RFC 4220 MPLS TE Link MIB Module November 2005 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4201] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. 14.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. Dubuc, et al. Standards Track [Page 52] RFC 4220 MPLS TE Link MIB Module November 2005 Authors' Addresses Martin Dubuc EMail: mdubuc@ncf.ca Thomas D. Nadeau Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719 Phone: +1-978-244-3051 EMail: tnadeau@cisco.com Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101 EMail: jplang@ieee.org Dubuc, et al. Standards Track [Page 53] RFC 4220 MPLS TE Link MIB Module November 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Dubuc, et al. Standards Track [Page 54] snmp-mibs-downloader-1.1/mibrfcs/rfc4265.txt0000644000000000000000000002534011402176072015567 0ustar Network Working Group B. Schliesser Request for Comments: 4265 SAVVIS Communications Category: Standards Track T. Nadeau Cisco Systems, Inc. November 2005 Definition of Textual Conventions for Virtual Private Network (VPN) Management 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). Table of Contents 1. Introduction ....................................................1 1.1. Conventions Used in This Document ..........................2 2. The Internet-Standard Management Framework ......................2 3. VPN-TC-STD-MIB ..................................................2 3.1. Description ................................................2 3.2. Definitions ................................................2 4. Security Considerations .........................................4 5. IANA Considerations for VPN-TC-STD-MIB ..........................4 6. References ......................................................4 6.1. Normative References .......................................4 6.2. Informative References .....................................5 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions used in Virtual Private Networks (VPNs) and IETF VPN-related MIBs. Schliesser & Nadeau Standards Track [Page 1] RFC 4265 VPN-TC-STD-MIB November 2005 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. VPN-TC-STD-MIB 3.1. Description The VPN-TC-STD-MIB defines a Textual Convention for the Global VPN Identifier, or VPN-ID, as specified in [RFC2685]. The purpose of a VPN-ID is to uniquely identify a VPN. It MUST be 7 octets in length, and SHOULD be comprised of a 3 octet Organizationally Unique Identifier (OUI) that uniquely identifies the VPN Authority, followed by a 4 octet value assigned by the VPN Authority that uniquely identifies the VPN within the context of the OUI. 3.2. Definitions VPN-TC-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; vpnTcMIB MODULE-IDENTITY LAST-UPDATED "200511150000Z" -- 15 November 2005 ORGANIZATION "Layer 3 Virtual Private Networks (L3VPN) Working Group." Schliesser & Nadeau Standards Track [Page 2] RFC 4265 VPN-TC-STD-MIB November 2005 CONTACT-INFO "Benson Schliesser bensons@savvis.net Thomas D. Nadeau tnadeau@cisco.com This TC MIB is a product of the PPVPN http://www.ietf.org/html.charters/ppvpn-charter.html and subsequently the L3VPN http://www.ietf.org/html.charters/l3vpn-charter.html working groups. Comments and discussion should be directed to l3vpn@ietf.org" DESCRIPTION "This MIB contains TCs for VPNs. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4265; see the RFC itself for full legal notices." -- Revision history. REVISION "200511150000Z" -- 15 November 2005 DESCRIPTION "Initial version, published as RFC 4265." ::= { mib-2 129 } -- definition of textual conventions VPNId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The purpose of a VPN-ID is to uniquely identify a VPN. The Global VPN Identifier format is: 3 octet VPN Authority, Organizationally Unique Identifier followed by 4 octet VPN index identifying VPN according to OUI" REFERENCE "Fox, B. and Gleeson, B., 'Virtual Private Networks Identifier', RFC 2685, September 1999." SYNTAX OCTET STRING (SIZE (7)) VPNIdOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention is an extension of the VPNId textual convention that defines a non-zero-length OCTET STRING to identify a physical entity. This extension permits the additional value of a zero-length OCTET STRING. Schliesser & Nadeau Standards Track [Page 3] RFC 4265 VPN-TC-STD-MIB November 2005 The semantics of the value zero-length OCTET STRING are object-specific and must therefore be defined as part of the description of any object that uses this syntax. Examples of usage of this extension are situations where none or all VPN IDs need to be referenced." SYNTAX OCTET STRING (SIZE (0 | 7)) END 4. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions that may be used by other MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet. 5. IANA Considerations for VPN-TC-STD-MIB The IANA has assigned { mib-2 129 } to the VPN-TC-STD-MIB module specified in this document. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. Schliesser & Nadeau Standards Track [Page 4] RFC 4265 VPN-TC-STD-MIB November 2005 6.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Authors' Addresses Benson Schliesser SAVVIS Communications 1 Savvis Parkway Saint Louis, MO 63017 USA Phone: +1-314-628-7036 EMail: bensons@savvis.net Thomas D. Nadeau Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719 Phone: +1-978-244-3051 EMail: tnadeau@cisco.com Schliesser & Nadeau Standards Track [Page 5] RFC 4265 VPN-TC-STD-MIB November 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schliesser & Nadeau Standards Track [Page 6] snmp-mibs-downloader-1.1/mibrfcs/rfc4268.txt0000644000000000000000000011663411402176072015601 0ustar Network Working Group S. Chisholm Request for Comments: 4268 Nortel Networks Category: Standards Track D. Perkins SNMPinfo November 2005 Entity State MIB 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the Entity MIB to provide information about the state of physical entities. In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations. Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Entity State ....................................................2 2.1. Hierarchical State Management ..............................3 2.2. Entity Redundancy ..........................................3 2.3. Physical Entity Users ......................................3 2.4. Physical Class Behavior ....................................4 3. Relation to Other MIBs ..........................................4 3.1. Relation to the Interfaces MIB .............................4 3.2. Relation to Alarm MIB ......................................5 3.3. Relation to Bridge MIB .....................................5 3.4. Relation to the Host Resources MIB .........................5 4. Textual Conventions .............................................6 5. Definitions .................................................... 9 Chisholm & Perkins Standards Track [Page 1] RFC 4268 Entity State MIB November 2005 6. Security Considerations ........................................16 7. Acknowledgements ...............................................17 8. References .....................................................17 8.1. Normative References ......................................17 8.2. Informative References ....................................18 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Entity State The goal in adding state objects to the Entity MIB [RFC4133] is to define a useful subset of the possible state attributes that could be tracked for a given entity and that both fit into the state models such as those used in the Interfaces MIB [RFC2863] as well as leverage existing well-deployed models. The entStateTable contains state objects that are a subset of the popular ISO/OSI states that are also defined in ITU's X.731 specification [X.731]. Objects are defined to capture administrative, operational, and usage states. In addition, there are further state objects defined to provide more information for these three basic states. Administrative state indicates permission to use or prohibition against using the entity and is imposed through the management services. Operational state indicates whether or not the entity is physically installed and working. Note that unlike the ifOperStatus [RFC2863], this operational state is independent of the administrative state. Usage state indicates whether or not the entity is in use at a specific instance, and if so, whether or not it currently has spare capacity to serve additional users. In the context of this MIB, the usage state refers to the ability of an entity to service other entities within its containment hierarchy. Chisholm & Perkins Standards Track [Page 2] RFC 4268 Entity State MIB November 2005 Alarm state indicates whether or not there are any alarms active against the entity. In addition to those alarm states defined in X.731 [X.731], warning and indeterminate status are also defined to provide a more complete mapping to the Alarm MIB [RFC3877]. Standby state indicates whether the entity is currently running as hot standby or cold standby or is currently providing service. The terms "state" and "status" are used interchangeably in this memo. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.1. Hierarchical State Management Physical entities exist within a containment hierarchy. Physical containment is defined by the entPhysicalContainedIn object[RFC4133]. This raises some interesting issues not addressed in existing work on state management. There are two types of state for an entity: 1) The state of the entity independent of the states of its parents and children in its containment hierarchy. This is often referred to as raw state. 2) The state of the entity, as it may be influenced by the state of its parents and children. This is often referred to as computed state. All state objects in this memo are raw state. 2.2. Entity Redundancy While this memo is not attempting to address the entire problem space around redundancy, the entStateStandby object provides an important piece of state information for entities, which helps identify which pieces of redundant equipment are currently providing service, and which are waiting in either hot or cold standby mode. 2.3. Physical Entity Users There are three ways to define the 'user' of a physical entity 1. Direct containment in physical hierarchy 2. Anywhere in physical hierarchy Chisholm & Perkins Standards Track [Page 3] RFC 4268 Entity State MIB November 2005 3. As defined by a means outside the scope of this MIB. This could include logical interfaces that could run on a port, software that could run on a module, etc. Administrative, operational, alarm, and standby state use all three definitions of 'user'. Usage state supports only the concept of direct containment to simplify implementations of this object. 2.4. Physical Class Behavior This MIB makes no effort to standardize the behaviors and characteristics of the various physical classes [RFC4133], but rather how this information is reported. In looking at real-world products, items within the same physical class vary substantially. The MIB has therefore provided guidance on how to support objects where a particular instance of a physical class cannot support part or all of a particular state. 3. Relation to Other MIBs 3.1. Relation to the Interfaces MIB The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which has states of up, down, and testing, and the ifOperStatus object, which has states of up, down, testing, unknown, dormant, notPresent, and lowerLayerDown. An ifAdminStatus of 'up' is equivalent to setting the entStateAdmin object to 'unlocked'. An ifAdminStatus of 'down' is equivalent to setting the entStateAdmin object to either 'locked' or 'shuttingDown', depending on a system's interpretation of 'down'. An ifOperStatus of 'up' is equivalent to an entStateOper value of 'enabled'. An ifOperStatus of 'down' due to operational failure is equivalent to an entStateOper value of 'disabled'. An ifOperStatus of 'down' due to being administratively disabled is equivalent to an entStateAdmin value of 'locked' and an entStateOper value of either 'enabled' or 'disabled' depending on whether there are any known issues that would prevent the entity from becoming operational when its entStateAdmin is set to 'unlocked'. An ifOperStatus of 'unknown' is equivalent to an entStateOper value of 'unknown'. The ifOperStatus values of 'testing' and 'dormant' are not explicitly supported by this MIB, but the state objects will be able to reflect other aspects of the entities' administrative and operational state. The ifOperStatus values of 'notPresent' and 'lowerLayerDown' are in some ways computed states and so are therefore not supported in this Chisholm & Perkins Standards Track [Page 4] RFC 4268 Entity State MIB November 2005 MIB. They can, though, be computed by examining the states of entities within this object's containment hierarchy and other available related states. 3.2. Relation to Alarm MIB The entStateAlarm object indicates whether or not there are any active alarms against this entity. If there are active alarms, then the alarmActiveTable in the Alarm MIB [RFC3877] should be searched for rows whose alarmActiveResourceId matches this entPhysicalIndex. Alternatively, if the alarmActiveTable is queried first and an active alarm with a value of alarmActiveResourceId that matches this entPhysicalIndex is found, then entStateAlarm can be used to quickly determine if there are additional active alarms with a different severity against this physical entity. 3.3 Relation to Bridge MIB For entities of physical type of 'port' that support the dot1dStpPortEnable object in the Bridge MIB [RFC4188], a value of 'enabled' is equivalent to setting the entStateAdmin object to 'unlocked'. Setting dot1dStpPortEnable to 'disabled' is equivalent to setting the entStateAdmin object to 'locked'. 3.4 Relation to the Host Resources MIB The hrDeviceStatus object in the Host Resources MIB [RFC2790] provides an operational state for devices. For entities that logically correspond to the concept of a device, a value of 'unknown' for hrDeviceStatus corresponds to an entStateOper value of 'unknown'. A value of 'running' corresponds to an entStateOper value of 'enabled'. A value of 'warning' also corresponds to an entStateOper value of 'enabled', but with appropriate bits set in the entStateAlarm object to indicate the alarms corresponding to the unusual error condition detected. A value of 'testing' or 'down' is equivalent to an entStateOper value of 'disabled'. Chisholm & Perkins Standards Track [Page 5] RFC 4268 Entity State MIB November 2005 4. Textual Conventions ENTITY-STATE-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; entityStateTc MODULE-IDENTITY LAST-UPDATED "200511220000Z" ORGANIZATION "IETF Entity MIB Working Group" CONTACT-INFO "General Discussion: entmib@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/entmib http://www.ietf.org/html.charters/entmib-charter.html Sharon Chisholm Nortel Networks PO Box 3511 Station C Ottawa, Ont. K1Y 4H7 Canada schishol@nortel.com David T. Perkins 548 Qualbrook Ct San Jose, CA 95110 USA Phone: 408 394-8702 dperkins@snmpinfo.com" DESCRIPTION "This MIB defines state textual conventions. Copyright (C) The Internet Society 2005. This version of this MIB module is part of RFC 4268; see the RFC itself for full legal notices." REVISION "200511220000Z" DESCRIPTION "Initial version, published as RFC 4268." ::= { mib-2 130 } EntityAdminState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the various possible administrative states. Chisholm & Perkins Standards Track [Page 6] RFC 4268 Entity State MIB November 2005 A value of 'locked' means the resource is administratively prohibited from use. A value of 'shuttingDown' means that usage is administratively limited to current instances of use. A value of 'unlocked' means the resource is not administratively prohibited from use. A value of 'unknown' means that this resource is unable to report administrative state." SYNTAX INTEGER { unknown (1), locked (2), shuttingDown (3), unlocked (4) } EntityOperState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of operational states. A value of 'disabled' means the resource is totally inoperable. A value of 'enabled' means the resource is partially or fully operable. A value of 'testing' means the resource is currently being tested and cannot therefore report whether it is operational or not. A value of 'unknown' means that this resource is unable to report operational state." SYNTAX INTEGER { unknown (1), disabled (2), enabled (3), testing (4) } EntityUsageState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of usage states. A value of 'idle' means the resource is servicing no users. A value of 'active' means the resource is currently in use and it has sufficient spare capacity to provide for additional users. A value of 'busy' means the resource is currently in use, but it currently has no spare capacity to provide for additional users. A value of 'unknown' means that this resource is unable to report usage state." SYNTAX INTEGER Chisholm & Perkins Standards Track [Page 7] RFC 4268 Entity State MIB November 2005 { unknown (1), idle (2), active (3), busy (4) } EntityAlarmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of alarm status. An Alarm [RFC3877] is a persistent indication of an error or warning condition. When no bits of this attribute are set, then no active alarms are known against this entity and it is not under repair. When the 'value of underRepair' is set, the resource is currently being repaired, which, depending on the implementation, may make the other values in this bit string not meaningful. When the value of 'critical' is set, one or more critical alarms are active against the resource. When the value of 'major' is set, one or more major alarms are active against the resource. When the value of 'minor' is set, one or more minor alarms are active against the resource. When the value of 'warning' is set, one or more warning alarms are active against the resource. When the value of 'indeterminate' is set, one or more alarms of whose perceived severity cannot be determined are active against this resource. A value of 'unknown' means that this resource is unable to report alarm state." SYNTAX BITS { unknown (0), underRepair (1), critical(2), major(3), minor(4), -- The following are not defined in X.733 warning (5), indeterminate (6) } Chisholm & Perkins Standards Track [Page 8] RFC 4268 Entity State MIB November 2005 EntityStandbyStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby status. A value of 'hotStandby' means the resource is not providing service, but it will be immediately able to take over the role of the resource to be backed up, without the need for initialization activity, and will contain the same information as the resource to be backed up. A value of 'coldStandy' means that the resource is to back up another resource, but will not be immediately able to take over the role of a resource to be backed up, and will require some initialization activity. A value of 'providingService' means the resource is providing service. A value of 'unknown' means that this resource is unable to report standby state." SYNTAX INTEGER { unknown (1), hotStandby (2), coldStandby (3), providingService (4) } END 5. Definitions ENTITY-STATE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF entPhysicalIndex FROM ENTITY-MIB EntityAdminState, EntityOperState, EntityUsageState, EntityAlarmStatus, EntityStandbyStatus FROM ENTITY-STATE-TC-MIB; entityStateMIB MODULE-IDENTITY LAST-UPDATED "200511220000Z" ORGANIZATION "IETF Entity MIB Working Group" Chisholm & Perkins Standards Track [Page 9] RFC 4268 Entity State MIB November 2005 CONTACT-INFO " General Discussion: entmib@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/entmib http://www.ietf.org/html.charters/entmib-charter.html Sharon Chisholm Nortel Networks PO Box 3511 Station C Ottawa, Ont. K1Y 4H7 Canada schishol@nortel.com David T. Perkins 548 Qualbrook Ct San Jose, CA 95110 USA Phone: 408 394-8702 dperkins@snmpinfo.com " DESCRIPTION "This MIB defines a state extension to the Entity MIB. Copyright (C) The Internet Society 2005. This version of this MIB module is part of RFC 4268; see the RFC itself for full legal notices." REVISION "200511220000Z" DESCRIPTION "Initial version, published as RFC 4268." ::= { mib-2 131 } -- Entity State Objects entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1 } entStateTable OBJECT-TYPE SYNTAX SEQUENCE OF EntStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about state/status of entities. This is a sparse augment of the entPhysicalTable. Entries appear in this table for values of entPhysicalClass [RFC4133] that in this implementation are able to report any of the state or status stored in this table. Chisholm & Perkins Standards Track [Page 10] RFC 4268 Entity State MIB November 2005 " ::= { entStateObjects 1 } entStateEntry OBJECT-TYPE SYNTAX EntStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "State information about this physical entity." INDEX { entPhysicalIndex } ::= { entStateTable 1 } EntStateEntry ::= SEQUENCE { entStateLastChanged DateAndTime, entStateAdmin EntityAdminState, entStateOper EntityOperState, entStateUsage EntityUsageState, entStateAlarm EntityAlarmStatus, entStateStandby EntityStandbyStatus } entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when the value of any of entStateAdmin, entStateOper, entStateUsage, entStateAlarm, or entStateStandby changed for this entity. If there has been no change since the last re-initialization of the local system, this object contains the date and time of local system initialization. If there has been no change since the entity was added to the local system, this object contains the date and time of the insertion." ::= { entStateEntry 1 } entStateAdmin OBJECT-TYPE SYNTAX EntityAdminState MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative state for this entity. Chisholm & Perkins Standards Track [Page 11] RFC 4268 Entity State MIB November 2005 This object refers to an entities administrative permission to service both other entities within its containment hierarchy as well other users of its services defined by means outside the scope of this MIB. Setting this object to 'notSupported' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error. Some physical entities exhibit only a subset of the remaining administrative state values. Some entities cannot be locked, and hence this object exhibits only the 'unlocked' state. Other entities cannot be shutdown gracefully, and hence this object does not exhibit the 'shuttingDown' state. A value of 'inconsistentValue' will be returned if attempts are made to set this object to values not supported by its administrative model." ::= { entStateEntry 2 } entStateOper OBJECT-TYPE SYNTAX EntityOperState MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state for this entity. Note that unlike the state model used within the Interfaces MIB [RFC2863], this object does not follow the administrative state. An administrative state of down does not predict an operational state of disabled. A value of 'testing' means that entity currently being tested and cannot therefore report whether it is operational or not. A value of 'disabled' means that an entity is totally inoperable and unable to provide service both to entities within its containment hierarchy, or to other receivers of its service as defined in ways outside the scope of this MIB. A value of 'enabled' means that an entity is fully or partially operable and able to provide service both to Chisholm & Perkins Standards Track [Page 12] RFC 4268 Entity State MIB November 2005 entities within its containment hierarchy, or to other receivers of its service as defined in ways outside the scope of this MIB. Note that some implementations may not be able to accurately report entStateOper while the entStateAdmin object has a value other than 'unlocked'. In these cases, this object MUST have a value of 'unknown'." ::= { entStateEntry 3 } entStateUsage OBJECT-TYPE SYNTAX EntityUsageState MAX-ACCESS read-only STATUS current DESCRIPTION "The usage state for this entity. This object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of 'idle' means this entity is able to contain other entities but that no other entity is currently contained within this entity. A value of 'active' means that at least one entity is contained within this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it. Some entities will exhibit only a subset of the usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of 'busy'. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of 'idle' and 'busy'." ::= { entStateEntry 4 } entStateAlarm OBJECT-TYPE SYNTAX EntityAlarmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The alarm status for this entity. It does not include the alarms raised on child components within its containment hierarchy. A value of 'unknown' means that this entity is Chisholm & Perkins Standards Track [Page 13] RFC 4268 Entity State MIB November 2005 unable to report alarm state. Note that this differs from 'indeterminate', which means that alarm state is supported and there are alarms against this entity, but the severity of some of the alarms is not known. If no bits are set, then this entity supports reporting of alarms, but there are currently no active alarms against this entity." ::= { entStateEntry 5 } entStateStandby OBJECT-TYPE SYNTAX EntityStandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby status for this entity. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." ::= { entStateEntry 6 } -- Notifications entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } entStateOperEnabled NOTIFICATION-TYPE OBJECTS { entStateAdmin, entStateAlarm } STATUS current DESCRIPTION "An entStateOperEnabled notification signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entities has transitioned into the 'enabled' state. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings. The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information on the administrative state at the time of the operation state change as well as to find out whether there were any known alarms against the entity at that time that may explain why the physical entity has become operationally disabled." ::= { entStateNotifications 1 } Chisholm & Perkins Standards Track [Page 14] RFC 4268 Entity State MIB November 2005 entStateOperDisabled NOTIFICATION-TYPE OBJECTS { entStateAdmin, entStateAlarm } STATUS current DESCRIPTION "An entStateOperDisabled notification signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entities has transitioned into the 'disabled' state. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings. The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information on the administrative state at the time of the operation state change as well as to find out whether there were any known alarms against the entity at that time that may affect the physical entity's ability to stay operationally enabled." ::= { entStateNotifications 2 } -- Conformance and Compliance entStateConformance OBJECT IDENTIFIER ::= { entityStateMIB 2 } entStateCompliances OBJECT IDENTIFIER ::= { entStateConformance 1 } entStateCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems supporting the Entity State MIB." MODULE -- this module MANDATORY-GROUPS { entStateGroup } GROUP entStateNotificationsGroup DESCRIPTION "This group is optional." OBJECT entStateAdmin MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { entStateCompliances 1 } entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2 } Chisholm & Perkins Standards Track [Page 15] RFC 4268 Entity State MIB November 2005 entStateGroup OBJECT-GROUP OBJECTS { entStateLastChanged, entStateAdmin, entStateOper, entStateUsage, entStateAlarm, entStateStandby } STATUS current DESCRIPTION "Standard Entity State group." ::= { entStateGroups 1} entStateNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { entStateOperEnabled, entStateOperDisabled } STATUS current DESCRIPTION "Standard Entity State Notification group." ::= { entStateGroups 2} END 6. Security Considerations The ENTITY-STATE-TC-MIB defined in section 4 does not define any management objects. Instead, it defines a set of textual conventions that may be used by other MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. The ENTITY-STATE-TC-MIB has therefore no impact on the security of the Internet. The ENTITY-STATE-MIB defined in section 5 defines one management object -- entStateAdmin -- that has a MAX-ACCESS clause of read- write. The object may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Note that setting the entStateAdmin to 'locked' or 'shuttingDown' can cause disruption of services ranging from those running on a port to those on an entire device, depending on the type of entity. Access to this object should be properly protected. Chisholm & Perkins Standards Track [Page 16] RFC 4268 Entity State MIB November 2005 Access to the objects defined in this MIB allows one to figure out what the active and standby resources in a network are. This information can be used to optimize attacks on networks so even read-only access to this MIB should be properly protected. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (entities) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Acknowledgements This document is a product of the Entity MIB Working Group. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Chisholm & Perkins Standards Track [Page 17] RFC 4268 Entity State MIB November 2005 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. 8.2. Informative References [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2863, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004. [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005. [X.731] ITU Recommendation X.731, "Information Technology - Open Systems Interconnection - System Management: State Management Function", 1992. Authors' Addresses Sharon Chisholm Nortel Networks PO Box 3511, Station C Ottawa, Ontario, K1Y 4H7 Canada EMail: schishol@nortel.com David T. Perkins 548 Qualbrook Ct San Jose, CA 95110 USA Phone: 408 394-8702 EMail: dperkins@snmpinfo.com Chisholm & Perkins Standards Track [Page 18] RFC 4268 Entity State MIB November 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Chisholm & Perkins Standards Track [Page 19] snmp-mibs-downloader-1.1/mibrfcs/rfc4273.txt0000644000000000000000000020013511402176072015563 0ustar Network Working Group J. Haas, Ed. Request for Comments: 4273 S. Hares, Ed. Obsoletes: 1269, 1657 NextHop Technologies Category: Standards Track January 2006 Definitions of Managed Objects for BGP-4 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. The origin of this memo is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions. This document obsoletes RFC 1269 and RFC 1657. Haas & Hares Standards Track [Page 1] RFC 4273 BGP4-MIB January 2006 Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Overview ........................................................2 4. Definitions .....................................................3 5. Security Considerations ........................................28 6. Acknowledgements ...............................................30 7. Normative References ...........................................31 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [BGP4, BGP4APP]. This memo obsoletes RFC 1657 and RFC 1269. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview These objects are used to control and manage a BGP-4 implementation. Apart from a few system-wide scalar objects, this MIB is broken into three tables: the BGP Peer Table, the BGP Received Path Attribute Table, and the BGP-4 Received Path Attribute Table. The BGP Peer Table contains information about state and current activity of connections with the BGP peers. The BGP Received Path Attribute Table contains path attributes received from all peers running BGP version 3 or less. The BGP-4 Received Path Attribute Table contains path attributes received from all BGP-4 peers. The actual attributes used in determining a route are a subset of the received attribute tables after local routing policy has been applied. Haas & Hares Standards Track [Page 2] RFC 4273 BGP4-MIB January 2006 4. Definitions BGP4-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress, Integer32, Counter32, Gauge32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; bgp MODULE-IDENTITY LAST-UPDATED "200601110000Z" ORGANIZATION "IETF IDR Working Group" CONTACT-INFO "E-mail: idr@ietf.org Jeffrey Haas, Susan Hares (Editors) NextHop Technologies 825 Victors Way Suite 100 Ann Arbor, MI 48108-2738 Tel: +1 734 222-1600 Fax: +1 734 222-1602 E-mail: jhaas@nexthop.com skh@nexthop.com" DESCRIPTION "The MIB module for the BGP-4 protocol. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4273; see the RFC itself for full legal notices." REVISION "200601110000Z" DESCRIPTION "Changes from RFC 1657: 1) Fixed the definitions of the notifications to make them equivalent to their initial definition in RFC 1269. 2) Added compliance and conformance info. 3) Updated information for the values of bgpPeerNegotiatedVersion, bgp4PathAttrLocalPref, bgp4PathAttrCalcLocalPref, bgp4PathAttrMultiExitDisc, bgp4PathAttrASPathSegement. 4) Added additional clarification comments where needed. Haas & Hares Standards Track [Page 3] RFC 4273 BGP4-MIB January 2006 5) Noted where objects do not fully reflect the protocol as Known Issues. 6) Updated the DESCRIPTION for the bgp4PathAttrAtomicAggregate object. 7) The following objects have had their DESCRIPTION clause modified to remove the text that suggested (using 'should' verb) initializing the counter to zero on a transition to the established state: bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages, bgpPeerOutTotalMessages Those implementations that still do this are still compliant with this new wording. Applications should not assume counters have started at zero. Published as RFC 4273." REVISION "199405050000Z" DESCRIPTION "Translated to SMIv2 and published as RFC 1657." REVISION "199110261839Z" DESCRIPTION "Initial version, published as RFC 1269." ::= { mib-2 15 } bgpVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Vector of supported BGP protocol version numbers. Each peer negotiates the version from this vector. Versions are identified via the string of bits contained within this object. The first octet contains bits 0 to 7, the second octet contains bits 8 to 15, and so on, with the most significant bit referring to the lowest bit number in the octet (e.g., the MSB of the first octet refers to bit 0). If a bit, i, is present and set, then the version (i+1) of the BGP is supported." REFERENCE "RFC 4271, Section 4.2." ::= { bgp 1 } bgpLocalAs OBJECT-TYPE Haas & Hares Standards Track [Page 4] RFC 4273 BGP4-MIB January 2006 SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The local autonomous system number." REFERENCE "RFC 4271, Section 4.2, 'My Autonomous System'." ::= { bgp 2 } -- BGP Peer table. This table contains, one entry per -- BGP peer, information about the BGP peer. bgpPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF BgpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "BGP peer table. This table contains, one entry per BGP peer, information about the connections with BGP peers." ::= { bgp 3 } bgpPeerEntry OBJECT-TYPE SYNTAX BgpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information about the connection with a BGP peer." INDEX { bgpPeerRemoteAddr } ::= { bgpPeerTable 1 } BgpPeerEntry ::= SEQUENCE { bgpPeerIdentifier IpAddress, bgpPeerState INTEGER, bgpPeerAdminStatus INTEGER, bgpPeerNegotiatedVersion Integer32, bgpPeerLocalAddr IpAddress, bgpPeerLocalPort Integer32, bgpPeerRemoteAddr IpAddress, bgpPeerRemotePort Haas & Hares Standards Track [Page 5] RFC 4273 BGP4-MIB January 2006 Integer32, bgpPeerRemoteAs Integer32, bgpPeerInUpdates Counter32, bgpPeerOutUpdates Counter32, bgpPeerInTotalMessages Counter32, bgpPeerOutTotalMessages Counter32, bgpPeerLastError OCTET STRING, bgpPeerFsmEstablishedTransitions Counter32, bgpPeerFsmEstablishedTime Gauge32, bgpPeerConnectRetryInterval Integer32, bgpPeerHoldTime Integer32, bgpPeerKeepAlive Integer32, bgpPeerHoldTimeConfigured Integer32, bgpPeerKeepAliveConfigured Integer32, bgpPeerMinASOriginationInterval Integer32, bgpPeerMinRouteAdvertisementInterval Integer32, bgpPeerInUpdateElapsedTime Gauge32 } bgpPeerIdentifier OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The BGP Identifier of this entry's BGP peer. This entry MUST be 0.0.0.0 unless the bgpPeerState is in the openconfirm or the established state." REFERENCE "RFC 4271, Section 4.2, 'BGP Identifier'." ::= { bgpPeerEntry 1 } Haas & Hares Standards Track [Page 6] RFC 4273 BGP4-MIB January 2006 bgpPeerState OBJECT-TYPE SYNTAX INTEGER { idle(1), connect(2), active(3), opensent(4), openconfirm(5), established(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The BGP peer connection state." REFERENCE "RFC 4271, Section 8.2.2." ::= { bgpPeerEntry 2 } bgpPeerAdminStatus OBJECT-TYPE SYNTAX INTEGER { stop(1), start(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired state of the BGP connection. A transition from 'stop' to 'start' will cause the BGP Manual Start Event to be generated. A transition from 'start' to 'stop' will cause the BGP Manual Stop Event to be generated. This parameter can be used to restart BGP peer connections. Care should be used in providing write access to this object without adequate authentication." REFERENCE "RFC 4271, Section 8.1.2." ::= { bgpPeerEntry 3 } bgpPeerNegotiatedVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The negotiated version of BGP running between the two peers. This entry MUST be zero (0) unless the bgpPeerState is in the openconfirm or the Haas & Hares Standards Track [Page 7] RFC 4273 BGP4-MIB January 2006 established state. Note that legal values for this object are between 0 and 255." REFERENCE "RFC 4271, Section 4.2. RFC 4271, Section 7." ::= { bgpPeerEntry 4 } bgpPeerLocalAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The local IP address of this entry's BGP connection." ::= { bgpPeerEntry 5 } bgpPeerLocalPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The local port for the TCP connection between the BGP peers." ::= { bgpPeerEntry 6 } bgpPeerRemoteAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The remote IP address of this entry's BGP peer." ::= { bgpPeerEntry 7 } bgpPeerRemotePort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote port for the TCP connection between the BGP peers. Note that the objects bgpPeerLocalAddr, bgpPeerLocalPort, bgpPeerRemoteAddr, and bgpPeerRemotePort provide the appropriate reference to the standard MIB TCP connection table." Haas & Hares Standards Track [Page 8] RFC 4273 BGP4-MIB January 2006 ::= { bgpPeerEntry 8 } bgpPeerRemoteAs OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote autonomous system number received in the BGP OPEN message." REFERENCE "RFC 4271, Section 4.2." ::= { bgpPeerEntry 9 } bgpPeerInUpdates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of BGP UPDATE messages received on this connection." REFERENCE "RFC 4271, Section 4.3." ::= { bgpPeerEntry 10 } bgpPeerOutUpdates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of BGP UPDATE messages transmitted on this connection." REFERENCE "RFC 4271, Section 4.3." ::= { bgpPeerEntry 11 } bgpPeerInTotalMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of messages received from the remote peer on this connection." REFERENCE "RFC 4271, Section 4." ::= { bgpPeerEntry 12 } bgpPeerOutTotalMessages OBJECT-TYPE SYNTAX Counter32 Haas & Hares Standards Track [Page 9] RFC 4273 BGP4-MIB January 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of messages transmitted to the remote peer on this connection." REFERENCE "RFC 4271, Section 4." ::= { bgpPeerEntry 13 } bgpPeerLastError OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "The last error code and subcode seen by this peer on this connection. If no error has occurred, this field is zero. Otherwise, the first byte of this two byte OCTET STRING contains the error code, and the second byte contains the subcode." REFERENCE "RFC 4271, Section 4.5." ::= { bgpPeerEntry 14 } bgpPeerFsmEstablishedTransitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times the BGP FSM transitioned into the established state for this peer." REFERENCE "RFC 4271, Section 8." ::= { bgpPeerEntry 15 } bgpPeerFsmEstablishedTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This timer indicates how long (in seconds) this peer has been in the established state or how long since this peer was last in the established state. It is set to zero when a new peer is configured or when the router is Haas & Hares Standards Track [Page 10] RFC 4273 BGP4-MIB January 2006 booted." REFERENCE "RFC 4271, Section 8." ::= { bgpPeerEntry 16 } bgpPeerConnectRetryInterval OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Time interval (in seconds) for the ConnectRetry timer. The suggested value for this timer is 120 seconds." REFERENCE "RFC 4271, Section 8.2.2. This is the value used to initialize the 'ConnectRetryTimer'." ::= { bgpPeerEntry 17 } bgpPeerHoldTime OBJECT-TYPE SYNTAX Integer32 ( 0 | 3..65535 ) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Time interval (in seconds) for the Hold Timer established with the peer. The value of this object is calculated by this BGP speaker, using the smaller of the values in bgpPeerHoldTimeConfigured and the Hold Time received in the OPEN message. This value must be at least three seconds if it is not zero (0). If the Hold Timer has not been established with the peer this object MUST have a value of zero (0). If the bgpPeerHoldTimeConfigured object has a value of (0), then this object MUST have a value of (0)." REFERENCE "RFC 4271, Section 4.2." ::= { bgpPeerEntry 18 } bgpPeerKeepAlive OBJECT-TYPE SYNTAX Integer32 ( 0 | 1..21845 ) Haas & Hares Standards Track [Page 11] RFC 4273 BGP4-MIB January 2006 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Time interval (in seconds) for the KeepAlive timer established with the peer. The value of this object is calculated by this BGP speaker such that, when compared with bgpPeerHoldTime, it has the same proportion that bgpPeerKeepAliveConfigured has, compared with bgpPeerHoldTimeConfigured. If the KeepAlive timer has not been established with the peer, this object MUST have a value of zero (0). If the of bgpPeerKeepAliveConfigured object has a value of (0), then this object MUST have a value of (0)." REFERENCE "RFC 4271, Section 4.4." ::= { bgpPeerEntry 19 } bgpPeerHoldTimeConfigured OBJECT-TYPE SYNTAX Integer32 ( 0 | 3..65535 ) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Time interval (in seconds) for the Hold Time configured for this BGP speaker with this peer. This value is placed in an OPEN message sent to this peer by this BGP speaker, and is compared with the Hold Time field in an OPEN message received from the peer when determining the Hold Time (bgpPeerHoldTime) with the peer. This value must not be less than three seconds if it is not zero (0). If it is zero (0), the Hold Time is NOT to be established with the peer. The suggested value for this timer is 90 seconds." REFERENCE "RFC 4271, Section 4.2. RFC 4271, Section 10." ::= { bgpPeerEntry 20 } bgpPeerKeepAliveConfigured OBJECT-TYPE Haas & Hares Standards Track [Page 12] RFC 4273 BGP4-MIB January 2006 SYNTAX Integer32 ( 0 | 1..21845 ) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Time interval (in seconds) for the KeepAlive timer configured for this BGP speaker with this peer. The value of this object will only determine the KEEPALIVE messages' frequency relative to the value specified in bgpPeerHoldTimeConfigured; the actual time interval for the KEEPALIVE messages is indicated by bgpPeerKeepAlive. A reasonable maximum value for this timer would be one third of that of bgpPeerHoldTimeConfigured. If the value of this object is zero (0), no periodical KEEPALIVE messages are sent to the peer after the BGP connection has been established. The suggested value for this timer is 30 seconds." REFERENCE "RFC 4271, Section 4.4. RFC 4271, Section 10." ::= { bgpPeerEntry 21 } bgpPeerMinASOriginationInterval OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Time interval (in seconds) for the MinASOriginationInterval timer. The suggested value for this timer is 15 seconds." REFERENCE "RFC 4271, Section 9.2.1.2. RFC 4271, Section 10." ::= { bgpPeerEntry 22 } bgpPeerMinRouteAdvertisementInterval OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION Haas & Hares Standards Track [Page 13] RFC 4273 BGP4-MIB January 2006 "Time interval (in seconds) for the MinRouteAdvertisementInterval timer. The suggested value for this timer is 30 seconds for EBGP connections and 5 seconds for IBGP connections." REFERENCE "RFC 4271, Section 9.2.1.1. RFC 4271, Section 10." ::= { bgpPeerEntry 23 } bgpPeerInUpdateElapsedTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Elapsed time (in seconds) since the last BGP UPDATE message was received from the peer. Each time bgpPeerInUpdates is incremented, the value of this object is set to zero (0)." REFERENCE "RFC 4271, Section 4.3. RFC 4271, Section 8.2.2, Established state." ::= { bgpPeerEntry 24 } bgpIdentifier OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The BGP Identifier of the local system." REFERENCE "RFC 4271, Section 4.2." ::= { bgp 4 } -- BGP Received Path Attribute Table. This table contains -- one entry per path to a network, and path attributes -- received from all peers running BGP version 3 or less. -- This table is obsolete, having been replaced in -- functionality by the bgp4PathAttrTable. bgpRcvdPathAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF BgpPathAttrEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The BGP Received Path Attribute Table contains information about paths to Haas & Hares Standards Track [Page 14] RFC 4273 BGP4-MIB January 2006 destination networks, received from all peers running BGP version 3 or less." ::= { bgp 5 } bgpPathAttrEntry OBJECT-TYPE SYNTAX BgpPathAttrEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "Information about a path to a network." INDEX { bgpPathAttrDestNetwork, bgpPathAttrPeer } ::= { bgpRcvdPathAttrTable 1 } BgpPathAttrEntry ::= SEQUENCE { bgpPathAttrPeer IpAddress, bgpPathAttrDestNetwork IpAddress, bgpPathAttrOrigin INTEGER, bgpPathAttrASPath OCTET STRING, bgpPathAttrNextHop IpAddress, bgpPathAttrInterASMetric Integer32 } bgpPathAttrPeer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The IP address of the peer where the path information was learned." ::= { bgpPathAttrEntry 1 } bgpPathAttrDestNetwork OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The address of the destination network." REFERENCE "RFC 1267, Section 4.3." ::= { bgpPathAttrEntry 2 } Haas & Hares Standards Track [Page 15] RFC 4273 BGP4-MIB January 2006 bgpPathAttrOrigin OBJECT-TYPE SYNTAX INTEGER { igp(1),-- networks are interior egp(2),-- networks learned via the -- EGP protocol incomplete(3) -- networks that -- are learned by some other -- means } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The ultimate origin of the path information." REFERENCE "RFC 1267, Section 4.3. RFC 1267, Section 5." ::= { bgpPathAttrEntry 3 } bgpPathAttrASPath OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2..255)) MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The set of ASes that must be traversed to reach the network. This object is probably best represented as SEQUENCE OF INTEGER. For SMI compatibility, though, it is represented as OCTET STRING. Each AS is represented as a pair of octets according to the following algorithm: first-byte-of-pair = ASNumber / 256; second-byte-of-pair = ASNumber & 255;" REFERENCE "RFC 1267, Section 4.3. RFC 1267, Section 5." ::= { bgpPathAttrEntry 4 } bgpPathAttrNextHop OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The address of the border router that should be used for the destination network." REFERENCE "RFC 1267, Section 4.3. RFC 1267, Section 5." ::= { bgpPathAttrEntry 5 } Haas & Hares Standards Track [Page 16] RFC 4273 BGP4-MIB January 2006 bgpPathAttrInterASMetric OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The optional inter-AS metric. If this attribute has not been provided for this route, the value for this object is 0." REFERENCE "RFC 1267, Section 4.3. RFC 1267, Section 5." ::= { bgpPathAttrEntry 6 } -- BGP-4 Received Path Attribute Table. This table -- contains one entry per path to a network, and path -- attributes received from all peers running BGP-4. bgp4PathAttrTable OBJECT-TYPE SYNTAX SEQUENCE OF Bgp4PathAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The BGP-4 Received Path Attribute Table contains information about paths to destination networks, received from all BGP4 peers." ::= { bgp 6 } bgp4PathAttrEntry OBJECT-TYPE SYNTAX Bgp4PathAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a path to a network." INDEX { bgp4PathAttrIpAddrPrefix, bgp4PathAttrIpAddrPrefixLen, bgp4PathAttrPeer } ::= { bgp4PathAttrTable 1 } Bgp4PathAttrEntry ::= SEQUENCE { bgp4PathAttrPeer IpAddress, bgp4PathAttrIpAddrPrefixLen Integer32, bgp4PathAttrIpAddrPrefix IpAddress, bgp4PathAttrOrigin INTEGER, Haas & Hares Standards Track [Page 17] RFC 4273 BGP4-MIB January 2006 bgp4PathAttrASPathSegment OCTET STRING, bgp4PathAttrNextHop IpAddress, bgp4PathAttrMultiExitDisc Integer32, bgp4PathAttrLocalPref Integer32, bgp4PathAttrAtomicAggregate INTEGER, bgp4PathAttrAggregatorAS Integer32, bgp4PathAttrAggregatorAddr IpAddress, bgp4PathAttrCalcLocalPref Integer32, bgp4PathAttrBest INTEGER, bgp4PathAttrUnknown OCTET STRING } bgp4PathAttrPeer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the peer where the path information was learned." ::= { bgp4PathAttrEntry 1 } bgp4PathAttrIpAddrPrefixLen OBJECT-TYPE SYNTAX Integer32 (0..32) MAX-ACCESS read-only STATUS current DESCRIPTION "Length in bits of the IP address prefix in the Network Layer Reachability Information field." ::= { bgp4PathAttrEntry 2 } bgp4PathAttrIpAddrPrefix OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An IP address prefix in the Network Layer Reachability Information field. This object Haas & Hares Standards Track [Page 18] RFC 4273 BGP4-MIB January 2006 is an IP address containing the prefix with length specified by bgp4PathAttrIpAddrPrefixLen. Any bits beyond the length specified by bgp4PathAttrIpAddrPrefixLen are zeroed." REFERENCE "RFC 4271, Section 4.3." ::= { bgp4PathAttrEntry 3 } bgp4PathAttrOrigin OBJECT-TYPE SYNTAX INTEGER { igp(1),-- networks are interior egp(2),-- networks learned via the -- EGP protocol incomplete(3) -- networks that -- are learned by some other -- means } MAX-ACCESS read-only STATUS current DESCRIPTION "The ultimate origin of the path information." REFERENCE "RFC 4271, Section 4.3. RFC 4271, Section 5.1.1." ::= { bgp4PathAttrEntry 4 } bgp4PathAttrASPathSegment OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence of AS path segments. Each AS path segment is represented by a triple . The type is a 1-octet field that has two possible values: 1 AS_SET: unordered set of ASes that a route in the UPDATE message has traversed 2 AS_SEQUENCE: ordered set of ASes that a route in the UPDATE message has traversed. The length is a 1-octet field containing the Haas & Hares Standards Track [Page 19] RFC 4273 BGP4-MIB January 2006 number of ASes in the value field. The value field contains one or more AS numbers. Each AS is represented in the octet string as a pair of octets according to the following algorithm: first-byte-of-pair = ASNumber / 256; second-byte-of-pair = ASNumber & 255; Known Issues: o BGP Confederations will result in a type of either 3 or 4. o An AS Path may be longer than 255 octets. This may result in this object containing a truncated AS Path." REFERENCE "RFC 4271, Section 4.3. RFC 4271, Section 5.1.2." ::= { bgp4PathAttrEntry 5 } bgp4PathAttrNextHop OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the border router that should be used for the destination network. This address is the NEXT_HOP address received in the UPDATE packet." REFERENCE "RFC 4271, Section 4.3. RFC 4271, Section 5.1.3." ::= { bgp4PathAttrEntry 6 } bgp4PathAttrMultiExitDisc OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This metric is used to discriminate between multiple exit points to an adjacent autonomous system. A value of -1 indicates the absence of this attribute. Known Issues: o The BGP-4 specification uses an unsigned 32 bit number. Thus, this Haas & Hares Standards Track [Page 20] RFC 4273 BGP4-MIB January 2006 object cannot represent the full range of the protocol." REFERENCE "RFC 4271, Section 4.3. RFC 4271, Section 5.1.4." ::= { bgp4PathAttrEntry 7 } bgp4PathAttrLocalPref OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The originating BGP4 speaker's degree of preference for an advertised route. A value of -1 indicates the absence of this attribute. Known Issues: o The BGP-4 specification uses an unsigned 32 bit number and thus this object cannot represent the full range of the protocol." REFERENCE "RFC 4271, Section 4.3. RFC 4271, Section 5.1.5." ::= { bgp4PathAttrEntry 8 } bgp4PathAttrAtomicAggregate OBJECT-TYPE SYNTAX INTEGER { lessSpecificRouteNotSelected(1), -- Typo corrected from RFC 1657 lessSpecificRouteSelected(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "If the ATOMIC_AGGREGATE attribute is present in the Path Attributes then this object MUST have a value of 'lessSpecificRouteNotSelected'. If the ATOMIC_AGGREGATE attribute is missing in the Path Attributes then this object MUST have a value of 'lessSpecificRouteSelected'. Note that ATOMIC_AGGREGATE is now a primarily informational attribute." REFERENCE "RFC 4271, Sections 5.1.6 and 9.1.4." Haas & Hares Standards Track [Page 21] RFC 4273 BGP4-MIB January 2006 ::= { bgp4PathAttrEntry 9 } bgp4PathAttrAggregatorAS OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The AS number of the last BGP4 speaker that performed route aggregation. A value of zero (0) indicates the absence of this attribute. Note that propagation of AS of zero is illegal in the Internet." REFERENCE "RFC 4271, Section 5.1.7. RFC 4271, Section 9.2.2.2." ::= { bgp4PathAttrEntry 10 } bgp4PathAttrAggregatorAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the last BGP4 speaker that performed route aggregation. A value of 0.0.0.0 indicates the absence of this attribute." REFERENCE "RFC 4271, Section 5.1.7. RFC 4271, Section 9.2.2.2." ::= { bgp4PathAttrEntry 11 } bgp4PathAttrCalcLocalPref OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The degree of preference calculated by the receiving BGP4 speaker for an advertised route. A value of -1 indicates the absence of this attribute. Known Issues: o The BGP-4 specification uses an unsigned 32 bit number and thus this object cannot represent the full range of the protocol." Haas & Hares Standards Track [Page 22] RFC 4273 BGP4-MIB January 2006 REFERENCE "RFC 4271, Section 9.1.1." ::= { bgp4PathAttrEntry 12 } bgp4PathAttrBest OBJECT-TYPE SYNTAX INTEGER { false(1),-- not chosen as best route true(2) -- chosen as best route } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this route was chosen as the best BGP4 route for this destination." REFERENCE "RFC 4271, Section 9.1.2." ::= { bgp4PathAttrEntry 13 } bgp4PathAttrUnknown OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "One or more path attributes not understood by this BGP4 speaker. Path attributes are recorded in the Update Path attribute format of type, length, value. Size zero (0) indicates the absence of such attributes. Octets beyond the maximum size, if any, are not recorded by this object. Known Issues: o Attributes understood by this speaker, but not represented in this MIB, are unavailable to the agent." REFERENCE "RFC 4271, Section 5." ::= { bgp4PathAttrEntry 14 } -- Traps. -- Note that in RFC 1657, bgpTraps was incorrectly -- assigned a value of { bgp 7 } and each of the -- traps had the bgpPeerRemoteAddr object inappropriately Haas & Hares Standards Track [Page 23] RFC 4273 BGP4-MIB January 2006 -- removed from their OBJECTS clause. The following -- definitions restore the semantics of the traps as -- they were initially defined in RFC 1269. bgpNotification OBJECT IDENTIFIER ::= { bgp 0 } bgpEstablishedNotification NOTIFICATION-TYPE OBJECTS { bgpPeerRemoteAddr, bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The bgpEstablishedNotification event is generated when the BGP FSM enters the established state. This Notification replaces the bgpEstablished Notification." ::= { bgpNotification 1 } bgpBackwardTransNotification NOTIFICATION-TYPE OBJECTS { bgpPeerRemoteAddr, bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The bgpBackwardTransNotification event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state. This Notification replaces the bgpBackwardsTransition Notification." ::= { bgpNotification 2 } -- { bgp 7 } is deprecated. Do not allocate new objects or -- notifications underneath this branch. bgpTraps OBJECT IDENTIFIER ::= { bgp 7 } -- deprecated bgpEstablished NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS deprecated DESCRIPTION "The bgpEstablished event is generated when the BGP FSM enters the established state. This Notification has been replaced by the bgpEstablishedNotification Notification." Haas & Hares Standards Track [Page 24] RFC 4273 BGP4-MIB January 2006 ::= { bgpTraps 1 } bgpBackwardTransition NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS deprecated DESCRIPTION "The bgpBackwardTransition event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state. This Notification has been replaced by the bgpBackwardTransNotification Notification." ::= { bgpTraps 2 } -- Conformance information bgp4MIBConformance OBJECT IDENTIFIER ::= { bgp 8 } bgp4MIBCompliances OBJECT IDENTIFIER ::= { bgp4MIBConformance 1 } bgp4MIBGroups OBJECT IDENTIFIER ::= { bgp4MIBConformance 2 } -- Compliance statements bgp4MIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the BGP4 mib." MODULE -- this module MANDATORY-GROUPS { bgp4MIBGlobalsGroup, bgp4MIBPeerGroup, bgp4MIBPathAttrGroup } GROUP bgp4MIBNotificationGroup DESCRIPTION "Implementation of BGP Notifications are completely optional in this MIB." ::= { bgp4MIBCompliances 1 } bgp4MIBDeprecatedCompliances MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement documenting deprecated objects in the BGP4 mib." MODULE -- this module GROUP bgp4MIBTrapGroup Haas & Hares Standards Track [Page 25] RFC 4273 BGP4-MIB January 2006 DESCRIPTION "Group containing TRAP objects that were improperly converted from SMIv1 in RFC 1657. The proper semantics have been restored with the objects in bgp4MIBNotificationGroup." ::= { bgp4MIBCompliances 2 } bgp4MIBObsoleteCompliances MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement documenting obsolete objects in the BGP4 mib." MODULE -- this module GROUP bgpRcvdPathAttrGroup DESCRIPTION "Group containing objects relevant to BGP-3 and earlier objects." ::= { bgp4MIBCompliances 3 } -- Units of conformance bgp4MIBGlobalsGroup OBJECT-GROUP OBJECTS { bgpVersion, bgpLocalAs, bgpIdentifier } STATUS current DESCRIPTION "A collection of objects providing information on global BGP state." ::= { bgp4MIBGroups 1 } bgp4MIBPeerGroup OBJECT-GROUP OBJECTS { bgpPeerIdentifier, bgpPeerState, bgpPeerAdminStatus, bgpPeerNegotiatedVersion, bgpPeerLocalAddr, bgpPeerLocalPort, bgpPeerRemoteAddr, bgpPeerRemotePort, bgpPeerRemoteAs, bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages, bgpPeerOutTotalMessages, bgpPeerLastError, bgpPeerFsmEstablishedTransitions, bgpPeerFsmEstablishedTime, Haas & Hares Standards Track [Page 26] RFC 4273 BGP4-MIB January 2006 bgpPeerConnectRetryInterval, bgpPeerHoldTime, bgpPeerKeepAlive, bgpPeerHoldTimeConfigured, bgpPeerKeepAliveConfigured, bgpPeerMinASOriginationInterval, bgpPeerMinRouteAdvertisementInterval, bgpPeerInUpdateElapsedTime } STATUS current DESCRIPTION "A collection of objects for managing BGP peers." ::= { bgp4MIBGroups 2 } bgpRcvdPathAttrGroup OBJECT-GROUP OBJECTS { bgpPathAttrPeer, bgpPathAttrDestNetwork, bgpPathAttrOrigin, bgpPathAttrASPath, bgpPathAttrNextHop, bgpPathAttrInterASMetric } STATUS obsolete DESCRIPTION "A collection of objects for managing BGP-3 and earlier path entries. This conformance group, like BGP-3, is obsolete." ::= { bgp4MIBGroups 3 } bgp4MIBPathAttrGroup OBJECT-GROUP OBJECTS { bgp4PathAttrPeer, bgp4PathAttrIpAddrPrefixLen, bgp4PathAttrIpAddrPrefix, bgp4PathAttrOrigin, bgp4PathAttrASPathSegment, bgp4PathAttrNextHop, bgp4PathAttrMultiExitDisc, bgp4PathAttrLocalPref, bgp4PathAttrAtomicAggregate, bgp4PathAttrAggregatorAS, bgp4PathAttrAggregatorAddr, bgp4PathAttrCalcLocalPref, bgp4PathAttrBest, bgp4PathAttrUnknown } STATUS current DESCRIPTION "A collection of objects for managing BGP path entries." Haas & Hares Standards Track [Page 27] RFC 4273 BGP4-MIB January 2006 ::= { bgp4MIBGroups 4 } bgp4MIBTrapGroup NOTIFICATION-GROUP NOTIFICATIONS { bgpEstablished, bgpBackwardTransition } STATUS deprecated DESCRIPTION "A collection of notifications for signaling changes in BGP peer relationships. Obsoleted by bgp4MIBNotificationGroup" ::= { bgp4MIBGroups 5 } bgp4MIBNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { bgpEstablishedNotification, bgpBackwardTransNotification } STATUS current DESCRIPTION "A collection of notifications for signaling changes in BGP peer relationships. Obsoletes bgp4MIBTrapGroup." ::= { bgp4MIBGroups 6 } END 5. Security Considerations This MIB relates to a system providing inter-domain routing. As such, improper manipulation of the objects represented by this MIB may result in denial of service to a large number of end-users. There are several management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects should be considered sensitive or vulnerable in most network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects include: o bgpPeerAdminStatus Improper change of bgpPeerAdminStatus, from start to stop, can cause significant disruption of the connectivity to those portions of the Internet reached via the applicable remote BGP peer. Haas & Hares Standards Track [Page 28] RFC 4273 BGP4-MIB January 2006 o bgpPeerConnectRetryInterval Improper change of this object can cause connections to be disrupted for extremely long time periods when otherwise they would be restored in a relatively short period of time. o bgpPeerHoldTimeConfigured, bgpPeerKeepAliveConfigured Misconfiguration of these objects can make BGP sessions more fragile and less resilient to denial of service attacks on the inter-domain routing system. o bgpPeerMinASOriginationInterval, bgpPeerMinRouteAdvertisementInterval Misconfiguration of these objects may adversely affect global Internet convergence of the routes advertised by this BGP speaker. This may result in long-lived routing loops and blackholes for the portions of the Internet that utilize these routes. There are a number of managed objects in this MIB that contain sensitive information regarding the operation of a network. For example, a BGP peer's local and remote addresses might be sensitive for ISPs who want to keep interface addresses on routers confidential in order to prevent router addresses used for a denial of service attack or spoofing. Therefore, it is important in most environments to control read access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to Haas & Hares Standards Track [Page 29] RFC 4273 BGP4-MIB January 2006 the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. Acknowledgements We would like to acknowledge the assistance of all the members of the Inter-Domain Routing Working Group, and particularly the following individuals: Yakov Rekhter, Juniper Networks Rob Coltun, Redback Guy Almes, Internet2 Jeff Honig, BSDi Marshall T. Rose, Dover Beach Consulting, Inc. Dennis Ferguson, Juniper Networks Matt Mathis, PSC John Krawczyk, Bay Networks Curtis Villamizar, Avici Dave LeRoy, Pencom Systems Paul Traina, Juniper Networks Andrew Partan, MFN Robert Snyder, Cisco Systems Dimitry Haskin, Nortel Peder Chr Norgaard, Telebit Communications A/S Joel Halpern, CTO Longitude Systems, Inc. Nick Thille, RedBack Networks Bert Wijnen, Lucent Shane Wright, NextHop Technologies Mike McFadden, Riverstone Networks, Inc. Jon Saperia, JDS Consulting, Inc. Wayne Tackabury, Gold Wire Technology, Inc. Bill Fenner, AT&T Research RJ Atkinson, Extreme Networks Dan Romascanu, Avaya Mathew Richardson, NextHop Technologies The origin of this document is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)" written by Steve Willis and John Burruss, which was updated by John Chu to support BGP-4 in RFC 1657. The editors wish to acknowledge the fine work of these original authors. Haas & Hares Standards Track [Page 30] RFC 4273 BGP4-MIB January 2006 7. Normative References [BGP4] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [BGP4APP] Rekhter, Y. and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Editors' Addresses Jeffrey Haas NextHop Technologies 825 Victor's Way, Suite 100 Ann Arbor, MI 48103 Phone: +1 734 222-1600 Fax: +1 734 222-1602 EMail: jhaas@nexthop.com Susan Hares NextHop Technologies 825 Victor's Way, Suite 100 Ann Arbor, MI 48103 Phone: +1 734 222-1600 Fax: +1 734 222-1602 EMail: skh@nexthop.com Haas & Hares Standards Track [Page 31] RFC 4273 BGP4-MIB January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Haas & Hares Standards Track [Page 32] snmp-mibs-downloader-1.1/mibrfcs/rfc4292.txt0000644000000000000000000020731111402176072015567 0ustar Network Working Group B. Haberman Request for Comments: 4292 Johns Hopkins University Obsoletes: 2096 April 2006 Category: Standards Track IP Forwarding Table MIB 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096. Table of Contents 1. Introduction ....................................................2 2. Conventions Used In This Document ...............................2 3. The Internet-Standard Management Framework ......................2 4. Overview ........................................................2 4.1. Relationship to Other MIBs .................................3 4.1.1. RFC 1213 ............................................3 4.1.2. RFC 1354 ............................................3 4.1.3. RFC 2096 ............................................3 4.1.4. RFC 2011 and 2465 ...................................3 5. Definitions .....................................................3 6. Security Considerations ........................................30 7. Changes from RFC 2096 ..........................................31 8. Normative References ...........................................32 9. Informative References .........................................32 10. Authors and Acknowledgements ..................................33 Haberman Standards Track [Page 1] RFC 4292 IP Forwarding Table MIB April 2006 1. Introduction This document defines a portion of the Management Information Base (MIB) for use in managing objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. It should be noted that the MIB definition described herein does not support multiple instances based on the same address family type. However, it does support an instance of the MIB per address family. 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Overview The MIB consists of one current table and two current global objects. 1. The object inetCidrRouteNumber indicates the number of current routes. This is primarily to avoid having to read the table in order to determine this number. 2. The object inetCidrRouteDiscards counts the number of valid routes that were discarded from inetCidrRouteTable for any reason. This object replaces the ipRoutingDiscards and ipv6DiscardedRoutes objects. 3. The inetCidrRouteTable provides the ability to display IP version-independent multipath CIDR routes. Haberman Standards Track [Page 2] RFC 4292 IP Forwarding Table MIB April 2006 4.1. Relationship to Other MIBs This MIB definition contains several deprecated and obsolete tables and objects. The following subsections describe the relationship between these objects and other MIB modules. 4.1.1. RFC 1213 The ipRouteTable object was originally defined in RFC 1213 [RFC1213]. It was updated by ipForwardTable in RFC 1354 [RFC1354]. 4.1.2. RFC 1354 The ipForwardTable object replaced the ipRouteTable object from RFC 1213. It was in turn obsoleted by the ipCidrRouteTable defined in RFC 2096 [RFC2096]. In addition, RFC 1354 introduced ipForwardNumber. This object reflects the number of entries found in ipForwardTable. It was obsoleted by ipCidrRouteNumber, defined in RFC 2096. 4.1.3. RFC 2096 In RFC 2096, the ipCidrRouteTable and ipCidrRouteNumber were introduced. The ipCidrRouteTable object supports multipath IP routes having the same network number but differing network masks. The number of entries in that table is reflected in ipCidrRouteNumber. These objects are deprecated by the definitions contained in this MIB definition. 4.1.4. RFC 2011 and 2465 RFC 2011 [RFC2011] contains the ipRoutingDiscards object, which counts the number of valid routes that have been removed from the ipCidrRouteTable object. The corresponding ipv6DiscardedRoutes object is defined in RFC 2465 [RFC2465]. These objects are deprecated in favor of the version-independent object inetCidrRouteDiscards defined in this MIB. 5. Definitions IP-FORWARD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Integer32, Gauge32, Counter32 FROM SNMPv2-SMI RowStatus FROM SNMPv2-TC Haberman Standards Track [Page 3] RFC 4292 IP Forwarding Table MIB April 2006 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndexOrZero FROM IF-MIB ip FROM IP-MIB IANAipRouteProtocol FROM IANA-RTPROTO-MIB InetAddress, InetAddressType, InetAddressPrefixLength, InetAutonomousSystemNumber FROM INET-ADDRESS-MIB; ipForward MODULE-IDENTITY LAST-UPDATED "200602010000Z" ORGANIZATION "IETF IPv6 Working Group http://www.ietf.org/html.charters/ipv6-charter.html" CONTACT-INFO "Editor: Brian Haberman Johns Hopkins University - Applied Physics Laboratory Mailstop 17-S442 11100 Johns Hopkins Road Laurel MD, 20723-6099 USA Phone: +1-443-778-1319 Email: brian@innovationslab.net Send comments to " DESCRIPTION "The MIB module for the management of CIDR multipath IP Routes. Copyright (C) The Internet Society (2006). This version of this MIB module is a part of RFC 4292; see the RFC itself for full legal notices." REVISION "200602010000Z" DESCRIPTION "IPv4/v6 version-independent revision. Minimal changes were made to the original RFC 2096 MIB to allow easy upgrade of existing IPv4 implementations to the version-independent MIB. These changes include: Adding inetCidrRouteDiscards as a replacement for the deprecated ipRoutingDiscards and ipv6DiscardedRoutes objects. Adding a new conformance statement to support the implementation of the IP Forwarding MIB in a read-only mode. Haberman Standards Track [Page 4] RFC 4292 IP Forwarding Table MIB April 2006 The inetCidrRouteTable replaces the IPv4-specific ipCidrRouteTable, its related objects, and related conformance statements. Published as RFC 4292." REVISION "199609190000Z" DESCRIPTION "Revised to support CIDR routes. Published as RFC 2096." REVISION "199207022156Z" DESCRIPTION "Initial version, published as RFC 1354." ::= { ip 24 } inetCidrRouteNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of current inetCidrRouteTable entries that are not invalid." ::= { ipForward 6 } inetCidrRouteDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid route entries discarded from the inetCidrRouteTable. Discarded route entries do not appear in the inetCidrRouteTable. One possible reason for discarding an entry would be to free-up buffer space for other route table entries." ::= { ipForward 8 } -- Inet CIDR Route Table -- The Inet CIDR Route Table deprecates and replaces the -- ipCidrRoute Table currently in the IP Forwarding Table MIB. -- It adds IP protocol independence. inetCidrRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF InetCidrRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Haberman Standards Track [Page 5] RFC 4292 IP Forwarding Table MIB April 2006 "This entity's IP Routing table." REFERENCE "RFC 1213 Section 6.6, The IP Group" ::= { ipForward 7 } inetCidrRouteEntry OBJECT-TYPE SYNTAX InetCidrRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular route to a particular destination, under a particular policy (as reflected in the inetCidrRoutePolicy object). Dynamically created rows will survive an agent reboot. Implementers need to be aware that if the total number of elements (octets or sub-identifiers) in inetCidrRouteDest, inetCidrRoutePolicy, and inetCidrRouteNextHop exceeds 111, then OIDs of column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { inetCidrRouteDestType, inetCidrRouteDest, inetCidrRoutePfxLen, inetCidrRoutePolicy, inetCidrRouteNextHopType, inetCidrRouteNextHop } ::= { inetCidrRouteTable 1 } InetCidrRouteEntry ::= SEQUENCE { inetCidrRouteDestType InetAddressType, inetCidrRouteDest InetAddress, inetCidrRoutePfxLen InetAddressPrefixLength, inetCidrRoutePolicy OBJECT IDENTIFIER, inetCidrRouteNextHopType InetAddressType, inetCidrRouteNextHop InetAddress, inetCidrRouteIfIndex InterfaceIndexOrZero, inetCidrRouteType INTEGER, inetCidrRouteProto IANAipRouteProtocol, inetCidrRouteAge Gauge32, inetCidrRouteNextHopAS InetAutonomousSystemNumber, inetCidrRouteMetric1 Integer32, inetCidrRouteMetric2 Integer32, inetCidrRouteMetric3 Integer32, Haberman Standards Track [Page 6] RFC 4292 IP Forwarding Table MIB April 2006 inetCidrRouteMetric4 Integer32, inetCidrRouteMetric5 Integer32, inetCidrRouteStatus RowStatus } inetCidrRouteDestType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the inetCidrRouteDest address, as defined in the InetAddress MIB. Only those address types that may appear in an actual routing table are allowed as values of this object." REFERENCE "RFC 4001" ::= { inetCidrRouteEntry 1 } inetCidrRouteDest OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination IP address of this route. The type of this address is determined by the value of the inetCidrRouteDestType object. The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { inetCidrRouteEntry 2 } inetCidrRoutePfxLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask to be logical-ANDed with the destination address before being compared to the value in the Haberman Standards Track [Page 7] RFC 4292 IP Forwarding Table MIB April 2006 inetCidrRouteDest field. The values for the index objects inetCidrRouteDest and inetCidrRoutePfxLen must be consistent. When the value of inetCidrRouteDest (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object inetCidrRoutePfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { inetCidrRouteEntry 3 } inetCidrRoutePolicy OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an opaque object without any defined semantics. Its purpose is to serve as an additional index that may delineate between multiple entries to the same destination. The value { 0 0 } shall be used as the default value for this object." ::= { inetCidrRouteEntry 4 } inetCidrRouteNextHopType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the inetCidrRouteNextHop address, as defined in the InetAddress MIB. Value should be set to unknown(0) for non-remote routes. Only those address types that may appear in an actual routing table are allowed as values of this object." REFERENCE "RFC 4001" ::= { inetCidrRouteEntry 5 } inetCidrRouteNextHop OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "On remote routes, the address of the next system en Haberman Standards Track [Page 8] RFC 4292 IP Forwarding Table MIB April 2006 route. For non-remote routes, a zero length string. The type of this address is determined by the value of the inetCidrRouteNextHopType object." ::= { inetCidrRouteEntry 6 } inetCidrRouteIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value that identifies the local interface through which the next hop of this route should be reached. A value of 0 is valid and represents the scenario where no interface is specified." ::= { inetCidrRouteEntry 7 } inetCidrRouteType OBJECT-TYPE SYNTAX INTEGER { other (1), -- not specified by this MIB reject (2), -- route that discards traffic and -- returns ICMP notification local (3), -- local interface remote (4), -- remote destination blackhole(5) -- route that discards traffic -- silently } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of route. Note that local(3) refers to a route for which the next hop is the final destination; remote(4) refers to a route for which the next hop is not the final destination. Routes that do not result in traffic forwarding or rejection should not be displayed, even if the implementation keeps them stored internally. reject(2) refers to a route that, if matched, discards the message as unreachable and returns a notification (e.g., ICMP error) to the message sender. This is used in some protocols as a means of correctly aggregating routes. blackhole(5) refers to a route that, if matched, discards the message silently." ::= { inetCidrRouteEntry 8 } Haberman Standards Track [Page 9] RFC 4292 IP Forwarding Table MIB April 2006 inetCidrRouteProto OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { inetCidrRouteEntry 9 } inetCidrRouteAge OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of 'too old' can be implied, except through knowledge of the routing protocol by which the route was learned." ::= { inetCidrRouteEntry 10 } inetCidrRouteNextHopAS OBJECT-TYPE SYNTAX InetAutonomousSystemNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The Autonomous System Number of the Next Hop. The semantics of this object are determined by the routing- protocol specified in the route's inetCidrRouteProto value. When this object is unknown or not relevant, its value should be set to zero." DEFVAL { 0 } ::= { inetCidrRouteEntry 11 } inetCidrRouteMetric1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The primary routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's inetCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } Haberman Standards Track [Page 10] RFC 4292 IP Forwarding Table MIB April 2006 ::= { inetCidrRouteEntry 12 } inetCidrRouteMetric2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's inetCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { inetCidrRouteEntry 13 } inetCidrRouteMetric3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's inetCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { inetCidrRouteEntry 14 } inetCidrRouteMetric4 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's inetCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { inetCidrRouteEntry 15 } inetCidrRouteMetric5 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- Haberman Standards Track [Page 11] RFC 4292 IP Forwarding Table MIB April 2006 protocol specified in the route's inetCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { inetCidrRouteEntry 16 } inetCidrRouteStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status variable, used according to row installation and removal conventions. A row entry cannot be modified when the status is marked as active(1)." ::= { inetCidrRouteEntry 17 } -- Conformance information ipForwardConformance OBJECT IDENTIFIER ::= { ipForward 5 } ipForwardGroups OBJECT IDENTIFIER ::= { ipForwardConformance 1 } ipForwardCompliances OBJECT IDENTIFIER ::= { ipForwardConformance 2 } -- Compliance statements ipForwardFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented for read-create, the implementation can claim full compliance. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT inetCidrRouteDestType -- SYNTAX InetAddressType (ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)) -- DESCRIPTION -- This MIB requires support for global and -- non-global ipv4 and ipv6 addresses. Haberman Standards Track [Page 12] RFC 4292 IP Forwarding Table MIB April 2006 -- -- OBJECT inetCidrRouteDest -- SYNTAX InetAddress (SIZE (4 | 8 | 16 | 20)) -- DESCRIPTION -- This MIB requires support for global and -- non-global IPv4 and IPv6 addresses. -- -- OBJECT inetCidrRouteNextHopType -- SYNTAX InetAddressType (unknown(0), ipv4(1), -- ipv6(2), ipv4z(3) -- ipv6z(4)) -- DESCRIPTION -- This MIB requires support for global and -- non-global ipv4 and ipv6 addresses. -- -- OBJECT inetCidrRouteNextHop -- SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20)) -- DESCRIPTION -- This MIB requires support for global and -- non-global IPv4 and IPv6 addresses. " MODULE -- this module MANDATORY-GROUPS { inetForwardCidrRouteGroup } OBJECT inetCidrRouteStatus SYNTAX RowStatus { active(1), notInService (2) } WRITE-SYNTAX RowStatus { active(1), notInService (2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait is not required." ::= { ipForwardCompliances 3 } ipForwardReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read- create (i.e., in read-only mode), the implementation can claim read-only compliance." MODULE -- this module MANDATORY-GROUPS { inetForwardCidrRouteGroup } OBJECT inetCidrRouteIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteType Haberman Standards Track [Page 13] RFC 4292 IP Forwarding Table MIB April 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteNextHopAS MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteMetric1 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteMetric2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteMetric3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteMetric4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteMetric5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT inetCidrRouteStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { ipForwardCompliances 4 } -- units of conformance inetForwardCidrRouteGroup OBJECT-GROUP OBJECTS { inetCidrRouteDiscards, inetCidrRouteIfIndex, inetCidrRouteType, inetCidrRouteProto, inetCidrRouteAge, Haberman Standards Track [Page 14] RFC 4292 IP Forwarding Table MIB April 2006 inetCidrRouteNextHopAS, inetCidrRouteMetric1, inetCidrRouteMetric2, inetCidrRouteMetric3, inetCidrRouteMetric4, inetCidrRouteMetric5, inetCidrRouteStatus, inetCidrRouteNumber } STATUS current DESCRIPTION "The IP version-independent CIDR Route Table." ::= { ipForwardGroups 4 } -- Deprecated Objects ipCidrRouteNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of current ipCidrRouteTable entries that are not invalid. This object is deprecated in favor of inetCidrRouteNumber and the inetCidrRouteTable." ::= { ipForward 3 } -- IP CIDR Route Table -- The IP CIDR Route Table obsoletes and replaces the ipRoute -- Table current in MIB-I and MIB-II and the IP Forwarding Table. -- It adds knowledge of the autonomous system of the next hop, -- multiple next hops, policy routing, and Classless -- Inter-Domain Routing. ipCidrRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IpCidrRouteEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This entity's IP Routing table. This table has been deprecated in favor of the IP version neutral inetCidrRouteTable." REFERENCE "RFC 1213 Section 6.6, The IP Group" ::= { ipForward 4 } ipCidrRouteEntry OBJECT-TYPE SYNTAX IpCidrRouteEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A particular route to a particular destination, under a Haberman Standards Track [Page 15] RFC 4292 IP Forwarding Table MIB April 2006 particular policy." INDEX { ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos, ipCidrRouteNextHop } ::= { ipCidrRouteTable 1 } IpCidrRouteEntry ::= SEQUENCE { ipCidrRouteDest IpAddress, ipCidrRouteMask IpAddress, ipCidrRouteTos Integer32, ipCidrRouteNextHop IpAddress, ipCidrRouteIfIndex Integer32, ipCidrRouteType INTEGER, ipCidrRouteProto INTEGER, ipCidrRouteAge Integer32, ipCidrRouteInfo OBJECT IDENTIFIER, ipCidrRouteNextHopAS Integer32, ipCidrRouteMetric1 Integer32, ipCidrRouteMetric2 Integer32, ipCidrRouteMetric3 Integer32, ipCidrRouteMetric4 Integer32, ipCidrRouteMetric5 Integer32, ipCidrRouteStatus RowStatus } ipCidrRouteDest OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The destination IP address of this route. This object may not take a Multicast (Class D) address value. Any assignment (implicit or otherwise) of an instance of this object to a value x must be rejected if the bitwise logical-AND of x with the value of the corresponding instance of the ipCidrRouteMask object is not equal to x." ::= { ipCidrRouteEntry 1 } ipCidrRouteMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only Haberman Standards Track [Page 16] RFC 4292 IP Forwarding Table MIB April 2006 STATUS deprecated DESCRIPTION "Indicate the mask to be logical-ANDed with the destination address before being compared to the value in the ipCidrRouteDest field. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the ipCidrRouteMask by reference to the IP Address Class. Any assignment (implicit or otherwise) of an instance of this object to a value x must be rejected if the bitwise logical-AND of x with the value of the corresponding instance of the ipCidrRouteDest object is not equal to ipCidrRouteDest." ::= { ipCidrRouteEntry 2 } -- The following convention is included for specification -- of TOS Field contents. At this time, the Host Requirements -- and the Router Requirements documents disagree on the width -- of the TOS field. This mapping describes the Router -- Requirements mapping, and leaves room to widen the TOS field -- without impact to fielded systems. ipCidrRouteTos OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The policy specifier is the IP TOS Field. The encoding of IP TOS is as specified by the following convention. Zero indicates the default path if no more specific policy applies. +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TYPE OF SERVICE | 0 | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ IP TOS IP TOS Field Policy Field Policy Contents Code Contents Code 0 0 0 0 ==> 0 0 0 0 1 ==> 2 0 0 1 0 ==> 4 0 0 1 1 ==> 6 0 1 0 0 ==> 8 0 1 0 1 ==> 10 0 1 1 0 ==> 12 0 1 1 1 ==> 14 1 0 0 0 ==> 16 1 0 0 1 ==> 18 1 0 1 0 ==> 20 1 0 1 1 ==> 22 Haberman Standards Track [Page 17] RFC 4292 IP Forwarding Table MIB April 2006 1 1 0 0 ==> 24 1 1 0 1 ==> 26 1 1 1 0 ==> 28 1 1 1 1 ==> 30" ::= { ipCidrRouteEntry 3 } ipCidrRouteNextHop OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "On remote routes, the address of the next system en route; Otherwise, 0.0.0.0." ::= { ipCidrRouteEntry 4 } ipCidrRouteIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The ifIndex value that identifies the local interface through which the next hop of this route should be reached." DEFVAL { 0 } ::= { ipCidrRouteEntry 5 } ipCidrRouteType OBJECT-TYPE SYNTAX INTEGER { other (1), -- not specified by this MIB reject (2), -- route that discards traffic local (3), -- local interface remote (4) -- remote destination } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The type of route. Note that local(3) refers to a route for which the next hop is the final destination; remote(4) refers to a route for which the next hop is not the final destination. Routes that do not result in traffic forwarding or rejection should not be displayed, even if the implementation keeps them stored internally. reject (2) refers to a route that, if matched, discards the message as unreachable. This is used in some protocols as a means of correctly aggregating routes." ::= { ipCidrRouteEntry 6 } Haberman Standards Track [Page 18] RFC 4292 IP Forwarding Table MIB April 2006 ipCidrRouteProto OBJECT-TYPE SYNTAX INTEGER { other (1), -- not specified local (2), -- local interface netmgmt (3), -- static route icmp (4), -- result of ICMP Redirect -- the following are all dynamic -- routing protocols egp (5), -- Exterior Gateway Protocol ggp (6), -- Gateway-Gateway Protocol hello (7), -- FuzzBall HelloSpeak rip (8), -- Berkeley RIP or RIP-II isIs (9), -- Dual IS-IS esIs (10), -- ISO 9542 ciscoIgrp (11), -- Cisco IGRP bbnSpfIgp (12), -- BBN SPF IGP ospf (13), -- Open Shortest Path First bgp (14), -- Border Gateway Protocol idpr (15), -- InterDomain Policy Routing ciscoEigrp (16) -- Cisco EIGRP } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { ipCidrRouteEntry 7 } ipCidrRouteAge OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied, except through knowledge of the routing protocol by which the route was learned." DEFVAL { 0 } ::= { ipCidrRouteEntry 8 } ipCidrRouteInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create Haberman Standards Track [Page 19] RFC 4292 IP Forwarding Table MIB April 2006 STATUS deprecated DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol that is responsible for this route, as determined by the value specified in the route's ipCidrRouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntactically valid object identifier, and any implementation conforming to ASN.1 and the Basic Encoding Rules must be able to generate and recognize this value." ::= { ipCidrRouteEntry 9 } ipCidrRouteNextHopAS OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The Autonomous System Number of the Next Hop. The semantics of this object are determined by the routing- protocol specified in the route's ipCidrRouteProto value. When this object is unknown or not relevant, its value should be set to zero." DEFVAL { 0 } ::= { ipCidrRouteEntry 10 } ipCidrRouteMetric1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The primary routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipCidrRouteEntry 11 } ipCidrRouteMetric2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipCidrRouteProto value. If this metric is not used, its value should be Haberman Standards Track [Page 20] RFC 4292 IP Forwarding Table MIB April 2006 set to -1." DEFVAL { -1 } ::= { ipCidrRouteEntry 12 } ipCidrRouteMetric3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipCidrRouteEntry 13 } ipCidrRouteMetric4 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipCidrRouteEntry 14 } ipCidrRouteMetric5 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipCidrRouteProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipCidrRouteEntry 15 } ipCidrRouteStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION Haberman Standards Track [Page 21] RFC 4292 IP Forwarding Table MIB April 2006 "The row status variable, used according to row installation and removal conventions." ::= { ipCidrRouteEntry 16 } -- compliance statements ipForwardCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMPv2 entities that implement the ipForward MIB. This compliance statement has been deprecated and replaced with ipForwardFullCompliance and ipForwardReadOnlyCompliance." MODULE -- this module MANDATORY-GROUPS { ipForwardCidrRouteGroup } ::= { ipForwardCompliances 1 } -- units of conformance ipForwardCidrRouteGroup OBJECT-GROUP OBJECTS { ipCidrRouteNumber, ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos, ipCidrRouteNextHop, ipCidrRouteIfIndex, ipCidrRouteType, ipCidrRouteProto, ipCidrRouteAge, ipCidrRouteInfo,ipCidrRouteNextHopAS, ipCidrRouteMetric1, ipCidrRouteMetric2, ipCidrRouteMetric3, ipCidrRouteMetric4, ipCidrRouteMetric5, ipCidrRouteStatus } STATUS deprecated DESCRIPTION "The CIDR Route Table. This group has been deprecated and replaced with inetForwardCidrRouteGroup." ::= { ipForwardGroups 3 } -- Obsoleted Definitions - Objects ipForwardNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION Haberman Standards Track [Page 22] RFC 4292 IP Forwarding Table MIB April 2006 "The number of current ipForwardTable entries that are not invalid." ::= { ipForward 1 } -- IP Forwarding Table -- The IP Forwarding Table obsoletes and replaces the ipRoute -- Table current in MIB-I and MIB-II. It adds knowledge of -- the autonomous system of the next hop, multiple next hop -- support, and policy routing support. ipForwardTable OBJECT-TYPE SYNTAX SEQUENCE OF IpForwardEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "This entity's IP Routing table." REFERENCE "RFC 1213 Section 6.6, The IP Group" ::= { ipForward 2 } ipForwardEntry OBJECT-TYPE SYNTAX IpForwardEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "A particular route to a particular destination, under a particular policy." INDEX { ipForwardDest, ipForwardProto, ipForwardPolicy, ipForwardNextHop } ::= { ipForwardTable 1 } IpForwardEntry ::= SEQUENCE { ipForwardDest IpAddress, ipForwardMask IpAddress, ipForwardPolicy Integer32, ipForwardNextHop IpAddress, ipForwardIfIndex Integer32, ipForwardType INTEGER, ipForwardProto INTEGER, ipForwardAge Integer32, ipForwardInfo OBJECT IDENTIFIER, ipForwardNextHopAS Integer32, ipForwardMetric1 Integer32, Haberman Standards Track [Page 23] RFC 4292 IP Forwarding Table MIB April 2006 ipForwardMetric2 Integer32, ipForwardMetric3 Integer32, ipForwardMetric4 Integer32, ipForwardMetric5 Integer32 } ipForwardDest OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The destination IP address of this route. An entry with a value of 0.0.0.0 is considered a default route. This object may not take a Multicast (Class D) address value. Any assignment (implicit or otherwise) of an instance of this object to a value x must be rejected if the bitwise logical-AND of x with the value of the corresponding instance of the ipForwardMask object is not equal to x." ::= { ipForwardEntry 1 } ipForwardMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS obsolete DESCRIPTION "Indicate the mask to be logical-ANDed with the destination address before being compared to the value in the ipForwardDest field. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the ipForwardMask by reference to the IP Address Class. Any assignment (implicit or otherwise) of an instance of this object to a value x must be rejected if the bitwise logical-AND of x with the value of the corresponding instance of the ipForwardDest object is not equal to ipForwardDest." DEFVAL { '00000000'H } -- 0.0.0.0 ::= { ipForwardEntry 2 } -- The following convention is included for specification -- of TOS Field contents. At this time, the Host Requirements -- and the Router Requirements documents disagree on the width -- of the TOS field. This mapping describes the Router Haberman Standards Track [Page 24] RFC 4292 IP Forwarding Table MIB April 2006 -- Requirements mapping, and leaves room to widen the TOS field -- without impact to fielded systems. ipForwardPolicy OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The general set of conditions that would cause the selection of one multipath route (set of next hops for a given destination) is referred to as 'policy'. Unless the mechanism indicated by ipForwardProto specifies otherwise, the policy specifier is the IP TOS Field. The encoding of IP TOS is as specified by the following convention. Zero indicates the default path if no more specific policy applies. +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TYPE OF SERVICE | 0 | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ IP TOS IP TOS Field Policy Field Policy Contents Code Contents Code 0 0 0 0 ==> 0 0 0 0 1 ==> 2 0 0 1 0 ==> 4 0 0 1 1 ==> 6 0 1 0 0 ==> 8 0 1 0 1 ==> 10 0 1 1 0 ==> 12 0 1 1 1 ==> 14 1 0 0 0 ==> 16 1 0 0 1 ==> 18 1 0 1 0 ==> 20 1 0 1 1 ==> 22 1 1 0 0 ==> 24 1 1 0 1 ==> 26 1 1 1 0 ==> 28 1 1 1 1 ==> 30 Protocols defining 'policy' otherwise must either define a set of values that are valid for this object or must implement an integer-instanced policy table for which this object's value acts as an index." ::= { ipForwardEntry 3 } ipForwardNextHop OBJECT-TYPE Haberman Standards Track [Page 25] RFC 4292 IP Forwarding Table MIB April 2006 SYNTAX IpAddress MAX-ACCESS read-only STATUS obsolete DESCRIPTION "On remote routes, the address of the next system en route; otherwise, 0.0.0.0." ::= { ipForwardEntry 4 } ipForwardIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS obsolete DESCRIPTION "The ifIndex value that identifies the local interface through which the next hop of this route should be reached." DEFVAL { 0 } ::= { ipForwardEntry 5 } ipForwardType OBJECT-TYPE SYNTAX INTEGER { other (1), -- not specified by this MIB invalid (2), -- logically deleted local (3), -- local interface remote (4) -- remote destination } MAX-ACCESS read-create STATUS obsolete DESCRIPTION "The type of route. Note that local(3) refers to a route for which the next hop is the final destination; remote(4) refers to a route for which the next hop is not the final destination. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipForwardTable object. That is, it effectively disassociates the destination identified with said entry from the route identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipForwardType object." DEFVAL { invalid } ::= { ipForwardEntry 6 } Haberman Standards Track [Page 26] RFC 4292 IP Forwarding Table MIB April 2006 ipForwardProto OBJECT-TYPE SYNTAX INTEGER { other (1), -- not specified local (2), -- local interface netmgmt (3), -- static route icmp (4), -- result of ICMP Redirect -- the following are all dynamic -- routing protocols egp (5), -- Exterior Gateway Protocol ggp (6), -- Gateway-Gateway Protocol hello (7), -- FuzzBall HelloSpeak rip (8), -- Berkeley RIP or RIP-II is-is (9), -- Dual IS-IS es-is (10), -- ISO 9542 ciscoIgrp (11), -- Cisco IGRP bbnSpfIgp (12), -- BBN SPF IGP ospf (13), -- Open Shortest Path First bgp (14), -- Border Gateway Protocol idpr (15) -- InterDomain Policy Routing } MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { ipForwardEntry 7 } ipForwardAge OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS obsolete DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned." DEFVAL { 0 } ::= { ipForwardEntry 8 } ipForwardInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS obsolete Haberman Standards Track [Page 27] RFC 4292 IP Forwarding Table MIB April 2006 DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol that is responsible for this route, as determined by the value specified in the route's ipForwardProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntactically valid object identifier, and any implementation conforming to ASN.1 and the Basic Encoding Rules must be able to generate and recognize this value." ::= { ipForwardEntry 9 } ipForwardNextHopAS OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS obsolete DESCRIPTION "The Autonomous System Number of the Next Hop. When this is unknown or not relevant to the protocol indicated by ipForwardProto, zero." DEFVAL { 0 } ::= { ipForwardEntry 10 } ipForwardMetric1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS obsolete DESCRIPTION "The primary routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 11 } ipForwardMetric2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS obsolete DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 12 } Haberman Standards Track [Page 28] RFC 4292 IP Forwarding Table MIB April 2006 ipForwardMetric3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS obsolete DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 13 } ipForwardMetric4 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS obsolete DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 14 } ipForwardMetric5 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS obsolete DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing- protocol specified in the route's ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 15 } -- Obsoleted Definitions - Groups -- compliance statements ipForwardOldCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement for SNMP entities that implement the ipForward MIB." Haberman Standards Track [Page 29] RFC 4292 IP Forwarding Table MIB April 2006 MODULE -- this module MANDATORY-GROUPS { ipForwardMultiPathGroup } ::= { ipForwardCompliances 2 } ipForwardMultiPathGroup OBJECT-GROUP OBJECTS { ipForwardNumber, ipForwardDest, ipForwardMask, ipForwardPolicy, ipForwardNextHop, ipForwardIfIndex, ipForwardType, ipForwardProto, ipForwardAge, ipForwardInfo, ipForwardNextHopAS, ipForwardMetric1, ipForwardMetric2, ipForwardMetric3, ipForwardMetric4, ipForwardMetric5 } STATUS obsolete DESCRIPTION "IP Multipath Route Table." ::= { ipForwardGroups 2 } END 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: 1. The inetCidrRouteTable contains routing and forwarding information that is critical to the operation of the network node (especially routers). Allowing unauthenticated write access to this table can compromise the validity of the forwarding information. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: 1. The inetCidrRouteTable contains routing and forwarding information that can be used to compromise a network. Haberman Standards Track [Page 30] RFC 4292 IP Forwarding Table MIB April 2006 Specifically, this table can be used to construct a map of the network in preparation for a denial-of-service attack on the network infrastructure. 2. The inetCidrRouteProto object identifies the routing protocols in use within a network. This information can be used to determine how a denial-of-service attack should be launched. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Changes from RFC 2096 This document obsoletes RFC 2096 in the following ways: 1. Replaces ipCidrRouteTable with inetCidrRouteTable. This applies to corresponding objects and conformance statements. 2. Utilizes the InetAddress TC to support IP version-independent implementations of the forwarding MIB. This gives common forwarding MIB support for IPv4 and IPv6. 3. Creates a read-only conformance statement to support implementations that only wish to retrieve data. 4. Creates the inetCidrRouteDiscards object to replace the deprecated ipRoutingDiscards and ipv6DiscardedRoutes objects. The inetCidrRouteTable retains the logical structure of the ipCidrRouteTable in order to allow the easy upgrade of existing IPv4 implementations to the version-independent MIB. Haberman Standards Track [Page 31] RFC 4292 IP Forwarding Table MIB April 2006 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP), RFC 4293, April 2006. [RTPROTO] IANA, "IP Route Protocol MIB", http://www.iana.org/assignments/ianaiprouteprotocol-mib, September 2000. 9. Informative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, March 1991. [RFC1354] Baker, F., "IP Forwarding Table MIB", RFC 1354, July 1992. [RFC2011] McCloghrie, K., Editor, "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996. [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Haberman Standards Track [Page 32] RFC 4292 IP Forwarding Table MIB April 2006 [RFC2465] Haskin, D. and S. Onishi, Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998. 10. Authors and Acknowledgements This document was based on RFC 2096 [RFC2096]. The following people provided text for this version of the document, or were authors of previous versions: Fred Baker, Cisco Bill Fenner, AT&T Research Brian Haberman, Johns Hopkins University - Applied Physics Laboratory Juergen Schoenwalder, TU Braunschweig Dave Thaler, Microsoft Margaret Wasserman, Thingmagic Dario Accornero, Mark Adam, Qing Li, and Shawn Routhier reviewed the document and provided helpful feedback. Mike Heard provided valuable feedback as the MIB Doctor for this document. Editors' Contact Information Comments or questions regarding this document should be sent to: Brian Haberman Johns Hopkins University - Applied Physics Laboratory Mailstop 17-S442 11100 Johns Hopkins Road Laurel MD, 20723-6099 USA Phone: +1-443-778-1319 EMail: brian@innovationslab.net Haberman Standards Track [Page 33] RFC 4292 IP Forwarding Table MIB April 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Haberman Standards Track [Page 34] snmp-mibs-downloader-1.1/mibrfcs/rfc4293.txt0000644000000000000000000073110311402176072015571 0ustar Network Working Group S. Routhier, Ed. Request for Comments: 4293 April 2006 Obsoletes: 2011, 2465, 2466 Category: Standards Track Management Information Base for the Internet Protocol (IP) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. Routhier, Ed. Standards Track [Page 1] RFC 4293 IP MIB April 2006 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Revision History ................................................3 3. Overview ........................................................3 3.1. Multi-Stack Implementations ................................3 3.2. Discussion of Tables and Groups ............................3 3.2.1. General Objects .....................................4 3.2.2. Interface Tables ....................................4 3.2.3. IP Statistics Tables ................................4 3.2.4. Internet Address Prefix Table .......................8 3.2.5. Internet Address Table ..............................8 3.2.6. Internet Address Translation Table ..................9 3.2.7. IPv6 Scope Zone Index Table .........................9 3.2.8. Default Router Table ................................9 3.2.9. Router Advertisement Table ..........................9 3.2.10. ICMP Statistics Tables .............................9 3.2.11. Conformance and Compliance ........................10 3.2.12. Deprecated Objects ................................10 4. Updating Implementations .......................................10 4.1. Updating an Implementation of the IPv4-only IP-MIB ........11 4.2. Updating an Implementation of the IPv6-MIB ................12 5. Definitions ....................................................13 6. Previous Work .................................................116 7. References ....................................................116 7.1. Normative References .....................................116 7.2. Informative References ...................................117 8. Security Considerations .......................................118 9. Acknowledgements ..............................................120 10. Authors ......................................................120 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [9]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3]. Routhier, Ed. Standards Track [Page 2] RFC 4293 IP MIB April 2006 2. Revision History One of the primary purposes of this revision of the IP MIB is to create a single set of objects to describe and manage IP modules in an IP version independent manner. Where RFCs 2465 and 2466 created a set of objects independent from RFC 2011, this document merges those three documents into a single unified set of objects. The ipSystemStatsTable and ipIfStatsTable tables are examples of updating objects to be independent of IP version. Both of these tables contain counters to reflect IP traffic statistics that originated in much earlier MIBs and both include an IP address type in order to separate the information based on IP version. Another purpose of this document is to increase the manageability of a node running IPv6 by adding new objects. Some of these tables, such as ipDefaultRouterTable, may be useful on both IPv4 and IPv6 nodes while others, such as ipv6RouterAdvertTable, are specific to a single protocol. 3. Overview 3.1. Multi-Stack Implementations This MIB does not provide native support for implementations of multiple stacks sharing the same address type. One option for supporting such designs is to assign each stack within an address type to a separate context. These contexts could then be selected based upon the context name, with the Entity MIB and View-based Access Control Model (VACM) Context Table providing methods for listing the supported contexts. 3.2. Discussion of Tables and Groups This MIB is composed of a small number of discrete objects and a series of tables meant to form the base for managing IPv4 and IPv6 entities. While some of the objects are meant to be included in all entities, some of the objects are only conditionally mandatory. The unconditionally mandatory objects are mostly counters for IP and ICMP statistics. The conditionally mandatory objects fall into one of several groups: objects for use in higher bandwidth situations, objects for use with IPv4, objects for use with IPv6, and objects for use on IPv6 routers. In short, it is not expected that every entity will implement all of the objects within this MIB. The reader should consult the conformance and compliance section to determine which objects are appropriate for a given entity. Routhier, Ed. Standards Track [Page 3] RFC 4293 IP MIB April 2006 3.2.1. General Objects In both IPv4 and IPv6, there are only a small number of "knobs" for controlling the general IP stack. Most controls will be in a more specific setting, such as for controlling a router or TCP engine. This MIB defines a total of three general knobs, only two of which are used for both IPv4 and IPv6. Objects are included for both protocols to enable or disable forwarding and to set limits on the lifetime of a packet (ttl or hop count). The third knob, the timeout period for reassembling fragments, is only defined for IPv4, as IPv6 specifies this value directly. Each group of objects is required when implementing their respective protocols. 3.2.2. Interface Tables This MIB includes a pair of tables to convey information about the IPv4 and IPv6 protocols that is interface specific. Special note should be taken of the administrative status objects. These are defined to allow each protocol to selectively enable or disable interfaces. These objects can be used in conjunction with the ifAdminStatus object to manipulate the interfaces as necessary. With these three objects, an interface may be enabled or disabled completely, as well as connected to the IPv4 stack, the IPv6 stack or both stacks. Setting ifAdminStatus to "down" should not affect the protocol specific status objects. Each interface table is required when implementing their respective protocols. 3.2.3. IP Statistics Tables The IP statistics tables (ipSystemStatsTable and ipIfStatsTable) contain objects to count the number of datagrams and octets that a given entity has processed. Unlike the previous attempt, this document uses a single table for multiple address types. Typically the only two types of interest are IPv4 and IPv6; however, the table can support other types if necessary. The first table, ipSystemStatsTable, conveys system wide information. (That is, the various counters are for all interfaces and not a specific set of interfaces.) Its index is formed from a single Routhier, Ed. Standards Track [Page 4] RFC 4293 IP MIB April 2006 sub-id that represents the address type for which the statistics were counted. The second table, ipIfStatsTable, conveys interface specific information. Its index is formed from two sub-ids. The first represents the address type (IPv4 and IPv6), and the interface within that address type is represented by the second sub-id. The two tables have a similar set of objects that are intended to count the same things, except for the difference in granularity. The object ID "ipSystemStatsEntry.2" is reserved in order to align the object IDs of the counters in the first table with their counterparts in the second table. Several objects to note are ipSystemStatsDiscontinuityTime, ipIfStatsDiscontinuityTime, ipSystemsStatsRefreshRate, and ipIfStatsRefreshRate. These objects provide information about the row in the table more than about the system itself. The discontinuity objects allow a management entity to determine if a discontinuity event that would invalidate the management entity's understanding of the counters has occurred. The system being re- initialized or the interface being cycled are possible examples of a discontinuity event. The refresh objects allow a management entity to determine a proper polling interval for the rest of the objects. The following Case diagram represents the general ordering of the packet counters. In order to avoid extra clutter, the prefixes "ipSystemStats" and "ipIfStats" have been removed from each of the counter names. Routhier, Ed. Standards Track [Page 5] RFC 4293 IP MIB April 2006 from from interface upper layers V V | | + InReceives (1) + OutRequests | | | | +--> InHdrErrors (5) +--> OutNoRoutes | | | | +->-+ InMcastPkts (1) | | V | +-<-+ | | | +->-+ InBcastPkts (1) | | V | +-<-+ | | | | | +--> InTruncatedPkts (5) | | | | | +--> InAddrErrors | | | | | +--> InDiscards (2) | | | | | Routhier, Ed. Standards Track [Page 6] RFC 4293 IP MIB April 2006 +--------+------->------+----->-----+----->-----+ | InForwDatagrams (6) | OutForwDatagrams (6)| | V +->-+ OutFragReqds | InNoRoutes | | (packets) / (local packet (3) | | | IF is that of the address | +--> OutFragFails | and may not be the receiving IF) | | (packets) | | | | | V OutFragOks | | | (packets) (7) | | | +->-+ ReasmReqds (fragments) +-<-+ OutFragCreates | | | (fragments) | | | | +--> ReasmFails (fragments (4)) +->-+ OutMcastPkts (1) | | | V | | +-<-+ +-<-+ ReasmOKs (reassembled packets) | | +->-+ OutBcastPkts (1) | | V +--> InUnknownProtos +-<-+ | | | | +--> InDiscards (2) +--> OutDiscards (2) | | | | + InDelivers + OutTransmits (1) | | V V to to upper interface layers (1) The HC counters and octet counters are also found at these points but have been left out for clarity. (2) The discard counters may increment at any time in the processing path. Packets discarded to the left of InNoRoutes cause the InDiscards counter to increment, while those discarded to the right are counted in the OutDiscards counters. (3) Local packets on the input side are counted on the interface associated with their destination address, which may not be the interface on which they were received. This requirement is caused by the possibility of losing the original interface during processing, especially re-assembly. Routhier, Ed. Standards Track [Page 7] RFC 4293 IP MIB April 2006 (4) Some re-assembly algorithms may lose track of the number of fragments during processing and so some fragments may not be counted in this object. (5) InTruncatedPkts should only be incremented if the frame contained a valid header but was otherwise shorter than required. Frames that are too short to contain a valid header should be counted as InHdrErrors. (6) The forwarding objects may be incremented, even for packets that originated locally or are destined for the local host, if their addresses are such that the local host would need to forward the packet to pass it to the correct interface. (7) When fragmenting a packet, an entity should increment the OutFragFails counter, rather than the OutDiscards counter, in order to preserve the equation FragOks + FragFails == FragRqds. The objects in both tables are spread amongst several conformance groups based on the bandwidth required to wrap the counters within an hour. The base system group is mandatory for all entities. The other system groups are optional depending on bandwidth. The interface specific-groups are optional. 3.2.4. Internet Address Prefix Table This table provides information about the prefixes this entity is using, including their lifetimes. This table provides a convenient place to which other tables that make use of prefixes, such as the ipAddressTable, may point. By including this table, the MIB can supply the prefix information for all addresses, yet minimize the amount of duplication required in storing and accessing this data. This arrangement also clarifies the relationship between addresses that have the same prefix. This table is required for IPv6 entities. 3.2.5. Internet Address Table This table lists the IP addresses (both IPv4 and IPv6) used by this entity. It also includes some basic information about how and when the address was formed and last updated. This table allows a manager to determine who a given entity thinks it is. This table is required for all IP entities. Routhier, Ed. Standards Track [Page 8] RFC 4293 IP MIB April 2006 3.2.6. Internet Address Translation Table This table provides a mapping between IP layer addresses and physical addresses as would be formed by either Address Resolution Protocol (ARP) for IPv4 or the neighbor discovery protocol for IPv6. 3.2.7. IPv6 Scope Zone Index Table This table specifies the zone index to interface mapping. By examining the table, a manager can determine which groups of interfaces are within a particular zone for a given scope. The zone index information is only valid within a given entity; the indexes used on one entity may not be comparable to those used on a different entity. This table is required for IPv6 entities. 3.2.8. Default Router Table This table lists the default routers known to this entity. This table is intended to be a simple list to display the information that end nodes may have been configured with or acquired through a simple system such as IPv6 router advertisements. Managers attempting to view more complicated routing information should examine the routing specific tables from other MIBs. This table is required for all entities. 3.2.9. Router Advertisement Table This table contains the non-routing information that an IPv6 router would use in constructing a router advertisement message. It does not contain information about the prefixes or other routing specific information that the router might advertise. The router should acquire such information from either the routing tables or from some routing table specific MIB. This table is only required for IPv6 router entities. 3.2.10. ICMP Statistics Tables There are two sets of statistics for ICMP. The first contains a simple set of counters to track the number of ICMP messages and errors processed by this entity. Routhier, Ed. Standards Track [Page 9] RFC 4293 IP MIB April 2006 The second supplies more detail about the ICMP messages processed by this entity. Its index is formed from two sub-ids. The first represents the address type (IPv4 and IPv6), and the second represents the particular message type being counted. A given row need not be instantiated unless a message of that type has been processed, i.e., the row for icmpMsgStatsType=X MAY be instantiated before but MUST be instantated after the first message with Type=X is received or transmitted. After receiving or transmitting any succeeding messages with Type=X, the relevant counter must be incremented. Both of these tables are required for all entities. 3.2.11. Conformance and Compliance This MIB contains several sets of objects. Some of these sets are useful on all types of entities, while others are only useful on a limited subset of entities. The conformance section attempts to group the objects into sets that may be discussed as units, and the compliance section then details which of these units are required in various circumstances. The circumstances used in the compliance section are implementing IPv4, IPv6, or IPv6 router functions and having a bandwidth of less than 20MB, between 20MB and 650MB, or greater than 650MB. 3.2.12. Deprecated Objects This MIB also includes a set of deprecated objects from previous iterations. They are included as part of the historical record. 4. Updating Implementations There are several general classes of change that are required. The first and most major change is that most of the previous objects have different object IDs and additional indexes to support the possibility of different address types. The general counters for IP and ICMP are examples of this. They have been moved to the ipSystemStatsTable and icmpMsgStatsTable, respectively. The second change is the extension of all address objects to allow for both IPv4 and IPv6 addresses and the addition of an address type object to specify what address type is in use. The third change is the addition of several new objects to the replacement for a previously existing table such as ipNetToPhysical. Routhier, Ed. Standards Track [Page 10] RFC 4293 IP MIB April 2006 The fourth change is the addition of completely new tables such as ipIfStatsTable and ipDefaultRouterTable. The first is based on the previous statistics groups, while the second is completely new to this MIB. 4.1. Updating an Implementation of the IPv4-only IP-MIB The somewhat more specific changes that are required for IPv4 follow. Note well: this is not meant to be an exhaustive list and the reader should examine the MIB for full details. Several of the general objects (ipForwarding, ipDefaultTTL, ipReasmTimeout) remain unchanged. Most of the rest of the general objects were counters and have been moved into the ipSystemStatsTable. The basic instrumentation should remain the same, though the object definitions should be checked for clarifications. If they aren't already in a structure, putting the counter variables in one would be useful. Several new objects have been added to count additional items, and instrumentation code must be added for these objects. Finally, the SNMP routines must be updated to handle the new indexing. In addition to the ipSystemStatsTable, the MIB includes the ipIfStatsTable. This table counts the same items as the system table but does so on a per interface basis. It is optional and may be ignored. If you decide to implement it, you may wish to arrange to collect the data on a per-interface basis and then sum those counters in order to provide the aggregate system level statistics. However, if you choose to provide the system level statistics by summing the interface level counters, no interface level statistics can be lost - if an interface is removed, the statistics associated with it must be retained. The ipAddrTable has, loosely, been converted to the ipAddressTable. While the general idea remains the same, the ipAddressTable is sufficiently different that writing new code may be easier than updating old code. The primary difference is the addition of several new objects. In addition, the ipAdEntReasmMaxSize has been moved to another table, ipv4InterfaceTable. As above, the SNMP routines will need to be updated to handle the new indexing. The ipNetToMediaTable has been moved to the ipNetToPhysicalTable. These tables are fairly similar and updating the old code may be straightforward. As above, the SNMP routines will need to be updated to handle the new indexing. Routhier, Ed. Standards Track [Page 11] RFC 4293 IP MIB April 2006 Two new tables, ipv4InterfaceTable and ipDefaultRouterTable, are required as well as several new ICMP counters. Finally, there are several tables that are required for IPv6 but are optional for IPv4 that you may elect to implement. 4.2. Updating an Implementation of the IPv6-MIB The somewhat more specific changes that are required for IPv6 follow. Note well: this is not meant to be an exhaustive list and the reader should examine the MIB for full details. Two of the general objects, ipv6Forwarding and ipv6DefaultHopLimit, have been renamed and given new object identifiers within the ip branch but are otherwise unchanged. The new names are ipv6IpForwarding and ipv6IpDefaultHopLimit. While there is an ipv6InterfaceTable that contains some of the pieces from the ipv6IfTable, the two are somewhat different in concept. The ipv6IfTable was meant to replicate the ifTable while the ipv6InterfaceTable is meant to be an addition to the ifTable. As such, items that were duplicated between the ifTable and ipv6IfTable have been removed and some new objects added. The ipv6IfStatsTable most closely resembles the ipIfStatsTable with an additional index for the address type and most of the instrumentation should be re-usable. Some new objects have been added to the ipIfStatsTable. As above, the SNMP routines will need to be updated to handle the new indexing. Finally, the ipIfStatsTable is optional and may be ignored. The ipSystemStatsTable is effectively new, but it may be able to make use of most of the instrumentation from the old ipv6IfStatsTable. As with the IPv4 discussion, one implementation strategy would be to count the statistics for the ipIfStatsTable and aggregate them when queried for this table. Again, as with the IPv4 discussion, this strategy only works if the interfaces cannot be removed or if the statistics for removed interfaces are somehow retained. The ipv6AddrPrefixTable is now the ipAddressPrefixTable. The new table contains an extra object and the additional index required for IPv4 compatibility. As above, the SNMP routines will need to be updated to handle the new indexing. The ipAddressTable is loosely based on the ipv6AddrTable but has changed considerably with the addition of several new objects and the removal of one of its indexes. Routhier, Ed. Standards Track [Page 12] RFC 4293 IP MIB April 2006 The IPv6 routing information (ipv6RouteNumber, ipv6DiscardedRoutes, and ipv6RouteTable) has been removed from this MIB. The replacements or updates for this information is in the update to the IP Forwarding Table MIB [16]. The ipv6NetToMediaTable has been converted to the ipNetToPhysicalTable. The new table contains an extra object and the additional index required for IPv4 compatibility. As above, the SNMP routines will need to be updated to handle the new indexing. The ICMP tables have been substantially changed. The previous tables required counting on a per-message and per-interface basis. The new tables only require counting on a per-message, per-protocol basis and include an aggregate of all messages on a per-protocol basis. In addition to the above, several new tables have been added. Both the ipv6ScopeZoneIndexTable and ipDefaultRouterTable are required on all IPv6 entities. The ipv6RouterAdvertTable is only required on IPv6 routers. 5. Definitions The following MIB module imports from the IF-MIB [6] and the INET- ADDRESS-MIB [7] and references Neighbor Discovery [4], the IPv6 Stateless Address Autoconfiguration protocol [5], the Default Router Preferences document [8], ARP [10] and the IPv6 address architecture document [17]. IP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, IpAddress, mib-2, Unsigned32, Counter64, zeroDotZero FROM SNMPv2-SMI PhysAddress, TruthValue, TimeStamp, RowPointer, TEXTUAL-CONVENTION, TestAndIncr, RowStatus, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddress, InetAddressType, InetAddressPrefixLength, InetVersion, InetZoneIndex FROM INET-ADDRESS-MIB InterfaceIndex FROM IF-MIB; ipMIB MODULE-IDENTITY LAST-UPDATED "200602020000Z" ORGANIZATION "IETF IPv6 MIB Revision Team" CONTACT-INFO "Editor: Routhier, Ed. Standards Track [Page 13] RFC 4293 IP MIB April 2006 Shawn A. Routhier Interworking Labs 108 Whispering Pines Dr. Suite 235 Scotts Valley, CA 95066 USA EMail: " DESCRIPTION "The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4293; see the RFC itself for full legal notices." REVISION "200602020000Z" DESCRIPTION "The IP version neutral revision with added IPv6 objects for ND, default routers, and router advertisements. As well as being the successor to RFC 2011, this MIB is also the successor to RFCs 2465 and 2466. Published as RFC 4293." REVISION "199411010000Z" DESCRIPTION "A separate MIB module (IP-MIB) for IP and ICMP management objects. Published as RFC 2011." REVISION "199103310000Z" DESCRIPTION "The initial revision of this MIB module was part of MIB-II, which was published as RFC 1213." ::= { mib-2 48} -- -- The textual conventions we define and use in this MIB. -- IpAddressOriginTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The origin of the address. manual(2) indicates that the address was manually configured to a specified address, e.g., by user configuration. dhcp(4) indicates an address that was assigned to this system by a DHCP server. linklayer(5) indicates an address created by IPv6 stateless Routhier, Ed. Standards Track [Page 14] RFC 4293 IP MIB April 2006 auto-configuration. random(6) indicates an address chosen by the system at random, e.g., an IPv4 address within 169.254/16, or an RFC 3041 privacy address." SYNTAX INTEGER { other(1), manual(2), dhcp(4), linklayer(5), random(6) } IpAddressStatusTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration protocol. The preferred(1) state indicates that this is a valid address that can appear as the destination or source address of a packet. The deprecated(2) state indicates that this is a valid but deprecated address that should no longer be used as a source address in new communications, but packets addressed to such an address are processed as expected. The invalid(3) state indicates that this isn't a valid address and it shouldn't appear as the destination or source address of a packet. The inaccessible(4) state indicates that the address is not accessible because the interface to which this address is assigned is not operational. The unknown(5) state indicates that the status cannot be determined for some reason. The tentative(6) state indicates that the uniqueness of the address on the link is being verified. Addresses in this state should not be used for general communication and should only be used to determine the uniqueness of the address. The duplicate(7) state indicates the address has been determined to be non-unique on the link and so must not be Routhier, Ed. Standards Track [Page 15] RFC 4293 IP MIB April 2006 used. The optimistic(8) state indicates the address is available for use, subject to restrictions, while its uniqueness on a link is being verified. In the absence of other information, an IPv4 address is always preferred(1)." REFERENCE "RFC 2462" SYNTAX INTEGER { preferred(1), deprecated(2), invalid(3), inaccessible(4), unknown(5), tentative(6), duplicate(7), optimistic(8) } IpAddressPrefixOriginTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The origin of this prefix. manual(2) indicates a prefix that was manually configured. wellknown(3) indicates a well-known prefix, e.g., 169.254/16 for IPv4 auto-configuration or fe80::/10 for IPv6 link-local addresses. Well known prefixes may be assigned by IANA, the address registries, or by specification in a standards track RFC. dhcp(4) indicates a prefix that was assigned by a DHCP server. routeradv(5) indicates a prefix learned from a router advertisement. Note: while IpAddressOriginTC and IpAddressPrefixOriginTC are similar, they are not identical. The first defines how an address was created, while the second defines how a prefix was found." SYNTAX INTEGER { other(1), manual(2), wellknown(3), dhcp(4), Routhier, Ed. Standards Track [Page 16] RFC 4293 IP MIB April 2006 routeradv(5) } Ipv6AddressIfIdentifierTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:" STATUS current DESCRIPTION "This data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order." SYNTAX OCTET STRING (SIZE (0..8)) -- -- the IP general group -- some objects that affect all of IPv4 -- ip OBJECT IDENTIFIER ::= { mib-2 4 } ipForwarding OBJECT-TYPE SYNTAX INTEGER { forwarding(1), -- acting as a router notForwarding(2) -- NOT acting as a router } MAX-ACCESS read-write STATUS current DESCRIPTION "The indication of whether this entity is acting as an IPv4 router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv4 routers forward datagrams. IPv4 hosts do not (except those source-routed via the host). When this object is written, the entity should save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system. Note: a stronger requirement is not used because this object was previously defined." ::= { ip 1 } ipDefaultTTL OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The default value inserted into the Time-To-Live field of the IPv4 header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer Routhier, Ed. Standards Track [Page 17] RFC 4293 IP MIB April 2006 protocol. When this object is written, the entity should save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system. Note: a stronger requirement is not used because this object was previously defined." ::= { ip 2 } ipReasmTimeout OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of seconds that received fragments are held while they are awaiting reassembly at this entity." ::= { ip 13 } -- -- the IPv6 general group -- Some objects that affect all of IPv6 -- ipv6IpForwarding OBJECT-TYPE SYNTAX INTEGER { forwarding(1), -- acting as a router notForwarding(2) -- NOT acting as a router } MAX-ACCESS read-write STATUS current DESCRIPTION "The indication of whether this entity is acting as an IPv6 router on any interface in respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv6 routers forward datagrams. IPv6 hosts do not (except those source-routed via the host). When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system." ::= { ip 25 } ipv6IpDefaultHopLimit OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION Routhier, Ed. Standards Track [Page 18] RFC 4293 IP MIB April 2006 "The default value inserted into the Hop Limit field of the IPv6 header of datagrams originated at this entity whenever a Hop Limit value is not supplied by the transport layer protocol. When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system." REFERENCE "RFC 2461 Section 6.3.2" ::= { ip 26 } -- -- IPv4 Interface Table -- ipv4InterfaceTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which a row in the ipv4InterfaceTable was added or deleted, or when an ipv4InterfaceReasmMaxSize or an ipv4InterfaceEnableStatus object was modified. If new objects are added to the ipv4InterfaceTable that require the ipv4InterfaceTableLastChange to be updated when they are modified, they must specify that requirement in their description clause." ::= { ip 27 } ipv4InterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv4InterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing per-interface IPv4-specific information." ::= { ip 28 } ipv4InterfaceEntry OBJECT-TYPE SYNTAX Ipv4InterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing IPv4-specific information for a specific interface." INDEX { ipv4InterfaceIfIndex } Routhier, Ed. Standards Track [Page 19] RFC 4293 IP MIB April 2006 ::= { ipv4InterfaceTable 1 } Ipv4InterfaceEntry ::= SEQUENCE { ipv4InterfaceIfIndex InterfaceIndex, ipv4InterfaceReasmMaxSize Integer32, ipv4InterfaceEnableStatus INTEGER, ipv4InterfaceRetransmitTime Unsigned32 } ipv4InterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipv4InterfaceEntry 1 } ipv4InterfaceReasmMaxSize OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the largest IPv4 datagram that this entity can re-assemble from incoming IPv4 fragmented datagrams received on this interface." ::= { ipv4InterfaceEntry 2 } ipv4InterfaceEnableStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The indication of whether IPv4 is enabled (up) or disabled (down) on this interface. This object does not affect the state of the interface itself, only its connection to an IPv4 stack. The IF-MIB should be used to control the state of the interface." ::= { ipv4InterfaceEntry 3 } ipv4InterfaceRetransmitTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" Routhier, Ed. Standards Track [Page 20] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The time between retransmissions of ARP requests to a neighbor when resolving the address or when probing the reachability of a neighbor." REFERENCE "RFC 1122" DEFVAL { 1000 } ::= { ipv4InterfaceEntry 4 } -- -- v6 interface table -- ipv6InterfaceTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which a row in the ipv6InterfaceTable was added or deleted or when an ipv6InterfaceReasmMaxSize, ipv6InterfaceIdentifier, ipv6InterfaceEnableStatus, ipv6InterfaceReachableTime, ipv6InterfaceRetransmitTime, or ipv6InterfaceForwarding object was modified. If new objects are added to the ipv6InterfaceTable that require the ipv6InterfaceTableLastChange to be updated when they are modified, they must specify that requirement in their description clause." ::= { ip 29 } ipv6InterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6InterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing per-interface IPv6-specific information." ::= { ip 30 } ipv6InterfaceEntry OBJECT-TYPE SYNTAX Ipv6InterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing IPv6-specific information for a given interface." Routhier, Ed. Standards Track [Page 21] RFC 4293 IP MIB April 2006 INDEX { ipv6InterfaceIfIndex } ::= { ipv6InterfaceTable 1 } Ipv6InterfaceEntry ::= SEQUENCE { ipv6InterfaceIfIndex InterfaceIndex, ipv6InterfaceReasmMaxSize Unsigned32, ipv6InterfaceIdentifier Ipv6AddressIfIdentifierTC, ipv6InterfaceEnableStatus INTEGER, ipv6InterfaceReachableTime Unsigned32, ipv6InterfaceRetransmitTime Unsigned32, ipv6InterfaceForwarding INTEGER } ipv6InterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipv6InterfaceEntry 1 } ipv6InterfaceReasmMaxSize OBJECT-TYPE SYNTAX Unsigned32 (1500..65535) UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The size of the largest IPv6 datagram that this entity can re-assemble from incoming IPv6 fragmented datagrams received on this interface." ::= { ipv6InterfaceEntry 2 } ipv6InterfaceIdentifier OBJECT-TYPE SYNTAX Ipv6AddressIfIdentifierTC MAX-ACCESS read-only STATUS current DESCRIPTION "The Interface Identifier for this interface. The Interface Identifier is combined with an address prefix to form an interface address. By default, the Interface Identifier is auto-configured according to the rules of the link type to which this interface is attached. Routhier, Ed. Standards Track [Page 22] RFC 4293 IP MIB April 2006 A zero length identifier may be used where appropriate. One possible example is a loopback interface." ::= { ipv6InterfaceEntry 3 } -- This object ID is reserved as it was used in earlier versions of -- the MIB module. In theory, OIDs are not assigned until the -- specification is released as an RFC; however, as some companies -- may have shipped code based on earlier versions of the MIB, it -- seems best to reserve this OID. This OID had been -- ipv6InterfacePhysicalAddress. -- ::= { ipv6InterfaceEntry 4} ipv6InterfaceEnableStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The indication of whether IPv6 is enabled (up) or disabled (down) on this interface. This object does not affect the state of the interface itself, only its connection to an IPv6 stack. The IF-MIB should be used to control the state of the interface. When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system." ::= { ipv6InterfaceEntry 5 } ipv6InterfaceReachableTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time a neighbor is considered reachable after receiving a reachability confirmation." REFERENCE "RFC 2461, Section 6.3.2" ::= { ipv6InterfaceEntry 6 } ipv6InterfaceRetransmitTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION Routhier, Ed. Standards Track [Page 23] RFC 4293 IP MIB April 2006 "The time between retransmissions of Neighbor Solicitation messages to a neighbor when resolving the address or when probing the reachability of a neighbor." REFERENCE "RFC 2461, Section 6.3.2" ::= { ipv6InterfaceEntry 7 } ipv6InterfaceForwarding OBJECT-TYPE SYNTAX INTEGER { forwarding(1), -- acting as a router notForwarding(2) -- NOT acting as a router } MAX-ACCESS read-write STATUS current DESCRIPTION "The indication of whether this entity is acting as an IPv6 router on this interface with respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv6 routers forward datagrams. IPv6 hosts do not (except those source-routed via the host). This object is constrained by ipv6IpForwarding and is ignored if ipv6IpForwarding is set to notForwarding. Those systems that do not provide per-interface control of the forwarding function should set this object to forwarding for all interfaces and allow the ipv6IpForwarding object to control the forwarding capability. When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system." ::= { ipv6InterfaceEntry 8 } -- -- Per-Interface or System-Wide IP statistics. -- -- The following two tables, ipSystemStatsTable and ipIfStatsTable, -- are intended to provide the same counters at different granularities. -- The ipSystemStatsTable provides system wide counters aggregating -- the traffic counters for all interfaces for a given address type. -- The ipIfStatsTable provides the same counters but for specific -- interfaces rather than as an aggregate. -- -- Note well: If a system provides both system-wide and interface- -- specific values, the system-wide value may not be equal to the sum -- of the interface-specific values across all interfaces due to e.g., -- dynamic interface creation/deletion. -- -- Note well: Both of these tables contain some items that are Routhier, Ed. Standards Track [Page 24] RFC 4293 IP MIB April 2006 -- represented by two objects, representing the value in either 32 -- or 64 bits. For those objects, the 32-bit value MUST be the low -- order 32 bits of the 64-bit value. Also note that the 32-bit -- counters must be included when the 64-bit counters are included. ipTrafficStats OBJECT IDENTIFIER ::= { ip 31 } ipSystemStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpSystemStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing system wide, IP version specific traffic statistics. This table and the ipIfStatsTable contain similar objects whose difference is in their granularity. Where this table contains system wide traffic statistics, the ipIfStatsTable contains the same statistics but counted on a per-interface basis." ::= { ipTrafficStats 1 } ipSystemStatsEntry OBJECT-TYPE SYNTAX IpSystemStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A statistics entry containing system-wide objects for a particular IP version." INDEX { ipSystemStatsIPVersion } ::= { ipSystemStatsTable 1 } IpSystemStatsEntry ::= SEQUENCE { ipSystemStatsIPVersion InetVersion, ipSystemStatsInReceives Counter32, ipSystemStatsHCInReceives Counter64, ipSystemStatsInOctets Counter32, ipSystemStatsHCInOctets Counter64, ipSystemStatsInHdrErrors Counter32, ipSystemStatsInNoRoutes Counter32, ipSystemStatsInAddrErrors Counter32, ipSystemStatsInUnknownProtos Counter32, ipSystemStatsInTruncatedPkts Counter32, ipSystemStatsInForwDatagrams Counter32, ipSystemStatsHCInForwDatagrams Counter64, ipSystemStatsReasmReqds Counter32, ipSystemStatsReasmOKs Counter32, ipSystemStatsReasmFails Counter32, ipSystemStatsInDiscards Counter32, ipSystemStatsInDelivers Counter32, Routhier, Ed. Standards Track [Page 25] RFC 4293 IP MIB April 2006 ipSystemStatsHCInDelivers Counter64, ipSystemStatsOutRequests Counter32, ipSystemStatsHCOutRequests Counter64, ipSystemStatsOutNoRoutes Counter32, ipSystemStatsOutForwDatagrams Counter32, ipSystemStatsHCOutForwDatagrams Counter64, ipSystemStatsOutDiscards Counter32, ipSystemStatsOutFragReqds Counter32, ipSystemStatsOutFragOKs Counter32, ipSystemStatsOutFragFails Counter32, ipSystemStatsOutFragCreates Counter32, ipSystemStatsOutTransmits Counter32, ipSystemStatsHCOutTransmits Counter64, ipSystemStatsOutOctets Counter32, ipSystemStatsHCOutOctets Counter64, ipSystemStatsInMcastPkts Counter32, ipSystemStatsHCInMcastPkts Counter64, ipSystemStatsInMcastOctets Counter32, ipSystemStatsHCInMcastOctets Counter64, ipSystemStatsOutMcastPkts Counter32, ipSystemStatsHCOutMcastPkts Counter64, ipSystemStatsOutMcastOctets Counter32, ipSystemStatsHCOutMcastOctets Counter64, ipSystemStatsInBcastPkts Counter32, ipSystemStatsHCInBcastPkts Counter64, ipSystemStatsOutBcastPkts Counter32, ipSystemStatsHCOutBcastPkts Counter64, ipSystemStatsDiscontinuityTime TimeStamp, ipSystemStatsRefreshRate Unsigned32 } ipSystemStatsIPVersion OBJECT-TYPE SYNTAX InetVersion MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version of this row." ::= { ipSystemStatsEntry 1 } -- This object ID is reserved to allow the IDs for this table's objects -- to align with the objects in the ipIfStatsTable. -- ::= { ipSystemStatsEntry 2 } ipSystemStatsInReceives OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Routhier, Ed. Standards Track [Page 26] RFC 4293 IP MIB April 2006 "The total number of input IP datagrams received, including those received in error. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 3 } ipSystemStatsHCInReceives OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of input IP datagrams received, including those received in error. This object counts the same datagrams as ipSystemStatsInReceives, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 4 } ipSystemStatsInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in input IP datagrams, including those received in error. Octets from datagrams counted in ipSystemStatsInReceives MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 5 } ipSystemStatsHCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in input IP datagrams, including those received in error. This object counts the same octets as ipSystemStatsInOctets, but allows for larger Routhier, Ed. Standards Track [Page 27] RFC 4293 IP MIB April 2006 values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 6 } ipSystemStatsInHdrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded due to errors in their IP headers, including version number mismatch, other format errors, hop count exceeded, errors discovered in processing their IP options, etc. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 7 } ipSystemStatsInNoRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded because no route could be found to transmit them to their destination. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 8 } ipSystemStatsInAddrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., ::0). For entities that are not IP routers and therefore do not forward Routhier, Ed. Standards Track [Page 28] RFC 4293 IP MIB April 2006 datagrams, this counter includes datagrams discarded because the destination address was not a local address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 9 } ipSystemStatsInUnknownProtos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of locally-addressed IP datagrams received successfully but discarded because of an unknown or unsupported protocol. When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 10 } ipSystemStatsInTruncatedPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded because the datagram frame didn't carry enough data. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 11 } ipSystemStatsInForwDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Routhier, Ed. Standards Track [Page 29] RFC 4293 IP MIB April 2006 "The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful. When tracking interface statistics, the counter of the incoming interface is incremented for each datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 12 } ipSystemStatsHCInForwDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. This object counts the same packets as ipSystemStatsInForwDatagrams, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 13 } ipSystemStatsReasmReqds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP fragments received that needed to be reassembled at this interface. When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments. Discontinuities in the value of this counter can occur at Routhier, Ed. Standards Track [Page 30] RFC 4293 IP MIB April 2006 re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 14 } ipSystemStatsReasmOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP datagrams successfully reassembled. When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 15 } ipSystemStatsReasmFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received. When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 16 } ipSystemStatsInDiscards OBJECT-TYPE SYNTAX Counter32 Routhier, Ed. Standards Track [Page 31] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 17 } ipSystemStatsInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of datagrams successfully delivered to IP user-protocols (including ICMP). When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 18 } ipSystemStatsHCInDelivers OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of datagrams successfully delivered to IP user-protocols (including ICMP). This object counts the same packets as ipSystemStatsInDelivers, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." Routhier, Ed. Standards Track [Page 32] RFC 4293 IP MIB April 2006 ::= { ipSystemStatsEntry 19 } ipSystemStatsOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipSystemStatsOutForwDatagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 20 } ipSystemStatsHCOutRequests OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. This object counts the same packets as ipSystemStatsOutRequests, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 21 } ipSystemStatsOutNoRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of locally generated IP datagrams discarded because no route could be found to transmit them to their destination. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 22 } Routhier, Ed. Standards Track [Page 33] RFC 4293 IP MIB April 2006 ipSystemStatsOutForwDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful. When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully forwarded datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 23 } ipSystemStatsHCOutForwDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. This object counts the same packets as ipSystemStatsOutForwDatagrams, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 24 } ipSystemStatsOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but were discarded (e.g., for lack of buffer space). Note that this counter would include Routhier, Ed. Standards Track [Page 34] RFC 4293 IP MIB April 2006 datagrams counted in ipSystemStatsOutForwDatagrams if any such datagrams met this (discretionary) discard criterion. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 25 } ipSystemStatsOutFragReqds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP datagrams that would require fragmentation in order to be transmitted. When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 26 } ipSystemStatsOutFragOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP datagrams that have been successfully fragmented. When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 27 } ipSystemStatsOutFragFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Routhier, Ed. Standards Track [Page 35] RFC 4293 IP MIB April 2006 STATUS current DESCRIPTION "The number of IP datagrams that have been discarded because they needed to be fragmented but could not be. This includes IPv4 packets that have the DF bit set and IPv6 packets that are being forwarded and exceed the outgoing link MTU. When tracking interface statistics, the counter of the outgoing interface is incremented for an unsuccessfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 28 } ipSystemStatsOutFragCreates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output datagram fragments that have been generated as a result of IP fragmentation. When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 29 } ipSystemStatsOutTransmits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that this entity supplied to the lower layers for transmission. This includes datagrams generated locally and those forwarded by this entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other Routhier, Ed. Standards Track [Page 36] RFC 4293 IP MIB April 2006 times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 30 } ipSystemStatsHCOutTransmits OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that this entity supplied to the lower layers for transmission. This object counts the same datagrams as ipSystemStatsOutTransmits, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 31 } ipSystemStatsOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in IP datagrams delivered to the lower layers for transmission. Octets from datagrams counted in ipSystemStatsOutTransmits MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 32 } ipSystemStatsHCOutOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in IP datagrams delivered to the lower layers for transmission. This objects counts the same octets as ipSystemStatsOutOctets, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Routhier, Ed. Standards Track [Page 37] RFC 4293 IP MIB April 2006 ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 33 } ipSystemStatsInMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 34 } ipSystemStatsHCInMcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams received. This object counts the same datagrams as ipSystemStatsInMcastPkts but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 35 } ipSystemStatsInMcastOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in IP multicast datagrams. Octets from datagrams counted in ipSystemStatsInMcastPkts MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 36 } ipSystemStatsHCInMcastOctets OBJECT-TYPE SYNTAX Counter64 Routhier, Ed. Standards Track [Page 38] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in IP multicast datagrams. This object counts the same octets as ipSystemStatsInMcastOctets, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 37 } ipSystemStatsOutMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams transmitted. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 38 } ipSystemStatsHCOutMcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams transmitted. This object counts the same datagrams as ipSystemStatsOutMcastPkts, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 39 } ipSystemStatsOutMcastOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted in IP multicast datagrams. Octets from datagrams counted in Routhier, Ed. Standards Track [Page 39] RFC 4293 IP MIB April 2006 ipSystemStatsOutMcastPkts MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 40 } ipSystemStatsHCOutMcastOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted in IP multicast datagrams. This object counts the same octets as ipSystemStatsOutMcastOctets, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 41 } ipSystemStatsInBcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 42 } ipSystemStatsHCInBcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams received. This object counts the same datagrams as ipSystemStatsInBcastPkts but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Routhier, Ed. Standards Track [Page 40] RFC 4293 IP MIB April 2006 ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 43 } ipSystemStatsOutBcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams transmitted. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 44 } ipSystemStatsHCOutBcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams transmitted. This object counts the same datagrams as ipSystemStatsOutBcastPkts, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime." ::= { ipSystemStatsEntry 45 } ipSystemStatsDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this entry's counters suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { ipSystemStatsEntry 46 } ipSystemStatsRefreshRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "milli-seconds" Routhier, Ed. Standards Track [Page 41] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum reasonable polling interval for this entry. This object provides an indication of the minimum amount of time required to update the counters in this entry." ::= { ipSystemStatsEntry 47 } ipIfStatsTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which a row in the ipIfStatsTable was added or deleted. If new objects are added to the ipIfStatsTable that require the ipIfStatsTableLastChange to be updated when they are modified, they must specify that requirement in their description clause." ::= { ipTrafficStats 2 } ipIfStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpIfStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing per-interface traffic statistics. This table and the ipSystemStatsTable contain similar objects whose difference is in their granularity. Where this table contains per-interface statistics, the ipSystemStatsTable contains the same statistics, but counted on a system wide basis." ::= { ipTrafficStats 3 } ipIfStatsEntry OBJECT-TYPE SYNTAX IpIfStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An interface statistics entry containing objects for a particular interface and version of IP." INDEX { ipIfStatsIPVersion, ipIfStatsIfIndex } ::= { ipIfStatsTable 1 } IpIfStatsEntry ::= SEQUENCE { ipIfStatsIPVersion InetVersion, ipIfStatsIfIndex InterfaceIndex, Routhier, Ed. Standards Track [Page 42] RFC 4293 IP MIB April 2006 ipIfStatsInReceives Counter32, ipIfStatsHCInReceives Counter64, ipIfStatsInOctets Counter32, ipIfStatsHCInOctets Counter64, ipIfStatsInHdrErrors Counter32, ipIfStatsInNoRoutes Counter32, ipIfStatsInAddrErrors Counter32, ipIfStatsInUnknownProtos Counter32, ipIfStatsInTruncatedPkts Counter32, ipIfStatsInForwDatagrams Counter32, ipIfStatsHCInForwDatagrams Counter64, ipIfStatsReasmReqds Counter32, ipIfStatsReasmOKs Counter32, ipIfStatsReasmFails Counter32, ipIfStatsInDiscards Counter32, ipIfStatsInDelivers Counter32, ipIfStatsHCInDelivers Counter64, ipIfStatsOutRequests Counter32, ipIfStatsHCOutRequests Counter64, ipIfStatsOutForwDatagrams Counter32, ipIfStatsHCOutForwDatagrams Counter64, ipIfStatsOutDiscards Counter32, ipIfStatsOutFragReqds Counter32, ipIfStatsOutFragOKs Counter32, ipIfStatsOutFragFails Counter32, ipIfStatsOutFragCreates Counter32, ipIfStatsOutTransmits Counter32, ipIfStatsHCOutTransmits Counter64, ipIfStatsOutOctets Counter32, ipIfStatsHCOutOctets Counter64, ipIfStatsInMcastPkts Counter32, ipIfStatsHCInMcastPkts Counter64, ipIfStatsInMcastOctets Counter32, ipIfStatsHCInMcastOctets Counter64, ipIfStatsOutMcastPkts Counter32, ipIfStatsHCOutMcastPkts Counter64, ipIfStatsOutMcastOctets Counter32, ipIfStatsHCOutMcastOctets Counter64, ipIfStatsInBcastPkts Counter32, ipIfStatsHCInBcastPkts Counter64, ipIfStatsOutBcastPkts Counter32, ipIfStatsHCOutBcastPkts Counter64, ipIfStatsDiscontinuityTime TimeStamp, ipIfStatsRefreshRate Unsigned32 } ipIfStatsIPVersion OBJECT-TYPE SYNTAX InetVersion Routhier, Ed. Standards Track [Page 43] RFC 4293 IP MIB April 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version of this row." ::= { ipIfStatsEntry 1 } ipIfStatsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipIfStatsEntry 2 } ipIfStatsInReceives OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of input IP datagrams received, including those received in error. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 3 } ipIfStatsHCInReceives OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of input IP datagrams received, including those received in error. This object counts the same datagrams as ipIfStatsInReceives, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 4 } ipIfStatsInOctets OBJECT-TYPE Routhier, Ed. Standards Track [Page 44] RFC 4293 IP MIB April 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in input IP datagrams, including those received in error. Octets from datagrams counted in ipIfStatsInReceives MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 5 } ipIfStatsHCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in input IP datagrams, including those received in error. This object counts the same octets as ipIfStatsInOctets, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 6 } ipIfStatsInHdrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded due to errors in their IP headers, including version number mismatch, other format errors, hop count exceeded, errors discovered in processing their IP options, etc. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 7 } ipIfStatsInNoRoutes OBJECT-TYPE SYNTAX Counter32 Routhier, Ed. Standards Track [Page 45] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded because no route could be found to transmit them to their destination. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 8 } ipIfStatsInAddrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., ::0). For entities that are not IP routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 9 } ipIfStatsInUnknownProtos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of locally-addressed IP datagrams received successfully but discarded because of an unknown or unsupported protocol. When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Routhier, Ed. Standards Track [Page 46] RFC 4293 IP MIB April 2006 ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 10 } ipIfStatsInTruncatedPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams discarded because the datagram frame didn't carry enough data. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 11 } ipIfStatsInForwDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful. When tracking interface statistics, the counter of the incoming interface is incremented for each datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 12 } ipIfStatsHCInForwDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. This object counts the same packets as Routhier, Ed. Standards Track [Page 47] RFC 4293 IP MIB April 2006 ipIfStatsInForwDatagrams, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 13 } ipIfStatsReasmReqds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP fragments received that needed to be reassembled at this interface. When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 14 } ipIfStatsReasmOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP datagrams successfully reassembled. When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 15 } ipIfStatsReasmFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Routhier, Ed. Standards Track [Page 48] RFC 4293 IP MIB April 2006 STATUS current DESCRIPTION "The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received. When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 16 } ipIfStatsInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 17 } ipIfStatsInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of datagrams successfully delivered to IP user-protocols (including ICMP). When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the Routhier, Ed. Standards Track [Page 49] RFC 4293 IP MIB April 2006 input interface for some of the datagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 18 } ipIfStatsHCInDelivers OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of datagrams successfully delivered to IP user-protocols (including ICMP). This object counts the same packets as ipIfStatsInDelivers, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 19 } ipIfStatsOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipIfStatsOutForwDatagrams. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 20 } ipIfStatsHCOutRequests OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. This object counts the same packets as Routhier, Ed. Standards Track [Page 50] RFC 4293 IP MIB April 2006 ipIfStatsOutRequests, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 21 } -- This object ID is reserved to allow the IDs for this table's objects -- to align with the objects in the ipSystemStatsTable. -- ::= {ipIfStatsEntry 22} ipIfStatsOutForwDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful. When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully forwarded datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 23 } ipIfStatsHCOutForwDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. This object counts the same packets as ipIfStatsOutForwDatagrams, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Routhier, Ed. Standards Track [Page 51] RFC 4293 IP MIB April 2006 ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 24 } ipIfStatsOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipIfStatsOutForwDatagrams if any such datagrams met this (discretionary) discard criterion. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 25 } ipIfStatsOutFragReqds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP datagrams that would require fragmentation in order to be transmitted. When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 26 } ipIfStatsOutFragOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP datagrams that have been successfully fragmented. When tracking interface statistics, the counter of the Routhier, Ed. Standards Track [Page 52] RFC 4293 IP MIB April 2006 outgoing interface is incremented for a successfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 27 } ipIfStatsOutFragFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP datagrams that have been discarded because they needed to be fragmented but could not be. This includes IPv4 packets that have the DF bit set and IPv6 packets that are being forwarded and exceed the outgoing link MTU. When tracking interface statistics, the counter of the outgoing interface is incremented for an unsuccessfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 28 } ipIfStatsOutFragCreates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output datagram fragments that have been generated as a result of IP fragmentation. When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 29 } Routhier, Ed. Standards Track [Page 53] RFC 4293 IP MIB April 2006 ipIfStatsOutTransmits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that this entity supplied to the lower layers for transmission. This includes datagrams generated locally and those forwarded by this entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 30 } ipIfStatsHCOutTransmits OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IP datagrams that this entity supplied to the lower layers for transmission. This object counts the same datagrams as ipIfStatsOutTransmits, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 31 } ipIfStatsOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in IP datagrams delivered to the lower layers for transmission. Octets from datagrams counted in ipIfStatsOutTransmits MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 32 } ipIfStatsHCOutOctets OBJECT-TYPE Routhier, Ed. Standards Track [Page 54] RFC 4293 IP MIB April 2006 SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in IP datagrams delivered to the lower layers for transmission. This objects counts the same octets as ipIfStatsOutOctets, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 33 } ipIfStatsInMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 34 } ipIfStatsHCInMcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams received. This object counts the same datagrams as ipIfStatsInMcastPkts, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 35 } ipIfStatsInMcastOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in IP multicast Routhier, Ed. Standards Track [Page 55] RFC 4293 IP MIB April 2006 datagrams. Octets from datagrams counted in ipIfStatsInMcastPkts MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 36 } ipIfStatsHCInMcastOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received in IP multicast datagrams. This object counts the same octets as ipIfStatsInMcastOctets, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 37 } ipIfStatsOutMcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams transmitted. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 38 } ipIfStatsHCOutMcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP multicast datagrams transmitted. This object counts the same datagrams as ipIfStatsOutMcastPkts, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other Routhier, Ed. Standards Track [Page 56] RFC 4293 IP MIB April 2006 times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 39 } ipIfStatsOutMcastOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted in IP multicast datagrams. Octets from datagrams counted in ipIfStatsOutMcastPkts MUST be counted here. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 40 } ipIfStatsHCOutMcastOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted in IP multicast datagrams. This object counts the same octets as ipIfStatsOutMcastOctets, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 41 } ipIfStatsInBcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 42 } ipIfStatsHCInBcastPkts OBJECT-TYPE Routhier, Ed. Standards Track [Page 57] RFC 4293 IP MIB April 2006 SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams received. This object counts the same datagrams as ipIfStatsInBcastPkts, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 43 } ipIfStatsOutBcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams transmitted. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 44 } ipIfStatsHCOutBcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IP broadcast datagrams transmitted. This object counts the same datagrams as ipIfStatsOutBcastPkts, but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime." ::= { ipIfStatsEntry 45 } ipIfStatsDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which Routhier, Ed. Standards Track [Page 58] RFC 4293 IP MIB April 2006 any one or more of this entry's counters suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { ipIfStatsEntry 46 } ipIfStatsRefreshRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "milli-seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum reasonable polling interval for this entry. This object provides an indication of the minimum amount of time required to update the counters in this entry." ::= { ipIfStatsEntry 47 } -- -- Internet Address Prefix table -- ipAddressPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddressPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table allows the user to determine the source of an IP address or set of IP addresses, and allows other tables to share the information via pointer rather than by copying. For example, when the node configures both a unicast and anycast address for a prefix, the ipAddressPrefix objects for those addresses will point to a single row in this table. This table primarily provides support for IPv6 prefixes, and several of the objects are less meaningful for IPv4. The table continues to allow IPv4 addresses to allow future flexibility. In order to promote a common configuration, this document includes suggestions for default values for IPv4 prefixes. Each of these values may be overridden if an object is meaningful to the node. All prefixes used by this entity should be included in this table independent of how the entity learned the prefix. (This table isn't limited to prefixes learned from router Routhier, Ed. Standards Track [Page 59] RFC 4293 IP MIB April 2006 advertisements.)" ::= { ip 32 } ipAddressPrefixEntry OBJECT-TYPE SYNTAX IpAddressPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ipAddressPrefixTable." INDEX { ipAddressPrefixIfIndex, ipAddressPrefixType, ipAddressPrefixPrefix, ipAddressPrefixLength } ::= { ipAddressPrefixTable 1 } IpAddressPrefixEntry ::= SEQUENCE { ipAddressPrefixIfIndex InterfaceIndex, ipAddressPrefixType InetAddressType, ipAddressPrefixPrefix InetAddress, ipAddressPrefixLength InetAddressPrefixLength, ipAddressPrefixOrigin IpAddressPrefixOriginTC, ipAddressPrefixOnLinkFlag TruthValue, ipAddressPrefixAutonomousFlag TruthValue, ipAddressPrefixAdvPreferredLifetime Unsigned32, ipAddressPrefixAdvValidLifetime Unsigned32 } ipAddressPrefixIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface on which this prefix is configured. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipAddressPrefixEntry 1 } ipAddressPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of ipAddressPrefix." ::= { ipAddressPrefixEntry 2 } ipAddressPrefixPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current Routhier, Ed. Standards Track [Page 60] RFC 4293 IP MIB April 2006 DESCRIPTION "The address prefix. The address type of this object is specified in ipAddressPrefixType. The length of this object is the standard length for objects of that type (4 or 16 bytes). Any bits after ipAddressPrefixLength must be zero. Implementors need to be aware that, if the size of ipAddressPrefixPrefix exceeds 114 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { ipAddressPrefixEntry 3 } ipAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The prefix length associated with this prefix. The value 0 has no special meaning for this object. It simply refers to address '::/0'." ::= { ipAddressPrefixEntry 4 } ipAddressPrefixOrigin OBJECT-TYPE SYNTAX IpAddressPrefixOriginTC MAX-ACCESS read-only STATUS current DESCRIPTION "The origin of this prefix." ::= { ipAddressPrefixEntry 5 } ipAddressPrefixOnLinkFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object has the value 'true(1)', if this prefix can be used for on-link determination; otherwise, the value is 'false(2)'. The default for IPv4 prefixes is 'true(1)'." REFERENCE "For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462" ::= { ipAddressPrefixEntry 6 } ipAddressPrefixAutonomousFlag OBJECT-TYPE SYNTAX TruthValue Routhier, Ed. Standards Track [Page 61] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "Autonomous address configuration flag. When true(1), indicates that this prefix can be used for autonomous address configuration (i.e., can be used to form a local interface address). If false(2), it is not used to auto- configure a local interface address. The default for IPv4 prefixes is 'false(2)'." REFERENCE "For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462" ::= { ipAddressPrefixEntry 7 } ipAddressPrefixAdvPreferredLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The remaining length of time, in seconds, that this prefix will continue to be preferred, i.e., time until deprecation. A value of 4,294,967,295 represents infinity. The address generated from a deprecated prefix should no longer be used as a source address in new communications, but packets received on such an interface are processed as expected. The default for IPv4 prefixes is 4,294,967,295 (infinity)." REFERENCE "For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462" ::= { ipAddressPrefixEntry 8 } ipAddressPrefixAdvValidLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The remaining length of time, in seconds, that this prefix will continue to be valid, i.e., time until invalidation. A value of 4,294,967,295 represents infinity. The address generated from an invalidated prefix should not appear as the destination or source address of a packet. Routhier, Ed. Standards Track [Page 62] RFC 4293 IP MIB April 2006 The default for IPv4 prefixes is 4,294,967,295 (infinity)." REFERENCE "For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462" ::= { ipAddressPrefixEntry 9 } -- -- Internet Address Table -- ipAddressSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating SNMP managers to coordinate their use of the set operation in creating or modifying rows within this table. In order to use this lock to coordinate the use of set operations, managers should first retrieve ipAddressTableSpinLock. They should then determine the appropriate row to create or modify. Finally, they should issue the appropriate set command, including the retrieved value of ipAddressSpinLock. If another manager has altered the table in the meantime, then the value of ipAddressSpinLock will have changed, and the creation will fail as it will be specifying an incorrect value for ipAddressSpinLock. It is suggested, but not required, that the ipAddressSpinLock be the first var bind for each set of objects representing a 'row' in a PDU." ::= { ip 33 } ipAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains addressing information relevant to the entity's interfaces. This table does not contain multicast address information. Tables for such information should be contained in multicast specific MIBs, such as RFC 3019. While this table is writable, the user will note that several objects, such as ipAddressOrigin, are not. The intention in allowing a user to write to this table is to allow them to add or remove any entry that isn't Routhier, Ed. Standards Track [Page 63] RFC 4293 IP MIB April 2006 permanent. The user should be allowed to modify objects and entries when that would not cause inconsistencies within the table. Allowing write access to objects, such as ipAddressOrigin, could allow a user to insert an entry and then label it incorrectly. Note well: When including IPv6 link-local addresses in this table, the entry must use an InetAddressType of 'ipv6z' in order to differentiate between the possible interfaces." ::= { ip 34 } ipAddressEntry OBJECT-TYPE SYNTAX IpAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An address mapping for a particular interface." INDEX { ipAddressAddrType, ipAddressAddr } ::= { ipAddressTable 1 } IpAddressEntry ::= SEQUENCE { ipAddressAddrType InetAddressType, ipAddressAddr InetAddress, ipAddressIfIndex InterfaceIndex, ipAddressType INTEGER, ipAddressPrefix RowPointer, ipAddressOrigin IpAddressOriginTC, ipAddressStatus IpAddressStatusTC, ipAddressCreated TimeStamp, ipAddressLastChanged TimeStamp, ipAddressRowStatus RowStatus, ipAddressStorageType StorageType } ipAddressAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of ipAddressAddr." ::= { ipAddressEntry 1 } ipAddressAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address to which this entry's addressing information Routhier, Ed. Standards Track [Page 64] RFC 4293 IP MIB April 2006 pertains. The address type of this object is specified in ipAddressAddrType. Implementors need to be aware that if the size of ipAddressAddr exceeds 116 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { ipAddressEntry 2 } ipAddressIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipAddressEntry 3 } ipAddressType OBJECT-TYPE SYNTAX INTEGER { unicast(1), anycast(2), broadcast(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of address. broadcast(3) is not a valid value for IPv6 addresses (RFC 3513)." DEFVAL { unicast } ::= { ipAddressEntry 4 } ipAddressPrefix OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the row in the prefix table to which this address belongs. May be { 0 0 } if there is no such row." DEFVAL { zeroDotZero } ::= { ipAddressEntry 5 } ipAddressOrigin OBJECT-TYPE SYNTAX IpAddressOriginTC MAX-ACCESS read-only STATUS current Routhier, Ed. Standards Track [Page 65] RFC 4293 IP MIB April 2006 DESCRIPTION "The origin of the address." ::= { ipAddressEntry 6 } ipAddressStatus OBJECT-TYPE SYNTAX IpAddressStatusTC MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the address, describing if the address can be used for communication. In the absence of other information, an IPv4 address is always preferred(1)." DEFVAL { preferred } ::= { ipAddressEntry 7 } ipAddressCreated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this entry was created. If this entry was created prior to the last re- initialization of the local network management subsystem, then this object contains a zero value." ::= { ipAddressEntry 8 } ipAddressLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this entry was last updated. If this entry was updated prior to the last re- initialization of the local network management subsystem, then this object contains a zero value." ::= { ipAddressEntry 9 } ipAddressRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The RowStatus TC requires that this DESCRIPTION clause states under which circumstances other objects in this row Routhier, Ed. Standards Track [Page 66] RFC 4293 IP MIB April 2006 can be modified. The value of this object has no effect on whether other objects in this conceptual row can be modified. A conceptual row can not be made active until the ipAddressIfIndex has been set to a valid index." ::= { ipAddressEntry 10 } ipAddressStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. If this object has a value of 'permanent', then no other objects are required to be able to be modified." DEFVAL { volatile } ::= { ipAddressEntry 11 } -- -- the Internet Address Translation table -- ipNetToPhysicalTable OBJECT-TYPE SYNTAX SEQUENCE OF IpNetToPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP Address Translation table used for mapping from IP addresses to physical addresses. The Address Translation tables contain the IP address to 'physical' address equivalences. Some interfaces do not use translation tables for determining address equivalences (e.g., DDN-X.25 has an algorithmic method); if all interfaces are of this type, then the Address Translation table is empty, i.e., has zero entries. While many protocols may be used to populate this table, ARP and Neighbor Discovery are the most likely options." REFERENCE "RFC 826 and RFC 2461" ::= { ip 35 } ipNetToPhysicalEntry OBJECT-TYPE SYNTAX IpNetToPhysicalEntry MAX-ACCESS not-accessible STATUS current Routhier, Ed. Standards Track [Page 67] RFC 4293 IP MIB April 2006 DESCRIPTION "Each entry contains one IP address to `physical' address equivalence." INDEX { ipNetToPhysicalIfIndex, ipNetToPhysicalNetAddressType, ipNetToPhysicalNetAddress } ::= { ipNetToPhysicalTable 1 } IpNetToPhysicalEntry ::= SEQUENCE { ipNetToPhysicalIfIndex InterfaceIndex, ipNetToPhysicalNetAddressType InetAddressType, ipNetToPhysicalNetAddress InetAddress, ipNetToPhysicalPhysAddress PhysAddress, ipNetToPhysicalLastUpdated TimeStamp, ipNetToPhysicalType INTEGER, ipNetToPhysicalState INTEGER, ipNetToPhysicalRowStatus RowStatus } ipNetToPhysicalIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipNetToPhysicalEntry 1 } ipNetToPhysicalNetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of ipNetToPhysicalNetAddress." ::= { ipNetToPhysicalEntry 2 } ipNetToPhysicalNetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP Address corresponding to the media-dependent `physical' address. The address type of this object is specified in ipNetToPhysicalAddressType. Implementors need to be aware that if the size of Routhier, Ed. Standards Track [Page 68] RFC 4293 IP MIB April 2006 ipNetToPhysicalNetAddress exceeds 115 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { ipNetToPhysicalEntry 3 } ipNetToPhysicalPhysAddress OBJECT-TYPE SYNTAX PhysAddress (SIZE(0..65535)) MAX-ACCESS read-create STATUS current DESCRIPTION "The media-dependent `physical' address. As the entries in this table are typically not persistent when this object is written the entity SHOULD NOT save the change to non-volatile storage." ::= { ipNetToPhysicalEntry 4 } ipNetToPhysicalLastUpdated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this entry was last updated. If this entry was updated prior to the last re- initialization of the local network management subsystem, then this object contains a zero value." ::= { ipNetToPhysicalEntry 5 } ipNetToPhysicalType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4), local(5) -- local interface } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToPhysicalTable. That is, it effectively dis- associates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent Routhier, Ed. Standards Track [Page 69] RFC 4293 IP MIB April 2006 removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToPhysicalType object. The 'dynamic(3)' type indicates that the IP address to physical addresses mapping has been dynamically resolved using e.g., IPv4 ARP or the IPv6 Neighbor Discovery protocol. The 'static(4)' type indicates that the mapping has been statically configured. Both of these refer to entries that provide mappings for other entities addresses. The 'local(5)' type indicates that the mapping is provided for an entity's own interface address. As the entries in this table are typically not persistent when this object is written the entity SHOULD NOT save the change to non-volatile storage." DEFVAL { static } ::= { ipNetToPhysicalEntry 6 } ipNetToPhysicalState OBJECT-TYPE SYNTAX INTEGER { reachable(1), -- confirmed reachability stale(2), -- unconfirmed reachability delay(3), -- waiting for reachability -- confirmation before entering -- the probe state probe(4), -- actively probing invalid(5), -- an invalidated mapping unknown(6), -- state can not be determined -- for some reason. incomplete(7) -- address resolution is being -- performed. } MAX-ACCESS read-only STATUS current DESCRIPTION Routhier, Ed. Standards Track [Page 70] RFC 4293 IP MIB April 2006 "The Neighbor Unreachability Detection state for the interface when the address mapping in this entry is used. If Neighbor Unreachability Detection is not in use (e.g. for IPv4), this object is always unknown(6)." REFERENCE "RFC 2461" ::= { ipNetToPhysicalEntry 7 } ipNetToPhysicalRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The RowStatus TC requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified. The value of this object has no effect on whether other objects in this conceptual row can be modified. A conceptual row can not be made active until the ipNetToPhysicalPhysAddress object has been set. Note that if the ipNetToPhysicalType is set to 'invalid', the managed node may delete the entry independent of the state of this object." ::= { ipNetToPhysicalEntry 8 } -- -- The IPv6 Scope Zone Index Table. -- ipv6ScopeZoneIndexTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6ScopeZoneIndexEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table used to describe IPv6 unicast and multicast scope zones. For those objects that have names rather than numbers, the names were chosen to coincide with the names used in the IPv6 address architecture document. " REFERENCE "Section 2.7 of RFC 4291" ::= { ip 36 } ipv6ScopeZoneIndexEntry OBJECT-TYPE SYNTAX Ipv6ScopeZoneIndexEntry Routhier, Ed. Standards Track [Page 71] RFC 4293 IP MIB April 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains the list of scope identifiers on a given interface." INDEX { ipv6ScopeZoneIndexIfIndex } ::= { ipv6ScopeZoneIndexTable 1 } Ipv6ScopeZoneIndexEntry ::= SEQUENCE { ipv6ScopeZoneIndexIfIndex InterfaceIndex, ipv6ScopeZoneIndexLinkLocal InetZoneIndex, ipv6ScopeZoneIndex3 InetZoneIndex, ipv6ScopeZoneIndexAdminLocal InetZoneIndex, ipv6ScopeZoneIndexSiteLocal InetZoneIndex, ipv6ScopeZoneIndex6 InetZoneIndex, ipv6ScopeZoneIndex7 InetZoneIndex, ipv6ScopeZoneIndexOrganizationLocal InetZoneIndex, ipv6ScopeZoneIndex9 InetZoneIndex, ipv6ScopeZoneIndexA InetZoneIndex, ipv6ScopeZoneIndexB InetZoneIndex, ipv6ScopeZoneIndexC InetZoneIndex, ipv6ScopeZoneIndexD InetZoneIndex } ipv6ScopeZoneIndexIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which these scopes belong. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipv6ScopeZoneIndexEntry 1 } ipv6ScopeZoneIndexLinkLocal OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for the link-local scope on this interface." ::= { ipv6ScopeZoneIndexEntry 2 } ipv6ScopeZoneIndex3 OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION Routhier, Ed. Standards Track [Page 72] RFC 4293 IP MIB April 2006 "The zone index for scope 3 on this interface." ::= { ipv6ScopeZoneIndexEntry 3 } ipv6ScopeZoneIndexAdminLocal OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for the admin-local scope on this interface." ::= { ipv6ScopeZoneIndexEntry 4 } ipv6ScopeZoneIndexSiteLocal OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for the site-local scope on this interface." ::= { ipv6ScopeZoneIndexEntry 5 } ipv6ScopeZoneIndex6 OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for scope 6 on this interface." ::= { ipv6ScopeZoneIndexEntry 6 } ipv6ScopeZoneIndex7 OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for scope 7 on this interface." ::= { ipv6ScopeZoneIndexEntry 7 } ipv6ScopeZoneIndexOrganizationLocal OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for the organization-local scope on this interface." ::= { ipv6ScopeZoneIndexEntry 8 } ipv6ScopeZoneIndex9 OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current Routhier, Ed. Standards Track [Page 73] RFC 4293 IP MIB April 2006 DESCRIPTION "The zone index for scope 9 on this interface." ::= { ipv6ScopeZoneIndexEntry 9 } ipv6ScopeZoneIndexA OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for scope A on this interface." ::= { ipv6ScopeZoneIndexEntry 10 } ipv6ScopeZoneIndexB OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for scope B on this interface." ::= { ipv6ScopeZoneIndexEntry 11 } ipv6ScopeZoneIndexC OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for scope C on this interface." ::= { ipv6ScopeZoneIndexEntry 12 } ipv6ScopeZoneIndexD OBJECT-TYPE SYNTAX InetZoneIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The zone index for scope D on this interface." ::= { ipv6ScopeZoneIndexEntry 13 } -- -- The Default Router Table -- This table simply lists the default routers; for more information -- about routing tables, see the routing MIBs -- ipDefaultRouterTable OBJECT-TYPE SYNTAX SEQUENCE OF IpDefaultRouterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table used to describe the default routers known to this Routhier, Ed. Standards Track [Page 74] RFC 4293 IP MIB April 2006 entity." ::= { ip 37 } ipDefaultRouterEntry OBJECT-TYPE SYNTAX IpDefaultRouterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a default router known to this entity." INDEX {ipDefaultRouterAddressType, ipDefaultRouterAddress, ipDefaultRouterIfIndex} ::= { ipDefaultRouterTable 1 } IpDefaultRouterEntry ::= SEQUENCE { ipDefaultRouterAddressType InetAddressType, ipDefaultRouterAddress InetAddress, ipDefaultRouterIfIndex InterfaceIndex, ipDefaultRouterLifetime Unsigned32, ipDefaultRouterPreference INTEGER } ipDefaultRouterAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type for this row." ::= { ipDefaultRouterEntry 1 } ipDefaultRouterAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the default router represented by this row. The address type of this object is specified in ipDefaultRouterAddressType. Implementers need to be aware that if the size of ipDefaultRouterAddress exceeds 115 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { ipDefaultRouterEntry 2 } ipDefaultRouterIfIndex OBJECT-TYPE SYNTAX InterfaceIndex Routhier, Ed. Standards Track [Page 75] RFC 4293 IP MIB April 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface by which the router can be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipDefaultRouterEntry 3 } ipDefaultRouterLifetime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The remaining length of time, in seconds, that this router will continue to be useful as a default router. A value of zero indicates that it is no longer useful as a default router. It is left to the implementer of the MIB as to whether a router with a lifetime of zero is removed from the list. For IPv6, this value should be extracted from the router advertisement messages." REFERENCE "For IPv6 RFC 2462 sections 4.2 and 6.3.4" ::= { ipDefaultRouterEntry 4 } ipDefaultRouterPreference OBJECT-TYPE SYNTAX INTEGER { reserved (-2), low (-1), medium (0), high (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of preference given to this router as a default router as described in he Default Router Preferences document. Treating the value as a 2 bit signed integer allows for simple arithmetic comparisons. For IPv4 routers or IPv6 routers that are not using the updated router advertisement format, this object is set to medium (0)." REFERENCE "RFC 4291, section 2.1" ::= { ipDefaultRouterEntry 5 } Routhier, Ed. Standards Track [Page 76] RFC 4293 IP MIB April 2006 -- -- Configuration information for constructing router advertisements -- ipv6RouterAdvertSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating SNMP managers to coordinate their use of the set operation in creating or modifying rows within this table. In order to use this lock to coordinate the use of set operations, managers should first retrieve ipv6RouterAdvertSpinLock. They should then determine the appropriate row to create or modify. Finally, they should issue the appropriate set command including the retrieved value of ipv6RouterAdvertSpinLock. If another manager has altered the table in the meantime, then the value of ipv6RouterAdvertSpinLock will have changed and the creation will fail as it will be specifying an incorrect value for ipv6RouterAdvertSpinLock. It is suggested, but not required, that the ipv6RouterAdvertSpinLock be the first var bind for each set of objects representing a 'row' in a PDU." ::= { ip 38 } ipv6RouterAdvertTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv6RouterAdvertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing information used to construct router advertisements." ::= { ip 39 } ipv6RouterAdvertEntry OBJECT-TYPE SYNTAX Ipv6RouterAdvertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information used to construct router advertisements. Information in this table is persistent, and when this object is written, the entity SHOULD save the change to non-volatile storage." INDEX { ipv6RouterAdvertIfIndex } Routhier, Ed. Standards Track [Page 77] RFC 4293 IP MIB April 2006 ::= { ipv6RouterAdvertTable 1 } Ipv6RouterAdvertEntry ::= SEQUENCE { ipv6RouterAdvertIfIndex InterfaceIndex, ipv6RouterAdvertSendAdverts TruthValue, ipv6RouterAdvertMaxInterval Unsigned32, ipv6RouterAdvertMinInterval Unsigned32, ipv6RouterAdvertManagedFlag TruthValue, ipv6RouterAdvertOtherConfigFlag TruthValue, ipv6RouterAdvertLinkMTU Unsigned32, ipv6RouterAdvertReachableTime Unsigned32, ipv6RouterAdvertRetransmitTime Unsigned32, ipv6RouterAdvertCurHopLimit Unsigned32, ipv6RouterAdvertDefaultLifetime Unsigned32, ipv6RouterAdvertRowStatus RowStatus } ipv6RouterAdvertIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface on which router advertisements constructed with this information will be transmitted. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipv6RouterAdvertEntry 1 } ipv6RouterAdvertSendAdverts OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A flag indicating whether the router sends periodic router advertisements and responds to router solicitations on this interface." REFERENCE "RFC 2461 Section 6.2.1" DEFVAL { false } ::= { ipv6RouterAdvertEntry 2 } ipv6RouterAdvertMaxInterval OBJECT-TYPE SYNTAX Unsigned32 (4..1800) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum time allowed between sending unsolicited router Routhier, Ed. Standards Track [Page 78] RFC 4293 IP MIB April 2006 advertisements from this interface." REFERENCE "RFC 2461 Section 6.2.1" DEFVAL { 600 } ::= { ipv6RouterAdvertEntry 3 } ipv6RouterAdvertMinInterval OBJECT-TYPE SYNTAX Unsigned32 (3..1350) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum time allowed between sending unsolicited router advertisements from this interface. The default is 0.33 * ipv6RouterAdvertMaxInterval, however, in the case of a low value for ipv6RouterAdvertMaxInterval, the minimum value for this object is restricted to 3." REFERENCE "RFC 2461 Section 6.2.1" ::= { ipv6RouterAdvertEntry 4 } ipv6RouterAdvertManagedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The true/false value to be placed into the 'managed address configuration' flag field in router advertisements sent from this interface." REFERENCE "RFC 2461 Section 6.2.1" DEFVAL { false } ::= { ipv6RouterAdvertEntry 5 } ipv6RouterAdvertOtherConfigFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The true/false value to be placed into the 'other stateful configuration' flag field in router advertisements sent from this interface." REFERENCE "RFC 2461 Section 6.2.1" DEFVAL { false } ::= { ipv6RouterAdvertEntry 6 } ipv6RouterAdvertLinkMTU OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current Routhier, Ed. Standards Track [Page 79] RFC 4293 IP MIB April 2006 DESCRIPTION "The value to be placed in MTU options sent by the router on this interface. A value of zero indicates that no MTU options are sent." REFERENCE "RFC 2461 Section 6.2.1" DEFVAL { 0 } ::= { ipv6RouterAdvertEntry 7 } ipv6RouterAdvertReachableTime OBJECT-TYPE SYNTAX Unsigned32 (0..3600000) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value to be placed in the reachable time field in router advertisement messages sent from this interface. A value of zero in the router advertisement indicates that the advertisement isn't specifying a value for reachable time." REFERENCE "RFC 2461 Section 6.2.1" DEFVAL { 0 } ::= { ipv6RouterAdvertEntry 8 } ipv6RouterAdvertRetransmitTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value to be placed in the retransmit timer field in router advertisements sent from this interface. A value of zero in the router advertisement indicates that the advertisement isn't specifying a value for retrans time." REFERENCE "RFC 2461 Section 6.2.1" DEFVAL { 0 } ::= { ipv6RouterAdvertEntry 9 } ipv6RouterAdvertCurHopLimit OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The default value to be placed in the current hop limit field in router advertisements sent from this interface. Routhier, Ed. Standards Track [Page 80] RFC 4293 IP MIB April 2006 The value should be set to the current diameter of the Internet. A value of zero in the router advertisement indicates that the advertisement isn't specifying a value for curHopLimit. The default should be set to the value specified in the IANA web pages (www.iana.org) at the time of implementation." REFERENCE "RFC 2461 Section 6.2.1" ::= { ipv6RouterAdvertEntry 10 } ipv6RouterAdvertDefaultLifetime OBJECT-TYPE SYNTAX Unsigned32 (0|4..9000) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value to be placed in the router lifetime field of router advertisements sent from this interface. This value MUST be either 0 or between ipv6RouterAdvertMaxInterval and 9000 seconds. A value of zero indicates that the router is not to be used as a default router. The default is 3 * ipv6RouterAdvertMaxInterval." REFERENCE "RFC 2461 Section 6.2.1" ::= { ipv6RouterAdvertEntry 11 } ipv6RouterAdvertRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. As all objects in this conceptual row have default values, a row can be created and made active by setting this object appropriately. The RowStatus TC requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ipv6RouterAdvertEntry 12 } -- Routhier, Ed. Standards Track [Page 81] RFC 4293 IP MIB April 2006 -- ICMP section -- icmp OBJECT IDENTIFIER ::= { mib-2 5 } -- -- ICMP non-message-specific counters -- -- These object IDs are reserved, as they were used in earlier -- versions of the MIB module. In theory, OIDs are not assigned -- until the specification is released as an RFC; however, as some -- companies may have shipped code based on earlier versions of -- the MIB, it seems best to reserve these OIDs. -- ::= { icmp 27 } -- ::= { icmp 28 } icmpStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IcmpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of generic system-wide ICMP counters." ::= { icmp 29 } icmpStatsEntry OBJECT-TYPE SYNTAX IcmpStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the icmpStatsTable." INDEX { icmpStatsIPVersion } ::= { icmpStatsTable 1 } IcmpStatsEntry ::= SEQUENCE { icmpStatsIPVersion InetVersion, icmpStatsInMsgs Counter32, icmpStatsInErrors Counter32, icmpStatsOutMsgs Counter32, icmpStatsOutErrors Counter32 } icmpStatsIPVersion OBJECT-TYPE SYNTAX InetVersion MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version of the statistics." Routhier, Ed. Standards Track [Page 82] RFC 4293 IP MIB April 2006 ::= { icmpStatsEntry 1 } icmpStatsInMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ICMP messages that the entity received. Note that this counter includes all those counted by icmpStatsInErrors." ::= { icmpStatsEntry 2 } icmpStatsInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP messages that the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.)." ::= { icmpStatsEntry 3 } icmpStatsOutMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ICMP messages that the entity attempted to send. Note that this counter includes all those counted by icmpStatsOutErrors." ::= { icmpStatsEntry 4 } icmpStatsOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ICMP messages that this entity did not send due to problems discovered within ICMP, such as a lack of buffers. This value should not include errors discovered outside the ICMP layer, such as the inability of IP to route the resultant datagram. In some implementations, there may be no types of error that contribute to this counter's value." ::= { icmpStatsEntry 5 } -- -- per-version, per-message type ICMP counters Routhier, Ed. Standards Track [Page 83] RFC 4293 IP MIB April 2006 -- icmpMsgStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IcmpMsgStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of system-wide per-version, per-message type ICMP counters." ::= { icmp 30 } icmpMsgStatsEntry OBJECT-TYPE SYNTAX IcmpMsgStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the icmpMsgStatsTable. The system should track each ICMP type value, even if that ICMP type is not supported by the system. However, a given row need not be instantiated unless a message of that type has been processed, i.e., the row for icmpMsgStatsType=X MAY be instantiated before but MUST be instantiated after the first message with Type=X is received or transmitted. After receiving or transmitting any succeeding messages with Type=X, the relevant counter must be incremented." INDEX { icmpMsgStatsIPVersion, icmpMsgStatsType } ::= { icmpMsgStatsTable 1 } IcmpMsgStatsEntry ::= SEQUENCE { icmpMsgStatsIPVersion InetVersion, icmpMsgStatsType Integer32, icmpMsgStatsInPkts Counter32, icmpMsgStatsOutPkts Counter32 } icmpMsgStatsIPVersion OBJECT-TYPE SYNTAX InetVersion MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version of the statistics." ::= { icmpMsgStatsEntry 1 } icmpMsgStatsType OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS not-accessible Routhier, Ed. Standards Track [Page 84] RFC 4293 IP MIB April 2006 STATUS current DESCRIPTION "The ICMP type field of the message type being counted by this row. Note that ICMP message types are scoped by the address type in use." REFERENCE "http://www.iana.org/assignments/icmp-parameters and http://www.iana.org/assignments/icmpv6-parameters" ::= { icmpMsgStatsEntry 2 } icmpMsgStatsInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of input packets for this AF and type." ::= { icmpMsgStatsEntry 3 } icmpMsgStatsOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output packets for this AF and type." ::= { icmpMsgStatsEntry 4 } -- -- conformance information -- ipMIBConformance OBJECT IDENTIFIER ::= { ipMIB 2 } ipMIBCompliances OBJECT IDENTIFIER ::= { ipMIBConformance 1 } ipMIBGroups OBJECT IDENTIFIER ::= { ipMIBConformance 2 } -- compliance statements ipMIBCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems that implement IP - either IPv4 or IPv6. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which we have the following compliance requirements, expressed in OBJECT clause form in this description clause: Routhier, Ed. Standards Track [Page 85] RFC 4293 IP MIB April 2006 -- OBJECT ipSystemStatsIPVersion -- SYNTAX InetVersion {ipv4(1), ipv6(2)} -- DESCRIPTION -- This MIB requires support for only IPv4 and IPv6 -- versions. -- -- OBJECT ipIfStatsIPVersion -- SYNTAX InetVersion {ipv4(1), ipv6(2)} -- DESCRIPTION -- This MIB requires support for only IPv4 and IPv6 -- versions. -- -- OBJECT icmpStatsIPVersion -- SYNTAX InetVersion {ipv4(1), ipv6(2)} -- DESCRIPTION -- This MIB requires support for only IPv4 and IPv6 -- versions. -- -- OBJECT icmpMsgStatsIPVersion -- SYNTAX InetVersion {ipv4(1), ipv6(2)} -- DESCRIPTION -- This MIB requires support for only IPv4 and IPv6 -- versions. -- -- OBJECT ipAddressPrefixType -- SYNTAX InetAddressType {ipv4(1), ipv6(2)} -- DESCRIPTION -- This MIB requires support for only global IPv4 and -- IPv6 address types. -- -- OBJECT ipAddressPrefixPrefix -- SYNTAX InetAddress (Size(4 | 16)) -- DESCRIPTION -- This MIB requires support for only global IPv4 and -- IPv6 addresses and so the size can be either 4 or -- 16 bytes. -- -- OBJECT ipAddressAddrType -- SYNTAX InetAddressType {ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This MIB requires support for only global and -- non-global IPv4 and IPv6 address types. -- -- OBJECT ipAddressAddr -- SYNTAX InetAddress (Size(4 | 8 | 16 | 20)) -- DESCRIPTION -- This MIB requires support for only global and Routhier, Ed. Standards Track [Page 86] RFC 4293 IP MIB April 2006 -- non-global IPv4 and IPv6 addresses and so the size -- can be 4, 8, 16, or 20 bytes. -- -- OBJECT ipNetToPhysicalNetAddressType -- SYNTAX InetAddressType {ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This MIB requires support for only global and -- non-global IPv4 and IPv6 address types. -- -- OBJECT ipNetToPhysicalNetAddress -- SYNTAX InetAddress (Size(4 | 8 | 16 | 20)) -- DESCRIPTION -- This MIB requires support for only global and -- non-global IPv4 and IPv6 addresses and so the size -- can be 4, 8, 16, or 20 bytes. -- -- OBJECT ipDefaultRouterAddressType -- SYNTAX InetAddressType {ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This MIB requires support for only global and -- non-global IPv4 and IPv6 address types. -- -- OBJECT ipDefaultRouterAddress -- SYNTAX InetAddress (Size(4 | 8 | 16 | 20)) -- DESCRIPTION -- This MIB requires support for only global and -- non-global IPv4 and IPv6 addresses and so the size -- can be 4, 8, 16, or 20 bytes." MODULE -- this module MANDATORY-GROUPS { ipSystemStatsGroup, ipAddressGroup, ipNetToPhysicalGroup, ipDefaultRouterGroup, icmpStatsGroup } GROUP ipSystemStatsHCOctetGroup DESCRIPTION "This group is mandatory for systems that have an aggregate bandwidth of greater than 20MB. Including this group does not allow an entity to neglect the 32 bit versions of these objects." GROUP ipSystemStatsHCPacketGroup DESCRIPTION "This group is mandatory for systems that have an aggregate bandwidth of greater than 650MB. Including this group Routhier, Ed. Standards Track [Page 87] RFC 4293 IP MIB April 2006 does not allow an entity to neglect the 32 bit versions of these objects." GROUP ipIfStatsGroup DESCRIPTION "This group is optional for all systems." GROUP ipIfStatsHCOctetGroup DESCRIPTION "This group is mandatory for systems that include the ipIfStatsGroup and include links with bandwidths of greater than 20MB. Including this group does not allow an entity to neglect the 32 bit versions of these objects." GROUP ipIfStatsHCPacketGroup DESCRIPTION "This group is mandatory for systems that include the ipIfStatsGroup and include links with bandwidths of greater than 650MB. Including this group does not allow an entity to neglect the 32 bit versions of these objects." GROUP ipv4GeneralGroup DESCRIPTION "This group is mandatory for all systems supporting IPv4." GROUP ipv4IfGroup DESCRIPTION "This group is mandatory for all systems supporting IPv4." GROUP ipv4SystemStatsGroup DESCRIPTION "This group is mandatory for all systems supporting IPv4." GROUP ipv4SystemStatsHCPacketGroup DESCRIPTION "This group is mandatory for all systems supporting IPv4 and that have an aggregate bandwidth of greater than 650MB. Including this group does not allow an entity to neglect the 32 bit versions of these objects." GROUP ipv4IfStatsGroup DESCRIPTION "This group is mandatory for all systems supporting IPv4 and including the ipIfStatsGroup." GROUP ipv4IfStatsHCPacketGroup DESCRIPTION "This group is mandatory for all systems supporting IPv4 and Routhier, Ed. Standards Track [Page 88] RFC 4293 IP MIB April 2006 including the ipIfStatsHCPacketGroup. Including this group does not allow an entity to neglect the 32 bit versions of these objects." GROUP ipv6GeneralGroup2 DESCRIPTION "This group is mandatory for all systems supporting IPv6." GROUP ipv6IfGroup DESCRIPTION "This group is mandatory for all systems supporting IPv6." GROUP ipAddressPrefixGroup DESCRIPTION "This group is mandatory for all systems supporting IPv6." GROUP ipv6ScopeGroup DESCRIPTION "This group is mandatory for all systems supporting IPv6." GROUP ipv6RouterAdvertGroup DESCRIPTION "This group is mandatory for all IPv6 routers." GROUP ipLastChangeGroup DESCRIPTION "This group is optional for all agents." OBJECT ipv6IpForwarding MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6IpDefaultHopLimit MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv4InterfaceEnableStatus MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6InterfaceEnableStatus MIN-ACCESS read-only Routhier, Ed. Standards Track [Page 89] RFC 4293 IP MIB April 2006 DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6InterfaceForwarding MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipAddressSpinLock MIN-ACCESS not-accessible DESCRIPTION "An agent is not required to provide write access to this object. However, if an agent provides write access to any of the other objects in the ipAddressGroup, it SHOULD provide write access to this object as well." OBJECT ipAddressIfIndex MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT ipAddressType MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT ipAddressStatus MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT ipAddressRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT ipAddressStorageType MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object. Routhier, Ed. Standards Track [Page 90] RFC 4293 IP MIB April 2006 If an agent allows this object to be written or created, it is not required to allow this object to be set to readOnly, permanent, or nonVolatile." OBJECT ipNetToPhysicalPhysAddress MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT ipNetToPhysicalType MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." OBJECT ipv6RouterAdvertSpinLock MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object. However, if an agent provides write access to any of the other objects in the ipv6RouterAdvertGroup, it SHOULD provide write access to this object as well." OBJECT ipv6RouterAdvertSendAdverts MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertMaxInterval MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertMinInterval MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertManagedFlag MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." Routhier, Ed. Standards Track [Page 91] RFC 4293 IP MIB April 2006 OBJECT ipv6RouterAdvertOtherConfigFlag MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertLinkMTU MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertReachableTime MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertRetransmitTime MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertCurHopLimit MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertDefaultLifetime MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write access to this object." OBJECT ipv6RouterAdvertRowStatus MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." ::= { ipMIBCompliances 2 } -- units of conformance ipv4GeneralGroup OBJECT-GROUP OBJECTS { ipForwarding, ipDefaultTTL, ipReasmTimeout } Routhier, Ed. Standards Track [Page 92] RFC 4293 IP MIB April 2006 STATUS current DESCRIPTION "The group of IPv4-specific objects for basic management of IPv4 entities." ::= { ipMIBGroups 3 } ipv4IfGroup OBJECT-GROUP OBJECTS { ipv4InterfaceReasmMaxSize, ipv4InterfaceEnableStatus, ipv4InterfaceRetransmitTime } STATUS current DESCRIPTION "The group of IPv4-specific objects for basic management of IPv4 interfaces." ::= { ipMIBGroups 4 } ipv6GeneralGroup2 OBJECT-GROUP OBJECTS { ipv6IpForwarding, ipv6IpDefaultHopLimit } STATUS current DESCRIPTION "The IPv6 group of objects providing for basic management of IPv6 entities." ::= { ipMIBGroups 5 } ipv6IfGroup OBJECT-GROUP OBJECTS { ipv6InterfaceReasmMaxSize, ipv6InterfaceIdentifier, ipv6InterfaceEnableStatus, ipv6InterfaceReachableTime, ipv6InterfaceRetransmitTime, ipv6InterfaceForwarding } STATUS current DESCRIPTION "The group of IPv6-specific objects for basic management of IPv6 interfaces." ::= { ipMIBGroups 6 } ipLastChangeGroup OBJECT-GROUP OBJECTS { ipv4InterfaceTableLastChange, ipv6InterfaceTableLastChange, ipIfStatsTableLastChange } STATUS current DESCRIPTION "The last change objects associated with this MIB. These objects are optional for all agents. They SHOULD be implemented on agents where it is possible to determine the proper values. Where it is not possible to determine the proper values, for example when the tables are split amongst several sub-agents using AgentX, the agent MUST NOT implement these objects to return an incorrect or static value." ::= { ipMIBGroups 7 } Routhier, Ed. Standards Track [Page 93] RFC 4293 IP MIB April 2006 ipSystemStatsGroup OBJECT-GROUP OBJECTS { ipSystemStatsInReceives, ipSystemStatsInOctets, ipSystemStatsInHdrErrors, ipSystemStatsInNoRoutes, ipSystemStatsInAddrErrors, ipSystemStatsInUnknownProtos, ipSystemStatsInTruncatedPkts, ipSystemStatsInForwDatagrams, ipSystemStatsReasmReqds, ipSystemStatsReasmOKs, ipSystemStatsReasmFails, ipSystemStatsInDiscards, ipSystemStatsInDelivers, ipSystemStatsOutRequests, ipSystemStatsOutNoRoutes, ipSystemStatsOutForwDatagrams, ipSystemStatsOutDiscards, ipSystemStatsOutFragReqds, ipSystemStatsOutFragOKs, ipSystemStatsOutFragFails, ipSystemStatsOutFragCreates, ipSystemStatsOutTransmits, ipSystemStatsOutOctets, ipSystemStatsInMcastPkts, ipSystemStatsInMcastOctets, ipSystemStatsOutMcastPkts, ipSystemStatsOutMcastOctets, ipSystemStatsDiscontinuityTime, ipSystemStatsRefreshRate } STATUS current DESCRIPTION "IP system wide statistics." ::= { ipMIBGroups 8 } ipv4SystemStatsGroup OBJECT-GROUP OBJECTS { ipSystemStatsInBcastPkts, ipSystemStatsOutBcastPkts } STATUS current DESCRIPTION "IPv4 only system wide statistics." ::= { ipMIBGroups 9 } ipSystemStatsHCOctetGroup OBJECT-GROUP OBJECTS { ipSystemStatsHCInOctets, ipSystemStatsHCOutOctets, ipSystemStatsHCInMcastOctets, ipSystemStatsHCOutMcastOctets } Routhier, Ed. Standards Track [Page 94] RFC 4293 IP MIB April 2006 STATUS current DESCRIPTION "IP system wide statistics for systems that may overflow the standard octet counters within 1 hour." ::= { ipMIBGroups 10 } ipSystemStatsHCPacketGroup OBJECT-GROUP OBJECTS { ipSystemStatsHCInReceives, ipSystemStatsHCInForwDatagrams, ipSystemStatsHCInDelivers, ipSystemStatsHCOutRequests, ipSystemStatsHCOutForwDatagrams, ipSystemStatsHCOutTransmits, ipSystemStatsHCInMcastPkts, ipSystemStatsHCOutMcastPkts } STATUS current DESCRIPTION "IP system wide statistics for systems that may overflow the standard packet counters within 1 hour." ::= { ipMIBGroups 11 } ipv4SystemStatsHCPacketGroup OBJECT-GROUP OBJECTS { ipSystemStatsHCInBcastPkts, ipSystemStatsHCOutBcastPkts } STATUS current DESCRIPTION "IPv4 only system wide statistics for systems that may overflow the standard packet counters within 1 hour." ::= { ipMIBGroups 12 } ipIfStatsGroup OBJECT-GROUP OBJECTS { ipIfStatsInReceives, ipIfStatsInOctets, ipIfStatsInHdrErrors, ipIfStatsInNoRoutes, ipIfStatsInAddrErrors, ipIfStatsInUnknownProtos, ipIfStatsInTruncatedPkts, ipIfStatsInForwDatagrams, ipIfStatsReasmReqds, ipIfStatsReasmOKs, ipIfStatsReasmFails, ipIfStatsInDiscards, ipIfStatsInDelivers, ipIfStatsOutRequests, ipIfStatsOutForwDatagrams, ipIfStatsOutDiscards, ipIfStatsOutFragReqds, ipIfStatsOutFragOKs, ipIfStatsOutFragFails, ipIfStatsOutFragCreates, ipIfStatsOutTransmits, ipIfStatsOutOctets, ipIfStatsInMcastPkts, ipIfStatsInMcastOctets, ipIfStatsOutMcastPkts, ipIfStatsOutMcastOctets, ipIfStatsDiscontinuityTime, ipIfStatsRefreshRate } STATUS current DESCRIPTION Routhier, Ed. Standards Track [Page 95] RFC 4293 IP MIB April 2006 "IP per-interface statistics." ::= { ipMIBGroups 13 } ipv4IfStatsGroup OBJECT-GROUP OBJECTS { ipIfStatsInBcastPkts, ipIfStatsOutBcastPkts } STATUS current DESCRIPTION "IPv4 only per-interface statistics." ::= { ipMIBGroups 14 } ipIfStatsHCOctetGroup OBJECT-GROUP OBJECTS { ipIfStatsHCInOctets, ipIfStatsHCOutOctets, ipIfStatsHCInMcastOctets, ipIfStatsHCOutMcastOctets } STATUS current DESCRIPTION "IP per-interfaces statistics for systems that include interfaces that may overflow the standard octet counters within 1 hour." ::= { ipMIBGroups 15 } ipIfStatsHCPacketGroup OBJECT-GROUP OBJECTS { ipIfStatsHCInReceives, ipIfStatsHCInForwDatagrams, ipIfStatsHCInDelivers, ipIfStatsHCOutRequests, ipIfStatsHCOutForwDatagrams, ipIfStatsHCOutTransmits, ipIfStatsHCInMcastPkts, ipIfStatsHCOutMcastPkts } STATUS current DESCRIPTION "IP per-interfaces statistics for systems that include interfaces that may overflow the standard packet counters within 1 hour." ::= { ipMIBGroups 16 } ipv4IfStatsHCPacketGroup OBJECT-GROUP OBJECTS { ipIfStatsHCInBcastPkts, ipIfStatsHCOutBcastPkts } STATUS current DESCRIPTION "IPv4 only per-interface statistics for systems that include interfaces that may overflow the standard packet counters within 1 hour." ::= { ipMIBGroups 17 } ipAddressPrefixGroup OBJECT-GROUP OBJECTS { ipAddressPrefixOrigin, ipAddressPrefixOnLinkFlag, ipAddressPrefixAutonomousFlag, ipAddressPrefixAdvPreferredLifetime, ipAddressPrefixAdvValidLifetime } STATUS current Routhier, Ed. Standards Track [Page 96] RFC 4293 IP MIB April 2006 DESCRIPTION "The group of objects for providing information about address prefixes used by this node." ::= { ipMIBGroups 18 } ipAddressGroup OBJECT-GROUP OBJECTS { ipAddressSpinLock, ipAddressIfIndex, ipAddressType, ipAddressPrefix, ipAddressOrigin, ipAddressStatus, ipAddressCreated, ipAddressLastChanged, ipAddressRowStatus, ipAddressStorageType } STATUS current DESCRIPTION "The group of objects for providing information about the addresses relevant to this entity's interfaces." ::= { ipMIBGroups 19 } ipNetToPhysicalGroup OBJECT-GROUP OBJECTS { ipNetToPhysicalPhysAddress, ipNetToPhysicalLastUpdated, ipNetToPhysicalType, ipNetToPhysicalState, ipNetToPhysicalRowStatus } STATUS current DESCRIPTION "The group of objects for providing information about the mappings of network address to physical address known to this node." ::= { ipMIBGroups 20 } ipv6ScopeGroup OBJECT-GROUP OBJECTS { ipv6ScopeZoneIndexLinkLocal, ipv6ScopeZoneIndex3, ipv6ScopeZoneIndexAdminLocal, ipv6ScopeZoneIndexSiteLocal, ipv6ScopeZoneIndex6, ipv6ScopeZoneIndex7, ipv6ScopeZoneIndexOrganizationLocal, ipv6ScopeZoneIndex9, ipv6ScopeZoneIndexA, ipv6ScopeZoneIndexB, ipv6ScopeZoneIndexC, ipv6ScopeZoneIndexD } STATUS current DESCRIPTION "The group of objects for managing IPv6 scope zones." ::= { ipMIBGroups 21 } ipDefaultRouterGroup OBJECT-GROUP OBJECTS { ipDefaultRouterLifetime, ipDefaultRouterPreference } Routhier, Ed. Standards Track [Page 97] RFC 4293 IP MIB April 2006 STATUS current DESCRIPTION "The group of objects for providing information about default routers known to this node." ::= { ipMIBGroups 22 } ipv6RouterAdvertGroup OBJECT-GROUP OBJECTS { ipv6RouterAdvertSpinLock, ipv6RouterAdvertSendAdverts, ipv6RouterAdvertMaxInterval, ipv6RouterAdvertMinInterval, ipv6RouterAdvertManagedFlag, ipv6RouterAdvertOtherConfigFlag, ipv6RouterAdvertLinkMTU, ipv6RouterAdvertReachableTime, ipv6RouterAdvertRetransmitTime, ipv6RouterAdvertCurHopLimit, ipv6RouterAdvertDefaultLifetime, ipv6RouterAdvertRowStatus } STATUS current DESCRIPTION "The group of objects for controlling information advertised by IPv6 routers." ::= { ipMIBGroups 23 } icmpStatsGroup OBJECT-GROUP OBJECTS {icmpStatsInMsgs, icmpStatsInErrors, icmpStatsOutMsgs, icmpStatsOutErrors, icmpMsgStatsInPkts, icmpMsgStatsOutPkts } STATUS current DESCRIPTION "The group of objects providing ICMP statistics." ::= { ipMIBGroups 24 } -- -- Deprecated objects -- ipInReceives OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of input datagrams received from interfaces, including those received in error. This object has been deprecated, as a new IP version-neutral Routhier, Ed. Standards Track [Page 98] RFC 4293 IP MIB April 2006 table has been added. It is loosely replaced by ipSystemStatsInRecieves." ::= { ip 3 } ipInHdrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of input datagrams discarded due to errors in their IPv4 headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IPv4 options, etc. This object has been deprecated as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInHdrErrors." ::= { ip 4 } ipInAddrErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of input datagrams discarded because the IPv4 address in their IPv4 header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IPv4 routers, and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInAddrErrors." ::= { ip 5 } ipForwDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of input datagrams for which this entity was not their final IPv4 destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IPv4 routers, this counter will include only those packets which Routhier, Ed. Standards Track [Page 99] RFC 4293 IP MIB April 2006 were Source-Routed via this entity, and the Source-Route option processing was successful. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInForwDatagrams." ::= { ip 6 } ipInUnknownProtos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInUnknownProtos." ::= { ip 7 } ipInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of input IPv4 datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInDiscards." ::= { ip 8 } ipInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of input datagrams successfully delivered to IPv4 user-protocols (including ICMP). This object has been deprecated as a new IP version neutral table has been added. It is loosely replaced by Routhier, Ed. Standards Track [Page 100] RFC 4293 IP MIB April 2006 ipSystemStatsIndelivers." ::= { ip 9 } ipOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of IPv4 datagrams which local IPv4 user protocols (including ICMP) supplied to IPv4 in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutRequests." ::= { ip 10 } ipOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of output IPv4 datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutDiscards." ::= { ip 11 } ipOutNoRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of IPv4 datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route' criterion. Note that this includes any datagrams which a host cannot route because all of its default routers are down. This object has been deprecated, as a new IP version-neutral Routhier, Ed. Standards Track [Page 101] RFC 4293 IP MIB April 2006 table has been added. It is loosely replaced by ipSystemStatsOutNoRoutes." ::= { ip 12 } ipReasmReqds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of IPv4 fragments received which needed to be reassembled at this entity. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsReasmReqds." ::= { ip 14 } ipReasmOKs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of IPv4 datagrams successfully re-assembled. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsReasmOKs." ::= { ip 15 } ipReasmFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of failures detected by the IPv4 re-assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IPv4 fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsReasmFails." ::= { ip 16 } ipFragOKs OBJECT-TYPE SYNTAX Counter32 Routhier, Ed. Standards Track [Page 102] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of IPv4 datagrams that have been successfully fragmented at this entity. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutFragOKs." ::= { ip 17 } ipFragFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of IPv4 datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutFragFails." ::= { ip 18 } ipFragCreates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of IPv4 datagram fragments that have been generated as a result of fragmentation at this entity. This object has been deprecated as a new IP version neutral table has been added. It is loosely replaced by ipSystemStatsOutFragCreates." ::= { ip 19 } ipRoutingDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries. Routhier, Ed. Standards Track [Page 103] RFC 4293 IP MIB April 2006 This object was defined in pre-IPv6 versions of the IP MIB. It was implicitly IPv4 only, but the original specifications did not indicate this protocol restriction. In order to clarify the specifications, this object has been deprecated and a similar, but more thoroughly clarified, object has been added to the IP-FORWARD-MIB." ::= { ip 23 } -- the deprecated IPv4 address table ipAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddrEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The table of addressing information relevant to this entity's IPv4 addresses. This table has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by the ipAddressTable although several objects that weren't deemed useful weren't carried forward while another (ipAdEntReasmMaxSize) was moved to the ipv4InterfaceTable." ::= { ip 20 } ipAddrEntry OBJECT-TYPE SYNTAX IpAddrEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The addressing information for one of this entity's IPv4 addresses." INDEX { ipAdEntAddr } ::= { ipAddrTable 1 } IpAddrEntry ::= SEQUENCE { ipAdEntAddr IpAddress, ipAdEntIfIndex INTEGER, ipAdEntNetMask IpAddress, ipAdEntBcastAddr INTEGER, ipAdEntReasmMaxSize INTEGER } ipAdEntAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION Routhier, Ed. Standards Track [Page 104] RFC 4293 IP MIB April 2006 "The IPv4 address to which this entry's addressing information pertains." ::= { ipAddrEntry 1 } ipAdEntIfIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipAddrEntry 2 } ipAdEntNetMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The subnet mask associated with the IPv4 address of this entry. The value of the mask is an IPv4 address with all the network bits set to 1 and all the hosts bits set to 0." ::= { ipAddrEntry 3 } ipAdEntBcastAddr OBJECT-TYPE SYNTAX INTEGER (0..1) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of the least-significant bit in the IPv4 broadcast address used for sending datagrams on the (logical) interface associated with the IPv4 address of this entry. For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcast addresses used by the entity on this (logical) interface." ::= { ipAddrEntry 4 } ipAdEntReasmMaxSize OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The size of the largest IPv4 datagram which this entity can re-assemble from incoming IPv4 fragmented datagrams received on this interface." ::= { ipAddrEntry 5 } Routhier, Ed. Standards Track [Page 105] RFC 4293 IP MIB April 2006 -- the deprecated IPv4 Address Translation table -- The Address Translation tables contain the IpAddress to -- "physical" address equivalences. Some interfaces do not -- use translation tables for determining address -- equivalences (e.g., DDN-X.25 has an algorithmic method); -- if all interfaces are of this type, then the Address -- Translation table is empty, i.e., has zero entries. ipNetToMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF IpNetToMediaEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The IPv4 Address Translation table used for mapping from IPv4 addresses to physical addresses. This table has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by the ipNetToPhysicalTable." ::= { ip 22 } ipNetToMediaEntry OBJECT-TYPE SYNTAX IpNetToMediaEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Each entry contains one IpAddress to `physical' address equivalence." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress } ::= { ipNetToMediaTable 1 } IpNetToMediaEntry ::= SEQUENCE { ipNetToMediaIfIndex INTEGER, ipNetToMediaPhysAddress PhysAddress, ipNetToMediaNetAddress IpAddress, ipNetToMediaType INTEGER } ipNetToMediaIfIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the Routhier, Ed. Standards Track [Page 106] RFC 4293 IP MIB April 2006 same value of the IF-MIB's ifIndex. This object predates the rule limiting index objects to a max access value of 'not-accessible' and so continues to use a value of 'read-create'." ::= { ipNetToMediaEntry 1 } ipNetToMediaPhysAddress OBJECT-TYPE SYNTAX PhysAddress (SIZE(0..65535)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The media-dependent `physical' address. This object should return 0 when this entry is in the 'incomplete' state. As the entries in this table are typically not persistent when this object is written the entity should not save the change to non-volatile storage. Note: a stronger requirement is not used because this object was previously defined." ::= { ipNetToMediaEntry 2 } ipNetToMediaNetAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The IpAddress corresponding to the media-dependent `physical' address. This object predates the rule limiting index objects to a max access value of 'not-accessible' and so continues to use a value of 'read-create'." ::= { ipNetToMediaEntry 3 } ipNetToMediaType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The type of mapping. Setting this object to the value invalid(2) has the effect Routhier, Ed. Standards Track [Page 107] RFC 4293 IP MIB April 2006 of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively dis-associates the interface identified with said entry from the mapping identified with said entry. It is an implementation- specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object. As the entries in this table are typically not persistent when this object is written the entity should not save the change to non-volatile storage. Note: a stronger requirement is not used because this object was previously defined." ::= { ipNetToMediaEntry 4 } -- the deprecated ICMP group icmpInMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsInMsgs." ::= { icmp 1 } icmpInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP messages which the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.). This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsInErrors." ::= { icmp 2 } Routhier, Ed. Standards Track [Page 108] RFC 4293 IP MIB April 2006 icmpInDestUnreachs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Destination Unreachable messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 3 } icmpInTimeExcds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Time Exceeded messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 4 } icmpInParmProbs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Parameter Problem messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 5 } icmpInSrcQuenchs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Source Quench messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 6 } Routhier, Ed. Standards Track [Page 109] RFC 4293 IP MIB April 2006 icmpInRedirects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Redirect messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 7 } icmpInEchos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Echo (request) messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 8 } icmpInEchoReps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Echo Reply messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 9 } icmpInTimestamps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Timestamp (request) messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 10 } Routhier, Ed. Standards Track [Page 110] RFC 4293 IP MIB April 2006 icmpInTimestampReps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Timestamp Reply messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 11 } icmpInAddrMasks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Address Mask Request messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 12 } icmpInAddrMaskReps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Address Mask Reply messages received. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 13 } icmpOutMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsOutMsgs." Routhier, Ed. Standards Track [Page 111] RFC 4293 IP MIB April 2006 ::= { icmp 14 } icmpOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP messages which this entity did not send due to problems discovered within ICMP, such as a lack of buffers. This value should not include errors discovered outside the ICMP layer, such as the inability of IP to route the resultant datagram. In some implementations, there may be no types of error which contribute to this counter's value. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsOutErrors." ::= { icmp 15 } icmpOutDestUnreachs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Destination Unreachable messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 16 } icmpOutTimeExcds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Time Exceeded messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 17 } icmpOutParmProbs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated Routhier, Ed. Standards Track [Page 112] RFC 4293 IP MIB April 2006 DESCRIPTION "The number of ICMP Parameter Problem messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 18 } icmpOutSrcQuenchs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Source Quench messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 19 } icmpOutRedirects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 20 } icmpOutEchos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Echo (request) messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 21 } icmpOutEchoReps OBJECT-TYPE SYNTAX Counter32 Routhier, Ed. Standards Track [Page 113] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Echo Reply messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 22 } icmpOutTimestamps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Timestamp (request) messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 23 } icmpOutTimestampReps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Timestamp Reply messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 24 } icmpOutAddrMasks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Address Mask Request messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 25 } icmpOutAddrMaskReps OBJECT-TYPE SYNTAX Counter32 Routhier, Ed. Standards Track [Page 114] RFC 4293 IP MIB April 2006 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of ICMP Address Mask Reply messages sent. This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable." ::= { icmp 26 } -- deprecated conformance information -- deprecated compliance statements ipMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for systems that implement only IPv4. For version-independence, this compliance statement is deprecated in favor of ipMIBCompliance2." MODULE -- this module MANDATORY-GROUPS { ipGroup, icmpGroup } ::= { ipMIBCompliances 1 } -- deprecated units of conformance ipGroup OBJECT-GROUP OBJECTS { ipForwarding, ipDefaultTTL, ipInReceives, ipInHdrErrors, ipInAddrErrors, ipForwDatagrams, ipInUnknownProtos, ipInDiscards, ipInDelivers, ipOutRequests, ipOutDiscards, ipOutNoRoutes, ipReasmTimeout, ipReasmReqds, ipReasmOKs, ipReasmFails, ipFragOKs, ipFragFails, ipFragCreates, ipAdEntAddr, ipAdEntIfIndex, ipAdEntNetMask, ipAdEntBcastAddr, ipAdEntReasmMaxSize, ipNetToMediaIfIndex, ipNetToMediaPhysAddress, ipNetToMediaNetAddress, ipNetToMediaType, ipRoutingDiscards } STATUS deprecated DESCRIPTION "The ip group of objects providing for basic management of IP entities, exclusive of the management of IP routes. Routhier, Ed. Standards Track [Page 115] RFC 4293 IP MIB April 2006 As part of the version independence, this group has been deprecated. " ::= { ipMIBGroups 1 } icmpGroup OBJECT-GROUP OBJECTS { icmpInMsgs, 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 } STATUS deprecated DESCRIPTION "The icmp group of objects providing ICMP statistics. As part of the version independence, this group has been deprecated. " ::= { ipMIBGroups 2 } END 6. Previous Work This document contains objects modified from RFC 1213 [11], RFC 2011 [12], RFC 2465 [13], and RFC 2466 [14]. 7. References 7.1. Normative References [1] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Routhier, Ed. Standards Track [Page 116] RFC 4293 IP MIB April 2006 [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [6] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [7] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [8] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, November 2005. 7.2. Informative References [9] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [10] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [11] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [12] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996. [13] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998. [14] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: ICMPv6 Group", RFC 2466, December 1998. [15] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [16] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006. Routhier, Ed. Standards Track [Page 117] RFC 4293 IP MIB April 2006 [17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: ipForwarding and ipv6IpForwarding - these objects allow a manager to enable or disable the routing functions on the entity. By disabling the routing functions, an attacker would possibly be able to deny service to users. By enabling the routing functions, an attacker could open a conduit into an area. This might result in the area providing transit for packets it shouldn't or might allow the attacker access to the area bypassing security safeguards. ipDefaultTTL and ipv6IpDefaultHopLimit - these objects allow a manager to determine the diameter of the valid area for a packet. By decreasing the value of these objects, an attacker could cause packets to be discarded before reaching their destinations. ipv4InterfaceEnableStatus and ipv6InterfaceEnableStatus - these objects allow a manager to enable or disable IPv4 and IPv6 on a specific interface. By enabling a protocol on an interface, an attacker might be able to create an unsecured path into a node (or through it if routing is also enabled). By disabling a protocol on an interface, an attacker might be able to force packets to be routed through some other interface or deny access to some or all of the network via that protocol. ipAddressTable - the objects in this table specify the addresses in use on this node. By modifying this information, an attacker can cause a node to either ignore messages destined to it or accept (at least at the IP layer) messages it would otherwise ignore. The use of filtering or security associations may reduce the potential damage in the latter case. ipv6RouterAdvertTable - the objects in this table specify the information that a router should propagate in its routing advertisement messages. By modifying this information, an attacker can interfere with the auto-configuration of all hosts on the link. Most modifications to this table will result in a Routhier, Ed. Standards Track [Page 118] RFC 4293 IP MIB April 2006 denial of service to some or all hosts on the link. However two objects, ipv6RouterAdvertManagedFlag and ipv6RouterAdvertOtherConfigFlag, indicate if a host should acquire configuration information from some other source. By enabling these, an attacker might be able to cause a host to retrieve its configuration information from a compromised source. ipNetToPhysicalPhysAddress and ipNetToPhysicalType - these objects specify information used to translate a network (IP) address into a media dependent address. By modifying these objects, an attacker could disable communication with a node or divert messages from one node to another. However, the attacker may be able to carry out a similar attack by simply responding to the ARP or ND request made by the target node. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Essentially, all of the objects in this MIB could be considered sensitive as they report on the status of the IP modules within a system. However, the ipSystemStatsTable, ipIfStatsTable, and ipAddressTable are likely to be of most interest to an attacker. The statistics tables supply information about the quantity and type of traffic this node is processing and, especially for transit providers, may be considered sensitive. The address table provides a convenient list of all addresses in use by this node. Each address in isolation is unremarkable, however, the total list would allow an attacker to correlate otherwise unrelated traffic. For example, an attacker might be able to correlate an RFC 3041 [15] private address with known public addresses, thus circumventing the intentions of RFC 3041. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [9], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Routhier, Ed. Standards Track [Page 119] RFC 4293 IP MIB April 2006 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Acknowledgements Reviews and other contributions were made by: Dario Acornero, Cisco Systems Mike MacFaden, VMWare Keith McCloghrie, Cisco Systems Juergen Schoenwalder, TU Braunschweig Margaret Wasserman, Devicescape 10. Authors This document was written by the IPv6 MIB revision design team: Bill Fenner, AT&T Labs -- Research EMail: fenner@research.att.com Brian Haberman EMail: brian@innovationslab.net Shawn A. Routhier EMail: sar@iwl.com Dave Thaler, Microsoft EMail: dthaler@microsoft.com This document updates parts of the MIBs from several other documents. RFC 2011 is the previous update to the IP MIB. RFC 2465 and RFC 2466 are the first versions that specified IPv6 addresses and information. RFC 2011: Keith McCloghrie, Cisco Systems (Editor) RFC 2465 and RFC 2466: Dimitry Haskin, Bay Networks Steve Onishi, Bay Networks Routhier, Ed. Standards Track [Page 120] RFC 4293 IP MIB April 2006 Editor's Contact Information Shawn A. Routhier Interworking Labs 108 Whispering Pines Dr. Suite 235 Scotts Valley, CA 95066 USA EMail: sar@iwl.com Routhier, Ed. Standards Track [Page 121] RFC 4293 IP MIB April 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Routhier, Ed. Standards Track [Page 122] snmp-mibs-downloader-1.1/mibrfcs/rfc4295.txt0000644000000000000000000063021611402176072015576 0ustar Network Working Group G. Keeni Request for Comments: 4295 Cyber Solutions Inc. Category: Standards Track K. Koide Tohoku University K. Nagami INTEC NetCore Inc. S. Gundavelli Cisco Systems Inc. April 2006 Mobile IPv6 Management Information Base 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 2.1. The Mobile IPv6 Protocol Entities ..........................2 2.2. Terminology ................................................3 3. Mobile IPv6 Monitoring and Control Requirements .................3 4. MIB Design ......................................................4 5. The Mobile-IPv6 MIB .............................................6 6. Security Considerations .......................................104 7. IANA Considerations ...........................................106 8. References ....................................................106 8.1. Normative References .....................................106 8.2. Informative References ...................................107 9. Acknowledgements ..............................................107 Keeni, et al. Standards Track [Page 1] RFC 4295 MOBILEIPV6-MIB April 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview 2.1. The Mobile IPv6 Protocol Entities Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. An entity that implements the MIPv6 protocol is a MIPv6 entity. There are three types of entities envisaged by the MIPv6 protocol. mobile node (MN): A node that can change its point of attachment from one link to another, while still being reachable via its home address. correspondent node (CN): A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. (Note that a correspondent node does not necessarily require MIPv6 support.) home agent (HA): A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and routes them to the mobile node's registered care-of address. This document defines a set of managed objects (MOs) that can be used to monitor and control MIPv6 entities. Keeni, et al. Standards Track [Page 2] RFC 4295 MOBILEIPV6-MIB April 2006 2.2. Terminology The terminology used in this document is consistent with the definitions used in Mobile IPv6 protocol specification [RFC3775]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Mobile IPv6 Monitoring and Control Requirements For managing a MIPv6 entity it is necessary to monitor the following: o capabilities of MIPv6 entities o traffic due to MIPv6 o binding-related statistics (at home agent, correspondent node, and mobile node) o binding details (at home agent and correspondent node) o history of Binding Updates (at home agent, correspondent node, and mobile node) The MIPv6 protocol document stipulates that several MIPv6-related parameters should be manually configurable. The MIPv6 MIB should define managed objects that can be used to configure the related parameters, for example: o the preference value the home agent will use in Router Advertisements; o the lifetime value the home agent will use in Router Advertisements; o whether a home agent will send ICMP Mobile Prefix Advertisements to mobile nodes; o whether a home agent will respond to ICMP Mobile Prefix Solicitation messages from mobile nodes; and o whether a home agent will process multicast group membership control messages from mobile nodes. Keeni, et al. Standards Track [Page 3] RFC 4295 MOBILEIPV6-MIB April 2006 4. MIB Design The basic principle has been to keep the MIB as simple as possible and at the same time to make it effective enough so that the essential needs of monitoring and control are met. It is envisaged that wherever possible existing MIBs will be used (e.g., IPSec MIB, Neighbor Discovery MIB, Tunnel MIB [RFC4087]) for monitor and control of MIPv6 entities. It is assumed that the Mobile IPv6 Management Information Base (MOBILEIPV6-MIB) will always be implemented in conjunction with the IPv6-capable version of the IP-MIB [RFC4293]. The MOBILEIPV6-MIB uses the textual conventions defined in the INET-ADDRESS-MIB [RFC4001]. The Mobile-IPv6 MIB is composed of the following groups of definitions: - mip6Core: a generic group containing objects that are common to all the Mobile IPv6 entities. - mip6Ha: this group models the home agent service. It is composed of objects specific to the services and associated advertisement parameters offered by the home agent on each of its links. It also contains objects pertaining to the maintenance of the home agent list on each of the links on which the service is offered. - mip6Mn: this group models the mobile node service. It is composed of objects specific to the Dynamic Home Agent discovery function and related parameters. It also contains objects that record the movement of the mobile node. - mip6Cn: models the correspondent node and is primarily scoped to its participation in the Return Routability procedure for achieving Route Optimization triggered by the mobile node. - mip6Notifications: defines the set of notifications that will be used to asynchronously monitor the Mobile IPv6 entities. The tables contained in the above groups are as follows: mip6BindingCacheTable : models the binding cache on the home agent and correspondent node. It contains details of the Binding Update requests that have been received and accepted. mip6BindingHistoryTable : tracks the history of the binding cache. mip6NodeTrafficTable : the mobile node-wise traffic counters. Keeni, et al. Standards Track [Page 4] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnHomeAddressTable : contains all the home addresses pertaining to the mobile node and the corresponding registration status. mip6MnBLTable : models the Binding Update List on the mobile node. It contains information about the registration requests sent by the mobile node and the corresponding results. mip6CnCounterTable : contains the mobile node-wise registration statistics. mip6HaConfTable : contains the configurable advertisement parameters for all the interfaces on which the home agent service is advertised. mip6HaCounterTable : contains registration statistics for all mobile nodes registered with the home agent. mip6HaListTable : contains the list of all routers that are acting as home agents on each of the interfaces on which the home agent service is offered by this router. mip6HaGlAddrTable : contains the global addresses of the home agents. Keeni, et al. Standards Track [Page 5] RFC 4295 MOBILEIPV6-MIB April 2006 5. The Mobile-IPv6 MIB. MOBILEIPV6-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, Unsigned32, Integer32, Counter32, Gauge32, Counter64, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, DateAndTime, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress FROM INET-ADDRESS-MIB ipv6InterfaceIfIndex FROM IP-MIB ; mip6MIB MODULE-IDENTITY LAST-UPDATED "200602010000Z" -- 1st February 2006 ORGANIZATION "IETF mip6 Working Group" CONTACT-INFO " Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Kenichi Nagami Postal: INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075 Japan Tel: +81-3-5665-5069 E-mail: nagami@inetcore.com Kazuhide Koide Postal: Tohoku University 2-1-1, Katahira Aoba-ku, Sendai, 980-8577 Japan Tel: +81-22-217-5454 E-mail: koide@shiratori.riec.tohoku.ac.jp Keeni, et al. Standards Track [Page 6] RFC 4295 MOBILEIPV6-MIB April 2006 Sri Gundavelli Postal: Cisco Systems 170 W.Tasman Drive, San Jose, CA 95134 USA Tel: +1-408-527-6109 E-mail: sgundave@cisco.com Support Group E-mail: mip6@ietf.org" DESCRIPTION "The MIB module for monitoring Mobile-IPv6 entities. Copyright (C) The Internet Society 2006. This version of this MIB module is part of RFC 4295; see the RFC itself for full legal notices. " REVISION "200602010000Z" -- 1st February 2006 DESCRIPTION "Initial version, published as RFC 4295." ::= { mib-2 133 } -- The major groups mip6Notifications OBJECT IDENTIFIER ::= { mip6MIB 0 } mip6Objects OBJECT IDENTIFIER ::= { mip6MIB 1 } mip6Conformance OBJECT IDENTIFIER ::= { mip6MIB 2 } mip6Core OBJECT IDENTIFIER ::= { mip6Objects 1 } mip6Mn OBJECT IDENTIFIER ::= { mip6Objects 2 } mip6Cn OBJECT IDENTIFIER ::= { mip6Objects 3 } mip6Ha OBJECT IDENTIFIER ::= { mip6Objects 4 } -- The sub groups mip6System OBJECT IDENTIFIER ::= { mip6Core 1 } mip6Bindings OBJECT IDENTIFIER ::= { mip6Core 2 } mip6Stats OBJECT IDENTIFIER ::= { mip6Core 3 } mip6MnSystem OBJECT IDENTIFIER ::= { mip6Mn 1 } mip6MnConf OBJECT IDENTIFIER ::= { mip6Mn 2 } mip6MnRegistration OBJECT IDENTIFIER ::= { mip6Mn 3 } mip6CnSystem OBJECT IDENTIFIER ::= { mip6Cn 1 } Keeni, et al. Standards Track [Page 7] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnStats OBJECT IDENTIFIER ::= { mip6Cn 2 } mip6HaAdvertisement OBJECT IDENTIFIER ::= { mip6Ha 1 } mip6HaStats OBJECT IDENTIFIER ::= { mip6Ha 2 } -- Textual Conventions Mip6BURequestRejectionCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of the status field in the Binding Acknowledgment message when the Binding Update was rejected. " REFERENCE "RFC 3775 : Section 6.1.8" SYNTAX INTEGER { reasonUnspecified (1), --(Code 128) admProhibited (2), --(Code 129) insufficientResource (3), --(Code 130) homeRegistrationNotSupported (4), --(Code 131) notHomeSubnet (5), --(Code 132) notHomeAgentForThisMobileNode (6), --(Code 133) duplicateAddressDetectionFailed (7), --(Code 134) sequenceNumberOutOfWindow (8), --(Code 135) expiredHomeNonceIndex (9), --(Code 136) expiredCareofNonceIndex (10), --(Code 137) expiredNonces (11), --(Code 138) registrationTypeChangeDisallowed(12) --(Code 139) } Keeni, et al. Standards Track [Page 8] RFC 4295 MOBILEIPV6-MIB April 2006 mip6Capabilities OBJECT-TYPE SYNTAX BITS { mobileNode (0), homeAgent (1), correspondentNode (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the Mobile IPv6 functions that are supported by this managed entity. Multiple Mobile IPv6 functions may be supported by a single entity. " REFERENCE "RFC 3775 : Section 3.2, 4.1" ::= { mip6System 1 } mip6Status OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the Mobile IPv6 function is enabled for the managed entity. If it is enabled, the agent discovery and registration functions will be operational. Changing the status from enabled(1) to disabled(2) will terminate the agent discovery and registration functions. On the other hand, changing the status from disabled(2) to enabled(1) will start the agent discovery and registration functions. The value of this object SHOULD remain unchanged across reboots of the managed entity. " ::= { mip6System 2 } -- mip6BindingCache Keeni, et al. Standards Track [Page 9] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6BindingCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table models the Binding Cache on the managed entity. The cache is maintained by home agents and correspondent nodes. It contains both correspondent registration entries and home registration entries. Entries in this table are not required to survive a reboot of the managed entity. " REFERENCE "RFC 3775 : Section 4.5, 9.1, 10.1" ::= { mip6Bindings 1 } mip6BindingCacheEntry OBJECT-TYPE SYNTAX Mip6BindingCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry represents a conceptual row in the binding cache table. It represents a single Binding Update. Implementors need to be aware that if the total number of octets in mip6BindingHomeAddress exceeds 113, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6BindingHomeAddressType, mip6BindingHomeAddress } ::= { mip6BindingCacheTable 1 } Keeni, et al. Standards Track [Page 10] RFC 4295 MOBILEIPV6-MIB April 2006 Mip6BindingCacheEntry ::= SEQUENCE { mip6BindingHomeAddressType InetAddressType, mip6BindingHomeAddress InetAddress, mip6BindingCOAType InetAddressType, mip6BindingCOA InetAddress, mip6BindingTimeRegistered DateAndTime, mip6BindingTimeGranted Gauge32, mip6BindingTimeRemaining Gauge32, mip6BindingHomeRegn TruthValue, mip6BindingMaxSeq Unsigned32, mip6BindingUsageTS DateAndTime, mip6BindingUsageCount Gauge32, mip6BindingAdminStatus INTEGER } mip6BindingHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mip6BindingHomeAddress that follows. " ::= { mip6BindingCacheEntry 1 } mip6BindingHomeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The home address of the mobile node corresponding to the Binding Cache entry. This field is used as the key for searching the mobile node's current care-of address in the Binding Cache. The type of the address represented by this object is specified by the corresponding mip6BindingHomeAddressType object. " REFERENCE "RFC 3775 : Section 9.1" ::= { mip6BindingCacheEntry 2 } Keeni, et al. Standards Track [Page 11] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The InetAddressType of the mip6BindingCOA that follows. " ::= { mip6BindingCacheEntry 3 } mip6BindingCOA OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The care-of address of the mobile node indicated by the home address field (mip6BindingHomeAddress) in this Binding Cache entry. The type of the address represented by this object is specified by the corresponding mip6BindingCOAType object. " REFERENCE "RFC 3775 : Section 9.1" ::= { mip6BindingCacheEntry 4 } mip6BindingTimeRegistered OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when this Binding Cache entry was created. " ::= { mip6BindingCacheEntry 5 } mip6BindingTimeGranted OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime in seconds granted to the mobile node for this registration. " ::= { mip6BindingCacheEntry 6 } Keeni, et al. Standards Track [Page 12] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingTimeRemaining OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime in seconds remaining for this registration. " REFERENCE "RFC 3775 : Section 9.1" ::= { mip6BindingCacheEntry 7 } mip6BindingHomeRegn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not this Binding Cache entry is a home registration entry (applicable only on nodes that support home agent functionality). " REFERENCE "RFC 3775 : Section 9.1" ::= { mip6BindingCacheEntry 8 } mip6BindingMaxSeq OBJECT-TYPE SYNTAX Unsigned32 (0..65536) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of the Sequence Number field received in previous Binding Updates for this home address (mip6BindingHomeAddress). " REFERENCE "RFC 3775 : Section 9.1, 9.5.1" ::= { mip6BindingCacheEntry 9 } Keeni, et al. Standards Track [Page 13] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingUsageTS OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when this entry was last looked up. " REFERENCE "RFC 3775 : Section 9.1" ::= { mip6BindingCacheEntry 10 } mip6BindingUsageCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this entry was looked up. " REFERENCE "RFC 3775 : Section 9.1" ::= { mip6BindingCacheEntry 11 } mip6BindingAdminStatus OBJECT-TYPE SYNTAX INTEGER { active (1), inactive (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This is an administrative object used to control the status of a binding cache entry. By default the value will be 'active'(1). A value of 'inactive'(2) will indicate that the validity of the entry is suspended. It does not exist in the binding cache for all practical purposes. The state can be changed from 'active' to 'inactive' by operator intervention. Causing the state to change to 'inactive' results in the entry being deleted from the cache. Attempts to change the status from 'inactive' to 'active' will be rejected. " REFERENCE "RFC 3775 : Section 9.1" ::= { mip6BindingCacheEntry 12 } Keeni, et al. Standards Track [Page 14] RFC 4295 MOBILEIPV6-MIB April 2006 -- mip6BindingHistory -- Once the lifetime expires an entry will be removed from the -- Binding Cache. -- For monitoring purposes it will be useful to have access to -- the history of the Binding Cache. BindingHistoryTable serves -- this purpose. It records the history of the Bindings. -- The size of the table will be left to implementors. mip6BindingHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6BindingHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing a record of the bindings. " ::= { mip6Bindings 2 } mip6BindingHistoryEntry OBJECT-TYPE SYNTAX Mip6BindingHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The record of a binding. Implementors need to be aware that if the total number of octets in mip6BindingHstHomeAddress exceeds 112, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6BindingHstHomeAddressType, mip6BindingHstHomeAddress , mip6BindingHstIndex} ::= { mip6BindingHistoryTable 1 } Keeni, et al. Standards Track [Page 15] RFC 4295 MOBILEIPV6-MIB April 2006 Mip6BindingHistoryEntry ::= SEQUENCE { mip6BindingHstHomeAddressType InetAddressType, mip6BindingHstHomeAddress InetAddress, mip6BindingHstIndex Unsigned32, mip6BindingHstCOAType InetAddressType, mip6BindingHstCOA InetAddress, mip6BindingHstTimeRegistered DateAndTime, mip6BindingHstTimeExpired DateAndTime, mip6BindingHstHomeRegn TruthValue, mip6BindingHstUsageTS DateAndTime, mip6BindingHstUsageCount Gauge32 } mip6BindingHstHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mip6BindingHstHomeAddress that follows. " ::= { mip6BindingHistoryEntry 1 } mip6BindingHstHomeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mobile node's home address. The type of the address represented by this object is specified by the corresponding mip6BindingHstHomeAddressType object. " ::= { mip6BindingHistoryEntry 2 } mip6BindingHstIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index to uniquely identify this record along with the mobile node's HomeAddress type and HomeAddress. It should be monotonically increasing. It may wrap after reaching its max value." ::= { mip6BindingHistoryEntry 3 } Keeni, et al. Standards Track [Page 16] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingHstCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The InetAddressType of the mip6BindingHstCOA that follows. " ::= { mip6BindingHistoryEntry 4 } mip6BindingHstCOA OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Mobile node's care-of address. One mobile node can have multiple bindings with different care-of addresses. The type of the address represented by this object is specified by the corresponding mip6BindingHstCOAType object. " ::= { mip6BindingHistoryEntry 5 } mip6BindingHstTimeRegistered OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when this Binding Cache entry was created. " ::= { mip6BindingHistoryEntry 6 } mip6BindingHstTimeExpired OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when this Binding Cache entry expired. " ::= { mip6BindingHistoryEntry 7 } Keeni, et al. Standards Track [Page 17] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingHstHomeRegn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not this Binding Cache entry is a home registration entry (applicable only on nodes that support home agent functionality). " ::= { mip6BindingHistoryEntry 8 } mip6BindingHstUsageTS OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp when this entry was last looked up. " ::= { mip6BindingHistoryEntry 9 } mip6BindingHstUsageCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this entry was looked up. " ::= { mip6BindingHistoryEntry 10 } -- mip6TrafficCounters -- MIPv6 Traffic will be characterized by -- IPv6 datagrams which satisfy at least one of the following -- conditions -- - the datagrams are tunneled to the mobile node by the HA -- - the datagrams are reverse tunneled by the MN to the HA -- - the datagrams have the Routing header type 2 set. -- - the datagrams have the Home Address option set in the -- Destination Option extension header -- - the datagrams have the mobility header mip6TotalTraffic OBJECT IDENTIFIER ::= { mip6Stats 1 } -- REFERENCE -- "RFC 3775 : Section 4.1, 6.3, 6.4" Keeni, et al. Standards Track [Page 18] RFC 4295 MOBILEIPV6-MIB April 2006 mip6InOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams received by the MIPv6 entity. This will include datagrams with the Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 1 } mip6HCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams received by the MIPv6 entity. This will include datagrams with the Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. This object is a 64-bit version of mip6InOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 2 } Keeni, et al. Standards Track [Page 19] RFC 4295 MOBILEIPV6-MIB April 2006 mip6InPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams received by the MIPv6 entity. This will include datagrams with the Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 3 } mip6HCInPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams received by the MIPv6 entity. This will include datagrams with the Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. This object is a 64-bit version of mip6InPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 4 } Keeni, et al. Standards Track [Page 20] RFC 4295 MOBILEIPV6-MIB April 2006 mip6OutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams sent by the MIPv6 entity. This will include datagrams with the Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 5 } mip6HCOutOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams sent by the MIPv6 entity. This will include datagrams with the Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. This object is a 64-bit version of mip6OutOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 6 } Keeni, et al. Standards Track [Page 21] RFC 4295 MOBILEIPV6-MIB April 2006 mip6OutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams sent by the MIPv6 entity. This will include the datagrams with Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 7 } mip6HCOutPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams sent by the MIPv6 entity. This will include datagrams with the Mobility Header, the Home Address option in the Destination Option extension header (Next Header value = 60), or the type 2 Routing Header. It will also include the IPv6 datagrams that are reverse tunneled to a home agent from a mobile node's home address. This object is a 64-bit version of mip6OutPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6TotalTraffic 8 } Keeni, et al. Standards Track [Page 22] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this MIPv6 entities global counters, viz., counters with OID prefix 'mip6TotalTraffic' or 'mip6CnGlobalStats' or 'mip6HaGlobalStats' suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object will have a zero value. " ::= { mip6TotalTraffic 9 } -- mip6NodeTrafficCounters mip6NodeTrafficTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6NodeTrafficEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing MIPv6 traffic counters per mobile node. " ::= { mip6Stats 2 } mip6NodeTrafficEntry OBJECT-TYPE SYNTAX Mip6NodeTrafficEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MIPv6 traffic statistics for a mobile node. Implementors need to be aware that if the total number of octets in mip6BindingHomeAddress exceeds 113, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6BindingHomeAddressType, mip6BindingHomeAddress } ::= { mip6NodeTrafficTable 1 } Keeni, et al. Standards Track [Page 23] RFC 4295 MOBILEIPV6-MIB April 2006 Mip6NodeTrafficEntry ::= SEQUENCE { mip6NodeInOctets Counter32, mip6HCNodeInOctets Counter64, mip6NodeInPkts Counter32, mip6HCNodeInPkts Counter64, mip6NodeOutOctets Counter32, mip6HCNodeOutOctets Counter64, mip6NodeOutPkts Counter32, mip6HCNodeOutPkts Counter64, mip6NodeCtrDiscontinuityTime TimeStamp } mip6NodeInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams received from the mobile node by the MIPv6 entity. This will include datagrams with the Mobility Header or the Home Address option in the Destination Option extension header (Next Header value = 60). It will also include the IPv6 datagrams that are reverse tunneled to a home agent from the mobile node's home address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 1 } Keeni, et al. Standards Track [Page 24] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HCNodeInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams received from the mobile node by the MIPv6 entity. This will include datagrams with the Mobility Header or the Home Address option in the Destination Option extension header (Next Header value = 60). It will also include the IPv6 datagrams that are reverse tunneled to a home agent from the mobile node's home address. This object is a 64-bit version of mip6NodeInOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 2 } mip6NodeInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams received from the mobile node by the MIPv6 entity. This will include the datagrams with the Mobility Header or the Home Address option in the Destination Option extension header (Next Header value = 60). It will also include the IPv6 datagrams that are reverse tunneled to a home agent from the mobile node's home address. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 3 } Keeni, et al. Standards Track [Page 25] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HCNodeInPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams received from the mobile node by the MIPv6 entity. This will include datagrams with the Mobility Header or the Home Address option in the Destination Option extension header (Next Header value = 60). It will also include the IPv6 datagrams that are reverse tunneled to a home agent from the mobile node's home address. This object is a 64-bit version of mip6NodeInPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 4 } mip6NodeOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams sent to the mobile node by the MIPv6 entity. This will include datagrams with the Mobility Header or the type 2 Routing Header. It will also include the IPv6 datagrams that are tunneled by a home agent to the mobile node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 5 } Keeni, et al. Standards Track [Page 26] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HCNodeOutOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets in the MIPv6 datagrams sent to the mobile node by the MIPv6 entity. This will include datagrams with the Mobility Header or the type 2 Routing Header. It will also include the IPv6 datagrams that are tunneled by a home agent to the mobile node. This object is a 64-bit version of mip6NodeOutOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 6 } mip6NodeOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams sent to the mobile node by the MIPv6 entity. This will include datagrams with the Mobility Header or the type 2 Routing Header. It will also include the IPv6 datagrams that are tunneled by a home agent to the mobile node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 7 } Keeni, et al. Standards Track [Page 27] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HCNodeOutPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MIPv6 datagrams sent to the mobile node by the MIPv6 entity. This will include datagrams with the Mobility Header or the type 2 Routing Header. It will also include the IPv6 datagrams that are tunneled by a home agent to the mobile node. This object is a 64-bit version of mip6NodeOutOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6NodeCtrDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1, 6.3, 6.4, 10.4.5" ::= { mip6NodeTrafficEntry 8 } mip6NodeCtrDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of the counters in this row suffered a discontinuity. The relevant counters are the specific instances of any Counter32 or Counter64 objects in this row. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value. " ::= { mip6NodeTrafficEntry 9 } -- mip6MnSystem Group mip6MnHomeAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6MnHomeAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing registration status for all the home addresses pertaining to the mobile node. " ::= { mip6MnSystem 1 } Keeni, et al. Standards Track [Page 28] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnHomeAddressEntry OBJECT-TYPE SYNTAX Mip6MnHomeAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The registration status for a home address. Implementors need to be aware that if the total number of octets in mip6MnHomeAddress exceeds 113, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6MnHomeAddressType, mip6MnHomeAddress } ::= { mip6MnHomeAddressTable 1 } Mip6MnHomeAddressEntry ::= SEQUENCE { mip6MnHomeAddressType InetAddressType, mip6MnHomeAddress InetAddress, mip6MnHomeAddressState INTEGER } mip6MnHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mip6MnHomeAddress that follows. " ::= { mip6MnHomeAddressEntry 1 } Keeni, et al. Standards Track [Page 29] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnHomeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unicast routable address assigned to the mobile node. This is used as the 'permanent address' of the mobile node in the sense that it remains unchanged regardless of the mobile node's current point of attachment. If mobile node doesn't have a home address assigned yet, then this object will take the default 'unspecified' value ::0. The type of the address represented by this object is specified by the corresponding mip6MnHomeAddressType object. " REFERENCE "RFC 3775 : Section 3.2" ::= { mip6MnHomeAddressEntry 2 } mip6MnHomeAddressState OBJECT-TYPE SYNTAX INTEGER { unknown(1), home(2), registered(3), pending(4), isolated(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the state of the mobile node: unknown -- The state of the mobile node cannot be determined. home -- mobile node is on the home network. registered -- mobile node is on a foreign network and is registered with the home agent. pending -- mobile node has sent registration request to the home agent and is waiting for the reply. isolated -- mobile node is isolated from network, i.e., it is not in its home network, it is not registered, and no registration ack is pending. " ::= { mip6MnHomeAddressEntry 3 } Keeni, et al. Standards Track [Page 30] RFC 4295 MOBILEIPV6-MIB April 2006 -- Mobile Node Discovery and Advertisement Group Counters mip6MnDiscoveryRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ICMP Dynamic Home Agent Address Discovery Requests sent by the mobile node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.5, 11.4.1" ::= { mip6MnConf 1 } mip6MnDiscoveryReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ICMP Dynamic Home Agent Address Discovery Replies received by the mobile node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.5, 11.4.1" ::= { mip6MnConf 2 } Keeni, et al. Standards Track [Page 31] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnDiscoveryTimeouts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ICMP Dynamic Home Agent Address Discovery Requests that timed out. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.5, 11.4.1, 12" ::= { mip6MnConf 3 } mip6MnPrefixSolicitationsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ICMP Mobile Prefix Solicitations sent by the mobile node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.5, 11.4.2" ::= { mip6MnConf 4 } Keeni, et al. Standards Track [Page 32] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnPrefixAdvsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ICMP Mobile Prefix Advertisements received by the mobile node. This will include the ICMP Mobile Prefix Advertisements that failed the validity checks. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.6, 11.4.3" ::= { mip6MnConf 5 } mip6MnPrefixAdvsIgnored OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Mobile Prefix Advertisements discarded by the validity check. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.6, 11.4.3" ::= { mip6MnConf 6 } Keeni, et al. Standards Track [Page 33] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnMovedToFN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile node has detected movement to a foreign network from another foreign network or from the home network, has reconstructed its care-of address and has initiated the care-of address registration process. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.5.1" ::= { mip6MnConf 7 } mip6MnMovedToHN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile node has detected movement from a foreign network to its home network. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.5.4" ::= { mip6MnConf 8 } -- Mobile Node Registration Group -- Registration table of mobile node Keeni, et al. Standards Track [Page 34] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBLTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6MnBLEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table corresponds to the Binding Update List (BL) that is maintained by the mobile node. The list holds an item for every binding that the mobile node has established or is trying to establish. Both correspondent and home registrations are included in this table. Entries from the table are deleted as the lifetime of the binding expires. " REFERENCE "RFC 3775 : Section 4.5, 11.1" ::= { mip6MnRegistration 1 } mip6MnBLEntry OBJECT-TYPE SYNTAX Mip6MnBLEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a Binding Update sent by the mobile node either to its home agent or to one of its correspondent nodes. Implementors need to be aware that if the total number of octets in mip6MnHomeAddress and mip6MnBLNodeAddress exceeds 111, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6MnHomeAddressType, mip6MnHomeAddress, mip6MnBLNodeAddressType, mip6MnBLNodeAddress } ::= { mip6MnBLTable 1 } Keeni, et al. Standards Track [Page 35] RFC 4295 MOBILEIPV6-MIB April 2006 Mip6MnBLEntry ::= SEQUENCE { mip6MnBLNodeAddressType InetAddressType, mip6MnBLNodeAddress InetAddress, mip6MnBLCOAType InetAddressType, mip6MnBLCOA InetAddress, mip6MnBLLifeTimeRequested Unsigned32, mip6MnBLLifeTimeGranted Unsigned32, mip6MnBLMaxSeq Unsigned32, mip6MnBLTimeSent DateAndTime, mip6MnBLAccepted TruthValue, mip6MnBLAcceptedTime DateAndTime, mip6MnBLRetransmissions Gauge32, mip6MnBLDontSendBUFlag TruthValue } mip6MnBLNodeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mip6MnBLNodeAddress that follows. " ::= { mip6MnBLEntry 1 } mip6MnBLNodeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the agent as used in the destination address of the Binding Update. The agent may be a home agent or a correspondent node. The type of the address represented by this object is specified by the corresponding mip6MnBLNodeAddressType object. " REFERENCE "RFC 3775 : Section 11.1" ::= { mip6MnBLEntry 2 } Keeni, et al. Standards Track [Page 36] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBLCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The InetAddressType of the mip6MnBLCOA that follows. " ::= { mip6MnBLEntry 3 } mip6MnBLCOA OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Care-of address that the mobile node intends to register in the Binding Update request. The type of the address represented by this object is specified by the corresponding mip6MnBLCOAType object. " REFERENCE "RFC 3775 : Section 11.1" ::= { mip6MnBLEntry 4 } mip6MnBLLifeTimeRequested OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime requested by the mobile node (in seconds) in the Binding Update. " REFERENCE "RFC 3775 : Section 11.1" ::= { mip6MnBLEntry 5 } Keeni, et al. Standards Track [Page 37] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBLLifeTimeGranted OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime granted to the mobile node for this binding. This field will be inaccessible if the Binding Update request has not been accepted. The lifetime remaining (lR) can be calculated using the current time (cT), mip6MnBLAcceptedTime (aT) and mip6MnBLLifeTimeGranted (lG) as follows: lR = lG - (cT - aT). When lR is zero, this entry will be deleted from the Binding Update List and consequently from this table. " ::= { mip6MnBLEntry 6 } mip6MnBLMaxSeq OBJECT-TYPE SYNTAX Unsigned32 (0..65536) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. " REFERENCE "RFC 3775 : Section 11.1" ::= { mip6MnBLEntry 7 } mip6MnBLTimeSent OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the last (re-)transmission occurred." REFERENCE "RFC 3775 : Section 11.1" ::= { mip6MnBLEntry 8 } Keeni, et al. Standards Track [Page 38] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBLAccepted OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1) if the mobile node has received a binding acknowledgment indicating that service has been accepted (status code 0 or 1); false(2) otherwise. false(2) implies that the registration is still pending. " ::= { mip6MnBLEntry 9 } mip6MnBLAcceptedTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the mobile node receives a binding acknowledgment indicating that Binding Update has been accepted (status code 0 or 1); This object will be inaccessible if the Binding Update request is still pending. " ::= { mip6MnBLEntry 10 } mip6MnBLRetransmissions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Binding Update retransmissions. " REFERENCE "RFC 3775 : Section 11.1" ::= { mip6MnBLEntry 11 } Keeni, et al. Standards Track [Page 39] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBLDontSendBUFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1) indicates that future binding updates will not be sent to mip6MnBLNodeAddress. false(2) implies that binding updates will be sent to mip6MnBLNodeAddress. The mobile node sets this flag in the when it receives an ICMP Parameter Problem, Code 1, error message in response to a return routability message or Binding Update sent to mip6MnBLNodeAddress. " REFERENCE "RFC 3775 : Section 11.1" ::= { mip6MnBLEntry 12 } -- Mobile Node Registration Group Counters mip6MnRegnCounters OBJECT IDENTIFIER ::= { mip6MnRegistration 2 } mip6MnMobilityMessagesSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of mobility messages, i.e., IPv6 datagrams with Mobility Header, sent by the mobile node. There are 3 types of mobility messages, viz., Home Test Init, Care-of Test Init, and Binding Updates, that are sent by mobile nodes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 4.2, 6.1" ::= { mip6MnRegnCounters 1 } Keeni, et al. Standards Track [Page 40] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnMobilityMessagesRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of mobility messages, i.e., IPv6 datagrams with Mobility Header, received by the mobile node. There are 5 types of mobility messages, viz., Home Test, Care-of Test, Binding Acknowledgment, Binding Refresh Request, and Binding Error, that are sent to mobile nodes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 4.2, 6.1" ::= { mip6MnRegnCounters 2 } mip6MnBUsToHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates sent to the mobile node's home agent(s). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.7.1" ::= { mip6MnRegnCounters 3 } Keeni, et al. Standards Track [Page 41] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBUAcksFromHA OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid binding acknowledgments received from the mobile node's home agent(s). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.7.3" ::= { mip6MnRegnCounters 4 } mip6MnBUsToCN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates sent to correspondent nodes by the mobile node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.7.2" ::= { mip6MnRegnCounters 5 } mip6MnBUAcksFromCN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid Binding Update acks received from all the correspondent nodes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.7.3" ::= { mip6MnRegnCounters 6 } Keeni, et al. Standards Track [Page 42] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBindingErrorsFromCN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Error messages received by mobile node from CN. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " ::= { mip6MnRegnCounters 7 } mip6MnICMPErrorsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of ICMP Error messages of type ICMP Parameter Problem, Code 1 or Code 2, received by the mobile node from a correspondent node in response to a return routability procedure, a Binding Update, or a packet with the Home Address option. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.3.5" ::= { mip6MnRegnCounters 8 } Keeni, et al. Standards Track [Page 43] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBRRequestsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Refresh requests received by the mobile node from correspondent nodes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 11.7.4" ::= { mip6MnRegnCounters 9 } -- Registration Group counters used for Correspondent Node mip6CnGlobalStats OBJECT IDENTIFIER ::= { mip6CnStats 1 } mip6CnHomeTestInitsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Home Test Init messages received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.4.1" ::= { mip6CnGlobalStats 1 } Keeni, et al. Standards Track [Page 44] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnHomeTestsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Home Test messages sent. If a Home Test Init message is found to be valid, a Home Test message will be generated and sent. Otherwise the Home Test message is silently discarded. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.4.3" ::= { mip6CnGlobalStats 2 } mip6CnCareOfTestInitsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Care-of Test Init messages received. " REFERENCE "RFC 3775 : Section 9.4.2" ::= { mip6CnGlobalStats 3 } mip6CnCareOfTestsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Care-of Test messages sent. If a Care-of Test Init message is found to be valid, a Care-of Test message will be generated and sent. Otherwise the Care-of Test message is silently discarded. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.4.4" ::= { mip6CnGlobalStats 4 } Keeni, et al. Standards Track [Page 45] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnBUsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates received by the correspondent node from mobile nodes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.1" ::= { mip6CnGlobalStats 5 } mip6CnBUAcksSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of acknowledgments sent by the correspondent node for the Binding Updates received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.4" ::= { mip6CnGlobalStats 6 } mip6CnBRsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Refresh Request messages sent by the correspondent node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.5" ::= { mip6CnGlobalStats 7 } Keeni, et al. Standards Track [Page 46] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnBindingErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Error messages sent by the correspondent node to the mobile node. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.3.3" ::= { mip6CnGlobalStats 8 } mip6CnBUsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates accepted by the correspondent node. If a Binding Acknowledgment message is sent for the Binding Update request, the Status code field in the message will have a value less than 128. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.1, 9.5.4" ::= { mip6CnGlobalStats 9 } Keeni, et al. Standards Track [Page 47] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnBUsRejected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the correspondent node. If a Binding Acknowledgment message has been sent for the Binding Update request, the Status code field in the message will have a value greater than or equal to 128. Otherwise the Binding Update request will be silently discarded. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.1, 9.5.4" ::= { mip6CnGlobalStats 10 } mip6CnReasonUnspecified OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the correspondent node with status code in the Binding Acknowledgment message indicating 'reason unspecified' (Code 128). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1.8" ::= { mip6CnGlobalStats 11 } Keeni, et al. Standards Track [Page 48] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnInsufficientResource OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the correspondent node with status code in the Binding Acknowledgment message indicating 'insufficient resources' (Code 130). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1.8" ::= { mip6CnGlobalStats 12 } mip6CnHomeRegnNotSupported OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'home registration not supported' (Code 131). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6CnGlobalStats 13 } Keeni, et al. Standards Track [Page 49] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnSeqNumberOutOfWindow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'sequence number out of window' (Code 135). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1.8, 9.5.1" ::= { mip6CnGlobalStats 14 } mip6CnExpiredHomeNonceIndex OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Updates rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'expired home nonce index' (Code 136). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1.8, 9.5.1" ::= { mip6CnGlobalStats 15 } Keeni, et al. Standards Track [Page 50] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnExpiredCareOfNonceIndex OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Updates rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'expired care-of nonce index' (Code 137). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1.8, 9.5.1" ::= { mip6CnGlobalStats 16 } mip6CnExpiredNonce OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Updates rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'expired nonces' (Code 138), i.e., the correspondent node no longer recognizes the Home Nonce Index value and the Care-of Nonce Index value. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1.8, 9.5.1" ::= { mip6CnGlobalStats 17 } Keeni, et al. Standards Track [Page 51] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnRegTypeChangeDisallowed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Updates rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'registration type change disallowed' (Code 139), i.e., a binding already exists for the given home address and the home registration flag has a different value than the Home Registration (H) bit in the Binding Update. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 6.1.8, 9.5.1" ::= { mip6CnGlobalStats 18 } -- The Correspondent Node statistics by mobile node mip6CnCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6CnCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing each mobile ." ::= { mip6CnStats 2 } Keeni, et al. Standards Track [Page 52] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnCounterEntry OBJECT-TYPE SYNTAX Mip6CnCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of correspondent node counters for a mobile node. Implementors need to be aware that if the total number of octets in mip6BindingHomeAddress exceeds 113, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6BindingHomeAddressType, mip6BindingHomeAddress } ::= { mip6CnCounterTable 1 } Mip6CnCounterEntry ::= SEQUENCE { mip6CnBURequestsAccepted Counter32, mip6CnBURequestsRejected Counter32, mip6CnBCEntryCreationTime DateAndTime, mip6CnBUAcceptedTime DateAndTime, mip6CnBURejectionTime DateAndTime, mip6CnBURejectionCode Mip6BURequestRejectionCode, mip6CnCtrDiscontinuityTime TimeStamp } mip6CnBURequestsAccepted OBJECT-TYPE --(Code 0,1) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests from the mobile node accepted by the correspondent node. If Binding Acknowledgment messages are sent, then the status code in the message will have a value less than 128. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CnCtrDiscontinuityTime. " ::= { mip6CnCounterEntry 1 } Keeni, et al. Standards Track [Page 53] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnBURequestsRejected OBJECT-TYPE -- (Code 128 through Code 159) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests from the mobile node that have been rejected by the correspondent node. This includes the Binding Update requests for which a Binding Acknowledgment message has been sent with status code value greater than or equal to 128 and the Binding Acknowledgment requests that have been silently discarded. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CnCtrDiscontinuityTime. " ::= { mip6CnCounterEntry 2 } mip6CnBCEntryCreationTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the current Binding Cache entry was created for the mobile node. " ::= { mip6CnCounterEntry 3 } mip6CnBUAcceptedTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last Binding Update was accepted by the correspondent node and the corresponding Binding Cache entry was updated. " ::= { mip6CnCounterEntry 4 } Keeni, et al. Standards Track [Page 54] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnBURejectionTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last Binding Update message was rejected by the correspondent node. If there have been no rejections, then this object will be inaccessible. " ::= { mip6CnCounterEntry 5 } mip6CnBURejectionCode OBJECT-TYPE SYNTAX Mip6BURequestRejectionCode MAX-ACCESS read-only STATUS current DESCRIPTION "If a Binding Acknowledgment is sent to the mobile node, this is the status code (> 128) that is returned in the Binding Acknowledgment. In case a Binding Acknowledgment is not sent to the mobile node, then this will be the value of the Status code that corresponds to the reason of the rejection. If there have been no rejections, then this object will be inaccessible. " REFERENCE "RFC 3775 : Section 6.1.8" ::= { mip6CnCounterEntry 6 } mip6CnCtrDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of counters in this row, viz., instances of 'mip6CnBURequestsAccepted' and 'mip6CnBURequestsRejected', suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object will have a zero value. " ::= { mip6CnCounterEntry 7 } -- Home agent group Keeni, et al. Standards Track [Page 55] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaAdvsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of valid Router Advertisements received with the Home Agent (H) bit set, on all the links on which it is serving as a Home Agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 7" ::= { mip6HaAdvertisement 1 } mip6HaAdvsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of unsolicited multicast Router Advertisements sent with the Home Agent (H) bit set, on all the links on which the router is serving as a Home Agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 7" ::= { mip6HaAdvertisement 2 } mip6HaConfTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6HaConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing configurable advertisement parameters for all interfaces on which the home agent service is advertised. It is RECOMMENDED that the last written values of the objects in the conceptual rows of this Keeni, et al. Standards Track [Page 56] RFC 4295 MOBILEIPV6-MIB April 2006 table will remain unchanged across reboots of the managed entity provided that the interfaces have not been renumbered after the reboot. " ::= { mip6HaAdvertisement 3 } mip6HaConfEntry OBJECT-TYPE SYNTAX Mip6HaConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Advertisement parameters for an interface. The instances of the columnar objects in this entry pertain to the interface that is uniquely identified by the ipv6InterfaceIfIndex of the interface. The same ipv6InterfaceIfIndex object is used to uniquely identify instances of the columnar objects of this conceptual row. " INDEX { ipv6InterfaceIfIndex } ::= { mip6HaConfTable 1 } Mip6HaConfEntry ::= SEQUENCE { mip6HaAdvPreference Integer32, mip6HaAdvLifetime Integer32, mip6HaPrefixAdv INTEGER, mip6HaPrefixSolicitation INTEGER, mip6HaMCastCtlMsgSupport INTEGER } mip6HaAdvPreference OBJECT-TYPE SYNTAX Integer32 (0..65536) MAX-ACCESS read-write STATUS current DESCRIPTION "The preference value for the home agent to be used in the Router Advertisements. Higher value denotes greater preference. " REFERENCE "RFC 3775 : Section 7.4, 8.4" ::= { mip6HaConfEntry 1 } Keeni, et al. Standards Track [Page 57] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaAdvLifetime OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The lifetime value for the home agent to be used in the Router Advertisements. " REFERENCE "RFC 3775 : Section 7.4" ::= { mip6HaConfEntry 2 } mip6HaPrefixAdv OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the home agent should support sending of the ICMP Mobile Prefix Advertisements. If it is disabled(2), the home agent will not send ICMP Mobile Prefix Advertisements to the mobile nodes. The state can be changed from enabled(1) to disabled(2) and vice versa by operator intervention. Causing the state to change from enabled(1) to disabled(2) will result in the home agent disabling the Prefix advertisement function. On the other hand, changing the status from disabled(2) to enabled(1) will start the prefix advertisement function. " REFERENCE "RFC 3775 : Section 8.4" ::= { mip6HaConfEntry 3} Keeni, et al. Standards Track [Page 58] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaPrefixSolicitation OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the home agent should respond to ICMP Mobile Prefix Solicitation messages it receives from the mobile nodes. By default, the value will be set to enabled(1). If it is disabled(2), the home agent will not respond to any ICMP Mobile Prefix Solicitation messages. The state can be changed from enabled(1) to disabled(2), by operator intervention. Causing the state to change from enabled(1) to disabled(2) will result in the home agent not responding to any ICMP Mobile Prefix Solicitation messages it receives from the mobile nodes. " REFERENCE "RFC 3775 : Section 8.4" ::= { mip6HaConfEntry 4} mip6HaMCastCtlMsgSupport OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the home agent should enable support for the processing of the multicast group membership control messages it receives from the mobile nodes. By default, the value will be set to enabled(1). If it is disabled(2), the home agent will not process any multicast group control messages it receives from the mobile nodes. The state can be changed from enabled(1) to disabled(2), by operator intervention. Causing the state to change from enabled(1) to disabled(2) will result in the home agent disabling the processing of the multicast group control messages it received from the mobile nodes. " REFERENCE "RFC 3775 : Section 10.4.3" ::= { mip6HaConfEntry 5} Keeni, et al. Standards Track [Page 59] RFC 4295 MOBILEIPV6-MIB April 2006 -- Registration Group counters HA mip6HaGlobalStats OBJECT IDENTIFIER ::= { mip6HaStats 1 } mip6HaHomeTestInitsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Home Test Init messages received by the home agent. This will include Home Test Init messages that failed the validity checks. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 5.2.5" ::= { mip6HaGlobalStats 1 } mip6HaHomeTestsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Home Test messages sent by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 5.2.5" ::= { mip6HaGlobalStats 2 } Keeni, et al. Standards Track [Page 60] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaBUsRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates received by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 3 } mip6HaBUAcksSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Acknowledgments sent by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 4 } mip6HaBRAdviceSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Acknowledgments sent by the home agent with Binding Refresh Advice mobility option included. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 5 } Keeni, et al. Standards Track [Page 61] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaBUsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Updates accepted by this HA. Binding Acknowledgment with status code of 0 or 1. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 6 } mip6HaPrefDiscoverReqd OBJECT-TYPE -- (Code 1) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgments sent by the home agent with status code indicating 'accepted but prefix discovery necessary' (Code 1). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 7 } Keeni, et al. Standards Track [Page 62] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaReasonUnspecified OBJECT-TYPE -- (Code 128) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'reason unspecified' (Code 128). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 8 } mip6HaAdmProhibited OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'administratively prohibited' (Code 129). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 9 } Keeni, et al. Standards Track [Page 63] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaInsufficientResource OBJECT-TYPE -- (Code 130) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'insufficient resources' (Code 130). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.2" ::= { mip6HaGlobalStats 10 } mip6HaHomeRegnNotSupported OBJECT-TYPE -- (Code 131) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'home registration not supported' (Code 131). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 11 } Keeni, et al. Standards Track [Page 64] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaNotHomeSubnet OBJECT-TYPE -- (Code 132) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'not home subnet' (Code 132). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 12 } mip6HaNotHomeAgentForThisMN OBJECT-TYPE -- (Code 133) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'not home agent for this mobile node' (Code 133). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.2" ::= { mip6HaGlobalStats 13 } Keeni, et al. Standards Track [Page 65] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaDupAddrDetectionFailed OBJECT-TYPE -- (Code 134) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'Duplicate Address Detection failed' (Code 134). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6HaGlobalStats 14 } mip6HaSeqNumberOutOfWindow OBJECT-TYPE -- (Code 135) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'sequence number out of window' (Code 135). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.1" ::= { mip6HaGlobalStats 15 } Keeni, et al. Standards Track [Page 66] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaExpiredHomeNonceIndex OBJECT-TYPE -- (Code 136) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'expired home nonce index' (Code 136). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.1" ::= { mip6HaGlobalStats 16 } mip6HaRegTypeChangeDisallowed OBJECT-TYPE -- (Code 139) SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgment message indicating 'registration type change disallowed' (Code 139), i.e., a binding already exists for the given home address and the home registration flag has a different value than the Home Registration (H) bit in the Binding Update. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. " REFERENCE "RFC 3775 : Section 9.5.1" ::= { mip6HaGlobalStats 17 } -- Home agent registration Counters per node Keeni, et al. Standards Track [Page 67] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6HaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing registration statistics for all mobile nodes registered with the home agent. " ::= { mip6HaStats 2 } mip6HaCounterEntry OBJECT-TYPE SYNTAX Mip6HaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Home agent registration statistics for a mobile node. Implementors need to be aware that if the total number of octets in mip6BindingHomeAddress exceeds 113, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6BindingHomeAddressType, mip6BindingHomeAddress } ::= { mip6HaCounterTable 1 } Mip6HaCounterEntry ::= SEQUENCE { mip6HaBURequestsAccepted Counter32, mip6HaBURequestsDenied Counter32, mip6HaBCEntryCreationTime DateAndTime, mip6HaBUAcceptedTime DateAndTime, mip6HaBURejectionTime DateAndTime, mip6HaRecentBURejectionCode Mip6BURequestRejectionCode, mip6HaCtrDiscontinuityTime TimeStamp } Keeni, et al. Standards Track [Page 68] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaBURequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of service requests for the mobile node accepted by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6HaCtrDiscontinuityTime. " ::= { mip6HaCounterEntry 1 } mip6HaBURequestsDenied OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of service requests for the mobile node rejected by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6HaCtrDiscontinuityTime. " ::= { mip6HaCounterEntry 2 } mip6HaBCEntryCreationTime OBJECT-TYPE SYNTAX DateAndTime UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the current Binding Cache entry was created for the mobile node. " ::= { mip6HaCounterEntry 3 } mip6HaBUAcceptedTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last Binding Update was accepted by the home agent for this mobile node. " ::= { mip6HaCounterEntry 4 } Keeni, et al. Standards Track [Page 69] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaBURejectionTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last Binding Update was rejected by the home agent for this mobile node. If there have been no rejections, then this object will be inaccessible. " ::= { mip6HaCounterEntry 5 } mip6HaRecentBURejectionCode OBJECT-TYPE SYNTAX Mip6BURequestRejectionCode MAX-ACCESS read-only STATUS current DESCRIPTION "If a Binding Acknowledgment is sent to the mobile node, this is the status code (> 128) that is returned in the Binding Acknowledgment. In case a Binding Acknowledgment is not sent to the mobile node, then this will be the value of the status code that corresponds to the reason of the rejection. If there have been no rejections, then this object will be inaccessible. " ::= { mip6HaCounterEntry 6 } mip6HaCtrDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of counters in this row, viz., instances of 'mip6HaBURequestsAccepted' and 'mip6HaBURequestsRejected', suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object will have a zero value. " ::= { mip6HaCounterEntry 7 } -- Home Agent List Table Keeni, et al. Standards Track [Page 70] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaListTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6HaListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table models the Home Agents List that contains the list of all routers that are acting as home agents on each of the interfaces on which the home agent service is offered by this router. " REFERENCE "RFC 3775 : Section 10.1" ::= { mip6HaAdvertisement 4 } mip6HaListEntry OBJECT-TYPE SYNTAX Mip6HaListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a router that is offering home agent service. The instances of the columnar objects in this entry pertain to an interface for a particular value of mip6HaLinkLocalAddressType and mip6HaLinkLocalAddress. The interface is uniquely identified by its ipv6InterfaceIfIndex. The same ipv6InterfaceIfIndex object is used in conjunction with the mip6HaLinkLocalAddressType and mip6HaLinkLocalAddress to uniquely identify instances of the columnar objects of this row. Implementors need to be aware that if the total number of octets in mip6HaLinkLocalAddress exceeds 112, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { ipv6InterfaceIfIndex, mip6HaLinkLocalAddressType, mip6HaLinkLocalAddress } ::= { mip6HaListTable 1 } Mip6HaListEntry ::= SEQUENCE { mip6HaLinkLocalAddressType InetAddressType, mip6HaLinkLocalAddress InetAddress, mip6HaPreference Integer32, mip6HaRecvLifeTime Gauge32, mip6HaRecvTimeStamp DateAndTime } Keeni, et al. Standards Track [Page 71] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaLinkLocalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type for the link-local address of the home agent that follows. " REFERENCE "RFC 3775 : Section 10.1" ::= { mip6HaListEntry 1 } mip6HaLinkLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The link local address of the home agent. The type of the address represented by this object is specified by the corresponding mip6HaLinkLocalAddressType object. " REFERENCE "RFC 3775 : Section 10.1" ::= { mip6HaListEntry 2 } mip6HaPreference OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The preference value of this home agent. Higher values indicate a more preferable home agent. The preference value is obtained from the preference field of the received Router Advertisement. " REFERENCE "RFC 3775 : Section 10.1" ::= { mip6HaListEntry 3 } Keeni, et al. Standards Track [Page 72] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaRecvLifeTime OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The lifetime for this home agent. " REFERENCE "RFC 3775 : Section 10.1" ::= { mip6HaListEntry 4 } mip6HaRecvTimeStamp OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the home agent advertisement was received. " ::= { mip6HaListEntry 5 } -- -- The list of global addresses of a home agent in the -- home agent list -- mip6HaGlAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF Mip6HaGlAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the global addresses of the home agents in the Home Agents List. " REFERENCE "RFC 3775 : Section 10.1" ::= { mip6HaAdvertisement 5 } Keeni, et al. Standards Track [Page 73] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaGlAddrEntry OBJECT-TYPE SYNTAX Mip6HaGlAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A global address for a home agent in the Home Agents List. The instances of the columnar objects in this entry pertain to an interface for a particular value of mip6HaLinkLocalAddressType, mip6HaLinkLocalAddress and mip6HaGaAddrSeqNo. The mip6HaGaAddrSeqNo object is used to distinguish between multiple instances of the home agent global addresses on the same interface for the same set of mip6HaLinkLocalAddressType, mip6HaLinkLocalAddress, values. There is no upper-bound on the maximum number of global addresses on an interface but, for practical purposes, the upper-bound of the value mip6HaGaAddrSeqNo is set to 1024. The interface is uniquely identified by its ipv6InterfaceIfIndex. The same ipv6InterfaceIfIndex object is used in conjunction with the mip6HaLinkLocalAddressType, mip6HaLinkLocalAddress, and mip6HaGaAddrSeqNo to uniquely identify instances of the columnar objects of this row. Implementors need to be aware that if the total number of octets in mip6HaLinkLocalAddress exceeds 111, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { ipv6InterfaceIfIndex, mip6HaLinkLocalAddressType, mip6HaLinkLocalAddress, mip6HaGaAddrSeqNo } ::= { mip6HaGlAddrTable 1 } Mip6HaGlAddrEntry ::= SEQUENCE { mip6HaGaAddrSeqNo Integer32, mip6HaGaGlobalAddressType InetAddressType, mip6HaGaGlobalAddress InetAddress } Keeni, et al. Standards Track [Page 74] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaGaAddrSeqNo OBJECT-TYPE SYNTAX Integer32 (1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index that along with ipv6InterfaceIfIndex, mip6HaLinkLocalAddressType, and mip6HaLinkLocalAddress uniquely identifies this row. " REFERENCE "RFC 3775 : Section 10.1" ::= { mip6HaGlAddrEntry 1 } mip6HaGaGlobalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type for the global address of the home agent that follows. " ::= { mip6HaGlAddrEntry 2 } mip6HaGaGlobalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A global address of the home agent. The type of the address represented by this object is specified by the corresponding mip6HaGaGlobalAddressType object. " ::= { mip6HaGlAddrEntry 3 } -- -- Notifications -- Keeni, et al. Standards Track [Page 75] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnRegistered NOTIFICATION-TYPE OBJECTS { mip6BindingTimeRegistered, mip6BindingCOAType, mip6BindingCOA } STATUS current DESCRIPTION "This notification is sent by a home agent when a mobile node registers with the home agent for the first time. Notifications will not be sent for subsequent updates and/or refreshes. The MO instances in the notifications will be identified by the mip6BindingHomeAddressType and mip6BindingHomeAddress for the mobile node in the mip6BindingCacheTable. " REFERENCE "RFC 3775 : Section 10.3.1" ::= { mip6Notifications 1 } mip6MnDeRegistered NOTIFICATION-TYPE OBJECTS { mip6BindingTimeRegistered, mip6BindingCOAType, mip6BindingCOA } STATUS current DESCRIPTION "This notification is sent by a home agent every time a mobile node de-registers with the home agent by sending a Binding Update that requests the home agent to delete a binding. The MO instances in the notifications will be identified by the mip6BindingHomeAddressType and mip6BindingHomeAddress for the mobile node in the mip6BindingCacheTable. " REFERENCE "RFC 3775 : Section 10.3.2" ::= { mip6Notifications 2 } Keeni, et al. Standards Track [Page 76] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnCOAChanged NOTIFICATION-TYPE OBJECTS { mip6BindingTimeRegistered, mip6BindingCOAType, mip6BindingCOA } STATUS current DESCRIPTION "This notification is sent by a home agent every time a mobile node sends a Binding Update with a new care-of address (for an existing Binding Cache entry). Notifications will not be sent for subsequent updates and/or refreshes for the same Care-of address. The registration of a new care-of address may indicate that the mobile node has moved or that the primary care-of address of the mobile node has become deprecated. The MO instances in the notifications will be identified by the mip6BindingHomeAddressType and mip6BindingHomeAddress for the mobile node in the mip6BindingCacheTable. " REFERENCE "RFC 3775 : Section 11.5.2, 11.7.1" ::= { mip6Notifications 3 } mip6MnBindingExpiredAtHA NOTIFICATION-TYPE OBJECTS { mip6BindingTimeRegistered, mip6BindingCOAType, mip6BindingCOA } STATUS current DESCRIPTION "This notification is sent by a home agent when a binding for the mobile node at the home agent expired (no timely Binding Updates were received). The MO instances in the notifications will be identified by the mip6BindingHomeAddressType and mip6BindingHomeAddress for the mobile node in the mip6BindingCacheTable. " REFERENCE "RFC 3775 : Section 10.3.2" ::= { mip6Notifications 4 } Keeni, et al. Standards Track [Page 77] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnBindingExpiredAtCN NOTIFICATION-TYPE OBJECTS { mip6BindingTimeRegistered, mip6BindingCOAType, mip6BindingCOA } STATUS current DESCRIPTION "This notification is sent by a correspondent node when a binding for the mobile node at the correspondent node expired (no timely Binding Updates were received). The MO instances in the notifications will be identified by the mip6BindingHomeAddressType and mip6BindingHomeAddress for the mobile node in the mip6BindingCacheTable. " ::= { mip6Notifications 5 } Keeni, et al. Standards Track [Page 78] RFC 4295 MOBILEIPV6-MIB April 2006 -- Conformance information mip6Groups OBJECT IDENTIFIER ::= { mip6Conformance 1 } mip6Compliances OBJECT IDENTIFIER ::= { mip6Conformance 2 } -- Units of conformance mip6SystemGroup OBJECT-GROUP OBJECTS { mip6Capabilities, mip6Status } STATUS current DESCRIPTION " A collection of objects for basic MIPv6 monitoring." ::= { mip6Groups 1 } mip6BindingCacheGroup OBJECT-GROUP OBJECTS { mip6BindingCOAType, mip6BindingCOA, mip6BindingTimeRegistered, mip6BindingTimeGranted, mip6BindingTimeRemaining, mip6BindingMaxSeq, mip6BindingHomeRegn, mip6BindingUsageTS, mip6BindingUsageCount, mip6BindingAdminStatus } STATUS current DESCRIPTION " A collection of objects for monitoring the Binding Cache. " ::= { mip6Groups 2 } Keeni, et al. Standards Track [Page 79] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingHstGroup OBJECT-GROUP OBJECTS { mip6BindingHstCOAType, mip6BindingHstCOA, mip6BindingHstTimeRegistered, mip6BindingHstTimeExpired, mip6BindingHstHomeRegn, mip6BindingHstUsageTS, mip6BindingHstUsageCount } STATUS current DESCRIPTION " A collection of objects for monitoring the Binding History. This can be used to monitor the movement of the mobile node. " ::= { mip6Groups 3 } mip6TotalTrafficGroup OBJECT-GROUP OBJECTS { mip6InOctets, mip6HCInOctets, mip6InPkts, mip6HCInPkts, mip6OutOctets, mip6HCOutOctets, mip6OutPkts, mip6HCOutPkts, mip6CounterDiscontinuityTime } STATUS current DESCRIPTION " A collection of objects for monitoring the total MIPv6 traffic. " ::= { mip6Groups 4 } Keeni, et al. Standards Track [Page 80] RFC 4295 MOBILEIPV6-MIB April 2006 mip6NodeTrafficGroup OBJECT-GROUP OBJECTS { mip6NodeInOctets, mip6HCNodeInOctets, mip6NodeInPkts, mip6HCNodeInPkts, mip6NodeOutOctets, mip6HCNodeOutOctets, mip6NodeOutPkts, mip6HCNodeOutPkts, mip6NodeCtrDiscontinuityTime } STATUS current DESCRIPTION " A collection of objects for monitoring the MIPv6 traffic due to a mobile node. " ::= { mip6Groups 5 } mip6MnSystemGroup OBJECT-GROUP OBJECTS { mip6MnHomeAddressState } STATUS current DESCRIPTION " A collection of objects for basic monitoring of the mobile node. " ::= { mip6Groups 6 } mip6MnConfGroup OBJECT-GROUP OBJECTS { mip6MnDiscoveryRequests, mip6MnDiscoveryReplies, mip6MnDiscoveryTimeouts, mip6MnPrefixSolicitationsSent, mip6MnPrefixAdvsRecd, mip6MnPrefixAdvsIgnored, mip6MnMovedToFN, mip6MnMovedToHN } STATUS current DESCRIPTION " A collection of objects for monitoring the advertisement-related info on the mobile node. " ::= { mip6Groups 7 } Keeni, et al. Standards Track [Page 81] RFC 4295 MOBILEIPV6-MIB April 2006 mip6MnRegistrationGroup OBJECT-GROUP OBJECTS { mip6MnBLCOAType, mip6MnBLCOA, mip6MnBLLifeTimeRequested, mip6MnBLLifeTimeGranted, mip6MnBLMaxSeq, mip6MnBLTimeSent, mip6MnBLAccepted, mip6MnBLAcceptedTime, mip6MnBLRetransmissions, mip6MnBLDontSendBUFlag, -- -- Binding Update List -- mip6MnMobilityMessagesSent, mip6MnMobilityMessagesRecd, mip6MnBUsToHA, mip6MnBUAcksFromHA, mip6MnBUsToCN, mip6MnBUAcksFromCN, mip6MnBindingErrorsFromCN, mip6MnICMPErrorsRecd, mip6MnBRRequestsRecd } STATUS current DESCRIPTION " A collection of objects for monitoring the registration statistics for the mobile node. " ::= { mip6Groups 8 } Keeni, et al. Standards Track [Page 82] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnStatsGroup OBJECT-GROUP OBJECTS { mip6CnBURequestsAccepted, mip6CnBURequestsRejected, mip6CnBCEntryCreationTime, mip6CnBUAcceptedTime, mip6CnBURejectionTime, mip6CnBURejectionCode, mip6CnCtrDiscontinuityTime } STATUS current DESCRIPTION " A collection of objects for monitoring the control messages and corresponding statistics for each mobile node communicating with the correspondent node. " ::= { mip6Groups 9 } mip6HaSystemGroup OBJECT-GROUP OBJECTS { mip6HaAdvsRecd, mip6HaAdvsSent, mip6HaAdvPreference, mip6HaAdvLifetime, mip6HaPrefixAdv, mip6HaPrefixSolicitation, mip6HaMCastCtlMsgSupport } STATUS current DESCRIPTION " A collection of objects for monitoring the advertisement-related parameters and statistics for the home agent. " ::= { mip6Groups 10 } Keeni, et al. Standards Track [Page 83] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaListGroup OBJECT-GROUP OBJECTS { mip6HaPreference, mip6HaRecvLifeTime, mip6HaRecvTimeStamp, mip6HaGaGlobalAddressType, mip6HaGaGlobalAddress } STATUS current DESCRIPTION " A collection of objects for monitoring the Home Agent List on the home agent. " ::= { mip6Groups 11 } mip6HaStatsGroup OBJECT-GROUP OBJECTS { mip6HaBURequestsAccepted, mip6HaBURequestsDenied, mip6HaBCEntryCreationTime, mip6HaBUAcceptedTime, mip6HaBURejectionTime, mip6HaRecentBURejectionCode, mip6HaCtrDiscontinuityTime } STATUS current DESCRIPTION " A collection of objects for monitoring registration-related statistics on the home agent. " ::= { mip6Groups 12 } Keeni, et al. Standards Track [Page 84] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CnGlobalStatsGroup OBJECT-GROUP OBJECTS { mip6CnHomeTestInitsRecd, mip6CnHomeTestsSent, mip6CnCareOfTestInitsRecd, mip6CnCareOfTestsSent, mip6CnBUsRecd, mip6CnBUAcksSent, mip6CnBRsSent, mip6CnBindingErrors, mip6CnBUsAccepted, mip6CnBUsRejected, mip6CnReasonUnspecified, mip6CnInsufficientResource, mip6CnHomeRegnNotSupported, mip6CnSeqNumberOutOfWindow, mip6CnExpiredHomeNonceIndex, mip6CnExpiredCareOfNonceIndex, mip6CnExpiredNonce, mip6CnRegTypeChangeDisallowed } STATUS current DESCRIPTION " A collection of objects for monitoring advertisement and registration statistics on a correspondent node. " ::= { mip6Groups 13 } Keeni, et al. Standards Track [Page 85] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaGlobalStatsGroup OBJECT-GROUP OBJECTS { mip6HaHomeTestInitsRecd, mip6HaHomeTestsSent, mip6HaBUsRecd, mip6HaBUAcksSent, mip6HaBRAdviceSent, mip6HaBUsAccepted, mip6HaPrefDiscoverReqd, mip6HaReasonUnspecified, mip6HaAdmProhibited, mip6HaInsufficientResource, mip6HaHomeRegnNotSupported, mip6HaNotHomeSubnet, mip6HaNotHomeAgentForThisMN, mip6HaDupAddrDetectionFailed, mip6HaSeqNumberOutOfWindow, mip6HaExpiredHomeNonceIndex, mip6HaRegTypeChangeDisallowed } STATUS current DESCRIPTION " A collection of objects for monitoring advertisement and registration statistics on a home agent. " ::= { mip6Groups 14 } mip6BindingCacheCtlGroup OBJECT-GROUP OBJECTS { mip6BindingAdminStatus } STATUS current DESCRIPTION "A collection of objects for controlling the Binding Cache. " ::= { mip6Groups 15 } Keeni, et al. Standards Track [Page 86] RFC 4295 MOBILEIPV6-MIB April 2006 mip6NotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mip6MnRegistered, mip6MnDeRegistered, mip6MnCOAChanged, mip6MnBindingExpiredAtHA, mip6MnBindingExpiredAtCN } STATUS current DESCRIPTION "A collection of notifications from a home agent or correspondent node to the Manager about the status of a mobile node. " ::= { mip6Groups 16 } -- Compliance statements Keeni, et al. Standards Track [Page 87] RFC 4295 MOBILEIPV6-MIB April 2006 mip6CoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB. " MODULE -- this module MANDATORY-GROUPS { mip6SystemGroup } ::= { mip6Compliances 1 } mip6Compliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the Binding Cache and the Total Traffic. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { mip6SystemGroup, mip6BindingCacheGroup, mip6TotalTrafficGroup } ::= { mip6Compliances 2 } Keeni, et al. Standards Track [Page 88] RFC 4295 MOBILEIPV6-MIB April 2006 mip6Compliance3 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the Binding Cache, the Binding History, the total traffic, and the mobile node-wide traffic. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHstHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- -- OBJECT mip6BindingHstHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- " MODULE -- this module MANDATORY-GROUPS { mip6SystemGroup, mip6BindingCacheGroup, mip6BindingHstGroup, mip6TotalTrafficGroup, mip6NodeTrafficGroup } Keeni, et al. Standards Track [Page 89] RFC 4295 MOBILEIPV6-MIB April 2006 ::= { mip6Compliances 3 } mip6CoreReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB without support for read-write (i.e., in read-only mode). " MODULE -- this module MANDATORY-GROUPS { mip6SystemGroup } OBJECT mip6Status MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mip6Compliances 4 } mip6ReadOnlyCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB without support for read-write (i.e., in read-only mode) and support monitoring of the Binding Cache and Total Traffic. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module Keeni, et al. Standards Track [Page 90] RFC 4295 MOBILEIPV6-MIB April 2006 MANDATORY-GROUPS { mip6SystemGroup, mip6BindingCacheGroup, mip6TotalTrafficGroup } OBJECT mip6Status MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6BindingAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mip6Compliances 5 } mip6ReadOnlyCompliance3 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB without support for read-write (i.e., in read-only mode) and support monitoring of the Binding Cache, the Binding History, the total traffic, and the mobile node-wide traffic. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHstHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- Keeni, et al. Standards Track [Page 91] RFC 4295 MOBILEIPV6-MIB April 2006 -- OBJECT mip6BindingHstHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- " MODULE -- this module MANDATORY-GROUPS { mip6SystemGroup, mip6BindingCacheGroup, mip6BindingHstGroup, mip6TotalTrafficGroup, mip6NodeTrafficGroup } OBJECT mip6Status MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6BindingAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mip6Compliances 6 } mip6MnCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the basic mobile node functionality. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6MnHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global Keeni, et al. Standards Track [Page 92] RFC 4295 MOBILEIPV6-MIB April 2006 -- ipv6 addresses for the mip6MnHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { mip6MnSystemGroup } ::= { mip6Compliances 7 } mip6MnCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the mobile node functionality specifically the Discovery- and Registration-related statistics, There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6MnHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnBLNodeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6MnBLNodeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnBLNodeAddress -- object. Keeni, et al. Standards Track [Page 93] RFC 4295 MOBILEIPV6-MIB April 2006 -- " MODULE -- this module MANDATORY-GROUPS { mip6MnSystemGroup, mip6MnConfGroup, mip6MnRegistrationGroup, mip6TotalTrafficGroup } ::= { mip6Compliances 8 } mip6CnCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the basic correspondent node functionality. " MODULE -- this module MANDATORY-GROUPS { mip6CnGlobalStatsGroup, mip6TotalTrafficGroup } ::= { mip6Compliances 9 } mip6CnCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the basic correspondent node functionality. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. Keeni, et al. Standards Track [Page 94] RFC 4295 MOBILEIPV6-MIB April 2006 " MODULE -- this module MANDATORY-GROUPS { mip6CnGlobalStatsGroup, mip6CnStatsGroup, mip6TotalTrafficGroup } ::= { mip6Compliances 10 } mip6HaCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the basic home agent functionality. " MODULE -- this module MANDATORY-GROUPS { mip6HaSystemGroup } ::= { mip6Compliances 11 } mip6HaCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring of the home agent functionality specifically the Home Agent List and the home-agent-registration-related statistics, There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6HaLinkLocalAddressType Keeni, et al. Standards Track [Page 95] RFC 4295 MOBILEIPV6-MIB April 2006 -- SYNTAX InetAddressType { ipv6z(4) } -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- -- OBJECT mip6HaLinkLocalAddress -- SYNTAX InetAddress (SIZE(20)) -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { mip6HaSystemGroup, mip6HaListGroup, mip6HaStatsGroup, mip6HaGlobalStatsGroup, mip6TotalTrafficGroup } ::= { mip6Compliances 12 } mip6HaCompliance3 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support monitoring and control of the home agent functionality specifically the Home Agent List and the home-agent-registration-related statistics, There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress Keeni, et al. Standards Track [Page 96] RFC 4295 MOBILEIPV6-MIB April 2006 -- object. -- -- OBJECT mip6HaLinkLocalAddressType -- SYNTAX InetAddressType { ipv6z(4) } -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- -- OBJECT mip6HaLinkLocalAddress -- SYNTAX InetAddress (SIZE(20)) -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { mip6HaSystemGroup, mip6HaListGroup, mip6HaStatsGroup, mip6HaGlobalStatsGroup, mip6BindingCacheCtlGroup, mip6TotalTrafficGroup } ::= { mip6Compliances 13 } Keeni, et al. Standards Track [Page 97] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaCoreReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB without support for read-write (i.e., in read-only mode) and support monitoring of the basic home agent functionality. " MODULE -- this module MANDATORY-GROUPS { mip6HaSystemGroup } OBJECT mip6HaAdvPreference MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaAdvLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaPrefixAdv MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaPrefixSolicitation MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaMCastCtlMsgSupport MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mip6Compliances 14 } Keeni, et al. Standards Track [Page 98] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaReadOnlyCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB without support for read-write (i.e., in read-only mode) and support monitoring of the home agent functionality specifically the Home Agent List and the home-agent-registration-related statistics. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6HaLinkLocalAddressType -- SYNTAX InetAddressType { ipv6z(4) } -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- -- OBJECT mip6HaLinkLocalAddress -- SYNTAX InetAddress (SIZE(20)) -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { mip6HaSystemGroup, mip6HaListGroup, mip6HaStatsGroup, mip6HaGlobalStatsGroup, Keeni, et al. Standards Track [Page 99] RFC 4295 MOBILEIPV6-MIB April 2006 mip6TotalTrafficGroup } OBJECT mip6HaAdvPreference MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaAdvLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaPrefixAdv MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaPrefixSolicitation MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaMCastCtlMsgSupport MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mip6Compliances 15 } Keeni, et al. Standards Track [Page 100] RFC 4295 MOBILEIPV6-MIB April 2006 mip6HaReadOnlyCompliance3 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB without support for read-write (i.e., in read-only mode) and support monitoring and control of the home agent functionality specifically the Home Agent List and the home-agent-registration-related statistics, There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6HaLinkLocalAddressType -- SYNTAX InetAddressType { ipv6z(4) } -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- -- OBJECT mip6HaLinkLocalAddress -- SYNTAX InetAddress (SIZE(20)) -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { mip6HaSystemGroup, mip6HaListGroup, mip6HaStatsGroup, mip6HaGlobalStatsGroup, Keeni, et al. Standards Track [Page 101] RFC 4295 MOBILEIPV6-MIB April 2006 mip6BindingCacheCtlGroup, mip6TotalTrafficGroup } OBJECT mip6HaAdvPreference MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaAdvLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaPrefixAdv MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaPrefixSolicitation MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6HaMCastCtlMsgSupport MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mip6BindingAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mip6Compliances 16 } mip6NotificationCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MOBILEIPV6-MIB and support Notification from home agent or correspondent node to management stations about the mobile node status. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: Keeni, et al. Standards Track [Page 102] RFC 4295 MOBILEIPV6-MIB April 2006 -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. " MODULE -- this module MANDATORY-GROUPS { mip6NotificationGroup } ::= { mip6Compliances 17 } END Keeni, et al. Standards Track [Page 103] RFC 4295 MOBILEIPV6-MIB April 2006 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and the corresponding sensitivity/vulnerability: mip6Status: The value of this object is used to enable or disable the MIPv6 functionality on a MIPv6 entity. Access to this MO may be abused to disrupt the MIPv6 communication. mip6HaAdvPreference: Access to this object may be abused to force MNs into selecting the wrong HA. mip6HaAdvLifetime: Access to this object may be abused to set the advertised lifetime to incorrect values. That will have an adverse impact on the MIPv6 communication. mip6BindingAdminStatus: The value of this object is used to control the status of a Binding Cache entry. Access to this object may be abused to deny Mobile IPv6 connectivity to a legitimate user or to grant Mobile IPv6 connectivity to an illegal user. mip6HaPrefixAdv: The value of this object indicates whether the home agent will send ICMP Mobile Prefix Advertisements to the mobile node. Access to this object may be abused to send unwanted/wrong prefix information or to deny the mobile node from receiving information about the changes in the home prefixes. This may result in disruption of the Mobile IPv6 connectivity. mip6HaPrefixSolicitation: The value of this object indicates whether the home agent should respond to ICMP Mobile Prefix Solicitation messages from a mobile node. Access to this object may be abused to deny the mobile node information about its home prefix. This may result in disruption of the Mobile IPv6 connectivity. mip6HaMCastCtlMsgSupport: The value of this object decides whether the home agent should process the multicast group membership control messages it receives from mobile nodes. Access to this object may be used to subvert administrate policy on multicasting or to disrupt the multicast communication with the mobile node. Keeni, et al. Standards Track [Page 104] RFC 4295 MOBILEIPV6-MIB April 2006 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: The address-related objects in this MIB may be considered to be particularly sensitive and/or private. The care-of-address-related objects reveal the location and movement of the mobile node. This information may be considered to be private and sensitive and must be carefully handled. mip6BindingHstCOAType mip6BindingHstCOA mip6MnBLCOAType mip6MnBLCOA The mobile node's home-address- and home-agent-related information may be considered to be sensitive too as these may provide clues to a malicious party on ways to disrupt the mobile nodes communication channels. mip6BindingHstHomeAddressType, mip6BindingHstHomeAddress, mip6MnHomeAddressType, mip6MnHomeAddress The correspondent node's address-related MOs will reveal the nodes with whom the mobile node is corresponding. This information may be considered private and sensitive. mip6MnBLNodeAddressType, mip6MnBLNodeAddress SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator Keeni, et al. Standards Track [Page 105] RFC 4295 MOBILEIPV6-MIB April 2006 responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations IANA has assigned a base arc in the 'mib-2' (standards track) OID tree for the 'mip6MIB' MODULE-IDENTITY defined in the Mobile-IPv6 MIB. The mib-2 number is 133 for mip6MIB. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3775] Johnson, D., Perkins, C., and Arkko J., Mobility Support in IPv6" RFC 3775, June 2004. [RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. Keeni, et al. Standards Track [Page 106] RFC 4295 MOBILEIPV6-MIB April 2006 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. 9. Acknowledgements The following groups and individuals have contributed to this document with discussions and comments: WIDE-netman group C.M. Heard Keeni, et al. Standards Track [Page 107] RFC 4295 MOBILEIPV6-MIB April 2006 Authors' Addresses Glenn Mansfield Keeni Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075 Japan Phone: +81-3-5665-5069 EMail: nagami@inetcore.com Kazuhide Koide Tohoku University 2-1-1, Katahira Aoba-ku, Sendai, 980-8577 Japan Phone: +81-22-217-5454 EMail: koide@shiratori.riec.tohoku.ac.jp Sri Gundavelli Cisco Systems 170 W.Tasman Drive, San Jose, CA 95134 USA Phone: +1-408-527-6109 EMail: sgundave@cisco.com Keeni, et al. Standards Track [Page 108] RFC 4295 MOBILEIPV6-MIB April 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Keeni, et al. Standards Track [Page 109] snmp-mibs-downloader-1.1/mibrfcs/rfc4318.txt0000644000000000000000000006673411402176072015602 0ustar Network Working Group D. Levi Request for Comments: 4318 Nortel Networks Category: Standards Track D. Harrington Effective Software December 2005 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 3. Relationship to IEEE 802.1t and 802.1w Amendments ...............2 4. Relation to the BRIDGE-MIB ......................................3 5. Definitions for RSTP-MIB ........................................3 6. Acknowledgements ...............................................10 7. IANA Considerations ............................................10 8. Security Considerations ........................................10 9. Normative References ...........................................11 10. Informative References ........................................12 Levi & Harrington Standards Track [Page 1] RFC 4318 RSTP MIB December 2005 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree (RSTP) capability defined by the IEEE P802.1t [802.1t] and P802.1w [802.1w] amendments to IEEE Std 802.1D-1998 [802.1D-1998] for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. 3. Relationship to IEEE 802.1t and 802.1w Amendments This document defines managed objects for the Rapid Spanning Tree Protocol defined by the IEEE P802.1t and IEEE P802.1w amendments to 802.1D-1998. RSTP-MIB Name IEEE 802.1 Reference dot1dStp dot1dStpVersion (w) 17.16.1 ForceVersion dot1dStpTxHoldCount (w) 17.16.6 TxHoldCount dot1dStpExtPortTable dot1dStpPortProtocolMigration (w) 17.18.10 mcheck dot1dStpPortAdminEdgePort (t) 18.3.3 adminEdgePort dot1dStpPortOperEdgePort (t) 18.3.4 operEdgePort dot1dStpPortAdminPointToPoint (w) 6.4.3 adminPointToPointMAC dot1dStpPortOperPointToPoint (w) 6.4.3 operPointToPointMAC dot1dStpPortAdminPathCost (D) 8.5.5.3 Path Cost There are concerns that there may be changes made in the 802.1D-2004 edition that would lead to non-backward-compatible SMI changes for 802.1t and 802.1w managed objects in the MIB modules. The Bridge MIB working group decided to 'freeze' the technical content of the MIB modules at a level that is compatible with the 802.1t and 802.1w Levi & Harrington Standards Track [Page 2] RFC 4318 RSTP MIB December 2005 versions, and leave to the IEEE 802.1 working group any updates beyond this. For informational purposes only, these are the references for the above objects in 802.1D-2004 [802.1D-2004]. RSTP-MIB Name IEEE 802.1D-2004 Reference dot1dStp dot1dStpVersion 17.13.4 ForceVersion dot1dStpTxHoldCount 17.13.12 TxHoldCount dot1dStpExtPortTable dot1dStpPortProtocolMigration 17.19.13 mcheck dot1dStpPortAdminEdgePort 17.13.1 adminEdgePort dot1dStpPortOperEdgePort 17.19.17 operEdgePort dot1dStpPortAdminPointToPoint 6.4.3 adminPointToPointMAC dot1dStpPortOperPointToPoint 6.4.3 operPointToPointMAC dot1dStpPortAdminPathCost 17.13.11 Path Cost 4. Relation to the BRIDGE-MIB The objects in the RSTP-MIB supplement those defined in the Bridge MIB [RFC4188]. The Original BRIDGE-MIB [RFC1493] has been updated in an SMIv2- compliant version [RFC4188]. Conformance statements have been added and some description and reference clauses have been updated. The interpretations of some objects were changed to accommodate IEEE 802.1t and 802.1w amendments. The object dot1dStpPortPathCost32 was added to support IEEE 802.1t, and the permissible values of dot1dStpPriority and dot1dStpPortPriority have been clarified for bridges supporting IEEE 802.1t or IEEE 802.1w. The interpretation of dot1dStpTimeSinceTopologyChange has been clarified for bridges supporting the RSTP. See the updated BRIDGE-MIB [RFC4188] for details. 5. Definitions for RSTP-MIB RSTP-MIB DEFINITIONS ::= BEGIN -- ------------------------------------------------------------- -- MIB for IEEE 802.1w Rapid Spanning Tree Protocol -- ------------------------------------------------------------- IMPORTS Levi & Harrington Standards Track [Page 3] RFC 4318 RSTP MIB December 2005 MODULE-IDENTITY, OBJECT-TYPE, Integer32, mib-2 FROM SNMPv2-SMI TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF dot1dStp, dot1dStpPortEntry FROM BRIDGE-MIB; rstpMIB MODULE-IDENTITY LAST-UPDATED "200512070000Z" ORGANIZATION "IETF Bridge MIB Working Group" CONTACT-INFO "Email: Bridge-mib@ietf.org" DESCRIPTION "The Bridge MIB Extension module for managing devices that support the Rapid Spanning Tree Protocol defined by IEEE 802.1w. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4318; See the RFC itself for full legal notices." REVISION "200512070000Z" DESCRIPTION "The initial version of this MIB module as published in RFC 4318." ::= { mib-2 134 } -- ---------------------------------------------------------- -- -- subtrees in the RSTP-MIB -- ---------------------------------------------------------- -- rstpNotifications OBJECT IDENTIFIER ::= { rstpMIB 0 } rstpObjects OBJECT IDENTIFIER ::= { rstpMIB 1 } rstpConformance OBJECT IDENTIFIER ::= { rstpMIB 2 } -- ------------------------------------------------------------- -- Addition to the dot1dStp group -- ------------------------------------------------------------- dot1dStpVersion OBJECT-TYPE SYNTAX INTEGER { stpCompatible(0), rstp(2) } MAX-ACCESS read-write STATUS current Levi & Harrington Standards Track [Page 4] RFC 4318 RSTP MIB December 2005 DESCRIPTION "The version of Spanning Tree Protocol the bridge is currently running. The value 'stpCompatible(0)' indicates the Spanning Tree Protocol specified in IEEE 802.1D-1998 and 'rstp(2)' indicates the Rapid Spanning Tree Protocol specified in IEEE 802.1w and clause 17 of 802.1D-2004. The values are directly from the IEEE standard. New values may be defined as future versions of the protocol become available. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1w clause 14.8.1, 17.12, 17.16.1" DEFVAL { rstp } ::= { dot1dStp 16 } dot1dStpTxHoldCount OBJECT-TYPE SYNTAX Integer32 (1..10) MAX-ACCESS read-write STATUS current DESCRIPTION "The value used by the Port Transmit state machine to limit the maximum transmission rate. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1w clause 17.16.6" DEFVAL { 3 } ::= { dot1dStp 17 } -- -- { dot1dStp 18 } was used to represent dot1dStpPathCostDefault -- in an earlier version of this MIB. It has since been -- obsoleted, and should not be used. -- dot1dStpExtPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dStpExtPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains port-specific Rapid Spanning Tree information." ::= { dot1dStp 19 } Levi & Harrington Standards Track [Page 5] RFC 4318 RSTP MIB December 2005 dot1dStpExtPortEntry OBJECT-TYPE SYNTAX Dot1dStpExtPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Rapid Spanning Tree information maintained by each port." AUGMENTS { dot1dStpPortEntry } ::= { dot1dStpExtPortTable 1 } Dot1dStpExtPortEntry ::= SEQUENCE { dot1dStpPortProtocolMigration TruthValue, dot1dStpPortAdminEdgePort TruthValue, dot1dStpPortOperEdgePort TruthValue, dot1dStpPortAdminPointToPoint INTEGER, dot1dStpPortOperPointToPoint TruthValue, dot1dStpPortAdminPathCost Integer32 } dot1dStpPortProtocolMigration OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When operating in RSTP (version 2) mode, writing true(1) to this object forces this port to transmit RSTP BPDUs. Any other operation on this object has no effect and it always returns false(2) when read." REFERENCE "IEEE 802.1w clause 14.8.2.4, 17.18.10, 17.26" ::= { dot1dStpExtPortEntry 1 } dot1dStpPortAdminEdgePort OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative value of the Edge Port parameter. A value of true(1) indicates that this port should be assumed as an edge-port, and a value of false(2) indicates that this port should be assumed as a non-edge-port. Levi & Harrington Standards Track [Page 6] RFC 4318 RSTP MIB December 2005 Setting this object will also cause the corresponding instance of dot1dStpPortOperEdgePort to change to the same value. Note that even when this object's value is true, the value of the corresponding instance of dot1dStpPortOperEdgePort can be false if a BPDU has been received. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1t clause 14.8.2, 18.3.3" ::= { dot1dStpExtPortEntry 2 } dot1dStpPortOperEdgePort OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The operational value of the Edge Port parameter. The object is initialized to the value of the corresponding instance of dot1dStpPortAdminEdgePort. When the corresponding instance of dot1dStpPortAdminEdgePort is set, this object will be changed as well. This object will also be changed to false on reception of a BPDU." REFERENCE "IEEE 802.1t clause 14.8.2, 18.3.4" ::= { dot1dStpExtPortEntry 3 } dot1dStpPortAdminPointToPoint OBJECT-TYPE SYNTAX INTEGER { forceTrue(0), forceFalse(1), auto(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative point-to-point status of the LAN segment attached to this port, using the enumeration values of the IEEE 802.1w clause. A value of forceTrue(0) indicates that this port should always be treated as if it is connected to a point-to-point link. A value of forceFalse(1) indicates that this port should be treated as having a shared media connection. A value of auto(2) indicates that this port is considered to have a point-to-point link if it is an Aggregator and all of its Levi & Harrington Standards Track [Page 7] RFC 4318 RSTP MIB December 2005 members are aggregatable, or if the MAC entity is configured for full duplex operation, either through auto-negotiation or by management means. Manipulating this object changes the underlying adminPortToPortMAC. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1w clause 6.4.3, 6.5, 14.8.2" ::= { dot1dStpExtPortEntry 4 } dot1dStpPortOperPointToPoint OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The operational point-to-point status of the LAN segment attached to this port. It indicates whether a port is considered to have a point-to-point connection. If adminPointToPointMAC is set to auto(2), then the value of operPointToPointMAC is determined in accordance with the specific procedures defined for the MAC entity concerned, as defined in IEEE 802.1w, clause 6.5. The value is determined dynamically; that is, it is re-evaluated whenever the value of adminPointToPointMAC changes, and whenever the specific procedures defined for the MAC entity evaluate a change in its point-to-point status." REFERENCE "IEEE 802.1w clause 6.4.3, 6.5, 14.8.2" ::= { dot1dStpExtPortEntry 5 } dot1dStpPortAdminPathCost OBJECT-TYPE SYNTAX Integer32 (0..200000000) MAX-ACCESS read-write STATUS current DESCRIPTION "The administratively assigned value for the contribution of this port to the path cost of paths toward the spanning tree root. Writing a value of '0' assigns the automatically calculated default Path Cost value to the port. If the default Path Cost is being used, this object returns '0' when read. This complements the object dot1dStpPortPathCost or dot1dStpPortPathCost32, which returns the operational value of the path cost. Levi & Harrington Standards Track [Page 8] RFC 4318 RSTP MIB December 2005 The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1D-1998: Section 8.5.5.3" ::= { dot1dStpExtPortEntry 6 } -- ------------------------------------------------------------- -- rstpMIB - Conformance Information -- ------------------------------------------------------------- rstpGroups OBJECT IDENTIFIER ::= { rstpConformance 1 } rstpCompliances OBJECT IDENTIFIER ::= { rstpConformance 2 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- rstpBridgeGroup OBJECT-GROUP OBJECTS { dot1dStpVersion, dot1dStpTxHoldCount } STATUS current DESCRIPTION "Rapid Spanning Tree information for the bridge." ::= { rstpGroups 1 } rstpPortGroup OBJECT-GROUP OBJECTS { dot1dStpPortProtocolMigration, dot1dStpPortAdminEdgePort, dot1dStpPortOperEdgePort, dot1dStpPortAdminPointToPoint, dot1dStpPortOperPointToPoint, dot1dStpPortAdminPathCost } STATUS current DESCRIPTION "Rapid Spanning Tree information for individual ports." ::= { rstpGroups 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- rstpCompliance MODULE-COMPLIANCE STATUS current Levi & Harrington Standards Track [Page 9] RFC 4318 RSTP MIB December 2005 DESCRIPTION "The compliance statement for device support of Rapid Spanning Tree Protocol (RSTP) bridging services." MODULE MANDATORY-GROUPS { rstpBridgeGroup, rstpPortGroup } ::= { rstpCompliances 1 } END 6. Acknowledgements This document was produced on behalf of the Bridge MIB Working Group in the Operations and Management area of the Internet Engineering Task Force. The authors wish to thank the members of the Bridge MIB Working Group, especially Alex Ruzin, for their comments and suggestions that improved this effort. Vivian Ngai and Les Bell were the initial authors of this document, and did the bulk of the development work for this document. 7. IANA Considerations The IANA has assigned the following OID: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- rstpMIB { mib-2 134 } 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Writable objects that could be misused to cause network delays and spanning tree instabilities include dot1dStpVersion, dot1dStpTxHoldCount, dot1dStpPortProtocolMigration, dot1dStpPortAdminEdgePort, and dot1dStpPortAdminPathCost. Levi & Harrington Standards Track [Page 10] RFC 4318 RSTP MIB December 2005 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: dot1dStpVersion could be read by an attacker to identify environments containing applications or protocols that are potentially sensitive to RSTP mode. dot1dStpPortAdminPointToPoint could be used to mislead an access control protocol, such as 802.1x, to believe that only one other system is attached to a LAN segment and to enable network access based on that assumption. This situation could permit potential man-in-the-middle attacks. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Levi & Harrington Standards Track [Page 11] RFC 4318 RSTP MIB December 2005 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [802.1D-1998] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005. [802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D) IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Technical and Editorial Corrections". [802.1w] IEEE 802.1w-2001, "(Amendment to IEEE Standard 802.1D) IEEE Standard for Information technology-- Telecommunications and information exchange between systems--Local and metropolitan area networks--Common Specifications--Part 3: Media Access Control (MAC) Bridges: Rapid Reconfiguation". 10. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [802.1D-2004] IEEE Project 802 Local and Metropolitan Area Networks, "IEEE Standard 802.1D-2004 MAC Bridges", 2004. [RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. Levi & Harrington Standards Track [Page 12] RFC 4318 RSTP MIB December 2005 Authors' Addresses David Levi Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 5138 EMail: dlevi@nortel.com David Harrington Effective Software 50 Harding Rd. Portsmouth, NH 03801 USA Phone: +1 603 436 8634 EMail: ietfdbh@comcast.net Les Bell Hemel Hempstead Herts. HP2 7YU UK EMail: elbell@ntlworld.com Vivian Ngai Salt lake City, UT USA EMail: vivian_ngai@acm.org Levi & Harrington Standards Track [Page 13] RFC 4318 RSTP MIB December 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Levi & Harrington Standards Track [Page 14] snmp-mibs-downloader-1.1/mibrfcs/rfc4319.txt0000644000000000000000000043706311402176072015600 0ustar Network Working Group C. Sikes Request for Comments: 4319 Zhone Technologies, Inc. Obsoletes: 3276 B. Ray Category: Standards Track PESA Switching Systems, Inc. R. Abbi Alcatel USA December 2005 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276. Sikes, et al. Standards Track [Page 1] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 2.1. Relationship to Other MIBs .................................3 2.1.1. General IF-MIB Integration (RFC 2863) ...............3 2.1.2. Usage of ifTable ....................................3 2.2. IANA Considerations ........................................4 2.3. Conventions Used in the MIB Module .........................5 2.3.1. Naming Conventions ..................................5 2.3.2. Textual Conventions .................................5 2.4. Structure ..................................................7 2.5. Line Topology ..............................................9 2.6. Counters, Interval Buckets, and Thresholds ................10 2.7. Profiles ..................................................11 2.8. Notifications .............................................12 3. Definitions ....................................................14 4. Implementation Analysis ........................................66 5. Security Considerations ........................................66 6. Acknowledgements ...............................................71 7. References .....................................................72 7.1. Normative References ......................................72 7.2. Informative References ....................................73 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Overview This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing HDSL2/SHDSL lines. Sikes, et al. Standards Track [Page 2] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 The MIB module described in RFC 3276 [RFC3276] describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) [T1E1.4] and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces [G.991.2]. These object descriptions are based upon the specifications for the HDSL2 and SHDSL Embedded Operations Channel (EOC), as defined in the American National Standards Institute (ANSI) T1E1.4/2000-006 [T1E1.4] and International Telecommunication Union (ITU) G.991.2 [G.991.2]. This document obsoletes RFC 3276 [RFC3276], which supports G.shdsl in that the MIB module described herein supports G.shdsl.bis as described in the G.991.2 [G.991.2]. In addition, objects have been added to improve the management of SHDSL lines. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of this document. 2.1. Relationship to Other MIBs This section outlines the relationship of this MIB module with other MIB modules described in RFCs. Specifically, the IF-MIB, as presented in RFC 2863 [RFC2863], is discussed. 2.1.1. General IF-MIB Integration (RFC 2863) The HDSL2/SHDSL line MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with RFC 2863 [RFC2863]. The IANA has assigned the following ifTypes to HDSL2 and SHDSL: IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... hdsl2 (168), -- High Bit-Rate DSL, 2nd generation shdsl (169), -- Multirate HDSL2 ... } Note that the ifFixedLengthGroup from RFC 2863 [RFC2863] MUST be supported and that the ifRcvAddressGroup does not apply to this MIB module. 2.1.2. Usage of ifTable The MIB branch identified by this ifType contains tables appropriate for this interface type. Most such tables extend the ifEntry table and are indexed by ifIndex. For interfaces in systems implementing Sikes, et al. Standards Track [Page 3] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 this MIB module, those table entries indexed by ifIndex MUST be persistent. The following attributes are part of the mandatory ifGeneralInformationGroup in RFC 2863 [RFC2863] and are not duplicated in the HDSL2/SHDSL line MIB. =================================================================== ifIndex Interface index. ifDescr See interfaces MIB [RFC2863]. ifType hdsl2(168) or shdsl(169). ifSpeed Set as appropriate. (This is fixed at 1552000 for HDSL2 lines) ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB [RFC2863]. ifOperStatus See interfaces MIB [RFC2863]. ifLastChange See interfaces MIB [RFC2863]. ifName See interfaces MIB [RFC2863]. ifAlias See interfaces MIB [RFC2863]. ifLinkUpDownTrapEnable Default to enabled(1). ifHighSpeed Set as appropriate. (For HDSL2 lines, this is fixed at 2) ifConnectorPresent Set as appropriate. =================================================================== Figure 1: Use of ifTable Objects 2.2. IANA Considerations The HDSL2-SHDSL-LINE-MIB module requires the allocation of a single object identifier for its MODULE-IDENTITY. The IANA has allocated this object identifier in the transmission subtree (48), defined in the SNMPv2-SMI MIB module. Sikes, et al. Standards Track [Page 4] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 The assignment was in fact done when RFC 3276 was published, and this revision of the RFC does not require any new action from IANA. 2.3. Conventions Used in the MIB Module 2.3.1. Naming Conventions A. xtuC refers to a central site terminal unit; H2TU-C for HDSL2, or STU-C for SHDSL. B. xtuR refers to a remote site terminal unit; H2TU-R for HDSL2, or STU-R for SHDSL. C. xtu refers to a terminal unit; either an xtuC or xtuR. D. xru refer to a regenerator unit; H2RU for HDSL2, or SRU for SHDSL. E. xU refers to any HDSL2/SHDSL unit; either an xtu or xru. F. CRC is Cyclic Redundancy Check [G.991.2]. G. ES means Errored Second [G.991.2]. J. LOSW means Loss of Sync Word [G.991.2]. I. LOSWS means LOSW Seconds [G.991.2]. J. SES means Severely Errored Second [G.991.2]. K. SNR means Signal-to-Noise Ratio [G.991.2]. L. UAS means Unavailable Second [G.991.2]. 2.3.2. Textual Conventions The following textual conventions are defined to reflect the line topology in the MIB module (further discussed in the following section) and to define the behavior of the statistics to be maintained by an agent. o Hdsl2ShdslUnitId: Attributes with this syntax uniquely identify each unit in an HDSL2/SHDSL span. It mirrors the EOC addressing mechanism: xtuC(1) - central office (CO) terminal unit xtuR(2) - customer premises equipment (CPE) terminal unit xru1(3) .. xru8(10) - regenerators, numbered from central office side o Hdsl2ShdslUnitSide: Attributes with this syntax reference the two sides of a unit: networkSide(1) - N in figure 2, below customerSide(2) - C in figure 2, below Sikes, et al. Standards Track [Page 5] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 o Hdsl2ShdslWirePair: Attributes with this syntax reference the wire pairs connecting the units: wirePair1(1) - First pair for HDSL2/SHDSL. wirePair2(2) - Optional second pair for SHDSL only. wirePair3(3) - Optional third pair for SHDSL.bis only. wirePair4(4) - Optional fourth pair for SHDSL.bis only. o Hdsl2ShdslTransmissionModeType: Attributes with this syntax specify the regional setting for an SHDSL line. Specified as a BITS construct, the two mode types are: region1 - ITU-T G.991.2 Annex A region2 - ITU-T G.991.2 Annex B o Hdsl2ShdslPerfCurrDayCount: Attributes with this syntax define the behavior of the 1-day (24 hour) gauges found in the MIB module. o Hdsl2Shdsl1DayIntervalCount: Attributes with this syntax define the behavior of the 1-day (24 hour) interval counters found in the MIB module. o Hdsl2ShdslPerfTimeElapsed: Attributes with this syntax define the behavior of the elapsed time counters found in the MIB module. o Hdsl2ShdslPerfIntervalThreshold: Attributes with this syntax define the behavior of the alarm thresholds found in the MIB module. o Hdsl2ShdslClockReferenceType: Attributes with this syntax define the clock references for the HDSL2/SHDSL span. Sikes, et al. Standards Track [Page 6] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 2.4. Structure The MIB module is structured into the following MIB groups: o Span Configuration Group: This group supports MIB objects for configuring parameters for the HDSL2/SHDSL span. It contains the following table: - hdsl2ShdslSpanConfTable o Span Status Group: This group supports MIB objects for retrieving span status information. It contains the following table: - hdsl2ShdslSpanStatusTable o Unit Inventory Group: This group supports MIB objects for retrieving unit inventory information about units in HDSL2/SHDSL lines via the EOC. It contains the following table: - hdsl2ShdslInventoryTable o Segment Endpoint Configuration Group: This group supports MIB objects for configuring parameters for the HDSL2/SHDSL segment endpoints. It contains the following table: - hdsl2ShdslEndpointConfTable o Segment Endpoint Current Status/Performance Group: This group supports MIB objects that provide the current status/ performance information relating to segment endpoints. It contains the following table: - hdsl2ShdslEndpointCurrTable o Segment Endpoint 15-Minute Interval Status/Performance Group: This group supports MIB objects that provide historic status/ performance information relating to segment endpoints in 15-minute intervals. It contains the following table: - hdsl2Shdsl15MinIntervalTable Sikes, et al. Standards Track [Page 7] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 o Segment Endpoint 1-Day Interval Status/Performance Group: This group supports MIB objects that provide historic status/ performance information relating to segment endpoints in 1-day intervals. It contains the following table: - hdsl2Shdsl1DayIntervalTable o Maintenance Group: This group supports MIB objects for performing maintenance operations such as loopbacks for HDSL2/SHDSL lines. It contains the following table(s): - hdsl2ShdslEndpointMaintTable - hdsl2ShdslUnitMaintTable o Span Configuration Profile Group: This group supports MIB objects for defining configuration profiles for HDSL2/SHDSL spans. It contains the following table: - hdsl2ShdslSpanConfProfileTable o Segment Endpoint Alarm Configuration Profile Group: This group supports MIB objects for defining alarm configuration profiles for HDSL2/SHDSL segment endpoints. It contains the following table: - hdsl2ShdslEndpointAlarmConfProfileTable o Notifications Group: This group defines the notifications supported for HDSL2/SHDSL lines: - hdsl2ShdslLoopAttenCrossing - hdsl2ShdslSNRMarginCrossing - hdsl2ShdslPerfESThresh - hdsl2ShdslPerfSESThresh - hdsl2ShdslPerfCRCanomaliesThresh - hdsl2ShdslPerfLOSWSThresh - hdsl2ShdslPerfUASThresh - hdsl2ShdslSpanInvalidNumRepeaters - hdsl2ShdslLoopbackFailure - hdsl2ShdslpowerBackoff - hdsl2ShdsldeviceFault Sikes, et al. Standards Track [Page 8] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 - hdsl2ShdsldcContinuityFault - hdsl2ShdslconfigInitFailure - hdsl2ShdslprotocolInitFailure - hdsl2ShdslnoNeighborPresent - hdsl2ShdslLocalPowerLoss o SHDSL Wire Pair Group: This group supports MIB objects that provide status of the SHDSL- specific wire pairs. - hdsl2ShdslEndpointCurrTipRingReversal - hdsl2ShdslEndpointCurrActivationState o Payload Group: This group supports MIB objects for retrieving payload rates that exclude any framing overhead. - hdsl2ShdslStatusMaxAttainablePayloadRate - hdsl2ShdslStatusActualPayloadRate 2.5. Line Topology An HDSL2/SHDSL line consists of a minimum of two units: xtuC (the central termination unit) and an xtuR (the remote termination unit). The line may optionally support up to 8 repeater/regenerator units (xru) as shown in the figure below. Sikes, et al. Standards Track [Page 9] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 <-- Network Side Customer Side --> || <~~~> <~~~> HDSL2/SHDSL Segments <~~~> +-------+ +-------+ +-------+ +-------+ +-------+ + C=1=N C=1=N C=..1..=N C=1=N + | xtuC | | xru1 | | xru2 | | xru8 | | xtuR | + C=2=N C=2=N C=..2..=N C=2=N + +-------+ +-------+ +-------+ +-------+ +-------+ Key: HDSL2/SHDSL span <~~~~> HDSL2/SHDSL segment =1= HDSL2/SHDSL wire-pair-1 =2= SHDSL optional wire-pair-2 (Not applicable to HDSL2) C Customer side segment endpoint (modem) N Network side segment endpoint (modem) Figure 2: General Topology for an HDSL2/SHDSL Line 2.6. Counters, Interval Buckets, and Thresholds For SNR Margin, Loop Attenuation, ES, SES, CRC anomalies, LOSW, and UAS, there are event counters, current 15-minute and 0 to 96 15- minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15- minute event bucket has an associated threshold notification. Unlike RFC 3593 [RFC3593] and RFC 2662 [RFC2662], there is no representation in the MIB module for invalid buckets. In those cases where the data for an interval is suspect or known to be invalid, the agent MUST NOT report the interval. If the current 15-minute event bucket is determined to be invalid, notifications based upon the value of the event bucket MUST NOT be generated. Not reporting an interval will result in holes in the associated table. For example, the table hdsl2Shdsl15MinIntervalTable is indexed by { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide, hdsl2ShdslEndpointWirePair, hdsl2Shdsl15MinIntervalNumber}. If interval 12 is determined to be invalid but intervals 11 and 13 are valid, a Get Next operation on the indices .1.1.1.1.11 would return indices .1.1.1.1.13. There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute interval and any wall clock; however, some implementations may align the 15-minute intervals with Sikes, et al. Standards Track [Page 10] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 quarter hours. Likewise, an implementation may choose to align 1-day intervals with the start of a day. Counters are not reset when an xU is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module). 2.7. Profiles As a managed node can handle a large number of xUs (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on every xU may become burdensome. Moreover, most lines are provisioned identically with the same set of parameters. To simplify the provisioning process, this MIB module makes use of profiles. A profile is a set of parameters that can be shared by multiple lines using the same configuration. The following profiles are used in this MIB module: o Span Configuration Profiles - Span configuration profiles contain parameters for configuring HDSL2/SHDSL spans. They are defined in the hdsl2ShdslSpanConfProfileTable. Since span configuration parameters are only applicable for SHDSL, the support for span configuration profiles is optional for HDSL2 interfaces. Note that the configuration of the span dictates the behavior for each individual segment endpoint in the span. If a different configuration is provisioned for any given segment endpoint within the span, the new configuration for this segment endpoint will override the span configuration for this segment endpoint only. o Segment Endpoint Alarm Configuration Profiles - These profiles contain parameters for configuring alarm thresholds for HDSL2/ SHDSL segment endpoints. These profiles are defined in the hdsl2ShdslEndpointAlarmConfProfileTable. The index value for this profile is a locally-unique administratively-assigned name for the profile having the textual convention 'SnmpAdminString' (RFC 3411 [RFC3411]). One or more lines may be configured to share parameters of a single profile (e.g., hdsl2ShdslEndpointAlarmConfProfile = 'silver') by setting its hdsl2ShdslEndpointAlarmConfProfile objects to the value of this profile. If a change is made to the profile, all lines that refer to it will be reconfigured to the changed parameters. Before a profile can be deleted or taken out of service, it must be first unreferenced from all associated lines. Sikes, et al. Standards Track [Page 11] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Implementations MUST provide a default profile whose name is 'DEFVAL' for each profile type. The values of the associated parameters will be vendor specific unless otherwise indicated in this document. Before a line's profiles have been set, these profiles will be automatically used by setting hdsl2ShdslEndpointAlarmConfProfile and hdsl2ShdslSpanConfProfile to 'DEFVAL' where appropriate. This default profile name, 'DEFVAL', is considered reserved in the context of profiles defined in this MIB module. Profiles are created, assigned, and deleted dynamically using the profile name and profile row status in each of the four profile tables. Profile changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line. 2.8. Notifications The ability to generate the SNMP notifications coldStart/warmStart (per [RFC3418]), which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/ linkDown (per [RFC2863]), which are per interface (i.e., HDSL2/SHDSL line) is required. A linkDown notification MAY be generated whenever any ES, SES, CRC anomaly, LOSW, or UAS event occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The notifications defined in this MIB module are for initialization failure and for the threshold crossings associated with the following events: ES, SES, CRC anomaly, LOSW, and UAS. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. The hdsl2ShdslEndpointCurrStatus is a bitmask representing all outstanding error conditions associated with a particular segment endpoint. Note that since the status of remote endpoints is obtained via the EOC, this information may be unavailable for units that are unreachable via EOC during a line error condition. Therefore, not all conditions may always be included in its current status. Notifications corresponding to the bit fields in this object are defined. Two alarm conditions, SNR Margin Alarm and Loop Attenuation Alarm, are organized in a manner slightly different from that implied in the EOC specifications. In the MIB module, these alarm conditions are Sikes, et al. Standards Track [Page 12] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 tied to the two thresholds, hdsl2ShdslEndpointThreshSNRMargin and hdsl2ShdslEndpointThreshLoopAttenuation, found in the hdsl2ShdslEndpointAlarmConfProfileTable. In the EOC, the alarm conditions associated with these thresholds are per unit. In the MIB module, these alarm conditions are per endpoint. For terminal units, this has no impact. For repeaters, this implies an implementation variance where the agent in the terminal unit is responsible for detecting a threshold crossing. As the reporting of a repeater detected alarm condition to the polling terminal unit occurs in the same EOC message as the reporting of the current SNR Margin and Loop Attenuation values, it is anticipated that this will have very little impact on agent implementation. A threshold notification occurs whenever the corresponding current 15-minute interval error counter becomes equal to, or exceeds, the threshold value. Only one notification SHOULD be sent per interval per interface. Since the current 15-minute counter is reset to 0 every 15 minutes, and if the condition persists, the notification may recur as often as every 15 minutes. For example, to get a notification whenever a "loss of" event occurs (but at most once every 15 minutes), set the corresponding threshold to 1. The agent will generate a notification when the event originally occurs. Notifications, other than the threshold notifications listed above, SHOULD be rate limited (throttled) such that there is at least a 1-minute gap between the generation of consecutive notifications of the same event. When notifications are rate limited, they are dropped and not queued for sending at a future time. This is intended to be a general rate-limiting statement for notifications that have no explicit rate-limiting assertions in this document otherwise. Note that the Network Management System, or NMS, may receive a linkDown notification as well, if enabled (via ifLinkUpDownTrapEnable [RFC2863]). At the beginning of the next 15-minute interval, the counter is reset. When the first second goes by and the event occurs, the current interval bucket will be 1, which equals the threshold, and the notification will be sent again. An hdsl2ShdslSpanInvalidNumRepeaters notification may be generated following completion of the discovery phase if the number of repeaters discovered on the line differs from the number of repeaters specified in hdsl2ShdslSpanConfNumRepeaters. For those conditions where the number of provisioned repeaters is greater than those encountered during span discovery, all table entries associated with the nonexistent repeaters are to be discarded. For those conditions where the number of provisioned repeaters is less than those Sikes, et al. Standards Track [Page 13] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 encountered during span discovery, additional table entries are to be created using the default span configuration profile. 3. Definitions HDSL2-SHDSL-LINE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, Gauge32, NOTIFICATION-TYPE, Integer32, transmission FROM SNMPv2-SMI RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC ifIndex FROM IF-MIB PerfCurrentCount, PerfIntervalCount FROM PerfHist-TC-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; hdsl2ShdslMIB MODULE-IDENTITY LAST-UPDATED "200512070000Z" -- December 7, 2005 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org WG-URL: http://www.ietf.org/html.charters/adslmib-charter.html Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: 1210-203 Westview Ln Raleigh NC 27605 USA Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair Bob Ray PESA Switching Systems, Inc. Sikes, et al. Standards Track [Page 14] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Postal 330-A Wynn Drive Huntsville, AL 35805 USA Phone +1 256 726 9200 ext. 142 Co-editor: Clay Sikes Zhone Technologies, Inc. Postal: 8545 126th Ave. N. Largo, FL 33772 USA Email: csikes@zhone.com Phone: +1 727 530 8257 Co-editor: Bob Ray PESA Switching Systems, Inc. Postal: 330-A Wynn Drive Huntsville, AL 35805 USA Email: rray@pesa.com Phone: +1 256 726 9200 ext. 142 Co-editor: Rajesh Abbi Alcatel USA Postal: 2301 Sugar Bush Road Raleigh, NC 27612-3339 USA Email: Rajesh.Abbi@alcatel.com Phone: +1 919 850 6194" DESCRIPTION "This MIB module defines a collection of objects for managing HDSL2/SHDSL lines. An agent may reside at either end of the line; however, the MIB module is designed to require no management communication between the modems beyond that inherent in the low-level EOC line protocol as defined in ANSI T1E1.4/2000-006 (for HDSL2 lines) or in ITU G.991.2 (for SHDSL lines). Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4319; see the RFC itself for full legal notices." REVISION "200512070000Z" -- December 7, 2005 DESCRIPTION "This version, published as RFC 4319. The following changes have been made in this version: 1. Added a 3rd and 4th wire pair. 2. Modified all rates such that their rates are only constrained by an unsigned 32-bit value and not by what today's perceived technology limitations are. Sikes, et al. Standards Track [Page 15] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 3. Clarified that the rates from RFC 3276 include payload and any applicable framing and added objects for payload-only rates. 4. Added an object to indicate whether the tip and ring are reversed on a wire pair. 5. Added an object to display the activation state of a wire pair. 6. Added references as necessary for clarification. 7. Added display hints to textual conventions as necessary. 8. Updated conformance statements as necessary. 9. Some changes were due to IETF requirements and RFC generation tools." REVISION "200205090000Z" -- May 9, 2002 DESCRIPTION "Initial version, published as RFC 3276." ::= { transmission 48 } hdsl2ShdslMibObjects OBJECT IDENTIFIER ::= { hdsl2ShdslMIB 1 } -- Textual Conventions used in this MIB module -- Hdsl2ShdslPerfCurrDayCount ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A gauge associated with interface performance measurements in a current 1-day (24 hour) measurement interval. The value of this gauge starts at zero at the beginning of an interval and is increased when associated events occur, until the end of the 1-day interval. At that time, the value of the gauge is stored in the previous 1-day history interval, as defined in a companion object of type Hdsl2Shdsl1DayIntevalCount, and the current interval gauge is restarted at zero. In the case where the agent has no valid data available for this interval, the corresponding object instance is not available, and upon a retrieval request, a corresponding error message shall be returned to indicate that this instance does not exist. Please note that zero is a valid value." SYNTAX Gauge32 Hdsl2Shdsl1DayIntervalCount ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" Sikes, et al. Standards Track [Page 16] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 STATUS current DESCRIPTION "A counter associated with interface performance measurements during the most previous 1-day (24 hour) measurement interval. The value of this gauge is equal to the value of the current day gauge, as defined in a companion object of type Hdsl2ShdslPerfCurrDayCount, at the end of its most recent interval. In the case where the agent has no valid data available for this interval, the corresponding object instance is not available, and upon a retrieval request, a corresponding error message shall be returned to indicate that this instance does not exist." SYNTAX Gauge32 Hdsl2ShdslPerfTimeElapsed ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The number of seconds that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock or the addition of a leap second, the current interval exceeds the maximum value, the agent will return the maximum value. For 15-minute intervals, the range is limited to (0..899). For 24-hour intervals, the range is limited to (0..86399)." SYNTAX Unsigned32(0..86399) Hdsl2ShdslPerfIntervalThreshold ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This convention defines a range of values that may be set in a fault threshold alarm control. As the number of seconds in a 15-minute interval numbers at most 900, objects of this type may have a range of 0...900, where the value of 0 disables the alarm." SYNTAX Unsigned32(0..900) Hdsl2ShdslUnitId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is the unique identification for all units in an HDSL2/SHDSL span. It is based on the EOC unit addressing scheme with reference to the xtuC." SYNTAX INTEGER Sikes, et al. Standards Track [Page 17] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 { xtuC(1), xtuR(2), xru1(3), xru2(4), xru3(5), xru4(6), xru5(7), xru6(8), xru7(9), xru8(10) } Hdsl2ShdslUnitSide ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is the referenced side of an HDSL2/SHDSL unit - Network or Customer side. The side facing the Network is the Network side, while the side facing the Customer is the Customer side." SYNTAX INTEGER { networkSide(1), customerSide(2) } Hdsl2ShdslWirePair ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is the referenced pair of wires in an HDSL2/SHDSL segment. HDSL2 only supports a single pair (wirePair1 or two wire), SHDSL lines support an optional second pair (wirePair2 or four wire), and G.shdsl.bis support an optional third pair (wirePair3 or six wire) and an optional fourth pair (wirePair4 or eight wire)." SYNTAX INTEGER { wirePair1(1), -- two wire wirePair2(2), -- four wire wirePair3(3), -- six wire wirePair4(4) -- eight wire } Hdsl2ShdslTransmissionModeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Contains the regional setting of the HDSL2/SHDSL span, represented as a bit-map of possible settings. The various bit positions are as follows: Sikes, et al. Standards Track [Page 18] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Bit Meaning Description 1 region 1 Indicates ITU-T G.991.2 Annex A. 2 region 2 Indicates ITU-T G.991.2 Annex B." SYNTAX BITS { region1(0), region2(1) } Hdsl2ShdslClockReferenceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The various STU-C symbol clock references for the HDSL2/SHDSL span, represented as an enumeration." SYNTAX INTEGER { localClk(1), -- Mode-1 per G991.2 networkClk(2), -- Mode-2 per G991.2 dataOrNetworkClk(3), -- Mode-3a per G991.2 dataClk(4) -- Mode-3b per G991.2 } -- Span Configuration Group -- hdsl2ShdslSpanConfTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslSpanConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports overall configuration of HDSL2/SHDSL spans. Entries in this table MUST be maintained in a persistent manner." ::= { hdsl2ShdslMibObjects 1 } hdsl2ShdslSpanConfEntry OBJECT-TYPE SYNTAX Hdsl2ShdslSpanConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2ShdslSpanConfTable. Each entry represents the complete span in a single HDSL2/SHDSL line. It is indexed by the ifIndex of the associated HDSL2/SHDSL line." INDEX { ifIndex } ::= { hdsl2ShdslSpanConfTable 1 } Sikes, et al. Standards Track [Page 19] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Hdsl2ShdslSpanConfEntry ::= SEQUENCE { hdsl2ShdslSpanConfNumRepeaters Unsigned32, hdsl2ShdslSpanConfProfile SnmpAdminString, hdsl2ShdslSpanConfAlarmProfile SnmpAdminString } hdsl2ShdslSpanConfNumRepeaters OBJECT-TYPE SYNTAX Unsigned32(0..8) UNITS "repeaters" MAX-ACCESS read-write STATUS current DESCRIPTION "This object provisions the number of repeaters/regenerators in this HDSL2/SHDSL span." ::= { hdsl2ShdslSpanConfEntry 1 } hdsl2ShdslSpanConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is a pointer to a span configuration profile in the hdsl2ShdslSpanConfProfileTable, which applies to this span. The value of this object is the index of the referenced profile in the hdsl2ShdslSpanConfProfileTable. Note that span configuration profiles are only applicable to SHDSL lines. HDSL2 lines MUST reference the default profile, 'DEFVAL'. By default, this object will have the value 'DEFVAL' (the index of the default profile). Any attempt to set this object to a value that is not the value of the index for an active entry in the profile table, hdsl2ShdslSpanConfProfileTable, MUST be rejected." ::= { hdsl2ShdslSpanConfEntry 2 } hdsl2ShdslSpanConfAlarmProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is a pointer to an alarm configuration profile in the hdsl2ShdslEndpointAlarmConfProfileTable. The value of this object is the index of the referenced profile in the hdsl2ShdslEndpointAlarmConfProfileTable. The alarm threshold configuration in the referenced profile will be Sikes, et al. Standards Track [Page 20] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 used by default for all segment endpoints in this span. Individual endpoints may override this profile by explicitly specifying some other profile in the hdsl2ShdslEndpointConfTable. By default, this object will have the value 'DEFVAL' (the index of the default profile). Any attempt to set this object to a value that is not the value of the index for an active entry in the profile table, hdsl2ShdslEndpointAlarmConfProfileTable, MUST be rejected." ::= { hdsl2ShdslSpanConfEntry 3 } -- Span Status Group -- hdsl2ShdslSpanStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslSpanStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides overall status information of HDSL2/SHDSL spans. This table contains live data from equipment. As such, it is NOT persistent." ::= { hdsl2ShdslMibObjects 2 } hdsl2ShdslSpanStatusEntry OBJECT-TYPE SYNTAX Hdsl2ShdslSpanStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2ShdslSpanStatusTable. Each entry represents the complete span in a single HDSL2/SHDSL line. It is indexed by the ifIndex of the associated HDSL2/SHDSL line." INDEX { ifIndex } ::= { hdsl2ShdslSpanStatusTable 1 } Hdsl2ShdslSpanStatusEntry ::= SEQUENCE { hdsl2ShdslStatusNumAvailRepeaters Unsigned32, hdsl2ShdslStatusMaxAttainableLineRate Unsigned32, hdsl2ShdslStatusActualLineRate Unsigned32, hdsl2ShdslStatusTransmissionModeCurrent Hdsl2ShdslTransmissionModeType, hdsl2ShdslStatusMaxAttainablePayloadRate Unsigned32, hdsl2ShdslStatusActualPayloadRate Unsigned32 } Sikes, et al. Standards Track [Page 21] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2ShdslStatusNumAvailRepeaters OBJECT-TYPE SYNTAX Unsigned32(0..8) MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the actual number of repeaters/regenerators discovered in this HDSL2/SHDSL span." ::= { hdsl2ShdslSpanStatusEntry 1 } hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the maximum attainable line rate in this HDSL2/SHDSL span. This object provides the maximum rate the line is capable of achieving. This is based upon measurements made during line probing. This rate includes payload (user data) and any applicable framing overhead." ::= { hdsl2ShdslSpanStatusEntry 2 } hdsl2ShdslStatusActualLineRate OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the actual line rate in this HDSL2/SHDSL span. This SHOULD equal ifSpeed. This rate includes payload (user data) and any applicable framing overhead" ::= { hdsl2ShdslSpanStatusEntry 3 } hdsl2ShdslStatusTransmissionModeCurrent OBJECT-TYPE SYNTAX Hdsl2ShdslTransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the current Power Spectral Density (PSD) regional setting of the HDSL2/SHDSL span." ::= { hdsl2ShdslSpanStatusEntry 4 } hdsl2ShdslStatusMaxAttainablePayloadRate OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION Sikes, et al. Standards Track [Page 22] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 "Contains the maximum attainable payload (user data) line rate in this HDSL2/SHDSL span. This object provides the maximum rate the line is capable of achieving. This is based upon measurements made during line probing. Any framing overhead is not included." ::= { hdsl2ShdslSpanStatusEntry 5 } hdsl2ShdslStatusActualPayloadRate OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) UNITS "bps" MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the actual line rate in this HDSL2/SHDSL span. Any framing overhead is not included." ::= { hdsl2ShdslSpanStatusEntry 6 } -- Unit Inventory Group -- hdsl2ShdslInventoryTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslInventoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports retrieval of unit inventory information available via the EOC from units in an HDSL2/SHDSL line. Entries in this table are dynamically created during the line discovery process. The life cycle for these entries is as follows: - xtu discovers a device, either a far-end xtu or an xru - an inventory table entry is created for the device - the line goes down for whatever reason - inventory table entries for unreachable devices are destroyed As these entries are created/destroyed dynamically, they are NOT persistent." ::= { hdsl2ShdslMibObjects 3 } hdsl2ShdslInventoryEntry OBJECT-TYPE SYNTAX Hdsl2ShdslInventoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2ShdslInventoryTable. Each entry Sikes, et al. Standards Track [Page 23] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 represents inventory information for a single unit in an HDSL2/SHDSL line. It is indexed by the ifIndex of the HDSL2/SHDSL line and the Hdsl2ShdslUnitId of the associated unit." INDEX { ifIndex, hdsl2ShdslInvIndex } ::= { hdsl2ShdslInventoryTable 1 } Hdsl2ShdslInventoryEntry ::= SEQUENCE { hdsl2ShdslInvIndex Hdsl2ShdslUnitId, hdsl2ShdslInvVendorID OCTET STRING, hdsl2ShdslInvVendorModelNumber OCTET STRING, hdsl2ShdslInvVendorSerialNumber OCTET STRING, hdsl2ShdslInvVendorEOCSoftwareVersion Integer32, hdsl2ShdslInvStandardVersion Integer32, hdsl2ShdslInvVendorListNumber OCTET STRING, hdsl2ShdslInvVendorIssueNumber OCTET STRING, hdsl2ShdslInvVendorSoftwareVersion OCTET STRING, hdsl2ShdslInvEquipmentCode OCTET STRING, hdsl2ShdslInvVendorOther OCTET STRING, hdsl2ShdslInvTransmissionModeCapability Hdsl2ShdslTransmissionModeType } hdsl2ShdslInvIndex OBJECT-TYPE SYNTAX Hdsl2ShdslUnitId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table corresponds to a physical element in an HDSL2/SHDSL span. It is based on the EOC unit addressing scheme with reference to the xtuC." ::= { hdsl2ShdslInventoryEntry 1 } hdsl2ShdslInvVendorID OBJECT-TYPE SYNTAX OCTET STRING(SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Vendor ID as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 25-32." ::= { hdsl2ShdslInventoryEntry 2 } hdsl2ShdslInvVendorModelNumber OBJECT-TYPE SYNTAX OCTET STRING(SIZE(12)) Sikes, et al. Standards Track [Page 24] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "Vendor model number as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 33-44." ::= { hdsl2ShdslInventoryEntry 3 } hdsl2ShdslInvVendorSerialNumber OBJECT-TYPE SYNTAX OCTET STRING(SIZE(12)) MAX-ACCESS read-only STATUS current DESCRIPTION "Vendor serial number as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 45-56." ::= { hdsl2ShdslInventoryEntry 4 } hdsl2ShdslInvVendorEOCSoftwareVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Vendor EOC version as reported in a Discovery Response message." REFERENCE "G.991.2, Section 9.5.5.7.2, Discovery response - Message ID 129, Octet 12." ::= { hdsl2ShdslInventoryEntry 5 } hdsl2ShdslInvStandardVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Version of the HDSL2/SHDSL standard implemented, as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octet 2." ::= { hdsl2ShdslInventoryEntry 6 } hdsl2ShdslInvVendorListNumber OBJECT-TYPE SYNTAX OCTET STRING(SIZE(3)) Sikes, et al. Standards Track [Page 25] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "Vendor list number as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 3-5." ::= { hdsl2ShdslInventoryEntry 7 } hdsl2ShdslInvVendorIssueNumber OBJECT-TYPE SYNTAX OCTET STRING(SIZE(2)) MAX-ACCESS read-only STATUS current DESCRIPTION "Vendor issue number as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 6-7." ::= { hdsl2ShdslInventoryEntry 8 } hdsl2ShdslInvVendorSoftwareVersion OBJECT-TYPE SYNTAX OCTET STRING(SIZE(6)) MAX-ACCESS read-only STATUS current DESCRIPTION "Vendor software version as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 8-13." ::= { hdsl2ShdslInventoryEntry 9 } hdsl2ShdslInvEquipmentCode OBJECT-TYPE SYNTAX OCTET STRING(SIZE(10)) MAX-ACCESS read-only STATUS current DESCRIPTION "Equipment code conforming to ANSI T1.213, Coded Identification of Equipment Entities." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 14-23." ::= { hdsl2ShdslInventoryEntry 10 } hdsl2ShdslInvVendorOther OBJECT-TYPE SYNTAX OCTET STRING(SIZE(12)) Sikes, et al. Standards Track [Page 26] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "Other vendor information as reported in an Inventory Response message." REFERENCE "G.991.2, Section 9.5.5.7.4, Inventory response - Message ID 130, Octets 57-68." ::= { hdsl2ShdslInventoryEntry 11 } hdsl2ShdslInvTransmissionModeCapability OBJECT-TYPE SYNTAX Hdsl2ShdslTransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the transmission mode capability of the SHDSL unit." ::= { hdsl2ShdslInventoryEntry 12 } -- Segment Endpoint Configuration Group -- hdsl2ShdslEndpointConfTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslEndpointConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports configuration parameters for segment endpoints in an HDSL2/SHDSL line. As this table is indexed by ifIndex, it MUST be maintained in a persistent manner." ::= { hdsl2ShdslMibObjects 4 } hdsl2ShdslEndpointConfEntry OBJECT-TYPE SYNTAX Hdsl2ShdslEndpointConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2ShdslEndpointConfTable. Each entry represents a single segment endpoint in an HDSL2/SHDSL line. It is indexed by the ifIndex of the HDSL2/SHDSL line, the UnitId of the associated unit, the side of the unit, and the wire pair of the associated modem." INDEX { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide, hdsl2ShdslEndpointWirePair} ::= { hdsl2ShdslEndpointConfTable 1 } Hdsl2ShdslEndpointConfEntry ::= SEQUENCE { Sikes, et al. Standards Track [Page 27] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2ShdslEndpointSide Hdsl2ShdslUnitSide, hdsl2ShdslEndpointWirePair Hdsl2ShdslWirePair, hdsl2ShdslEndpointAlarmConfProfile SnmpAdminString } hdsl2ShdslEndpointSide OBJECT-TYPE SYNTAX Hdsl2ShdslUnitSide MAX-ACCESS not-accessible STATUS current DESCRIPTION "The side of the unit associated with this segment endpoint -- Network/Customer side -- as per the Hdsl2ShdslUnitSide textual convention." ::= { hdsl2ShdslEndpointConfEntry 1 } hdsl2ShdslEndpointWirePair OBJECT-TYPE SYNTAX Hdsl2ShdslWirePair MAX-ACCESS not-accessible STATUS current DESCRIPTION "The wire pair of the modem associated with this segment endpoint as per the Hdsl2ShdslWirePair textual convention." ::= { hdsl2ShdslEndpointConfEntry 2 } hdsl2ShdslEndpointAlarmConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object configures the alarm threshold values to be used for this segment endpoint. The values are obtained from the alarm configuration profile referenced by this object. The value of this object is the index of the referenced profile in the hdsl2ShdslEndpointAlarmConfProfileTable, or NULL (a zero-length SnmpAdminString). If the value is a zero-length SnmpAdminString, the endpoint uses the default Alarm Configuration Profile for the associated span as per the hdsl2ShdslSpanConfAlarmProfile object in the hdsl2ShdslSpanConfTable. The default value of this object is a zero-length SnmpAdminString. Any attempt to set this object to a value that is not the value of the index for an active entry in the profile table, hdsl2ShdslEndpointAlarmConfProfileTable, MUST be rejected." ::= { hdsl2ShdslEndpointConfEntry 3 } -- Segment Endpoint Current Status/Performance Group -- Sikes, et al. Standards Track [Page 28] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2ShdslEndpointCurrTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslEndpointCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains current status and performance information for segment endpoints in HDSL2/SHDSL lines. As with other tables in this MIB module indexed by ifIndex, entries in this table MUST be maintained in a persistent manner." ::= { hdsl2ShdslMibObjects 5 } hdsl2ShdslEndpointCurrEntry OBJECT-TYPE SYNTAX Hdsl2ShdslEndpointCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2ShdslEndpointCurrTable. Each entry contains status and performance information relating to a single segment endpoint. It is indexed by the ifIndex of the HDSL2/SHDSL line, the UnitId of the associated unit, the side of the unit, and the wire pair of the associated modem." INDEX { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide, hdsl2ShdslEndpointWirePair } ::= { hdsl2ShdslEndpointCurrTable 1 } Hdsl2ShdslEndpointCurrEntry ::= SEQUENCE { hdsl2ShdslEndpointCurrAtn Integer32, hdsl2ShdslEndpointCurrSnrMgn Integer32, hdsl2ShdslEndpointCurrStatus BITS, hdsl2ShdslEndpointES Counter32, hdsl2ShdslEndpointSES Counter32, hdsl2ShdslEndpointCRCanomalies Counter32, hdsl2ShdslEndpointLOSWS Counter32, hdsl2ShdslEndpointUAS Counter32, hdsl2ShdslEndpointCurr15MinTimeElapsed Hdsl2ShdslPerfTimeElapsed, hdsl2ShdslEndpointCurr15MinES PerfCurrentCount, hdsl2ShdslEndpointCurr15MinSES PerfCurrentCount, hdsl2ShdslEndpointCurr15MinCRCanomalies PerfCurrentCount, hdsl2ShdslEndpointCurr15MinLOSWS PerfCurrentCount, hdsl2ShdslEndpointCurr15MinUAS PerfCurrentCount, hdsl2ShdslEndpointCurr1DayTimeElapsed Hdsl2ShdslPerfTimeElapsed, hdsl2ShdslEndpointCurr1DayES Hdsl2ShdslPerfCurrDayCount, hdsl2ShdslEndpointCurr1DaySES Sikes, et al. Standards Track [Page 29] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Hdsl2ShdslPerfCurrDayCount, hdsl2ShdslEndpointCurr1DayCRCanomalies Hdsl2ShdslPerfCurrDayCount, hdsl2ShdslEndpointCurr1DayLOSWS Hdsl2ShdslPerfCurrDayCount, hdsl2ShdslEndpointCurr1DayUAS Hdsl2ShdslPerfCurrDayCount, hdsl2ShdslEndpointCurrTipRingReversal INTEGER, hdsl2ShdslEndpointCurrActivationState INTEGER } hdsl2ShdslEndpointCurrAtn OBJECT-TYPE SYNTAX Integer32(-127..128) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The current loop attenuation for this endpoint as reported in a Network or Customer Side Performance Status message." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 1 } hdsl2ShdslEndpointCurrSnrMgn OBJECT-TYPE SYNTAX Integer32(-127..128) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The current SNR margin for this endpoint as reported in a Status Response/SNR message." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 2 } hdsl2ShdslEndpointCurrStatus OBJECT-TYPE SYNTAX BITS { noDefect(0), powerBackoff(1), deviceFault(2), dcContinuityFault(3), snrMarginAlarm(4), loopAttenuationAlarm(5), loswFailureAlarm(6), configInitFailure(7), protocolInitFailure(8), noNeighborPresent(9), loopbackActive(10) } Sikes, et al. Standards Track [Page 30] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "Contains the current state of the endpoint. This is a bit-map of possible conditions. The various bit positions are as follows: noDefect There are no defects on the line. powerBackoff Indicates enhanced Power Backoff. deviceFault Indicates that a vendor-dependent diagnostic or self-test fault has been detected. dcContinuityFault Indicates vendor-dependent conditions that interfere with span powering such as short and open circuits. snrMarginAlarm Indicates that the SNR margin has dropped below the alarm threshold. loopAttenuationAlarm Indicates that the loop attenuation exceeds the alarm threshold. loswFailureAlarm Indicates a forward LOSW alarm. configInitFailure Endpoint failure during initialization due to paired endpoint not able to support requested configuration. protocolInitFailure Endpoint failure during initialization due to incompatible protocol used by the paired endpoint. noNeighborPresent Endpoint failure during initialization due to no activation sequence detected from paired endpoint. loopbackActive A loopback is currently active at this segment endpoint. This is intended to supplement ifOperStatus. Note that there is a 1:1 relationship between the status bits defined in this object and the notification thresholds defined elsewhere in this MIB module." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" Sikes, et al. Standards Track [Page 31] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 ::= { hdsl2ShdslEndpointCurrEntry 3 } hdsl2ShdslEndpointES OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) on this endpoint since the xU was last restarted." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 4 } hdsl2ShdslEndpointSES OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) on this endpoint since the xU was last restarted." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 5 } hdsl2ShdslEndpointCRCanomalies OBJECT-TYPE SYNTAX Counter32 UNITS "detected CRC Anomalies" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC anomalies on this endpoint since the xU was last restarted." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 6 } hdsl2ShdslEndpointLOSWS OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Sync Word (LOSW) Seconds on this endpoint since the xU was last restarted." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 7 } hdsl2ShdslEndpointUAS OBJECT-TYPE SYNTAX Counter32 Sikes, et al. Standards Track [Page 32] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) on this endpoint since the xU was last restarted." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 8 } hdsl2ShdslEndpointCurr15MinTimeElapsed OBJECT-TYPE SYNTAX Hdsl2ShdslPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in the current 15-minute interval." ::= { hdsl2ShdslEndpointCurrEntry 9 } hdsl2ShdslEndpointCurr15MinES OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) in the current 15-minute interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 10 } hdsl2ShdslEndpointCurr15MinSES OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) in the current 15-minute interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 11 } hdsl2ShdslEndpointCurr15MinCRCanomalies OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "detected CRC Anomalies" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC anomalies in the current 15-minute interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" Sikes, et al. Standards Track [Page 33] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 ::= { hdsl2ShdslEndpointCurrEntry 12 } hdsl2ShdslEndpointCurr15MinLOSWS OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Sync Word (LOSW) Seconds in the current 15-minute interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 13 } hdsl2ShdslEndpointCurr15MinUAS OBJECT-TYPE SYNTAX PerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) in the current 15-minute interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 14 } hdsl2ShdslEndpointCurr1DayTimeElapsed OBJECT-TYPE SYNTAX Hdsl2ShdslPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::= { hdsl2ShdslEndpointCurrEntry 15 } hdsl2ShdslEndpointCurr1DayES OBJECT-TYPE SYNTAX Hdsl2ShdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) during the current day as measured by hdsl2ShdslEndpointCurr1DayTimeElapsed." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 16 } hdsl2ShdslEndpointCurr1DaySES OBJECT-TYPE SYNTAX Hdsl2ShdslPerfCurrDayCount UNITS "seconds" Sikes, et al. Standards Track [Page 34] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) during the current day as measured by hdsl2ShdslEndpointCurr1DayTimeElapsed." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 17 } hdsl2ShdslEndpointCurr1DayCRCanomalies OBJECT-TYPE SYNTAX Hdsl2ShdslPerfCurrDayCount UNITS "detected CRC Anomalies" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC anomalies during the current day as measured by hdsl2ShdslEndpointCurr1DayTimeElapsed." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 18 } hdsl2ShdslEndpointCurr1DayLOSWS OBJECT-TYPE SYNTAX Hdsl2ShdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Sync Word (LOSW) Seconds during the current day as measured by hdsl2ShdslEndpointCurr1DayTimeElapsed." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 19 } hdsl2ShdslEndpointCurr1DayUAS OBJECT-TYPE SYNTAX Hdsl2ShdslPerfCurrDayCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) during the current day as measured by hdsl2ShdslEndpointCurr1DayTimeElapsed." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2ShdslEndpointCurrEntry 20 } hdsl2ShdslEndpointCurrTipRingReversal OBJECT-TYPE SYNTAX INTEGER { normal(1), reversed(2) } MAX-ACCESS read-only Sikes, et al. Standards Track [Page 35] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 STATUS current DESCRIPTION "This object indicates the state of the tip/ring for the wire pair." ::= { hdsl2ShdslEndpointCurrEntry 21 } hdsl2ShdslEndpointCurrActivationState OBJECT-TYPE SYNTAX INTEGER { preActivation(1), -- PreTrain activation(2), -- Training data(3) -- Trained } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the activation or training state of the wire pair." REFERENCE "ITU-T G.991.2, Section 6.2 PMD Activation Sequence" ::= { hdsl2ShdslEndpointCurrEntry 22 } -- Segment Endpoint 15-Minute Interval Status/Performance Group -- hdsl2Shdsl15MinIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2Shdsl15MinIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each HDSL2/SHDSL endpoint performance data collection interval. This table contains live data from equipment. As such, it is NOT persistent." ::= { hdsl2ShdslMibObjects 6 } hdsl2Shdsl15MinIntervalEntry OBJECT-TYPE SYNTAX Hdsl2Shdsl15MinIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2Shdsl15MinIntervalTable." INDEX { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide, hdsl2ShdslEndpointWirePair, hdsl2Shdsl15MinIntervalNumber} ::= { hdsl2Shdsl15MinIntervalTable 1 } Hdsl2Shdsl15MinIntervalEntry ::= SEQUENCE { hdsl2Shdsl15MinIntervalNumber Unsigned32, Sikes, et al. Standards Track [Page 36] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2Shdsl15MinIntervalES PerfIntervalCount, hdsl2Shdsl15MinIntervalSES PerfIntervalCount, hdsl2Shdsl15MinIntervalCRCanomalies PerfIntervalCount, hdsl2Shdsl15MinIntervalLOSWS PerfIntervalCount, hdsl2Shdsl15MinIntervalUAS PerfIntervalCount } hdsl2Shdsl15MinIntervalNumber OBJECT-TYPE SYNTAX Unsigned32(1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number. Interval 1 is the most recent previous interval; interval 96 is 24 hours ago. Intervals 2..96 are optional." ::= { hdsl2Shdsl15MinIntervalEntry 1 } hdsl2Shdsl15MinIntervalES OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) during the interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl15MinIntervalEntry 2 } hdsl2Shdsl15MinIntervalSES OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) during the interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl15MinIntervalEntry 3 } hdsl2Shdsl15MinIntervalCRCanomalies OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "detected CRC Anomalies" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC anomalies during the interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl15MinIntervalEntry 4 } hdsl2Shdsl15MinIntervalLOSWS OBJECT-TYPE Sikes, et al. Standards Track [Page 37] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Sync Word (LOSW) Seconds during the interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl15MinIntervalEntry 5 } hdsl2Shdsl15MinIntervalUAS OBJECT-TYPE SYNTAX PerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) during the interval." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl15MinIntervalEntry 6 } -- Segment Endpoint 1-Day Interval Status/Performance Group -- hdsl2Shdsl1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2Shdsl1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each HDSL2/SHDSL endpoint performance data collection interval. This table contains live data from equipment. As such, it is NOT persistent." ::= { hdsl2ShdslMibObjects 7 } hdsl2Shdsl1DayIntervalEntry OBJECT-TYPE SYNTAX Hdsl2Shdsl1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2Shdsl1DayIntervalTable." INDEX { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide, hdsl2ShdslEndpointWirePair, hdsl2Shdsl1DayIntervalNumber } ::= { hdsl2Shdsl1DayIntervalTable 1 } Hdsl2Shdsl1DayIntervalEntry ::= SEQUENCE { hdsl2Shdsl1DayIntervalNumber Unsigned32, hdsl2Shdsl1DayIntervalMoniSecs Hdsl2ShdslPerfTimeElapsed, Sikes, et al. Standards Track [Page 38] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2Shdsl1DayIntervalES Hdsl2Shdsl1DayIntervalCount, hdsl2Shdsl1DayIntervalSES Hdsl2Shdsl1DayIntervalCount, hdsl2Shdsl1DayIntervalCRCanomalies Hdsl2Shdsl1DayIntervalCount, hdsl2Shdsl1DayIntervalLOSWS Hdsl2Shdsl1DayIntervalCount, hdsl2Shdsl1DayIntervalUAS Hdsl2Shdsl1DayIntervalCount } hdsl2Shdsl1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32(1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "History Data Interval number. Interval 1 is the most recent previous day; interval 30 is 30 days ago. Intervals 2..30 are optional." ::= { hdsl2Shdsl1DayIntervalEntry 1 } hdsl2Shdsl1DayIntervalMoniSecs OBJECT-TYPE SYNTAX Hdsl2ShdslPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::= { hdsl2Shdsl1DayIntervalEntry 2 } hdsl2Shdsl1DayIntervalES OBJECT-TYPE SYNTAX Hdsl2Shdsl1DayIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) during the 1-day interval as measured by hdsl2Shdsl1DayIntervalMoniSecs." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl1DayIntervalEntry 3 } hdsl2Shdsl1DayIntervalSES OBJECT-TYPE SYNTAX Hdsl2Shdsl1DayIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) during the 1-day Sikes, et al. Standards Track [Page 39] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 interval as measured by hdsl2Shdsl1DayIntervalMoniSecs." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl1DayIntervalEntry 4 } hdsl2Shdsl1DayIntervalCRCanomalies OBJECT-TYPE SYNTAX Hdsl2Shdsl1DayIntervalCount UNITS "detected CRC Anomalies" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC anomalies during the 1-day interval as measured by hdsl2Shdsl1DayIntervalMoniSecs." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl1DayIntervalEntry 5 } hdsl2Shdsl1DayIntervalLOSWS OBJECT-TYPE SYNTAX Hdsl2Shdsl1DayIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Sync Word (LOSW) Seconds during the 1-day interval as measured by hdsl2Shdsl1DayIntervalMoniSecs." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl1DayIntervalEntry 6 } hdsl2Shdsl1DayIntervalUAS OBJECT-TYPE SYNTAX Hdsl2Shdsl1DayIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) during the 1-day interval as measured by hdsl2Shdsl1DayIntervalMoniSecs." REFERENCE "HDSL2 Section 7.5.3.7; SHDSL Section 9.5.5.7" ::= { hdsl2Shdsl1DayIntervalEntry 7 } -- Maintenance Group -- hdsl2ShdslEndpointMaintTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslEndpointMaintEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports maintenance operations (e.g., loopbacks) to be performed on HDSL2/SHDSL segment endpoints. This table contains live data from equipment. As such, it is NOT Sikes, et al. Standards Track [Page 40] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 persistent." ::= { hdsl2ShdslMibObjects 8 } hdsl2ShdslEndpointMaintEntry OBJECT-TYPE SYNTAX Hdsl2ShdslEndpointMaintEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2ShdslEndpointMaintTable. Each entry corresponds to a single segment endpoint and is indexed by the ifIndex of the HDSL2/SHDSL line, the UnitId of the associated unit, and the side of the unit." INDEX { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide } ::= { hdsl2ShdslEndpointMaintTable 1 } Hdsl2ShdslEndpointMaintEntry ::= SEQUENCE { hdsl2ShdslMaintLoopbackConfig INTEGER, hdsl2ShdslMaintTipRingReversal INTEGER, hdsl2ShdslMaintPowerBackOff INTEGER, hdsl2ShdslMaintSoftRestart INTEGER } hdsl2ShdslMaintLoopbackConfig OBJECT-TYPE SYNTAX INTEGER { noLoopback(1), normalLoopback(2), specialLoopback(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls configuration of loopbacks for the associated segment endpoint. The status of the loopback is obtained via the hdsl2ShdslEndpointCurrStatus object." ::= { hdsl2ShdslEndpointMaintEntry 1 } hdsl2ShdslMaintTipRingReversal OBJECT-TYPE SYNTAX INTEGER { normal(1), reversed(2) } MAX-ACCESS read-only STATUS current DESCRIPTION Sikes, et al. Standards Track [Page 41] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 "This object indicates the state of the tip/ring pair at the associated segment endpoint." ::= { hdsl2ShdslEndpointMaintEntry 2 } hdsl2ShdslMaintPowerBackOff OBJECT-TYPE SYNTAX INTEGER { default(1), enhanced(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object configures the receiver at the associated segment endpoint to operate in default or enhanced power backoff mode." ::= { hdsl2ShdslEndpointMaintEntry 3 } hdsl2ShdslMaintSoftRestart OBJECT-TYPE SYNTAX INTEGER { ready(1), restart(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object enables the manager to trigger a soft restart of the modem at the associated segment endpoint. The manager may only set this object to the 'restart(2)' value, which initiates a restart. The agent will perform a restart after approximately 5 seconds. Following the 5 second period, the agent will restore the object to the 'ready(1)' state." ::= { hdsl2ShdslEndpointMaintEntry 4 } hdsl2ShdslUnitMaintTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslUnitMaintEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports maintenance operations for units in a HDSL2/SHDSL line. Entries in this table MUST be maintained in a persistent manner." ::= { hdsl2ShdslMibObjects 9 } hdsl2ShdslUnitMaintEntry OBJECT-TYPE SYNTAX Hdsl2ShdslUnitMaintEntry Sikes, et al. Standards Track [Page 42] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the hdsl2ShdslUnitMaintTable. Each entry corresponds to a single unit and is indexed by the ifIndex of the HDSL2/SHDSL line and the UnitId of the associated unit." INDEX { ifIndex, hdsl2ShdslInvIndex } ::= { hdsl2ShdslUnitMaintTable 1 } Hdsl2ShdslUnitMaintEntry ::= SEQUENCE { hdsl2ShdslMaintLoopbackTimeout Integer32, hdsl2ShdslMaintUnitPowerSource INTEGER } hdsl2ShdslMaintLoopbackTimeout OBJECT-TYPE SYNTAX Integer32(0..4095) UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "This object configures the timeout value for loopbacks initiated at segments endpoints contained in the associated unit. A value of 0 disables the timeout." ::= { hdsl2ShdslUnitMaintEntry 1 } hdsl2ShdslMaintUnitPowerSource OBJECT-TYPE SYNTAX INTEGER { local(1), span(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the DC power source being used by the associated unit." ::= { hdsl2ShdslUnitMaintEntry 2 } -- Span Configuration Profile Group -- hdsl2ShdslSpanConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslSpanConfProfileEntry MAX-ACCESS not-accessible STATUS current Sikes, et al. Standards Track [Page 43] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 DESCRIPTION "This table supports definitions of span configuration profiles for SHDSL lines. HDSL2 does not support these configuration options. This table MUST be maintained in a persistent manner." ::= { hdsl2ShdslMibObjects 10 } hdsl2ShdslSpanConfProfileEntry OBJECT-TYPE SYNTAX Hdsl2ShdslSpanConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to a single span configuration profile. Each profile contains a set of span configuration parameters. The configuration parameters in a profile are applied to those lines referencing that profile (see the hdsl2ShdslSpanConfProfile object). Profiles may be created/deleted using the row creation/deletion mechanism via hdsl2ShdslSpanConfProfileRowStatus. If an active entry is referenced in hdsl2ShdslSpanConfProfile, the entry MUST remain active until all references are removed." INDEX { IMPLIED hdsl2ShdslSpanConfProfileName } ::= { hdsl2ShdslSpanConfProfileTable 1 } Hdsl2ShdslSpanConfProfileEntry ::= SEQUENCE { hdsl2ShdslSpanConfProfileName SnmpAdminString, hdsl2ShdslSpanConfWireInterface INTEGER, hdsl2ShdslSpanConfMinLineRate Unsigned32, hdsl2ShdslSpanConfMaxLineRate Unsigned32, hdsl2ShdslSpanConfPSD INTEGER, hdsl2ShdslSpanConfTransmissionMode Hdsl2ShdslTransmissionModeType, hdsl2ShdslSpanConfRemoteEnabled INTEGER, hdsl2ShdslSpanConfPowerFeeding INTEGER, hdsl2ShdslSpanConfCurrCondTargetMarginDown Integer32, hdsl2ShdslSpanConfWorstCaseTargetMarginDown Integer32, hdsl2ShdslSpanConfCurrCondTargetMarginUp Integer32, hdsl2ShdslSpanConfWorstCaseTargetMarginUp Integer32, hdsl2ShdslSpanConfUsedTargetMargins BITS, hdsl2ShdslSpanConfReferenceClock Hdsl2ShdslClockReferenceType, hdsl2ShdslSpanConfLineProbeEnable INTEGER, hdsl2ShdslSpanConfProfileRowStatus RowStatus } hdsl2ShdslSpanConfProfileName OBJECT-TYPE Sikes, et al. Standards Track [Page 44] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is the unique index associated with this profile. Entries in this table are referenced via the object hdsl2ShdslSpanConfProfile in Hdsl2ShdslSpanConfEntry." ::= { hdsl2ShdslSpanConfProfileEntry 1 } hdsl2ShdslSpanConfWireInterface OBJECT-TYPE SYNTAX INTEGER { twoWire(1), fourWire(2), sixWire(3), eightWire(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the two-wire or optional four-wire, six-wire, or eight-wire operation for SHDSL lines." DEFVAL { twoWire } ::= { hdsl2ShdslSpanConfProfileEntry 2 } hdsl2ShdslSpanConfMinLineRate OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the minimum transmission rate for the associated SHDSL Line in bits-per-second (bps) and includes both payload (user data) and any applicable framing overhead. If the minimum line rate equals the maximum line rate (hdsl2ShdslSpanMaxLineRate), the line rate is considered 'fixed'. If the minimum line rate is less than the maximum line rate, the line rate is considered 'rate-adaptive'." DEFVAL { 1552000 } ::= { hdsl2ShdslSpanConfProfileEntry 3 } hdsl2ShdslSpanConfMaxLineRate OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) UNITS "bps" MAX-ACCESS read-create STATUS current DESCRIPTION Sikes, et al. Standards Track [Page 45] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 "This object configures the maximum transmission rate for the associated SHDSL Line in bits-per-second (bps) and includes both payload (user data) and any applicable framing overhead. If the minimum line rate equals the maximum line rate (hdsl2ShdslSpanMaxLineRate), the line rate is considered 'fixed'. If the minimum line rate is less than the maximum line rate, the line rate is considered 'rate-adaptive'." DEFVAL { 1552000 } ::= { hdsl2ShdslSpanConfProfileEntry 4 } hdsl2ShdslSpanConfPSD OBJECT-TYPE SYNTAX INTEGER { symmetric(1), asymmetric(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures use of symmetric/asymmetric PSD (Power Spectral Density) Mask for the associated SHDSL Line. Support for symmetric PSD is mandatory for all supported data rates. Support for asymmetric PSD is optional." DEFVAL { symmetric } ::= { hdsl2ShdslSpanConfProfileEntry 5 } hdsl2ShdslSpanConfTransmissionMode OBJECT-TYPE SYNTAX Hdsl2ShdslTransmissionModeType MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the regional setting for the SHDSL line." DEFVAL { { region1 } } ::= { hdsl2ShdslSpanConfProfileEntry 6 } hdsl2ShdslSpanConfRemoteEnabled OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables/disables support for remote management of the units in an SHDSL line from the STU-R via the EOC." Sikes, et al. Standards Track [Page 46] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 DEFVAL { enabled } ::= { hdsl2ShdslSpanConfProfileEntry 7 } hdsl2ShdslSpanConfPowerFeeding OBJECT-TYPE SYNTAX INTEGER { noPower(1), powerFeed(2), wettingCurrent(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables/disables support for optional power feeding in an SHDSL line." DEFVAL { noPower } ::= { hdsl2ShdslSpanConfProfileEntry 8 } hdsl2ShdslSpanConfCurrCondTargetMarginDown OBJECT-TYPE SYNTAX Integer32(-10..21) UNITS "dB" MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the downstream current condition target SNR margin for an SHDSL line. The SNR margin is the difference between the desired SNR and the actual SNR. Target SNR margin is the desired SNR margin for a unit." DEFVAL { 0 } ::= { hdsl2ShdslSpanConfProfileEntry 9 } hdsl2ShdslSpanConfWorstCaseTargetMarginDown OBJECT-TYPE SYNTAX Integer32(-10..21) UNITS "dB" MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the downstream worst-case target SNR margin for an SHDSL line. The SNR margin is the difference between the desired SNR and the actual SNR. Target SNR margin is the desired SNR margin for a unit." DEFVAL { 0 } ::= { hdsl2ShdslSpanConfProfileEntry 10 } hdsl2ShdslSpanConfCurrCondTargetMarginUp OBJECT-TYPE SYNTAX Integer32(-10..21) UNITS "dB" MAX-ACCESS read-create Sikes, et al. Standards Track [Page 47] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 STATUS current DESCRIPTION "This object specifies the upstream current-condition target SNR margin for an SHDSL line. The SNR margin is the difference between the desired SNR and the actual SNR. Target SNR margin is the desired SNR margin for a unit." DEFVAL { 0 } ::= { hdsl2ShdslSpanConfProfileEntry 11 } hdsl2ShdslSpanConfWorstCaseTargetMarginUp OBJECT-TYPE SYNTAX Integer32(-10..21) UNITS "dB" MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the upstream worst-case target SNR margin for an SHDSL line. The SNR margin is the difference between the desired SNR and the actual SNR. Target SNR margin is the desired SNR margin for a unit." DEFVAL { 0 } ::= { hdsl2ShdslSpanConfProfileEntry 12 } hdsl2ShdslSpanConfUsedTargetMargins OBJECT-TYPE SYNTAX BITS { currCondDown(0), worstCaseDown(1), currCondUp(2), worstCaseUp(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether a target SNR margin is enabled or disabled. This is a bit-map of possible settings. The various bit positions are as follows: currCondDown - current-condition downstream target SNR margin enabled worstCaseDown - worst-case downstream target SNR margin enabled currCondUp - current-condition upstream target SNR margin enabled worstCaseUp - worst-case upstream target SNR margin enabled." Sikes, et al. Standards Track [Page 48] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 DEFVAL { { currCondDown } } ::= { hdsl2ShdslSpanConfProfileEntry 13 } hdsl2ShdslSpanConfReferenceClock OBJECT-TYPE SYNTAX Hdsl2ShdslClockReferenceType MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the clock reference for the STU-C in an SHDSL Line." DEFVAL { localClk } ::= { hdsl2ShdslSpanConfProfileEntry 14 } hdsl2ShdslSpanConfLineProbeEnable OBJECT-TYPE SYNTAX INTEGER { disable(1), enable(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables/disables support for Line Probe of the units in an SHDSL line. When Line Probe is enabled, the system performs Line Probing to find the best possible rate. If Line Probe is disabled, the rate adaptation phase is skipped to shorten set up time." DEFVAL { disable } ::= { hdsl2ShdslSpanConfProfileEntry 15 } hdsl2ShdslSpanConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls creation/deletion of the associated entry in this table per the semantics of RowStatus. If an active entry is referenced in hdsl2ShdslSpanConfProfile, the entry MUST remain active until all references are removed." ::= { hdsl2ShdslSpanConfProfileEntry 16 } -- Segment Endpoint Alarm Configuration Profile group -- hdsl2ShdslEndpointAlarmConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF Hdsl2ShdslEndpointAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current Sikes, et al. Standards Track [Page 49] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 DESCRIPTION "This table supports definitions of alarm configuration profiles for HDSL2/SHDSL segment endpoints. This table MUST be maintained in a persistent manner." ::= { hdsl2ShdslMibObjects 11 } hdsl2ShdslEndpointAlarmConfProfileEntry OBJECT-TYPE SYNTAX Hdsl2ShdslEndpointAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to a single alarm configuration profile. Each profile contains a set of parameters for setting alarm thresholds for various performance attributes monitored at HDSL2/SHDSL segment endpoints. Profiles may be created/deleted using the row creation/deletion mechanism via hdsl2ShdslEndpointAlarmConfProfileRowStatus. If an active entry is referenced in either hdsl2ShdslSpanConfAlarmProfile or hdsl2ShdslEndpointAlarmConfProfile, the entry MUST remain active until all references are removed." INDEX { IMPLIED hdsl2ShdslEndpointAlarmConfProfileName } ::= { hdsl2ShdslEndpointAlarmConfProfileTable 1 } Hdsl2ShdslEndpointAlarmConfProfileEntry ::= SEQUENCE { hdsl2ShdslEndpointAlarmConfProfileName SnmpAdminString, hdsl2ShdslEndpointThreshLoopAttenuation Integer32, hdsl2ShdslEndpointThreshSNRMargin Integer32, hdsl2ShdslEndpointThreshES Hdsl2ShdslPerfIntervalThreshold, hdsl2ShdslEndpointThreshSES Hdsl2ShdslPerfIntervalThreshold, hdsl2ShdslEndpointThreshCRCanomalies Integer32, hdsl2ShdslEndpointThreshLOSWS Hdsl2ShdslPerfIntervalThreshold, hdsl2ShdslEndpointThreshUAS Hdsl2ShdslPerfIntervalThreshold, hdsl2ShdslEndpointAlarmConfProfileRowStatus RowStatus } hdsl2ShdslEndpointAlarmConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is the unique index associated with this profile." ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 1 } Sikes, et al. Standards Track [Page 50] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2ShdslEndpointThreshLoopAttenuation OBJECT-TYPE SYNTAX Integer32(-127..128) UNITS "dB" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the loop attenuation alarm threshold. When the current value of hdsl2ShdslEndpointCurrAtn reaches or exceeds this threshold, an hdsl2ShdslLoopAttenCrossing MAY be generated." DEFVAL { 0 } ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 2 } hdsl2ShdslEndpointThreshSNRMargin OBJECT-TYPE SYNTAX Integer32(-127..128) UNITS "dB" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the SNR margin alarm threshold. When the current value of hdsl2ShdslEndpointCurrSnrMgn reaches or drops below this threshold, a hdsl2ShdslSNRMarginCrossing MAY be generated." DEFVAL { 0 } ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 3 } hdsl2ShdslEndpointThreshES OBJECT-TYPE SYNTAX Hdsl2ShdslPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of Errored Seconds (ES) within any given 15-minute performance data collection interval. If the value of Errored Seconds in a particular 15-minute collection interval reaches/ exceeds this value, an hdsl2ShdslPerfESThresh MAY be generated. At most, one notification will be sent per interval per endpoint." DEFVAL { 0 } ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 4 } hdsl2ShdslEndpointThreshSES OBJECT-TYPE SYNTAX Hdsl2ShdslPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION Sikes, et al. Standards Track [Page 51] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 "This object configures the threshold for the number of Severely Errored Seconds (SES) within any given 15-minute performance data collection interval. If the value of Severely Errored Seconds in a particular 15-minute collection interval reaches/exceeds this value, an hdsl2ShdslPerfSESThresh MAY be generated. At most, one notification will be sent per interval per endpoint." DEFVAL { 0 } ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 5 } hdsl2ShdslEndpointThreshCRCanomalies OBJECT-TYPE SYNTAX Integer32 UNITS "detected CRC Anomalies" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of CRC anomalies within any given 15-minute performance data collection interval. If the value of CRC anomalies in a particular 15-minute collection interval reaches/exceeds this value, an hdsl2ShdslPerfCRCanomaliesThresh MAY be generated. At most, one notification will be sent per interval per endpoint." DEFVAL { 0 } ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 6 } hdsl2ShdslEndpointThreshLOSWS OBJECT-TYPE SYNTAX Hdsl2ShdslPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of Loss of Sync Word (LOSW) Seconds within any given 15-minute performance data collection interval. If the value of LOSW in a particular 15-minute collection interval reaches/exceeds this value, an hdsl2ShdslPerfLOSWSThresh MAY be generated. At most, one notification will be sent per interval per endpoint." DEFVAL { 0 } ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 7 } hdsl2ShdslEndpointThreshUAS OBJECT-TYPE SYNTAX Hdsl2ShdslPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION Sikes, et al. Standards Track [Page 52] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 "This object configures the threshold for the number of Unavailable Seconds (UAS) within any given 15-minute performance data collection interval. If the value of UAS in a particular 15-minute collection interval reaches/exceeds this value, an hdsl2ShdslPerfUASThresh MAY be generated. At most, one notification will be sent per interval per endpoint." DEFVAL { 0 } ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 8 } hdsl2ShdslEndpointAlarmConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls creation/deletion of the associated entry in this table as per the semantics of RowStatus. If an active entry is referenced in either hdsl2ShdslSpanConfAlarmProfile or hdsl2ShdslEndpointAlarmConfProfile, the entry MUST remain active until all references are removed." ::= { hdsl2ShdslEndpointAlarmConfProfileEntry 9 } -- Notifications Group -- hdsl2ShdslNotifications OBJECT IDENTIFIER ::= { hdsl2ShdslMIB 0 } hdsl2ShdslLoopAttenCrossing NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrAtn, hdsl2ShdslEndpointThreshLoopAttenuation } STATUS current DESCRIPTION "This notification indicates that the loop attenuation threshold (as per the hdsl2ShdslEndpointThreshLoopAttenuation value) has been reached/exceeded for the HDSL2/SHDSL segment endpoint." ::= { hdsl2ShdslNotifications 1 } hdsl2ShdslSNRMarginCrossing NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrSnrMgn, hdsl2ShdslEndpointThreshSNRMargin } Sikes, et al. Standards Track [Page 53] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 STATUS current DESCRIPTION "This notification indicates that the SNR margin threshold (as per the hdsl2ShdslEndpointThreshSNRMargin value) has been reached/exceeded for the HDSL2/SHDSL segment endpoint." ::= { hdsl2ShdslNotifications 2 } hdsl2ShdslPerfESThresh NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurr15MinES, hdsl2ShdslEndpointThreshES } STATUS current DESCRIPTION "This notification indicates that the errored seconds threshold (as per the hdsl2ShdslEndpointThreshES value) has been reached/exceeded for the HDSL2/SHDSL segment endpoint." ::= { hdsl2ShdslNotifications 3 } hdsl2ShdslPerfSESThresh NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurr15MinSES, hdsl2ShdslEndpointThreshSES } STATUS current DESCRIPTION "This notification indicates that the severely errored seconds threshold (as per the hdsl2ShdslEndpointThreshSES value) has been reached/exceeded for the HDSL2/SHDSL segment endpoint." ::= { hdsl2ShdslNotifications 4 } hdsl2ShdslPerfCRCanomaliesThresh NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurr15MinCRCanomalies, hdsl2ShdslEndpointThreshCRCanomalies } STATUS current DESCRIPTION "This notification indicates that the CRC anomalies threshold (as per the hdsl2ShdslEndpointThreshCRCanomalies value) has been reached/exceeded for the HDSL2/SHDSL segment endpoint." ::= { hdsl2ShdslNotifications 5 } hdsl2ShdslPerfLOSWSThresh NOTIFICATION-TYPE Sikes, et al. Standards Track [Page 54] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 OBJECTS { hdsl2ShdslEndpointCurr15MinLOSWS, hdsl2ShdslEndpointThreshLOSWS } STATUS current DESCRIPTION "This notification indicates that the LOSW Seconds threshold (as per the hdsl2ShdslEndpointThreshLOSWS value) has been reached/exceeded for the HDSL2/SHDSL segment endpoint." ::= { hdsl2ShdslNotifications 6 } hdsl2ShdslPerfUASThresh NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurr15MinUAS, hdsl2ShdslEndpointThreshUAS } STATUS current DESCRIPTION "This notification indicates that the unavailable seconds threshold (as per the hdsl2ShdslEndpointThreshUAS value) has been reached/exceeded for the HDSL2/SHDSL segment endpoint." ::= { hdsl2ShdslNotifications 7 } hdsl2ShdslSpanInvalidNumRepeaters NOTIFICATION-TYPE OBJECTS { hdsl2ShdslSpanConfNumRepeaters } STATUS current DESCRIPTION "This notification indicates that a mismatch has been detected between the number of repeater/regenerator units configured for an HDSL2/SHDSL line via the hdsl2ShdslSpanConfNumRepeaters object and the actual number of repeater/regenerator units discovered via the EOC." ::= { hdsl2ShdslNotifications 8 } hdsl2ShdslLoopbackFailure NOTIFICATION-TYPE OBJECTS { hdsl2ShdslMaintLoopbackConfig } STATUS current DESCRIPTION "This notification indicates that an endpoint maintenance loopback command failed for an HDSL2/SHDSL segment." Sikes, et al. Standards Track [Page 55] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 ::= { hdsl2ShdslNotifications 9 } hdsl2ShdslpowerBackoff NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrStatus } STATUS current DESCRIPTION "This notification indicates that the bit setting for powerBackoff in the hdsl2ShdslEndpointCurrStatus object for this endpoint has changed." ::= { hdsl2ShdslNotifications 10 } hdsl2ShdsldeviceFault NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrStatus } STATUS current DESCRIPTION "This notification indicates that the bit setting for deviceFault in the hdsl2ShdslEndpointCurrStatus object for this endpoint has changed." ::= { hdsl2ShdslNotifications 11 } hdsl2ShdsldcContinuityFault NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrStatus } STATUS current DESCRIPTION "This notification indicates that the bit setting for dcContinuityFault in the hdsl2ShdslEndpointCurrStatus object for this endpoint has changed." ::= { hdsl2ShdslNotifications 12 } hdsl2ShdslconfigInitFailure NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrStatus } STATUS current DESCRIPTION "This notification indicates that the bit setting for configInitFailure in the hdsl2ShdslEndpointCurrStatus object for this endpoint has changed." Sikes, et al. Standards Track [Page 56] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 ::= { hdsl2ShdslNotifications 13 } hdsl2ShdslprotocolInitFailure NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrStatus } STATUS current DESCRIPTION "This notification indicates that the bit setting for protocolInitFailure in the hdsl2ShdslEndpointCurrStatus object for this endpoint has changed." ::= { hdsl2ShdslNotifications 14 } hdsl2ShdslnoNeighborPresent NOTIFICATION-TYPE OBJECTS { hdsl2ShdslEndpointCurrStatus } STATUS current DESCRIPTION "This notification indicates that the bit setting for noNeighborPresent in the hdsl2ShdslEndpointCurrStatus object for this endpoint has changed." ::= { hdsl2ShdslNotifications 15 } hdsl2ShdslLocalPowerLoss NOTIFICATION-TYPE OBJECTS { hdsl2ShdslInvVendorID } STATUS current DESCRIPTION "This notification indicates impending unit failure due to loss of local power (last gasp)." ::= { hdsl2ShdslNotifications 16 } -- conformance information -- hdsl2ShdslConformance OBJECT IDENTIFIER ::= { hdsl2ShdslMIB 3 } hdsl2ShdslGroups OBJECT IDENTIFIER ::= { hdsl2ShdslConformance 1 } hdsl2ShdslCompliances OBJECT IDENTIFIER ::= { hdsl2ShdslConformance 2 } -- agent compliance statements Sikes, et al. Standards Track [Page 57] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2ShdslLineMibCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMP entities that implement HDSL2 and SHDSL. The version of SHDSL supported in this compliance statement is g.shdsl. **** This compliance statement is deprecated. ****" MODULE MANDATORY-GROUPS { hdsl2ShdslSpanConfGroup, hdsl2ShdslSpanStatusGroup, hdsl2ShdslInventoryGroup, hdsl2ShdslEndpointConfGroup, hdsl2ShdslEndpointCurrGroup, hdsl2Shdsl15MinIntervalGroup, hdsl2Shdsl1DayIntervalGroup, hdsl2ShdslMaintenanceGroup, hdsl2ShdslEndpointAlarmConfGroup, hdsl2ShdslNotificationGroup } GROUP hdsl2ShdslInventoryShdslGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." GROUP hdsl2ShdslSpanShdslStatusGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." GROUP hdsl2ShdslSpanConfProfileGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." OBJECT hdsl2ShdslSpanConfWireInterface SYNTAX INTEGER { twoWire(1), fourWire(2) } DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification defined in RFC 3276." Sikes, et al. Standards Track [Page 58] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 OBJECT hdsl2ShdslStatusMaxAttainableLineRate SYNTAX Unsigned32(0..4112000) DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification defined in RFC 3276." OBJECT hdsl2ShdslStatusActualLineRate SYNTAX Unsigned32(0..4112000) DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification defined in RFC 3276." OBJECT hdsl2ShdslSpanConfMinLineRate SYNTAX Unsigned32(0..4112000) DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification defined in RFC 3276." OBJECT hdsl2ShdslSpanConfMaxLineRate SYNTAX Unsigned32(0..4112000) DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification defined in RFC 3276." ::= { hdsl2ShdslCompliances 1 } hdsl2GshdslbisLineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement HDSL2 and SHDSL. The version of SHDSL supported in this compliance statement is g.shdsl.bis." MODULE MANDATORY-GROUPS { hdsl2ShdslSpanConfGroup, hdsl2ShdslSpanStatusGroup, hdsl2ShdslInventoryGroup, hdsl2ShdslEndpointConfGroup, hdsl2ShdslEndpointCurrGroup, hdsl2Shdsl15MinIntervalGroup, hdsl2Shdsl1DayIntervalGroup, hdsl2ShdslMaintenanceGroup, hdsl2ShdslEndpointAlarmConfGroup, Sikes, et al. Standards Track [Page 59] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2ShdslNotificationGroup } GROUP hdsl2ShdslInventoryShdslGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." GROUP hdsl2ShdslSpanShdslStatusGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." GROUP hdsl2ShdslSpanConfProfileGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." GROUP hdsl2ShdslWirePairGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." GROUP hdsl2ShdslPayloadRateGroup DESCRIPTION "Support for this group is only required for implementations supporting SHDSL lines." ::= { hdsl2ShdslCompliances 2 } -- units of conformance -- hdsl2ShdslSpanConfGroup OBJECT-GROUP OBJECTS { hdsl2ShdslSpanConfNumRepeaters, hdsl2ShdslSpanConfProfile, hdsl2ShdslSpanConfAlarmProfile } STATUS current DESCRIPTION "This group supports objects for configuring span-related parameters for HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 1 } hdsl2ShdslSpanStatusGroup OBJECT-GROUP OBJECTS Sikes, et al. Standards Track [Page 60] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 { hdsl2ShdslStatusNumAvailRepeaters } STATUS current DESCRIPTION "This group supports objects for retrieving span-related status for HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 2 } hdsl2ShdslInventoryShdslGroup OBJECT-GROUP OBJECTS { hdsl2ShdslInvTransmissionModeCapability } STATUS current DESCRIPTION "This group supports objects for retrieving SHDSL-specific inventory information." ::= { hdsl2ShdslGroups 3 } hdsl2ShdslSpanShdslStatusGroup OBJECT-GROUP OBJECTS { hdsl2ShdslStatusMaxAttainableLineRate, hdsl2ShdslStatusActualLineRate, hdsl2ShdslStatusTransmissionModeCurrent } STATUS current DESCRIPTION "This group supports objects for retrieving SHDSL-specific span-related status." ::= { hdsl2ShdslGroups 4 } hdsl2ShdslInventoryGroup OBJECT-GROUP OBJECTS { hdsl2ShdslInvVendorID, hdsl2ShdslInvVendorModelNumber, hdsl2ShdslInvVendorSerialNumber, hdsl2ShdslInvVendorEOCSoftwareVersion, hdsl2ShdslInvStandardVersion, hdsl2ShdslInvVendorListNumber, hdsl2ShdslInvVendorIssueNumber, hdsl2ShdslInvVendorSoftwareVersion, hdsl2ShdslInvEquipmentCode, hdsl2ShdslInvVendorOther } STATUS current Sikes, et al. Standards Track [Page 61] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 DESCRIPTION "This group supports objects that provide unit inventory information about the units in HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 5 } hdsl2ShdslEndpointConfGroup OBJECT-GROUP OBJECTS { hdsl2ShdslEndpointCurrAtn } STATUS current DESCRIPTION "This group supports objects for configuring parameters for segment endpoints in HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 6 } hdsl2ShdslEndpointCurrGroup OBJECT-GROUP OBJECTS { hdsl2ShdslEndpointCurrAtn, hdsl2ShdslEndpointCurrSnrMgn, hdsl2ShdslEndpointCurrStatus, hdsl2ShdslEndpointES, hdsl2ShdslEndpointSES, hdsl2ShdslEndpointCRCanomalies, hdsl2ShdslEndpointLOSWS, hdsl2ShdslEndpointUAS, hdsl2ShdslEndpointCurr15MinTimeElapsed, hdsl2ShdslEndpointCurr15MinES, hdsl2ShdslEndpointCurr15MinSES, hdsl2ShdslEndpointCurr15MinCRCanomalies, hdsl2ShdslEndpointCurr15MinLOSWS, hdsl2ShdslEndpointCurr15MinUAS, hdsl2ShdslEndpointCurr1DayTimeElapsed, hdsl2ShdslEndpointCurr1DayES, hdsl2ShdslEndpointCurr1DaySES, hdsl2ShdslEndpointCurr1DayCRCanomalies, hdsl2ShdslEndpointCurr1DayLOSWS, hdsl2ShdslEndpointCurr1DayUAS } STATUS current DESCRIPTION "This group supports objects that provide current status and performance measurements relating to segment endpoints in HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 7 } hdsl2Shdsl15MinIntervalGroup OBJECT-GROUP Sikes, et al. Standards Track [Page 62] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 OBJECTS { hdsl2Shdsl15MinIntervalES, hdsl2Shdsl15MinIntervalSES, hdsl2Shdsl15MinIntervalCRCanomalies, hdsl2Shdsl15MinIntervalLOSWS, hdsl2Shdsl15MinIntervalUAS } STATUS current DESCRIPTION "This group supports objects that maintain historic performance measurements relating to segment endpoints in HDSL2/SHDSL lines in 15-minute intervals." ::= { hdsl2ShdslGroups 8 } hdsl2Shdsl1DayIntervalGroup OBJECT-GROUP OBJECTS { hdsl2Shdsl1DayIntervalMoniSecs, hdsl2Shdsl1DayIntervalES, hdsl2Shdsl1DayIntervalSES, hdsl2Shdsl1DayIntervalCRCanomalies, hdsl2Shdsl1DayIntervalLOSWS, hdsl2Shdsl1DayIntervalUAS } STATUS current DESCRIPTION "This group supports objects that maintain historic performance measurements relating to segment endpoints in HDSL2/SHDSL lines in 1-day intervals." ::= { hdsl2ShdslGroups 9 } hdsl2ShdslMaintenanceGroup OBJECT-GROUP OBJECTS { hdsl2ShdslMaintLoopbackConfig, hdsl2ShdslMaintTipRingReversal, hdsl2ShdslMaintPowerBackOff, hdsl2ShdslMaintSoftRestart, hdsl2ShdslMaintLoopbackTimeout, hdsl2ShdslMaintUnitPowerSource } STATUS current DESCRIPTION "This group supports objects that provide support for maintenance actions for HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 10 } Sikes, et al. Standards Track [Page 63] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 hdsl2ShdslEndpointAlarmConfGroup OBJECT-GROUP OBJECTS { hdsl2ShdslEndpointAlarmConfProfile, hdsl2ShdslEndpointThreshLoopAttenuation, hdsl2ShdslEndpointThreshSNRMargin, hdsl2ShdslEndpointThreshES, hdsl2ShdslEndpointThreshSES, hdsl2ShdslEndpointThreshCRCanomalies, hdsl2ShdslEndpointThreshLOSWS, hdsl2ShdslEndpointThreshUAS, hdsl2ShdslEndpointAlarmConfProfileRowStatus } STATUS current DESCRIPTION "This group supports objects that allow configuration of alarm thresholds for various performance parameters for HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 11 } hdsl2ShdslNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { hdsl2ShdslLoopAttenCrossing, hdsl2ShdslSNRMarginCrossing, hdsl2ShdslPerfESThresh, hdsl2ShdslPerfSESThresh, hdsl2ShdslPerfCRCanomaliesThresh, hdsl2ShdslPerfLOSWSThresh, hdsl2ShdslPerfUASThresh, hdsl2ShdslSpanInvalidNumRepeaters, hdsl2ShdslLoopbackFailure, hdsl2ShdslpowerBackoff, hdsl2ShdsldeviceFault, hdsl2ShdsldcContinuityFault, hdsl2ShdslconfigInitFailure, hdsl2ShdslprotocolInitFailure, hdsl2ShdslnoNeighborPresent, hdsl2ShdslLocalPowerLoss } STATUS current DESCRIPTION "This group supports notifications of significant conditions associated with HDSL2/SHDSL lines." ::= { hdsl2ShdslGroups 12 } hdsl2ShdslSpanConfProfileGroup OBJECT-GROUP OBJECTS Sikes, et al. Standards Track [Page 64] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 { hdsl2ShdslSpanConfWireInterface, hdsl2ShdslSpanConfMinLineRate, hdsl2ShdslSpanConfMaxLineRate, hdsl2ShdslSpanConfPSD, hdsl2ShdslSpanConfTransmissionMode, hdsl2ShdslSpanConfRemoteEnabled, hdsl2ShdslSpanConfPowerFeeding, hdsl2ShdslSpanConfCurrCondTargetMarginDown, hdsl2ShdslSpanConfWorstCaseTargetMarginDown, hdsl2ShdslSpanConfCurrCondTargetMarginUp, hdsl2ShdslSpanConfWorstCaseTargetMarginUp, hdsl2ShdslSpanConfUsedTargetMargins, hdsl2ShdslSpanConfReferenceClock, hdsl2ShdslSpanConfLineProbeEnable, hdsl2ShdslSpanConfProfileRowStatus } STATUS current DESCRIPTION "This group supports objects that constitute configuration profiles for configuring span-related parameters in SHDSL lines." ::= { hdsl2ShdslGroups 13 } hdsl2ShdslWirePairGroup OBJECT-GROUP OBJECTS { hdsl2ShdslEndpointCurrTipRingReversal, hdsl2ShdslEndpointCurrActivationState } STATUS current DESCRIPTION "This group supports objects that provide the status of SHDSL-specific wire pairs." ::= { hdsl2ShdslGroups 14 } hdsl2ShdslPayloadRateGroup OBJECT-GROUP OBJECTS { hdsl2ShdslStatusMaxAttainablePayloadRate, hdsl2ShdslStatusActualPayloadRate } STATUS current DESCRIPTION "This group supports objects for retrieving payload rates that exclude any framing overhead." ::= { hdsl2ShdslGroups 15 } Sikes, et al. Standards Track [Page 65] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 END 4. Implementation Analysis A management application that supports RFC 3276 could mistakenly flag a unit that responds with a rate or wire pair that exceeds the ranges and/or enumerations specified in RFC 3276. For example, a G.shdsl.bis line with four wire pairs would report statistics for wire pairs that do not exist in RFC 3276. That is, a GET-NEXT request issues with the object identifier: hdsl2ShdslEndpointCurrAtn.1.1.1.2 might return hdsl2ShdslEndpointCurrAtn.1.1.1.3 = 0 with a G.shdsl.bis unit and hdsl2ShdslEndpointCurrSnrMgn.1.1.1.1 = 0 with an HDSL2 unit as these objects are indexed by INDEX { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslendpointSide, hdsl2ShdslEndpointWirePair } A management application intended to manage G.shdsl.bis agents SHOULD be modified to accept this sequence. One should note that this same unmodified management application is still capable of managing G.shdsl.bis agents albeit to the degree of G.SHDSL (non-bis) limitations. That is, it can create and monitor configurations limited to two wire pairs with an upper-rate limit of 4112000 bits/second. 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Sikes, et al. Standards Track [Page 66] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 o hdsl2ShdslSpanConfTable The table consists of the following objects that support SET operations: * hdsl2ShdslSpanConfNumRepeaters * hdsl2ShdslSpanConfProfile * hdsl2ShdslSpanConfAlarmProfile Unauthorized changes to hdsl2ShdslSpanConfNumRepeaters could result in an hdsl2ShdslSpanInvalidNumRepeaters notification. Note the discussion on hdsl2ShdslSpanInvalidNumRepeaters in the Notifications section above. Unauthorized changes to hdsl2ShdslSpanConfProfile could have an adverse operational effect on a span. Reference the hdsl2ShdslSpanConfProfileTable discussion below. Unauthorized changes to hdsl2ShdslSpanConfAlarmProfile could have a contrary effect on notifications. Reference the hdsl2ShdslEndpointAlarmConfProfileTable discussion below. o hdsl2ShdslEndpointConfTable This table contains one object, hdsl2ShdslEndpointAlarmConfProfile, that supports SET operations. Unauthorized changes could have an undesirable notifications. Reference the hdsl2ShdslEndpointAlarmConfProfileTable discussion below. o hdsl2ShdslEndpointMaintTable The table consists of the following objects that support SET operations: * hdsl2ShdslMaintLoopbackConfig * hdsl2ShdslMaintPowerBackoff * hdsl2ShdslMaintSoftRestart Unauthorized changes to hdsl2ShdslMaintLoopbackConfig could prevent end-to-end data transfer due to an activation of a loopback. Unauthorized changes to hdsl2ShdslMaintPowerBackoff could result in an increased in bundle interference. Sikes, et al. Standards Track [Page 67] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Unauthorized changes to hdsl2ShdslMaintSoftRestart could result in a temporary interruption of end-to-end data transfer as the result of the triggering of a soft restart. o hdsl2ShdslUnitMaintTable This table contains one object, hdsl2ShdslMaintLoopbackTimeout, that supports SET operations. An unauthorized change to this object could result in the timeout value for loopbacks being increased, decreased, or disabled. o hdsl2ShdslSpanConfProfileTable The table consists of the following objects that support SET operations: * hdsl2ShdslSpanConfWireInterface * hdsl2ShdslSpanConfMinLineRate * hdsl2ShdslSpanConfMaxLineRate * hdsl2ShdslSpanConfPSD * hdsl2ShdslSpanConfTransmissionMode * hdsl2ShdslSpanConfRemoteEnabled * hdsl2ShdslSpanConfPowerFeeding * hdsl2ShdslSpanConfCurrCondTargetMarginDown * hdsl2ShdslSpanConfWorstCaseTargetMarginDown * hdsl2ShdslSpanConfCurrCondTargetMarginUp * hdsl2ShdslSpanConfWorstCaseTargetMarginUp * hdsl2ShdslSpanConfUsedTargetMargins * hdsl2ShdslSpanConfReferenceClock * hdsl2ShdslSpanConfLineProbeEnable * hdsl2ShdslSpanConfProfileRowStatus Setting any of the objects to an incorrect value could have an adverse operational effect on a span. Unauthorized changes to the hdsl2ShdslSpanConfWireInterface could result in the failure of a span to achieve activation to a state that would permit data flow. For example, setting this object to six-wire or eight-wire operation when one of the units in the span only supports two-wire or four-wire operation would likely prevent an expected end-to-end data transfer capability. Unauthorized changes to hdsl2ShdslSpanConfMinLineRate or hdsl2ShdslSpanConfMaxLineRate could have an adverse effect on performance. The range of allowable line rates could be altered such that the span may not be able to train to a line rate that Sikes, et al. Standards Track [Page 68] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 would permit any end-user data to traverse the span or the span could train to a line rate that is either greater than or less than the line rate that the provider has pledged. Unauthorized changes to hdsl2ShdslSpanConfPSD or hdsl2ShdslSpanConfTransmissionMode could have a detrimental effect on loop reach, performance, or spectral compatibility. Unauthorized changes to hdsl2ShdslSpanConfRemoteEnable could alter the remote management ability of units. Unauthorized changes to hdsl2ShdslSpanConfPowerFeeding could shutdown units that are expected to be fed power remotely. Changing the configuration such that wetting current is not supplied may result in corrosion of electrical contacts. Unauthorized changes to hdsl2ShdslSpanConfCurrCondTargetMarginDown, hdsl2ShdslSpanConfWorstCaseTargetMarginDown, hdsl2ShdslSpanConfCurrCondTargetMarginUp, hdsl2ShdslSpanConfWorstCaseTargetMarginUp, or hdsl2ShdslSpanConfUsedTargetMargins could result in invalid parameters used to determine if a data rate can be supported under current and worst-case noise. Unauthorized changes to hdsl2ShdslSpanConfReferenceClock could result in the selection of a clock source that might either prevent any data from being transferred or impair data transfer. In addition, an increase in CRC anomalies may be experienced. Unauthorized changes to hdsl2ShdslSpanConfLineProbeEnable could have a negative effect on selecting the optimum rate or power level based on current line conditions. Unauthorized changes to row status could result in unwanted profiles being created or brought into service. Also, changes to the row status could result in profiles being inadvertently deleted or taken out of service. o hdsl2ShdslEndpointAlarmConfProfileTable The table consists of the following objects that support SET operations: * hdsl2ShdslEndpointThreshLoopAttenuation * hdsl2ShdslEndpointThreshSNRMargin * hdsl2ShdslEndpointThreshES * hdsl2ShdslEndpointThreshSES Sikes, et al. Standards Track [Page 69] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 * hdsl2ShdslEndpointThreshCRCanomalies * hdsl2ShdslEndpointThreshLOSWS * hdsl2ShdslEndpointThreshUAS * hdsl2ShdslEndpointAlarmConfProfileRowStatus Increasing any of the threshold values could result in a notification being suppressed or deferred. Setting a threshold to 0 could result in a notification being suppressed. Suppressing or deferring a notification could prevent the timely delivery of important diagnostic information. Decreasing any of the threshold values could result in a notification being sent from the network falsely reporting a threshold crossing. Changing a threshold value could also have an impact on the amount of notifications the agent sends. This document adds a paragraph, which was not in RFC 3276 [RFC3276], to the Notifications section that provides general guidance to the rate limiting of notifications. Agent implementations not adhering to the rate- limiting desires could result in notifications being generated at an uncontrolled rate. Unauthorized changes to a threshold value could result in an undesired notification rate. Unauthorized changes to row status could result in unwanted profiles being created or brought into service. Also, changes to the row status could result in profiles being inadvertently deleted or taken out of service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o hdsl2ShdslInventoryTable Access to these objects would allow an intruder to obtain information about which vendor's equipment is in use on the network. Further, such information is considered sensitive in many environments for competitive reasons. * hdsl2ShdslInvVendorID * hdsl2ShdslInvVendorModelNumber * hdsl2ShdslInvVendorSerialNumber * hdsl2ShdslInvVendorEOCSoftwareVersion * hdsl2ShdslInvStandardVersion * hdsl2ShdslInvVendorListNumber Sikes, et al. Standards Track [Page 70] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 * hdsl2ShdslInvVendorIssueNumber * hdsl2ShdslInvVendorSoftwareVersion * hdsl2ShdslInvEquipmentCode * hdsl2ShdslInvVendorOther * hdsl2ShdslInvTransmissionModeCapability SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. Acknowledgements The authors are deeply grateful to the authors of the ADSL LINE MIB (RFC 2662 [RFC2662]), Gregory Bathrick and Faye Ly, as much of the text and structure of this document originate in their documents. The authors are also grateful to the authors of FR MFR MIB (RFC 3020 [RFC3020]), Prayson Pate, Bob Lynch, and Kenneth Rehbehn, as the majority of the Security Considerations section was lifted from their document. The authors also acknowledge the importance of the contributions and suggestions regarding interface indexing structures received from David Horton of CITR. The authors are extremely thankful to Bert Wijnen, Randy Presuhn, and C. M. Heard for their extensive review and the many suggestions they provided. Sikes, et al. Standards Track [Page 71] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Other contributions were received from the following: Matt Beanland (Extel Communications) Philip Bergstresser (Adtran) Steve Blackwell (Centillium) Umberto Bonollo (NEC Australia) John Egan (Metalink BroadBand) Yagal Hachmon (RAD) Mark Johnson (Red Point) Sharon Mantin (Orckit) Moti Morgenstern (ECI) Raymond Murphy (Ericsson) Lee Nipper (Verilink) Randy Presuhn (BMC Software) Katy Sherman (Orckit) Mike Sneed (ECI) Jon Turney (DSL Solutions) Aron Wahl (Memotec) Bert Wijnen (Lucent) Jim Wilson (for Mindspeed) Michael Wrobel (Memotec) 7. References 7.1. Normative References [G.991.2] Blackwell, S., "Single-Pair High-Speed Digital Subscriber Line (SHDSL) Transceivers", ITU-T G.991.2, December 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Sikes, et al. Standards Track [Page 72] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [T1E1.4] American National Standards Institute, "ANSI T1E1.4/2000- 006", February 2000. 7.2. Informative References [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, August 1999. [RFC3020] Pate, P., Lynch, B., and K. Rehbehn, "Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function", RFC 3020, December 2000. [RFC3276] Ray, B. and R. Abbi, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing", RFC 3276, May 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Sikes, et al. Standards Track [Page 73] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Authors' Addresses Clay Sikes Zhone Technologies, Inc. Florida Design Center 8454 126th Ave. N. Largo, FL 33773 US Phone: +1 727 530 8257 Fax: +1 727 532 5698 EMail: csikes@zhone.com Bob Ray PESA Switching Systems, Inc. 330-A Wynn Drive Huntsville, AL 35805 US Phone: +1 256 726 9200 ext. 142 Fax: +1 256 726 9271 EMail: rray@pesa.com Rajesh Abbi Alcatel USA 2301 Sugar Bush Road Raleigh, NC 27612 US Phone: +1 919-850-6194 Fax: +1 919-850-6670 EMail: Rajesh.Abbi@alcatel.com Sikes, et al. Standards Track [Page 74] RFC 4319 HDSL2-SHDSL-LINE-MIB December 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sikes, et al. Standards Track [Page 75] snmp-mibs-downloader-1.1/mibrfcs/rfc4323.txt0000644000000000000000000060124511402176072015566 0ustar Network Working Group M. Patrick Request for Comments: 4323 W. Murwin Category: Standards Track Motorola BCS January 2006 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0. Patrick & Murwin Standards Track [Page 1] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Table of Contents 1. Introduction ....................................................2 1.1. The Internet-Standard Management Framework .................2 1.2. Glossary ...................................................3 2. Overview ........................................................5 2.1. Textual Conventions ........................................5 2.2. MIB Organization ...........................................5 2.2.1. docsIetfQosPktClassTable ............................9 2.2.2. docsIetfQosParamSetTable ...........................10 2.2.2.1. Interoperation with DOCSIS 1.0 ............11 2.2.3. docsIetfQosServiceFlowTable ........................12 2.2.4. docsIetfQosServiceFlowStatsTable ...................13 2.2.5. docsIetfQosUpstreamStatsTable ......................14 2.2.6. docsIetfQosDynamicServiceStatsTable ................14 2.2.7. docsIetfQosServiceFlowLogTable .....................14 2.2.8. docsIetfQosServiceClassTable .......................15 2.2.9. docsIetfQosServiceClassPolicyTable .................15 2.2.10. docsIetfQosPHSTable ...............................16 2.2.11. docsIetfQosCmtsMacToSrvFlowTable ..................16 3. Externally Administered Classification .........................16 4. DOCSIS and IPv4 Type-of-Service (ToS) Field ....................19 5. Definitions ....................................................20 6. Security Considerations ........................................84 7. IANA Considerations ............................................86 8. Acknowledgements ...............................................86 9. Normative References ...........................................86 10. Informative References ........................................87 1. Introduction This memo is a product of the IP over Cable Data Network (IPCDN) working group within the Internet Engineering Task Force (IETF). 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3]. Patrick & Murwin Standards Track [Page 2] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 1.2. Glossary Active QPS Active QoS Parameter Set (QPS). The set of QoS parameters that describe the current level of service provided to a Service Flow (SF). Active SF Active Service Flow. An SF with a non-empty Active QPS. Admitted QPS Admitted QoS Parameter Set. The set of QoS parameters that describe a level of service that the Service Flow is not currently using, but that it is guaranteed to receive upon the SF's request to make the set Active. Admitted SF A Service Flow with a non-empty Admitted QPS. CATV Cable Television. CM Cable Modem. A modem connecting a subscriber's LAN to the Cable Television (CATV) Radio Frequency (RF) network. DOCSIS CMs operate as a MAC layer bridge between the home LAN and the Cable Television (CATV) Radio Frequency (RF) network. CMTS Cable Modem Termination System. The "head-end" device providing connectivity between the RF network and the Internet. Downstream The direction from the head-end towards the subscriber. DSA Dynamic Service Addition. A DOCSIS MAC management message requesting the dynamic creation of a new Service Flow. New SFs are created with a three- message exchange of a DSA-REQ, DSA-RSP, and DSA-ACK. DSC Dynamic Service Change. A DOCSIS MAC management message requesting a change to the attributes of a Service Flow. SFs are changed with a three-message exchange of a DSC-REQ, DSC-RSP, and DSC-ACK. DSD Dynamic Service Delete. A DOCSIS MAC management message requesting the deletion of a Service Flow. SFs are deleted with a two-message exchange of a DSD-REQ and DSD-ACK. Patrick & Murwin Standards Track [Page 3] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Head-end The origination point in most cable systems of the subscriber video signals. It is generally also the location of the CMTS. PHS Payload Header Suppression. A feature of DOCSIS 1.1 and 2.0 in which header bytes that are common in a sequence of packets of a Service Flow are replaced by a one-byte PHSI Index (PHSI) when transmitting the packet on the RF network. primary SF Primary Service Flow. All CMs have a Primary Upstream Service Flow and a Primary Downstream Service Flow. They provide a default path for forwarded packets that are not classified to any other Service Flow. Provisioned QPS A QoS Parameter Set describing an envelope of service within which a Service Flow is authorized to request admission. All existing Service Flows must have a non-empty Provisioned QPS; thus, all SFs are considered to be "Provisioned". RF Radio Frequency. In particular, this abbreviation refers to the radio frequencies for Cable Television (CATV). SCN Service Class Name. A named set of QoS parameters. A Service Flow may or may not be associated with a single named Service Class. A Service Class has as an attribute a QoS Parameter Set that is used as the default set of values for all Service Flows belonging to the Service Class. SID Service ID. A 16-bit unsigned integer assigned by the CMTS for an Upstream Service Flow with a non- empty Active QoS Parameter Set. SF Service Flow. A unidirectional stream of packets between the CM and CMTS. SFs are characterized as upstream or downstream. The SF is the fundamental unit of service provided on a DOCSIS CATV network. SFID Service Flow ID. A 32-bit unsigned integer assigned by the CMTS to each Service Flow. Upstream The direction from a subscriber CM to the head-end CMTS. Patrick & Murwin Standards Track [Page 4] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 2. Overview This MIB module provides a set of objects required for the management of DOCSIS 1.1 and 2.0 compliant Cable Modems (CM) and Cable Modem Termination Systems (CMTS). The specification is derived from the DOCSIS 2.0 Radio Frequency Interface specification [4]. Please note that the referenced DOCSIS specifications only requires Cable Modems to process IPv4 customer traffic. Design choices in this MIB module reflect those requirements. Future versions of the DOCSIS standard are expected to require support for IPv6 as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. 2.1. Textual Conventions The textual convention "DocsIetfQosRfMacIfDirection" is defined to indicate the direction of a packet classifier relative to an interface. It takes the values of either downstream(1) or upstream(2). The textual convention "DocsIetfQosBitRate" corresponds to the bits per second as defined for QoS Parameter Sets in DOCSIS 1.1 and 2.0. This definition includes all bits of the Ethernet MAC frame as transmitted on the RF network, starting with the Destination Address and ending with the Ethernet Frame Check Sequence (FCS). It does NOT includes bits in the DOCSIS MAC header. 2.2. MIB Organization The structure of the IPCDN QoS MIB module (DOCS-IETF-QOS-MIB) is summarized below: docsIetfQosMIB docsIetfQosMIBObjects docsIetfQosPktClassTable docsIetfQosPktClassEntry docsIetfQosPktClassId docsIetfQosPktClassDirection docsIetfQosPktClassPriority docsIetfQosPktClassIpTosLow docsIetfQosPktClassIpTosHigh docsIetfQosPktClassIpTosMask docsIetfQosPktClassIpProtocol docsIetfQosPktClassInetAddressType docsIetfQosPktClassInetSourceAddr docsIetfQosPktClassInetSourceMask Patrick & Murwin Standards Track [Page 5] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosPktClassInetDestAddr docsIetfQosPktClassInetDestMask docsIetfQosPktClassSourcePortStart docsIetfQosPktClassSourcePortEnd docsIetfQosPktClassDestPortStart docsIetfQosPktClassDestPortEnd docsIetfQosPktClassDestMacAddr docsIetfQosPktClassDestMacMask docsIetfQosPktClassSourceMacAddr docsIetfQosPktClassEnetProtocolType docsIetfQosPktClassEnetProtocol docsIetfQosPktClassUserPriLow docsIetfQosPktClassUserPriHigh docsIetfQosPktClassVlanId docsIetfQosPktClassStateActive docsIetfQosPktClassPkts docsIetfQosPktClassBitMap docsIetfQosParamSetTable docsIetfQosParamSetEntry docsIetfQosParamSetServiceClassName docsIetfQosParamSetPriority docsIetfQosParamSetMaxTrafficRate docsIetfQosParamSetMaxTrafficBurst docsIetfQosParamSetMinReservedRate docsIetfQosParamSetMinReservedPkt docsIetfQosParamSetActiveTimeout docsIetfQosParamSetAdmittedTimeout docsIetfQosParamSetMaxConcatBurst docsIetfQosParamSetSchedulingType docsIetfQosParamSetNomPollInterval docsIetfQosParamSetTolPollJitter docsIetfQosParamSetUnsolicitGrantSize docsIetfQosParamSetNomGrantInterval docsIetfQosParamSetTolGrantJitter docsIetfQosParamSetGrantsPerInterval docsIetfQosParamSetTosAndMask docsIetfQosParamSetTosOrMask docsIetfQosParamSetMaxLatency docsIetfQosParamSetType docsIetfQosParamSetRequestPolicyOct docsIetfQosParamSetBitMap docsIetfQosServiceFlowTable docsIetfQosServiceFlowEntry docsIetfQosServiceFlowId docsIetfQosServiceFlowSID docsIetfQosServiceFlowDirection docsIetfQosServiceFlowPrimary docsIetfQosServiceFlowStatsTable Patrick & Murwin Standards Track [Page 6] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosServiceFlowStatsEntry docsIetfQosServiceFlowPkts docsIetfQosServiceFlowOctets docsIetfQosServiceFlowTimeCreated docsIetfQosServiceFlowTimeActive docsIetfQosServiceFlowPHSUnknowns docsIetfQosServiceFlowPolicedDropPkts docsIetfQosServiceFlowPolicedDelayPkts docsIetfQosUpstreamStatsTable docsIetfQosUpstreamStatsEntry docsIetfQosSID docsIetfQosUpstreamFragments docsIetfQosUpstreamFragDiscards docsIetfQosUpstreamConcatBursts docsIetfQosDynamicServiceStatsTable docsIetfQosDynamicServiceStatsEntry docsIetfQosIfDirection docsIetfQosDSAReqs docsIetfQosDSARsps docsIetfQosDSAAcks docsIetfQosDSCReqs docsIetfQosDSCRsps docsIetfQosDSCAcks docsIetfQosDSDReqs docsIetfQosDSDRsps docsIetfQosDynamicAdds docsIetfQosDynamicAddFails docsIetfQosDynamicChanges docsIetfQosDynamicChangeFails docsIetfQosDynamicDeletes docsIetfQosDynamicDeleteFails docsIetfQosDCCReqs docsIetfQosDCCRsps docsIetfQosDCCAcks docsIetfQosDCCs docsIetfQosDCCFails docsIetfQosServiceFlowLogTable docsIetfQosServiceFlowLogEntry docsIetfQosServiceFlowLogIndex docsIetfQosServiceFlowLogIfIndex docsIetfQosServiceFlowLogSFID docsIetfQosServiceFlowLogCmMac docsIetfQosServiceFlowLogPkts docsIetfQosServiceFlowLogOctets docsIetfQosServiceFlowLogTimeDeleted docsIetfQosServiceFlowLogTimeCreated docsIetfQosServiceFlowLogTimeActive docsIetfQosServiceFlowLogDirection Patrick & Murwin Standards Track [Page 7] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosServiceFlowLogPrimary docsIetfQosServiceFlowLogServiceClassName docsIetfQosServiceFlowLogPolicedDropPkts docsIetfQosServiceFlowLogPolicedDelayPkts docsIetfQosServiceFlowLogControl docsIetfQosServiceClassTable docsIetfQosServiceClassEntry docsIetfQosServiceClassName docsIetfQosServiceClassStatus docsIetfQosServiceClassMaxTrafficRate docsIetfQosServiceClassMaxTrafficBurst docsIetfQosServiceClassMinReservedRate docsIetfQosServiceClassMinReservedPkt docsIetfQosServiceClassMaxConcatBurst docsIetfQosServiceClassNomPollInterval docsIetfQosServiceClassTolPollJitter docsIetfQosServiceClassUnsolicitGrantSize docsIetfQosServiceClassNomGrantInterval docsIetfQosServiceClassTolGrantJitter docsIetfQosServiceClassGrantsPerInterval docsIetfQosServiceClassMaxLatency docsIetfQosServiceClassActiveTimeout docsIetfQosServiceClassAdmittedTimeout docsIetfQosServiceClassSchedulingType docsIetfQosServiceClassRequestPolicy docsIetfQosServiceClassTosAndMask docsIetfQosServiceClassTosOrMask docsIetfQosServiceClassDirection docsIetfQosServiceClassStorageType docsIetfQosServiceClassDSCPOverwrite docsIetfQosServiceClassPolicyTable docsIetfQosServiceClassPolicyEntry docsIetfQosServiceClassPolicyIndex docsIetfQosServiceClassPolicyName docsIetfQosServiceClassPolicyRulePriority docsIetfQosServiceClassPolicyStatus docsIetfQosServiceClassPolicyStorageType docsIetfQosPHSTable docsIetfQosPHSEntry docsIetfQosPHSField docsIetfQosPHSMask docsIetfQosPHSSize docsIetfQosPHSVerify docsIetfQosPHSIndex docsIetfQosCmtsMacToSrvFlowTable docsIetfQosCmtsMacToSrvFlowEntry Patrick & Murwin Standards Track [Page 8] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosCmtsCmMac docsIetfQosCmtsServiceFlowId docsIetfQosCmtsIfIndex This MIB module is organized as 11 tables. Most tables are implemented in both the CM and CMTS; the docsIetfQosUpstreamStatsTable and docsIetfQosServiceFlowLogTable are implemented on the CMTS only. 2.2.1. docsIetfQosPktClassTable The docsIetfQosPktClassTable reports the Service Flow Classifiers implemented by the managed device. The table is indexed by the tuple { ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId }. The ifIndex corresponds to a CATV MAC interface. Each CATV MAC interface has a set of Service Flows identified with a docsIetfQosServiceFlowId value that is unique for that interface. Each Service Flow may have a number of packet classifiers that map packets to the flow. The ClassifierId for the classifier is unique only within a particular Service Flow. The semantics of packet classification are provided in [4]. Briefly, the DOCSIS MAC interface calls for matching packets based on values within the 802.2 (LLC), 802.3, IP, and/or UDP/TCP headers. Packets that map more than one classifier are prioritized according to their docsIetfQosPktClassPriority values. The docsIetfQosServiceFlowId (an index object) indicates to which Service Flow the packet is classified. The docsIetfQosPktClassTable is distinct from the docsDevIpFilterTable of [6] in that docsIetfQosPktClassTable is intended only to reflect the state of the Service Flow Classifiers. Service Flow Classifiers may be created only via a CM configuration file or from the Dynamic Service Addition (DSA) messages. For this reason, docsIetfQosPktClassTable is read-only. The docsDevIpFilterTable is intended for external policy-based administration of packet classifiers. See the section "Externally Administered Classification", below. Patrick & Murwin Standards Track [Page 9] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 2.2.2. docsIetfQosParamSetTable The docsIetfQosParamSetTable reports the values of QoS Parameter Set as defined in Section C.2.2 of [4]. In general, a Service Flow is associated with three different QoS Parameter Sets (QPSs): an "active" QPS, an "admitted" QPS, and a "provisioned" or "authorized" QPS. The relationship of these three sets is represented below: +---------------------+ | Provisioned | | | | +---------------+ | | | Admitted | | | | | | | | +---------+ | | | | | Active | | | | | | | | | | | +---------+ | | | | | | | +---------------+ | | | +---------------------+ Figure 1: QoS Parameter Sets The Provisioned QPS describes the maximum service envelope for which the SF is authorized. The Admitted QPS is the set of services for which a Service Flow has requested admission to the DOCSIS RF network, but which is not yet active. The Admitted QPS is used during the two-phase process of IP Telephony/PacketCable Service Flow admission to admit the bandwidth for a bidirectional voice call when the far end is ringing. Because ringing may occur for up to four minutes, this permits the bandwidth to be reserved but not actually consumed during this interval. The Active QPS is the set of services actually being used by the Service Flow. The DOCSIS v1.1 specification [4] defines what it means for a QPS envelope to be "within" another. In general, an inner QPS is considered "within" an outer QPS when all QoS parameters represent demands of equal or fewer resources of the network. In addition to its use as an attribute of a Service Flow, a QPS is also an attribute of a Service Class. A DOCSIS CM configuration file or DSA message may request the creation of a new SF and give only the Service Class Name. The CMTS "expands the macro" of a Service Class Name creation by populating the Provisioned, Admitted, and/or Active QPSs of the Service Flow with the QPS of the Service Class Name. All Patrick & Murwin Standards Track [Page 10] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 the QPSs of a Service Flow must be expansions of the same Service Class, and in this case the SF is said to "belong" to the Service Class. Changing the contents of a Service Class' QPS does not affect the QPS of any Service Flow earlier expanded from that Service Class name. Only the CMTS implements docsIetfQosServiceClassTable. See [4], section 8, for a full description and the theory of operation of DOCSIS 1.1 QoS operation. The docsIetfQosParamSetTable sets are indexed by { ifIndex, docsIetfQosServiceFlowId, docsIetfQosParamSetType}. ifIndex indicates a particular "DOCSIS MAC Domain". docsIetfQosServiceFlowId uniquely identifies a Service Flow on that MAC domain. The docsIetfQosParamSetType indicates whether the row describes an active, admitted, or provisioned QoS Parameter Set. The docsIetfQosParamSetTable is read-only because it indicates the QoS Parameter Set contents as defined by DOCSIS signaling. The docsIetfQosServiceClassTable is read-create to permit managers to define a template of QoS Parameters that can be referenced by DOCSIS modems when creating their QoS Parameter Sets. 2.2.2.1. Interoperation with DOCSIS 1.0 The DOCS-IF-MIB [7] specifies a docsIfQosProfileTable to describe the set of Class Of Service (COS) parameters associated with a COS "profile". The docsIfCmServiceTable, which contains one entry per SID, references this table with a docsIfCmServiceQosProfile number. The DOCSIS 1.1 and 2.0 CM registration process allows a modem to register as operating with DOCSIS 1.0, DOCSIS 1.1, or DOCSIS 2.0 functionality. For ease of expression, we call a modem registering with DOCSIS 1.0 functionality a "DOCSIS 1.0 modem", regardless of the modem's capabilities. A CMTS or CM supporting DOCSIS 1.0, as well as DOCSIS 1.1, and/or DOCSIS 2.0 implements both the tables of [7] and the tables of this MIB module. The interoperation goal is that before modem registration, the DOCSIS 1.0 MIB [7] applies. After registration, either the DOCSIS 1.0 or DOCSIS 1.1/2.0 MIB applies, depending on the mode with which the modem registered. The specific interoperation rules are: 1. When a CM initially ranges, the CM implements a row in the DOCS-IF-MIB docsIfCmServiceTable, and the CMTS implements a row in the DOCS-IF-MIB docsIfCmtsServiceTable corresponding to the default upstream Service ID (SID) used for pre-registration Patrick & Murwin Standards Track [Page 11] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 upstream traffic. For historical compatibility, a row may be created for the docsIfQosProfileTable with default values, which may be referenced by the docsIfCmServiceTable entries. 2. Both a CMTS and CM implementing this MIB MUST NOT implement docsIetfQosParamSetTable or docsIetfQosServiceFlowTable rows until after the CM registers with DOCSIS 1.1 or 2.0 modem operation. 3. When a modem registers with the CMTS as a "DOCSIS 1.1" or "DOCSIS 2.0" modem, any exclusively-referenced row in DOCS-IF- MIB docsIfQosProfileTable representing the modem's upstream QoS profile for pre-registration traffic MUST be removed. Multiply-referenced rows may remain. The docsIfCmServiceQosProfile object in the CM's row of docsIfCmServiceTable MUST be set to zero. The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem continues to exist, and the various statistic objects in that row are incremented. The CMTS should retain a docsIfCmtsServiceTable entry for the DOCSIS 1.1 or DOCSIS 2.0 CM. 4. When a DOCSIS 1.1 or DOCSIS 2.0 modem registers, both the CMTS and CM represent all Service Flows described in the modem configuration file in docsIetfQosParamSetTable and docsIetfQosServiceFlowTable. 5. DOCSIS 1.0 modems do not have entries in the DOCS-IETF-QOS-MIB. 2.2.3. docsIetfQosServiceFlowTable The docsIetfQosServiceFlowTable provides read-only information about all the Service Flows known by the device. It is indexed by the combination of { ifIndex, dosQosServiceFlowId }, where ifIndex corresponds to a CATV MAC interface and docsIetfQosServiceFlowId is the 32-bit integer assigned by the CMTS controlling the MAC domain. A CM typically has only a single CATV MAC interface, whereas a CMTS may have several. See [7] for a description of the ifIndex numbering for DOCSIS devices. The table indicates whether a given SF is in the upstream or downstream direction, and whether it is the "primary" SF in that direction. The primary SF carries traffic that is not otherwise classified to any other SF in that direction. Patrick & Murwin Standards Track [Page 12] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 2.2.4. docsIetfQosServiceFlowStatsTable The docsIetfQosServiceFlowStatsTable provides statistics for all currently existing SFs known by the managed device. It provides basic packet and octet counters, as well as certain other SF-specific stats such as the time at which the flow was created and how many seconds it has been active. The table also provides objects that can be used to fine-tune admission control decisions; namely, the number of packets dropped or delayed due to QoS policing decisions enforced by the managed device. The model of the Service Flows stats table is that there exists a Service Flow Classification function followed by a Service Flow maximum rate Policing function for packets transmitted onto the DOCSIS RF network, as depicted below. +----------+ +------------+ clsfy 1 -----+ | Per-SF | forwarded Pkts | |-----------> | | Maximum |-> for DOCSIS ----->| Classify | clsfy 2 SF1 |--> | Rate | RF Network | Function |-----------> | | Policing | transmission | | -----+ | Function | | | | |----+ | | | | | | | +----------+ Dropped +------------+ | ^ +----+ Delayed Packets intended for transmission onto the DOCSIS RF network (upstream or downstream) are first classified to a Service Flow by matching one of several possible classifiers associated with that Service Flow. The docsIetfQosPktClassPkts count includes the number of packets that match the classifier, regardless of the eventual disposition of the packet. DOCSIS requires that each Service Flow be policed to maintain a maximum rate of transmission. This is performed by either dropping or delaying a packet on that Service Flow. The docsIetfQosServiceFlowPolicedDropPkts object counts the number of Service Flow packets dropped by the policing function. The docsIetfQosServiceFlowPolicedDelayPkts counts the number of packets delayed but still forwarded. The docsIetfQosServiceFlowPkts object counts the total number of packets forwarded beyond the policing function intended for eventual transmission onto the DOCSIS RF network. Although packets may later be dropped by other functions (e.g., a transmit queue overflow on a DOCSIS hardware transmitter), the docsIetfQos MIB per service-flow counters are not affected. Patrick & Murwin Standards Track [Page 13] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 2.2.5. docsIetfQosUpstreamStatsTable This table provides statistics that are measured only at the CMTS in the upstream direction. These include counts of fragmentation headers received, fragments discarded, and concatenation headers received. 2.2.6. docsIetfQosDynamicServiceStatsTable This table provides read-only stats on the operation of the Dynamic Service state machines as specified in section 9.4 of [4]. It provides a set of 14 counters in each direction for a DOCSIS MAC layer interface. That is, each DOCSIS MAC layer interface has one row for downstream stats and a second row for upstream stats. Eight of the counters are DSx packet type counts, one counter for each of the eight DSx packet types. For example, the docsIetfQosDSAReqs object in the upstream row at the CMTS counts the number of DSA-REQ messages received by the CMTS from that interface. The docsIetfQosDSAReqs object in the downstream row at the CMTS counts the number of DSA-REQ messages transmitted by the CMTS on that interface. The remaining six counters per (interface, direction) combination count the number of successful and unsuccessful transactions that were initiated on the interface and direction. For example, the upstream docsIetfQosDynamicAdds on a CMTS is the number of successfully completed CM-initiated dynamic additions, because at the CMTS a CM-initiated DSA starts in the upstream direction. The downstream docsIetfQosDynamicAdds at a CMTS is the number of successful CMTS-initiated DSA transactions. Dynamic service transactions can fail for a number of reasons, as listed in the state machines of section 9.4. Rather than include still more counters for each different failure reason, they are grouped into a single count, e.g., docsIetfQosDynamicAddFails. Again, this object exists in both directions, so that locally originated and remotely originated transaction failures are counted separately. Further troubleshooting of transaction failures will require vendor-specific queries and operation. 2.2.7. docsIetfQosServiceFlowLogTable This table contains a log of the Service Flows that no longer exist in the docsIetfQosServiceFlowTable. It is intended to be periodically polled by traffic monitoring and billing agents. It is implemented only at the CMTS. Patrick & Murwin Standards Track [Page 14] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 It contains a chronological log of SF session statistics, including a total count of packets and octets transferred on the SF. It includes time stamps of the SF creation and deletion time, and of its number of active seconds. The active second count is the count of seconds that the SF had a non-empty Active QoS Parameter Set, i.e., it was eligible to pass data. For unicast SFs, it includes the CM MAC address associated with the flow for billing reference purposes. The maximum number of log records kept by a CMTS and the duration that a log record is maintained in the table are vendor-specific. An explicit control object is provided so that the monitoring application can explicitly delete records it has read. 2.2.8. docsIetfQosServiceClassTable This table defines the Service Class Name and references a QoS Parameter Set for each Service Class defined in a CMTS. It is indexed by the Service Class Name string itself. The table is read- create on a CMTS, and is not implemented in a CM. Each entry of the docsIetfQosServiceClassTable should define a template for flows in a given direction (upstream or downstream). Some parameters of the docsIetfQosServiceClassTable are specific to a particular direction, and so their values are not applicable when used as a template for flows in the other direction. 2.2.9. docsIetfQosServiceClassPolicyTable The docsIetfQosServiceClassPolicyTable can be referenced by the docsDevFilterPolicyTable of [6] in order to have a "policy" that classifies packets to a named Service Class. This is one mechanism by which "external" entities (such as an SNMP manager) may control the classification of a packet for QoS purposes. Entries are indexed by a small-integer docsIetfQosServiceClassPolicyIndex. They provide a Service Class Name and a Rule Priority. A policy referencing a row of this table intends the packet to be forwarded on a Service Flow "belonging" to the named Service Class. See section 3, "Externally Administered Classification", below. This table is implemented on both the CM and CMTS, and is read-create on both. Patrick & Murwin Standards Track [Page 15] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 2.2.10. docsIetfQosPHSTable The Payload Header Suppression (PHS) feature of DOCSIS 1.1 and 2.0 permits packets to replace the unchanging bytes of the Ethernet, IP, and UDP headers with a one-byte index when transmitting on the cable network. This is especially useful for IP Telephony packets, where such suppression can result in almost twice the number of calls supported within the same upstream channel. Each entry of the table corresponds to a PHS Rule as described in section 8.4 of [4]. The rules are identified by their corresponding Service Flow ID and docsIetfQosPktClassId. A PHS rule is associated with exactly one classifier. The table is therefore indexed by the tuple { ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId}. This table is read-only, and MUST be implemented on both the CM and CMTS when PHS is supported. 2.2.11 docsIetfQosCmtsMacToSrvFlowTable The docsIetfQosCmtsMacToSrvFlowTable describes the mapping of CM MAC addresses to the Service Flow IDs that are uniquely identified with that CM. External applications may collect statistics on all packets flowing through a CM by determining the SFID of all of its flows, and then collecting the statistics of packets and bytes for each flow. Downstream multicast Service Flows are not indicated in the docsIetfQosCmtsMacToSrvFlowTable because they are not associated with only one CM. 3. Externally Administered Classification DOCSIS 1.1 and 2.0 provide rich semantics for the classification of packets to Service Flows with the Service Flow Classifier table. Service Flow Classifiers may be created statically in the DOCSIS CM configuration file, or may be created dynamically with Dynamic Service Addition (DSA) and Dynamic Service Change (DSC) DOCSIS MAC messages. Several major issues arose with the concept of externally administered classification; e.g., should an external SNMP manager be permitted to create classification rows? One problem was the coordination of classifier IDs because such an approach would require either separate classifier ID number spaces or objects to coordinate both internal and external classifier ID assignments. A more serious problem, however, was that external creation of SF Classifiers would require "knowledge" of the individual Service Flow ID for Service Flows by external applications. It was strongly felt by the Patrick & Murwin Standards Track [Page 16] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 committee that SFIDs should remain internal DOCSIS objects, and not be transmitted as part of protocol flows, e.g., for IP packet telephony signaling. DOCSIS 1.1 introduced the concept of named Service Classes for ease of administration within a domain of CMs and CMTSs. What was desired was to permit external classification of packets to a Service Class, not to a particular Service Flow. The DOCSIS committee therefore decided to use the already-defined IP Packet Filter Table [6] for the external classification of packets for QoS purposes. The docsDevIpPacketFilterTable defines similar packet matching criteria as does docsIetfQosPktClassTable, but it matches a packet to an arbitrary "policy set" instead of a particular Service Flow. One of the policies in the policy set then selects the Service Class of the SF on which to forward the packet. The docsIetfQosServiceClassPolicyTable of this MIB module defines the Service Class Name to which a packet is classified. The interaction of external and internal packet classification is depicted below. Patrick & Murwin Standards Track [Page 17] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 | | Outbound Pkt V docsDevIpFilterTable------> docsDevFilterPolicyTable | | | V | docsIetfQosServiceClassPolicyTable | | Pkt | ServiceClassName,| | ServiceClassPolicyRulePriority| V V +--------------------------------------------------------+ | | DOCSIS MAC LAYER ENTITY | | | | | Select | | V | any | | docsIetfQosPktClassTable <--------------| SFID Y | | | | in SCN | | | docsIetfQosPktClassPriority, | | | | SFID X | | | V V | | +--------------------------------------------+ | | | Select the SFID associated with the | | | | higher of docsIetfQosPktClassPriority or | | | | docsIetfQosServiceClassPolicyRulePriority | | | +--------------------------------------------+ | | | | | V | | | | | | | | | | ... | | Service Flows | | +----+ +----+ | | SFID X SFID Y | +--------------------------------------------------------+ Figure 2: DOCSIS Packet Classification The processing of an outgoing packet proceeds as follows: 1. The packet is first checked for matches with rows of the docsDevIpFilterTable. If it matches, the matching row provides a docsDevFilterPolicyId integer. 2. The docsDevFilterPolicyId indexes into one (or more) rows of docsDevFilterPolicyTable. Each row provides an arbitrary RowPointer (docsDevFilterPolicyPtr), corresponding to a policy to be applied to the packet. Patrick & Murwin Standards Track [Page 18] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 3. This MIB module defines a docsIetfQosServiceClassPolicyTable whose entries may be pointed to by docsDevFilterPolicyPtr in order to classify packets administratively to a named DOCSIS Service Class. The docsIetfQosServiceClassPolicyEntry provides a Service Class Name (SCN) as docsIetfQosServiceClassPolicyName and a classification rule priority as docsIetfQosServiceClassPolicyRulePriority. These are submitted to the device's DOCSIS MAC Layer entity as a special form of the MAC_DATA.request primitive, as described in Section E.2.1 of [4]. 4. The MAC Layer selects an SFID ("Y") of an active Service Flow belonging to the named class, choosing an SF arbitrarily if there is more than one. 5. The packet is then classified according to the docsIetfQosPktClassTable, which may classify the packet to a different SFID "X". Associated with the classifier is a docsIetfQosPktClassPriority. 6. In the event of a conflict between the SCN-determined SFID and the classified SFID, the greater of docsIetfQosPktClassPriority and docsIetfQosServiceClassPolicyRulePriority determines which SFID is selected to forward the packet. A packet that does not match a docsIetfQosServiceClassPolicyEntry is directly submitted to the DOCSIS MAC layer, where the docsIetfQosPktClassTable selects the SID on which it is to be forwarded. By convention (in [4]), the "internal" docsIetfQosPktClassPriority values should be in the range 64-191, while the "external" priorities may be either in the range 192-255 to override the internal classification or in the range 0-63 to be overridden by internal classification. This classification mechanism applies both upstream from the CM and downstream from the CMTS. 4. DOCSIS and IPv4 Type-of-Service (ToS) Field The DOCSIS-IETF-QOS-MIB MIB module relies on the DOCSIS MAC layer protocols and uses objects that reflect the IPv4 Type-of-Service (ToS) octet as defined in [14]. The applicability of these objects is limited to the DOCSIS access network. The past and current versions of the DOCSIS specifications for which this MIB module is defined do not reflect Differentiated Services [9] on the DOCSIS access network. However, with proper selection of values for these Patrick & Murwin Standards Track [Page 19] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 objects, the network operator can enforce Differentiated Services Per-hop Behaviors (PHBs) on the DOCSIS Access Network, and can configure the modification of the DSCP for certain packet flows as they enter the metro network from the access network. Essentially this makes the DOCSIS access network TOS marking compatible with the wider use of DSCP outside DOCSIS networks. Note that because the entire IPv4 TOS octet may be available for modification via the latter mechanism (due to the current MAC level DOCSIS protocols and CLI interface configuration), it is possible that the DOCSIS network could be configured to modify the Explicit Congestion Notification (ECN) bits [10] of certain packets. This modification of the ECN bits is prevented by the MIB module's design. The MIB module prohibits the modification of the TOS octet (read-only objects: docsIetfQosPktClassIpTosLow, docsIetfQosPktClassIpTosHigh docsIetfQosPktClassIpTosMask, docsIetfQosParamSetTosAndMask, docsIetfQosParamSetTosOrMask) and allows the DSCP field to be modified (read-create object: docsIetfQosServiceClassDSCPOverwrite). 5. Definitions This MIB module refers to the SNMPv2-SMI [1] MIB module, SNMPv2-TC [2] MIB module, SNMPv2-CONF [3] MIB Module, DOCSIS RFI Specification SP-RFIv2.0-I06-040804 [4], INET-ADDRESS-MIB [8] MIB module, IF-MIB [11] MIB module, SNMP-FRAMEWORK-MIB [12] MIB module, and DIFFSERV- DSCP-TC [13] MIB module. DOCS-IETF-QOS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Unsigned32, Counter64, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, MacAddress, RowStatus, TruthValue, TimeStamp, StorageType FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE Patrick & Murwin Standards Track [Page 20] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB DscpOrAny FROM DIFFSERV-DSCP-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB; docsIetfQosMIB MODULE-IDENTITY LAST-UPDATED "200601230000Z" -- January 23, 2006 ORGANIZATION "IETF IP over Cable Data Network (IPCDN) Working Group" CONTACT-INFO " Co-Author: Michael Patrick Postal: Motorola BCS 111 Locke Drive Marlborough, MA 01752-7214 U.S.A. Phone: +1 508 786 7563 E-mail: michael.patrick@motorola.com Co-Author: William Murwin Postal: Motorola BCS 111 Locke Drive Marlborough, MA 01752-7214 U.S.A. Phone: +1 508 786 7594 E-mail: w.murwin@motorola.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, Richard_Woundy@cable.comcast.com Jean-Francois Mule, jfm@cablelabs.com" DESCRIPTION "This is the management information for Quality Of Service (QOS) for DOCSIS 1.1 and 2.0. Patrick & Murwin Standards Track [Page 21] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4323; see the RFC itself for full legal notices." REVISION "200601230000Z" -- January 23, 2006 DESCRIPTION "Initial version, published as RFC 4323." ::= { mib-2 127 } -- -- Placeholder for notifications/traps. -- docsIetfQosNotifications OBJECT IDENTIFIER ::= { docsIetfQosMIB 0 } docsIetfQosMIBObjects OBJECT IDENTIFIER ::= { docsIetfQosMIB 1 } -- Textual Conventions DocsIetfQosRfMacIfDirection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates a direction on an RF MAC interface. The value downstream(1) is from Cable Modem Termination System to Cable Modem. The value upstream(2) is from Cable Modem to Cable Modem Termination System." SYNTAX INTEGER { downstream(1), upstream(2) } DocsIetfQosBitRate ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The rate of traffic in unit of bits per second. Used to specify traffic rate for QOS." SYNTAX Unsigned32 DocsIetfQosSchedulingType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The scheduling service provided by a CMTS for an upstream Service Flow. If the parameter is omitted from an upstream QOS Parameter Set, this object takes the value of bestEffort (2). This parameter must be reported as undefined (1) for downstream QOS Parameter Sets." SYNTAX INTEGER { undefined (1), Patrick & Murwin Standards Track [Page 22] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 bestEffort (2), nonRealTimePollingService(3), realTimePollingService(4), unsolictedGrantServiceWithAD(5), unsolictedGrantService(6) } ----------------------------------------------------------------------- -- -- Packet Classifier Table -- docsIetfQosPktClassTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosPktClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the packet classification configured on the CM or CMTS. The model is that a packet either received as input from an interface or transmitted for output on an interface may be compared against an ordered list of rules pertaining to the packet contents. Each rule is a row of this table. A matching rule provides a Service Flow ID to which the packet is classified. All rules need to match for a packet to match a classifier. The objects in this row correspond to a set of Classifier Encoding parameters in a DOCSIS MAC management message. The docsIetfQosPktClassBitMap indicates which particular parameters were present in the classifier as signaled in the DOCSIS message. If the referenced parameter was not present in the signaled DOCSIS 1.1 and 2.0 Classifier, the corresponding object in this row reports a value as specified in the DESCRIPTION section." ::= { docsIetfQosMIBObjects 1 } docsIetfQosPktClassEntry OBJECT-TYPE SYNTAX DocsIetfQosPktClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table provides a single packet classifier rule. The index ifIndex is an ifType of docsCableMaclayer(127)." INDEX { Patrick & Murwin Standards Track [Page 23] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId } ::= { docsIetfQosPktClassTable 1 } DocsIetfQosPktClassEntry ::= SEQUENCE { docsIetfQosPktClassId Unsigned32, docsIetfQosPktClassDirection DocsIetfQosRfMacIfDirection, docsIetfQosPktClassPriority Integer32, docsIetfQosPktClassIpTosLow OCTET STRING, docsIetfQosPktClassIpTosHigh OCTET STRING, docsIetfQosPktClassIpTosMask OCTET STRING, docsIetfQosPktClassIpProtocol Integer32, docsIetfQosPktClassInetAddressType InetAddressType, docsIetfQosPktClassInetSourceAddr InetAddress, docsIetfQosPktClassInetSourceMask InetAddress, docsIetfQosPktClassInetDestAddr InetAddress, docsIetfQosPktClassInetDestMask InetAddress, docsIetfQosPktClassSourcePortStart InetPortNumber, docsIetfQosPktClassSourcePortEnd InetPortNumber, docsIetfQosPktClassDestPortStart InetPortNumber, docsIetfQosPktClassDestPortEnd InetPortNumber, docsIetfQosPktClassDestMacAddr MacAddress, docsIetfQosPktClassDestMacMask MacAddress, docsIetfQosPktClassSourceMacAddr MacAddress, docsIetfQosPktClassEnetProtocolType INTEGER, docsIetfQosPktClassEnetProtocol Integer32, docsIetfQosPktClassUserPriLow Integer32, docsIetfQosPktClassUserPriHigh Integer32, docsIetfQosPktClassVlanId Integer32, docsIetfQosPktClassStateActive TruthValue, docsIetfQosPktClassPkts Counter64, docsIetfQosPktClassBitMap BITS } docsIetfQosPktClassId OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index assigned to packet classifier entry by the CMTS, which is unique per Service Flow." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.2" ::= { docsIetfQosPktClassEntry 1 } docsIetfQosPktClassDirection OBJECT-TYPE Patrick & Murwin Standards Track [Page 24] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 SYNTAX DocsIetfQosRfMacIfDirection MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the direction to which the classifier is applied." ::= { docsIetfQosPktClassEntry 2 } docsIetfQosPktClassPriority OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The value specifies the order of evaluation of the classifiers. The higher the value, the higher the priority. The value of 0 is used as default in provisioned Service Flows Classifiers. The default value of 64 is used for dynamic Service Flow Classifiers. If the referenced parameter is not present in a classifier, this object reports the default value as defined above." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.5" ::= { docsIetfQosPktClassEntry 3 } docsIetfQosPktClassIpTosLow OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The low value of a range of TOS byte values. If the referenced parameter is not present in a classifier, this object reports the value of 0. The IP TOS octet, as originally defined in RFC 791, has been superseded by the 6-bit Differentiated Services Field (DSField, RFC 3260) and the 2-bit Explicit Congestion Notification Field (ECN field, RFC 3168). This object is defined as an 8-bit octet as per the DOCSIS Specification for packet classification." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.1" ::= { docsIetfQosPktClassEntry 4 } docsIetfQosPktClassIpTosHigh OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only Patrick & Murwin Standards Track [Page 25] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 STATUS current DESCRIPTION "The 8-bit high value of a range of TOS byte values. If the referenced parameter is not present in a classifier, this object reports the value of 0. The IP TOS octet as originally defined in RFC 791 has been superseded by the 6-bit Differentiated Services Field (DSField, RFC 3260) and the 2-bit Explicit Congestion Notification Field (ECN field, RFC 3168). This object is defined as an 8-bit octet as defined by the DOCSIS Specification for packet classification." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.1" ::= { docsIetfQosPktClassEntry 5 } docsIetfQosPktClassIpTosMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The mask value is bitwise ANDed with TOS byte in an IP packet, and this value is used for range checking of TosLow and TosHigh. If the referenced parameter is not present in a classifier, this object reports the value of 0. The IP TOS octet as originally defined in RFC 791 has been superseded by the 6-bit Differentiated Services Field (DSField, RFC 3260) and the 2-bit Explicit Congestion Notification Field (ECN field, RFC 3168). This object is defined as an 8-bit octet per the DOCSIS Specification for packet classification." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.1" ::= { docsIetfQosPktClassEntry 6 } docsIetfQosPktClassIpProtocol OBJECT-TYPE SYNTAX Integer32 (0..258) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the value of the IP Protocol field required for IP packets to match this rule. Patrick & Murwin Standards Track [Page 26] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 The value 256 matches traffic with any IP Protocol value. The value 257 by convention matches both TCP and UDP. If the referenced parameter is not present in a classifier, this object reports the value of 258." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.2" ::= { docsIetfQosPktClassEntry 7 } docsIetfQosPktClassInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the Internet address for docsIetfQosPktClassInetSourceAddr, docsIetfQosPktClassInetSourceMask, docsIetfQosPktClassInetDestAddr, and docsIetfQosPktClassInetDestMask. If the referenced parameter is not present in a classifier, this object reports the value of ipv4(1)." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.3" ::= { docsIetfQosPktClassEntry 8 } docsIetfQosPktClassInetSourceAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the value of the IP Source Address required for packets to match this rule. An IP packet matches the rule when the packet IP Source Address bitwise ANDed with the docsIetfQosPktClassInetSourceMask value equals the docsIetfQosPktClassInetSourceAddr value. The address type of this object is specified by docsIetfQosPktClassInetAddressType. If the referenced parameter is not present in a classifier, this object reports the value of '00000000'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.3" ::= { docsIetfQosPktClassEntry 9 } Patrick & Murwin Standards Track [Page 27] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosPktClassInetSourceMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies which bits of a packet's IP Source Address are compared to match this rule. An IP packet matches the rule when the packet source address bitwise ANDed with the docsIetfQosPktClassInetSourceMask value equals the docsIetfQosIpPktClassInetSourceAddr value. The address type of this object is specified by docsIetfQosPktClassInetAddressType. If the referenced parameter is not present in a classifier, this object reports the value of 'FFFFFFFF'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.4" ::= { docsIetfQosPktClassEntry 10 } docsIetfQosPktClassInetDestAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the value of the IP Destination Address required for packets to match this rule. An IP packet matches the rule when the packet IP Destination Address bitwise ANDed with the docsIetfQosPktClassInetDestMask value equals the docsIetfQosPktClassInetDestAddr value. The address type of this object is specified by docsIetfQosPktClassInetAddressType. If the referenced parameter is not present in a classifier, this object reports the value of '00000000'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.5" ::= { docsIetfQosPktClassEntry 11 } docsIetfQosPktClassInetDestMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current Patrick & Murwin Standards Track [Page 28] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 DESCRIPTION "This object specifies which bits of a packet's IP Destination Address are compared to match this rule. An IP packet matches the rule when the packet destination address bitwise ANDed with the docsIetfQosPktClassInetDestMask value equals the docsIetfQosIpPktClassInetDestAddr value. The address type of this object is specified by docsIetfQosPktClassInetAddressType. If the referenced parameter is not present in a classifier, this object reports the value of 'FFFFFFFF'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.6" ::= { docsIetfQosPktClassEntry 12 } docsIetfQosPktClassSourcePortStart OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the low-end inclusive range of TCP/UDP source port numbers to which a packet is compared. This object is irrelevant for non-TCP/UDP IP packets. If the referenced parameter is not present in a classifier, this object reports the value of 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.7" ::= { docsIetfQosPktClassEntry 13 } docsIetfQosPktClassSourcePortEnd OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the high-end inclusive range of TCP/UDP source port numbers to which a packet is compared. This object is irrelevant for non-TCP/UDP IP packets. If the referenced parameter is not present in a classifier, this object reports the value of 65535." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.8" ::= { docsIetfQosPktClassEntry 14 } Patrick & Murwin Standards Track [Page 29] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosPktClassDestPortStart OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the low-end inclusive range of TCP/UDP destination port numbers to which a packet is compared. If the referenced parameter is not present in a classifier, this object reports the value of 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.9" ::= { docsIetfQosPktClassEntry 15 } docsIetfQosPktClassDestPortEnd OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the high-end inclusive range of TCP/UDP destination port numbers to which a packet is compared. If the referenced parameter is not present in a classifier, this object reports the value of 65535." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.10" ::= { docsIetfQosPktClassEntry 16 } docsIetfQosPktClassDestMacAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An Ethernet packet matches an entry when its destination MAC address bitwise ANDed with docsIetfQosPktClassDestMacMask equals the value of docsIetfQosPktClassDestMacAddr. If the referenced parameter is not present in a classifier, this object reports the value of '000000000000'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.1" ::= { docsIetfQosPktClassEntry 17 } docsIetfQosPktClassDestMacMask OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current Patrick & Murwin Standards Track [Page 30] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 DESCRIPTION "An Ethernet packet matches an entry when its destination MAC address bitwise ANDed with docsIetfQosPktClassDestMacMask equals the value of docsIetfQosPktClassDestMacAddr. If the referenced parameter is not present in a classifier, this object reports the value of '000000000000'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.1" ::= { docsIetfQosPktClassEntry 18 } docsIetfQosPktClassSourceMacAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An Ethernet packet matches this entry when its source MAC address equals the value of this object. If the referenced parameter is not present in a classifier, this object reports the value of 'FFFFFFFFFFFF'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.2" ::= { docsIetfQosPktClassEntry 19 } docsIetfQosPktClassEnetProtocolType OBJECT-TYPE SYNTAX INTEGER { none(0), ethertype(1), dsap(2), mac(3), all(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the format of the layer 3 protocol ID in the Ethernet packet. A value of none(0) means that the rule does not use the layer 3 protocol type as a matching criteria. A value of ethertype(1) means that the rule applies only to frames that contain an EtherType value. Ethertype values are contained in packets using the Dec-Intel-Xerox (DIX) encapsulation or the RFC1042 Sub-Network Access Protocol (SNAP) encapsulation formats. A value of dsap(2) means that the rule applies Patrick & Murwin Standards Track [Page 31] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 only to frames using the IEEE802.3 encapsulation format with a Destination Service Access Point (DSAP) other than 0xAA (which is reserved for SNAP). A value of mac(3) means that the rule applies only to MAC management messages for MAC management messages. A value of all(4) means that the rule matches all Ethernet packets. If the Ethernet frame contains an 802.1P/Q Tag header (i.e., EtherType 0x8100), this object applies to the embedded EtherType field within the 802.1P/Q header. If the referenced parameter is not present in a classifier, this object reports the value of 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.3" ::= { docsIetfQosPktClassEntry 20 } docsIetfQosPktClassEnetProtocol OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "If docsIetfQosEthPktClassProtocolType is none(0), this object is ignored when considering whether a packet matches the current rule. If dosQosPktClassEnetProtocolType is ethertype(1), this object gives the 16-bit value of the EtherType that the packet must match in order to match the rule. If docsIetfQosPktClassEnetProtocolType is dsap(2), the lower 8 bits of this object's value must match the DSAP byte of the packet in order to match the rule. If docsIetfQosPktClassEnetProtocolType is mac(3), the lower 8 bits of this object's value represent a lower bound (inclusive) of MAC management message type codes matched, and the upper 8 bits represent the upper bound (inclusive) of matched MAC message type codes. Certain message type codes are excluded from matching, as specified in the reference. Patrick & Murwin Standards Track [Page 32] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 If the Ethernet frame contains an 802.1P/Q Tag header (i.e., EtherType 0x8100), this object applies to the embedded EtherType field within the 802.1P/Q header. If the referenced parameter is not present in the classifier, the value of this object is reported as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.3" ::= { docsIetfQosPktClassEntry 21 } docsIetfQosPktClassUserPriLow OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header (indicated with EtherType 0x8100). Such frames include a 16-bit Tag that contains a 3-bit Priority field and a 12-bit VLAN number. Tagged Ethernet packets must have a 3-bit Priority field within the range of docsIetfQosPktClassPriLow to docsIetfQosPktClassPriHigh in order to match this rule. If the referenced parameter is not present in the classifier, the value of this object is reported as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.7.1" ::= { docsIetfQosPktClassEntry 22 } docsIetfQosPktClassUserPriHigh OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Qtag header (indicated with EtherType 0x8100). Such frames include a 16-bit Tag that contains a 3-bit Priority field and a 12-bit VLAN number. Tagged Ethernet packets must have a 3-bit Priority field within the range of docsIetfQosPktClassPriLow to docsIetfQosPktClassPriHigh in order to match this rule. Patrick & Murwin Standards Track [Page 33] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 If the referenced parameter is not present in the classifier, the value of this object is reported as 7." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.7.1" ::= { docsIetfQosPktClassEntry 23 } docsIetfQosPktClassVlanId OBJECT-TYPE SYNTAX Integer32 (0 | 1..4094) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames using the 802.1P/Q tag header. Tagged packets must have a VLAN Identifier that matches the value in order to match the rule. If the referenced parameter is not present in the classifier, the value of this object is reported as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.7.2" ::= { docsIetfQosPktClassEntry 24 } docsIetfQosPktClassStateActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not the classifier is enabled to classify packets to a Service Flow. If the referenced parameter is not present in the classifier, the value of this object is reported as true(1)." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.6" ::= { docsIetfQosPktClassEntry 25 } docsIetfQosPktClassPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of packets that have been classified using this entry. This includes all packets delivered to a Service Flow maximum rate policing function, whether or not that function drops the packets. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." Patrick & Murwin Standards Track [Page 34] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 ::= { docsIetfQosPktClassEntry 26 } docsIetfQosPktClassBitMap OBJECT-TYPE SYNTAX BITS { -- Reference SP-RFIv2.0-I06-040804 rulePriority(0), -- Appendix C.2.1.3.4 activationState(1), -- Appendix C.2.1.3.6 ipTos(2), -- Appendix C.2.1.5.1 ipProtocol(3), -- Appendix C.2.1.5.2 ipSourceAddr(4), -- Appendix C.2.1.5.3 ipSourceMask(5), -- Appendix C.2.1.5.4 ipDestAddr(6), -- Appendix C.2.1.5.5 ipDestMask(7), -- Appendix C.2.1.5.6 sourcePortStart(8), -- Appendix C.2.1.5.7 sourcePortEnd(9), -- Appendix C.2.1.5.8 destPortStart(10), -- Appendix C.2.1.5.9 destPortEnd(11), -- Appendix C.2.1.5.10 destMac(12), -- Appendix C.2.1.6.1 sourceMac(13), -- Appendix C.2.1.6.2 ethertype(14), -- Appendix C.2.1.6.3 userPri(15), -- Appendix C.2.1.7.1 vlanId(16) -- Appendix C.2.1.7.2 } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates which parameter encodings were actually present in the DOCSIS packet classifier encoding signaled in the DOCSIS message that created or modified the classifier. Note that Dynamic Service Change messages have replace semantics, so that all non-default parameters must be present whether the classifier is being created or changed. A bit of this object is set to 1 if the parameter indicated by the comment was present in the classifier encoding, and to 0 otherwise. Note that BITS are encoded most significant bit first, so that if, for example, bits 6 and 7 are set, this object is encoded as the octet string '030000'H." ::= { docsIetfQosPktClassEntry 27 } -- -- QOS Parameter Set Table -- Patrick & Murwin Standards Track [Page 35] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosParamSetTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosParamSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of DOCSIS 1.1 and 2.0 QOS parameters defined in a managed device. The ifIndex index specifies a DOCSIS MAC Domain. The docsIetfQosServiceFlowId index specifies a particular Service Flow. The docsIetfQosParamSetType index indicates whether the active, admitted, or provisioned QOS Parameter Set is being described by the row. Only the QOS Parameter Sets of DOCSIS 1.1 and 2.0 Service Flows are represented in this table. DOCSIS 1.0 QOS service profiles are not represented in this table. Each row corresponds to a DOCSIS QOS Parameter Set as signaled via DOCSIS MAC management messages. Each object in the row corresponds to one or part of one DOCSIS 1.1 Service Flow Encoding. The docsIetfQosParamSetBitMap object in the row indicates which particular parameters were signaled in the original registration or dynamic service request message that created the QOS Parameter Set. In many cases, even if a QOS Parameter Set parameter was not signaled, the DOCSIS specification calls for a default value to be used. That default value is reported as the value of the corresponding object in this row. Many objects are not applicable, depending on the Service Flow direction or upstream scheduling type. The object value reported in this case is specified in the DESCRIPTION clause." ::= { docsIetfQosMIBObjects 2 } docsIetfQosParamSetEntry OBJECT-TYPE SYNTAX DocsIetfQosParamSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique set of QOS parameters." INDEX { ifIndex, docsIetfQosServiceFlowId, docsIetfQosParamSetType Patrick & Murwin Standards Track [Page 36] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 } ::= { docsIetfQosParamSetTable 1 } DocsIetfQosParamSetEntry ::= SEQUENCE { docsIetfQosParamSetServiceClassName SnmpAdminString, docsIetfQosParamSetPriority Integer32, docsIetfQosParamSetMaxTrafficRate DocsIetfQosBitRate, docsIetfQosParamSetMaxTrafficBurst Unsigned32, docsIetfQosParamSetMinReservedRate DocsIetfQosBitRate, docsIetfQosParamSetMinReservedPkt Integer32, docsIetfQosParamSetActiveTimeout Integer32, docsIetfQosParamSetAdmittedTimeout Integer32, docsIetfQosParamSetMaxConcatBurst Integer32, docsIetfQosParamSetSchedulingType DocsIetfQosSchedulingType, docsIetfQosParamSetNomPollInterval Unsigned32, docsIetfQosParamSetTolPollJitter Unsigned32, docsIetfQosParamSetUnsolicitGrantSize Integer32, docsIetfQosParamSetNomGrantInterval Unsigned32, docsIetfQosParamSetTolGrantJitter Unsigned32, docsIetfQosParamSetGrantsPerInterval Integer32, docsIetfQosParamSetTosAndMask OCTET STRING, docsIetfQosParamSetTosOrMask OCTET STRING, docsIetfQosParamSetMaxLatency Unsigned32, docsIetfQosParamSetType INTEGER, docsIetfQosParamSetRequestPolicyOct OCTET STRING, docsIetfQosParamSetBitMap BITS } docsIetfQosParamSetServiceClassName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Refers to the Service Class Name from which the parameter set values were derived. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is a zero-length string." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.4" ::= { docsIetfQosParamSetEntry 1 } docsIetfQosParamSetPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "The relative priority of a Service Flow. Higher numbers indicate higher priority. This priority should only be used to differentiate Patrick & Murwin Standards Track [Page 37] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Service Flow from identical parameter sets. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 0. If the parameter is not applicable, the reported value is 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.1" ::= { docsIetfQosParamSetEntry 2 } docsIetfQosParamSetMaxTrafficRate OBJECT-TYPE SYNTAX DocsIetfQosBitRate MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum sustained traffic rate allowed for this Service Flow in bits/sec. Must count all MAC frame data PDU from the bytes following the MAC header HCS to the end of the CRC. The number of bytes forwarded is limited during any time interval. The value 0 means no maximum traffic rate is enforced. This object applies to both upstream and downstream Service Flows. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 0. If the parameter is not applicable, it is reported as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.2" ::= { docsIetfQosParamSetEntry 3 } docsIetfQosParamSetMaxTrafficBurst OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the token bucket size in bytes for this parameter set. The value is calculated from the byte following the MAC header HCS to the end of the CRC. This object is applied in conjunction with docsIetfQosParamSetMaxTrafficRate to calculate maximum sustained traffic rate. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort (2), nonRealTimePollingService(3), and realTimePollingService(4) is 3044. If this parameter is not applicable, it is reported as 0. Patrick & Murwin Standards Track [Page 38] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 " REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.3" ::= { docsIetfQosParamSetEntry 4 } docsIetfQosParamSetMinReservedRate OBJECT-TYPE SYNTAX DocsIetfQosBitRate MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the guaranteed minimum rate in bits/sec for this parameter set. The value is calculated from the byte following the MAC header HCS to the end of the CRC. The default value of 0 means that no bandwidth is reserved. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 0. If the parameter is not applicable, it is reported as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.4" ::= { docsIetfQosParamSetEntry 5 } docsIetfQosParamSetMinReservedPkt OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies an assumed minimum packet size in bytes for which the docsIetfQosParamSetMinReservedRate will be provided. The value is calculated from the byte following the MAC header HCS to the end of the CRC. If the referenced parameter is omitted from a DOCSIS QOS parameter set, the default value is CMTS implementation dependent. In this case, the CMTS reports the default value it is using, and the CM reports a value of 0. If the referenced parameter is not applicable to the direction or scheduling type of the Service Flow, both CMTS and CM report this object's value as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.5" ::= { docsIetfQosParamSetEntry 6 } docsIetfQosParamSetActiveTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current Patrick & Murwin Standards Track [Page 39] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 DESCRIPTION "Specifies the maximum duration in seconds that resources remain unused on an active service flow before CMTS signals that both active and admitted parameters set are null. The default value of 0 signifies an infinite amount of time. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.6" ::= { docsIetfQosParamSetEntry 7 } docsIetfQosParamSetAdmittedTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum duration in seconds that resources remain in admitted state before resources must be released. The value of 0 signifies an infinite amount of time. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 200. " REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.7" DEFVAL { 200 } ::= { docsIetfQosParamSetEntry 8 } docsIetfQosParamSetMaxConcatBurst OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum concatenated burst in bytes that an upstream Service Flow is allowed. The value is calculated from the FC byte of the Concatenation MAC Header to the last CRC byte in of the last concatenated MAC frame, inclusive. The value of 0 specifies no maximum burst. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort(2), nonRealTimePollingService(3), and Patrick & Murwin Standards Track [Page 40] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 realTimePollingService(4) is 1522. If the parameter is not applicable, this object's value is reported as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.1" ::= { docsIetfQosParamSetEntry 9 } docsIetfQosParamSetSchedulingType OBJECT-TYPE SYNTAX DocsIetfQosSchedulingType MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the upstream scheduling service used for upstream Service Flow. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set of an upstream Service Flow, the default value of this object is bestEffort(2). For QOS parameter sets of downstream Service Flows, this object's value is reported as undefined(1)." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.2" ::= { docsIetfQosParamSetEntry 10 } docsIetfQosParamSetNomPollInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the nominal interval in microseconds between successive unicast request opportunities on an upstream Service Flow. This object applies only to upstream Service Flows with DocsIetfQosSchedulingType of value nonRealTimePollingService(3), realTimePollingService(4), and unsolictedGrantServiceWithAD(5). The parameter is mandatory for realTimePollingService(4). If the parameter is omitted with nonRealTimePollingService(3), the CMTS uses an implementation-dependent value. If the parameter is omitted with unsolictedGrantServiceWithAD(5), the CMTS uses as a default value the value of the Nominal Grant Interval parameter. In all cases, the CMTS reports the value it is using when the parameter is applicable. The CM reports the signaled parameter value if it was signaled, and 0 otherwise. Patrick & Murwin Standards Track [Page 41] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.4" ::= { docsIetfQosParamSetEntry 11 } docsIetfQosParamSetTolPollJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum amount of time in microseconds that the unicast request interval may be delayed from the nominal periodic schedule on an upstream Service Flow. This parameter is applicable only to upstream Service Flows with a DocsIetfQosSchedulingType of realTimePollingService(4) or unsolictedGrantServiceWithAD(5). If the referenced parameter is applicable but not present in the corresponding DOCSIS QOS Parameter Set, the CMTS uses an implementation-dependent value and reports the value it is using. The CM reports a value of 0 in this case. If the parameter is not applicable to the direction or upstream scheduling type of the Service Flow, both CMTS and CM report this object's value as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.5" ::= { docsIetfQosParamSetEntry 12 } docsIetfQosParamSetUnsolicitGrantSize OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the unsolicited grant size in bytes. The grant size includes the entire MAC frame data PDU from the Frame Control byte to the end of the MAC frame. The referenced parameter is applicable only for upstream flows with a DocsIetfQosSchedulingType of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and it is mandatory Patrick & Murwin Standards Track [Page 42] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 when applicable. Both CMTS and CM report the signaled value of the parameter in this case. If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.6" ::= { docsIetfQosParamSetEntry 13 } docsIetfQosParamSetNomGrantInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the nominal interval in microseconds between successive data grant opportunities on an upstream Service Flow. The referenced parameter is applicable only for upstream flows with a DocsIetfQosSchedulingType of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and it is mandatory when applicable. Both CMTS and CM report the signaled value of the parameter in this case. If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.7" ::= { docsIetfQosParamSetEntry 14 } docsIetfQosParamSetTolGrantJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum amount of time in microseconds that the transmission opportunities may be delayed from the nominal periodic schedule. The referenced parameter is applicable only for upstream flows with a DocsIetfQosSchedulingType of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and it is mandatory when applicable. Both CMTS and CM report the Patrick & Murwin Standards Track [Page 43] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 signaled value of the parameter in this case. If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.8" ::= { docsIetfQosParamSetEntry 15 } docsIetfQosParamSetGrantsPerInterval OBJECT-TYPE SYNTAX Integer32 (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of data grants per Nominal Grant Interval (docsIetfQosParamSetNomGrantInterval). The referenced parameter is applicable only for upstream flows with a DocsIetfQosSchedulingType of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and it is mandatory when applicable. Both CMTS and CM report the signaled value of the parameter in this case. If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.9" ::= { docsIetfQosParamSetEntry 16 } docsIetfQosParamSetTosAndMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the AND mask for the IP TOS byte for overwriting IP packet's TOS value. The IP packet TOS byte is bitwise ANDed with docsIetfQosParamSetTosAndMask, and the result is bitwise ORed with docsIetfQosParamSetTosORMask and the result is written to the IP packet TOS byte. A value of 'FF'H for docsIetfQosParamSetTosAndMask and a value of '00'H for docsIetfQosParamSetTosOrMask means that the IP Packet TOS byte is not overwritten. This combination is reported if the referenced parameter is not present in a QOS Parameter Set. Patrick & Murwin Standards Track [Page 44] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 The IP TOS octet as originally defined in RFC 791 has been superseded by the 6-bit Differentiated Services Field (DSField, RFC 3260) and the 2-bit Explicit Congestion Notification Field (ECN field, RFC 3168). Network operators SHOULD avoid specifying values of docsIetfQosParamSetTosAndMask and docsIetfQosParamSetTosORMask that would result in the modification of the ECN bits. In particular, operators should not use values of docsIetfQosParamSetTosAndMask that have either of the least-significant two bits set to 0. Similarly, operators should not use values of docsIetfQosParamSetTosORMask that have either of the least-significant two bits set to 1. Even though this object is only enforced by the Cable Modem Termination System (CMTS), Cable Modems MUST report the value as signaled in the referenced parameter." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10; RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP; RFC 3260, New Terminology and Clarifications for Diffserv." ::= { docsIetfQosParamSetEntry 17 } docsIetfQosParamSetTosOrMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the OR mask for the IP TOS byte. See the description of docsIetfQosParamSetTosAndMask for further details. The IP TOS octet as originally defined in RFC 791 has been superseded by the 6-bit Differentiated Services Field (DSField, RFC 3260) and the 2-bit Explicit Congestion Notification Field (ECN field, RFC 3168). Network operators SHOULD avoid specifying values of docsIetfQosParamSetTosAndMask and docsIetfQosParamSetTosORMask that would result in the modification of the ECN bits." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10; RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP; RFC 3260, New Terminology and Clarifications for Patrick & Murwin Standards Track [Page 45] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Diffserv." ::= { docsIetfQosParamSetEntry 18 } docsIetfQosParamSetMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum latency between the reception of a packet by the CMTS on its NSI and the forwarding of the packet to the RF interface. A value of 0 signifies no maximum latency is enforced. This object only applies to downstream Service Flows. If the referenced parameter is not present in the corresponding downstream DOCSIS QOS Parameter Set, the default value is 0. This parameter is not applicable to upstream DOCSIS QOS Parameter Sets, and its value is reported as 0 in this case." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.7.1" ::= { docsIetfQosParamSetEntry 19 } docsIetfQosParamSetType OBJECT-TYPE SYNTAX INTEGER { active (1), admitted (2), provisioned (3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the type of the QOS parameter set defined by this row. active(1) indicates the Active QOS parameter set, describing the service currently being provided by the DOCSIS MAC domain to the Service Flow. admitted(2) indicates the Admitted QOS Parameter Set, describing services reserved by the DOCSIS MAC domain for use by the service flow. provisioned (3) describes the QOS Parameter Set defined in the DOCSIS CM Configuration file for the Service Flow." REFERENCE "SP-RFIv2.0-I06-040804, 8.1.5" ::= { docsIetfQosParamSetEntry 20 } docsIetfQosParamSetRequestPolicyOct OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) -- A 32-bit mask represented most significant byte Patrick & Murwin Standards Track [Page 46] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 -- first. The 32-bit integer represented in this -- manner equals the binary value of the referenced -- integer parameter of the DOCSIS RFI -- specification. -- The BITS syntax is not used in order to avoid -- the confusion caused by different bit-numbering -- conventions. MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies which transmit interval opportunities the CM omits for upstream transmission requests and packet transmissions. This object takes its default value for downstream Service Flows. Unless otherwise indicated, a bit value of 1 means that a CM must not use that opportunity for upstream transmission. If bit 0 is the least significant bit of the least significant (4th) octet, and if bit number is increased with significance, the bit definitions are defined as follows: broadcastReqOpp(0): all CMs broadcast request opportunities priorityReqMulticastReq(1): priority request multicast request opportunities reqDataForReq(2): request/data opportunities for requests reqDataForData(3): request/data opportunities for data piggybackReqWithData(4): piggyback requests with data concatenateData(5): concatenate data fragmentData(6): fragment data suppresspayloadheaders(7): suppress payload headers Patrick & Murwin Standards Track [Page 47] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 dropPktsExceedUGSize(8): A value of 1 means that the Service Flow must drop packets that do not fit in the Unsolicited Grant size. If the referenced parameter is not present in a QOS Parameter Set, the value of this object is reported as '00000000'H." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.3" ::= { docsIetfQosParamSetEntry 21 } docsIetfQosParamSetBitMap OBJECT-TYPE -- Each bit corresponds to a parameter -- from SP-RFI-v1.1-I10-037030, -- Appendix C in the indicated SYNTAX BITS { -- section number. trafficPriority(0), -- C.2.2.5.1 maxTrafficRate(1), -- C.2.2.5.2 maxTrafficBurst(2), -- C.2.2.5.3 minReservedRate(3), -- C.2.2.5.4 minReservedPkt(4), -- C.2.2.5.5 activeTimeout(5), -- C.2.2.5.6 admittedTimeout(6), -- C.2.2.5.7 maxConcatBurst(7), -- C.2.2.6.1 schedulingType(8), -- C.2.2.6.2 requestPolicy(9), -- C.2.2.6.3 nomPollInterval(10), -- C.2.2.6.4 tolPollJitter(11), -- C.2.2.6.5 unsolicitGrantSize(12), -- C.2.2.6.6 nomGrantInterval(13), -- C.2.2.6.7 tolGrantJitter(14), -- C.2.2.6.8 grantsPerInterval(15), -- C.2.2.6.9 tosOverwrite(16), -- C.2.2.6.10 maxLatency(17) -- C.2.2.7.1 } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the set of QOS Parameter Set parameters actually signaled in the DOCSIS registration or dynamic service request message that created or modified the QOS Parameter Set. A bit is set to 1 when the parameter described by the indicated reference section is present in the original request. Note that when Service Class names are expanded, the registration or dynamic response message may contain parameters as expanded by the CMTS based Patrick & Murwin Standards Track [Page 48] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 on a stored service class. These expanded parameters are not indicated by a 1 bit in this object. Note that even though some QOS Parameter Set parameters may not be signaled in a message (so that the paramater's bit in this object is 0), the DOCSIS specification requires that default values be used. These default values are reported as the corresponding object's value in the row. Note that BITS objects are encoded most significant bit first. For example, if bits 1 and 16 are set, the value of this object is the octet string '400080'H." ::= { docsIetfQosParamSetEntry 22 } -- -- Service Flow Table -- docsIetfQosServiceFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosServiceFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of DOCSIS-QOS Service Flows in a managed device." ::= { docsIetfQosMIBObjects 3 } docsIetfQosServiceFlowEntry OBJECT-TYPE SYNTAX DocsIetfQosServiceFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a Service Flow. An entry in the table exists for each Service Flow ID. The ifIndex is an ifType of docsCableMaclayer(127)." INDEX { ifIndex, docsIetfQosServiceFlowId } ::= { docsIetfQosServiceFlowTable 1 } DocsIetfQosServiceFlowEntry ::= SEQUENCE { docsIetfQosServiceFlowId Unsigned32, docsIetfQosServiceFlowSID Unsigned32, docsIetfQosServiceFlowDirection DocsIetfQosRfMacIfDirection, docsIetfQosServiceFlowPrimary TruthValue } Patrick & Murwin Standards Track [Page 49] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosServiceFlowId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index assigned to a Service Flow by CMTS." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.2" ::= { docsIetfQosServiceFlowEntry 1 } docsIetfQosServiceFlowSID OBJECT-TYPE SYNTAX Unsigned32 (0..16383) MAX-ACCESS read-only STATUS current DESCRIPTION "Service Identifier (SID) assigned to an admitted or active Service Flow. This object reports a value of 0 if a Service ID is not associated with the Service Flow. Only active or admitted upstream Service Flows will have a Service ID (SID)." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.3" ::= { docsIetfQosServiceFlowEntry 2 } docsIetfQosServiceFlowDirection OBJECT-TYPE SYNTAX DocsIetfQosRfMacIfDirection MAX-ACCESS read-only STATUS current DESCRIPTION "The direction of the Service Flow." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.1/2" ::= { docsIetfQosServiceFlowEntry 3 } docsIetfQosServiceFlowPrimary OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Object reflects whether Service Flow is the primary or a secondary Service Flow. A primary Service Flow is the default Service Flow for otherwise unclassified traffic and all MAC messages." REFERENCE "SP-RFIv2.0-I06-040804, Section 8.1 " ::= { docsIetfQosServiceFlowEntry 4 } -- -- Service Flow Stats Table -- docsIetfQosServiceFlowStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosServiceFlowStatsEntry MAX-ACCESS not-accessible Patrick & Murwin Standards Track [Page 50] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 STATUS current DESCRIPTION "This table describes statistics associated with the Service Flows in a managed device." ::= { docsIetfQosMIBObjects 4 } docsIetfQosServiceFlowStatsEntry OBJECT-TYPE SYNTAX DocsIetfQosServiceFlowStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a set of Service Flow statistics. An entry in the table exists for each Service Flow ID. The ifIndex is an ifType of docsCableMaclayer(127)." INDEX { ifIndex, docsIetfQosServiceFlowId } ::= { docsIetfQosServiceFlowStatsTable 1 } DocsIetfQosServiceFlowStatsEntry ::= SEQUENCE { docsIetfQosServiceFlowPkts Counter64, docsIetfQosServiceFlowOctets Counter64, docsIetfQosServiceFlowTimeCreated TimeStamp, docsIetfQosServiceFlowTimeActive Counter32, docsIetfQosServiceFlowPHSUnknowns Counter32, docsIetfQosServiceFlowPolicedDropPkts Counter32, docsIetfQosServiceFlowPolicedDelayPkts Counter32 } docsIetfQosServiceFlowPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "For outgoing Service Flows, this object counts the number of Packet Data PDUs forwarded to this Service Flow. For incoming upstream CMTS service flows, this object counts the number of Packet Data PDUs actually received on the Service Flow identified by the SID for which the packet was scheduled. CMs not classifying downstream packets may report this object's value as 0 for downstream Service Flows. This object does not count MAC-specific management messages. Particularly for UGS flows, packets sent on the primary Service Flow in violation of the UGS grant size should be counted only by the instance of this object that is associated with the primary service Patrick & Murwin Standards Track [Page 51] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 flow. Unclassified upstream user data packets (i.e., non- MAC-management) forwarded to the primary upstream Service Flow should be counted by the instance of this object that is associated with the primary service flow. This object does include packets counted by docsIetfQosServiceFlowPolicedDelayPkts, but does not include packets counted by docsIetfQosServiceFlowPolicedDropPkts and docsIetfQosServiceFlowPHSUnknowns. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosServiceFlowStatsEntry 1 } docsIetfQosServiceFlowOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets from the byte after the MAC header HCS to the end of the CRC for all packets counted in the docsIetfQosServiceFlowPkts object for this row. Note that this counts the octets after payload header suppression and before payload header expansion have been applied. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosServiceFlowStatsEntry 2 } docsIetfQosServiceFlowTimeCreated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the service flow was created." ::= { docsIetfQosServiceFlowStatsEntry 3 } docsIetfQosServiceFlowTimeActive OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current Patrick & Murwin Standards Track [Page 52] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 DESCRIPTION "The number of seconds that the service flow has been active. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosServiceFlowStatsEntry 4 } docsIetfQosServiceFlowPHSUnknowns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For incoming upstream CMTS service flows, this object counts the number of packets received with an unknown payload header suppression index. The service flow is identified by the SID for which the packet was scheduled. On a CM, only this object's instance for the primary downstream service flow counts packets received with an unknown payload header suppression index. All other downstream service flows on CM report this objects value as 0. All outgoing service flows report this object's value as 0. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosServiceFlowStatsEntry 5 } docsIetfQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For outgoing service flows, this object counts the number of Packet Data PDUs classified to this service flow dropped due to: (1) implementation-dependent excessive delay while enforcing the Maximum Sustained Traffic Rate; or (2) UGS packets dropped due to exceeding the Unsolicited Grant Size with a Request/Transmission policy that requires such packets to be dropped. Classified packets dropped due to other reasons Patrick & Murwin Standards Track [Page 53] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 must be counted in ifOutDiscards for the interface of this service flow. This object reports 0 for incoming service flows. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosServiceFlowStatsEntry 6 } docsIetfQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only outgoing packets delayed in order to maintain the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply. This object is 0 for incoming service flows. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosServiceFlowStatsEntry 7 } -- -- Upstream Service Flow Stats Table (CMTS ONLY) -- docsIetfQosUpstreamStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosUpstreamStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes statistics associated with upstream service flows. All counted frames must be received without a Frame Check Sequence (FCS) error." ::= { docsIetfQosMIBObjects 5 } docsIetfQosUpstreamStatsEntry OBJECT-TYPE SYNTAX DocsIetfQosUpstreamStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a set of upstream service flow statistics. An entry in the table exists for each upstream Service Flow in a managed device. The ifIndex is an ifType of docsCableMaclayer(127)." INDEX { Patrick & Murwin Standards Track [Page 54] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 ifIndex, docsIetfQosSID } ::= { docsIetfQosUpstreamStatsTable 1 } DocsIetfQosUpstreamStatsEntry ::= SEQUENCE { docsIetfQosSID Unsigned32, docsIetfQosUpstreamFragments Counter32, docsIetfQosUpstreamFragDiscards Counter32, docsIetfQosUpstreamConcatBursts Counter32 } docsIetfQosSID OBJECT-TYPE SYNTAX Unsigned32 (1..16383) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies a service ID for an admitted or active upstream service flow." ::= { docsIetfQosUpstreamStatsEntry 1 } docsIetfQosUpstreamFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of fragmentation headers received on an upstream service flow, regardless of whether the fragment was correctly reassembled into a valid packet. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosUpstreamStatsEntry 2 } docsIetfQosUpstreamFragDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of upstream fragments discarded and not assembled into a valid upstream packet. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosUpstreamStatsEntry 3 } docsIetfQosUpstreamConcatBursts OBJECT-TYPE SYNTAX Counter32 Patrick & Murwin Standards Track [Page 55] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of concatenation headers received on an upstream service flow. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosUpstreamStatsEntry 4 } -- -- Dynamic Service Stats Table -- docsIetfQosDynamicServiceStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosDynamicServiceStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes statistics associated with the Dynamic Service Flows in a managed device." ::= { docsIetfQosMIBObjects 6 } docsIetfQosDynamicServiceStatsEntry OBJECT-TYPE SYNTAX DocsIetfQosDynamicServiceStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a set of dynamic service flow statistics. Two entries exist for each DOCSIS MAC layer interface for the upstream and downstream direction. On the CMTS, the downstream direction row indicates messages transmitted or transactions originated by the CMTS. The upstream direction row indicates messages received or transaction originated by the CM. On the CM, the downstream direction row indicates messages received or transactions originated by the CMTS. The upstream direction row indicates messages transmitted by the CM or transactions originated by the CM. The ifIndex is an ifType of docsCableMaclayer(127)." INDEX { ifIndex, docsIetfQosIfDirection } ::= { docsIetfQosDynamicServiceStatsTable 1 } DocsIetfQosDynamicServiceStatsEntry ::= SEQUENCE { docsIetfQosIfDirection DocsIetfQosRfMacIfDirection, docsIetfQosDSAReqs Counter32, Patrick & Murwin Standards Track [Page 56] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosDSARsps Counter32, docsIetfQosDSAAcks Counter32, docsIetfQosDSCReqs Counter32, docsIetfQosDSCRsps Counter32, docsIetfQosDSCAcks Counter32, docsIetfQosDSDReqs Counter32, docsIetfQosDSDRsps Counter32, docsIetfQosDynamicAdds Counter32, docsIetfQosDynamicAddFails Counter32, docsIetfQosDynamicChanges Counter32, docsIetfQosDynamicChangeFails Counter32, docsIetfQosDynamicDeletes Counter32, docsIetfQosDynamicDeleteFails Counter32, docsIetfQosDCCReqs Counter32, docsIetfQosDCCRsps Counter32, docsIetfQosDCCAcks Counter32, docsIetfQosDCCs Counter32, docsIetfQosDCCFails Counter32 } docsIetfQosIfDirection OBJECT-TYPE SYNTAX DocsIetfQosRfMacIfDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "The direction of interface." ::= { docsIetfQosDynamicServiceStatsEntry 1 } docsIetfQosDSAReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Addition Requests, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 2 } docsIetfQosDSARsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Addition Responses, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that Patrick & Murwin Standards Track [Page 57] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 3 } docsIetfQosDSAAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Addition Acknowledgements, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 4 } docsIetfQosDSCReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Change Requests, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 5 } docsIetfQosDSCRsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Change Responses, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 6 } docsIetfQosDSCAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Change Acknowledgements, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that Patrick & Murwin Standards Track [Page 58] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 7 } docsIetfQosDSDReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Delete Requests, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 8 } docsIetfQosDSDRsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Delete Responses, including retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 9 } docsIetfQosDynamicAdds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Service Addition transactions. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 10 } docsIetfQosDynamicAddFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Service Addition transactions. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that Patrick & Murwin Standards Track [Page 59] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 11 } docsIetfQosDynamicChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Service Change transactions. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 12 } docsIetfQosDynamicChangeFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Service Change transactions. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 13 } docsIetfQosDynamicDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Service Delete transactions. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 14 } docsIetfQosDynamicDeleteFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Service Delete transactions. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that Patrick & Murwin Standards Track [Page 60] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 15 } docsIetfQosDCCReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Channel Change Request messages traversing an interface. This count is nonzero only on downstream direction rows. This count should include the number of retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 16 } docsIetfQosDCCRsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Channel Change Response messages traversing an interface. This count is nonzero only on upstream direction rows. This count should include the number of retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 17 } docsIetfQosDCCAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Channel Change Acknowledgement messages traversing an interface. This count is nonzero only on downstream direction rows. This count should include the number of retries. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 18 } docsIetfQosDCCs OBJECT-TYPE SYNTAX Counter32 Patrick & Murwin Standards Track [Page 61] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Channel Change transactions. This count is nonzero only on downstream direction rows. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 19 } docsIetfQosDCCFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Channel Change transactions. This count is nonzero only on downstream direction rows. This counter's last discontinuity is the ifCounterDiscontinuityTime for the same ifIndex that indexes this object." ::= { docsIetfQosDynamicServiceStatsEntry 20 } -- -- Service Flow Log Table (CMTS ONLY) -- docsIetfQosServiceFlowLogTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosServiceFlowLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a log of the disconnected Service Flows in a managed device." ::= { docsIetfQosMIBObjects 7 } docsIetfQosServiceFlowLogEntry OBJECT-TYPE SYNTAX DocsIetfQosServiceFlowLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The information regarding a single disconnected service flow." INDEX { docsIetfQosServiceFlowLogIndex } ::= { docsIetfQosServiceFlowLogTable 1 } DocsIetfQosServiceFlowLogEntry ::= SEQUENCE { Patrick & Murwin Standards Track [Page 62] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosServiceFlowLogIndex Unsigned32, docsIetfQosServiceFlowLogIfIndex InterfaceIndex, docsIetfQosServiceFlowLogSFID Unsigned32, docsIetfQosServiceFlowLogCmMac MacAddress, docsIetfQosServiceFlowLogPkts Counter64, docsIetfQosServiceFlowLogOctets Counter64, docsIetfQosServiceFlowLogTimeDeleted TimeStamp, docsIetfQosServiceFlowLogTimeCreated TimeStamp, docsIetfQosServiceFlowLogTimeActive Counter32, docsIetfQosServiceFlowLogDirection DocsIetfQosRfMacIfDirection, docsIetfQosServiceFlowLogPrimary TruthValue, docsIetfQosServiceFlowLogServiceClassName SnmpAdminString, docsIetfQosServiceFlowLogPolicedDropPkts Counter32, docsIetfQosServiceFlowLogPolicedDelayPkts Counter32, docsIetfQosServiceFlowLogControl INTEGER } docsIetfQosServiceFlowLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Unique index for a logged service flow." ::= { docsIetfQosServiceFlowLogEntry 1 } docsIetfQosServiceFlowLogIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex of ifType docsCableMaclayer(127) on the CMTS where the service flow was present." ::= { docsIetfQosServiceFlowLogEntry 2 } docsIetfQosServiceFlowLogSFID OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The index assigned to the service flow by the CMTS." ::= { docsIetfQosServiceFlowLogEntry 3 } docsIetfQosServiceFlowLogCmMac OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC address for the cable modem associated with the service flow." ::= { docsIetfQosServiceFlowLogEntry 4 } docsIetfQosServiceFlowLogPkts OBJECT-TYPE Patrick & Murwin Standards Track [Page 63] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets counted on this service flow after payload header suppression." ::= { docsIetfQosServiceFlowLogEntry 5 } docsIetfQosServiceFlowLogOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets counted on this service flow after payload header suppression." ::= { docsIetfQosServiceFlowLogEntry 6 } docsIetfQosServiceFlowLogTimeDeleted OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the service flow was deleted." ::= { docsIetfQosServiceFlowLogEntry 7 } docsIetfQosServiceFlowLogTimeCreated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the service flow was created." ::= { docsIetfQosServiceFlowLogEntry 8 } docsIetfQosServiceFlowLogTimeActive OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The total time that the service flow was active." ::= { docsIetfQosServiceFlowLogEntry 9 } docsIetfQosServiceFlowLogDirection OBJECT-TYPE SYNTAX DocsIetfQosRfMacIfDirection MAX-ACCESS read-only STATUS current DESCRIPTION "The value of docsIetfQosServiceFlowDirection for the service flow." ::= { docsIetfQosServiceFlowLogEntry 10 } docsIetfQosServiceFlowLogPrimary OBJECT-TYPE Patrick & Murwin Standards Track [Page 64] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of docsIetfQosServiceFlowPrimary for the service flow." ::= { docsIetfQosServiceFlowLogEntry 11 } docsIetfQosServiceFlowLogServiceClassName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of docsIetfQosParamSetServiceClassName for the provisioned QOS Parameter Set of the service flow." ::= { docsIetfQosServiceFlowLogEntry 12 } docsIetfQosServiceFlowLogPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The final value of docsIetfQosServiceFlowPolicedDropPkts for the service flow." ::= { docsIetfQosServiceFlowLogEntry 13 } docsIetfQosServiceFlowLogPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The final value of docsIetfQosServiceFlowPolicedDelayPkts for the service flow." ::= { docsIetfQosServiceFlowLogEntry 14 } docsIetfQosServiceFlowLogControl OBJECT-TYPE SYNTAX INTEGER { active(1), destroy(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to the value destroy(6) removes this entry from the table. Reading this object returns the value active(1)." ::= { docsIetfQosServiceFlowLogEntry 15 } Patrick & Murwin Standards Track [Page 65] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 -- -- Service Class Table (CMTS ONLY) -- docsIetfQosServiceClassTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosServiceClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of DOCSIS-QOS Service Classes in a CMTS." ::= { docsIetfQosMIBObjects 8 } docsIetfQosServiceClassEntry OBJECT-TYPE SYNTAX DocsIetfQosServiceClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A provisioned service class on a CMTS. Each entry defines a template for certain DOCSIS QOS Parameter Set values. When a CM creates or modifies an Admitted QOS Parameter Set for a Service Flow, it may reference a Service Class Name instead of providing explicit QOS Parameter Set values. In this case, the CMTS populates the QOS Parameter Set with the applicable corresponding values from the named Service Class. Subsequent changes to a Service Class row do not affect the QOS Parameter Set values of any service flows already admitted. A service class template applies to only a single direction, as indicated in the docsIetfQosServiceClassDirection object." INDEX { docsIetfQosServiceClassName } ::= { docsIetfQosServiceClassTable 1 } DocsIetfQosServiceClassEntry ::= SEQUENCE { docsIetfQosServiceClassName SnmpAdminString, docsIetfQosServiceClassStatus RowStatus, docsIetfQosServiceClassPriority Integer32, docsIetfQosServiceClassMaxTrafficRate DocsIetfQosBitRate, docsIetfQosServiceClassMaxTrafficBurst Unsigned32, docsIetfQosServiceClassMinReservedRate DocsIetfQosBitRate, docsIetfQosServiceClassMinReservedPkt Integer32, docsIetfQosServiceClassMaxConcatBurst Integer32, docsIetfQosServiceClassNomPollInterval Unsigned32, docsIetfQosServiceClassTolPollJitter Unsigned32, docsIetfQosServiceClassUnsolicitGrantSize Integer32, Patrick & Murwin Standards Track [Page 66] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosServiceClassNomGrantInterval Unsigned32, docsIetfQosServiceClassTolGrantJitter Unsigned32, docsIetfQosServiceClassGrantsPerInterval Integer32, docsIetfQosServiceClassMaxLatency Unsigned32, docsIetfQosServiceClassActiveTimeout Integer32, docsIetfQosServiceClassAdmittedTimeout Integer32, docsIetfQosServiceClassSchedulingType DocsIetfQosSchedulingType, docsIetfQosServiceClassRequestPolicy OCTET STRING, docsIetfQosServiceClassTosAndMask OCTET STRING, docsIetfQosServiceClassTosOrMask OCTET STRING, docsIetfQosServiceClassDirection DocsIetfQosRfMacIfDirection, docsIetfQosServiceClassStorageType StorageType, docsIetfQosServiceClassDSCPOverwrite DscpOrAny } docsIetfQosServiceClassName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..15)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Service Class Name. DOCSIS specifies that the maximum size is 16 ASCII characters including a terminating zero. The terminating zero is not represented in this SnmpAdminString syntax object." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.4" ::= { docsIetfQosServiceClassEntry 1 } docsIetfQosServiceClassStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used to create or delete rows in this table. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not be timed out." ::= { docsIetfQosServiceClassEntry 2 } docsIetfQosServiceClassPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetPriority." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 3 } docsIetfQosServiceClassMaxTrafficRate OBJECT-TYPE SYNTAX DocsIetfQosBitRate MAX-ACCESS read-create STATUS current Patrick & Murwin Standards Track [Page 67] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 DESCRIPTION "Template for docsIetfQosParamSetMaxTrafficRate." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 4 } docsIetfQosServiceClassMaxTrafficBurst OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetMaxTrafficBurst." DEFVAL { 3044 } ::= { docsIetfQosServiceClassEntry 5 } docsIetfQosServiceClassMinReservedRate OBJECT-TYPE SYNTAX DocsIetfQosBitRate MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSEtMinReservedRate." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 6 } docsIetfQosServiceClassMinReservedPkt OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetMinReservedPkt." ::= { docsIetfQosServiceClassEntry 7 } docsIetfQosServiceClassMaxConcatBurst OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetMaxConcatBurst." DEFVAL { 1522 } ::= { docsIetfQosServiceClassEntry 8 } docsIetfQosServiceClassNomPollInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetNomPollInterval." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 9 } docsIetfQosServiceClassTolPollJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-create Patrick & Murwin Standards Track [Page 68] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 STATUS current DESCRIPTION "Template for docsIetfQosParamSetTolPollJitter." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 10 } docsIetfQosServiceClassUnsolicitGrantSize OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetUnsolicitGrantSize." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 11 } docsIetfQosServiceClassNomGrantInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetNomGrantInterval." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 12 } docsIetfQosServiceClassTolGrantJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetTolGrantJitter." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 13 } docsIetfQosServiceClassGrantsPerInterval OBJECT-TYPE SYNTAX Integer32 (0..127) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetGrantsPerInterval." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 14 } docsIetfQosServiceClassMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetClassMaxLatency." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.7.1" DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 15 } Patrick & Murwin Standards Track [Page 69] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosServiceClassActiveTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetActiveTimeout." DEFVAL { 0 } ::= { docsIetfQosServiceClassEntry 16 } docsIetfQosServiceClassAdmittedTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetAdmittedTimeout." DEFVAL { 200 } ::= { docsIetfQosServiceClassEntry 17 } docsIetfQosServiceClassSchedulingType OBJECT-TYPE SYNTAX DocsIetfQosSchedulingType MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetSchedulingType." DEFVAL { bestEffort } ::= { docsIetfQosServiceClassEntry 18 } docsIetfQosServiceClassRequestPolicy OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsIetfQosParamSetRequestPolicyOct." DEFVAL { '00000000'H } -- no bits are set ::= { docsIetfQosServiceClassEntry 19 } docsIetfQosServiceClassTosAndMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "Template for docsIetfQosParamSetTosAndMask. The IP TOS octet as originally defined in RFC 791 has been superseded by the 6-bit Differentiated Services Field (DSField, RFC 3260) and the 2-bit Explicit Congestion Notification Field (ECN field, RFC 3168). Network operators SHOULD avoid specifying values of docsIetfQosServiceClassTosAndMask and docsIetfQosServiceClassTosOrMask that would result in the modification of the ECN bits. Patrick & Murwin Standards Track [Page 70] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 In particular, operators should not use values of docsIetfQosServiceClassTosAndMask that have either of the least-significant two bits set to 0. Similarly,operators should not use values of docsIetfQosServiceClassTosOrMask that have either of the least-significant two bits set to 1." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10; RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP; RFC 3260, New Terminology and Clarifications for Diffserv." ::= { docsIetfQosServiceClassEntry 20 } docsIetfQosServiceClassTosOrMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "Template for docsIetfQosParamSetTosOrMask. The IP TOS octet as originally defined in RFC 791 has been superseded by the 6-bit Differentiated Services Field (DSField, RFC 3260) and the 2-bit Explicit Congestion Notification Field (ECN field, RFC 3168). Network operators SHOULD avoid specifying values of docsIetfQosServiceClassTosAndMask and docsIetfQosServiceClassTosOrMask that would result in the modification of the ECN bits. In particular, operators should not use values of docsIetfQosServiceClassTosAndMask that have either of the least-significant two bits set to 0. Similarly, operators should not use values of docsIetfQosServiceClassTosOrMask that have either of the least-significant two bits set to 1." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10; RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP; RFC 3260, New Terminology and Clarifications for Diffserv." ::= { docsIetfQosServiceClassEntry 21 } docsIetfQosServiceClassDirection OBJECT-TYPE SYNTAX DocsIetfQosRfMacIfDirection MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies whether the service class template applies to upstream or downstream service flows." DEFVAL { upstream } Patrick & Murwin Standards Track [Page 71] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 ::= { docsIetfQosServiceClassEntry 22 } docsIetfQosServiceClassStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row is kept in volatile storage and lost upon reboot or whether it is backed up by non-volatile or permanent storage. 'permanent' entries need not allow writable access to any object." DEFVAL { nonVolatile } ::= { docsIetfQosServiceClassEntry 23 } docsIetfQosServiceClassDSCPOverwrite OBJECT-TYPE SYNTAX DscpOrAny MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows the overwrite of the DSCP field per RFC 3260. If this object is -1, then the corresponding entry's docsIetfQosServiceClassTosAndMask value MUST be 'FF'H and docsIetfQosServiceClassTosOrMask MUST be '00'H. Otherwise, this object is in the range of 0..63, and the corresponding entry's docsIetfQosServiceClassTosAndMask value MUST be '03'H and the docsIetfQosServiceClassTosOrMask MUST be this object's value shifted left by two bit positions." REFERENCE "RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP; RFC 3260, New Terminology and Clarifications for Diffserv." DEFVAL { -1 } ::= { docsIetfQosServiceClassEntry 24 } -- -- Service Class PolicyTable -- docsIetfQosServiceClassPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosServiceClassPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of DOCSIS-QOS Service Class Policies. This table is an adjunct to the Patrick & Murwin Standards Track [Page 72] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsDevFilterPolicy table. Entries in the docsDevFilterPolicy table can point to specific rows in this table. This table permits mapping a packet to a service class name of an active service flow so long as a classifier does not exist at a higher priority." REFERENCE "SP-RFIv2.0-I06-040804, Appendix E.2.1" ::= { docsIetfQosMIBObjects 9 } docsIetfQosServiceClassPolicyEntry OBJECT-TYPE SYNTAX DocsIetfQosServiceClassPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A service class name policy entry." INDEX { docsIetfQosServiceClassPolicyIndex } ::= { docsIetfQosServiceClassPolicyTable 1 } DocsIetfQosServiceClassPolicyEntry ::= SEQUENCE { docsIetfQosServiceClassPolicyIndex Unsigned32, docsIetfQosServiceClassPolicyName SnmpAdminString, docsIetfQosServiceClassPolicyRulePriority Integer32, docsIetfQosServiceClassPolicyStatus RowStatus, docsIetfQosServiceClassPolicyStorageType StorageType } docsIetfQosServiceClassPolicyIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index value to identify an entry in this table uniquely." ::= { docsIetfQosServiceClassPolicyEntry 1 } docsIetfQosServiceClassPolicyName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Service Class Name to identify the name of the service class flow to which the packet should be directed." REFERENCE "SP-RFIv2.0-I06-040804, Appendix E.2.1" ::= { docsIetfQosServiceClassPolicyEntry 2 } docsIetfQosServiceClassPolicyRulePriority OBJECT-TYPE Patrick & Murwin Standards Track [Page 73] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Service Class Policy rule priority for the entry." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.5" ::= { docsIetfQosServiceClassPolicyEntry 3 } docsIetfQosServiceClassPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used to create or delete rows in this table. This object should not be deleted if it is referenced by an entry in docsDevFilterPolicy. The reference should be deleted first. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not be timed out." ::= { docsIetfQosServiceClassPolicyEntry 4 } docsIetfQosServiceClassPolicyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row is kept in volatile storage and lost upon reboot or whether it is backed up by non-volatile or permanent storage. 'permanent' entries need not allow writable access to any object." DEFVAL { nonVolatile } ::= { docsIetfQosServiceClassPolicyEntry 5 } -- -- Payload Header Suppression(PHS) Table -- docsIetfQosPHSTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosPHSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of payload header suppression entries." ::= { docsIetfQosMIBObjects 10 } docsIetfQosPHSEntry OBJECT-TYPE SYNTAX DocsIetfQosPHSEntry MAX-ACCESS not-accessible STATUS current Patrick & Murwin Standards Track [Page 74] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 DESCRIPTION "A payload header suppression entry. The ifIndex is an ifType of docsCableMaclayer(127). The index docsIetfQosServiceFlowId selects one service flow from the cable MAC layer interface. The docsIetfQosPktClassId index matches an index of the docsIetfQosPktClassTable." INDEX { ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId } ::= { docsIetfQosPHSTable 1 } DocsIetfQosPHSEntry ::= SEQUENCE { docsIetfQosPHSField OCTET STRING, docsIetfQosPHSMask OCTET STRING, docsIetfQosPHSSize Integer32, docsIetfQosPHSVerify TruthValue, docsIetfQosPHSIndex Integer32 } docsIetfQosPHSField OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression field defines the bytes of the header that must be suppressed/restored by the sending/receiving device. The number of octets in this object should be the same as the value of docsIetfQosPHSSize." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.1" ::= { docsIetfQosPHSEntry 1 } docsIetfQosPHSMask OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression mask defines the bit mask that is used in combination with the docsIetfQosPHSField. It defines which bytes in the header must be suppressed/restored by the sending or receiving device. Each bit of this bit mask corresponds to a byte in the docsIetfQosPHSField, with the least Patrick & Murwin Standards Track [Page 75] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 significant bit corresponding to the first byte of the docsIetfQosPHSField. Each bit of the bit mask specifies whether the corresponding byte should be suppressed in the packet. A bit value of '1' indicates that the byte should be suppressed by the sending device and restored by the receiving device. A bit value of '0' indicates that the byte should not be suppressed by the sending device or restored by the receiving device. If the bit mask does not contain a bit for each byte in the docsIetfQosPHSField, then the bit mask is extended with bit values of '1' to be the necessary length." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.3" ::= { docsIetfQosPHSEntry 2 } docsIetfQosPHSSize OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression size specifies the number of bytes in the header to be suppressed and restored. The value of this object must match the number of bytes in the docsIetfQosPHSField." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.4" ::= { docsIetfQosPHSEntry 3 } docsIetfQosPHSVerify OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression verification value. If 'true', the sender must verify docsIetfQosPHSField is the same as what is contained in the packet to be suppressed." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.5" ::= { docsIetfQosPHSEntry 4 } docsIetfQosPHSIndex OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression index uniquely Patrick & Murwin Standards Track [Page 76] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 references the PHS rule for a given service flow." REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.2" ::= { docsIetfQosPHSEntry 5 } -- -- docsIetfQosCmtsMacToSrvFlowTable (CMTS Only) -- docsIetfQosCmtsMacToSrvFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIetfQosCmtsMacToSrvFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides for referencing the service flows associated with a particular cable modem. This allows indexing into other docsIetfQos tables that are indexed by docsIetfQosServiceFlowId and ifIndex." ::= { docsIetfQosMIBObjects 11 } docsIetfQosCmtsMacToSrvFlowEntry OBJECT-TYPE SYNTAX DocsIetfQosCmtsMacToSrvFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry is created by CMTS for each service flow connected to this CMTS." INDEX { docsIetfQosCmtsCmMac, docsIetfQosCmtsServiceFlowId } ::= { docsIetfQosCmtsMacToSrvFlowTable 1 } DocsIetfQosCmtsMacToSrvFlowEntry ::= SEQUENCE { docsIetfQosCmtsCmMac MacAddress, docsIetfQosCmtsServiceFlowId Unsigned32, docsIetfQosCmtsIfIndex InterfaceIndex } docsIetfQosCmtsCmMac OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MAC address for the referenced CM." ::= { docsIetfQosCmtsMacToSrvFlowEntry 1 } docsIetfQosCmtsServiceFlowId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current Patrick & Murwin Standards Track [Page 77] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 DESCRIPTION "An index assigned to a service flow by CMTS." ::= { docsIetfQosCmtsMacToSrvFlowEntry 2 } docsIetfQosCmtsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex of ifType docsCableMacLayer(127) on the CMTS that is connected to the Cable Modem." ::= { docsIetfQosCmtsMacToSrvFlowEntry 3 } -- -- Conformance definitions -- docsIetfQosConformance OBJECT IDENTIFIER ::= { docsIetfQosMIB 2 } docsIetfQosGroups OBJECT IDENTIFIER ::= { docsIetfQosConformance 1 } docsIetfQosCompliances OBJECT IDENTIFIER ::= { docsIetfQosConformance 2 } docsIetfQosCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for MCNS Cable Modems and Cable Modem Termination Systems that implement DOCSIS Service Flows." MODULE -- docsIetfQosMIB MANDATORY-GROUPS { docsIetfQosBaseGroup } GROUP docsIetfQosCmtsGroup DESCRIPTION "This group is mandatory for Cable Modem Termination Systems (CMTS) and is not implemented for Cable Modems (CM)." GROUP docsIetfQosParamSetGroup DESCRIPTION "This group is mandatory for Cable Modem Termination Systems (CMTS) and Cable Modems. Cable modems only implement objects in this group as read-only." GROUP docsIetfQosSrvClassPolicyGroup DESCRIPTION "This group is optional for Cable Modem Termination Patrick & Murwin Standards Track [Page 78] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Systems (CMTS) and Cable Modems. This group is relevant if policy-based service flow classification is implemented. See docsDevPolicyTable in DOCS-CABLE-DEVICE-MIB for more details." GROUP docsIetfQosServiceClassGroup DESCRIPTION "This group is mandatory for a Cable Modem Termination System (CMTS) that implements expansion of Service Class Names in a QOS Parameter Set. This group is not implemented on the Cable Modems." OBJECT docsIetfQosPktClassPkts DESCRIPTION "This object only needs to be implemented in entries that are classifying packets and not policing packets." OBJECT docsIetfQosPktClassInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsIetfQosPktClassInetSourceAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsIetfQosPktClassInetSourceMask SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsIetfQosPktClassInetDestAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsIetfQosPktClassInetDestMask SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsIetfQosServiceClassStorageType Patrick & Murwin Standards Track [Page 79] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT docsIetfQosServiceClassPolicyStorageType SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." ::= { docsIetfQosCompliances 1 } docsIetfQosBaseGroup OBJECT-GROUP OBJECTS { docsIetfQosPktClassDirection, docsIetfQosPktClassPriority, docsIetfQosPktClassIpTosLow, docsIetfQosPktClassIpTosHigh, docsIetfQosPktClassIpTosMask, docsIetfQosPktClassIpProtocol, docsIetfQosPktClassSourcePortStart, docsIetfQosPktClassSourcePortEnd, docsIetfQosPktClassDestPortStart, docsIetfQosPktClassDestPortEnd, docsIetfQosPktClassDestMacAddr, docsIetfQosPktClassDestMacMask, docsIetfQosPktClassSourceMacAddr, docsIetfQosPktClassEnetProtocolType, docsIetfQosPktClassEnetProtocol, docsIetfQosPktClassUserPriLow, docsIetfQosPktClassUserPriHigh, docsIetfQosPktClassVlanId, docsIetfQosPktClassStateActive, docsIetfQosPktClassPkts, docsIetfQosPktClassBitMap, docsIetfQosPktClassInetAddressType, docsIetfQosPktClassInetSourceAddr, docsIetfQosPktClassInetSourceMask, docsIetfQosPktClassInetDestAddr, docsIetfQosPktClassInetDestMask, docsIetfQosServiceFlowSID, docsIetfQosServiceFlowDirection, docsIetfQosServiceFlowPrimary, docsIetfQosServiceFlowPkts, docsIetfQosServiceFlowOctets, Patrick & Murwin Standards Track [Page 80] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosServiceFlowTimeCreated, docsIetfQosServiceFlowTimeActive, docsIetfQosServiceFlowPHSUnknowns, docsIetfQosServiceFlowPolicedDropPkts, docsIetfQosServiceFlowPolicedDelayPkts, docsIetfQosDSAReqs, docsIetfQosDSARsps, docsIetfQosDSAAcks, docsIetfQosDSCReqs, docsIetfQosDSCRsps, docsIetfQosDSCAcks, docsIetfQosDSDReqs, docsIetfQosDSDRsps, docsIetfQosDynamicAdds, docsIetfQosDynamicAddFails, docsIetfQosDynamicChanges, docsIetfQosDynamicChangeFails, docsIetfQosDynamicDeletes, docsIetfQosDynamicDeleteFails, docsIetfQosDCCReqs, docsIetfQosDCCRsps, docsIetfQosDCCAcks, docsIetfQosDCCs, docsIetfQosDCCFails, docsIetfQosPHSField, docsIetfQosPHSMask, docsIetfQosPHSSize, docsIetfQosPHSVerify, docsIetfQosPHSIndex } STATUS current DESCRIPTION "Group of objects implemented in both Cable Modems and Cable Modem Termination Systems." ::= { docsIetfQosGroups 1 } docsIetfQosParamSetGroup OBJECT-GROUP OBJECTS { docsIetfQosParamSetServiceClassName, docsIetfQosParamSetPriority, docsIetfQosParamSetMaxTrafficRate, docsIetfQosParamSetMaxTrafficBurst, docsIetfQosParamSetMinReservedRate, docsIetfQosParamSetMinReservedPkt, docsIetfQosParamSetActiveTimeout, docsIetfQosParamSetAdmittedTimeout, Patrick & Murwin Standards Track [Page 81] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 docsIetfQosParamSetMaxConcatBurst, docsIetfQosParamSetSchedulingType, docsIetfQosParamSetNomPollInterval, docsIetfQosParamSetTolPollJitter, docsIetfQosParamSetUnsolicitGrantSize, docsIetfQosParamSetNomGrantInterval, docsIetfQosParamSetTolGrantJitter, docsIetfQosParamSetGrantsPerInterval, docsIetfQosParamSetTosAndMask, docsIetfQosParamSetTosOrMask, docsIetfQosParamSetMaxLatency, docsIetfQosParamSetRequestPolicyOct, docsIetfQosParamSetBitMap } STATUS current DESCRIPTION "Group of objects implemented in both Cable Modems and Cable Modem Termination Systems for QOS Parameter Sets." ::= { docsIetfQosGroups 2 } docsIetfQosCmtsGroup OBJECT-GROUP OBJECTS { docsIetfQosUpstreamFragments, docsIetfQosUpstreamFragDiscards, docsIetfQosUpstreamConcatBursts, docsIetfQosServiceFlowLogIfIndex, docsIetfQosServiceFlowLogSFID, docsIetfQosServiceFlowLogCmMac, docsIetfQosServiceFlowLogPkts, docsIetfQosServiceFlowLogOctets, docsIetfQosServiceFlowLogTimeDeleted, docsIetfQosServiceFlowLogTimeCreated, docsIetfQosServiceFlowLogTimeActive, docsIetfQosServiceFlowLogDirection, docsIetfQosServiceFlowLogPrimary, docsIetfQosServiceFlowLogServiceClassName, docsIetfQosServiceFlowLogPolicedDropPkts, docsIetfQosServiceFlowLogPolicedDelayPkts, docsIetfQosServiceFlowLogControl, docsIetfQosCmtsIfIndex -- docsIetfQosCmtsMacToSrvFlowTable required } STATUS current DESCRIPTION Patrick & Murwin Standards Track [Page 82] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 "Group of objects implemented only in the CMTS." ::= { docsIetfQosGroups 3 } docsIetfQosSrvClassPolicyGroup OBJECT-GROUP OBJECTS { docsIetfQosServiceClassPolicyName, docsIetfQosServiceClassPolicyRulePriority, docsIetfQosServiceClassPolicyStatus, docsIetfQosServiceClassPolicyStorageType } STATUS current DESCRIPTION "Group of objects implemented in both Cable Modems and Cable Modem Termination Systems when supporting policy-based service flows." ::= { docsIetfQosGroups 4 } docsIetfQosServiceClassGroup OBJECT-GROUP OBJECTS { docsIetfQosServiceClassStatus, docsIetfQosServiceClassPriority, docsIetfQosServiceClassMaxTrafficRate, docsIetfQosServiceClassMaxTrafficBurst, docsIetfQosServiceClassMinReservedRate, docsIetfQosServiceClassMinReservedPkt, docsIetfQosServiceClassMaxConcatBurst, docsIetfQosServiceClassNomPollInterval, docsIetfQosServiceClassTolPollJitter, docsIetfQosServiceClassUnsolicitGrantSize, docsIetfQosServiceClassNomGrantInterval, docsIetfQosServiceClassTolGrantJitter, docsIetfQosServiceClassGrantsPerInterval, docsIetfQosServiceClassMaxLatency, docsIetfQosServiceClassActiveTimeout, docsIetfQosServiceClassAdmittedTimeout, docsIetfQosServiceClassSchedulingType, docsIetfQosServiceClassRequestPolicy, docsIetfQosServiceClassTosAndMask, docsIetfQosServiceClassTosOrMask, docsIetfQosServiceClassDirection, docsIetfQosServiceClassStorageType, docsIetfQosServiceClassDSCPOverwrite } STATUS current DESCRIPTION "Group of objects implemented only in Cable Modem Termination Systems when supporting expansion of Service Class Names in a QOS Parameter Set" Patrick & Murwin Standards Track [Page 83] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 ::= { docsIetfQosGroups 5 } END 6. Security Considerations This MIB module relates to an agent that will provide metropolitan public Internet access. As such, improper manipulation of the objects represented by this MIB module may result in denial of service to a large number of end-users [6]. Manipulation of the docsIetfQosServiceClassTable and docsIetfQosServiceClassPolicyTable may allow an end-user to increase his or her service levels, or affect other end-users in either a positive or negative manner. In addition, manipulation of docsIetfQosServiceFlowLogControl could allow an attacker to remove logs of packet and byte counts forwarded on a Service Flow. If such logs were used for billing, the attacker would obtain free service. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The docsIetfQosServiceClassTable provides a template of QOS parameters such as maximum rate limits for a named service class. Changing these parameters would allow an attacker to obtain an unauthorized class of service. o The docsIetfQosServiceClassPolicyTable applies CMTS vendor proprietary policies for packet forwarding, including dropping, scheduling, notification, or other policies. Changing this table could allow an attacker to deny service to all subscribers of the CMTS or could grant the attacker unauthorized forwarding policies. o The docsIetfQosServiceFlowLogControl object controls the deletion of entries in the docsIetfQosServiceFlowLogTable, which acts as a historical "detail record" of DOCSIS Service Flow packets and bytes transmitted. Such records may be used for billing purposes, so the unauthorized deletion of the records can result in free service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to Patrick & Murwin Standards Track [Page 84] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 control even GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o Unauthorized SNMP GET access of the docsIetfQosPktClassTable or docsIetfQosPHSTable can allow an attacker to learn IP addresses permitted to have enhanced quality of service, for possible spoofing. This table typically contains the IP addresses involved in voice-over-IP sessions, for example. o Unauthorized SNMP GET access of the docsIetfQosParamSetTable allows an attacker to learn the names of Service Classes that are permitted to have enhanced QoS service, and the values of that enhanced service. That name can be referenced in an unauthorized DOCSIS cable modem configuration file to obtain enhanced service. o Unauthorized SNMP GET access of the docsIetfQosServiceFlowTable can tell an attacker when Service Flows are active, e.g., when a voice-over-IP call is in progress. Unauthorized SNMP GET access of the docsIetfQosServiceFlowLogTable can expose private information about network usage. o Unauthorized SNMP GET access of the docsIetfQosServiceFlowStatsTable, docsIetfQosUpstreamStatsTable, docsIetfQosDynamicServiceStatsTable, docsIetfQosServiceFlowLogTable, and docsIetfQosCmtsMacToSrvFlowTable can tell an attacker the volume of traffic to and from any Service Flow in the system, resulting in loss of privacy of the amount and direction of data transfer. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [15], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP Patrick & Murwin Standards Track [Page 85] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER Value -------------- ----------------------- docsIetfQosMIB { mib-2 127 } 8. Acknowledgements The authors gratefully acknowledge the comments and suggestions of the IP over Cable Data Network (IPCDN) Working Group (especially the co-chairs Richard Woundy and Jean-Francois Mule) as well as the contributions of the Operation and Management Area Director, Bert Wijnen. 9. Normative References [1] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [4] "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I06-040804", DOCSIS, August 2004, http://www.cablelabs.com/specifications/archives/. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] St. Johns, M., "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999. Patrick & Murwin Standards Track [Page 86] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 [7] St. Johns, M., "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [8] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [9] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [11] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [12] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [13] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 10. Informative References [15] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Patrick & Murwin Standards Track [Page 87] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Authors' Addresses Michael Patrick Motorola Broadband Communications Sector 111 Locke Drive Marlborough, MA 01752 Phone: (508) 786-7563 EMail: michael.patrick@motorola.com William Murwin Motorola Broadband Communications Sector 111 Locke Drive Marlborough, MA 01752 Phone: (508) 786-7594 EMail: w.murwin@motorola.com Patrick & Murwin Standards Track [Page 88] RFC 4323 IPCDN DOCSIS QoS MIB January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Patrick & Murwin Standards Track [Page 89] snmp-mibs-downloader-1.1/mibrfcs/rfc4363.txt0000644000000000000000000056106511402176072015577 0ustar Network Working Group D. Levi Request for Comments: 4363 Nortel Networks Obsoletes: 2674 D. Harrington Category: Standards Track Effective Software January 2006 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM). Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo supplements RFC 4188 and obsoletes RFC 2674. Levi & Harrington Standards Track [Page 1] RFC 4363 Bridge MIB Extensions January 2006 Table of Contents 1. The Internet-Standard Management Framework ......................3 2. Overview ........................................................3 2.1. Scope ......................................................3 3. Structure of MIBs ...............................................4 3.1. Structure of Extended Bridge MIB Module ....................5 3.1.1. Relationship to IEEE 802.1D-1998 Manageable Objects .............................................5 3.1.2. Relationship to IEEE 802.1Q Manageable Objects ......6 3.1.3. The dot1dExtBase Subtree ............................7 3.1.4. The dot1dPriority Subtree ...........................7 3.1.5. The dot1dGarp Subtree ...............................7 3.1.6. The dot1dGmrp Subtree ...............................7 3.1.7. The dot1dTpHCPortTable ..............................8 3.1.8. The dot1dTpPortOverflowTable ........................8 3.2. Structure of Virtual Bridge MIB module .....................8 3.2.1. Relationship to IEEE 802.1Q Manageable Objects ......8 3.2.2. The dot1qBase Subtree ..............................12 3.2.3. The dot1qTp Subtree ................................12 3.2.4. The dot1qStatic Subtree ............................12 3.2.5. The dot1qVlan Subtree ..............................12 3.3. Textual Conventions .......................................12 3.4. Relationship to Other MIBs ................................13 3.4.1. Relationship to the SNMPv2-MIB .....................13 3.4.2. Relationship to the IF-MIB .........................13 3.4.2.1. Layering Model ............................14 3.4.2.2. ifStackTable ..............................15 3.4.2.3. ifRcvAddressTable .........................15 3.4.3. Relationship to the BRIDGE-MIB .....................16 3.4.3.1. The dot1dBase Subtree .....................16 3.4.3.2. The dot1dStp Subtree ......................16 3.4.3.3. The dot1dTp Subtree .......................16 3.4.3.4. The dot1dStatic Subtree ...................17 3.4.3.5. Additions to the BRIDGE-MIB ...............17 4. Definitions for Extended Bridge MIB ............................18 5. Definitions for Virtual Bridge MIB .............................42 6. Acknowledgements ...............................................91 7. Security Considerations ........................................91 8. Normative References ...........................................94 9. Informative References .........................................95 Appendix A. Email from Tony Jeffrey from IEEE .....................96 Levi & Harrington Standards Track [Page 2] RFC 4363 Bridge MIB Extensions January 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview A common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the network layer. These devices are often known as 'layer 2 switches'. The transparent method of bridging is defined by IEEE 802.1D-1998 [802.1D]. Managed objects for transparent bridging are defined in the BRIDGE-MIB [BRIDGE-MIB]. The original IEEE 802.1D is augmented by IEEE 802.1Q-2003 [802.1Q] to provide support for 'virtual bridged LANs' where a single bridged physical LAN network may be used to support multiple logical bridged LANs, each of which offers a service approximately the same as that defined by IEEE 802.1D. Such virtual LANs (VLANs) are an integral feature of switched LAN networks. A VLAN can be viewed as a group of end-stations on multiple LAN segments and can communicate as if they were on a single LAN. IEEE 802.1Q defines port-based Virtual LANs where membership is determined by the bridge port on which data frames are received, and port-and-protocol-based Virtual LANs where membership is determined by the bridge port on which frames are received and the protocol identifier of the frame. This memo defines the objects needed for the management of port-based VLANs in bridge entities. This memo supplements RFC 4188 [BRIDGE-MIB] and obsoletes RFC 2674 [RFC2674]. 2.1. Scope The MIB modules defined in this document include a comprehensive set of managed objects that attempts to match the set defined in IEEE 802.1D and IEEE 802.1Q. However, to be consistent with the spirit of Levi & Harrington Standards Track [Page 3] RFC 4363 Bridge MIB Extensions January 2006 the SNMP Framework, a subjective judgement was made to omit the objects from those standards most 'costly' to implement in an agent and least 'essential' for fault and configuration management. The omissions are described in Section 3 below. Historical note: The original BRIDGE-MIB [RFC1493] used the following principles for determining inclusion of an object in the BRIDGE-MIB module: (1) Start with a small set of essential objects and add only as further objects are needed. (2) Require that objects be essential for either fault or configuration management. (3) Consider evidence of current use and/or utility. (4) Limit the total number of objects. (5) Exclude objects that are simply derivable from others in this or other MIBs. (6) Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. 3. Structure of MIBs This document defines objects that supplement those in the BRIDGE-MIB module [BRIDGE-MIB]. Section 3.4.3 of the present document contains some recommendations regarding usage of objects in the BRIDGE-MIB by devices implementing the enhancements defined here. An extended bridge MIB module P-BRIDGE-MIB defines managed objects for the traffic class and multicast filtering enhancements defined by IEEE 802.1D-1998 [802.1D], including the Restricted Group Registration control defined by IEEE P802.1t [802.1t]. A virtual bridge MIB module Q-BRIDGE-MIB defines managed objects for the Virtual LAN bridging enhancements defined by IEEE 802.1Q-2003 [802.1Q], including the Restricted VLAN Registration control, defined by IEEE P802.1u [802.1u], and the VLAN Classification by Protocol and Port enhancement, defined by IEEE P802.1v [802.1v]. Levi & Harrington Standards Track [Page 4] RFC 4363 Bridge MIB Extensions January 2006 3.1. Structure of Extended Bridge MIB Module Objects in this MIB are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees is shown below. 3.1.1. Relationship to IEEE 802.1D-1998 Manageable Objects This section contains a cross-reference to the objects defined in IEEE 802.1D-1998 [802.1D]. It also details those objects that are not considered necessary in this MIB module. Some objects defined by IEEE 802.1D-1998 have been included in the virtual bridge MIB module rather than this one: entries in dot1qTpGroupTable, dot1qForwardAllTable, and dot1qForwardUnregisteredTable are required for virtual bridged LANs with additional indexing (e.g., per-VLAN, per-Filtering-Database (per-FDB)) and so are not defined here. Instead, devices that do not implement virtual bridged LANs but do implement the Extended Forwarding Services defined by IEEE 802.1D (i.e., dynamic learning of multicast group addresses and group service requirements in the filtering database) should implement these tables with a fixed value for dot1qFdbId (the value 1 is recommended) or dot1qVlanIndex (the value 1 is recommended). Devices that support Extended Filtering Services should support dot1qTpGroupTable, dot1qForwardAllTable, and dot1qForwardUnregisteredTable. Extended Bridge MIB Name IEEE 802.1D-1998 Name dot1dExtBase Bridge dot1dDeviceCapabilities dot1dExtendedFilteringServices dot1dTrafficClasses dot1dTrafficClassesEnabled dot1dGmrpStatus .ApplicantAdministrativeControl dot1dPriority dot1dPortPriorityTable dot1dPortDefaultUserPriority .UserPriority dot1dPortNumTrafficClasses dot1dUserPriorityRegenTable .UserPriorityRegenerationTable dot1dUserPriority dot1dRegenUserPriority dot1dTrafficClassTable .TrafficClassTable dot1dTrafficClassPriority dot1dTrafficClass dot1dPortOutboundAccessPriorityTable .OutboundAccessPriorityTable dot1dPortOutboundAccessPriority Levi & Harrington Standards Track [Page 5] RFC 4363 Bridge MIB Extensions January 2006 dot1dGarp dot1dPortGarpTable dot1dPortGarpJoinTime .JoinTime dot1dPortGarpLeaveTime .LeaveTime dot1dPortGarpLeaveAllTime .LeaveAllTime dot1dGmrp dot1dPortGmrpTable dot1dPortGmrpStatus .ApplicantAdministrativeControl dot1dPortGmrpFailedRegistrations .FailedRegistrations dot1dPortGmrpLastPduOrigin .OriginatorOfLastPDU dot1dPortRestrictedGroupRegistration Restricted Group Registration (Ref. IEEE 802.1t 10.3.2.3) dot1dTp dot1dTpHCPortTable dot1dTpHCPortInFrames .BridgePort.FramesReceived dot1dTpHCPortOutFrames .ForwardOutBound dot1dTpHCPortInDiscards .DiscardInbound dot1dTpPortOverflowTable dot1dTpPortInOverflowFrames .BridgePort.FramesReceived dot1dTpPortOutOverflowFrames .ForwardOutBound dot1dTpPortInOverflowDiscards .DiscardInbound The following IEEE 802.1D-1998 management objects have not been included in the Bridge MIB for the indicated reasons. IEEE 802.1D-1998 Object Disposition Bridge.StateValue not considered useful Bridge.ApplicantAdministrativeControl not provided per-attribute (e.g., per-VLAN, per-Group). Only per-{device,port,application} control is provided in this MIB. notify group registration failure not considered useful (IEEE 802.1t 14.10.1.2) 3.1.2. Relationship to IEEE 802.1Q Manageable Objects This section contains section number cross-references to manageable objects defined in IEEE 802.1Q-2003 [802.1Q]. These objects have been included in this MIB as they provide a natural fit with the IEEE 802.1D objects with which they are co-located. Levi & Harrington Standards Track [Page 6] RFC 4363 Bridge MIB Extensions January 2006 Extended Bridge MIB Name IEEE 802.1Q-2003 Section and Name dot1dExtBase Bridge dot1dDeviceCapabilities dot1qStaticEntryIndividualPort 5.2 implementation options dot1qIVLCapable dot1qSVLCapable dot1qHybridCapable dot1qConfigurablePvidTagging 12.10.1.1 read bridge vlan config dot1dLocalVlanCapable dot1dPortCapabilitiesTable dot1dPortCapabilities dot1qDot1qTagging 5.2 implementation options dot1qConfigurableAcceptableFrameTypes 5.2 implementation options dot1qIngressFiltering 5.2 implementation options 3.1.3. The dot1dExtBase Subtree This subtree contains the objects that are applicable to all bridges implementing the traffic class and multicast filtering features of IEEE 802.1D-1998 [802.1D]. It includes per-device configuration of Generic Attribute Registration Protocol (GARP) and GARP Multicast Registration Protocol (GMRP) protocols. 3.1.4. The dot1dPriority Subtree This subtree contains the objects for configuring and reporting status of priority-based queuing mechanisms in a bridge. This includes per-port user_priority treatment, mapping of user_priority in frames into internal traffic classes, and outbound user_priority and access_priority. 3.1.5. The dot1dGarp Subtree This subtree contains the objects for configuring and reporting on operation of the Generic Attribute Registration Protocol (GARP). 3.1.6. The dot1dGmrp Subtree This subtree contains the objects for configuring and reporting on operation of the GARP Multicast Registration Protocol (GMRP). Levi & Harrington Standards Track [Page 7] RFC 4363 Bridge MIB Extensions January 2006 3.1.7. The dot1dTpHCPortTable This table extends the dot1dTp subtree from the BRIDGE-MIB [BRIDGE-MIB] and contains the objects for reporting port-bridging statistics for high-capacity network interfaces. 3.1.8. The dot1dTpPortOverflowTable This table extends the dot1dTp subtree from the BRIDGE-MIB [BRIDGE-MIB] and contains the objects for reporting the upper bits of port-bridging statistics for high-capacity network interfaces for when 32-bit counters are inadequate. 3.2. Structure of Virtual Bridge MIB module Objects in this MIB are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees is shown below. Some manageable objects defined in the BRIDGE-MIB [BRIDGE-MIB] need to be indexed differently when they are used in a VLAN bridging environment: these objects are, therefore, effectively duplicated by new objects with different indexing, which are defined in the Virtual Bridge MIB. 3.2.1. Relationship to IEEE 802.1Q Manageable Objects This section contains section-number cross-references to manageable objects defined in clause 12 of IEEE 802.1Q-2003 [802.1Q]. It also details those objects that are not considered necessary in this MIB module. Note: Unlike IEEE 802.1D-1998, IEEE 802.1Q-2003 [802.1Q] did not define exact syntax for a set of managed objects. The following cross-references indicate the section numbering of the descriptions of management operations from clause 12 in the latter document. Virtual Bridge MIB object IEEE 802.1Q-2003 Reference dot1qBase dot1qVlanVersionNumber 12.10.1.1 read bridge vlan config dot1qMaxVlanId 12.10.1.1 read bridge vlan config dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan config dot1qNumVlans dot1qGvrpStatus 12.9.2.1/2 read/set garp applicant controls dot1qTp dot1qFdbTable dot1qFdbId Levi & Harrington Standards Track [Page 8] RFC 4363 Bridge MIB Extensions January 2006 dot1qFdbDynamicCount 12.7.1.1.3 read filtering d/base dot1qTpFdbTable dot1qTpFdbAddress dot1qTpFdbPort dot1qTpFdbStatus dot1qTpGroupTable 12.7.7.1 read filtering entry dot1qTpGroupAddress dot1qTpGroupEgressPorts dot1qTpGroupLearnt dot1qForwardAllTable 12.7.7.1 read filtering entry dot1qForwardAllPorts dot1qForwardAllStaticPorts dot1qForwardAllForbiddenPorts dot1qForwardUnregisteredTable 12.7.7.1 read filtering entry dot1qForwardUnregisteredPorts dot1qForwardUnregisteredStaticPorts dot1qForwardUnregisteredForbiddenPorts dot1qStatic dot1qStaticUnicastTable 12.7.7.1 create/delete/read filtering entry 12.7.6.1 read permanent database dot1qStaticUnicastAddress dot1qStaticUnicastReceivePort dot1qStaticUnicastAllowedToGoTo dot1qStaticUnicastStatus dot1qStaticMulticastTable 12.7.7.1 create/delete/read filtering entry 12.7.6.1 read permanent database dot1qStaticMulticastAddress dot1qStaticMulticastReceivePort dot1qStaticMulticastStaticEgressPorts dot1qStaticMulticastForbiddenEgressPorts dot1qStaticMulticastStatus dot1qVlan dot1qVlanNumDeletes dot1qVlanCurrentTable 12.10.2.1 read vlan configuration 12.10.3.5 read VID to FID allocations 12.10.3.6 read FID allocated to VID 12.10.3.7 read VIDs allocated to FID dot1qVlanTimeMark dot1qVlanIndex dot1qVlanFdbId dot1qVlanCurrentEgressPorts dot1qVlanCurrentUntaggedPorts dot1qVlanStatus Levi & Harrington Standards Track [Page 9] RFC 4363 Bridge MIB Extensions January 2006 dot1qVlanCreationTime dot1qVlanStaticTable 12.7.7.1/2/3 create/delete/read filtering entry 12.7.6.1 read permanent database 12.10.2.2 create vlan config 12.10.2.3 delete vlan config dot1qVlanStaticName 12.4.1.3 set bridge name dot1qVlanStaticEgressPorts dot1qVlanForbiddenEgressPorts dot1qVlanStaticUntaggedPorts dot1qVlanStaticRowStatus dot1qNextFreeLocalVlanIndex dot1qPortVlanTable 12.10.1.1 read bridge vlan configuration dot1qPvid 12.10.1.2 configure PVID values dot1qPortAcceptableFrameTypes 12.10.1.3 configure acceptable frame types parameter dot1qPortIngressFiltering 12.10.1.4 configure ingress filtering parameters dot1qPortGvrpStatus 12.9.2.2 read/set garp applicant controls dot1qPortGvrpFailedRegistrations dot1qPortGvrpLastPduOrigin dot1qPortRestrictedVlanRegistration IEEE 802.1u 11.2.3.2.3 Restricted VLAN Registration dot1qPortVlanStatisticsTable 12.6.1.1 read forwarding port counters dot1qTpVlanPortInFrames dot1qTpVlanPortOutFrames dot1qTpVlanPortInDiscards dot1qTpVlanPortInOverflowFrames dot1qTpVlanPortOutOverflowFrames dot1qTpVlanPortInOverflowDiscards dot1qPortVlanHCStatisticsTable 12.6.1.1 read forwarding port counters dot1qTpVlanPortHCInFrames dot1qTpVlanPortHCOutFrames dot1qTpVlanPortHCInDiscards dot1qLearningConstraintsTable 12.10.3.1/3/4 read/set/delete vlan learning constraints 12.10.3.2 read vlan learning constraints for VID dot1qConstraintVlan dot1qConstraintSet dot1qConstraintType dot1qConstraintStatus dot1qConstraintSetDefault Levi & Harrington Standards Track [Page 10] RFC 4363 Bridge MIB Extensions January 2006 dot1qConstraintTypeDefault dot1vProtocol IEEE 802.1v Reference: dot1vProtocolGroupTable 8.6.4 Protocol Group Database, 8.6.2 Protocol Template dot1vProtocolTemplateFrameType dot1vProtocolTemplateProtocolValue dot1vProtocolGroupId 8.6.3 Protocol Group Identifier dot1vProtocolGroupRowStatus dot1vProtocolPortTable 8.4.4 VID Set for each Port dot1vProtocolPortGroupId dot1vProtocolGroupVid dot1vProtocolPortRowStatus The following IEEE 802.1Q management objects have not been included in the Bridge MIB for the indicated reasons. IEEE 802.1Q-2003 Operation Disposition reset bridge (12.4.1.4) not considered useful reset vlan bridge (12.10.1.5) not considered useful read forwarding port counters (12.6.1.1) discard on error details not considered useful read permanent database (12.7.6.1) permanent database size not considered useful number of static filtering count rows in entries dot1qStaticUnicastTable + dot1qStaticMulticastTable number of static VLAN count rows in registration entries dot1qVlanStaticTable read filtering entry range use GetNext operation. (12.7.7.4) read filtering database (12.7.1.1) filtering database size not considered useful number of dynamic group address count rows applicable to each entries (12.7.1.3) FDB in dot1dTpGroupTable read garp state (12.9.3.1) not considered useful notify vlan registration failure not considered useful (12.10.1.6) Levi & Harrington Standards Track [Page 11] RFC 4363 Bridge MIB Extensions January 2006 notify learning constraint violation (12.10.3.10) not considered useful 3.2.2. The dot1qBase Subtree This subtree contains the objects that are applicable to all bridges implementing IEEE 802.1Q virtual LANs. 3.2.3. The dot1qTp Subtree This subtree contains objects that control the operation and report the status of transparent bridging. This includes management of the dynamic Filtering Databases for both unicast and multicast forwarding. This subtree will be implemented by all bridges that perform destination-address filtering. 3.2.4. The dot1qStatic Subtree This subtree contains objects that control static configuration information for transparent bridging. This includes management of the static entries in the Filtering Databases for both unicast and multicast forwarding. 3.2.5. The dot1qVlan Subtree This subtree contains objects that control configuration and report status of the Virtual LANs known to a bridge. This includes management of the statically configured VLANs as well as reporting VLANs discovered by other means (e.g., GARP VLAN Registration Protocol (GVRP)). It also controls configuration and reports status of per-port objects relating to VLANs and reports traffic statistics. It also provides for management of the VLAN Learning Constraints. 3.3. Textual Conventions Various Working Groups have defined standards-track MIB documents (for example, [RFC2613] and [RFC3318]), that contain objects and Textual Conventions to represent a Virtual Local Area Network Identifier (VLAN-ID) [802.1Q]. New definitions are showing up in various documents (for example, [RFC4323] and [RFC4149]). Unfortunately, the result is a set of different definitions for the same piece of management information. This may lead to confusion and unnecessary complexity. In order to address this situation, three new textual conventions are defined in the Q-BRIDGE-MIB, called VlanIdOrAny, VlanIdOrNone, and VlanIdOrAnyOrNone. These new textual conventions should be (re)used in MIB modules so that they all represent a VLAN-ID in the same way. Levi & Harrington Standards Track [Page 12] RFC 4363 Bridge MIB Extensions January 2006 These textual conventions provide a means to specify MIB objects that refer to a specific VLAN, to any VLAN, or to no VLAN. For an example of how these textual conventions might be used, consider a MIB object, with SYNTAX of VlanIdOrAnyOrNone, that specifies the VLAN on which to accept incoming packets of a particular protocol. Such an object would allow the device to be configured to accept packets of this protocol received with a specific 802.1q tag value, with any 802.1q tag value, or with no 802.1q tag. Note that a MIB object that is defined using one of these textual conventions should clarify the meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause. 3.4. Relationship to Other MIBs As described above, some IEEE 802.1D management objects have not been included in this MIB because they overlap with objects in other MIBs applicable to a bridge implementing this MIB module. 3.4.1. Relationship to the SNMPv2-MIB The SNMPv2-MIB [RFC3418] defines objects that are generally applicable to managed devices. These objects apply to the device as a whole, irrespective of whether bridging is the device's sole functionality or only a subset of the device's functionality. Full support for the 802.1D management objects requires that the SNMPv2-MIB objects sysDescr and sysUpTime be implemented. Note that compliance to the current SNMPv2-MIB module requires additional objects and notifications to be implemented as specified in RFC 3418 [RFC3418]. 3.4.2. Relationship to the IF-MIB The IF-MIB, [RFC2863], requires that any MIB that is an adjunct of the IF-MIB clarify specific areas within the IF-MIB. These areas were intentionally left vague in the IF-MIB in order to avoid over- constraining the MIB, thereby precluding management of certain media-types. The IF-MIB enumerates several areas that a media-specific MIB must clarify. Each of these areas is addressed in a following subsection. The implementor is referred to the IF-MIB in order to understand the general intent of these areas. The IF-MIB [RFC2863] defines managed objects for managing network interfaces. A network interface is considered attached to a 'subnetwork'. (Note that this term is not to be confused with 'subnet', which refers to an addressing partitioning scheme used in the Internet suite of protocols.) The term 'segment' is used in this Levi & Harrington Standards Track [Page 13] RFC 4363 Bridge MIB Extensions January 2006 memo to refer to such a subnetwork, whether it be an Ethernet segment, a 'ring', a WAN link, or even an X.25 virtual circuit. Full support for the 802.1D management objects requires that the IF-MIB objects ifIndex, ifType, ifDescr, ifPhysAddress, and ifLastChange are implemented. Note that compliance to the current IF-MIB module requires additional objects and notifications to be implemented as specified in RFC 2863 [RFC2863]. Implicit in this Extended Bridge MIB is the notion of ports on a bridge. Each of these ports is associated with one interface of the 'interfaces' subtree (one row in ifTable), and, in most situations, each port is associated with a different interface. However, there are situations in which multiple ports are associated with the same interface. An example of such a situation would be several ports each corresponding one-to-one with several X.25 virtual circuits but all on the same interface. Each port is uniquely identified by a port number. A port number has no mandatory relationship to an interface number, but in the simple case a port number will have the same value as the corresponding interface's interface number. Port numbers are in the range (1..dot1dBaseNumPorts). Some entities perform other functionality as well as bridging through the sending and receiving of data on their interfaces. In such situations, only a subset of the data sent/received on an interface is within the domain of the entity's bridging functionality. This subset is considered delineated according to a set of protocols, with some protocols being bridged, and other protocols not being bridged. For example, in an entity that exclusively performed bridging, all protocols would be considered bridged, whereas in an entity that performed IP routing on IP datagrams and only bridged other protocols, only the non-IP data would be considered bridged. Thus, this Extended Bridge MIB (and in particular, its counters) is applicable only to that subset of the data on an entity's interfaces that is sent/received for a protocol being bridged. All such data is sent/received via the ports of the bridge. 3.4.2.1. Layering Model This memo assumes the interpretation of the Interfaces Subtree to be in accordance with the IF-MIB [RFC2863], which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Levi & Harrington Standards Track [Page 14] RFC 4363 Bridge MIB Extensions January 2006 This document does not make any assumption that within an entity, VLANs that are instantiated as an entry in dot1qVlanCurrentTable by either management configuration through dot1qVlanStaticTable or by dynamic means (e.g., through GVRP) are also represented by an entry in ifTable. Where an entity contains higher-layer protocol entities (e.g., IP-layer interfaces that transmit and receive traffic to/from a VLAN), these should be represented in the ifTable as interfaces of type propVirtual(53). Protocol-specific types such as l3ipxvlan(137) should not be used here, since there is no implication that the bridge will perform any protocol filtering before delivering up to these virtual interfaces. 3.4.2.2. ifStackTable In addition, the IF-MIB [RFC2863] defines a table 'ifStackTable' for describing the relationship between logical interfaces within an entity. It is anticipated that implementors will use this table to describe the binding of (for example) IP interfaces to physical ports, although the presence of VLANs makes the representation less than perfect for showing connectivity. The ifStackTable cannot represent the full capability of the IEEE 802.1Q VLAN bridging standard, since that makes a distinction between VLAN bindings on 'ingress' to and 'egress' from a port: these relationships may or may not be symmetrical whereas Interface MIB Evolution assumes a symmetrical binding for transmit and receive. This makes it necessary to define other manageable objects for configuring which ports are members of which VLANs. 3.4.2.3. ifRcvAddressTable This table contains all MAC addresses, unicast, multicast, and broadcast, for which an interface will receive packets and forward them up to a higher-layer entity for local consumption. Note that this does not include addresses for data-link layer control protocols such as Spanning-Tree, GMRP, or GVRP. The format of the address, contained in ifRcvAddressAddress, is the same as for ifPhysAddress. This table does not include unicast or multicast addresses that are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filtering mechanism. Levi & Harrington Standards Track [Page 15] RFC 4363 Bridge MIB Extensions January 2006 3.4.3. Relationship to the BRIDGE-MIB This section defines how objects in the BRIDGE-MIB module [BRIDGE-MIB] should be represented for devices that implement the extensions: some of the old objects are less useful in such devices but must still be implemented for reasons of backwards compatibility. 3.4.3.1. The dot1dBase Subtree This subtree contains objects that are applicable to all types of bridges. Interpretation of this subtree is unchanged. 3.4.3.2. The dot1dStp Subtree This subtree contains the objects that denote the bridge's state with respect to the Spanning Tree Protocol. Interpretation of this subtree is unchanged. 3.4.3.3. The dot1dTp Subtree This subtree contains objects that describe the entity's state with respect to transparent bridging. In a device operating with a single Filtering Database, interpretation of this subtree is unchanged. In a device supporting multiple Filtering Databases, this subtree is interpreted as follows: dot1dTpLearnedEntryDiscards The number of times that *any* of the FDBs became full. dot1dTpAgingTime This applies to all Filtering Databases. dot1dTpFdbTable Report MAC addresses learned on each port, regardless of which Filtering Database they have been learned in. If an address has been learned in multiple databases on a single port, report it only once. If an address has been learned in multiple databases on more than one port, report the entry on any one of the valid ports. Levi & Harrington Standards Track [Page 16] RFC 4363 Bridge MIB Extensions January 2006 dot1dTpPortTable This table is port-based and is not affected by multiple Filtering Databases or multiple VLANs. The counters should include frames received or transmitted for all VLANs. Note that equivalent 64-bit port statistics counters, as well as other objects to represent the upper 32 bits of these counters, are defined in this document for high-capacity network interfaces. These have conformance statements to indicate for which speeds of interface they are required. 3.4.3.4. The dot1dStatic Subtree This optional subtree contains objects that describe the configuration of destination-address filtering. In a device operating with a single Filtering Database, interpretation of this subtree is unchanged. In a device supporting multiple Filtering Databases, this subtree is interpreted as follows: dot1dStaticTable Entries read from this table include all static entries from all of the Filtering Databases. Entries for the same MAC address and receive port in more than one Filtering Database must appear only once, since these are the indices of this table. This table should be implemented as read-only in devices that support multiple Forwarding Databases. Instead, write access should be provided through dot1qStaticUnicastTable and dot1qStaticMulticastTable, as defined in this document. 3.4.3.5. Additions to the BRIDGE-MIB To supplement the BRIDGE-MIB [BRIDGE-MIB], this module contains: (1) support for multiple traffic classes and dynamic multicast filtering as per IEEE 802.1D-1998 [802.1D]. (2) support for bridged Virtual LANs as per IEEE 802.1Q-2003 [802.1Q]. (3) support for 64-bit versions of BRIDGE-MIB [BRIDGE-MIB] port counters. Levi & Harrington Standards Track [Page 17] RFC 4363 Bridge MIB Extensions January 2006 4. Definitions for Extended Bridge MIB P-BRIDGE-MIB DEFINITIONS ::= BEGIN -- ------------------------------------------------------------- -- MIB for IEEE 802.1p devices -- ------------------------------------------------------------- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Counter64 FROM SNMPv2-SMI TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF dot1dTp, dot1dTpPort, dot1dBridge, dot1dBasePortEntry, dot1dBasePort FROM BRIDGE-MIB; pBridgeMIB MODULE-IDENTITY LAST-UPDATED "200601090000Z" ORGANIZATION "IETF Bridge MIB Working Group" CONTACT-INFO "Email: bridge-mib@ietf.org ietfmibs@ops.ietf.org David Levi Postal: Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 865 686 0432 Email: dlevi@nortel.com David Harrington Postal: Effective Software 50 Harding Rd. Portsmouth, NH 03801 USA Phone: +1 603 436 8634 Email: ietfdbh@comcast.net Les Bell Postal: Hemel Hempstead, Herts. HP2 7YU UK Email: elbell@ntlworld.com Vivian Ngai Levi & Harrington Standards Track [Page 18] RFC 4363 Bridge MIB Extensions January 2006 Email: vivian_ngai@acm.org Andrew Smith Postal: Beijing Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089 PRC Fax: +1 415 345 1827 Email: ah_smith@acm.org Paul Langille Postal: Newbridge Networks 5 Corporate Drive Andover, MA 01810 USA Phone: +1 978 691 4665 Email: langille@newbridge.com Anil Rijhsinghani Postal: Accton Technology Corporation 5 Mount Royal Ave Marlboro, MA 01752 USA Phone: Email: anil@accton.com Keith McCloghrie Postal: Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 Email: kzm@cisco.com" DESCRIPTION "The Bridge MIB Extension module for managing Priority and Multicast Filtering, defined by IEEE 802.1D-1998, including Restricted Group Registration defined by IEEE 802.1t-2001. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4363; See the RFC itself for full legal notices." REVISION "200601090000Z" DESCRIPTION "Added dot1dPortRestrictedGroupRegistration. Deprecated pBridgePortGmrpGroup and pBridgeCompliance and added pBridgePortGmrpGroup2 and pBridgeCompliance2." Levi & Harrington Standards Track [Page 19] RFC 4363 Bridge MIB Extensions January 2006 REVISION "199908250000Z" DESCRIPTION "The Bridge MIB Extension module for managing Priority and Multicast Filtering, defined by IEEE 802.1D-1998. Initial version, published as RFC 2674." ::= { dot1dBridge 6 } pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 } -- ------------------------------------------------------------- -- Textual Conventions -- ------------------------------------------------------------- EnabledStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A simple status value for the object." SYNTAX INTEGER { enabled(1), disabled(2) } -- ------------------------------------------------------------- -- subtrees in the P-BRIDGE MIB -- ------------------------------------------------------------- dot1dExtBase OBJECT IDENTIFIER ::= { pBridgeMIBObjects 1 } dot1dPriority OBJECT IDENTIFIER ::= { pBridgeMIBObjects 2 } dot1dGarp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 3 } dot1dGmrp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 4 } -- ------------------------------------------------------------- -- the dot1dExtBase subtree -- ------------------------------------------------------------- dot1dDeviceCapabilities OBJECT-TYPE SYNTAX BITS { dot1dExtendedFilteringServices(0), dot1dTrafficClasses(1), dot1qStaticEntryIndividualPort(2), dot1qIVLCapable(3), dot1qSVLCapable(4), dot1qHybridCapable(5), dot1qConfigurablePvidTagging(6), dot1dLocalVlanCapable(7) } MAX-ACCESS read-only STATUS current DESCRIPTION Levi & Harrington Standards Track [Page 20] RFC 4363 Bridge MIB Extensions January 2006 "Indicates the optional parts of IEEE 802.1D and 802.1Q that are implemented by this device and are manageable through this MIB. Capabilities that are allowed on a per-port basis are indicated in dot1dPortCapabilities. dot1dExtendedFilteringServices(0), -- can perform filtering of -- individual multicast addresses -- controlled by GMRP. dot1dTrafficClasses(1), -- can map user priority to -- multiple traffic classes. dot1qStaticEntryIndividualPort(2), -- dot1qStaticUnicastReceivePort & -- dot1qStaticMulticastReceivePort -- can represent non-zero entries. dot1qIVLCapable(3), -- Independent VLAN Learning (IVL). dot1qSVLCapable(4), -- Shared VLAN Learning (SVL). dot1qHybridCapable(5), -- both IVL & SVL simultaneously. dot1qConfigurablePvidTagging(6), -- whether the implementation -- supports the ability to -- override the default PVID -- setting and its egress status -- (VLAN-Tagged or Untagged) on -- each port. dot1dLocalVlanCapable(7) -- can support multiple local -- bridges, outside of the scope -- of 802.1Q defined VLANs." REFERENCE "ISO/IEC 15802-3 Section 5.2, IEEE 802.1Q/D11 Section 5.2, 12.10.1.1.3/b/2" ::= { dot1dExtBase 1 } dot1dTrafficClassesEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The value true(1) indicates that Traffic Classes are enabled on this bridge. When false(2), the bridge operates with a single priority level for all traffic. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { true } Levi & Harrington Standards Track [Page 21] RFC 4363 Bridge MIB Extensions January 2006 ::= { dot1dExtBase 2 } dot1dGmrpStatus OBJECT-TYPE SYNTAX EnabledStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative status requested by management for GMRP. The value enabled(1) indicates that GMRP should be enabled on this device, in all VLANs, on all ports for which it has not been specifically disabled. When disabled(2), GMRP is disabled, in all VLANs and on all ports, and all GMRP packets will be forwarded transparently. This object affects both Applicant and Registrar state machines. A transition from disabled(2) to enabled(1) will cause a reset of all GMRP state machines on all ports. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { enabled } ::= { dot1dExtBase 3 } -- ------------------------------------------------------------- -- Port Capabilities Table -- ------------------------------------------------------------- dot1dPortCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dPortCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains capabilities information about every port that is associated with this bridge." ::= { dot1dExtBase 4 } dot1dPortCapabilitiesEntry OBJECT-TYPE SYNTAX Dot1dPortCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of capabilities information about this port indexed by dot1dBasePort." AUGMENTS { dot1dBasePortEntry } ::= { dot1dPortCapabilitiesTable 1 } Dot1dPortCapabilitiesEntry ::= SEQUENCE { Levi & Harrington Standards Track [Page 22] RFC 4363 Bridge MIB Extensions January 2006 dot1dPortCapabilities BITS } dot1dPortCapabilities OBJECT-TYPE SYNTAX BITS { dot1qDot1qTagging(0), dot1qConfigurableAcceptableFrameTypes(1), dot1qIngressFiltering(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the parts of IEEE 802.1D and 802.1Q that are optional on a per-port basis, that are implemented by this device, and that are manageable through this MIB. dot1qDot1qTagging(0), -- supports 802.1Q VLAN tagging of -- frames and GVRP. dot1qConfigurableAcceptableFrameTypes(1), -- allows modified values of -- dot1qPortAcceptableFrameTypes. dot1qIngressFiltering(2) -- supports the discarding of any -- frame received on a Port whose -- VLAN classification does not -- include that Port in its Member -- set." REFERENCE "ISO/IEC 15802-3 Section 5.2, IEEE 802.1Q/D11 Section 5.2" ::= { dot1dPortCapabilitiesEntry 1 } -- ------------------------------------------------------------- -- the dot1dPriority subtree -- ------------------------------------------------------------- -- ------------------------------------------------------------- -- Port Priority Table -- ------------------------------------------------------------- dot1dPortPriorityTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dPortPriorityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains information about every port that is associated with this transparent bridge." Levi & Harrington Standards Track [Page 23] RFC 4363 Bridge MIB Extensions January 2006 ::= { dot1dPriority 1 } dot1dPortPriorityEntry OBJECT-TYPE SYNTAX Dot1dPortPriorityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Default User Priorities for each port of a transparent bridge. This is indexed by dot1dBasePort." AUGMENTS { dot1dBasePortEntry } ::= { dot1dPortPriorityTable 1 } Dot1dPortPriorityEntry ::= SEQUENCE { dot1dPortDefaultUserPriority Integer32, dot1dPortNumTrafficClasses Integer32 } dot1dPortDefaultUserPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-write STATUS current DESCRIPTION "The default ingress User Priority for this port. This only has effect on media, such as Ethernet, that do not support native User Priority. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1dPortPriorityEntry 1 } dot1dPortNumTrafficClasses OBJECT-TYPE SYNTAX Integer32 (1..8) MAX-ACCESS read-write STATUS current DESCRIPTION "The number of egress traffic classes supported on this port. This object may optionally be read-only. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1dPortPriorityEntry 2 } -- ------------------------------------------------------------- -- User Priority Regeneration Table -- ------------------------------------------------------------- Levi & Harrington Standards Track [Page 24] RFC 4363 Bridge MIB Extensions January 2006 dot1dUserPriorityRegenTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dUserPriorityRegenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Regenerated User Priorities for each received User Priority on each port of a bridge. The Regenerated User Priority value may be used to index the Traffic Class Table for each input port. This only has effect on media that support native User Priority. The default values for Regenerated User Priorities are the same as the User Priorities." REFERENCE "ISO/IEC 15802-3 Section 6.4" ::= { dot1dPriority 2 } dot1dUserPriorityRegenEntry OBJECT-TYPE SYNTAX Dot1dUserPriorityRegenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A mapping of incoming User Priority to a Regenerated User Priority." INDEX { dot1dBasePort, dot1dUserPriority } ::= { dot1dUserPriorityRegenTable 1 } Dot1dUserPriorityRegenEntry ::= SEQUENCE { dot1dUserPriority Integer32, dot1dRegenUserPriority Integer32 } dot1dUserPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The User Priority for a frame received on this port." ::= { dot1dUserPriorityRegenEntry 1 } dot1dRegenUserPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-write STATUS current DESCRIPTION "The Regenerated User Priority that the incoming User Levi & Harrington Standards Track [Page 25] RFC 4363 Bridge MIB Extensions January 2006 Priority is mapped to for this port. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1dUserPriorityRegenEntry 2 } -- ------------------------------------------------------------- -- Traffic Class Table -- ------------------------------------------------------------- dot1dTrafficClassTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dTrafficClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table mapping evaluated User Priority to Traffic Class, for forwarding by the bridge. Traffic class is a number in the range (0..(dot1dPortNumTrafficClasses-1))." REFERENCE "ISO/IEC 15802-3 Table 7-2" ::= { dot1dPriority 3 } dot1dTrafficClassEntry OBJECT-TYPE SYNTAX Dot1dTrafficClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "User Priority to Traffic Class mapping." INDEX { dot1dBasePort, dot1dTrafficClassPriority } ::= { dot1dTrafficClassTable 1 } Dot1dTrafficClassEntry ::= SEQUENCE { dot1dTrafficClassPriority Integer32, dot1dTrafficClass Integer32 } dot1dTrafficClassPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Priority value determined for the received frame. This value is equivalent to the priority indicated in the tagged frame received, or one of the evaluated priorities, determined according to the media-type. Levi & Harrington Standards Track [Page 26] RFC 4363 Bridge MIB Extensions January 2006 For untagged frames received from Ethernet media, this value is equal to the dot1dPortDefaultUserPriority value for the ingress port. For untagged frames received from non-Ethernet media, this value is equal to the dot1dRegenUserPriority value for the ingress port and media-specific user priority." ::= { dot1dTrafficClassEntry 1 } dot1dTrafficClass OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-write STATUS current DESCRIPTION "The Traffic Class the received frame is mapped to. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1dTrafficClassEntry 2 } -- ------------------------------------------------------------- -- Outbound Access Priority Table -- ------------------------------------------------------------- dot1dPortOutboundAccessPriorityTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dPortOutboundAccessPriorityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table mapping Regenerated User Priority to Outbound Access Priority. This is a fixed mapping for all port types, with two options for 802.5 Token Ring." REFERENCE "ISO/IEC 15802-3 Table 7-3" ::= { dot1dPriority 4 } dot1dPortOutboundAccessPriorityEntry OBJECT-TYPE SYNTAX Dot1dPortOutboundAccessPriorityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Regenerated User Priority to Outbound Access Priority mapping." INDEX { dot1dBasePort, dot1dRegenUserPriority } ::= { dot1dPortOutboundAccessPriorityTable 1 } Dot1dPortOutboundAccessPriorityEntry ::= SEQUENCE { Levi & Harrington Standards Track [Page 27] RFC 4363 Bridge MIB Extensions January 2006 dot1dPortOutboundAccessPriority Integer32 } dot1dPortOutboundAccessPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "The Outbound Access Priority the received frame is mapped to." ::= { dot1dPortOutboundAccessPriorityEntry 1 } -- ------------------------------------------------------------- -- the dot1dGarp subtree -- ------------------------------------------------------------- -- ------------------------------------------------------------- -- The GARP Port Table -- ------------------------------------------------------------- dot1dPortGarpTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dPortGarpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of GARP control information about every bridge port. This is indexed by dot1dBasePort." ::= { dot1dGarp 1 } dot1dPortGarpEntry OBJECT-TYPE SYNTAX Dot1dPortGarpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "GARP control information for a bridge port." AUGMENTS { dot1dBasePortEntry } ::= { dot1dPortGarpTable 1 } Dot1dPortGarpEntry ::= SEQUENCE { dot1dPortGarpJoinTime TimeInterval, dot1dPortGarpLeaveTime TimeInterval, dot1dPortGarpLeaveAllTime TimeInterval } Levi & Harrington Standards Track [Page 28] RFC 4363 Bridge MIB Extensions January 2006 dot1dPortGarpJoinTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "The GARP Join time, in centiseconds. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { 20 } ::= { dot1dPortGarpEntry 1 } dot1dPortGarpLeaveTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "The GARP Leave time, in centiseconds. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { 60 } ::= { dot1dPortGarpEntry 2 } dot1dPortGarpLeaveAllTime OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION "The GARP LeaveAll time, in centiseconds. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { 1000 } ::= { dot1dPortGarpEntry 3 } -- ------------------------------------------------------------- -- The GMRP Port Configuration and Status Table -- ------------------------------------------------------------- dot1dPortGmrpTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dPortGmrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of GMRP control and status information about every bridge port. Augments the dot1dBasePortTable." ::= { dot1dGmrp 1 } Levi & Harrington Standards Track [Page 29] RFC 4363 Bridge MIB Extensions January 2006 dot1dPortGmrpEntry OBJECT-TYPE SYNTAX Dot1dPortGmrpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "GMRP control and status information for a bridge port." AUGMENTS { dot1dBasePortEntry } ::= { dot1dPortGmrpTable 1 } Dot1dPortGmrpEntry ::= SEQUENCE { dot1dPortGmrpStatus EnabledStatus, dot1dPortGmrpFailedRegistrations Counter32, dot1dPortGmrpLastPduOrigin MacAddress, dot1dPortRestrictedGroupRegistration TruthValue } dot1dPortGmrpStatus OBJECT-TYPE SYNTAX EnabledStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative state of GMRP operation on this port. The value enabled(1) indicates that GMRP is enabled on this port in all VLANs as long as dot1dGmrpStatus is also enabled(1). A value of disabled(2) indicates that GMRP is disabled on this port in all VLANs: any GMRP packets received will be silently discarded, and no GMRP registrations will be propagated from other ports. Setting this to a value of enabled(1) will be stored by the agent but will only take effect on the GMRP protocol operation if dot1dGmrpStatus also indicates the value enabled(1). This object affects all GMRP Applicant and Registrar state machines on this port. A transition from disabled(2) to enabled(1) will cause a reset of all GMRP state machines on this port. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { enabled } ::= { dot1dPortGmrpEntry 1 } dot1dPortGmrpFailedRegistrations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Levi & Harrington Standards Track [Page 30] RFC 4363 Bridge MIB Extensions January 2006 STATUS current DESCRIPTION "The total number of failed GMRP registrations, for any reason, in all VLANs, on this port." ::= { dot1dPortGmrpEntry 2 } dot1dPortGmrpLastPduOrigin OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Source MAC Address of the last GMRP message received on this port." ::= { dot1dPortGmrpEntry 3 } dot1dPortRestrictedGroupRegistration OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The state of Restricted Group Registration on this port. If the value of this control is true(1), then creation of a new dynamic entry is permitted only if there is a Static Filtering Entry for the VLAN concerned, in which the Registrar Administrative Control value is Normal Registration. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1t clause 10.3.2.3, 14.10.1.3." DEFVAL { false } ::= { dot1dPortGmrpEntry 4 } -- ------------------------------------------------------------- -- High-Capacity Port Table for Transparent Bridges -- ------------------------------------------------------------- dot1dTpHCPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dTpHCPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains information about every high- capacity port that is associated with this transparent bridge." ::= { dot1dTp 5 } Levi & Harrington Standards Track [Page 31] RFC 4363 Bridge MIB Extensions January 2006 dot1dTpHCPortEntry OBJECT-TYPE SYNTAX Dot1dTpHCPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics information for each high-capacity port of a transparent bridge." INDEX { dot1dTpPort } ::= { dot1dTpHCPortTable 1 } Dot1dTpHCPortEntry ::= SEQUENCE { dot1dTpHCPortInFrames Counter64, dot1dTpHCPortOutFrames Counter64, dot1dTpHCPortInDiscards Counter64 } dot1dTpHCPortInFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been received by this port from its segment. Note that a frame received on the interface corresponding to this port is only counted by this object if and only if it is for a protocol being processed by the local bridging function, including bridge management frames." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1dTpHCPortEntry 1 } dot1dTpHCPortOutFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been transmitted by this port to its segment. Note that a frame transmitted on the interface corresponding to this port is only counted by this object if and only if it is for a protocol being processed by the local bridging function, including bridge management frames." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" Levi & Harrington Standards Track [Page 32] RFC 4363 Bridge MIB Extensions January 2006 ::= { dot1dTpHCPortEntry 2 } dot1dTpHCPortInDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of valid frames that have been received by this port from its segment that were discarded (i.e., filtered) by the Forwarding Process." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1dTpHCPortEntry 3 } -- ---------------------------------------------------- -- Upper part of High-Capacity Port Table for Transparent Bridges -- ---------------------------------------------------- dot1dTpPortOverflowTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dTpPortOverflowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains the most-significant bits of statistics counters for ports that are associated with this transparent bridge that are on high-capacity interfaces, as defined in the conformance clauses for this table. This table is provided as a way to read 64-bit counters for agents that support only SNMPv1. Note that the reporting of most-significant and least-significant counter bits separately runs the risk of missing an overflow of the lower bits in the interval between sampling. The manager must be aware of this possibility, even within the same varbindlist, when interpreting the results of a request or asynchronous notification." ::= { dot1dTp 6 } dot1dTpPortOverflowEntry OBJECT-TYPE SYNTAX Dot1dTpPortOverflowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The most significant bits of statistics counters for a high- capacity interface of a transparent bridge. Each object is associated with a corresponding object in dot1dTpPortTable that indicates the least significant bits of the counter." INDEX { dot1dTpPort } Levi & Harrington Standards Track [Page 33] RFC 4363 Bridge MIB Extensions January 2006 ::= { dot1dTpPortOverflowTable 1 } Dot1dTpPortOverflowEntry ::= SEQUENCE { dot1dTpPortInOverflowFrames Counter32, dot1dTpPortOutOverflowFrames Counter32, dot1dTpPortInOverflowDiscards Counter32 } dot1dTpPortInOverflowFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated dot1dTpPortInFrames counter has overflowed." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1dTpPortOverflowEntry 1 } dot1dTpPortOutOverflowFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated dot1dTpPortOutFrames counter has overflowed." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1dTpPortOverflowEntry 2 } dot1dTpPortInOverflowDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated dot1dTpPortInDiscards counter has overflowed." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1dTpPortOverflowEntry 3 } -- ------------------------------------------------------------- -- IEEE 802.1p MIB - Conformance Information -- ------------------------------------------------------------- Levi & Harrington Standards Track [Page 34] RFC 4363 Bridge MIB Extensions January 2006 pBridgeConformance OBJECT IDENTIFIER ::= { pBridgeMIB 2 } pBridgeGroups OBJECT IDENTIFIER ::= { pBridgeConformance 1 } pBridgeCompliances OBJECT IDENTIFIER ::= { pBridgeConformance 2 } -- ------------------------------------------------------------- -- units of conformance -- ------------------------------------------------------------- pBridgeExtCapGroup OBJECT-GROUP OBJECTS { dot1dDeviceCapabilities, dot1dPortCapabilities } STATUS current DESCRIPTION "A collection of objects indicating the optional capabilities of the device." ::= { pBridgeGroups 1 } pBridgeDeviceGmrpGroup OBJECT-GROUP OBJECTS { dot1dGmrpStatus } STATUS current DESCRIPTION "A collection of objects providing device-level control for the Multicast Filtering extended bridge services." ::= { pBridgeGroups 2 } pBridgeDevicePriorityGroup OBJECT-GROUP OBJECTS { dot1dTrafficClassesEnabled } STATUS current DESCRIPTION "A collection of objects providing device-level control for the Priority services." ::= { pBridgeGroups 3 } pBridgeDefaultPriorityGroup OBJECT-GROUP OBJECTS { dot1dPortDefaultUserPriority } STATUS current DESCRIPTION Levi & Harrington Standards Track [Page 35] RFC 4363 Bridge MIB Extensions January 2006 "A collection of objects defining the User Priority applicable to each port for media that do not support native User Priority." ::= { pBridgeGroups 4 } pBridgeRegenPriorityGroup OBJECT-GROUP OBJECTS { dot1dRegenUserPriority } STATUS current DESCRIPTION "A collection of objects defining the User Priorities applicable to each port for media that support native User Priority." ::= { pBridgeGroups 5 } pBridgePriorityGroup OBJECT-GROUP OBJECTS { dot1dPortNumTrafficClasses, dot1dTrafficClass } STATUS current DESCRIPTION "A collection of objects defining the traffic classes within a bridge for each evaluated User Priority." ::= { pBridgeGroups 6 } pBridgeAccessPriorityGroup OBJECT-GROUP OBJECTS { dot1dPortOutboundAccessPriority } STATUS current DESCRIPTION "A collection of objects defining the media-dependent outbound access level for each priority." ::= { pBridgeGroups 7 } pBridgePortGarpGroup OBJECT-GROUP OBJECTS { dot1dPortGarpJoinTime, dot1dPortGarpLeaveTime, dot1dPortGarpLeaveAllTime } STATUS current DESCRIPTION "A collection of objects providing port level control and status information for GARP operation." ::= { pBridgeGroups 8 } Levi & Harrington Standards Track [Page 36] RFC 4363 Bridge MIB Extensions January 2006 pBridgePortGmrpGroup OBJECT-GROUP OBJECTS { dot1dPortGmrpStatus, dot1dPortGmrpFailedRegistrations, dot1dPortGmrpLastPduOrigin } STATUS deprecated DESCRIPTION "A collection of objects providing port level control and status information for GMRP operation." ::= { pBridgeGroups 9 } pBridgeHCPortGroup OBJECT-GROUP OBJECTS { dot1dTpHCPortInFrames, dot1dTpHCPortOutFrames, dot1dTpHCPortInDiscards } STATUS current DESCRIPTION "A collection of objects providing 64-bit statistics counters for high-capacity bridge ports." ::= { pBridgeGroups 10 } pBridgePortOverflowGroup OBJECT-GROUP OBJECTS { dot1dTpPortInOverflowFrames, dot1dTpPortOutOverflowFrames, dot1dTpPortInOverflowDiscards } STATUS current DESCRIPTION "A collection of objects providing overflow statistics counters for high-capacity bridge ports." ::= { pBridgeGroups 11 } pBridgePortGmrpGroup2 OBJECT-GROUP OBJECTS { dot1dPortGmrpStatus, dot1dPortGmrpFailedRegistrations, dot1dPortGmrpLastPduOrigin, dot1dPortRestrictedGroupRegistration } STATUS current DESCRIPTION "A collection of objects providing port level control and status information for GMRP operation." ::= { pBridgeGroups 12 } Levi & Harrington Standards Track [Page 37] RFC 4363 Bridge MIB Extensions January 2006 -- ------------------------------------------------------------- -- compliance statements -- ------------------------------------------------------------- pBridgeCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for device support of Priority and Multicast Filtering extended bridging services." MODULE MANDATORY-GROUPS { pBridgeExtCapGroup } GROUP pBridgeDeviceGmrpGroup DESCRIPTION "This group is mandatory for devices supporting the GMRP application, defined by IEEE 802.1D Extended Filtering Services." GROUP pBridgeDevicePriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by IEEE 802.1D." GROUP pBridgeDefaultPriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by the extended bridge services with media types, such as Ethernet, that do not support native User Priority." GROUP pBridgeRegenPriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by IEEE 802.1D and that have interface media types that support native User Priority, e.g., IEEE 802.5." GROUP pBridgePriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by IEEE 802.1D." GROUP pBridgeAccessPriorityGroup DESCRIPTION "This group is optional and is relevant only for devices supporting the priority forwarding operations defined by Levi & Harrington Standards Track [Page 38] RFC 4363 Bridge MIB Extensions January 2006 IEEE 802.1D and that have interface media types that support native Access Priority, e.g., IEEE 802.5." GROUP pBridgePortGarpGroup DESCRIPTION "This group is mandatory for devices supporting any of the GARP applications: e.g., GMRP, defined by the extended filtering services of 802.1D; or GVRP, defined by 802.1Q (refer to the Q-BRIDGE-MIB for conformance statements for GVRP)." GROUP pBridgePortGmrpGroup DESCRIPTION "This group is mandatory for devices supporting the GMRP application, as defined by IEEE 802.1D Extended Filtering Services." GROUP pBridgeHCPortGroup DESCRIPTION "Support for this group in a device is mandatory for those bridge ports that map to network interfaces that have the value of the corresponding instance of ifSpeed greater than 650,000,000 bits/second." GROUP pBridgePortOverflowGroup DESCRIPTION "Support for this group in a device is mandatory for those bridge ports that map to network interfaces that have the value of the corresponding instance of ifSpeed greater than 650,000,000 bits/second." OBJECT dot1dPortNumTrafficClasses MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dot1dTrafficClass MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dot1dRegenUserPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { pBridgeCompliances 1 } Levi & Harrington Standards Track [Page 39] RFC 4363 Bridge MIB Extensions January 2006 pBridgeCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for device support of Priority and Multicast Filtering extended bridging services." MODULE MANDATORY-GROUPS { pBridgeExtCapGroup } GROUP pBridgeDeviceGmrpGroup DESCRIPTION "This group is mandatory for devices supporting the GMRP application, defined by IEEE 802.1D Extended Filtering Services." GROUP pBridgeDevicePriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by IEEE 802.1D." GROUP pBridgeDefaultPriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by the extended bridge services with media types, such as Ethernet, that do not support native User Priority." GROUP pBridgeRegenPriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by IEEE 802.1D and that have interface media types that support native User Priority, e.g., IEEE 802.5." GROUP pBridgePriorityGroup DESCRIPTION "This group is mandatory only for devices supporting the priority forwarding operations defined by IEEE 802.1D." GROUP pBridgeAccessPriorityGroup DESCRIPTION "This group is optional and is relevant only for devices supporting the priority forwarding operations defined by IEEE 802.1D and that have interface media types that support native Access Priority, e.g., IEEE 802.5." GROUP pBridgePortGarpGroup Levi & Harrington Standards Track [Page 40] RFC 4363 Bridge MIB Extensions January 2006 DESCRIPTION "This group is mandatory for devices supporting any of the GARP applications: e.g., GMRP, defined by the extended filtering services of 802.1D; or GVRP, defined by 802.1Q (refer to the Q-BRIDGE-MIB for conformance statements for GVRP)." GROUP pBridgePortGmrpGroup2 DESCRIPTION "This group is mandatory for devices supporting the GMRP application, as defined by IEEE 802.1D Extended Filtering Services." GROUP pBridgeHCPortGroup DESCRIPTION "Support for this group in a device is mandatory for those bridge ports that map to network interfaces that have the value of the corresponding instance of ifSpeed greater than 650,000,000 bits/second." GROUP pBridgePortOverflowGroup DESCRIPTION "Support for this group in a device is mandatory for those bridge ports that map to network interfaces that have the value of the corresponding instance of ifSpeed greater than 650,000,000 bits/second." OBJECT dot1dPortNumTrafficClasses MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dot1dTrafficClass MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT dot1dRegenUserPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { pBridgeCompliances 2 } END Levi & Harrington Standards Track [Page 41] RFC 4363 Bridge MIB Extensions January 2006 5. Definitions for Virtual Bridge MIB Q-BRIDGE-MIB DEFINITIONS ::= BEGIN -- ------------------------------------------------------------- -- MIB for IEEE 802.1Q Devices -- ------------------------------------------------------------- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64, Unsigned32, TimeTicks, Integer32 FROM SNMPv2-SMI RowStatus, TruthValue, TEXTUAL-CONVENTION, MacAddress FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF dot1dBridge, dot1dBasePortEntry, dot1dBasePort FROM BRIDGE-MIB EnabledStatus FROM P-BRIDGE-MIB TimeFilter FROM RMON2-MIB; qBridgeMIB MODULE-IDENTITY LAST-UPDATED "200601090000Z" ORGANIZATION "IETF Bridge MIB Working Group" CONTACT-INFO "Email: Bridge-mib@ietf.org ietfmibs@ops.ietf.org David Levi Postal: Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 865 686 0432 Email: dlevi@nortel.com David Harrington Postal: Effective Software 50 Harding Rd. Portsmouth, NH 03801 USA Phone: +1 603 436 8634 Email: ietfdbh@comcast.net Levi & Harrington Standards Track [Page 42] RFC 4363 Bridge MIB Extensions January 2006 Les Bell Postal: Hemel Hempstead, Herts. HP2 7YU UK Email: elbell@ntlworld.com Andrew Smith Postal: Beijing Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089 PRC Fax: +1 415 345 1827 Email: ah_smith@acm.org Paul Langille Postal: Newbridge Networks 5 Corporate Drive Andover, MA 01810 USA Phone: +1 978 691 4665 Email: langille@newbridge.com Anil Rijhsinghani Postal: Accton Technology Corporation 5 Mount Royal Ave Marlboro, MA 01752 USA Phone: Email: anil@accton.com Keith McCloghrie Postal: Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 Email: kzm@cisco.com" DESCRIPTION "The VLAN Bridge MIB module for managing Virtual Bridged Local Area Networks, as defined by IEEE 802.1Q-2003, including Restricted Vlan Registration defined by IEEE 802.1u-2001 and Vlan Classification defined by IEEE 802.1v-2001. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4363; See the RFC itself for full legal notices." REVISION "200601090000Z" Levi & Harrington Standards Track [Page 43] RFC 4363 Bridge MIB Extensions January 2006 DESCRIPTION "Added Vlan TEXTUAL-CONVENTIONs, dot1qPortRestrictedVlanRegistration, dot1vProtocol subtree, qBridgeClassificationDeviceGroup, qBridgePortGroup2, qBridgeClassificationPortGroup, and qBridgeCompliance2. Clarified dot1qForwardAllStaticPorts, qPortAcceptableFrameTypes, and qBridgeCompliance. Deprecated qBridgePortGroup and qBridgeCompliance." REVISION "199908250000Z" DESCRIPTION "The VLAN Bridge MIB module for managing Virtual Bridged Local Area Networks, as defined by IEEE 802.1Q-1998. Initial version, published as RFC 2674." ::= { dot1dBridge 7 } qBridgeMIBObjects OBJECT IDENTIFIER ::= { qBridgeMIB 1 } -- ------------------------------------------------------------- -- Textual Conventions -- ------------------------------------------------------------- PortList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each octet within this value specifies a set of eight ports, with the first octet specifying ports 1 through 8, the second octet specifying ports 9 through 16, etc. Within each octet, the most significant bit represents the lowest numbered port, and the least significant bit represents the highest numbered port. Thus, each port of the bridge is represented by a single bit within the value of this object. If that bit has a value of '1', then that port is included in the set of ports; the port is not included if its bit has a value of '0'." SYNTAX OCTET STRING VlanIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A value used to index per-VLAN tables: values of 0 and 4095 are not permitted. If the value is between 1 and 4094 inclusive, it represents an IEEE 802.1Q VLAN-ID with global scope within a given bridged domain (see VlanId textual convention). If the value is greater than 4095, Levi & Harrington Standards Track [Page 44] RFC 4363 Bridge MIB Extensions January 2006 then it represents a VLAN with scope local to the particular agent, i.e., one without a global VLAN-ID assigned to it. Such VLANs are outside the scope of IEEE 802.1Q, but it is convenient to be able to manage them in the same way using this MIB." SYNTAX Unsigned32 VlanId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN-ID that uniquely identifies a VLAN. This is the 12-bit VLAN-ID used in the VLAN Tag header. The range is defined by the REFERENCEd specification." REFERENCE "IEEE Std 802.1Q 2003 Edition, Virtual Bridged Local Area Networks." SYNTAX Integer32 (1..4094) VlanIdOrAny ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN-ID that uniquely identifies a specific VLAN, or any VLAN. The special value of 4095 is used to indicate a wildcard, i.e., any VLAN. This can be used in any situation where an object or table entry must refer either to a specific VLAN or to any VLAN. Note that a MIB object that is defined using this TEXTUAL-CONVENTION should clarify the meaning of 'any VLAN' (i.e., the special value 4095)." SYNTAX Integer32 (1..4094 | 4095) VlanIdOrNone ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN-ID that uniquely identifies a specific VLAN, or no VLAN. The special value of zero is used to indicate that no VLAN-ID is present or used. This can be used in any situation where an object or a table entry must refer either to a specific VLAN, or to no VLAN. Note that a MIB object that is defined using this TEXTUAL-CONVENTION should clarify the meaning of 'no VLAN' (i.e., the special value 0)." SYNTAX Integer32 (0 | 1..4094) Levi & Harrington Standards Track [Page 45] RFC 4363 Bridge MIB Extensions January 2006 VlanIdOrAnyOrNone ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN-ID that uniquely identifies a specific VLAN, any VLAN, or no VLAN. The special values 0 and 4095 have the same meaning as described in the VlanIdOrAny and VlanIdOrNone TEXTUAL-CONVENTIONs. Note that a MIB object that is defined using this TEXTUAL-CONVENTION should clarify the meaning of 'any VLAN' and 'no VLAN' (i.e., the special values 0 and 4095)." SYNTAX Integer32 (0 | 1..4094 | 4095) -- ------------------------------------------------------------- -- subtrees in the Q-BRIDGE MIB -- ------------------------------------------------------------- dot1qBase OBJECT IDENTIFIER ::= { qBridgeMIBObjects 1 } dot1qTp OBJECT IDENTIFIER ::= { qBridgeMIBObjects 2 } dot1qStatic OBJECT IDENTIFIER ::= { qBridgeMIBObjects 3 } dot1qVlan OBJECT IDENTIFIER ::= { qBridgeMIBObjects 4 } dot1vProtocol OBJECT IDENTIFIER ::= { qBridgeMIBObjects 5 } -- ------------------------------------------------------------- -- dot1qBase subtree -- ------------------------------------------------------------- dot1qVlanVersionNumber OBJECT-TYPE SYNTAX INTEGER { version1(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of IEEE 802.1Q that this device supports." REFERENCE "IEEE 802.1Q/D11 Section 12.10.1.1" ::= { dot1qBase 1 } dot1qMaxVlanId OBJECT-TYPE SYNTAX VlanId MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum IEEE 802.1Q VLAN-ID that this device Levi & Harrington Standards Track [Page 46] RFC 4363 Bridge MIB Extensions January 2006 supports." REFERENCE "IEEE 802.1Q/D11 Section 9.3.2.3" ::= { dot1qBase 2 } dot1qMaxSupportedVlans OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of IEEE 802.1Q VLANs that this device supports." REFERENCE "IEEE 802.1Q/D11 Section 12.10.1.1" ::= { dot1qBase 3 } dot1qNumVlans OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of IEEE 802.1Q VLANs that are configured in this device." REFERENCE "IEEE 802.1Q/D11 Section 12.7.1.1" ::= { dot1qBase 4 } dot1qGvrpStatus OBJECT-TYPE SYNTAX EnabledStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative status requested by management for GVRP. The value enabled(1) indicates that GVRP should be enabled on this device, on all ports for which it has not been specifically disabled. When disabled(2), GVRP is disabled on all ports, and all GVRP packets will be forwarded transparently. This object affects all GVRP Applicant and Registrar state machines. A transition from disabled(2) to enabled(1) will cause a reset of all GVRP state machines on all ports. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { enabled } ::= { dot1qBase 5 } -- ------------------------------------------------------------- Levi & Harrington Standards Track [Page 47] RFC 4363 Bridge MIB Extensions January 2006 -- the dot1qTp subtree -- ------------------------------------------------------------- -- ------------------------------------------------------------- -- the current Filtering Database Table -- ------------------------------------------------------------- dot1qFdbTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qFdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains configuration and control information for each Filtering Database currently operating on this device. Entries in this table appear automatically when VLANs are assigned FDB IDs in the dot1qVlanCurrentTable." ::= { dot1qTp 1 } dot1qFdbEntry OBJECT-TYPE SYNTAX Dot1qFdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a specific Filtering Database." INDEX { dot1qFdbId } ::= { dot1qFdbTable 1 } Dot1qFdbEntry ::= SEQUENCE { dot1qFdbId Unsigned32, dot1qFdbDynamicCount Counter32 } dot1qFdbId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identity of this Filtering Database." ::= { dot1qFdbEntry 1 } dot1qFdbDynamicCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Levi & Harrington Standards Track [Page 48] RFC 4363 Bridge MIB Extensions January 2006 DESCRIPTION "The current number of dynamic entries in this Filtering Database." REFERENCE "IEEE 802.1Q/D11 Section 12.7.1.1.3" ::= { dot1qFdbEntry 2 } -- ------------------------------------------------------------- -- Multiple Forwarding Databases for 802.1Q Transparent Devices -- This table is an alternative to the dot1dTpFdbTable, -- previously defined for 802.1D devices that only support a -- single Forwarding Database. -- ------------------------------------------------------------- dot1qTpFdbTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qTpFdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains information about unicast entries for which the device has forwarding and/or filtering information. This information is used by the transparent bridging function in determining how to propagate a received frame." REFERENCE "IEEE 802.1Q/D11 Section 12.7.7" ::= { dot1qTp 2 } dot1qTpFdbEntry OBJECT-TYPE SYNTAX Dot1qTpFdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a specific unicast MAC address for which the device has some forwarding and/or filtering information." INDEX { dot1qFdbId, dot1qTpFdbAddress } ::= { dot1qTpFdbTable 1 } Dot1qTpFdbEntry ::= SEQUENCE { dot1qTpFdbAddress MacAddress, dot1qTpFdbPort Integer32, dot1qTpFdbStatus INTEGER } Levi & Harrington Standards Track [Page 49] RFC 4363 Bridge MIB Extensions January 2006 dot1qTpFdbAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unicast MAC address for which the device has forwarding and/or filtering information." ::= { dot1qTpFdbEntry 1 } dot1qTpFdbPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Either the value '0', or the port number of the port on which a frame having a source address equal to the value of the corresponding instance of dot1qTpFdbAddress has been seen. A value of '0' indicates that the port number has not been learned but that the device does have some forwarding/filtering information about this address (e.g., in the dot1qStaticUnicastTable). Implementors are encouraged to assign the port value to this object whenever it is learned, even for addresses for which the corresponding value of dot1qTpFdbStatus is not learned(3)." ::= { dot1qTpFdbEntry 2 } dot1qTpFdbStatus OBJECT-TYPE SYNTAX INTEGER { other(1), invalid(2), learned(3), self(4), mgmt(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The status of this entry. The meanings of the values are: other(1) - none of the following. This may include the case where some other MIB object (not the corresponding instance of dot1qTpFdbPort, nor an entry in the dot1qStaticUnicastTable) is being used to determine if and how frames addressed to the value of the corresponding instance of dot1qTpFdbAddress are being forwarded. invalid(2) - this entry is no longer valid (e.g., it Levi & Harrington Standards Track [Page 50] RFC 4363 Bridge MIB Extensions January 2006 was learned but has since aged out), but has not yet been flushed from the table. learned(3) - the value of the corresponding instance of dot1qTpFdbPort was learned and is being used. self(4) - the value of the corresponding instance of dot1qTpFdbAddress represents one of the device's addresses. The corresponding instance of dot1qTpFdbPort indicates which of the device's ports has this address. mgmt(5) - the value of the corresponding instance of dot1qTpFdbAddress is also the value of an existing instance of dot1qStaticAddress." ::= { dot1qTpFdbEntry 3 } -- ------------------------------------------------------------- -- Dynamic Group Registration Table -- ------------------------------------------------------------- dot1qTpGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qTpGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing filtering information for VLANs configured into the bridge by (local or network) management, or learned dynamically, specifying the set of ports to which frames received on a VLAN for this FDB and containing a specific Group destination address are allowed to be forwarded." ::= { dot1qTp 3 } dot1qTpGroupEntry OBJECT-TYPE SYNTAX Dot1qTpGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Filtering information configured into the bridge by management, or learned dynamically, specifying the set of ports to which frames received on a VLAN and containing a specific Group destination address are allowed to be forwarded. The subset of these ports learned dynamically is also provided." INDEX { dot1qVlanIndex, dot1qTpGroupAddress } ::= { dot1qTpGroupTable 1 } Dot1qTpGroupEntry ::= SEQUENCE { dot1qTpGroupAddress Levi & Harrington Standards Track [Page 51] RFC 4363 Bridge MIB Extensions January 2006 MacAddress, dot1qTpGroupEgressPorts PortList, dot1qTpGroupLearnt PortList } dot1qTpGroupAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination Group MAC address in a frame to which this entry's filtering information applies." ::= { dot1qTpGroupEntry 1 } dot1qTpGroupEgressPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION "The complete set of ports, in this VLAN, to which frames destined for this Group MAC address are currently being explicitly forwarded. This does not include ports for which this address is only implicitly forwarded, in the dot1qForwardAllPorts list." ::= { dot1qTpGroupEntry 2 } dot1qTpGroupLearnt OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION "The subset of ports in dot1qTpGroupEgressPorts that were learned by GMRP or some other dynamic mechanism, in this Filtering database." ::= { dot1qTpGroupEntry 3 } -- ------------------------------------------------------------- -- Service Requirements subtree -- ------------------------------------------------------------- dot1qForwardAllTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qForwardAllEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing forwarding information for each Levi & Harrington Standards Track [Page 52] RFC 4363 Bridge MIB Extensions January 2006 VLAN, specifying the set of ports to which forwarding of all multicasts applies, configured statically by management or dynamically by GMRP. An entry appears in this table for all VLANs that are currently instantiated." REFERENCE "IEEE 802.1Q/D11 Section 12.7.2, 12.7.7" ::= { dot1qTp 4 } dot1qForwardAllEntry OBJECT-TYPE SYNTAX Dot1qForwardAllEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Forwarding information for a VLAN, specifying the set of ports to which all multicasts should be forwarded, configured statically by management or dynamically by GMRP." INDEX { dot1qVlanIndex } ::= { dot1qForwardAllTable 1 } Dot1qForwardAllEntry ::= SEQUENCE { dot1qForwardAllPorts PortList, dot1qForwardAllStaticPorts PortList, dot1qForwardAllForbiddenPorts PortList } dot1qForwardAllPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION "The complete set of ports in this VLAN to which all multicast group-addressed frames are to be forwarded. This includes ports for which this need has been determined dynamically by GMRP, or configured statically by management." ::= { dot1qForwardAllEntry 1 } dot1qForwardAllStaticPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-write STATUS current DESCRIPTION Levi & Harrington Standards Track [Page 53] RFC 4363 Bridge MIB Extensions January 2006 "The set of ports configured by management in this VLAN to which all multicast group-addressed frames are to be forwarded. Ports entered in this list will also appear in the complete set shown by dot1qForwardAllPorts. This value will be restored after the device is reset. This only applies to ports that are members of the VLAN, defined by dot1qVlanCurrentEgressPorts. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardAllForbiddenPorts. The default value is a string of ones of appropriate length, to indicate the standard behaviour of using basic filtering services, i.e., forward all multicasts to all ports. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1qForwardAllEntry 2 } dot1qForwardAllForbiddenPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-write STATUS current DESCRIPTION "The set of ports configured by management in this VLAN for which the Service Requirement attribute Forward All Multicast Groups may not be dynamically registered by GMRP. This value will be restored after the device is reset. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardAllStaticPorts. The default value is a string of zeros of appropriate length. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1qForwardAllEntry 3 } dot1qForwardUnregisteredTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qForwardUnregisteredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing forwarding information for each VLAN, specifying the set of ports to which forwarding of multicast group-addressed frames for which no more specific forwarding information applies. This is configured statically by management and determined dynamically by GMRP. An entry appears in this table for all VLANs that are currently instantiated." Levi & Harrington Standards Track [Page 54] RFC 4363 Bridge MIB Extensions January 2006 REFERENCE "IEEE 802.1Q/D11 Section 12.7.2, 12.7.7" ::= { dot1qTp 5 } dot1qForwardUnregisteredEntry OBJECT-TYPE SYNTAX Dot1qForwardUnregisteredEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Forwarding information for a VLAN, specifying the set of ports to which all multicasts for which there is no more specific forwarding information shall be forwarded. This is configured statically by management or dynamically by GMRP." INDEX { dot1qVlanIndex } ::= { dot1qForwardUnregisteredTable 1 } Dot1qForwardUnregisteredEntry ::= SEQUENCE { dot1qForwardUnregisteredPorts PortList, dot1qForwardUnregisteredStaticPorts PortList, dot1qForwardUnregisteredForbiddenPorts PortList } dot1qForwardUnregisteredPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION "The complete set of ports in this VLAN to which multicast group-addressed frames for which there is no more specific forwarding information will be forwarded. This includes ports for which this need has been determined dynamically by GMRP, or configured statically by management." ::= { dot1qForwardUnregisteredEntry 1 } dot1qForwardUnregisteredStaticPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-write STATUS current DESCRIPTION "The set of ports configured by management, in this VLAN, to which multicast group-addressed frames for which there is no more specific forwarding information Levi & Harrington Standards Track [Page 55] RFC 4363 Bridge MIB Extensions January 2006 are to be forwarded. Ports entered in this list will also appear in the complete set shown by dot1qForwardUnregisteredPorts. This value will be restored after the device is reset. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardUnregisteredForbiddenPorts. The default value is a string of zeros of appropriate length, although this has no effect with the default value of dot1qForwardAllStaticPorts. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1qForwardUnregisteredEntry 2 } dot1qForwardUnregisteredForbiddenPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-write STATUS current DESCRIPTION "The set of ports configured by management in this VLAN for which the Service Requirement attribute Forward Unregistered Multicast Groups may not be dynamically registered by GMRP. This value will be restored after the device is reset. A port may not be added in this set if it is already a member of the set of ports in dot1qForwardUnregisteredStaticPorts. The default value is a string of zeros of appropriate length. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1qForwardUnregisteredEntry 3 } -- ------------------------------------------------------------- -- The Static (Destination-Address Filtering) Database -- ------------------------------------------------------------- dot1qStaticUnicastTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qStaticUnicastEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing filtering information for Unicast MAC addresses for each Filtering Database, configured into the device by (local or network) management specifying the set of ports to which frames received from specific ports and containing specific unicast destination addresses are allowed to be forwarded. A value of zero in this table (as the port number from Levi & Harrington Standards Track [Page 56] RFC 4363 Bridge MIB Extensions January 2006 which frames with a specific destination address are received) is used to specify all ports for which there is no specific entry in this table for that particular destination address. Entries are valid for unicast addresses only." REFERENCE "IEEE 802.1Q/D11 Section 12.7.7, ISO/IEC 15802-3 Section 7.9.1" ::= { dot1qStatic 1 } dot1qStaticUnicastEntry OBJECT-TYPE SYNTAX Dot1qStaticUnicastEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Filtering information configured into the device by (local or network) management specifying the set of ports to which frames received from a specific port and containing a specific unicast destination address are allowed to be forwarded." INDEX { dot1qFdbId, dot1qStaticUnicastAddress, dot1qStaticUnicastReceivePort } ::= { dot1qStaticUnicastTable 1 } Dot1qStaticUnicastEntry ::= SEQUENCE { dot1qStaticUnicastAddress MacAddress, dot1qStaticUnicastReceivePort Integer32, dot1qStaticUnicastAllowedToGoTo PortList, dot1qStaticUnicastStatus INTEGER } dot1qStaticUnicastAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination MAC address in a frame to which this entry's filtering information applies. This object must take the value of a unicast address." ::= { dot1qStaticUnicastEntry 1 } Levi & Harrington Standards Track [Page 57] RFC 4363 Bridge MIB Extensions January 2006 dot1qStaticUnicastReceivePort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Either the value '0' or the port number of the port from which a frame must be received in order for this entry's filtering information to apply. A value of zero indicates that this entry applies on all ports of the device for which there is no other applicable entry." ::= { dot1qStaticUnicastEntry 2 } dot1qStaticUnicastAllowedToGoTo OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-write STATUS current DESCRIPTION "The set of ports for which a frame with a specific unicast address will be flooded in the event that it has not been learned. It also specifies the set of ports on which a specific unicast address may be dynamically learned. The dot1qTpFdbTable will have an equivalent entry with a dot1qTpFdbPort value of '0' until this address has been learned, at which point it will be updated with the port the address has been seen on. This only applies to ports that are members of the VLAN, defined by dot1qVlanCurrentEgressPorts. The default value of this object is a string of ones of appropriate length. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1Q/D11 Table 8-5, ISO/IEC 15802-3 Table 7-5" ::= { dot1qStaticUnicastEntry 3 } dot1qStaticUnicastStatus OBJECT-TYPE SYNTAX INTEGER { other(1), invalid(2), permanent(3), deleteOnReset(4), deleteOnTimeout(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the status of this entry. other(1) - this entry is currently in use, but Levi & Harrington Standards Track [Page 58] RFC 4363 Bridge MIB Extensions January 2006 the conditions under which it will remain so differ from the following values. invalid(2) - writing this value to the object removes the corresponding entry. permanent(3) - this entry is currently in use and will remain so after the next reset of the bridge. deleteOnReset(4) - this entry is currently in use and will remain so until the next reset of the bridge. deleteOnTimeout(5) - this entry is currently in use and will remain so until it is aged out. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { permanent } ::= { dot1qStaticUnicastEntry 4 } dot1qStaticMulticastTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qStaticMulticastEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing filtering information for Multicast and Broadcast MAC addresses for each VLAN, configured into the device by (local or network) management specifying the set of ports to which frames received from specific ports and containing specific Multicast and Broadcast destination addresses are allowed to be forwarded. A value of zero in this table (as the port number from which frames with a specific destination address are received) is used to specify all ports for which there is no specific entry in this table for that particular destination address. Entries are valid for Multicast and Broadcast addresses only." REFERENCE "IEEE 802.1Q/D11 Section 12.7.7, ISO/IEC 15802-3 Section 7.9.1" ::= { dot1qStatic 2 } dot1qStaticMulticastEntry OBJECT-TYPE SYNTAX Dot1qStaticMulticastEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Filtering information configured into the device by (local or network) management specifying the set of ports to which frames received from this specific port Levi & Harrington Standards Track [Page 59] RFC 4363 Bridge MIB Extensions January 2006 for this VLAN and containing this Multicast or Broadcast destination address are allowed to be forwarded." INDEX { dot1qVlanIndex, dot1qStaticMulticastAddress, dot1qStaticMulticastReceivePort } ::= { dot1qStaticMulticastTable 1 } Dot1qStaticMulticastEntry ::= SEQUENCE { dot1qStaticMulticastAddress MacAddress, dot1qStaticMulticastReceivePort Integer32, dot1qStaticMulticastStaticEgressPorts PortList, dot1qStaticMulticastForbiddenEgressPorts PortList, dot1qStaticMulticastStatus INTEGER } dot1qStaticMulticastAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination MAC address in a frame to which this entry's filtering information applies. This object must take the value of a Multicast or Broadcast address." ::= { dot1qStaticMulticastEntry 1 } dot1qStaticMulticastReceivePort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Either the value '0' or the port number of the port from which a frame must be received in order for this entry's filtering information to apply. A value of zero indicates that this entry applies on all ports of the device for which there is no other applicable entry." ::= { dot1qStaticMulticastEntry 2 } dot1qStaticMulticastStaticEgressPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-write Levi & Harrington Standards Track [Page 60] RFC 4363 Bridge MIB Extensions January 2006 STATUS current DESCRIPTION "The set of ports to which frames received from a specific port and destined for a specific Multicast or Broadcast MAC address must be forwarded, regardless of any dynamic information, e.g., from GMRP. A port may not be added in this set if it is already a member of the set of ports in dot1qStaticMulticastForbiddenEgressPorts. The default value of this object is a string of ones of appropriate length. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1qStaticMulticastEntry 3 } dot1qStaticMulticastForbiddenEgressPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-write STATUS current DESCRIPTION "The set of ports to which frames received from a specific port and destined for a specific Multicast or Broadcast MAC address must not be forwarded, regardless of any dynamic information, e.g., from GMRP. A port may not be added in this set if it is already a member of the set of ports in dot1qStaticMulticastStaticEgressPorts. The default value of this object is a string of zeros of appropriate length. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1qStaticMulticastEntry 4 } dot1qStaticMulticastStatus OBJECT-TYPE SYNTAX INTEGER { other(1), invalid(2), permanent(3), deleteOnReset(4), deleteOnTimeout(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the status of this entry. other(1) - this entry is currently in use, but the conditions under which it will remain so differ from the following values. Levi & Harrington Standards Track [Page 61] RFC 4363 Bridge MIB Extensions January 2006 invalid(2) - writing this value to the object removes the corresponding entry. permanent(3) - this entry is currently in use and will remain so after the next reset of the bridge. deleteOnReset(4) - this entry is currently in use and will remain so until the next reset of the bridge. deleteOnTimeout(5) - this entry is currently in use and will remain so until it is aged out. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { permanent } ::= { dot1qStaticMulticastEntry 5 } -- ------------------------------------------------------------- -- The Current VLAN Database -- ------------------------------------------------------------- dot1qVlanNumDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a VLAN entry has been deleted from the dot1qVlanCurrentTable (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2." ::= { dot1qVlan 1 } dot1qVlanCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qVlanCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing current configuration information for each VLAN currently configured into the device by (local or network) management, or dynamically created as a result of GVRP requests received." ::= { dot1qVlan 2 } dot1qVlanCurrentEntry OBJECT-TYPE SYNTAX Dot1qVlanCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information for a VLAN configured into the device by Levi & Harrington Standards Track [Page 62] RFC 4363 Bridge MIB Extensions January 2006 (local or network) management, or dynamically created as a result of GVRP requests received." INDEX { dot1qVlanTimeMark, dot1qVlanIndex } ::= { dot1qVlanCurrentTable 1 } Dot1qVlanCurrentEntry ::= SEQUENCE { dot1qVlanTimeMark TimeFilter, dot1qVlanIndex VlanIndex, dot1qVlanFdbId Unsigned32, dot1qVlanCurrentEgressPorts PortList, dot1qVlanCurrentUntaggedPorts PortList, dot1qVlanStatus INTEGER, dot1qVlanCreationTime TimeTicks } dot1qVlanTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { dot1qVlanCurrentEntry 1 } dot1qVlanIndex OBJECT-TYPE SYNTAX VlanIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VLAN-ID or other identifier referring to this VLAN." ::= { dot1qVlanCurrentEntry 2 } dot1qVlanFdbId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Filtering Database used by this VLAN. This is one of the dot1qFdbId values in the dot1qFdbTable. This value is allocated automatically by the device whenever Levi & Harrington Standards Track [Page 63] RFC 4363 Bridge MIB Extensions January 2006 the VLAN is created: either dynamically by GVRP, or by management, in dot1qVlanStaticTable. Allocation of this value follows the learning constraints defined for this VLAN in dot1qLearningConstraintsTable." ::= { dot1qVlanCurrentEntry 3 } dot1qVlanCurrentEgressPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION "The set of ports that are transmitting traffic for this VLAN as either tagged or untagged frames." REFERENCE "IEEE 802.1Q/D11 Section 12.10.2.1" ::= { dot1qVlanCurrentEntry 4 } dot1qVlanCurrentUntaggedPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION "The set of ports that are transmitting traffic for this VLAN as untagged frames." REFERENCE "IEEE 802.1Q/D11 Section 12.10.2.1" ::= { dot1qVlanCurrentEntry 5 } dot1qVlanStatus OBJECT-TYPE SYNTAX INTEGER { other(1), permanent(2), dynamicGvrp(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the status of this entry. other(1) - this entry is currently in use, but the conditions under which it will remain so differ from the following values. permanent(2) - this entry, corresponding to an entry in dot1qVlanStaticTable, is currently in use and will remain so after the next reset of the device. The port lists for this entry include ports from the equivalent dot1qVlanStaticTable entry and ports learned dynamically. dynamicGvrp(3) - this entry is currently in use Levi & Harrington Standards Track [Page 64] RFC 4363 Bridge MIB Extensions January 2006 and will remain so until removed by GVRP. There is no static entry for this VLAN, and it will be removed when the last port leaves the VLAN." ::= { dot1qVlanCurrentEntry 6 } dot1qVlanCreationTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this VLAN was created." ::= { dot1qVlanCurrentEntry 7 } -- ------------------------------------------------------------- -- The Static VLAN Database -- ------------------------------------------------------------- dot1qVlanStaticTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qVlanStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing static configuration information for each VLAN configured into the device by (local or network) management. All entries are permanent and will be restored after the device is reset." ::= { dot1qVlan 3 } dot1qVlanStaticEntry OBJECT-TYPE SYNTAX Dot1qVlanStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Static information for a VLAN configured into the device by (local or network) management." INDEX { dot1qVlanIndex } ::= { dot1qVlanStaticTable 1 } Dot1qVlanStaticEntry ::= SEQUENCE { dot1qVlanStaticName SnmpAdminString, dot1qVlanStaticEgressPorts PortList, dot1qVlanForbiddenEgressPorts PortList, dot1qVlanStaticUntaggedPorts PortList, Levi & Harrington Standards Track [Page 65] RFC 4363 Bridge MIB Extensions January 2006 dot1qVlanStaticRowStatus RowStatus } dot1qVlanStaticName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively assigned string, which may be used to identify the VLAN." REFERENCE "IEEE 802.1Q/D11 Section 12.10.2.1" ::= { dot1qVlanStaticEntry 1 } dot1qVlanStaticEgressPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-create STATUS current DESCRIPTION "The set of ports that are permanently assigned to the egress list for this VLAN by management. Changes to a bit in this object affect the per-port, per-VLAN Registrar control for Registration Fixed for the relevant GVRP state machine on each port. A port may not be added in this set if it is already a member of the set of ports in dot1qVlanForbiddenEgressPorts. The default value of this object is a string of zeros of appropriate length, indicating not fixed." REFERENCE "IEEE 802.1Q/D11 Section 12.7.7.3, 11.2.3.2.3" ::= { dot1qVlanStaticEntry 2 } dot1qVlanForbiddenEgressPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-create STATUS current DESCRIPTION "The set of ports that are prohibited by management from being included in the egress list for this VLAN. Changes to this object that cause a port to be included or excluded affect the per-port, per-VLAN Registrar control for Registration Forbidden for the relevant GVRP state machine on each port. A port may not be added in this set if it is already a member of the set of ports in dot1qVlanStaticEgressPorts. The default value of this object is a string of zeros of appropriate length, excluding all ports from the forbidden set." Levi & Harrington Standards Track [Page 66] RFC 4363 Bridge MIB Extensions January 2006 REFERENCE "IEEE 802.1Q/D11 Section 12.7.7.3, 11.2.3.2.3" ::= { dot1qVlanStaticEntry 3 } dot1qVlanStaticUntaggedPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-create STATUS current DESCRIPTION "The set of ports that should transmit egress packets for this VLAN as untagged. The default value of this object for the default VLAN (dot1qVlanIndex = 1) is a string of appropriate length including all ports. There is no specified default for other VLANs. If a device agent cannot support the set of ports being set, then it will reject the set operation with an error. For example, a manager might attempt to set more than one VLAN to be untagged on egress where the device does not support this IEEE 802.1Q option." REFERENCE "IEEE 802.1Q/D11 Section 12.10.2.1" ::= { dot1qVlanStaticEntry 4 } dot1qVlanStaticRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the status of this entry." ::= { dot1qVlanStaticEntry 5 } dot1qNextFreeLocalVlanIndex OBJECT-TYPE SYNTAX Integer32 (0|4096..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The next available value for dot1qVlanIndex of a local VLAN entry in dot1qVlanStaticTable. This will report values >=4096 if a new Local VLAN may be created or else the value 0 if this is not possible. A row creation operation in this table for an entry with a local VlanIndex value may fail if the current value of this object is not used as the index. Even if the value read is used, there is no guarantee that it will still be the valid index when the create operation is attempted; another manager may have already got in during the intervening time interval. In this case, dot1qNextFreeLocalVlanIndex should be re-read Levi & Harrington Standards Track [Page 67] RFC 4363 Bridge MIB Extensions January 2006 and the creation re-tried with the new value. This value will automatically change when the current value is used to create a new row." ::= { dot1qVlan 4 } -- ------------------------------------------------------------- -- The VLAN Port Configuration Table -- ------------------------------------------------------------- dot1qPortVlanTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qPortVlanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing per-port control and status information for VLAN configuration in the device." ::= { dot1qVlan 5 } dot1qPortVlanEntry OBJECT-TYPE SYNTAX Dot1qPortVlanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information controlling VLAN configuration for a port on the device. This is indexed by dot1dBasePort." AUGMENTS { dot1dBasePortEntry } ::= { dot1qPortVlanTable 1 } Dot1qPortVlanEntry ::= SEQUENCE { dot1qPvid VlanIndex, dot1qPortAcceptableFrameTypes INTEGER, dot1qPortIngressFiltering TruthValue, dot1qPortGvrpStatus EnabledStatus, dot1qPortGvrpFailedRegistrations Counter32, dot1qPortGvrpLastPduOrigin MacAddress, dot1qPortRestrictedVlanRegistration TruthValue } dot1qPvid OBJECT-TYPE Levi & Harrington Standards Track [Page 68] RFC 4363 Bridge MIB Extensions January 2006 SYNTAX VlanIndex MAX-ACCESS read-write STATUS current DESCRIPTION "The PVID, the VLAN-ID assigned to untagged frames or Priority-Tagged frames received on this port. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1Q/D11 Section 12.10.1.1" DEFVAL { 1 } ::= { dot1qPortVlanEntry 1 } dot1qPortAcceptableFrameTypes OBJECT-TYPE SYNTAX INTEGER { admitAll(1), admitOnlyVlanTagged(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "When this is admitOnlyVlanTagged(2), the device will discard untagged frames or Priority-Tagged frames received on this port. When admitAll(1), untagged frames or Priority-Tagged frames received on this port will be accepted and assigned to a VID based on the PVID and VID Set for this port. This control does not affect VLAN-independent Bridge Protocol Data Unit (BPDU) frames, such as GVRP and Spanning Tree Protocol (STP). It does affect VLAN- dependent BPDU frames, such as GMRP. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1Q/D11 Section 12.10.1.3" DEFVAL { admitAll } ::= { dot1qPortVlanEntry 2 } dot1qPortIngressFiltering OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When this is true(1), the device will discard incoming frames for VLANs that do not include this Port in its Levi & Harrington Standards Track [Page 69] RFC 4363 Bridge MIB Extensions January 2006 Member set. When false(2), the port will accept all incoming frames. This control does not affect VLAN-independent BPDU frames, such as GVRP and STP. It does affect VLAN- dependent BPDU frames, such as GMRP. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1Q/D11 Section 12.10.1.4" DEFVAL { false } ::= { dot1qPortVlanEntry 3 } dot1qPortGvrpStatus OBJECT-TYPE SYNTAX EnabledStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The state of GVRP operation on this port. The value enabled(1) indicates that GVRP is enabled on this port, as long as dot1qGvrpStatus is also enabled for this device. When disabled(2) but dot1qGvrpStatus is still enabled for the device, GVRP is disabled on this port: any GVRP packets received will be silently discarded, and no GVRP registrations will be propagated from other ports. This object affects all GVRP Applicant and Registrar state machines on this port. A transition from disabled(2) to enabled(1) will cause a reset of all GVRP state machines on this port. The value of this object MUST be retained across reinitializations of the management system." DEFVAL { enabled } ::= { dot1qPortVlanEntry 4 } dot1qPortGvrpFailedRegistrations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of failed GVRP registrations, for any reason, on this port." ::= { dot1qPortVlanEntry 5 } dot1qPortGvrpLastPduOrigin OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only Levi & Harrington Standards Track [Page 70] RFC 4363 Bridge MIB Extensions January 2006 STATUS current DESCRIPTION "The Source MAC Address of the last GVRP message received on this port." ::= { dot1qPortVlanEntry 6 } dot1qPortRestrictedVlanRegistration OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The state of Restricted VLAN Registration on this port. If the value of this control is true(1), then creation of a new dynamic VLAN entry is permitted only if there is a Static VLAN Registration Entry for the VLAN concerned, in which the Registrar Administrative Control value for this port is Normal Registration. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "IEEE 802.1u clause 11.2.3.2.3, 12.10.1.7." DEFVAL { false } ::= { dot1qPortVlanEntry 7 } -- ------------------------------------------------------------- -- Per port VLAN Statistics Table -- ------------------------------------------------------------- dot1qPortVlanStatisticsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qPortVlanStatisticsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing per-port, per-VLAN statistics for traffic received. Separate objects are provided for both the most-significant and least-significant bits of statistics counters for ports that are associated with this transparent bridge. The most-significant bit objects are only required on high-capacity interfaces, as defined in the conformance clauses for these objects. This mechanism is provided as a way to read 64-bit counters for agents that support only SNMPv1. Note that the reporting of most-significant and least- significant counter bits separately runs the risk of missing an overflow of the lower bits in the interval between sampling. The manager must be aware of this possibility, even within the same varbindlist, when interpreting the results of a request or Levi & Harrington Standards Track [Page 71] RFC 4363 Bridge MIB Extensions January 2006 asynchronous notification." ::= { dot1qVlan 6 } dot1qPortVlanStatisticsEntry OBJECT-TYPE SYNTAX Dot1qPortVlanStatisticsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Traffic statistics for a VLAN on an interface." INDEX { dot1dBasePort, dot1qVlanIndex } ::= { dot1qPortVlanStatisticsTable 1 } Dot1qPortVlanStatisticsEntry ::= SEQUENCE { dot1qTpVlanPortInFrames Counter32, dot1qTpVlanPortOutFrames Counter32, dot1qTpVlanPortInDiscards Counter32, dot1qTpVlanPortInOverflowFrames Counter32, dot1qTpVlanPortOutOverflowFrames Counter32, dot1qTpVlanPortInOverflowDiscards Counter32 } dot1qTpVlanPortInFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid frames received by this port from its segment that were classified as belonging to this VLAN. Note that a frame received on this port is counted by this object if and only if it is for a protocol being processed by the local forwarding process for this VLAN. This object includes received bridge management frames classified as belonging to this VLAN (e.g., GMRP, but not GVRP or STP." REFERENCE "IEEE 802.1Q/D11 Section 12.6.1.1.3(a)" ::= { dot1qPortVlanStatisticsEntry 1 } dot1qTpVlanPortOutFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Levi & Harrington Standards Track [Page 72] RFC 4363 Bridge MIB Extensions January 2006 STATUS current DESCRIPTION "The number of valid frames transmitted by this port to its segment from the local forwarding process for this VLAN. This includes bridge management frames originated by this device that are classified as belonging to this VLAN (e.g., GMRP, but not GVRP or STP)." REFERENCE "IEEE 802.1Q/D11 Section 12.6.1.1.3(d)" ::= { dot1qPortVlanStatisticsEntry 2 } dot1qTpVlanPortInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid frames received by this port from its segment that were classified as belonging to this VLAN and that were discarded due to VLAN-related reasons. Specifically, the IEEE 802.1Q counters for Discard Inbound and Discard on Ingress Filtering." REFERENCE "IEEE 802.1Q/D11 Section 12.6.1.1.3" ::= { dot1qPortVlanStatisticsEntry 3 } dot1qTpVlanPortInOverflowFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated dot1qTpVlanPortInFrames counter has overflowed." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1qPortVlanStatisticsEntry 4 } dot1qTpVlanPortOutOverflowFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated dot1qTpVlanPortOutFrames counter has overflowed." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1qPortVlanStatisticsEntry 5 } dot1qTpVlanPortInOverflowDiscards OBJECT-TYPE Levi & Harrington Standards Track [Page 73] RFC 4363 Bridge MIB Extensions January 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the associated dot1qTpVlanPortInDiscards counter has overflowed." REFERENCE "ISO/IEC 15802-3 Section 14.6.1.1.3" ::= { dot1qPortVlanStatisticsEntry 6 } dot1qPortVlanHCStatisticsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qPortVlanHCStatisticsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing per-port, per-VLAN statistics for traffic on high-capacity interfaces." ::= { dot1qVlan 7 } dot1qPortVlanHCStatisticsEntry OBJECT-TYPE SYNTAX Dot1qPortVlanHCStatisticsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Traffic statistics for a VLAN on a high-capacity interface." INDEX { dot1dBasePort, dot1qVlanIndex } ::= { dot1qPortVlanHCStatisticsTable 1 } Dot1qPortVlanHCStatisticsEntry ::= SEQUENCE { dot1qTpVlanPortHCInFrames Counter64, dot1qTpVlanPortHCOutFrames Counter64, dot1qTpVlanPortHCInDiscards Counter64 } dot1qTpVlanPortHCInFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid frames received by this port from its segment that were classified as belonging to this VLAN. Note that a frame received on this port is counted by this object if and only if it is for a Levi & Harrington Standards Track [Page 74] RFC 4363 Bridge MIB Extensions January 2006 protocol being processed by the local forwarding process for this VLAN. This object includes received bridge management frames classified as belonging to this VLAN (e.g., GMRP, but not GVRP or STP)." REFERENCE "IEEE 802.1Q/D11 Section 12.6.1.1.3(a)" ::= { dot1qPortVlanHCStatisticsEntry 1 } dot1qTpVlanPortHCOutFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid frames transmitted by this port to its segment from the local forwarding process for this VLAN. This includes bridge management frames originated by this device that are classified as belonging to this VLAN (e.g., GMRP, but not GVRP or STP)." REFERENCE "IEEE 802.1Q/D11 Section 12.6.1.1.3(d)" ::= { dot1qPortVlanHCStatisticsEntry 2 } dot1qTpVlanPortHCInDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid frames received by this port from its segment that were classified as belonging to this VLAN and that were discarded due to VLAN-related reasons. Specifically, the IEEE 802.1Q counters for Discard Inbound and Discard on Ingress Filtering." REFERENCE "IEEE 802.1Q/D11 Section 12.6.1.1.3" ::= { dot1qPortVlanHCStatisticsEntry 3 } -- ------------------------------------------------------------- -- The VLAN Learning Constraints Table -- ------------------------------------------------------------- dot1qLearningConstraintsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qLearningConstraintsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing learning constraints for sets of Shared and Independent VLANs." REFERENCE Levi & Harrington Standards Track [Page 75] RFC 4363 Bridge MIB Extensions January 2006 "IEEE 802.1Q/D11 Section 12.10.3.1" ::= { dot1qVlan 8 } dot1qLearningConstraintsEntry OBJECT-TYPE SYNTAX Dot1qLearningConstraintsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A learning constraint defined for a VLAN." INDEX { dot1qConstraintVlan, dot1qConstraintSet } ::= { dot1qLearningConstraintsTable 1 } Dot1qLearningConstraintsEntry ::= SEQUENCE { dot1qConstraintVlan VlanIndex, dot1qConstraintSet Integer32, dot1qConstraintType INTEGER, dot1qConstraintStatus RowStatus } dot1qConstraintVlan OBJECT-TYPE SYNTAX VlanIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the row in dot1qVlanCurrentTable for the VLAN constrained by this entry." ::= { dot1qLearningConstraintsEntry 1 } dot1qConstraintSet OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identity of the constraint set to which dot1qConstraintVlan belongs. These values may be chosen by the management station." ::= { dot1qLearningConstraintsEntry 2 } dot1qConstraintType OBJECT-TYPE SYNTAX INTEGER { independent(1), shared(2) } Levi & Harrington Standards Track [Page 76] RFC 4363 Bridge MIB Extensions January 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The type of constraint this entry defines. independent(1) - the VLAN, dot1qConstraintVlan, uses a filtering database independent from all other VLANs in the same set, defined by dot1qConstraintSet. shared(2) - the VLAN, dot1qConstraintVlan, shares the same filtering database as all other VLANs in the same set, defined by dot1qConstraintSet." ::= { dot1qLearningConstraintsEntry 3 } dot1qConstraintStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry." ::= { dot1qLearningConstraintsEntry 4 } dot1qConstraintSetDefault OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The identity of the constraint set to which a VLAN belongs, if there is not an explicit entry for that VLAN in dot1qLearningConstraintsTable. The value of this object MUST be retained across reinitializations of the management system." ::= { dot1qVlan 9 } dot1qConstraintTypeDefault OBJECT-TYPE SYNTAX INTEGER { independent(1), shared(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of constraint set to which a VLAN belongs, if there is not an explicit entry for that VLAN in dot1qLearningConstraintsTable. The types are as defined for dot1qConstraintType. The value of this object MUST be retained across Levi & Harrington Standards Track [Page 77] RFC 4363 Bridge MIB Extensions January 2006 reinitializations of the management system." ::= { dot1qVlan 10 } -- ------------------------------------------------------------- -- dot1vProtocol subtree -- ------------------------------------------------------------- dot1vProtocolGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1vProtocolGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains mappings from Protocol Templates to Protocol Group Identifiers used for Port-and-Protocol-based VLAN Classification." REFERENCE "IEEE 802.1v clause 8.6.4" ::= { dot1vProtocol 1 } dot1vProtocolGroupEntry OBJECT-TYPE SYNTAX Dot1vProtocolGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A mapping from a Protocol Template to a Protocol Group Identifier." INDEX { dot1vProtocolTemplateFrameType, dot1vProtocolTemplateProtocolValue } ::= { dot1vProtocolGroupTable 1 } Dot1vProtocolGroupEntry ::= SEQUENCE { dot1vProtocolTemplateFrameType INTEGER, dot1vProtocolTemplateProtocolValue OCTET STRING, dot1vProtocolGroupId Integer32, dot1vProtocolGroupRowStatus RowStatus } dot1vProtocolTemplateFrameType OBJECT-TYPE SYNTAX INTEGER { ethernet (1), rfc1042 (2), snap8021H (3), snapOther (4), Levi & Harrington Standards Track [Page 78] RFC 4363 Bridge MIB Extensions January 2006 llcOther (5) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The data-link encapsulation format or the 'detagged_frame_type' in a Protocol Template." REFERENCE "IEEE 802.1v clause 8.6.2" ::= { dot1vProtocolGroupEntry 1 } dot1vProtocolTemplateProtocolValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2 | 5)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identification of the protocol above the data-link layer in a Protocol Template. Depending on the frame type, the octet string will have one of the following values: For 'ethernet', 'rfc1042' and 'snap8021H', this is the 16-bit (2-octet) IEEE 802.3 Type Field. For 'snapOther', this is the 40-bit (5-octet) PID. For 'llcOther', this is the 2-octet IEEE 802.2 Link Service Access Point (LSAP) pair: first octet for Destination Service Access Point (DSAP) and second octet for Source Service Access Point (SSAP)." REFERENCE "IEEE 802.1v clause 8.6.2" ::= { dot1vProtocolGroupEntry 2 } dot1vProtocolGroupId OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents a group of protocols that are associated together when assigning a VID to a frame." REFERENCE "IEEE 802.1v clause 8.6.3, 12.10.2.1" ::= { dot1vProtocolGroupEntry 3 } dot1vProtocolGroupRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Levi & Harrington Standards Track [Page 79] RFC 4363 Bridge MIB Extensions January 2006 STATUS current DESCRIPTION "This object indicates the status of this entry." ::= { dot1vProtocolGroupEntry 4 } dot1vProtocolPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1vProtocolPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that contains VID sets used for Port-and-Protocol-based VLAN Classification." REFERENCE "IEEE 802.1v clause 8.4.4" ::= { dot1vProtocol 2 } dot1vProtocolPortEntry OBJECT-TYPE SYNTAX Dot1vProtocolPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A VID set for a port." INDEX { dot1dBasePort, dot1vProtocolPortGroupId } ::= { dot1vProtocolPortTable 1 } Dot1vProtocolPortEntry ::= SEQUENCE { dot1vProtocolPortGroupId Integer32, dot1vProtocolPortGroupVid Integer32, dot1vProtocolPortRowStatus RowStatus } dot1vProtocolPortGroupId OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Designates a group of protocols in the Protocol Group Database." REFERENCE "IEEE 802.1v clause 8.6.3, 12.10.1.2" ::= { dot1vProtocolPortEntry 1 } dot1vProtocolPortGroupVid OBJECT-TYPE Levi & Harrington Standards Track [Page 80] RFC 4363 Bridge MIB Extensions January 2006 SYNTAX Integer32 (1..4094) MAX-ACCESS read-create STATUS current DESCRIPTION "The VID associated with a group of protocols for each port." REFERENCE "IEEE 802.1v clause 8.4.4, 12.10.1.2" ::= { dot1vProtocolPortEntry 2 } dot1vProtocolPortRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the status of this entry." ::= { dot1vProtocolPortEntry 3 } -- ------------------------------------------------------------- -- IEEE 802.1Q MIB - Conformance Information -- ------------------------------------------------------------- qBridgeConformance OBJECT IDENTIFIER ::= { qBridgeMIB 2 } qBridgeGroups OBJECT IDENTIFIER ::= { qBridgeConformance 1 } qBridgeCompliances OBJECT IDENTIFIER ::= { qBridgeConformance 2 } -- ------------------------------------------------------------- -- units of conformance -- ------------------------------------------------------------- qBridgeBaseGroup OBJECT-GROUP OBJECTS { dot1qVlanVersionNumber, dot1qMaxVlanId, dot1qMaxSupportedVlans, dot1qNumVlans, dot1qGvrpStatus } STATUS current DESCRIPTION "A collection of objects providing device-level control and status information for the Virtual LAN bridge services." ::= { qBridgeGroups 1 } qBridgeFdbUnicastGroup OBJECT-GROUP Levi & Harrington Standards Track [Page 81] RFC 4363 Bridge MIB Extensions January 2006 OBJECTS { dot1qFdbDynamicCount, dot1qTpFdbPort, dot1qTpFdbStatus } STATUS current DESCRIPTION "A collection of objects providing information about all unicast addresses, learned dynamically or statically configured by management, in each Filtering Database." ::= { qBridgeGroups 2 } qBridgeFdbMulticastGroup OBJECT-GROUP OBJECTS { dot1qTpGroupEgressPorts, dot1qTpGroupLearnt } STATUS current DESCRIPTION "A collection of objects providing information about all multicast addresses, learned dynamically or statically configured by management, in each Filtering Database." ::= { qBridgeGroups 3 } qBridgeServiceRequirementsGroup OBJECT-GROUP OBJECTS { dot1qForwardAllPorts, dot1qForwardAllStaticPorts, dot1qForwardAllForbiddenPorts, dot1qForwardUnregisteredPorts, dot1qForwardUnregisteredStaticPorts, dot1qForwardUnregisteredForbiddenPorts } STATUS current DESCRIPTION "A collection of objects providing information about service requirements, learned dynamically or statically configured by management, in each Filtering Database." ::= { qBridgeGroups 4 } qBridgeFdbStaticGroup OBJECT-GROUP OBJECTS { dot1qStaticUnicastAllowedToGoTo, dot1qStaticUnicastStatus, dot1qStaticMulticastStaticEgressPorts, dot1qStaticMulticastForbiddenEgressPorts, dot1qStaticMulticastStatus } Levi & Harrington Standards Track [Page 82] RFC 4363 Bridge MIB Extensions January 2006 STATUS current DESCRIPTION "A collection of objects providing information about unicast and multicast addresses statically configured by management, in each Filtering Database or VLAN." ::= { qBridgeGroups 5 } qBridgeVlanGroup OBJECT-GROUP OBJECTS { dot1qVlanNumDeletes, dot1qVlanFdbId, dot1qVlanCurrentEgressPorts, dot1qVlanCurrentUntaggedPorts, dot1qVlanStatus, dot1qVlanCreationTime } STATUS current DESCRIPTION "A collection of objects providing information about all VLANs currently configured on this device." ::= { qBridgeGroups 6 } qBridgeVlanStaticGroup OBJECT-GROUP OBJECTS { dot1qVlanStaticName, dot1qVlanStaticEgressPorts, dot1qVlanForbiddenEgressPorts, dot1qVlanStaticUntaggedPorts, dot1qVlanStaticRowStatus, dot1qNextFreeLocalVlanIndex } STATUS current DESCRIPTION "A collection of objects providing information about VLANs statically configured by management." ::= { qBridgeGroups 7 } qBridgePortGroup OBJECT-GROUP OBJECTS { dot1qPvid, dot1qPortAcceptableFrameTypes, dot1qPortIngressFiltering, dot1qPortGvrpStatus, dot1qPortGvrpFailedRegistrations, dot1qPortGvrpLastPduOrigin } STATUS deprecated DESCRIPTION Levi & Harrington Standards Track [Page 83] RFC 4363 Bridge MIB Extensions January 2006 "A collection of objects providing port-level VLAN control and status information for all ports." ::= { qBridgeGroups 8 } qBridgeVlanStatisticsGroup OBJECT-GROUP OBJECTS { dot1qTpVlanPortInFrames, dot1qTpVlanPortOutFrames, dot1qTpVlanPortInDiscards } STATUS current DESCRIPTION "A collection of objects providing per-port packet statistics for all VLANs currently configured on this device." ::= { qBridgeGroups 9 } qBridgeVlanStatisticsOverflowGroup OBJECT-GROUP OBJECTS { dot1qTpVlanPortInOverflowFrames, dot1qTpVlanPortOutOverflowFrames, dot1qTpVlanPortInOverflowDiscards } STATUS current DESCRIPTION "A collection of objects providing overflow counters for per-port packet statistics for all VLANs currently configured on this device for high-capacity interfaces, defined as those that have the value of the corresponding instance of ifSpeed greater than 650,000,000 bits/second." ::= { qBridgeGroups 10 } qBridgeVlanHCStatisticsGroup OBJECT-GROUP OBJECTS { dot1qTpVlanPortHCInFrames, dot1qTpVlanPortHCOutFrames, dot1qTpVlanPortHCInDiscards } STATUS current DESCRIPTION "A collection of objects providing per-port packet statistics for all VLANs currently configured on this device for high-capacity interfaces, defined as those that have the value of the corresponding instance of ifSpeed greater than 650,000,000 bits/second." ::= { qBridgeGroups 11 } qBridgeLearningConstraintsGroup OBJECT-GROUP Levi & Harrington Standards Track [Page 84] RFC 4363 Bridge MIB Extensions January 2006 OBJECTS { dot1qConstraintType, dot1qConstraintStatus } STATUS current DESCRIPTION "A collection of objects defining the Filtering Database constraints all VLANs have with each other." ::= { qBridgeGroups 12 } qBridgeLearningConstraintDefaultGroup OBJECT-GROUP OBJECTS { dot1qConstraintSetDefault, dot1qConstraintTypeDefault } STATUS current DESCRIPTION "A collection of objects defining the default Filtering Database constraints for VLANs that have no specific constraints defined." ::= { qBridgeGroups 13 } qBridgeClassificationDeviceGroup OBJECT-GROUP OBJECTS { dot1vProtocolGroupId, dot1vProtocolGroupRowStatus } STATUS current DESCRIPTION "VLAN classification information for the bridge." ::= { qBridgeGroups 14 } qBridgeClassificationPortGroup OBJECT-GROUP OBJECTS { dot1vProtocolPortGroupVid, dot1vProtocolPortRowStatus } STATUS current DESCRIPTION "VLAN classification information for individual ports." ::= { qBridgeGroups 15 } qBridgePortGroup2 OBJECT-GROUP OBJECTS { dot1qPvid, dot1qPortAcceptableFrameTypes, dot1qPortIngressFiltering, dot1qPortGvrpStatus, Levi & Harrington Standards Track [Page 85] RFC 4363 Bridge MIB Extensions January 2006 dot1qPortGvrpFailedRegistrations, dot1qPortGvrpLastPduOrigin, dot1qPortRestrictedVlanRegistration } STATUS current DESCRIPTION "A collection of objects providing port-level VLAN control and status information for all ports." ::= { qBridgeGroups 16 } -- ------------------------------------------------------------- -- compliance statements -- ------------------------------------------------------------- qBridgeCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for device support of Virtual LAN Bridge services. RFC2674 was silent about the expected persistence of the read-write objects in this MIB module. Applications MUST NOT assume that the values of the read-write objects are persistent across reinitializations of the management system and MUST NOT assume that the values are not persistent across reinitializations of the management system." MODULE MANDATORY-GROUPS { qBridgeBaseGroup, qBridgeVlanGroup, qBridgeVlanStaticGroup, qBridgePortGroup } GROUP qBridgeFdbUnicastGroup DESCRIPTION "This group is mandatory for bridges that implement 802.1Q transparent bridging." GROUP qBridgeFdbMulticastGroup DESCRIPTION "This group is mandatory for bridges that implement 802.1Q transparent bridging." GROUP qBridgeServiceRequirementsGroup DESCRIPTION Levi & Harrington Standards Track [Page 86] RFC 4363 Bridge MIB Extensions January 2006 "This group is mandatory for bridges that implement extended filtering services. All objects must be read-write if extended-filtering services are enabled." GROUP qBridgeFdbStaticGroup DESCRIPTION "This group is optional." GROUP qBridgeVlanStatisticsGroup DESCRIPTION "This group is optional as there may be significant implementation cost associated with its support." GROUP qBridgeVlanStatisticsOverflowGroup DESCRIPTION "This group is optional as there may be significant implementation cost associated with its support. It is most relevant for high-capacity interfaces where the SNMP agent supports only SNMPv1." GROUP qBridgeVlanHCStatisticsGroup DESCRIPTION "This group is optional as there may be significant implementation cost associated with its support. It is most relevant for high-capacity interfaces." GROUP qBridgeLearningConstraintsGroup DESCRIPTION "This group is mandatory for devices implementing both Independent VLAN Learning (IVL) and Shared VLAN Learning (SVL) modes of operation of the filtering database, as defined by IEEE 802.1Q." GROUP qBridgeLearningConstraintDefaultGroup DESCRIPTION "This group is mandatory for devices implementing both Independent VLAN Learning (IVL) and Shared VLAN Learning (SVL) modes of operation of the filtering database, as defined by IEEE 802.1Q." OBJECT dot1qPortAcceptableFrameTypes MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." OBJECT dot1qPortIngressFiltering Levi & Harrington Standards Track [Page 87] RFC 4363 Bridge MIB Extensions January 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." OBJECT dot1qConstraintSetDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." OBJECT dot1qConstraintTypeDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." ::= { qBridgeCompliances 1 } qBridgeCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for device support of Virtual LAN Bridge services. This document clarifies the persistence requirements for the read-write objects in this MIB module. All implementations claiming compliance to qBridgeCompliance2 MUST retain the values of those read-write objects that specify this requirement." MODULE MANDATORY-GROUPS { qBridgeBaseGroup, qBridgeVlanGroup, qBridgeVlanStaticGroup, qBridgePortGroup2 } GROUP qBridgeFdbUnicastGroup DESCRIPTION "This group is mandatory for bridges that implement 802.1Q transparent bridging." GROUP qBridgeFdbMulticastGroup DESCRIPTION "This group is mandatory for bridges that implement 802.1Q transparent bridging." Levi & Harrington Standards Track [Page 88] RFC 4363 Bridge MIB Extensions January 2006 GROUP qBridgeServiceRequirementsGroup DESCRIPTION "This group is mandatory for bridges that implement extended filtering services. All objects must be read-write if extended-filtering services are enabled." GROUP qBridgeFdbStaticGroup DESCRIPTION "This group is optional." GROUP qBridgeVlanStatisticsGroup DESCRIPTION "This group is optional as there may be significant implementation cost associated with its support." GROUP qBridgeVlanStatisticsOverflowGroup DESCRIPTION "This group is optional as there may be significant implementation cost associated with its support. It is most relevant for high-capacity interfaces where the SNMP agent supports only SNMPv1." GROUP qBridgeVlanHCStatisticsGroup DESCRIPTION "This group is optional as there may be significant implementation cost associated with its support. It is most relevant for high-capacity interfaces." GROUP qBridgeLearningConstraintsGroup DESCRIPTION "This group is mandatory for devices implementing both Independent VLAN Learning (IVL) and Shared VLAN Learning (SVL) modes of operation of the filtering database, as defined by IEEE 802.1Q." GROUP qBridgeLearningConstraintDefaultGroup DESCRIPTION "This group is mandatory for devices implementing both Independent VLAN Learning (IVL) and Shared VLAN Learning (SVL) modes of operation of the filtering database, as defined by IEEE 802.1Q." GROUP qBridgeClassificationDeviceGroup DESCRIPTION "This group is mandatory ONLY for devices implementing VLAN Classification as specified in IEEE 802.1v." Levi & Harrington Standards Track [Page 89] RFC 4363 Bridge MIB Extensions January 2006 GROUP qBridgeClassificationPortGroup DESCRIPTION "This group is mandatory ONLY for devices implementing VLAN Classification as specified in IEEE 802.1v." OBJECT dot1qPortAcceptableFrameTypes MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." OBJECT dot1qPortIngressFiltering MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." OBJECT dot1qConstraintSetDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." OBJECT dot1qConstraintTypeDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." OBJECT dot1vProtocolGroupId MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1v." OBJECT dot1vProtocolGroupRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1v." ::= { qBridgeCompliances 2 } END Levi & Harrington Standards Track [Page 90] RFC 4363 Bridge MIB Extensions January 2006 6. Acknowledgements Much of the groundwork for this document was performed by the IEEE 802.1 working group during the definition of the IEEE 802.1D updates [802.1D] and IEEE 802.1Q [802.1Q]. The authors wish to thank the members of the Bridge Working Group, and David Harrington, Anders SW Christensen, Andrew Smith, Paul Langille, Anil Rijhsinghani, and Keith McCloghrie in particular for their comments and suggestions, which improved this effort. Editing for the final version was done by David Levi. The new textual conventions related to VLAN-IDs were produced as a result of a review of the use of VLAN-ID in several MIB modules. Further investigation found that VLAN-ID objects were defined in a few other MIB modules. The editor would like to thank all who contributed to the discussion that resulted in these new textual conventions. Specifically, Bert Wijnen, Les Bell, Andrew Smith, Mike Heard, Randy Presuhn, Dan Romascanu, Eduardo Cardona, Tom Petch, Juergen Schoenwaelder, Richard Woundy, Tony Jeffree, and William Murwin. We also received input and feedback from IEEE confirming that the values 0 and 4095 are not used for identifying a specific VLAN-ID and so can be used to represent none or a wildcard (see Appendix A). 7. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These tables and objects and their sensitivity/vulnerability are described below. The following tables and objects in the P-BRIDGE-MIB can be manipulated to interfere with the operation of priority classes. This could, for example, be used to force a reinitialization of state machines, thus causing network instability. Another possibility would be for an attacker to override established policy on port priorities, thus giving a user (or an attacker) unauthorized preferential treatment. dot1dTrafficClassesEnabled dot1dGmrpStatus dot1dPortPriorityTable dot1dUserPriorityRegenTable Levi & Harrington Standards Track [Page 91] RFC 4363 Bridge MIB Extensions January 2006 dot1dTrafficClassTable dot1dPortGarpTable dot1dPortGmrpTable The following tables and objects in the Q-BRIDGE-MIB could be manipulated to interfere with the operation of virtual LANs. This could, for example, be used to force a reinitialization of state machines to cause network instability, or changing the forwarding and filtering policies. dot1qGvrpStatus dot1qForwardAllTable dot1qStaticUnicastTable dot1qStaticMulticastTable dot1qVlanStaticTable dot1qPortVlanTable dot1qLearningConstraintsTable dot1vProtocolGroupTable dot1vProtocolPortTable Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability. The objects dot1dDeviceCapabilities and dot1dPortCapabilitiesTable in the P-BRIDGE-MIB could be used by an attacker to determine which attacks might be useful to attempt against a given device. The following read-only tables and objects in the Q-BRIDGE-MIB could be used by an attacker to determine which attacks might be useful to attempt against a given device, could be used by an attacker to detect whether their attacks are being blocked or filtered, or could be used to understand the logical topology of the network. dot1qMaxVlanID dot1qMaxSupportedVlans dot1qNumVlans dot1qFdbTable dot1qTpFdbTable dot1qTpGroupTable dot1qVlanCurrentTable dot1qPortVlanStatisticsTable Levi & Harrington Standards Track [Page 92] RFC 4363 Bridge MIB Extensions January 2006 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. Normative References [BRIDGE-MIB] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", RFC 2674, August 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Levi & Harrington Standards Track [Page 93] RFC 4363 Bridge MIB Extensions January 2006 [802.1D] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 2003. [802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D) IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Technical and Editorial Corrections". [802.1u] IEEE 802.1u-2001, "(Amendment to IEEE Standard 802.1Q) IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks - Amendment 1: Technical and Editorial Corrections". [802.1v] IEEE 802.1v-2001, "(Amendment to IEEE Standard 802.1Q) IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks--Amendment 2: VLAN Classification by Protocol and Port". 9. Informative References [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [RFC4323] Patrick, M. and W. Murwin, "Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB)", RFC 4323, January 2006. [RFC4149] Kalbfleisch, C., Cole, R., and D. Romascanu, "Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms", RFC 4149, August 2005. [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999. Levi & Harrington Standards Track [Page 94] RFC 4363 Bridge MIB Extensions January 2006 [RFC3318] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework Policy Information Base", RFC 3318, March 2003. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Levi & Harrington Standards Track [Page 95] RFC 4363 Bridge MIB Extensions January 2006 Appendix A. Email from Tony Jeffrey from IEEE -----Original Message----- From: Tony Jeffree [mailto:tony@jeffree.co.uk] Sent: Friday, 6th of June 2003 17:16 To: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Subject: RE: VLAn ID Bert et al - We have concluded that the use of 4095 as a wildcard is acceptable to 802.1, and we will make any necessary changes to 802.1Q in due course to relax the current stated restriction. However, we need to know whether that is all that needs to be done to 802.1Q - i.e., is there any need to change our definitions of the managed objects in the document (Clause 12) to reflect the interpretation of 4095 as a wildcard, or is this simply an issue for the SNMP machinery to handle? Regards, Tony Levi & Harrington Standards Track [Page 96] RFC 4363 Bridge MIB Extensions January 2006 Authors' Adresses David Levi Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 865 686 0432 EMail: dlevi@nortel.com David Harrington Effective Software 50 Harding Rd. Portsmouth, NH 03801 USA Phone: +1 603 436 8634 EMail: ietfdbh@comcast.net Vivian Ngai Salt lake City, UT USA EMail: vivian_ngai@acm.org Les Bell Hemel Hempstead Herts. HP2 7YU UK EMail: elbell@ntlworld.com Andrew Smith Beijing Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089 PRC Fax: +1 415 345 1827 EMail: ah_smith@acm.org Levi & Harrington Standards Track [Page 97] RFC 4363 Bridge MIB Extensions January 2006 Paul Langille Newbridge Networks 5 Corporate Drive Andover, MA 01810 USA Phone: +1 978 691 4665 EMail: langille@newbridge.com Anil Rijhsinghani Accton Technology Corporation 5 Mount Royal Ave Marlboro, MA 01752 USA EMail: anil@accton.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 EMail: kzm@cisco.com Levi & Harrington Standards Track [Page 98] RFC 4363 Bridge MIB Extensions January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Levi & Harrington Standards Track [Page 99] snmp-mibs-downloader-1.1/mibrfcs/rfc4368.txt0000644000000000000000000012446311402176072015601 0ustar Network Working Group T. Nadeau Request for Comments: 4368 S. Hegde Category: Standards Track Cisco Systems, Inc. January 2006 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................2 3. The SNMP Management Framework ...................................3 4. Interface Stacking of LC-ATM ....................................3 5. Structure of the MPLS-LC-ATM-STD-MIB Module .....................3 6. Structure of the MPLS-LC-FR-STD-MIB Module ......................4 7. MPLS Label-Controlled ATM MIB Definitions .......................5 8. MPLS Label-Controlled Frame Relay MIB Definitions ..............12 9. Acknowledgments ................................................18 10. Security Considerations .......................................18 11. IANA Considerations ...........................................19 11.1. IANA Considerations for MPLS-LC-ATM-STD-MIB ..............19 11.2. IANA Considerations for MPLS-LC-FR-STD-MIB ...............19 12. References ....................................................20 12.1. Normative References .....................................20 12.2. Informative References ...................................21 Nadeau & Hegde Standards Track [Page 1] RFC 4368 MPLS LC ATM and FR MIBs January 2006 1. Introduction This memo defines how label-switching-controlled Frame-Relay [RFC3034] and ATM [RFC3035] interfaces can be realized given the interface stacking as defined in the MPLS-LSR-STD [RFC3813] and MPLS-TE-STD [RFC3812] MIBs. This document also contains a MIB module that sparsely extends the MPLS-LSR-STD MIB's mplsInterfaceConfTable in such a way as to identify which MPLS-type interfaces have LC-ATM or LC-FR capabilities. Comments should be made directly to the MPLS mailing list at mpls@uu.net. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [RFC2119]. 2. Terminology This document uses terminology from the document describing the MPLS architecture [RFC3031], as well as from RFC 3035 and RFC 3034. Specifically, the following terms will be used in this document. C-FR RFC 3034 defines a label-switching-controlled Frame Relay (LC-FR) interface. Packets traversing such an interface carry labels in the DLCI field C-ATM RFC 3035 defines a label-switching-controlled ATM (LC-ATM) interface as an ATM interface controlled by the label switching control component. When a packet traversing such an interface is received, it is treated as a labeled packet. The packet's top label is inferred from either the contents of the Virtual Channel Identifier (VCI) field or the combined contents of the Virtual Path Identifier (VPI) and VCI fields. Any two LDP peers that are connected via an LC-ATM interface will use LDP negotiations to determine which of these cases is applicable to that interface. Static configuration of labels is also possible. When LDP is used to distribute labels for use on label-controlled interfaces, label configuration information may be available in the MPLS-LDP-ATM-STD-MIB [RFC3815] when LC-ATM interfaces are used, or the MPLS-LDP-FRAME-RELAY-STD-MIB [RFC3815] when LC-FR interfaces are used. Nadeau & Hegde Standards Track [Page 2] RFC 4368 MPLS LC ATM and FR MIBs January 2006 3. The SNMP Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Interface Stacking of LC-ATM Since LC-ATM interfaces [RFC2863] can carry labeled MPLS traffic, they too are considered MPLS subinterfaces with ifType = mpls(166). They differ slightly in their capability from a packet-oriented MPLS interface in that they may carry ATM- or Frame-Relay-encapsulated traffic. It is thus beneficial to identify them as such. To do this, two tables are defined that extend the MPLS-LSR-STD MIB's mplsInterfaceTable (see section 5 for LC-ATM or section 6 for LC-FR). 5. Structure of the MPLS-LC-ATM-STD-MIB Module The MPLS-LC-ATM-STD-MIB module is structured simply as a table of entries that sparsely extend those found in the interfaces table. In particular, the entries in the mplsLcAtmStdInterfaceConfTable extend interfaces capable of supporting MPLS, as is defined in [RFC3813], to include entries that also support LC-ATM (and their unique attributes). Therefore, the module can be visualized as follows. Note that the ifTable comes from [RFC2863], the mplsInterfaceTable from [RFC3813], and the mplsLcAtmStdInterfaceConfTable from the MPLS-LC-ATM-STD-MIB module described below. ifTable mplsInterfaceTable mplsLcAtmStdInterfaceConfTable .1 .2 .2 .3 .4 .4 .4 .5 Nadeau & Hegde Standards Track [Page 3] RFC 4368 MPLS LC ATM and FR MIBs January 2006 In the example shown above, five interfaces exist on the device in question. Of those interfaces, those with ifIndex = .2 and .4 are of ifType = mpls(166) indicating that they are capable of MPLS. Of those two, the entry with index .4 is capable of MPLS LC-ATM operations. Note that the label partition model utilized by the authors of this document reflects widespread implementation and is seen by the MPLS working group as sufficiently flexible to meet the operational needs, even if it is more restrictive than [RFC3035] allows. To this end, we have limited the control and unlabeled VPI and VCI to single values. Note that mplsLcAtmStdUnlabTrafVci and mplsLcAtmStdCtrlVci MUST not be equal; nor should mplsLcAtmStdCtrlVpi or mplsLcAtmStdUnlabTrafVpi be equal. 6. Structure of the MPLS-LC-FR-STD-MIB Module The MPLS-LC-FR-STD-MIB module is structured simply as a table of entries that sparsely extend those found in the interfaces table. In particular, the entries in the mplsLcFrStdInterfaceConfTable extend interfaces capable of supporting MPLS, as is defined in [RFC3813], to include entries that also support LC-Frame Relay (and their unique attributes). Therefore, the module can be visualized as follows. Note that the ifTable comes from [RFC2863], the mplsInterfaceTable from [RFC3813], and the mplsLcAtmStdInterfaceConfTable from the MPLS-LC-FR-STD-MIB module described below. ifTable mplsInterfaceTable mplsLcFrStdInterfaceConfTable .1 .2 .2 .3 .4 .4 .4 .5 In the example shown above, five interfaces exist on the device in question. Of those interfaces, those with ifIndex = .2 and .4 are of ifType = mpls(166) indicating that they are capable of MPLS. Of those two, the entry with index .4 is capable of MPLS LC-Frame Relay operations. Note that even though the architecture as described in [RFC3034] calls for supporting mixed labeled and unlabeled traffic, this MIB does not support that, as this capability does not seem to be used operationally. Note that the DLCI ranges represented by mplsLcFrStdTrafficMinDlci to mplsLcFrStdTrafficMaxDlci and mplsLcFrStdCtrlMinDlci to mplsLcFrStdCtrlMaxDlci MUST not overlap. Nadeau & Hegde Standards Track [Page 4] RFC 4368 MPLS LC ATM and FR MIBs January 2006 7. MPLS Label-Controlled ATM MIB Definitions The following MIB module imports from [RFC2514], [RFC3811], and [RFC3813]. MPLS-LC-ATM-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF RowStatus, StorageType, TruthValue FROM SNMPv2-TC AtmVpIdentifier FROM ATM-TC-MIB mplsStdMIB, MplsAtmVcIdentifier FROM MPLS-TC-STD-MIB mplsInterfaceIndex FROM MPLS-LSR-STD-MIB ; mplsLcAtmStdMIB MODULE-IDENTITY LAST-UPDATED "200601120000Z" -- 12 January 2006 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Thomas D. Nadeau Postal: Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Tel: +1-978-244-3051 Email: tnadeau@cisco.com Subrahmanya Hegde Postal: Cisco Systems, Inc. 225 East Tazman Drive Tel: +1-408-525-6562 Email: subrah@cisco.com General comments should be sent to mpls@uu.net " DESCRIPTION "This MIB module contains managed object definitions for MPLS Label-Controlled ATM interfaces as defined in [RFC3035]. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4368; see the RFC itself for full legal notices." Nadeau & Hegde Standards Track [Page 5] RFC 4368 MPLS LC ATM and FR MIBs January 2006 -- Revision history. REVISION "200601120000Z" -- 12 January 2006 DESCRIPTION "Initial revision, published as part of RFC 4368." ::= { mplsStdMIB 9 } -- Top level components of this MIB module. -- Tables, Scalars, Notifications, Conformance mplsLcAtmStdNotifications OBJECT IDENTIFIER ::= { mplsLcAtmStdMIB 0 } mplsLcAtmStdObjects OBJECT IDENTIFIER ::= { mplsLcAtmStdMIB 1 } mplsLcAtmStdConformance OBJECT IDENTIFIER ::= { mplsLcAtmStdMIB 2 } -- MPLS LC-ATM Interface Configuration Table. mplsLcAtmStdInterfaceConfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLcAtmStdInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface MPLS LC-ATM capability and associated information. In particular, this table sparsely extends the MPLS-LSR-STD-MIB's mplsInterfaceConfTable." ::= { mplsLcAtmStdObjects 1 } mplsLcAtmStdInterfaceConfEntry OBJECT-TYPE SYNTAX MplsLcAtmStdInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LSR for every interface capable of supporting MPLS LC-ATM. Each entry in this table will exist only if a corresponding entry in ifTable and mplsInterfaceConfTable exists. If the associated entries in ifTable and mplsInterfaceConfTable are deleted, the corresponding entry in this table must also be deleted shortly thereafter." INDEX { mplsInterfaceIndex } ::= { mplsLcAtmStdInterfaceConfTable 1 } MplsLcAtmStdInterfaceConfEntry ::= SEQUENCE { mplsLcAtmStdCtrlVpi AtmVpIdentifier, mplsLcAtmStdCtrlVci MplsAtmVcIdentifier, Nadeau & Hegde Standards Track [Page 6] RFC 4368 MPLS LC ATM and FR MIBs January 2006 mplsLcAtmStdUnlabTrafVpi AtmVpIdentifier, mplsLcAtmStdUnlabTrafVci MplsAtmVcIdentifier, mplsLcAtmStdVcMerge TruthValue, mplsLcAtmVcDirectlyConnected TruthValue, mplsLcAtmLcAtmVPI AtmVpIdentifier, mplsLcAtmStdIfConfRowStatus RowStatus, mplsLcAtmStdIfConfStorageType StorageType } mplsLcAtmStdCtrlVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "This is the VPI value over which this LSR is willing to accept control traffic on this interface." ::= { mplsLcAtmStdInterfaceConfEntry 1 } mplsLcAtmStdCtrlVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "This is the VCI value over which this LSR is willing to accept control traffic on this interface." ::= { mplsLcAtmStdInterfaceConfEntry 2 } mplsLcAtmStdUnlabTrafVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "This is the VPI value over which this LSR is willing to accept unlabeled traffic on this interface." ::= { mplsLcAtmStdInterfaceConfEntry 3 } mplsLcAtmStdUnlabTrafVci OBJECT-TYPE SYNTAX MplsAtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "This is the VCI value over which this LSR is willing to accept unlabeled traffic on this interface." ::= { mplsLcAtmStdInterfaceConfEntry 4 } Nadeau & Hegde Standards Track [Page 7] RFC 4368 MPLS LC ATM and FR MIBs January 2006 mplsLcAtmStdVcMerge OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If set to true(1), indicates that this interface is capable of ATM VC merge; otherwise, it MUST be set to false(2)." DEFVAL { false } ::= { mplsLcAtmStdInterfaceConfEntry 5 } mplsLcAtmVcDirectlyConnected OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This value indicates whether an LC-ATM is directly or indirectly (by means of a VP) connected. If set to true(1), indicates that this interface is directly connected LC-ATM; otherwise, it MUST be set to false(2). Note that although it can be intimated from RFC 3057 that multiple VPs may be used, in practice only a single one is used, and therefore the authors of this MIB module have chosen to model it as such." DEFVAL { true } ::= { mplsLcAtmStdInterfaceConfEntry 6 } mplsLcAtmLcAtmVPI OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "This is the VPI value used for indirectly connected LC-ATM interfaces. For these interfaces, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field (see [RFC3035]). If the interface is directly connected, this value MUST be set to zero." DEFVAL { 0 } ::= { mplsLcAtmStdInterfaceConfEntry 7 } mplsLcAtmStdIfConfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Nadeau & Hegde Standards Track [Page 8] RFC 4368 MPLS LC ATM and FR MIBs January 2006 "This object is used to create and delete entries in this table. When configuring entries in this table, the corresponding ifEntry and mplsInterfaceConfEntry MUST exist beforehand. If a manager attempts to create an entry for a corresponding mplsInterfaceConfEntry that does not support LC-ATM, the agent MUST return an inconsistentValue error. If this table is implemented read-only, then the agent must set this object to active(1) when this row is made active. If this table is implemented writable, then an agent MUST not allow modification to its objects once this value is set to active(1), except to mplsLcAtmStdIfConfRowStatus and mplsLcAtmStdIfConfStorageType." ::= { mplsLcAtmStdInterfaceConfEntry 8 } mplsLcAtmStdIfConfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLcAtmStdInterfaceConfEntry 9 } -- End of mplsLcAtmStdInterfaceConfTable -- Module compliance. mplsLcAtmStdCompliances OBJECT IDENTIFIER ::= { mplsLcAtmStdConformance 1 } mplsLcAtmStdGroups OBJECT IDENTIFIER ::= { mplsLcAtmStdConformance 2 } -- Compliance requirement for full compliance mplsLcAtmStdModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for MPLS-LC-ATM-STD-MIB. Such devices can be monitored and also be configured using this MIB module." Nadeau & Hegde Standards Track [Page 9] RFC 4368 MPLS LC ATM and FR MIBs January 2006 MODULE -- this module MANDATORY-GROUPS { mplsLcAtmStdIfGroup } OBJECT mplsLcAtmStdIfConfRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." ::= { mplsLcAtmStdCompliances 1 } -- Compliance requirement for read-only implementations. mplsLcAtmStdModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for MPLS-LC-ATM-STD-MIB. Such devices can be monitored but cannot be configured using this MIB module. " MODULE -- this module MANDATORY-GROUPS { mplsLcAtmStdIfGroup } -- mplsLcAtmStdInterfaceConfTable OBJECT mplsLcAtmStdCtrlVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmStdCtrlVci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmStdUnlabTrafVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmStdUnlabTrafVci Nadeau & Hegde Standards Track [Page 10] RFC 4368 MPLS LC ATM and FR MIBs January 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmStdVcMerge MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmStdIfConfRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmVcDirectlyConnected MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmLcAtmVPI MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcAtmStdIfConfStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mplsLcAtmStdCompliances 2 } -- Units of conformance. mplsLcAtmStdIfGroup OBJECT-GROUP OBJECTS { mplsLcAtmStdCtrlVpi, mplsLcAtmStdCtrlVci, mplsLcAtmStdUnlabTrafVpi, mplsLcAtmStdUnlabTrafVci, mplsLcAtmStdVcMerge, mplsLcAtmVcDirectlyConnected, mplsLcAtmLcAtmVPI, mplsLcAtmStdIfConfRowStatus, mplsLcAtmStdIfConfStorageType } STATUS current DESCRIPTION "Collection of objects needed for MPLS LC-ATM Nadeau & Hegde Standards Track [Page 11] RFC 4368 MPLS LC ATM and FR MIBs January 2006 interface configuration." ::= { mplsLcAtmStdGroups 1 } END 8. MPLS Label-Controlled Frame Relay MIB Definitions The following MIB module imports from [RFC2115], [RFC3811], and [RFC3813]. MPLS-LC-FR-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF RowStatus, StorageType FROM SNMPv2-TC mplsInterfaceIndex FROM MPLS-LSR-STD-MIB DLCI FROM FRAME-RELAY-DTE-MIB mplsStdMIB FROM MPLS-TC-STD-MIB ; mplsLcFrStdMIB MODULE-IDENTITY LAST-UPDATED "200601120000Z" -- 12 January 2006 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Subrahmanya Hegde Email: subrah@cisco.com General comments should be sent to mpls@uu.net " DESCRIPTION "This MIB module contains managed object definitions for MPLS Label-Controlled Frame-Relay interfaces as defined in (RFC3034). Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4368; see the RFC itself for full legal notices." Nadeau & Hegde Standards Track [Page 12] RFC 4368 MPLS LC ATM and FR MIBs January 2006 -- Revision history. REVISION "200601120000Z" -- 12 January 2006 DESCRIPTION "Initial revision, published as part of RFC 4368." ::= { mplsStdMIB 10 } -- Top level components of this MIB module. -- Tables, Scalars, Notifications, Conformance mplsLcFrStdNotifications OBJECT IDENTIFIER ::= { mplsLcFrStdMIB 0 } mplsLcFrStdObjects OBJECT IDENTIFIER ::= { mplsLcFrStdMIB 1 } mplsLcFrStdConformance OBJECT IDENTIFIER ::= { mplsLcFrStdMIB 2 } -- MPLS LC-FR Interface Configuration Table. mplsLcFrStdInterfaceConfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLcFrStdInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface MPLS LC-FR capability and associated information. In particular, this table sparsely extends the MPLS-LSR-STD-MIB's mplsInterfaceConfTable." ::= { mplsLcFrStdObjects 1 } mplsLcFrStdInterfaceConfEntry OBJECT-TYPE SYNTAX MplsLcFrStdInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LSR for every interface capable of supporting MPLS LC-FR. Each entry in this table will exist only if a corresponding entry in ifTable and mplsInterfaceConfTable exists. If the associated entries in ifTable and mplsInterfaceConfTable are deleted, the corresponding entry in this table must also be deleted shortly thereafter." INDEX { mplsInterfaceIndex } ::= { mplsLcFrStdInterfaceConfTable 1 } MplsLcFrStdInterfaceConfEntry ::= SEQUENCE { mplsLcFrStdTrafficMinDlci DLCI, mplsLcFrStdTrafficMaxDlci DLCI, mplsLcFrStdCtrlMinDlci DLCI, mplsLcFrStdCtrlMaxDlci DLCI, mplsLcFrStdInterfaceConfRowStatus RowStatus, Nadeau & Hegde Standards Track [Page 13] RFC 4368 MPLS LC ATM and FR MIBs January 2006 mplsLcFrStdInterfaceConfStorageType StorageType } mplsLcFrStdTrafficMinDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-create STATUS current DESCRIPTION "This is the minimum DLCI value over which this LSR is willing to accept traffic on this interface." ::= { mplsLcFrStdInterfaceConfEntry 1 } mplsLcFrStdTrafficMaxDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-create STATUS current DESCRIPTION "This is the max DLCI value over which this LSR is willing to accept traffic on this interface." ::= { mplsLcFrStdInterfaceConfEntry 2 } mplsLcFrStdCtrlMinDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-create STATUS current DESCRIPTION "This is the min DLCI value over which this LSR is willing to accept control traffic on this interface." ::= { mplsLcFrStdInterfaceConfEntry 3 } mplsLcFrStdCtrlMaxDlci OBJECT-TYPE SYNTAX DLCI MAX-ACCESS read-create STATUS current DESCRIPTION "This is the max DLCI value over which this LSR is willing to accept control traffic on this interface." ::= { mplsLcFrStdInterfaceConfEntry 4 } mplsLcFrStdInterfaceConfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Nadeau & Hegde Standards Track [Page 14] RFC 4368 MPLS LC ATM and FR MIBs January 2006 "This object is used to create and delete entries in this table. When configuring entries in this table, the corresponding ifEntry and mplsInterfaceConfEntry MUST exist beforehand. If a manager attempts to create an entry for a corresponding mplsInterfaceConfEntry that does not support LC-FR, the agent MUST return an inconsistentValue error. If this table is implemented read-only, then the agent must set this object to active(1) when this row is made active. If this table is implemented writable, then an agent MUST not allow modification to its objects once this value is set to active(1), except to mplsLcFrStdInterfaceConfRowStatus and mplsLcFrStdInterfaceConfStorageType." ::= { mplsLcFrStdInterfaceConfEntry 5 } mplsLcFrStdInterfaceConfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent(4)' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { mplsLcFrStdInterfaceConfEntry 6 } -- End of mplsLcFrStdInterfaceConfTable -- Module compliance. mplsLcFrStdCompliances OBJECT IDENTIFIER ::= { mplsLcFrStdConformance 1 } mplsLcFrStdGroups OBJECT IDENTIFIER ::= { mplsLcFrStdConformance 2 } -- Compliance requirement for full compliance mplsLcFrStdModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for MPLS-LC-FR-STD-MIB. Such devices can be monitored and also be configured using this MIB module." Nadeau & Hegde Standards Track [Page 15] RFC 4368 MPLS LC ATM and FR MIBs January 2006 MODULE -- this module MANDATORY-GROUPS { mplsLcFrStdIfGroup } OBJECT mplsLcFrStdInterfaceConfRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." ::= { mplsLcFrStdCompliances 1 } -- Compliance requirement for read-only implementations. mplsLcFrStdModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for MPLS-LC-FR-STD-MIB. Such devices can be monitored but cannot be configured using this MIB module. " MODULE -- this module MANDATORY-GROUPS { mplsLcFrStdIfGroup } -- mplsLcFrStdInterfaceConfTable OBJECT mplsLcFrStdTrafficMinDlci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcFrStdTrafficMaxDlci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcFrStdCtrlMinDlci MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau & Hegde Standards Track [Page 16] RFC 4368 MPLS LC ATM and FR MIBs January 2006 OBJECT mplsLcFrStdCtrlMaxDlci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcFrStdInterfaceConfRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsLcFrStdInterfaceConfStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mplsLcFrStdCompliances 2 } -- Units of conformance. mplsLcFrStdIfGroup OBJECT-GROUP OBJECTS { mplsLcFrStdTrafficMinDlci, mplsLcFrStdTrafficMaxDlci, mplsLcFrStdCtrlMinDlci, mplsLcFrStdCtrlMaxDlci, mplsLcFrStdInterfaceConfRowStatus, mplsLcFrStdInterfaceConfStorageType } STATUS current DESCRIPTION "Collection of objects needed for MPLS LC-FR interface configuration." ::= { mplsLcFrStdGroups 1 } END Nadeau & Hegde Standards Track [Page 17] RFC 4368 MPLS LC ATM and FR MIBs January 2006 9. Acknowledgments We wish to thank Joan Cucchiara and Carlos Pignataro for their comments on this document. 10. Security Considerations It is clear that these MIB modules are potentially useful for monitoring MPLS LSRs supporting LC-ATM and/or LC-FR. These MIBs can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the MplsLcAtmStdInterfaceConfTable and mplsLcFrStdInterfaceConfTable collectively contain objects that may be used to provision MPLS LC or FR-enabled interfaces. Unauthorized access to objects in these tables could result in disruption of traffic on the network. This is especially true if traffic has been established over these interfaces. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent that implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the MplsLcAtmStdInterfaceConfTable and mplsLcFrStdInterfaceConfTable collectively show the LC-ATM and/or LC-FR interfaces, their associated configurations, and their linkages to other MPLS-related configuration and/or performance statistics. Administrators not wishing to reveal Nadeau & Hegde Standards Track [Page 18] RFC 4368 MPLS LC ATM and FR MIBs January 2006 this information should consider these objects sensitive/vulnerable and take precautions so they are not revealed. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. IANA Considerations As described in and as requested in the MPLS-TC-STD-MIB [RFC3811], MPLS-related standards track MIB modules should be rooted under the mplsStdMIB subtree. There are 2 MPLS MIB modules contained in this document; each of the following "IANA Considerations" subsections requested from IANA a new assignment under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. 11.1. IANA Considerations for MPLS-LC-ATM-STD-MIB The IANA has assigned { mplsStdMIB 9 } to the MPLS-LC-ATM-STD-MIB module specified in this document. 11.2. IANA Considerations for MPLS-LC-FR-STD-MIB The IANA has assigned { mplsStdMIB 10 } to the MPLS-LC-FR-STD-MIB module specified in this document. Nadeau & Hegde Standards Track [Page 19] RFC 4368 MPLS LC ATM and FR MIBs January 2006 12. References 12.1. Normative References [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001. [RFC2115] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [RFC2514] Noto, M., Spiegel, E., and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Nadeau & Hegde Standards Track [Page 20] RFC 4368 MPLS LC ATM and FR MIBs January 2006 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 12.2. Informative References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719 Phone: +1-978-936-1470 EMail: tnadeau@cisco.com Subrahmanya Hegde Cisco Systems, Inc. 225 East Tazman Drive San Jose, CA 95134 Phone: +1-408-525-6562 EMail: subrah@cisco.com Nadeau & Hegde Standards Track [Page 21] RFC 4368 MPLS LC ATM and FR MIBs January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nadeau & Hegde Standards Track [Page 22] snmp-mibs-downloader-1.1/mibrfcs/rfc4369.txt0000644000000000000000000016373211402176072015604 0ustar Network Working Group K. Gibbons Request for Comments: 4369 McDATA Corporation Category: Standards Track C. Monia Consultant J. Tseng Riverbed Technology F. Travostino Nortel January 2006 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Introduction ....................................................2 3. Technical Description ...........................................3 4. MIB Definition ..................................................4 5. IANA Considerations ............................................25 6. Security Considerations ........................................25 7. Normative References ...........................................26 8. Informative References .........................................27 Gibbons, et al. Standards Track [Page 1] RFC 4369 iFCP MIB January 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction The iFCP protocol can be used by FC-to-IP-based storage gateways for Fibre Channel Protocol (FCP) storage interconnects. Figure 1 provides an example of an interconnect between iFCP gateways. Gateway Region Gateway Region +--------+ +--------+ +--------+ +--------+ | FC | | FC | | FC | | FC | | Device | | Device | | Device | | Device | Fibre |........| |........| FC |........| |........| Channel | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain | | | | ^ +---+----+ +---+----+ +----+---+ +----+---+ | | F_PORT | | F_PORT | | F_PORT | | F_PORT | | =+========+==+========+===========+========+==+========+========== | iFCP Layer |<--------->| iFCP Layer | | |....................| ^ |....................| | | iFCP Portal | | | iFCP Portal | v +--------+-----------+ | +----------+---------+ IP iFCP|Gateway Control iFCP|Gateway Network | Data | | | | | |<------Encapsulated Frames------->| | +------------------+ | | | | | +------+ IP Network +--------+ | | +------------------+ Figure 1: Interconnect between iFCP Gateways Gibbons, et al. Standards Track [Page 2] RFC 4369 iFCP MIB January 2006 The iFCP MIB Module is designed to allow SNMP to be used to monitor and manage local iFCP gateway instances, including the configuration of iFCP sessions between gateways. 3. Technical Description The iFCP MIB Module is divided into sections for iFCP local gateway instance management, iFCP session management, and iFCP session statistics. The section for iFCP gateway management provides default settings and information about each local instance. A single management entity can monitor multiple local gateway instances. Each local gateway is conceptually an independent gateway that has both Fibre Channel and IP interfaces. The default IP Time Out Value (IP_TOV) is configurable for each gateway. Other standard MIBs, such as the Fibre Management MIB [RFC4044] or Interfaces Group MIB [RFC2863], can be used to manage non-iFCP-specific gateway parameters. The local gateway instance section provides iFCP-specific information as well as optional links to other standard management MIBs. The iFCP session management section provides information on iFCP sessions that use one of the local iFCP gateway instances. This section allows the management of specific iFCP parameters, including changing the IP_TOV from the default setting of the gateway. The iFCP session statistics section provides statistical information on the iFCP sessions that use one of the local iFCP gateways. These tables augment the session management table. Additional statistical information for an iFCP gateway or session, that is not iFCP-specific, can be obtained using other standard MIBs. The iFCP statistics are provided in both standard and low-capacity (counter32) methods. The following MIB module imports from RMON2-MIB [RFC2021], SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], HCNUM-TC [RFC2856], IF-MIB [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET- ADDRESS-MIB [RFC4001], FC-MGMT-MIB [RFC4044], and ENTITY-MIB (v3) [RFC4133]. Gibbons, et al. Standards Track [Page 3] RFC 4369 iFCP MIB January 2006 4. MIB Definition IFCP-MGMT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Gauge32, Integer32, Unsigned32, transmission FROM SNMPv2-SMI OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp, TruthValue, StorageType FROM SNMPv2-TC -- From RFC 2021 ZeroBasedCounter32 FROM RMON2-MIB -- From RFC 2856 ZeroBasedCounter64 FROM HCNUM-TC -- From RFC 2863 InterfaceIndexOrZero FROM IF-MIB -- From RFC 3411 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- From RFC 4001 InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- From RFC 4044 FcNameIdOrZero, FcAddressIdOrZero Gibbons, et al. Standards Track [Page 4] RFC 4369 iFCP MIB January 2006 FROM FC-MGMT-MIB -- From RFC 4133 PhysicalIndexOrZero FROM ENTITY-MIB ; ifcpMgmtMIB MODULE-IDENTITY LAST-UPDATED "200601170000Z" ORGANIZATION "IETF IPS Working Group" CONTACT-INFO " Attn: Kevin Gibbons McDATA Corporation 4555 Great America Pkwy Santa Clara, CA 95054-1208 USA Phone: (408) 567-5765 EMail: kevin.gibbons@mcdata.com Charles Monia Consultant 7553 Morevern Circle San Jose, CA 95135 USA EMail: charles_monia@yahoo.com Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107 USA Phone: (650) 274-2109 EMail: joshtseng@yahoo.com Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA Phone: (978) 288-7708 EMail: travos@nortel.com" DESCRIPTION "This module defines management information specific to internet Fibre Channel Protocol (iFCP) gateway management. Copyright (C) The Internet Society 2006. This version of this MIB module is part of RFC 4369; see the RFC itself for full legal notices." REVISION "200601170000Z" DESCRIPTION Gibbons, et al. Standards Track [Page 5] RFC 4369 iFCP MIB January 2006 "Initial version of iFCP Management Module. This MIB published as RFC 4369." ::= { transmission 230 } -- -- Textual Conventions -- IfcpIpTOVorZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The maximum propagation delay, in seconds, for an encapsulated FC frame to traverse the IP network. A value of 0 implies fibre channel frame lifetime limits will not be enforced." REFERENCE "RFC 4172, iFCP Protocol Specification" SYNTAX Unsigned32 (0..3600) IfcpLTIorZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The value for the Liveness Test Interval (LTI) being used in an iFCP connection, in seconds. A value of 0 implies no Liveness Test Interval will be used." REFERENCE "RFC 4172, iFCP Protocol Specification" SYNTAX Unsigned32 (0..65535) IfcpSessionStates ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value for an iFCP session state." SYNTAX INTEGER {down(1), openPending(2), open(3)} IfcpAddressMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The values for iFCP Address Translation Mode." REFERENCE "RFC 4172, iFCP Protocol Specification" SYNTAX INTEGER {addressTransparent(1), addressTranslation(2)} -- -- Internet Fibre Channel Protocol (iFCP) -- ifcpGatewayObjects OBJECT IDENTIFIER ::= {ifcpMgmtMIB 1} ifcpGatewayConformance OBJECT IDENTIFIER ::= {ifcpMgmtMIB 2} Gibbons, et al. Standards Track [Page 6] RFC 4369 iFCP MIB January 2006 -- -- Local iFCP Gateway Instance Information ================== -- ifcpLclGatewayInfo OBJECT IDENTIFIER ::= {ifcpGatewayObjects 1} ifcpLclGtwyInstTable OBJECT-TYPE SYNTAX SEQUENCE OF IfcpLclGtwyInstEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about all local iFCP Gateway instances that can be monitored and controlled. This table contains an entry for each local iFCP Gateway instance that is being managed." ::= {ifcpLclGatewayInfo 1} ifcpLclGtwyInstEntry OBJECT-TYPE SYNTAX IfcpLclGtwyInstEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the local iFCP Gateway Instance table. Parameters and settings for the gateway are found here." INDEX { ifcpLclGtwyInstIndex } ::= {ifcpLclGtwyInstTable 1} IfcpLclGtwyInstEntry ::= SEQUENCE { ifcpLclGtwyInstIndex Unsigned32, ifcpLclGtwyInstPhyIndex PhysicalIndexOrZero, ifcpLclGtwyInstVersionMin Unsigned32, ifcpLclGtwyInstVersionMax Unsigned32, ifcpLclGtwyInstAddrTransMode IfcpAddressMode, ifcpLclGtwyInstFcBrdcstSupport TruthValue, ifcpLclGtwyInstDefaultIpTOV IfcpIpTOVorZero, ifcpLclGtwyInstDefaultLTInterval IfcpLTIorZero, ifcpLclGtwyInstDescr SnmpAdminString, ifcpLclGtwyInstNumActiveSessions Gauge32, ifcpLclGtwyInstStorageType StorageType } ifcpLclGtwyInstIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer value to uniquely identify this iFCP Gateway from other local Gateway instances." Gibbons, et al. Standards Track [Page 7] RFC 4369 iFCP MIB January 2006 ::= {ifcpLclGtwyInstEntry 1} ifcpLclGtwyInstPhyIndex OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "An index indicating the location of this local gateway within a larger entity, if one exists. If supported, this is the entPhysicalIndex from the Entity MIB (Version 3), for this iFCP Gateway. If not supported, or if not related to a physical entity, then the value of this object is 0." REFERENCE "Entity MIB (Version 3)" ::= {ifcpLclGtwyInstEntry 2} ifcpLclGtwyInstVersionMin OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum iFCP protocol version supported by the local iFCP gateway instance." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpLclGtwyInstEntry 3} ifcpLclGtwyInstVersionMax OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum iFCP protocol version supported by the local iFCP gateway instance." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpLclGtwyInstEntry 4} ifcpLclGtwyInstAddrTransMode OBJECT-TYPE SYNTAX IfcpAddressMode MAX-ACCESS read-write STATUS current DESCRIPTION "The local iFCP gateway operating mode. Changing this value may cause existing sessions to be disrupted." REFERENCE "RFC 4172, iFCP Protocol Specification" DEFVAL { addressTranslation } ::= {ifcpLclGtwyInstEntry 5} ifcpLclGtwyInstFcBrdcstSupport OBJECT-TYPE SYNTAX TruthValue Gibbons, et al. Standards Track [Page 8] RFC 4369 iFCP MIB January 2006 MAX-ACCESS read-write STATUS current DESCRIPTION "Whether the local iFCP gateway supports FC Broadcast. Changing this value may cause existing sessions to be disrupted." REFERENCE "RFC 4172, iFCP Protocol Specification" DEFVAL { false } ::= {ifcpLclGtwyInstEntry 6} ifcpLclGtwyInstDefaultIpTOV OBJECT-TYPE SYNTAX IfcpIpTOVorZero MAX-ACCESS read-write STATUS current DESCRIPTION "The default IP_TOV used for iFCP sessions at this gateway. This is the default maximum propagation delay that will be used for an iFCP session. The value can be changed on a per-session basis. The valid range is 0 - 3600 seconds. A value of 0 implies that fibre channel frame lifetime limits will not be enforced." REFERENCE "RFC 4172, iFCP Protocol Specification" DEFVAL { 6 } ::= {ifcpLclGtwyInstEntry 7} ifcpLclGtwyInstDefaultLTInterval OBJECT-TYPE SYNTAX IfcpLTIorZero MAX-ACCESS read-write STATUS current DESCRIPTION "The default Liveness Test Interval (LTI), in seconds, used for iFCP sessions at this gateway. This is the default value for an iFCP session and can be changed on a per-session basis. The valid range is 0 - 65535 seconds. A value of 0 implies no Liveness Test Interval will be performed on a session." REFERENCE "RFC 4172, iFCP Protocol Specification" DEFVAL { 10 } ::= {ifcpLclGtwyInstEntry 8} ifcpLclGtwyInstDescr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-write STATUS current DESCRIPTION "A user-entered description for this iFCP Gateway." DEFVAL { "" } ::= {ifcpLclGtwyInstEntry 9} Gibbons, et al. Standards Track [Page 9] RFC 4369 iFCP MIB January 2006 ifcpLclGtwyInstNumActiveSessions OBJECT-TYPE SYNTAX Gauge32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of iFCP sessions in the open or open-pending state." ::= {ifcpLclGtwyInstEntry 10} ifcpLclGtwyInstStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this row. Parameter values defined for a gateway are usually non-volatile, but may be volatile or permanent in some configurations. If permanent, then the following parameters must have read-write access: ifcpLclGtwyInstAddrTransMode, ifcpLclGtwyInstDefaultIpTOV, and ifcpLclGtwyInstDefaultLTInterval." DEFVAL { nonVolatile } ::= {ifcpLclGtwyInstEntry 11} -- -- iFCP N Port Session Information ============================ -- ifcpNportSessionInfo OBJECT IDENTIFIER ::= {ifcpGatewayObjects 2} ifcpSessionAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IfcpSessionAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An iFCP session consists of the pair of N_PORTs comprising the session endpoints joined by a single TCP/IP connection. This table provides information on each iFCP session currently using a local iFCP Gateway instance. iFCP sessions are created and removed by the iFCP Gateway instances, which are reflected in this table." ::= {ifcpNportSessionInfo 1} ifcpSessionAttributesEntry OBJECT-TYPE SYNTAX IfcpSessionAttributesEntry MAX-ACCESS not-accessible Gibbons, et al. Standards Track [Page 10] RFC 4369 iFCP MIB January 2006 STATUS current DESCRIPTION "Each entry contains information about one iFCP session consisting of a pair of N_PORTs joined by a single TCP/IP connection. This table's INDEX includes ifcpLclGtwyInstIndex, which identifies the local iFCP Gateway instance that created the session for the entry. Soon after an entry is created in this table for an iFCP session, it will correspond to an entry in the tcpConnectionTable of the TCP-MIB (RFC 4022). The corresponding entry might represent a preexisting TCP connection, or it might be a newly-created entry. (Note that if IPv4 is being used, an entry in RFC 2012's tcpConnTable may also correspond.) The values of ifcpSessionLclPrtlAddrType and ifcpSessionRmtPrtlIfAddrType in this table and the values of tcpConnectionLocalAddressType and tcpConnectionRemAddressType used as INDEX values for the corresponding entry in the tcpConnectionTable should be the same; this makes it simpler to locate a session's TCP connection in the TCP-MIB. (Of course, all four values need to be 'ipv4' if there's a corresponding entry in the tcpConnTable.) If an entry is created in this table for a session, prior to knowing which local and/or remote port numbers will be used for the TCP connection, then ifcpSessionLclPrtlTcpPort and/or ifcpSessionRmtPrtlTcpPort have the value zero until such time as they can be updated to the port numbers (to be) used for the connection. (Thus, a port value of zero should not be used to locate a session's TCP connection in the TCP-MIB.) When the TCP connection terminates, the entry in the tcpConnectionTable and the entry in this table both get deleted (and, if applicable, so does the entry in the tcpConnTable)." INDEX { ifcpLclGtwyInstIndex, ifcpSessionIndex } ::= {ifcpSessionAttributesTable 1} IfcpSessionAttributesEntry ::= SEQUENCE { ifcpSessionIndex Integer32, ifcpSessionLclPrtlIfIndex InterfaceIndexOrZero, ifcpSessionLclPrtlAddrType InetAddressType, ifcpSessionLclPrtlAddr InetAddress, ifcpSessionLclPrtlTcpPort InetPortNumber, ifcpSessionLclNpWwun FcNameIdOrZero, ifcpSessionLclNpFcid FcAddressIdOrZero, ifcpSessionRmtNpWwun FcNameIdOrZero, ifcpSessionRmtPrtlIfAddrType InetAddressType, ifcpSessionRmtPrtlIfAddr InetAddress, ifcpSessionRmtPrtlTcpPort InetPortNumber, Gibbons, et al. Standards Track [Page 11] RFC 4369 iFCP MIB January 2006 ifcpSessionRmtNpFcid FcAddressIdOrZero, ifcpSessionRmtNpFcidAlias FcAddressIdOrZero, ifcpSessionIpTOV IfcpIpTOVorZero, ifcpSessionLclLTIntvl IfcpLTIorZero, ifcpSessionRmtLTIntvl IfcpLTIorZero, ifcpSessionBound TruthValue, ifcpSessionStorageType StorageType } ifcpSessionIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The iFCP session index is a unique value used as an index to the table, along with a specific local iFCP Gateway instance. This index is used because the local N Port and remote N Port information would create an complex index that would be difficult to implement." ::= {ifcpSessionAttributesEntry 1} ifcpSessionLclPrtlIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This is the interface index in the IF-MIB ifTable being used as the local portal in this session, as described in the IF-MIB. If the local portal is not associated with an entry in the ifTable, then the value is 0. The ifType of the interface will generally be a type that supports IP, but an implementation may support iFCP using other protocols. This object can be used to obtain additional information about the interface." REFERENCE "RFC 2863, The Interfaces Group MIB (IF-MIB)" ::= {ifcpSessionAttributesEntry 2} ifcpSessionLclPrtlAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address in ifcpSessionLclIfAddr." ::= {ifcpSessionAttributesEntry 3} ifcpSessionLclPrtlAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only Gibbons, et al. Standards Track [Page 12] RFC 4369 iFCP MIB January 2006 STATUS current DESCRIPTION "This is the external IP address of the interface being used for the iFCP local portal in this session. The address type is defined in ifcpSessionLclPrtlAddrType. If the value is a DNS name, then the name is resolved once, during the initial session instantiation." ::= {ifcpSessionAttributesEntry 4} ifcpSessionLclPrtlTcpPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "This is the TCP port number that is being used for the iFCP local portal in this session. This is normally an ephemeral port number selected by the gateway. The value may be 0 during an initial setup period." ::= {ifcpSessionAttributesEntry 5} ifcpSessionLclNpWwun OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "World Wide Unique Name of the local N Port. For an unbound session, this variable will be a zero-length string." REFERENCE "RFC 4172, iFCP Protocol Specification" DEFVAL { "" } ::= {ifcpSessionAttributesEntry 6} ifcpSessionLclNpFcid OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Fibre Channel Identifier of the local N Port. For an unbound session, this variable will be a zero-length string." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpSessionAttributesEntry 7} ifcpSessionRmtNpWwun OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "World Wide Unique Name of the remote N Port. For an unbound session, this variable will be a zero-length string." Gibbons, et al. Standards Track [Page 13] RFC 4369 iFCP MIB January 2006 REFERENCE "RFC 4172, iFCP Protocol Specification" DEFVAL { "" } ::= {ifcpSessionAttributesEntry 8} ifcpSessionRmtPrtlIfAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address in ifcpSessionRmtPrtlIfAddr." ::= {ifcpSessionAttributesEntry 9} ifcpSessionRmtPrtlIfAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is the remote gateway IP address being used for the portal on the remote iFCP gateway. The address type is defined in ifcpSessionRmtPrtlIfAddrType. If the value is a DNS name, then the name is resolved once, during the initial session instantiation." ::= {ifcpSessionAttributesEntry 10} ifcpSessionRmtPrtlTcpPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "This is the TCP port number being used for the portal on the remote iFCP gateway. Generally, this will be the iFCP canonical port. The value may be 0 during an initial setup period." DEFVAL { 3420 } ::= {ifcpSessionAttributesEntry 11} ifcpSessionRmtNpFcid OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Fibre Channel Identifier of the remote N Port. For an unbound session, this variable will be a zero-length string." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpSessionAttributesEntry 12} ifcpSessionRmtNpFcidAlias OBJECT-TYPE SYNTAX FcAddressIdOrZero Gibbons, et al. Standards Track [Page 14] RFC 4369 iFCP MIB January 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "Fibre Channel Identifier Alias assigned by the local gateway for the remote N Port. For an unbound session, this variable will be a zero-length string." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpSessionAttributesEntry 13} ifcpSessionIpTOV OBJECT-TYPE SYNTAX IfcpIpTOVorZero MAX-ACCESS read-write STATUS current DESCRIPTION "The IP_TOV being used for this iFCP session. This is the maximum propagation delay that will be used for the iFCP session. The value can be changed on a per-session basis and initially defaults to ifcpLclGtwyInstDefaultIpTOV for the local gateway instance. The valid range is 0 - 3600 seconds. A value of 0 implies fibre channel frame lifetime limits will not be enforced." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpSessionAttributesEntry 14} ifcpSessionLclLTIntvl OBJECT-TYPE SYNTAX IfcpLTIorZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Liveness Test Interval (LTI) used for this iFCP session. The value can be changed on a per-session basis and initially defaults to ifcpLclGtwyInstDefaultLTInterval for the local gateway instance. The valid range is 0 - 65535 seconds. A value of 0 implies that the gateway will not originate Liveness Test messages for the session." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpSessionAttributesEntry 15} ifcpSessionRmtLTIntvl OBJECT-TYPE SYNTAX IfcpLTIorZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Liveness Test Interval (LTI) as requested by the remote gateway instance to use for this iFCP session. This value may change over the life of the session. The valid range is 0 - 65535 seconds. A value of 0 implies that the remote gateway has not been requested to originate Liveness Test messages for Gibbons, et al. Standards Track [Page 15] RFC 4369 iFCP MIB January 2006 the session." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpSessionAttributesEntry 16} ifcpSessionBound OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates whether this session is bound to a specific local and remote N Port. Sessions by default are unbound and ready for future assignment to a local and remote N Port." REFERENCE "RFC 4172, iFCP Protocol Specification" ::= {ifcpSessionAttributesEntry 17} ifcpSessionStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this row. Parameter values defined for a session are usually non-volatile, but may be volatile or permanent in some configurations. If permanent, then ifcpSessionIpTOV must have read-write access." DEFVAL { nonVolatile } ::= {ifcpSessionAttributesEntry 18} -- -- Local iFCP Gateway Instance Session Statistics ============= -- ifcpSessionStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IfcpSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides statistics on an iFCP session." ::= {ifcpNportSessionInfo 2} ifcpSessionStatsEntry OBJECT-TYPE SYNTAX IfcpSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides iFCP-specific statistics per session." AUGMENTS {ifcpSessionAttributesEntry} Gibbons, et al. Standards Track [Page 16] RFC 4369 iFCP MIB January 2006 ::= {ifcpSessionStatsTable 1} IfcpSessionStatsEntry ::= SEQUENCE { ifcpSessionState IfcpSessionStates, ifcpSessionDuration Unsigned32, ifcpSessionTxOctets ZeroBasedCounter64, ifcpSessionRxOctets ZeroBasedCounter64, ifcpSessionTxFrames ZeroBasedCounter64, ifcpSessionRxFrames ZeroBasedCounter64, ifcpSessionStaleFrames ZeroBasedCounter64, ifcpSessionHeaderCRCErrors ZeroBasedCounter64, ifcpSessionFcPayloadCRCErrors ZeroBasedCounter64, ifcpSessionOtherErrors ZeroBasedCounter64, ifcpSessionDiscontinuityTime TimeStamp } ifcpSessionState OBJECT-TYPE SYNTAX IfcpSessionStates MAX-ACCESS read-only STATUS current DESCRIPTION "The current session operating state." ::= {ifcpSessionStatsEntry 1} ifcpSessionDuration OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates, in seconds, how long the iFCP session has been in an open or open-pending state. When a session is down, the value is reset to 0." ::= {ifcpSessionStatsEntry 2} ifcpSessionTxOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted by the iFCP gateway for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 3} ifcpSessionRxOctets OBJECT-TYPE SYNTAX ZeroBasedCounter64 Gibbons, et al. Standards Track [Page 17] RFC 4369 iFCP MIB January 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received by the iFCP gateway for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 4} ifcpSessionTxFrames OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of iFCP frames transmitted by the gateway for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 5} ifcpSessionRxFrames OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of iFCP frames received by the gateway for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 6} ifcpSessionStaleFrames OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of received iFCP frames that were stale and discarded by the gateway for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 7} ifcpSessionHeaderCRCErrors OBJECT-TYPE SYNTAX ZeroBasedCounter64 Gibbons, et al. Standards Track [Page 18] RFC 4369 iFCP MIB January 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of CRC errors that occurred in the frame header, detected by the gateway for this session. Usually, a single Header CRC error is sufficient to terminate an iFCP session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 8} ifcpSessionFcPayloadCRCErrors OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of CRC errors that occurred in the Fibre Channel frame payload, detected by the gateway for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 9} ifcpSessionOtherErrors OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of errors, other than errors explicitly measured, detected by the gateway for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifcpSessionDiscontinuityTime." ::= {ifcpSessionStatsEntry 10} ifcpSessionDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one (or more) of the ifcpSessionStatsTable counters suffered a discontinuity. The relevant counters are the specific Counter64-based instances associated with the ifcpSessionStatsTable: ifcpSessionTxOctets, Gibbons, et al. Standards Track [Page 19] RFC 4369 iFCP MIB January 2006 ifcpSessionRxOctets, ifcpSessionTxFrames, ifcpSessionRxFrames, ifcpSessionStaleFrames, ifcpSessionHeaderCRCErrors, ifcpSessionFcPayloadCRCErrors, and ifcpSessionOtherErrors. If no such discontinuities have occurred since the last reinitialization of the local management subsystem, then this object contains a zero value." ::= {ifcpSessionStatsEntry 11} -- -- Low Capacity Statistics -- ifcpSessionLcStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IfcpSessionLcStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides low capacity statistics for an iFCP session. These are provided for backward compatibility with systems that do not support Counter64-based objects. At 1-Gbps rates, a Counter32-based object can wrap as often as every 34 seconds. Counter32-based objects can be sufficient for many situations. However, when possible, it is recommended to use the high capacity statistics in ifcpSessionStatsTable based on Counter64 objects." ::= {ifcpNportSessionInfo 3} ifcpSessionLcStatsEntry OBJECT-TYPE SYNTAX IfcpSessionLcStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides iFCP-specific statistics per session." AUGMENTS {ifcpSessionAttributesEntry} ::= {ifcpSessionLcStatsTable 1} IfcpSessionLcStatsEntry ::= SEQUENCE { ifcpSessionLcTxOctets ZeroBasedCounter32, ifcpSessionLcRxOctets ZeroBasedCounter32, ifcpSessionLcTxFrames ZeroBasedCounter32, ifcpSessionLcRxFrames ZeroBasedCounter32, ifcpSessionLcStaleFrames ZeroBasedCounter32, ifcpSessionLcHeaderCRCErrors ZeroBasedCounter32, ifcpSessionLcFcPayloadCRCErrors ZeroBasedCounter32, ifcpSessionLcOtherErrors ZeroBasedCounter32 } Gibbons, et al. Standards Track [Page 20] RFC 4369 iFCP MIB January 2006 ifcpSessionLcTxOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted by the iFCP gateway for this session." ::= {ifcpSessionLcStatsEntry 1} ifcpSessionLcRxOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received by the iFCP gateway for this session." ::= {ifcpSessionLcStatsEntry 2} ifcpSessionLcTxFrames OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of iFCP frames transmitted by the gateway for this session." ::= {ifcpSessionLcStatsEntry 3} ifcpSessionLcRxFrames OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of iFCP frames received by the gateway for this session." ::= {ifcpSessionLcStatsEntry 4} ifcpSessionLcStaleFrames OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of received iFCP frames that were stale and discarded by the gateway for this session." ::= {ifcpSessionLcStatsEntry 5} ifcpSessionLcHeaderCRCErrors OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only Gibbons, et al. Standards Track [Page 21] RFC 4369 iFCP MIB January 2006 STATUS current DESCRIPTION "The total number of CRC errors that occurred in the frame header, detected by the gateway for this session. Usually, a single Header CRC error is sufficient to terminate an iFCP session." ::= {ifcpSessionLcStatsEntry 6} ifcpSessionLcFcPayloadCRCErrors OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of CRC errors that occurred in the Fibre Channel frame payload, detected by the gateway for this session." ::= {ifcpSessionLcStatsEntry 7} ifcpSessionLcOtherErrors OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of errors, other than errors explicitly measured, detected by the gateway for this session." ::= {ifcpSessionLcStatsEntry 8} --========================================================== ifcpCompliances OBJECT IDENTIFIER ::= {ifcpGatewayConformance 1} ifcpGatewayCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Implementation requirements for iFCP MIB compliance." MODULE -- this module MANDATORY-GROUPS { ifcpLclGatewayGroup, ifcpLclGatewaySessionGroup, ifcpLclGatewaySessionStatsGroup, ifcpLclGatewaySessionLcStatsGroup } OBJECT ifcpSessionLclPrtlAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "Support is only required for global IPv4 Gibbons, et al. Standards Track [Page 22] RFC 4369 iFCP MIB January 2006 and IPv6 address types." OBJECT ifcpSessionRmtPrtlIfAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "Support is only required for global IPv4 and IPv6 address types." ::= {ifcpCompliances 1} ifcpGroups OBJECT IDENTIFIER ::= {ifcpGatewayConformance 2} ifcpLclGatewayGroup OBJECT-GROUP OBJECTS { ifcpLclGtwyInstPhyIndex, ifcpLclGtwyInstVersionMin, ifcpLclGtwyInstVersionMax, ifcpLclGtwyInstAddrTransMode, ifcpLclGtwyInstFcBrdcstSupport, ifcpLclGtwyInstDefaultIpTOV, ifcpLclGtwyInstDefaultLTInterval, ifcpLclGtwyInstDescr, ifcpLclGtwyInstNumActiveSessions, ifcpLclGtwyInstStorageType } STATUS current DESCRIPTION "iFCP local device info group. This group provides information about each gateway." ::= {ifcpGroups 1} ifcpLclGatewaySessionGroup OBJECT-GROUP OBJECTS { ifcpSessionLclPrtlIfIndex, ifcpSessionLclPrtlAddrType, ifcpSessionLclPrtlAddr, ifcpSessionLclPrtlTcpPort, ifcpSessionLclNpWwun, ifcpSessionLclNpFcid, ifcpSessionRmtNpWwun, ifcpSessionRmtPrtlIfAddrType, ifcpSessionRmtPrtlIfAddr, ifcpSessionRmtPrtlTcpPort, ifcpSessionRmtNpFcid, ifcpSessionRmtNpFcidAlias, ifcpSessionIpTOV, ifcpSessionLclLTIntvl, ifcpSessionRmtLTIntvl, Gibbons, et al. Standards Track [Page 23] RFC 4369 iFCP MIB January 2006 ifcpSessionBound, ifcpSessionStorageType } STATUS current DESCRIPTION "iFCP Session group. This group provides information about each iFCP session currently active between iFCP gateways." ::= {ifcpGroups 4} ifcpLclGatewaySessionStatsGroup OBJECT-GROUP OBJECTS { ifcpSessionState, ifcpSessionDuration, ifcpSessionTxOctets, ifcpSessionRxOctets, ifcpSessionTxFrames, ifcpSessionRxFrames, ifcpSessionStaleFrames, ifcpSessionHeaderCRCErrors, ifcpSessionFcPayloadCRCErrors, ifcpSessionOtherErrors, ifcpSessionDiscontinuityTime } STATUS current DESCRIPTION "iFCP Session Statistics group. This group provides statistics with 64-bit counters for each iFCP session currently active between iFCP gateways. This group is only required for agents that can support Counter64- based data types." ::= {ifcpGroups 5} ifcpLclGatewaySessionLcStatsGroup OBJECT-GROUP OBJECTS { ifcpSessionLcTxOctets, ifcpSessionLcRxOctets, ifcpSessionLcTxFrames, ifcpSessionLcRxFrames, ifcpSessionLcStaleFrames, ifcpSessionLcHeaderCRCErrors, ifcpSessionLcFcPayloadCRCErrors, ifcpSessionLcOtherErrors } STATUS current DESCRIPTION "iFCP Session Low Capacity Statistics group. This group provides statistics with low-capacity 32-bit counters Gibbons, et al. Standards Track [Page 24] RFC 4369 iFCP MIB January 2006 for each iFCP session currently active between iFCP gateways. This group is only required for agents that do not support Counter64-based data types, or that need to support SNMPv1 applications." ::= {ifcpGroups 6} END 5. IANA Considerations The IANA has made a unique MIB OID assignment under the transmission branch for IFCP-MGMT-MIB. 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Changing the following object values, with a MAX-ACCESS of read- write, may cause disruption in storage traffic: ifcpLclGtwyInstAddrTransMode ifcpLclGtwyInstFcBrdcstSupport ifcpLclGtwyInstDefaultIpTOV ifcpLclGtwyInstDefaultLTInterval ifcpSessionIpTOV Changing the following object value, with a MAX-ACCESS of read-write, may cause a user to lose track of the iFCP gateway: ifcpLclGtwyInstDescr Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Gibbons, et al. Standards Track [Page 25] RFC 4369 iFCP MIB January 2006 The following object tables provide information about storage traffic sessions, and can indicate to a user who is communicating and exchanging storage data: ifcpLclGtwyInstTable ifcpSessionAttributesTable SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Normative References [RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. Gibbons, et al. Standards Track [Page 26] RFC 4369 iFCP MIB January 2006 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005. 8. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Gibbons, et al. Standards Track [Page 27] RFC 4369 iFCP MIB January 2006 Authors' Addresses Kevin Gibbons McDATA Corporation 4555 Great America Pkwy Santa Clara, CA 95054-1208 USA Phone: (408)567-5765 EMail: kevin.gibbons@mcdata.com Charles Monia Consultant 7553 Morevern Circle San Jose, CA 95135 USA EMail: charles_monia@yahoo.com Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107 USA Phone: (650)274-2109 EMail: joshtseng@yahoo.com Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA Phone: (978)288-7708 EMail: travos@nortel.com Gibbons, et al. Standards Track [Page 28] RFC 4369 iFCP MIB January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gibbons, et al. Standards Track [Page 29] snmp-mibs-downloader-1.1/mibrfcs/rfc4382.txt0000644000000000000000000024713211402176072015574 0ustar Network Working Group T. Nadeau, Ed. Request for Comments: 4382 H. van der Linde, Ed. Category: Standards Track Cisco Systems, Inc. February 2006 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. Nadeau & van Der Linde Standards Track [Page 1] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................3 3. The Internet-Standard Management Framework ......................3 4. Assumptions and Prerequisites ...................................3 5. Brief Description of MIB Objects ................................3 5.1. mplsL3VpnVrfTable ..........................................3 5.2. mplsL3VpnIfConfTable .......................................4 5.3. mplsL3VpnVrfPerfTable ......................................4 5.4. mplsL3VpnVrfRouteTable .....................................4 5.5. MplsVpnVrfRTTable ..........................................4 6. Example of MPLS L3VPN Setup .....................................4 7. MPLS-L3VPN-STD-MIB Module Definitions ...........................5 8. Security Considerations ........................................38 9. IANA Considerations ............................................40 9.1. IANA Considerations for MPLS-L3VPN-STD-MIB ................40 10. Dedication ....................................................40 11. Acknowledgements ..............................................40 12. References ....................................................40 12.1. Normative References .....................................40 12.2. Informative References ...................................41 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. This document adopts the definitions, acronyms, and mechanisms described in [RFC4364]. Unless otherwise stated, the mechanisms of [RFC4364] apply and will not be re-described here. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Nadeau & van Der Linde Standards Track [Page 2] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 2. Terminology This document uses terminology from the document describing the MPLS architecture [RFC3031] and from the document describing MPLS Layer-3 VPNs (L3VPN) [RFC4364], as well as the MPLS architecture [RFC3031]. Throughout this document, the use of the terms "Provider Edge (PE) and Customer Edge (CE)" or "PE/CE" will be replaced by "PE" in all cases except when a network device is a CE when used in the carrier's carrier model. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Assumptions and Prerequisites It is assumed that certain things are configured and operational in order for the tables and objects described in this MIB to function correctly. These things are outlined below: - MPLS in general, must be configured and operational. - Label Distribution Protocol (LDP) paths or traffic-engineered tunnels [RFC3812] should be configured between PEs and CEs. 5. Brief Description of MIB Objects The following subsections describe the purpose of each of the objects contained in the MPLS-L3VPN-STD-MIB. 5.1. mplsL3VpnVrfTable This table represents the MPLS L3VPNs that are configured. A Network Management System (NMS) or SNMP agent creates an entry in this table for every MPLS L3VPN configured on the LSR being examined. The Virtual Routing and Forwarding (VRF) that is Nadeau & van Der Linde Standards Track [Page 3] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 configured at a particular device represents an instance of some VPN, but not the entire VPN (unless it is the only VRF, of course). The collective set of VRF instances comprises the actual VPN. This information is typically only known in its entirety at the NMS. That is, specific devices generally only know of their local VRF information, but not that of other LSRs' VRFs. 5.2. mplsL3VpnIfConfTable This table represents the MPLS L3VPN-enabled interfaces that are associated with a specific VRF as represented in the aforementioned mplsL3VpnVrfTable. Each entry in this table corresponds to an entry in the Interfaces MIB. In addition, each entry extends its corresponding entry in the Interfaces MIB to contain specific MPLS L3VPN information. Due to this correspondence, certain objects such as traffic counters are not found in this MIB to avoid overlap, but instead are found in the Interfaces MIB [RFC2863]. 5.3. mplsL3VpnVrfPerfTable This table contains objects to measure the performance of MPLS L3VPNs and augments the mplsL3VpnVrfTable. High capacity counters are provided for objects that are likely to wrap around quickly on objects such as high-speed interface counters. 5.4. mplsL3VpnVrfRouteTable The table contains the objects necessary to configure and monitor routes used by a particular VRF. This includes a cross-connect pointer into the MPLS-LSR-STD-MIB's mplsXCTable, which may be used to refer that entry to its label stack used to label switch that entry. 5.5. MplsVpnVrfRTTable The table contains the objects necessary to configure and monitor route targets for a particular VRF. 6. Example of MPLS L3VPN Setup In this section, we provide a brief example of using the MIB objects described in the following section. While this example is not meant to illustrate every nuance of the MIB, it is intended as an aid to understanding some of the key concepts. It is our intent that it is read only after the reader has gone through the MIB itself. Nadeau & van Der Linde Standards Track [Page 4] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 This configuration is under the assumption that 1) MPLS has been pre-configured in the network, through enabling LDP or Resource Reservation Protocol - Traffic Engineering (RSVP-TE); 2) OSPF or Intermediate System to Intermediate System (IS-IS) has been pre- configured; and 3) BGP sessions have been established between PEs. Defining the VRF, the route target, and route distinguisher: In mplsL3VpnVrfTable: { mplsL3VpnVrfName = "RED", mplsL3VpnVrfDescription = "Intranet of Company ABC", mplsL3VpnVrfRD = "100:1", -- octet string mplsL3VpnVrfRowStatus = createAndGo(4) } In mplsL3VpnVrfRouteTable: { mplsL3VpnVrfRTRowStatus."Red"."100:1".import = createAndGo, mplsL3VpnVrfRTRowStatus."Red"."100:1".export = createAndGo } 7. MPLS-L3VPN-STD-MIB Module Definitions MPLS-L3VPN-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Counter32, Unsigned32, Gauge32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TEXTUAL-CONVENTION, TruthValue, RowStatus, TimeStamp, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] VPNIdOrZero FROM VPN-TC-STD-MIB -- [RFC4265] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] IANAipRouteProtocol FROM IANA-RTPROTO-MIB -- [RTPROTO] InetAddress, InetAddressType, InetAddressPrefixLength, InetAutonomousSystemNumber FROM INET-ADDRESS-MIB -- [RFC4001] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] Nadeau & van Der Linde Standards Track [Page 5] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 MplsIndexType FROM MPLS-LSR-STD-MIB -- [RFC3813] ; mplsL3VpnMIB MODULE-IDENTITY LAST-UPDATED "200601230000Z" -- 23 January 2006 ORGANIZATION "IETF Layer-3 Virtual Private Networks Working Group." CONTACT-INFO " Thomas D. Nadeau tnadeau@cisco.com Harmen van der Linde havander@cisco.com Comments and discussion to l3vpn@ietf.org" DESCRIPTION "This MIB contains managed object definitions for the Layer-3 Multiprotocol Label Switching Virtual Private Networks. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC4382; see the RFC itself for full legal notices." -- Revision history. REVISION "200601230000Z" -- 23 January 2006 DESCRIPTION "Initial version. Published as RFC 4382." ::= { mplsStdMIB 11 } -- Textual Conventions. MplsL3VpnName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An identifier that is assigned to each MPLS/BGP VPN and is used to uniquely identify it. This is assigned by the system operator or NMS and SHOULD be unique throughout the MPLS domain. If this is the case, then this identifier can then be used at any LSR within a specific MPLS domain to identify this MPLS/BGP VPN. It may also be possible to preserve the uniqueness of this identifier across MPLS domain boundaries, in which case this identifier can then be used to uniquely identify MPLS/BGP VPNs on a more global basis. This object MAY be set to the VPN ID as defined in RFC 2685." REFERENCE "RFC 2685 Fox B., et al, 'Virtual Private Nadeau & van Der Linde Standards Track [Page 6] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 Networks Identifier', September 1999." SYNTAX OCTET STRING (SIZE (0..31)) MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Syntax for a route distinguisher and route target as defined in [RFC4364]." REFERENCE "[RFC4364]" SYNTAX OCTET STRING(SIZE (0..256)) MplsL3VpnRtType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Used to define the type of a route target usage. Route targets can be specified to be imported, exported, or both. For a complete definition of a route target, see [RFC4364]." REFERENCE "[RFC4364]" SYNTAX INTEGER { import(1), export(2), both(3) } -- Top level components of this MIB. mplsL3VpnNotifications OBJECT IDENTIFIER ::= { mplsL3VpnMIB 0 } mplsL3VpnObjects OBJECT IDENTIFIER ::= { mplsL3VpnMIB 1 } mplsL3VpnScalars OBJECT IDENTIFIER ::= { mplsL3VpnObjects 1 } mplsL3VpnConf OBJECT IDENTIFIER ::= { mplsL3VpnObjects 2 } mplsL3VpnPerf OBJECT IDENTIFIER ::= { mplsL3VpnObjects 3 } mplsL3VpnRoute OBJECT IDENTIFIER ::= { mplsL3VpnObjects 4 } mplsL3VpnConformance OBJECT IDENTIFIER ::= { mplsL3VpnMIB 2 } -- -- Scalar Objects -- mplsL3VpnConfiguredVrfs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRFs that are configured on this node." ::= { mplsL3VpnScalars 1 } mplsL3VpnActiveVrfs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Nadeau & van Der Linde Standards Track [Page 7] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 DESCRIPTION "The number of VRFs that are active on this node. That is, those VRFs whose corresponding mplsL3VpnVrfOperStatus object value is equal to operational (1)." ::= { mplsL3VpnScalars 2 } mplsL3VpnConnectedInterfaces OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of interfaces connected to a VRF." ::= { mplsL3VpnScalars 3 } mplsL3VpnNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true, then it enables the generation of all notifications defined in this MIB. This object's value should be preserved across agent reboots." REFERENCE "See also [RFC3413] for explanation that notifications are under the ultimate control of the MIB modules in this document." DEFVAL { false } ::= { mplsL3VpnScalars 4 } mplsL3VpnVrfConfMaxPossRts OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes maximum number of routes that the device will allow all VRFs jointly to hold. If this value is set to 0, this indicates that the device is unable to determine the absolute maximum. In this case, the configured maximum MAY not actually be allowed by the device." ::= { mplsL3VpnScalars 5 } mplsL3VpnVrfConfRteMxThrshTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current Nadeau & van Der Linde Standards Track [Page 8] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 DESCRIPTION "Denotes the interval in seconds, at which the route max threshold notification may be reissued after the maximum value has been exceeded (or has been reached if mplsL3VpnVrfConfMaxRoutes and mplsL3VpnVrfConfHighRteThresh are equal) and the initial notification has been issued. This value is intended to prevent continuous generation of notifications by an agent in the event that routes are continually added to a VRF after it has reached its maximum value. If this value is set to 0, the agent should only issue a single notification at the time that the maximum threshold has been reached, and should not issue any more notifications until the value of routes has fallen below the configured threshold value. This is the recommended default behavior." DEFVAL { 0 } ::= { mplsL3VpnScalars 6 } mplsL3VpnIllLblRcvThrsh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of illegally received labels above which the mplsNumVrfSecIllglLblThrshExcd notification is issued. The persistence of this value mimics that of the device's configuration." ::= { mplsL3VpnScalars 7 } -- VPN Interface Configuration Table mplsL3VpnIfConfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsL3VpnIfConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface MPLS capability and associated information." ::= { mplsL3VpnConf 1 } mplsL3VpnIfConfEntry OBJECT-TYPE SYNTAX MplsL3VpnIfConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LSR for every interface capable of supporting MPLS L3VPN. Each entry in this table is meant to correspond to an entry in the Interfaces Table." Nadeau & van Der Linde Standards Track [Page 9] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 INDEX { mplsL3VpnVrfName, mplsL3VpnIfConfIndex } ::= { mplsL3VpnIfConfTable 1 } MplsL3VpnIfConfEntry ::= SEQUENCE { mplsL3VpnIfConfIndex InterfaceIndex, mplsL3VpnIfVpnClassification INTEGER, mplsL3VpnIfVpnRouteDistProtocol BITS, mplsL3VpnIfConfStorageType StorageType, mplsL3VpnIfConfRowStatus RowStatus } mplsL3VpnIfConfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a unique index for an entry in the mplsL3VpnIfConfTable. A non-zero index for an entry indicates the ifIndex for the corresponding interface entry in the MPLS-VPN-layer in the ifTable. Note that this table does not necessarily correspond one-to-one with all entries in the Interface MIB having an ifType of MPLS-layer; rather, only those that are enabled for MPLS L3VPN functionality." REFERENCE "RFC2863" ::= { mplsL3VpnIfConfEntry 1 } mplsL3VpnIfVpnClassification OBJECT-TYPE SYNTAX INTEGER { carrierOfCarrier (1), enterprise (2), interProvider (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether this link participates in a carrier's carrier, enterprise, or inter-provider scenario." DEFVAL { enterprise } ::= { mplsL3VpnIfConfEntry 2 } mplsL3VpnIfVpnRouteDistProtocol OBJECT-TYPE SYNTAX BITS { none (0), bgp (1), ospf (2), rip(3), isis(4), Nadeau & van Der Linde Standards Track [Page 10] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 static(5), other (6) } MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes the route distribution protocol across the PE-CE link. Note that more than one routing protocol may be enabled at the same time; thus, this object is specified as a bitmask. For example, static(5) and ospf(2) are a typical configuration." ::= { mplsL3VpnIfConfEntry 3 } mplsL3VpnIfConfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this VPN If entry. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." REFERENCE "See RFC2579." DEFVAL { volatile } ::= { mplsL3VpnIfConfEntry 4 } mplsL3VpnIfConfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. Rows in this table signify that the specified interface is associated with this VRF. If the row creation operation succeeds, the interface will have been associated with the specified VRF, otherwise the agent MUST not allow the association. If the agent only allows read-only operations on this table, it MUST create entries in this table as they are created on the device. When a row in this table is in active(1) state, no objects in that row can be modified except mplsL3VpnIfConfStorageType and mplsL3VpnIfConfRowStatus." ::= { mplsL3VpnIfConfEntry 5 } -- VRF Configuration Table Nadeau & van Der Linde Standards Track [Page 11] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mplsL3VpnVrfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsL3VpnVrfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface MPLS L3VPN VRF Table capability and associated information. Entries in this table define VRF routing instances associated with MPLS/VPN interfaces. Note that multiple interfaces can belong to the same VRF instance. The collection of all VRF instances comprises an actual VPN." ::= { mplsL3VpnConf 2 } mplsL3VpnVrfEntry OBJECT-TYPE SYNTAX MplsL3VpnVrfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LSR for every VRF capable of supporting MPLS L3VPN. The indexing provides an ordering of VRFs per-VPN interface." INDEX { mplsL3VpnVrfName } ::= { mplsL3VpnVrfTable 1 } MplsL3VpnVrfEntry ::= SEQUENCE { mplsL3VpnVrfName MplsL3VpnName, mplsL3VpnVrfVpnId VPNIdOrZero, mplsL3VpnVrfDescription SnmpAdminString, mplsL3VpnVrfRD MplsL3VpnRouteDistinguisher, mplsL3VpnVrfCreationTime TimeStamp, mplsL3VpnVrfOperStatus INTEGER, mplsL3VpnVrfActiveInterfaces Gauge32, mplsL3VpnVrfAssociatedInterfaces Unsigned32, mplsL3VpnVrfConfMidRteThresh Unsigned32, mplsL3VpnVrfConfHighRteThresh Unsigned32, mplsL3VpnVrfConfMaxRoutes Unsigned32, mplsL3VpnVrfConfLastChanged TimeStamp, mplsL3VpnVrfConfRowStatus RowStatus, mplsL3VpnVrfConfAdminStatus INTEGER, mplsL3VpnVrfConfStorageType StorageType } mplsL3VpnVrfName OBJECT-TYPE SYNTAX MplsL3VpnName MAX-ACCESS not-accessible STATUS current DESCRIPTION Nadeau & van Der Linde Standards Track [Page 12] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 "The human-readable name of this VPN. This MAY be equivalent to the [RFC2685] VPN-ID, but may also vary. If it is set to the VPN ID, it MUST be equivalent to the value of mplsL3VpnVrfVpnId. It is strongly recommended that all sites supporting VRFs that are part of the same VPN use the same naming convention for VRFs as well as the same VPN ID." REFERENCE "[RFC2685]" ::= { mplsL3VpnVrfEntry 1 } mplsL3VpnVrfVpnId OBJECT-TYPE SYNTAX VPNIdOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The VPN ID as specified in [RFC2685]. If a VPN ID has not been specified for this VRF, then this variable SHOULD be set to a zero-length OCTET STRING." ::= { mplsL3VpnVrfEntry 2 } mplsL3VpnVrfDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The human-readable description of this VRF." DEFVAL { "" } ::= { mplsL3VpnVrfEntry 3 } mplsL3VpnVrfRD OBJECT-TYPE SYNTAX MplsL3VpnRouteDistinguisher MAX-ACCESS read-create STATUS current DESCRIPTION "The route distinguisher for this VRF." DEFVAL { "" } ::= { mplsL3VpnVrfEntry 4 } mplsL3VpnVrfCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which this VRF entry was created." ::= { mplsL3VpnVrfEntry 5 } Nadeau & van Der Linde Standards Track [Page 13] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mplsL3VpnVrfOperStatus OBJECT-TYPE SYNTAX INTEGER { up (1), down (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Denotes whether or not a VRF is operational. A VRF is up(1) when there is at least one interface associated with the VRF whose ifOperStatus is up(1). A VRF is down(2) when: a. There does not exist at least one interface whose ifOperStatus is up(1). b. There are no interfaces associated with the VRF." ::= { mplsL3VpnVrfEntry 6 } mplsL3VpnVrfActiveInterfaces OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of interfaces connected to this VRF with ifOperStatus = up(1). This value should increase when an interface is associated with the corresponding VRF and its corresponding ifOperStatus is equal to up(1). If an interface is associated whose ifOperStatus is not up(1), then the value is not incremented until such time as it transitions to this state. This value should be decremented when an interface is disassociated with a VRF or the corresponding ifOperStatus transitions out of the up(1) state to any other state. " ::= { mplsL3VpnVrfEntry 7 } mplsL3VpnVrfAssociatedInterfaces OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of interfaces connected to this VRF (independent of ifOperStatus type)." ::= { mplsL3VpnVrfEntry 8 } mplsL3VpnVrfConfMidRteThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create Nadeau & van Der Linde Standards Track [Page 14] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 STATUS current DESCRIPTION "Denotes mid-level water marker for the number of routes that this VRF may hold." DEFVAL { 0 } ::= { mplsL3VpnVrfEntry 9 } mplsL3VpnVrfConfHighRteThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes high-level water marker for the number of routes that this VRF may hold." DEFVAL { 0 } ::= { mplsL3VpnVrfEntry 10 } mplsL3VpnVrfConfMaxRoutes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes maximum number of routes that this VRF is configured to hold. This value MUST be less than or equal to mplsL3VpnVrfConfMaxPossRts unless it is set to 0." DEFVAL { 0 } ::= { mplsL3VpnVrfEntry 11 } mplsL3VpnVrfConfLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last change of this table entry, which includes changes of VRF parameters defined in this table or addition or deletion of interfaces associated with this VRF." ::= { mplsL3VpnVrfEntry 12 } mplsL3VpnVrfConfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. Nadeau & van Der Linde Standards Track [Page 15] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 When a row in this table is in active(1) state, no objects in that row can be modified except mplsL3VpnVrfConfAdminStatus, mplsL3VpnVrfConfRowStatus, and mplsL3VpnVrfConfStorageType." ::= { mplsL3VpnVrfEntry 13 } mplsL3VpnVrfConfAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), -- can't pass packets testing(3) -- in some test mode } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the desired operational status of this VRF." ::= { mplsL3VpnVrfEntry 14 } mplsL3VpnVrfConfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this VPN VRF entry. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." REFERENCE "See RFC2579." DEFVAL { volatile } ::= { mplsL3VpnVrfEntry 15 } -- MplsL3VpnVrfRTTable mplsL3VpnVrfRTTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsL3VpnVrfRTEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-VRF route target association. Each entry identifies a connectivity policy supported as part of a VPN." ::= { mplsL3VpnConf 3 } mplsL3VpnVrfRTEntry OBJECT-TYPE SYNTAX MplsL3VpnVrfRTEntry MAX-ACCESS not-accessible Nadeau & van Der Linde Standards Track [Page 16] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 STATUS current DESCRIPTION "An entry in this table is created by an LSR for each route target configured for a VRF supporting a MPLS L3VPN instance. The indexing provides an ordering per-VRF instance. See [RFC4364] for a complete definition of a route target." INDEX { mplsL3VpnVrfName, mplsL3VpnVrfRTIndex, mplsL3VpnVrfRTType } ::= { mplsL3VpnVrfRTTable 1 } MplsL3VpnVrfRTEntry ::= SEQUENCE { mplsL3VpnVrfRTIndex Unsigned32, mplsL3VpnVrfRTType MplsL3VpnRtType, mplsL3VpnVrfRT MplsL3VpnRouteDistinguisher, mplsL3VpnVrfRTDescr SnmpAdminString, mplsL3VpnVrfRTRowStatus RowStatus, mplsL3VpnVrfRTStorageType StorageType } mplsL3VpnVrfRTIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Auxiliary index for route targets configured for a particular VRF." ::= { mplsL3VpnVrfRTEntry 2 } mplsL3VpnVrfRTType OBJECT-TYPE SYNTAX MplsL3VpnRtType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The route target distribution type." ::= { mplsL3VpnVrfRTEntry 3 } mplsL3VpnVrfRT OBJECT-TYPE SYNTAX MplsL3VpnRouteDistinguisher MAX-ACCESS read-create STATUS current DESCRIPTION "The route target distribution policy." DEFVAL { "" } ::= { mplsL3VpnVrfRTEntry 4 } mplsL3VpnVrfRTDescr OBJECT-TYPE SYNTAX SnmpAdminString Nadeau & van Der Linde Standards Track [Page 17] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "Description of the route target." DEFVAL { "" } ::= { mplsL3VpnVrfRTEntry 5 } mplsL3VpnVrfRTRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. When a row in this table is in active(1) state, no objects in that row can be modified except mplsL3VpnVrfRTRowStatus." ::= { mplsL3VpnVrfRTEntry 6 } mplsL3VpnVrfRTStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this VPN route target (RT) entry. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." REFERENCE "See RFC2579." DEFVAL { volatile } ::= { mplsL3VpnVrfRTEntry 7 } -- VRF Security Table mplsL3VpnVrfSecTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsL3VpnVrfSecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per MPLS L3VPN VRF Table security-related counters." ::= { mplsL3VpnConf 6 } mplsL3VpnVrfSecEntry OBJECT-TYPE SYNTAX MplsL3VpnVrfSecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Nadeau & van Der Linde Standards Track [Page 18] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 "An entry in this table is created by an LSR for every VRF capable of supporting MPLS L3VPN. Each entry in this table is used to indicate security-related information for each VRF entry." AUGMENTS { mplsL3VpnVrfEntry } ::= { mplsL3VpnVrfSecTable 1 } MplsL3VpnVrfSecEntry ::= SEQUENCE { mplsL3VpnVrfSecIllegalLblVltns Counter32, mplsL3VpnVrfSecDiscontinuityTime TimeStamp } mplsL3VpnVrfSecIllegalLblVltns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of illegally received labels on this VPN/VRF. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsL3VpnVrfSecDiscontinuityTime." ::= { mplsL3VpnVrfSecEntry 1 } mplsL3VpnVrfSecDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this entry's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsL3VpnVrfSecEntry 2 } -- VRF Performance Table mplsL3VpnVrfPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsL3VpnVrfPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per MPLS L3VPN VRF Table performance Nadeau & van Der Linde Standards Track [Page 19] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 information." ::= { mplsL3VpnPerf 1 } mplsL3VpnVrfPerfEntry OBJECT-TYPE SYNTAX MplsL3VpnVrfPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LSR for every VRF capable of supporting MPLS L3VPN." AUGMENTS { mplsL3VpnVrfEntry } ::= { mplsL3VpnVrfPerfTable 1 } MplsL3VpnVrfPerfEntry ::= SEQUENCE { mplsL3VpnVrfPerfRoutesAdded Counter32, mplsL3VpnVrfPerfRoutesDeleted Counter32, mplsL3VpnVrfPerfCurrNumRoutes Gauge32, mplsL3VpnVrfPerfRoutesDropped Counter32, mplsL3VpnVrfPerfDiscTime TimeStamp } mplsL3VpnVrfPerfRoutesAdded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of routes added to this VPN/VRF since the last discontinuity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsL3VpnVrfPerfDiscTime." ::= { mplsL3VpnVrfPerfEntry 1 } mplsL3VpnVrfPerfRoutesDeleted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of routes removed from this VPN/VRF. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsL3VpnVrfPerfDiscTime." ::= { mplsL3VpnVrfPerfEntry 2 } mplsL3VpnVrfPerfCurrNumRoutes OBJECT-TYPE Nadeau & van Der Linde Standards Track [Page 20] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of routes currently used by this VRF." ::= { mplsL3VpnVrfPerfEntry 3 } mplsL3VpnVrfPerfRoutesDropped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter should be incremented when the number of routes contained by the specified VRF exceeds or attempts to exceed the maximum allowed value as indicated by mplsL3VpnVrfMaxRouteThreshold. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mplsL3VpnVrfPerfDiscTime." ::= { mplsL3VpnVrfPerfEntry 4 } mplsL3VpnVrfPerfDiscTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this entry's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { mplsL3VpnVrfPerfEntry 5 } -- VRF Routing Table mplsL3VpnVrfRteTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsL3VpnVrfRteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface MPLS L3VPN VRF Table routing information. Entries in this table define VRF routing entries associated with the specified MPLS/VPN interfaces. Note Nadeau & van Der Linde Standards Track [Page 21] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 that this table contains both BGP and Interior Gateway Protocol IGP routes, as both may appear in the same VRF." REFERENCE "[RFC2096]" ::= { mplsL3VpnRoute 1 } mplsL3VpnVrfRteEntry OBJECT-TYPE SYNTAX MplsL3VpnVrfRteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LSR for every route present configured (either dynamically or statically) within the context of a specific VRF capable of supporting MPLS/BGP VPN. The indexing provides an ordering of VRFs per-VPN interface. Implementers need to be aware that there are quite a few index objects that together can exceed the size allowed for an Object Identifier (OID). So implementers must make sure that OIDs of column instances in this table will have no more than 128 sub-identifiers, otherwise they cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { mplsL3VpnVrfName, mplsL3VpnVrfRteInetCidrDestType, mplsL3VpnVrfRteInetCidrDest, mplsL3VpnVrfRteInetCidrPfxLen, mplsL3VpnVrfRteInetCidrPolicy, mplsL3VpnVrfRteInetCidrNHopType, mplsL3VpnVrfRteInetCidrNextHop } ::= { mplsL3VpnVrfRteTable 1 } MplsL3VpnVrfRteEntry ::= SEQUENCE { mplsL3VpnVrfRteInetCidrDestType InetAddressType, mplsL3VpnVrfRteInetCidrDest InetAddress, mplsL3VpnVrfRteInetCidrPfxLen InetAddressPrefixLength, mplsL3VpnVrfRteInetCidrPolicy OBJECT IDENTIFIER, mplsL3VpnVrfRteInetCidrNHopType InetAddressType, mplsL3VpnVrfRteInetCidrNextHop InetAddress, mplsL3VpnVrfRteInetCidrIfIndex InterfaceIndexOrZero, mplsL3VpnVrfRteInetCidrType INTEGER, mplsL3VpnVrfRteInetCidrProto IANAipRouteProtocol, mplsL3VpnVrfRteInetCidrAge Gauge32, mplsL3VpnVrfRteInetCidrNextHopAS InetAutonomousSystemNumber, mplsL3VpnVrfRteInetCidrMetric1 Integer32, mplsL3VpnVrfRteInetCidrMetric2 Integer32, Nadeau & van Der Linde Standards Track [Page 22] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mplsL3VpnVrfRteInetCidrMetric3 Integer32, mplsL3VpnVrfRteInetCidrMetric4 Integer32, mplsL3VpnVrfRteInetCidrMetric5 Integer32, mplsL3VpnVrfRteXCPointer MplsIndexType, mplsL3VpnVrfRteInetCidrStatus RowStatus } mplsL3VpnVrfRteInetCidrDestType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the mplsL3VpnVrfRteInetCidrDest address, as defined in the InetAddress MIB. Only those address types that may appear in an actual routing table are allowed as values of this object." REFERENCE "RFC4001" ::= { mplsL3VpnVrfRteEntry 1 } mplsL3VpnVrfRteInetCidrDest OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination IP address of this route. The type of this address is determined by the value of the mplsL3VpnVrfRteInetCidrDestType object. The values for the index objects mplsL3VpnVrfRteInetCidrDest and mplsL3VpnVrfRteInetCidrPfxLen must be consistent. When the value of mplsL3VpnVrfRteInetCidrDest is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object mplsL3VpnVrfRteInetCidrPfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { mplsL3VpnVrfRteEntry 2 } mplsL3VpnVrfRteInetCidrPfxLen OBJECT-TYPE SYNTAX InetAddressPrefixLength (0..128) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the number of leading one bits that form the Nadeau & van Der Linde Standards Track [Page 23] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mask to be logical-ANDed with the destination address before being compared to the value in the mplsL3VpnVrfRteInetCidrDest field. The values for the index objects mplsL3VpnVrfRteInetCidrDest and mplsL3VpnVrfRteInetCidrPfxLen must be consistent. When the value of mplsL3VpnVrfRteInetCidrDest is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object mplsL3VpnVrfRteInetCidrPfxLen MUST be equal to x. If not, then the index pair is not consistent and an inconsistentName error must be returned on SET or CREATE requests." ::= { mplsL3VpnVrfRteEntry 3 } mplsL3VpnVrfRteInetCidrPolicy OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an opaque object without any defined semantics. Its purpose is to serve as an additional index that may delineate between multiple entries to the same destination. The value { 0 0 } shall be used as the default value for this object." ::= { mplsL3VpnVrfRteEntry 4 } mplsL3VpnVrfRteInetCidrNHopType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the mplsL3VpnVrfRteInetCidrNextHop address, as defined in the InetAddress MIB. Value should be set to unknown(0) for non-remote routes. Only those address types that may appear in an actual routing table are allowed as values of this object." REFERENCE "RFC4001" ::= { mplsL3VpnVrfRteEntry 5 } mplsL3VpnVrfRteInetCidrNextHop OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current Nadeau & van Der Linde Standards Track [Page 24] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 DESCRIPTION "On remote routes, the address of the next system en route. For non-remote routes, a zero-length string. The type of this address is determined by the value of the mplsL3VpnVrfRteInetCidrNHopType object." ::= { mplsL3VpnVrfRteEntry 6 } mplsL3VpnVrfRteInetCidrIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value that identifies the local interface through which the next hop of this route should be reached. A value of 0 is valid and represents the scenario where no interface is specified." DEFVAL { 0 } ::= { mplsL3VpnVrfRteEntry 7 } mplsL3VpnVrfRteInetCidrType OBJECT-TYPE SYNTAX INTEGER { other (1), -- not specified by this MIB reject (2), -- route which discards traffic and -- returns ICMP notification local (3), -- local interface remote (4), -- remote destination blackhole(5) -- route which discards traffic -- silently } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of route. Note that local(3) refers to a route for which the next hop is the final destination; remote(4) refers to a route for which the next hop is not the final destination. Routes that do not result in traffic forwarding or rejection should not be displayed even if the implementation keeps them stored internally. reject(2) refers to a route that, if matched, discards the message as unreachable and returns a notification (e.g., ICMP error) to the message sender. This is used in some protocols as a means of correctly aggregating routes. blackhole(5) refers to a route that, if matched, Nadeau & van Der Linde Standards Track [Page 25] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 discards the message silently." DEFVAL { other } ::= { mplsL3VpnVrfRteEntry 8 } mplsL3VpnVrfRteInetCidrProto OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { mplsL3VpnVrfRteEntry 9 } mplsL3VpnVrfRteInetCidrAge OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of 'too old' can be implied except through knowledge of the routing protocol by which the route was learned." ::= { mplsL3VpnVrfRteEntry 10 } mplsL3VpnVrfRteInetCidrNextHopAS OBJECT-TYPE SYNTAX InetAutonomousSystemNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The Autonomous System Number of the next hop. The semantics of this object are determined by the routing protocol specified in the route's mplsL3VpnVrfRteInetCidrProto value. When this object is unknown or not relevant, its value should be set to zero." DEFVAL { 0 } ::= { mplsL3VpnVrfRteEntry 11 } mplsL3VpnVrfRteInetCidrMetric1 OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The primary routing metric for this route. The semantics of this metric are determined by the Nadeau & van Der Linde Standards Track [Page 26] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 routing protocol specified in the route's mplsL3VpnVrfRteInetCidrProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { mplsL3VpnVrfRteEntry 12 } mplsL3VpnVrfRteInetCidrMetric2 OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing protocol specified in the route's mplsL3VpnVrfRteInetCidrProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { mplsL3VpnVrfRteEntry 13 } mplsL3VpnVrfRteInetCidrMetric3 OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing protocol specified in the route's mplsL3VpnVrfRteInetCidrProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { mplsL3VpnVrfRteEntry 14 } mplsL3VpnVrfRteInetCidrMetric4 OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing protocol specified in the route's mplsL3VpnVrfRteInetCidrProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { mplsL3VpnVrfRteEntry 15 } Nadeau & van Der Linde Standards Track [Page 27] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mplsL3VpnVrfRteInetCidrMetric5 OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing protocol specified in the route's mplsL3VpnVrfRteInetCidrProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { mplsL3VpnVrfRteEntry 16 } mplsL3VpnVrfRteXCPointer OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS read-create STATUS current DESCRIPTION "Index into mplsXCTable that identifies which cross- connect entry is associated with this VRF route entry by containing the mplsXCIndex of that cross-connect entry. The string containing the single-octet 0x00 indicates that a label stack is not associated with this route entry. This can be the case because the label bindings have not yet been established, or because some change in the agent has removed them. When the label stack associated with this VRF route is created, it MUST establish the associated cross-connect entry in the mplsXCTable and then set that index to the value of this object. Changes to the cross-connect object in the mplsXCTable MUST automatically be reflected in the value of this object. If this object represents a static routing entry, then the manager must ensure that this entry is maintained consistently in the corresponding mplsXCTable as well." REFERENCE "RFC 3813 - Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information base (MIB), C. Srinivasan, A. Vishwanathan, and T. Nadeau, June 2004" ::= { mplsL3VpnVrfRteEntry 17 } mplsL3VpnVrfRteInetCidrStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status variable, used according to row installation and removal conventions. Nadeau & van Der Linde Standards Track [Page 28] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 A row entry cannot be modified when the status is marked as active(1)." ::= { mplsL3VpnVrfRteEntry 18 } -- MPLS L3VPN Notifications mplsL3VpnVrfUp NOTIFICATION-TYPE OBJECTS { mplsL3VpnIfConfRowStatus, mplsL3VpnVrfOperStatus } STATUS current DESCRIPTION "This notification is generated when: a. No interface is associated with this VRF, and the first (and only first) interface associated with it has its ifOperStatus change to up(1). b. One interface is associated with this VRF, and the ifOperStatus of this interface changes to up(1). c. Multiple interfaces are associated with this VRF, and the ifOperStatus of all interfaces is down(2), and the first of those interfaces has its ifOperStatus change to up(1)." ::= { mplsL3VpnNotifications 1 } mplsL3VpnVrfDown NOTIFICATION-TYPE OBJECTS { mplsL3VpnIfConfRowStatus, mplsL3VpnVrfOperStatus } STATUS current DESCRIPTION "This notification is generated when: a. One interface is associated with this VRF, and the ifOperStatus of this interface changes from up(1) to down(2). b. Multiple interfaces are associated with this VRF, and the ifOperStatus of all except one of these interfaces is equal to up(1), and the ifOperStatus of that interface changes from up(1) to down(2). c. The last interface with ifOperStatus equal to up(1) is disassociated from a VRF." ::= { mplsL3VpnNotifications 2 } mplsL3VpnVrfRouteMidThreshExceeded NOTIFICATION-TYPE OBJECTS { mplsL3VpnVrfPerfCurrNumRoutes, mplsL3VpnVrfConfMidRteThresh Nadeau & van Der Linde Standards Track [Page 29] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 } STATUS current DESCRIPTION "This notification is generated when the number of routes contained by the specified VRF exceeds the value indicated by mplsL3VpnVrfMidRouteThreshold. A single notification MUST be generated when this threshold is exceeded, and no other notifications of this type should be issued until the value of mplsL3VpnVrfPerfCurrNumRoutes has fallen below that of mplsL3VpnVrfConfMidRteThresh." ::= { mplsL3VpnNotifications 3 } mplsL3VpnVrfNumVrfRouteMaxThreshExceeded NOTIFICATION-TYPE OBJECTS { mplsL3VpnVrfPerfCurrNumRoutes, mplsL3VpnVrfConfHighRteThresh } STATUS current DESCRIPTION "This notification is generated when the number of routes contained by the specified VRF exceeds or attempts to exceed the maximum allowed value as indicated by mplsL3VpnVrfMaxRouteThreshold. In cases where mplsL3VpnVrfConfHighRteThresh is set to the same value as mplsL3VpnVrfConfMaxRoutes, mplsL3VpnVrfConfHighRteThresh need not be exceeded; rather, just reached for this notification to be issued. Note that mplsL3VpnVrfConfRteMxThrshTime denotes the interval at which the this notification will be reissued after the maximum value has been exceeded (or reached if mplsL3VpnVrfConfMaxRoutes and mplsL3VpnVrfConfHighRteThresh are equal) and the initial notification has been issued. This value is intended to prevent continuous generation of notifications by an agent in the event that routes are continually added to a VRF after it has reached its maximum value. The default value is 0 minutes. If this value is set to 0, the agent should only issue a single notification at the time that the maximum threshold has been reached, and should not issue any more notifications until the value of routes has fallen below the configured threshold value." ::= { mplsL3VpnNotifications 4 } mplsL3VpnNumVrfSecIllglLblThrshExcd NOTIFICATION-TYPE OBJECTS { mplsL3VpnVrfSecIllegalLblVltns } STATUS current DESCRIPTION "This notification is generated when the number of illegal label violations on a VRF as indicated by Nadeau & van Der Linde Standards Track [Page 30] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mplsL3VpnVrfSecIllegalLblVltns has exceeded mplsL3VpnIllLblRcvThrsh. The threshold is not included in the varbind here because the value of mplsL3VpnVrfSecIllegalLblVltns should be one greater than the threshold at the time this notification is issued." ::= { mplsL3VpnNotifications 5 } mplsL3VpnNumVrfRouteMaxThreshCleared NOTIFICATION-TYPE OBJECTS { mplsL3VpnVrfPerfCurrNumRoutes, mplsL3VpnVrfConfHighRteThresh } STATUS current DESCRIPTION "This notification is generated only after the number of routes contained by the specified VRF exceeds or attempts to exceed the maximum allowed value as indicated by mplsVrfMaxRouteThreshold, and then falls below this value. The emission of this notification informs the operator that the error condition has been cleared without the operator having to query the device. Note that mplsL3VpnVrfConfRteMxThrshTime denotes the interval at which the mplsNumVrfRouteMaxThreshExceeded notification will be reissued after the maximum value has been exceeded (or reached if mplsL3VpnVrfConfMaxRoutes and mplsL3VpnVrfConfHighRteThresh are equal) and the initial notification has been issued. Therefore, the generation of this notification should also be emitted with this same frequency (assuming that the error condition is cleared). Specifically, if the error condition is reached and cleared several times during the period of time specified in mplsL3VpnVrfConfRteMxThrshTime, only a single notification will be issued to indicate the first instance of the error condition as well as the first time the error condition is cleared. This behavior is intended to prevent continuous generation of notifications by an agent in the event that routes are continually added and removed to/from a VRF after it has reached its maximum value. The default value is 0. If this value is set to 0, the agent should issue a notification whenever the maximum threshold has been cleared." ::= { mplsL3VpnNotifications 6 } -- Conformance Statement mplsL3VpnGroups OBJECT IDENTIFIER ::= { mplsL3VpnConformance 1 } mplsL3VpnCompliances Nadeau & van Der Linde Standards Track [Page 31] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 OBJECT IDENTIFIER ::= { mplsL3VpnConformance 2 } -- Module Compliance mplsL3VpnModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for the MPLS-L3VPN-STD-MIB" MODULE -- this module MANDATORY-GROUPS { mplsL3VpnScalarGroup, mplsL3VpnVrfGroup, mplsL3VpnIfGroup, mplsL3VpnPerfGroup, mplsL3VpnVrfRteGroup, mplsL3VpnVrfRTGroup, mplsL3VpnSecGroup, mplsL3VpnNotificationGroup } GROUP mplsL3VpnPerfRouteGroup DESCRIPTION "This group is only mandatory for LSRs that support tracking the number of routes attempted to be added to VRFs." OBJECT mplsL3VpnIfConfRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." OBJECT mplsL3VpnVrfConfRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." OBJECT mplsL3VpnVrfRTRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." Nadeau & van Der Linde Standards Track [Page 32] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 ::= { mplsL3VpnCompliances 1 } -- -- ReadOnly Compliance -- mplsL3VpnModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for MPLS-L3VPN-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB module." MODULE -- this module MANDATORY-GROUPS { mplsL3VpnScalarGroup, mplsL3VpnVrfGroup, mplsL3VpnIfGroup, mplsL3VpnPerfGroup, mplsL3VpnVrfRteGroup, mplsL3VpnVrfRTGroup, mplsL3VpnSecGroup, mplsL3VpnNotificationGroup } GROUP mplsL3VpnPerfRouteGroup DESCRIPTION "This group is only mandatory for LSRs that support tracking the number of routes attempted to be added to VRFs." OBJECT mplsL3VpnIfConfRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfConfRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRTRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnIfVpnClassification MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau & van Der Linde Standards Track [Page 33] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 OBJECT mplsL3VpnIfVpnRouteDistProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnIfConfStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfVpnId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRD MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfConfMidRteThresh MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfConfHighRteThresh MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfConfMaxRoutes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfConfStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRT MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRTDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRTStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau & van Der Linde Standards Track [Page 34] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 OBJECT mplsL3VpnVrfRteInetCidrIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrNextHopAS MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrMetric1 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrMetric2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrMetric3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrMetric4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrMetric5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteXCPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsL3VpnVrfRteInetCidrStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mplsL3VpnCompliances 2 } -- Units of conformance. mplsL3VpnScalarGroup OBJECT-GROUP OBJECTS { mplsL3VpnConfiguredVrfs, mplsL3VpnActiveVrfs, mplsL3VpnConnectedInterfaces, Nadeau & van Der Linde Standards Track [Page 35] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mplsL3VpnNotificationEnable, mplsL3VpnVrfConfMaxPossRts, mplsL3VpnVrfConfRteMxThrshTime, mplsL3VpnIllLblRcvThrsh } STATUS current DESCRIPTION "Collection of scalar objects required for MPLS VPN management." ::= { mplsL3VpnGroups 1 } mplsL3VpnVrfGroup OBJECT-GROUP OBJECTS { mplsL3VpnVrfVpnId, mplsL3VpnVrfDescription, mplsL3VpnVrfRD, mplsL3VpnVrfCreationTime, mplsL3VpnVrfOperStatus, mplsL3VpnVrfActiveInterfaces, mplsL3VpnVrfAssociatedInterfaces, mplsL3VpnVrfConfMidRteThresh, mplsL3VpnVrfConfHighRteThresh, mplsL3VpnVrfConfMaxRoutes, mplsL3VpnVrfConfLastChanged, mplsL3VpnVrfConfRowStatus, mplsL3VpnVrfConfAdminStatus, mplsL3VpnVrfConfStorageType } STATUS current DESCRIPTION "Collection of objects needed for MPLS VPN VRF management." ::= { mplsL3VpnGroups 2 } mplsL3VpnIfGroup OBJECT-GROUP OBJECTS { mplsL3VpnIfVpnClassification, mplsL3VpnIfVpnRouteDistProtocol, mplsL3VpnIfConfStorageType, mplsL3VpnIfConfRowStatus } STATUS current DESCRIPTION "Collection of objects needed for MPLS VPN interface management." ::= { mplsL3VpnGroups 3 } mplsL3VpnPerfGroup OBJECT-GROUP OBJECTS { mplsL3VpnVrfPerfRoutesAdded, mplsL3VpnVrfPerfRoutesDeleted, Nadeau & van Der Linde Standards Track [Page 36] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 mplsL3VpnVrfPerfCurrNumRoutes } STATUS current DESCRIPTION "Collection of objects needed for MPLS VPN performance information." ::= { mplsL3VpnGroups 4 } mplsL3VpnPerfRouteGroup OBJECT-GROUP OBJECTS { mplsL3VpnVrfPerfRoutesDropped, mplsL3VpnVrfPerfDiscTime } STATUS current DESCRIPTION "Collection of objects needed to track MPLS VPN routing table dropped routes." ::= { mplsL3VpnGroups 5 } mplsL3VpnSecGroup OBJECT-GROUP OBJECTS { mplsL3VpnVrfSecIllegalLblVltns, mplsL3VpnVrfSecDiscontinuityTime } STATUS current DESCRIPTION "Collection of objects needed for MPLS VPN security-related information." ::= { mplsL3VpnGroups 7 } mplsL3VpnVrfRteGroup OBJECT-GROUP OBJECTS { mplsL3VpnVrfRteInetCidrIfIndex, mplsL3VpnVrfRteInetCidrType, mplsL3VpnVrfRteInetCidrProto, mplsL3VpnVrfRteInetCidrAge, mplsL3VpnVrfRteInetCidrNextHopAS, mplsL3VpnVrfRteInetCidrMetric1, mplsL3VpnVrfRteInetCidrMetric2, mplsL3VpnVrfRteInetCidrMetric3, mplsL3VpnVrfRteInetCidrMetric4, mplsL3VpnVrfRteInetCidrMetric5, mplsL3VpnVrfRteXCPointer, mplsL3VpnVrfRteInetCidrStatus } STATUS current DESCRIPTION "Objects required for VRF route table management." ::= { mplsL3VpnGroups 8 } mplsL3VpnVrfRTGroup OBJECT-GROUP Nadeau & van Der Linde Standards Track [Page 37] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 OBJECTS { mplsL3VpnVrfRTDescr, mplsL3VpnVrfRT, mplsL3VpnVrfRTRowStatus, mplsL3VpnVrfRTStorageType } STATUS current DESCRIPTION "Objects required for VRF route target management." ::= { mplsL3VpnGroups 9 } mplsL3VpnNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mplsL3VpnVrfUp, mplsL3VpnVrfDown, mplsL3VpnVrfRouteMidThreshExceeded, mplsL3VpnVrfNumVrfRouteMaxThreshExceeded, mplsL3VpnNumVrfSecIllglLblThrshExcd, mplsL3VpnNumVrfRouteMaxThreshCleared } STATUS current DESCRIPTION "Objects required for MPLS VPN notifications." ::= { mplsL3VpnGroups 10 } END -- End of MPLS-VPN-MIB 8. Security Considerations It is clear that these MIB modules are potentially useful for monitoring of MPLS LSRs supporting L3 MPLS VPN. This MIB module can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsL3VpnVrfRouteTable, mplsL3VpnIfConfTable, and mplsL3VpnVrfTable tables collectively contain objects that may be used to provision MPLS VRF interfaces and configuration. Unauthorized access to objects in these tables could result in disruption of traffic on the network. This is especially true if these VRFs have been previously provisioned and are in use. Nadeau & van Der Linde Standards Track [Page 38] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent that implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the mplsL3VpnVrfTable, mplsL3VpnIfConfTable tables collectively show the VRF interfaces and associated VRF configurations as well as their linkages to other MPLS-related configuration and/or performance statistics. Administrators not wishing to reveal this information should consider these objects sensitive/vulnerable and take precautions so they are not revealed. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Nadeau & van Der Linde Standards Track [Page 39] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 9. IANA Considerations As described in MPLS-TC-STD-MIB [RFC3811], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There is one MPLS-related MIB module contained in this document. The following subsection requests IANA for a new assignment under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. 9.1. IANA Considerations for MPLS-L3VPN-STD-MIB The IANA has assigned { mplsStdMIB 11 } to the MPLS-L3VPN-STD-MIB module specified in this document. 10. Dedication Steve Brannon passed away suddenly on January 30, 2001. We would like to dedicate our efforts in this area and this document to his memory. 11. Acknowledgements This document has benefited from discussions and input from Bill Fenner, Gerald Ash, Sumit Mukhopadhyay, Mike Piecuch, and Joan Weiss. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. Nadeau & van Der Linde Standards Track [Page 40] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "MPLS Multiprotocol Label Switching (MPLS) Label Switch Router Management Information Base ", RFC 3813, June 2004 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. [RFC4265] Schliesser, B. and T. Nadeau, "Definition of Textual Conventions for Virtual Private Network (VPN) Management", RFC 4265, November 2005. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RTPROTO] IANA, "IP Route Protocol MIB", http://www.iana.org/assignments/ianaiprouteprotocol-mib, September 2000. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Nadeau & van Der Linde Standards Track [Page 41] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 12.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 13. Contributors' Addresses Luyuan Fang AT&T 200 Laurel Ave Middletown, NJ 07748 Phone: +1-732-420-1921 EMail: luyuanfang@att.com Martin Tatham British Telecom BT Adastal Park, Martlesham Heath, Ipswich, IP5 3RE UK Phone: +44 1473 606349 Fax: +44 1473 606727 EMail: martin.tatham@bt.com Fabio M. Chiussi Bell Laboratories, Lucent Technologies 101 Crawfords Corner Road Room 4D-521 Holmdel, NJ 07733 Phone: +1-732-949-2407 EMail: fabio@bell-labs.com Nadeau & van Der Linde Standards Track [Page 42] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 Joseph Dube Avici Systems, Inc. 101 Billerica Avenue North Billerica, MA 01862 Editors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 Phone: +1-978-936-1470 EMail: tnadeau@cisco.com Harmen van der Linde Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 Phone: +1-732-420-1916 EMail: havander@cisco.com Nadeau & van Der Linde Standards Track [Page 43] RFC 4382 MPLS-L3VPN-STD-MIB February 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nadeau & van Der Linde Standards Track [Page 44] snmp-mibs-downloader-1.1/mibrfcs/rfc4404.txt0000644000000000000000000016607311402176072015573 0ustar Network Working Group R. Natarajan Request for Comments: 4404 F5 Networks Category: Standards Track A. Rijhsinghani Accton Technology Corporation February 2006 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview of FCIP Management Model ...............................2 3. Relationship to Other MIBs ......................................4 4. MIB Definitions .................................................6 5. Security Considerations ........................................29 6. IANA Considerations ............................................30 7. Acknowledgements ...............................................30 8. Normative References ...........................................30 9. Informative References .........................................31 Natarajan & Rijhsinghani Standards Track [Page 1] RFC 4404 FCIP MIB February 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview of FCIP Management Model Note that the Fibre Channel Over TCP/IP (FCIP) Entity is fully described in [RFC3821] from a functional point of view. A collection of multiple instances of FCIP Entities and the corresponding FC Entities, described in [FCBB2], within an SNMP Context is referred to as an FCIP device here. This section describes FCIP from a management point of view. +------------------------------------------+ | FCIP Device | | | | +-----------+ +-----------+ | | |FCIP Entity| |FCIP Entity| | | | | | | | | | | | | | | +--+--+--+--+ +--+--+--+--+ | | | | | | | | | | | | | | | | | | FCIP Links FCIP Links | | | +------------------------------------------+ The FCIP device provides an IP-based interconnection model for interconnecting FC fabric elements. In this model, the FCIP devices along with the IP network on which they are running provide a new FCIP transport network. This IP-based FCIP Interconnection Model supports the following topology: o The FCIP-based transport network is formed by interconnecting the FCIP devices. Natarajan & Rijhsinghani Standards Track [Page 2] RFC 4404 FCIP MIB February 2006 o Each FCIP device has one or more FCIP Entities or Instances. o Peer FCIP Entities are connected by FCIP Links attached to VE_ports/B_Access. o Each FCIP Link Endpoint contains one or more Data Engines. o The FCIP device can work as a stand-alone box or as part of a FC fabric element. Each FCIP Entity managed by this MIB is referred to as an FCIP Instance. The MIB is broken up as follows: 2.1. FCIP Entity Instances Table The FCIP Entity table contains information about this entity's existing instances of FCIP entities. 2.2. FCIP Link Table The FCIP link table contains information about this FCIP device's existing FCIP links. 2.3. FCIP TCP Connection Table The FCIP TCP Connection table contains information about existing TCP connections. Each FCIP link within an FCIP entity contains one or more TCP connections. The FCIP entity employs a Data Engine for each TCP connection for handling FC frame encapsulation, de-encapsulation, and transmission of FCIP frames on the connection. 2.4. FCIP Dynamic Route Table The FCIP dynamic route table contains routing information that is dynamically discovered by this FCIP device. The FCIP device may use the SLPv2 protocol [RFC3822] in conjunction with other protocols, such as Fabric Shortest Path First (FSPF), to dynamically discover other FCIP entities and populate this table to map destination domains to FCIP Links. 2.5. FCIP Static Route Table The FCIP static route table contains routing information that is statically configured into this FCIP device by the Network Admin. In the absence of dynamic discovery of remote FCIP entities, the Network Manager can configure remote domains and FCIP Entities that are reachable by this device into this table. Natarajan & Rijhsinghani Standards Track [Page 3] RFC 4404 FCIP MIB February 2006 At any point in time, both the static and dynamic routing tables can be active. If a DID is present in both tables, information in the static route table will take precedence over the entry in the dynamic route table for the same DID. 2.6. FCIP Discovery Domain Table The FCIP Discovery Domain Table maps this device's FCIP Entities into FCIP Discovery Domains. 2.7. FCIP Link Error Table The FCIP Link Errors Table contains counters that indicate error conditions on an FCIP Link. 3. Relationship to Other MIBs Objects accessible from other MIB modules applicable to FCIP devices have not been included in this MIB module. The following subsections list all applicable MIB modules that should be present with FCIP- MGMT-MIB. 3.1. Relationship to the 'TCP' Group This group is mandatory for all systems that implement TCP. Objects relevant to TCP must be obtained from this group [RFC4022]. 3.2. Relationship to the 'interfaces' MIB The 'interfaces' group is defined as being mandatory for all systems and contains information on an entity's interfaces. Each logical/virtual interface created as an FCIP Link should be represented as a row in the ifTable with a unique ifIndex value and a value of ifType 'fcipLink' (224) for each such interface. For a complete list of interface types, refer to the IANA registry at "http://www.iana.org/assignments/smi-numbers". These are the only ifIndex values of relevance to an FCIP Entity because FCIP runs on top of TCP/IP. FCIP runs over TCP. Thus, by definition, there is no ifTable interface directly beneath it, and so ifStackLowerLayer is always 0. For any protocol using FCIP (i.e., above FCIP), FCIP appears to be a regular FC interface. As stated in [RFC4044], a regular "FC interface will typically have no other ifTable rows stacked on top of it", and thus, ifStackHigherLayer is typically zero. Natarajan & Rijhsinghani Standards Track [Page 4] RFC 4404 FCIP MIB February 2006 3.3. Relationship to the Fibre Channel Management MIB The Fibre Channel Management MIB [RFC4044] is assumed for FC functionality managed objects. 3.4. Specific Interface Group MIB Objects The following table provides specific implementation guidelines for applying the objects defined in the Interfaces Group MIB to FCIP Links. For those objects not listed here, refer to their generic definitions in [RFC2863]. Object Guidelines ifType 'fcipLink' (224) ifSpeed The ifSpeed for the physical interface(s) over which the FCIP Link runs. ifPhysAddress There is no physical address corresponding to an FCIP Link (only World Wide Name, WWN). Reported as 0. ifAdminStatus Write access is not required, and support for 'testing' is not required. ifOperStatus Support for 'testing' is not required. The value 'dormant' has no meaning for FCIP Links. ifInOctets The number of octets of FCIP information ifHCInOctets contained in received frames in TCP streams, starting with FCIP header. ifInUcastPkts The number of FCIP frames received ifHCInUcastPkts on this FCIP Link. ifOutOctets The number of octets of FCIP information ifHCOutOctets contained in transmitted frames in TCP streams, starting with FCIP header. ifOutUcastPkts The number of FCIP frames transmitted ifHCOutUcastPkts on this FCIP Link. Natarajan & Rijhsinghani Standards Track [Page 5] RFC 4404 FCIP MIB February 2006 ifInMulticastPkts These counters are not incremented. ifInBroadcastPkts ifOutMulticastPkts ifOutBroadcastPkts ifHCInMulticastPkts ifHCInBroadcastPkts ifHCOutMulticastPkts ifHCOutBroadcastPkts ifLinkUpDownTrapEnable Default is 'disabled'. ifPromiscuousMode This will be 'false'. ifConnectorPresent This will be 'false'. 4. MIB Definitions The following MIB module has IMPORTS from [RFC2578], [RFC2579], [RFC4001], [RFC4044], [RFC2863], [RFC2580], and [RFC3411]. In REFERENCE clauses, it refers to [FC-SW-3], [RFC3821], [RFC2883], [RFC1323], [RFC2474] and [RFC3822]. FCIP-MGMT-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, Unsigned32, Counter32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, RowStatus, TimeStamp FROM SNMPv2-TC InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB FcNameIdOrZero FROM FC-MGMT-MIB InterfaceIndex FROM IF-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; fcipMIB MODULE-IDENTITY LAST-UPDATED "200602060000Z" ORGANIZATION "IETF IPFC Working Group" CONTACT-INFO "Anil Rijhsinghani Accton Technology Corporation 5 Mount Royal Ave Marlboro, MA 01752 USA. Natarajan & Rijhsinghani Standards Track [Page 6] RFC 4404 FCIP MIB February 2006 Ravi Natarajan F5 Networks 2460 North First Street, Suite 100 San Jose, CA 95131 USA." DESCRIPTION "The module defines management information specific to FCIP devices. Copyright(C) The Internet Society (2006). This version of this MIB module is part of RFC 4404; see the RFC itself for full legal notices." REVISION "200602060000Z" DESCRIPTION "Initial version of this module, published as RFC 4404." ::= { mib-2 224 } fcipObjects OBJECT IDENTIFIER ::= { fcipMIB 1 } fcipConformance OBJECT IDENTIFIER ::= { fcipMIB 2 } fcipConfig OBJECT IDENTIFIER ::= { fcipObjects 1 } -- ****************************************************************** -- Textual conventions -- FcipDomainIdInOctetForm ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Domain ID of a FC entity in octet form to support the concatenation(000000h||Domain_ID) format defined in the FSPF routing protocol." REFERENCE "FC-SW-3 section 4.8" SYNTAX OCTET STRING (SIZE(1)) FcipEntityMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of port mode provided by an FCIP Entity for an FCIP Link. An FCIP Entity can be an E-Port mode for one of its FCIP Link Endpoints or a B-Port mode for another of its FCIP Link Endpoints." REFERENCE "FC-BB, rev 4.7, 2 May 1997, section 3." SYNTAX INTEGER { ePortMode(1), bPortMode(2) } Natarajan & Rijhsinghani Standards Track [Page 7] RFC 4404 FCIP MIB February 2006 FcipEntityId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The FCIP entity identifier as defined in RFC 3821." REFERENCE "RFC 3821, Section 7.1, FCIP Special Frame Format" SYNTAX OCTET STRING (SIZE(8)) -- ****************************************************************** -- The FCIP group -- -- This group defines the global scalar objects applicable to FCIP -- devices only -- fcipDynIpConfType OBJECT-TYPE SYNTAX INTEGER { slpv2(1), none(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of discovery protocol used to discover remote FCIP entities. The value of this object is persistent across system restarts." ::= { fcipConfig 1 } fcipDeviceWWN OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The World Wide Name of this FCIP device." ::= { fcipConfig 2 } fcipEntitySACKOption OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether the TCP Selective Acknowledgement Option is enabled at this FCIP device to let the receiver acknowledge multiple lost packets in a single ACK for faster Natarajan & Rijhsinghani Standards Track [Page 8] RFC 4404 FCIP MIB February 2006 recovery." REFERENCE "The Selective Ack option is defined in RFC 2883." ::= { fcipConfig 3 } -- ****************************************************************** -- The FCIP Entity Table -- fcipEntityInstanceTable OBJECT-TYPE SYNTAX SEQUENCE OF FcipEntityInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about this FCIP device's existing instances of FCIP entities." REFERENCE "RFC 3821, Section 5.4, FCIP Entity" ::= { fcipConfig 4 } fcipEntityInstanceEntry OBJECT-TYPE SYNTAX FcipEntityInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the FCIP entity table with information about a particular FCIP entity. Once a row has been created, it is non-volatile across agent restarts until it is deleted." INDEX { fcipEntityId } ::= { fcipEntityInstanceTable 1 } FcipEntityInstanceEntry ::= SEQUENCE { fcipEntityId FcipEntityId, fcipEntityName SnmpAdminString, fcipEntityAddressType InetAddressType, fcipEntityAddress InetAddress, fcipEntityTcpConnPort InetPortNumber, fcipEntitySeqNumWrap TruthValue, fcipEntityPHBSupport TruthValue, fcipEntityStatus RowStatus } fcipEntityId OBJECT-TYPE SYNTAX FcipEntityId MAX-ACCESS not-accessible Natarajan & Rijhsinghani Standards Track [Page 9] RFC 4404 FCIP MIB February 2006 STATUS current DESCRIPTION "The FCIP entity identifier." REFERENCE "RFC 3821, Section 7.1, FCIP Special Frame Format" ::= { fcipEntityInstanceEntry 1 } fcipEntityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively-assigned name for this FCIP entity." ::= { fcipEntityInstanceEntry 2 } fcipEntityAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address by which the entity is reachable. Only address types IPv4 and IPv6 are supported." ::= { fcipEntityInstanceEntry 3 } fcipEntityAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Internet address for the entity, if configured. The format of this address is determined by the value of the fcipEntityAddressType object." ::= { fcipEntityInstanceEntry 4 } fcipEntityTcpConnPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "A TCP port other than the FCIP Well-Known port on which the FCIP entity listens for new TCP connection requests. It contains the value zero(0) if the FCIP Entity only listens on the Well-Known port." DEFVAL { 0 } ::= { fcipEntityInstanceEntry 5 } fcipEntitySeqNumWrap OBJECT-TYPE SYNTAX TruthValue Natarajan & Rijhsinghani Standards Track [Page 10] RFC 4404 FCIP MIB February 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the FCIP Entity supports protection against sequence number wrap." REFERENCE "The PAWS option is defined in RFC 1323." ::= { fcipEntityInstanceEntry 6 } fcipEntityPHBSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the FCIP Entity supports PHB IP quality of service (QoS)." REFERENCE "Per hop behavior is defined in RFC 2474, definition of the Differentiated Services Field." ::= { fcipEntityInstanceEntry 7 } fcipEntityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the operational status of the row. When a management station sets the status to active(1), then the values for the objects fcipEntityName, fcipEntityAddressType, and fcipEntityAddress should be supplied as part of the set request. The values of the objects fcipEntityName, fcipEntityAddressType, and fcipEntityAddress can be changed if the row status is in active state. The object fcipEntityTcpConnPort takes the default value zero(0), if no value is supplied at the time of row creation. Setting the status to destroy(6) deletes the specified FCIP entity instance row from the table. It also deletes all the rows corresponding to the specified FCIP entity from the fcipLinkTable and fcipTcpConnTable tables." ::= { fcipEntityInstanceEntry 8 } Natarajan & Rijhsinghani Standards Track [Page 11] RFC 4404 FCIP MIB February 2006 -- ****************************************************************** -- The FCIP Link Table -- fcipLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF FcipLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about FCIP links that exist on this device." ::= { fcipConfig 5 } fcipLinkEntry OBJECT-TYPE SYNTAX FcipLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the FCIP link table containing information about a particular FCIP link. The values of the read-create objects in this table are persistent across system restarts." INDEX { fcipEntityId, fcipLinkIndex } ::= { fcipLinkTable 1 } FcipLinkEntry ::= SEQUENCE { fcipLinkIndex Unsigned32, fcipLinkIfIndex InterfaceIndex, fcipLinkCost Unsigned32, fcipLinkLocalFcipEntityMode FcipEntityMode, fcipLinkLocalFcipEntityAddressType InetAddressType, fcipLinkLocalFcipEntityAddress InetAddress, fcipLinkRemFcipEntityWWN FcNameIdOrZero, fcipLinkRemFcipEntityId FcipEntityId, fcipLinkRemFcipEntityAddressType InetAddressType, fcipLinkRemFcipEntityAddress InetAddress, fcipLinkStatus RowStatus, fcipLinkCreateTime TimeStamp } fcipLinkIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies one FCIP link within an FCIP entity." ::= { fcipLinkEntry 1 } Natarajan & Rijhsinghani Standards Track [Page 12] RFC 4404 FCIP MIB February 2006 fcipLinkIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the virtual interface corresponding to the FCIP Link running over TCP/IP." ::= { fcipLinkEntry 2 } fcipLinkCost OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The FSPF cost associated with this FCIP Link." DEFVAL { 0 } ::= { fcipLinkEntry 3 } fcipLinkLocalFcipEntityMode OBJECT-TYPE SYNTAX FcipEntityMode MAX-ACCESS read-only STATUS current DESCRIPTION "The mode of the local end of the FCIP link." ::= { fcipLinkEntry 4 } fcipLinkLocalFcipEntityAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address contained in the corresponding instance of fcipLinkLocalFcipEntityAddress. Only address types IPv4 and IPv6 are supported." ::= { fcipLinkEntry 5 } fcipLinkLocalFcipEntityAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Internet address for the local end of this FCIP Link. The format of this object is determined by the value of the fcipLinkLocalFcipEntityAddressType object." ::= { fcipLinkEntry 6 } fcipLinkRemFcipEntityWWN OBJECT-TYPE SYNTAX FcNameIdOrZero Natarajan & Rijhsinghani Standards Track [Page 13] RFC 4404 FCIP MIB February 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The World Wide Name of the remote FC Fabric Entity." REFERENCE "RFC 3821, Section 7.1, FCIP Special Frame Format" ::= { fcipLinkEntry 7 } fcipLinkRemFcipEntityId OBJECT-TYPE SYNTAX FcipEntityId MAX-ACCESS read-create STATUS current DESCRIPTION "The remote FCIP entity's identifier." REFERENCE "RFC 3821, Section 7.1, FCIP Special Frame Format" ::= { fcipLinkEntry 8 } fcipLinkRemFcipEntityAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address contained in the corresponding instance of fcipLinkRemFcipEntityAddress. Only address types IPv4 and IPv6 are supported." ::= { fcipLinkEntry 9 } fcipLinkRemFcipEntityAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Internet address for the remote end of this FCIP Link. The format of this object is determined by the value of the fcipLinkRemFcipEntityAddressType object." ::= { fcipLinkEntry 10 } fcipLinkStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the operational status of the row. The values of objects fcipLinkLocalFcipEntityAddressType, fcipLinkLocalFcipEntityAddress, fcipLinkRemFcipEntityWWN, fcipLinkRemFcipEntityId, fcipLinkRemFcipEntityAddressType, Natarajan & Rijhsinghani Standards Track [Page 14] RFC 4404 FCIP MIB February 2006 and fcipLinkRemFcipEntityAddress can be changed if the row is in active(1) state. The object fcipLinkCost is set to the value zero(0) if no value is supplied at the time of row creation. Setting the status to destroy(6) deletes the specified FCIP link from the table. It also deletes all rows corresponding to the specified FCIP link from the fcipTcpConnTable table." ::= { fcipLinkEntry 11 } fcipLinkCreateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last created." ::= { fcipLinkEntry 12 } -- ****************************************************************** -- The TCP Connection Table -- fcipTcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF FcipTcpConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about existing TCP connections. Each FCIP link within an FCIP entity manages one or more TCP connections. The FCIP entity employs a Data Engine for each TCP connection for handling FC frame encapsulation, de-encapsulation, and transmission of FCIP frames on the connection." ::= { fcipConfig 6 } fcipTcpConnEntry OBJECT-TYPE SYNTAX FcipTcpConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the FCIP TCP Connection table containing information about a particular TCP connection." INDEX { fcipEntityId, fcipLinkIndex, fcipTcpConnLocalPort, fcipTcpConnRemPort} ::= { fcipTcpConnTable 1 } Natarajan & Rijhsinghani Standards Track [Page 15] RFC 4404 FCIP MIB February 2006 FcipTcpConnEntry ::= SEQUENCE { fcipTcpConnLocalPort InetPortNumber, fcipTcpConnRemPort InetPortNumber, fcipTcpConnRWSize Unsigned32, fcipTcpConnMSS Unsigned32 } fcipTcpConnLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local port number for this TCP connection." ::= { fcipTcpConnEntry 1 } fcipTcpConnRemPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port number for this TCP connection." ::= { fcipTcpConnEntry 2 } fcipTcpConnRWSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The default maximum TCP Receiver Window size for this TCP connection." ::= { fcipTcpConnEntry 3 } fcipTcpConnMSS OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The TCP Maximum Segment Size (MSS) for this TCP connection." ::= { fcipTcpConnEntry 4 } Natarajan & Rijhsinghani Standards Track [Page 16] RFC 4404 FCIP MIB February 2006 -- ****************************************************************** -- The Dynamic Route Table -- fcipDynamicRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF FcipDynamicRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about dynamically discovered routing information. The FCIP device may use the SLPv2 protocol in conjunction with other protocols (say, FSPF) for dynamically discovering other FCIP entities and may populate this table with FCIP link information for each Destination Address Identifier." ::= { fcipConfig 7 } fcipDynamicRouteEntry OBJECT-TYPE SYNTAX FcipDynamicRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the FCIP Dynamic Route Table containing information about a particular FCIP route." INDEX { fcipEntityId, fcipDynamicRouteDID } ::= { fcipDynamicRouteTable 1 } FcipDynamicRouteEntry ::= SEQUENCE { fcipDynamicRouteDID FcipDomainIdInOctetForm, fcipDynamicRouteLinkIndex Unsigned32 } fcipDynamicRouteDID OBJECT-TYPE SYNTAX FcipDomainIdInOctetForm MAX-ACCESS not-accessible STATUS current DESCRIPTION "8-bit ID of a Fibre Channel Domain that is reachable from this FCIP device." ::= { fcipDynamicRouteEntry 1 } fcipDynamicRouteLinkIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The FCIP Link used to reach the domain specified by the Natarajan & Rijhsinghani Standards Track [Page 17] RFC 4404 FCIP MIB February 2006 corresponding instance of fcipDynamicRouteDID. The link identified by a value of this object is the same FCIP link as identified by the same value of fcipLinkIndex for the same FCIP entity." ::= { fcipDynamicRouteEntry 2 } -- ****************************************************************** -- The Static Route Table -- fcipStaticRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF FcipStaticRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about static route entries configured by the Network Admin. In the absence of dynamic discovery of remote FCIP entities, the Network Manager will figure out all remote FCIP devices that are reachable from this device and populate this table with FCIP link information for each Domain ID. At any time, both static and dynamic routing can be active, and an entry in the static route table for a given DID takes precedence over the entry in the dynamic route table for the same Domain ID." ::= { fcipConfig 8 } fcipStaticRouteEntry OBJECT-TYPE SYNTAX FcipStaticRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the FCIP Static Route Table containing information about a particular FCIP route. The values of the read-create objects in this table are persistent across system restarts." INDEX { fcipEntityId, fcipStaticRouteDID } ::= { fcipStaticRouteTable 1 } FcipStaticRouteEntry ::= SEQUENCE { fcipStaticRouteDID FcipDomainIdInOctetForm, fcipStaticRouteLinkIndex Unsigned32, fcipStaticRouteStatus RowStatus } fcipStaticRouteDID OBJECT-TYPE SYNTAX FcipDomainIdInOctetForm Natarajan & Rijhsinghani Standards Track [Page 18] RFC 4404 FCIP MIB February 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "8-bit ID of a Fibre Channel Domain that is reachable from this FCIP device." ::= { fcipStaticRouteEntry 1 } fcipStaticRouteLinkIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The FCIP Link used to reach the domain specified by the corresponding instance of fcipStaticRouteDID. The link identified by a value of this object is the same FCIP link as identified by the same value of fcipLinkIndex for the same FCIP entity." ::= { fcipStaticRouteEntry 2 } fcipStaticRouteStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the operational status of the row. When a management station sets the status to active(1), the values for the object fcipStaticRouteLinkIndex should be supplied as part of the set request. Setting the status to destroy(6) deletes the specified FCIP static route entry from the table." ::= { fcipStaticRouteEntry 3 } -- ****************************************************************** -- The FCIP Discovery Domain Table -- fcipDiscoveryDomainTable OBJECT-TYPE SYNTAX SEQUENCE OF FcipDiscoveryDomainEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about FCIP Discovery Domains. Each FCIP Discovery Domain is associated with one or more FCIP entities." ::= { fcipConfig 9 } Natarajan & Rijhsinghani Standards Track [Page 19] RFC 4404 FCIP MIB February 2006 fcipDiscoveryDomainEntry OBJECT-TYPE SYNTAX FcipDiscoveryDomainEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the FCIP Discovery Domain Table containing information about a particular FCIP Discovery Domain that is associated with one or more FCIP entities. The values of the read-write object fcipDiscoveryDomainName are persistent across system restarts." INDEX { fcipEntityId, fcipDiscoveryDomainIndex } ::= { fcipDiscoveryDomainTable 1 } FcipDiscoveryDomainEntry ::= SEQUENCE { fcipDiscoveryDomainIndex Unsigned32, fcipDiscoveryDomainName SnmpAdminString } fcipDiscoveryDomainIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer that uniquely identifies an FCIP Discovery Domain associated with this FCIP entity." ::= { fcipDiscoveryDomainEntry 1 } fcipDiscoveryDomainName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..128)) MAX-ACCESS read-write STATUS current DESCRIPTION "The name of this FCIP Discovery Domain." REFERENCE "RFC 3822, Section 4.1.1, FCIP Discovery Domains" ::= { fcipDiscoveryDomainEntry 2 } Natarajan & Rijhsinghani Standards Track [Page 20] RFC 4404 FCIP MIB February 2006 -- ****************************************************************** -- The FCIP Link Errors -- fcipLinkErrorsTable OBJECT-TYPE SYNTAX SEQUENCE OF FcipLinkErrorsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of error counters for FCIP Links. Each counter records the number of times a particular error happened that caused a TCP connection to close down." REFERENCE "RFC 3821, Section 5.2, FCIP Link" ::= { fcipConfig 10 } fcipLinkErrorsEntry OBJECT-TYPE SYNTAX FcipLinkErrorsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row of the FCIP Link Errors Table containing error counters for an FCIP Link." INDEX { fcipEntityId, fcipLinkIndex } ::= { fcipLinkErrorsTable 1 } FcipLinkErrorsEntry ::= SEQUENCE { fcipLinkFcipLossofFcSynchs Counter32, fcipLinkFcipEncapErrors Counter32, fcipLinkFcipNotReceivedSfResps Counter32, fcipLinkFcipSfRespMismatches Counter32, fcipLinkFcipSfInvalidNonces Counter32, fcipLinkFcipReceivedSfDuplicates Counter32, fcipLinkFcipSfInvalidWWNs Counter32, fcipLinkFcipBB2LkaTimeOuts Counter32, fcipLinkFcipSntpExpiredTimeStamps Counter32, fcipLinkTcpTooManyErrors Counter32, fcipLinkTcpExcessiveDroppedDatagrams Counter32, fcipLinkTcpSaParamMismatches Counter32 } fcipLinkFcipLossofFcSynchs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times FC synchronization was lost on this FCIP Natarajan & Rijhsinghani Standards Track [Page 21] RFC 4404 FCIP MIB February 2006 Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 1 } fcipLinkFcipEncapErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FCIP frames received with encapsulation errors such as improper header, format, or length. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 2 } fcipLinkFcipNotReceivedSfResps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an FCIP Special Frame Response was expected but not received on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 3 } fcipLinkFcipSfRespMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times FCIP Special Frame Bytes mismatch happened on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 4 } fcipLinkFcipSfInvalidNonces OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times FCIP Special Frame Invalid Connection Nonce happened on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 5 } fcipLinkFcipReceivedSfDuplicates OBJECT-TYPE SYNTAX Counter32 Natarajan & Rijhsinghani Standards Track [Page 22] RFC 4404 FCIP MIB February 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times duplicate FCIP Special Frames were received on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 6 } fcipLinkFcipSfInvalidWWNs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times FCIP Special Frames with invalid destination FC Fabric Entity WWN were received on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 7 } fcipLinkFcipBB2LkaTimeOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC Keep Alive Time-outs that occurred on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 8 } fcipLinkFcipSntpExpiredTimeStamps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames discarded due to an expired Simple Network Time Protocol (SNTP) timestamp on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 9 } fcipLinkTcpTooManyErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of TCP connections that closed down on this FCIP Link due to too many errors on the connection. The last discontinuity of this counter is indicated by Natarajan & Rijhsinghani Standards Track [Page 23] RFC 4404 FCIP MIB February 2006 fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 10 } fcipLinkTcpExcessiveDroppedDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of TCP connections that closed down on this FCIP Link due to an excessive number of dropped FCIP packets. The last discontinuity of this counter is indicated by fcipLinkCreateTime." ::= { fcipLinkErrorsEntry 11 } fcipLinkTcpSaParamMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times TCP connections with Security Association parameter mismatches were closed down on this FCIP Link. The last discontinuity of this counter is indicated by fcipLinkCreateTime." REFERENCE "RFC 3821, Section 9.4.2, TCP Connection Security Associations (SAs)" ::= { fcipLinkErrorsEntry 12 } -- ****************************************************************** -- Conformance Statements -- fcipCompliances OBJECT IDENTIFIER ::= { fcipConformance 1 } fcipGroups OBJECT IDENTIFIER ::= { fcipConformance 2 } fcipCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for FCIP MIB." MODULE -- this module MANDATORY-GROUPS { fcipEntityScalarGroup, fcipEntityInstanceGroup, fcipLinkGroup, fcipTcpConnGroup, fcipDiscoveryDomainGroup, fcipLinkErrorsGroup Natarajan & Rijhsinghani Standards Track [Page 24] RFC 4404 FCIP MIB February 2006 } GROUP fcipDynamicRouteGroup DESCRIPTION "This group is mandatory only for systems that do not have these objects in any other FC MIB. It may be implemented even in that case for convenience." GROUP fcipStaticRouteGroup DESCRIPTION "This group is mandatory only for systems that do not have these objects in any other FC MIB. It may be implemented even in that case for convenience." OBJECT fcipEntityAddressType SYNTAX INTEGER { ipv4(1), ipv6(2) } DESCRIPTION "Only IPv4 and IPv6 address types need to be supported for addressing FCIP entities." OBJECT fcipEntityAddress SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "Size of FCIP entity's IP address depends on address type. FCIP entity address size is four if the IP address is IPv4 and sixteen if the IP address type is IPv6." OBJECT fcipLinkLocalFcipEntityAddressType SYNTAX INTEGER { ipv4(1), ipv6(2) } DESCRIPTION "Only IPv4 and IPv6 address types need to be supported for addressing the local FCIP entities." OBJECT fcipLinkLocalFcipEntityAddress SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "Size of FCIP entity's IP address depends on address type. FCIP entity address size is four if the IP address is IPv4 and sixteen if the IP address type is IPv6." OBJECT fcipLinkRemFcipEntityAddressType SYNTAX INTEGER { ipv4(1), ipv6(2) } DESCRIPTION "Only IPv4 and IPv6 address types need to be supported for addressing the remote FCIP entities." OBJECT fcipLinkRemFcipEntityAddress SYNTAX InetAddress (SIZE(4|16)) Natarajan & Rijhsinghani Standards Track [Page 25] RFC 4404 FCIP MIB February 2006 DESCRIPTION "Size of FCIP entity's IP address depends on the address type. FCIP entity address size is four if the IP address is IPv4 and sixteen if the IP address type is IPv6." ::= { fcipCompliances 1 } fcipEntityScalarGroup OBJECT-GROUP OBJECTS { fcipDynIpConfType, fcipDeviceWWN, fcipEntitySACKOption } STATUS current DESCRIPTION "Collection of scalar objects applicable to all FCIP instances." ::= { fcipGroups 1 } fcipEntityInstanceGroup OBJECT-GROUP OBJECTS { fcipEntityName, fcipEntityAddressType, fcipEntityAddress, fcipEntityTcpConnPort, fcipEntitySeqNumWrap, fcipEntityPHBSupport, fcipEntityStatus } STATUS current DESCRIPTION "A collection of objects providing information about FCIP instances." ::= { fcipGroups 2 } fcipLinkGroup OBJECT-GROUP OBJECTS { fcipLinkIfIndex, fcipLinkCost, fcipLinkLocalFcipEntityMode, fcipLinkLocalFcipEntityAddressType, fcipLinkLocalFcipEntityAddress, fcipLinkRemFcipEntityWWN, fcipLinkRemFcipEntityId, fcipLinkRemFcipEntityAddressType, fcipLinkRemFcipEntityAddress, fcipLinkStatus, fcipLinkCreateTime } Natarajan & Rijhsinghani Standards Track [Page 26] RFC 4404 FCIP MIB February 2006 STATUS current DESCRIPTION "A collection of objects providing information about FCIP Links." ::= { fcipGroups 3 } fcipTcpConnGroup OBJECT-GROUP OBJECTS { fcipTcpConnRWSize, fcipTcpConnMSS } STATUS current DESCRIPTION "A collection of objects providing information about FCIP TCP connections." ::= { fcipGroups 4 } fcipDiscoveryDomainGroup OBJECT-GROUP OBJECTS { fcipDiscoveryDomainName } STATUS current DESCRIPTION "A collection of objects providing information about FCIP Discovery Domains." ::= { fcipGroups 5 } fcipLinkErrorsGroup OBJECT-GROUP OBJECTS { fcipLinkFcipLossofFcSynchs, fcipLinkFcipEncapErrors, fcipLinkFcipNotReceivedSfResps, fcipLinkFcipSfRespMismatches, fcipLinkFcipSfInvalidNonces, fcipLinkFcipReceivedSfDuplicates, fcipLinkFcipSfInvalidWWNs, fcipLinkFcipBB2LkaTimeOuts, fcipLinkFcipSntpExpiredTimeStamps, fcipLinkTcpTooManyErrors, fcipLinkTcpExcessiveDroppedDatagrams, fcipLinkTcpSaParamMismatches } STATUS current DESCRIPTION "A collection of objects providing information about FCIP link errors." ::= { fcipGroups 6 } Natarajan & Rijhsinghani Standards Track [Page 27] RFC 4404 FCIP MIB February 2006 fcipDynamicRouteGroup OBJECT-GROUP OBJECTS { fcipDynamicRouteLinkIndex } STATUS current DESCRIPTION "A collection of objects providing information about FCIP dynamic routes." ::= { fcipGroups 7 } fcipStaticRouteGroup OBJECT-GROUP OBJECTS { fcipStaticRouteLinkIndex, fcipStaticRouteStatus } STATUS current DESCRIPTION "A collection of objects providing information about FCIP static routes." ::= { fcipGroups 8 } END Natarajan & Rijhsinghani Standards Track [Page 28] RFC 4404 FCIP MIB February 2006 5. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. In particular, write access to fcipDiscoveryDomainName and fcipEntityAddress can cause a loss of reachability to portions of the Fibre Channel fabric, while write access to fcipStaticRouteStatus can create incorrect routes to remote devices. There are a number of managed objects in this MIB that contain what could be considered as sensitive information. In particular, the objects which provide information on identification and network topology: fcipDeviceWWN, fcipEntityName, fcipEntityAddress, fcipLinkLocalFcipEntityAddress, fcipLinkRemFcipEntityWWN, and fcipLinkRemFcipEntityAddress -- information on identification; fcipDiscoveryDomainName -- information on discovery domains; fcipDynamicRouteLinkIndex -- information on dynamic routes; fcipStaticRouteLinkIndex and fcipStaticRouteStatus -- information on static routes SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to Natarajan & Rijhsinghani Standards Track [Page 29] RFC 4404 FCIP MIB February 2006 the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations The IANA has assigned a MIB OID assignment under the transmission branch. Specifically, { transmission 224 } for fcipMIB since this MIB contains the media-specific definitions that correspond to the ifType value of fcipLink(224). 7. Acknowledgements The authors acknowledge significant feedback and guidance from NM Area advisor Keith McCloghrie, Cisco. Comments and input from members of the FCIP Working Group have also been incorporated. 8. Normative References [RFC3821] Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel Over TCP/IP (FCIP)", RFC 3821, July 2004. [FCBB2] Fibre Channel Backbone -2 v6 (FC-BB-2), T11/03-078v0, February 2003. [FC-SW-3] Fibre Channel Switch Fabric -3 (FC-SW-3), T11/03-018v4, December 2003. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Natarajan & Rijhsinghani Standards Track [Page 30] RFC 4404 FCIP MIB February 2006 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005. [RFC3822] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, July 2004. [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 9. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Natarajan & Rijhsinghani Standards Track [Page 31] RFC 4404 FCIP MIB February 2006 Authors' Addresses Anil Rijhsinghani Accton Technology Corporation 5 Mount Royal Ave Marlboro, MA 01752 USA EMail: anil@charter.net Ravi Natarajan F5 Networks 2460 North First Street, Suite 100 San Jose, CA 95131 USA EMail: r.natarajan@f5.com Natarajan & Rijhsinghani Standards Track [Page 32] RFC 4404 FCIP MIB February 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Natarajan & Rijhsinghani Standards Track [Page 33] snmp-mibs-downloader-1.1/mibrfcs/rfc4438.txt0000644000000000000000000021101411402176072015564 0ustar Network Working Group C. DeSanti Request for Comments: 4438 V. Gaonkar Category: Standards Track H.K. Vivek K. McCloghrie Cisco Systems S. Gai Retired April 2006 Fibre Channel Name Server MIB 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. DeSanti, et al. Standards Track [Page 1] RFC 4438 Fibre Channel Name Server MIB April 2006 Table of Contents 1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Short Overview of Fibre Channel .................................3 4. Relationship to Other MIBs ......................................5 5. MIB Overview ....................................................5 5.1. Fibre Channel Management Instance ..........................5 5.2. Name Server Information Subset .............................5 5.3. Fabric Index ...............................................6 5.4. The MIB Groups .............................................6 5.4.1. The t11NsDBGroup Group ..............................6 5.4.2. Three Statistics Groups .............................7 5.4.3. The t11NsNotifyGroup Group ..........................7 5.4.4. The t11NsNotifyControlGroup Group ...................7 5.5. The Actual Values of Objects ...............................7 6. The T11-FC-NAME-SERVER-MIB Module ...............................8 7. Acknowledgements ...............................................31 8. Normative References ...........................................32 9. Informative References .........................................33 10. IANA Considerations ...........................................33 11. Security Considerations .......................................33 DeSanti, et al. Standards Track [Page 2] RFC 4438 Fibre Channel Name Server MIB April 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Name Server function, which provides a means for Fibre Channel ports to register and discover Fibre Channel attributes. Such attributes include names, addresses, types, features, etc., at various protocol layers. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of Fibre Channel The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an DeSanti, et al. Standards Track [Page 3] RFC 4438 Fibre Channel Name Server MIB April 2006 Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the Fabric, each node, and most ports, have globally-unique names. These globally-unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers, which identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy. The Fibre Channel Name Server provides a way for N_Ports and NL_Ports to register and discover Fibre Channel attributes. Such attributes include names, addresses, types, features, etc., at various protocol layers, including upper layer protocols specific to Fibre Channel (which are sometimes called "FC-4s"). Communication with the Name Server is via Fibre Channel's CT (Common Transport for Generic Services) using "Information Units" (called CT_IUs) as either requests, responses, or unsolicited. Registrations may be performed by a third party. However, the Name Server may refuse such third-party registration for unspecified reasons. Once registered, the attributes are made available to requestors. Requestors could learn about new registrations via periodic polling of the Name Server, but such polling would generate a considerable overhead. To avoid this overhead, the Registered State Change Notification (RSCN) mechanism defined in FC-FS [FC-FS] allows an Nx_Port to register to receive an RSCN whenever an event occurs that may affect the state of other Nx_Port(s), including changes in the information registered with the Name Server. The Fibre Channel Name Server is defined in the FC-GS specification, The latest specification is [FC-GS-4]; the previous version was [FC-GS-3]. DeSanti, et al. Standards Track [Page 4] RFC 4438 Fibre Channel Name Server MIB April 2006 4. Relationship to Other MIBs The first standardized MIB for Fibre Channel [RFC2837] was focused on Fibre Channel switches. It was obsoleted by the more generic Fibre Channel Management MIB [FC-MGMT], which defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB [IF-MIB] for Fibre Channel interfaces. This MIB extends beyond [FC-MGMT] to cover the functionality, in Fibre Channel switches, of providing Fibre Channel's Name Server function. This MIB also imports some common textual conventions from T11-TC-MIB, defined in [FC-FAM-MIB]. 5. MIB Overview This MIB module provides the means for monitoring the operation of, and configuring some parameters of, one or more instances of Fibre Channel Name Server functionality. (Note that there are no definitions in this MIB module of "managed actions" that can be invoked via SNMP.) 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [FC-MGMT] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [FC-MGMT] as the index value to uniquely identify each Fibre Channel management instance within the same SNMP context ([RFC3411], section 3.3.1). 5.2. Name Server Information Subset In addition to allowing for multiple Fibre Channel management instances, this MIB is based on the notion that the information registered with the Name Server is available as one or more subsets. The MIB allows the different subsets to be accessed either: DeSanti, et al. Standards Track [Page 5] RFC 4438 Fibre Channel Name Server MIB April 2006 - via different SNMP agents/contexts, - via different Fibre Channel management instances within the same SNMP agent/context, and/or - via the same Fibre Channel management instance within the same SNMP agent/context. The union of these subsets (across all agents/contexts in the network) represents the total set of information registered with the Name Server. Note that the intersection of the subsets is often non-empty, and the use of the term "subset" does not preclude any subset from containing the complete set of Name Server information. Each of these subsets is identified using an index value called a Name Server Information Subset Index. Thus, all objects in this MIB are in tables that are INDEXed by at least fcmInstanceIndex and t11NsInfoSubsetIndex, where the latter contains a Name Server Information Subset Index value. 5.3. Fabric Index The [FC-SW-3] standard for an interconnecting Fabric consisting of multiple Fabric Switch elements describes the operation of a single Fabric in a physical infrastructure. The current [FC-SW-4] standard also supports the operation of multiple Virtual Fabrics operating within one (or more) physical infrastructures. In such a scenario, each Fabric has, of course, its own management instrumentation. In order to accommodate this scenario, this MIB module defines all Fabric-related information in tables that are INDEXed by an arbitrary integer, named a "Fabric Index". In a Fabric that is conformant to [FC-SW-3], the value of this Fabric Index will always be 1. 5.4. The MIB Groups This section describes the six MIB groups contained in the MIB. 5.4.1. The t11NsDBGroup Group This group contains information about the operation of the Name Server function acting upon a Name Server Information Subset, including an indication of whether such operation is performed local to a particular Fibre Channel switch, or independently of a Fibre Channel switch. It also contains the information currently registered in a particular Name Server Information Subset. DeSanti, et al. Standards Track [Page 6] RFC 4438 Fibre Channel Name Server MIB April 2006 5.4.2. Three Statistics Groups There are three groups of Name Server statistics objects: t11NsRequestStatsGroup -- stats about requests t11NsRscnStatsGroup -- stats about (Name Server) RSCNs t11NsRejectStatsGroup -- stats about rejects Each of these groups is conditionally mandatory; specifically, each group contains objects for particular statistics such that implementation of the group is mandatory only for an implementation that counts/captures the group's particular statistics. The intent here is not to force implementations to capture these statistics, but rather to have all implementations that do capture them, provide access to them via the same MIB objects. 5.4.3. The t11NsNotifyGroup Group This group contains a set of notifications that provide for monitoring the rejections of Name Server Registration Requests. 5.4.4. The t11NsNotifyControlGroup Group This group contains objects for controlling the generation of, and for information to be included in, the notifications defined in the t11NsNotifyGroup group. 5.5. The Actual Values of Objects The objects defined in the t11NsRegTable represent the values registered with the Name Server. The SNMP agent MUST report the actual values, even if they are incorrectly formatted. This is the reason why, for example, the two objects that represent IP addresses, t11NsNodeIpAddress and t11NsPortIpAddress, have the SYNTAX of OCTET STRING, so that they are able to represent invalid values (which could not be represented using InetAddressType and InetAddress). Similarly, each set of (t11NsRejectReasonCode, t11NsRejReasonCodeExp, t11NsRejReasonVendorCode) objects must hold the values of the actual reject, explanation, and vendor-specific codes that were present in the generated Reject message (the "Reject CT_IU"), irrespective of whether or not such code values were appropriate. DeSanti, et al. Standards Track [Page 7] RFC 4438 Fibre Channel Name Server MIB April 2006 6. The T11-FC-NAME-SERVER-MIB Module T11-FC-NAME-SERVER-MIB DEFINITIONS ::= BEGIN -- The MIB for management of the Fibre Channel functionality which -- implements the Name Server function. IMPORTS MODULE-IDENTITY,OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32, Integer32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] TruthValue, TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC -- [RFC2579] fcmInstanceIndex, FcPortType, FcAddressIdOrZero, FcClasses, FcNameIdOrZero FROM FC-MGMT-MIB -- [FC-MGMT] T11FabricIndex FROM T11-TC-MIB -- [FC-FAM-MIB] t11FamLocalSwitchWwn FROM T11-FC-FABRIC-ADDR-MGR-MIB; -- [FC-FAM-MIB] t11FcNameServerMIB MODULE-IDENTITY LAST-UPDATED "200603020000Z" ORGANIZATION "T11" CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com" DESCRIPTION "The MIB module for the management of the functionality, which realizes the FC-GS-4 requirements for Name Server (NS). Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4438; see the RFC itself for full legal notices." DeSanti, et al. Standards Track [Page 8] RFC 4438 Fibre Channel Name Server MIB April 2006 REVISION "200603020000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4438." ::= { mib-2 135 } t11NsNotifications OBJECT IDENTIFIER ::= { t11FcNameServerMIB 0 } t11NsMIBObjects OBJECT IDENTIFIER ::= { t11FcNameServerMIB 1 } t11NsMIBConformance OBJECT IDENTIFIER ::= { t11FcNameServerMIB 2 } t11NsStatus OBJECT IDENTIFIER ::= { t11NsMIBObjects 1 } t11NsStatistics OBJECT IDENTIFIER ::= { t11NsMIBObjects 2 } -- Textual Conventions T11NsGs4RejectReasonCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The FC-GS-4 reject reason code for a request. none(1) - no error. invalidCmdCode(2) - request contained an invalid command code. invalidVerLevel(3) - request contained an invalid version number. logicalError(4) - there was a logical error. invalidIUSize(5) - the CT_IU (Information Unit) size was invalid. logicalBusy(6) - the module is busy. protocolError(7) - there was a protocol error. unableToPerformCmdReq(8) - the command specified in the req could not be executed. The details of exactly what failed will be in the corresponding reason code explanation. cmdNotSupported(9) - the command is not supported. serverNotAvailable(10) - the identified server was not available. couldNotEstabSession(11) - a server session could not be established. vendorError(12) - a vendor-specific error." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4), section 4.4.3." DeSanti, et al. Standards Track [Page 9] RFC 4438 Fibre Channel Name Server MIB April 2006 SYNTAX INTEGER { none(1), invalidCmdCode(2), invalidVerLevel(3), logicalError(4), invalidIUSize(5), logicalBusy(6), protocolError(7), unableToPerformCmdReq(8), cmdNotSupported(9), serverNotAvailable(10), couldNotEstabSession(11), vendorError(12) } T11NsRejReasonCodeExpl ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The reject reason code explanation: noAdditionalExplanation(1) - no additional explanation. portIdentifierNotRegistered(2) - Port Identifier not registered. portNameNotRegistered(3) - Port Name not registered. nodeNameNotRegistered(4) - Node Name not registered. classOfServiceNotRegistered(5) - Class of Service not registered. nodeIpAddressNotRegistered(6) - 'IP Address (Node)' value not registered. ipaNotRegistered(7) - Initial Process Associator (IPA) not registered. fc4TypeNotRegistered(8) - FC-4 TYPEs not registered. symbolicPortNameNotRegistered(9) - Symbolic Port Name not registered. symbolicNodeNameNotRegistered(10) - Symbolic Node Name not registered. portTypeNotRegistered(11) - 'Port Type' not registered. portIpAddressNotRegistered(12) - 'IP Address (Port)' value not registered. fabricPortNameNotRegistered(13) - Fabric Port Name not registered. hardAddressNotRegistered(14) - 'Hard Address' not registered. DeSanti, et al. Standards Track [Page 10] RFC 4438 Fibre Channel Name Server MIB April 2006 fc4DescriptorNotRegistered(15) - FC-4 Descriptor not registered. fc4FeaturesNotRegistered(16) - FC-4 Features not registered. accessDenied(17) - Access denied. unacceptablePortIdentifier(18) - Unacceptable Port Identifier. databaseEmpty(19) - Database is empty. noObjectRegInSpecifiedScope(20) - no object has been registered in the specified scope. domainIdNotPresent(21) - Domain ID not present. portIdNotPresent(22) - Port number not present. noDeviceAttached(23) - No device attached. authorizationException(24) - Authorization Exception. authenticationException(25) - Authentication Exception. databaseFull(26) - Database full." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4), sections 4.4.4 and 5.2.4" SYNTAX INTEGER { noAdditionalExplanation(1), portIdentifierNotRegistered(2), portNameNotRegistered(3), nodeNameNotRegistered(4), classOfServiceNotRegistered(5), nodeIpAddressNotRegistered(6), ipaNotRegistered(7), fc4TypeNotRegistered(8), symbolicPortNameNotRegistered(9), symbolicNodeNameNotRegistered(10), portTypeNotRegistered(11), portIpAddressNotRegistered(12), fabricPortNameNotRegistered(13), hardAddressNotRegistered(14), fc4DescriptorNotRegistered(15), fc4FeaturesNotRegistered(16), accessDenied(17), unacceptablePortIdentifier(18), databaseEmpty(19), DeSanti, et al. Standards Track [Page 11] RFC 4438 Fibre Channel Name Server MIB April 2006 noObjectRegInSpecifiedScope(20), domainIdNotPresent(21), portIdNotPresent(22), noDeviceAttached(23), authorizationException(24), authenticationException(25), databaseFull(26) } -- -- Information about a Name Server Information Subset -- t11NsInfoSubsetTable OBJECT-TYPE SYNTAX SEQUENCE OF T11NsInfoSubsetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one entry for each Name Server Information Subset within each Fibre Channel management instance." ::= { t11NsStatus 1 } t11NsInfoSubsetEntry OBJECT-TYPE SYNTAX T11NsInfoSubsetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry contains information about operations on a particular Name Server Information Subset within the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11NsInfoSubsetIndex } ::= { t11NsInfoSubsetTable 1 } T11NsInfoSubsetEntry ::= SEQUENCE { t11NsInfoSubsetIndex Unsigned32, t11NsInfoSubsetSwitchIndex Unsigned32, t11NsInfoSubsetTableLastChange TimeStamp, t11NsInfoSubsetNumRows Integer32, t11NsInfoSubsetTotalRejects Counter32, t11NsInfoSubsetRejReqNotfyEnable TruthValue } t11NsInfoSubsetIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DeSanti, et al. Standards Track [Page 12] RFC 4438 Fibre Channel Name Server MIB April 2006 DESCRIPTION "An arbitrary integer value that uniquely identifies this Name Server Information Subset amongst all others within the same Fibre Channel management instance. It is mandatory to keep this value constant between restarts of the agent and to make every possible effort to keep it constant across such restarts." ::= { t11NsInfoSubsetEntry 1 } t11NsInfoSubsetSwitchIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is zero when operations upon this Name Server Information Subset do not occur at a local Fibre Channel switch; otherwise, it is non-zero and identifies the local switch. The switch identified by a non-zero value of this object is the same switch as is identified by the same value of fcmSwitchIndex." REFERENCE "fcmSwitchIndex is defined in the FC-MGMT-MIB module" ::= { t11NsInfoSubsetEntry 2 } t11NsInfoSubsetTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last update to any entry in the t11NsRegTable with the same values of fcmInstanceIndex and t11NsInfoSubsetIndex. This includes creation of an entry, deletion of an entry, or modification of an existing entry. If no such update has taken place since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { t11NsInfoSubsetEntry 3 } t11NsInfoSubsetNumRows OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Nx_Ports currently registered in this DeSanti, et al. Standards Track [Page 13] RFC 4438 Fibre Channel Name Server MIB April 2006 Name Server Information Subset, i.e., the number of rows in the t11NsRegTable with the same values of fcmInstanceIndex and t11NsInfoSubsetIndex." ::= { t11NsInfoSubsetEntry 4 } t11NsInfoSubsetTotalRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of (CT_IU) Requests for Name Server functions that were rejected for inclusion in this Name Server Information Subset, across all Fabrics for which it contains information. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11NsInfoSubsetEntry 5 } t11NsInfoSubsetRejReqNotfyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether 't11NsRejectRegNotify' notifications are generated by rejections of requests to register information in this Name Server Information Subset. If value of this object is 'true', then the notification is generated when a request is rejected. If it is 'false', the notification is not generated. The persistence of values of this object across an agent reboot is implementation-dependent." DEFVAL { false } ::= { t11NsInfoSubsetEntry 6 } -- -- Registered Port Information -- t11NsRegTable OBJECT-TYPE SYNTAX SEQUENCE OF T11NsRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains entries for all Nx_Ports registered DeSanti, et al. Standards Track [Page 14] RFC 4438 Fibre Channel Name Server MIB April 2006 in the identified Name Server Information Subsets across all Fabrics for which such subsets contain information." ::= { t11NsStatus 2 } t11NsRegEntry OBJECT-TYPE SYNTAX T11NsRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information about an Nx_Port represented by t11NsRegPortIdentifier that is registered with a Name Server Information Subset (identified by t11NsInfoSubsetIndex) within the Fibre Channel management instance (identified by fcmInstanceIndex) on the Fabric (identified by t11NsRegFabricIndex)." INDEX { fcmInstanceIndex, t11NsInfoSubsetIndex, t11NsRegFabricIndex, t11NsRegPortIdentifier } ::= { t11NsRegTable 1 } T11NsRegEntry ::= SEQUENCE { t11NsRegFabricIndex T11FabricIndex, t11NsRegPortIdentifier FcAddressIdOrZero, t11NsRegPortName FcNameIdOrZero, t11NsRegNodeName FcNameIdOrZero, t11NsRegClassOfSvc FcClasses, t11NsRegNodeIpAddress OCTET STRING, t11NsRegProcAssoc OCTET STRING, t11NsRegFc4Type OCTET STRING, t11NsRegPortType FcPortType, t11NsRegPortIpAddress OCTET STRING, t11NsRegFabricPortName FcNameIdOrZero, t11NsRegHardAddress FcAddressIdOrZero, t11NsRegSymbolicPortName SnmpAdminString, t11NsRegSymbolicNodeName SnmpAdminString, t11NsRegFc4Features OCTET STRING } t11NsRegFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric. In a Fabric conformant to SW-3, only a single Fabric can operate within a single physical infrastructure, and thus, the value of this Fabric Index will always be 1. DeSanti, et al. Standards Track [Page 15] RFC 4438 Fibre Channel Name Server MIB April 2006 However, it is possible that future standards will define how multiple Fabrics, each with its own management instrumentation, could operate within one (or more) physical infrastructures. To allow for this future possibility, this index value is used to uniquely identify a particular Fabric within a physical infrastructure." ::= { t11NsRegEntry 1 } t11NsRegPortIdentifier OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Fibre Channel Address Identifier of this Nx_Port. If no Port Identifier has been registered, then the value of this object is the zero-length string." ::= { t11NsRegEntry 2 } t11NsRegPortName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Port_Name (WWN) of this Nx_Port. If this object has not been registered, then its value is the zero-length string." DEFVAL {''H} ::= { t11NsRegEntry 3 } t11NsRegNodeName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Node_Name (WWN) of this Nx_Port. If this object has not been registered, then its value is the zero-length string." DEFVAL {''H} ::= { t11NsRegEntry 4 } t11NsRegClassOfSvc OBJECT-TYPE SYNTAX FcClasses MAX-ACCESS read-only STATUS current DESCRIPTION "The class of service indicator. This object is an array of bits that contain a bit map of the classes of service supported by the associated port. If a bit in DeSanti, et al. Standards Track [Page 16] RFC 4438 Fibre Channel Name Server MIB April 2006 this object is 1, it indicates that the class of service is supported by the associated port. When a bit is set to 0, it indicates that no class of service is supported by this Nx_Port. If this object has not been not registered for a port, then the instance for that port is not instantiated." ::= { t11NsRegEntry 5 } t11NsRegNodeIpAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the node of this Nx_Port, in network-byte order, either as a 32-bit IPv4 address or a 128-bit IPv6 address. For the former, the leftmost 96 bits (12 bytes) should contain x'00 00 00 00 00 00 00 00 00 00 FF FF', and the IPv4 address should be present in the rightmost 32 bits. Note that the value of this object is the IP address value that is received in the FC-GS-4 message Register IP address (Node) RIP_NN. It is not validated against any IP address format. If no 'IP address (Node)' has been registered, then the value of this object is the zero-length string." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4)" DEFVAL { ''H } ::= { t11NsRegEntry 6 } t11NsRegProcAssoc OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Fibre Channel Initial Process Associator (IPA). If no 'Initial Process Associator' has been registered, then the value of this object is the zero-length string." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4)" DEFVAL { ''H } ::= { t11NsRegEntry 7 } DeSanti, et al. Standards Track [Page 17] RFC 4438 Fibre Channel Name Server MIB April 2006 t11NsRegFc4Type OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC-4 protocol types supported by this Nx_Port. This is an array of 256 bits. Each bit in the array corresponds to a Type value as defined by Fibre Channel standards and contained in the Type field of the frame header. The order of the bits in the 256-bit (32-byte) value is the same as defined in FC-GS-4, section 5.2.3.8, and represented in network-byte order. If no 'FC-4 TYPEs' has been registered, then the value of this object is the zero-length string." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4), section 5.2.3.8." DEFVAL { ''H } ::= { t11NsRegEntry 8 } t11NsRegPortType OBJECT-TYPE SYNTAX FcPortType MAX-ACCESS read-only STATUS current DESCRIPTION "The port type of this port. If no 'Port Type' has been registered, then the value of this object is unidentified and is represented by the value 'unknown'." DEFVAL { 1 } -- 'unknown', see [FC-MGMT] ::= { t11NsRegEntry 9 } t11NsRegPortIpAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value that Fibre Channel calls an 'IP Address (Port)' that represents the IP address of the associated port. The value is either in 32-bit IPv4 format or 128-bit IPv6 format, in network-byte order. When this object contains an IPv4 address, the leftmost 96 bits (12 bytes) should contain x'00 00 00 00 00 00 00 00 00 00 FF FF'. The IPv4 address should be present in the rightmost 32 bits. Note that the value of this object is the IP address value DeSanti, et al. Standards Track [Page 18] RFC 4438 Fibre Channel Name Server MIB April 2006 that is received in the FC-GS-4 message Register IP address (Port) RIPP_ID. It is not validated against any IP address format. If no 'IP address (Port)' has been registered, then the value of this object is the zero-length string." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4, (FC-GS-4)" DEFVAL {''H} ::= { t11NsRegEntry 10 } t11NsRegFabricPortName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Fabric Port Name (WWN) of the Fx_Port to which this Nx_Port is attached. If no 'Fabric Port Name' has been registered, then the value of this object is the zero-length string." DEFVAL {''H} ::= { t11NsRegEntry 11 } t11NsRegHardAddress OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The format of this object is identical to the format of Hard Address defined in the Discover Address (ADISC) Extended Link Service (FC-FS). Hard Address is the 24-bit NL_Port identifier that consists of: - the 8-bit Domain_ID in the most significant byte - the 8-bit Area_ID in the next most significant byte - the 8-bit AL-PA (Arbitrated Loop Physical Address) which an NL_Port attempts acquire during FC-AL initialization in the least significant byte. If the port is not an NL_Port, or if it is an NL_Port but does not have a hard address, then all bits are reported as zeros. If no 'Hard Address' has been registered, then the DeSanti, et al. Standards Track [Page 19] RFC 4438 Fibre Channel Name Server MIB April 2006 value of this object is the zero-length string." DEFVAL {''H} ::= { t11NsRegEntry 12 } t11NsRegSymbolicPortName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The user-defined name of this port. If no 'Symbolic Port Name' has been registered, then the value of this object is the zero-length string." DEFVAL {''H} ::= { t11NsRegEntry 13 } t11NsRegSymbolicNodeName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The user-defined name of the node of this port. If no 'Symbolic Node Name' has been registered, then the value of this object is the zero-length string." DEFVAL {''H} ::= { t11NsRegEntry 14 } t11NsRegFc4Features OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC-4 Features associated with FC-4 Types on this port encoded as a 128-byte value in network-byte order, or the zero-length string if no 'FC-4 Features' have been registered. Section 5.2.3.15 of FC-GS-4 is the authoritative definition of the format of the 128-byte value, i.e., if different, FC-GS-4 takes precedence over the following description: The 128-byte value is an array of 4-bit values, one for each FC-4 Type value, positioned as follows: the 5 most significant bits of a Type value identify where it appears within the 128-byte value, specifically, within which word: DeSanti, et al. Standards Track [Page 20] RFC 4438 Fibre Channel Name Server MIB April 2006 - Word 0 (of the 128-byte value) contains information related to Types '00' through '07'; - Word 1 contains information related to Types '08' through 0F'; - and so forth, up to Word 31, which contains information related to Types 'F8' through 'FF'. The least significant of the eight 4-bit values in each Word represents an FC-4 Type with 000 as its 3 least significant bits, and most significant 4-bit value in each Word represents an FC-4 Type with 111 as its 3 least significant bits." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4), section 5.2.3.15." DEFVAL {''H} ::= { t11NsRegEntry 15 } -- -- Registered FC-4 Descriptors -- t11NsRegFc4DescriptorTable OBJECT-TYPE SYNTAX SEQUENCE OF T11NsRegFc4DescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains entries for all FC-4 Descriptors registered in the identified Name Server Information Subsets across all Fabrics for which such subsets contain information." ::= { t11NsStatus 3 } t11NsRegFc4DescriptorEntry OBJECT-TYPE SYNTAX T11NsRegFc4DescriptorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the t11NsRegFc4DescriptorTable, containing information about an FC-4 Descriptor that is associated with a particular FC-4 Type value. The particular FC-4 Descriptor was registered by an Nx_Port (identified by t11NsRegPortIdentifier) in a Name Server Information Subset (identified by t11NsInfoSubsetIndex) within the Fibre Channel management instance (identified by fcmInstanceIndex) on the Fabric (identified by DeSanti, et al. Standards Track [Page 21] RFC 4438 Fibre Channel Name Server MIB April 2006 t11NsRegFabricIndex). If no FC-4 Descriptors have been registered for a particular port, then there will be no entries in this table for that port." INDEX { fcmInstanceIndex, t11NsInfoSubsetIndex, t11NsRegFabricIndex, t11NsRegPortIdentifier, t11NsRegFc4TypeValue } ::= { t11NsRegFc4DescriptorTable 1 } T11NsRegFc4DescriptorEntry ::= SEQUENCE { t11NsRegFc4TypeValue Unsigned32, t11NsRegFc4Descriptor OCTET STRING } t11NsRegFc4TypeValue OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer value that identifies an FC-4 Type value (representing a particular protocol type, as specified in FC-FS) for which an FC-4 Descriptor has been registered. An instance of this object contains a 'Type value' that corresponds to a '1' bit in the value of the t11NsRegFc4Type registered for the same port; this correspondence is as specified in FC-GS-4." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4), section 5.2.3.8, and ANSI INCITS 373-2003, Fibre Channel - Framing and Signaling (FC-FS), section 9.6, Table 29." ::= { t11NsRegFc4DescriptorEntry 1 } t11NsRegFc4Descriptor OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC-4 Descriptor value that has been registered for the particular port on the particular Fabric, and for the FC-4 Type represented by the corresponding value of t11NsRegFc4TypeIndex. The format of an FC-4 Descriptor is dependent on the corresponding FC-4 Type value, but is represented in DeSanti, et al. Standards Track [Page 22] RFC 4438 Fibre Channel Name Server MIB April 2006 network-byte order." REFERENCE "ANSI INCITS 387-2004, Fibre Channel - Generic Services-4 (FC-GS-4), section 5.2.5.42" ::= { t11NsRegFc4DescriptorEntry 2 } -- -- Name Server per-Fabric Statistics -- t11NsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF T11NsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains per-Fabric state and statistics for operations upon the identified Name Server Information Subsets." ::= { t11NsStatistics 1 } t11NsStatsEntry OBJECT-TYPE SYNTAX T11NsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table contains state and statistics for operations upon a Name Server Information Subset (identified by t11NsInfoSubsetIndex) within the Fibre Channel management instance (identified by fcmInstanceIndex) on the Fabric (identified by t11NsRegFabricIndex)." INDEX { fcmInstanceIndex, t11NsInfoSubsetIndex, t11NsRegFabricIndex } ::= { t11NsStatsTable 1 } T11NsStatsEntry ::= SEQUENCE { t11NsInGetReqs Counter32, t11NsOutGetReqs Counter32, t11NsInRegReqs Counter32, t11NsInDeRegReqs Counter32, t11NsInRscns Counter32, t11NsOutRscns Counter32, t11NsRejects Counter32, t11NsDatabaseFull TruthValue } t11NsInGetReqs OBJECT-TYPE DeSanti, et al. Standards Track [Page 23] RFC 4438 Fibre Channel Name Server MIB April 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of (CT_IU) Get Requests received requesting information from this Name Server Information Subset on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11NsStatsEntry 1 } t11NsOutGetReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of (CT_IU) Get Requests sent in order to obtain information needed in this Name Server Information Subset on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11NsStatsEntry 2 } t11NsInRegReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of (CT_IU) Registration Requests received to register information in the Name Server Information Subset on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11NsStatsEntry 3 } t11NsInDeRegReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of (CT_IU) De-registration Requests received to de-register information from this Name Server Information Subset on this Fabric. This counter has no discontinuities other than those DeSanti, et al. Standards Track [Page 24] RFC 4438 Fibre Channel Name Server MIB April 2006 that all Counter32s have when sysUpTime=0." ::= { t11NsStatsEntry 4 } t11NsInRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of received RSCNs, indicating Name Server-related changes relating to this Name Server Information Subset on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11NsStatsEntry 5 } t11NsOutRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of transmitted RSCNs, indicating Name Server-related changes relating to this Name Server Information Subset on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11NsStatsEntry 6 } t11NsRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of CT_IU Requests for Name Server functions on this Name Server Information Subset on this Fabric that were rejected. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11NsStatsEntry 7 } t11NsDatabaseFull OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the database containing this DeSanti, et al. Standards Track [Page 25] RFC 4438 Fibre Channel Name Server MIB April 2006 Name Server Information Subset is full. This object is set to 'true' only if the Name Server is unable to allocate space for a new entry for the corresponding Fabric, and it is set to 'false' whenever an existing entry is deleted for the corresponding Fabric." ::= { t11NsStatsEntry 8 } -- -- Reject information objects -- t11NsRejectTable OBJECT-TYPE SYNTAX SEQUENCE OF T11NsRejectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about the most recent Name Server Registration Request failures for various ports on various Fabrics. If no information is available about the most recent rejection of a Registration Request on a particular port on a particular Fabric, then there will no entry in this table for that port and Fabric. When a t11NsRejectRegNotify notification is sent for such a Registration Request failure, the values of the objects in the relevant entry of this table are updated immediately prior to generating the notification." ::= { t11NsStatus 4 } t11NsRejectEntry OBJECT-TYPE SYNTAX T11NsRejectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information about the most recent rejection of a request to register information in the Name Server Information Subset (identified by t11NsInfoSubsetIndex) within the Fibre Channel management instance (identified by fcmInstanceIndex) for a particular port (identified by t11NsRegPortIdentifier) on a particular Fabric (identified by t11NsRegFabricIndex)." INDEX { fcmInstanceIndex, t11NsInfoSubsetIndex, t11NsRegFabricIndex, t11NsRegPortIdentifier } ::= { t11NsRejectTable 1 } T11NsRejectEntry ::= SEQUENCE { DeSanti, et al. Standards Track [Page 26] RFC 4438 Fibre Channel Name Server MIB April 2006 t11NsRejectCtCommandString OCTET STRING, t11NsRejectReasonCode T11NsGs4RejectReasonCode, t11NsRejReasonCodeExp T11NsRejReasonCodeExpl, t11NsRejReasonVendorCode OCTET STRING } t11NsRejectCtCommandString OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The binary content of the Registration Request, formatted as an octet string (in network byte order) containing the CT_IU, as described in Table 2 of [FC-GS-4] (including the preamble), which was most recently rejected for the particular Name Server Information Subset on the particular port on the particular Fabric. This object contains the zero-length string if and when the CT-IU's content is unavailable. When the length of this object is 255 octets, it contains the first 255 octets of the CT-IU (in network-byte order)." ::= { t11NsRejectEntry 1 } t11NsRejectReasonCode OBJECT-TYPE SYNTAX T11NsGs4RejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION "A registration reject reason code. This object contains the reason code of the most recent Name Server Registration Request failure for the particular port on the particular Fabric." ::= { t11NsRejectEntry 2 } t11NsRejReasonCodeExp OBJECT-TYPE SYNTAX T11NsRejReasonCodeExpl MAX-ACCESS read-only STATUS current DESCRIPTION "A registration reject reason code explanation. This object contains the reason code explanation of the most recent Name Server Registration Request failure for the particular port on the particular Fabric." ::= { t11NsRejectEntry 3 } DeSanti, et al. Standards Track [Page 27] RFC 4438 Fibre Channel Name Server MIB April 2006 t11NsRejReasonVendorCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "A registration reject vendor-specific code. This object contains the vendor-specific code of the most recent Name Server Registration Request failure for the particular port on the particular Fabric." ::= { t11NsRejectEntry 4 } -- -- Notifications -- t11NsRejectRegNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11NsRegPortName, t11NsRejectCtCommandString, t11NsRejectReasonCode, t11NsRejReasonCodeExp, t11NsRejReasonVendorCode } STATUS current DESCRIPTION "This notification is generated whenever a request to register information in a Name Server Information Subset (for which the corresponding instance of t11NsInfoSubsetRejReqNotfyEnable is 'true') is rejected on a particular Fabric for a particular Nx_Port. The value of t11FamLocalSwitchWwn indicates the WWN of the switch that received the request. (If the WWN is unavailable, the value is set to the zero-length string.) The value of t11NsRejectCtCommandString indicates the rejected request, and the values of t11NsRejectReasonCode, t11NsRejReasonCodeExp, and t11NsRejReasonVendorCode indicate the reason for the rejection. The value of t11NsRegPortName represents the Port Name if it is able to be extracted out of the Registration Request, or otherwise the value as currently registered on the port." ::= { t11NsNotifications 1 } -- -- Conformance DeSanti, et al. Standards Track [Page 28] RFC 4438 Fibre Channel Name Server MIB April 2006 -- t11NsMIBCompliances OBJECT IDENTIFIER ::= {t11NsMIBConformance 1} t11NsMIBGroups OBJECT IDENTIFIER ::= {t11NsMIBConformance 2} t11NsMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the Fibre Channel Name Server." MODULE MANDATORY-GROUPS {t11NsDBGroup, t11NsNotifyControlGroup, t11NsNotifyGroup} OBJECT t11NsInfoSubsetRejReqNotfyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP t11NsRequestStatsGroup DESCRIPTION "This group is mandatory only for an implementation that captures statistics related to Name Server requests." GROUP t11NsRscnStatsGroup DESCRIPTION "This group is mandatory only for an implementation that captures statistics related to Name Server-related RSCNs." GROUP t11NsRejectStatsGroup DESCRIPTION "This group is mandatory only for an implementation that captures statistics related to Name Server rejects." ::= { t11NsMIBCompliances 1 } -- Units of conformance t11NsDBGroup OBJECT-GROUP OBJECTS { t11NsInfoSubsetSwitchIndex, t11NsInfoSubsetTableLastChange, t11NsInfoSubsetNumRows, t11NsRegPortName, t11NsRegNodeName, t11NsRegClassOfSvc, DeSanti, et al. Standards Track [Page 29] RFC 4438 Fibre Channel Name Server MIB April 2006 t11NsRegNodeIpAddress, t11NsRegProcAssoc, t11NsRegFc4Type, t11NsRegPortType, t11NsRegPortIpAddress, t11NsRegFabricPortName, t11NsRegHardAddress, t11NsRegSymbolicPortName, t11NsRegSymbolicNodeName, t11NsRegFc4Features, t11NsRegFc4Descriptor } STATUS current DESCRIPTION "A collection of objects for monitoring the information registered in a Name Server Information Subset." ::= { t11NsMIBGroups 1 } t11NsRequestStatsGroup OBJECT-GROUP OBJECTS { t11NsInGetReqs, t11NsOutGetReqs, t11NsInRegReqs, t11NsInDeRegReqs, t11NsDatabaseFull} STATUS current DESCRIPTION "A collection of objects for displaying Name Server statistics and state for Name Server requests." ::= { t11NsMIBGroups 2 } t11NsRscnStatsGroup OBJECT-GROUP OBJECTS { t11NsInRscns, t11NsOutRscns } STATUS current DESCRIPTION "A collection of objects for displaying Name Server statistics for Name Server-related RSCNs." ::= { t11NsMIBGroups 3 } t11NsRejectStatsGroup OBJECT-GROUP OBJECTS { t11NsInfoSubsetTotalRejects, t11NsRejects } STATUS current DESCRIPTION "A collection of objects for displaying Name Server statistics for rejects." ::= { t11NsMIBGroups 4 } t11NsNotifyControlGroup OBJECT-GROUP DeSanti, et al. Standards Track [Page 30] RFC 4438 Fibre Channel Name Server MIB April 2006 OBJECTS { t11NsRejectCtCommandString, t11NsRejectReasonCode, t11NsRejReasonCodeExp, t11NsRejReasonVendorCode, t11NsInfoSubsetRejReqNotfyEnable } STATUS current DESCRIPTION "A collection of notification control and notification information objects for monitoring rejections of Name Server registrations." ::= { t11NsMIBGroups 5 } t11NsNotifyGroup NOTIFICATION-GROUP NOTIFICATIONS {t11NsRejectRegNotify } STATUS current DESCRIPTION "A collection of notifications for monitoring rejections of Name Server registrations." ::= { t11NsMIBGroups 6 } END 7. Acknowledgements This document began life as a work item of the INCITS Task Group T11.5. We wish to acknowledge the many contributions and comments from the INCITS Technical Committee T11, including the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 members, especially: Ken Hirata, Emulex Scott Kipp, McData Michael O'Donnell, McData Elizabeth G. Rodriguez, Dot Hill Steven L. Wilson, Brocade Bob Nixon, Emulex Thanks also to Orly Nicklass of RAD Data Communications, Bert Wijnen of Lucent, and those members of the IMSS WG who provided review comments. DeSanti, et al. Standards Track [Page 31] RFC 4438 Fibre Channel Name Server MIB April 2006 8. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)" ANSI INCITS 373-2003, April 2003. [FC-GS-3] "Fibre Channel - Generic Services - 3 (FC-GS-3)", ANSI INCITS 348-2000, November 2000. [FC-GS-4] "Fibre Channel - Generic Services - 4 (FC-GS-4)", ANSI INCITS 387-2004, February 2004. [FC-SW-3] "Fibre Channel - Switch Fabric - 3 (FC-SW-3)", ANSI INCITS 384-2004, June 2004. [FC-SW-4] "Fibre Channel - Switch Fabric - 4 (FC-SW-4)", ANSI INCITS 418-2006, 2006. [FC-MGMT] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [FC-FAM-MIB] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, April 2006. DeSanti, et al. Standards Track [Page 32] RFC 4438 Fibre Channel Name Server MIB April 2006 9. Informative References [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. 10. IANA Considerations IANA has assigned a MIB OID to the T11-FC-NAME-SERVER-MIB module under the appropriate subtree. 11. Security Considerations There is one management object defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. This object and its sensitivity/vulnerability is: t11NsInfoSubsetRejReqNotfyEnable -- the ability to enable/disable notifications. Such objects may be considered sensitive or vulnerable in some network environments. For example, the ability to change network topology or network speed may afford an attacker the ability to obtain better performance at the expense of other network users. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: DeSanti, et al. Standards Track [Page 33] RFC 4438 Fibre Channel Name Server MIB April 2006 t11NsRegTable -- contains information about registered Nx_Ports. t11NsStatsTable -- contains statistics and state information about the Name Server. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. DeSanti, et al. Standards Track [Page 34] RFC 4438 Fibre Channel Name Server MIB April 2006 Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Vinay Gaonkar Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 527-8576 EMail: vgaonkar@cisco.com H.K. Vivek Cisco Systems, Inc. 71 Millers Rd Bangalore, India Phone: +91 80 2289933x5117 EMail: hvivek@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com Silvano Gai Retired DeSanti, et al. Standards Track [Page 35] RFC 4438 Fibre Channel Name Server MIB April 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). DeSanti, et al. Standards Track [Page 36] snmp-mibs-downloader-1.1/mibrfcs/rfc4439.txt0000644000000000000000000022654111402176072015600 0ustar Network Working Group C. DeSanti Request for Comments: 4439 V. Gaonkar Category: Standards Track K. McCloghrie Cisco Systems S. Gai Retired March 2006 Fibre Channel Fabric Address Manager MIB 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. DeSanti, et al. Standards Track [Page 1] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 Table of Contents 1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Short Overview of Fibre Channel .................................3 4. Relationship to Other MIBs ......................................4 5. MIB Overview ....................................................5 5.1. Fibre Channel Management Instance ..........................5 5.2. Switch Index ...............................................5 5.3. Fabric Index ...............................................5 5.4. The t11FamGroup Group ......................................6 5.5. The t11FamDatabaseGroup Group ..............................6 5.6. The t11FamAreaGroup Group ..................................6 5.7. The t11FamCacheGroup Group .................................6 5.8. The t11FamCommandGroup Group ...............................6 5.9. The t11FamNotificationGroup Group ..........................6 5.10. Use of RCF and BF .........................................6 6. Definitions .....................................................8 6.1. The T11-TC-MIB Module ......................................8 6.2. The T11-FC-FABRIC-ADDR-MGR-MIB Module ......................9 7. Acknowledgements ...............................................35 8. Normative References ...........................................36 9. Informative References .........................................36 10. IANA Considerations ...........................................37 11. Security Considerations .......................................37 DeSanti, et al. Standards Track [Page 2] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. Fabric Address Manager refers to the functionality of acquiring DomainID(s) as specified in [FC-SW-3], and managing Fibre Channel Identifiers as specified in [FC-FS]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of Fibre Channel The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an DeSanti, et al. Standards Track [Page 3] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the Fabric, each node, and most ports, have globally-unique names. These globally-unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers, which identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a Fabric is in use, the FC address identifiers are dynamically assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy. Each switch in a Fabric is assigned one (or more) unique Domain_IDs using a two-step process. First, one switch, called Principal Switch, is selected from the switches of a Fabric. Then, the Principal Switch assigns Domain_IDs to the other switches of the Fabric. Address assignment within a domain is performed by the switch to which that Domain_ID is granted. 4. Relationship to Other MIBs The first standardized MIB for Fibre Channel [RFC2837] was focused on Fibre Channel switches. It is being replaced by the more generic Fibre Channel Management MIB [FC-MGMT], which defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB [IF-MIB] for Fibre Channel interfaces. [FC-MGMT] includes the specification of how the generic objects defined in [IF-MIB] apply to Fibre Channel interfaces. Note that an interface's ifIndex value must be unique within an SNMP context, irrespective of how many Fibre Channel management instances (see below) and how many Fibre Channel switches are instrumented within that SNMP context. This document defines the T11-FC-FABRIC-ADDR-MGR-MIB module, which extends beyond [FC-MGMT] to cover the functionality, in Fibre Channel switches, which is used to manage Fabric configuration, domains, and addresses within a domain. This document also contains a MIB module, T11-TC-MIB, to define textual conventions that might also be useful in other MIBs defined by T11. DeSanti, et al. Standards Track [Page 4] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 5. MIB Overview This section explains the use of a Fibre Channel management instance, a Switch Index, and a Fabric Index. It also describes the six MIB groups contained in the MIB. 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [FC-MGMT] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX sub-agents, with each sub- agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [FC-MGMT] as the index value to uniquely identify a Fibre Channel management instance. 5.2. Switch Index The FC-MGMT-MIB [FC-MGMT] defines the fcmSwitchTable as a table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value to uniquely identify a Fibre Channel switch amongst those (one or more) managed by the same Fibre Channel management instance. 5.3. Fabric Index The [FC-SW-3] standard for an interconnecting Fabric consisting of multiple Fabric Switch elements describes the operation of a single Fabric in a physical infrastructure. The current [FC-SW-4] standard also supports the operation of multiple Virtual Fabrics operating within one (or more) physical infrastructures. In such a scenario, each Fabric has, of course, its own management instrumentation. In order to accommodate this scenario, this MIB module defines all Fabric-related information in tables that are INDEXed by an arbitrary integer, named a "Fabric Index". In a Fabric that is conformant to [FC-SW-3], the value of this Fabric Index will always be 1. DeSanti, et al. Standards Track [Page 5] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 It is quite possible, and may even become likely, that (a port of) a Fibre Channel switch will be connected to multiple such Fabrics. Thus, in order to simplify a query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before t11FamFabricIndex when they both appear in the same INDEX clause. 5.4. The t11FamGroup Group This group contains basic information about the Fabric Address Manager functionality within a switch, including its configuration parameters that are per-interface (i.e., specified for a particular Fibre Channel interface identified by an ifIndex value). 5.5. The t11FamDatabaseGroup Group This group contains information about which switches are assigned to which domains. 5.6. The t11FamAreaGroup Group This group contains information about which Port-IDs have been assigned within the areas of the local domain. 5.7. The t11FamCacheGroup Group This conditional mandatory group contains information about all the FC address identifier assignments that have been recently released. This cache is kept to support the concept of Preferred Domain_ID via a best-effort attempt for (short-term) re-assignment of the same FC address identifiers. 5.8. The t11FamCommandGroup Group This optional group contains objects used for initiating an operation on a Fabric. 5.9. The t11FamNotificationGroup Group This group contains notifications of significant events concerning the Fabric Address management functionality within a switch. 5.10. Use of RCF and BF Included in [FC-SW-3] is the specification of Reconfigure Fabric (RCF) and Build Fabric (BF), both of which are command codes of the Switch Fabric Internal Link Service (SW_ILS). [FC-SW-3] includes the warning: DeSanti, et al. Standards Track [Page 6] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 NOTE 13 - Since the RCF causes a complete reconfiguration of the Fabric, and may cause addresses allocated to a Switch to change, this SW_ILS should be used with caution. The BF SW_ILS allows the Fabric to attempt reconfiguration without loss of or change of address and therefore should be attempted before an RCF. Examples of situations in which RCF may be appropriate include resolution of overlapped Domains, or the failure of a Fabric Reconfiguration initiated by a BF. Further, [FC-MI] specifies: A Fabric is prohibited from autonomously generating an RCF, but an outside administrative function may request a switch to generate an RCF. Such an administrative function is outside the scope of this technical report. The T11-FC-FABRIC-ADDR-MGR-MIB defined in this document is consistent with both of the above quotes since it defines two objects, t11FamAutoReconfigure and t11FamRestart, which are defined with a MAX-ACCESS of read-write, and setting them to the appropriate value is a means by which "an outside administrative function may request a switch to generate an RCF" [FC-MI]. Note, however, the MIB specifies in its compliance section that the minimum required level of support for these two objects is read-only. Further, for both t11FamAutoReconfigure and t11FamRestart, the MIB serves only as a request to generate; it does not represent the action of the RCF or BF. That is, a successful SNMP SetRequest on these objects will cause an RCF (or BF) to be sent, but SNMP does not/cannot ensure the successful operation of the SW_ILS operation. DeSanti, et al. Standards Track [Page 7] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 6. Definitions 6.1. The T11-TC-MIB Module T11-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] t11TcMIB MODULE-IDENTITY LAST-UPDATED "200603020000Z" ORGANIZATION "T11" CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com" DESCRIPTION "This module defines textual conventions used in T11 MIBs. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4439; see the RFC itself for full legal notices." REVISION "200603020000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4439." ::= { mib-2 136 } T11FabricIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A Fabric Index that is used as a unique index value to identify a particular Fabric within one (or more) physical infrastructures. In an environment that is conformant to FC-SW-3, where DeSanti, et al. Standards Track [Page 8] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 there is always exactly one Fabric in a single physical infrastructure, the value of this Fabric Index will always be 1. However, the current standard, FC-SW-4, defines how multiple Fabrics, each with its own management instrumentation, could operate within one (or more) physical infrastructures. When such multiple Fabrics are in use, this index value is used to uniquely identify a particular Fabric within a physical infrastructure. Note that the value of this textual convention has a range of (0..4095) so as to be consistent with FC-SW-4, which says that a 'VF_ID Bitmap' is 512 bytes long, with the high-order bit representing VF_ID zero, and the low-order bit representing 4095." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 6.1.27.2.4." SYNTAX Unsigned32 (0..4095) END 6.2. The T11-FC-FABRIC-ADDR-MGR-MIB Module T11-FC-FABRIC-ADDR-MGR-MIB DEFINITIONS ::= BEGIN -- the Fibre Channel Fabric Address Manager MIB -- -- for management of the functionality, in Fibre Channel switches, -- which is used to manage fabric configuration, domains, and -- addresses within a domain. -- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32, Gauge32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TEXTUAL-CONVENTION, TruthValue, RowStatus FROM SNMPv2-TC -- [RFC2579] ifIndex FROM IF-MIB -- [IF-MIB] fcmInstanceIndex, fcmSwitchIndex, FcDomainIdOrZero, FcNameIdOrZero FROM FC-MGMT-MIB -- [FC-MGMT] T11FabricIndex FROM T11-TC-MIB; t11FcFabricAddrMgrMIB MODULE-IDENTITY DeSanti, et al. Standards Track [Page 9] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 LAST-UPDATED "200603020000Z" ORGANIZATION "T11" CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com" DESCRIPTION "The MIB module for the Fabric Address management functionality defined by the Fibre Channel standards. For the purposes of this MIB, Fabric Address Manager refers to the functionality of acquiring DomainID(s) as specified in FC-SW-3, and managing Fibre Channel Identifiers as specified in FC-FS. An instance of 'Fabric Address Manager' software functionality executes in the Principal Switch, and in each other switch. After an agent reboot, the values of read-write objects defined in this MIB module are implementation-dependent. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4439; see the RFC itself for full legal notices." REVISION "200603020000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4439." ::= { mib-2 137 } t11FamNotifications OBJECT IDENTIFIER ::= { t11FcFabricAddrMgrMIB 0 } t11FamMIBObjects OBJECT IDENTIFIER ::= { t11FcFabricAddrMgrMIB 1 } t11FamMIBConformance OBJECT IDENTIFIER ::= { t11FcFabricAddrMgrMIB 2 } t11FamConfiguration OBJECT IDENTIFIER ::= { t11FamMIBObjects 1 } t11FamInfo OBJECT IDENTIFIER ::= { t11FamMIBObjects 2 } t11FamNotifyControl OBJECT IDENTIFIER ::= { t11FamMIBObjects 3 } -- Textual Conventions T11FamDomainPriority ::= TEXTUAL-CONVENTION DeSanti, et al. Standards Track [Page 10] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 DISPLAY-HINT "d" STATUS current DESCRIPTION "Priority of a switch. The Principal Switch selection is influenced by the priority of the switches. Some values of importance are: 1 : The highest priority in Principal Switch selection, which is used by the administrator to establish which switch becomes the Principal Switch. 255 : Indicates that the switch is not capable of acting as a Principal Switch." REFERENCE "Fibre Channel - Switch Fabric - 3 (FC-SW-3), ANSI INCITS 384-2004, section 6.1.5." SYNTAX Unsigned32 (1..255) T11FamDomainInterfaceRole ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The 'designated' state/role of the Inter-Switch Link (ISL) to which an interface connects, or (if not connected) the state of the interface: nonPrincipal (1) - non-Principal ISL principalUpstream (2) - Upstream Principal ISL principalDownsteam (3) - Downstream Principal ISL isolated (4) - interface is isolated down (5) - interface is down unknown (6) - state/role is unknown " REFERENCE "Fibre Channel - Switch Fabric - 3 (FC-SW-3), ANSI INCITS 384-2004, Sections 3.1, 5.7, and Figure 9." SYNTAX INTEGER { nonPrincipal (1), principalUpstream (2), principalDownsteam (3), isolated (4), down (5), unknown (6) } T11FamState ::= TEXTUAL-CONVENTION STATUS current DeSanti, et al. Standards Track [Page 11] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 DESCRIPTION "The state of the Fabric Address Manager, as described in Table 86 and Figure 15 of FC-SW-3. - 'other' represents a switch that is in a state not represented by any of the below enumerations. - 'starting' represents a switch engaged in the process represented by the first row in Table 86. - 'unconfigured' represents a switch that requires operator input before it can begin the process represented by the first row in Table 86. - 'principalSwitchSelection' represents a switch engaged in the process represented by the second row in Table 86, but not in states F0 or F1 of Figure 15. - 'domainIdDistribution' represents a switch engaged in the process represented by the third row in Table 86. - 'buildFabricPhase' represents a switch that is in state F0 of Figure 15. - 'reconfigureFabricPhase' represents a switch that is in state F1 of Figure 15. - 'stable' represents a switch that has successfully completed the process represented by the third row in Table 86 and has at least one E_Port. - 'stableWithNoEports' represents a switch that has successfully completed the process represented by the third row in Table 86 but has no E_Ports. - 'noDomains' represents a switch that has completed the process represented by the third row in Table 86 but failed to obtain a Domain_ID. - 'disabled' represents any situation in which the corresponding instance of t11FamEnable has the value 'false'. - 'unknown' represents a switch that is confused about what state it is in." REFERENCE "Fibre Channel - Switch Fabric - 3 (FC-SW-3), ANSI INCITS 384-2004, Table 86 and Figure 15." SYNTAX INTEGER { DeSanti, et al. Standards Track [Page 12] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 other(1), starting(2), unconfigured(3), principalSwitchSelection(4), domainIdDistribution(5), buildFabricPhase(6), reconfigureFabricPhase(7), stable(8), stableWithNoEports(9), noDomains(10), disabled(11), unknown(12) } -- -- t11FamTable -- t11FamTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains Fabric Address Manager related parameters that are able to be configured and monitored in a Fibre Channel switch. For each of the switches (identified by fcmSwitchIndex) managed by a Fibre Channel management instance (identified by fcmInstanceIndex), there is any entry for each Fabric known to that switch. Entries are implicitly created/removed if and when additional Fabrics are created/deleted." ::= { t11FamConfiguration 1 } t11FamEntry OBJECT-TYPE SYNTAX T11FamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry provides information on the local Fabric Address Manager functionality for a Fabric known to a particular switch." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FamFabricIndex } ::= { t11FamTable 1 } T11FamEntry ::= SEQUENCE { t11FamFabricIndex T11FabricIndex, t11FamConfigDomainId FcDomainIdOrZero, DeSanti, et al. Standards Track [Page 13] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamConfigDomainIdType INTEGER, t11FamAutoReconfigure TruthValue, t11FamContiguousAllocation TruthValue, t11FamPriority T11FamDomainPriority, t11FamPrincipalSwitchWwn FcNameIdOrZero, t11FamLocalSwitchWwn FcNameIdOrZero, t11FamAssignedAreaIdList OCTET STRING, t11FamGrantedFcIds Counter32, t11FamRecoveredFcIds Counter32, t11FamFreeFcIds Gauge32, t11FamAssignedFcIds Gauge32, t11FamAvailableFcIds Gauge32, t11FamRunningPriority T11FamDomainPriority, t11FamPrincSwRunningPriority T11FamDomainPriority, t11FamState T11FamState, t11FamLocalPrincipalSwitchSlctns Counter32, t11FamPrincipalSwitchSelections Counter32, t11FamBuildFabrics Counter32, t11FamFabricReconfigures Counter32, t11FamDomainId FcDomainIdOrZero, t11FamSticky TruthValue, t11FamRestart INTEGER, t11FamRcFabricNotifyEnable TruthValue, t11FamEnable TruthValue, t11FamFabricName FcNameIdOrZero } t11FamFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric known to a particular switch. In a Fabric conformant to FC-SW-3, only a single Fabric can operate within a physical infrastructure, and thus, the value of this Fabric Index will always be 1. However, the current standard, FC-SW-4, defines how multiple Fabrics, each with its own management instrumentation, could operate within one (or more) physical infrastructures. When such multiple Fabrics are in use, this index value is used to uniquely identify a particular Fabric within a physical infrastructure." ::= { t11FamEntry 1 } DeSanti, et al. Standards Track [Page 14] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamConfigDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "The configured Domain_ID of the particular switch on this Fabric, or zero if no Domain_ID has been configured. The meaning of this object depends on t11FamConfigDomainIdType object. If t11FamConfigDomainIdType is 'preferred', then the configured Domain_ID is called the 'preferred Domain_ID'. Valid values are between 0 and 239. In a situation where this Domain_ID cannot be assigned, any other Domain_ID will be acceptable. A value of zero means any Domain_ID. If t11FamConfigDomainIdType is 'insistent', then the configured Domain_ID is called the 'insistent Domain_ID' and valid values are between 1 and 239. In a situation where this Domain_ID cannot be assigned, no other Domain_ID is acceptable. In both of the above cases, the switch sends an RDI (Request Domain_ID) to request this Domain_ID to the Principal Switch. If no Domain_ID is able to be granted in the case of 'preferred', or if an 'insistent' Domain_ID is configured but not able to be granted, then it is an error condition. When this error occurs, the switch will continue as if it receives a SW_RJT with a reason/explanation of 'Unable to perform command request'/'Domain_ID not available'. That is, its E_Ports on that Fabric will be isolated and the administrator informed via a 't11FamDomainIdNotAssigned' notification. If t11FamConfigDomainIdType is 'static', then the configured Domain_ID is called the 'static Domain_ID' and valid values are between 1 and 239. In this situation, there is no Principal Switch in the Fabric and the Domain_ID is simply assigned by configuration, together with the Fabric_Name. A switch configured with a static Domain_ID, on receiving an EFP, BF, RCF, DIA, or RDI SW_ILS, shall reply with an SW_RJT having Reason Code Explanation 'E_Port is Isolated' and shall isolate the receiving E_Port. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 7." DeSanti, et al. Standards Track [Page 15] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 DEFVAL { 0 } ::= { t11FamEntry 2 } t11FamConfigDomainIdType OBJECT-TYPE SYNTAX INTEGER { preferred(1), insistent(2), static(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Type of configured Domain_ID contained in t11FamConfigDomainId. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." DEFVAL { preferred } ::= { t11FamEntry 3 } t11FamAutoReconfigure OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines how a particular switch responds to certain error conditions. The condition that might cause these errors is the merging of two disjoint Fabrics that have overlapping Domain_ID lists. If value of this object is 'true', the switch will send an RCF (ReConfigureFabric) to rebuild the Fabric. If 'false', the switch will isolate the E_Ports on which the errors happened. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." REFERENCE "Fibre Channel - Switch Fabric - 3 (FC-SW-3), December 2003, sections 6.1.12 & 7.3. Fibre Channel - Methodologies for Interconnects (FC-MI), INCITS TR-30-2002, table 14, note g." DEFVAL { false } ::= { t11FamEntry 4 } DeSanti, et al. Standards Track [Page 16] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamContiguousAllocation OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Determines how a particular switch behaves when elected as the Principal Switch. If true, the switch will only accept RDIs with a contiguous allocation; specifically, it will reject RDIs with non-contiguous Domain_IDs, and if an RDI for a contiguous Domain_ID is not able to be fulfilled, it will try to replace all the Domain_IDs in the list with contiguous Domain_IDs, and if that fails, the RDI will be rejected. If false, then the switch acts normally in granting the Domain_IDs even if they are not contiguous. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." ::= { t11FamEntry 5 } t11FamPriority OBJECT-TYPE SYNTAX T11FamDomainPriority MAX-ACCESS read-write STATUS current DESCRIPTION "The initial or configured priority of a particular switch to be used in Principal Switch selection process. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." ::= { t11FamEntry 6 } t11FamPrincipalSwitchWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The WWN of the Principal Switch on this Fabric, or zero-length string if the identity of the principal switch is unknown." DEFVAL { ''H } ::= { t11FamEntry 7 } t11FamLocalSwitchWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only DeSanti, et al. Standards Track [Page 17] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 STATUS current DESCRIPTION "The WWN of the particular switch on this Fabric." ::= { t11FamEntry 8 } t11FamAssignedAreaIdList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..256)) MAX-ACCESS read-only STATUS current DESCRIPTION "The list of (zero or more) Area_IDs that have been assigned by a particular switch in this Fabric, formatted as an array of octets in ascending order. Each octet represents one Area_ID. So, the list containing Area_IDs 23, 45, 235, and 56 would be formatted as the 4-octet string x'172d38eb'. A particular area's Area_ID is used as the index into the t11FamAreaTable to get the statistics on that area." ::= { t11FamEntry 9 } t11FamGrantedFcIds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Fibre Channel Address Identifiers granted (for local use, i.e., with a particular switch's Domain_ID) by the Fabric Address Manager on that switch. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FamEntry 10 } t11FamRecoveredFcIds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Fibre Channel Address Identifiers that have been recovered by the Fabric Address Manager on a particular switch since the switch has been initialized. A recovered Fibre Channel Address Identifier is one that is explicitly returned after previously being used. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." DeSanti, et al. Standards Track [Page 18] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 ::= { t11FamEntry 11 } t11FamFreeFcIds OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Fibre Channel Address Identifiers that are currently unassigned on this Fabric and could be available for assignment either immediately or at some later time. The sum of the instances of FreeFcIds and AssignedFcIds corresponding to a particular Fabric is the total number of Fibre Channel Address Identifiers that the local Fabric Address Management is capable of assigning on that Fabric." ::= { t11FamEntry 12 } t11FamAssignedFcIds OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Fibre Channel Address Identifiers that are currently assigned on this Fabric. The sum of the instances of FreeFcIds and AssignedFcIds corresponding to a particular Fabric is the total number of Fibre Channel Address Identifiers that the local Fabric Address Management is capable of assigning on that Fabric." ::= { t11FamEntry 13 } t11FamAvailableFcIds OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Fibre Channel Address Identifiers that are unassigned and currently available for immediate assignment on the Fabric, e.g., with the 'Clean Address' bit set to 1." REFERENCE "Fibre Channel - Framing and Signaling (FC-FS), ANSI INCITS 373-2003, section 15.6.2.4.2." ::= { t11FamEntry 14 } t11FamRunningPriority OBJECT-TYPE SYNTAX T11FamDomainPriority MAX-ACCESS read-only STATUS current DeSanti, et al. Standards Track [Page 19] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 DESCRIPTION "The running priority of a particular switch on this Fabric. This value is initialized to the value of t11FamPriority, and subsequently altered as specified by the procedures defined in FC-SW-3." ::= { t11FamEntry 15 } t11FamPrincSwRunningPriority OBJECT-TYPE SYNTAX T11FamDomainPriority MAX-ACCESS read-only STATUS current DESCRIPTION "The running priority of the Principal Switch on this Fabric." ::= { t11FamEntry 16 } t11FamState OBJECT-TYPE SYNTAX T11FamState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the Fabric Address Manager on a particular switch on this Fabric." ::= { t11FamEntry 17 } t11FamLocalPrincipalSwitchSlctns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a particular switch became the Principal Switch on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FamEntry 18 } t11FamPrincipalSwitchSelections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Principal Switch selections on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FamEntry 19 } DeSanti, et al. Standards Track [Page 20] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamBuildFabrics OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of non-disruptive fabric reconfigurations (BFs) that have occurred on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FamEntry 20 } t11FamFabricReconfigures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of disruptive fabric reconfigurations (RCFs) that have occurred on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FamEntry 21 } t11FamDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Domain_ID of a particular switch on this Fabric or zero if no Domain_ID has been assigned." ::= { t11FamEntry 22 } t11FamSticky OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether a particular switch is supporting the concept of Preferred Domain_IDs via a best-effort attempt to re-assign the same Fibre Channel Address Identifier value to a port on the next occasion when a port requests an assignment on this Fabric. If the value of this object is 'true', then the switch is maintaining rows in the t11FamFcIdCacheTable for this Fabric." ::= { t11FamEntry 23 } DeSanti, et al. Standards Track [Page 21] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamRestart OBJECT-TYPE SYNTAX INTEGER { nonDisruptive(1), disruptive(2), noOp(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object tells the Fabric Address Manager to request a Fabric reconfiguration. If this object is set to 'disruptive', then an RCF (ReConfigure Fabric) is generated in the Fabric in order for the Fabric to recover from the errors. If this object is set to 'nonDisruptive', then a BF (Build Fabric) is generated in the Fabric. No action is taken if this object is set to 'noOp'. The value of the object when read is always 'noOp'. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." REFERENCE "Fibre Channel - Switch Fabric - 3 (FC-SW-3), ANSI INCITS 384-2004, section 7.3." ::= { t11FamEntry 24 } t11FamRcFabricNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "An indication of whether or not a particular switch should issue a t11FamFabricChangeNotify notification on sending or receiving ReConfigureFabric (RCF) on a Fabric. If the value of the object is 'true', then the notification is generated. If the value is 'false', notification is not generated. If an implementation requires all Fabrics to have the same value, then setting one instance of this object to a new object will result in all corresponding instances being set to that same new value. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." DeSanti, et al. Standards Track [Page 22] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 DEFVAL { false } ::= { t11FamEntry 25 } t11FamEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Enables the Fabric Address Manager on this switch on this Fabric. If enabled on a Fabric, the switch will participate in Principal Switch selection, and Domain_IDs are assigned dynamically. If disabled, the switch will not participate in Principal Switch selection, and Domain_IDs are assigned statically. Thus, the corresponding value of t11FamConfigDomainIdType needs to be 'static'. For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, sections 7.1 and 7.3." DEFVAL { true } ::= { t11FamEntry 26 } t11FamFabricName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "The WWN that is configured on this switch to be used as the name of this Fabric when the value of t11FamEnable is 'false'. If the value of t11FamEnable is 'true', this value is not used. Fibre Channel requires that: a) all switches in an operational Fabric be configured with the same Fabric name; and b) each Fabric have a unique Fabric name. If either of these is violated, either by switches within a single Fabric being configured with different Fabric names, or by multiple Fabrics that share management applications or interact in other ways having the same Fabric name, then the behavior of the switches and associated management functions is not specified by Fibre Channel or Internet standards. DeSanti, et al. Standards Track [Page 23] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 7.1." ::= { t11FamEntry 27 } -- -- t11FamIfTable - Interface configuration -- t11FamIfTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FamIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains those Fabric Address Manager parameters and status values that are per-interface (identified by an ifIndex value), per-Fabric (identified by a t11FamFabricIndex value), and per-switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). An entry in this table is automatically created when an E_Port becomes non-isolated on a particular Fabric. An entry is deleted automatically from this table if: a) the corresponding interface is no longer an E_Port (e.g., a G_Port that is dynamically determined to be an F_Port), and all configuration parameter(s) have default values; or b) the interface identified by ifIndex no longer exists (e.g., because a line-card is physically removed); or c) the row in the t11FamTable corresponding the fabric identified by t11FamFabricID no longer exists. Creating an entry in this table via t11FamIfRowStatus provides the means to specify non-default parameter value(s) for an interface at a time when the relevant row in this table does not exist, i.e., because the interface is either down or it is not an E_Port." ::= { t11FamConfiguration 2 } t11FamIfEntry OBJECT-TYPE SYNTAX T11FamIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information on the interface configuration on the Fabric identified by DeSanti, et al. Standards Track [Page 24] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FamFabricIndex, ifIndex} ::= { t11FamIfTable 1 } T11FamIfEntry ::= SEQUENCE { t11FamIfRcfReject TruthValue, t11FamIfRole T11FamDomainInterfaceRole, t11FamIfRowStatus RowStatus } t11FamIfRcfReject OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object determines if the incoming ReConfigure Fabric (RCF) messages on this interface on this Fabric is accepted or not. If this object is 'true', then the incoming RCF is rejected. If 'false', incoming RCF is accepted. Note that this object does not apply to the outgoing RCFs generated by this interface. Implementations that support write-access to this object can do so under whatever conditions they choose." DEFVAL {false} ::= { t11FamIfEntry 1 } t11FamIfRole OBJECT-TYPE SYNTAX T11FamDomainInterfaceRole MAX-ACCESS read-only STATUS current DESCRIPTION "The role of this interface." ::= { t11FamIfEntry 2 } t11FamIfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row." ::= { t11FamIfEntry 3 } -- DeSanti, et al. Standards Track [Page 25] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 -- t11FamAreaTable -- t11FamAreaTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FamAreaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains area assignments per-Fabric by a switch's Fabric Address Manager. Each octet in t11FamAssignedAreaList is able to be used to index into this table to find information on each area." REFERENCE "Fibre Channel - Switch Fabric - 3 (FC-SW-3), ANSI INCITS 384-2004, section 4.8." ::= { t11FamInfo 1 } t11FamAreaEntry OBJECT-TYPE SYNTAX T11FamAreaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry gives information on the Area_ID and all Port_IDs that have been assigned within an area for the Fabric identified by t11FamFabricIndex, by the Fabric Address Manager in the switch identified by fcmInstanceIndex and fcmSwitchIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FamFabricIndex, t11FamAreaAreaId} ::= { t11FamAreaTable 1 } T11FamAreaEntry ::= SEQUENCE { t11FamAreaAreaId Unsigned32, t11FamAreaAssignedPortIdList OCTET STRING } t11FamAreaAreaId OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Area_ID of this area." ::= { t11FamAreaEntry 1 } t11FamAreaAssignedPortIdList OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..256)) MAX-ACCESS read-only STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 26] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 "The list of Port_IDs which have been assigned in this area and Fabric, formatted as an array of octets in ascending order. There could be zero or more Port_IDs assigned on this area and Fabric. Each octet represents one Port_ID. So, the list containing the Port_IDs 23, 45, 235, and 56 would be formatted as the 4-octet string x'172d38eb'." ::= { t11FamAreaEntry 2 } -- -- t11FamDatabaseTable -- t11FamDatabaseTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FamDatabaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all information known by a switch about all the domains that have been assigned in each Fabric." REFERENCE "Fibre Channel - Switch Fabric - 3 (FC-SW-3), ANSI INCITS 384-2004, section 4.8." ::= { t11FamInfo 2 } t11FamDatabaseEntry OBJECT-TYPE SYNTAX T11FamDatabaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the t11FamDatabaseTable containing information about one Domain_ID in the Fabric identified by t11FamFabricIndex, and known by the switch identified by t11FamFabricIndex and t11FamDatabaseDomainId." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FamFabricIndex , t11FamDatabaseDomainId} ::= { t11FamDatabaseTable 1 } T11FamDatabaseEntry ::= SEQUENCE { t11FamDatabaseDomainId FcDomainIdOrZero, t11FamDatabaseSwitchWwn FcNameIdOrZero } t11FamDatabaseDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero (1..239) DeSanti, et al. Standards Track [Page 27] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Domain_ID for which this row contains information. The value must be non-zero." ::= { t11FamDatabaseEntry 1 } t11FamDatabaseSwitchWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The node name (WWN) of the switch to which the corresponding value of t11FamDatabaseDomainId is currently assigned for the particular Fabric." ::= { t11FamDatabaseEntry 2 } -- -- Fibre Channel Address Identifier cache information -- -- The cached information allows the Fabric Address Manager to -- implement the concept of a Preferred Domain_ID, whereby after a port -- releases a Fibre Channel Address Identifier value, a switch makes an -- attempt to re-assign the same Fibre Channel Address Identifier value -- on the next occasion when that port requests an assignment. -- t11FamMaxFcIdCacheSize OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of Fibre Channel Address Identifiers that are able to be cached in the t11FamFcIdCacheTable. If the number is unknown, the value of this object is zero." ::= { t11FamInfo 3 } -- -- t11FamFcIdCacheTable -- t11FamFcIdCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FamFcIdCacheEntry MAX-ACCESS not-accessible STATUS current DeSanti, et al. Standards Track [Page 28] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 DESCRIPTION "This table contains all the Fibre Channel Address Identifiers that have recently been released by the Fabric Address Manager in a switch. So, it lists all the Fibre Channel Address Identifiers that have valid WWN-to-Fibre Channel Address Identifier mappings and are currently not assigned to any ports. These Fibre Channel Address Identifiers were assigned to ports but have since been released. These cached Fibre Channel Address Identifiers contain only Area_ID and Port_ID information. This cache is kept to provide best-effort re-assignment of same Fibre Channel Address Identifiers; i.e., when an Nx_Port asks for a Fibre Channel Address Identifier, soon after releasing one, the same value is re-assigned, if possible." ::= { t11FamInfo 4 } t11FamFcIdCacheEntry OBJECT-TYPE SYNTAX T11FamFcIdCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the t11FamFcIdCacheTable containing information about one Fibre Channel Address Identifier that was released from a WWN, corresponding to a range of one or more ports connected to the switch (identified by t11FamFabricIndex and t11FamFcIdCacheWwn) in the Fabric (identified by t11FamFabricIndex). An entry is created when a Fibre Channel Address Identifier is released by the last port in the range. The oldest entry is deleted if the number of rows in this table reaches t11FamMaxFcIdCacheSize, and its space is required for a new entry. An entry is also deleted when its Fibre Channel Address Identifier is assigned to a port." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FamFabricIndex, t11FamFcIdCacheWwn} ::= { t11FamFcIdCacheTable 1 } T11FamFcIdCacheEntry ::= SEQUENCE { t11FamFcIdCacheWwn FcNameIdOrZero, t11FamFcIdCacheAreaIdPortId OCTET STRING, t11FamFcIdCachePortIds Unsigned32 } t11FamFcIdCacheWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS not-accessible STATUS current DeSanti, et al. Standards Track [Page 29] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 DESCRIPTION "The N_Port_Name (WWN) of the port associated with this entry." ::= { t11FamFcIdCacheEntry 1 } t11FamFcIdCacheAreaIdPortId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "The combination of this object and t11FamFcIdCachePortIds represent one range of Fibre Channel Address Identifiers, which were assigned and later released. This object contains the Area_ID and Port_ID of the first Fibre Channel Address Identifier in the range. Note that this object is only 2 bytes." ::= { t11FamFcIdCacheEntry 2 } t11FamFcIdCachePortIds OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The combination of t11FamFcIdCacheAreaIdPortId and this object represent one range of Fibre Channel Address Identifiers, which were assigned and later released. This object contains the number of (consecutive) Fibre Channel Address Identifiers in the range." ::= { t11FamFcIdCacheEntry 3 } -- Objects for use in notifications t11FamNotifyFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "A unique index value that identifies a particular Fabric for which a particular notification is generated. In a Fabric conformant to SW-3, only a single Fabric can operate within a physical infrastructure, and thus, the value of this Fabric Index will always be 1. However, the current standard, FC-SW-4, defines how multiple Fabrics, each with its own management DeSanti, et al. Standards Track [Page 30] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 instrumentation, could operate within one (or more) physical infrastructures. In order to accommodate this scenario, this index value is used to uniquely identify a particular Fabric within a physical infrastructure." ::= { t11FamNotifyControl 1 } -- Notifications t11FamDomainIdNotAssignedNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11FamNotifyFabricIndex } STATUS current DESCRIPTION "This notification indicates that a Domain_ID has not been configured or assigned for a particular Fabric, identified by t11FamNotifyFabricIndex, on a particular switch identified by t11FamLocalSwitchWwn. This could happen under the following conditions, and results in the switch isolating E_Ports on the Fabric: - if the switch's request for a configured static Domain_ID is rejected or no other Domain_ID is assigned, then the E_Ports are isolated." ::= { t11FamNotifications 1 } t11FamNewPrincipalSwitchNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11FamNotifyFabricIndex } STATUS current DESCRIPTION "This notification indicates that a particular switch, identified by t11FamLocalSwitchWwn, has become the new Principal Switch on the Fabric identified by t11FamNotifyFabricIndex. This notification is sent soon after its election as the new Principal Switch, i.e., upon expiration of a Principal Switch selection timer that is equal to twice the Fabric Stability Timeout value (F_S_TOV)." ::= { t11FamNotifications 2 } t11FamFabricChangeNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11FamNotifyFabricIndex } STATUS current DESCRIPTION "This notification is sent whenever a particular switch, identified by t11FamLocalSwitchWwn, sends or receives a Build Fabric (BF) or a ReConfigure Fabric (RCF) message on the Fabric identified by DeSanti, et al. Standards Track [Page 31] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamNotifyFabricIndex. This notification is not sent if a 't11FamNewPrincipalSwitchNotify' notification is sent for the same event." ::= { t11FamNotifications 3 } -- -- Conformance -- t11FamMIBCompliances OBJECT IDENTIFIER ::= { t11FamMIBConformance 1 } t11FamMIBGroups OBJECT IDENTIFIER ::= { t11FamMIBConformance 2 } t11FamMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for Fibre Channel switches that implement Fabric Address Manager functionality." MODULE MANDATORY-GROUPS { t11FamGroup, t11FamDatabaseGroup, t11FamAreaGroup, t11FamNotificationGroup } OBJECT t11FamConfigDomainId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FamConfigDomainIdType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FamAutoReconfigure MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FamContiguousAllocation MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FamPriority DeSanti, et al. Standards Track [Page 32] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FamIfRcfReject MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FamIfRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FamRcFabricNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP t11FamCacheGroup DESCRIPTION "This group is mandatory only for switches that support the concept of Preferred Domain_ID via a best- effort attempt for (short-term) re-assignment of the same FC address identifiers." GROUP t11FamCommandGroup DESCRIPTION "This group is optional." ::= { t11FamMIBCompliances 1 } -- Units of Conformance t11FamGroup OBJECT-GROUP OBJECTS { t11FamConfigDomainId, t11FamConfigDomainIdType, t11FamAutoReconfigure, t11FamContiguousAllocation, t11FamPriority, t11FamPrincipalSwitchWwn, t11FamLocalSwitchWwn, t11FamAssignedAreaIdList, t11FamGrantedFcIds, t11FamRecoveredFcIds, t11FamFreeFcIds, t11FamAssignedFcIds, DeSanti, et al. Standards Track [Page 33] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamAvailableFcIds, t11FamRunningPriority, t11FamPrincSwRunningPriority, t11FamState, t11FamLocalPrincipalSwitchSlctns, t11FamPrincipalSwitchSelections, t11FamBuildFabrics, t11FamFabricReconfigures, t11FamDomainId, t11FamSticky, t11FamRestart, t11FamRcFabricNotifyEnable, t11FamEnable, t11FamFabricName, t11FamIfRcfReject, t11FamIfRole, t11FamIfRowStatus, t11FamNotifyFabricIndex } STATUS current DESCRIPTION "A collection of general objects for displaying and configuring Fabric Address management." ::= { t11FamMIBGroups 1 } t11FamCommandGroup OBJECT-GROUP OBJECTS { t11FamRestart } STATUS current DESCRIPTION "A collection of objects used for initiating an operation on the Fabric." ::= { t11FamMIBGroups 2 } t11FamDatabaseGroup OBJECT-GROUP OBJECTS { t11FamDatabaseSwitchWwn } STATUS current DESCRIPTION "A collection of objects containing information about Domain-IDs assignments." ::= { t11FamMIBGroups 3 } t11FamAreaGroup OBJECT-GROUP OBJECTS { t11FamAreaAssignedPortIdList } STATUS current DESCRIPTION "A collection of objects containing information about currently assigned addresses within a domain." ::= { t11FamMIBGroups 4 } DeSanti, et al. Standards Track [Page 34] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamCacheGroup OBJECT-GROUP OBJECTS { t11FamMaxFcIdCacheSize, t11FamFcIdCacheAreaIdPortId, t11FamFcIdCachePortIds } STATUS current DESCRIPTION "A collection of objects containing information about recently-released Fibre Channel Address Identifiers." ::= { t11FamMIBGroups 5 } t11FamNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FamDomainIdNotAssignedNotify, t11FamNewPrincipalSwitchNotify, t11FamFabricChangeNotify } STATUS current DESCRIPTION "A collection of notifications for status monitoring and notification." ::= { t11FamMIBGroups 6 } END 7. Acknowledgements This document began life as a work item of the INCITS Task Group T11.5. We wish to acknowledge the many contributions and comments from the INCITS Technical Committee T11, including the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 members, especially: Ken Hirata, Emulex Scott Kipp, McData Michael O'Donnell, McData Elizabeth G. Rodriguez, Dot Hill Steven L. Wilson, Brocade Thanks also to Orly Nicklass of RAD Data Communications, Bert Wijnen of Lucent, and those members of the IMSS WG who provided review comments. DeSanti, et al. Standards Track [Page 35] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 8. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [FC-MGMT] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [FC-SW-3] "Fibre Channel - Switch Fabric - 3 (FC-SW-3)", ANSI INCITS 384-2004, June 2004. [FC-SW-4] "Fibre Channel - Switch Fabric - 4 (FC-SW-4)", ANSI INCITS 418-2006, 2006. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)" ANSI INCITS 373-2003, April 2003. 9. Informative References [RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [FC-MI] "Fibre Channel - Methodologies for Interconnects (FC-MI)", INCITS TR-30-2002, November 2002. DeSanti, et al. Standards Track [Page 36] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 10. IANA Considerations IANA has made two MIB OID assignments, one for the T11-TC-MIB module and one for the T11-FC-FABRIC-ADDR-MGR-MIB module, under the appropriate subtree(s). 11. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: t11FamConfigDomainId, t11FamConfigDomainIdType and t11FamContiguousAllocation -- ability to change the address allocation policy. t11FamRestart and t11FamAutoReconfigure -- ability to cause a fabric reconfiguration, e.g., on certain error conditions. t11FamPriority -- ability to affect which switch becomes the Principal Switch. t11FamRcFabricNotifyEnable -- ability to enable/disable a notification. t11FamIfRcfReject -- ability to change the switch's behavior on receipt of an RCF. t11FamIfRowStatus -- ability to change an interface configuration parameter. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may also be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: t11FamTable and t11FamIfTable -- contain the configuration, status, and statistics of the Fabric Address Manager. DeSanti, et al. Standards Track [Page 37] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 t11FamAreaTable, t11FamDatabaseTable and t11FamFcIdCacheTable -- contain information on currently assigned or recently- released addresses. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. DeSanti, et al. Standards Track [Page 38] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Vinay Gaonkar Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 527-8576 EMail: vgaonkar@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com Silvano Gai Retired DeSanti, et al. Standards Track [Page 39] RFC 4439 Fibre Channel Fabric Address Manager MIB March 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). DeSanti, et al. Standards Track [Page 40] snmp-mibs-downloader-1.1/mibrfcs/rfc4444.txt0000644000000000000000000054332011402176072015571 0ustar Network Working Group J. Parker, Ed. Request for Comments: 4444 Axiowave Networks Category: Standards Track April 2006 Management Information Base for Intermediate System to Intermediate System (IS-IS) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Definition of IS-IS MIB. . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 96 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 96 8. Normative References . . . . . . . . . . . . . . . . . . . . . 101 9. Informative References . . . . . . . . . . . . . . . . . . . . 102 Parker Standards Track [Page 1] RFC 4444 IS-IS MIB April 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This document describes a management information base for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589 [ISO10589], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. The objects are mainly derived from the Guidelines for Definition of Managed Objects (GDMO) definitions in ISO 10589 and from the GDMO definitions in ISO 10733 [ISO10733]. There are also additional objects for managing the IP-specific functionality of Integrated IS- IS operation. This MIB imports definitions from SNMPv2-TC [RFC2579], SNMPv2-SMI [RFC2578], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411], DIFFSERV-MIB [RFC3289], IF-MIB [RFC2863], and INET-ADDRESS-MIB [RFC4001]. See the imports section of the MIB for the specific items imported. This MIB defines some objects to manage Mesh Groups, described in [RFC2973], and a three-way handshake for point-to-point adjacencies, described in [RFC3373]. The IS-IS MIB defines the following objects: System-Wide Attributes - isisSystem This table contains information specific to a single instance of the IS-IS protocol running on a router. Parker Standards Track [Page 2] RFC 4444 IS-IS MIB April 2006 - isisManAreaAddr This table includes area addresses that are manually configured, which are used to control the associations formed between Level 1 Intermediate Systems. - isisAreaAddr This table includes area addresses reported in relevant L1 LSPs. - isisSummAddr This table holds summary addresses configured for each Level 2 instance of the IS-IS protocol running on a router. - isisRedistributeAddr This table provides criteria to decide whether a route should be leaked from L2 to L1 when Domain Wide Prefix leaking is enabled. - isisRouter This table holds the hostname and router ID for Intermediate Systems in the network. - isisSysLevel This table contains information specific to a domain (Level 2) or an area (Level 1) of the IS-IS protocol. - isisNextCircIndex This scalar is used to provide a unique circuit index. Circuit-specific Attributes - isisCirc This table contains information specific to a point-to-point or a broadcast interface in the system. - isisCircLevel This table contains information specific to Level 1 or Level 2 of an interface. Parker Standards Track [Page 3] RFC 4444 IS-IS MIB April 2006 Counters - isisSystemCounter Counters in the System table, such as number of times we have wrapped a sequence counter on one of our Link State PDUs. - isisCircuitCounter Counters of events particular to a circuit, such as PDUs with an illegal value of the System ID field length. - isisPacketCounter Counts of IS-IS Protocol PDUs broken down into packet type. Attributes associated with an Adjacency - isisISAdj This table contains information about adjacencies to routers maintained by the protocol. Entries in this table cannot be created by management action: they are established through the Hello protocol. - isisISAdjAreaAddr This table contains the set of Area Addresses of neighboring Intermediate Systems, as reported in IIH PDUs. - isisISAdjIPAddr This table contains the set of IP Addresses of neighboring Intermediate Systems, as reported in received IIH PDUs. - isisISAdjProtSupp This table contains the set of protocols supported by neighboring Intermediate Systems, as reported in received IIH PDUs. Parker Standards Track [Page 4] RFC 4444 IS-IS MIB April 2006 Attributes Associated with Addresses - isisRA The Reachable Address Table. This table contains information about an address prefix manually configured on the system or learned through another protocol. - isisIPRA The IP Reachable Address Table. This table contains information about an IP reachable address manually configured on this system or learned from another protocol. Attributes Associated with Link State PDU Table - isisLSPSummaryTable The Link State PDU Summary Table. This table contains information contained in the headers of Link State PDUs stored by the system. - isisLSPTLVTable The Link State PDU TLV Table. This table holds the sequence of TLVs that make up an LSP fragment. Attributes Associated with a Notification - isisNotification This table defines attributes that will be included when reporting IS-IS notifications. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Parker Standards Track [Page 5] RFC 4444 IS-IS MIB April 2006 4. Definition of IS-IS MIB ISIS-MIB DEFINITIONS ::= BEGIN IMPORTS TEXTUAL-CONVENTION, RowStatus, TruthValue, TimeStamp FROM SNMPv2-TC -- RFC2579 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32, mib-2 FROM SNMPv2-SMI -- RFC2578 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC2571 IndexInteger, IndexIntegerNextFree FROM DIFFSERV-MIB -- RFC3289 InterfaceIndex FROM IF-MIB -- RFC2863 InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB; -- RFC3291 isisMIB MODULE-IDENTITY LAST-UPDATED "200604040000Z" -- April 4, 2006, midnight ORGANIZATION "IETF IS-IS for IP Internets Working Group" CONTACT-INFO "IS-IS for IP Internets working Group http://www.ietf.org/html.charters/isis-charter.html isis-wg@ietf.org Jeff Parker Department of Computer Science Middlebury College, Middlebury, Vermont 05753 jeffp at middlbury dot edu" DESCRIPTION "This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589, when it is used to construct routing tables for IP networks, as described in RFC 1195. This document is based on a 1994 IETF document by Chris Gunner. This version has been modified to include current syntax, to exclude portions of the protocol that are not relevant to IP, and to add management support for current practice. Parker Standards Track [Page 6] RFC 4444 IS-IS MIB April 2006 Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4444; see the RFC itself for full legal notices." REVISION "200604040000Z" -- April 4, 2006, midnight DESCRIPTION "Initial version, published as RFC 4444." ::= { mib-2 138 } -- Top-level structure of the MIB isisNotifications OBJECT IDENTIFIER ::= { isisMIB 0 } isisObjects OBJECT IDENTIFIER ::= { isisMIB 1 } isisConformance OBJECT IDENTIFIER ::= { isisMIB 2 } -- OBJECT IDENTIFIER definitions -- System wide attributes. isisSystem OBJECT IDENTIFIER ::= { isisObjects 1 } -- Attributes associated with the domain or with the area. isisSysLevel OBJECT IDENTIFIER ::= { isisObjects 2 } -- Attributes associated with one Circuit isisCirc OBJECT IDENTIFIER ::= { isisObjects 3 } -- Attributes associated with area or domain relevant within a Circuit. isisCircLevelValues OBJECT IDENTIFIER ::= { isisObjects 4 } -- System and circuit counters. isisCounters OBJECT IDENTIFIER ::= { isisObjects 5 } -- Attributes associated with an adjacent Protocol Peer. isisISAdj OBJECT IDENTIFIER ::= { isisObjects 6 } -- Attributes associated with a configured address. isisReachAddr OBJECT IDENTIFIER ::= { isisObjects 7 } -- Attributes associated with IP routes learned by -- configuration or through another protocol. isisIPReachAddr OBJECT IDENTIFIER ::= { isisObjects 8 } -- The collection of Link State PDUs known to the Intermediate System isisLSPDataBase OBJECT IDENTIFIER ::= { isisObjects 9 } -- Objects included in Notifications. isisNotification OBJECT IDENTIFIER ::= { isisObjects 10 } Parker Standards Track [Page 7] RFC 4444 IS-IS MIB April 2006 -- Type definitions IsisOSINSAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "OSI Network Service Address, e.g., NSAP, SNPA, or Network Entity Title" SYNTAX OCTET STRING (SIZE(0..20)) IsisSystemID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ID for an Intermediate System. This should be unique within a network, and is included in all PDUs originated by an Intermediate System. The protocol does not place any meanings upon the bits, other than using ordering to break ties in electing a Designated IS on a LAN." REFERENCE "{ISIS.aoi systemId (119)}" SYNTAX OCTET STRING (SIZE(6)) IsisLinkStatePDUID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The 8-byte Link State PDU (LSP) ID, consisting of the 6-byte SystemID of the originating IS; a one-byte PseudoNode ID, which is 0 unless the LSP represents the topology of a LAN; and a one-byte LSP fragment number that is issued in sequence, starting with 0. Non-zero PseudoNode IDs need to be unique to the IS but need not match the IfIndex." REFERENCE "{See section 9.8 of ISO 10589}" SYNTAX OCTET STRING (SIZE(8)) IsisAdminState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Type used in enabling and disabling a row." SYNTAX INTEGER { on(1), off(2) } IsisLSPBuffSize ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" Parker Standards Track [Page 8] RFC 4444 IS-IS MIB April 2006 STATUS current DESCRIPTION "Integer sub-range for maximum LSP size." SYNTAX Unsigned32 (512..16000) IsisLevelState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "States of the IS-IS protocol." SYNTAX INTEGER { off (1), on (2), waiting (3), overloaded(4) } IsisSupportedProtocol ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Types of network protocol supported by Integrated IS-IS. The values for ISO8473 and IP are those registered for these protocols in ISO TR9577." REFERENCE "{See section 5.3.1 of RFC 1195}" SYNTAX INTEGER { iso8473(129), ipV6(142), ip(204) } IsisDefaultMetric ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Integer sub-range for default metric for single hop. ISO 10589 provides for 4 types of metric. Only the 'default' metric is used in practice." REFERENCE "{See section 7.2.2 of ISO 10589}" SYNTAX Unsigned32 (0..63) IsisWideMetric ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Wide metric for IS Neighbors. ISO 10589 provides a 6-bit metric. Traffic Engineering extensions provide 24-bit metrics." Parker Standards Track [Page 9] RFC 4444 IS-IS MIB April 2006 REFERENCE "{See section 3 of RFC 3784}" SYNTAX Unsigned32 (0..16777215) IsisFullMetric ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Full metric for IP Routes. Traffic Engineering extensions provide 32-bit metrics." REFERENCE "{See section 4 of RFC 3784}" SYNTAX Unsigned32 IsisMetricType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Is this an Internal or External Metric?" REFERENCE "{See section 7.2.2 of ISO 10589}" SYNTAX INTEGER { internal(1), external(2) } IsisMetricStyle ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Do we use RFC 1195 style metrics or wide metrics?" REFERENCE "{See section 5 of RFC 3787}" SYNTAX INTEGER { narrow(1), wide(2), both(3) } IsisISLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a level." REFERENCE "{See definitions 3.6.1 and 3.6.11 of ISO 10589}" SYNTAX INTEGER { area(1), -- L1 domain(2) -- L2 } IsisLevel ::= TEXTUAL-CONVENTION STATUS current Parker Standards Track [Page 10] RFC 4444 IS-IS MIB April 2006 DESCRIPTION "Identifies one or more levels." REFERENCE "{See definitions 3.6.1 and 3.6.11 of ISO 10589}" SYNTAX INTEGER { level1(1), level2(2), level1and2(3) } IsisPDUHeader ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A block to contain the header from a PDU." SYNTAX OCTET STRING (SIZE(0..64)) IsisCircuitID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ID for a circuit." REFERENCE "{See section 7.2.7 of ISO 10589}" SYNTAX OCTET STRING (SIZE(0|7)) IsisISPriority ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Integer sub-range for IS-IS priority." REFERENCE "{See section 9.5 of ISO 10589}" SYNTAX Unsigned32 (0..127) IsisUnsigned16TC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An Unsigned32 further restricted to 16 bits. Note that the ASN.1 BER encoding may still require 24 bits for some values." SYNTAX Unsigned32 (0..65535) IsisUnsigned8TC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An Unsigned32 further restricted to 8 bits. Note that the ASN.1 BER encoding may still require 16 bits for some values." SYNTAX Unsigned32 (0..255) Parker Standards Track [Page 11] RFC 4444 IS-IS MIB April 2006 -- Behavior Definitions -- ResettingTimer behavior definition -- -- "This behavior applies to objects that specify the interval -- between events in the operation of the protocol state machine. -- If the value of such an object is set to a new value while -- the protocol state machine is in operation, the implementation -- shall take the necessary steps to ensure that for any time -- interval that was in progress when the value of the -- corresponding object was changed, the next expiration of that -- interval takes place the specified time after the original -- start of that interval, or immediately, whichever is later. -- The precision with which this time shall be implemented shall -- be the same as that associated with the basic operation of -- the timer object." -- ReplaceOnlyWhileDisabled behavior definition -- "This behavior applies to objects that may not be modified -- while the corresponding table row's variable of type -- IsisAdminState is in state on." -- ManualOrAutomatic behavior definition -- "This behavior applies to objects that are read-write -- if the object was created manually. Objects that were -- created automatically that have this behavior are -- read-only. isisSysObject OBJECT IDENTIFIER ::= { isisSystem 1 } isisSysVersion OBJECT-TYPE SYNTAX INTEGER { unknown(0), one(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the IS-IS protocol that is implemented." REFERENCE "{ISIS.aoi version (1)}" DEFVAL { one } ::= { isisSysObject 1 } isisSysLevelType OBJECT-TYPE SYNTAX IsisLevel Parker Standards Track [Page 12] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS read-write STATUS current DESCRIPTION "At which levels is the Intermediate System running? This object may not be modified when the isisSysAdminState variable is in state 'on' for this Intermediate System. Configured values MUST survive an agent reboot." REFERENCE "{ISIS.aoi iSType (2)}" DEFVAL { level1and2 } ::= { isisSysObject 2 } isisSysID OBJECT-TYPE SYNTAX IsisSystemID MAX-ACCESS read-write STATUS current DESCRIPTION "The ID for this Intermediate System. This value is appended to each of the area addresses to form the Network Entity Titles. The derivation of a value for this object is implementation specific. Some implementations may automatically assign values and not permit an SNMP write, while others may require the value to be set manually. Configured values MUST survive an agent reboot." REFERENCE "{ISIS.aoi systemId (119)}" ::= { isisSysObject 3 } isisSysMaxPathSplits OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum number of paths with equal routing metric value which it is permitted to split between. This object may not be modified when the isisSysAdminState variable is in state 'on' for this Intermediate System. Configured values MUST survive an agent reboot." REFERENCE "{ISIS.aoi maximumPathSplits (3)}" DEFVAL { 2 } ::= { isisSysObject 4 } isisSysMaxLSPGenInt OBJECT-TYPE SYNTAX Unsigned32 (1..65235) Parker Standards Track [Page 13] RFC 4444 IS-IS MIB April 2006 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum interval, in seconds, between generated LSPs by this Intermediate System. This object follows the ResettingTimer behavior. The value must be greater than any value configured for isisSysLevelMinLSPGenInt, and should be at least 300 seconds less than isisSysMaxAge. Configured values MUST survive an agent reboot." REFERENCE "{ISIS.aoi maximumLSPGenerationInterval (6)}" DEFVAL { 900 } ::= { isisSysObject 5 } isisSysPollESHelloRate OBJECT-TYPE SYNTAX IsisUnsigned16TC (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value, in seconds, to be used for the suggested ES configuration timer in ISH PDUs when soliciting the ES configuration. Configured values MUST survive an agent reboot." REFERENCE "{ISIS.aoi pollESHelloRate (13)}" DEFVAL { 50 } ::= { isisSysObject 6 } isisSysWaitTime OBJECT-TYPE SYNTAX IsisUnsigned16TC (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Number of seconds to delay in state 'waiting' before entering the state 'on'. This object follows the ResettingTimer behavior. Configured values MUST survive an agent reboot." REFERENCE "{ISIS.aoi waitingTime (15)}" DEFVAL { 60 } ::= { isisSysObject 7 } isisSysAdminState OBJECT-TYPE SYNTAX IsisAdminState Parker Standards Track [Page 14] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative state of this Intermediate System. Setting this object to the value 'on' when its current value is 'off' enables the Intermediate System. Configured values MUST survive an agent reboot." DEFVAL { off } ::= { isisSysObject 8 } isisSysL2toL1Leaking OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true, allow the router to leak L2 routes into L1. Configured values MUST survive an agent reboot." DEFVAL { false } ::= { isisSysObject 9 } isisSysMaxAge OBJECT-TYPE SYNTAX IsisUnsigned16TC (350..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Value to place in RemainingLifeTime field of the LSPs we generate. This should be at least 300 seconds greater than isisSysMaxLSPGenInt. Configured values MUST survive an agent reboot." DEFVAL { 1200 } ::= { isisSysObject 10 } isisSysReceiveLSPBufferSize OBJECT-TYPE SYNTAX IsisUnsigned16TC (1492..16000) UNITS "bytes" MAX-ACCESS read-write STATUS current DESCRIPTION "Size of the largest buffer we are designed or configured to store. This should be at least as big as the maximum isisSysLevelOrigLSPBuffSize supported by the system. Parker Standards Track [Page 15] RFC 4444 IS-IS MIB April 2006 If resources allow, we will store and flood LSPs larger than isisSysReceiveLSPBufferSize, as this can help avoid problems in networks with different values for isisSysLevelOrigLSPBuffSize. Configured values MUST survive an agent reboot." DEFVAL { 1492 } ::= { isisSysObject 11 } isisSysProtSupported OBJECT-TYPE SYNTAX BITS { iso8473 (0), ipv4 (1), ipv6 (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the set of protocols supported by this Intermediate System." ::= { isisSysObject 12 } isisSysNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is set to true(1), then it enables the emission of IS-IS Notifications. If it is set to false(2), these notifications are not sent. Configured values MUST survive an agent reboot." DEFVAL { true } ::= { isisSysObject 13 } -- The Level 1 Manual Area Address Table isisManAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of manual area addresses configured on this Intermediate System. At least one row in which the value of isisManAreaAddrExistState is active must be present. The maximum number of rows in this table for Parker Standards Track [Page 16] RFC 4444 IS-IS MIB April 2006 which the object isisManAreaAddrExistState has the value active is 3. An attempt to create more than 3 rows of isisManAreaAddrEntry with state 'active' in one instance of the IS-IS protocol should return inconsistentValue." REFERENCE "{ISIS.aoi manualAreaAddresses (10)}" ::= { isisSystem 2 } isisManAreaAddrEntry OBJECT-TYPE SYNTAX IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address manually configured on this system. Dynamically created rows MUST survive an agent reboot." INDEX { isisManAreaAddr } ::= { isisManAreaAddrTable 1 } IsisManAreaAddrEntry ::= SEQUENCE { isisManAreaAddr IsisOSINSAddress, isisManAreaAddrExistState RowStatus } isisManAreaAddr OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "A manually configured area address for this system. Note: An index for the entry {1, {49.0001} active} in this table would be the ordered pair (1, (0x03 0x49 0x00 0x01)), as the length of an octet string is part of the OID." ::= { isisManAreaAddrEntry 1 } isisManAreaAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Parker Standards Track [Page 17] RFC 4444 IS-IS MIB April 2006 "The state of the isisManAreaAddrEntry. If the isisSysAdminState for this Intermediate System is 'on' and an attempt is made to set this object to the value 'destroy' or 'notInService' when this is the only isisManAreaAddrEntry in state 'active' for this Intermediate System should return inconsistentValue. A row entry cannot be modified when the value of this object is 'active'." ::= { isisManAreaAddrEntry 2 } -- The Level 1 Area Address Table -- The Level 1 Area Address Table contains the -- union of the sets of relevant area addresses configured -- or learned from Level 1 LSPs received by this Intermediate System. isisAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The union of the sets of area addresses reported in all Level 1 LSPs with fragment number zero generated by this Intermediate System, or received from other Intermediate Systems that are reachable via Level 1 routing." REFERENCE "{ISIS.aoi areaAddresses (18)}" ::= { isisSystem 3 } isisAreaAddrEntry OBJECT-TYPE SYNTAX IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address reported in a Level 1 LSP generated or received by this Intermediate System. Dynamically learned rows do not survive an agent reboot." INDEX { isisAreaAddr } ::= { isisAreaAddrTable 1 } IsisAreaAddrEntry ::= SEQUENCE { isisAreaAddr IsisOSINSAddress } Parker Standards Track [Page 18] RFC 4444 IS-IS MIB April 2006 isisAreaAddr OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An area address reported in a Level 1 LSP." ::= { isisAreaAddrEntry 1 } -- The Summary Address Table -- The Summary Address Table contains the set of summary -- addresses manually configured for the Intermediate System. -- -- This is used to control leaking L1 routes into L2. isisSummAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSummAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of IP summary addresses to use in forming summary TLVs originated by this Intermediate System. An administrator may use a summary address to combine and modify IP Reachability announcements. If the Intermediate system can reach any subset of the summary address, the summary address MUST be announced instead, at the configured metric." ::= { isisSystem 4 } isisSummAddrEntry OBJECT-TYPE SYNTAX IsisSummAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP summary address. Dynamically created rows MUST survive an agent reboot. Implementers need to be aware that if the total number of elements (octets or sub-identifiers) in isisSummAddress and isisSummAddrPrefixLen is too great, then OIDs of column instances in this table will have more than 128 subidentifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { isisSummAddressType, isisSummAddress, isisSummAddrPrefixLen } Parker Standards Track [Page 19] RFC 4444 IS-IS MIB April 2006 ::= { isisSummAddrTable 1 } IsisSummAddrEntry ::= SEQUENCE { isisSummAddressType InetAddressType, isisSummAddress InetAddress, isisSummAddrPrefixLen InetAddressPrefixLength, isisSummAddrExistState RowStatus, isisSummAddrMetric IsisDefaultMetric, isisSummAddrFullMetric IsisFullMetric } isisSummAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Type of IP address for this summary address." ::= { isisSummAddrEntry 1 } isisSummAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP Address value for this summary address. The address must not contain any set host bits (bits set after the address prefix determined by isisSummAddrPrefixLen). The type of this address is determined by the value of the isisSummAddressType object." ::= { isisSummAddrEntry 2 } isisSummAddrPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Length of the IP NetMask for this summary address. The values for the index objects isisSummAddress and Parker Standards Track [Page 20] RFC 4444 IS-IS MIB April 2006 isisSummAddrPrefixLen must be consistent. When the value of isisSummAddress (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object isisSummAddrPrefixLen MUST be equal to x. If not, then the index pair is not consistent, and an inconsistentName error must be returned on SET or CREATE requests." ::= { isisSummAddrEntry 3 } isisSummAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this summary address. Support for 'createAndWait' and 'notInService' is not required. A row entry cannot be modified when the value of this object is 'active'." ::= { isisSummAddrEntry 4 } isisSummAddrMetric OBJECT-TYPE SYNTAX IsisDefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric value to announce this summary address within LSPs generated by this system." DEFVAL { 20 } ::= { isisSummAddrEntry 5 } isisSummAddrFullMetric OBJECT-TYPE SYNTAX IsisFullMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The wide metric value to announce this summary address within LSPs generated by this system." DEFVAL { 20 } ::= { isisSummAddrEntry 6 } -- The Redistribution table defines addresses that should be -- leaked from L2 to L1 if isisSysL2toL1Leaking is enabled. isisRedistributeAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRedistributeAddrEntry MAX-ACCESS not-accessible Parker Standards Track [Page 21] RFC 4444 IS-IS MIB April 2006 STATUS current DESCRIPTION "This table provides criteria to decide if a route should be leaked from L2 to L1 when Domain Wide Prefix leaking is enabled. Addresses that match the summary mask in the table MUST be announced at L1 by routers when isisSysL2toL1Leaking is enabled. Routes that fall into the ranges specified are announced as is, without being summarized. Routes that do not match a summary mask are not announced." ::= { isisSystem 5 } isisRedistributeAddrEntry OBJECT-TYPE SYNTAX IsisRedistributeAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one configured IP summary address to manage leaking L2 addresses into L1. Dynamically created rows MUST survive an agent reboot. Implementers need to be aware that if the total number of elements (octets or sub-identifiers) in isisRedistributeAddrAddress and isisRedistributeAddrPrefixLen is too great, then OIDs of column instances in this table will have more than 128 subidentifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { isisRedistributeAddrType, isisRedistributeAddrAddress, isisRedistributeAddrPrefixLen } ::= { isisRedistributeAddrTable 1 } IsisRedistributeAddrEntry ::= SEQUENCE { isisRedistributeAddrType InetAddressType, isisRedistributeAddrAddress InetAddress, isisRedistributeAddrPrefixLen InetAddressPrefixLength, isisRedistributeAddrExistState RowStatus } isisRedistributeAddrType OBJECT-TYPE Parker Standards Track [Page 22] RFC 4444 IS-IS MIB April 2006 SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Type of IP address for this summary address." ::= { isisRedistributeAddrEntry 1 } isisRedistributeAddrAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP Address value for this summary address. The type of this address is determined by the value of the isisRedistributeAddrType object. The address must not contain any set host bits - bits set after the address prefix determined by isisRedistributeAddrPrefixLen." ::= { isisRedistributeAddrEntry 2 } isisRedistributeAddrPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Length of the IP NetMask for this summary address. The values for the index objects isisRedistributeAddrAddress and isisRedistributeAddrPrefixLen must be consistent. When the value of isisRedistributeAddrAddress (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object isisRedistributeAddrPrefixLen MUST be equal to x. If not, then the index pair is not consistent, and an inconsistentName error must be returned on SET or CREATE requests." ::= { isisRedistributeAddrEntry 3 } isisRedistributeAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this summary address. Support Parker Standards Track [Page 23] RFC 4444 IS-IS MIB April 2006 for createAndWait and notInService is not required. A row entry cannot be modified when the value of this object is 'active'." ::= { isisRedistributeAddrEntry 4 } -- The Router Table keeps track of hostnames and router IDs -- associated with Intermediate Systems in the area and domain. isisRouterTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRouterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of hostnames and router ID." ::= { isisSystem 6 } isisRouterEntry OBJECT-TYPE SYNTAX IsisRouterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry tracks information about one Intermediate System at one level. Dynamically learned rows do not survive an agent reboot." INDEX { isisRouterSysID, isisRouterLevel } ::= { isisRouterTable 1 } IsisRouterEntry ::= SEQUENCE { isisRouterSysID IsisSystemID, isisRouterLevel IsisISLevel, isisRouterHostName SnmpAdminString, isisRouterID Unsigned32 } isisRouterSysID OBJECT-TYPE SYNTAX IsisSystemID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The System ID of the Intermediate System." Parker Standards Track [Page 24] RFC 4444 IS-IS MIB April 2006 ::= { isisRouterEntry 1 } isisRouterLevel OBJECT-TYPE SYNTAX IsisISLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level at which the information about this Intermediate System was received." ::= { isisRouterEntry 2 } isisRouterHostName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The hostname listed in the LSP, or a zero-length string if none." ::= { isisRouterEntry 3 } isisRouterID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID found in the LSP, or zero if none." ::= { isisRouterEntry 4 } -- The System Level Table -- This table captures level-specific information about the system isisSysLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSysLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Level specific information about the System." ::= { isisSysLevel 1 } isisSysLevelEntry OBJECT-TYPE SYNTAX IsisSysLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row describes variables configured for Area or Domain. Configured values MUST survive an agent reboot." INDEX { isisSysLevelIndex } Parker Standards Track [Page 25] RFC 4444 IS-IS MIB April 2006 ::= { isisSysLevelTable 1 } IsisSysLevelEntry ::= SEQUENCE { isisSysLevelIndex IsisISLevel, isisSysLevelOrigLSPBuffSize IsisLSPBuffSize, isisSysLevelMinLSPGenInt IsisUnsigned16TC, isisSysLevelState IsisLevelState, isisSysLevelSetOverload TruthValue, isisSysLevelSetOverloadUntil Unsigned32, isisSysLevelMetricStyle IsisMetricStyle, isisSysLevelSPFConsiders IsisMetricStyle, isisSysLevelTEEnabled TruthValue } isisSysLevelIndex OBJECT-TYPE SYNTAX IsisISLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level that this entry describes." ::= { isisSysLevelEntry 1 } isisSysLevelOrigLSPBuffSize OBJECT-TYPE SYNTAX IsisLSPBuffSize MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum size of LSPs and SNPs originated by this Intermediate System at this level. This object may not be modified when the isisSysAdminState variable is in state 'on' for this Intermediate System." REFERENCE "{ISIS.aoi originatingL1LSPBufferSize (9)}" DEFVAL { 1492 } ::= { isisSysLevelEntry 2 } isisSysLevelMinLSPGenInt OBJECT-TYPE SYNTAX IsisUnsigned16TC (1..65535) UNITS "seconds" Parker Standards Track [Page 26] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS read-write STATUS current DESCRIPTION "Minimum interval, in seconds, between successive generation of LSPs with the same LSPID at this level by this Intermediate System." REFERENCE "{ISIS.aoi minimumLSPGenerationInterval (11)}" DEFVAL { 30 } ::= { isisSysLevelEntry 3 } isisSysLevelState OBJECT-TYPE SYNTAX IsisLevelState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the database at this level. The value 'off' indicates that IS-IS is not active at this level. The value 'on' indicates that IS-IS is active at this level and is not overloaded. The value 'waiting' indicates a database that is low on an essential resource, such as memory. The administrator may force the state to 'overloaded' by setting the object isisSysLevelSetOverload. If the state is 'waiting' or 'overloaded', we originate LSPs with the overload bit set." REFERENCE "{ISIS.aoi l1State (17)}" ::= { isisSysLevelEntry 4 } isisSysLevelSetOverload OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Administratively set the overload bit for the level. The overload bit MUST continue to be set if the implementation runs out of memory, independent of this variable. It may also be set manually independent of this variable, using the isisSysLevelSetOverloadUntil object." DEFVAL { false } ::= { isisSysLevelEntry 5 } isisSysLevelSetOverloadUntil OBJECT-TYPE SYNTAX Unsigned32 UNITS "Seconds until clearing manually set Overload Bit" MAX-ACCESS read-write STATUS current Parker Standards Track [Page 27] RFC 4444 IS-IS MIB April 2006 DESCRIPTION "If this object is non-zero, the overload bit is set at this level when the isisSysAdminState variable goes to state 'on' for this Intermediate System. The overload bit remains set for isisSysLevelSetOverloadUntil seconds. When isisSysLevelSetOverloadUntil seconds have elapsed, the overload flag remains set if the implementation has run out of memory, or if it is set manually using the isisSysLevelSetOverload object. If isisSysLevelSetOverload is false, the system clears the overload bit when isisSysLevelSetOverloadUntil seconds have elapsed, if the system has not run out of memory." ::= { isisSysLevelEntry 6 } isisSysLevelMetricStyle OBJECT-TYPE SYNTAX IsisMetricStyle MAX-ACCESS read-write STATUS current DESCRIPTION "Which style of metric do we generate in our LSPs at this level?" DEFVAL { narrow } ::= { isisSysLevelEntry 7 } isisSysLevelSPFConsiders OBJECT-TYPE SYNTAX IsisMetricStyle MAX-ACCESS read-write STATUS current DESCRIPTION "Which style of metric do we consider in our SPF computation at this level?" DEFVAL { narrow } ::= { isisSysLevelEntry 8 } isisSysLevelTEEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Do we do Traffic Engineering at this level?" DEFVAL { false } ::= { isisSysLevelEntry 9 } -- Static to provide next CircIndex isisNextCircIndex OBJECT-TYPE SYNTAX IndexIntegerNextFree Parker Standards Track [Page 28] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to assist a management application in creating new rows in the isisCircTable. If it is possible to create a new instance of isisCircEntry, then this object will contain a non-zero value that is not in use as the index of any row in the isisCircTable. The network manager reads the value of this object and then (if the value read is non-zero) attempts to create the corresponding instance of isisCircEntry. If the set request fails with the code 'inconsistentValue', then the process must be repeated; if the set request succeeds, then the agent will change the value of this object according to an implementation-specific algorithm." ::= { isisCirc 1 } -- The Circuit Table -- Each broadcast or point-to-point interface on the system -- corresponds to one entry in the Circuit table. However, there -- may be multiple X.25 DA circuit entries in the Circuit table -- for a given X.25 interface. isisCircTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of circuits used by this Intermediate System." ::= { isisCirc 2 } isisCircEntry OBJECT-TYPE SYNTAX IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircEntry exists for each circuit configured for Integrated IS-IS on this system. Dynamically created rows MUST survive an agent reboot." INDEX { isisCircIndex } ::= { isisCircTable 1 } Parker Standards Track [Page 29] RFC 4444 IS-IS MIB April 2006 IsisCircEntry ::= SEQUENCE { isisCircIndex IndexInteger, isisCircIfIndex InterfaceIndex, isisCircAdminState IsisAdminState, isisCircExistState RowStatus, isisCircType INTEGER, isisCircExtDomain TruthValue, isisCircLevelType IsisLevel, isisCircPassiveCircuit TruthValue, isisCircMeshGroupEnabled INTEGER, isisCircMeshGroup Unsigned32, isisCircSmallHellos TruthValue, isisCircLastUpTime TimeStamp, isisCirc3WayEnabled TruthValue, isisCircExtendedCircID Unsigned32 } isisCircIndex OBJECT-TYPE SYNTAX IndexInteger MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index used to uniquely identify this circuit. When creating a row in this table, the isisNextCircIndex object should be retrieved, and its value should be specified as the value of this index using a SET operation. A retrieved value of zero(0) indicates that no rows can be created at this time." ::= { isisCircEntry 1 } isisCircIfIndex OBJECT-TYPE SYNTAX InterfaceIndex Parker Standards Track [Page 30] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The value of ifIndex for the interface to which this circuit corresponds. This object cannot be modified after creation." ::= { isisCircEntry 2 } isisCircAdminState OBJECT-TYPE SYNTAX IsisAdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the circuit." DEFVAL { off } ::= { isisCircEntry 3 } isisCircExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this circuit. Setting the state to 'notInService' halts the generation and processing of IS-IS protocol PDUs on this circuit. Setting the state to destroy will also erase any configuration associated with the circuit. Support for 'createAndWait' and 'notInService' is not required. A row entry cannot be modified when the value of this object is 'active'." ::= { isisCircEntry 4 } isisCircType OBJECT-TYPE SYNTAX INTEGER { broadcast(1), ptToPt(2), staticIn(3), staticOut(4), dA(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the circuit. This object follows the ReplaceOnlyWhileDisabled behavior. The type specified must be compatible with the type of the interface defined Parker Standards Track [Page 31] RFC 4444 IS-IS MIB April 2006 by the value of isisCircIfIndex." REFERENCE "{ISIS.aoi type (33)}" ::= { isisCircEntry 5 } isisCircExtDomain OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, suppress normal transmission of and interpretation of Intra-domain IS-IS PDUs on this circuit." REFERENCE "{ISIS.aoi externalDomain (46)}" DEFVAL { false } ::= { isisCircEntry 6 } isisCircLevelType OBJECT-TYPE SYNTAX IsisLevel MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates which type of packets will be sent and accepted on this circuit. The values set will be saved, but the values used will be modified by the settings of isisSysLevelType. Thus, if the isisSysTpe is level2 and the isisCircLevelType for a circuit is level1, the circuit will not send or receive IS-IS packets. This object follows the ReplaceOnlyWhileDisabled behavior." DEFVAL { level1and2 } ::= { isisCircEntry 7 } isisCircPassiveCircuit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Should we include this interface in LSPs, even if it is not running the IS-IS Protocol?" DEFVAL { false } ::= { isisCircEntry 8 } isisCircMeshGroupEnabled OBJECT-TYPE SYNTAX INTEGER { inactive(1), blocked(2), set(3) Parker Standards Track [Page 32] RFC 4444 IS-IS MIB April 2006 } MAX-ACCESS read-create STATUS current DESCRIPTION "Is this port a member of a mesh group, or is it blocked? Circuits in the same mesh group act as a virtual multiaccess network. LSPs seen on one circuit in a mesh group will not be flooded to another circuit in the same mesh group." REFERENCE "{ RFC 2973 }" DEFVAL { inactive } ::= { isisCircEntry 9 } isisCircMeshGroup OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Circuits in the same mesh group act as a virtual multiaccess network. LSPs seen on one circuit in a mesh group will not be flooded to another circuit in the same mesh group. If isisCircMeshGroupEnabled is inactive or blocked, this value is ignored." REFERENCE "{ RFC 2973 }" ::= { isisCircEntry 10 } isisCircSmallHellos OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Can we send unpadded hellos on LAN circuits? False means the LAN Hellos must be padded. Implementations should allow the administrator to read this value. An implementation need not be able to support unpadded hellos to be conformant." DEFVAL { false } ::= { isisCircEntry 11 } isisCircLastUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "How long the circuit has been enabled, measured in hundredths of seconds since the last re-initialization of the network management subsystem; 0 if the circuit has never been 'on'." Parker Standards Track [Page 33] RFC 4444 IS-IS MIB April 2006 ::= { isisCircEntry 12 } isisCirc3WayEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Is this circuit enabled to run 3Way handshake?" DEFVAL { true } ::= { isisCircEntry 13 } isisCircExtendedCircID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value to be used as the extended circuit ID in 3Way handshake. This value is only used if isisCirc3WayEnabled is true, and it must be unique across all circuits on this IS." ::= { isisCircEntry 14 } -- The Circuit Level Table -- This table captures level-specific information about a circuit isisCircLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Level specific information about circuits used by IS-IS." ::= { isisCircLevelValues 1 } isisCircLevelEntry OBJECT-TYPE SYNTAX IsisCircLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircLevelEntry exists for each level on each circuit configured for Integrated IS-IS on this system. Configured values MUST survive an agent reboot." INDEX { isisCircIndex, isisCircLevelIndex } ::= { isisCircLevelTable 1 } IsisCircLevelEntry ::= Parker Standards Track [Page 34] RFC 4444 IS-IS MIB April 2006 SEQUENCE { isisCircLevelIndex IsisISLevel, isisCircLevelMetric IsisDefaultMetric, isisCircLevelWideMetric IsisWideMetric, isisCircLevelISPriority IsisISPriority, isisCircLevelIDOctet Unsigned32, isisCircLevelID IsisCircuitID, isisCircLevelDesIS IsisCircuitID, isisCircLevelHelloMultiplier Unsigned32, isisCircLevelHelloTimer Unsigned32, isisCircLevelDRHelloTimer Unsigned32, isisCircLevelLSPThrottle IsisUnsigned16TC, isisCircLevelMinLSPRetransInt Unsigned32, isisCircLevelCSNPInterval Unsigned32, isisCircLevelPartSNPInterval Unsigned32 } isisCircLevelIndex OBJECT-TYPE SYNTAX IsisISLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level that this entry describes." ::= { isisCircLevelEntry 1 } isisCircLevelMetric OBJECT-TYPE SYNTAX IsisDefaultMetric MAX-ACCESS read-write STATUS current DESCRIPTION "The metric value of this circuit for this level." REFERENCE "{ISIS.aoi l1DefaultMetric (35)}" DEFVAL { 10 } ::= { isisCircLevelEntry 2 } Parker Standards Track [Page 35] RFC 4444 IS-IS MIB April 2006 isisCircLevelWideMetric OBJECT-TYPE SYNTAX IsisWideMetric MAX-ACCESS read-write STATUS current DESCRIPTION "The wide metric value of this circuit for this level." DEFVAL { 10 } ::= { isisCircLevelEntry 3 } isisCircLevelISPriority OBJECT-TYPE SYNTAX IsisISPriority MAX-ACCESS read-write STATUS current DESCRIPTION "The priority for becoming the LAN-Designated Intermediate System at this level." REFERENCE "{ISIS.aoi l2IntermediateSystemPriority (73)}" DEFVAL { 64 } ::= { isisCircLevelEntry 4 } isisCircLevelIDOctet OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "A one-byte identifier for the circuit selected by the Intermediate System. On point-to-point circuits, the value is used as the Local Circuit ID in point-to-point IIH PDUs transmitted on this circuit. In this case, values of isisCircLevelIDOctet do not need to be unique. For broadcast circuits, the value is used to generate the LAN ID that will be used if this Intermediate System is elected as the Designated IS on this circuit. The value is required to differ on LANs where the Intermediate System is the Designated Intermediate System." ::= { isisCircLevelEntry 5 } isisCircLevelID OBJECT-TYPE SYNTAX IsisCircuitID MAX-ACCESS read-only STATUS current DESCRIPTION "On a point-to-point circuit with a fully initialized adjacency to a peer IS, the value of this object is the circuit ID negotiated during adjacency initialization. Parker Standards Track [Page 36] RFC 4444 IS-IS MIB April 2006 On a point to point circuit without such an adjacency, the value is the concatenation of the local system ID and the one-byte isisCircLevelIDOctet for this circuit, i.e., the value that would be proposed for the circuit ID. On other circuit types, the value returned is the zero- length OCTET STRING." REFERENCE "{ISIS.aoi ptPtCircuitID (51)}" ::= { isisCircLevelEntry 6 } isisCircLevelDesIS OBJECT-TYPE SYNTAX IsisCircuitID MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the LAN-Designated Intermediate System on this circuit at this level. If, for any reason, this system is not partaking in the relevant Designated Intermediate System election process, then the value returned is the zero-length OCTET STRING." REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}" ::= { isisCircLevelEntry 7 } isisCircLevelHelloMultiplier OBJECT-TYPE SYNTAX Unsigned32 (2..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This value is multiplied by the corresponding HelloTimer, and the result in seconds (rounded up) is used as the holding time in transmitted hellos, to be used by receivers of hello packets from this IS." REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 10 } ::= { isisCircLevelEntry 8 } isisCircLevelHelloTimer OBJECT-TYPE SYNTAX Unsigned32 (10..600000) UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum period, in milliseconds, between IIH PDUs on multiaccess networks at this level for LANs. The value at L1 is used as the period between Hellos on L1L2 point-to-point circuits. Setting this value at level 2 on an L1L2 point-to-point circuit will result in an error of InconsistentValue. Parker Standards Track [Page 37] RFC 4444 IS-IS MIB April 2006 This object follows the ResettingTimer behavior." REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 3000 } ::= { isisCircLevelEntry 9 } isisCircLevelDRHelloTimer OBJECT-TYPE SYNTAX Unsigned32 (10..120000) UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Period, in milliseconds, between Hello PDUs on multiaccess networks when this IS is the Designated Intermediate System. This object follows the ResettingTimer behavior." REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 1000 } ::= { isisCircLevelEntry 10 } isisCircLevelLSPThrottle OBJECT-TYPE SYNTAX IsisUnsigned16TC (1..65535) UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Minimal interval of time, in milliseconds, between transmissions of LSPs on an interface at this level." REFERENCE "{ISIS.aoi minimumBroadcastLSPTransmissionInterval (5)}" DEFVAL { 30 } ::= { isisCircLevelEntry 11 } isisCircLevelMinLSPRetransInt OBJECT-TYPE SYNTAX Unsigned32 (1..300) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Minimum interval, in seconds, between re-transmission of an LSP at this level. This object follows the ResettingTimer behavior. Note that isisCircLevelLSPThrottle controls how fast we send back-to-back LSPs. This variable controls how fast we re-send the same LSP." REFERENCE "{ISIS.aoi minimumLSPTransmissionInterval (5)}" DEFVAL { 5 } ::= { isisCircLevelEntry 12 } Parker Standards Track [Page 38] RFC 4444 IS-IS MIB April 2006 isisCircLevelCSNPInterval OBJECT-TYPE SYNTAX Unsigned32 (1..600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Interval of time, in seconds, between periodic transmission of a complete set of CSNPs on multiaccess networks if this router is the designated router at this level. This object follows the ResettingTimer behavior." REFERENCE "{ISIS.aoi completeSNPInterval (8)}" DEFVAL { 10 } ::= { isisCircLevelEntry 13 } isisCircLevelPartSNPInterval OBJECT-TYPE SYNTAX Unsigned32 (1..120) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Minimum interval, in seconds, between sending Partial Sequence Number PDUs at this level. This object follows the ResettingTimer behavior." REFERENCE "{ISIS.aoi partialSNPInterval (14)}" DEFVAL { 2 } ::= { isisCircLevelEntry 14 } -- isisSystemCounterTable keeps track of system-wide events. isisSystemCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSystemCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "System-wide counters for this Intermediate System." ::= { isisCounters 1 } isisSystemCounterEntry OBJECT-TYPE SYNTAX IsisSystemCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "System-wide IS-IS counters." INDEX { isisSysStatLevel } ::= { isisSystemCounterTable 1 } IsisSystemCounterEntry ::= Parker Standards Track [Page 39] RFC 4444 IS-IS MIB April 2006 SEQUENCE { isisSysStatLevel IsisISLevel, isisSysStatCorrLSPs Counter32, isisSysStatAuthTypeFails Counter32, isisSysStatAuthFails Counter32, isisSysStatLSPDbaseOloads Counter32, isisSysStatManAddrDropFromAreas Counter32, isisSysStatAttmptToExMaxSeqNums Counter32, isisSysStatSeqNumSkips Counter32, isisSysStatOwnLSPPurges Counter32, isisSysStatIDFieldLenMismatches Counter32, isisSysStatPartChanges Counter32, isisSysStatSPFRuns Counter32, isisSysStatLSPErrors Counter32 } isisSysStatLevel OBJECT-TYPE SYNTAX IsisISLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level that this entry describes." ::= { isisSystemCounterEntry 1 } isisSysStatCorrLSPs OBJECT-TYPE SYNTAX Counter32 UNITS "Number of corrupted in-memory frames" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of corrupted in-memory LSPs detected. LSPs received from the wire with a bad checksum are silently dropped and are not counted. Parker Standards Track [Page 40] RFC 4444 IS-IS MIB April 2006 LSPs received from the wire with parse errors are counted by isisSysStatLSPErrors." REFERENCE "{ISIS.aoi corruptedLSPsDetected (19)}" ::= { isisSystemCounterEntry 2 } isisSysStatAuthTypeFails OBJECT-TYPE SYNTAX Counter32 UNITS "Number of frames with authentication type mismatches" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of authentication type mismatches recognized by this Intermediate System." ::= { isisSystemCounterEntry 3 } isisSysStatAuthFails OBJECT-TYPE SYNTAX Counter32 UNITS "Number of frames with authentication key failures" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of authentication key failures recognized by this Intermediate System." ::= { isisSystemCounterEntry 4 } isisSysStatLSPDbaseOloads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the LSP database has become overloaded." REFERENCE "{ISIS.aoi lSPL1DatabaseOverloads (20)}" ::= { isisSystemCounterEntry 5 } isisSysStatManAddrDropFromAreas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a manual address has been dropped from the area." REFERENCE "{ISIS.aoi manualAddressesDroppedFromArea (21)}" ::= { isisSystemCounterEntry 6 } isisSysStatAttmptToExMaxSeqNums OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Parker Standards Track [Page 41] RFC 4444 IS-IS MIB April 2006 STATUS current DESCRIPTION "Number of times the IS has attempted to exceed the maximum sequence number." REFERENCE "{ISIS.aoi attemptsToExceedmaximumSequenceNumber (22)}" ::= { isisSystemCounterEntry 7 } isisSysStatSeqNumSkips OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a sequence number skip has occurred." REFERENCE "{ISIS.aoi sequenceNumberSkips (23)}" ::= { isisSystemCounterEntry 8 } isisSysStatOwnLSPPurges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a zero-aged copy of the system's own LSP is received from some other node." REFERENCE "{ISIS.aoi ownLSPPurges (24)}" ::= { isisSystemCounterEntry 9 } isisSysStatIDFieldLenMismatches OBJECT-TYPE SYNTAX Counter32 UNITS "Number of frames with ID length mismatches" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a PDU is received with a different value for ID field length from that of the receiving system." REFERENCE "{ISIS.aoi iDFieldLengthMismatches (25)}" ::= { isisSystemCounterEntry 10 } isisSysStatPartChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Partition changes." ::= { isisSystemCounterEntry 11 } isisSysStatSPFRuns OBJECT-TYPE SYNTAX Counter32 Parker Standards Track [Page 42] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times we ran SPF at this level." ::= { isisSystemCounterEntry 12 } isisSysStatLSPErrors OBJECT-TYPE SYNTAX Counter32 UNITS "Number of frames with errors that we have received" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of LSPs with errors we have received." ::= { isisSystemCounterEntry 13 } -- isisCircuitCounterTable keeps track of events -- specific to a circuit and a level isisCircuitCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircuitCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Circuit specific counters for this Intermediate System." ::= { isisCounters 2 } isisCircuitCounterEntry OBJECT-TYPE SYNTAX IsisCircuitCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircuitCounterEntry exists for each circuit used by Integrated IS-IS on this system." INDEX { isisCircIndex, isisCircuitType } ::= { isisCircuitCounterTable 1 } IsisCircuitCounterEntry ::= SEQUENCE { isisCircuitType INTEGER, isisCircAdjChanges Counter32, isisCircNumAdj Unsigned32, isisCircInitFails Counter32, isisCircRejAdjs Parker Standards Track [Page 43] RFC 4444 IS-IS MIB April 2006 Counter32, isisCircIDFieldLenMismatches Counter32, isisCircMaxAreaAddrMismatches Counter32, isisCircAuthTypeFails Counter32, isisCircAuthFails Counter32, isisCircLANDesISChanges Counter32 } isisCircuitType OBJECT-TYPE SYNTAX INTEGER { lanlevel1(1), lanlevel2(2), p2pcircuit(3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "What type of circuit saw these counts? The point-to-point Hello PDU includes both L1 and L2, and ISs form a single adjacency on point-to-point links. Thus, we combine counts on point-to-point links into one group." ::= { isisCircuitCounterEntry 1 } isisCircAdjChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an adjacency state change has occurred on this circuit." REFERENCE "{ISIS.aoi changesInAdjacencyState (40)}" ::= { isisCircuitCounterEntry 2 } isisCircNumAdj OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of adjacencies on this circuit." Parker Standards Track [Page 44] RFC 4444 IS-IS MIB April 2006 REFERENCE "{ISIS.aoi changesInAdjacencyState (40)}" ::= { isisCircuitCounterEntry 3 } isisCircInitFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times initialization of this circuit has failed. This counts events such as PPP NCP failures. Failures to form an adjacency are counted by isisCircRejAdjs." ::= { isisCircuitCounterEntry 4 } isisCircRejAdjs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an adjacency has been rejected on this circuit." REFERENCE "{ISIS.aoi rejectedAdjacencies (42)}" ::= { isisCircuitCounterEntry 5 } isisCircIDFieldLenMismatches OBJECT-TYPE SYNTAX Counter32 UNITS "Number of frames with ID field length mismatch" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an IS-IS control PDU with an ID field length different from that for this system has been received." REFERENCE "{ISIS.aoi iDFieldLengthMismatches (25)}" ::= { isisCircuitCounterEntry 6 } isisCircMaxAreaAddrMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an IS-IS control PDU with a max area address field different from that for this system has been received." REFERENCE "{ISIS.aoi iDFieldLengthMismatches (25)}" ::= { isisCircuitCounterEntry 7 } isisCircAuthTypeFails OBJECT-TYPE Parker Standards Track [Page 45] RFC 4444 IS-IS MIB April 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an IS-IS control PDU with an auth type field different from that for this system has been received." ::= { isisCircuitCounterEntry 8 } isisCircAuthFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an IS-IS control PDU with the correct auth type has failed to pass authentication validation." ::= { isisCircuitCounterEntry 9 } isisCircLANDesISChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the Designated IS has changed on this circuit at this level. If the circuit is point to point, this count is zero." ::= { isisCircuitCounterEntry 10 } -- isisPacketCounterTable keeps track of the number of IS-IS -- control packets sent and received at each level isisPacketCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisPacketCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about IS-IS protocol traffic at one level, on one circuit, in one direction." ::= { isisCounters 3 } isisPacketCounterEntry OBJECT-TYPE SYNTAX IsisPacketCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about IS-IS protocol traffic at one level, on one circuit, in one direction." Parker Standards Track [Page 46] RFC 4444 IS-IS MIB April 2006 INDEX { isisCircIndex, isisPacketCountLevel, isisPacketCountDirection } ::= { isisPacketCounterTable 1 } IsisPacketCounterEntry ::= SEQUENCE { isisPacketCountLevel IsisISLevel, isisPacketCountDirection INTEGER, isisPacketCountIIHello Counter32, isisPacketCountISHello Counter32, isisPacketCountESHello Counter32, isisPacketCountLSP Counter32, isisPacketCountCSNP Counter32, isisPacketCountPSNP Counter32, isisPacketCountUnknown Counter32 } isisPacketCountLevel OBJECT-TYPE SYNTAX IsisISLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level at which these PDU counts have been collected." ::= { isisPacketCounterEntry 1 } isisPacketCountDirection OBJECT-TYPE SYNTAX INTEGER { sending(1), receiving(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "Were we sending or receiving these PDUs?" ::= { isisPacketCounterEntry 2 } isisPacketCountIIHello OBJECT-TYPE Parker Standards Track [Page 47] RFC 4444 IS-IS MIB April 2006 SYNTAX Counter32 UNITS "Number of IS-IS Hellos frames seen in this direction at this level" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS Hello PDUs seen in this direction at this level. Point-to-Point IIH PDUs are counted at the lowest enabled level: at L1 on L1 or L1L2 circuits, and at L2 otherwise." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::= { isisPacketCounterEntry 3 } isisPacketCountISHello OBJECT-TYPE SYNTAX Counter32 UNITS "Number of ES-IS frames seen in this direction at this level." MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ES-IS Hello PDUs seen in this direction. ISH PDUs are counted at the lowest enabled level: at L1 on L1 or L1L2 circuits, and at L2 otherwise." ::= { isisPacketCounterEntry 4 } isisPacketCountESHello OBJECT-TYPE SYNTAX Counter32 UNITS "Number of ES Hello frames seen in this direction at this level" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ES Hello PDUs seen in this direction. ESH PDUs are counted at the lowest enabled level: at L1 on L1 or L1L2 circuits, and at L2 otherwise." ::= { isisPacketCounterEntry 5 } isisPacketCountLSP OBJECT-TYPE SYNTAX Counter32 UNITS "Number of IS-IS LSP frames seen in this direction at this level" MAX-ACCESS read-only STATUS current DESCRIPTION Parker Standards Track [Page 48] RFC 4444 IS-IS MIB April 2006 "The number of IS-IS LSPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::= { isisPacketCounterEntry 6 } isisPacketCountCSNP OBJECT-TYPE SYNTAX Counter32 UNITS "Number of IS-IS CSNP frames seen in this direction at this level" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS CSNPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::= { isisPacketCounterEntry 7 } isisPacketCountPSNP OBJECT-TYPE SYNTAX Counter32 UNITS "Number of IS-IS PSNP frames seen in this direction at this level" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS PSNPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::= { isisPacketCounterEntry 8 } isisPacketCountUnknown OBJECT-TYPE SYNTAX Counter32 UNITS "Number of unknown IS-IS frames seen at this level" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of unknown IS-IS PDUs seen at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::= { isisPacketCounterEntry 9 } -- The IS Adjacency Table -- -- Each adjacency to an IS corresponds to one entry in this -- table. isisISAdjTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjEntry MAX-ACCESS not-accessible Parker Standards Track [Page 49] RFC 4444 IS-IS MIB April 2006 STATUS current DESCRIPTION "The table of adjacencies to Intermediate Systems." ::= { isisISAdj 1 } isisISAdjEntry OBJECT-TYPE SYNTAX IsisISAdjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to one adjacency to an Intermediate System on this system. Dynamically learned rows do not survive an agent reboot." INDEX { isisCircIndex, isisISAdjIndex } ::= { isisISAdjTable 1 } IsisISAdjEntry ::= SEQUENCE { isisISAdjIndex Unsigned32, isisISAdjState INTEGER, isisISAdj3WayState INTEGER, isisISAdjNeighSNPAAddress IsisOSINSAddress, isisISAdjNeighSysType INTEGER, isisISAdjNeighSysID IsisSystemID, isisISAdjNbrExtendedCircID Unsigned32, isisISAdjUsage IsisLevel, isisISAdjHoldTimer IsisUnsigned16TC, isisISAdjNeighPriority IsisISPriority, isisISAdjLastUpTime TimeStamp } isisISAdjIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current Parker Standards Track [Page 50] RFC 4444 IS-IS MIB April 2006 DESCRIPTION "A unique value identifying the IS adjacency from all other such adjacencies on this circuit. This value is automatically assigned by the system when the adjacency is created." ::= { isisISAdjEntry 1 } isisISAdjState OBJECT-TYPE SYNTAX INTEGER { down (1), initializing (2), up (3), failed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the adjacency." REFERENCE "{ISIS.aoi adjacencyState (78)}" ::= { isisISAdjEntry 2 } isisISAdj3WayState OBJECT-TYPE SYNTAX INTEGER { up (0), initializing (1), down (2), failed (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The 3Way state of the adjacency. These are picked to match the historical on-the-wire representation of the 3Way state and are not intended to match isisISAdjState." REFERENCE "{ RFC 3373 }" ::= { isisISAdjEntry 3 } isisISAdjNeighSNPAAddress OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SNPA address of the neighboring system." REFERENCE "{ISIS.aoi neighbourSNPAAddress (79)}" ::= { isisISAdjEntry 4 } Parker Standards Track [Page 51] RFC 4444 IS-IS MIB April 2006 isisISAdjNeighSysType OBJECT-TYPE SYNTAX INTEGER { l1IntermediateSystem(1), l2IntermediateSystem(2), l1L2IntermediateSystem(3), unknown(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the neighboring system." REFERENCE "{ISIS.aoi neighbourSystemType (80)}" ::= { isisISAdjEntry 5 } isisISAdjNeighSysID OBJECT-TYPE SYNTAX IsisSystemID MAX-ACCESS read-only STATUS current DESCRIPTION "The system ID of the neighboring Intermediate System." REFERENCE "{ISIS.aoi neighbourSystemIds (83)}" ::= { isisISAdjEntry 6 } isisISAdjNbrExtendedCircID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 4-byte Extended Circuit ID learned from the Neighbor during 3-way handshake, or 0." ::= { isisISAdjEntry 7 } isisISAdjUsage OBJECT-TYPE SYNTAX IsisLevel MAX-ACCESS read-only STATUS current DESCRIPTION "How is the adjacency used? On a point-to-point link, this might be level1and2, but on a LAN, the usage will be level1 on the adjacency between peers at L1, and level2 for the adjacency between peers at L2." REFERENCE "{ISIS.aoi adjacencyUsage (82)}" ::= { isisISAdjEntry 8 } isisISAdjHoldTimer OBJECT-TYPE SYNTAX IsisUnsigned16TC (1..65535) Parker Standards Track [Page 52] RFC 4444 IS-IS MIB April 2006 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The holding time, in seconds, for this adjacency. This value is based on received IIH PDUs and the elapsed time since receipt." REFERENCE "{ISIS.aoi holdingTimer (85)}" ::= { isisISAdjEntry 9 } isisISAdjNeighPriority OBJECT-TYPE SYNTAX IsisISPriority MAX-ACCESS read-only STATUS current DESCRIPTION "Priority of the neighboring Intermediate System for becoming the Designated Intermediate System." REFERENCE "{ISIS.aoi lANPriority (86)}" ::= { isisISAdjEntry 10 } isisISAdjLastUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "When the adjacency most recently entered the state 'up', measured in hundredths of a second since the last re-initialization of the network management subsystem. Holds 0 if the adjacency has never been in state 'up'." ::= { isisISAdjEntry 11 } -- The IS Adjacency Area Address Table -- The IS Adjacency Area Address Table contains the set of -- Area Addresses of neighboring -- Intermediate Systems as reported in IIH PDUs. isisISAdjAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of Area Addresses of neighboring Intermediate Systems as reported in received IIH PDUs." REFERENCE "{ISIS.aoi areaAddressesOfNeighbour (84)}" ::= { isisISAdj 2 } Parker Standards Track [Page 53] RFC 4444 IS-IS MIB April 2006 isisISAdjAreaAddrEntry OBJECT-TYPE SYNTAX IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one Area Address reported by a neighboring Intermediate System in its IIH PDUs. Dynamically learned rows do not survive an agent reboot." INDEX { isisCircIndex, isisISAdjIndex, isisISAdjAreaAddrIndex } ::= { isisISAdjAreaAddrTable 1 } IsisISAdjAreaAddrEntry ::= SEQUENCE { isisISAdjAreaAddrIndex Unsigned32, isisISAdjAreaAddress IsisOSINSAddress } isisISAdjAreaAddrIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index for the areas associated with one neighbor. This provides a simple way to walk the table." ::= { isisISAdjAreaAddrEntry 1 } isisISAdjAreaAddress OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "One Area Address as reported in IIH PDUs received from the neighbor." ::= { isisISAdjAreaAddrEntry 2 } -- The IS Adjacency IP Address Table -- The IS Adjacency IP Address Table contains the -- set of IP Addresses of neighboring Intermediate Systems -- as reported in received IIH PDUs. isisISAdjIPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjIPAddrEntry Parker Standards Track [Page 54] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of IP Addresses of neighboring Intermediate Systems as reported in received IIH PDUs." ::= { isisISAdj 3 } isisISAdjIPAddrEntry OBJECT-TYPE SYNTAX IsisISAdjIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP Address reported by a neighboring Intermediate System in its IIH PDUs. Dynamically learned rows do not survive an agent reboot." INDEX { isisCircIndex, isisISAdjIndex, isisISAdjIPAddrIndex } ::= { isisISAdjIPAddrTable 1 } IsisISAdjIPAddrEntry ::= SEQUENCE { isisISAdjIPAddrIndex Unsigned32, isisISAdjIPAddrType InetAddressType, isisISAdjIPAddrAddress InetAddress } isisISAdjIPAddrIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index to this table that identifies the IP addresses to which this entry belongs." ::= { isisISAdjIPAddrEntry 1 } isisISAdjIPAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of one IP Address as reported in IIH PDUs Parker Standards Track [Page 55] RFC 4444 IS-IS MIB April 2006 received from the neighbor." ::= { isisISAdjIPAddrEntry 2 } isisISAdjIPAddrAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "One IP Address as reported in IIH PDUs received from the neighbor. The type of this address is determined by the value of the isisISAdjIPAddrType object." ::= { isisISAdjIPAddrEntry 3 } -- The IS Adjacency Protocol Supported Table -- -- The IS Adjacency Protocol Supported Table contains the set of -- protocols supported by neighboring -- Intermediate Systems as reported in received IIH PDUs. isisISAdjProtSuppTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of protocols supported by neighboring Intermediate Systems as reported in received IIH PDUs." ::= { isisISAdj 4 } isisISAdjProtSuppEntry OBJECT-TYPE SYNTAX IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one protocol supported by a neighboring Intermediate System as reported in its IIH PDUs. Dynamically learned rows do not survive an agent reboot." INDEX { isisCircIndex, isisISAdjIndex, isisISAdjProtSuppProtocol } ::= { isisISAdjProtSuppTable 1 } IsisISAdjProtSuppEntry ::= SEQUENCE { Parker Standards Track [Page 56] RFC 4444 IS-IS MIB April 2006 isisISAdjProtSuppProtocol IsisSupportedProtocol } isisISAdjProtSuppProtocol OBJECT-TYPE SYNTAX IsisSupportedProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "One supported protocol as reported in IIH PDUs received from the neighbor." ::= { isisISAdjProtSuppEntry 1 } -- The Reachable Address Group -- -- The Reachable Address Table -- Each entry records information about a reachable address -- (NSAP or address prefix) manually configured on the system -- or learned through another protocol. isisRATable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of Reachable Addresses to NSAPs or Address Prefixes." ::= { isisReachAddr 1 } isisRAEntry OBJECT-TYPE SYNTAX IsisRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines a configured Reachable Address to an NSAP or Address Prefix. Dynamically created rows MUST survive an agent reboot." INDEX { isisCircIndex, isisRAIndex } ::= { isisRATable 1 } IsisRAEntry ::= SEQUENCE { isisRAIndex Unsigned32, isisRAExistState RowStatus, Parker Standards Track [Page 57] RFC 4444 IS-IS MIB April 2006 isisRAAdminState IsisAdminState, isisRAAddrPrefix IsisOSINSAddress, isisRAMapType INTEGER, isisRAMetric IsisDefaultMetric, isisRAMetricType IsisMetricType, isisRASNPAAddress IsisOSINSAddress, isisRASNPAMask IsisOSINSAddress, isisRASNPAPrefix IsisOSINSAddress, isisRAType INTEGER } isisRAIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier for this isisRAEntry. This value must be unique amongst all Reachable Addresses on the same parent Circuit." ::= { isisRAEntry 1 } isisRAExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this Reachable Address. This object follows the ManualOrAutomatic behaviors. Support for 'createAndWait' and 'notInService' is not required. A row entry cannot be modified when the value of this object is 'active'." ::= { isisRAEntry 2 } isisRAAdminState OBJECT-TYPE SYNTAX IsisAdminState MAX-ACCESS read-create STATUS current DESCRIPTION Parker Standards Track [Page 58] RFC 4444 IS-IS MIB April 2006 "The administrative state of the Reachable Address. This object follows the ManualOrAutomatic behaviors." DEFVAL { off } ::= { isisRAEntry 3 } isisRAAddrPrefix OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The destination of this Reachable Address. This is an Address Prefix. This object follows the ReplaceOnlyWhileDisabled and ManualOrAutomatic behaviors." REFERENCE "{ISIS.aoi addressPrefix (98)}" ::= { isisRAEntry 4 } isisRAMapType OBJECT-TYPE SYNTAX INTEGER { none (1), explicit (2), extractIDI (3), extractDSP (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of mapping to be employed to ascertain the SNPA Address that should be used in forwarding PDUs for this Reachable Address prefix. This object follows the ManualOrAutomatic behavior. The following values of mapping type are defined: none: The mapping is null because the neighbor SNPA is implicit by nature of the subnetwork (e.g., a point-to-point linkage). explicit: The subnetwork addresses in the object isisRASNPAAddress are to be used. extractIDI: The SNPA is embedded in the IDI of the destination NSAP Address. The mapping algorithm extracts the SNPA to be used according to the format and encoding rules of ISO8473/Add2. This SNPA extraction algorithm can be used in conjunction with Reachable Address prefixes from the X.121, F.69, E.163, and E.164 Parker Standards Track [Page 59] RFC 4444 IS-IS MIB April 2006 addressing subdomains. extractDSP: All, or a suffix, of the SNPA is embedded in the DSP of the destination address. This SNPA extraction algorithm extracts the embedded subnetwork addressing information by performing a logical AND of the isisRASNPAMask object value with the destination address. The part of the SNPA extracted from the destination NSAP is appended to the isisRASNPAPrefix object value to form the next hop subnetwork addressing information." REFERENCE "{ISO10589-ISIS.aoi mappingType (107)}" ::= { isisRAEntry 5 } isisRAMetric OBJECT-TYPE SYNTAX IsisDefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric value for reaching the specified prefix over this circuit. This object follows the ManualOrAutomatic behavior." REFERENCE "{ISIS.aoi DefaultMetric (99)}" DEFVAL { 20 } ::= { isisRAEntry 6 } isisRAMetricType OBJECT-TYPE SYNTAX IsisMetricType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the metric is internal or external. This object follows the ManualOrAutomatic behavior." REFERENCE "{ISIS.aoi DefaultMetricType (103)}" DEFVAL { internal } ::= { isisRAEntry 7 } isisRASNPAAddress OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The SNPA Address to which a PDU may be forwarded in order to reach a destination that matches the address prefix of the Reachable Address. This object follows the Parker Standards Track [Page 60] RFC 4444 IS-IS MIB April 2006 ManualOrAutomatic behavior." REFERENCE "{ISIS.aoi sNPAAddresses (109)}" -- Note only one address may be specified per Reachable Address -- in the MIB DEFVAL { ''H } ::= { isisRAEntry 8 } isisRASNPAMask OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-create STATUS current DESCRIPTION "A bit mask with 1 bit indicating the positions in the effective destination address from which embedded SNPA information is to be extracted. For the extraction, the first octet of the isisRASNPAMask object value is aligned with the first octet (AFI) of the NSAP Address. If the isisRASNPAMask object value and NSAP Address are of different lengths, the shorter of the two is logically padded with zeros before performing the extraction. This object follows the ManualOrAutomatic behavior." REFERENCE "{ISIS.aoi sNPAMask (122)}" DEFVAL { '00'H } ::= { isisRAEntry 9 } isisRASNPAPrefix OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-create STATUS current DESCRIPTION "A fixed SNPA prefix for use when the isisRAMapType is extractDSP. The SNPA Address to use is formed by concatenating the fixed SNPA prefix with a variable SNPA part that is extracted from the effective destination address. For Reachable Address prefixes in which the entire SNPA is embedded in the DSP, the SNPA Prefix shall be null. This object follows the ManualOrAutomatic behavior." REFERENCE "{ISIS.aoi sNPAPrefix (123)}" DEFVAL { '00'H } ::= { isisRAEntry 10 } isisRAType OBJECT-TYPE SYNTAX INTEGER { manual (1), automatic (2) } Parker Standards Track [Page 61] RFC 4444 IS-IS MIB April 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Reachable address. Those of type manual are created by the network manager. Those of type automatic are created through propagation of routing information from another routing protocol (e.g., IDRP). " DEFVAL {manual} ::= {isisRAEntry 11 } -- The IP Reachable Address Table -- Each entry records information about one IP reachable -- address manually configured on this system or learned from -- another protocol. isisIPRATable OBJECT-TYPE SYNTAX SEQUENCE OF IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of IP Reachable Addresses to networks, subnetworks, or hosts either manually configured or learned from another protocol." ::= { isisIPReachAddr 1 } isisIPRAEntry OBJECT-TYPE SYNTAX IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines an IP Reachable Address to a network, subnetwork, or host. Each IP Reachable Address may have multiple entries in the table, one for each equal cost path to the reachable address. Dynamically created rows MUST survive an agent reboot. Implementers need to be aware that if the total number of elements (octets or sub-identifiers) in isisIPRADestr, isisIPRADestPrefixLen, and isisIPRANextHopIndex is too great, then OIDs of column instances in this table will have more than 128 subidentifiers and cannot be accessed using SNMPv1, Parker Standards Track [Page 62] RFC 4444 IS-IS MIB April 2006 SNMPv2c, or SNMPv3." INDEX { isisSysLevelIndex, isisIPRADestType, isisIPRADest, isisIPRADestPrefixLen, isisIPRANextHopIndex } ::= { isisIPRATable 1 } IsisIPRAEntry ::= SEQUENCE { isisIPRADestType InetAddressType, isisIPRADest InetAddress, isisIPRADestPrefixLen InetAddressPrefixLength, isisIPRANextHopIndex Unsigned32, isisIPRANextHopType InetAddressType, isisIPRANextHop InetAddress, isisIPRAType INTEGER, isisIPRAExistState RowStatus, isisIPRAAdminState IsisAdminState, isisIPRAMetric IsisDefaultMetric, isisIPRAMetricType IsisMetricType, isisIPRAFullMetric IsisFullMetric, isisIPRASNPAAddress IsisOSINSAddress, isisIPRASourceType INTEGER } isisIPRADestType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of this IP Reachable Address." ::= { isisIPRAEntry 1 } Parker Standards Track [Page 63] RFC 4444 IS-IS MIB April 2006 isisIPRADest OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination of this IP Reachable Address. This is a network address, subnetwork address, or host address. The type of this address is determined by the value of the isisIPRADestType object." ::= { isisIPRAEntry 2 } isisIPRADestPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length of the IP Netmask for Reachability Address. The values for the index objects isisIPRADest and isisIPRADestPrefixLen must be consistent. When the value of isisIPRADest (excluding the zone index, if one is present) is x, then the bitwise logical-AND of x with the value of the mask formed from the corresponding index object isisIPRADestPrefixLen MUST be equal to x. If not, then the index pair is not consistent, and an inconsistentName error must be returned on SET or CREATE requests." ::= { isisIPRAEntry 3 } isisIPRANextHopIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of next hop. Used when there are multiple Equal Cost Multipath alternatives for the same destination." ::= { isisIPRAEntry 4 } isisIPRANextHopType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the IP next hop address." ::= { isisIPRAEntry 5 } Parker Standards Track [Page 64] RFC 4444 IS-IS MIB April 2006 isisIPRANextHop OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP next hop to this destination. The type of this address is determined by the value of the isisIPRANextHopType object." ::= { isisIPRAEntry 6 } isisIPRAType OBJECT-TYPE SYNTAX INTEGER { manual (1), automatic (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of this IP Reachable Address. Those of type manual are created by the network manager. Those of type automatic are created through propagation of routing information from another routing protocol. This object follows the ManualOrAutomatic behavior." ::= { isisIPRAEntry 7 } isisIPRAExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of this IP Reachable Address. This object follows the ExistenceState and ManualOrAutomatic behaviors. Support for 'createAndWait' and 'notInService' is not required. A row entry cannot be modified when the value of this object is 'active'." ::= { isisIPRAEntry 8 } isisIPRAAdminState OBJECT-TYPE SYNTAX IsisAdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the IP Reachable Address. This object follows the IsisAdminState and ManualOrAutomatic Parker Standards Track [Page 65] RFC 4444 IS-IS MIB April 2006 behaviors." DEFVAL { off } ::= { isisIPRAEntry 9 } isisIPRAMetric OBJECT-TYPE SYNTAX IsisDefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric value for reaching the specified destination over this circuit. This object follows the ManualOrAutomatic behavior." DEFVAL { 10 } ::= { isisIPRAEntry 10 } isisIPRAMetricType OBJECT-TYPE SYNTAX IsisMetricType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the metric is internal or external. This object follows the ManualOrAutomatic behavior." DEFVAL { internal } ::= { isisIPRAEntry 11 } isisIPRAFullMetric OBJECT-TYPE SYNTAX IsisFullMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The wide metric value for reaching the specified destination over this circuit. This object follows the ManualOrAutomatic behavior." DEFVAL { 10 } ::= { isisIPRAEntry 12 } isisIPRASNPAAddress OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The SNPA Address to which a PDU may be forwarded in order to reach a destination that matches this IP Reachable Address. This object follows the ManualOrAutomatic behavior." DEFVAL { ''H } ::= { isisIPRAEntry 13 } Parker Standards Track [Page 66] RFC 4444 IS-IS MIB April 2006 isisIPRASourceType OBJECT-TYPE SYNTAX INTEGER { static (1), direct (2), ospfv2 (3), ospfv3 (4), isis (5), rip (6), igrp (7), eigrp (8), bgp (9), other (10) } MAX-ACCESS read-only STATUS current DESCRIPTION "The origin of this route." ::= { isisIPRAEntry 14 } -- The LSP Database Table -- -- The first table provides Summary Information about LSPs -- The next table provides a complete record isisLSPSummaryTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisLSPSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of LSP Headers." ::= { isisLSPDataBase 1 } isisLSPSummaryEntry OBJECT-TYPE SYNTAX IsisLSPSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry provides a summary describing an LSP currently stored in the system. Dynamically learned rows will not survive an agent reboot." INDEX { isisLSPLevel, isisLSPID } ::= { isisLSPSummaryTable 1 } IsisLSPSummaryEntry ::= Parker Standards Track [Page 67] RFC 4444 IS-IS MIB April 2006 SEQUENCE { isisLSPLevel IsisISLevel, isisLSPID IsisLinkStatePDUID, isisLSPSeq Unsigned32, isisLSPZeroLife TruthValue, isisLSPChecksum IsisUnsigned16TC, isisLSPLifetimeRemain IsisUnsigned16TC, isisLSPPDULength IsisUnsigned16TC, isisLSPAttributes IsisUnsigned8TC } isisLSPLevel OBJECT-TYPE SYNTAX IsisISLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "At which level does this LSP appear?" ::= { isisLSPSummaryEntry 1 } isisLSPID OBJECT-TYPE SYNTAX IsisLinkStatePDUID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 8-byte LSP ID for this Link State PDU." ::= { isisLSPSummaryEntry 2 } isisLSPSeq OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number for this LSP." ::= { isisLSPSummaryEntry 3 } isisLSPZeroLife OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Parker Standards Track [Page 68] RFC 4444 IS-IS MIB April 2006 "Is this LSP being purged by this system?" ::= { isisLSPSummaryEntry 4 } isisLSPChecksum OBJECT-TYPE SYNTAX IsisUnsigned16TC MAX-ACCESS read-only STATUS current DESCRIPTION "The 16-bit Fletcher Checksum for this LSP." ::= { isisLSPSummaryEntry 5 } isisLSPLifetimeRemain OBJECT-TYPE SYNTAX IsisUnsigned16TC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The remaining lifetime, in seconds, for this LSP." ::= { isisLSPSummaryEntry 6 } isisLSPPDULength OBJECT-TYPE SYNTAX IsisUnsigned16TC MAX-ACCESS read-only STATUS current DESCRIPTION "The length of this LSP." ::= { isisLSPSummaryEntry 7 } isisLSPAttributes OBJECT-TYPE SYNTAX IsisUnsigned8TC MAX-ACCESS read-only STATUS current DESCRIPTION "Flags carried by the LSP." ::= { isisLSPSummaryEntry 8 } -- LSP Table -- -- The full LSP as a sequence of {Type, Len, Value} tuples -- Since the underlying LSP may have changed while downloading -- TLVs, we provide the Sequence number and Checksum for each -- LSP TLV, so the network manager may verify that they are -- still working on the same version of the LSP. isisLSPTLVTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisLSPTLVEntry MAX-ACCESS not-accessible STATUS current Parker Standards Track [Page 69] RFC 4444 IS-IS MIB April 2006 DESCRIPTION "The table of LSPs in the database." ::= { isisLSPDataBase 2 } isisLSPTLVEntry OBJECT-TYPE SYNTAX IsisLSPTLVEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry describes a TLV within an LSP currently stored in the system. Dynamically learned rows will not survive an agent reboot." INDEX { isisLSPLevel, isisLSPID, isisLSPTLVIndex } ::= { isisLSPTLVTable 1 } IsisLSPTLVEntry ::= SEQUENCE { isisLSPTLVIndex Unsigned32, isisLSPTLVSeq Unsigned32, isisLSPTLVChecksum IsisUnsigned16TC, isisLSPTLVType IsisUnsigned8TC, isisLSPTLVLen IsisUnsigned8TC, isisLSPTLVValue OCTET STRING } isisLSPTLVIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this TLV in the LSP. The first TLV has index 1, and the Nth TLV has an index of N." ::= { isisLSPTLVEntry 1 } isisLSPTLVSeq OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Parker Standards Track [Page 70] RFC 4444 IS-IS MIB April 2006 DESCRIPTION "The sequence number for this LSP." ::= { isisLSPTLVEntry 2 } isisLSPTLVChecksum OBJECT-TYPE SYNTAX IsisUnsigned16TC MAX-ACCESS read-only STATUS current DESCRIPTION "The 16-bit Fletcher Checksum for this LSP." ::= { isisLSPTLVEntry 3 } isisLSPTLVType OBJECT-TYPE SYNTAX IsisUnsigned8TC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this TLV." ::= { isisLSPTLVEntry 4 } isisLSPTLVLen OBJECT-TYPE SYNTAX IsisUnsigned8TC MAX-ACCESS read-only STATUS current DESCRIPTION "The length of this TLV." ::= { isisLSPTLVEntry 5 } isisLSPTLVValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this TLV." ::= { isisLSPTLVEntry 6 } -- The IS-IS Notification Table -- The IS-IS Notification Table records fields that are -- required for notifications isisNotificationEntry OBJECT IDENTIFIER ::= { isisNotification 1 } isisNotificationSysLevelIndex OBJECT-TYPE SYNTAX IsisLevel MAX-ACCESS accessible-for-notify Parker Standards Track [Page 71] RFC 4444 IS-IS MIB April 2006 STATUS current DESCRIPTION "The system level for this notification." ::= { isisNotificationEntry 1 } isisNotificationCircIfIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The identifier of this circuit relevant to this notification." ::= { isisNotificationEntry 2 } isisPduLspId OBJECT-TYPE SYNTAX IsisLinkStatePDUID MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "An Octet String that uniquely identifies a Link State PDU." ::= { isisNotificationEntry 3 } isisPduFragment OBJECT-TYPE SYNTAX IsisPDUHeader MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Holds up to 64 initial bytes of a PDU that triggered the notification." ::= { isisNotificationEntry 4 } isisPduFieldLen OBJECT-TYPE SYNTAX IsisUnsigned8TC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Holds the System ID length reported in PDU we received." ::= { isisNotificationEntry 5 } isisPduMaxAreaAddress OBJECT-TYPE SYNTAX IsisUnsigned8TC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Holds the Max Area Addresses reported in a PDU we received." ::= { isisNotificationEntry 6 } Parker Standards Track [Page 72] RFC 4444 IS-IS MIB April 2006 isisPduProtocolVersion OBJECT-TYPE SYNTAX IsisUnsigned8TC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Holds the Protocol version reported in PDU we received." ::= { isisNotificationEntry 7 } isisPduLspSize OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Holds the size of LSP we received that is too big to forward." ::= { isisNotificationEntry 8 } isisPduOriginatingBufferSize OBJECT-TYPE SYNTAX IsisUnsigned16TC (0..16000) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Holds the size of isisSysLevelOrigLSPBuffSize advertised by the peer in the originatingLSPBufferSize TLV. If the peer does not advertise this TLV, this value is set to 0." ::= { isisNotificationEntry 9 } isisPduBufferSize OBJECT-TYPE SYNTAX IsisUnsigned16TC (0..16000) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Holds the size of LSP received from peer." ::= { isisNotificationEntry 10 } isisPduProtocolsSupported OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The list of protocols supported by an adjacent system. This may be empty." ::= { isisNotificationEntry 11 } isisAdjState OBJECT-TYPE SYNTAX INTEGER { Parker Standards Track [Page 73] RFC 4444 IS-IS MIB April 2006 down (1), initializing (2), up (3), failed(4) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The current state of an adjacency." ::= { isisNotificationEntry 12 } isisErrorOffset OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "An offset to a problem in a PDU. If the problem is a malformed TLV, this points to the beginning of the TLV. If the problem is in the header, this points to the byte that is suspicious." ::= { isisNotificationEntry 13 } isisErrorTLVType OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The type for a malformed TLV." ::= { isisNotificationEntry 14 } isisNotificationAreaAddress OBJECT-TYPE SYNTAX IsisOSINSAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "An Area Address." ::= { isisNotificationEntry 15 } -- Notification definitions -- -- Note that notifications can be disabled by setting -- isisSysNotificationEnable false isisDatabaseOverload NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisSysLevelState } Parker Standards Track [Page 74] RFC 4444 IS-IS MIB April 2006 STATUS current DESCRIPTION "This notification is generated when the system enters or leaves the Overload state. The number of times this has been generated and cleared is kept track of by isisSysStatLSPDbaseOloads." ::= { isisNotifications 1 } isisManualAddressDrops NOTIFICATION-TYPE OBJECTS { isisNotificationAreaAddress } STATUS current DESCRIPTION "This notification is generated when one of the manual areaAddresses assigned to this system is ignored when computing routes. The object isisNotificationAreaAddress describes the area that has been dropped. The number of times this event has been generated is counted by isisSysStatManAddrDropFromAreas. The agent must throttle the generation of consecutive isisManualAddressDrops notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 2 } isisCorruptedLSPDetected NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisPduLspId } STATUS current DESCRIPTION "This notification is generated when we find that an LSP that was stored in memory has become corrupted. The number of times this has been generated is counted by isisSysCorrLSPs. We forward an LSP ID. We may have independent knowledge of the ID, but in some implementations there is a chance that the ID itself will be corrupted." Parker Standards Track [Page 75] RFC 4444 IS-IS MIB April 2006 ::= { isisNotifications 3 } isisAttemptToExceedMaxSequence NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisPduLspId } STATUS current DESCRIPTION "When the sequence number on an LSP we generate wraps the 32-bit sequence counter, we purge and wait to re-announce this information. This notification describes that event. Since these should not be generated rapidly, we generate an event each time this happens. While the first 6 bytes of the LSPID are ours, the other two contain useful information." ::= { isisNotifications 4 } isisIDLenMismatch NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisPduFieldLen, isisNotificationCircIfIndex, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a PDU with a different value for the System ID Length. This notification includes an index to identify the circuit where we saw the PDU and the header of the PDU, which may help a network manager identify the source of the confusion. The agent must throttle the generation of consecutive isisIDLenMismatch notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 5 } isisMaxAreaAddressesMismatch NOTIFICATION-TYPE OBJECTS { Parker Standards Track [Page 76] RFC 4444 IS-IS MIB April 2006 isisNotificationSysLevelIndex, isisPduMaxAreaAddress, isisNotificationCircIfIndex, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a PDU with a different value for the Maximum Area Addresses. This notification includes the header of the packet, which may help a network manager identify the source of the confusion. The agent must throttle the generation of consecutive isisMaxAreaAddressesMismatch notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 6 } isisOwnLSPPurge NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduLspId } STATUS current DESCRIPTION "A notification sent when we receive a PDU with our systemID and zero age. This notification includes the circuit Index and router ID from the LSP, if available, which may help a network manager identify the source of the confusion." ::= { isisNotifications 7 } isisSequenceNumberSkip NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduLspId } STATUS current Parker Standards Track [Page 77] RFC 4444 IS-IS MIB April 2006 DESCRIPTION "When we receive an LSP with our System ID and different contents, we may need to reissue the LSP with a higher sequence number. We send this notification if we need to increase the sequence number by more than one. If two Intermediate Systems are configured with the same System ID, this notification will fire." ::= { isisNotifications 8 } isisAuthenticationTypeFailure NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a PDU with the wrong authentication type field. This notification includes the header of the packet, which may help a network manager identify the source of the confusion. The agent must throttle the generation of consecutive isisAuthenticationTypeFailure notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 9 } isisAuthenticationFailure NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a PDU with an incorrect authentication information field. This notification includes the header of the packet, which may help a network manager identify the source of the confusion. Parker Standards Track [Page 78] RFC 4444 IS-IS MIB April 2006 The agent must throttle the generation of consecutive isisAuthenticationFailure notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 10 } isisVersionSkew NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduProtocolVersion, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a Hello PDU from an IS running a different version of the protocol. This notification includes the header of the packet, which may help a network manager identify the source of the confusion. The agent must throttle the generation of consecutive isisVersionSkew notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 11 } isisAreaMismatch NOTIFICATION-TYPE OBJECTS { isisNotificationCircIfIndex, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a Hello PDU from an IS that does not share any area address. This notification includes the header of the packet, which may help a network manager identify the source of the confusion. Parker Standards Track [Page 79] RFC 4444 IS-IS MIB April 2006 The agent must throttle the generation of consecutive isisAreaMismatch notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 12 } isisRejectedAdjacency NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a Hello PDU from an IS but do not establish an adjacency for some reason. The agent must throttle the generation of consecutive isisRejectedAdjacency notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 13 } isisLSPTooLargeToPropagate NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduLspSize, isisPduLspId } STATUS current DESCRIPTION "A notification sent when we attempt to propagate an LSP that is larger than the dataLinkBlockSize for the circuit. The agent must throttle the generation of consecutive isisLSPTooLargeToPropagate notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not Parker Standards Track [Page 80] RFC 4444 IS-IS MIB April 2006 queued for sending at a future time." ::= { isisNotifications 14 } isisOrigLSPBuffSizeMismatch NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduLspId, isisPduOriginatingBufferSize, isisPduBufferSize } STATUS current DESCRIPTION "A notification sent when a Level 1 LSP or Level 2 LSP is received that is larger than the local value for isisSysLevelOrigLSPBuffSize, or when an LSP is received that contains the supported Buffer Size option and the value in the PDU option field does not match the local value for isisSysLevelOrigLSPBuffSize. We pass up the size from the option field and the size of the LSP when one of them exceeds our configuration. The agent must throttle the generation of consecutive isisOrigLSPBuffSizeMismatch notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 15 } isisProtocolsSupportedMismatch NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduProtocolsSupported, isisPduLspId, isisPduFragment } STATUS current DESCRIPTION "A notification sent when a non-pseudonode segment 0 LSP is received that has no matching protocols supported. This may be because the system does not generate the field, or because there are no common elements. The list of protocols supported should be included in the notification: it may be Parker Standards Track [Page 81] RFC 4444 IS-IS MIB April 2006 empty if the TLV is not supported, or if the TLV is empty. The agent must throttle the generation of consecutive isisProtocolsSupportedMismatch notifications so that there is at least a 5-second gap between notifications of this type. When notifications are throttled, they are dropped, not queued for sending at a future time." ::= { isisNotifications 16 } isisAdjacencyChange NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduLspId, isisAdjState } STATUS current DESCRIPTION "A notification sent when an adjacency changes state, entering or leaving state up. The first 6 bytes of the isisPduLspId are the SystemID of the adjacent IS. The isisAdjState is the new state of the adjacency." ::= { isisNotifications 17 } isisLSPErrorDetected NOTIFICATION-TYPE OBJECTS { isisNotificationSysLevelIndex, isisPduLspId, isisNotificationCircIfIndex, isisPduFragment, isisErrorOffset, isisErrorTLVType } STATUS current DESCRIPTION "This notification is generated when we receive an LSP with a parse error. The isisCircIfIndex holds an index of the circuit on which the PDU arrived. The isisPduFragment holds the start of the LSP, and the isisErrorOffset points to the problem. If the problem is a malformed TLV, isisErrorOffset points to the start of the TLV, and isisErrorTLVType Parker Standards Track [Page 82] RFC 4444 IS-IS MIB April 2006 holds the value of the type. If the problem is with the LSP header, isisErrorOffset points to the suspicious byte. The number of such LSPs is accumulated in isisSysStatLSPErrors." ::= { isisNotifications 18 } -- Agent Conformance Definitions -- We define the objects a conformant agent must define isisCompliances OBJECT IDENTIFIER ::= { isisConformance 1 } isisGroups OBJECT IDENTIFIER ::= { isisConformance 2 } -- compliance statements isisCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support the IS-IS MIB. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements. Those requirements and similar requirements for related objects are expressed below, in pseudo-OBJECT clause form, in this description: -- OBJECT isisSummAddressType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 Summary -- Addresses and anticipates the support of -- IPv6 addresses. -- -- -- OBJECT isisRedistributeAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 -- Redistribution Addresses and anticipates -- the support of IPv6 addresses." -- Parker Standards Track [Page 83] RFC 4444 IS-IS MIB April 2006 -- -- OBJECT isisISAdjIPAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 -- Adjacency Addresses and anticipates the -- support of IPv6 addresses. MODULE -- this module MANDATORY-GROUPS { isisSystemGroup, isisCircuitGroup, isisISAdjGroup, isisNotificationObjectGroup, isisNotificationGroup } ::= { isisCompliances 1 } -- List of all groups, mandatory and optional isisAdvancedCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that fully support the IS-IS MIB. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements. Those requirements and similar requirements for related objects are expressed below, in pseudo-OBJECT clause form, in this description: -- OBJECT isisSummAddressType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 Summary -- Addresses and anticipates the support of -- IPv6 addresses. -- -- -- OBJECT isisRedistributeAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 -- Redistribution Addresses and anticipates -- the support of IPv6 addresses." Parker Standards Track [Page 84] RFC 4444 IS-IS MIB April 2006 -- -- -- OBJECT isisISAdjIPAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 -- Adjacency Addresses and anticipates the -- support of IPv6 addresses. -- -- -- OBJECT isisIPRADestType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 RA -- Addresses and anticipates the support of -- IPv6 addresses. -- -- -- OBJECT isisIPRANextHopType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 NextHop -- Addresses and anticipates the support of -- IPv6 addresses. MODULE -- this module MANDATORY-GROUPS { isisSystemGroup, isisCircuitGroup, isisISAdjGroup, isisNotificationObjectGroup, isisNotificationGroup, isisISPDUCounterGroup, isisRATableGroup, isisISIPRADestGroup, isisLSPGroup } ::= { isisCompliances 2 } isisReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read-create (i.e., in read-only mode), the implementation can claim read-only compliance. Such a device can then be monitored but cannot be Parker Standards Track [Page 85] RFC 4444 IS-IS MIB April 2006 configured with this MIB." MODULE -- this module MANDATORY-GROUPS { isisSystemGroup, isisCircuitGroup, isisISAdjGroup } OBJECT isisSysLevelType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysMaxPathSplits MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysMaxLSPGenInt MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysPollESHelloRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysWaitTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysAdminState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysL2toL1Leaking MIN-ACCESS read-only DESCRIPTION "Write access is not required." Parker Standards Track [Page 86] RFC 4444 IS-IS MIB April 2006 OBJECT isisSysMaxAge MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisManAreaAddrExistState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysLevelOrigLSPBuffSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysLevelMinLSPGenInt MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysLevelSetOverload MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysLevelSetOverloadUntil MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysLevelMetricStyle MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysLevelSPFConsiders MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysLevelTEEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSysReceiveLSPBufferSize MIN-ACCESS read-only DESCRIPTION Parker Standards Track [Page 87] RFC 4444 IS-IS MIB April 2006 "Write access is not required." OBJECT isisSummAddrExistState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSummAddrMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisSummAddrFullMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisRedistributeAddrExistState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircAdminState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircExistState MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircExtDomain MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircPassiveCircuit Parker Standards Track [Page 88] RFC 4444 IS-IS MIB April 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircMeshGroupEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircMeshGroup MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircSmallHellos MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircExtendedCircID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCirc3WayEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelWideMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelISPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." Parker Standards Track [Page 89] RFC 4444 IS-IS MIB April 2006 OBJECT isisCircLevelHelloMultiplier MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelHelloTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelDRHelloTimer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelLSPThrottle MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelMinLSPRetransInt MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelCSNPInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT isisCircLevelPartSNPInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { isisCompliances 3 } -- MIB Grouping isisSystemGroup OBJECT-GROUP OBJECTS { isisSysVersion, isisSysLevelType, isisSysID, isisSysMaxPathSplits, isisSysMaxLSPGenInt, isisSysPollESHelloRate, isisSysWaitTime, Parker Standards Track [Page 90] RFC 4444 IS-IS MIB April 2006 isisSysAdminState, isisSysL2toL1Leaking, isisSysMaxAge, isisSysProtSupported, isisSysNotificationEnable, isisManAreaAddrExistState, isisSysLevelOrigLSPBuffSize, isisSysLevelMinLSPGenInt, isisSysLevelState, isisSysLevelSetOverload, isisSysLevelSetOverloadUntil, isisSysLevelMetricStyle, isisSysLevelSPFConsiders, isisSysLevelTEEnabled, isisSysReceiveLSPBufferSize, isisSummAddrExistState, isisSummAddrMetric, isisAreaAddr, isisSummAddrFullMetric, isisRedistributeAddrExistState, isisRouterHostName, isisRouterID, isisSysStatCorrLSPs, isisSysStatLSPDbaseOloads, isisSysStatManAddrDropFromAreas, isisSysStatAttmptToExMaxSeqNums, isisSysStatSeqNumSkips, isisSysStatOwnLSPPurges, isisSysStatIDFieldLenMismatches, isisSysStatPartChanges, isisSysStatSPFRuns, isisSysStatAuthTypeFails, isisSysStatAuthFails, isisSysStatLSPErrors } STATUS current DESCRIPTION "The collections of objects used to manage an IS-IS router." ::= { isisGroups 1 } isisCircuitGroup OBJECT-GROUP OBJECTS { isisNextCircIndex, isisCircAdminState, isisCircExistState, isisCircType, isisCircExtDomain, Parker Standards Track [Page 91] RFC 4444 IS-IS MIB April 2006 isisCircLevelType, isisCircAdjChanges, isisCircNumAdj, isisCircInitFails, isisCircRejAdjs, isisCircIDFieldLenMismatches, isisCircMaxAreaAddrMismatches, isisCircAuthTypeFails, isisCircAuthFails, isisCircLANDesISChanges, isisCircPassiveCircuit, isisCircMeshGroupEnabled, isisCircMeshGroup, isisCircSmallHellos, isisCircLastUpTime, isisCirc3WayEnabled, isisCircExtendedCircID, isisCircIfIndex, isisCircLevelMetric, isisCircLevelWideMetric, isisCircLevelISPriority, isisCircLevelIDOctet, isisCircLevelID, isisCircLevelDesIS, isisCircLevelHelloMultiplier, isisCircLevelHelloTimer, isisCircLevelDRHelloTimer, isisCircLevelLSPThrottle, isisCircLevelMinLSPRetransInt, isisCircLevelCSNPInterval, isisCircLevelPartSNPInterval } STATUS current DESCRIPTION "The collections of objects used to describe an IS-IS Circuit." ::= { isisGroups 2 } isisISAdjGroup OBJECT-GROUP OBJECTS { isisISAdjState, isisISAdj3WayState, isisISAdjNeighSNPAAddress, isisISAdjNeighSysType, isisISAdjNeighSysID, isisISAdjNbrExtendedCircID, isisISAdjUsage, isisISAdjHoldTimer, Parker Standards Track [Page 92] RFC 4444 IS-IS MIB April 2006 isisISAdjNeighPriority, isisISAdjLastUpTime, isisISAdjAreaAddress, isisISAdjIPAddrType, isisISAdjIPAddrAddress, isisISAdjProtSuppProtocol } STATUS current DESCRIPTION "The collections of objects used to manage an IS-IS Adjacency." ::= { isisGroups 3 } isisNotificationObjectGroup OBJECT-GROUP OBJECTS { isisNotificationSysLevelIndex, isisNotificationCircIfIndex, isisPduLspId, isisPduFragment, isisPduFieldLen, isisPduMaxAreaAddress, isisPduProtocolVersion, isisPduLspSize, isisPduOriginatingBufferSize, isisPduBufferSize, isisPduProtocolsSupported, isisAdjState, isisErrorOffset, isisErrorTLVType, isisNotificationAreaAddress } STATUS current DESCRIPTION "The objects used to record notification parameters." ::= { isisGroups 4 } isisNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { isisDatabaseOverload, isisManualAddressDrops, isisCorruptedLSPDetected, isisAttemptToExceedMaxSequence, isisIDLenMismatch, isisMaxAreaAddressesMismatch, isisOwnLSPPurge, isisSequenceNumberSkip, isisAuthenticationTypeFailure, Parker Standards Track [Page 93] RFC 4444 IS-IS MIB April 2006 isisAuthenticationFailure, isisVersionSkew, isisAreaMismatch, isisRejectedAdjacency, isisLSPTooLargeToPropagate, isisOrigLSPBuffSizeMismatch, isisProtocolsSupportedMismatch, isisAdjacencyChange, isisLSPErrorDetected } STATUS current DESCRIPTION "The collections of notifications sent by an IS." ::= { isisGroups 5 } isisISPDUCounterGroup OBJECT-GROUP OBJECTS { isisPacketCountIIHello, isisPacketCountISHello, isisPacketCountESHello, isisPacketCountLSP, isisPacketCountCSNP, isisPacketCountPSNP, isisPacketCountUnknown } STATUS current DESCRIPTION "The collections of objects used to count protocol PDUs." ::= { isisGroups 6 } isisRATableGroup OBJECT-GROUP OBJECTS { isisRAExistState, isisRAAdminState, isisRAAddrPrefix, isisRAMapType, isisRAMetric, isisRAMetricType, isisRASNPAAddress, isisRASNPAMask, isisRASNPAPrefix, isisRAType } STATUS current DESCRIPTION "The collections of objects used to manage the Parker Standards Track [Page 94] RFC 4444 IS-IS MIB April 2006 reachable NSAP prefixes." ::= { isisGroups 7 } isisISIPRADestGroup OBJECT-GROUP OBJECTS { isisIPRANextHopType, isisIPRANextHop, isisIPRAType, isisIPRAExistState, isisIPRAAdminState, isisIPRAMetric, isisIPRAFullMetric, isisIPRAMetricType, isisIPRASNPAAddress, isisIPRASourceType } STATUS current DESCRIPTION "The collections of objects used to manage configured IP addresses." ::= { isisGroups 8 } isisLSPGroup OBJECT-GROUP OBJECTS { isisLSPSeq, isisLSPZeroLife, isisLSPChecksum, isisLSPLifetimeRemain, isisLSPPDULength, isisLSPAttributes, isisLSPTLVSeq, isisLSPTLVChecksum, isisLSPTLVType, isisLSPTLVLen, isisLSPTLVValue } STATUS current DESCRIPTION "The collections of objects used to observe the LSP Database." ::= { isisGroups 9 } END Parker Standards Track [Page 95] RFC 4444 IS-IS MIB April 2006 5. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- isisMIB { mib-2 138 } 6. Acknowledgements This MIB is based on a March 1994 document by Chris Gunner, who should be held blameless for the errors introduced since then. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. We would like to thank the following individuals for constructive and valuable comments: Mike Bartlett, Neal Castagnoli, Ken Chapman, Joan Cucchiara, Satish Dattatri, Nagi Jonnala, Adrian Farrel, Shamik Ganguly, Les Ginsberg, Don Goodspeed, Jeff Gross, Jim Halpin, Jon Harrison, Dimitri Haskin, C. M. Heard, Peter Higginson, Christian Hopps, Laura Liu, Gavin McPherson, Kay Noguchi, Serge Maskalik, Z. Opalka, Jeff Pickering, Sundar Ramachandran, Swaminatha Ramalingam, Aravind Ravikumar, Juergen Schoenwaelder, Koen Vermeulen, Hans De Vleeschouwer, Bert Wijnen, and Bingzhang Zhao. 7. Security Considerations Management information defined in this MIB may be considered sensitive in some network environments. 7.1. Discussion This MIB may be used to manage an IP router, which is used to direct network traffic. The control of network traffic allows an attacker to deny service to a region of the network or to forward traffic to adversaries. By raising or lowering metrics, traffic may be directed to insecure portions of the network. By disabling the protocol on an interface, the network may be partitioned. Changes to the network topology will force all routers to recompute their routes. Periodic route changes have brought down networks in the past by subjecting routers to stressful recomputations. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network Parker Standards Track [Page 96] RFC 4444 IS-IS MIB April 2006 environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Authentication of received SNMP requests and controlled access to management information should be employed in such environments. We identify a set of threats and then list attributes that can be used in each form of attack. We discuss the effects that can be obtained by a single change to the variable in each class. 7.2. Threats - Drop an Adjacency - Drop all Peers - Drop Subnetwork - Split the Network - Intermittent Outages - Redirect Traffic - Delay Convergence - Avoid Detection - Prevent Updates - Hijack LAN - Create Problems for CLNS Networks 7.2.1. Drop an Adjacency By changing attributes that are used to peer, we can disrupt an adjacency and bring a link down. isisCirc3WayEnabled isisCircAdminState isisCircExistState isisCircLevelDRHelloTimer isisCircLevelHelloTimer isisCircLevelType isisCircSmallHellos 7.2.2. Drop All Adjacencies These attributes can be used to break some or all of a router's adjacencies. In the case of System ID, the adjacency may be restored. However, it will subject the network to additional stress. isisSysLevelType isisManAreaAddrExistState isisSysAdminState isisSysID Parker Standards Track [Page 97] RFC 4444 IS-IS MIB April 2006 7.2.3. Drop Subnetwork This attribute can be used to stop advertisement of a subnetwork reachable through a single interface. isisCircPassiveCircuit 7.2.4. Split the Network If the network design depends upon Wide Metrics or TE, we can use these attributes to prevent traffic from passing through a router. isisSysLevelMetricStyle isisSysLevelOrigLSPBuffSize isisSysLevelSPFConsiders isisSysLevelTEEnabled isisSysReceiveLSPBufferSize 7.2.5. Intermittent Outages We can use these attributes to subject the network to a series of topology changes, or otherwise force extensive recomputations of routes. isisSysLevelMinLSPGenInt isisSysLevelSetOverload isisSysLevelSetOverloadUntil isisSysMaxAge isisSysMaxLSPGenInt isisSysL2toL1Leaking isisSysID 7.2.6. Redirect Traffic By changing attributes such as metrics, we can push traffic to different parts of the network. This may allow an intruder to observe data traffic from otherwise remote parts of the network. We may also use these attributes to deny service to parts of the network. isisSysMaxPathSplits isisCircLevelMetric isisCircLevelWideMetric isisIPRAAdminState isisIPRAExistState isisIPRAFullMetric isisIPRAMetric Parker Standards Track [Page 98] RFC 4444 IS-IS MIB April 2006 isisIPRAMetricType isisIPRANextHop isisIPRANextHopType isisIPRASNPAAddress isisIPRAType isisRedistributeAddrExistState isisSummAddrExistState isisSummAddrFullMetric isisSummAddrMetric isisSysL2toL1Leaking 7.2.7. Delay Convergence These attributes can be used to slow convergence by increasing the minimal interval required to update a packet. isisCircLevelCSNPInterval isisCircLevelLSPThrottle isisCircLevelMinLSPRetransInt isisCircLevelPartSNPInterval isisSysWaitTime isisCircPassiveCircuit 7.2.8. Avoid Detection By turning off traps, we can prevent a Network Management station from observing problems in the network caused by other aspects of an attack. isisSysNotificationEnable 7.2.9. Prevent Updates Mesh Groups can be used to prevent the transmission of Link State PDUs on certain interfaces, delaying or preventing the propagation of updates. isisCircMeshGroup isisCircMeshGroupEnabled 7.2.10. Hijack LAN If we have compromised a router, we can use this attribute to become the designated router and lie about the topology of a LAN. isisCircLevelISPriority Parker Standards Track [Page 99] RFC 4444 IS-IS MIB April 2006 7.2.11. Create Problems for CLNS Networks This attribute can be used to modify the handling of CLNS traffic. isisRAAddrPrefix isisRAAdminState isisRAExistState isisRAMapType isisRAMetric isisRAMetricType isisRASNPAAddress isisRASNPAMask isisRASNPAPrefix isisRAType isisSysPollESHelloRate 7.2.12. Mostly Harmless The following writable attributes do not pose a known security risk. isisCircExtDomain isisCircExtendedCircID isisCircIfIndex isisCircLevelHelloMultiplier isisCircType 7.2.13. Recommendations Much of the MIB is used to set or read attributes which are readily visible to any intruder who has access to traffic. None of the security attributes are setable or visible through the MIB. Read access to the MIB does not pose additional risks or vulnerabilities. If write access is to be provided, it is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an Parker Standards Track [Page 100] RFC 4444 IS-IS MIB April 2006 instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. Normative References [ISO10589] ISO 10589, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002. [ISO10733] ISO 10733, "Information Processing Systems - Open Systems Interconnection - Specification of the elements of Management Information related to OSI Network layer Standards", September 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Parker Standards Track [Page 101] RFC 4444 IS-IS MIB April 2006 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 9. Informative References [RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups", RFC 2973, October 2000. [RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point- to-Point Adjacencies", RFC 3373, September 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Authors' Address Jeff Parker Department of Computer Science Middlebury College, Middlebury, Vermont 05753 EMail: jeffp@middlebury.edu Parker Standards Track [Page 102] RFC 4444 IS-IS MIB April 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Parker Standards Track [Page 103] snmp-mibs-downloader-1.1/mibrfcs/rfc4455.txt0000644000000000000000000053540311402176072015576 0ustar Network Working Group M. Hallak-Stamler Request for Comments: 4455 Sanrad Intelligent Storage Category: Standards Track M. Bakke Cisco Systems, Inc. Y. Lederman Siliquent Technologies M. Krueger Hewlett-Packard K. McCloghrie Cisco Systems, Inc. April 2006 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. Table of Contents 1. The Internet-Standard Management Framework ......................3 2. Requirements Notation ...........................................3 3. Overview ........................................................3 3.1. Introduction ...............................................4 3.2. SCSI Terminology ...........................................6 3.2.1. SCSI Application Layer ..............................6 3.2.2. SCSI Device .........................................6 3.2.3. SCSI Port ...........................................6 3.2.4. SCSI Initiator Device ...............................7 3.2.5. SCSI Initiator Port .................................7 Hallak-Stamler, et al. Standards Track [Page 1] RFC 4455 SCSI MIB April 2006 3.2.6. SCSI Target Device ..................................7 3.2.7. SCSI Target Port ....................................7 3.2.8. Logical Units .......................................7 3.2.9. Logical Unit Number .................................7 3.2.10. Interconnect Subsystem .............................7 3.2.11. Device Server ......................................8 3.2.12. Task Manager .......................................8 3.2.13. SCSI Instance ......................................8 3.3. SCSI MIB Module Implementation .............................8 3.4. Bridging and Virtualization ...............................10 3.5. SCSI Command MIB Module ...................................11 4. Structure of the MIB ...........................................11 4.1. The SCSI Device Group .....................................11 4.2. The Initiator Group .......................................11 4.3. The Target Group ..........................................11 4.4. The Discovery Group .......................................12 4.5. The LUN Map Group .........................................12 4.6. The Target Statistic Group ................................12 4.7. The Target High Speed Statistic Group .....................12 4.8. The LUN Map Statistics Group ..............................12 4.9. The LUN Map Statistics High Speed Group ...................13 4.10. The Initiator Statistics Group ...........................13 4.11. The Initiator High Speed Statistic Group .................13 4.12. The Discovery Statistics Group ...........................13 4.13. The Discovery Statistics High Speed Group ................14 4.14. The Device Statistics Group ..............................14 5. Relationships in This MIB ......................................14 6. Relationship to Other MIBs .....................................16 6.1. Host Resource MIB .........................................16 6.2. iSCSI MIB Module ..........................................16 7. Miscellaneous Details ..........................................16 7.1. Names and Identifiers .....................................16 7.2. Logical Unit Number .......................................16 7.3. Notifications .............................................16 7.4. SCSI Domains ..............................................17 7.5. Counters: 32 Bits and 64 Bits .............................17 7.6. Local versus Remote Entities ..............................18 8. Abbreviations ..................................................18 9. Object Definitions .............................................18 10. Object Population Example: SCSI Target and Initiator Devices on a pSCSI Bus ........................................76 10.1. scsiInstance Table: ......................................77 10.2. scsiDevice Table: ........................................77 10.3. scsiPort Table: ..........................................77 10.4. scsiTransport Table: .....................................77 10.5. scsiIntrDev Table: .......................................78 10.6. scsiInitiatorPort Table: .................................78 10.7. scsiDscTgt Table: ........................................78 Hallak-Stamler, et al. Standards Track [Page 2] RFC 4455 SCSI MIB April 2006 10.8. scsiDscLUN: ..............................................78 10.9. scsiDscLUNIdentifier: ....................................79 10.10. scsiAttTgtPort Table: ...................................79 10.11. scsiTgtDev Table: .......................................79 10.12. scsiTgtPort Table: ......................................80 10.13. scsiLU Table: ...........................................80 10.14. scsiLuId Table: .........................................80 10.15. scsiLunMap Table: .......................................81 10.16. scsiAuthorizedIntr Table: ...............................81 10.17. scsiAttIntrPort Table: ..................................81 11. Security Considerations .......................................81 12. Acknowledgements ..............................................84 13. IANA Considerations ...........................................84 14. References ....................................................84 14.1. Normative References .....................................84 14.2. Informative References ...................................85 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Overview This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects to configure and monitor Small Computer System Interface entities (SCSI entities), i.e., SCSI target devices and SCSI initiator devices and SCSI ports. Hallak-Stamler, et al. Standards Track [Page 3] RFC 4455 SCSI MIB April 2006 SCSI is a client-server protocol in which application clients within a SCSI initiator device (client) issue service requests to logical units contained in a SCSI target device(server). This MIB module is based on documents defined by the ANSI T10 Technical Committee, specifically the SCSI Architecture Model - 2 [SAM2] and SCSI Primary Commands - 2 [SPC2]. The [SAM2] standard is the primary source for the SCSI architecture discussion in this document and the terminology used in this MIB module. 3.1. Introduction In the late 1970s, a firm called Shugart Associates started to have some considerable success with a peripheral interface definition in what became the PC marketplace, and this interface was adopted and extended by an open standards committee to form the Small Computer Systems Interface (SCSI). SCSI defines an 8-bit-wide multi-drop "bus" structure, which could interconnect a total of eight peripherals and computer systems. It is important to realize that initially SCSI standardized only the "physical connection", i.e., the connectors, cables, and interface signals. Thus, even though a peripheral could be connected to multiple systems, the information that flowed across the interface was different in each case. This was addressed some five years later by the definition of a Common Command Set, and with this definition in place it was possible for the first time to develop a peripheral with both a common interface and common operating firmware for connection to multiple systems. The physical interface of SCSI continued to be developed throughout the 1980s with the addition of fast (up to 10 megabytes/s) and wide (16 bits) variants, but the distance supported remained a maximum of 25 meters (from one end of the bus to another), and indeed some of the faster variants supported much less than that distance. The command set development continued, with special commands for tapes, printers, and even processors being added to the original disk- oriented set. So successful was SCSI in the 1980s that the majority of the available Operating Systems incorporated support for the SCSI command set as standard. However, at the end of the 1980s the distance, speed, and number of devices supported by SCSI were starting to become significant impediments to systems design, and although the "information explosion" had not yet started in earnest, it was already being anticipated. At the same time, the serial interface technologies Hallak-Stamler, et al. Standards Track [Page 4] RFC 4455 SCSI MIB April 2006 developed for Local Area Networks such as Ethernet, and the fibre optics technologies that were first deployed in telecommunications applications were starting to appear sufficiently rugged and low cost for use in peripheral interface applications. Thus, a standards project was begun in 1988 to develop a new serial, fibre-optic interface to carry the SCSI command sets and other peripheral protocols. This interface eventually became known as Fibre Channel (FC), and it is based on an architecture centered around an abstractly defined "fabric", which may be a switch or a loop connection. MIB modules for various FC equipments are already in existence. In order to support the new interfaces, it was necessary to completely reorganize the SCSI standards and definitions. The command sets were separated from the physical interface definitions, and a SCSI Architectural Model (SAM) was created to define the interaction between the various standards. It is a key to understanding SAM to realize that it was first created approximately 10 years AFTER the first SCSI products were shipped! The most recent development in this saga occurred in 2000 when an IETF Working Group was formed to address, among other things, a definition for transporting the SCSI command sets directly over a TCP/IP infrastructure. This effort is known as iSCSI [RFC3720], and an iSCSI MIB module is already under development [ISCSI]. Most of the projects are in T10, except Fibre Channel, which is defined by T11 and IEEE defines 1394. The SCSI MIB module represents the SCSI protocol layer common to all SCSI command sets and transports. It does not represent the command sets and transports themselves. These should appear in other MIB modules specific to the transport or command set. The following illustration shows the relationships between the various actual and possible SCSI-related MIB modules. Hallak-Stamler, et al. Standards Track [Page 5] RFC 4455 SCSI MIB April 2006 +---------------------------------+ SCSI Command | Higher-level MIBs, specific to | Sets | command sets, disk, tape, etc. | +---------------------------------+ SCSI | SCSI MIB | +-------+---------+-------+-------+ SCSI | iSCSI | FCP | SPI | Other | Transport | MIB | MIB | MIB | MIBs | Protocols | | | | | +-------+---------+-------+-------+ SCSI | TCP | Fibre | Other | Interconnect | MIB | Channel | Interconnect | | | MIBs | MIBs | +-------+---------+---------------+ An iSCSI MIB module [ISCSI] and a Fibre Channel interconnect MIB module [RFC4044] are currently being developed. No development is currently planned for standard command-set-specific or device- specific MIBs. The TCP-MIB [RFC4022] is already a proposed standard RFC 4022. 3.2. SCSI Terminology The following sections explain some of the SCSI terminology, which is used later in defining the MIB module. For the authoritative definitions of these terms, see SAM-2 [SAM2]. 3.2.1. SCSI Application Layer The protocols and procedures that implement or invoke SCSI commands and task management functions by using services provided by a SCSI transport protocol layer. 3.2.2. SCSI Device A SCSI device is an entity that contains one or more SCSI ports that are connected to a service delivery subsystem and supports a SCSI application protocol. 3.2.3. SCSI Port A SCSI port is a device-resident entity that connects the application client, device server, or task manager to the service delivery subsystem through which requests and responses are routed. A SCSI port is synonymous with port and either a SCSI initiator port or a SCSI target port. Hallak-Stamler, et al. Standards Track [Page 6] RFC 4455 SCSI MIB April 2006 3.2.4. SCSI Initiator Device A SCSI initiator device contains application clients and SCSI initiator ports that originate device service and task management requests to be processed by a SCSI target device. When used, this term refers to SCSI initiator devices or SCSI target/initiator devices that are using the SCSI target/initiator port as a SCSI initiator port. 3.2.5. SCSI Initiator Port A SCSI initiator port acts as the connection between application clients and the service delivery subsystem through which requests and responses are routed. In all cases when this term is used, it refers to an initiator port or a SCSI target/initiator port operating as a SCSI initiator port. 3.2.6. SCSI Target Device A SCSI target device contains logical units and SCSI target ports that receive device service and task management requests for processing. When used, this term refers to SCSI target devices or SCSI target/initiator devices that are using the SCSI target/initiator port as a SCSI target port. 3.2.7. SCSI Target Port A SCSI target port contains a task router and acts as the connection between device servers and task managers and the service delivery subsystem through which requests and responses are routed. When this term is used, it refers to a SCSI target port or a SCSI target/initiator port operating as a SCSI target port. 3.2.8. Logical Units A logical unit is an entity residing in the SCSI target device that implements a device model and processes SCSI commands sent by an application client. 3.2.9. Logical Unit Number A Logical Unit Number or LUN is a 64-bit identifier for a logical unit. 3.2.10. Interconnect Subsystem An interconnect subsystem is one or more interconnects that appear as a single path for the transfer of information between SCSI devices. Hallak-Stamler, et al. Standards Track [Page 7] RFC 4455 SCSI MIB April 2006 3.2.11. Device Server A device server is an object within the logical unit that processes SCSI tasks according to the rules for task management. 3.2.12. Task Manager A task manager is a server within the SCSI target device that processes task management functions. 3.2.13. SCSI Instance A "SCSI instance" is a distinct SCSI entity within a managed system. Whereas most implementations will have just one SCSI instance, the MIB module allows for multiple (virtual) instances, such that a large system can be "partitioned" into multiple, distinct virtual systems. For example, in a host, it allows multiple vendors' implementations of the MIB module to co-exist under a single SNMP agent through each vendor's implementation being a different SCSI instance. It also allows a single SNMP agent to represent multiple subsystems each of which has its own SCSI instance. 3.3. SCSI MIB Module Implementation The SCSI MIB module is a basic building block to use in the various SCSI management scenarios. This module is intended to be implemented in every SCSI entity in a managed system. A SCSI entity can be a SCSI initiator device, SCSI target device or SCSI initiator and Target device. Since SCSI (storage) networking devices may contain more than one SCSI entity, it is possible that more than one SCSI instance will reside in a single device. In small-scale environments, a single network management station (NMS) may have SNMP access to both SCSI initiator devices and SCSI target devices. However, if the SCSI target devices, or virtualized target devices, are being provided as a service, it is more likely that the provider of the service owns and manages the SCSI target devices and that the consumer of the service owns and manages the SCSI initiator devices. In this case, the service provider NMS and the consumer NMS may have only allowed SNMP access to the SCSI target devices and the SCSI initiator devices, respectively. The figures in this chapter describe the location of the SCSI MIB module implementations in the various SCSI management scenarios. The locations of the SCSI SNMP agent implementing the SCSI MIB module are denoted with '*'. Hallak-Stamler, et al. Standards Track [Page 8] RFC 4455 SCSI MIB April 2006 +----------+ +---------+ |SCSI | SCSI Transport |SCSI | |Initiator +---------------------------------------+Target | |Device | |Device | | * | | * | +----------+ +---------+ | | | | | | | | | | | SNMP +----------+ SNMP | +------------------|SCSI |-------------------+ |Management| | (NMS) | +----------+ Figure 1. Single SCSI Initiator Device and Single SCSI Target Device Figure 1 describes a simple SCSI management scenario of a SCSI initiator device, a SCSI target device, and a management station. In this scenario, there are two SNMP agents, each containing its SCSI instance and its respective objects. As the SCSI target device and SCSI initiator device are interconnected, their target and initiator port objects will be complementary. +-----------+ | +--------+-+ SCSI Transport +---------+ | | SCSI |---------------------------------------+ SCSI | |* | Initiator+---------------------------------------+ Target | +--| Device | SCSI Transport | Device | | | * | | * | | +----------+ +---------+ | | | | | | | | | | | | | | | |SNMP | SNMP +----------+ SNMP | +-------+------------------|SCSI |-------------------+ |Management| | (NMS) | +----------+ Figure 2. Multiple Hosts and a Single Target Device Hallak-Stamler, et al. Standards Track [Page 9] RFC 4455 SCSI MIB April 2006 Figure 2 adds another SCSI initiator device, to the SCSI network, which connects to the same SCSI target device. The additional SCSI initiator device also has an SNMP agent implementing the SCSI MIB module. In this case, the SCSI target device's MIB module will show that two SCSI initiator devices are attached to it. +-----------+ +----------+ | +----------+ +---------------+ +-+-------+ | | |SCSI |--------------| Virtualization| | SCSI | | |* |Initiator +--------------| Device +-------+ Target | | +--|Device | SCSI | | | Device | *| | | * | | * | | * |--+ | +----------+ Transport +------------+--+ +---------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | SNMP +-----------+ | SNMP | | +-------+------------------+ SCSI + +-+------------+-------+ | Management| | (NMS) | +-----------+ Figure 3. Multiple Hosts, Virtualization Device and Multiple SCSI Target Devices Figure 3 adds an in-band virtualization device that encapsulates, and possibly modifies, the SCSI target devices' representation to the SCSI Initiator devices. It is common practice for an in-band virtualization device to include both SCSI target and initiator device functionality. Therefore, its SCSI MIB module implementation includes both the SCSI Target device and Initiator device objects. It should be noted that the Virtualization device might implement additional proprietary MIB modules, as the SCSI MIB module does not distinguish between physical and virtual SCSI entities. 3.4. Bridging and Virtualization Storage virtualization is a concept that abstracts storage resources in such a way that, storage entities are provided as pool of logical entities. Usually, the virtualization process is transparent to the storage users (i.e., hosts). Virtualization normally affects the SCSI entities represented to SCSI initiator devices. However, the SCSI MIB module enables the representation of SCSI entities and their respective status, including error and performance-monitoring Hallak-Stamler, et al. Standards Track [Page 10] RFC 4455 SCSI MIB April 2006 statistics. It should be possible to perform a limited number of configuration modification and diagnostic actions. The SCSI entities embodied in the bridging and virtualization devices can be represented by the SCSI MIB module. However, the configuration of bridging and virtualization devices is beyond the above-described scope and therefore should be provided through other MIB modules. 3.5. SCSI Command MIB Module The management of SCSI commands is beyond the scope of this MIB module. Future SCSI Command MIB module can link to this MIB module, through the use of Object Identifiers (OIDs) or INDEX values of appropriate tables. 4. Structure of the MIB This MIB module contains fourteen conformance groups: 4.1. The SCSI Device Group The scsiDeviceGroup group contains the objects general to each SCSI instance: instance, device, and port objects. It contains also the objects referring to the transport(s) used by those SCSI instances. This group is mandatory for all SCSI managed system. Alias objects are provided for SCSI instances and SCSI devices to enable administrators to identify them. These objects contain human-readable administrative text strings, and hence use the SnmpAdminString textual convention from [RFC3411]. 4.2. The Initiator Group The scsiInitiatorDeviceGroup contains all the managed information related to a local SCSI initiator device and port. In addition, it contains the managed objects referring to the monitored attached SCSI target devices. Any managed system acting as a SCSI initiator or target/initiator device and port MUST support this group. 4.3. The Target Group The scsiTargetDeviceGroup contains all the managed objects related to a local SCSI target device, a local SCSI target port, monitored attached initiator ports, logical units, and logical unit identifiers. Hallak-Stamler, et al. Standards Track [Page 11] RFC 4455 SCSI MIB April 2006 Managed systems acting as a SCSI target or target/initiator device and port must support this group. 4.4. The Discovery Group The scsiDiscoveryGroup group is a collection of managed objects referring to remote SCSI target devices, remote SCSI target ports, remote logical units, and remote logical unit identifiers discovered by or configured to a managed system acting as a SCSI initiator device. Managed systems acting as a SCSI initiator device and port and supporting remote SCSI target devices or ports configuration or discovery should implement this group. 4.5. The LUN Map Group The scsiLunMapGroup group is a collection of managed objects allowing mapping between SCSI target devices, logical units, and logical unit numbers in one side to remote authorized SCSI initiator devices or ports in another side. Managed systems supporting this mapping should implement the scsiLunMapGroup. 4.6. The Target Statistic Group The scsiTargetDevStatsGroup group is a collection of managed objects representing various statistics referring to a SCSI target device or port. Managed systems acting as a SCSI target device and port supporting statistics should implement this group. 4.7. The Target High Speed Statistic Group The scsiTargetDevHSStatsGroup group is a collection of managed objects representing various statistics referring to a SCSI target device or port. It provides support for systems that can quickly generate countable information because they run at high speed. Managed systems acting as a SCSI target device and port and running at high speed supporting should implement this group. 4.8. The LUN Map Statistics Group The scsiLunMapStatsGroup group is a collection of managed objects representing various statistics referring to remote authorized SCSI initiator devices or ports. Hallak-Stamler, et al. Standards Track [Page 12] RFC 4455 SCSI MIB April 2006 Managed systems acting as a SCSI target device and port and able to gather statistics on remote SCSI initiator devices or ports should implement this group. 4.9. The LUN Map Statistics High Speed Group The scsiLunMapHSStatsGroup group is a collection of managed objects representing various statistics referring to remote authorized SSCI initiator devices or ports. It provides support for systems that can quickly generate countable information because they run at high speed. Managed systems acting as a SCSI target device and port and able to gather statistics on remote SCSI initiator devices or ports and running at high speed should implement this group. 4.10. The Initiator Statistics Group The scsiInitiatorDevStatsGroup group is a collection of managed objects representing various statistics referring to a SCSI initiator device or port. Managed systems acting as a SCSI initiator device and port supporting statistics should implement this group. 4.11. The Initiator High Speed Statistic Group The scsiInitiatorDevHSStatsGroup group is a collection of managed objects representing various statistics referring to a SCSI initiator device or port. It provides support for systems that can quickly generate countable information because they run at high speed. Managed systems acting as a SCSI initiator device and port and running at high speed supporting should implement this group. 4.12. The Discovery Statistics Group The scsiDiscoveryStatsGroup group is a collection of managed objects representing various statistics referring to remote discovered or configured SCSI target devices or ports. Managed systems acting as a SCSI initiator device and port and able to gather statistics on remote SCSI target devices or ports should implement this group. Hallak-Stamler, et al. Standards Track [Page 13] RFC 4455 SCSI MIB April 2006 4.13. The Discovery Statistics High Speed Group The scsiDiscoveryHSStatsGroup group is a collection of managed objects representing various statistics referring to remote discovered or configured SCSI target devices or ports. It provides support for systems that can quickly generate countable information because they run at high speed. Managed systems acting as a SCSI initiator device and port and able to gather statistics on remote SCSI target devices or ports and running at high speed should implement this group. 4.14. The Device Statistics Group The scsiDeviceStatGroup group is a collection of managed objects representing various statistics referring to a SCSI device. Managed systems able to gather device statistics should implement this group. 5. Relationships in This MIB This section outlines the functionality and the dependency between the MIB tables providing the required management functionality for SCSI initiator and target devices. For specific usage of these tables, the reader should refer to the description of the tables and their respective table entries and attributes. Following is a list of required SCSI initiator-related features, and the respective tables facilitating this functionality: o List all the SCSI initiator ports that should be managed through this MIB module. The table scsiIntrPortTable maintains all the SCSI initiator ports for the SCSI initiator devices in the MIB module. o Provide a list of all SCSI target ports or SCSI target devices to which a SCSI initiator port can attach. This should prevent a SCSI initiator device or port from attaching to SCSI target devices that should be either invisible or inaccessible to it. The entries in this list can be created either manually or by automatic discovery mechanisms (e.g., SLP, iSNS). The ScsiDscTgtTable provides this information. The entries in this table point to the SCSI initiator port, and indicate that the SCSI initiator port can only attach to SCSI target ports or SCSI target devices provided in the respective entries of the ScsiDscTgtTable. Hallak-Stamler, et al. Standards Track [Page 14] RFC 4455 SCSI MIB April 2006 This MIB module permits, but does not require, this table to be written via SNMP. There are significant security considerations in allowing writes to this table; see Section 11. o The information, for the aforementioned SCSI target ports or SCSI target devices, about the LUs and their respective LUN Ids should be provided. The scsiDscLunTable and scsiDscLunIdTable maintain this information. o The scsiAttTgtPortTable provides the information about the SCSI target ports each SCSI initiator port is currently communicating with. This table should be dynamically updated to reflect those connections. Following is a list of required SCSI target device-related features, and the respective tables facilitating this functionality: o List all the SCSI target ports that should be managed through this MIB module. The table scsiTgtPortTable maintains all the SCSI target ports for the SCSI target devices in the MIB module. o Provide a list of valid SCSI initiator ports or SCSI initiator devices authorized to attach to a SCSI target port. This list should feature the concept of "access lists", which are common in IP routers and switches. The ScsiAuthorizedIntr table provides this information. This MIB module permits, but does not require this table to be written via SNMP. There are significant security considerations in allowing writes to this table; see Section 11. o It should be possible to specify the list of LUNs exposed to each SCSI initiator port or device, when it is attached to the SCSI target device. SCSI target devices must provide a default list of LUNs. This list of LUNs can either be a unique list for each SCSI initiator device or be the default list. For each entry in the ScsiAuthorizedIntr table, a pointer, named scsiAuthIntrLunMapIndex, indexing the ScsiLunMapTable facilitates this feature. o Provide means to monitor all the SCSI initiator ports currently attached to this SCSI target port. The scsiAttIntrPortTable provides this information. This table should be dynamically updated to reflect those connections. Hallak-Stamler, et al. Standards Track [Page 15] RFC 4455 SCSI MIB April 2006 6. Relationship to Other MIBs 6.1. Host Resource MIB The SCSI MIB module extends objects defined in the host resource MIB module to SCSI-specific entities but does not contain information on software modules such as device drivers. If MIB objects are required for installed packages of SCSI software, then the hrSWInstalledGroup of the Host Resources MIB [RFC2790] are the standard MIB objects to use. 6.2. iSCSI MIB Module The SCSI MIB module defines managed objects for the SCSI protocol layer. The SCSI layer can run on top of several transport layers; iSCSI is one of them. The ISCSI-MIB [ISCSI] is the MIB portion defining the managed objects for the transport called iSCSI. In the same way, a fibre channel or parallel SCSI MIB module would define managed objects for a transport called, respectively, fibre channel or parallel SCSI. The relationship between the SCSI MIB module and any valid transport MIB module is determined via the SCSI port managed table that has an object pointing to the corresponding row, if any, of the relevant table in a transport MIB module. 7. Miscellaneous Details 7.1. Names and Identifiers The names and the identifiers of the SCSI devices, ports, and logical units depend on the underlying transport protocols; their format and length vary accordingly. Please refer to SAM-2 [SAM2] for more details. 7.2. Logical Unit Number The Logical Unit Number is a 64-bit integer. This type does not exist in SMI and therefore, this MIB contains a textual convention defining LUN as an OCTET STRING. 7.3. Notifications Separate SNMP notifications may be enabled/disabled to notify of a change in any of the SCSI device status variables. A notification will be generated theoretically for each occurrence (see restriction Hallak-Stamler, et al. Standards Track [Page 16] RFC 4455 SCSI MIB April 2006 below) of the abnormal status (e.g., if the SCSI device's current status is abnormal and another logical unit changes its status from available to abnormal another notification will occur). To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing the SCSI MIB module should not send more than three SCSI notifications in any 10-second period. The 3-in-10 rule was chosen because one notification every three seconds was deemed often enough, but if and when two or three different notifications happen at the same time, it would not be desirable to suppress them. Three notifications in 10 seconds is a happy medium, where a short burst of notifications is allowed, without inundating the network and/or destination host with a large number of notifications. The ultimate control on sending of notifications is in command of the notification generator module specified in [RFC3413]. 7.4. SCSI Domains SAM-2 [SAM2] specifies that devices belong to a domain. However, it is not usually possible to determine this from within a system, so domains are not represented within this MIB module. 7.5. Counters: 32 Bits and 64 Bits Some counters, in (newer) high-performance systems, can increase at a fast enough rate such that their representation as Counter32s can cause them to "wrap" in less than an hour. The SMIv2 provides Counter64 as the syntax for such counters. However, (older) SNMPv1 implementations cannot support Counter64s. Thus, this MIB module defines such counters as both Counter32s and Counter64's. The counters in this MIB module that count data are defined in terms of megabytes (i.e., as the number of megabytes of data), such that Counter64s are not required. However, the counters in this MIB module that count commands, when in use at 5 GBit/second with 512-byte read/write operations, could wrap within an hour. Therefore, each of these counters will be defined as both a Counter32 and a Counter64, with the latter being mandatory, for system speeds of 4 Gbit/second or higher. A possible (but not required) implementation strategy is to have the value of each Counter32 be the same value as the low-order 32 bits of the corresponding Counter64. Hallak-Stamler, et al. Standards Track [Page 17] RFC 4455 SCSI MIB April 2006 7.6. Local versus Remote Entities This MIB module qualifies often SCSI entities as local or remote. The local entities are the ones for which the agent is reporting. The remote entities are the ones that the local entities are in communication with via the SCSI protocol. 8. Abbreviations This MIB module will use the following abbreviations: Inst = Instance Dev = SCSI Device Tgt = SCSI Target Device Intr = SCSI Initiator Device Att = Attached Id = Identifier Dsc = Discovered pSCSI = Parallel SCSI 9. Object Definitions SCSI-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, Counter64, Gauge32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TimeStamp, TruthValue, RowStatus, RowPointer, AutonomousType, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; scsiMIB MODULE-IDENTITY LAST-UPDATED "200603300000Z" -- 30th March 2006 ORGANIZATION "IETF" CONTACT-INFO " Michele Hallak-Stamler Hallak-Stamler, et al. Standards Track [Page 18] RFC 4455 SCSI MIB April 2006 Sanrad Intelligent Network 27 Habarzel Street Tel Aviv, Israel Phone: +972 3 7674809 E-mail: michele@sanrad.com Yaron Lederman Siliquent Technologies Ltd. 21 Etzel Street Ramat Gan, Israel Phone: +972 54 5308833 E-mail: yaronled@bezeqint.net Mark Bakke Postal: Cisco Systems, Inc 7900 International Drive, Suite 400 Bloomington, MN USA 55425 E-mail: mbakke@cisco.com Marjorie Krueger Postal: Hewlett-Packard 8000 Foothills Blvd. Roseville, CA 95747 E-mail: marjorie_krueger@hp.com Keith McCloghrie Cisco Systems, Inc. Postal: 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408 526-5260 E-mail: kzm@cisco.com " DESCRIPTION "The SCSI MIB Module. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4455; see the RFC itself for full legal notices." -- Revision History REVISION "200603300000Z" DESCRIPTION " Initial version published as RFC 4455." ::= { mib-2 139} --****************** Textual Conventions ************************** ScsiLUN ::= TEXTUAL-CONVENTION Hallak-Stamler, et al. Standards Track [Page 19] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This textual convention represents a SCSI Logical Unit Number (LUN). The format of a LUN is documented in Tables A.2 and A.3 of SAM-2 [SAM2]." REFERENCE "SCSI Architecture Model-2 (SAM-2), ANSI INCITS 366-2003, T10 Project 1157-D, 12 September 2002 - Annex A [SAM2]" SYNTAX OCTET STRING (SIZE ( 2 | 8)) ScsiIndexValue ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An arbitrary integer value, greater than zero, for use as a unique index value." SYNTAX Unsigned32 (1..4294967295) ScsiPortIndexValueOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the ScsiIndexValue convention. The latter defines a greater than zero value used to identify an index. This extension permits the additional value of zero and is applicable only to indices of SCSI port. Usage of the zero is object-specific and must therefore be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the index was unknown, or when none or all indices need to be referenced." SYNTAX Unsigned32 (0..4294967295) ScsiIndexValueOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the ScsiIndexValue convention. The latter defines a greater than zero value used to identify an index. This extension permits the additional value of zero. Usage of the zero is object-specific and must therefore be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where index was unknown, or when none or all indices need to be referenced." SYNTAX Unsigned32 (0..4294967295) ScsiIdentifier ::= TEXTUAL-CONVENTION Hallak-Stamler, et al. Standards Track [Page 20] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This textual convention represents a generic SCSI port identifier. The format depends on the transport used and is documented in Tables A.2 and A.3 of SAM-2 [SAM2]." REFERENCE "SCSI Architecture Model-2 (SAM-2), ANSI INCITS 366-2003, T10 Project 1157-D, 12 September 2002 - Annex A [SAM2]" SYNTAX OCTET STRING (SIZE (0..262)) ScsiName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention represents the name of a SCSI initiator device, a SCSI target device, a SCSI initiator port or a SCSI target port. The format depends on the transport used and is documented in Tables A.4 and A.5 of SAM-2 [SAM2]. Every object defined using this syntax must define whether it is a) always used for a port, b) always used for a device, or c) the circumstances under which it is used for a port or device." REFERENCE "SCSI Architecture Model-2 (SAM-2), ANSI INCITS 366-2003, T10 Project 1157-D, 12 September 2002 - Annex A [SAM2]" SYNTAX OCTET STRING (SIZE (0..262)) ScsiLuNameOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention represents either the name of a SCSI logical unit or a zero-length string. Objects defined with this syntax must specify the meaning of the zero-length string. The format of the name of a LU is defined as: - a zero-length octet string or - a string of eight bytes." REFERENCE "SCSI Architecture Model-2 (SAM-2), ANSI INCITS 366-2003, T10 Project 1157-D, 12 September 2002 - Annex A [SAM2]" SYNTAX OCTET STRING (SIZE (0 | 8)) ScsiDeviceOrPort ::= TEXTUAL-CONVENTION Hallak-Stamler, et al. Standards Track [Page 21] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This type specifies whether a particular configuration is applicable to a port or to a device." SYNTAX INTEGER { device(1), port(2), other(3) } ScsiIdCodeSet ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention specifies the code set for the identifier contained in an Identification Descriptor returned in a logical unit's Device Identification Page, and is formatted as defined in T10 SPC-2 (see REFERENCE) Table 172 - Code Set" REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" SYNTAX Unsigned32 (0..15) ScsiIdAssociation ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention specifies what the identifier is associated with (e.g., with the addressed physical/logical device or with a particular port) for the identifier contained in an Identification Descriptor returned in a logical unit's Device Identification Page, and is formatted as defined in T10 SPC-2 (see REFERENCE) Table 173 - Association." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" SYNTAX Unsigned32 (0..3) ScsiIdType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention specifies the type for the identifier contained in an Identification Descriptor returned in a Hallak-Stamler, et al. Standards Track [Page 22] RFC 4455 SCSI MIB April 2006 logical unit's Device Identification Page, and is formatted as defined in T10 SPC-2 (see REFERENCE) table 174 - Identifier Type." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" SYNTAX Unsigned32 (0..15) ScsiIdValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention represents an identifier. The objects of type ScsiIdCodeSet, ScsiIdAssociation, ScsiIdType define together the format. The format is the same as contained in an Identification Descriptor returned in a logical unit's Device Identification Page, and is formatted as defined in T10 SPC-2 (see REFERENCE)." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" SYNTAX OCTET STRING (SIZE (0..255)) ScsiHrSWInstalledIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The index value for a software module's row in the Host Resources MIBs hrSWInstalledTable. A zero value indicates that no row in the hrSWInstalledTable is applicable." REFERENCE "hrSWInstalledTable is defined in the Host Resources MIB, [RFC2790]." SYNTAX Integer32 (0..2147483647) --****************** Structure of the MIB ************************** scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 } scsiAdmin OBJECT IDENTIFIER ::= { scsiMIB 1 } scsiObjects OBJECT IDENTIFIER ::= { scsiMIB 2 } scsiConformance OBJECT IDENTIFIER ::= { scsiMIB 3 } scsiTransportTypes OBJECT IDENTIFIER ::= { scsiAdmin 1 } scsiGeneral OBJECT IDENTIFIER ::= { scsiObjects 1 } scsiInitiatorDevice OBJECT IDENTIFIER ::= { scsiObjects 2 } scsiTargetDevice OBJECT IDENTIFIER ::= { scsiObjects 3 } Hallak-Stamler, et al. Standards Track [Page 23] RFC 4455 SCSI MIB April 2006 scsiLogicalUnit OBJECT IDENTIFIER ::= { scsiObjects 4 } --****************** Transport Types ******************************* -- The following object identifiers allow determining the different -- transports (service delivery subsystems) in use under the SCSI -- layer. scsiTransportOther OBJECT-IDENTITY STATUS current DESCRIPTION "This identity identifies a transport that has no identity; it might happen because the transport is unknown or might not have been defined when this MIB module was created." ::= { scsiTransportTypes 1 } scsiTransportSPI OBJECT-IDENTITY STATUS current DESCRIPTION "This identity identifies a parallel SCSI transport." REFERENCE "T10 - SCSI Parallel Interface - 4 (SPI-4) - ANSI INCITS 362-2002 [SPI4]" ::= { scsiTransportTypes 2 } scsiTransportFCP OBJECT-IDENTITY STATUS current DESCRIPTION "This identity identifies a Fibre Channel Protocol for SCSI, Second Version." REFERENCE "T10 - SCSI Fibre Channel Protocol - 2 (FCP-2) - ANSI INCITS 350-2003 [FCP2]" ::= { scsiTransportTypes 3 } scsiTransportSRP OBJECT-IDENTITY STATUS current DESCRIPTION "This identity identifies a protocol for transporting SCSI over Remote Direct Memory Access (RDMA) interfaces, e.g., InfiniBand (tm)." REFERENCE "T10 - SCSI RDMA Protocol (SRP) - ANSI INCITS 365-2002 [SRP]." ::= { scsiTransportTypes 4 } scsiTransportISCSI OBJECT-IDENTITY STATUS current DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 24] RFC 4455 SCSI MIB April 2006 "This identity identifies an iSCSI transport." REFERENCE "IETF IPS WG - Internet Small Computer Systems Interface (iSCSI) [RFC3720] " ::= { scsiTransportTypes 5 } scsiTransportSBP OBJECT-IDENTITY STATUS current DESCRIPTION "This identity identifies the Serial Bus Protocol 3." REFERENCE "T10 - Serial Bus Protocol 3 (SBP-3) - ANSI INCITS 375-2004 [SBP3]." ::= { scsiTransportTypes 6 } scsiTransportSAS OBJECT-IDENTITY STATUS current DESCRIPTION "This identity identifies the Serial Attach SCSI Protocol." REFERENCE "T10 - Serial Attached SCSI - 1.1 (SAS - 1.1) - #1601-D Rev-10 [SAS-1.1]." ::= { scsiTransportTypes 7 } --****************** Instance Table ***************************** scsiInstanceTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of SCSI instances present on the system. The SCSI instance is the top-level entity, to which everything else belongs. An SNMP agent could represent more than one instance if it represents either a stack of devices, or virtual partitions of a larger device, or a host running multiple SCSI implementations from different vendors." ::= { scsiGeneral 1 } scsiInstanceEntry OBJECT-TYPE SYNTAX ScsiInstanceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular SCSI instance." INDEX { scsiInstIndex } ::= { scsiInstanceTable 1 } Hallak-Stamler, et al. Standards Track [Page 25] RFC 4455 SCSI MIB April 2006 ScsiInstanceEntry ::= SEQUENCE { scsiInstIndex ScsiIndexValue, scsiInstAlias SnmpAdminString, scsiInstSoftwareIndex ScsiHrSWInstalledIndexOrZero, scsiInstVendorVersion SnmpAdminString, scsiInstScsiNotificationsEnable TruthValue, scsiInstStorageType StorageType } scsiInstIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents an arbitrary integer used to uniquely identify a particular SCSI instance." ::= { scsiInstanceEntry 1 } scsiInstAlias OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..79)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object represents an administrative string, configured by the administrator. It can be a zero-length string." ::= { scsiInstanceEntry 2 } scsiInstSoftwareIndex OBJECT-TYPE SYNTAX ScsiHrSWInstalledIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "If this management instance corresponds to an installed software module, then this object's value is the value of the hrSWInstalledIndex of that module. If there is no correspondence to an installed software module (or no module that has an hrSWInstalledIndex value), then the value of this object is zero." REFERENCE "hrSWInstalledIndex is defined in the Host Resources MIB, [RFC2790]." ::= { scsiInstanceEntry 3 } scsiInstVendorVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 26] RFC 4455 SCSI MIB April 2006 "This object represents a text string set by the manufacturer describing the version of this instance. The format of this string is determined solely by the manufacturer and is for informational purposes only. It is unrelated to the SCSI specification version numbers." ::= { scsiInstanceEntry 4 } scsiInstScsiNotificationsEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether notifications defined in this MIB module will be generated." DEFVAL { true } ::= { scsiInstanceEntry 5 } scsiInstStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the memory realization for this SCSI entity. Specifically, each row in the following tables: scsiIntrDevTable scsiDscTgtTable scsiAuthorizedIntrTable scsiLunMapTable has a StorageType as specified by the instance of this object that is INDEXed by the same value of scsiInstIndex. This value of this object is also used to indicate the persistence across reboots of writable values in its row of the scsiInstanceTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row, nor to any object belonging to a table whose entry is INDEXed by the same value of scsiInstIndex." DEFVAL { nonVolatile } ::= { scsiInstanceEntry 6 } --******************** Device Table ******************************** scsiDeviceTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiDeviceEntry Hallak-Stamler, et al. Standards Track [Page 27] RFC 4455 SCSI MIB April 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of SCSI devices contained in each of the SCSI manageable instances that this agent is reporting." ::= { scsiGeneral 2 } scsiDeviceEntry OBJECT-TYPE SYNTAX ScsiDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular SCSI device included in this SCSI manageable instance identifiable by the value of scsiInstIndex." INDEX {scsiInstIndex, scsiDeviceIndex} ::= { scsiDeviceTable 1 } ScsiDeviceEntry ::= SEQUENCE { scsiDeviceIndex ScsiIndexValue, scsiDeviceAlias SnmpAdminString, scsiDeviceRole BITS, scsiDevicePortNumber Unsigned32 } scsiDeviceIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an arbitrary integer used to uniquely identify a particular device within a particular SCSI instance." ::= { scsiDeviceEntry 1 } scsiDeviceAlias OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..79)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains an administrative name for this device. If no name is assigned, the value of this object is the zero-length string. The StorageType of this object is specified by the instance of scsiInstStorageType that is INDEXed by the same value of scsiInstIndex." ::= { scsiDeviceEntry 2 } scsiDeviceRole OBJECT-TYPE Hallak-Stamler, et al. Standards Track [Page 28] RFC 4455 SCSI MIB April 2006 SYNTAX BITS { target(0), initiator(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object determines whether this device is acting as a SCSI initiator device, or as a SCSI target device, or as both." ::= { scsiDeviceEntry 3 } scsiDevicePortNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of ports contained in this device." ::= { scsiDeviceEntry 4 } --****************** Port Table ************************************ scsiPortTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of SCSI ports for each SCSI device in each instance." ::= { scsiGeneral 3 } scsiPortEntry OBJECT-TYPE SYNTAX ScsiPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular SCSI port of a particular SCSI device in a particular SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex, scsiPortIndex } ::= { scsiPortTable 1 } ScsiPortEntry ::= SEQUENCE { scsiPortIndex ScsiIndexValue, scsiPortRole BITS, scsiPortTransportPtr RowPointer, scsiPortBusyStatuses Counter32 } Hallak-Stamler, et al. Standards Track [Page 29] RFC 4455 SCSI MIB April 2006 scsiPortIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular port of a given device within a particular SCSI instance." ::= { scsiPortEntry 1 } scsiPortRole OBJECT-TYPE SYNTAX BITS { target(0), initiator(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether this port is acting as a SCSI initiator port, or as a SCSI target port or as both." ::= { scsiPortEntry 2 } scsiPortTransportPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a pointer to the corresponding row in the scsiTransportTable. This row contains information on the transport such as transport type and port name." ::= { scsiPortEntry 3 } scsiPortBusyStatuses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of port busy statuses sent or received by this port. Note: Initiator ports only receive busy status and SCSI target ports only send busy status. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiPortEntry 4 } --******************** Table of supported transports *************** scsiTransportTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiTransportEntry MAX-ACCESS not-accessible Hallak-Stamler, et al. Standards Track [Page 30] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This table contains the device transport-specific information for each transport connected to each device in scsiDeviceTable." ::= { scsiGeneral 5 } scsiTransportEntry OBJECT-TYPE SYNTAX ScsiTransportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing parameters applicable to a transport used by a particular device of a particular SCSI manageable instance." INDEX { scsiInstIndex, scsiDeviceIndex, scsiTransportIndex} ::= { scsiTransportTable 1 } ScsiTransportEntry ::= SEQUENCE { scsiTransportIndex ScsiIndexValue, scsiTransportType AutonomousType, scsiTransportPointer RowPointer, scsiTransportDevName ScsiName } scsiTransportIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular transport within a given device within a particular SCSI instance." ::= { scsiTransportEntry 1 } scsiTransportType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the transport type of this row of the transport table. For example, if this object has the value scsiTransportFCP, then the identified transport is FCP." ::= { scsiTransportEntry 2 } scsiTransportPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only Hallak-Stamler, et al. Standards Track [Page 31] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This object represents a pointer to a conceptual row in a 'transport' MIB module allowing a manager to get useful information for the transport described by this entry. For example, if the transport of this device is iSCSI, this object will point to the iSCSI Instance of the iSCSI MIB module. If there is no MIB for this transport, this object has the value 0.0." ::= { scsiTransportEntry 3 } scsiTransportDevName OBJECT-TYPE SYNTAX ScsiName MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the name of this device in one of the format(s) appropriate for this type of transport." ::= { scsiTransportEntry 4 } --******************** SCSI Initiator Device Table *************** scsiIntrDevTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiIntrDevEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information for each local SCSI initiator device in each instance." ::= { scsiInitiatorDevice 1} scsiIntrDevEntry OBJECT-TYPE SYNTAX ScsiIntrDevEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing information applicable to a SCSI initiator device within a particular SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex } ::= { scsiIntrDevTable 1 } ScsiIntrDevEntry ::= SEQUENCE { scsiIntrDevTgtAccessMode INTEGER, scsiIntrDevOutResets Counter32 } scsiIntrDevTgtAccessMode OBJECT-TYPE SYNTAX INTEGER { Hallak-Stamler, et al. Standards Track [Page 32] RFC 4455 SCSI MIB April 2006 unknown(1), autoEnable(2), manualEnable(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls whether or not a discovered SCSI target device is immediately authorized: - autoEnable (2) means that when a SCSI initiator device discovers a SCSI target device, it can use it immediately. - manualEnable (3) means that the SCSI initiator device must wait for an operator to set scsiIntrDscTgtConfigured = true before it is authorized. The StorageType of this object is specified by the instance of scsiInstStorageType that is INDEXed by the same value of scsiInstIndex." ::= { scsiIntrDevEntry 1 } scsiIntrDevOutResets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the total number of times that this SCSI initiator device has issued - a LOGICAL UNIT RESET or TARGET RESET task management request, or - any other SCSI transport protocol-specific action or event that causes a Logical Unit Reset or a Hard Reset at one or more SCSI target ports ([SAM2] chapters 5.9.6, 5.9.7). Discontinuities in the value of this counter can occur at re- initialization of the management system." REFERENCE "SCSI Architecture Model-2 (SAM-2), ANSI INCITS 366-2003, T10 Project 1157-D, 12 September 2002 Chapters 5.9.6 & 5.9.7 [SAM2]" ::= { scsiIntrDevEntry 2 } -- The following section describes managed objects related to -- SCSI initiator ports. scsiIntrPortTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiIntrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 33] RFC 4455 SCSI MIB April 2006 "This table contains all the SCSI initiator ports for each local SCSI initiator or target/initiator devices in each SCSI instance." ::= { scsiInitiatorDevice 2 } scsiIntrPortEntry OBJECT-TYPE SYNTAX ScsiIntrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing information applicable to a particular SCSI initiator port of a particular SCSI device within a SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex, scsiPortIndex } ::= { scsiIntrPortTable 1 } ScsiIntrPortEntry ::= SEQUENCE { scsiIntrPortName ScsiName, scsiIntrPortIdentifier ScsiIdentifier, scsiIntrPortOutCommands Counter32, scsiIntrPortWrittenMegaBytes Counter32, scsiIntrPortReadMegaBytes Counter32, scsiIntrPortHSOutCommands Counter64 } scsiIntrPortName OBJECT-TYPE SYNTAX ScsiName MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the name of the port assigned for use by the SCSI protocol. The format will depend on the type of transport this port is using." ::= { scsiIntrPortEntry 1 } scsiIntrPortIdentifier OBJECT-TYPE SYNTAX ScsiIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the identifier of the port in one of the format(s) appropriate for the type of transport in use." ::= { scsiIntrPortEntry 2 } scsiIntrPortOutCommands OBJECT-TYPE SYNTAX Counter32 UNITS "commands" Hallak-Stamler, et al. Standards Track [Page 34] RFC 4455 SCSI MIB April 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands sent by this SCSI initiator port. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiIntrPortEntry 3 } scsiIntrPortWrittenMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the amount of data in megabytes sent by this SCSI initiator port. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiIntrPortEntry 4 } scsiIntrPortReadMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the amount of data in megabytes received by this SCSI initiator port. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiIntrPortEntry 5 } scsiIntrPortHSOutCommands OBJECT-TYPE SYNTAX Counter64 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands sent by this SCSI initiator port. This object provides support for systems that can quickly generate a large number of commands because they run at high speed. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiIntrPortEntry 6 } Hallak-Stamler, et al. Standards Track [Page 35] RFC 4455 SCSI MIB April 2006 --******************** Discovered SCSI Target Device group ******** scsiRemoteTgtDev OBJECT IDENTIFIER ::= { scsiInitiatorDevice 3 } -- SCSI target device discovered or authorized to attach each of the -- SCSI initiator ports of each SCSI initiator device of each -- instance. scsiDscTgtTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiDscTgtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes all the remote (not in the local system) SCSI target ports that are authorized to attach to each local SCSI initiator port of this SCSI instance." ::= { scsiRemoteTgtDev 1 } scsiDscTgtEntry OBJECT-TYPE SYNTAX ScsiDscTgtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry (row) contains information about the SCSI target device or port to which this SCSI initiator port (or all SCSI initiator ports in the SCSI initiator entry indexed by scsiInstIndex, scsiDeviceIndex) will attempt to attach. The entry is either for all local ports (if scsiDscTgtIntrPortIndex is zero) or only for the specific SCSI initiator port identified by scsiDscTgtIntrPortIndex. Note that if an entry in this table is deleted, any corresponding entries in the scsiDscLunsTable must be deleted as well. The StorageType of a row in this table is specified by the instance of scsiInstStorageType that is INDEXed by the same value of scsiInstIndex." INDEX { scsiInstIndex, scsiDeviceIndex, scsiDscTgtIntrPortIndex, scsiDscTgtIndex } ::= { scsiDscTgtTable 1 } ScsiDscTgtEntry ::= SEQUENCE { scsiDscTgtIntrPortIndex ScsiPortIndexValueOrZero, scsiDscTgtIndex ScsiIndexValue, scsiDscTgtDevOrPort ScsiDeviceOrPort, scsiDscTgtName ScsiName, scsiDscTgtConfigured TruthValue, scsiDscTgtDiscovered TruthValue, scsiDscTgtInCommands Counter32, scsiDscTgtWrittenMegaBytes Counter32, scsiDscTgtReadMegaBytes Counter32, Hallak-Stamler, et al. Standards Track [Page 36] RFC 4455 SCSI MIB April 2006 scsiDscTgtHSInCommands Counter64, scsiDscTgtLastCreation TimeStamp, scsiDscTgtRowStatus RowStatus } scsiDscTgtIntrPortIndex OBJECT-TYPE SYNTAX ScsiPortIndexValueOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object relates to a particular local device within a particular SCSI instance and specifies - the index of the local SCSI initiator port, - or zero, if this entry refers to the local device and therefore refers to all the local SCSI initiator ports." ::= { scsiDscTgtEntry 1 } scsiDscTgtIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an arbitrary integer used to uniquely identify a particular SCSI target device either discovered by, or configured for use with, one or more ports scsiDscTgtName of a particular device within a particular SCSI instance." ::= { scsiDscTgtEntry 2 } scsiDscTgtDevOrPort OBJECT-TYPE SYNTAX ScsiDeviceOrPort MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether this entry describes a configured SCSI target device name (and applies to all ports on the identified SCSI target device) or an individual SCSI target port." ::= { scsiDscTgtEntry 3 } scsiDscTgtName OBJECT-TYPE SYNTAX ScsiName MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the name of this configured or discovered SCSI target device or port depending on the value of scsiDscTgtDevOrPort." ::= { scsiDscTgtEntry 4 } Hallak-Stamler, et al. Standards Track [Page 37] RFC 4455 SCSI MIB April 2006 scsiDscTgtConfigured OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object means -true(1): this entry has been configured by an administrator. -false(2): this entry has been added from a discovery mechanism (e.g., SendTargets, SLP, iSNS). An administrator can modify this value from false to true." DEFVAL { true } ::= { scsiDscTgtEntry 5 } scsiDscTgtDiscovered OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object means -true(1): this entry has been discovered by the SCSI instance as result of an automatic discovery process. -false(2):this entry has been added by manual configuration. This entry is read-only because an administrator cannot change it. Note that it is an implementation decision to determine how long to retain a row with configured=false, such as when the SCSI target device is no longer visible/accessible to the local SCSI initiator device." ::= { scsiDscTgtEntry 6 } scsiDscTgtInCommands OBJECT-TYPE SYNTAX Counter32 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands received from this SCSI target port or device. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiDscTgtLastCreation." ::= { scsiDscTgtEntry 7 } scsiDscTgtWrittenMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current Hallak-Stamler, et al. Standards Track [Page 38] RFC 4455 SCSI MIB April 2006 DESCRIPTION "This object represents the amount of megabytes of data sent as the result of WRITE commands to this SCSI target port or device. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiDscTgtLastCreation." ::= { scsiDscTgtEntry 8 } scsiDscTgtReadMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the amount of megabytes received as the result of READ commands to this SCSI target port or device. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiDscTgtLastCreation." ::= { scsiDscTgtEntry 9 } scsiDscTgtHSInCommands OBJECT-TYPE SYNTAX Counter64 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands received by this SCSI target port or device. This object provides support for system that can quickly generate a large number of commands because they run at high speed. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiDscTgtLastCreation." ::= { scsiDscTgtEntry 10 } scsiDscTgtLastCreation OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the value of sysUpTime when this row was created." ::= { scsiDscTgtEntry 11 } scsiDscTgtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Hallak-Stamler, et al. Standards Track [Page 39] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This object allows an administrator to configure dynamically a new entry in this table via SNMP or eventually delete it. An administrator is not allowed to delete an entry for which the value of the object scsiIntrDscTgtDiscovered is equal to true. Note that when an entry in this table is deleted, then any corresponding entries in the scsiDscLunsTable must also be automatically deleted. A newly created row cannot be made active until a value has been set for scsiDscTgtName. In this case, the value of the corresponding instance of the scsiDscTgtRowStatus column will stay 'notReady'. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { scsiDscTgtEntry 12 } --********************** LUNs discovered *************************** scsiDscLunTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiDscLunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes all the remote (not in the local system) logical unit numbers (LUNs) discovered via each local SCSI initiator port of each local device within a particular SCSI instance." ::= { scsiRemoteTgtDev 2 } scsiDscLunEntry OBJECT-TYPE SYNTAX ScsiDscLunEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) represents a discovered LUN at a particular SCSI target device (scsiDscTgtIndex), where the LUN was discovered by a particular local SCSI initiator device within a particular SCSI instance, possibly via a particular local SCSI initiator port. Note that when an entry in the scsiDscTgtTable is deleted, all corresponding entries in this table should automatically be deleted." Hallak-Stamler, et al. Standards Track [Page 40] RFC 4455 SCSI MIB April 2006 INDEX { scsiInstIndex, scsiDeviceIndex, scsiDscTgtIntrPortIndex, scsiDscTgtIndex, scsiDscLunIndex } ::= { scsiDscLunTable 1 } ScsiDscLunEntry ::= SEQUENCE { scsiDscLunIndex ScsiIndexValue, scsiDscLunLun ScsiLUN } scsiDscLunIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an arbitrary integer used to uniquely identify a particular LUN discovered by a particular SCSI initiator port or a particular SCSI initiator device within a particular SCSI instance. Entries in the scsiDscLunIdTable are associated with a LUN by having the value of this object in their INDEX." ::= { scsiDscLunEntry 1 } scsiDscLunLun OBJECT-TYPE SYNTAX ScsiLUN MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the Logical Unit Number (LUN) of the discovered logical unit." ::= { scsiDscLunEntry 2 } --******************** LU Identifiers discovered ******************* scsiDscLunIdTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiDscLunIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes all the known LU identifiers of the remote (not in the local system) logical units discovered via each local SCSI initiator port or device of this SCSI instance." ::= { scsiRemoteTgtDev 3 } scsiDscLunIdEntry OBJECT-TYPE SYNTAX ScsiDscLunIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 41] RFC 4455 SCSI MIB April 2006 "An entry (row) represents the LU identifier of a discovered LUN at a particular SCSI target device (scsiDscTgtIndex), where the LUN was discovered by a particular local SCSI initiator device within a particular SCSI instance, possibly via a particular local SCSI initiator port." INDEX { scsiInstIndex, scsiDeviceIndex, scsiDscTgtIntrPortIndex, scsiDscTgtIndex, scsiDscLunIndex, scsiDscLunIdIndex } ::= { scsiDscLunIdTable 1 } ScsiDscLunIdEntry ::= SEQUENCE { scsiDscLunIdIndex ScsiIndexValue, scsiDscLunIdCodeSet ScsiIdCodeSet, scsiDscLunIdAssociation ScsiIdAssociation, scsiDscLunIdType ScsiIdType, scsiDscLunIdValue ScsiIdValue } scsiDscLunIdIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an arbitrary integer used to uniquely identify a particular LUN identifier discovered by each SCSI initiator device or particular SCSI initiator port within a particular SCSI instance." ::= { scsiDscLunIdEntry 1 } scsiDscLunIdCodeSet OBJECT-TYPE SYNTAX ScsiIdCodeSet MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the code set in use with this identifier. The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiDscLunIdEntry 2 } scsiDscLunIdAssociation OBJECT-TYPE SYNTAX ScsiIdAssociation MAX-ACCESS read-only STATUS current DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 42] RFC 4455 SCSI MIB April 2006 "This object specifies what the identifier is associated with (e.g., with the addressed physical/logical device or with a particular port). The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiDscLunIdEntry 3 } scsiDscLunIdType OBJECT-TYPE SYNTAX ScsiIdType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the type of the identifier. The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiDscLunIdEntry 4 } scsiDscLunIdValue OBJECT-TYPE SYNTAX ScsiIdValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the actual value of this identifier. The format is defined by the objects scsiDscLunIdCodeSet, scsiDscLunIdAssociation, scsiDscLunIdType. The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiDscLunIdEntry 5 } --***** Table of SCSI Target Device Attached to local SCSI --***** Initiator Ports scsiAttTgtPortTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiAttTgtPortEntry MAX-ACCESS not-accessible Hallak-Stamler, et al. Standards Track [Page 43] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This table includes all the remote (not in the local system) SCSI target ports that are currently attached to each local SCSI initiator port of this SCSI instance." ::= { scsiRemoteTgtDev 4 } scsiAttTgtPortEntry OBJECT-TYPE SYNTAX ScsiAttTgtPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) represents a remote SCSI target port (scsiAttTgtPortIndex) currently attached to a particular SCSI initiator port (scsiPortIndex) of a particular SCSI initiator device within a particular SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex, scsiPortIndex, scsiAttTgtPortIndex } ::= { scsiAttTgtPortTable 1 } ScsiAttTgtPortEntry ::= SEQUENCE { scsiAttTgtPortIndex ScsiIndexValue, scsiAttTgtPortDscTgtIdx ScsiIndexValueOrZero, scsiAttTgtPortName ScsiName, scsiAttTgtPortIdentifier ScsiIdentifier } scsiAttTgtPortIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular SCSI target currently attached to a particular SCSI initiator port of a particular SCSI initiator device within a particular SCSI instance." ::= { scsiAttTgtPortEntry 1 } scsiAttTgtPortDscTgtIdx OBJECT-TYPE SYNTAX ScsiIndexValueOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of the scsiDscTgtIntrPortIndex index variable for the row in the scsiDscTgtTable representing this currently attached SCSI target port. If the currently attached SCSI target port is not represented in the scsiDscTgtTable, then the value of this object is zero." Hallak-Stamler, et al. Standards Track [Page 44] RFC 4455 SCSI MIB April 2006 ::= { scsiAttTgtPortEntry 2 } scsiAttTgtPortName OBJECT-TYPE SYNTAX ScsiName MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the name of the attached SCSI target port." ::= { scsiAttTgtPortEntry 3 } scsiAttTgtPortIdentifier OBJECT-TYPE SYNTAX ScsiIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the identifier of the attached SCSI target port." ::= { scsiAttTgtPortEntry 4 } -- ***************************************************************** -- ***** Table of SCSI Target devices -- scsiTgtDevTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiTgtDevEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about each local SCSI target device." ::= { scsiTargetDevice 1 } scsiTgtDevEntry OBJECT-TYPE SYNTAX ScsiTgtDevEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing information applicable to a particular local SCSI target device within a particular SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex } ::= { scsiTgtDevTable 1 } ScsiTgtDevEntry ::= SEQUENCE { scsiTgtDevNumberOfLUs Gauge32, scsiTgtDeviceStatus INTEGER, scsiTgtDevNonAccessibleLUs Gauge32, scsiTgtDevResets Counter32 Hallak-Stamler, et al. Standards Track [Page 45] RFC 4455 SCSI MIB April 2006 } scsiTgtDevNumberOfLUs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the number of logical units accessible via this local SCSI target device." ::= { scsiTgtDevEntry 1 } scsiTgtDeviceStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), available(2), broken(3), readying(4), abnormal(5), nonAddrFailure(6), nonAddrFailReadying(7), nonAddrFailAbnormal(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the status of this SCSI device, summarizing the state of both the addressable devices (i.e., the logical units) and the non-addressable devices within this SCSI device: - unknown(1): This value is used when the status cannot be determined - available(2): All addressable and non-addressable devices within the SCSI device are fully operational (i.e., no logical units have an abnormal status). - broken(3): The SCSI device is not operational and cannot be made operational without external intervention. - readying(4): One or more logical units within the SCSI device are being initialized and access to the SCSI device is temporarily limited (i.e., one or more of the logical units have a readying status). - abnormal(5): One or more addressable devices within the SCSI device are indicating a status other than available; nevertheless, the SCSI device is operational (i.e., one or more of the logical units have an abnormal status). - nonAddrFailure(6): One or more non-addressable devices within the SCSI device have failed; nevertheless, the SCSI device is operational (i.e., no logical units have an abnormal or readying status). Hallak-Stamler, et al. Standards Track [Page 46] RFC 4455 SCSI MIB April 2006 - nonAddrFailReadying(7): One or more non-addressable devices within the SCSI device have failed; nevertheless, one or more logical units within the SCSI device are being initialized and access to the SCSI device is temporarily limited. - nonAddrFailAbnormal(8): One or more non-addressable devices within the SCSI device have failed and one or more addressable devices within the SCSI device are indicating a status other than available; however, the SCSI device is operational. " REFERENCE "SCSI Controller Commands-2 (SCC-2) ANSI INCITS 318-1998 6.3.1.8 REPORT STATES service action [SCC2]" ::= { scsiTgtDevEntry 2} scsiTgtDevNonAccessibleLUs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the number of logical units existing but not currently accessible via this local SCSI target device." ::= { scsiTgtDevEntry 3 } scsiTgtDevResets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of hard resets encountered by this SCSI target device. Discontinuities in the value of this counter can occur at re- initialization of the management system." REFERENCE "SCSI Architecture Model-2 (SAM-2), ANSI INCITS 366-2003, T10 Project 1157-D, 12 September 2002 - Chapter 5.9.7 [SAM2]" ::= { scsiTgtDevEntry 4 } --******************** SCSI Target Port Table ********************* scsiTgtPortTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiTgtPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes all the local SCSI target ports of all the local SCSI target devices." Hallak-Stamler, et al. Standards Track [Page 47] RFC 4455 SCSI MIB April 2006 ::= { scsiTargetDevice 2 } scsiTgtPortEntry OBJECT-TYPE SYNTAX ScsiTgtPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing information applicable to a particular local SCSI target port of a particular local SCSI target device within a particular SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex, scsiPortIndex} ::= { scsiTgtPortTable 1 } ScsiTgtPortEntry ::= SEQUENCE { scsiTgtPortName ScsiName, scsiTgtPortIdentifier ScsiIdentifier, scsiTgtPortInCommands Counter32, scsiTgtPortWrittenMegaBytes Counter32, scsiTgtPortReadMegaBytes Counter32, scsiTgtPortHSInCommands Counter64 } scsiTgtPortName OBJECT-TYPE SYNTAX ScsiName MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the name of the port assigned for use in the SCSI protocol." ::= { scsiTgtPortEntry 1 } scsiTgtPortIdentifier OBJECT-TYPE SYNTAX ScsiIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the identifier of the port in one of the format(s) appropriate for the type of transport." ::= { scsiTgtPortEntry 2 } scsiTgtPortInCommands OBJECT-TYPE SYNTAX Counter32 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands received by this SCSI target port. Hallak-Stamler, et al. Standards Track [Page 48] RFC 4455 SCSI MIB April 2006 Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiTgtPortEntry 3 } scsiTgtPortWrittenMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the amount of data written in megabytes by this SCSI target port. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiTgtPortEntry 4 } scsiTgtPortReadMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the amount of data read in megabytes by this SCSI target port. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiTgtPortEntry 5 } scsiTgtPortHSInCommands OBJECT-TYPE SYNTAX Counter64 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands received. This object provides support for systems that can quickly generate a large number of commands because they run at high speed. Discontinuities in the value of this counter can occur at re- initialization of the management system." ::= { scsiTgtPortEntry 6 } scsiRemoteIntrDev OBJECT IDENTIFIER ::= { scsiTargetDevice 3 } -- The scsiAuthorizedIntrTable contains the list of remote initiator -- ports that are authorized to be attached to specific SCSI target -- ports and on which an administrator would like to keep permanent -- information and long term statistics even when not currently -- attached. Hallak-Stamler, et al. Standards Track [Page 49] RFC 4455 SCSI MIB April 2006 scsiAuthorizedIntrTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiAuthorizedIntrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes all the authorized SCSI initiator devices or ports that may attach a SCSI target device (ScsiAuthIntrTgtPortIndex = 0) or port (ScsiAuthIntrTgtPortIndex different than 0) of the local SCSI instance. Statistics are kept for each such authorization; thus, the authorizations should be configured in the manner that will cause the desired set of statistics to be collected and that will determine the correct LUN map." ::= { scsiRemoteIntrDev 1 } scsiAuthorizedIntrEntry OBJECT-TYPE SYNTAX ScsiAuthorizedIntrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) represents a remote SCSI initiator port or remote SCSI initiator device that may attach to the local SCSI target port or device within a particular SCSI instance. The StorageType of a row in this table is specified by the instance of scsiInstStorageType that is INDEXed by the same value of scsiInstIndex." INDEX { scsiInstIndex, scsiDeviceIndex, scsiAuthIntrTgtPortIndex, scsiAuthIntrIndex } ::= { scsiAuthorizedIntrTable 1 } ScsiAuthorizedIntrEntry ::= SEQUENCE { scsiAuthIntrTgtPortIndex ScsiPortIndexValueOrZero, scsiAuthIntrIndex ScsiIndexValue, scsiAuthIntrDevOrPort ScsiDeviceOrPort, scsiAuthIntrName ScsiName, scsiAuthIntrLunMapIndex ScsiIndexValueOrZero, scsiAuthIntrAttachedTimes Counter32, scsiAuthIntrOutCommands Counter32, scsiAuthIntrReadMegaBytes Counter32, scsiAuthIntrWrittenMegaBytes Counter32, scsiAuthIntrHSOutCommands Counter64, scsiAuthIntrLastCreation TimeStamp, scsiAuthIntrRowStatus RowStatus } scsiAuthIntrTgtPortIndex OBJECT-TYPE SYNTAX ScsiPortIndexValueOrZero Hallak-Stamler, et al. Standards Track [Page 50] RFC 4455 SCSI MIB April 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains either the index of the port or zero, to indicate any port, on the particular local SCSI target device." ::= { scsiAuthorizedIntrEntry 1 } scsiAuthIntrIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an arbitrary integer used to uniquely identify a SCSI initiator device or port that is authorized to attach to a particular local SCSI target device or port of a particular SCSI instance." ::= { scsiAuthorizedIntrEntry 2 } scsiAuthIntrDevOrPort OBJECT-TYPE SYNTAX ScsiDeviceOrPort MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies whether this entry refers to a remote SCSI initiator port or to a SCSI initiator device. A value of device(1) means that the authorized remote initiator is a SCSI initiator device and includes all of its ports. A value of port(2) means that the authorized remote initiator is a SCSI initiator port." ::= { scsiAuthorizedIntrEntry 3 } scsiAuthIntrName OBJECT-TYPE SYNTAX ScsiName MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the name of the remote SCSI initiator device or port authorized by this row." ::= { scsiAuthorizedIntrEntry 4 } scsiAuthIntrLunMapIndex OBJECT-TYPE SYNTAX ScsiIndexValueOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the set of entries in the scsiLunMapTable for which scsiLunMapIndex has the same value as the value of this object. The identified set of entries Hallak-Stamler, et al. Standards Track [Page 51] RFC 4455 SCSI MIB April 2006 constitutes the LUN map to be used for accessing logical units when the remote SCSI initiator port or device corresponding to this entry is attached to any local SCSI target port or device corresponding to this entry. Note that this object has a value of zero if this entry should use the default LUN map." ::= { scsiAuthorizedIntrEntry 5 } scsiAuthIntrAttachedTimes OBJECT-TYPE SYNTAX Counter32 UNITS "Times" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the number of times that this remote SCSI initiator device or port has transitioned from unattached to attached to this local SCSI target device or port. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiAuthIntrLastCreation." ::= { scsiAuthorizedIntrEntry 6 } scsiAuthIntrOutCommands OBJECT-TYPE SYNTAX Counter32 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the number of commands that the remote SCSI initiator device or port corresponding to this entry has sent to the local SCSI target device or port corresponding to this entry. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiAuthIntrLastCreation." ::= { scsiAuthorizedIntrEntry 7 } scsiAuthIntrReadMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the amount of data in megabytes that the remote SCSI initiator device or port corresponding to this entry has read from the local SCSI target device or port corresponding to this entry. Discontinuities in the value of this counter can occur at re- Hallak-Stamler, et al. Standards Track [Page 52] RFC 4455 SCSI MIB April 2006 initialization of the management system, and at other times as indicated by the value of scsiAuthIntrLastCreation." ::= { scsiAuthorizedIntrEntry 8 } scsiAuthIntrWrittenMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the amount of data in megabytes that the remote SCSI initiator device or port corresponding to this entry has written to the local SCSI target device or port corresponding to this entry. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiAuthIntrLastCreation." ::= { scsiAuthorizedIntrEntry 9} scsiAuthIntrHSOutCommands OBJECT-TYPE SYNTAX Counter64 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands sent by the remote SCSI initiator device or port corresponding to this entry to the local SCSI target device or port corresponding to this entry. This object provides support for systems that can quickly generate a large number of commands because they run at high speed. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiAuthIntrLastCreation." ::= { scsiAuthorizedIntrEntry 10 } scsiAuthIntrLastCreation OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the value of sysUpTime when this row was last created." ::= { scsiAuthorizedIntrEntry 11 } scsiAuthIntrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Hallak-Stamler, et al. Standards Track [Page 53] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This object allows an administrator to create or delete this entry. A newly created row cannot be made active until a value has been set for scsiAuthIntrName. In this case, the value of the corresponding instance of the scsiAuthIntrRowStatus column will stay 'notReady'. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { scsiAuthorizedIntrEntry 12 } -- Table of SCSI initiator devices or ports attached to local -- SCSI target ports -- scsiAttIntrPortTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiAttIntrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes all the remote SCSI initiator ports that are currently attached to a local SCSI target port of all local devices within all SCSI instances." ::= { scsiRemoteIntrDev 2 } scsiAttIntrPortEntry OBJECT-TYPE SYNTAX ScsiAttIntrPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) represents a remote SCSI initiator port currently attached to a particular local SCSI target port of a particular SCSI target device of a particular SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex, scsiPortIndex, scsiAttIntrPortIndex } ::= { scsiAttIntrPortTable 1 } ScsiAttIntrPortEntry ::= SEQUENCE { scsiAttIntrPortIndex ScsiIndexValue, scsiAttIntrPortAuthIntrIdx ScsiIndexValueOrZero, scsiAttIntrPortName ScsiName, scsiAttIntrPortIdentifier ScsiIdentifier } Hallak-Stamler, et al. Standards Track [Page 54] RFC 4455 SCSI MIB April 2006 scsiAttIntrPortIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents an arbitrary integer used to uniquely identify a particular attached remote initiator port to a particular SCSI target port within a particular SCSI target device within a particular SCSI instance." ::= { scsiAttIntrPortEntry 1 } scsiAttIntrPortAuthIntrIdx OBJECT-TYPE SYNTAX ScsiIndexValueOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the corresponding index in the scsiAuthorizedIntrTable for this current attached remote SCSI initiator device or zero if this remote attached SCSI initiator device is not configured in that table." ::= { scsiAttIntrPortEntry 2 } scsiAttIntrPortName OBJECT-TYPE SYNTAX ScsiName MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the name of the remote SCSI initiator device attached to this local SCSI target port." ::= { scsiAttIntrPortEntry 3 } scsiAttIntrPortIdentifier OBJECT-TYPE SYNTAX ScsiIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the identifier of the remote SCSI initiator device attached to this local SCSI target port." ::= { scsiAttIntrPortEntry 4 } --****************** Managed Objects regarding logical units ******* scsiLuTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiLuEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the logical units exposed by local SCSI target devices. Hallak-Stamler, et al. Standards Track [Page 55] RFC 4455 SCSI MIB April 2006 It includes attributes for the World Wide Name (WWN), scsiLuVendorId, scsiLuProductId, and scsiLuRevisionId, which may also appear in the scsiLuIdTable. If an implementation exposes a WWN as a LuIdTable entry, it must match the scsiLuWwnName in this table. If an implementation exposes a (vendor, product, revision) identifier as an LuIdTable entry, each of these fields must match the scsiLuVendorId, scsiLuProductId, and scsiLuRevisionId attributes in this table." ::= { scsiLogicalUnit 1 } scsiLuEntry OBJECT-TYPE SYNTAX ScsiLuEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) contains information applicable to a particular logical unit of a particular local SCSI target device within a particular SCSI instance." INDEX { scsiInstIndex, scsiDeviceIndex, scsiLuIndex} ::= { scsiLuTable 1 } ScsiLuEntry ::= SEQUENCE { scsiLuIndex ScsiIndexValue, scsiLuDefaultLun ScsiLUN, scsiLuWwnName ScsiLuNameOrZero, scsiLuVendorId SnmpAdminString, scsiLuProductId SnmpAdminString, scsiLuRevisionId SnmpAdminString, scsiLuPeripheralType Unsigned32, scsiLuStatus INTEGER, scsiLuState BITS, scsiLuInCommands Counter32, scsiLuReadMegaBytes Counter32, scsiLuWrittenMegaBytes Counter32, scsiLuInResets Counter32, scsiLuOutTaskSetFullStatus Counter32, scsiLuHSInCommands Counter64, scsiLuLastCreation TimeStamp } scsiLuIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents an arbitrary integer used to uniquely identify a particular logical unit within a particular SCSI target device within a particular SCSI instance." Hallak-Stamler, et al. Standards Track [Page 56] RFC 4455 SCSI MIB April 2006 ::= { scsiLuEntry 1 } scsiLuDefaultLun OBJECT-TYPE SYNTAX ScsiLUN MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the default Logical Unit Number (LUN) for this logical unit; if a SCSI initiator device has not been configured to view this logical unit via an entry in the ScsiLunMapTable, the LU will be visible as scsiLuDefaultLun. If this logical unit does not have a default LUN, it will only be visible if specified via the ScsiLunMapTable, and this object will contain a zero-length string." ::= { scsiLuEntry 2 } scsiLuWwnName OBJECT-TYPE SYNTAX ScsiLuNameOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the World Wide Name of this LU that is the device identifier of the Vital Product Data (VPD) page name; if there is no WWN for this LU, this object will contain a zero-length string. If there is more than one identifier, they will be listed in the scsiLuIdTable and this object will contain a zero-length string." ::= { scsiLuEntry 3 } scsiLuVendorId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents a string identifying the vendor of this LU as reported in the Standard INQUIRY data." ::= { scsiLuEntry 4 } scsiLuProductId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents a string identifying the product for this LU as reported in the Standard INQUIRY data." ::= { scsiLuEntry 5 } scsiLuRevisionId OBJECT-TYPE Hallak-Stamler, et al. Standards Track [Page 57] RFC 4455 SCSI MIB April 2006 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents a string defining the product revision of this LU as reported in the Standard INQUIRY data." ::= { scsiLuEntry 6 } scsiLuPeripheralType OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the value returned by SCSI Standard INQUIRY data. It can be: direct-access device, sequential-access device, printer, communication device and so on. The values that can be returned here are defined in SCSI Primary Commands -2." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001,11 July 2001 [SPC2]- Table 48." ::= { scsiLuEntry 7 } scsiLuStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), available(2), notAvailable(3), broken(4), readying(5), abnormal(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the status of this logical unit: - unknown(1): The status of this logical unit cannot be determined. - available(2): The logical unit is fully operational (i.e., accepts media access SCSI commands and has no state information to report). - notAvailable(3): The logical unit is capable of being supported but is not available (i.e., no logical unit is currently present or the logical unit is present but not configured for use). - broken(4): The logical unit has failed and cannot respond to SCSI commands. - readying(5): The logical unit is being initialized and Hallak-Stamler, et al. Standards Track [Page 58] RFC 4455 SCSI MIB April 2006 access is temporarily limited. - abnormal(6): The logical unit has state information available that indicates it is operating with limits. The scsiLuState indicates what those limits are. " REFERENCE "SCSI Controller Commands-2 (SCC-2) ANSI INCITS 318-1998 6.3.1.8 REPORT STATES service action [SCC2]" ::= { scsiLuEntry 8 } scsiLuState OBJECT-TYPE SYNTAX BITS { dataLost(0), dynamicReconfigurationInProgress(1), exposed(2), fractionallyExposed(3), partiallyExposed(4), protectedRebuild(5), protectionDisabled(6), rebuild(7), recalculate(8), spareInUse(9), verifyInProgress(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the state of a logical unit and its meaning according to the bit position: 0 Data lost: Within the logical unit data has been lost. 1 Dynamic reconfiguration in progress: The logical unit is being reconfigured. In this state all data is still protected. 2 Exposed: Within the logical unit data is not protected. In this state all data is still valid; however, loss of data or data availability is unavoidable in the event of a failure. 3 Fractionally exposed: Within the logical unit part of the data is not protected. In this state all data is still valid; however, a failure may cause a loss of data or a loss of data availability. 4 Partially exposed: Within the logical unit one or more underlying storage devices have failed. In this state all data is still protected. 5 Protected rebuild: The logical unit is in the process of a rebuild operation. In this state all data is protected. 6 Protection disabled: Within the logical unit the data Hallak-Stamler, et al. Standards Track [Page 59] RFC 4455 SCSI MIB April 2006 protection method has been disabled. In this state all data is still valid; however, loss of data or data availability is unavoidable in the event of a failure. 7 Rebuild: The data protection method is in the process of rebuilding data. In this state data is not protected. 8 Recalculate: The logical unit is in the process of a recalculate operation. 9 Spare in use: Within the logical unit a storage device in full or part is being used to store data. In this state all data is still protected. 10 Verify in progress: Within the logical unit data is being verified." REFERENCE "SCSI Controller Commands-2 (SCC-2) ANSI INCITS 318-1998 6.3.1.8 REPORT STATES service action [SCC2]" ::= { scsiLuEntry 9 } scsiLuInCommands OBJECT-TYPE SYNTAX Counter32 UNITS "commands" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of commands received by this logical unit. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiLuLastCreation." ::= { scsiLuEntry 10 } scsiLuReadMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the amount of data in megabytes read from this logical unit. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiLuLastCreation." ::= { scsiLuEntry 11 } scsiLuWrittenMegaBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Megabytes" MAX-ACCESS read-only Hallak-Stamler, et al. Standards Track [Page 60] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "This object represents the amount of data in megabytes written to this logical unit. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiLuLastCreation." ::= { scsiLuEntry 12 } scsiLuInResets OBJECT-TYPE SYNTAX Counter32 UNITS "resets" MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of times that this logical unit received - a LOGICAL UNIT RESET or TARGET RESET task management request, or - any other SCSI transport protocol-specific action or event that causes a Logical Unit Reset or a Hard Reset at a SCSI target port of the containing device ([SAM2] Chapters 5.9.6, 5.9.7). Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiLuLastCreation." REFERENCE "SCSI Architecture Model-2 (SAM-2), ANSI INCITS 366-2003, T10 Project 1157-D, 12 September 2002 - Chapter 5.9.7 [SAM2]" ::= { scsiLuEntry 13 } scsiLuOutTaskSetFullStatus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the number of Task Set full statuses issued for this logical unit. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiLuLastCreation." ::= { scsiLuEntry 14 } scsiLuHSInCommands OBJECT-TYPE SYNTAX Counter64 UNITS "commands" MAX-ACCESS read-only STATUS current Hallak-Stamler, et al. Standards Track [Page 61] RFC 4455 SCSI MIB April 2006 DESCRIPTION "This object represents the number of commands received by this logical unit. This object provides support for systems that can quickly generate a large number of commands because they run at high speed. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of scsiLuLastCreation." ::= { scsiLuEntry 15 } scsiLuLastCreation OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the value of sysUpTime when this row was last created." ::= { scsiLuEntry 16 } --****************** Logical Unit Identifier Table ***************** scsiLuIdTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiLuIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of identifiers for all logical units exposed by the local SCSI target device." ::= { scsiLogicalUnit 2 } scsiLuIdEntry OBJECT-TYPE SYNTAX ScsiLuIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing information applicable to a particular identifier for a particular logical unit of a particular SCSI target device within a particular SCSI instance." INDEX {scsiInstIndex, scsiDeviceIndex, scsiLuIndex, scsiLuIdIndex} ::= { scsiLuIdTable 1 } ScsiLuIdEntry ::= SEQUENCE { scsiLuIdIndex ScsiIndexValue, scsiLuIdCodeSet ScsiIdCodeSet, scsiLuIdAssociation ScsiIdAssociation, scsiLuIdType ScsiIdType, scsiLuIdValue ScsiIdValue } Hallak-Stamler, et al. Standards Track [Page 62] RFC 4455 SCSI MIB April 2006 scsiLuIdIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents an arbitrary integer used to uniquely identify a particular LU identifier within a particular logical unit within a particular SCSI target device within a particular SCSI instance." ::= { scsiLuIdEntry 1 } scsiLuIdCodeSet OBJECT-TYPE SYNTAX ScsiIdCodeSet MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the code set in use with this identifier. The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001 Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiLuIdEntry 2 } scsiLuIdAssociation OBJECT-TYPE SYNTAX ScsiIdAssociation MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies what the identifier is associated with (e.g., with the addressed physical/logical device or with a particular port). The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001, Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiLuIdEntry 3 } scsiLuIdType OBJECT-TYPE SYNTAX ScsiIdType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the type of the identifier. Hallak-Stamler, et al. Standards Track [Page 63] RFC 4455 SCSI MIB April 2006 The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001, Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiLuIdEntry 4 } scsiLuIdValue OBJECT-TYPE SYNTAX ScsiIdValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the actual value of this identifier. The format is defined by the objects scsiLuIdCodeSet, scsiLuIdAssociation, scsiLuIdType. The value is represented in the same format as is contained in the identifier's Identification Descriptor within the logical unit's Device Identification Page." REFERENCE "ANSI - SCSI Primary Commands - 2 (SPC-2), ANSI INCITS 351-2001, 11 July 2001, Chapter 8: section 8.4.4, Vital Product Data Parameters [SPC2]" ::= { scsiLuIdEntry 5 } --******************* The LUN Map Table **************************** scsiLunMapTable OBJECT-TYPE SYNTAX SEQUENCE OF ScsiLunMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides the ability to present a logical unit using different Logical Unit Numbers for different SCSI initiator devices. This table provides a mapping between a logical unit and a Logical Unit Number, and can be referenced by a ScsiAuthorizedIntrEntry to specify the LUN map for that initiator." ::= { scsiLogicalUnit 3 } scsiLunMapEntry OBJECT-TYPE SYNTAX ScsiLunMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information about the mapping of a Hallak-Stamler, et al. Standards Track [Page 64] RFC 4455 SCSI MIB April 2006 particular logical unit to a particular LUN. The set of entries that all have the same values of scsiInstIndex, scsiDeviceIndex and scsiLunMapIndex constitutes a LUN map within a particular SCSI instance. The StorageType of a row in this table is specified by the instance of scsiInstStorageType that is INDEX-ed by the same value of scsiInstIndex." INDEX { scsiInstIndex, scsiDeviceIndex, scsiLunMapIndex, scsiLunMapLun} ::= { scsiLunMapTable 1 } ScsiLunMapEntry ::= SEQUENCE { scsiLunMapIndex ScsiIndexValue, scsiLunMapLun ScsiLUN, scsiLunMapLuIndex ScsiIndexValue, scsiLunMapRowStatus RowStatus } scsiLunMapIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents an arbitrary integer used to uniquely identify a particular LunMap within a particular SCSI target device within a particular SCSI instance." ::= { scsiLunMapEntry 1 } scsiLunMapLun OBJECT-TYPE SYNTAX ScsiLUN MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the Logical Unit Number, to which a logical unit is mapped by this row." ::= { scsiLunMapEntry 2 } scsiLunMapLuIndex OBJECT-TYPE SYNTAX ScsiIndexValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the logical unit for which the value of scsiLuIndex is the same as the value of this object. The identified logical unit is the one mapped to a LUN by this row." ::= { scsiLunMapEntry 3 } Hallak-Stamler, et al. Standards Track [Page 65] RFC 4455 SCSI MIB April 2006 scsiLunMapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows an administrator to create and delete this entry." ::= { scsiLunMapEntry 4 } --********************** Notifications ****************************** -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 2 } scsiNotificationsPrefix OBJECT IDENTIFIER ::= { scsiNotifications 0 } scsiTgtDeviceStatusChanged NOTIFICATION-TYPE OBJECTS { scsiTgtDeviceStatus } STATUS current DESCRIPTION "This notification will be generated for each occurrence of the abnormal status (e.g., if the SCSI target device's current status is abnormal) providing that the SCSI instance's value of scsiInstScsiNotificationsEnable is enabled. An SNMP agent implementing the SCSI MIB module should not send more than three SCSI identical notifications in any 10-second period." ::= { scsiNotificationsPrefix 1 } scsiLuStatusChanged NOTIFICATION-TYPE OBJECTS { scsiLuStatus } STATUS current DESCRIPTION "This notification will be generated each time that scsiLuStatus changes providing that the SCSI instance's value of scsiInstScsiNotificationsEnable is enabled. An SNMP agent implementing the SCSI MIB module should not send more than three SCSI identical notifications in any 10-second period." ::= { scsiNotificationsPrefix 2 } --****************************************************************** -- The next part defines the conformance groups in use -- for SCSI MIB module. scsiCompliances OBJECT IDENTIFIER ::= { scsiConformance 1 } scsiCompliance MODULE-COMPLIANCE Hallak-Stamler, et al. Standards Track [Page 66] RFC 4455 SCSI MIB April 2006 STATUS current DESCRIPTION "Describes the requirements for compliance to this SCSI MIB module. If an implementation can be both a SCSI target device and a SCSI initiator device, all groups are mandatory." MODULE -- this module MANDATORY-GROUPS { scsiDeviceGroup } OBJECT scsiInstAlias MIN-ACCESS read-only DESCRIPTION "Write access is not mandatory." OBJECT scsiInstScsiNotificationsEnable MIN-ACCESS read-only DESCRIPTION "Write access is not mandatory." OBJECT scsiDeviceAlias MIN-ACCESS read-only DESCRIPTION "Write access is not mandatory." OBJECT scsiInstStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- Conditionally mandatory groups to be included with -- the mandatory groups when the implementation has -- SCSI target device. GROUP scsiTargetDeviceGroup DESCRIPTION "This group is mandatory for all SCSI implementations that have SCSI target devices." GROUP scsiLunMapGroup DESCRIPTION "This group is mandatory for systems having the capabilities of mapping local SCSI target devices and logical units according to remote SCSI initiator devices." OBJECT scsiAuthIntrDevOrPort MIN-ACCESS read-only DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 67] RFC 4455 SCSI MIB April 2006 "Write access is not required." OBJECT scsiAuthIntrName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT scsiAuthIntrLunMapIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT scsiAuthIntrRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." GROUP scsiTgtDevLuNotificationsGroup DESCRIPTION "This group is mandatory for all SCSI implementations that have SCSI target devices and are able to report status changes." -- Conditionally mandatory groups to be included with -- the mandatory groups when the implementation has -- SCSI initiator device. GROUP scsiInitiatorDeviceGroup DESCRIPTION "This group is mandatory for all SCSI implementations that have SCSI initiator devices." OBJECT scsiIntrDevTgtAccessMode MIN-ACCESS read-only DESCRIPTION "Write access is not mandatory." GROUP scsiDiscoveryGroup DESCRIPTION "This group is mandatory for systems having the capabilities of discovering remote SCSI target devices via local SCSI initiator devices." OBJECT scsiLunMapLuIndex MIN-ACCESS read-only Hallak-Stamler, et al. Standards Track [Page 68] RFC 4455 SCSI MIB April 2006 DESCRIPTION "Write access is not mandatory." OBJECT scsiLunMapRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT scsiDscTgtDevOrPort MIN-ACCESS read-only DESCRIPTION "Write access is not mandatory." OBJECT scsiDscTgtName MIN-ACCESS read-only DESCRIPTION "Write access is not mandatory." OBJECT scsiDscTgtConfigured SYNTAX TruthValue { false(2) } MIN-ACCESS read-only DESCRIPTION "The value of true(1) is not mandatory neither is the write access." OBJECT scsiDscTgtRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- Conditionally mandatory groups to be included with the mandatory -- groups when the implementation can gather statistics. GROUP scsiDeviceStatGroup DESCRIPTION "This group is mandatory for all SCSI implementations that can gather statistics." -- Conditionally mandatory groups to be included with the mandatory -- groups when the implementation can gather statistics at the SCSI -- initiator device side. GROUP scsiInitiatorDevStatsGroup Hallak-Stamler, et al. Standards Track [Page 69] RFC 4455 SCSI MIB April 2006 DESCRIPTION "This group is mandatory for all SCSI implementations that can gather statistics at SCSI initiator device side." GROUP scsiDiscoveryStatsGroup DESCRIPTION "This group is mandatory for system having the capabilities of gathering statistics regarding remote SCSI target devices via local SCSI initiator devices." -- Conditionally mandatory groups to be included with the mandatory -- groups when the implementation can gather statistics at the SCSI -- target side. GROUP scsiTargetDevStatsGroup DESCRIPTION "This group is mandatory for all SCSI implementations that can gather statistics at SCSI target devices." GROUP scsiLunMapStatsGroup DESCRIPTION "This group is mandatory for SCSI implementations able to map local SCSI target devices and logical units according to remote SCSI initiator devices." -- Conditionally mandatory groups to be included with the mandatory -- groups when the implementation is running at high speed and can -- gather statistics at the SCSI initiator device side. GROUP scsiInitiatorDevHSStatsGroup DESCRIPTION "This group is mandatory for all SCSI implementations that can gather statistics at the SCSI initiator device side and are running at high speed, meaning speed of 4 Gbit/second or higher." GROUP scsiDiscoveryHSStatsGroup DESCRIPTION "This group is mandatory for systems having the capabilities of gathering statistics regarding remote SCSI target devices via local SCSI initiator devices and are running at high speed, meaning speed of 4 Gbit/second or higher." -- Conditionally mandatory groups to be included with the mandatory -- groups when the implementation is running at high speed and can -- gather statistics at the SCSI target side. GROUP scsiTargetDevHSStatsGroup DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 70] RFC 4455 SCSI MIB April 2006 "This group is mandatory for all SCSI implementations that can gather statistics at SCSI target devices in high speed systems, meaning speed of 4 Gbit/second or higher." GROUP scsiLunMapHSStatsGroup DESCRIPTION "This group is mandatory for SCSI implementations able to map local SCSI target devices and logical units according to remote SCSI initiator devices in a high speed system, meaning speed of 4 Gbit/second or higher." ::= { scsiCompliances 1 } scsiGroups OBJECT IDENTIFIER ::= { scsiConformance 2 } scsiDeviceGroup OBJECT-GROUP OBJECTS { scsiInstAlias, scsiInstSoftwareIndex, scsiInstVendorVersion, scsiInstScsiNotificationsEnable, scsiInstStorageType, scsiDeviceAlias, scsiDeviceRole, scsiDevicePortNumber, scsiPortRole, scsiPortTransportPtr, scsiTransportType, scsiTransportPointer, scsiTransportDevName } STATUS current DESCRIPTION "A collection of objects providing information about SCSI instances, devices, and ports." ::= { scsiGroups 1 } scsiInitiatorDeviceGroup OBJECT-GROUP OBJECTS { scsiIntrDevTgtAccessMode, scsiIntrPortName, scsiIntrPortIdentifier, scsiAttTgtPortDscTgtIdx, scsiAttTgtPortName, scsiAttTgtPortIdentifier } STATUS current DESCRIPTION "This group is relevant for s SCSI initiator device and port." Hallak-Stamler, et al. Standards Track [Page 71] RFC 4455 SCSI MIB April 2006 ::= { scsiGroups 2 } scsiDiscoveryGroup OBJECT-GROUP OBJECTS { scsiDscTgtDevOrPort, scsiDscTgtName, scsiDscTgtConfigured, scsiDscTgtDiscovered, scsiDscTgtRowStatus, scsiDscTgtLastCreation, scsiDscLunLun, scsiDscLunIdCodeSet, scsiDscLunIdAssociation, scsiDscLunIdType, scsiDscLunIdValue } STATUS current DESCRIPTION "This group is relevant for the discovered SCSI target devices by a SCSI initiator port." ::= { scsiGroups 3 } scsiTargetDeviceGroup OBJECT-GROUP OBJECTS { scsiTgtDevNumberOfLUs, scsiTgtDeviceStatus, scsiTgtDevNonAccessibleLUs, scsiTgtPortName, scsiTgtPortIdentifier, scsiAttIntrPortAuthIntrIdx, scsiAttIntrPortName, scsiAttIntrPortIdentifier, scsiLuDefaultLun, scsiLuWwnName, scsiLuVendorId, scsiLuProductId, scsiLuRevisionId, scsiLuPeripheralType, scsiLuStatus, scsiLuState, scsiLuLastCreation, scsiLuIdCodeSet, scsiLuIdAssociation, scsiLuIdType, scsiLuIdValue } STATUS current DESCRIPTION Hallak-Stamler, et al. Standards Track [Page 72] RFC 4455 SCSI MIB April 2006 "This group is relevant for a SCSI target device and port." ::= { scsiGroups 4 } scsiLunMapGroup OBJECT-GROUP OBJECTS { scsiLunMapLuIndex, scsiLunMapRowStatus, scsiAuthIntrDevOrPort, scsiAuthIntrName, scsiAuthIntrLunMapIndex, scsiAuthIntrLastCreation, scsiAuthIntrRowStatus } STATUS current DESCRIPTION "This group is a collection of attributes regarding the mapping between Logical Unit Number, logical unit, and target device." ::= { scsiGroups 5} scsiTargetDevStatsGroup OBJECT-GROUP OBJECTS { scsiTgtDevResets, scsiTgtPortInCommands, scsiTgtPortWrittenMegaBytes, scsiTgtPortReadMegaBytes, scsiLuInCommands, scsiLuReadMegaBytes, scsiLuWrittenMegaBytes, scsiLuInResets, scsiLuOutTaskSetFullStatus } STATUS current DESCRIPTION "This group is a collection of statistics for all implementations of the SCSI MIB module that contain SCSI target devices." ::= { scsiGroups 6} scsiTargetDevHSStatsGroup OBJECT-GROUP OBJECTS { scsiTgtPortHSInCommands, scsiLuHSInCommands } STATUS current DESCRIPTION "This group is a collection of high speed statistics for all implementations of the SCSI MIB module that contain SCSI target devices." Hallak-Stamler, et al. Standards Track [Page 73] RFC 4455 SCSI MIB April 2006 ::= { scsiGroups 7} scsiLunMapStatsGroup OBJECT-GROUP OBJECTS { scsiAuthIntrAttachedTimes, scsiAuthIntrOutCommands, scsiAuthIntrReadMegaBytes, scsiAuthIntrWrittenMegaBytes } STATUS current DESCRIPTION "This group is a collection of statistics regarding SCSI initiator devices authorized to attach local logical unit and SCSI target device." ::= { scsiGroups 8} scsiLunMapHSStatsGroup OBJECT-GROUP OBJECTS { scsiAuthIntrHSOutCommands } STATUS current DESCRIPTION "This group is a collection of high speed statistics regarding SCSI initiator devices authorized to attach local logical unit and SCSI target device." ::= { scsiGroups 9} scsiInitiatorDevStatsGroup OBJECT-GROUP OBJECTS { scsiIntrDevOutResets, scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes, scsiIntrPortReadMegaBytes } STATUS current DESCRIPTION "This group is a collection of statistics for all implementations of the SCSI MIB module that contain SCSI initiator devices." ::= { scsiGroups 10} scsiInitiatorDevHSStatsGroup OBJECT-GROUP OBJECTS { scsiIntrPortHSOutCommands } STATUS current DESCRIPTION "This group is a collection of high speed statistics for all Hallak-Stamler, et al. Standards Track [Page 74] RFC 4455 SCSI MIB April 2006 implementations of the SCSI MIB module that contain SCSI initiator devices." ::= { scsiGroups 11} scsiDiscoveryStatsGroup OBJECT-GROUP OBJECTS { scsiDscTgtInCommands, scsiDscTgtReadMegaBytes, scsiDscTgtWrittenMegaBytes } STATUS current DESCRIPTION "This group is a collection of statistics for all implementations of the SCSI MIB module that contain discovered SCSI initiator devices." ::= { scsiGroups 12} scsiDiscoveryHSStatsGroup OBJECT-GROUP OBJECTS { scsiDscTgtHSInCommands } STATUS current DESCRIPTION "This group is a collection of high speed statistics for all implementations of the SCSI MIB module that contain discovered SCSI initiator devices." ::= { scsiGroups 13} scsiDeviceStatGroup OBJECT-GROUP OBJECTS { scsiPortBusyStatuses } STATUS current DESCRIPTION "A collection of statistics regarding SCSI devices and ports." ::= { scsiGroups 14 } scsiTgtDevLuNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { scsiTgtDeviceStatusChanged, scsiLuStatusChanged } STATUS current DESCRIPTION "A collection of notifications regarding status change of SCSI target devices and logical units." ::= { scsiGroups 15 } Hallak-Stamler, et al. Standards Track [Page 75] RFC 4455 SCSI MIB April 2006 END 10. Object Population Example: SCSI Target and Initiator Devices on a pSCSI Bus This section provides a sample set of values for a parallel SCSI scenario in which a SCSI MIB module can be implemented. The example shown below is not a normative part of this document and makes some assumptions about the underlying implementation, which are not based on actual implementations. The respective sections describe the sequence of object instantiations and attempts to explain non-typical values for attributes that are unique to the scenario. Note: While populating the objects, the population of statistics is not considered. This scenario deals with a SCSI target and initiator devices attached to a parallel SCSI bus, defined by one of the SCSI-3 Parallel Interface standards (the version referenced in the MIB module is the 4th generation, called SPI-4). We assume that the SCSI initiator device is a Host Bus Adaptor (HBA), and the SCSI target device is a physical disk. We assume that the SCSI target device has one integrated logical unit, identified by a Logical Unit Number (LUN) of 0, which is the default LUN. The parallel SCSI transport only supports port identifiers, and not port names. The transport pointer is set to 0 since there is no MIB module defined for SPI-4. We assume an HBA as the SCSI initiator device and a disk as the SCSI target device. We assume that the SCSI target device has one logical unit, addressed by Logical Unit Number set to 0 (LUN0), which is the default LUN. Parallel SCSI has only port identifiers, no port names. The transport pointer for parallel SCSI is set to 0 since there is no reference transport (SPI) MIB module. Once the SCSI system is initialized, an SNMP agent should be able to view the values of variables populated in the ScsiDevice, ScsiInitiatorDevice, ScsiTargetDevice, ScsiPort, ScsiTargetPort, ScsiInitiatorPort, ScsiLogicalUnit, ScsiLUIdentifier objects. The ScsiAuthorizedIntr population depends on the transport and the implementation. As this example scenario is parallel SCSI, we deal with the ports. Hence the ScsiPortIndexOrZero is the index of the SCSI target port and ScsiAuthIntrDevOrPort is "port". Same is the case with the variables in scsiDscTgtDevOrPort. Note that "" means zero-length string. Hallak-Stamler, et al. Standards Track [Page 76] RFC 4455 SCSI MIB April 2006 10.1. scsiInstance Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiInstAlias "pSCSI-1" scsiInstSoftwareIndex 1000 scsiInstVendorVersion "1.0a" scsiInstScsiNotificationsEnable true scsiInstStorageType nonVolatile 10.2. scsiDevice Table: Attribute Value ---------- ------ scsiInstIndex 1 1 scsiDeviceIndex 1 2 scsiDeviceAlias "pSCSI-HBA" "pSCSI-Disk1" scsiDeviceRole initiator(1) target(0) scsiDevicePortNumber 1 1 10.3. scsiPort Table: Attribute Value ---------- ------ scsiInstIndex 1 1 scsiDeviceIndex 1 2 scsiPortIndex 1 2 scsiPortRole initiator(1) target(0) scsiPortTransportPtr 1 2 10.4. scsiTransport Table: Attribute Value ---------- ------ scsiInstIndex 1 1 scsiDeviceIndex 1 2 scsiTransportIndex 1 2 scsiTransportType scsiTransportSPI scsiTransportSPI scsiTransportPointer 0.0 0.0 scsiTransportDevName "" "" Hallak-Stamler, et al. Standards Track [Page 77] RFC 4455 SCSI MIB April 2006 10.5. scsiIntrDev Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 1 scsiIntrDevTgtAccessMode autoEnable(2) 10.6. scsiInitiatorPort Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 1 scsiPortIndex 1 scsiIntrPortName "" scsiIntrPortIdentifier *1 0001b *1 Port Identifier for SCSI is represented by 4 bits. 10.7. scsiDscTgt Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 1 scsiDscTgtIntrPortIndex 1 scsiDscTgtIndex 1 scsiDscTgtDevOrPort port(2) scsiDscTgtName "" scsiDscTgtConfigured false(2) scsiDscTgtDiscovered true(1) scsiDscTgtRowStatus active(1) 10.8. scsiDscLUN: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 1 scsiDscTgtIntrPortIndex 1 scsiDscTgtIndex 1 scsiDscLunIndex 1 scsiDscLunLun 0 Hallak-Stamler, et al. Standards Track [Page 78] RFC 4455 SCSI MIB April 2006 10.9. scsiDscLUNIdentifier: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 1 scsiDscLunIndex 1 scsiDscLunIdIndex 1 scsiDscLunIdCodeSet *1 2 scsiDscLunIdAssociation *2 1 scsiDscLunIdType *3 1 scsiDscLunIdValue ASPENsl318203-001 *1 - The identifier field will have ASCII graphic codes. *2 - The identifier is associated with the port that received the request. *3 - As defined in SPC. (This value specifies that the scsiDscLunIdValue contains a vendorID in the first 8 bytes concatenated with the product identifier field and product serial number.) 10.10. scsiAttTgtPort Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 1 scsiPortIndex 1 scsiAttTgtPortIndex 1 scsiAttTgtPortDscTgtIdx 1 scsiAttTgtPortName "" scsiAttTgtPortId 0011b 10.11. scsiTgtDev Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 2 scsiTgtDevNumberOfLUs 1 scsiTgtDeviceStatus available(2) scsiTgtDevNonAccessibleLUs 0 Hallak-Stamler, et al. Standards Track [Page 79] RFC 4455 SCSI MIB April 2006 10.12. scsiTgtPort Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 2 scsiPortIndex 2 scsiPortName "" scsiTgtPortIdentifier 0010b 10.13. scsiLU Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 2 scsiLuIndex 1 scsiLuDefaultLun 0 scsiLuWwnName "" scsiLuVendorId "xyz-corp" scsiLuProductId "super turbo disk" scsiRevisionId 02 scsiLUPeripheralType 00 scsiLUStatus available(2) scsiLuState exposed(3) 10.14. scsiLuId Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 2 scsiLuIndex 1 scsiLuIdIndex 1 scsiLuIdCodeSet *1 2 scsiLuIdAssociation *2 1 scsiLuIdType *3 1 scsiLuIdValue ASPENsl318203-0004 *1 - The identifier field will have ASCII graphic codes. *2 - The identifier is associated with the port that received the request. *3 - As defined in SPC. (This value specifies that the LuIdValue contains a vendorID in the first 8 bytes concatenated with the product identifier field and product serial number.) Hallak-Stamler, et al. Standards Track [Page 80] RFC 4455 SCSI MIB April 2006 10.15. scsiLunMap Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 2 scsiLunMapIndex 1 scsiLunMapLun 0 scsiLunMapLuIndex 1 scsiLunMapLunRowStatus active(1) 10.16. scsiAuthorizedIntr Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 2 scsiAuthIntrTgtPortIndex 2 scsiAuthIntrIndex 1 scsiAuthIntrDevOrPort port(2) scsiAuthIntrName "" scsiAuthIntrLunMapIndex 1 scsiAuthIntrRowStatus active(1) 10.17. scsiAttIntrPort Table: Attribute Value ---------- ------ scsiInstIndex 1 scsiDeviceIndex 2 scsiPortIndex 2 scsiAttIntrPortIdx 1 scsiAttIntrPortAuthIntrIdx 1 scsiAttIntrPortName "" scsiAttIntrPortIdentifier 0011b 11. Security Considerations There are a number of management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the following: o scsiInstAlias, scsiInstScsiNotificationsEnable, scsiInstStorageType and scsiDeviceAlias: these objects can be manipulated to affect the management of a SCSI instance and its Hallak-Stamler, et al. Standards Track [Page 81] RFC 4455 SCSI MIB April 2006 devices; specifically, the SCSI instance's administrative alias, whether it generates notifications, whether its non-default parameter settings are retained over restarts, and the administrative alias for each of its devices. o scsiIntrDevTgtAccessMode: this object can be manipulated to allow immediate access by local SCSI initiator devices to discovered SCSI target devices without waiting for administrator approval, where such approval might not be forthcoming. o scsiDscTgtTable: the objects in this table can be manipulated to remove administrator-specified controls on access by local SCSI initiator devices to discovered SCSI target devices. o scsiAuthorizedIntrTable: the objects in this table can be manipulated to remove administrator-specified controls on access by remote SCSI initiator devices to local SCSI target devices. o scsiLunMapTable: the objects in this table can be manipulated to provide access by a remote SCSI initiator device to logical units that an administrator has configured as not accessible to said initiator. In each of the last four cases, the objects in the tables can also be manipulated to cause a denial of service attack, by preventing administrator-authorized access. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. All seventeen of the tables in this MIB module contain information which might be considered sensitive to read access in some environments, e.g., o the settings of all read-write/read-create parameter objects mentioned above, o scsiInstSoftwareIndex, scsiInstVendorVersion --which version of which software is running; o scsiDeviceRole, scsiPortRole, scsiTransportType, scsiTransportPointer, scsiTransportDevName, scsiDscLunIdCodeSet, scsiDscLunIdAssociation, scsiDscLunIdType, scsiDscLunIdValue plus information in several tables: scsiTgtDevTable, scsiLuTable, scsiLuIdTable, scsiLunMapTable Hallak-Stamler, et al. Standards Track [Page 82] RFC 4455 SCSI MIB April 2006 --topology information indicating which devices/ports are targets, about the transport protocols they use, and more specific information about such targets, including detailed information about the LUNs they expose and how they are mapped onto logical units; o scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes, scsiIntrPortReadMegaBytes, scsiIntrPortHSOutCommands scsiDscTgtInCommands, scsiDscTgtWrittenMegaBytes, scsiDscTgtReadMegaBytes, scsiDscTgtHSInCommands, scsiTgtPortInCommands, scsiTgtPortWrittenMegaBytes, scsiTgtPortReadMegaBytes, scsiTgtPortHSInCommands, scsiAuthIntrAttachedTimes, scsiAuthIntrOutCommands, scsiAuthIntrReadMegaBytes, scsiAuthIntrWrittenMegaBytes, scsiAuthIntrHSOutCommands, scsiLuInCommands, scsiLuReadMegaBytes, scsiLuWrittenMegaBytes, scsiLuHSInCommands -- statistics that could be used for traffic analysis. o scsiAttTgtPortTable -- information on which initiators are connected to which targets that could be used for traffic analysis. o scsiAuthorizedIntrTable and scsiAttIntrPortTable tables -- information about which initiators are authorized to connect to that targets. These information may need to be kept private in sensitive environments. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Hallak-Stamler, et al. Standards Track [Page 83] RFC 4455 SCSI MIB April 2006 12. Acknowledgements This document is the result of the work of the SCSI MIB Group. In particular, the contributions of Sajay Selvaraj (HCL Technologies), George Penokie (IBM), and Roger Cummings (Veritas Software) were critical to the formulation of this specification. 13. IANA Considerations IANA has made a MIB OID assignment under the mib-2 branch for the SCSI-MIB. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [SAM2] ANSI INCITS 366-2003, "SCSI Architecture Model-2 (SAM-2)", SAM-2 Revision 24, September 2002. [SPC2] ANSI INCITS 351-2001, "SCSI Primary Commands - 2 (SPC-2)", SPC-2 Revision 20, July 2001. Hallak-Stamler, et al. Standards Track [Page 84] RFC 4455 SCSI MIB April 2006 14.2. Informative References [FCP2] ANSI INCITS 350-2003, "Fibre Channel Protocol for SCSI (FCP-2)", FCP-2 Revision 08, September 2002. [ISCSI] Bakke, M., "Definitions of Managed Objects for iSCSI", Work in Progress, October 2005. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. [RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [SAS-1.1] T10 Project #1601-D, "Serial Attached SCSI - 1.1 (SAS- 1.1)", SAS-1.1 Revision 10, September 2005. [SBP3] ANSI INCITS 375-2004, "Serial Bus Protocol 3 (SBP-3)", SBP-3 Revision 05, September 2003. [SCC2] ANSI INCITS 318-1998, "SCSI Controller Commands - 2 (SCC- 2)", SCC-2 Revision 04, September 1997. [SPI4] ANSI INCITS 362-2002, "SCSI Parallel Interface-4 (SPI4)", SPI-4 Revision 10, May 2002. [SRP] ANSI INCITS 365-2002, "SCSI RDMA Protocol (SRP)", SRP Revision 16a, July 2002. Hallak-Stamler, et al. Standards Track [Page 85] RFC 4455 SCSI MIB April 2006 Authors' Addresses Michele Hallak-Stamler Sanrad Intelligent Storage 27 Habarzel Street Tel Aviv 69710 IL Phone: +972 3 7674809 EMail: michele@sanrad.com URI: http://www.sanrad.com/ Mark Bakke Cisco Systems, Inc. 7900 International Drive, Suite 400 Bloomington, MN 55425 USA EMail: mbakke@cisco.com URI: http://www.cisco.com/ Yaron Lederman Siliquent Technologies 21 Etzel Street Ramat Gan IL Phone: +972 54 5308833 EMail: yaronled@bezeqint.net Marjorie Krueger Hewlett-Packard 8000 Foothills Blvd Roseville, CA 95747 US Phone: +1 916-785-2656 EMail: marjorie_krueger@hp.com Hallak-Stamler, et al. Standards Track [Page 86] RFC 4455 SCSI MIB April 2006 Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 US Phone: +1 408 526-5260 EMail: kzm@cisco.com Hallak-Stamler, et al. Standards Track [Page 87] RFC 4455 SCSI MIB April 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hallak-Stamler, et al. Standards Track [Page 88] snmp-mibs-downloader-1.1/mibrfcs/rfc4498.txt0000644000000000000000000016351611402176072015607 0ustar Network Working Group G. Keeni Request for Comments: 4498 Cyber Solutions Inc. Category: Experimental May 2006 The Managed Object Aggregation MIB Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). IESG Note The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. Abstract This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances. Keeni Experimental [Page 1] RFC 4498 The Managed Object Aggregation MIB May 2006 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Background ......................................................2 3. MO Aggregation: The Concept .....................................3 4. The Requirements for Managed Object Aggregation .................6 5. MIB Design ......................................................6 6. The Aggregation MIB Modules .....................................7 7. Security Considerations ........................................25 8. IANA Considerations ............................................27 9. References .....................................................27 9.1. Normative References ......................................27 9.2. Informative References ....................................27 10. Acknowledgements ..............................................28 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Background For the purpose of management, it is necessary to access Managed Objects (MOs). The SNMP framework provides a mechanism for naming and describing managed objects. These objects are accessed via a virtual information store termed a Management Information Base (MIB). MIBs have been defined by equipment, protocol, and application developers to provide management access to the managed entities. We will call the MOs defined in these MIBs simple MOs (SMO). Management applications will access one or more instances of these SMOs, one or more times, to monitor the target entity. Keeni Experimental [Page 2] RFC 4498 The Managed Object Aggregation MIB May 2006 There is a cost associated with accessing MOs. The cost is the network bandwidth and the packet header processing overhead at the command generator (manager) and the command responder (agent). This cost constrains the number of MO instances that can be polled and the interval at which polling can be carried out. The overhead reduction can be carried out by reducing the number of query-response packets. This will reduce the packet processing overhead, and to some extent, the bandwidth. The payloads in a typical SNMP "get" packet and the corresponding response are as shown in Figure 1. In this example, polling is carried out for 'n' Managed Object instances OID1, OID2, ..., OIDn. It is obvious that a substantial amount of the payload in an SNMP packet consists of the OIDs. 3. MO Aggregation: The Concept In this document, a mechanism of MO aggregation for payload compression is defined. The idea is simple: we introduce the concept of an Aggregate MO (AgMO). An AgMO is just another MO as far as the SNMP protocol is concerned. No new protocol operations will be required to handle these MOs. As in the case of any other MO, it requires additional instrumentation at the command responder (agent) and at the (command generator) manager. In this mechanism, the user defines an Aggregate MO (AgMO) corresponding to one or more (predefined) MO instances. Semantically, the value of an AgMO instance will be equivalent to the concatenation of the values of the corresponding MO instances. The order of the concatenation will be determined by the order in which the MO instances are specified in the AgMO definition. With the definitions done, the user can, as and when the necessity arises, do an SNMP 'get' on instances of the AgMO to fetch the value of the constituent MO instances. There is substantial savings on bandwidth, as only one instance object identifier is carried in the request and the response. In the normal case, instance object identifiers for each of the constituent MO instances would be carried in the requests and the responses. This is the basic concept of Aggregate Managed Objects. For every AgMO, an ErrorStatus Managed Object is defined. This MO indicates errors, if any, that have been encountered while fetching the values of the constituent MO instances. The error indication is comprised of the index of the MO instance and the corresponding error. If there are no errors, the ErrorStatus Managed Object instance will have a null value. This is the basic concept of Aggregate Managed Objects. Keeni Experimental [Page 3] RFC 4498 The Managed Object Aggregation MIB May 2006 The concepts are explained in Figure 2. An aggregate managed object, AgMOx, has been defined for the MO instances MOI1, ... MOIn. The value of an instance of AgMOx will be a concatenation of the values of MOI1, ... MOIn, in that order. Polling for MO Instances [MOI1, MOI2, ... MOIn]: +--------+------+-------+... -+------+------+ Query: |Get req | MOI1 | NULL | | MOIn | NULL | +--------+------+-------+... -+------+------+ +--------+------+-------+... -+------+------+ Response: |Get resp| MOI1 | Val1 | | MOIn | Valn | +--------+------+-------+... -+------+------+ Figure 1. Polling for MO instances Polling for an instance (AgMOIx) of an aggregate MO (AgMOx): AgMOx = aggr{AgMOI1, AgMOI2, ......AgMOIn} +--------+--------+-------+ Query: |Get req | AgMOIx | NULL | +--------+--------+-------+ +--------+--------+------------------------+ Response: |Get resp| AgMOIx | Val1,Val2,...,Valn | +--------+--------+------------------------+ Figure 2. MO aggregation As a further refinement of the AgMO, we introduce the Time-Based Aggregated Managed Object (TAgMO). The TAgMO is an MO that represents the values of a user-specified MO instance sampled at user-specified intervals for a user-specified number of times. In this case, the user defines a TAgMO by specifying the MO instance that needs to be sampled, the sampling interval, and the desired number of samples that will be included in one TAgMO. The value of a TAgMO instance will include the timestamp (sysUpTime) at which the first sample was taken. The start time is not specified when the TAgMO is defined. Implementations may choose to align the start time with the appropriate time boundaries (e.g., seconds, minutes, hours). With the definitions, the user can do an SNMP "get" on an instance of the TAgMO to fetch the values of the constituent MO instance sampled at the specified intervals. This is the concept of Time-Based aggregation. Keeni Experimental [Page 4] RFC 4498 The Managed Object Aggregation MIB May 2006 Polling for 'n' samples of an MO Instance [MOI] at an interval 'i': Query Time Response ===== ==== ======== +--------+-----+-----------+ |Get req | MOI | NULL | t +--------+-----+-----------+ : +--------+-----+--------------+ : |Get resp| MOI | Val(t) | : +--------+-----+--------------+ +--------+-----+-----------+ t+i |Get req | MOI | NULL | : +--------+-----+-----------+ : +--------+-----+--------------+ : |Get resp| MOI | Val(t+i) | X +--------+-----+--------------+ X : +--------+-----+-----------+ t+(n-1)i |Get req | MOI | NULL | : +--------+-----+-----------+ : +--------+-----+--------------+ : |Get resp| MOI | Val(t+(n-1)i)| +--------+-----+--------------+ Figure 3. Periodic polling for samples of an MO instance Polling for an instance (TAgMOIx) of a Time-Based aggregate MO (TAgMOx): TAgMOx = aggr{'n' polled samples of an instance (MOI) of MO at intervals = 'i' microseconds} +--------+---------+-------+ Query: |Get req | TAgMOIx | NULL | +--------+---------+-------+ +--------+---------+--------------------------------------+ Response: |Get resp| TAgMOIx | t,Val(t),Val(t+i),.,Val(t + (n-1)*i) | +--------+---------+--------------------------------------+ Figure 4. Time-Based aggregation The TAgMO instance is a "bucket" of data representing the value of the corresponding MO instance sampled at 'i' microsecond intervals, 'n' times (i.e., over a 'n' X 'i' microsecond window). The TAgMO instance value gets updated at 'n' X 'i' microsecond intervals. Keeni Experimental [Page 5] RFC 4498 The Managed Object Aggregation MIB May 2006 4. The Requirements for Managed Object Aggregation The general requirements of managed object aggregation are as follows: o It should lead to fewer packets. o It should lead to less bandwidth consumption. o It should not lead to loss of information. In the case of Time-Based aggregation, there will be a delay involved in getting the actual data. The minimum delay in this case will be the duration of the aggregation. The manager application is expected to configure AgMOs (Aggregate MOs) and TAgMOs (Time-Based Aggregate MOs) with care so that the response size is not too large. In case the resultant response size is larger than the maximum acceptable message size of the originator or larger than the local maximum message size, then the error-status field will be set to "tooBig". Note that an aggregate MO can be defined only when all the constituent MO instances of interest are known. This scheme cannot be employed if a manager/application does not know the specific MO instances (of interest) that are serviced by the management target. In such cases, the application may "discover" the MO instances of interest by some means, e.g., by "walking" through the MIB tree on the agent. According to the results of the "walk", the application can define an appropriate aggregate MO that will serve the purpose. Considering the cost involved in this exercise, this method is recommended only if the aggregate MO will be used repeatedly, so that the benefits of aggregation outweigh the costs of configuration. 5. MIB Design The basic principle has been to keep the MIB as simple as possible and at the same time to make it flexible enough that a large number of users and applications can use the MIB to configure aggregate MOs conveniently. Two separate MIB modules have been defined. The AggrMIB supports the aggregation of independent MO instances, while TAggrMIB supports the aggregation of several samples of the same MO instance. Both of these MIB modules use the textual conventions defined in RMON-MIB [RFC2819] and SNMP-FRAMEWORK-MIB [RFC3411]. Keeni Experimental [Page 6] RFC 4498 The Managed Object Aggregation MIB May 2006 The AggrMIB is comprised of three tables, described below. - The aggrCtlTable controls the aggregation process. Each row in this table defines the attributes of the aggregate object defined in the aggrMOTable. - The aggrMOTable defines the primary MO-based aggregation, i.e., the MOs that will be aggregated. - The aggrDataTable contains the details of the aggregated object. The TAggrMIB is comprised of two tables described below. - The tAggrCtlTable controls the aggregation process. Each row in this table defines the attributes of the aggregate object defined in the aggrMOTable. - The tAggrDataTable contains the details of the aggregated object. 6. The Aggregation MIB Modules AGGREGATE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, experimental, Unsigned32, OBJECT-TYPE, Opaque FROM SNMPv2-SMI OwnerString FROM RMON-MIB RowStatus, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; aggrMIB MODULE-IDENTITY LAST-UPDATED "200604270000Z" -- 27th April, 2006 ORGANIZATION "Cyber Solutions Inc. NetMan Working Group" CONTACT-INFO " Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Support Group E-mail: mibsupport@cysols.com" Keeni Experimental [Page 7] RFC 4498 The Managed Object Aggregation MIB May 2006 DESCRIPTION "The MIB for servicing aggregate objects. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4498; see the RFC itself for full legal notices. " REVISION "200604270000Z" -- 27th April, 2006 DESCRIPTION "Initial version, published as RFC 4498." ::= { experimental 123 } AggrMOErrorStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to model the error status of the constituent MO instances. The error status for a constituent MO instance is given in terms of two elements: o The moIndex, which indicates the position of the MO instance (starting at 1) in the value of the aggregated MO instance. o The moError, which indicates the error that was encountered in fetching that MO instance. The syntax in ASN.1 Notation will be ErrorStatus :: = SEQUENCE { moIndex Integer32, moError SnmpPduErrorStatus } AggrMOErrorStatus ::= SEQUENCE OF { ErrorStatus } Note1: The command responder will supply values for all constituent MO instances, in the same order in which the MO instances are specified for the AgMO. If an error is encountered for an MO instance, then the corresponding value will have an ASN.1 value NULL, and an error will be flagged in the corresponding AggrMOErrorStatus object. Only MOs for which errors have been encountered will have their corresponding moIndex and moError values set. Note2: The error code for the component MO instances will be in accordance with the SnmpPduErrorStatus TC defined in the DISMAN-SCHEDULE-MIB [RFC3231]. Note3: The command generator will need to know constituent MO instances and their order to correctly interpret AggrMOErrorStatus. " SYNTAX Opaque (SIZE (0..1024)) Keeni Experimental [Page 8] RFC 4498 The Managed Object Aggregation MIB May 2006 AggrMOValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to model the aggregate MOs. It will have a format dependent on the constituent MOs, a sequence of values. The syntax in ASN.1 Notation will be MOValue :: = SEQUENCE { value ObjectSyntax } where 'value' is the value of a constituent MO instance. AggrMOValue :: = SEQUENCE OF { MOValue } Note: The command generator will need to know the constituent MO instances and their order to correctly interpret AggrMOValue." SYNTAX Opaque (SIZE (0..1024)) AggrMOCompressedValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to model the compressed aggregate MOs." SYNTAX OCTET STRING (SIZE (0..1024)) -- -- The aggregation control table -- There will be a row for each aggregate MO -- aggrCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF AggrCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that controls the aggregation of the MOs." ::= {aggrMIB 1} aggrCtlEntry OBJECT-TYPE SYNTAX AggrCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of the control table that defines one aggregated MO. Keeni Experimental [Page 9] RFC 4498 The Managed Object Aggregation MIB May 2006 Entries in this table are required to survive a reboot of the managed entity depending on the value of the corresponding aggrCtlEntryStorageType instance. " INDEX {aggrCtlEntryID } ::= {aggrCtlTable 1 } AggrCtlEntry ::= SEQUENCE { aggrCtlEntryID SnmpAdminString, aggrCtlMOIndex Unsigned32, aggrCtlMODescr SnmpAdminString, aggrCtlCompressionAlgorithm INTEGER, aggrCtlEntryOwner OwnerString, aggrCtlEntryStorageType StorageType, aggrCtlEntryStatus RowStatus } aggrCtlEntryID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally unique, administratively assigned name for this aggregated MO. It is used as an index to uniquely identify this row in the table." ::= { aggrCtlEntry 1 } aggrCtlMOIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to a group of MOs identified by aggrMOEntryID in the aggrMOTable. This is the group of MOs that will be aggregated." ::= { aggrCtlEntry 2 } aggrCtlMODescr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..64)) MAX-ACCESS read-create STATUS current Keeni Experimental [Page 10] RFC 4498 The Managed Object Aggregation MIB May 2006 DESCRIPTION "A textual description of the object that is being aggregated." ::= {aggrCtlEntry 3} -- only one compression algorithm is defined as of now. aggrCtlCompressionAlgorithm OBJECT-TYPE SYNTAX INTEGER { none (1), deflate (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The compression algorithm that will be used by the agent to compress the value of the aggregated object. The deflate algorithm and corresponding data format specification is described in RFC 1951. It is compatible with the widely used gzip utility. " REFERENCE "RFC1951 : DEFLATE Compressed Data Format Specification version 1.3 " DEFVAL { none } ::= {aggrCtlEntry 4} aggrCtlEntryOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that created this entry." ::= {aggrCtlEntry 5} aggrCtlEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether the parameters defined in this row are kept in volatile storage and lost upon reboot or backed up by non-volatile (permanent) storage. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. Keeni Experimental [Page 11] RFC 4498 The Managed Object Aggregation MIB May 2006 " ::= {aggrCtlEntry 6} aggrCtlEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status variable, used according to row installation and removal conventions. Objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row, a. change the row status to 'notInService', b. change the values of the row, and c. change the row status to 'active'. The aggrCtlEntryStatus may be changed to 'active' if all the MOs in the conceptual row have been assigned valid values. " ::= {aggrCtlEntry 7} -- -- The Table of primary(simple) MOs -- aggrMOTable OBJECT-TYPE SYNTAX SEQUENCE OF AggrMOEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of primary(simple) MOs that will be aggregated. Each row in this table represents a MO that will be aggregated. The aggrMOEntryID index is used to identify the group of MOs that will be aggregated. The aggrMOIndex instance in the corresponding row of the aggrCtlTable will have a value equal to the value of aggrMOEntryID. The aggrMOEntryMOID index is used to identify an MO in the group. " ::= {aggrMIB 2} aggrMOEntry OBJECT-TYPE SYNTAX AggrMOEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Keeni Experimental [Page 12] RFC 4498 The Managed Object Aggregation MIB May 2006 "A row of the table that specifies one MO. Entries in this table are required to survive a reboot of the managed entity depending on the value of the corresponding aggrMOEntryStorageType instance. " INDEX { aggrMOEntryID, aggrMOEntryMOID } ::= {aggrMOTable 1 } AggrMOEntry ::= SEQUENCE { aggrMOEntryID Unsigned32, aggrMOEntryMOID Unsigned32, aggrMOInstance OBJECT IDENTIFIER, aggrMODescr SnmpAdminString, aggrMOEntryStorageType StorageType, aggrMOEntryStatus RowStatus } aggrMOEntryID OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index uniquely identifying a group of MOs that will be aggregated." ::= { aggrMOEntry 1 } aggrMOEntryMOID OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index to uniquely identify an MO instance in the group of MO instances that will be aggregated." ::= { aggrMOEntry 2 } aggrMOInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OID of the MO instance, the value of which will be sampled by the agent." Keeni Experimental [Page 13] RFC 4498 The Managed Object Aggregation MIB May 2006 ::= { aggrMOEntry 3 } aggrMODescr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "A textual description of the object that will be aggregated." ::= {aggrMOEntry 4} aggrMOEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether the parameters defined in this row are kept in volatile storage and lost upon reboot or backed up by non-volatile (permanent) storage. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " ::= {aggrMOEntry 5} aggrMOEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status variable, used according to row installation and removal conventions. Objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row, a. change the row status to 'notInService', b. change the values of the row, and c. change the row status to 'active'. The aggrMOEntryStatus may be changed to 'active' iff all the MOs in the conceptual row have been assigned valid values. " ::= {aggrMOEntry 6} -- -- aggrDataTable: The Table of Data. Each row represents a Data Keeni Experimental [Page 14] RFC 4498 The Managed Object Aggregation MIB May 2006 -- set. aggrCtlEntryID is the key to the table. -- It is used to identify instances of the -- aggregated MO that are present in the table. -- aggrDataTable OBJECT-TYPE SYNTAX SEQUENCE OF AggrDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row of this table contains information about an aggregateMO indexed by aggrCtlEntryID." ::= {aggrMIB 3} aggrDataEntry OBJECT-TYPE SYNTAX AggrDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information pertaining to an aggregate MO." INDEX {aggrCtlEntryID} ::= {aggrDataTable 1 } AggrDataEntry ::= SEQUENCE { aggrDataRecord AggrMOValue, aggrDataRecordCompressed AggrMOCompressedValue, aggrDataErrorRecord AggrMOErrorStatus } aggrDataRecord OBJECT-TYPE SYNTAX AggrMOValue MAX-ACCESS read-only STATUS current DESCRIPTION "The snapshot value of the aggregated MO. Note that the access privileges to this object will be governed by the access privileges of the component objects. Thus, an entity attempting to access an instance of this MO MUST have access rights to all the component instance objects and this MO instance. " ::= { aggrDataEntry 1} aggrDataRecordCompressed OBJECT-TYPE SYNTAX AggrMOCompressedValue Keeni Experimental [Page 15] RFC 4498 The Managed Object Aggregation MIB May 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The compressed value of the aggregated MO. The compression algorithm will depend on the aggrCtlCompressionAlgorithm given in the corresponding aggrCtlEntry. If the value of the corresponding aggrCtlCompressionAlgorithm is (1) 'none', then the value of all instances of this object will be a string of zero length. Note that the access privileges to this object will be governed by the access privileges of the component objects. Thus, an entity attempting to access an instance of this MO MUST have access rights to all the component instance objects and this MO instance. " ::= { aggrDataEntry 2} aggrDataErrorRecord OBJECT-TYPE SYNTAX AggrMOErrorStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The error status corresponding to the MO instances aggregated in aggrDataRecord (and aggrDataRecordCompressed)." ::= { aggrDataEntry 3} -- Conformance information aggrConformance OBJECT IDENTIFIER ::= { aggrMIB 4 } aggrGroups OBJECT IDENTIFIER ::= { aggrConformance 1 } aggrCompliances OBJECT IDENTIFIER ::= { aggrConformance 2 } -- Compliance statements aggrMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AGGREGATE-MIB." MODULE -- this module MANDATORY-GROUPS { aggrMibBasicGroup } ::= { aggrCompliances 1 } -- Units of conformance aggrMibBasicGroup OBJECT-GROUP OBJECTS { aggrCtlMOIndex, aggrCtlMODescr, Keeni Experimental [Page 16] RFC 4498 The Managed Object Aggregation MIB May 2006 aggrCtlCompressionAlgorithm, aggrCtlEntryOwner, aggrCtlEntryStorageType, aggrCtlEntryStatus, aggrMOInstance, aggrMODescr, aggrMOEntryStorageType, aggrMOEntryStatus, aggrDataRecord, aggrDataRecordCompressed, aggrDataErrorRecord } STATUS current DESCRIPTION "A collection of objects for aggregation of MOs." ::= { aggrGroups 1 } END TIME-AGGREGATE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, experimental, OBJECT-TYPE, Opaque, Integer32 FROM SNMPv2-SMI OwnerString FROM RMON-MIB RowStatus, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; tAggrMIB MODULE-IDENTITY LAST-UPDATED "200604270000Z" -- 27 April 2006 ORGANIZATION "Cyber Solutions Inc. NetMan Working Group" CONTACT-INFO " Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Support Group E-mail: mibsupport@cysols.com" DESCRIPTION Keeni Experimental [Page 17] RFC 4498 The Managed Object Aggregation MIB May 2006 "The MIB for servicing Time-Based aggregate objects. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4498; see the RFC itself for full legal notices. " REVISION "200604270000Z" -- 27th April, 2006 DESCRIPTION "Initial version, published as RFC 4498." ::= { experimental 124 } TAggrMOErrorStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to model the error status of the sampled MO instance. The error status for a sampled MO instance is given in terms of two elements: o The moIndex, which indicates the sample number of the MO instance (starting at 1) in the value of the time- aggregated MO instance. o The moError, which indicates the error that was encountered in sampling that MO instance. The syntax in ASN.1 Notation will be ErrorStatus :: = SEQUENCE { moIndex Integer32, moError SnmpPduErrorStatus } TAggrMOErrorStatus ::= SEQUENCE OF { ErrorStatus } Note1: The command responder will supply values for all the samples of the MO instance. If an error is encountered for a sample, then the corresponding value will have an ASN.1 value NULL, and an error will be flagged in the corresponding TAggrMOErrorStatus object. Only MOs for which errors have been encountered will the corresponding moIndex and moError values be set. Note2: The error code for the component MO instances will be in accordance with the SnmpPduErrorStatus TC defined in the DISMAN-SCHEDULE-MIB[RFC3231]. " SYNTAX Opaque (SIZE (0..1024)) TimeAggrMOValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to model the time-aggregated MOs. It Keeni Experimental [Page 18] RFC 4498 The Managed Object Aggregation MIB May 2006 will be a sequence of values. The syntax in ASN.1 Notation will be MOSampleValue :: = SEQUENCE { value ObjectSyntax } TimeAggrMOValue ::= SEQUENCE OF { MOSampleValue } where the first MOSampleValue, if any, will always be the timestamp of the first sample in the aggregated object. The subsequent values are the values of the MO instance sampled at the specified intervals for the specified number of times. Note: The command generator will need to know the constituent MO instance and the sampling interval to correctly interpret TimeAggrMOValue. " SYNTAX Opaque (SIZE (0..1024)) CompressedTimeAggrMOValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to model the compressed TAgMOs." SYNTAX Opaque (SIZE (0..1024)) -- -- The Time-Based aggregation control table -- tAggrCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF TAggrCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Time-Based aggregation control table. It controls the aggregation of the samples of MO instances. There will be a row for each TAgMO. " ::= {tAggrMIB 1} tAggrCtlEntry OBJECT-TYPE SYNTAX TAggrCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of the control table that defines one Time-Based aggregate MO (TAgMO)." INDEX {tAggrCtlEntryID } ::= {tAggrCtlTable 1 } Keeni Experimental [Page 19] RFC 4498 The Managed Object Aggregation MIB May 2006 TAggrCtlEntry ::= SEQUENCE { tAggrCtlEntryID SnmpAdminString, tAggrCtlMOInstance OBJECT IDENTIFIER, tAggrCtlAgMODescr SnmpAdminString, tAggrCtlInterval Integer32, tAggrCtlSamples Integer32, tAggrCtlCompressionAlgorithm INTEGER, tAggrCtlEntryOwner OwnerString, tAggrCtlEntryStorageType StorageType, tAggrCtlEntryStatus RowStatus } tAggrCtlEntryID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally unique, administratively assigned name for this aggregated MO. It is used as an index to uniquely identify this row in the table." ::= { tAggrCtlEntry 1 } tAggrCtlMOInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The sampled values of this MO instance will be aggregated by the TAgMO. " ::= { tAggrCtlEntry 2 } tAggrCtlAgMODescr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "A textual description of the aggregate object." ::= {tAggrCtlEntry 3} Keeni Experimental [Page 20] RFC 4498 The Managed Object Aggregation MIB May 2006 tAggrCtlInterval OBJECT-TYPE SYNTAX Integer32 UNITS "micro seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval, in microseconds, at which the MO instance pointed at by tAggrInstance will be sampled for Time-Based aggregation. " ::= {tAggrCtlEntry 4} tAggrCtlSamples OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of times at which the MO instance referred to by tAggrInstance will be sampled for Time-Based aggregation." ::= {tAggrCtlEntry 5} -- only one compression algorithm is defined as of now. tAggrCtlCompressionAlgorithm OBJECT-TYPE SYNTAX INTEGER { none (1), deflate (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The compression algorithm that will be used by the agent to compress the value of the TAgMO. The deflate algorithm and corresponding data format specification is described in RFC 1951. It is compatible with the widely used gzip utility. " REFERENCE "RFC1951 : DEFLATE Compressed Data Format Specification version 1.3 " DEFVAL { none } ::= {tAggrCtlEntry 6} tAggrCtlEntryOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current Keeni Experimental [Page 21] RFC 4498 The Managed Object Aggregation MIB May 2006 DESCRIPTION "A textual description of the entity that created this entry. " ::= {tAggrCtlEntry 7} tAggrCtlEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether the parameters defined in this row are kept in volatile storage and lost upon reboot or backed up by non-volatile (permanent) storage. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " ::= {tAggrCtlEntry 8} tAggrCtlEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row status variable, used according to row installation and removal conventions. Objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row, a. change the row status to 'notInService', b. change the values of the row, and c. change the row status to 'active'. The tAggrCtlEntryStatus may be changed to 'active' iff all the MOs in the conceptual row have been assigned valid values. " ::= {tAggrCtlEntry 9} -- -- tAggrDataTable: The data table. -- tAggrDataTable OBJECT-TYPE SYNTAX SEQUENCE OF TAggrDataEntry Keeni Experimental [Page 22] RFC 4498 The Managed Object Aggregation MIB May 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is the data table. Each row of this table contains information about a TAgMO indexed by tAggrCtlEntryID. tAggrCtlEntryID is the key to the table. It is used to identify instances of the TAgMO that are present in the table. " ::= {tAggrMIB 2} tAggrDataEntry OBJECT-TYPE SYNTAX TAggrDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information pertaining to a TAgMO." INDEX {tAggrCtlEntryID} ::= {tAggrDataTable 1 } TAggrDataEntry ::= SEQUENCE { tAggrDataRecord TimeAggrMOValue, tAggrDataRecordCompressed CompressedTimeAggrMOValue, tAggrDataErrorRecord TAggrMOErrorStatus } tAggrDataRecord OBJECT-TYPE SYNTAX TimeAggrMOValue MAX-ACCESS read-only STATUS current DESCRIPTION "The snapshot value of the TAgMO." ::= { tAggrDataEntry 1} tAggrDataRecordCompressed OBJECT-TYPE SYNTAX CompressedTimeAggrMOValue MAX-ACCESS read-only STATUS current DESCRIPTION "The compressed value of the TAgMO. The compression algorithm will depend on the tAggrCtlCompressionAlgorithm given in the corresponding tAggrCtlEntry. If the value of the corresponding tAggrCtlCompressionAlgorithm is (1) 'none', then the Keeni Experimental [Page 23] RFC 4498 The Managed Object Aggregation MIB May 2006 value of all instances of this object will be a string of zero length. Note that the access privileges to this object will be governed by the access privileges of the corresponding MO instance. Thus, an entity attempting to access an instance of this MO MUST have access rights to the instance object pointed at by tAggrCtlMOInstance and this MO instance. " ::= { tAggrDataEntry 2} tAggrDataErrorRecord OBJECT-TYPE SYNTAX TAggrMOErrorStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The error status corresponding to the MO instance samples aggregated in tAggrDataRecord (and tAggrDataRecordCompressed)." ::= { tAggrDataEntry 3} -- Conformance information tAggrConformance OBJECT IDENTIFIER ::= { tAggrMIB 3 } tAggrGroups OBJECT IDENTIFIER ::= { tAggrConformance 1 } tAggrCompliances OBJECT IDENTIFIER ::= { tAggrConformance 2 } -- Compliance statements tAggrMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the TIME-AGGREGATE-MIB." MODULE -- this module MANDATORY-GROUPS { tAggrMibBasicGroup } ::= { tAggrCompliances 1 } -- Units of conformance tAggrMibBasicGroup OBJECT-GROUP OBJECTS { tAggrCtlMOInstance, tAggrCtlAgMODescr, tAggrCtlInterval, tAggrCtlSamples, tAggrCtlCompressionAlgorithm, tAggrCtlEntryOwner, tAggrCtlEntryStorageType, tAggrCtlEntryStatus, Keeni Experimental [Page 24] RFC 4498 The Managed Object Aggregation MIB May 2006 tAggrDataRecord, tAggrDataRecordCompressed, tAggrDataErrorRecord } STATUS current DESCRIPTION "A collection of objects for Time-Based aggregation of MOs." ::= { tAggrGroups 1 } END 7. Security Considerations There are management objects in the MIB modules defined in this document that have a MAX-ACCESS clause of read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The objects and corresponding vulnerabilities are discussed below. The following MOs are used to configure an agent that implements the aggregate MIB modules. aggrCtlMOIndex, aggrCtlMODescr, aggrCtlCompressionAlgorithm, aggrCtlEntryOwner, aggrCtlEntryStorageType, aggrCtlEntryStatus, aggrMOInstance, aggrMODescr, aggrMOEntryStorageType, aggrMOEntryStatus, tAggrCtlMOInstance, tAggrCtlAgMODescr, tAggrCtlInterval, tAggrCtlSamples, tAggrCtlCompressionAlgorithm, tAggrCtlEntryOwner, tAggrCtlEntryStorageType, tAggrCtlEntryStatus, Keeni Experimental [Page 25] RFC 4498 The Managed Object Aggregation MIB May 2006 Access to these objects may be abused to affect the operation of the data collection system. In particular, - by changing the value of an instance of aggrCtlEntryStatus, tAggrCtlEntryStatus, aggrMOEntryStatus, or tAggrMOEntryStatus to 'notInService' or 'destroy', the data aggregation operation for the corresponding entry will become unavailable to the management system. - by changing the value of an instance of aggrMOInstance or tAggrCtlMOInstance, the data aggregation operation may be subverted. This may result in wrong information being fed to the management system. - by adding several rows in the aggrMOTable corresponding to an aggregate MO, it is possible to make the value of the aggregate MOs very large. A similar effect may be achieved by manipulating the value of the tAggrCtlSamples instance corresponding to a Time-Based aggregate MO. This could result in very heavy management traffic and/or fragmentation of response packets. In some cases the responder may refuse to send the data and will simply respond with an error message indicating that the response packet size is too big. An entity attempting to access an instance of an aggregated MO MUST have access rights to all the component instance objects and the aggregate MO instance. An implementation MUST follow this requirement. Lax adherence to this requirement will breach the security model and make the system vulnerable to illegal accesses. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Keeni Experimental [Page 26] RFC 4498 The Managed Object Aggregation MIB May 2006 8. IANA Considerations The MIB modules in this document use the following IANA-assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- aggrMIB { experimental 123 } tAggrMIB { experimental 124 } 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 3231, January 2002. [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. 9.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Keeni Experimental [Page 27] RFC 4498 The Managed Object Aggregation MIB May 2006 10. Acknowledgements This document is the product of discussions and deliberations carried out in the WIDE-netman group. Bert Wijnen and Glenn Waters reviewed the document and provided valuable comments. Authors' Addresses Glenn Mansfield Keeni Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Keeni Experimental [Page 28] RFC 4498 The Managed Object Aggregation MIB May 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Keeni Experimental [Page 29] snmp-mibs-downloader-1.1/mibrfcs/rfc4502.txt0000644000000000000000000107000011402176072015553 0ustar Network Working Group S. Waldbusser Request for Comments: 4502 May 2006 Obsoletes: 2021 Updates: 3273 Category: Standards Track Remote Network Monitoring Management Information Base Version 2 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. Waldbusser Standards Track [Page 1] RFC 4502 Remote Network Monitoring MIB May 2006 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 2.1. Remote Network Management Goals ............................3 2.2. Structure of MIB ...........................................4 3. Control of Remote Network Monitoring Devices ....................6 3.1. Resource Sharing among Multiple Management Stations ........7 3.2. Row Addition among Multiple Management Stations ............8 4. Conventions .....................................................9 5. RMON 2 Conventions .............................................10 5.1. Usage of the Term Application Level .......................10 5.2. Protocol Directory and Limited Extensibility ..............10 5.3. Errors in Packets .........................................11 6. Definitions ....................................................11 7. Security Considerations .......................................130 8. Appendix - TimeFilter Implementation Notes ....................132 9. Changes since RFC 2021 ........................................138 10. Acknowledgements .............................................140 11. References ...................................................140 11.1. Normative References ....................................140 11.2. Informative References ..................................140 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview The RMON2 MIB defines objects that provide RMON analysis up to the application layer. Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network. Often, these remote probes are stand-alone devices and devote significant internal resources for the sole purpose of managing a network. An organization may employ many of these devices, one per Waldbusser Standards Track [Page 2] RFC 4502 Remote Network Monitoring MIB May 2006 network segment, to manage its internet. In addition, these devices may be used for a network management service provider to access a client network, which is often geographically remote. The objects defined in this document are intended to serve as an interface between an RMON agent and an RMON management application and are not intended for direct manipulation by humans. While some users may tolerate the direct display of some of these objects, few will tolerate the complexity of manually manipulating objects to accomplish row creation. The management application should handle these functions. 2.1. Remote Network Management Goals o Offline Operation There are times when a management station will not be in constant contact with its remote monitoring devices. This sometimes occurs by design, in an attempt to lower communications costs (especially when communicating over a WAN or dialup link), or by accident, as network failures affect the communications between the management station and the probe. For this reason, this MIB allows a probe to be configured to perform diagnostics and to collect statistics continuously, even when communication with the management station may not be possible or efficient. The probe may then attempt to notify the management station when an exceptional condition occurs. Thus, even in circumstances where communication between the management station and probe is not continuous, fault, performance, and configuration information may be continuously accumulated and communicated to the management station conveniently and efficiently. o Proactive Monitoring Given the resources available on the monitor, it is potentially helpful for it to run diagnostics continuously and to log network performance. The monitor is always available at the onset of any failure. It can notify the management station of the failure and can store historical statistical information about the failure. This historical information can be played back by the management station in an attempt to perform further diagnosis of the cause of the problem. Waldbusser Standards Track [Page 3] RFC 4502 Remote Network Monitoring MIB May 2006 o Problem Detection and Reporting The monitor can be configured to recognize conditions, most notably error conditions, and to check for them continuously. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways. o Value Added Data Because a remote monitoring device represents a network resource dedicated exclusively to network management functions, and because it is located directly on the monitored portion of the network, the remote network monitoring device has the opportunity to add significant value to the data it collects. For instance, by highlighting those hosts on the network that generate the most traffic or errors, the probe can give the management station precisely the information it needs to solve a class of problems. o Multiple Managers An organization may have multiple management stations for different units of the organization, for different functions (e.g., engineering and operations), and in order to provide disaster recovery. Because environments with multiple management stations are common, the remote network monitoring device has to deal with more than one management station, potentially using its resources concurrently. 2.2. Structure of MIB The objects are arranged into the following groups: - protocol directory - protocol distribution - address mapping - network layer host - network layer matrix - application layer host - application layer matrix - user history Waldbusser Standards Track [Page 4] RFC 4502 Remote Network Monitoring MIB May 2006 - probe configuration These groups are the basic units of conformance. If a remote monitoring device implements a group, then it must implement all objects in that group. For example, a managed agent that implements the network layer matrix group must implement the nlMatrixSDTable and the nlMatrixDSTable. Implementations of this MIB must also implement the IF-MIB [RFC2863]. These groups are defined to provide a means of assigning object identifiers, and to provide a method for managed agents to know which objects they must implement. This document also contains AUGMENTing tables to extend some tables defined in the RMON MIB [RFC2819]. These extensions include the following: 1) Adding the DroppedFrames and LastCreateTime conventions to each table defined in the RMON MIB. 2) Augmenting the RMON filter table with a mechanism that allows filtering based on an offset from the beginning of a particular protocol, even if the protocol headers are of variable length. 3) Augmenting the RMON filter and capture status bits with additional bits for WAN media and generic media. These bits are defined here as follows: Bit Definition 6 For WAN media, this bit is set for packets coming from one direction and cleared for packets coming from the other direction. It is an implementation-specific matter as to which bit is assigned to which direction, but it must be consistent for all packets received by the agent. If the agent knows which end of the link is "local" and which end is "network", the bit should be set for packets from the "local" side and should be cleared for packets from the "network" side. 7 For any media, this bit is set for any packet with a physical layer error. This bit may be set in addition to other media-specific bits that denote the same condition. Waldbusser Standards Track [Page 5] RFC 4502 Remote Network Monitoring MIB May 2006 8 For any media, this bit is set for any packet that is too short for the media. This bit may be set in addition to other media-specific bits that denote the same condition. 9 For any media, this bit is set for any packet that is too long for the media. This bit may be set in addition to other media-specific bits that denote the same condition. These enhancements are implemented by RMON-2 probes that also implement RMON and do not add any requirements to probes that are compliant to just RMON. 3. Control of Remote Network Monitoring Devices Due to the complex nature of the available functions in these devices, the functions often need user configuration. In many cases, the function requires that parameters be set up for a data collection operation. The operation can proceed only after these parameters are fully set up. Many functional groups in this MIB have one or more tables in which to set up control parameters, and one or more data tables in which to place the results of the operation. The control tables are typically read/write in nature, while the data tables are typically read-only. Because the parameters in the control table often describe resulting data in the data table, many of the parameters can be modified only when the control entry is not active. Thus, the method for modifying these parameters is to deactivate the entry, perform the SNMP Set operations to modify the entry, and then reactivate the entry. Deleting the control entry causes the deletion of any associated data entries, which also gives a convenient method for reclaiming the resources used by the associated data. Some objects in this MIB provide a mechanism to execute an action on the remote monitoring device. These objects may execute an action as a result of a change in the state of the object. For those objects in this MIB, a request to set an object to the same value as it currently holds would thus cause no action to occur. To facilitate control by multiple managers, resources have to be shared among the managers. These resources are typically the memory and computation resources that a function requires. Waldbusser Standards Track [Page 6] RFC 4502 Remote Network Monitoring MIB May 2006 3.1. Resource Sharing among Multiple Management Stations When multiple management stations wish to use functions that compete for a finite amount of resources on a device, a method to facilitate this sharing of resources is required. Potential conflicts include the following: o Two management stations wish to use resources simultaneously that together would exceed the capability of the device. o A management station uses a significant amount of resources for a long period of time. o A management station uses resources and then crashes, forgetting to free the resources so that others may use them. The OwnerString mechanism is provided for each management station- initiated function in this MIB to avoid these conflicts and to help resolve them when they occur. Each function has a label identifying the initiator (owner) of the function. This label is set by the initiator to provide for the following possibilities: o A management station may recognize resources it owns and no longer needs. o A network operator can find the management station that owns the resource and negotiate for it to be freed. o A network operator may decide unilaterally to free resources another network operator has reserved. o Upon initialization, a management station may recognize resources it had reserved in the past. With this information, it may free the resources if it no longer needs them. Management stations and probes should support any format of the owner string dictated by the local policy of the organization. It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. This information will help users share the resources more effectively. There is often default functionality that the device or the administrator of the probe (often the network administrator) wishes to set up. The resources associated with this functionality are then owned by the device itself or by the network administrator, and they are intended to be long-lived. In this case, the device or the administrator will set the relevant owner object to a string starting Waldbusser Standards Track [Page 7] RFC 4502 Remote Network Monitoring MIB May 2006 with 'monitor'. Indiscriminate modification of the monitor-owned configuration by network management stations is discouraged. In fact, a network management station should only modify these objects under the direction of the administrator of the probe. Resources on a probe are scarce and are typically allocated when control rows are created by an application. Since many applications may be using a probe simultaneously, indiscriminate allocation of resources to particular applications is very likely to cause resource shortages in the probe. When a network management station wishes to utilize a function in a monitor, it is encouraged first to scan the control table of that function to find an instance with similar parameters to share. This is especially true for those instances owned by the monitor, which can be assumed to change infrequently. If a management station decides to share an instance owned by another management station, it should understand that the management station that owns the instance may indiscriminately modify or delete it. Note that a management application should have the most trust in a monitor-owned row, because it should be changed very infrequently. A row owned by the management application is less long-lived because a network administrator is more likely to reassign resources from a row that is in use by one user than those from a monitor-owned row that is potentially in use by many users. A row owned by another application would be even less long-lived because the other application may delete or modify that row completely at its discretion. 3.2. Row Addition among Multiple Management Stations The addition of new rows is achieved using the RowStatus Textual Convention [RFC2579]. In this MIB, rows are often added to a table in order to configure a function. This configuration usually involves parameters that control the operation of the function. The agent must check these parameters to make sure they are appropriate given the restrictions defined in this MIB, as well as any implementation-specific restrictions, such as lack of resources. The agent implementor may be confused as to when to check these parameters and when to signal to the management station that the parameters are invalid. There are two opportunities: o When the management station sets each parameter object. o When the management station sets the row status object to active. Waldbusser Standards Track [Page 8] RFC 4502 Remote Network Monitoring MIB May 2006 If the latter option is chosen, it would be unclear to the management station which of the several parameters was invalid and caused the badValue error to be emitted. Thus, wherever possible, the implementor should choose the former option, as it will provide more information to the management station. A problem can arise when multiple management stations attempt to set configuration information simultaneously using SNMP. When this involves the addition of a new conceptual row in the same control table, the managers may collide, attempting to create the same entry. To guard against these collisions, each such control entry contains a status object with special semantics that help arbitrate among the managers. If an attempt is made with the row addition mechanism to create such a status object and that object already exists, an error is returned. When more than one manager simultaneously attempts to create the same conceptual row, only the first will succeed. The others will receive an error. In the RMON MIB [RFC2819], the EntryStatus textual convention was introduced to provide this mutual exclusion function. Since then, this function was added to the SNMP framework as the RowStatus textual convention. The RowStatus textual convention is used for the definition of all new tables. When a manager wishes to create a new control entry, it needs to choose an index for that row. It may choose this index in a variety of ways, hopefully minimizing the chances that the index is in use by another manager. If the index is in use, the mechanism mentioned previously will guard against collisions. Examples of schemes to choose index values include random selection or scanning the control table while looking for the first unused index. Because index values may be any valid value in the range and are chosen by the manager, the agent must allow a row to be created with any unused index value if it has the resources to create a new row. Some tables in this MIB reference other tables within this MIB. When creating or deleting entries in these tables, it is generally allowable for dangling references to exist. There is no defined order for creating or deleting entries in these tables. 4. Conventions The following conventions are used throughout the RMON MIB and its companion documents. Waldbusser Standards Track [Page 9] RFC 4502 Remote Network Monitoring MIB May 2006 Good Packets Good packets are error-free packets that have a valid frame length. For example, on Ethernet, good packets are error-free packets that are between 64 octets and 1518 octets long. They follow the form defined in IEEE 802.3 section 3.2.all. Bad Packets Bad packets are packets that have proper framing and are therefore recognized as packets, but that contain errors within the packet or have an invalid length. For example, on Ethernet, bad packets have a valid preamble and SFD but have a bad CRC, or they are either shorter than 64 octets or longer than 1518 octets. 5. RMON 2 Conventions The following practices and conventions are introduced in the RMON 2 MIB. 5.1. Usage of the Term "Application Level" There are many cases in this MIB where the term "Application Level" is used to describe a class of protocols or a capability. This does not typically mean a protocol that is an OSI Layer 7 protocol. Rather, it is used to identify a class of protocols that is not limited to MAC-layer and network-layer protocols, but can also include transport, session, presentation, and application-layer protocols. 5.2. Protocol Directory and Limited Extensibility Every RMON 2 implementation will have the capability to parse certain types of packets and identify their protocol type at multiple levels. The protocol directory presents an inventory of protocol types the probe is capable of monitoring and allows the addition, deletion, and configuration of protocol types in this list. One concept deserves special attention: the "limited extensibility" of the protocol directory table. Using the RMON 2 model, protocols are detected by static software that has been written at implementation time. Therefore, as a matter of configuration, an implementation cannot suddenly learn how to parse new packet types. However, an implementation may be written such that the software knows where the demultiplexing field is for a particular protocol, and it can be written in such a way that the decoding of the next layer up is table driven. This works when the code has been written to accommodate it and can be extended no more than one level higher. Waldbusser Standards Track [Page 10] RFC 4502 Remote Network Monitoring MIB May 2006 This extensibility is called "limited extensibility" to highlight these limitations. However, this can be a very useful tool. For example, suppose that an implementation has C code that understands how to decode IP packets on any of several ethernet encapsulations, and also knows how to interpret the IP protocol field to recognize UDP packets and how to decode the UDP port number fields. That implementation may be table driven so that among the many different UDP port numbers possible, it is configured to recognize 161 as SNMP, port 53 as DNS, and port 69 as TFTP. The limited extensibility of the protocol directory table would allow an SNMP operation to create an entry that would create an additional table mapping for UDP that would recognize UDP port 123 as NTP and begin counting such packets. This limited extensibility is an option that an implementation can choose to allow or disallow for any protocol that has child protocols. 5.3. Errors in Packets Packets with link-level errors are not counted anywhere in this MIB because most variables in this MIB require the decoding of the contents of the packet, which is meaningless if there is a link-level error. Packets in which protocol errors are detected are counted for all protocols below the layer in which the error was encountered. The implication of this is that packets in which errors are detected at the network-layer are not counted anywhere in this MIB, while packets with errors detected at the transport layer may have network-layer statistics counted. 6. Definitions RMON2-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Gauge32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, DisplayString, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB OwnerString, statistics, history, hosts, matrix, filter, etherStatsEntry, historyControlEntry, hostControlEntry, matrixControlEntry, filterEntry, channelEntry FROM RMON-MIB tokenRing, tokenRingMLStatsEntry, tokenRingPStatsEntry, Waldbusser Standards Track [Page 11] RFC 4502 Remote Network Monitoring MIB May 2006 ringStationControlEntry, sourceRoutingStatsEntry FROM TOKEN-RING-RMON-MIB; -- Remote Network Monitoring MIB rmon MODULE-IDENTITY LAST-UPDATED "200605020000Z" -- May 2, 2006 ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "Author: Steve Waldbusser Phone: +1-650-948-6500 Fax : +1-650-745-0671 Email: waldbusser@nextbeacon.com Working Group Chair: Andy Bierman E-mail: ietf@andybierman.com Working Group Mailing List: To subscribe send email to: " DESCRIPTION "The MIB module for managing remote monitoring device implementations. This MIB module extends the architecture introduced in the original RMON MIB as specified in RFC 2819. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4502; see the RFC itself for full legal notices." REVISION "200605020000Z" -- May 2, 2006 DESCRIPTION "This version updates the proposed-standard version of the RMON2 MIB (published as RFC 2021) by adding 2 new enumerations to the nlMatrixTopNControlRateBase object and 4 new enumerations to the alMatrixTopNControlRateBase object. These new enumerations support the creation of high-capacity topN reports in the High Capacity RMON MIB [RFC3273]. Additionally, the following objects have been deprecated, as they have not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard: probeDownloadFile probeDownloadTFTPServer probeDownloadAction probeDownloadStatus Waldbusser Standards Track [Page 12] RFC 4502 Remote Network Monitoring MIB May 2006 serialMode serialProtocol serialTimeout serialModemInitString serialModemHangUpString serialModemConnectResp serialModemNoConnectResp serialDialoutTimeout serialStatus serialConnectDestIpAddress serialConnectType serialConnectDialString serialConnectSwitchConnectSeq serialConnectSwitchDisconnectSeq serialConnectSwitchResetSeq serialConnectOwner serialConnectStatus netConfigIPAddress netConfigSubnetMask netConfigStatus netDefaultGateway tokenRingMLStats2DroppedFrames tokenRingMLStats2CreateTime tokenRingPStats2DroppedFrames tokenRingPStats2CreateTime ringStationControl2DroppedFrames ringStationControl2CreateTime sourceRoutingStats2DroppedFrames sourceRoutingStats2CreateTime trapDestIndex trapDestCommunity trapDestProtocol trapDestAddress trapDestOwner trapDestStatus In addition, two corrections were made. The LastCreateTime Textual Convention had been defined with a base type of another textual convention, which isn't allowed in SMIv2. The definition has been modified to use TimeTicks as the base type. Further, the SerialConfigEntry SEQUENCE definition included sub-typing information that is not allowed in SMIv2. This information has been deleted. Ranges were added to a number of objects and textual-conventions to constrain their maximum (and sometimes minimum) sizes. The addition of these ranges documents existing practice for these objects. These objects Waldbusser Standards Track [Page 13] RFC 4502 Remote Network Monitoring MIB May 2006 are: ControlString protocolDirID protocolDirParameters addressMapNetworkAddress nlHostAddress nlMatrixSDSourceAddress nlMatrixSDDestAddress nlMatrixDSSourceAddress nlMatrixDSDestAddress nlMatrixTopNSourceAddress nlMatrixTopNDestAddress alHostEntry alMatrixSDEntry alMatrixDSEntry alMatrixTopNSourceAddress alMatrixTopNDestAddress Finally, the TimeFilter TC has been updated to encourage agent implementations that allow a MIB walk to behave well even when performed by an application that is not aware of the special TimeFilter semantics." REVISION "200207080000Z" -- 08 July, 2002 DESCRIPTION "Added new enumerations to support the High-Capacity RMON MIB as defined in RFC 3273. Also fixed some typos and added clarifications." REVISION "199605270000Z" -- 27 May, 1996 DESCRIPTION "Original version. Published as RFC 2021." ::= { mib-2 16 } -- { rmon 1 } through { rmon 10 } are defined in RMON and -- the Token Ring RMON MIB [RFC1513] protocolDir OBJECT IDENTIFIER ::= { rmon 11 } protocolDist OBJECT IDENTIFIER ::= { rmon 12 } addressMap OBJECT IDENTIFIER ::= { rmon 13 } nlHost OBJECT IDENTIFIER ::= { rmon 14 } nlMatrix OBJECT IDENTIFIER ::= { rmon 15 } alHost OBJECT IDENTIFIER ::= { rmon 16 } alMatrix OBJECT IDENTIFIER ::= { rmon 17 } usrHistory OBJECT IDENTIFIER ::= { rmon 18 } probeConfig OBJECT IDENTIFIER ::= { rmon 19 } rmonConformance OBJECT IDENTIFIER ::= { rmon 20 } Waldbusser Standards Track [Page 14] RFC 4502 Remote Network Monitoring MIB May 2006 -- Textual Conventions ZeroBasedCounter32 ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes an object that counts events with the following semantics: objects of this type will be set to zero(0) on creation and will thereafter count appropriate events, wrapping back to zero(0) when the value 2^32 is reached. Provided that an application discovers the new object within the minimum time to wrap, it can use the initial value as a delta since it last polled the table of which this object is part. It is important for a management station to be aware of this minimum time and the actual time between polls, and to discard data if the actual time is too long or there is no defined minimum time. Typically, this TC is used in tables where the INDEX space is constantly changing and/or the TimeFilter mechanism is in use." SYNTAX Gauge32 LastCreateTime ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes an object that stores the value of the sysUpTime object at the last time its entry was created. This can be used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all LastCreateTime objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects." SYNTAX TimeTicks TimeFilter ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "To be used for the index to a table. Allows an application to download only those rows changed since a particular time. Waldbusser Standards Track [Page 15] RFC 4502 Remote Network Monitoring MIB May 2006 Note that this is not a history mechanism. Only current values of underlying objects are returned; saved instance values associated with particular values of sysUpTime are not. An entry is considered changed if the value of any object in the entry changes, if the row is created, or if any object in the entry is created or deleted. Note that deleted entries cannot be detected or downloaded. A time-filtered conceptual table is created by inserting a single object of SYNTAX TimeFilter as the first INDEX component in a copy of an existing basic conceptual table (i.e., any SEQUENCE without a TimeFilter INDEX component). Thus, for each conceptual entry 'I' in the basic table, there exists N conceptual entries in the time-filtered version, indexed N.I, where 'N' is equal to the value of sysUpTime. When an application retrieves conceptual instances from a time-filtered table, and an INDEX value is provided for the TimeFilter INDEX component 'N', the agent will only consider returning basic conceptual entries (e.g., 'fooColumn.N.I') if any column within the basic conceptual entry has changed since sysUpTime 'N'. If not, the basic conceptual entry will be ignored for the particular retrieval operation. When sysUpTime is equal to zero, this table shall be empty. One conceptual entry exists for each past value of sysUpTime, except that the whole table is purged should sysUpTime wrap. As an entry in a time-filtered table is updated (i.e., one of the columns in the basic conceptual table is changed), new conceptual entries are also created in the time-filtered version (which still shares the now updated object values with all other instances). The number of unique time-filtered instances that are created is determined by the value of sysUpTime at which the basic entry was last updated. One unique instance will exist for each value of sysUpTime at the last update time for the row. However, a new TimeFilter index instance is created for each new sysUpTime value. The TimeFilter index values not associated with entry updates are called duplicate time-filtered instances. After some deployment experience, it has been determined that a time-filtered table is more efficient if the agent stops a MIB walk operation by skipping over rows with a TimeFilter index value higher than the value in the received GetNext/GetBulk request. That is, instead of incrementing a TimeFilter index value, the agent will continue to the next Waldbusser Standards Track [Page 16] RFC 4502 Remote Network Monitoring MIB May 2006 object or table. As a consequence, GetNext or GetBulk operations will provide only one pass through a time-filtered table. It is suggested that an agent implement a time-filtered table in this manner to improve performance and avoid a MIB walk getting stuck in time-filtered tables. It is, however, still acceptable for an agent to implement a time-filtered table in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses), and management applications must be able to deal with such traditional implementations. See the appendix for further discussion of this textual convention. The following example is provided to demonstrate TimeFilter behavior: Consider the following basic conceptual table, basicFooTable. (Note that the basic version of a time-filtered table may not actually be defined.) basicFooTable: basicFooTable ... INDEX { fooIndex } BasicFooEntry { fooIndex Integer32, fooCounts Counter32 } For this example, the basicFooTable contains two static conceptual entries (fooIndex equals '1' and '2'), created at time zero. It also contains one dynamic conceptual entry (fooIndex equals '3'), which is created at time '3' and deleted at time '7'. The time-filtered version of the basicFooTable could be defined as follows: FooTable: fooTable ... INDEX { fooTimeMark, fooIndex } FooEntry { Waldbusser Standards Track [Page 17] RFC 4502 Remote Network Monitoring MIB May 2006 fooTimeMark TimeFilter, fooIndex Integer32, fooCounts Counter32 } Note that entries exist in the time-filtered conceptual table only if they actually exist in the underlying (basic) table. For this example, the fooTable will have three underlying basic entries (fooIndex == 1, 2, and 3), with the following activity (for sysUpTime equal 0 to 9): - fooEntry.N.1 is created at time '0' and most recently updated at time '6' to the value '5'. - fooEntry.N.2 is created at time '0' and most recently updated at time '8' to the value '9'. - fooEntry.N.3 is created at time '3', updated at time '5' to the value '17', and deleted at time '7'. The following tables show the values that would be returned for MIB walk operations with various TimeFilter values, done at different times. An application issues a retrieval request at time 'T', with a TimeFilter value, 'N' (typically set to a lower value, such as the value of sysUpTime at the last polling cycle). The following values would be returned in a MIB walk of fooCounts.N if T equals '0' and N equals '0': fooCounts.N.I Value ========================== fooCounts.0.1 0 fooCounts.0.2 0 Note that nothing is returned for fooCounts.0.3, since that entry does not exist at sysUpTime equals '0'. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '3' and N equals '0': fooCounts.N.I Value ======================= fooCounts.0.1 0 fooCounts.0.2 0 fooCounts.0.3 0 fooCounts.1.3 0 fooCounts.2.3 0 fooCounts.3.3 0 Waldbusser Standards Track [Page 18] RFC 4502 Remote Network Monitoring MIB May 2006 Note that there are no instances for T equals 1 or 2 for the first two values of N, as these entries did not change since they were created at time '0'. Note that the current value for 'fooCounts.N.3' is returned here, even for values of N less than '3' (when the entry was created). The agent only considers the current existence of an entry in the TimeFilter algorithm, not the time when the entry was created. Note that the instances 'fooCounts.0.3', 'fooCounts.1.3', and 'fooCounts.2.3' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '6' and N equals '3': fooCounts.N.I Value ======================= fooCounts.3.1 5 fooCounts.3.3 17 fooCounts.4.1 5 fooCounts.4.3 17 fooCounts.5.1 5 fooCounts.5.3 17 fooCounts.6.1 5 Note that no instances for entry 'fooCounts.N.2' are returned, since it has not changed since time '3'. Note that all instances except 'fooCounts.5.3' and 'fooCounts.6.1' are duplicates and can be suppressed by the agent in a MIB walk. The following values would be returned in a full (traditional) MIB walk of fooCounts.N if T equals '9' and N equals '6': fooCounts.N.I Value ======================= fooCounts.6.1 5 fooCounts.6.2 9 fooCounts.7.2 9 fooCounts.8.2 9 Note that no instances for entry 'fooCounts.N.3' are returned, since it was deleted at time '7'. Note that instances 'fooCounts.6.2' and 'fooCounts.7.2' Waldbusser Standards Track [Page 19] RFC 4502 Remote Network Monitoring MIB May 2006 are duplicates and can be suppressed by the agent in a MIB walk." SYNTAX TimeTicks DataSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the source of the data that the associated function is configured to analyze. This source can be any interface on this device. In order to identify a particular interface, this object shall identify the instance of the ifIndex object, defined in [RFC2863], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1." SYNTAX OBJECT IDENTIFIER -- -- Protocol Directory Group -- -- Lists the inventory of protocols the probe has the capability of -- monitoring and allows the addition, deletion, and configuration of -- entries in this list. protocolDirLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the protocol directory was last modified, either through insertions or deletions, or through modifications of the protocolDirAddressMapConfig, protocolDirHostConfig, or protocolDirMatrixConfig." ::= { protocolDir 1 } protocolDirTable OBJECT-TYPE SYNTAX SEQUENCE OF ProtocolDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the protocols that this agent has the capability to decode and count. There is one entry in this table for each such protocol. These protocols represent different network-layer, transport-layer, and higher-layer Waldbusser Standards Track [Page 20] RFC 4502 Remote Network Monitoring MIB May 2006 protocols. The agent should boot up with this table preconfigured with those protocols that it knows about and wishes to monitor. Implementations are strongly encouraged to support protocols higher than the network layer (at least for the protocol distribution group), even for implementations that don't support the application-layer groups." ::= { protocolDir 2 } protocolDirEntry OBJECT-TYPE SYNTAX ProtocolDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the protocolDirTable. An example of the indexing of this entry is protocolDirLocalIndex.8.0.0.0.1.0.0.8.0.2.0.0, which is the encoding of a length of 8, followed by 8 subids encoding the protocolDirID of 1.2048, followed by a length of 2 and the 2 subids encoding zero-valued parameters. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { protocolDirID, protocolDirParameters } ::= { protocolDirTable 1 } ProtocolDirEntry ::= SEQUENCE { protocolDirID OCTET STRING, protocolDirParameters OCTET STRING, protocolDirLocalIndex Integer32, protocolDirDescr DisplayString, protocolDirType BITS, protocolDirAddressMapConfig INTEGER, protocolDirHostConfig INTEGER, protocolDirMatrixConfig INTEGER, protocolDirOwner OwnerString, protocolDirStatus RowStatus } protocolDirID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..128)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for a particular protocol. Standard identifiers will be defined in such a manner that they Waldbusser Standards Track [Page 21] RFC 4502 Remote Network Monitoring MIB May 2006 can often be used as specifications for new protocols - i.e., a tree-structured assignment mechanism that matches the protocol encapsulation 'tree' and that has algorithmic assignment mechanisms for certain subtrees. See RFC 2074 for more details. Despite the algorithmic mechanism, the probe will only place entries in here for those protocols it chooses to collect. In other words, it need not populate this table with all possible ethernet protocol types, nor need it create them on the fly when it sees them. Whether it does these things is a matter of product definition (cost/benefit, usability) and is up to the designer of the product. If an entry is written to this table with a protocolDirID that the agent doesn't understand, either directly or algorithmically, the SET request will be rejected with an inconsistentName or badValue (for SNMPv1) error." ::= { protocolDirEntry 1 } protocolDirParameters OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters for the associated protocolDirID. See the associated RMON2 Protocol Identifiers document for a description of the possible parameters. There will be one octet in this string for each sub-identifier in the protocolDirID, and the parameters will appear here in the same order as the associated sub-identifiers appear in the protocolDirID. Every node in the protocolDirID tree has a different, optional set of parameters defined (that is, the definition of parameters for a node is optional). The proper parameter value for each node is included in this string. Note that the inclusion of a parameter value in this string for each node is not optional. What is optional is that a node may have no parameters defined, in which case the parameter field for that node will be zero." ::= { protocolDirEntry 2 } protocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 22] RFC 4502 Remote Network Monitoring MIB May 2006 "The locally arbitrary but unique identifier associated with this protocolDir entry. The value for each supported protocol must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization, except that if a protocol is deleted and re-created, it must be re-created with a new value that has not been used since the last re-initialization. The specific value is meaningful only within a given SNMP entity. A protocolDirLocalIndex must not be re-used until the next agent restart in the event that the protocol directory entry is deleted." ::= { protocolDirEntry 3 } protocolDirDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "A textual description of the protocol encapsulation. A probe may choose to describe only a subset of the entire encapsulation (e.g., only the highest layer). This object is intended for human consumption only. This object may not be modified if the associated protocolDirStatus object is equal to active(1)." ::= { protocolDirEntry 4 } protocolDirType OBJECT-TYPE SYNTAX BITS { extensible(0), addressRecognitionCapable(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes 2 attributes of this protocol directory entry. The presence or absence of the 'extensible' bit describes whether this protocol directory entry can be extended by the user by creating protocol directory entries that are children of this protocol. An example of an entry that will often allow extensibility is Waldbusser Standards Track [Page 23] RFC 4502 Remote Network Monitoring MIB May 2006 'ip.udp'. The probe may automatically populate some children of this node, such as 'ip.udp.snmp' and 'ip.udp.dns'. A probe administrator or user may also populate additional children via remote SNMP requests that create entries in this table. When a child node is added for a protocol for which the probe has no built-in support extending a parent node (for which the probe does have built-in support), that child node is not extendable. This is termed 'limited extensibility'. When a child node is added through this extensibility mechanism, the values of protocolDirLocalIndex and protocolDirType shall be assigned by the agent. The other objects in the entry will be assigned by the manager who is creating the new entry. This object also describes whether this agent can recognize addresses for this protocol, should it be a network-level protocol. That is, while a probe may be able to recognize packets of a particular network-layer protocol and count them, it takes additional logic to be able to recognize the addresses in this protocol and to populate network-layer or application-layer tables with the addresses in this protocol. If this bit is set, the agent will recognize network-layer addresses for this protocol and populate the network- and application-layer host and matrix tables with these protocols. Note that when an entry is created, the agent will supply values for the bits that match the capabilities of the agent with respect to this protocol. Note that since row creations usually exercise the limited extensibility feature, these bits will usually be set to zero." ::= { protocolDirEntry 5 } protocolDirAddressMapConfig OBJECT-TYPE SYNTAX INTEGER { notSupported(1), supportedOff(2), supportedOn(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes and configures the probe's support for address mapping for this protocol. When the probe creates entries in this table for all protocols that it understands, Waldbusser Standards Track [Page 24] RFC 4502 Remote Network Monitoring MIB May 2006 it will set the entry to notSupported(1) if it doesn't have the capability to perform address mapping for the protocol or if this protocol is not a network-layer protocol. When an entry is created in this table by a management operation as part of the limited extensibility feature, the probe must set this value to notSupported(1), because limited extensibility of the protocolDirTable does not extend to interpreting addresses of the extended protocols. If the value of this object is notSupported(1), the probe will not perform address mapping for this protocol and shall not allow this object to be changed to any other value. If the value of this object is supportedOn(3), the probe supports address mapping for this protocol and is configured to perform address mapping for this protocol for all addressMappingControlEntries and all interfaces. If the value of this object is supportedOff(2), the probe supports address mapping for this protocol but is configured to not perform address mapping for this protocol for any addressMappingControlEntries and all interfaces. Whenever this value changes from supportedOn(3) to supportedOff(2), the probe shall delete all related entries in the addressMappingTable." ::= { protocolDirEntry 6 } protocolDirHostConfig OBJECT-TYPE SYNTAX INTEGER { notSupported(1), supportedOff(2), supportedOn(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes and configures the probe's support for the network-layer and application-layer host tables for this protocol. When the probe creates entries in this table for all protocols that it understands, it will set the entry to notSupported(1) if it doesn't have the capability to track the nlHostTable for this protocol or if the alHostTable is implemented but doesn't have the capability to track this protocol. Note that if the alHostTable is implemented, the probe may only support a protocol if it is supported in both the nlHostTable and the alHostTable. If the associated protocolDirType object has the addressRecognitionCapable bit set, then this is a network- layer protocol for which the probe recognizes addresses, and Waldbusser Standards Track [Page 25] RFC 4502 Remote Network Monitoring MIB May 2006 thus the probe will populate the nlHostTable and alHostTable with addresses it discovers for this protocol. If the value of this object is notSupported(1), the probe will not track the nlHostTable or alHostTable for this protocol and shall not allow this object to be changed to any other value. If the value of this object is supportedOn(3), the probe supports tracking of the nlHostTable and alHostTable for this protocol and is configured to track both tables for this protocol for all control entries and all interfaces. If the value of this object is supportedOff(2), the probe supports tracking of the nlHostTable and alHostTable for this protocol but is configured to not track these tables for any control entries or interfaces. Whenever this value changes from supportedOn(3) to supportedOff(2), the probe shall delete all related entries in the nlHostTable and alHostTable. Note that since each alHostEntry references 2 protocol directory entries, one for the network address and one for the type of the highest protocol recognized, an entry will only be created in that table if this value is supportedOn(3) for both protocols." ::= { protocolDirEntry 7 } protocolDirMatrixConfig OBJECT-TYPE SYNTAX INTEGER { notSupported(1), supportedOff(2), supportedOn(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object describes and configures the probe's support for the network-layer and application-layer matrix tables for this protocol. When the probe creates entries in this table for all protocols that it understands, it will set the entry to notSupported(1) if it doesn't have the capability to track the nlMatrixTables for this protocol or if the alMatrixTables are implemented but don't have the capability to track this protocol. Note that if the alMatrix tables are implemented, the probe may only support a protocol if it is supported in both of the nlMatrixTables and both of the alMatrixTables. If the associated protocolDirType object has the addressRecognitionCapable bit set, then this is a network- Waldbusser Standards Track [Page 26] RFC 4502 Remote Network Monitoring MIB May 2006 layer protocol for which the probe recognizes addresses, and thus the probe will populate both of the nlMatrixTables and both of the alMatrixTables with addresses it discovers for this protocol. If the value of this object is notSupported(1), the probe will not track either of the nlMatrixTables or the alMatrixTables for this protocol and shall not allow this object to be changed to any other value. If the value of this object is supportedOn(3), the probe supports tracking of both of the nlMatrixTables and (if implemented) both of the alMatrixTables for this protocol and is configured to track these tables for this protocol for all control entries and all interfaces. If the value of this object is supportedOff(2), the probe supports tracking of both of the nlMatrixTables and (if implemented) both of the alMatrixTables for this protocol but is configured to not track these tables for this protocol for any control entries or interfaces. Whenever this value changes from supportedOn(3) to supportedOff(2), the probe shall delete all related entries in the nlMatrixTables and the alMatrixTables. Note that since each alMatrixEntry references 2 protocol directory entries, one for the network address and one for the type of the highest protocol recognized, an entry will only be created in that table if this value is supportedOn(3) for both protocols." ::= { protocolDirEntry 8 } protocolDirOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { protocolDirEntry 9 } protocolDirStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this protocol directory entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. Waldbusser Standards Track [Page 27] RFC 4502 Remote Network Monitoring MIB May 2006 If this object is not equal to active(1), all associated entries in the nlHostTable, nlMatrixSDTable, nlMatrixDSTable, alHostTable, alMatrixSDTable, and alMatrixDSTable shall be deleted." ::= { protocolDirEntry 10 } -- -- Protocol Distribution Group (protocolDist) -- -- Collects the relative amounts of octets and packets for the -- different protocols detected on a network segment. -- protocolDistControlTable, -- protocolDistStatsTable protocolDistControlTable OBJECT-TYPE SYNTAX SEQUENCE OF ProtocolDistControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of protocol type distribution statistics tables. Implementations are encouraged to add an entry per monitored interface upon initialization so that a default collection of protocol statistics is available. Rationale: This table controls collection of very basic statistics for any or all of the protocols detected on a given interface. An NMS can use this table to quickly determine bandwidth allocation utilized by different protocols. A media-specific statistics collection could also be configured (e.g., etherStats, trPStats) to easily obtain total frame, octet, and droppedEvents for the same interface." ::= { protocolDist 1 } protocolDistControlEntry OBJECT-TYPE SYNTAX ProtocolDistControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the protocolDistControlTable. An example of the indexing of this entry is protocolDistControlDroppedFrames.7" INDEX { protocolDistControlIndex } Waldbusser Standards Track [Page 28] RFC 4502 Remote Network Monitoring MIB May 2006 ::= { protocolDistControlTable 1 } ProtocolDistControlEntry ::= SEQUENCE { protocolDistControlIndex Integer32, protocolDistControlDataSource DataSource, protocolDistControlDroppedFrames Counter32, protocolDistControlCreateTime LastCreateTime, protocolDistControlOwner OwnerString, protocolDistControlStatus RowStatus } protocolDistControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this protocolDistControlEntry." ::= { protocolDistControlEntry 1 } protocolDistControlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of data for the this protocol distribution. The statistics in this group reflect all packets on the local network segment attached to the identified interface. This object may not be modified if the associated protocolDistControlStatus object is equal to active(1)." ::= { protocolDistControlEntry 2 } protocolDistControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Waldbusser Standards Track [Page 29] RFC 4502 Remote Network Monitoring MIB May 2006 Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { protocolDistControlEntry 3 } protocolDistControlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { protocolDistControlEntry 4 } protocolDistControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { protocolDistControlEntry 5 } protocolDistControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the protocolDistStatsTable shall be deleted." ::= { protocolDistControlEntry 6 } -- per interface protocol distribution statistics table protocolDistStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF ProtocolDistStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry is made in this table for every protocol in the protocolDirTable that has been seen in at least one packet. Counters are updated in this table for every protocol type that is encountered when parsing a packet, but no counters are Waldbusser Standards Track [Page 30] RFC 4502 Remote Network Monitoring MIB May 2006 updated for packets with MAC-layer errors. Note that if a protocolDirEntry is deleted, all associated entries in this table are removed." ::= { protocolDist 2 } protocolDistStatsEntry OBJECT-TYPE SYNTAX ProtocolDistStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the protocolDistStatsTable. The index is composed of the protocolDistControlIndex of the associated protocolDistControlEntry, followed by the protocolDirLocalIndex of the associated protocol that this entry represents. In other words, the index identifies the protocol distribution an entry is a part of and the particular protocol that it represents. An example of the indexing of this entry is protocolDistStatsPkts.1.18" INDEX { protocolDistControlIndex, protocolDirLocalIndex } ::= { protocolDistStatsTable 1 } ProtocolDistStatsEntry ::= SEQUENCE { protocolDistStatsPkts ZeroBasedCounter32, protocolDistStatsOctets ZeroBasedCounter32 } protocolDistStatsPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type received without errors. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { protocolDistStatsEntry 1 } protocolDistStatsOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets of this protocol type Waldbusser Standards Track [Page 31] RFC 4502 Remote Network Monitoring MIB May 2006 received since it was added to the protocolDistStatsTable (excluding framing bits, but including FCS octets), except for those octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { protocolDistStatsEntry 2 } -- -- Address Map Group (addressMap) -- -- Lists MAC address to network address bindings discovered by the -- probe and what interface they were last seen on. -- addressMapControlTable -- addressMapTable addressMapInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an address mapping entry has been inserted into the addressMapTable. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. Note that the table size can be determined by subtracting addressMapDeletes from addressMapInserts." ::= { addressMap 1 } addressMapDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an address mapping entry has been deleted from the addressMapTable (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. Note that the table size can be determined by subtracting addressMapDeletes from addressMapInserts." ::= { addressMap 2 } addressMapMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-write Waldbusser Standards Track [Page 32] RFC 4502 Remote Network Monitoring MIB May 2006 STATUS current DESCRIPTION "The maximum number of entries that are desired in the addressMapTable. The probe will not create more than this number of entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. This object may be used to control how resources are allocated on the probe for the various RMON functions." ::= { addressMap 3 } addressMapControlTable OBJECT-TYPE SYNTAX SEQUENCE OF AddressMapControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table to control the collection of mappings from network layer address to physical address to interface. Note that this is not like the typical RMON controlTable and dataTable in which each entry creates its own data table. Each entry in this table enables the discovery of addresses on a new interface and the placement of address mappings into the central addressMapTable. Implementations are encouraged to add an entry per monitored interface upon initialization so that a default collection of address mappings is available." ::= { addressMap 4 } addressMapControlEntry OBJECT-TYPE SYNTAX AddressMapControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the addressMapControlTable. An example of the indexing of this entry is addressMapControlDroppedFrames.1" Waldbusser Standards Track [Page 33] RFC 4502 Remote Network Monitoring MIB May 2006 INDEX { addressMapControlIndex } ::= { addressMapControlTable 1 } AddressMapControlEntry ::= SEQUENCE { addressMapControlIndex Integer32, addressMapControlDataSource DataSource, addressMapControlDroppedFrames Counter32, addressMapControlOwner OwnerString, addressMapControlStatus RowStatus } addressMapControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this entry in the addressMapControlTable." ::= { addressMapControlEntry 1 } addressMapControlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of data for this addressMapControlEntry." ::= { addressMapControlEntry 2 } addressMapControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { addressMapControlEntry 3 } addressMapControlOwner OBJECT-TYPE SYNTAX OwnerString Waldbusser Standards Track [Page 34] RFC 4502 Remote Network Monitoring MIB May 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { addressMapControlEntry 4 } addressMapControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this addressMap control entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the addressMapTable shall be deleted." ::= { addressMapControlEntry 5 } addressMapTable OBJECT-TYPE SYNTAX SEQUENCE OF AddressMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of mappings from network layer address to physical address to interface. The probe will add entries to this table based on the source MAC and network addresses seen in packets without MAC-level errors. The probe will populate this table for all protocols in the protocol directory table whose value of protocolDirAddressMapConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirAddressMapConfig value of supportedOff(2)." ::= { addressMap 5 } addressMapEntry OBJECT-TYPE SYNTAX AddressMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the addressMapTable. The protocolDirLocalIndex in the index identifies the network layer protocol of the addressMapNetworkAddress. Waldbusser Standards Track [Page 35] RFC 4502 Remote Network Monitoring MIB May 2006 An example of the indexing of this entry is addressMapSource.783495.18.4.128.2.6.6.11.1.3.6.1.2.1.2.2.1.1.1. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { addressMapTimeMark, protocolDirLocalIndex, addressMapNetworkAddress, addressMapSource } ::= { addressMapTable 1 } AddressMapEntry ::= SEQUENCE { addressMapTimeMark TimeFilter, addressMapNetworkAddress OCTET STRING, addressMapSource OBJECT IDENTIFIER, addressMapPhysicalAddress OCTET STRING, addressMapLastChange TimeStamp } addressMapTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { addressMapEntry 1 } addressMapNetworkAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this relation. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { addressMapEntry 2 } addressMapSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER Waldbusser Standards Track [Page 36] RFC 4502 Remote Network Monitoring MIB May 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface or port on which the associated network address was most recently seen. If this address mapping was discovered on an interface, this object shall identify the instance of the ifIndex object, defined in [RFC2863], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to ifIndex.1. If this address mapping was discovered on a port, this object shall identify the instance of the rptrGroupPortIndex object, defined in [RFC2108], for the desired port. For example, if an entry were to receive data from group #1, port #1, this object would be set to rptrGroupPortIndex.1.1. Note that while the dataSource associated with this entry may only point to index objects, this object may at times point to repeater port objects. This situation occurs when the dataSource points to an interface that is a locally attached repeater and the agent has additional information about the source port of traffic seen on that repeater." ::= { addressMapEntry 3 } addressMapPhysicalAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The last source physical address on which the associated network address was seen. If the protocol of the associated network address was encapsulated inside of a network-level or higher protocol, this will be the address of the next-lower protocol with the addressRecognitionCapable bit enabled and will be formatted as specified for that protocol." ::= { addressMapEntry 4 } addressMapLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this entry was last created or the values of the physical address changed. Waldbusser Standards Track [Page 37] RFC 4502 Remote Network Monitoring MIB May 2006 This can be used to help detect duplicate address problems, in which case this object will be updated frequently." ::= { addressMapEntry 5 } -- -- Network Layer Host Group -- -- Counts the amount of traffic sent from and to each network address -- discovered by the probe. -- Note that while the hlHostControlTable also has objects that -- control an optional alHostTable, implementation of the alHostTable is -- not required to fully implement this group. hlHostControlTable OBJECT-TYPE SYNTAX SEQUENCE OF HlHostControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of higher-layer (i.e., non-MAC) host table control entries. These entries will enable the collection of the network- and application-level host tables indexed by network addresses. Both the network- and application-level host tables are controlled by this table so that they will both be created and deleted at the same time, further increasing the ease with which they can be implemented as a single datastore. (Note that if an implementation stores application-layer host records in memory, it can derive network-layer host records from them.) Entries in the nlHostTable will be created on behalf of each entry in this table. Additionally, if this probe implements the alHostTable, entries in the alHostTable will be created on behalf of each entry in this table. Implementations are encouraged to add an entry per monitored interface upon initialization so that a default collection of host statistics is available." ::= { nlHost 1 } hlHostControlEntry OBJECT-TYPE SYNTAX HlHostControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the hlHostControlTable. An example of the indexing of this entry is Waldbusser Standards Track [Page 38] RFC 4502 Remote Network Monitoring MIB May 2006 hlHostControlNlDroppedFrames.1" INDEX { hlHostControlIndex } ::= { hlHostControlTable 1 } HlHostControlEntry ::= SEQUENCE { hlHostControlIndex Integer32, hlHostControlDataSource DataSource, hlHostControlNlDroppedFrames Counter32, hlHostControlNlInserts Counter32, hlHostControlNlDeletes Counter32, hlHostControlNlMaxDesiredEntries Integer32, hlHostControlAlDroppedFrames Counter32, hlHostControlAlInserts Counter32, hlHostControlAlDeletes Counter32, hlHostControlAlMaxDesiredEntries Integer32, hlHostControlOwner OwnerString, hlHostControlStatus RowStatus } hlHostControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the hlHostControlTable. Each such entry defines a function that discovers hosts on a particular interface and places statistics about them in the nlHostTable, and optionally in the alHostTable, on behalf of this hlHostControlEntry." ::= { hlHostControlEntry 1 } hlHostControlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of data for the associated host tables. The statistics in this group reflect all packets on the local network segment attached to the identified interface. This object may not be modified if the associated hlHostControlStatus object is equal to active(1)." ::= { hlHostControlEntry 2 } hlHostControlNlDroppedFrames OBJECT-TYPE Waldbusser Standards Track [Page 39] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for the associated nlHost entries for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the nlHostTable is inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { hlHostControlEntry 3 } hlHostControlNlInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an nlHost entry has been inserted into the nlHost table. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlNlDeletes from hlHostControlNlInserts." ::= { hlHostControlEntry 4 } hlHostControlNlDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an nlHost entry has been Waldbusser Standards Track [Page 40] RFC 4502 Remote Network Monitoring MIB May 2006 deleted from the nlHost table (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlNlDeletes from hlHostControlNlInserts." ::= { hlHostControlEntry 5 } hlHostControlNlMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of entries that are desired in the nlHostTable on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlHostControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions." ::= { hlHostControlEntry 6 } hlHostControlAlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for the associated Waldbusser Standards Track [Page 41] RFC 4502 Remote Network Monitoring MIB May 2006 alHost entries for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the alHostTable is not implemented or is inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { hlHostControlEntry 7 } hlHostControlAlInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an alHost entry has been inserted into the alHost table. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlAlDeletes from hlHostControlAlInserts." ::= { hlHostControlEntry 8 } hlHostControlAlDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an alHost entry has been deleted from the alHost table (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For Waldbusser Standards Track [Page 42] RFC 4502 Remote Network Monitoring MIB May 2006 example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlHostControlAlDeletes from hlHostControlAlInserts." ::= { hlHostControlEntry 9 } hlHostControlAlMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of entries that are desired in the alHost table on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlHostControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions." ::= { hlHostControlEntry 10 } hlHostControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { hlHostControlEntry 11 } hlHostControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Waldbusser Standards Track [Page 43] RFC 4502 Remote Network Monitoring MIB May 2006 "The status of this hlHostControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nlHostTable and alHostTable shall be deleted." ::= { hlHostControlEntry 12 } nlHostTable OBJECT-TYPE SYNTAX SEQUENCE OF NlHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for a particular network layer address that has been discovered on an interface of this device. The probe will populate this table for all network layer protocols in the protocol directory table whose value of protocolDirHostConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirHostConfig value of supportedOff(2). The probe will add to this table all addresses seen as the source or destination address in all packets with no MAC errors, and will increment octet and packet counts in the table for all packets with no MAC errors." ::= { nlHost 2 } nlHostEntry OBJECT-TYPE SYNTAX NlHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the nlHostTable. The hlHostControlIndex value in the index identifies the hlHostControlEntry on whose behalf this entry was created. The protocolDirLocalIndex value in the index identifies the network layer protocol of the nlHostAddress. An example of the indexing of this entry is nlHostOutPkts.1.783495.18.4.128.2.6.6. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take Waldbusser Standards Track [Page 44] RFC 4502 Remote Network Monitoring MIB May 2006 care to avoid such combinations." INDEX { hlHostControlIndex, nlHostTimeMark, protocolDirLocalIndex, nlHostAddress } ::= { nlHostTable 1 } NlHostEntry ::= SEQUENCE { nlHostTimeMark TimeFilter, nlHostAddress OCTET STRING, nlHostInPkts ZeroBasedCounter32, nlHostOutPkts ZeroBasedCounter32, nlHostInOctets ZeroBasedCounter32, nlHostOutOctets ZeroBasedCounter32, nlHostOutMacNonUnicastPkts ZeroBasedCounter32, nlHostCreateTime LastCreateTime } nlHostTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { nlHostEntry 1 } nlHostAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this nlHostEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { nlHostEntry 2 } nlHostInPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted to Waldbusser Standards Track [Page 45] RFC 4502 Remote Network Monitoring MIB May 2006 this address since it was added to the nlHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlHostEntry 3 } nlHostOutPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted by this address since it was added to the nlHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlHostEntry 4 } nlHostInOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address since it was added to the nlHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { nlHostEntry 5 } nlHostOutOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted by this address since it was added to the nlHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { nlHostEntry 6 } Waldbusser Standards Track [Page 46] RFC 4502 Remote Network Monitoring MIB May 2006 nlHostOutMacNonUnicastPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted by this address that were directed to any MAC broadcast addresses or to any MAC multicast addresses since this host was added to the nlHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlHostEntry 7 } nlHostCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { nlHostEntry 8 } -- -- Network Layer Matrix Group -- -- Counts the amount of traffic sent between each pair of network -- addresses discovered by the probe. -- Note that while the hlMatrixControlTable also has objects that -- control optional alMatrixTables, implementation of the -- alMatrixTables is not required to fully implement this group. hlMatrixControlTable OBJECT-TYPE SYNTAX SEQUENCE OF HlMatrixControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of higher-layer (i.e., non-MAC) matrix control entries. These entries will enable the collection of the network- and application-level matrix tables containing conversation statistics indexed by pairs of network addresses. Both the network- and application-level matrix tables are controlled by this table so that they will both be created and deleted at the same time, further increasing the ease with which they can be implemented as a single datastore. (Note that if an implementation stores application-layer matrix records Waldbusser Standards Track [Page 47] RFC 4502 Remote Network Monitoring MIB May 2006 in memory, it can derive network-layer matrix records from them.) Entries in the nlMatrixSDTable and nlMatrixDSTable will be created on behalf of each entry in this table. Additionally, if this probe implements the alMatrix tables, entries in the alMatrix tables will be created on behalf of each entry in this table." ::= { nlMatrix 1 } hlMatrixControlEntry OBJECT-TYPE SYNTAX HlMatrixControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the hlMatrixControlTable. An example of indexing of this entry is hlMatrixControlNlDroppedFrames.1" INDEX { hlMatrixControlIndex } ::= { hlMatrixControlTable 1 } HlMatrixControlEntry ::= SEQUENCE { hlMatrixControlIndex Integer32, hlMatrixControlDataSource DataSource, hlMatrixControlNlDroppedFrames Counter32, hlMatrixControlNlInserts Counter32, hlMatrixControlNlDeletes Counter32, hlMatrixControlNlMaxDesiredEntries Integer32, hlMatrixControlAlDroppedFrames Counter32, hlMatrixControlAlInserts Counter32, hlMatrixControlAlDeletes Counter32, hlMatrixControlAlMaxDesiredEntries Integer32, hlMatrixControlOwner OwnerString, hlMatrixControlStatus RowStatus } hlMatrixControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the hlMatrixControlTable. Each such entry defines a function that discovers conversations on a particular interface and places statistics about them in the nlMatrixSDTable and the nlMatrixDSTable, and optionally the alMatrixSDTable and alMatrixDSTable, on behalf of this Waldbusser Standards Track [Page 48] RFC 4502 Remote Network Monitoring MIB May 2006 hlMatrixControlEntry." ::= { hlMatrixControlEntry 1 } hlMatrixControlDataSource OBJECT-TYPE SYNTAX DataSource MAX-ACCESS read-create STATUS current DESCRIPTION "The source of the data for the associated matrix tables. The statistics in this group reflect all packets on the local network segment attached to the identified interface. This object may not be modified if the associated hlMatrixControlStatus object is equal to active(1)." ::= { hlMatrixControlEntry 2 } hlMatrixControlNlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the nlMatrixTables are inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { hlMatrixControlEntry 3 } hlMatrixControlNlInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an nlMatrix entry has been inserted into the nlMatrix tables. If an entry is inserted, Waldbusser Standards Track [Page 49] RFC 4502 Remote Network Monitoring MIB May 2006 then deleted, and then inserted, this counter will be incremented by 2. The addition of a conversation into both the nlMatrixSDTable and nlMatrixDSTable shall be counted as two insertions (even though every addition into one table must be accompanied by an insertion into the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the sum of then nlMatrixSDTable and nlMatrixDSTable sizes can be determined by subtracting hlMatrixControlNlDeletes from hlMatrixControlNlInserts." ::= { hlMatrixControlEntry 4 } hlMatrixControlNlDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an nlMatrix entry has been deleted from the nlMatrix tables (for any reason). If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. The deletion of a conversation from both the nlMatrixSDTable and nlMatrixDSTable shall be counted as two deletions (even though every deletion from one table must be accompanied by a deletion from the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlMatrixControlNlDeletes from hlMatrixControlNlInserts." ::= { hlMatrixControlEntry 5 } hlMatrixControlNlMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION Waldbusser Standards Track [Page 50] RFC 4502 Remote Network Monitoring MIB May 2006 "The maximum number of entries that are desired in the nlMatrix tables on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlMatrixControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions." ::= { hlMatrixControlEntry 6 } hlMatrixControlAlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that if the alMatrixTables are not implemented or are inactive because no protocols are enabled in the protocol directory, this value should be 0. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { hlMatrixControlEntry 7 } hlMatrixControlAlInserts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 51] RFC 4502 Remote Network Monitoring MIB May 2006 "The number of times an alMatrix entry has been inserted into the alMatrix tables. If an entry is inserted, then deleted, and then inserted, this counter will be incremented by 2. The addition of a conversation into both the alMatrixSDTable and alMatrixDSTable shall be counted as two insertions (even though every addition into one table must be accompanied by an insertion into the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlMatrixControlAlDeletes from hlMatrixControlAlInserts." ::= { hlMatrixControlEntry 8 } hlMatrixControlAlDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an alMatrix entry has been deleted from the alMatrix tables. If an entry is deleted, then inserted, and then deleted, this counter will be incremented by 2. The deletion of a conversation from both the alMatrixSDTable and alMatrixDSTable shall be counted as two deletions (even though every deletion from one table must be accompanied by a deletion from the other). To allow for efficient implementation strategies, agents may delay updating this object for short periods of time. For example, an implementation strategy may allow internal data structures to differ from those visible via SNMP for short periods of time. This counter may reflect the internal data structures for those short periods of time. Note that the table size can be determined by subtracting hlMatrixControlAlDeletes from hlMatrixControlAlInserts." ::= { hlMatrixControlEntry 9 } hlMatrixControlAlMaxDesiredEntries OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION Waldbusser Standards Track [Page 52] RFC 4502 Remote Network Monitoring MIB May 2006 "The maximum number of entries that are desired in the alMatrix tables on behalf of this control entry. The probe will not create more than this number of associated entries in the table but may choose to create fewer entries in this table for any reason, including the lack of resources. If this object is set to a value less than the current number of entries, enough entries are chosen in an implementation-dependent manner and deleted so that the number of entries in the table equals the value of this object. If this value is set to -1, the probe may create any number of entries in this table. If the associated hlMatrixControlStatus object is equal to 'active', this object may not be modified. This object may be used to control how resources are allocated on the probe for the various RMON functions." ::= { hlMatrixControlEntry 10 } hlMatrixControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { hlMatrixControlEntry 11 } hlMatrixControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this hlMatrixControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nlMatrixSDTable, nlMatrixDSTable, alMatrixSDTable, and alMatrixDSTable shall be deleted by the agent." ::= { hlMatrixControlEntry 12 } nlMatrixSDTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixSDEntry MAX-ACCESS not-accessible Waldbusser Standards Track [Page 53] RFC 4502 Remote Network Monitoring MIB May 2006 STATUS current DESCRIPTION "A list of traffic matrix entries that collect statistics for conversations between two network-level addresses. This table is indexed first by the source address and then by the destination address to make it convenient to collect all conversations from a particular address. The probe will populate this table for all network layer protocols in the protocol directory table whose value of protocolDirMatrixConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirMatrixConfig value of supportedOff(2). The probe will add to this table all pairs of addresses seen in all packets with no MAC errors and will increment octet and packet counts in the table for all packets with no MAC errors. Further, this table will only contain entries that have a corresponding entry in the nlMatrixDSTable with the same source address and destination address." ::= { nlMatrix 2 } nlMatrixSDEntry OBJECT-TYPE SYNTAX NlMatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the nlMatrixSDTable. The hlMatrixControlIndex value in the index identifies the hlMatrixControlEntry on whose behalf this entry was created. The protocolDirLocalIndex value in the index identifies the network-layer protocol of the nlMatrixSDSourceAddress and nlMatrixSDDestAddress. An example of the indexing of this table is nlMatrixSDPkts.1.783495.18.4.128.2.6.6.4.128.2.6.7. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { hlMatrixControlIndex, nlMatrixSDTimeMark, protocolDirLocalIndex, nlMatrixSDSourceAddress, nlMatrixSDDestAddress } ::= { nlMatrixSDTable 1 } Waldbusser Standards Track [Page 54] RFC 4502 Remote Network Monitoring MIB May 2006 NlMatrixSDEntry ::= SEQUENCE { nlMatrixSDTimeMark TimeFilter, nlMatrixSDSourceAddress OCTET STRING, nlMatrixSDDestAddress OCTET STRING, nlMatrixSDPkts ZeroBasedCounter32, nlMatrixSDOctets ZeroBasedCounter32, nlMatrixSDCreateTime LastCreateTime } nlMatrixSDTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { nlMatrixSDEntry 1 } nlMatrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixSDEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { nlMatrixSDEntry 2 } nlMatrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixSDEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an Waldbusser Standards Track [Page 55] RFC 4502 Remote Network Monitoring MIB May 2006 encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { nlMatrixSDEntry 3 } nlMatrixSDPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted from the source address to the destination address since this entry was added to the nlMatrixSDTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlMatrixSDEntry 4 } nlMatrixSDOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted from the source address to the destination address since this entry was added to the nlMatrixSDTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { nlMatrixSDEntry 5 } nlMatrixSDCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { nlMatrixSDEntry 6 } -- Traffic matrix tables from destination to source nlMatrixDSTable OBJECT-TYPE Waldbusser Standards Track [Page 56] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX SEQUENCE OF NlMatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of traffic matrix entries that collect statistics for conversations between two network-level addresses. This table is indexed first by the destination address and then by the source address to make it convenient to collect all conversations to a particular address. The probe will populate this table for all network layer protocols in the protocol directory table whose value of protocolDirMatrixConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirMatrixConfig value of supportedOff(2). The probe will add to this table all pairs of addresses seen in all packets with no MAC errors and will increment octet and packet counts in the table for all packets with no MAC errors. Further, this table will only contain entries that have a corresponding entry in the nlMatrixSDTable with the same source address and destination address." ::= { nlMatrix 3 } nlMatrixDSEntry OBJECT-TYPE SYNTAX NlMatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the nlMatrixDSTable. The hlMatrixControlIndex value in the index identifies the hlMatrixControlEntry on whose behalf this entry was created. The protocolDirLocalIndex value in the index identifies the network-layer protocol of the nlMatrixDSSourceAddress and nlMatrixDSDestAddress. An example of the indexing of this table is nlMatrixDSPkts.1.783495.18.4.128.2.6.7.4.128.2.6.6. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { hlMatrixControlIndex, nlMatrixDSTimeMark, protocolDirLocalIndex, Waldbusser Standards Track [Page 57] RFC 4502 Remote Network Monitoring MIB May 2006 nlMatrixDSDestAddress, nlMatrixDSSourceAddress } ::= { nlMatrixDSTable 1 } NlMatrixDSEntry ::= SEQUENCE { nlMatrixDSTimeMark TimeFilter, nlMatrixDSSourceAddress OCTET STRING, nlMatrixDSDestAddress OCTET STRING, nlMatrixDSPkts ZeroBasedCounter32, nlMatrixDSOctets ZeroBasedCounter32, nlMatrixDSCreateTime LastCreateTime } nlMatrixDSTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { nlMatrixDSEntry 1 } nlMatrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixDSEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { nlMatrixDSEntry 2 } nlMatrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixDSEntry. This is represented as an octet string with specific semantics and length as identified Waldbusser Standards Track [Page 58] RFC 4502 Remote Network Monitoring MIB May 2006 by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { nlMatrixDSEntry 3 } nlMatrixDSPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted from the source address to the destination address since this entry was added to the nlMatrixDSTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { nlMatrixDSEntry 4 } nlMatrixDSOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted from the source address to the destination address since this entry was added to the nlMatrixDSTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { nlMatrixDSEntry 5 } nlMatrixDSCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { nlMatrixDSEntry 6 } nlMatrixTopNControlTable OBJECT-TYPE Waldbusser Standards Track [Page 59] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX SEQUENCE OF NlMatrixTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N matrix entries according to a selected metric." ::= { nlMatrix 4 } nlMatrixTopNControlEntry OBJECT-TYPE SYNTAX NlMatrixTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the nlMatrixTopNControlTable. An example of the indexing of this table is nlMatrixTopNControlDuration.3" INDEX { nlMatrixTopNControlIndex } ::= { nlMatrixTopNControlTable 1 } NlMatrixTopNControlEntry ::= SEQUENCE { nlMatrixTopNControlIndex Integer32, nlMatrixTopNControlMatrixIndex Integer32, nlMatrixTopNControlRateBase INTEGER, nlMatrixTopNControlTimeRemaining Integer32, nlMatrixTopNControlGeneratedReports Counter32, nlMatrixTopNControlDuration Integer32, nlMatrixTopNControlRequestedSize Integer32, nlMatrixTopNControlGrantedSize Integer32, nlMatrixTopNControlStartTime TimeStamp, nlMatrixTopNControlOwner OwnerString, nlMatrixTopNControlStatus RowStatus } nlMatrixTopNControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the nlMatrixTopNControlTable. Each such entry defines one topN report prepared for one interface." ::= { nlMatrixTopNControlEntry 1 } nlMatrixTopNControlMatrixIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) Waldbusser Standards Track [Page 60] RFC 4502 Remote Network Monitoring MIB May 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The nlMatrix[SD/DS] table for which a topN report will be prepared on behalf of this entry. The nlMatrix[SD/DS] table is identified by the value of the hlMatrixControlIndex for that table - that value is used here to identify the particular table. This object may not be modified if the associated nlMatrixTopNControlStatus object is equal to active(1)." ::= { nlMatrixTopNControlEntry 2 } nlMatrixTopNControlRateBase OBJECT-TYPE SYNTAX INTEGER { nlMatrixTopNPkts(1), nlMatrixTopNOctets(2), nlMatrixTopNHighCapacityPkts(3), nlMatrixTopNHighCapacityOctets(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable for each nlMatrix[SD/DS] entry that the nlMatrixTopNEntries are sorted by, as well as a control for the table that the results will be reported in. This object may not be modified if the associated nlMatrixTopNControlStatus object is equal to active(1). If this value is less than or equal to 2, when the report is prepared, entries are created in the nlMatrixTopNTable associated with this object. If this value is greater than or equal to 3, when the report is prepared, entries are created in the nlMatrixTopNHighCapacityTable associated with this object." ::= { nlMatrixTopNControlEntry 3 } nlMatrixTopNControlTimeRemaining OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this Waldbusser Standards Track [Page 61] RFC 4502 Remote Network Monitoring MIB May 2006 report and is immediately loaded into the associated nlMatrixTopNControlDuration object. When the report finishes, the probe will automatically start another collection with the same initial value of nlMatrixTopNControlTimeRemaining. Thus, the management station may simply read the resulting reports repeatedly, checking the startTime and duration each time to ensure that a report was not missed or that the report parameters were not changed. While the value of this object is non-zero, it decrements by one per second until it reaches zero. At the time that this object decrements to zero, the report is made accessible in the nlMatrixTopNTable, overwriting any report that may be there. When this object is modified by the management station, any associated entries in the nlMatrixTopNTable shall be deleted. (Note that this is a different algorithm than the one used in the hostTopNTable)." DEFVAL { 1800 } ::= { nlMatrixTopNControlEntry 4 } nlMatrixTopNControlGeneratedReports OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reports that have been generated by this entry." ::= { nlMatrixTopNControlEntry 5 } nlMatrixTopNControlDuration OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval. When the associated nlMatrixTopNControlTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the nlMatrixTopNControlTimeRemaining is set. This value shall be zero if no reports have been requested for this nlMatrixTopNControlEntry." Waldbusser Standards Track [Page 62] RFC 4502 Remote Network Monitoring MIB May 2006 ::= { nlMatrixTopNControlEntry 6 } nlMatrixTopNControlRequestedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of matrix entries requested for this report. When this object is created or modified, the probe should set nlMatrixTopNControlGrantedSize as closely to this object as possible for the particular probe implementation and available resources." DEFVAL { 150 } ::= { nlMatrixTopNControlEntry 7 } nlMatrixTopNControlGrantedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of matrix entries in this report. When the associated nlMatrixTopNControlRequestedSize object is created or modified, the probe should set this object as closely to the requested value as possible for the particular implementation and available resources. The probe must not lower this value except as a side-effect of a set to the associated nlMatrixTopNControlRequestedSize object. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNPkts, when the next topN report is generated, matrix entries with the highest value of nlMatrixTopNPktRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNOctets, when the next topN report is generated, matrix entries with the highest value of nlMatrixTopNOctetRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. It is an implementation-specific matter how entries with the same value of nlMatrixTopNPktRate or nlMatrixTopNOctetRate are sorted. It is also an implementation-specific matter as to Waldbusser Standards Track [Page 63] RFC 4502 Remote Network Monitoring MIB May 2006 whether zero-valued entries are available." ::= { nlMatrixTopNControlEntry 8 } nlMatrixTopNControlStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this topN report was last started. In other words, this is the time that the associated nlMatrixTopNControlTimeRemaining object was modified to start the requested report or the time the report was last automatically (re)started. This object may be used by the management station to determine whether a report was missed." ::= { nlMatrixTopNControlEntry 9 } nlMatrixTopNControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { nlMatrixTopNControlEntry 10 } nlMatrixTopNControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this nlMatrixTopNControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nlMatrixTopNTable shall be deleted by the agent." ::= { nlMatrixTopNControlEntry 11 } nlMatrixTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for those network-layer matrix entries Waldbusser Standards Track [Page 64] RFC 4502 Remote Network Monitoring MIB May 2006 that have counted the highest number of octets or packets." ::= { nlMatrix 5 } nlMatrixTopNEntry OBJECT-TYPE SYNTAX NlMatrixTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the nlMatrixTopNTable. The nlMatrixTopNControlIndex value in the index identifies the nlMatrixTopNControlEntry on whose behalf this entry was created. An example of the indexing of this table is nlMatrixTopNPktRate.3.10" INDEX { nlMatrixTopNControlIndex, nlMatrixTopNIndex } ::= { nlMatrixTopNTable 1 } NlMatrixTopNEntry ::= SEQUENCE { nlMatrixTopNIndex Integer32, nlMatrixTopNProtocolDirLocalIndex Integer32, nlMatrixTopNSourceAddress OCTET STRING, nlMatrixTopNDestAddress OCTET STRING, nlMatrixTopNPktRate Gauge32, nlMatrixTopNReversePktRate Gauge32, nlMatrixTopNOctetRate Gauge32, nlMatrixTopNReverseOctetRate Gauge32 } nlMatrixTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the nlMatrixTopNTable among those in the same report. This index is between 1 and N, where N is the number of entries in this report. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNPkts, increasing values of nlMatrixTopNIndex shall be assigned to entries with decreasing values of nlMatrixTopNPktRate until index N is assigned or there are no more nlMatrixTopNEntries. If the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNOctets, increasing values of nlMatrixTopNIndex Waldbusser Standards Track [Page 65] RFC 4502 Remote Network Monitoring MIB May 2006 shall be assigned to entries with decreasing values of nlMatrixTopNOctetRate until index N is assigned or there are no more nlMatrixTopNEntries." ::= { nlMatrixTopNEntry 1 } nlMatrixTopNProtocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex of the network-layer protocol of this entry's network address." ::= { nlMatrixTopNEntry 2 } nlMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the protocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { nlMatrixTopNEntry 3 } nlMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the nlMatrixTopNProtocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." Waldbusser Standards Track [Page 66] RFC 4502 Remote Network Monitoring MIB May 2006 ::= { nlMatrixTopNEntry 4 } nlMatrixTopNPktRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the source host to the destination host during this sampling interval, counted using the rules for counting the nlMatrixSDPkts object. If the value of nlMatrixTopNControlRateBase is nlMatrixTopNPkts, this variable will be used to sort this report." ::= { nlMatrixTopNEntry 5 } nlMatrixTopNReversePktRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen from the destination host to the source host during this sampling interval, counted using the rules for counting the nlMatrixSDPkts object. (Note that the corresponding nlMatrixSDPkts object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNPkts, the sort of topN entries is based entirely on nlMatrixTopNPktRate, and not on the value of this object." ::= { nlMatrixTopNEntry 6 } nlMatrixTopNOctetRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen from the source host to the destination host during this sampling interval, counted using the rules for counting the nlMatrixSDOctets object. If the value of nlMatrixTopNControlRateBase is nlMatrixTopNOctets, this variable will be used to sort this report." ::= { nlMatrixTopNEntry 7 } nlMatrixTopNReverseOctetRate OBJECT-TYPE Waldbusser Standards Track [Page 67] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen from the destination host to the source host during this sampling interval, counted using the rules for counting the nlMatrixDSOctets object. (Note that the corresponding nlMatrixSDOctets object selected is the one whose source address is equal to nlMatrixTopNDestAddress and whose destination address is equal to nlMatrixTopNSourceAddress.) Note that if the value of nlMatrixTopNControlRateBase is equal to nlMatrixTopNOctets, the sort of topN entries is based entirely on nlMatrixTopNOctetRate, and not on the value of this object." ::= { nlMatrixTopNEntry 8 } -- Application Layer Functions -- -- The application layer host, matrix, and matrixTopN functions report -- on protocol usage at the network layer or higher. Note that the -- use of the term application layer does not imply that only -- application-layer protocols are counted, rather it means that -- protocols up to and including the application layer are supported. -- -- Application Layer Host Group -- -- Counts the amount of traffic, by protocol, sent from and to each -- network address discovered by the probe. -- Implementation of this group requires implementation of the Network -- Layer Host Group. alHostTable OBJECT-TYPE SYNTAX SEQUENCE OF AlHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for a particular protocol from a particular network address that has been discovered on an interface of this device. The probe will populate this table for all protocols in the protocol directory table whose value of protocolDirHostConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirHostConfig value of supportedOff(2). Waldbusser Standards Track [Page 68] RFC 4502 Remote Network Monitoring MIB May 2006 The probe will add to this table all addresses seen as the source or destination address in all packets with no MAC errors and will increment octet and packet counts in the table for all packets with no MAC errors. Further, entries will only be added to this table if their address exists in the nlHostTable and will be deleted from this table if their address is deleted from the nlHostTable." ::= { alHost 1 } alHostEntry OBJECT-TYPE SYNTAX AlHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the alHostTable. The hlHostControlIndex value in the index identifies the hlHostControlEntry on whose behalf this entry was created. The first protocolDirLocalIndex value in the index identifies the network-layer protocol of the address. The nlHostAddress value in the index identifies the network- layer address of this entry. The second protocolDirLocalIndex value in the index identifies the protocol that is counted by this entry. An example of the indexing in this entry is alHostOutPkts.1.783495.18.4.128.2.6.6.34. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { hlHostControlIndex, alHostTimeMark, protocolDirLocalIndex, nlHostAddress, protocolDirLocalIndex } ::= { alHostTable 1 } AlHostEntry ::= SEQUENCE { alHostTimeMark TimeFilter, alHostInPkts ZeroBasedCounter32, alHostOutPkts ZeroBasedCounter32, alHostInOctets ZeroBasedCounter32, alHostOutOctets ZeroBasedCounter32, alHostCreateTime LastCreateTime } alHostTimeMark OBJECT-TYPE SYNTAX TimeFilter Waldbusser Standards Track [Page 69] RFC 4502 Remote Network Monitoring MIB May 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { alHostEntry 1 } alHostInPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type without errors transmitted to this address since it was added to the alHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alHostEntry 2 } alHostOutPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type without errors transmitted by this address since it was added to the alHostTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alHostEntry 3 } alHostInOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address of this protocol type since it was added to the alHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { alHostEntry 4 } Waldbusser Standards Track [Page 70] RFC 4502 Remote Network Monitoring MIB May 2006 alHostOutOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted by this address of this protocol type since it was added to the alHostTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { alHostEntry 5 } alHostCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { alHostEntry 6 } -- -- Application Layer Matrix Group -- -- Counts the amount of traffic, by protocol, sent between each pair -- of network addresses discovered by the probe. -- Implementation of this group requires implementation of the Network -- Layer Matrix Group. alMatrixSDTable OBJECT-TYPE SYNTAX SEQUENCE OF AlMatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of application traffic matrix entries that collect statistics for conversations of a particular protocol between two network-level addresses. This table is indexed first by the source address and then by the destination address to make it convenient to collect all statistics from a particular address. The probe will populate this table for all protocols in the protocol directory table whose value of Waldbusser Standards Track [Page 71] RFC 4502 Remote Network Monitoring MIB May 2006 protocolDirMatrixConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirMatrixConfig value of supportedOff(2). The probe will add to this table all pairs of addresses for all protocols seen in all packets with no MAC errors and will increment octet and packet counts in the table for all packets with no MAC errors. Further, entries will only be added to this table if their address pair exists in the nlMatrixSDTable and will be deleted from this table if the address pair is deleted from the nlMatrixSDTable." ::= { alMatrix 1 } alMatrixSDEntry OBJECT-TYPE SYNTAX AlMatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the alMatrixSDTable. The hlMatrixControlIndex value in the index identifies the hlMatrixControlEntry on whose behalf this entry was created. The first protocolDirLocalIndex value in the index identifies the network-layer protocol of the nlMatrixSDSourceAddress and nlMatrixSDDestAddress. The nlMatrixSDSourceAddress value in the index identifies the network-layer address of the source host in this conversation. The nlMatrixSDDestAddress value in the index identifies the network-layer address of the destination host in this conversation. The second protocolDirLocalIndex value in the index identifies the protocol that is counted by this entry. An example of the indexing of this entry is alMatrixSDPkts.1.783495.18.4.128.2.6.6.4.128.2.6.7.34. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { hlMatrixControlIndex, alMatrixSDTimeMark, protocolDirLocalIndex, nlMatrixSDSourceAddress, nlMatrixSDDestAddress, protocolDirLocalIndex } ::= { alMatrixSDTable 1 } AlMatrixSDEntry ::= SEQUENCE { alMatrixSDTimeMark TimeFilter, Waldbusser Standards Track [Page 72] RFC 4502 Remote Network Monitoring MIB May 2006 alMatrixSDPkts ZeroBasedCounter32, alMatrixSDOctets ZeroBasedCounter32, alMatrixSDCreateTime LastCreateTime } alMatrixSDTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { alMatrixSDEntry 1 } alMatrixSDPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type without errors transmitted from the source address to the destination address since this entry was added to the alMatrixSDTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alMatrixSDEntry 2 } alMatrixSDOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixSDTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { alMatrixSDEntry 3 } alMatrixSDCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 73] RFC 4502 Remote Network Monitoring MIB May 2006 "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { alMatrixSDEntry 4 } -- Traffic matrix tables from destination to source alMatrixDSTable OBJECT-TYPE SYNTAX SEQUENCE OF AlMatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of application traffic matrix entries that collect statistics for conversations of a particular protocol between two network-level addresses. This table is indexed first by the destination address and then by the source address to make it convenient to collect all statistics to a particular address. The probe will populate this table for all protocols in the protocol directory table whose value of protocolDirMatrixConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirMatrixConfig value of supportedOff(2). The probe will add to this table all pairs of addresses for all protocols seen in all packets with no MAC errors and will increment octet and packet counts in the table for all packets with no MAC errors. Further, entries will only be added to this table if their address pair exists in the nlMatrixDSTable and will be deleted from this table if the address pair is deleted from the nlMatrixDSTable." ::= { alMatrix 2 } alMatrixDSEntry OBJECT-TYPE SYNTAX AlMatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the alMatrixDSTable. The hlMatrixControlIndex value in the index identifies the hlMatrixControlEntry on whose behalf this entry was created. The first protocolDirLocalIndex value in the index identifies the network-layer protocol of the alMatrixDSSourceAddress and alMatrixDSDestAddress. The nlMatrixDSDestAddress value in the index identifies the network-layer address of the destination host in this Waldbusser Standards Track [Page 74] RFC 4502 Remote Network Monitoring MIB May 2006 conversation. The nlMatrixDSSourceAddress value in the index identifies the network-layer address of the source host in this conversation. The second protocolDirLocalIndex value in the index identifies the protocol that is counted by this entry. An example of the indexing of this entry is alMatrixDSPkts.1.783495.18.4.128.2.6.7.4.128.2.6.6.34. Note that some combinations of index values may result in an index that exceeds 128 sub-identifiers in length, which exceeds the maximum for the SNMP protocol. Implementations should take care to avoid such combinations." INDEX { hlMatrixControlIndex, alMatrixDSTimeMark, protocolDirLocalIndex, nlMatrixDSDestAddress, nlMatrixDSSourceAddress, protocolDirLocalIndex } ::= { alMatrixDSTable 1 } AlMatrixDSEntry ::= SEQUENCE { alMatrixDSTimeMark TimeFilter, alMatrixDSPkts ZeroBasedCounter32, alMatrixDSOctets ZeroBasedCounter32, alMatrixDSCreateTime LastCreateTime } alMatrixDSTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESS not-accessible STATUS current DESCRIPTION "A TimeFilter for this entry. See the TimeFilter textual convention to see how this works." ::= { alMatrixDSEntry 1 } alMatrixDSPkts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets of this protocol type without errors transmitted from the source address to the destination address since this entry was added to the alMatrixDSTable. Note that this is the number of link-layer packets, so if a single network-layer packet is fragmented into several link-layer frames, this counter is incremented several times." ::= { alMatrixDSEntry 2 } Waldbusser Standards Track [Page 75] RFC 4502 Remote Network Monitoring MIB May 2006 alMatrixDSOctets OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets in packets of this protocol type transmitted from the source address to the destination address since this entry was added to the alMatrixDSTable (excluding framing bits, but including FCS octets), excluding octets in packets that contained errors. Note that this doesn't count just those octets in the particular protocol frames but includes the entire packet that contained the protocol." ::= { alMatrixDSEntry 3 } alMatrixDSCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last activated. This can be used by the management station to ensure that the entry has not been deleted and recreated between polls." ::= { alMatrixDSEntry 4 } alMatrixTopNControlTable OBJECT-TYPE SYNTAX SEQUENCE OF AlMatrixTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of parameters that control the creation of a report of the top N matrix entries according to a selected metric." ::= { alMatrix 3 } alMatrixTopNControlEntry OBJECT-TYPE SYNTAX AlMatrixTopNControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the alMatrixTopNControlTable. An example of the indexing of this table is alMatrixTopNControlDuration.3" INDEX { alMatrixTopNControlIndex } ::= { alMatrixTopNControlTable 1 } Waldbusser Standards Track [Page 76] RFC 4502 Remote Network Monitoring MIB May 2006 AlMatrixTopNControlEntry ::= SEQUENCE { alMatrixTopNControlIndex Integer32, alMatrixTopNControlMatrixIndex Integer32, alMatrixTopNControlRateBase INTEGER, alMatrixTopNControlTimeRemaining Integer32, alMatrixTopNControlGeneratedReports Counter32, alMatrixTopNControlDuration Integer32, alMatrixTopNControlRequestedSize Integer32, alMatrixTopNControlGrantedSize Integer32, alMatrixTopNControlStartTime TimeStamp, alMatrixTopNControlOwner OwnerString, alMatrixTopNControlStatus RowStatus } alMatrixTopNControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the alMatrixTopNControlTable. Each such entry defines one topN report prepared for one interface." ::= { alMatrixTopNControlEntry 1 } alMatrixTopNControlMatrixIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The alMatrix[SD/DS] table for which a topN report will be prepared on behalf of this entry. The alMatrix[SD/DS] table is identified by the value of the hlMatrixControlIndex for that table - that value is used here to identify the particular table. This object may not be modified if the associated alMatrixTopNControlStatus object is equal to active(1)." ::= { alMatrixTopNControlEntry 2 } alMatrixTopNControlRateBase OBJECT-TYPE SYNTAX INTEGER { alMatrixTopNTerminalsPkts(1), alMatrixTopNTerminalsOctets(2), alMatrixTopNAllPkts(3), alMatrixTopNAllOctets(4), alMatrixTopNTerminalsHighCapacityPkts(5), alMatrixTopNTerminalsHighCapacityOctets(6), Waldbusser Standards Track [Page 77] RFC 4502 Remote Network Monitoring MIB May 2006 alMatrixTopNAllHighCapacityPkts(7), alMatrixTopNAllHighCapacityOctets(8) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls which alMatrix[SD/DS] entry that the alMatrixTopNEntries are sorted by, which view of the matrix table that will be used, as well as which table the results will be reported in. The values alMatrixTopNTerminalsPkts, alMatrixTopNTerminalsOctets, alMatrixTopNTerminalsHighCapacityPkts, and alMatrixTopNTerminalsHighCapacityOctets cause collection only from protocols that have no child protocols that are counted. The values alMatrixTopNAllPkts, alMatrixTopNAllOctets, alMatrixTopNAllHighCapacityPkts, and alMatrixTopNAllHighCapacityOctets cause collection from all alMatrix entries. This object may not be modified if the associated alMatrixTopNControlStatus object is equal to active(1)." ::= { alMatrixTopNControlEntry 3 } alMatrixTopNControlTimeRemaining OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds left in the report currently being collected. When this object is modified by the management station, a new collection is started, possibly aborting a currently running report. The new value is used as the requested duration of this report and is immediately loaded into the associated alMatrixTopNControlDuration object. When the report finishes, the probe will automatically start another collection with the same initial value of alMatrixTopNControlTimeRemaining. Thus, the management station may simply read the resulting reports repeatedly, checking the startTime and duration each time to ensure that a report was not missed or that the report parameters were not changed. While the value of this object is non-zero, it decrements by one per second until it reaches zero. At the time Waldbusser Standards Track [Page 78] RFC 4502 Remote Network Monitoring MIB May 2006 that this object decrements to zero, the report is made accessible in the alMatrixTopNTable, overwriting any report that may be there. When this object is modified by the management station, any associated entries in the alMatrixTopNTable shall be deleted. (Note that this is a different algorithm than the one used in the hostTopNTable)." DEFVAL { 1800 } ::= { alMatrixTopNControlEntry 4 } alMatrixTopNControlGeneratedReports OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of reports that have been generated by this entry." ::= { alMatrixTopNControlEntry 5 } alMatrixTopNControlDuration OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that this report has collected during the last sampling interval. When the associated alMatrixTopNControlTimeRemaining object is set, this object shall be set by the probe to the same value and shall not be modified until the next time the alMatrixTopNControlTimeRemaining is set. This value shall be zero if no reports have been requested for this alMatrixTopNControlEntry." ::= { alMatrixTopNControlEntry 6 } alMatrixTopNControlRequestedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of matrix entries requested for this report. When this object is created or modified, the probe should set alMatrixTopNControlGrantedSize as closely to this object as possible for the particular probe implementation and available resources." Waldbusser Standards Track [Page 79] RFC 4502 Remote Network Monitoring MIB May 2006 DEFVAL { 150 } ::= { alMatrixTopNControlEntry 7 } alMatrixTopNControlGrantedSize OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of matrix entries in this report. When the associated alMatrixTopNControlRequestedSize object is created or modified, the probe should set this object as closely to the requested value as possible for the particular implementation and available resources. The probe must not lower this value except as a side-effect of a set to the associated alMatrixTopNControlRequestedSize object. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, when the next topN report is generated, matrix entries with the highest value of alMatrixTopNPktRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, when the next topN report is generated, matrix entries with the highest value of alMatrixTopNOctetRate shall be placed in this table in decreasing order of this rate until there is no more room or until there are no more matrix entries. It is an implementation-specific matter how entries with the same value of alMatrixTopNPktRate or alMatrixTopNOctetRate are sorted. It is also an implementation-specific matter as to whether zero-valued entries are available." ::= { alMatrixTopNControlEntry 8 } alMatrixTopNControlStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this topN report was last started. In other words, this is the time that the associated alMatrixTopNControlTimeRemaining object was modified to start the requested report or the time the report was last automatically (re)started. Waldbusser Standards Track [Page 80] RFC 4502 Remote Network Monitoring MIB May 2006 This object may be used by the management station to determine whether a report was missed." ::= { alMatrixTopNControlEntry 9 } alMatrixTopNControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { alMatrixTopNControlEntry 10 } alMatrixTopNControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this alMatrixTopNControlEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the alMatrixTopNTable shall be deleted by the agent." ::= { alMatrixTopNControlEntry 11 } alMatrixTopNTable OBJECT-TYPE SYNTAX SEQUENCE OF AlMatrixTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for those application-layer matrix entries that have counted the highest number of octets or packets." ::= { alMatrix 4 } alMatrixTopNEntry OBJECT-TYPE SYNTAX AlMatrixTopNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the alMatrixTopNTable. The alMatrixTopNControlIndex value in the index identifies the alMatrixTopNControlEntry on whose behalf this entry was created. Waldbusser Standards Track [Page 81] RFC 4502 Remote Network Monitoring MIB May 2006 An example of the indexing of this table is alMatrixTopNPktRate.3.10" INDEX { alMatrixTopNControlIndex, alMatrixTopNIndex } ::= { alMatrixTopNTable 1 } AlMatrixTopNEntry ::= SEQUENCE { alMatrixTopNIndex Integer32, alMatrixTopNProtocolDirLocalIndex Integer32, alMatrixTopNSourceAddress OCTET STRING, alMatrixTopNDestAddress OCTET STRING, alMatrixTopNAppProtocolDirLocalIndex Integer32, alMatrixTopNPktRate Gauge32, alMatrixTopNReversePktRate Gauge32, alMatrixTopNOctetRate Gauge32, alMatrixTopNReverseOctetRate Gauge32 } alMatrixTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the alMatrixTopNTable among those in the same report. This index is between 1 and N, where N is the number of entries in this report. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, increasing values of alMatrixTopNIndex shall be assigned to entries with decreasing values of alMatrixTopNPktRate until index N is assigned or there are no more alMatrixTopNEntries. If the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, increasing values of alMatrixTopNIndex shall be assigned to entries with decreasing values of alMatrixTopNOctetRate until index N is assigned or there are no more alMatrixTopNEntries." ::= { alMatrixTopNEntry 1 } alMatrixTopNProtocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The protocolDirLocalIndex of the network-layer protocol of this entry's network address." Waldbusser Standards Track [Page 82] RFC 4502 Remote Network Monitoring MIB May 2006 ::= { alMatrixTopNEntry 2 } alMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { alMatrixTopNEntry 3 } alMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of IP, this object is encoded as a length octet of 4, followed by the 4 octets of the IP address, in network byte order." ::= { alMatrixTopNEntry 4 } alMatrixTopNAppProtocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the protocol counted by this matrix entry." ::= { alMatrixTopNEntry 5 } alMatrixTopNPktRate OBJECT-TYPE SYNTAX Gauge32 Waldbusser Standards Track [Page 83] RFC 4502 Remote Network Monitoring MIB May 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the alMatrixSDPkts object. If the value of alMatrixTopNControlRateBase is alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, this variable will be used to sort this report." ::= { alMatrixTopNEntry 6 } alMatrixTopNReversePktRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the alMatrixDSPkts object. (Note that the corresponding alMatrixSDPkts object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.) Note that if the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsPkts or alMatrixTopNAllPkts, the sort of topN entries is based entirely on alMatrixTopNPktRate, and not on the value of this object." ::= { alMatrixTopNEntry 7 } alMatrixTopNOctetRate OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the source host to the destination host during this sampling interval, counted using the rules for counting the alMatrixSDOctets object. If the value of alMatrixTopNControlRateBase is alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, this variable will be used to sort this report." ::= { alMatrixTopNEntry 8 } alMatrixTopNReverseOctetRate OBJECT-TYPE Waldbusser Standards Track [Page 84] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets seen of this protocol from the destination host to the source host during this sampling interval, counted using the rules for counting the alMatrixDSOctets object. (Note that the corresponding alMatrixSDOctets object selected is the one whose source address is equal to alMatrixTopNDestAddress and whose destination address is equal to alMatrixTopNSourceAddress.) Note that if the value of alMatrixTopNControlRateBase is equal to alMatrixTopNTerminalsOctets or alMatrixTopNAllOctets, the sort of topN entries is based entirely on alMatrixTopNOctetRate, and not on the value of this object." ::= { alMatrixTopNEntry 9 } -- -- User History Collection Group (usrHistory) -- -- The usrHistory group combines mechanisms seen in the alarm and -- history groups to provide user-specified history collection, -- utilizing two additional control tables and one additional data -- table. This function has traditionally been done by NMS -- applications, via periodic polling. The usrHistory group allows -- this task to be offloaded to an RMON probe. -- -- Data (an ASN.1 INTEGER based object) is collected in the same -- manner as any history data table (e.g., etherHistoryTable) except -- that the user specifies the MIB instances to be collected. Objects -- are collected in bucket-groups, with the intent that all MIB -- instances in the same bucket-group are collected as atomically as -- possible by the RMON probe. -- -- The usrHistoryControlTable is a one-dimensional read-create table. -- Each row configures a collection of user history buckets, much -- the same as a historyControlEntry, except that the creation of a -- row in this table will cause one or more associated instances in -- the usrHistoryObjectTable to be created. The user specifies the -- number of bucket elements (rows in the usrHistoryObjectTable) -- requested, as well as the number of buckets requested. -- -- The usrHistoryObjectTable is a 2-d read-write table. -- Each row configures a single MIB instance to be collected. -- All rows with the same major index constitute a bucket-group. -- -- The usrHistoryTable is a 3-d read-only table containing Waldbusser Standards Track [Page 85] RFC 4502 Remote Network Monitoring MIB May 2006 -- the data of associated usrHistoryControlEntries. Each -- entry represents the value of a single MIB instance -- during a specific sampling interval (or the rate of -- change during the interval). -- -- A sample value is stored in two objects - an absolute value and -- a status object. This allows numbers from -(2G-1) to +4G to be -- stored. The status object also indicates whether a sample is -- valid. This allows data collection to continue if periodic -- retrieval of a particular instance fails for any reason. -- -- Row Creation Order Relationships -- -- The static nature of the usrHistoryObjectTable creates -- some row creation/modification issues. The rows in this -- table need to be set before the associated -- usrHistoryControlEntry can be activated. -- -- Note that the usrHistoryObject entries associated with a -- particular usrHistoryControlEntry are not required to -- be active before the control entry is activated. However, -- the usrHistory data entries associated with an inactive -- usrHistoryObject entry will be inactive (i.e., -- usrHistoryValStatus == valueNotAvailable). -- usrHistoryControlTable OBJECT-TYPE SYNTAX SEQUENCE OF UsrHistoryControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of data-collection configuration entries." ::= { usrHistory 1 } usrHistoryControlEntry OBJECT-TYPE SYNTAX UsrHistoryControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of parameters that set up a group of user-defined MIB objects to be sampled periodically (called a bucket-group). For example, an instance of usrHistoryControlInterval might be named usrHistoryControlInterval.1" INDEX { usrHistoryControlIndex } ::= { usrHistoryControlTable 1 } Waldbusser Standards Track [Page 86] RFC 4502 Remote Network Monitoring MIB May 2006 UsrHistoryControlEntry ::= SEQUENCE { usrHistoryControlIndex Integer32, usrHistoryControlObjects Integer32, usrHistoryControlBucketsRequested Integer32, usrHistoryControlBucketsGranted Integer32, usrHistoryControlInterval Integer32, usrHistoryControlOwner OwnerString, usrHistoryControlStatus RowStatus } usrHistoryControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the usrHistoryControlTable. Each such entry defines a set of samples at a particular interval for a specified set of MIB instances available from the managed system." ::= { usrHistoryControlEntry 1 } usrHistoryControlObjects OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of MIB objects to be collected in the portion of usrHistoryTable associated with this usrHistoryControlEntry. This object may not be modified if the associated instance of usrHistoryControlStatus is equal to active(1)." ::= { usrHistoryControlEntry 2 } usrHistoryControlBucketsRequested OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The requested number of discrete time intervals over which data is to be saved in the part of the usrHistoryTable associated with this usrHistoryControlEntry. When this object is created or modified, the probe should set usrHistoryControlBucketsGranted as closely to this object as possible for the particular probe implementation and available resources." DEFVAL { 50 } Waldbusser Standards Track [Page 87] RFC 4502 Remote Network Monitoring MIB May 2006 ::= { usrHistoryControlEntry 3 } usrHistoryControlBucketsGranted OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of discrete sampling intervals over which data shall be saved in the part of the usrHistoryTable associated with this usrHistoryControlEntry. When the associated usrHistoryControlBucketsRequested object is created or modified, the probe should set this object as closely to the requested value as possible for the particular probe implementation and available resources. The probe must not lower this value except as a result of a modification to the associated usrHistoryControlBucketsRequested object. The associated usrHistoryControlBucketsRequested object should be set before or at the same time as this object to allow the probe to accurately estimate the resources required for this usrHistoryControlEntry. There will be times when the actual number of buckets associated with this entry is less than the value of this object. In this case, at the end of each sampling interval, a new bucket will be added to the usrHistoryTable. When the number of buckets reaches the value of this object and a new bucket is to be added to the usrHistoryTable, the oldest bucket associated with this usrHistoryControlEntry shall be deleted by the agent so that the new bucket can be added. When the value of this object changes to a value less than the current value, entries are deleted from the usrHistoryTable associated with this usrHistoryControlEntry. Enough of the oldest of these entries shall be deleted by the agent so that their number remains less than or equal to the new value of this object. When the value of this object changes to a value greater than the current value, the number of associated usrHistory entries may be allowed to grow." ::= { usrHistoryControlEntry 4 } Waldbusser Standards Track [Page 88] RFC 4502 Remote Network Monitoring MIB May 2006 usrHistoryControlInterval OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The interval in seconds over which the data is sampled for each bucket in the part of the usrHistory table associated with this usrHistoryControlEntry. Because the counters in a bucket may overflow at their maximum value with no indication, a prudent manager will take into account the possibility of overflow in any of the associated counters. It is important to consider the minimum time in which any counter could overflow on a particular media type and to set the usrHistoryControlInterval object to a value less than this interval. This object may not be modified if the associated usrHistoryControlStatus object is equal to active(1)." DEFVAL { 1800 } ::= { usrHistoryControlEntry 5 } usrHistoryControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { usrHistoryControlEntry 6 } usrHistoryControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this variable history control entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the usrHistoryTable shall be deleted." ::= { usrHistoryControlEntry 7 } -- Object table usrHistoryObjectTable OBJECT-TYPE Waldbusser Standards Track [Page 89] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX SEQUENCE OF UsrHistoryObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of data-collection configuration entries." ::= { usrHistory 2 } usrHistoryObjectEntry OBJECT-TYPE SYNTAX UsrHistoryObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of MIB instances to be sampled periodically. Entries in this table are created when an associated usrHistoryControlObjects object is created. The usrHistoryControlIndex value in the index is that of the associated usrHistoryControlEntry. For example, an instance of usrHistoryObjectVariable might be usrHistoryObjectVariable.1.3" INDEX { usrHistoryControlIndex, usrHistoryObjectIndex } ::= { usrHistoryObjectTable 1 } UsrHistoryObjectEntry ::= SEQUENCE { usrHistoryObjectIndex Integer32, usrHistoryObjectVariable OBJECT IDENTIFIER, usrHistoryObjectSampleType INTEGER } usrHistoryObjectIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index used to uniquely identify an entry in the usrHistoryObject table. Each such entry defines a MIB instance to be collected periodically." ::= { usrHistoryObjectEntry 1 } usrHistoryObjectVariable OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the particular variable to be Waldbusser Standards Track [Page 90] RFC 4502 Remote Network Monitoring MIB May 2006 sampled. Only variables that resolve to an ASN.1 primitive type of Integer32 (Integer32, Counter, Gauge, or TimeTicks) may be sampled. Because SNMP access control is articulated entirely in terms of the contents of MIB views, no access control mechanism exists that can restrict the value of this object to identify only those objects that exist in a particular MIB view. Because there is thus no acceptable means of restricting the read access that could be obtained through the user history mechanism, the probe must only grant write access to this object in those views that have read access to all objects on the probe. See USM [RFC3414] and VACM [RFC3415] for more information. During a set operation, if the supplied variable name is not available in the selected MIB view, a badValue error must be returned. This object may not be modified if the associated usrHistoryControlStatus object is equal to active(1)." ::= { usrHistoryObjectEntry 2 } usrHistoryObjectSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable for storage in the usrHistoryTable. If the value of this object is absoluteValue(1), the value of the selected variable will be copied directly into the history bucket. If the value of this object is deltaValue(2), the value of the selected variable at the last sample will be subtracted from the current value, and the difference will be stored in the history bucket. If the associated usrHistoryObjectVariable instance could not be obtained at the previous sample interval, then a delta sample is not possible, and the value of the associated usrHistoryValStatus object for this interval will be valueNotAvailable(1). Waldbusser Standards Track [Page 91] RFC 4502 Remote Network Monitoring MIB May 2006 This object may not be modified if the associated usrHistoryControlStatus object is equal to active(1)." ::= { usrHistoryObjectEntry 3 } -- data table usrHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF UsrHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of user-defined history entries." ::= { usrHistory 3 } usrHistoryEntry OBJECT-TYPE SYNTAX UsrHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A historical sample of user-defined variables. This sample is associated with the usrHistoryControlEntry that set up the parameters for a regular collection of these samples. The usrHistoryControlIndex value in the index identifies the usrHistoryControlEntry on whose behalf this entry was created. The usrHistoryObjectIndex value in the index identifies the usrHistoryObjectEntry on whose behalf this entry was created. For example, an instance of usrHistoryAbsValue, which represents the 14th sample of a variable collected as specified by usrHistoryControlEntry.1 and usrHistoryObjectEntry.1.5, would be named usrHistoryAbsValue.1.14.5" INDEX { usrHistoryControlIndex, usrHistorySampleIndex, usrHistoryObjectIndex } ::= { usrHistoryTable 1 } UsrHistoryEntry ::= SEQUENCE { usrHistorySampleIndex Integer32, usrHistoryIntervalStart TimeStamp, usrHistoryIntervalEnd TimeStamp, usrHistoryAbsValue Gauge32, usrHistoryValStatus INTEGER } usrHistorySampleIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current Waldbusser Standards Track [Page 92] RFC 4502 Remote Network Monitoring MIB May 2006 DESCRIPTION "An index that uniquely identifies the particular sample this entry represents among all samples associated with the same usrHistoryControlEntry. This index starts at 1 and increases by one as each new sample is taken." ::= { usrHistoryEntry 1 } usrHistoryIntervalStart OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the start of the interval over which this sample was measured. If the probe keeps track of the time of day, it should start the first sample of the history at a time such that when the next hour of the day begins, a sample is started at that instant. Note that following this rule may require that the probe delay collecting the first sample of the history, as each sample must be of the same interval. Also note that the sample that is currently being collected is not accessible in this table until the end of its interval." ::= { usrHistoryEntry 2 } usrHistoryIntervalEnd OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the end of the interval over which this sample was measured." ::= { usrHistoryEntry 3 } usrHistoryAbsValue OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The absolute value (i.e., unsigned value) of the user-specified statistic during the last sampling period. The value during the current sampling period is not made available until the period is completed. To obtain the true value for this sampling interval, the associated instance of usrHistoryValStatus must be checked, and usrHistoryAbsValue adjusted as necessary. Waldbusser Standards Track [Page 93] RFC 4502 Remote Network Monitoring MIB May 2006 If the MIB instance could not be accessed during the sampling interval, then this object will have a value of zero, and the associated instance of usrHistoryValStatus will be set to 'valueNotAvailable(1)'. The access control check prescribed in the definition of usrHistoryObjectVariable SHOULD be checked for each sampling interval. If this check determines that access should not be allowed, then this object will have a value of zero, and the associated instance of usrHistoryValStatus will be set to 'valueNotAvailable(1)'." ::= { usrHistoryEntry 4 } usrHistoryValStatus OBJECT-TYPE SYNTAX INTEGER { valueNotAvailable(1), valuePositive(2), valueNegative(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the validity and sign of the data in the associated instance of usrHistoryAbsValue. If the MIB instance could not be accessed during the sampling interval, then 'valueNotAvailable(1)' will be returned. If the sample is valid and the actual value of the sample is greater than or equal to zero, then 'valuePositive(2)' is returned. If the sample is valid and the actual value of the sample is less than zero, 'valueNegative(3)' will be returned. The associated instance of usrHistoryAbsValue should be multiplied by -1 to obtain the true sample value." ::= { usrHistoryEntry 5 } -- The Probe Configuration Group -- -- This group controls the configuration of various operating -- parameters of the probe. ControlString ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to communicate with a modem or a Waldbusser Standards Track [Page 94] RFC 4502 Remote Network Monitoring MIB May 2006 serial data switch. A ControlString contains embedded commands to control how the device will interact with the remote device through the serial interface. Commands are represented as two-character sequences beginning with the '^' character. The following commands are recognized by the device (note that command characters are case sensitive): ^s Send string that follows, which is terminated by the next command or the end of string. ^c Delay for the number of seconds that follows. Toss out any data received rather than store it in a buffer for parsing. ^t Set timeout to the value represented by the decimal digits that follow. The default timeout is 20 seconds. Note that this timeout may be overridden by a smaller serialTimeout configured for the associated serial interface (see serialConfigTable). ^w Wait for the reply string that follows, which is terminated by the next command or the end of string. Partial and case-insensitive matching is applied, i.e., if the reply string (any case combination) is found anywhere in the received string, then the a match is found. If the current timeout elapses without a match, then the remaining control string is ignored. ^! The ^ character. ^d Delay the number of seconds specified by the decimal digits that follow. ^b Send break for the number of milliseconds specified by the decimal digits that follow. If no digits follow, break will be enforced for 250 milliseconds by default. The following ASCII control characters may be inserted into the '^s' send string or the '^w' reply string: ^@ 0x00 ^A 0x01 .. ^M 0x0D .. ^Z 0x1A ^[ 0x1B ^ 0x1C ^] 0x1D ^^ 0x1E ^_ 0x1F Waldbusser Standards Track [Page 95] RFC 4502 Remote Network Monitoring MIB May 2006 Binary data may also be inserted into the data stream. The control sequence for each byte of binary data is ^0x##, where ## is the hexadecimal representation of the data byte. Two ASCII characters (0-9, a-f, A-F) must follow the '^0x' control prefix. For example, '^0x0D^0x0A' is interpreted as a carriage return followed by a line feed." SYNTAX OCTET STRING (SIZE (0..255)) probeCapabilities OBJECT-TYPE SYNTAX BITS { etherStats(0), historyControl(1), etherHistory(2), alarm(3), hosts(4), hostTopN(5), matrix(6), filter(7), capture(8), event(9), tokenRingMLStats(10), tokenRingPStats(11), tokenRingMLHistory(12), tokenRingPHistory(13), ringStation(14), ringStationOrder(15), ringStationConfig(16), sourceRouting(17), protocolDirectory(18), protocolDistribution(19), addressMapping(20), nlHost(21), nlMatrix(22), alHost(23), alMatrix(24), usrHistory(25), probeConfig(26) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the RMON MIB groups supported on at least one interface by this probe." ::= { probeConfig 1 } probeSoftwareRev OBJECT-TYPE SYNTAX DisplayString (SIZE(0..15)) MAX-ACCESS read-only Waldbusser Standards Track [Page 96] RFC 4502 Remote Network Monitoring MIB May 2006 STATUS current DESCRIPTION "The software revision of this device. This string will have a zero length if the revision is unknown." ::= { probeConfig 2 } probeHardwareRev OBJECT-TYPE SYNTAX DisplayString (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The hardware revision of this device. This string will have a zero length if the revision is unknown." ::= { probeConfig 3 } probeDateTime OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 8 | 11)) MAX-ACCESS read-write STATUS current DESCRIPTION "Probe's current date and time. field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC 0..11 10 11 minutes from UTC 0..59 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then time zone information (fields 8-10) is not present, and that if no time information is known, the null string is returned." ::= { probeConfig 4 } probeResetControl OBJECT-TYPE Waldbusser Standards Track [Page 97] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX INTEGER { running(1), warmBoot(2), coldBoot(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to warmBoot(2) causes the device to restart the application software with current configuration parameters saved in non-volatile memory. Setting this object to coldBoot(3) causes the device to reinitialize configuration parameters in non-volatile memory to default values and to restart the application software. When the device is running normally, this variable has a value of running(1)." ::= { probeConfig 5 } -- The following download objects do not restrict an implementation -- from implementing additional download mechanisms (controlled in an -- implementation-specific manner). Further, in the case where the RMON -- agent shares a processor with other types of systems, the -- implementation is not required to download those non-RMON functions -- with this mechanism. probeDownloadFile OBJECT-TYPE SYNTAX DisplayString (SIZE(0..127)) MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The file name to be downloaded from the TFTP server when a download is next requested via this MIB. This value is set to the zero-length string when no file name has been specified. This object has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { probeConfig 6 } probeDownloadTFTPServer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The IP address of the TFTP server that contains the boot image to load when a download is next requested via this MIB. This value is set to '0.0.0.0' when no IP address has been Waldbusser Standards Track [Page 98] RFC 4502 Remote Network Monitoring MIB May 2006 specified. This object has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { probeConfig 7 } probeDownloadAction OBJECT-TYPE SYNTAX INTEGER { notDownloading(1), downloadToPROM(2), downloadToRAM(3) } MAX-ACCESS read-write STATUS deprecated DESCRIPTION "When this object is set to downloadToRAM(3) or downloadToPROM(2), the device will discontinue its normal operation and begin download of the image specified by probeDownloadFile from the server specified by probeDownloadTFTPServer using the TFTP protocol. If downloadToRAM(3) is specified, the new image is copied to RAM only (the old image remains unaltered in the flash EPROM). If downloadToPROM(2) is specified, the new image is written to the flash EPROM memory after its checksum has been verified to be correct. When the download process is completed, the device will warm boot to restart the newly loaded application. When the device is not downloading, this object will have a value of notDownloading(1). This object has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { probeConfig 8 } probeDownloadStatus OBJECT-TYPE SYNTAX INTEGER { downloadSuccess(1), downloadStatusUnknown(2), downloadGeneralError(3), downloadNoResponseFromServer(4), downloadChecksumError(5), downloadIncompatibleImage(6), downloadTftpFileNotFound(7), downloadTftpAccessViolation(8) } MAX-ACCESS read-only Waldbusser Standards Track [Page 99] RFC 4502 Remote Network Monitoring MIB May 2006 STATUS deprecated DESCRIPTION "The status of the last download procedure, if any. This object will have a value of downloadStatusUnknown(2) if no download process has been performed. This object has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { probeConfig 9 } serialConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF SerialConfigEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A table of serial interface configuration entries. This data will be stored in non-volatile memory and preserved across probe resets or power loss. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { probeConfig 10 } serialConfigEntry OBJECT-TYPE SYNTAX SerialConfigEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A set of configuration parameters for a particular serial interface on this device. If the device has no serial interfaces, this table is empty. The index is composed of the ifIndex assigned to this serial line interface." INDEX { ifIndex } ::= { serialConfigTable 1 } SerialConfigEntry ::= SEQUENCE { serialMode INTEGER, serialProtocol INTEGER, serialTimeout Integer32, serialModemInitString ControlString, serialModemHangUpString ControlString, serialModemConnectResp DisplayString, serialModemNoConnectResp DisplayString, serialDialoutTimeout Integer32, Waldbusser Standards Track [Page 100] RFC 4502 Remote Network Monitoring MIB May 2006 serialStatus RowStatus } serialMode OBJECT-TYPE SYNTAX INTEGER { direct(1), modem(2) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The type of incoming connection to be expected on this serial interface." DEFVAL { direct } ::= { serialConfigEntry 1 } serialProtocol OBJECT-TYPE SYNTAX INTEGER { other(1), slip(2), ppp(3) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The type of data link encapsulation to be used on this serial interface." DEFVAL { slip } ::= { serialConfigEntry 2 } serialTimeout OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This timeout value is used when the Management Station has initiated the conversation over the serial link. This variable represents the number of seconds of inactivity allowed before terminating the connection on this serial interface. Use the serialDialoutTimeout in the case where the probe has initiated the connection for the purpose of sending a trap." DEFVAL { 300 } ::= { serialConfigEntry 3 } serialModemInitString OBJECT-TYPE SYNTAX ControlString (SIZE (0..255)) MAX-ACCESS read-create STATUS deprecated Waldbusser Standards Track [Page 101] RFC 4502 Remote Network Monitoring MIB May 2006 DESCRIPTION "A control string that controls how a modem attached to this serial interface should be initialized. The initialization is performed once during startup and again after each connection is terminated if the associated serialMode has the value of modem(2). A control string that is appropriate for a wide variety of modems is: '^s^MATE0Q0V1X4 S0=1 S2=43^M'." ::= { serialConfigEntry 4 } serialModemHangUpString OBJECT-TYPE SYNTAX ControlString (SIZE (0..255)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A control string that specifies how to disconnect a modem connection on this serial interface. This object is only meaningful if the associated serialMode has the value of modem(2). A control string that is appropriate for a wide variety of modems is: '^d2^s+++^d2^sATH0^M^d2'." ::= { serialConfigEntry 5 } serialModemConnectResp OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "An ASCII string containing substrings that describe the expected modem connection response code and associated bps rate. The substrings are delimited by the first character in the string, for example: /CONNECT/300/CONNECT 1200/1200/CONNECT 2400/2400/ CONNECT 4800/4800/CONNECT 9600/9600 will be interpreted as: response code bps rate CONNECT 300 CONNECT 1200 1200 CONNECT 2400 2400 CONNECT 4800 4800 CONNECT 9600 9600 The agent will use the information in this string to adjust the bps rate of this serial interface once a modem connection is established. A value that is appropriate for a wide variety of modems is: Waldbusser Standards Track [Page 102] RFC 4502 Remote Network Monitoring MIB May 2006 '/CONNECT/300/CONNECT 1200/1200/CONNECT 2400/2400/ CONNECT 4800/4800/CONNECT 9600/9600/CONNECT 14400/14400/ CONNECT 19200/19200/CONNECT 38400/38400/'." ::= { serialConfigEntry 6 } serialModemNoConnectResp OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "An ASCII string containing response codes that may be generated by a modem to report the reason why a connection attempt has failed. The response codes are delimited by the first character in the string, for example: /NO CARRIER/BUSY/NO DIALTONE/NO ANSWER/ERROR/ If one of these response codes is received via this serial interface while attempting to make a modem connection, the agent will issue the hang up command as specified by serialModemHangUpString. A value that is appropriate for a wide variety of modems is: '/NO CARRIER/BUSY/NO DIALTONE/NO ANSWER/ERROR/'." ::= { serialConfigEntry 7 } serialDialoutTimeout OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This timeout value is used when the probe initiates the serial connection with the intention of contacting a management station. This variable represents the number of seconds of inactivity allowed before terminating the connection on this serial interface." DEFVAL { 20 } ::= { serialConfigEntry 8 } serialStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this serialConfigEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value." ::= { serialConfigEntry 9 } Waldbusser Standards Track [Page 103] RFC 4502 Remote Network Monitoring MIB May 2006 netConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF NetConfigEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A table of netConfigEntries. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { probeConfig 11 } netConfigEntry OBJECT-TYPE SYNTAX NetConfigEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A set of configuration parameters for a particular network interface on this device. If the device has no network interface, this table is empty. The index is composed of the ifIndex assigned to the corresponding interface." INDEX { ifIndex } ::= { netConfigTable 1 } NetConfigEntry ::= SEQUENCE { netConfigIPAddress IpAddress, netConfigSubnetMask IpAddress, netConfigStatus RowStatus } netConfigIPAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The IP address of this Net interface. The default value for this object is 0.0.0.0. If either the netConfigIPAddress or netConfigSubnetMask is 0.0.0.0, then when the device boots, it may use BOOTP to try to figure out what these values should be. If BOOTP fails before the device can talk on the network, this value must be configured (e.g., through a terminal attached to the device). If BOOTP is used, care should be taken to not send BOOTP broadcasts too frequently and to eventually send them very infrequently if no replies are received." ::= { netConfigEntry 1 } Waldbusser Standards Track [Page 104] RFC 4502 Remote Network Monitoring MIB May 2006 netConfigSubnetMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The subnet mask of this Net interface. The default value for this object is 0.0.0.0. If either the netConfigIPAddress or netConfigSubnetMask is 0.0.0.0, then when the device boots, it may use BOOTP to try to figure out what these values should be. If BOOTP fails before the device can talk on the network, this value must be configured (e.g., through a terminal attached to the device). If BOOTP is used, care should be taken to not send BOOTP broadcasts too frequently and to eventually send them very infrequently if no replies are received." ::= { netConfigEntry 2 } netConfigStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this netConfigEntry. An entry may not exist in the active state unless all objects in the entry have an appropriate value." ::= { netConfigEntry 3 } netDefaultGateway OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The IP Address of the default gateway. If this value is undefined or unknown, it shall have the value 0.0.0.0." ::= { probeConfig 12 } -- Trap Destination Table -- -- This table defines the destination addresses for traps generated -- from the device. This table maps a community to one or more trap -- destination entries. -- -- The same trap will be sent to all destinations specified in the -- entries that have the same trapDestCommunity as the eventCommunity -- (as defined by RMON MIB), as long as no access control mechanism -- (e.g., VACM) prohibits sending to one or more of the destinations. -- Information in this table will be stored in non-volatile memory. Waldbusser Standards Track [Page 105] RFC 4502 Remote Network Monitoring MIB May 2006 -- If the device has gone through a hard restart, this information -- will be reset to its default state. trapDestTable OBJECT-TYPE SYNTAX SEQUENCE OF TrapDestEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A list of trap destination entries." ::= { probeConfig 13 } trapDestEntry OBJECT-TYPE SYNTAX TrapDestEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This entry includes a destination IP address to which traps are sent for this community." INDEX { trapDestIndex } ::= { trapDestTable 1 } TrapDestEntry ::= SEQUENCE { trapDestIndex Integer32, trapDestCommunity OCTET STRING, trapDestProtocol INTEGER, trapDestAddress OCTET STRING, trapDestOwner OwnerString, trapDestStatus RowStatus } trapDestIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A value that uniquely identifies this trapDestEntry." ::= { trapDestEntry 1 } trapDestCommunity OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..127)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A community to which this destination address belongs. This entry is associated with any eventEntries in the RMON MIB whose value of eventCommunity is equal to the value of this object. Every time an associated event entry sends a trap due to an event, that trap will be sent to each Waldbusser Standards Track [Page 106] RFC 4502 Remote Network Monitoring MIB May 2006 address in the trapDestTable with a trapDestCommunity equal to eventCommunity, as long as no access control mechanism precludes it (e.g., VACM). This object may not be modified if the associated trapDestStatus object is equal to active(1)." ::= { trapDestEntry 2 } trapDestProtocol OBJECT-TYPE SYNTAX INTEGER { ip(1), ipx(2) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The protocol with which this trap is to be sent." ::= { trapDestEntry 3 } trapDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The destination address for traps on behalf of this entry. If the associated trapDestProtocol object is equal to ip(1), the encoding of this object is the same as the snmpUDPAddress textual convention in RFC 3417, 'Transport Mappings for the Simple Network Management Protocol (SNMP)' [RFC3417]: -- for a SnmpUDPAddress of length 6: -- -- octets contents encoding -- 1-4 IP-address network-byte order -- 5-6 UDP-port network-byte order If the associated trapDestProtocol object is equal to ipx(2), the encoding of this object is the same as the snmpIPXAddress textual convention in RFC 3417, 'Transport Mappings for the Simple Network Management Protocol (SNMP)' [RFC3417]: -- for a SnmpIPXAddress of length 12: -- -- octets contents encoding -- 1-4 network-number network-byte order -- 5-10 physical-address network-byte order -- 11-12 socket-number network-byte order This object may not be modified if the associated Waldbusser Standards Track [Page 107] RFC 4502 Remote Network Monitoring MIB May 2006 trapDestStatus object is equal to active(1)." ::= { trapDestEntry 4 } trapDestOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { trapDestEntry 5 } trapDestStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this trap destination entry. An entry may not exist in the active state unless all objects in the entry have an appropriate value." ::= { trapDestEntry 6 } -- Serial Connection Table -- -- The device may communicate with a management station using -- SLIP. In order for the device to send traps via SLIP, it must -- be able to initiate a connection over the serial interface. The -- serialConnectionTable stores the parameters for such connection -- initiation. serialConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF SerialConnectionEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A list of serialConnectionEntries. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { probeConfig 14 } serialConnectionEntry OBJECT-TYPE SYNTAX SerialConnectionEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION Waldbusser Standards Track [Page 108] RFC 4502 Remote Network Monitoring MIB May 2006 "Configuration for a SLIP link over a serial line." INDEX { serialConnectIndex } ::= { serialConnectionTable 1 } SerialConnectionEntry ::= SEQUENCE { serialConnectIndex Integer32, serialConnectDestIpAddress IpAddress, serialConnectType INTEGER, serialConnectDialString ControlString, serialConnectSwitchConnectSeq ControlString, serialConnectSwitchDisconnectSeq ControlString, serialConnectSwitchResetSeq ControlString, serialConnectOwner OwnerString, serialConnectStatus RowStatus } serialConnectIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A value that uniquely identifies this serialConnection entry." ::= { serialConnectionEntry 1 } serialConnectDestIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The IP Address that can be reached at the other end of this serial connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1)." ::= { serialConnectionEntry 2 } serialConnectType OBJECT-TYPE SYNTAX INTEGER { direct(1), modem(2), switch(3), modemSwitch(4) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION Waldbusser Standards Track [Page 109] RFC 4502 Remote Network Monitoring MIB May 2006 "The type of outgoing connection to be made. If this object has the value direct(1), then a direct serial connection is assumed. If this object has the value modem(2), then serialConnectDialString will be used to make a modem connection. If this object has the value switch(3), then serialConnectSwitchConnectSeq will be used to establish the connection over a serial data switch, and serialConnectSwitchDisconnectSeq will be used to terminate the connection. If this object has the value modem-switch(4), then a modem connection will be made first, followed by the switch connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1)." DEFVAL { direct } ::= { serialConnectionEntry 3 } serialConnectDialString OBJECT-TYPE SYNTAX ControlString (SIZE(0..255)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A control string that specifies how to dial the phone number in order to establish a modem connection. The string should include the dialing prefix and suffix. For example: '^s^MATD9,888-1234^M' will instruct the Probe to send a carriage return, followed by the dialing prefix 'ATD', the phone number '9,888-1234', and a carriage return as the dialing suffix. This object may not be modified if the associated serialConnectStatus object is equal to active(1)." ::= { serialConnectionEntry 4 } serialConnectSwitchConnectSeq OBJECT-TYPE SYNTAX ControlString (SIZE(0..255)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A control string that specifies how to establish a data switch connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1)." ::= { serialConnectionEntry 5 } serialConnectSwitchDisconnectSeq OBJECT-TYPE SYNTAX ControlString (SIZE(0..255)) Waldbusser Standards Track [Page 110] RFC 4502 Remote Network Monitoring MIB May 2006 MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A control string that specifies how to terminate a data switch connection. This object may not be modified if the associated serialConnectStatus object is equal to active(1)." ::= { serialConnectionEntry 6 } serialConnectSwitchResetSeq OBJECT-TYPE SYNTAX ControlString (SIZE(0..255)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A control string that specifies how to reset a data switch in the event of a timeout. This object may not be modified if the associated serialConnectStatus object is equal to active(1)." ::= { serialConnectionEntry 7 } serialConnectOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { serialConnectionEntry 8 } serialConnectStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this serialConnectionEntry. If the manager attempts to set this object to active(1) when the serialConnectType is set to modem(2) or modem-switch(4) and the serialConnectDialString is a zero-length string or cannot be correctly parsed as a ConnectString, the set request will be rejected with badValue(3). If the manager attempts to set this object to active(1) when the serialConnectType is set to switch(3) or modem-switch(4) and the serialConnectSwitchConnectSeq, the serialConnectSwitchDisconnectSeq, or Waldbusser Standards Track [Page 111] RFC 4502 Remote Network Monitoring MIB May 2006 the serialConnectSwitchResetSeq is a zero-length string or cannot be correctly parsed as a ConnectString, the set request will be rejected with badValue(3). An entry may not exist in the active state unless all objects in the entry have an appropriate value." ::= { serialConnectionEntry 9 } -- -- Extensions to the RMON 1 MIB for RMON 2 devices -- -- These extensions include the standard LastCreateTime Textual -- Convention for all control tables, as well as an augmentation of -- the filter entry that provides variable-length offsets into -- packets. -- Each of the following, except for filterDroppedFrames, is a -- read-only object which, if implemented, automatically appears when -- the RMON1 row it is associated with is created. etherStats2Table OBJECT-TYPE SYNTAX SEQUENCE OF EtherStats2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." ::= { statistics 4 } etherStats2Entry OBJECT-TYPE SYNTAX EtherStats2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { etherStatsEntry } ::= { etherStats2Table 1 } EtherStats2Entry ::= SEQUENCE { etherStatsDroppedFrames Counter32, etherStatsCreateTime LastCreateTime } etherStatsDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 112] RFC 4502 Remote Network Monitoring MIB May 2006 "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { etherStats2Entry 1 } etherStatsCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { etherStats2Entry 2 } historyControl2Table OBJECT-TYPE SYNTAX SEQUENCE OF HistoryControl2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." ::= { history 5 } historyControl2Entry OBJECT-TYPE SYNTAX HistoryControl2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { historyControlEntry } ::= { historyControl2Table 1 } HistoryControl2Entry ::= SEQUENCE { historyControlDroppedFrames Counter32 } historyControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 Waldbusser Standards Track [Page 113] RFC 4502 Remote Network Monitoring MIB May 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { historyControl2Entry 1 } hostControl2Table OBJECT-TYPE SYNTAX SEQUENCE OF HostControl2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." ::= { hosts 4 } hostControl2Entry OBJECT-TYPE SYNTAX HostControl2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { hostControlEntry } ::= { hostControl2Table 1 } HostControl2Entry ::= SEQUENCE { hostControlDroppedFrames Counter32, hostControlCreateTime LastCreateTime } hostControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the Waldbusser Standards Track [Page 114] RFC 4502 Remote Network Monitoring MIB May 2006 probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { hostControl2Entry 1 } hostControlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { hostControl2Entry 2 } matrixControl2Table OBJECT-TYPE SYNTAX SEQUENCE OF MatrixControl2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." ::= { matrix 4 } matrixControl2Entry OBJECT-TYPE SYNTAX MatrixControl2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { matrixControlEntry } ::= { matrixControl2Table 1 } MatrixControl2Entry ::= SEQUENCE { matrixControlDroppedFrames Counter32, matrixControlCreateTime LastCreateTime } matrixControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Waldbusser Standards Track [Page 115] RFC 4502 Remote Network Monitoring MIB May 2006 "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { matrixControl2Entry 1 } matrixControlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { matrixControl2Entry 2 } channel2Table OBJECT-TYPE SYNTAX SEQUENCE OF Channel2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." ::= { filter 3 } channel2Entry OBJECT-TYPE SYNTAX Channel2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { channelEntry } ::= { channel2Table 1 } Channel2Entry ::= SEQUENCE { channelDroppedFrames Counter32, channelCreateTime LastCreateTime } channelDroppedFrames OBJECT-TYPE Waldbusser Standards Track [Page 116] RFC 4502 Remote Network Monitoring MIB May 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { channel2Entry 1 } channelCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { channel2Entry 2 } tokenRingMLStats2Table OBJECT-TYPE SYNTAX SEQUENCE OF TokenRingMLStats2Entry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Contains the RMON-2 augmentations to RMON-1. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { statistics 5 } tokenRingMLStats2Entry OBJECT-TYPE SYNTAX TokenRingMLStats2Entry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { tokenRingMLStatsEntry } Waldbusser Standards Track [Page 117] RFC 4502 Remote Network Monitoring MIB May 2006 ::= { tokenRingMLStats2Table 1 } TokenRingMLStats2Entry ::= SEQUENCE { tokenRingMLStatsDroppedFrames Counter32, tokenRingMLStatsCreateTime LastCreateTime } tokenRingMLStatsDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { tokenRingMLStats2Entry 1 } tokenRingMLStatsCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { tokenRingMLStats2Entry 2 } tokenRingPStats2Table OBJECT-TYPE SYNTAX SEQUENCE OF TokenRingPStats2Entry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Contains the RMON-2 augmentations to RMON-1. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { statistics 6 } Waldbusser Standards Track [Page 118] RFC 4502 Remote Network Monitoring MIB May 2006 tokenRingPStats2Entry OBJECT-TYPE SYNTAX TokenRingPStats2Entry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { tokenRingPStatsEntry } ::= { tokenRingPStats2Table 1 } TokenRingPStats2Entry ::= SEQUENCE { tokenRingPStatsDroppedFrames Counter32, tokenRingPStatsCreateTime LastCreateTime } tokenRingPStatsDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { tokenRingPStats2Entry 1 } tokenRingPStatsCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { tokenRingPStats2Entry 2 } ringStationControl2Table OBJECT-TYPE SYNTAX SEQUENCE OF RingStationControl2Entry MAX-ACCESS not-accessible STATUS deprecated Waldbusser Standards Track [Page 119] RFC 4502 Remote Network Monitoring MIB May 2006 DESCRIPTION "Contains the RMON-2 augmentations to RMON-1. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { tokenRing 7 } ringStationControl2Entry OBJECT-TYPE SYNTAX RingStationControl2Entry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { ringStationControlEntry } ::= { ringStationControl2Table 1 } RingStationControl2Entry ::= SEQUENCE { ringStationControlDroppedFrames Counter32, ringStationControlCreateTime LastCreateTime } ringStationControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { ringStationControl2Entry 1 } ringStationControlCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to Waldbusser Standards Track [Page 120] RFC 4502 Remote Network Monitoring MIB May 2006 ensure that the table has not been deleted and recreated between polls." ::= { ringStationControl2Entry 2 } sourceRoutingStats2Table OBJECT-TYPE SYNTAX SEQUENCE OF SourceRoutingStats2Entry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Contains the RMON-2 augmentations to RMON-1. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard." ::= { tokenRing 8 } sourceRoutingStats2Entry OBJECT-TYPE SYNTAX SourceRoutingStats2Entry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { sourceRoutingStatsEntry } ::= { sourceRoutingStats2Table 1 } SourceRoutingStats2Entry ::= SEQUENCE { sourceRoutingStatsDroppedFrames Counter32, sourceRoutingStatsCreateTime LastCreateTime } sourceRoutingStatsDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of frames that were received by the probe and therefore not accounted for in the *StatsDropEvents, but that the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. This count does not include packets that were not counted because they had MAC-layer errors. Note that, unlike the dropEvents counter, this number is the exact number of frames dropped." ::= { sourceRoutingStats2Entry 1 } Waldbusser Standards Track [Page 121] RFC 4502 Remote Network Monitoring MIB May 2006 sourceRoutingStatsCreateTime OBJECT-TYPE SYNTAX LastCreateTime MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The value of sysUpTime when this control entry was last activated. This can be used by the management station to ensure that the table has not been deleted and recreated between polls." ::= { sourceRoutingStats2Entry 2 } filter2Table OBJECT-TYPE SYNTAX SEQUENCE OF Filter2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides a variable-length packet filter feature to the RMON-1 filter table." ::= { filter 4 } filter2Entry OBJECT-TYPE SYNTAX Filter2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides a variable-length packet filter feature to the RMON-1 filter table." AUGMENTS { filterEntry } ::= { filter2Table 1 } Filter2Entry ::= SEQUENCE { filterProtocolDirDataLocalIndex Integer32, filterProtocolDirLocalIndex Integer32 } filterProtocolDirDataLocalIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "When this object is set to a non-zero value, the filter that it is associated with performs the following operations on every packet: 1) If the packet doesn't match the protocol directory entry identified by this object, discard the packet and exit (i.e., discard the packet if it is not of the identified protocol). Waldbusser Standards Track [Page 122] RFC 4502 Remote Network Monitoring MIB May 2006 2) If the associated filterProtocolDirLocalIndex is non-zero and the packet doesn't match the protocol directory entry identified by that object, discard the packet and exit. 3) If the packet matches, perform the regular filter algorithm as if the beginning of this named protocol is the beginning of the packet, potentially applying the filterOffset value to move further into the packet." DEFVAL { 0 } ::= { filter2Entry 1 } filterProtocolDirLocalIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "When this object is set to a non-zero value, the filter that it is associated with will discard the packet if the packet doesn't match this protocol directory entry." DEFVAL { 0 } ::= { filter2Entry 2 } -- Conformance Macros rmon2MIBCompliances OBJECT IDENTIFIER ::= { rmonConformance 1 } rmon2MIBGroups OBJECT IDENTIFIER ::= { rmonConformance 2 } rmon2MIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the RMON2 MIB" MODULE -- this module MANDATORY-GROUPS { protocolDirectoryGroup, protocolDistributionGroup, addressMapGroup, nlHostGroup, nlMatrixGroup, usrHistoryGroup, probeInformationGroup } OBJECT nlMatrixTopNControlRateBase SYNTAX INTEGER { nlMatrixTopNPkts(1), nlMatrixTopNOctets(2) } DESCRIPTION Waldbusser Standards Track [Page 123] RFC 4502 Remote Network Monitoring MIB May 2006 "Conformance to RMON2 requires only support for these values of nlMatrixTopNControlRateBase." GROUP rmon1EnhancementGroup DESCRIPTION "The rmon1EnhancementGroup is mandatory for systems that implement RMON [RFC2819]." GROUP rmon1EthernetEnhancementGroup DESCRIPTION "The rmon1EthernetEnhancementGroup is optional and is appropriate for systems that implement the Ethernet group of RMON [RFC2819]." ::= { rmon2MIBCompliances 1 } rmon2MIBApplicationLayerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the RMON2 MIB with Application-Layer Enhancements." MODULE -- this module MANDATORY-GROUPS { protocolDirectoryGroup, protocolDistributionGroup, addressMapGroup, nlHostGroup, nlMatrixGroup, alHostGroup, alMatrixGroup, usrHistoryGroup, probeInformationGroup } OBJECT nlMatrixTopNControlRateBase SYNTAX INTEGER { nlMatrixTopNPkts(1), nlMatrixTopNOctets(2) } DESCRIPTION "Conformance to RMON2 requires only support for these values of nlMatrixTopNControlRateBase." OBJECT alMatrixTopNControlRateBase SYNTAX INTEGER { alMatrixTopNTerminalsPkts(1), alMatrixTopNTerminalsOctets(2), alMatrixTopNAllPkts(3), alMatrixTopNAllOctets(4) } DESCRIPTION "Conformance to RMON2 requires only support for these Waldbusser Standards Track [Page 124] RFC 4502 Remote Network Monitoring MIB May 2006 values of alMatrixTopNControlRateBase." GROUP rmon1EnhancementGroup DESCRIPTION "The rmon1EnhancementGroup is mandatory for systems that implement RMON [RFC2819]." GROUP rmon1EthernetEnhancementGroup DESCRIPTION "The rmon1EthernetEnhancementGroup is optional and is appropriate for systems that implement the Ethernet group of RMON [RFC2819]." ::= { rmon2MIBCompliances 2 } protocolDirectoryGroup OBJECT-GROUP OBJECTS { protocolDirLastChange, protocolDirLocalIndex, protocolDirDescr, protocolDirType, protocolDirAddressMapConfig, protocolDirHostConfig, protocolDirMatrixConfig, protocolDirOwner, protocolDirStatus } STATUS current DESCRIPTION "Lists the inventory of protocols the probe has the capability of monitoring and allows the addition, deletion, and configuration of entries in this list." ::= { rmon2MIBGroups 1 } protocolDistributionGroup OBJECT-GROUP OBJECTS { protocolDistControlDataSource, protocolDistControlDroppedFrames, protocolDistControlCreateTime, protocolDistControlOwner, protocolDistControlStatus, protocolDistStatsPkts, protocolDistStatsOctets } STATUS current DESCRIPTION "Collects the relative amounts of octets and packets for the different protocols detected on a network segment." ::= { rmon2MIBGroups 2 } addressMapGroup OBJECT-GROUP OBJECTS { addressMapInserts, addressMapDeletes, addressMapMaxDesiredEntries, addressMapControlDataSource, addressMapControlDroppedFrames, addressMapControlOwner, addressMapControlStatus, addressMapPhysicalAddress, addressMapLastChange } STATUS current Waldbusser Standards Track [Page 125] RFC 4502 Remote Network Monitoring MIB May 2006 DESCRIPTION "Lists MAC address to network address bindings discovered by the probe and what interface they were last seen on." ::= { rmon2MIBGroups 3 } nlHostGroup OBJECT-GROUP OBJECTS { hlHostControlDataSource, hlHostControlNlDroppedFrames, hlHostControlNlInserts, hlHostControlNlDeletes, hlHostControlNlMaxDesiredEntries, hlHostControlAlDroppedFrames, hlHostControlAlInserts, hlHostControlAlDeletes, hlHostControlAlMaxDesiredEntries, hlHostControlOwner, hlHostControlStatus, nlHostInPkts, nlHostOutPkts, nlHostInOctets, nlHostOutOctets, nlHostOutMacNonUnicastPkts, nlHostCreateTime } STATUS current DESCRIPTION "Counts the amount of traffic sent from and to each network address discovered by the probe. Note that while the hlHostControlTable also has objects that control an optional alHostTable, implementation of the alHostTable is not required to fully implement this group." ::= { rmon2MIBGroups 4 } nlMatrixGroup OBJECT-GROUP OBJECTS { hlMatrixControlDataSource, hlMatrixControlNlDroppedFrames, hlMatrixControlNlInserts, hlMatrixControlNlDeletes, hlMatrixControlNlMaxDesiredEntries, hlMatrixControlAlDroppedFrames, hlMatrixControlAlInserts, hlMatrixControlAlDeletes, hlMatrixControlAlMaxDesiredEntries, hlMatrixControlOwner, hlMatrixControlStatus, nlMatrixSDPkts, nlMatrixSDOctets, nlMatrixSDCreateTime, nlMatrixDSPkts, nlMatrixDSOctets, nlMatrixDSCreateTime, nlMatrixTopNControlMatrixIndex, nlMatrixTopNControlRateBase, nlMatrixTopNControlTimeRemaining, nlMatrixTopNControlGeneratedReports, nlMatrixTopNControlDuration, nlMatrixTopNControlRequestedSize, nlMatrixTopNControlGrantedSize, nlMatrixTopNControlStartTime, nlMatrixTopNControlOwner, nlMatrixTopNControlStatus, nlMatrixTopNProtocolDirLocalIndex, nlMatrixTopNSourceAddress, nlMatrixTopNDestAddress, nlMatrixTopNPktRate, nlMatrixTopNReversePktRate, Waldbusser Standards Track [Page 126] RFC 4502 Remote Network Monitoring MIB May 2006 nlMatrixTopNOctetRate, nlMatrixTopNReverseOctetRate } STATUS current DESCRIPTION "Counts the amount of traffic sent between each pair of network addresses discovered by the probe. Note that while the hlMatrixControlTable also has objects that control optional alMatrixTables, implementation of the alMatrixTables is not required to fully implement this group." ::= { rmon2MIBGroups 5 } alHostGroup OBJECT-GROUP OBJECTS { alHostInPkts, alHostOutPkts, alHostInOctets, alHostOutOctets, alHostCreateTime } STATUS current DESCRIPTION "Counts the amount of traffic, by protocol, sent from and to each network address discovered by the probe. Implementation of this group requires implementation of the Network-Layer Host Group." ::= { rmon2MIBGroups 6 } alMatrixGroup OBJECT-GROUP OBJECTS { alMatrixSDPkts, alMatrixSDOctets, alMatrixSDCreateTime, alMatrixDSPkts, alMatrixDSOctets, alMatrixDSCreateTime, alMatrixTopNControlMatrixIndex, alMatrixTopNControlRateBase, alMatrixTopNControlTimeRemaining, alMatrixTopNControlGeneratedReports, alMatrixTopNControlDuration, alMatrixTopNControlRequestedSize, alMatrixTopNControlGrantedSize, alMatrixTopNControlStartTime, alMatrixTopNControlOwner, alMatrixTopNControlStatus, alMatrixTopNProtocolDirLocalIndex, alMatrixTopNSourceAddress, alMatrixTopNDestAddress, alMatrixTopNAppProtocolDirLocalIndex, alMatrixTopNPktRate, alMatrixTopNReversePktRate, alMatrixTopNOctetRate, alMatrixTopNReverseOctetRate } STATUS current DESCRIPTION "Counts the amount of traffic, by protocol, sent between each pair of network addresses discovered by the probe. Implementation of this group requires implementation of the Network-Layer Matrix Group." ::= { rmon2MIBGroups 7 } usrHistoryGroup OBJECT-GROUP Waldbusser Standards Track [Page 127] RFC 4502 Remote Network Monitoring MIB May 2006 OBJECTS { usrHistoryControlObjects, usrHistoryControlBucketsRequested, usrHistoryControlBucketsGranted, usrHistoryControlInterval, usrHistoryControlOwner, usrHistoryControlStatus, usrHistoryObjectVariable, usrHistoryObjectSampleType, usrHistoryIntervalStart, usrHistoryIntervalEnd, usrHistoryAbsValue, usrHistoryValStatus } STATUS current DESCRIPTION "The usrHistoryGroup provides user-defined collection of historical information from MIB objects on the probe." ::= { rmon2MIBGroups 8 } probeInformationGroup OBJECT-GROUP OBJECTS { probeCapabilities, probeSoftwareRev, probeHardwareRev, probeDateTime } STATUS current DESCRIPTION "This group describes various operating parameters of the probe and controls the local time of the probe." ::= { rmon2MIBGroups 9 } probeConfigurationGroup OBJECT-GROUP OBJECTS { probeResetControl, probeDownloadFile, probeDownloadTFTPServer, probeDownloadAction, probeDownloadStatus, serialMode, serialProtocol, serialTimeout, serialModemInitString, serialModemHangUpString, serialModemConnectResp, serialModemNoConnectResp, serialDialoutTimeout, serialStatus, netConfigIPAddress, netConfigSubnetMask, netConfigStatus, netDefaultGateway, trapDestCommunity, trapDestProtocol, trapDestAddress, trapDestOwner, trapDestStatus, serialConnectDestIpAddress, serialConnectType, serialConnectDialString, serialConnectSwitchConnectSeq, serialConnectSwitchDisconnectSeq, serialConnectSwitchResetSeq, serialConnectOwner, serialConnectStatus } STATUS deprecated DESCRIPTION "This group controls the configuration of various operating parameters of the probe. This group is not referenced by any MODULE-COMPLIANCE macro because it is 'grandfathered' from more recent MIB review rules that would require it." ::= { rmon2MIBGroups 10 } Waldbusser Standards Track [Page 128] RFC 4502 Remote Network Monitoring MIB May 2006 rmon1EnhancementGroup OBJECT-GROUP OBJECTS { historyControlDroppedFrames, hostControlDroppedFrames, hostControlCreateTime, matrixControlDroppedFrames, matrixControlCreateTime, channelDroppedFrames, channelCreateTime, filterProtocolDirDataLocalIndex, filterProtocolDirLocalIndex } STATUS current DESCRIPTION "This group adds some enhancements to RMON-1 that help management stations." ::= { rmon2MIBGroups 11 } rmon1EthernetEnhancementGroup OBJECT-GROUP OBJECTS { etherStatsDroppedFrames, etherStatsCreateTime } STATUS current DESCRIPTION "This group adds some enhancements to RMON-1 that help management stations." ::= { rmon2MIBGroups 12 } rmon1TokenRingEnhancementGroup OBJECT-GROUP OBJECTS { tokenRingMLStatsDroppedFrames, tokenRingMLStatsCreateTime, tokenRingPStatsDroppedFrames, tokenRingPStatsCreateTime, ringStationControlDroppedFrames, ringStationControlCreateTime, sourceRoutingStatsDroppedFrames, sourceRoutingStatsCreateTime } STATUS deprecated DESCRIPTION "This group adds some enhancements to RMON-1 that help management stations. This group is not referenced by any MODULE-COMPLIANCE macro because it is 'grandfathered' from more recent MIB review rules that would require it." ::= { rmon2MIBGroups 13 } END Waldbusser Standards Track [Page 129] RFC 4502 Remote Network Monitoring MIB May 2006 7. Security Considerations In order to implement this MIB, a probe must capture all packets on the locally-attached network, including packets between third parties. These packets are analyzed to collect network addresses, protocol usage information, and conversation statistics. Data of this nature may be considered sensitive in some environments. In such environments, the administrator may wish to restrict SNMP access to the probe. The usrHistoryGroup periodically samples the values of user-specified variables on the probe and stores them in another table. Since the access-control specified for a stored snapshot may be different from the access-control for the sampled variable, the agent MUST ensure that usrHistoryObjectVariable is not writable in MIB views that don't already have read access to the entire agent. Because the access control configuration can change over time, information could later be deemed sensitive that would still be accessible to this function. For this reason, an agent SHOULD check the access control on every sample. If an agent doesn't implement the latter check, there is potential for sensitive information to be revealed. A probe implementing this MIB is likely to also implement RMON [RFC2819], which includes functions for returning the contents of captured packets, potentially including sensitive user data or passwords. It is recommended that SNMP access to these functions be restricted. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Waldbusser Standards Track [Page 130] RFC 4502 Remote Network Monitoring MIB May 2006 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Waldbusser Standards Track [Page 131] RFC 4502 Remote Network Monitoring MIB May 2006 8. Appendix - TimeFilter Implementation Notes 1) Theory of Operation The TimeFilter mechanism allows an NMS to reduce the number of SNMP transactions required for a 'table-update' operation, by retrieving only the rows that have changed since a specified time (usually the last poll time). Polling of tables that incorporate a 'TimeFilter' INDEX can be reduced to a theoretical minimum (if used correctly). It can be easily implemented by an agent in a way independent of the number of NMS applications using the same time-filtered table. Although the name 'TimeFilter' may imply that a history of change events is maintained by the agent, this is not the case. A time- filtered-value represents the current value of the object instance, not the 'saved' value at the time indicated by the TimeFilter INDEX value. Note that TimeFilter objects only appear in INDEX clauses (always not-accessible), so their value is never retrieved. By design, the actual value of a TimeFilter instance is not in itself meaningful (it's not a 'last-change-timestamp'). The TimeFilter is a boolean filtering function applied in internal Get* PDU processing. If the 'last-change-time' of the specified instance is less than the particular TimeFilter INDEX value, then the instance is considered 'not-present', and either it is skipped for GetNext and GetBulk PDUs, or a 'noSuchInstance' exception is returned for Get PDUs. For TimeFilter purposes: - a row is created when an accessible column is created within the row. - a column that is created or deleted causes the TimeFilter to update the time-stamp, only because the value of the column is changing (non-existent <-> some value). - a row is deleted when all accessible columns are deleted. This event is not detectable with TimeFilter, and deleted rows are not retrievable with SNMP. 1.1) Agent Implementation of a Time-Filtered Table In implementation, the time-filtered rows (one for each tick of sysUpTime) are only conceptual. The agent simply filters a real table based on: * the current value of sysUpTime, Waldbusser Standards Track [Page 132] RFC 4502 Remote Network Monitoring MIB May 2006 * the TimeFilter value passed in the varbind, and * the last-update timestamp of each requested row (agent implementation requirement). For example, to implement a time-filtered table row (e.g., set of counters), an agent maintains a timestamp in a 32-bit storage location, initialized to zero. This is in addition to whatever instrumentation is needed for the set of counters. Each time one of the counters is updated, the current value of sysUpTime is recorded in the associated timestamp. If this is not possible or practical, then a background polling process must 'refresh' the timestamp by sampling counter values and comparing them to recorded samples. The timestamp update must occur within 5 seconds of the actual change event. When an agent receives a Get, GetNext, or GetBulk PDU requesting a time-filtered instance, after the agent has determined that the instance is within the specified MIB view, the following conceptual test is applied to determine if the object is returned or filtered: /* return TRUE if the object is present */ boolean time_filter_test ( TimeFilter last_modified_timestamp, TimeFilter index_value_in_pdu ) { if (last_modified_timestamp < index_value_in_pdu) return FALSE; else return TRUE; } The agent applies this function regardless of the lastActivationTime of the conceptual row in question. In other words, counter discontinuities are ignored (i.e., a conceptual row is deleted and then re-created later). An agent should consider an object instance 'changed' when it is created (either at restart time for scalars and static objects, or row-creation-time for dynamic tables). Note that using a timeFilter INDEX value of zero removes the filtering functionality, as the instance will always be 'present' according to the test above. After some deployment experience, it has been determined that a time-filtered table is more efficient to use if the agent stops a MIB walk operation after one time-filtered entry. That is, a GetNext or GetBulk operation will provide one pass through a given table (i.e., Waldbusser Standards Track [Page 133] RFC 4502 Remote Network Monitoring MIB May 2006 the agent will continue to the next object or table) instead of incrementing a TimeMark INDEX value, even if there exist higher TimeMark values that are valid for the same conceptual row. It is acceptable for an agent to implement a time-filtered table in this manner or in the traditional manner (i.e., every conceptual time-filtered instance is returned in GetNext and GetBulk PDU responses). 1.2) NMS Implementation of a Time-Filtered Table The particular TimeFilter INDEX values used by an NMS reflect the polling interval of the NMS, relative to the particular agent's notion of sysUpTime. An NMS needs to maintain one timestamp variable per agent (initialized to zero) for an arbitrary group of time-filtered MIB objects that are gathered together in the same PDU. Each time the Get* PDU is sent, a request for sysUpTime is included. The retrieved sysUpTime value is used as the timeFilter value in the next polling cycle. If a polling sweep of a time-filtered group of objects requires more than one SNMP transaction, then the sysUpTime value retrieved in the first GetResponse PDU of the polling sweep is saved as the next timeFilter value. The actual last-update time of a given object is not indicated in the returned GetResponse instance identifier, but rather the timeFilter value passed in the Get*Request PDU is returned. A "time-filtered get-next/bulk-sweep", done once per polling cycle, is a series of GetNext or GetBulk transactions and is over when one of the following events occurs: 1) the TimeFilter index value returned in the GetResponse is different from the TimeFilter index value passed in the GetNext or GetBulk request. Counter values will still be returned beyond this point (until the last-change-time is reached), but most likely the same values will be returned. 2) the return PDU includes instances lexigraphically greater than the objects expected (i.e., same GetNext semantics as if the TimeFilter weren't there). 3) a noSuchName or other exception/error is returned. Note that the use of a time-filtered table in combination with a GetRequest PDU neutralizes any optimization that otherwise might be achieved with the TimeFilter. Either the current time-filtered Waldbusser Standards Track [Page 134] RFC 4502 Remote Network Monitoring MIB May 2006 object-value is returned, or, if there is no time-filtered object- value instance, then a 'noSuchInstance' exception (SNMPv2c or SNMPv3) or 'noSuchName' error (SNMPv1) is returned. 2) TimeFilter Example The following example demonstrates how an NMS and Agent might use a table with a TimeFilter object in the INDEX. A static table is assumed to keep the example simple, but dynamic tables can also be supported. 2.1) General Assumptions fooEntry INDEX { fooTimeMark, fooIfIndex } FooEntry = SEQUENCE { fooTimeMark TimeFilter, fooIfIndex Integer32, fooCounts Counter32 } The NMS polls the fooTable every 15 seconds, and the baseline poll occurs when the agent has been up for 6 seconds, and when the NMS has been up for 10 seconds. There are 2 static rows in this table at system initialization (fooCounts.0.1 and fooCounts.0.2). Row 1 was updated as follows: SysUpTime fooCounts.*.1 value 500 1 900 2 2300 3 Row 2 was updated as follows: SysUpTime fooCounts.*.2 value 1100 1 1400 2 2.2) SNMP Transactions from NMS Perspective Time nms-1000: # NMS baseline poll -- get everything since last agent # restart - TimeFilter == 0 get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, fooCounts.0); Waldbusser Standards Track [Page 135] RFC 4502 Remote Network Monitoring MIB May 2006 returns: sysUpTime.0 == 600 fooCounts.0.1 == 1 # incremented at time 500 fooCounts.0.2 == 0 # visible; created at time 0 Time nms-2500: # NMS 1st poll # TimeFilter index == 600 get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, fooCounts.600); returns: sysUpTime.0 == 2100 fooCounts.600.1 == 2 # incremented at time 900 fooCounts.601.1 == 2 # indicates end of sweep Time nms-4000: # NMS 2nd poll # TimeFilter == 2100 get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, fooCounts.2100); returns: sysUpTime.0 == 3600 fooCounts.2100.1 == 3 # incremented at time 2300 fooCounts.2102.1 == 3 # indicates end-of-sweep # the counter value for row 2 is not returned because # it hasn't changed since sysUpTime == 2100. # The next timetick value for row 1 is returned instead Time nms-5500: # NMS 3rd poll # TimeFilter == 3600 get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, fooCounts.3600); returns: sysUpTime.0 == 5100 some-instance-outside-the-fooTable == some-instance-outside-the-fooTable == # no 'fooTable' counter values at all are returned # because neither counter has been updated since # sysUpTime == 3600 Waldbusser Standards Track [Page 136] RFC 4502 Remote Network Monitoring MIB May 2006 2.3) Transactions and TimeFilter Maintenance: Agent Perspective Time agt-0: # initialize fooTable fooCounts.1 = 0; changed.1 = 0; fooCounts.2 = 0; changed.2 = 0; Time agt-500: # increment fooCounts.1 ++fooCounts.1; changed.1 = 500; Time agt-600 # answer get-bulk # get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, # fooCounts.0); # (changed >= 0) # return both counters Time agt-900: # increment fooCounts.1 ++fooCounts.1; changed.1 = 900; Time agt-1100: # increment fooCounts.2 ++fooCounts.2; changed.2 = 1100; Time agt-1400: # increment fooCounts.2 ++fooCounts.2; changed.2 = 1400; Time agt-2100 # answer get-bulk # get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, # fooCounts.600); # (changed >= 600) # return both counters Time agt-2300: # increment fooCounts.1 ++fooCounts.1; changed.1 = 2300; Time agt-3600: # answer get-bulk # get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, # fooCounts.2100); # (changed >= 2100) # return only fooCounts.1 from the fooTable--twice Waldbusser Standards Track [Page 137] RFC 4502 Remote Network Monitoring MIB May 2006 Time agt-5100: # answer get-bulk # get-bulk(nonRptrs=1, maxReps=2, sysUpTime.0, # fooCounts.3600); # (changed >= 3600) # return lexigraphically-next two MIB instances 9. Changes since RFC 2021 This version obsoletes the proposed-standard version of the RMON2 MIB (published as RFC 2021) by adding 2 new enumerations to the nlMatrixTopNControlRateBase object and 4 new enumerations to the alMatrixTopNControlRateBase object. These new enumerations support the creation of high capacity top N reports in the High Capacity RMON MIB [RFC3273]. Additionally, the following objects have been deprecated, as they have not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard: probeDownloadFile probeDownloadTFTPServer probeDownloadAction probeDownloadStatus serialMode serialProtocol serialTimeout serialModemInitString serialModemHangUpString serialModemConnectResp serialModemNoConnectResp serialDialoutTimeout serialStatus serialConnectDestIpAddress serialConnectType serialConnectDialString serialConnectSwitchConnectSeq serialConnectSwitchDisconnectSeq serialConnectSwitchResetSeq serialConnectOwner serialConnectStatus netConfigIPAddress netConfigSubnetMask netConfigStatus netDefaultGateway tokenRingMLStats2DroppedFrames tokenRingMLStats2CreateTime tokenRingPStats2DroppedFrames Waldbusser Standards Track [Page 138] RFC 4502 Remote Network Monitoring MIB May 2006 tokenRingPStats2CreateTime ringStationControl2DroppedFrames ringStationControl2CreateTime sourceRoutingStats2DroppedFrames sourceRoutingStats2CreateTime trapDestIndex trapDestCommunity trapDestProtocol trapDestAddress trapDestOwner trapDestStatus In addition, two corrections were made. The LastCreateTime Textual Convention had been defined with a base type of another textual convention, which isn't allowed in SMIv2. The definition has been modified to use TimeTicks as the base type. Further, the SerialConfigEntry SEQUENCE definition included sub- typing information that is not allowed in SMIv2. This information has been deleted. Ranges were added to a number of objects and textual-conventions to constrain their maximum (and sometimes minimum) sizes. The addition of these ranges documents existing practice for these objects. These objects are: ControlString protocolDirID protocolDirParameters addressMapNetworkAddress nlHostAddress nlMatrixSDSourceAddress nlMatrixSDDestAddress nlMatrixDSSourceAddress nlMatrixDSDestAddress nlMatrixTopNSourceAddress nlMatrixTopNDestAddress alHostEntry alMatrixSDEntry alMatrixDSEntry alMatrixTopNSourceAddress alMatrixTopNDestAddress Finally, the TimeFilter TC has been updated to encourage agent implementations that allow a MIB walk to behave well even when performed by an application that is not aware of the special TimeFilter semantics. Waldbusser Standards Track [Page 139] RFC 4502 Remote Network Monitoring MIB May 2006 10. Acknowledgements This document was produced by the IETF Remote Network Monitoring Working Group. The TimeFilter mechanism was invented and documented by Jeanne Haney and further documented by Andy Bierman. The User History group was created by Andy Bierman. 11. References 11.1. Normative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC3273] Waldbusser, S., "Remote Network Monitoring Management Information Base for High Capacity Networks", RFC 3273, July 2002. [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC1513] Waldbusser, S., "Token Ring Extensions to the Remote Network Monitoring MIB", RFC 1513, September 1993. 11.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Waldbusser Standards Track [Page 140] RFC 4502 Remote Network Monitoring MIB May 2006 [RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Author's Address Steve Waldbusser Phone: +1 650-948-6500 Fax: +1 650-745-0671 EMail: waldbusser@nextbeacon.com Waldbusser Standards Track [Page 141] RFC 4502 Remote Network Monitoring MIB May 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Waldbusser Standards Track [Page 142] snmp-mibs-downloader-1.1/mibrfcs/rfc4544.txt0000644000000000000000000046157511402176072015605 0ustar Network Working Group M. Bakke Request for Comments: 4544 Cisco Systems Category: Standards Track M. Krueger Hewlett-Packard T. McSweeney IBM J. Muchow Qlogic Corp. May 2006 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). Bakke, et al. Standards Track [Page 1] RFC 4544 iSCSI MIB May 2006 Table of Contents 1. Introduction ....................................................3 2. Specification of Requirements ...................................3 3. The Internet-Standard Management Framework ......................3 4. Relationship to Other MIB Modules ...............................3 5. Relationship to SNMP Contexts ...................................4 6. Discussion ......................................................4 6.1. iSCSI MIB Object Model .....................................5 6.2. iSCSI MIB Table Structure ..................................6 6.3. iscsiInstance ..............................................7 6.4. iscsiPortal ................................................7 6.5. iscsiTargetPortal ..........................................9 6.6. iscsiInitiatorPortal .......................................9 6.7. iscsiNode .................................................10 6.8. iscsiTarget ...............................................10 6.9. iscsiTgtAuthorization .....................................11 6.10. iscsiInitiator ...........................................11 6.11. iscsiIntrAuthorization ...................................11 6.12. iscsiSession .............................................11 6.13. iscsiConnection ..........................................12 6.14. IP Addresses and TCP Port Numbers ........................12 6.15. Descriptors: Using OIDs in Place of Enumerated Types .....13 6.16. Notifications ............................................13 7. MIB Definitions ................................................14 8. Security Considerations ........................................79 9. IANA Considerations ............................................80 10. Normative References ..........................................80 11. Informative References ........................................81 12. Acknowledgements ..............................................81 Bakke, et al. Standards Track [Page 2] RFC 4544 iSCSI MIB May 2006 1. Introduction This document defines a MIB module for iSCSI [RFC3720], used to manage devices that implement the iSCSI protocol. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Relationship to Other MIB Modules The iSCSI MIB module is normally layered between the SCSI MIB module [RFC4455] and the TCP MIB module [RFC4022], and makes use of the IP Storage (IPS) Identity Authentication MIB module [RFC4545]. Here is how these modules are related: SCSI MIB Within systems where a SCSI layer is present, each iscsiNode, whether it has an initiator role, target role, or both, is related to one SCSI device within the SCSI MIB module. In this case, the iscsiNodeTransportType attribute points to the SCSI transport object within the SCSI MIB module, which in turn contains an attribute that points back to the iscsiNode. In this way, a management station can navigate between the two MIB modules. In systems where a SCSI layer is not present, such as within an iSCSI proxy device, the iscsiNodeTransportType attribute points to the appropriate corresponding object within the appropriate MIB, or is left blank. Bakke, et al. Standards Track [Page 3] RFC 4544 iSCSI MIB May 2006 TCP MIB Each iSCSI connection is related to one transport-level connection. Currently, iSCSI uses only TCP; the iSCSI connection is related to a TCP connection using its normal (protocol, source address, source port, destination address, destination port) 5-tuple. AUTH MIB Each iSCSI node that serves a target role can have a list of authorized initiators. Each of the entries in this list points to an identity within the IPS Identity Authentication MIB module that will be allowed to access the target. iSCSI nodes that serve in an initiator role can also have a list of authorized targets. Each of the entries in this list points to an identity within the Auth MIB module to which the initiator should attempt to establish sessions. The Auth MIB module includes information used to identify initiators and targets by their iSCSI name, IP address, and/or credentials. This MIB module imports objects from RFCs 2578 [RFC2578], 2579 [RFC2579], 2580 [RFC2580], and 3411 [RFC3411]. It also imports textual conventions from the INET-ADDRESS-MIB [RFC4001]. 5. Relationship to SNMP Contexts Each non-scalar object in the iSCSI MIB module is indexed first by an iSCSI Instance. Each instance is a collection of nodes, portals, sessions, etc., that can define a physical or virtual partitioning of an iSCSI-capable device. The use of an instance works well with partitionable or hierarchical storage devices and fits in logically with other management schemes. Instances do not replace SNMP contexts, however they do provide a very simple way to assign a virtual or physical partition of a device to one or more SNMP contexts, without having to do so for each individual node, portal, and session row. 6. Discussion This MIB module structure supplies configuration, fault, and statistics information for iSCSI devices [RFC3720]. It is structured around the well-known iSCSI objects, such as targets, initiators, sessions, connections, and the like. This MIB module may also be used to configure access to iSCSI targets, by creating iSCSI Portals and authorization list entries. Bakke, et al. Standards Track [Page 4] RFC 4544 iSCSI MIB May 2006 It is worthwhile to note that this is an iSCSI MIB module and as such reflects only iSCSI objects. This module does not contain information about the SCSI-layer attributes of a device. If a SCSI layer is present, the SCSI MIB module, currently under development, may be used to manage SCSI information for a device. The iSCSI MIB module consists of several "objects", each of which is represented by one or more tables. This section contains a brief description of the "object" hierarchy and a description of each object, followed by a discussion of the actual table structure within the objects. 6.1. iSCSI MIB Object Model The top-level object in this structure is the iSCSI instance, which "contains" all of the other objects. iscsiInstance -- A distinct iSCSI entity within the managed system. iscsiPortal -- An IP address used by this instance iscsiTargetPortal -- Contains portal information relevant when the portal -- is used to listen for connections to its targets. iscsiInitiatorPortal -- Contains portal information relevant when the portal -- is used to initiate connections to other targets. iscsiNode -- An iSCSI node can act as an initiator, a target, or both. -- Contains generic (non-role-specific) information. iscsiTarget -- Target-specific iSCSI node information. iscsiTgtAuth -- A list of initiator identities that are allowed -- access to this target. iscsiInitiator -- Initiator-specific iSCSI node information. iscsiIntrAuth -- A list of target identities to which this initiator -- is configured to establish sessions. iscsiSession -- An active iSCSI session between an initiator and target. -- The session's direction may be Inbound (outside -- initiator to our target) or Outbound (our initiator to -- an outside target). iscsiConnection -- An active TCP connection within an iSCSI session. Bakke, et al. Standards Track [Page 5] RFC 4544 iSCSI MIB May 2006 An iSCSI node can be an initiator, a target, or both. The iSCSI node's portals may be used to initiate connections (initiator) or listen for connections (target), depending on whether the iSCSI node is acting as an initiator or target. The iSCSI MIB module assumes that any target may be accessed via any portal that can take on a target role, although other access controls not reflected in the module might limit this. 6.2. iSCSI MIB Table Structure Each iSCSI object exports one or more tables: an attributes table, and zero or more statistics tables, which augment the attributes table. Since iSCSI is an evolving standard, it is much cleaner to provide statistics and attributes as separate tables, allowing attributes and statistics to be added independently. In a few cases, there are multiple categories of statistics that will likely grow; in this case, an object will contain multiple statistics tables. iscsiObjects iscsiDescriptors iscsiInstance iscsiInstanceAttributesTable iscsiInstanceSsnErrorStatsTable -- Counts abnormal session terminations iscsiPortal iscsiPortalAttributesTable iscsiTargetPortal iscsiTgtPortalAttributesTable iscsiInitiatorPortal iscsiIntrPortalAttributesTable iscsiNode iscsiNodeAttributesTable iscsiTarget iscsiTargetAttributesTable iscsiTargetLoginStatsTable -- Counts successful and unsuccessful logins iscsiTargetLogoutStatsTable -- Counts normal and abnormal logouts iscsiTgtAuthorization iscsiTgtAuthAttributesTable iscsiInitiator iscsiInitiatorAttributesTable iscsiInitiatorLoginStatsTable -- Counts successful and unsuccessful logins iscsiInitiatorLogoutStatsTable -- Counts normal and abnormal logouts iscsiIntrAuthorization iscsiIntrAuthAttributesTable Bakke, et al. Standards Track [Page 6] RFC 4544 iSCSI MIB May 2006 iscsiSession iscsiSessionAttributesTable iscsiSessionStatsTable -- Performance-related counts (requests, responses, bytes) iscsiSessionCxnErrorStatsTable -- Counts digest errors, connection errors, etc. iscsiConnection iscsiConnectionAttributesTable Note that this module does not attempt to count everything that could be counted; it is designed to include only those counters that would be useful for identifying performance, security, and fault problems from a management station. 6.3. iscsiInstance The iscsiInstanceAttributesTable is the primary table of the iSCSI MIB module. Every table entry in this module is "owned" by exactly one iSCSI instance; all other table entries in the module include this table's index as their primary index. Most implementations will include just one iSCSI instance row in this table. However, this table exists to allow for multiple virtual instances. For example, many IP routing products now allow multiple virtual routers. The iSCSI MIB module has the same premise; a large system could be "partitioned" into multiple, distinct virtual systems. This also allows a single SNMP agent to proxy for multiple subsystems, perhaps a set of stackable devices, each of which has one or even more instances. The instance attributes include the iSCSI vendor and version, as well as information on the last target or initiator at the other end of a session that caused a session failure. The iscsiInstanceSsnErrorStatsTable augments the attributes table and provides statistics on session failures due to digest, connection, or iSCSI format errors. 6.4. iscsiPortal The iscsiPortalAttributesTable lists iSCSI portals that can be used to listen for connections to targets, to initiate connections to other targets, or to do both. Bakke, et al. Standards Track [Page 7] RFC 4544 iSCSI MIB May 2006 Each row in the table includes an IP address (either v4 or v6), and a transport protocol (currently only TCP is defined). Each portal may have additional attributes, depending on whether it is an initiator portal, a target portal, or both. Initiator portals also have portal tags; these are placed in corresponding rows in the iscsiIntrPortalAttributesTable. Target portals have both portal tags and ports (e.g., TCP listen ports if the transport protocol is TCP); these are placed in rows in the iscsiTgtPortalAttributesTable. Portal rows, along with their initiator and target portal counterparts, may be created and destroyed through this MIB module by a management station. Rows in the initiator and target portal tables are created and destroyed automatically by the agent, whenever a row is created or destroyed in the iscsiPortalAttributesTable, or if the value of iscsiPortalRoles changes. Attributes in these tables may then be modified by the management station if the agent implementation allows. When created by a management station, the iscsiPortalRoles attribute is used to control row creation in the initiator and target portal tables. Creating a row with the targetTypePortal bit set in iscsiPortalRoles will cause the implementation to start listening for iSCSI connections on the portal. Creating a row with the initiatorTypePortal bit set in iscsiPortalRoles will not necessarily cause connections to be established; it is left to the implementation whether and when to make use of the portal. Both bits may be set if the portal is to be used by both initiator and target nodes. When deleting a row in the iscsiPortalAttibutesTable, all connections associated with that row are terminated. The implementation may either terminate the connection immediately or request a clean shutdown as specified in [RFC3720]. An outbound connection (when an iscsiInitiatorPortal is deleted) matches the portal if its iscsiCxnLocalAddr matches the iscsiPortalAddr. An inbound connection (when an iscsiTargetPortal is deleted) matches the portal if its iscsiCxnLocalAddr matches the iscsiPortalAddr, and its iscsiCxnLocalPort matches the iscsiTargetPortalPort. Individual objects within a row in this table may not be modified while the row is active. For instance, changing the IP address of a portal requires that the rows associated with the old IP address be deleted, and new rows be created (in either order). Bakke, et al. Standards Track [Page 8] RFC 4544 iSCSI MIB May 2006 6.5. iscsiTargetPortal The iscsiTgtPortalAttributesTable contains target-specific attributes for iSCSI portals. Rows in this table use the same indices as their corresponding rows in the iscsiPortalAttributesTable, with the addition of iscsiNodeIndex. Rows in this table are created when the targetTypePortal bit is set in the iscsiPortalRoles attribute of the corresponding iscsiPortalAttributesEntry; they are destroyed when this bit is cleared. This table contains the TCP (or other protocol) port on which the socket is listening for incoming connections. It also includes a portal group aggregation tag; iSCSI target portals within this instance sharing the same tag can contain connections within the same session. This table will be empty for iSCSI instances that contain only initiators (such as iSCSI host driver implementations). Many implementations use the same target portal tag and protocol port for all nodes accessed via a portal. These implementations will create a single row in the iscsiTgtPortalAttributeTable, with an iscsiNodeIndex of zero. Other implementations do not use the same tag and/or port for all nodes; these implementations will create a row in this table for each (portal, node) tuple, using iscsiNodeIndex to designate the node for this portal tag and port. 6.6. iscsiInitiatorPortal The iscsiIntrPortalAttributesTable contains initiator-specific objects for iSCSI portals. Rows in this table use the same indices as their corresponding entries in the iscsiPortalAttributesTable. A row in this table is created when the initiatorTypePortal bit is set in the iscsiPortalRoles attribute; it is destroyed when this bit is cleared. Each row in this table contains a portal group aggregation tag, indicating which portals an initiator may use together within a multiple-connection session. This table will be empty for iSCSI instances that contain only targets (such as most iSCSI devices). Bakke, et al. Standards Track [Page 9] RFC 4544 iSCSI MIB May 2006 Many implementations use the same initiator tag for all nodes accessing targets via a given portal. These implementations will create a single row in iscsiIntrPortalAttributeTable, with an iscsiNodeIndex of zero. Other implementations do not use the same tag and/or port for all nodes; these implementations will create a row in this table for each (portal, node) tuple, using iscsiNodeIndex to designate the node for this portal tag and port. 6.7. iscsiNode The iscsiNodeAttributesTable contains a list of iSCSI nodes, each of which may have an initiator role, a target role, or both. This table contains the node's attributes that are common to both roles, such as its iSCSI name and alias string. Attributes specific to initiators or targets are available in the iscsiTarget and iscsiInitiator objects. Each row in this table that can fulfill a target role has a corresponding row in the iscsiTarget table; each entry that fulfills an initiator role has a row in the iscsiInitiator table. Nodes such as copy managers that can take on both roles have a corresponding row in each table. This table also contains the login negotiations preferences for this node. These objects indicate the values this node will offer or prefer in the operational negotiation phase of the login process. For most implementations, each entry in the table also contains a RowPointer to the transport table entry in the SCSI MIB module that this iSCSI node represents. For implementations without a standard SCSI layer above iSCSI, such as an iSCSI proxy or gateway, this RowPointer can point to a row in an implementation-specific table that this iSCSI node represents. 6.8. iscsiTarget The iscsiTargetAttributesTable contains target-specific attributes for iSCSI nodes. Each entry in this table uses the same index values as its corresponding iscsiNode entry. This table contains attributes used to indicate the last failure that was (or should have been) sent as a notification. This table is augmented by the iscsiTargetLoginStatsTable and the iscsiTargetLogoutStatsTable, which count the numbers of normal and abnormal logins and logouts to this target. Bakke, et al. Standards Track [Page 10] RFC 4544 iSCSI MIB May 2006 6.9. iscsiTgtAuthorization The iscsiTgtAuthAttributesTable contains an entry for each initiator identifier that will be allowed to access the target under which it appears. Each entry contains a RowPointer to a user identity in the IPS Authorization MIB module, which contains the name, address, and credential information necessary to authenticate the initiator. 6.10. iscsiInitiator The iscsiInitiatorAttributesTable contains a list of initiator- specific attributes for iSCSI nodes. Each entry in this table uses the same index values as its corresponding iscsiNode entry. Most implementations will include a single entry in this table, regardless of the number of physical interfaces the initiator may use. This table is augmented by the iscsiInitiatorLoginStatsTable and the iscsiInitiatorLogoutStatsTable, which count the numbers of normal and abnormal logins and logouts from this initiator. 6.11. iscsiIntrAuthorization The iscsiIntrAuthAttributesTable contains an entry for each target identifier to which the initiator is configured to establish a session. Each entry contains a RowPointer to a user identity in the IPS Authorization MIB module, which contains the name, address, and credential information necessary to identify (for discovery purposes) and authenticate the target. 6.12. iscsiSession The iscsiSessionAttributesTable contains a set of rows that list the sessions known to be existing locally for each node in each iSCSI instance. The session type for each session indicates whether the session is used for normal SCSI commands or for discovery using the SendTargets text command. Discovery sessions that do not belong to any particular node have a node index attribute of zero. Bakke, et al. Standards Track [Page 11] RFC 4544 iSCSI MIB May 2006 The session direction for each session indicates whether it is an Inbound session or an Outbound session. Inbound sessions are from some other initiator to the target node under which the session appears. Outbound sessions are from the initiator node under which the session appears to a target outside this iSCSI instance. Many attributes may be negotiated when starting an iSCSI session. Most of these attributes are included in the session object. Some attributes, such as the integrity and authentication schemes, have some standard values that can be extended by vendors to include their own schemes. These contain an object identifier, rather than the expected enumerated type, to allow these values to be extended by other MIB modules, such as an enterprise MIB module. The iscsiSessionStatsTable includes statistics related to performance; it counts iSCSI data bytes and PDUs. For implementations that support error recovery without terminating a session, the iscsiSessionCxnErrorStatsTable contains counters for the numbers of digest and connection errors that have occurred within the session. 6.13. iscsiConnection The iscsiConnectionAttributesTable contains a list of active connections within each session. It contains the IP addresses and TCP (or other protocol) ports of both the local and remote sides of the connection. These may be used to locate other connection-related information and statistics in the TCP MIB module [RFC4022]. The attributes table also contains a connection state. This state is not meant to directly map to the state tables included within the iSCSI specification; they are meant to be simplified, higher-level definitions of connection state that provide information more useful to a user or network manager. No statistics are kept for connections. 6.14. IP Addresses and TCP Port Numbers The IP addresses in this module are represented by two attributes, one of type InetAddressType, and the other of type InetAddress. These are taken from [RFC4001], which specifies how to support addresses that may be either IPv4 or IPv6. Bakke, et al. Standards Track [Page 12] RFC 4544 iSCSI MIB May 2006 The TCP port numbers that appear in a few of the structures are described as simply port numbers, with a protocol attribute indicating whether they are TCP ports or something else. This will allow the module to be compatible with iSCSI over transports other than TCP in the future. 6.15. Descriptors: Using OIDs in Place of Enumerated Types The iSCSI MIB module has a few attributes, namely, the digest method attributes, where an enumerated type would work well, except that an implementation may need to extend the attribute and add types of its own. To make this work, this MIB module defines a set of object identities within the iscsiDescriptors subtree. Each of these object identities is basically an enumerated type. Attributes that make use of these object identities have a value that is an Object Identifier (OID) instead of an enumerated type. These OIDs can indicate either the object identities defined in this module or object identities defined elsewhere, such as in an enterprise MIB module. Those implementations that add their own digest methods should also define a corresponding object identity for each of these methods within their own enterprise MIB module, and return its OID whenever one of these attributes is using that method. 6.16. Notifications Three notifications are provided. One is sent by an initiator detecting a critical login failure, another is sent by a target detecting a critical login failure, and the third is sent upon a session being terminated due to an abnormal connection or digest failure. Critical failures are defined as those that may expose security-related problems that may require immediate action, such as failures due to authentication, authorization, or negotiation problems. Attributes in the initiator, target, and instance objects provide the information necessary to send in the notification, such as the initiator or target name and IP address at the other end that may have caused the failure. To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing the iSCSI MIB module SHOULD NOT send more than three iSCSI notifications in any 10-second period. The 3-in-10 rule was chosen because one notification every three seconds was deemed often enough, but should two or three different notifications happen at the same time, it would not be desirable to suppress them. Three notifications in 10 seconds is a happy medium, Bakke, et al. Standards Track [Page 13] RFC 4544 iSCSI MIB May 2006 where a short burst of notifications is allowed, without inundating the network and/or notification host with a large number of notifications. 7. MIB Definitions ISCSI-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, NOTIFICATION-TYPE, Unsigned32, Counter32, Counter64, Gauge32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, RowPointer, TimeStamp, RowStatus, AutonomousType, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- RFC 4001 ; iscsiMibModule MODULE-IDENTITY LAST-UPDATED "200605220000Z" -- May 22, 2006 ORGANIZATION "IETF IPS Working Group" CONTACT-INFO " Mark Bakke Cisco Systems, Inc 7900 International Drive, Suite 400 Bloomington, MN USA 55425 E-mail: mbakke@cisco.com Marjorie Krueger Hewlett-Packard Networked Storage Architecture Networked Storage Solutions Org. 8000 Foothills Blvd. Roseville, CA 95747 Bakke, et al. Standards Track [Page 14] RFC 4544 iSCSI MIB May 2006 E-mail: marjorie_krueger@hp.com Tom McSweeney IBM Corporation 600 Park Offices Drive Research Triangle Park, NC USA 27709 E-mail: tommcs@us.ibm.com James Muchow Qlogic Corp. 6321 Bury Dr. Eden Prairie, MN USA 55346 E-mail: james.muchow@qlogic.com" DESCRIPTION "The iSCSI Protocol MIB module. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4544; see the RFC itself for full legal notices." REVISION "200605220000Z" -- May 22, 2006 DESCRIPTION "Initial version of the iSCSI Protocol MIB module" ::= { mib-2 142 } iscsiNotifications OBJECT IDENTIFIER ::= { iscsiMibModule 0 } iscsiObjects OBJECT IDENTIFIER ::= { iscsiMibModule 1 } iscsiConformance OBJECT IDENTIFIER ::= { iscsiMibModule 2 } iscsiAdmin OBJECT IDENTIFIER ::= { iscsiMibModule 3 } -- Textual Conventions IscsiTransportProtocol ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This data type is used to define the transport protocols that will carry iSCSI PDUs." REFERENCE "RFC791, RFC1700 The presently known, officially delegated numbers can be found at: http://www.iana.org/assignments/protocol-numbers" Bakke, et al. Standards Track [Page 15] RFC 4544 iSCSI MIB May 2006 SYNTAX Unsigned32 (0..255) IscsiDigestMethod ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the methods possible for digest negotiation. none - a placeholder for a secondary digest method that means only the primary method can be used. other - a digest method other than those defined below. noDigest - does not support digests (will operate without a digest (Note: implementations must support digests to be compliant with the RFC3720). CRC32c - require a CRC32C digest." REFERENCE "RFC 3720, Section 12.1, HeaderDigest and DataDigest" SYNTAX INTEGER { none(1), other(2), noDigest(3), crc32c(4) } IscsiName ::= TEXTUAL-CONVENTION DISPLAY-HINT "223t" STATUS current DESCRIPTION "This data type is used for objects whose value is an iSCSI name with the properties described in RFC 3720 section 3.2.6.1, and encoded as specified in RFC 3720 section 3.2.6.2. A zero-length string indicates the absence of an iSCSI name." REFERENCE "RFC 3720, Section 3.2.6, iSCSI Names." SYNTAX OCTET STRING (SIZE(0 | 16..223)) --********************************************************************** iscsiDescriptors OBJECT IDENTIFIER ::= { iscsiAdmin 1 } iscsiHeaderIntegrityTypes OBJECT IDENTIFIER ::= { iscsiDescriptors 1 } iscsiHdrIntegrityNone OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when no integrity scheme (for either the header or data) is being Bakke, et al. Standards Track [Page 16] RFC 4544 iSCSI MIB May 2006 used." REFERENCE "RFC 3720, Section 12.1, HeaderDigest and DataDigest" ::= { iscsiHeaderIntegrityTypes 1 } iscsiHdrIntegrityCrc32c OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when the integrity scheme (for either the header or data) is CRC32c." REFERENCE "RFC 3720, Section 12.1, HeaderDigest and DataDigest" ::= { iscsiHeaderIntegrityTypes 2 } iscsiDataIntegrityTypes OBJECT IDENTIFIER ::= { iscsiDescriptors 2 } iscsiDataIntegrityNone OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when no integrity scheme (for either the header or data) is being used." REFERENCE "RFC 3720, Section 12.1, HeaderDigest and DataDigest" ::= { iscsiDataIntegrityTypes 1 } iscsiDataIntegrityCrc32c OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when the integrity scheme (for either the header or data) is CRC32c." REFERENCE "RFC 3720, Section 12.1, HeaderDigest and DataDigest" ::= { iscsiDataIntegrityTypes 2 } --********************************************************************** iscsiInstance OBJECT IDENTIFIER ::= { iscsiObjects 1 } -- Instance Attributes Table iscsiInstanceAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiInstanceAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of iSCSI instances present on the system." ::= { iscsiInstance 1 } Bakke, et al. Standards Track [Page 17] RFC 4544 iSCSI MIB May 2006 iscsiInstanceAttributesEntry OBJECT-TYPE SYNTAX IscsiInstanceAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular iSCSI instance." INDEX { iscsiInstIndex } ::= { iscsiInstanceAttributesTable 1 } IscsiInstanceAttributesEntry ::= SEQUENCE { iscsiInstIndex Unsigned32, iscsiInstDescr SnmpAdminString, iscsiInstVersionMin Unsigned32, iscsiInstVersionMax Unsigned32, iscsiInstVendorID SnmpAdminString, iscsiInstVendorVersion SnmpAdminString, iscsiInstPortalNumber Unsigned32, iscsiInstNodeNumber Unsigned32, iscsiInstSessionNumber Unsigned32, iscsiInstSsnFailures Counter32, iscsiInstLastSsnFailureType AutonomousType, iscsiInstLastSsnRmtNodeName IscsiName, iscsiInstDiscontinuityTime TimeStamp } iscsiInstIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular iSCSI instance. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { iscsiInstanceAttributesEntry 1 } iscsiInstDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string, determined by the implementation to describe the iSCSI instance. When only a single instance is present, this object may be set to the zero-length string; with multiple iSCSI instances, it may be used in an implementation-dependent manner to describe the purpose of the respective instance." Bakke, et al. Standards Track [Page 18] RFC 4544 iSCSI MIB May 2006 ::= { iscsiInstanceAttributesEntry 2 } iscsiInstVersionMin OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum version number of the iSCSI specification such that this iSCSI instance supports this minimum value, the maximum value indicated by the corresponding instance in iscsiInstVersionMax, and all versions in between." REFERENCE "RFC 3720, Section 10.12, Login Request" ::= { iscsiInstanceAttributesEntry 3 } iscsiInstVersionMax OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum version number of the iSCSI specification such that this iSCSI instance supports this maximum value, the minimum value indicated by the corresponding instance in iscsiInstVersionMin, and all versions in between." REFERENCE "RFC 3720, Section 10.12, Login Request" ::= { iscsiInstanceAttributesEntry 4 } iscsiInstVendorID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string describing the manufacturer of the implementation of this instance." ::= { iscsiInstanceAttributesEntry 5 } iscsiInstVendorVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string set by the manufacturer describing the version of the implementation of this instance. The format of this string is determined solely by the manufacturer, and is for informational purposes only. Bakke, et al. Standards Track [Page 19] RFC 4544 iSCSI MIB May 2006 It is unrelated to the iSCSI specification version numbers." ::= { iscsiInstanceAttributesEntry 6 } iscsiInstPortalNumber OBJECT-TYPE SYNTAX Unsigned32 UNITS "transport endpoints" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of rows in the iscsiPortalAttributesTable that are currently associated with this iSCSI instance." ::= { iscsiInstanceAttributesEntry 7 } iscsiInstNodeNumber OBJECT-TYPE SYNTAX Unsigned32 UNITS "iSCSI nodes" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of rows in the iscsiNodeAttributesTable that are currently associated with this iSCSI instance." ::= { iscsiInstanceAttributesEntry 8 } iscsiInstSessionNumber OBJECT-TYPE SYNTAX Unsigned32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of rows in the iscsiSessionAttributesTable that are currently associated with this iSCSI instance." ::= { iscsiInstanceAttributesEntry 9 } iscsiInstSsnFailures OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of times a session belonging to this instance has been failed. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiInstDiscontinuityTime." REFERENCE "RFC 3720, Section 12.1, HeaderDigest and DataDigest" ::= { iscsiInstanceAttributesEntry 10 } iscsiInstLastSsnFailureType OBJECT-TYPE Bakke, et al. Standards Track [Page 20] RFC 4544 iSCSI MIB May 2006 SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The counter object in the iscsiInstSsnErrorStatsTable that was incremented when the last session failure occurred. If the reason for failure is not found in the iscsiInstSsnErrorStatsTable, the value { 0.0 } is used instead." ::= { iscsiInstanceAttributesEntry 11 } iscsiInstLastSsnRmtNodeName OBJECT-TYPE SYNTAX IscsiName MAX-ACCESS read-only STATUS current DESCRIPTION "The iSCSI name of the remote node from the failed session." ::= { iscsiInstanceAttributesEntry 12 } iscsiInstDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime on the most recent occasion at which any one or more of this instance's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { iscsiInstanceAttributesEntry 13 } -- Instance Session Failure Stats Table iscsiInstanceSsnErrorStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiInstanceSsnErrorStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics regarding the occurrences of error types that result in a session failure." ::= { iscsiInstance 2 } iscsiInstanceSsnErrorStatsEntry OBJECT-TYPE Bakke, et al. Standards Track [Page 21] RFC 4544 iSCSI MIB May 2006 SYNTAX IscsiInstanceSsnErrorStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular iSCSI instance." AUGMENTS { iscsiInstanceAttributesEntry } ::= { iscsiInstanceSsnErrorStatsTable 1 } IscsiInstanceSsnErrorStatsEntry ::= SEQUENCE { iscsiInstSsnDigestErrors Counter32, iscsiInstSsnCxnTimeoutErrors Counter32, iscsiInstSsnFormatErrors Counter32 } iscsiInstSsnDigestErrors OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of sessions that were failed due to receipt of a PDU containing header or data digest errors. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiInstDiscontinuityTime." REFERENCE "RFC 3720, Section 6.7, Digest Errors" ::= { iscsiInstanceSsnErrorStatsEntry 1 } iscsiInstSsnCxnTimeoutErrors OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of sessions that were failed due to a sequence exceeding a time limit. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiInstDiscontinuityTime." REFERENCE "RFC 3720, Section 6.4, Connection Timeout Management" ::= { iscsiInstanceSsnErrorStatsEntry 2 } iscsiInstSsnFormatErrors OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current Bakke, et al. Standards Track [Page 22] RFC 4544 iSCSI MIB May 2006 DESCRIPTION "The count of sessions that were failed due to receipt of a PDU that contained a format error. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiInstDiscontinuityTime." REFERENCE "RFC 3720, Section 6.6, Format Errors" ::= { iscsiInstanceSsnErrorStatsEntry 3 } --********************************************************************** iscsiPortal OBJECT IDENTIFIER ::= { iscsiObjects 2 } -- Portal Attributes Table iscsiPortalAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiPortalAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of transport endpoints (using TCP or another transport protocol) used by this iSCSI instance. An iSCSI instance may use a portal to listen for incoming connections to its targets, to initiate connections to other targets, or both." ::= { iscsiPortal 1 } iscsiPortalAttributesEntry OBJECT-TYPE SYNTAX IscsiPortalAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular portal instance." INDEX { iscsiInstIndex, iscsiPortalIndex } ::= { iscsiPortalAttributesTable 1 } IscsiPortalAttributesEntry ::= SEQUENCE { iscsiPortalIndex Unsigned32, iscsiPortalRowStatus RowStatus, iscsiPortalRoles BITS, iscsiPortalAddrType InetAddressType, iscsiPortalAddr InetAddress, iscsiPortalProtocol IscsiTransportProtocol, iscsiPortalMaxRecvDataSegLength Unsigned32, iscsiPortalPrimaryHdrDigest IscsiDigestMethod, iscsiPortalPrimaryDataDigest IscsiDigestMethod, iscsiPortalSecondaryHdrDigest IscsiDigestMethod, iscsiPortalSecondaryDataDigest IscsiDigestMethod, Bakke, et al. Standards Track [Page 23] RFC 4544 iSCSI MIB May 2006 iscsiPortalRecvMarker TruthValue, iscsiPortalStorageType StorageType } iscsiPortalIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular transport endpoint within this iSCSI instance. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { iscsiPortalAttributesEntry 1 } iscsiPortalRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. When the value of this object is 'active', the values of the other objects in this table cannot be changed. Rows may be discarded using RowStatus. Note that creating a row in this table will typically cause the agent to create one or more rows in iscsiTgtPortalAttributesTable and/or iscsiIntrPortalAttributesTable." ::= { iscsiPortalAttributesEntry 2 } iscsiPortalRoles OBJECT-TYPE SYNTAX BITS { targetTypePortal(0), initiatorTypePortal(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "A portal can operate in one or both of two roles: as a target portal and/or an initiator portal. If the portal will operate in both roles, both bits must be set. This object will define a corresponding row that Bakke, et al. Standards Track [Page 24] RFC 4544 iSCSI MIB May 2006 will exist or must be created in the iscsiTgtPortalAttributesTable, the iscsiIntrPortalAttributesTable or both. If the targetTypePortal bit is set, one or more corresponding iscsiTgtPortalAttributesEntry rows will be found or created. If the initiatorTypePortal bit is set, one or more corresponding iscsiIntrPortalAttributesEntry rows will be found or created. If both bits are set, one or more corresponding rows will be found or created in one of the above tables." ::= { iscsiPortalAttributesEntry 3 } iscsiPortalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet Network Address contained in the corresponding instance of the iscsiPortalAddr." DEFVAL { ipv4 } ::= { iscsiPortalAttributesEntry 4 } iscsiPortalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The portal's Internet Network Address, of the type specified by the object iscsiPortalAddrType. If iscsiPortalAddrType has the value 'dns', this address gets resolved to an IP address whenever a new iSCSI connection is established using this portal." ::= { iscsiPortalAttributesEntry 5 } iscsiPortalProtocol OBJECT-TYPE SYNTAX IscsiTransportProtocol MAX-ACCESS read-create STATUS current DESCRIPTION "The portal's transport protocol." DEFVAL { 6 } -- TCP ::= { iscsiPortalAttributesEntry 6 } iscsiPortalMaxRecvDataSegLength OBJECT-TYPE SYNTAX Unsigned32 (512..16777215) UNITS "bytes" MAX-ACCESS read-create STATUS current Bakke, et al. Standards Track [Page 25] RFC 4544 iSCSI MIB May 2006 DESCRIPTION "The maximum PDU length this portal can receive. This may be constrained by hardware characteristics and individual implementations may choose not to allow this object to be changed." REFERENCE "RFC 3720, Section 12.12, MaxRecvDataSegmentLength" DEFVAL { 8192 } ::= { iscsiPortalAttributesEntry 7 } iscsiPortalPrimaryHdrDigest OBJECT-TYPE SYNTAX IscsiDigestMethod MAX-ACCESS read-create STATUS current DESCRIPTION "The preferred header digest for this portal." DEFVAL { crc32c } ::= { iscsiPortalAttributesEntry 8 } iscsiPortalPrimaryDataDigest OBJECT-TYPE SYNTAX IscsiDigestMethod MAX-ACCESS read-create STATUS current DESCRIPTION "The preferred data digest method for this portal." DEFVAL { crc32c } ::= { iscsiPortalAttributesEntry 9 } iscsiPortalSecondaryHdrDigest OBJECT-TYPE SYNTAX IscsiDigestMethod MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate header digest preference for this portal." DEFVAL { noDigest } ::= { iscsiPortalAttributesEntry 10 } iscsiPortalSecondaryDataDigest OBJECT-TYPE SYNTAX IscsiDigestMethod MAX-ACCESS read-create STATUS current DESCRIPTION "An alternate data digest preference for this portal." DEFVAL { noDigest } ::= { iscsiPortalAttributesEntry 11 } iscsiPortalRecvMarker OBJECT-TYPE SYNTAX TruthValue Bakke, et al. Standards Track [Page 26] RFC 4544 iSCSI MIB May 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether or not this portal will request markers in its incoming data stream." REFERENCE "RFC 3720, Appendix A." DEFVAL { false } ::= { iscsiPortalAttributesEntry 12 } iscsiPortalStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { iscsiPortalAttributesEntry 13 } --********************************************************************** iscsiTargetPortal OBJECT IDENTIFIER ::= { iscsiObjects 3 } -- Target Portal Attributes Table iscsiTgtPortalAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiTgtPortalAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of transport endpoints (using TCP or another transport protocol) on which this iSCSI instance listens for incoming connections to its targets." ::= { iscsiTargetPortal 1 } iscsiTgtPortalAttributesEntry OBJECT-TYPE SYNTAX IscsiTgtPortalAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular portal instance that is used to listen for incoming connections to local targets. One or more rows in this table is populated by the agent for each Bakke, et al. Standards Track [Page 27] RFC 4544 iSCSI MIB May 2006 iscsiPortalAttributesEntry row that has the bit targetTypePortal set in its iscsiPortalRoles column." INDEX { iscsiInstIndex, iscsiPortalIndex, iscsiTgtPortalNodeIndexOrZero } ::= { iscsiTgtPortalAttributesTable 1 } IscsiTgtPortalAttributesEntry ::= SEQUENCE { iscsiTgtPortalNodeIndexOrZero Unsigned32, iscsiTgtPortalPort InetPortNumber, iscsiTgtPortalTag Unsigned32 } iscsiTgtPortalNodeIndexOrZero OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular node within an iSCSI instance present on the local system. For implementations where each {portal, node} tuple can have a different portal tag, this value will map to the iscsiNodeIndex. For implementations where the portal tag is the same for a given portal regardless of which node is using the portal, the value 0 (zero) is used." ::= { iscsiTgtPortalAttributesEntry 1 } iscsiTgtPortalPort OBJECT-TYPE SYNTAX InetPortNumber (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The portal's transport protocol port number on which the portal listens for incoming iSCSI connections when the portal is used as a target portal. This object's storage type is specified in iscsiPortalStorageType." ::= { iscsiTgtPortalAttributesEntry 2 } iscsiTgtPortalTag OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The portal's aggregation tag when the portal is used as a target portal. Multiple-connection sessions may Bakke, et al. Standards Track [Page 28] RFC 4544 iSCSI MIB May 2006 be aggregated over portals sharing an identical aggregation tag. This object's storage type is specified in iscsiPortalStorageType." REFERENCE "RFC 3720, Section 3.4.1, iSCSI Architectural Model" ::= { iscsiTgtPortalAttributesEntry 3 } --********************************************************************** iscsiInitiatorPortal OBJECT IDENTIFIER ::= { iscsiObjects 4 } -- Initiator Portal Attributes Table iscsiIntrPortalAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiIntrPortalAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Internet Network Addresses (using TCP or another transport protocol) from which this iSCSI instance may initiate connections to other targets." ::= { iscsiInitiatorPortal 1 } iscsiIntrPortalAttributesEntry OBJECT-TYPE SYNTAX IscsiIntrPortalAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular portal instance that is used to initiate connections to iSCSI targets. One or more rows in this table is populated by the agent for each iscsiPortalAttributesEntry row that has the bit initiatorTypePortal set in its iscsiPortalRoles column." INDEX { iscsiInstIndex, iscsiPortalIndex, iscsiIntrPortalNodeIndexOrZero } ::= { iscsiIntrPortalAttributesTable 1 } IscsiIntrPortalAttributesEntry ::= SEQUENCE { iscsiIntrPortalNodeIndexOrZero Unsigned32, iscsiIntrPortalTag Unsigned32 } iscsiIntrPortalNodeIndexOrZero OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION Bakke, et al. Standards Track [Page 29] RFC 4544 iSCSI MIB May 2006 "An arbitrary integer used to uniquely identify a particular node within an iSCSI instance present on the local system. For implementations where each {portal, node} tuple can have a different portal tag, this value will map to the iscsiNodeIndex. For implementations where the portal tag is the same for a given portal regardless of which node is using the portal, the value 0 (zero) is used." ::= { iscsiIntrPortalAttributesEntry 1 } iscsiIntrPortalTag OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The portal's aggregation tag when the portal is used as an initiator portal. Multiple-connection sessions may be aggregated over portals sharing an identical aggregation tag. This object's storage type is specified in iscsiPortalStorageType." REFERENCE "RFC 3720, Section 3.4.1, iSCSI Architectural Model" ::= { iscsiIntrPortalAttributesEntry 2 } --********************************************************************** iscsiNode OBJECT IDENTIFIER ::= { iscsiObjects 5 } -- Node Attributes Table iscsiNodeAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiNodeAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of iSCSI nodes belonging to each iSCSI instance present on the local system. An iSCSI node can act as an initiator, a target, or both." ::= { iscsiNode 1 } iscsiNodeAttributesEntry OBJECT-TYPE SYNTAX IscsiNodeAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Bakke, et al. Standards Track [Page 30] RFC 4544 iSCSI MIB May 2006 "An entry (row) containing management information applicable to a particular iSCSI node." INDEX { iscsiInstIndex, iscsiNodeIndex } ::= { iscsiNodeAttributesTable 1 } IscsiNodeAttributesEntry ::= SEQUENCE { iscsiNodeIndex Unsigned32, iscsiNodeName IscsiName, iscsiNodeAlias SnmpAdminString, iscsiNodeRoles BITS, iscsiNodeTransportType RowPointer, iscsiNodeInitialR2T TruthValue, iscsiNodeImmediateData TruthValue, iscsiNodeMaxOutstandingR2T Unsigned32, iscsiNodeFirstBurstLength Unsigned32, iscsiNodeMaxBurstLength Unsigned32, iscsiNodeMaxConnections Unsigned32, iscsiNodeDataSequenceInOrder TruthValue, iscsiNodeDataPDUInOrder TruthValue, iscsiNodeDefaultTime2Wait Unsigned32, iscsiNodeDefaultTime2Retain Unsigned32, iscsiNodeErrorRecoveryLevel Unsigned32, iscsiNodeDiscontinuityTime TimeStamp, iscsiNodeStorageType StorageType } iscsiNodeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular node within an iSCSI instance. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { iscsiNodeAttributesEntry 1 } iscsiNodeName OBJECT-TYPE SYNTAX IscsiName MAX-ACCESS read-only STATUS current DESCRIPTION "This node's iSCSI name, which is independent of the location of the node, and can be resolved into a set of addresses through various discovery services." ::= { iscsiNodeAttributesEntry 2 } Bakke, et al. Standards Track [Page 31] RFC 4544 iSCSI MIB May 2006 iscsiNodeAlias OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A character string that is a human-readable name or description of the iSCSI node. If configured, this alias may be communicated to the initiator or target node at the remote end of the connection during a Login Request or Response message. This string is not used as an identifier, but can be displayed by the system's user interface in a list of initiators and/or targets to which it is connected. If no alias exists, the value is a zero-length string." REFERENCE "RFC 3720, Section 12.6, TargetAlias, 12.7, InitiatorAlias" ::= { iscsiNodeAttributesEntry 3 } iscsiNodeRoles OBJECT-TYPE SYNTAX BITS { targetTypeNode(0), initiatorTypeNode(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "A node can operate in one or both of two roles: a target role and/or an initiator role. If the node will operate in both roles, both bits must be set. This object will also define the corresponding rows that will exist in the iscsiTargetAttributesTable, the iscsiInitiatorAttributesTable or both. If the targetTypeNode bit is set, there will be a corresponding iscsiTargetAttributesEntry. If the initiatorTypeNode bit is set, there will be a corresponding iscsiInitiatorAttributesEntry. If both bits are set, there will be a corresponding iscsiTgtPortalAttributesEntry and iscsiPortalAttributesEntry." ::= { iscsiNodeAttributesEntry 4 } iscsiNodeTransportType OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the corresponding row in the appropriate Bakke, et al. Standards Track [Page 32] RFC 4544 iSCSI MIB May 2006 table for this SCSI transport, thereby allowing management stations to locate the SCSI-level device that is represented by this iscsiNode. For example, it will usually point to the corresponding scsiTrnspt object in the SCSI MIB module. If no corresponding row exists, the value 0.0 must be used to indicate this." REFERENCE "SCSI-MIB" ::= { iscsiNodeAttributesEntry 5 } iscsiNodeInitialR2T OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the InitialR2T preference for this node: true = YES, false = will try to negotiate NO, will accept YES " REFERENCE "RFC 3720, Section 12.10, InitialR2T" ::= { iscsiNodeAttributesEntry 6 } iscsiNodeImmediateData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates ImmediateData preference for this node: true = YES (but will accept NO), false = NO " REFERENCE "RFC 3720, Section 12.11, ImmediateData" DEFVAL { true } ::= { iscsiNodeAttributesEntry 7 } iscsiNodeMaxOutstandingR2T OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "R2Ts" MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum number of outstanding requests-to-transmit (R2Ts) allowed per iSCSI task." REFERENCE "RFC 3720, Section 12.17, MaxOutstandingR2T" Bakke, et al. Standards Track [Page 33] RFC 4544 iSCSI MIB May 2006 DEFVAL { 1 } ::= { iscsiNodeAttributesEntry 8 } iscsiNodeFirstBurstLength OBJECT-TYPE SYNTAX Unsigned32 (512..16777215) UNITS "bytes" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum length (bytes) supported for unsolicited data to/from this node." REFERENCE "RFC 3720, Section 12.14, FirstBurstLength" DEFVAL { 65536 } ::= { iscsiNodeAttributesEntry 9 } iscsiNodeMaxBurstLength OBJECT-TYPE SYNTAX Unsigned32 (512..16777215) UNITS "bytes" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of bytes that can be sent within a single sequence of Data-In or Data-Out PDUs." REFERENCE "RFC 3720, Section 12.13, MaxBurstLength" DEFVAL { 262144 } ::= { iscsiNodeAttributesEntry 10 } iscsiNodeMaxConnections OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "connections" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of connections allowed in each session to and/or from this node." REFERENCE "RFC 3720, Section 12.2, MaxConnections" DEFVAL { 1 } ::= { iscsiNodeAttributesEntry 11 } iscsiNodeDataSequenceInOrder OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The DataSequenceInOrder preference of this node. Bakke, et al. Standards Track [Page 34] RFC 4544 iSCSI MIB May 2006 False (=No) indicates that iSCSI data PDU sequences may be transferred in any order. True (=Yes) indicates that data PDU sequences must be transferred using continuously increasing offsets, except during error recovery." REFERENCE "RFC 3720, Section 12.19, DataSequenceInOrder" DEFVAL { true } ::= { iscsiNodeAttributesEntry 12 } iscsiNodeDataPDUInOrder OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The DataPDUInOrder preference of this node. False (=No) indicates that iSCSI data PDUs within sequences may be in any order. True (=Yes) indicates that data PDUs within sequences must be at continuously increasing addresses, with no gaps or overlay between PDUs." REFERENCE "RFC 3720, Section 12.18, DataPDUInOrder" DEFVAL { true } ::= { iscsiNodeAttributesEntry 13 } iscsiNodeDefaultTime2Wait OBJECT-TYPE SYNTAX Unsigned32 (0..3600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The DefaultTime2Wait preference of this node. This is the minimum time, in seconds, to wait before attempting an explicit/implicit logout or active iSCSI task reassignment after an unexpected connection termination or a connection reset." REFERENCE "RFC 3720, Section 12.15, DefaultTime2Wait" DEFVAL { 2 } ::= { iscsiNodeAttributesEntry 14 } iscsiNodeDefaultTime2Retain OBJECT-TYPE SYNTAX Unsigned32 (0..3600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The DefaultTime2Retain preference of this node. This is Bakke, et al. Standards Track [Page 35] RFC 4544 iSCSI MIB May 2006 the maximum time, in seconds after an initial wait (Time2Wait), before which an active iSCSI task reassignment is still possible after an unexpected connection termination or a connection reset." REFERENCE "RFC 3720, Section 12.16, DefaultTime2Retain" DEFVAL { 20 } ::= { iscsiNodeAttributesEntry 15 } iscsiNodeErrorRecoveryLevel OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The ErrorRecoveryLevel preference of this node. Currently, only 0-2 are valid. This object is designed to accommodate future error recovery levels. Higher error recovery levels imply support in addition to support for the lower error level functions. In other words, error level 2 implies support for levels 0-1, since those functions are subsets of error level 2." REFERENCE "RFC 3720, Section 12.20, ErrorRecoveryLevel" DEFVAL { 0 } ::= { iscsiNodeAttributesEntry 16 } iscsiNodeDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime on the most recent occasion at which any one or more of this node's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { iscsiNodeAttributesEntry 17 } iscsiNodeStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION Bakke, et al. Standards Track [Page 36] RFC 4544 iSCSI MIB May 2006 "The storage type for all read-write objects within this row. Rows in this table are always created via an external process, and may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row. If this object has the value 'volatile', modifications to read-write objects in this row are not persistent across reboots. If this object has the value 'nonVolatile', modifications to objects in this row are persistent. An implementation may choose to allow this object to be set to either 'nonVolatile' or 'volatile', allowing the management application to choose this behavior." DEFVAL { volatile } ::= { iscsiNodeAttributesEntry 18 } --********************************************************************** iscsiTarget OBJECT IDENTIFIER ::= { iscsiObjects 6 } -- Target Attributes Table iscsiTargetAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiTargetAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of iSCSI nodes that can take on a target role, belonging to each iSCSI instance present on the local system." ::= { iscsiTarget 1 } iscsiTargetAttributesEntry OBJECT-TYPE SYNTAX IscsiTargetAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular node that can take on a target role." INDEX { iscsiInstIndex, iscsiNodeIndex } ::= { iscsiTargetAttributesTable 1 } IscsiTargetAttributesEntry ::= SEQUENCE { iscsiTgtLoginFailures Counter32, Bakke, et al. Standards Track [Page 37] RFC 4544 iSCSI MIB May 2006 iscsiTgtLastFailureTime TimeStamp, iscsiTgtLastFailureType AutonomousType, iscsiTgtLastIntrFailureName IscsiName, iscsiTgtLastIntrFailureAddrType InetAddressType, iscsiTgtLastIntrFailureAddr InetAddress } iscsiTgtLoginFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failed login attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of times a login attempt to this local target has failed. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiTargetAttributesEntry 1 } iscsiTgtLastFailureTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp of the most recent failure of a login attempt to this target. A value of zero indicates that no such failures have occurred since the last system boot." ::= { iscsiTargetAttributesEntry 2 } iscsiTgtLastFailureType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the most recent failure of a login attempt to this target, represented as the OID of the counter object in iscsiTargetLoginStatsTable for which the relevant instance was incremented. A value of 0.0 indicates a type that is not represented by any of the counters in iscsiTargetLoginStatsTable." ::= { iscsiTargetAttributesEntry 3 } iscsiTgtLastIntrFailureName OBJECT-TYPE SYNTAX IscsiName MAX-ACCESS read-only STATUS current Bakke, et al. Standards Track [Page 38] RFC 4544 iSCSI MIB May 2006 DESCRIPTION "The iSCSI name of the initiator that failed the last login attempt." ::= { iscsiTargetAttributesEntry 4 } iscsiTgtLastIntrFailureAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet Network Address contained in the corresponding instance of the iscsiTgtLastIntrFailureAddr. The value 'dns' is not allowed." ::= { iscsiTargetAttributesEntry 5 } iscsiTgtLastIntrFailureAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An Internet Network Address, of the type specified by the object iscsiTgtLastIntrFailureAddrType, giving the host address of the initiator that failed the last login attempt." ::= { iscsiTargetAttributesEntry 6 } -- Target Login Stats Table iscsiTargetLoginStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiTargetLoginStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of counters that keep a record of the results of initiators' login attempts to this target." ::= { iscsiTarget 2 } iscsiTargetLoginStatsEntry OBJECT-TYPE SYNTAX IscsiTargetLoginStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing counters for each result of a login attempt to this target." AUGMENTS { iscsiTargetAttributesEntry } ::= { iscsiTargetLoginStatsTable 1 } IscsiTargetLoginStatsEntry ::= SEQUENCE { Bakke, et al. Standards Track [Page 39] RFC 4544 iSCSI MIB May 2006 iscsiTgtLoginAccepts Counter32, iscsiTgtLoginOtherFails Counter32, iscsiTgtLoginRedirects Counter32, iscsiTgtLoginAuthorizeFails Counter32, iscsiTgtLoginAuthenticateFails Counter32, iscsiTgtLoginNegotiateFails Counter32 } iscsiTgtLoginAccepts OBJECT-TYPE SYNTAX Counter32 UNITS "successful logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs with status 0x0000, Accept Login, transmitted by this target. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiTargetLoginStatsEntry 1 } iscsiTgtLoginOtherFails OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Login Response PDUs that were transmitted by this target and that were not counted by any other object in the row. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiTargetLoginStatsEntry 2 } iscsiTgtLoginRedirects OBJECT-TYPE SYNTAX Counter32 UNITS "redirected logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs with status class 0x01, Redirection, transmitted by this target. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." Bakke, et al. Standards Track [Page 40] RFC 4544 iSCSI MIB May 2006 REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiTargetLoginStatsEntry 3 } iscsiTgtLoginAuthorizeFails OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs with status 0x0202, Forbidden Target, transmitted by this target. If this counter is incremented, an iscsiTgtLoginFailure notification should be generated. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiTargetLoginStatsEntry 4 } iscsiTgtLoginAuthenticateFails OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs with status 0x0201, Authentication Failed, transmitted by this target. If this counter is incremented, an iscsiTgtLoginFailure notification should be generated. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiTargetLoginStatsEntry 5 } iscsiTgtLoginNegotiateFails OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a target has effectively refused a login because the parameter negotiation failed. Bakke, et al. Standards Track [Page 41] RFC 4544 iSCSI MIB May 2006 If this counter is incremented, an iscsiTgtLoginFailure notification should be generated. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." ::= { iscsiTargetLoginStatsEntry 6 } -- Target Logout Stats Table iscsiTargetLogoutStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiTargetLogoutStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "When a target receives a Logout command, it responds with a Logout Response that carries a status code. This table contains counters for both normal and abnormal logout requests received by this target." ::= { iscsiTarget 3 } iscsiTargetLogoutStatsEntry OBJECT-TYPE SYNTAX IscsiTargetLogoutStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing counters of Logout Response PDUs that were received by this target." AUGMENTS { iscsiTargetAttributesEntry } ::= { iscsiTargetLogoutStatsTable 1 } IscsiTargetLogoutStatsEntry ::= SEQUENCE { iscsiTgtLogoutNormals Counter32, iscsiTgtLogoutOthers Counter32 } iscsiTgtLogoutNormals OBJECT-TYPE SYNTAX Counter32 UNITS "normal logouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Logout Command PDUs received by this target, with reason code 0 (closes the session). If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.14.1, Reason Code" ::= { iscsiTargetLogoutStatsEntry 1 } Bakke, et al. Standards Track [Page 42] RFC 4544 iSCSI MIB May 2006 iscsiTgtLogoutOthers OBJECT-TYPE SYNTAX Counter32 UNITS "abnormal logouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Logout Command PDUs received by this target, with any reason code other than 0. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.14.1, Reason Code" ::= { iscsiTargetLogoutStatsEntry 2 } --********************************************************************** iscsiTgtAuthorization OBJECT IDENTIFIER ::= { iscsiObjects 7 } -- Target Authorization Attributes Table iscsiTgtAuthAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiTgtAuthAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of initiator identities that are authorized to access each target node within each iSCSI instance present on the local system." ::= { iscsiTgtAuthorization 1 } iscsiTgtAuthAttributesEntry OBJECT-TYPE SYNTAX IscsiTgtAuthAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular target node's authorized initiator identity." INDEX { iscsiInstIndex, iscsiNodeIndex, iscsiTgtAuthIndex } ::= { iscsiTgtAuthAttributesTable 1 } IscsiTgtAuthAttributesEntry ::= SEQUENCE { iscsiTgtAuthIndex Unsigned32, iscsiTgtAuthRowStatus RowStatus, iscsiTgtAuthIdentity RowPointer, iscsiTgtAuthStorageType StorageType } Bakke, et al. Standards Track [Page 43] RFC 4544 iSCSI MIB May 2006 iscsiTgtAuthIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular target's authorized initiator identity within an iSCSI instance present on the local system. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { iscsiTgtAuthAttributesEntry 1 } iscsiTgtAuthRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. When the value of this object is 'active', the values of the other objects in this table cannot be changed. Rows may be discarded using RowStatus." ::= { iscsiTgtAuthAttributesEntry 2 } iscsiTgtAuthIdentity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to the corresponding user entry in the IPS-AUTH MIB module that will be allowed to access this iSCSI target." REFERENCE "IPS-AUTH MIB, RFC 4545" ::= { iscsiTgtAuthAttributesEntry 3 } iscsiTgtAuthStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." Bakke, et al. Standards Track [Page 44] RFC 4544 iSCSI MIB May 2006 DEFVAL { nonVolatile } ::= { iscsiTgtAuthAttributesEntry 4 } --********************************************************************** iscsiInitiator OBJECT IDENTIFIER ::= { iscsiObjects 8 } -- Initiator Attributes Table iscsiInitiatorAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiInitiatorAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of iSCSI nodes that can take on an initiator role, belonging to each iSCSI instance present on the local system." ::= { iscsiInitiator 1 } iscsiInitiatorAttributesEntry OBJECT-TYPE SYNTAX IscsiInitiatorAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular iSCSI node that has initiator capabilities." INDEX { iscsiInstIndex, iscsiNodeIndex } ::= { iscsiInitiatorAttributesTable 1 } IscsiInitiatorAttributesEntry ::= SEQUENCE { iscsiIntrLoginFailures Counter32, iscsiIntrLastFailureTime TimeStamp, iscsiIntrLastFailureType AutonomousType, iscsiIntrLastTgtFailureName IscsiName, iscsiIntrLastTgtFailureAddrType InetAddressType, iscsiIntrLastTgtFailureAddr InetAddress } iscsiIntrLoginFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of times a login attempt from this local initiator has failed. If this counter has suffered a discontinuity, the time of the Bakke, et al. Standards Track [Page 45] RFC 4544 iSCSI MIB May 2006 last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiInitiatorAttributesEntry 1 } iscsiIntrLastFailureTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp of the most recent failure of a login attempt from this initiator. A value of zero indicates that no such failures have occurred since the last system boot." ::= { iscsiInitiatorAttributesEntry 2 } iscsiIntrLastFailureType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the most recent failure of a login attempt from this initiator, represented as the OID of the counter object in iscsiInitiatorLoginStatsTable for which the relevant instance was incremented. A value of 0.0 indicates a type that is not represented by any of the counters in iscsiInitiatorLoginStatsTable." ::= { iscsiInitiatorAttributesEntry 3 } iscsiIntrLastTgtFailureName OBJECT-TYPE SYNTAX IscsiName MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string giving the name of the target that failed the last login attempt." ::= { iscsiInitiatorAttributesEntry 4 } iscsiIntrLastTgtFailureAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet Network Address contained in the corresponding instance of the iscsiIntrLastTgtFailureAddr. The value 'dns' is not allowed." ::= { iscsiInitiatorAttributesEntry 5 } iscsiIntrLastTgtFailureAddr OBJECT-TYPE Bakke, et al. Standards Track [Page 46] RFC 4544 iSCSI MIB May 2006 SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An Internet Network Address, of the type specified by the object iscsiIntrLastTgtFailureAddrType, giving the host address of the target that failed the last login attempt." ::= { iscsiInitiatorAttributesEntry 6 } -- Initiator Login Stats Table iscsiInitiatorLoginStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiInitiatorLoginStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of counters which keep track of the results of this initiator's login attempts." ::= { iscsiInitiator 2 } iscsiInitiatorLoginStatsEntry OBJECT-TYPE SYNTAX IscsiInitiatorLoginStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing counters of each result of this initiator's login attempts." AUGMENTS { iscsiInitiatorAttributesEntry } ::= { iscsiInitiatorLoginStatsTable 1 } IscsiInitiatorLoginStatsEntry ::= SEQUENCE { iscsiIntrLoginAcceptRsps Counter32, iscsiIntrLoginOtherFailRsps Counter32, iscsiIntrLoginRedirectRsps Counter32, iscsiIntrLoginAuthFailRsps Counter32, iscsiIntrLoginAuthenticateFails Counter32, iscsiIntrLoginNegotiateFails Counter32 } iscsiIntrLoginAcceptRsps OBJECT-TYPE SYNTAX Counter32 UNITS "successful logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs with status 0x0000, Accept Login, received by this initiator. If this counter has suffered a discontinuity, the time of the Bakke, et al. Standards Track [Page 47] RFC 4544 iSCSI MIB May 2006 last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiInitiatorLoginStatsEntry 1 } iscsiIntrLoginOtherFailRsps OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs received by this initiator with any status code not counted in the objects below. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiInitiatorLoginStatsEntry 2 } iscsiIntrLoginRedirectRsps OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs with status class 0x01, Redirection, received by this initiator. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiInitiatorLoginStatsEntry 3 } iscsiIntrLoginAuthFailRsps OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Login Response PDUs with status class 0x201, Authentication Failed, received by this initiator. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiInitiatorLoginStatsEntry 4 } Bakke, et al. Standards Track [Page 48] RFC 4544 iSCSI MIB May 2006 iscsiIntrLoginAuthenticateFails OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the initiator has aborted a login because the target could not be authenticated. No response is generated. If this counter is incremented, an iscsiIntrLoginFailure notification should be generated. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.13.5, Status-Class and Status-Detail" ::= { iscsiInitiatorLoginStatsEntry 5 } iscsiIntrLoginNegotiateFails OBJECT-TYPE SYNTAX Counter32 UNITS "failed logins" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the initiator has aborted a login because parameter negotiation with the target failed. No response is generated. If this counter is incremented, an iscsiIntrLoginFailure notification should be generated. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 6.10, Negotiation Failures" ::= { iscsiInitiatorLoginStatsEntry 6 } -- Initiator Logout Stats Table iscsiInitiatorLogoutStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiInitiatorLogoutStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "When an initiator attempts to send a Logout command, the target responds with a Logout Response that carries a status code. Bakke, et al. Standards Track [Page 49] RFC 4544 iSCSI MIB May 2006 This table contains a list of counters of Logout Response PDUs of each status code that was received by each initiator belonging to this iSCSI instance present on this system." ::= { iscsiInitiator 3 } iscsiInitiatorLogoutStatsEntry OBJECT-TYPE SYNTAX IscsiInitiatorLogoutStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing counters of Logout Response PDUs of each status code that was generated by this initiator." AUGMENTS { iscsiInitiatorAttributesEntry } ::= { iscsiInitiatorLogoutStatsTable 1 } IscsiInitiatorLogoutStatsEntry ::= SEQUENCE { iscsiIntrLogoutNormals Counter32, iscsiIntrLogoutOthers Counter32 } iscsiIntrLogoutNormals OBJECT-TYPE SYNTAX Counter32 UNITS "normal logouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Logout Command PDUs generated by this initiator with reason code 0 (closes the session). If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.14.1, Reason Code" ::= { iscsiInitiatorLogoutStatsEntry 1 } iscsiIntrLogoutOthers OBJECT-TYPE SYNTAX Counter32 UNITS "abnormal logouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Logout Command PDUs generated by this initiator with any status code other than 0. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiNodeDiscontinuityTime." REFERENCE "RFC 3720, Section 10.14.1, Reason Code" Bakke, et al. Standards Track [Page 50] RFC 4544 iSCSI MIB May 2006 ::= { iscsiInitiatorLogoutStatsEntry 2 } --********************************************************************** iscsiIntrAuthorization OBJECT IDENTIFIER ::= { iscsiObjects 9 } -- Initiator Authorization Attributes Table iscsiIntrAuthAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiIntrAuthAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of target identities that each initiator on the local system may access." ::= { iscsiIntrAuthorization 1 } iscsiIntrAuthAttributesEntry OBJECT-TYPE SYNTAX IscsiIntrAuthAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular initiator node's authorized target identity." INDEX { iscsiInstIndex, iscsiNodeIndex, iscsiIntrAuthIndex } ::= { iscsiIntrAuthAttributesTable 1 } IscsiIntrAuthAttributesEntry ::= SEQUENCE { iscsiIntrAuthIndex Unsigned32, iscsiIntrAuthRowStatus RowStatus, iscsiIntrAuthIdentity RowPointer, iscsiIntrAuthStorageType StorageType } iscsiIntrAuthIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular initiator node's authorized target identity within an iSCSI instance present on the local system. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { iscsiIntrAuthAttributesEntry 1 } Bakke, et al. Standards Track [Page 51] RFC 4544 iSCSI MIB May 2006 iscsiIntrAuthRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. When the value of this object is 'active', the values of the other objects in this table cannot be changed. Rows may be discarded using RowStatus." ::= { iscsiIntrAuthAttributesEntry 2 } iscsiIntrAuthIdentity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to the corresponding user entry in the IPS-AUTH MIB module to which this initiator node should attempt to establish an iSCSI session." REFERENCE "IPS-AUTH MIB, RFC 4545" ::= { iscsiIntrAuthAttributesEntry 3 } iscsiIntrAuthStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { iscsiIntrAuthAttributesEntry 4 } --********************************************************************** iscsiSession OBJECT IDENTIFIER ::= { iscsiObjects 10 } -- Session Attributes Table iscsiSessionAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiSessionAttributesEntry MAX-ACCESS not-accessible Bakke, et al. Standards Track [Page 52] RFC 4544 iSCSI MIB May 2006 STATUS current DESCRIPTION "A list of sessions belonging to each iSCSI instance present on the system." ::= { iscsiSession 1 } iscsiSessionAttributesEntry OBJECT-TYPE SYNTAX IscsiSessionAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular session. If this session is a discovery session that is not attached to any particular node, the iscsiSsnNodeIndex will be zero. Otherwise, the iscsiSsnNodeIndex will have the same value as iscsiNodeIndex." INDEX { iscsiInstIndex, iscsiSsnNodeIndex, iscsiSsnIndex } ::= { iscsiSessionAttributesTable 1 } IscsiSessionAttributesEntry ::= SEQUENCE { iscsiSsnNodeIndex Unsigned32, iscsiSsnIndex Unsigned32, iscsiSsnDirection INTEGER, iscsiSsnInitiatorName IscsiName, iscsiSsnTargetName IscsiName, iscsiSsnTSIH Unsigned32, iscsiSsnISID OCTET STRING, iscsiSsnInitiatorAlias SnmpAdminString, iscsiSsnTargetAlias SnmpAdminString, iscsiSsnInitialR2T TruthValue, iscsiSsnImmediateData TruthValue, iscsiSsnType INTEGER, iscsiSsnMaxOutstandingR2T Unsigned32, iscsiSsnFirstBurstLength Unsigned32, iscsiSsnMaxBurstLength Unsigned32, iscsiSsnConnectionNumber Gauge32, iscsiSsnAuthIdentity RowPointer, iscsiSsnDataSequenceInOrder TruthValue, iscsiSsnDataPDUInOrder TruthValue, iscsiSsnErrorRecoveryLevel Unsigned32, iscsiSsnDiscontinuityTime TimeStamp } iscsiSsnNodeIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible Bakke, et al. Standards Track [Page 53] RFC 4544 iSCSI MIB May 2006 STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular node within an iSCSI instance present on the local system. For normal, non-discovery sessions, this value will map to the iscsiNodeIndex. For discovery sessions that do not have a node associated, the value 0 (zero) is used." ::= { iscsiSessionAttributesEntry 1 } iscsiSsnIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular session within an iSCSI instance present on the local system. An agent should attempt to not reuse index values unless a reboot has occurred. iSCSI sessions are destroyed during a reboot; rows in this table are not persistent across reboots." ::= { iscsiSessionAttributesEntry 2 } iscsiSsnDirection OBJECT-TYPE SYNTAX INTEGER { inboundSession(1), outboundSession(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Direction of iSCSI session: inboundSession - session is established from an external initiator to a target within this iSCSI instance. outboundSession - session is established from an initiator within this iSCSI instance to an external target." ::= { iscsiSessionAttributesEntry 3 } iscsiSsnInitiatorName OBJECT-TYPE SYNTAX IscsiName MAX-ACCESS read-only STATUS current DESCRIPTION "If iscsiSsnDirection is Inbound, this object is a UTF-8 string that will contain the name of the remote initiator. If this session is a discovery session that Bakke, et al. Standards Track [Page 54] RFC 4544 iSCSI MIB May 2006 does not specify a particular initiator, this object will contain a zero-length string. If iscsiSsnDirection is Outbound, this object will contain a zero-length string." ::= { iscsiSessionAttributesEntry 4 } iscsiSsnTargetName OBJECT-TYPE SYNTAX IscsiName MAX-ACCESS read-only STATUS current DESCRIPTION "If iscsiSsnDirection is Outbound, this object is a UTF-8 string that will contain the name of the remote target. If this session is a discovery session that does not specify a particular target, this object will contain a zero-length string. If iscsiSsnDirection is Inbound, this object will contain a zero-length string." ::= { iscsiSessionAttributesEntry 5 } iscsiSsnTSIH OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The target-defined identification handle for this session." REFERENCE "RFC 3720, Section 10.12.6, TSIH" ::= { iscsiSessionAttributesEntry 6 } iscsiSsnISID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(6)) MAX-ACCESS read-only STATUS current DESCRIPTION "The initiator-defined portion of the iSCSI Session ID." REFERENCE "RFC 3720, Section 10.12.5, ISID" ::= { iscsiSessionAttributesEntry 7 } iscsiSsnInitiatorAlias OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string that gives the alias communicated by the Bakke, et al. Standards Track [Page 55] RFC 4544 iSCSI MIB May 2006 initiator end of the session during the login phase. If no alias exists, the value is a zero-length string." REFERENCE "RFC 3720, Section 12.7, InitiatorAlias" ::= { iscsiSessionAttributesEntry 8 } iscsiSsnTargetAlias OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string that gives the alias communicated by the target end of the session during the login phase. If no alias exists, the value is a zero-length string." REFERENCE "RFC 3720, Section 12.6, TargetAlias" ::= { iscsiSessionAttributesEntry 9 } iscsiSsnInitialR2T OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If set to true, indicates that the initiator must wait for an R2T before sending to the target. If set to false, the initiator may send data immediately, within limits set by iscsiSsnFirstBurstLength and the expected data transfer length of the request." REFERENCE "RFC 3720, Section 12.10, InitialR2T" ::= { iscsiSessionAttributesEntry 10 } iscsiSsnImmediateData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the initiator and target have agreed to support immediate data on this session." REFERENCE "RFC 3720, Section 12.11, ImmediateData" ::= { iscsiSessionAttributesEntry 11 } iscsiSsnType OBJECT-TYPE SYNTAX INTEGER { normalSession(1), Bakke, et al. Standards Track [Page 56] RFC 4544 iSCSI MIB May 2006 discoverySession(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Type of iSCSI session: normalSession - session is a normal iSCSI session discoverySession - session is being used only for discovery." REFERENCE "RFC 3720, Section 12.21, SessionType" ::= { iscsiSessionAttributesEntry 12 } iscsiSsnMaxOutstandingR2T OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "R2Ts" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of outstanding requests-to-transmit (R2Ts) per iSCSI task within this session." REFERENCE "RFC 3720, Section 12.17, MaxOutstandingR2T" ::= { iscsiSessionAttributesEntry 13 } iscsiSsnFirstBurstLength OBJECT-TYPE SYNTAX Unsigned32 (512..16777215) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum length supported for unsolicited data sent within this session." REFERENCE "RFC 3720, Section 12.14, FirstBurstLength" ::= { iscsiSessionAttributesEntry 14 } iscsiSsnMaxBurstLength OBJECT-TYPE SYNTAX Unsigned32 (512..16777215) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of bytes that can be sent within a single sequence of Data-In or Data-Out PDUs." REFERENCE "RFC 3720, Section 12.13, MaxBurstLength" ::= { iscsiSessionAttributesEntry 15 } Bakke, et al. Standards Track [Page 57] RFC 4544 iSCSI MIB May 2006 iscsiSsnConnectionNumber OBJECT-TYPE SYNTAX Gauge32 (1..65535) UNITS "connections" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transport protocol connections that currently belong to this session." ::= { iscsiSessionAttributesEntry 16 } iscsiSsnAuthIdentity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a pointer to a row in the IPS-AUTH MIB module that identifies the authentication method being used on this session, as communicated during the login phase." REFERENCE "IPS-AUTH MIB, RFC 4545" ::= { iscsiSessionAttributesEntry 17 } iscsiSsnDataSequenceInOrder OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "False indicates that iSCSI data PDU sequences may be transferred in any order. True indicates that data PDU sequences must be transferred using continuously increasing offsets, except during error recovery." REFERENCE "RFC 3720, Section 12.19, DataSequenceInOrder" ::= { iscsiSessionAttributesEntry 18 } iscsiSsnDataPDUInOrder OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "False indicates that iSCSI data PDUs within sequences may be in any order. True indicates that data PDUs within sequences must be at continuously increasing addresses, with no gaps or overlay between PDUs. Default is true." Bakke, et al. Standards Track [Page 58] RFC 4544 iSCSI MIB May 2006 REFERENCE "RFC 3720, Section 12.18, DataPDUInOrder" ::= { iscsiSessionAttributesEntry 19 } iscsiSsnErrorRecoveryLevel OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of error recovery negotiated between the initiator and the target. Higher numbers represent more detailed recovery schemes." REFERENCE "RFC 3720, Section 12.20, ErrorRecoveryLevel" ::= { iscsiSessionAttributesEntry 20 } iscsiSsnDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime on the most recent occasion at which any one or more of this session's counters suffered a discontinuity. When a session is established, and this object is created, it is initialized to the current value of SysUpTime." ::= { iscsiSessionAttributesEntry 21 } -- Session Stats Table iscsiSessionStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of general iSCSI traffic counters for each of the sessions present on the system." ::= { iscsiSession 2 } iscsiSessionStatsEntry OBJECT-TYPE SYNTAX IscsiSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing general iSCSI traffic counters for a particular session." AUGMENTS { iscsiSessionAttributesEntry } Bakke, et al. Standards Track [Page 59] RFC 4544 iSCSI MIB May 2006 ::= { iscsiSessionStatsTable 1 } IscsiSessionStatsEntry ::= SEQUENCE { iscsiSsnCmdPDUs Counter32, iscsiSsnRspPDUs Counter32, iscsiSsnTxDataOctets Counter64, iscsiSsnRxDataOctets Counter64, iscsiSsnLCTxDataOctets Counter32, iscsiSsnLCRxDataOctets Counter32 } iscsiSsnCmdPDUs OBJECT-TYPE SYNTAX Counter32 UNITS "PDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Command PDUs transferred on this session. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." ::= { iscsiSessionStatsEntry 1 } iscsiSsnRspPDUs OBJECT-TYPE SYNTAX Counter32 UNITS "PDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of Response PDUs transferred on this session. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." ::= { iscsiSessionStatsEntry 2 } iscsiSsnTxDataOctets OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of data octets that were transmitted by the local iSCSI node on this session. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." ::= { iscsiSessionStatsEntry 3 } iscsiSsnRxDataOctets OBJECT-TYPE SYNTAX Counter64 UNITS "octets" Bakke, et al. Standards Track [Page 60] RFC 4544 iSCSI MIB May 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of data octets that were received by the local iSCSI node on this session. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." ::= { iscsiSessionStatsEntry 4 } iscsiSsnLCTxDataOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "A Low Capacity shadow object of iscsiSsnTxDataOctets for those systems that don't support Counter64. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." ::= { iscsiSessionStatsEntry 5 } iscsiSsnLCRxDataOctets OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "A Low Capacity shadow object of iscsiSsnRxDataOctets for those systems that don't support Counter64. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." ::= { iscsiSessionStatsEntry 6 } -- Session Connection Error Stats Table iscsiSessionCxnErrorStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiSessionCxnErrorStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of error counters for each of the sessions present on this system." ::= { iscsiSession 3 } iscsiSessionCxnErrorStatsEntry OBJECT-TYPE SYNTAX IscsiSessionCxnErrorStatsEntry MAX-ACCESS not-accessible STATUS current Bakke, et al. Standards Track [Page 61] RFC 4544 iSCSI MIB May 2006 DESCRIPTION "An entry (row) containing error counters for a particular session." AUGMENTS { iscsiSessionAttributesEntry } ::= { iscsiSessionCxnErrorStatsTable 1 } IscsiSessionCxnErrorStatsEntry ::= SEQUENCE { iscsiSsnCxnDigestErrors Counter32, iscsiSsnCxnTimeoutErrors Counter32 } iscsiSsnCxnDigestErrors OBJECT-TYPE SYNTAX Counter32 UNITS "PDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of PDUs that were received on the session and contained header or data digest errors. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." REFERENCE "RFC 3720, Section 6.7, Digest Errors" ::= { iscsiSessionCxnErrorStatsEntry 1 } iscsiSsnCxnTimeoutErrors OBJECT-TYPE SYNTAX Counter32 UNITS "connections" MAX-ACCESS read-only STATUS current DESCRIPTION "The count of connections within this session that have been terminated due to timeout. If this counter has suffered a discontinuity, the time of the last discontinuity is indicated in iscsiSsnDiscontinuityTime." REFERENCE "RFC 3720, Section 6.4, Connection Timeout Management" ::= { iscsiSessionCxnErrorStatsEntry 2 } --********************************************************************** iscsiConnection OBJECT IDENTIFIER ::= { iscsiObjects 11 } -- Connection Attributes Table iscsiConnectionAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IscsiConnectionAttributesEntry MAX-ACCESS not-accessible Bakke, et al. Standards Track [Page 62] RFC 4544 iSCSI MIB May 2006 STATUS current DESCRIPTION "A list of connections belonging to each iSCSI instance present on the system." ::= { iscsiConnection 1 } iscsiConnectionAttributesEntry OBJECT-TYPE SYNTAX IscsiConnectionAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular connection." INDEX { iscsiInstIndex, iscsiSsnNodeIndex, iscsiSsnIndex, iscsiCxnIndex } ::= { iscsiConnectionAttributesTable 1 } IscsiConnectionAttributesEntry ::= SEQUENCE { iscsiCxnIndex Unsigned32, iscsiCxnCid Unsigned32, iscsiCxnState INTEGER, iscsiCxnAddrType InetAddressType, iscsiCxnLocalAddr InetAddress, iscsiCxnProtocol IscsiTransportProtocol, iscsiCxnLocalPort InetPortNumber, iscsiCxnRemoteAddr InetAddress, iscsiCxnRemotePort InetPortNumber, iscsiCxnMaxRecvDataSegLength Unsigned32, iscsiCxnMaxXmitDataSegLength Unsigned32, iscsiCxnHeaderIntegrity IscsiDigestMethod, iscsiCxnDataIntegrity IscsiDigestMethod, iscsiCxnRecvMarker TruthValue, iscsiCxnSendMarker TruthValue, iscsiCxnVersionActive Unsigned32 } iscsiCxnIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular connection of a particular session within an iSCSI instance present on the local system. An agent should attempt to not reuse index values unless a reboot has occurred. iSCSI connections are destroyed during a reboot; rows in this table are not persistent across reboots." Bakke, et al. Standards Track [Page 63] RFC 4544 iSCSI MIB May 2006 ::= { iscsiConnectionAttributesEntry 1 } iscsiCxnCid OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The iSCSI Connection ID for this connection." ::= { iscsiConnectionAttributesEntry 2 } iscsiCxnState OBJECT-TYPE SYNTAX INTEGER { login(1), full(2), logout(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of this connection, from an iSCSI negotiation point of view. Here are the states: login - The transport protocol connection has been established, but a valid iSCSI login response with the final bit set has not been sent or received. full - A valid iSCSI login response with the final bit set has been sent or received. logout - A valid iSCSI logout command has been sent or received, but the transport protocol connection has not yet been closed." ::= { iscsiConnectionAttributesEntry 3 } iscsiCxnAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet Network Addresses contained in the corresponding instances of iscsiCxnLocalAddr and iscsiCxnRemoteAddr. The value 'dns' is not allowed." ::= { iscsiConnectionAttributesEntry 4 } iscsiCxnLocalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION Bakke, et al. Standards Track [Page 64] RFC 4544 iSCSI MIB May 2006 "The local Internet Network Address, of the type specified by iscsiCxnAddrType, used by this connection." ::= { iscsiConnectionAttributesEntry 5 } iscsiCxnProtocol OBJECT-TYPE SYNTAX IscsiTransportProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol over which this connection is running." ::= { iscsiConnectionAttributesEntry 6 } iscsiCxnLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The local transport protocol port used by this connection. This object cannot have the value zero, since it represents an established connection." ::= { iscsiConnectionAttributesEntry 7 } iscsiCxnRemoteAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The remote Internet Network Address, of the type specified by iscsiCxnAddrType, used by this connection." ::= { iscsiConnectionAttributesEntry 8 } iscsiCxnRemotePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The remote transport protocol port used by this connection. This object cannot have the value zero, since it represents an established connection." ::= { iscsiConnectionAttributesEntry 9 } iscsiCxnMaxRecvDataSegLength OBJECT-TYPE SYNTAX Unsigned32 (512..16777215) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION Bakke, et al. Standards Track [Page 65] RFC 4544 iSCSI MIB May 2006 "The maximum data payload size supported for command or data PDUs able to be received on this connection." REFERENCE "RFC 3720, Section 12.12, MaxRecvDataSegmentLength" ::= { iscsiConnectionAttributesEntry 10 } iscsiCxnMaxXmitDataSegLength OBJECT-TYPE SYNTAX Unsigned32 (512..16777215) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum data payload size supported for command or data PDUs to be sent on this connection." REFERENCE "RFC 3720, Section 12.12, MaxRecvDataSegmentLength" ::= { iscsiConnectionAttributesEntry 11 } iscsiCxnHeaderIntegrity OBJECT-TYPE SYNTAX IscsiDigestMethod MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the iSCSI header digest scheme in use within this connection." ::= { iscsiConnectionAttributesEntry 12 } iscsiCxnDataIntegrity OBJECT-TYPE SYNTAX IscsiDigestMethod MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the iSCSI data digest scheme in use within this connection." ::= { iscsiConnectionAttributesEntry 13 } iscsiCxnRecvMarker OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not this connection is receiving markers in its incoming data stream." REFERENCE "RFC 3720, Appendix A." ::= { iscsiConnectionAttributesEntry 14 } iscsiCxnSendMarker OBJECT-TYPE Bakke, et al. Standards Track [Page 66] RFC 4544 iSCSI MIB May 2006 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not this connection is inserting markers in its outgoing data stream." REFERENCE "RFC 3720, Appendix A." ::= { iscsiConnectionAttributesEntry 15 } iscsiCxnVersionActive OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Active version number of the iSCSI specification negotiated on this connection." REFERENCE "RFC 3720, Section 10.12, Login Request" ::= { iscsiConnectionAttributesEntry 16 } --********************************************************************** -- Notifications iscsiTgtLoginFailure NOTIFICATION-TYPE OBJECTS { iscsiTgtLoginFailures, iscsiTgtLastFailureType, iscsiTgtLastIntrFailureName, iscsiTgtLastIntrFailureAddrType, iscsiTgtLastIntrFailureAddr } STATUS current DESCRIPTION "Sent when a login is failed by a target. To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing this notification SHOULD NOT send more than 3 notifications of this type in any 10-second time period." ::= { iscsiNotifications 1 } iscsiIntrLoginFailure NOTIFICATION-TYPE OBJECTS { iscsiIntrLoginFailures, iscsiIntrLastFailureType, iscsiIntrLastTgtFailureName, iscsiIntrLastTgtFailureAddrType, Bakke, et al. Standards Track [Page 67] RFC 4544 iSCSI MIB May 2006 iscsiIntrLastTgtFailureAddr } STATUS current DESCRIPTION "Sent when a login is failed by an initiator. To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing this notification SHOULD NOT send more than 3 notifications of this type in any 10-second time period." ::= { iscsiNotifications 2 } iscsiInstSessionFailure NOTIFICATION-TYPE OBJECTS { iscsiInstSsnFailures, iscsiInstLastSsnFailureType, iscsiInstLastSsnRmtNodeName } STATUS current DESCRIPTION "Sent when an active session is failed by either the initiator or the target. To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing this notification SHOULD NOT send more than 3 notifications of this type in any 10-second time period." ::= { iscsiNotifications 3 } --********************************************************************** -- Conformance Statements iscsiCompliances OBJECT IDENTIFIER ::= { iscsiConformance 1 } iscsiGroups OBJECT IDENTIFIER ::= { iscsiConformance 2 } iscsiInstanceAttributesGroup OBJECT-GROUP OBJECTS { iscsiInstDescr, iscsiInstVersionMin, iscsiInstVersionMax, iscsiInstVendorID, iscsiInstVendorVersion, iscsiInstPortalNumber, iscsiInstNodeNumber, iscsiInstSessionNumber, iscsiInstSsnFailures, iscsiInstLastSsnFailureType, Bakke, et al. Standards Track [Page 68] RFC 4544 iSCSI MIB May 2006 iscsiInstLastSsnRmtNodeName, iscsiInstDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects providing information about iSCSI instances." ::= { iscsiGroups 1 } iscsiInstanceSsnErrorStatsGroup OBJECT-GROUP OBJECTS { iscsiInstSsnDigestErrors, iscsiInstSsnCxnTimeoutErrors, iscsiInstSsnFormatErrors } STATUS current DESCRIPTION "A collection of objects providing information about errors that have caused a session failure for an iSCSI instance." ::= { iscsiGroups 2 } iscsiPortalAttributesGroup OBJECT-GROUP OBJECTS { iscsiPortalRowStatus, iscsiPortalStorageType, iscsiPortalRoles, iscsiPortalAddrType, iscsiPortalAddr, iscsiPortalProtocol, iscsiPortalMaxRecvDataSegLength, iscsiPortalPrimaryHdrDigest, iscsiPortalPrimaryDataDigest, iscsiPortalSecondaryHdrDigest, iscsiPortalSecondaryDataDigest, iscsiPortalRecvMarker } STATUS current DESCRIPTION "A collection of objects providing information about the transport protocol endpoints of the local targets." ::= { iscsiGroups 3 } iscsiTgtPortalAttributesGroup OBJECT-GROUP OBJECTS { iscsiTgtPortalPort, iscsiTgtPortalTag } Bakke, et al. Standards Track [Page 69] RFC 4544 iSCSI MIB May 2006 STATUS current DESCRIPTION "A collection of objects providing information about the transport protocol endpoints of the local targets." ::= { iscsiGroups 4 } iscsiIntrPortalAttributesGroup OBJECT-GROUP OBJECTS { iscsiIntrPortalTag } STATUS current DESCRIPTION "An object providing information about the portal tags used by the local initiators." ::= { iscsiGroups 5 } iscsiNodeAttributesGroup OBJECT-GROUP OBJECTS { iscsiNodeName, iscsiNodeAlias, iscsiNodeRoles, iscsiNodeTransportType, iscsiNodeInitialR2T, iscsiNodeImmediateData, iscsiNodeMaxOutstandingR2T, iscsiNodeFirstBurstLength, iscsiNodeMaxBurstLength, iscsiNodeMaxConnections, iscsiNodeDataSequenceInOrder, iscsiNodeDataPDUInOrder, iscsiNodeDefaultTime2Wait, iscsiNodeDefaultTime2Retain, iscsiNodeErrorRecoveryLevel, iscsiNodeDiscontinuityTime, iscsiNodeStorageType } STATUS current DESCRIPTION "A collection of objects providing information about all local targets." ::= { iscsiGroups 6 } iscsiTargetAttributesGroup OBJECT-GROUP OBJECTS { iscsiTgtLoginFailures, iscsiTgtLastFailureTime, iscsiTgtLastFailureType, iscsiTgtLastIntrFailureName, Bakke, et al. Standards Track [Page 70] RFC 4544 iSCSI MIB May 2006 iscsiTgtLastIntrFailureAddrType, iscsiTgtLastIntrFailureAddr } STATUS current DESCRIPTION "A collection of objects providing information about all local targets." ::= { iscsiGroups 7 } iscsiTargetLoginStatsGroup OBJECT-GROUP OBJECTS { iscsiTgtLoginAccepts, iscsiTgtLoginOtherFails, iscsiTgtLoginRedirects, iscsiTgtLoginAuthorizeFails, iscsiTgtLoginAuthenticateFails, iscsiTgtLoginNegotiateFails } STATUS current DESCRIPTION "A collection of objects providing information about all login attempts by remote initiators to local targets." ::= { iscsiGroups 8 } iscsiTargetLogoutStatsGroup OBJECT-GROUP OBJECTS { iscsiTgtLogoutNormals, iscsiTgtLogoutOthers } STATUS current DESCRIPTION "A collection of objects providing information about all logout events between remote initiators and local targets." ::= { iscsiGroups 9 } iscsiTargetAuthGroup OBJECT-GROUP OBJECTS { iscsiTgtAuthRowStatus, iscsiTgtAuthStorageType, iscsiTgtAuthIdentity } STATUS current DESCRIPTION "A collection of objects providing information about all remote initiators that are authorized to connect to local targets." ::= { iscsiGroups 10 } Bakke, et al. Standards Track [Page 71] RFC 4544 iSCSI MIB May 2006 iscsiInitiatorAttributesGroup OBJECT-GROUP OBJECTS { iscsiIntrLoginFailures, iscsiIntrLastFailureTime, iscsiIntrLastFailureType, iscsiIntrLastTgtFailureName, iscsiIntrLastTgtFailureAddrType, iscsiIntrLastTgtFailureAddr } STATUS current DESCRIPTION "A collection of objects providing information about all local initiators." ::= { iscsiGroups 11 } iscsiInitiatorLoginStatsGroup OBJECT-GROUP OBJECTS { iscsiIntrLoginAcceptRsps, iscsiIntrLoginOtherFailRsps, iscsiIntrLoginRedirectRsps, iscsiIntrLoginAuthFailRsps, iscsiIntrLoginAuthenticateFails, iscsiIntrLoginNegotiateFails } STATUS current DESCRIPTION "A collection of objects providing information about all login attempts by local initiators to remote targets." ::= { iscsiGroups 12 } iscsiInitiatorLogoutStatsGroup OBJECT-GROUP OBJECTS { iscsiIntrLogoutNormals, iscsiIntrLogoutOthers } STATUS current DESCRIPTION "A collection of objects providing information about all logout events between local initiators and remote targets." ::= { iscsiGroups 13 } iscsiInitiatorAuthGroup OBJECT-GROUP OBJECTS { iscsiIntrAuthRowStatus, iscsiIntrAuthStorageType, iscsiIntrAuthIdentity } STATUS current Bakke, et al. Standards Track [Page 72] RFC 4544 iSCSI MIB May 2006 DESCRIPTION "A collection of objects providing information about all remote targets that are initiators of the local system that they are authorized to access." ::= { iscsiGroups 14 } iscsiSessionAttributesGroup OBJECT-GROUP OBJECTS { iscsiSsnDirection, iscsiSsnInitiatorName, iscsiSsnTargetName, iscsiSsnTSIH, iscsiSsnISID, iscsiSsnInitiatorAlias, iscsiSsnTargetAlias, iscsiSsnInitialR2T, iscsiSsnImmediateData, iscsiSsnType, iscsiSsnMaxOutstandingR2T, iscsiSsnFirstBurstLength, iscsiSsnMaxBurstLength, iscsiSsnConnectionNumber, iscsiSsnAuthIdentity, iscsiSsnDataSequenceInOrder, iscsiSsnDataPDUInOrder, iscsiSsnErrorRecoveryLevel, iscsiSsnDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects providing information applicable to all sessions." ::= { iscsiGroups 15 } iscsiSessionPDUStatsGroup OBJECT-GROUP OBJECTS { iscsiSsnCmdPDUs, iscsiSsnRspPDUs } STATUS current DESCRIPTION "A collection of objects providing information about PDU traffic for each session." ::= { iscsiGroups 16 } iscsiSessionOctetStatsGroup OBJECT-GROUP OBJECTS { iscsiSsnTxDataOctets, Bakke, et al. Standards Track [Page 73] RFC 4544 iSCSI MIB May 2006 iscsiSsnRxDataOctets } STATUS current DESCRIPTION "A collection of objects providing information about octet traffic for each session using a Counter64 data type." ::= { iscsiGroups 17 } iscsiSessionLCOctetStatsGroup OBJECT-GROUP OBJECTS { iscsiSsnLCTxDataOctets, iscsiSsnLCRxDataOctets } STATUS current DESCRIPTION "A collection of objects providing information about octet traffic for each session using a Counter32 data type." ::= { iscsiGroups 18 } iscsiSessionCxnErrorStatsGroup OBJECT-GROUP OBJECTS { iscsiSsnCxnDigestErrors, iscsiSsnCxnTimeoutErrors } STATUS current DESCRIPTION "A collection of objects providing information about connection errors for all sessions." ::= { iscsiGroups 19 } iscsiConnectionAttributesGroup OBJECT-GROUP OBJECTS { iscsiCxnCid, iscsiCxnState, iscsiCxnProtocol, iscsiCxnAddrType, iscsiCxnLocalAddr, iscsiCxnLocalPort, iscsiCxnRemoteAddr, iscsiCxnRemotePort, iscsiCxnMaxRecvDataSegLength, iscsiCxnMaxXmitDataSegLength, iscsiCxnHeaderIntegrity, iscsiCxnDataIntegrity, iscsiCxnRecvMarker, iscsiCxnSendMarker, iscsiCxnVersionActive } Bakke, et al. Standards Track [Page 74] RFC 4544 iSCSI MIB May 2006 STATUS current DESCRIPTION "A collection of objects providing information about all connections used by all sessions." ::= { iscsiGroups 20 } iscsiTgtLgnNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { iscsiTgtLoginFailure } STATUS current DESCRIPTION "A collection of notifications that indicate a login failure from a remote initiator to a local target." ::= { iscsiGroups 21 } iscsiIntrLgnNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { iscsiIntrLoginFailure } STATUS current DESCRIPTION "A collection of notifications that indicate a login failure from a local initiator to a remote target." ::= { iscsiGroups 22 } iscsiSsnFlrNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { iscsiInstSessionFailure } STATUS current DESCRIPTION "A collection of notifications that indicate session failures occurring after login." ::= { iscsiGroups 23 } --********************************************************************** iscsiComplianceV1 MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial version of compliance statement based on initial version of this MIB module. If an implementation can be both a target and an initiator, all groups are mandatory." MODULE -- this module MANDATORY-GROUPS { Bakke, et al. Standards Track [Page 75] RFC 4544 iSCSI MIB May 2006 iscsiInstanceAttributesGroup, iscsiInstanceSsnErrorStatsGroup, iscsiPortalAttributesGroup, iscsiNodeAttributesGroup, iscsiSessionAttributesGroup, iscsiSessionPDUStatsGroup, iscsiSessionCxnErrorStatsGroup, iscsiConnectionAttributesGroup, iscsiSsnFlrNotificationsGroup } -- Conditionally mandatory groups depending on the ability -- to support Counter64 data types and/or to provide counter -- information to SNMPv1 applications. GROUP iscsiSessionOctetStatsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that can support Counter64 data types." GROUP iscsiSessionLCOctetStatsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that provide information to SNMPv1-only applications; this includes agents that cannot support Counter64 data types." -- Conditionally mandatory groups to be included with -- the mandatory groups when the implementation has -- iSCSI target facilities. GROUP iscsiTgtPortalAttributesGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI target facilities." OBJECT iscsiPortalMaxRecvDataSegLength MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT iscsiNodeStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required; an implementation may choose to allow this object to be set to 'volatile' or 'nonVolatile'." Bakke, et al. Standards Track [Page 76] RFC 4544 iSCSI MIB May 2006 GROUP iscsiTargetAttributesGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI target facilities." GROUP iscsiTargetLoginStatsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI target facilities." GROUP iscsiTargetLogoutStatsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI target facilities." GROUP iscsiTgtLgnNotificationsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI target facilities." GROUP iscsiTargetAuthGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI target facilities." -- Conditionally mandatory groups to be included with -- the mandatory groups when the implementation has -- iSCSI initiator facilities. GROUP iscsiIntrPortalAttributesGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI initiator facilities." GROUP iscsiInitiatorAttributesGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI initiator facilities." GROUP iscsiInitiatorLoginStatsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI initiator facilities." GROUP iscsiInitiatorLogoutStatsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI initiator facilities." Bakke, et al. Standards Track [Page 77] RFC 4544 iSCSI MIB May 2006 GROUP iscsiIntrLgnNotificationsGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI initiator facilities." GROUP iscsiInitiatorAuthGroup DESCRIPTION "This group is mandatory for all iSCSI implementations that have iSCSI initiator facilities." OBJECT iscsiNodeErrorRecoveryLevel SYNTAX Unsigned32 (0..2) DESCRIPTION "Only values 0-2 are defined at present." ::= { iscsiCompliances 1 } END Bakke, et al. Standards Track [Page 78] RFC 4544 iSCSI MIB May 2006 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: iscsiPortalAttributesTable, iscsiTgtPortalAttributesTable, and iscsiIntrPortalAttributesTable can be used to add or remove IP addresses to be used by iSCSI. iscsiTgtAuthAttributesTable entries can be added or removed, to allow or disallow access to a target by an initiator. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: iscsiNodeAttributesTable, iscsiTargetAttributesTable, and iscsiTgtAuthorization can be used to glean information needed to make connections to the iSCSI targets this module represents. However, it is the responsibility of the initiators and targets involved to authenticate each other to ensure that an inappropriately advertised or discovered initiator or target does not compromise their security. These issues are discussed in [RFC3720]. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator Bakke, et al. Standards Track [Page 79] RFC 4544 iSCSI MIB May 2006 responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations The IANA has assigned a MIB OID number under the mib-2 branch for the ISCSI-MIB. 10. Normative References [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, March 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4545] Bakke, M. and J. Muchow, "Definitions of Managed Objects for IP Storage User Identity Authorization", RFC 4545, May 2006. Bakke, et al. Standards Track [Page 80] RFC 4544 iSCSI MIB May 2006 11. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005. [RFC4455] Hallak-Stamler, M., Bakke, M., Lederman, Y., Krueger, M., and K. McCloghrie, "Definition of Managed Objects for Small Computer System Interface (SCSI) Entities", RFC 4455, April 2006. 12. Acknowledgements In addition to the authors, several people contributed to the development of this MIB module. Thanks especially to those who took the time to participate in our weekly conference calls to build our requirements, object models, table structures, and attributes: John Hufferd, Tom McSweeney (IBM), Kevin Gibbons (Nishan Systems), Chad Gregory (Intel), Jack Harwood (EMC), Hari Mudaliar (Adaptec), Ie Wei Njoo (Agilent), Lawrence Lamers (SAN Valley), Satish Mali (Stonefly Networks), and William Terrell (Troika). Special thanks to Tom McSweeney, Ie Wei Njoo, and Kevin Gibbons, who wrote the descriptions for many of the tables and attributes in this MIB module, to Ayman Ghanem for finding and suggesting changes for many problems in this module, and to Keith McCloghrie for serving as advisor to the team. Bakke, et al. Standards Track [Page 81] RFC 4544 iSCSI MIB May 2006 Authors' Addresses Mark Bakke Cisco Systems, Inc 7900 International Drive, Suite 400 Bloomington, MN USA 55425 EMail: mbakke@cisco.com Marjorie Krueger Hewlett-Packard Networked Storage Architecture Networked Storage Solutions Org. 8000 Foothills Blvd. Roseville, CA USA 95747 EMail: marjorie_krueger@hp.com Tom McSweeney IBM Corporation 600 Park Offices Drive Research Triangle Park, NC USA 27709 EMail: tommcs@us.ibm.com James Muchow Qlogic Corp. 6321 Bury Drive Eden Prairie, MN USA 55346 EMail: james.muchow@qlogic.com Bakke, et al. Standards Track [Page 82] RFC 4544 iSCSI MIB May 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bakke, et al. Standards Track [Page 83] snmp-mibs-downloader-1.1/mibrfcs/rfc4545.txt0000644000000000000000000025246111402176072015576 0ustar Network Working Group M. Bakke Request for Comments: 4545 Cisco Systems Category: Standards Track J. Muchow Qlogic Corp. May 2006 Definitions of Managed Objects for IP Storage User Identity Authorization 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. Bakke & Muchow Standards Track [Page 1] RFC 4545 IPS Authorization MIB May 2006 Table of Contents 1. Introduction ....................................................3 2. Specification of Requirements ...................................3 3. The Internet-Standard Management Framework ......................3 4. Relationship to Other MIB Modules ...............................3 5. Relationship to the USM MIB Module ..............................4 6. Relationship to SNMP Contexts ...................................5 7. Discussion ......................................................5 7.1. Authorization MIB Object Model .............................5 7.2. ipsAuthInstance ............................................6 7.3. ipsAuthIdentity ............................................7 7.4. ipsAuthIdentityName ........................................7 7.5. ipsAuthIdentityAddress .....................................8 7.6. ipsAuthCredential ..........................................8 7.7. IP, Fibre Channel, and Other Addresses .....................9 7.8. Descriptors: Using OIDs in Place of Enumerated Types ......10 7.9. Notifications .............................................10 8. MIB Definitions ................................................11 9. Security Considerations ........................................35 9.1. MIB Security Considerations ...............................35 9.2. Other Security Considerations .............................38 10. IANA Considerations ...........................................40 11. Normative References ..........................................40 12. Informative References ........................................41 13. Acknowledgements ..............................................41 Bakke & Muchow Standards Track [Page 2] RFC 4545 IPS Authorization MIB May 2006 1. Introduction This MIB module will be used to configure and/or look at the configuration of user identities and their credential information. For the purposes of this MIB module, a "user" identity does not need to be an actual person; a user can also be a host, an application, a cluster of hosts, or any other identifiable entity that can be authorized to access a resource. Most objects in this MIB module have a MAX-ACCESS of read-create; this module is intended to allow configuration of user identities and their names, addresses, and credentials. MIN-ACCESS for all objects is read-only for those implementations that configure through other means, but require the ability to monitor user identities. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Relationship to Other MIB Modules The IPS-AUTH-MIB module does not directly address objects within other modules. The identity address objects contain IPv4, IPv6, or other address types, and as such they may be indirectly related to objects within the IP [RFC4293] MIB module. This MIB module does not provide actual authorization or access control lists; it provides a means to identify entities that can be included in other authorization lists. This should generally be done in MIB modules that reference identities in this one. It also does not cover login or authentication failure statistics or Bakke & Muchow Standards Track [Page 3] RFC 4545 IPS Authorization MIB May 2006 notifications, as these are all fairly application specific and are not generic enough to be included here. The user identity objects within this module are typically referenced from other modules by a RowPointer within that module. A module containing resources for which it requires a list of authorized user identities may create such a list, with a single RowPointer within each list element pointing to a user identity within this module. This is neither required nor restricted by this MIB module. 5. Relationship to the USM MIB Module The User-based Security Model (USM) [RFC3414] also defines the concept of a user, defining authentication and privacy protocols and their credentials. The definition of USM includes the SNMP-USER- BASED-SM-MIB module allows configuration of SNMPv3 user credentials to protect SNMPv3 messages. Although USM's users are not related to the user identities managed by the IPS-AUTH-MIB module defined in this document, USM will often be implemented on the same system as the IPS-AUTH-MIB module, with the SNMP-USER-BASED-SM-MIB module used to manage the security protecting SNMPv3 messages, including those that access the IPS-AUTH-MIB module. The term "user" in this document is distinct from an SNMPv3 user and is intended to include, but is not limited to, users of IP storage devices. A "user" in this document is a collection of user names (unique identifiers), user addresses, and credentials that can be used together to determine whether an entity should be allowed access to a resource. Each user can have multiple names, addresses, and credentials. As a result, this MIB module is particularly suited to managing users of storage resources, which are typically given access control lists consisting of potentially multiple identifiers, addresses, and credentials. This MIB module provides for authorization lists only and does not include setting of data privacy parameters. In contrast, an SNMPv3 user as defined in [RFC3414] has exactly one user-name, one authentication protocol, and one privacy protocol, along with their associated information and SNMP-specific information, such as an engine ID. These objects are defined to support exactly the information needed for SNMPv3 security. For the remainder of this document, the term "user" means an IPS- AUTH-MIB user identity. Bakke & Muchow Standards Track [Page 4] RFC 4545 IPS Authorization MIB May 2006 6. Relationship to SNMP Contexts Each non-scalar object in the IPS-AUTH-MIB module is indexed first by an instance. Each instance is a collection of identities that can be used to authorize access to a resource. The use of an instance works well with partitionable or hierarchical devices and fits in logically with other management schemes. Instances do not replace SNMP contexts; however, they do provide a very simple way to assign a collection of identities within a device to one or more SNMP contexts, without having to do so for each identity's row. 7. Discussion This MIB module structure is intended to allow the configuration of a list of user identities, each with a list of names, addresses, credentials, and certificates that, when combined, will distinguish that identity. The IPS-AUTH-MIB module is structured around two primary "objects", the authorization instance and the identity, which serve as containers for the remainder of the objects. This section contains a brief description of the "object" hierarchy and a description of each object, followed by a discussion of the actual SNMP table structure within the objects. 7.1. Authorization MIB Object Model The top-level object in this structure is the authorization instance, which "contains" all of the other objects. The indexing hierarchy of this module looks like: ipsAuthInstance -- A distinct authorization entity within the managed system. -- Most implementations will have just one of these. ipsAuthIdentity -- A user identity, consisting of a set of identity names, -- addresses, and credentials reflected in the following -- objects: ipsAuthIdentityName -- A name for a user identity. A name should be globally -- unique, and unchanging over time. Some protocols may -- not require this one. ipsAuthIdentityAddress -- An address range, typically but not necessarily an -- IPv4, IPv6, or Fibre Channel address range, at which -- the identity is allowed to reside. ipsAuthCredential -- A single credential, such as a CHAP username, Bakke & Muchow Standards Track [Page 5] RFC 4545 IPS Authorization MIB May 2006 -- which can be used to verify the identity. ipsAuthCredChap -- CHAP-specific attributes for an ipsAuthCredential ipsAuthCredSrp -- SRP-specific attributes ipsAuthCredKerberos -- Kerberos-specific attributes Each identity contains the information necessary to identify a particular end-point that wishes to access a service, such as iSCSI. An identity can contain multiple names, addresses, and credentials. Each of these names, addresses, and credentials exists in its own row. If multiple rows of one of these three types are present, they are treated in an "OR" fashion; an entity to be authorized need only match one of the rows. If rows of different types are present (e.g., a name and an address), these are treated in an "AND" fashion; an entity to be authorized must match at least one row from each category. If there are no rows present of a category, this category is ignored. For example, if an ipsAuthIdentity contains two rows of ipsAuthIdentityAddress, one row of ipsAuthCredential, and no rows of ipsAuthIdentityName, an entity must match the Credential row and at least one of the two Address rows to match the identity. Index values such as ipsAuthInstIndex and ipsAuthIdentIndex are referenced in multiple tables, and rows can be added and deleted. An implementation should therefore attempt to keep all index values persistent across reboots; index values for rows that have been deleted must not be reused before a reboot. 7.2. ipsAuthInstance The ipsAuthInstanceAttributesTable is the primary table of the IPS- AUTH-MIB module. Every other table entry in this module includes the index of an ipsAuthInstanceAttributesEntry as its primary index. An authorization instance is basically a managed set of identities. Many implementations will include just one authorization instance row in this table. However, there will be cases where multiple rows in this table may be used: - A large system may be "partitioned" into multiple, distinct virtual systems, perhaps sharing the SNMP agent but not their lists of identities. Each virtual system would have its own authorization instance. Bakke & Muchow Standards Track [Page 6] RFC 4545 IPS Authorization MIB May 2006 - A set of stackable systems, each with its own set of identities, may be represented by a common SNMP agent. Each individual system would have its own authorization instance. - Multiple protocols, each with its own set of identities, may exist within a single system and be represented by a single SNMP agent. In this case, each protocol may have its own authorization instance. An entry in this table is often referenced by its name (ipsAuthInstDescr), which should be displayed to the user by the management station. When an implementation supports only one entry in this table, the description may be returned as a zero-length string. 7.3. ipsAuthIdentity The ipsAuthIdentAttributesTable contains one entry for each configured user identity. The identity contains only a description of what the identity is used for; its attributes are all contained in other tables, since they can each have multiple values. Other MIB modules containing lists of users authorized to access a particular resource should generally contain a RowPointer to the ipsAuthIdentAttributesEntry that will, if authenticated, be allowed access to the resource. All other table entries make use of the indices to this table as their primary indices. 7.4. ipsAuthIdentityName The ipsAuthIdentNameAttributesTable contains a list of UTF-8 names, each of which belongs to, and may be used to identify, a particular identity in the authIdentity table. Implementations making use of the IPS-AUTH-MIB module may identify their resources by names, addresses, or both. A name is typically a unique (within the required scope), unchanging identifier for a resource. It will normally meet some or all of the requirements for a Uniform Resource Name [RFC1737], although a name in the context of this MIB module does not need to be a URN. Identifiers that typically change over time should generally be placed into the ipsAuthIdentityAddress table; names that have no uniqueness properties should usually be placed into the description attribute for the identity. Bakke & Muchow Standards Track [Page 7] RFC 4545 IPS Authorization MIB May 2006 An example of an identity name is the iSCSI Name, defined in [RFC3720]. Any other MIB module defining names to be used as ipsAuthIdentityName objects should specify how its names are unique, and the domain within which they are unique. If this table contains no entries associated with a particular user identity, the implementation does not need to check any name parameters when verifying that identity. If the table contains multiple entries associated with a particular user identity, the implementation should consider a match with any one of these entries to be valid. 7.5. ipsAuthIdentityAddress The ipsAuthIdentAddrAttributesTable contains a list of addresses at which the identity may reside. For example, an identity may be allowed access to a resource only from a certain IP address, or only if its address is in a certain range or set of ranges. Each entry contains a starting and ending address. If a single address is desired in the list, both starting and ending addresses must be identical. Each entry contains an AddrType attribute. This attribute contains an enumeration registered as an IANA Address Family type [IANA-AF]. Although many implementations will use IPv4 or IPv6 address types for these entries, any IANA-registered type may be used, as long as it makes sense to the application. Matching any address within any range within the list associated with a particular identity is considered a valid match. If no entries are present in this list for a given identity, its address is automatically assumed to match the identity. Netmasks are not supported, since an address range can express the same thing with more flexibility. An application specifying addresses using network masks may do so, and convert to and from address ranges when reading or writing this MIB module. 7.6. ipsAuthCredential The ipsAuthCredentialAttributesTable contains a list of credentials, each of which may be used to verify a particular identity. Bakke & Muchow Standards Track [Page 8] RFC 4545 IPS Authorization MIB May 2006 Each credential contains an authentication method to be used, such as CHAP [RFC1994], SRP [RFC2945], or Kerberos [RFC4120]. This attribute contains an object identifier instead of an enumerated type, allowing other MIB modules to add their own authentication methods, without modifying this MIB module. For each entry in this table, there will exist an entry in another table containing its attributes. The table in which to place the entry depends on the AuthMethod attribute: CHAP If the AuthMethod is set to the CHAP OID, an entry using the same indices as the ipsAuthCredential will exist in the ipsAuthCredChap table, which contains the CHAP username. SRP If the AuthMethod is set to the SRP OID, an entry using the same indices as the ipsAuthCredential will exist in the ipsAuthCredSrp table, which contains the SRP username. Kerberos If the AuthMethod is set to the Kerberos OID, an entry using the same indices as the ipsAuthCredential will exist in the ipsAuthCredKerberos table, which contains the Kerberos principal. Other If the AuthMethod is set to any OID not defined in this module, an entry using the same indices as the ipsAuthCredential entry should be placed in the other module that define whatever attributes are needed for that type of credential. An additional credential type can be added to this MIB module by defining a new OID in the ipsAuthMethodTypes subtree, and defining a new table specific to that credential type. 7.7. IP, Fibre Channel, and Other Addresses The IP addresses in this MIB module are represented by two attributes, one of type AddressFamilyNumbers, and the other of type AuthAddress. Each address can take on any of the types within the list of address family numbers; the most likely being IPv4, IPv6, or one of the Fibre Channel address types. The type AuthAddress is an octet string. If the address family is IPv4 or IPv6, the format is taken from the InetAddress specified in [RFC4001]. If the address family is one of the Fibre Channel types, the format is identical to the FcNameIdOrZero type defined in [RFC4044]. Bakke & Muchow Standards Track [Page 9] RFC 4545 IPS Authorization MIB May 2006 7.8. Descriptors: Using OIDs in Place of Enumerated Types Some attributes, particularly the authentication method attribute, would normally require an enumerated type. However, implementations will likely need to add new authentication method types of their own, without extending this MIB module. To make this work, this module defines a set of object identities within ipsAuthDescriptors. Each of these object identities is basically an enumerated type. Attributes that make use of these object identities have a value that is an OID instead of an enumerated type. These OIDs can either indicate the object identities defined in this module, or object identities defined elsewhere, such as in an enterprise MIB module. Those implementations that add their own authentication methods should also define a corresponding object identity for each of these methods within their own enterprise MIB module, and return its OID whenever one of these attributes is using that method. 7.9. Notifications Monitoring of authentication failures and other notification events are outside the scope of this MIB module, as they are generally application specific. No notifications are provided or required. Bakke & Muchow Standards Track [Page 10] RFC 4545 IPS Authorization MIB May 2006 8. MIB Definitions IPS-AUTH-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Unsigned32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, AutonomousType, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB ; ipsAuthMibModule MODULE-IDENTITY LAST-UPDATED "200605220000Z" -- May 22, 2006 ORGANIZATION "IETF IPS Working Group" CONTACT-INFO " Mark Bakke Postal: Cisco Systems, Inc 7900 International Drive, Suite 400 Bloomington, MN USA 55425 E-mail: mbakke@cisco.com James Muchow Postal: Qlogic Corp. 6321 Bury Dr. Eden Prairie, MN USA 55346 E-Mail: james.muchow@qlogic.com" DESCRIPTION "The IP Storage Authorization MIB module. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4545; see the RFC itself for full legal notices." Bakke & Muchow Standards Track [Page 11] RFC 4545 IPS Authorization MIB May 2006 REVISION "200605220000Z" -- May 22, 2006 DESCRIPTION "Initial version of the IP Storage Authentication MIB module, published as RFC 4545" ::= { mib-2 141 } ipsAuthNotifications OBJECT IDENTIFIER ::= { ipsAuthMibModule 0 } ipsAuthObjects OBJECT IDENTIFIER ::= { ipsAuthMibModule 1 } ipsAuthConformance OBJECT IDENTIFIER ::= { ipsAuthMibModule 2 } -- Textual Conventions IpsAuthAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "IP Storage requires the use of address information that uses not only the InetAddress type defined in the INET-ADDRESS-MIB, but also Fibre Channel type defined in the Fibre Channel Management MIB. Although these address types are recognized in the IANA Address Family Numbers MIB, the addressing mechanisms have not been merged into a well-known, common type. This data type, the IpsAuthAddress, performs the merging for this MIB module. The formats of objects of this type are determined by a corresponding object with syntax AddressFamilyNumbers, and thus every object defined using this TC must identify the object with syntax AddressFamilyNumbers that specifies its type. The syntax and semantics of this object depend on the identified AddressFamilyNumbers object as follows: AddressFamilyNumbers this object ==================== =========== ipV4(1) restricted to the same syntax and semantics as the InetAddressIPv4 TC. ipV6(2) restricted to the same syntax and semantics as the InetAddressIPv6 TC. fibreChannelWWPN (22) & fibreChannelWWNN(23) restricted to the same syntax and semantics as the FcNameIdOrZero TC. Types other than the above should not be used unless Bakke & Muchow Standards Track [Page 12] RFC 4545 IPS Authorization MIB May 2006 the corresponding format of the IpsAuthAddress object is further specified (e.g., in a future revision of this TC)." REFERENCE "IANA-ADDRESS-FAMILY-NUMBERS-MIB; INET-ADDRESS-MIB (RFC 4001); FC-MGMT-MIB (RFC 4044)." SYNTAX OCTET STRING (SIZE(0..255)) --****************************************************************** ipsAuthDescriptors OBJECT IDENTIFIER ::= { ipsAuthObjects 1 } ipsAuthMethodTypes OBJECT-IDENTITY STATUS current DESCRIPTION "Registration point for Authentication Method Types." REFERENCE "RFC 3720, iSCSI Protocol Specification." ::= { ipsAuthDescriptors 1 } ipsAuthMethodNone OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when no authentication method is used." REFERENCE "RFC 3720, iSCSI Protocol Specification." ::= { ipsAuthMethodTypes 1 } ipsAuthMethodSrp OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when the authentication method is SRP." REFERENCE "RFC 3720, iSCSI Protocol Specification." ::= { ipsAuthMethodTypes 2 } ipsAuthMethodChap OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when the authentication method is CHAP." REFERENCE "RFC 3720, iSCSI Protocol Specification." ::= { ipsAuthMethodTypes 3 } ipsAuthMethodKerberos OBJECT-IDENTITY STATUS current DESCRIPTION "The authoritative identifier when the authentication method is Kerberos." Bakke & Muchow Standards Track [Page 13] RFC 4545 IPS Authorization MIB May 2006 REFERENCE "RFC 3720, iSCSI Protocol Specification." ::= { ipsAuthMethodTypes 4 } --****************************************************************** ipsAuthInstance OBJECT IDENTIFIER ::= { ipsAuthObjects 2 } -- Instance Attributes Table ipsAuthInstanceAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthInstanceAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Authorization instances present on the system." ::= { ipsAuthInstance 2 } ipsAuthInstanceAttributesEntry OBJECT-TYPE SYNTAX IpsAuthInstanceAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a particular Authorization instance." INDEX { ipsAuthInstIndex } ::= { ipsAuthInstanceAttributesTable 1 } IpsAuthInstanceAttributesEntry ::= SEQUENCE { ipsAuthInstIndex Unsigned32, ipsAuthInstDescr SnmpAdminString, ipsAuthInstStorageType StorageType } ipsAuthInstIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular authorization instance. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { ipsAuthInstanceAttributesEntry 1 } ipsAuthInstDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write Bakke & Muchow Standards Track [Page 14] RFC 4545 IPS Authorization MIB May 2006 STATUS current DESCRIPTION "A character string, determined by the implementation to describe the authorization instance. When only a single instance is present, this object may be set to the zero-length string; with multiple authorization instances, it must be set to a unique value in an implementation-dependent manner to describe the purpose of the respective instance. If this is deployed in a master agent with more than one subagent implementing this MIB module, the master agent is responsible for ensuring that this object is unique across all subagents." ::= { ipsAuthInstanceAttributesEntry 2 } ipsAuthInstStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "The storage type for all read-write objects within this row. Rows in this table are always created via an external process, and may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row. If this object has the value 'volatile', modifications to read-write objects in this row are not persistent across reboots. If this object has the value 'nonVolatile', modifications to objects in this row are persistent. An implementation may choose to allow this object to be set to either 'nonVolatile' or 'volatile', allowing the management application to choose this behavior." DEFVAL { volatile } ::= { ipsAuthInstanceAttributesEntry 3 } ipsAuthIdentity OBJECT IDENTIFIER ::= { ipsAuthObjects 3 } -- User Identity Attributes Table ipsAuthIdentAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthIdentAttributesEntry MAX-ACCESS not-accessible STATUS current Bakke & Muchow Standards Track [Page 15] RFC 4545 IPS Authorization MIB May 2006 DESCRIPTION "A list of user identities, each belonging to a particular ipsAuthInstance." ::= { ipsAuthIdentity 1 } ipsAuthIdentAttributesEntry OBJECT-TYPE SYNTAX IpsAuthIdentAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information describing a user identity within an authorization instance on this node." INDEX { ipsAuthInstIndex, ipsAuthIdentIndex } ::= { ipsAuthIdentAttributesTable 1 } IpsAuthIdentAttributesEntry ::= SEQUENCE { ipsAuthIdentIndex Unsigned32, ipsAuthIdentDescription SnmpAdminString, ipsAuthIdentRowStatus RowStatus, ipsAuthIdentStorageType StorageType } ipsAuthIdentIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular identity instance within an authorization instance present on the node. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { ipsAuthIdentAttributesEntry 1 } ipsAuthIdentDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A character string describing this particular identity." ::= { ipsAuthIdentAttributesEntry 2 } ipsAuthIdentRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Bakke & Muchow Standards Track [Page 16] RFC 4545 IPS Authorization MIB May 2006 DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. Rows may be discarded using RowStatus. The value of ipsAuthIdentDescription may be set while ipsAuthIdentRowStatus is 'active'." ::= { ipsAuthIdentAttributesEntry 3 } ipsAuthIdentStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for all read-create objects in this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipsAuthIdentAttributesEntry 4 } ipsAuthIdentityName OBJECT IDENTIFIER ::= { ipsAuthObjects 4 } -- User Initiator Name Attributes Table ipsAuthIdentNameAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthIdentNameAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of unique names that can be used to positively identify a particular user identity." ::= { ipsAuthIdentityName 1 } ipsAuthIdentNameAttributesEntry OBJECT-TYPE SYNTAX IpsAuthIdentNameAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a unique identity name, which can be used to identify a user identity within a particular authorization instance." INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthIdentNameIndex } ::= { ipsAuthIdentNameAttributesTable 1 } Bakke & Muchow Standards Track [Page 17] RFC 4545 IPS Authorization MIB May 2006 IpsAuthIdentNameAttributesEntry ::= SEQUENCE { ipsAuthIdentNameIndex Unsigned32, ipsAuthIdentName SnmpAdminString, ipsAuthIdentNameRowStatus RowStatus, ipsAuthIdentNameStorageType StorageType } ipsAuthIdentNameIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular identity name instance within an ipsAuthIdentity within an authorization instance. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { ipsAuthIdentNameAttributesEntry 1 } ipsAuthIdentName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A character string that is the unique name of an identity that may be used to identify this ipsAuthIdent entry." ::= { ipsAuthIdentNameAttributesEntry 2 } ipsAuthIdentNameRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. Rows may be discarded using RowStatus. The value of ipsAuthIdentName may be set when this value is 'active'." ::= { ipsAuthIdentNameAttributesEntry 3 } ipsAuthIdentNameStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION Bakke & Muchow Standards Track [Page 18] RFC 4545 IPS Authorization MIB May 2006 "The storage type for all read-create objects in this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipsAuthIdentNameAttributesEntry 4 } ipsAuthIdentityAddress OBJECT IDENTIFIER ::= { ipsAuthObjects 5 } -- User Initiator Address Attributes Table ipsAuthIdentAddrAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthIdentAddrAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of address ranges that are allowed to serve as the endpoint addresses of a particular identity. An address range includes a starting and ending address and an optional netmask, and an address type indicator, which can specify whether the address is IPv4, IPv6, FC-WWPN, or FC-WWNN." ::= { ipsAuthIdentityAddress 1 } ipsAuthIdentAddrAttributesEntry OBJECT-TYPE SYNTAX IpsAuthIdentAddrAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to an address range that is used as part of the authorization of an identity within an authorization instance on this node." INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthIdentAddrIndex } ::= { ipsAuthIdentAddrAttributesTable 1 } IpsAuthIdentAddrAttributesEntry ::= SEQUENCE { ipsAuthIdentAddrIndex Unsigned32, ipsAuthIdentAddrType AddressFamilyNumbers, ipsAuthIdentAddrStart IpsAuthAddress, ipsAuthIdentAddrEnd IpsAuthAddress, ipsAuthIdentAddrRowStatus RowStatus, ipsAuthIdentAddrStorageType StorageType } ipsAuthIdentAddrIndex OBJECT-TYPE Bakke & Muchow Standards Track [Page 19] RFC 4545 IPS Authorization MIB May 2006 SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular ipsAuthIdentAddress instance within an ipsAuthIdentity within an authorization instance present on the node. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { ipsAuthIdentAddrAttributesEntry 1 } ipsAuthIdentAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-create STATUS current DESCRIPTION "The address types used in the ipsAuthIdentAddrStart and ipsAuthAddrEnd objects. This type is taken from the IANA address family types." ::= { ipsAuthIdentAddrAttributesEntry 2 } ipsAuthIdentAddrStart OBJECT-TYPE SYNTAX IpsAuthAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The starting address of the allowed address range. The format of this object is determined by ipsAuthIdentAddrType." ::= { ipsAuthIdentAddrAttributesEntry 3 } ipsAuthIdentAddrEnd OBJECT-TYPE SYNTAX IpsAuthAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The ending address of the allowed address range. If the ipsAuthIdentAddrEntry specifies a single address, this shall match the ipsAuthIdentAddrStart. The format of this object is determined by ipsAuthIdentAddrType." ::= { ipsAuthIdentAddrAttributesEntry 4 } ipsAuthIdentAddrRowStatus OBJECT-TYPE SYNTAX RowStatus Bakke & Muchow Standards Track [Page 20] RFC 4545 IPS Authorization MIB May 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. Rows may be discarded using RowStatus. The values of ipsAuthIdentAddrStart and ipsAuthIdentAddrEnd may be set when this value is 'active'. The value of ipsAuthIdentAddrType may not be set when this value is 'active'." ::= { ipsAuthIdentAddrAttributesEntry 5 } ipsAuthIdentAddrStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for all read-create objects in this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipsAuthIdentAddrAttributesEntry 6 } ipsAuthCredential OBJECT IDENTIFIER ::= { ipsAuthObjects 6 } -- Credential Attributes Table ipsAuthCredentialAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthCredentialAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of credentials related to user identities that are allowed as valid authenticators of the particular identity." ::= { ipsAuthCredential 1 } ipsAuthCredentialAttributesEntry OBJECT-TYPE SYNTAX IpsAuthCredentialAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a credential that verifies a user identity within an authorization instance. Bakke & Muchow Standards Track [Page 21] RFC 4545 IPS Authorization MIB May 2006 To provide complete information in this MIB for a credential, the management station must not only create the row in this table but must also create a row in another table, where the other table is determined by the value of ipsAuthCredAuthMethod, e.g., if ipsAuthCredAuthMethod has the value ipsAuthMethodChap, a row must be created in the ipsAuthCredChapAttributesTable." INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } ::= { ipsAuthCredentialAttributesTable 1 } IpsAuthCredentialAttributesEntry ::= SEQUENCE { ipsAuthCredIndex Unsigned32, ipsAuthCredAuthMethod AutonomousType, ipsAuthCredRowStatus RowStatus, ipsAuthCredStorageType StorageType } ipsAuthCredIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer used to uniquely identify a particular Credential instance within an instance present on the node. This index value must not be modified or reused by an agent unless a reboot has occurred. An agent should attempt to keep this value persistent across reboots." ::= { ipsAuthCredentialAttributesEntry 1 } ipsAuthCredAuthMethod OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains an OBJECT IDENTIFIER that identifies the authentication method used with this credential. When a row is created in this table, a corresponding row must be created by the management station in a corresponding table specified by this value. When a row is deleted from this table, the corresponding row must be automatically deleted by the agent in the corresponding table specified by this value. Bakke & Muchow Standards Track [Page 22] RFC 4545 IPS Authorization MIB May 2006 If the value of this object is ipsAuthMethodNone, no corresponding rows are created or deleted from other tables. Some standardized values for this object are defined within the ipsAuthMethodTypes subtree." ::= { ipsAuthCredentialAttributesEntry 2 } ipsAuthCredRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. Rows may be discarded using RowStatus. The value of ipsAuthCredAuthMethod must not be changed while this row is 'active'." ::= { ipsAuthCredentialAttributesEntry 3 } ipsAuthCredStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for all read-create objects in this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipsAuthCredentialAttributesEntry 4 } ipsAuthCredChap OBJECT IDENTIFIER ::= { ipsAuthObjects 7 } -- Credential Chap-Specific Attributes Table ipsAuthCredChapAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthCredChapAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of CHAP attributes for credentials that use ipsAuthMethodChap as their ipsAuthCredAuthMethod. A row in this table can only exist when an instance of the ipsAuthCredAuthMethod object exists (or is created Bakke & Muchow Standards Track [Page 23] RFC 4545 IPS Authorization MIB May 2006 simultaneously) having the same instance identifiers and a value of 'ipsAuthMethodChap'." ::= { ipsAuthCredChap 1 } ipsAuthCredChapAttributesEntry OBJECT-TYPE SYNTAX IpsAuthCredChapAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a credential that uses ipsAuthMethodChap as their ipsAuthCredAuthMethod. When a row is created in ipsAuthCredentialAttributesTable with ipsAuthCredAuthMethod = ipsAuthCredChap, the management station must create a corresponding row in this table. When a row is deleted from ipsAuthCredentialAttributesTable with ipsAuthCredAuthMethod = ipsAuthCredChap, the agent must delete the corresponding row (if any) in this table." INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } ::= { ipsAuthCredChapAttributesTable 1 } IpsAuthCredChapAttributesEntry ::= SEQUENCE { ipsAuthCredChapUserName SnmpAdminString, ipsAuthCredChapRowStatus RowStatus, ipsAuthCredChapStorageType StorageType } ipsAuthCredChapUserName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A character string containing the CHAP user name for this credential." REFERENCE "W. Simpson, RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP), August 1996" ::= { ipsAuthCredChapAttributesEntry 1 } ipsAuthCredChapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Bakke & Muchow Standards Track [Page 24] RFC 4545 IPS Authorization MIB May 2006 "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. Rows may be discarded using RowStatus. The value of ipsAuthCredChapUserName may be changed while this row is 'active'." ::= { ipsAuthCredChapAttributesEntry 2 } ipsAuthCredChapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for all read-create objects in this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipsAuthCredChapAttributesEntry 3 } ipsAuthCredSrp OBJECT IDENTIFIER ::= { ipsAuthObjects 8 } -- Credential Srp-Specific Attributes Table ipsAuthCredSrpAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthCredSrpAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of SRP attributes for credentials that use ipsAuthMethodSrp as its ipsAuthCredAuthMethod. A row in this table can only exist when an instance of the ipsAuthCredAuthMethod object exists (or is created simultaneously) having the same instance identifiers and a value of 'ipsAuthMethodSrp'." ::= { ipsAuthCredSrp 1 } ipsAuthCredSrpAttributesEntry OBJECT-TYPE SYNTAX IpsAuthCredSrpAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a credential that uses ipsAuthMethodSrp as their ipsAuthCredAuthMethod. Bakke & Muchow Standards Track [Page 25] RFC 4545 IPS Authorization MIB May 2006 When a row is created in ipsAuthCredentialAttributesTable with ipsAuthCredAuthMethod = ipsAuthCredSrp, the management station must create a corresponding row in this table. When a row is deleted from ipsAuthCredentialAttributesTable with ipsAuthCredAuthMethod = ipsAuthCredSrp, the agent must delete the corresponding row (if any) in this table." INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } ::= { ipsAuthCredSrpAttributesTable 1 } IpsAuthCredSrpAttributesEntry ::= SEQUENCE { ipsAuthCredSrpUserName SnmpAdminString, ipsAuthCredSrpRowStatus RowStatus, ipsAuthCredSrpStorageType StorageType } ipsAuthCredSrpUserName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A character string containing the SRP user name for this credential." REFERENCE "T. Wu, RFC 2945: The SRP Authentication and Key Exchange System, September 2000" ::= { ipsAuthCredSrpAttributesEntry 1 } ipsAuthCredSrpRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. Rows may be discarded using RowStatus. The value of ipsAuthCredSrpUserName may be changed while the status of this row is 'active'." ::= { ipsAuthCredSrpAttributesEntry 2 } ipsAuthCredSrpStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION Bakke & Muchow Standards Track [Page 26] RFC 4545 IPS Authorization MIB May 2006 "The storage type for all read-create objects in this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipsAuthCredSrpAttributesEntry 3 } ipsAuthCredKerberos OBJECT IDENTIFIER ::= { ipsAuthObjects 9 } -- Credential Kerberos-Specific Attributes Table ipsAuthCredKerbAttributesTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsAuthCredKerbAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Kerberos attributes for credentials that use ipsAuthMethodKerberos as their ipsAuthCredAuthMethod. A row in this table can only exist when an instance of the ipsAuthCredAuthMethod object exists (or is created simultaneously) having the same instance identifiers and a value of 'ipsAuthMethodKerb'." ::= { ipsAuthCredKerberos 1 } ipsAuthCredKerbAttributesEntry OBJECT-TYPE SYNTAX IpsAuthCredKerbAttributesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (row) containing management information applicable to a credential that uses ipsAuthMethodKerberos as its ipsAuthCredAuthMethod. When a row is created in ipsAuthCredentialAttributesTable with ipsAuthCredAuthMethod = ipsAuthCredKerberos, the management station must create a corresponding row in this table. When a row is deleted from ipsAuthCredentialAttributesTable with ipsAuthCredAuthMethod = ipsAuthCredKerberos, the agent must delete the corresponding row (if any) in this table." INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } ::= { ipsAuthCredKerbAttributesTable 1 } IpsAuthCredKerbAttributesEntry ::= SEQUENCE { Bakke & Muchow Standards Track [Page 27] RFC 4545 IPS Authorization MIB May 2006 ipsAuthCredKerbPrincipal SnmpAdminString, ipsAuthCredKerbRowStatus RowStatus, ipsAuthCredKerbStorageType StorageType } ipsAuthCredKerbPrincipal OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A character string containing a Kerberos principal for this credential." REFERENCE "C. Neuman, S. Hartman, and K. Raeburn, RFC 4120: The Kerberos Network Authentication Service (V5), July 2005" ::= { ipsAuthCredKerbAttributesEntry 1 } ipsAuthCredKerbRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This field allows entries to be dynamically added and removed from this table via SNMP. When adding a row to this table, all non-Index/RowStatus objects must be set. Rows may be discarded using RowStatus. The value of ipsAuthCredKerbPrincipal may be changed while this row is 'active'." ::= { ipsAuthCredKerbAttributesEntry 2 } ipsAuthCredKerbStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for all read-create objects in this row. Rows in this table that were created through an external process may have a storage type of readOnly or permanent. Conceptual rows having the value 'permanent' need not allow write access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipsAuthCredKerbAttributesEntry 3 } --****************************************************************** -- Notifications -- There are no notifications necessary in this MIB module. Bakke & Muchow Standards Track [Page 28] RFC 4545 IPS Authorization MIB May 2006 --****************************************************************** -- Conformance Statements ipsAuthCompliances OBJECT IDENTIFIER ::= { ipsAuthConformance 1 } ipsAuthGroups OBJECT IDENTIFIER ::= { ipsAuthConformance 2 } ipsAuthInstanceAttributesGroup OBJECT-GROUP OBJECTS { ipsAuthInstDescr, ipsAuthInstStorageType } STATUS current DESCRIPTION "A collection of objects providing information about authorization instances." ::= { ipsAuthGroups 1 } ipsAuthIdentAttributesGroup OBJECT-GROUP OBJECTS { ipsAuthIdentDescription, ipsAuthIdentRowStatus, ipsAuthIdentStorageType } STATUS current DESCRIPTION "A collection of objects providing information about user identities within an authorization instance." ::= { ipsAuthGroups 2 } ipsAuthIdentNameAttributesGroup OBJECT-GROUP OBJECTS { ipsAuthIdentName, ipsAuthIdentNameRowStatus, ipsAuthIdentNameStorageType } STATUS current DESCRIPTION "A collection of objects providing information about user names within user identities within an authorization instance." ::= { ipsAuthGroups 3 } ipsAuthIdentAddrAttributesGroup OBJECT-GROUP OBJECTS { ipsAuthIdentAddrType, ipsAuthIdentAddrStart, ipsAuthIdentAddrEnd, Bakke & Muchow Standards Track [Page 29] RFC 4545 IPS Authorization MIB May 2006 ipsAuthIdentAddrRowStatus, ipsAuthIdentAddrStorageType } STATUS current DESCRIPTION "A collection of objects providing information about address ranges within user identities within an authorization instance." ::= { ipsAuthGroups 4 } ipsAuthIdentCredAttributesGroup OBJECT-GROUP OBJECTS { ipsAuthCredAuthMethod, ipsAuthCredRowStatus, ipsAuthCredStorageType } STATUS current DESCRIPTION "A collection of objects providing information about credentials within user identities within an authorization instance." ::= { ipsAuthGroups 5 } ipsAuthIdentChapAttrGroup OBJECT-GROUP OBJECTS { ipsAuthCredChapUserName, ipsAuthCredChapRowStatus, ipsAuthCredChapStorageType } STATUS current DESCRIPTION "A collection of objects providing information about CHAP credentials within user identities within an authorization instance." ::= { ipsAuthGroups 6 } ipsAuthIdentSrpAttrGroup OBJECT-GROUP OBJECTS { ipsAuthCredSrpUserName, ipsAuthCredSrpRowStatus, ipsAuthCredSrpStorageType } STATUS current DESCRIPTION "A collection of objects providing information about SRP credentials within user identities within an authorization instance." ::= { ipsAuthGroups 7 } Bakke & Muchow Standards Track [Page 30] RFC 4545 IPS Authorization MIB May 2006 ipsAuthIdentKerberosAttrGroup OBJECT-GROUP OBJECTS { ipsAuthCredKerbPrincipal, ipsAuthCredKerbRowStatus, ipsAuthCredKerbStorageType } STATUS current DESCRIPTION "A collection of objects providing information about Kerberos credentials within user identities within an authorization instance." ::= { ipsAuthGroups 8 } --****************************************************************** ipsAuthComplianceV1 MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial version of compliance statement based on initial version of this MIB module. The Instance and Identity groups are mandatory; at least one of the other groups (Name, Address, Credential, Certificate) is also mandatory for any given implementation." MODULE -- this module MANDATORY-GROUPS { ipsAuthInstanceAttributesGroup, ipsAuthIdentAttributesGroup } -- Conditionally mandatory groups to be included with -- the mandatory groups when necessary. GROUP ipsAuthIdentNameAttributesGroup DESCRIPTION "This group is mandatory for all implementations that make use of unique identity names." GROUP ipsAuthIdentAddrAttributesGroup DESCRIPTION "This group is mandatory for all implementations that use addresses to help verify identities." GROUP ipsAuthIdentCredAttributesGroup DESCRIPTION "This group is mandatory for all implementations that use credentials to help verify identities." Bakke & Muchow Standards Track [Page 31] RFC 4545 IPS Authorization MIB May 2006 GROUP ipsAuthIdentChapAttrGroup DESCRIPTION "This group is mandatory for all implementations that use CHAP to help verify identities. The ipsAuthIdentCredAttributesGroup must be implemented if this group is implemented." GROUP ipsAuthIdentSrpAttrGroup DESCRIPTION "This group is mandatory for all implementations that use SRP to help verify identities. The ipsAuthIdentCredAttributesGroup must be implemented if this group is implemented." GROUP ipsAuthIdentKerberosAttrGroup DESCRIPTION "This group is mandatory for all implementations that use Kerberos to help verify identities. The ipsAuthIdentCredAttributesGroup must be implemented if this group is implemented." OBJECT ipsAuthInstDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthInstStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthIdentDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthIdentRowStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." Bakke & Muchow Standards Track [Page 32] RFC 4545 IPS Authorization MIB May 2006 OBJECT ipsAuthIdentName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthIdentNameRowStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipsAuthIdentAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthIdentAddrStart MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthIdentAddrEnd MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthIdentAddrRowStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipsAuthCredAuthMethod MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthCredRowStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the Bakke & Muchow Standards Track [Page 33] RFC 4545 IPS Authorization MIB May 2006 six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipsAuthCredChapUserName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthCredChapRowStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipsAuthCredSrpUserName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthCredSrpRowStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT ipsAuthCredKerbPrincipal MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipsAuthCredKerbRowStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." ::= { ipsAuthCompliances 1 } END Bakke & Muchow Standards Track [Page 34] RFC 4545 IPS Authorization MIB May 2006 9. Security Considerations 9.1. MIB Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o in the ipsAuthInstanceAttributesTable: - ipsAuthInstDescr could be modified to camouflage the existence of a rogue authorization instance; o in the ipsAuthIdentAttributesTable: - ipsAuthIdentDescription could be modified to camouflage the existence of a rogue identity; - ipsAuthIdentRowStatus could be modified to add or delete a rogue identity; - ipsAuthIdentStorageType could be modified to make temporary rows permanent, or permanent rows temporary; o in the ipsAuthIdentNameAttributesTable: - ipsAuthIdentName could be modified to change the name of an existing identity; - ipsAuthIdentNameRowStatus could be modified to add or delete a name of an existing identity; - ipsAuthIdentNameStorageType could be modified to make temporary rows permanent, or permanent rows temporary; o in the ipsAuthIdentAddrAttributesTable: - ipsAuthIdentAddrType could be modified to change the type of address checking performed; - ipsAuthIdentAddrStart could be modified to change the start of the allowed range; Bakke & Muchow Standards Track [Page 35] RFC 4545 IPS Authorization MIB May 2006 - ipsAuthIdentAddrEnd could be modified to change the end of the allowed range; - ipsAuthIdentAddrRowStatus could be modified to add or delete the checking of an address range; - ipsAuthIdentAddrStorageType could be modified to make temporary rows permanent, or permanent rows temporary; o in the ipsAuthCredentialAttributesTable: - ipsAuthCredAuthMethod could be modified to change the type of authentication to be used; - ipsAuthCredRowStatus could be modified to add or delete checking of credentials; - ipsAuthCredStorageType could be modified to make temporary rows permanent, or permanent rows temporary; o in the ipsAuthCredChapAttributesTable: - ipsAuthCredChapUserName could be modified to change the CHAP user name for a credential; - ipsAuthCredChapRowStatus could be modified to add or delete CHAP attributes for credentials; - ipsAuthCredChapStorageType could be modified to make temporary rows permanent, or permanent rows temporary; o in the ipsAuthCredSrpAttributesTable: - ipsAuthCredSrpUserName could be modified to change the SRP user name for a credential; - ipsAuthCredSrpRowStatus could be modified to add or delete SRP attributes for credentials; - ipsAuthCredSrpStorageType could be modified to make temporary rows permanent, or permanent rows temporary; o in the ipsAuthCredKerbAttributesTable: - ipsAuthCredKerbPrincipal could be modified to change the Kerberos principal for a credential; Bakke & Muchow Standards Track [Page 36] RFC 4545 IPS Authorization MIB May 2006 - ipsAuthCredKerbRowStatus could be modified to add or delete Kerberos attributes for credentials; - ipsAuthCredKerbStorageType could be modified to make temporary rows permanent, or permanent rows temporary; Note that removal of legitimate credentials can result in either denial of service or weakening the requirements for access of a particular service. Note also that some types of credentials, such as CHAP or SRP, also require passwords or verifiers to be associated with the credential. These are managed outside this MIB module. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o All tables (specifically: ipsAuthInstanceAttributesTable, ipsAuthIdentAttributesTable, ipsAuthIdentNameAttributesTable, ipsAuthIdentAddrAttributesTable, ipsAuthCredentialAttributesTable, ipsAuthCredChapAttributesTable, ipsAuthCredSrpAttributesTable, and ipsAuthCredKerbAttributesTable) provide the ability to find out which names, addresses, and credentials would be required to access services on the managed system. If these credentials are easily spoofed (particularly the name or address), read access to this MIB module must be tightly controlled. When used with pointers from another MIB module to rows in the ipsAuthIdentAttributesTable, this MIB module provides information about which entities are authorized to connect to which entities. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an Bakke & Muchow Standards Track [Page 37] RFC 4545 IPS Authorization MIB May 2006 instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. In many implementations, the objects in this MIB module can be read and modified via other mechanisms or protocols in addition to this MIB module. For the system to be secure, other mechanisms that can read and modify the contents of this MIB module must also address the above issues, and handle the threats outlined in [RFC3411], section 1.4. Given the sensitivity of information contained in this MIB module, it is strongly recommended that encryption (SNMPv3 with a securityLevel of authPriv [RFC3411]) be used for all access to objects in this MIB module. 9.2. Other Security Considerations An identity consists of a set of names (e.g., an iSCSI Initiator Name), addresses (e.g., an IP address or Fibre Channel World Wide Name (WWN)), and credentials (e.g., a CHAP user name). To match an identity, one must match: o One of the IdentNames belonging to the IdentIndex, unless there are no IdentNames for the IdentIndex, and o One of the IdentAddrs belonging to the IdentIndex, unless there are no IdentAddrs for the IdentIndex, and o One of the IdentCreds belonging to the IdentIndex, unless there are no Creds for the IdentIndex. Note that if any of the above lists are empty for a given IdentIndex, any identifier of that type is considered to match the identity. The non-empty lists will still be checked. For example, if the IdentAddrs list is empty for the IndentIndex, but there are entries in IdentNames and IdentCreds, any address will be considered a match, as long as the offered name and credential match one of the IdentNames and IdentCreds, respectively. This leaves a possible security window while adding and removing entries from one of these lists. For example, an identity could consist of no IdentNames, no IdentAddrs, and exactly one IdentCred. If that IdentCred was to be updated, several methods could be used: Bakke & Muchow Standards Track [Page 38] RFC 4545 IPS Authorization MIB May 2006 o The UserName or Principal could be simply written in the appropriate table, if the credential's type remained the same (recommended). o The new credential could be added, then the old deleted (recommended). o The new credential could be added, and the old deleted in the same SNMP request (recommended, but do the add first). o The old credential could be deleted, then the new added (Don't use!). Of the above methods, the last leaves a window in which the list is empty, possibly allowing unconstrained access to the resource making use of this MIB. This method should never be used for Names, Addrs, or Creds. The use of the third method, adding and deleting within the same request, should be used with care. It is recommended that within the request, the add be done first. Otherwise, an implementation may attempt to perform these operations in order, potentially leaving a window. The first two methods are recommended. Care must also be taken when updating the IdentAddrs for an identity. Each IdentAddr specifies a range of addresses that match the identity, and has an address type, starting address, and ending address. Modifying these one at a time can open a temporary window where a larger range of addresses are allowed. For example, a single address is specified using IdentAddrType = ipv4, IdentAddrStart = IdentAddrEnd = 192.0.2.5. We want to update this to specify the single address 192.0.2.34. If the end address is updated first, we temporarily allow the range 192.0.2.5 .. 192.0.2.34, which is not what we want. Similarly, if we change from 192.0.2.34 back to 192.0.2.5, and we update IdentAddrStart first, we end up with the range again. To handle this, an application must either: o update both IdentAddrStart and IdentAddrEnd in the same SNMP set request, or o add the new IdentAddrStart and IdentAddrEnd with a new IdentAddrIndex, then delete the old one, using the methods shown before. Bakke & Muchow Standards Track [Page 39] RFC 4545 IPS Authorization MIB May 2006 Since the value of IdentAddrType specifies the formats of IdentAddrStart and IdentAddrEnd, modification of IdentAddrType is not allowed for an existing row. 10. IANA Considerations The IANA has assigned a MIB OID number under the mib-2 branch for the IPS-AUTH-MIB. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J. , Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [IANA-AF] IANA, "IANA Address Family Numbers MIB", http://www.iana.org/assignments/ ianaaddressfamilynumbers-mib. [RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. Bakke & Muchow Standards Track [Page 40] RFC 4545 IPS Authorization MIB May 2006 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. 12. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, March 2004. [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. 13. Acknowledgements In addition to the authors, several people contributed to the development of this MIB module through discussions of authentication, authorization, and access within the iSCSI MIB module and security teams, including John Hufferd, Marjorie Krueger, Keith McCloghrie, Tom McSweeney, Steve Senum, and Josh Tseng. Thanks also to Bill Studenmund (Wasabi Systems) for adding the Kerberos method, and to Ayman Ghanem for finding and suggesting changes to several problems found in the MIB module. Thanks especially to Keith McCloghrie for serving as advisor for this MIB module. Bakke & Muchow Standards Track [Page 41] RFC 4545 IPS Authorization MIB May 2006 Authors' Addresses Mark Bakke Postal: Cisco Systems, Inc 7900 International Drive, Suite 400 Bloomington, MN USA 55425 EMail: mbakke@cisco.com James Muchow Postal: Qlogic Corp. 6321 Bury Drive Eden Prairie, MN USA 55346 EMail: james.muchow@qlogic.com Bakke & Muchow Standards Track [Page 42] RFC 4545 IPS Authorization MIB May 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bakke & Muchow Standards Track [Page 43] snmp-mibs-downloader-1.1/mibrfcs/rfc4546.txt0000644000000000000000000111345411402176072015576 0ustar Network Working Group D. Raftus Request for Comments: 4546 ATI Technologies, Inc. Obsoletes: 2670 E. Cardona Category: Standards Track CableLabs June 2006 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces 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. This document revises and obsoletes RFC 2670. Please see Section 5.3 for a description of the changes from RFC 2670. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Glossary ........................................................3 2.1. Baseline Privacy ...........................................3 2.2. CATV .......................................................3 2.3. Channel ....................................................3 2.4. CM or Cable Modem ..........................................3 2.5. CMTS or Cable Modem Termination System .....................3 2.6. Codeword ...................................................4 2.7. Data Packet ................................................4 2.8. dBmV .......................................................4 2.9. DOCSIS .....................................................4 Raftus & Cardona Standards Track [Page 1] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 2.9.1. DOCSIS 1.0 ..........................................4 2.9.2. DOCSIS 1.1 ..........................................4 2.9.3. DOCSIS 2.0 ..........................................4 2.10. Downstream ................................................5 2.11. Euro-DOCSIS ...............................................5 2.12. Head-end ..................................................5 2.13. MAC Packet ................................................5 2.14. MCNS ......................................................5 2.15. Mini-slot .................................................5 2.16. QPSK (Quadrature Phase Shift Keying) ......................5 2.17. QAM (Quadrature Amplitude Modulation) .....................5 2.18. RF ........................................................5 2.19. Symbol-times ..............................................5 2.20. Upstream ..................................................6 3. Overview ........................................................6 3.1. Textual Conventions ........................................6 3.1.1. Textual Conventions in RFC 2670 .....................6 3.1.2. Textual Conventions in RFC 4546 .....................6 3.2. Structure of the MIB .......................................6 3.2.1. docsIfBaseObjects ...................................7 3.2.2. docsIfCmObjects .....................................7 3.2.3. docsIfCmtsObjects ...................................8 3.2.4. Relationship to the Interfaces MIB Module ...........8 3.2.5. Offline Upstream Parameters Handling ...............22 4. Definitions ....................................................24 5. Revision History ..............................................134 5.1. Scope ....................................................134 5.2. Extension ................................................134 6. Security Considerations .......................................134 7. Management Interoperability of DOCSIS 1.0, 1.1, and 2.0 .......136 8. References ....................................................136 8.1. Normative References .....................................136 8.2. Informative References ...................................137 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] STD 58, RFC 2580 [RFC2580]. Raftus & Cardona Standards Track [Page 2] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 2. Glossary The terms in this document are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification process. 2.1. Baseline Privacy Security interface specification, designed for DOCSIS-compliant cable data systems, that ensures device authentication data confidentiality in the CATV plant. See [BPI] and [BPIPLUS]. 2.2. CATV Originally "Community Antenna Television", it now refers to any cable or hybrid fiber and cable system used to deliver video signals to a community. 2.3. Channel A specific frequency allocation with an RF medium, specified by channel width in Hertz (cycles per second) and by center frequency. Within the US Cable Systems, upstream channels are generally allocated from the 5-42MHz range while downstream channels are generally allocated from the 50-750MHz range, depending on the capabilities of the given system. The typical broadcast channel width in the US is 6MHz. Upstream channel widths for DOCSIS vary. For European cable systems, upstream channels vary by country. The upper edge of upstream channel allocations varies between 25 MHz to 65 MHz, and the lower edge of downstream channel allocations varies between 47 MHz and 87.5 MHz. The typical broadcast channel width in Europe is 8MHz. The actual parameters are of concern to systems deploying Euro-DOCSIS technology. The downstream channels conform to the requirements of ITU-T Recommendation J.83 [ITU-T_J.83] 2.4. CM or Cable Modem A CM acts as a "slave" station in a DOCSIS-compliant cable data system. 2.5. CMTS or Cable Modem Termination System A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS-compliant cable data system. It is the only station that transmits downstream, and it Raftus & Cardona Standards Track [Page 3] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 controls the scheduling of upstream transmissions by its associated CMs. 2.6. Codeword A characteristic of the Forward Error Correction scheme, used above the RF media layer. See "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209". 2.7. Data Packet The payload portion of the MAC Packet. 2.8. dBmV A measure of RF signal voltage amplitude, whose power level is determined by the characteristic impedance. A zero dB signal power is equivalent to 48.75 dBmV signal amplitude in a 75 Ohm system. 2.9. DOCSIS "Data Over Cable Service Interface Specification". A term referring to the ITU-T J112 [ITU-T_J.112] Annex B standard for cable modem systems. 2.9.1. DOCSIS 1.0 Cable modem systems that are CM/CMTS compliant to requirements in [RFI1.0]. A common reference to DOCSIS 1.0 in this document is the upstream channel queuing mechanism, known as Class of Service (COS). 2.9.2. DOCSIS 1.1 Cable modem systems that are CM/CMTS compliant to requirements in [ITU-T_J.112]. DOCSIS 1.1 references in this document are in part associated with the upstream and downstream Quality of Service (QOS). The term DOCSIS 1.x is used in this document to refer to both DOCSIS 1.0 and DOCSIS 1.1. 2.9.3. DOCSIS 2.0 Cable modem systems that are CM/CMTS compliant to requirements in [ITU-T_J.122]. DOCSIS 2.0 corresponds to the second generation of radio-frequency interface specifications of DOCSIS. Raftus & Cardona Standards Track [Page 4] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 2.10. Downstream The direction from the head-end towards the subscriber. 2.11. Euro-DOCSIS Cable modem systems CM/CMTS that conform to the European spectrum lineup and are compliant to requirements of Annex F in [ITU-T_J.122]. 2.12. Head-end The origination point in most cable systems of the subscriber video signals. Generally also the location of the CMTS equipment. 2.13. MAC Packet A DOCSIS PDU. 2.14. MCNS "Multimedia Cable Network System". Generally replaced in usage by DOCSIS. 2.15. Mini-slot In general, an interval of time that is allocated by the CMTS to a given CM for that CM to transmit in an upstream direction. See [ITU-T_J.122] 2.16. QPSK (Quadrature Phase Shift Keying) A particular modulation scheme on an RF medium. See [Proakis00]. 2.17. QAM (Quadrature Amplitude Modulation) A particular modulation scheme on RF medium. Usually expressed with a number indicating the size of the modulation constellation (e.g., 16 QAM). See [Proakis00]. 2.18. RF Radio Frequency. 2.19. Symbol-times A characteristic of the RF modulation scheme. See [ITU-T_J.122]. Raftus & Cardona Standards Track [Page 5] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 2.20. Upstream The direction from the subscriber towards the head-end. 3. Overview This MIB module provides a set of objects required for the management of DOCSIS-compliant Cable Modem (CM) and Cable Modem Termination System (CMTS) RF interfaces. The specification is derived in part from the parameters and protocols described in [ITU-T_J.122]. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 3.1. Textual Conventions This MIB module defines new textual conventions for CM and CMTS indications of DOCSIS 2.0 RFI capabilities, configuration, usage, and backward compatible modes of operation, as defined in [RFI2.0]. With the same purpose, there are some textual conventions that represent capabilities and modes of operation of [RFI1.1] that are not covered by RFC 2670, and are managed proprietarily in the DOCSIS OSSI 1.1 specification [OSSI1.1]. 3.1.1. Textual Conventions in RFC 2670 RFC 2670 defined two textual conventions, TenthdBmV and TenthdB, which are power measurement representations. 3.1.2. Textual Conventions in RFC 4546 This MIB module defines the textual convention DocsisUpstreamType to represent the DOCSIS 1.0 [RFI1.0] and DOCSIS 2.0 [RFI2.0] upstream burst modulation profiles types. This MIB module defines the textual conventions DocsisVersion and DocsisQosVersion to represent the DOCSIS 1.0 [RFI1.0] and DOCSIS 1.1 [RFI1.1] COS/QOS capabilities and modes of operation. 3.2. Structure of the MIB This MIB module is structured as three groups: o Management information pertinent to both Cable Modem (CM) and Cable Modem Termination System (CMTS) (docsIfBaseObjects). Raftus & Cardona Standards Track [Page 6] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 o Management information pertinent to Cable Modem only (docsIfCmObjects). o Management information pertinent to Cable Modem Termination System only (docsIfCmtsObjects). Tables within each of these groups cover different functions; e.g., upstream queue services, channel characteristics, MAC layer management, etc. Rows created automatically (e.g., by the device according to the hardware configuration) may and generally will have a mixture of configuration and status objects within them. Rows that are meant to be created by the management station are generally restricted to configuration (read-create) objects. 3.2.1. docsIfBaseObjects docsIfDownstreamChannelTable - This table describes the existing downstream channels for a CMTS and the received downstream channel for a CM. docsIfUpstreamChannelTable - This table describes the existing upstream channels for a CMTS and the current upstream transmission channel for a CM. docsIfQosProfileTable - This table describes the valid Quality of Service profiles for the cable data system. docsIfSignalQualityTable - This table is used to monitor RF signal quality characteristics of received signals. docsIfDocsisBaseCapability - This object is used to indicate the highest level of DOCSIS version a cable device can support. 3.2.2. docsIfCmObjects docsIfCmMacTable - This table is used to monitor the DOCSIS MAC interface and can be considered an extension to the ifEntry. docsIfCmStatusTable - This table maintains a number of status objects and counters for cable modems. There is a comparable table at the CMTS, docsIfCmtsCmStatusTable, which maintains similar counters from the CMTS point of view. docsIfCmServiceTable - This table describes the upstream service queues available at this CM. There is a comparable table at the CMTS, docsIfCmtsServiceEntry, which describes the service queues from the point of view of the CMTS. Raftus & Cardona Standards Track [Page 7] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 3.2.3. docsIfCmtsObjects docsIfCmtsMacTable - Describes the attributes of each CMTS MAC interface. docsIfCmtsStatusTable - This table provides a set of aggregated counters that roll-up values and events that occur on the underlying sub-interfaces. docsIfCmtsCmStatusTable - This table is used to hold information about known (i.e., ranging, registered, and/or previously online) cable modems on the system serviced by this CMTS. docsIfCmtsServiceTable - This table provides access to the information related to upstream service queues. docsIfCmtsModulationTable - This table allows control over the modulation profiles for RF channels associated with this CMTS. docsIfCmtsMacToCmTable - This table allows fast access into the docsIfCmtsCmTable via a MAC address (of the CM) interface. docsIfCmtsChannelUtilizationTable - This table provides statistical load usage data for attached upstream and downstream physical channels. docsIfCmtsDownChannelCounterTable - This table provides statistical data for attached downstream channels, appropriate as input for load usage calculations. docsIfCmtsUpChannelCounterTable - This table provides statistical data for attached upstream channels, appropriate as input for load usage calculations. 3.2.4. Relationship to the Interfaces MIB Module This section clarifies the relationship of this MIB module to the Interfaces MIB [RFC2863]. Several areas of correlation are addressed in the following subsections. The implementer is referred to the Interfaces MIB document in order to understand the general intent of these areas. 3.2.4.1. Layering Model An instance of ifEntry exists for each RF downstream interface, for each RF upstream interface, for each upstream logical Channel, and for each RF MAC layer. Raftus & Cardona Standards Track [Page 8] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 The ifStackTable [RFC2863] MUST be implemented to identify the relationships among sub-interfaces. The following example illustrates a CMTS MAC interface with one downstream and two upstream interfaces. | <== to network layer +------------------ --+-------------------------------+ | RF MAC | +--+------------------+------------------------+------+ | | | +-------+-----+ +------+------+ +------+------+ | Downstream1 | | Upstream1 | | Upstream2 | | | | | | | +-------------+ ++-----------++ ++-----------++ | | | | +----+----+ +----+----+ +----+----+ +----+----+ | Ch-1 | | Ch-2 | | Ch-1 | | Ch-2 | |(A/TDMA) | |(S-CDMA) | |(A/TDMA) | |(S-CDMA) | +---------+ +---------+ +---------+ +---------+ Figure 1 As can be seen from this example, the RF MAC interface is layered on top of the downstream and upstream interfaces, and the RF upstream interface is layered on top of an upstream logical channel. In this example, the assignment of index values could be as follows: ifIndex ifType Description 2 docsCableMaclayer(127) CATV MAC Layer 3 docsCableDownstream(128) CATV Downstream interface 4 docsCableUpstream(129) CATV Upstream interface 5 docsCableUpstream(129) CATV Upstream interface 6 docsCableUpstreamChannel(205) CATV Upstream Channel 7 docsCableUpstreamChannel(205) CATV Upstream Channel 8 docsCableUpstreamChannel(205) CATV Upstream Channel 9 docsCableUpstreamChannel(205) CATV Upstream Channel Figure 2 Raftus & Cardona Standards Track [Page 9] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 The corresponding ifStack entries would then be: | IfStackHigherLayer | ifStackLowerLayer | | 0 | 2 | | 2 | 3 | | 2 | 4 | | 2 | 5 | | 4 | 6 | | 4 | 7 | | 5 | 8 | | 5 | 9 | | 3 | 0 | | 6 | 0 | | 7 | 0 | | 8 | 0 | | 9 | 0 | Figure 3 The same interface model can also be used in Telephony or Telco Return systems. A pure Telco Return system (Cable Modem, as well as Cable Modem Termination System) would not have upstream cable channels, only downstream cable channels. Systems supporting both Telco Return and cable upstream channels can use the above model without modification. Telco Return upstream channel(s) management is outside the scope of this document. 3.2.4.2. Virtual Circuits This medium does not support virtual circuits, and this area is not applicable to this MIB module. 3.2.4.3. ifTestTable The ifTestTable is optional for DOCSIS CM/CMTS implementations, but is not specifically influenced by the RF MIB. 3.2.4.4. ifRcvAddressTable The ifRcvAddressTable is optional for DOCSIS CM/CMTS implementations, but is not specifically influenced by the RF MIB. Raftus & Cardona Standards Track [Page 10] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 3.2.4.5. ifEntry This section documents only the differences from the requirements specified in the Interfaces MIB module. See that MIB module for columns omitted from the descriptions below. 3.2.4.5.1. ifEntry for Downstream Interfaces The ifEntry for downstream interfaces supports the ifGeneralInformationGroup and the ifPacketGroup of the Interfaces MIB module. This is an output-only interface at the CMTS, and all input status counters -- ifIn* -- will return zero. This is an input-only interface at the CM, and all output status counters -- ifOut* -- will return zero. 3.2.4.5.1.1. ifEntry for Downstream Interfaces in Cable Modem Termination System ifTable Comments ============== =========================================== ifIndex Each CATV Downstream interface is represented by an ifEntry. ifType The IANA value of docsCableDownstream(128). ifSpeed Return the speed of this downstream channel. The returned value is the raw bandwidth in bits/s of this interface. This is the symbol rate multiplied with the number of bits per symbol. ifHighSpeed Return the speed of this downstream channel. The returned value is the raw bandwidth in megabits/s of this interface. This is the symbol rate multiplied with the number of bits per symbol. ifPhysAddress Return the zero-length OCTET STRING. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of this interface. ifMtu The size of the largest frame that can be sent on this interface, specified in octets. The value includes the length of the MAC header. ifInOctets ifHCInOctets Return zero. Raftus & Cardona Standards Track [Page 11] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifInUcastPkts ifHCInUcastPkts Return zero. ifInMulticastPkts ifHCInMulticastPkts Return zero. ifInBroadcastPkts ifHCInBroadcastPkts Return zero. ifInDiscards Return zero. ifInErrors Return zero. ifInUnknownProtos Return zero. ifOutOctets ifHCOutOctets The total number of octets transmitted on this interface. This includes MAC packets as well as data packets, and includes the length of the MAC header. ifOutUcastPkts ifHCOutUcastPkts The number of unicast packets transmitted on this interface. This includes MAC packets as well as data packets. ifOutMulticastPkts ifHCOutMulticastPkts Return the number of multicast packets transmitted on this interface. This includes MAC packets as well as data packets. ifOutBroadcastPkts ifHCOutBroadcastPkts Return the number of broadcast packets transmitted on this interface. This includes MAC packets as well as data packets. ifOutDiscards The total number of outbound packets which were discarded. Possible reasons are: buffer shortage. ifOutErrors The number of packets that could not be transmitted due to errors. ifPromiscuousMode Return false. Raftus & Cardona Standards Track [Page 12] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 3.2.4.5.1.2. ifEntry for Downstream Interfaces in Cable Modem ifTable Comments ============== =========================================== ifIndex Each CATV Downstream interface is represented by an ifEntry. ifType The IANA value of docsCableDownstream(128). ifSpeed Return the speed of this downstream channel. The returned value the raw bandwidth in bits/s of this interface. This is the symbol rate multiplied with the number of bits per symbol. ifHighSpeed Return the speed of this downstream channel. The returned value the raw bandwidth in megabits/s of this interface. This is the symbol rate multiplied with the number of bits per symbol. ifPhysAddress Return the zero-length OCTET STRING. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of this interface. ifMtu The size of the largest frame that can be received from this interface, specified in octets. The value includes the length of the MAC header. ifInOctets ifHCInOctets The total number of octets received on this interface. This includes data packets as well as MAC packets, and includes the length of the MAC header. ifInUcastPkts ifHCInUcastPkts The number of unicast packets received on this interface. This includes data packets as well as MAC packets. ifInMulticastPkts ifHCInMulticastPkts Return the number of multicast packets received on this interface. This includes data packets as well as MAC packets. Raftus & Cardona Standards Track [Page 13] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifInBroadcastPkts ifHCInBroadcastPkts Return the number of broadcast packets received on this interface. This includes data packets as well as MAC packets. ifInDiscards The total number of received packets that have been discarded. The possible reasons are: buffer shortage. ifInErrors The number of inbound packets that contained errors preventing them from being deliverable to higher layers. Possible reasons are: MAC FCS error. ifInUnknownProtos The number of frames with an unknown packet type. These are MAC frames with an unknown packet type. ifOutOctets Return zero. ifHCOutOctets ifOutUcastPkts Return zero. ifHCOutUcastPkts ifOutMulticastPkts ifHCOutMulticastPkts Return zero. ifOutBroadcastPkts ifHCOutBroadcastPkts Return zero. ifOutDiscards Return zero. ifOutErrors Return zero. ifPromiscuousMode Refer to the Interfaces MIB. 3.2.4.5.2. ifEntry for Upstream Interfaces Each supported interface of the type docsCableUpstream(129) must have a corresponding ifEntry. The ifEntry for upstream interfaces supports the ifGeneralInformationGroup and the ifPacketGroup of the Interfaces MIB. This is an input-only interface at the CMTS, and all output status counters -- ifOut* -- will return zero. This is an output only interface at the CM, and all input status counters -- ifIn* -- will return zero. Raftus & Cardona Standards Track [Page 14] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 3.2.4.5.2.1. ifEntry for Upstream Interfaces in Cable Modem Termination System ifTable Comments ============== =========================================== ifIndex Each RF Cable Upstream interface is represented by an ifEntry. ifType The IANA value of docsCableUpstream (129). ifSpeed Return the maximum channel throughput (not payload throughput) supported by the interface. The maximum throughput is calculated for the case where upstream channels are configured to maximize interface throughput. ifHighSpeed Return the maximum channel throughput (not payload throughput) supported by the interface. The maximum throughput is calculated for the case where upstream channels are configured to maximize interface throughput. Units for this object are (1/1 000 000) * IfSpeed. ifPhysAddress Return the zero-length OCTET STRING. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of this interface. This reflects the total status of all the channels under this interface. So if at least one channel has a physical connection this interface has connection. ifMtu The size of the largest frame that can be transmitted on this interface, specified in octets. The value includes the length of the MAC header. This is the maximum of all the ifMtu of all the channels under this interface. ifInOctets ifHCInOctets The total (sum) number of octets received on all the upstream channels under this interface. This includes data packets as well as MAC packets, and includes the length of the MAC header. Raftus & Cardona Standards Track [Page 15] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifInUcastPkts ifHCInUcastPkts The total number of unicast packets received on all the upstream channels under this interface. This includes data packets as well as MAC packets. ifInMulticastPkts ifHCInMulticastPkts Return the total number of multicast packets received on all the upstream channels under this interface. This includes data packets as well as MAC layer packets. ifInBroadcastPkts ifHCInBroadcastPkts Return the total number of broadcast packets received on all the upstream channels under this interface. This includes data packets as well as MAC packets. ifInDiscards The total number of received packets that have been discarded on all the upstream channels under this interface. The possible reasons are: buffer shortage. ifInErrors The total number of inbound packets that contained errors preventing them from being deliverable to higher layers. Possible reasons are: MAC FCS error. ifInUnknownProtos The total number of frames with an unknown packet type. These are MAC frames with an unknown packet type. ifOutOctets Return zero. ifHCOutOctets ifOutUcastPkts Return zero. ifHCOutOctets ifOutMulticastPkts ifHCOutMulticastPkts Return zero. ifOutBroadcastPkts ifHCOutBroadcastPkts Return zero. Raftus & Cardona Standards Track [Page 16] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifOutDiscards Return zero. ifOutErrors Return zero. 3.2.4.5.2.2. ifEntry for Upstream Interfaces in Cable Modem ifTable Comments ============== =========================================== ifIndex Each RF Cable Upstream interface is represented by an ifEntry. ifType The IANA value of docsCableUpstream (129). ifSpeed Return the speed of this upstream interface. The returned value is the raw bandwidth in bits/s of this interface. ifHighSpeed Return the speed of this upstream interface. The returned value is the raw bandwidth in megabits/s of this interface. ifPhysAddress Return the zero-length OCTET STRING. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of this interface. ifMtu The size of the largest frame that can be transmitted on this interface, specified in octets. The value includes the length of the MAC header. ifInOctets Return zero. ifHCInOctets ifInUcastPkts Return zero. ifHCInUcastPkts ifInMulticastPkts ifHCInMulticastPkts Return zero. ifInBroadcastPkts ifHCInBroadcastPkts Return zero. ifInDiscards Return zero. Raftus & Cardona Standards Track [Page 17] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifInErrors Return zero. ifInUnknownProtos Return zero. ifOutOctets ifHCOutOctets The total number of octets transmitted on this interface. This includes MAC packets as well as data packets, and includes the length of the MAC header. ifOutUcastPkts ifHCOutUcastPkts The number of unicast packets transmitted on this interface. This includes MAC packets as well as data packets. ifOutMulticastPkts ifHCOutMulticastPkts Return the number of multicast packets transmitted on this interface. This includes MAC packets as well as data packets. ifOutBroadcastPkts ifHCOutBroadcastPkts Return the number of broadcast packets transmitted on this interface. This includes MAC packets as well as data packets. ifOutDiscards The total number of outbound packets that were discarded. Possible reasons are: buffer shortage. ifOutErrors The number of packets that could not be transmitted due to errors. ifPromiscuousMode Return false. 3.2.4.5.3. ifEntry for Upstream Channels Each supported channel of the type docsCableUpstreamChannel(205) must have a corresponding ifEntry. The ifEntry for upstream channels supports the ifGeneralInformationGroup and the ifPacketGroup of the Interfaces MIB. This is an input only interface at the CMTS and all output status counters -- ifOut* -- will return zero. DOCSIS CMs are not required to support logical upstream channels. Raftus & Cardona Standards Track [Page 18] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 3.2.4.5.3.1. ifEntry for Upstream Channels in Cable Modem Termination System ifTable Comments ============== =========================================== ifIndex Each RF Cable Upstream channel is represented by an ifEntry. ifType The IANA value of docsCableUpstreamChannel (205). ifSpeed Return the speed of this upstream channel. The returned value is the raw bandwidth in bits/s of this channel. ifHighSpeed Return the speed of this upstream channel. The returned value is the raw bandwidth in megabits/s of this channel. ifPhysAddress Return the zero-length OCTET STRING. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of this interface. ifMtu The size of the largest frame that can be received on this interface, specified in octets. The value includes the length of the MAC header. ifInOctets The total number of octets received on this interface. This includes data packets as well as MAC packets, and includes the length of the MAC header. ifInUcastPkts ifHCInUcastPkts The number of unicast packets received on this interface. This includes data packets as well as MAC packets. ifInMulticastPkts ifHCInMulticastPkts Return the number of multicast packets received on this interface. This includes data packets as well as MAC layer packets. Raftus & Cardona Standards Track [Page 19] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifInBroadcastPkts ifHCInBroadcastPkts Return the number of broadcast packets received on this interface. This includes data packets as well as MAC packets. ifInDiscards The total number of received packets that have been discarded. The possible reasons are: buffer shortage. ifInErrors The number of inbound packets that contained errors preventing them from being deliverable to higher layers. Possible reasons are: MAC FCS error. ifInUnknownProtos The number of frames with an unknown packet type. These are MAC frames with an unknown packet type. ifOutOctets Return zero. ifHCOutOctets ifOutUcastPkts Return zero. ifHCOutUcastPkts ifOutMulticastPkts ifHCOutMulticastPkts Return zero. ifOutBroadcastPkts ifHCOutBroadcastPkts Return zero. ifOutDiscards Return zero. ifOutErrors Return zero. 3.2.4.5.4. ifEntry for the MAC Layer The ifEntry for the MAC Layer supports the ifGeneralInformationGroup and the ifPacketGroup of the Interfaces MIB. This interface provides an aggregate view of status for the lower level downstream and upstream interfaces. ifTable Comments ============== =========================================== ifIndex Each RF Cable MAC layer entity is represented by an ifEntry. Raftus & Cardona Standards Track [Page 20] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifType The IANA value of docsCableMaclayer(127). ifSpeed Return zero. ifPhysAddress Return the physical address of this interface. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of the MAC layer interface. ifHighSpeed Return zero. ifMtu Return 1500. ifInOctets ifHCInOctets The total number of data octets received on this interface, targeted for upper protocol layers. ifInUcastPkts ifHCInUcastPkts The number of unicast packets received on this interface, targeted for upper protocol layers. ifInMulticastPkts ifHCInMulticastPkts Return the number of multicast packets received on this interface, targeted for upper protocol layers. ifInBroadcastPkts ifHCInBroadcastPkts Return the number of broadcast packets received on this interface, targeted for upper protocol layers. ifInDiscards The total number of received packets that have been discarded. The possible reasons are: buffer shortage. ifInErrors The number of inbound packets that contained errors preventing them from being deliverable to higher layers. Possible reasons are: data packet FCS error, invalid MAC header. ifInUnknownProtos The number of frames with an unknown packet type. This is the number of data packets targeted for upper protocol layers with an unknown packet type. Raftus & Cardona Standards Track [Page 21] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifOutOctets The total number of octets, received from upper ifHCOutOctets protocol layers and transmitted on this interface. ifOutUcastPkts ifHCOutUcastPkts The number of unicast packets, received from upper protocol layers and transmitted on this interface. ifOutMulticastPkts ifHCOutMulticastPkts Return the number of multicast packets received from upper protocol layers and transmitted on this interface. ifOutBroadcastPkts ifHCOutBroadcastPkts Return the number of broadcast packets received from upper protocol layers and transmitted on this interface. ifOutDiscards The total number of outbound packets that were discarded. Possible reasons are: buffer shortage. ifOutErrors The number of packets that could not be transmitted due to errors. ifPromiscuousMode Refer to the Interfaces MIB. 3.2.5. Offline Upstream Parameters Handling 3.2.5.1. Overview This section describes the offline configuration of the DOCSIS 2.0 upstream logical interface parameters. The purpose of this feature is to guarantee that upstream logical interface parameters (such as modulation profile, channel type, mini-slot size, and SCDMA attributes) are consistent prior to committing changes to an active upstream logical interface. This mechanism can reduce possible downtime of the upstream interface by minimizing SNMP SET operations to in-service upstream interfaces. This mechanism is supported by CMTSs and is not applicable to CMs. 3.2.5.2. Operation This mechanism uses three upstream channel MIB objects defined for DOCSIS 2.0 CMTS implementations: Raftus & Cardona Standards Track [Page 22] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfUpChannelStatus - The RowStatus object for the creation of temporary interfaces in the upstream interface table. A temporary entry is used to modify, validate, and commit upstream parameters of a physical interface. In the CMTS, a physical upstream interface refers to an upstream logical channel interface. docsIfUpChannelCloneFrom - This MIB object associates a physical interface with a temporary interface for the purpose of updating the upstream parameters of the physical interface. docsIfUpChannelUpdate - This MIB object is the commit object that transfers the validated upstream parameters from the temporary interface to the physical interface. The offline upstream parameters handling operation is as follows: o A temporary interface is created in which docsIfUpChannelStatus is set to 'createAndWait', which turns the new create entry status to 'notReady'. o A SET to docsIfUpChannelCloneFrom in the temporary interface to the physical interface ifIndex value performs two actions: * Creates the association of the physical interface to the temporary interface. * Copies the original upstream parameters from the physical interface to the temporary interface, which turns its status to 'notInService'. o The operator modifies the temporary interface parameters to the desired values. o At this point, a SET to 'active' to the RowStatus of the temporary interface is successful if all parameters in the temporary interface are valid for the associated physical interface; otherwise, the temporary entry remains with status 'notInservice', and the SET returns the error 'commitFailed'. o When the temporary interface status is 'active', a SET to docsIfUpChannelUpdate to 'true' transfers the temporary interface parameters values to the physical interface. o After completion of the update operations, the temporary interface is destroyed, setting the docsIfUpChannelStatus to 'destroy'. Raftus & Cardona Standards Track [Page 23] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 3.2.5.3. Relation of docsIfUpChannelStatus and ifMib The main purpose of docsIfUpChannelStatus is the creation of temporary interfaces for offline handling of the configuration of physical interfaces; it does not manage the creation or control of physical interfaces. To maintain a consistent operation and status report of interfaces, this object does not manage the administrative and operational status of physical interfaces. 4. Definitions DOCS-IF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Integer32, Counter32, Counter64, TimeTicks, IpAddress, transmission FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, MacAddress, RowStatus, TruthValue, TimeInterval, TimeStamp, StorageType FROM SNMPv2-TC -- [RFC2579] OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF -- [RFC2580] ifIndex, InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] IANAifType FROM IANAifType-MIB; -- [IANA] docsIfMib MODULE-IDENTITY LAST-UPDATED "200605240000Z" -- May 24, 2006 ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO Raftus & Cardona Standards Track [Page 24] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 " David Raftus Postal: ATI Technologies Inc. 340 Terry Fox Drive, Suite 202 Ottawa Ontario Canada Phone: +1 613 592 1052 ext.222 E-mail: david.raftus@ati.com Eduardo Cardona Postal: Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80027-9750 U.S.A. Phone: Tel: +1 303 661 9100 Fax: +1 303 661 9199 E-mail: e.cardona@cablelabs.com;mibs@cablelabs.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, Richard_Woundy@cable.comcast.com Jean-Francois Mule, jf.mule@cablelabs.com" DESCRIPTION "This is the MIB Module for DOCSIS 2.0-compliant Radio Frequency (RF) interfaces in Cable Modems and Cable Modem Termination Systems. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4546; see the RFC itself for full legal notices." REVISION "200605240000Z" DESCRIPTION "Revision of the IETF RF MIB module for DOCSIS 2.0. This version published as RFC 4546. This MIB module revision includes the following among others: Usage of ifType (205) for upstream logical channels. Addition of downstream and upstream utilization counters. Additional statistics per upstream interface. Upstream channel offline configuration mechanism. Added MIB support for new DOCSIS 2.0 modulation attributes. Euro-DOCSIS downstream interleave values. Adjustments to RFC 2670 definitions based on the MIB review guidelines from the IETF Raftus & Cardona Standards Track [Page 25] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Operations and Management Area (OPS)." REVISION "199908190000Z" DESCRIPTION "Initial version, published as RFC 2670. Modified by Mike St. Johns to fix problems identified by the first pass of the MIB doctor. Of special note, docsIfRangingResp and docsIfCmtsInsertionInterval were obsoleted and replaced by other objects with the same functionality, but with more appropriate syntax." ::= { transmission 127 } -- Textual Conventions TenthdBmV ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-1" STATUS current DESCRIPTION "This data type represents power levels that are normally expressed in dBmV. Units are in tenths of a dBmV; for example, 5.1 dBmV will be represented as 51." SYNTAX Integer32 TenthdB ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-1" STATUS current DESCRIPTION "This data type represents power levels that are normally expressed in dB. Units are in tenths of a dB; for example, 5.1 dB will be represented as 51." SYNTAX Integer32 DocsisVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the DOCSIS Radio Frequency specification being referenced. 'docsis10' indicates DOCSIS 1.0. 'docsis11' indicates DOCSIS 1.1. 'docsis20' indicates DOCSIS 2.0." SYNTAX INTEGER { docsis10 (1), docsis11 (2), docsis20 (3) } DocsisQosVersion ::= TEXTUAL-CONVENTION Raftus & Cardona Standards Track [Page 26] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 STATUS current DESCRIPTION "Indicates the referenced quality-of-service level. 'docsis10 refers to DOCSIS 1.0 Class of Service queuing services, and 'docsis11' refers to DOCSIS 1.1 Quality of Service." SYNTAX INTEGER { docsis10 (1), docsis11 (2) } DocsisUpstreamType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the DOCSIS Upstream Channel Type. 'unknown' means information not available. 'tdma' is related to TDMA, Time Division Multiple Access; 'atdma' is related to A-TDMA, Advanced Time Division Multiple Access, 'scdma' is related to S-CDMA, Synchronous Code Division Multiple Access. 'tdmaAndAtdma is related to simultaneous support of TDMA and A-TDMA modes." SYNTAX INTEGER { unknown(0), tdma(1), atdma(2), scdma(3), tdmaAndAtdma(4) } DocsEqualizerData ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type represents the equalizer data as measured at the receiver interface. The format of the equalizer follows the structure of the Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI v2.0 : 1 byte Main tap location 1..(n + m) 1 byte Number of forward taps per symbol 1 byte Number of forward taps: n 1 byte Number of reverse taps: m Following are the equalizer coefficients: First, forward taps coefficients: 2 bytes F1 (real), 2 bytes F1 (imag) Raftus & Cardona Standards Track [Page 27] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ... 2 bytes Fn (real), 2 bytes Fn (imag) Then, reverse taps coefficients: 2 bytes D1 (real), 2 bytes D1 (imag) ... 2 bytes Dm (real), 2 bytes Dm (imag) The equalizer coefficients are considered signed 16-bit integers in the range from -32768 (0x8000) to 32767 (0x7FFF). DOCSIS specifications require up to a maximum of 64 equalizer taps (n + m); therefore, this object size can get up 260 bytes (4 + 4x64). The minimum object size (other than zero) for a t-spaced tap with a minimum of 8 symbols will be 36 (4 + 4x8)." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 8-23." SYNTAX OCTET STRING(SIZE (0 | 36..260)) docsIfMibObjects OBJECT IDENTIFIER ::= { docsIfMib 1 } docsIfBaseObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 1 } docsIfCmObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 2 } docsIfCmtsObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 3 } -- -- BASE GROUP -- -- -- The following table is implemented on both the Cable Modem -- and the Cable Modem Termination System. This table is -- read only for the CM. -- docsIfDownstreamChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfDownstreamChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of downstream channels (frequency bands)." REFERENCE Raftus & Cardona Standards Track [Page 28] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-16, and 6-17." ::= { docsIfBaseObjects 1 } docsIfDownstreamChannelEntry OBJECT-TYPE SYNTAX DocsIfDownstreamChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry provides a list of attributes for a single downstream channel. An entry in this table exists for each ifEntry with an ifType of docsCableDownstream(128)." INDEX { ifIndex } ::= { docsIfDownstreamChannelTable 1 } DocsIfDownstreamChannelEntry ::= SEQUENCE { docsIfDownChannelId Integer32, docsIfDownChannelFrequency Integer32, docsIfDownChannelWidth Integer32, docsIfDownChannelModulation INTEGER, docsIfDownChannelInterleave INTEGER, docsIfDownChannelPower TenthdBmV, docsIfDownChannelAnnex INTEGER, docsIfDownChannelStorageType StorageType } docsIfDownChannelId OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The Cable Modem Termination System identification of the downstream channel within this particular MAC interface. if the interface is down, the object returns the most current value. If the downstream channel ID is unknown, this object returns a value of 0." ::= { docsIfDownstreamChannelEntry 1 } docsIfDownChannelFrequency OBJECT-TYPE SYNTAX Integer32 (0..1000000000) UNITS "hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The center of the downstream frequency associated with this channel. This object will return the current tuner Raftus & Cardona Standards Track [Page 29] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 frequency. If a CMTS provides IF output, this object will return 0, unless this CMTS is in control of the final downstream frequency. See the associated compliance object for a description of valid frequencies that may be written to this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.3.3." ::= { docsIfDownstreamChannelEntry 2 } docsIfDownChannelWidth OBJECT-TYPE SYNTAX Integer32 (0..16000000) UNITS "hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The bandwidth of this downstream channel. Most implementations are expected to support a channel width of 6 MHz (North America) and/or 8 MHz (Europe). See the associated compliance object for a description of the valid channel widths for this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 6-17." ::= { docsIfDownstreamChannelEntry 3 } docsIfDownChannelModulation OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), qam64(3), qam256(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The modulation type associated with this downstream channel. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). See the associated conformance object for write conditions and limitations. See the reference for specifics on the modulation profiles implied by qam64 and qam256." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Raftus & Cardona Standards Track [Page 30] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 6-17." ::= { docsIfDownstreamChannelEntry 4 } docsIfDownChannelInterleave OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "The Forward Error Correction (FEC) interleaving used for this downstream channel. Values are defined as follows: taps8Increment16(3): protection 5.9/4.1 usec, latency .22/.15 msec taps16Increment8(4): protection 12/8.2 usec, latency .48/.33 msec taps32Increment4(5): protection 24/16 usec, latency .98/.68 msec taps64Increment2(6): protection 47/33 usec, latency 2/1.4 msec taps128Increment1(7): protection 95/66 usec, latency 4/2.8 msec taps12increment17(8): protection 18/14 usec, latency 0.43/0.32 msec The value 'taps12increment17' is supported by EuroDOCSIS cable systems only, and the others by DOCSIS cable systems. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM), or the value of unknown(1). The value of other(2) is returned if the interleave is known but not defined in the above list. See the associated conformance object for write conditions and limitations. See the reference for the FEC configuration described by the setting of this object." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Raftus & Cardona Standards Track [Page 31] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Table 6-15." ::= { docsIfDownstreamChannelEntry 5 } docsIfDownChannelPower OBJECT-TYPE SYNTAX TenthdBmV UNITS "dBmV" MAX-ACCESS read-write STATUS current DESCRIPTION "At the CMTS, the operational transmit power. At the CM, the received power level. If the interface is down, this object either returns the configured value (CMTS), the most current value (CM) or the value of 0. See the associated conformance object for write conditions and limitations. See the reference for recommended and required power levels." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-16, 6-17." ::= { docsIfDownstreamChannelEntry 6 } docsIfDownChannelAnnex OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), annexA(3), annexB(4), annexC(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object indicates the conformance of the implementation to important regional cable standards. annexA : Annex A from ITU-T J.83 is used. (equivalent to EN 300 429) annexB : Annex B from ITU-T J.83 is used. annexC : Annex C from ITU-T J.83 is used." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 6.3.1, and H.3.1." ::= { docsIfDownstreamChannelEntry 7 } docsIfDownChannelStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only Raftus & Cardona Standards Track [Page 32] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 STATUS current DESCRIPTION "The storage type for this conceptual row. Entries with this object set to permanent(4) do not require write operations for read-write objects." ::= { docsIfDownstreamChannelEntry 8 } -- -- The following table is implemented on both the CM and the CMTS. -- For the CM, only attached channels appear in the table. For the -- CM, this table is read-only as well. -- docsIfUpstreamChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfUpstreamChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the attributes of attached upstream channels." ::= { docsIfBaseObjects 2 } docsIfUpstreamChannelEntry OBJECT-TYPE SYNTAX DocsIfUpstreamChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of attributes for a single upstream channel. For DOCSIS 2.0 CMTSs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstreamChannel (205). For DOCSIS 1.x CM/CMTSs and DOCSIS 2.0 CMs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstream (129). For DOCSIS 2.0 CMTSs, two classes of interfaces can be defined for this table: o Upstream Physical Interfaces: The traditional DOCSIS 1.x CMTS upstream interface ifType 129 and the DOCSIS 2.0 ifType 205 that are functional. In other words, interfaces that represent upstream receivers within an RF MAC interface. Entries of physical interfaces are exposed to the management interface with their corresponding ifStack hierarchy and are not administratively created by this table. Raftus & Cardona Standards Track [Page 33] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 o Upstream Temporary Interfaces: A fictitious interface created for the purpose of manipulating physical interface parameters offline, then validating prior to updating the target physical interface. In case of a reinitialization of the managed system, physical interfaces values persist while the temporary interfaces are not recreated. This mechanism helps to minimize service disruptions originating in situations where a group of interface parameter values need to be consistent with each other in SET operations. A temporary buffer (temporary interface) is provided to allow the CMTS to validate the parameters offline." INDEX { ifIndex } ::= { docsIfUpstreamChannelTable 1 } DocsIfUpstreamChannelEntry ::= SEQUENCE { docsIfUpChannelId Integer32, docsIfUpChannelFrequency Integer32, docsIfUpChannelWidth Integer32, docsIfUpChannelModulationProfile Unsigned32, docsIfUpChannelSlotSize Unsigned32, docsIfUpChannelTxTimingOffset Unsigned32, docsIfUpChannelRangingBackoffStart Integer32, docsIfUpChannelRangingBackoffEnd Integer32, docsIfUpChannelTxBackoffStart Integer32, docsIfUpChannelTxBackoffEnd Integer32, docsIfUpChannelScdmaActiveCodes Unsigned32, docsIfUpChannelScdmaCodesPerSlot Integer32, docsIfUpChannelScdmaFrameSize Unsigned32, docsIfUpChannelScdmaHoppingSeed Unsigned32, docsIfUpChannelType DocsisUpstreamType, docsIfUpChannelCloneFrom InterfaceIndexOrZero, docsIfUpChannelUpdate TruthValue, docsIfUpChannelStatus RowStatus, docsIfUpChannelPreEqEnable TruthValue } docsIfUpChannelId OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The CMTS identification of the upstream channel." ::= { docsIfUpstreamChannelEntry 1 } Raftus & Cardona Standards Track [Page 34] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfUpChannelFrequency OBJECT-TYPE SYNTAX Integer32 (0..1000000000) UNITS "hertz" MAX-ACCESS read-create STATUS current DESCRIPTION "The center of the frequency band associated with this upstream interface. This object returns 0 if the frequency is undefined or unknown. Minimum permitted upstream frequency is 5,000,000 Hz for current technology. See the associated conformance object for write conditions and limitations." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 4-2." ::= { docsIfUpstreamChannelEntry 2 } docsIfUpChannelWidth OBJECT-TYPE SYNTAX Integer32 (0..64000000) UNITS "hertz" MAX-ACCESS read-create STATUS current DESCRIPTION "The bandwidth of this upstream interface. This object returns 0 if the interface width is undefined or unknown. Minimum permitted interface width is currently 200,000 Hz. See the associated conformance object for write conditions and limitations." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 6-5." ::= { docsIfUpstreamChannelEntry 3 } docsIfUpChannelModulationProfile OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "An entry identical to the docsIfModIndex in the docsIfCmtsModulationTable that describes this channel. This channel is further instantiated there by a grouping of interval usage codes (IUCs) that, together, fully describe the channel modulation. This object returns 0 if the docsIfCmtsModulationTable entry does not exist or is empty. See the associated conformance object for write conditions and limitations. Raftus & Cardona Standards Track [Page 35] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Setting this object returns an 'inconsistentValue' error if the following conditions are not satisfied: 1. All the IUC entries in the selected modulation profile MUST have the same value of docsIfCmtsModChannelType. 2. All of the Modulation parameters in the selected modulation profile MUST be consistent with the other parameters in this docsIfUpstreamChannelEntry." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 8-19." ::= { docsIfUpstreamChannelEntry 4 } docsIfUpChannelSlotSize OBJECT-TYPE SYNTAX Unsigned32 UNITS "ticks" MAX-ACCESS read-create STATUS current DESCRIPTION "Applicable to TDMA and ATDMA channel types only. The number of 6.25 microsecond ticks in each upstream mini-slot. Returns zero if the value is undefined or unknown or in case of an SCDMA channel. See the associated conformance object for write conditions and limitations." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.1.2.4." ::= { docsIfUpstreamChannelEntry 5 } docsIfUpChannelTxTimingOffset OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, a measure of the current round trip time obtained from the ranging offset (initial ranging offset + ranging offset adjustments). At the CMTS, the maximum of timing offset, among all the CMs that are/were present on the channel, taking into account all ( initial + periodic ) timing offset corrections that were sent for each of the CMs. Generally, these measurements are positive, but if the measurements are negative, the value of this object is zero. Used for timing of CM upstream transmissions to ensure synchronized arrivals at the CMTS. Units are one 64th fraction of 6.25 microseconds." Raftus & Cardona Standards Track [Page 36] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.19." ::= { docsIfUpstreamChannelEntry 6 } docsIfUpChannelRangingBackoffStart OBJECT-TYPE SYNTAX Integer32 (0..16) MAX-ACCESS read-create STATUS current DESCRIPTION "The initial random backoff window to use when retrying Ranging Requests. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 8.3.4, and 9.4." ::= { docsIfUpstreamChannelEntry 7 } docsIfUpChannelRangingBackoffEnd OBJECT-TYPE SYNTAX Integer32 (0..16) MAX-ACCESS read-create STATUS current DESCRIPTION "The final random backoff window to use when retrying Ranging Requests. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.4, and 9.4." ::= { docsIfUpstreamChannelEntry 8 } docsIfUpChannelTxBackoffStart OBJECT-TYPE SYNTAX Integer32 (0..16) MAX-ACCESS read-create STATUS current DESCRIPTION "The initial random backoff window to use when retrying transmissions. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations." Raftus & Cardona Standards Track [Page 37] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.4, and 9.4." ::= { docsIfUpstreamChannelEntry 9 } docsIfUpChannelTxBackoffEnd OBJECT-TYPE SYNTAX Integer32 (0..16) MAX-ACCESS read-create STATUS current DESCRIPTION "The final random backoff window to use when retrying transmissions. Expressed as a power of 2. A value of 16 at the CMTS indicates that a proprietary adaptive retry mechanism is to be used. See the associated conformance object for write conditions and limitations." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.4, and 9.4." ::= { docsIfUpstreamChannelEntry 10 } docsIfUpChannelScdmaActiveCodes OBJECT-TYPE SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88 |90..96|98..100|102|104..106|108 |110..112|114..126|128) MAX-ACCESS read-create STATUS current DESCRIPTION "Applicable for SCDMA channel types only. Number of active codes. Returns zero for Non-SCDMA channel types. Note that legal values from 64..128 MUST be non-prime." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.11.2.1." ::= { docsIfUpstreamChannelEntry 11 } docsIfUpChannelScdmaCodesPerSlot OBJECT-TYPE SYNTAX Integer32(0 | 2..32) UNITS "codesperMinislots" MAX-ACCESS read-create STATUS current DESCRIPTION "Applicable for SCDMA channel types only. The number of SCDMA codes per mini-slot. Returns zero if the value is undefined or unknown or in Raftus & Cardona Standards Track [Page 38] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 case of a TDMA or ATDMA channel." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.11.2.1." ::= { docsIfUpstreamChannelEntry 12 } docsIfUpChannelScdmaFrameSize OBJECT-TYPE SYNTAX Unsigned32 (0..32) UNITS "spreadIntervals" MAX-ACCESS read-create STATUS current DESCRIPTION "Applicable for SCDMA channel types only. SCDMA Frame size in units of spreading intervals. This value returns zero for non-SCDMA Profiles." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.12." ::= { docsIfUpstreamChannelEntry 13 } docsIfUpChannelScdmaHoppingSeed OBJECT-TYPE SYNTAX Unsigned32 (0..32767) MAX-ACCESS read-create STATUS current DESCRIPTION "Applicable for SCDMA channel types only. 15-bit seed used for code hopping sequence initialization. Returns zero for non-SCDMA channel types. Setting this value to a value different than zero for non-SCDMA channel types returns the error 'wrongValue'." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.14.1." ::= { docsIfUpstreamChannelEntry 14 } docsIfUpChannelType OBJECT-TYPE SYNTAX DocsisUpstreamType MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the Upstream channel type. This object returns the value of docsIfCmtsModChannelType for the modulation profile selected in docsIfUpChannelModulationProfile for this row." REFERENCE Raftus & Cardona Standards Track [Page 39] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.1." ::= { docsIfUpstreamChannelEntry 15 } docsIfUpChannelCloneFrom OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the ifIndex value of the physical interface row entry whose parameters are to be adjusted. Upon setting this object to the ifIndex value of a physical interface, the following interface objects values are copied to this entry: docsIfUpChannelFrequency, docsIfUpChannelWidth, docsIfUpChannelModulationProfile, docsIfUpChannelSlotSize, docsIfUpChannelRangingBackoffStart, docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart, docsIfUpChannelTxBackoffEnd, docsIfUpChannelScdmaActiveCodes, docsIfUpChannelScdmaCodesPerSlot, docsIfUpChannelScdmaFrameSize, docsIfUpChannelScdmaHoppingSeed, docsIfUpChannelType, and docsIfUpChannelPreEqEnable Setting this object to the value of a non-existent or a temporary upstream interface returns the error 'wrongValue'. This object MUST contain a value of zero for physical interfaces entries. Setting this object in row entries that correspond to physical interfaces returns the error 'wrongValue'." ::= { docsIfUpstreamChannelEntry 16 } docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Used to perform the copy of adjusted parameters from the temporary interface entry to the physical interface indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET to 'true' of Raftus & Cardona Standards Track [Page 40] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 this object. A SET to 'true' fails and returns error 'commitFailed' if docsIfUpChannelStatus value is 'notInService', which means that the interface parameters values are not compatible with each other or have not been validated yet. Reading this object always returns 'false'." ::= { docsIfUpstreamChannelEntry 17 } docsIfUpChannelStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is only used for the creation of a temporary upstream row with the purpose of updating the parameters of a physical upstream channel entry. The following restrictions apply to this object: 1. This object is not writable for physical interfaces. 2. Temporary interface entries are only created by a SET of this object to createandWait(5). 3. ifAdminStatus from the Interface MIB RFC 2863 is used to take a physical upstream channel offline, to be consistent with DOCSIS 1.x operation, as indicated in RFC 2670. In addition, o ifAdminStatus 'down' is reflected in this object as 'notInService'. o ifOperStatus 'down' while ifAdminStatus 'up' is reflected in this object as 'notInservice'. 4. Temporary created rows MUST be set to 'active' with the purpose of validating upstream parameter consistency prior to transferring the parameters to the physical interface. Below is a mandatory procedure for adjusting the values of a physical interface: 1. Create a temporary interface entry through an SNMP SET using 'createAndWait'. At this point, the RowStatus reports 'notReady'. The Manager entity uses an ifIndex value outside the operational range of the physical interfaces for the creation of a temporary interface. 2. Set the docsIfUpChannelCloneFrom object to the ifIndex value of the physical row to update. Now docsIfUpChannelStatus reports 'notInService'. 3. Change the upstream parameters to the desired values in the temporary row. Raftus & Cardona Standards Track [Page 41] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 4. Validate that all parameters are consistent by setting docsIfUpChannelStatus to 'active'. A failure to set the RowStatus to 'active' returns the error 'commitFailed', which means the parameters are not compatible with the target physical interface. 5. With docsIfUpChannelStatus 'active', transfer the parameters to the target physical interface by setting the object docsIfUpChannelUpdate to 'true'. 6. Delete the temporary row by setting docsIfUpChannelStatus to 'destroy'." ::= { docsIfUpstreamChannelEntry 18 } docsIfUpChannelPreEqEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "At the CMTS, this object is used to enable or disable pre-equalization on the upstream channel represented by this table instance. At the CM, this object is read-only and reflects the status of pre-equalization as represented in the RNG-RSP. Pre-equalization is considered enabled at the CM if a RNG-RSP with pre-equalization data has been received at least once since the last mac reinitialization." DEFVAL {false} ::= { docsIfUpstreamChannelEntry 19 } -- The following table describes the attributes of each class of -- service. The entries in this table are referenced from the -- docsIfServiceEntries. They exist as a separate table in order to -- reduce redundant information in docsIfServiceTable. -- -- This table is implemented at both the CM and the CMTS. -- The CM need only maintain entries for the classes of service -- referenced by its docsIfCmServiceTable. -- docsIfQosProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfQosProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes the attributes for each class of service." ::= { docsIfBaseObjects 3 } docsIfQosProfileEntry OBJECT-TYPE SYNTAX DocsIfQosProfileEntry Raftus & Cardona Standards Track [Page 42] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes the attributes for a single class of service. If implemented as read-create in the Cable Modem Termination System, creation of entries in this table is controlled by the value of docsIfCmtsQosProfilePermissions. If implemented as read-only, entries are created based on information in REG-REQ MAC messages received from cable modems (for Cable Modem Termination System), or based on information extracted from the TFTP option file (for Cable Modem). In the Cable Modem Termination System, read-only entries are removed if no longer referenced by docsIfCmtsServiceTable. An entry in this table MUST not be removed while it is referenced by an entry in docsIfCmServiceTable (Cable Modem) or docsIfCmtsServiceTable (Cable Modem Termination System). An entry in this table SHOULD NOT be changeable while it is referenced by an entry in docsIfCmtsServiceTable. If this table is created automatically, there SHOULD only be a single entry for each Class of Service. Multiple entries with the same Class of Service parameters are NOT RECOMMENDED." INDEX { docsIfQosProfIndex } ::= { docsIfQosProfileTable 1 } DocsIfQosProfileEntry ::= SEQUENCE { docsIfQosProfIndex Integer32, docsIfQosProfPriority Integer32, docsIfQosProfMaxUpBandwidth Integer32, docsIfQosProfGuarUpBandwidth Integer32, docsIfQosProfMaxDownBandwidth Integer32, docsIfQosProfMaxTxBurst Integer32, -- deprecated docsIfQosProfBaselinePrivacy TruthValue, docsIfQosProfStatus RowStatus, docsIfQosProfMaxTransmitBurst Integer32, docsIfQosProfStorageType StorageType } docsIfQosProfIndex OBJECT-TYPE SYNTAX Integer32 (1..16383) Raftus & Cardona Standards Track [Page 43] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies an entry in the docsIfQosProfileTable." ::= { docsIfQosProfileEntry 1 } docsIfQosProfPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "A relative priority assigned to this service when allocating bandwidth. Zero indicates lowest priority and seven indicates highest priority. Interpretation of priority is device-specific. MUST NOT be changed while this row is active." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex C.1.1.4." DEFVAL { 0 } ::= { docsIfQosProfileEntry 2 } docsIfQosProfMaxUpBandwidth OBJECT-TYPE SYNTAX Integer32 (0..100000000) UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum upstream bandwidth, in bits per second, allowed for a service with this service class. Zero if there is no restriction of upstream bandwidth. MUST NOT be changed while this row is active." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex C.1.1.4." DEFVAL { 0 } ::= { docsIfQosProfileEntry 3 } docsIfQosProfGuarUpBandwidth OBJECT-TYPE SYNTAX Integer32 (0..100000000) UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum guaranteed upstream bandwidth, in bits per second, Raftus & Cardona Standards Track [Page 44] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 allowed for a service with this service class. MUST NOT be changed while this row is active." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex C.1.1.4." DEFVAL { 0 } ::= { docsIfQosProfileEntry 4 } docsIfQosProfMaxDownBandwidth OBJECT-TYPE SYNTAX Integer32 (0..100000000) UNITS "bits per second" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum downstream bandwidth, in bits per second, allowed for a service with this service class. Zero if there is no restriction of downstream bandwidth. MUST NOT be changed while this row is active." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex C.1.1.4." DEFVAL { 0 } ::= { docsIfQosProfileEntry 5 } docsIfQosProfMaxTxBurst OBJECT-TYPE SYNTAX Integer32 (0..255) UNITS "mini-slots" MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The maximum number of mini-slots that may be requested for a single upstream transmission. A value of zero means there is no limit. MUST NOT be changed while this row is active. This object has been deprecated and replaced by docsIfQosProfMaxTransmitBurst, to fix a mismatch of the units and value range with respect to the DOCSIS Maximum Upstream Channel Transmit Burst Configuration Setting." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, C.1.1.4." DEFVAL { 0 } ::= { docsIfQosProfileEntry 6 } Raftus & Cardona Standards Track [Page 45] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfQosProfBaselinePrivacy OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether Baseline Privacy is enabled for this service class. MUST NOT be changed while this row is active." DEFVAL { false } ::= { docsIfQosProfileEntry 7 } docsIfQosProfStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This is object is used to create or delete rows in this table. This object MUST NOT be changed from active while the row is referenced by any entry in either docsIfCmServiceTable (on the CM) or docsIfCmtsServiceTable (on the CMTS)." ::= { docsIfQosProfileEntry 8 } docsIfQosProfMaxTransmitBurst OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of bytes that may be requested for a single upstream transmission. A value of zero means there is no limit. Note: This value does not include any physical layer overhead. MUST NOT be changed while this row is active." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex C.1.1.4." DEFVAL { 0 } ::= { docsIfQosProfileEntry 9 } docsIfQosProfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this conceptual row. Entries with this object set to permanent(4) Raftus & Cardona Standards Track [Page 46] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 do not require write operations for writable objects." ::= { docsIfQosProfileEntry 10 } docsIfSignalQualityTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfSignalQualityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "At the CM, describes the PHY signal quality of downstream channels. At the CMTS, this object describes the PHY signal quality of upstream channels. At the CMTS, this table MAY exclude contention intervals." ::= { docsIfBaseObjects 4 } docsIfSignalQualityEntry OBJECT-TYPE SYNTAX DocsIfSignalQualityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "At the CM, this object describes the PHY characteristics of a downstream channel. At the CMTS, it describes the PHY signal quality of an upstream channel. An entry in this table exists for each ifEntry with an ifType of docsCableDownstream(128) for Cable Modems. For DOCSIS 1.1 Cable Modem Termination Systems, an entry exists for each ifEntry with an ifType of docsCableUpstream (129). For DOCSIS 2.0 Cable Modem Termination Systems, an entry exists for each ifEntry with an ifType of docsCableUpstreamChannel (205)." INDEX { ifIndex } ::= { docsIfSignalQualityTable 1 } DocsIfSignalQualityEntry ::= SEQUENCE { docsIfSigQIncludesContention TruthValue, docsIfSigQUnerroreds Counter32, docsIfSigQCorrecteds Counter32, docsIfSigQUncorrectables Counter32, docsIfSigQSignalNoise TenthdB, docsIfSigQMicroreflections Integer32, docsIfSigQEqualizationData DocsEqualizerData, docsIfSigQExtUnerroreds Counter64, docsIfSigQExtCorrecteds Counter64, docsIfSigQExtUncorrectables Counter64 } docsIfSigQIncludesContention OBJECT-TYPE Raftus & Cardona Standards Track [Page 47] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1) if this CMTS includes contention intervals in the counters in this table. Always false(2) for CMs." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4.1" ::= { docsIfSignalQualityEntry 1 } docsIfSigQUnerroreds OBJECT-TYPE SYNTAX Counter32 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received on this channel without error. This includes all codewords, whether or not they were part of frames destined for this device. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 6.2.4, and 6.3.6." ::= { docsIfSignalQualityEntry 2 } docsIfSigQCorrecteds OBJECT-TYPE SYNTAX Counter32 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received on this channel with correctable errors. This includes all codewords, whether or not they were part of frames destined for this device. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 6.2.4, and 6.3.6." Raftus & Cardona Standards Track [Page 48] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ::= { docsIfSignalQualityEntry 3 } docsIfSigQUncorrectables OBJECT-TYPE SYNTAX Counter32 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received on this channel with uncorrectable errors. This includes all codewords, whether or not they were part of frames destined for this device. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 6.2.4, and 6.3.6." ::= { docsIfSignalQualityEntry 4 } docsIfSigQSignalNoise OBJECT-TYPE SYNTAX TenthdB UNITS "TenthdB" MAX-ACCESS read-only STATUS current DESCRIPTION "Signal/Noise ratio as perceived for this channel. At the CM, this object describes the Signal/Noise of the downstream channel. At the CMTS, it describes the average Signal/Noise of the upstream channel." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 4-1 and 4-2" ::= { docsIfSignalQualityEntry 5 } docsIfSigQMicroreflections OBJECT-TYPE SYNTAX Integer32 (0..255) UNITS "-dBc" MAX-ACCESS read-only STATUS current DESCRIPTION "Microreflections, including in-channel response as perceived on this interface, measured in dBc below the signal level. This object is not assumed to return an absolutely accurate value, but it gives a rough indication Raftus & Cardona Standards Track [Page 49] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 of microreflections received on this interface. It is up to the implementer to provide information as accurately as possible." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 4-1 and 4-2" ::= { docsIfSignalQualityEntry 6 } docsIfSigQEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "At the CM, this object returns the equalization data for the downstream channel. At the CMTS, this object is not applicable and is not instantiated. Note that previous CMTS implementations may instantiate this object in two ways: - An equalization value indicating an equalization average for the upstream channel. Those values have vendor-dependent interpretations. - Return a zero-length OCTET STRING to indicate that the value is unknown or if there is no equalization data available or defined." REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 6-23." ::= { docsIfSignalQualityEntry 7 } docsIfSigQExtUnerroreds OBJECT-TYPE SYNTAX Counter64 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received on this channel without error. This includes all codewords, whether or not they were part of frames destined for this device. This is the 64-bit version of docsIfSigQUnerroreds. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Raftus & Cardona Standards Track [Page 50] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 6.2.4, and 6.3.6." ::= { docsIfSignalQualityEntry 8 } docsIfSigQExtCorrecteds OBJECT-TYPE SYNTAX Counter64 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received on this channel with correctable errors. This includes all codewords, whether or not they were part of frames destined for this device. This is the 64-bit version of docsIfSigQCorrecteds. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 6.2.4, and 6.3.6." ::= { docsIfSignalQualityEntry 9 } docsIfSigQExtUncorrectables OBJECT-TYPE SYNTAX Counter64 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received on this channel with uncorrectable errors. This includes all codewords, whether or not they were part of frames destined for this device. This is the 64-bit version of docsIfSigQUncorrectables. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Sections 6.2.4, 6.3.6." ::= { docsIfSignalQualityEntry 10 } -- -- DOCSIS Version of the device -- Raftus & Cardona Standards Track [Page 51] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfDocsisBaseCapability OBJECT-TYPE SYNTAX DocsisVersion MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of the DOCSIS capability of the device." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex G." ::= { docsIfBaseObjects 5 } -- -- CABLE MODEM GROUP -- -- -- The CM MAC Table -- docsIfCmMacTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmMacEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes the attributes of each CM MAC interface, extending the information available from ifEntry." ::= { docsIfCmObjects 1 } docsIfCmMacEntry OBJECT-TYPE SYNTAX DocsIfCmMacEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing objects describing attributes of each MAC entry, extending the information in ifEntry. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsIfCmMacTable 1 } DocsIfCmMacEntry ::= SEQUENCE { docsIfCmCmtsAddress MacAddress, docsIfCmCapabilities BITS, docsIfCmRangingRespTimeout TimeTicks, docsIfCmRangingTimeout TimeInterval } Raftus & Cardona Standards Track [Page 52] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmCmtsAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the CMTS that is believed to control this MAC domain. At the CM, this will be the source address from SYNC, MAP, and other MAC-layer messages. If the CMTS is unknown, returns 00-00-00-00-00-00." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.2.2." ::= { docsIfCmMacEntry 1 } docsIfCmCapabilities OBJECT-TYPE SYNTAX BITS { atmCells(0), concatenation(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the capabilities of the MAC implementation at this interface. Note that packet transmission is always supported. Therefore, there is no specific bit required to explicitly indicate this capability. Note that BITS objects are encoded most significant bit first. For example, if bit 1 is set, the value of this object is the octet string '40'H." ::= { docsIfCmMacEntry 2 } docsIfCmRangingRespTimeout OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS obsolete DESCRIPTION "Waiting time for a Ranging Response packet. This object has been obsoleted and replaced by docsIfCmRangingTimeout to correct the typing to TimeInterval." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.1.6." DEFVAL { 20 } ::= { docsIfCmMacEntry 3 } Raftus & Cardona Standards Track [Page 53] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmRangingTimeout OBJECT-TYPE SYNTAX TimeInterval UNITS "HundredOfSeconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Waiting time for a Ranging Response packet. This object MUST NOT persist at reinitialization of the managed system." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.1.6, timer T3." DEFVAL { 20 } ::= { docsIfCmMacEntry 4 } -- -- CM status table. -- This table is implemented only at the CM. -- docsIfCmStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maintains a number of status objects and counters for Cable Modems." ::= { docsIfCmObjects 2 } docsIfCmStatusEntry OBJECT-TYPE SYNTAX DocsIfCmStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of status objects and counters for a single MAC layer instance in Cable Modem. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsIfCmStatusTable 1 } DocsIfCmStatusEntry ::= SEQUENCE { docsIfCmStatusValue INTEGER, docsIfCmStatusCode OCTET STRING, docsIfCmStatusTxPower TenthdBmV, docsIfCmStatusResets Counter32, docsIfCmStatusLostSyncs Counter32, Raftus & Cardona Standards Track [Page 54] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmStatusInvalidMaps Counter32, docsIfCmStatusInvalidUcds Counter32, docsIfCmStatusInvalidRangingResponses Counter32, docsIfCmStatusInvalidRegistrationResponses Counter32, docsIfCmStatusT1Timeouts Counter32, docsIfCmStatusT2Timeouts Counter32, docsIfCmStatusT3Timeouts Counter32, docsIfCmStatusT4Timeouts Counter32, docsIfCmStatusRangingAborteds Counter32, docsIfCmStatusDocsisOperMode DocsisQosVersion, docsIfCmStatusModulationType DocsisUpstreamType, docsIfCmStatusEqualizationData DocsEqualizerData, docsIfCmStatusUCCs Counter32, docsIfCmStatusUCCFails Counter32 } docsIfCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), notReady(2), notSynchronized(3), phySynchronized(4), usParametersAcquired(5), rangingComplete(6), ipComplete(7), todEstablished(8), securityEstablished(9), paramTransferComplete(10), registrationComplete(11), operational(12), accessDenied(13) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current Cable Modem connectivity state, as specified in the RF Interface Specification. Interpretations for state values 1-12 are clearly outlined in the SP-RFI reference given below. The state value accessDenied(13) indicates the CMTS has sent a Registration Aborted message to the CM. The same state is reported as accessDenied(7) by the CMTS object docsIfCmtsCmStatusValue." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 11.2. Data-Over-Cable Service Interface Specifications: Raftus & Cardona Standards Track [Page 55] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Operations Support System Interface Specification SP-OSSIv2.0-I09-050812, Section 6.3.4.2." ::= { docsIfCmStatusEntry 1 } docsIfCmStatusCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE( 0 | 5 | 6 )) MAX-ACCESS read-only STATUS current DESCRIPTION "Status code for a Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal. An example of a returned value could be 'T101.0'. The zero-length OCTET STRING indicates no status code yet registered." REFERENCE "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I09-050812, Annex D." ::= { docsIfCmStatusEntry 2 } docsIfCmStatusTxPower OBJECT-TYPE SYNTAX TenthdBmV UNITS "TenthdBmV" MAX-ACCESS read-only STATUS current DESCRIPTION "The operational transmit power for the attached upstream channel." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.18." ::= { docsIfCmStatusEntry 3 } docsIfCmStatusResets OBJECT-TYPE SYNTAX Counter32 UNITS "resets" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the CM reset or initialized this interface. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other Raftus & Cardona Standards Track [Page 56] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmStatusEntry 4 } docsIfCmStatusLostSyncs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the CM lost synchronization with the downstream channel. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.2." ::= { docsIfCmStatusEntry 5 } docsIfCmStatusInvalidMaps OBJECT-TYPE SYNTAX Counter32 UNITS "maps" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the CM received invalid MAP messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.4." ::= { docsIfCmStatusEntry 6 } docsIfCmStatusInvalidUcds OBJECT-TYPE SYNTAX Counter32 UNITS "messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the CM received invalid UCD messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of Raftus & Cardona Standards Track [Page 57] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.3." ::= { docsIfCmStatusEntry 7 } docsIfCmStatusInvalidRangingResponses OBJECT-TYPE SYNTAX Counter32 UNITS "messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the CM received invalid ranging response messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.6." ::= { docsIfCmStatusEntry 8 } docsIfCmStatusInvalidRegistrationResponses OBJECT-TYPE SYNTAX Counter32 UNITS "messages" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the CM received invalid registration response messages. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.8." ::= { docsIfCmStatusEntry 9 } docsIfCmStatusT1Timeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current Raftus & Cardona Standards Track [Page 58] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "Number of times counter T1 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 9-2." ::= { docsIfCmStatusEntry 10 } docsIfCmStatusT2Timeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times counter T2 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 9-2." ::= { docsIfCmStatusEntry 11 } docsIfCmStatusT3Timeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times counter T3 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 9-2." ::= { docsIfCmStatusEntry 12 } docsIfCmStatusT4Timeouts OBJECT-TYPE SYNTAX Counter32 Raftus & Cardona Standards Track [Page 59] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times counter T4 expired in the CM. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 9-2." ::= { docsIfCmStatusEntry 13 } docsIfCmStatusRangingAborteds OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the ranging process was aborted by the CMTS. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.3.3." ::= { docsIfCmStatusEntry 14 } docsIfCmStatusDocsisOperMode OBJECT-TYPE SYNTAX DocsisQosVersion MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether the device has registered using 1.0 Class of Service or 1.1 Quality of Service. An unregistered CM SHOULD indicate 'docsis11' for a docsIfDocsisBaseCapability value of DOCSIS 1.1/2.0. An unregistered CM SHOULD indicate 'docsis10' for a docsIfDocsisBaseCapability value of DOCSIS 1.0." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex G." Raftus & Cardona Standards Track [Page 60] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ::= { docsIfCmStatusEntry 15 } docsIfCmStatusModulationType OBJECT-TYPE SYNTAX DocsisUpstreamType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates modulation type status currently used by the CM. Since this object specifically identifies PHY mode, the shared upstream channel type is not permitted." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.1." ::= { docsIfCmStatusEntry 16 } docsIfCmStatusEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "Pre-equalization data for this CM after convolution with data indicated in the RNG-RSP. This data is valid when docsIfUpChannelPreEqEnable is set to true." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 8-23." ::= { docsIfCmStatusEntry 17 } docsIfCmStatusUCCs OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Upstream Channel Change transactions. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmStatusEntry 18 } docsIfCmStatusUCCFails OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" Raftus & Cardona Standards Track [Page 61] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Upstream Channel Change transactions. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmStatusEntry 19 } -- -- The Cable Modem Service Table -- docsIfCmServiceTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmServiceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes the attributes of each upstream service queue on a CM." ::= { docsIfCmObjects 3 } docsIfCmServiceEntry OBJECT-TYPE SYNTAX DocsIfCmServiceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes the attributes of an upstream bandwidth service queue. An entry in this table exists for each Service ID. The primary index is an ifIndex with an ifType of docsCableMaclayer(127)." INDEX { ifIndex, docsIfCmServiceId } ::= { docsIfCmServiceTable 1 } DocsIfCmServiceEntry ::= SEQUENCE { docsIfCmServiceId Integer32, docsIfCmServiceQosProfile Integer32, docsIfCmServiceTxSlotsImmed Counter32, docsIfCmServiceTxSlotsDed Counter32, docsIfCmServiceTxRetries Counter32, docsIfCmServiceTxExceededs Counter32, docsIfCmServiceRqRetries Counter32, docsIfCmServiceRqExceededs Counter32, docsIfCmServiceExtTxSlotsImmed Counter64, docsIfCmServiceExtTxSlotsDed Counter64 Raftus & Cardona Standards Track [Page 62] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 } docsIfCmServiceId OBJECT-TYPE SYNTAX Integer32 (1..16383) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies a service queue for upstream bandwidth. The attributes of this service queue are shared between the CM and the CMTS. The CMTS allocates upstream bandwidth to this service queue based on requests from the CM and on the class of service associated with this queue." ::= { docsIfCmServiceEntry 1 } docsIfCmServiceQosProfile OBJECT-TYPE SYNTAX Integer32 (0..16383) MAX-ACCESS read-only STATUS current DESCRIPTION "The index in docsIfQosProfileTable describing the quality of service attributes associated with this particular service. If no associated entry in docsIfQosProfileTable exists, this object returns a value of zero." ::= { docsIfCmServiceEntry 2 } docsIfCmServiceTxSlotsImmed OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of upstream mini-slots that have been used to transmit data PDUs in immediate (contention) mode. This includes only those PDUs that are presumed to have arrived at the head-end (i.e., those that were explicitly acknowledged). It does not include retransmission attempts or mini-slots used by requests. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 3 } docsIfCmServiceTxSlotsDed OBJECT-TYPE Raftus & Cardona Standards Track [Page 63] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of upstream mini-slots that have been used to transmit data PDUs in dedicated mode (i.e., as a result of a unicast Data Grant). Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 4 } docsIfCmServiceTxRetries OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of attempts to transmit data PDUs containing requests for acknowledgment that did not result in acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 5 } docsIfCmServiceTxExceededs OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of data PDU transmission failures due to excessive retries without acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of Raftus & Cardona Standards Track [Page 64] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 6 } docsIfCmServiceRqRetries OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of attempts to transmit bandwidth requests that did not result in acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 7 } docsIfCmServiceRqExceededs OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of requests for bandwidth that failed due to excessive retries without acknowledgment. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 8 } docsIfCmServiceExtTxSlotsImmed OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current Raftus & Cardona Standards Track [Page 65] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "The number of upstream mini-slots that have been used to transmit data PDUs in immediate (contention) mode. This includes only those PDUs that are presumed to have arrived at the head-end (i.e., those that were explicitly acknowledged). It does not include retransmission attempts or mini-slots used by requests. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 9 } docsIfCmServiceExtTxSlotsDed OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of upstream mini-slots that have been used to transmit data PDUs in dedicated mode (i.e., as a result of a unicast Data Grant). Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.4." ::= { docsIfCmServiceEntry 10 } -- -- CMTS GROUP -- -- -- The CMTS MAC Table -- docsIfCmtsMacTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsMacEntry MAX-ACCESS not-accessible STATUS current Raftus & Cardona Standards Track [Page 66] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "Describes the attributes of each CMTS MAC interface, extending the information available from ifEntry. Mandatory for all CMTS devices." ::= { docsIfCmtsObjects 1 } docsIfCmtsMacEntry OBJECT-TYPE SYNTAX DocsIfCmtsMacEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing objects describing attributes of each MAC entry, extending the information in ifEntry. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsIfCmtsMacTable 1 } DocsIfCmtsMacEntry ::= SEQUENCE { docsIfCmtsCapabilities BITS, docsIfCmtsSyncInterval Integer32, docsIfCmtsUcdInterval Integer32, docsIfCmtsMaxServiceIds Integer32, docsIfCmtsInsertionInterval TimeTicks, -- Obsolete docsIfCmtsInvitedRangingAttempts Integer32, docsIfCmtsInsertInterval TimeInterval, docsIfCmtsMacStorageType StorageType } docsIfCmtsCapabilities OBJECT-TYPE SYNTAX BITS { atmCells(0), concatenation(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the capabilities of the CMTS MAC implementation at this interface. Note that packet transmission is always supported. Therefore, there is no specific bit required to explicitly indicate this capability. Note that BITS objects are encoded most significant bit first. For example, if bit 1 is set, the value of this object is the octet string '40'H." ::= { docsIfCmtsMacEntry 1 } docsIfCmtsSyncInterval OBJECT-TYPE Raftus & Cardona Standards Track [Page 67] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 SYNTAX Integer32 (1..200) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The interval between CMTS transmission of successive SYNC messages at this interface." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.3." ::= { docsIfCmtsMacEntry 2 } docsIfCmtsUcdInterval OBJECT-TYPE SYNTAX Integer32 (1..2000) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The interval between CMTS transmission of successive Upstream Channel Descriptor messages for each upstream channel at this interface." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.3" ::= { docsIfCmtsMacEntry 3 } docsIfCmtsMaxServiceIds OBJECT-TYPE SYNTAX Integer32 (1..16383) UNITS "SIDs" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of service IDs that may be simultaneously active." ::= { docsIfCmtsMacEntry 4 } docsIfCmtsInsertionInterval OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS obsolete DESCRIPTION "The amount of time to elapse between each broadcast initial maintenance grant. Broadcast initial maintenance grants are used to allow new cable modems to join the network. Zero indicates that a vendor-specific algorithm is used instead of a fixed time. The maximum amount of Raftus & Cardona Standards Track [Page 68] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 time permitted by the specification is 2 seconds. This object has been obsoleted and replaced by docsIfCmtsInsertInterval to fix a SYNTAX typing problem." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex B." ::= { docsIfCmtsMacEntry 5 } docsIfCmtsInvitedRangingAttempts OBJECT-TYPE SYNTAX Integer32 (0..1024) UNITS "attempts" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of attempts to make on invitations for ranging requests. A value of zero means the system SHOULD attempt to range forever." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 9.3.3 and Annex B." ::= { docsIfCmtsMacEntry 6 } docsIfCmtsInsertInterval OBJECT-TYPE SYNTAX TimeInterval UNITS "HundredOfSeconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time to elapse between each broadcast initial maintenance grant. Broadcast initial maintenance grants are used to allow new cable modems to join the network. Zero indicates that a vendor-specific algorithm is used instead of a fixed time. The maximum amount of time permitted by the specification is 2 seconds." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex B." ::= { docsIfCmtsMacEntry 7 } docsIfCmtsMacStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this conceptual row. Raftus & Cardona Standards Track [Page 69] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Entries with this object set to permanent(4) do not require write operations for read-write objects." ::= { docsIfCmtsMacEntry 8 } -- -- -- CMTS status table. -- docsIfCmtsStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "For the MAC layer, this group maintains a number of status objects and counters." ::= { docsIfCmtsObjects 2 } docsIfCmtsStatusEntry OBJECT-TYPE SYNTAX DocsIfCmtsStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status entry for a single MAC layer. An entry in this table exists for each ifEntry with an ifType of docsCableMaclayer(127)." INDEX { ifIndex } ::= { docsIfCmtsStatusTable 1 } DocsIfCmtsStatusEntry ::= SEQUENCE { docsIfCmtsStatusInvalidRangeReqs Counter32, docsIfCmtsStatusRangingAborteds Counter32, docsIfCmtsStatusInvalidRegReqs Counter32, docsIfCmtsStatusFailedRegReqs Counter32, docsIfCmtsStatusInvalidDataReqs Counter32, docsIfCmtsStatusT5Timeouts Counter32 } docsIfCmtsStatusInvalidRangeReqs OBJECT-TYPE SYNTAX Counter32 UNITS "messages" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts invalid RNG-REQ messages received on this interface. Discontinuities in the value of this counter can occur Raftus & Cardona Standards Track [Page 70] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.5." ::= { docsIfCmtsStatusEntry 1 } docsIfCmtsStatusRangingAborteds OBJECT-TYPE SYNTAX Counter32 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts ranging attempts that were explicitly aborted by the CMTS. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.6." ::= { docsIfCmtsStatusEntry 2 } docsIfCmtsStatusInvalidRegReqs OBJECT-TYPE SYNTAX Counter32 UNITS "messages" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts invalid REG-REQ messages received on this interface; that is, syntax, out of range parameters, or erroneous requests. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.7." ::= { docsIfCmtsStatusEntry 3 } docsIfCmtsStatusFailedRegReqs OBJECT-TYPE SYNTAX Counter32 Raftus & Cardona Standards Track [Page 71] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 UNITS "attempts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts failed registration attempts. Included are docsIfCmtsStatusInvalidRegReqs, authentication, and class of service failures. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.3.7." ::= { docsIfCmtsStatusEntry 4 } docsIfCmtsStatusInvalidDataReqs OBJECT-TYPE SYNTAX Counter32 UNITS "messages" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts invalid data request messages received on this interface. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsStatusEntry 5 } docsIfCmtsStatusT5Timeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of times counter T5 expired on this interface. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 9-2." ::= { docsIfCmtsStatusEntry 6 } Raftus & Cardona Standards Track [Page 72] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 -- -- CM status table (within CMTS). -- This table is implemented only at the CMTS. -- It contains per-CM status information available in the CMTS. -- docsIfCmtsCmStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsCmStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects in the CMTS, maintained for each cable modem connected to this CMTS." ::= { docsIfCmtsObjects 3 } docsIfCmtsCmStatusEntry OBJECT-TYPE SYNTAX DocsIfCmtsCmStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status information for a single cable modem. An entry in this table exists for each cable modem that is connected to the CMTS implementing this table." INDEX { docsIfCmtsCmStatusIndex } ::= { docsIfCmtsCmStatusTable 1 } DocsIfCmtsCmStatusEntry ::= SEQUENCE { docsIfCmtsCmStatusIndex Integer32, docsIfCmtsCmStatusMacAddress MacAddress, docsIfCmtsCmStatusIpAddress IpAddress, -- deprecated docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero, docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero, docsIfCmtsCmStatusRxPower TenthdBmV, docsIfCmtsCmStatusTimingOffset Unsigned32, docsIfCmtsCmStatusEqualizationData DocsEqualizerData, docsIfCmtsCmStatusValue INTEGER, docsIfCmtsCmStatusUnerroreds Counter32, docsIfCmtsCmStatusCorrecteds Counter32, docsIfCmtsCmStatusUncorrectables Counter32, docsIfCmtsCmStatusSignalNoise TenthdB, docsIfCmtsCmStatusMicroreflections Integer32, docsIfCmtsCmStatusExtUnerroreds Counter64, docsIfCmtsCmStatusExtCorrecteds Counter64, docsIfCmtsCmStatusExtUncorrectables Counter64, docsIfCmtsCmStatusDocsisRegMode DocsisQosVersion, docsIfCmtsCmStatusModulationType DocsisUpstreamType, docsIfCmtsCmStatusInetAddressType InetAddressType, docsIfCmtsCmStatusInetAddress InetAddress, Raftus & Cardona Standards Track [Page 73] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsCmStatusValueLastUpdate TimeStamp, docsIfCmtsCmStatusHighResolutionTimingOffset Unsigned32 } docsIfCmtsCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index value to uniquely identify an entry in this table. For an individual cable modem, this index value SHOULD NOT change during CMTS uptime." ::= { docsIfCmtsCmStatusEntry 1 } docsIfCmtsCmStatusMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "MAC address of the cable modem. If the cable modem has multiple MAC addresses, this is the MAC address associated with the Cable interface." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 8.2.2." ::= { docsIfCmtsCmStatusEntry 2 } docsIfCmtsCmStatusIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "IP address of this cable modem. If the cable modem has no IP address assigned, or the IP address is unknown, this object returns a value of 0.0.0.0. If the cable modem has multiple IP addresses, this object returns the IP address associated with the Cable interface. This object has been deprecated and replaced by docsIfCmtsCmStatusInetAddressType and docsIfCmtsCmStatusInetAddress, to enable IPv6 addressing in the future." ::= { docsIfCmtsCmStatusEntry 3 } docsIfCmtsCmStatusDownChannelIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current Raftus & Cardona Standards Track [Page 74] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "IfIndex of the downstream channel that this CM is connected to. If the downstream channel is unknown, this object returns a value of zero." ::= { docsIfCmtsCmStatusEntry 4 } docsIfCmtsCmStatusUpChannelIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "For DOCSIS 2.0, indicates the ifIndex of the logical upstream channel (ifType 205) this CM is connected to. For DOCSIS 1.x, indicates the ifIndex of the upstream channel (ifType 129) this CM is connected to. If the upstream channel is unknown, this object returns a value of zero." ::= { docsIfCmtsCmStatusEntry 5 } docsIfCmtsCmStatusRxPower OBJECT-TYPE SYNTAX TenthdBmV UNITS "ThenthdBmV" MAX-ACCESS read-only STATUS current DESCRIPTION "The receive power as perceived for upstream data from this cable modem. If the receive power is unknown, this object returns a value of zero." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.18." ::= { docsIfCmtsCmStatusEntry 6 } docsIfCmtsCmStatusTimingOffset OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A measure of the current round trip time for this CM. Used for timing of CM upstream transmissions to ensure synchronized arrivals at the CMTS. Units are in terms of (6.25 microseconds/64). Returns zero if the value is unknown. For channels requiring finer resolution, please refer to object docsIfCmtsCmStatusHighResolutionTimingOffset." REFERENCE Raftus & Cardona Standards Track [Page 75] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.17." ::= { docsIfCmtsCmStatusEntry 7 } docsIfCmtsCmStatusEqualizationData OBJECT-TYPE SYNTAX DocsEqualizerData MAX-ACCESS read-only STATUS current DESCRIPTION "Equalization data for this CM, as measured by the CMTS. Returns the zero-length OCTET STRING if the value is unknown or if there is no equalization data available or defined." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Figure 8-23." ::= { docsIfCmtsCmStatusEntry 8 } docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- value 8 should not be used registeredBPIInitializing(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current cable modem connectivity state, as specified in the RF Interface Specification. Returned status information is the CM status, as assumed by the CMTS, and indicates the following events: other(1) Any state other than below. ranging(2) The CMTS has received an Initial Ranging Request message from the CM, and the ranging process is not yet complete. rangingAborted(3) The CMTS has sent a Ranging Abort message to the CM. Raftus & Cardona Standards Track [Page 76] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 rangingComplete(4) The CMTS has sent a Ranging Complete message to the CM. ipComplete(5) The CMTS has received a DHCP reply message and forwarded it to the CM. registrationComplete(6) The CMTS has sent a Registration Response message to the CM. accessDenied(7) The CMTS has sent a Registration Aborted message to the CM. operational(8) Value 8 is considered reserved and should not be defined in future revisions of this MIB module to avoid conflict with documented implementations that support value 8 to indicate operational state after completing the BPI initialization process. registeredBPIInitializing(9) Baseline Privacy (BPI) is enabled and the CMTS is in the process of completing BPI initialization. This state MAY last for a significant length of time if failures occur during the initialization process. After completion of BPI initialization, the CMTS will report registrationComplete(6). The CMTS only needs to report states it is able to detect." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 11.2." ::= { docsIfCmtsCmStatusEntry 9 } docsIfCmtsCmStatusUnerroreds OBJECT-TYPE SYNTAX Counter32 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received without error from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.4." ::= { docsIfCmtsCmStatusEntry 10 } Raftus & Cardona Standards Track [Page 77] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsCmStatusCorrecteds OBJECT-TYPE SYNTAX Counter32 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received with correctable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.4." ::= { docsIfCmtsCmStatusEntry 11 } docsIfCmtsCmStatusUncorrectables OBJECT-TYPE SYNTAX Counter32 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received with uncorrectable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.4." ::= { docsIfCmtsCmStatusEntry 12 } docsIfCmtsCmStatusSignalNoise OBJECT-TYPE SYNTAX TenthdB UNITS "TenthdB" MAX-ACCESS read-only STATUS current DESCRIPTION "Signal/Noise ratio as perceived for upstream data from this cable modem. If the Signal/Noise is unknown, this object returns a value of zero." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Raftus & Cardona Standards Track [Page 78] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 4-1 and 4-2." ::= { docsIfCmtsCmStatusEntry 13 } docsIfCmtsCmStatusMicroreflections OBJECT-TYPE SYNTAX Integer32 (0..255) UNITS "-dBc" MAX-ACCESS read-only STATUS current DESCRIPTION "Total microreflections, including in-channel response as perceived on this interface, measured in dBc below the signal level. This object is not assumed to return an absolutely accurate value, but it gives a rough indication of microreflections received on this interface. It is up to the implementer to provide information as accurately as possible. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 4-1 and 4-2" ::= { docsIfCmtsCmStatusEntry 14 } docsIfCmtsCmStatusExtUnerroreds OBJECT-TYPE SYNTAX Counter64 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received without error from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.5." ::= { docsIfCmtsCmStatusEntry 15 } docsIfCmtsCmStatusExtCorrecteds OBJECT-TYPE SYNTAX Counter64 UNITS "codewords" Raftus & Cardona Standards Track [Page 79] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received with correctable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.5." ::= { docsIfCmtsCmStatusEntry 16 } docsIfCmtsCmStatusExtUncorrectables OBJECT-TYPE SYNTAX Counter64 UNITS "codewords" MAX-ACCESS read-only STATUS current DESCRIPTION "Codewords received with uncorrectable errors from this cable modem. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.5." ::= { docsIfCmtsCmStatusEntry 17 } docsIfCmtsCmStatusDocsisRegMode OBJECT-TYPE SYNTAX DocsisQosVersion MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether the CM has registered using 1.0 Class of Service or 1.1 Quality of Service." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Annex G." ::= { docsIfCmtsCmStatusEntry 18 } docsIfCmtsCmStatusModulationType OBJECT-TYPE SYNTAX DocsisUpstreamType Raftus & Cardona Standards Track [Page 80] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates modulation type currently used by the CM. Since this object specifically identifies PHY mode, the shared type is not permitted. If the upstream channel is unknown, this object returns a value of zero." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 8-19." ::= { docsIfCmtsCmStatusEntry 19 } docsIfCmtsCmStatusInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of internet address of docsIfCmtsCmStatusInetAddress. If the cable modem internet address is unassigned or unknown, then the value of this object is unknown(0)." ::= { docsIfCmtsCmStatusEntry 20 } docsIfCmtsCmStatusInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Internet address of this cable modem. If the Cable Modem has no Internet address assigned, or the Internet address is unknown, the value of this object is the zero-length OCTET STRING. If the cable modem has multiple Internet addresses, this object returns the Internet address associated with the Cable (i.e., RF MAC) interface." ::= { docsIfCmtsCmStatusEntry 21 } docsIfCmtsCmStatusValueLastUpdate OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when docsIfCmtsCmStatusValue was last updated." ::= { docsIfCmtsCmStatusEntry 22 } docsIfCmtsCmStatusHighResolutionTimingOffset OBJECT-TYPE Raftus & Cardona Standards Track [Page 81] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A measure of the current round trip time for this CM. Used for timing of CM upstream transmissions to ensure synchronized arrivals at the CMTS. Units are in terms of (6.25 microseconds/(64*256)). Returns zero if the value is unknown. This is the high resolution version of object docsIfCmtsCmStatusTimingOffset, for channels requiring finer resolution." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Section 6.2.17." ::= { docsIfCmtsCmStatusEntry 23 } -- -- The CMTS Service Table. -- docsIfCmtsServiceTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsServiceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes the attributes of upstream service queues in a Cable Modem Termination System." ::= { docsIfCmtsObjects 4 } docsIfCmtsServiceEntry OBJECT-TYPE SYNTAX DocsIfCmtsServiceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes the attributes of a single upstream bandwidth service queue. Entries in this table exist for each ifEntry with an ifType of docsCableMaclayer(127), and for each service queue (Service ID) within this MAC layer. Entries in this table are created with the creation of individual Service IDs by the MAC layer and removed when a Service ID is removed." INDEX { ifIndex, docsIfCmtsServiceId } ::= { docsIfCmtsServiceTable 1 } DocsIfCmtsServiceEntry ::= SEQUENCE { Raftus & Cardona Standards Track [Page 82] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsServiceId Integer32, docsIfCmtsServiceCmStatusIndex Integer32, -- deprecated docsIfCmtsServiceAdminStatus INTEGER, docsIfCmtsServiceQosProfile Integer32, docsIfCmtsServiceCreateTime TimeStamp, docsIfCmtsServiceInOctets Counter32, docsIfCmtsServiceInPackets Counter32, docsIfCmtsServiceNewCmStatusIndex Integer32 } docsIfCmtsServiceId OBJECT-TYPE SYNTAX Integer32 (1..16383) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies a service queue for upstream bandwidth. The attributes of this service queue are shared between the Cable Modem and the Cable Modem Termination System. The CMTS allocates upstream bandwidth to this service queue based on requests from the CM and on the class of service associated with this queue." ::= { docsIfCmtsServiceEntry 1 } docsIfCmtsServiceCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Pointer to an entry in docsIfCmtsCmStatusTable identifying the cable modem using this Service Queue. If multiple cable modems are using this Service Queue, the value of this object is zero. This object has been deprecated and replaced by docsIfCmtsServiceNewCmStatusIndex, to fix a mismatch of the value range with respect to docsIfCmtsCmStatusIndex (1..2147483647)." ::= { docsIfCmtsServiceEntry 2 } docsIfCmtsServiceAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2), destroyed(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Allows a service class for a particular modem to be suppressed, (re-)enabled, or deleted altogether." Raftus & Cardona Standards Track [Page 83] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ::= { docsIfCmtsServiceEntry 3 } docsIfCmtsServiceQosProfile OBJECT-TYPE SYNTAX Integer32 (0..16383) MAX-ACCESS read-only STATUS current DESCRIPTION "The index in docsIfQosProfileTable describing the quality of service attributes associated with this particular service. If no associated docsIfQosProfileTable entry exists, this object returns a value of zero." ::= { docsIfCmtsServiceEntry 4 } docsIfCmtsServiceCreateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was created." ::= { docsIfCmtsServiceEntry 5 } docsIfCmtsServiceInOctets OBJECT-TYPE SYNTAX Counter32 UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The cumulative number of Packet Data octets received on this Service ID. The count does not include the size of the Cable MAC header. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsServiceEntry 6 } docsIfCmtsServiceInPackets OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The cumulative number of Packet Data packets received on this Service ID. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." Raftus & Cardona Standards Track [Page 84] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ::= { docsIfCmtsServiceEntry 7 } docsIfCmtsServiceNewCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Pointer (via docsIfCmtsCmStatusIndex) to an entry in docsIfCmtsCmStatusTable identifying the cable modem using this Service Queue. If multiple cable modems are using this Service Queue, the value of this object is zero." ::= { docsIfCmtsServiceEntry 8 } -- -- The following table provides upstream channel modulation profiles. -- Entries in this table can be -- re-used by one or more upstream channels. An upstream channel -- will have a modulation profile for each value of -- docsIfModIntervalUsageCode. -- docsIfCmtsModulationTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsModulationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a modulation profile associated with one or more upstream channels." ::= { docsIfCmtsObjects 5 } docsIfCmtsModulationEntry OBJECT-TYPE SYNTAX DocsIfCmtsModulationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a modulation profile for an Interval Usage Code for one or more upstream channels. Entries in this table are created by the operator. Initial default entries MAY be created at system initialization time, which could report a value of 'permanent' or 'readOnly' for docsIfCmtsModStorageType. A CMTS MAY reject the creation of additional Interval Usage Codes for a modulation profile being defined at Initialization time. No individual objects have to be specified in order to create an entry in this table. Raftus & Cardona Standards Track [Page 85] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Note that some objects do not have DEFVAL clauses but do have calculated defaults and need not be specified during row creation." INDEX { docsIfCmtsModIndex, docsIfCmtsModIntervalUsageCode} ::= { docsIfCmtsModulationTable 1 } DocsIfCmtsModulationEntry ::= SEQUENCE { docsIfCmtsModIndex Integer32, docsIfCmtsModIntervalUsageCode INTEGER, docsIfCmtsModControl RowStatus, docsIfCmtsModType INTEGER, docsIfCmtsModPreambleLen Integer32, docsIfCmtsModDifferentialEncoding TruthValue, docsIfCmtsModFECErrorCorrection Integer32, docsIfCmtsModFECCodewordLength Integer32, docsIfCmtsModScramblerSeed Integer32, docsIfCmtsModMaxBurstSize Integer32, docsIfCmtsModGuardTimeSize Unsigned32, docsIfCmtsModLastCodewordShortened TruthValue, docsIfCmtsModScrambler TruthValue, docsIfCmtsModByteInterleaverDepth Unsigned32, docsIfCmtsModByteInterleaverBlockSize Unsigned32, docsIfCmtsModPreambleType INTEGER, docsIfCmtsModTcmErrorCorrectionOn TruthValue, docsIfCmtsModScdmaInterleaverStepSize Unsigned32, docsIfCmtsModScdmaSpreaderEnable TruthValue, docsIfCmtsModScdmaSubframeCodes Unsigned32, docsIfCmtsModChannelType DocsisUpstreamType, docsIfCmtsModStorageType StorageType } docsIfCmtsModIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index into the Channel Modulation table representing a group of Interval Usage Codes, all associated with the same channel." ::= { docsIfCmtsModulationEntry 1 } docsIfCmtsModIntervalUsageCode OBJECT-TYPE SYNTAX INTEGER { request(1), requestData(2), initialRanging(3), periodicRanging(4), shortData(5), Raftus & Cardona Standards Track [Page 86] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 longData(6), advPhyShortData(9), advPhyLongData(10), ugs(11) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index into the Channel Modulation table that, when grouped with other Interval Usage Codes, fully instantiates all modulation sets for a given upstream channel." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 8-20." ::= { docsIfCmtsModulationEntry 2 } docsIfCmtsModControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Controls and reflects the status of rows in this table. There is no restriction on the changing of values in this table while their associated rows are active, with the exception of: 1. If a modulation profile is being referenced by one or more upstream channels, an attempt to set the value of docsIfCmtsModChannelType returns an 'inconsistentValue' error. 2. If a modulation profile is being referenced by one or more upstream channels, an attempt to set docsIfCmtsModControl to destroy(6) or notInService(2) returns an 'inconsistentValue' error." ::= { docsIfCmtsModulationEntry 3 } docsIfCmtsModType OBJECT-TYPE SYNTAX INTEGER { other(1), qpsk(2), qam16(3), qam8(4), qam32(5), qam64(6), qam128(7) Raftus & Cardona Standards Track [Page 87] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 } MAX-ACCESS read-create STATUS current DESCRIPTION "The modulation type used on this channel. Returns other(1) if the modulation type is not qpsk, qam16, qam8, qam32, qam64, or qam128. Type qam128 is used for SCDMA channels only. See the reference for the modulation profiles implied by different modulation types." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { qpsk } ::= { docsIfCmtsModulationEntry 4 } docsIfCmtsModPreambleLen OBJECT-TYPE SYNTAX Integer32 (0..1536) UNITS "bits" MAX-ACCESS read-create STATUS current DESCRIPTION "The preamble length for this modulation profile in bits. Default value is the minimum needed by the implementation at the CMTS for the given modulation profile." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." ::= { docsIfCmtsModulationEntry 5 } docsIfCmtsModDifferentialEncoding OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies whether or not differential encoding is used on this channel." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { false } ::= { docsIfCmtsModulationEntry 6 } docsIfCmtsModFECErrorCorrection OBJECT-TYPE SYNTAX Integer32 (0..16) Raftus & Cardona Standards Track [Page 88] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 UNITS "Bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of correctable errored bytes (t) used in forward error correction code. The value of 0 indicates that no correction is employed. The number of check bytes appended will be twice this value." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { 0 } ::= { docsIfCmtsModulationEntry 7 } docsIfCmtsModFECCodewordLength OBJECT-TYPE SYNTAX Integer32 (1..255) UNITS "Bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of data bytes (k) in the forward error correction codeword. This object is not used if docsIfCmtsModFECErrorCorrection is zero." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { 32 } ::= { docsIfCmtsModulationEntry 8 } docsIfCmtsModScramblerSeed OBJECT-TYPE SYNTAX Integer32 (0..32767) MAX-ACCESS read-create STATUS current DESCRIPTION "The 15-bit seed value for the scrambler polynomial." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 8-19." DEFVAL { 0 } ::= { docsIfCmtsModulationEntry 9 } docsIfCmtsModMaxBurstSize OBJECT-TYPE SYNTAX Integer32 (0..255) UNITS "mini-slots" Raftus & Cardona Standards Track [Page 89] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of mini-slots that can be transmitted during this channel's burst time. Returns zero if the burst length is bounded by the allocation MAP rather than by this profile. Default value is 0, except for shortData, where it is 8." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 8-19." ::= { docsIfCmtsModulationEntry 10 } docsIfCmtsModGuardTimeSize OBJECT-TYPE SYNTAX Unsigned32 UNITS "Symbol-times" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of symbol-times that MUST follow the end of this channel's burst. Default value is the minimum time needed by the implementation for this modulation profile." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." ::= { docsIfCmtsModulationEntry 11 } docsIfCmtsModLastCodewordShortened OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the last FEC codeword is truncated." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { true } ::= { docsIfCmtsModulationEntry 12 } docsIfCmtsModScrambler OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the scrambler is employed." Raftus & Cardona Standards Track [Page 90] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { false } ::= { docsIfCmtsModulationEntry 13 } docsIfCmtsModByteInterleaverDepth OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "ATDMA Byte Interleaver Depth (Ir). This object returns 1 for non-ATDMA profiles." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { 1 } ::= { docsIfCmtsModulationEntry 14 } docsIfCmtsModByteInterleaverBlockSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "ATDMA Byte Interleaver Block size (Br). This object returns zero for non-ATDMA profiles " REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { 18 } ::= { docsIfCmtsModulationEntry 15 } docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { unknown(0), qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts. The value 'unknown(0)' represents a row entry consisting only of DOCSIS 1.x bursts" REFERENCE Raftus & Cardona Standards Track [Page 91] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { qpsk0 } ::= { docsIfCmtsModulationEntry 16 } docsIfCmtsModTcmErrorCorrectionOn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Trellis Code Modulation (TCM) On/Off. This value returns false for non-S-CDMA profiles." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { false } ::= { docsIfCmtsModulationEntry 17 } docsIfCmtsModScdmaInterleaverStepSize OBJECT-TYPE SYNTAX Unsigned32 (0 | 1..32) MAX-ACCESS read-create STATUS current DESCRIPTION " S-CDMA Interleaver step size. This value returns zero for non-S-CDMA profiles." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." DEFVAL { 1 } ::= { docsIfCmtsModulationEntry 18 } docsIfCmtsModScdmaSpreaderEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION " S-CDMA spreader. This value returns false for non-S-CDMA profiles. Default value for IUC 3 and 4 is OFF; for all other IUCs it is ON." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Tables 6-7, and 8-19." ::= { docsIfCmtsModulationEntry 19 } Raftus & Cardona Standards Track [Page 92] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsModScdmaSubframeCodes OBJECT-TYPE SYNTAX Unsigned32 (0 | 1..128) MAX-ACCESS read-create STATUS current DESCRIPTION " S-CDMA sub-frame size. This value returns zero for non-S-CDMA profiles." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 6-7, and 8-19." DEFVAL { 1 } ::= { docsIfCmtsModulationEntry 20 } docsIfCmtsModChannelType OBJECT-TYPE SYNTAX DocsisUpstreamType MAX-ACCESS read-create STATUS current DESCRIPTION "Describes the modulation channel type for this modulation entry. All the active entries in a modulation profile (that is all active entries that share a common docsIfCmtsModIndex) MUST have the same value of docsIfCmtsModChannelType." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I10-051209, Table 8-19." DEFVAL { tdma } ::= { docsIfCmtsModulationEntry 21 } docsIfCmtsModStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this conceptual row. Entries with this object set to permanent(4) do not require write operations for read-write objects." DEFVAL { nonVolatile } ::= { docsIfCmtsModulationEntry 22 } docsIfCmtsQosProfilePermissions OBJECT-TYPE SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) Raftus & Cardona Standards Track [Page 93] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 } MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies permitted methods of creating entries in docsIfQosProfileTable. createByManagement(0) is set if entries can be created using SNMP. updateByManagement(1) is set if updating entries using SNMP is permitted. createByModems(2) is set if entries can be created based on information in REG-REQ MAC messages received from cable modems. Information in this object is only applicable if docsIfQosProfileTable is implemented as read-create. Otherwise, this object is implemented as read-only and returns createByModems(2). Either createByManagement(0) or updateByManagement(1) MUST be set when writing to this object. Note that BITS objects are encoded most significant bit first. For example, if bit 2 is set, the value of this object is the octet string '20'H." ::= { docsIfCmtsObjects 6 } docsIfCmtsMacToCmTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsMacToCmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a table to provide a quick access index into the docsIfCmtsCmStatusTable. There is exactly one row in this table for each row in the docsIfCmtsCmStatusTable. In general, the management station SHOULD use this table only to get a pointer into the docsIfCmtsCmStatusTable (which corresponds to the CM's RF interface MAC address) and SHOULD not iterate (e.g., GetNext through) this table." ::= { docsIfCmtsObjects 7 } docsIfCmtsMacToCmEntry OBJECT-TYPE SYNTAX DocsIfCmtsMacToCmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the docsIfCmtsMacToCmTable. An entry in this table exists for each cable modem that is connected to the CMTS implementing this table." INDEX { docsIfCmtsCmMac } ::= {docsIfCmtsMacToCmTable 1 } DocsIfCmtsMacToCmEntry ::= SEQUENCE { Raftus & Cardona Standards Track [Page 94] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsCmMac MacAddress, docsIfCmtsCmPtr Integer32 } docsIfCmtsCmMac OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RF side MAC address for the referenced CM (e.g., the interface on the CM that has docsCableMacLayer(127) as its ifType)." ::= { docsIfCmtsMacToCmEntry 1 } docsIfCmtsCmPtr OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An row index into docsIfCmtsCmStatusTable. When queried with the correct instance value (e.g., a CM's MAC address), returns the index in docsIfCmtsCmStatusTable that represents that CM." ::= { docsIfCmtsMacToCmEntry 2 } -- The following independent object and associated table provide -- operators with a mechanism to evaluate the load/utilization of -- both upstream and downstream physical channels. This information -- may be used for capacity planning and incident analysis and may -- be particularly helpful in provisioning of high value QOS. -- -- Utilization is expressed as an index representing the calculated -- percentage utilization of the upstream or downstream channel in -- the most recent sampling interval (i.e., utilization interval). -- Refer to the DESCRIPTION field of the -- docsIfCmtsChannelUtUtilization object for definitions and -- calculation details. docsIfCmtsChannelUtilizationInterval OBJECT-TYPE SYNTAX Integer32 (0..86400) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The time interval in seconds over which the channel utilization index is calculated. All upstream/downstream channels use the same docsIfCmtsChannelUtilizationInterval. Raftus & Cardona Standards Track [Page 95] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Setting a value of zero disables utilization reporting. A channel utilization index is calculated over a fixed window applying to the most recent docsIfCmtsChannelUtilizationInterval. It would therefore be prudent to use a relatively short docsIfCmtsChannelUtilizationInterval. It is a vendor decision whether to reset the timer when docsIfCmtsChannelUtilizationInterval is changed during a utilization sampling period." ::= { docsIfCmtsObjects 8 } docsIfCmtsChannelUtilizationTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsChannelUtilizationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Reports utilization statistics for attached upstream and downstream physical channels." ::= { docsIfCmtsObjects 9 } docsIfCmtsChannelUtilizationEntry OBJECT-TYPE SYNTAX DocsIfCmtsChannelUtilizationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Utilization statistics for a single upstream or downstream physical channel. An entry exists in this table for each ifEntry with an ifType equal to docsCableDownstream (128) or docsCableUpstream (129)." INDEX { ifIndex, docsIfCmtsChannelUtIfType, docsIfCmtsChannelUtId } ::= { docsIfCmtsChannelUtilizationTable 1 } DocsIfCmtsChannelUtilizationEntry ::= SEQUENCE { docsIfCmtsChannelUtIfType IANAifType, docsIfCmtsChannelUtId Integer32, docsIfCmtsChannelUtUtilization Integer32 } docsIfCmtsChannelUtIfType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The secondary index into this table. Indicates the IANA interface type associated with this physical channel. Only docsCableDownstream (128) and Raftus & Cardona Standards Track [Page 96] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsCableUpstream (129) are valid." ::= { docsIfCmtsChannelUtilizationEntry 1 } docsIfCmtsChannelUtId OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The tertiary index into this table. Indicates the CMTS identifier for this physical channel." ::= { docsIfCmtsChannelUtilizationEntry 2 } docsIfCmtsChannelUtUtilization OBJECT-TYPE SYNTAX Integer32 (0..100) UNITS "percent" MAX-ACCESS read-only STATUS current DESCRIPTION "The calculated and truncated utilization index for this physical upstream or downstream channel, accurate as of the most recent docsIfCmtsChannelUtilizationInterval. Upstream Channel Utilization Index: The upstream channel utilization index is expressed as a percentage of mini-slots utilized on the physical channel, regardless of burst type. For an Initial Maintenance region, the mini-slots for the complete region are considered utilized if the CMTS received an upstream burst within the region from any CM on the physical channel. For contention REQ and REQ/DATA regions, the mini-slots for a transmission opportunity within the region are considered utilized if the CMTS received an upstream burst within the opportunity from any CM on the physical channel. For all other regions, utilized mini-slots are those in which the CMTS granted bandwidth to any unicast SID on the physical channel. For an upstream interface that has multiple logical upstream channels enabled, the utilization index is a weighted sum of utilization indices for the logical channels. The weight for each utilization index is the percentage of upstream mini-slots allocated for the corresponding logical channel. Example: If 75% of bandwidth is allocated to the first logical channel and 25% to the second, and the utilization indices for each are 60 and 40, respectively, the Raftus & Cardona Standards Track [Page 97] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 utilization index for the upstream physical channel is (60 * 0.75) + (40 * 0.25) = 55. This figure applies to the most recent utilization interval. Downstream Channel Utilization Index: The downstream channel utilization index is a percentage expressing the ratio between bytes used to transmit data versus the total number of bytes transmitted in the raw bandwidth of the MPEG channel. As with the upstream utilization index, the calculated value represents the most recent utilization interval. Formula: Downstream utilization index = (100 * (data bytes / raw bytes)) Definitions: Data bytes: Number of bytes transmitted as data in the docsIfCmtsChannelUtilizationInterval. Identical to docsIfCmtsDownChannelCtrUsed Bytes measured over the utilization interval. Raw bandwidth: Total number of bytes available for transmitting data, not including bytes used for headers and other overhead. Raw bytes: (raw bandwidth * docsIfCmtsChannelUtilizationInterval). Identical to docsIfCmtsDownChannelCtrTotal Bytes measured over the utilization interval." ::= { docsIfCmtsChannelUtilizationEntry 3 } -- The following table provides operators with input data -- appropriate for calculating downstream channel utilization. -- Operators may use the docsIfCmtsChannelUtilizationTable or -- perform their own polling of the -- docsIfCmtsDownChannelCounterTable objects to characterize -- their downstream channel usage. The 32-bit counter objects are -- included to provide backward compatibility with SNMPv1 managers, -- which cannot access 64-bit counter objects. docsIfCmtsDownChannelCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsDownChannelCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is implemented at the CMTS to collect downstream channel statistics for utilization Raftus & Cardona Standards Track [Page 98] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 calculations." ::= { docsIfCmtsObjects 10 } docsIfCmtsDownChannelCounterEntry OBJECT-TYPE SYNTAX DocsIfCmtsDownChannelCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry provides a list of traffic counters for a single downstream channel. An entry in this table exists for each ifEntry with an ifType of docsCableDownstream(128)." INDEX { ifIndex } ::= { docsIfCmtsDownChannelCounterTable 1 } DocsIfCmtsDownChannelCounterEntry ::= SEQUENCE { docsIfCmtsDownChnlCtrId Integer32, docsIfCmtsDownChnlCtrTotalBytes Counter32, docsIfCmtsDownChnlCtrUsedBytes Counter32, docsIfCmtsDownChnlCtrExtTotalBytes Counter64, docsIfCmtsDownChnlCtrExtUsedBytes Counter64 } docsIfCmtsDownChnlCtrId OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The Cable Modem Termination System identification of the downstream channel within this particular MAC interface. If the interface is down, the object returns the most current value. If the downstream channel ID is unknown, this object returns a value of 0." ::= { docsIfCmtsDownChannelCounterEntry 1 } docsIfCmtsDownChnlCtrTotalBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "At the CMTS, the total number of bytes in the Payload portion of MPEG Packets (i.e., not including MPEG header or pointer_field) transported by this downstream channel. This is the 32-bit version of docsIfCmtsDownChnlCtrExtTotalBytes, included to provide back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur Raftus & Cardona Standards Track [Page 99] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsDownChannelCounterEntry 2 } docsIfCmtsDownChnlCtrUsedBytes OBJECT-TYPE SYNTAX Counter32 UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "At the CMTS, the total number of DOCSIS data bytes transported by this downstream channel. The number of data bytes is defined as the total number of bytes transported in DOCSIS payloads minus the number of stuff bytes transported in DOCSIS payloads. This is the 32-bit version of docsIfCmtsDownChnlCtrExtUsedBytes, included to provide back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsDownChannelCounterEntry 3 } docsIfCmtsDownChnlCtrExtTotalBytes OBJECT-TYPE SYNTAX Counter64 UNITS "Bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "At the CMTS, the total number of bytes in the Payload portion of MPEG Packets (i.e., not including MPEG header or pointer_field) transported by this downstream channel. This is the 64-bit version of docsIfCmtsDownChnlCtrTotalBytes and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsDownChannelCounterEntry 4 } docsIfCmtsDownChnlCtrExtUsedBytes OBJECT-TYPE SYNTAX Counter64 UNITS "Bytes" MAX-ACCESS read-only Raftus & Cardona Standards Track [Page 100] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 STATUS current DESCRIPTION "At the CMTS, the total number of DOCSIS data bytes transported by this downstream channel. The number of data bytes is defined as the total number of bytes transported in DOCSIS payloads minus the number of stuff bytes transported in DOCSIS payloads. This is the 64-bit version of docsIfCmtsDownChnlCtrUsedBytes and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsDownChannelCounterEntry 5 } -- The following table provides operators with input data appropriate -- for calculating upstream channel utilization, and for determining -- the traffic characteristics of upstream channels. Operators may -- use the docsIfCmtsChannelUtilizationTable or perform their own -- polling of the docsIfCmtsUpChannelCounterTable objects for -- utilization determination. -- The first four 32 and 64 objects in this table are mandatory. -- Vendors may choose to implement the remaining optional objects to -- provide operators with finer characterization of upstream channel -- traffic patterns. The 32-bit counter objects are included to -- provide backward compatibility with SNMPv1 managers, which cannot -- access 64-bit counter objects. docsIfCmtsUpChannelCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsIfCmtsUpChannelCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is implemented at the CMTS to provide upstream channel statistics appropriate for channel utilization calculations." ::= { docsIfCmtsObjects 11 } docsIfCmtsUpChannelCounterEntry OBJECT-TYPE SYNTAX DocsIfCmtsUpChannelCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of traffic statistics for a single upstream channel. For DOCSIS 2.0 CMTSs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstreamChannel (205). Raftus & Cardona Standards Track [Page 101] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 For DOCSIS 1.x CMTSs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstream (129)." INDEX { ifIndex } ::= { docsIfCmtsUpChannelCounterTable 1 } DocsIfCmtsUpChannelCounterEntry ::= SEQUENCE { docsIfCmtsUpChnlCtrId Integer32, docsIfCmtsUpChnlCtrTotalMslots Counter32, docsIfCmtsUpChnlCtrUcastGrantedMslots Counter32, docsIfCmtsUpChnlCtrTotalCntnMslots Counter32, docsIfCmtsUpChnlCtrUsedCntnMslots Counter32, docsIfCmtsUpChnlCtrExtTotalMslots Counter64, docsIfCmtsUpChnlCtrExtUcastGrantedMslots Counter64, docsIfCmtsUpChnlCtrExtTotalCntnMslots Counter64, docsIfCmtsUpChnlCtrExtUsedCntnMslots Counter64, docsIfCmtsUpChnlCtrCollCntnMslots Counter32, docsIfCmtsUpChnlCtrTotalCntnReqMslots Counter32, docsIfCmtsUpChnlCtrUsedCntnReqMslots Counter32, docsIfCmtsUpChnlCtrCollCntnReqMslots Counter32, docsIfCmtsUpChnlCtrTotalCntnReqDataMslots Counter32, docsIfCmtsUpChnlCtrUsedCntnReqDataMslots Counter32, docsIfCmtsUpChnlCtrCollCntnReqDataMslots Counter32, docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots Counter32, docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots Counter32, docsIfCmtsUpChnlCtrCollCntnInitMaintMslots Counter32, docsIfCmtsUpChnlCtrExtCollCntnMslots Counter64, docsIfCmtsUpChnlCtrExtTotalCntnReqMslots Counter64, docsIfCmtsUpChnlCtrExtUsedCntnReqMslots Counter64, docsIfCmtsUpChnlCtrExtCollCntnReqMslots Counter64, docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots Counter64, docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots Counter64, docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots Counter64, docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots Counter64, docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots Counter64, docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots Counter64 } docsIfCmtsUpChnlCtrId OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The CMTS identification of the upstream channel." ::= { docsIfCmtsUpChannelCounterEntry 1 } docsIfCmtsUpChnlCtrTotalMslots OBJECT-TYPE SYNTAX Counter32 Raftus & Cardona Standards Track [Page 102] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of all mini-slots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel that is inactive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalMslots and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 2 } docsIfCmtsUpChnlCtrUcastGrantedMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of unicast granted mini-slots on the upstream logical channel, regardless of burst type. Unicast granted mini-slots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However, this object does not include minis-lots for reserved IUCs, or grants to SIDs designated as meaning 'no CM'. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUcastGrantedMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 3 } docsIfCmtsUpChnlCtrTotalCntnMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention mini-slots defined for this upstream logical channel. This count includes all mini-slots assigned to a broadcast or Raftus & Cardona Standards Track [Page 103] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnMslots, and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 4 } docsIfCmtsUpChnlCtrUsedCntnMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention mini-slots utilized on the upstream logical channel. For contention regions, utilized mini-slots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnMslots and is included for back compatibility with SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 5 } docsIfCmtsUpChnlCtrExtTotalMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of all mini-slots defined for this upstream logical channel. This count includes all IUCs and SIDs, even those allocated to the NULL SID for a 2.0 logical channel that is inactive. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 6 } Raftus & Cardona Standards Track [Page 104] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsUpChnlCtrExtUcastGrantedMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of unicast granted mini-slots on the upstream logical channel, regardless of burst type. Unicast granted mini-slots are those in which the CMTS assigned bandwidth to any unicast SID on the logical channel. However, this object does not include mini-slots for reserved IUCs, or grants to SIDs designated as meaning 'no CM'. This is the 64-bit version of docsIfCmtsUpChnlCtrUcastGrantedMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 7 } docsIfCmtsUpChnlCtrExtTotalCntnMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention mini-slots defined for this upstream logical channel. This count includes all mini-slots assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 8 } docsIfCmtsUpChnlCtrExtUsedCntnMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention Raftus & Cardona Standards Track [Page 105] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 mini-slots utilized on the upstream logical channel. For contention regions, utilized mini-slots are those in which the CMTS correctly received an upstream burst from any CM on the upstream logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnMslots and will not be accessible to SNMPv1 managers. Support for this object is mandatory. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 9 } docsIfCmtsUpChnlCtrCollCntnMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention mini-slots subjected to collisions on the upstream logical channel. For contention regions, these are the mini-slots applicable to bursts that the CMTS detected but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 10 } docsIfCmtsUpChnlCtrTotalCntnReqMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of Raftus & Cardona Standards Track [Page 106] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 11 } docsIfCmtsUpChnlCtrUsedCntnReqMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request mini-slots utilized on this upstream logical channel. This count includes all contention mini-slots for IUC1 applicable to bursts that the CMTS correctly received. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnReqMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 12 } docsIfCmtsUpChnlCtrCollCntnReqMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC1 applicable to bursts that the CMTS detected but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnReqMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 13 } docsIfCmtsUpChnlCtrTotalCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention Raftus & Cardona Standards Track [Page 107] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 request data mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 14 } docsIfCmtsUpChnlCtrUsedCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS correctly received. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 15 } docsIfCmtsUpChnlCtrCollCntnReqDataMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of Raftus & Cardona Standards Track [Page 108] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 16 } docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance mini-slots defined for this upstream logical channel. This includes all mini-slots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 32-bit version of docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 17 } docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS correctly received. This is the 32-bit version of docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 18 } docsIfCmtsUpChnlCtrCollCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter32 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION Raftus & Cardona Standards Track [Page 109] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "Current count, from CMTS initialization, of contention initial maintenance mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 32-bit version of docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots and is included for back compatibility with SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 19 } docsIfCmtsUpChnlCtrExtCollCntnMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of collision contention mini-slots on the upstream logical channel. For contention regions, these are the mini-slots applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 20 } docsIfCmtsUpChnlCtrExtTotalCntnReqMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC1 assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnReqMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur Raftus & Cardona Standards Track [Page 110] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 21 } docsIfCmtsUpChnlCtrExtUsedCntnReqMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request mini-slots utilized on this upstream logical channel. This count includes all contention mini-slots for IUC1 applicable to bursts that the CMTS correctly received. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnReqMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 22 } docsIfCmtsUpChnlCtrExtCollCntnReqMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC1 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnReqMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 23 } docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current Raftus & Cardona Standards Track [Page 111] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "Current count, from CMTS initialization, of contention request data mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC2 assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnReqDataMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 24 } docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS correctly received. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnReqDataMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 25 } docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of contention request data mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC2 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnReqDataMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur Raftus & Cardona Standards Track [Page 112] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 26 } docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of initial maintenance mini-slots defined for this upstream logical channel. This count includes all mini-slots for IUC3 assigned to a broadcast or multicast SID on the logical channel. This is the 64-bit version of docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 27 } docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current DESCRIPTION "Current count, from CMTS initialization, of initial maintenance mini-slots utilized on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS correctly received. This is the 64-bit version of docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 28 } docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots OBJECT-TYPE SYNTAX Counter64 UNITS "mini-slots" MAX-ACCESS read-only STATUS current Raftus & Cardona Standards Track [Page 113] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "Current count, from CMTS initialization, of contention initial maintenance mini-slots subjected to collisions on this upstream logical channel. This includes all contention mini-slots for IUC3 applicable to bursts that the CMTS detected, but could not correctly receive. This is the 64-bit version of docsIfCmtsUpChnlCtrCollCntnInitMaintMslots and will not be accessible to SNMPv1 managers. Discontinuities in the value of this counter can occur at reinitialization of the managed system, and at other times as indicated by the value of ifCounterDiscontinuityTime for the associated ifIndex." ::= { docsIfCmtsUpChannelCounterEntry 29 } -- -- notification group is for future extension. -- docsIfNotification OBJECT IDENTIFIER ::= { docsIfMib 2 } -- -- MIB Compliance statements. -- -- -- Conformance definitions -- docsIfConformance OBJECT IDENTIFIER ::= { docsIfMib 3 } docsIfCompliances OBJECT IDENTIFIER ::= { docsIfConformance 1 } docsIfGroups OBJECT IDENTIFIER ::= { docsIfConformance 2 } docsIfBasicCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for devices that implement DOCSIS 1.x compliant Radio Frequency Interfaces." MODULE -- docsIfMib -- unconditionally mandatory groups MANDATORY-GROUPS { docsIfBasicGroup } -- conditionally mandatory group GROUP docsIfCmGroup Raftus & Cardona Standards Track [Page 114] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "This group is implemented only in cable modems, not in cable modem termination systems." -- conditionally mandatory group GROUP docsIfCmtsGroup DESCRIPTION "This group is implemented only in cable modem termination systems, not in cable modems." OBJECT docsIfDownChannelFrequency WRITE-SYNTAX Integer32 (54000000..860000000) MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems. The values above are appropriate for a cable plant using a Sub-Split channel plan. If DOCSIS is extended to cover other types of channel plans (and frequency allocations), this object will be modified accordingly." OBJECT docsIfDownChannelWidth WRITE-SYNTAX Integer32 (6000000) MIN-ACCESS read-only DESCRIPTION "It is important to implement this object as read-only. In cable modems, this object is always implemented as read-only. The above value is appropriate for cable plants running under NTSC (National Television Standards Committee) standards. If DOCSIS is extended to work with other standards (e.g., European standards), this object will be modified accordingly." OBJECT docsIfDownChannelModulation WRITE-SYNTAX INTEGER { qam64 (3), qam256 (4) } MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfDownChannelInterleave WRITE-SYNTAX INTEGER { taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), Raftus & Cardona Standards Track [Page 115] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 taps64Increment2(6), taps128Increment1(7) } MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfDownChannelPower MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelFrequency WRITE-SYNTAX Integer32 (5000000..42000000) MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems. The values above are appropriate for a cable plant using a Sub-Split channel plan. If DOCSIS is extended to cover other types of channel plans (and frequency allocations), this object will be modified accordingly." OBJECT docsIfUpChannelWidth WRITE-SYNTAX Integer32 (200000..3200000) MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems. The above value is appropriate for cable plants running under NTSC (National Television Standards Committee) standards. If DOCSIS is extended to work with other standards (e.g., European standards), this object will be modified accordingly." OBJECT docsIfUpChannelModulationProfile MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelSlotSize MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." Raftus & Cardona Standards Track [Page 116] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 OBJECT docsIfUpChannelRangingBackoffStart MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelRangingBackoffEnd MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelTxBackoffStart MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelTxBackoffEnd MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfQosProfPriority MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfMaxUpBandwidth MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfGuarUpBandwidth MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfMaxDownBandwidth MIN-ACCESS read-only DESCRIPTION Raftus & Cardona Standards Track [Page 117] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfMaxTxBurst MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfBaselinePrivacy MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfStatus MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfCmtsServiceAdminStatus MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsSyncInterval MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsUcdInterval MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsInsertInterval MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsInvitedRangingAttempts MIN-ACCESS read-only DESCRIPTION Raftus & Cardona Standards Track [Page 118] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "It is compliant to implement this object as read-only." OBJECT docsIfCmtsQosProfilePermissions WRITE-SYNTAX BITS { createByManagement(0), updateByManagement(1) } MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsModType WRITE-SYNTAX INTEGER { qpsk (2), qam16 (3) } DESCRIPTION "A management station MAY only set 16QAM or QPSK modulation, but others might be possible, based on device configuration." OBJECT docsIfCmtsModPreambleLen SYNTAX Integer32 (0..1024) DESCRIPTION "The range of the values for this MODULE-COMPLIANCE is 0..1024." OBJECT docsIfCmtsModFECErrorCorrection SYNTAX Integer32 (0..10) DESCRIPTION "The range of the values for this MODULE-COMPLIANCE is 0..10." ::= { docsIfCompliances 1 } docsIfBasicComplianceV2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for devices that implement DOCSIS 2.0 Radio Frequency Interfaces." MODULE -- docsIfMib -- unconditionally mandatory groups MANDATORY-GROUPS { docsIfBasicGroupV2 } Raftus & Cardona Standards Track [Page 119] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 -- conditionally mandatory group GROUP docsIfCmGroupV2 DESCRIPTION "This group is implemented only in cable modems, not in cable modem termination systems." -- conditionally mandatory group GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in cable modem termination systems, not in cable modems." OBJECT docsIfDownChannelFrequency WRITE-SYNTAX Integer32 (47000000..862000000) MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems. A range of 54MHz to 860MHz is appropriate for a cable plant using a North American Sub-Split channel plan. The spectrum range has been expanded to accommodate a lower edge of 47MHz and an upper edge of 862MHz for some European channel plans. If DOCSIS is extended to cover other types of channel plans (and frequency allocations), this object will be modified accordingly." OBJECT docsIfDownChannelWidth WRITE-SYNTAX Integer32 (6000000 | 8000000) MIN-ACCESS read-only DESCRIPTION "It is important to implement this object as read-only. In cable modems, this object is always implemented as read-only. The value of 6 MHz is appropriate for cable plants running under NTSC (National Television Standards Committee) standards. The value of 8 MHz is appropriate for cable plants running under ETSI standards. For other regional standards, this object will be modified accordingly." OBJECT docsIfDownChannelModulation WRITE-SYNTAX INTEGER { qam64 (3), qam256 (4) } MIN-ACCESS read-only DESCRIPTION Raftus & Cardona Standards Track [Page 120] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfDownChannelInterleave WRITE-SYNTAX INTEGER { taps8Increment16(3), taps16Increment8(4), taps32Increment4(5), taps64Increment2(6), taps128Increment1(7), taps12increment17(8) } MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfDownChannelPower MIN-ACCESS read-only DESCRIPTION "Read-write in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelFrequency WRITE-SYNTAX Integer32 (5000000..65000000) MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems. A range of 5MHz to 42MHz is appropriate for a cable plant using a North American Sub-Split channel plan. The spectrum range has been expanded to accommodate an upper edge of 65MHz for some European channel plans. If DOCSIS is extended to cover other types of channel plans (and frequency allocations), this object will be modified accordingly." OBJECT docsIfUpChannelWidth WRITE-SYNTAX Integer32 (200000..6400000) MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems, read-only in cable modems. The above value is appropriate for cable plants running under NTSC (National Television Standards Committee) standards. If DOCSIS is extended to work with other standards (e.g., European standards), this object will be modified accordingly." Raftus & Cardona Standards Track [Page 121] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 OBJECT docsIfUpChannelModulationProfile MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelSlotSize MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfUpChannelRangingBackoffStart MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelRangingBackoffEnd MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelTxBackoffStart MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelTxBackoffEnd MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelScdmaActiveCodes MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems. The number of active codes when SCDMA is in use MUST range from 64 to 128 and MUST be a non-Prime value. Providing this range allows for the following features and capabilities: 1) Power management in S-CDMA spreader-on frames (with a 3 dB spread). Raftus & Cardona Standards Track [Page 122] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 2) Avoidance of code 0. 3) Flexible mini-slot sizes with and without the use of code 0." OBJECT docsIfUpChannelScdmaCodesPerSlot MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelScdmaFrameSize MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelScdmaHoppingSeed MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelCloneFrom MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelUpdate MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." OBJECT docsIfUpChannelStatus MIN-ACCESS read-only DESCRIPTION "Read-create in Cable Modem Termination Systems; read-only in Cable Modems. Entries associated to physical interfaces only support the read-only value 'active'." OBJECT docsIfUpChannelPreEqEnable MIN-ACCESS read-only DESCRIPTION "Read-create in cable modem termination systems; read-only in cable modems." Raftus & Cardona Standards Track [Page 123] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 OBJECT docsIfQosProfPriority MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfMaxUpBandwidth MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfGuarUpBandwidth MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfMaxDownBandwidth MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfBaselinePrivacy MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfStatus MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." OBJECT docsIfQosProfMaxTransmitBurst MIN-ACCESS read-only DESCRIPTION "This object is always read-only in cable modems. It is compliant to implement this object as read-only in cable modem termination systems." Raftus & Cardona Standards Track [Page 124] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 OBJECT docsIfCmRangingTimeout MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmStatusModulationType SYNTAX INTEGER { unknown(0), tdma(1), atdma(2), scdma(3) } DESCRIPTION "CM does not use both modulation burst profiles of a 'tdmAndAtdma' ChannelType; therefore, 'tdmAndAtdma'is not supported." OBJECT docsIfCmtsServiceAdminStatus MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsSyncInterval MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsUcdInterval MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsInsertInterval MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsInvitedRangingAttempts MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsQosProfilePermissions WRITE-SYNTAX BITS { createByManagement(0), updateByManagement(1) } MIN-ACCESS read-only Raftus & Cardona Standards Track [Page 125] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsIfCmtsModType WRITE-SYNTAX INTEGER { qpsk(2), qam16(3), qam64(6) } DESCRIPTION "A management station MAY only set 64QAM, 16QAM, or QPSK modulation for Time or Code division Multiple Access, but others might be possible based on device configuration." OBJECT docsIfCmtsCmStatusModulationType SYNTAX INTEGER { unknown(0), tdma(1), atdma(2), scdma(3) } DESCRIPTION "CM does not use both modulation burst profiles of a 'tdmAndAtdma' ChannelType; therefore, 'tdmAndAtdma'is not supported." ::= { docsIfCompliances 2 } docsIfBasicGroup OBJECT-GROUP OBJECTS { docsIfDownChannelId, docsIfDownChannelFrequency, docsIfDownChannelWidth, docsIfDownChannelModulation, docsIfDownChannelInterleave, docsIfDownChannelPower, docsIfUpChannelId, docsIfUpChannelFrequency, docsIfUpChannelWidth, docsIfUpChannelModulationProfile, docsIfUpChannelSlotSize, docsIfUpChannelTxTimingOffset, docsIfUpChannelRangingBackoffStart, docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart, docsIfUpChannelTxBackoffEnd, docsIfQosProfPriority, Raftus & Cardona Standards Track [Page 126] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfQosProfMaxUpBandwidth, docsIfQosProfGuarUpBandwidth, docsIfQosProfMaxDownBandwidth, docsIfQosProfMaxTxBurst, docsIfQosProfBaselinePrivacy, docsIfQosProfStatus, docsIfSigQIncludesContention, docsIfSigQUnerroreds, docsIfSigQCorrecteds, docsIfSigQUncorrectables, docsIfSigQSignalNoise, docsIfSigQMicroreflections, docsIfSigQEqualizationData } STATUS deprecated DESCRIPTION "Group of objects implemented in both cable modems and cable modem termination systems." ::= { docsIfGroups 1 } docsIfCmGroup OBJECT-GROUP OBJECTS { docsIfCmCmtsAddress, docsIfCmCapabilities, docsIfCmRangingTimeout, docsIfCmStatusValue, docsIfCmStatusCode, docsIfCmStatusTxPower, docsIfCmStatusResets, docsIfCmStatusLostSyncs, docsIfCmStatusInvalidMaps, docsIfCmStatusInvalidUcds, docsIfCmStatusInvalidRangingResponses, docsIfCmStatusInvalidRegistrationResponses, docsIfCmStatusT1Timeouts, docsIfCmStatusT2Timeouts, docsIfCmStatusT3Timeouts, docsIfCmStatusT4Timeouts, docsIfCmStatusRangingAborteds, docsIfCmServiceQosProfile, docsIfCmServiceTxSlotsImmed, docsIfCmServiceTxSlotsDed, docsIfCmServiceTxRetries, docsIfCmServiceTxExceededs, docsIfCmServiceRqRetries, docsIfCmServiceRqExceededs } STATUS deprecated Raftus & Cardona Standards Track [Page 127] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 DESCRIPTION "Group of objects implemented in cable modems." ::= { docsIfGroups 2 } docsIfCmtsGroup OBJECT-GROUP OBJECTS { docsIfCmtsCapabilities, docsIfCmtsSyncInterval, docsIfCmtsUcdInterval, docsIfCmtsMaxServiceIds, docsIfCmtsInvitedRangingAttempts, docsIfCmtsInsertInterval, docsIfCmtsStatusInvalidRangeReqs, docsIfCmtsStatusRangingAborteds, docsIfCmtsStatusInvalidRegReqs, docsIfCmtsStatusFailedRegReqs, docsIfCmtsStatusInvalidDataReqs, docsIfCmtsStatusT5Timeouts, docsIfCmtsCmStatusMacAddress, docsIfCmtsCmStatusIpAddress, docsIfCmtsCmStatusDownChannelIfIndex, docsIfCmtsCmStatusUpChannelIfIndex, docsIfCmtsCmStatusRxPower, docsIfCmtsCmStatusTimingOffset, docsIfCmtsCmStatusEqualizationData, docsIfCmtsCmStatusValue, docsIfCmtsCmStatusUnerroreds, docsIfCmtsCmStatusCorrecteds, docsIfCmtsCmStatusUncorrectables, docsIfCmtsCmStatusSignalNoise, docsIfCmtsCmStatusMicroreflections, docsIfCmtsServiceCmStatusIndex, docsIfCmtsServiceAdminStatus, docsIfCmtsServiceQosProfile, docsIfCmtsServiceCreateTime, docsIfCmtsServiceInOctets, docsIfCmtsServiceInPackets, docsIfCmtsModType, docsIfCmtsModControl, docsIfCmtsModPreambleLen, docsIfCmtsModDifferentialEncoding, docsIfCmtsModFECErrorCorrection, docsIfCmtsModFECCodewordLength, docsIfCmtsModScramblerSeed, docsIfCmtsModMaxBurstSize, docsIfCmtsModGuardTimeSize, docsIfCmtsModLastCodewordShortened, docsIfCmtsModScrambler, Raftus & Cardona Standards Track [Page 128] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsQosProfilePermissions, docsIfCmtsCmPtr } STATUS deprecated DESCRIPTION "Group of objects implemented in Cable Modem Termination Systems." ::= { docsIfGroups 3 } -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670 -- was the first version of this MIB Module. docsIfObsoleteGroup OBJECT-GROUP OBJECTS { docsIfCmRangingRespTimeout, docsIfCmtsInsertionInterval } STATUS obsolete DESCRIPTION "Group of objects obsoleted." ::= { docsIfGroups 4 } docsIfBasicGroupV2 OBJECT-GROUP OBJECTS { docsIfDownChannelId, docsIfDownChannelFrequency, docsIfDownChannelWidth, docsIfDownChannelModulation, docsIfDownChannelInterleave, docsIfDownChannelPower, docsIfDownChannelAnnex, docsIfUpChannelId, docsIfUpChannelFrequency, docsIfUpChannelWidth, docsIfUpChannelModulationProfile, docsIfUpChannelSlotSize, docsIfUpChannelTxTimingOffset, docsIfUpChannelRangingBackoffStart, docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart, docsIfUpChannelTxBackoffEnd, docsIfUpChannelScdmaActiveCodes, docsIfUpChannelScdmaCodesPerSlot, docsIfUpChannelScdmaFrameSize, docsIfUpChannelScdmaHoppingSeed, docsIfUpChannelType, docsIfUpChannelCloneFrom, Raftus & Cardona Standards Track [Page 129] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfUpChannelUpdate, docsIfUpChannelStatus, docsIfUpChannelPreEqEnable, docsIfQosProfPriority, docsIfQosProfMaxUpBandwidth, docsIfQosProfGuarUpBandwidth, docsIfQosProfMaxDownBandwidth, docsIfQosProfBaselinePrivacy, docsIfQosProfStatus, docsIfQosProfMaxTransmitBurst, docsIfSigQIncludesContention, docsIfSigQUnerroreds, docsIfSigQCorrecteds, docsIfSigQUncorrectables, docsIfSigQSignalNoise, docsIfSigQMicroreflections, docsIfSigQExtUnerroreds, docsIfSigQExtCorrecteds, docsIfSigQExtUncorrectables, docsIfDocsisBaseCapability } STATUS current DESCRIPTION "Group of objects implemented in both cable modems and cable modem termination systems." ::= { docsIfGroups 5 } docsIfCmGroupV2 OBJECT-GROUP OBJECTS { docsIfCmCmtsAddress, docsIfCmCapabilities, docsIfCmRangingTimeout, docsIfCmStatusValue, docsIfCmStatusCode, docsIfCmStatusTxPower, docsIfCmStatusResets, docsIfCmStatusLostSyncs, docsIfCmStatusInvalidMaps, docsIfCmStatusInvalidUcds, docsIfCmStatusInvalidRangingResponses, docsIfCmStatusInvalidRegistrationResponses, docsIfCmStatusT1Timeouts, docsIfCmStatusT2Timeouts, docsIfCmStatusT3Timeouts, docsIfCmStatusT4Timeouts, docsIfCmStatusRangingAborteds, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType, Raftus & Cardona Standards Track [Page 130] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmStatusEqualizationData, docsIfCmStatusUCCs, docsIfCmStatusUCCFails, docsIfCmServiceQosProfile, docsIfCmServiceTxSlotsImmed, docsIfCmServiceTxSlotsDed, docsIfCmServiceTxRetries, docsIfCmServiceTxExceededs, docsIfCmServiceRqRetries, docsIfCmServiceRqExceededs, docsIfCmServiceExtTxSlotsImmed, docsIfCmServiceExtTxSlotsDed, docsIfSigQEqualizationData } STATUS current DESCRIPTION "Group of objects implemented in cable modems." ::= { docsIfGroups 6 } docsIfCmtsGroupV2 OBJECT-GROUP OBJECTS { docsIfCmtsCapabilities, docsIfCmtsSyncInterval, docsIfCmtsUcdInterval, docsIfCmtsMaxServiceIds, docsIfCmtsInvitedRangingAttempts, docsIfCmtsInsertInterval, docsIfCmtsMacStorageType, docsIfCmtsStatusInvalidRangeReqs, docsIfCmtsStatusRangingAborteds, docsIfCmtsStatusInvalidRegReqs, docsIfCmtsStatusFailedRegReqs, docsIfCmtsStatusInvalidDataReqs, docsIfCmtsStatusT5Timeouts, docsIfCmtsCmStatusMacAddress, docsIfCmtsCmStatusDownChannelIfIndex, docsIfCmtsCmStatusUpChannelIfIndex, docsIfCmtsCmStatusRxPower, docsIfCmtsCmStatusTimingOffset, docsIfCmtsCmStatusEqualizationData, docsIfCmtsCmStatusValue, docsIfCmtsCmStatusUnerroreds, docsIfCmtsCmStatusCorrecteds, docsIfCmtsCmStatusUncorrectables, docsIfCmtsCmStatusSignalNoise, docsIfCmtsCmStatusMicroreflections, docsIfCmtsCmStatusExtUnerroreds, docsIfCmtsCmStatusExtCorrecteds, Raftus & Cardona Standards Track [Page 131] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsCmStatusExtUncorrectables, docsIfCmtsCmStatusDocsisRegMode, docsIfCmtsCmStatusModulationType, docsIfCmtsCmStatusInetAddressType, docsIfCmtsCmStatusInetAddress, docsIfCmtsCmStatusValueLastUpdate, docsIfCmtsCmStatusHighResolutionTimingOffset, docsIfCmtsServiceAdminStatus, docsIfCmtsServiceQosProfile, docsIfCmtsServiceCreateTime, docsIfCmtsServiceInOctets, docsIfCmtsServiceInPackets, docsIfCmtsServiceNewCmStatusIndex, docsIfCmtsModType, docsIfCmtsModControl, docsIfCmtsModPreambleLen, docsIfCmtsModDifferentialEncoding, docsIfCmtsModFECErrorCorrection, docsIfCmtsModFECCodewordLength, docsIfCmtsModScramblerSeed, docsIfCmtsModMaxBurstSize, docsIfCmtsModGuardTimeSize, docsIfCmtsModLastCodewordShortened, docsIfCmtsModScrambler, docsIfCmtsModByteInterleaverDepth, docsIfCmtsModByteInterleaverBlockSize, docsIfCmtsModPreambleType, docsIfCmtsModTcmErrorCorrectionOn, docsIfCmtsModScdmaInterleaverStepSize, docsIfCmtsModScdmaSpreaderEnable, docsIfCmtsModScdmaSubframeCodes, docsIfCmtsModChannelType, docsIfCmtsModStorageType, docsIfCmtsQosProfilePermissions, docsIfCmtsCmPtr, docsIfCmtsChannelUtilizationInterval, docsIfCmtsChannelUtUtilization, docsIfCmtsDownChnlCtrId, docsIfCmtsDownChnlCtrTotalBytes, docsIfCmtsDownChnlCtrUsedBytes, docsIfCmtsDownChnlCtrExtTotalBytes, docsIfCmtsDownChnlCtrExtUsedBytes, docsIfCmtsUpChnlCtrId, docsIfCmtsUpChnlCtrTotalMslots, docsIfCmtsUpChnlCtrUcastGrantedMslots, docsIfCmtsUpChnlCtrTotalCntnMslots, docsIfCmtsUpChnlCtrUsedCntnMslots, docsIfCmtsUpChnlCtrExtTotalMslots, Raftus & Cardona Standards Track [Page 132] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfCmtsUpChnlCtrExtUcastGrantedMslots, docsIfCmtsUpChnlCtrExtTotalCntnMslots, docsIfCmtsUpChnlCtrExtUsedCntnMslots, docsIfCmtsUpChnlCtrCollCntnMslots, docsIfCmtsUpChnlCtrTotalCntnReqMslots, docsIfCmtsUpChnlCtrUsedCntnReqMslots, docsIfCmtsUpChnlCtrCollCntnReqMslots, docsIfCmtsUpChnlCtrTotalCntnReqDataMslots, docsIfCmtsUpChnlCtrUsedCntnReqDataMslots, docsIfCmtsUpChnlCtrCollCntnReqDataMslots, docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots, docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots, docsIfCmtsUpChnlCtrCollCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtCollCntnMslots, docsIfCmtsUpChnlCtrExtTotalCntnReqMslots, docsIfCmtsUpChnlCtrExtUsedCntnReqMslots, docsIfCmtsUpChnlCtrExtCollCntnReqMslots, docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots, docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots, docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots, docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots, docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots, docsIfDownChannelStorageType, docsIfQosProfStorageType } STATUS current DESCRIPTION "Group of objects implemented in Cable Modem Termination Systems." ::= { docsIfGroups 7 } END Raftus & Cardona Standards Track [Page 133] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 5. Revision History 5.1. Scope The MIB module in this document has been developed to accommodate DOCSIS 2.0 devices and their system capabilities. The MIB module is an update to RFC 2670 [RFC2670] with the additional incorporation of DOCSIS 2.0 [RFI2.0] and Euro-DOCSIS specification requirements [EN-300-429]. 5.2. Extension We have maintained the MIB objects as defined in RFC 2670 [RFC2670]. In some cases new MIB objects have been created with identical functionality but greater capacity (i.e., 32 to 64 bits). In these situations, both the original 32 bit objects and the new 64 bit objects must be implemented. 6. Security Considerations This MIB module relates to a system that will provide metropolitan public internet access. As such, improper manipulation of the MIB objects represented by this MIB module may result in denial of service to a large number of end-users. There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The CMTS is the controller of most of the parameters of the DOCSIS RFI Interface. Therefore, write access to the CMTS MIB objects may compromise the end-user's services. In the CM case, the only read-write object of this MIB module is docsIfCmRangingTimeout, which if SET maliciously, may not constitute a critical factor of service degradation. The rest of the CM-required MIB objects in this MIB module are read- only, either by definition, or by compliance statements. The CMTS is the controller of most of the parameters of the DOCSIS RFI Interface. Below are the CMTS MIB object's vulnerabilities: o Objects in the docsIfBasicGroupv2, if SET maliciously, could result in a denial of service. Particularly, SETs to objects in Raftus & Cardona Standards Track [Page 134] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 docsIfDownstreamChannelTable, docsIfUpstreamChannelTable, docsIfCmtsModulationTable, and docsIfQosProfileTable (the last one in conjunction with the MIB object docsIfCmtsQosProfilePermissions) can alter negatively the physical and link layer parameters of upstream and downstream channels. o The Object docsIfCmtsServiceAdminStatus of the docsIfCmtsGroupv2 group, when SET maliciously by an attacker to 'disabled' or 'destroyed', will interrupt the service of the corresponding cable modem. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Below are some sensitivity considerations: o Read access to the MIB objects in tables docsIfCmStatusTable (CM), docsIfSignalQualityTable (CM/CMTS) and in CMTS tables docsIfCmtsCmStatusTable, docsIfCmtsChannelUtilizationTable, docsIfCmtsDownChannelCounterTable, and docsIfCmtsUpChannelCounterTable, could reveal information about the cable modems' distribution among the upstream and downstream channels and their performance, which could be used to gain access to a different tiered service offer. The table docsIfCmtsCmStatusTable also contains the MAC and IP addresses of the cable modems, which can be used for theft of service. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Raftus & Cardona Standards Track [Page 135] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 7. Management Interoperability of DOCSIS 1.0, 1.1, and 2.0 The MIB module contained in this document updates RFC 2670 [RFC2670], primarily to handle the management requirements of the DOCSIS RF Interface of DOCSIS 2.0 [ITU-T_J.122]. RFC 2670 contains the DOCSIS RF Interface management requirements for DOCSIS 1.0 and DOCSIS 1.1. The management requirements of Class of Service (DOCSIS 1.0) pertaining to RFC 2670 are the same as this document update and are contained in the tables docsIfQosProfileTable, docsIfCmServiceTable, and docsIfCmtsServiceTable. DOCSIS 1.1 and DOCSIS 2.0 Quality of Service management requirements are defined in the DOCSIS management specifications [OSSI1.1] and [OSSI2.0], respectively. 8. References 8.1. Normative References [EN-300-429] European Telecommunications Standard Institute, "ETSI Standard EN 300 429, Version 1.2.1: Digital Video Broadcasting (DVB), Framing structure, channel coding and modulation for cable systems", April 1998. [IANA] Internet Assigned Numbers Authority, "Internet Assigned Numbers Authority", October 2005, . [ITU-T_J.112] Telecommunication Standardization Sector of International Telecommunications Union, "Transmission Systems for Interactive Cable Television Services, Annex B.", March 2001, . [ITU-T_J.122] Telecommunication Standardization Sector of International Telecommunications Union, "Second- Generation Transmission Systems for Interactive Cable Television Services.", December 2002, . [ITU-T_J.83] Telecommunication Standardization Sector of International Telecommunications Union, "ITU-T Recommendation J.83(4/97), Digital multi-programme systems for television sound and data services for cable distribution.", April 1997, . Raftus & Cardona Standards Track [Page 136] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFI1.1] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv1.1-C01-050907", September 2005, . [RFI2.0] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I09-050812", August 2005, . 8.2. Informative References [BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, . [BPIPLUS] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification SP-BPI+-I12-050812", August 2005, . [OSSI1.1] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv1.1-C01-050907", September 2005, . Raftus & Cardona Standards Track [Page 137] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 [OSSI2.0] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I09-050812", September 2005, . [Proakis00] McGraw-Hill, "Digital Communications, 4th Edition", 2000. [RFC2670] St. Johns, M., "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFI1.0] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1 2002", 2002, . Authors' Addresses David Raftus ATI Technologies 340 Terry Fox Drive, Suite 202 Ottawa, Ontario Canada Phone: +1 613 592 1052 ext.222 EMail: david.raftus@ati.com Eduardo Cardona Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80020 USA Phone: +1 303 661 3375 EMail: e.cardona@cablelabs.com Raftus & Cardona Standards Track [Page 138] RFC 4546 DOCSIS 2.0 Radio Frequency (RFI) MIB June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Raftus & Cardona Standards Track [Page 139] snmp-mibs-downloader-1.1/mibrfcs/rfc4547.txt0000644000000000000000000024371511402176072015602 0ustar Network Working Group A. Ahmad Request for Comments: 4547 Cisco Systems Inc. Category: Standards Track G. Nakanishi Motorola June 2006 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB. This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. Ahmad & Makanishi Standards Track [Page 1] RFC 4547 Event Notification MIB June 2006 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Glossary ........................................................2 2.1. BPI - Baseline Privacy Interface ...........................3 2.2. BPI - Baseline Privacy Plus Interface ......................3 2.3. CATV .......................................................3 2.4. CM - Cable Modem ...........................................3 2.5. CMTS - Cable Modem Termination System ......................3 2.6. DOCSIS .....................................................3 2.7. Downstream .................................................4 2.8. Head-end ...................................................4 2.9. MAC Packet .................................................4 2.10. RF ........................................................4 2.11. SID .......................................................4 2.12. TLV .......................................................4 2.13. Upstream ..................................................4 3. Overview ........................................................4 3.1. Structure of the MIB .......................................5 4. Definitions .....................................................5 5. Contributors ...................................................35 6. Acknowledgements ...............................................36 7. Security Considerations ........................................36 8. IANA Considerations ............................................37 9. References .....................................................37 9.1. Normative References ......................................37 9.2. Informative References ....................................38 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4]. 2. Glossary The terms in this document are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification (DOCSIS) process. Ahmad & Makanishi Standards Track [Page 2] RFC 4547 Event Notification MIB June 2006 2.1. BPI - Baseline Privacy Interface A mechanism for providing data privacy over the HFC network in DOCSIS 1.0 systems [8]. 2.2. BPI - Baseline Privacy Plus Interface A mechanism that extends the Baseline Privacy Interface with the addition of CM authentication over the HFC network in DOCSIS 1.1/2.0 systems and beyond [9]. 2.3. CATV Originally "Community Antenna Television", now used to refer to any cable or hybrid fiber and cable system used to deliver video signals to a community. 2.4. CM - Cable Modem A CM acts as a "slave" station in a DOCSIS-compliant cable data system. 2.5. CMTS - Cable Modem Termination System A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS-compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs. 2.6. DOCSIS DOCSIS stands for "Data-over-Cable Service Interface Specifications" and refers to the ITU-T J.112 Annex B standard for cable modem systems [10], [13] commonly known as DOCSIS 1.0. The DOCSIS 1.1 specification is an extension of DOCSIS 1.0, with new features to support quality of service, fragmentation, and requirements for European cable plants [14]. DOCSIS 2.0 [15] builds upon DOCSIS 1.1 and provides all of the features and functionality that DOCSIS 1.1 provides. In addition, it provides some significant enhancements in upstream capacity over DOCSIS 1.1, such as 30.72 Mbps maximum upstream channel capacity, Synchronous-Code Division Multiple Access (CDMA) operation, increased robustness to upstream noise and channel impairments, Enhanced Reed- Solomon error correction, and Trellis Coded Modulation. Ahmad & Makanishi Standards Track [Page 3] RFC 4547 Event Notification MIB June 2006 2.7. Downstream The direction from the CMTS to the CM. 2.8. Head-end The origination point in most cable systems of the subscriber video signals. Generally also the location of the CMTS equipment. 2.9. MAC Packet A term referring to DOCSIS Protocol Data Unit (PDU). 2.10. RF A term referring to Radio Frequency. 2.11. SID A term referring to DOCSIS Service ID. The SID identifies a particular upstream bandwidth allocation and class-of-service management for DOCSIS, and identifies a particular bidirectional security association for BPI. 2.12. TLV TLV stands for Type/Length/Value. TLV is an encoding method consisting of three fields. The first field indicates the type of element, the second field indicates the length of the element, and the third field contains the element's value. 2.13. Upstream The direction from the CM to the CMTS. 3. Overview Offering High Speed Internet Service in the cable industry has become extremely successful. DOCSIS devices are being deployed at a rate of multiple thousands per day. Although operators are enjoying successful deployment, they are also facing the challenge of properly managing deployed devices. Operators are using Simple Network Management Protocol, a set of Management Information Base (MIB) required by DOCSIS, and SNMP Notifications to manage deployed DOCSIS devices. The usage of SNMP Notification for event reporting is becoming more popular as an effective and efficient method for network monitoring. Ahmad & Makanishi Standards Track [Page 4] RFC 4547 Event Notification MIB June 2006 Unfortunately, only a minimal set of SNMP Notifications is currently available. This notification MIB, in conjunction with [11] and [12], provides a minimum set of standard DOCSIS Notifications that DOCSIS devices SHOULD support to enable successful management of DOCSIS devices and networks. This document defines a set of objects required for the event notification management of DOCSIS-compliant Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs). The MIB module is derived from the DOCSIS [11] and [12]. Appendix H of [11] defines all DOCSIS 1.1 required events, and Appendix D of [12] does that for DOCSIS 2.0. The notifications specified in this document are used to notify these events via SNMP. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. 3.1. Structure of the MIB This DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB was designed to extend the RFC2669 [5] notification module. Two groups of SNMP notification objects are defined in this document. One group defines notifications for cable modem events, and the other group defines notifications for cable modem termination system events. DOCSIS defines numerous events, and each event is assigned to a functional category. This MIB defines a notification object for each functional category. The varbinding list of each notification includes information about the event that occurred on the device. 4. Definitions The MIB module defined here IMPORTs from SNMPv2-SMI [2], SNMPv2-CONF [3], DOCS-CABLE-DEVICE-MIB [5], DOCS-IF-MIB [6], and IF-MIB [7]. DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI -- RFC 2578 MODULE-COMPLIANCE, Ahmad & Makanishi Standards Track [Page 5] RFC 4547 Event Notification MIB June 2006 OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580 docsDevEvLevel, docsDevEvId, docsDevEvText, docsDevSwFilename, docsDevSwServer, docsDevServerDhcp, docsDevServerTime FROM DOCS-CABLE-DEVICE-MIB -- RFC 2669 docsIfCmCmtsAddress, docsIfCmtsCmStatusMacAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType, docsIfCmtsCmStatusDocsisRegMode, docsIfCmtsCmStatusModulationType FROM DOCS-IF-MIB -- RFC 4546 ifPhysAddress FROM IF-MIB; -- RFC 2863 docsDevNotifMIB MODULE-IDENTITY LAST-UPDATED "200605240000Z" -- May 24, 2006 ORGANIZATION "IETF IP over Cable Data Network Working Group" CONTACT-INFO " Azlina Ahmad Postal: Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134, U.S.A. Phone: 408 853 7927 E-mail: azlina@cisco.com Greg Nakanishi Postal: Motorola 6450 Sequence Drive San Diego, CA 92121, U.S.A. Phone: 858 404 2366 E-mail: gnakanishi@motorola.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Ahmad & Makanishi Standards Track [Page 6] RFC 4547 Event Notification MIB June 2006 Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, richard_woundy@cable.comcast.com Jean-Francois Mule, jf.mule@cablelabs.com" DESCRIPTION "The Event Notification MIB is an extension of the CABLE DEVICE MIB. It defines various notification objects for both cable modem and cable modem termination systems. Two groups of SNMP notification objects are defined. One group is for notifying cable modem events, and one group is for notifying cable modem termination system events. DOCSIS defines numerous events, and each event is assigned to a functional category. This MIB defines a notification object for each functional category. The varbinding list of each notification includes information about the event that occurred on the device. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4547; see the RFC itself for full legal notices." REVISION "200605240000Z" -- May 24, 2006 DESCRIPTION "Initial version, published as RFC 4547." ::= { mib-2 132 } docsDevNotifControl OBJECT IDENTIFIER ::= { docsDevNotifMIB 1} docsDevCmNotifs OBJECT IDENTIFIER ::= { docsDevNotifMIB 2 0 } docsDevCmtsNotifs OBJECT IDENTIFIER ::= { docsDevNotifMIB 3 0 } docsDevCmNotifControl OBJECT-TYPE SYNTAX BITS { cmInitTLVUnknownNotif( 0), cmDynServReqFailNotif( 1), cmDynServRspFailNotif( 2), cmDynServAckFailNotif( 3), cmBpiInitNotif( 4), cmBPKMNotif( 5), cmDynamicSANotif( 6), cmDHCPFailNotif( 7), cmSwUpgradeInitNotif( 8), cmSwUpgradeFailNotif( 9), cmSwUpgradeSuccessNotif( 10), Ahmad & Makanishi Standards Track [Page 7] RFC 4547 Event Notification MIB June 2006 cmSwUpgradeCVCNotif( 11), cmTODFailNotif( 12), cmDCCReqFailNotif( 13), cmDCCRspFailNotif( 14), cmDCCAckFailNotif( 15) } MAX-ACCESS read-write STATUS current DESCRIPTION "The object is used to enable specific CM notifications. For example, if the first bit is set, then docsDevCmInitTLVUnknownNotif is enabled. If it is not set, the notification is disabled. Note that notifications are also under the control of the MIB modules defined in RFC3413. If the device is rebooted,the value of this object SHOULD revert to the default value. " DEFVAL { {} } ::= { docsDevNotifControl 1 } docsDevCmtsNotifControl OBJECT-TYPE SYNTAX BITS { cmtsInitRegReqFailNotif( 0), cmtsInitRegRspFailNotif( 1), cmtsInitRegAckFailNotif( 2), cmtsDynServReqFailNotif( 3), cmtsDynServRspFailNotif( 4), cmtsDynServAckFailNotif( 5), cmtsBpiInitNotif( 6), cmtsBPKMNotif( 7), cmtsDynamicSANotif( 8), cmtsDCCReqFailNotif( 9), cmtsDCCRspFailNotif( 10), cmtsDCCAckFailNotif( 11) } MAX-ACCESS read-write STATUS current DESCRIPTION "The object is used to enable specific CMTS notifications. For example, if the first bit is set, then docsDevCmtsInitRegRspFailNotif is enabled. If it is not set, the notification is disabled. Note that notifications are also under the control of the MIB modules defined in RFC3413. Ahmad & Makanishi Standards Track [Page 8] RFC 4547 Event Notification MIB June 2006 If the device is rebooted,the value of this object SHOULD revert to the default value. " DEFVAL { {} } ::= { docsDevNotifControl 2 } docsDevCmInitTLVUnknownNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "Notification to indicate that an unknown TLV was encountered during the TLV parsing process. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 1 } Ahmad & Makanishi Standards Track [Page 9] RFC 4547 Event Notification MIB June 2006 docsDevCmDynServReqFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic service request during the dynamic services process. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected to (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 2 } docsDevCmDynServRspFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, Ahmad & Makanishi Standards Track [Page 10] RFC 4547 Event Notification MIB June 2006 docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION " A notification to report the failure of a dynamic service response during the dynamic services process. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 3} docsDevCmDynServAckFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION Ahmad & Makanishi Standards Track [Page 11] RFC 4547 Event Notification MIB June 2006 "A notification to report the failure of a dynamic service acknowledgement during the dynamic services process. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 4} docsDevCmBpiInitNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a BPI initialization attempt during the registration process. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the Ahmad & Makanishi Standards Track [Page 12] RFC 4547 Event Notification MIB June 2006 event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 5 } docsDevCmBPKMNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a Baseline Privacy Key Management (BPKM) operation. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS Ahmad & Makanishi Standards Track [Page 13] RFC 4547 Event Notification MIB June 2006 to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 6 } docsDevCmDynamicSANotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic security association operation. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. Ahmad & Makanishi Standards Track [Page 14] RFC 4547 Event Notification MIB June 2006 - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 7 } docsDevCmDHCPFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsDevServerDhcp, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a DHCP operation. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsDevServerDhcp: the IP address of the DHCP server. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 8 } Ahmad & Makanishi Standards Track [Page 15] RFC 4547 Event Notification MIB June 2006 docsDevCmSwUpgradeInitNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsDevSwFilename, docsDevSwServer, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to indicate that a software upgrade has been initiated on the device. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 9 } docsDevCmSwUpgradeFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, Ahmad & Makanishi Standards Track [Page 16] RFC 4547 Event Notification MIB June 2006 ifPhysAddress, docsIfCmCmtsAddress, docsDevSwFilename, docsDevSwServer, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a software upgrade attempt. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsDevSwFilename: the software image file name - docsDevSwServer: the IP address of the server that the image is retrieved from. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 10 } docsDevCmSwUpgradeSuccessNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, Ahmad & Makanishi Standards Track [Page 17] RFC 4547 Event Notification MIB June 2006 docsDevSwFilename, docsDevSwServer, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the software upgrade success status. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsDevSwFilename: the software image file name - docsDevSwServer: the IP address of the server that the image is retrieved from. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 11 } docsDevCmSwUpgradeCVCFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, Ahmad & Makanishi Standards Track [Page 18] RFC 4547 Event Notification MIB June 2006 docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report that the verification of the code file has failed during a secure software upgrade attempt. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 12 } docsDevCmTODFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsDevServerTime, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a time of day Ahmad & Makanishi Standards Track [Page 19] RFC 4547 Event Notification MIB June 2006 operation. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsDevServerTime: the IP address of the time server. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 13 } docsDevCmDCCReqFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION " A notification to report the failure of a dynamic channel change request during the dynamic channel change process on the CM. This notification sends additional information about the event by including the following objects in its varbinding list. Ahmad & Makanishi Standards Track [Page 20] RFC 4547 Event Notification MIB June 2006 - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 14 } docsDevCmDCCRspFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic channel change response during the dynamic channel change process on the CM. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable Ahmad & Makanishi Standards Track [Page 21] RFC 4547 Event Notification MIB June 2006 interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 15 } docsDevCmDCCAckFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, ifPhysAddress, docsIfCmCmtsAddress, docsIfDocsisBaseCapability, docsIfCmStatusDocsisOperMode, docsIfCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic channel change acknowledgement during the dynamic channel change process on the CM. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - ifPhysAddress: the MAC address of the cable interface of this cable modem. - docsIfCmCmtsAddress: the MAC address of the CMTS to which the CM is connected (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface to which it is Ahmad & Makanishi Standards Track [Page 22] RFC 4547 Event Notification MIB June 2006 connected). - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1) that the CM is operating in. - docsIfCmtsCmStatusModulationType the upstream modulation methodology used by the CM. " ::= { docsDevCmNotifs 16} docsDevCmtsInitRegReqFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a registration request from a CM during the CM initialization process that was detected on the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. Ahmad & Makanishi Standards Track [Page 23] RFC 4547 Event Notification MIB June 2006 - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 1 } docsDevCmtsInitRegRspFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a registration response during the CM initialization process that was detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 2 } docsDevCmtsInitRegAckFailNotif NOTIFICATION-TYPE Ahmad & Makanishi Standards Track [Page 24] RFC 4547 Event Notification MIB June 2006 OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a registration acknowledgement from the CM during the CM initialization process that was detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 3 } docsDevCmtsDynServReqFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, Ahmad & Makanishi Standards Track [Page 25] RFC 4547 Event Notification MIB June 2006 docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic service request during the dynamic services process that was detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 4 } docsDevCmtsDynServRspFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION Ahmad & Makanishi Standards Track [Page 26] RFC 4547 Event Notification MIB June 2006 "A notification to report the failure of a dynamic service response during the dynamic services process that was detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 5 } docsDevCmtsDynServAckFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic service acknowledgement during the dynamic services process that was detected by the CMTS. This notification sends additional information about the event by including the following objects in its Ahmad & Makanishi Standards Track [Page 27] RFC 4547 Event Notification MIB June 2006 varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 6 } docsDevCmtsBpiInitNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a BPI initialization attempt during the CM registration process that was detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. Ahmad & Makanishi Standards Track [Page 28] RFC 4547 Event Notification MIB June 2006 - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 7 } docsDevCmtsBPKMNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a BPKM operation that is detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface Ahmad & Makanishi Standards Track [Page 29] RFC 4547 Event Notification MIB June 2006 connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 8 } docsDevCmtsDynamicSANotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic security association operation that is detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. Ahmad & Makanishi Standards Track [Page 30] RFC 4547 Event Notification MIB June 2006 - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 9 } docsDevCmtsDCCReqFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic channel change request during the dynamic channel change process and is detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 10 } docsDevCmtsDCCRspFailNotif NOTIFICATION-TYPE Ahmad & Makanishi Standards Track [Page 31] RFC 4547 Event Notification MIB June 2006 OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic channel change response during the dynamic channel change process and is detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 11 } docsDevCmtsDCCAckFailNotif NOTIFICATION-TYPE OBJECTS { docsDevEvLevel, docsDevEvId, docsDevEvText, docsIfCmtsCmStatusMacAddress, Ahmad & Makanishi Standards Track [Page 32] RFC 4547 Event Notification MIB June 2006 ifPhysAddress, docsIfCmtsCmStatusDocsisRegMode, docsIfDocsisBaseCapability, docsIfCmtsCmStatusModulationType } STATUS current DESCRIPTION "A notification to report the failure of a dynamic channel change acknowledgement during the dynamic channel change process and is detected by the CMTS. This notification sends additional information about the event by including the following objects in its varbinding list. - docsDevEvLevel: the priority level associated with the event. - docsDevEvId: the unique identifier of the event that occurred. - docsDevEvText: a textual description of the event. - docsIfCmtsCmStatusMacAddress: the MAC address of the CM with which this notification is associated. - ifPhysAddress: the MAC address of the CMTS (if there is a cable card/interface in the CMTS, then it is actually the MAC address of the cable interface that connected to the CM) cable interface connected to the CM. - docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1) that the reporting CM is operating in. - docsIfDocsisBaseCapability: the highest version of the DOCSIS specification (1.0, 1.1, 2.0) that the device is capable of supporting. - docsIfCmtsCmStatusModulationType: the upstream modulation methodology used by the CM. " ::= { docsDevCmtsNotifs 12} -- --Conformance definitions -- docsDevNotifConformance OBJECT IDENTIFIER ::= { docsDevNotifMIB 4 } docsDevNotifGroups OBJECT IDENTIFIER ::= { docsDevNotifConformance 1 } docsDevNotifCompliances OBJECT IDENTIFIER ::= { docsDevNotifConformance 2 } docsDevCmNotifCompliance MODULE-COMPLIANCE STATUS current Ahmad & Makanishi Standards Track [Page 33] RFC 4547 Event Notification MIB June 2006 DESCRIPTION "The compliance statement for CM Notifications and Control." MODULE --docsDevNotif MANDATORY-GROUPS { docsDevCmNotifControlGroup, docsDevCmNotificationGroup } ::= { docsDevNotifCompliances 1 } docsDevCmNotifControlGroup OBJECT-GROUP OBJECTS { docsDevCmNotifControl } STATUS current DESCRIPTION "This group represents objects that allow control over CM Notifications." ::= { docsDevNotifGroups 1 } docsDevCmNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { docsDevCmInitTLVUnknownNotif, docsDevCmDynServReqFailNotif, docsDevCmDynServRspFailNotif, docsDevCmDynServAckFailNotif, docsDevCmBpiInitNotif, docsDevCmBPKMNotif, docsDevCmDynamicSANotif, docsDevCmDHCPFailNotif, docsDevCmSwUpgradeInitNotif, docsDevCmSwUpgradeFailNotif, docsDevCmSwUpgradeSuccessNotif, docsDevCmSwUpgradeCVCFailNotif, docsDevCmTODFailNotif, docsDevCmDCCReqFailNotif, docsDevCmDCCRspFailNotif, docsDevCmDCCAckFailNotif } STATUS current DESCRIPTION "A collection of CM notifications providing device status and control." ::= { docsDevNotifGroups 2 } docsDevCmtsNotifCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION Ahmad & Makanishi Standards Track [Page 34] RFC 4547 Event Notification MIB June 2006 "The compliance statement for DOCSIS CMTS Notification and Control." MODULE --docsDevNotif MANDATORY-GROUPS { docsDevCmtsNotifControlGroup, docsDevCmtsNotificationGroup } ::= { docsDevNotifCompliances 2 } docsDevCmtsNotifControlGroup OBJECT-GROUP OBJECTS { docsDevCmtsNotifControl } STATUS current DESCRIPTION "This group represents objects that allow control over CMTS Notifications." ::= { docsDevNotifGroups 3 } docsDevCmtsNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { docsDevCmtsInitRegReqFailNotif, docsDevCmtsInitRegRspFailNotif, docsDevCmtsInitRegAckFailNotif , docsDevCmtsDynServReqFailNotif, docsDevCmtsDynServRspFailNotif, docsDevCmtsDynServAckFailNotif, docsDevCmtsBpiInitNotif, docsDevCmtsBPKMNotif, docsDevCmtsDynamicSANotif, docsDevCmtsDCCReqFailNotif, docsDevCmtsDCCRspFailNotif, docsDevCmtsDCCAckFailNotif } STATUS current DESCRIPTION "A collection of CMTS notifications providing device status and control." ::= { docsDevNotifGroups 4 } END 5. Contributors Thanks go to the following people, who have made significant contributions to this document: Junming Gao, Jean-Francois Mule, Dave Raftus, Pak Siripunkaw, and Rich Woundy. Ahmad & Makanishi Standards Track [Page 35] RFC 4547 Event Notification MIB June 2006 6. Acknowledgements This document was produced by the IPCDN Working Group. Thanks to Harrie Hazewinkel and Bert Wijnen for their thorough review and insightful comments on this document. Special thanks to Rich Woundy, who made several valuable suggestions to improve the notifications. 7. Security Considerations There are two management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create (docsDevCmNotifControl and docsDevCmtsNotifControl). Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Setting docsDevCmNotifControl or docsDevCmtsNotifControl may cause flooding of notifications, which can disrupt network service. Besides causing "flooding", changing the objects can also mean that notifications will not be emitted when one intends that to happen. This MIB defines a number of notification objects that send detailed information about the event that caused the generation of the notification. Information in the notification message includes: event priority, the event Id, the event message body, the CM DOCSIS capability, the CM DOCSIS QOS level, the CM DOCSIS upstream modulation type, the cable interface MAC address of the cable modem, and the cable card MAC address of the CMTS to which the modem is connected. The monitoring of these notification messages could be used to gather information about the state of the network and devices (CM and CMTS) attached to the network. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [16], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an Ahmad & Makanishi Standards Track [Page 36] RFC 4547 Event Notification MIB June 2006 instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- docsDevNotifMIB { mib-2 132 } 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [5] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999. [6] Raftus, D. and E. Cardona, "Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces", RFC 4546, June 2006. [7] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [8] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2", 2002, . Ahmad & Makanishi Standards Track [Page 37] RFC 4547 Event Notification MIB June 2006 [9] CableLabs, "Baseline Privacy Plus Interface Specification SP- BPI+040407", April 2004, . [10] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Operations Support System Interface Specification Radio Frequency Interface SCTE 22-3", 2002, . [11] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification CM-SP- OSSIv1.1-C01-050907", September 2005, . [12] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification CM-SP- OSSIv2.0-I09-050812", August 2005, . [13] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1", 2002, . [14] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification CM-SP-RFIv1.1-C01- 050907", September 2005, . [15] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification CM-SP-RFIv2.0-I10- 051209", December 2005, . 9.2. Informative References [16] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Ahmad & Makanishi Standards Track [Page 38] RFC 4547 Event Notification MIB June 2006 Authors' Addresses Azlina Ahmad Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 US Phone: 408 853 7927 EMail: azlina@cisco.com Greg Nakanishi Motorola 6450 Sequence Dr. San Diego, CA 92126 US Phone: 858 404-2366 EMail: gnakanishi@motorola.com Ahmad & Makanishi Standards Track [Page 39] RFC 4547 Event Notification MIB June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ahmad & Makanishi Standards Track [Page 40] snmp-mibs-downloader-1.1/mibrfcs/rfc4560.txt0000644000000000000000000062612411402176072015574 0ustar Network Working Group J. Quittek, Ed. Request for Comments: 4560 NEC Obsoletes: 2925 K. White, Ed. Category: Standards Track IBM Corp. June 2006 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. Quittek & White Standards Track [Page 1] RFC 4560 REMOPS MIB June 2006 Table of Contents 1. Introduction ....................................................3 1.1. Ping .......................................................3 1.2. Traceroute .................................................4 1.3. Lookup .....................................................5 1.4. Remote Operations ..........................................5 2. The Internet-Standard Management Framework ......................5 3. Structure of the MIBs ...........................................6 3.1. Ping MIB ...................................................6 3.1.1. pingMaxConcurrentRequests ...........................7 3.1.2. pingCtlTable ........................................7 3.1.3. pingResultsTable ....................................7 3.1.4. pingProbeHistoryTable ...............................8 3.2. Traceroute MIB .............................................8 3.2.1. traceRouteMaxConcurrentRequests .....................8 3.2.2. traceRouteCtlTable ..................................8 3.2.3. traceRouteResultsTable ..............................9 3.2.4. traceRouteProbeHistoryTable ........................10 3.2.5. traceRouteHopsTable ................................10 3.3. Lookup MIB ................................................10 3.3.1. lookupMaxConcurrentRequests and lookupPurgeTime ....11 3.3.2. lookupCtlTable .....................................11 3.3.3. lookupResultsTable .................................12 3.4. Conformance ...............................................12 4. Definitions ....................................................13 4.1. DISMAN-PING-MIB ...........................................13 4.2. DISMAN-TRACEROUTE-MIB .....................................46 4.3. DISMAN-NSLOOKUP-MIB .......................................84 5. Security Considerations ........................................95 6. Acknowledgements ...............................................97 7. References .....................................................97 7.1. Normative References ......................................97 7.2. Informative References ....................................98 Quittek & White Standards Track [Page 2] RFC 4560 REMOPS MIB June 2006 1. Introduction This document defines standards-based MIB modules for performing specific remote operations. The remote operations defined by this document consist of the ping, traceroute, and lookup functions. Ping and traceroute are two very useful functions for managing networks. Ping is typically used to determine whether a path exists between two hosts, whereas traceroute shows an actual path. Both ping and traceroute yield round-trip times measured in milliseconds. These times can be used as a rough approximation for network transit time. The lookup functions considered in this document are the equivalents of name to address conversion functions such as gethostbyname()/gethostbyaddr() and getaddrinfo()/getnameinfo(). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.1. Ping Ping is usually implemented using the Internet Control Message Protocol (ICMP) "ECHO" facility. It is also possible to implement a ping capability using alternate methods, including the following: o Using the UDP echo port (7), if supported. This is defined by RFC 862 [RFC862]. o Timing a Simple Network Management Protocol (SNMP) query. o Timing a TCP connect attempt. In general, almost any request/response flow can be used to generate a round-trip time. Often, many of the non-ICMP ECHO facility methods stand a better chance of yielding a good response (not timing out, for example) since some routers don't honor Echo Requests (timeout situation) or are handled at lower priority, thus possibly giving false indications of round trip times. Quittek & White Standards Track [Page 3] RFC 4560 REMOPS MIB June 2006 Note that almost any of the various methods used for generating a round-trip time can be considered a form of system attack when used excessively. Sending a system request too often can negatively effect its performance. Attempting to connect to what is supposed to be an unused port can be very unpredictable. There are tools that attempt to connect to a range of TCP ports to test that any receiving server can handle erroneous connection attempts. It is also important to a management application using a remote ping capability to know which method is being used. Different methods will yield different response times, since the protocol and resulting processing will be different. It is RECOMMENDED that the ping capability defined within this memo be implemented using the ICMP Echo Facility. 1.2. Traceroute Traceroute is usually implemented by transmitting a series of probe packets with increasing time-to-live values. A probe packet is a UDP datagram encapsulated into an IP packet. Each hop in a path to the target (destination) host rejects the probe packet (probe's TTL too small) until its time-to-live value becomes large enough for the probe to be forwarded. Each hop in a traceroute path returns an ICMP message that is used to discover the hop and to calculate a round trip time. Some systems use ICMP probes (ICMP Echo request packets) instead of UDP ones to implement traceroute. In both cases traceroute relies on the probes being rejected via an ICMP message to discover the hops taken along a path to the final destination. Both probe types, UDP and ICMP, are encapsulated into an IP packet and thus have a TTL field that can be used to cause a path rejection. Implementations of the remote traceroute capability as defined within this memo SHOULD be done using UDP packets to a (hopefully) unused port. ICMP probes (ICMP Echo Request packets) SHOULD NOT be used. Many PC implementations of traceroute use the ICMP probe method, which they should not, since this implementation method has been known to have a high probability of failure. Intermediate hops become invisible when a router either refuses to send an ICMP TTL expired message in response to an incoming ICMP packet or simply tosses ICMP echo requests altogether. The behavior of some routers not to return a TTL expired message in response to an ICMP Echo request is due in part to the following text extracted from RFC 792 [RFC792]: "The ICMP messages typically report errors in the processing of datagrams. To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages." Quittek & White Standards Track [Page 4] RFC 4560 REMOPS MIB June 2006 1.3. Lookup The Lookup operation enables remote lookup of addresses for a symbolic name as it is, for example, performed by functions getnameinfo() or gethostbyaddr() and lookup of symbolic names for an address as it is, for example, performed by functions getaddrinfo() or gethostbyname(). Note that whatever lookup function is chosen, results are not necessarily consistent with the results of a pure Domain Name Service (DNS) lookup, but may be influenced by local lookup tables or other sources of information. The lookup capability can be used to determine the symbolic name of a hop in a traceroute path. Also, the reverse lookup can be used, for example, for analyzing name lookup problems. 1.4. Remote Operations The MIB modules defined in this document allow a management station to initiate ping, traceroute, and lookup operations remotely. The basic scenario is illustrated by the following diagram. +-------+ +-------+ +-------+ | |---------->| | | | | | initiate | |---------->| | | Mgmt. | operation |Managed| perform |Target | |Station| remotely | Node | operation | Host | | | | | | | | |<----------| | | | +-------+ receive +-------+ +-------+ result of operation A management station is the local host from which the remote ping, traceroute, or Lookup operation is initiated using an SNMP request. The managed node is a remote host where the MIBs defined by this memo are implemented. It receives the remote operation via SNMP and performs the actual ping, traceroute, or lookup function. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Quittek & White Standards Track [Page 5] RFC 4560 REMOPS MIB June 2006 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Structure of the MIBs This document defines three MIB modules: o DISMAN-PING-MIB Defines a ping MIB. o DISMAN-TRACEROUTE-MIB Defines a traceroute MIB. o DISMAN-NSLOOKUP-MIB Provides access to lookup functions for symbolic names and addresses at a remote host provided, for example, by functions getaddrinfo()/getnameinfo() and gethostbyname()/gethostbyaddr(). The ping and traceroute MIBs are structured to allow creation of ping or traceroute tests that can be set up to issue a series of operations periodically and to generate NOTIFICATIONs to report on test results. Many network administrators have in the past written UNIX shell scripts or command batch files to operate in a fashion similar to the functionality provided by the ping and traceroute MIBs defined within this memo. The intent of this document is to acknowledge the importance of these functions and to provide a standards-based solution. 3.1. Ping MIB The DISMAN-PING-MIB consists of the following components: o pingMaxConcurrentRequests o pingCtlTable o pingResultsTable o pingProbeHistoryTable Quittek & White Standards Track [Page 6] RFC 4560 REMOPS MIB June 2006 3.1.1. pingMaxConcurrentRequests The object pingMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation supports. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value. 3.1.2. pingCtlTable A remote ping test is started by setting pingCtlAdminStatus to enabled(1). The corresponding pingCtlEntry MUST have been created, and its pingCtlRowStatus set to active(1), prior to starting the test. A single SNMP PDU can be used to create and start a remote ping test. Within the PDU, pingCtlTargetAddress should be set to the target host's address (pingCtlTargetAddressType will default to ipv4(1)), pingCtlAdminStatus to enabled(1), and pingCtlRowStatus to createAndGo(4). The first index element, pingCtlOwnerIndex, is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and that allows a management application to identify its entries. The second index, pingCtlTestName (also an SnmpAdminString), enables the same management application to have multiple requests outstanding. Using the maximum value for the parameters defined within a pingEntry can result in a single remote ping test's taking at most 15 minutes (pingCtlTimeOut times pingCtlProbeCount), plus whatever time it takes to send the ping request and to receive its response over the network from the target host. Use of the defaults for pingCtlTimeOut and pingCtlProbeCount yields a maximum of 3 seconds to perform a "normal" ping test. A management application can delete an active remote ping request by setting the corresponding pingCtlRowStatus object to destroy(6). The contents of the pingCtlTable are preserved across reIPLs (Initial Program Loads) of its agent according the values of each of the pingCtlStorageType objects. 3.1.3. pingResultsTable An entry in the pingResultsTable is created for a corresponding pingCtlEntry once the test defined by this entry is started. Quittek & White Standards Track [Page 7] RFC 4560 REMOPS MIB June 2006 3.1.4. pingProbeHistoryTable The results of past ping probes are stored in this table on a per- pingCtlEntry basis. This table is initially indexed by pingCtlOwnerIndex and pingCtlTestName so that the results of a probe relate to the pingCtlEntry that caused it. The maximum number of entries stored in this table per pingCtlEntry is determined by the value of pingCtlMaxRows. An implementation of this MIB will remove the oldest entry in the pingProbeHistoryTable of the corresponding entry in the pingCtlTable to allow the addition of a new entry once the number of rows in the pingProbeHistoryTable reaches the value specified by pingCtlMaxRows for the corresponding entry in the pingCtlTable. An implementation MUST start assigning pingProbeHistoryIndex values at 1 and wrap after exceeding the maximum possible value, as defined by the limit of this object ('ffffffff'h). 3.2. Traceroute MIB The DISMAN-TRACEROUTE-MIB consists of the following components: o traceRouteMaxConcurrentRequests o traceRouteCtlTable o traceRouteResultsTable o traceRouteProbeHistoryTable o traceRouteHopsTable 3.2.1. traceRouteMaxConcurrentRequests The object traceRouteMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation supports. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value. 3.2.2. traceRouteCtlTable A remote traceroute test is started by setting traceRouteCtlAdminStatus to enabled(1). The corresponding traceRouteCtlEntry MUST have been created, and its traceRouteCtlRowStatus set to active(1), prior to starting the test. A single SNMP PDU can be used to create and start a remote traceroute Quittek & White Standards Track [Page 8] RFC 4560 REMOPS MIB June 2006 test. Within the PDU, traceRouteCtlTargetAddress should be set to the target host's address (traceRouteCtlTargetAddressType will default to ipv4(1)), traceRouteCtlAdminStatus to enabled(1), and traceRouteCtlRowStatus to createAndGo(4). The first index element, traceRouteCtlOwnerIndex, is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and that allows a management application to identify its entries. The second index, traceRouteCtlTestName (also an SnmpAdminString), enables the same management application to have multiple requests outstanding. Traceroute has a much longer theoretical maximum time for completion than ping: basically, 42 hours and 30 minutes (the product of traceRouteCtlTimeOut, traceRouteCtlProbesPerHop, and traceRouteCtlMaxTtl) plus some network transit time! Use of the defaults defined within an traceRouteCtlEntry yields a maximum of 4 minutes and 30 seconds for a default traceroute operation. Clearly, 42 plus hours is too long to wait for a traceroute operation to be completed. The maximum Time to Live (TTL) value in effect for traceroute determines how long the traceroute function will keep increasing the TTL value in the probe it transmits, hoping to reach the target host. The function ends whenever the maximum TTL is exceeded or the target host is reached. The object traceRouteCtlMaxFailures was created in order to impose a throttle for how long traceroute continues to increase the TTL field in a probe without receiving any kind of response (timeouts). It is RECOMMENDED that agent implementations impose a time limit for how long it allows a traceroute operation to take, relative to how the function is implemented. For example, an implementation that can't process multiple traceroute operations at the same time SHOULD impose a shorter maximum allowed time period. A management application can delete an active remote traceroute request by setting the corresponding traceRouteCtlRowStatus object to destroy(6). The contents of the traceRouteCtlTable are preserved across reIPLs (Initial Program Loads) of its agent according to the values of each of the traceRouteCtlStorageType objects. 3.2.3. traceRouteResultsTable An entry in the traceRouteResultsTable is created upon determining the results of a specific traceroute operation. Entries in this table relate back to the traceRouteCtlEntry that caused the Quittek & White Standards Track [Page 9] RFC 4560 REMOPS MIB June 2006 corresponding traceroute operation to occur. The objects traceRouteResultsCurHopCount and traceRouteResultsCurProbeCount can be examined to determine how far the current remote traceroute operation has reached. 3.2.4. traceRouteProbeHistoryTable The results of past traceroute probes can be stored in this table on a per-traceRouteCtlEntry basis. This table is initially indexed by traceRouteCtlOwnerIndex and traceRouteCtlTestName so that the results of a probe relate to the traceRouteCtlEntry that caused it. The number of entries stored in this table per traceRouteCtlEntry is determined by the value of traceRouteCtlMaxRows. An implementation of this MIB will remove the oldest entry in the traceRouteProbeHistoryTable of the corresponding entry in the traceRouteCtlTable to allow the addition of an new entry once the number of rows in the traceRouteProbeHistoryTable reaches the value of traceRouteCtlMaxRows for the corresponding entry in the traceRouteCtlTable. An implementation MUST start assigning traceRouteProbeHistoryIndex values at 1 and wrap after exceeding the maximum possible value, as defined by the limit of this object ('ffffffff'h). 3.2.5. traceRouteHopsTable The current traceroute path can be stored in this table on a per- traceRouteCtlEntry basis. This table is initially indexed by traceRouteCtlOwnerIndex and traceRouteCtlTestName so that a traceroute path relates to the traceRouteCtlEntry that caused it. A third index, traceRouteHopsHopIndex, enables keeping one traceRouteHopsEntry per traceroute hop. Creation of traceRouteHopsTable entries is enabled by setting the corresponding traceRouteCtlCreateHopsEntries object to true(1). 3.3. Lookup MIB The DISMAN-NSLOOKUP-MIB consists of the following components: o lookupMaxConcurrentRequests and lookupPurgeTime o lookupCtlTable o lookupResultsTable Quittek & White Standards Track [Page 10] RFC 4560 REMOPS MIB June 2006 3.3.1. lookupMaxConcurrentRequests and lookupPurgeTime The object lookupMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation is structured to support. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value. The object lookupPurgeTime provides a method for entries in the lookupCtlTable and lookupResultsTable to be automatically deleted after the corresponding operation is completed. 3.3.2. lookupCtlTable A remote lookup operation is initiated by performing an SNMP SET request on lookupCtlRowStatus. A single SNMP PDU can be used to create and start a remote lookup operation. Within the PDU, lookupCtlTargetAddress should be set to the entity to be resolved (lookupCtlTargetAddressType will default to ipv4(1)) and lookupCtlRowStatus to createAndGo(4). The object lookupCtlOperStatus can be examined to determine the state of a lookup operation. A management application can delete an active remote lookup request by setting the corresponding lookupCtlRowStatus object to destroy(6). An lookupCtlEntry is initially indexed by lookupCtlOwnerIndex, which is a type of SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and that also allows for a management application to identify its entries. The lookupCtlOwnerIndex portion of the index is then followed by lookupCtlOperationName. The lookupCtlOperationName index enables the same lookupCtlOwnerIndex entity to have multiple outstanding requests. The value of lookupCtlTargetAddressType determines which lookup function to perform. Specification of dns(16) as the value of this index implies that a function such as getaddrinfo() or gethostbyname() should be performed to determine the numeric addresses associated with a symbolic name via lookupResultsTable entries. Use of a value of either ipv4(1) or ipv6(2) implies that a function such as getnameinfo() or gethostbyaddr() should be performed to determine the symbolic name(s) associated with a numeric address at a remote host. Quittek & White Standards Track [Page 11] RFC 4560 REMOPS MIB June 2006 3.3.3. lookupResultsTable The lookupResultsTable is used to store the results of lookup operations. Results to be reported here SHOULD be results of a lookup function that is commonly used by applications at the managed node. This implies that results are not necessarily consistent with the results of a pure DNS lookup at the managed node, but may be influenced by local lookup tables or other sources of information, depending on the configuration of the managed node. The lookupResultsTable is initially indexed by the same index elements that the lookupCtlTable contains (lookupCtlOwnerIndex and lookupCtlOperationName) but has a third index element, lookupResultsIndex (Unsigned32 textual convention), in order to associate multiple results with the same lookupCtlEntry. A remote host can be multi-homed and can have multiple symbolic (DNS) names. Therefore, a lookup operation can return multiple IP addresses and multiple symbolic names. If the lookup operation was performed for a certain address by using getnameinfo() or gethostbyaddr(), for example, then entries in the lookupResultsTable MUST be made for each host name returned. If the lookup operation identifies one hostname as the host's 'official host name', then this name MUST be assigned a lookupResultsIndex of 1. If a lookup operation was performed for a certain symbolic name by using getaddrinfo() or gethostbyname(), for example, then entries in the lookupResultsTable MUST be made for each address returned. The entries MUST be stored in the order that they are retrieved. Values assigned to lookupResultsIndex MUST start at 1 and increase in order. An implementation SHOULD NOT retain SNMP-created entries in the lookupResultsTable across reIPLs (Initial Program Loads) of its agent, since management applications need to see consistent behavior with respect to the persistence of the table entries that they create. 3.4. Conformance Each of the three MIB modules defined in this document has two current compliance statements, one for full compliance and one for minimum compliance. The minimum compliance statements are intended to be applied to implementation for devices with very limited resources. The main difference between full and minimum compliance is that for minimum compliance, dynamic creation and deletion of table entries is not required, whereas it is required for full compliance. Quittek & White Standards Track [Page 12] RFC 4560 REMOPS MIB June 2006 In addition, the DISMAN-PING-MIB module and the DISMAN-TRACEROUTE-MIB modules each have a deprecated compliance statement that was current in RFC 2925. Semantically, the new full compliance statements are identical to the deprecated ones. But some of the object groups used in the old compliance statements needed to be split in order to support the new minimal compliance statements. 4. Definitions The following MIB modules import from [RFC2863], [RFC3411], and [RFC4001]. They also use the REFERENCE clause to reference [RFC1812], [RFC2474], and [RFC3260]. 4.1. DISMAN-PING-MIB DISMAN-PING-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Gauge32, mib-2, NOTIFICATION-TYPE, OBJECT-IDENTITY FROM SNMPv2-SMI -- RFC2578 TEXTUAL-CONVENTION, RowStatus, StorageType, DateAndTime, TruthValue FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC2580 InterfaceIndexOrZero -- RFC2863 FROM IF-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC3411 InetAddressType, InetAddress FROM INET-ADDRESS-MIB; -- RFC4001 pingMIB MODULE-IDENTITY LAST-UPDATED "200606130000Z" -- 13 June 2006 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-115 Quittek & White Standards Track [Page 13] RFC 4560 REMOPS MIB June 2006 Email: quittek@netlab.nec.de" DESCRIPTION "The Ping MIB (DISMAN-PING-MIB) provides the capability of controlling the use of the ping function at a remote host. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4560; see the RFC itself for full legal notices." -- Revision history REVISION "200606130000Z" -- 13 June 2006 DESCRIPTION "Updated version, published as RFC 4560. - Correctly considered IPv6 in DESCRIPTION clause of pingCtlDataSize - Replaced references to RFC 2575 by RFC 3415 - Replaced references to RFC 2571 by RFC 3411 - Replaced references to RFC 2851 by RFC 4001 - Added DEFVAL { {} } to definition of pingCtlTrapGeneration - Changed DEFVAL of object pingCtlDescr from DEFVAL { '00'H } to DEFVAL { ''H } - Changed DEFVAL of object pingCtlSourceAddressType from DEFVAL { ipv4 } to DEFVAL { unknown } - Extended DESCRIPTION clause of pingResultsTable describing re-initialization of entries - Changed SYNTAX of pingResultsProbeResponses and pingResultsSentProbes from Unsigned32 to Gauge32 - Changed status of pingCompliance to deprecated - Added pingFullCompliance and pingMinimumCompliance - Changed status of pingGroup and pingTimeStampGroup to deprecated - Added pingMinimumGroup, pingCtlRowStatusGroup, and pingHistoryGroup" REVISION "200009210000Z" -- 21 September 2000 DESCRIPTION "Initial version, published as RFC 2925." ::= { mib-2 80 } -- Textual Conventions OperationResponseStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Quittek & White Standards Track [Page 14] RFC 4560 REMOPS MIB June 2006 "Used to report the result of an operation: responseReceived(1) - Operation is completed successfully. unknown(2) - Operation failed due to unknown error. internalError(3) - An implementation detected an error in its own processing that caused an operation to fail. requestTimedOut(4) - Operation failed to receive a valid reply within the time limit imposed on it. unknownDestinationAddress(5) - Invalid destination address. noRouteToTarget(6) - Could not find a route to target. interfaceInactiveToTarget(7) - The interface to be used in sending a probe is inactive, and an alternate route does not exist. arpFailure(8) - Unable to resolve a target address to a media-specific address. maxConcurrentLimitReached(9) - The maximum number of concurrent active operations would have been exceeded if the corresponding operation was allowed. unableToResolveDnsName(10) - The DNS name specified was unable to be mapped to an IP address. invalidHostAddress(11) - The IP address for a host has been determined to be invalid. Examples of this are broadcast or multicast addresses." SYNTAX INTEGER { responseReceived(1), unknown(2), internalError(3), requestTimedOut(4), unknownDestinationAddress(5), noRouteToTarget(6), interfaceInactiveToTarget(7), arpFailure(8), maxConcurrentLimitReached(9), unableToResolveDnsName(10), invalidHostAddress(11) } -- Top level structure of the MIB pingNotifications OBJECT IDENTIFIER ::= { pingMIB 0 } pingObjects OBJECT IDENTIFIER ::= { pingMIB 1 } pingConformance OBJECT IDENTIFIER ::= { pingMIB 2 } -- The registration node (point) for ping implementation types Quittek & White Standards Track [Page 15] RFC 4560 REMOPS MIB June 2006 pingImplementationTypeDomains OBJECT IDENTIFIER ::= { pingMIB 3 } pingIcmpEcho OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates that an implementation is using the Internet Control Message Protocol (ICMP) 'ECHO' facility." ::= { pingImplementationTypeDomains 1 } pingUdpEcho OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates that an implementation is using the UDP echo port (7)." REFERENCE "RFC 862, 'Echo Protocol'." ::= { pingImplementationTypeDomains 2 } pingSnmpQuery OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates that an implementation is using an SNMP query to calculate a round trip time." ::= { pingImplementationTypeDomains 3 } pingTcpConnectionAttempt OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates that an implementation is attempting to connect to a TCP port in order to calculate a round trip time." ::= { pingImplementationTypeDomains 4 } -- Simple Object Definitions pingMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active ping requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect. Quittek & White Standards Track [Page 16] RFC 4560 REMOPS MIB June 2006 The limit applies only to new requests being activated. When a new value is set, the agent will continue processing all the requests already active, even if their number exceeds the limit just imposed." DEFVAL { 10 } ::= { pingObjects 1 } -- Ping Control Table pingCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF PingCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the ping Control Table for providing, via SNMP, the capability of performing ping operations at a remote host. The results of these operations are stored in the pingResultsTable and the pingProbeHistoryTable." ::= { pingObjects 2 } pingCtlEntry OBJECT-TYPE SYNTAX PingCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the pingCtlTable. The first index element, pingCtlOwnerIndex, is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415, VACM) and that allows a management application to identify its entries. The second index, pingCtlTestName (also an SnmpAdminString), enables the same management application to have multiple outstanding requests." INDEX { pingCtlOwnerIndex, pingCtlTestName } ::= { pingCtlTable 1 } PingCtlEntry ::= SEQUENCE { pingCtlOwnerIndex SnmpAdminString, pingCtlTestName SnmpAdminString, pingCtlTargetAddressType InetAddressType, pingCtlTargetAddress InetAddress, pingCtlDataSize Unsigned32, pingCtlTimeOut Unsigned32, Quittek & White Standards Track [Page 17] RFC 4560 REMOPS MIB June 2006 pingCtlProbeCount Unsigned32, pingCtlAdminStatus INTEGER, pingCtlDataFill OCTET STRING, pingCtlFrequency Unsigned32, pingCtlMaxRows Unsigned32, pingCtlStorageType StorageType, pingCtlTrapGeneration BITS, pingCtlTrapProbeFailureFilter Unsigned32, pingCtlTrapTestFailureFilter Unsigned32, pingCtlType OBJECT IDENTIFIER, pingCtlDescr SnmpAdminString, pingCtlSourceAddressType InetAddressType, pingCtlSourceAddress InetAddress, pingCtlIfIndex InterfaceIndexOrZero, pingCtlByPassRouteTable TruthValue, pingCtlDSField Unsigned32, pingCtlRowStatus RowStatus } pingCtlOwnerIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (RFC 2575, VACM) for tables in which multiple users may need to create or modify entries independently, the initial index is used as an 'owner index'. Such an initial index has a syntax of SnmpAdminString and can thus be trivially mapped to a securityName or groupName defined in VACM, in accordance with a security policy. When used in conjunction with such a security policy, all entries in the table belonging to a particular user (or group) will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the 'column' subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask 'wildcarding' the column subidentifier. More elaborate configurations are possible." ::= { pingCtlEntry 1 } Quittek & White Standards Track [Page 18] RFC 4560 REMOPS MIB June 2006 pingCtlTestName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the ping test. This is locally unique, within the scope of a pingCtlOwnerIndex." ::= { pingCtlEntry 2 } pingCtlTargetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the type of host address to be used at a remote host for performing a ping operation." DEFVAL { unknown } ::= { pingCtlEntry 3 } pingCtlTargetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the host address to be used at a remote host for performing a ping operation. The host address type is determined by the value of the corresponding pingCtlTargetAddressType. A value for this object MUST be set prior to transitioning its corresponding pingCtlEntry to active(1) via pingCtlRowStatus." DEFVAL { ''H } ::= { pingCtlEntry 4 } pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation, in octets. Whether this value can be applied depends on the selected implementation method for performing a ping operation, indicated by pingCtlType in the same conceptual row. If the method used allows applying the value contained Quittek & White Standards Track [Page 19] RFC 4560 REMOPS MIB June 2006 in this object, then it MUST be applied. If the specified size is not appropriate for the chosen ping method, the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by subtracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." DEFVAL { 0 } ::= { pingCtlEntry 5 } pingCtlTimeOut OBJECT-TYPE SYNTAX Unsigned32 (1..60) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the time-out value, in seconds, for a remote ping operation." DEFVAL { 3 } ::= { pingCtlEntry 6 } pingCtlProbeCount OBJECT-TYPE SYNTAX Unsigned32 (1..15) UNITS "probes" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the number of times to perform a ping operation at a remote host as part of a single ping test." DEFVAL { 1 } ::= { pingCtlEntry 7 } pingCtlAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- test should be started disabled(2) -- test should be stopped } MAX-ACCESS read-create STATUS current DESCRIPTION "Reflects the desired state that a pingCtlEntry should be in: Quittek & White Standards Track [Page 20] RFC 4560 REMOPS MIB June 2006 enabled(1) - Attempt to activate the test as defined by this pingCtlEntry. disabled(2) - Deactivate the test as defined by this pingCtlEntry. Refer to the corresponding pingResultsOperStatus to determine the operational state of the test defined by this entry." DEFVAL { disabled } ::= { pingCtlEntry 8 } pingCtlDataFill OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "The content of this object is used together with the corresponding pingCtlDataSize value to determine how to fill the data portion of a probe packet. The option of selecting a data fill pattern can be useful when links are compressed or have data pattern sensitivities. The contents of pingCtlDataFill should be repeated in a ping packet when the size of the data portion of the ping packet is greater than the size of pingCtlDataFill." DEFVAL { '00'H } ::= { pingCtlEntry 9 } pingCtlFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait before repeating a ping test as defined by the value of the various objects in the corresponding row. A single ping test consists of a series of ping probes. The number of probes is determined by the value of the corresponding pingCtlProbeCount object. After a single test is completed the number of seconds as defined by the value of pingCtlFrequency MUST elapse before the next ping test is started. A value of 0 for this object implies that the test as defined by the corresponding entry will not be repeated." DEFVAL { 0 } Quittek & White Standards Track [Page 21] RFC 4560 REMOPS MIB June 2006 ::= { pingCtlEntry 10 } pingCtlMaxRows OBJECT-TYPE SYNTAX Unsigned32 UNITS "rows" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of corresponding entries allowed in the pingProbeHistoryTable. An implementation of this MIB will remove the oldest corresponding entry in the pingProbeHistoryTable to allow the addition of an new entry once the number of corresponding rows in the pingProbeHistoryTable reaches this value. Old entries are not removed when a new test is started. Entries are added to the pingProbeHistoryTable until pingCtlMaxRows is reached before entries begin to be removed. A value of 0 for this object disables creation of pingProbeHistoryTable entries." DEFVAL { 50 } ::= { pingCtlEntry 11 } pingCtlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { pingCtlEntry 12 } pingCtlTrapGeneration OBJECT-TYPE SYNTAX BITS { probeFailure(0), testFailure(1), testCompletion(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object determines when and whether to generate a notification for this entry: Quittek & White Standards Track [Page 22] RFC 4560 REMOPS MIB June 2006 probeFailure(0) - Generate a pingProbeFailed notification subject to the value of pingCtlTrapProbeFailureFilter. The object pingCtlTrapProbeFailureFilter can be used to specify the number of consecutive probe failures that are required before a pingProbeFailed notification can be generated. testFailure(1) - Generate a pingTestFailed notification. In this instance the object pingCtlTrapTestFailureFilter can be used to determine the number of probe failures that signal when a test fails. testCompletion(2) - Generate a pingTestCompleted notification. By default, no bits are set, indicating that none of the above options is selected." DEFVAL { {} } -- no bits set. ::= { pingCtlEntry 13 } pingCtlTrapProbeFailureFilter OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is used to determine when to generate a pingProbeFailed NOTIFICATION. Setting BIT probeFailure(0) of object pingCtlTrapGeneration to '1' implies that a pingProbeFailed NOTIFICATION is generated only when a number of consecutive ping probes equal to the value of pingCtlTrapProbeFailureFilter fail within a given ping test. After triggering the notification, the probe failure counter is reset to zero." DEFVAL { 1 } ::= { pingCtlEntry 14 } pingCtlTrapTestFailureFilter OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is used to determine when to generate a pingTestFailed NOTIFICATION. Setting BIT testFailure(1) of object Quittek & White Standards Track [Page 23] RFC 4560 REMOPS MIB June 2006 pingCtlTrapGeneration to '1' implies that a pingTestFailed NOTIFICATION is generated only when a number of consecutive ping tests equal to the value of pingCtlTrapProbeFailureFilter fail. After triggering the notification, the test failure counter is reset to zero." DEFVAL { 1 } ::= { pingCtlEntry 15 } pingCtlType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is used either to report or to select the implementation method to be used for calculating a ping response time. The value of this object MAY be selected from pingImplementationTypeDomains. Additional implementation types SHOULD be allocated as required by implementers of the DISMAN-PING-MIB under their enterprise-specific registration point and not beneath pingImplementationTypeDomains." DEFVAL { pingIcmpEcho } ::= { pingCtlEntry 16 } pingCtlDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The purpose of this object is to provide a descriptive name of the remote ping test." DEFVAL { ''H } ::= { pingCtlEntry 17 } pingCtlSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the type of the source address, pingCtlSourceAddress, to be used at a remote host when a ping operation is performed." DEFVAL { unknown } ::= { pingCtlEntry 18 } Quittek & White Standards Track [Page 24] RFC 4560 REMOPS MIB June 2006 pingCtlSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Use the specified IP address (which must be given in numeric form, not as a hostname) as the source address in outgoing probe packets. On hosts with more than one IP address, this option can be used to select the address to be used. If the IP address is not one of this machine's interface addresses, an error is returned and nothing is sent. A zero-length octet string value for this object disables source address specification. The address type (InetAddressType) that relates to this object is specified by the corresponding value of pingCtlSourceAddressType." DEFVAL { ''H } ::= { pingCtlEntry 19 } pingCtlIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Setting this object to an interface's ifIndex prior to starting a remote ping operation directs the ping probes to be transmitted over the specified interface. A value of zero for this object means that this option is not enabled." DEFVAL { 0 } ::= { pingCtlEntry 20 } pingCtlByPassRouteTable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The purpose of this object is to enable optional bypassing the route table. If enabled, the remote host will bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly attached network, an error is returned. This option can be used to perform the ping operation to a local host through an interface that has no route defined (e.g., after the interface was dropped by the routing daemon at the host)." Quittek & White Standards Track [Page 25] RFC 4560 REMOPS MIB June 2006 DEFVAL { false } ::= { pingCtlEntry 21 } pingCtlDSField OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the value to store in the Type of Service (TOS) octet in the IPv4 header or in the Traffic Class octet in the IPv6 header, respectively, of the IP packet used to encapsulate the ping probe. The octet to be set in the IP header contains the Differentiated Services (DS) Field in the six most significant bits. This option can be used to determine what effect an explicit DS Field setting has on a ping response. Not all values are legal or meaningful. A value of 0 means that the function represented by this option is not supported. DS Field usage is often not supported by IP implementations, and not all values are supported. Refer to RFC 2474 and RFC 3260 for guidance on usage of this field." REFERENCE "Refer to RFC 1812 for the definition of the IPv4 TOS octet and to RFC 2460 for the definition of the IPv6 Traffic Class octet. Refer to RFC 2474 and RFC 3260 for the definition of the Differentiated Services Field." DEFVAL { 0 } ::= { pingCtlEntry 22 } pingCtlRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the pingCtlTable. Deletion of an entry in this table results in the deletion of all corresponding (same pingCtlOwnerIndex and pingCtlTestName index values) pingResultsTable and pingProbeHistoryTable entries. A value MUST be specified for pingCtlTargetAddress prior to acceptance of a transition to active(1) state. When a value for pingCtlTargetAddress is set, Quittek & White Standards Track [Page 26] RFC 4560 REMOPS MIB June 2006 the value of object pingCtlRowStatus changes from notReady(3) to notInService(2). Activation of a remote ping operation is controlled via pingCtlAdminStatus, not by changing this object's value to active(1). Transitions in and out of active(1) state are not allowed while an entry's pingResultsOperStatus is active(1), with the exception that deletion of an entry in this table by setting its RowStatus object to destroy(6) will stop an active ping operation. The operational state of a ping operation can be determined by examination of its pingResultsOperStatus object." REFERENCE "See definition of RowStatus in RFC 2579, 'Textual Conventions for SMIv2.'" ::= { pingCtlEntry 23 } -- Ping Results Table pingResultsTable OBJECT-TYPE SYNTAX SEQUENCE OF PingResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Ping Results Table for providing the capability of performing ping operations at a remote host. The results of these operations are stored in the pingResultsTable and the pingProbeHistoryTable. An entry is added to the pingResultsTable when an pingCtlEntry is started by successful transition of its pingCtlAdminStatus object to enabled(1). If the object pingCtlAdminStatus already has the value enabled(1), and if the corresponding pingResultsOperStatus object has the value completed(3), then successfully writing enabled(1) to object pingCtlAdminStatus re-initializes the already existing entry in the pingResultsTable. The values of objects in the re-initialized entry are the same as the values of objects in a new entry would be. An entry is removed from the pingResultsTable when its corresponding pingCtlEntry is deleted." Quittek & White Standards Track [Page 27] RFC 4560 REMOPS MIB June 2006 ::= { pingObjects 3 } pingResultsEntry OBJECT-TYPE SYNTAX PingResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the pingResultsTable. The pingResultsTable has the same indexing as the pingCtlTable so that a pingResultsEntry corresponds to the pingCtlEntry that caused it to be created." INDEX { pingCtlOwnerIndex, pingCtlTestName } ::= { pingResultsTable 1 } PingResultsEntry ::= SEQUENCE { pingResultsOperStatus INTEGER, pingResultsIpTargetAddressType InetAddressType, pingResultsIpTargetAddress InetAddress, pingResultsMinRtt Unsigned32, pingResultsMaxRtt Unsigned32, pingResultsAverageRtt Unsigned32, pingResultsProbeResponses Gauge32, pingResultsSentProbes Gauge32, pingResultsRttSumOfSquares Unsigned32, pingResultsLastGoodProbe DateAndTime } pingResultsOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- test is in progress disabled(2), -- test has stopped completed(3) -- test is completed } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of a pingCtlEntry: enabled(1) - Test is active. disabled(2) - Test has stopped. completed(3) - Test is completed." ::= { pingResultsEntry 1 } Quittek & White Standards Track [Page 28] RFC 4560 REMOPS MIB June 2006 pingResultsIpTargetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of address stored in the corresponding pingResultsIpTargetAddress object." DEFVAL { unknown } ::= { pingResultsEntry 2 } pingResultsIpTargetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object reports the IP address associated with a pingCtlTargetAddress value when the destination address is specified as a DNS name. The value of this object should be a zero-length octet string when a DNS name is not specified or when a specified DNS name fails to resolve. The address type (InetAddressType) that relates to this object is specified by the corresponding value of pingResultsIpTargetAddressType." DEFVAL { ''H } ::= { pingResultsEntry 3 } pingResultsMinRtt OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum ping round-trip-time (RTT) received. A value of 0 for this object implies that no RTT has been received." ::= { pingResultsEntry 4 } pingResultsMaxRtt OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum ping round-trip-time (RTT) received. A value of 0 for this object implies that no RTT has been received." Quittek & White Standards Track [Page 29] RFC 4560 REMOPS MIB June 2006 ::= { pingResultsEntry 5 } pingResultsAverageRtt OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The current average ping round-trip-time (RTT)." ::= { pingResultsEntry 6 } pingResultsProbeResponses OBJECT-TYPE SYNTAX Gauge32 UNITS "responses" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses received for the corresponding pingCtlEntry and pingResultsEntry. The value of this object MUST be reported as 0 when no probe responses have been received." ::= { pingResultsEntry 7 } pingResultsSentProbes OBJECT-TYPE SYNTAX Gauge32 UNITS "probes" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reflects the number of probes sent for the corresponding pingCtlEntry and pingResultsEntry. The value of this object MUST be reported as 0 when no probes have been sent." ::= { pingResultsEntry 8 } pingResultsRttSumOfSquares OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the sum of the squares for all ping responses received. Its purpose is to enable standard deviation calculation. The value of this object MUST be reported as 0 when no ping responses have been received." ::= { pingResultsEntry 9 } Quittek & White Standards Track [Page 30] RFC 4560 REMOPS MIB June 2006 pingResultsLastGoodProbe OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Date and time when the last response was received for a probe." ::= { pingResultsEntry 10 } -- Ping Probe History Table pingProbeHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF PingProbeHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a table for storing the results of ping operations. The number of entries in this table is limited per entry in the pingCtlTable by the value of the corresponding pingCtlMaxRows object. An entry in this table is created when the result of a ping probe is determined. The initial 2 instance identifier index values identify the pingCtlEntry that a probe result (pingProbeHistoryEntry) belongs to. An entry is removed from this table when its corresponding pingCtlEntry is deleted. An implementation of this MIB will remove the oldest entry in the pingProbeHistoryTable of the corresponding entry in the pingCtlTable to allow the addition of an new entry once the number of rows in the pingProbeHistoryTable reaches the value specified by pingCtlMaxRows for the corresponding entry in the pingCtlTable." ::= { pingObjects 4 } pingProbeHistoryEntry OBJECT-TYPE SYNTAX PingProbeHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the pingProbeHistoryTable. The first two index elements identify the pingCtlEntry that a pingProbeHistoryEntry belongs to. The third index element selects a single probe result." INDEX { Quittek & White Standards Track [Page 31] RFC 4560 REMOPS MIB June 2006 pingCtlOwnerIndex, pingCtlTestName, pingProbeHistoryIndex } ::= { pingProbeHistoryTable 1 } PingProbeHistoryEntry ::= SEQUENCE { pingProbeHistoryIndex Unsigned32, pingProbeHistoryResponse Unsigned32, pingProbeHistoryStatus OperationResponseStatus, pingProbeHistoryLastRC Integer32, pingProbeHistoryTime DateAndTime } pingProbeHistoryIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created when the result of a ping probe is determined. The initial 2 instance identifier index values identify the pingCtlEntry that a probe result (pingProbeHistoryEntry) belongs to. An implementation MUST start assigning pingProbeHistoryIndex values at 1 and wrap after exceeding the maximum possible value as defined by the limit of this object ('ffffffff'h)." ::= { pingProbeHistoryEntry 1 } pingProbeHistoryResponse OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time measured in milliseconds from when a probe was sent to when its response was received or when it timed out. The value of this object is reported as 0 when it is not possible to transmit a probe." ::= { pingProbeHistoryEntry 2 } pingProbeHistoryStatus OBJECT-TYPE SYNTAX OperationResponseStatus MAX-ACCESS read-only STATUS current Quittek & White Standards Track [Page 32] RFC 4560 REMOPS MIB June 2006 DESCRIPTION "The result of a particular probe done by a remote host." ::= { pingProbeHistoryEntry 3 } pingProbeHistoryLastRC OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The last implementation-method-specific reply code received. If the ICMP Echo capability is being used, then a successful probe ends when an ICMP response is received that contains the code ICMP_ECHOREPLY(0). The ICMP codes are maintained by IANA. Standardized ICMP codes are listed at http://www.iana.org/assignments/icmp-parameters. The ICMPv6 codes are listed at http://www.iana.org/assignments/icmpv6-parameters." ::= { pingProbeHistoryEntry 4 } pingProbeHistoryTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Timestamp for when this probe result was determined." ::= { pingProbeHistoryEntry 5 } -- Notification Definition section pingProbeFailed NOTIFICATION-TYPE OBJECTS { pingCtlTargetAddressType, pingCtlTargetAddress, pingResultsOperStatus, pingResultsIpTargetAddressType, pingResultsIpTargetAddress, pingResultsMinRtt, pingResultsMaxRtt, pingResultsAverageRtt, pingResultsProbeResponses, pingResultsSentProbes, pingResultsRttSumOfSquares, pingResultsLastGoodProbe } STATUS current DESCRIPTION "Generated when a probe failure is detected, when the Quittek & White Standards Track [Page 33] RFC 4560 REMOPS MIB June 2006 corresponding pingCtlTrapGeneration object is set to probeFailure(0), subject to the value of pingCtlTrapProbeFailureFilter. The object pingCtlTrapProbeFailureFilter can be used to specify the number of consecutive probe failures that are required before this notification can be generated." ::= { pingNotifications 1 } pingTestFailed NOTIFICATION-TYPE OBJECTS { pingCtlTargetAddressType, pingCtlTargetAddress, pingResultsOperStatus, pingResultsIpTargetAddressType, pingResultsIpTargetAddress, pingResultsMinRtt, pingResultsMaxRtt, pingResultsAverageRtt, pingResultsProbeResponses, pingResultsSentProbes, pingResultsRttSumOfSquares, pingResultsLastGoodProbe } STATUS current DESCRIPTION "Generated when a ping test is determined to have failed, when the corresponding pingCtlTrapGeneration object is set to testFailure(1). In this instance, pingCtlTrapTestFailureFilter should specify the number of probes in a test required to have failed in order to consider the test failed." ::= { pingNotifications 2 } pingTestCompleted NOTIFICATION-TYPE OBJECTS { pingCtlTargetAddressType, pingCtlTargetAddress, pingResultsOperStatus, pingResultsIpTargetAddressType, pingResultsIpTargetAddress, pingResultsMinRtt, pingResultsMaxRtt, pingResultsAverageRtt, pingResultsProbeResponses, pingResultsSentProbes, pingResultsRttSumOfSquares, pingResultsLastGoodProbe Quittek & White Standards Track [Page 34] RFC 4560 REMOPS MIB June 2006 } STATUS current DESCRIPTION "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object has the testCompletion(2) bit set." ::= { pingNotifications 3 } -- Conformance information -- Compliance statements pingCompliances OBJECT IDENTIFIER ::= { pingConformance 1 } pingGroups OBJECT IDENTIFIER ::= { pingConformance 2 } -- Compliance statements pingFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that fully implement the DISMAN-PING-MIB." MODULE -- this module MANDATORY-GROUPS { pingMinimumGroup, pingCtlRowStatusGroup, pingHistoryGroup, pingNotificationsGroup } OBJECT pingMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT pingCtlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pingCtlType MIN-ACCESS read-only DESCRIPTION "Write access is not required. In addition, the only value that MUST be supported by an implementation is pingIcmpEcho." Quittek & White Standards Track [Page 35] RFC 4560 REMOPS MIB June 2006 OBJECT pingCtlSourceAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT pingCtlSourceAddress SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT pingCtlIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT pingCtlByPassRouteTable MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of its implementation. The function represented by this object is implementable if the setsockopt SOL_SOCKET SO_DONTROUTE option is supported." OBJECT pingCtlDSField MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT pingResultsIpTargetAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to Quittek & White Standards Track [Page 36] RFC 4560 REMOPS MIB June 2006 support IPv4 and IPv6 addresses." OBJECT pingResultsIpTargetAddress SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT pingResultsLastGoodProbe DESCRIPTION "This object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." OBJECT pingProbeHistoryTime DESCRIPTION "This object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." ::= { pingCompliances 2 } pingMinimumCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The minimum compliance statement for SNMP entities that implement the minimal subset of the DISMAN-PING-MIB. Implementors might choose this subset for small devices with limited resources." MODULE -- this module MANDATORY-GROUPS { pingMinimumGroup } GROUP pingCtlRowStatusGroup DESCRIPTION "A compliant implementation does not have to implement the pingCtlRowStatusGroup." GROUP pingHistoryGroup DESCRIPTION "A compliant implementation does not have to implement the pingHistoryGroup." GROUP pingNotificationsGroup DESCRIPTION "A compliant implementation does not have to implement Quittek & White Standards Track [Page 37] RFC 4560 REMOPS MIB June 2006 the pingNotificationsGroup." OBJECT pingMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT pingCtlDataFill MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT pingCtlFrequency MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT pingCtlMaxRows MIN-ACCESS read-only DESCRIPTION "Write access is not required. If the pingHistoryGroup is not implemented, then write access to this object MUST be disabled, and the object MUST return a value of 0 when retrieved." OBJECT pingCtlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pingCtlTrapGeneration MIN-ACCESS read-only DESCRIPTION "Write access is not required. If the pingNotificationsGroup is not implemented, then write access to this object MUST be disabled, and the object MUST return a value with no bit set when retrieved. No bit set indicates that not notification is generated." OBJECT pingCtlTrapProbeFailureFilter MIN-ACCESS read-only DESCRIPTION Quittek & White Standards Track [Page 38] RFC 4560 REMOPS MIB June 2006 "If write access to pingCtlTrapGeneration is not supported, then write access to this object must also not be supported. In this case, return 0 as the value of this object." OBJECT pingCtlTrapTestFailureFilter MIN-ACCESS read-only DESCRIPTION "If write access to pingCtlTrapGeneration is not supported, then write access to this object must also not be supported. In this case, return 0 as the value of this object." OBJECT pingCtlType MIN-ACCESS read-only DESCRIPTION "Write access is not required. In addition, the only value that MUST be supported by an implementation is pingIcmpEcho." OBJECT pingCtlDescr MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT pingCtlSourceAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT pingCtlSourceAddress SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT pingCtlIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is Quittek & White Standards Track [Page 39] RFC 4560 REMOPS MIB June 2006 not supported, return a 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT pingCtlByPassRouteTable MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return false(2) as the value of this object. A value of false(2) means that the function represented by this option is not supported." OBJECT pingCtlDSField MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT pingResultsIpTargetAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and IPv6 addresses." OBJECT pingResultsIpTargetAddress SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT pingResultsLastGoodProbe DESCRIPTION "This object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." OBJECT pingProbeHistoryTime DESCRIPTION "If the pingHistoryGroup is implemented, then this object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values Quittek & White Standards Track [Page 40] RFC 4560 REMOPS MIB June 2006 be reported as '0000000000000000'H." ::= { pingCompliances 3 } pingCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for the DISMAN-PING-MIB. This compliance statement has been deprecated because the group pingGroup and the pingTimeStampGroup have been split and deprecated. The pingFullCompliance statement is semantically identical to the deprecated pingCompliance statement." MODULE -- this module MANDATORY-GROUPS { pingGroup, pingNotificationsGroup } GROUP pingTimeStampGroup DESCRIPTION "This group is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this group is not supported the values for the objects in this group be reported as '0000000000000000'H." OBJECT pingMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT pingCtlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. It is also allowed that implementations support only the volatile StorageType enumeration." OBJECT pingCtlType MIN-ACCESS read-only DESCRIPTION "Write access is not required. In addition, the only value that MUST be supported by an implementation is pingIcmpEcho." Quittek & White Standards Track [Page 41] RFC 4560 REMOPS MIB June 2006 OBJECT pingCtlByPassRouteTable MIN-ACCESS read-only DESCRIPTION "This object is not required by implementations that are not capable of its implementation. The function represented by this object is implementable if the setsockopt SOL_SOCKET SO_DONTROUTE option is supported." OBJECT pingCtlSourceAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "This object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT pingCtlSourceAddress SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "This object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT pingCtlIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported, return a 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT pingCtlDSField MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported, return a 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT pingResultsIpTargetAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and IPv6 addresses." Quittek & White Standards Track [Page 42] RFC 4560 REMOPS MIB June 2006 OBJECT pingResultsIpTargetAddress SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." ::= { pingCompliances 1 } -- MIB groupings pingMinimumGroup OBJECT-GROUP OBJECTS { pingMaxConcurrentRequests, pingCtlTargetAddressType, pingCtlTargetAddress, pingCtlDataSize, pingCtlTimeOut, pingCtlProbeCount, pingCtlAdminStatus, pingCtlDataFill, pingCtlFrequency, pingCtlMaxRows, pingCtlStorageType, pingCtlTrapGeneration, pingCtlTrapProbeFailureFilter, pingCtlTrapTestFailureFilter, pingCtlType, pingCtlDescr, pingCtlByPassRouteTable, pingCtlSourceAddressType, pingCtlSourceAddress, pingCtlIfIndex, pingCtlDSField, pingResultsOperStatus, pingResultsIpTargetAddressType, pingResultsIpTargetAddress, pingResultsMinRtt, pingResultsMaxRtt, pingResultsAverageRtt, pingResultsProbeResponses, pingResultsSentProbes, pingResultsRttSumOfSquares, pingResultsLastGoodProbe } STATUS current DESCRIPTION "The group of objects that constitute the remote ping capability." Quittek & White Standards Track [Page 43] RFC 4560 REMOPS MIB June 2006 ::= { pingGroups 4 } pingCtlRowStatusGroup OBJECT-GROUP OBJECTS { pingCtlRowStatus } STATUS current DESCRIPTION "The RowStatus object of the pingCtlTable." ::= { pingGroups 5 } pingHistoryGroup OBJECT-GROUP OBJECTS { pingProbeHistoryResponse, pingProbeHistoryStatus, pingProbeHistoryLastRC, pingProbeHistoryTime } STATUS current DESCRIPTION "The group of objects that constitute the history capability." ::= { pingGroups 6 } pingNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { pingProbeFailed, pingTestFailed, pingTestCompleted } STATUS current DESCRIPTION "The notification that are required to be supported by implementations of this MIB." ::= { pingGroups 3 } pingGroup OBJECT-GROUP OBJECTS { pingMaxConcurrentRequests, pingCtlTargetAddressType, pingCtlTargetAddress, pingCtlDataSize, pingCtlTimeOut, pingCtlProbeCount, pingCtlAdminStatus, pingCtlDataFill, pingCtlFrequency, Quittek & White Standards Track [Page 44] RFC 4560 REMOPS MIB June 2006 pingCtlMaxRows, pingCtlStorageType, pingCtlTrapGeneration, pingCtlTrapProbeFailureFilter, pingCtlTrapTestFailureFilter, pingCtlType, pingCtlDescr, pingCtlByPassRouteTable, pingCtlSourceAddressType, pingCtlSourceAddress, pingCtlIfIndex, pingCtlDSField, pingCtlRowStatus, pingResultsOperStatus, pingResultsIpTargetAddressType, pingResultsIpTargetAddress, pingResultsMinRtt, pingResultsMaxRtt, pingResultsAverageRtt, pingResultsProbeResponses, pingResultsSentProbes, pingResultsRttSumOfSquares, pingProbeHistoryResponse, pingProbeHistoryStatus, pingProbeHistoryLastRC } STATUS deprecated DESCRIPTION "The group of objects that constitute the remote ping capability." ::= { pingGroups 1 } pingTimeStampGroup OBJECT-GROUP OBJECTS { pingResultsLastGoodProbe, pingProbeHistoryTime } STATUS deprecated DESCRIPTION "The group of DateAndTime objects." ::= { pingGroups 2 } END Quittek & White Standards Track [Page 45] RFC 4560 REMOPS MIB June 2006 4.2. DISMAN-TRACEROUTE-MIB DISMAN-TRACEROUTE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32, Unsigned32, mib-2, NOTIFICATION-TYPE, OBJECT-IDENTITY FROM SNMPv2-SMI -- RFC2578 RowStatus, StorageType, TruthValue, DateAndTime FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC3411 InterfaceIndexOrZero -- RFC2863 FROM IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC4001 OperationResponseStatus FROM DISMAN-PING-MIB; -- RFC4560 traceRouteMIB MODULE-IDENTITY LAST-UPDATED "200606130000Z" -- 13 June 2006 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-115 Email: quittek@netlab.nec.de" DESCRIPTION "The Traceroute MIB (DISMAN-TRACEROUTE-MIB) provides access to the traceroute capability at a remote host. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4560; see the RFC itself for full legal notices." -- Revision history Quittek & White Standards Track [Page 46] RFC 4560 REMOPS MIB June 2006 REVISION "200606130000Z" -- 13 June 2006 DESCRIPTION "Updated version, published as RFC 4560. - Correctly considered IPv6 in DESCRIPTION clause of object traceRouteCtlDataSize - Replaced references to RFC 2575 by RFC 3415 - Replaced references to RFC 2571 by RFC 3411 - Replaced references to RFC 2851 by RFC 4001 - Clarified DESCRIPTION clause of object traceRouteResultsLastGoodPath - Changed range of object traceRouteCtlInitialTtl from (0..255) to (1..255) - Extended DESCRIPTION clause of traceRouteResultsTable describing re-initialization of entries - Changed SYNTAX of traceRouteResultsTestAttempts and traceRouteResultsTestSuccesses from Unsigned32 to Gauge32 - Changed status of traceRouteCompliance to deprecated - Added traceRouteFullCompliance and traceRouteMinimumCompliance - Changed status of traceRouteGroup and traceRouteTimeStampGroup to deprecated - Added traceRouteMinimumGroup, traceRouteCtlRowStatusGroup, and traceRouteHistoryGroup - Changed DEFVAL of object traceRouteCtlTargetAddressType from { ipv4 } to { unknown } - Changed DEFVAL of object traceRouteCtlDescr from { '00'H } to { ''H } - Added DEFVAL for object traceRouteCtlTrapGeneration of DEFVAL { { } }" REVISION "200009210000Z" -- 21 September 2000 DESCRIPTION "Initial version, published as RFC 2925." ::= { mib-2 81 } -- Top level structure of the MIB traceRouteNotifications OBJECT IDENTIFIER ::= { traceRouteMIB 0 } traceRouteObjects OBJECT IDENTIFIER ::= { traceRouteMIB 1 } traceRouteConformance OBJECT IDENTIFIER ::= { traceRouteMIB 2 } -- The registration node (point) for traceroute implementation types traceRouteImplementationTypeDomains OBJECT IDENTIFIER ::= { traceRouteMIB 3 } Quittek & White Standards Track [Page 47] RFC 4560 REMOPS MIB June 2006 traceRouteUsingUdpProbes OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates that an implementation is using UDP probes to perform the traceroute operation." ::= { traceRouteImplementationTypeDomains 1 } -- Simple Object Definitions traceRouteMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active traceroute requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect. The limit applies only to new requests being activated. When a new value is set, the agent will continue processing all the requests already active, even if their number exceeds the limit just imposed." DEFVAL { 10 } ::= { traceRouteObjects 1 } -- Traceroute Control Table traceRouteCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF TraceRouteCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Remote Operations Traceroute Control Table for providing the capability of invoking traceroute from a remote host. The results of traceroute operations can be stored in the traceRouteResultsTable, traceRouteProbeHistoryTable, and the traceRouteHopsTable." ::= { traceRouteObjects 2 } traceRouteCtlEntry OBJECT-TYPE SYNTAX TraceRouteCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Quittek & White Standards Track [Page 48] RFC 4560 REMOPS MIB June 2006 "Defines an entry in the traceRouteCtlTable. The first index element, traceRouteCtlOwnerIndex, is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415, VACM) and that allows a management application to identify its entries. The second index, traceRouteCtlTestName (also an SnmpAdminString), enables the same management application to have multiple requests outstanding." INDEX { traceRouteCtlOwnerIndex, traceRouteCtlTestName } ::= { traceRouteCtlTable 1 } TraceRouteCtlEntry ::= SEQUENCE { traceRouteCtlOwnerIndex SnmpAdminString, traceRouteCtlTestName SnmpAdminString, traceRouteCtlTargetAddressType InetAddressType, traceRouteCtlTargetAddress InetAddress, traceRouteCtlByPassRouteTable TruthValue, traceRouteCtlDataSize Unsigned32, traceRouteCtlTimeOut Unsigned32, traceRouteCtlProbesPerHop Unsigned32, traceRouteCtlPort Unsigned32, traceRouteCtlMaxTtl Unsigned32, traceRouteCtlDSField Unsigned32, traceRouteCtlSourceAddressType InetAddressType, traceRouteCtlSourceAddress InetAddress, traceRouteCtlIfIndex InterfaceIndexOrZero, traceRouteCtlMiscOptions SnmpAdminString, traceRouteCtlMaxFailures Unsigned32, traceRouteCtlDontFragment TruthValue, traceRouteCtlInitialTtl Unsigned32, traceRouteCtlFrequency Unsigned32, traceRouteCtlStorageType StorageType, traceRouteCtlAdminStatus INTEGER, traceRouteCtlDescr SnmpAdminString, traceRouteCtlMaxRows Unsigned32, traceRouteCtlTrapGeneration BITS, traceRouteCtlCreateHopsEntries TruthValue, traceRouteCtlType OBJECT IDENTIFIER, traceRouteCtlRowStatus RowStatus } traceRouteCtlOwnerIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) Quittek & White Standards Track [Page 49] RFC 4560 REMOPS MIB June 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (RFC 3415, VACM) for tables in which multiple users may need to create or modify entries independently, the initial index is used as an 'owner index'. Such an initial index has a syntax of SnmpAdminString and can thus be trivially mapped to a securityName or groupName defined in VACM, in accordance with a security policy. When used in conjunction with such a security policy, all entries in the table belonging to a particular user (or group) will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the 'column' subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask 'wildcarding' the column subidentifier. More elaborate configurations are possible." ::= { traceRouteCtlEntry 1 } traceRouteCtlTestName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a traceroute test. This is locally unique, within the scope of a traceRouteCtlOwnerIndex." ::= { traceRouteCtlEntry 2 } traceRouteCtlTargetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the type of host address to be used on the traceroute request at the remote host." DEFVAL { unknown } ::= { traceRouteCtlEntry 3 } Quittek & White Standards Track [Page 50] RFC 4560 REMOPS MIB June 2006 traceRouteCtlTargetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the host address used on the traceroute request at the remote host. The host address type can be determined by examining the value of the corresponding traceRouteCtlTargetAddressType. A value for this object MUST be set prior to transitioning its corresponding traceRouteCtlEntry to active(1) via traceRouteCtlRowStatus." ::= { traceRouteCtlEntry 4 } traceRouteCtlByPassRouteTable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The purpose of this object is to enable optional bypassing the route table. If enabled, the remote host will bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly attached network, an error is returned. This option can be used to perform the traceroute operation to a local host through an interface that has no route defined (e.g., after the interface was dropped by the routing daemon at the host)." DEFVAL { false } ::= { traceRouteCtlEntry 5 } traceRouteCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion of a traceroute request, in octets. If the RECOMMENDED traceroute method (UDP datagrams as probes) is used, then the value contained in this object MUST be applied. If another traceroute method is used for which the specified size is not appropriate, then the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. Quittek & White Standards Track [Page 51] RFC 4560 REMOPS MIB June 2006 The maximum value for this object was computed by subtracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." DEFVAL { 0 } ::= { traceRouteCtlEntry 6 } traceRouteCtlTimeOut OBJECT-TYPE SYNTAX Unsigned32 (1..60) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the time-out value, in seconds, for a traceroute request." DEFVAL { 3 } ::= { traceRouteCtlEntry 7 } traceRouteCtlProbesPerHop OBJECT-TYPE SYNTAX Unsigned32 (1..10) UNITS "probes" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the number of times to reissue a traceroute request with the same time-to-live (TTL) value." DEFVAL { 3 } ::= { traceRouteCtlEntry 8 } traceRouteCtlPort OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "UDP Port" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the (initial) UDP port to send the traceroute request to. A port needs to be specified that is not in use at the destination (target) host. The default value for this object is the IANA assigned port, 33434, for the traceroute function." DEFVAL { 33434 } ::= { traceRouteCtlEntry 9 } traceRouteCtlMaxTtl OBJECT-TYPE SYNTAX Unsigned32 (1..255) UNITS "time-to-live value" Quittek & White Standards Track [Page 52] RFC 4560 REMOPS MIB June 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum time-to-live value." DEFVAL { 30 } ::= { traceRouteCtlEntry 10 } traceRouteCtlDSField OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the value to store in the Type of Service (TOS) octet in the IPv4 header or in the Traffic Class octet in the IPv6 header, respectively, of the IP packet used to encapsulate the traceroute probe. The octet to be set in the IP header contains the Differentiated Services (DS) Field in the six most significant bits. This option can be used to determine what effect an explicit DS Field setting has on a traceroute response. Not all values are legal or meaningful. A value of 0 means that the function represented by this option is not supported. DS Field usage is often not supported by IP implementations, and not all values are supported. Refer to RFC 2474 and RFC 3260 for guidance on usage of this field." REFERENCE "Refer to RFC 1812 for the definition of the IPv4 TOS octet and to RFC 2460 for the definition of the IPv6 Traffic Class octet. Refer to RFC 2474 and RFC 3260 for the definition of the Differentiated Services Field." DEFVAL { 0 } ::= { traceRouteCtlEntry 11 } traceRouteCtlSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the type of the source address, traceRouteCtlSourceAddress, to be used at a remote host when a traceroute operation is performed." DEFVAL { unknown } ::= { traceRouteCtlEntry 12 } Quittek & White Standards Track [Page 53] RFC 4560 REMOPS MIB June 2006 traceRouteCtlSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Use the specified IP address (which must be given as an IP number, not a hostname) as the source address in outgoing probe packets. On hosts with more than one IP address, this option can be used to select the address to be used. If the IP address is not one of this machine's interface addresses, an error is returned, and nothing is sent. A zero-length octet string value for this object disables source address specification. The address type (InetAddressType) that relates to this object is specified by the corresponding value of traceRouteCtlSourceAddressType." DEFVAL { ''H } ::= { traceRouteCtlEntry 13 } traceRouteCtlIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Setting this object to an interface's ifIndex prior to starting a remote traceroute operation directs the traceroute probes to be transmitted over the specified interface. A value of zero for this object implies that this option is not enabled." DEFVAL { 0 } ::= { traceRouteCtlEntry 14 } traceRouteCtlMiscOptions OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Enables an application to specify implementation-dependent options." DEFVAL { ''H } ::= { traceRouteCtlEntry 15 } traceRouteCtlMaxFailures OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "timeouts" MAX-ACCESS read-create STATUS current DESCRIPTION Quittek & White Standards Track [Page 54] RFC 4560 REMOPS MIB June 2006 "The value of this object indicates the maximum number of consecutive timeouts allowed before a remote traceroute request is terminated. A value of either 255 (maximum hop count/possible TTL value) or 0 indicates that the function of terminating a remote traceroute request when a specific number of consecutive timeouts are detected is disabled." DEFVAL { 5 } ::= { traceRouteCtlEntry 16 } traceRouteCtlDontFragment OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables setting of the don't fragment flag (DF) in the IP header for a probe. Use of this object enables a manual PATH MTU test is performed." DEFVAL { false } ::= { traceRouteCtlEntry 17 } traceRouteCtlInitialTtl OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object specifies the initial TTL value to use. This enables bypassing the initial (often well known) portion of a path." DEFVAL { 1 } ::= { traceRouteCtlEntry 18 } traceRouteCtlFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait before repeating a traceroute test, as defined by the value of the various objects in the corresponding row. After a single test is completed the number of seconds as defined by the value of traceRouteCtlFrequency MUST elapse before the next traceroute test is started. A value of 0 for this object implies that the test as defined by the corresponding entry will not be Quittek & White Standards Track [Page 55] RFC 4560 REMOPS MIB June 2006 repeated." DEFVAL { 0 } ::= { traceRouteCtlEntry 19 } traceRouteCtlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { traceRouteCtlEntry 20 } traceRouteCtlAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- operation should be started disabled(2) -- operation should be stopped } MAX-ACCESS read-create STATUS current DESCRIPTION "Reflects the desired state that an traceRouteCtlEntry should be in: enabled(1) - Attempt to activate the test as defined by this traceRouteCtlEntry. disabled(2) - Deactivate the test as defined by this traceRouteCtlEntry. Refer to the corresponding traceRouteResultsOperStatus to determine the operational state of the test defined by this entry." DEFVAL { disabled } ::= { traceRouteCtlEntry 21 } traceRouteCtlDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The purpose of this object is to provide a descriptive name of the remote traceroute test." DEFVAL { ''H } ::= { traceRouteCtlEntry 22 } Quittek & White Standards Track [Page 56] RFC 4560 REMOPS MIB June 2006 traceRouteCtlMaxRows OBJECT-TYPE SYNTAX Unsigned32 UNITS "rows" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of corresponding entries allowed in the traceRouteProbeHistoryTable. An implementation of this MIB will remove the oldest corresponding entry in the traceRouteProbeHistoryTable to allow the addition of an new entry once the number of corresponding rows in the traceRouteProbeHistoryTable reaches this value. Old entries are not removed when a new test is started. Entries are added to the traceRouteProbeHistoryTable until traceRouteCtlMaxRows is reached before entries begin to be removed. A value of 0 for this object disables creation of traceRouteProbeHistoryTable entries." DEFVAL { 50 } ::= { traceRouteCtlEntry 23 } traceRouteCtlTrapGeneration OBJECT-TYPE SYNTAX BITS { pathChange(0), testFailure(1), testCompletion(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object determines when and whether to generate a notification for this entry: pathChange(0) - Generate a traceRoutePathChange notification when the current path varies from a previously determined path. testFailure(1) - Generate a traceRouteTestFailed notification when the full path to a target can't be determined. testCompletion(2) - Generate a traceRouteTestCompleted notification when the path to a target has been determined. The value of this object defaults to an empty set, indicating that none of the above options has been selected." Quittek & White Standards Track [Page 57] RFC 4560 REMOPS MIB June 2006 DEFVAL { { } } ::= { traceRouteCtlEntry 24 } traceRouteCtlCreateHopsEntries OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The current path for a traceroute test is kept in the traceRouteHopsTable on a per-hop basis when the value of this object is true(1)." DEFVAL { false } ::= { traceRouteCtlEntry 25 } traceRouteCtlType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object is used either to report or to select the implementation method to be used for performing a traceroute operation. The value of this object may be selected from traceRouteImplementationTypeDomains. Additional implementation types should be allocated as required by implementers of the DISMAN-TRACEROUTE-MIB under their enterprise specific registration point, not beneath traceRouteImplementationTypeDomains." DEFVAL { traceRouteUsingUdpProbes } ::= { traceRouteCtlEntry 26 } traceRouteCtlRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the traceRouteCtlTable. Deletion of an entry in this table results in a deletion of all corresponding (same traceRouteCtlOwnerIndex and traceRouteCtlTestName index values) traceRouteResultsTable, traceRouteProbeHistoryTable, and traceRouteHopsTable entries. A value MUST be specified for traceRouteCtlTargetAddress prior to acceptance of a transition to active(1) state. Quittek & White Standards Track [Page 58] RFC 4560 REMOPS MIB June 2006 When a value for pingCtlTargetAddress is set, the value of object pingCtlRowStatus changes from notReady(3) to notInService(2). Activation of a remote traceroute operation is controlled via traceRouteCtlAdminStatus, and not by transitioning of this object's value to active(1). Transitions in and out of active(1) state are not allowed while an entry's traceRouteResultsOperStatus is active(1), with the exception that deletion of an entry in this table by setting its RowStatus object to destroy(6) will stop an active traceroute operation. The operational state of an traceroute operation can be determined by examination of the corresponding traceRouteResultsOperStatus object." REFERENCE "See definition of RowStatus in RFC 2579, 'Textual Conventions for SMIv2.'" ::= { traceRouteCtlEntry 27 } -- Traceroute Results Table traceRouteResultsTable OBJECT-TYPE SYNTAX SEQUENCE OF TraceRouteResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Remote Operations Traceroute Results Table for keeping track of the status of a traceRouteCtlEntry. An entry is added to the traceRouteResultsTable when an traceRouteCtlEntry is started by successful transition of its traceRouteCtlAdminStatus object to enabled(1). If the object traceRouteCtlAdminStatus already has the value enabled(1), and if the corresponding traceRouteResultsOperStatus object has the value completed(3), then successfully writing enabled(1) to the object traceRouteCtlAdminStatus re-initializes the already existing entry in the traceRouteResultsTable. The values of objects in the re-initialized entry are the same as the values of objects in a new entry would be. An entry is removed from the traceRouteResultsTable when Quittek & White Standards Track [Page 59] RFC 4560 REMOPS MIB June 2006 its corresponding traceRouteCtlEntry is deleted." ::= { traceRouteObjects 3 } traceRouteResultsEntry OBJECT-TYPE SYNTAX TraceRouteResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the traceRouteResultsTable. The traceRouteResultsTable has the same indexing as the traceRouteCtlTable so that a traceRouteResultsEntry corresponds to the traceRouteCtlEntry that caused it to be created." INDEX { traceRouteCtlOwnerIndex, traceRouteCtlTestName } ::= { traceRouteResultsTable 1 } TraceRouteResultsEntry ::= SEQUENCE { traceRouteResultsOperStatus INTEGER, traceRouteResultsCurHopCount Gauge32, traceRouteResultsCurProbeCount Gauge32, traceRouteResultsIpTgtAddrType InetAddressType, traceRouteResultsIpTgtAddr InetAddress, traceRouteResultsTestAttempts Gauge32, traceRouteResultsTestSuccesses Gauge32, traceRouteResultsLastGoodPath DateAndTime } traceRouteResultsOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- test is in progress disabled(2), -- test has stopped completed(3) -- test is completed } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of an traceRouteCtlEntry: enabled(1) - Test is active. disabled(2) - Test has stopped. completed(3) - Test is completed." ::= { traceRouteResultsEntry 1 } traceRouteResultsCurHopCount OBJECT-TYPE Quittek & White Standards Track [Page 60] RFC 4560 REMOPS MIB June 2006 SYNTAX Gauge32 UNITS "hops" MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the current TTL value (from 1 to 255) for a remote traceroute operation. Maximum TTL value is determined by traceRouteCtlMaxTtl." ::= { traceRouteResultsEntry 2 } traceRouteResultsCurProbeCount OBJECT-TYPE SYNTAX Gauge32 UNITS "probes" MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the current probe count (1..10) for a remote traceroute operation. The maximum probe count is determined by traceRouteCtlProbesPerHop." ::= { traceRouteResultsEntry 3 } traceRouteResultsIpTgtAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of address stored in the corresponding traceRouteResultsIpTgtAddr object." ::= { traceRouteResultsEntry 4 } traceRouteResultsIpTgtAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object reports the IP address associated with a traceRouteCtlTargetAddress value when the destination address is specified as a DNS name. The value of this object should be a zero-length octet string when a DNS name is not specified or when a specified DNS name fails to resolve." ::= { traceRouteResultsEntry 5 } traceRouteResultsTestAttempts OBJECT-TYPE Quittek & White Standards Track [Page 61] RFC 4560 REMOPS MIB June 2006 SYNTAX Gauge32 UNITS "tests" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of attempts to determine a path to a target. The value of this object MUST be started at 0." ::= { traceRouteResultsEntry 6 } traceRouteResultsTestSuccesses OBJECT-TYPE SYNTAX Gauge32 UNITS "tests" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of attempts to determine a path to a target that have succeeded. The value of this object MUST be reported as 0 when no attempts have succeeded." ::= { traceRouteResultsEntry 7 } traceRouteResultsLastGoodPath OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the last complete path was determined. A path is complete if responses were received or timeout occurred for each hop on the path; i.e., for each TTL value from the value of the corresponding traceRouteCtlInitialTtl object up to the end of the path or (if no reply from the target IP address was received) up to the value of the corresponding traceRouteCtlMaxTtl object." ::= { traceRouteResultsEntry 8 } -- Trace Route Probe History Table traceRouteProbeHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF TraceRouteProbeHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Remote Operations Traceroute Results Table for storing the results of a traceroute operation. An implementation of this MIB will remove the oldest Quittek & White Standards Track [Page 62] RFC 4560 REMOPS MIB June 2006 entry in the traceRouteProbeHistoryTable of the corresponding entry in the traceRouteCtlTable to allow the addition of a new entry once the number of rows in the traceRouteProbeHistoryTable reaches the value specified by traceRouteCtlMaxRows for the corresponding entry in the traceRouteCtlTable." ::= { traceRouteObjects 4 } traceRouteProbeHistoryEntry OBJECT-TYPE SYNTAX TraceRouteProbeHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a table for storing the results of a traceroute operation. Entries in this table are limited by the value of the corresponding traceRouteCtlMaxRows object. The first two index elements identify the traceRouteCtlEntry that a traceRouteProbeHistoryEntry belongs to. The third index element selects a single traceroute operation result. The fourth and fifth indexes select the hop and the probe for a particular traceroute operation." INDEX { traceRouteCtlOwnerIndex, traceRouteCtlTestName, traceRouteProbeHistoryIndex, traceRouteProbeHistoryHopIndex, traceRouteProbeHistoryProbeIndex } ::= { traceRouteProbeHistoryTable 1 } TraceRouteProbeHistoryEntry ::= SEQUENCE { traceRouteProbeHistoryIndex Unsigned32, traceRouteProbeHistoryHopIndex Unsigned32, traceRouteProbeHistoryProbeIndex Unsigned32, traceRouteProbeHistoryHAddrType InetAddressType, traceRouteProbeHistoryHAddr InetAddress, traceRouteProbeHistoryResponse Unsigned32, traceRouteProbeHistoryStatus OperationResponseStatus, traceRouteProbeHistoryLastRC Integer32, traceRouteProbeHistoryTime DateAndTime } traceRouteProbeHistoryIndex OBJECT-TYPE Quittek & White Standards Track [Page 63] RFC 4560 REMOPS MIB June 2006 SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created when the result of a traceroute probe is determined. The initial 2 instance identifier index values identify the traceRouteCtlEntry that a probe result (traceRouteProbeHistoryEntry) belongs to. An entry is removed from this table when its corresponding traceRouteCtlEntry is deleted. An implementation MUST start assigning traceRouteProbeHistoryIndex values at 1 and wrap after exceeding the maximum possible value, as defined by the limit of this object ('ffffffff'h)." ::= { traceRouteProbeHistoryEntry 1 } traceRouteProbeHistoryHopIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates which hop in a traceroute path the probe's results are for. The value of this object is initially determined by the value of traceRouteCtlInitialTtl." ::= { traceRouteProbeHistoryEntry 2 } traceRouteProbeHistoryProbeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..10) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the index of a probe for a particular hop in a traceroute path. The number of probes per hop is determined by the value of the corresponding traceRouteCtlProbesPerHop object." ::= { traceRouteProbeHistoryEntry 3 } traceRouteProbeHistoryHAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This objects indicates the type of address stored in the corresponding traceRouteProbeHistoryHAddr object." ::= { traceRouteProbeHistoryEntry 4 } Quittek & White Standards Track [Page 64] RFC 4560 REMOPS MIB June 2006 traceRouteProbeHistoryHAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of a hop in a traceroute path. This object is not allowed to be a DNS name. The value of the corresponding object, traceRouteProbeHistoryHAddrType, indicates this object's IP address type." ::= { traceRouteProbeHistoryEntry 5 } traceRouteProbeHistoryResponse OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time measured in milliseconds from when a probe was sent to when its response was received or when it timed out. The value of this object is reported as 0 when it is not possible to transmit a probe." ::= { traceRouteProbeHistoryEntry 6 } traceRouteProbeHistoryStatus OBJECT-TYPE SYNTAX OperationResponseStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The result of a traceroute operation made by a remote host for a particular probe." ::= { traceRouteProbeHistoryEntry 7 } traceRouteProbeHistoryLastRC OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The last implementation-method-specific reply code received. Traceroute is usually implemented by transmitting a series of probe packets with increasing time-to-live values. A probe packet is a UDP datagram encapsulated into an IP packet. Each hop in a path to the target (destination) host rejects the probe packets (probe's TTL too small, ICMP reply) until either the maximum TTL is exceeded or the target host is received." ::= { traceRouteProbeHistoryEntry 8 } Quittek & White Standards Track [Page 65] RFC 4560 REMOPS MIB June 2006 traceRouteProbeHistoryTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Timestamp for when this probe's results were determined." ::= { traceRouteProbeHistoryEntry 9 } -- Traceroute Hop Results Table traceRouteHopsTable OBJECT-TYPE SYNTAX SEQUENCE OF TraceRouteHopsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Remote Operations Traceroute Hop Table for keeping track of the results of traceroute tests on a per-hop basis." ::= { traceRouteObjects 5 } traceRouteHopsEntry OBJECT-TYPE SYNTAX TraceRouteHopsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the traceRouteHopsTable. The first two index elements identify the traceRouteCtlEntry that a traceRouteHopsEntry belongs to. The third index element, traceRouteHopsHopIndex, selects a hop in a traceroute path." INDEX { traceRouteCtlOwnerIndex, traceRouteCtlTestName, traceRouteHopsHopIndex } ::= { traceRouteHopsTable 1 } TraceRouteHopsEntry ::= SEQUENCE { traceRouteHopsHopIndex Unsigned32, traceRouteHopsIpTgtAddressType InetAddressType, traceRouteHopsIpTgtAddress InetAddress, traceRouteHopsMinRtt Unsigned32, traceRouteHopsMaxRtt Unsigned32, traceRouteHopsAverageRtt Unsigned32, traceRouteHopsRttSumOfSquares Unsigned32, Quittek & White Standards Track [Page 66] RFC 4560 REMOPS MIB June 2006 traceRouteHopsSentProbes Unsigned32, traceRouteHopsProbeResponses Unsigned32, traceRouteHopsLastGoodProbe DateAndTime } traceRouteHopsHopIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specifies the hop index for a traceroute hop. Values for this object with respect to the same traceRouteCtlOwnerIndex and traceRouteCtlTestName MUST start at 1 and be given increasing values for subsequent hops. The value of traceRouteHopsHopIndex is not necessarily the number of the hop on the traced path. The traceRouteHopsTable keeps the current traceroute path per traceRouteCtlEntry if enabled by setting the corresponding traceRouteCtlCreateHopsEntries to true(1). All hops (traceRouteHopsTable entries) in a traceroute path MUST be updated at the same time when a traceroute operation is completed. Care needs to be applied when a path either changes or can't be determined. The initial portion of the path, up to the first hop change, MUST retain the same traceRouteHopsHopIndex values. The remaining portion of the path SHOULD be assigned new traceRouteHopsHopIndex values." ::= { traceRouteHopsEntry 1 } traceRouteHopsIpTgtAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of address stored in the corresponding traceRouteHopsIpTgtAddress object." ::= { traceRouteHopsEntry 2 } traceRouteHopsIpTgtAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object reports the IP address associated with Quittek & White Standards Track [Page 67] RFC 4560 REMOPS MIB June 2006 the hop. A value for this object should be reported as a numeric IP address, not as a DNS name. The address type (InetAddressType) that relates to this object is specified by the corresponding value of pingCtlSourceAddressType." ::= { traceRouteHopsEntry 3 } traceRouteHopsMinRtt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum traceroute round-trip-time (RTT) received for this hop. A value of 0 for this object implies that no RTT has been received." ::= { traceRouteHopsEntry 4 } traceRouteHopsMaxRtt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum traceroute round-trip-time (RTT) received for this hop. A value of 0 for this object implies that no RTT has been received." ::= { traceRouteHopsEntry 5 } traceRouteHopsAverageRtt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current average traceroute round-trip-time (RTT) for this hop." ::= { traceRouteHopsEntry 6 } traceRouteHopsRttSumOfSquares OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the sum of the squares of all round-trip-times received for this hop. Its purpose is to enable standard deviation calculation." ::= { traceRouteHopsEntry 7 } traceRouteHopsSentProbes OBJECT-TYPE Quittek & White Standards Track [Page 68] RFC 4560 REMOPS MIB June 2006 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reflects the number of probes sent for this hop during this traceroute test. The value of this object should start at 0." ::= { traceRouteHopsEntry 8 } traceRouteHopsProbeResponses OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses received for this hop during this traceroute test. This value of this object should start at 0." ::= { traceRouteHopsEntry 9 } traceRouteHopsLastGoodProbe OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Date and time at which the last response was received for a probe for this hop during this traceroute test." ::= { traceRouteHopsEntry 10 } -- Notification Definition section traceRoutePathChange NOTIFICATION-TYPE OBJECTS { traceRouteCtlTargetAddressType, traceRouteCtlTargetAddress, traceRouteResultsIpTgtAddrType, traceRouteResultsIpTgtAddr } STATUS current DESCRIPTION "The path to a target has changed." ::= { traceRouteNotifications 1 } traceRouteTestFailed NOTIFICATION-TYPE OBJECTS { traceRouteCtlTargetAddressType, traceRouteCtlTargetAddress, traceRouteResultsIpTgtAddrType, traceRouteResultsIpTgtAddr Quittek & White Standards Track [Page 69] RFC 4560 REMOPS MIB June 2006 } STATUS current DESCRIPTION "Could not determine the path to a target." ::= { traceRouteNotifications 2 } traceRouteTestCompleted NOTIFICATION-TYPE OBJECTS { traceRouteCtlTargetAddressType, traceRouteCtlTargetAddress, traceRouteResultsIpTgtAddrType, traceRouteResultsIpTgtAddr } STATUS current DESCRIPTION "The path to a target has just been determined." ::= { traceRouteNotifications 3 } -- Conformance information -- Compliance statements traceRouteCompliances OBJECT IDENTIFIER ::= { traceRouteConformance 1 } traceRouteGroups OBJECT IDENTIFIER ::= { traceRouteConformance 2 } -- Compliance statements traceRouteFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that fully implement the DISMAN-TRACEROUTE-MIB." MODULE -- this module MANDATORY-GROUPS { traceRouteMinimumGroup, traceRouteCtlRowStatusGroup, traceRouteHistoryGroup } GROUP traceRouteHopsTableGroup DESCRIPTION "This group lists the objects that make up a traceRouteHopsEntry. Support of the traceRouteHopsTable is optional." GROUP traceRouteNotificationsGroup DESCRIPTION Quittek & White Standards Track [Page 70] RFC 4560 REMOPS MIB June 2006 "This group defines a collection of optional notifications." OBJECT traceRouteMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support SET operations to this object." OBJECT traceRouteCtlByPassRouteTable MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of its implementation. The function represented by this object is implementable if the setsockopt SOL_SOCKET SO_DONTROUTE option is supported." OBJECT traceRouteCtlDSField MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 implies that the function represented by this option is not supported." OBJECT traceRouteCtlSourceAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT traceRouteCtlSourceAddress SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT traceRouteCtlIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is Quittek & White Standards Track [Page 71] RFC 4560 REMOPS MIB June 2006 not supported, return a 0 as the value of this object. A value of 0 implies that the function represented by this option is not supported." OBJECT traceRouteCtlMiscOptions MIN-ACCESS read-only DESCRIPTION "Support of this object is optional. If not supporting, do not allow write access and return a zero-length octet string as the value of the object." OBJECT traceRouteCtlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. It is also allowed that implementations support only the volatile(2) StorageType enumeration." OBJECT traceRouteCtlType MIN-ACCESS read-only DESCRIPTION "Write access is not required. In addition, the only value that is RECOMMENDED to be supported by an implementation is traceRouteUsingUdpProbes." OBJECT traceRouteResultsIpTgtAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteResultsIpTgtAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteResultsLastGoodPath DESCRIPTION "If the traceRouteHopsTableGroup is implemented, then this object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." OBJECT traceRouteProbeHistoryHAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } Quittek & White Standards Track [Page 72] RFC 4560 REMOPS MIB June 2006 DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteProbeHistoryHAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteProbeHistoryTime DESCRIPTION "This object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." OBJECT traceRouteHopsIpTgtAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteHopsIpTgtAddress SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteHopsLastGoodProbe DESCRIPTION "This object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." ::= { traceRouteCompliances 2 } traceRouteMinimumCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The minimum compliance statement for SNMP entities which implement the minimal subset of the DISMAN-TRACEROUTE-MIB. Implementors might choose this subset for small devices with limited resources." MODULE -- this module Quittek & White Standards Track [Page 73] RFC 4560 REMOPS MIB June 2006 MANDATORY-GROUPS { traceRouteMinimumGroup } GROUP traceRouteCtlRowStatusGroup DESCRIPTION "A compliant implementation does not have to implement the traceRouteCtlRowStatusGroup." GROUP traceRouteHistoryGroup DESCRIPTION "A compliant implementation does not have to implement the traceRouteHistoryGroup." GROUP traceRouteHopsTableGroup DESCRIPTION "This group lists the objects that make up a traceRouteHopsEntry. Support of the traceRouteHopsTable is optional." GROUP traceRouteNotificationsGroup DESCRIPTION "This group defines a collection of optional notifications." OBJECT traceRouteMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support SET operations to this object." OBJECT traceRouteCtlByPassRouteTable MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a false(2) as the value of this object. A value of false(2) means that the function represented by this option is not supported." OBJECT traceRouteCtlDSField MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 implies that the function represented by this option is not supported." OBJECT traceRouteCtlSourceAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only Quittek & White Standards Track [Page 74] RFC 4560 REMOPS MIB June 2006 DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT traceRouteCtlSourceAddress SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access to this object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT traceRouteCtlIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 implies that the function represented by this option is not supported." OBJECT traceRouteCtlMiscOptions MIN-ACCESS read-only DESCRIPTION "Support of this object is optional. If not supporting, do not allow write access, and return a zero-length octet string as the value of the object." OBJECT traceRouteCtlDontFragment MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a false(2) as the value of this object. A value of false(2) means that the function represented by this option is not supported." OBJECT traceRouteCtlInitialTtl MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, return a 1 as the value of this object." OBJECT traceRouteCtlFrequency MIN-ACCESS read-only DESCRIPTION Quittek & White Standards Track [Page 75] RFC 4560 REMOPS MIB June 2006 "Write access is not required. If write access is not supported, return a 0 as the value of this object. A value of 0 implies that the function represented by this option is not supported." OBJECT traceRouteCtlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. It is also allowed that implementations support only the volatile(2) StorageType enumeration." OBJECT traceRouteCtlDescr MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT traceRouteCtlMaxRows MIN-ACCESS read-only DESCRIPTION "Write access is not required. If the traceRouteHistoryGroup is not implemented, then write access to this object MUST be disabled, and the object MUST return a value of 0 when retrieved." OBJECT traceRouteCtlTrapGeneration MIN-ACCESS read-only DESCRIPTION "Write access is not required. If the traceRouteNotificationsGroup is not implemented, then write access to this object MUST be disabled, and the object MUST return a value with no bit set when retrieved. No bit set indicates that no notification is generated." OBJECT traceRouteCtlCreateHopsEntries MIN-ACCESS read-only DESCRIPTION "Write access is not required. If the traceRouteHopsTableGroup is not implemented, then write access to this object MUST be disabled, and the object MUST return a value of false(2) when retrieved." OBJECT traceRouteCtlType MIN-ACCESS read-only DESCRIPTION "Write access is not required. In addition, the only Quittek & White Standards Track [Page 76] RFC 4560 REMOPS MIB June 2006 value that is RECOMMENDED to be supported by an implementation is traceRouteUsingUdpProbes." OBJECT traceRouteResultsIpTgtAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteResultsIpTgtAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteResultsLastGoodPath DESCRIPTION "This object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." OBJECT traceRouteProbeHistoryHAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteProbeHistoryHAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteProbeHistoryTime DESCRIPTION "If the traceRouteHistoryGroup is implemented, then this object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." OBJECT traceRouteHopsIpTgtAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation should only support IPv4 and Quittek & White Standards Track [Page 77] RFC 4560 REMOPS MIB June 2006 globally unique IPv6 address values for this object." OBJECT traceRouteHopsIpTgtAddress SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteHopsLastGoodProbe DESCRIPTION "If the traceRouteHopsTableGroup is implemented, then this object is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects. It is RECOMMENDED that when this object is not supported its values be reported as '0000000000000000'H." ::= { traceRouteCompliances 3 } traceRouteCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for the DISMAN-TRACEROUTE-MIB. This compliance statement has been deprecated because the traceRouteGroup and the traceRouteTimeStampGroup have been split and deprecated. The traceRouteFullCompliance is semantically identical to the deprecated traceRouteCompliance statement." MODULE -- this module MANDATORY-GROUPS { traceRouteGroup } GROUP traceRouteTimeStampGroup DESCRIPTION "This group is mandatory for implementations that have access to a system clock and that are capable of setting the values for DateAndTime objects." GROUP traceRouteNotificationsGroup DESCRIPTION "This group defines a collection of optional notifications." GROUP traceRouteHopsTableGroup DESCRIPTION "This group lists the objects that make up a traceRouteHopsEntry. Support of the traceRouteHopsTable is optional." Quittek & White Standards Track [Page 78] RFC 4560 REMOPS MIB June 2006 OBJECT traceRouteMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support SET operations to this object." OBJECT traceRouteCtlByPassRouteTable MIN-ACCESS read-only DESCRIPTION "This object is not required by implementations that are not capable of its implementation. The function represented by this object is implementable if the setsockopt SOL_SOCKET SO_DONTROUTE option is supported." OBJECT traceRouteCtlSourceAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "This object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and IPv6 addresses." OBJECT traceRouteCtlSourceAddress SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "This object is not required by implementations that are not capable of binding the send socket with a source address. An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT traceRouteCtlIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported, return a 0 as the value of this object. A value of 0 implies that the function represented by this option is not supported." OBJECT traceRouteCtlMiscOptions MIN-ACCESS read-only DESCRIPTION "Support of this object is optional. When not supporting, do not allow write access, and return a zero-length octet string as the value of the object." Quittek & White Standards Track [Page 79] RFC 4560 REMOPS MIB June 2006 OBJECT traceRouteCtlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. It is also allowed that implementations support only the volatile StorageType enumeration." OBJECT traceRouteCtlDSField MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported, return a 0 as the value of this object. A value of 0 implies that the function represented by this option is not supported." OBJECT traceRouteCtlType MIN-ACCESS read-only DESCRIPTION "Write access is not required. In addition, the only value that is RECOMMENDED to be supported by an implementation is traceRouteUsingUdpProbes." OBJECT traceRouteResultsIpTgtAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteResultsIpTgtAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteProbeHistoryHAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteProbeHistoryHAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteHopsIpTgtAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } Quittek & White Standards Track [Page 80] RFC 4560 REMOPS MIB June 2006 DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." OBJECT traceRouteHopsIpTgtAddress SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation should only support IPv4 and globally unique IPv6 address values for this object." ::= { traceRouteCompliances 1 } -- MIB groupings traceRouteMinimumGroup OBJECT-GROUP OBJECTS { traceRouteMaxConcurrentRequests, traceRouteCtlTargetAddressType, traceRouteCtlTargetAddress, traceRouteCtlByPassRouteTable, traceRouteCtlDataSize, traceRouteCtlTimeOut, traceRouteCtlProbesPerHop, traceRouteCtlPort, traceRouteCtlMaxTtl, traceRouteCtlDSField, traceRouteCtlSourceAddressType, traceRouteCtlSourceAddress, traceRouteCtlIfIndex, traceRouteCtlMiscOptions, traceRouteCtlMaxFailures, traceRouteCtlDontFragment, traceRouteCtlInitialTtl, traceRouteCtlFrequency, traceRouteCtlStorageType, traceRouteCtlAdminStatus, traceRouteCtlMaxRows, traceRouteCtlTrapGeneration, traceRouteCtlDescr, traceRouteCtlCreateHopsEntries, traceRouteCtlType, traceRouteResultsOperStatus, traceRouteResultsCurHopCount, traceRouteResultsCurProbeCount, traceRouteResultsIpTgtAddrType, traceRouteResultsIpTgtAddr, traceRouteResultsTestAttempts, traceRouteResultsTestSuccesses, traceRouteResultsLastGoodPath Quittek & White Standards Track [Page 81] RFC 4560 REMOPS MIB June 2006 } STATUS current DESCRIPTION "The group of objects that constitute the remote traceroute operation." ::= { traceRouteGroups 5 } traceRouteCtlRowStatusGroup OBJECT-GROUP OBJECTS { traceRouteCtlRowStatus } STATUS current DESCRIPTION "The RowStatus object of the traceRouteCtlTable." ::= { traceRouteGroups 6 } traceRouteHistoryGroup OBJECT-GROUP OBJECTS { traceRouteProbeHistoryHAddrType, traceRouteProbeHistoryHAddr, traceRouteProbeHistoryResponse, traceRouteProbeHistoryStatus, traceRouteProbeHistoryLastRC, traceRouteProbeHistoryTime } STATUS current DESCRIPTION "The group of objects that constitute the history capability." ::= { traceRouteGroups 7 } traceRouteNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { traceRoutePathChange, traceRouteTestFailed, traceRouteTestCompleted } STATUS current DESCRIPTION "The notifications that are required to be supported by implementations of this MIB." ::= { traceRouteGroups 3 } traceRouteHopsTableGroup OBJECT-GROUP OBJECTS { traceRouteHopsIpTgtAddressType, traceRouteHopsIpTgtAddress, Quittek & White Standards Track [Page 82] RFC 4560 REMOPS MIB June 2006 traceRouteHopsMinRtt, traceRouteHopsMaxRtt, traceRouteHopsAverageRtt, traceRouteHopsRttSumOfSquares, traceRouteHopsSentProbes, traceRouteHopsProbeResponses, traceRouteHopsLastGoodProbe } STATUS current DESCRIPTION "The group of objects that constitute the traceRouteHopsTable." ::= { traceRouteGroups 4 } traceRouteGroup OBJECT-GROUP OBJECTS { traceRouteMaxConcurrentRequests, traceRouteCtlTargetAddressType, traceRouteCtlTargetAddress, traceRouteCtlByPassRouteTable, traceRouteCtlDataSize, traceRouteCtlTimeOut, traceRouteCtlProbesPerHop, traceRouteCtlPort, traceRouteCtlMaxTtl, traceRouteCtlDSField, traceRouteCtlSourceAddressType, traceRouteCtlSourceAddress, traceRouteCtlIfIndex, traceRouteCtlMiscOptions, traceRouteCtlMaxFailures, traceRouteCtlDontFragment, traceRouteCtlInitialTtl, traceRouteCtlFrequency, traceRouteCtlStorageType, traceRouteCtlAdminStatus, traceRouteCtlMaxRows, traceRouteCtlTrapGeneration, traceRouteCtlDescr, traceRouteCtlCreateHopsEntries, traceRouteCtlType, traceRouteCtlRowStatus, traceRouteResultsOperStatus, traceRouteResultsCurHopCount, traceRouteResultsCurProbeCount, traceRouteResultsIpTgtAddrType, traceRouteResultsIpTgtAddr, traceRouteResultsTestAttempts, Quittek & White Standards Track [Page 83] RFC 4560 REMOPS MIB June 2006 traceRouteResultsTestSuccesses, traceRouteProbeHistoryHAddrType, traceRouteProbeHistoryHAddr, traceRouteProbeHistoryResponse, traceRouteProbeHistoryStatus, traceRouteProbeHistoryLastRC } STATUS deprecated DESCRIPTION "The group of objects that constitute the remote traceroute operation." ::= { traceRouteGroups 1 } traceRouteTimeStampGroup OBJECT-GROUP OBJECTS { traceRouteResultsLastGoodPath, traceRouteProbeHistoryTime } STATUS deprecated DESCRIPTION "The group of DateAndTime objects." ::= { traceRouteGroups 2 } END 4.3. DISMAN-NSLOOKUP-MIB DISMAN-NSLOOKUP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2, Integer32 FROM SNMPv2-SMI -- RFC2578 RowStatus FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC3411 InetAddressType, InetAddress FROM INET-ADDRESS-MIB; -- RFC4001 lookupMIB MODULE-IDENTITY LAST-UPDATED "200606130000Z" -- 13 June 2006 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Juergen Quittek Quittek & White Standards Track [Page 84] RFC 4560 REMOPS MIB June 2006 NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-115 Email: quittek@netlab.nec.de" DESCRIPTION "The Lookup MIB (DISMAN-NSLOOKUP-MIB) enables determination of either the name(s) corresponding to a host address or of the address(es) associated with a host name at a remote host. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4560; see the RFC itself for full legal notices." -- Revision history REVISION "200606130000Z" -- 13 June 2006 DESCRIPTION "Updated version, published as RFC 4560. - Replaced references to RFC 2575 by RFC 3415 - Replaced references to RFC 2571 by RFC 3411 - Replaced references to RFC 2851 by RFC 4001 - Added value enabled(1) to SYNTAX clause of lookupCtlOperStatus - Added lookupMinimumCompliance - Defined semantics of value 0 for object lookupPurgeTime - Added DEFVAL { unknown } to object lookupCtlTargetAddressType OBJECT-TYPE" REVISION "200009210000Z" -- 21 September 2000 DESCRIPTION "Initial version, published as RFC 2925." ::= { mib-2 82 } -- Top level structure of the MIB lookupObjects OBJECT IDENTIFIER ::= { lookupMIB 1 } lookupConformance OBJECT IDENTIFIER ::= { lookupMIB 2 } -- Simple Object Definitions lookupMaxConcurrentRequests OBJECT-TYPE Quittek & White Standards Track [Page 85] RFC 4560 REMOPS MIB June 2006 SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active lookup requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect. The limit applies only to new requests being activated. When a new value is set, the agent will continue processing all the requests already active, even if their number exceed the limit just imposed." DEFVAL { 10 } ::= { lookupObjects 1 } lookupPurgeTime OBJECT-TYPE SYNTAX Unsigned32 (0..86400) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time to wait before automatically deleting an entry in the lookupCtlTable and any dependent lookupResultsTable entries after the lookup operation represented by a lookupCtlEntry has been completed. A lookupCtEntry is considered complete when its lookupCtlOperStatus object has a value of completed(3). A value of 0 indicates that automatic deletion of entries is disabled." DEFVAL { 900 } -- 15 minutes as default ::= { lookupObjects 2 } -- Lookup Control Table lookupCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF LookupCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Lookup Control Table for providing the capability of performing a lookup operation for a symbolic host name or for a host address from a remote host." Quittek & White Standards Track [Page 86] RFC 4560 REMOPS MIB June 2006 ::= { lookupObjects 3 } lookupCtlEntry OBJECT-TYPE SYNTAX LookupCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the lookupCtlTable. A lookupCtlEntry is initially indexed by lookupCtlOwnerIndex, which is a type of SnmpAdminString, a textual convention that allows for the use of the SNMPv3 View-Based Access Control Model (RFC 3415, VACM) and that also allows a management application to identify its entries. The second index element, lookupCtlOperationName, enables the same lookupCtlOwnerIndex entity to have multiple outstanding requests. The value of lookupCtlTargetAddressType determines which lookup function to perform." INDEX { lookupCtlOwnerIndex, lookupCtlOperationName } ::= { lookupCtlTable 1 } LookupCtlEntry ::= SEQUENCE { lookupCtlOwnerIndex SnmpAdminString, lookupCtlOperationName SnmpAdminString, lookupCtlTargetAddressType InetAddressType, lookupCtlTargetAddress InetAddress, lookupCtlOperStatus INTEGER, lookupCtlTime Unsigned32, lookupCtlRc Integer32, lookupCtlRowStatus RowStatus } lookupCtlOwnerIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (RFC 2575, VACM) for tables in which multiple users may need to create or modify entries independently, the initial index is used as an 'owner index'. Such an initial index has a syntax of SnmpAdminString and can thus be trivially mapped to a Quittek & White Standards Track [Page 87] RFC 4560 REMOPS MIB June 2006 securityName or groupName defined in VACM, in accordance with a security policy. When used in conjunction with such a security policy all entries in the table belonging to a particular user (or group) will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the 'column' subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask 'wildcarding' the column subidentifier. More elaborate configurations are possible." ::= { lookupCtlEntry 1 } lookupCtlOperationName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a lookup operation. This is locally unique, within the scope of an lookupCtlOwnerIndex." ::= { lookupCtlEntry 2 } lookupCtlTargetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the type of address for performing a lookup operation for a symbolic host name or for a host address from a remote host. Specification of dns(16) as the value for this object means that a function such as, for example, getaddrinfo() or gethostbyname() should be performed to return one or more numeric addresses. Use of a value of either ipv4(1) or ipv6(2) means that a functions such as, for example, getnameinfo() or gethostbyaddr() should be used to return the symbolic names associated with a host." DEFVAL { unknown } ::= { lookupCtlEntry 3 } Quittek & White Standards Track [Page 88] RFC 4560 REMOPS MIB June 2006 lookupCtlTargetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the address used for a resolver lookup at a remote host. The corresponding lookupCtlTargetAddressType objects determines its type, as well as the function that can be requested. A value for this object MUST be set prior to transitioning its corresponding lookupCtlEntry to active(1) via lookupCtlRowStatus." ::= { lookupCtlEntry 4 } lookupCtlOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- operation is active notStarted(2), -- operation has not started completed(3) -- operation is done } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of an lookupCtlEntry: enabled(1) - Operation is active. notStarted(2) - Operation has not been enabled. completed(3) - Operation has been completed. An operation is automatically enabled(1) when its lookupCtlRowStatus object is transitioned to active(1) status. Until this occurs, lookupCtlOperStatus MUST report a value of notStarted(2). After the lookup operation is completed (success or failure), the value for lookupCtlOperStatus MUST be transitioned to completed(3)." ::= { lookupCtlEntry 5 } lookupCtlTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Reports the number of milliseconds that a lookup operation required to be completed at a remote host. Completed means operation failure as well as Quittek & White Standards Track [Page 89] RFC 4560 REMOPS MIB June 2006 success." ::= { lookupCtlEntry 6 } lookupCtlRc OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The system-specific return code from a lookup operation. All implementations MUST return a value of 0 for this object when the remote lookup operation succeeds. A non-zero value for this objects indicates failure. It is recommended that implementations return the error codes that are generated by the lookup function used." ::= { lookupCtlEntry 7 } lookupCtlRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows entries to be created and deleted in the lookupCtlTable. A remote lookup operation is started when an entry in this table is created via an SNMP set request and the entry is activated. This occurs by setting the value of this object to CreateAndGo(4) during row creation or by setting this object to active(1) after the row is created. A value MUST be specified for lookupCtlTargetAddress prior to the acceptance of a transition to active(1) state. A remote lookup operation starts when its entry first becomes active(1). Transitions in and out of active(1) state have no effect on the operational behavior of a remote lookup operation, with the exception that deletion of an entry in this table by setting its RowStatus object to destroy(6) will stop an active remote lookup operation. The operational state of a remote lookup operation can be determined by examination of its lookupCtlOperStatus object." REFERENCE Quittek & White Standards Track [Page 90] RFC 4560 REMOPS MIB June 2006 "See definition of RowStatus in RFC 2579, 'Textual Conventions for SMIv2.'" ::= { lookupCtlEntry 8 } -- Lookup Results Table lookupResultsTable OBJECT-TYPE SYNTAX SEQUENCE OF LookupResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the Lookup Results Table for providing the capability of determining the results of a operation at a remote host. One or more entries are added to the lookupResultsTable when a lookup operation, as reflected by an lookupCtlEntry, is completed successfully. All entries related to a successful lookup operation MUST be added to the lookupResultsTable at the same time that the associating lookupCtlOperStatus object is transitioned to completed(2). The number of entries added depends on the results determined for a particular lookup operation. All entries associated with an lookupCtlEntry are removed when the lookupCtlEntry is deleted. A remote host can be multi-homed and have more than one IP address associated with it (returned by lookup function), or it can have more than one symbolic name (returned by lookup function). A function such as, for example, getnameinfo() or gethostbyaddr() is called with a host address as its parameter and is used primarily to determine a symbolic name to associate with the host address. Entries in the lookupResultsTable MUST be made for each host name returned. If the function identifies an 'official host name,' then this symbolic name MUST be assigned a lookupResultsIndex of 1. A function such as, for example, getaddrinfo() or gethostbyname() is called with a symbolic host name and is used primarily to retrieve a host address. The entries Quittek & White Standards Track [Page 91] RFC 4560 REMOPS MIB June 2006 MUST be stored in the order that they are retrieved from the lookup function. lookupResultsIndex 1 MUST be assigned to the first entry." ::= { lookupObjects 4 } lookupResultsEntry OBJECT-TYPE SYNTAX LookupResultsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the lookupResultsTable. The first two index elements identify the lookupCtlEntry that a lookupResultsEntry belongs to. The third index element selects a single lookup operation result." INDEX { lookupCtlOwnerIndex, lookupCtlOperationName, lookupResultsIndex } ::= { lookupResultsTable 1 } LookupResultsEntry ::= SEQUENCE { lookupResultsIndex Unsigned32, lookupResultsAddressType InetAddressType, lookupResultsAddress InetAddress } lookupResultsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the lookupResultsTable are created when the result of a lookup operation is determined. Entries MUST be stored in the lookupResultsTable in the order that they are retrieved. Values assigned to lookupResultsIndex MUST start at 1 and increase consecutively." ::= { lookupResultsEntry 1 } lookupResultsAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION Quittek & White Standards Track [Page 92] RFC 4560 REMOPS MIB June 2006 "Indicates the type of result of a remote lookup operation. A value of unknown(0) implies either that the operation hasn't been started or that it has failed." ::= { lookupResultsEntry 2 } lookupResultsAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects a result for a remote lookup operation as per the value of lookupResultsAddressType. The address type (InetAddressType) that relates to this object is specified by the corresponding value of lookupResultsAddress." ::= { lookupResultsEntry 3 } -- Conformance information -- Compliance statements lookupCompliances OBJECT IDENTIFIER ::= { lookupConformance 1 } lookupGroups OBJECT IDENTIFIER ::= { lookupConformance 2 } -- Compliance statements lookupCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that fully implement the DISMAN-NSLOOKUP-MIB." MODULE -- this module MANDATORY-GROUPS { lookupGroup } OBJECT lookupMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT lookupPurgeTime MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a set operation to this object." Quittek & White Standards Track [Page 93] RFC 4560 REMOPS MIB June 2006 ::= { lookupCompliances 1 } lookupMinimumCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The minimum compliance statement for SNMP entities that implement the minimal subset of the DISMAN-NSLOOKUP-MIB. Implementors might choose this subset for small devices with limited resources." MODULE -- this module MANDATORY-GROUPS { lookupGroup } OBJECT lookupMaxConcurrentRequests MIN-ACCESS read-only DESCRIPTION "The agent is not required to support set operations to this object." OBJECT lookupPurgeTime MIN-ACCESS read-only DESCRIPTION "The agent is not required to support a set operation to this object." OBJECT lookupCtlRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported, then at least one entry in the lookupCtlTable MUST be established already when the SNMP agent starts offering access to the NSLOOKUP-MIB module. If, in such a case, only a single entry is offered, then it is RECOMMENDED that this entry use strings with a length of 0 for both of its two index objects." ::= { lookupCompliances 2 } -- MIB groupings lookupGroup OBJECT-GROUP OBJECTS { lookupMaxConcurrentRequests, lookupPurgeTime, lookupCtlOperStatus, lookupCtlTargetAddressType, lookupCtlTargetAddress, lookupCtlTime, lookupCtlRc, lookupCtlRowStatus, Quittek & White Standards Track [Page 94] RFC 4560 REMOPS MIB June 2006 lookupResultsAddressType, lookupResultsAddress } STATUS current DESCRIPTION "The group of objects that constitute the remote Lookup operation." ::= { lookupGroups 1 } END 5. Security Considerations There are a number of management objects defined in the three MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o pingMaxConcurrentRequests o traceRouteMaxConcurrentRequests o lookupMaxConcurrentRequests The MIB modules limit their maximum numbers of concurrent requests by the values of these objects. Unauthorized access to them may lead to an overload of the managed node and to a disruption of other functions of the managed node. o pingCtlTable o traceRouteCtlTable o lookupCtlTable All objects in entries of these tables (except index objects) have a MAX-ACCESS clause of read-create. Unauthorized access to these objects can disturb the measurements controlled by the tables. Also, the functions offered by the MIB modules can be misused for illegal data retrieval and for attacking other systems by floods of ping probes, traceroute probes or lookup requests, respectively. In general, all three, the ping, traceroute, and lookup functions, when used excessively are considered a form of system attack. In the case of ping, sending a system request too often can negatively effect its performance and attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can, like ping, negatively affect system performance. The same applies to excessive use of the lookup service, particularly if the lookup cannot be resolved locally. In Quittek & White Standards Track [Page 95] RFC 4560 REMOPS MIB June 2006 insecure environments, it is RECOMMENDED that the MIBs defined within this memo not be supported. o lookupPurgeTime Unauthorized access to this object can lead to the deletion of results of lookup operations before they are read by a management system, if the object is set to 0 or small values close to 0. If the object is set to very high values, unauthorized access can lead to a high consumption of resources for storing lookup results. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. However, the only information that can be disclosed without encryption is the configuration and results of measurements that are performed by implementations of the MIB modules. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM), defined in RFC 3415 [RFC3415], for tables in which multiple users may need to create or modify entries independently, the initial index is used as an "owner index." Such an initial index has a syntax of SnmpAdminString and can thus be trivially mapped to a securityName or groupName defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask 'wildcarding' the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is Quittek & White Standards Track [Page 96] RFC 4560 REMOPS MIB June 2006 allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. Acknowledgements This document is a product of the DISMAN Working Group. Thanks to Eduardo Cardona for suggesting the minimum compliance statements and to Juergen Schoenwaelder for the very detailed and constructive MIB review. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Quittek & White Standards Track [Page 97] RFC 4560 REMOPS MIB June 2006 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 7.2. Informative References [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Quittek & White Standards Track [Page 98] RFC 4560 REMOPS MIB June 2006 Authors' Addresses Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-115 EMail: quittek@netlab.nec.de Kenneth D. White Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA EMail: wkenneth@us.ibm.com Quittek & White Standards Track [Page 99] RFC 4560 REMOPS MIB June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Quittek & White Standards Track [Page 100] snmp-mibs-downloader-1.1/mibrfcs/rfc4624.txt0000644000000000000000000016260711402176072015576 0ustar Network Working Group B. Fenner Request for Comments: 4624 AT&T Research Category: Experimental D. Thaler Microsoft October 2006 Multicast Source Discovery Protocol (MSDP) MIB Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract 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 managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers. Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Overview ........................................................2 4. Definitions .....................................................3 5. Security Considerations ........................................28 6. IANA Considerations ............................................29 7. Acknowledgements ...............................................30 8. References .....................................................30 8.1. Normative References ......................................30 8.2. Informative References ....................................30 Fenner & Thaler Experimental [Page 1] RFC 4624 MSDP MIB October 2006 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 managed objects used for managing Multicast Source Discovery Protocol (MSDP) [1] speakers. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [7]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [4], STD 58, RFC 2579 [5] and STD 58, RFC 2580 [6]. 3. Overview This MIB module contains four scalars and four tables, one deprecated. The tables are: o The deprecated Requests Table, containing the longest-match table used to determine the peer to send SA-Requests to for a given group. This table is deprecated because Requests were removed from MSDP before it became an RFC. o The Peer Table, containing information on the system's peers. o The Source-Active (SA) Cache Table, containing the SA cache entries. o The Mesh Group Table, containing the list of MSDP mesh groups to which this system belongs. This MIB module uses the IpAddress SYNTAX, making it only suitable for IPv4 systems. Although the desired direction for MIBs is to use InetAddressType/InetAddress pairs to allow both IPv4 and IPv6 (and future formats as well), the MSDP protocol itself is IPv4-only, and the MSDP working group made an explicit decision not to create an IPv6 version of the protocol. Fenner & Thaler Experimental [Page 2] RFC 4624 MSDP MIB October 2006 This MIB module is somewhat disorganized, with scalars before and after tables, holes in the OID space, tables with the RowStatus in the middle, and so on. This is because objects were added and removed as necessary as the MSDP protocol evolved, and the plan was to renumber the whole MIB when moving to the standard mib-2 tree. The MSDP Working Group then changed direction, publishing the MSDP protocol as Experimental. Since there were existing implementations using the strange object order under the experimental OID, the WG decided not to renumber the MIB and to publish it as experimental, keeping the experimental OID. 4. Definitions -- -- MSDP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Counter32, Gauge32, TimeTicks, Integer32, IpAddress FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp, DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; msdpMIB MODULE-IDENTITY LAST-UPDATED "200608010000Z" ORGANIZATION "IETF MBONED Working Group" CONTACT-INFO "Bill Fenner 75 Willow Road Menlo Park, CA 94025 Phone: +1 650 867 6073 E-mail: fenner@research.att.com Dave Thaler One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 8835 Email: dthaler@microsoft.com MBONED Working Group: mboned@lists.uoregon.edu" DESCRIPTION "An experimental MIB module for MSDP Management and Monitoring. Fenner & Thaler Experimental [Page 3] RFC 4624 MSDP MIB October 2006 Copyright (C) The Internet Society 2006. This version of this MIB module is part of RFC 4624; see the RFC itself for full legal notices." REVISION "200608010000Z" DESCRIPTION "Initial version, published as RFC 4624." ::= { experimental 92 } msdpMIBobjects OBJECT IDENTIFIER ::= { msdpMIB 1 } msdp OBJECT IDENTIFIER ::= { msdpMIBobjects 1 } msdpEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The state of MSDP on this MSDP speaker - globally enabled or disabled. Changes to this object should be stored to non-volatile memory." ::= { msdp 1 } msdpCacheLifetime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "The lifetime given to SA cache entries when created or refreshed. This is the [SG-State-Period] in the MSDP spec. A value of 0 means no SA caching is done by this MSDP speaker. Changes to this object should be stored to non-volatile memory. This object does not measure time per se; instead, it is the delta from the time at which an SA message is received at which it should be expired if not refreshed. (i.e., it is the value of msdpSACacheExpiryTime immediately after receiving an SA message applying to that row.) As such, TimeInterval would be a more appropriate SYNTAX; it remains TimeTicks for backwards compatibility." REFERENCE "RFC 3618 section 5.3" ::= { msdp 2 } Fenner & Thaler Experimental [Page 4] RFC 4624 MSDP MIB October 2006 msdpNumSACacheEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of entries in the SA Cache table." ::= { msdp 3 } -- -- The spec doesn't define SA-Hold-Down-Period any more. -- msdpSAHoldDownPeriod OBJECT-TYPE -- ::= { msdp 9 } -- This object was introduced in error, with a similar definition -- to msdpCacheLifetime. -- msdpSAStatePeriod OBJECT-TYPE -- ::= { msdp 10 } msdpRPAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The Rendezvous Point (RP) address used when sourcing MSDP SA messages. May be 0.0.0.0 on non-RPs. Changes to this object should be stored to non-volatile memory." ::= { msdp 11 } -- -- The MSDP Requests table -- SA Requests were removed from the MSDP spec, so this entire table -- is deprecated. msdpRequestsTable OBJECT-TYPE SYNTAX SEQUENCE OF MsdpRequestsEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table listing group ranges and MSDP peers used when deciding where to send an SA Request message, when required. If SA Requests are not enabled, this table may be empty. In order to choose a peer to whom to send an SA Request for a given group, G, the subset of entries in this table whose (msdpRequestsPeerType, msdpRequestsPeer) tuple represents a Fenner & Thaler Experimental [Page 5] RFC 4624 MSDP MIB October 2006 peer whose msdpPeerState is established are examined. The set is further reduced by examining only those entries for which msdpPeerRequestsGroupAddressType equals the address type of G. The entries with the highest value of msdpRequestsGroupPrefix are considered, where the group G falls within the range described by the combination of msdpRequestsGroup and msdpRequestsGroupPrefix. (This sequence is commonly known as a 'longest-match' lookup.) Finally, if multiple entries remain, the entry with the lowest value of msdpRequestsPriority is chosen. The SA Request message is sent to the peer described by this row." ::= { msdp 4 } msdpRequestsEntry OBJECT-TYPE SYNTAX MsdpRequestsEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) representing a group range used when deciding where to send an SA Request message." INDEX { msdpRequestsGroupAddress, msdpRequestsGroupMask } ::= { msdpRequestsTable 1 } MsdpRequestsEntry ::= SEQUENCE { msdpRequestsGroupAddress IpAddress, msdpRequestsGroupMask IpAddress, msdpRequestsPeer IpAddress, msdpRequestsStatus RowStatus } msdpRequestsGroupAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The group address that, when combined with the mask in this entry, represents the group range to which this row applies." ::= { msdpRequestsEntry 1 } msdpRequestsGroupMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The mask that, when combined with the group address Fenner & Thaler Experimental [Page 6] RFC 4624 MSDP MIB October 2006 in this entry, represents the group range to which this row applies." ::= { msdpRequestsEntry 2 } msdpRequestsPeer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The peer to which MSDP SA Requests for groups matching this entry's group range will be sent. This object, combined with msdpRequestsPeerType, must match the INDEX of a row in the msdpPeerTable, and to be considered, this peer's msdpPeerState must be established." ::= { msdpRequestsEntry 3 } msdpRequestsStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this row, by which new rows may be added to the table or old rows may be deleted." ::= { msdpRequestsEntry 4 } -- -- The MSDP Peer table -- msdpPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF MsdpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the MSDP speaker's peers." ::= { msdp 5 } msdpPeerEntry OBJECT-TYPE SYNTAX MsdpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an MSDP peer. If row creation is supported, dynamically added rows are added to the system's stable configuration (corresponding to a StorageType value of nonVolatile). " Fenner & Thaler Experimental [Page 7] RFC 4624 MSDP MIB October 2006 INDEX { msdpPeerRemoteAddress } ::= { msdpPeerTable 1 } MsdpPeerEntry ::= SEQUENCE { msdpPeerRemoteAddress IpAddress, msdpPeerState INTEGER, msdpPeerRPFFailures Counter32, msdpPeerInSAs Counter32, msdpPeerOutSAs Counter32, msdpPeerInSARequests Counter32, msdpPeerOutSARequests Counter32, msdpPeerInSAResponses Counter32, msdpPeerOutSAResponses Counter32, msdpPeerInControlMessages Counter32, msdpPeerOutControlMessages Counter32, msdpPeerInDataPackets Counter32, msdpPeerOutDataPackets Counter32, msdpPeerFsmEstablishedTransitions Counter32, msdpPeerFsmEstablishedTime TimeStamp, msdpPeerInMessageTime TimeStamp, msdpPeerLocalAddress IpAddress, msdpPeerConnectRetryInterval Integer32, msdpPeerHoldTimeConfigured Integer32, msdpPeerKeepAliveConfigured Integer32, msdpPeerDataTtl Integer32, msdpPeerProcessRequestsFrom TruthValue, msdpPeerStatus RowStatus, msdpPeerRemotePort Integer32, msdpPeerLocalPort Integer32, msdpPeerEncapsulationType INTEGER, msdpPeerConnectionAttempts Counter32, msdpPeerInNotifications Counter32, msdpPeerOutNotifications Counter32, msdpPeerLastError OCTET STRING, msdpPeerDiscontinuityTime TimeStamp } msdpPeerRemoteAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the remote MSDP peer." ::= { msdpPeerEntry 1 } -- dunno what happened to 2. msdpPeerState OBJECT-TYPE Fenner & Thaler Experimental [Page 8] RFC 4624 MSDP MIB October 2006 SYNTAX INTEGER { inactive(1), listen(2), connecting(3), established(4), disabled(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the MSDP TCP connection with this peer." ::= { msdpPeerEntry 3 } msdpPeerRPFFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SA messages received from this peer that failed the Peer-RPF check. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 4 } msdpPeerInSAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA messages received on this connection. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 5 } msdpPeerOutSAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA messages transmitted on this connection. Fenner & Thaler Experimental [Page 9] RFC 4624 MSDP MIB October 2006 Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 6 } msdpPeerInSARequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA-Request messages received on this connection. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 7 } msdpPeerOutSARequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA-Request messages transmitted on this connection. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 8 } msdpPeerInSAResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of MSDP SA-Response messages received on this connection. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 9 } Fenner & Thaler Experimental [Page 10] RFC 4624 MSDP MIB October 2006 msdpPeerOutSAResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of MSDP SA Response messages transmitted on this TCP connection. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 10 } msdpPeerInControlMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of MSDP messages, excluding encapsulated data packets, received on this TCP connection. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 11 } msdpPeerOutControlMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of MSDP messages, excluding encapsulated data packets, transmitted on this TCP connection. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 12 } msdpPeerInDataPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of encapsulated data packets received Fenner & Thaler Experimental [Page 11] RFC 4624 MSDP MIB October 2006 from this peer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 13 } msdpPeerOutDataPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of encapsulated data packets sent to this peer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of msdpPeerDiscontinuityTime." ::= { msdpPeerEntry 14 } msdpPeerFsmEstablishedTransitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times the MSDP FSM transitioned into the ESTABLISHED state." REFERENCE "RFC 3618 section 11" ::= { msdpPeerEntry 15 } msdpPeerFsmEstablishedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This timestamp is set to the value of sysUpTime when a peer transitions into or out of the ESTABLISHED state. It is set to zero when the MSDP speaker is booted." REFERENCE "RFC 3618 section 11" ::= { msdpPeerEntry 16 } msdpPeerInMessageTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Fenner & Thaler Experimental [Page 12] RFC 4624 MSDP MIB October 2006 "The sysUpTime value when the last MSDP message was received from the peer. It is set to zero when the MSDP speaker is booted." ::= { msdpPeerEntry 17 } msdpPeerLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The local IP address used for this entry's MSDP TCP connection." ::= { msdpPeerEntry 18 } -- msdpPeerSAAdvPeriod ([SA-Advertisement-Timer]) has been removed. -- ::= { msdpPeerEntry 19 } -- RFC 3618, Section 5.1, says it MUST be 60 seconds. msdpPeerConnectRetryInterval OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Time interval, in seconds, for the [ConnectRetry-period] for this peer." REFERENCE "RFC 3618 section 5.6" DEFVAL { 30 } ::= { msdpPeerEntry 20 } msdpPeerHoldTimeConfigured OBJECT-TYPE SYNTAX Integer32 (0|3..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Time interval, in seconds, for the [HoldTime-Period] configured for this MSDP speaker with this peer. If the value of this object is zero (0), the MSDP connection is never torn down due to the absence of messages from the peer." REFERENCE "RFC 3618 section 5.4" DEFVAL { 75 } ::= { msdpPeerEntry 21 } msdpPeerKeepAliveConfigured OBJECT-TYPE SYNTAX Integer32 (0|1..21845) Fenner & Thaler Experimental [Page 13] RFC 4624 MSDP MIB October 2006 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Time interval, in seconds, for the [KeepAlive-Period] configured for this MSDP speaker with this peer. If the value of this object is zero (0), no periodic KEEPALIVE messages are sent to the peer after the MSDP connection has been established." REFERENCE "RFC 3618 section 5.5" DEFVAL { 60 } ::= { msdpPeerEntry 22 } msdpPeerDataTtl OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum TTL a packet is required to have before it may be forwarded using SA encapsulation to this peer." DEFVAL { 1 } ::= { msdpPeerEntry 23 } msdpPeerProcessRequestsFrom OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object indicates whether to process MSDP SA Request messages from this peer. If True(1), MSDP SA Request messages from this peer are processed and replied to (if appropriate) with SA Response messages. If False(2), MSDP SA Request messages from this peer are silently ignored. It defaults to False when msdpCacheLifetime is 0 and to True when msdpCacheLifetime is non-0. This object is deprecated because MSDP SA Requests were removed from the MSDP specification." ::= { msdpPeerEntry 24 } msdpPeerStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The RowStatus object by which peers can be added and deleted. A transition to 'active' will cause the MSDP Fenner & Thaler Experimental [Page 14] RFC 4624 MSDP MIB October 2006 'Enable MSDP peering with P' Event to be generated. A transition out of the 'active' state will cause the MSDP 'Disable MSDP peering with P' Event to be generated. Care should be used in providing write access to this object without adequate authentication. msdpPeerRemoteAddress is the only variable that must be set to a valid value before the row can be activated. Since this is the table's INDEX, a row can be activated by simply setting the msdpPeerStatus variable. It is possible to modify other columns in the same conceptual row when the status value is active(1)." REFERENCE "RFC 3618 section 11.1" ::= { msdpPeerEntry 25 } msdpPeerRemotePort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The remote port for the TCP connection between the MSDP peers." DEFVAL { 639 } ::= { msdpPeerEntry 26 } msdpPeerLocalPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The local port for the TCP connection between the MSDP peers." DEFVAL { 639 } ::= { msdpPeerEntry 27 } -- msdpPeerEncapsulationState has been removed -- because there is no longer an encapsulation -- state machine. -- ::= { msdpPeerEntry 28 } msdpPeerEncapsulationType OBJECT-TYPE SYNTAX INTEGER { none(0), tcp(1) } MAX-ACCESS read-create STATUS current Fenner & Thaler Experimental [Page 15] RFC 4624 MSDP MIB October 2006 DESCRIPTION "The encapsulation in use when encapsulating data in SA messages to this peer." ::= { msdpPeerEntry 29 } msdpPeerConnectionAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the state machine has transitioned from INACTIVE to CONNECTING." ::= { msdpPeerEntry 30 } msdpPeerInNotifications OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of MSDP Notification messages received from this peer. This object is deprecated because MSDP Notifications have been removed from the spec." ::= { msdpPeerEntry 31 } msdpPeerOutNotifications OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of MSDP Notification messages transmitted to this peer. This object is deprecated because MSDP Notifications have been removed from the spec." ::= { msdpPeerEntry 32 } msdpPeerLastError OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The last error code and subcode received via Notification from this peer. If no error has occurred, this field is zero. Otherwise, the first byte of this two-byte OCTET STRING contains the O-bit and error code, and the second byte contains the subcode. Fenner & Thaler Experimental [Page 16] RFC 4624 MSDP MIB October 2006 This object is deprecated because MSDP Notifications have been removed from the spec." DEFVAL { '0000'h } ::= { msdpPeerEntry 33 } msdpPeerDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which one or more of this entry's counters suffered a discontinuity. See the DESCRIPTION of each object to see if it is expected to have discontinuities. These discontinuities may occur at peer connection establishment. If no such discontinuities have occurred since the last reinitialization of the local management subsystem, then this object contains a zero value." ::= { msdpPeerEntry 34 } -- -- The MSDP Source-Active Cache table -- msdpSACacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MsdpSACacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the MSDP SA advertisements currently in the MSDP speaker's cache." ::= { msdp 6 } msdpSACacheEntry OBJECT-TYPE SYNTAX MsdpSACacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an MSDP SA advertisement. The INDEX to this table includes msdpSACacheOriginRP for diagnosing incorrect MSDP advertisements; normally, a Group and Source pair would be unique. Row creation is not permitted; msdpSACacheStatus may only be used to delete rows from this table." Fenner & Thaler Experimental [Page 17] RFC 4624 MSDP MIB October 2006 INDEX { msdpSACacheGroupAddr, msdpSACacheSourceAddr, msdpSACacheOriginRP } ::= { msdpSACacheTable 1 } MsdpSACacheEntry ::= SEQUENCE { msdpSACacheGroupAddr IpAddress, msdpSACacheSourceAddr IpAddress, msdpSACacheOriginRP IpAddress, msdpSACachePeerLearnedFrom IpAddress, msdpSACacheRPFPeer IpAddress, msdpSACacheInSAs Counter32, msdpSACacheInDataPackets Counter32, msdpSACacheUpTime TimeTicks, msdpSACacheExpiryTime TimeTicks, msdpSACacheStatus RowStatus } msdpSACacheGroupAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group address of the SA Cache entry." ::= { msdpSACacheEntry 1 } msdpSACacheSourceAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The source address of the SA Cache entry." ::= { msdpSACacheEntry 2 } msdpSACacheOriginRP OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RP of the SA Cache entry. This field is in the INDEX in order to catch multiple RP's advertising the same source and group." ::= { msdpSACacheEntry 3 } msdpSACachePeerLearnedFrom OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION Fenner & Thaler Experimental [Page 18] RFC 4624 MSDP MIB October 2006 "The peer from which this SA Cache entry was last accepted. This address must correspond to the msdpPeerRemoteAddress value for a row in the MSDP Peer Table. This should be 0.0.0.0 on the router that originated the entry." ::= { msdpSACacheEntry 4 } msdpSACacheRPFPeer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The peer from which an SA message corresponding to this cache entry would be accepted (i.e., the RPF peer for msdpSACacheOriginRP). This may be different than msdpSACachePeerLearnedFrom if this entry was created by an MSDP SA-Response. This address must correspond to the msdpPeerRemoteAddress value for a row in the MSDP Peer Table, or it may be 0.0.0.0 if no RPF peer exists." ::= { msdpSACacheEntry 5 } msdpSACacheInSAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA messages received relevant to this cache entry. This object must be initialized to zero when creating a cache entry." ::= { msdpSACacheEntry 6 } msdpSACacheInDataPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP-encapsulated data packets received relevant to this cache entry. This object must be initialized to zero when creating a cache entry." ::= { msdpSACacheEntry 7 } msdpSACacheUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was first placed in the SA cache. Fenner & Thaler Experimental [Page 19] RFC 4624 MSDP MIB October 2006 The first epoch is the time that the entry was first placed in the SA cache, and the second epoch is the current time." ::= { msdpSACacheEntry 8 } msdpSACacheExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before this entry will expire from the SA cache. The first epoch is now, and the second epoch is the time that the entry will expire." ::= { msdpSACacheEntry 9 } msdpSACacheStatus OBJECT-TYPE SYNTAX RowStatus { active(1), destroy(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The status of this row in the table. The only allowable actions are to retrieve the status, which will be 'active', or to set the status to 'destroy' in order to remove this entry from the cache. Row creation is not permitted. No columnar objects are writable, so there are none that may be changed while the status value is active(1)." ::= { msdpSACacheEntry 10 } -- -- MSDP Mesh Group Membership table -- msdpMeshGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF MsdpMeshGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing MSDP Mesh Group configuration." ::= { msdp 12 } msdpMeshGroupEntry OBJECT-TYPE Fenner & Thaler Experimental [Page 20] RFC 4624 MSDP MIB October 2006 SYNTAX MsdpMeshGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing a peer in an MSDP Mesh Group. If row creation is supported, dynamically added rows are added to the system's stable configuration (corresponding to a StorageType value of nonVolatile)." INDEX { msdpMeshGroupName, msdpMeshGroupPeerAddress } ::= { msdpMeshGroupTable 1 } MsdpMeshGroupEntry ::= SEQUENCE { msdpMeshGroupName DisplayString, msdpMeshGroupPeerAddress IpAddress, msdpMeshGroupStatus RowStatus } msdpMeshGroupName OBJECT-TYPE SYNTAX DisplayString (SIZE(1..64)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the mesh group." ::= { msdpMeshGroupEntry 1 } msdpMeshGroupPeerAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "A peer address that is a member of the mesh group with name msdpMeshGroupName. The msdpMeshGroupPeerAddress must match a row in the msdpPeerTable." ::= { msdpMeshGroupEntry 2 } msdpMeshGroupStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This entry's status, by which new entries may be added to the table and old entries deleted. msdpMeshGroupName and msdpMeshGroupPeerAddress must be set to valid values before the row can be activated. Since these are the table's INDEX, a row can be activated Fenner & Thaler Experimental [Page 21] RFC 4624 MSDP MIB October 2006 by simply setting the msdpMeshGroupStatus variable. It is not possible to modify other columns in the same conceptual row when the status value is active(1), because the only other objects in the row are part of the INDEX. Changing one of these changes the row, so an old row must be deleted and a new one created." ::= { msdpMeshGroupEntry 3 } -- Traps msdpTraps OBJECT IDENTIFIER ::= { msdp 0 } msdpEstablished NOTIFICATION-TYPE OBJECTS { msdpPeerFsmEstablishedTransitions } STATUS current DESCRIPTION "The MSDP Established event is generated when the MSDP FSM enters the ESTABLISHED state." ::= { msdpTraps 1 } msdpBackwardTransition NOTIFICATION-TYPE OBJECTS { msdpPeerState } STATUS current DESCRIPTION "The MSDPBackwardTransition Event is generated when the MSDP FSM moves from a higher-numbered state to a lower-numbered state." ::= { msdpTraps 2 } -- conformance information msdpMIBConformance OBJECT IDENTIFIER ::= { msdp 8 } msdpMIBCompliances OBJECT IDENTIFIER ::= { msdpMIBConformance 1 } msdpMIBGroups OBJECT IDENTIFIER ::= { msdpMIBConformance 2 } -- compliance statements msdpMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for entities that implement a pre- RFC version of MSDP. This statement is deprecated because it includes objects used for managing/monitoring aspects of MSDP that were removed before it was published as an RFC." MODULE -- this module MANDATORY-GROUPS { msdpMIBGlobalsGroup, msdpMIBPeerGroup, Fenner & Thaler Experimental [Page 22] RFC 4624 MSDP MIB October 2006 msdpMIBNotificationGroup } GROUP msdpMIBEncapsulationGroup DESCRIPTION "This group is mandatory if MSDP encapsulation interfaces are not given their own interface index numbers." GROUP msdpMIBSACacheGroup DESCRIPTION "This group is mandatory if the MSDP speaker has the ability to cache SA messages." GROUP msdpMIBRequestsGroup DESCRIPTION "This group is mandatory if the MSDP speaker has the ability to send SA-Request messages and to parse SA-Response messages." GROUP msdpMIBRPGroup DESCRIPTION "This group is mandatory if the MSDP speaker sources (as opposed to forwards) MSDP messages." GROUP msdpMIBMeshGroupGroup DESCRIPTION "This group is mandatory if the MSDP speaker can participate in MSDP Mesh Groups." ::= { msdpMIBCompliances 1 } msdpMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement MSDP (RFC3618)." MODULE -- this module MANDATORY-GROUPS { msdpMIBGlobalsGroup, msdpMIBPeerGroup2, msdpMIBSACacheGroup, msdpMIBEncapsulationGroup } GROUP msdpMIBRPGroup DESCRIPTION "This group is mandatory if the MSDP speaker sources (as opposed to forwards) MSDP messages." GROUP msdpMIBMeshGroupGroup DESCRIPTION "This group is mandatory if the MSDP speaker can participate in MSDP Mesh Groups." ::= { msdpMIBCompliances 2 } msdpMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement MSDP (RFC3618), but do not permit configuration (or only permit Fenner & Thaler Experimental [Page 23] RFC 4624 MSDP MIB October 2006 partial configuration) via SNMP." MODULE -- this module MANDATORY-GROUPS { msdpMIBGlobalsGroup, msdpMIBPeerGroup2, msdpMIBSACacheGroup, msdpMIBEncapsulationGroup } GROUP msdpMIBRPGroup DESCRIPTION "This group is mandatory if the MSDP speaker sources (as opposed to forwards) MSDP messages." GROUP msdpMIBMeshGroupGroup DESCRIPTION "This group is mandatory if the MSDP speaker can participate in MSDP Mesh Groups." OBJECT msdpEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpCacheLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpPeerLocalAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpPeerConnectRetryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpPeerHoldTimeConfigured MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpPeerKeepAliveConfigured MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpPeerDataTtl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpPeerStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpPeerEncapsulationType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Fenner & Thaler Experimental [Page 24] RFC 4624 MSDP MIB October 2006 OBJECT msdpSACacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpRPAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT msdpMeshGroupStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { msdpMIBCompliances 3 } -- units of conformance msdpMIBGlobalsGroup OBJECT-GROUP OBJECTS { msdpEnabled } STATUS current DESCRIPTION "A collection of objects providing information on global MSDP state." ::= { msdpMIBGroups 1 } msdpMIBPeerGroup OBJECT-GROUP OBJECTS { msdpPeerRPFFailures, msdpPeerState, msdpPeerInSAs, msdpPeerOutSAs, msdpPeerInSARequests, msdpPeerOutSARequests, msdpPeerInSAResponses, msdpPeerOutSAResponses, msdpPeerInNotifications, msdpPeerOutNotifications, msdpPeerInControlMessages, msdpPeerOutControlMessages, msdpPeerFsmEstablishedTransitions, msdpPeerFsmEstablishedTime, msdpPeerLocalAddress, msdpPeerRemotePort, msdpPeerLocalPort, msdpPeerConnectRetryInterval, msdpPeerHoldTimeConfigured, msdpPeerKeepAliveConfigured, msdpPeerInMessageTime, msdpPeerProcessRequestsFrom, msdpPeerConnectionAttempts, msdpPeerLastError, msdpPeerStatus, msdpPeerDiscontinuityTime } STATUS deprecated DESCRIPTION "A collection of objects for managing MSDP peers. This group Fenner & Thaler Experimental [Page 25] RFC 4624 MSDP MIB October 2006 is deprecated in favor of msdpMIBPeerGroup2 because it contains objects for managing aspects of MSDP that were removed before it was published as an RFC." ::= { msdpMIBGroups 2 } msdpMIBEncapsulationGroup OBJECT-GROUP OBJECTS { msdpPeerInDataPackets, msdpPeerOutDataPackets, msdpPeerDataTtl, msdpPeerEncapsulationType } STATUS current DESCRIPTION "A collection of objects for managing encapsulations if the MSDP encapsulation interfaces are not given interface indices." ::= { msdpMIBGroups 3 } msdpMIBSACacheGroup OBJECT-GROUP OBJECTS { msdpCacheLifetime, msdpNumSACacheEntries, msdpSACachePeerLearnedFrom, msdpSACacheRPFPeer, msdpSACacheInSAs, msdpSACacheInDataPackets, msdpSACacheUpTime, msdpSACacheExpiryTime, msdpSACacheStatus } STATUS current DESCRIPTION "A collection of objects for managing MSDP SA cache entries." ::= { msdpMIBGroups 4 } msdpMIBNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { msdpEstablished, msdpBackwardTransition } STATUS current DESCRIPTION "A collection of notifications for signaling changes in MSDP peer relationships." ::= { msdpMIBGroups 5 } msdpMIBRequestsGroup OBJECT-GROUP OBJECTS { msdpRequestsPeer, msdpRequestsStatus } STATUS deprecated DESCRIPTION "A collection of objects for managing MSDP Request transmission. This group is deprecated because Requests were removed from MSDP before its publication as an RFC." ::= { msdpMIBGroups 6 } msdpMIBRPGroup OBJECT-GROUP Fenner & Thaler Experimental [Page 26] RFC 4624 MSDP MIB October 2006 OBJECTS { msdpRPAddress } STATUS current DESCRIPTION "A collection of objects for MSDP speakers that source MSDP messages." ::= { msdpMIBGroups 7 } msdpMIBMeshGroupGroup OBJECT-GROUP OBJECTS { msdpMeshGroupStatus } STATUS current DESCRIPTION "A collection of objects for MSDP speakers that can participate in MSDP mesh groups." ::= { msdpMIBGroups 8 } msdpMIBPeerGroup2 OBJECT-GROUP OBJECTS { msdpPeerRPFFailures, msdpPeerState, msdpPeerInSAs, msdpPeerOutSAs, msdpPeerInSARequests, msdpPeerOutSARequests, msdpPeerInControlMessages, msdpPeerOutControlMessages, msdpPeerFsmEstablishedTransitions, msdpPeerFsmEstablishedTime, msdpPeerLocalAddress, msdpPeerRemotePort, msdpPeerLocalPort, msdpPeerConnectRetryInterval, msdpPeerHoldTimeConfigured, msdpPeerKeepAliveConfigured, msdpPeerInMessageTime, msdpPeerConnectionAttempts, msdpPeerStatus, msdpPeerDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects for managing MSDP peers." ::= { msdpMIBGroups 9 } END Fenner & Thaler Experimental [Page 27] RFC 4624 MSDP MIB October 2006 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: msdpEnabled Obviously, by modifying msdpEnabled, an attacker could simply disable MSDP processing on the router. msdpCacheLifetime If allowed to modify msdpCacheLifetime, an attacker could set the value to a value lower than a peer's refresh interval, causing all state to time out and be refreshed. msdpRequestsPeer, msdpRequestsStatus If allowed to modify entries in the msdpRequestsTable, an attacker could cause this system to send MSDP Requests to an unknown system, or could simply remove the proper configuration. Note that the msdpRequestsTable is deprecated, and the MSDP Request functionality is not in the published MSDP spec. msdpPeerTable objects The writable objects in the msdpPeerTable are: msdpPeerLocalAddress, msdpPeerConnectRetryInterval, msdpPeerHoldTimeConfigured, msdpPeerKeepAliveConfigured, msdpPeerDataTtl, msdpPeerProcessRequestsFrom, msdpPeerStatus, and msdpPeerEncapsulationType. Of these, modifying msdpPeerIpAddress and msdpPeerStatus could cause a changed or deleted peer configuration. Modifying any of the other values could cause subtle protocol misbehavior. msdpSACacheStatus This writable object can be used to remove valid values from the router's SA cache. msdpRPAddress Changing this object can cause a failure of the Peer-RPF rules for SA messages sourced by this router. msdpMeshGroupStatus This object can be used to change this router's idea of its mesh group membership and those of its peers. Misconfiguration of mesh groups can cause subtle protocol misbehavior. Fenner & Thaler Experimental [Page 28] RFC 4624 MSDP MIB October 2006 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o The entire msdpPeerTable. Peer information can result in discovering internal topology, which many want to keep secret. o msdpNumSACacheEntries. The size of the SA Cache could reveal whether this system has MSDP entries for public and/or private groups. o The entire msdpSACacheTable. The active sources and groups in a network could be private. o The entire msdpMeshGroupTable. This information can also lead to internal topology information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [6], Section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations Since this MIB is for an experimental protocol, it uses an experimental OID. Decimal Name Description References ------- ---- ----------- ---------- 92 MSDP-MIB Multicast Source Discovery MIB RFC 4624 Fenner & Thaler Experimental [Page 29] RFC 4624 MSDP MIB October 2006 7. Acknowledgements Tom Pusateri and Billy Ng both provided valuable input on early versions of this document. It was completed with feedback from Mike Davison and Ketan Talaulikar. Lucy Lynch provided a desperately needed reminder to finish this document. 8. References 8.1 Normative References [1] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [2] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [3] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [5] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [6] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 8.2. Informative References [7] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Fenner & Thaler Experimental [Page 30] RFC 4624 MSDP MIB October 2006 Authors' Addresses Bill Fenner 1 River Oaks Place San Jose, CA 95134-1918 Phone: +1 (408 493-8505 EMail: fenner@research.att.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com Fenner & Thaler Experimental [Page 31] RFC 4624 MSDP MIB October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Fenner & Thaler Experimental [Page 32] snmp-mibs-downloader-1.1/mibrfcs/rfc4625.txt0000644000000000000000000012047611402176072015575 0ustar Network Working Group C. DeSanti Request for Comments: 4625 K. McCloghrie Category: Standards Track Cisco Systems S. Kode Consultant S. Gai Retired September 2006 Fibre Channel Routing Information MIB 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. DeSanti, et al. Standards Track [Page 1] RFC 4625 FC Routing Information MIB September 2006 Table of Contents 1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Short Overview of Fibre Channel .................................3 3.1. Introduction ...............................................3 3.2. Routing Protocols ..........................................4 3.3. Virtual Fabrics ............................................4 4. Relationship to Other MIBs ......................................5 5. MIB Overview ....................................................5 5.1. Fibre Channel Management Instance ..........................5 5.2. Switch Index ...............................................6 5.3. Fabric Index ...............................................6 5.4. The t11FcRouteGroup Group ..................................6 5.5. The t11FcRouteTable's INDEX ................................6 6. The T11-FC-ROUTE-MIB Module .....................................7 7. Acknowledgements ...............................................17 8. IANA Considerations ............................................17 9. Security Considerations ........................................17 10. Normative References ..........................................19 11. Informative References ........................................20 DeSanti, et al. Standards Track [Page 2] RFC 4625 FC Routing Information MIB September 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Routing Table for routing within a Fabric. Managed objects specific to particular routing protocols, such as the Fabric Shortest Path First (FSPF) protocol [FC-SW-4], are not specified in this MIB module. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of Fibre Channel 3.1. Introduction The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols, such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port DeSanti, et al. Standards Track [Page 3] RFC 4625 FC Routing Information MIB September 2006 is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the fabric, each node, and most ports, have globally-unique names. These globally-unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, a Domain_ID being the highest level of the hierarchy. 3.2. Routing Protocols The routing of frames within the Fabric is normally based on the standard routing protocol, called the Fabric Shortest Path First (FSPF) protocol. The operation of FSPF (or of any other routing protocol) allows a switch to generate and maintain its own routing table of how to forward frames it receives; i.e., a table in which to look up the destination address of a received frame in order to determine the best link by which to forward that frame towards its destination. 3.3. Virtual Fabrics The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4] (which replaces the previous revision, [FC-SW-3]). [FC-SW-4] carries forward the existing specification for the operation of a single Fabric in a physical infrastructure, augmenting it with the definition of Virtual Fabrics and with the specification of how multiple Virtual Fabrics can operate within one (or more) physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core switch. DeSanti, et al. Standards Track [Page 4] RFC 4625 FC Routing Information MIB September 2006 4. Relationship to Other MIBs The first standardized MIB for Fibre Channel [RFC2837] was focussed on Fibre Channel switches. It is being replaced by the more generic Fibre Channel Management MIB [FC-MGMT], which defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB [RFC2863] for Fibre Channel interfaces. This MIB extends beyond [FC-MGMT] to cover the routing of traffic within a Fabric of a Fibre Channel network. The standard routing protocol for Fibre Channel is FSPF [FC-SW-4]. Another MIB [RFC4626] specifies management information specific to FSPF. This MIB contains routing information that is independent of FSPF (i.e., it would still apply even if a routing protocol other than FSPF were in use in the network). This MIB imports some common Textual Conventions from T11-TC-MIB, defined in [RFC4439]. 5. MIB Overview This MIB module provides the means for monitoring the operation of, and configuring some parameters of, one or more instances of the FSPF protocol. (Note that there are no definitions in this MIB module of "managed actions" that can be invoked via SNMP.) 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [FC-MGMT] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent with multiple AgentX [RFC2741] sub-agents, each sub-agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [FC-MGMT] as the index value that uniquely identifies each Fibre Channel management instance within the same SNMP context ([RFC3411], Section 3.3.1). DeSanti, et al. Standards Track [Page 5] RFC 4625 FC Routing Information MIB September 2006 5.2. Switch Index The FC-MGMT-MIB [FC-MGMT] defines the fcmSwitchTable as a table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value that uniquely identifies a Fibre Channel switch among those (one or more) managed by the same Fibre Channel management instance. 5.3. Fabric Index Whether operating on a physical Fabric (i.e., without Virtual Fabrics) or within a Virtual Fabric, the operation of FSPF within a Fabric is identical. Therefore, this MIB defines all Fabric-related information in tables that are INDEX-ed by an arbitrary integer, named a "Fabric Index", the syntax of which is IMPORTed from the T11-TC-MIB. When a device is connected to a single physical Fabric, without use of any virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple virtual and/or physical Fabrics, this index provides a means to distinguish one Fabric from another. It is quite possible, and may even be likely, that a Fibre Channel switch will have ports connected to multiple virtual and/or physical Fabrics. Thus, in order to simplify a management protocol query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before t11FcRouteFabricIndex when they both appear in the same INDEX clause. 5.4. The t11FcRouteGroup Group This MIB contains one object group, the t11FcRouteGroup, which contains objects to allow the displaying and the configuring of routes in the Fibre Channel Routing tables for the locally managed switches. 5.5. The t11FcRouteTable's INDEX It is normally valuable for a MIB table that contains routes to be ordered such that a management application is able to query the table based on some attribute, without having to read every row in the MIB table. This requires that the rows in the table be ordered according to such attributes, and thus that those attributes be represented by objects included in the table's INDEX clause. Examples of this can be seen in the ipCidrRouteTable [RFC2096] and, more recently, the inetCidrRouteTable in [RFC4292]. DeSanti, et al. Standards Track [Page 6] RFC 4625 FC Routing Information MIB September 2006 While this useful feature results in an unusually large number (ten) of objects in the t11FcRouteTable's INDEX clause, all ten are either integers or strings of 3 (or zero) octet length, so the resulting OIDs are not unusually large. (Specifically, the aggregate number of sub-identifiers to be appended to an OBJECT-TYPE's OID, when naming an instance of an object in the t11FcRouteTable, is at most 22 sub- identifiers; i.e., less than the *minimum* number to be appended for the inetCidrRouteTable table.) 6. The T11-FC-ROUTE-MIB Module T11-FC-ROUTE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, TimeStamp, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndex, InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] fcmInstanceIndex, fcmSwitchIndex, FcAddressIdOrZero, FcDomainIdOrZero FROM FC-MGMT-MIB -- [FC-MGMT] T11FabricIndex FROM T11-TC-MIB; -- [RFC4439] t11FcRouteMIB MODULE-IDENTITY LAST-UPDATED "200608140000Z" ORGANIZATION "T11" CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Email: kzm@cisco.com" DESCRIPTION "The MIB module for configuring and displaying Fibre Channel Route Information. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4625; see the RFC itself for full legal notices." REVISION "200608140000Z" DeSanti, et al. Standards Track [Page 7] RFC 4625 FC Routing Information MIB September 2006 DESCRIPTION "Initial version of this MIB module, published as RFC4625." ::= {mib-2 144 } t11FcRouteNotifications OBJECT IDENTIFIER ::= { t11FcRouteMIB 0 } t11FcRouteObjects OBJECT IDENTIFIER ::= { t11FcRouteMIB 1 } t11FcRouteConformance OBJECT IDENTIFIER ::= { t11FcRouteMIB 2 } -- -- Per-Fabric routing information -- t11FcRouteFabricTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcRouteFabricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing Fibre Channel Routing information that is specific to a Fabric." ::= { t11FcRouteObjects 1 } t11FcRouteFabricEntry OBJECT-TYPE SYNTAX T11FcRouteFabricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains routing information specific to a particular Fabric on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcRouteFabricIndex } ::= { t11FcRouteFabricTable 1 } T11FcRouteFabricEntry ::= SEQUENCE { t11FcRouteFabricIndex T11FabricIndex, t11FcRouteFabricLastChange TimeStamp } t11FcRouteFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric. In a Fabric conformant to FC-SW-3, only a single Fabric DeSanti, et al. Standards Track [Page 8] RFC 4625 FC Routing Information MIB September 2006 can operate within a physical infrastructure, and thus the value of this Fabric Index will always be 1. In a Fabric conformant to FC-SW-4, multiple Virtual Fabrics can operate within one (or more) physical infrastructures. In such a case, index value is used to uniquely identify a particular Fabric within a physical infrastructure." ::= { t11FcRouteFabricEntry 1 } t11FcRouteFabricLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent time when any corresponding row in the t11FcRouteTable was created, modified, or deleted. A corresponding row in the t11FcRouteTable is for the same management instance, the same switch, and same Fabric as the row in this table. If no change has occurred since the last restart of the management system, then the value of this object is 0." ::= { t11FcRouteFabricEntry 2 } -- -- Fibre Channel Routing table -- t11FcRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Fibre Channel Routing tables for the locally managed switches. This table lists all the routes that are configured in and/or computed by any local switch for any Fabric. Such routes are used by a switch to forward frames (of user data) on a Fabric. The conceptual process is based on extracting the Destination Fibre Channel Address Identifier (D_ID) out of a received frame (of user data) and comparing it to each entry of this table that is applicable to the given switch and Fabric. Such comparison consists of first performing a logical-AND of the extracted D_ID with a mask (the value of t11FcRouteDestMask) and second comparing the result of that 'AND' operation to the value of t11FcRouteDestAddrId. A similar comparison is made of the Source Fibre Channel Address Identifier (S_ID) of a frame DeSanti, et al. Standards Track [Page 9] RFC 4625 FC Routing Information MIB September 2006 against the t11FcRouteSrcAddrId and t11FcRouteSrcMask values of an entry. If an entry's value of t11FcRouteInInterface is non-zero, then a further comparison determines if the frame was received on the appropriate interface. If all of these comparisons for a particular entry are successful, then that entry represents a potential route for forwarding the received frame. For entries configured by a user, t11FcRouteProto has the value 'netmgmt'; only entries of this type can be deleted by the user." ::= { t11FcRouteObjects 2 } t11FcRouteEntry OBJECT-TYPE SYNTAX T11FcRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains a route to a particular destination, possibly from a particular subset of source addresses, on a particular Fabric via a particular output interface and learned in a particular manner." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcRouteFabricIndex, t11FcRouteDestAddrId, t11FcRouteDestMask, t11FcRouteSrcAddrId, t11FcRouteSrcMask, t11FcRouteInInterface, t11FcRouteProto, t11FcRouteOutInterface } ::= { t11FcRouteTable 1 } T11FcRouteEntry ::= SEQUENCE { t11FcRouteDestAddrId FcAddressIdOrZero, t11FcRouteDestMask FcAddressIdOrZero, t11FcRouteSrcAddrId FcAddressIdOrZero, t11FcRouteSrcMask FcAddressIdOrZero, t11FcRouteInInterface InterfaceIndexOrZero, t11FcRouteProto INTEGER, t11FcRouteOutInterface InterfaceIndex, t11FcRouteDomainId FcDomainIdOrZero, t11FcRouteMetric Unsigned32, t11FcRouteType INTEGER, t11FcRouteIfDown INTEGER, t11FcRouteStorageType StorageType, t11FcRouteRowStatus RowStatus } t11FcRouteDestAddrId OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) DeSanti, et al. Standards Track [Page 10] RFC 4625 FC Routing Information MIB September 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The destination Fibre Channel Address Identifier of this route. A zero-length string for this field is not allowed." ::= { t11FcRouteEntry 1 } t11FcRouteDestMask OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mask to be logical-ANDed with a destination Fibre Channel Address Identifier before it is compared to the value in the t11FcRouteDestAddrId field. Allowed values are 255.255.255, 255.255.0, or 255.0.0. FSPF's definition generates routes to a Domain_ID, so the mask for all FSPF-generated routes is 255.0.0. The zero-length value has the same meaning as 0.0.0." ::= { t11FcRouteEntry 2 } t11FcRouteSrcAddrId OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The source Fibre Channel Address Identifier of this route. Note that if this object and the corresponding instance of t11FcRouteSrcMask both have a value of 0.0.0, then this route matches all source addresses. The zero-length value has the same meaning as 0.0.0." ::= { t11FcRouteEntry 3 } t11FcRouteSrcMask OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mask to be logical-ANDed with a source Fibre Channel Address Identifier before it is compared to the value in the t11FcRouteSrcAddrId field. Allowed values are 255.255.255, 255.255.0, 255.0.0, or 0.0.0. The zero-length value has the same meaning as 0.0.0." ::= { t11FcRouteEntry 4 } t11FcRouteInInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero DeSanti, et al. Standards Track [Page 11] RFC 4625 FC Routing Information MIB September 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of this object is non-zero, it is the value of ifIndex that identifies the local Fibre Channel interface through which a frame must have been received in order to match with this entry. If the value of this object is zero, the matching does not require that the frame be received on any specific interface." ::= { t11FcRouteEntry 5 } t11FcRouteProto OBJECT-TYPE SYNTAX INTEGER { other(1), local(2), netmgmt(3), fspf(4) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mechanism via which this route was learned: other(1) - not specified local(2) - local interface netmgmt(3)- static route fspf(4) - Fibre Shortest Path First " ::= { t11FcRouteEntry 6 } t11FcRouteOutInterface OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex that identifies the local Fibre Channel interface through which the next hop of this route is to be reached." ::= { t11FcRouteEntry 7 } t11FcRouteDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The domain_ID of next hop switch. This object can have a value of zero if the value DeSanti, et al. Standards Track [Page 12] RFC 4625 FC Routing Information MIB September 2006 of t11FcRouteProto is 'local'." ::= { t11FcRouteEntry 8 } t11FcRouteMetric OBJECT-TYPE SYNTAX Unsigned32 (0..65536) MAX-ACCESS read-create STATUS current DESCRIPTION "The routing metric for this route. The use of this object is dependent on t11FcRouteProto." ::= { t11FcRouteEntry 9 } t11FcRouteType OBJECT-TYPE SYNTAX INTEGER { local(1), remote(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of route. local(1) - a route for which the next Fibre Channel port is the final destination; remote(2) - a route for which the next Fibre Channel port is not the final destination." DEFVAL {local} ::= { t11FcRouteEntry 10 } t11FcRouteIfDown OBJECT-TYPE SYNTAX INTEGER { remove(1), retain(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates what happens to this route when the output interface (given by the corresponding value of t11FcRouteOutInterface) is operationally 'down'. If this object's value is 'retain', the route is to be retained in this table. If this object's value is 'remove', the route is to be removed from this table." DEFVAL { retain } ::= { t11FcRouteEntry 11 } DeSanti, et al. Standards Track [Page 13] RFC 4625 FC Routing Information MIB September 2006 t11FcRouteStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11FcRouteEntry 12 } t11FcRouteRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The only rows that can be deleted by setting this object to 'destroy' are those for which t11FcRouteProto has the value 'netmgmt'." ::= { t11FcRouteEntry 13 } -- -- Conformance -- t11FcRouteCompliances OBJECT IDENTIFIER ::= { t11FcRouteConformance 1 } t11FcRouteGroups OBJECT IDENTIFIER ::= { t11FcRouteConformance 2 } t11FcRouteCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the T11-FC-ROUTE-MIB. -- -- Note: The next four OBJECT clauses are for auxiliary objects, and the -- SMIv2 does not permit inclusion of objects that are not accessible -- in an OBJECT clause (see Sections 3.1 & 5.4.3 in STD 58, RFC 2580). -- Thus, these four clauses cannot be included below in the normal -- location for OBJECT clauses. -- -- OBJECT t11FcRouteSrcAddrId -- SYNTAX FcAddressIdOrZero (SIZE (0)) -- DESCRIPTION -- 'Support is not required for routes that -- match only a subset of possible source DeSanti, et al. Standards Track [Page 14] RFC 4625 FC Routing Information MIB September 2006 -- addresses.' -- -- OBJECT t11FcRouteSrcMask -- SYNTAX FcAddressIdOrZero (SIZE (0)) -- DESCRIPTION -- 'Support is not required for routes that -- match only a subset of possible source -- addresses.' -- -- OBJECT t11FcRouteDestMask -- DESCRIPTION -- 'Support is mandatory only for FSPF-generated -- routes. Since FSPF's definition generates -- routes to a Domain_ID, the mask for all -- FSPF-generated routes is 255.0.0. Thus, -- support is only required for 255.0.0.' -- -- OBJECT t11FcRouteInInterface -- SYNTAX InterfaceIndexOrZero (0) -- DESCRIPTION -- 'Support for routes specific to particular -- source interfaces is not required.' " MODULE -- this module MANDATORY-GROUPS { t11FcRouteGroup } OBJECT t11FcRouteIfDown MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcRouteDomainId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcRouteMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcRouteType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcRouteStorageType DeSanti, et al. Standards Track [Page 15] RFC 4625 FC Routing Information MIB September 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcRouteRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FcRouteCompliances 1 } t11FcRouteGroup OBJECT-GROUP OBJECTS { t11FcRouteFabricLastChange, t11FcRouteDomainId, t11FcRouteMetric, t11FcRouteType, t11FcRouteIfDown, t11FcRouteStorageType, t11FcRouteRowStatus } STATUS current DESCRIPTION "A collection of objects for displaying and configuring routes." ::= { t11FcRouteGroups 1 } END DeSanti, et al. Standards Track [Page 16] RFC 4625 FC Routing Information MIB September 2006 7. Acknowledgements This document was originally developed and approved by the INCITS Task Group T11.5 (http://www.t11.org) as the SM-RTM project. We wish to acknowledge the contributions and comments from the INCITS Technical Committee T11, including the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 members, especially: Ken Hirata, Emulex Scott Kipp, McData Elizabeth G. Rodriguez, Dot Hill The document was subsequently approved by the IETF's IMSS Working Group, chaired by David Black (EMC Corporation). We also wish to acknowledge Bert Wijnen (Lucent Technologies), the IETF Area Director, for his review of the document. 8. IANA Considerations The IANA has assigned a MIB OID for the T11-FC-ROUTE-MIB module under the appropriate subtree. 9. Security Considerations There are several management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability are: t11FcRouteDomainId, t11FcRouteMetric, t11FcRouteType, t11FcRouteIfDown, t11FcRouteRowStatus -- configure new routes and/or modify existing routes. Such objects may be considered sensitive or vulnerable in some network environments. For example, the ability to change network topology or network speed may afford an attacker the ability to obtain better performance at the expense of other network users. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. DeSanti, et al. Standards Track [Page 17] RFC 4625 FC Routing Information MIB September 2006 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The objects and their sensitivity/vulnerability are: the write-able objects listed above plus one other: t11FcRouteLastChangeTime -- the time of the last routing table change. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. DeSanti, et al. Standards Track [Page 18] RFC 4625 FC Routing Information MIB September 2006 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, March 2006. [RFC4626] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol", RFC 4626, September 2006. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)", ANSI INCITS 373-2003, April 2003. [FC-SW-3] "Fibre Channel - Switch Fabric - 3 (FC-SW-3)", ANSI INCITS 384-2004, 2004. [FC-SW-4] "Fibre Channel - Switch Fabric - 4 (FC-SW-4)", ANSI INCITS 418-2006, 2006. [FC-MGMT] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. DeSanti, et al. Standards Track [Page 19] RFC 4625 FC Routing Information MIB September 2006 11. Informative References [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006. DeSanti, et al. Standards Track [Page 20] RFC 4625 FC Routing Information MIB September 2006 Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Srini Kode Consultant Phone: 408-348-5343 EMail: srinikode@yahoo.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com Silvano Gai Retired DeSanti, et al. Standards Track [Page 21] RFC 4625 FC Routing Information MIB September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). DeSanti, et al. Standards Track [Page 22] snmp-mibs-downloader-1.1/mibrfcs/rfc4626.txt0000644000000000000000000020456111402176072015574 0ustar Network Working Group C. DeSanti Request for Comments: 4626 V. Gaonkar Category: Standards Track K. McCloghrie Cisco Systems S. Gai Retired September 2006 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. DeSanti, et al. Standards Track [Page 1] RFC 4626 Fibre Channel FSPF MIB September 2006 Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Short Overview of Fibre Channel .................................3 3.1. Introduction ...............................................3 3.2. FSPF Protocol ..............................................4 3.3. Virtual Fabrics ............................................4 4. Relationship to Other MIBs ......................................5 5. MIB Overview ....................................................5 5.1. Fibre Channel Management Instance ..........................5 5.2. Switch Index ...............................................6 5.3. Fabric Index ...............................................6 5.4. The MIB Groups .............................................6 5.4.1. The t11FspfGeneralGroup Group .......................6 5.4.2. The t11FspfIfGroup Group ............................7 5.4.3. The t11FspfDatabaseGroup Group ......................7 5.4.4. The t11FspfNotificationGroup Group ..................7 6. The T11-FC-FSPF-MIB Module ......................................7 7. Acknowledgements ...............................................31 8. IANA Considerations ............................................32 9. Security Considerations ........................................32 10. Normative References ..........................................33 11. Informative References ........................................34 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol, which is specified in [FC-SW-4]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. DeSanti, et al. Standards Track [Page 2] RFC 4626 Fibre Channel FSPF MIB September 2006 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of Fibre Channel 3.1. Introduction The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols, such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the fabric, each node, and most ports, have globally-unique names. These globally-unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, a Domain_ID being the highest level of the hierarchy. DeSanti, et al. Standards Track [Page 3] RFC 4626 Fibre Channel FSPF MIB September 2006 The routing of frames within the Fabric is normally based on a routing protocol called Fabric Shortest Path First (FSPF). FSPF is a link state path selection protocol, which is defined in Section 8 of [FC-SW-4]. FSPF keeps track of the state of the links on all switches in the Fabric and associates a cost with each link. The protocol computes paths from a switch to all the other switches in the Fabric by adding the cost of all the links traversed by the path, and choosing the path that minimizes the cost. The collection of link states (including cost) of all the switches in a Fabric constitutes the topology database (or link-state database). 3.2. FSPF Protocol FSPF has four major components: a) A Hello protocol, used to establish connectivity with a neighbor switch, to establish the identity of the neighbor switch, and to exchange FSPF parameters and capabilities; b) A replicated topology database, with protocols and mechanisms to keep the databases synchronized across the Fabric; c) A path computation algorithm (e.g., Dijkstra's algorithm); d) A routing table update. The topology database synchronization in turn consists of two major components: an initial database synchronization and an update mechanism. The initial database synchronization is used when a switch is initialized, or when an Inter-Switch Link (ISL) comes up. The update mechanism is used in two circumstances: a) When there is a link state change; for example, an ISL going down or coming up; b) On a periodic basis, to prevent switches from deleting topology information from the database. Also note that all connections between Fibre Channel switches are point-to-point. 3.3. Virtual Fabrics The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4]. [FC-SW-4] carries forward the previous version's specification for the operation of a single Fabric in a physical infrastructure, augmenting it with the definition of Virtual Fabrics and with the specification of how multiple Virtual DeSanti, et al. Standards Track [Page 4] RFC 4626 Fibre Channel FSPF MIB September 2006 Fabrics can operate within one (or more) physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core switch. 4. Relationship to Other MIBs The first standardized MIB module for Fibre Channel [RFC4044] was focussed on Fibre Channel switches. It is being replaced by the more generic Fibre Channel Management MIB [FC-MGMT] which defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB [RFC2863] for Fibre Channel interfaces. This MIB module extends beyond [FC-MGMT] to cover the operation of the FSPF routing protocol in Fibre Channel switches. This MIB module only contains information specific to FSPF. Information that would still be applicable if any other routing protocol were used is specified in a separate MIB module. This MIB module imports some common Textual Conventions from T11-TC- MIB, defined in [RFC4439]. 5. MIB Overview This MIB module provides the means for monitoring the operation of, and configuring some parameters of, one or more instances of the FSPF protocol. 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [FC-MGMT] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent with multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. DeSanti, et al. Standards Track [Page 5] RFC 4626 Fibre Channel FSPF MIB September 2006 The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [FC-MGMT] as the index value that uniquely identifies each Fibre Channel management instance within the same SNMP context ([RFC3411], Section 3.3.1). 5.2. Switch Index The FC-MGMT-MIB [FC-MGMT] defines the fcmSwitchTable as a table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value that uniquely identifies a Fibre Channel switch among those (one or more) managed by the same Fibre Channel management instance. 5.3. Fabric Index Whether operating on a physical Fabric (i.e., without Virtual Fabrics) or within a Virtual Fabric, the operation of FSPF within a Fabric is identical. Therefore, this MIB module defines all Fabric- related information in tables that are INDEX-ed by an arbitrary integer, named a "Fabric Index", the syntax of which is IMPORTed from the T11-TC-MIB. When a device is connected to a single physical Fabric, without use of any virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple virtual and/or physical Fabrics, this index provides a means to distinguish one Fabric from another. It is quite possible, and may even be likely, that a Fibre Channel switch will have ports connected to multiple virtual and/or physical Fabrics. Thus, in order to simplify a management protocol query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before t11FspfFabricIndex when they both appear in the same INDEX clause. 5.4. The MIB Groups This section describes the four MIB groups contained in the MIB module. 5.4.1. The t11FspfGeneralGroup Group This group provides for per-Fabric monitoring of the FSPF state and per-Fabric monitoring/configuration of FSPF parameters. DeSanti, et al. Standards Track [Page 6] RFC 4626 Fibre Channel FSPF MIB September 2006 5.4.2. The t11FspfIfGroup Group This group provides for per-interface monitoring of FSPF state/statistics and per-interface monitoring/configuration of FSPF parameters. 5.4.3. The t11FspfDatabaseGroup Group This group permits the monitoring of the information present in the FSPF topology database. 5.4.4. The t11FspfNotificationGroup Group This group contains the notifications that are generated on asynchronous events related to the operation of FSPF. 6. The T11-FC-FSPF-MIB Module T11-FC-FSPF-MIB DEFINITIONS ::= BEGIN -- -- For management of FSPF, the Fibre Channel routing protocol. -- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, Unsigned32, TimeTicks, Gauge32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TEXTUAL-CONVENTION, RowStatus, StorageType, TruthValue FROM SNMPv2-TC -- [RFC2579] ifIndex, InterfaceIndex FROM IF-MIB -- [RFC2863] fcmInstanceIndex, fcmSwitchIndex, FcDomainIdOrZero FROM FC-MGMT-MIB -- [FC-MGMT] T11FabricIndex FROM T11-TC-MIB -- [RFC4439] t11FamConfigDomainId FROM T11-FC-FABRIC-ADDR-MGR-MIB; -- [RFC4439] t11FcFspfMIB MODULE-IDENTITY LAST-UPDATED "200608140000Z" ORGANIZATION "T11" CONTACT-INFO "Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com DeSanti, et al. Standards Track [Page 7] RFC 4626 Fibre Channel FSPF MIB September 2006 Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Email: kzm@cisco.com" DESCRIPTION "The MIB module for managing the Fabric Shortest Path First (FSPF) protocol. FSPF is specified in FC-SW-4. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4626; see the RFC itself for full legal notices." REVISION "200608140000Z" DESCRIPTION "Initial version of this MIB module published as RFC4626." ::= { mib-2 143 } t11FspfNotifications OBJECT IDENTIFIER ::= { t11FcFspfMIB 0 } t11FspfObjects OBJECT IDENTIFIER ::= { t11FcFspfMIB 1 } t11FspfConformance OBJECT IDENTIFIER ::= { t11FcFspfMIB 2 } t11FspfConfiguration OBJECT IDENTIFIER ::= { t11FspfObjects 1 } t11FspfDatabase OBJECT IDENTIFIER ::= { t11FspfObjects 2 } -- -- TEXTUAL CONVENTIONS T11FspfLsrType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Type of the Link State Record. FC-SW-4 defines two types of LSRs and allows for the possibility for more will be defined in the future: 01 - Switch Link Record 02 - Obsolete 240 - 255 - Vendor Specific others - Reserved. " REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 6.1.9.3." SYNTAX Integer32 (0..255) T11FspfLinkType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 8] RFC 4626 Fibre Channel FSPF MIB September 2006 "Type of an the FSPF Link. Presently defined values: 1 - Point-to-Point 240-255 - Vendor Specific all others - Reserved. " REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 6.1.9.4." SYNTAX Integer32 (0..255) T11FspfInterfaceState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The state of the FSPF Neighbor Finite State Machine for the neighbor (switch) on a particular interface. Possible values are : down(1) - Down init(2) - Init dbExchange(3) - Database Exchange dbAckwait(4) - Database AckWait dbWait(5) - Database Wait full(6) - Full (Connected) " REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 8.7." SYNTAX INTEGER { down(1), init(2), dbExchange(3), dbAckwait(4), dbWait(5), full(6) } T11FspfLastCreationTime ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes an object that stores the last time it, and the row containing it, was created. This can be used by management applications to determine that a row has been deleted and re-created between reads, causing an otherwise undetectable discontinuity in the data." SYNTAX TimeTicks DeSanti, et al. Standards Track [Page 9] RFC 4626 Fibre Channel FSPF MIB September 2006 -- -- t11FspfTable t11FspfTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FspfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table allows the users to configure and monitor FSPF's per-Fabric parameters and statistics on all Fabrics known to locally managed switches. Entries are created/removed by the agent if and when (Virtual) Fabrics are created/deleted." ::= { t11FspfConfiguration 1 } t11FspfEntry OBJECT-TYPE SYNTAX T11FspfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing FSPF variables, parameters, and statistics on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex) for a particular Fabric (identified by a t11FspfFabricIndex value). (Note that the local switch's per-fabric Domain-ID is available in t11FamConfigDomainId, which is defined in T11-FC-FABRIC-ADDR-MGR-MIB.)" INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FspfFabricIndex } ::= { t11FspfTable 1 } T11FspfEntry ::= SEQUENCE { t11FspfFabricIndex T11FabricIndex, t11FspfMinLsArrival Unsigned32, t11FspfMinLsInterval Unsigned32, t11FspfLsRefreshTime Unsigned32, t11FspfMaxAge Unsigned32, t11FspfMaxAgeDiscards Counter32, t11FspfPathComputations Counter32, t11FspfChecksumErrors Counter32, t11FspfLsrs Gauge32, t11FspfCreateTime T11FspfLastCreationTime, t11FspfAdminStatus INTEGER, t11FspfOperStatus INTEGER, t11FspfNbrStateChangNotifyEnable TruthValue, t11FspfSetToDefault INTEGER, t11FspfStorageType StorageType DeSanti, et al. Standards Track [Page 10] RFC 4626 Fibre Channel FSPF MIB September 2006 } t11FspfFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric. In a Fabric conformant to FC-SW-4, multiple Virtual Fabrics can operate within one (or more) physical infrastructures. In such a case, index value is used to uniquely identify a particular Fabric within a physical infrastructure. In a Fabric that has (can have) only a single Fabric operating within the physical infrastructure, the value of this Fabric Index will always be 1." ::= { t11FspfEntry 1 } t11FspfMinLsArrival OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliSeconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum time after accepting a Link State Record (LSR) on this Fabric before accepting another update of the same LSR on the same Fabric. An LSR update that is not accepted because of this time interval is discarded." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, sections 8.6.4.5 & 15.1." DEFVAL {1000} ::= { t11FspfEntry 2 } t11FspfMinLsInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliSeconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum time after this switch sends an LSR on this Fabric before it will send another update of the same LSR on the same Fabric." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 15.1." DeSanti, et al. Standards Track [Page 11] RFC 4626 Fibre Channel FSPF MIB September 2006 DEFVAL {5000} ::= { t11FspfEntry 3 } t11FspfLsRefreshTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "Minutes" MAX-ACCESS read-only STATUS current DESCRIPTION "The interval between transmission of refresh LSRs on this Fabric." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, sections 8.5.1 & 15.1." DEFVAL {30} ::= { t11FspfEntry 4 } t11FspfMaxAge OBJECT-TYPE SYNTAX Unsigned32 UNITS "Minutes" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum age an LSR will be retained in the FSPF database on this Fabric. An LSR is removed from the database after MaxAge is reached." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 15.1." DEFVAL {60} ::= { t11FspfEntry 5 } t11FspfMaxAgeDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LSRs discarded due to their age reaching t11FspfMaxAge in this Fabric. The last discontinuity of this counter is indicated by t11FspfCreateTime." ::= { t11FspfEntry 6 } t11FspfPathComputations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the path computation algorithm has been invoked by this Switch on this Fabric to compute a set of minimum cost paths for this Fabric. The last DeSanti, et al. Standards Track [Page 12] RFC 4626 Fibre Channel FSPF MIB September 2006 discontinuity of this counter is indicated by t11FspfCreateTime." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 8.1.1." ::= { t11FspfEntry 7 } t11FspfChecksumErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FSPF checksum errors that were detected locally (and therefore discarded) on this Fabric. The last discontinuity of this counter is indicated by t11FspfCreateTime." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 8.5.4." ::= { t11FspfEntry 8 } t11FspfLsrs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries for this Fabric in the t11FspfLsrTable." ::= { t11FspfEntry 9 } t11FspfCreateTime OBJECT-TYPE SYNTAX T11FspfLastCreationTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last created." ::= { t11FspfEntry 10 } t11FspfAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired state of FSPF in this Fabric. If value of this object is set to 'up', then FSPF is enabled in this Fabric. If set to 'down', then FSPF is disabled in this Fabric -- when FSPF is disabled, FSPF provides DeSanti, et al. Standards Track [Page 13] RFC 4626 Fibre Channel FSPF MIB September 2006 no routes to be included in the T11-FC-ROUTE-MIB module. (see the T11-FC-ROUTE-MIB)." REFERENCE "T11-FC-ROUTE-MIB, The Fibre Channel Routing Information MIB, RFC4625." DEFVAL {up} ::= { t11FspfEntry 11 } t11FspfOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "State of FSPF in this Fabric. If 't11FspfAdminStatus' is 'down', then the 't11FspfOperStatus' should be 'down'. If 't11FspfAdminStatus' is changed to 'up', then 't11FspfOperStatus' should change to 'up' as and when FSPF is active in this Fabric." ::= { t11FspfEntry 12 } t11FspfNbrStateChangNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies whether or not the local agent should issue the notification 't11FspfNbrStateChangNotify' when the local switch learns of a change of state in the FSPF Neighbor Finite State Machine on an interface in this Fabric. If the value of the object is 'true, then the notification is generated. If the value is 'false', notification is not generated." DEFVAL { false } ::= { t11FspfEntry 13 } t11FspfSetToDefault OBJECT-TYPE SYNTAX INTEGER { default(1), noOp(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this value to 'default' changes the value of each and every writable object in this row to its default DeSanti, et al. Standards Track [Page 14] RFC 4626 Fibre Channel FSPF MIB September 2006 value. No action is taken if this object is set to 'noOp'. The value of the object, when read, is always 'noOp'." ::= { t11FspfEntry 14 } t11FspfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "The storage type for read-write objects in this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11FspfEntry 15 } -- -- t11FspfIfTable t11FspfIfTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FspfIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table allows the users to configure and monitor the FSPF parameters that are per-interface (identified by a t11FspfIfIndex value), per-Fabric (identified by a t11FspfFabricIndex value), and per-switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). Creating a row in this table via t11FspfIfRowStatus provides the means to specify non-default parameter value(s) for an interface at a time when the relevant row in this table would not otherwise exist because the interface is either down or it is not an E_Port, but the corresponding row in the t11FspfTable must already exist. After the non-default values have been specified for a port's parameters, they need to be retained in this table, even when the port becomes 'isolated'. However, having unnecessary rows in this table clutters it up and makes those rows that are useful harder for an NMS to find. Therefore, when an E_Port becomes isolated, its row gets deleted if and only if all of its parameter values are the default values; also, when an E_Port becomes non-isolated DeSanti, et al. Standards Track [Page 15] RFC 4626 Fibre Channel FSPF MIB September 2006 in a particular Fabric, a row in this table needs to exist and is automatically created, if necessary. The specific conditions for an automated/implicit deletion of a row are: a) if the corresponding interface is no longer an E_Port (e.g., a G_Port which is dynamically determined to be an F_Port), and all configurable parameters have default values; or b) if the interface identified by t11FspfIfIndex no longer exists (e.g., because a line-card is physically removed); or c) if the corresponding row in the t11FspfTable is deleted. " ::= { t11FspfConfiguration 2 } t11FspfIfEntry OBJECT-TYPE SYNTAX T11FspfIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing FSPF information for the interface identified by t11FspfIfIndex, on the fabric identified by t11FspfFabricIndex, on the switch identified by fcmSwitchIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FspfFabricIndex, t11FspfIfIndex } ::= { t11FspfIfTable 1 } T11FspfIfEntry ::= SEQUENCE { t11FspfIfIndex InterfaceIndex, t11FspfIfHelloInterval Unsigned32, t11FspfIfDeadInterval Unsigned32, t11FspfIfRetransmitInterval Unsigned32, t11FspfIfInLsuPkts Counter32, t11FspfIfInLsaPkts Counter32, t11FspfIfOutLsuPkts Counter32, t11FspfIfOutLsaPkts Counter32, t11FspfIfOutHelloPkts Counter32, t11FspfIfInHelloPkts Counter32, t11FspfIfRetransmittedLsuPkts Counter32, t11FspfIfInErrorPkts Counter32, t11FspfIfNbrState T11FspfInterfaceState, t11FspfIfNbrDomainId FcDomainIdOrZero, t11FspfIfNbrPortIndex Unsigned32, t11FspfIfAdminStatus INTEGER, t11FspfIfCreateTime T11FspfLastCreationTime, t11FspfIfSetToDefault INTEGER, DeSanti, et al. Standards Track [Page 16] RFC 4626 Fibre Channel FSPF MIB September 2006 t11FspfIfLinkCostFactor Unsigned32, t11FspfIfStorageType StorageType, t11FspfIfRowStatus RowStatus } t11FspfIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex that identifies the local Fibre Channel interface for which this entry contains FSPF information." ::= { t11FspfIfEntry 1 } t11FspfIfHelloInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Interval between the periodic HELLO messages sent on this interface in this Fabric to verify the link health. Note that this value must be same at both ends of a link in this Fabric." DEFVAL {20} ::= { t11FspfIfEntry 2 } t11FspfIfDeadInterval OBJECT-TYPE SYNTAX Unsigned32 (2..65535) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum time for which no HELLO messages can be received on this interface in this Fabric. After this time, the interface is assumed to be broken and removed from the database. Note that this value must be greater than the HELLO interval specified on this interface in this Fabric." DEFVAL {80} ::= { t11FspfIfEntry 3 } t11FspfIfRetransmitInterval OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 17] RFC 4626 Fibre Channel FSPF MIB September 2006 "The time after which an unacknowledged LSR is retransmitted on this interface in this Fabric." DEFVAL {5} ::= { t11FspfIfEntry 4 } t11FspfIfInLsuPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Link State Update (LSU) packets received on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 5 } t11FspfIfInLsaPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Link State Acknowledgement (LSA) packets received on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 6 } t11FspfIfOutLsuPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Link State Update (LSU) packets transmitted on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 7 } t11FspfIfOutLsaPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Link State Acknowledgement (LSA) packets transmitted on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 8 } DeSanti, et al. Standards Track [Page 18] RFC 4626 Fibre Channel FSPF MIB September 2006 t11FspfIfOutHelloPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of HELLO packets transmitted on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 9 } t11FspfIfInHelloPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of HELLO packets received on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 10 } t11FspfIfRetransmittedLsuPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LSU packets that contained one or more retransmitted LSRs, and that were transmitted on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 11 } t11FspfIfInErrorPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of invalid FSPF control packets received on this interface in this Fabric. The last discontinuity of this counter is indicated by t11FspfIfCreateTime." ::= { t11FspfIfEntry 12 } t11FspfIfNbrState OBJECT-TYPE SYNTAX T11FspfInterfaceState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of FSPF's 'neighbor state machine', which is the operational state of the interaction with the DeSanti, et al. Standards Track [Page 19] RFC 4626 Fibre Channel FSPF MIB September 2006 neighbor's interface that is connected to this interface. If the 't11FspfIfAdminStatus' is 'down', then this object should be 'down'. If the 't11FspfIfAdminStatus' is 'up', then this object's value depends on the state of FSPF's 'neighbor state machine' on this interface in this Fabric." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 8.7" ::= { t11FspfIfEntry 13 } t11FspfIfNbrDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Domain Id of the neighbor in this Fabric." ::= { t11FspfIfEntry 14 } t11FspfIfNbrPortIndex OBJECT-TYPE SYNTAX Unsigned32 (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The index, as known by the neighbor, of the neighbor's interface that is connected to this interface in this Fabric." REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 6.1.9.4." ::= { t11FspfIfEntry 15 } t11FspfIfAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of FSPF on this interface in this Fabric, whenever 't11FspfAdminStatus' is 'up'. If the value of this object is set to 'up', then FSPF is enabled on this interface in this Fabric. If set to 'down', then FSPF is disabled on this interface in this Fabric. Note that the operational state of FSPF on an interface is given by t11FspfIfNbrState." DEFVAL {up} ::= { t11FspfIfEntry 16 } DeSanti, et al. Standards Track [Page 20] RFC 4626 Fibre Channel FSPF MIB September 2006 t11FspfIfCreateTime OBJECT-TYPE SYNTAX T11FspfLastCreationTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was last created." ::= { t11FspfIfEntry 17 } t11FspfIfSetToDefault OBJECT-TYPE SYNTAX INTEGER { default(1), noOp(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Setting this value to 'default' changes the value of each and every writable object in this row to its default value. If all the configuration parameters have their default values, and if the interface is down, then the row is deleted automatically. No action is taken if this object is set to 'noOp'. The value of the object, when read, is always 'noOp'." ::= { t11FspfIfEntry 18 } t11FspfIfLinkCostFactor OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative factor used in calculating the cost of sending a frame on this interface in this Fabric. The formula used to calculate the link cost is: Link Cost = S * (1.0625e12 / ifSpeed) where: S = (the value of this object / 100) ifSpeed = interface speed (as defined in the IF-MIB). " REFERENCE "Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 8.5.5; and IF-MIB, RFC 2863." DeSanti, et al. Standards Track [Page 21] RFC 4626 Fibre Channel FSPF MIB September 2006 DEFVAL { 100 } ::= { t11FspfIfEntry 19 } t11FspfIfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11FspfIfEntry 20 } t11FspfIfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the conceptual row. This object can be used to create an entry only if there is an entry in the t11FspfTable for the corresponding Fabric, and if the interface is either isolated or is a non-E_port. Setting this object to 'destroy' will typically fail; to reverse the creation process, set the corresponding instance of t11FspfIfSetToDefault to 'default'." ::= { t11FspfIfEntry 21 } -- -- t11FspfLsrTable t11FspfLsrTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FspfLsrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is the database of all the latest incarnations of the Link State Records (LSRs) that are currently contained in the topology database, for all interfaces on all Fabrics known to locally managed switches. A Fabric's topology database contains the LSRs that have been either issued or received by a local switch on that Fabric, and that have not reached t11FspfMaxAge." DeSanti, et al. Standards Track [Page 22] RFC 4626 Fibre Channel FSPF MIB September 2006 ::= { t11FspfDatabase 1 } t11FspfLsrEntry OBJECT-TYPE SYNTAX T11FspfLsrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This gives information for the most recent update of an LSR. There is one entry for every LSR issued or received by a locally managed switch (identified by fcmInstanceIndex and fcmSwitchIndex) in a Fabric (identified by t11FspfFabricIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FspfFabricIndex, t11FspfLsrDomainId, t11FspfLsrType } ::= { t11FspfLsrTable 1 } T11FspfLsrEntry ::= SEQUENCE { t11FspfLsrDomainId FcDomainIdOrZero, t11FspfLsrType T11FspfLsrType, t11FspfLsrAdvDomainId FcDomainIdOrZero, t11FspfLsrAge Unsigned32, t11FspfLsrIncarnationNumber Unsigned32, t11FspfLsrCheckSum Unsigned32, t11FspfLsrLinks Unsigned32 } t11FspfLsrDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "Domain Id of the LSR owner in this Fabric. It is the Link State Id of this LSR." ::= { t11FspfLsrEntry 1 } t11FspfLsrType OBJECT-TYPE SYNTAX T11FspfLsrType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Type of this LSR." ::= { t11FspfLsrEntry 2 } t11FspfLsrAdvDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 23] RFC 4626 Fibre Channel FSPF MIB September 2006 "Domain Id of the switch that is advertising the LSR on the behalf of the switch owning it." ::= { t11FspfLsrEntry 3 } t11FspfLsrAge OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "Seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this LSR was inserted into the database." ::= { t11FspfLsrEntry 4 } t11FspfLsrIncarnationNumber OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The link state incarnation number of this LSR. This is used to identify most recent instance of an LSR while updating the topology database when an LSR is received. The updating of an LSR includes incrementing its incarnation number prior to transmission of the updated LSR. So, the most recent LSR is the one with the largest incarnation number." ::= { t11FspfLsrEntry 5 } t11FspfLsrCheckSum OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The checksum of the LSR." ::= { t11FspfLsrEntry 6 } t11FspfLsrLinks OBJECT-TYPE SYNTAX Unsigned32 (0..65355) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of entries in the t11FspfLinkTable associated with this LSR." ::= { t11FspfLsrEntry 7 } -- -- t11FspfLinkTable t11FspfLinkNumber OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) DeSanti, et al. Standards Track [Page 24] RFC 4626 Fibre Channel FSPF MIB September 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of rows in the t11FspfLinkTable." ::= { t11FspfDatabase 3 } t11FspfLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FspfLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the list of Inter-Switch Links and their information that is part of an LSR, either received or transmitted." ::= { t11FspfDatabase 4 } t11FspfLinkEntry OBJECT-TYPE SYNTAX T11FspfLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry that contains information about a link contained in an LSR in this Fabric. An entry is created whenever a new link appears in an (issued or received) LSR. An entry is deleted when a link no longer appears in an (issued or received) LSR." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FspfFabricIndex, t11FspfLsrDomainId, t11FspfLsrType, t11FspfLinkIndex} ::= { t11FspfLinkTable 1 } T11FspfLinkEntry ::= SEQUENCE { t11FspfLinkIndex Unsigned32, t11FspfLinkNbrDomainId FcDomainIdOrZero, t11FspfLinkPortIndex Unsigned32, t11FspfLinkNbrPortIndex Unsigned32, t11FspfLinkType T11FspfLinkType, t11FspfLinkCost Integer32 } t11FspfLinkIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary index of this link." ::= { t11FspfLinkEntry 1 } t11FspfLinkNbrDomainId OBJECT-TYPE DeSanti, et al. Standards Track [Page 25] RFC 4626 Fibre Channel FSPF MIB September 2006 SYNTAX FcDomainIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Domain Id of the neighbor on the other end of this link in this Fabric." ::= { t11FspfLinkEntry 2 } t11FspfLinkPortIndex OBJECT-TYPE SYNTAX Unsigned32 (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The source E_port of this link, as indicated by the index value in the LSR received from the switch identified by 't11FspfLsrDomainId'." ::= { t11FspfLinkEntry 3 } t11FspfLinkNbrPortIndex OBJECT-TYPE SYNTAX Unsigned32 (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The destination E_port of this link, as indicated by the index value in the LSR received from the switch identified by 't11FspfLinkNbrDomainId'." ::= { t11FspfLinkEntry 4 } t11FspfLinkType OBJECT-TYPE SYNTAX T11FspfLinkType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this link." ::= { t11FspfLinkEntry 5 } t11FspfLinkCost OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The cost of sending a frame on this link in this Fabric. Link cost is calculated using the formula: link cost = S * (1.0625e12 / Signalling Rate) For issued LSRs, S is determined by the value of t11FspfIfLinkCostFactor for the corresponding interface DeSanti, et al. Standards Track [Page 26] RFC 4626 Fibre Channel FSPF MIB September 2006 and Fabric." ::= { t11FspfLinkEntry 6 } -- -- Notification-related object t11FspfIfPrevNbrState OBJECT-TYPE SYNTAX T11FspfInterfaceState MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The previous state of FSPF's Neighbor Finite State Machine on an interface. This object is only used in the 't11FspfNbrStateChangNotify' notification." ::= { t11FspfConfiguration 3 } -- -- Notifications t11FspfNbrStateChangNotify NOTIFICATION-TYPE OBJECTS { ifIndex, t11FamConfigDomainId, t11FspfIfNbrDomainId, t11FspfIfNbrState, t11FspfIfPrevNbrState } STATUS current DESCRIPTION "This notification signifies that there has been a change in the state of an FSPF neighbor. This is generated when the FSPF state changes to a terminal state, through either regression (i.e., goes from Full to Init or Down) or progression (i.e., from any state to Full). The value of 't11FspfIfNbrState' is the state of the neighbor after the change." ::= { t11FspfNotifications 1 } -- -- Conformance t11FspfMIBCompliances OBJECT IDENTIFIER ::= { t11FspfConformance 1 } t11FspfMIBGroups OBJECT IDENTIFIER ::= { t11FspfConformance 2 } DeSanti, et al. Standards Track [Page 27] RFC 4626 Fibre Channel FSPF MIB September 2006 t11FspfMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the FSPF." MODULE -- this module MANDATORY-GROUPS { t11FspfGeneralGroup, t11FspfIfGroup, t11FspfDatabaseGroup, t11FspfNotificationGroup } GROUP t11FspfIfCounterGroup DESCRIPTION "These counters, for particular FSPF-packet occurrences on an interface, are mandatory only for those systems that count such events." OBJECT t11FspfIfRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, so only one value needs to be supported." OBJECT t11FspfIfStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfNbrStateChangNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfMinLsArrival MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfMinLsInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." DeSanti, et al. Standards Track [Page 28] RFC 4626 Fibre Channel FSPF MIB September 2006 OBJECT t11FspfSetToDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfIfHelloInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfIfDeadInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfIfRetransmitInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfIfAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfIfSetToDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FspfIfLinkCostFactor MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FspfMIBCompliances 1 } -- Units of Conformance t11FspfGeneralGroup OBJECT-GROUP OBJECTS { t11FspfMinLsArrival, t11FspfMinLsInterval, t11FspfLsRefreshTime, DeSanti, et al. Standards Track [Page 29] RFC 4626 Fibre Channel FSPF MIB September 2006 t11FspfMaxAge, t11FspfMaxAgeDiscards, t11FspfPathComputations, t11FspfChecksumErrors, t11FspfLsrs, t11FspfCreateTime, t11FspfAdminStatus, t11FspfOperStatus, t11FspfNbrStateChangNotifyEnable, t11FspfSetToDefault, t11FspfStorageType } STATUS current DESCRIPTION "A collection of objects for displaying and configuring FSPF parameters." ::= { t11FspfMIBGroups 1 } t11FspfIfGroup OBJECT-GROUP OBJECTS { t11FspfIfHelloInterval, t11FspfIfDeadInterval, t11FspfIfRetransmitInterval, t11FspfIfNbrState, t11FspfIfNbrDomainId, t11FspfIfNbrPortIndex, t11FspfIfAdminStatus, t11FspfIfCreateTime, t11FspfIfSetToDefault, t11FspfIfLinkCostFactor, t11FspfIfRowStatus, t11FspfIfStorageType, t11FspfIfPrevNbrState } STATUS current DESCRIPTION "A collection of objects for displaying the FSPF interface information." ::= { t11FspfMIBGroups 2 } t11FspfIfCounterGroup OBJECT-GROUP OBJECTS { t11FspfIfInLsuPkts, t11FspfIfInLsaPkts, t11FspfIfOutLsuPkts, t11FspfIfOutLsaPkts, t11FspfIfOutHelloPkts, t11FspfIfInHelloPkts, t11FspfIfRetransmittedLsuPkts, t11FspfIfInErrorPkts } STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 30] RFC 4626 Fibre Channel FSPF MIB September 2006 "A collection of objects for counting particular FSPF-packet occurrences on an interface." ::= { t11FspfMIBGroups 3 } t11FspfDatabaseGroup OBJECT-GROUP OBJECTS { t11FspfLsrAdvDomainId, t11FspfLsrAge, t11FspfLsrIncarnationNumber, t11FspfLsrCheckSum, t11FspfLsrLinks, t11FspfLinkNbrDomainId, t11FspfLinkPortIndex, t11FspfLinkNbrPortIndex, t11FspfLinkType, t11FspfLinkCost, t11FspfLinkNumber } STATUS current DESCRIPTION "A collection of objects for displaying the FSPF topology database information." ::= { t11FspfMIBGroups 4 } t11FspfNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FspfNbrStateChangNotify } STATUS current DESCRIPTION "A collection of notifications for FSPF." ::= { t11FspfMIBGroups 5 } END 7. Acknowledgements This document was originally developed and approved by the INCITS Task Group T11.5 (http://www.t11.org) as the SM-FSM project. We wish to acknowledge the many contributions and comments from the INCITS Technical Committee T11, including the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 members, especially: Ken Hirata, Emulex Scott Kipp, McData Elizabeth G. Rodriguez, Dot Hill The document was subsequently approved by the IETF's IMSS Working Group, chaired by David Black (EMC Corporation). We also wish to acknowledge Bert Wijnen (Lucent Technologies), the IETF Area Director, for his review of the document. DeSanti, et al. Standards Track [Page 31] RFC 4626 Fibre Channel FSPF MIB September 2006 8. IANA Considerations The IANA assigned a MIB OID for the T11-FC-FSPF-MIB module under the appropriate subtree. 9. Security Considerations There are several management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability are: t11FspfMinLsArrival, t11FspfMinLsInterval, t11FspfIfHelloInterval, t11FspfIfDeadInterval & t11FspfIfRetransmitInterval -- alter the responsiveness of the FSPF protocol t11FspfAdminStatus & t11FspfIfAdminStatus -- enable/disable dynamic routing via FSPF t11FspfSetToDefault & t11FspfIfSetToDefault -- nullify valid configuration changes t11FspfIfLinkCostFactor -- alter the choice of links t11FspfNbrStateChangNotifyEnable -- enable/disable notifications. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: t11FspfTable -- contains per-Fabric parameters and statistics t11FspfIfTable -- contains per-interface parameters and statistics t11FspfLsrTable & t11FspfLinkTable -- database of LSR information, DeSanti, et al. Standards Track [Page 32] RFC 4626 Fibre Channel FSPF MIB September 2006 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)" ANSI INCITS 373-2003, April 2003. DeSanti, et al. Standards Track [Page 33] RFC 4626 Fibre Channel FSPF MIB September 2006 [FC-SW-4] "Fibre Channel - Switch Fabric - 4 (FC-SW-4)", ANSI INCITS 418-2006, 2006. [FC-MGMT] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, March 2006. 11. Informative References [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. DeSanti, et al. Standards Track [Page 34] RFC 4626 Fibre Channel FSPF MIB September 2006 Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Vinay Gaonkar Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 527-8576 EMail: vgaonkar@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com Silvano Gai Retired DeSanti, et al. Standards Track [Page 35] RFC 4626 Fibre Channel FSPF MIB September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). DeSanti, et al. Standards Track [Page 36] snmp-mibs-downloader-1.1/mibrfcs/rfc4631.txt0000644000000000000000000045176011402176072015575 0ustar Network Working Group M. Dubuc Request for Comments: 4631 T. Nadeau Obsoletes: 4327 Cisco Systems Category: Standards Track J. Lang Sonos, Inc. E. McGinnis Hammerhead Systems A. Farrel Old Dog Consulting September 2006 Link Management Protocol (LMP) Management Information Base (MIB) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides minor corrections to and obsoletes RFC 4327. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). Dubuc, et al. Standards Track [Page 1] RFC 4631 LMP-MIB Module September 2006 Table of Contents 1. The Internet-Standard Management Framework ......................3 2. Introduction ....................................................3 3. Terminology .....................................................3 4. Feature Checklist ...............................................4 5. Outline .........................................................4 6. Brief Description of MIB Objects ................................5 6.1. lmpNbrTable ................................................5 6.2. lmpControlChannelTable .....................................5 6.3. lmpControlChannelPerfTable .................................5 6.4. lmpTeLinkTable .............................................5 6.5. lmpLinkVerificationTable ...................................5 6.6. lmpTeLinkPerfTable .........................................6 6.7. lmpDataLinkTable ...........................................6 6.8. lmpDataLinkPerfTable .......................................6 7. Example of LMP Control Channel Setup ............................6 8. Application of the Interfaces Group to LMP ......................9 8.1. Support of the LMP Layer by ifTable .......................10 9. LMP MIB Module Definitions .....................................11 10. Security Considerations .......................................78 11. Contributors ..................................................79 12. Acknowledgements ..............................................79 13. IANA Considerations ...........................................79 13.1. IANA Considerations for LMP ifType .......................79 13.2. IANA Considerations for LMP-MIB ..........................79 14. Changes from RFC 4327 to RFC 4631 .............................79 15. References ....................................................80 15.1. Normative References .....................................80 15.2. Informative References ...................................81 Dubuc, et al. Standards Track [Page 2] RFC 4631 LMP-MIB Module September 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction Current work is under way in the IETF to specify a suite of protocols to be used as a common control plane and a separate common measurement plane. Generalized MPLS (GMPLS) [RFC3471] and the Link Management Protocol [RFC4204] are key components of this standardization activity. The primary purpose of LMP is to manage traffic engineering (TE) links. Primary goals of LMP are the maintenance of the control channel connectivity, correlation of link properties, verification of data-bearing links, and detection and isolation of link faults. We describe in this document a MIB module that can be used to manage LMP implementations. This MIB module covers both configuration and performance-monitoring aspects of LMP. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Terminology This document uses terminology from the document describing the Link Management Protocol [RFC4204]. An "LMP adjacency" is formed between two nodes that support the same capabilities, and LMP messages are exchanged between the node pair over control channels that form this adjacency. Several control channels can be active at the same time. With the exception of messages related to control channel management, anytime an LMP message needs to be transferred to a neighbor node, it can be sent on any of the active control channels. The control channels can also be used to exchange MPLS control plane information or routing information. Dubuc, et al. Standards Track [Page 3] RFC 4631 LMP-MIB Module September 2006 LMP is designed to support aggregation of one or more data-bearing links into a traffic-engineering (TE) link. The data-bearing links can be either component links or ports, depending on their multiplexing capability (see [RFC4204] for the distinction between port and component link). Each TE link is associated with an LMP adjacency, and one or more control channels are used to exchange LMP messages for a particular adjacency. In turn, control channels are used to manage the TE links associated with the LMP adjacency. 4. Feature Checklist The Link Management Protocol MIB module (LMP-MIB) is designed to satisfy the following requirements and constraints: - The MIB module supports the enabling and disabling of LMP capability on LMP-capable interfaces of a photonic switch, optical cross-connect, or router. - The MIB module is used to provide information about LMP adjacencies. - Support is provided for configuration of the keep-alive and link verification parameters. - The MIB module is used to express the mapping between local and remote TE links, as well as local and remote interface identifiers for port or component link. - Performance counters are provided for measuring LMP performance on a per-control channel basis. Performance counters are also provided for measuring LMP performance on the data-bearing links. Note that the LMP MIB module goes hand-in-hand with the TE Link (TE- LINK-STD-MIB) MIB module [RFC4220]. The TE link table, which is used to associate data-bearing links to TE links, is defined in the TE Link MIB. The TE link table in the LMP MIB module contains TE link information specific to LMP. 5. Outline Configuring LMP through an optical device involves the following steps: - Enabling LMP on LMP-capable interfaces through control channel configuration. Dubuc, et al. Standards Track [Page 4] RFC 4631 LMP-MIB Module September 2006 - Optionally, specifying link verification parameters. - Configuring the data-bearing links and associating them to the appropriate TE link (this association is stored in the ifStackTable of the Interfaces Group MIB). TE links are managed by the control channels that run between the same pair of nodes (LMP adjacency). 6. Brief Description of MIB Objects Sections 6.1 - 6.8 describe objects pertaining to LMP. The MIB objects were derived from the LMP document [RFC4204]. 6.1. lmpNbrTable The remote node table is used to identify the pair of nodes that exchange LMP messages over control channels. 6.2. lmpControlChannelTable The control channel table is used for enabling the LMP protocol on LMP-capable interfaces. A photonic switch, optical cross-connect, or router creates an entry in this table for every LMP-capable interface in that device. 6.3. lmpControlChannelPerfTable The control channel performance table is used for collecting LMP performance counts on a per-control channel basis. Each entry in the lmpControlChannelTable has a corresponding entry in the lmpControlChannelPerfTable. 6.4. lmpTeLinkTable The TE link table is used for specifying LMP information associated with TE links. 6.5. lmpLinkVerificationTable The link verification table is used for configuring the LMP link verification parameters of TE links. For every TE link entry in the lmpTeLinkTable that supports the link verification procedure, there is a corresponding entry in the lmpLinkVerificationTable. Dubuc, et al. Standards Track [Page 5] RFC 4631 LMP-MIB Module September 2006 6.6. lmpTeLinkPerfTable The TE link performance table is used for collecting LMP performance counts on a per-TE link basis. Each entry in the lmpTeLinkTable has a corresponding entry in the lmpTeLinkPerfTable. 6.7. lmpDataLinkTable The data-bearing link table is used to specify the data-bearing links that are associated with TE links. 6.8. lmpDataLinkPerfTable The data-bearing link performance table is used for collecting LMP performance counts on data-bearing links. 7. Example of LMP Control Channel Setup In this section, we provide a brief example of using the MIB objects described in Section 9 to set up an LMP control channel. This example is not meant to illustrate every nuance of the MIB module, but it is intended as an aid to understanding some of the key concepts. It is meant to be read after one goes through the MIB itself. Suppose that one would like to form an LMP adjacency between two nodes using two control channels. Suppose also that there are three data-bearing links. We also assume that the data-bearing links are ports (lambdas) and that the link verification procedure is not enabled. The following example illustrates which rows and corresponding objects might be created to accomplish this. First, LMP must be enabled between the pair of nodes. In lmpNbrTable: { lmpNbrNodeId = 'c0000201'H, -- 192.0.2.1 lmpNbrAdminStatus = up(1), lmpNbrRowStatus = createAndGo(4), lmpNbrStorageType = nonVolatile(3) } Then, the control channels must be set up. These are created in the lmpControlChannelTable. In lmpControlChannelTable: { lmpCcId = 1, Dubuc, et al. Standards Track [Page 6] RFC 4631 LMP-MIB Module September 2006 lmpCcUnderlyingIfIndex = 1, lmpCcIsIf = false(2), lmpCcAuthentication = false(2), lmpCcHelloInterval = 15, lmpCcHelloIntervalMin = 15, lmpCcHelloIntervalMax = 1000, lmpCcHelloDeadInterval = 45, lmpCcHelloDeadIntervalMin = 45, lmpCcHelloDeadIntervalMax = 1000, lmpCcAdminStatus = up(1), lmpCcRowStatus = createAndGo(4), lmpCcStorageType = nonVolatile(3) } { lmpCcId = 2, lmpCcUnderlyingIfIndex = 2, lmpCcIsIf = false(2), lmpCcAuthentication = false(2), lmpCcHelloInterval = 15, lmpCcHelloIntervalMin = 15, lmpCcHelloIntervalMax = 1000, lmpCcHelloDeadInterval = 45, lmpCcHelloDeadIntervalMin = 45, lmpCcHelloDeadIntervalMax = 1000, lmpCcAdminStatus = up(1), lmpCcRowStatus = createAndGo(4), lmpCcStorageType = nonVolatile(3) } Next, the three data-bearing links are created. For each data- bearing link, an ifEntry with the same ifIndex needs to be created beforehand. In lmpDataLinkTable: { ifIndex = 41, lmpDataLinkAddressType = unknown(0), lmpDataLinkIpAddr = ''H, lmpDataLinkRemoteIpAddress = ''H, lmpDataLinkRemoteIfId = 47, lmpDataLinkRowStatus = createAndGo(4), lmpDataLinkStorageType = nonVolatile(3) } { ifIndex = 43, lmpDataLinkAddressType = unknown(0), Dubuc, et al. Standards Track [Page 7] RFC 4631 LMP-MIB Module September 2006 lmpDataLinkIpAddr = ''H, lmpDataLinkRemoteIpAddress = ''H, lmpDataLinkRemoteIfId = 42, lmpDataLinkRowStatus = createAndGo(4), lmpDataLinkStorageType = nonVolatile(3) } { ifIndex = 44, lmpDataLinkAddressType = unknown(0), lmpDataLinkIpAddr = ''H, lmpDataLinkRemoteIpAddress = ''H, lmpDataLinkRemoteIfId = 48, lmpDataLinkRowStatus = createAndGo(4), lmpDataLinkStorageType = nonVolatile(3) } Note that the data-bearing link type (lmpDataLinkType) does not need to be provisioned, as it is automatically populated by the node. The definition of the protection role (primary or secondary) for the data-bearing links is stored in the componentLinkTable of the TE Link MIB module [RFC4220]. Then, a TE link is created as an ifEntry with ifType teLink in the ifTable. Once the TE link is created in the ifTable, a TE link entry is created in the LMP MIB module to specify TE link information specific to LMP. In lmpTeLinkTable: { ifIndex = 20, lmpTeLinkVerification = true(1), lmpTeLinkFaultManagement = true(1), lmpTeLinkDwdm = false(2), lmpTeLinkRowStatus = createAndGo(4), lmpTeLinkStorageType = nonVolatile(3) } and in lmpLinkVerificationTable: { ifIndex = 20, lmpLinkVerifyInterval = 100, lmpLinkVerifyDeadInterval = 300, lmpLinkVerifyTransportMechanism = j0Trace(3), lmpLinkVerifyAllLinks = true(1), lmpLinkVerifyTransmissionRate = 100000, lmpLinkVerifyWavelength = 0, Dubuc, et al. Standards Track [Page 8] RFC 4631 LMP-MIB Module September 2006 lmpLinkVerifyRowStatus = createAndGo(4), lmpLinkVerifyStorageType = nonVolatile(3) } The association between the data-bearing links and the TE links is stored in the ifStackTable [RFC2863]. In parallel with the entry created in the lmpTeLinkTable, an entry may be created in the teLinkTable of the TE Link MIB module [RFC4220]. 8. Application of the Interfaces Group to LMP The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing LMP control channels that are modeled as interfaces. If the control channel as defined in the lmpControlChannelTable is modeled as an ifEntry, then the following definition applies. An lmpControlChannelTable entry is designated as being represented as an Interfaces MIB ifEntry if the lmpControlChannelEntry object lmpCcIsIf is set to true (1). In this case, the control channel SHOULD be modeled as an ifEntry and provide appropriate interface stacking, as defined below. This memo assumes the interpretation of the Interfaces Group to be in accordance with [RFC2863], which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Since the LMP interface only carries control traffic, it is considered to be below the internetwork layer. Thus, the LMP interface may be represented as an entry in the ifTable. The interrelation of entries in the ifTable is defined by Interfaces Stack Group defined in [RFC2863]. When LMP control channels are modeled as interfaces, the interface stack table must appear as follows for the LMP control channel interfaces: +----------------------------------------+ | LMP-interface ifType = lmp(227) + +----------------------------------------+ | Underlying Layer... + +----------------------------------------+ In the above diagram, "Underlying Layer..." refers to the ifIndex of any interface type over which the LMP interface will transmit its traffic. Note that if the underlying layer provides multiple access Dubuc, et al. Standards Track [Page 9] RFC 4631 LMP-MIB Module September 2006 to its media (i.e., Ethernet), then it is possible to stack multiple LMP interfaces on top of this interface in parallel. Note that it is not a requirement that LMP control channels be modeled as interfaces. It is acceptable that control channels simply exist as logical connections between adjacent LMP-capable nodes. In this case, lmpCcIsIf is set to false(2), and no corresponding entry is made in the ifTable. 8.1. Support of the LMP Layer by ifTable Some specific interpretations of ifTable for the LMP layer follow. Object Use for the LMP layer. ifIndex Each LMP interface may be represented by an ifEntry. ifDescr Description of the LMP interface. ifType The value that is allocated for LMP is 227. This number has been assigned by the IANA. ifSpeed The total bandwidth in bits per second for use by the LMP layer. ifPhysAddress Unused. ifAdminStatus This variable indicates the administrator's intent as to whether LMP should be enabled, disabled, or running in some diagnostic testing mode on this interface. Also see [RFC2863]. ifOperStatus This value reflects the actual or operational status of LMP on this interface. ifLastChange See [RFC2863]. ifInOctets The number of received octets over the interface; i.e., the number of octets received as LMP packets. ifOutOctets The number of transmitted octets over the interface; i.e., the number of octets transmitted as LMP packets. ifInErrors The number of LMP packets dropped due to uncorrectable errors. Dubuc, et al. Standards Track [Page 10] RFC 4631 LMP-MIB Module September 2006 ifInUnknownProtos The number of received packets discarded during packet header validation, including packets with unrecognized label values. ifOutErrors See [RFC2863]. ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). ifConnectorPresent Set to false (2). ifHighSpeed See [RFC2863]. ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in [RFC2863]. ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in [RFC2863]. ifAlias The nonvolatile 'alias' name for the interface, as specified by a network manager. ifCounterDiscontinuityTime See [RFC2863]. 9. LMP MIB Module Definitions This MIB module IMPORTs objects from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC4001], and [RFC4220], and it has REFERENCE clauses to [RFC4204], [RFC4207], [RFC4209], [RFC3471], and [RFC2914]. LMP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, transmission, Unsigned32, Counter32, TimeTicks FROM SNMPv2-SMI -- RFC 2578 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580 TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, TimeStamp Dubuc, et al. Standards Track [Page 11] RFC 4631 LMP-MIB Module September 2006 FROM SNMPv2-TC -- RFC 2579 InterfaceIndexOrZero, ifIndex FROM IF-MIB -- RFC 2863 InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC 4001 teLinkRemoteIpAddr, teLinkIncomingIfId, TeLinkEncodingType FROM TE-LINK-STD-MIB; -- RFC 4220 lmpMIB MODULE-IDENTITY LAST-UPDATED "200608140000Z" -- 14 August 2006 ORGANIZATION "Common Control and Measurement Protocols (CCAMP) Working Group" CONTACT-INFO " Martin Dubuc Email: dubuc.consulting@sympatico.ca Thomas D. Nadeau Email: tnadeau@cisco.com Jonathan P. Lang Email: jplang@ieee.org Evan McGinnis Email: emcginnis@hammerheadsystems.com Adrian Farrel Email: adrian@olddog.co.uk" DESCRIPTION "Copyright (C) 2006 The Internet Society. This version of the MIB module is part of RFC 4631; see the RFC itself for full legal notices. This MIB module contains managed object definitions for the Link Management Protocol (LMP) as defined in 'Link Management Protocol'." -- Revision history. REVISION "200608140000Z" -- 14 August 2006 DESCRIPTION "Revised version: - Fixes textual descriptions of TruthValue settings such that True is always 1 and False is always 2. - Adds punctuation to REFERENCE clauses. Dubuc, et al. Standards Track [Page 12] RFC 4631 LMP-MIB Module September 2006 This revision published as RFC 4631" REVISION "200601110000Z" -- 11 January 2006 DESCRIPTION "Initial version published as RFC 4327" ::= { transmission 227 } -- Textual Conventions LmpInterval ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The interval delay, in milliseconds." SYNTAX Unsigned32 (1..65535) LmpRetransmitInterval ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The retransmission interval delay in milliseconds." SYNTAX Unsigned32 (1..4294967295) LmpNodeId ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents a Node ID in network byte order. Node ID is an address of type IPv4." REFERENCE "Section 1.1 of Link Management Protocol, RFC 4204." SYNTAX OCTET STRING(SIZE(4)) -- Top level components of this MIB -- Notifications lmpNotifications OBJECT IDENTIFIER ::= { lmpMIB 0 } -- Tables, Scalars lmpObjects OBJECT IDENTIFIER ::= { lmpMIB 1 } -- Conformance lmpConformance OBJECT IDENTIFIER ::= { lmpMIB 2 } lmpAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired operational status of LMP on the node. Dubuc, et al. Standards Track [Page 13] RFC 4631 LMP-MIB Module September 2006 Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." DEFVAL { up } ::= { lmpObjects 1 } lmpOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of LMP on the node." ::= { lmpObjects 2 } -- LMP Neighbor Table lmpNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the neighbor node(s) to which control channels may be established." ::= { lmpObjects 3 } lmpNbrEntry OBJECT-TYPE SYNTAX LmpNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by a LMP-enabled device for every pair of nodes that can establish control channels." INDEX { lmpNbrNodeId } ::= { lmpNbrTable 1 } LmpNbrEntry ::= SEQUENCE { lmpNbrNodeId LmpNodeId, lmpNbrRetransmitInterval LmpRetransmitInterval, lmpNbrRetryLimit Unsigned32, lmpNbrRetransmitDelta Unsigned32, lmpNbrAdminStatus INTEGER, lmpNbrOperStatus INTEGER, lmpNbrRowStatus RowStatus, lmpNbrStorageType StorageType } lmpNbrNodeId OBJECT-TYPE SYNTAX LmpNodeId Dubuc, et al. Standards Track [Page 14] RFC 4631 LMP-MIB Module September 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a unique index for an entry in the LmpNbrTable. This value represents the remote Node ID." ::= { lmpNbrEntry 1 } lmpNbrRetransmitInterval OBJECT-TYPE SYNTAX LmpRetransmitInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the initial retransmission interval that is used for the retransmission of messages that require acknowledgement. This object, along with lmpNbrRetryLimit, is used to implement the congestion-handling mechanism defined in Section 10 of the Link Management Protocol specification, which is based on RFC 2914." REFERENCE "Link Management Protocol, RFC 4204. Congestion Control Principles, RFC 2914." DEFVAL { 500 } ::= { lmpNbrEntry 2 } lmpNbrRetryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum number of times a message is transmitted without being acknowledged. A value of 0 is used to indicate that a node should never stop retransmission. This object, along with lmpNbrRetransmitInterval, is used to implement the congestion-handling mechanism as defined in Section 10 of the Link Management Protocol specification, which is based on RFC 2914." REFERENCE "Link Management Protocol, RFC 4204. Congestion Control Principles, RFC 2914." DEFVAL { 3 } ::= { lmpNbrEntry 3 } lmpNbrRetransmitDelta OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION Dubuc, et al. Standards Track [Page 15] RFC 4631 LMP-MIB Module September 2006 "This object governs the speed with which the sender increases the retransmission interval, as explained in Section 10 of the Link Management Protocol specification, which is based on RFC 2914. This value is a power used to express the exponential backoff. The ratio of two successive retransmission intervals is (1 + Delta)." REFERENCE "Link Management Protocol, RFC 4204. Congestion Control Principles, RFC 2914." DEFVAL { 1 } ::= { lmpNbrEntry 4 } lmpNbrAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of LMP to this remote node." ::= { lmpNbrEntry 5 } lmpNbrOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of LMP to this remote node." ::= { lmpNbrEntry 6 } lmpNbrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. None of the writable objects in a row can be changed if the status is active(1). All read-create objects must have valid and consistent values before the row can be activated." ::= { lmpNbrEntry 7 } lmpNbrStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the lmpNbrTable. Conceptual rows having the value 'permanent' need not allow write-access to any Dubuc, et al. Standards Track [Page 16] RFC 4631 LMP-MIB Module September 2006 columnar object in the row." DEFVAL { nonVolatile } ::= { lmpNbrEntry 8 } -- End of lmpNbrTable lmpCcHelloIntervalDefault OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the default value for the HelloInterval parameter used in the Hello protocol keep-alive phase. It indicates how frequently LMP Hello messages will be sent. It is used as the default value for lmpCcHelloInterval. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpObjects 4 } lmpCcHelloIntervalDefaultMin OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the default minimum value for the HelloInterval parameter. It is used as a default value for lmpCcHelloIntervalMin. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." ::= { lmpObjects 5 } lmpCcHelloIntervalDefaultMax OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the default maximum value for the HelloInterval parameter. It is used as a default value for lmpCcHelloIntervalMax. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." ::= { lmpObjects 6 } lmpCcHelloDeadIntervalDefault OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write Dubuc, et al. Standards Track [Page 17] RFC 4631 LMP-MIB Module September 2006 STATUS current DESCRIPTION "This object specifies the default HelloDeadInterval parameter to use in the Hello protocol keep-alive phase. It indicates how long a device should wait before declaring the control channel dead. The HelloDeadInterval parameter should be at least three times the value of HelloInterval. It is used as a default value for lmpCcHelloDeadInterval. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpObjects 7 } lmpCcHelloDeadIntervalDefaultMin OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the default minimum value for the HelloDeadInterval parameter. It is used as a default value for lmpCcHelloDeadIntervalMin. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." ::= { lmpObjects 8 } lmpCcHelloDeadIntervalDefaultMax OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the default maximum value for the HelloDeadInterval parameter. It is used as a default value for lmpCcHelloDeadIntervalMax. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." ::= { lmpObjects 9 } -- LMP Control Channel Table lmpControlChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpControlChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies LMP control channel information." ::= { lmpObjects 10 } Dubuc, et al. Standards Track [Page 18] RFC 4631 LMP-MIB Module September 2006 lmpControlChannelEntry OBJECT-TYPE SYNTAX LmpControlChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LMP-enabled device for every control channel. Whenever a new entry is created with lmpCcIsIf set to true(1), a corresponding entry is created in ifTable as well (see RFC 2863)." INDEX { lmpCcId } ::= { lmpControlChannelTable 1 } LmpControlChannelEntry ::= SEQUENCE { lmpCcId Unsigned32, lmpCcUnderlyingIfIndex InterfaceIndexOrZero, lmpCcIsIf TruthValue, lmpCcNbrNodeId LmpNodeId, lmpCcRemoteId Unsigned32, lmpCcRemoteAddressType InetAddressType, lmpCcRemoteIpAddr InetAddress, lmpCcSetupRole INTEGER, lmpCcAuthentication TruthValue, lmpCcHelloInterval LmpInterval, lmpCcHelloIntervalMin LmpInterval, lmpCcHelloIntervalMax LmpInterval, lmpCcHelloIntervalNegotiated LmpInterval, lmpCcHelloDeadInterval LmpInterval, lmpCcHelloDeadIntervalMin LmpInterval, lmpCcHelloDeadIntervalMax LmpInterval, lmpCcHelloDeadIntervalNegotiated LmpInterval, lmpCcLastChange TimeTicks, lmpCcAdminStatus INTEGER, lmpCcOperStatus INTEGER, lmpCcRowStatus RowStatus, lmpCcStorageType StorageType } lmpCcId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value represents the local control channel identifier. The control channel identifier is a non-zero 32-bit number." ::= { lmpControlChannelEntry 1 } lmpCcUnderlyingIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero Dubuc, et al. Standards Track [Page 19] RFC 4631 LMP-MIB Module September 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "If lmpCcIsIf is set to true(1), this object carries the index into the ifTable of the entry that represents the LMP interface over which LMP will transmit its traffic. If this object is set to zero but lmpCcIsIf is set to true(1), the control channel is not currently associated with any underlying interface, and the control channel's operational status must not be up(1); nor should the control channel forward or receive traffic. If lmpCcIsIf is set to false(2), this object should be set to zero and ignored." ::= { lmpControlChannelEntry 2 } lmpCcIsIf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "In implementations where the control channels are modeled as interfaces, the value of this object is true(1), and this control channel is represented by an interface in the interfaces group table as indicated by the value of lmpCcUnderlyingIfIndex. If control channels are not modeled as interfaces, the value of this object is false(2), and there is no corresponding interface for this control channel in the interfaces group table; the value of lmpCcUnderlyingIfIndex should be ignored." ::= { lmpControlChannelEntry 3 } lmpCcNbrNodeId OBJECT-TYPE SYNTAX LmpNodeId MAX-ACCESS read-create STATUS current DESCRIPTION "This is the Node ID of the control channel remote node. This value either is configured or gets created by the node when a Config message is received or when an outgoing Config message is acknowledged by the remote node." ::= { lmpControlChannelEntry 4 } lmpCcRemoteId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION Dubuc, et al. Standards Track [Page 20] RFC 4631 LMP-MIB Module September 2006 "This value represents the remote control channel identifier (32-bit number). It is determined during the negotiation phase. A value of zero means that the remote control channel identifier has not yet been learned." ::= { lmpControlChannelEntry 5 } lmpCcRemoteAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This value represents the remote control channel IP address type. In point-to-point configuration, this value can be set to unknown(0)." ::= { lmpControlChannelEntry 6 } lmpCcRemoteIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This value represents the remote control channel Internet address for numbered control channel. The type of this address is determined by lmpCcRemoteAddressType. The control channel must be numbered on non-point-to-point configuration. For point-to-point configuration, the remote control channel address can be of type unknown, in which case this object must be a zero-length string. The lmpCcRemoteId object then identifies the unnumbered address." ::= { lmpControlChannelEntry 7 } lmpCcSetupRole OBJECT-TYPE SYNTAX INTEGER { active(1), passive(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The role that this node should take during establishment of this control channel. An active node will initiate establishment. A passive node will wait for the remote node to initiate. A pair of nodes that both take the passive role will never establish communications." DEFVAL { active } ::= { lmpControlChannelEntry 8 } lmpCcAuthentication OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create Dubuc, et al. Standards Track [Page 21] RFC 4631 LMP-MIB Module September 2006 STATUS current DESCRIPTION "This object indicates whether the control channel must use authentication." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpControlChannelEntry 9 } lmpCcHelloInterval OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the value of the HelloInterval parameter. The default value for this object should be set to lmpCcHelloIntervalDefault." ::= { lmpControlChannelEntry 10 } lmpCcHelloIntervalMin OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the minimum value for the HelloInterval parameter. The default value for this object should be set to lmpCcHelloIntervalMinDefault." ::= { lmpControlChannelEntry 11 } lmpCcHelloIntervalMax OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum value for the HelloInterval parameter. The default value for this object should be set to lmpCcHelloIntervalMaxDefault." ::= { lmpControlChannelEntry 12 } lmpCcHelloIntervalNegotiated OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Once the control channel is active, this object represents the negotiated HelloInterval value." ::= { lmpControlChannelEntry 13 } lmpCcHelloDeadInterval OBJECT-TYPE Dubuc, et al. Standards Track [Page 22] RFC 4631 LMP-MIB Module September 2006 SYNTAX LmpInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the value of the HelloDeadInterval parameter. The default value for this object should be set to lmpCcHelloDeadIntervalDefault." ::= { lmpControlChannelEntry 14 } lmpCcHelloDeadIntervalMin OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the minimum value for the HelloDeadInterval parameter. The default value for this object should be set to lmpCcHelloDeadIntervalMinDefault." ::= { lmpControlChannelEntry 15 } lmpCcHelloDeadIntervalMax OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum value for the HelloDeadInterval parameter. The default value for this object should be set to lmpCcHelloIntervalMaxDefault." ::= { lmpControlChannelEntry 16 } lmpCcHelloDeadIntervalNegotiated OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-only STATUS current DESCRIPTION "Once the control channel is active, this object represents the negotiated HelloDeadInterval value." ::= { lmpControlChannelEntry 17 } lmpCcLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the control channel entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." Dubuc, et al. Standards Track [Page 23] RFC 4631 LMP-MIB Module September 2006 ::= { lmpControlChannelEntry 18 } lmpCcAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of this control channel." ::= { lmpControlChannelEntry 19 } lmpCcOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), configSnd(3), configRcv(4), active(5), goingDown(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of this control channel." ::= { lmpControlChannelEntry 20 } lmpCcRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. None of the writable objects in a row can be changed if the status is active(1). All read-create objects must have valid and consistent values before the row can be activated." ::= { lmpControlChannelEntry 21 } lmpCcStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the lmpControlChannelTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." DEFVAL { nonVolatile } Dubuc, et al. Standards Track [Page 24] RFC 4631 LMP-MIB Module September 2006 ::= { lmpControlChannelEntry 22 } -- End of lmpControlChannelTable -- LMP Control Channel Performance Table lmpControlChannelPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpControlChannelPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies LMP control channel performance counters." ::= { lmpObjects 11 } lmpControlChannelPerfEntry OBJECT-TYPE SYNTAX LmpControlChannelPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by a LMP-enabled device for every control channel. lmpCcCounterDiscontinuityTime is used to indicate potential discontinuity for all counter objects in this table." INDEX { lmpCcId } ::= { lmpControlChannelPerfTable 1 } LmpControlChannelPerfEntry ::= SEQUENCE { lmpCcInOctets Counter32, lmpCcInDiscards Counter32, lmpCcInErrors Counter32, lmpCcOutOctets Counter32, lmpCcOutDiscards Counter32, lmpCcOutErrors Counter32, lmpCcConfigReceived Counter32, lmpCcConfigSent Counter32, lmpCcConfigRetransmit Counter32, lmpCcConfigAckReceived Counter32, lmpCcConfigAckSent Counter32, lmpCcConfigNackReceived Counter32, lmpCcConfigNackSent Counter32, lmpCcHelloReceived Counter32, lmpCcHelloSent Counter32, lmpCcBeginVerifyReceived Counter32, lmpCcBeginVerifySent Counter32, lmpCcBeginVerifyRetransmit Counter32, lmpCcBeginVerifyAckReceived Counter32, Dubuc, et al. Standards Track [Page 25] RFC 4631 LMP-MIB Module September 2006 lmpCcBeginVerifyAckSent Counter32, lmpCcBeginVerifyNackReceived Counter32, lmpCcBeginVerifyNackSent Counter32, lmpCcEndVerifyReceived Counter32, lmpCcEndVerifySent Counter32, lmpCcEndVerifyRetransmit Counter32, lmpCcEndVerifyAckReceived Counter32, lmpCcEndVerifyAckSent Counter32, lmpCcTestStatusSuccessReceived Counter32, lmpCcTestStatusSuccessSent Counter32, lmpCcTestStatusSuccessRetransmit Counter32, lmpCcTestStatusFailureReceived Counter32, lmpCcTestStatusFailureSent Counter32, lmpCcTestStatusFailureRetransmit Counter32, lmpCcTestStatusAckReceived Counter32, lmpCcTestStatusAckSent Counter32, lmpCcLinkSummaryReceived Counter32, lmpCcLinkSummarySent Counter32, lmpCcLinkSummaryRetransmit Counter32, lmpCcLinkSummaryAckReceived Counter32, lmpCcLinkSummaryAckSent Counter32, lmpCcLinkSummaryNackReceived Counter32, lmpCcLinkSummaryNackSent Counter32, lmpCcChannelStatusReceived Counter32, lmpCcChannelStatusSent Counter32, lmpCcChannelStatusRetransmit Counter32, lmpCcChannelStatusAckReceived Counter32, lmpCcChannelStatusAckSent Counter32, lmpCcChannelStatusReqReceived Counter32, lmpCcChannelStatusReqSent Counter32, lmpCcChannelStatusReqRetransmit Counter32, lmpCcChannelStatusRspReceived Counter32, lmpCcChannelStatusRspSent Counter32, lmpCcCounterDiscontinuityTime TimeStamp } lmpCcInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of LMP message octets received on the control channel." ::= { lmpControlChannelPerfEntry 1 } lmpCcInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Dubuc, et al. Standards Track [Page 26] RFC 4631 LMP-MIB Module September 2006 STATUS current DESCRIPTION "The number of inbound packets that were chosen to be discarded even though no errors had been detected. One possible reason for discarding such a packet could be to free up buffer space." ::= { lmpControlChannelPerfEntry 2 } lmpCcInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound packets that contained errors preventing them from being processed by LMP." ::= { lmpControlChannelPerfEntry 3 } lmpCcOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of LMP message octets transmitted out of the control channel." ::= { lmpControlChannelPerfEntry 4 } lmpCcOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets that were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space." ::= { lmpControlChannelPerfEntry 5 } lmpCcOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets that could not be transmitted because of errors." ::= { lmpControlChannelPerfEntry 6 } lmpCcConfigReceived OBJECT-TYPE Dubuc, et al. Standards Track [Page 27] RFC 4631 LMP-MIB Module September 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Config messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 7 } lmpCcConfigSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Config messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 8 } lmpCcConfigRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Config messages that have been retransmitted over this control channel." ::= { lmpControlChannelPerfEntry 9 } lmpCcConfigAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ConfigAck messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 10 } lmpCcConfigAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ConfigAck messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 11 } lmpCcConfigNackReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Dubuc, et al. Standards Track [Page 28] RFC 4631 LMP-MIB Module September 2006 DESCRIPTION "This object counts the number of ConfigNack messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 12 } lmpCcConfigNackSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ConfigNack messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 13 } lmpCcHelloReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Hello messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 14 } lmpCcHelloSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Hello messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 15 } lmpCcBeginVerifyReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerify messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 16 } lmpCcBeginVerifySent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerify messages that have been sent on this control channel." Dubuc, et al. Standards Track [Page 29] RFC 4631 LMP-MIB Module September 2006 ::= { lmpControlChannelPerfEntry 17 } lmpCcBeginVerifyRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerify messages that have been retransmitted over this control channel." ::= { lmpControlChannelPerfEntry 18 } lmpCcBeginVerifyAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyAck messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 19 } lmpCcBeginVerifyAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyAck messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 20 } lmpCcBeginVerifyNackReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyNack messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 21 } lmpCcBeginVerifyNackSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyNack messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 22 } lmpCcEndVerifyReceived OBJECT-TYPE Dubuc, et al. Standards Track [Page 30] RFC 4631 LMP-MIB Module September 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerify messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 23 } lmpCcEndVerifySent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerify messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 24 } lmpCcEndVerifyRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerify messages that have been retransmitted over this control channel." ::= { lmpControlChannelPerfEntry 25 } lmpCcEndVerifyAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerifyAck messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 26 } lmpCcEndVerifyAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerifyAck messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 27 } lmpCcTestStatusSuccessReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Dubuc, et al. Standards Track [Page 31] RFC 4631 LMP-MIB Module September 2006 DESCRIPTION "This object counts the number of TestStatusSuccess messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 28 } lmpCcTestStatusSuccessSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusSuccess messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 29 } lmpCcTestStatusSuccessRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusSuccess messages that have been retransmitted over this control channel." ::= { lmpControlChannelPerfEntry 30 } lmpCcTestStatusFailureReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusFailure messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 31 } lmpCcTestStatusFailureSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusFailure messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 32 } lmpCcTestStatusFailureRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusFailure messages that have been retransmitted over this control channel." Dubuc, et al. Standards Track [Page 32] RFC 4631 LMP-MIB Module September 2006 ::= { lmpControlChannelPerfEntry 33 } lmpCcTestStatusAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusAck messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 34 } lmpCcTestStatusAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusAck messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 35 } lmpCcLinkSummaryReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummary messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 36 } lmpCcLinkSummarySent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummary messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 37 } lmpCcLinkSummaryRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummary messages that have been retransmitted over this control channel." ::= { lmpControlChannelPerfEntry 38 } lmpCcLinkSummaryAckReceived OBJECT-TYPE Dubuc, et al. Standards Track [Page 33] RFC 4631 LMP-MIB Module September 2006 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryAck messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 39 } lmpCcLinkSummaryAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryAck messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 40 } lmpCcLinkSummaryNackReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryNack messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 41 } lmpCcLinkSummaryNackSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryNack messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 42 } lmpCcChannelStatusReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatus messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 43 } lmpCcChannelStatusSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Dubuc, et al. Standards Track [Page 34] RFC 4631 LMP-MIB Module September 2006 DESCRIPTION "This object counts the number of ChannelStatus messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 44 } lmpCcChannelStatusRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatus messages that have been retransmitted on this control channel." ::= { lmpControlChannelPerfEntry 45 } lmpCcChannelStatusAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusAck messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 46 } lmpCcChannelStatusAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatus messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 47 } lmpCcChannelStatusReqReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusRequest messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 48 } lmpCcChannelStatusReqSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusRequest messages that have been sent on this control channel." Dubuc, et al. Standards Track [Page 35] RFC 4631 LMP-MIB Module September 2006 ::= { lmpControlChannelPerfEntry 49 } lmpCcChannelStatusReqRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusRequest messages that have been retransmitted on this control channel." ::= { lmpControlChannelPerfEntry 50 } lmpCcChannelStatusRspReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusResponse messages that have been received on this control channel." ::= { lmpControlChannelPerfEntry 51 } lmpCcChannelStatusRspSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusResponse messages that have been sent on this control channel." ::= { lmpControlChannelPerfEntry 52 } lmpCcCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which one or more of this control channel's counters suffered a discontinuity. The relevant counters are the specific instances associated with this control channel of any Counter32 object contained in the lmpControlChannelPerfTable. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { lmpControlChannelPerfEntry 53 } -- End of lmpControlChannelPerfTable -- LMP TE Link Table Dubuc, et al. Standards Track [Page 36] RFC 4631 LMP-MIB Module September 2006 lmpTeLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpTeLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the LMP-specific TE link information. Overall TE link information is kept in three separate tables: ifTable for interface-specific information, lmpTeLinkTable for LMP specific information, and teLinkTable for generic TE link information. ifIndex is the common index to all tables." ::= { lmpObjects 12 } lmpTeLinkEntry OBJECT-TYPE SYNTAX LmpTeLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table exists for each ifEntry with an ifType of teLink(200) that is managed by LMP. An ifEntry with an ifIndex must exist before the corresponding lmpTeLinkEntry is created. If a TE link entry in the ifTable is destroyed, then so is the corresponding entry in the lmpTeLinkTable. The administrative status value is controlled from the ifEntry. Setting the administrative status to testing prompts LMP to start link verification on the TE link. Information about the TE link that is not LMP specific is contained in the teLinkTable of the TE-LINK-STD-MIB MIB module." INDEX { ifIndex } ::= { lmpTeLinkTable 1 } LmpTeLinkEntry ::= SEQUENCE { lmpTeLinkNbrRemoteNodeId LmpNodeId, lmpTeLinkVerification TruthValue, lmpTeLinkFaultManagement TruthValue, lmpTeLinkDwdm TruthValue, lmpTeLinkOperStatus INTEGER, lmpTeLinkRowStatus RowStatus, lmpTeLinkStorageType StorageType } lmpTeLinkNbrRemoteNodeId OBJECT-TYPE SYNTAX LmpNodeId MAX-ACCESS read-create STATUS current DESCRIPTION "This is the Node ID of the TE link remote node. This value may be learned during the control channel parameter negotiation Dubuc, et al. Standards Track [Page 37] RFC 4631 LMP-MIB Module September 2006 phase (in the Config message). Node ID is an address whose type must be IPv4." ::= { lmpTeLinkEntry 1 } lmpTeLinkVerification OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether the LMP link verification procedure is enabled for this TE link." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpTeLinkEntry 2 } lmpTeLinkFaultManagement OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether the LMP fault management procedure is enabled on this TE link." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpTeLinkEntry 3 } lmpTeLinkDwdm OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether the LMP DWDM procedure is enabled on this TE link." REFERENCE "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems, RFC 4209." ::= { lmpTeLinkEntry 4 } lmpTeLinkOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3), init(4), degraded(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of this TE link. The status is set to testing when the TE link is performing link verification. A degraded state indicates that there is Dubuc, et al. Standards Track [Page 38] RFC 4631 LMP-MIB Module September 2006 no active control channel between the pair of nodes that form the endpoints of the TE link, but that at least one data-bearing link on the TE link is allocated." ::= { lmpTeLinkEntry 5 } lmpTeLinkRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. None of the writable objects in a row can be changed if the status is active(1). All read-create objects must have valid and consistent values before the row can be activated." ::= { lmpTeLinkEntry 6 } lmpTeLinkStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the lmpTeLinkTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." DEFVAL { nonVolatile } ::= { lmpTeLinkEntry 7 } -- End of lmpTeLinkTable lmpGlobalLinkVerificationInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates how often the link verification procedure is executed. The interval is in milliseconds. A value of 0 is used to indicate that the link verification procedure should not be executed. The interval specified in this object should be large enough to allow the verification procedure to be completed before the start of the next interval. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." ::= { lmpObjects 13 } Dubuc, et al. Standards Track [Page 39] RFC 4631 LMP-MIB Module September 2006 -- LMP Link Verification Table lmpLinkVerificationTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpLinkVerificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies TE link information associated with the LMP verification procedure." ::= { lmpObjects 14 } lmpLinkVerificationEntry OBJECT-TYPE SYNTAX LmpLinkVerificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LMP-enabled device for every TE link that supports the LMP verification procedure." INDEX { ifIndex } ::= { lmpLinkVerificationTable 1 } LmpLinkVerificationEntry ::= SEQUENCE { lmpLinkVerifyInterval LmpInterval, lmpLinkVerifyDeadInterval LmpInterval, lmpLinkVerifyTransportMechanism BITS, lmpLinkVerifyAllLinks TruthValue, lmpLinkVerifyTransmissionRate Unsigned32, lmpLinkVerifyWavelength Unsigned32, lmpLinkVerifyRowStatus RowStatus, lmpLinkVerifyStorageType StorageType } lmpLinkVerifyInterval OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the VerifyInterval parameter used in the LMP link verification process. It indicates the interval at which the Test messages are sent." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpLinkVerificationEntry 1 } lmpLinkVerifyDeadInterval OBJECT-TYPE SYNTAX LmpInterval MAX-ACCESS read-create Dubuc, et al. Standards Track [Page 40] RFC 4631 LMP-MIB Module September 2006 STATUS current DESCRIPTION "This object specifies the VerifyDeadInterval parameter used in the verification of the physical connectivity of data- bearing links. It specifies the observation period used to detect a Test message at the remote node." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpLinkVerificationEntry 2 } lmpLinkVerifyTransportMechanism OBJECT-TYPE SYNTAX BITS { -- All encoding types: payload(0), -- SONET/SDH encoding type: dccSectionOverheadBytes(1), dccLineOverheadBytes(2), j0Trace(3), j1Trace(4), j2Trace(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This defines the transport mechanism for the Test messages. The scope of this bit mask is restricted to each link encoding type. The local node will set the bits corresponding to the various mechanisms it can support for transmitting LMP Test messages. The receiver chooses the appropriate mechanism in the BeginVerifyAck message." REFERENCE "Link Management Protocol, RFC 4204 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages, RFC 4207." ::= { lmpLinkVerificationEntry 3 } lmpLinkVerifyAllLinks OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A value of true(1) for this object indicates that the verification process checks all unallocated links; otherwise, only the new ports or component links that have been added to this TE link are verified." ::= { lmpLinkVerificationEntry 4 } Dubuc, et al. Standards Track [Page 41] RFC 4631 LMP-MIB Module September 2006 lmpLinkVerifyTransmissionRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes per second" MAX-ACCESS read-create STATUS current DESCRIPTION "This is the transmission rate of the data link over which the Test messages will be transmitted and is expressed in bytes per second." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpLinkVerificationEntry 5 } lmpLinkVerifyWavelength OBJECT-TYPE SYNTAX Unsigned32 UNITS "nanometers" MAX-ACCESS read-create STATUS current DESCRIPTION "This value corresponds to the wavelength at which the Test messages will be transmitted and is measured in nanometers (nm). If each data-bearing link corresponds to a separate wavelength, then this value should be set to 0." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpLinkVerificationEntry 6 } lmpLinkVerifyRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. None of the writable objects in a row can be changed if the status is active(1). All read-create objects must have valid and consistent values before the row can be activated." ::= { lmpLinkVerificationEntry 7 } lmpLinkVerifyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the lmpLinkVerificationTable. Conceptual rows having the value 'permanent' need not allow write-access to any Dubuc, et al. Standards Track [Page 42] RFC 4631 LMP-MIB Module September 2006 columnar object in the row." DEFVAL { nonVolatile } ::= { lmpLinkVerificationEntry 8 } -- End of lmpLinkVerificationTable -- LMP TE Link Performance Table lmpTeLinkPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpTeLinkPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies LMP TE link performance counters." ::= { lmpObjects 15 } lmpTeLinkPerfEntry OBJECT-TYPE SYNTAX LmpTeLinkPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by an LMP-enabled device for every TE link. lmpTeCounterDiscontinuityTime is used to indicate potential discontinuity for all counter objects in this table." INDEX { ifIndex } ::= { lmpTeLinkPerfTable 1 } LmpTeLinkPerfEntry ::= SEQUENCE { lmpTeInOctets Counter32, lmpTeOutOctets Counter32, lmpTeBeginVerifyReceived Counter32, lmpTeBeginVerifySent Counter32, lmpTeBeginVerifyRetransmit Counter32, lmpTeBeginVerifyAckReceived Counter32, lmpTeBeginVerifyAckSent Counter32, lmpTeBeginVerifyNackReceived Counter32, lmpTeBeginVerifyNackSent Counter32, lmpTeEndVerifyReceived Counter32, lmpTeEndVerifySent Counter32, lmpTeEndVerifyRetransmit Counter32, lmpTeEndVerifyAckReceived Counter32, lmpTeEndVerifyAckSent Counter32, lmpTeTestStatusSuccessReceived Counter32, lmpTeTestStatusSuccessSent Counter32, lmpTeTestStatusSuccessRetransmit Counter32, lmpTeTestStatusFailureReceived Counter32, Dubuc, et al. Standards Track [Page 43] RFC 4631 LMP-MIB Module September 2006 lmpTeTestStatusFailureSent Counter32, lmpTeTestStatusFailureRetransmit Counter32, lmpTeTestStatusAckReceived Counter32, lmpTeTestStatusAckSent Counter32, lmpTeLinkSummaryReceived Counter32, lmpTeLinkSummarySent Counter32, lmpTeLinkSummaryRetransmit Counter32, lmpTeLinkSummaryAckReceived Counter32, lmpTeLinkSummaryAckSent Counter32, lmpTeLinkSummaryNackReceived Counter32, lmpTeLinkSummaryNackSent Counter32, lmpTeChannelStatusReceived Counter32, lmpTeChannelStatusSent Counter32, lmpTeChannelStatusRetransmit Counter32, lmpTeChannelStatusAckReceived Counter32, lmpTeChannelStatusAckSent Counter32, lmpTeChannelStatusReqReceived Counter32, lmpTeChannelStatusReqSent Counter32, lmpTeChannelStatusReqRetransmit Counter32, lmpTeChannelStatusRspReceived Counter32, lmpTeChannelStatusRspSent Counter32, lmpTeCounterDiscontinuityTime TimeStamp } lmpTeInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of LMP message octets received for this TE link." ::= { lmpTeLinkPerfEntry 1 } lmpTeOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of LMP message octets transmitted out for this TE link." ::= { lmpTeLinkPerfEntry 2 } lmpTeBeginVerifyReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerify messages that have Dubuc, et al. Standards Track [Page 44] RFC 4631 LMP-MIB Module September 2006 been received for this TE link." ::= { lmpTeLinkPerfEntry 3 } lmpTeBeginVerifySent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerify messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 4 } lmpTeBeginVerifyRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerify messages that have been retransmitted for this TE link." ::= { lmpTeLinkPerfEntry 5 } lmpTeBeginVerifyAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyAck messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 6 } lmpTeBeginVerifyAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyAck messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 7 } lmpTeBeginVerifyNackReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyNack messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 8 } Dubuc, et al. Standards Track [Page 45] RFC 4631 LMP-MIB Module September 2006 lmpTeBeginVerifyNackSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of BeginVerifyNack messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 9 } lmpTeEndVerifyReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerify messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 10 } lmpTeEndVerifySent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerify messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 11 } lmpTeEndVerifyRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerify messages that have been retransmitted over this control channel." ::= { lmpTeLinkPerfEntry 12 } lmpTeEndVerifyAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of EndVerifyAck messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 13 } lmpTeEndVerifyAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Dubuc, et al. Standards Track [Page 46] RFC 4631 LMP-MIB Module September 2006 STATUS current DESCRIPTION "This object counts the number of EndVerifyAck messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 14 } lmpTeTestStatusSuccessReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusSuccess messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 15 } lmpTeTestStatusSuccessSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusSuccess messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 16 } lmpTeTestStatusSuccessRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusSuccess messages that have been retransmitted for this TE link." ::= { lmpTeLinkPerfEntry 17 } lmpTeTestStatusFailureReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusFailure messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 18 } lmpTeTestStatusFailureSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusFailure messages Dubuc, et al. Standards Track [Page 47] RFC 4631 LMP-MIB Module September 2006 that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 19 } lmpTeTestStatusFailureRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusFailure messages that have been retransmitted on this TE link." ::= { lmpTeLinkPerfEntry 20 } lmpTeTestStatusAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusAck messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 21 } lmpTeTestStatusAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of TestStatusAck messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 22 } lmpTeLinkSummaryReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummary messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 23 } lmpTeLinkSummarySent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummary messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 24 } Dubuc, et al. Standards Track [Page 48] RFC 4631 LMP-MIB Module September 2006 lmpTeLinkSummaryRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummary messages that have been retransmitted over this control channel." ::= { lmpTeLinkPerfEntry 25 } lmpTeLinkSummaryAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryAck messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 26 } lmpTeLinkSummaryAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryAck messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 27 } lmpTeLinkSummaryNackReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryNack messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 28 } lmpTeLinkSummaryNackSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of LinkSummaryNack messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 29 } lmpTeChannelStatusReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Dubuc, et al. Standards Track [Page 49] RFC 4631 LMP-MIB Module September 2006 STATUS current DESCRIPTION "This object counts the number of ChannelStatus messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 30 } lmpTeChannelStatusSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatus messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 31 } lmpTeChannelStatusRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatus messages that have been retransmitted for this TE link." ::= { lmpTeLinkPerfEntry 32 } lmpTeChannelStatusAckReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusAck messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 33 } lmpTeChannelStatusAckSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatus messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 34 } lmpTeChannelStatusReqReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusRequest messages Dubuc, et al. Standards Track [Page 50] RFC 4631 LMP-MIB Module September 2006 that have been received for this TE link." ::= { lmpTeLinkPerfEntry 35 } lmpTeChannelStatusReqSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusRequest messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 36 } lmpTeChannelStatusReqRetransmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusRequest messages that have been retransmitted for this TE link." ::= { lmpTeLinkPerfEntry 37 } lmpTeChannelStatusRspReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusResponse messages that have been received for this TE link." ::= { lmpTeLinkPerfEntry 38 } lmpTeChannelStatusRspSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of ChannelStatusResponse messages that have been sent for this TE link." ::= { lmpTeLinkPerfEntry 39 } lmpTeCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which one or more of this TE link's counters suffered a discontinuity. The relevant counters are the specific instances associated with this TE link of any Counter32 Dubuc, et al. Standards Track [Page 51] RFC 4631 LMP-MIB Module September 2006 object contained in the lmpTeLinkPerfTable. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { lmpTeLinkPerfEntry 40 } -- End of lmpTeLinkPerfTable -- LMP Data Link Table lmpDataLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpDataLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the data-bearing links managed by the LMP." ::= { lmpObjects 16 } lmpDataLinkEntry OBJECT-TYPE SYNTAX LmpDataLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table exists for each ifEntry that represents a data-bearing link. An ifEntry with an ifIndex must exist before the corresponding lmpDataLinkEntry is created. If an entry representing the data-bearing link is destroyed in the ifTable, then so is the corresponding entry in the lmpDataLinkTable. The administrative status value is controlled from the ifEntry. The index to this table is also used to get information in the componentLinkTable of the TE-LINK-STD-MIB MIB module." INDEX { ifIndex } ::= { lmpDataLinkTable 1 } LmpDataLinkEntry ::= SEQUENCE { lmpDataLinkType INTEGER, lmpDataLinkAddressType InetAddressType, lmpDataLinkIpAddr InetAddress, lmpDataLinkRemoteIpAddress InetAddress, lmpDataLinkRemoteIfId InterfaceIndexOrZero, lmpDataLinkEncodingType TeLinkEncodingType, lmpDataLinkActiveOperStatus INTEGER, lmpDataLinkPassiveOperStatus INTEGER, lmpDataLinkRowStatus RowStatus, lmpDataLinkStorageType StorageType Dubuc, et al. Standards Track [Page 52] RFC 4631 LMP-MIB Module September 2006 } lmpDataLinkType OBJECT-TYPE SYNTAX INTEGER { port(1), componentLink(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute specifies whether this data-bearing link is a port or a component link. Component links are multiplex capable, whereas ports are not multiplex capable." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpDataLinkEntry 1 } lmpDataLinkAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This attribute specifies the data-bearing link IP address type. If the data-bearing link is unnumbered, the address type must be set to unknown(0)." ::= { lmpDataLinkEntry 2 } lmpDataLinkIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The local Internet address for numbered links. The type of this address is determined by the value of lmpDataLinkAddressType object. For IPv4 and IPv6 numbered links, this object represents the local IP address associated with the data-bearing link. For an unnumbered link, the local address is of type unknown, and this object is set to the zero-length string; the ifIndex object then identifies the unnumbered address." ::= { lmpDataLinkEntry 3 } lmpDataLinkRemoteIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current Dubuc, et al. Standards Track [Page 53] RFC 4631 LMP-MIB Module September 2006 DESCRIPTION "The remote Internet address for numbered data-bearing links. The type of this address is determined by the lmpDataLinkAddressType object. For IPv4 and IPv6 numbered links, this object represents the remote IP address associated with the data-bearing link. For an unnumbered link, the remote address is of type unknown, and this object is set to the zero-length string; the lmpDataLinkRemoteIfId object then identifies the unnumbered address. This information is either configured manually or communicated by the remote node during the link verification procedure." ::= { lmpDataLinkEntry 4 } lmpDataLinkRemoteIfId OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Interface identifier of the remote end point. This information is either configured manually or communicated by the remote node during the link verification procedure." ::= { lmpDataLinkEntry 5 } lmpDataLinkEncodingType OBJECT-TYPE SYNTAX TeLinkEncodingType MAX-ACCESS read-create STATUS current DESCRIPTION "The encoding type of the data-bearing link." REFERENCE "Generalized MPLS Signaling Functional Description, RFC 3471." ::= { lmpDataLinkEntry 6 } lmpDataLinkActiveOperStatus OBJECT-TYPE SYNTAX INTEGER { upAlloc(1), upFree(2), down(3), testing(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of this data-bearing link Dubuc, et al. Standards Track [Page 54] RFC 4631 LMP-MIB Module September 2006 (active FSM)." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpDataLinkEntry 7 } lmpDataLinkPassiveOperStatus OBJECT-TYPE SYNTAX INTEGER { upAlloc(1), upFree(2), down(3), psvTst(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual operational status of this data-bearing link (passive FSM)." REFERENCE "Link Management Protocol, RFC 4204." ::= { lmpDataLinkEntry 8 } lmpDataLinkRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. None of the writable objects in a row can be changed if the status is active(1). All read-create objects must have valid and consistent values before the row can be activated." ::= { lmpDataLinkEntry 9 } lmpDataLinkStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the lmpDataLinkTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." DEFVAL { nonVolatile } ::= { lmpDataLinkEntry 10 } -- End of lmpDataLinkTable -- LMP Data Link Performance Table Dubuc, et al. Standards Track [Page 55] RFC 4631 LMP-MIB Module September 2006 lmpDataLinkPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF LmpDataLinkPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the data-bearing links LMP performance counters." ::= { lmpObjects 17 } lmpDataLinkPerfEntry OBJECT-TYPE SYNTAX LmpDataLinkPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table contains information about the LMP performance counters for the data-bearing links. lmpDataLinkDiscontinuityTime is used to indicate potential discontinuity for all counter objects in this table." INDEX { ifIndex } ::= { lmpDataLinkPerfTable 1 } LmpDataLinkPerfEntry ::= SEQUENCE { lmpDataLinkTestReceived Counter32, lmpDataLinkTestSent Counter32, lmpDataLinkActiveTestSuccess Counter32, lmpDataLinkActiveTestFailure Counter32, lmpDataLinkPassiveTestSuccess Counter32, lmpDataLinkPassiveTestFailure Counter32, lmpDataLinkDiscontinuityTime TimeStamp } lmpDataLinkTestReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Test messages that have been received on this data-bearing link." ::= { lmpDataLinkPerfEntry 1 } lmpDataLinkTestSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of Test messages that have been sent on this data-bearing link." ::= { lmpDataLinkPerfEntry 2 } Dubuc, et al. Standards Track [Page 56] RFC 4631 LMP-MIB Module September 2006 lmpDataLinkActiveTestSuccess OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of data-bearing link tests that were successful on the active side of this data- bearing link." ::= { lmpDataLinkPerfEntry 3 } lmpDataLinkActiveTestFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of data-bearing link tests that failed on the active side of this data-bearing link." ::= { lmpDataLinkPerfEntry 4 } lmpDataLinkPassiveTestSuccess OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of data-bearing link tests that were successful on the passive side of this data- bearing link." ::= { lmpDataLinkPerfEntry 5 } lmpDataLinkPassiveTestFailure OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of data-bearing link tests that failed on the passive side of this data-bearing link." ::= { lmpDataLinkPerfEntry 6 } lmpDataLinkDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which one or more of this data-bearing link's counters suffered a discontinuity. The relevant counters are the specific instances associated with this data-bearing link of any Counter32 object contained in the lmpDataLinkPerfTable. If Dubuc, et al. Standards Track [Page 57] RFC 4631 LMP-MIB Module September 2006 no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { lmpDataLinkPerfEntry 7 } -- End of lmpDataLinkPerfTable -- Notification Configuration lmpNotificationMaxRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The LMP notification rate depends on the size of the network, the type of links, the network configuration, the reliability of the network, etc. When this MIB was designed, care was taken to minimize the amount of notifications generated for LMP purposes. Wherever possible, notifications are state driven, meaning that the notifications are sent only when the system changes state. The only notifications that are repeated and that could cause a problem as far as congestion is concerned are the ones associated with data link verification. Without any considerations to handling of these notifications, a problem may arise if the number of data links is high. Since the data link verification notifications can happen only once per data link per link verification interval, the notification rate should be sustainable if one chooses an appropriate link verification interval for a given network configuration. For instance, a network of 100 nodes with 5 links of 128 wavelengths each and a link verification of 1 minute, where no more than 10% of the links failed at any given time, would have 1 notification per second sent from each node, or 100 notifications per second for the whole network. The rest of the notifications are negligible compared to this number. To alleviate the congestion problem, the lmpNotificationMaxRate object can be used to implement a throttling mechanism. It is also possible to enable/disable certain type of notifications. This variable indicates the maximum number of notifications issued per minute. If events occur more rapidly, the implementation may simply fail to Dubuc, et al. Standards Track [Page 58] RFC 4631 LMP-MIB Module September 2006 emit these notifications during that period or may queue them until an appropriate time. A value of 0 means that no throttling is applied and events may be notified at the rate at which they occur. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." ::= { lmpObjects 18 } lmpLinkPropertyNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true(1), then it enables the generation of lmpTeLinkPropertyMismatch and lmpDataLinkPropertyMismatch notifications; otherwise, these notifications are not emitted. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." DEFVAL { false } ::= { lmpObjects 19 } lmpUnprotectedNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true(1), then it enables the generation of lmpUnprotected notifications; otherwise, these notifications are not emitted. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." DEFVAL { false } ::= { lmpObjects 20 } lmpCcUpDownNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true(1), then it enables the generation of lmpControlChannelUp and lmpControlChannelDown notifications; otherwise, these notifications are not emitted. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." DEFVAL { false } ::= { lmpObjects 21 } Dubuc, et al. Standards Track [Page 59] RFC 4631 LMP-MIB Module September 2006 lmpTeLinkNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true(1), then it enables the generation of lmpTeLinkDegraded and lmpTeLinkNotDegraded notifications; otherwise, these notifications are not emitted. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." DEFVAL { false } ::= { lmpObjects 22 } lmpDataLinkNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true(1), then it enables the generation of lmpDataLinkVerificationFailure notification; otherwise, these notifications are not emitted. Implementations should save the value of this object in persistent memory so that it survives restarts or reboot." DEFVAL { false } ::= { lmpObjects 23 } -- Notifications -- Link Property Mismatch Notifications lmpTeLinkPropertyMismatch NOTIFICATION-TYPE OBJECTS { teLinkRemoteIpAddr, teLinkIncomingIfId } STATUS current DESCRIPTION "This notification is generated when a TE link property mismatch is detected on the node. The received remote TE link ID of the misconfigured TE link is represented by either teLinkRemoteIpAddr or teLinkIncomingIfId, depending on whether the TE link is numbered or unnumbered. This notification should not be sent unless lmpLinkPropertyNotificationsEnabled is true(1). It is recommended that this notification be reported only the first time a mismatch is detected. Otherwise, for a given TE link, this notification can occur no more than once per verification interval (lmpGlobalLinkVerificationInterval)." ::= { lmpNotifications 1 } Dubuc, et al. Standards Track [Page 60] RFC 4631 LMP-MIB Module September 2006 lmpDataLinkPropertyMismatch NOTIFICATION-TYPE OBJECTS { lmpDataLinkType, lmpDataLinkRemoteIfId } STATUS current DESCRIPTION "This notification is generated when a data-bearing link property mismatch is detected on the node. lmpDataLinkType is used to identify the local identifiers associated with the data link. (The data link interface index can be used to determine the TE link interface index, as this relationship is captured in the interface stack table.) The remote entity interface ID is the remote entity interface ID received in the LinkSummary message. This notification should not be sent unless lmpLinkPropertyNotificationsEnabled is true(1). It is recommended that this notification be reported only the first time a mismatch is detected. Otherwise, for a given data link, this notification can occur no more than once per verification interval (lmpGlobalLinkVerificationInterval)." ::= { lmpNotifications 2 } -- Neighbor Notification lmpUnprotected NOTIFICATION-TYPE OBJECTS { lmpCcNbrNodeId } STATUS current DESCRIPTION "This notification is generated when there is more than one control channel between LMP neighbors and the last redundant control channel has failed. If the remaining operational control channel fails, then there will be no more control channels between the pair of nodes and all the TE links between the pair of nodes, will go to degraded state. This notification should not be sent unless lmpUnprotectedNotificationsEnabled is set to true(1)." ::= { lmpNotifications 3 } -- Control Channel Notifications lmpControlChannelUp NOTIFICATION-TYPE OBJECTS { lmpCcAdminStatus, lmpCcOperStatus } STATUS current DESCRIPTION "This notification is generated when a control channel transitions to the up operational state. This notification should not be sent unless lmpCcUpDownNotificationsEnabled is true(1)." ::= { lmpNotifications 4 } Dubuc, et al. Standards Track [Page 61] RFC 4631 LMP-MIB Module September 2006 lmpControlChannelDown NOTIFICATION-TYPE OBJECTS { lmpCcAdminStatus, lmpCcOperStatus } STATUS current DESCRIPTION "This notification is generated when a control channel transitions out of the up operational state. This notification should not be sent unless lmpCcUpDownNotificationsEnabled is true(1)." ::= { lmpNotifications 5 } -- TE Link Notification lmpTeLinkDegraded NOTIFICATION-TYPE OBJECTS { lmpTeLinkOperStatus } STATUS current DESCRIPTION "This notification is generated when a lmpTeLinkOperStatus object for a TE link enters the degraded state. This notification should not be sent unless lmpTeLinkNotificationsEnabled is true(1)." ::= { lmpNotifications 6 } lmpTeLinkNotDegraded NOTIFICATION-TYPE OBJECTS { lmpTeLinkOperStatus } STATUS current DESCRIPTION "This notification is generated when a lmpTeLinkOperStatus object for a TE link leaves the degraded state. This notification should not be sent unless lmpTeLinkNotificationsEnabled is true(1)." ::= { lmpNotifications 7 } -- Data-bearing Link Notification lmpDataLinkVerificationFailure NOTIFICATION-TYPE OBJECTS { lmpDataLinkActiveOperStatus, lmpDataLinkPassiveOperStatus } STATUS current DESCRIPTION "This notification is generated when a data-bearing link verification fails. This notification should not be sent unless lmpDataLinkNotificationsEnabled is true(1). For a given data link, this notification can occur no more than once per verification interval (lmpGlobalLinkVerificationInterval)." ::= { lmpNotifications 8 } -- End of notifications Dubuc, et al. Standards Track [Page 62] RFC 4631 LMP-MIB Module September 2006 -- Module compliance lmpCompliances OBJECT IDENTIFIER ::= { lmpConformance 1 } lmpGroups OBJECT IDENTIFIER ::= { lmpConformance 2 } lmpModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that support the configuration and monitoring of LMP MIB." MODULE -- this module MANDATORY-GROUPS { lmpNodeGroup, lmpControlChannelGroup, lmpLinkPropertyCorrelationGroup, lmpPerfGroup, lmpTeLinkGroup, lmpDataLinkGroup } GROUP lmpCcIsNotInterfaceGroup DESCRIPTION "This group is mandatory for devices that support control channels that are not interfaces, in addition to lmpControlChannelGroup. The following constraint applies: lmpCcIsIf must at least be read-only, returning false(2)." GROUP lmpCcIsInterfaceGroup DESCRIPTION "This group is mandatory for devices that support control channels that are interfaces, in addition to lmpControlChannelGroup. The following constraint applies: lmpCcIsIf must at least be read-only, returning true(1)." GROUP lmpLinkVerificationGroup DESCRIPTION "This group is mandatory for devices that support the link verification procedure." GROUP lmpNotificationGroup DESCRIPTION "This group is optional." -- lmpNbrTable OBJECT lmpNbrRowStatus Dubuc, et al. Standards Track [Page 63] RFC 4631 LMP-MIB Module September 2006 SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." -- lmpControlChannelTable OBJECT lmpCcRemoteAddressType SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "Only ipv4(1) and ipv6(2) address types need to be supported for non-point-to-point configurations." OBJECT lmpCcRemoteIpAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "The size of the IP address depends on the address type." OBJECT lmpCcRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." OBJECT lmpCcOperStatus SYNTAX INTEGER { up(1), down(2) } DESCRIPTION "A value of configSnd(3), configRcv(4), active(5), or goingDown(6) need not be supported." -- lmpTeLinkTable OBJECT lmpTeLinkOperStatus SYNTAX INTEGER { up(1), down(2), degraded(5) } DESCRIPTION "The testing(3) and init(4) state need not be supported." OBJECT lmpTeLinkRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." Dubuc, et al. Standards Track [Page 64] RFC 4631 LMP-MIB Module September 2006 -- lmpDataLinkTable OBJECT lmpDataLinkActiveOperStatus SYNTAX INTEGER { upAlloc(1), upFree(2), down(3) } DESCRIPTION "A value of testing(4) need not be supported." OBJECT lmpDataLinkPassiveOperStatus SYNTAX INTEGER { upAlloc(1), upFree(2), down(3) } DESCRIPTION "A value of psvTst(4) need not be supported." OBJECT lmpDataLinkRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notReady(3) and createAndWait(5) is not required." ::= { lmpCompliances 1 } lmpModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that support the monitoring of the LMP MIB." MODULE -- this module -- The mandatory groups have to be implemented -- by all LMP-enabled devices. However, they may all be supported -- as read-only objects in the case where manual -- configuration is not supported. MANDATORY-GROUPS { lmpNodeGroup, lmpControlChannelGroup, lmpLinkPropertyCorrelationGroup, lmpPerfGroup, lmpTeLinkGroup, lmpDataLinkGroup } GROUP lmpCcIsNotInterfaceGroup DESCRIPTION "This group is mandatory for devices that support control channels that are not interfaces, in addition to lmpControlChannelGroup. The following constraint applies: lmpCcIsIf must at least be read-only, returning false(2)." GROUP lmpCcIsInterfaceGroup Dubuc, et al. Standards Track [Page 65] RFC 4631 LMP-MIB Module September 2006 DESCRIPTION "This group is mandatory for devices that support control channels that are interfaces, in addition to lmpControlChannelGroup. The following constraint applies: lmpCcIsIf must at least be read-only, returning true(1)." GROUP lmpLinkVerificationGroup DESCRIPTION "This group is mandatory for devices that support the link verification procedure." GROUP lmpNotificationGroup DESCRIPTION "This group is optional." -- Scalars OBJECT lmpAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpGlobalLinkVerificationInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloIntervalDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloIntervalDefaultMin MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloIntervalDefaultMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloDeadIntervalDefault MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloDeadIntervalDefaultMin Dubuc, et al. Standards Track [Page 66] RFC 4631 LMP-MIB Module September 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloDeadIntervalDefaultMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpNotificationMaxRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- lmpNbrTable OBJECT lmpNbrRetransmitInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpNbrRetryLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpNbrRetransmitDelta MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpNbrRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported." OBJECT lmpNbrStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- lmpControlChannelTable OBJECT lmpCcUnderlyingIfIndex MIN-ACCESS read-only DESCRIPTION Dubuc, et al. Standards Track [Page 67] RFC 4631 LMP-MIB Module September 2006 "Write access is not required." OBJECT lmpCcIsIf MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcNbrNodeId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcRemoteAddressType SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Only ipv4(1) and ipv6(2) address types need to be supported for non-point-to-point configurations." OBJECT lmpCcRemoteIpAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "The size of the IP address depends on the address type." OBJECT lmpCcSetupRole MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcAuthentication MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloIntervalMin MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloIntervalMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcHelloDeadIntervalMin MIN-ACCESS read-only DESCRIPTION Dubuc, et al. Standards Track [Page 68] RFC 4631 LMP-MIB Module September 2006 "Write access is not required." OBJECT lmpCcHelloDeadIntervalMax MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpCcRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported." OBJECT lmpCcOperStatus SYNTAX INTEGER { up(1), down(2) } DESCRIPTION "A value of configSnd(3), configRcv(4), active(5), or goingDown(6) need not be supported." OBJECT lmpCcStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- lmpLinkVerificationTable OBJECT lmpLinkVerifyInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpLinkVerifyDeadInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpLinkVerifyAllLinks MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- lmpTeLinkTable OBJECT lmpTeLinkNbrRemoteNodeId MIN-ACCESS read-only DESCRIPTION "Write access is not required if the link verification Dubuc, et al. Standards Track [Page 69] RFC 4631 LMP-MIB Module September 2006 procedure is enabled." OBJECT lmpTeLinkVerification MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpTeLinkFaultManagement MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpTeLinkDwdm MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpTeLinkOperStatus SYNTAX INTEGER { up(1), down(2), degraded(5) } DESCRIPTION "The testing(3) and init(4) state need not be supported." OBJECT lmpTeLinkRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported." OBJECT lmpTeLinkStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- lmpTeLinkVerificationTable OBJECT lmpLinkVerifyTransmissionRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpLinkVerifyWavelength MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT lmpLinkVerifyRowStatus SYNTAX RowStatus { active(1) } Dubuc, et al. Standards Track [Page 70] RFC 4631 LMP-MIB Module September 2006 MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported." OBJECT lmpLinkVerifyStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- lmpDataLinkTable OBJECT lmpDataLinkAddressType SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Only ipv4(1) and ipv6(2) address types need to be supported for numbered links. For unnumbered links, the unknown(0) address type needs to be supported." OBJECT lmpDataLinkIpAddr SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "The size of the data-bearing link IP address depends on the type of data-bearing link. Data-bearing link IP address size is zero if the link is unnumbered, four if the link IP address is IPv4, and sixteen if the link IP address is IPv6." OBJECT lmpDataLinkRemoteIpAddress SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required if the link verification procedure is enabled." OBJECT lmpDataLinkRemoteIfId MIN-ACCESS read-only DESCRIPTION "Write access is not required if the link verification procedure is enabled." OBJECT lmpDataLinkEncodingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Dubuc, et al. Standards Track [Page 71] RFC 4631 LMP-MIB Module September 2006 OBJECT lmpDataLinkActiveOperStatus SYNTAX INTEGER { upAlloc(1), upFree(2), down(3) } DESCRIPTION "A value of testing(4) need not be supported." OBJECT lmpDataLinkPassiveOperStatus SYNTAX INTEGER { upAlloc(1), upFree(2), down(3) } DESCRIPTION "A value of psvTst(4) need not be supported." OBJECT lmpDataLinkRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported." OBJECT lmpDataLinkStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { lmpCompliances 2 } -- Units of conformance lmpNodeGroup OBJECT-GROUP OBJECTS { lmpAdminStatus, lmpOperStatus, lmpNbrAdminStatus, lmpNbrOperStatus, lmpNbrRowStatus, lmpNbrStorageType, lmpUnprotectedNotificationsEnabled, lmpNotificationMaxRate } STATUS current DESCRIPTION "Collection of objects that represent LMP node configuration." ::= { lmpGroups 1 } lmpControlChannelGroup OBJECT-GROUP OBJECTS { lmpNbrRetransmitInterval, lmpNbrRetryLimit, lmpNbrRetransmitDelta, lmpNbrAdminStatus, Dubuc, et al. Standards Track [Page 72] RFC 4631 LMP-MIB Module September 2006 lmpNbrOperStatus, lmpNbrRowStatus, lmpNbrStorageType, lmpCcHelloIntervalDefault, lmpCcHelloIntervalDefaultMin, lmpCcHelloIntervalDefaultMax, lmpCcHelloDeadIntervalDefault, lmpCcHelloDeadIntervalDefaultMin, lmpCcHelloDeadIntervalDefaultMax, lmpCcNbrNodeId, lmpCcRemoteId, lmpCcRemoteAddressType, lmpCcRemoteIpAddr, lmpCcSetupRole, lmpCcAuthentication, lmpCcHelloInterval, lmpCcHelloIntervalMin, lmpCcHelloIntervalMax, lmpCcHelloIntervalNegotiated, lmpCcHelloDeadInterval, lmpCcHelloDeadIntervalMin, lmpCcHelloDeadIntervalMax, lmpCcHelloDeadIntervalNegotiated, lmpCcOperStatus, lmpCcRowStatus, lmpCcStorageType, lmpCcUpDownNotificationsEnabled } STATUS current DESCRIPTION "Objects that can be used to configure LMP interface." ::= { lmpGroups 2 } lmpCcIsInterfaceGroup OBJECT-GROUP OBJECTS { lmpCcIsIf } STATUS current DESCRIPTION "Objects that can be used to configure control channels that are interfaces." ::= { lmpGroups 3 } lmpCcIsNotInterfaceGroup OBJECT-GROUP OBJECTS { lmpCcUnderlyingIfIndex, lmpCcIsIf, lmpCcLastChange, lmpCcAdminStatus } STATUS current Dubuc, et al. Standards Track [Page 73] RFC 4631 LMP-MIB Module September 2006 DESCRIPTION "Objects that can be used to configure control channels that are not interfaces." ::= { lmpGroups 4 } lmpLinkPropertyCorrelationGroup OBJECT-GROUP OBJECTS { lmpLinkPropertyNotificationsEnabled } STATUS current DESCRIPTION "Collection of objects used to configure the link property correlation procedure." ::= { lmpGroups 5 } lmpLinkVerificationGroup OBJECT-GROUP OBJECTS { lmpGlobalLinkVerificationInterval, lmpLinkVerifyInterval, lmpLinkVerifyDeadInterval, lmpLinkVerifyTransportMechanism, lmpLinkVerifyAllLinks, lmpLinkVerifyTransmissionRate, lmpLinkVerifyWavelength, lmpLinkVerifyRowStatus, lmpLinkVerifyStorageType, lmpDataLinkNotificationsEnabled } STATUS current DESCRIPTION "Collection of objects that represent the link verification procedure configuration." ::= { lmpGroups 6 } lmpPerfGroup OBJECT-GROUP OBJECTS { lmpCcInOctets, lmpCcInDiscards, lmpCcInErrors, lmpCcOutOctets, lmpCcOutDiscards, lmpCcOutErrors, lmpCcConfigReceived, lmpCcConfigSent, lmpCcConfigRetransmit, lmpCcConfigAckReceived, lmpCcConfigAckSent, lmpCcConfigNackSent, lmpCcConfigNackReceived, lmpCcHelloReceived, lmpCcHelloSent, lmpCcBeginVerifyReceived, Dubuc, et al. Standards Track [Page 74] RFC 4631 LMP-MIB Module September 2006 lmpCcBeginVerifySent, lmpCcBeginVerifyRetransmit, lmpCcBeginVerifyAckReceived, lmpCcBeginVerifyAckSent, lmpCcBeginVerifyNackReceived, lmpCcBeginVerifyNackSent, lmpCcEndVerifyReceived, lmpCcEndVerifySent, lmpCcEndVerifyRetransmit, lmpCcEndVerifyAckReceived, lmpCcEndVerifyAckSent, lmpCcTestStatusSuccessReceived, lmpCcTestStatusSuccessSent, lmpCcTestStatusSuccessRetransmit, lmpCcTestStatusFailureReceived, lmpCcTestStatusFailureSent, lmpCcTestStatusFailureRetransmit, lmpCcTestStatusAckReceived, lmpCcTestStatusAckSent, lmpCcLinkSummaryReceived, lmpCcLinkSummarySent, lmpCcLinkSummaryRetransmit, lmpCcLinkSummaryAckReceived, lmpCcLinkSummaryAckSent, lmpCcLinkSummaryNackReceived, lmpCcLinkSummaryNackSent, lmpCcChannelStatusReceived, lmpCcChannelStatusSent, lmpCcChannelStatusRetransmit, lmpCcChannelStatusAckReceived, lmpCcChannelStatusAckSent, lmpCcChannelStatusReqReceived, lmpCcChannelStatusReqSent, lmpCcChannelStatusReqRetransmit, lmpCcChannelStatusRspReceived, lmpCcChannelStatusRspSent, lmpCcCounterDiscontinuityTime, lmpTeInOctets, lmpTeOutOctets, lmpTeBeginVerifyReceived, lmpTeBeginVerifySent, lmpTeBeginVerifyRetransmit, lmpTeBeginVerifyAckReceived, lmpTeBeginVerifyAckSent, lmpTeBeginVerifyNackReceived, lmpTeBeginVerifyNackSent, lmpTeEndVerifyReceived, lmpTeEndVerifySent, Dubuc, et al. Standards Track [Page 75] RFC 4631 LMP-MIB Module September 2006 lmpTeEndVerifyRetransmit, lmpTeEndVerifyAckReceived, lmpTeEndVerifyAckSent, lmpTeTestStatusSuccessReceived, lmpTeTestStatusSuccessSent, lmpTeTestStatusSuccessRetransmit, lmpTeTestStatusFailureReceived, lmpTeTestStatusFailureSent, lmpTeTestStatusFailureRetransmit, lmpTeTestStatusAckReceived, lmpTeTestStatusAckSent, lmpTeLinkSummaryReceived, lmpTeLinkSummarySent, lmpTeLinkSummaryRetransmit, lmpTeLinkSummaryAckReceived, lmpTeLinkSummaryAckSent, lmpTeLinkSummaryNackReceived, lmpTeLinkSummaryNackSent, lmpTeChannelStatusReceived, lmpTeChannelStatusSent, lmpTeChannelStatusRetransmit, lmpTeChannelStatusAckReceived, lmpTeChannelStatusAckSent, lmpTeChannelStatusReqReceived, lmpTeChannelStatusReqSent, lmpTeChannelStatusReqRetransmit, lmpTeChannelStatusRspSent, lmpTeChannelStatusRspReceived, lmpTeCounterDiscontinuityTime, lmpDataLinkTestReceived, lmpDataLinkTestSent, lmpDataLinkActiveTestSuccess, lmpDataLinkActiveTestFailure, lmpDataLinkPassiveTestSuccess, lmpDataLinkPassiveTestFailure, lmpDataLinkDiscontinuityTime } STATUS current DESCRIPTION "Collection of objects used to provide performance information about LMP interfaces and data-bearing links." ::= { lmpGroups 7 } lmpTeLinkGroup OBJECT-GROUP OBJECTS { lmpTeLinkNbrRemoteNodeId, lmpTeLinkVerification, lmpTeLinkFaultManagement, lmpTeLinkDwdm, Dubuc, et al. Standards Track [Page 76] RFC 4631 LMP-MIB Module September 2006 lmpTeLinkOperStatus, lmpTeLinkRowStatus, lmpTeLinkStorageType, lmpTeLinkNotificationsEnabled } STATUS current DESCRIPTION "Objects that can be used to configure TE links." ::= { lmpGroups 8 } lmpDataLinkGroup OBJECT-GROUP OBJECTS { lmpDataLinkType, lmpDataLinkAddressType, lmpDataLinkIpAddr, lmpDataLinkRemoteIpAddress, lmpDataLinkRemoteIfId, lmpDataLinkEncodingType, lmpDataLinkActiveOperStatus, lmpDataLinkPassiveOperStatus, lmpDataLinkRowStatus, lmpDataLinkStorageType } STATUS current DESCRIPTION "Collection of objects that represent data-bearing link configuration." ::= { lmpGroups 9 } lmpNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { lmpTeLinkPropertyMismatch, lmpDataLinkPropertyMismatch, lmpUnprotected, lmpControlChannelUp, lmpControlChannelDown, lmpTeLinkDegraded, lmpTeLinkNotDegraded, lmpDataLinkVerificationFailure } STATUS current DESCRIPTION "Set of notifications defined in this module." ::= { lmpGroups 10 } -- End of LMP-MIB END Dubuc, et al. Standards Track [Page 77] RFC 4631 LMP-MIB Module September 2006 10. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: - Unauthorized changes to the lmpNbrTable, lmpControlChannelTable, lmpTeLinkTable, and lmpDataLinkTable may disrupt allocation of resources in the network. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: - The lmpNbrTable exposes the network provider's node IP addresses. - lmpControlChannelTable exposes the network provider's control network. - lmpDataLinkTable exposes the network provider's data network. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Dubuc, et al. Standards Track [Page 78] RFC 4631 LMP-MIB Module September 2006 11. Contributors Sudheer Dharanikota EMail: sudheer@ieee.org 12. Acknowledgements The general structure of this document has been modeled around the MPLS Label Switching Router (LSR) MIB [RFC3813]. The authors wish to thank Dmitry Ryumkin, Baktha Muralidharan and George Wang. Thanks to Tom Petch for spotting inconsistencies in RFC 4327 and to Bert Wijnen for document review. 13. IANA Considerations No new IANA actions are requested in this document. All IANA actions from RFC 4327 still hold and are reproduced here for information. Note that new assignments can only be made via a Standards Action as specified in [RFC2434]. 13.1. IANA Considerations for LMP ifType The IANA has assigned 227 ifType for LMP interfaces. 13.2. IANA Considerations for LMP-MIB The IANA has assigned { transmission 227 } to the LMP-MIB module specified in this document. 14. Changes from RFC 4327 to RFC 4631 The following changes have been made relative to RFC 4327. a. Show that this document obsoletes RFC 4327. b. Indicate in Abstract that this document provides minor corrections to RFC 4327. c. Correct use of TruthValue settings such that True is always 1, and False is always 2. d. Update to acknowledgements section. e. Note in IANA section to show no further action required. f. Remove identification of RFC 4327 and request RFC Editor to insert new RFC number. g. Update timestamps. Dubuc, et al. Standards Track [Page 79] RFC 4631 LMP-MIB Module September 2006 h. Update author information. i. Added punctuation to REFERENCE clauses. j. Update Revision History clause. k. Add this section. l. Remove square braces from references to external documents from within the MIB module itself. m. Minor editorial corrections to text and DESCRIPTIONS clauses. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005. Dubuc, et al. Standards Track [Page 80] RFC 4631 LMP-MIB Module September 2006 [RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, October 2005. [RFC4209] Fredette, A. and J. Lang, "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC 4209, October 2005. [RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005. 15.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. Dubuc, et al. Standards Track [Page 81] RFC 4631 LMP-MIB Module September 2006 Authors' Addresses Martin Dubuc EMail: dubuc.consulting@sympatico.ca Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 EMail: tnadeau@cisco.com Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101 EMail: jplang@ieee.org Evan McGinnis Hammerhead Systems 640 Clyde Court Mountain View, CA 94043 EMail: emcginnis@hammerheadsystems.com Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Dubuc, et al. Standards Track [Page 82] RFC 4631 LMP-MIB Module September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Dubuc, et al. Standards Track [Page 83] snmp-mibs-downloader-1.1/mibrfcs/rfc4639.txt0000644000000000000000000055747411402176072015616 0ustar Network Working Group R. Woundy Request for Comments: 4639 Comcast Cable Obsoletes: 2669 K. Marez Category: Standards Track Motorola December 2006 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems 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. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems. This memo obsoletes RFC 2669. Woundy & Marez Standards Track [Page 1] RFC 4639 DOCSIS Cable Device MIB December 2006 Table of Contents 1. The Internet-Standard Management Framework ......................3 2. Glossary ........................................................3 2.1. CATV .......................................................3 2.2. CM or Cable Modem ..........................................3 2.3. CMTS or Cable Modem Termination System .....................3 2.4. DOCSIS or Data-Over-Cable Service Interface Specification ..3 2.5. Downstream .................................................4 2.6. Head-End ...................................................4 2.7. Media Access Control (MAC) Packet ..........................4 2.8. RF .........................................................4 2.9. Simple Network Management Protocol (SNMP) ..................4 2.10. Upstream ..................................................4 3. Introduction ....................................................4 3.1. Structure of the MIB .......................................5 3.1.1. IMPORTed MIB Modules and REFERENCE Clauses ..........6 3.1.2. Persistence Model for Cable Modems ..................6 3.1.3. IPv4 Compliance .....................................6 3.2. Management Requirements ....................................7 3.2.1. Handling of Software Upgrades .......................7 3.2.2. Events and Notifications ............................8 3.2.3. Notification Throttling .............................8 3.2.3.1. Notification Rate Throttling ...............8 3.2.3.2. Limiting the Notification Rate .............9 3.3. Protocol Filters ...........................................9 3.3.1. Inbound LLC Filters: docsDevFilterLLCTable .........10 3.3.2. Special Filters ....................................11 3.3.2.1. IP Spoofing Filters: docsDevCpeTable, docsDevCpeInetTable ......11 3.3.2.2. SNMP Access Filters: docsDevNmAccessTable ......................11 3.3.3. IP Filtering: docsDevFilterIpTable .................12 3.3.4. Outbound LLC Filters ...............................13 4. Definitions ....................................................13 5. Acknowledgements ...............................................78 5.1. Revision Descriptions .....................................78 6. Security Considerations ........................................79 7. IANA Considerations ............................................82 8. References .....................................................83 8.1. Normative References ......................................83 8.2. Informative References ....................................85 Woundy & Marez Standards Track [Page 2] RFC 4639 DOCSIS Cable Device MIB December 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Glossary The terms in this document are derived either from normal cable system usage, or from the documents associated with the Data-Over- Cable Service Interface Specification (DOCSIS) process. 2.1. CATV Originally "Community Antenna Television", now used to refer to any cable or hybrid fiber and cable system used to deliver video signals to a community. 2.2. CM or Cable Modem A CM acts as a "slave" station in a DOCSIS-compliant cable data system. 2.3. CMTS or Cable Modem Termination System A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS-compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs. 2.4. DOCSIS or Data-Over-Cable Service Interface Specification A term referring to the ITU-T Recommendation J.112 [ITU-T_J.112], Annex B, standard for cable modem systems. [RFI1.0] [RFI1.1] [RFI2.0] Woundy & Marez Standards Track [Page 3] RFC 4639 DOCSIS Cable Device MIB December 2006 2.5. Downstream The direction from the head-end towards the subscriber. 2.6. Head-End The origination point in most cable systems of the subscriber video signals. Generally, also the location of the CMTS equipment. 2.7. Media Access Control (MAC) Packet A DOCSIS Packet Data Unit. 2.8. RF Radio Frequency. 2.9. Simple Network Management Protocol (SNMP) Protocol used for network access to Management Information Base (MIB) objects. The three most commonly used versions are Version 1 (SNMPv1), Version 2 (SNMPv2c), and Version 3 (SNMPv3). 2.10. Upstream The direction from the subscriber towards the head-end. 3. Introduction This MIB module provides a set of objects required for the management of DOCSIS-compliant Cable Modems (CM) and Cable Modem Termination Systems (CMTS). The specification is derived from the DOCSIS Radio Frequency Interface specification [RFI1.0]. Please note that the DOCSIS 1.0 standard only required that Cable Modems implement SNMPv1 and to process Internet Protocol Version 4 (IPv4) customer traffic. Design choices in the original version of this MIB module reflected those requirements. DOCSIS 1.1 [RFI1.1] and DOCSIS 2.0 [RFI2.0] require support for SNMPv3, as well as for SNMPv1 and SNMPv2c, and the changes in this MIB module over the previous proposed standard version reflect those additional requirements. Future versions of DOCSIS, starting with DOCSIS 3.0 [MULPI3.0], are expected to require support for the Internet Protocol Version 6 (IPv6) as both a Customer Premise Equipment (CPE) protocol and one supported by the network elements of the DOCSIS CMTS/CM system. Woundy & Marez Standards Track [Page 4] RFC 4639 DOCSIS Cable Device MIB December 2006 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3.1. Structure of the MIB This MIB module is structured into seven components. A component contains one or more MIB groups related by deprecation or logical extension. o The docsDevBaseGroup extends the MIB-II 'system' group of RFC3418 [RFC3418] with objects needed for cable device system management. Related to this group is the docsDevBaseIgmpGroup (enabling Internet Group Management Protocol (IGMP) status and control) and the docsDevBaseMaxCpeGroup (managing the maximum number of CPEs permitted access through the cable modem). o The docsDevNmAccessGroup and the docsDevNmAccessExtGroup provide a minimum level of SNMP access security (see Section 2.7 of [OSSI1.0], Section 2 of [OSSI1.1], and Section 5 of [OSSI2.0]). With the completion of the SNMP coexistence document, RFC 3584 [RFC3584], these groups have been deprecated in this version of the MIB. o The docsDevSoftwareGroup, updated by the docsDevSoftwareGroupV2, provides information for network-downloadable software upgrades. See "Handling of Software Upgrades", below. o The docsDevServerGroup, updated by the docsDevServerGroupV2, provides information about the progress of the interaction between the CM or CMTS and various provisioning servers. o The docsDevEventGroup, updated by the docsDevEventGroupV2, provides control and logging for event reporting. With the addition of the SNMP Notification MIB, RFC 3413 [RFC3413], and Notification Log MIB, RFC 3014 [RFC3014], which cover event reporting, the objects in this MIB module have been modified to allow for the usage of these RFCs. o The docsDevFilterGroup configures filters at the link layer and IP layer for bridged data traffic. This group has been deprecated in this version of the MIB in favor of the docsDevFilterLLCGroup, and by groups from the Differentiated Services MIB [RFC3289] -- specifically, the groups representing the Data Path, Classifier, and Actions tables from that MIB. Woundy & Marez Standards Track [Page 5] RFC 4639 DOCSIS Cable Device MIB December 2006 o The docsDevCpeGroup, updated by the docsDevInetCpeGroup, provides control over which IP addresses may be used by CPEs (e.g., PCs) serviced by a given cable modem. This provides anti-spoofing control at the point of origin for a large cable modem system. This group is separate from docsDevFilter, primarily as this group is only implemented on the Cable Modem (CM) and MUST NOT be implemented on the Cable Modem Termination System (CMTS). 3.1.1. IMPORTed MIB Modules and REFERENCE Clauses This MIB module IMPORTs definitions normatively from the following MIB modules, beyond [RFC2578], [RFC2579], and [RFC2580]: INET- ADDRESS-MIB [RFC4001], SNMP-FRAMEWORK-MIB [RFC3411], IF-MIB [RFC2863], RMON2-MIB [RFC4502], and DIFFSERV-MIB [RFC3289]. This MIB module also includes DESCRIPTION and REFERENCE clauses that normatively refer to [RFC868], [RFC3617], [RFI1.0], [RFI1.1], [RFI2.0], [OSSI1.1], and [OSSI2.0]. 3.1.2. Persistence Model for Cable Modems Most of the tables in this MIB module (e.g., docsDevNmAccessTable, docsDevFilterLLCTable) are specified not to let objects persist across reboots. The expectation (and current operational practice) is that upon reboot, these tables are cleared and repopulated from the DOCSIS configuration file supplied by the cable operator. This approach enables a cable modem to adapt to the current cable operator's environment, which in turn enables cable modem portability across different cable operators. A notable exception to the persistence model is docsDevEventTable, since it is useful to maintain a record of events across reboots for debugging purposes. 3.1.3. IPv4 Compliance Please note that the compliance statements in this version of the MIB module require support only for IPv4 addresses. That is because the current versions of the DOCSIS protocols (1.0, 1.1, and 2.0) are not IPv6 capable. Although support for IPv6 will require changes to the DOCSIS protocols, it is expected that the only changes needed to the MIB module itself will be the addition of new compliance statements that mandate support for IPv6 addresses. Woundy & Marez Standards Track [Page 6] RFC 4639 DOCSIS Cable Device MIB December 2006 3.2. Management Requirements 3.2.1. Handling of Software Upgrades The Cable Modem software upgrade process is documented in [RFI1.0]. From a network management station, the operator o sets docsDevSwServer to the address of the Trivial File Transfer Protocol (TFTP) server for software upgrades; o sets docsDevSwFilename to the file pathname of the software upgrade image; and o sets docsDevSwAdminStatus to upgrade-from-mgt. Although DOCSIS only specifies the implementation of the TFTP protocol [RFC1350] for file transfers, other functional entities embedded within the cable device (particularly a PacketCable Multimedia Terminal Adapter [MTA-PROV]) specify the optional implementation of the Hyper Text Transfer Protocol (HTTP) [RFC1945] and [RFC2616] for file transfers. The value of the docsDevSwServerTransportProtocol object determines which protocol is used for SNMP-initiated software upgrade. One reason for the SNMP-initiated upgrade is to allow loading of a temporary software image (e.g., special diagnostic software) that differs from the software normally used on that device without changing the provisioning database. Note that software upgrades should not be accepted blindly by the cable device. The cable device may refuse an upgrade if o the download is incomplete; o the file contents are incomplete or damaged; or o the software is not intended for that hardware device (this may include the case of a feature set that has not been purchased for this device). A cable device that implements the code verification mechanisms of [BPIPLUS] verifies the source and integrity of the downloaded image by validating one or more Code Verification Signatures that are bundled within the software upgrade. Woundy & Marez Standards Track [Page 7] RFC 4639 DOCSIS Cable Device MIB December 2006 3.2.2. Events and Notifications This MIB module provides control facilities for reporting events through syslog [RFC3164], notifications (traps and informs), and non-volatile logging. Additional controls allow the agent to use the SNMP Notification MIB [RFC3413] and Notification Log MIB [RFC3014] for event notification. The conventions for event reporting are outside the scope of this document. The definition and coding of common DOCSIS notifications can be found in [RFC4547]. 3.2.3. Notification Throttling The CM and CMTS MUST provide support for notification message throttling as described below. The network operator can employ notification rate throttling or notification limiting by manipulating the appropriate MIB variables. 3.2.3.1. Notification Rate Throttling Network operators may employ either of two rate control methods. In the first method, the device ceases to send notifications when the rate exceeds the specified maximum message rate. It resumes sending notifications only if reactivated by a network management station request. In the second method, the device resumes sending notifications when the rate falls below the specified maximum message rate. The network operator configures the specified maximum message rate by setting the measurement interval (in seconds), and the maximum number of notifications to be transmitted within the measurement interval. The operator can query the operational throttling state (to determine whether notifications are enabled or blocked by throttling) of the device, as well as query and set the administrative throttling state (to manage the rate control method) of the device. Woundy & Marez Standards Track [Page 8] RFC 4639 DOCSIS Cable Device MIB December 2006 3.2.3.2. Limiting the Notification Rate Network operators may wish to limit the number of notifications sent by a device over a specified time period. The device ceases to send notifications when the number of notifications exceeds the specified threshold. It resumes sending notifications only when the measurement interval has passed. The network operator defines the maximum number of notifications he is willing to handle and sets the measurement interval to a large number (in hundredths of a second). For this case, the administrative throttling state is set to stop at a threshold that is the maximum number of notifications. See "Techniques for Managing Asynchronously Generated Alerts" [RFC1224] for additional technical motivations. 3.3. Protocol Filters The Cable Device MIB provides objects for both Link Layer Control (LLC) and IP protocol filters. The LLC protocol filter entries can be used to limit CM forwarding to a restricted set of network-layer protocols (such as IP, Internetwork Packet Exchange (IPX), Network Basic Input/Output System (NetBIOS), and Appletalk). The IP protocol filter entries can be used to restrict upstream or downstream traffic according to source and destination IP addresses, transport-layer protocols (such as Transport Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP)), and source and destination TCP/UDP port numbers. In general, a cable modem applies filters (or, more properly, classifiers) in an order appropriate to the layering model. Specifically, the inbound MAC (or LLC) layer filters are applied first, then the "special" filters, then the IP layer inbound filters, then the IP layer outbound filters, and then any final LLC outbound filters. Woundy & Marez Standards Track [Page 9] RFC 4639 DOCSIS Cable Device MIB December 2006 ***************** * LLC Filter In * ***************** | v ******************* * Special Filters * * | * * V * * ************ * * * IP Spoof * * * ************ * * | * * v * * *************** * * * SNMP Access * * * *************** * * | * ******************* | v **************** * IP Filter In * **************** | v ***************** * IP Filter Out * ***************** | v ****************** * LLC Filter Out * ****************** 3.3.1. Inbound LLC Filters: docsDevFilterLLCTable The inbound LLC (or MAC or level-2) filters are contained in the docsDevFilterLLCTable and are applied to level-2 frames entering the cable modem from either the RF MAC interface or from one of the CPE interfaces (physical or logical). These filters are used to prohibit the processing and forwarding of certain types of level-2 traffic that may be disruptive to the network. The filters, as currently specified, can be set to cause the modem either to drop frames that match at least one filter, or to process a frame that matches at least one filter. Some examples of possible configurations would be to permit only IP (and ARP) traffic, or to drop NetBIOS traffic. Woundy & Marez Standards Track [Page 10] RFC 4639 DOCSIS Cable Device MIB December 2006 3.3.2. Special Filters Special filters are applied after the packet is accepted from the MAC layer by the IP module, but before any other processing is done. They are filters that apply only to a very specific class of traffic. 3.3.2.1. IP Spoofing Filters: docsDevCpeTable, docsDevCpeInetTable IP spoofing filters are applied to packets entering the modem from one of the CPE interfaces and are intended to prevent a subscriber from stealing or misusing IP addresses that were not assigned to the subscriber. If the filters are active (enabled), the source address of the IP packet must match at least one IP address in one of these two tables (docsDevCpeTable or docsDevCpeInetTable), or it is discarded without further processing. To prevent potential implementation ambiguity, the device consults the docsDevCpeTable for the IP packet source address before consulting the docsDevCpeInetTable. The table can be automatically populated where the first N different IP addresses seen from the CPE side of the cable modem are used to populate the table automatically. The spoofing filters are specified in the docsDevCpeTable and the docsDevCpeInetTable, and the policy for automatically creating filters in those tables is controlled by docsDevCpeEnroll and docsDevMaxCpe, as well as by the network management agent. Similar IP spoofing filter controls are defined for CMTS implementation in the Subscriber Management MIB [RFC4036]. 3.3.2.2. SNMP Access Filters: docsDevNmAccessTable The SNMP access filters are applied to SNMP packets entering from any interface and destined for the cable modem. If the packets enter from a CPE interface, the SNMP filters are applied after the IP spoofing filters. The filters only apply to SNMPv1 or SNMPv2c traffic and are not consulted for SNMPv3 traffic (and need not be implemented by a v3-only agent). SNMPv3 access control is specified in the User Security Model MIB, in [RFC3414]. With the completion of the SNMP coexistence document, RFC 3584 [RFC3584], docsDevNmAccess table has been deprecated in this version of the MIB. See the body of the MIB for the description of how agents should handle the interaction between RFC 3584 MIBs and this MIB. Woundy & Marez Standards Track [Page 11] RFC 4639 DOCSIS Cable Device MIB December 2006 3.3.3. IP Filtering: docsDevFilterIpTable The IP Filtering table acts as a classifier table. Each row in the table describes a template against which IP packets are compared. The template includes source and destination addresses (and their associated masks), upper level protocol (e.g., TCP, UDP), source and destination port ranges, and Terms of Service (ToS) values. A row also contains interface and traffic direction match values that have to be considered in combination. All columns of a particular row must match the appropriate fields in the packet and must match the interface and direction items for the packet to result in a match to the packet. When classifying a packet, each table is scanned, beginning with the lowest number filter. If the agent finds a match, it applies the group of policies specified. If the matched filter has the continue bit set, the agent continues the scan possibly matching additional filters and applying additional policies. For example, this allows the agent to take one set of actions for the 24.0.16/255.255.255.0 group and one set of actions for telnet packets to/from 24.0.16.30, and these sets of actions may not be mutually exclusive. Once a packet is matched, one of three actions happen according to the setting of docsDevFilterIpControl in the row. The packet may be dropped, in which case no further processing is required. The packet may be accepted, and processing of the packet continues. Lastly, the packet may have a set of policy actions applied to it. If docsDevFilterIpContinue is set to true, scanning of the table continues and additional matches may result. When a packet matches and docsDevFilterIpControl in the filter matched is set to 'policy', the value of docsDevFilterIpPolicyId is used as a selector into the docsDevFilterPolicyTable. The first level of indirection may result in zero or more actions being taken according to the match. The docsDevFilterPolicyTable is scanned in row order, and all rows where docsDevFilterPolicyId equals docsDevFilterIpPolicyId have the action specified by the docsDevFilterPolicyValue 'executed'. For an example of the use of these IP Filtering MIB tables, see [RFC2669]. The IP Filtering table and related tables have been deprecated in this version of the MIB in favor of the Data Path, Classifier, and Action tables from the Differentiated Services MIB [RFC3289]. See the body of the MIB for the description of how agents should handle the interaction between RFC 3289 MIBs and this MIB module. Woundy & Marez Standards Track [Page 12] RFC 4639 DOCSIS Cable Device MIB December 2006 3.3.4. Outbound LLC Filters Lastly, any outbound LLC filters are applied to the packet just prior to its being emitted on the appropriate interface. This MIB module does not specify any outbound LLC filters, but section 3 of the DOCSIS Quality of Service (QoS) MIB, [RFC4323], includes outbound LLC filtering requirements. 4. Definitions DOCS-CABLE-DEVICE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Unsigned32, Counter32, Integer32, zeroDotZero, mib-2 FROM SNMPv2-SMI -- RFC 2578 RowStatus, RowPointer, DateAndTime, TruthValue, StorageType FROM SNMPv2-TC -- RFC 2579 InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC 4001 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF -- RFC 2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 InterfaceIndexOrZero FROM IF-MIB -- RFC 2863 ZeroBasedCounter32 FROM RMON2-MIB -- RFC 4502 diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBDscpMarkActGroup, diffServMIBCounterGroup, diffServMIBAlgDropGroup, Woundy & Marez Standards Track [Page 13] RFC 4639 DOCSIS Cable Device MIB December 2006 diffServDataPathStatus, diffServClfrStatus, diffServClfrElementStatus, diffServMultiFieldClfrAddrType, diffServMultiFieldClfrSrcAddr, diffServMultiFieldClfrDstAddr, diffServAlgDropStatus, diffServDataPathStorage, diffServClfrStorage, diffServClfrElementStorage, diffServMultiFieldClfrStorage, diffServActionStorage, diffServCountActStorage, diffServAlgDropStorage, diffServAlgDropType FROM DIFFSERV-MIB; -- RFC 3289 docsDev MODULE-IDENTITY LAST-UPDATED "200612200000Z" -- December 20, 2006 ORGANIZATION "IETF IP over Cable Data Network Working Group" CONTACT-INFO " Rich Woundy Postal: Comcast Cable 27 Industrial Avenue Chelmsford, MA 01824 U.S.A. Phone: +1 978 244 4010 E-mail: richard_woundy@cable.comcast.com Kevin Marez Postal: Motorola Corporation 6450 Sequence Drive San Diego, CA 92121 U.S.A. Phone: +1 858 404 3785 E-mail: kevin.marez@motorola.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, richard_woundy@cable.comcast.com Jean-Francois Mule, jf.mule@cablelabs.com" DESCRIPTION "This is the MIB Module for DOCSIS-compliant cable modems Woundy & Marez Standards Track [Page 14] RFC 4639 DOCSIS Cable Device MIB December 2006 and cable-modem termination systems. Copyright (C) The IETF Trust (2006). This version of this MIB module was published in RFC 4639; for full legal notices see the RFC itself." REVISION "200612200000Z" -- December 20, 2006 DESCRIPTION "Second version, published as RFC 4639. Modifications to this MIB module since RFC 2669 include: - Deprecation of the docsDevFilter group in favor of the DiffServ MIB groups, to enable support for IPv6 filtering and DiffServ Code Point (DSCP) marking. - Deprecation of the docsDevCpeGroup in favor of the docsDevCpeInetGroup, to enable support of IPv6. - Addition of various InetAddress objects to enable support of IPv6. - Deprecation of docsDevNmAccessTable in favor of SNMP Coexistence and SNMPv3 -- yet adding docsDevNmAccessTrapVersion and clarifying docsDevNmAccessIp for current use of this table, - Addition of docsDevIgmpModeControl for management and control of the IGMP mode of operation, - Addition of docsDevMaxCpe for management of the maxmium number of CPEs permitted access through a cable modem, - Addition of docsDevSwServerTransportProtocol, and modifications to docsDevSoftware object DESCRIPTIONS, to enable software downloads via either TFTP or HTTP, - Replacement of docsDevEvThrottleInhibited with docsDevEvThrottleThresholdExceeded to simplify event threshold management, - Modification of docsDevEvReporting to enable local logging to the internal volatile log, and not to the internal non-volatile log, - Modification of the compliance statement to make the docsDevCpe objects optional - Created placeholders for two OIDs in the docsDevFilterPolicyTable that were never used - Modified the DESCRIPTION of docsDevSwServerTransportProtocol and docsDevSwServerAddressType to address the dependence between each object - Added a reference to docsDevServerConfigTftpAddress - Clarified the scope of notifications that are covered by docsDevEvThrottleThreshold - Clarified an error condition that could occur when Woundy & Marez Standards Track [Page 15] RFC 4639 DOCSIS Cable Device MIB December 2006 doing a SET to docsDevEvReporting - Defined each of the enumerated types for both docsDevEvLevel and docsDevEvPriority - Added UNITS clause to docsDevFilterLLCMatches, docsDevFilterIpMatches, docsDevMaxCpe, docsDevEvThrottleThreshold and docsDevEvCounts. - Added REFERENCE clause to docsDevFilterIpProtocol - Modified DESCRIPTION of docsDevCpeInetAddr to be more protocol-neutral - Removed the enumerated value (1) from both docsDevCpeInetSource and docsDevCpeSource - Covered additional read-write and read-create objects in the Security Considerations section - Modified the default value of docsDevNmAccessIpMask to be consistent with OSSI specification - Modified the SYNTAX of docsDevNmAccessCommunity and docsDevNmAccessInterfaces in the Conformance Statement section - Added SYNTAX clause to docsDevEvReporting in the Conformance Statement section - Modified SYNTAX clause of docsDevEvReporting to move new enumerated type to byte boundary - Added references to DOCSIS 2.0 specifications to multiple objects - Clarified non-persistency across reboots for all tables - Clarified functionality of docsDevSw objects as they relate to docsDevSwOperStatus - Clarified enumerated types (9) and (10) for docsDevServerBootState - Defined the state of unknown(0) for the following objects: docsDevServerDhcpAddressType, docsDevServerTimeAddressType, docsDevServerConfigTftpAddressType and docsDevServerConfigTftpAddressType - Modified the value in docsDevFilterIpDaddr to be consistent with the SYNTAX - Specified which rows could be modified in an active row for docsDevFilterPolicyStatus - Defined the term 'manually' in docsDevCpeEnroll - Clarified the description for docsDevFilterTosOrMask - Covered the case of a non-existent row for docsDevFilterPolicyPtr - Added DEFVAL clauses for multiple objects - Replaced docsDevNotification OBJECT IDENTIFIER with docsDevNotifications to address possible compatibility issues Woundy & Marez Standards Track [Page 16] RFC 4639 DOCSIS Cable Device MIB December 2006 - Added support for the usage of RFC 3413 and RFC 3014 as event notification mechanisms - Removed docsDevFilterPolicyObsoleteGroup - Added stdInterface(9) type to docsDevEvReporting to support the usage of RFC3413 and RFC3014 - Modified DESCRIPTION for docsDevMaxCpe" REVISION "199908190000Z" DESCRIPTION "Initial version, published as RFC 2669." ::= { mib-2 69 } docsDevMIBObjects OBJECT IDENTIFIER ::= { docsDev 1 } docsDevBase OBJECT IDENTIFIER ::= { docsDevMIBObjects 1 } -- -- For the following object, there is no concept in the -- RFI specification corresponding to a backup CMTS. The -- enumeration is provided here in case someone is able -- to define such a role or device. -- docsDevRole OBJECT-TYPE SYNTAX INTEGER { cm(1), cmtsActive(2), cmtsBackup(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current role of this device. cm(1) is a Cable Modem, cmtsActive(2) is a Cable Modem Termination System that is controlling the system of cable modems, and cmtsBackup(3) is a CMTS that is currently connected but is not controlling the system (not currently used). In general, if this device is a 'cm', its role will not change during operation or between reboots. If the device is a 'cmts' it may change between cmtsActive and cmtsBackup and back again during normal operation. NB: At this time, the DOCSIS standards do not support the concept of a backup CMTS, but cmtsBackup is included for completeness." ::= { docsDevBase 1 } Woundy & Marez Standards Track [Page 17] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevDateTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-write STATUS current DESCRIPTION "The current date and time, with time zone information (if known). If the real data and time cannot be determined, this shall represent elapsed time from boot relative to the standard epoch '1970-1-1,0:0:0.0'. In other words, if this agent has been up for 3 minutes and not been able to determine what the actual date and time are, this object will return the value '1970-1-1,0:03:0.0'." ::= { docsDevBase 2 } docsDevResetNow OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to true(1) causes the device to reset. Reading this object always returns false(2)." ::= { docsDevBase 3 } docsDevSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturer's serial number for this device." ::= { docsDevBase 4 } docsDevSTPControl OBJECT-TYPE SYNTAX INTEGER { stEnabled(1), noStFilterBpdu(2), noStPassBpdu(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls operation of the spanning tree protocol (as distinguished from transparent bridging). If set to stEnabled(1), then the spanning tree protocol is enabled, subject to bridging constraints. Woundy & Marez Standards Track [Page 18] RFC 4639 DOCSIS Cable Device MIB December 2006 If noStFilterBpdu(2), then spanning tree is not active, and Bridge PDUs received are discarded. If noStPassBpdu(3), then spanning tree is not active, and Bridge PDUs are transparently forwarded. Note that a device need not implement all of these options, but that noStFilterBpdu(2) is required." DEFVAL { noStFilterBpdu } ::= { docsDevBase 5 } docsDevIgmpModeControl OBJECT-TYPE SYNTAX INTEGER { passive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the IGMP mode of operation for the CM or CMTS. In passive mode, the device forwards IGMP between interfaces as based on knowledge of Multicast Session activity on the subscriber side interface and the rules defined in the DOCSIS RFI specification. In active mode, the device terminates at and initiates IGMP through its interfaces as based on the knowledge of Multicast Session activity on the subscriber side interface." REFERENCE "DOCSIS RFI 1.1 Specification, Section 3.3.1. and DOCSIS RFI 2.0 Specification, Section 5.3.1." DEFVAL { passive } ::= { docsDevBase 6 } docsDevMaxCpe OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "CPEs" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of CPEs that can be granted access through a CM during a CM epoch. This value can be obtained from the CM configuration file; however, it may be adjusted by the CM according to hardware or software limitations that have been imposed on the implementation." REFERENCE "DOCSIS RFI 1.0 Specification, Appendix C.7.20., and Woundy & Marez Standards Track [Page 19] RFC 4639 DOCSIS Cable Device MIB December 2006 DOCSIS RFI 1.1 Specification, Appendix C.1.1.7. and DOCSIS RFI 2.0 Specification, Appendix C.1.1.7." ::= { docsDevBase 7 } -- -- The following table provides one level of security for access -- to the device by network management stations. -- Note that access is also constrained by the -- community strings and any vendor-specific security. -- docsDevNmAccessTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevNmAccessEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table controls access to SNMP objects by network management stations. If the table is empty, access to SNMP objects is unrestricted. The objects in this table MUST NOT persist across reboots. The objects in this table are only accessible from cable devices that are not capable of operating in SNMP Coexistence mode (RFC 3584) or in SNMPv3 mode (RFC 3410). See the conformance section for details. Note that some devices are required by other specifications (e.g., the DOCSIS OSSIv1.1 specification) to support the legacy SNMPv1/v2c docsDevNmAccess mode for backward compatibility. This table is deprecated. Instead, use the SNMP coexistence MIBs from RFC 3584, the TARGET and NOTIFICATION MIBs from RFC 3413, and the View-Based Access Control Model (VACM) MIBs for all SNMP protocol versions from RFC 3415." ::= { docsDevMIBObjects 2 } docsDevNmAccessEntry OBJECT-TYPE SYNTAX DocsDevNmAccessEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry describing access to SNMP objects by a particular network management station. An entry in this table is not readable unless the management station has read-write permission (either implicit if the table is empty, or explicit through an entry in this table). Entries are ordered by docsDevNmAccessIndex. The first Woundy & Marez Standards Track [Page 20] RFC 4639 DOCSIS Cable Device MIB December 2006 matching entry (e.g., matching IP address and community string) is used to derive access." INDEX { docsDevNmAccessIndex } ::= { docsDevNmAccessTable 1 } DocsDevNmAccessEntry ::= SEQUENCE { docsDevNmAccessIndex Integer32, docsDevNmAccessIp IpAddress, docsDevNmAccessIpMask IpAddress, docsDevNmAccessCommunity OCTET STRING, docsDevNmAccessControl INTEGER, docsDevNmAccessInterfaces OCTET STRING, docsDevNmAccessStatus RowStatus, docsDevNmAccessTrapVersion INTEGER } docsDevNmAccessIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Index used to order the application of access entries." ::= { docsDevNmAccessEntry 1 } docsDevNmAccessIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The IP address (or subnet) of the network management station. The address 0.0.0.0 is defined to mean any Network Management Station (NMS). If traps are enabled for this entry, then the value must be the address of a specific device. Implementations MAY recognize 255.255.255.255 as equivalent to 0.0.0.0." DEFVAL { '00000000'h } ::= { docsDevNmAccessEntry 2 } docsDevNmAccessIpMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The IP subnet mask of the network management stations. If traps are enabled for this entry, then the value must be 0.0.0.0. Implementations MAY recognize 255.255.255.255 as equivalent to 0.0.0.0." Woundy & Marez Standards Track [Page 21] RFC 4639 DOCSIS Cable Device MIB December 2006 DEFVAL { '00000000'h } ::= { docsDevNmAccessEntry 3 } docsDevNmAccessCommunity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The community string to be matched for access by this entry. If set to a zero-length string, then any community string will match. When read, this object SHOULD return a zero-length string." DEFVAL { "public" } ::= { docsDevNmAccessEntry 4 } docsDevNmAccessControl OBJECT-TYPE SYNTAX INTEGER { none(1), read(2), readWrite(3), roWithTraps(4), rwWithTraps(5), trapsOnly(6) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Specifies the type of access allowed to this NMS. Setting this object to none(1) causes the table entry to be destroyed. Read(2) allows access by 'get' and 'get-next' PDUs. ReadWrite(3) allows access by 'set' as well. RoWithtraps(4), rwWithTraps(5), and trapsOnly(6) control distribution of Trap PDUs transmitted by this device." DEFVAL { read } ::= { docsDevNmAccessEntry 5 } -- The syntax of the following object was copied from RFC 1493, -- dot1dStaticAllowedToGoTo. docsDevNmAccessInterfaces OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..32)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Specifies the set of interfaces from which requests from this NMS will be accepted. Each octet within the value of this object specifies a set of eight Woundy & Marez Standards Track [Page 22] RFC 4639 DOCSIS Cable Device MIB December 2006 interfaces, the first octet specifying ports 1 through 8, the second octet specifying interfaces 9 through 16, etc. Within each octet, the most significant bit represents the lowest numbered interface, and the least significant bit represents the highest numbered interface. Thus, each interface is represented by a single bit within the value of this object. If that bit has a value of '1' then that interface is included in the set. Note that entries in this table apply only to link-layer interfaces (e.g., Ethernet and CATV MAC). Bits representing upstream and downstream channel interfaces MUST NOT be set to '1'. Note that if bits corresponding to non-existing interfaces are set, the result is implementation specific. Note that according to the DOCSIS OSSIv1.1 specification, when ifIndex '1' is included in the set, then this row applies to all CPE (customer-facing) interfaces. The size of this object is the minimum required to represent all configured interfaces for this device." ::= { docsDevNmAccessEntry 6 } docsDevNmAccessStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Controls and reflects the status of rows in this table. Rows in this table may be created by either the create-and-go or create-and-wait paradigm. There is no restriction on changing values in a row of this table while the row is active. The following objects MUST have valid values before this object can be set to active: docsDevNmAccessIp, docsDevNmAccessStatus, docsDevNmAccessIpMask, docsDevNmAccessCommunity, docsDevNmAccessControl, and docsDevNmAccessInterfaces." ::= { docsDevNmAccessEntry 7 } docsDevNmAccessTrapVersion OBJECT-TYPE SYNTAX INTEGER { Woundy & Marez Standards Track [Page 23] RFC 4639 DOCSIS Cable Device MIB December 2006 disableSNMPv2trap(1), enableSNMPv2trap(2) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Specifies the TRAP version that is sent to this NMS. Setting this object to disableSNMPv2trap (1) causes the trap in SNMPv1 format to be sent to a particular NMS. Setting this object to enableSNMPv2trap (2) causes the trap in SNMPv2 format be sent to a particular NMS." DEFVAL { disableSNMPv2trap } ::= { docsDevNmAccessEntry 8 } -- -- The following group describes control objects used for downloading -- firmware to a cable device. Procedures for software download are -- described in Section 3.2.1 of the RFC containing this MIB module. -- docsDevSoftware OBJECT IDENTIFIER ::= { docsDevMIBObjects 3 } docsDevSwServer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The address of the TFTP server used for software upgrades. If the TFTP server is unknown or is a non-IPv4 address, return 0.0.0.0. This object is deprecated. See docsDevSwServerAddress for its replacement. This object will have its value modified, given a valid SET to docsDevSwServerAddress." ::= { docsDevSoftware 1 } docsDevSwFilename OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-write STATUS current DESCRIPTION "The filename of the software image to be downloaded via TFTP, or the abs_path (as defined in RFC 2616) of the software image to be downloaded via HTTP. Unless set via SNMP, this is the filename or abs_path specified by the provisioning server during the boot process that corresponds to the software version that Woundy & Marez Standards Track [Page 24] RFC 4639 DOCSIS Cable Device MIB December 2006 is desired for this device. If unknown, the value of this object is the zero-length string." ::= { docsDevSoftware 2 } docsDevSwAdminStatus OBJECT-TYPE SYNTAX INTEGER { upgradeFromMgt(1), allowProvisioningUpgrade(2), ignoreProvisioningUpgrade(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "If set to upgradeFromMgt(1), the device will initiate a TFTP or HTTP software image download. After successfully receiving an image, the device will set its state to ignoreProvisioningUpgrade(3) and reboot. If the download process is interrupted (e.g., by a reset or power failure), the device will load the previous image and, after re-initialization, continue to attempt loading the image specified in docsDevSwFilename. If set to allowProvisioningUpgrade(2), the device will use the software version information supplied by the provisioning server when next rebooting (this does not cause a reboot). When set to ignoreProvisioningUpgrade(3), the device will disregard software image upgrade information from the provisioning server. Note that reading this object can return upgradeFromMgt(1). This indicates that a software download is currently in progress, and that the device will reboot after successfully receiving an image." DEFVAL { allowProvisioningUpgrade } ::= { docsDevSoftware 3 } docsDevSwOperStatus OBJECT-TYPE SYNTAX INTEGER { inProgress(1), completeFromProvisioning(2), completeFromMgt(3), failed(4), other(5) } Woundy & Marez Standards Track [Page 25] RFC 4639 DOCSIS Cable Device MIB December 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "InProgress(1) indicates that a TFTP or HTTP download is underway, either as a result of a version mismatch at provisioning or as a result of a upgradeFromMgt request. No other docsDevSw* objects can be modified in this state. CompleteFromProvisioning(2) indicates that the last software upgrade was a result of version mismatch at provisioning. CompleteFromMgt(3) indicates that the last software upgrade was a result of setting docsDevSwAdminStatus to upgradeFromMgt. Failed(4) indicates that the last attempted download failed, ordinarily due to TFTP or HTTP timeout." REFERENCE "DOCSIS RFI 1.0 Specification, Section 8.2., and DOCSIS RFI 1.1 Specification, Section 10.1. and DOCSIS RFI 2.0 Specification, Section 12.1." ::= { docsDevSoftware 4 } docsDevSwCurrentVers OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The software version currently operating in this device. This string's syntax is that used by the individual vendor to identify software versions. For a CM, this string will describe the current software load. For a CMTS, this object SHOULD contain a human-readable representation either of the vendor specific designation of the software for the chassis, or of the software for the control processor. If neither of these is applicable, the value MUST be a zero-length string." ::= { docsDevSoftware 5 } docsDevSwServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of address of the TFTP or HTTP server used for Woundy & Marez Standards Track [Page 26] RFC 4639 DOCSIS Cable Device MIB December 2006 software upgrades. If docsDevSwServerTransportProtocol is currently set to tftp(1), attempting to set this object to dns(16) MUST result in an error." ::= { docsDevSoftware 6 } docsDevSwServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The address of the TFTP or HTTP server used for software upgrades. If the TFTP/HTTP server is unknown, return the zero- length address string (see the TextualConvention). If docsDevSwServer is also implemented in this agent, this object is tied to it. A set of this object to an IPv4 address will result in also setting the value of docsDevSwServer to that address. If this object is set to an IPv6 address, docsDevSwServer is set to 0.0.0.0. If docsDevSwServer is set, this object is also set to that value. Note that if both are set in the same action, the order of which one sets the other is undefined." ::= { docsDevSoftware 7 } docsDevSwServerTransportProtocol OBJECT-TYPE SYNTAX INTEGER { tftp(1), http(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the transport protocol (TFTP or HTTP) to be used for software upgrades. If the value of this object is tftp(1), then the cable device uses TFTP (RFC 1350) read request packets to download the docsDevSwFilename from the docsDevSwServerAddress in octet mode. If the value of this object is http(2), then the cable device uses HTTP 1.0 (RFC 1945) or HTTP 1.1 (RFC 2616) GET requests sent to host docsDevSwServerAddress to Woundy & Marez Standards Track [Page 27] RFC 4639 DOCSIS Cable Device MIB December 2006 download the software image from path docsDevSwFilename. If docsDevSwServerAddressType is currently set to dns(16), attempting to set this object to tftp(1) MUST result in an error." DEFVAL { tftp } ::= { docsDevSoftware 8 } -- -- The following group describes server access and parameters used -- for initial provisioning and bootstrapping. -- docsDevServer OBJECT IDENTIFIER ::= { docsDevMIBObjects 4 } docsDevServerBootState OBJECT-TYPE SYNTAX INTEGER { operational(1), disabled(2), waitingForDhcpOffer(3), waitingForDhcpResponse(4), waitingForTimeServer(5), waitingForTftp(6), refusedByCmts(7), forwardingDenied(8), other(9), unknown(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "If operational(1), the device has completed loading and processing of configuration parameters, and the CMTS has completed the Registration exchange. If disabled(2), then the device was administratively disabled, possibly by being refused network access in the configuration file. If waitingForDhcpOffer(3), then a Dynamic Host Configuration Protocol (DHCP) Discover has been transmitted, and no offer has yet been received. If waitingForDhcpResponse(4), then a DHCP Request has been transmitted, and no response has yet been received. If waitingForTimeServer(5), then a Time Request has been transmitted, and no response has yet been received. Woundy & Marez Standards Track [Page 28] RFC 4639 DOCSIS Cable Device MIB December 2006 If waitingForTftp(6), then a request to the TFTP parameter server has been made, and no response received. If refusedByCmts(7), then the Registration Request/Response exchange with the CMTS failed. If forwardingDenied(8), then the registration process was completed, but the network access option in the received configuration file prohibits forwarding. If other(9), then the registration process reached a point that does not fall into one of the above categories. If unknown(10), then the device has not yet begun the registration process or is in some other indeterminate state." REFERENCE "DOCSIS RFI 1.0 Specification, Figure 7-1, and DOCSIS RFI 1.1 Specification, Figure 9-1 and DOCSIS RFI 2.0 Specification, Figure 11-1." ::= { docsDevServer 1 } docsDevServerDhcp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The IP address of the DHCP server that assigned an IP address to this device. Returns 0.0.0.0 if DHCP is not used for IP address assignment, or if this agent is not assigned an IPv4 address. This object is deprecated and is replaced by docsDevServerDhcpAddress." ::= { docsDevServer 2 } docsDevServerTime OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The IP address of the Time server (RFC 0868). Returns 0.0.0.0 if the time server IP address is unknown, or if the time server is not an IPv4 server. This object is deprecated and is replaced by Woundy & Marez Standards Track [Page 29] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevServerTimeAddress." ::= { docsDevServer 3 } docsDevServerTftp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The IP address of the TFTP server responsible for downloading provisioning and configuration parameters to this device. Returns 0.0.0.0 if the TFTP server address is unknown or is not an IPv4 address. This object is deprecated and is replaced by docsDevServerConfigTftpAddress." ::= { docsDevServer 4 } docsDevServerConfigFile OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the device configuration file read from the TFTP server. Returns a zero-length string if the configuration file name is unknown." ::= { docsDevServer 5 } docsDevServerDhcpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address of docsDevServerDhcpAddress. If DHCP was not used, this value should return unknown(0)." ::= { docsDevServer 6 } docsDevServerDhcpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The internet address of the DHCP server that assigned an IP address to this device. Returns the zero length octet string if DHCP was not used for IP address assignment." ::= { docsDevServer 7 } Woundy & Marez Standards Track [Page 30] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevServerTimeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address of docsDevServerTimeAddress. If no time server exists, this value should return unknown(0)." ::= { docsDevServer 8 } docsDevServerTimeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet address of the RFC 868 Time server, as provided by DHCP option 4. Note that if multiple values are provided to the CM in DHCP option 4, the value of this MIB object MUST be the Time server address from which the Time of Day reference was acquired as based on the DOCSIS RFI specification. During the period of time where the Time of Day have not been acquired, the Time server address reported by the CM may report the first address value in the DHCP option value or the last server address the CM attempted to get the Time of day value. Returns the zero-length octet string if the time server IP address is not provisioned." REFERENCE "DOCSIS RFI 1.1 Specification, Section 9.2.7. and DOCSIS RFI 2.0 Specification, Section 11.2.7." ::= { docsDevServer 9 } docsDevServerConfigTftpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address of docsDevServerConfigTftpAddress. If no TFTP server exists, this value should return unknown(0)." ::= { docsDevServer 10 } docsDevServerConfigTftpAddress OBJECT-TYPE SYNTAX InetAddress Woundy & Marez Standards Track [Page 31] RFC 4639 DOCSIS Cable Device MIB December 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The internet address of the TFTP server responsible for downloading provisioning and configuration parameters to this device. Returns the zero-length octet string if the config server address is unknown. There are certain security risks that are involved with using TFTP." REFERENCE "RFC 3617, Section 5" ::= { docsDevServer 11 } -- -- Event Reporting -- docsDevEvent OBJECT IDENTIFIER ::= { docsDevMIBObjects 5 } docsDevEvControl OBJECT-TYPE SYNTAX INTEGER { resetLog(1), useDefaultReporting(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to resetLog(1) empties the event log. All data is deleted. Setting it to useDefaultReporting(2) returns all event priorities to their factory-default reporting. Reading this object always returns useDefaultReporting(2)." ::= { docsDevEvent 1 } docsDevEvSyslog OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The IP address of the Syslog server. If 0.0.0.0, either syslog transmission is inhibited, or the Syslog server address is not an IPv4 address. This object is deprecated and is replaced by docsDevEvSyslogAddress." ::= { docsDevEvent 2 } docsDevEvThrottleAdminStatus OBJECT-TYPE Woundy & Marez Standards Track [Page 32] RFC 4639 DOCSIS Cable Device MIB December 2006 SYNTAX INTEGER { unconstrained(1), maintainBelowThreshold(2), stopAtThreshold(3), inhibited(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the transmission of traps and syslog messages with respect to the trap pacing threshold. unconstrained(1) causes traps and syslog messages to be transmitted without regard to the threshold settings. maintainBelowThreshold(2) causes trap transmission and syslog messages to be suppressed if the number of traps would otherwise exceed the threshold. stopAtThreshold(3) causes trap transmission to cease at the threshold and not to resume until directed to do so. inhibited(4) causes all trap transmission and syslog messages to be suppressed. A single event is always treated as a single event for threshold counting. That is, an event causing both a trap and a syslog message is still treated as a single event. Writing to this object resets the thresholding state." DEFVAL { unconstrained } ::= { docsDevEvent 3 } docsDevEvThrottleInhibited OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS deprecated DESCRIPTION "If true(1), trap and syslog transmission is currently inhibited due to thresholds and/or the current setting of docsDevEvThrottleAdminStatus. In addition, this is true(1) when transmission is inhibited because no syslog (docsDevEvSyslog) or trap (docsDevNmAccessEntry) destinations have been set. This object is deprecated and is replaced by docsDevEvThrottleThresholdExceeded." Woundy & Marez Standards Track [Page 33] RFC 4639 DOCSIS Cable Device MIB December 2006 ::= { docsDevEvent 4 } docsDevEvThrottleThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "events" MAX-ACCESS read-write STATUS current DESCRIPTION "Number of events per docsDevEvThrottleInterval permitted before throttling is to occur. A single event, whether the notification could result in messages transmitted using syslog, SNMP, or both protocols, and regardless of the number of destinations, (including zero) is always treated as a single event for threshold counting. For example, an event causing both a trap and a syslog message is still treated as a single event. All system notifications that occur within the device should be taken into consideration when calculating and monitoring the threshold." DEFVAL { 0 } ::= { docsDevEvent 5 } docsDevEvThrottleInterval OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The interval over which docsDevEvThrottleThreshold applies." DEFVAL { 1 } ::= { docsDevEvent 6 } -- -- The following table controls the reporting of the various classes -- of events. -- docsDevEvControlTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevEvControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table allows control of the reporting of event classes. For each event priority, a combination of Woundy & Marez Standards Track [Page 34] RFC 4639 DOCSIS Cable Device MIB December 2006 logging and reporting mechanisms may be chosen. The mapping of event types to priorities is vendor dependent. Vendors may also choose to allow the user to control that mapping through proprietary means. Table entries MUST persist across reboots for CMTS devices and MUST NOT persist across reboots for CM devices." ::= { docsDevEvent 7 } docsDevEvControlEntry OBJECT-TYPE SYNTAX DocsDevEvControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Allows configuration of the reporting mechanisms for a particular event priority." INDEX { docsDevEvPriority } ::= { docsDevEvControlTable 1 } DocsDevEvControlEntry ::= SEQUENCE { docsDevEvPriority INTEGER, docsDevEvReporting BITS } docsDevEvPriority OBJECT-TYPE SYNTAX INTEGER { emergency(1), alert(2), critical(3), error(4), warning(5), notice(6), information(7), debug(8) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The priority level that is controlled by this entry. These are ordered from most (emergency) to least (debug) critical. Each event with a CM or CMTS has a particular priority level associated with it (as defined by the vendor). emergency(1) events indicate vendor-specific fatal hardware or software errors that prevent normal system operation. Woundy & Marez Standards Track [Page 35] RFC 4639 DOCSIS Cable Device MIB December 2006 alert(2) events indicate a serious failure that causes the reporting system to reboot but is not caused by hardware or software malfunctioning. critical(3) events indicate a serious failure that requires attention and prevents the device from transmitting data but that could be recovered without rebooting the system. error(4) and warning(5) events indicate that a failure occurred that could interrupt the normal data flow but that does not cause the device to re-register. notice(6) and information(7) events indicate a milestone or checkpoint in normal operation that could be of particular importance for troubleshooting. debug(8) events are reserved for vendor-specific events. During normal operation, no event more critical than notice(6) should be generated. Events between warning and emergency should be generated at appropriate levels of problems (e.g., emergency when the box is about to crash)." ::= { docsDevEvControlEntry 1 } docsDevEvReporting OBJECT-TYPE SYNTAX BITS { local(0), traps(1), syslog(2), -- The following are extensions to the original set of -- labels. The extensions start at an octet boundary. -- So for bits 3 - 7, one MUST set them to zero on send -- and one MUST ignore them on receipt. localVolatile(8), stdInterface(9) } MAX-ACCESS read-write STATUS current DESCRIPTION "Defines the action to be taken on occurrence of this event class. Implementations may not necessarily support all options for all event classes but at minimum must allow traps and syslogging to be disabled. Woundy & Marez Standards Track [Page 36] RFC 4639 DOCSIS Cable Device MIB December 2006 If the local(0) bit is set, then log to the internal log and update non-volatile store, for backward compatibility with the original RFC 2669 definition. If the traps(1) bit is set, then generate an SNMP trap; if the syslog(2) bit is set, then send a syslog message (assuming that the syslog address is set). If the localVolatile(8) bit is set, then log to the internal log without updating non-volatile store. If the stdInterface(9) bit is set, then the agent ignores all other bits except the local(0), syslog(2), and localVolatile(8) bits. Setting the stdInterface(9) bit indicates that RFC3413 and RFC3014 are being used to control event reporting mechanisms." ::= { docsDevEvControlEntry 2 } docsDevEventTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains a log of network and device events that may be of interest in fault isolation and troubleshooting. If the local(0) bit is set in docsDevEvReporting, entries in this table MUST persist across reboots." ::= { docsDevEvent 8 } docsDevEventEntry OBJECT-TYPE SYNTAX DocsDevEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a network or device event that may be of interest in fault isolation and troubleshooting. Multiple sequential identical events are represented by incrementing docsDevEvCounts and setting docsDevEvLastTime to the current time rather than creating multiple rows. Entries are created with the first occurrence of an event. docsDevEvControl can be used to clear the table. Individual events cannot be deleted." INDEX { docsDevEvIndex } ::= { docsDevEventTable 1 } DocsDevEventEntry ::= SEQUENCE { docsDevEvIndex Integer32, docsDevEvFirstTime DateAndTime, Woundy & Marez Standards Track [Page 37] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevEvLastTime DateAndTime, docsDevEvCounts Counter32, docsDevEvLevel INTEGER, docsDevEvId Unsigned32, docsDevEvText SnmpAdminString } docsDevEvIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Provides relative ordering of the objects in the event log. This object will always increase except when (a) the log is reset via docsDevEvControl, (b) the device reboots and does not implement non-volatile storage for this log, or (c) it reaches the value 2^31. The next entry for all the above cases is 1." ::= { docsDevEventEntry 1 } docsDevEvFirstTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of docsDevDateTime at the time this entry was created." ::= { docsDevEventEntry 2 } docsDevEvLastTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "When an entry reports only one event, this object will have the same value as the corresponding instance of docsDevEvFirstTime. When an entry reports multiple events, this object will record the value that docsDevDateTime had when the most recent event for this entry occurred." ::= { docsDevEventEntry 3 } -- This object was renamed from docsDevEvCount to meet naming -- requirements for Counter32 docsDevEvCounts OBJECT-TYPE SYNTAX Counter32 UNITS "events" Woundy & Marez Standards Track [Page 38] RFC 4639 DOCSIS Cable Device MIB December 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of consecutive event instances reported by this entry. This starts at 1 with the creation of this row and increments by 1 for each subsequent duplicate event." ::= { docsDevEventEntry 4 } docsDevEvLevel OBJECT-TYPE SYNTAX INTEGER { emergency(1), alert(2), critical(3), error(4), warning(5), notice(6), information(7), debug(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The priority level of this event, as defined by the vendor. These are ordered from most serious (emergency) to least serious (debug). emergency(1) events indicate vendor-specific fatal hardware or software errors that prevent normal system operation. alert(2) events indicate a serious failure that causes the reporting system to reboot but that is not caused by hardware or software malfunctioning. critical(3) events indicate a serious failure that requires attention and prevents the device from transmitting data but that could be recovered without rebooting the system. error(4) and warning(5) events indicate that a failure occurred that could interrupt the normal data flow but that does not cause the device to re-register. notice(6) and information(7) events indicate a milestone or checkpoint in normal operation that could be of particular importance for troubleshooting. debug(8) events are reserved for vendor-specific Woundy & Marez Standards Track [Page 39] RFC 4639 DOCSIS Cable Device MIB December 2006 events. During normal operation, no event more critical than notice(6) should be generated. Events between warning and emergency should be generated at appropriate levels of problems (e.g., emergency when the box is about to crash)." ::= { docsDevEventEntry 5 } -- -- It is strongly recommended that implementors follow the CableLabs -- enumerations for docsDevEvId, per the DOCSIS OSSIv1.1 spec -- and follow-on specifications. -- docsDevEvId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "For this product, uniquely identifies the type of event that is reported by this entry." REFERENCE "DOCSIS OSSI 1.1 Specification, Appendix H and DOCSIS OSSI 2.0 Specification, Annex D." ::= { docsDevEventEntry 6 } docsDevEvText OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Provides a human-readable description of the event, including all relevant context (interface numbers, etc.)." ::= { docsDevEventEntry 7 } docsDevEvSyslogAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of address of docsDevEvSyslogAddress. If no syslog server exists, this value should return unknown(0)." DEFVAL { unknown } ::= { docsDevEvent 9 } Woundy & Marez Standards Track [Page 40] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevEvSyslogAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The Internet address of the Syslog server, as provided by DHCP option 7 or set via SNMP management. If the address of the server is set to the zero-length string, the 0.0.0.0 IPv4 address, or the 0: IPv6 address, Syslog transmission is inhibited. Note that if multiple values are provided to the CM in DHCP option 7, the value of this MIB object MUST be the first Syslog server address received. By default at agent boot, this object returns the zero length string." ::= { docsDevEvent 10 } docsDevEvThrottleThresholdExceeded OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If true(1), trap and syslog transmission is currently inhibited due to exceeding the trap/syslog event threshold in the current interval." ::= { docsDevEvent 11 } -- -- Link Level Control Filtering -- docsDevFilter OBJECT IDENTIFIER ::= { docsDevMIBObjects 6 } docsDevFilterLLCUnmatchedAction OBJECT-TYPE SYNTAX INTEGER { discard(1), accept(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "LLC (Link Level Control) filters can be defined on an inclusive or exclusive basis: CMs can be configured to forward only packets matching a set of layer three protocols, or to drop packets matching a set of layer three protocols. Typical use of these filters is to Woundy & Marez Standards Track [Page 41] RFC 4639 DOCSIS Cable Device MIB December 2006 filter out possibly harmful (given the context of a large metropolitan LAN) protocols. If set to discard(1), any L2 packet that does not match at least one filter in the docsDevFilterLLCTable will be discarded. If set to accept(2), any L2 packet that does not match at least one filter in the docsDevFilterLLCTable will be accepted for further processing (e.g., bridging). In other words, if the packet does not match an entry in the table, it takes this action; if it does match an entry in the table, it takes the opposite of this action." DEFVAL { accept } ::= { docsDevFilter 1 } docsDevFilterLLCTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterLLCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of filters to apply to (bridged) LLC traffic. The filters in this table are applied to incoming traffic on the appropriate interface(s) prior to any further processing (e.g., before the packet is handed off for level 3 processing, or for bridging). The specific action taken when no filter is matched is controlled by docsDevFilterLLCUnmatchedAction. Table entries MUST NOT persist across reboots for any device." ::= { docsDevFilter 2 } docsDevFilterLLCEntry OBJECT-TYPE SYNTAX DocsDevFilterLLCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a single filter to apply to (bridged) LLC traffic received on a specified interface. " INDEX { docsDevFilterLLCIndex } ::= { docsDevFilterLLCTable 1 } DocsDevFilterLLCEntry ::= SEQUENCE { docsDevFilterLLCIndex Integer32, docsDevFilterLLCStatus RowStatus, docsDevFilterLLCIfIndex InterfaceIndexOrZero, docsDevFilterLLCProtocolType INTEGER, docsDevFilterLLCProtocol Integer32, docsDevFilterLLCMatches Counter32 } Woundy & Marez Standards Track [Page 42] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevFilterLLCIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index used for the identification of filters (note that LLC filter order is irrelevant)." ::= { docsDevFilterLLCEntry 1 } docsDevFilterLLCStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Controls and reflects the status of rows in this table. There is no restriction on changing any of the associated columns for this row while this object is set to active. Specifying only this object (with the appropriate index) on a CM is sufficient to create a filter row that matches all inbound packets on the ethernet interface and results in the packets being discarded. docsDevFilterLLCIfIndex (at least) must be specified on a CMTS to create a row." ::= { docsDevFilterLLCEntry 2} docsDevFilterLLCIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The entry interface to which this filter applies. The value corresponds to ifIndex for either a CATV MAC or another network interface. If the value is zero, the filter applies to all interfaces. In Cable Modems, the default value is the customer side interface(s). In CMTSs, this object has to be specified to create a row in this table. Note that according to the DOCSIS OSSIv1.1 specification, ifIndex '1' in the CM means that this row applies to all Cable Modem-to-CPE Interfaces (CMCI)." REFERENCE "DOCSIS OSSI 1.1 Specification, Section 3.3.4.1. and DOCSIS OSSI 2.0 Specification, Section 6.3.4.1." ::= { docsDevFilterLLCEntry 3 } Woundy & Marez Standards Track [Page 43] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevFilterLLCProtocolType OBJECT-TYPE SYNTAX INTEGER { ethertype(1), dsap(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The format of the value in docsDevFilterLLCProtocol: either a two-byte Ethernet Ethertype, or a one-byte 802.2 Service Access Point (SAP) value. ethertype(1) also applies to Standard Network Access Protocol (SNAP) encapsulated frames." DEFVAL { ethertype } ::= { docsDevFilterLLCEntry 4 } docsDevFilterLLCProtocol OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The layer-three protocol for which this filter applies. The protocol value format depends on docsDevFilterLLCProtocolType. Note that for SNAP frames, ethertype filtering is performed rather than Destination Service Access Point (DSAP) =0xAA." DEFVAL { 0 } ::= { docsDevFilterLLCEntry 5 } docsDevFilterLLCMatches OBJECT-TYPE SYNTAX Counter32 UNITS "matches" MAX-ACCESS read-only STATUS current DESCRIPTION "Counts the number of times this filter was matched." ::= { docsDevFilterLLCEntry 6 } -- -- IPv4 Filtering -- docsDevFilterIpDefault OBJECT-TYPE SYNTAX INTEGER { discard(1), accept(2) } MAX-ACCESS read-write Woundy & Marez Standards Track [Page 44] RFC 4639 DOCSIS Cable Device MIB December 2006 STATUS deprecated DESCRIPTION "The default behavior for (bridged) packets that do not match IP filters (or Internet filters, if implemented) is defined by docsDevFilterIpDefault. If set to discard(1), all packets not matching an IP filter in docsDevFilterIpTable will be discarded. If set to accept(2), all packets not matching an IP filter or an Internet filter will be accepted for further processing (e.g., bridging)." DEFVAL { accept } ::= { docsDevFilter 3 } docsDevFilterIpTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterIpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An ordered list of filters or classifiers to apply to IP traffic. Filter application is ordered by the filter index, rather than by a best match algorithm (note that this implies that the filter table may have gaps in the index values). Packets that match no filters will have policy 0 in the docsDevFilterPolicyTable applied to them, if it exists. Otherwise, Packets that match no filters are discarded or forwarded according to the setting of docsDevFilterIpDefault. Any IP packet can theoretically match multiple rows of this table. When considering a packet, the table is scanned in row index order (e.g., filter 10 is checked before filter 20). If the packet matches that filter (which means that it matches ALL criteria for that row), actions appropriate to docsDevFilterIpControl and docsDevFilterPolicyId are taken. If the packet was discarded processing is complete. If docsDevFilterIpContinue is set to true, the filter comparison continues with the next row in the table, looking for additional matches. If the packet matches no filter in the table, the packet is accepted or dropped for further processing according to the setting of docsDevFilterIpDefault. If the packet is accepted, the actions specified by policy group 0 (e.g., the rows in docsDevFilterPolicyTable that have a value of 0 for docsDevFilterPolicyId) are taken, if that policy Woundy & Marez Standards Track [Page 45] RFC 4639 DOCSIS Cable Device MIB December 2006 group exists. Logically, this table is consulted twice during the processing of any IP packet: once upon its acceptance from the L2 entity, and once upon its transmission to the L2 entity. In actuality, for cable modems, IP filtering is generally the only IP processing done for transit traffic. This means that inbound and outbound filtering can generally be done at the same time with one pass through the filter table. The objects in this table are only accessible from cable devices that are not operating in DiffServ MIB mode (RFC 3289). See the conformance section for details. Note that some devices are required by other specifications (e.g., the DOCSIS OSSIv1.1 specification) to support the legacy SNMPv1/v2c docsDevFilter mode for backward compatibility. Table entries MUST NOT persist across reboots for any device. This table is deprecated. Instead, use the DiffServ MIB from RFC 3289." ::= { docsDevFilter 4 } docsDevFilterIpEntry OBJECT-TYPE SYNTAX DocsDevFilterIpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Describes a filter to apply to IP traffic received on a specified interface. All identity objects in this table (e.g., source and destination address/mask, protocol, source/dest port, TOS/mask, interface and direction) must match their respective fields in the packet for any given filter to match. To create an entry in this table, docsDevFilterIpIfIndex must be specified." INDEX { docsDevFilterIpIndex } ::= { docsDevFilterIpTable 1 } DocsDevFilterIpEntry ::= SEQUENCE { docsDevFilterIpIndex Integer32, docsDevFilterIpStatus RowStatus, docsDevFilterIpControl INTEGER, Woundy & Marez Standards Track [Page 46] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevFilterIpIfIndex InterfaceIndexOrZero, docsDevFilterIpDirection INTEGER, docsDevFilterIpBroadcast TruthValue, docsDevFilterIpSaddr IpAddress, docsDevFilterIpSmask IpAddress, docsDevFilterIpDaddr IpAddress, docsDevFilterIpDmask IpAddress, docsDevFilterIpProtocol Integer32, docsDevFilterIpSourcePortLow Integer32, docsDevFilterIpSourcePortHigh Integer32, docsDevFilterIpDestPortLow Integer32, docsDevFilterIpDestPortHigh Integer32, docsDevFilterIpMatches ZeroBasedCounter32, docsDevFilterIpTos OCTET STRING, docsDevFilterIpTosMask OCTET STRING, docsDevFilterIpContinue TruthValue, docsDevFilterIpPolicyId Integer32 } docsDevFilterIpIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Index used to order the application of filters. The filter with the lowest index is always applied first." ::= { docsDevFilterIpEntry 1 } docsDevFilterIpStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Controls and reflects the status of rows in this table. Specifying only this object (with the appropriate index) on a CM is sufficient to create a filter row that matches all inbound packets on the ethernet interface and results in the packets being discarded. docsDevFilterIpIfIndex (at least) must be specified on a CMTS to create a row. Creation of the rows may be done via either create-and-wait or create-and-go, but the filter is not applied until this object is set to (or changes to) active. There is no restriction in changing any object in a row while this object is set to active." ::= { docsDevFilterIpEntry 2 } Woundy & Marez Standards Track [Page 47] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevFilterIpControl OBJECT-TYPE SYNTAX INTEGER { discard(1), accept(2), policy(3) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "If set to discard(1), all packets matching this filter will be discarded, and scanning of the remainder of the filter list will be aborted. If set to accept(2), all packets matching this filter will be accepted for further processing (e.g., bridging). If docsDevFilterIpContinue is set to true, see if there are other matches; otherwise, done. If set to policy (3), execute the policy entries matched by docsDevFilterIpPolicyId in docsDevFilterPolicyTable. If docsDevFilterIpContinue is set to true, continue scanning the table for other matches; otherwise, done." DEFVAL { discard } ::= { docsDevFilterIpEntry 3 } docsDevFilterIpIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The entry interface to which this filter applies. The value corresponds to ifIndex for either a CATV MAC or another interface. If the value is zero, the filter applies to all interfaces. Default value in CMs is the index of the customer-side (e.g., ethernet) interface(s). In CMTSes, this object MUST be specified to create a row in this table. Note that according to the DOCSIS OSSIv1.1 specification, ifIndex '1' in the Cable Modem means that this row applies to all CMCI (customer-facing) interfaces." REFERENCE "DOCSIS OSSI 1.1 Specification, Section 3.3.4.1. and DOCSIS OSSI 2.0 Specification, Section 6.3.4.1." ::= { docsDevFilterIpEntry 4 } docsDevFilterIpDirection OBJECT-TYPE Woundy & Marez Standards Track [Page 48] RFC 4639 DOCSIS Cable Device MIB December 2006 SYNTAX INTEGER { inbound(1), outbound(2), both(3) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Determines whether the filter is applied to inbound(1) traffic, outbound(2) traffic, or traffic in both(3) directions." DEFVAL { inbound } ::= { docsDevFilterIpEntry 5 } docsDevFilterIpBroadcast OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS deprecated DESCRIPTION "If set to true(1), the filter only applies to multicast and broadcast traffic. If set to false(2), the filter applies to all traffic." DEFVAL { false } ::= { docsDevFilterIpEntry 6 } docsDevFilterIpSaddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The source IP address, or portion thereof, that is to be matched for this filter. The source address is first masked (ANDed) against docsDevFilterIpSmask before being compared to this value. A value of 0 for this object and 0 for the mask matches all IP addresses." DEFVAL { '00000000'h } ::= { docsDevFilterIpEntry 7 } docsDevFilterIpSmask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A bit mask that is to be applied to the source address prior to matching. This mask is not necessarily the same as a subnet mask, but 1s bits must be leftmost and contiguous." DEFVAL { '00000000'h } Woundy & Marez Standards Track [Page 49] RFC 4639 DOCSIS Cable Device MIB December 2006 ::= { docsDevFilterIpEntry 8 } docsDevFilterIpDaddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The destination IP address, or portion thereof, that is to be matched for this filter. The destination address is first masked (ANDed) against docsDevFilterIpDmask before being compared to this value. A value of 00000000 for this object and 00000000 for the mask matches all IP addresses." DEFVAL { '00000000'h } ::= { docsDevFilterIpEntry 9 } docsDevFilterIpDmask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "A bit mask that is to be applied to the destination address prior to matching. This mask is not necessarily the same as a subnet mask, but 1s bits MUST be leftmost and contiguous." DEFVAL { '00000000'h } ::= { docsDevFilterIpEntry 10 } docsDevFilterIpProtocol OBJECT-TYPE SYNTAX Integer32 (0..256) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The IP protocol value that is to be matched. For example, icmp is 1, tcp is 6, and udp is 17. A value of 256 matches ANY protocol." REFERENCE "www.iana.org/assignments/protocol-numbers" DEFVAL { 256 } ::= { docsDevFilterIpEntry 11 } docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This is the inclusive lower bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this Woundy & Marez Standards Track [Page 50] RFC 4639 DOCSIS Cable Device MIB December 2006 object is ignored during matching." REFERENCE "www.iana.org/assignments/port-numbers" DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } docsDevFilterIpSourcePortHigh OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This is the inclusive upper bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." REFERENCE "www.iana.org/assignments/port-numbers" DEFVAL { 65535 } ::= { docsDevFilterIpEntry 13 } docsDevFilterIpDestPortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This is the inclusive lower bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." REFERENCE "www.iana.org/assignments/port-numbers" DEFVAL { 0 } ::= { docsDevFilterIpEntry 14 } docsDevFilterIpDestPortHigh OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This is the inclusive upper bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." REFERENCE "www.iana.org/assignments/port-numbers" DEFVAL { 65535 } ::= { docsDevFilterIpEntry 15 } docsDevFilterIpMatches OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "matches" MAX-ACCESS read-only Woundy & Marez Standards Track [Page 51] RFC 4639 DOCSIS Cable Device MIB December 2006 STATUS deprecated DESCRIPTION "Counts the number of times this filter was matched. This object is initialized to 0 at boot, or at row creation, and is reset only upon reboot." ::= { docsDevFilterIpEntry 16 } docsDevFilterIpTos OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This is the value to be matched to the packet's TOS (Type of Service) value (after the TOS value is ANDed with docsDevFilterIpTosMask). A value for this object of 0 and a mask of 0 matches all TOS values." DEFVAL { '00'h } ::= { docsDevFilterIpEntry 17 } docsDevFilterIpTosMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The mask to be applied to the packet's TOS value before matching." DEFVAL { '00'h } ::= { docsDevFilterIpEntry 18 } docsDevFilterIpContinue OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS deprecated DESCRIPTION "If this value is set to true and docsDevFilterIpControl is anything but discard (1), continue scanning and applying policies. See Section 3.3.3 for more details." DEFVAL { false } ::= { docsDevFilterIpEntry 19 } docsDevFilterIpPolicyId OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object points to an entry in docsDevFilterPolicyTable. If docsDevFilterIpControl Woundy & Marez Standards Track [Page 52] RFC 4639 DOCSIS Cable Device MIB December 2006 is set to policy (3), execute all matching policies in docsDevFilterPolicyTable. If no matching policy exists, treat as if docsDevFilterIpControl were set to accept (1). If this object is set to the value of 0, there is no matching policy, and docsDevFilterPolicyTable MUST NOT be consulted." DEFVAL { 0 } ::= { docsDevFilterIpEntry 20 } -- -- Policy Mapping Table -- docsDevFilterPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterPolicyEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A Table that maps between a policy group ID and a set of pointers to policies to be applied. All rows with the same docsDevFilterPolicyId are part of the same group of policy pointers and are applied in the order in this table. docsDevFilterPolicyTable exists to allow multiple policy actions (referenced by policy pointers) to be applied to any given classified packet. The policy actions are applied in index order. For example: Index ID Type Action 1 1 TOS 1 9 5 TOS 1 12 1 IPSEC 3 This says that a packet that matches a filter with policy id 1 first has TOS policy 1 applied (which might set the TOS bits to enable a higher priority) and next has the IPSEC policy 3 applied (which may result in the packets being dumped into a secure VPN to a remote encryptor). Policy ID 0 is reserved for default actions and is applied only to packets that match no filters in docsDevFilterIpTable. Table entries MUST NOT persist across reboots for any device. This table is deprecated. Instead, use the DiffServ MIB Woundy & Marez Standards Track [Page 53] RFC 4639 DOCSIS Cable Device MIB December 2006 from RFC 3289." ::= { docsDevFilter 5 } docsDevFilterPolicyEntry OBJECT-TYPE SYNTAX DocsDevFilterPolicyEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the docsDevFilterPolicyTable. Entries are created by Network Management. To create an entry, docsDevFilterPolicyId MUST be specified." INDEX { docsDevFilterPolicyIndex } ::= { docsDevFilterPolicyTable 1 } DocsDevFilterPolicyEntry ::= SEQUENCE { docsDevFilterPolicyIndex Integer32, docsDevFilterPolicyId Integer32, -- docsDevFilterPolicyType INTEGER, -- docsDevFilterPolicyAction Integer32, docsDevFilterPolicyStatus RowStatus, docsDevFilterPolicyPtr RowPointer } docsDevFilterPolicyIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Index value for the table." ::= { docsDevFilterPolicyEntry 1 } docsDevFilterPolicyId OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Policy ID for this entry. If a policy ID can apply to multiple rows of this table, all relevant policies are executed. Policy 0 (if populated) is applied to all packets that do not match any of the filters. N.B. If docsDevFilterIpPolicyId is set to 0, it DOES NOT match policy 0 of this table." ::= { docsDevFilterPolicyEntry 2 } -- The following two objects were removed and never used; however, -- to preserve OID numbering, they are simply commented out to -- to ensure that they are not used again. -- docsDevFilterPolicyType ::= { docsDevFilterPolicyEntry 3 } -- docsDevFilterPolicyAction ::= { docsDevFilterPolicyEntry 4 } Woundy & Marez Standards Track [Page 54] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevFilterPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Object used to create an entry in this table. There is no restriction in changing any object in a row while this object is set to active. The following object MUST have a valid value before this object can be set to active: docsDevFilterPolicyPtr." ::= { docsDevFilterPolicyEntry 5 } docsDevFilterPolicyPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object points to a row in an applicable filter policy table. Currently, the only standard policy table is docsDevFilterTosTable. Per the textual convention, this object points to the first accessible object in the row; e.g., to point to a row in docsDevFilterTosTable with an index of 21, the value of this object would be the object identifier docsDevTosStatus.21. Vendors are recommended to adhere to the same convention when adding vendor-specific policy table extensions. If this pointer references an empty or non-existent row, then no policy action is taken. The default upon row creation is a null pointer that results in no policy action being taken." DEFVAL { zeroDotZero } ::= { docsDevFilterPolicyEntry 6 } -- -- TOS Policy action table -- docsDevFilterTosTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterTosEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Table used to describe Type of Service (TOS) bits Woundy & Marez Standards Track [Page 55] RFC 4639 DOCSIS Cable Device MIB December 2006 processing. This table is an adjunct to the docsDevFilterIpTable and the docsDevFilterPolicy table. Entries in the latter table can point to specific rows in this (and other) tables and cause specific actions to be taken. This table permits the manipulation of the value of the Type of Service bits in the IP header of the matched packet as follows: Set the tosBits of the packet to (tosBits & docsDevFilterTosAndMask) | docsDevFilterTosOrMask This construct allows you to do a clear and set of all the TOS bits in a flexible manner. Table entries MUST NOT persist across reboots for any device. This table is deprecated. Instead, use the DiffServ MIB from RFC 3289." ::= { docsDevFilter 6 } docsDevFilterTosEntry OBJECT-TYPE SYNTAX DocsDevFilterTosEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A TOS policy entry." INDEX { docsDevFilterTosIndex } ::= { docsDevFilterTosTable 1 } DocsDevFilterTosEntry ::= SEQUENCE { docsDevFilterTosIndex Integer32, docsDevFilterTosStatus RowStatus, docsDevFilterTosAndMask OCTET STRING, docsDevFilterTosOrMask OCTET STRING } docsDevFilterTosIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The unique index for this row. There are no ordering requirements for this table, and any valid index may be specified." Woundy & Marez Standards Track [Page 56] RFC 4639 DOCSIS Cable Device MIB December 2006 ::= { docsDevFilterTosEntry 1 } docsDevFilterTosStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The object used to create and delete entries in this table. A row created by specifying just this object results in a row that specifies no change to the TOS bits. A row may be created using either the create-and-go or create-and-wait paradigms. There is no restriction on the ability to change values in this row while the row is active." ::= { docsDevFilterTosEntry 2 } docsDevFilterTosAndMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This value is bitwise ANDed with the matched packet's TOS bits." DEFVAL { 'ff'h } ::= { docsDevFilterTosEntry 3 } docsDevFilterTosOrMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This value is bitwise ORed with the result from the AND procedure (tosBits & docsDevFilterTosAndMask). The result then replaces the packet's TOS bits." DEFVAL { '00'h } ::= { docsDevFilterTosEntry 4 } -- -- CPE IP Management and anti-spoofing group. Only implemented on -- Cable Modems. -- docsDevCpe OBJECT IDENTIFIER ::= { docsDevMIBObjects 7 } docsDevCpeEnroll OBJECT-TYPE SYNTAX INTEGER { none(1), any(2) Woundy & Marez Standards Track [Page 57] RFC 4639 DOCSIS Cable Device MIB December 2006 } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the population of docsDevFilterCpeTable. If set to none, the filters must be set manually by a network management action (either configuration or SNMP set). If set to any, the CM wiretaps the packets originating from the ethernet and enrolls up to docsDevCpeIpMax addresses as based on the source IPv4 or v6 addresses of those packets." DEFVAL { any } ::= { docsDevCpe 1 } docsDevCpeIpMax OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the maximum number of CPEs allowed to be learned behind this device. If set to zero, any number of CPEs may connect up to the maximum permitted for the device. If set to -1, no filtering is done on CPE source addresses, and no entries are made in the docsDevFilterCpeTable via learning. If an attempt is made to set this to a number greater than that permitted for the device, it is set to that maximum." DEFVAL { -1 } ::= { docsDevCpe 2 } docsDevCpeTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevCpeEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table lists the IPv4 addresses seen (or permitted) as source addresses in packets originating from the customer interface on this device. In addition, this table can be provisioned with the specific addresses permitted for the CPEs via the normal row creation mechanisms. Table entries MUST NOT persist across reboots for any device. N.B. Management action can add entries in this table and in docsDevCpeIpTable past the value of Woundy & Marez Standards Track [Page 58] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevCpeIpMax. docsDevCpeIpMax ONLY restricts the ability of the CM to add learned addresses automatically. This table is deprecated and is replaced by docsDevCpeInetTable." ::= { docsDevCpe 3 } docsDevCpeEntry OBJECT-TYPE SYNTAX DocsDevCpeEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the docsDevFilterCpeTable. There is one entry for each IPv4 CPE seen or provisioned. If docsDevCpeIpMax is set to -1, this table is ignored; otherwise, upon receipt of an IP packet from the customer interface of the CM, the source IP address is checked against this table. If the address is in the table, packet processing continues. If the address is not in the table but docsDevCpeEnroll is set to any and the sum of the table sizes of docsDevCpeTable and docsDevCpeInetTable is less than docsDevCpeIpMax, the address is added to the table, and packet processing continues. Otherwise, the packet is dropped. The filtering actions specified by this table occur after any LLC filtering (docsDevFilterLLCTable), but prior to any IP filtering (docsDevFilterIpTable, docsDevNmAccessTable)." INDEX { docsDevCpeIp } ::= {docsDevCpeTable 1 } DocsDevCpeEntry ::= SEQUENCE { docsDevCpeIp IpAddress, docsDevCpeSource INTEGER, docsDevCpeStatus RowStatus } docsDevCpeIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The IPv4 address to which this entry applies. N.B. Attempts to set all zeros or all ones address values MUST be rejected." Woundy & Marez Standards Track [Page 59] RFC 4639 DOCSIS Cable Device MIB December 2006 ::= { docsDevCpeEntry 1 } docsDevCpeSource OBJECT-TYPE SYNTAX INTEGER { other(1), manual(2), learned(3) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object describes how this entry was created. If the value is manual(2), this row was created by a network management action (either configuration or SNMP set). If set to learned(3), then it was found via looking at the source IPv4 address of a received packet. The value other(1) is used for any entries that do not meet manual(2) or learned(3) criteria." ::= { docsDevCpeEntry 2 } docsDevCpeStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Standard object to manipulate rows. To create a row in this table, one only needs to specify this object. Management stations SHOULD use the create-and-go mechanism for creating rows in this table." ::= { docsDevCpeEntry 3 } -- -- Internet CPE Management and anti spoofing group, for support of -- non-IPv4 CPEs. -- docsDevCpeInetTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevCpeInetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the IP addresses seen (or permitted) as source addresses in packets originating from the customer interface on this device. In addition, this table can be provisioned with the specific addresses permitted for the CPEs via the normal row creation mechanisms. Woundy & Marez Standards Track [Page 60] RFC 4639 DOCSIS Cable Device MIB December 2006 N.B. Management action can add entries in this table and in docsDevCpeIpTable past the value of docsDevCpeIpMax. docsDevCpeIpMax ONLY restricts the ability of the CM to add learned addresses automatically. Table entries MUST NOT persist across reboots for any device. This table exactly mirrors docsDevCpeTable and applies to IPv4 and IPv6 addresses." ::= { docsDevCpe 4 } docsDevCpeInetEntry OBJECT-TYPE SYNTAX DocsDevCpeInetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the docsDevFilterCpeInetTable. There is one entry for each IP CPE seen or provisioned. If docsDevCpeIpMax is set to -1, this table is ignored; otherwise, upon receipt of an IP packet from the customer interface of the CM, the source IP address is checked against this table. If the address is in the table, packet processing continues. If the address is not in the table but docsDevCpeEnroll is set to any and the sum of the table sizes for docsDevCpeTable and docsDevCpeInetTable is less than docsDevCpeIpMax, the address is added to the table, and packet processing continues. Otherwise, the packet is dropped. The filtering actions specified by this table occur after any LLC filtering (docsDevFilterLLCTable), but prior to any IP filtering (docsDevFilterIpTable, docsDevNmAccessTable). When an agent (cable modem) restarts, then all dynamically created rows are lost." INDEX { docsDevCpeInetType, docsDevCpeInetAddr } ::= { docsDevCpeInetTable 1 } DocsDevCpeInetEntry ::= SEQUENCE { docsDevCpeInetType InetAddressType, docsDevCpeInetAddr InetAddress, docsDevCpeInetSource INTEGER, docsDevCpeInetRowStatus RowStatus } Woundy & Marez Standards Track [Page 61] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevCpeInetType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of internet address of docsDevCpeInetAddr." ::= { docsDevCpeInetEntry 1 } docsDevCpeInetAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Internet address to which this entry applies. Implementors need to be aware that if the size of docsDevCpeInetAddr exceeds 114 octets OIDs of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. Only unicast address are allowed for this object." ::= { docsDevCpeInetEntry 2 } docsDevCpeInetSource OBJECT-TYPE SYNTAX INTEGER { manual(2), learned(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes how this entry was created. If the value is manual(2), this row was created by a network management action (either configuration or SNMP set). If set to learned(3), then it was found via looking at the source IP address of a received packet." ::= { docsDevCpeInetEntry 3 } docsDevCpeInetRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Standard object to manipulate rows. To create a row in this table, one only needs to specify this object. Management stations SHOULD use the create-and-go mechanism for creating rows in this table." Woundy & Marez Standards Track [Page 62] RFC 4639 DOCSIS Cable Device MIB December 2006 ::= { docsDevCpeInetEntry 4 } -- -- Placeholder for notifications/traps. -- -- erroneous, DO NOT USE docsDevNotification docsDevNotification OBJECT IDENTIFIER ::= { docsDev 2 } -- erroneous, DO NOT USE docsDevNotification docsDevNotifications OBJECT IDENTIFIER ::= { docsDev 0 } -- -- RFC 2669 Conformance definitions -- docsDevConformance OBJECT IDENTIFIER ::= { docsDev 3 } docsDevGroups OBJECT IDENTIFIER ::= { docsDevConformance 1 } docsDevCompliances OBJECT IDENTIFIER ::= { docsDevConformance 2 } docsDevBasicCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The RFC 2669 compliance statement for MCNS/DOCSIS Cable Modems and Cable Modem Termination Systems." MODULE -- docsDev -- conditionally mandatory groups GROUP docsDevBaseGroup DESCRIPTION "Mandatory in Cable Modems, optional in Cable Modem Termination Systems." GROUP docsDevEventGroup DESCRIPTION "Mandatory in Cable Modems, optional in Cable Modem Termination Systems." GROUP docsDevFilterGroup DESCRIPTION "Mandatory in Cable Modems, optional in Cable Modem Termination Systems." GROUP docsDevNmAccessGroup Woundy & Marez Standards Track [Page 63] RFC 4639 DOCSIS Cable Device MIB December 2006 DESCRIPTION "This group is only implemented in devices that do not implement the SNMPv3 User Security Model. It SHOULD NOT be implemented by devices that conform to SNMPv3. For devices that do not implement SNMPv3 or later, this group is Mandatory in Cable Modems and is optional in Cable Modem Termination Systems." GROUP docsDevServerGroup DESCRIPTION "This group is implemented only in Cable Modems, and is not implemented in Cable Modem Termination Systems." GROUP docsDevSoftwareGroup DESCRIPTION "This group is Mandatory in Cable Modems and optional in Cable Modem Termination Systems." GROUP docsDevCpeGroup DESCRIPTION "This group is Mandatory in Cable Modems, and is not implemented in Cable Modem Termination Systems." OBJECT docsDevSTPControl MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support noStFilterBpdu(2)." OBJECT docsDevNmAccessIp DESCRIPTION "It is compliant to recognize the IP address 255.255.255.255 as referring to any NMS." OBJECT docsDevEvReporting MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support local(0). An agent need not enforce that trap or syslog logging be accompanied by local(0) or localVolatile(3) logging." ::= { docsDevCompliances 1 } docsDevBaseGroup OBJECT-GROUP OBJECTS { docsDevRole, docsDevDateTime, Woundy & Marez Standards Track [Page 64] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevResetNow, docsDevSerialNumber, docsDevSTPControl } STATUS current DESCRIPTION "A collection of objects providing device status and control." ::= { docsDevGroups 1 } docsDevNmAccessGroup OBJECT-GROUP OBJECTS { docsDevNmAccessIp, docsDevNmAccessIpMask, docsDevNmAccessCommunity, docsDevNmAccessControl, docsDevNmAccessInterfaces, docsDevNmAccessStatus } STATUS deprecated DESCRIPTION "A collection of objects for controlling access to SNMP objects on cable devices. This group has been deprecated because all the objects have been deprecated in favor of SNMPv3 and Coexistence MIBs." ::= { docsDevGroups 2 } docsDevSoftwareGroup OBJECT-GROUP OBJECTS { docsDevSwServer, docsDevSwFilename, docsDevSwAdminStatus, docsDevSwOperStatus, docsDevSwCurrentVers } STATUS deprecated DESCRIPTION "A collection of objects for controlling software downloads. This group has been deprecated and replaced by docsDevSoftwareGroupV2. Object docsDevSwServer has been replaced by docsDevSwServerAddressType and docsDevSwServerAddress, and docsDevSwServerTransportProtocol has been added to support TFTP and HTTP firmware downloads." Woundy & Marez Standards Track [Page 65] RFC 4639 DOCSIS Cable Device MIB December 2006 ::= { docsDevGroups 3 } docsDevServerGroup OBJECT-GROUP OBJECTS { docsDevServerBootState, docsDevServerDhcp, docsDevServerTime, docsDevServerTftp, docsDevServerConfigFile } STATUS deprecated DESCRIPTION "A collection of objects providing status about server provisioning. This group has been deprecated and replaced by docsDevServerGroupV2. The objects docsDevServerDhcp, docsDevServerTime, and docsDevServerTftp have been replaced by docsDevServerDhcpAddressType, docsDevServerDhcpAddress, docsDevServerTimeAddressType, docsDevServerTimeAddress, docsDevServerConfigTftpAddressType, and docsDevServerConfigTftpAddress." ::= { docsDevGroups 4 } docsDevEventGroup OBJECT-GROUP OBJECTS { docsDevEvControl, docsDevEvSyslog, docsDevEvThrottleAdminStatus, docsDevEvThrottleInhibited, docsDevEvThrottleThreshold, docsDevEvThrottleInterval, docsDevEvReporting, docsDevEvFirstTime, docsDevEvLastTime, docsDevEvCounts, docsDevEvLevel, docsDevEvId, docsDevEvText } STATUS deprecated DESCRIPTION "A collection of objects used to control and monitor events. This group has been deprecated and replaced by docsDevEventGroupV2. The object docsDevEvSyslog has Woundy & Marez Standards Track [Page 66] RFC 4639 DOCSIS Cable Device MIB December 2006 been replaced by docsDevEvSyslogAddressType and docsDevEvSyslogAddress, and docsDevEvThrottleInhibited has been replaced by docsDevEvThrottleThresholdExceeded." ::= { docsDevGroups 5 } docsDevFilterGroup OBJECT-GROUP OBJECTS { docsDevFilterLLCUnmatchedAction, docsDevFilterIpDefault, docsDevFilterLLCStatus, docsDevFilterLLCIfIndex, docsDevFilterLLCProtocolType, docsDevFilterLLCProtocol, docsDevFilterLLCMatches, docsDevFilterIpControl, docsDevFilterIpIfIndex, docsDevFilterIpStatus, docsDevFilterIpDirection, docsDevFilterIpBroadcast, docsDevFilterIpSaddr, docsDevFilterIpSmask, docsDevFilterIpDaddr, docsDevFilterIpDmask, docsDevFilterIpProtocol, docsDevFilterIpSourcePortLow, docsDevFilterIpSourcePortHigh, docsDevFilterIpDestPortLow, docsDevFilterIpDestPortHigh, docsDevFilterIpMatches, docsDevFilterIpTos, docsDevFilterIpTosMask, docsDevFilterIpContinue, docsDevFilterIpPolicyId, docsDevFilterPolicyId, docsDevFilterPolicyStatus, docsDevFilterPolicyPtr, docsDevFilterTosStatus, docsDevFilterTosAndMask, docsDevFilterTosOrMask } STATUS deprecated DESCRIPTION "A collection of objects to specify filters at the link layer and IPv4 layer. This group has been deprecated and replaced by various groups from the DiffServ MIB." Woundy & Marez Standards Track [Page 67] RFC 4639 DOCSIS Cable Device MIB December 2006 ::= { docsDevGroups 6 } docsDevCpeGroup OBJECT-GROUP OBJECTS { docsDevCpeEnroll, docsDevCpeIpMax, docsDevCpeSource, docsDevCpeStatus } STATUS deprecated DESCRIPTION "A collection of objects used to control the number and specific values of IPv4 addresses allowed for associated Customer Premises Equipment (CPE). This group has been deprecated and replaced by docsDevInetCpeGroup. The object docsDevCpeSource has been replaced by docsDevCpeInetSource, and docsDevCpeStatus has been replaced by docsDevCpeInetRowStatus." ::= { docsDevGroups 7 } -- -- RFC 4639 Conformance definitions -- docsDevGroupsV2 OBJECT IDENTIFIER ::= { docsDevConformance 3 } docsDevCompliancesV2 OBJECT IDENTIFIER ::= { docsDevConformance 4 } docsDevCmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Cable Modems. This compliance statement applies to implementations of DOCSIS versions that are not IPv6 capable." MODULE DIFFSERV-MIB -- RFC 3289 MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBDscpMarkActGroup, diffServMIBCounterGroup, diffServMIBAlgDropGroup Woundy & Marez Standards Track [Page 68] RFC 4639 DOCSIS Cable Device MIB December 2006 } OBJECT diffServDataPathStatus -- same as RFC 3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServClfrStatus -- same as RFC 3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServClfrElementStatus -- same as RFC 3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServMultiFieldClfrAddrType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServMultiFieldClfrSrcAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServMultiFieldClfrDstAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServAlgDropStatus -- same as RFC 3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." Woundy & Marez Standards Track [Page 69] RFC 4639 DOCSIS Cable Device MIB December 2006 OBJECT diffServDataPathStorage SYNTAX StorageType { volatile(2) } DESCRIPTION "An implementation is only required to support volatile storage." OBJECT diffServClfrStorage SYNTAX StorageType { volatile(2) } DESCRIPTION "An implementation is only required to support volatile storage." OBJECT diffServClfrElementStorage SYNTAX StorageType { volatile(2) } DESCRIPTION "An implementation is only required to support volatile storage." OBJECT diffServMultiFieldClfrStorage SYNTAX StorageType { volatile(2) } DESCRIPTION "An implementation is only required to support volatile storage." OBJECT diffServActionStorage SYNTAX StorageType { volatile(2) } DESCRIPTION "An implementation is only required to support volatile storage." OBJECT diffServCountActStorage SYNTAX StorageType { volatile(2) } DESCRIPTION "An implementation is only required to support volatile storage." OBJECT diffServAlgDropStorage SYNTAX StorageType { volatile(2) } DESCRIPTION "An implementation is only required to support volatile storage." OBJECT diffServAlgDropType SYNTAX INTEGER { alwaysDrop(5) } DESCRIPTION "This object is only used to provide packet filtering. Implementations need not support other values of this enumeration." Woundy & Marez Standards Track [Page 70] RFC 4639 DOCSIS Cable Device MIB December 2006 MODULE -- docsDev MANDATORY-GROUPS { docsDevBaseGroup, docsDevBaseIgmpGroup, docsDevBaseMaxCpeGroup, docsDevSoftwareGroupV2, docsDevServerGroupV2, docsDevEventGroupV2, docsDevFilterLLCGroup } -- conditionally mandatory groups GROUP docsDevInetCpeGroup DESCRIPTION "This group is optional in Cable Modems." OBJECT docsDevDateTime MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsDevSTPControl SYNTAX INTEGER { noStFilterBpdu(2) } MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support noStFilterBpdu(2)." OBJECT docsDevIgmpModeControl SYNTAX INTEGER { passive(1) } MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support passive(1)." OBJECT docsDevSwServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevSwServerAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." Woundy & Marez Standards Track [Page 71] RFC 4639 DOCSIS Cable Device MIB December 2006 OBJECT docsDevServerDhcpAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevServerDhcpAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevServerTimeAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevServerTimeAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevServerConfigTftpAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevServerConfigTftpAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevEvReporting MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support local(0)." OBJECT docsDevEvSyslogAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." Woundy & Marez Standards Track [Page 72] RFC 4639 DOCSIS Cable Device MIB December 2006 OBJECT docsDevEvSyslogAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevSwServerTransportProtocol SYNTAX INTEGER { tftp(1) } DESCRIPTION "An implementation is only required to support TFTP software image downloads." ::= { docsDevCompliancesV2 1 } docsDevCmtsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Cable Modem Termination Systems. This compliance statement applies to implementations of DOCSIS versions that are not IPv6 capable." MODULE -- docsDev -- conditionally mandatory groups GROUP docsDevBaseGroup DESCRIPTION "Optional in Cable Modem Termination Systems." GROUP docsDevBaseIgmpGroup DESCRIPTION "Optional in Cable Modem Termination Systems." GROUP docsDevBaseMaxCpeGroup DESCRIPTION "This group MUST NOT be implemented in Cable Modem Termination Systems." GROUP docsDevSoftwareGroupV2 DESCRIPTION "Optional in Cable Modem Termination Systems." GROUP docsDevServerGroupV2 DESCRIPTION "This group MUST NOT be implemented in Cable Modem Termination Systems." Woundy & Marez Standards Track [Page 73] RFC 4639 DOCSIS Cable Device MIB December 2006 GROUP docsDevEventGroupV2 DESCRIPTION "Optional in Cable Modem Termination Systems." GROUP docsDevFilterLLCGroup DESCRIPTION "This group MUST NOT be implemented in Cable Modem Termination Systems. See the Subscriber Management MIB for similar CMTS capability." GROUP docsDevInetCpeGroup DESCRIPTION "This group MUST NOT be implemented in Cable Modem Termination Systems. See the Subscriber Management MIB for similar CMTS capability." OBJECT docsDevDateTime MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only." OBJECT docsDevSTPControl SYNTAX INTEGER { noStFilterBpdu(2) } MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support noStFilterBpdu(2)." OBJECT docsDevIgmpModeControl SYNTAX INTEGER { passive(1) } MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support passive(1)." OBJECT docsDevSwServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevSwServerAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevEvReporting Woundy & Marez Standards Track [Page 74] RFC 4639 DOCSIS Cable Device MIB December 2006 MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support local(0)." OBJECT docsDevEvSyslogAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevEvSyslogAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsDevSwServerTransportProtocol SYNTAX INTEGER { tftp(1) } DESCRIPTION "An implementation is only required to support TFTP software image downloads." ::= { docsDevCompliancesV2 2 } docsDevBaseIgmpGroup OBJECT-GROUP OBJECTS { docsDevIgmpModeControl } STATUS current DESCRIPTION "An object providing cable device IGMP status and control." ::= { docsDevGroupsV2 1 } docsDevBaseMaxCpeGroup OBJECT-GROUP OBJECTS { docsDevMaxCpe } STATUS current DESCRIPTION "An object providing management of the maximum number of CPEs permitted access through a cable modem." ::= { docsDevGroupsV2 2 } docsDevNmAccessExtGroup OBJECT-GROUP OBJECTS { docsDevNmAccessTrapVersion Woundy & Marez Standards Track [Page 75] RFC 4639 DOCSIS Cable Device MIB December 2006 } STATUS deprecated DESCRIPTION "An object, in addition to the objects in docsDevNmAccessGroup, for controlling access to SNMP objects on cable devices. This group is included in this MIB due to existing implementations of docsDevNmAccessTrapVersion in DOCSIS cable modems. This group has been deprecated because the object has been deprecated in favor of SNMPv3 and Coexistence MIBs." ::= { docsDevGroupsV2 3 } docsDevSoftwareGroupV2 OBJECT-GROUP OBJECTS { docsDevSwFilename, docsDevSwAdminStatus, docsDevSwOperStatus, docsDevSwCurrentVers, docsDevSwServerAddressType, docsDevSwServerAddress, docsDevSwServerTransportProtocol } STATUS current DESCRIPTION "A collection of objects for controlling software downloads. This group replaces docsDevSoftwareGroup." ::= { docsDevGroupsV2 4 } docsDevServerGroupV2 OBJECT-GROUP OBJECTS { docsDevServerBootState, docsDevServerDhcpAddressType, docsDevServerDhcpAddress, docsDevServerTimeAddressType, docsDevServerTimeAddress, docsDevServerConfigTftpAddressType, docsDevServerConfigTftpAddress, docsDevServerConfigFile } STATUS current DESCRIPTION "A collection of objects providing status about server provisioning. This group replaces docsDevServerGroup." ::= { docsDevGroupsV2 5 } Woundy & Marez Standards Track [Page 76] RFC 4639 DOCSIS Cable Device MIB December 2006 docsDevEventGroupV2 OBJECT-GROUP OBJECTS { docsDevEvControl, docsDevEvThrottleAdminStatus, docsDevEvThrottleThreshold, docsDevEvThrottleInterval, docsDevEvReporting, docsDevEvFirstTime, docsDevEvLastTime, docsDevEvCounts, docsDevEvLevel, docsDevEvId, docsDevEvText, docsDevEvSyslogAddressType, docsDevEvSyslogAddress, docsDevEvThrottleThresholdExceeded } STATUS current DESCRIPTION "A collection of objects used to control and monitor events. This group replaces docsDevEventGroup. The event reporting mechanism, and more specifically docsDevEvReporting, can be used to take advantage of the event reporting features of RFC3413 and RFC3014." ::= { docsDevGroupsV2 6 } docsDevFilterLLCGroup OBJECT-GROUP OBJECTS { docsDevFilterLLCUnmatchedAction, docsDevFilterLLCStatus, docsDevFilterLLCIfIndex, docsDevFilterLLCProtocolType, docsDevFilterLLCProtocol, docsDevFilterLLCMatches } STATUS current DESCRIPTION "A collection of objects to specify link layer filters." ::= { docsDevGroupsV2 7 } docsDevInetCpeGroup OBJECT-GROUP OBJECTS { docsDevCpeEnroll, docsDevCpeIpMax, docsDevCpeInetSource, docsDevCpeInetRowStatus } STATUS current Woundy & Marez Standards Track [Page 77] RFC 4639 DOCSIS Cable Device MIB December 2006 DESCRIPTION "A collection of objects used to control the number and specific values of Internet (e.g., IPv4 and IPv6) addresses allowed for associated Customer Premises Equipment (CPE)." ::= { docsDevGroupsV2 8 } END 5. Acknowledgements This document is a production of the IPCDN Working Group and is a revision of RFC 2669, "Cable Device Management Information Base for DOCSIS-Compliant Cable Modems and Cable Modem Termination Systems" [RFC2669]. Mike St. Johns and Guenter Roeck served well as the editors of previous versions of this MIB module. The editor specifically wishes to thank Howard Abramson, Eduardo Cardona, Andre Lejeune, Kevin Marez, Jean-Francois Mule, Greg Nakanishi, Pak Siripunkaw, Boris Tsekinovski, Randy Presuhn, Bert Wijnen, and Bill Yost for their contributions to this document. 5.1. Revision Descriptions This document contains the following revisions over RFC 2669: o All IPv4 address objects were either deprecated and replaced or mirrored with IPv6 objects, where appropriate, following the guidelines of RFC 4001 [RFC4001]. In particular, docsDevCpeInetTable was added, and the docsDevFilterGroup objects were deprecated in favor of the DiffServ MIB. o Objects that were obviated by SNMPv3 and the SNMP Coexistence MIBs have been deprecated; e.g., docsDevNmAccessTable. o A new object, docsDevIgmpModeControl, has been added to control passive versus active IGMP modem operation. o A new object, docsDevMaxCpe, has been added to report the maximum number of CPEs granted network access across the CM. o A new object, docsDevSwServerTransportProtocol, has been added to docsDevSoftware, and other object DESCRIPTIONs have been modified, to enable the use of either TFTP or HTTP for software downloads to the device. Woundy & Marez Standards Track [Page 78] RFC 4639 DOCSIS Cable Device MIB December 2006 o A new object, docsDevEvThrottleThresholdExceeded, has been added to replace docsDevEvThrottleInhibited for simplification of event threshold management. o The docsDevEvReporting object has been modified to enable local logging to the internal volatile log, and not to the internal non-volatile log. o Minor updates to the description text have been made to a number of objects to clarify their meaning. o The compliance statements were updated to reflect current requirements (including making the docsDevCpe objects optional) and split between CM and CMTS devices. o Text was added to indicate support of the SNMP Notification MIB [RFC3413] and Notification Log MIB [RFC3014] modules. 6. Security Considerations This MIB module relates to a system that will provide metropolitan public internet access. As such, improper manipulation of the objects represented by this MIB module may result in denial of service to a large number of end-users. In addition, manipulation of docsDevNmAccessTable, docsDevFilterLLCTable, docsDevFilterIpTable, docsDevFilterInetTable, and the elements of the docsDevCpe and docsDevCpeInetTable groups may allow an end-user to increase his or her service levels, spoof his or her IP addresses, change the permitted management stations, or affect other end-users in either a positive or negative manner. It is recommended that the implementors prevent the "tiny fragment" and "overlapping fragment" attacks for the IP filtering tables in this MIB module, as discussed in [RFC1858] and [RFC3128]. Prevention of these attacks can be implemented with the following rules, when TCP source and/or destination port filtering is enabled: o Admit all packets with fragment offset >= 2. o Discard all packets with fragment offset = 1, or with fragment offset = 0 AND fragment payload length < 16. o Apply filtering rules to all packets with fragment offset = 0. This MIB module does not affect confidentiality of services on a cable modem system. [BPI] and [BPIPLUS] specify the implementation of the DOCSIS Baseline Privacy and Baseline Privacy Plus mechanisms for data transmission confidentiality. Woundy & Marez Standards Track [Page 79] RFC 4639 DOCSIS Cable Device MIB December 2006 There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The use of docsDevNmAccessTable to specify management stations is considered only limited protection and does not protect against attacks that spoof the management station's IP address. The use of stronger mechanisms, such as SNMPv3 security, should be considered, where possible. Specifically, SNMPv3 USM [RFC3414] and VACM [RFC3415] MUST be used with any v3 agent that implements this MIB module. o The CM may have its software changed by the actions of the management system using a combination of the following objects: docsDevSwServer, docsDevSwFilename, docsDevSwAdminStatus, docsDevSwServerAddressType, docsDevSwServerAddress, and docsDevSwServerTransportProtocol. An improper software download may result in substantial vulnerabilities and the loss of the ability of the management system to control the cable modem. A cable device SHOULD implement the code verification mechanisms of [BPIPLUS] to verify the source and integrity of downloaded software images. o The device may be reset by setting docsDevResetNow = true(1). This causes the device to reload its configuration files, as well as to eliminate all previous non-persistent network management settings. As such, this may provide a vector for attacking the system. o Setting docsDevEvThrottleAdminStatus = unconstrained(1) (which is also the DEFVAL) may cause flooding of traps, which can disrupt network service. Additionally, docsDevThrottleThreshold and docsDevThrottleInterval could also be set to high values that may cause a disruption in service. o Setting docsDevDateTime to an arbitrary (incorrect) value would merely cause the device to record incorrect timestamps on many events/actions that rely on this object for reporting. o Setting docsDevEvControl to resetLog(1) will delete any event log history and could potentially impact debugging/troubleshooting efforts. o Setting docsDevEvSyslog. Woundy & Marez Standards Track [Page 80] RFC 4639 DOCSIS Cable Device MIB December 2006 o Setting docsDevEvReporting to enable syslog reporting, along with a redirect of the syslog server could allow access to sensitive information on network devices. Modifying docsDevEvSyslog, docsDevEvSyslogAddressType, or docsDevEvSyslogAddress could allow a redirect of sensitive information. o Setting docsDevFilterLLCnmatchedAction or docsDevFilterIpDefault could cause significant changes to default traffic filtering on a device. o Setting docsDevCpeEnroll to any(2) could cause the docsDevFilterCPETable to be populated, which may not be the intended functionality. o Setting docsDevCpeIpMax to a value other than that intended by the MSO may allow a user to provision more devices than the MSO would like. o Setting values in the docsDevNmAccess table can potentially introduce a mechanism for users to use a local NMS device and manipulate other settings in the CM or CMTS. o Setting values in the docsDevFilterLLC and docsDevFilterIP tables can allow or deny access to certain devices that the MSO does not want. o Setting docsDevCpeStatus and docsDevCpeInetRowStatus may allow users to provision more devices than were intended by the MSO, or to provision different ones. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o Rows from docsDevNmAccessTable may provide sufficient information for attackers to spoof management stations that have management access to the device. o The docsDevSwCurrentVers object may provide hints as to the software vulnerabilities of the cable device. o The docsDevFilterLLCTable and docsDevFilterLLCTable may provide clues for attacking the cable device and other subscriber devices. Woundy & Marez Standards Track [Page 81] RFC 4639 DOCSIS Cable Device MIB December 2006 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- docsDevMIB { mib-2 69 } Woundy & Marez Standards Track [Page 82] RFC 4639 DOCSIS Cable Device MIB December 2006 8. References 8.1. Normative References [BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, . [BPIPLUS] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", August 2005, , . [ITU-T_J.112] ITU-T Recommendation J.112 (3/98), "Transmission Systems for Interactive Cable Television Services, J.112, International Telecommunications Union", March 1998, . [MTA-PROV] CableLabs, "PacketCable(TM) 1.5 Specification: MTA Device Provisioning PKT-SP-PROV1.5-I02-050812", August 2005, , . [OSSI1.0] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specification: DOCSIS 1.0 Operations Support System Interface (OSSI), SCTE 22-3 2002", 2002, . [OSSI1.1] SCTE Data Standards Subcommittee, "DOCSIS 1.1 Part 3: Operations Support System Interface ANSI/SCTE 23-3 2005", 2005, . [OSSI2.0] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I09-050812", August 2005, , . [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Woundy & Marez Standards Track [Page 83] RFC 4639 DOCSIS Cable Device MIB December 2006 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser , "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2669] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Woundy & Marez Standards Track [Page 84] RFC 4639 DOCSIS Cable Device MIB December 2006 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. [RFC868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFI1.0] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1 2002", 2002, . [RFI1.1] SCTE Data Standards Subcommittee, "DOCSIS 1.1 Part 1: Radio Frequency Interface ANSI/SCTE 23-1 2005", 2005, . [RFI2.0] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFI2.0-I11-060602", June 2006, , . 8.2. Informative References [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations r IP Fragment Filtering", RFC 1858, October 1995. [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Traner Protocol -- HTTP/1.0", RFC 1945, May 1996. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. Woundy & Marez Standards Track [Page 85] RFC 4639 DOCSIS Cable Device MIB December 2006 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicbility Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003. [RFC4547] Ahmad, A. and G. Nakanishi, "Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems", RFC 4547, June 2006. [RFC1224] Steinberg, L., "Techniques for managing asynchronously generated alerts", RFC 1224, May 1991. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4036] Sawyer, W., "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management", RFC 4036, April 2005. [RFC4323] Patrick, M. and W. Murwin, "Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)", RFC 4323, January 2006. [MULPI3.0] CableLabs, "Data-Over-Cable Service Interface Specifications: DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification CM-SP-MULPIv3.0-I01- 060804", August 2006, , . Woundy & Marez Standards Track [Page 86] RFC 4639 DOCSIS Cable Device MIB December 2006 Authors' Addresses Richard Woundy Comcast Cable 27 Industrial Avenue Chelmsford, MA 01824 USA Phone: +1 978 244 4010 EMail: richard_woundy@cable.comcast.com Kevin Marez Motorola Corporation 6450 Sequence Drive San Diego, CA 92121 USA Phone: +1 858 404 3785 EMail: kevin.marez@motorola.com Woundy & Marez Standards Track [Page 87] RFC 4639 DOCSIS Cable Device MIB December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Woundy & Marez Standards Track [Page 88] snmp-mibs-downloader-1.1/mibrfcs/rfc4668.txt0000644000000000000000000013617411402176072015606 0ustar Network Working Group D. Nelson Request for Comments: 4668 Enterasys Networks Obsoletes: 2618 August 2006 Category: Standards Track RADIUS Authentication Client MIB for IPv6 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients. This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. Nelson Standards Track [Page 1] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 Table of Contents 1. Introduction ....................................................3 2. Terminology .....................................................3 3. The Internet-Standard Management Framework ......................3 4. Scope of Changes ................................................3 5. Structure of the MIB Module .....................................4 6. Deprecated Objects ..............................................5 7. Definitions .....................................................5 8. Security Considerations ........................................20 9. References .....................................................22 9.1. Normative References ......................................22 9.2. Informative References ....................................22 Appendix A. Acknowledgements ......................................23 Nelson Standards Track [Page 2] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The objects defined within this memo relate to the Remote Authentication Dial-In User Service (RADIUS) Authentication Client as defined in RFC 2865 [RFC2865]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses terminology from RFC 2865 [RFC2865]. This document uses the word "malformed" with respect to RADIUS packets, particularly in the context of counters of "malformed packets". While RFC 2865 does not provide an explicit definition of "malformed", malformed generally means that the implementation has determined the packet does not match the format defined in RFC 2865. Some implementations may determine that packets are malformed when the Vendor Specific Attribute (VSA) format does not follow the RFC 2865 recommendations for VSAs. Those implementations are used in deployments today, and thus set the de facto definition of "malformed". 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Scope of Changes This document obsoletes RFC 2618 [RFC2618], RADIUS Authentication Client MIB, by deprecating the radiusAuthServerTable table and adding a new table, radiusAuthServerExtTable, containing radiusAuthServerInetAddressType, radiusAuthServerInetAddress, and Nelson Standards Track [Page 3] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 radiusAuthClientServerInetPortNumber. The purpose of these added MIB objects is to support version-neutral IP addressing formats. The existing table containing radiusAuthServerAddress and radiusAuthClientServerPortNumber is deprecated. The remaining MIB objects are carried forward from RFC 2618 into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. RFC 4001 [RFC4001], which defines the SMI Textual Conventions for IPv6 addresses, contains the following recommendation. 'In particular, when revising a MIB module that contains IPv4 specific tables, it is suggested to define new tables using the textual conventions defined in this memo [RFC4001] that support all versions of IP. The status of the new tables SHOULD be "current", whereas the status of the old IP version specific tables SHOULD be changed to "deprecated". The other approach, of having multiple similar tables for different IP versions, is strongly discouraged.' 5. Structure of the MIB Module The RADIUS authentication protocol, described in RFC 2865 [RFC2865], distinguishes between the client function and the server function. In RADIUS authentication, clients send Access-Requests, and servers reply with Access-Accepts, Access-Rejects, and Access-Challenges. Typically, Network Access Server (NAS) devices implement the client function, and thus would be expected to implement the RADIUS authentication client MIB, while RADIUS authentication servers implement the server function, and thus would be expected to implement the RADIUS authentication server MIB. However, it is possible for a RADIUS authentication entity to perform both client and server functions. For example, a RADIUS proxy may act as a server to one or more RADIUS authentication clients, while simultaneously acting as an authentication client to one or more authentication servers. In such situations, it is expected that RADIUS entities combining client and server functionality will support both the client and server MIBs. The client MIB is defined in this document, and the server MIB is defined in [RFC4669]. This MIB module contains two scalars as well as a single table, the RADIUS Authentication Server Table, which contains one row for each RADIUS authentication server with which the client shares a secret. Each entry in the RADIUS Authentication Server Table includes sixteen columns presenting a view of the activity of the RADIUS authentication client. This MIB imports from [RFC2578], [RFC2580], [RFC3411], and [RFC4001]. Nelson Standards Track [Page 4] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 6. Deprecated Objects The deprecated table in this MIB is carried forward from RFC 2618 [RFC2618]. There are two conditions under which it MAY be desirable for managed entities to continue to support the deprecated table: 1. The managed entity only supports IPv4 address formats. 2. The managed entity supports both IPv4 and IPv6 address formats, and the deprecated table is supported for backwards compatibility with older management stations. This option SHOULD only be used when the IP addresses in the new table are in IPv4 format and can accurately be represented in both the new table and the deprecated table. Managed entities SHOULD NOT instantiate row entries in the deprecated table, containing IPv4-only address objects, when the RADIUS server address represented in such a table row is not an IPv4 address. Managed entities SHOULD NOT return inaccurate values of IP address or SNMP object access errors for IPv4-only address objects in otherwise populated tables. When row entries exist in both the deprecated IPv4-only table and the new IP-version-neutral table that describe the same RADIUS server, the row indexes SHOULD be the same for the corresponding rows in each table, to facilitate correlation of these related rows by management applications. 7. Definitions RADIUS-AUTH-CLIENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Counter32, Integer32, Gauge32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; radiusAuthClientMIB MODULE-IDENTITY LAST-UPDATED "200608210000Z" -- 21 August 2006 ORGANIZATION "IETF RADIUS Extensions Working Group." CONTACT-INFO " Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 Nelson Standards Track [Page 5] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 US Phone: +1 425 936 6605 EMail: bernarda@microsoft.com" DESCRIPTION "The MIB module for entities implementing the client side of the Remote Authentication Dial-In User Service (RADIUS) authentication protocol. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4668; see the RFC itself for full legal notices." REVISION "200608210000Z" -- 21 August 2006 DESCRIPTION "Revised version as published in RFC 4668. This version obsoletes that of RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this version." REVISION "199906110000Z" -- 11 Jun 1999 DESCRIPTION "Initial version as published in RFC 2618." ::= { radiusAuthentication 2 } radiusMIB OBJECT-IDENTITY STATUS current DESCRIPTION "The OID assigned to RADIUS MIB work by the IANA." ::= { mib-2 67 } radiusAuthentication OBJECT IDENTIFIER ::= {radiusMIB 1} radiusAuthClientMIBObjects OBJECT IDENTIFIER ::= { radiusAuthClientMIB 1 } radiusAuthClient OBJECT IDENTIFIER ::= { radiusAuthClientMIBObjects 1 } radiusAuthClientInvalidServerAddresses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Response packets received from unknown addresses." ::= { radiusAuthClient 1 } radiusAuthClientIdentifier OBJECT-TYPE SYNTAX SnmpAdminString Nelson Standards Track [Page 6] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS authentication client. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865 section 5.32" ::= { radiusAuthClient 2 } radiusAuthServerTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusAuthServerEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table listing the RADIUS authentication servers with which the client shares a secret." ::= { radiusAuthClient 3 } radiusAuthServerEntry OBJECT-TYPE SYNTAX RadiusAuthServerEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) representing a RADIUS authentication server with which the client shares a secret." INDEX { radiusAuthServerIndex } ::= { radiusAuthServerTable 1 } RadiusAuthServerEntry ::= SEQUENCE { radiusAuthServerIndex Integer32, radiusAuthServerAddress IpAddress, radiusAuthClientServerPortNumber Integer32, radiusAuthClientRoundTripTime TimeTicks, radiusAuthClientAccessRequests Counter32, radiusAuthClientAccessRetransmissions Counter32, radiusAuthClientAccessAccepts Counter32, radiusAuthClientAccessRejects Counter32, radiusAuthClientAccessChallenges Counter32, radiusAuthClientMalformedAccessResponses Counter32, radiusAuthClientBadAuthenticators Counter32, radiusAuthClientPendingRequests Gauge32, radiusAuthClientTimeouts Counter32, radiusAuthClientUnknownTypes Counter32, radiusAuthClientPacketsDropped Counter32 } radiusAuthServerIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) Nelson Standards Track [Page 7] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A number uniquely identifying each RADIUS Authentication server with which this client communicates." ::= { radiusAuthServerEntry 1 } radiusAuthServerAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The IP address of the RADIUS authentication server referred to in this table entry." ::= { radiusAuthServerEntry 2 } radiusAuthClientServerPortNumber OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The UDP port the client is using to send requests to this server." REFERENCE "RFC 2865 section 3" ::= { radiusAuthServerEntry 3 } radiusAuthClientRoundTripTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The time interval (in hundredths of a second) between the most recent Access-Reply/Access-Challenge and the Access-Request that matched it from this RADIUS authentication server." ::= { radiusAuthServerEntry 4 } -- Request/Response statistics -- -- TotalIncomingPackets = Accepts + Rejects + Challenges + -- UnknownTypes -- -- TotalIncomingPackets - MalformedResponses - -- BadAuthenticators - UnknownTypes - PacketsDropped = -- Successfully received -- -- AccessRequests + PendingRequests + ClientTimeouts = Nelson Standards Track [Page 8] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 -- Successfully received -- -- radiusAuthClientAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Request packets sent to this server. This does not include retransmissions." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthServerEntry 5 } radiusAuthClientAccessRetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Request packets retransmitted to this RADIUS authentication server." REFERENCE "RFC 2865 sections 2.5, 4.1" ::= { radiusAuthServerEntry 6 } radiusAuthClientAccessAccepts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Accept packets (valid or invalid) received from this server." REFERENCE "RFC 2865 section 4.2" ::= { radiusAuthServerEntry 7 } radiusAuthClientAccessRejects OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Reject packets (valid or invalid) received from this server." REFERENCE "RFC 2865 section 4.3" ::= { radiusAuthServerEntry 8 } Nelson Standards Track [Page 9] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 radiusAuthClientAccessChallenges OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Challenge packets (valid or invalid) received from this server." REFERENCE "RFC 2865 section 4.4" ::= { radiusAuthServerEntry 9 } -- "Access-Response" includes an Access-Accept, Access-Challenge -- or Access-Reject radiusAuthClientMalformedAccessResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of malformed RADIUS Access-Response packets received from this server. Malformed packets include packets with an invalid length. Bad authenticators or Message Authenticator attributes or unknown types are not included as malformed access responses." ::= { radiusAuthServerEntry 10 } radiusAuthClientBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Response packets containing invalid authenticators or Message Authenticator attributes received from this server." REFERENCE "RFC 2865 section 3, RFC 2869 section 5.14" ::= { radiusAuthServerEntry 11 } radiusAuthClientPendingRequests OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Request packets destined for this server that have not yet timed out or received a response. This variable is incremented Nelson Standards Track [Page 10] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 when an Access-Request is sent and decremented due to receipt of an Access-Accept, Access-Reject, Access-Challenge, timeout, or retransmission." REFERENCE "RFC 2865 section 2" ::= { radiusAuthServerEntry 12 } radiusAuthClientTimeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of authentication timeouts to this server. After a timeout, the client may retry to the same server, send to a different server, or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as a Request as well as a timeout." REFERENCE "RFC 2865 section 2, RFC 2869 section 2.3.2" ::= { radiusAuthServerEntry 13 } radiusAuthClientUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS packets of unknown type that were received from this server on the authentication port." ::= { radiusAuthServerEntry 14 } radiusAuthClientPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS packets that were received from this server on the authentication port and dropped for some other reason." ::= { radiusAuthServerEntry 15 } -- New MIB Objects in this revision radiusAuthServerExtTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusAuthServerExtEntry Nelson Standards Track [Page 11] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS authentication servers with which the client shares a secret." ::= { radiusAuthClient 4 } radiusAuthServerExtEntry OBJECT-TYPE SYNTAX RadiusAuthServerExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing a RADIUS authentication server with which the client shares a secret." INDEX { radiusAuthServerExtIndex } ::= { radiusAuthServerExtTable 1 } RadiusAuthServerExtEntry ::= SEQUENCE { radiusAuthServerExtIndex Integer32, radiusAuthServerInetAddressType InetAddressType, radiusAuthServerInetAddress InetAddress, radiusAuthClientServerInetPortNumber InetPortNumber, radiusAuthClientExtRoundTripTime TimeTicks, radiusAuthClientExtAccessRequests Counter32, radiusAuthClientExtAccessRetransmissions Counter32, radiusAuthClientExtAccessAccepts Counter32, radiusAuthClientExtAccessRejects Counter32, radiusAuthClientExtAccessChallenges Counter32, radiusAuthClientExtMalformedAccessResponses Counter32, radiusAuthClientExtBadAuthenticators Counter32, radiusAuthClientExtPendingRequests Gauge32, radiusAuthClientExtTimeouts Counter32, radiusAuthClientExtUnknownTypes Counter32, radiusAuthClientExtPacketsDropped Counter32, radiusAuthClientCounterDiscontinuity TimeTicks } radiusAuthServerExtIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS Authentication server with which this client communicates." ::= { radiusAuthServerExtEntry 1 } Nelson Standards Track [Page 12] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 radiusAuthServerInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address format used for the radiusAuthServerInetAddress object." ::= { radiusAuthServerExtEntry 2 } radiusAuthServerInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the RADIUS authentication server referred to in this table entry, using the version-neutral IP address format." ::= { radiusAuthServerExtEntry 3 } radiusAuthClientServerInetPortNumber OBJECT-TYPE SYNTAX InetPortNumber ( 1..65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The UDP port the client is using to send requests to this server. The value of zero (0) is invalid." REFERENCE "RFC 2865 section 3" ::= { radiusAuthServerExtEntry 4 } radiusAuthClientExtRoundTripTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time interval (in hundredths of a second) between the most recent Access-Reply/Access-Challenge and the Access-Request that matched it from this RADIUS authentication server." REFERENCE "RFC 2865 section 2" ::= { radiusAuthServerExtEntry 5 } -- Request/Response statistics -- -- TotalIncomingPackets = Accepts + Rejects + Challenges + -- UnknownTypes -- -- TotalIncomingPackets - MalformedResponses - -- BadAuthenticators - UnknownTypes - PacketsDropped = Nelson Standards Track [Page 13] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 -- Successfully received -- -- AccessRequests + PendingRequests + ClientTimeouts = -- Successfully received -- -- radiusAuthClientExtAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Request packets sent to this server. This does not include retransmissions. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthServerExtEntry 6 } radiusAuthClientExtAccessRetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Request packets retransmitted to this RADIUS authentication server. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 sections 2.5, 4.1" ::= { radiusAuthServerExtEntry 7 } radiusAuthClientExtAccessAccepts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Accept packets (valid or invalid) received from this server. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value Nelson Standards Track [Page 14] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 section 4.2" ::= { radiusAuthServerExtEntry 8 } radiusAuthClientExtAccessRejects OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Reject packets (valid or invalid) received from this server. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 section 4.3" ::= { radiusAuthServerExtEntry 9 } radiusAuthClientExtAccessChallenges OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Challenge packets (valid or invalid) received from this server. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 section 4.4" ::= { radiusAuthServerExtEntry 10 } -- "Access-Response" includes an Access-Accept, Access-Challenge, -- or Access-Reject radiusAuthClientExtMalformedAccessResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Access-Response packets received from this server. Malformed packets include packets with Nelson Standards Track [Page 15] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 an invalid length. Bad authenticators or Message Authenticator attributes or unknown types are not included as malformed access responses. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 sections 3, 4" ::= { radiusAuthServerExtEntry 11 } radiusAuthClientExtBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Response packets containing invalid authenticators or Message Authenticator attributes received from this server. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 section 3" ::= { radiusAuthServerExtEntry 12 } radiusAuthClientExtPendingRequests OBJECT-TYPE SYNTAX Gauge32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an Access-Request is sent and decremented due to receipt of an Access-Accept, Access-Reject, Access-Challenge, timeout, or retransmission." REFERENCE "RFC 2865 section 2" ::= { radiusAuthServerExtEntry 13 } radiusAuthClientExtTimeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of authentication timeouts to this server. Nelson Standards Track [Page 16] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 After a timeout, the client may retry to the same server, send to a different server, or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as a Request as well as a timeout. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 sections 2.5, 4.1" ::= { radiusAuthServerExtEntry 14 } radiusAuthClientExtUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets of unknown type that were received from this server on the authentication port. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." REFERENCE "RFC 2865 section 4" ::= { radiusAuthServerExtEntry 15 } radiusAuthClientExtPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets that were received from this server on the authentication port and dropped for some other reason. This counter may experience a discontinuity when the RADIUS Client module within the managed entity is reinitialized, as indicated by the current value of radiusAuthClientCounterDiscontinuity." ::= { radiusAuthServerExtEntry 16 } radiusAuthClientCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "centiseconds" MAX-ACCESS read-only STATUS current DESCRIPTION Nelson Standards Track [Page 17] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 "The number of centiseconds since the last discontinuity in the RADIUS Client counters. A discontinuity may be the result of a reinitialization of the RADIUS Client module within the managed entity." ::= { radiusAuthServerExtEntry 17 } -- conformance information radiusAuthClientMIBConformance OBJECT IDENTIFIER ::= { radiusAuthClientMIB 2 } radiusAuthClientMIBCompliances OBJECT IDENTIFIER ::= { radiusAuthClientMIBConformance 1 } radiusAuthClientMIBGroups OBJECT IDENTIFIER ::= { radiusAuthClientMIBConformance 2 } -- compliance statements radiusAuthClientMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for authentication clients implementing the RADIUS Authentication Client MIB. Implementation of this module is for IPv4-only entities, or for backwards compatibility use with entities that support both IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthClientMIBGroup } ::= { radiusAuthClientMIBCompliances 1 } radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for authentication clients implementing the RADIUS Authentication Client IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } OBJECT radiusAuthServerInetAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION Nelson Standards Track [Page 18] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusAuthServerInetAddress SYNTAX InetAddress ( SIZE (4|16) ) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." ::= { radiusAuthClientMIBCompliances 2 } -- units of conformance radiusAuthClientMIBGroup OBJECT-GROUP OBJECTS { radiusAuthClientIdentifier, radiusAuthClientInvalidServerAddresses, radiusAuthServerAddress, radiusAuthClientServerPortNumber, radiusAuthClientRoundTripTime, radiusAuthClientAccessRequests, radiusAuthClientAccessRetransmissions, radiusAuthClientAccessAccepts, radiusAuthClientAccessRejects, radiusAuthClientAccessChallenges, radiusAuthClientMalformedAccessResponses, radiusAuthClientBadAuthenticators, radiusAuthClientPendingRequests, radiusAuthClientTimeouts, radiusAuthClientUnknownTypes, radiusAuthClientPacketsDropped } STATUS deprecated DESCRIPTION "The basic collection of objects providing management of RADIUS Authentication Clients." ::= { radiusAuthClientMIBGroups 1 } radiusAuthClientExtMIBGroup OBJECT-GROUP OBJECTS { radiusAuthClientIdentifier, radiusAuthClientInvalidServerAddresses, radiusAuthServerInetAddressType, radiusAuthServerInetAddress, radiusAuthClientServerInetPortNumber, radiusAuthClientExtRoundTripTime, radiusAuthClientExtAccessRequests, radiusAuthClientExtAccessRetransmissions, radiusAuthClientExtAccessAccepts, Nelson Standards Track [Page 19] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 radiusAuthClientExtAccessRejects, radiusAuthClientExtAccessChallenges, radiusAuthClientExtMalformedAccessResponses, radiusAuthClientExtBadAuthenticators, radiusAuthClientExtPendingRequests, radiusAuthClientExtTimeouts, radiusAuthClientExtUnknownTypes, radiusAuthClientExtPacketsDropped, radiusAuthClientCounterDiscontinuity } STATUS current DESCRIPTION "The collection of extended objects providing management of RADIUS Authentication Clients using version-neutral IP address format." ::= { radiusAuthClientMIBGroups 2 } END 8. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: radiusAuthServerIPAddress This can be used to determine the address of the RADIUS authentication server with which the client is communicating. This information could be useful in mounting an attack on the authentication server. radiusAuthClientServerPortNumber This can be used to determine the port number on which the RADIUS authentication client is sending. This information could be useful in impersonating the client in order to send data to the authentication server. Nelson Standards Track [Page 20] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 radiusAuthServerInetAddress This can be used to determine the address of the RADIUS authentication server with which the client is communicating. This information could be useful in mounting an attack on the authentication server. radiusAuthClientServerInetPortNumber This can be used to determine the port number on which the RADIUS authentication client is sending. This information could be useful in impersonating the client in order to send data to the authentication server. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Nelson Standards Track [Page 21] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 9.2. Informative References [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC 2618, June 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006. Nelson Standards Track [Page 22] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 Appendix A. Acknowledgements The authors of the original MIB are Bernard Aboba and Glen Zorn. Many thanks to all reviewers, especially to Dave Harrington, Dan Romascanu, C.M. Heard, Bruno Pape, Greg Weber, and Bert Wijnen. Author's Address David B. Nelson Enterasys Networks 50 Minuteman Road Andover, MA 01810 USA EMail: dnelson@enterasys.com Nelson Standards Track [Page 23] RFC 4668 RADIUS Auth Client MIB (IPv6) August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nelson Standards Track [Page 24] snmp-mibs-downloader-1.1/mibrfcs/rfc4669.txt0000644000000000000000000014253511402176072015605 0ustar Network Working Group D. Nelson Request for Comments: 4669 Enterasys Networks Obsoletes: 2619 August 2006 Category: Standards Track RADIUS Authentication Server MIB for IPv6 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers. This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. Nelson Standards Track [Page 1] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 Table of Contents 1. Introduction ....................................................3 2. Terminology .....................................................3 3. The Internet-Standard Management Framework ......................3 4. Scope of Changes ................................................3 5. Structure of the MIB Module .....................................4 6. Deprecated Objects ..............................................5 7. Definitions .....................................................5 8. Security Considerations ........................................21 9. References .....................................................23 9.1. Normative References ......................................23 9.2. Informative References ....................................23 Appendix A. Acknowledgements ......................................24 Nelson Standards Track [Page 2] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The objects defined within this memo relate to the Remote Authentication Dial-In User Service (RADIUS) Authentication Server as defined in RFC 2865 [RFC2865]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses terminology from RFC 2865 [RFC2865]. This document uses the word "malformed" with respect to RADIUS packets, particularly in the context of counters of "malformed packets". While RFC 2865 does not provide an explicit definition of "malformed", malformed generally means that the implementation has determined the packet does not match the format defined in RFC 2865. Some implementations may determine that packets are malformed when the Vendor Specific Attribute (VSA) format does not follow the RFC 2865 recommendations for VSAs. Those implementations are used in deployments today, and thus set the de facto definition of "malformed". 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Scope of Changes This document obsoletes RFC 2619 [RFC2619], RADIUS Authentication Server MIB, by deprecating the radiusAuthClientTable table and adding a new table, radiusAuthClientExtTable, containing radiusAuthClientInetAddressType and radiusAuthClientInetAddress. The Nelson Standards Track [Page 3] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 purpose of these added MIB objects is to support version-neutral IP addressing formats. The existing table containing radiusAuthClientAddress is deprecated. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. RFC 4001 [RFC4001], which defines the SMI Textual Conventions for version-neutral IP addresses, contains the following recommendation. 'In particular, when revising a MIB module that contains IPv4 specific tables, it is suggested to define new tables using the textual conventions defined in this memo [RFC4001] that support all versions of IP. The status of the new tables SHOULD be "current", whereas the status of the old IP version specific tables SHOULD be changed to "deprecated". The other approach, of having multiple similar tables for different IP versions, is strongly discouraged.' 5. Structure of the MIB Module The RADIUS authentication protocol, described in RFC 2865 [RFC2865], distinguishes between the client function and the server function. In RADIUS authentication, clients send Access-Requests, and servers reply with Access-Accepts, Access-Rejects, and Access-Challenges. Typically, NAS devices implement the client function, and thus would be expected to implement the RADIUS authentication client MIB, while RADIUS authentication servers implement the server function, and thus would be expected to implement the RADIUS authentication server MIB. However, it is possible for a RADIUS authentication entity to perform both client and server functions. For example, a RADIUS proxy may act as a server to one or more RADIUS authentication clients, while simultaneously acting as an authentication client to one or more authentication servers. In such situations, it is expected that RADIUS entities combining client and server functionality will support both the client and server MIBs. The server MIB is defined in this document, and the client MIB is defined in [RFC4668]. This MIB module contains fourteen scalars as well as a single table, the RADIUS Authentication Client Table, which contains one row for each RADIUS authentication client with which the server shares a secret. Each entry in the RADIUS Authentication Client Table includes thirteen columns presenting a view of the activity of the RADIUS authentication server. This MIB imports from [RFC2578], [RFC2580], [RFC3411], and [RFC4001]. Nelson Standards Track [Page 4] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 6. Deprecated Objects The deprecated table in this MIB is carried forward from RFC 2619 [RFC2619]. There are two conditions under which it MAY be desirable for managed entities to continue to support the deprecated table: 1. The managed entity only supports IPv4 address formats. 2. The managed entity supports both IPv4 and IPv6 address formats, and the deprecated table is supported for backwards compatibility with older management stations. This option SHOULD only be used when the IP addresses in the new table are in IPv4 format and can accurately be represented in both the new table and the deprecated table. Managed entities SHOULD NOT instantiate row entries in the deprecated table, containing IPv4-only address objects, when the RADIUS client address represented in such a table row is not an IPv4 address. Managed entities SHOULD NOT return inaccurate values of IP address or SNMP object access errors for IPv4-only address objects in otherwise populated tables. When row entries exist in both the deprecated IPv4-only table and the new IP-version-neutral table that describe the same RADIUS client, the row indexes SHOULD be the same for the corresponding rows in each table, to facilitate correlation of these related rows by management applications. 7. Definitions RADIUS-AUTH-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Counter32, Integer32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; radiusAuthServMIB MODULE-IDENTITY LAST-UPDATED "200608210000Z" -- 21 August 2006 ORGANIZATION "IETF RADIUS Extensions Working Group." CONTACT-INFO " Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 US Phone: +1 425 936 6605 Nelson Standards Track [Page 5] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 EMail: bernarda@microsoft.com" DESCRIPTION "The MIB module for entities implementing the server side of the Remote Authentication Dial-In User Service (RADIUS) authentication protocol. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4669; see the RFC itself for full legal notices." REVISION "200608210000Z" -- 21 August 2006 DESCRIPTION "Revised version as published in RFC 4669. This version obsoletes that of RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this version." REVISION "199906110000Z" -- 11 Jun 1999 DESCRIPTION "Initial version as published in RFC 2619." ::= { radiusAuthentication 1 } radiusMIB OBJECT-IDENTITY STATUS current DESCRIPTION "The OID assigned to RADIUS MIB work by the IANA." ::= { mib-2 67 } radiusAuthentication OBJECT IDENTIFIER ::= {radiusMIB 1} radiusAuthServMIBObjects OBJECT IDENTIFIER ::= { radiusAuthServMIB 1 } radiusAuthServ OBJECT IDENTIFIER ::= { radiusAuthServMIBObjects 1 } radiusAuthServIdent OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The implementation identification string for the RADIUS authentication server software in use on the system, for example, 'FNS-2.1'." ::= {radiusAuthServ 1} radiusAuthServUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current Nelson Standards Track [Page 6] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 DESCRIPTION "If the server has a persistent state (e.g., a process), this value will be the time elapsed (in hundredths of a second) since the server process was started. For software without persistent state, this value will be zero." ::= {radiusAuthServ 2} radiusAuthServResetTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "If the server has a persistent state (e.g., a process) and supports a 'reset' operation (e.g., can be told to re-read configuration files), this value will be the time elapsed (in hundredths of a second) since the server was 'reset.' For software that does not have persistence or does not support a 'reset' operation, this value will be zero." ::= {radiusAuthServ 3} radiusAuthServConfigReset OBJECT-TYPE SYNTAX INTEGER { other(1), reset(2), initializing(3), running(4)} MAX-ACCESS read-write STATUS current DESCRIPTION "Status/action object to reinitialize any persistent server state. When set to reset(2), any persistent server state (such as a process) is reinitialized as if the server had just been started. This value will never be returned by a read operation. When read, one of the following values will be returned: other(1) - server in some unknown state; initializing(3) - server (re)initializing; running(4) - server currently running." ::= {radiusAuthServ 4} radiusAuthServTotalAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received on the Nelson Standards Track [Page 7] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 authentication port." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthServ 5} radiusAuthServTotalInvalidRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Request packets received from unknown addresses." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthServ 6 } radiusAuthServTotalDupAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS Access-Request packets received." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthServ 7 } radiusAuthServTotalAccessAccepts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Accept packets sent." REFERENCE "RFC 2865 section 4.2" ::= { radiusAuthServ 8 } radiusAuthServTotalAccessRejects OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Reject packets sent." REFERENCE "RFC 2865 section 4.3" ::= { radiusAuthServ 9 } radiusAuthServTotalAccessChallenges OBJECT-TYPE SYNTAX Counter32 Nelson Standards Track [Page 8] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Challenge packets sent." REFERENCE "RFC 2865 section 4.4" ::= { radiusAuthServ 10 } radiusAuthServTotalMalformedAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Access-Request packets received. Bad authenticators and unknown types are not included as malformed Access-Requests." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthServ 11 } radiusAuthServTotalBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Authentication-Request packets that contained invalid Message Authenticator attributes received." REFERENCE "RFC 2865 section 3" ::= { radiusAuthServ 12 } radiusAuthServTotalPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets silently discarded for some reason other than malformed, bad authenticators or unknown types." REFERENCE "RFC 2865 section 3" ::= { radiusAuthServ 13 } radiusAuthServTotalUnknownTypes OBJECT-TYPE SYNTAX Counter32 Nelson Standards Track [Page 9] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets of unknown type that were received." REFERENCE "RFC 2865 section 4" ::= { radiusAuthServ 14 } radiusAuthClientTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusAuthClientEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table listing the RADIUS authentication clients with which the server shares a secret." ::= { radiusAuthServ 15 } radiusAuthClientEntry OBJECT-TYPE SYNTAX RadiusAuthClientEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) representing a RADIUS authentication client with which the server shares a secret." INDEX { radiusAuthClientIndex } ::= { radiusAuthClientTable 1 } RadiusAuthClientEntry ::= SEQUENCE { radiusAuthClientIndex Integer32, radiusAuthClientAddress IpAddress, radiusAuthClientID SnmpAdminString, radiusAuthServAccessRequests Counter32, radiusAuthServDupAccessRequests Counter32, radiusAuthServAccessAccepts Counter32, radiusAuthServAccessRejects Counter32, radiusAuthServAccessChallenges Counter32, radiusAuthServMalformedAccessRequests Counter32, radiusAuthServBadAuthenticators Counter32, radiusAuthServPacketsDropped Counter32, radiusAuthServUnknownTypes Counter32 } radiusAuthClientIndex OBJECT-TYPE Nelson Standards Track [Page 10] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A number uniquely identifying each RADIUS authentication client with which this server communicates." ::= { radiusAuthClientEntry 1 } radiusAuthClientAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The NAS-IP-Address of the RADIUS authentication client referred to in this table entry." REFERENCE "RFC 2865 section 2" ::= { radiusAuthClientEntry 2 } radiusAuthClientID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The NAS-Identifier of the RADIUS authentication client referred to in this table entry. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865 section 5.32" ::= { radiusAuthClientEntry 3 } -- Server Counters -- -- Responses = AccessAccepts + AccessRejects + AccessChallenges -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped - Responses = Pending -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped = entries logged radiusAuthServAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of packets received on the authentication Nelson Standards Track [Page 11] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 port from this client." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthClientEntry 4 } radiusAuthServDupAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of duplicate RADIUS Access-Request packets received from this client." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthClientEntry 5 } radiusAuthServAccessAccepts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Accept packets sent to this client." REFERENCE "RFC 2865 section 4.2" ::= { radiusAuthClientEntry 6 } radiusAuthServAccessRejects OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Reject packets sent to this client." REFERENCE "RFC 2865 section 4.3" ::= { radiusAuthClientEntry 7 } radiusAuthServAccessChallenges OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Access-Challenge packets sent to this client." REFERENCE "RFC 2865 section 4.4" ::= { radiusAuthClientEntry 8 } Nelson Standards Track [Page 12] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 radiusAuthServMalformedAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of malformed RADIUS Access-Request packets received from this client. Bad authenticators and unknown types are not included as malformed Access-Requests." REFERENCE "RFC 2865 section 3" ::= { radiusAuthClientEntry 9 } radiusAuthServBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Authentication-Request packets that contained invalid Message Authenticator attributes received from this client." REFERENCE "RFC 2865 section 3" ::= { radiusAuthClientEntry 10 } radiusAuthServPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of incoming packets from this client silently discarded for some reason other than malformed, bad authenticators or unknown types." REFERENCE "RFC 2865 section 3" ::= { radiusAuthClientEntry 11 } radiusAuthServUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS packets of unknown type that were received from this client." REFERENCE "RFC 2865 section 4" ::= { radiusAuthClientEntry 12 } Nelson Standards Track [Page 13] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 -- New MIB objects added in this revision radiusAuthClientExtTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusAuthClientExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS authentication clients with which the server shares a secret." ::= { radiusAuthServ 16 } radiusAuthClientExtEntry OBJECT-TYPE SYNTAX RadiusAuthClientExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing a RADIUS authentication client with which the server shares a secret." INDEX { radiusAuthClientExtIndex } ::= { radiusAuthClientExtTable 1 } RadiusAuthClientExtEntry ::= SEQUENCE { radiusAuthClientExtIndex Integer32, radiusAuthClientInetAddressType InetAddressType, radiusAuthClientInetAddress InetAddress, radiusAuthClientExtID SnmpAdminString, radiusAuthServExtAccessRequests Counter32, radiusAuthServExtDupAccessRequests Counter32, radiusAuthServExtAccessAccepts Counter32, radiusAuthServExtAccessRejects Counter32, radiusAuthServExtAccessChallenges Counter32, radiusAuthServExtMalformedAccessRequests Counter32, radiusAuthServExtBadAuthenticators Counter32, radiusAuthServExtPacketsDropped Counter32, radiusAuthServExtUnknownTypes Counter32, radiusAuthServCounterDiscontinuity TimeTicks } radiusAuthClientExtIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS authentication client with which this server communicates." Nelson Standards Track [Page 14] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 ::= { radiusAuthClientExtEntry 1 } radiusAuthClientInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address format used for the radiusAuthClientInetAddress object." ::= { radiusAuthClientExtEntry 2 } radiusAuthClientInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the RADIUS authentication client referred to in this table entry, using the version-neutral IP address format." ::= { radiusAuthClientExtEntry 3 } radiusAuthClientExtID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS authentication client referred to in this table entry. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865 section 5.32" ::= { radiusAuthClientExtEntry 4 } -- Server Counters -- -- Responses = AccessAccepts + AccessRejects + AccessChallenges -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped - Responses = Pending -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped = entries logged radiusAuthServExtAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only Nelson Standards Track [Page 15] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 STATUS current DESCRIPTION "The number of packets received on the authentication port from this client. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthClientExtEntry 5 } radiusAuthServExtDupAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS Access-Request packets received from this client. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 section 4.1" ::= { radiusAuthClientExtEntry 6 } radiusAuthServExtAccessAccepts OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Accept packets sent to this client. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 section 4.2" ::= { radiusAuthClientExtEntry 7 } radiusAuthServExtAccessRejects OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Reject packets sent to this client. This counter may experience a discontinuity when the RADIUS Server module within the Nelson Standards Track [Page 16] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 section 4.3" ::= { radiusAuthClientExtEntry 8 } radiusAuthServExtAccessChallenges OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Challenge packets sent to this client. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 section 4.4" ::= { radiusAuthClientExtEntry 9 } radiusAuthServExtMalformedAccessRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Access-Request packets received from this client. Bad authenticators and unknown types are not included as malformed Access-Requests. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 sections 3, 4.1" ::= { radiusAuthClientExtEntry 10 } radiusAuthServExtBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Authentication-Request packets that contained invalid Message Authenticator attributes received from this client. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." Nelson Standards Track [Page 17] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 REFERENCE "RFC 2865 section 3" ::= { radiusAuthClientExtEntry 11 } radiusAuthServExtPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets from this client silently discarded for some reason other than malformed, bad authenticators or unknown types. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 section 3" ::= { radiusAuthClientExtEntry 12 } radiusAuthServExtUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets of unknown type that were received from this client. This counter may experience a discontinuity when the RADIUS Server module within the managed entity is reinitialized, as indicated by the current value of radiusAuthServCounterDiscontinuity." REFERENCE "RFC 2865 section 4" ::= { radiusAuthClientExtEntry 13 } radiusAuthServCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "centiseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of centiseconds since the last discontinuity in the RADIUS Server counters. A discontinuity may be the result of a reinitialization of the RADIUS Server module within the managed entity." ::= { radiusAuthClientExtEntry 14 } Nelson Standards Track [Page 18] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 -- conformance information radiusAuthServMIBConformance OBJECT IDENTIFIER ::= { radiusAuthServMIB 2 } radiusAuthServMIBCompliances OBJECT IDENTIFIER ::= { radiusAuthServMIBConformance 1 } radiusAuthServMIBGroups OBJECT IDENTIFIER ::= { radiusAuthServMIBConformance 2 } -- compliance statements radiusAuthServMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for authentication servers implementing the RADIUS Authentication Server MIB. Implementation of this module is for IPv4-only entities, or for backwards compatibility use with entities that support both IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthServMIBGroup } OBJECT radiusAuthServConfigReset WRITE-SYNTAX INTEGER { reset(2) } DESCRIPTION "The only SETable value is 'reset' (2)." ::= { radiusAuthServMIBCompliances 1 } radiusAuthServMIBExtCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for authentication servers implementing the RADIUS Authentication Server IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthServExtMIBGroup } OBJECT radiusAuthServConfigReset WRITE-SYNTAX INTEGER { reset(2) } DESCRIPTION "The only SETable value is 'reset' (2)." OBJECT radiusAuthClientInetAddressType Nelson Standards Track [Page 19] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusAuthClientInetAddress SYNTAX InetAddress ( SIZE (4|16) ) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." ::= { radiusAuthServMIBCompliances 2 } -- units of conformance radiusAuthServMIBGroup OBJECT-GROUP OBJECTS {radiusAuthServIdent, radiusAuthServUpTime, radiusAuthServResetTime, radiusAuthServConfigReset, radiusAuthServTotalAccessRequests, radiusAuthServTotalInvalidRequests, radiusAuthServTotalDupAccessRequests, radiusAuthServTotalAccessAccepts, radiusAuthServTotalAccessRejects, radiusAuthServTotalAccessChallenges, radiusAuthServTotalMalformedAccessRequests, radiusAuthServTotalBadAuthenticators, radiusAuthServTotalPacketsDropped, radiusAuthServTotalUnknownTypes, radiusAuthClientAddress, radiusAuthClientID, radiusAuthServAccessRequests, radiusAuthServDupAccessRequests, radiusAuthServAccessAccepts, radiusAuthServAccessRejects, radiusAuthServAccessChallenges, radiusAuthServMalformedAccessRequests, radiusAuthServBadAuthenticators, radiusAuthServPacketsDropped, radiusAuthServUnknownTypes } STATUS deprecated DESCRIPTION "The collection of objects providing management of a RADIUS Authentication Server." ::= { radiusAuthServMIBGroups 1 } Nelson Standards Track [Page 20] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 radiusAuthServExtMIBGroup OBJECT-GROUP OBJECTS {radiusAuthServIdent, radiusAuthServUpTime, radiusAuthServResetTime, radiusAuthServConfigReset, radiusAuthServTotalAccessRequests, radiusAuthServTotalInvalidRequests, radiusAuthServTotalDupAccessRequests, radiusAuthServTotalAccessAccepts, radiusAuthServTotalAccessRejects, radiusAuthServTotalAccessChallenges, radiusAuthServTotalMalformedAccessRequests, radiusAuthServTotalBadAuthenticators, radiusAuthServTotalPacketsDropped, radiusAuthServTotalUnknownTypes, radiusAuthClientInetAddressType, radiusAuthClientInetAddress, radiusAuthClientExtID, radiusAuthServExtAccessRequests, radiusAuthServExtDupAccessRequests, radiusAuthServExtAccessAccepts, radiusAuthServExtAccessRejects, radiusAuthServExtAccessChallenges, radiusAuthServExtMalformedAccessRequests, radiusAuthServExtBadAuthenticators, radiusAuthServExtPacketsDropped, radiusAuthServExtUnknownTypes, radiusAuthServCounterDiscontinuity } STATUS current DESCRIPTION "The collection of objects providing management of a RADIUS Authentication Server." ::= { radiusAuthServMIBGroups 2 } END 8. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are: Nelson Standards Track [Page 21] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 radiusAuthServConfigReset This object can be used to reinitialize the persistent state of any server. When set to reset(2), any persistent server state (such as a process) is reinitialized as if the server had just been started. Depending on the server implementation details, this action may or may not interrupt the processing of pending request in the server. Abuse of this object may lead to a Denial of Service attack on the server. There are a number of managed objects in this MIB that may contain sensitive information. These are: radiusAuthClientIPAddress This can be used to determine the address of the RADIUS authentication client with which the server is communicating. This information could be useful in mounting an attack on the authentication client. radiusAuthClientInetAddress This can be used to determine the address of the RADIUS authentication client with which the server is communicating. This information could be useful in mounting an attack on the authentication client. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMP versions prior to SNMPv3 do not provide a secure environment. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Nelson Standards Track [Page 22] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 9.2. Informative References [RFC2619] Zorn, G. and B. Aboba, "RADIUS Authentication Server MIB", RFC 2619, June 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006. Nelson Standards Track [Page 23] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 Appendix A. Acknowledgements The authors of the original MIB are Bernard Aboba and Glen Zorn. Many thanks to all reviewers, especially to David Harrington, Dan Romascanu, C.M. Heard, Bruno Pape, Greg Weber, and Bert Wijnen. Author's Address David B. Nelson Enterasys Networks 50 Minuteman Road Andover, MA 01810 USA EMail: dnelson@enterasys.com Nelson Standards Track [Page 24] RFC 4669 RADIUS Auth Server MIB (IPv6) August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nelson Standards Track [Page 25] snmp-mibs-downloader-1.1/mibrfcs/rfc4670.txt0000644000000000000000000012717311402176072015576 0ustar Network Working Group D. Nelson Request for Comments: 4670 Enterasys Networks Obsoletes: 2620 August 2006 Category: Informational RADIUS Accounting Client MIB for IPv6 Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients. This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. Nelson Informational [Page 1] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 Table of Contents 1. Introduction ....................................................3 2. Terminology .....................................................3 3. The Internet-Standard Management Framework ......................3 4. Scope of Changes ................................................3 5. Structure of the MIB Module .....................................4 6. Deprecated Objects ..............................................5 7. Definitions .....................................................5 8. Security Considerations ........................................19 9. References .....................................................20 9.1. Normative References ......................................20 9.2. Informative References ....................................21 Appendix A. Acknowledgements ......................................22 Nelson Informational [Page 2] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The objects defined within this memo relate to the Remote Authentication Dial-In User Service (RADIUS) Accounting Client as defined in RFC 2866 [RFC2866]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses terminology from RFC 2865 [RFC2865] and RFC 2866 [RFC2866]. This document uses the word "malformed" with respect to RADIUS packets, particularly in the context of counters of "malformed packets". While RFC 2866 does not provide an explicit definition of "malformed", malformed generally means that the implementation has determined the packet does not match the format defined in RFC 2866. Those implementations are used in deployments today, and thus set the de facto definition of "malformed". 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Scope of Changes This document obsoletes RFC 2620 [RFC2620], RADIUS Accounting Client MIB, by deprecating the radiusAccServerTable table and adding a new table, radiusAccServerExtTable, containing radiusAccServerInetAddressType, radiusAccServerInetAddress, and radiusAccClientServerInetPortNumber. The purpose of these added MIB objects is to support version-neutral IP addressing formats. The Nelson Informational [Page 3] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 existing table containing radiusAuthServerAddress and radiusAuthClientServerPortNumber is deprecated. The remaining MIB objects from RFC 2620 are carried forward into this document. RFC 4001 [RFC4001], which defines the SMI Textual Conventions for IPv6 addresses, contains the following recommendation. 'In particular, when revising a MIB module that contains IPv4 specific tables, it is suggested to define new tables using the textual conventions defined in this memo [RFC4001] that support all versions of IP. The status of the new tables SHOULD be "current", whereas the status of the old IP version specific tables SHOULD be changed to "deprecated". The other approach, of having multiple similar tables for different IP versions, is strongly discouraged.' 5. Structure of the MIB Module The RADIUS accounting protocol, described in RFC 2866 [RFC2866], distinguishes between the client function and the server function. In RADIUS accounting, clients send Accounting-Requests, and servers reply with Accounting-Responses. Typically, Network Access Server (NAS) devices implement the client function, and thus would be expected to implement the RADIUS accounting client MIB, while RADIUS accounting servers implement the server function, and thus would be expected to implement the RADIUS accounting server MIB. However, it is possible for a RADIUS accounting entity to perform both client and server functions. For example, a RADIUS proxy may act as a server to one or more RADIUS accounting clients, while simultaneously acting as an accounting client to one or more accounting servers. In such situations, it is expected that RADIUS entities combining client and server functionality will support both the client and server MIBs. The client MIB is defined in this document, and the server MIB is defined in [RFC4671]. This MIB module contains two scalars as well as a single table, the RADIUS Accounting Server Table, which contains one row for each RADIUS server with which the client shares a secret. Each entry in the RADIUS Accounting Server Table includes fifteen columns presenting a view of the activity of the RADIUS client. This MIB imports from [RFC2578], [RFC2580], [RFC3411], and [RFC4001]. Nelson Informational [Page 4] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 6. Deprecated Objects The deprecated table in this MIB is carried forward from RFC 2620 [RFC2620]. There are two conditions under which it MAY be desirable for managed entities to continue to support the deprecated table: 1. The managed entity only supports IPv4 address formats. 2. The managed entity supports both IPv4 and IPv6 address formats, and the deprecated table is supported for backwards compatibility with older management stations. This option SHOULD only be used when the IP addresses in the new table are in IPv4 format and can accurately be represented in both the new table and the deprecated table. Managed entities SHOULD NOT instantiate row entries in the deprecated table, containing IPv4-only address objects, when the RADIUS accounting server address represented in such a table row is not an IPv4 address. Managed entities SHOULD NOT return inaccurate values of IP address or SNMP object access errors for IPv4-only address objects in otherwise populated tables. When row entries exist in both the deprecated IPv4-only table and the new IP-version-neutral table that describe the same RADIUS accounting server, the row indexes SHOULD be the same for the corresponding rows in each table, to facilitate correlation of these related rows by management applications. 7. Definitions RADIUS-ACC-CLIENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Counter32, Integer32, Gauge32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; radiusAccClientMIB MODULE-IDENTITY LAST-UPDATED "200608210000Z" -- 21 August 2006 ORGANIZATION "IETF RADIUS Extensions Working Group." CONTACT-INFO " Bernard Aboba Microsoft One Microsoft Way Nelson Informational [Page 5] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 Redmond, WA 98052 US Phone: +1 425 936 6605 EMail: bernarda@microsoft.com" DESCRIPTION "The MIB module for entities implementing the client side of the Remote Authentication Dial-In User Service (RADIUS) accounting protocol. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4670; see the RFC itself for full legal notices." REVISION "200608210000Z" -- 21 August 2006 DESCRIPTION "Revised version as published in RFC 4670. This version obsoletes that of RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this version." REVISION "199906110000Z" -- 11 Jun 1999 DESCRIPTION "Initial version as published in RFC 2620." ::= { radiusAccounting 2 } radiusMIB OBJECT-IDENTITY STATUS current DESCRIPTION "The OID assigned to RADIUS MIB work by the IANA." ::= { mib-2 67 } radiusAccounting OBJECT IDENTIFIER ::= {radiusMIB 2} radiusAccClientMIBObjects OBJECT IDENTIFIER ::= { radiusAccClientMIB 1 } radiusAccClient OBJECT IDENTIFIER ::= { radiusAccClientMIBObjects 1 } radiusAccClientInvalidServerAddresses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Response packets received from unknown addresses." ::= { radiusAccClient 1 } Nelson Informational [Page 6] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 radiusAccClientIdentifier OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS accounting client. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865 section 5.32" ::= { radiusAccClient 2 } radiusAccServerTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusAccServerEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table listing the RADIUS accounting servers with which the client shares a secret." ::= { radiusAccClient 3 } radiusAccServerEntry OBJECT-TYPE SYNTAX RadiusAccServerEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) representing a RADIUS accounting server with which the client shares a secret." INDEX { radiusAccServerIndex } ::= { radiusAccServerTable 1 } RadiusAccServerEntry ::= SEQUENCE { radiusAccServerIndex Integer32, radiusAccServerAddress IpAddress, radiusAccClientServerPortNumber Integer32, radiusAccClientRoundTripTime TimeTicks, radiusAccClientRequests Counter32, radiusAccClientRetransmissions Counter32, radiusAccClientResponses Counter32, radiusAccClientMalformedResponses Counter32, radiusAccClientBadAuthenticators Counter32, radiusAccClientPendingRequests Gauge32, radiusAccClientTimeouts Counter32, radiusAccClientUnknownTypes Counter32, radiusAccClientPacketsDropped Counter32 } Nelson Informational [Page 7] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 radiusAccServerIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A number uniquely identifying each RADIUS Accounting server with which this client communicates." ::= { radiusAccServerEntry 1 } radiusAccServerAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The IP address of the RADIUS accounting server referred to in this table entry." ::= { radiusAccServerEntry 2 } radiusAccClientServerPortNumber OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The UDP port the client is using to send requests to this server." REFERENCE "RFC 2866 section 3" ::= { radiusAccServerEntry 3 } radiusAccClientRoundTripTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The time interval between the most recent Accounting-Response and the Accounting-Request that matched it from this RADIUS accounting server." REFERENCE "RFC 2866 section 2" ::= { radiusAccServerEntry 4 } -- Request/Response statistics -- -- Requests = Responses + PendingRequests + ClientTimeouts -- -- Responses - MalformedResponses - BadAuthenticators - -- UnknownTypes - PacketsDropped = Successfully received Nelson Informational [Page 8] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 radiusAccClientRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Accounting-Request packets sent. This does not include retransmissions." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccServerEntry 5 } radiusAccClientRetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Accounting-Request packets retransmitted to this RADIUS accounting server. Retransmissions include retries where the Identifier and Acct-Delay have been updated, as well as those in which they remain the same." REFERENCE "RFC 2866 section 2" ::= { radiusAccServerEntry 6 } radiusAccClientResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS packets received on the accounting port from this server." REFERENCE "RFC 2866 section 4.2" ::= { radiusAccServerEntry 7 } radiusAccClientMalformedResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of malformed RADIUS Accounting-Response packets received from this server. Malformed packets include packets with an invalid length. Bad authenticators and unknown types are not included as malformed accounting responses." REFERENCE "RFC 2866 section 3" Nelson Informational [Page 9] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 ::= { radiusAccServerEntry 8 } radiusAccClientBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Accounting-Response packets that contained invalid authenticators received from this server." REFERENCE "RFC 2866 section 3" ::= { radiusAccServerEntry 9 } radiusAccClientPendingRequests OBJECT-TYPE SYNTAX Gauge32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Accounting-Request packets sent to this server that have not yet timed out or received a response. This variable is incremented when an Accounting-Request is sent and decremented due to receipt of an Accounting-Response, a timeout, or a retransmission." REFERENCE "RFC 2866 section 2" ::= { radiusAccServerEntry 10 } radiusAccClientTimeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of accounting timeouts to this server. After a timeout, the client may retry to the same server, send to a different server, or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as an Accounting-Request as well as a timeout." REFERENCE "RFC 2866 section 2" ::= { radiusAccServerEntry 11 } radiusAccClientUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" Nelson Informational [Page 10] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS packets of unknown type that were received from this server on the accounting port." REFERENCE "RFC 2866 section 4" ::= { radiusAccServerEntry 12 } radiusAccClientPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS packets that were received from this server on the accounting port and dropped for some other reason." ::= { radiusAccServerEntry 13 } -- New MIB objects added in this revision radiusAccServerExtTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusAccServerExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS accounting servers with which the client shares a secret." ::= { radiusAccClient 4 } radiusAccServerExtEntry OBJECT-TYPE SYNTAX RadiusAccServerExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing a RADIUS accounting server with which the client shares a secret." INDEX { radiusAccServerExtIndex } ::= { radiusAccServerExtTable 1 } RadiusAccServerExtEntry ::= SEQUENCE { radiusAccServerExtIndex Integer32, radiusAccServerInetAddressType InetAddressType, radiusAccServerInetAddress InetAddress, radiusAccClientServerInetPortNumber InetPortNumber, radiusAccClientExtRoundTripTime TimeTicks, Nelson Informational [Page 11] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 radiusAccClientExtRequests Counter32, radiusAccClientExtRetransmissions Counter32, radiusAccClientExtResponses Counter32, radiusAccClientExtMalformedResponses Counter32, radiusAccClientExtBadAuthenticators Counter32, radiusAccClientExtPendingRequests Gauge32, radiusAccClientExtTimeouts Counter32, radiusAccClientExtUnknownTypes Counter32, radiusAccClientExtPacketsDropped Counter32, radiusAccClientCounterDiscontinuity TimeTicks } radiusAccServerExtIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS Accounting server with which this client communicates." ::= { radiusAccServerExtEntry 1 } radiusAccServerInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address format used for the radiusAccServerInetAddress object." ::= { radiusAccServerExtEntry 2 } radiusAccServerInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the RADIUS accounting server referred to in this table entry, using the version-neutral IP address format." ::= { radiusAccServerExtEntry 3 } radiusAccClientServerInetPortNumber OBJECT-TYPE SYNTAX InetPortNumber ( 1..65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION Nelson Informational [Page 12] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 "The UDP port the client is using to send requests to this accounting server. The value zero (0) is invalid." REFERENCE "RFC 2866 section 3" ::= { radiusAccServerExtEntry 4 } radiusAccClientExtRoundTripTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time interval between the most recent Accounting-Response and the Accounting-Request that matched it from this RADIUS accounting server." REFERENCE "RFC 2866 section 2" ::= { radiusAccServerExtEntry 5 } -- Request/Response statistics -- -- Requests = Responses + PendingRequests + ClientTimeouts -- -- Responses - MalformedResponses - BadAuthenticators - -- UnknownTypes - PacketsDropped = Successfully received radiusAccClientExtRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets sent. This does not include retransmissions. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccServerExtEntry 6 } radiusAccClientExtRetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets retransmitted to this RADIUS accounting server. Nelson Informational [Page 13] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 Retransmissions include retries where the Identifier and Acct-Delay have been updated, as well as those in which they remain the same. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 2" ::= { radiusAccServerExtEntry 7 } radiusAccClientExtResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets received on the accounting port from this server. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 4.2" ::= { radiusAccServerExtEntry 8 } radiusAccClientExtMalformedResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Accounting-Response packets received from this server. Malformed packets include packets with an invalid length. Bad authenticators and unknown types are not included as malformed accounting responses. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 3" ::= { radiusAccServerExtEntry 9 } radiusAccClientExtBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current Nelson Informational [Page 14] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 DESCRIPTION "The number of RADIUS Accounting-Response packets that contained invalid authenticators received from this server. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 3" ::= { radiusAccServerExtEntry 10 } radiusAccClientExtPendingRequests OBJECT-TYPE SYNTAX Gauge32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets sent to this server that have not yet timed out or received a response. This variable is incremented when an Accounting-Request is sent and decremented due to receipt of an Accounting-Response, a timeout, or a retransmission. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 2" ::= { radiusAccServerExtEntry 11 } radiusAccClientExtTimeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of accounting timeouts to this server. After a timeout, the client may retry to the same server, send to a different server, or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as an Accounting-Request as well as a timeout. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 2" Nelson Informational [Page 15] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 ::= { radiusAccServerExtEntry 12 } radiusAccClientExtUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets of unknown type that were received from this server on the accounting port. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." REFERENCE "RFC 2866 section 4" ::= { radiusAccServerExtEntry 13 } radiusAccClientExtPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets that were received from this server on the accounting port and dropped for some other reason. This counter may experience a discontinuity when the RADIUS Accounting Client module within the managed entity is reinitialized, as indicated by the current value of radiusAccClientCounterDiscontinuity." ::= { radiusAccServerExtEntry 14 } radiusAccClientCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "centiseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of centiseconds since the last discontinuity in the RADIUS Accounting Client counters. A discontinuity may be the result of a reinitialization of the RADIUS Accounting Client module within the managed entity." ::= { radiusAccServerExtEntry 15 } Nelson Informational [Page 16] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 -- conformance information radiusAccClientMIBConformance OBJECT IDENTIFIER ::= { radiusAccClientMIB 2 } radiusAccClientMIBCompliances OBJECT IDENTIFIER ::= { radiusAccClientMIBConformance 1 } radiusAccClientMIBGroups OBJECT IDENTIFIER ::= { radiusAccClientMIBConformance 2 } -- units of conformance radiusAccClientMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for accounting clients implementing the RADIUS Accounting Client MIB. Implementation of this module is for IPv4-only entities, or for backwards compatibility use with entities that support both IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAccClientMIBGroup } ::= { radiusAccClientMIBCompliances 1 } radiusAccClientExtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for accounting clients implementing the RADIUS Accounting Client IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAccClientExtMIBGroup } OBJECT radiusAccServerInetAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusAccServerInetAddress SYNTAX InetAddress ( SIZE (4|16) ) DESCRIPTION Nelson Informational [Page 17] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 "An implementation is only required to support IPv4 and globally unique IPv6 addresses." ::= { radiusAccClientMIBCompliances 2 } -- units of conformance radiusAccClientMIBGroup OBJECT-GROUP OBJECTS { radiusAccClientIdentifier, radiusAccClientInvalidServerAddresses, radiusAccServerAddress, radiusAccClientServerPortNumber, radiusAccClientRoundTripTime, radiusAccClientRequests, radiusAccClientRetransmissions, radiusAccClientResponses, radiusAccClientMalformedResponses, radiusAccClientBadAuthenticators, radiusAccClientPendingRequests, radiusAccClientTimeouts, radiusAccClientUnknownTypes, radiusAccClientPacketsDropped } STATUS deprecated DESCRIPTION "The basic collection of objects providing management of RADIUS Accounting Clients." ::= { radiusAccClientMIBGroups 1 } radiusAccClientExtMIBGroup OBJECT-GROUP OBJECTS { radiusAccClientIdentifier, radiusAccClientInvalidServerAddresses, radiusAccServerInetAddressType, radiusAccServerInetAddress, radiusAccClientServerInetPortNumber, radiusAccClientExtRoundTripTime, radiusAccClientExtRequests, radiusAccClientExtRetransmissions, radiusAccClientExtResponses, radiusAccClientExtMalformedResponses, radiusAccClientExtBadAuthenticators, radiusAccClientExtPendingRequests, radiusAccClientExtTimeouts, radiusAccClientExtUnknownTypes, radiusAccClientExtPacketsDropped, radiusAccClientCounterDiscontinuity Nelson Informational [Page 18] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 } STATUS current DESCRIPTION "The basic collection of objects providing management of RADIUS Accounting Clients." ::= { radiusAccClientMIBGroups 2 } END 8. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. There are a number of managed objects in this MIB that may contain sensitive information. These are: radiusAcctServerIPAddress This can be used to determine the address of the RADIUS accounting server with which the client is communicating. This information could be useful in mounting an attack on the accounting server. radiusAcctServerInetAddress This can be used to determine the address of the RADIUS accounting server with which the client is communicating. This information could be useful in mounting an attack on the accounting server. radiusAcctClientServerPortNumber This can be used to determine the port number on which the RADIUS accounting client is sending. This information could be useful in impersonating the client in order to send data to the accounting server. radiusAcctClientServerInetPortNumber This can be used to determine the port number on which the RADIUS accounting client is sending. This information could be useful in impersonating the client in order to send data to the accounting server. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. Nelson Informational [Page 19] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 SNMP versions prior to SNMPv3 do not provide a secure environment. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. Nelson Informational [Page 20] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 9.2. Informative References [RFC2620] Aboba, B. and G. Zorn, "RADIUS Accounting Client MIB", RFC 2620, June 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006. Nelson Informational [Page 21] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 Appendix A. Acknowledgements The authors of the original MIB are Bernard Aboba and Glen Zorn. Many thanks to all reviewers, especially to Dave Harrington, Dan Romascanu, C.M. Heard, Bruno Pape, Greg Weber, and Bert Wijnen. Author's Address David B. Nelson Enterasys Networks 50 Minuteman Road Andover, MA 01810 USA EMail: dnelson@enterasys.com Nelson Informational [Page 22] RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nelson Informational [Page 23] snmp-mibs-downloader-1.1/mibrfcs/rfc4671.txt0000644000000000000000000013511611402176072015573 0ustar Network Working Group D. Nelson Request for Comments: 4671 Enterasys Networks Obsoletes: 2621 August 2006 Category: Informational RADIUS Accounting Server MIB for IPv6 Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers. This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. Nelson Informational [Page 1] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 Table of Contents 1. Introduction ....................................................3 2. Terminology .....................................................3 3. The Internet-Standard Management Framework ......................3 4. Scope of Changes ................................................3 5. Structure of the MIB Module .....................................4 6. Deprecated Objects ..............................................5 7. Definitions .....................................................5 8. Security Considerations ........................................20 9. References .....................................................22 9.1. Normative References ......................................22 9.2. Informative References ....................................22 Appendix A. Acknowledgements ......................................23 Nelson Informational [Page 2] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The objects defined within this memo relate to the Remote Authentication Dial-In User Service (RADIUS) Accounting Server as defined in RFC 2866 [RFC2866]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses terminology from RFC 2865 [RFC2865] and RFC 2866 [RFC2866]. This document uses the word "malformed" with respect to RADIUS packets, particularly in the context of counters of "malformed packets". While RFC 2866 does not provide an explicit definition of "malformed", malformed generally means that the implementation has determined the packet does not match the format defined in RFC 2866. Those implementations are used in deployments today, and thus set the de facto definition of "malformed". 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Scope of Changes This document obsoletes RFC 2621 [RFC2621], RADIUS Accounting Server MIB, by deprecating the radiusAccClientTable table and adding a new table, radiusAccClientExtTable, containing radiusAccClientInetAddressType and radiusAccClientInetAddress. The purpose of these added MIB objects is to support version-neutral IP addressing formats. The existing table containing Nelson Informational [Page 3] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 radiusAccClientAddress is deprecated. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. RFC 4001 [RFC4001], which defines the SMI Textual Conventions for version-neutral IP addresses, contains the following recommendation. 'In particular, when revising a MIB module that contains IPv4 specific tables, it is suggested to define new tables using the textual conventions defined in this memo [RFC4001] that support all versions of IP. The status of the new tables SHOULD be "current", whereas the status of the old IP version specific tables SHOULD be changed to "deprecated". The other approach, of having multiple similar tables for different IP versions, is strongly discouraged.' 5. Structure of the MIB Module The RADIUS accounting protocol, described in RFC 2866 [RFC2866], distinguishes between the client function and the server function. In RADIUS accounting, clients send Accounting-Requests, and servers reply with Accounting-Responses. Typically, Network Access Server (NAS) devices implement the client function, and thus would be expected to implement the RADIUS accounting client MIB, while RADIUS accounting servers implement the server function, and thus would be expected to implement the RADIUS accounting server MIB. However, it is possible for a RADIUS accounting entity to perform both client and server functions. For example, a RADIUS proxy may act as a server to one or more RADIUS accounting clients, while simultaneously acting as an accounting client to one or more accounting servers. In such situations, it is expected that RADIUS entities combining client and server functionality will support both the client and server MIBs. The server MIB is defined in this document, and the client MIB is defined in [RFC4670]. This MIB module contains thirteen scalars as well as a single table, the RADIUS Accounting Client Table, which contains one row for each RADIUS accounting client with which the server shares a secret. Each entry in the RADIUS Accounting Client Table includes twelve columns presenting a view of the activity of the RADIUS accounting server. This MIB imports from [RFC2578], [RFC2580], [RFC3411], and [RFC4001]. Nelson Informational [Page 4] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 6. Deprecated Objects The deprecated table in this MIB is carried forward from RFC 2621 [RFC2621]. There are two conditions under which it MAY be desirable for managed entities to continue to support the deprecated table: 1. The managed entity only supports IPv4 address formats. 2. The managed entity supports both IPv4 and IPv6 address formats, and the deprecated table is supported for backwards compatibility with older management stations. This option SHOULD only be used when the IP addresses in the new table are in IPv4 format and can accurately be represented in both the new table and the deprecated table. Managed entities SHOULD NOT instantiate row entries in the deprecated table, containing IPv4-only address objects, when the RADIUS accounting client address represented in such a table row is not an IPv4 address. Managed entities SHOULD NOT return inaccurate values of IP address or SNMP object access errors for IPv4-only address objects in otherwise populated tables. When row entries exist in both the deprecated IPv4-only table and the new IP-version-neutral table that describe the same RADIUS accounting client, the row indexes SHOULD be the same for the corresponding rows in each table, to facilitate correlation of these related rows by management applications. 7. Definitions RADIUS-ACC-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Counter32, Integer32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; radiusAccServMIB MODULE-IDENTITY LAST-UPDATED "200608210000Z" -- 21 August 2006 ORGANIZATION "IETF RADIUS Extensions Working Group." CONTACT-INFO " Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 US Nelson Informational [Page 5] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 Phone: +1 425 936 6605 EMail: bernarda@microsoft.com" DESCRIPTION "The MIB module for entities implementing the server side of the Remote Authentication Dial-In User Service (RADIUS) accounting protocol. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4671; see the RFC itself for full legal notices." REVISION "200608210000Z" -- 21 August 2006 DESCRIPTION "Revised version as published in RFC 4671. This version obsoletes that of RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version- neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this version." REVISION "199906110000Z" -- 11 Jun 1999 DESCRIPTION "Initial version as published in RFC 2621." ::= { radiusAccounting 1 } radiusMIB OBJECT-IDENTITY STATUS current DESCRIPTION "The OID assigned to RADIUS MIB work by the IANA." ::= { mib-2 67 } radiusAccounting OBJECT IDENTIFIER ::= {radiusMIB 2} radiusAccServMIBObjects OBJECT IDENTIFIER ::= { radiusAccServMIB 1 } radiusAccServ OBJECT IDENTIFIER ::= { radiusAccServMIBObjects 1 } radiusAccServIdent OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The implementation identification string for the RADIUS accounting server software in use on the system, for example, 'FNS-2.1'." ::= {radiusAccServ 1} radiusAccServUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Nelson Informational [Page 6] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 STATUS current DESCRIPTION "If the server has a persistent state (e.g., a process), this value will be the time elapsed (in hundredths of a second) since the server process was started. For software without persistent state, this value will be zero." ::= {radiusAccServ 2} radiusAccServResetTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "If the server has a persistent state (e.g., a process) and supports a 'reset' operation (e.g., can be told to re-read configuration files), this value will be the time elapsed (in hundredths of a second) since the server was 'reset.' For software that does not have persistence or does not support a 'reset' operation, this value will be zero." ::= {radiusAccServ 3} radiusAccServConfigReset OBJECT-TYPE SYNTAX INTEGER { other(1), reset(2), initializing(3), running(4)} MAX-ACCESS read-write STATUS current DESCRIPTION "Status/action object to reinitialize any persistent server state. When set to reset(2), any persistent server state (such as a process) is reinitialized as if the server had just been started. This value will never be returned by a read operation. When read, one of the following values will be returned: other(1) - server in some unknown state; initializing(3) - server (re)initializing; running(4) - server currently running." ::= {radiusAccServ 4} radiusAccServTotalRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION Nelson Informational [Page 7] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 "The number of packets received on the accounting port." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccServ 5 } radiusAccServTotalInvalidRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets received from unknown addresses." REFERENCE "RFC 2866 sections 2, 4.1" ::= { radiusAccServ 6 } radiusAccServTotalDupRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS Accounting-Request packets received." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccServ 7 } radiusAccServTotalResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Response packets sent." REFERENCE "RFC 2866 section 4.2" ::= { radiusAccServ 8 } radiusAccServTotalMalformedRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Accounting-Request packets received. Bad authenticators or unknown types are not included as malformed Access-Requests." REFERENCE "RFC 2866 section 3" Nelson Informational [Page 8] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 ::= { radiusAccServ 9 } radiusAccServTotalBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets that contained an invalid authenticator." REFERENCE "RFC 2866 section 3" ::= { radiusAccServ 10 } radiusAccServTotalPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets silently discarded for a reason other than malformed, bad authenticators, or unknown types." REFERENCE "RFC 2866 section 3" ::= { radiusAccServ 11 } radiusAccServTotalNoRecords OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets that were received and responded to but not recorded." ::= { radiusAccServ 12 } radiusAccServTotalUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets of unknown type that were received." REFERENCE "RFC 2866 section 4" ::= { radiusAccServ 13 } radiusAccClientTable OBJECT-TYPE Nelson Informational [Page 9] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 SYNTAX SEQUENCE OF RadiusAccClientEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table listing the RADIUS accounting clients with which the server shares a secret." ::= { radiusAccServ 14 } radiusAccClientEntry OBJECT-TYPE SYNTAX RadiusAccClientEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) representing a RADIUS accounting client with which the server shares a secret." INDEX { radiusAccClientIndex } ::= { radiusAccClientTable 1 } RadiusAccClientEntry ::= SEQUENCE { radiusAccClientIndex Integer32, radiusAccClientAddress IpAddress, radiusAccClientID SnmpAdminString, radiusAccServPacketsDropped Counter32, radiusAccServRequests Counter32, radiusAccServDupRequests Counter32, radiusAccServResponses Counter32, radiusAccServBadAuthenticators Counter32, radiusAccServMalformedRequests Counter32, radiusAccServNoRecords Counter32, radiusAccServUnknownTypes Counter32 } radiusAccClientIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A number uniquely identifying each RADIUS accounting client with which this server communicates." ::= { radiusAccClientEntry 1 } radiusAccClientAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The NAS-IP-Address of the RADIUS accounting client Nelson Informational [Page 10] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 referred to in this table entry." ::= { radiusAccClientEntry 2 } radiusAccClientID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The NAS-Identifier of the RADIUS accounting client referred to in this table entry. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865 section 5.32" ::= { radiusAccClientEntry 3 } -- Server Counters -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped - Responses = Pending -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped - NoRecords = entries logged radiusAccServPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of incoming packets received from this client and silently discarded for a reason other than malformed, bad authenticators, or unknown types." REFERENCE "RFC 2866 section 3" ::= { radiusAccClientEntry 4 } radiusAccServRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of packets received from this client on the accounting port." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccClientEntry 5 } radiusAccServDupRequests OBJECT-TYPE SYNTAX Counter32 Nelson Informational [Page 11] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of duplicate RADIUS Accounting-Request packets received from this client." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccClientEntry 6 } radiusAccServResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Accounting-Response packets sent to this client." REFERENCE "RFC 2866 section 4.2" ::= { radiusAccClientEntry 7 } radiusAccServBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Accounting-Request packets that contained invalid authenticators received from this client." REFERENCE "RFC 2866 section 3" ::= { radiusAccClientEntry 8 } radiusAccServMalformedRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of malformed RADIUS Accounting-Request packets that were received from this client. Bad authenticators and unknown types are not included as malformed Accounting-Requests." REFERENCE "RFC 2866 section 3" ::= { radiusAccClientEntry 9 } radiusAccServNoRecords OBJECT-TYPE SYNTAX Counter32 UNITS "packets" Nelson Informational [Page 12] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS Accounting-Request packets that were received and responded to but not recorded." ::= { radiusAccClientEntry 10 } radiusAccServUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of RADIUS packets of unknown type that were received from this client." REFERENCE "RFC 2866 section 4" ::= { radiusAccClientEntry 11 } -- New MIB objects added in this revision radiusAccClientExtTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusAccClientExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS accounting clients with which the server shares a secret." ::= { radiusAccServ 15 } radiusAccClientExtEntry OBJECT-TYPE SYNTAX RadiusAccClientExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing a RADIUS accounting client with which the server shares a secret." INDEX { radiusAccClientExtIndex } ::= { radiusAccClientExtTable 1 } RadiusAccClientExtEntry ::= SEQUENCE { radiusAccClientExtIndex Integer32, radiusAccClientInetAddressType InetAddressType, radiusAccClientInetAddress InetAddress, radiusAccClientExtID SnmpAdminString, radiusAccServExtPacketsDropped Counter32, Nelson Informational [Page 13] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 radiusAccServExtRequests Counter32, radiusAccServExtDupRequests Counter32, radiusAccServExtResponses Counter32, radiusAccServExtBadAuthenticators Counter32, radiusAccServExtMalformedRequests Counter32, radiusAccServExtNoRecords Counter32, radiusAccServExtUnknownTypes Counter32, radiusAccServerCounterDiscontinuity TimeTicks } radiusAccClientExtIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS accounting client with which this server communicates." ::= { radiusAccClientExtEntry 1 } radiusAccClientInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address format used for the radiusAccClientInetAddress object." ::= { radiusAccClientExtEntry 2 } radiusAccClientInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the RADIUS accounting client referred to in this table entry, using the IPv6 address format." ::= { radiusAccClientExtEntry 3 } radiusAccClientExtID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS accounting client referred to in this table entry. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865 section 5.32" ::= { radiusAccClientExtEntry 4 } Nelson Informational [Page 14] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 -- Server Counters -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped - Responses = Pending -- -- Requests - DupRequests - BadAuthenticators - MalformedRequests - -- UnknownTypes - PacketsDropped - NoRecords = entries logged radiusAccServExtPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets received from this client and silently discarded for a reason other than malformed, bad authenticators, or unknown types. This counter may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." REFERENCE "RFC 2866 section 3" ::= { radiusAccClientExtEntry 5 } radiusAccServExtRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received from this client on the accounting port. This counter may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccClientExtEntry 6 } radiusAccServExtDupRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS Accounting-Request packets received from this client. This counter Nelson Informational [Page 15] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." REFERENCE "RFC 2866 section 4.1" ::= { radiusAccClientExtEntry 7 } radiusAccServExtResponses OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Response packets sent to this client. This counter may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." REFERENCE "RFC 2866 section 4.2" ::= { radiusAccClientExtEntry 8 } radiusAccServExtBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets that contained invalid authenticators received from this client. This counter may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." REFERENCE "RFC 2866 section 3" ::= { radiusAccClientExtEntry 9 } radiusAccServExtMalformedRequests OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Accounting-Request packets that were received from this client. Bad authenticators and unknown types are not Nelson Informational [Page 16] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 included as malformed Accounting-Requests. This counter may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." REFERENCE "RFC 2866 section 3" ::= { radiusAccClientExtEntry 10 } radiusAccServExtNoRecords OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Accounting-Request packets that were received and responded to but not recorded. This counter may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." ::= { radiusAccClientExtEntry 11 } radiusAccServExtUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS packets of unknown type that were received from this client. This counter may experience a discontinuity when the RADIUS Accounting Server module within the managed entity is reinitialized, as indicated by the current value of radiusAccServerCounterDiscontinuity." REFERENCE "RFC 2866 section 4" ::= { radiusAccClientExtEntry 12 } radiusAccServerCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "centiseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of centiseconds since the last discontinuity in the RADIUS Accounting Server counters. A discontinuity may be the result of a reinitialization of the RADIUS Accounting Server Nelson Informational [Page 17] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 module within the managed entity." ::= { radiusAccClientExtEntry 13 } -- conformance information radiusAccServMIBConformance OBJECT IDENTIFIER ::= { radiusAccServMIB 2 } radiusAccServMIBCompliances OBJECT IDENTIFIER ::= { radiusAccServMIBConformance 1 } radiusAccServMIBGroups OBJECT IDENTIFIER ::= { radiusAccServMIBConformance 2 } -- compliance statements radiusAccServMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for accounting servers implementing the RADIUS Accounting Server MIB. Implementation of this module is for IPv4-only entities, or for backwards compatibility use with entities that support both IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAccServMIBGroup } OBJECT radiusAccServConfigReset WRITE-SYNTAX INTEGER { reset(2) } DESCRIPTION "The only SETable value is 'reset' (2)." ::= { radiusAccServMIBCompliances 1 } radiusAccServExtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for accounting servers implementing the RADIUS Accounting Server IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAccServExtMIBGroup } OBJECT radiusAccServConfigReset WRITE-SYNTAX INTEGER { reset(2) } Nelson Informational [Page 18] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 DESCRIPTION "The only SETable value is 'reset' (2)." OBJECT radiusAccClientInetAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusAccClientInetAddress SYNTAX InetAddress ( SIZE (4|16) ) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." ::= { radiusAccServMIBCompliances 2 } -- units of conformance radiusAccServMIBGroup OBJECT-GROUP OBJECTS {radiusAccServIdent, radiusAccServUpTime, radiusAccServResetTime, radiusAccServConfigReset, radiusAccServTotalRequests, radiusAccServTotalInvalidRequests, radiusAccServTotalDupRequests, radiusAccServTotalResponses, radiusAccServTotalMalformedRequests, radiusAccServTotalBadAuthenticators, radiusAccServTotalPacketsDropped, radiusAccServTotalNoRecords, radiusAccServTotalUnknownTypes, radiusAccClientAddress, radiusAccClientID, radiusAccServPacketsDropped, radiusAccServRequests, radiusAccServDupRequests, radiusAccServResponses, radiusAccServBadAuthenticators, radiusAccServMalformedRequests, radiusAccServNoRecords, radiusAccServUnknownTypes } STATUS deprecated DESCRIPTION "The collection of objects providing management of a RADIUS Accounting Server." Nelson Informational [Page 19] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 ::= { radiusAccServMIBGroups 1 } radiusAccServExtMIBGroup OBJECT-GROUP OBJECTS {radiusAccServIdent, radiusAccServUpTime, radiusAccServResetTime, radiusAccServConfigReset, radiusAccServTotalRequests, radiusAccServTotalInvalidRequests, radiusAccServTotalDupRequests, radiusAccServTotalResponses, radiusAccServTotalMalformedRequests, radiusAccServTotalBadAuthenticators, radiusAccServTotalPacketsDropped, radiusAccServTotalNoRecords, radiusAccServTotalUnknownTypes, radiusAccClientInetAddressType, radiusAccClientInetAddress, radiusAccClientExtID, radiusAccServExtPacketsDropped, radiusAccServExtRequests, radiusAccServExtDupRequests, radiusAccServExtResponses, radiusAccServExtBadAuthenticators, radiusAccServExtMalformedRequests, radiusAccServExtNoRecords, radiusAccServExtUnknownTypes, radiusAccServerCounterDiscontinuity } STATUS current DESCRIPTION "The collection of objects providing management of a RADIUS Accounting Server." ::= { radiusAccServMIBGroups 2 } END 8. Security Considerations There are management objects (radiusAccServConfigReset) defined in this MIB that have a MAX-ACCESS clause of read-write and/or read- create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non- secure environment without proper protection can have a negative effect on network operations. These are: Nelson Informational [Page 20] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 radiusAccServConfigReset This object can be used to reinitialize the persistent state of any server. When set to reset(2), any persistent server state (such as a process) is reinitialized as if the server had just been started. Depending on the server implementation details, this action may or may not interrupt the processing of pending request in the server. Abuse of this object may lead to a Denial of Service attack on the server. There are a number of managed objects in this MIB that may contain sensitive information. These are: radiusAccClientIPAddress This can be used to determine the address of the RADIUS accounting client with which the server is communicating. This information could be useful in mounting an attack on the accounting client. radiusAccClientInetAddress This can be used to determine the address of the RADIUS accounting client with which the server is communicating. This information could be useful in mounting an attack on the accounting client. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMP versions prior to SNMPv3 do not provide a secure environment. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Nelson Informational [Page 21] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 9.2. Informative References [RFC2621] Zorn, G. and B. Aboba, "RADIUS Accounting Server MIB", RFC 2621, June 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006. Nelson Informational [Page 22] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 Appendix A. Acknowledgements The authors of the original MIB are Bernard Aboba and Glen Zorn. Many thanks to all reviewers, especially to Dave Harrington, Dan Romascanu, C.M. Heard, Bruno Pape, Greg Weber, and Bert Wijnen. Author's Address David B. Nelson Enterasys Networks 50 Minuteman Road Andover, MA 01810 USA EMail: dnelson@enterasys.com Nelson Informational [Page 23] RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nelson Informational [Page 24] snmp-mibs-downloader-1.1/mibrfcs/rfc4672.txt0000644000000000000000000014320111402176072015566 0ustar Network Working Group S. De Cnodder Request for Comments: 4672 Alcatel Category: Informational N. Jonnala M. Chiba Cisco Systems, Inc. September 2006 RADIUS Dynamic Authorization Client MIB Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. Table of Contents 1. Introduction ....................................................2 1.1. Requirements Notation ......................................2 1.2. Terminology ................................................2 2. The Internet-Standard Management Framework ......................3 3. Overview ........................................................3 4. RADIUS Dynamic Authorization Client MIB Definitions .............3 5. Security Considerations ........................................19 6. IANA Considerations ............................................20 7. Acknowledgements ...............................................20 8. References .....................................................21 8.1. Normative References ......................................21 8.2. Informative References ....................................21 De Cnodder, et al. Informational [Page 1] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. It is becoming increasingly important to support Dynamic Authorization extensions on the network access server (NAS) devices to handle the Disconnect and Change-of-Authorization (CoA) messages, as described in [RFC3576]. As a result, the effective management of RADIUS Dynamic Authorization entities is of considerable importance. This RADIUS Dynamic Authorization Client MIB complements the managed objects used for managing RADIUS authentication and accounting servers, as described in [RFC4669] and [RFC4671], respectively. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Dynamic Authorization Server (DAS) The component that resides on the NAS that processes the Disconnect and Change-of-Authorization (CoA) Request packets [RFC3576] sent by the Dynamic Authorization Client. Dynamic Authorization Client (DAC) The component that sends Disconnect and CoA-Request packets to the Dynamic Authorization Server. Although this component often resides on the RADIUS server, it is also possible for this component to be located on a separate host, such as a Rating Engine. Dynamic Authorization Server Port The UDP port on which the Dynamic Authorization Server listens for the Disconnect and CoA requests sent by the Dynamic Authorization Client. De Cnodder, et al. Informational [Page 2] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. 3. Overview "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-Request, CoA-ACK, and CoA-NAK packets. [RFC4673] defines the Dynamic Authorization Server MIB and the relationship with other MIB modules. This MIB module for the Dynamic Authorization Client contains the following: 1. Two scalar objects 2. One Dynamic Authorization Server table. This table contains one row for each DAS with which the DAC shares a secret. 4. RADIUS Dynamic Authorization Client MIB Definitions RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, mib-2, TimeTicks FROM SNMPv2-SMI -- [RFC2578] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- [RFC4001] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- [RFC2580] radiusDynAuthClientMIB MODULE-IDENTITY LAST-UPDATED "200608290000Z" -- 29 August 2006 ORGANIZATION "IETF RADEXT Working Group" CONTACT-INFO " Stefaan De Cnodder De Cnodder, et al. Informational [Page 3] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road, Bangalore-560027, India. Phone: +91 94487 60828 EMail: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 EMail: mchiba@cisco.com " DESCRIPTION "The MIB module for entities implementing the client side of the Dynamic Authorization Extensions to the Remote Authentication Dial-In User Service (RADIUS) protocol. Copyright (C) The Internet Society (2006). Initial version as published in RFC 4672; for full legal notices see the RFC itself." REVISION "200609290000Z" -- 29 August 2006 DESCRIPTION "Initial version as published in RFC 4672" ::= { mib-2 145 } radiusDynAuthClientMIBObjects OBJECT IDENTIFIER ::= { radiusDynAuthClientMIB 1 } radiusDynAuthClientScalars OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBObjects 1 } radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Disconnect-Ack and Disconnect-NAK packets De Cnodder, et al. Informational [Page 4] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 received from unknown addresses. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." ::= { radiusDynAuthClientScalars 1 } radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CoA-Ack and CoA-NAK packets received from unknown addresses. Disconnect-NAK packets received from unknown addresses. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." ::= { radiusDynAuthClientScalars 2 } radiusDynAuthServerTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusDynAuthServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS Dynamic Authorization Servers with which the client shares a secret." ::= { radiusDynAuthClientMIBObjects 2 } radiusDynAuthServerEntry OBJECT-TYPE SYNTAX RadiusDynAuthServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing one Dynamic Authorization Server with which the client shares a secret." INDEX { radiusDynAuthServerIndex } ::= { radiusDynAuthServerTable 1 } RadiusDynAuthServerEntry ::= SEQUENCE { radiusDynAuthServerIndex Integer32, radiusDynAuthServerAddressType InetAddressType, radiusDynAuthServerAddress InetAddress, radiusDynAuthServerClientPortNumber InetPortNumber, radiusDynAuthServerID SnmpAdminString, radiusDynAuthClientRoundTripTime TimeTicks, radiusDynAuthClientDisconRequests Counter32, De Cnodder, et al. Informational [Page 5] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 radiusDynAuthClientDisconAuthOnlyRequests Counter32, radiusDynAuthClientDisconRetransmissions Counter32, radiusDynAuthClientDisconAcks Counter32, radiusDynAuthClientDisconNaks Counter32, radiusDynAuthClientDisconNakAuthOnlyRequest Counter32, radiusDynAuthClientDisconNakSessNoContext Counter32, radiusDynAuthClientMalformedDisconResponses Counter32, radiusDynAuthClientDisconBadAuthenticators Counter32, radiusDynAuthClientDisconPendingRequests Gauge32, radiusDynAuthClientDisconTimeouts Counter32, radiusDynAuthClientDisconPacketsDropped Counter32, radiusDynAuthClientCoARequests Counter32, radiusDynAuthClientCoAAuthOnlyRequest Counter32, radiusDynAuthClientCoARetransmissions Counter32, radiusDynAuthClientCoAAcks Counter32, radiusDynAuthClientCoANaks Counter32, radiusDynAuthClientCoANakAuthOnlyRequest Counter32, radiusDynAuthClientCoANakSessNoContext Counter32, radiusDynAuthClientMalformedCoAResponses Counter32, radiusDynAuthClientCoABadAuthenticators Counter32, radiusDynAuthClientCoAPendingRequests Gauge32, radiusDynAuthClientCoATimeouts Counter32, radiusDynAuthClientCoAPacketsDropped Counter32, radiusDynAuthClientUnknownTypes Counter32, radiusDynAuthClientCounterDiscontinuity TimeTicks } radiusDynAuthServerIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS Dynamic Authorization Server with which this Dynamic Authorization Client communicates. This number is allocated by the agent implementing this MIB module and is unique in this context." ::= { radiusDynAuthServerEntry 1 } radiusDynAuthServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of IP address of the RADIUS Dynamic Authorization Server referred to in this table entry." ::= { radiusDynAuthServerEntry 2 } De Cnodder, et al. Informational [Page 6] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 radiusDynAuthServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address value of the RADIUS Dynamic Authorization Server referred to in this table entry using the version neutral IP address format. The type of this address is determined by the value of the radiusDynAuthServerAddressType object." ::= { radiusDynAuthServerEntry 3 } radiusDynAuthServerClientPortNumber OBJECT-TYPE SYNTAX InetPortNumber (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The UDP destination port that the RADIUS Dynamic Authorization Client is using to send requests to this server. The value zero is invalid." ::= { radiusDynAuthServerEntry 4 } radiusDynAuthServerID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS Dynamic Authorization Server referred to in this table entry. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865, Section 5.32, NAS-Identifier." ::= { radiusDynAuthServerEntry 5 } radiusDynAuthClientRoundTripTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time interval (in hundredths of a second) between the most recent Disconnect or CoA request and the receipt of the corresponding Disconnect or CoA reply. A value of zero is returned if no reply has been received yet from this server." ::= { radiusDynAuthServerEntry 6 } De Cnodder, et al. Informational [Page 7] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 radiusDynAuthClientDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests sent to this Dynamic Authorization Server. This also includes the RADIUS Disconnect-Requests that have a Service-Type attribute with value 'Authorize Only'. Disconnect-NAK packets received from unknown addresses. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 7 } radiusDynAuthClientDisconAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Server. Disconnect-NAK packets received from unknown addresses. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 8 } radiusDynAuthClientDisconRetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "retransmissions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-request packets retransmitted to this RADIUS Dynamic Authorization Server. Disconnect-NAK packets received from unknown addresses. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE De Cnodder, et al. Informational [Page 8] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 9 } radiusDynAuthClientDisconAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-ACK packets received from this Dynamic Authorization Server. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 10 } radiusDynAuthClientDisconNaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets received from this Dynamic Authorization Server. This includes the RADIUS Disconnect-NAK packets received with a Service-Type attribute with value 'Authorize Only' and the RADIUS Disconnect-NAK packets received if no session context was found. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 11 } radiusDynAuthClientDisconNakAuthOnlyRequest OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Server. This counter may experience a discontinuity when the DAC module (re)starts, as De Cnodder, et al. Informational [Page 9] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 12 } radiusDynAuthClientDisconNakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets received from this Dynamic Authorization Server because no session context was found; i.e., it includes an Error-Cause attribute with value 503 ('Session Context Not Found'). This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 13 } radiusDynAuthClientMalformedDisconResponses OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Disconnect-Ack and Disconnect-NAK packets received from this Dynamic Authorization Server. Bad authenticators and unknown types are not included as malformed Disconnect-Ack and Disconnect-NAK packets. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 14 } radiusDynAuthClientDisconBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current De Cnodder, et al. Informational [Page 10] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 DESCRIPTION "The number of RADIUS Disconnect-Ack and Disconnect-NAK packets that contained invalid Authenticator field received from this Dynamic Authorization Server. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 15 } radiusDynAuthClientDisconPendingRequests OBJECT-TYPE SYNTAX Gauge32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an Disconnect-Request is sent and decremented due to receipt of a Disconnect-Ack, a Disconnect-NAK, a timeout, or a retransmission." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 16 } radiusDynAuthClientDisconTimeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Disconnect request timeouts to this server. After a timeout, the client may retry to the same server or give up. A retry to the same server is counted as a retransmit and as a timeout. A send to a different server is counted as a Disconnect-Request and as a timeout. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 17 } radiusDynAuthClientDisconPacketsDropped OBJECT-TYPE De Cnodder, et al. Informational [Page 11] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming Disconnect-Ack and Disconnect-NAK packets from this Dynamic Authorization Server silently discarded by the client application for some reason other than malformed, bad authenticators, or unknown types. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 18 } radiusDynAuthClientCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-Requests sent to this Dynamic Authorization Server. This also includes CoA requests that have a Service-Type attribute with value 'Authorize Only'. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 19 } radiusDynAuthClientCoAAuthOnlyRequest OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." De Cnodder, et al. Informational [Page 12] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 20 } radiusDynAuthClientCoARetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "retransmissions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-request packets retransmitted to this RADIUS Dynamic Authorization Server. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 21 } radiusDynAuthClientCoAAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-ACK packets received from this Dynamic Authorization Server. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 22 } radiusDynAuthClientCoANaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets received from this Dynamic Authorization Server. This includes the RADIUS CoA-NAK packets received with a Service-Type attribute with value 'Authorize Only' and the RADIUS CoA-NAK packets received because no session context De Cnodder, et al. Informational [Page 13] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 was found. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 23 } radiusDynAuthClientCoANakAuthOnlyRequest OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Server. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 24 } radiusDynAuthClientCoANakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets received from this Dynamic Authorization Server because no session context was found; i.e., it includes an Error-Cause attribute with value 503 ('Session Context Not Found'). This counter may experience a discontinuity when the DAC module (re)starts as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 25 } radiusDynAuthClientMalformedCoAResponses OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current De Cnodder, et al. Informational [Page 14] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 DESCRIPTION "The number of malformed RADIUS CoA-Ack and CoA-NAK packets received from this Dynamic Authorization Server. Bad authenticators and unknown types are not included as malformed CoA-Ack and CoA-NAK packets. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 26 } radiusDynAuthClientCoABadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-Ack and CoA-NAK packets that contained invalid Authenticator field received from this Dynamic Authorization Server. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 27 } radiusDynAuthClientCoAPendingRequests OBJECT-TYPE SYNTAX Gauge32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an CoA-Request is sent and decremented due to receipt of a CoA-Ack, a CoA-NAK, or a timeout, or a retransmission." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 28 } radiusDynAuthClientCoATimeouts OBJECT-TYPE De Cnodder, et al. Informational [Page 15] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CoA request timeouts to this server. After a timeout, the client may retry to the same server or give up. A retry to the same server is counted as a retransmit and as a timeout. A send to a different server is counted as a CoA-Request and as a timeout. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 29 } radiusDynAuthClientCoAPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming CoA-Ack and CoA-NAK from this Dynamic Authorization Server silently discarded by the client application for some reason other than malformed, bad authenticators, or unknown types. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 30 } radiusDynAuthClientUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets of unknown types that were received on the Dynamic Authorization port. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." De Cnodder, et al. Informational [Page 16] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 REFERENCE "RFC 3576, Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 31 } radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the last counter discontinuity. A discontinuity may be the result of a reinitialization of the DAC module within the managed entity." ::= { radiusDynAuthServerEntry 32 } -- conformance information radiusDynAuthClientMIBConformance OBJECT IDENTIFIER ::= { radiusDynAuthClientMIB 2 } radiusDynAuthClientMIBCompliances OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBConformance 1 } radiusDynAuthClientMIBGroups OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBConformance 2 } -- compliance statements radiusDynAuthClientMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities implementing the RADIUS Dynamic Authorization Client. Implementation of this module is for entities that support IPv4 and/or IPv6." MODULE -- this module MANDATORY-GROUPS { radiusDynAuthClientMIBGroup } OBJECT radiusDynAuthServerAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusDynAuthServerAddress SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." De Cnodder, et al. Informational [Page 17] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 GROUP radiusDynAuthClientAuthOnlyGroup DESCRIPTION "Only required for Dynamic Authorization Clients that are supporting Service-Type attributes with value 'Authorize-Only'." GROUP radiusDynAuthClientNoSessGroup DESCRIPTION "This group is not required if the Dynamic Authorization Server cannot easily determine whether a session exists (e.g., in case of a RADIUS proxy)." ::= { radiusDynAuthClientMIBCompliances 1 } -- units of conformance radiusDynAuthClientMIBGroup OBJECT-GROUP OBJECTS { radiusDynAuthClientDisconInvalidServerAddresses, radiusDynAuthClientCoAInvalidServerAddresses, radiusDynAuthServerAddressType, radiusDynAuthServerAddress, radiusDynAuthServerClientPortNumber, radiusDynAuthServerID, radiusDynAuthClientRoundTripTime, radiusDynAuthClientDisconRequests, radiusDynAuthClientDisconRetransmissions, radiusDynAuthClientDisconAcks, radiusDynAuthClientDisconNaks, radiusDynAuthClientMalformedDisconResponses, radiusDynAuthClientDisconBadAuthenticators, radiusDynAuthClientDisconPendingRequests, radiusDynAuthClientDisconTimeouts, radiusDynAuthClientDisconPacketsDropped, radiusDynAuthClientCoARequests, radiusDynAuthClientCoARetransmissions, radiusDynAuthClientCoAAcks, radiusDynAuthClientCoANaks, radiusDynAuthClientMalformedCoAResponses, radiusDynAuthClientCoABadAuthenticators, radiusDynAuthClientCoAPendingRequests, radiusDynAuthClientCoATimeouts, radiusDynAuthClientCoAPacketsDropped, radiusDynAuthClientUnknownTypes, radiusDynAuthClientCounterDiscontinuity } STATUS current De Cnodder, et al. Informational [Page 18] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 DESCRIPTION "The collection of objects providing management of a RADIUS Dynamic Authorization Client." ::= { radiusDynAuthClientMIBGroups 1 } radiusDynAuthClientAuthOnlyGroup OBJECT-GROUP OBJECTS { radiusDynAuthClientDisconAuthOnlyRequests, radiusDynAuthClientDisconNakAuthOnlyRequest, radiusDynAuthClientCoAAuthOnlyRequest, radiusDynAuthClientCoANakAuthOnlyRequest } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages including Service-Type attribute with value 'Authorize Only'." ::= { radiusDynAuthClientMIBGroups 2 } radiusDynAuthClientNoSessGroup OBJECT-GROUP OBJECTS { radiusDynAuthClientDisconNakSessNoContext, radiusDynAuthClientCoANakSessNoContext } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages that are referring to non-existing sessions." ::= { radiusDynAuthClientMIBGroups 3 } END 5. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: De Cnodder, et al. Informational [Page 19] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 radiusDynAuthServerAddress and radiusDynAuthServerAddressType These can be used to determine the address of the DAS with which the DAC is communicating. This information could be useful in mounting an attack on the DAS. radiusDynAuthServerID This can be used to determine the Identifier of the DAS. This information could be useful in impersonating the DAS. radiusDynAuthServerClientPortNumber This can be used to determine the destination port number to which the DAC is sending. This information could be useful in mounting an attack on the DAS. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations The IANA has assigned OID number 145 under mib-2. 7. Acknowledgements The authors would also like to acknowledge the following people for their comments on this document: Bernard Aboba, Alan DeKok, David Nelson, Anjaneyulu Pata, Dan Romascanu, Juergen Schoenwaelder, Greg Weber, Bert Wijnen, and Glen Zorn. De Cnodder, et al. Informational [Page 20] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 8.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006. [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006. De Cnodder, et al. Informational [Page 21] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 [RFC4673] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Server MIB", RFC 4673, September 2006. Authors' Addresses Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road Bangalore-560027, India Phone: +91 94487 60828 EMail: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 EMail: mchiba@cisco.com De Cnodder, et al. Informational [Page 22] RFC 4672 RADIUS Dynamic Authorization Client MIB September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). De Cnodder, et al. Informational [Page 23] snmp-mibs-downloader-1.1/mibrfcs/rfc4673.txt0000644000000000000000000013502311402176072015572 0ustar Network Working Group S. De Cnodder Request for Comments: 4673 Alcatel Category: Informational N. Jonnala M. Chiba Cisco Systems, Inc. September 2006 RADIUS Dynamic Authorization Server MIB Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. Table of Contents 1. Introduction ....................................................2 1.1. Requirements Notation ......................................2 1.2. Terminology ................................................2 2. The Internet-Standard Management Framework ......................2 3. Overview ........................................................3 4. RADIUS Dynamic Authorization Server MIB Definitions .............5 5. Security Considerations ........................................20 6. IANA Considerations ............................................21 7. Acknowledgements ...............................................21 8. References .....................................................21 8.1. Normative References ......................................21 8.2. Informative References ....................................22 De Cnodder, et al. Informational [Page 1] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It is becoming increasingly important to support Dynamic Authorization extensions on the network access server (NAS) devices to handle the Disconnect and Change-of-Authorization (CoA) messages as described in [RFC3576]. As a result, the effective management of RADIUS Dynamic Authorization entities is of considerable importance. This RADIUS Dynamic Authorization Server (DAS) MIB complements the managed objects used for managing RADIUS authentication and accounting clients as described in [RFC4668] and [RFC4670], respectively. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Dynamic Authorization Server (DAS) The component that resides on the NAS that processes the Disconnect and Change-of-Authorization (CoA) Request packets [RFC3576] sent by the Dynamic Authorization Client. Dynamic Authorization Client (DAC) The component that sends Disconnect and CoA-Request packets to the Dynamic Authorization Server. Although this component often resides on the RADIUS server, it is also possible for it to be located on a separate host, such as a Rating Engine. Dynamic Authorization Server Port The UDP port on which the Dynamic Authorization Server listens for the Disconnect and CoA requests sent by the Dynamic Authorization Client. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. De Cnodder, et al. Informational [Page 2] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 Managed objects are accessed via a virtual information store, termed the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. 3. Overview "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-Request, CoA-ACK, and CoA-NAK packets. Typically, NAS devices implement the DAS function, and thus would be expected to implement the RADIUS Dynamic Authorization Server MIB, whereas DACs implement the client function and thus would be expected to implement the RADIUS Dynamic Authorization Client MIB. However, it is possible for a RADIUS Dynamic Authorization entity to perform both client and server functions. For example, a RADIUS proxy may act as a DAS to one or more DACs while simultaneously acting as a DAC to one or more DASs. In such situations, it is expected that RADIUS entities combining client and server functionality will support both the client and server MIBs. This memo describes the MIB for Dynamic Authorization Servers and relates to the following documents as follows: [RFC4668] describes the MIB for a RADIUS Auth Client MIB. [RFC4669] describes the MIB for a RADIUS Auth Server MIB. [RFC4670] describes the MIB for a RADIUS Acct Client MIB. [RFC4671] describes the MIB for a RADIUS Acct Server MIB. [RFC4672] describes the MIB for a RADIUS Dynamic Auth Client. A NAS typically implements the MIBs for a RADIUS Authentication Client, a RADIUS accounting client, and a RADIUS Dynamic Authorization Server. However, any one MIB can be implemented without implementing any of the other MIBs; i.e., the MIBs have no dependencies on each other. A typical case would be for a device to implement the MIBs RADIUS authentication server, RADIUS accounting server, and RADIUS Dynamic Authorization Client. A RADIUS proxy might implement any, all, or a subset of the MIBs listed above and the MIB as defined in this document. De Cnodder, et al. Informational [Page 3] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 +---------------+ +---------------+ User 1----| | Disconnect-Request | | | Dynamic | CoA-Request | Dynamic | User 2----| Authorization |<---------------------| Authorization | | Server |--------------------->| Client | User 3----| (DAS) | Disconnect-Ack | (DAC) | | | Disconnect-NAK | | +---------------+ CoA-Ack/CoA-NAK +---------------+ Figure 1. Mapping of clients and servers This MIB module for the Dynamic Authorization Server contains the following: 1. Three scalar objects. 2. One Dynamic Authorization Client Table. This table contains one row for each DAC with which the DAS shares a secret. De Cnodder, et al. Informational [Page 4] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 4. RADIUS Dynamic Authorization Server MIB Definitions RADIUS-DYNAUTH-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, mib-2, TimeTicks FROM SNMPv2-SMI -- [RFC2578] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- [RFC2580] radiusDynAuthServerMIB MODULE-IDENTITY LAST-UPDATED "200608290000Z" -- 29 August 2006 ORGANIZATION "IETF RADEXT Working Group" CONTACT-INFO " Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road, Bangalore-560027, India. Phone: +91 94487 60828 EMail: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 EMail: mchiba@cisco.com " DESCRIPTION "The MIB module for entities implementing the server side of the Dynamic Authorization Extensions to the Remote Authentication Dial-In User Service (RADIUS) protocol. Copyright (C) The Internet Society (2006). De Cnodder, et al. Informational [Page 5] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 Initial version as published in RFC 4673; for full legal notices see the RFC itself." REVISION "200608290000Z" -- 29 August 2006 DESCRIPTION "Initial version as published in RFC 4673." ::= { mib-2 146 } radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 1 } radiusDynAuthServerScalars OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBObjects 1 } radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Disconnect-Request packets received from unknown addresses. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." ::= { radiusDynAuthServerScalars 1 } radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CoA-Request packets received from unknown addresses. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." ::= { radiusDynAuthServerScalars 2 } radiusDynAuthServerIdentifier OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS Dynamic Authorization Server. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865, Section 5.32, NAS-Identifier." ::= { radiusDynAuthServerScalars 3 } De Cnodder, et al. Informational [Page 6] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 radiusDynAuthClientTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusDynAuthClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS Dynamic Authorization Clients with which the server shares a secret." ::= { radiusDynAuthServerMIBObjects 2 } radiusDynAuthClientEntry OBJECT-TYPE SYNTAX RadiusDynAuthClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing one Dynamic Authorization Client with which the server shares a secret." INDEX { radiusDynAuthClientIndex } ::= { radiusDynAuthClientTable 1 } RadiusDynAuthClientEntry ::= SEQUENCE { radiusDynAuthClientIndex Integer32, radiusDynAuthClientAddressType InetAddressType, radiusDynAuthClientAddress InetAddress, radiusDynAuthServDisconRequests Counter32, radiusDynAuthServDisconAuthOnlyRequests Counter32, radiusDynAuthServDupDisconRequests Counter32, radiusDynAuthServDisconAcks Counter32, radiusDynAuthServDisconNaks Counter32, radiusDynAuthServDisconNakAuthOnlyRequests Counter32, radiusDynAuthServDisconNakSessNoContext Counter32, radiusDynAuthServDisconUserSessRemoved Counter32, radiusDynAuthServMalformedDisconRequests Counter32, radiusDynAuthServDisconBadAuthenticators Counter32, radiusDynAuthServDisconPacketsDropped Counter32, radiusDynAuthServCoARequests Counter32, radiusDynAuthServCoAAuthOnlyRequests Counter32, radiusDynAuthServDupCoARequests Counter32, radiusDynAuthServCoAAcks Counter32, radiusDynAuthServCoANaks Counter32, radiusDynAuthServCoANakAuthOnlyRequests Counter32, radiusDynAuthServCoANakSessNoContext Counter32, radiusDynAuthServCoAUserSessChanged Counter32, radiusDynAuthServMalformedCoARequests Counter32, radiusDynAuthServCoABadAuthenticators Counter32, radiusDynAuthServCoAPacketsDropped Counter32, radiusDynAuthServUnknownTypes Counter32, De Cnodder, et al. Informational [Page 7] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 radiusDynAuthServerCounterDiscontinuity TimeTicks } radiusDynAuthClientIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS Dynamic Authorization Client with which this Dynamic Authorization Server communicates. This number is allocated by the agent implementing this MIB module and is unique in this context." ::= { radiusDynAuthClientEntry 1 } radiusDynAuthClientAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of IP address of the RADIUS Dynamic Authorization Client referred to in this table entry." ::= { radiusDynAuthClientEntry 2 } radiusDynAuthClientAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address value of the RADIUS Dynamic Authorization Client referred to in this table entry, using the version neutral IP address format. The type of this address is determined by the value of the radiusDynAuthClientAddressType object." ::= { radiusDynAuthClientEntry 3 } radiusDynAuthServDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests received from this Dynamic Authorization Client. This also includes the RADIUS Disconnect-Requests that have a Service-Type attribute with value 'Authorize Only'. This counter may experience a discontinuity when the De Cnodder, et al. Informational [Page 8] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 DAS module (re)starts as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 4 } radiusDynAuthServDisconAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 5 } radiusDynAuthServDupDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS Disconnect-Request packets received from this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 6 } radiusDynAuthServDisconAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-ACK packets sent to this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." De Cnodder, et al. Informational [Page 9] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 7 } radiusDynAuthServDisconNaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets sent to this Dynamic Authorization Client. This includes the RADIUS Disconnect-NAK packets sent with a Service-Type attribute with value 'Authorize Only' and the RADIUS Disconnect-NAK packets sent because no session context was found. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 8 } radiusDynAuthServDisconNakAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 9 } radiusDynAuthServDisconNakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets sent to this Dynamic Authorization Client because no session context was found. This counter may De Cnodder, et al. Informational [Page 10] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 10 } radiusDynAuthServDisconUserSessRemoved OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user sessions removed for the Disconnect-Requests received from this Dynamic Authorization Client. Depending on site- specific policies, a single Disconnect request can remove multiple user sessions. In cases where this Dynamic Authorization Server has no knowledge of the number of user sessions that are affected by a single request, each such Disconnect-Request will count as a single affected user session only. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 11 } radiusDynAuthServMalformedDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Disconnect-Request packets received from this Dynamic Authorization Client. Bad authenticators and unknown types are not included as malformed Disconnect-Requests. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 12 } De Cnodder, et al. Informational [Page 11] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 radiusDynAuthServDisconBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Request packets that contained an invalid Authenticator field received from this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 13 } radiusDynAuthServDisconPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming Disconnect-Requests from this Dynamic Authorization Client silently discarded by the server application for some reason other than malformed, bad authenticators, or unknown types. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 14 } radiusDynAuthServCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests received from this Dynamic Authorization Client. This also includes the CoA requests that have a Service-Type attribute with value 'Authorize Only'. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." De Cnodder, et al. Informational [Page 12] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 15 } radiusDynAuthServCoAAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 16 } radiusDynAuthServDupCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS CoA-Request packets received from this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 17 } radiusDynAuthServCoAAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-ACK packets sent to this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module De Cnodder, et al. Informational [Page 13] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 18 } radiusDynAuthServCoANaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets sent to this Dynamic Authorization Client. This includes the RADIUS CoA-NAK packets sent with a Service-Type attribute with value 'Authorize Only' and the RADIUS CoA-NAK packets sent because no session context was found. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 19 } radiusDynAuthServCoANakAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 20 } radiusDynAuthServCoANakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current De Cnodder, et al. Informational [Page 14] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 DESCRIPTION "The number of RADIUS CoA-NAK packets sent to this Dynamic Authorization Client because no session context was found. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 21 } radiusDynAuthServCoAUserSessChanged OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user sessions authorization changed for the CoA-Requests received from this Dynamic Authorization Client. Depending on site- specific policies, a single CoA request can change multiple user sessions' authorization. In cases where this Dynamic Authorization Server has no knowledge of the number of user sessions that are affected by a single request, each such CoA-Request will count as a single affected user session only. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 22 } radiusDynAuthServMalformedCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS CoA-Request packets received from this Dynamic Authorization Client. Bad authenticators and unknown types are not included as malformed CoA-Requests. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE De Cnodder, et al. Informational [Page 15] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 23 } radiusDynAuthServCoABadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-Request packets that contained an invalid Authenticator field received from this Dynamic Authorization Client. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 24 } radiusDynAuthServCoAPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming CoA packets from this Dynamic Authorization Client silently discarded by the server application for some reason other than malformed, bad authenticators, or unknown types. This counter may experience a discontinuity when the DAS module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 25 } radiusDynAuthServUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets of unknown types that were received on the Dynamic Authorization port. This counter may experience a discontinuity when the DAS De Cnodder, et al. Informational [Page 16] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 module (re)starts, as indicated by the value of radiusDynAuthServerCounterDiscontinuity." REFERENCE "RFC 3576, Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 26 } radiusDynAuthServerCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the last counter discontinuity. A discontinuity may be the result of a reinitialization of the DAS module within the managed entity." ::= { radiusDynAuthClientEntry 27 } -- conformance information radiusDynAuthServerMIBConformance OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 2 } radiusDynAuthServerMIBCompliances OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 1 } radiusDynAuthServerMIBGroups OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 2 } -- compliance statements radiusAuthServerMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities implementing the RADIUS Dynamic Authorization Server. Implementation of this module is for entities that support IPv4 and/or IPv6." MODULE -- this module MANDATORY-GROUPS { radiusDynAuthServerMIBGroup } OBJECT radiusDynAuthClientAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusDynAuthClientAddress SYNTAX InetAddress (SIZE(4|16)) De Cnodder, et al. Informational [Page 17] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." GROUP radiusDynAuthServerAuthOnlyGroup DESCRIPTION "Only required for Dynamic Authorization Clients that are supporting Service-Type attributes with value 'Authorize-Only'." GROUP radiusDynAuthServerNoSessGroup DESCRIPTION "This group is not required if the Dynamic Authorization Server cannot easily determine whether a session exists (e.g., in case of a RADIUS proxy)." ::= { radiusDynAuthServerMIBCompliances 1 } -- units of conformance radiusDynAuthServerMIBGroup OBJECT-GROUP OBJECTS { radiusDynAuthServerDisconInvalidClientAddresses, radiusDynAuthServerCoAInvalidClientAddresses, radiusDynAuthServerIdentifier, radiusDynAuthClientAddressType, radiusDynAuthClientAddress, radiusDynAuthServDisconRequests, radiusDynAuthServDupDisconRequests, radiusDynAuthServDisconAcks, radiusDynAuthServDisconNaks, radiusDynAuthServDisconUserSessRemoved, radiusDynAuthServMalformedDisconRequests, radiusDynAuthServDisconBadAuthenticators, radiusDynAuthServDisconPacketsDropped, radiusDynAuthServCoARequests, radiusDynAuthServDupCoARequests, radiusDynAuthServCoAAcks, radiusDynAuthServCoANaks, radiusDynAuthServCoAUserSessChanged, radiusDynAuthServMalformedCoARequests, radiusDynAuthServCoABadAuthenticators, radiusDynAuthServCoAPacketsDropped, radiusDynAuthServUnknownTypes, radiusDynAuthServerCounterDiscontinuity } STATUS current De Cnodder, et al. Informational [Page 18] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 DESCRIPTION "The collection of objects providing management of a RADIUS Dynamic Authorization Server." ::= { radiusDynAuthServerMIBGroups 1 } radiusDynAuthServerAuthOnlyGroup OBJECT-GROUP OBJECTS { radiusDynAuthServDisconAuthOnlyRequests, radiusDynAuthServDisconNakAuthOnlyRequests, radiusDynAuthServCoAAuthOnlyRequests, radiusDynAuthServCoANakAuthOnlyRequests } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages including Service-Type attribute with value 'Authorize Only'." ::= { radiusDynAuthServerMIBGroups 2 } radiusDynAuthServerNoSessGroup OBJECT-GROUP OBJECTS { radiusDynAuthServDisconNakSessNoContext, radiusDynAuthServCoANakSessNoContext } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages that are referring to non-existing sessions." ::= { radiusDynAuthServerMIBGroups 3 } END De Cnodder, et al. Informational [Page 19] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 5. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: radiusDynAuthClientAddress and radiusDynAuthClientAddressType These can be used to determine the address of the DAC with which the DAS is communicating. This information could be useful in mounting an attack on the DAC. radiusDynAuthServerIdentifier This can be used to determine the Identifier of the DAS. This information could be useful in impersonating the DAS. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. De Cnodder, et al. Informational [Page 20] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 6. IANA Considerations The IANA has assigned OID number 146 under mib-2. 7. Acknowledgements The authors would like to acknowledge the following people for their comments on this document: Bernard Aboba, Alan DeKok, David Nelson, Anjaneyulu Pata, Dan Romascanu, Juergen Schoenwaelder, Greg Weber, Bert Wijnen, and Glen Zorn. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. De Cnodder, et al. Informational [Page 21] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 8.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006. [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006. [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006. [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006. [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Client MIB", RFC 4672, September 2006. De Cnodder, et al. Informational [Page 22] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 Authors' Addresses Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road Bangalore-560027, India Phone: +91 94487 60828 EMail: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 EMail: mchiba@cisco.com De Cnodder, et al. Informational [Page 23] RFC 4673 RADIUS Dynamic Authorization Server MIB September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). De Cnodder, et al. Informational [Page 24] snmp-mibs-downloader-1.1/mibrfcs/rfc4682.txt0000644000000000000000000041423711402176072015601 0ustar Network Working Group E. Nechamkin Request for Comments: 4682 Broadcom Corp. Category: Standards Track J-F. Mule CableLabs December 2006 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices 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. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Terminology .....................................................2 3. Introduction ....................................................4 3.1. Structure of the MTA MIB ...................................5 3.2. pktcMtaDevBase .............................................5 3.3. pktcMtaDevServer ...........................................6 3.4. pktcMtaDevSecurity .........................................6 3.5. Relationship between MIB Objects in the MTA MIB ............7 3.6. Secure Software Download ...................................8 3.7. X.509 Certificates Dependencies ............................8 4. Definitions .....................................................9 5. Acknowledgements ...............................................52 6. Security Considerations ........................................52 7. IANA Considerations ............................................55 8. Normative References ...........................................55 9. Informative References .........................................57 Nechamkin & Mule Standards Track [Page 1] RFC 4682 IPCDN MTA MIB December 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when used in the guidelines in this memo, are to be interpreted as described in RFC 2119 [RFC2119]. The terms "MIB module" and "information module" are used interchangeably in this memo. As used here, both terms refer to any of the three types of information modules defined in Section 3 of RFC 2578 [RFC2578]. Some of the terms used in this memo are defined below. Some additional terms are also defined in the PacketCable MTA Device Provisioning Specification [PKT-SP-PROV] and the PacketCable Security Specification [PKT-SP-SEC]. DOCSIS The CableLabs(R) Certified(TM) Cable Modem project, also known as DOCSIS(R) (Data over Cable Service Interface Specification), defines interface requirements for cable modems involved in high-speed data distribution over cable television system networks. DOCSIS also refers to the ITU-T J.112 recommendation, Annex B, for cable modem systems [ITU-T-J112]. Cable Modem A Cable Modem (CM) acts as a data transport agent used to transfer call management and voice data packets over a DOCSIS-compliant cable system. Multimedia Terminal Adapter A Multimedia Terminal Adapter (MTA) is a PacketCable- or IPCablecom- compliant device providing telephony services over a cable or hybrid Nechamkin & Mule Standards Track [Page 2] RFC 4682 IPCDN MTA MIB December 2006 system used to deliver video signals to a community. It contains an interface to endpoints, a network interface, CODECs, and all signaling and encapsulation functions required for Voice over IP transport, call signaling, and Quality of Service signaling. An MTA can be an embedded or a standalone device. An Embedded MTA (E-MTA) is an MTA device containing an embedded DOCSIS Cable Modem. A Standalone MTA (S-MTA) is an MTA device separated from the DOCSIS cable modem by non-DOCSIS Message Access Control (MAC) interface (e.g., Ethernet, USB). Endpoint An endpoint or MTA endpoint is a standard RJ-11 telephony physical port located on the MTA and used for attaching the telephone device to the MTA. X.509 Certificate A X.509 certificate is an Internet X.509 Public Key Infrastructure certificate developed as part of the ITU-T X.500 Directory recommendations. It is defined in RFC 3280 [RFC3280] and RFC 4630 [RFC4630]. Voice over IP Voice over IP (VoIP) is a technology providing the means to transfer digitized packets with voice information over IP networks. Public Key Certificate A Public Key Certificate (also known as a Digital Certificate) is a binding between an entity's public key and one or more attributes relating to its identity. DHCP The Dynamic Host Configuration Protocol (DHCP) is defined by RFC 2131 [RFC2131]. In addition, commonly used DHCP options are defined in RFC 2132 [RFC2132]. Additional DHCP options used by PacketCable and IPCablecom MTAs can be found in the CableLabs Client Configuration DHCP specifications, RFC 3495 [RFC3495] and RFC 3594 [RFC3594]. TFTP The Trivial File Transfer Protocol (TFTP) is defined by RFC 1350 [RFC1350]. HTTP The Hypertext Transfer Protocol (HTTP/1.1) is defined by RFC 2616 [RFC2616]. Call Management Server A Call Management Server (CMS) is an element of the PacketCable network infrastructure that controls audio connections between MTAs. Nechamkin & Mule Standards Track [Page 3] RFC 4682 IPCDN MTA MIB December 2006 CODEC, COder-DECoder A Coder-DECoder is a hardware or software component used in audio/video systems to convert an analog signal to digital, and then (possibly) to compress it so that lower bandwidth telecommunications channels can be used. The signal is decompressed and converted (decoded) back to analog output by a compatible CODEC at the receiving end. Operations Systems Support An Operations Systems Support system (OSS) is a system of back office software components used for fault, configuration, accounting, performance, and security management working in interaction with each other and providing the operations support in deployed PacketCable systems. Key Distribution Center A Key Distribution Center (KDC) is an element of the OSS systems functioning as a Kerberos Security Server, providing mutual authentication of the various components of the PacketCable system (e.g., mutual authentication between an MTA and a CMS, or between an MTA and the Provisioning Server). Security Association A Security Association (SA) is a one-way relationship between a sender and a receiver offering security services on the communication flow. 3. Introduction This MIB module provides a set of objects required for the management of PacketCable, ETSI, and ITU-T IPCablecom compliant MTA devices. The MTA MIB module is intended to supersede various MTA MIB modules from which it is partly derived: - The PacketCable 1.0 MTA MIB Specification [PKT-SP-MIB-MTA]. - The ITU-T IPCablecom MTA MIB requirements [ITU-T-J168]. - The ETSI MTA MIB [ETSITS101909-8]. The ETSI MTA MIB requirements also refer to various signal characteristics defined in [EN300001], Chapter 3, titled 'Ringing Signal Characteristics', and [EN300659-1]. Several normative and informative references are used to help define MTA MIB objects. As a convention, wherever PacketCable and IPCablecom requirements are equivalent, the PacketCable reference is used in the object REFERENCE clause. IPCablecom-compliant MTA devices MUST use the equivalent IPCablecom references. Nechamkin & Mule Standards Track [Page 4] RFC 4682 IPCDN MTA MIB December 2006 3.1. Structure of the MTA MIB The MTA MIB module is identified by pktcIetfMtaMib and is structured in three object groups: - pktcMtaDevBase defines the management information pertinent to the MTA device itself. - pktcMtaDevServer defines the management information pertinent to the provisioning back office servers. - pktcMtaDevSecurity defines the management information pertinent to the PacketCable and IPCablecom security mechanisms. The first two object groups, pktcMtaDevBase and pktcMtaDevServer, contain only scalar information objects describing the corresponding characteristics of the MTA device and back office servers. The third group, pktcMtaDevSecurity, contains two tables controlling the logical associations between KDC realms and Application Servers (CMS and Provisioning Server). The rows in the various tables of the MTA MIB module can be created automatically (e.g., by the device according to the current state information), or they can be created by the management station, depending on the operational situation. The tables defined in the MTA MIB module may have a mixture of both types of rows. 3.2. pktcMtaDevBase This object group contains the management information related to the MTA device itself. It also contains some objects used to control the MTA state. Some highlights are as follows: - pktcMtaDevSerialNumber. This object contains the MTA Serial Number. - pktcMtaDevEndPntCount. This object contains the number of endpoints present in the managed MTA. - pktcMtaDevProvisioningState. This object contains the information describing the completion state of the MTA initialization process. - pktcMtaDevEnabled. This object controls the administrative state of the MTA endpoints and allows operators to enable or disable telephony services on the device. - pktcMtaDevResetNow. This object is used to instruct the MTA to reset. Nechamkin & Mule Standards Track [Page 5] RFC 4682 IPCDN MTA MIB December 2006 3.3. pktcMtaDevServer This object group contains the management information describing the back office servers and the parameters related to the communication timers. It also includes some objects controlling the initial MTA interaction with the Provisioning Server. Some highlights are as follows: - pktcMtaDevServerDhcp1. This object contains the IP address of the primary DHCP server designated for the MTA provisioning. - pktcMtaDevServerDhcp2. This object contains the IP address of the secondary DHCP server designated for the MTA provisioning. - pktcMtaDevServerDns1. This object contains the IP address of the primary DNS used by the managed MTA to resolve the Fully Qualified Domain Name (FQDN) and IP addresses. - pktcMtaDevServerDns2. This object contains the IP address of the secondary DNS used by the managed MTA to resolve the FQDN and IP addresses. - pktcMtaDevConfigFile. This object contains the name of the provisioning configuration file the managed MTA must download from the Provisioning Server. - pktcMtaDevProvConfigHash. This object contains the hash value of the MTA configuration file calculated over its content. When the managed MTA downloads the file, it authenticates the configuration file using the hash value provided in this object. 3.4. pktcMtaDevSecurity This object group contains the management information describing the security-related characteristics of the managed MTA. It contains two tables describing logical dependencies and parameters necessary to establish Security Associations between the MTA and other Application Servers (back office components and CMSes). The CMS table (pktcMtaDevCmsTable) and the realm table (pktcMtaDevRealmTable) are used for managing the MTA signaling security. The realm table defines the CMS domains. The CMS table defines the CMS within the domains. Each MTA endpoint is associated with one CMS at any given time. Nechamkin & Mule Standards Track [Page 6] RFC 4682 IPCDN MTA MIB December 2006 The two tables in this object group are as follows: - pktcMtaDevRealmTable. This table is used in conjunction with any Application Server that communicates securely with the managed MTA (CMS or Provisioning Server). - pktcMtaDevCmsTable. This table contains the parameters describing the SA establishment between the MTA and CMSes. 3.5. Relationship between MIB Objects in the MTA MIB This section clarifies the relationship between various MTA MIB objects with respect to the role they play in the process of establishing Security Associations. The process of Security Association establishment between an MTA and Application Servers is described in the PacketCable Security Specification [PKT-SP-SEC]. In particular, an MTA communicates with 2 types of back office Application Servers: Call Management Servers and Provisioning Servers. The SA establishment process consists of two steps: a. Authentication Server Exchange (AS-exchange). This step provides mutual authentication between the parties; i.e., between an MTA and an Authentication Server. The process of AS-exchange is defined by a number of parameters grouped per each realm. These parameters are gathered in the Realm Table (pktcMtaDevRealmTable). The Realm Table is indexed by the Index Counter and contains conceptual column with the Kerberos realm name. b. Application server exchange (AP-exchange). This step allows for the establishment of Security Associations between authenticated parties. The CMS table (pktcMtaDevCmsTable) contains the parameters for the AP-exchange process between an MTA and a CMS. The CMS table is indexed by the Index Counter and contains the CMS FQDN (the conceptual column pktcMtaDevCmsFqdn). Each row contains the Kerberos realm name associated with each CMS FQDN. This allows for each CMS to exist in a different Kerberos realm. The MTA MIB module also contains a group of scalar MIB objects in the server group (pktcMtaDevServer). These objects define various parameters for the AP-exchange process between an MTA and the Provisioning Server. These objects are: - pktcMtaDevProvUnsolicitedKeyMaxTimeout, - pktcMtaDevProvUnsolicitedKeyNomTimeout, Nechamkin & Mule Standards Track [Page 7] RFC 4682 IPCDN MTA MIB December 2006 - pktcMtaDevProvUnsolicitedKeyMaxRetries, and - pktcMtaDevProvSolicitedKeyTimeout. 3.6. Secure Software Download E-MTAs are embedded with DOCSIS 1.1 cable modems. E-MTAs have their software upgraded by the Cable Modem according to the DOCSIS requirements. Although E-MTAs have their software upgraded by the Cable Modem according to the DOCSIS requirements, S-MTAs implement a specific mechanism for Secure Software Download. This provides a means to verify the code upgrade using Code Verification Certificates and is modeled after the DOCSIS mechanism implemented in Cable Modems. This is the reason why the MTA MIB and the S-MTA compliance modules also rely on two MIB object groups: - docsBpi2CodeDownloadGroup, defined in the IETF BPI Plus MIB module (DOCS-IETF-BPI2-MIB [RFC4131]). - docsDevSoftwareGroupV2, defined in the IETF Cable Devicev2 MIB module (DOCS-CABLE-DEVICE-MIB [RFC4639]). 3.7. X.509 Certificates Dependencies As specified in the PacketCable Security Specification [PKT-SP-SEC], E-MTAs must use the authentication mechanism based on the X.509 Public Key Infrastructure Certificates, as defined in RFC 3280 [RFC3280] and RFC 4630 [RFC4630]. The value of the pktcMtaDevRealmOrgName MIB object should contain the X.509 organization name attribute of the Telephony Service Provider certificate (OrganizationName). X.509 attributes are defined using UTF-8 string encoding [RFC3629, RFC3280, and RFC4630]. Note that UTF-8 encoded characters can be encoded as sequences of 1 to 6 octets, assuming that code points as high as 0x7ffffffff might be used ([RFC3629]). Subsequent versions of Unicode and ISO 10646 have limited the upper bound to 0x10ffff ([RFC3629]). Consequently, the current version of UTF-8, defined in RFC 3629, does not require more than four octets to encode a valid code point. Nechamkin & Mule Standards Track [Page 8] RFC 4682 IPCDN MTA MIB December 2006 4. Definitions The MIB module below makes references and citations to [RFC868], [RFC3280], [RFC4630], and [RFC3617]. PKTC-IETF-MTA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Unsigned32, Counter32, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC -- [RFC2579] OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] sysDescr FROM SNMPv2-MIB -- [RFC3418] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] docsDevSoftwareGroupV2 FROM DOCS-CABLE-DEVICE-MIB -- [RFC4639] DocsX509ASN1DEREncodedCertificate, docsBpi2CodeDownloadGroup FROM DOCS-IETF-BPI2-MIB -- [RFC4131] LongUtf8String FROM SYSAPPL-MIB -- [RFC2287] ifPhysAddress FROM IF-MIB; -- [RFC2863] pktcIetfMtaMib MODULE-IDENTITY LAST-UPDATED "200609180000Z" -- September 18, 2006 ORGANIZATION "IETF IP over Cable Data Network Working Group" CONTACT-INFO "Eugene Nechamkin Broadcom Corporation, 200-13711 International Place, Nechamkin & Mule Standards Track [Page 9] RFC 4682 IPCDN MTA MIB December 2006 Richmond, BC, V6V 2Z8 CANADA Phone: +1 604 233 8500 Email: enechamkin@broadcom.com Jean-Francois Mule Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80027-9750 U.S.A. Phone: +1 303 661 9100 Email: jf.mule@cablelabs.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-Chair: Jean-Francois Mule, jf.mule@cablelabs.com Co-Chair: Richard Woundy, Richard_Woundy@cable.comcast.com" DESCRIPTION "This MIB module defines the basic management object for the Multimedia Terminal Adapter devices compliant with PacketCable and IPCablecom requirements. Copyright (C) The IETF Trust (2006). This version of this MIB module is part of RFC 4682; see the RFC itself for full legal notices." REVISION "200609180000Z" -- September 18, 2006 DESCRIPTION "Initial version, published as RFC 4682." ::= { mib-2 140 } -- Textual Conventions PktcMtaDevProvEncryptAlg ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " This textual convention defines various types of the encryption algorithms used for the encryption of the MTA configuration file. The description of the encryption algorithm for each enumerated value is as follows: 'none(0)' no encryption is used, 'des64CbcMode(1)' DES 64-bit key in CBC mode, Nechamkin & Mule Standards Track [Page 10] RFC 4682 IPCDN MTA MIB December 2006 't3Des192CbcMode(2)' 3DES 192-bit key in CBC mode, 'aes128CbcMode(3)' AES 128-bit key in CBC mode, 'aes256CbcMode(4)' AES 256-bit key in CBC mode." SYNTAX INTEGER { none (0), des64CbcMode (1), t3Des192CbcMode (2), aes128CbcMode (3), aes256CbcMode (4) } --================================================================= -- The MTA MIB module only supports a single Provisioning Server. --================================================================= pktcMtaNotification OBJECT IDENTIFIER ::= { pktcIetfMtaMib 0 } pktcMtaMibObjects OBJECT IDENTIFIER ::= { pktcIetfMtaMib 1 } pktcMtaDevBase OBJECT IDENTIFIER ::= { pktcMtaMibObjects 1 } pktcMtaDevServer OBJECT IDENTIFIER ::= { pktcMtaMibObjects 2 } pktcMtaDevSecurity OBJECT IDENTIFIER ::= { pktcMtaMibObjects 3 } pktcMtaDevErrors OBJECT IDENTIFIER ::= { pktcMtaMibObjects 4 } pktcMtaConformance OBJECT IDENTIFIER ::= { pktcIetfMtaMib 2 } -- -- The following pktcMtaDevBase group describes the base MTA objects -- pktcMtaDevResetNow OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION " This object controls the MTA software reset. Reading this object always returns 'false'. Setting this object to 'true' causes the device to reset immediately and the following actions to occur: 1. All connections (if present) are flushed locally. 2. All current actions such as ringing immediately terminate. 3. Requests for signaling notifications, such as notification based on digit map recognition, are flushed. 4. All endpoints are disabled. 5. The provisioning flow is started at step MTA-1. If a value is written into an instance of pktcMtaDevResetNow, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE Nechamkin & Mule Standards Track [Page 11] RFC 4682 IPCDN MTA MIB December 2006 " PacketCable MTA Device Provisioning Specification." ::= { pktcMtaDevBase 1 } pktcMtaDevSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object specifies the manufacturer's serial number of this MTA. The value of this object MUST be identical to the value specified in DHCP option 43, sub-option 4. The list of sub-options for DHCP option 43 are defined in the PacketCable MTA Device Provisioning Specification." REFERENCE " PacketCable MTA Device Provisioning Specification." ::= { pktcMtaDevBase 2 } pktcMtaDevSwCurrentVers OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object identifies the software version currently operating in the MTA. The MTA MUST return a string descriptive of the current software load. This object should use the syntax defined by the individual vendor to identify the software version. The data presented in this object MUST be identical to the software version information contained in the 'sysDescr' MIB object of the MTA. The value of this object MUST be identical to the value specified in DHCP option 43, sub-option 6. The list of sub-options for DHCP option 43 are defined in the PacketCable MTA Device Provisioning Specification." REFERENCE " PacketCable MTA Device Provisioning Specification." ::= { pktcMtaDevBase 3 } pktcMtaDevFQDN OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Fully Qualified Domain Name for this MTA. The MTA FQDN is used to uniquely identify the device to the PacketCable back office elements." Nechamkin & Mule Standards Track [Page 12] RFC 4682 IPCDN MTA MIB December 2006 ::= { pktcMtaDevBase 4 } pktcMtaDevEndPntCount OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the number of physical endpoints for this MTA." ::= { pktcMtaDevBase 5 } pktcMtaDevEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the MTA Admin Status of this device. If this object is set to 'true', the MTA is administratively enabled, and the MTA MUST be able to interact with the PacketCable entities, such as CMS, Provisioning Server, KDC, and other MTAs and MGs on all PacketCable interfaces. If this object is set to 'false', the MTA is administratively disabled, and the MTA MUST perform the following actions for all endpoints: - Shut down all media sessions, if present. - Shut down Network Control Signaling (NCS) signaling by following the Restart in Progress procedures in the PacketCable NCS specification. The MTA must execute all actions required to enable or disable the telephony services for all endpoints immediately upon receipt of an SNMP SET operation. Additionally, the MTA MUST maintain the SNMP Interface for management and also the SNMP Key management interface. Also, the MTA MUST NOT continue Kerberized key management with CMSes until this object is set to 'true'. Note: MTAs MUST renew the CMS Kerberos tickets according to the PacketCable Security or IPCablecom Specification. If a value is written into an instance of pktcMtaDevEnabled, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification; PacketCable Network-Based Call Signaling Protocol Nechamkin & Mule Standards Track [Page 13] RFC 4682 IPCDN MTA MIB December 2006 Specification." ::= { pktcMtaDevBase 6 } pktcMtaDevTypeIdentifier OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object provides the MTA device type identifier. The value of this object must be a copy of the DHCP option 60 value exchanged between the MTA and the DHCP server. The DHCP option 60 value contains an ASCII-encoded string identifying capabilities of the MTA as defined in the PacketCable MTA Device Provisioning Specification." REFERENCE " RFC 2132, DHCP Options and BOOTP Vendor Extensions; PacketCable MTA Device Provisioning Specification." ::= { pktcMtaDevBase 7 } pktcMtaDevProvisioningState OBJECT-TYPE SYNTAX INTEGER { pass (1), inProgress (2), failConfigFileError (3), passWithWarnings (4), passWithIncompleteParsing (5), failureInternalError (6), failureOtherReason (7) } MAX-ACCESS read-only STATUS current DESCRIPTION " This object indicates the completion state of the MTA device provisioning process. pass: If the configuration file could be parsed successfully and the MTA is able to reflect the same in its MIB, the MTA MUST return the value 'pass'. inProgress: If the MTA is in the process of being provisioned, the MTA MUST return the value 'inProgress'. failConfigFileError: If the configuration file was in error due to incorrect values in the mandatory parameters, the MTA MUST reject the configuration file, and the MTA MUST return the value Nechamkin & Mule Standards Track [Page 14] RFC 4682 IPCDN MTA MIB December 2006 'failConfigFileError'. passWithWarnings: If the configuration file had proper values for all the mandatory parameters but has errors in any of the optional parameters (this includes any vendor-specific Object Identifiers (OIDs) that are incorrect or not known to the MTA), the MTA MUST return the value 'passWithWarnings'. passWithIncompleteParsing: If the configuration file is valid but the MTA cannot reflect the same in its configuration (for example, too many entries caused memory exhaustion), it must accept the CMS configuration entries related, and the MTA MUST return the value 'passWithIncompleteParsing'. failureInternalError: If the configuration file cannot be parsed due to an Internal error, the MTA MUST return the value 'failureInternalError'. failureOtherReason: If the MTA cannot accept the configuration file for any other reason than the ones stated above, the MTA MUST return the value 'failureOtherReason'. When a final SNMP INFORM is sent as part of Step 25 of the MTA Provisioning process, this parameter is also included in the final INFORM message." REFERENCE " PacketCable MTA Device Provisioning Specification." ::= { pktcMtaDevBase 8 } pktcMtaDevHttpAccess OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION " This object indicates whether the HTTP protocol is supported for the MTA configuration file transfer." ::= { pktcMtaDevBase 9 } pktcMtaDevProvisioningTimer OBJECT-TYPE SYNTAX Unsigned32 (0..30) UNITS "minutes" MAX-ACCESS read-write STATUS current Nechamkin & Mule Standards Track [Page 15] RFC 4682 IPCDN MTA MIB December 2006 DESCRIPTION " This object defines the time interval for the provisioning flow to complete. The MTA MUST finish all provisioning operations starting from the moment when an MTA receives its DHCP ACK and ending at the moment when the MTA downloads its configuration file (e.g., MTA5 to MTA23) within the period of time set by this object. Failure to comply with this condition constitutes a provisioning flow failure. If the object is set to 0, the MTA MUST ignore the provisioning timer condition. If a value is written into an instance of pktcMtaDevProvisioningTimer, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " PacketCable MTA Device Provisioning Specification." DEFVAL {10} ::= {pktcMtaDevBase 10} pktcMtaDevProvisioningCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of times the provisioning cycle has looped through step MTA-1." ::= {pktcMtaDevBase 11} pktcMtaDevErrorOidsTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcMtaDevErrorOidsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table contains the list of configuration errors or warnings the MTA encountered when parsing the configuration file it received from the Provisioning Server. For each error, an entry is created in this table, containing the configuration parameters the MTA rejected and the associated reason (e.g., wrong or unknown OID, inappropriate object values). If the MTA did not report a provisioning state of 'pass(1)' in the pktcMtaDevProvisioningState object, this table MUST be populated for each error or warning instance. Even if different parameters share the same error type (e.g., all realm name configuration parameters are invalid), all observed errors or warnings must be reported as different instances. Errors are placed into the table in no particular order. The table MUST be cleared each time Nechamkin & Mule Standards Track [Page 16] RFC 4682 IPCDN MTA MIB December 2006 the MTA reboots." REFERENCE " PacketCable MTA Device Provisioning Specification." ::= {pktcMtaDevBase 12 } pktcMtaDevErrorOidsEntry OBJECT-TYPE SYNTAX PktcMtaDevErrorOidsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This entry contains the necessary information the MTA MUST attempt to provide in case of configuration file errors or warnings." INDEX { pktcMtaDevErrorOidIndex } ::= {pktcMtaDevErrorOidsTable 1} PktcMtaDevErrorOidsEntry ::= SEQUENCE { pktcMtaDevErrorOidIndex Unsigned32, pktcMtaDevErrorOid SnmpAdminString, pktcMtaDevErrorValue SnmpAdminString, pktcMtaDevErrorReason SnmpAdminString } pktcMtaDevErrorOidIndex OBJECT-TYPE SYNTAX Unsigned32 (1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object is the index of the MTA configuration error table. It is an integer value that starts at value '1' and is incremented for each encountered configuration file error or warning. The maximum number of errors or warnings that can be recorded in the pktcMtaDevErrorOidsTable is set to 1024 as a configuration file is usually validated by operators before deployment. Given the possible number of configuration parameter assignments in the MTA configuration file, 1024 is perceived as a sufficient limit even with future extensions. If the number of the errors in the configuration file exceeds 1024, all errors beyond the 1024th one MUST be ignored and not be reflected in the pktcMtaDevErrorOidsTable." ::= {pktcMtaDevErrorOidsEntry 1} Nechamkin & Mule Standards Track [Page 17] RFC 4682 IPCDN MTA MIB December 2006 pktcMtaDevErrorOid OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains a human readable representation (character string) of the OID corresponding to the configuration file parameter that caused the particular error. For example, if the value of the pktcMtaDevEnabled object in the configuration file caused an error, then this object instance will contain the human-readable string of '1.3.6.1.2.1.140.1.1.6.0'. If the MTA generated an error because it was not able to recognize a particular OID, then this object instance would contain an empty value (zero-length string). For example, if the value of an OID in the configuration file was interpreted by the MTA as being 1.2.3.4.5, and if the MTA was not able to recognize this OID as a valid one, this object instance will contain a zero-length string. If the number of errors in the configuration file exceeds 1024, then for all subsequent errors, the pktcMtaDevErrorOid of the table's 1024th entry MUST contain a human-readable representation of the pktcMtaDevErrorsTooManyErrors object; i.e., the string '1.3.6.1.2.1.140.1.1.4.1.0'. Note that the syntax of this object is SnmpAdminString instead of OBJECT IDENTIFIER because the object value may not be a valid OID due to human or configuration tool encoding errors." ::= {pktcMtaDevErrorOidsEntry 2} pktcMtaDevErrorValue OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the value of the OID corresponding to the configuration file parameter that caused the error. If the MTA cannot recognize the OID of the configuration parameter causing the error, then this object instance contains the OID itself as interpreted by the MTA in human-readable representation. If the MTA can recognize the OID but generate an error due to a wrong value of the parameter, then the object Nechamkin & Mule Standards Track [Page 18] RFC 4682 IPCDN MTA MIB December 2006 instance contains the erroneous value of the parameter as read from the configuration file. In both cases, the value of this object must be represented in human-readable form as a character string. For example, if the value of the pktcMtaDevEnabled object in the configuration file was 3 (invalid value), then the pktcMtaDevErrorValue object instance will contain the human-readable (string) representation of value '3'. Similarly, if the OID in the configuration file has been interpreted by the MTA as being 1.2.3.4.5 and the MTA cannot recognize this OID as a valid one, then this pktcMtaDevErrorValue object instance will contain human readable (string) representation of value '1.2.3.4.5'. If the number of errors in the configuration file exceeds 1024, then for all subsequent errors, the pktcMtaDevErrorValue of the table's 1024th entry MUST contain a human-readable representation of the pktcMtaDevErrorsTooManyErrors object; i.e., the string '1.3.6.1.2.1.140.1.1.4.1.0'." ::= {pktcMtaDevErrorOidsEntry 3} pktcMtaDevErrorReason OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object indicates the reason for the error or warning, as per the MTA's interpretation, in human-readable form. For example: 'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE', 'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO', 'OUT OF MEMORY - CANNOT STORE'. This object may also contain vendor specific errors for private vendor OIDs and any proprietary error codes or messages that can help diagnose configuration errors. If the number of errors in the configuration file exceeds 1024, then for all subsequent errors, the pktcMtaDevErrorReason of the table's 1024th entry MUST contain a human-readable string indicating the reason for an error; for example, 'Too many errors in the configuration file'." ::= {pktcMtaDevErrorOidsEntry 4} -- -- The following group describes server access and parameters used Nechamkin & Mule Standards Track [Page 19] RFC 4682 IPCDN MTA MIB December 2006 -- for the initial MTA provisioning and bootstrapping phases. -- pktcMtaDevDhcpServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Internet address type for the PacketCable DHCP servers specified in MTA MIB." DEFVAL { ipv4 } ::= { pktcMtaDevServer 1} pktcMtaDevServerDhcp1 OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Internet Address of the primary DHCP server the MTA uses during provisioning. The type of this address is determined by the value of the pktcMtaDevDhcpServerAddressType object. When the latter has the value 'ipv4(1)', this object contains the IP address of the primary DHCP server. It is provided by the CM to the MTA via the DHCP option code 122, sub-option 1, as defined in RFC 3495. The behavior of this object when the value of pktcMtaDevDhcpServerAddressType is other than 'ipv4(1)' is not presently specified, but it may be specified in future versions of this MIB module. If this object is of value 0.0.0.0, the MTA MUST stop all provisioning attempts, as well as all other activities. If this object is of value 255.255.255.255, it means that there was no preference given for the primary DHCP server, and, the MTA must follow the logic of RFC2131, and the value of DHCP option 122, sub-option 2, must be ignored." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 2131, Dynamic Host Configuration Protocol; RFC 3495, DHCP Option for CableLabs Client Configuration." ::= { pktcMtaDevServer 2 } pktcMtaDevServerDhcp2 OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only Nechamkin & Mule Standards Track [Page 20] RFC 4682 IPCDN MTA MIB December 2006 STATUS current DESCRIPTION " This object contains the Internet Address of the secondary DHCP server the MTA uses during provisioning. The type of this address is determined by the value of the pktcMtaDevDhcpServerAddressType object. When the latter has the value 'ipv4(1)', this object contains the IP address of the secondary DHCP server. It is provided by the CM to the MTA via the DHCP option code 122, sub-option 2, as defined in RFC 3495. The behavior of this object when the value of pktcMtaDevDhcpServerAddressType is other than 'ipv4(1)' is not presently specified, but it may be specified in future versions of this MIB module. If there was no secondary DHCP server provided in DHCP Option 122, sub-option 2, this object must return the value 0.0.0.0." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 3495, DHCP Option for CableLabs Client Configuration." ::= { pktcMtaDevServer 3 } pktcMtaDevDnsServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Internet address type for the PacketCable DNS servers specified in MTA MIB." DEFVAL { ipv4 } ::= { pktcMtaDevServer 4} pktcMtaDevServerDns1 OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the IP Address of the primary DNS server to be used by the MTA. The type of this address is determined by the value of the pktcMtaDevDnsServerAddressType object. When the latter has the value 'ipv4(1)', this object contains the IP address of the primary DNS server. As defined in RFC 2132, PacketCable-compliant MTAs receive the IP addresses of the DNS Servers in DHCP option 6. The behavior of this object when the value of pktcMtaDevDnsServerAddressType is other than 'ipv4(1)' Nechamkin & Mule Standards Track [Page 21] RFC 4682 IPCDN MTA MIB December 2006 is not presently specified, but it may be specified in future versions of this MIB module. If a value is written into an instance of pktcMtaDevServerDns1, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 2132, DHCP Options and BOOTP Vendor Extensions." ::= { pktcMtaDevServer 5 } pktcMtaDevServerDns2 OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the IP Address of the secondary DNS server to be used by the MTA. The type of this address is determined by the value of the pktcMtaDevDnsServerAddressType object. When the latter has the value 'ipv4(1)', this object contains the IP address of the secondary DNS server. As defined in RFC 2132, PacketCable-compliant MTAs receive the IP addresses of the DNS Servers in DHCP option 6. The behavior of this object when the value of pktcMtaDevDnsServerAddressType is other than 'ipv4(1)' is not presently specified, but it may be specified in future versions of this MIB module. If a value is written into an instance of pktcMtaDevServerDns2, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 2132, DHCP Options and BOOTP Vendor Extensions." ::= { pktcMtaDevServer 6 } pktcMtaDevTimeServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the Internet address type for the PacketCable Time servers specified in MTA MIB." DEFVAL { ipv4 } ::= { pktcMtaDevServer 7} pktcMtaDevTimeServer OBJECT-TYPE SYNTAX InetAddress Nechamkin & Mule Standards Track [Page 22] RFC 4682 IPCDN MTA MIB December 2006 MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the Internet Address of the Time Server used by an S-MTA for Time Synchronization. The type of this address is determined by the value of the pktcMtaDevTimeServerAddressType object. When the latter has the value 'ipv4(1)', this object contains the IP address of the Time Server used for Time Synchronization. In the case of an S-MTA, this object must be populated with a value other than 0.0.0.0 as obtained from DHCP option 4. The protocol by which the time of day MUST be retrieved is defined in RFC 868. In the case of an E-MTA, this object must contain a value of 0.0.0.0 if the address type is 'ipv4(1)' since an E-MTA does not use the Time Protocol for time synchronization (an E-MTA uses the time retrieved by the DOCSIS cable modem). The behavior of this object when the value of pktcMtaDevTimeServerAddressType is other than 'ipv4(1)' is not presently specified, but it may be specified in future versions of this MIB module. If a value is written into an instance of pktcMtaDevTimeServer, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " RFC 868, Time Protocol; RFC 2131, Dynamic Host Configuration Protocol; RFC 2132, DHCP Options and BOOTP Vendor Extensions." ::= { pktcMtaDevServer 8} pktcMtaDevConfigFile OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the MTA device configuration file information, including the access method, the server name, and the configuration file name. The value of this object is the Uniform Resource Locator (URL) of the configuration file for TFTP or HTTP download. If this object value is a TFTP URL, it must be formatted as defined in RFC 3617. If this object value is an HTTP URL, it must be formatted as defined in RFC 2616. If the MTA SNMP Enrollment mechanism is used, then the MTA must download the file provided by the Provisioning Server Nechamkin & Mule Standards Track [Page 23] RFC 4682 IPCDN MTA MIB December 2006 during provisioning via an SNMP SET on this object. If the MTA SNMP Enrollment mechanism is not used, this object MUST contain the URL value corresponding to the 'siaddr' and 'file' fields received in the DHCP ACK to locate the configuration file: the 'siaddr' and 'file' fields represent the host and file of the TFTP URL, respectively. In this case, the MTA MUST return an 'inconsistentValue' error in response to SNMP SET operations. The MTA MUST return a zero-length string if the server address (host part of the URL) is unknown. If a value is written into an instance of pktcMtaDevConfigFile, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 3617, URI Scheme for TFTP; RFC 2616, HTTP 1.1" ::= { pktcMtaDevServer 9 } pktcMtaDevSnmpEntity OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the FQDN of the SNMP entity of the Provisioning Server. When the MTA SNMP Enrollment Mechanism is used, this object represents the server that the MTA communicates with, that it receives the configuration file URL from, and that it sends the enrollment notification to. The SNMP entity is also the destination entity for all the provisioning notifications. It may be used for post-provisioning SNMP operations. During the provisioning phase, this SNMP entity FQDN is supplied to the MTA via DHCP option 122, sub-option 3, as defined in RFC 3495. The MTA must resolve the FQDN value before its very first network interaction with the SNMP entity during the provisioning phase." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 3495, DHCP Option for CableLabs Client Configuration." ::= { pktcMtaDevServer 10 } pktcMtaDevProvConfigHash OBJECT-TYPE SYNTAX OCTET STRING (SIZE(20)) MAX-ACCESS read-write STATUS current Nechamkin & Mule Standards Track [Page 24] RFC 4682 IPCDN MTA MIB December 2006 DESCRIPTION " This object contains the hash value of the contents of the configuration file. The authentication algorithm is Secure Hashing Algorithm 1 (SHA-1), and the length is 160 bits. The hash calculation MUST follow the requirements defined in the PacketCable Security Specification. When the MTA SNMP Enrollment mechanism is used, this hash value is calculated and sent to the MTA prior to sending the config file. This object value is then provided by the Provisioning server via an SNMP SET operation. When the MTA SNMP Enrollment mechanism is not in use, the hash value is provided in the configuration file itself, and it is also calculated by the MTA. This object value MUST represent the hash value calculated by the MTA. When the MTA SNMP Enrollment mechanism is not in use, the MTA must reject all SNMP SET operations on this object and return an 'inconsistentValue' error. If a value is written into an instance of pktcMtaDevProvConfigHash, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification." ::= { pktcMtaDevServer 11 } pktcMtaDevProvConfigKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE(32)) MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the key used to encrypt/decrypt the configuration file when secure SNMPv3 provisioning is used. The value of this object is provided along with the configuration file information (pktcMtaDevConfigFile) and hash (pktcMtaDevProvConfigHash) by the Provisioning Server via SNMP SET once the configuration file has been created, as defined by the PacketCable Security specification. The privacy algorithm is defined by the pktcMtaDevProvConfigEncryptAlg MIB object. The MTA requirements related to the privacy algorithm are defined in the PacketCable Security Specification. If this object is set at any other provisioning step than that allowed by the PacketCable MTA Device Nechamkin & Mule Standards Track [Page 25] RFC 4682 IPCDN MTA MIB December 2006 Provisioning Specification, the MTA SHOULD return an 'inconsistentValue' error. This object must not be used in non secure provisioning mode. In non-secure provisioning modes, the MTA SHOULD return an 'inconsistentValue' in response to SNMP SET operations, and the MTA SHOULD return a zero-length string in response to SNMP GET operations. If a value is written into an instance of pktcMtaDevProvConfigKey, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification." ::= { pktcMtaDevServer 12 } pktcMtaDevProvConfigEncryptAlg OBJECT-TYPE SYNTAX PktcMtaDevProvEncryptAlg MAX-ACCESS read-write STATUS current DESCRIPTION " This object defines the encryption algorithm used for privacy protection of the MTA Configuration File content." DEFVAL { des64CbcMode } ::= { pktcMtaDevServer 13 } pktcMtaDevProvSolicitedKeyTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..180) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object defines a Kerberos Key Management timer on the MTA. It is the time period during which the MTA saves the nonce and Server Kerberos Principal Identifier to match an AP Request and its associated AP Reply response from the Provisioning Server. After the timeout has been exceeded, the client discards this (nonce, Server Kerberos Principal Identifier) pair, after which it will no longer accept a matching AP Reply. This timer only applies when the Provisioning Server initiated key management for SNMPv3 (with a Wake Up message). If this object is set to a zero value, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations. This object should not be used in non-secure provisioning modes. In non-secure provisioning modes, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations, and the MTA MUST return a zero value in Nechamkin & Mule Standards Track [Page 26] RFC 4682 IPCDN MTA MIB December 2006 response to SNMP GET operations. If a value is written into an instance of pktcMtaDevProvSolicitedKeyTimeout, the agent MUST NOT retain the supplied value across MTA re-initializations or reboots." DEFVAL { 3 } ::= { pktcMtaDevServer 14 } --================================================================= -- -- Unsolicited key updates are retransmitted according to an -- exponential back-off mechanism using two timers and a maximum -- retry counter for AS replies. -- The initial retransmission timer value is the nominal timer -- value (pktcMtaDevProvUnsolicitedKeyNomTimeout). The -- retransmissions occur with an exponentially increasing interval -- that caps at the maximum timeout value -- (pktcMtaDevProvUnsolicitedKeyMaxTimeout). -- Retransmissions stop when the maximum retry counter is reached -- (pktcMtaDevProvUnsolicitedKeyMaxRetries). -- For example, with values of 3 seconds for the nominal -- timer, 100 seconds for the maximum timeout, and 8 retries max, -- and with an exponential value of 2, this results in -- retransmission intervals will be 3 s, 6 s, 12 s, 24 s, 48 s, -- 96 s, 100 s, and 100 s; -- retransmissions then stop because the maximum number of -- retries (8) has been reached. -- --================================================================= -- -- Timeouts for unsolicited key management updates are only -- pertinent before the first SNMPv3 message is sent between the -- MTA and the Provisioning Server and before the configuration -- file is loaded. -- --================================================================= pktcMtaDevProvUnsolicitedKeyMaxTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..600) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This object defines the timeout value that applies to an MTA-initiated AP-REQ/REP key management exchange with the Provisioning Server in SNMPv3 provisioning. It is the maximum timeout value, and it may not be exceeded in the exponential back-off algorithm. If the DHCP option Nechamkin & Mule Standards Track [Page 27] RFC 4682 IPCDN MTA MIB December 2006 code 122, sub-option 5, is provided to the MTA, it overwrites this value. In non-secure provisioning modes, the MTA MUST return a zero value in response to SNMP GET operations." REFERENCE " PacketCable Security Specification." DEFVAL {600} ::= { pktcMtaDevServer 15 } pktcMtaDevProvUnsolicitedKeyNomTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..600) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This object defines the starting value of the timeout for the AP-REQ/REP Backoff and Retry mechanism with exponential timeout in SNMPv3 provisioning. If the DHCP option code 122, sub-option 5, is provided the MTA, it overwrites this value. In non-secure provisioning modes, the MTA MUST return a zero value in response to SNMP GET operations." REFERENCE " PacketCable Security Specification." DEFVAL {3} ::= { pktcMtaDevServer 16} pktcMtaDevProvUnsolicitedKeyMaxRetries OBJECT-TYPE SYNTAX Unsigned32 (0..32) MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains a retry counter that applies to an MTA-initiated AP-REQ/REP key management exchange with the Provisioning Server in secure SNMPv3 provisioning. It is the maximum number of retries before the MTA stops attempting to establish a Security Association with Provisioning Server. If the DHCP option code 122, sub-option 5, is provided to the MTA, it overwrites this value. If this object is set to a zero value, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations. In non-secure provisioning modes, the MTA MUST return a zero value in response to SNMP GET operations." REFERENCE Nechamkin & Mule Standards Track [Page 28] RFC 4682 IPCDN MTA MIB December 2006 " PacketCable Security Specification." DEFVAL {8} ::= { pktcMtaDevServer 17 } pktcMtaDevProvKerbRealmName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the name of the associated provisioning Kerberos realm acquired during the MTA4 provisioning step (DHCP Ack) for SNMPv3 provisioning. The uppercase ASCII representation of the associated Kerberos realm name MUST be used by both the Manager (SNMP entity) and the MTA. The Kerberos realm name for the Provisioning Server is supplied to the MTA via DHCP option code 122, sub-option 6, as defined in RFC 3495. In secure SNMP provisioning mode, the value of the Kerberos realm name for the Provisioning Server supplied in the MTA configuration file must match the value supplied in the DHCP option code 122, sub-option 6. Otherwise, the value of this object must contain the value supplied in DHCP Option 122, sub-option 6." REFERENCE " PacketCable MTA Device Provisioning Specification; RFC 3495, DHCP Option for CableLabs Client Configuration." ::= { pktcMtaDevServer 18 } pktcMtaDevProvState OBJECT-TYPE SYNTAX INTEGER { operational (1), waitingForSnmpSetInfo (2), waitingForTftpAddrResponse (3), waitingForConfigFile (4) } MAX-ACCESS read-only STATUS current DESCRIPTION " This object defines the MTA provisioning state. If the state is: 'operational(1)', the device has completed the loading and processing of the initialization parameters. 'waitingForSnmpSetInfo(2)', the device is waiting on its configuration file download access information. Note that this state is only reported when the MTA Nechamkin & Mule Standards Track [Page 29] RFC 4682 IPCDN MTA MIB December 2006 SNMP enrollment mechanism is used. 'waitingForTftpAddrResponse(3)', the device has sent a DNS request to resolve the server providing the configuration file, and it is awaiting for a response. Note that this state is only reported when the MTA SNMP enrollment mechanism is used. 'waitingForConfigFile(4)', the device has sent a request via TFTP or HTTP for the download of its configuration file, and it is awaiting for a response or the file download is in progress." REFERENCE " PacketCable MTA Device Provisioning Specification, PacketCable Security Specification." ::= { pktcMtaDevServer 19 } -- -- The following object group describes the security objects. -- pktcMtaDevManufacturerCertificate OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the MTA Manufacturer Certificate. The object value must be the ASN.1 DER encoding of the MTA manufacturer's X.509 public key certificate. The MTA Manufacturer Certificate is issued to each MTA manufacturer and is installed into each MTA at the time of manufacture or with a secure code download. The specific requirements related to this certificate are defined in the PacketCable or IPCablecom Security specifications." REFERENCE " PacketCable Security Specification." ::= {pktcMtaDevSecurity 1} pktcMtaDevCertificate OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the MTA Device Certificate. The object value must be the ASN.1 DER encoding of the MTA's X.509 public-key certificate issued by the manufacturer and installed into the MTA at the time of Nechamkin & Mule Standards Track [Page 30] RFC 4682 IPCDN MTA MIB December 2006 manufacture or with a secure code download. This certificate contains the MTA MAC address. The specific requirements related to this certificate are defined in the PacketCable or IPCablecom Security specifications." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevSecurity 2 } pktcMtaDevCorrelationId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains a correlation ID, an arbitrary value generated by the MTA that will be exchanged as part of the device capability data to the Provisioning Application. This random value is used as an identifier to correlate related events in the MTA provisioning sequence. This value is intended for use only during the MTA initialization and configuration file download." REFERENCE " PacketCable MTA Device Provisioning Specification." ::= { pktcMtaDevSecurity 3 } pktcMtaDevTelephonyRootCertificate OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the telephony Service Provider Root certificate. The object value is the ASN.1 DER encoding of the IP Telephony Service Provider Root X.509 public key certificate. This certification is stored in the MTA non-volatile memory and can be updated with a secure code download. This certificate is used to validate the initial AS Reply received by the MTA from the Key Distribution Center (KDC) during the MTA initialization. The specific requirements related to this certificate are defined in the PacketCable or IPCablecom Security specifications." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevSecurity 4 } --================================================================= -- -- Informative Procedures for Setting up Security Associations -- Nechamkin & Mule Standards Track [Page 31] RFC 4682 IPCDN MTA MIB December 2006 -- A Security Association may be set up either via configuration or -- via NCS signaling. -- -- I. Security association setup via configuration. -- -- The realm must be configured first. Associated with the realm -- is a KDC. The realm table (pktcMtaDevRealmTable) indicates -- information about the realm (e.g., name, organization name) and -- parameters associated with KDC communications (e.g., grace -- periods, AS Request/AS Reply adaptive back-off parameters). -- -- Once the realm is established, one or more CMS(es) may be -- defined in the realm. Associated with each CMS -- entry in the pktcMtaDevCmsTable is an explicit reference -- to a Realm via the realm name (pktcMtaDevCmsKerbRealmName), -- the FQDN of the CMS, and parameters associated with IPSec -- key management with the CMS (e.g., clock skew, AP Request/ -- AP Reply adaptive back-off parameters). -- -- II. Security association setup via NCS signaling. -- -- The procedure of establishing the Security Associations -- for NCS signaling is described in the PacketCable Security -- specification. -- It involves the analysis of the pktcNcsEndPntConfigTable row -- for the corresponding endpoint number and the correlation of -- the CMS FQDN from this row with the CMS Table and -- consequently, with the Realm Table. Both of these tables -- are defined below. The pktcNcsEndPntConfigTable is defined in -- the IP over Cable Data Network (IPCDN) -- NCS Signaling MIB [NCSSIGMIB]. -- -- III. When the MTA receives wake-up or re-key messages from a -- CMS, it performs key management based on the corresponding -- entry in the CMS table. If the matching CMS entry does not -- exist, it must ignore the wake-up or re-key messages. -- --================================================================= --================================================================= -- -- pktcMtaDevRealmTable -- -- The pktcMtaDevRealmTable shows the KDC realms. The table is -- indexed with pktcMtaDevRealmIndex. The Realm Table contains the -- pktcMtaDevRealmName in conjunction with any server that needs -- a Security Association with the MTA. Uppercase must be used -- to compare the pktcMtaDevRealmName content. -- Nechamkin & Mule Standards Track [Page 32] RFC 4682 IPCDN MTA MIB December 2006 --================================================================= pktcMtaDevRealmAvailSlot OBJECT-TYPE SYNTAX Unsigned32 (0..64) MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the index number of the first available entry in the realm table (pktcMtaDevRealmTable). If all the entries in the realm table have been assigned, this object contains the value of zero. A management station should create new entries in the realm table, using the following procedure: First, issue a management protocol retrieval operation to determine the value of the first available index in the realm table (pktcMtaDevRealmAvailSlot). Second, issue a management protocol SET operation to create an instance of the pktcMtaDevRealmStatus object by setting its value to 'createAndWait(5)'. Third, if the SET operation succeeded, continue modifying the object instances corresponding to the newly created conceptual row, without fear of collision with other management stations. When all necessary conceptual columns of the row are properly populated (via SET operations or default values), the management station may SET the pktcMtaDevRealmStatus object to 'active(1)'." ::= { pktcMtaDevSecurity 5 } pktcMtaDevRealmTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcMtaDevRealmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object contains the realm table. The CMS table (pktcMtaDevCmsTable) and the realm table (pktcMtaDevRealmTable) are used for managing the MTA-CMS Security Associations. The realm table defines the Kerberos realms for the Application Servers (CMSes and the Provisioning Server)." ::= { pktcMtaDevSecurity 6 } pktcMtaDevRealmEntry OBJECT-TYPE SYNTAX PktcMtaDevRealmEntry MAX-ACCESS not-accessible STATUS current Nechamkin & Mule Standards Track [Page 33] RFC 4682 IPCDN MTA MIB December 2006 DESCRIPTION " This table entry object lists the MTA security parameters for a single Kerberos realm. The conceptual rows MUST NOT persist across MTA reboots." INDEX { pktcMtaDevRealmIndex } ::= { pktcMtaDevRealmTable 1 } PktcMtaDevRealmEntry ::= SEQUENCE { pktcMtaDevRealmIndex Unsigned32, pktcMtaDevRealmName SnmpAdminString, pktcMtaDevRealmPkinitGracePeriod Unsigned32, pktcMtaDevRealmTgsGracePeriod Unsigned32, pktcMtaDevRealmOrgName LongUtf8String, pktcMtaDevRealmUnsolicitedKeyMaxTimeout Unsigned32, pktcMtaDevRealmUnsolicitedKeyNomTimeout Unsigned32, pktcMtaDevRealmUnsolicitedKeyMaxRetries Unsigned32, pktcMtaDevRealmStatus RowStatus } pktcMtaDevRealmIndex OBJECT-TYPE SYNTAX Unsigned32 (1..64) MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object defines the realm table index." ::= { pktcMtaDevRealmEntry 1} pktcMtaDevRealmName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object identifies the Kerberos realm name in all capitals. The MTA MUST prohibit the instantiation of any two rows with identical Kerberos realm names. The MTA MUST also verify that any search operation involving Kerberos realm names is done using the uppercase ASCII representation of the characters." ::= { pktcMtaDevRealmEntry 2 } pktcMtaDevRealmPkinitGracePeriod OBJECT-TYPE SYNTAX Unsigned32 (15..600) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the PKINIT Grace Period. For the purpose of key management with Application Servers (CMSes Nechamkin & Mule Standards Track [Page 34] RFC 4682 IPCDN MTA MIB December 2006 or the Provisioning Server), the MTA must utilize the PKINIT exchange to obtain Application Server tickets. The MTA may utilize the PKINIT exchange to obtain Ticket Granting Tickets (TGTs), which are then used to obtain Application Server tickets in a TGS exchange. The PKINIT exchange occurs according to the current Ticket Expiration Time (TicketEXP) and on the PKINIT Grace Period (PKINITGP). The MTA MUST initiate the PKINIT exchange at the time: TicketEXP - PKINITGP." REFERENCE " PacketCable Security Specification." DEFVAL { 15 } ::= { pktcMtaDevRealmEntry 3 } pktcMtaDevRealmTgsGracePeriod OBJECT-TYPE SYNTAX Unsigned32 (1..600) UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the Ticket Granting Server Grace Period (TGSGP). The Ticket Granting Server (TGS) Request/Reply exchange may be performed by the MTA on demand whenever an Application Server ticket is needed to establish security parameters. If the MTA possesses a ticket that corresponds to the Provisioning Server or a CMS that currently exists in the CMS table, the MTA MUST initiate the TGS Request/Reply exchange at the time: TicketEXP - TGSGP." REFERENCE " PacketCable Security Specification." DEFVAL { 10 } ::= { pktcMtaDevRealmEntry 4 } pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8String MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider certificate." REFERENCE " PacketCable Security Specification; RFCs 3280 and 4630, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" ::= { pktcMtaDevRealmEntry 5 } Nechamkin & Mule Standards Track [Page 35] RFC 4682 IPCDN MTA MIB December 2006 pktcMtaDevRealmUnsolicitedKeyMaxTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..600) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object specifies the maximum time the MTA will attempt to perform the exponential back-off algorithm. This timer only applies when the MTA initiated key management. If the DHCP option code 122, sub-option 4, is provided to the MTA, it overwrites this value. Unsolicited key updates are retransmitted according to an exponential back-off mechanism using two timers and a maximum retry counter for AS replies. The initial retransmission timer value is the nominal timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The retransmissions occur with an exponentially increasing interval that caps at the maximum timeout value (pktcMtaDevRealmUnsolicitedKeyMaxTimeout). Retransmissions stop when the maximum retry counter is reached (pktcMatDevRealmUnsolicitedMaxRetries). For example, with values of 3 seconds for the nominal timer, 20 seconds for the maximum timeout, and 5 retries max, retransmission intervals will be 3 s, 6 s, 12 s, 20 s, and 20 s, and retransmissions then stop because the maximum number of retries has been reached." REFERENCE " PacketCable Security Specification." DEFVAL { 100 } ::= { pktcMtaDevRealmEntry 6 } pktcMtaDevRealmUnsolicitedKeyNomTimeout OBJECT-TYPE SYNTAX Unsigned32 (100..600000) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object specifies the initial timeout value for the AS-REQ/AS-REP exponential back-off and retry mechanism. If the DHCP option code 122, sub-option 4, is provided to the MTA, it overwrites this value. This value should account for the average roundtrip time between the MTA and the KDC, as well as the processing delay on the KDC. Nechamkin & Mule Standards Track [Page 36] RFC 4682 IPCDN MTA MIB December 2006 Unsolicited key updates are retransmitted according to an exponential back-off mechanism using two timers and a maximum retry counter for AS replies. The initial retransmission timer value is the nominal timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The retransmissions occur with an exponentially increasing interval that caps at the maximum timeout value (pktcMtaDevRealmUnsolicitedKeyMaxTimeout). Retransmissions stop when the maximum retry counter is reached (pktcMatDevRealmUnsolicitedMaxRetries). For example, with values of 3 seconds for the nominal timer, 20 seconds for the maximum timeout, and 5 retries max, in retransmission intervals will be 3 s, 6 s, 12 s, 20 s, and 20 s; retransmissions then stop because the maximum number of retries has been reached." REFERENCE " PacketCable Security Specification." DEFVAL { 3000 } ::= { pktcMtaDevRealmEntry 7 } pktcMtaDevRealmUnsolicitedKeyMaxRetries OBJECT-TYPE SYNTAX Unsigned32 (0..1024) MAX-ACCESS read-create STATUS current DESCRIPTION " This object specifies the maximum number of retries the MTA attempts to obtain a ticket from the KDC. Unsolicited key updates are retransmitted according to an exponential back-off mechanism using two timers and a maximum retry counter for AS replies. The initial retransmission timer value is the nominal timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The retransmissions occur with an exponentially increasing interval that caps at the maximum timeout value (pktcMtaDevRealmUnsolicitedKeyMaxTimeout). Retransmissions stop when the maximum retry counter is reached (pktcMatDevRealmUnsolicitedMaxRetries). For example, with values of 3 seconds for the nominal timer, 20 seconds for the maximum timeout, and 5 retries max, retransmission intervals will be 3 s, 6 s, 12 s, 20 s, and 20 s; retransmissions then stop because the maximum number of retries has been reached." REFERENCE " PacketCable Security Specification." DEFVAL { 5 } Nechamkin & Mule Standards Track [Page 37] RFC 4682 IPCDN MTA MIB December 2006 ::= { pktcMtaDevRealmEntry 8 } pktcMtaDevRealmStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION " This object defines the row status of this realm in the realm table (pktcMtaDevRealmTable). An entry in this table is not qualified for activation until the object instances of all corresponding columns have been initialized, either by default values, or via explicit SET operations. Until all object instances in this row are initialized, the status value for this realm must be 'notReady(3)'. In particular, two columnar objects must be explicitly SET: the realm name (pktcMtaDevRealmName) and the organization name (pktcMtaDevRealmOrgName). Once these 2 objects have been set and the row status is SET to 'active(1)', the MTA MUST NOT allow any modification of these 2 object values. The value of this object has no effect on whether other columnar objects in this row can be modified." ::= { pktcMtaDevRealmEntry 9 } --================================================================= -- -- The CMS table, pktcMtaDevCmsTable -- -- The CMS table and the realm table (pktcMtaDevRealmTable) are used -- for managing the MTA signaling security. The CMS table defines -- the CMSes the MTA is allowed to communicate with and contains -- the parameters describing the SA establishment between the MTA -- and a CMS. -- The CMS table is indexed by pktcMtaDevCmsIndex. The table -- contains the CMS FQDN (pktcMtaDevCmsFQDN) and the associated -- Kerberos realm name (pktcMtaDevCmsKerbRealmName) so that the MTA -- can find the corresponding Kerberos realm name in the -- pktcMtaDevRealmTable. -- --================================================================= pktcMtaDevCmsAvailSlot OBJECT-TYPE SYNTAX Unsigned32 (0..128) MAX-ACCESS read-only STATUS current DESCRIPTION Nechamkin & Mule Standards Track [Page 38] RFC 4682 IPCDN MTA MIB December 2006 " This object contains the index number of the first available entry in the CMS table (pktcMtaDevCmsTable). If all the entries in the CMS table have been assigned, this object contains the value of zero. A management station should create new entries in the CMS table, using the following procedure: First, issue a management protocol retrieval operation to determine the value of the first available index in the CMS table (pktcMtaDevCmsAvailSlot). Second, issue a management protocol SET operation to create an instance of the pktcMtaDevCmsStatus object by setting its value to 'createAndWait(5)'. Third, if the SET operation succeeded, continue modifying the object instances corresponding to the newly created conceptual row, without fear of collision with other management stations. When all necessary conceptual columns of the row are properly populated (via SET operations or default values), the management station may SET the pktcMtaDevCmsStatus object to 'active(1)'." ::= { pktcMtaDevSecurity 7 } pktcMtaDevCmsTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcMtaDevCmsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object defines the CMS table. The CMS table (pktcMtaDevCmsTable) and the realm table (pktcMtaDevRealmTable) are used for managing security between the MTA and CMSes. Each CMS table entry defines a CMS the managed MTA is allowed to communicate with and contains security parameters for key management with that CMS." ::= { pktcMtaDevSecurity 8 } pktcMtaDevCmsEntry OBJECT-TYPE SYNTAX PktcMtaDevCmsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table entry object lists the MTA key management parameters used when establishing Security Associations with a CMS. The conceptual rows MUST NOT persist across MTA reboots." INDEX { pktcMtaDevCmsIndex } Nechamkin & Mule Standards Track [Page 39] RFC 4682 IPCDN MTA MIB December 2006 ::= { pktcMtaDevCmsTable 1 } PktcMtaDevCmsEntry ::= SEQUENCE { pktcMtaDevCmsIndex Unsigned32, pktcMtaDevCmsFqdn SnmpAdminString, pktcMtaDevCmsKerbRealmName SnmpAdminString, pktcMtaDevCmsMaxClockSkew Unsigned32, pktcMtaDevCmsSolicitedKeyTimeout Unsigned32, pktcMtaDevCmsUnsolicitedKeyMaxTimeout Unsigned32, pktcMtaDevCmsUnsolicitedKeyNomTimeout Unsigned32, pktcMtaDevCmsUnsolicitedKeyMaxRetries Unsigned32, pktcMtaDevCmsIpsecCtrl TruthValue, pktcMtaDevCmsStatus RowStatus } pktcMtaDevCmsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..128) MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object defines the CMS table index." ::= { pktcMtaDevCmsEntry 1 } pktcMtaDevCmsFqdn OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object specifies the CMS FQDN. The MTA must prohibit the instantiation of any two rows with identical FQDNs. The MTA must also verify that any search and/or comparison operation involving a CMS FQDN is case insensitive. The MTA must resolve the CMS FQDN as required by the corresponding PacketCable Specifications." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification; PacketCable Network-Based Call Signaling Protocol Specification." ::= { pktcMtaDevCmsEntry 2 } pktcMtaDevCmsKerbRealmName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object identifies the Kerberos realm name in uppercase characters associated with the CMS defined in this Nechamkin & Mule Standards Track [Page 40] RFC 4682 IPCDN MTA MIB December 2006 conceptual row. The object value is a reference point to the corresponding Kerberos realm name in the realm table (pktcMtaDevRealmTable)." ::= { pktcMtaDevCmsEntry 3 } pktcMtaDevCmsMaxClockSkew OBJECT-TYPE SYNTAX Unsigned32 (1..1800) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object specifies the maximum allowable clock skew between the MTA and the CMS defined in this row." DEFVAL { 300 } ::= { pktcMtaDevCmsEntry 4 } pktcMtaDevCmsSolicitedKeyTimeout OBJECT-TYPE SYNTAX Unsigned32 (100..30000) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object defines a Kerberos Key Management timer on the MTA. It is the time period during which the MTA saves the nonce and Server Kerberos Principal Identifier to match an AP Request and its associated AP Reply response from the CMS. This timer only applies when the CMS initiated key management (with a Wake Up message or a Rekey message)." REFERENCE " PacketCable Security Specification." DEFVAL { 1000 } ::= { pktcMtaDevCmsEntry 5 } --================================================================= -- -- Unsolicited key updates are retransmitted according to an -- exponential back-off mechanism using two timers and a maximum -- retry counter for AS replies. -- The initial retransmission timer value is the nominal timer -- value (pktcMtaDevCmsUnsolicitedKeyNomTimeout). The -- retransmissions occur with an exponentially increasing interval -- that caps at the maximum timeout value -- (pktcMtaDevCmsUnsolicitedKeyMaxTimeout). -- Retransmissions stop when the maximum retry counter is reached -- (pktcMatDevCmsUnsolicitedMaxRetries). -- For example, with values of 3 seconds for the nominal -- timer, 20 seconds for the maximum timeout, and 5 retries max, -- retransmission intervals will be 3 s, 6 s, 12 s, Nechamkin & Mule Standards Track [Page 41] RFC 4682 IPCDN MTA MIB December 2006 -- 20 s, and 20 s; retransmissions then stop due to the -- maximum number of retries reached. -- --================================================================= pktcMtaDevCmsUnsolicitedKeyMaxTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..600) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object defines the timeout value that only applies to an MTA-initiated key management exchange. It is the maximum timeout, and it may not be exceeded in the exponential back-off algorithm." REFERENCE " PacketCable Security Specification." DEFVAL { 600 } ::= { pktcMtaDevCmsEntry 6 } pktcMtaDevCmsUnsolicitedKeyNomTimeout OBJECT-TYPE SYNTAX Unsigned32 (100..30000) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object defines the starting value of the timeout for an MTA-initiated key management. It should account for the average roundtrip time between the MTA and the CMS and the processing time on the CMS." REFERENCE " PacketCable Security Specification." DEFVAL { 500 } ::= { pktcMtaDevCmsEntry 7 } pktcMtaDevCmsUnsolicitedKeyMaxRetries OBJECT-TYPE SYNTAX Unsigned32 (0..1024) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the maximum number of retries before the MTA stops attempting to establish a Security Association with the CMS." REFERENCE " PacketCable Security Specification." DEFVAL { 5 } ::= { pktcMtaDevCmsEntry 8 } Nechamkin & Mule Standards Track [Page 42] RFC 4682 IPCDN MTA MIB December 2006 pktcMtaDevCmsIpsecCtrl OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION " This object specifies the MTA IPSec control flag. If the object value is 'true', the MTA must use Kerberos Key Management and IPsec to communicate with this CMS. If it is 'false', IPSec Signaling Security and Kerberos key management are disabled for this specific CMS." DEFVAL { true } ::= { pktcMtaDevCmsEntry 9 } pktcMtaDevCmsStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION " This object defines the row status associated with this particular CMS in the CMS table (pktcMtaDevCmsTable). An entry in this table is not qualified for activation until the object instances of all corresponding columns have been initialized, either by default values or via explicit SET operations. Until all object instances in this row are initialized, the status value for this realm must be 'notReady(3)'. In particular, two columnar objects must be SET: the CMS FQDN (pktcMtaDevCmsFqdn) and the Kerberos realm name (pktcMtaDevCmsKerbRealmName). Once these 2 objects have been set and the row status is SET to 'active(1)', the MTA MUST NOT allow any modification of these 2 object values. The value of this object has no effect on whether other columnar objects in this row can be modified." ::= { pktcMtaDevCmsEntry 10 } pktcMtaDevResetKrbTickets OBJECT-TYPE SYNTAX BITS { invalidateProvOnReboot (0), invalidateAllCmsOnReboot (1) } MAX-ACCESS read-write STATUS current DESCRIPTION " This object defines a Kerberos Ticket Control Mask that instructs the MTA to invalidate the specific Application Nechamkin & Mule Standards Track [Page 43] RFC 4682 IPCDN MTA MIB December 2006 Server Kerberos ticket(s) that are stored locally in the MTA NVRAM (non-volatile or persistent memory). If the MTA does not store Kerberos tickets in NVRAM, it MUST ignore setting of this object and MUST report a BITS value of zero when the object is read. If the MTA supports Kerberos tickets storage in NVRAM, the object value is encoded as follows: - Setting the invalidateProvOnReboot bit (bit 0) to 1 means that the MTA MUST invalidate the Kerberos Application Ticket(s) for the Provisioning Application at the next MTA reboot if secure SNMP provisioning mode is used. In non-secure provisioning modes, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations with a bit 0 set to 1. - Setting the invalidateAllCmsOnReboot bit (bit 1) to 1 means that the MTA MUST invalidate the Kerberos Application Ticket(s) for all CMSes currently assigned to the MTA endpoints. If a value is written into an instance of pktcMtaDevResetKrbTickets, the agent MUST retain the supplied value across an MTA re-initialization or reboot." REFERENCE "PacketCable Security Specification." DEFVAL { { } } ::= { pktcMtaDevSecurity 9 } -- -- The following group, pktcMtaDevErrors, defines an OID -- corresponding to error conditions encountered during the MTA -- provisioning. -- pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY STATUS current DESCRIPTION "This object defines the OID corresponding to the error condition when too many errors are encountered in the MTA configuration file during provisioning." ::= { pktcMtaDevErrors 1 } pktcMtaDevProvisioningEnrollment NOTIFICATION-TYPE OBJECTS { sysDescr, pktcMtaDevSwCurrentVers, pktcMtaDevTypeIdentifier, ifPhysAddress, pktcMtaDevCorrelationId Nechamkin & Mule Standards Track [Page 44] RFC 4682 IPCDN MTA MIB December 2006 } STATUS current DESCRIPTION " This INFORM notification is issued by the MTA to initiate the PacketCable provisioning process when the MTA SNMP enrollment mechanism is used. It contains the system description, the current software version, the MTA device type identifier, the MTA MAC address (obtained in the MTA ifTable in the ifPhysAddress object that corresponds to the ifIndex 1), and a correlation ID." ::= { pktcMtaNotification 1 } pktcMtaDevProvisioningStatus NOTIFICATION-TYPE OBJECTS { ifPhysAddress, pktcMtaDevCorrelationId, pktcMtaDevProvisioningState } STATUS current DESCRIPTION " This INFORM notification may be issued by the MTA to confirm the completion of the PacketCable provisioning process, and to report its provisioning completion status. It contains the MTA MAC address (obtained in the MTA ifTable in the ifPhysAddress object that corresponds to the ifIndex 1), a correlation ID and the MTA provisioning state as defined in pktcMtaDevProvisioningState." ::= { pktcMtaNotification 2 } -- -- Compliance Statements -- pktcMtaCompliances OBJECT IDENTIFIER ::= { pktcMtaConformance 1 } pktcMtaGroups OBJECT IDENTIFIER ::= { pktcMtaConformance 2 } pktcMtaBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION " The compliance statement for MTA devices that implement PacketCable or IPCablecom requirements. This compliance statement applies to MTA implementations that support PacketCable 1.0 or IPCablecom requirements, which are not IPv6-capable at the time of this Nechamkin & Mule Standards Track [Page 45] RFC 4682 IPCDN MTA MIB December 2006 RFC publication." MODULE -- Unconditionally mandatory groups for MTAs MANDATORY-GROUPS { pktcMtaGroup, pktcMtaNotificationGroup } OBJECT pktcMtaDevDhcpServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore is not required. It may be defined in future versions of this MIB module." OBJECT pktcMtaDevDnsServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore is not required. It may be defined in future versions of this MIB module." OBJECT pktcMtaDevTimeServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore is not required. It may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDhcp1 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDhcp2 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDns1 Nechamkin & Mule Standards Track [Page 46] RFC 4682 IPCDN MTA MIB December 2006 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDns2 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevTimeServer SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevProvConfigEncryptAlg SYNTAX PktcMtaDevProvEncryptAlg DESCRIPTION "An implementation is only required to support values of none(0) and des64Cbcmode(1). An IV of zero is used to encrypt in des64Cbcmode, and the length of pktcMtaDevProvConfigKey is 64 bits, as defined in the PacketCable Security specification. Other encryption types may be defined in future versions of this MIB module." OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION "The Organization Name field in X.509 certificates can contain up to 64 UTF-8 encoded characters, as defined in RFCs 3280 and 4630. Therefore, compliant devices are only required to support Organization Name values of up to 64 UTF-8 encoded characters. Given that RFCs 3280 and 4630 define the UTF-8 encoding, compliant devices must support a maximum size of 384 octets for pktcMtaDevRealmOrgName. The calculation of 384 octets comes from the RFC 3629 UTF-8 encoding definition whereby the UTF-8 encoded characters are encoded as sequences of 1 to 6 octets, assuming that code points as high as 0x7ffffffff might be used. Subsequent versions of Unicode and ISO 10646 have limited the upper bound to 0x10ffff. Nechamkin & Mule Standards Track [Page 47] RFC 4682 IPCDN MTA MIB December 2006 Consequently, the current version of UTF-8, defined in RFC 3629, does not require more than four octets to encode a valid code point." ::= { pktcMtaCompliances 1 } pktcMtaGroup OBJECT-GROUP OBJECTS { pktcMtaDevResetNow, pktcMtaDevSerialNumber, pktcMtaDevSwCurrentVers, pktcMtaDevFQDN, pktcMtaDevEndPntCount, pktcMtaDevEnabled, pktcMtaDevProvisioningCounter, pktcMtaDevErrorOid, pktcMtaDevErrorValue, pktcMtaDevErrorReason, pktcMtaDevTypeIdentifier, pktcMtaDevProvisioningState, pktcMtaDevHttpAccess, pktcMtaDevCertificate, pktcMtaDevCorrelationId, pktcMtaDevManufacturerCertificate, pktcMtaDevDhcpServerAddressType, pktcMtaDevDnsServerAddressType, pktcMtaDevTimeServerAddressType, pktcMtaDevProvConfigEncryptAlg, pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2, pktcMtaDevServerDns1, pktcMtaDevServerDns2, pktcMtaDevTimeServer, pktcMtaDevConfigFile, pktcMtaDevSnmpEntity, pktcMtaDevRealmPkinitGracePeriod, pktcMtaDevRealmTgsGracePeriod, pktcMtaDevRealmAvailSlot, pktcMtaDevRealmName, pktcMtaDevRealmOrgName, pktcMtaDevRealmUnsolicitedKeyMaxTimeout, pktcMtaDevRealmUnsolicitedKeyNomTimeout, pktcMtaDevRealmUnsolicitedKeyMaxRetries, pktcMtaDevRealmStatus, pktcMtaDevCmsAvailSlot, pktcMtaDevCmsFqdn, pktcMtaDevCmsKerbRealmName, pktcMtaDevCmsUnsolicitedKeyMaxTimeout, Nechamkin & Mule Standards Track [Page 48] RFC 4682 IPCDN MTA MIB December 2006 pktcMtaDevCmsUnsolicitedKeyNomTimeout, pktcMtaDevCmsUnsolicitedKeyMaxRetries, pktcMtaDevCmsSolicitedKeyTimeout, pktcMtaDevCmsMaxClockSkew, pktcMtaDevCmsIpsecCtrl, pktcMtaDevCmsStatus, pktcMtaDevResetKrbTickets, pktcMtaDevProvUnsolicitedKeyMaxTimeout, pktcMtaDevProvUnsolicitedKeyNomTimeout, pktcMtaDevProvUnsolicitedKeyMaxRetries, pktcMtaDevProvKerbRealmName, pktcMtaDevProvSolicitedKeyTimeout, pktcMtaDevProvConfigHash, pktcMtaDevProvConfigKey, pktcMtaDevProvState, pktcMtaDevProvisioningTimer, pktcMtaDevTelephonyRootCertificate } STATUS current DESCRIPTION " A collection of objects for managing PacketCable or IPCablecom MTA implementations." ::= { pktcMtaGroups 1 } pktcMtaNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pktcMtaDevProvisioningStatus, pktcMtaDevProvisioningEnrollment } STATUS current DESCRIPTION " A collection of notifications dealing with the change of MTA provisioning status." ::= { pktcMtaGroups 2 } pktcMtaBasicSmtaCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION " The compliance statement for S-MTA devices that implement PacketCable or IPCablecom requirements. This compliance statement applies to S-MTA implementations that support PacketCable or IPCablecom requirements, which are not IPv6-capable at the time of this RFC publication." MODULE -- Unconditionally Mandatory Groups for S-MTA devices MANDATORY-GROUPS { Nechamkin & Mule Standards Track [Page 49] RFC 4682 IPCDN MTA MIB December 2006 pktcMtaGroup, pktcMtaNotificationGroup } OBJECT pktcMtaDevDhcpServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore is not required. It may be defined in future versions of this MIB module." OBJECT pktcMtaDevDnsServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore is not required. It may be defined in future versions of this MIB module." OBJECT pktcMtaDevTimeServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore is not required. It may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDhcp1 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDhcp2 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevServerDns1 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." Nechamkin & Mule Standards Track [Page 50] RFC 4682 IPCDN MTA MIB December 2006 OBJECT pktcMtaDevServerDns2 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevTimeServer SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses. Other address types support may be defined in future versions of this MIB module." OBJECT pktcMtaDevProvConfigEncryptAlg SYNTAX PktcMtaDevProvEncryptAlg DESCRIPTION "An implementation is only required to support values of none(0) and des64Cbcmode(1). An IV of zero is used to encrypt in des64Cbcmode, and the length of pktcMtaDevProvConfigKey is 64 bits, as defined in the PacketCable Security specification. Other encryption types may be defined in future versions of this MIB module." OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION "The Organization Name field in X.509 certificates can contain up to 64 UTF-8 encoded characters, as defined in RFCs 3280 and 4630. Therefore, compliant devices are only required to support Organization Name values of up to 64 UTF-8 encoded characters. Given that RFCs 3280 and 4630 define the UTF-8 encoding, compliant devices must support a maximum size of 384 octets for pktcMtaDevRealmOrgName. The calculation of 384 octets comes from the RFC 3629 UTF-8 encoding definition whereby the UTF-8 encoded characters are encoded as sequences of 1 to 6 octets, assuming that code points as high as 0x7ffffffff might be used. Subsequent versions of Unicode and ISO 10646 have limited the upper bound to 0x10ffff. Consequently, the current version of UTF-8, defined in RFC 3629 does not require more than four octets to encode a valid code point." MODULE DOCS-CABLE-DEVICE-MIB MANDATORY-GROUPS { Nechamkin & Mule Standards Track [Page 51] RFC 4682 IPCDN MTA MIB December 2006 docsDevSoftwareGroupV2 } MODULE DOCS-IETF-BPI2-MIB MANDATORY-GROUPS { docsBpi2CodeDownloadGroup } ::= { pktcMtaCompliances 2 } END 5. Acknowledgements The current editors would like to thank the members of the IETF IPCDN working group and the CableLabs PacketCable Provisioning and OSS focus team for their comments and suggestions. In particular, we wish to express our gratitude for the contributions made by the following individuals (in no particular order): Angela Lyda,Sumanth Channabasappa, Matt A. Osman, Klaus Hermanns, Paul Duffy, Rick Vetter, Sasha Medvinsky, Roy Spitzer, Itay Sherman, Satish Kumar and Eric Rosenfeld. Finally, special thanks to our area director Bert Wijnen, Rich Woundy, Randy Presuhn, Mike Heard, and Dave Thaler. 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Improper manipulation of the objects defined in this MIB may result in random behavior of MTA devices and may result in service disruption. These are the tables and objects and their sensitivity/vulnerability: - The following objects, if SET maliciously, would cause the MTA device to reset and/or stop its service: pktcMtaDevResetNow. pktcMtaDevEnabled. - All writable objects in the pktcMtaDevServer group and some in the pktcMtaDevRealmTable share the potential, if SET maliciously, to prevent the MTA from provisioning properly. Thus, they are considered very sensitive for service delivery. The objects in question are: Nechamkin & Mule Standards Track [Page 52] RFC 4682 IPCDN MTA MIB December 2006 pktcMtaDevProvisioningTimer, pktcMtaDevDhcpServerAddressType, pktcMtaDevDnsServerAddressType, pktcMtaDevTimeServerAddressType, pktcMtaDevProvConfigEncryptAlg, pktcMtaDevServerDns1, pktcMtaDevServerDns2, pktcMtaDevTimeServer, pktcMtaDevConfigFile, pktcMtaDevProvConfigHash, pktcMtaDevProvConfigKey, pktcMtaDevProvSolicitedKeyTimeout, pktcMtaDevRealmName, pktcMtaDevRealmOrgName, pktcMtaDevRealmUnsolicitedKeyMaxTimeout, pktcMtaDevRealmUnsolicitedKeyNomTimeout, pktcMtaDevRealmUnsolicitedKeyMaxRetries, and pktcMtaDevRealmStatus. Certain of the above objects have additional specific vulnerabilities: o pktcMtaDevServerDns1 and pktcMtaDevServerDns2, if SET maliciously, could prevent the MTA from being authenticated and consequently from getting telephony services. o pktcMtaDevRealmStatus, if SET maliciously, could cause the whole row of the table to be deleted, which may prevent MTA from getting telephony services. - All writable objects in the pktcMtaDevCmsTable table share the potential, if SET maliciously, to disrupt the telephony service by altering which Call Management Server the MTA must send signaling registration to; in particular: pktcMtaDevCmsFqdn, pktcMtaDevCmsKerbRealmName, pktcMtaDevCmsMaxClockSkew, pktcMtaDevCmsSolicitedKeyTimeout, pktcMtaDevCmsUnsolicitedKeyMaxTimeout, pktcMtaDevCmsUnsolicitedKeyNomTimeout, pktcMtaDevCmsUnsolicitedKeyMaxRetries (this object, if set to a zero value '0', may prevent the MTA from retrying its attempt to establish a Security Association with the CMS), and pktcMtaDevCmsStatus. Nechamkin & Mule Standards Track [Page 53] RFC 4682 IPCDN MTA MIB December 2006 - Some writable objects in the pktcMtaDevRealmTable table will not have an immediate effect on service, if SET maliciously. However, they may impact the service performance and cause avalanche attacks on provisioning and Kerberos KDC servers, especially after massive device reboots occur. The objects in question are as follows: pktcMtaDevResetKrbTickets: This object, if set to 'true', will cause the MTA to request a new Kerberos ticket at reboot. pktcMtaDevRealmPkinitGracePeriod, pktcMtaDevRealmTgsGracePeriod: These 2 objects, if set to short time periods, will cause the MTA to renew its tickets more frequently. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. Some of these objects may contain information that may be sensitive from a business or customer perspective. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity and vulnerability: - Some readable objects in the pktcMtaDevBase, pktcMtaDevServer, and pktcMtaDevSecurity groups share the potential, if read maliciously, to facilitate Denial-of-Service (DoS) attacks against provisioning or Kerberos servers. The object in question are as follows: pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2, and pktcMtaDevSnmpEntity. The values of these objects may be used to launch DoS attacks on the Telephony Service Provider DHCP or Provisioning servers. pktcMtaDevProvKerbRealmName, pktcMtaDevManufacturerCertificate, pktcMtaDevCertificate and pktcMtaDevTelephonyRootCertificate. The values of these objects may be used by attackers to launch DoS attacks against Kerberos servers. - One additional readable object may expose some security threats: pktcMtaDevFQDN. This object may include sensitive information about the domain name, and potentially, the domain topology. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is Nechamkin & Mule Standards Track [Page 54] RFC 4682 IPCDN MTA MIB December 2006 allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see Section 8 in [RFC3410]), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pktcIetfMtaMib { mib-2 140 } 8. Normative References [RFC868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983. [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. Nechamkin & Mule Standards Track [Page 55] RFC 4682 IPCDN MTA MIB December 2006 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder J., Case, J. Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J. Case, J. Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration", RFC 3495, March 2003. [RFC3594] Duffy, P., "PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option", RFC 3594, September 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. Nechamkin & Mule Standards Track [Page 56] RFC 4682 IPCDN MTA MIB December 2006 [RFC4131] Green, S., Ozawa, K., Cardona, E., and A. Katsnelson, "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus", RFC 4131, September 2005. [RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4630, August 2006. [RFC4639] Woundy, R. and K. Marez, "Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems", RFC 4639, December 2006. [PKT-SP-PROV] Packetcable MTA Device Provisioning Specification, Issued, PKT-SP-PROV-I11-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/ [PKT-SP-SEC] PacketCable Security Specification, Issued, PKT-SP- SEC-I12-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/ [ITU-T-J112] Transmission Systems for Interactive Cable Television Services, Annex B, J.112, ITU-T, March, 1998. [ITU-T-J168] IPCablecom Multimedia Terminal Adapter (MTA) MIB requirements, J.168, ITU-T, March, 2001. 9. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003. Nechamkin & Mule Standards Track [Page 57] RFC 4682 IPCDN MTA MIB December 2006 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [PKT-SP-MIB-MTA] Packetcable MTA MIB Specification, Issued, PKT-SP- MIB-MTA-I10-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/ [ETSITS101909-8] ETSI TS 101 909-8: "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 8: Media Terminal Adaptor (MTA) Management Information Base (MIB)". [EN300001] EN 300 001 V1.5.1 (1998-10):"European Standard (Telecommunications series) Attachments to Public Switched Telephone Network (PSTN); General technical requirements for equipment connected to an analogue subscriber interface in the PSTN". [EN300659-1] EN 300 659-1: "Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 1: On hook data transmission". [NCSSIGMIB] Beacham G., Kumar S., Channabasappa S., "Network Control Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)", Work in Progress, June 2006. Nechamkin & Mule Standards Track [Page 58] RFC 4682 IPCDN MTA MIB December 2006 Authors' Addresses Eugene Nechamkin Broadcom Corporation, 200 - 13711 International Place Richmond, BC, V6V 2Z8 CANADA Phone: +1 604 233 8500 EMail: enechamkin@broadcom.com Jean-Francois Mule Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, Colorado 80027-9750 U.S.A. Phone: +1 303 661 9100 EMail: jf.mule@cablelabs.com Nechamkin & Mule Standards Track [Page 59] RFC 4682 IPCDN MTA MIB December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nechamkin & Mule Standards Track [Page 60] snmp-mibs-downloader-1.1/mibrfcs/rfc4706.txt0000644000000000000000000124700011402176072015567 0ustar Network Working Group M. Morgenstern Request for Comments: 4706 M. Dodge Category: Standards Track ECI Telecom Ltd. S. Baillie U. Bonollo NEC Australia November 2006 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Asymmetric Digital Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their variants. Morgenstern, et al. Standards Track [Page 1] RFC 4706 ADSL2-LINE MIB November 2006 Table of Contents 1. The Internet-Standard Management Framework ......................3 2. Overview ........................................................3 2.1. Relationship to Other MIBs .................................4 2.1.1. General IF-MIB Integration (RFC 2863) ...............4 2.1.2. Usage of ifTable ....................................5 2.2. IANA Considerations ........................................6 2.3. Conventions Used in the MIB Module .........................6 2.3.1. Naming Conventions ..................................6 2.3.2. Textual Conventions .................................7 2.4. Structure .................................................12 2.5. Persistence ...............................................15 2.6. Line Topology .............................................17 2.7. Counters, Interval Buckets, and Thresholds ................18 2.7.1. Counters Managed ...................................18 2.7.2. Minimum Number of Buckets ..........................19 2.7.3. Interval Buckets Initialization ....................19 2.7.4. Interval Buckets Validity ..........................19 2.8. Profiles ..................................................20 2.8.1. Configuration Profiles and Templates ...............21 2.8.2. Alarm Configuration Profiles and Templates .........22 2.8.3. Managing Profiles and Templates ....................22 2.8.4. Managing Multiple Bearer Channels ..................23 2.9. Notifications .............................................24 3. Definitions ....................................................25 4. Implementation Analysis .......................................155 5. Security Considerations .......................................155 6. Acknowledgements ..............................................163 7. References ....................................................163 7.1. Normative References .....................................163 7.2. Informative References ...................................165 Morgenstern, et al. Standards Track [Page 2] RFC 4706 ADSL2-LINE MIB November 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing ADSL, ADSL2, and ADSL2+ lines. The MIB module described in RFC 2662 [RFC2662] describes objects used for managing Asymmetric Bit-Rate DSL (ADSL) interfaces per [T1E1.413], [G.992.1], and [G.992.2]. These object descriptions are based upon the specifications for the ADSL Embedded Operations Channel (EOC) as defined in American National Standards Institute (ANSI) T1E1.413/1995 [T1E1.413] and International Telecommunication Union (ITU-T) G.992.1 [G.992.1] and G.992.2 [G.992.2]. This document does not obsolete RFC 2662 [RFC2662], but rather provides a more comprehensive management model that includes the ADSL2 and ADSL2+ technologies per G.992.3, G.992.4, and G.992.5 ([G.992.3], [G.992.4], and [G.992.5] respectively). In addition, objects have been added to improve the management of ADSL, ADSL2, and ADSL2+ lines. Additionally, the management framework for New Generation ADSL lines specified [TR-90] by the Digital Subscriber Line Forum (DSLF) has been taken into consideration. That framework is based on ITU-T G.997.1 standard [G.997.1] as well as on two amendments: ([G.997.1am1] and [G.997.1am2]). This document refers to all three documents as G.997.1. That is, a MIB attribute whose REFERENCE section provides a paragraph number in ITU-T G.997.1 is actually originated from either G.997.1 [G.997.1] or one of its amendment documents. Morgenstern, et al. Standards Track [Page 3] RFC 4706 ADSL2-LINE MIB November 2006 Note that the revised ITU-T G.997.1 standard also refers to the next generation of VDSL technology, known as VDSL2, as per ITU-T G.993.2 [G.993.2]. However, managing VDSL2 lines is currently beyond the scope of this document. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the IANA Considerations section of this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.1. Relationship to Other MIBs This section outlines the relationship of this MIB module with other MIB modules described in RFCs. Specifically, IF-MIB as presented in RFC 2863 [RFC2863] is discussed. 2.1.1. General IF-MIB Integration (RFC 2863) The ADSL2 Line MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with RFC 2863 [RFC2863]. The IANA has assigned the following ifTypes, which may be applicable for ADSL lines: IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... channel(70), -- Channel adsl(94), -- Asymmetric Digital Subscriber Loop ... interleave(124), -- Interleaved Channel fast(125), -- Fast Channel ... adsl2plus(238), -- Asymmetric Digital Subscriber Loop Version 2, Version 2 Plus, and all variants ... } ADSL lines that are identified with ifType=adsl(94) MUST be managed with the MIB specified by RFC 2662. ADSL, ADSL2, and ADSL2+ lines identified with ifType=adsl2plus(238) MUST be managed with the MIB specified by this document. Morgenstern, et al. Standards Track [Page 4] RFC 4706 ADSL2-LINE MIB November 2006 In any case, the SNMP agent may use either ifType=interleave(124) or fast(125) for each channel, e.g., depending on whether or not it is capable of using an interleaver on that channel. It may use the ifType=channel(70) when all channels are capable of using an interleaver (e.g., for ADSL2 XTUs). Note that the ifFixedLengthGroup from RFC 2863 [RFC2863] MUST be supported and that the ifRcvAddressGroup does not apply to this MIB module. 2.1.2. Usage of ifTable The MIB branch identified by ifType contains tables appropriate for the interface types described above. Most such tables extend the ifEntry table and are indexed by ifIndex. For interfaces in systems implementing this MIB module, those table entries indexed by ifIndex MUST be persistent. The following attributes are part of the mandatory ifGeneralInformationGroup in the Interfaces MIB [RFC2863] and are not duplicated in the ADSL2 Line MIB. =================================================================== ifIndex Interface index. ifDescr See interfaces MIB. ifType adsl2plus(238) or channel(70) or interleave(124) or fast(125). ifSpeed Set as appropriate. ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB. ifOperStatus See interfaces MIB. ifLastChange See interfaces MIB. ifName See interfaces MIB. ifAlias See interfaces MIB. Morgenstern, et al. Standards Track [Page 5] RFC 4706 ADSL2-LINE MIB November 2006 ifLinkUpDownTrapEnable Default to enabled(1). ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. =================================================================== Figure 1: Use of ifTable Objects 2.2. IANA Considerations The IANA has allocated ifType=adsl2plus(238) for Asymmetric Digital Subscriber Loop Version 2. A separate ifType number was necessary to distinguish between ADSL lines that are managed with the RFC 2662 management model and ADSL/ADSL2 and ADSL2+ lines managed with the model defined in this document. Also, the IANA has assigned transmission number 238 to the ADSL2-LINE-MIB module. An assignment was in fact done when RFC 2662 was published, but as this MIB does not obsolete RFC 2662, it required a new assignment from IANA. 2.3. Conventions Used in the MIB Module 2.3.1. Naming Conventions ATU ADSL Transceiver Unit ATU-C ATU at the Central office end (i.e., network operator). ATU-R ATU at the Remote end (i.e., subscriber end of the loop). XTU A terminal unit; either an ATU-C or an ATU-R. CRC Cyclic Redundancy Check DELT Dual Ended Loop Test ES Errored Second FEC Forward Error Correction LOF Loss Of Frame LOS Loss Of Signal LOSS LOS Seconds SES Severely-Errored Second SNR Signal-to-Noise Ratio UAS Unavailable Seconds Morgenstern, et al. Standards Track [Page 6] RFC 4706 ADSL2-LINE MIB November 2006 2.3.2. Textual Conventions The following textual conventions are defined to reflect the line topology in the MIB module (further discussed in the following section), the various transmission modes, power states, synchronization states, possible values for various configuration parameters, status parameters, and other parameter types. o Adsl2Unit: Attributes with this syntax uniquely identify each unit in the ADSL/ADSL2/ADSL2+ link. It mirrors the EOC addressing mechanism: atuc(1) - Central office ADSL transceiver unit (ATU-C). atur(2) - Remote ADSL transceiver unit (ATU-R). o Adsl2Direction: Attributes with this syntax uniquely identify a transmission direction in an ADSL/ADSL2/ADSL2+ link. Upstream direction is a transmission from the remote end (ATU-R) towards the central office end (ATU-C), while downstream direction is a transmission from the ATU-C towards the ATU-R. upstream(1) - Transmission from the ATU-R to the ATU-C. downstream(2) - Transmission from the ATU-C to the ATU-R. o Adsl2TransmissionModeType: Attributes with this syntax reference the list of possible transmission modes for ADSL/ADSL2 or ADSL2+. Specified as a BITS construct, there are currently a few dozen transmission modes in the list. o Adsl2RaMode: Attributes with this syntax reference if and how Rate-Adaptive synchronization is being used on the respective ADSL/ADSL2 or ADSL2+ link: manual(1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit(2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values. Morgenstern, et al. Standards Track [Page 7] RFC 4706 ADSL2-LINE MIB November 2006 dynamicRa(3) - Dynamic Rate-Adaptation during initialization process as well as during SHOWTIME. o Adsl2InitResult: Attributes with this syntax reference the recent result of a full initialization attempt: noFail(0) - Successful initialization. configError(1) - Configuration failure. configNotFeasible(2) - Configuration details not supported. commFail(3) - Communication failure. noPeerAtu(4) - Peer ADSL Transceiver Unit (ATU) not detected. otherCause(5) - Other initialization failure reason. o Adsl2OperationModes: Attributes with this syntax uniquely identify an ADSL mode, which is a category associated with each transmission mode defined for the ADSL/ADSL2 or ADSL2+ link. Part of the line configuration profile depends on the ADSL Mode: Specified as an enumeration construct, there are currently a few dozen transmission modes in the list. o Adsl2PowerMngState: Attributes with this syntax uniquely identify each power management state defined for the ADSL/ADSL2 or ADSL2+ link: l0(1) - L0 - Full power management state. l1(2) - L1 - Low power management state (for G.992.2). l2(3) - L2 - Low power management state (for G.992.3, G.992.4, and G.992.5). l3(4) - L3 - Idle power management state. o Adsl2ConfPmsForce: Attributes with this syntax are configuration parameters that reference the desired power management state for the ADSL/ADSL2 or ADSL2+ link: l3toL0(0) - Perform a transition from L3 to L0 (Full power management state). l0toL2(2) - Perform a transition from L0 to L2 (Low power management state). Morgenstern, et al. Standards Track [Page 8] RFC 4706 ADSL2-LINE MIB November 2006 l0orL2toL3(3) - Perform a transition into L3 (Idle power management state). o Adsl2LConfProfPmMode: Attributes with this syntax are configuration parameters that reference the power modes/states into which the ATU-C or ATU-R may autonomously transit. This is a BITS structure that allows control of the following transit options: allowTransitionsToIdle(0) - XTU may autonomously transit to idle (L3) state. allowTransitionsToLowPower(1) - XTU may autonomously transit to low-power (L2) state. o Adsl2LineLdsf: Attributes with this syntax are configuration parameters that control the Loop Diagnostic mode for the ADSL/ADSL2 or ADSL2+ link: inhibit(0) - Inhibit Loop Diagnostic mode. force(1) - Force/Initiate Loop Diagnostic mode. o Adsl2LdsfResult: Attributes with this syntax are status parameters that report the result of the recent Loop Diagnostic mode issued for the ADSL/ADSL2 or ADSL2+ link: none(1) - The default value, in case loop diagnostics mode forced (LDSF) was never requested for the associated line. success(2) - The recent command completed successfully. inProgress(3) - The Loop Diagnostics process is in progress. unsupported(4) - The NE or the line card doesn't support LDSF. cannotRun(5) - The NE cannot initiate the command, due to a nonspecific reason. aborted(6) - The Loop Diagnostics process aborted. failed(7) - The Loop Diagnostics process failed. illegalMode(8) - The NE cannot initiate the command, due to the specific mode of the relevant line. Morgenstern, et al. Standards Track [Page 9] RFC 4706 ADSL2-LINE MIB November 2006 adminUp(9) - The NE cannot initiate the command because the relevant line is administratively 'Up'. tableFull(10) - The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources(11) - The NE cannot initiate the command, due to lack of internal memory resources. o Adsl2SymbolProtection: Attributes with this syntax are configuration parameters that reference the minimum-length impulse noise protection (INP) in terms of number of symbols: noProtection(1) - INP not required. halfSymbol(2) - INP length = 1/2 symbol. singleSymbol(3) - INP length = 1 symbol. twoSymbols(4) - INP length = 2 symbols. threeSymbols(5) - INP length = 3 symbols. fourSymbols(6) - INP length = 4 symbols. fiveSymbols(7) - INP length = 5 symbols. sixSymbols(8) - INP length = 6 symbols. sevenSymbols(9) - INP length = 7 symbols. eightSymbols(10) - INP length = 8 symbols. nineSymbols(11) - INP length = 9 symbols. tenSymbols(12) - INP length = 10 symbols. elevenSymbols(13) - INP length = 11 symbols. twelveSymbols(14) - INP length = 12 symbols. thirteeSymbols(15) - INP length = 13 symbols. fourteenSymbols(16) - INP length = 14 symbols. fifteenSymbols(17) - INP length = 15 symbols. sixteenSymbols(18) - INP length = 16 symbols. o Adsl2MaxBer: Attributes with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER): eminus3(1) - Maximum BER=E^-3. eminus5(2) - Maximum BER=E^-5. eminus7(3) - Maximum BER=E^-7. o Adsl2ScMaskDs: Attributes with this syntax are configuration parameters that reference the downstream sub-carrier mask. It is a bitmap of up to 512 bits. Morgenstern, et al. Standards Track [Page 10] RFC 4706 ADSL2-LINE MIB November 2006 o Adsl2ScMaskUs: Attributes with this syntax are configuration parameters that reference the upstream sub-carrier mask. It is a bitmap of up to 64 bits. o Adsl2RfiDs: Attributes with this syntax are configuration parameters that reference the downstream notch filters. It is a bitmap of up to 512 bits. o Adsl2PsdMaskDs: Attributes with this syntax are configuration parameters that reference the downstream power spectrum density (PSD) mask. It is a structure of up to 32 breakpoints, where each breakpoint occupies 3 octets. o Adsl2PsdMaskUs: Attributes with this syntax are configuration parameters that reference the upstream power spectrum density (PSD) mask. It is a structure of up to 4 breakpoints, where each breakpoint occupies 3 octets. o Adsl2Tssi: Attributes with this syntax are status parameters that reference the transmit spectrum shaping (TSSi). It is a structure of up to 32 breakpoints, where each breakpoint occupies 3 octets. o Adsl2LastTransmittedState: Attributes with this syntax reference the list of initialization states for ADSL/ADSL2 or ADSL2+ modems. The list of states for CO side modems (ATU-Cs) is different from the list of states for the remote side modems (ATU-Rs). Specified as an enumeration type, there are currently a few dozen states in the list per each unit side (i.e., ATU-C or ATU-R). o Adsl2LineStatus: Attributes with this syntax are status parameters that reflect the failure status for a given endpoint of ADSL/ADSL2 or ADSL2+ link. Morgenstern, et al. Standards Track [Page 11] RFC 4706 ADSL2-LINE MIB November 2006 This is a BITS structure that can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. lossOfFrame(1) - Loss of frame synchronization. lossOfSignal(2) - Loss of signal. lossOfPower(3) - Loss of power. Usually this failure may be reported for ATU-Rs only. initFailure(4) - Recent initialization process failed. Never active on ATU-R. o Adsl2ChAtmStatus: Attributes with this syntax are status parameters that reflect the failure status for Transmission Convergence (TC) layer of a given ATM interface (data path over an ADSL/ADSL2 or ADSL2+ link). This is a BITS structure that can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. noCellDelineation(1) - The link was successfully initialized but cell delineation was never acquired on the associated ATM data path. lossOfCellDelineation(2) - Loss of cell delineation on the associated ATM data path. o Adsl2ChPtmStatus: Attributes with this syntax are status parameters that reflect the failure status for a given PTM interface (packet data path over an ADSL/ADSL2 or ADSL2+ link). This is a BITS structure that can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. outOfSync(1) - Out of synchronization. 2.4. Structure The MIB module is structured into following MIB groups: o Line Configuration, Maintenance, and Status Group: This group supports MIB objects for configuring parameters for the ADSL/ADSL2 or ADSL2+ line and retrieving line status information. Morgenstern, et al. Standards Track [Page 12] RFC 4706 ADSL2-LINE MIB November 2006 It also supports MIB objects for configuring a requested power state or initiating a Dual Ended Loop Test (DELT) process in the ADSL/ADSL2 or ADSL2+ line. It contains the following table: - adsl2LineTable o Channel Status Group: This group supports MIB objects for retrieving channel layer status information. It contains the following table: - adsl2ChannelStatusTable o Subcarrier Status Group: This group supports MIB objects for retrieving the sub-carrier layer status information, mostly collected by a Dual Ended Loop Test (DELT) process. It contains the following table: - adsl2SCStatusTable o Unit Inventory Group: This group supports MIB objects for retrieving Unit inventory information about units in ADSL/ADSL2 or ADSL2+ lines via the EOC. It contains the following table: - adsl2LineInventoryTable o Current Performance Group: This group supports MIB objects that provide the current performance information relating to ADSL/ADSL2 and ADSL2+ line, units and channels level. It contains the following tables: - adsl2PMLineCurrTable - adsl2PMLineCurrInitTable - adsl2PMChCurrTable o 15-Minute Interval Performance Group: This group supports MIB objects that provide historic performance information relating to ADSL/ADSL2 and ADSL2+ line, units and channels level in 15-minute intervals. It contains the following tables: Morgenstern, et al. Standards Track [Page 13] RFC 4706 ADSL2-LINE MIB November 2006 - adsl2PMLineHist15MinTable - adsl2PMLineInitHist15MinTable - adsl2PMChHist15MinTable o 1-Day Interval Performance Group: This group supports MIB objects that provide historic performance information relating to ADSL/ADSL2 and ADSL2+ line, units and channels level in 1-day intervals. It contains the following tables: - adsl2PMLineHist1DayTable - adsl2PMLineInitHist1DayTable - adsl2PMChHist1DTable o Configuration Template and Profile Group: This group supports MIB objects for defining configuration profiles for ADSL/ADSL2 and ADSL2+ lines and channels, as well as configuration templates. Each configuration template is comprised of one line configuration profile and one or more channel configuration profiles. This group contains the following tables: - adsl2LineConfTemplateTable - adsl2LineConfProfTable - adsl2LineConfProfModeSpecTable - adsl2ChConfProfileTable o Alarm Configuration Template and Profile Group: This group supports MIB objects for defining alarm profiles for ADSL/ADSL2 and ADSL2+ lines and channels, as well as alarm templates. Each alarm template is comprised of one line alarm profile and one or more channel alarm profiles. This group contains the following tables: - adsl2LineAlarmConfTemplateTable - adsl2LineAlarmConfProfileTable - adsl2ChAlarmConfProfileTable o Notifications Group: This group defines the notifications supported for ADSL/ADSL2 and ADSL2+ lines: - adsl2LinePerfFECSThreshAtuc - adsl2LinePerfFECSThreshAtur - adsl2LinePerfESThreshAtuc Morgenstern, et al. Standards Track [Page 14] RFC 4706 ADSL2-LINE MIB November 2006 - adsl2LinePerfESThreshAtur - adsl2LinePerfSESThreshAtuc - adsl2LinePerfSESThreshAtur - adsl2LinePerfLOSSThreshAtuc - adsl2LinePerfLOSSThreshAtur - adsl2LinePerfUASThreshAtuc - adsl2LinePerfUASThreshAtur - adsl2LinePerfCodingViolationsThreshAtuc - adsl2LinePerfCodingViolationsThreshAtur - adsl2LinePerfCorrectedThreshAtuc - adsl2LinePerfCorrectedThreshAtur - adsl2LinePerfFailedFullInitThresh - adsl2LinePerfFailedShortInitThresh - adsl2LineStatusChangeAtuc - adsl2LineStatusChangeAtur 2.5. Persistence All read-create objects and most read-write objects defined in this MIB module SHOULD be stored persistently. Following is an exhaustive list of these persistent objects: adsl2LineCnfgTemplate adsl2LineAlarmCnfgTemplate adsl2LineCmndConfPmsf adsl2LineCmndConfLdsf adsl2LineCmndAutomodeColdStart adsl2LConfTempTemplateName adsl2LConfTempLineProfile adsl2LConfTempChan1ConfProfile adsl2LConfTempChan1RaRatioDs adsl2LConfTempChan1RaRatioUs adsl2LConfTempChan2ConfProfile adsl2LConfTempChan2RaRatioDs adsl2LConfTempChan2RaRatioUs adsl2LConfTempChan3ConfProfile adsl2LConfTempChan3RaRatioDs adsl2LConfTempChan3RaRatioUs adsl2LConfTempChan4ConfProfile adsl2LConfTempChan4RaRatioDs adsl2LConfTempChan4RaRatioUs adsl2LConfTempRowStatus adsl2LConfProfProfileName adsl2LConfProfScMaskDs adsl2LConfProfScMaskUs adsl2LConfProfRfiBandsDs adsl2LConfProfRaModeDs adsl2LConfProfRaModeUs Morgenstern, et al. Standards Track [Page 15] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LConfProfRaUsNrmDs adsl2LConfProfRaUsNrmUs adsl2LConfProfRaUsTimeDs adsl2LConfProfRaUsTimeUs adsl2LConfProfRaDsNrmsDs adsl2LConfProfRaDsNrmsUs adsl2LConfProfRaDsTimeDs adsl2LConfProfRaDsTimeUs adsl2LConfProfTargetSnrmDs adsl2LConfProfTargetSnrmUs adsl2LConfProfMaxSnrmDs adsl2LConfProfMaxSnrmUs adsl2LConfProfMinSnrmDs adsl2LConfProfMinSnrmUs adsl2LConfProfMsgMinUs adsl2LConfProfMsgMinDs adsl2LConfProfAtuTransSysEna adsl2LConfProfPmMode adsl2LConfProfL0Time adsl2LConfProfL2Time adsl2LConfProfL2Atpr adsl2LConfProfL2Atprt adsl2LConfProfRowStatus adsl2LConfProfAdslMode adsl2LConfProfMaxNomPsdDs adsl2LConfProfMaxNomPsdUs adsl2LConfProfMaxNomAtpDs adsl2LConfProfMaxNomAtpUs adsl2LConfProfMaxAggRxPwrUs adsl2LConfProfPsdMaskDs adsl2LConfProfPsdMaskUs adsl2LConfProfPsdMaskSelectUs adsl2LConfProfModeSpecRowStatus adsl2ChConfProfProfileName adsl2ChConfProfMinDataRateDs adsl2ChConfProfMinDataRateUs adsl2ChConfProfMinResDataRateDs adsl2ChConfProfMinResDataRateUs adsl2ChConfProfMaxDataRateDs adsl2ChConfProfMaxDataRateUs adsl2ChConfProfMinDataRateLowPwrDs adsl2ChConfProfMaxDelayDs adsl2ChConfProfMaxDelayUs adsl2ChConfProfMinProtectionDs adsl2ChConfProfMinProtectionUs adsl2ChConfProfMaxBerDs adsl2ChConfProfMaxBerUs adsl2ChConfProfUsDataRateDs Morgenstern, et al. Standards Track [Page 16] RFC 4706 ADSL2-LINE MIB November 2006 adsl2ChConfProfDsDataRateDs adsl2ChConfProfUsDataRateUs adsl2ChConfProfDsDataRateUs adsl2ChConfProfImaEnabled adsl2ChConfProfRowStatus adsl2LAlarmConfTempTemplateName adsl2LAlarmConfTempLineProfile adsl2LAlarmConfTempChan1ConfProfile adsl2LAlarmConfTempChan2ConfProfile adsl2LAlarmConfTempChan3ConfProfile adsl2LAlarmConfTempChan4ConfProfile adsl2LAlarmConfTempRowStatus adsl2LineAlarmConfProfileName adsl2LineAlarmConfProfileAtucThresh15MinFecs adsl2LineAlarmConfProfileAtucThresh15MinEs adsl2LineAlarmConfProfileAtucThresh15MinSes adsl2LineAlarmConfProfileAtucThresh15MinLoss adsl2LineAlarmConfProfileAtucThresh15MinUas adsl2LineAlarmConfProfileAturThresh15MinFecs adsl2LineAlarmConfProfileAturThresh15MinEs adsl2LineAlarmConfProfileAturThresh15MinSes adsl2LineAlarmConfProfileAturThresh15MinLoss adsl2LineAlarmConfProfileAturThresh15MinUas adsl2LineAlarmConfProfileThresh15MinFailedFullInt adsl2LineAlarmConfProfileThresh15MinFailedShrtInt adsl2LineAlarmConfProfileRowStatus adsl2ChAlarmConfProfileName adsl2ChAlarmConfProfileAtucThresh15MinCodingViolations adsl2ChAlarmConfProfileAtucThresh15MinCorrected adsl2ChAlarmConfProfileAturThresh15MinCodingViolations adsl2ChAlarmConfProfileAturThresh15MinCorrected adsl2ChAlarmConfProfileRowStatus Note also that the interface indices in this MIB are maintained persistently. View-based Access Control Model (VACM) data relating to these SHOULD be stored persistently as well [RFC3410]. 2.6. Line Topology An ADSL/ADSL2 and ADSL2+ Line consists of two units: ATU-C (the central office termination unit) and ATU-R (the remote termination unit). There are up to 4 channels, each carrying an independent information flow, as shown in the figure below. Morgenstern, et al. Standards Track [Page 17] RFC 4706 ADSL2-LINE MIB November 2006 <-- Network Side Customer Side --> || +-------+ +-------+ + |<---------------------1------------------->| + + |<---------------------2------------------->| + | ATU-C <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| ATU-R | + |<---------------------3------------------->| + + |<---------------------4------------------->| + +-------+ +-------+ Key: ADSL/ADSL2/ADSL2+ Span <~~~~> ADSL/ADSL2/ADSL2+ twisted-pair -1- Channel #1 carried over the line -2- Optional channel #2 carried over the line -3- Optional channel #3 carried over the line -4- Optional channel #4 carried over the line Figure 2: General topology for an ADSL/ADSL2/ADSL2+ Line 2.7. Counters, Interval Buckets, and Thresholds 2.7.1. Counters Managed There are various types of counters specified in this MIB. Each counter refers either to the whole ADSL/ADSL2/ADSL2+ line, to one of the XTU entities, or to one of the bearer channels. o On the whole line level For full initializations, failed full initializations, short initializations, and failed short initializations, there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute "failed" event bucket has an associated threshold notification. o On the XTU level For the LOS Seconds, ES, SES, FEC seconds, and UAS, there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute event bucket has an associated threshold notification. Morgenstern, et al. Standards Track [Page 18] RFC 4706 ADSL2-LINE MIB November 2006 o On the bearer channel level For the coding violations (CRC anomalies) and corrected blocks (i.e., FEC events), there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute event bucket has an associated threshold notification. 2.7.2. Minimum Number of Buckets Although it is possible to support up to 96 15-minute history buckets of "interval-counters", systems implementing this MIB module SHOULD practically support at least 16 buckets, as specified in ITU-T G.997.1, paragraph 7.2.7.2. Similarly, it is possible to support up to 30 previous 1-day "interval-counters", but systems implementing this MIB module SHOULD support at least 1 previous-day bucket. 2.7.3. Interval Buckets Initialization There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute interval and any wall clock; however, some implementations may align the 15-minute intervals with quarter hours. Likewise, an implementation may choose to align one day intervals with the start of a day. Counters are not reset when an XTU is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module). 2.7.4. Interval Buckets Validity As in RFC 3593 [RFC3593] and RFC 2662 [RFC2662], in case the data for an interval is suspect or known to be invalid, the agent MUST report the interval as invalid. If the current 15-minute event bucket is determined to be invalid, the element management system SHOULD ignore its content, and the agent MUST NOT generate notifications based upon the value of the event bucket. A valid 15-minute event bucket SHOULD usually count the events for exactly 15 minutes. Similarly, a valid 1-day event bucket SHOULD usually count the events for exactly 24 hours. However, the following scenarios are exceptional: Morgenstern, et al. Standards Track [Page 19] RFC 4706 ADSL2-LINE MIB November 2006 1) For implementations that align the 15-minute intervals with quarter hours, and the 1-day intervals with start of a day, the management system may still start the PM process not aligned with the wall clock. Such a management system may wish to retrieve even partial information for the first event buckets, rather than declaring them all as invalid. 2) For an event bucket that suffered relatively short outages, the management system may wish to retrieve the available PM outcomes, rather than declare the whole event bucket as invalid. This is more important for 1-day event buckets. 3) An event bucket may be shorter or longer than the formal duration if a clock adjustment was performed during the interval. This MIB allows supporting the exceptional scenarios described above by reporting the actual Monitoring Time of a monitoring interval. This parameter is relevant only for Valid intervals, but is useful for these exceptional scenarios: a) The management system MAY still declare a partial PM interval as Valid and report the actual number of seconds the interval lasted. b) If the interval was shortened or extended due to clock corrections, the management system SHOULD report the actual number of seconds the interval lasted, besides reporting that the interval is Valid. 2.8. Profiles As a managed node can handle a large number of XTUs, (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on every XTU may become burdensome. Moreover, most lines are provisioned identically with the same set of parameters. To simplify the provisioning process, this MIB module makes use of profiles and templates. A configuration profile is a set of parameters that can be shared by multiple entities. There are configuration profiles to address the line-level provisioning, and another type of profile that addresses the channel-level provisioning parameters. A configuration template is actually a profile-of-profiles. That is, a template is comprised of one line configuration profile and one or more channel configuration profiles. A template provides the complete configuration of a line. The same configuration can be shared by multiple lines. Morgenstern, et al. Standards Track [Page 20] RFC 4706 ADSL2-LINE MIB November 2006 Similarly to the configuration profiles and templates, this MIB module makes use of templates and profiles for specifying the alarm thresholds associated with performance parameters. This allows provisioning multiple lines with the same criteria for generating threshold crossing notifications. The following paragraphs describe templates and profiles used in this MIB module 2.8.1. Configuration Profiles and Templates o Line Configuration Profiles - Line configuration profiles contain parameters for configuring the low layer of ADSL/ADSL2 and ADSL2+ lines. They are defined in the adsl2LineConfProfTable. The line configuration includes issues such as the specific ADSL/ADSL2 or ADSL2+ modes to enable on the respective line, power spectrum parameters, rate adaptation criteria, and SNR margin- related parameters. A subset of the line configuration parameters depends upon the specific ADSL Mode allowed (i.e., Does the profile allow ADSL, ADSL2, and/or ADSL2+) as well as what annex/annexes of the standard are allowed. This is the reason a line profile MUST include one or more mode-specific extensions. o Channel Configuration Profiles - Channel configuration profiles contain parameters for configuring bearer channels over the ADSL/ADSL2 and ADSL2+ lines. They are sometimes considered the service layer configuration of the ADSL/ADSL2 and ADSL2+ lines. They are defined in the adsl2ChConfProfTable. The channel configuration includes issues such as the desired minimum and maximum rate on each traffic flow direction and impulse noise protection parameters. o Line Configuration Templates - Line configuration templates allow combining line configuration profiles and channel configuration profiles to a comprehensive configuration of the ADSL/ADSL2 and ADSL2+ line. They are defined in the adsl2LineConfTemplateTable. The line configuration template includes one index (OID) of a line configuration profile and one to four indexes of channel configuration profiles. The template also addresses the issue of distributing the excess available data rate on each traffic flow direction (i.e., the data rate left after each channel is allocated a data rate to satisfy its minimum requested data rate) among the various channels. Morgenstern, et al. Standards Track [Page 21] RFC 4706 ADSL2-LINE MIB November 2006 2.8.2. Alarm Configuration Profiles and Templates o Line Alarm Configuration Profiles - Line-level Alarm configuration profiles contain the threshold values for Performance Monitoring (PM) parameters, counted either on the whole line level or on an XTU level. Thresholds are required only for failures and anomalies, e.g., there are thresholds for failed initializations and LOS seconds, but not for the aggregate number of full initializations. These profiles are defined in the adsl2LineAlarmConfProfileTable. o Channel Alarm Configuration Profiles - Channel-level Alarm configuration profiles contain the threshold values for PM parameters counted on a bearer channel level. Thresholds are defined for two types of anomalies: corrected blocks and coding violations. These profiles are defined in the adsl2ChAlarmConfProfileTable. o Line Alarm Configuration Templates - Line Alarm configuration templates allow combining line-level alarm configuration profiles and channel-level alarm configuration profiles to a comprehensive configuration of the PM thresholds for ADSL/ADSL2 and ADSL2+ line. They are defined in the adsl2LineAlarmConfTemplateTable. The line alarm configuration template includes one index (OID) of a line-level alarm configuration profile and one to four indexes of channel-level alarm configuration profiles. 2.8.3. Managing Profiles and Templates The index value for each profile and template is a locally-unique, administratively assigned name having the textual convention 'SnmpAdminString' (RFC 3411 [RFC3411]). One or more lines may be configured to share parameters of a single configuration template (e.g., adsl2LConfTempTemplateName = 'silver') by setting its adsl2LineCnfgTemplate objects to the value of this template. One or more lines may be configured to share parameters of a single Alarm configuration template (e.g., adsl2LAlarmConfTempTemplateName = 'silver') by setting its adsl2LineAlarmCnfgTemplate objects to the value of this template. Before a template can be deleted or taken out of service, it MUST first be unreferenced from all associated lines. Implementations MAY also reject template modification while it is associated with any line. Morgenstern, et al. Standards Track [Page 22] RFC 4706 ADSL2-LINE MIB November 2006 Before a profile can be deleted or taken out of service, it MUST first be unreferenced from all associated templates. Implementations MAY also reject profile modification while it is referenced by any template. Implementations MUST provide a default profile whose name is 'DEFVAL' for each profile and template type. The values of the associated parameters will be vendor-specific unless otherwise indicated in this document. Before a line's templates have been set, these templates will be automatically used by setting adsl2LineCnfgTemplate and adsl2LineAlarmCnfgTemplate to 'DEFVAL' where appropriate. This default profile name, 'DEFVAL', is considered reserved in the context of profiles and templates defined in this MIB module. Profiles and templates are created, assigned, and deleted dynamically using the profile name and profile row status in each of the profile tables. If the implementation allows modifying a profile or template while it is associated with a line, then such changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line. 2.8.4. Managing Multiple Bearer Channels The number of bearer channels is configured by setting the template attributes adsl2LConfTempChan1ConfProfile, adsl2LConfTempChan2ConfProfile, adsl2LConfTempChan3ConfProfile, and adsl2LConfTempChan4ConfProfile and then assigning that template to a DSL line using the adsl2LineCnfgTemplate attribute. When the number of bearer channels for a DSL line changes, the SNMP agent will automatically create or destroy rows in channel-related tables associated with that line. For example, when a DSL line is operating with one bearer channel, there will be zero rows in channel-related tables for channels two, three, and four. The SNMP agent MUST create and destroy channel-related rows as follows: o When the number of bearer channels for a DSL line changes to a higher number, the SNMP agent will automatically create rows in the adsl2ChannelStatusTable, and adsl2PMChCurrTable tables for that line. o When the number of bearer channels for a DSL line changes to a lower number, the SNMP agent will automatically destroy rows in the adsl2ChannelStatusTable, adsl2PMChCurrTable, adsl2PMChHist15MinTable, and adsl2PMChHist1DTable tables for that line. Morgenstern, et al. Standards Track [Page 23] RFC 4706 ADSL2-LINE MIB November 2006 2.9. Notifications The ability to generate the SNMP notifications coldStart/warmStart (per [RFC3418]), which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/linkDown (per [RFC2863]), which are per interface (i.e., ADSL/ADSL2 or ADSL2+ line), is REQUIRED. A linkDown notification MAY be generated whenever any of ES, SES, CRC Anomaly, LOS, LOF, or UAS event occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The notifications defined in this MIB module are for status change (e.g., initialization failure) and for the threshold crossings associated with the following events: full initialization failures, short initialization failures, ES, SES, FEC Seconds, LOS Seconds, UAS, FEC Seconds, FEC events, and CRC anomalies. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. The adsl2LineStatusAtur and adsl2LineStatusAtuc are bitmasks representing all outstanding error conditions associated with the ATU-R and ATU-C (respectively). Note that since the ATU-R status is obtained via the EOC, this information may be unavailable in case the ATU-R is unreachable via EOC during a line error condition. Therefore, not all conditions may always be included in its current status. Notifications corresponding to the bit fields in those two status objects are defined. Note that there are other status parameters that refer to the ATU-R (e.g., downstream line attenuation). Those parameters also depend on the availability of EOC between the ATU-C and the ATU-R. A threshold notification occurs whenever the corresponding current 15-minute interval error counter becomes equal to or exceeds the threshold value. Only one notification SHOULD be sent per interval per interface. Since the current 15-minute counter is reset to 0 every 15 minutes, if the condition persists, the notification may recur as often as every 15 minutes. For example, to get a notification whenever a "loss of" event occurs (but at most once every 15 minutes), set the corresponding threshold to 1. The agent will generate a notification when the event originally occurs. Notifications, other than the threshold notifications listed above, SHOULD be rate-limited (throttled) such that there is an implementation-specific gap between the generation of consecutive notifications of the same event. When notifications are rate- Morgenstern, et al. Standards Track [Page 24] RFC 4706 ADSL2-LINE MIB November 2006 limited, they are dropped and not queued for sending at a future time. This is intended to be a general rate-limiting statement for notifications that otherwise have no explicit rate-limiting assertions in this document. Note that the Network Management System, or NMS, may receive a linkDown notification, as well, if enabled (via ifLinkUpDownTrapEnable [RFC2863]). At the beginning of the next 15 minute interval, the counter is reset. When the first second goes by and the event occurs, the current interval bucket will be 1, which equals the threshold, and the notification will be sent again. 3. Definitions ADSL2-LINE-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; adsl2TCMIB MODULE-IDENTITY LAST-UPDATED "200610040000Z" -- October 4th, 2006 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair & Co-editor: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 Morgenstern, et al. Standards Track [Page 25] RFC 4706 ADSL2-LINE MIB November 2006 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION "This MIB Module provides Textual Conventions to be used by the ADSL2-LINE-MIB module for the purpose of managing ADSL, ADSL2, and ADSL2+ lines. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4706: see the RFC itself for full legal notices." REVISION "200610040000Z" -- October 4th, 2006 DESCRIPTION "Initial version, published as RFC 4706." ::= { transmission 238 2 } -- adsl2MIB 2 ------------------------------------------------ -- Textual Conventions -- ------------------------------------------------ Adsl2Unit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values Morgenstern, et al. Standards Track [Page 26] RFC 4706 ADSL2-LINE MIB November 2006 are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R)." SYNTAX INTEGER { atuc(1), atur(2) } Adsl2Direction ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the direction of a band as being either upstream or downstream. Specified as an INTEGER, the two values are: upstream(1), and downstream(2)." SYNTAX INTEGER { upstream(1), downstream(2) } Adsl2TransmissionModeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of ADSL2 line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) -- not in G.997.1 Bit 13-17: Reserved Bit 18 : G.992.3 POTS non-overlapped (F) Bit 19 : G.992.3 POTS overlapped (F) Bit 20 : G.992.3 ISDN non-overlapped (F) Bit 21 : G.992.3 ISDN overlapped (F) Morgenstern, et al. Standards Track [Page 27] RFC 4706 ADSL2-LINE MIB November 2006 Bit 22-23: Reserved Bit 24 : G.992.4 POTS non-overlapped (L) Bit 25 : G.992.4 POTS overlapped (L) Bit 26-27: Reserved Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F) Bit 29 : G.992.3 Annex I All-Digital overlapped (F) Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F) Bit 31 : G.992.3 Annex J All-Digital overlapped (F) Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L) Bit 33 : G.992.4 Annex I All-Digital overlapped (L) Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) Bit 36 : G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) Bit 37 : G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) Bit 38 : G.992.3 Annex M POTS non-overlapped (F) Bit 39 : G.992.3 Annex M POTS overlapped (F) Bit 40 : G.992.5 POTS non-overlapped (F) Bit 41 : G.992.5 POTS overlapped (F) Bit 42 : G.992.5 ISDN non-overlapped (F) Bit 43 : G.992.5 ISDN overlapped (F) Bit 44-45: Reserved Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F) Bit 47 : G.992.5 Annex I All-Digital overlapped (F) Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F) Bit 49 : G.992.5 Annex J All-Digital overlapped (F) Bit 50 : G.992.5 Annex M POTS non-overlapped (F) Bit 51 : G.992.5 Annex M POTS overlapped (F) Bit 52-55: Reserved" SYNTAX BITS { ansit1413(0), etsi(1), g9921PotsNonOverlapped(2), g9921PotsOverlapped(3), g9921IsdnNonOverlapped(4), g9921isdnOverlapped(5), g9921tcmIsdnNonOverlapped(6), g9921tcmIsdnOverlapped(7), g9922potsNonOverlapped(8), g9922potsOverlapped(9), g9922tcmIsdnNonOverlapped(10), g9922tcmIsdnOverlapped(11), g9921tcmIsdnSymmetric(12), reserved1(13), reserved2(14), Morgenstern, et al. Standards Track [Page 28] RFC 4706 ADSL2-LINE MIB November 2006 reserved3(15), reserved4(16), reserved5(17), g9923PotsNonOverlapped(18), g9923PotsOverlapped(19), g9923IsdnNonOverlapped(20), g9923isdnOverlapped(21), reserved6(22), reserved7(23), g9924potsNonOverlapped(24), g9924potsOverlapped(25), reserved8(26), reserved9(27), g9923AnnexIAllDigNonOverlapped(28), g9923AnnexIAllDigOverlapped(29), g9923AnnexJAllDigNonOverlapped(30), g9923AnnexJAllDigOverlapped(31), g9924AnnexIAllDigNonOverlapped(32), g9924AnnexIAllDigOverlapped(33), g9923AnnexLMode1NonOverlapped(34), g9923AnnexLMode2NonOverlapped(35), g9923AnnexLMode3Overlapped(36), g9923AnnexLMode4Overlapped(37), g9923AnnexMPotsNonOverlapped(38), g9923AnnexMPotsOverlapped(39), g9925PotsNonOverlapped(40), g9925PotsOverlapped(41), g9925IsdnNonOverlapped(42), g9925isdnOverlapped(43), reserved10(44), reserved11(45), g9925AnnexIAllDigNonOverlapped(46), g9925AnnexIAllDigOverlapped(47), g9925AnnexJAllDigNonOverlapped(48), g9925AnnexJAllDigOverlapped(49), g9925AnnexMPotsNonOverlapped(50), g9925AnnexMPotsOverlapped(51), reserved12(52), reserved13(53), reserved14(54), reserved15(55) } Adsl2RaMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the rate adaptation behavior for the line. The three possible behaviors are: Morgenstern, et al. Standards Track [Page 29] RFC 4706 ADSL2-LINE MIB November 2006 manual(1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit(2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values. dynamicRa(3) - Dynamic Rate-Adaptation during initialization process as well as during SHOWTIME." SYNTAX INTEGER { manual(1), raInit(2), dynamicRa(3) } Adsl2InitResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the result of a full initialization attempt; the six possible result values are: noFail(0) - Successful initialization. configError(1) - Configuration failure. configNotFeasible(2) - Configuration details not supported. commFail(3) - Communication failure. noPeerAtu(4) - Peer ATU not detected. otherCause(5) - Other initialization failure reason. The values used are as defined in ITU-T G.997.1, paragraph 7.5.1.3" SYNTAX INTEGER { noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), otherCause(5) } Adsl2OperationModes ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ADSL2 management model specified includes an ADSL Mode attribute that identifies an instance of ADSL Mode-Specific PSD Configuration object in the ADSL Line Profile. The following classes of ADSL operating mode are defined. The notes (F) and (L) denote Full-Rate and Lite/splitterless respectively: Morgenstern, et al. Standards Track [Page 30] RFC 4706 ADSL2-LINE MIB November 2006 +-------+--------------------------------------------------+ | Value | ADSL operation mode description | +-------+--------------------------------------------------+ 1 - The default/generic PSD configuration. Default configuration will be used when no other matching mode-specific configuration can be found. 2 - ADSL family. The attributes included in the Mode- Specific PSD Configuration are irrelevant for ITU-T G.992.1 and G.992.2 ADSL modes. Hence, it is possible to map those modes to this generic class. 3-7 - Unused. Reserved for future ITU-T specification. 8 - G.992.3 POTS non-overlapped (F) 9 - G.992.3 POTS overlapped (F) 10 - G.992.3 ISDN non-overlapped (F) 11 - G.992.3 ISDN overlapped (F) 12-13 - Unused. Reserved for future ITU-T specification. 14 - G.992.4 POTS non-overlapped (L) 15 - G.992.4 POTS overlapped (L) 16-17 - Unused. Reserved for future ITU-T specification. 18 - G.992.3 Annex I All-Digital non-overlapped (F) 19 - G.992.3 Annex I All-Digital overlapped (F) 20 - G.992.3 Annex J All-Digital non-overlapped (F) 21 - G.992.3 Annex J All-Digital overlapped (F) 22 - G.992.4 Annex I All-Digital non-overlapped (L) 23 - G.992.4 Annex I All-Digital overlapped (L) 24 - G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) 25 - G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) 26 - G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) 27 - G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) 28 - G.992.3 Annex M POTS non-overlapped (F) 29 - G.992.3 Annex M POTS overlapped (F) 30 - G.992.5 POTS non-overlapped (F) 31 - G.992.5 POTS overlapped (F) 32 - G.992.5 ISDN non-overlapped (F) 33 - G.992.5 ISDN overlapped (F) 34-35 - Unused. Reserved for future ITU-T specification. 36 - G.992.5 Annex I All-Digital non-overlapped (F) 37 - G.992.5 Annex I All-Digital overlapped (F) 38 - G.992.5 Annex J All-Digital non-overlapped (F) 39 - G.992.5 Annex J All-Digital overlapped (F) 40 - G.992.5 Annex M POTS non-overlapped (F) 41 - G.992.5 Annex M POTS overlapped (F) Morgenstern, et al. Standards Track [Page 31] RFC 4706 ADSL2-LINE MIB November 2006 " SYNTAX INTEGER { defMode (1), adsl(2), g9923PotsNonOverlapped(8), g9923PotsOverlapped(9), g9923IsdnNonOverlapped(10), g9923isdnOverlapped(11), g9924potsNonOverlapped(14), g9924potsOverlapped(15), g9923AnnexIAllDigNonOverlapped(18), g9923AnnexIAllDigOverlapped(19), g9923AnnexJAllDigNonOverlapped(20), g9923AnnexJAllDigOverlapped(21), g9924AnnexIAllDigNonOverlapped(22), g9924AnnexIAllDigOverlapped(23), g9923AnnexLMode1NonOverlapped(24), g9923AnnexLMode2NonOverlapped(25), g9923AnnexLMode3Overlapped(26), g9923AnnexLMode4Overlapped(27), g9923AnnexMPotsNonOverlapped(28), g9923AnnexMPotsOverlapped(29), g9925PotsNonOverlapped(30), g9925PotsOverlapped(31), g9925IsdnNonOverlapped(32), g9925isdnOverlapped(33), g9925AnnexIAllDigNonOverlapped(36), g9925AnnexIAllDigOverlapped(37), g9925AnnexJAllDigNonOverlapped(38), g9925AnnexJAllDigOverlapped(39), g9925AnnexMPotsNonOverlapped(40), g9925AnnexMPotsOverlapped(41) } Adsl2PowerMngState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax uniquely identify each power management state defined for the ADSL/ADSL2 or ADSL2+ link. The possible values are: l0(1) - L0 - Full power management state. l1(2) - L1 - Low power management state (for G.992.2). l2(3) - L2 - Low power management state (for G.992.3, G.992.4, and G.992.5). l3(4) - L3 - Idle power management state." SYNTAX INTEGER { Morgenstern, et al. Standards Track [Page 32] RFC 4706 ADSL2-LINE MIB November 2006 l0(1), l1(2), l2(3), l3(4) } Adsl2ConfPmsForce ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the desired power management state for the ADSL/ADSL2 or ADSL2+ link: l3toL0(0) - Perform a transition from L3 to L0 (Full power management state). l0toL2(2) - Perform a transition from L0 to L2 (Low power management state). l0orL2toL3(3) - Perform a transition into L3 (Idle power management state). The values used are as defined in ITU-T G.997.1, paragraph 7.3.1.1.3" SYNTAX INTEGER { l3toL0(0), l0toL2(2), l0orL2toL3(3) } Adsl2LConfProfPmMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the power modes/states into which the ATU-C or ATU-R may autonomously transit. It is a BITS structure that allows control of the following transit options: allowTransitionsToIdle(0) - XTU may autonomously transit to idle (L3) state. allowTransitionsToLowPower(1) - XTU may autonomously transit to low-power (L2) state." SYNTAX BITS { allowTransitionsToIdle(0), allowTransitionsToLowPower(1) } Adsl2LineLdsf ::= TEXTUAL-CONVENTION Morgenstern, et al. Standards Track [Page 33] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that control the Loop Diagnostic mode for the ADSL/ADSL2 or ADSL2+ link. The possible values are: inhibit(0) - Inhibit Loop Diagnostic mode. force(1) - Force/Initiate Loop Diagnostic mode. The values used are as defined in ITU-T G.997.1, paragraph 7.3.1.1.8" SYNTAX INTEGER { inhibit(0), force(1) } Adsl2LdsfResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Possible failure reasons associated with performing a Dual Ended Loop Test (DELT) on a DSL line. Possible values are: none(1) - The default value in case LDSF was never requested for the associated line. success(2) - The recent command completed successfully. inProgress(3) - The Loop Diagnostics process is in progress. unsupported(4) - The NE or the line card doesn't support LDSF. cannotRun(5) - The NE cannot initiate the command, due to a nonspecific reason. aborted(6) - The Loop Diagnostics process aborted. failed(7) - The Loop Diagnostics process failed. illegalMode(8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp(9) - The NE cannot initiate the command, as the relevant line is administratively 'Up'. tableFull(10) - The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources(11) - The NE cannot initiate the command, due to lack of internal memory resources." SYNTAX INTEGER { none(1), success(2), Morgenstern, et al. Standards Track [Page 34] RFC 4706 ADSL2-LINE MIB November 2006 inProgress(3), unsupported(4), cannotRun(5), aborted(6), failed(7), illegalMode(8), adminUp(9), tableFull(10), noResources(11) } Adsl2SymbolProtection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the minimum-length impulse noise protection (INP) in terms of number of symbols. The possible values are: noProtection (i.e., INP not required), halfSymbol (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol." SYNTAX INTEGER { noProtection(1), halfSymbol(2), singleSymbol(3), twoSymbols(4), threeSymbols(5), fourSymbols(6), fiveSymbols(7), sixSymbols(8), sevenSymbols(9), eightSymbols(10), nineSymbols(11), tenSymbols(12), elevenSymbols(13), twelveSymbols(14), thirteeSymbols(15), fourteenSymbols(16), fifteenSymbols(17), sixteenSymbols(18) } Adsl2MaxBer ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER). The possible values are: eminus3(1) - Maximum BER=E^-3 Morgenstern, et al. Standards Track [Page 35] RFC 4706 ADSL2-LINE MIB November 2006 eminus5(2) - Maximum BER=E^-5 eminus7(3) - Maximum BER=E^-7" SYNTAX INTEGER { eminus3(1), eminus5(2), eminus7(3) } Adsl2ScMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 512 bits in this OCTET STRING array represents the corresponding bin in the downstream direction. A value of one indicates that the bin is not in use." SYNTAX OCTET STRING (SIZE(0..64)) Adsl2ScMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 64 bits in this OCTET STRING array represents the corresponding bin in the upstream direction. A value of one indicates that the bin is not in use." SYNTAX OCTET STRING (SIZE(0..8)) Adsl2RfiDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 512 bits in this OCTET STRING array represents the corresponding bin in the downstream direction. A value of one indicates that the bin is part of a notch filter." SYNTAX OCTET STRING (SIZE(0..64)) Adsl2PsdMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz." SYNTAX OCTET STRING (SIZE(0..96)) Morgenstern, et al. Standards Track [Page 36] RFC 4706 ADSL2-LINE MIB November 2006 Adsl2PsdMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 4 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz." SYNTAX OCTET STRING (SIZE(0..12)) Adsl2Tssi ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 transmit spectrum shaping (TSSi) breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the shaping parameter at the breakpoint. It is a value from 0 to 127 (units of -0.5 dB). The special value 127 indicates that the sub-carrier is not transmitted." SYNTAX OCTET STRING (SIZE(0..96)) Adsl2LastTransmittedState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This parameter represents the last successfully transmitted initialization state in the last full initialization performed on the line. States are per the specific xDSL technology and are numbered from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used) up to Showtime." SYNTAX INTEGER { atucG9941(0), atucQuiet1(1), atucComb1(2), atucQuiet2(3), atucComb2(4), atucIcomb1(5), atucLineprob(6), atucQuiet3(7), atucComb3(8), atucIComb2(9), atucMsgfmt(10), Morgenstern, et al. Standards Track [Page 37] RFC 4706 ADSL2-LINE MIB November 2006 atucMsgpcb(11), atucQuiet4(12), atucReverb1(13), atucTref1(14), atucReverb2(15), atucEct(16), atucReverb3(17), atucTref2(18), atucReverb4(19), atucSegue1(20), atucMsg1(21), atucReverb5(22), atucSegue2(23), atucMedley(24), atucExchmarker(25), atucMsg2(26), atucReverb6(27), atucSegue3(28), atucParams(29), atucReverb7(30), atucSegue4(31), atucShowtime(32), -- aturG9941(100), aturQuiet1(101), aturComb1(102), aturQuiet2(103), aturComb2(104), aturIcomb1(105), aturLineprob(106), aturQuiet3(107), aturComb3(108), aturIcomb2(109), aturMsgfmt(110), aturMsgpcb(111), aturReverb1(112), aturQuiet4(113), aturReverb2(114), aturQuiet5(115), aturReverb3(116), aturEct(117), aturReverb4(118), aturSegue1(119), aturReverb5(120), aturSegue2(121), aturMsg1(122), aturMedley(123), aturExchmarker(124), Morgenstern, et al. Standards Track [Page 38] RFC 4706 ADSL2-LINE MIB November 2006 aturMsg2(125), aturReverb6(126), aturSegue3(127), aturParams(128), aturReverb7(129), aturSegue4(130), aturShowtime(131) } Adsl2LineStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are status parameters that reflect the failure status for a given endpoint of ADSL/ADSL2 or ADSL2+ link. This BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. lossOfFrame(1) - Loss of frame synchronization. lossOfSignal(2) - Loss of signal. lossOfPower(3) - Loss of power. Usually this failure may be reported for ATU-Rs only. initFailure(4) - Recent initialization process failed. Never active on ATU-R." SYNTAX BITS { noDefect(0), lossOfFrame(1), lossOfSignal(2), lossOfPower(3), initFailure(4) } Adsl2ChAtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are status parameters that reflect the failure status for Transmission Convergence (TC) layer of a given ATM interface (data path over an ADSL/ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. noCellDelineation(1) - The link was successfully Morgenstern, et al. Standards Track [Page 39] RFC 4706 ADSL2-LINE MIB November 2006 initialized, but cell delineation was never acquired on the associated ATM data path. lossOfCellDelineation(2) - Loss of cell delineation on the associated ATM data path." SYNTAX BITS { noDefect(0), noCellDelineation(1), lossOfCellDelineation(2) } Adsl2ChPtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are status parameters that reflect the failure status for a given PTM interface (packet data path over an ADSL/ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. outOfSync(1) - Out of synchronization." SYNTAX BITS { noDefect(0), outOfSync(1) } END Morgenstern, et al. Standards Track [Page 40] RFC 4706 ADSL2-LINE MIB November 2006 ADSL2-LINE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Unsigned32, NOTIFICATION-TYPE, Integer32, Counter32 FROM SNMPv2-SMI ifIndex FROM IF-MIB TruthValue, RowStatus FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB HCPerfIntervalThreshold, HCPerfTimeElapsed FROM HC-PerfHist-TC-MIB -- [RFC3705] Adsl2Unit, Adsl2Direction, Adsl2TransmissionModeType, Adsl2RaMode, Adsl2InitResult, Adsl2OperationModes, Adsl2PowerMngState, Adsl2ConfPmsForce, Adsl2LConfProfPmMode, Adsl2LineLdsf, Adsl2LdsfResult, Adsl2SymbolProtection, Adsl2MaxBer, Adsl2ScMaskDs, Adsl2ScMaskUs, Adsl2RfiDs, Adsl2PsdMaskDs, Adsl2PsdMaskUs, Adsl2Tssi, Adsl2LastTransmittedState, Adsl2LineStatus, Adsl2ChAtmStatus, Morgenstern, et al. Standards Track [Page 41] RFC 4706 ADSL2-LINE MIB November 2006 Adsl2ChPtmStatus FROM ADSL2-LINE-TC-MIB -- [This document] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; adsl2MIB MODULE-IDENTITY LAST-UPDATED "200610040000Z" -- October 4th, 2006 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair & Co-editor: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo Morgenstern, et al. Standards Track [Page 42] RFC 4706 ADSL2-LINE MIB November 2006 NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION " This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing ADSL, ADSL2, and ADSL2+ lines. The MIB module described in RFC 2662 [RFC2662] describes objects used for managing Asymmetric Bit-Rate DSL (ADSL) interfaces per [T1E1.413], [G.992.1], and [G.992.2]. These object descriptions are based upon the specifications for the ADSL Embedded Operations Channel (EOC) as defined in American National Standards Institute (ANSI) T1E1.413/1995 [T1E1.413] and International Telecommunication Union (ITU-T) G.992.1 [G.992.1] and G.992.2 [G.992.2]. This document does not obsolete RFC 2662 [RFC2662], but rather provides a more comprehensive management model that includes the ADSL2 and ADSL2+ technologies per G.992.3, G.992.4, and G.992.5 ([G.992.3], [G.992.4], and [G.992.5], respectively). In addition, objects have been added to improve the management of ADSL, ADSL2, and ADSL2+ lines. Additionally, the management framework for New Generation ADSL lines specified by the Digital Subscriber Line Forum (DSLF) has been taken into consideration [TR-90]. That framework is based on ITU-T G.997.1 standard [G.997.1] as well as two amendments: [G.997.1am1] and [G.997.1am2]. Note that the revised ITU-T G.997.1 standard also refers to the next generation of VDSL technology, known as VDSL2, per ITU-T G.993.2 [G.993.2]. However, managing VDSL2 lines is currently beyond the scope of this document. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the IANA Considerations section of this document. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4706: see the RFC itself for full legal notices." Morgenstern, et al. Standards Track [Page 43] RFC 4706 ADSL2-LINE MIB November 2006 REVISION "200610040000Z" -- October 4th, 2006 DESCRIPTION "Initial version, published as RFC 4706." ::= { transmission 238 } adsl2 OBJECT IDENTIFIER ::= { adsl2MIB 1 } ------------------------------------------------ adsl2Line OBJECT IDENTIFIER ::= { adsl2 1 } adsl2Status OBJECT IDENTIFIER ::= { adsl2 2 } adsl2Inventory OBJECT IDENTIFIER ::= { adsl2 3 } adsl2PM OBJECT IDENTIFIER ::= { adsl2 4 } adsl2Profile OBJECT IDENTIFIER ::= { adsl2 5 } adsl2Scalar OBJECT IDENTIFIER ::= { adsl2 6 } adsl2Notifications OBJECT IDENTIFIER ::= { adsl2 0 } adsl2Conformance OBJECT IDENTIFIER ::= { adsl2 7 } ------------------------------------------------ adsl2PMLine OBJECT IDENTIFIER ::= { adsl2PM 1 } adsl2PMChannel OBJECT IDENTIFIER ::= { adsl2PM 2 } ------------------------------------------------ adsl2ProfileLine OBJECT IDENTIFIER ::= { adsl2Profile 1 } adsl2ProfileChannel OBJECT IDENTIFIER ::= { adsl2Profile 2 } adsl2ProfileAlarmConf OBJECT IDENTIFIER ::= { adsl2Profile 3 } ------------------------------------------------ adsl2ScalarSC OBJECT IDENTIFIER ::= { adsl2Scalar 1 } ------------------------------------------------ ------------------------------------------------ -- adsl2LineTable -- ------------------------------------------------ adsl2LineTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineTable contains configuration, command, and status parameters of the ADSL2 line. The index of this table is an interface index where the interface has an ifType of adsl2plus(238). Several objects in this table MUST be maintained in a persistent manner." ::= { adsl2Line 1 } adsl2LineEntry OBJECT-TYPE SYNTAX Adsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 44] RFC 4706 ADSL2-LINE MIB November 2006 "The table adsl2LineTable contains configuration, commands, and status parameters of the ADSL2 line" INDEX { ifIndex } ::= { adsl2LineTable 1 } Adsl2LineEntry ::= SEQUENCE { adsl2LineCnfgTemplate SnmpAdminString, adsl2LineAlarmCnfgTemplate SnmpAdminString, adsl2LineCmndConfPmsf Adsl2ConfPmsForce, adsl2LineCmndConfLdsf Adsl2LineLdsf, adsl2LineCmndConfLdsfFailReason Adsl2LdsfResult, adsl2LineCmndAutomodeColdStart TruthValue, adsl2LineStatusAtuTransSys Adsl2TransmissionModeType, adsl2LineStatusPwrMngState Adsl2PowerMngState, adsl2LineStatusInitResult Adsl2InitResult, adsl2LineStatusLastStateDs Adsl2LastTransmittedState, adsl2LineStatusLastStateUs Adsl2LastTransmittedState, adsl2LineStatusAtur Adsl2LineStatus, adsl2LineStatusAtuc Adsl2LineStatus, adsl2LineStatusLnAttenDs Unsigned32, adsl2LineStatusLnAttenUs Unsigned32, adsl2LineStatusSigAttenDs Unsigned32, adsl2LineStatusSigAttenUs Unsigned32, adsl2LineStatusSnrMarginDs Integer32, adsl2LineStatusSnrMarginUs Integer32, adsl2LineStatusAttainableRateDs Unsigned32, adsl2LineStatusAttainableRateUs Unsigned32, adsl2LineStatusActPsdDs Integer32, adsl2LineStatusActPsdUs Integer32, adsl2LineStatusActAtpDs Integer32, adsl2LineStatusActAtpUs Integer32 } adsl2LineCnfgTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Line Configuration Templates Table, (adsl2LineConfTemplateTable), which applies for this ADSL2 line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-90, paragraph 5.1.1" DEFVAL { "DEFVAL" } ::= { adsl2LineEntry 1 } Morgenstern, et al. Standards Track [Page 45] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LineAlarmCnfgTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Line Alarm Configuration Template Table, (adsl2LineAlarmConfTemplateTable), which applies to this ADSL2 line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-90, paragraph 5.1.1" DEFVAL { "DEFVAL" } ::= { adsl2LineEntry 2 } adsl2LineCmndConfPmsf OBJECT-TYPE SYNTAX Adsl2ConfPmsForce MAX-ACCESS read-write STATUS current DESCRIPTION "Power management state forced. Defines the line states to be forced by the near-end ATU on this line. The various possible values are: l3toL0(0), l0toL2(2), or l0orL2toL3(3). This object MUST be maintained in a persistent manner." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.1.3" DEFVAL { l3toL0 } ::= { adsl2LineEntry 3 } adsl2LineCmndConfLdsf OBJECT-TYPE SYNTAX Adsl2LineLdsf MAX-ACCESS read-write STATUS current DESCRIPTION "Loop diagnostics mode forced (LDSF). Defines whether the line should be forced into the loop diagnostics mode by the near-end ATU on this line or only be responsive to loop diagnostics initiated by the far-end ATU. This object MUST be maintained in a persistent manner. However, in case the operator forces loop diagnostics mode then the access node should reset the object (inhibit) when loop diagnostics mode procedures are completed." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.1.8" DEFVAL { inhibit } Morgenstern, et al. Standards Track [Page 46] RFC 4706 ADSL2-LINE MIB November 2006 ::= { adsl2LineEntry 4 } adsl2LineCmndConfLdsfFailReason OBJECT-TYPE SYNTAX Adsl2LdsfResult MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the recent occasion the Loop diagnostics mode forced (LDSF) was issued for the associated line. Possible values are: none(1) - The default value in case LDSF was never requested for the associated line. success(2) - The recent command completed successfully. inProgress(3) - The Loop Diagnostics process is in progress. unsupported(4) - The NE or the line card doesn't support LDSF. cannotRun(5) - The NE cannot initiate the command, due to a nonspecific reason. aborted(6) - The Loop Diagnostics process aborted. failed(7) - The Loop Diagnostics process failed. illegalMode(8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp(9) - The NE cannot initiate the command, as the relevant line is administratively 'Up'. tableFull(10) - The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources(11) - The NE cannot initiate the command, due to lack of internal memory resources." DEFVAL { none } ::= { adsl2LineEntry 5 } adsl2LineCmndAutomodeColdStart OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Automode cold start forced. This parameter is defined in order to improve testing of the performance of ATUs supporting automode when it is enabled in the MIB. Change the value of this parameter to 'true' indicates a change in loop conditions applied to the devices under test. The ATUs shall reset any historical information used for automode and for shortening G.994.1 handshake Morgenstern, et al. Standards Track [Page 47] RFC 4706 ADSL2-LINE MIB November 2006 and initialization. Automode is the case where multiple operation-modes are enabled through the adsl2LConfProfAtuTransSysEna object in the line configuration profile being used for the ADSL line, and where the selection of the actual operation-mode depends not only on the common capabilities of both ATUs (as exchanged in G.994.1), but also on achievable data rates under given loop conditions. This object MUST be maintained in a persistent manner." REFERENCE "ITU-T G.997.1 (amendment 1), 7.3.1.1.10" DEFVAL { false } ::= { adsl2LineEntry 6 } adsl2LineStatusAtuTransSys OBJECT-TYPE SYNTAX Adsl2TransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU Transmission System (ATS) in use. It is coded in a bit-map representation with only a single bit set to '1' (the selected coding for the ADSL line). This parameter may be derived from the handshaking procedures defined in Recommendation G.994.1. A set of ADSL2 line transmission modes, with one bit per mode." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.1.1" ::= { adsl2LineEntry 7 } adsl2LineStatusPwrMngState OBJECT-TYPE SYNTAX Adsl2PowerMngState MAX-ACCESS read-only STATUS current DESCRIPTION "The current power management state. One of four possible power management states: L0 - Synchronized and full transmission (i.e., Showtime). L1 - Low Power with reduced net data rate (G.992.2 only). L2 - Low Power with reduced net data rate (G.992.3 and G.992.4 only). L3 - No power. The various possible values are: l0(1), l1(2), l2(3), or l3(4)." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.2" ::= { adsl2LineEntry 8 } Morgenstern, et al. Standards Track [Page 48] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LineStatusInitResult OBJECT-TYPE SYNTAX Adsl2InitResult MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the result of the last full initialization performed on the line. It is an enumeration type with the following values: noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), or otherCause(5)." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.3" ::= { adsl2LineEntry 9 } adsl2LineStatusLastStateDs OBJECT-TYPE SYNTAX Adsl2LastTransmittedState MAX-ACCESS read-only STATUS current DESCRIPTION "The last successful transmitted initialization state in the downstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.4" ::= { adsl2LineEntry 10 } adsl2LineStatusLastStateUs OBJECT-TYPE SYNTAX Adsl2LastTransmittedState MAX-ACCESS read-only STATUS current DESCRIPTION "The last successful transmitted initialization state in the upstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.5" ::= { adsl2LineEntry 11 } adsl2LineStatusAtur OBJECT-TYPE SYNTAX Adsl2LineStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state (existing failures) of the ATU-R. This is a bit-map of possible conditions." REFERENCE "ITU-T G.997.1, paragraph 7.1.1.2" ::= { adsl2LineEntry 12 } adsl2LineStatusAtuc OBJECT-TYPE SYNTAX Adsl2LineStatus MAX-ACCESS read-only STATUS current Morgenstern, et al. Standards Track [Page 49] RFC 4706 ADSL2-LINE MIB November 2006 DESCRIPTION "Indicates current state (existing failures) of the ATU-C. This is a bit-map of possible conditions." REFERENCE "ITU-T G.997.1, paragraph 7.1.1.1" ::= { adsl2LineEntry 13 } adsl2LineStatusLnAttenDs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during diagnostics mode and initialization. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.6" ::= { adsl2LineEntry 14 } adsl2LineStatusLnAttenUs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during diagnostics mode and initialization. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.7" ::= { adsl2LineEntry 15 } adsl2LineStatusSigAttenDs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 50] RFC 4706 ADSL2-LINE MIB November 2006 "The measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during Showtime. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.8" ::= { adsl2LineEntry 16 } adsl2LineStatusSigAttenUs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during Showtime. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.9" ::= { adsl2LineEntry 17 } adsl2LineStatusSnrMarginDs OBJECT-TYPE SYNTAX Integer32 (-640..630 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Downstream SNR Margin is the maximum increase in dB of the noise power received at the ATU-R, such that the BER requirements are met for all downstream bearer channels. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.10" ::= { adsl2LineEntry 18 } adsl2LineStatusSnrMarginUs OBJECT-TYPE SYNTAX Integer32 (-640..630 | 2147483646 | 2147483647) Morgenstern, et al. Standards Track [Page 51] RFC 4706 ADSL2-LINE MIB November 2006 UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Upstream SNR Margin is the maximum increase in dB of the noise power received at the ATU-C, such that the BER requirements are met for all downstream bearer channels. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.11" ::= { adsl2LineEntry 19 } adsl2LineStatusAttainableRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Downstream. The maximum downstream net data rate currently attainable by the ATU-C transmitter and the ATU-R receiver, coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.12" ::= { adsl2LineEntry 20 } adsl2LineStatusAttainableRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Upstream. The maximum upstream net data rate currently attainable by the ATU-R transmitter and the ATU-C receiver, coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.13" ::= { adsl2LineEntry 21 } adsl2LineStatusActPsdDs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 52] RFC 4706 ADSL2-LINE MIB November 2006 "Actual Power Spectrum Density (PSD) Downstream. The average downstream transmit PSD over the sub-carriers used for downstream. It ranges from -900 to 0 units of 0.1 dB (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.14" ::= { adsl2LineEntry 22 } adsl2LineStatusActPsdUs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Power Spectrum Density (PSD) Upstream. The average upstream transmit PSD over the sub-carriers used for upstream. It ranges from -900 to 0 units of 0.1 dB (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.15" ::= { adsl2LineEntry 23 } adsl2LineStatusActAtpDs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Downstream. The total amount of transmit power delivered by the ATU-C at the U-C reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.16" ::= { adsl2LineEntry 24 } adsl2LineStatusActAtpUs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Upstream. The total amount of transmit power delivered by the ATU-R at the U-R reference point, at the instant of measurement. It ranges Morgenstern, et al. Standards Track [Page 53] RFC 4706 ADSL2-LINE MIB November 2006 from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.17" ::= { adsl2LineEntry 25 } ------------------------------------------------ -- adsl2ChannelStatusTable -- ------------------------------------------------ adsl2ChannelStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2ChannelStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2ChannelStatusTable contains status parameters of the ADSL2 channel. This table contains live data from equipment." ::= { adsl2Status 1 } adsl2ChannelStatusEntry OBJECT-TYPE SYNTAX Adsl2ChannelStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2ChannelStatusTable contains status parameters of the ADSL2 channel. The index of this table consists of an interface index, where the interface has an ifType value that is applicable for a DSL channel, along with a termination unit." INDEX { ifIndex, adsl2ChStatusUnit } ::= { adsl2ChannelStatusTable 1 } Adsl2ChannelStatusEntry ::= SEQUENCE { adsl2ChStatusUnit Adsl2Unit, adsl2ChStatusChannelNum Unsigned32, adsl2ChStatusActDataRate Unsigned32, adsl2ChStatusPrevDataRate Unsigned32, adsl2ChStatusActDelay Unsigned32, adsl2ChStatusAtmStatus Adsl2ChAtmStatus, adsl2ChStatusPtmStatus Adsl2ChPtmStatus } adsl2ChStatusUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible Morgenstern, et al. Standards Track [Page 54] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "The termination unit atuc(1) or atur(2)." ::= { adsl2ChannelStatusEntry 1 } adsl2ChStatusChannelNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Provides the bearer channel number associated with this row (i.e., the channel ifIndex). This enables determining the channel configuration profile and the channel thresholds profile applicable for this bearer channel." ::= { adsl2ChannelStatusEntry 2 } adsl2ChStatusActDataRate OBJECT-TYPE SYNTAX Unsigned32(0..200000000) UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The actual net data rate that the bearer channel is operating at, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. The data rate is coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.2.1" ::= { adsl2ChannelStatusEntry 3 } adsl2ChStatusPrevDataRate OBJECT-TYPE SYNTAX Unsigned32(0..200000000) UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The previous net data rate that the bearer channel was operating at just before the latest rate change event. This could be a full or short initialization, fast retrain, DRA or power management transitions, excluding transitions between L0 state and L1 or L2 states. The data rate is coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.2.2" ::= { adsl2ChannelStatusEntry 4 } adsl2ChStatusActDelay OBJECT-TYPE SYNTAX Unsigned32(0..8176) UNITS "milliseconds" Morgenstern, et al. Standards Track [Page 55] RFC 4706 ADSL2-LINE MIB November 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The actual one-way interleaving delay introduced by the PMS-TC in the direction of the bearer channel, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. It is coded in ms (rounded to the nearest ms)." REFERENCE "ITU-T G.997.1, paragraph 7.5.2.3" ::= { adsl2ChannelStatusEntry 5 } adsl2ChStatusAtmStatus OBJECT-TYPE SYNTAX Adsl2ChAtmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state (existing failures) of the ADSL channel in case its Data Path is ATM. This is a bit-map of possible conditions. The various bit positions are: noDefect(0), noCellDelineation(1), or lossOfCellDelineation(2). In the case where the channel is not an ATM Data Path, the object is set to '0'." REFERENCE "ITU-T G.997.1, paragraph 7.1.4" ::= { adsl2ChannelStatusEntry 6 } adsl2ChStatusPtmStatus OBJECT-TYPE SYNTAX Adsl2ChPtmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state (existing failures) of the ADSL channel in case its Data Path is PTM. This is a bit-map of possible conditions. The various bit positions are: noDefect(0), or outOfSync(1). In the case where the channel is not a PTM Data Path, the object is set to '0'." REFERENCE "ITU-T G.997.1, paragraph 7.1.5" ::= { adsl2ChannelStatusEntry 7 } ------------------------------------------------ -- Scalars that relate to the adsl2SCStatusTable. ------------------------------------------------ adsl2ScalarSCMaxInterfaces OBJECT-TYPE Morgenstern, et al. Standards Track [Page 56] RFC 4706 ADSL2-LINE MIB November 2006 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value determines the upper size of adsl2SCStatusTable. The maximum number of entries in adsl2SCStatusTable is equal to two times the value of this attribute." ::= { adsl2ScalarSC 1 } adsl2ScalarSCAvailInterfaces OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value determines the amount of space that is currently available in adsl2SCStatusTable. The number of entries available in adsl2SCStatusTable is equal to two times the value of this attribute." ::= { adsl2ScalarSC 2 } ------------------------------------------------ -- adsl2SCStatusTable -- ------------------------------------------------ adsl2SCStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2SCStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2SCStatusTable contains status parameters of the ADSL2 sub-carriers. The following points apply to this table: 1. The main purpose of this table is to hold the results of a DELT. 2. This table also holds parameters obtained at line initialization time. 3. The rows in this table are volatile; that is, they are lost if the SNMP agent is rebooted. 4. Due to the large OCTET STRING attributes in this table, the worst case memory requirements for this table are very high. The manager may use the row status attribute of this table to delete rows in order to reclaim memory. 5. The manager may create rows in this table. The SNMP agent may create rows in this table. Only the manager may delete rows in this table. 6. The maximum number of rows allowable in this table is indicated by the scalar attribute adsl2ScalarSCMaxInterfaces. Morgenstern, et al. Standards Track [Page 57] RFC 4706 ADSL2-LINE MIB November 2006 The number of rows available in this table is indicated by the scalar attribute adsl2ScalarSCAvailInterfaces. 7. The SNMP agent is permitted to create rows in this table when a DELT completes successfully or when line initialization occurs. It is not mandatory for the SNMP agent to create rows in this table; hence, it may be necessary for the manager to create rows in this table before any results can be stored. 8. If the manager attempts to create a row in this table and there are no more rows available, the creation attempt will fail, and the response to the SNMP SET PDU will contain the error noCreation(11). 9. If the SNMP agent attempts to create a row in this table and there are no more rows available, the creation attempt will fail, and the attribute adsl2LineCmndConfLdsfFailReason will indicate the reason for the failure. The failure reason will be either tableFull(10) or noResources(11). 10. An example of use of this table is as follows: Step 1. : The DELT is started by setting the : adsl2LineCmndConfLdsf from inhibit to force. Step 2. : The DELT completes, and valid data is : available. Step 3. : The row in the adsl2SCStatusTable where the : results will be stored does not yet exist so : the SNMP agent attempts to create the row. Step 4. : Due to a low memory condition, a row in the : adsl2SCStatusTable table cannot be created at : this time. Step 5. : The reason for the failure, tableFull(10), is : indicated in the adsl2LineCmndConfLdsfFailReason : attribute. 11. Another example of use of this table is as follows : Step 1. : The DELT is started by setting the : adsl2LineCmndConfLdsf from inhibit to force. Step 2. : The DELT completes and valid data is : available. Step 3. : The row in the adsl2SCStatusTable where the : results will be stored does not yet exist so : the SNMP agent attempts to create the row. Step 4. : The row creation is successful. Step 5. : The value of the attribute : adsl2LineCmndConfLdsfFailReasonreason is set : to success(2). 12. Another example of use of this table is as follows: Step 1. : The manager creates a row in adsl2SCStatusTable : for a particular ADSL2 line. Step 2. : The DELT is started on the above-mentioned Morgenstern, et al. Standards Track [Page 58] RFC 4706 ADSL2-LINE MIB November 2006 : line by setting the adsl2LineCmndConfLdsf from : inhibit to force. Step 3. : The DELT completes, and valid data is : available. Step 4. : The value of the attribute : adsl2LineCmndConfLdsfFailReasonreason is set : to success(2)." ::= { adsl2Status 2 } adsl2SCStatusEntry OBJECT-TYPE SYNTAX Adsl2SCStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table Adsl2SCStatusEntry contains status parameters of the ADSL2 sub-carriers. The index of this table is an interface index where the interface has an ifType of adsl2plus(238)." INDEX { ifIndex, adsl2SCStatusDirection } ::= { adsl2SCStatusTable 1 } Adsl2SCStatusEntry ::= SEQUENCE { adsl2SCStatusDirection Adsl2Direction, adsl2SCStatusMtime Unsigned32, adsl2SCStatusSnr OCTET STRING, adsl2SCStatusBitsAlloc OCTET STRING, adsl2SCStatusGainAlloc OCTET STRING, adsl2SCStatusTssi Adsl2Tssi, adsl2SCStatusLinScale Unsigned32, adsl2SCStatusLinReal OCTET STRING, adsl2SCStatusLinImg OCTET STRING, adsl2SCStatusLogMt Unsigned32, adsl2SCStatusLog OCTET STRING, adsl2SCStatusQlnMt Unsigned32, adsl2SCStatusQln OCTET STRING, adsl2SCStatusLnAtten Unsigned32, adsl2SCStatusSigAtten Unsigned32, adsl2SCStatusSnrMargin Integer32, adsl2SCStatusAttainableRate Unsigned32, adsl2SCStatusActAtp Integer32, adsl2SCStatusRowStatus RowStatus } adsl2SCStatusDirection OBJECT-TYPE SYNTAX Adsl2Direction MAX-ACCESS not-accessible STATUS current Morgenstern, et al. Standards Track [Page 59] RFC 4706 ADSL2-LINE MIB November 2006 DESCRIPTION "The direction of the sub-carrier is either upstream or downstream." ::= { adsl2SCStatusEntry 1 } adsl2SCStatusMtime OBJECT-TYPE SYNTAX Unsigned32 UNITS "symbols" MAX-ACCESS read-only STATUS current DESCRIPTION "SNR Measurement Time. The number of symbols used to measure the SNR values on the respective transmission direction. It should correspond to the value specified in the recommendation (e.g., the number of symbols in 1 second time interval for G.992.3). This parameter corresponds to 1 second in loop diagnostic procedure and should be updated otherwise." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.20.1 (SNRMTds) and paragraph 7.5.1.20.3 (SNRMTus)" ::= { adsl2SCStatusEntry 2 } adsl2SCStatusSnr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNR Margin per sub-carrier, expressing the ratio between the received signal power and received noise power per subscriber. It is an array of 512 octets, designed for supporting up to 512 (downstream) sub-carriers. The number of utilized octets on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Octet i (0 <= i < NSC) is set to a value in the range 0 to 254 to indicate that the respective downstream or upstream sub- carrier i has SNR of: (-32 + Adsl2SubcarrierSnr(i)/2) in dB (i.e., -32 to 95dB). The special value 255 means that no measurement could be done for the subcarrier because it is out of the PSD mask passband or that the noise PSD is out of range to be represented. Each value in this array is 8 bits wide." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.20.2 (SNRpsds) and paragraph 7.5.1.20.4 (SNRpsus)" ::= { adsl2SCStatusEntry 3 } adsl2SCStatusBitsAlloc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..256)) Morgenstern, et al. Standards Track [Page 60] RFC 4706 ADSL2-LINE MIB November 2006 UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION "The bits allocation per sub-carrier. An array of 256 octets (512 nibbles), designed for supporting up to 512 (downstream) sub-carriers. The number of utilized nibbles on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Nibble i (0 <= i < NSC) is set to a value in the range 0 to 15 to indicate that the respective downstream or upstream sub-carrier i has the same amount of bits allocation." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.21.1 (BITSpsds) and paragraph 7.5.1.21.2 (BITSpsus)" ::= { adsl2SCStatusEntry 4 } adsl2SCStatusGainAlloc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-only STATUS current DESCRIPTION "The gain allocation per sub-carrier. An array of 512 16-bits values, designed for supporting up to 512 (downstream) sub- carriers. The number of utilized octets on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Value i (0 <= i < NSC) is in the range 0 to 4093 to indicate that the respective downstream or upstream sub-carrier i has the same amount of gain value. The gain value is represented as a multiple of 1/512 on a linear scale. Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.21.3 (GAINSpsds) and paragraph 7.5.1.21.4 (GAINSpsus)" ::= { adsl2SCStatusEntry 5 } adsl2SCStatusTssi OBJECT-TYPE SYNTAX Adsl2Tssi MAX-ACCESS read-only STATUS current DESCRIPTION "The transmit spectrum shaping (TSSi) breakpoints expressed as the set of breakpoints exchanged during G.994.1. Each breakpoint is a pair of values occupying 3 octets with the following structure: First 2 octets - Index of the subcarrier used in the context of Morgenstern, et al. Standards Track [Page 61] RFC 4706 ADSL2-LINE MIB November 2006 the breakpoint. Third octet - The shaping parameter at the breakpoint. Subcarrier index is an unsigned number in the range 1 to either NSCds (downstream direction) or NSCus (upstream direction). The shaping parameter value is in the range 0 to 127 (units of -0.5dB). The special value 127 indicates that the subcarrier is not transmitted." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.21.5 (TSSpsds) and paragraph 7.5.1.21.6 (TSSpsus)" ::= { adsl2SCStatusEntry 6 } adsl2SCStatusLinScale OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The scale factor to be applied to the H(f) linear representation values for the respective transmission direction. This parameter is only available after a loop diagnostic procedure." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.18.1 (HLINSCds) and paragraph 7.5.1.18.5 (HLINSCus)" ::= { adsl2SCStatusEntry 7 } adsl2SCStatusLinReal OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 complex H(f) linear representation values in linear scale for the respective transmission direction. It is designed to support up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the real component [referred to here as a(i)] of Hlin(f = i*Df) value for a particular sub-carrier index i (0 <= i < NSC). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is Adsl2SubcarrierLinScale and a(i) and b(i) [provided by the Adsl2SubcarrierLinImg object] are in the range (-2^15+1) to (+2^15-1). A special value a(i)=b(i)= -2^15 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the attenuation is out of range to be represented. This parameter is only available after a loop diagnostic procedure. Morgenstern, et al. Standards Track [Page 62] RFC 4706 ADSL2-LINE MIB November 2006 Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.18.2 (HLINpsds) and paragraph 7.5.1.18.6 (HLINpsds)" ::= { adsl2SCStatusEntry 8 } adsl2SCStatusLinImg OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 complex H(f) linear representation values in linear scale for the respective transmission direction. It is designed to support up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the imaginary component [referred to here as b(i)] of Hlin(f = i*Df) value for a particular sub- carrier index i (0 <= i < NSC). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is Adsl2SubcarrierLinScale and a(i) [provided by the Adsl2SubcarrierLinReal object] and b(i) are in the range (-2^15+1) to (+2^15-1). A special value a(i)=b(i)= -2^15 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the attenuation is out of range to be represented. This parameter is only available after a loop diagnostic procedure. Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.18.2 (HLINpsds) and paragraph 7.5.1.18.6 (HLINpsds)" ::= { adsl2SCStatusEntry 9 } adsl2SCStatusLogMt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of symbols used to measure the H(f) logarithmic measurement values for the respective transmission direction. This parameter should correspond to the value specified in the recommendation (e.g., the number of symbols in 1 second time interval for G.992.3). This parameter corresponds to 1 second in loop diagnostic procedure and should be updated in initialization" Morgenstern, et al. Standards Track [Page 63] RFC 4706 ADSL2-LINE MIB November 2006 REFERENCE "ITU-T G.997.1, paragraph 7.5.1.18.3 (HLOGMTds) and paragraph 7.5.1.18.7 (HLOGMTus)" ::= { adsl2SCStatusEntry 10 } adsl2SCStatusLog OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 real H(f) logarithmic representation values in dB for the respective transmission direction. It is designed to support up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the real Hlog(f = i*Df) value for a particular sub-carrier index i, (0 <= i < NSC). The real Hlog(f) value is represented as (6-m(i)/10), with m(i) in the range 0 to 1022. A special value m=1023 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the attenuation is out of range to be represented. This parameter is applicable in loop diagnostic procedure and initialization. Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.18.4 (HLOGpsds) and paragraph 7.5.1.18.8 (HLOGpsus)" ::= { adsl2SCStatusEntry 11 } adsl2SCStatusQlnMt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of symbols used to measure the Quiet Line Noise values on the respective transmission direction. This parameter should correspond to the value specified in the recommendation (e.g., the number of symbols in 1 second time interval for G.992.3). This parameter corresponds to 1 second in loop diagnostic procedure and should be updated in initialization " REFERENCE "ITU-T G.997.1, paragraph 7.5.1.19.1 (QLNMTds) and paragraph 7.5.1.19.3 (QLNMTus)" ::= { adsl2SCStatusEntry 12 } adsl2SCStatusQln OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..512)) UNITS "dBm/Hz" Morgenstern, et al. Standards Track [Page 64] RFC 4706 ADSL2-LINE MIB November 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 real Quiet Line Noise values in dBm/Hz for the respective transmission direction. It is designed for up to 512 (downstream) sub-carriers. The number of utilized values on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Each array entry represents the QLN(f = i*Df) value for a particular sub-carrier index i, (0 <= i < NSC). The QLN(f) is represented as ( -23-n(i)/2), with n(i) in the range 0 to 254. A special value n(i)=255 indicates that no measurement could be done for the subcarrier because it is out of the passband or that the noise PSD is out of range to be represented. This parameter is applicable in loop diagnostic procedure and initialization. Each value in this array is 8 bits wide." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.19.2 (QLNpsds) and paragraph 7.5.1.19.4 (QLNpsus)" ::= { adsl2SCStatusEntry 13 } adsl2SCStatusLnAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "When referring to the downstream direction, it is the measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub-carriers during diagnostics mode. When referring to the upstream direction, it is the measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub-carriers during diagnostics mode. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.6 (LATNds) and paragraph 7.5.1.7 (LATNus)" Morgenstern, et al. Standards Track [Page 65] RFC 4706 ADSL2-LINE MIB November 2006 ::= { adsl2SCStatusEntry 14 } adsl2SCStatusSigAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "When referring to the downstream direction, it is the measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during Showtime after the diagnostics mode. When referring to the upstream direction, it is the measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during Showtime after the diagnostics mode. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.8 (SATNds) and paragraph 7.5.1.9 (SATNus)" ::= { adsl2SCStatusEntry 15 } adsl2SCStatusSnrMargin OBJECT-TYPE SYNTAX Integer32 (-640..630 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "SNR Margin is the maximum increase in dB of the noise power received at the ATU (ATU-R on downstream direction and ATU-C on upstream direction), such that the BER requirements are met for all bearer channels received at the ATU. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once Morgenstern, et al. Standards Track [Page 66] RFC 4706 ADSL2-LINE MIB November 2006 the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.10 (SNRMds) and paragraph 7.5.1.11 (SNRMus)" ::= { adsl2SCStatusEntry 16 } adsl2SCStatusAttainableRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate. The maximum net data rate currently attainable by the ATU-C transmitter and ATU-R receiver (when referring to downstream direction) or by the ATU-R transmitter and ATU-C receiver (when referring to upstream direction). Value is coded in bits/second. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.12 (ATTNDRds) and paragraph 7.5.1.13 (ATTNDRus)" ::= { adsl2SCStatusEntry 17 } adsl2SCStatusActAtp OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power from the ATU (ATU-R on downstream direction and ATU-C on upstream direction), at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of all 1's indicates the measurement is out of range to be represented. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.16 (ACTATPds) and paragraph 7.5.1.17 (ACTATPus)" ::= { adsl2SCStatusEntry 18 } adsl2SCStatusRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Morgenstern, et al. Standards Track [Page 67] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "Row Status. The manager may create and delete rows of this table. Please see the description of adsl2SCStatusTable above for more details." ::= { adsl2SCStatusEntry 19 } ------------------------------------------------ -- adsl2LineInventoryTable -- ------------------------------------------------ adsl2LineInventoryTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2LineInventoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineInventoryTable contains inventory of the ADSL2 units." ::= { adsl2Inventory 1 } adsl2LineInventoryEntry OBJECT-TYPE SYNTAX Adsl2LineInventoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineInventoryTable contains inventory of the ADSL2 units. The index of this table is an interface index where the interface has an ifType of adsl2plus(238)." INDEX { ifIndex, adsl2LInvUnit } ::= { adsl2LineInventoryTable 1 } Adsl2LineInventoryEntry ::= SEQUENCE { adsl2LInvUnit Adsl2Unit, adsl2LInvG994VendorId OCTET STRING, adsl2LInvSystemVendorId OCTET STRING, adsl2LInvVersionNumber OCTET STRING, adsl2LInvSerialNumber OCTET STRING, adsl2LInvSelfTestResult Unsigned32, adsl2LInvTransmissionCapabilities Adsl2TransmissionModeType } adsl2LInvUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit atuc(1) or atur(2)." Morgenstern, et al. Standards Track [Page 68] RFC 4706 ADSL2-LINE MIB November 2006 ::= { adsl2LineInventoryEntry 1 } adsl2LInvG994VendorId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU G.994.1 Vendor ID as inserted in the G.994.1 CL/CLR message. It consists of 8 binary octets, including a country code followed by a (regionally allocated) provider code, as defined in Recommendation T.35." REFERENCE "ITU-T G.997.1, paragraph 7.4" ::= { adsl2LineInventoryEntry 2 } adsl2LInvSystemVendorId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU System Vendor ID (identifies the ATU system integrator) as inserted in the Overhead Messages (both ATUs for G.992.3 and G.992.4) or in the Embedded Operations Channel (only ATU-R in G.992.1 and G.992.2). It consists of 8 binary octets, with the same format as used for Adsl2InvG994VendorId." REFERENCE "ITU-T G.997.1, paragraph 7.4" ::= { adsl2LineInventoryEntry 3 } adsl2LInvVersionNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU version number (vendor-specific information) as inserted in the Overhead Messages (both ATUs for G.992.3 and G.992.4) or in the Embedded Operations Channel (only ATU-R in G.992.1 and G.992.2). It consists of up to 16 binary octets." REFERENCE "ITU-T G.997.1, paragraph 7.4" ::= { adsl2LineInventoryEntry 4 } adsl2LInvSerialNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU serial number (vendor-specific information) as inserted in the Overhead Messages (both ATUs for G.992.3 and G.992.4) or in the Embedded Operations Channel (only ATU-R in Morgenstern, et al. Standards Track [Page 69] RFC 4706 ADSL2-LINE MIB November 2006 G.992.1 and G.992.2). It is vendor-specific information. It consists of up to 32 ASCII characters." REFERENCE "ITU-T G.997.1, paragraph 7.4" ::= { adsl2LineInventoryEntry 5 } adsl2LInvSelfTestResult OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU self-test result, coded as a 32-bit value. The most significant octet of the result is '0' if the self-test passed, and '1' if the self-test failed. The interpretation of the other octets is vendor discretionary." REFERENCE "ITU-T G.997.1, paragraph 7.4" ::= { adsl2LineInventoryEntry 6 } adsl2LInvTransmissionCapabilities OBJECT-TYPE SYNTAX Adsl2TransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU transmission system capability list of the different coding types. It is coded in a bit-map representation with 1 or more bits set. A bit set to '1' means that the ATU supports the respective coding. The value may be derived from the handshaking procedures defined in G.994.1. A set of ADSL2 line transmission modes, with one bit per mode." REFERENCE "ITU-T G.997.1, paragraph 7.4" ::= { adsl2LineInventoryEntry 7 } ------------------------------------------------ -- adsl2LineConfTemplateTable -- ------------------------------------------------ adsl2LineConfTemplateTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2LineConfTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineConfTemplateTable contains ADSL2 line configuration templates. Entries in this table MUST be maintained in a persistent manner." ::= { adsl2ProfileLine 1 } adsl2LineConfTemplateEntry OBJECT-TYPE Morgenstern, et al. Standards Track [Page 70] RFC 4706 ADSL2-LINE MIB November 2006 SYNTAX Adsl2LineConfTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineConfTemplateTable contains the ADSL2 line configuration template. A default template with an index of 'DEFVAL' will always exist, and its parameters will be set to vendor- specific values, unless otherwise specified in this document." INDEX { adsl2LConfTempTemplateName } ::= { adsl2LineConfTemplateTable 1 } Adsl2LineConfTemplateEntry ::= SEQUENCE { adsl2LConfTempTemplateName SnmpAdminString, adsl2LConfTempLineProfile SnmpAdminString, adsl2LConfTempChan1ConfProfile SnmpAdminString, adsl2LConfTempChan1RaRatioDs Unsigned32, adsl2LConfTempChan1RaRatioUs Unsigned32, adsl2LConfTempChan2ConfProfile SnmpAdminString, adsl2LConfTempChan2RaRatioDs Unsigned32, adsl2LConfTempChan2RaRatioUs Unsigned32, adsl2LConfTempChan3ConfProfile SnmpAdminString, adsl2LConfTempChan3RaRatioDs Unsigned32, adsl2LConfTempChan3RaRatioUs Unsigned32, adsl2LConfTempChan4ConfProfile SnmpAdminString, adsl2LConfTempChan4RaRatioDs Unsigned32, adsl2LConfTempChan4RaRatioUs Unsigned32, adsl2LConfTempRowStatus RowStatus } adsl2LConfTempTemplateName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table." REFERENCE "DSL Forum TR-90, paragraph 5.1.4" ::= { adsl2LineConfTemplateEntry 1 } adsl2LConfTempLineProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Line Configuration Profile Table, (adsl2LineConfProfTable), which applies for this ADSL2 line." Morgenstern, et al. Standards Track [Page 71] RFC 4706 ADSL2-LINE MIB November 2006 REFERENCE "DSL Forum TR-90, paragraph 5.1.4" DEFVAL { "DEFVAL" } ::= { adsl2LineConfTemplateEntry 2 } adsl2LConfTempChan1ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table, (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #1. The channel profile name specified here must match the name of an existing row in the adsl2ChConfProfileTable table." DEFVAL { "DEFVAL" } ::= { adsl2LineConfTemplateEntry 3 } adsl2LConfTempChan1RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #1 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan1RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 100 } ::= { adsl2LineConfTemplateEntry 4 } adsl2LConfTempChan1RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #1 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the Morgenstern, et al. Standards Track [Page 72] RFC 4706 ADSL2-LINE MIB November 2006 100 - adsl2LConfTempChan1RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 100 } ::= { adsl2LineConfTemplateEntry 5 } adsl2LConfTempChan2ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #2. If the channel is unused, then the object is set to a zero-length string. This object may be set to a zero-length string only if adsl2LConfTempChan3ConfProfile contains a zero-length string." DEFVAL { "" } ::= { adsl2LineConfTemplateEntry 6 } adsl2LConfTempChan2RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #2 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan2RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 0 } ::= { adsl2LineConfTemplateEntry 7 } adsl2LConfTempChan2RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" Morgenstern, et al. Standards Track [Page 73] RFC 4706 ADSL2-LINE MIB November 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #2 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan2RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 0 } ::= { adsl2LineConfTemplateEntry 8 } adsl2LConfTempChan3ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #3. If the channel is unused, then the object is set to a zero-length string. This object may be set to a zero-length string only if adsl2LConfTempChan4ConfProfile contains a zero-length string. This object may be set to a non-zero-length string only if adsl2LConfTempChan2ConfProfile contains a non-zero-length string." DEFVAL { "" } ::= { adsl2LineConfTemplateEntry 9 } adsl2LConfTempChan3RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #3 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan3RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream Morgenstern, et al. Standards Track [Page 74] RFC 4706 ADSL2-LINE MIB November 2006 direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 0 } ::= { adsl2LineConfTemplateEntry 10 } adsl2LConfTempChan3RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #3 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan3RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 0 } ::= { adsl2LineConfTemplateEntry 11 } adsl2LConfTempChan4ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Channel Configuration Profile Table (adsl2ChConfProfileTable) that applies to ADSL2 bearer channel #4. If the channel is unused, then the object is set to a zero-length string. This object may be set to a non-zero-length string only if adsl2LConfTempChan3ConfProfile contains a non-zero-length string." DEFVAL { "" } ::= { adsl2LineConfTemplateEntry 12 } adsl2LConfTempChan4RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken Morgenstern, et al. Standards Track [Page 75] RFC 4706 ADSL2-LINE MIB November 2006 into account for the bearer channel #4 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan4RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels. The sum of rate adaptation ratios over all bearers on the same direction shall sum to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 0 } ::= { adsl2LineConfTemplateEntry 13 } adsl2LConfTempChan4RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in %) that should be taken into account for the bearer channel #4 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - adsl2LConfTempChan4RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels. The sum of rate adaptation ratios over all bearers on the same direction shall sum to 100%." REFERENCE "ITU-T G.997.1, paragraph 7.3.2.1" DEFVAL { 0 } ::= { adsl2LineConfTemplateEntry 14 } adsl2LConfTempRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. A template is activated by setting this object to 'active'. When 'active' is set, the system will validate the template. Before a template can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it must first be unreferenced from all associated lines." ::= { adsl2LineConfTemplateEntry 15 } Morgenstern, et al. Standards Track [Page 76] RFC 4706 ADSL2-LINE MIB November 2006 ------------------------------------------ -- adsl2LineConfProfTable -- ------------------------------------------ adsl2LineConfProfTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2LineConfProfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineConfProfTable contains ADSL2 line profile configuration. Entries in this table MUST be maintained in a persistent manner." ::= { adsl2ProfileLine 2 } adsl2LineConfProfEntry OBJECT-TYPE SYNTAX Adsl2LineConfProfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineConfProfTable contains ADSL2 line profile configuration. A default profile with an index of 'DEFVAL' will always exist, and its parameters will be set to vendor- specific values, unless otherwise specified in this document." INDEX { adsl2LConfProfProfileName } ::= { adsl2LineConfProfTable 1 } Adsl2LineConfProfEntry ::= SEQUENCE { adsl2LConfProfProfileName SnmpAdminString, adsl2LConfProfScMaskDs Adsl2ScMaskDs, adsl2LConfProfScMaskUs Adsl2ScMaskUs, adsl2LConfProfRfiBandsDs Adsl2RfiDs, adsl2LConfProfRaModeDs Adsl2RaMode, adsl2LConfProfRaModeUs Adsl2RaMode, adsl2LConfProfRaUsNrmDs Unsigned32, adsl2LConfProfRaUsNrmUs Unsigned32, adsl2LConfProfRaUsTimeDs Unsigned32, adsl2LConfProfRaUsTimeUs Unsigned32, adsl2LConfProfRaDsNrmsDs Unsigned32, adsl2LConfProfRaDsNrmsUs Unsigned32, adsl2LConfProfRaDsTimeDs Unsigned32, adsl2LConfProfRaDsTimeUs Unsigned32, adsl2LConfProfTargetSnrmDs Unsigned32, adsl2LConfProfTargetSnrmUs Unsigned32, adsl2LConfProfMaxSnrmDs Unsigned32, Morgenstern, et al. Standards Track [Page 77] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LConfProfMaxSnrmUs Unsigned32, adsl2LConfProfMinSnrmDs Unsigned32, adsl2LConfProfMinSnrmUs Unsigned32, adsl2LConfProfMsgMinUs Unsigned32, adsl2LConfProfMsgMinDs Unsigned32, adsl2LConfProfAtuTransSysEna Adsl2TransmissionModeType, adsl2LConfProfPmMode Adsl2LConfProfPmMode, adsl2LConfProfL0Time Unsigned32, adsl2LConfProfL2Time Unsigned32, adsl2LConfProfL2Atpr Unsigned32, adsl2LConfProfL2Atprt Unsigned32, adsl2LConfProfRowStatus RowStatus } adsl2LConfProfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table." ::= { adsl2LineConfProfEntry 1 } adsl2LConfProfScMaskDs OBJECT-TYPE SYNTAX Adsl2ScMaskDs MAX-ACCESS read-create STATUS current DESCRIPTION "Sub-carriers mask. A bitmap of 512 bits that allows masking up to 512 downstream sub-carriers, depending on NSCds. If bit i (0 <= i < NSCds) is set to '1', the respective downstream sub-carrier i is masked, and if set to '0', the respective sub-carrier is unmasked. Note that there should always be unmasked sub-carriers (i.e., the object cannot be all 1's). Also note that if NSCds < 512, all bits i (NSCds < i <= 512) should be set to '1'." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.2.6" ::= { adsl2LineConfProfEntry 2 } adsl2LConfProfScMaskUs OBJECT-TYPE SYNTAX Adsl2ScMaskUs MAX-ACCESS read-create STATUS current DESCRIPTION "Sub-carriers mask. A bitmap of 64 bits that allows masking up to 64 downstream sub-carriers, depending on NSCds. If bit i (0 <= i < NSCus) is set to '1', the respective upstream sub-carrier i is masked, and if set to '0', the respective sub-carrier is unmasked. Note that there Morgenstern, et al. Standards Track [Page 78] RFC 4706 ADSL2-LINE MIB November 2006 should always be unmasked sub-carriers (i.e., the object cannot be all 1's). Also note that if NSCus < 64, all bits i (NSCus < i <= 64) should be set to '1'." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.2.7" ::= { adsl2LineConfProfEntry 3 } adsl2LConfProfRfiBandsDs OBJECT-TYPE SYNTAX Adsl2RfiDs MAX-ACCESS read-create STATUS current DESCRIPTION "The subset of downstream PSD mask breakpoints that shall be used to notch an RFI band. The specific interpolation around these points is defined in G.992.5. It is a bitmap of 512 bits that allows referring to up to 512 downstream sub-carriers, depending on NSCds. If bit i (0 <= i < NSCds) is set to '1', the respective downstream sub-carrier i is part of a notch filter, and if set to '0', the respective sub-carrier is not part of a notch filter. This information complements the specification provided by adsl2LConfProfPsdMaskDs. Note that if NSCds < 512, all bits i (NSCds= 1 for one or more bearer channels OR LOS >= 1 OR SEF >=1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >=1 OR RDI >=1 OR LPR-FE >=1 . This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 6 } adsl2PMLCurr15MSes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1 . This parameter is inhibited during UAS." Morgenstern, et al. Standards Track [Page 112] RFC 4706 ADSL2-LINE MIB November 2006 REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 7 } adsl2PMLCurr15MLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R)." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 8 } adsl2PMLCurr15MUas OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely-errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 9 } adsl2PMLCurr1DayValidIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Valid intervals." ::= { adsl2PMLineCurrEntry 10 } adsl2PMLCurr1DayInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid intervals." ::= { adsl2PMLineCurrEntry 11 } adsl2PMLCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only Morgenstern, et al. Standards Track [Page 113] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized." ::= { adsl2PMLineCurrEntry 12 } adsl2PMLCurr1DayFecs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 13 } adsl2PMLCurr1DayEs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was: ATU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 14 } adsl2PMLCurr1DaySes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1 This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" Morgenstern, et al. Standards Track [Page 114] RFC 4706 ADSL2-LINE MIB November 2006 ::= { adsl2PMLineCurrEntry 15 } adsl2PMLCurr1DayLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R)." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 16 } adsl2PMLCurr1DayUas OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely- errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrEntry 17 } ------------------------------------------------ -- PM line init current counters -- ------------------------------------------------ adsl2PMLineCurrInitTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMLineCurrInitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMLineCurrInitTable contains current initialization counters of the ADSL2 line. The PM counters in the table are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized." ::= { adsl2PMLine 2 } adsl2PMLineCurrInitEntry OBJECT-TYPE SYNTAX Adsl2PMLineCurrInitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 115] RFC 4706 ADSL2-LINE MIB November 2006 "The table adsl2PMLineCurrInitTable contains current initialization counters of the ADSL2 line. The index of this table consists of an interface index, where the interface has an ifType of adsl2plus(238), and a termination unit." INDEX { ifIndex } ::= { adsl2PMLineCurrInitTable 1 } Adsl2PMLineCurrInitEntry ::= SEQUENCE { adsl2PMLCurrInit15MTimeElapsed Unsigned32, adsl2PMLCurrInit15MFullInits Unsigned32, adsl2PMLCurrInit15MFailedFullInits Unsigned32, adsl2PMLCurrInit15MShortInits Unsigned32, adsl2PMLCurrInit15MFailedShortInits Unsigned32, adsl2PMLCurrInit1DayTimeElapsed Unsigned32, adsl2PMLCurrInit1DayFullInits Unsigned32, adsl2PMLCurrInit1DayFailedFullInits Unsigned32, adsl2PMLCurrInit1DayShortInits Unsigned32, adsl2PMLCurrInit1DayFailedShortInits Unsigned32 } adsl2PMLCurrInit15MTimeElapsed OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized." ::= { adsl2PMLineCurrInitEntry 1 } adsl2PMLCurrInit15MFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 2 } adsl2PMLCurrInit15MFailedFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Morgenstern, et al. Standards Track [Page 116] RFC 4706 ADSL2-LINE MIB November 2006 DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 3 } adsl2PMLCurrInit15MShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 4 } adsl2PMLCurrInit15MFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 5 } adsl2PMLCurrInit1DayTimeElapsed OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized." ::= { adsl2PMLineCurrInitEntry 6 } adsl2PMLCurrInit1DayFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 7 } Morgenstern, et al. Standards Track [Page 117] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMLCurrInit1DayFailedFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 8 } adsl2PMLCurrInit1DayShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 9 } adsl2PMLCurrInit1DayFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineCurrInitEntry 10 } ------------------------------------------- -- PM line history 15 Minutes -- ------------------------------------------- adsl2PMLineHist15MinTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMLineHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMLineHist15MinTable contains PM line history for 15min intervals of the ADSL2 line." ::= { adsl2PMLine 3 } adsl2PMLineHist15MinEntry OBJECT-TYPE SYNTAX Adsl2PMLineHist15MinEntry MAX-ACCESS not-accessible STATUS current Morgenstern, et al. Standards Track [Page 118] RFC 4706 ADSL2-LINE MIB November 2006 DESCRIPTION "The table adsl2PMLineHist15MinTable contains PM line history for 15min intervals of the ADSL2 line. The index of this table consists of an interface index, where the interface has an ifType of adsl2plus(238), along with a termination unit, and an interval number." INDEX { ifIndex, adsl2PMLHist15MUnit, adsl2PMLHist15MInterval } ::= { adsl2PMLineHist15MinTable 1 } Adsl2PMLineHist15MinEntry ::= SEQUENCE { adsl2PMLHist15MUnit Adsl2Unit, adsl2PMLHist15MInterval Unsigned32, adsl2PMLHist15MMonitoredTime Unsigned32, adsl2PMLHist15MFecs Counter32, adsl2PMLHist15MEs Counter32, adsl2PMLHist15MSes Counter32, adsl2PMLHist15MLoss Counter32, adsl2PMLHist15MUas Counter32, adsl2PMLHist15MValidInterval TruthValue } adsl2PMLHist15MUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit atuc(1) or atur(2)." ::= { adsl2PMLineHist15MinEntry 1 } adsl2PMLHist15MInterval OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { adsl2PMLineHist15MinEntry 2 } adsl2PMLHist15MMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { adsl2PMLineHist15MinEntry 3 } Morgenstern, et al. Standards Track [Page 119] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMLHist15MFecs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist15MinEntry 4 } adsl2PMLHist15MEs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was: ATU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist15MinEntry 5 } adsl2PMLHist15MSes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist15MinEntry 6 } adsl2PMLHist15MLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 120] RFC 4706 ADSL2-LINE MIB November 2006 "Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R)." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist15MinEntry 7 } adsl2PMLHist15MUas OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely- errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist15MinEntry 8 } adsl2PMLHist15MValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adsl2PMLineHist15MinEntry 9 } --------------------------------------- -- PM line history 1 Day -- --------------------------------------- adsl2PMLineHist1DayTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMLineHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMLineHist1DayTable contains PM line history for 24-hour intervals of the ADSL2 line." ::= { adsl2PMLine 4 } adsl2PMLineHist1DayEntry OBJECT-TYPE SYNTAX Adsl2PMLineHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMLineHist1DayTable contains PM line history for 24-hour intervals of the ADSL2 line. Morgenstern, et al. Standards Track [Page 121] RFC 4706 ADSL2-LINE MIB November 2006 The index of this table consists of an interface index, where the interface has an ifType of adsl2plus(238), along with a termination unit, and an interval number." INDEX { ifIndex, adsl2PMLHist1DUnit, adsl2PMLHist1DInterval } ::= { adsl2PMLineHist1DayTable 1 } Adsl2PMLineHist1DayEntry ::= SEQUENCE { adsl2PMLHist1DUnit Adsl2Unit, adsl2PMLHist1DInterval Unsigned32, adsl2PMLHist1DMonitoredTime Unsigned32, adsl2PMLHist1DFecs Counter32, adsl2PMLHist1DEs Counter32, adsl2PMLHist1DSes Counter32, adsl2PMLHist1DLoss Counter32, adsl2PMLHist1DUas Counter32, adsl2PMLHist1DValidInterval TruthValue } adsl2PMLHist1DUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { adsl2PMLineHist1DayEntry 1 } adsl2PMLHist1DInterval OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { adsl2PMLineHist1DayEntry 2 } adsl2PMLHist1DMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { adsl2PMLineHist1DayEntry 3 } adsl2PMLHist1DFecs OBJECT-TYPE SYNTAX Counter32 Morgenstern, et al. Standards Track [Page 122] RFC 4706 ADSL2-LINE MIB November 2006 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist1DayEntry 4 } adsl2PMLHist1DEs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was: ATU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1 ATU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist1DayEntry 5 } adsl2PMLHist1DSes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was: ATU-C: (CRC-8 summed over all bearer channels) >= 18 OR LOS >= 1 OR SEF >> 1 OR LPR >= 1 ATU-R: (FEBE summed over all bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist1DayEntry 6 } adsl2PMLHist1DLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval where there was LOS (or LOS-FE for ATU-R)." Morgenstern, et al. Standards Track [Page 123] RFC 4706 ADSL2-LINE MIB November 2006 REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist1DayEntry 7 } adsl2PMLHist1DUas OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely- errored seconds, and ends at the onset of 10 contiguous seconds with no severely-errored seconds." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineHist1DayEntry 8 } adsl2PMLHist1DValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adsl2PMLineHist1DayEntry 9 } ------------------------------------------- -- PM line init history 15 Minutes -- ------------------------------------------- adsl2PMLineInitHist15MinTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMLineInitHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMLineInitHist15MinTable contains PM line initialization history for 15-minute intervals of the ADSL2 line." ::= { adsl2PMLine 5 } adsl2PMLineInitHist15MinEntry OBJECT-TYPE SYNTAX Adsl2PMLineInitHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMLineInitHist15MinTable contains PM line Morgenstern, et al. Standards Track [Page 124] RFC 4706 ADSL2-LINE MIB November 2006 initialization history for 15 minutes intervals of the ADSL2 line. The index of this table consists of an interface index, where the interface has an ifType of adsl2plus(238), and an interval number." INDEX { ifIndex, adsl2PMLHistInit15MInterval } ::= { adsl2PMLineInitHist15MinTable 1 } Adsl2PMLineInitHist15MinEntry ::= SEQUENCE { adsl2PMLHistInit15MInterval Unsigned32, adsl2PMLHistInit15MMonitoredTime Unsigned32, adsl2PMLHistInit15MFullInits Unsigned32, adsl2PMLHistInit15MFailedFullInits Unsigned32, adsl2PMLHistInit15MShortInits Unsigned32, adsl2PMLHistInit15MFailedShortInits Unsigned32, adsl2PMLHistInit15MValidInterval TruthValue } adsl2PMLHistInit15MInterval OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { adsl2PMLineInitHist15MinEntry 1 } adsl2PMLHistInit15MMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { adsl2PMLineInitHist15MinEntry 2 } adsl2PMLHistInit15MFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist15MinEntry 3 } adsl2PMLHistInit15MFailedFullInits OBJECT-TYPE Morgenstern, et al. Standards Track [Page 125] RFC 4706 ADSL2-LINE MIB November 2006 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist15MinEntry 4 } adsl2PMLHistInit15MShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist15MinEntry 5 } adsl2PMLHistInit15MFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist15MinEntry 6 } adsl2PMLHistInit15MValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adsl2PMLineInitHist15MinEntry 7 } ------------------------------------------- -- PM line init history 1 Day -- ------------------------------------------- adsl2PMLineInitHist1DayTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMLineInitHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 126] RFC 4706 ADSL2-LINE MIB November 2006 "The table adsl2PMLineInitHist1DayTable contains PM line initialization history for 24-hour intervals of the ADSL2 line." ::= { adsl2PMLine 6 } adsl2PMLineInitHist1DayEntry OBJECT-TYPE SYNTAX Adsl2PMLineInitHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMLineInitHist1DayTable contains PM line initialization history for 24-hour intervals of the ADSL2 line. The index of this table consists of an interface index, where the interface has an ifType of adsl2plus(238), and an interval number." INDEX { ifIndex, adsl2PMLHistinit1DInterval } ::= { adsl2PMLineInitHist1DayTable 1 } Adsl2PMLineInitHist1DayEntry ::= SEQUENCE { adsl2PMLHistinit1DInterval Unsigned32, adsl2PMLHistinit1DMonitoredTime Unsigned32, adsl2PMLHistinit1DFullInits Unsigned32, adsl2PMLHistinit1DFailedFullInits Unsigned32, adsl2PMLHistinit1DShortInits Unsigned32, adsl2PMLHistinit1DFailedShortInits Unsigned32, adsl2PMLHistinit1DValidInterval TruthValue } adsl2PMLHistinit1DInterval OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { adsl2PMLineInitHist1DayEntry 1 } adsl2PMLHistinit1DMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { adsl2PMLineInitHist1DayEntry 2 } Morgenstern, et al. Standards Track [Page 127] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMLHistinit1DFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist1DayEntry 3 } adsl2PMLHistinit1DFailedFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist1DayEntry 4 } adsl2PMLHistinit1DShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist1DayEntry 5 } adsl2PMLHistinit1DFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph 7.2.1" ::= { adsl2PMLineInitHist1DayEntry 6 } adsl2PMLHistinit1DValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adsl2PMLineInitHist1DayEntry 7 } Morgenstern, et al. Standards Track [Page 128] RFC 4706 ADSL2-LINE MIB November 2006 --------------------------------------------------- -- PM channel current counters -- --------------------------------------------------- adsl2PMChCurrTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMChCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMChCurrTable contains current Performance Monitoring results of the ADSL2 channel. The PM counters in the table are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized." ::= { adsl2PMChannel 1 } adsl2PMChCurrEntry OBJECT-TYPE SYNTAX Adsl2PMChCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMChCurrTable contains current Performance Monitoring results of the ADSL2 channel. The index of this table consists of an interface index, where the interface has an ifType value that is applicable for a DSL channel, along with a termination unit." INDEX { ifIndex, adsl2PMChCurrUnit } ::= { adsl2PMChCurrTable 1 } Adsl2PMChCurrEntry ::= SEQUENCE { adsl2PMChCurrUnit Adsl2Unit, adsl2PMChCurrValidIntervals Unsigned32, adsl2PMChCurrInvalidIntervals Unsigned32, adsl2PMChCurr15MTimeElapsed HCPerfTimeElapsed, adsl2PMChCurr15MCodingViolations Unsigned32, adsl2PMChCurr15MCorrectedBlocks Unsigned32, adsl2PMChCurr1DayValidIntervals Unsigned32, adsl2PMChCurr1DayInvalidIntervals Unsigned32, adsl2PMChCurr1DayTimeElapsed HCPerfTimeElapsed, adsl2PMChCurr1DayCodingViolations Unsigned32, adsl2PMChCurr1DayCorrectedBlocks Unsigned32 } adsl2PMChCurrUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 129] RFC 4706 ADSL2-LINE MIB November 2006 "The termination unit." ::= { adsl2PMChCurrEntry 1 } adsl2PMChCurrValidIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Valid intervals." ::= { adsl2PMChCurrEntry 2 } adsl2PMChCurrInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid intervals." ::= { adsl2PMChCurrEntry 3 } adsl2PMChCurr15MTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized." ::= { adsl2PMChCurrEntry 4 } adsl2PMChCurr15MCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly should increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChCurrEntry 5 } adsl2PMChCurr15MCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Morgenstern, et al. Standards Track [Page 130] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChCurrEntry 6 } adsl2PMChCurr1DayValidIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Valid intervals." ::= { adsl2PMChCurrEntry 7 } adsl2PMChCurr1DayInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid intervals." ::= { adsl2PMChCurrEntry 8 } adsl2PMChCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds since this PM interval began. Note that the PM counters are not reset even when the XTU is reinitialized. They are reinitialized only when the agent itself is reset or reinitialized." ::= { adsl2PMChCurrEntry 9 } adsl2PMChCurr1DayCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly should Morgenstern, et al. Standards Track [Page 131] RFC 4706 ADSL2-LINE MIB November 2006 increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChCurrEntry 10 } adsl2PMChCurr1DayCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChCurrEntry 11 } ------------------------------------------- -- PM channel history 15 Minutes -- ------------------------------------------- adsl2PMChHist15MinTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMChHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMChCurrTable contains current Performance Monitoring results of the ADSL2 channel." ::= { adsl2PMChannel 2 } adsl2PMChHist15MinEntry OBJECT-TYPE SYNTAX Adsl2PMChHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMChCurrTable contains current Performance Monitoring results of the ADSL2 channel. The index of this table consists of an interface index, where the interface has an ifType value that is applicable for a DSL channel, along with a termination unit, and the interval number." INDEX { ifIndex, adsl2PMChHist15MUnit, adsl2PMChHist15MInterval } ::= { adsl2PMChHist15MinTable 1 } Morgenstern, et al. Standards Track [Page 132] RFC 4706 ADSL2-LINE MIB November 2006 Adsl2PMChHist15MinEntry ::= SEQUENCE { adsl2PMChHist15MUnit Adsl2Unit, adsl2PMChHist15MInterval Unsigned32, adsl2PMChHist15MMonitoredTime Unsigned32, adsl2PMChHist15MCodingViolations Unsigned32, adsl2PMChHist15MCorrectedBlocks Unsigned32, adsl2PMChHist15MValidInterval TruthValue } adsl2PMChHist15MUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { adsl2PMChHist15MinEntry 1 } adsl2PMChHist15MInterval OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { adsl2PMChHist15MinEntry 2 } adsl2PMChHist15MMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { adsl2PMChHist15MinEntry 3 } adsl2PMChHist15MCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly should increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChHist15MinEntry 4 } Morgenstern, et al. Standards Track [Page 133] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMChHist15MCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChHist15MinEntry 5 } adsl2PMChHist15MValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adsl2PMChHist15MinEntry 6 } ------------------------------------------ -- PM channel history 1 Day -- ------------------------------------------ adsl2PMChHist1DTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2PMChHist1DEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMChHist1DayTable contains PM channel history for 1-day intervals of ADSL2." ::= { adsl2PMChannel 3 } adsl2PMChHist1DEntry OBJECT-TYPE SYNTAX Adsl2PMChHist1DEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2PMChHist1DayTable contains PM channel history for 1-day intervals of ADSL2. The index of this table consists of an interface index, where the interface has an ifType value that is applicable for a DSL channel, along with a termination unit, and the interval number." Morgenstern, et al. Standards Track [Page 134] RFC 4706 ADSL2-LINE MIB November 2006 INDEX { ifIndex, adsl2PMChHist1DUnit, adsl2PMChHist1DInterval } ::= { adsl2PMChHist1DTable 1 } Adsl2PMChHist1DEntry ::= SEQUENCE { adsl2PMChHist1DUnit Adsl2Unit, adsl2PMChHist1DInterval Unsigned32, adsl2PMChHist1DMonitoredTime Unsigned32, adsl2PMChHist1DCodingViolations Unsigned32, adsl2PMChHist1DCorrectedBlocks Unsigned32, adsl2PMChHist1DValidInterval TruthValue } adsl2PMChHist1DUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { adsl2PMChHist1DEntry 1 } adsl2PMChHist1DInterval OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { adsl2PMChHist1DEntry 2 } adsl2PMChHist1DMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { adsl2PMChHist1DEntry 3 } adsl2PMChHist1DCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for ATU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple Morgenstern, et al. Standards Track [Page 135] RFC 4706 ADSL2-LINE MIB November 2006 channels, then each related CRC-8 (or FEBE) anomaly should increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChHist1DEntry 4 } adsl2PMChHist1DCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of FEC (FFEC for ATU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly should increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph 7.2.2" ::= { adsl2PMChHist1DEntry 5 } adsl2PMChHist1DValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { adsl2PMChHist1DEntry 6 } ------------------------------------------- -- Notifications Group -- ------------------------------------------- adsl2LinePerfFECSThreshAtuc NOTIFICATION-TYPE OBJECTS { adsl2PMLCurr15MFecs, adsl2LineAlarmConfProfileAtucThresh15MinFecs } STATUS current DESCRIPTION "This notification indicates that the FEC seconds threshold has been reached/exceeded for the referred ATU-C." ::= { adsl2Notifications 1 } adsl2LinePerfFECSThreshAtur NOTIFICATION-TYPE OBJECTS { Morgenstern, et al. Standards Track [Page 136] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMLCurr15MFecs, adsl2LineAlarmConfProfileAturThresh15MinFecs } STATUS current DESCRIPTION "This notification indicates that the FEC seconds threshold has been reached/exceeded for the referred ATU-R." ::= { adsl2Notifications 2 } adsl2LinePerfESThreshAtuc NOTIFICATION-TYPE OBJECTS { adsl2PMLCurr15MEs, adsl2LineAlarmConfProfileAtucThresh15MinEs } STATUS current DESCRIPTION "This notification indicates that the errored seconds threshold has been reached/exceeded for the referred ATU-C." ::= { adsl2Notifications 3 } adsl2LinePerfESThreshAtur NOTIFICATION-TYPE OBJECTS { adsl2PMLCurr15MEs, adsl2LineAlarmConfProfileAturThresh15MinEs } STATUS current DESCRIPTION "This notification indicates that the errored seconds threshold has been reached/exceeded for the referred ATU-R." ::= { adsl2Notifications 4 } adsl2LinePerfSESThreshAtuc NOTIFICATION-TYPE OBJECTS { adsl2PMLCurr15MSes, adsl2LineAlarmConfProfileAtucThresh15MinSes } STATUS current DESCRIPTION "This notification indicates that the severely-errored seconds threshold has been reached/exceeded for the referred ATU-C." ::= { adsl2Notifications 5 } adsl2LinePerfSESThreshAtur NOTIFICATION-TYPE OBJECTS { Morgenstern, et al. Standards Track [Page 137] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMLCurr15MSes, adsl2LineAlarmConfProfileAturThresh15MinSes } STATUS current DESCRIPTION "This notification indicates that the severely-errored seconds threshold has been reached/exceeded for the referred ATU-R." ::= { adsl2Notifications 6 } adsl2LinePerfLOSSThreshAtuc NOTIFICATION-TYPE OBJECTS { adsl2PMLCurr15MLoss, adsl2LineAlarmConfProfileAtucThresh15MinLoss } STATUS current DESCRIPTION "This notification indicates that the LOS seconds threshold has been reached/exceeded for the referred ATU-C." ::= { adsl2Notifications 7 } adsl2LinePerfLOSSThreshAtur NOTIFICATION-TYPE OBJECTS { adsl2PMLCurr15MLoss, adsl2LineAlarmConfProfileAturThresh15MinLoss } STATUS current DESCRIPTION "This notification indicates that the LOS seconds threshold has been reached/exceeded for the referred ATU-R." ::= { adsl2Notifications 8 } adsl2LinePerfUASThreshAtuc NOTIFICATION-TYPE OBJECTS { adsl2PMLCurr15MUas, adsl2LineAlarmConfProfileAtucThresh15MinUas } STATUS current DESCRIPTION "This notification indicates that the unavailable seconds threshold has been reached/exceeded for the referred ATU-C." ::= { adsl2Notifications 9 } adsl2LinePerfUASThreshAtur NOTIFICATION-TYPE OBJECTS { Morgenstern, et al. Standards Track [Page 138] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMLCurr15MUas, adsl2LineAlarmConfProfileAturThresh15MinUas } STATUS current DESCRIPTION "This notification indicates that the unavailable seconds threshold has been reached/exceeded for the referred ATU-R." ::= { adsl2Notifications 10 } adsl2LinePerfCodingViolationsThreshAtuc NOTIFICATION-TYPE OBJECTS { adsl2PMChCurr15MCodingViolations, adsl2ChAlarmConfProfileAtucThresh15MinCodingViolations } STATUS current DESCRIPTION "This notification indicates that the coding violations threshold has been reached/exceeded for the referred ATU-C." ::= { adsl2Notifications 11 } adsl2LinePerfCodingViolationsThreshAtur NOTIFICATION-TYPE OBJECTS { adsl2PMChCurr15MCodingViolations, adsl2ChAlarmConfProfileAturThresh15MinCodingViolations } STATUS current DESCRIPTION "This notification indicates that the coding violations threshold has been reached/exceeded for the referred ATU-R." ::= { adsl2Notifications 12 } adsl2LinePerfCorrectedThreshAtuc NOTIFICATION-TYPE OBJECTS { adsl2PMChCurr15MCorrectedBlocks, adsl2ChAlarmConfProfileAtucThresh15MinCorrected } STATUS current DESCRIPTION "This notification indicates that the corrected blocks (FEC events) threshold has been reached/exceeded for the referred ATU-C." ::= { adsl2Notifications 13 } adsl2LinePerfCorrectedThreshAtur NOTIFICATION-TYPE OBJECTS Morgenstern, et al. Standards Track [Page 139] RFC 4706 ADSL2-LINE MIB November 2006 { adsl2PMChCurr15MCorrectedBlocks, adsl2ChAlarmConfProfileAturThresh15MinCorrected } STATUS current DESCRIPTION "This notification indicates that the corrected blocks (FEC events) threshold has been reached/exceeded for the referred ATU-R." ::= { adsl2Notifications 14 } adsl2LinePerfFailedFullInitThresh NOTIFICATION-TYPE OBJECTS { adsl2PMLCurrInit15MFailedFullInits, adsl2LineAlarmConfProfileThresh15MinFailedFullInt } STATUS current DESCRIPTION "This notification indicates that the failed full initializations threshold has been reached/exceeded for the referred ADSL/ADSL2 or ADSL2+ line." ::= { adsl2Notifications 15 } adsl2LinePerfFailedShortInitThresh NOTIFICATION-TYPE OBJECTS { adsl2PMLCurrInit15MFailedShortInits, adsl2LineAlarmConfProfileThresh15MinFailedShrtInt } STATUS current DESCRIPTION "This notification indicates that the failed short initializations threshold has been reached/exceeded for the referred ADSL/ADSL2 or ADSL2+ line." ::= { adsl2Notifications 16 } adsl2LineStatusChangeAtuc NOTIFICATION-TYPE OBJECTS { adsl2LineStatusAtuc } STATUS current DESCRIPTION "This notification indicates that a status change is detected for the referred ATU-C." ::= { adsl2Notifications 17 } Morgenstern, et al. Standards Track [Page 140] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LineStatusChangeAtur NOTIFICATION-TYPE OBJECTS { adsl2LineStatusAtur } STATUS current DESCRIPTION "This notification indicates that a status change is detected for the referred ATU-R." ::= { adsl2Notifications 18 } -- conformance information adsl2Groups OBJECT IDENTIFIER ::= { adsl2Conformance 1 } adsl2Compliances OBJECT IDENTIFIER ::= { adsl2Conformance 2 } adsl2LineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that manage ADSL/ADSL2 or ADSL2+ interfaces." MODULE -- this module MANDATORY-GROUPS { adsl2LineGroup, adsl2ChannelStatusGroup, adsl2SCStatusGroup, adsl2LineInventoryGroup, adsl2LineConfTemplateGroup, adsl2LineConfProfGroup, adsl2LineConfProfModeSpecGroup, adsl2ChConfProfileGroup, adsl2LineAlarmConfTemplateGroup, adsl2PMLineCurrGroup, adsl2PMLineCurrInitGroup, adsl2PMLineHist15MinGroup, adsl2PMLineHist1DayGroup, adsl2PMLineInitHist15MinGroup, adsl2PMLineInitHist1DayGroup, adsl2PMChCurrGroup, adsl2PMChHist15MinGroup, adsl2PMChHist1DGroup } GROUP adsl2ChannelStatusAtmGroup DESCRIPTION "The group of status objects required when the data path Morgenstern, et al. Standards Track [Page 141] RFC 4706 ADSL2-LINE MIB November 2006 is ATM." GROUP adsl2ChannelStatusPtmGroup DESCRIPTION "The group of status objects required when the data path is PTM." GROUP adsl2LineConfProfRaGroup DESCRIPTION "The group of objects required for controlling the rate- adaptive behavior of the line." GROUP adsl2LineConfProfMsgMinGroup DESCRIPTION "The group of objects required for controlling the rate reserved for Overhead traffic." GROUP adsl2LineAlarmConfProfileGroup DESCRIPTION "The group of objects that define the alarm thresholds on line-level PM counters." GROUP adsl2ChAlarmConfProfileGroup DESCRIPTION "The group of objects that define the alarm thresholds on channel-level PM counters." GROUP adsl2ChConfProfileAtmGroup DESCRIPTION "The group of configuration objects required when the data path is ATM." GROUP adsl2ChConfProfileMinResGroup DESCRIPTION "The group of configuration objects required for the reserved data rate." GROUP adsl2PMLineCurrInitShortGroup DESCRIPTION "The group of PM counters for the current interval's short initializations." GROUP adsl2PMLineInitHist15MinShortGroup DESCRIPTION "The group of PM counters for the previous 15-minute interval's short initializations." GROUP adsl2PMLineInitHist1DayShortGroup Morgenstern, et al. Standards Track [Page 142] RFC 4706 ADSL2-LINE MIB November 2006 DESCRIPTION "The group of PM counters for the previous 24-hour interval's short initializations." GROUP adsl2ScalarSCGroup DESCRIPTION "The group of objects that report the available memory resources for DELT processes." GROUP adsl2ThreshNotificationGroup DESCRIPTION "The group of threshold crossing notifications." GROUP adsl2StatusChangeNotificationGroup DESCRIPTION "The group of status change notifications." ::= { adsl2Compliances 1 } -- units of conformance adsl2LineGroup OBJECT-GROUP OBJECTS { adsl2LineCnfgTemplate, adsl2LineAlarmCnfgTemplate, adsl2LineCmndConfPmsf, adsl2LineCmndConfLdsf, adsl2LineCmndConfLdsfFailReason, adsl2LineCmndAutomodeColdStart, adsl2LineStatusAtuTransSys, adsl2LineStatusPwrMngState, adsl2LineStatusInitResult, adsl2LineStatusLastStateDs, adsl2LineStatusLastStateUs, adsl2LineStatusAtur, adsl2LineStatusAtuc, adsl2LineStatusLnAttenDs, adsl2LineStatusLnAttenUs, adsl2LineStatusSigAttenDs, adsl2LineStatusSigAttenUs, adsl2LineStatusSnrMarginDs, adsl2LineStatusSnrMarginUs, adsl2LineStatusAttainableRateDs, adsl2LineStatusAttainableRateUs, adsl2LineStatusActPsdDs, adsl2LineStatusActPsdUs, adsl2LineStatusActAtpDs, Morgenstern, et al. Standards Track [Page 143] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LineStatusActAtpUs } STATUS current DESCRIPTION "The group of configuration, status, and commands objects on the line level." ::= { adsl2Groups 1 } adsl2ChannelStatusGroup OBJECT-GROUP OBJECTS { adsl2ChStatusChannelNum, adsl2ChStatusActDataRate, adsl2ChStatusPrevDataRate, adsl2ChStatusActDelay } STATUS current DESCRIPTION "The group of status objects on the channel level." ::= { adsl2Groups 2 } adsl2ChannelStatusAtmGroup OBJECT-GROUP OBJECTS { adsl2ChStatusAtmStatus } STATUS current DESCRIPTION "The group of status objects on the data path level when it is ATM." ::= { adsl2Groups 3 } adsl2ChannelStatusPtmGroup OBJECT-GROUP OBJECTS { adsl2ChStatusPtmStatus } STATUS current DESCRIPTION "The group of status objects on the data path level when it is PTM." ::= { adsl2Groups 4 } adsl2SCStatusGroup OBJECT-GROUP OBJECTS { adsl2SCStatusMtime, adsl2SCStatusSnr, Morgenstern, et al. Standards Track [Page 144] RFC 4706 ADSL2-LINE MIB November 2006 adsl2SCStatusBitsAlloc, adsl2SCStatusGainAlloc, adsl2SCStatusTssi, adsl2SCStatusLinScale, adsl2SCStatusLinReal, adsl2SCStatusLinImg, adsl2SCStatusLogMt, adsl2SCStatusLog, adsl2SCStatusQlnMt, adsl2SCStatusQln, adsl2SCStatusLnAtten, adsl2SCStatusSigAtten, adsl2SCStatusSnrMargin, adsl2SCStatusAttainableRate, adsl2SCStatusActAtp, adsl2SCStatusRowStatus } STATUS current DESCRIPTION "The group of status objects on the sub-carrier level. They are updated as a result of a DELT process." ::= { adsl2Groups 5 } adsl2LineInventoryGroup OBJECT-GROUP OBJECTS { adsl2LInvG994VendorId, adsl2LInvSystemVendorId, adsl2LInvVersionNumber, adsl2LInvSerialNumber, adsl2LInvSelfTestResult, adsl2LInvTransmissionCapabilities } STATUS current DESCRIPTION "The group of inventory objects per XTU." ::= { adsl2Groups 6 } adsl2LineConfTemplateGroup OBJECT-GROUP OBJECTS { adsl2LConfTempLineProfile, adsl2LConfTempChan1ConfProfile, adsl2LConfTempChan1RaRatioDs, adsl2LConfTempChan1RaRatioUs, adsl2LConfTempChan2ConfProfile, adsl2LConfTempChan2RaRatioDs, adsl2LConfTempChan2RaRatioUs, Morgenstern, et al. Standards Track [Page 145] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LConfTempChan3ConfProfile, adsl2LConfTempChan3RaRatioDs, adsl2LConfTempChan3RaRatioUs, adsl2LConfTempChan4ConfProfile, adsl2LConfTempChan4RaRatioDs, adsl2LConfTempChan4RaRatioUs, adsl2LConfTempRowStatus } STATUS current DESCRIPTION "The group of objects in a line configuration template." ::= { adsl2Groups 7 } adsl2LineConfProfGroup OBJECT-GROUP OBJECTS { adsl2LConfProfScMaskDs, adsl2LConfProfScMaskUs, adsl2LConfProfRfiBandsDs, adsl2LConfProfRaModeDs, adsl2LConfProfRaModeUs, adsl2LConfProfTargetSnrmDs, adsl2LConfProfTargetSnrmUs, adsl2LConfProfMaxSnrmDs, adsl2LConfProfMaxSnrmUs, adsl2LConfProfMinSnrmDs, adsl2LConfProfMinSnrmUs, adsl2LConfProfAtuTransSysEna, adsl2LConfProfPmMode, adsl2LConfProfL0Time, adsl2LConfProfL2Time, adsl2LConfProfL2Atpr, adsl2LConfProfL2Atprt, adsl2LConfProfRowStatus } STATUS current DESCRIPTION "The group of objects in a line configuration profile." ::= { adsl2Groups 8 } adsl2LineConfProfRaGroup OBJECT-GROUP OBJECTS { adsl2LConfProfRaUsNrmDs, adsl2LConfProfRaUsNrmUs, adsl2LConfProfRaUsTimeDs, adsl2LConfProfRaUsTimeUs, adsl2LConfProfRaDsNrmsDs, Morgenstern, et al. Standards Track [Page 146] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LConfProfRaDsNrmsUs, adsl2LConfProfRaDsTimeDs, adsl2LConfProfRaDsTimeUs } STATUS current DESCRIPTION "The group of objects required for controlling the rate- adaptive behavior of the line." ::= { adsl2Groups 9 } adsl2LineConfProfMsgMinGroup OBJECT-GROUP OBJECTS { adsl2LConfProfMsgMinUs, adsl2LConfProfMsgMinDs } STATUS current DESCRIPTION "The group of objects required for controlling the rate reserved for Overhead traffic." ::= { adsl2Groups 10 } adsl2LineConfProfModeSpecGroup OBJECT-GROUP OBJECTS { adsl2LConfProfMaxNomPsdDs, adsl2LConfProfMaxNomPsdUs, adsl2LConfProfMaxNomAtpDs, adsl2LConfProfMaxNomAtpUs, adsl2LConfProfMaxAggRxPwrUs, adsl2LConfProfPsdMaskDs, adsl2LConfProfPsdMaskUs, adsl2LConfProfPsdMaskSelectUs, adsl2LConfProfModeSpecRowStatus } STATUS current DESCRIPTION "The group of objects in a line configuration profile that have an instance for each operation mode allowed." ::= { adsl2Groups 11 } adsl2ChConfProfileGroup OBJECT-GROUP OBJECTS { adsl2ChConfProfMinDataRateDs, adsl2ChConfProfMinDataRateUs, adsl2ChConfProfMaxDataRateDs, adsl2ChConfProfMaxDataRateUs, Morgenstern, et al. Standards Track [Page 147] RFC 4706 ADSL2-LINE MIB November 2006 adsl2ChConfProfMinDataRateLowPwrDs, adsl2ChConfProfMaxDelayDs, adsl2ChConfProfMaxDelayUs, adsl2ChConfProfMinProtectionDs, adsl2ChConfProfMinProtectionUs, adsl2ChConfProfMaxBerDs, adsl2ChConfProfMaxBerUs, adsl2ChConfProfUsDataRateDs, adsl2ChConfProfDsDataRateDs, adsl2ChConfProfUsDataRateUs, adsl2ChConfProfDsDataRateUs, adsl2ChConfProfRowStatus } STATUS current DESCRIPTION "The group of objects in a channel configuration profile." ::= { adsl2Groups 12 } adsl2ChConfProfileAtmGroup OBJECT-GROUP OBJECTS { adsl2ChConfProfImaEnabled, adsl2ChStatusAtmStatus } STATUS current DESCRIPTION "The group of configuration objects required when the data path is ATM." ::= { adsl2Groups 13 } adsl2ChConfProfileMinResGroup OBJECT-GROUP OBJECTS { adsl2ChConfProfMinResDataRateDs, adsl2ChConfProfMinResDataRateUs } STATUS current DESCRIPTION "The group of configuration objects required for the reserved data rate." ::= { adsl2Groups 14 } adsl2LineAlarmConfTemplateGroup OBJECT-GROUP OBJECTS { adsl2LAlarmConfTempLineProfile, adsl2LAlarmConfTempChan1ConfProfile, adsl2LAlarmConfTempChan2ConfProfile, Morgenstern, et al. Standards Track [Page 148] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LAlarmConfTempChan3ConfProfile, adsl2LAlarmConfTempChan4ConfProfile, adsl2LAlarmConfTempRowStatus } STATUS current DESCRIPTION "The group of objects in a line alarm template." ::= { adsl2Groups 15 } adsl2LineAlarmConfProfileGroup OBJECT-GROUP OBJECTS { adsl2LineAlarmConfProfileAtucThresh15MinFecs, adsl2LineAlarmConfProfileAtucThresh15MinEs, adsl2LineAlarmConfProfileAtucThresh15MinSes, adsl2LineAlarmConfProfileAtucThresh15MinLoss, adsl2LineAlarmConfProfileAtucThresh15MinUas, adsl2LineAlarmConfProfileAturThresh15MinFecs, adsl2LineAlarmConfProfileAturThresh15MinEs, adsl2LineAlarmConfProfileAturThresh15MinSes, adsl2LineAlarmConfProfileAturThresh15MinLoss, adsl2LineAlarmConfProfileAturThresh15MinUas, adsl2LineAlarmConfProfileThresh15MinFailedFullInt, adsl2LineAlarmConfProfileThresh15MinFailedShrtInt, adsl2LineAlarmConfProfileRowStatus } STATUS current DESCRIPTION "The group of objects in a line alarm profile." ::= { adsl2Groups 16 } adsl2ChAlarmConfProfileGroup OBJECT-GROUP OBJECTS { adsl2ChAlarmConfProfileAtucThresh15MinCodingViolations, adsl2ChAlarmConfProfileAtucThresh15MinCorrected, adsl2ChAlarmConfProfileAturThresh15MinCodingViolations, adsl2ChAlarmConfProfileAturThresh15MinCorrected, adsl2ChAlarmConfProfileRowStatus } STATUS current DESCRIPTION "The group of objects in a channel alarm profile." ::= { adsl2Groups 17 } adsl2PMLineCurrGroup OBJECT-GROUP OBJECTS Morgenstern, et al. Standards Track [Page 149] RFC 4706 ADSL2-LINE MIB November 2006 { adsl2PMLCurrValidIntervals, adsl2PMLCurrInvalidIntervals, adsl2PMLCurr15MTimeElapsed, adsl2PMLCurr15MFecs, adsl2PMLCurr15MEs, adsl2PMLCurr15MSes, adsl2PMLCurr15MLoss, adsl2PMLCurr15MUas, adsl2PMLCurr1DayValidIntervals, adsl2PMLCurr1DayInvalidIntervals, adsl2PMLCurr1DayTimeElapsed, adsl2PMLCurr1DayFecs, adsl2PMLCurr1DayEs, adsl2PMLCurr1DaySes, adsl2PMLCurr1DayLoss, adsl2PMLCurr1DayUas } STATUS current DESCRIPTION "The group of objects that report the line-level counters for current PM intervals." ::= { adsl2Groups 18 } adsl2PMLineCurrInitGroup OBJECT-GROUP OBJECTS { adsl2PMLCurrInit15MTimeElapsed, adsl2PMLCurrInit15MFullInits, adsl2PMLCurrInit15MFailedFullInits, adsl2PMLCurrInit1DayTimeElapsed, adsl2PMLCurrInit1DayFullInits, adsl2PMLCurrInit1DayFailedFullInits } STATUS current DESCRIPTION "The group of objects that report the full initialization counters for current PM intervals." ::= { adsl2Groups 19 } adsl2PMLineCurrInitShortGroup OBJECT-GROUP OBJECTS { adsl2PMLCurrInit15MShortInits, adsl2PMLCurrInit15MFailedShortInits, adsl2PMLCurrInit1DayShortInits, adsl2PMLCurrInit1DayFailedShortInits } Morgenstern, et al. Standards Track [Page 150] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "The group of objects that report the short initialization counters for current PM intervals." ::= { adsl2Groups 20 } adsl2PMLineHist15MinGroup OBJECT-GROUP OBJECTS { adsl2PMLHist15MMonitoredTime, adsl2PMLHist15MFecs, adsl2PMLHist15MEs, adsl2PMLHist15MSes, adsl2PMLHist15MLoss, adsl2PMLHist15MUas, adsl2PMLHist15MValidInterval } STATUS current DESCRIPTION "The group of line-level PM counters for the previous 15-minute interval." ::= { adsl2Groups 21 } adsl2PMLineHist1DayGroup OBJECT-GROUP OBJECTS { adsl2PMLHist1DMonitoredTime, adsl2PMLHist1DFecs, adsl2PMLHist1DEs, adsl2PMLHist1DSes, adsl2PMLHist1DLoss, adsl2PMLHist1DUas, adsl2PMLHist1DValidInterval } STATUS current DESCRIPTION "The group of line-level PM counters for the previous 24-hour interval." ::= { adsl2Groups 22 } adsl2PMLineInitHist15MinGroup OBJECT-GROUP OBJECTS { adsl2PMLHistInit15MMonitoredTime, adsl2PMLHistInit15MFullInits, adsl2PMLHistInit15MFailedFullInits, adsl2PMLHistInit15MValidInterval } Morgenstern, et al. Standards Track [Page 151] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "The group of PM counters for the previous 15-minute interval's full initializations." ::= { adsl2Groups 23 } adsl2PMLineInitHist15MinShortGroup OBJECT-GROUP OBJECTS { adsl2PMLHistInit15MShortInits, adsl2PMLHistInit15MFailedShortInits } STATUS current DESCRIPTION "The group of PM counters for the previous 15-minute interval's short initializations." ::= { adsl2Groups 24 } adsl2PMLineInitHist1DayGroup OBJECT-GROUP OBJECTS { adsl2PMLHistinit1DMonitoredTime, adsl2PMLHistinit1DFullInits, adsl2PMLHistinit1DFailedFullInits, adsl2PMLHistinit1DValidInterval } STATUS current DESCRIPTION "The group of PM counters for the previous 24-hour interval's full initializations." ::= { adsl2Groups 25 } adsl2PMLineInitHist1DayShortGroup OBJECT-GROUP OBJECTS { adsl2PMLHistinit1DShortInits, adsl2PMLHistinit1DFailedShortInits } STATUS current DESCRIPTION "The group of PM counters for the previous 24-hour interval's short initializations." ::= { adsl2Groups 26 } adsl2PMChCurrGroup OBJECT-GROUP OBJECTS { adsl2PMChCurrValidIntervals, Morgenstern, et al. Standards Track [Page 152] RFC 4706 ADSL2-LINE MIB November 2006 adsl2PMChCurrInvalidIntervals, adsl2PMChCurr15MTimeElapsed, adsl2PMChCurr15MCodingViolations, adsl2PMChCurr15MCorrectedBlocks, adsl2PMChCurr1DayValidIntervals, adsl2PMChCurr1DayInvalidIntervals, adsl2PMChCurr1DayTimeElapsed, adsl2PMChCurr1DayCodingViolations, adsl2PMChCurr1DayCorrectedBlocks } STATUS current DESCRIPTION "The group of objects that report the channel-level counters for current PM intervals." ::= { adsl2Groups 27 } adsl2PMChHist15MinGroup OBJECT-GROUP OBJECTS { adsl2PMChHist15MMonitoredTime, adsl2PMChHist15MCodingViolations, adsl2PMChHist15MCorrectedBlocks, adsl2PMChHist15MValidInterval } STATUS current DESCRIPTION "The group of objects that report the channel-level counters for previous 15-minute PM intervals." ::= { adsl2Groups 28 } adsl2PMChHist1DGroup OBJECT-GROUP OBJECTS { adsl2PMChHist1DMonitoredTime, adsl2PMChHist1DCodingViolations, adsl2PMChHist1DCorrectedBlocks, adsl2PMChHist1DValidInterval } STATUS current DESCRIPTION "The group of objects that report the channel-level counters for previous 24-hour PM intervals." ::= { adsl2Groups 29 } adsl2ScalarSCGroup OBJECT-GROUP OBJECTS { adsl2ScalarSCMaxInterfaces, Morgenstern, et al. Standards Track [Page 153] RFC 4706 ADSL2-LINE MIB November 2006 adsl2ScalarSCAvailInterfaces } STATUS current DESCRIPTION "The group of objects that report the available memory resources for DELT processes." ::= { adsl2Groups 30 } adsl2ThreshNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { adsl2LinePerfFECSThreshAtuc, adsl2LinePerfFECSThreshAtur, adsl2LinePerfESThreshAtuc, adsl2LinePerfESThreshAtur, adsl2LinePerfSESThreshAtuc, adsl2LinePerfSESThreshAtur, adsl2LinePerfLOSSThreshAtuc, adsl2LinePerfLOSSThreshAtur, adsl2LinePerfUASThreshAtuc, adsl2LinePerfUASThreshAtur, adsl2LinePerfCodingViolationsThreshAtuc, adsl2LinePerfCodingViolationsThreshAtur, adsl2LinePerfCorrectedThreshAtuc, adsl2LinePerfCorrectedThreshAtur, adsl2LinePerfFailedFullInitThresh, adsl2LinePerfFailedShortInitThresh } STATUS current DESCRIPTION "This group supports notifications of significant conditions associated with ADSL/ADSL2/ADSL2+ lines." ::= { adsl2Groups 31 } adsl2StatusChangeNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { adsl2LineStatusChangeAtuc, adsl2LineStatusChangeAtur } STATUS current DESCRIPTION "This group supports notifications of threshold crossing associated with ADSL/ADSL2/ADSL2+ lines." ::= { adsl2Groups 32 } END Morgenstern, et al. Standards Track [Page 154] RFC 4706 ADSL2-LINE MIB November 2006 4. Implementation Analysis A management application intended to manage ADSL links (e.g., G.992.1) with this MIB module must be modified to adapt itself to certain differences between RFC 2662 [RFC2662] and this MIB module, including the following aspects: o Although the configuration templates/profiles allow referring to 1-4 bearer channels, ADSL links are limited to 2 channels at most. o Although the channel configuration profile allows higher data rates, ADSL links are limited to downstream/upstream data rates as assumed in RFC 2662 [RFC2662]. o The Impulse Noise Protection (INP) configuration parameters are given by minimum protection and maximum delay parameters. o The line configuration profile includes a sub-table that addresses mode-specific parameters. For ADSL links, the management application SHOULD create a row in that table for the 'adsl' mode. o The line configuration profile includes parameters that are irrelevant for ADSL links. Similarly, many status parameters in the MIB are irrelevant for certain ADSL modes. Therefore, it is advised to consult with ITU G.997.1 standard [G.997.1] regarding the scope and relevance of each parameter in this MIB. 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o adsl2LineTable The table consists of the following objects that support SET operations: * adsl2LineCnfgTemplate * adsl2LineAlarmCnfgTemplate * adsl2LineCmndConfPmsf * adsl2LineCmndConfLdsf * adsl2LineCmndAutomodeColdStart Morgenstern, et al. Standards Track [Page 155] RFC 4706 ADSL2-LINE MIB November 2006 Unauthorized changes to adsl2LineCnfgTemplate could have a major adverse operational effect on many lines simultaneously. Unauthorized changes to adsl2LineAlarmCnfgTemplate could have a contrary effect on notifications. Unauthorized changes to adsl2LineCmndConfPmsf could have an adverse affect on the power consumption of a line and may disrupt an operational service. Unauthorized changes to adsl2LineCmndConfLdsf could cause an unscheduled line test to be carried out on the line. Unauthorized changes to adsl2LineCmndAutomodeColdStart could cause an unscheduled cold reset to the line. o adsl2SCStatusTable This table contains one object, adsl2SCStatusRowStatus, that supports SET operations. Unauthorized changes could result in line test results being deleted prematurely. o adsl2LineConfTemplateTable The table consists of the following objects that support SET operations: * adsl2LConfTempLineProfile * adsl2LConfTempChan1ConfProfile * adsl2LConfTempChan1RaRatioDs * adsl2LConfTempChan1RaRatioUs * adsl2LConfTempChan2ConfProfile * adsl2LConfTempChan2RaRatioDs * adsl2LConfTempChan2RaRatioUs * adsl2LConfTempChan3ConfProfile * adsl2LConfTempChan3RaRatioDs * adsl2LConfTempChan3RaRatioUs * adsl2LConfTempChan4ConfProfile * adsl2LConfTempChan4RaRatioDs * adsl2LConfTempChan4RaRatioUs * adsl2LConfTempRowStatus Unauthorized changes to adsl2LConfTempLineProfile, adsl2LConfTempChan1ConfProfile, adsl2LConfTempChan2ConfProfile, adsl2LConfTempChan3ConfProfile, or adsl2LConfTempChan4ConfProfile could have an adverse operational effect on several lines; could Morgenstern, et al. Standards Track [Page 156] RFC 4706 ADSL2-LINE MIB November 2006 change several lines over to running in unwanted levels of operation; or could result in several services undergoing changes in the number of channels that carry the service. Unauthorized changes to adsl2LConfTempChan1RaRatioDs, adsl2LConfTempChan2RaRatioDs, adsl2LConfTempChan3RaRatioDs, or adsl2LConfTempChan4RaRatioDs, would alter the relative rate allocations among all channels belonging to a line. This could have an adverse operational effect on several lines. Unauthorized changes to adsl2LConfTempRowStatus could result in templates being created or brought into service prematurely; or could result in templates being inadvertently deleted or taken out of service. o adsl2LineConfProfTable The table consists of the following objects that support SET operations: * adsl2LConfProfScMaskDs * adsl2LConfProfScMaskUs * adsl2LConfProfRfiBandsDs * adsl2LConfProfRaModeDs * adsl2LConfProfRaModeUs * adsl2LConfProfRaUsNrmDs * adsl2LConfProfRaUsNrmUs * adsl2LConfProfRaUsTimeDs * adsl2LConfProfRaUsTimeUs * adsl2LConfProfRaDsNrmsDs * adsl2LConfProfRaDsNrmsUs * adsl2LConfProfRaDsTimeDs * adsl2LConfProfRaDsTimeUs * adsl2LConfProfTargetSnrmDs * adsl2LConfProfTargetSnrmUs * adsl2LConfProfMaxSnrmDs * adsl2LConfProfMaxSnrmUs * adsl2LConfProfMinSnrmDs * adsl2LConfProfMinSnrmUs * adsl2LConfProfMsgMinUs * adsl2LConfProfMsgMinDs * adsl2LConfProfAtuTransSysEna * adsl2LConfProfPmMode * adsl2LConfProfL0Time * adsl2LConfProfL2Time * adsl2LConfProfL2Atpr * adsl2LConfProfL2Atprt * adsl2LConfProfRowStatus Morgenstern, et al. Standards Track [Page 157] RFC 4706 ADSL2-LINE MIB November 2006 Unauthorized changes resulting in the setting of any of the above objects to an incorrect value could have an adverse operational effect on several lines. Also, unauthorized changes to adsl2LConfProfRowStatus could result in unwanted line profiles being created or brought into service prematurely; or could result in line profiles being inadvertently deleted or taken out of service. o adsl2LineConfProfModeSpecTable The table consists of the following objects that support SET operations: * adsl2LConfProfMaxNomPsdDs * adsl2LConfProfMaxNomPsdUs * adsl2LConfProfMaxNomAtpDs * adsl2LConfProfMaxNomAtpUs * adsl2LConfProfMaxAggRxPwrUs * adsl2LConfProfPsdMaskDs * adsl2LConfProfPsdMaskUs * adsl2LConfProfPsdMaskSelectUs * adsl2LConfProfModeSpecRowStatus Unauthorized changes resulting in the setting of any of the above objects to an incorrect value could have an adverse operational effect on several lines. Also, unauthorized changes to adsl2LConfProfModeSpecRowStatus could result in unwanted PSD configurations being created or brought into service prematurely; or could result in PSD configurations being inadvertently deleted or taken out of service. o adsl2ChConfProfileTable The table consists of the following objects that support SET operations: * adsl2ChConfProfMinDataRateDs * adsl2ChConfProfMinDataRateUs * adsl2ChConfProfMinResDataRateDs * adsl2ChConfProfMinResDataRateUs * adsl2ChConfProfMaxDataRateDs * adsl2ChConfProfMaxDataRateUs * adsl2ChConfProfMinDataRateLowPwrDs * adsl2ChConfProfMaxDelayDs * adsl2ChConfProfMaxDelayUs Morgenstern, et al. Standards Track [Page 158] RFC 4706 ADSL2-LINE MIB November 2006 * adsl2ChConfProfMinProtectionDs * adsl2ChConfProfMinProtectionUs * adsl2ChConfProfMaxBerDs * adsl2ChConfProfMaxBerUs * adsl2ChConfProfUsDataRateDs * adsl2ChConfProfDsDataRateDs * adsl2ChConfProfUsDataRateUs * adsl2ChConfProfDsDataRateUs * adsl2ChConfProfImaEnabled * adsl2ChConfProfRowStatus Unauthorized changes resulting in the setting of any of the above objects to an incorrect value could have an adverse operational effect on several lines. Also, unauthorized changes to adsl2ChConfProfRowStatus could result in unwanted channel profiles being created or brought into service prematurely; or could result in channel profiles being inadvertently deleted or taken out of service. o adsl2LineAlarmConfTemplateTable The table consists of the following objects that support SET operations: * adsl2LAlarmConfTempLineProfile * adsl2LAlarmConfTempChan1ConfProfile * adsl2LalarmConfTempChan2ConfProfile * adsl2LalarmConfTempChan3ConfProfile * adsl2LalarmConfTempChan4ConfProfile * adsl2LAlarmConfTempRowStatus Unauthorized changes to adsl2LAlarmConfTempLineProfile, adsl2LAlarmConfTempChan1ConfProfile, adsl2LAlarmConfTempChan2ConfProfile, adsl2LAlarmConfTempChan3ConfProfile, or adsl2LAlarmConfTempChan4ConfProfile could have an adverse effect on the management of notifications generated at the scope of several to many lines; or could change several to many lines over to running with unwanted management rates for generated notifications. Unauthorized changes to adsl2LAlarmConfTempRowStatus could result in alarm templates being created or brought into service prematurely; or could result in alarm templates being inadvertently deleted or taken out of service. Morgenstern, et al. Standards Track [Page 159] RFC 4706 ADSL2-LINE MIB November 2006 o adsl2LineAlarmConfProfileTable The table consists of the following objects that support SET operations: * adsl2LineAlarmConfProfileAtucThresh15MinFecs * adsl2LineAlarmConfProfileAtucThresh15MinEs * adsl2LineAlarmConfProfileAtucThresh15MinSes * adsl2LineAlarmConfProfileAtucThresh15MinLoss * adsl2LineAlarmConfProfileAtucThresh15MinUas * adsl2LineAlarmConfProfileAturThresh15MinFecs * adsl2LineAlarmConfProfileAturThresh15MinEs * adsl2LineAlarmConfProfileAturThresh15MinSes * adsl2LineAlarmConfProfileAturThresh15MinLoss * adsl2LineAlarmConfProfileAturThresh15MinUas * adsl2LineAlarmConfProfileThresh15MinFailedFullInt * adsl2LineAlarmConfProfileThresh15MinFailedShrtInt * adsl2LineAlarmConfProfileRowStatus Increasing any of the threshold values could result in a notification being suppressed or deferred. Setting a threshold to 0 could result in a notification being suppressed. Suppressing or deferring a notification could prevent the timely delivery of important diagnostic information. Decreasing any of the threshold values could result in a notification being sent from the network falsely reporting a threshold crossing. Changing a threshold value could also have an impact on the amount of notifications the agent sends. The Notifications Section of this document has a paragraph that provides general guidance on the rate-limiting of notifications. Agent implementations not providing rate-limiting could result in notifications being generated at an uncontrolled rate. Unauthorized changes to a threshold value could result in an undesired notification rate. Unauthorized changes to row status could result in unwanted line alarm profiles being created or brought into service. Also, changes to the row status could result in line alarm profiles being inadvertently deleted or taken out of service. o adsl2ChAlarmConfProfileTable The table consists of the following objects that support SET operations: Morgenstern, et al. Standards Track [Page 160] RFC 4706 ADSL2-LINE MIB November 2006 * adsl2ChAlarmConfProfileAtucThresh15MinCodingViolations * adsl2ChAlarmConfProfileAtucThresh15MinCorrected * adsl2ChAlarmConfProfileAturThresh15MinCodingViolations * adsl2ChAlarmConfProfileAturThresh15MinCorrected * adsl2ChAlarmConfProfileRowStatus * adsl2LineAlarmConfProfileAturThresh15MinFecs * adsl2LineAlarmConfProfileAturThresh15MinEs * adsl2LineAlarmConfProfileAturThresh15MinSes * adsl2LineAlarmConfProfileAturThresh15MinLoss * adsl2LineAlarmConfProfileAturThresh15MinUas * adsl2LineAlarmConfProfileThresh15MinFailedFullInt * adsl2LineAlarmConfProfileThresh15MinFailedShrtInt * adsl2LineAlarmConfProfileRowStatus Increasing any of the threshold values could result in a notification being suppressed or deferred. Setting a threshold to 0 could result in a notification being suppressed. Suppressing or deferring a notification could prevent the timely delivery of important diagnostic information. Decreasing any of the threshold values could result in a notification being sent from the network falsely reporting a threshold crossing. Changing a threshold value could also have an impact on the amount of notifications the agent sends. The Notifications Section of this document has a paragraph that provides general guidance on the rate-limiting of notifications. Agent implementations not providing rate-limiting could result in notifications being generated at an uncontrolled rate. Unauthorized changes to a threshold value could result in an undesired notification rate. Unauthorized changes to row status could result in unwanted channel alarm profiles being created or brought into service. Also, changes to the row status could result in channel alarm profiles being inadvertently deleted or taken out of service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Morgenstern, et al. Standards Track [Page 161] RFC 4706 ADSL2-LINE MIB November 2006 o adsl2LineInventoryTable Access to these objects would allow an intruder to obtain information about which vendor's equipment is in use on the network. Further, such information is considered sensitive in many environments for competitive reasons. * adsl2LInvG994VendorId * adsl2LInvSystemVendorId * adsl2LInvVersionNumber * adsl2LInvSerialNumber * adsl2LInvSelfTestResult * adsl2LInvTransmissionCapabilities SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). It is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access only to those objects whose principals (users) have legitimate rights to indeed GET or SET (change/create/delete) them. Morgenstern, et al. Standards Track [Page 162] RFC 4706 ADSL2-LINE MIB November 2006 6. Acknowledgements The authors are deeply grateful to the authors of the HDSL2 LINE MIB (RFC 4319), Clay Sikes and Bob Ray, for contributing to accelerating the work on this document. The structure of this document as well as several paragraphs originate in their document. Special thanks to Bert Wijnen for his meticulous review of this text. Other contributions and advice were received from the following: Bert Wijnen (Lucent) Bob Ray (Pesa) Chen Jian (Huawei) Clay Sikes (Zhone) Mauro Molinari (Marconi) Narendranath Nair (Wipro) Randy Presuhn (Mindspring) Veena Naidu (Wipro) 7. References 7.1. Normative References [G.992.1] "Asymmetric digital subscriber line (ADSL) transceivers", ITU-T G.992.1, 1999. [G.992.2] "Splitterless asymmetric digital subscriber line (ADSL) transceivers", ITU-T G.992.2, 1999. [G.992.3] "Asymmetric digital subscriber line transceivers 2 (ADSL2)", ITU-T G.992.3, 2002. [G.992.4] "Splitterless asymmetric digital subscriber line transceivers 2 (Splitterless ADSL2)", ITU-T G.992.4, 2002. [G.992.5] "Asymmetric digital subscriber line (ADSL) transceivers - Extended bandwidth ADSL2 (ADSL2+)", ITU-T G.992.5, 2003. [G.993.2] "Very-high speed Digital Subscriber Line Transceivers 2 (VDSL2 draft)", ITU-T G.993.2, July 2005. [G.997.1] "Physical layer management for digital subscriber line (DSL) transceivers", ITU-T G.997.1, May 2003. Morgenstern, et al. Standards Track [Page 163] RFC 4706 ADSL2-LINE MIB November 2006 [G.997.1am1] "Physical layer management for digital subscriber line (DSL) transceivers Amendment 1", ITU-T G.997.1 Amendment 1, December 2003. [G.997.1am2] "Physical layer management for digital subscriber line (DSL) transceivers Amendment 2", ITU-T G.997.1 Amendment 2, January 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, February 2004. [T1E1.413] J. Bingham & F. Van der Putten, "Network and Customer Installation Interfaces - Asymmetric Digital Subscriber Line (ADSL) Metallic Interface. (T1.413 Issue 2)", ANSI T1E1.413-1998, June 1998. Morgenstern, et al. Standards Track [Page 164] RFC 4706 ADSL2-LINE MIB November 2006 [TR-90] Abbi, R., "Protocol Independent Object Model for Managing Next Generation ADSL Technologies", DSL Forum TR-90, December 2004. 7.2. Informative References [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, August 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Morgenstern, et al. Standards Track [Page 165] RFC 4706 ADSL2-LINE MIB November 2006 Authors' Addresses Moti Morgenstern ECI Telecom Ltd. 30 Hasivim St. Petach Tikva 49517 Israel Phone: +972 3 926 6258 Fax: +972 3 928 7342 EMail: moti.Morgenstern@ecitele.com Menachem Dodge ECI Telecom Ltd. 30 Hasivim St. Petach Tikva 49517 Israel Phone: +972 3 926 8421 Fax: +972 3 928 7342 EMail: mbdodge@ieee.org Scott Baillie NEC Australia 649-655 Springvale Road Mulgrave, Victoria 3170 Australia Phone: +61 3 9264 3986 Fax: +61 3 9264 3892 EMail: scott.baillie@nec.com.au Umberto Bonollo NEC Australia 649-655 Springvale Road Mulgrave, Victoria 3170 Australia Phone: +61 3 9264 3385 Fax: +61 3 9264 3892 EMail: umberto.bonollo@nec.com.au Morgenstern, et al. Standards Track [Page 166] RFC 4706 ADSL2-LINE MIB November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Morgenstern, et al. Standards Track [Page 167] snmp-mibs-downloader-1.1/mibrfcs/rfc4711.txt0000644000000000000000000022703511402176072015570 0ustar Network Working Group A. Siddiqui Request for Comments: 4711 D. Romascanu Category: Standards Track Avaya E. Golovinsky Alert Logic October 2006 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB, RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. RAQMON Framework ................................................2 4. Structure of the RAQMON MIB .....................................2 5. RAQMON MIB Definitions ..........................................3 6. Security Considerations ........................................33 7. IANA Considerations ............................................35 8. Acknowledgements ...............................................35 9. Normative References ...........................................36 10. Informative References ........................................36 Siddiqui, et al. Standards Track [Page 1] RFC 4711 RAQMON MIB October 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends [RFC2819] with managed objects used for real-time application QoS monitoring. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. RAQMON Framework As outlined in [RFC4710], the RAQMON framework is based on three entities: - RAQMON Data Source (RDS) - RAQMON Report Collector (RRC) - RAQMON MIB Structure The RAQMON MIB describes information passed between RRCs and a RAQMON Application ("RAQMON manager"). 4. Structure of the RAQMON MIB The RAQMON MIB module is composed of three MIB groups: raqmonSession, raqmonException, and raqmonConfig. The raqmonSession MIB group incorporates the following tables: Siddiqui, et al. Standards Track [Page 2] RFC 4711 RAQMON MIB October 2006 - The raqmonParticpantTable contains information about participants in open and closed (terminated) sessions, including parameters of the sessions they are involved in, aggregated since the beginning of the session. - The raqmonQosTable contains historical information about QoS during sessions. The set of parameters represented in this table is more restricted, but it includes historical per- RAQMON-report information. - The raqmonParticpantAddrTable maps participant addresses into the indices of the raqmonParticpantTable. This table allows management applications to find entries sorted by raqmonParticipantAddr rather than raqmonParticipantStartDate. The raqmonException MIB group includes a table of filters that trigger notifications for sessions with poor QoS. The raqmonConfig MIB group includes objects that define the configuration of the RAQMON Report Collector. This MIB module MUST be implemented by RAQMON Report Collectors. A separate MIB module is defined in [RFC4712] for mapping the RAQMON PDUs onto an SNMP transport. The MIB module defined in [RFC4712] is normally implemented by RAQMON Data Sources (RDS). 5. RAQMON MIB Definitions The MIB module herein IMPORTS definitions from the following: SNMPv2-SMI [RFC2578] SNMPv2-TC [RFC2579] SNMPv2-CONF [RFC2580] RMON-MIB [RFC2819] SNMP-FRAMEWORK-MIB [RFC3411] INET-ADDRESS-MIB [RFC4001] It also uses REFERENCE clauses to refer to [RFC4710]. It also mentions [RFC3737] with respect to the MODULE-IDENTITY OID allocation. Siddiqui, et al. Standards Track [Page 3] RFC 4711 RAQMON MIB October 2006 RAQMON-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF Integer32, Unsigned32, Gauge32, Counter32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB rmon FROM RMON-MIB RowStatus, TruthValue, DateAndTime, RowPointer FROM SNMPv2-TC; raqmonMIB MODULE-IDENTITY LAST-UPDATED "200610100000Z" -- October 10, 2006 ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/rmonmib-charter.html Mailing lists: General Discussion: rmonmib@ietf.org To Subscribe: rmonmib-requests@ietf.org In Body: subscribe your_email_address Chair: Andy Bierman Email: ietf@andybierman.com Editor: Dan Romascanu Avaya Email: dromasca@avaya.com" DESCRIPTION "Real-Time Application QoS Monitoring MIB. Copyright (c) The Internet Society (2006). This version of this MIB module is part of RFC 4711; See the RFC itself for full legal notices." REVISION "200610100000Z" DESCRIPTION "Initial version, published as RFC 4711." ::= { rmon 31 } -- This OID allocation conforms to [RFC3737] Siddiqui, et al. Standards Track [Page 4] RFC 4711 RAQMON MIB October 2006 -- -- Node definitions -- raqmonNotifications OBJECT IDENTIFIER ::= { raqmonMIB 0 } raqmonSessionAlarm NOTIFICATION-TYPE OBJECTS { raqmonParticipantAddr, raqmonParticipantName, raqmonParticipantPeerAddrType, raqmonParticipantPeerAddr, raqmonQoSEnd2EndNetDelay, raqmonQoSInterArrivalJitter, raqmonQosLostPackets, raqmonQosRcvdPackets } STATUS current DESCRIPTION "A notification generated by an entry in the raqmonSessionExceptionTable." ::= { raqmonNotifications 1 } raqmonMIBObjects OBJECT IDENTIFIER ::= { raqmonMIB 1 } raqmonSession OBJECT IDENTIFIER ::= { raqmonMIBObjects 1 } raqmonParticipantTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonParticipantEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about participants in both active and closed (terminated) sessions." ::= { raqmonSession 1 } raqmonParticipantEntry OBJECT-TYPE SYNTAX RaqmonParticipantEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row contains information for a single session (application) run by one participant. Indexation by the start time of the session aims to ease sorting by management applications. Agents MUST NOT report identical start times for any two sessions on the same host. Rows are removed for inactive sessions when implementation-specific age or space limits are reached." Siddiqui, et al. Standards Track [Page 5] RFC 4711 RAQMON MIB October 2006 INDEX { raqmonParticipantStartDate, raqmonParticipantIndex } ::= { raqmonParticipantTable 1 } RaqmonParticipantEntry ::= SEQUENCE { raqmonParticipantStartDate DateAndTime, raqmonParticipantIndex Unsigned32, raqmonParticipantReportCaps BITS, raqmonParticipantAddrType InetAddressType, raqmonParticipantAddr InetAddress, raqmonParticipantSendPort InetPortNumber, raqmonParticipantRecvPort InetPortNumber, raqmonParticipantSetupDelay Integer32, raqmonParticipantName SnmpAdminString, raqmonParticipantAppName SnmpAdminString, raqmonParticipantQosCount Gauge32, raqmonParticipantEndDate DateAndTime, raqmonParticipantDestPayloadType Integer32, raqmonParticipantSrcPayloadType Integer32, raqmonParticipantActive TruthValue, raqmonParticipantPeer RowPointer, raqmonParticipantPeerAddrType InetAddressType, raqmonParticipantPeerAddr InetAddress, raqmonParticipantSrcL2Priority Integer32, raqmonParticipantDestL2Priority Integer32, raqmonParticipantSrcDSCP Integer32, raqmonParticipantDestDSCP Integer32, raqmonParticipantCpuMean Integer32, raqmonParticipantCpuMin Integer32, raqmonParticipantCpuMax Integer32, raqmonParticipantMemoryMean Integer32, raqmonParticipantMemoryMin Integer32, raqmonParticipantMemoryMax Integer32, raqmonParticipantNetRTTMean Integer32, raqmonParticipantNetRTTMin Integer32, raqmonParticipantNetRTTMax Integer32, raqmonParticipantIAJitterMean Integer32, raqmonParticipantIAJitterMin Integer32, raqmonParticipantIAJitterMax Integer32, raqmonParticipantIPDVMean Integer32, raqmonParticipantIPDVMin Integer32, raqmonParticipantIPDVMax Integer32, raqmonParticipantNetOwdMean Integer32, raqmonParticipantNetOwdMin Integer32, raqmonParticipantNetOwdMax Integer32, raqmonParticipantAppDelayMean Integer32, raqmonParticipantAppDelayMin Integer32, raqmonParticipantAppDelayMax Integer32, Siddiqui, et al. Standards Track [Page 6] RFC 4711 RAQMON MIB October 2006 raqmonParticipantPacketsRcvd Integer32, raqmonParticipantPacketsSent Integer32, raqmonParticipantOctetsRcvd Integer32, raqmonParticipantOctetsSent Integer32, raqmonParticipantLostPackets Integer32, raqmonParticipantLostPacketsFrct Integer32, raqmonParticipantDiscards Integer32, raqmonParticipantDiscardsFrct Integer32 } raqmonParticipantStartDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The date and time of this entry. It will be the date and time of the first report received." ::= { raqmonParticipantEntry 1 } raqmonParticipantIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the conceptual row, which is for SNMP purposes only and has no relation to any protocol value. There is no requirement that these rows be created or maintained sequentially. The index will be unique for a particular date and time." ::= { raqmonParticipantEntry 2 } raqmonParticipantReportCaps OBJECT-TYPE SYNTAX BITS { raqmonPartRepDsrcName(0), raqmonPartRepRecvName(1), raqmonPartRepDsrcPort(2), raqmonPartRepRecvPort(3), raqmonPartRepSetupTime(4), raqmonPartRepSetupDelay(5), raqmonPartRepSessionDuration(6), raqmonPartRepSetupStatus(7), raqmonPartRepRTEnd2EndNetDelay(8), raqmonPartRepOWEnd2EndNetDelay(9), raqmonPartApplicationDelay(10), raqmonPartRepIAJitter(11), raqmonPartRepIPDV(12), Siddiqui, et al. Standards Track [Page 7] RFC 4711 RAQMON MIB October 2006 raqmonPartRepRcvdPackets(13), raqmonPartRepRcvdOctets(14), raqmonPartRepSentPackets(15), raqmonPartRepSentOctets(16), raqmonPartRepCumPacketsLoss(17), raqmonPartRepFractionPacketsLoss(18), raqmonPartRepCumDiscards(19), raqmonPartRepFractionDiscards(20), raqmonPartRepSrcPayloadType(21), raqmonPartRepDestPayloadType(22), raqmonPartRepSrcLayer2Priority(23), raqmonPartRepSrcTosDscp(24), raqmonPartRepDestLayer2Priority(25), raqmonPartRepDestTosDscp(26), raqmonPartRepCPU(27), raqmonPartRepMemory(28), raqmonPartRepAppName(29) } MAX-ACCESS read-only STATUS current DESCRIPTION "The Report capabilities of the participant, as perceived by the Collector. If the participant can report the Data Source Name as defined in [RFC4710], Section 5.3, then the raqmonPartRepDsrcName bit will be set. If the participant can report the Receiver Name as defined in [RFC4710], Section 5.4, then the raqmonPartRepRecvName bit will be set. If the participant can report the Data Source Port as defined in [RFC4710], Section 5.5, then the raqmonPartRepDsrcPort bit will be set. If the participant can report the Receiver Port as defined in [RFC4710], Section 5.6, then the raqmonPartRepRecvPort bit will be set. If the participant can report the Session Setup Time as defined in [RFC4710], Section 5.7, then the raqmonPartRepSetupTime bit will be set. If the participant can report the Session Setup Delay as defined in [RFC4710], Section 5.8, then the raqmonPartRepSetupDelay bit will be set. Siddiqui, et al. Standards Track [Page 8] RFC 4711 RAQMON MIB October 2006 If the participant can report the Session Duration as defined in [RFC4710], Section 5.9, then the raqmonPartRepSessionDuration bit will be set. If the participant can report the Setup Status as defined in [RFC4710], Section 5.10, then the raqmonPartRepSetupStatus bit will be set. If the participant can report the Round-Trip End-to-end Network Delay as defined in [RFC4710], Section 5.11, then the raqmonPartRepRTEnd2EndNetDelay bit will be set. If the participant can report the One-way End-to-end Network Delay as defined in [RFC4710], Section 5.12, then the raqmonPartRepOWEnd2EndNetDelay bit will be set. If the participant can report the Application Delay as defined in [RFC4710], Section 5.13, then the raqmonPartApplicationDelay bit will be set. If the participant can report the Inter-Arrival Jitter as defined in [RFC4710], Section 5.14, then the raqmonPartRepIAJitter bit will be set. If the participant can report the IP Packet Delay Variation as defined in [RFC4710], Section 5.15, then the raqmonPartRepIPDV bit will be set. If the participant can report the number of application packets received as defined in [RFC4710], Section 5.16, then the raqmonPartRepRcvdPackets bit will be set. If the participant can report the number of application octets received as defined in [RFC4710], Section 5.17, then the raqmonPartRepRcvdOctets bit will be set. If the participant can report the number of application packets sent as defined in [RFC4710], Section 5.18, then the raqmonPartRepSentPackets bit will be set. If the participant can report the number of application octets sent as defined in [RFC4710], Section 5.19, then the raqmonPartRepSentOctets bit will be set. If the participant can report the number of cumulative packets lost as defined in [RFC4710], Section 5.20, then the raqmonPartRepCumPacketsLoss bit will be set. Siddiqui, et al. Standards Track [Page 9] RFC 4711 RAQMON MIB October 2006 If the participant can report the fraction of packet loss as defined in [RFC4710], Section 5.21, then the raqmonPartRepFractionPacketsLoss bit will be set. If the participant can report the number of cumulative discards as defined in [RFC4710], Section 5.22, then the raqmonPartRepCumDiscards bit will be set. If the participant can report the fraction of discards as defined in [RFC4710], Section 5.23, then the raqmonPartRepFractionDiscards bit will be set. If the participant can report the Source Payload Type as defined in [RFC4710], Section 5.24, then the raqmonPartRepSrcPayloadType bit will be set. If the participant can report the Destination Payload Type as defined in [RFC4710], Section 5.25, then the raqmonPartRepDestPayloadType bit will be set. If the participant can report the Source Layer 2 Priority as defined in [RFC4710], Section 5.26, then the raqmonPartRepSrcLayer2Priority bit will be set. If the participant can report the Source DSCP/ToS value as defined in [RFC4710], Section 5.27, then the raqmonPartRepSrcToSDscp bit will be set. If the participant can report the Destination Layer 2 Priority as defined in [RFC4710], Section 5.28, then the raqmonPartRepDestLayer2Priority bit will be set. If the participant can report the Destination DSCP/ToS Value as defined in [RFC4710], Section 5.29, then the raqmonPartRepDestToSDscp bit will be set. If the participant can report the CPU utilization as defined in [RFC4710], Section 5.30, then the raqmonPartRepCPU bit will be set. If the participant can report the memory utilization as defined in [RFC4710], Section 5.31, then the raqmonPartRepMemory bit will be set. If the participant can report the Application Name as defined in [RFC4710], Section 5.32, then the raqmonPartRepAppName bit will be set. Siddiqui, et al. Standards Track [Page 10] RFC 4711 RAQMON MIB October 2006 The capability of reporting of a specific metric does not mandate that the metric must be reported permanently by the data source to the respective collector. Some data sources MAY be configured not to send a metric, or some metrics may not be relevant to the specific application." ::= { raqmonParticipantEntry 3 } raqmonParticipantAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the Internet address of the participant for this session." ::= { raqmonParticipantEntry 4 } raqmonParticipantAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet Address of the participant for this session. Formatting of this object is determined by the value of raqmonParticipantAddrType." ::= { raqmonParticipantEntry 5 } raqmonParticipantSendPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "Port from which session data is sent. If the value was not reported to the collector, this object will have the value 0." REFERENCE "Section 5.5 of the [RFC4710]" ::= { raqmonParticipantEntry 6 } raqmonParticipantRecvPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "Port on which session data is received. If the value was not reported to the collector, this object will have the value 0." REFERENCE Siddiqui, et al. Standards Track [Page 11] RFC 4711 RAQMON MIB October 2006 "Section 5.6 of the [RFC4710]" ::= { raqmonParticipantEntry 7 } raqmonParticipantSetupDelay OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Session setup time. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.8 of the [RFC4710]" ::= { raqmonParticipantEntry 8 } raqmonParticipantName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The data source name for the participant." REFERENCE "Section 5.3 of the [RFC4710]" ::= { raqmonParticipantEntry 9 } raqmonParticipantAppName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A string giving the name and possibly the version of the application generating the stream, e.g., 'videotool 1.2.' This information may be useful for debugging purposes and is similar to the Mailer or Mail-System-Version SMTP headers. The tool value is expected to remain constant for the duration of the session." REFERENCE "Section 5.32 of the [RFC4710]" ::= { raqmonParticipantEntry 10 } raqmonParticipantQosCount OBJECT-TYPE SYNTAX Gauge32 UNITS "entries" MAX-ACCESS read-only STATUS current Siddiqui, et al. Standards Track [Page 12] RFC 4711 RAQMON MIB October 2006 DESCRIPTION "The current number of entries in the raqmonQosTable for this participant and session." ::= { raqmonParticipantEntry 11 } raqmonParticipantEndDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time of the most recent report received." ::= { raqmonParticipantEntry 12 } raqmonParticipantDestPayloadType OBJECT-TYPE SYNTAX Integer32 (-1|0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination Payload Type. If the value was not reported to the collector, this object will have the value -1." REFERENCE "RFC 3551 and Section 5.25 of the [RFC4710]" ::= { raqmonParticipantEntry 13 } raqmonParticipantSrcPayloadType OBJECT-TYPE SYNTAX Integer32 (-1|0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Source Payload Type. If the value was not reported to the collector, this object will have the value -1." REFERENCE "RFC 3551 and Section 5.24 of the [RFC4710]" ::= { raqmonParticipantEntry 14 } raqmonParticipantActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Value 'true' indicates that the session for this participant is active (open). Value 'false' indicates that the session is closed (terminated)." ::= { raqmonParticipantEntry 15 } Siddiqui, et al. Standards Track [Page 13] RFC 4711 RAQMON MIB October 2006 raqmonParticipantPeer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "The pointer to the corresponding entry in this table for the other peer participant. If there is no such entry in the participant table of the collector represented by this SNMP agent, then the value will be { 0 0 }. " ::= { raqmonParticipantEntry 16 } raqmonParticipantPeerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the Internet address of the peer participant for this session." ::= { raqmonParticipantEntry 17 } raqmonParticipantPeerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet Address of the peer participant for this session. Formatting of this object is determined by the value of raqmonParticipantPeerAddrType." ::= { raqmonParticipantEntry 18 } raqmonParticipantSrcL2Priority OBJECT-TYPE SYNTAX Integer32 (-1|0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "Source Layer 2 Priority. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.26 of the [RFC4710]" ::= { raqmonParticipantEntry 19 } raqmonParticipantDestL2Priority OBJECT-TYPE SYNTAX Integer32 (-1|0..7) MAX-ACCESS read-only STATUS current DESCRIPTION Siddiqui, et al. Standards Track [Page 14] RFC 4711 RAQMON MIB October 2006 "Destination Layer 2 Priority. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.28 of the [RFC4710]" ::= { raqmonParticipantEntry 20 } raqmonParticipantSrcDSCP OBJECT-TYPE SYNTAX Integer32 (-1|0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "Source Layer 3 DSCP value. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.27 of the [RFC4710]" ::= { raqmonParticipantEntry 21 } raqmonParticipantDestDSCP OBJECT-TYPE SYNTAX Integer32 (-1|0..63) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination Layer 3 DSCP value." REFERENCE "Section 5.29 of the [RFC4710]" ::= { raqmonParticipantEntry 22 } raqmonParticipantCpuMean OBJECT-TYPE SYNTAX Integer32 (-1|0..100) UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION "Mean CPU utilization. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.30 of the [RFC4710]" ::= { raqmonParticipantEntry 23 } raqmonParticipantCpuMin OBJECT-TYPE SYNTAX Integer32 (-1|0..100) UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION Siddiqui, et al. Standards Track [Page 15] RFC 4711 RAQMON MIB October 2006 "Minimum CPU utilization. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.30 of the [RFC4710]" ::= { raqmonParticipantEntry 24 } raqmonParticipantCpuMax OBJECT-TYPE SYNTAX Integer32 (-1|0..100) UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum CPU utilization. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.30 of the [RFC4710]" ::= { raqmonParticipantEntry 25 } raqmonParticipantMemoryMean OBJECT-TYPE SYNTAX Integer32 (-1|0..100) UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION "Mean memory utilization. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.31 of the [RFC4710]" ::= { raqmonParticipantEntry 26 } raqmonParticipantMemoryMin OBJECT-TYPE SYNTAX Integer32 (-1|0..100) UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum memory utilization. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.31 of the [RFC4710]" ::= { raqmonParticipantEntry 27 } raqmonParticipantMemoryMax OBJECT-TYPE SYNTAX Integer32 (-1|0..100) Siddiqui, et al. Standards Track [Page 16] RFC 4711 RAQMON MIB October 2006 UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum memory utilization. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.31 of the [RFC4710]" ::= { raqmonParticipantEntry 28 } raqmonParticipantNetRTTMean OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Mean round-trip end-to-end network delay over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.11 of the [RFC4710]" ::= { raqmonParticipantEntry 29 } raqmonParticipantNetRTTMin OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum round-trip end-to-end network delay over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.11 of the [RFC4710]" ::= { raqmonParticipantEntry 30 } raqmonParticipantNetRTTMax OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum round-trip end-to-end network delay over the entire session. If the value was not reported to the collector, Siddiqui, et al. Standards Track [Page 17] RFC 4711 RAQMON MIB October 2006 this object will have the value -1." REFERENCE "Section 5.11 of the [RFC4710]" ::= { raqmonParticipantEntry 31 } raqmonParticipantIAJitterMean OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Mean inter-arrival jitter over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.14 of the [RFC4710]" ::= { raqmonParticipantEntry 32 } raqmonParticipantIAJitterMin OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum inter-arrival jitter over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.14 of the [RFC4710]" ::= { raqmonParticipantEntry 33 } raqmonParticipantIAJitterMax OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum inter-arrival jitter over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.14 of the [RFC4710]" ::= { raqmonParticipantEntry 34 } raqmonParticipantIPDVMean OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only Siddiqui, et al. Standards Track [Page 18] RFC 4711 RAQMON MIB October 2006 STATUS current DESCRIPTION "Mean IP packet delay variation over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.15 of the [RFC4710]" ::= { raqmonParticipantEntry 35 } raqmonParticipantIPDVMin OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum IP packet delay variation over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.15 of the [RFC4710]" ::= { raqmonParticipantEntry 36 } raqmonParticipantIPDVMax OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum IP packet delay variation over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.15 of the [RFC4710]" ::= { raqmonParticipantEntry 37 } raqmonParticipantNetOwdMean OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Mean Network one-way delay over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.12 of the [RFC4710]" ::= { raqmonParticipantEntry 38 } Siddiqui, et al. Standards Track [Page 19] RFC 4711 RAQMON MIB October 2006 raqmonParticipantNetOwdMin OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum Network one-way delay over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.12 of the [RFC4710]" ::= { raqmonParticipantEntry 39 } raqmonParticipantNetOwdMax OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Network one-way delay over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.1 of the [RFC4710]" ::= { raqmonParticipantEntry 40 } raqmonParticipantAppDelayMean OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Mean application delay over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.13 of the [RFC4710]" ::= { raqmonParticipantEntry 41 } raqmonParticipantAppDelayMin OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum application delay over the entire session. If the value was not reported to the collector, this object will have the value -1." Siddiqui, et al. Standards Track [Page 20] RFC 4711 RAQMON MIB October 2006 REFERENCE "Section 5.13 of the [RFC4710]" ::= { raqmonParticipantEntry 42 } raqmonParticipantAppDelayMax OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum application delay over the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.13 of the [RFC4710]" ::= { raqmonParticipantEntry 43 } raqmonParticipantPacketsRcvd OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets received for the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.16 of the [RFC4710]" ::= { raqmonParticipantEntry 44 } raqmonParticipantPacketsSent OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets sent for the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.17 of the [RFC4710]" ::= { raqmonParticipantEntry 45 } raqmonParticipantOctetsRcvd OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "Octets" MAX-ACCESS read-only STATUS current Siddiqui, et al. Standards Track [Page 21] RFC 4711 RAQMON MIB October 2006 DESCRIPTION "Count of octets received for the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.18 of the [RFC4710]" ::= { raqmonParticipantEntry 46 } raqmonParticipantOctetsSent OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "Octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of octets sent for the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.19 of the [RFC4710]" ::= { raqmonParticipantEntry 47 } raqmonParticipantLostPackets OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets lost by this receiver for the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.20 of the [RFC4710]" ::= { raqmonParticipantEntry 48 } raqmonParticipantLostPacketsFrct OBJECT-TYPE SYNTAX Integer32 (-1|0..100) UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION "Fraction of lost packets out of total packets received. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.21 of the [RFC4710]" ::= { raqmonParticipantEntry 49 } Siddiqui, et al. Standards Track [Page 22] RFC 4711 RAQMON MIB October 2006 raqmonParticipantDiscards OBJECT-TYPE SYNTAX Integer32 (-1|0..2147483647) UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets discarded by this receiver for the entire session. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.22 of the [RFC4710]" ::= { raqmonParticipantEntry 50 } raqmonParticipantDiscardsFrct OBJECT-TYPE SYNTAX Integer32 (-1|0..100) UNITS "percents" MAX-ACCESS read-only STATUS current DESCRIPTION "Fraction of discarded packets out of total packets received. If the value was not reported to the collector, this object will have the value -1." REFERENCE "Section 5.23 of the [RFC4710]" ::= { raqmonParticipantEntry 51 } raqmonQosTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonQosEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of historical information about quality-of-service data during sessions." ::= { raqmonSession 2 } raqmonQosEntry OBJECT-TYPE SYNTAX RaqmonQosEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information from a single RAQMON packet, related to a single session (application) run by one participant. Indexation by the start time of the session aims to ease sorting by management applications. Agents MUST NOT report identical start times for any two sessions Siddiqui, et al. Standards Track [Page 23] RFC 4711 RAQMON MIB October 2006 on the same host. Rows are removed for inactive sessions when implementation-specific time or space limits are reached." INDEX { raqmonParticipantStartDate, raqmonParticipantIndex, raqmonQosTime } ::= { raqmonQosTable 1 } RaqmonQosEntry ::= SEQUENCE { raqmonQosTime Unsigned32, raqmonQoSEnd2EndNetDelay Integer32, raqmonQoSInterArrivalJitter Integer32, raqmonQosRcvdPackets Integer32, raqmonQosRcvdOctets Integer32, raqmonQosSentPackets Integer32, raqmonQosSentOctets Integer32, raqmonQosLostPackets Integer32, raqmonQosSessionStatus SnmpAdminString } raqmonQosTime OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) UNITS "seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION "Time of this entry measured from the start of the corresponding participant session." ::= { raqmonQosEntry 1 } raqmonQoSEnd2EndNetDelay OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The round-trip time. Will contain the previous value if there was no report for this time, or -1 if the value has never been reported." REFERENCE "Section 5.11 of the [RFC4710]" ::= { raqmonQosEntry 2 } raqmonQoSInterArrivalJitter OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) Siddiqui, et al. Standards Track [Page 24] RFC 4711 RAQMON MIB October 2006 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of delay variation as observed by this receiver. Will contain the previous value if there was no report for this time, or -1 if the value has never been reported." REFERENCE "Section 5.14 of the [RFC4710]" ::= { raqmonQosEntry 3 } raqmonQosRcvdPackets OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets received by this receiver since the previous entry. Will contain the previous value if there was no report for this time, or -1 if the value has never been reported." REFERENCE "Section 5.16 of the [RFC4710]" ::= { raqmonQosEntry 4 } raqmonQosRcvdOctets OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of octets received by this receiver since the previous report. Will contain the previous value if there was no report for this time, or -1 if the value has never been reported." REFERENCE "Section 5.18 of the [RFC4710]" ::= { raqmonQosEntry 5 } raqmonQosSentPackets OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets sent since the previous report. Will contain the previous value if there Siddiqui, et al. Standards Track [Page 25] RFC 4711 RAQMON MIB October 2006 was no report for this time, or -1 if the value has never been reported." REFERENCE "Section 5.17 of the [RFC4710]" ::= { raqmonQosEntry 6 } raqmonQosSentOctets OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of octets sent since the previous report. Will contain the previous value if there was no report for this time, or -1 if the value has never been reported." REFERENCE "Section 5.19 of the [RFC4710]" ::= { raqmonQosEntry 7 } raqmonQosLostPackets OBJECT-TYPE SYNTAX Integer32 (-1 | 0..2147483647) UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of packets lost as observed by this receiver since the previous report. Will contain the previous value if there was no report for this time, or -1 if the value has never been reported." REFERENCE "Section 5.20 of the [RFC4710]" ::= { raqmonQosEntry 8 } raqmonQosSessionStatus OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The session status. Will contain the previous value if there was no report for this time or the zero-length string if no value was ever reported." REFERENCE "Section 5.10 of the [RFC4710]" ::= { raqmonQosEntry 9 } raqmonParticipantAddrTable OBJECT-TYPE Siddiqui, et al. Standards Track [Page 26] RFC 4711 RAQMON MIB October 2006 SYNTAX SEQUENCE OF RaqmonParticipantAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maps raqmonParticipantAddr to the index of the raqmonParticipantTable. This table allows management applications to find entries sorted by raqmonParticipantAddr rather than raqmonParticipantStartDate." ::= { raqmonSession 3 } raqmonParticipantAddrEntry OBJECT-TYPE SYNTAX RaqmonParticipantAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to exactly one entry in the raqmonParticipantEntry: the entry containing the index pair raqmonParticipantStartDate, raqmonParticipantIndex. Note that there is no concern about the indexation of this table exceeding the limits defined by RFC 2578, Section 3.5. According to [RFC4710], Section 5.1, only IPv4 and IPv6 addresses can be reported as participant addresses." INDEX { raqmonParticipantAddrType, raqmonParticipantAddr, raqmonParticipantStartDate, raqmonParticipantIndex } ::= { raqmonParticipantAddrTable 1 } RaqmonParticipantAddrEntry ::= SEQUENCE { raqmonParticipantAddrEndDate DateAndTime } raqmonParticipantAddrEndDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of raqmonParticipantEndDate for the corresponding raqmonParticipantEntry." ::= { raqmonParticipantAddrEntry 1 } raqmonException OBJECT IDENTIFIER ::= { raqmonMIBObjects 2 } raqmonSessionExceptionTable OBJECT-TYPE Siddiqui, et al. Standards Track [Page 27] RFC 4711 RAQMON MIB October 2006 SYNTAX SEQUENCE OF RaqmonSessionExceptionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines thresholds for the management station to get notifications about sessions that encountered poor quality of service. The information in this table MUST be persistent across agent reboots." ::= { raqmonException 2 } raqmonSessionExceptionEntry OBJECT-TYPE SYNTAX RaqmonSessionExceptionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the raqmonSessionExceptionTable." INDEX { raqmonSessionExceptionIndex } ::= { raqmonSessionExceptionTable 1 } RaqmonSessionExceptionEntry ::= SEQUENCE { raqmonSessionExceptionIndex Unsigned32, raqmonSessionExceptionIAJitterThreshold Unsigned32, raqmonSessionExceptionNetRTTThreshold Unsigned32, raqmonSessionExceptionLostPacketsThreshold Unsigned32, raqmonSessionExceptionRowStatus RowStatus } raqmonSessionExceptionIndex OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the raqmonSessionExceptionTable. Management applications can determine unused indices by performing GetNext or GetBulk operations on the Table." ::= { raqmonSessionExceptionEntry 2 } raqmonSessionExceptionIAJitterThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION Siddiqui, et al. Standards Track [Page 28] RFC 4711 RAQMON MIB October 2006 "Threshold for jitter. The value during a session must be greater than or equal to this value for an exception to be created." ::= { raqmonSessionExceptionEntry 3 } raqmonSessionExceptionNetRTTThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Threshold for round-trip time. The value during a session must be greater than or equal to this value for an exception to be created." ::= { raqmonSessionExceptionEntry 4 } raqmonSessionExceptionLostPacketsThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..1000) UNITS "tenth of a percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Threshold for lost packets in units of tenths of a percent. The value during a session must be greater than or equal to this value for an exception to be created." ::= { raqmonSessionExceptionEntry 5 } raqmonSessionExceptionRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object has a value of 'active' when exceptions are being monitored by the system. A newly-created conceptual row must have all the read-create objects initialized before becoming 'active'. A conceptual row that is in the 'notReady' or 'notInService' state MAY be removed after 5 minutes. No writeable objects can be changed while the row is active." ::= { raqmonSessionExceptionEntry 7 } raqmonConfig OBJECT IDENTIFIER ::= { raqmonMIBObjects 3 } raqmonConfigPort OBJECT-TYPE SYNTAX InetPortNumber Siddiqui, et al. Standards Track [Page 29] RFC 4711 RAQMON MIB October 2006 MAX-ACCESS read-write STATUS current DESCRIPTION "The UDP port to listen on for RAQMON reports, running on transport protocols other than SNMP. If the RAQMON PDU transport protocol is SNMP, a write operation on this object has no effect, as the standard port 162 is always used. The value of this object MUST be persistent across agent reboots." ::= { raqmonConfig 1 } raqmonConfigPduTransport OBJECT-TYPE SYNTAX BITS { other(0), tcp(1), snmp(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The PDU transport(s) used by this collector. If other(0) is set, the collector supports a transport other than SNMP or TCP. If tcp(1) is set, the collector supports TCP as a transport protocol. If snmp(2) is set, the collector supports SNMP as a transport protocol." ::= { raqmonConfig 2 } raqmonConfigRaqmonPdus OBJECT-TYPE SYNTAX Counter32 UNITS "PDUs" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of RAQMON PDUs received by the Collector." ::= { raqmonConfig 3 } raqmonConfigRDSTimeout OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of seconds since the reception of the last RAQMON PDU from a RDS after which a session Siddiqui, et al. Standards Track [Page 30] RFC 4711 RAQMON MIB October 2006 between the respective RDS and the collector will be considered terminated. The value of this object MUST be persistent across agent reboots." ::= { raqmonConfig 4 } raqmonConformance OBJECT IDENTIFIER ::= { raqmonMIB 2 } raqmonCompliances OBJECT IDENTIFIER ::= { raqmonConformance 1 } raqmonGroups OBJECT IDENTIFIER ::= { raqmonConformance 2 } raqmonCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the RAQMON MIB." MODULE -- this module MANDATORY-GROUPS { raqmonCollectorGroup, raqmonCollectorNotificationsGroup } OBJECT raqmonParticipantAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "Only IPv4 and IPv6 addresses need to be supported." OBJECT raqmonParticipantAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "Only IPv4 and IPv6 addresses need to be supported." OBJECT raqmonParticipantPeerAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "Only IPv4 and IPv6 addresses need to be supported." OBJECT raqmonParticipantPeerAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "Only IPv4 and IPv6 addresses need to be supported." ::= { raqmonCompliances 1 } Siddiqui, et al. Standards Track [Page 31] RFC 4711 RAQMON MIB October 2006 raqmonCollectorGroup OBJECT-GROUP OBJECTS { raqmonParticipantReportCaps, raqmonParticipantAddrType, raqmonParticipantAddr, raqmonParticipantSendPort, raqmonParticipantRecvPort, raqmonParticipantSetupDelay, raqmonParticipantName, raqmonParticipantAppName, raqmonParticipantQosCount, raqmonParticipantEndDate, raqmonParticipantDestPayloadType, raqmonParticipantSrcPayloadType, raqmonParticipantActive, raqmonParticipantPeer, raqmonParticipantPeerAddrType, raqmonParticipantPeerAddr, raqmonParticipantSrcL2Priority, raqmonParticipantDestL2Priority, raqmonParticipantSrcDSCP, raqmonParticipantDestDSCP, raqmonParticipantCpuMean, raqmonParticipantCpuMin, raqmonParticipantCpuMax, raqmonParticipantMemoryMean, raqmonParticipantMemoryMin, raqmonParticipantMemoryMax, raqmonParticipantNetRTTMean, raqmonParticipantNetRTTMin, raqmonParticipantNetRTTMax, raqmonParticipantIAJitterMean, raqmonParticipantIAJitterMin, raqmonParticipantIAJitterMax, raqmonParticipantIPDVMean, raqmonParticipantIPDVMin, raqmonParticipantIPDVMax, raqmonParticipantNetOwdMean, raqmonParticipantNetOwdMin, raqmonParticipantNetOwdMax, raqmonParticipantAppDelayMean, raqmonParticipantAppDelayMin, raqmonParticipantAppDelayMax, raqmonParticipantPacketsRcvd, raqmonParticipantPacketsSent, raqmonParticipantOctetsRcvd, raqmonParticipantOctetsSent, raqmonParticipantLostPackets, Siddiqui, et al. Standards Track [Page 32] RFC 4711 RAQMON MIB October 2006 raqmonParticipantLostPacketsFrct, raqmonParticipantDiscards, raqmonParticipantDiscardsFrct, raqmonQoSEnd2EndNetDelay, raqmonQoSInterArrivalJitter, raqmonQosRcvdPackets, raqmonQosRcvdOctets, raqmonQosSentPackets, raqmonQosSentOctets, raqmonQosLostPackets, raqmonQosSessionStatus, raqmonParticipantAddrEndDate, raqmonConfigPort, raqmonSessionExceptionIAJitterThreshold, raqmonSessionExceptionNetRTTThreshold, raqmonSessionExceptionLostPacketsThreshold, raqmonSessionExceptionRowStatus, raqmonConfigPduTransport, raqmonConfigRaqmonPdus, raqmonConfigRDSTimeout} STATUS current DESCRIPTION "Objects used in RAQMON by a collector." ::= { raqmonGroups 1 } raqmonCollectorNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { raqmonSessionAlarm } STATUS current DESCRIPTION "Notifications emitted by a RAQMON collector." ::= { raqmonGroups 2 } END 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Setting the value of the object raqmonRDSTimeout to too low a value would result in RDS sessions being terminated sooner than necessary, while setting at too high a value may result in terminated sessions continuing to be managed, with unnecessary memory allocations. Siddiqui, et al. Standards Track [Page 33] RFC 4711 RAQMON MIB October 2006 Setting the following object to incorrect values can result in the collectors either flooding the management applications with unnecessary notifications, or not sending notifications when the QoS in the network may be degraded. raqmonSessionExceptionIAJitterThreshold raqmonSessionExceptionRTTThreshold raqmonSessionExceptionLostPacketsThreshold Setting the raqmonConfigPort object to incorrect values can result in the collector not being able to receive RAQMON PDUs from the data sources. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. These are: raqmonParticipantTable raqmonQoSTable raqmonParticpantAddrTable Unauthorized exposure of these objects may lead to disclosure of the addresses of the participants in applications, or information about the traffic patents of the applications, which may be considered sensitive in certain environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt their values when sending them over the network via SNMP. The structure of the RAQMON tables limits what can be usefully done for access control configuration using View-based Access Control Model (VACM). For example, with these structures it would not be possible to provide a group, with access to performance data for a specific group of devices, since the index values for raqmonParticpantEntry cannot be known in advance. Likewise, raqmonSessionExceptionEntries apply to all entries in the raqmonQoSTable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Siddiqui, et al. Standards Track [Page 34] RFC 4711 RAQMON MIB October 2006 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations No requirements from IANA are defined in this document. The root OID of the MIB module defined in this document belongs to the RMON subtree, as reserved in [RFC3737]. 8. Acknowledgements Richard Smith created the first proprietary version of this MIB. The authors would also like to thank all the participants in the Remote Monitoring MIB Working Group, and especially Andy Bierman, Steven Waldbusser, Alan Clark, Itai Zilbershtein, and Robert Cole for interesting discussions, ideas, comments, and direct contributions to this work. The authors would also like to thank Randy Presuhn for the precious technical comments, as well as for the laborious activity of reviewing the syntax and spelling of the document. The authors would like to thank Bert Wijnen for the review of the final versions of the document, as well as for the guidance provided during the whole period of editing. Siddiqui, et al. Standards Track [Page 35] RFC 4711 RAQMON MIB October 2006 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC3411] Harrington, D., Preshun, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwalder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- time Application Quality-of-Service Monitoring (RAQMON) Framework", RFC 4710, October 2006. 10. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman, M., and Y. Kim, "Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)", RFC 4712, October 2006. [RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules", RFC 3737, April 2004. Siddiqui, et al. Standards Track [Page 36] RFC 4711 RAQMON MIB October 2006 Authors' Addresses Anwar A. Siddiqui Avaya Labs 307 Middletown Lincroft Road Lincroft, New Jersey 07738 USA Phone: +1 732 852-3200 Fax: +1 732 817-5922 EMail: anwars@avaya.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Phone: +972 3-645-8414 EMail: dromasca@avaya.com Eugene Golovinsky EMail: gene@alertlogic.net Siddiqui, et al. Standards Track [Page 37] RFC 4711 RAQMON MIB October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Siddiqui, et al. Standards Track [Page 38] snmp-mibs-downloader-1.1/mibrfcs/rfc4712.txt0000644000000000000000000032553711402176072015577 0ustar Network Working Group A. Siddiqui Request for Comments: 4712 D. Romascanu Category: Standards Track Avaya E. Golovinsky Alert Logic M. Rahman Samsung Information Systems America Y. Kim Broadcom October 2006 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo specifies two transport mappings of the Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). Siddiqui, et al. Standards Track [Page 1] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Table of Contents 1. Introduction ....................................................3 2. Transporting RAQMON Protocol Data Units .........................3 2.1. TCP as an RDS/RRC Network Transport Protocol ...............3 2.1.1. The RAQMON PDU ......................................5 2.1.2. The BASIC Part of the RAQMON Protocol Data Unit .....7 2.1.3. APP Part of the RAQMON Protocol Data Unit ..........14 2.1.4. Byte Order, Alignment, and Time Format of RAQMON PDUs ........................................15 2.2. Securing RAQMON Session ...................................15 2.2.1. Sequencing of the Start TLS Operation ..............18 2.2.2. Closing a TLS Connection ...........................21 2.3. SNMP Notifications as an RDS/RRC Network Transport Protocol ..................................................22 3. IANA Considerations ............................................38 4. Congestion-Safe RAQMON Operation ...............................38 5. Acknowledgements ...............................................39 6. Security Considerations ........................................39 6.1. Usage of TLS with RAQMON ..................................41 6.1.1. Confidentiality & Message Integrity ................41 6.1.2. TLS CipherSuites ...................................41 6.1.3. RAQMON Authorization State .........................42 7. References .....................................................43 7.1. Normative References ......................................43 7.2. Informative References ....................................44 Appendix A. Pseudocode ............................................46 Siddiqui, et al. Standards Track [Page 2] RFC 4712 Transport Mappings for RAQMON PDU October 2006 1. Introduction The Real-Time Application QoS Monitoring (RAQMON) Framework, as outlined by [RFC4710], extends the Remote Monitoring family of protocols (RMON) by defining entities such as RAQMON Data Sources RDS) and RAQMON Report Collectors (RRC) to perform various application monitoring in real time. [RFC4710] defines the relevant metrics for RAQMON monitoring carried by the common protocol data unit (PDU) used between a RDS and RRC to report QoS statistics. This memo contains a syntactical description of the RAQMON PDU structure. The following sections of this memo contain detailed specifications for the usage of TCP and SNMP to carry RAQMON information. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Transporting RAQMON Protocol Data Units The RAQMON Protocol Data Unit (PDU) utilizes a common data format understood by the RDS and the RRC. A RAQMON PDU does not transport application data but rather occupies the place of a payload specification at the application layer of the protocol stack. As part of the specification, this memo also specifies the usage of TCP and SNMP as underlying transport protocols to carry RAQMON PDUs between RDSs and RRCs. While two transport protocol choices have been provided as options to chose from for RDS implementers, RRCs MUST implement the TCP transport and MAY implement the SNMP transport. 2.1. TCP as an RDS/RRC Network Transport Protocol A transport binding using TCP is included within the RAQMON specification to facilitate reporting from various types of embedded devices that run applications such as Voice over IP, Voice over Wi-Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, software download applications, e-business style transactions, web access from wired or wireless computing devices etc. For many of these devices, PDUs and a TCP-based transport fit the deployment needs. The RAQMON transport requirements for end-to-end congestion control and reliability are inherently built into TCP as a transport protocol [RFC793]. Siddiqui, et al. Standards Track [Page 3] RFC 4712 Transport Mappings for RAQMON PDU October 2006 To use TCP to transport RAQMON PDUs, it is sufficient to send the PDUs as TCP data. As each PDU carries its length, the receiver can determine the PDU boundaries. The following section details the RAQMON PDU specifications. Though transmitted as one Protocol Data Unit, a RAQMON PDU is functionally divided into two different parts: the BASIC part and application extensions required for vendor-specific extension [RFC4710]. Both functional parts follow a field carrying a SMI Network Management Private Enterprise code currently maintained by IANA http://www.iana.org/assignments/enterprise-numbers, which is used to identify the organization that defined the information carried in the PDU. A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. The parameters carried by RAQMON PDUs are shown in Figure 1 and are defined in section 5 of [RFC4710]. Vendors MUST use the BASIC part of the PDU to report parameters pre- listed here in the specification for interoperability, as opposed to using the application-specific portion. Vendors MAY also use application-specific extensions to convey application-, vendor-, or device-specific parameters not included in the BASIC part of the specification and explicitly publish such data externally to attain extended interoperability. Siddiqui, et al. Standards Track [Page 4] RFC 4712 Transport Mappings for RAQMON PDU October 2006 2.1.1. The RAQMON PDU 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PDT = 1 |B| T |P|S|R| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 |Report Type = 0| RC_N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Address {DA} | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Address (RA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Application Name (AN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Data Source Name (DN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Receiver's Name (RN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Session State ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Round-Trip End-to-End Network Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One-Way End-to-End Network Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative Packet Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative Application Packet Discard | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Application Packets sent | Siddiqui, et al. Standards Track [Page 5] RFC 4712 Transport Mappings for RAQMON PDU October 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Application Packets received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Application Octets sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Application Octets received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Device Port Used | Receiver Device Port Used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Source Payload |Receiver | CPU | Memory | |Type |Payload Type | Utilization | Utilization | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Setup Delay | Application Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Packet Delay Variation | Inter arrival Jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Discrd | Packet loss | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = "xxx" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Report Type = "yyy" | Length of Application Part | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application/vendor specific extension | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = "abc" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Report Type = "zzz" | Length of Application Part | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application/vendor specific extension | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RAQMON Protocol Data Unit Siddiqui, et al. Standards Track [Page 6] RFC 4712 Transport Mappings for RAQMON PDU October 2006 2.1.2. The BASIC Part of the RAQMON Protocol Data Unit A RAQMON PDU must contain the following BASIC part fields at all times: PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being sent. PDT = 1 is used for the current RAQMON PDU version defined in this document. basic (B): 1 bit - While set to 1, the basic flag indicates that the PDU has BASIC part of the RAQMON PDU. A value of zero is considered valid and indicates a RAQMON NULL PDU. trailer (T): 3 bits - Total number of Application-Specific Extensions that follow the BASIC part of RAQMON PDU. A value of zero is considered valid as many times as there is no application- specific information to add to the basic information. padding (P): 1 bit - If the padding bit is set, the BASIC part of the RAQMON PDU contains some additional padding octets at the end of the BASIC part of the PDU that are not part of the monitoring information. Padding may be needed in some cases, as reporting is based on the intent of a RDS to report certain parameters. Also, some parameters may be reported only once at the beginning of the reporting session, e.g., Data Source Name, Receiver Name, payload type, etc. Actual padding at the end of the BASIC part of the PDU is 0, 8, 16, or 24 bits to make the length of the BASIC part of the PDU a multiple of 32 bits Source IP version Flag (S): 1 bit - While set to 1, the source IP version flag indicates that the Source IP address contained in the PDU is an IPv6 address. Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP version flag indicates that the receiver IP address contained in the PDU is an IPv6 address. record count (RC): 4 bits - Total number of application records contained in the BASIC part of the PDU. A value of zero is considered valid but useless, with the exception of the case of a NULL PDU indicating the end of a RDS reporting session. length: 16 bits (unsigned integer) - The length of the BASIC part of the RAQMON PDU in units of 32-bit words minus one; this count includes the header and any padding. Siddiqui, et al. Standards Track [Page 7] RFC 4712 Transport Mappings for RAQMON PDU October 2006 DSRC: 32 bits - Data Source identifier represents a unique RAQMON reporting session descriptor that points to a specific reporting session between RDS and RRC. Uniqueness of DSRC is valid only within a reporting session. DSRC values should be randomly generated using vendor-chosen algorithms for each communication session. It is not sufficient to obtain a DSRC simply by calling random() without carefully initializing the state. One could use an algorithm like the one defined in Appendix A.6 in [RFC3550] to create a DSRC. Depending on the choice of algorithm, there is a finite probability that two DSRCs from two different RDSs may be the same. To further reduce the probability that two RDSs pick the same DSRC for two different reporting sessions, it is recommended that an RRC use parameters like Data Source Address (DA), Data Source Name (DN), and layer 2 Media Access Control (MAC) Address in the PDU in conjunction with a DSRC value. It is not mandatory for RDSs to send parameters like Data Source Address (DA), Data Source Name (DN), and MAC Address in every PDU sent to RRC, but occasionally sending these parameters will reduce the probability of DSRC collision drastically. However, this will cause an additional overhead per PDU. A value of zero for basic (B) bit and trailer (T) bits constitutes a RAQMON NULL PDU (i.e., nothing to report). RDSs MUST send a RAQMON NULL PDU to RRC to indicate the end of the RDS reporting session. A NULL PDU ends with the DSRC field. SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is used to indicate the RMON-WG-compliant BASIC part of the RAQMON PDU format. Report Type: 8 bits - These bits are reserved by the IETF RMON Working Group. A value of 0 within SMI Enterprise Code = 0 is used for the version of the PDU defined by this document. The BASIC part of each RAQMON PDU consists of Record Count Number (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the presence of appropriate RAQMON parameters within a record, as defined in Table 1. RC_N: 8 bits - The Record Count number indicates a sub-session within a communication session. A value of zero is a valid record number. The maximum number of records that can be described in one RAQMON Packet is 256. RAQMON Parameter Presence Flags (RPPF): 32 bits Each of these flags, while set, represents that this RAQMON PDU contains corresponding parameters as specified in Table 1. Siddiqui, et al. Standards Track [Page 8] RFC 4712 Transport Mappings for RAQMON PDU October 2006 +----------------+--------------------------------------------------+ | Bit Sequence | Presence/Absence of corresponding Parameter | | Number | within this RAQMON PDU | +----------------+--------------------------------------------------+ | 0 | Data Source Address (DA) | | | | | 1 | Receiver Address (RA) | | | | | 2 | NTP Timestamp | | | | | 3 | Application Name | | | | | 4 | Data Source Name (DN) | | | | | 5 | Receiver Name (RN) | | | | | 6 | Session Setup Status | | | | | 7 | Session Duration | | | | | 8 | Round-Trip End-to-End Net Delay (RTT) | | | | | 9 | One-Way End-to-End Network Delay (OWD) | | | | | 10 | Cumulative Packets Loss | | | | | 11 | Cumulative Packets Discards | | | | | 12 | Total number of App Packets sent | | | | | 13 | Total number of App Packets received | | | | | 14 | Total number of App Octets sent | | | | | 15 | Total number of App Octets received | | | | | 16 | Data Source Device Port Used | | | | | 17 | Receiver Device Port Used | | | | | 18 | Source Layer 2 Priority | | | | | 19 | Source Layer 3 Priority | | | | | 20 | Destination Layer 2 Priority | | | | | 21 | Destination Layer 3 Priority | | | | Siddiqui, et al. Standards Track [Page 9] RFC 4712 Transport Mappings for RAQMON PDU October 2006 | 22 | Source Payload Type | | | | | 23 | Receiver Payload Type | | | | | 24 | CPU Utilization | | | | | 25 | Memory Utilization | | | | | 26 | Session Setup Delay | | | | | 27 | Application Delay | | | | | 28 | IP Packet Delay Variation | | | | | 29 | Inter arrival Jitter | | | | | 30 | Packet Discard (in fraction) | | | | | 31 | Packet Loss (in fraction) | +----------------+--------------------------------------------------+ Table 1: RAQMON Parameters and Corresponding RPPF Data Source Address (DA): 32 bits or 160 bits in binary representation - This parameter is defined in section 5.1 of [RFC4710]. IPv6 addresses are incorporated in Data Source Address by setting the source IP version flag (S bit) of the RAQMON PDU header to 1. Receiver Address (RA): 32 bits or 160 bits - This parameter is defined in section 5.2 of [RFC4710]. It follows the exact same syntax as Data Source Address but is used to indicate a Receiver Address. IPv6 addresses are incorporated in Receiver Address by setting the receiver IP version flag (R bit) of the RAQMON PDU header to 1. Session Setup Date/Time (NTP timestamp): 64 bits - This parameter is defined in section 5.7 of [RFC4710] and represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds [RFC1305]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. Application Name: This parameter is defined in section 5.32 of [RFC4710]. The Application Name field starts with an 8-bit octet count describing the length of the text followed by the text itself using UTF-8 encoding. Application Name field is a multiple of 32 bits, and padding will be used if necessary. Siddiqui, et al. Standards Track [Page 10] RFC 4712 Transport Mappings for RAQMON PDU October 2006 A Data Source that does not support NTP SHOULD set the appropriate RAQMON flag to 0 to avoid wasting 64 bits in the PDU. Since the NTP time stamp is intended to provide the setup Date/Time of a session, it is RECOMMENDED that the NTP Timestamp be used only in the first RAQMON PDU after sub-session RC_N setup is completed, in order to use network resources efficiently. Data Source Name (DN): Defined in section 5.3 of [RFC4710]. The Data Source Name field starts with an 8-bit octet count describing the length of the text followed by the text itself. Padding is used to ensure that the length and text encoding occupy a multiple of 32 bits in the DN field of the PDU. The text MUST NOT be longer than 255 octets. The text is encoded according to the UTF-8 encoding specified in [RFC3629]. Applications SHOULD instruct RDSs to send out the Data Source Name infrequently to ensure efficient usage of network resources as this parameter is expected to remain constant for the duration of the reporting session. Receiver Name (RN): This metric is defined in section 5.4 of [RFC4710]. Like Data Source Name, the Receiver Name field starts with an 8-bit octet count describing the length of the text, followed by the text itself. The Receiver Name, including the length field encoding, is a multiple of 32 bits and follows the same padding rules as applied to the Data Source Name. Since the Receiver Name is expected to remain constant during the entire reporting session, this information SHOULD be sent out occasionally over random time intervals to maximize success of reaching a RRC and also conserve network bandwidth. Session Setup Status: The Session (sub-session) Setup Status is defined in section 5.10 of [RFC4710]. This field starts with an 8-bit length field followed by the text itself. Session Setup Status is a multiple of 32 bits. Session Duration: 32 bits - The Session (sub-session) Duration metric is defined in section 5.9 of [RFC4710]. Session Duration is an unsigned integer expressed in seconds. Round-Trip End-to-End Network Delay: 32 bits - The Round-Trip End- to-End Network Delay is defined in section 5.11 of [RFC4710]. This field represents the Round-Trip End-to-End Delay of sub- session RC_N, which is an unsigned integer expressed in milliseconds. One-Way End-to-End Network Delay: 32 bits - The One-Way End-to-End Network Delay is defined in section 5.12 of [RFC4710]. This field represents the One-Way End-to-End Delay of sub-session RC_N, which is an unsigned integer expressed in milliseconds. Siddiqui, et al. Standards Track [Page 11] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Cumulative Application Packet Loss: 32 bits - This parameter is defined in section 5.20 of [RFC4710] as an unsigned integer, representing the total number of packets from sub-session RC_N that have been lost while this RAQMON PDU was generated. Cumulative Application Packet Discards: 32 bits - This parameter is defined in section 5.22 of [RFC4710] as an unsigned integer representing the total number of packets from sub-session RC_N that have been discarded while this RAQMON PDU was generated. Total number of Application Packets sent: 32 bits - This parameter is defined in section 5.17 of [RFC4710] as an unsigned integer, representing the total number of packets transmitted within sub- session RC_N by the sender. Total number of Application Packets received: 32 bits - This parameter is defined in section 5.16 of [RFC4710] and is represented as an unsigned integer representing the total number of packets transmitted within sub-session RC_N by the receiver. Total number of Application Octets sent: 32 bits - This parameter is defined in section 5.19 of [RFC4710] as an unsigned integer, representing the total number of payload octets (i.e., not including header or padding) transmitted in packets by the sender within sub-session RC_N. Total number of Application Octets received: 32 bits - This parameter is defined in section 5.18 of [RFC4710] as an unsigned integer representing the total number of payload octets (i.e., not including header or padding) transmitted in packets by the receiver within sub-session RC_N. Data Source Device Port Used: 16 bits - This parameter is defined in section 5.5 of [RFC4710] and describes the port number used by the Data Source as used by the application in RC_N session while this RAQMON PDU was generated. Receiver Device Port Used: 16 bits - This parameter is defined in section 5.6 of [RFC4710] and describes the receiver port used by the application to communicate to the receiver. It follows same syntax as Source Device Port Used. S_Layer2: 8 bits - This parameter, defined in section 5.26 of [RFC4710], is associated to the source's IEEE 802.1D [IEEE802.1D] priority tagging of traffic in the communication sub-session RC_N. Since IEEE 802.1 priority tags are 3 bits long, the first 3 bits of this parameter represent the IEEE 802.1 tag value, and the last 5 bits are padded to 0. Siddiqui, et al. Standards Track [Page 12] RFC 4712 Transport Mappings for RAQMON PDU October 2006 S_Layer3: 8 bits - This parameter, defined in section 5.27 of [RFC4710], represents the layer 3 QoS marking used to send packets to the receiver by this data source during sub-session RC_N. D_Layer2: 8 bits - This parameter, defined in section 5.28 of [RFC4710], represents layer 2 IEEE 802.1D priority tags used by the receiver to send packets to the data source during sub-session RC_N session if the Data Source can learn such information. Since IEEE 802.1 priority tags are 3 bits long, the first 3 bits of this parameter represent the IEEE 802.1 priority tag value, and the last 5 bits are padded to 0. D_Layer3: 8 bits - This parameter is defined in section 5.29 of [RFC4710] and represents the layer 3 QoS marking used by the receiver to send packets to the data source during sub-session RC_N, if the Data Source can learn such information. Source Payload Type: 8 bits - This parameter is defined in section 5.24 of [RFC4710] and specifies the payload type of the data source of the communication sub-session RC_N as defined in [RFC3551]. Receiver Payload Type: 8 bits - This parameter is defined in section 5.25 of [RFC4710] and specifies the receiver payload type of the communication sub-session RC_N as defined in [RFC3551]. CPU Utilization: 8 bits - This parameter, defined in section 5.30 of [RFC4710], represents the percentage of CPU used during session RC_N from the last report until the time this RAQMON PDU was generated. The CPU Utilization is expressed in percents in the range 0 to 100. The value should indicate not only CPU utilization associated to a session RC_N but also actual CPU Utilization, to indicate a snapshot of the CPU utilization of the host running the RDS while session RC_N in progress. Memory Utilization: 8 bits - This parameter, defined in section 5.31 of [RFC4710], represents the percentage of total memory used during session RC_N up until the time this RAQMON PDU was generated. The memory utilization is expressed in percents 0 to 100. The Memory Utilization value should indicate not only the memory utilization associated to a session RC_N but the total memory utilization, to indicate a snapshot of end-device memory utilization while session RC_N is in progress. Session Setup Delay: 16 bits - The Session (sub-session) Setup Delay metric is defined in section 5.8 of [RFC4710] and expressed in milliseconds. Siddiqui, et al. Standards Track [Page 13] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Application Delay: 16 bits - The Application Delay is defined in section 5.13 of [RFC4710] and is represented as an unsigned integer expressed in milliseconds. IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is defined in section 5.15 of [RFC4710] and is represented as an unsigned integer expressed in milliseconds. Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined in section 5.14 of [RFC4710] and is represented as an unsigned integer expressed in milliseconds. Packet Discard in Fraction: 8 bits - This parameter is defined in section 5.23 of [RFC4710] and is expressed as a fixed-point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the discard fraction by 256.) This metric is defined to be the number of packets discarded, divided by the total number of packets. Packet Loss in Fraction: 8 bits - This parameter is defined in section 5.21 of [RFC4710] and is expressed as a fixed-point number, with the binary point at the left edge of the field. The metric is defined to be the number of packets lost divided by the number of packets expected. The value is calculated by dividing the total number of packets lost (after the effects of applying any error protection, such as Forward Error Correction (FEC)) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. padding: 0, 8, 16, or 24 bits - If the padding bit (P) is set, then this field may be present. The actual padding at the end of the BASIC part of the PDU is 0, 8, 16, or 24 bits to make the length of the BASIC part of the PDU a multiple of 32 bits. 2.1.3. APP Part of the RAQMON Protocol Data Unit The APP part of the RAQMON PDU is intended to accommodate extensions for new applications in a modular manner and without requiring a PDU type value registration. Vendors may design and publish application-specific extensions. Any RAQMON-compliant RRC MUST be able to recognize vendors' SMI Enterprise Codes and MUST recognize the presence of application- specific extensions identified by using Report Type fields. As represented in Figure 1, the Report Type and Application Length Siddiqui, et al. Standards Track [Page 14] RFC 4712 Transport Mappings for RAQMON PDU October 2006 fields are always located at a fixed offset relative to the start of the extension fields. There is no need for the RRC to understand the semantics of the enterprise-specific parts of the PDU. SMI Enterprise Code: 32 bits - Vendors and application developers should fill in appropriate SMI Enterprise IDs available at http://www.iana.org/assignments/enterprise-numbers. A non-zero SMI Enterprise Code indicates a vendor- or application-specific extension. RAQMON PDUs are capable of carrying multiple Application Parts within a PDU. Report Type: 16 bits - Vendors and application developers should fill in the appropriate report type within a specified SMI Enterprise Code. It is RECOMMENDED that vendors publish application-specific extensions and maintain such report types for better interoperability. Length of the Application Part: 16 bits (unsigned integer) - The length of the Application Part of the RAQMON PDU in 32-bit words minus one, which includes the header of the Application Part. Application-dependent data: variable length - Application/ vendor-dependent data is defined by the application developers. It is interpreted by the vendor-specific application and not by the RRC itself. Its length must be a multiple of 32 bits and will be padded if necessary. 2.1.4. Byte Order, Alignment, and Time Format of RAQMON PDUs All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in [RFC791]. Unless otherwise noted, numeric constants are in decimal (base 10). All header data is aligned to its natural length, i.e., 16-bit fields are aligned on even offsets, 32-bit fields are aligned at offsets divisible by four, etc. Octets designated as padding have the value zero. 2.2. Securing RAQMON Session The RAQMON session, initiated over TCP transport, between an RDS and an RRC carries monitoring information from an RDS client to the RRC, the collector. The RRC distinguishes between clients based on various identifiers used by the RDS to identify itself to the RRC Siddiqui, et al. Standards Track [Page 15] RFC 4712 Transport Mappings for RAQMON PDU October 2006 (Data Source Address and Data Source Name) and the RRC (Receiver's Address and Receiver's Name). In order to ensure integrity of the claimed identities of RDS and RRC to each other, authentication services are required. Subsequently, where protection from unauthorized modification and unauthorized disclosure of RAQMON data in transit from RDS to RRC is needed, data confidentiality and message integrity services will be required. In order to prevent monitoring-misinformation due to session-recording and replay by unauthorized sources, replay protection services may be required. TLS provides, at the transport layer, the required authentication services through the handshake protocol and subsequent data confidentiality, message integrity, and replay protection of the application protocol using a ciphersuite negotiated during authentication. The RDS client authenticates the RRC in session. The RRC optionally authenticates the RDS. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PDT = 1 |B| T |P|S|R| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 |Report Type = | RC_N | | | TLS_REQ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: RAQMON StartTLS Request - TLS_REQ The protection of a RAQMON session starts with the RDS client's StartTLS request upon successful establishment of the TCP session. The RDS sends the StartTLS request by transmitting the TLS_REQ PDU as in Figure 2. This PDU is distinguished by TLS_REQ Report Type. Following this request, the client MUST NOT send any PDUs on this connection until it receives a StartTLS response. Other fields of the PDU are as specified in Figure 1. The flags field do not carry any significance and exist for compatibility with the generic RAQMON PDU. The flags field in this version MUST be ignored. Siddiqui, et al. Standards Track [Page 16] RFC 4712 Transport Mappings for RAQMON PDU October 2006 When a StartTLS request is made, the target server, RRC, MUST return a RAQMON PDU containing a StartTLS response, TLS_RESP. A RAQMON TLS_RESP is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PDT = 1 |B| T |P|S|R| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 |Report Type = | Result | | | TLS_RESP| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: RAQMON StartTLS Response - TLS_RESP The RRC responds to the StartTLS request by transmitting the TLS_RESP PDU as in Figure 3. This PDU is distinguished by TLS_RESP Report Type. The Result field is an octet containing the result of the request. This field can carry one of the following values: +-------+------------------+----------------------------------------+ | Value | Mnemonic | Result | +-------+------------------+----------------------------------------+ | 0 | OK | Success. The server is willing and | | | | able to negotiate TLS. | | 1 | OP_ERR | Sequencing Error (e.g., TLS already | | | | established). | | 2 | PROTO_ERR | TLS not supported or incorrect PDU | | | | format. | | 3 | UNAVAIL | TLS service problem or RRC server | | | | going down. | | 4 | CONF_REQD | Confidentiality Service Required. | | | | | | 5 | STRONG_AUTH_REQD | Strong Authentication Service | | | | Required. | | 6 | REFERRAL | Referral to a RRC Server supporting | | | | TLS. | +-------+------------------+----------------------------------------+ Table 2 Other fields of the PDU are as specified in Figure 1. Siddiqui, et al. Standards Track [Page 17] RFC 4712 Transport Mappings for RAQMON PDU October 2006 The server MUST return OP_ERR if the client violates any of the StartTLS operation sequencing requirements described in the section below. If the server does not support TLS (whether by design or by current configuration), it MUST set the resultCode to PROTO_ERR or to REFERRAL. The server MUST include an actual referral value in the RAQMON REFER field if it returns a resultCode of referral. The client's current session is unaffected if the server does not support TLS. The client MAY proceed with RAQMON session, or it MAY close the connection. The server MUST return UNAVAIL if it supports TLS but cannot establish a TLS connection for some reason, e.g., if the certificate server not responding, if it cannot contact its TLS implementation, or if the server is in process of shutting down. The client MAY retry the StartTLS operation, MAY proceed with RAQMON session, or MAY close the connection. 2.2.1. Sequencing of the Start TLS Operation This section describes the overall procedures clients and servers MUST follow for TLS establishment. These procedures take into consideration various aspects of the overall security of the RAQMON connection including discovery of resulting security level. 2.2.1.1. Requesting to Start TLS on a RAQMON Association The client MAY send the StartTLS request at any time after establishing an RAQMON (TCP) connection, except that in the following cases the client MUST NOT send a StartTLS request: o if TLS is currently established on the connection, or o if RAQMON traffic is in progress on the connection. The result of violating any of these requirements is a Result of OP_ERR, as described above in Table 2. If the client did not establish a TLS connection before sending any other requests, and the server requires the client to establish a TLS connection before performing a particular request, the server MUST reject that request with a CONF_REQD or STRONG_AUTH_REQD result. The client MAY send a Start TLS extended request, or it MAY choose to close the connection. Siddiqui, et al. Standards Track [Page 18] RFC 4712 Transport Mappings for RAQMON PDU October 2006 2.2.1.2. Starting TLS The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable. In the successful case, the client, which has ceased to transfer RAQMON PDUs on the connection, MUST either begin a TLS negotiation or close the connection. The client will send PDUs in the TLS Record Protocol directly over the underlying transport connection to the server to initiate TLS negotiation [TLS]. 2.2.1.3. TLS Version Negotiation Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in [TLS]. The reader is referred to that document for details. 2.2.1.4. Discovery of Resultant Security Level After a TLS connection is established on a RAQMON connection, both parties MUST individually decide whether or not to continue based on the security assurance level achieved. Ascertaining the TLS connection's assurance level is implementation dependent and is accomplished by communicating with one's respective local TLS implementation. If the client or server decides that the level of authentication or confidentiality is not high enough for it to continue, it SHOULD gracefully close the TLS connection immediately after the TLS negotiation has completed Section 2.2.2.1. The client MAY attempt to Start TLS again, MAY disconnect, or MAY proceed to send RAQMON session data, if RRC policy permits. 2.2.1.5. Server Identity Check The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: o The client MUST use the server dnsNAME in the subjectAltName field to validate the server certificate presented. The server dnsName MUST be part of subjectAltName of the server. o Matching is case-insensitive. Siddiqui, et al. Standards Track [Page 19] RFC 4712 Transport Mappings for RAQMON PDU October 2006 o The "*" wildcard character is allowed. If present, it applies only to the left-most name component. For example, *.example.com would match a.example.com, b.example.com, etc., but not example.com. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name), a match in any one of the set is considered acceptable. If the hostname does not match the dNSName-based identity in the certificate per the above check, automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect. Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information. We also refer readers to similar guidelines as applied for LDAP over TLS [RFC4513]. 2.2.1.6. Client Identity Check Anonymous TLS authentication helps establish a TLS RAQMON session that offers o server-authentication in course of TLS establishment and o confidentiality and replay protection of RAQMON traffic, but o no protection against man-in-the-middle attacks during session establishment and o no protection from spoofing attacks by unauthorized clients. The server MUST authenticate the RDS client when deployment is susceptible to the above threats. This is done by requiring client authentication during TLS session establishment. In the TLS negotiation, the server MUST request a certificate. The client will provide its certificate to the server and MUST perform a private-key-based encryption, proving it has the private key associated with the certificate. As deployments will require protection of sensitive data in transit, the client and server MUST negotiate a ciphersuite that contains a bulk encryption algorithm of appropriate strength. Siddiqui, et al. Standards Track [Page 20] RFC 4712 Transport Mappings for RAQMON PDU October 2006 The server MUST verify that the client's certificate is valid. The server will normally check that the certificate is issued by a known CA, and that none of the certificates on the client's certificate chain are invalid or revoked. There are several procedures by which the server can perform these checks. The server validates the certificate by the Distinguished Name of the RDS client entity in the Subject field of the certificate. A corresponding set of guidelines will apply to use of TLS-PSK modes [TLS-PSK] using pre-shared keys instead of client certificates. 2.2.1.7. Refresh of Server Capabilities Information The client MUST refresh any cached server capabilities information upon TLS session establishment, such as prior RRC state related to a previous RAQMON session based on another DSRC. This is necessary to protect against active-intermediary attacks, which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment. 2.2.2. Closing a TLS Connection 2.2.2.1. Graceful Closure Either the client or server MAY terminate the TLS connection on an RAQMON session by sending a TLS closure alert. This will leave the RAQMON connection intact. Before closing a TLS connection, the client MUST wait for any outstanding RAQMON transmissions to complete. This happens naturally when the RAQMON client is single-threaded and synchronous. After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs and, following the receipt of the alert, MAY send and receive RAQMON PDUs. The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs and MAY send and receive RAQMON PDUs. Siddiqui, et al. Standards Track [Page 21] RFC 4712 Transport Mappings for RAQMON PDU October 2006 2.2.2.2. Abrupt Closure Either the client or server MAY abruptly close the entire RAQMON session and any TLS connection established on it by dropping the underlying TCP connection. It MAY be possible for RRC to send RDS a disconnection notification, which allows the client to know that the disconnection is not due to network failure. However, this message is not defined in this version. 2.3. SNMP Notifications as an RDS/RRC Network Transport Protocol It was an inherent objective of the RAQMON Framework to re-use existing application-level transport protocols to maximize the usage of existing installations as well as to avoid transport-protocol- level complexities in the design process. Choice of SNMP as a means to transport RAQMON PDU was motivated by the intent of using existing installed devices implementing SNMP agents as RAQMON Data Sources (RDSs). There are some potential problems with the usage of SNMP as a transport mapping protocol: o The potential of congestion is higher than with the TCP transport, because of the usage of UDP at the transport layer. o The encoding of the information is less efficient, and this results in bigger message size, which again may negatively impact congestion conditions and memory size requirements in the devices. In order to avoid these potential problems, the following recommendations are made: o Usage of the TCP transport is RECOMMENDED in deployment over the SNMP transport wherever available for a pair of RDS/RRC. o The usage of Inform PDUs is RECOMMENDED. o The usage of Traps PDU is NOT RECOMMENDED. o It is RECOMMENDED that information carried by notifications be maintained within the limits of the MTU size in order to avoid fragmentation. If SNMP is chosen as a mechanism to transport RAQMON PDUs, the following specification applies to RAQMON-related usage of SNMP: Siddiqui, et al. Standards Track [Page 22] RFC 4712 Transport Mappings for RAQMON PDU October 2006 o RDSs implement the capability of embedding RAQMON parameters in SNMP Notifications, re-using well-known SNMP mechanisms to report RAQMON Statistics. The RAQMON RDS MIB module, as specified in 2.1.1, MUST be used in order to map the RAQMON PDUs onto the SNMP Notifications transport. o Since RDSs are not computationally rich, and in order to keep the RDS realization as lightweight as possible, RDSs MAY fail to respond to SNMP requests like GET, SET, etc., with the exception of the GET and SET commands required to implement the User-Based Security Model (USM) defined by [RFC3414]. o In order to meet congestion safety requirements, SNMP INFORM PDUs SHOULD be used. In case INFORM PDUs are used, RDSs MUST process the SNMP INFORM responses from RRCs and MUST serialize the PDU transmission rate, i.e., limit the number of PDUS sent in a specific time interval. o Standard UDP port 162 SHOULD be used for SNMP Notifications. 2.3.1. Encoding RAQMON Using the RAQMON RDS MIB Module The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP Notifications for transport purposes. The MIB module defines the objects needed for mapping the BASIC part of RAQMON PDU, defined in [RFC4710], as well as the Notifications themselves. In order to incorporate any application-specific extensions in the Application (APP) part of RAQMON PDU, as defined in [RFC4710], additional variable bindings MAY be included in RAQMON notifications as described in the MIB module. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. Siddiqui, et al. Standards Track [Page 23] RFC 4712 Transport Mappings for RAQMON PDU October 2006 The following MIB module IMPORTS definitions from the following: SNMPv2-SMI [RFC2578] SNMPv2-TC [RFC2579] SNMPv2-CONF [RFC2580] RMON-MIB [RFC2819] DIFFSERV-DSCP-TC [RFC3289] SNMP-FRAMEWORK-MIB [RFC3411] INET-ADDRESS-MIB [RFC4001] It also uses REFERENCE clauses to refer to [RFC4710]. RAQMON-RDS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Unsigned32 FROM SNMPv2-SMI DateAndTime FROM SNMPv2-TC rmon FROM RMON-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB Dscp FROM DIFFSERV-DSCP-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; raqmonDsMIB MODULE-IDENTITY LAST-UPDATED "200610100000Z" -- October 10, 2006 ORGANIZATION "RMON Working Group" CONTACT-INFO "WG EMail: rmonmib@ietf.org Subscribe: rmonmib-request@ietf.org MIB Editor: Eugene Golovinsky Postal: BMC Software, Inc. 2101 CityWest Boulevard, Siddiqui, et al. Standards Track [Page 24] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Houston, TX, 77094 USA Tel: +713-918-1816 Email: egolovin@bmc.com " DESCRIPTION "This is the RAQMON Data Source notification MIB Module. It provides a mapping of RAQMON PDUs to SNMP notifications. Ds stands for data source. Note that all of the object types defined in this module are accessible-for-notify and would consequently not be available to a browser using simple Get, GetNext, or GetBulk requests. Copyright (c) The Internet Society (2006). This version of this MIB module is part of RFC 4712; See the RFC itself for full legal notices." REVISION "200610100000Z" -- October 10, 2006 DESCRIPTION "Initial version, published as RFC 4712." ::= { rmon 32 } -- This OID allocation conforms to [RFC3737] raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 } raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 } raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 } raqmonDsNotificationTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonDsNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This conceptual table provides the SNMP mapping of the RAQMON BASIC PDU. It is indexed by the RAQMON Data Source, sub-session, and address of the peer entity. Note that there is no concern about the indexation of this table exceeding the limits defined by RFC 2578 Section 3.5. According to [RFC4710], Section 5.1, Siddiqui, et al. Standards Track [Page 25] RFC 4712 Transport Mappings for RAQMON PDU October 2006 only IPv4 and IPv6 addresses can be reported as participant addresses." ::= { raqmonDsMIBObjects 1 } raqmonDsNotificationEntry OBJECT-TYPE SYNTAX RaqmonDsNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry (row) is not retrievable and is not kept by RDSs. It serves data organization purposes only." INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType, raqmonDsPeerAddr } ::= { raqmonDsNotificationTable 1 } RaqmonDsNotificationEntry ::= SEQUENCE { raqmonDsDSRC Unsigned32, raqmonDsRCN Unsigned32, raqmonDsPeerAddrType InetAddressType, raqmonDsPeerAddr InetAddress, raqmonDsAppName SnmpAdminString, raqmonDsDataSourceDevicePort InetPortNumber, raqmonDsReceiverDevicePort InetPortNumber, raqmonDsSessionSetupDateTime DateAndTime, raqmonDsSessionSetupDelay Unsigned32, raqmonDsSessionDuration Unsigned32, raqmonDsSessionSetupStatus SnmpAdminString, raqmonDsRoundTripEndToEndNetDelay Unsigned32, raqmonDsOneWayEndToEndNetDelay Unsigned32, raqmonDsApplicationDelay Unsigned32, raqmonDsInterArrivalJitter Unsigned32, raqmonDsIPPacketDelayVariation Unsigned32, raqmonDsTotalPacketsReceived Counter32, raqmonDsTotalPacketsSent Counter32, raqmonDsTotalOctetsReceived Counter32, raqmonDsTotalOctetsSent Counter32, raqmonDsCumulativePacketLoss Counter32, raqmonDsPacketLossFraction Unsigned32, raqmonDsCumulativeDiscards Counter32, raqmonDsDiscardsFraction Unsigned32, raqmonDsSourcePayloadType Unsigned32, raqmonDsReceiverPayloadType Unsigned32, raqmonDsSourceLayer2Priority Unsigned32, raqmonDsSourceDscp Dscp, raqmonDsDestinationLayer2Priority Unsigned32, raqmonDsDestinationDscp Dscp, raqmonDsCpuUtilization Unsigned32, raqmonDsMemoryUtilization Unsigned32 } Siddiqui, et al. Standards Track [Page 26] RFC 4712 Transport Mappings for RAQMON PDU October 2006 raqmonDsDSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Data Source identifier represents a unique session descriptor that points to a specific session between communicating entities. Identifiers unique for sessions conducted between two entities are generated by the communicating entities. Zero is a valid value, with no special semantics." ::= { raqmonDsNotificationEntry 1 } raqmonDsRCN OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Record Count Number indicates a sub-session within a communication session. A maximum number of 16 sub-sessions are supported; this limitation is dictated by reasons of compatibility with other transport protocols." ::= { raqmonDsNotificationEntry 2 } raqmonDsPeerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the Internet address of the peer participant for this session." REFERENCE "Section 5.2 of [RFC4710]" ::= { raqmonDsNotificationEntry 3 } raqmonDsPeerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Internet Address of the peer participant for this session." REFERENCE "Section 5.2 of [RFC4710]" ::= { raqmonDsNotificationEntry 4 } raqmonDsAppName OBJECT-TYPE Siddiqui, et al. Standards Track [Page 27] RFC 4712 Transport Mappings for RAQMON PDU October 2006 SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This is a text string giving the name and possibly the version of the application associated with that session, e.g., 'XYZ VoIP Agent 1.2'." REFERENCE "Section 5.28 of [RFC4710]" ::= { raqmonDsNotificationEntry 5 } raqmonDsDataSourceDevicePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The port number from which data for this session was sent by the Data Source device." REFERENCE "Section 5.5 of [RFC4710]" ::= { raqmonDsNotificationEntry 6 } raqmonDsReceiverDevicePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The port number where the data for this session was received." REFERENCE "Section 5.6 of [RFC4710]" ::= { raqmonDsNotificationEntry 7 } raqmonDsSessionSetupDateTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The time when session was initiated." REFERENCE "Section 5.7 of [RFC4710]" ::= { raqmonDsNotificationEntry 8 } raqmonDsSessionSetupDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current Siddiqui, et al. Standards Track [Page 28] RFC 4712 Transport Mappings for RAQMON PDU October 2006 DESCRIPTION "Session setup time." REFERENCE "Section 5.8 of [RFC4710]" ::= { raqmonDsNotificationEntry 9 } raqmonDsSessionDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Session duration, including setup time. The SYNTAX of this object allows expression of the duration of sessions that do not exceed 4660 hours and 20 minutes." REFERENCE "Section 5.9 of [RFC4710]" ::= { raqmonDsNotificationEntry 10 } raqmonDsSessionSetupStatus OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Describes appropriate communication session states, e.g., Call Established successfully, RSVP reservation failed, etc." REFERENCE "Section 5.10 of [RFC4710]" ::= { raqmonDsNotificationEntry 11 } raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Most recent available information about the round-trip end-to-end network delay." REFERENCE "Section 5.11 of [RFC4710]" ::= { raqmonDsNotificationEntry 12} raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current Siddiqui, et al. Standards Track [Page 29] RFC 4712 Transport Mappings for RAQMON PDU October 2006 DESCRIPTION "Most recent available information about the one-way end-to-end network delay." REFERENCE "Section 5.12 of [RFC4710]" ::= { raqmonDsNotificationEntry 13} raqmonDsApplicationDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Most recent available information about the application delay." REFERENCE "Section 5.13 of [RFC4710" ::= { raqmonDsNotificationEntry 14} raqmonDsInterArrivalJitter OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "An estimate of the inter-arrival jitter." REFERENCE "Section 5.14 of [RFC4710]" ::= { raqmonDsNotificationEntry 15} raqmonDsIPPacketDelayVariation OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "An estimate of the inter-arrival delay variation." REFERENCE "Section 5.15 of [RFC4710]" ::= { raqmonDsNotificationEntry 16} raqmonDsTotalPacketsReceived OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of packets transmitted within a communication Siddiqui, et al. Standards Track [Page 30] RFC 4712 Transport Mappings for RAQMON PDU October 2006 session by the receiver since the start of the session." REFERENCE "Section 5.16 of [RFC4710]" ::= { raqmonDsNotificationEntry 17 } raqmonDsTotalPacketsSent OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of packets transmitted within a communication session by the sender since the start of the session." REFERENCE "Section 5.17 of [RFC4710]" ::= { raqmonDsNotificationEntry 18 } raqmonDsTotalOctetsReceived OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The total number of payload octets (i.e., not including header or padding octets) transmitted in packets by the receiver within a communication session since the start of the session." REFERENCE "Section 5.18 of [RFC4710]" ::= { raqmonDsNotificationEntry 19 } raqmonDsTotalOctetsSent OBJECT-TYPE SYNTAX Counter32 UNITS "octets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of payload octets (i.e., not including headers or padding) transmitted in packets by the sender within a communication sub-session since the start of the session." REFERENCE "Section 5.19 of [RFC4710]" ::= { raqmonDsNotificationEntry 20 } raqmonDsCumulativePacketLoss OBJECT-TYPE SYNTAX Counter32 UNITS "packets" Siddiqui, et al. Standards Track [Page 31] RFC 4712 Transport Mappings for RAQMON PDU October 2006 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of packets from this session whose loss had been detected since the start of the session." REFERENCE "Section 5.20 of [RFC4710]" ::= { raqmonDsNotificationEntry 21 } raqmonDsPacketLossFraction OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percentage of packets sent" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The percentage of lost packets with respect to the overall packets sent. This is defined to be 100 times the number of packets lost divided by the number of packets expected." REFERENCE "Section 5.21 of [RFC4710]" ::= { raqmonDsNotificationEntry 22 } raqmonDsCumulativeDiscards OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of packet discards detected since the start of the session." REFERENCE "Section 5.22 of [RFC4710]" ::= { raqmonDsNotificationEntry 23 } raqmonDsDiscardsFraction OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percentage of packets sent" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The percentage of discards with respect to the overall packets sent. This is defined to be 100 times the number of discards divided by the number of packets expected." REFERENCE "Section 5.23 of [RFC4710]" ::= { raqmonDsNotificationEntry 24 } Siddiqui, et al. Standards Track [Page 32] RFC 4712 Transport Mappings for RAQMON PDU October 2006 raqmonDsSourcePayloadType OBJECT-TYPE SYNTAX Unsigned32 (0..127) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The payload type of the packet sent by this RDS." REFERENCE "RFC 1890, Section 5.24 of [RFC4710] " ::= { raqmonDsNotificationEntry 25 } raqmonDsReceiverPayloadType OBJECT-TYPE SYNTAX Unsigned32 (0..127) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The payload type of the packet received by this RDS." REFERENCE "RFC 1890, Section 5.25 of [RFC4710] " ::= { raqmonDsNotificationEntry 26 } raqmonDsSourceLayer2Priority OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Source Layer 2 priority used by the data source to send packets to the receiver by this data source during this communication session." REFERENCE "Section 5.26 of [RFC4710]" ::= { raqmonDsNotificationEntry 27 } raqmonDsSourceDscp OBJECT-TYPE SYNTAX Dscp MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Layer 3 TOS/DSCP values used by the Data Source to prioritize traffic sent." REFERENCE "Section 5.27 of [RFC4710]" ::= { raqmonDsNotificationEntry 28 } raqmonDsDestinationLayer2Priority OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION Siddiqui, et al. Standards Track [Page 33] RFC 4712 Transport Mappings for RAQMON PDU October 2006 "Destination Layer 2 priority. This is the priority used by the peer communicating entity to send packets to the data source." REFERENCE "Section 5.28 of [RFC4710]" ::= { raqmonDsNotificationEntry 29 } raqmonDsDestinationDscp OBJECT-TYPE SYNTAX Dscp MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Layer 3 TOS/DSCP values used by the peer communicating entity to prioritize traffic sent to the source." REFERENCE "Section 5.29 of [RFC4710]" ::= { raqmonDsNotificationEntry 30 } raqmonDsCpuUtilization OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percent" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Latest available information about the total CPU utilization." REFERENCE "Section 5.30 of [RFC4710]" ::= { raqmonDsNotificationEntry 31 } raqmonDsMemoryUtilization OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percent" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Latest available information about the total memory utilization." REFERENCE "Section 5.31 of [RFC4710]" ::= { raqmonDsNotificationEntry 32 } -- definitions of the notifications -- -- raqmonDsAppName is the only object that MUST be sent by an -- RDS every time the static notification is generated. Siddiqui, et al. Standards Track [Page 34] RFC 4712 Transport Mappings for RAQMON PDU October 2006 -- raqmonDsTotalPacketsReceived is the only object that MUST be -- sent by an RD every time the dynamic notification is generated. -- Other objects from the raqmonDsNotificationTable may be -- included in the variable binding list. Specifically, a raqmon -- notification will include MIB objects that provide information -- about metrics that characterize the application session raqmonDsStaticNotification NOTIFICATION-TYPE OBJECTS { raqmonDsAppName } STATUS current DESCRIPTION "This notification maps the static parameters in the BASIC RAQMON PDU onto an SNMP transport. This notification is expected to be sent once per session, or when a new sub-session is initiated. The following objects MAY be carried by the raqmonDsStaticNotification: raqmonDsDataSourceDevicePort, raqmonDsReceiverDevicePort, raqmonDsSessionSetupDateTime, raqmonDsSessionSetupDelay, raqmonDsSessionDuration, raqmonDsSourcePayloadType, raqmonDsReceiverPayloadType, raqmonDsSourceLayer2Priority, raqmonDsSourceDscp, raqmonDsDestinationLayer2Priority, raqmonDsDestinationDscp It is RECOMMENDED to keep the size of a notification within the MTU size limits in order to avoid fragmentation." ::= { raqmonDsNotifications 1 } raqmonDsDynamicNotification NOTIFICATION-TYPE OBJECTS { raqmonDsTotalPacketsReceived } STATUS current DESCRIPTION "This notification maps the dynamic parameters in the BASIC RAQMON PDU onto an SNMP transport. The following objects MAY be carried by the raqmonDsDynamicNotification: raqmonDsRoundTripEndToEndNetDelay, raqmonDsOneWayEndToEndNetDelay, Siddiqui, et al. Standards Track [Page 35] RFC 4712 Transport Mappings for RAQMON PDU October 2006 raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsCpuUtilization, raqmonDsMemoryUtilization It is RECOMMENDED to keep the size of a notification within the MTU size limits in order to avoid fragmentation." ::= { raqmonDsNotifications 2 } raqmonDsByeNotification NOTIFICATION-TYPE OBJECTS { raqmonDsAppName } STATUS current DESCRIPTION "The BYE Notification. This Notification is the equivalent of the RAQMON NULL PDU, which signals the end of a RAQMON session." ::= { raqmonDsNotifications 3 } -- -- conformance information raqmonDsCompliance OBJECT IDENTIFIER ::= { raqmonDsConformance 1 } raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } raqmonDsBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement this MIB module. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which we have the following compliance requirements, expressed in OBJECT clause form in this description clause: -- OBJECT raqmonDsPeerAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } Siddiqui, et al. Standards Track [Page 36] RFC 4712 Transport Mappings for RAQMON PDU October 2006 -- DESCRIPTION -- This MIB requires support for only global IPv4 -- and IPv6 address types. -- -- OBJECT raqmonDsPeerAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- This MIB requires support for only global IPv4 -- and IPv6 address types. -- " MODULE -- this module MANDATORY-GROUPS { raqmonDsNotificationGroup, raqmonDsPayloadGroup } ::= { raqmonDsCompliance 1 } raqmonDsNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { raqmonDsStaticNotification, raqmonDsDynamicNotification, raqmonDsByeNotification } STATUS current DESCRIPTION "Standard RAQMON Data Source Notification group." ::= { raqmonDsGroups 1 } raqmonDsPayloadGroup OBJECT-GROUP OBJECTS { raqmonDsAppName, raqmonDsDataSourceDevicePort, raqmonDsReceiverDevicePort, raqmonDsSessionSetupDateTime, raqmonDsSessionSetupDelay, raqmonDsSessionDuration, raqmonDsSessionSetupStatus, raqmonDsRoundTripEndToEndNetDelay, raqmonDsOneWayEndToEndNetDelay, raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsReceived, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsSourcePayloadType, raqmonDsReceiverPayloadType, Siddiqui, et al. Standards Track [Page 37] RFC 4712 Transport Mappings for RAQMON PDU October 2006 raqmonDsSourceLayer2Priority, raqmonDsSourceDscp, raqmonDsDestinationLayer2Priority, raqmonDsDestinationDscp, raqmonDsCpuUtilization, raqmonDsMemoryUtilization } STATUS current DESCRIPTION "Standard RAQMON Data Source payload MIB objects group." ::= { raqmonDsGroups 2 } END 3. IANA Considerations Applications using the RAQMON Framework require a single fixed port. Port number 7744 is registered with IANA for use as the default port for RAQMON PDUs over TCP. Hosts that run multiple applications may use this port as an indication to have used RAQMON or provision a separate TCP port as part of provisioning RAQMON RDS and RAQMON Collector. The particular port number was chosen to lie in the range above 5000 to accommodate port number allocation practice within the Unix operating system, where privileged processes can only use port numbers below 1024 and port numbers between 1024 and 5000 are automatically assigned by the operating systems. The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made according to [RFC3737], and there is no need for any IANA action on this respect. 4. Congestion-Safe RAQMON Operation As outlined in earlier sections, the TCP congestion control mechanism provides inherent congestion safety features when TCP is implemented as transport to carry RAQMON PDU. To ensure congestion safety, clearly the best thing to do is to use a congestion-safe transport protocol such as TCP. If this is not feasible, it may be necessary to fall back to UDP since SNMP over UDP is a widely deployed transport protocol. When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow section 3 of [RFC4710], which outlines measures that MUST be taken to use RAQMON in a congestion-safe manner. Congestion safety Siddiqui, et al. Standards Track [Page 38] RFC 4712 Transport Mappings for RAQMON PDU October 2006 requirements in section 3 of [RFC4710] would ensure that a RAQMON implementation using SNMP over UDP does not lead to congestion under heavy network load. 5. Acknowledgements The authors would like to thank Bill Walker and Joseph Mastroguilio from Avaya and Bin Hu from Motorola for their discussions. The authors would also like to extend special thanks to Randy Presuhn, who reviewed this document for spelling and formatting purposes, and who provided a deep review of the technical content. We also would like to thank Bert Wijnen for the permanent coaching during the evolution of this document and the detailed review of its final versions. The Security Considerations section was reviewed by Sam Hartman and Kurt D. Zeilenga and almost completely re-written by Mahalingam Mani. 6. Security Considerations [RFC4710] outlines a threat model associated with RAQMON and security considerations to be taken into account in the RAQMON specification to mitigate against those threats. It is imperative that RAQMON PDU implementations be able to provide the following protection mechanisms in order to attain end-to-end security: 1. Authentication: The RRC SHOULD be able to verify that a RAQMON report was originated by the RDS claiming to have sent it. At minimum, an RDS/RRC pair MUST use a digest-based authentication procedure to authenticate, like the one defined in [RFC1321]. 2. Privacy: RAQMON information includes identification of the parties participating in a communication session. RAQMON deployments SHOULD be able to provide protection from eavesdropping, and to prevent an unauthorized third party from gathering potentially sensitive information. This can be achieved by using secure transport protocols supporting confidentiality based on encryption technologies such as DES (Data Encryption Standard), [3DES], and AES (Advanced Encryption Standard) [AES]. 3. Protection from DoS attacks directed at the RRC: RDSs send RAQMON reports as a side effect of external events (for example, receipt of a phone call). An attacker can try to overwhelm the RRC (or the network) by initiating a large number of events in order to swamp the RRC with excessive numbers of RAQMON PDUs. Siddiqui, et al. Standards Track [Page 39] RFC 4712 Transport Mappings for RAQMON PDU October 2006 To prevent DoS attacks against the RRC, the RDS will send the first report for a session only after the session has been established, so that the session set-up process is not affected. 4. NAT and Firewall Friendly Design: The presence of IP addresses and TCP/UDP port information in RAQMON PDUs may be NAT- unfriendly. Where NAT-friendliness is a requirement, the RDS MAY omit IP address information from the RAQMON PDU. Another way to avoid this problem is by using NAT-Aware Application Layer Gateways (ALGs) to ensure that correct IP addresses appear in RAQMON PDUs. For the usage of TCP, TLS MUST be used to provide transport layer security. Section 6.1 describes the usage of TLS with RAQMON. This memo also defines the RAQMON-RDS-MIB module with the purpose of mapping the RAQMON PDUs into SNMP Notifications. To attain end-to- end security, the following measures have been taken in the RAQMON- RDS-MIB module design: There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. Consequently, if this MIB module is implemented correctly, there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: raqmonDsNotificationTable The objects in this table contain user session information, and their disclosure may be sensitive in some environments. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Siddiqui, et al. Standards Track [Page 40] RFC 4712 Transport Mappings for RAQMON PDU October 2006 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and confidentiality). It is a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6.1. Usage of TLS with RAQMON 6.1.1. Confidentiality & Message Integrity The subsequently authorized RAQMON data flow itself is protected by the same TLS security association that protects the client-side exchange. This standard TLS channel is now bound to the server through the above client-side authentication. The session itself is identified by the tuple {RDS ip-address:RDS_port / RRC ip-address: RRC port}. 6.1.2. TLS CipherSuites Several issues should be considered when selecting TLS ciphersuites that are appropriate for use in a given circumstance. These issues include the following: The ciphersuite's ability to provide adequate confidentiality protection for passwords and other data sent over the transport connection. Client and server implementers should recognize that some TLS ciphersuites provide no confidentiality protection, while other ciphersuites that do provide confidentiality protection may be vulnerable to being cracked using brute force methods, especially in light of ever-increasing CPU speeds that reduce the time needed to successfully mount such attacks. Client and server implementers should carefully consider the value of the password or data being protected versus the level of confidentiality protection provided by the ciphersuite to ensure that the level of protection afforded by the ciphersuite is appropriate. The ciphersuite's vulnerability (or lack thereof) to man-in-the- middle attacks. Ciphersuites vulnerable to man-in-the-middle attacks SHOULD NOT be used to protect passwords or sensitive data, unless the network configuration is such that the danger of a man-in-the-middle attack is negligible. Siddiqui, et al. Standards Track [Page 41] RFC 4712 Transport Mappings for RAQMON PDU October 2006 After a TLS negotiation (either initial or subsequent) is completed, both protocol peers should independently verify that the security services provided by the negotiated ciphersuite are adequate for the intended use of the RAQMON session. If not, the TLS layer should be closed. Spoofing Attacks: When anonymous TLS alone is negotiated without client authentication, the client's identity is never established. This easily allows any end-entity to establish a TLS-secured RAQMON connection to the RRC. This not only offers an opportunity to spoof legitimate RDS clients and hence compromise the integrity of RRC monitoring data, but also opens the RRC up to unauthorized clients posing as genuine RDS entities to launch a DoS by flooding data. RAQMON deployment policy MUST consider requiring RDS client authentication during TLS session establishment, especially when RDS clients communicate across unprotected internet. Insider attacks: Even client-authenticated TLS connections are open to spoofing attacks by one trusted client on another. Validation of RDS source address against RDS TLS-session source address SHOULD be performed to detect such attempts. 6.1.3. RAQMON Authorization State Every RAQMON session (between RDS and RRC) has an associated authorization state. This state is comprised of numerous factors such as what (if any) authorization state has been established, how it was established, and what security services are in place. Some factors may be determined and/or affected by protocol events (e.g., StartTLS, or TLS closure), and some factors may be determined by external events (e.g., time of day or server load). While it is often convenient to view authorization state in simplistic terms (as we often do in this technical specification) such as "an anonymous state", it is noted that authorization systems in RAQMON implementations commonly involve many factors that interrelate. Authorization in RAQMON is a local matter. One of the key factors in making authorization decisions is authorization identity. The initial session establishment defined in Section 2.2 allows information to be exchanged between the client and server to establish an authorization identity for the RAQMON session. The RRC is not to allow any RDS-transactions-related traffic through for processing until the client authentication is complete, unless anonymous authentication mode is negotiated. Siddiqui, et al. Standards Track [Page 42] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Upon initial establishment of the RAQMON session, the session has an anonymous authorization identity. Among other things, this implies that the client need not send a TLSStartRequired in the first PDU of the RAQMON message. The client may send any operation request prior to binding RDS to any authentication, and the RRC MUST treat it as if it had been performed after an anonymous RAQMON session start. The RDS automatically is placed in an unauthorized state upon RRC sending a TLSstart request to the RRC. It is noted that other events both internal and external to RAQMON may result in the authentication and authorization states being moved to an anonymous one. For instance, the establishment, change, or closure of data security services may result in a move to an anonymous state, or the user's credential information (e.g., certificate) may have expired. The former is an example of an event internal to RAQMON, whereas the latter is an example of an event external to RAQMON. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. Siddiqui, et al. Standards Track [Page 43] RFC 4712 Transport Mappings for RAQMON PDU October 2006 [RFC3411] Harrington, D., Preshun, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwalder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- time Application Quality-of-Service Monitoring (RAQMON)", RFC 4710, October 2006. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 7.2. Informative References [3DES] Americation National Standards Institute, "Triple Data Encryption Algorithm Modes of Operation", ANSI X9.52-1998. [AES] Federal Information Processing Standard (FIPS), "Specifications for the ADVANCED ENCRYPTION STANDARD(AES)", Publication 197, November 2001. [IEEE802.1D] "Information technology-Telecommunications and information exchange between systems--Local and metropolitan area networks-Common Specification a--Media access control (MAC) bridges:15802-3: 1998(ISO/IEC)", [ANSI/IEEE Std 802.1D Edition], 1998. [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, March 1992. [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. Siddiqui, et al. Standards Track [Page 44] RFC 4712 Transport Mappings for RAQMON PDU October 2006 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules", RFC 3737, April 2004. [RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006. [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. Siddiqui, et al. Standards Track [Page 45] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Appendix A. Pseudocode The implementation notes included in Appendix are for informational purposes only and are meant to clarify the RAQMON specification. Pseudocode for RDS & RRC We provide examples of pseudocode for aspects of RDS and RRC. There may be other implementation methods that are faster in particular operating environments or have other advantages. RDS: when (session starts} { report.identifier = session.endpoints, session.starttime; report.timestamp = 0; while (session in progress) { wait interval; report.statistics = update statistics; report.curtimestamp += interval; if encryption required report_data = encrypt(report, encrypt parameters); else report_data = report; raqmon_pdu = header, report_data; send raqmon-pdu; } } RRC: listen on raqmon port when ( raqmon_pdu received ) { decrypt raqmon_pdu.data if needed if report.identifier in database if report.current_time_stamp > last update update session statistics from report.statistics else discard report } Siddiqui, et al. Standards Track [Page 46] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Authors' Addresses Anwar Siddiqui Avaya 307 Middletown Lincroft Road Lincroft, NJ 80302 USA Phone: +1 732 852-3200 EMail: anwars@avaya.com Dan Romascanu Avaya Atidim Technology Park, Bldg #3 Tel Aviv, 61131 Israel Phone: +972-3-645-8414 EMail: dromasca@avaya.com Eugene Golovinsky Alert Logic Phone: +1 713 918-1816 EMail: gene@alertlogic.net Mahfuzur Rahman Samsung Information Systems America 75 West Plumeria Drive San Jose, CA 95134 USA Phone: +1 408 544-5559 Yongbum Yong Kim Broadcom 3151 Zanker Road San Jose, CA 95134 USA Phone: +1 408 501-7800 EMail: ybkim@broadcom.com Siddiqui, et al. Standards Track [Page 47] RFC 4712 Transport Mappings for RAQMON PDU October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Siddiqui, et al. Standards Track [Page 48] snmp-mibs-downloader-1.1/mibrfcs/rfc4747.txt0000644000000000000000000011417211402176072015576 0ustar Network Working Group S. Kipp Request for Comments: 4747 G. Ramkumar Category: Standards Track McDATA Corporation K. McCloghrie Cisco Systems November 2006 The Virtual Fabrics MIB 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. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabrics function. Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Short Overview of Fibre Channel .................................2 4. Relationship to Other MIBs ......................................3 5. MIB Overview ....................................................3 5.1. Fibre Channel Management Instance ..........................4 5.2. Representing Core and Virtual Switches .....................4 6. The T11-FC-VIRTUAL-FABRIC-MIB Module ............................5 7. Security Considerations ........................................16 8. IANA Considerations ............................................17 9. Acknowledgements ...............................................17 10. Normative References ..........................................17 11. Informative References ........................................18 Kipp, et al. Standards Track [Page 1] RFC 4747 Virtual Fabrics MIB November 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabric function. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of Fibre Channel The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Kipp, et al. Standards Track [Page 2] RFC 4747 Virtual Fabrics MIB November 2006 Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components (including the Fabric, each node, and most ports) have globally-unique names. These globally-unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a Fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy. Virtual Fabrics allow a single physical Fabric to be divided into multiple logical Fabrics. Each Virtual Fabric may be managed independently like traditional Fabrics. Virtual Fabrics are designed to achieve a better utilization of a physical infrastructure and to isolate events in one Virtual Fabric from affecting other Fabrics. When one Core Switch provides switching functions for multiple Virtual Fabrics, that Core Switch is modeled as containing multiple Virtual Switches, one for each Virtual Fabric. Each Virtual Fabric is identified by a 12-bit Virtual Fabric ID (VF_ID). When frames from multiple Virtual Fabrics are transmitted over a physical link, the VF_ID carried in a frame's Virtual Fabric Tagging Header (VFT_Header) identifies which Virtual Fabric the frame belongs to. The use of VFT_Headers is enabled through an initial negotiation exchange between the two connected ports. 4. Relationship to Other MIBs This MIB extends beyond [RFC4044] to cover the functionality, in Fibre Channel switches, of providing Fibre Channel's Virtual Fabrics function. 5. MIB Overview This MIB module provides the means for monitoring the operation of, and configuring some parameters of, one or more instances of Fibre Channel Virtual Fabric functionality. (Note that there are no definitions in this MIB module of "managed actions" which can be invoked via a remote network management protocol such as SNMP.) Kipp, et al. Standards Track [Page 3] RFC 4747 Virtual Fabrics MIB November 2006 The following MIB module has IMPORTS from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC4044], and [RFC4439]. In REFERENCE clauses, it refers to [FC-SW-4]. 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [RFC4044] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [RFC4044] as the index value to uniquely identify each Fibre Channel management instance, for example within the same SNMP context ([RFC3411] section 3.3.1). The t11vfVirtualSwitchTable augments the fcmSwitchTable, and the primary index variable of the fcmSwitchTable is fcmInstanceIndex. 5.2. Representing Core and Virtual Switches In the presence of Virtual Switches, fcmSwitchTable in RFC4044 contains a row for each Virtual Switch. fcmSwitchTable, t11vfCoreSwitchTable, and t11vfVirtualSwitchTable are complementary. The t11vfCoreSwitchTable and t11vfVirtualSwitchTable contain information that helps the management client determine which Switches are Virtual Switches and how each relates to a Core Switch. A Virtual Switch must reside in a single Core Switch, and a Core Switch is defined as a set of entities with the same Core Switch_Name. RFC 4044 was defined before Virtual Switches were standard and represented only physical Switches, so the RFC 4044 tables were not defined as read-create. With the advent of Virtual Switches, Virtual Switches can now be created by administrators, and read-create tables are required. The StorageType of RFC 4044 tables were not defined, and StorageTypes used in this MIB should also apply to the RFC 4044 tables that this MIB augments. Kipp, et al. Standards Track [Page 4] RFC 4747 Virtual Fabrics MIB November 2006 6. The T11-FC-VIRTUAL-FABRIC-MIB Module T11-FC-VIRTUAL-FABRIC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndex FROM IF-MIB -- [RFC2863] fcmInstanceIndex, FcNameIdOrZero, fcmPortEntry, fcmSwitchEntry FROM FC-MGMT-MIB -- [RFC4044] T11FabricIndex FROM T11-TC-MIB; -- [RFC4439] t11FcVirtualFabricMIB MODULE-IDENTITY LAST-UPDATED "200611100000Z" ORGANIZATION "IETF IMSS (Internet and Management Support for Storage) Working Group" CONTACT-INFO " Scott Kipp McDATA Corporation Tel: +1 720 558-3452 E-mail: scott.kipp@mcdata.com Postal: 4 McDATA Parkway Broomfield, CO USA 80021 G D Ramkumar SnapTell, Inc. Tel: +1 650-326-7627 E-mail: gramkumar@stanfordalumni.org Postal: 2741 Middlefield Rd, Suite 200 Palo Alto, CA USA 94306 Keith McCloghrie Cisco Systems, Inc. Tel: +1 408 526-5260 E-mail: kzm@cisco.com Postal: 170 West Tasman Drive San Jose, CA USA 95134 " DESCRIPTION "This module defines management information specific to Fibre Channel Virtual Fabrics. A Virtual Fabric is a Kipp, et al. Standards Track [Page 5] RFC 4747 Virtual Fabrics MIB November 2006 Fabric composed of partitions of switches, links and N_Ports with a single Fabric management domain, Fabric Services and independence from other Virtual Fabrics. Copyright (C) The IETF Trust (2006). This version of this MIB module is part of RFC 4747; see the RFC itself for full legal notices." REVISION "200611100000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4747." ::= { mib-2 147 } t11vfObjects OBJECT IDENTIFIER ::= { t11FcVirtualFabricMIB 1 } t11vfConformance OBJECT IDENTIFIER ::= { t11FcVirtualFabricMIB 2 } --******************************** -- MIB object definitions -- t11vfCoreSwitchTable OBJECT-TYPE SYNTAX SEQUENCE OF T11vfCoreSwitchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of core switches supported by the current management entity." ::= { t11vfObjects 1 } t11vfCoreSwitchEntry OBJECT-TYPE SYNTAX T11vfCoreSwitchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents one core switch." INDEX { fcmInstanceIndex, t11vfCoreSwitchSwitchName } ::= { t11vfCoreSwitchTable 1} T11vfCoreSwitchEntry ::= SEQUENCE { t11vfCoreSwitchSwitchName FcNameIdOrZero, t11vfCoreSwitchMaxSupported Unsigned32, t11vfCoreSwitchStorageType StorageType } t11vfCoreSwitchSwitchName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8 | 16)) MAX-ACCESS not-accessible STATUS current Kipp, et al. Standards Track [Page 6] RFC 4747 Virtual Fabrics MIB November 2006 DESCRIPTION "The Core Switch_Name (WWN) of this Core Switch." ::= { t11vfCoreSwitchEntry 1 } t11vfCoreSwitchMaxSupported OBJECT-TYPE SYNTAX Unsigned32 (1..4095) MAX-ACCESS read-write STATUS current DESCRIPTION "In switches that do not support Virtual Fabrics, this object has the value of 1. If Virtual Fabrics are supported, this object is the maximum number of Virtual Fabrics supported by the Core Switch. For the purpose of this count, the Control VF_ID is ignored." ::= { t11vfCoreSwitchEntry 2 } t11vfCoreSwitchStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11vfCoreSwitchEntry 3 } -- Virtual Switch table t11vfVirtualSwitchTable OBJECT-TYPE SYNTAX SEQUENCE OF T11vfVirtualSwitchEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Virtual Switches. When one Core Switch provides switching functions for multiple Virtual Fabrics, that Core Switch is modeled as containing multiple Virtual Switches, one for each Virtual Fabric. This table contains one row for every Virtual Switch on every Core Switch. This table augments the basic switch information in the fcmSwitchTable Table in the FC-MGMT-MIB." REFERENCE "fcmSwitchTable is defined in the FC-MGMT-MIB [RFC4044]." ::= { t11vfObjects 2 } t11vfVirtualSwitchEntry OBJECT-TYPE SYNTAX T11vfVirtualSwitchEntry Kipp, et al. Standards Track [Page 7] RFC 4747 Virtual Fabrics MIB November 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of the Virtual Switch table. Each row is for a Virtual Switch. This table augments the fcmSwitchTable, i.e., every entry in this table has a one-to-one correspondence with an entry in the fcmSwitchTable. At the time when the fcmSwitchTable was defined, it applied to physical switches. With the definition and usage of virtual switches, fcmSwitchTable now applies to virtual switches as well as physical switches, and (in contrast to physical switches) it is appropriate to provide the capability for virtual switches to be created via remote management applications, e.g., via SNMP. So, this entry contains a RowStatus object (to allow the creation of a virtual switch), as well as a StorageType object. Obviously, if a row is created/deleted in this table, the corresponding row in the fcmSwitchTable will be created/deleted." REFERENCE "fcmSwitchEntry is defined in the FC-MGMT-MIB module [RFC4044]." AUGMENTS { fcmSwitchEntry } ::= { t11vfVirtualSwitchTable 1} T11vfVirtualSwitchEntry ::= SEQUENCE { t11vfVirtualSwitchVfId T11FabricIndex, t11vfVirtualSwitchCoreSwitchName FcNameIdOrZero, t11vfVirtualSwitchRowStatus RowStatus, t11vfVirtualSwitchStorageType StorageType } t11vfVirtualSwitchVfId OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The VF_ID of the Virtual Fabric for which this virtual switch performs its switching function. The Control VF_ID is implicitly enabled and is not set. Communication with the Control VF_ID is required." REFERENCE "FC-SW-4, REV 7.5, section 12.2" ::= { t11vfVirtualSwitchEntry 1 } Kipp, et al. Standards Track [Page 8] RFC 4747 Virtual Fabrics MIB November 2006 t11vfVirtualSwitchCoreSwitchName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8 | 16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Core Switch_Name (WWN) of the Core Switch that contains this Virtual Switch." REFERENCE "FC-SW-4, REV 7.5, section 12.2." ::= { t11vfVirtualSwitchEntry 2 } t11vfVirtualSwitchRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row." ::= { t11vfVirtualSwitchEntry 3 } t11vfVirtualSwitchStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11vfVirtualSwitchEntry 4 } -- Port table t11vfPortTable OBJECT-TYPE SYNTAX SEQUENCE OF T11vfPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Port attributes related to Virtual Fabrics." ::= { t11vfObjects 3 } t11vfPortEntry OBJECT-TYPE SYNTAX T11vfPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a physical Port on a switch. Switches that support Virtual Fabrics would add Kipp, et al. Standards Track [Page 9] RFC 4747 Virtual Fabrics MIB November 2006 these four additional columns to the fcmPortEntry row." REFERENCE "fcmPortEntry is defined in the FC-MGMT-MIB module." AUGMENTS { fcmPortEntry } ::= { t11vfPortTable 1} T11vfPortEntry ::= SEQUENCE { t11vfPortVfId T11FabricIndex, t11vfPortTaggingAdminStatus INTEGER, t11vfPortTaggingOperStatus INTEGER, t11vfPortStorageType StorageType } t11vfPortVfId OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS read-write STATUS current DESCRIPTION "The Port VF_ID assigned to this Port. The Port VF_ID is the default Virtual Fabric that is assigned to untagged frames arriving at this Port. The Control VF_ID is implicitly enabled and is not set. Communication with the Control VF_ID is required." REFERENCE "FC-SW-4, REV 7.5, section 12.1" DEFVAL {1} ::= { t11vfPortEntry 1 } t11vfPortTaggingAdminStatus OBJECT-TYPE SYNTAX INTEGER { off(1), on(2), auto(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to configure the administrative status of Virtual Fabric tagging on this Port. SET operation Description -------------- ------------------------------------------- off(1) To disable Virtual Fabric tagging on this Port. on(2) To enable Virtual Fabric tagging on this Kipp, et al. Standards Track [Page 10] RFC 4747 Virtual Fabrics MIB November 2006 Port if the attached Port doesn't prohibit it. auto(3) To enable Virtual Fabric tagging if the peer requests it." REFERENCE "FC-SW-4, REV 7.5, section 12.4" ::= { t11vfPortEntry 2 } t11vfPortTaggingOperStatus OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to report the operational status of Virtual Fabric tagging on this Port. SET operation Description -------------- ------------------------------------------- off(1) Virtual Fabric tagging is disabled on this Port. on(2) Virtual Fabric tagging is enabled on this Port." REFERENCE "FC-SW-4, REV 7.5, section 12.4" ::= { t11vfPortEntry 3 } t11vfPortStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "The storage type for this conceptual row, and for the corresponding row in the augmented fcmPortTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11vfPortEntry 4 } -- Locally Enabled Table t11vfLocallyEnabledTable OBJECT-TYPE Kipp, et al. Standards Track [Page 11] RFC 4747 Virtual Fabrics MIB November 2006 SYNTAX SEQUENCE OF T11vfLocallyEnabledEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table for assigning and reporting operational status of locally-enabled Virtual Fabric IDs to Ports. The set of Virtual Fabrics operational on the Port is the bit-wise 'AND' of the set of locally-enabled VF_IDs of this Port and the locally-enabled VF_IDs of the attached Port." ::= { t11vfObjects 4 } t11vfLocallyEnabledEntry OBJECT-TYPE SYNTAX T11vfLocallyEnabledEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for each locally-enabled VF_ID on each Port." REFERENCE "FC-SW-4, REV 7.5, section 12.4" INDEX { t11vfLocallyEnabledPortIfIndex, t11vfLocallyEnabledVfId } ::= { t11vfLocallyEnabledTable 1} T11vfLocallyEnabledEntry ::= SEQUENCE { t11vfLocallyEnabledPortIfIndex InterfaceIndex, t11vfLocallyEnabledVfId T11FabricIndex, t11vfLocallyEnabledOperStatus INTEGER, t11vfLocallyEnabledRowStatus RowStatus, t11vfLocallyEnabledStorageType StorageType } t11vfLocallyEnabledPortIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of the ifIndex that identifies the Port." ::= { t11vfLocallyEnabledEntry 1 } t11vfLocallyEnabledVfId OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-enabled VF_ID on this Port." ::= { t11vfLocallyEnabledEntry 2 } Kipp, et al. Standards Track [Page 12] RFC 4747 Virtual Fabrics MIB November 2006 t11vfLocallyEnabledOperStatus OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to report the operational status of Virtual Fabric tagging on this Port. SET operation Description -------------- ------------------------------------------- off(1) Virtual Fabric tagging is disabled on this Port. on(2) Virtual Fabric tagging is enabled on this Port." REFERENCE "FC-SW-4, REV 7.3, section 12.4" ::= { t11vfLocallyEnabledEntry 3 } t11vfLocallyEnabledRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. When a row in this table is in 'active(1)' state, no object in that row can be modified except t11vfLocallyEnabledRowStatus and t11vfLocallyEnabledStorageType." ::= { t11vfLocallyEnabledEntry 4 } t11vfLocallyEnabledStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { t11vfLocallyEnabledEntry 5 } --******************************** Kipp, et al. Standards Track [Page 13] RFC 4747 Virtual Fabrics MIB November 2006 -- Conformance Section -- t11vfMIBCompliances OBJECT IDENTIFIER ::= { t11vfConformance 1 } t11vfMIBGroups OBJECT IDENTIFIER ::= { t11vfConformance 2 } t11vfMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for compliance to the Fibre Channel Virtual Fabric MIB." MODULE -- this module MANDATORY-GROUPS { t11vfGeneralGroup } OBJECT t11vfCoreSwitchMaxSupported MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfCoreSwitchStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfVirtualSwitchVfId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfVirtualSwitchRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfVirtualSwitchStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfPortVfId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfPortTaggingAdminStatus MIN-ACCESS read-only DESCRIPTION Kipp, et al. Standards Track [Page 14] RFC 4747 Virtual Fabrics MIB November 2006 "Write access is not required." OBJECT t11vfPortStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfLocallyEnabledRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11vfLocallyEnabledStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11vfMIBCompliances 1 } -- Units of conformance t11vfGeneralGroup OBJECT-GROUP OBJECTS { t11vfCoreSwitchMaxSupported, t11vfVirtualSwitchVfId, t11vfVirtualSwitchCoreSwitchName, t11vfVirtualSwitchRowStatus, t11vfPortVfId, t11vfPortTaggingAdminStatus, t11vfLocallyEnabledOperStatus, t11vfPortTaggingOperStatus, t11vfLocallyEnabledRowStatus, t11vfCoreSwitchStorageType, t11vfVirtualSwitchStorageType, t11vfPortStorageType, t11vfLocallyEnabledStorageType } STATUS current DESCRIPTION "A collection of objects for monitoring and configuring Virtual Fabrics in a Fibre Channel switch." ::= { t11vfMIBGroups 1 } END Kipp, et al. Standards Track [Page 15] RFC 4747 Virtual Fabrics MIB November 2006 7. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: t11vfCoreSwitchMaxSupported, t11vfVirtualSwitchVfId, t11vfCoreSwitchStorageType, t11vfVirtualSwitchStorageType and t11vfVirtualSwitchRowStatus - the ability to change the configuration of Virtual Fabrics on a particular switch. t11vfPortTaggingAdminStatus, t11vfLocallyEnabledRowStatus, t11vfPortVfId, t11vfPortStorageType and t11vfLocallyEnabledStorageType - the ability to change the configuration of Virtual Fabrics on a port of a particular switch. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: t11vfVirtualSwitchCoreSwitchName, t11vfPortTaggingOperStatus, t11vfLocallyEnabledOperStatus, - the ability to discover configuration of Virtual Fabrics on a virtual switch or a port. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Kipp, et al. Standards Track [Page 16] RFC 4747 Virtual Fabrics MIB November 2006 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations IANA has assigned 147 for the MIB module under the appropriate subtree. 9. Acknowledgements This document was developed by the INCITS Task Group T11.5. We wish to acknowledge the contributions and comments from the INCITS Technical Committee T11 and the IMSS WG, including the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio Desanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec IMSS WG Chair: David Black, EMC Corporation Bert Wijnen, Lucent 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. Kipp, et al. Standards Track [Page 17] RFC 4747 Virtual Fabrics MIB November 2006 [RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, March 2006. [FC-FS] "Fibre Channel Framing and Signaling - 2 (FC-FS-2)", ANSI INCITS 1619-D, http://www.t11.org/t11/stat.nsf/upnum/1619-d, 2006. [FC-SW-4] "Fibre Channel Switch Fabric 4 (FC-SW-4)", ANSI INCITS 418-2006, http://www.t11.org/t11/stat.nsf/upnum/1674-d, 2006. 11. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Kipp, et al. Standards Track [Page 18] RFC 4747 Virtual Fabrics MIB November 2006 Authors' Addresses Scott Kipp McDATA Corporation 4 McDATA Parkway Broomfield, CO 80021 Phone: +1 720-558-3452 EMail: scott.kipp@mcdata.com G D Ramkumar SnapTell, Inc. 2741 Middlefield Rd, Suite 200 Palo Alto, CA 94306 Phone: +1 650-326-7627 EMail: gramkumar@stanfordalumni.org Keith McCloghrie Cisco Systems 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com Kipp, et al. Standards Track [Page 19] RFC 4747 Virtual Fabrics MIB November 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kipp, et al. Standards Track [Page 20] snmp-mibs-downloader-1.1/mibrfcs/rfc4750.txt0000644000000000000000000066237311402176072015603 0ustar Network Working Group D. Joyal, Ed. Request for Comments: 4750 Nortel Obsoletes: 1850 P. Galecki, Ed. Category: Standards Track Airvana S. Giacalone, Ed. CSFB Original Authors: R. Coltun Touch Acoustra F. Baker Cisco Systems December 2006 OSPF Version 2 Management Information Base 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. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B. Galecki, et al. Standards Track [Page 1] RFC 4750 OSPFv2 MIB December 2006 Table of Contents 1. Overview ........................................................3 1.1. The Internet-Standard Management Framework .................3 1.2. Conceptual Row Creation ....................................3 1.3. Default Configuration ......................................4 1.4. OSPF Counters ..............................................5 1.5. Multiple OSPF Instances ....................................5 1.6. Conventions ................................................6 2. Structure of This MIB ...........................................6 2.1. The Purposes of the Sections in This MIB ...................6 2.1.1. General Variables ...................................6 2.1.2. Area Data Structure and Area Stub Metric Table ......6 2.1.3. Link State Database and External Link State Database ............................................7 2.1.4. Address Table and Host Tables .......................7 2.1.5. Interface and Interface Metric Tables ...............7 2.1.6. Virtual Interface Table .............................7 2.1.7. Neighbor and Virtual Neighbor Tables ................7 2.1.8. Local Link State Database Table and Virtual Local Link State Database Table .....................7 2.1.9. AS-scope Link State Database Table ..................7 2.1.10. Area LSA Count Table ...............................7 3. OSPF MIB Module .................................................8 4. OSPF Trap Overview .............................................94 4.1. Introduction ..............................................94 4.2. Approach ..................................................95 4.3. Ignoring Initial Activity .................................95 4.4. Throttling Traps ..........................................95 4.5. One Trap Per OSPF Event ...................................96 4.6. Polling Event Counters ....................................96 4.7. Translating Notification Parameters .......................97 4.8. Historical Artifacts ......................................97 5. OSPF Trap Definitions ..........................................98 6. Security Considerations .......................................110 7. IANA Considerations ...........................................111 8. Acknowledgements ..............................................111 9. References ....................................................111 9.1. Normative References .....................................111 9.2. Informative References ...................................111 Appendix A. TOS Support ..........................................113 Appendix B. Changes from RFC 1850 ................................113 B.1. General Group Changes ....................................113 B.2. OSPF NSSA Enhancement Support ............................113 B.3. Opaque LSA Support .......................................114 B.4. Graceful Restart Support .................................116 B.5. OSPF Compliances .........................................116 B.6. OSPF Authentication and Security .........................117 Galecki, et al. Standards Track [Page 2] RFC 4750 OSPFv2 MIB December 2006 B.7. OSPF Trap MIB ............................................117 B.8. Miscellaneous ............................................118 1. Overview 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.2. Conceptual Row Creation For the benefit of row-creation in "conceptual" tables, DEFVAL (Default Value) clauses are included in the definitions in section 3, suggesting values that an agent should use for instances of variables that need to be created due to a Set-Request, but that are not specified in the Set-Request. DEFVAL clauses have not been specified for some objects that are read-only, implying that they are zeroed upon row creation. These objects are of the SYNTAX Counter32 or Gauge32. For those objects not having a DEFVAL clause, both management stations and agents should heed the Robustness Principle of the Internet (see [RFC791]): "be liberal in what you accept, conservative in what you send" Therefore, management stations should include as many of these columnar objects as possible (e.g., all read-write objects) in a Set-Request when creating a conceptual row. Agents should accept a Set-Request with as few of these columnar objects as they need (e.g., the minimum contents of a "row-creating" SET consists of those objects for which, as they cannot be intuited, no default is specified). Galecki, et al. Standards Track [Page 3] RFC 4750 OSPFv2 MIB December 2006 1.3. Default Configuration OSPF is a powerful routing protocol, equipped with features to handle virtually any configuration requirement that might reasonably be found within an Autonomous System (AS). With this power comes a fair degree of complexity, which the sheer number of objects in the MIB will attest to. Care has therefore been taken, in constructing this MIB, to define default values for virtually every object, to minimize the amount of parameterization required in the typical case. That default configuration is as follows: Given the following assumptions: - IP has already been configured. - The ifTable has already been configured. - ifSpeed is estimated by the interface drivers. - The OSPF process automatically discovers all IP interfaces and creates corresponding OSPF interfaces. - The OSPF process automatically creates the areas required for the interfaces. The simplest configuration of an OSPF process requires the following: - The OSPF process be enabled. This can be accomplished with a single SET: ospfAdminStat := enabled. The configured system will have the following attributes: - The RouterID will be one of the IP addresses of the device. - The device will be neither an Area Border Router nor an Autonomous System Border Router. - Every IP interface, with or without an address, will be an OSPF interface. - The AreaID of each interface will be 0.0.0.0, the backbone. - Authentication will be disabled. Galecki, et al. Standards Track [Page 4] RFC 4750 OSPFv2 MIB December 2006 - All broadcast and point-to-point interfaces will be operational. Non-broadcast multi-access (NBMA) interfaces require the configuration of at least one neighbor. - Timers on all direct interfaces will be: Hello Interval: 10 seconds Dead Timeout: 40 Seconds Retransmission: 5 Seconds Transit Delay: 1 Second Poll Interval: 120 Seconds - No direct links to hosts will be configured. - No addresses will be summarized. - Metrics, being a measure of bit duration, are unambiguous and intelligent. - No virtual links will be configured. 1.4. OSPF Counters This MIB defines several counters, namely: - ospfOriginateNewLsas, ospfRxNewLsas in the ospfGeneralGroup - ospfSpfRuns, ospfAreaNssaTranslatorEvents in the ospfAreaTable - ospfIfEvents in the ospfIfTable - ospfVirtIfEvents in the ospfVirtIfTable - ospfNbrEvents in the ospfNbrTable - ospfVirtNbrEvents in the ospfVirtNbrTable As a best practice, a management entity, when reading these counters, should use the discontinuity object, ospfDiscontinuityTime, to determine if an event that would invalidate the management entity understanding of the counters has occurred. A restart of the OSPF routing process is a possible example of a discontinuity event. 1.5. Multiple OSPF Instances SNMPv3 supports "Contexts" that can be used to implement MIB views on multiple OSPF instances on the same system. See [RFC3411] or its successors for details. Galecki, et al. Standards Track [Page 5] RFC 4750 OSPFv2 MIB December 2006 1.6. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Structure of This MIB This MIB is composed of the following sections: General Variables Area Data Structure Area Stub Metric Table Link State Database (LSDB) Address Range Table Host Table Interface Table Interface Metric Table Virtual Interface Table Neighbor Table Virtual Neighbor Table External Link State Database Aggregate Range Table Local Link State Database AS-scope Link State Database It supports the base OSPFv2 specification [RFC2328] and extensions to OSPFv2 such as [RFC1765], [RFC1793], [RFC2370], [RFC3101] and [RFC3623]. There exists a separate MIB for notifications ("traps"), which is entirely optional. 2.1. The Purposes of the Sections in This MIB 2.1.1. General Variables The general variables describe (as it may seem from the name) variables that are global to the OSPF Process. 2.1.2. Area Data Structure and Area Stub Metric Table The Area Data Structure describes all of the OSPF Areas that the router participates in. The Area Table includes data for Not-So- Stubby-Area (NSSA) translation. The Area Stub Metric Table describes the metrics advertised into a stub area by the default router(s). Galecki, et al. Standards Track [Page 6] RFC 4750 OSPFv2 MIB December 2006 2.1.3. Link State Database and External Link State Database The link state database is provided primarily to provide detailed information for network debugging. 2.1.4. Address Table and Host Tables The Address Range Table and Host Table are provided to view configured Network Summary and host route information. 2.1.5. Interface and Interface Metric Tables The Interface Table and the Interface Metric Table together describe the various IP interfaces to OSPF. The metrics are placed in separate tables in order to simplify dealing with multiple types of service. The Interface table includes link-local (Opaque type-9) link state advertisement (LSA) statistics. 2.1.6. Virtual Interface Table The Virtual Interface Table describes virtual links to the OSPF Process, similarly to the (non-virtual) Interface Tables. This Table includes link-local (Opaque type-9) LSA statistics. 2.1.7. Neighbor and Virtual Neighbor Tables The Neighbor Table and the Virtual Neighbor Table describe the neighbors to the OSPF Process. 2.1.8. Local Link State Database Table and Virtual Local Link State Database Table The Local Link State Database Table and Virtual Local Link State Database Table are identical to the OSPF LSDB Table in format, but contain only link-local (Opaque type-9) link state advertisements for non-virtual and virtual links. 2.1.9. AS-scope Link State Database Table The AS-scope Link State Database Table is identical to the OSPF LSDB Table in format, but contains only AS-scoped link state advertisements. 2.1.10. Area LSA Count Table The table, which maintains number of link state advertisements on the per-area, per-LSA-type basis. Galecki, et al. Standards Track [Page 7] RFC 4750 OSPFv2 MIB December 2006 3. OSPF MIB Module OSPF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndexOrZero FROM IF-MIB; ospf MODULE-IDENTITY LAST-UPDATED "200611100000Z" -- November 10, 2006 00:00:00 EST ORGANIZATION "IETF OSPF Working Group" CONTACT-INFO "WG E-Mail: ospf@ietf.org WG Chairs: acee@cisco.com rohit@gmail.com Editors: Dan Joyal Nortel 600 Technology Park Drive Billerica, MA 01821 djoyal@nortel.com Piotr Galecki Airvana 19 Alpha Road Chelmsford, MA 01824 pgalecki@airvana.com Spencer Giacalone CSFB Eleven Madison Ave New York, NY 10010-3629 spencer.giacalone@gmail.com" DESCRIPTION "The MIB module to describe the OSPF Version 2 Protocol. Note that some objects in this MIB module may pose a significant security risk. Refer to the Security Considerations section in RFC 4750 for more information. Galecki, et al. Standards Track [Page 8] RFC 4750 OSPFv2 MIB December 2006 Copyright (C) The IETF Trust (2006). This version of this MIB module is part of RFC 4750; see the RFC itself for full legal notices." REVISION "200611100000Z" -- November 10, 2006 09:00:00 EST DESCRIPTION "Updated for latest changes to OSPF Version 2: - updated the General Group with the new ospfRFC1583Compatibility, ospfReferenceBandwidth and ospfDiscontinuityTime objects - added graceful-restart-related objects - added stub-router-related objects - updated the Area Table with NSSA-related objects - added ospfAreaAggregateExtRouteTag object - added Opaque LSA-related objects - updates to the Compliances and Security sections - added area LSA counter table - added section describing translation of notification parameters between SNMP versions - added ospfComplianceObsolete to contain obsolete object groups - deprecated ospfExtLsdbTable See Appendix B of RFC 4750 for more details. This version published as part of RFC 4750" REVISION "199501201225Z" -- Fri Jan 20 12:25:50 PST 1995 DESCRIPTION "The initial SMIv2 revision of this MIB module, published in RFC 1850." ::= { mib-2 14 } AreaID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An OSPF Area Identifier. Note that the Area ID, in OSPF, has the same format as an IP address, but has the function of defining a summarization point for link state advertisements." SYNTAX IpAddress RouterID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A OSPF Router Identifier. Note that the Router ID, in OSPF, has the same format as an IP address, but identifies the router independent Galecki, et al. Standards Track [Page 9] RFC 4750 OSPFv2 MIB December 2006 of its IP address." SYNTAX IpAddress Metric ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-0" STATUS current DESCRIPTION "The OSPF internal metric. Note that the OSPF metric is defined as an unsigned value in the range." SYNTAX Integer32 (0..'FFFF'h) BigMetric ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-0" STATUS current DESCRIPTION "The OSPF external metric." SYNTAX Integer32 (0..'FFFFFF'h) Status ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An indication of the operability of an OSPF function or feature. For example, the status of an interface: 'enabled' indicates that it is willing to communicate with other OSPF routers, and 'disabled' indicates that it is not." SYNTAX INTEGER { enabled (1), disabled (2) } PositiveInteger ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-0" STATUS current DESCRIPTION "A positive integer. Values in excess are precluded as unnecessary and prone to interoperability issues." SYNTAX Integer32 (0..'7FFFFFFF'h) HelloRange ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-0" STATUS current DESCRIPTION "The range of intervals in seconds on which Hello messages are exchanged." SYNTAX Integer32 (1..'FFFF'h) UpToMaxAge ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-0" STATUS current Galecki, et al. Standards Track [Page 10] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The values in seconds that one might find or configure for variables bounded by the maximum age of an LSA." SYNTAX Integer32 (0..3600) DesignatedRouterPriority ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-0" STATUS current DESCRIPTION "The range of values defined for the priority of a system for becoming the designated router." SYNTAX Integer32 (0..'FF'h) TOSType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-0" STATUS current DESCRIPTION "Type of Service (TOS) is defined as a mapping to the IP Type of Service Flags as defined in the IP Forwarding Table MIB +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TYPE OF SERVICE | 0 | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ IP TOS IP TOS Field Policy Field Policy Contents Code Contents Code 0 0 0 0 ==> 0 0 0 0 1 ==> 2 0 0 1 0 ==> 4 0 0 1 1 ==> 6 0 1 0 0 ==> 8 0 1 0 1 ==> 10 0 1 1 0 ==> 12 0 1 1 1 ==> 14 1 0 0 0 ==> 16 1 0 0 1 ==> 18 1 0 1 0 ==> 20 1 0 1 1 ==> 22 1 1 0 0 ==> 24 1 1 0 1 ==> 26 1 1 1 0 ==> 28 1 1 1 1 ==> 30 The remaining values are left for future definition." SYNTAX Integer32 (0..30) OspfAuthenticationType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The authentication type." SYNTAX INTEGER { Galecki, et al. Standards Track [Page 11] RFC 4750 OSPFv2 MIB December 2006 none (0), simplePassword (1), md5 (2) -- reserved for specification by IANA (> 2) } -- OSPF General Variables -- Note: These parameters apply globally to the Router's -- OSPF Process. ospfGeneralGroup OBJECT IDENTIFIER ::= { ospf 1 } ospfRouterId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-write STATUS current DESCRIPTION "A 32-bit integer uniquely identifying the router in the Autonomous System. By convention, to ensure uniqueness, this should default to the value of one of the router's IP interface addresses. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, C.1 Global parameters" ::= { ospfGeneralGroup 1 } ospfAdminStat OBJECT-TYPE SYNTAX Status MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative status of OSPF in the router. The value 'enabled' denotes that the OSPF Process is active on at least one interface; 'disabled' disables it on all interfaces. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." ::= { ospfGeneralGroup 2 } ospfVersionNumber OBJECT-TYPE SYNTAX INTEGER { version2 (2) } MAX-ACCESS read-only STATUS current Galecki, et al. Standards Track [Page 12] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The current version number of the OSPF protocol is 2." REFERENCE "OSPF Version 2, Title" ::= { ospfGeneralGroup 3 } ospfAreaBdrRtrStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag to note whether this router is an Area Border Router." REFERENCE "OSPF Version 2, Section 3 Splitting the AS into Areas" ::= { ospfGeneralGroup 4 } ospfASBdrRtrStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "A flag to note whether this router is configured as an Autonomous System Border Router. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Section 3.3 Classification of routers" ::= { ospfGeneralGroup 5 } ospfExternLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of external (LS type-5) link state advertisements in the link state database." REFERENCE "OSPF Version 2, Appendix A.4.5 AS external link advertisements" ::= { ospfGeneralGroup 6 } ospfExternLsaCksumSum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only Galecki, et al. Standards Track [Page 13] RFC 4750 OSPFv2 MIB December 2006 STATUS current DESCRIPTION "The 32-bit sum of the LS checksums of the external link state advertisements contained in the link state database. This sum can be used to determine if there has been a change in a router's link state database and to compare the link state database of two routers. The value should be treated as unsigned when comparing two sums of checksums." ::= { ospfGeneralGroup 7 } ospfTOSSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The router's support for type-of-service routing. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Appendix F.1.2 Optional TOS support" ::= { ospfGeneralGroup 8 } ospfOriginateNewLsas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of new link state advertisements that have been originated. This number is incremented each time the router originates a new LSA. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfGeneralGroup 9 } ospfRxNewLsas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Galecki, et al. Standards Track [Page 14] RFC 4750 OSPFv2 MIB December 2006 "The number of link state advertisements received that are determined to be new instantiations. This number does not include newer instantiations of self-originated link state advertisements. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfGeneralGroup 10 } ospfExtLsdbLimit OBJECT-TYPE SYNTAX Integer32 (-1..'7FFFFFFF'h) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of non-default AS-external LSAs entries that can be stored in the link state database. If the value is -1, then there is no limit. When the number of non-default AS-external LSAs in a router's link state database reaches ospfExtLsdbLimit, the router enters overflow state. The router never holds more than ospfExtLsdbLimit non-default AS-external LSAs in its database. OspfExtLsdbLimit MUST be set identically in all routers attached to the OSPF backbone and/or any regular OSPF area (i.e., OSPF stub areas and NSSAs are excluded). This object is persistent and when written the entity SHOULD save the change to non-volatile storage." DEFVAL { -1 } ::= { ospfGeneralGroup 11 } ospfMulticastExtensions OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A bit mask indicating whether the router is forwarding IP multicast (Class D) datagrams based on the algorithms defined in the multicast extensions to OSPF. Bit 0, if set, indicates that the router can Galecki, et al. Standards Track [Page 15] RFC 4750 OSPFv2 MIB December 2006 forward IP multicast datagrams in the router's directly attached areas (called intra-area multicast routing). Bit 1, if set, indicates that the router can forward IP multicast datagrams between OSPF areas (called inter-area multicast routing). Bit 2, if set, indicates that the router can forward IP multicast datagrams between Autonomous Systems (called inter-AS multicast routing). Only certain combinations of bit settings are allowed, namely: 0 (no multicast forwarding is enabled), 1 (intra-area multicasting only), 3 (intra-area and inter-area multicasting), 5 (intra-area and inter-AS multicasting), and 7 (multicasting everywhere). By default, no multicast forwarding is enabled. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." DEFVAL { 0 } ::= { ospfGeneralGroup 12 } ospfExitOverflowInterval OBJECT-TYPE SYNTAX PositiveInteger MAX-ACCESS read-write STATUS current DESCRIPTION "The number of seconds that, after entering OverflowState, a router will attempt to leave OverflowState. This allows the router to again originate non-default AS-external LSAs. When set to 0, the router will not leave overflow state until restarted. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." DEFVAL { 0 } ::= { ospfGeneralGroup 13 } ospfDemandExtensions OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write Galecki, et al. Standards Track [Page 16] RFC 4750 OSPFv2 MIB December 2006 STATUS current DESCRIPTION "The router's support for demand routing. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "Extending OSPF to Support Demand Circuits" ::= { ospfGeneralGroup 14 } ospfRFC1583Compatibility OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates metrics used to choose among multiple AS-external LSAs. When RFC1583Compatibility is set to enabled, only cost will be used when choosing among multiple AS-external LSAs advertising the same destination. When RFC1583Compatibility is set to disabled, preference will be driven first by type of path using cost only to break ties. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Section 16.4.1 External path preferences" ::= { ospfGeneralGroup 15 } ospfOpaqueLsaSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The router's support for Opaque LSA types." REFERENCE "The OSPF Opaque LSA Option" ::= { ospfGeneralGroup 16 } ospfReferenceBandwidth OBJECT-TYPE SYNTAX Unsigned32 UNITS "kilobits per second" MAX-ACCESS read-write STATUS current DESCRIPTION "Reference bandwidth in kilobits/second for Galecki, et al. Standards Track [Page 17] RFC 4750 OSPFv2 MIB December 2006 calculating default interface metrics. The default value is 100,000 KBPS (100 MBPS). This object is persistent and when written the entity SHOULD save the change to non-volatile storage." ::= { ospfGeneralGroup 17 } ospfRestartSupport OBJECT-TYPE SYNTAX INTEGER { none (1), plannedOnly (2), plannedAndUnplanned (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The router's support for OSPF graceful restart. Options include: no restart support, only planned restarts, or both planned and unplanned restarts. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." ::= { ospfGeneralGroup 18 } ospfRestartInterval OBJECT-TYPE SYNTAX Integer32 (1..1800) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Configured OSPF graceful restart timeout interval. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." ::= { ospfGeneralGroup 19 } ospfRestartStrictLsaChecking OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if strict LSA checking is enabled for graceful restart. This object is persistent and when written the entity SHOULD save the change to non-volatile Galecki, et al. Standards Track [Page 18] RFC 4750 OSPFv2 MIB December 2006 storage." ::= { ospfGeneralGroup 20 } ospfRestartStatus OBJECT-TYPE SYNTAX INTEGER { notRestarting (1), plannedRestart (2), unplannedRestart (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current status of OSPF graceful restart." ::= { ospfGeneralGroup 21 } ospfRestartAge OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in current OSPF graceful restart interval." ::= { ospfGeneralGroup 22 } ospfRestartExitReason OBJECT-TYPE SYNTAX INTEGER { none (1), -- none attempted inProgress (2), -- restart in -- progress completed (3), -- successfully -- completed timedOut (4), -- timed out topologyChanged (5) -- aborted due to -- topology change. } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the outcome of the last attempt at a graceful restart. If the value is 'none', no restart has yet been attempted. If the value is 'inProgress', a restart attempt is currently underway." ::= { ospfGeneralGroup 23 } ospfAsLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Galecki, et al. Standards Track [Page 19] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The number of AS-scope link state advertisements in the AS-scope link state database." ::= { ospfGeneralGroup 24 } ospfAsLsaCksumSum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit unsigned sum of the LS checksums of the AS link state advertisements contained in the AS-scope link state database. This sum can be used to determine if there has been a change in a router's AS-scope link state database, and to compare the AS-scope link state database of two routers." ::= { ospfGeneralGroup 25 } ospfStubRouterSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The router's support for stub router functionality." REFERENCE "OSPF Stub Router Advertisement" ::= { ospfGeneralGroup 26 } ospfStubRouterAdvertisement OBJECT-TYPE SYNTAX INTEGER { doNotAdvertise (1), advertise(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the advertisement of stub router LSAs by the router. The value doNotAdvertise will result in the advertisement of a standard router LSA and is the default value. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." ::= { ospfGeneralGroup 27 } ospfDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp Galecki, et al. Standards Track [Page 20] RFC 4750 OSPFv2 MIB December 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one of this MIB's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { ospfGeneralGroup 28 } -- OSPF Area Table -- The OSPF Area Table contains information -- regarding the various areas. ospfAreaTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfAreaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the configured parameters and cumulative statistics of the router's attached areas. The interfaces and virtual links are configured as part of these areas. Area 0.0.0.0, by definition, is the backbone area." REFERENCE "OSPF Version 2, Section 6 The Area Data Structure" ::= { ospf 2 } ospfAreaEntry OBJECT-TYPE SYNTAX OspfAreaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the configured parameters and cumulative statistics of one of the router's attached areas. The interfaces and virtual links are configured as part of these areas. Area 0.0.0.0, by definition, is the backbone area. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." INDEX { ospfAreaId } ::= { ospfAreaTable 1 } Galecki, et al. Standards Track [Page 21] RFC 4750 OSPFv2 MIB December 2006 OspfAreaEntry ::= SEQUENCE { ospfAreaId AreaID, ospfAuthType OspfAuthenticationType, ospfImportAsExtern INTEGER, ospfSpfRuns Counter32, ospfAreaBdrRtrCount Gauge32, ospfAsBdrRtrCount Gauge32, ospfAreaLsaCount Gauge32, ospfAreaLsaCksumSum Integer32, ospfAreaSummary INTEGER, ospfAreaStatus RowStatus, ospfAreaNssaTranslatorRole INTEGER, ospfAreaNssaTranslatorState INTEGER, ospfAreaNssaTranslatorStabilityInterval PositiveInteger, ospfAreaNssaTranslatorEvents Counter32 } ospfAreaId OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-only -- read-only since originally -- an SMIv1 index STATUS current DESCRIPTION "A 32-bit integer uniquely identifying an area. Area ID 0.0.0.0 is used for the OSPF backbone." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfAreaEntry 1 } ospfAuthType OBJECT-TYPE SYNTAX OspfAuthenticationType MAX-ACCESS read-create STATUS obsolete Galecki, et al. Standards Track [Page 22] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The authentication type specified for an area." REFERENCE "OSPF Version 2, Appendix D Authentication" DEFVAL { none } -- no authentication, by default ::= { ospfAreaEntry 2 } ospfImportAsExtern OBJECT-TYPE SYNTAX INTEGER { importExternal (1), importNoExternal (2), importNssa (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates if an area is a stub area, NSSA, or standard area. Type-5 AS-external LSAs and type-11 Opaque LSAs are not imported into stub areas or NSSAs. NSSAs import AS-external data as type-7 LSAs" REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" DEFVAL { importExternal } ::= { ospfAreaEntry 3 } ospfSpfRuns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the intra-area route table has been calculated using this area's link state database. This is typically done using Dijkstra's algorithm. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfAreaEntry 4 } ospfAreaBdrRtrCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Area Border Routers reachable within this area. This is initially zero and is calculated in each Shortest Path First (SPF) pass." Galecki, et al. Standards Track [Page 23] RFC 4750 OSPFv2 MIB December 2006 ::= { ospfAreaEntry 5 } ospfAsBdrRtrCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Autonomous System Border Routers reachable within this area. This is initially zero and is calculated in each SPF pass." ::= { ospfAreaEntry 6 } ospfAreaLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of link state advertisements in this area's link state database, excluding AS-external LSAs." ::= { ospfAreaEntry 7 } ospfAreaLsaCksumSum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit sum of the link state advertisements' LS checksums contained in this area's link state database. This sum excludes external (LS type-5) link state advertisements. The sum can be used to determine if there has been a change in a router's link state database, and to compare the link state database of two routers. The value should be treated as unsigned when comparing two sums of checksums." DEFVAL { 0 } ::= { ospfAreaEntry 8 } ospfAreaSummary OBJECT-TYPE SYNTAX INTEGER { noAreaSummary (1), sendAreaSummary (2) } MAX-ACCESS read-create STATUS current DESCRIPTION Galecki, et al. Standards Track [Page 24] RFC 4750 OSPFv2 MIB December 2006 "The variable ospfAreaSummary controls the import of summary LSAs into stub and NSSA areas. It has no effect on other areas. If it is noAreaSummary, the router will not originate summary LSAs into the stub or NSSA area. It will rely entirely on its default route. If it is sendAreaSummary, the router will both summarize and propagate summary LSAs." DEFVAL { noAreaSummary } ::= { ospfAreaEntry 9 } ospfAreaStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfAreaEntry 10 } ospfAreaNssaTranslatorRole OBJECT-TYPE SYNTAX INTEGER { always (1), candidate (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates an NSSA border router's ability to perform NSSA translation of type-7 LSAs into type-5 LSAs." DEFVAL { candidate } ::= { ospfAreaEntry 11 } ospfAreaNssaTranslatorState OBJECT-TYPE SYNTAX INTEGER { enabled (1), elected (2), disabled (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates if and how an NSSA border router is performing NSSA translation of type-7 LSAs into type-5 Galecki, et al. Standards Track [Page 25] RFC 4750 OSPFv2 MIB December 2006 LSAs. When this object is set to enabled, the NSSA Border router's OspfAreaNssaExtTranslatorRole has been set to always. When this object is set to elected, a candidate NSSA Border router is Translating type-7 LSAs into type-5. When this object is set to disabled, a candidate NSSA border router is NOT translating type-7 LSAs into type-5." ::= { ospfAreaEntry 12 } ospfAreaNssaTranslatorStabilityInterval OBJECT-TYPE SYNTAX PositiveInteger UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds after an elected translator determines its services are no longer required, that it should continue to perform its translation duties." DEFVAL { 40 } ::= { ospfAreaEntry 13 } ospfAreaNssaTranslatorEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of translator state changes that have occurred since the last boot-up. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfAreaEntry 14 } -- OSPF Area Default Metric Table ospfStubAreaTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfStubAreaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of metrics that will be advertised by a default Area Border Router into a stub area." REFERENCE "OSPF Version 2, Appendix C.2, Area Parameters" ::= { ospf 3 } ospfStubAreaEntry OBJECT-TYPE SYNTAX OspfStubAreaEntry Galecki, et al. Standards Track [Page 26] RFC 4750 OSPFv2 MIB December 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The metric for a given Type of Service that will be advertised by a default Area Border Router into a stub area. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Appendix C.2, Area Parameters" INDEX { ospfStubAreaId, ospfStubTOS } ::= { ospfStubAreaTable 1 } OspfStubAreaEntry ::= SEQUENCE { ospfStubAreaId AreaID, ospfStubTOS TOSType, ospfStubMetric BigMetric, ospfStubStatus RowStatus, ospfStubMetricType INTEGER } ospfStubAreaId OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The 32-bit identifier for the stub area. On creation, this can be derived from the instance." ::= { ospfStubAreaEntry 1 } ospfStubTOS OBJECT-TYPE SYNTAX TOSType MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The Type of Service associated with the metric. On creation, this can be derived from Galecki, et al. Standards Track [Page 27] RFC 4750 OSPFv2 MIB December 2006 the instance." ::= { ospfStubAreaEntry 2 } ospfStubMetric OBJECT-TYPE SYNTAX BigMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric value applied at the indicated Type of Service. By default, this equals the least metric at the Type of Service among the interfaces to other areas." ::= { ospfStubAreaEntry 3 } ospfStubStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfStubAreaEntry 4 } ospfStubMetricType OBJECT-TYPE SYNTAX INTEGER { ospfMetric (1), -- OSPF Metric comparableCost (2), -- external type 1 nonComparable (3) -- external type 2 } MAX-ACCESS read-create STATUS current DESCRIPTION "This variable displays the type of metric advertised as a default route." DEFVAL { ospfMetric } ::= { ospfStubAreaEntry 5 } -- OSPF Link State Database ospfLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfLsdbEntry MAX-ACCESS not-accessible STATUS current Galecki, et al. Standards Track [Page 28] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The OSPF Process's link state database (LSDB). The LSDB contains the link state advertisements from throughout the areas that the device is attached to." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements" ::= { ospf 4 } ospfLsdbEntry OBJECT-TYPE SYNTAX OspfLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single link state advertisement." INDEX { ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId } ::= { ospfLsdbTable 1 } OspfLsdbEntry ::= SEQUENCE { ospfLsdbAreaId AreaID, ospfLsdbType INTEGER, ospfLsdbLsid IpAddress, ospfLsdbRouterId RouterID, ospfLsdbSequence Integer32, ospfLsdbAge Integer32, ospfLsdbChecksum Integer32, ospfLsdbAdvertisement OCTET STRING } ospfLsdbAreaId OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The 32-bit identifier of the area from which the LSA was received." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" Galecki, et al. Standards Track [Page 29] RFC 4750 OSPFv2 MIB December 2006 ::= { ospfLsdbEntry 1 } ospfLsdbType OBJECT-TYPE SYNTAX INTEGER { routerLink (1), networkLink (2), summaryLink (3), asSummaryLink (4), asExternalLink (5), -- but see ospfAsLsdbTable multicastLink (6), nssaExternalLink (7), areaOpaqueLink (10) } MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format. Note: External link state advertisements are permitted for backward compatibility, but should be displayed in the ospfAsLsdbTable rather than here." REFERENCE "OSPF Version 2, Appendix A.4.1 The Link State Advertisement header" ::= { ospfLsdbEntry 2 } ospfLsdbLsid OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The Link State ID is an LS Type Specific field containing either a Router ID or an IP address; it identifies the piece of the routing domain that is being described by the advertisement." REFERENCE "OSPF Version 2, Section 12.1.4 Link State ID" ::= { ospfLsdbEntry 3 } ospfLsdbRouterId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current Galecki, et al. Standards Track [Page 30] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1 Global parameters" ::= { ospfLsdbEntry 4 } ospfLsdbSequence OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It starts with the value '80000001'h, or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. Thus, a typical sequence number will be very negative. It is used to detect old and duplicate Link State Advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6 LS sequence number" ::= { ospfLsdbEntry 5 } ospfLsdbAge OBJECT-TYPE SYNTAX Integer32 -- Should be 0..MaxAge, except when -- doNotAge bit is set UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the age of the link state advertisement in seconds." REFERENCE "OSPF Version 2, Section 12.1.1 LS age" ::= { ospfLsdbEntry 6 } ospfLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless Galecki, et al. Standards Track [Page 31] RFC 4750 OSPFv2 MIB December 2006 datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7 LS checksum" ::= { ospfLsdbEntry 7 } ospfLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header. Note that for variable length LSAs, SNMP agents may not be able to return the largest string size." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements" ::= { ospfLsdbEntry 8 } -- Address Range Table ospfAreaRangeTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfAreaRangeEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "The Address Range Table acts as an adjunct to the Area Table. It describes those Address Range Summaries that are configured to be propagated from an Area to reduce the amount of information about it that is known beyond its borders. It contains a set of IP address ranges specified by an IP address/IP network mask pair. For example, class B address range of X.X.X.X with a network mask of 255.255.0.0 includes all IP addresses from X.X.0.0 to X.X.255.255. Note that this table is obsoleted and is replaced by the Area Aggregate Table." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospf 5 } ospfAreaRangeEntry OBJECT-TYPE SYNTAX OspfAreaRangeEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION Galecki, et al. Standards Track [Page 32] RFC 4750 OSPFv2 MIB December 2006 "A single area address range. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" INDEX { ospfAreaRangeAreaId, ospfAreaRangeNet } ::= { ospfAreaRangeTable 1 } OspfAreaRangeEntry ::= SEQUENCE { ospfAreaRangeAreaId AreaID, ospfAreaRangeNet IpAddress, ospfAreaRangeMask IpAddress, ospfAreaRangeStatus RowStatus, ospfAreaRangeEffect INTEGER } ospfAreaRangeAreaId OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS obsolete DESCRIPTION "The area that the address range is to be found within." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfAreaRangeEntry 1 } ospfAreaRangeNet OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS obsolete DESCRIPTION "The IP address of the net or subnet indicated by the range." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfAreaRangeEntry 2 } Galecki, et al. Standards Track [Page 33] RFC 4750 OSPFv2 MIB December 2006 ospfAreaRangeMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS obsolete DESCRIPTION "The subnet mask that pertains to the net or subnet." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfAreaRangeEntry 3 } ospfAreaRangeStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS obsolete DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfAreaRangeEntry 4 } ospfAreaRangeEffect OBJECT-TYPE SYNTAX INTEGER { advertiseMatching (1), doNotAdvertiseMatching (2) } MAX-ACCESS read-create STATUS obsolete DESCRIPTION "Subnets subsumed by ranges either trigger the advertisement of the indicated summary (advertiseMatching) or result in the subnet's not being advertised at all outside the area." DEFVAL { advertiseMatching } ::= { ospfAreaRangeEntry 5 } -- OSPF Host Table ospfHostTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Host/Metric Table indicates what hosts are directly Galecki, et al. Standards Track [Page 34] RFC 4750 OSPFv2 MIB December 2006 attached to the router, what metrics and types of service should be advertised for them, and what areas they are found within." REFERENCE "OSPF Version 2, Appendix C.7 Host route parameters" ::= { ospf 6 } ospfHostEntry OBJECT-TYPE SYNTAX OspfHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A metric to be advertised, for a given type of service, when a given host is reachable. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." INDEX { ospfHostIpAddress, ospfHostTOS } ::= { ospfHostTable 1 } OspfHostEntry ::= SEQUENCE { ospfHostIpAddress IpAddress, ospfHostTOS TOSType, ospfHostMetric Metric, ospfHostStatus RowStatus, ospfHostAreaID AreaID, ospfHostCfgAreaID AreaID } ospfHostIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The IP address of the host." REFERENCE "OSPF Version 2, Appendix C.7 Host route parameters" ::= { ospfHostEntry 1 } Galecki, et al. Standards Track [Page 35] RFC 4750 OSPFv2 MIB December 2006 ospfHostTOS OBJECT-TYPE SYNTAX TOSType MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The Type of Service of the route being configured." REFERENCE "OSPF Version 2, Appendix C.7 Host route parameters" ::= { ospfHostEntry 2 } ospfHostMetric OBJECT-TYPE SYNTAX Metric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric to be advertised." REFERENCE "OSPF Version 2, Appendix C.7 Host route parameters" ::= { ospfHostEntry 3 } ospfHostStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfHostEntry 4 } ospfHostAreaID OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The OSPF area to which the host belongs. Deprecated by ospfHostCfgAreaID." REFERENCE "OSPF Version 2, Appendix C.7 Host parameters" ::= { ospfHostEntry 5 } ospfHostCfgAreaID OBJECT-TYPE SYNTAX AreaID Galecki, et al. Standards Track [Page 36] RFC 4750 OSPFv2 MIB December 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "To configure the OSPF area to which the host belongs." REFERENCE "OSPF Version 2, Appendix C.7 Host parameters" ::= { ospfHostEntry 6 } -- OSPF Interface Table ospfIfTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPF Interface Table describes the interfaces from the viewpoint of OSPF. It augments the ipAddrTable with OSPF specific information." REFERENCE "OSPF Version 2, Appendix C.3 Router interface parameters" ::= { ospf 7 } ospfIfEntry OBJECT-TYPE SYNTAX OspfIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPF interface entry describes one interface from the viewpoint of OSPF. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." INDEX { ospfIfIpAddress, ospfAddressLessIf } ::= { ospfIfTable 1 } OspfIfEntry ::= SEQUENCE { ospfIfIpAddress IpAddress, ospfAddressLessIf InterfaceIndexOrZero, ospfIfAreaId AreaID, ospfIfType INTEGER, ospfIfAdminStat Galecki, et al. Standards Track [Page 37] RFC 4750 OSPFv2 MIB December 2006 Status, ospfIfRtrPriority DesignatedRouterPriority, ospfIfTransitDelay UpToMaxAge, ospfIfRetransInterval UpToMaxAge, ospfIfHelloInterval HelloRange, ospfIfRtrDeadInterval PositiveInteger, ospfIfPollInterval PositiveInteger, ospfIfState INTEGER, ospfIfDesignatedRouter IpAddress, ospfIfBackupDesignatedRouter IpAddress, ospfIfEvents Counter32, ospfIfAuthKey OCTET STRING, ospfIfStatus RowStatus, ospfIfMulticastForwarding INTEGER, ospfIfDemand TruthValue, ospfIfAuthType OspfAuthenticationType, ospfIfLsaCount Gauge32, ospfIfLsaCksumSum Unsigned32, ospfIfDesignatedRouterId RouterID, ospfIfBackupDesignatedRouterId RouterID } ospfIfIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The IP address of this OSPF interface." Galecki, et al. Standards Track [Page 38] RFC 4750 OSPFv2 MIB December 2006 ::= { ospfIfEntry 1 } ospfAddressLessIf OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "For the purpose of easing the instancing of addressed and addressless interfaces; this variable takes the value 0 on interfaces with IP addresses and the corresponding value of ifIndex for interfaces having no IP address." ::= { ospfIfEntry 2 } ospfIfAreaId OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-create STATUS current DESCRIPTION "A 32-bit integer uniquely identifying the area to which the interface connects. Area ID 0.0.0.0 is used for the OSPF backbone." DEFVAL { '00000000'H } -- 0.0.0.0 ::= { ospfIfEntry 3 } ospfIfType OBJECT-TYPE SYNTAX INTEGER { broadcast (1), nbma (2), pointToPoint (3), pointToMultipoint (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The OSPF interface type. By way of a default, this field may be intuited from the corresponding value of ifType. Broadcast LANs, such as Ethernet and IEEE 802.5, take the value 'broadcast', X.25 and similar technologies take the value 'nbma', and links that are definitively point to point take the value 'pointToPoint'." ::= { ospfIfEntry 4 } ospfIfAdminStat OBJECT-TYPE SYNTAX Status Galecki, et al. Standards Track [Page 39] RFC 4750 OSPFv2 MIB December 2006 MAX-ACCESS read-create STATUS current DESCRIPTION "The OSPF interface's administrative status. The value formed on the interface, and the interface will be advertised as an internal route to some area. The value 'disabled' denotes that the interface is external to OSPF." DEFVAL { enabled } ::= { ospfIfEntry 5 } ospfIfRtrPriority OBJECT-TYPE SYNTAX DesignatedRouterPriority MAX-ACCESS read-create STATUS current DESCRIPTION "The priority of this interface. Used in multi-access networks, this field is used in the designated router election algorithm. The value 0 signifies that the router is not eligible to become the designated router on this particular network. In the event of a tie in this value, routers will use their Router ID as a tie breaker." DEFVAL { 1 } ::= { ospfIfEntry 6 } ospfIfTransitDelay OBJECT-TYPE SYNTAX UpToMaxAge UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The estimated number of seconds it takes to transmit a link state update packet over this interface. Note that the minimal value SHOULD be 1 second." DEFVAL { 1 } ::= { ospfIfEntry 7 } ospfIfRetransInterval OBJECT-TYPE SYNTAX UpToMaxAge UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between link state advertisement retransmissions, for adjacencies belonging to this interface. This value is also used when retransmitting Galecki, et al. Standards Track [Page 40] RFC 4750 OSPFv2 MIB December 2006 database description and Link State request packets. Note that minimal value SHOULD be 1 second." DEFVAL { 5 } ::= { ospfIfEntry 8 } ospfIfHelloInterval OBJECT-TYPE SYNTAX HelloRange UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The length of time, in seconds, between the Hello packets that the router sends on the interface. This value must be the same for all routers attached to a common network." DEFVAL { 10 } ::= { ospfIfEntry 9 } ospfIfRtrDeadInterval OBJECT-TYPE SYNTAX PositiveInteger UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that a router's Hello packets have not been seen before its neighbors declare the router down. This should be some multiple of the Hello interval. This value must be the same for all routers attached to a common network." DEFVAL { 40 } ::= { ospfIfEntry 10 } ospfIfPollInterval OBJECT-TYPE SYNTAX PositiveInteger UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The larger time interval, in seconds, between the Hello packets sent to an inactive non-broadcast multi-access neighbor." DEFVAL { 120 } ::= { ospfIfEntry 11 } ospfIfState OBJECT-TYPE SYNTAX INTEGER { down (1), loopback (2), waiting (3), Galecki, et al. Standards Track [Page 41] RFC 4750 OSPFv2 MIB December 2006 pointToPoint (4), designatedRouter (5), backupDesignatedRouter (6), otherDesignatedRouter (7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The OSPF Interface State." DEFVAL { down } ::= { ospfIfEntry 12 } ospfIfDesignatedRouter OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the designated router." DEFVAL { '00000000'H } -- 0.0.0.0 ::= { ospfIfEntry 13 } ospfIfBackupDesignatedRouter OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the backup designated router." DEFVAL { '00000000'H } -- 0.0.0.0 ::= { ospfIfEntry 14 } ospfIfEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this OSPF interface has changed its state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfIfEntry 15 } ospfIfAuthKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-create STATUS current Galecki, et al. Standards Track [Page 42] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The cleartext password used as an OSPF authentication key when simplePassword security is enabled. This object does not access any OSPF cryptogaphic (e.g., MD5) authentication key under any circumstance. If the key length is shorter than 8 octets, the agent will left adjust and zero fill to 8 octets. Unauthenticated interfaces need no authentication key, and simple password authentication cannot use a key of more than 8 octets. Note that the use of simplePassword authentication is NOT recommended when there is concern regarding attack upon the OSPF system. SimplePassword authentication is only sufficient to protect against accidental misconfigurations because it re-uses cleartext passwords [RFC1704]. When read, ospfIfAuthKey always returns an octet string of length zero." REFERENCE "OSPF Version 2, Section 9 The Interface Data Structure" DEFVAL { '0000000000000000'H } -- 0.0.0.0.0.0.0.0 ::= { ospfIfEntry 16 } ospfIfStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfIfEntry 17 } ospfIfMulticastForwarding OBJECT-TYPE SYNTAX INTEGER { blocked (1), -- no multicast forwarding multicast (2), -- using multicast address unicast (3) -- to each OSPF neighbor Galecki, et al. Standards Track [Page 43] RFC 4750 OSPFv2 MIB December 2006 } MAX-ACCESS read-create STATUS current DESCRIPTION "The way multicasts should be forwarded on this interface: not forwarded, forwarded as data link multicasts, or forwarded as data link unicasts. Data link multicasting is not meaningful on point-to-point and NBMA interfaces, and setting ospfMulticastForwarding to 0 effectively disables all multicast forwarding." DEFVAL { blocked } ::= { ospfIfEntry 18 } ospfIfDemand OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether Demand OSPF procedures (hello suppression to FULL neighbors and setting the DoNotAge flag on propagated LSAs) should be performed on this interface." DEFVAL { false } ::= { ospfIfEntry 19 } ospfIfAuthType OBJECT-TYPE SYNTAX OspfAuthenticationType MAX-ACCESS read-create STATUS current DESCRIPTION "The authentication type specified for an interface. Note that this object can be used to engage in significant attacks against an OSPF router." REFERENCE "OSPF Version 2, Appendix D Authentication" DEFVAL { none } -- no authentication, by default ::= { ospfIfEntry 20 } ospfIfLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of link-local link state advertisements in this interface's link-local link state database." ::= { ospfIfEntry 21 } Galecki, et al. Standards Track [Page 44] RFC 4750 OSPFv2 MIB December 2006 ospfIfLsaCksumSum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit unsigned sum of the Link State Advertisements' LS checksums contained in this interface's link-local link state database. The sum can be used to determine if there has been a change in the interface's link state database and to compare the interface link state database of routers attached to the same subnet." ::= { ospfIfEntry 22 } ospfIfDesignatedRouterId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID of the designated router." ::= { ospfIfEntry 23 } ospfIfBackupDesignatedRouterId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID of the backup designated router." ::= { ospfIfEntry 24 } -- OSPF Interface Metric Table ospfIfMetricTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfIfMetricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Metric Table describes the metrics to be advertised for a specified interface at the various types of service. As such, this table is an adjunct of the OSPF Interface Table. Types of service, as defined by RFC 791, have the ability to request low delay, high bandwidth, or reliable linkage. For the purposes of this specification, the measure of bandwidth: Galecki, et al. Standards Track [Page 45] RFC 4750 OSPFv2 MIB December 2006 Metric = referenceBandwidth / ifSpeed is the default value. The default reference bandwidth is 10^8. For multiple link interfaces, note that ifSpeed is the sum of the individual link speeds. This yields a number having the following typical values: Network Type/bit rate Metric >= 100 MBPS 1 Ethernet/802.3 10 E1 48 T1 (ESF) 65 64 KBPS 1562 56 KBPS 1785 19.2 KBPS 5208 9.6 KBPS 10416 Routes that are not specified use the default (TOS 0) metric. Note that the default reference bandwidth can be configured using the general group object ospfReferenceBandwidth." REFERENCE "OSPF Version 2, Appendix C.3 Router interface parameters" ::= { ospf 8 } ospfIfMetricEntry OBJECT-TYPE SYNTAX OspfIfMetricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular TOS metric for a non-virtual interface identified by the interface index. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Appendix C.3 Router interface parameters" INDEX { ospfIfMetricIpAddress, ospfIfMetricAddressLessIf, ospfIfMetricTOS } ::= { ospfIfMetricTable 1 } Galecki, et al. Standards Track [Page 46] RFC 4750 OSPFv2 MIB December 2006 OspfIfMetricEntry ::= SEQUENCE { ospfIfMetricIpAddress IpAddress, ospfIfMetricAddressLessIf InterfaceIndexOrZero, ospfIfMetricTOS TOSType, ospfIfMetricValue Metric, ospfIfMetricStatus RowStatus } ospfIfMetricIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The IP address of this OSPF interface. On row creation, this can be derived from the instance." ::= { ospfIfMetricEntry 1 } ospfIfMetricAddressLessIf OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "For the purpose of easing the instancing of addressed and addressless interfaces; this variable takes the value 0 on interfaces with IP addresses and the value of ifIndex for interfaces having no IP address. On row creation, this can be derived from the instance." ::= { ospfIfMetricEntry 2 } ospfIfMetricTOS OBJECT-TYPE SYNTAX TOSType MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The Type of Service metric being referenced. On row creation, this can be derived from the instance." ::= { ospfIfMetricEntry 3 } Galecki, et al. Standards Track [Page 47] RFC 4750 OSPFv2 MIB December 2006 ospfIfMetricValue OBJECT-TYPE SYNTAX Metric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric of using this Type of Service on this interface. The default value of the TOS 0 metric is 10^8 / ifSpeed." ::= { ospfIfMetricEntry 4 } ospfIfMetricStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfIfMetricEntry 5 } -- OSPF Virtual Interface Table ospfVirtIfTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfVirtIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about this router's virtual interfaces that the OSPF Process is configured to carry on." REFERENCE "OSPF Version 2, Appendix C.4 Virtual link parameters" ::= { ospf 9 } ospfVirtIfEntry OBJECT-TYPE SYNTAX OspfVirtIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single virtual interface. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." Galecki, et al. Standards Track [Page 48] RFC 4750 OSPFv2 MIB December 2006 INDEX { ospfVirtIfAreaId, ospfVirtIfNeighbor } ::= { ospfVirtIfTable 1 } OspfVirtIfEntry ::= SEQUENCE { ospfVirtIfAreaId AreaID, ospfVirtIfNeighbor RouterID, ospfVirtIfTransitDelay UpToMaxAge, ospfVirtIfRetransInterval UpToMaxAge, ospfVirtIfHelloInterval HelloRange, ospfVirtIfRtrDeadInterval PositiveInteger, ospfVirtIfState INTEGER, ospfVirtIfEvents Counter32, ospfVirtIfAuthKey OCTET STRING, ospfVirtIfStatus RowStatus, ospfVirtIfAuthType OspfAuthenticationType, ospfVirtIfLsaCount Gauge32, ospfVirtIfLsaCksumSum Unsigned32 } ospfVirtIfAreaId OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The transit area that the virtual link traverses. By definition, this is not 0.0.0.0." ::= { ospfVirtIfEntry 1 } ospfVirtIfNeighbor OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current Galecki, et al. Standards Track [Page 49] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The Router ID of the virtual neighbor." ::= { ospfVirtIfEntry 2 } ospfVirtIfTransitDelay OBJECT-TYPE SYNTAX UpToMaxAge UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The estimated number of seconds it takes to transmit a Link State update packet over this interface. Note that the minimal value SHOULD be 1 second." DEFVAL { 1 } ::= { ospfVirtIfEntry 3 } ospfVirtIfRetransInterval OBJECT-TYPE SYNTAX UpToMaxAge UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between link state avertisement retransmissions, for adjacencies belonging to this interface. This value is also used when retransmitting database description and Link State request packets. This value should be well over the expected round-trip time. Note that the minimal value SHOULD be 1 second." DEFVAL { 5 } ::= { ospfVirtIfEntry 4 } ospfVirtIfHelloInterval OBJECT-TYPE SYNTAX HelloRange UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The length of time, in seconds, between the Hello packets that the router sends on the interface. This value must be the same for the virtual neighbor." DEFVAL { 10 } ::= { ospfVirtIfEntry 5 } ospfVirtIfRtrDeadInterval OBJECT-TYPE Galecki, et al. Standards Track [Page 50] RFC 4750 OSPFv2 MIB December 2006 SYNTAX PositiveInteger UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that a router's Hello packets have not been seen before its neighbors declare the router down. This should be some multiple of the Hello interval. This value must be the same for the virtual neighbor." DEFVAL { 60 } ::= { ospfVirtIfEntry 6 } ospfVirtIfState OBJECT-TYPE SYNTAX INTEGER { down (1), -- these use the same encoding pointToPoint (4) -- as the ospfIfTable } MAX-ACCESS read-only STATUS current DESCRIPTION "OSPF virtual interface states." DEFVAL { down } ::= { ospfVirtIfEntry 7 } ospfVirtIfEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of state changes or error events on this virtual link. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfVirtIfEntry 8 } ospfVirtIfAuthKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..256)) MAX-ACCESS read-create STATUS current DESCRIPTION "The cleartext password used as an OSPF authentication key when simplePassword security is enabled. This object does not access any OSPF cryptogaphic (e.g., MD5) authentication key under any circumstance. Galecki, et al. Standards Track [Page 51] RFC 4750 OSPFv2 MIB December 2006 If the key length is shorter than 8 octets, the agent will left adjust and zero fill to 8 octets. Unauthenticated interfaces need no authentication key, and simple password authentication cannot use a key of more than 8 octets. Note that the use of simplePassword authentication is NOT recommended when there is concern regarding attack upon the OSPF system. SimplePassword authentication is only sufficient to protect against accidental misconfigurations because it re-uses cleartext passwords. [RFC1704] When read, ospfIfAuthKey always returns an octet string of length zero." REFERENCE "OSPF Version 2, Section 9 The Interface Data Structure" DEFVAL { '0000000000000000'H } -- 0.0.0.0.0.0.0.0 ::= { ospfVirtIfEntry 9 } ospfVirtIfStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfVirtIfEntry 10 } ospfVirtIfAuthType OBJECT-TYPE SYNTAX OspfAuthenticationType MAX-ACCESS read-create STATUS current DESCRIPTION "The authentication type specified for a virtual interface. Note that this object can be used to engage in significant attacks against an OSPF router." REFERENCE "OSPF Version 2, Appendix E Authentication" DEFVAL { none } -- no authentication, by default Galecki, et al. Standards Track [Page 52] RFC 4750 OSPFv2 MIB December 2006 ::= { ospfVirtIfEntry 11 } ospfVirtIfLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of link-local link state advertisements in this virtual interface's link-local link state database." ::= { ospfVirtIfEntry 12 } ospfVirtIfLsaCksumSum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit unsigned sum of the link state advertisements' LS checksums contained in this virtual interface's link-local link state database. The sum can be used to determine if there has been a change in the virtual interface's link state database, and to compare the virtual interface link state database of the virtual neighbors." ::= { ospfVirtIfEntry 13 } -- OSPF Neighbor Table ospfNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table describing all non-virtual neighbors in the locality of the OSPF router." REFERENCE "OSPF Version 2, Section 10 The Neighbor Data Structure" ::= { ospf 10 } ospfNbrEntry OBJECT-TYPE SYNTAX OspfNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The information regarding a single neighbor. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile Galecki, et al. Standards Track [Page 53] RFC 4750 OSPFv2 MIB December 2006 storage." REFERENCE "OSPF Version 2, Section 10 The Neighbor Data Structure" INDEX { ospfNbrIpAddr, ospfNbrAddressLessIndex } ::= { ospfNbrTable 1 } OspfNbrEntry ::= SEQUENCE { ospfNbrIpAddr IpAddress, ospfNbrAddressLessIndex InterfaceIndexOrZero, ospfNbrRtrId RouterID, ospfNbrOptions Integer32, ospfNbrPriority DesignatedRouterPriority, ospfNbrState INTEGER, ospfNbrEvents Counter32, ospfNbrLsRetransQLen Gauge32, ospfNbmaNbrStatus RowStatus, ospfNbmaNbrPermanence INTEGER, ospfNbrHelloSuppressed TruthValue, ospfNbrRestartHelperStatus INTEGER, ospfNbrRestartHelperAge Unsigned32, ospfNbrRestartHelperExitReason INTEGER } ospfNbrIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The IP address this neighbor is using in its IP source address. Note that, on addressless links, this will not be 0.0.0.0 but the Galecki, et al. Standards Track [Page 54] RFC 4750 OSPFv2 MIB December 2006 address of another of the neighbor's interfaces." ::= { ospfNbrEntry 1 } ospfNbrAddressLessIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "On an interface having an IP address, zero. On addressless interfaces, the corresponding value of ifIndex in the Internet Standard MIB. On row creation, this can be derived from the instance." ::= { ospfNbrEntry 2 } ospfNbrRtrId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-only STATUS current DESCRIPTION "A 32-bit integer (represented as a type IpAddress) uniquely identifying the neighboring router in the Autonomous System." DEFVAL { '00000000'H } -- 0.0.0.0 ::= { ospfNbrEntry 3 } ospfNbrOptions OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A bit mask corresponding to the neighbor's options field. Bit 0, if set, indicates that the system will operate on Type of Service metrics other than TOS 0. If zero, the neighbor will ignore all metrics except the TOS 0 metric. Bit 1, if set, indicates that the associated area accepts and operates on external information; if zero, it is a stub area. Bit 2, if set, indicates that the system is capable of routing IP multicast datagrams, that is that it implements the multicast extensions to OSPF. Galecki, et al. Standards Track [Page 55] RFC 4750 OSPFv2 MIB December 2006 Bit 3, if set, indicates that the associated area is an NSSA. These areas are capable of carrying type-7 external advertisements, which are translated into type-5 external advertisements at NSSA borders." REFERENCE "OSPF Version 2, Section 12.1.2 Options" DEFVAL { 0 } ::= { ospfNbrEntry 4 } ospfNbrPriority OBJECT-TYPE SYNTAX DesignatedRouterPriority MAX-ACCESS read-create STATUS current DESCRIPTION "The priority of this neighbor in the designated router election algorithm. The value 0 signifies that the neighbor is not eligible to become the designated router on this particular network." DEFVAL { 1 } ::= { ospfNbrEntry 5 } ospfNbrState OBJECT-TYPE SYNTAX INTEGER { down (1), attempt (2), init (3), twoWay (4), exchangeStart (5), exchange (6), loading (7), full (8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the relationship with this neighbor." REFERENCE "OSPF Version 2, Section 10.1 Neighbor States" DEFVAL { down } ::= { ospfNbrEntry 6 } ospfNbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Galecki, et al. Standards Track [Page 56] RFC 4750 OSPFv2 MIB December 2006 "The number of times this neighbor relationship has changed state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfNbrEntry 7 } ospfNbrLsRetransQLen OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current length of the retransmission queue." ::= { ospfNbrEntry 8 } ospfNbmaNbrStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfNbrEntry 9 } ospfNbmaNbrPermanence OBJECT-TYPE SYNTAX INTEGER { dynamic (1), -- learned through protocol permanent (2) -- configured address } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable displays the status of the entry; 'dynamic' and 'permanent' refer to how the neighbor became known." DEFVAL { permanent } ::= { ospfNbrEntry 10 } ospfNbrHelloSuppressed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only Galecki, et al. Standards Track [Page 57] RFC 4750 OSPFv2 MIB December 2006 STATUS current DESCRIPTION "Indicates whether Hellos are being suppressed to the neighbor." ::= { ospfNbrEntry 11 } ospfNbrRestartHelperStatus OBJECT-TYPE SYNTAX INTEGER { notHelping (1), helping (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the router is acting as a graceful restart helper for the neighbor." ::= { ospfNbrEntry 12 } ospfNbrRestartHelperAge OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in current OSPF graceful restart interval, if the router is acting as a restart helper for the neighbor." ::= { ospfNbrEntry 13 } ospfNbrRestartHelperExitReason OBJECT-TYPE SYNTAX INTEGER { none (1), -- not attempted inProgress (2), -- restart in -- progress completed (3), -- successfully -- completed timedOut (4), -- timed out topologyChanged (5) -- aborted due to -- topology -- change. } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the outcome of the last attempt at acting as a graceful restart helper for the neighbor." ::= { ospfNbrEntry 14 } -- OSPF Virtual Neighbor Table Galecki, et al. Standards Track [Page 58] RFC 4750 OSPFv2 MIB December 2006 ospfVirtNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfVirtNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes all virtual neighbors. Since virtual links are configured in the Virtual Interface Table, this table is read-only." REFERENCE "OSPF Version 2, Section 15 Virtual Links" ::= { ospf 11 } ospfVirtNbrEntry OBJECT-TYPE SYNTAX OspfVirtNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Virtual neighbor information." INDEX { ospfVirtNbrArea, ospfVirtNbrRtrId } ::= { ospfVirtNbrTable 1 } OspfVirtNbrEntry ::= SEQUENCE { ospfVirtNbrArea AreaID, ospfVirtNbrRtrId RouterID, ospfVirtNbrIpAddr IpAddress, ospfVirtNbrOptions Integer32, ospfVirtNbrState INTEGER, ospfVirtNbrEvents Counter32, ospfVirtNbrLsRetransQLen Gauge32, ospfVirtNbrHelloSuppressed TruthValue, ospfVirtNbrRestartHelperStatus INTEGER, ospfVirtNbrRestartHelperAge Unsigned32, ospfVirtNbrRestartHelperExitReason INTEGER } ospfVirtNbrArea OBJECT-TYPE Galecki, et al. Standards Track [Page 59] RFC 4750 OSPFv2 MIB December 2006 SYNTAX AreaID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The Transit Area Identifier." ::= { ospfVirtNbrEntry 1 } ospfVirtNbrRtrId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "A 32-bit integer uniquely identifying the neighboring router in the Autonomous System." ::= { ospfVirtNbrEntry 2 } ospfVirtNbrIpAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address this virtual neighbor is using." ::= { ospfVirtNbrEntry 3 } ospfVirtNbrOptions OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A bit mask corresponding to the neighbor's options field. Bit 1, if set, indicates that the system will operate on Type of Service metrics other than TOS 0. If zero, the neighbor will ignore all metrics except the TOS 0 metric. Bit 2, if set, indicates that the system is network multicast capable, i.e., that it implements OSPF multicast routing." ::= { ospfVirtNbrEntry 4 } ospfVirtNbrState OBJECT-TYPE SYNTAX INTEGER { down (1), attempt (2), Galecki, et al. Standards Track [Page 60] RFC 4750 OSPFv2 MIB December 2006 init (3), twoWay (4), exchangeStart (5), exchange (6), loading (7), full (8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the virtual neighbor relationship." ::= { ospfVirtNbrEntry 5 } ospfVirtNbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this virtual link has changed its state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ospfDiscontinuityTime." ::= { ospfVirtNbrEntry 6 } ospfVirtNbrLsRetransQLen OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current length of the retransmission queue." ::= { ospfVirtNbrEntry 7 } ospfVirtNbrHelloSuppressed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether Hellos are being suppressed to the neighbor." ::= { ospfVirtNbrEntry 8 } ospfVirtNbrRestartHelperStatus OBJECT-TYPE SYNTAX INTEGER { notHelping (1), helping (2) } Galecki, et al. Standards Track [Page 61] RFC 4750 OSPFv2 MIB December 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the router is acting as a graceful restart helper for the neighbor." ::= { ospfVirtNbrEntry 9 } ospfVirtNbrRestartHelperAge OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in current OSPF graceful restart interval, if the router is acting as a restart helper for the neighbor." ::= { ospfVirtNbrEntry 10 } ospfVirtNbrRestartHelperExitReason OBJECT-TYPE SYNTAX INTEGER { none (1), -- not attempted inProgress (2), -- restart in -- progress completed (3), -- successfully -- completed timedOut (4), -- timed out topologyChanged (5) -- aborted due to -- topology -- change. } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the outcome of the last attempt at acting as a graceful restart helper for the neighbor." ::= { ospfVirtNbrEntry 11 } -- OSPF Link State Database, External ospfExtLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfExtLsdbEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The OSPF Process's external LSA link state database. This table is identical to the OSPF LSDB Table in format, but contains only external link state advertisements. The purpose is to allow external Galecki, et al. Standards Track [Page 62] RFC 4750 OSPFv2 MIB December 2006 LSAs to be displayed once for the router rather than once in each non-stub area. Note that external LSAs are also in the AS-scope link state database." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements" ::= { ospf 12 } ospfExtLsdbEntry OBJECT-TYPE SYNTAX OspfExtLsdbEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "A single link state advertisement." INDEX { ospfExtLsdbType, ospfExtLsdbLsid, ospfExtLsdbRouterId } ::= { ospfExtLsdbTable 1 } OspfExtLsdbEntry ::= SEQUENCE { ospfExtLsdbType INTEGER, ospfExtLsdbLsid IpAddress, ospfExtLsdbRouterId RouterID, ospfExtLsdbSequence Integer32, ospfExtLsdbAge Integer32, ospfExtLsdbChecksum Integer32, ospfExtLsdbAdvertisement OCTET STRING } ospfExtLsdbType OBJECT-TYPE SYNTAX INTEGER { asExternalLink (5) } MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format." REFERENCE Galecki, et al. Standards Track [Page 63] RFC 4750 OSPFv2 MIB December 2006 "OSPF Version 2, Appendix A.4.1 The Link State Advertisement header" ::= { ospfExtLsdbEntry 1 } ospfExtLsdbLsid OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "The Link State ID is an LS Type Specific field containing either a Router ID or an IP address; it identifies the piece of the routing domain that is being described by the advertisement." REFERENCE "OSPF Version 2, Section 12.1.4 Link State ID" ::= { ospfExtLsdbEntry 2 } ospfExtLsdbRouterId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1 Global parameters" ::= { ospfExtLsdbEntry 3 } ospfExtLsdbSequence OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The sequence number field is a signed 32-bit integer. It starts with the value '80000001'h, or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. Thus, a typical sequence number will be very negative. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6 LS sequence number" ::= { ospfExtLsdbEntry 4 } Galecki, et al. Standards Track [Page 64] RFC 4750 OSPFv2 MIB December 2006 ospfExtLsdbAge OBJECT-TYPE SYNTAX Integer32 -- Should be 0..MaxAge, except when -- doNotAge bit is set UNITS "seconds" MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This field is the age of the link state advertisement in seconds." REFERENCE "OSPF Version 2, Section 12.1.1 LS age" ::= { ospfExtLsdbEntry 5 } ospfExtLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7 LS checksum" ::= { ospfExtLsdbEntry 6 } ospfExtLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE(36)) MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The entire link state advertisement, including its header." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements" ::= { ospfExtLsdbEntry 7 } -- OSPF Use of the CIDR Route Table ospfRouteGroup OBJECT IDENTIFIER ::= { ospf 13 } -- The IP Forwarding Table defines a number of objects for use by -- the routing protocol to externalize its information. Most of Galecki, et al. Standards Track [Page 65] RFC 4750 OSPFv2 MIB December 2006 -- the variables (ipForwardDest, ipForwardMask, ipForwardPolicy, -- ipForwardNextHop, ipForwardIfIndex, ipForwardType, -- ipForwardProto, ipForwardAge, and ipForwardNextHopAS) are -- defined there. -- Those that leave some discretion are defined here. -- ipCidrRouteProto is, of course, ospf (13). -- ipCidrRouteAge is the time since the route was first -- calculated, as opposed to the time since the last SPF run. -- ipCidrRouteInfo is an OBJECT IDENTIFIER for use by the routing -- protocol. The following values shall be found there depending -- on the way the route was calculated. ospfIntraArea OBJECT IDENTIFIER ::= { ospfRouteGroup 1 } ospfInterArea OBJECT IDENTIFIER ::= { ospfRouteGroup 2 } ospfExternalType1 OBJECT IDENTIFIER ::= { ospfRouteGroup 3 } ospfExternalType2 OBJECT IDENTIFIER ::= { ospfRouteGroup 4 } -- ipCidrRouteMetric1 is, by definition, the primary routing -- metric. Therefore, it should be the metric that route -- selection is based on. For intra-area and inter-area routes, -- it is an OSPF metric. For External Type 1 (comparable value) -- routes, it is an OSPF metric plus the External Metric. For -- external Type 2 (non-comparable value) routes, it is the -- external metric. -- ipCidrRouteMetric2 is, by definition, a secondary routing -- metric. Therefore, it should be the metric that breaks a tie -- among routes having equal metric1 values and the same -- calculation rule. For intra-area, inter-area routes, and -- External Type 1 (comparable value) routes, it is unused. For -- External Type 2 (non-comparable value) routes, it is the metric -- to the AS border router. -- ipCidrRouteMetric3, ipCidrRouteMetric4, and ipCidrRouteMetric5 -- are unused. -- The OSPF Area Aggregate Table -- -- This table replaces the OSPF Area Summary Table, being an -- extension of that for CIDR routers. ospfAreaAggregateTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfAreaAggregateEntry MAX-ACCESS not-accessible STATUS current Galecki, et al. Standards Track [Page 66] RFC 4750 OSPFv2 MIB December 2006 DESCRIPTION "The Area Aggregate Table acts as an adjunct to the Area Table. It describes those address aggregates that are configured to be propagated from an area. Its purpose is to reduce the amount of information that is known beyond an Area's borders. It contains a set of IP address ranges specified by an IP address/IP network mask pair. For example, a class B address range of X.X.X.X with a network mask of 255.255.0.0 includes all IP addresses from X.X.0.0 to X.X.255.255. Note that if ranges are configured such that one range subsumes another range (e.g., 10.0.0.0 mask 255.0.0.0 and 10.1.0.0 mask 255.255.0.0), the most specific match is the preferred one." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospf 14 } ospfAreaAggregateEntry OBJECT-TYPE SYNTAX OspfAreaAggregateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single area aggregate entry. Information in this table is persistent and when this object is written the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" INDEX { ospfAreaAggregateAreaID, ospfAreaAggregateLsdbType, ospfAreaAggregateNet, ospfAreaAggregateMask } ::= { ospfAreaAggregateTable 1 } OspfAreaAggregateEntry ::= SEQUENCE { ospfAreaAggregateAreaID AreaID, ospfAreaAggregateLsdbType INTEGER, ospfAreaAggregateNet IpAddress, ospfAreaAggregateMask IpAddress, ospfAreaAggregateStatus Galecki, et al. Standards Track [Page 67] RFC 4750 OSPFv2 MIB December 2006 RowStatus, ospfAreaAggregateEffect INTEGER, ospfAreaAggregateExtRouteTag Unsigned32 } ospfAreaAggregateAreaID OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The area within which the address aggregate is to be found." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfAreaAggregateEntry 1 } ospfAreaAggregateLsdbType OBJECT-TYPE SYNTAX INTEGER { summaryLink (3), nssaExternalLink (7) } MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The type of the address aggregate. This field specifies the Lsdb type that this address aggregate applies to." REFERENCE "OSPF Version 2, Appendix A.4.1 The Link State Advertisement header" ::= { ospfAreaAggregateEntry 2 } ospfAreaAggregateNet OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The IP address of the net or subnet indicated by the range." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfAreaAggregateEntry 3 } Galecki, et al. Standards Track [Page 68] RFC 4750 OSPFv2 MIB December 2006 ospfAreaAggregateMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The subnet mask that pertains to the net or subnet." REFERENCE "OSPF Version 2, Appendix C.2 Area parameters" ::= { ospfAreaAggregateEntry 4 } ospfAreaAggregateStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfAreaAggregateEntry 5 } ospfAreaAggregateEffect OBJECT-TYPE SYNTAX INTEGER { advertiseMatching (1), doNotAdvertiseMatching (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Subnets subsumed by ranges either trigger the advertisement of the indicated aggregate (advertiseMatching) or result in the subnet's not being advertised at all outside the area." DEFVAL { advertiseMatching } ::= { ospfAreaAggregateEntry 6 } ospfAreaAggregateExtRouteTag OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "External route tag to be included in NSSA (type-7) LSAs." Galecki, et al. Standards Track [Page 69] RFC 4750 OSPFv2 MIB December 2006 DEFVAL { 0 } ::= { ospfAreaAggregateEntry 7 } -- OSPF Link State Database, link-local for non-virtual links ospfLocalLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfLocalLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPF Process's link-local link state database for non-virtual links. This table is identical to the OSPF LSDB Table in format, but contains only link-local Link State Advertisements for non-virtual links. The purpose is to allow link-local LSAs to be displayed for each non-virtual interface. This table is implemented to support type-9 LSAs that are defined in 'The OSPF Opaque LSA Option'." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements and The OSPF Opaque LSA Option" ::= { ospf 17 } ospfLocalLsdbEntry OBJECT-TYPE SYNTAX OspfLocalLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single link state advertisement." INDEX { ospfLocalLsdbIpAddress, ospfLocalLsdbAddressLessIf, ospfLocalLsdbType, ospfLocalLsdbLsid, ospfLocalLsdbRouterId } ::= { ospfLocalLsdbTable 1 } OspfLocalLsdbEntry ::= SEQUENCE { ospfLocalLsdbIpAddress IpAddress, ospfLocalLsdbAddressLessIf InterfaceIndexOrZero, ospfLocalLsdbType INTEGER, ospfLocalLsdbLsid IpAddress, ospfLocalLsdbRouterId RouterID, Galecki, et al. Standards Track [Page 70] RFC 4750 OSPFv2 MIB December 2006 ospfLocalLsdbSequence Integer32, ospfLocalLsdbAge Integer32, ospfLocalLsdbChecksum Integer32, ospfLocalLsdbAdvertisement OCTET STRING } ospfLocalLsdbIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the interface from which the LSA was received if the interface is numbered." REFERENCE "OSPF Version 2, Appendix C.3 Interface parameters" ::= { ospfLocalLsdbEntry 1 } ospfLocalLsdbAddressLessIf OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index of the interface from which the LSA was received if the interface is unnumbered." REFERENCE "OSPF Version 2, Appendix C.3 Interface parameters" ::= { ospfLocalLsdbEntry 2 } ospfLocalLsdbType OBJECT-TYPE SYNTAX INTEGER { localOpaqueLink (9) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format." REFERENCE "OSPF Version 2, Appendix A.4.1 The Link State Advertisement header" ::= { ospfLocalLsdbEntry 3 } ospfLocalLsdbLsid OBJECT-TYPE Galecki, et al. Standards Track [Page 71] RFC 4750 OSPFv2 MIB December 2006 SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Link State ID is an LS Type Specific field containing a 32-bit identifier in IP address format; it identifies the piece of the routing domain that is being described by the advertisement." REFERENCE "OSPF Version 2, Section 12.1.4 Link State ID" ::= { ospfLocalLsdbEntry 4 } ospfLocalLsdbRouterId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1 Global parameters" ::= { ospfLocalLsdbEntry 5 } ospfLocalLsdbSequence OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It starts with the value '80000001'h, or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. Thus, a typical sequence number will be very negative. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6 LS sequence number" ::= { ospfLocalLsdbEntry 6 } ospfLocalLsdbAge OBJECT-TYPE SYNTAX Integer32 -- Should be 0..MaxAge, except when -- doNotAge bit is set UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Galecki, et al. Standards Track [Page 72] RFC 4750 OSPFv2 MIB December 2006 "This field is the age of the link state advertisement in seconds." REFERENCE "OSPF Version 2, Section 12.1.1 LS age" ::= { ospfLocalLsdbEntry 7 } ospfLocalLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7 LS checksum" ::= { ospfLocalLsdbEntry 8 } ospfLocalLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header. Note that for variable length LSAs, SNMP agents may not be able to return the largest string size." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements" ::= { ospfLocalLsdbEntry 9 } -- OSPF Link State Database, link-local for virtual Links ospfVirtLocalLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfVirtLocalLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPF Process's link-local link state database for virtual links. Galecki, et al. Standards Track [Page 73] RFC 4750 OSPFv2 MIB December 2006 This table is identical to the OSPF LSDB Table in format, but contains only link-local Link State Advertisements for virtual links. The purpose is to allow link-local LSAs to be displayed for each virtual interface. This table is implemented to support type-9 LSAs that are defined in 'The OSPF Opaque LSA Option'." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements and The OSPF Opaque LSA Option" ::= { ospf 18 } ospfVirtLocalLsdbEntry OBJECT-TYPE SYNTAX OspfVirtLocalLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single link state advertisement." INDEX { ospfVirtLocalLsdbTransitArea, ospfVirtLocalLsdbNeighbor, ospfVirtLocalLsdbType, ospfVirtLocalLsdbLsid, ospfVirtLocalLsdbRouterId } ::= { ospfVirtLocalLsdbTable 1 } OspfVirtLocalLsdbEntry ::= SEQUENCE { ospfVirtLocalLsdbTransitArea AreaID, ospfVirtLocalLsdbNeighbor RouterID, ospfVirtLocalLsdbType INTEGER, ospfVirtLocalLsdbLsid IpAddress, ospfVirtLocalLsdbRouterId RouterID, ospfVirtLocalLsdbSequence Integer32, ospfVirtLocalLsdbAge Integer32, ospfVirtLocalLsdbChecksum Integer32, ospfVirtLocalLsdbAdvertisement OCTET STRING } ospfVirtLocalLsdbTransitArea OBJECT-TYPE Galecki, et al. Standards Track [Page 74] RFC 4750 OSPFv2 MIB December 2006 SYNTAX AreaID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The transit area that the virtual link traverses. By definition, this is not 0.0.0.0." REFERENCE "OSPF Version 2, Appendix C.3 Interface parameters" ::= { ospfVirtLocalLsdbEntry 1 } ospfVirtLocalLsdbNeighbor OBJECT-TYPE SYNTAX RouterID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Router ID of the virtual neighbor." REFERENCE "OSPF Version 2, Appendix C.3 Interface parameters" ::= { ospfVirtLocalLsdbEntry 2 } ospfVirtLocalLsdbType OBJECT-TYPE SYNTAX INTEGER { localOpaqueLink (9) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format." REFERENCE "OSPF Version 2, Appendix A.4.1 The Link State Advertisement header" ::= { ospfVirtLocalLsdbEntry 3 } ospfVirtLocalLsdbLsid OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Link State ID is an LS Type Specific field containing a 32-bit identifier in IP address format; it identifies the piece of the routing domain that is being described by the advertisement." REFERENCE "OSPF Version 2, Section 12.1.4 Link State ID" ::= { ospfVirtLocalLsdbEntry 4 } ospfVirtLocalLsdbRouterId OBJECT-TYPE SYNTAX RouterID Galecki, et al. Standards Track [Page 75] RFC 4750 OSPFv2 MIB December 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1 Global parameters" ::= { ospfVirtLocalLsdbEntry 5 } ospfVirtLocalLsdbSequence OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It starts with the value '80000001'h, or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. Thus, a typical sequence number will be very negative. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6 LS sequence number" ::= { ospfVirtLocalLsdbEntry 6 } ospfVirtLocalLsdbAge OBJECT-TYPE SYNTAX Integer32 -- Should be 0..MaxAge, except when -- doNotAge bit is set UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the age of the link state advertisement in seconds." REFERENCE "OSPF Version 2, Section 12.1.1 LS age" ::= { ospfVirtLocalLsdbEntry 7 } ospfVirtLocalLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that Galecki, et al. Standards Track [Page 76] RFC 4750 OSPFv2 MIB December 2006 an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7 LS checksum" ::= { ospfVirtLocalLsdbEntry 8 } ospfVirtLocalLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements. Note that for variable length LSAs, SNMP agents may not be able to return the largest string size." ::= { ospfVirtLocalLsdbEntry 9 } -- OSPF Link State Database, AS-scope ospfAsLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfAsLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPF Process's AS-scope LSA link state database. The database contains the AS-scope Link State Advertisements from throughout the areas that the device is attached to. This table is identical to the OSPF LSDB Table in format, but contains only AS-scope Link State Advertisements. The purpose is to allow AS-scope LSAs to be displayed once for the router rather than once in each non-stub area." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements" ::= { ospf 19 } ospfAsLsdbEntry OBJECT-TYPE SYNTAX OspfAsLsdbEntry Galecki, et al. Standards Track [Page 77] RFC 4750 OSPFv2 MIB December 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single link state advertisement." INDEX { ospfAsLsdbType, ospfAsLsdbLsid, ospfAsLsdbRouterId } ::= { ospfAsLsdbTable 1 } OspfAsLsdbEntry ::= SEQUENCE { ospfAsLsdbType INTEGER, ospfAsLsdbLsid IpAddress, ospfAsLsdbRouterId RouterID, ospfAsLsdbSequence Integer32, ospfAsLsdbAge Integer32, ospfAsLsdbChecksum Integer32, ospfAsLsdbAdvertisement OCTET STRING } ospfAsLsdbType OBJECT-TYPE SYNTAX INTEGER { asExternalLink (5), asOpaqueLink (11) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format." REFERENCE "OSPF Version 2, Appendix A.4.1 The Link State Advertisement header" ::= { ospfAsLsdbEntry 1 } ospfAsLsdbLsid OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Link State ID is an LS Type Specific field containing either a Router ID or an IP address; Galecki, et al. Standards Track [Page 78] RFC 4750 OSPFv2 MIB December 2006 it identifies the piece of the routing domain that is being described by the advertisement." REFERENCE "OSPF Version 2, Section 12.1.4 Link State ID" ::= { ospfAsLsdbEntry 2 } ospfAsLsdbRouterId OBJECT-TYPE SYNTAX RouterID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1 Global parameters" ::= { ospfAsLsdbEntry 3 } ospfAsLsdbSequence OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It starts with the value '80000001'h, or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. Thus, a typical sequence number will be very negative. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6 LS sequence number" ::= { ospfAsLsdbEntry 4 } ospfAsLsdbAge OBJECT-TYPE SYNTAX Integer32 -- Should be 0..MaxAge, except when -- doNotAge bit is set UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the age of the link state advertisement in seconds." REFERENCE "OSPF Version 2, Section 12.1.1 LS age" ::= { ospfAsLsdbEntry 5 } Galecki, et al. Standards Track [Page 79] RFC 4750 OSPFv2 MIB December 2006 ospfAsLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7 LS checksum" ::= { ospfAsLsdbEntry 6 } ospfAsLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header." REFERENCE "OSPF Version 2, Section 12 Link State Advertisements. Note that for variable length LSAs, SNMP agents may not be able to return the largest string size." ::= { ospfAsLsdbEntry 7 } -- OSPF Area LSA Counter Table ospfAreaLsaCountTable OBJECT-TYPE SYNTAX SEQUENCE OF OspfAreaLsaCountEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maintains per-area, per-LSA-type counters" ::= { ospf 20 } ospfAreaLsaCountEntry OBJECT-TYPE SYNTAX OspfAreaLsaCountEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry with a number of link advertisements Galecki, et al. Standards Track [Page 80] RFC 4750 OSPFv2 MIB December 2006 of a given type for a given area." INDEX { ospfAreaLsaCountAreaId, ospfAreaLsaCountLsaType } ::= { ospfAreaLsaCountTable 1 } OspfAreaLsaCountEntry ::= SEQUENCE { ospfAreaLsaCountAreaId AreaID, ospfAreaLsaCountLsaType INTEGER, ospfAreaLsaCountNumber Gauge32 } ospfAreaLsaCountAreaId OBJECT-TYPE SYNTAX AreaID MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry Area ID." ::= { ospfAreaLsaCountEntry 1 } ospfAreaLsaCountLsaType OBJECT-TYPE SYNTAX INTEGER { routerLink (1), networkLink (2), summaryLink (3), asSummaryLink (4), multicastLink (6), nssaExternalLink (7), areaOpaqueLink (10) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry LSA type." ::= { ospfAreaLsaCountEntry 2 } ospfAreaLsaCountNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of LSAs of a given type for a given area." ::= { ospfAreaLsaCountEntry 3 } -- conformance information Galecki, et al. Standards Track [Page 81] RFC 4750 OSPFv2 MIB December 2006 ospfConformance OBJECT IDENTIFIER ::= { ospf 15 } ospfGroups OBJECT IDENTIFIER ::= { ospfConformance 1 } ospfCompliances OBJECT IDENTIFIER ::= { ospfConformance 2 } -- compliance statements ospfCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for OSPF systems conforming to RFC 1850." MODULE -- this module MANDATORY-GROUPS { ospfBasicGroup, ospfAreaGroup, ospfStubAreaGroup, ospfIfGroup, ospfIfMetricGroup, ospfVirtIfGroup, ospfNbrGroup, ospfVirtNbrGroup, ospfAreaAggregateGroup } GROUP ospfHostGroup DESCRIPTION "This group is mandatory for OSPF systems that support attached hosts." GROUP ospfLsdbGroup DESCRIPTION "This group is mandatory for OSPF systems that display their per-area link state database." GROUP ospfExtLsdbGroup DESCRIPTION "This group is mandatory for OSPF systems that display their external link state database." ::= { ospfCompliances 1 } ospfCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement." MODULE -- this module MANDATORY-GROUPS { ospfBasicGroup2, ospfAreaGroup2, ospfStubAreaGroup, ospfIfGroup2, Galecki, et al. Standards Track [Page 82] RFC 4750 OSPFv2 MIB December 2006 ospfIfMetricGroup, ospfVirtIfGroup2, ospfNbrGroup2, ospfVirtNbrGroup2, ospfAreaAggregateGroup2 } GROUP ospfHostGroup2 DESCRIPTION "This group is mandatory for OSPF systems that support attached hosts." GROUP ospfLsdbGroup DESCRIPTION "This group is mandatory for OSPF systems that display their per-area link state database." GROUP ospfAsLsdbGroup DESCRIPTION "This group is mandatory for OSPF systems that display their AS-scope link state database." GROUP ospfLocalLsdbGroup DESCRIPTION "This group is mandatory for OSPF systems that display their per-link link state database for non-virtual links." GROUP ospfVirtLocalLsdbGroup DESCRIPTION "This group is mandatory for OSPF systems that display their per-link link state database for virtual links." GROUP ospfAreaLsaCountGroup DESCRIPTION "This group is mandatory for OSPF systems that display per-area, per-LSA-type counters." ::= { ospfCompliances 2 } ospfComplianceObsolete MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "Contains obsolete object groups." MODULE -- this module GROUP ospfAreaRangeGroup DESCRIPTION "This group is obsolete, and it is mandatory only for non-Classless Inter-Domain Routing (CIDR) OSPF systems that support multiple areas." GROUP ospfObsoleteGroup DESCRIPTION "This group contains obsolete objects, which are no longer required for OSPF systems." ::= { ospfCompliances 3 } Galecki, et al. Standards Track [Page 83] RFC 4750 OSPFv2 MIB December 2006 -- units of conformance ospfBasicGroup OBJECT-GROUP OBJECTS { ospfRouterId, ospfAdminStat, ospfVersionNumber, ospfAreaBdrRtrStatus, ospfASBdrRtrStatus, ospfExternLsaCount, ospfExternLsaCksumSum, ospfTOSSupport, ospfOriginateNewLsas, ospfRxNewLsas, ospfExtLsdbLimit, ospfMulticastExtensions, ospfExitOverflowInterval, ospfDemandExtensions } STATUS deprecated DESCRIPTION "These objects are used to monitor/manage global OSPF parameters. This object group conforms to RFC 1850." ::= { ospfGroups 1 } ospfAreaGroup OBJECT-GROUP OBJECTS { ospfAreaId, ospfImportAsExtern, ospfSpfRuns, ospfAreaBdrRtrCount, ospfAsBdrRtrCount, ospfAreaLsaCount, ospfAreaLsaCksumSum, ospfAreaSummary, ospfAreaStatus } STATUS deprecated DESCRIPTION "These objects are used for OSPF systems supporting areas per RFC 1850." ::= { ospfGroups 2 } ospfStubAreaGroup OBJECT-GROUP OBJECTS { ospfStubAreaId, ospfStubTOS, Galecki, et al. Standards Track [Page 84] RFC 4750 OSPFv2 MIB December 2006 ospfStubMetric, ospfStubStatus, ospfStubMetricType } STATUS current DESCRIPTION "These objects are used for OSPF systems supporting stub areas." ::= { ospfGroups 3 } ospfLsdbGroup OBJECT-GROUP OBJECTS { ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId, ospfLsdbSequence, ospfLsdbAge, ospfLsdbChecksum, ospfLsdbAdvertisement } STATUS current DESCRIPTION "These objects are used for OSPF systems that display their link state database." ::= { ospfGroups 4 } ospfAreaRangeGroup OBJECT-GROUP OBJECTS { ospfAreaRangeAreaId, ospfAreaRangeNet, ospfAreaRangeMask, ospfAreaRangeStatus, ospfAreaRangeEffect } STATUS obsolete DESCRIPTION "These objects are used for non-CIDR OSPF systems that support multiple areas. This object group is obsolete." ::= { ospfGroups 5 } ospfHostGroup OBJECT-GROUP OBJECTS { ospfHostIpAddress, ospfHostTOS, ospfHostMetric, ospfHostStatus, Galecki, et al. Standards Track [Page 85] RFC 4750 OSPFv2 MIB December 2006 ospfHostAreaID } STATUS deprecated DESCRIPTION "These objects are used for OSPF systems that support attached hosts." ::= { ospfGroups 6 } ospfIfGroup OBJECT-GROUP OBJECTS { ospfIfIpAddress, ospfAddressLessIf, ospfIfAreaId, ospfIfType, ospfIfAdminStat, ospfIfRtrPriority, ospfIfTransitDelay, ospfIfRetransInterval, ospfIfHelloInterval, ospfIfRtrDeadInterval, ospfIfPollInterval, ospfIfState, ospfIfDesignatedRouter, ospfIfBackupDesignatedRouter, ospfIfEvents, ospfIfAuthType, ospfIfAuthKey, ospfIfStatus, ospfIfMulticastForwarding, ospfIfDemand } STATUS deprecated DESCRIPTION "These objects are used to monitor/manage OSPF interfaces. This object group conforms to RFC 1850." ::= { ospfGroups 7 } ospfIfMetricGroup OBJECT-GROUP OBJECTS { ospfIfMetricIpAddress, ospfIfMetricAddressLessIf, ospfIfMetricTOS, ospfIfMetricValue, ospfIfMetricStatus } STATUS current DESCRIPTION "These objects are used for OSPF systems for supporting Galecki, et al. Standards Track [Page 86] RFC 4750 OSPFv2 MIB December 2006 interface metrics." ::= { ospfGroups 8 } ospfVirtIfGroup OBJECT-GROUP OBJECTS { ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfTransitDelay, ospfVirtIfRetransInterval, ospfVirtIfHelloInterval, ospfVirtIfRtrDeadInterval, ospfVirtIfState, ospfVirtIfEvents, ospfVirtIfAuthType, ospfVirtIfAuthKey, ospfVirtIfStatus } STATUS deprecated DESCRIPTION "These objects are used for OSPF systems for supporting virtual interfaces. This object group conforms to RFC 1850." ::= { ospfGroups 9 } ospfNbrGroup OBJECT-GROUP OBJECTS { ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrOptions, ospfNbrPriority, ospfNbrState, ospfNbrEvents, ospfNbrLsRetransQLen, ospfNbmaNbrStatus, ospfNbmaNbrPermanence, ospfNbrHelloSuppressed } STATUS deprecated DESCRIPTION "These objects are used to monitor/manage OSPF neighbors. This object group conforms to RFC 1850." ::= { ospfGroups 10 } ospfVirtNbrGroup OBJECT-GROUP OBJECTS { ospfVirtNbrArea, ospfVirtNbrRtrId, Galecki, et al. Standards Track [Page 87] RFC 4750 OSPFv2 MIB December 2006 ospfVirtNbrIpAddr, ospfVirtNbrOptions, ospfVirtNbrState, ospfVirtNbrEvents, ospfVirtNbrLsRetransQLen, ospfVirtNbrHelloSuppressed } STATUS deprecated DESCRIPTION "These objects are used to monitor/manage OSPF virtual neighbors. This object group conforms to RFC 1850." ::= { ospfGroups 11 } ospfExtLsdbGroup OBJECT-GROUP OBJECTS { ospfExtLsdbType, ospfExtLsdbLsid, ospfExtLsdbRouterId, ospfExtLsdbSequence, ospfExtLsdbAge, ospfExtLsdbChecksum, ospfExtLsdbAdvertisement } STATUS deprecated DESCRIPTION "These objects are used for OSPF systems that display their link state database. This object group conforms to RFC 1850. This object group is replaced by the ospfAsLsdbGroup in order to support any AS-scope LSA type in a single table." ::= { ospfGroups 12 } ospfAreaAggregateGroup OBJECT-GROUP OBJECTS { ospfAreaAggregateAreaID, ospfAreaAggregateLsdbType, ospfAreaAggregateNet, ospfAreaAggregateMask, ospfAreaAggregateStatus, ospfAreaAggregateEffect } STATUS deprecated DESCRIPTION "These objects are used for OSPF systems to support network prefix aggregation across areas." Galecki, et al. Standards Track [Page 88] RFC 4750 OSPFv2 MIB December 2006 ::= { ospfGroups 13 } ospfLocalLsdbGroup OBJECT-GROUP OBJECTS { ospfLocalLsdbSequence, ospfLocalLsdbAge, ospfLocalLsdbChecksum, ospfLocalLsdbAdvertisement } STATUS current DESCRIPTION "These objects are used for OSPF systems that display their link-local link state databases for non-virtual links." ::= { ospfGroups 14 } ospfVirtLocalLsdbGroup OBJECT-GROUP OBJECTS { ospfVirtLocalLsdbSequence, ospfVirtLocalLsdbAge, ospfVirtLocalLsdbChecksum, ospfVirtLocalLsdbAdvertisement } STATUS current DESCRIPTION "These objects are used for OSPF systems that display their link-local link state databases for virtual links." ::= { ospfGroups 15 } ospfAsLsdbGroup OBJECT-GROUP OBJECTS { ospfAsLsdbSequence, ospfAsLsdbAge, ospfAsLsdbChecksum, ospfAsLsdbAdvertisement } STATUS current DESCRIPTION "These objects are used for OSPF systems that display their AS-scope link state database." ::= { ospfGroups 16 } ospfBasicGroup2 OBJECT-GROUP OBJECTS { ospfRouterId, ospfAdminStat, ospfVersionNumber, Galecki, et al. Standards Track [Page 89] RFC 4750 OSPFv2 MIB December 2006 ospfAreaBdrRtrStatus, ospfASBdrRtrStatus, ospfExternLsaCount, ospfExternLsaCksumSum, ospfTOSSupport, ospfOriginateNewLsas, ospfRxNewLsas, ospfExtLsdbLimit, ospfMulticastExtensions, ospfExitOverflowInterval, ospfDemandExtensions, ospfRFC1583Compatibility, ospfOpaqueLsaSupport, ospfReferenceBandwidth, ospfRestartSupport, ospfRestartInterval, ospfRestartStrictLsaChecking, ospfRestartStatus, ospfRestartAge, ospfRestartExitReason, ospfAsLsaCount, ospfAsLsaCksumSum, ospfStubRouterSupport, ospfStubRouterAdvertisement, ospfDiscontinuityTime } STATUS current DESCRIPTION "These objects are used to monitor/manage OSPF global parameters." ::= { ospfGroups 17 } ospfAreaGroup2 OBJECT-GROUP OBJECTS { ospfAreaId, ospfImportAsExtern, ospfSpfRuns, ospfAreaBdrRtrCount, ospfAsBdrRtrCount, ospfAreaLsaCount, ospfAreaLsaCksumSum, ospfAreaSummary, ospfAreaStatus, ospfAreaNssaTranslatorRole, ospfAreaNssaTranslatorState, ospfAreaNssaTranslatorStabilityInterval, ospfAreaNssaTranslatorEvents } Galecki, et al. Standards Track [Page 90] RFC 4750 OSPFv2 MIB December 2006 STATUS current DESCRIPTION "These objects are used by OSPF systems to support areas." ::= { ospfGroups 18 } ospfIfGroup2 OBJECT-GROUP OBJECTS { ospfIfIpAddress, ospfAddressLessIf, ospfIfAreaId, ospfIfType, ospfIfAdminStat, ospfIfRtrPriority, ospfIfTransitDelay, ospfIfRetransInterval, ospfIfHelloInterval, ospfIfRtrDeadInterval, ospfIfPollInterval, ospfIfState, ospfIfDesignatedRouter, ospfIfBackupDesignatedRouter, ospfIfEvents, ospfIfAuthType, ospfIfAuthKey, ospfIfStatus, ospfIfMulticastForwarding, ospfIfDemand, ospfIfLsaCount, ospfIfLsaCksumSum } STATUS current DESCRIPTION "These objects are used to monitor/manage OSPF interfaces." ::= { ospfGroups 19 } ospfVirtIfGroup2 OBJECT-GROUP OBJECTS { ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfTransitDelay, ospfVirtIfRetransInterval, ospfVirtIfHelloInterval, ospfVirtIfRtrDeadInterval, ospfVirtIfState, ospfVirtIfEvents, ospfVirtIfAuthType, ospfVirtIfAuthKey, Galecki, et al. Standards Track [Page 91] RFC 4750 OSPFv2 MIB December 2006 ospfVirtIfStatus, ospfVirtIfLsaCount, ospfVirtIfLsaCksumSum, ospfIfDesignatedRouterId, ospfIfBackupDesignatedRouterId } STATUS current DESCRIPTION "These objects are used to monitor/manage OSPF virtual interfaces." ::= { ospfGroups 20 } ospfNbrGroup2 OBJECT-GROUP OBJECTS { ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrOptions, ospfNbrPriority, ospfNbrState, ospfNbrEvents, ospfNbrLsRetransQLen, ospfNbmaNbrStatus, ospfNbmaNbrPermanence, ospfNbrHelloSuppressed, ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, ospfNbrRestartHelperExitReason } STATUS current DESCRIPTION "These objects are used to monitor/manage OSPF neighbors." ::= { ospfGroups 21 } ospfVirtNbrGroup2 OBJECT-GROUP OBJECTS { ospfVirtNbrArea, ospfVirtNbrRtrId, ospfVirtNbrIpAddr, ospfVirtNbrOptions, ospfVirtNbrState, ospfVirtNbrEvents, ospfVirtNbrLsRetransQLen, ospfVirtNbrHelloSuppressed, ospfVirtNbrRestartHelperStatus, ospfVirtNbrRestartHelperAge, ospfVirtNbrRestartHelperExitReason Galecki, et al. Standards Track [Page 92] RFC 4750 OSPFv2 MIB December 2006 } STATUS current DESCRIPTION "These objects are used to monitor/manage OSPF virtual neighbors." ::= { ospfGroups 22 } ospfAreaAggregateGroup2 OBJECT-GROUP OBJECTS { ospfAreaAggregateAreaID, ospfAreaAggregateLsdbType, ospfAreaAggregateNet, ospfAreaAggregateMask, ospfAreaAggregateStatus, ospfAreaAggregateEffect, ospfAreaAggregateExtRouteTag } STATUS current DESCRIPTION "These objects are used for OSPF systems to support network prefix aggregation across areas." ::= { ospfGroups 23 } ospfAreaLsaCountGroup OBJECT-GROUP OBJECTS { ospfAreaLsaCountNumber } STATUS current DESCRIPTION "These objects are used for OSPF systems that display per-area, per-LSA-type counters." ::= { ospfGroups 24 } ospfHostGroup2 OBJECT-GROUP OBJECTS { ospfHostIpAddress, ospfHostTOS, ospfHostMetric, ospfHostStatus, ospfHostCfgAreaID } STATUS current DESCRIPTION "These objects are used for OSPF systems that support attached hosts." ::= { ospfGroups 25 } -- This object group is included for SMI conformance. It is not a Galecki, et al. Standards Track [Page 93] RFC 4750 OSPFv2 MIB December 2006 -- mandatory group for compliance with this MIB ospfObsoleteGroup OBJECT-GROUP OBJECTS { ospfAuthType } STATUS obsolete DESCRIPTION "These objects are obsolete and are no longer required for OSPF systems. They are placed into this group for SMI conformance." ::= { ospfGroups 26 } END 4. OSPF Trap Overview 4.1. Introduction OSPF is an event-driven routing protocol, where an event can be a change in an OSPF interface's link-level status, the expiration of an OSPF timer, or the reception of an OSPF protocol packet. Many of the actions that OSPF takes as a result of these events will result in a change of the routing topology. As routing topologies become large and complex, it is often difficult to locate the source of a topology change or unpredicted routing path by polling a large number or routers. Because of the difficulty of polling a large number of devices, a more prudent approach is for devices to notify a network manager of potentially critical OSPF events using SNMP traps. This section defines a set of traps, objects, and mechanisms to enhance the ability to manage IP internetworks that use OSPF as their Interior Gateway Protocol (IGP). It is an optional but very useful extension to the OSPF MIB. Galecki, et al. Standards Track [Page 94] RFC 4750 OSPFv2 MIB December 2006 4.2. Approach The mechanism for sending traps is straightforward. When an exception event occurs, the application notifies the local agent, who sends a trap to the appropriate SNMP management stations. The message includes the trap type and may include a list of trap- specific variables. Section 5 gives the trap definitions, which includes the variable lists. The Router ID of the originator of the trap is included in the variable list so that the network manager may easily determine the source of the trap. To limit the frequency of OSPF traps, the following additional mechanisms are suggested. 4.3. Ignoring Initial Activity The majority of critical events occur when OSPF is enabled on a router, at which time the designated router is elected and neighbor adjacencies are formed. During this initial period, a potential flood of traps is unnecessary since the events are expected. To avoid unnecessary traps, a router should not originate expected OSPF interface-related traps until two of that interface's dead timer intervals have elapsed. The expected OSPF interface traps are ospfIfStateChange, ospfVirtIfStateChange, ospfNbrStateChange, ospfVirtNbrStateChange, ospfTxRetransmit, and ospfVirtIfTxRetransmit. Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated until two dead timer intervals have elapsed where the dead timer interval used should be the dead timer with the smallest value. 4.4. Throttling Traps The mechanism for throttling the traps is similar to the mechanism explained in RFC 1224 [RFC1224]. The basic premise of the throttling mechanism is that of a sliding window, defined in seconds and an upper bound on the number of traps that may be generated within this window. Note that unlike RFC 1224, traps are not sent to inform the network manager that the throttling mechanism has kicked in. A single window should be used to throttle all OSPF trap types except for the ospfLsdbOverflow and the ospfLsdbApproachingOverflow traps, which should not be throttled. For example, with a window time of 3, an upper bound of 3, and events to cause trap types 1, 3, 5, and 7 (4 traps within a 3-second period), the type-7 (the 4th) trap should not be generated. Appropriate values are 7 traps with a window time of 10 seconds. Galecki, et al. Standards Track [Page 95] RFC 4750 OSPFv2 MIB December 2006 4.5. One Trap Per OSPF Event Several of the traps defined in section 5 are generated as the result of finding an unusual condition while parsing an OSPF packet or a processing a timer event. There may be more than one unusual condition detected while handling the event. For example, a link state update packet may contain several retransmitted link state advertisements (LSAs), or a retransmitted database description packet may contain several database description entries. To limit the number of traps and variables, OSPF should generate at most one trap per OSPF event. Only the variables associated with the first unusual condition should be included with the trap. Similarly, if more than one type of unusual condition is encountered while parsing the packet, only the first event will generate a trap. 4.6. Polling Event Counters Many of the tables in the OSPF MIB contain generalized event counters. By enabling the traps defined in this document, a network manager can obtain more specific information about these events. A network manager may want to poll these event counters and enable specific OSPF traps when a particular counter starts increasing abnormally. The following table shows the relationship between the event counters defined in the OSPF MIB and the trap types. Counter32 Trap Type ----------------------- ------------------------ ospfOriginateNewLsas ospfOriginateLsa ospfIfEvents ospfIfStateChange ospfConfigError ospfIfAuthFailure ospfRxBadPacket ospfTxRetransmit ospfVirtIfEvents ospfVirtIfStateChange ospfVirtIfConfigError ospfVirtIfAuthFailure ospfVirtIfRxBadPacket ospfVirtIfTxRetransmit ospfNbrEvents ospfNbrStateChange ospfVirtNbrEvents ospfVirtNbrStateChange ospfExternLSACount ospfLsdbApproachingOverflow ospfExternLSACount ospfLsdbOverflow Galecki, et al. Standards Track [Page 96] RFC 4750 OSPFv2 MIB December 2006 4.7. Translating Notification Parameters The definition of the OSPF notifications pre-dates the RFC 2578 [RFC2578] requirement of having a zero value for the penultimate sub-identifier for translating SNMPv2/SNMPv3 trap parameters to SNMPv1 trap parameters. RFC 3584 [RFC3584], section 3, defines the translation rules that can be implemented by intermediate proxy- agents or multi-lingual agents to convert SNMPv2/SNMPv3 notifications to SNMPv1 notifications and vice versa. The conversion is not reversible, that is, a conversion to one SNMP version and then back again will result in an incorrectly formatted version of the notification. According to the rules specified in RFC 3584, section 3.1, translation of OSPF notifications from SNMPv1 to SNMPv2/SNMPv3 would result in the SNMPv2/SNMPv3 snmpTrapOID being the concatenation of the SNMPv1 'enterprise' parameter and two additional sub-identifiers, '0' and the SNMPv1 'specific-trap' parameter. According to the rules specified in RFC 3584, section 3.2, translation of OSPF notifications from SNMPv2/SNMPv3 to SNMPv1, as the notifications are defined in this MIB, would result in the SNMPv1 'enterprise' parameter being set to the SNMPv2/SNMPv3 snmpTrapOID parameter value with the last sub-identifier removed and the 'specific-trap' parameter being set to the last sub-identifier of the SNMPv2/SNMPv3 snmpTrapOID parameter. Note that a notification originated from an SNMPv1 agent will not be converted into the same notification that would be originated from a native SNMPv2/SNMPv3 agent. 4.8. Historical Artifacts The MIB modules that are updated by this document were originally written in SMIv1 for SNMPv1 when only traps were used. Since this version of the MIB module is written in SMIv2, it should be understood that all types of notifications, trap and inform PDUs, may be used by native SNMPv2 and SNMPv3 agents, although only traps are mentioned. Also, for backwards compatibility, the OSPF Trap module remains rooted at {ospf 16}. Galecki, et al. Standards Track [Page 97] RFC 4750 OSPFv2 MIB December 2006 5. OSPF Trap Definitions OSPF-TRAP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ospfRouterId, ospfIfIpAddress, ospfAddressLessIf, ospfIfState, ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfState, ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrState, ospfVirtNbrArea, ospfVirtNbrRtrId, ospfVirtNbrState, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId, ospfLsdbAreaId, ospfExtLsdbLimit, ospf, ospfAreaId, ospfAreaNssaTranslatorState, ospfRestartStatus, ospfRestartInterval, ospfRestartExitReason, ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, ospfNbrRestartHelperExitReason, ospfVirtNbrRestartHelperStatus, ospfVirtNbrRestartHelperAge, ospfVirtNbrRestartHelperExitReason FROM OSPF-MIB; ospfTrap MODULE-IDENTITY LAST-UPDATED "200611100000Z" -- November 10, 2006 00:00:00 EST ORGANIZATION "IETF OSPF Working Group" CONTACT-INFO "WG E-Mail: ospf@ietf.org WG Chairs: acee@cisco.com rohit@gmail.com Editors: Dan Joyal Nortel 600 Technology Park Drive Billerica, MA 01821 djoyal@nortel.com Piotr Galecki Airvana 19 Alpha Road Chelmsford, MA 01824 pgalecki@airvana.com Spencer Giacalone CSFB Eleven Madison Ave New York, NY 10010-3629 Galecki, et al. Standards Track [Page 98] RFC 4750 OSPFv2 MIB December 2006 spencer.giacalone@gmail.com" DESCRIPTION "The MIB module to describe traps for the OSPF Version 2 Protocol. Copyright (C) The IETF Trust (2006). This version of this MIB module is part of RFC 4750; see the RFC itself for full legal notices." REVISION "200611100000Z" -- November 10, 2006 00:00:00 EST DESCRIPTION "Updated for latest changes to OSPFv2: -added graceful restart related traps -added new config error types -added ospfNssaTranslatorStatusChange trap. See Appendix B of RFC 4750 for more details. This version published as part of RFC 4750" REVISION "199501201225Z" -- Fri Jan 20 12:25:50 PST 1995 DESCRIPTION "The initial SMIv2 revision of this MIB module, published in RFC 1850." ::= { ospf 16 } -- Trap Support Objects -- The following are support objects for the OSPF traps. ospfTrapControl OBJECT IDENTIFIER ::= { ospfTrap 1 } ospfTraps OBJECT IDENTIFIER ::= { ospfTrap 2 } ospfSetTrap OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-write STATUS current DESCRIPTION "A 4-octet string serving as a bit map for the trap events defined by the OSPF traps. This object is used to enable and disable specific OSPF traps where a 1 in the bit field represents enabled. The right-most bit (least significant) represents trap 0. This object is persistent and when written Galecki, et al. Standards Track [Page 99] RFC 4750 OSPFv2 MIB December 2006 the entity SHOULD save the change to non-volatile storage." ::= { ospfTrapControl 1 } ospfConfigErrorType OBJECT-TYPE SYNTAX INTEGER { badVersion (1), areaMismatch (2), unknownNbmaNbr (3), -- Router is DR eligible unknownVirtualNbr (4), authTypeMismatch(5), authFailure (6), netMaskMismatch (7), helloIntervalMismatch (8), deadIntervalMismatch (9), optionMismatch (10), mtuMismatch (11), duplicateRouterId (12), noError (13) } MAX-ACCESS read-only STATUS current DESCRIPTION "Potential types of configuration conflicts. Used by the ospfConfigError and ospfConfigVirtError traps. When the last value of a trap using this object is needed, but no traps of that type have been sent, this value pertaining to this object should be returned as noError." ::= { ospfTrapControl 2 } ospfPacketType OBJECT-TYPE SYNTAX INTEGER { hello (1), dbDescript (2), lsReq (3), lsUpdate (4), lsAck (5), nullPacket (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "OSPF packet types. When the last value of a trap using this object is needed, but no traps of that type have been sent, this value pertaining to this object should be returned as nullPacket." ::= { ospfTrapControl 3 } Galecki, et al. Standards Track [Page 100] RFC 4750 OSPFv2 MIB December 2006 ospfPacketSrc OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of an inbound packet that cannot be identified by a neighbor instance. When the last value of a trap using this object is needed, but no traps of that type have been sent, this value pertaining to this object should be returned as 0.0.0.0." ::= { ospfTrapControl 4 } -- Traps ospfVirtIfStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfState -- The new state } STATUS current DESCRIPTION "An ospfVirtIfStateChange trap signifies that there has been a change in the state of an OSPF virtual interface. This trap should be generated when the interface state regresses (e.g., goes from Point-to-Point to Down) or progresses to a terminal state (i.e., Point-to-Point)." ::= { ospfTraps 1 } ospfNbrStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrState -- The new state } STATUS current DESCRIPTION "An ospfNbrStateChange trap signifies that there has been a change in the state of a non-virtual OSPF neighbor. This trap should be generated when the neighbor state regresses (e.g., goes from Attempt or Full to 1-Way or Down) or progresses to a terminal state (e.g., Galecki, et al. Standards Track [Page 101] RFC 4750 OSPFv2 MIB December 2006 2-Way or Full). When an neighbor transitions from or to Full on non-broadcast multi-access and broadcast networks, the trap should be generated by the designated router. A designated router transitioning to Down will be noted by ospfIfStateChange." ::= { ospfTraps 2 } ospfVirtNbrStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtNbrArea, ospfVirtNbrRtrId, ospfVirtNbrState -- The new state } STATUS current DESCRIPTION "An ospfVirtNbrStateChange trap signifies that there has been a change in the state of an OSPF virtual neighbor. This trap should be generated when the neighbor state regresses (e.g., goes from Attempt or Full to 1-Way or Down) or progresses to a terminal state (e.g., Full)." ::= { ospfTraps 3 } ospfIfConfigError NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfIpAddress, ospfAddressLessIf, ospfPacketSrc, -- The source IP address ospfConfigErrorType, -- Type of error ospfPacketType } STATUS current DESCRIPTION "An ospfIfConfigError trap signifies that a packet has been received on a non-virtual interface from a router whose configuration parameters conflict with this router's configuration parameters. Note that the event optionMismatch should cause a trap only if it prevents an adjacency from forming." ::= { ospfTraps 4 } ospfVirtIfConfigError NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfConfigErrorType, -- Type of error Galecki, et al. Standards Track [Page 102] RFC 4750 OSPFv2 MIB December 2006 ospfPacketType } STATUS current DESCRIPTION "An ospfVirtIfConfigError trap signifies that a packet has been received on a virtual interface from a router whose configuration parameters conflict with this router's configuration parameters. Note that the event optionMismatch should cause a trap only if it prevents an adjacency from forming." ::= { ospfTraps 5 } ospfIfAuthFailure NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfIpAddress, ospfAddressLessIf, ospfPacketSrc, -- The source IP address ospfConfigErrorType, -- authTypeMismatch or -- authFailure ospfPacketType } STATUS current DESCRIPTION "An ospfIfAuthFailure trap signifies that a packet has been received on a non-virtual interface from a router whose authentication key or authentication type conflicts with this router's authentication key or authentication type." ::= { ospfTraps 6 } ospfVirtIfAuthFailure NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfConfigErrorType, -- authTypeMismatch or -- authFailure ospfPacketType } STATUS current DESCRIPTION "An ospfVirtIfAuthFailure trap signifies that a packet has been received on a virtual interface from a router whose authentication key or authentication type conflicts with this router's authentication key or authentication type." Galecki, et al. Standards Track [Page 103] RFC 4750 OSPFv2 MIB December 2006 ::= { ospfTraps 7 } ospfIfRxBadPacket NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfIpAddress, ospfAddressLessIf, ospfPacketSrc, -- The source IP address ospfPacketType } STATUS current DESCRIPTION "An ospfIfRxBadPacket trap signifies that an OSPF packet has been received on a non-virtual interface that cannot be parsed." ::= { ospfTraps 8 } ospfVirtIfRxBadPacket NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfPacketType } STATUS current DESCRIPTION "An ospfVirtIfRxBadPacket trap signifies that an OSPF packet has been received on a virtual interface that cannot be parsed." ::= { ospfTraps 9 } ospfTxRetransmit NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfIpAddress, ospfAddressLessIf, ospfNbrRtrId, -- Destination ospfPacketType, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId } STATUS current DESCRIPTION "An ospfTxRetransmit trap signifies than an OSPF packet has been retransmitted on a non-virtual interface. All packets that may be retransmitted are associated with an LSDB entry. The LS type, LS ID, and Router ID are used to identify the LSDB entry." ::= { ospfTraps 10 } Galecki, et al. Standards Track [Page 104] RFC 4750 OSPFv2 MIB December 2006 ospfVirtIfTxRetransmit NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfPacketType, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId } STATUS current DESCRIPTION "An ospfVirtIfTxRetransmit trap signifies than an OSPF packet has been retransmitted on a virtual interface. All packets that may be retransmitted are associated with an LSDB entry. The LS type, LS ID, and Router ID are used to identify the LSDB entry." ::= { ospfTraps 11 } ospfOriginateLsa NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfLsdbAreaId, -- 0.0.0.0 for AS Externals ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId } STATUS current DESCRIPTION "An ospfOriginateLsa trap signifies that a new LSA has been originated by this router. This trap should not be invoked for simple refreshes of LSAs (which happens every 30 minutes), but instead will only be invoked when an LSA is (re)originated due to a topology change. Additionally, this trap does not include LSAs that are being flushed because they have reached MaxAge." ::= { ospfTraps 12 } ospfMaxAgeLsa NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfLsdbAreaId, -- 0.0.0.0 for AS Externals ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId } STATUS current DESCRIPTION Galecki, et al. Standards Track [Page 105] RFC 4750 OSPFv2 MIB December 2006 "An ospfMaxAgeLsa trap signifies that one of the LSAs in the router's link state database has aged to MaxAge." ::= { ospfTraps 13 } ospfLsdbOverflow NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfExtLsdbLimit } STATUS current DESCRIPTION "An ospfLsdbOverflow trap signifies that the number of LSAs in the router's link state database has exceeded ospfExtLsdbLimit." ::= { ospfTraps 14 } ospfLsdbApproachingOverflow NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfExtLsdbLimit } STATUS current DESCRIPTION "An ospfLsdbApproachingOverflow trap signifies that the number of LSAs in the router's link state database has exceeded ninety percent of ospfExtLsdbLimit." ::= { ospfTraps 15 } ospfIfStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfIpAddress, ospfAddressLessIf, ospfIfState -- The new state } STATUS current DESCRIPTION "An ospfIfStateChange trap signifies that there has been a change in the state of a non-virtual OSPF interface. This trap should be generated when the interface state regresses (e.g., goes from Dr to Down) or progresses to a terminal state (i.e., Point-to-Point, DR Other, Dr, or Backup)." ::= { ospfTraps 16 } ospfNssaTranslatorStatusChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap Galecki, et al. Standards Track [Page 106] RFC 4750 OSPFv2 MIB December 2006 ospfAreaId, ospfAreaNssaTranslatorState -- The current translation -- status } STATUS current DESCRIPTION "An ospfNssaTranslatorStatusChange trap indicates that there has been a change in the router's ability to translate OSPF type-7 LSAs into OSPF type-5 LSAs. This trap should be generated when the translator status transitions from or to any defined status on a per-area basis." ::= { ospfTraps 17 } ospfRestartStatusChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfRestartStatus, ospfRestartInterval, ospfRestartExitReason } STATUS current DESCRIPTION "An ospfRestartStatusChange trap signifies that there has been a change in the graceful restart state for the router. This trap should be generated when the router restart status changes." ::= { ospfTraps 18 } ospfNbrRestartHelperStatusChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, ospfNbrRestartHelperExitReason } STATUS current DESCRIPTION "An ospfNbrRestartHelperStatusChange trap signifies that there has been a change in the graceful restart helper state for the neighbor. This trap should be generated when the neighbor restart helper status transitions for a neighbor." ::= { ospfTraps 19 } ospfVirtNbrRestartHelperStatusChange NOTIFICATION-TYPE Galecki, et al. Standards Track [Page 107] RFC 4750 OSPFv2 MIB December 2006 OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtNbrArea, ospfVirtNbrRtrId, ospfVirtNbrRestartHelperStatus, ospfVirtNbrRestartHelperAge, ospfVirtNbrRestartHelperExitReason } STATUS current DESCRIPTION "An ospfVirtNbrRestartHelperStatusChange trap signifies that there has been a change in the graceful restart helper state for the virtual neighbor. This trap should be generated when the virtual neighbor restart helper status transitions for a virtual neighbor." ::= { ospfTraps 20 } -- conformance information ospfTrapConformance OBJECT IDENTIFIER ::= { ospfTrap 3 } ospfTrapGroups OBJECT IDENTIFIER ::= { ospfTrapConformance 1 } ospfTrapCompliances OBJECT IDENTIFIER ::= { ospfTrapConformance 2 } -- compliance statements ospfTrapCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement." MODULE -- this module MANDATORY-GROUPS { ospfTrapControlGroup } GROUP ospfTrapControlGroup DESCRIPTION "This group is optional but recommended for all OSPF systems." ::= { ospfTrapCompliances 1 } ospfTrapCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement." MODULE -- this module MANDATORY-GROUPS { ospfTrapControlGroup, ospfTrapEventGroup } OBJECT ospfConfigErrorType MIN-ACCESS accessible-for-notify DESCRIPTION "This object is only required to be supplied within notifications." Galecki, et al. Standards Track [Page 108] RFC 4750 OSPFv2 MIB December 2006 OBJECT ospfPacketType MIN-ACCESS accessible-for-notify DESCRIPTION "This object is only required to be supplied within notifications." OBJECT ospfPacketSrc MIN-ACCESS accessible-for-notify DESCRIPTION "This object is only required to be supplied within notifications." ::= { ospfTrapCompliances 2 } -- units of conformance ospfTrapControlGroup OBJECT-GROUP OBJECTS { ospfSetTrap, ospfConfigErrorType, ospfPacketType, ospfPacketSrc } STATUS current DESCRIPTION "These objects are required to control traps from OSPF systems." ::= { ospfTrapGroups 1 } ospfTrapEventGroup NOTIFICATION-GROUP NOTIFICATIONS { ospfVirtIfStateChange, ospfNbrStateChange, ospfVirtNbrStateChange, ospfIfConfigError, ospfVirtIfConfigError, ospfIfAuthFailure, ospfVirtIfAuthFailure, ospfIfRxBadPacket, ospfVirtIfRxBadPacket, ospfTxRetransmit, ospfVirtIfTxRetransmit, ospfOriginateLsa, ospfMaxAgeLsa, ospfLsdbOverflow, ospfLsdbApproachingOverflow, ospfIfStateChange, ospfNssaTranslatorStatusChange, ospfRestartStatusChange, ospfNbrRestartHelperStatusChange, ospfVirtNbrRestartHelperStatusChange } Galecki, et al. Standards Track [Page 109] RFC 4750 OSPFv2 MIB December 2006 STATUS current DESCRIPTION "A grouping of OSPF trap events, as specified in NOTIFICATION-TYPE constructs." ::= { ospfTrapGroups 2 } END 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. It is recommended that attention be specifically given to implementing the MAX-ACCESS clause in a number of objects, including ospfIfAuthKey, ospfIfAuthType, ospfVirtIfAuthKey, and ospfVirtIfAuthType in scenarios that DO NOT use SNMPv3 strong security (i.e., authentication and encryption). Extreme caution must be used to minimize the risk of cascading security vulnerabilities when SNMPv3 strong security is not used. When SNMPv3 strong security is not used, these objects should have access of read-only, not read-create. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View- based Access Control Model RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Galecki, et al. Standards Track [Page 110] RFC 4750 OSPFv2 MIB December 2006 7. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- ospf { mib-2 14 } 8. Acknowledgements This document was produced by the OSPF Working Group and is based on the MIB for OSPF version 2 by Rob Coltun and Fred Baker [RFC1850]. The editors would like to acknowledge John Moy, Rob Coltun, Randall Atkinson, David T. Perkins, Ken Chapman, Brian Field, Acee Lindem, Vishwas Manral, Roy Jose, Don Goodspeed, Vivek Dubey, Keith McCloghrie, Bill Fenner, and Dan Romascanu for their constructive comments. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 9.2 Informative References [RFC1224] Steinberg, L., "Techniques for managing asynchronously generated alerts", RFC 1224, May 1991. [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. Galecki, et al. Standards Track [Page 111] RFC 4750 OSPFv2 MIB December 2006 [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [RFC1850] Baker, F. and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. Galecki, et al. Standards Track [Page 112] RFC 4750 OSPFv2 MIB December 2006 Appendix A. TOS Support For backward compatibility with previous versions of the OSPF MIB specification, TOS-specific information has been retained in this document, though the TOS routing option has been deleted from OSPF [RFC2328]. Appendix B. Changes from RFC 1850 This section documents the differences between this memo and RFC 1850. Appendix B.1. General Group Changes Added object ospfRFC1583Compatibility to indicate support with "RFC 1583 Compatibility" [RFC1583]. This object has DEFVAL of "enabled". Added object ospfReferenceBandwidth to allow configuration of a reference bandwidth for calculation of default interface metrics. Added objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge, ospfRestartStrictLsaChecking, and ospfRestartExitReason to support graceful restart. Added objects ospfStubRouterSupport and ospfStubRouteAdvertisement to support stub routers. Added object ospfDiscontinuityTime in order for a management entity to detect counter discontinuity events. Appendix B.2. OSPF NSSA Enhancement Support Added new objects to OspfAreaTable including the following: -ospfAreaNssaTranslatorRole to indicate the configured NSSA translation role. -ospfAreaNssaTranslatorState to indicate the current NSSA translation role. -ospfAreaNssaTranslatorStabilityInterval to indicate time to continue to perform at current translation status. -ospfAreaNssaTranslatorEvents to indicate the number of times OSPF translation state has changed. Added new object ospfAreaAggregateExtRouteTag to ospfAreaAggregateTable. Galecki, et al. Standards Track [Page 113] RFC 4750 OSPFv2 MIB December 2006 Added new object ospfNssaTranslatorStatusChange to ospfTraps in OSPF-TRAP-MIB DEFINITIONS. Added ospfAreaId to IMPORTS in OSPF-TRAP-MIB DEFINITIONS to support ospfNssaTranslatorStatusChange. Added ospfAreaExtNssaTranslatorStatus to IMPORTS in OSPF-TRAP-MIB DEFINITIONS to support ospfNssaTranslatorStatusChange. Modified the DESCRIPTION clause of the ospfAreaSummary object in the ospfAreaTable to indicate support for NSSA. Modified the DESCRIPTION clause of the ospfImportAsExtern object in the ospfAreaTable for clarity. Appendix B.3. Opaque LSA Support Added object ospfOpaqueLsaSupport to ospfGeneralGroup to indicate support of OSPF Opaque LSAs. Created ospfLocalLsdbTable, for link-local (type-9) LSA support. This table is indexed by the following: -ospflocalLsdbIpAddress -ospfLocalLsdbAddressLessIf -ospfLocalLsdbType -ospfLocalLsdbLsid -ospfLocalLsdbRouterId ospfLocalLsdbTable contains the following (columnar) objects: -ospfLocalLsdbSequence, to indicate LSA instance -ospfLocalLsdbAge -ospfLocalLsdbChecksum -ospfLocalLsdbAdvertisement, containing the entire LSA Created ospfVirLocalLsdbTable, for link-local (type-9) LSA support on virtual links. This table is indexed by the following: -ospfVirtLocalLsdbTransitArea Galecki, et al. Standards Track [Page 114] RFC 4750 OSPFv2 MIB December 2006 -ospfVirtLocalLsdbNeighbor, to indicate the router ID of the virtual neighbor -ospfVirLocalLsdbType -ospfVirLocalLsdbLsid -ospfVirLocalLsdbRouterId ospfVirLocalLsdbTable contains the following (columnar) objects: -ospfVirLocalLsdbSequence, to indicate LSA instance -ospfVirLocalLsdbAge -ospfVirLocalLsdbChecksum -ospfVirLocalLsdbAdvertisement, containing the entire LSA Added objects to ospfIfTable to support link-local (type-9) LSAs, including the following: -ospfIfLsaCount -ospfIfLsaCksumSum, to indicate the sum of the type-9 link state advertisement checksums on this interface Added objects to ospfVirIfTable, to support link-local (type-9) LSAs on virtual links, including the following: -ospfVirIfLsaCount -ospfVirIfLsaCksumSum, to indicate the sum of the type-9 link state advertisement checksums on this link To support area scope (type-10) LSAs, the enumeration areaOpaqueLink (10) was added to ospfLsdbType in the ospfLsdbTable. Created ospfAsLsdbTable, for AS-scope LSA support. This table is indexed by the following: -ospfAsLsdbType -ospfAsLsdbLsid -ospfAsLsdbRouterId ospfAsLsdbTable contains the following (columnar) objects: Galecki, et al. Standards Track [Page 115] RFC 4750 OSPFv2 MIB December 2006 -ospfAsLsdbSequence, to indicate LSA instance -ospfAsLsdbAge -ospfAsLsdbChecksum -ospfAsLsdbAdvertisement, containing the entire LSA Appendix B.4. Graceful Restart Support Added objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge, ospfRestartStrictLsaChecking, and ospfRestartExitReason to general group. Added objects ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, and ospfNbrRestartHelperExitReason to OspfNbrTable. Added objects ospfVirtNbrRestartHelperStatus, ospfVirtNbrRestartHelperAge, and ospfVirtNbrRestartHelperExitReason to OspfVirtNbrTable. Appendix B.5. OSPF Compliances New compliance statements were added for new and for obsoleted conformance groups. These statements include the following: -ospfCompliance2 -ospfComplianceObsolete New conformance groups were created to support new objects added to the group. These groups include the following: -ospfBasicGroup2 -ospfAreaGroup2 -ospfIfGroup2 -ospfVirtIfGroup2 -ospfNbrGroup2 -ospfVirtNbrGroup2 -ospfAreaAggregateGroup2 Added completely new conformance groups, including the following: Galecki, et al. Standards Track [Page 116] RFC 4750 OSPFv2 MIB December 2006 -ospfLocalLsdbGroup, which specifies support for link-local (type-9) LSAs -ospfVirtLocalLsdbGroup, which specifies support for link-local (type-9) LSAs on virtual links -ospfObsoleteGroup, for obsolete objects and SMI compatibility Appendix B.6. OSPF Authentication and Security As there has been significant concern in the community regarding cascading security vulnerabilities, the following changes have been incorporated: -Modified the DESCRIPTION clause of ospfIfAuthKey due to security concerns and to increase clarity -Modified the DESCRIPTION clause of ospfVirtIfAuthKey due to security concerns and to increase clarity -Modified the DESCRIPTION clause of ospfIfAuthType due to security concerns and to increase clarity -Modified the DESCRIPTION clause of ospfVirtIfType due to security concerns and to increase clarity -Modified the OSPF MIB MODULE DESCRIPTION due to security concerns and to include a reference to the Security Considerations section in this document that will transcend compilation -Modified the Security Considerations section to provide detail Appendix B.7. OSPF Trap MIB Added ospfTrapEventGroup. Added importation of NOTIFICATION-GROUP. Changed the STATUS of the ospfTrapCompliance MODULE-COMPLIANCE construct to obsolete. Added ospfTrapCompliance2 MODULE-COMPLIANCE construct, which replaces ospfTrapCompliance. OspfTrapCompliance includes an updated MANDATORY-GROUPS clause and new MIN-ACCESS specifications. Added mtuMismatch enumeration to ospfConfigErrorType object in ospfTrapControl to imply MTU mismatch trap generation. in ospfIfConfigError. Galecki, et al. Standards Track [Page 117] RFC 4750 OSPFv2 MIB December 2006 Added noError enumeration to ospfConfigErrorType object for situations when traps are requested but none have been sent. Updated the DESCRIPTION clause accordingly. Added nullPacket enumeration to ospfPacketType object for situations when traps are requested but none have been sent. Updated the DESCRIPTION clause accordingly. Updated the DESCRIPTION clause of ospfPacketSrc for situations when traps are requested, but none have been sent. Added NOTIFICATION-TYPE for ospfRestartStatusChange. Added NOTIFICATION-TYPE for ospfNbrRestartHelperStatusChange. Added NOTIFICATION-TYPE for ospfVirtNbrRestartHelperStatusChange. Appendix B.8. Miscellaneous Various sections have been moved or modified for clarity. Most of these changes are semantic in nature and include, but are not limited to the following: -The OSPF overview section's format was revised. Unneeded information was removed. Removed information includes OSPF TOS default values. -The trap overview section's format and working were revised. Unneeded information was removed. -Modified the DESCRIPTION clause of "Status" "TEXTUAL-CONVENTION" for clarity. -The Updates section was moved from the overview to its own section. -Updated "REFERENCE" clauses in all objects, as needed. -Modified the SEQUENCE of the OspfIfTable to reflect the true order of the objects in the table. -Modified the DESCRIPTION clause of all row management objects for clarity. Added ospfHostCfgAreaID to object to Host table with read-create access. Deprecated ospfHostAreaID. Galecki, et al. Standards Track [Page 118] RFC 4750 OSPFv2 MIB December 2006 Added importation of InterfaceIndexOrZero from IF-MIB. This TEXTUAL-CONVENTION will replace the InterfaceIndex TEXTUAL- CONVENTION. Changed the SYNTAX clause of ospfNbrAddressLessIndex to use the semantically identical InterfaceIndexOrZero TEXTUAL-CONVENTION, as permitted by the SMI. Changed the STATUS clause of the TEXTUAL-CONVENTION InterfaceIndex to obsolete and modified the DESCRIPTION accordingly. Changed the SYNTAX clause of ospfAddressLessIf to use the semantically identical InterfaceIndexOrZero TEXTUAL-CONVENTION, as permitted by the SMI. Changed the SYNTAX clause of ospfIfMetricAddressLessIf to use the semantically identical InterfaceIndexOrZero TEXTUAL-CONVENTION, as permitted by the SMI. Changed importation of mib-2 from RFC1213-MIB to SNMPv2-SMI Added Intellectual Property Rights section. Updated REVISION DESCRIPTION clauses with description of major MIB modifications. Moved all relevant MIB comments to objects' DESCRIPTION clauses. Added reasoning for object deprecation. Added persistence information for read-write, read-create objects. Described conditions when columns can be modified in RowStatus managed rows as required by RFC 2579. Defined OspfAuthenticationType TC and modified authentication type objects to use the new type. Made index objects of new tables not accessible. Added the UNITS clause to several objects. Added ospfIfDesignatedRouterId and ospfIfBackupDesignatedRouterId to the OspfIfEntry. Added the area LSA counter table. Added IANA Considerations section. Galecki, et al. Standards Track [Page 119] RFC 4750 OSPFv2 MIB December 2006 Authors' Addresses Dan Joyal (Editor) Nortel, Inc. 600 Technology Park Drive Billerica, MA 01821 USA EMail: djoyal@nortel.com Piotr Galecki (Editor) Airvana, Inc. 19 Alpha Road Chelmsford, MA 01824 USA EMail: pgalecki@airvana.com Spencer Giacalone (Editor) CSFB Eleven Madison Ave New York, NY 10010-3629 USA EMail: spencer.giacalone@gmail.com Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA EMail: fred@cisco.com Rob Coltun Touch Acoustra 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA EMail: undisclosed Galecki, et al. Standards Track [Page 120] RFC 4750 OSPFv2 MIB December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Galecki, et al. Standards Track [Page 121] snmp-mibs-downloader-1.1/mibrfcs/rfc4780.txt0000644000000000000000000047131411402176072015577 0ustar Network Working Group K. Lingle Request for Comments: 4780 Cisco Systems, Inc. Category: Standards Track J-F. Mule CableLabs J. Maeng D. Walker April 2007 Management Information Base for the Session Initiation Protocol (SIP) 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. Lingle, et al. Standards Track [Page 1] RFC 4780 SIP MIB Modules April 2007 Table of Contents 1. Introduction ....................................................2 2. Conventions .....................................................2 3. The Internet-Standard Management Framework ......................2 4. Overview ........................................................3 5. Structure of the SIP MIB ........................................3 5.1. Textual Conventions ........................................6 5.2. Relationship to the Network Services MIB ...................6 5.3. IMPORTed MIB Modules and REFERENCE Clauses ................10 6. Accommodating SIP Extension Methods ............................11 7. Definitions ....................................................12 7.1. SIP Textual Conventions ...................................12 7.2. SIP Common MIB Module .....................................15 7.3. SIP User Agent MIB Module .................................55 7.4. SIP Server MIB Module (Proxy, Redirect, and Registrar Servers) ........................................59 8. IANA Considerations ............................................77 9. Security Considerations ........................................78 10. Contributor Acknowledgments ...................................80 11. References ....................................................80 11.1. Normative References .....................................80 11.2. Informative References ...................................81 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. The managed objects defined in this document are intended to provide basic SIP protocol management for SIP entities. The management of application-specific or service-specific SIP configuration is out of scope. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Lingle, et al. Standards Track [Page 2] RFC 4780 SIP MIB Modules April 2007 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a set of MIB modules that are compliant to the SMIv2, which is described in STD 58, comprised of RFC 2578 [RFC2578], RFC 2579 [RFC2579], and RFC 2580 [RFC2580]. 4. Overview SIP [RFC3261] is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. This MIB provides some managed objects for SIP entities defined in RFC 3261 [RFC3261] - User Agents (UA), and Proxy, Redirect, and Registrar servers. It is intended to provide management of the basic SIP entities. It provides for monitoring of status and protocol statistics, as well as for configuration of SIP entities. 5. Structure of the SIP MIB Four MIB modules are specified: SIP-COMMON-MIB, SIP-SERVER-MIB, SIP- UA-MIB, and SIP-TC-MIB. SIP-COMMON-MIB contains common MIB objects used in all the SIP entities. SIP-SERVER-MIB contains objects specific to Proxy, Redirect, and Registrar servers. SIP-UA-MIB includes objects specific to User Agents. SIP-TC-MIB defines the textual conventions used throughout the MIB modules. The MIB modules contain the following groups of objects: SIP-COMMON-MIB: Management objects common to all the SIP entities o sipCommonMIBObjects * sipCommonCfgBase: This object group defines configuration objects common to all SIP entities, including the SIP protocol version, the type of SIP entity (UA, proxy, redirect, registrar servers), the operational and administrative status, the SIP organization name, the maximum number of SIP transactions an entity can manage, etc. * sipCommonCfgTimer: This object group defines timer configuration objects applicable to SIP user agent and stateful SIP proxy entities. Lingle, et al. Standards Track [Page 3] RFC 4780 SIP MIB Modules April 2007 * sipCommonSummaryStats: This object group defines a table containing the summary statistics objects applicable to all SIP entities, including the total number of all SIP requests and responses in/out and the total number of transactions. * sipCommonMethodStats: This object group defines a table containing the SIP method statistics objects applicable to all SIP entities, including the number of outbound and inbound requests on a per method basis. Retransmissions, where appropriate, are also included in these statistics. * sipCommonStatusCode: This object group defines a table indicating the number of SIP responses (in and out) that the SIP entity has been requested to monitor on a per-method basis (100, 200, 302, etc.). * sipCommonStatsTrans: This object group defines a table containing a gauge reflecting the number of transactions currently awaiting definitive responses by the managed SIP entity. * sipCommonStatsRetry: This object group defines statistic objects indicating the number of retransmissions sent on a per-method basis. * sipCommonOtherStats: This object group defines additional statistics objects including the number of SIP requests received with unsupported URIs, the number of requests received with unsupported SIP methods, and the number of discarded messages. * sipCommonNotifObjects: This object group defines objects accessible only via a notification (MAX ACCESS clause of accessible-for-notify): they are related to the SNMP notifications defined in this MIB module. The SIP-COMMON-MIB also contains notifications, including: o sipCommonStatusCodeNotif: indicates that a specific status code has been sent or received by the system. o sipCommonStatusCodeThreshExceededNotif: indicates that a specific status code has been sent or received by the system frequently enough to exceed the configured threshold. Lingle, et al. Standards Track [Page 4] RFC 4780 SIP MIB Modules April 2007 SIP-SERVER-MIB: Groups of objects for SIP Proxy, Redirect, and Registrar servers o sipServerMIBObjects * sipServerCfg: This object group defines common server configuration objects including the SIP server host address. * sipServerProxyCfg: This object group defines configuration objects for SIP Proxy Servers including the proxy mode of operation (stateless, stateful, call stateful), the proxy authentication method(s), realm, etc. * sipServerProxyStats: This object group defines a table containing the statistics objects applicable to SIP Proxy Servers. It includes the number of occurrences of unsupported options being specified in received Proxy-Require headers. * sipServerRegCfg: This object group defines common configuration objects for SIP Registrar servers, including the ability to accept third-party registrations, such as the maximum registration expiry that may be requested by user agents, the maximum number of users the registrar can support, the number of currently registered users, per contact registration information, etc. * sipServerRegStats: This object group contains summary statistics objects for SIP Registrar servers. Precisely, it contains the number of REGISTER requests that have been accepted or rejected. SIP-UA-MIB: Group of objects for SIP User Agents o sipUAMIBObjects * sipUACfgServer: This object group specifies SIP server configuration objects applicable to SIP user agents including the Internet address of the SIP Server the UA uses to register, proxy, or redirect calls. To conform with this specification, an SNMP agent MUST implement the SIP-TC-MIB module, plus the SIP-COMMON-MIB module and one of the SIP entity-type-specific MIB modules (SIP-SERVER-MIB or SIP-UA-MIB) as applicable for each instance of a SIP entity being managed. If a device has more than one SIP entity or multiple instances of the same entity type, it MUST implement multiple SIP modules. Section 5.2 describes handling of multiple instances in detail. Lingle, et al. Standards Track [Page 5] RFC 4780 SIP MIB Modules April 2007 5.1. Textual Conventions The data types SipTCTransportProtocol, SipTCEntityRole, SipTCOptionTagHeaders, and SipTCMethodName are defined in the SIP- TC-MIB module and used as Textual Conventions in this document. 5.2. Relationship to the Network Services MIB In the design of the SIP MIB, the authors considered the following requirement: the SIP MIB must allow a single system with a single SNMP agent to support multiple instances of various SIP MIB modules. This requirement is met by using the framework provided by the Network Services Monitoring MIB, NETWORK-SERVICES-MIB, RFC 2788 [RFC2788]. A device implementing the SIP MIB MUST support the NETWORK-SERVICES- MIB and, at a minimum, MUST support the index and name objects (applIndex and applName) in the application table (applTable). In order to allow each instance of a SIP entity to be managed as a separate network service application, a naming convention SHOULD be used to make the application name unique. For example, if a system is running 2 SIP UAs that need to be managed as 2 separate SIP entities, by convention, the application names used in the Network Services Monitoring MIB application table should be "sip_ua1" and "sip_ua2". This convention allows each instance to have its own row in the application table (applTable). It is therefore RECOMMENDED that the following application name conventions be adopted: o for a SIP Proxy entity, the applName value SHOULD be equal to a character string starting with "sip_proxy" followed by a unique application instance identifier, for example, "sip_proxy1", "sip_proxy17". o for a SIP Registrar entity, the applName value SHOULD be equal to a character string starting with "sip_registrar" followed by a unique application instance identifier, for example, "sip_registrar1", "sip_registrar2". o for a SIP User Agent entity, the applName value SHOULD be equal to a character string starting with "sip_ua" followed by a unique application instance identifier, for example, "sip_ua1", "sip_ua2". Lingle, et al. Standards Track [Page 6] RFC 4780 SIP MIB Modules April 2007 o for any combination of Proxy, Registrar, or Redirect Server being managed as a single aggregate entity, the applName value for the combined server entity SHOULD reflect the appropriate combination followed by a unique application instance identifier. In order to facilitate consistent agent behavior and management application expectations, the following order of names is RECOMMENDED: * if Proxy exists, list first. * if Proxy and Redirect exists, list Redirect second. * if Registrar exists, always list last. For example "sip_proxy1", "sip_proxy_registrar1", "sip_proxy_redirect5", "sip_proxy_redirect_registrar2", or "sip_registrar1". o Note: the value of the network service application index (applIndex) may be different from the instance identifier used in the system (the applIndex is dynamically created and is the value assigned by the SNMP agent at the creation of the table entry, whereas the value of the instance identifier to be used in the application name is provided as part of the application name applName by the system administrator or configuration files of the SIP entity). This note is illustrated in the first example provided below. Finally, the SNMP agent MAY support any combination of the other attributes in applTable. If supported, the following objects SHOULD have values populated as follows: o applVersion: version of the SIP application. o applUptime: the value of applUptime MUST be identical to the value of sipCommonCfgServiceStartTime defined in the SIP-COMMON-MIB module. o applOperStatus: the value of applOperStatus SHOULD reflect the operational status of sipCommonCfgServiceOperStatus, at least by means of a mapping. o applLastChange: the value of applLastChange MUST be identical to the value of sipCommonCfgServiceLastChange defined in the SIP- COMMON module. A number of other objects are defined as part of the applTable. They are not included for the sake of brevity and due to the fact that they do not enhance the concept being presented. Lingle, et al. Standards Track [Page 7] RFC 4780 SIP MIB Modules April 2007 Example 1: The tables below illustrate how a system acting as both Proxy and Registrar server might be configured to maintain separate SIP- COMMON-MIB instances. The NETWORK-SERVICES-MIB applTable might be populated as follows: +-----------+-------------------+----------------------+ | applIndex | applName | applDescription | +-----------+-------------------+----------------------+ | 1 | "sip_proxy10" | "ACME SIP Proxy" | | 2 | "sip_registrar17" | "ACME SIP Registrar" | +-----------+-------------------+----------------------+ The SIP-COMMON-MIB sipCommonCfgTable would have two rows: one for the proxy (applIndex=1) and one for the registrar (applIndex=2). The SIP-SERVER-MIB tables would, however, only be populated with one row indexed by applIndex=1 and applIndex=2, respectively, if the server provides either proxy or registrar. The SIP-COMMON-MIB sipCommonCfgTable might be populated as: +---------+------------------------+--------------------------+-----+ |applIndex| sipCommonCfgProtocol | sipCommonCfgServiceOper | ... | | | Version | Status | | +---------+------------------------+--------------------------+-----+ | 1 | "SIP/2.0" | up(1) | | | 2 | "SIP/2.0" | restarting(4) | | +---------+------------------------+--------------------------+-----+ while the sipServerProxyCfgTable in SIP-SERVER-MIB might be populated as: +-----------+-------------------------------+-----+ | applIndex | sipServerCfgProxyStatefulness | ... | +-----------+-------------------------------+-----+ | 1 | stateless(1) | | +-----------+-------------------------------+-----+ Lingle, et al. Standards Track [Page 8] RFC 4780 SIP MIB Modules April 2007 and the sipServerRegUserTable in SIP-SERVER-MIB might be populated as: +-----------+-----------------------+---------------------+-----+ | applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... | +-----------+-----------------------+---------------------+-----+ | 2 | 1 | bob@example.com | | | 2 | 2 | alice@example.com | | | 2 | 3 | jim@example.com | | | 2 | 4 | john@example.com | | +-----------+-----------------------+---------------------+-----+ Example 2: This example illustrates how to represent a system acting as both Proxy and Registrar server, where the two entities share a single instance of SIP-COMMON-MIB. The NETWORK-SERVICES-MIB applTable might be populated as follows: +-----------+------------------------+------------------------------+ | applIndex | applName | applDescription | +-----------+------------------------+------------------------------+ | 1 | "sip_proxy_registrar1" | "ACME SIP Proxy and | | | | Registrar" | +-----------+------------------------+------------------------------+ The SIP-COMMON-MIB sipCommonCfgTable would have only one row to cover both the proxy and the registrar. The SIP-COMMON-MIB sipCommonCfgTable might be populated as: +----------+---------------------------+-----------------------------+ |applIndex |sipCommonCfgProtocolVersion|sipCommonCfgServiceOperStatus| +----------+---------------------------+-----------------------------+ | 1 | "SIP/2.0" | up(1) | +----------+---------------------------+-----------------------------+ Lingle, et al. Standards Track [Page 9] RFC 4780 SIP MIB Modules April 2007 while the sipServerRegUserTable in SIP-SERVER-MIB might be populated as: +-----------+-----------------------+---------------------+-----+ | applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... | +-----------+-----------------------+---------------------+-----+ | 2 | 1 | bob@example.com | | | 2 | 2 | alice@example.com | | | 2 | 3 | kevin@example.com | | | 2 | 4 | jf@example.com | | +-----------+-----------------------+---------------------+-----+ The NETWORK-SERVICES-MIB assocTable is not considered a requirement for SIP systems. It is not a mandatory group for compliance with the NETWORK-SERVICES-MIB module. The relationship between the value of applOperStatus and sipCommonCfgServiceOperStatus is as follows: +-------------------------------+---------------+-------------------+ | sipCommonCfgServiceOperStatus | -- | applOperStatus | | | corresponds | | | | to --> | | +-------------------------------+---------------+-------------------+ | up | --> | up | | down | --> | down | | congested | --> | congested | | restarting | --> | restarting | | quiescing | --> | quiescing | | testing | --> | up | | unknown | --> | --indeterminate-- | +-------------------------------+---------------+-------------------+ If the sipOperStatus is 'unknown', there is no corresponding value of applOperStatus. Therefore, the last known value of applOperStatus SHOULD be maintained until the sipOperStatus transitions to a value that can be mapped appropriately. 5.3. IMPORTed MIB Modules and REFERENCE Clauses The SIP MIB modules defined in this document IMPORT definitions normatively from the following MIB modules, beyond [RFC2578], [RFC2579], and [RFC2580]: INET-ADDRESS-MIB [RFC4001], NETWORK- SERVICES-MIB [RFC2788], SNMP-FRAMEWORK-MIB [RFC3411]. This MIB module also includes REFERENCE clauses that normatively refer to SIP [RFC3261] and INET-ADDRESS-MIB [RFC4001]. Lingle, et al. Standards Track [Page 10] RFC 4780 SIP MIB Modules April 2007 Finally, this MIB module makes informative references to several RFCs in some of the examples described in the DESCRIPTION clauses, including Reliability of Provisional Responses in SIP [RFC3262] and SIP over SCTP [RFC4168]. 6. Accommodating SIP Extension Methods The core set of SIP methods is defined in RFC 3261 [RFC3261]. Other IETF RFCs define additional methods. In the future, additional methods may be defined. In order to avoid having to update the SIP- COMMON-MIB module to accommodate these extension methods, we use a method identifier name (SipTCMethodName TEXTUAL-CONVENTION) to represent all SIP methods registered with IANA. For example, the sipCommonMethodSupportedTable is the main table for listing all of the SIP methods supported by a system, including the SIP methods defined in RFC 3261 [RFC3261] and other SIP methods registered with IANA. The table is informational in nature and populated by the system. Entries cannot be added or deleted by an SNMP manager. The SIP specification (RFC 3261 [RFC3261], Section 27.4) establishes the sub-registries for SIP Methods and Response Codes under http://www.iana.org/assignments/sip-parameters. This document uses the existing sub-registry for the names of registered SIP methods. For example, in the sipCommonMethodSupportedTable of SIP-COMMON-MIB, the sipCommonMethodSupportedName values can be represented as follows: +------------------------------+ | sipCommonMethodSupportedName | +------------------------------+ | "ACK" | | "BYE" | | "CANCEL" | | "INVITE" | | "OPTIONS" | +------------------------------+ Lingle, et al. Standards Track [Page 11] RFC 4780 SIP MIB Modules April 2007 7. Definitions 7.1. SIP Textual Conventions SIP-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC; -- RFC 2579 sipTC MODULE-IDENTITY LAST-UPDATED "200704200000Z" ORGANIZATION "IETF Session Initiation Protocol Working Group" CONTACT-INFO "SIP WG email: sip@ietf.org Co-editor Kevin Lingle Cisco Systems, Inc. postal: 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA email: klingle@cisco.com phone: +1 919 476 2029 Co-editor Joon Maeng email: jmaeng@austin.rr.com Co-editor Jean-Francois Mule CableLabs postal: 858 Coal Creek Circle Louisville, CO 80027 USA email: jf.mule@cablelabs.com phone: +1 303 661 9100 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) MIB TEXTUAL-CONVENTION module used by other SIP-related MIB Modules. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4780; see the RFC itself for Lingle, et al. Standards Track [Page 12] RFC 4780 SIP MIB Modules April 2007 full legal notices." REVISION "200704200000Z" DESCRIPTION "Initial version of the IETF SIP-TC-MIB module. This version published as part of RFC 4780." ::= { mib-2 148 } -- -- Textual Conventions -- SipTCTransportProtocol ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that selected transport protocol is in some way dependent on the context of the object using this convention. If a bit has value 0, then that transport protocol is not selected. Combinations of bits can be set when multiple transport protocols are selected. bit 0: a protocol other than those defined here bit 1: User Datagram Protocol bit 2: Transmission Control Protocol bit 3: Stream Control Transmission Protocol bit 4: Transport Layer Security Protocol over TCP bit 5: Transport Layer Security Protocol over SCTP " REFERENCE "RFC 3261, Section 18 and RFC 4168" SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), -- RFC4168 tlsTcp(4), tlsSctp(5) -- RFC 4168 } SipTCEntityRole ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention defines the role of a SIP entity. Examples of SIP entities are proxies, user agents, redirect servers, registrars, or combinations of the above. User Agent (UA): A logical entity that can act as both a user agent client and user agent server. Lingle, et al. Standards Track [Page 13] RFC 4780 SIP MIB Modules April 2007 User Agent Client (UAC): A logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. User Agent Server (UAS): A logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity 'closer' to the targeted user. Proxies are also useful for enforcing policy. A proxy interprets and, if necessary, rewrites specific parts of a request message before forwarding it. Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs. Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles." REFERENCE "RFC 3261, Section 6" SYNTAX BITS { other(0), userAgent(1), proxyServer(2), redirectServer(3), registrarServer(4) } SipTCOptionTagHeaders ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention defines the header fields that use the option Lingle, et al. Standards Track [Page 14] RFC 4780 SIP MIB Modules April 2007 tags per Section 19.2 of RFC 3261. These tags are used in Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37), and Unsupported (Section 20.40) header fields." REFERENCE "RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40" SYNTAX BITS { require(0), -- Require header proxyRequire(1), -- Proxy-Require header supported(2), -- Supported header unsupported(3) -- Unsupported header } SipTCMethodName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TEXTUAL-CONVENTION is a string that uniquely identifies a SIP method. The scope of uniqueness is the context of all defined SIP methods. Experimental support of extension methods is acceptable and expected. Extension methods are those defined in Internet-Draft documents but not yet allocated and officially sanctioned by IANA. To support experimental extension methods, any object using this TEXTUAL-CONVENTION as syntax MAY return/accept a method identifier value other than those sanctioned by IANA. That system MUST ensure no collisions with officially assigned method names." REFERENCE "RFC 3261, Section 27.4" SYNTAX OCTET STRING (SIZE (1..100)) END 7.2. SIP Common MIB Module SIP-COMMON-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Gauge32, TimeTicks, Unsigned32, Lingle, et al. Standards Track [Page 15] RFC 4780 SIP MIB Modules April 2007 mib-2 FROM SNMPv2-SMI -- RFC 2578 RowStatus, TimeStamp, TruthValue FROM SNMPv2-TC -- RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 SipTCTransportProtocol, SipTCMethodName, SipTCEntityRole, SipTCOptionTagHeaders FROM SIP-TC-MIB -- RFC 4780 applIndex FROM NETWORK-SERVICES-MIB -- RFC 2788 InetPortNumber FROM INET-ADDRESS-MIB; -- RFC 4001 sipCommonMIB MODULE-IDENTITY LAST-UPDATED "200704200000Z" ORGANIZATION "IETF Session Initiation Protocol Working Group" CONTACT-INFO "SIP WG email: sip@ietf.org Co-editor Kevin Lingle Cisco Systems, Inc. postal: 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA email: klingle@cisco.com phone: +1 919 476 2029 Co-editor Joon Maeng email: jmaeng@austin.rr.com Co-editor Jean-Francois Mule CableLabs Lingle, et al. Standards Track [Page 16] RFC 4780 SIP MIB Modules April 2007 postal: 858 Coal Creek Circle Louisville, CO 80027 USA email: jf.mule@cablelabs.com phone: +1 303 661 9100 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) Common MIB module. This module defines objects that may be common to all SIP entities. SIP is an application-layer signaling protocol for creating, modifying and terminating multimedia sessions with one or more participants. These sessions include Internet multimedia conferences and Internet telephone calls. SIP is defined in RFC 3261 (June 2002). This MIB is defined for managing objects that are common to SIP User Agents (UAs), Proxy, Redirect, and Registrar servers. Objects specific to each of these entities MAY be managed using entity specific MIBs defined in other modules. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4780; see the RFC itself for full legal notices." REVISION "200704200000Z" DESCRIPTION "Initial version of the IETF SIP-COMMON-MIB module. This version published as part of RFC 4780." ::= { mib-2 149 } -- Top-Level Components of this MIB. sipCommonMIBNotifications OBJECT IDENTIFIER ::= { sipCommonMIB 0 } sipCommonMIBObjects OBJECT IDENTIFIER ::= { sipCommonMIB 1 } sipCommonMIBConformance OBJECT IDENTIFIER ::= { sipCommonMIB 2 } -- -- This MIB contains objects that are common to all SIP entities. -- -- Common basic configuration sipCommonCfgBase OBJECT IDENTIFIER ::= { sipCommonMIBObjects 1 } -- Protocol timer configuration sipCommonCfgTimer OBJECT IDENTIFIER ::= { sipCommonMIBObjects 2 } -- SIP message summary statistics Lingle, et al. Standards Track [Page 17] RFC 4780 SIP MIB Modules April 2007 sipCommonSummaryStats OBJECT IDENTIFIER ::= { sipCommonMIBObjects 3 } -- Per method statistics sipCommonMethodStats OBJECT IDENTIFIER ::= { sipCommonMIBObjects 4 } -- Per Status code or status code class statistics sipCommonStatusCode OBJECT IDENTIFIER ::= { sipCommonMIBObjects 5 } -- Transaction statistics sipCommonStatsTrans OBJECT IDENTIFIER ::= { sipCommonMIBObjects 6 } -- Method retry statistics sipCommonStatsRetry OBJECT IDENTIFIER ::= { sipCommonMIBObjects 7 } -- Other statistics sipCommonOtherStats OBJECT IDENTIFIER ::= { sipCommonMIBObjects 8 } -- Accessible-for-notify objects sipCommonNotifObjects OBJECT IDENTIFIER ::= { sipCommonMIBObjects 9 } -- -- Common Configuration Objects -- sipCommonCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the common configuration objects applicable to all SIP entities." ::= { sipCommonCfgBase 1 } sipCommonCfgEntry OBJECT-TYPE SYNTAX SipCommonCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common configuration. Each row represents objects for a particular SIP entity instance present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipCommonCfgTable 1 } SipCommonCfgEntry ::= SEQUENCE { Lingle, et al. Standards Track [Page 18] RFC 4780 SIP MIB Modules April 2007 sipCommonCfgProtocolVersion SnmpAdminString, sipCommonCfgServiceOperStatus INTEGER, sipCommonCfgServiceStartTime TimeTicks, sipCommonCfgServiceLastChange TimeTicks, sipCommonCfgOrganization SnmpAdminString, sipCommonCfgMaxTransactions Unsigned32, sipCommonCfgServiceNotifEnable BITS, sipCommonCfgEntityType SipTCEntityRole } sipCommonCfgProtocolVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object will reflect the version of SIP supported by this SIP entity. It will follow the same format as SIP version information contained in the SIP messages generated by this SIP entity. For example, entities supporting SIP version 2 will return 'SIP/2.0' as dictated by the standard." REFERENCE "RFC 3261, Section 7.1" ::= { sipCommonCfgEntry 1 } sipCommonCfgServiceOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), up(2), down(3), congested(4), restarting(5), quiescing(6), testing(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the current operational state of the SIP application. unknown : The operational status cannot be determined for some reason. up : The application is operating normally and is processing (receiving and possibly issuing) SIP requests and responses. down : The application is currently unable to process SIP messages. congested : The application is operational but no additional Lingle, et al. Standards Track [Page 19] RFC 4780 SIP MIB Modules April 2007 inbound transactions can be accommodated at the moment. restarting : The application is currently unavailable, but it is in the process of restarting and will presumably, soon be able to process SIP messages. quiescing : The application is currently operational but has been administratively put into quiescence mode. Additional inbound transactions MAY be rejected. testing : The application is currently in test mode and MAY not be able to process SIP messages. The operational status values defined for this object are not based on any specific information contained in the SIP standard." ::= { sipCommonCfgEntry 2 } sipCommonCfgServiceStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the SIP entity was last started. If started prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { sipCommonCfgEntry 3 } sipCommonCfgServiceLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the SIP entity entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { sipCommonCfgEntry 4 } sipCommonCfgOrganization OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the organization name that the SIP entity inserts into Organization headers of SIP messages processed by this system. If the string is empty, no Organization header is to be generated." Lingle, et al. Standards Track [Page 20] RFC 4780 SIP MIB Modules April 2007 REFERENCE "RFC 3261, Section 20.25" ::= { sipCommonCfgEntry 5 } sipCommonCfgMaxTransactions OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum number of simultaneous transactions per second that the SIP entity can manage. In general, the value of this object SHOULD reflect a level of transaction processing per second that is considered high enough to impact the system's CPU and/or memory resources to the point of deteriorating SIP call processing but not high enough to cause catastrophic system failure." ::= { sipCommonCfgEntry 6 } sipCommonCfgServiceNotifEnable OBJECT-TYPE SYNTAX BITS { sipCommonServiceColdStart(0), sipCommonServiceWarmStart(1), sipCommonServiceStatusChanged(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies which SIP service related notifications are enabled. Each bit represents a specific notification. If a bit has a value 1, the associated notification is enabled and will be generated by the SIP entity at the appropriate time. Support for these notifications is OPTIONAL: either none or all notification values are supported. If an implementation does not support this object, it should return a 'noSuchObject' exception to an SNMP GET operation. If notifications are supported, this object's default value SHOULD reflect sipCommonServiceColdStart and sipCommonServiceWarmStart enabled and sipCommonServiceStatusChanged disabled. This object value SHOULD persist across reboots." DEFVAL { { sipCommonServiceColdStart, sipCommonServiceWarmStart } } ::= { sipCommonCfgEntry 7 } sipCommonCfgEntityType OBJECT-TYPE SYNTAX SipTCEntityRole MAX-ACCESS read-only Lingle, et al. Standards Track [Page 21] RFC 4780 SIP MIB Modules April 2007 STATUS current DESCRIPTION "This object identifies the list of SIP entities to which this row is related. It is defined as a bit map. Each bit represents a type of SIP entity. If a bit has value 1, the SIP entity represented by this row plays the role of this entity type. If a bit has value 0, the SIP entity represented by this row does not act as this entity type. Combinations of bits can be set when the SIP entity plays multiple SIP roles." ::= { sipCommonCfgEntry 8 } -- -- Support for multiple ports -- sipCommonPortTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the list of ports that each SIP entity in this system is allowed to use. These ports can be advertised using the Contact header in a REGISTER request or response." ::= { sipCommonCfgBase 2 } sipCommonPortEntry OBJECT-TYPE SYNTAX SipCommonPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specification of a particular port. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipCommonPort } ::= { sipCommonPortTable 1 } SipCommonPortEntry ::= SEQUENCE { sipCommonPort InetPortNumber, sipCommonPortTransportRcv SipTCTransportProtocol } sipCommonPort OBJECT-TYPE SYNTAX InetPortNumber (1..65535) MAX-ACCESS not-accessible STATUS current Lingle, et al. Standards Track [Page 22] RFC 4780 SIP MIB Modules April 2007 DESCRIPTION "This object reflects a particular port that can be used by the SIP application." ::= { sipCommonPortEntry 1 } sipCommonPortTransportRcv OBJECT-TYPE SYNTAX SipTCTransportProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "This object will specify the transport protocol the SIP entity will use to receive SIP messages. This object is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that transport protocol is currently being used. If a bit has value 0, then that transport protocol is currently not being used." ::= { sipCommonPortEntry 2 } -- -- Support for SIP option tags (SIP extensions). -- SIP extensions MAY be supported or required by SIP entities. -- sipCommonOptionTagTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonOptionTagEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of the SIP option tags (SIP extensions) that are either required, supported, or unsupported by the SIP entity. These option tags are used in the Require, Proxy-Require, Supported, and Unsupported header fields. Example: If a user agent client supports, and requires the server to support, reliability of provisional responses (RFC 3262), this table contains a row with the option tag string '100rel' in sipCommonOptionTag and the OCTET STRING value of '1010 0000' or '0xA0' in sipCommonOptionTagHeaderField. If a server does not support the required feature (indicated in a Require header to a UAS, or in a Proxy-Require to a Proxy Server), the server returns a 420 Bad Extension listing the feature in an Unsupported header. Normally, the list of such features supported by an entity is static (i.e., will not change over time)." Lingle, et al. Standards Track [Page 23] RFC 4780 SIP MIB Modules April 2007 REFERENCE "RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40" ::= { sipCommonCfgBase 3 } sipCommonOptionTagEntry OBJECT-TYPE SYNTAX SipCommonOptionTagEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular SIP option tag (extension) supported or unsupported by the SIP entity, and which may be supported or required by a peer. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipCommonOptionTagIndex } ::= { sipCommonOptionTagTable 1 } SipCommonOptionTagEntry ::= SEQUENCE { sipCommonOptionTagIndex Unsigned32, sipCommonOptionTag SnmpAdminString, sipCommonOptionTagHeaderField SipTCOptionTagHeaders } sipCommonOptionTagIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table." ::= { sipCommonOptionTagEntry 1 } sipCommonOptionTag OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the SIP option tag. The option tag names are registered with IANA and available at http://www.iana.org." REFERENCE "RFC 3261, Section 27.1" ::= { sipCommonOptionTagEntry 2 } sipCommonOptionTagHeaderField OBJECT-TYPE SYNTAX SipTCOptionTagHeaders MAX-ACCESS read-only STATUS current Lingle, et al. Standards Track [Page 24] RFC 4780 SIP MIB Modules April 2007 DESCRIPTION "This object indicates whether the SIP option tag is supported (Supported header), unsupported (Unsupported header), or required (Require or Proxy-Require header) by the SIP entity. A SIP option tag may be both supported and required." ::= { sipCommonOptionTagEntry 3 } -- -- Supported SIP Methods -- sipCommonMethodSupportedTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonMethodSupportedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of methods supported by each SIP entity in this system (see the standard set of SIP methods in Section 7.1 of RFC 3261). Any additional methods that may be incorporated into the SIP protocol can be represented by this table without any requirement to update this MIB module. The table is informational in nature and conveys capabilities of the managed system to the SNMP Manager. From a protocol point of view, the list of methods advertised by the SIP entity in the Allow header (Section 20.5 of RFC 3261) MUST be consistent with the methods reflected in this table." ::= { sipCommonCfgBase 4 } sipCommonMethodSupportedEntry OBJECT-TYPE SYNTAX SipCommonMethodSupportedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular method supported by the SIP entity. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipCommonMethodSupportedIndex } ::= { sipCommonMethodSupportedTable 1 } SipCommonMethodSupportedEntry ::= SEQUENCE { sipCommonMethodSupportedIndex Unsigned32, sipCommonMethodSupportedName SipTCMethodName } Lingle, et al. Standards Track [Page 25] RFC 4780 SIP MIB Modules April 2007 sipCommonMethodSupportedIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table and reflects an assigned number used to identify a specific SIP method. This identifier is suitable for referencing the associated method throughout this and other MIBs supported by this managed system." ::= { sipCommonMethodSupportedEntry 1 } sipCommonMethodSupportedName OBJECT-TYPE SYNTAX SipTCMethodName MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the supported method's name. The method name MUST be all upper case (e.g., 'INVITE')." ::= { sipCommonMethodSupportedEntry 2 } -- -- SIP Timer Configuration -- sipCommonCfgTimerTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonCfgTimerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains timer configuration objects applicable to SIP user agent and SIP stateful Proxy Server entities." ::= { sipCommonCfgTimer 1 } sipCommonCfgTimerEntry OBJECT-TYPE SYNTAX SipCommonCfgTimerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of timer configuration. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The objects in this table entry SHOULD be non-volatile and their value SHOULD be kept at reboot." Lingle, et al. Standards Track [Page 26] RFC 4780 SIP MIB Modules April 2007 INDEX { applIndex } ::= { sipCommonCfgTimerTable 1 } SipCommonCfgTimerEntry ::= SEQUENCE { sipCommonCfgTimerA Unsigned32, sipCommonCfgTimerB Unsigned32, sipCommonCfgTimerC Unsigned32, sipCommonCfgTimerD Unsigned32, sipCommonCfgTimerE Unsigned32, sipCommonCfgTimerF Unsigned32, sipCommonCfgTimerG Unsigned32, sipCommonCfgTimerH Unsigned32, sipCommonCfgTimerI Unsigned32, sipCommonCfgTimerJ Unsigned32, sipCommonCfgTimerK Unsigned32, sipCommonCfgTimerT1 Unsigned32, sipCommonCfgTimerT2 Unsigned32, sipCommonCfgTimerT4 Unsigned32 } sipCommonCfgTimerA OBJECT-TYPE SYNTAX Unsigned32 (100..1000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the initial value for the retransmit timer for the INVITE method. The retransmit timer doubles after each retransmission, ensuring an exponential backoff in network traffic. This object represents the initial time a SIP entity will wait to receive a provisional response to an INVITE before resending the INVITE request." REFERENCE "RFC 3261, Section 17.1.1.2" DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 1 } sipCommonCfgTimerB OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP entity will wait to receive a final response to an INVITE. The timer is started upon transmission of the initial INVITE request." REFERENCE "RFC 3261, Section 17.1.1.2" Lingle, et al. Standards Track [Page 27] RFC 4780 SIP MIB Modules April 2007 DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 2 } sipCommonCfgTimerC OBJECT-TYPE SYNTAX Unsigned32 (180000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP Proxy Server will wait to receive a provisional response to an INVITE. The Timer C MUST be set for each client transaction when an INVITE request is proxied." REFERENCE "RFC 3261, Section 16.6" DEFVAL { 180000 } ::= { sipCommonCfgTimerEntry 3 } sipCommonCfgTimerD OBJECT-TYPE SYNTAX Unsigned32 (0..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the amount of time that the server transaction can remain in the 'Completed' state when unreliable transports are used. The default value MUST be equal to or greater than 32000 for UDP transport, and its value MUST be 0 for TCP/SCTP transport." REFERENCE "RFC 3261, Section 17.1.1.2" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 4 } sipCommonCfgTimerE OBJECT-TYPE SYNTAX Unsigned32 (100..1000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the initial value for the retransmit timer for a non-INVITE method while in 'Trying' state. The retransmit timer doubles after each retransmission until it reaches T2 to ensure an exponential backoff in network traffic. This object represents the initial time a SIP entity will wait to receive a provisional response to the request before resending the non-INVITE request." REFERENCE Lingle, et al. Standards Track [Page 28] RFC 4780 SIP MIB Modules April 2007 "RFC 3261, Section 17.1.2.2" DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 5 } sipCommonCfgTimerF OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP entity will wait to receive a final response to a non-INVITE request. The timer is started upon transmission of the initial request." REFERENCE "RFC 3261, Section 17.1.2.2" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 6 } sipCommonCfgTimerG OBJECT-TYPE SYNTAX Unsigned32 (0..1000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the initial value for the retransmit timer for final responses to INVITE requests. If timer G fires, the response is passed to the transport layer again for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case, it is reset with the value of T2. The default value MUST be T1 for UDP transport, and its value MUST be 0 for reliable transport like TCP/SCTP." REFERENCE "RFC 3261, Section 17.2.1" DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 7 } sipCommonCfgTimerH OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a server will wait to receive an ACK before it abandons retransmitting the response. Lingle, et al. Standards Track [Page 29] RFC 4780 SIP MIB Modules April 2007 The timer is started upon entering the 'Completed' state." REFERENCE "RFC 3261, Section 17.2.1" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 8 } sipCommonCfgTimerI OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP entity will wait to receive additional ACK message retransmissions. The timer is started upon entering the 'Confirmed' state. The default value MUST be T4 for UDP transport and its value MUST be 0 for reliable transport like TCP/SCTP." REFERENCE "RFC 3261, Section 17.2.1" DEFVAL { 5000 } ::= { sipCommonCfgTimerEntry 9 } sipCommonCfgTimerJ OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP server will wait to receive retransmissions of non-INVITE requests. The timer is started upon entering the 'Completed' state for non-INVITE transactions. When timer J fires, the server MUST transition to the 'Terminated' state." REFERENCE "RFC 3261, Section 17.2.2" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 10 } sipCommonCfgTimerK OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP client will wait to receive retransmissions of responses to non-INVITE requests. The timer is started upon entering the 'Completed' state for Lingle, et al. Standards Track [Page 30] RFC 4780 SIP MIB Modules April 2007 non-INVITE transactions. When timer K fires, the server MUST transition to the 'Terminated' state. The default value MUST be T4 for UDP transport, and its value MUST be 0 for reliable transport like TCP/SCTP." REFERENCE "RFC 3261, Section 17.1.2.2" DEFVAL { 5000 } ::= { sipCommonCfgTimerEntry 11 } sipCommonCfgTimerT1 OBJECT-TYPE SYNTAX Unsigned32 (200..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the T1 timer for a SIP entity. T1 is an estimate of the round-trip time (RTT) between the client and server transactions." REFERENCE "RFC 3261, Section 17" DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 12 } sipCommonCfgTimerT2 OBJECT-TYPE SYNTAX Unsigned32 (200..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the T2 timer for a SIP entity. T2 is the maximum retransmit interval for non-INVITE requests and INVITE responses. It's used in various parts of the protocol to reset other Timer* objects to this value." REFERENCE "RFC 3261, Section 17" DEFVAL { 4000 } ::= { sipCommonCfgTimerEntry 13 } sipCommonCfgTimerT4 OBJECT-TYPE SYNTAX Unsigned32 (200..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the T4 timer for a SIP entity. T4 is the maximum duration a message will remain in the network. It represents the amount of time the network will take to clear messages between client and server transactions. It's used in Lingle, et al. Standards Track [Page 31] RFC 4780 SIP MIB Modules April 2007 various parts of the protocol to reset other Timer* objects to this value." REFERENCE "RFC 3261, Section 17" DEFVAL { 5000 } ::= { sipCommonCfgTimerEntry 14 } -- -- Common Statistics Objects -- -- -- Summary Statistics -- sipCommonSummaryStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonSummaryStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the summary statistics objects applicable to all SIP entities. Each row represents those objects for a particular SIP entity present in this system." ::= { sipCommonSummaryStats 1 } sipCommonSummaryStatsEntry OBJECT-TYPE SYNTAX SipCommonSummaryStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of summary statistics. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipCommonSummaryStatsTable 1 } SipCommonSummaryStatsEntry ::= SEQUENCE { sipCommonSummaryInRequests Counter32, sipCommonSummaryOutRequests Counter32, sipCommonSummaryInResponses Counter32, sipCommonSummaryOutResponses Counter32, sipCommonSummaryTotalTransactions Counter32, sipCommonSummaryDisconTime TimeStamp } sipCommonSummaryInRequests OBJECT-TYPE Lingle, et al. Standards Track [Page 32] RFC 4780 SIP MIB Modules April 2007 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the total number of SIP request messages received by the SIP entity, including retransmissions. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonSummaryDisconTime object in the same row." ::= { sipCommonSummaryStatsEntry 1 } sipCommonSummaryOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of SIP request messages sent out (originated and relayed) by the SIP entity. Where a particular message is sent more than once, for example as a retransmission or as a result of forking, each transmission is counted separately. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonSummaryDisconTime object in the same row." ::= { sipCommonSummaryStatsEntry 2 } sipCommonSummaryInResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of SIP response messages received by the SIP entity, including retransmissions. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonSummaryDisconTime object in the same row." ::= { sipCommonSummaryStatsEntry 3 } sipCommonSummaryOutResponses OBJECT-TYPE Lingle, et al. Standards Track [Page 33] RFC 4780 SIP MIB Modules April 2007 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of SIP response messages sent (originated and relayed) by the SIP entity including retransmissions. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonSummaryDisconTime object in the same row." ::= { sipCommonSummaryStatsEntry 4 } sipCommonSummaryTotalTransactions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number of transactions that are in progress and transactions that have reached the 'Terminated' state. It is not applicable to stateless SIP Proxy Servers. A SIP transaction occurs between a client and a server, and comprises all messages from the first request sent from the client to the server, up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also include an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. The branch ID parameter in the Via header field values serves as a transaction identifier. A transaction is identified by the CSeq sequence number within a single call leg. The ACK request has the same CSeq number as the corresponding INVITE request, but comprises a transaction of its own. In the case of a forked request, each branch counts as a single transaction. For a transaction stateless Proxy Server, this counter is always 0. Lingle, et al. Standards Track [Page 34] RFC 4780 SIP MIB Modules April 2007 Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonSummaryDisconTime object in the same row." ::= { sipCommonSummaryStatsEntry 5 } sipCommonSummaryDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for the summary statistics objects in this row last experienced a discontinuity." ::= { sipCommonSummaryStatsEntry 6 } -- -- SIP Method Statistics -- Total counts for each SIP method. -- sipCommonMethodStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonMethodStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the method statistics objects for SIP entities. Each row represents those objects for a particular SIP entity present in this system." ::= { sipCommonMethodStats 1 } sipCommonMethodStatsEntry OBJECT-TYPE SYNTAX SipCommonMethodStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of per entity method statistics. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipCommonMethodStatsName } ::= { sipCommonMethodStatsTable 1 } SipCommonMethodStatsEntry ::= SEQUENCE { sipCommonMethodStatsName SipTCMethodName, sipCommonMethodStatsOutbounds Counter32, Lingle, et al. Standards Track [Page 35] RFC 4780 SIP MIB Modules April 2007 sipCommonMethodStatsInbounds Counter32, sipCommonMethodStatsDisconTime TimeStamp } sipCommonMethodStatsName OBJECT-TYPE SYNTAX SipTCMethodName MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies the SIP method related to the objects in a particular row." ::= { sipCommonMethodStatsEntry 1 } sipCommonMethodStatsOutbounds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of requests sent by the SIP entity, excluding retransmissions. Retransmissions are counted separately and are not reflected in this counter. A Management Station can detect discontinuities in this counter by monitoring the sipCommonMethodStatsDisconTime object in the same row." REFERENCE "RFC 3261, Section 7.1" ::= { sipCommonMethodStatsEntry 2 } sipCommonMethodStatsInbounds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of requests received by the SIP entity. Retransmissions are counted separately and are not reflected in this counter. A Management Station can detect discontinuities in this counter by monitoring the sipCommonMethodStatsDisconTime object in the same row." REFERENCE "RFC 3261, Section 7.1" ::= { sipCommonMethodStatsEntry 3 } sipCommonMethodStatsDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Lingle, et al. Standards Track [Page 36] RFC 4780 SIP MIB Modules April 2007 "The value of the sysUpTime object when the counters for the method statistics objects in this row last experienced a discontinuity." ::= { sipCommonMethodStatsEntry 4 } -- -- Support for specific status codes -- sipCommonStatusCodeTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonStatusCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the list of SIP status codes that each SIP entity in this system has been requested to monitor. It is the mechanism by which specific status codes are monitored. Entries created in this table must not persist across reboots." ::= { sipCommonStatusCode 1 } sipCommonStatusCodeEntry OBJECT-TYPE SYNTAX SipCommonStatusCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This row contains information on a particular SIP status code that the SIP entity has been requested to monitor. Entries created in this table must not persist across reboots. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipCommonStatusCodeMethod, sipCommonStatusCodeValue } ::= { sipCommonStatusCodeTable 1 } SipCommonStatusCodeEntry ::= SEQUENCE { sipCommonStatusCodeMethod SipTCMethodName, sipCommonStatusCodeValue Unsigned32, sipCommonStatusCodeIns Counter32, sipCommonStatusCodeOuts Counter32, sipCommonStatusCodeRowStatus RowStatus, sipCommonStatusCodeDisconTime TimeStamp } sipCommonStatusCodeMethod OBJECT-TYPE SYNTAX SipTCMethodName MAX-ACCESS not-accessible Lingle, et al. Standards Track [Page 37] RFC 4780 SIP MIB Modules April 2007 STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table." ::= { sipCommonStatusCodeEntry 1 } sipCommonStatusCodeValue OBJECT-TYPE SYNTAX Unsigned32 (100..999) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains a SIP status code value that the SIP entity has been requested to monitor. All of the other information in the row is related to this value." ::= { sipCommonStatusCodeEntry 2 } sipCommonStatusCodeIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of response messages received by the SIP entity with the status code value contained in the sipCommonStatusCodeValue column. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service, or when the monitoring of the status code is temporarily disabled. A Management Station can detect discontinuities in this counter by monitoring the sipCommonStatusCodeDisconTime object in the same row." ::= { sipCommonStatusCodeEntry 3 } sipCommonStatusCodeOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of response messages sent by the SIP entity with the status code value contained in the sipCommonStatusCodeValue column. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service, or when the monitoring of the Status code is temporarily disabled. A Management Station can detect discontinuities in this counter by monitoring the sipCommonStatusCodeDisconTime object in the same row." Lingle, et al. Standards Track [Page 38] RFC 4780 SIP MIB Modules April 2007 ::= { sipCommonStatusCodeEntry 4 } sipCommonStatusCodeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row augmentation in sipCommonStatusCodeNotifTable will be governed by the value of this RowStatus. The values 'createAndGo' and 'destroy' are the only valid values allowed for this object. If a row exists, it will reflect a status of 'active' when queried." ::= { sipCommonStatusCodeEntry 5 } sipCommonStatusCodeDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for the status code statistics objects in this row last experienced a discontinuity." ::= { sipCommonStatusCodeEntry 6 } -- -- Support for specific status code notifications -- sipCommonStatusCodeNotifTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonStatusCodeNotifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects to control notifications related to particular status codes that each SIP entity in this system has been requested to monitor. There is an entry in this table corresponding to each entry in sipCommonStatusCodeTable. Therefore, this table augments sipCommonStatusCodeTable and utilizes the same index methodology. The objects in this table are not included directly in the sipCommonStatusCodeTable simply to keep the status code notification control objects separate from the actual status code statistics." ::= { sipCommonStatusCode 2 } Lingle, et al. Standards Track [Page 39] RFC 4780 SIP MIB Modules April 2007 sipCommonStatusCodeNotifEntry OBJECT-TYPE SYNTAX SipCommonStatusCodeNotifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This row contains information controlling notifications for a particular SIP status code that the SIP entity has been requested to monitor." AUGMENTS { sipCommonStatusCodeEntry } ::= { sipCommonStatusCodeNotifTable 1 } SipCommonStatusCodeNotifEntry ::= SEQUENCE { sipCommonStatusCodeNotifSend TruthValue, sipCommonStatusCodeNotifEmitMode INTEGER, sipCommonStatusCodeNotifThresh Unsigned32, sipCommonStatusCodeNotifInterval Unsigned32 } sipCommonStatusCodeNotifSend OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls whether a sipCommonStatusCodeNotif is emitted when the status code value specified by sipCommonStatusCodeValue is sent or received. If the value of this object is 'true', then a notification is sent. If it is 'false', no notification is sent. Note well that a notification MAY be emitted for every message sent or received that contains the particular status code. Depending on the status code involved, this can cause a significant number of notification emissions that could be detrimental to network performance. Managers are forewarned to be prudent in the use of this object to enable notifications. Look to sipCommonStatusCodeNotifEmitMode for alternative controls for sipCommonStatusCodeNotif emissions." DEFVAL { false } ::= { sipCommonStatusCodeNotifEntry 1 } sipCommonStatusCodeNotifEmitMode OBJECT-TYPE SYNTAX INTEGER { normal(1), oneShot(2), triggered(3) -- read-only } MAX-ACCESS read-write STATUS current DESCRIPTION Lingle, et al. Standards Track [Page 40] RFC 4780 SIP MIB Modules April 2007 "The object sipCommonStatusCodeNotifSend MUST be set to 'true' for the values of this object to have any effect. It is RECOMMENDED that the desired emit mode be established by this object prior to setting sipCommonStatusCodeNotifSend to 'true'. This object and the sipCommonStatusCodeNotifSend object can obviously be set independently, but their respective values will have a dependency on each other and the resulting notifications. This object specifies the mode for emissions of sipCommonStatusCodeNotif notifications. normal : sipCommonStatusCodeNotif notifications will be emitted by the system for each SIP response message sent or received that contains the desired status code. oneShot : Only one sipCommonStatusCodeNotif notification will be emitted. It will be the next SIP response message sent or received that contains the desired status code. No more notifications are emitted until this object is set to 'oneShot' again or set to 'normal'. This option is provided as a means of quelling the potential promiscuous behavior that can be associated with the sipCommonStatusCodeNotif. triggered : This value is only readable and cannot be set. It reflects that the 'oneShot' case has occurred, and indicates that the mode needs to be reset to get further notifications. The mode is reset by setting this object to 'oneShot' or 'normal'." DEFVAL { oneShot } ::= { sipCommonStatusCodeNotifEntry 2 } sipCommonStatusCodeNotifThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the number of response messages sent or received by this system that are considered excessive. Based on crossing that threshold, a sipCommonStatusCodeThreshExceededInNotif notification or a sipCommonStatusCodeThreshExceededOutNotif will be sent. The sipCommonStatusCodeThreshExceededInNotif and Lingle, et al. Standards Track [Page 41] RFC 4780 SIP MIB Modules April 2007 sipCommonStatusCodeThreshExceededOutNotif notifications can be used as an early warning mechanism in lieu of using sipCommonStatusCodeNotif. Note that the configuration applied by this object will be applied equally to inbound and outbound response messages." DEFVAL { 500 } ::= { sipCommonStatusCodeNotifEntry 3 } sipCommonStatusCodeNotifInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the time interval over which, if sipCommonStatusCodeThresh is exceeded with respect to sent or received messages, a sipCommonStatusCodeThreshExceededInNotif or sipCommonStatusCodeThreshExceededOutNotif notification will be sent. Note that the configuration applied by this object will be applied equally to inbound and outbound response messages." DEFVAL { 60 } ::= { sipCommonStatusCodeNotifEntry 4 } -- -- Transaction Statistics -- sipCommonTransCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonTransCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the transactions currently awaiting definitive responses by each SIP entity in this system. This table does not apply to transaction stateless Proxy Servers." ::= { sipCommonStatsTrans 1 } sipCommonTransCurrentEntry OBJECT-TYPE SYNTAX SipCommonTransCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular SIP entity's current transactions. Lingle, et al. Standards Track [Page 42] RFC 4780 SIP MIB Modules April 2007 Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipCommonTransCurrentTable 1 } SipCommonTransCurrentEntry ::= SEQUENCE { sipCommonTransCurrentactions Gauge32 } sipCommonTransCurrentactions OBJECT-TYPE SYNTAX Gauge32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of transactions awaiting definitive (non-1xx) response. In the case of a forked request, each branch counts as a single transaction corresponding to the entity identified by applIndex." ::= { sipCommonTransCurrentEntry 1 } -- -- SIP Retry Statistics -- -- This group contains various statistics objects about -- retransmission counts. -- sipCommonStatsRetryTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonStatsRetryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains retry statistics objects applicable to each SIP entity in this system." ::= { sipCommonStatsRetry 1 } sipCommonStatsRetryEntry OBJECT-TYPE SYNTAX SipCommonStatsRetryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of retry statistics. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." Lingle, et al. Standards Track [Page 43] RFC 4780 SIP MIB Modules April 2007 INDEX { applIndex, sipCommonStatsRetryMethod } ::= { sipCommonStatsRetryTable 1 } SipCommonStatsRetryEntry ::= SEQUENCE { sipCommonStatsRetryMethod SipTCMethodName, sipCommonStatsRetries Counter32, sipCommonStatsRetryFinalResponses Counter32, sipCommonStatsRetryNonFinalResponses Counter32, sipCommonStatsRetryDisconTime TimeStamp } sipCommonStatsRetryMethod OBJECT-TYPE SYNTAX SipTCMethodName MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies the SIP method related to the objects in a row." ::= { sipCommonStatsRetryEntry 1 } sipCommonStatsRetries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of request retransmissions that have been sent by the SIP entity. Note that there could be multiple retransmissions per request. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonStatsRetryDisconTime object in the same row." ::= { sipCommonStatsRetryEntry 2 } sipCommonStatsRetryFinalResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of Final Response retries that have been sent by the SIP entity. Note that there could be multiple retransmissions per request. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by Lingle, et al. Standards Track [Page 44] RFC 4780 SIP MIB Modules April 2007 monitoring the sipCommonStatsRetryDisconTime object in the same row." ::= { sipCommonStatsRetryEntry 3 } sipCommonStatsRetryNonFinalResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of non-Final Response retries that have been sent by the SIP entity. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonStatsRetryDisconTime object in the same row." ::= { sipCommonStatsRetryEntry 4 } sipCommonStatsRetryDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for the retry statistics objects in this row last experienced a discontinuity." ::= { sipCommonStatsRetryEntry 5 } -- -- Other Common Statistics -- sipCommonOtherStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonOtherStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains other common statistics supported by each SIP entity in this system." ::= { sipCommonOtherStats 1 } sipCommonOtherStatsEntry OBJECT-TYPE SYNTAX SipCommonOtherStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular SIP entity's other common statistics. Lingle, et al. Standards Track [Page 45] RFC 4780 SIP MIB Modules April 2007 Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipCommonOtherStatsTable 1 } SipCommonOtherStatsEntry ::= SEQUENCE { sipCommonOtherStatsNumUnsupportedUris Counter32, sipCommonOtherStatsNumUnsupportedMethods Counter32, sipCommonOtherStatsOtherwiseDiscardedMsgs Counter32, sipCommonOtherStatsDisconTime TimeStamp } sipCommonOtherStatsNumUnsupportedUris OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of RequestURIs received with an unsupported scheme. A server normally responds to such requests with a 400 Bad Request status code. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonOtherStatsDisconTime object in the same row." ::= { sipCommonOtherStatsEntry 1 } sipCommonOtherStatsNumUnsupportedMethods OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SIP requests received with unsupported methods. A server normally responds to such requests with a 501 (Not Implemented) or 405 (Method Not Allowed). Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonOtherStatsDisconTime object in the same row." ::= { sipCommonOtherStatsEntry 2 } sipCommonOtherStatsOtherwiseDiscardedMsgs OBJECT-TYPE SYNTAX Counter32 Lingle, et al. Standards Track [Page 46] RFC 4780 SIP MIB Modules April 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SIP messages received that, for any number of reasons, was discarded without a response. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipCommonOtherStatsDisconTime object in the same row." ::= { sipCommonOtherStatsEntry 3 } sipCommonOtherStatsDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for the statistics objects in this row last experienced a discontinuity." ::= { sipCommonOtherStatsEntry 4 } -- -- Notification related objects -- -- -- Status code related notification objects. -- sipCommonStatusCodeNotifTo OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the value of the To header in the message containing the status code that caused the notification. The header name will be part of this object value. For example, 'To: Watson '." ::= { sipCommonNotifObjects 1 } sipCommonStatusCodeNotifFrom OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the value of the From header in the message containing the status code that caused the Lingle, et al. Standards Track [Page 47] RFC 4780 SIP MIB Modules April 2007 notification. The header name will be part of this object value. For example, 'From: Watson '." ::= { sipCommonNotifObjects 2 } sipCommonStatusCodeNotifCallId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the value of the Call-ID in the message containing the status code that caused the notification. The header name will be part of this object value. For example, 'Call-ID: 5551212@example.com'." ::= { sipCommonNotifObjects 3 } sipCommonStatusCodeNotifCSeq OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the CSeq value in the message containing the status code that caused the notification. The header name will be part of this object value. For example, 'CSeq: 1722 INVITE'." ::= { sipCommonNotifObjects 4 } -- -- General notification related objects. -- sipCommonNotifApplIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the applIndex as described in RFC 2788. This object is created in order to allow a variable binding containing a value of applIndex in a notification." ::= { sipCommonNotifObjects 5 } sipCommonNotifSequenceNumber OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains a sequence number for each notification generated by this SIP entity. Each notification SHOULD have a unique sequence number. A network manager can use this information to determine whether notifications from a Lingle, et al. Standards Track [Page 48] RFC 4780 SIP MIB Modules April 2007 particular SIP entity have been missed. The value of this object MUST start at 1 and increase by 1 with each generated notification. If a system restarts, the sequence number MAY start again from 1." ::= { sipCommonNotifObjects 6 } -- -- Notifications -- sipCommonStatusCodeNotif NOTIFICATION-TYPE OBJECTS { sipCommonNotifSequenceNumber, sipCommonNotifApplIndex, sipCommonStatusCodeNotifTo, sipCommonStatusCodeNotifFrom, sipCommonStatusCodeNotifCallId, sipCommonStatusCodeNotifCSeq, sipCommonStatusCodeIns, sipCommonStatusCodeOuts } STATUS current DESCRIPTION "Signifies that a specific status code has been sent or received by the system." ::= { sipCommonMIBNotifications 1 } sipCommonStatusCodeThreshExceededInNotif NOTIFICATION-TYPE OBJECTS { sipCommonNotifSequenceNumber, sipCommonNotifApplIndex, sipCommonStatusCodeIns } STATUS current DESCRIPTION "Signifies that a specific status code was found to have been received by the system frequently enough to exceed the configured threshold. This notification can be used as an early warning mechanism in lieu of using sipCommonStatusCodeNotif." ::= { sipCommonMIBNotifications 2 } sipCommonStatusCodeThreshExceededOutNotif NOTIFICATION-TYPE OBJECTS { sipCommonNotifSequenceNumber, sipCommonNotifApplIndex, sipCommonStatusCodeOuts } STATUS current Lingle, et al. Standards Track [Page 49] RFC 4780 SIP MIB Modules April 2007 DESCRIPTION "Signifies that a specific status code was found to have been sent by the system enough to exceed the configured threshold. This notification can be used as an early warning mechanism in lieu of using sipCommonStatusCodeNotif." ::= { sipCommonMIBNotifications 3 } sipCommonServiceColdStart NOTIFICATION-TYPE OBJECTS { sipCommonNotifSequenceNumber, sipCommonNotifApplIndex, sipCommonCfgServiceStartTime } STATUS current DESCRIPTION "Signifies that the SIP service has reinitialized itself or started for the first time. This SHOULD result from a hard 'down' to 'up' administrative status change. The configuration or behavior of the service MAY be altered." ::= { sipCommonMIBNotifications 4 } sipCommonServiceWarmStart NOTIFICATION-TYPE OBJECTS { sipCommonNotifSequenceNumber, sipCommonNotifApplIndex, sipCommonCfgServiceLastChange } STATUS current DESCRIPTION "Signifies that the SIP service has reinitialized itself and is restarting after an administrative 'reset'. The configuration or behavior of the service MAY be altered." ::= { sipCommonMIBNotifications 5 } sipCommonServiceStatusChanged NOTIFICATION-TYPE OBJECTS { sipCommonNotifSequenceNumber, sipCommonNotifApplIndex, sipCommonCfgServiceLastChange, sipCommonCfgServiceOperStatus } STATUS current DESCRIPTION "Signifies that the SIP service operational status has changed." ::= { sipCommonMIBNotifications 6 } -- -- Conformance Lingle, et al. Standards Track [Page 50] RFC 4780 SIP MIB Modules April 2007 -- sipCommonMIBCompliances OBJECT IDENTIFIER ::= { sipCommonMIBConformance 1 } sipCommonMIBGroups OBJECT IDENTIFIER ::= { sipCommonMIBConformance 2 } -- -- Compliance Statements -- sipCommonCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities." MODULE -- this module MANDATORY-GROUPS { sipCommonConfigGroup, sipCommonStatsGroup } OBJECT sipCommonStatusCodeRowStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT sipCommonCfgServiceNotifEnable MIN-ACCESS not-accessible DESCRIPTION "This object is optional and does not need to be supported." GROUP sipCommonInformationalGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any support for these objects, as they provide optional information." GROUP sipCommonConfigTimerGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any timer configuration." GROUP sipCommonStatsRetryGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any retry statistics." GROUP sipCommonNotifGroup DESCRIPTION Lingle, et al. Standards Track [Page 51] RFC 4780 SIP MIB Modules April 2007 "This group is OPTIONAL. A SIP entity can elect to not provide any notifications. If implemented, the sipCommonStatusCodeNotifGroup and sipCommonNotifObjectsGroup MUST also be implemented." GROUP sipCommonStatusCodeNotifGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any notifications. If implemented, the sipCommonNotifGroup and sipCommonNotifObjectsGroup MUST also be implemented." GROUP sipCommonNotifObjectsGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any notifications. If implemented, the sipCommonStatusCodeNotifGroup and sipCommonNotifGroup MUST also be implemented." ::= { sipCommonMIBCompliances 1 } -- -- Units of Conformance -- sipCommonConfigGroup OBJECT-GROUP OBJECTS { sipCommonCfgProtocolVersion, sipCommonCfgServiceOperStatus, sipCommonCfgServiceStartTime, sipCommonCfgServiceLastChange, sipCommonPortTransportRcv, sipCommonOptionTag, sipCommonOptionTagHeaderField, sipCommonCfgMaxTransactions, sipCommonCfgServiceNotifEnable, sipCommonCfgEntityType, sipCommonMethodSupportedName } STATUS current DESCRIPTION "A collection of objects providing configuration common to all SIP entities." ::= { sipCommonMIBGroups 1 } sipCommonInformationalGroup OBJECT-GROUP OBJECTS { sipCommonCfgOrganization } STATUS current Lingle, et al. Standards Track [Page 52] RFC 4780 SIP MIB Modules April 2007 DESCRIPTION "A collection of objects providing configuration common to all SIP entities." ::= { sipCommonMIBGroups 2 } sipCommonConfigTimerGroup OBJECT-GROUP OBJECTS { sipCommonCfgTimerA, sipCommonCfgTimerB, sipCommonCfgTimerC, sipCommonCfgTimerD, sipCommonCfgTimerE, sipCommonCfgTimerF, sipCommonCfgTimerG, sipCommonCfgTimerH, sipCommonCfgTimerI, sipCommonCfgTimerJ, sipCommonCfgTimerK, sipCommonCfgTimerT1, sipCommonCfgTimerT2, sipCommonCfgTimerT4 } STATUS current DESCRIPTION "A collection of objects providing timer configuration common to all SIP entities." ::= { sipCommonMIBGroups 3 } sipCommonStatsGroup OBJECT-GROUP OBJECTS { sipCommonSummaryInRequests, sipCommonSummaryOutRequests, sipCommonSummaryInResponses, sipCommonSummaryOutResponses, sipCommonSummaryTotalTransactions, sipCommonSummaryDisconTime, sipCommonMethodStatsOutbounds, sipCommonMethodStatsInbounds, sipCommonMethodStatsDisconTime, sipCommonStatusCodeIns, sipCommonStatusCodeOuts, sipCommonStatusCodeRowStatus, sipCommonStatusCodeDisconTime, sipCommonTransCurrentactions, sipCommonOtherStatsNumUnsupportedUris, sipCommonOtherStatsNumUnsupportedMethods, sipCommonOtherStatsOtherwiseDiscardedMsgs, sipCommonOtherStatsDisconTime Lingle, et al. Standards Track [Page 53] RFC 4780 SIP MIB Modules April 2007 } STATUS current DESCRIPTION "A collection of objects providing statistics common to all SIP entities." ::= { sipCommonMIBGroups 4 } sipCommonStatsRetryGroup OBJECT-GROUP OBJECTS { sipCommonStatsRetries, sipCommonStatsRetryFinalResponses, sipCommonStatsRetryNonFinalResponses, sipCommonStatsRetryDisconTime } STATUS current DESCRIPTION "A collection of objects providing retry statistics." ::= { sipCommonMIBGroups 5 } sipCommonNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { sipCommonStatusCodeNotif, sipCommonStatusCodeThreshExceededInNotif, sipCommonStatusCodeThreshExceededOutNotif, sipCommonServiceColdStart, sipCommonServiceWarmStart, sipCommonServiceStatusChanged } STATUS current DESCRIPTION "A collection of notifications common to all SIP entities." ::= { sipCommonMIBGroups 6 } sipCommonStatusCodeNotifGroup OBJECT-GROUP OBJECTS { sipCommonStatusCodeNotifSend, sipCommonStatusCodeNotifEmitMode, sipCommonStatusCodeNotifThresh, sipCommonStatusCodeNotifInterval } STATUS current DESCRIPTION "A collection of objects related to the control and attribution of notifications common to all SIP entities." ::= { sipCommonMIBGroups 7 } sipCommonNotifObjectsGroup OBJECT-GROUP Lingle, et al. Standards Track [Page 54] RFC 4780 SIP MIB Modules April 2007 OBJECTS { sipCommonStatusCodeNotifTo, sipCommonStatusCodeNotifFrom, sipCommonStatusCodeNotifCallId, sipCommonStatusCodeNotifCSeq, sipCommonNotifApplIndex, sipCommonNotifSequenceNumber } STATUS current DESCRIPTION "A collection of accessible-for-notify objects related to the notification defined in this MIB module." ::= { sipCommonMIBGroups 8 } END 7.3. SIP User Agent MIB Module SIP-UA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI -- RFC 2578 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 applIndex FROM NETWORK-SERVICES-MIB -- RFC 2788 InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC 4001 SipTCEntityRole FROM SIP-TC-MIB; -- RFC 4780 sipUAMIB MODULE-IDENTITY LAST-UPDATED "200704200000Z" ORGANIZATION "IETF Session Initiation Protocol Working Group" CONTACT-INFO "SIP WG email: sip@ietf.org Co-editor Kevin Lingle Lingle, et al. Standards Track [Page 55] RFC 4780 SIP MIB Modules April 2007 Cisco Systems, Inc. postal: 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA email: klingle@cisco.com phone: +1 919 476 2029 Co-editor Joon Maeng email: jmaeng@austin.rr.com Co-editor Jean-Francois Mule CableLabs postal: 858 Coal Creek Circle Louisville, CO 80027 USA email: jf.mule@cablelabs.com phone: +1 303 661 9100 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) User Agent (UA) MIB module. SIP is an application-layer signaling protocol for creating, modifying, and terminating multimedia sessions with one or more participants. These sessions include Internet multimedia conferences and Internet telephone calls. SIP is defined in RFC 3261 (June 2002). A User Agent is an application that contains both a User Agent Client (UAC) and a User Agent Server (UAS). A UAC is an application that initiates a SIP request. A UAS is an application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects, or redirects the request. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4780; see the RFC itself for full legal notices." REVISION "200704200000Z" DESCRIPTION "Initial version of the IETF SIP-UA-MIB module. This version published as part of RFC 4780." ::= { mib-2 150 } -- Top-Level Components of this MIB. sipUAMIBObjects OBJECT IDENTIFIER ::= { sipUAMIB 1 } Lingle, et al. Standards Track [Page 56] RFC 4780 SIP MIB Modules April 2007 sipUAMIBConformance OBJECT IDENTIFIER ::= { sipUAMIB 2 } -- -- This MIB contains objects related to SIP User Agents. -- sipUACfgServer OBJECT IDENTIFIER ::= { sipUAMIBObjects 1 } -- -- SIP Server Configuration -- sipUACfgServerTable OBJECT-TYPE SYNTAX SEQUENCE OF SipUACfgServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP server configuration objects applicable to each SIP user agent in this system." ::= { sipUACfgServer 1 } sipUACfgServerEntry OBJECT-TYPE SYNTAX SipUACfgServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of server configuration. Each row represents those objects for a particular SIP user agent present in this system. applIndex is used to uniquely identify these instances of SIP user agents and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex, sipUACfgServerIndex } ::= { sipUACfgServerTable 1 } SipUACfgServerEntry ::= SEQUENCE { sipUACfgServerIndex Unsigned32, sipUACfgServerAddressType InetAddressType, sipUACfgServerAddress InetAddress, sipUACfgServerRole SipTCEntityRole } sipUACfgServerIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier of a server address when multiple addresses Lingle, et al. Standards Track [Page 57] RFC 4780 SIP MIB Modules April 2007 are configured by the SIP entity. If one address isn't reachable, then another can be tried." ::= { sipUACfgServerEntry 1 } sipUACfgServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the type of address contained in the associated instance of sipUACfgServerAddress." REFERENCE "INET-ADDRESS-MIB (RFC 4001)" ::= { sipUACfgServerEntry 2 } sipUACfgServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the address of a SIP server this user agent will use to proxy/redirect calls. The type of this address is determined by the value of the sipUACfgServerAddressType object." REFERENCE "INET-ADDRESS-MIB (RFC 4001)" ::= { sipUACfgServerEntry 3 } sipUACfgServerRole OBJECT-TYPE SYNTAX SipTCEntityRole MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the function of the SIP server this user agent should communicate with: registrar, proxy (outbound proxy), etc." ::= { sipUACfgServerEntry 4 } -- -- Conformance -- sipUAMIBCompliances OBJECT IDENTIFIER ::= { sipUAMIBConformance 1 } sipUAMIBGroups OBJECT IDENTIFIER ::= { sipUAMIBConformance 2 } -- -- Compliance Statements -- sipUACompliance MODULE-COMPLIANCE STATUS current Lingle, et al. Standards Track [Page 58] RFC 4780 SIP MIB Modules April 2007 DESCRIPTION "The compliance statement for SIP entities that implement the SIP-UA-MIB module." MODULE -- this module MANDATORY-GROUPS { sipUAConfigGroup } ::= { sipUAMIBCompliances 1 } -- -- Units of Conformance -- sipUAConfigGroup OBJECT-GROUP OBJECTS { sipUACfgServerAddressType, sipUACfgServerAddress, sipUACfgServerRole } STATUS current DESCRIPTION "A collection of objects providing information about the configuration of SIP User Agents." ::= { sipUAMIBGroups 1 } END 7.4. SIP Server MIB Module (Proxy, Redirect, and Registrar Servers) SIP-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, Gauge32, mib-2 FROM SNMPv2-SMI -- RFC 2578 TruthValue, TimeStamp, DateAndTime FROM SNMPv2-TC -- RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 Lingle, et al. Standards Track [Page 59] RFC 4780 SIP MIB Modules April 2007 applIndex FROM NETWORK-SERVICES-MIB -- RFC 2788 InetAddressType, InetAddress FROM INET-ADDRESS-MIB; -- RFC 4001 sipServerMIB MODULE-IDENTITY LAST-UPDATED "200704200000Z" ORGANIZATION "IETF Session Initiation Protocol Working Group" CONTACT-INFO "SIP WG email: sip@ietf.org Co-editor: Kevin Lingle Cisco Systems, Inc. postal: 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA email: klingle@cisco.com phone: +1 919 476 2029 Co-editor: Joon Maeng email: jmaeng@austin.rr.com Co-editor: Jean-Francois Mule CableLabs postal: 858 Coal Creek Circle Louisville, CO 80027 USA email: jf.mule@cablelabs.com phone: +1 303 661 9100 Co-editor: Dave Walker email: drwalker@rogers.com " DESCRIPTION "Session Initiation Protocol (SIP) Server MIB module. SIP is an application-layer signaling protocol for creating, modifying, and terminating multimedia sessions with one or more participants. These sessions include Internet multimedia conferences and Internet telephone calls. SIP is defined in RFC 3261 (June 2002). This MIB is defined for the management of SIP Proxy, Redirect, and Registrar Servers. Lingle, et al. Standards Track [Page 60] RFC 4780 SIP MIB Modules April 2007 A Proxy Server acts as both a client and a server. It accepts requests from other clients, either responding to them or passing them on to other servers, possibly after modification. A Redirect Server accepts requests from clients and returns zero or more addresses to that client. Unlike a User Agent Server, it does not accept calls. A Registrar is a server that accepts REGISTER requests. A Registrar is typically co-located with a Proxy or Redirect Server. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4780; see the RFC itself for full legal notices." REVISION "200704200000Z" DESCRIPTION "Initial version of the IETF SIP-SERVER-MIB module. This version published as part of RFC 4780." ::= { mib-2 151 } -- Top-Level Components of this MIB. sipServerMIBObjects OBJECT IDENTIFIER ::= { sipServerMIB 1 } sipServerMIBConformance OBJECT IDENTIFIER ::= { sipServerMIB 2 } -- -- These groups contain objects common to all SIP servers. -- sipServerCfg OBJECT IDENTIFIER ::= { sipServerMIBObjects 1 } -- -- Common Server Configuration Objects -- sipServerCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF SipServerCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains configuration objects applicable to SIP Redirect and Proxy Servers." ::= { sipServerCfg 1 } sipServerCfgEntry OBJECT-TYPE SYNTAX SipServerCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Lingle, et al. Standards Track [Page 61] RFC 4780 SIP MIB Modules April 2007 "A row of common configuration. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipServerCfgTable 1 } SipServerCfgEntry ::= SEQUENCE { sipServerCfgHostAddressType InetAddressType, sipServerCfgHostAddress InetAddress } sipServerCfgHostAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet address by which the SIP server is reachable." REFERENCE "RFC 3261, Section 19.1.1" ::= { sipServerCfgEntry 1 } sipServerCfgHostAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This is the host portion of a SIP URI that is assigned to the SIP server. It MAY contain a fully qualified domain name or an IP address. The length of the value will depend on the type of address specified. The type of address given by this object is controlled by sipServerCfgHostAddressType." REFERENCE "RFC 3261, Section 19.1.1" ::= { sipServerCfgEntry 2 } -- -- This group contains MIB objects -- related to SIP Proxy Servers. -- sipServerProxyCfg OBJECT IDENTIFIER ::= { sipServerMIBObjects 3 } Lingle, et al. Standards Track [Page 62] RFC 4780 SIP MIB Modules April 2007 sipServerProxyStats OBJECT IDENTIFIER ::= { sipServerMIBObjects 4 } -- -- Proxy Server Configuration -- sipServerProxyCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF SipServerProxyCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains configuration objects applicable to SIP Proxy Servers." ::= { sipServerProxyCfg 1 } sipServerProxyCfgEntry OBJECT-TYPE SYNTAX SipServerProxyCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common proxy configuration. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipServerProxyCfgTable 1 } SipServerProxyCfgEntry ::= SEQUENCE { sipServerCfgProxyStatefulness INTEGER, sipServerCfgProxyRecursion TruthValue, sipServerCfgProxyRecordRoute TruthValue, sipServerCfgProxyAuthMethod BITS, sipServerCfgProxyAuthDefaultRealm SnmpAdminString } sipServerCfgProxyStatefulness OBJECT-TYPE SYNTAX INTEGER { stateless(1), transactionStateful(2), callStateful(3) } MAX-ACCESS read-only STATUS current DESCRIPTION Lingle, et al. Standards Track [Page 63] RFC 4780 SIP MIB Modules April 2007 "This object reflects the default mode of operation for the Proxy Server entity. A stateless proxy is a logical entity that does not maintain the client or server transaction state machines when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream. If the value of this object is stateless(1), the proxy defaults to stateless operations. A transaction stateful proxy, or simply a 'stateful proxy', is a logical entity that maintains the client and server transaction state machines during the processing of a request. A (transaction) stateful proxy is not the same as a call stateful proxy. If the value of this object is transactionStateful(2), the proxy is stateful on a transaction basis. A call stateful proxy is a logical entity if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true. If the value of this object is callStateful(3), the proxy is call stateful." REFERENCE "RFC 3261, Section 16" ::= { sipServerProxyCfgEntry 1 } sipServerCfgProxyRecursion OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects whether or not the Proxy performs a recursive search on the Contacts provided in 3xx redirects. If the value of this object is 'true', a recursive search is performed. If the value is 'false', no search is performed, and the 3xx response is sent upstream towards the source of the request." REFERENCE "RFC 3261 Sections 16.5 and 16.6" ::= { sipServerProxyCfgEntry 2 } sipServerCfgProxyRecordRoute OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current Lingle, et al. Standards Track [Page 64] RFC 4780 SIP MIB Modules April 2007 DESCRIPTION "This object reflects whether or not the proxy adds itself to the Record-Route header as a default action. This header is used to list the proxies that insist on being in the signaling path for subsequent requests related to the call leg. If the value of this object is 'true', the proxy adds itself to the end of the Record-Route header, creating the header if required. If the value is 'false', the proxy does not add itself to the Record-Route header." REFERENCE "RFC 3261, Section 20.30" ::= { sipServerProxyCfgEntry 3 } -- -- Security -- sipServerCfgProxyAuthMethod OBJECT-TYPE SYNTAX BITS { none(0), tls(1), digest(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the authentication methods that MAY be used to authenticate request originators. bit 0 no authentication is performed bit 1 TLS is used bit 2 HTTP Digest is used." REFERENCE "RFC 3261 Sections 22, 23, 26, 26.2.3" ::= { sipServerProxyCfgEntry 4 } sipServerCfgProxyAuthDefaultRealm OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the default realm value used in Proxy-Authenticate headers. Note that this MAY need to be stored per user, in which case, this default value is ignored. " REFERENCE "RFC 3261, Section 22.1" ::= { sipServerProxyCfgEntry 5 } Lingle, et al. Standards Track [Page 65] RFC 4780 SIP MIB Modules April 2007 -- -- Proxy Server Statistics -- sipServerProxyStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipServerProxyStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the statistics objects applicable to all SIP Proxy Servers in this system." ::= { sipServerProxyStats 1 } sipServerProxyStatsEntry OBJECT-TYPE SYNTAX SipServerProxyStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of summary statistics. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipServerProxyStatsTable 1 } SipServerProxyStatsEntry ::= SEQUENCE { sipServerProxyStatProxyReqFailures Counter32, sipServerProxyStatsDisconTime TimeStamp } sipServerProxyStatProxyReqFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of occurrences of unsupported options being specified in received Proxy-Require headers. Such occurrences result in a 420 Bad Extension status code being returned. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by Lingle, et al. Standards Track [Page 66] RFC 4780 SIP MIB Modules April 2007 monitoring the sipServerProxyStatsDisconTime object in the same row." ::= { sipServerProxyStatsEntry 1 } sipServerProxyStatsDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for the server statistics objects in this row last experienced a discontinuity." ::= { sipServerProxyStatsEntry 2 } -- -- This group contains MIB objects related to SIP Registrars. -- sipServerRegCfg OBJECT IDENTIFIER ::= { sipServerMIBObjects 5 } sipServerRegStats OBJECT IDENTIFIER ::= { sipServerMIBObjects 6 } -- -- Registrar Configuration -- sipServerRegCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF SipServerRegCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains configuration objects applicable to SIP Registrars." ::= { sipServerRegCfg 1 } sipServerRegCfgEntry OBJECT-TYPE SYNTAX SipServerRegCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common Registrar configuration. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipServerRegCfgTable 1 } SipServerRegCfgEntry ::= Lingle, et al. Standards Track [Page 67] RFC 4780 SIP MIB Modules April 2007 SEQUENCE { sipServerRegMaxContactExpiryDuration Unsigned32, sipServerRegMaxUsers Unsigned32, sipServerRegCurrentUsers Gauge32, sipServerRegDfltRegActiveInterval Unsigned32 } sipServerRegMaxContactExpiryDuration OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum expiry that may be requested by a User Agent for a particular Contact. User Agents can specify expiry using either an Expiry header in a REGISTER request, or using an Expires parameter in a Contact header in a REGISTER request. If the value requested by the User Agent is greater than the value of this object, then the contact information is given the duration specified by this object, and that duration is indicated to the User Agent in the response." ::= { sipServerRegCfgEntry 1 } sipServerRegMaxUsers OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum number of users that the Registrar supports. The current number of users is reflected by sipServerRegCurrentUsers." ::= { sipServerRegCfgEntry 2 } sipServerRegCurrentUsers OBJECT-TYPE SYNTAX Gauge32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the number of users currently registered with the Registrar." ::= { sipServerRegCfgEntry 3 } sipServerRegDfltRegActiveInterval OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Lingle, et al. Standards Track [Page 68] RFC 4780 SIP MIB Modules April 2007 "This object reflects the default time interval the Registrar considers registrations to be active. The value is used to compute the Expires header in the REGISTER response. If a user agent requests a time interval shorter than specified by this object, the Registrar SHOULD honor that request. If a Contact entry does not have an 'expires' parameter, the value of the Expires header field is used instead. If a Contact entry has no 'expires' parameter and no Expires header field is present, the value of this object is used as the default value." REFERENCE "RFC 3261, Section 10.2" ::= { sipServerRegCfgEntry 4 } -- -- Per User Information -- sipServerRegUserTable OBJECT-TYPE SYNTAX SEQUENCE OF SipServerRegUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on all users registered to each Registrar in this system." ::= { sipServerRegCfg 2 } sipServerRegUserEntry OBJECT-TYPE SYNTAX SipServerRegUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry contains information for a single user registered to this Registrar. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex, sipServerRegUserIndex } ::= { sipServerRegUserTable 1 } SipServerRegUserEntry ::= SEQUENCE { sipServerRegUserIndex Unsigned32, sipServerRegUserUri SnmpAdminString, sipServerRegUserAuthenticationFailures Counter32, sipServerRegUserDisconTime TimeStamp } Lingle, et al. Standards Track [Page 69] RFC 4780 SIP MIB Modules April 2007 sipServerRegUserIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table." ::= { sipServerRegUserEntry 1 } sipServerRegUserUri OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the user's address-of-record. It is the main form by which the Registrar knows the user. The format is typically 'user@domain'. It is contained in the To header for all REGISTER requests." ::= { sipServerRegUserEntry 2 } sipServerRegUserAuthenticationFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number of times the user has failed authentication. Discontinuities in the value of this counter can occur due to successful user authentications and at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipServerRegUserDisconTime object in the same row." ::= { sipServerRegUserEntry 3 } sipServerRegUserDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for the user registration statistics objects in this row last experienced a discontinuity." ::= { sipServerRegUserEntry 4 } -- -- Per Contact Information -- sipServerRegContactTable OBJECT-TYPE SYNTAX SEQUENCE OF SipServerRegContactEntry Lingle, et al. Standards Track [Page 70] RFC 4780 SIP MIB Modules April 2007 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on every location where a registered user (specified by sipServerRegUserIndex) wishes to be found (i.e., the user has provided contact information to each SIP Registrar in this system)." ::= { sipServerRegCfg 3 } sipServerRegContactEntry OBJECT-TYPE SYNTAX SipServerRegContactEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry contains information for a single Contact. Multiple contacts may exist for a single user. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex, sipServerRegUserIndex, sipServerRegContactIndex } ::= { sipServerRegContactTable 1 } SipServerRegContactEntry ::= SEQUENCE { sipServerRegContactIndex Unsigned32, sipServerRegContactDisplayName SnmpAdminString, sipServerRegContactURI SnmpAdminString, sipServerRegContactLastUpdated TimeStamp, sipServerRegContactExpiry DateAndTime, sipServerRegContactPreference SnmpAdminString } sipServerRegContactIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Along with the sipServerRegUserIndex, this object uniquely identifies a conceptual row in the table." ::= { sipServerRegContactEntry 1 } Lingle, et al. Standards Track [Page 71] RFC 4780 SIP MIB Modules April 2007 sipServerRegContactDisplayName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the display name for the Contact. For example, 'Santa at Home', or 'Santa on his Sled', corresponding to contact URIs of sip:BigGuy@example.com or sip:sclaus817@example.com, respectively." ::= { sipServerRegContactEntry 2 } sipServerRegContactURI OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains either a SIP URI where the user can be contacted. This URI is normally returned to a client from a Redirect Server, or is used as the RequestURI in a SIP request line for requests forwarded by a proxy." ::= { sipServerRegContactEntry 3 } sipServerRegContactLastUpdated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the time when this contact information was accepted. If the contact information is updated via a subsequent REGISTER of the same information, this object is also updated." ::= { sipServerRegContactEntry 4 } sipServerRegContactExpiry OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the date and time when the contact information will no longer be valid. Such times may be specified by the user at registration (i.e., Expires header or expiry parameter in the Contact information), or a system default can be applied." ::= { sipServerRegContactEntry 5 } sipServerRegContactPreference OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only Lingle, et al. Standards Track [Page 72] RFC 4780 SIP MIB Modules April 2007 STATUS current DESCRIPTION "This object indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record. A registering user may provide this preference as a 'qvalue' parameter in the Contact header. The format of this item is a decimal number between 0 and 1 (for example 0.9). Higher values indicate locations preferred by the user." REFERENCE "RFC 3261, Section 10.2.1.2, 16.6, and 20.10" ::= { sipServerRegContactEntry 6 } -- -- Registrar Statistics -- sipServerRegStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipServerRegStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the summary statistics objects applicable to all SIP Registrars in this system." ::= { sipServerRegStats 1 } sipServerRegStatsEntry OBJECT-TYPE SYNTAX SipServerRegStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of summary statistics. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipServerRegStatsTable 1 } SipServerRegStatsEntry ::= SEQUENCE { sipServerRegStatsAcceptedRegs Counter32, sipServerRegStatsRejectedRegs Counter32, sipServerRegStatsDisconTime TimeStamp } Lingle, et al. Standards Track [Page 73] RFC 4780 SIP MIB Modules April 2007 sipServerRegStatsAcceptedRegs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number of REGISTER requests that have been accepted (status code 200) by the Registrar. This includes additions of new contact information, refreshing contact information, as well as requests for deletion of contact information. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipServerRegStatsDisconTime object in the same row." ::= { sipServerRegStatsEntry 1 } sipServerRegStatsRejectedRegs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number REGISTER requests that have been rejected by the Registrar. Discontinuities in the value of this counter can occur at re-initialization of the SIP entity or service. A Management Station can detect discontinuities in this counter by monitoring the sipServerRegStatsDisconTime object in the same row." ::= { sipServerRegStatsEntry 2 } sipServerRegStatsDisconTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime object when the counters for the registrar statistics objects in this row last experienced a discontinuity." ::= { sipServerRegStatsEntry 3 } -- -- Conformance -- sipServerMIBCompliances OBJECT IDENTIFIER ::= { sipServerMIBConformance 1 } Lingle, et al. Standards Track [Page 74] RFC 4780 SIP MIB Modules April 2007 sipServerMIBGroups OBJECT IDENTIFIER ::= { sipServerMIBConformance 2 } -- -- Compliance Statements -- sipServerProxyServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities acting as Proxy Servers." MODULE -- this module MANDATORY-GROUPS { sipServerConfigGroup, sipServerProxyConfigGroup, sipServerProxyStatsGroup } ::= { sipServerMIBCompliances 1 } sipRedirectServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities acting as Redirect Servers." MODULE -- this module MANDATORY-GROUPS { sipServerConfigGroup } ::= { sipServerMIBCompliances 2 } sipServerRegistrarServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities acting as Registrars." MODULE -- this module MANDATORY-GROUPS { sipServerConfigGroup, sipServerRegistrarConfigGroup, sipServerRegistrarStatsGroup } GROUP sipServerRegistrarUsersGroup DESCRIPTION "This is an optional group." ::= { sipServerMIBCompliances 3 } -- -- Units of Conformance -- sipServerConfigGroup OBJECT-GROUP OBJECTS { sipServerCfgHostAddressType, sipServerCfgHostAddress Lingle, et al. Standards Track [Page 75] RFC 4780 SIP MIB Modules April 2007 } STATUS current DESCRIPTION "A collection of objects providing configuration common to SIP Proxy and Redirect servers." ::= { sipServerMIBGroups 1 } sipServerProxyConfigGroup OBJECT-GROUP OBJECTS { sipServerCfgProxyStatefulness, sipServerCfgProxyRecursion, sipServerCfgProxyRecordRoute, sipServerCfgProxyAuthMethod, sipServerCfgProxyAuthDefaultRealm } STATUS current DESCRIPTION "A collection of objects providing configuration for SIP Proxy servers." ::= { sipServerMIBGroups 2 } sipServerProxyStatsGroup OBJECT-GROUP OBJECTS { sipServerProxyStatProxyReqFailures, sipServerProxyStatsDisconTime } STATUS current DESCRIPTION "A collection of objects providing statistics for SIP Proxy servers." ::= { sipServerMIBGroups 3 } sipServerRegistrarConfigGroup OBJECT-GROUP OBJECTS { sipServerRegMaxContactExpiryDuration, sipServerRegMaxUsers, sipServerRegCurrentUsers, sipServerRegDfltRegActiveInterval } STATUS current DESCRIPTION "A collection of objects providing configuration for SIP Registrars." ::= { sipServerMIBGroups 4 } sipServerRegistrarStatsGroup OBJECT-GROUP OBJECTS { sipServerRegStatsAcceptedRegs, Lingle, et al. Standards Track [Page 76] RFC 4780 SIP MIB Modules April 2007 sipServerRegStatsRejectedRegs, sipServerRegStatsDisconTime } STATUS current DESCRIPTION "A collection of objects providing statistics for SIP Registrars." ::= { sipServerMIBGroups 5 } sipServerRegistrarUsersGroup OBJECT-GROUP OBJECTS { sipServerRegUserUri, sipServerRegUserAuthenticationFailures, sipServerRegUserDisconTime, sipServerRegContactDisplayName, sipServerRegContactURI, sipServerRegContactLastUpdated, sipServerRegContactExpiry, sipServerRegContactPreference } STATUS current DESCRIPTION "A collection of objects related to registered users." ::= { sipServerMIBGroups 6 } END 8. IANA Considerations The MIB modules defined in this document use the following IANA- assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: +--------------+-------------------------+ | Descriptor | OBJECT IDENTIFIER value | +--------------+-------------------------+ | sipTC | { mib-2 148 } | | sipCommonMIB | { mib-2 149 } | | sipUAMIB | { mib-2 150 } | | sipServerMIB | { mib-2 151 } | +--------------+-------------------------+ Lingle, et al. Standards Track [Page 77] RFC 4780 SIP MIB Modules April 2007 9. Security Considerations There are a number of management objects defined in the SIP-COMMON- MIB MIB module with a MAX-ACCESS clause of read-write and/or read- create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non- secure environment without proper protection can have a negative effect on network operations. The following read-create object in SIP-COMMON-MIB is used to configure the status code statistics that will be monitored by the SIP entity: sipCommonStatusCodeRowStatus: If this object is SET maliciously, it may result in an over- allocation of resources in a system for the purpose of accumulating and maintaining statistics. The following read-write objects in SIP-COMMON-MIB are used to configure the behavior of certain SNMP notifications potentially generated by a SIP entity: sipCommonStatusCodeNotifSend, sipCommonStatusCodeNotifEmitMode, sipCommonStatusCodeNotifThresh, sipCommonStatusCodeNotifInterval, sipCommonCfgServiceNotifEnable: If these objects are SET maliciously, it may result in a system and/or network performance impact due to the generation of SNMP notifications. Some of the readable objects in the MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The following object values may contain private or confidential customer information like first name, last name, customer identification, location, company affiliation, the time the information was updated, etc. sipServerRegContactDisplayName, sipServerRegContactURI, sipServerRegContactLastUpdated and sipCommonCfgOrganization. Lingle, et al. Standards Track [Page 78] RFC 4780 SIP MIB Modules April 2007 The sipCommonCfgTable table contains some objects that may help attackers gain knowledge about the status and operations of the SIP service. In particular, the object value of sipCommonCfgServiceOperStatus may indicate that the SIP entity is in congested state and may lead attackers to build additional service attacks to overload the system. The sipCommonCfgEntityType object indicates the type of SIP entity, and the sipCommonMethodSupportedTable table contains in the SIP- COMMON-MIB MIB module list of SIP methods supported by each entity in the system. Gaining access to this information may allow attackers to build method-specific attacks or use unsupported methods to create denial-of-service attack scenarios. In the SIP-UA-MIB MIB module, the sipUACfgServerTable contains the address of the SIP servers providing services to the UA, and obtaining this information may disclose some private or sensitive information about the SIP service usage. In the SIP-SERVER-MIB MIB module, the sipServerCfgProxyAuthMethod object defines the authentication methods supported by the server and may be used to build specific denial-of-service attackers targeted at the security mechanisms employed by the SIP entity. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this set of MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see RFC 3410 [RFC3410]), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsi when bility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Lingle, et al. Standards Track [Page 79] RFC 4780 SIP MIB Modules April 2007 10. Contributor Acknowledgments We wish to thank the members of the IETF SIP and SIPPING working groups, and the SIP-MIB Design team for their comments and suggestions. Detailed comments were provided by Tom Taylor, Kavitha Patchayappan, Dan Romascanu, Cullen Jennings, Orit Levin, AC Mahendran, Mary Barnes, Rohan Mahy, Bob Penfield, Charles Eckel, and Dean Willis. Special thanks to Bert Wijnen for his expert reviews, which have greatly improved the SIP MIB modules. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2788] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC 2788, March 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. Lingle, et al. Standards Track [Page 80] RFC 4780 SIP MIB Modules April 2007 11.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005. Lingle, et al. Standards Track [Page 81] RFC 4780 SIP MIB Modules April 2007 Authors' Addresses Kevin Lingle Cisco Systems, Inc. 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 US Phone: +1 919 476 2029 EMail: klingle@cisco.com Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Phone: +1 303 661 9100 EMail: jf.mule@cablelabs.com Joon Maeng 5612 Sedona Drive Austin, TX 78759 US Phone: +1 512 418 0590 EMail: jmaeng@austin.rr.com Dave Walker EMail: drwalker@rogers.com Lingle, et al. Standards Track [Page 82] RFC 4780 SIP MIB Modules April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lingle, et al. Standards Track [Page 83] snmp-mibs-downloader-1.1/mibrfcs/rfc4789.txt0000644000000000000000000004265711402176072015614 0ustar Network Working Group J. Schoenwaelder Request for Comments: 4789 International University Bremen Obsoletes: 1089 T. Jeffree Updates: 3417 Consultant Category: Standards Track November 2006 Simple Network Management Protocol (SNMP) over IEEE 802 Networks 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. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks. This document obsoletes RFC 1089. Table of Contents 1. Introduction ....................................................2 1.1. Key Words ..................................................2 2. Definitions .....................................................3 3. SNMP over IEEE 802 Networks .....................................4 3.1. Serialization ..............................................4 3.2. Well-known Values ..........................................4 3.3. IEEE 802.3 Frame Format ....................................5 4. Relationship to Other MIB Modules ...............................5 5. IANA Considerations .............................................6 6. Security Considerations .........................................6 7. Acknowledgments .................................................7 8. References ......................................................7 8.1. Normative References .......................................7 8.2. Informative References .....................................7 Schoenwaelder & Jeffree Standards Track [Page 1] RFC 4789 SNMP over IEEE 802 November 2006 1. Introduction This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks. For a detailed overview of the documents that describe the Internet- Standard management framework, please refer to section 7 of RFC 3410 [RFC3410]. This document supplements the standard SNMP transport mappings defined in RFC 3417 [RFC3417]. This document obsoletes RFC 1089. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.1. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Schoenwaelder & Jeffree Standards Track [Page 2] RFC 4789 SNMP over IEEE 802 November 2006 2. Definitions SNMP-IEEE802-TM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, snmpModules, snmpDomains FROM SNMPv2-SMI; snmpIeee802TmMib MODULE-IDENTITY LAST-UPDATED "200611210000Z" ORGANIZATION "IETF Operations and Management Area" CONTACT-INFO "Juergen Schoenwaelder (Editor) International University Bremen P.O. Box 750 561 28725 Bremen, Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Send comments to ." DESCRIPTION "This MIB module defines the SNMP over IEEE 802 transport mapping. Copyright (C) The IETF Trust (2006). This version of this MIB module is part of RFC 4789; see the RFC itself for full legal notices." REVISION "200611210000Z" DESCRIPTION "The initial version, published as RFC 4789." ::= { snmpModules 21 } snmpIeee802Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over IEEE 802 networks transport domain. The corresponding transport address is of type MacAddress as defined in the SNMPv2-TC module (RFC 2579)." REFERENCE "RFC 2579" ::= { snmpDomains 6 } END Schoenwaelder & Jeffree Standards Track [Page 3] RFC 4789 SNMP over IEEE 802 November 2006 3. SNMP over IEEE 802 Networks This is an optional transport mapping. The need to carry SNMP directly over an 802 LAN transport in order to allow for the management of simple devices was identified in applications like the Two-Port Media Access Control (MAC) Relay, which is being developed in IEEE 802.1 as project P802.1aj [802.1aj]. SNMP over IEEE 802 networks has some inherent restrictions. Using the SNMP over IEEE 802 transport mapping restricts messages to a single logical IEEE 802 LAN, bridged LAN or VLAN. Furthermore, only a single SNMP engine can be addressed on a given IEEE 802 network interface. In particular, command generators and notification receivers, as well as command responders and notification originators, must share a single transport endpoint. 3.1. Serialization SNMP messages are serialized, as described in Section 8 of RFC 3417 [RFC3417]. The resulting serialized message is shipped in the data portion of an IEEE LAN MAC frame. 3.2. Well-known Values Serialized SNMP messages are sent in IEEE 802.3 frames with an Ethernet type field of 33100 (hexadecimal 814C). When serialized SNMP messages are sent in IEEE 802.3 frames (and in other IEEE 802 MAC frame types that can natively represent Ethernet type values), an Ethernet type field value of 33100 (hexadecimal 814C) MUST be used as the link layer protocol identifier. In IEEE 802 LANs that use LLC as the means of link layer protocol identification, such as IEEE 802.11 Wireless LANs, the SNAP encapsulation method described in subclause 10.5 "Encapsulation of Ethernet frames over LLC" in [IEEE802] MUST be used. When an SNMP entity uses this transport mapping, it MUST be capable of accepting SNMP messages up to and including 484 octets in size. It is RECOMMENDED that implementations be capable of accepting messages of up to 1472 octets in size. Implementation of larger values is encouraged whenever possible. Schoenwaelder & Jeffree Standards Track [Page 4] RFC 4789 SNMP over IEEE 802 November 2006 3.3. IEEE 802.3 Frame Format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +- -+ | Ethernet | +- -+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +- -+ | Ethernet | +- -+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 1 0 1 0 0 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SNMP | +- -+ / message ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Each tic mark represents one bit.) 4. Relationship to Other MIB Modules Several core SNMP MIB modules use TDomain/TAddress pairs to identify SNMP transport endpoints. The SNMP-TARGET-MIB [RFC3413] uses TDomain/TAddress pairs to identify targets that can be used as notification receivers. TDomain/TAddress pairs are used by the NOTIFICATION-LOG-MIB [RFC3014] to record the source from which a notification was received. The ENTITY-MIB [RFC4133] uses TDomain/ TAddress pairs to provide the transport endpoint of logical entities. The MIB module contained in this document introduces the object identifier constant snmpIeee802Domain. This constant can be assigned to an object of type TDomain to identify an SNMP over IEEE 802 endpoint, in which case the corresponding TAddress will have a value that conforms to the MacAddress textual convention. By providing these definitions, it is possible to use the generic MIB modules to refer to SNMP over IEEE 802 endpoints. Schoenwaelder & Jeffree Standards Track [Page 5] RFC 4789 SNMP over IEEE 802 November 2006 5. IANA Considerations IANA made a MIB OID assignment under the snmpModules branch for the SNMP-IEEE802-TM-MIB module. IANA assigned an OID value below snmpDomains for the transport domain. This first required the setup of a registry for OIDs under snmpDomains. At the point of this writing, the following assignments already exist: Prefix: iso.org.dod.internet.snmpv2.snmpDomains (1.3.6.1.6.1) Decimal Name Description References ------- ---- ----------- ---------- 1 snmpUDPDomain SNMP over UDP [RFC3417] 2 snmpCLNSDomain SNMP over CLNS [RFC3417] 3 snmpCONSDomain SNMP over CONS [RFC3417] 4 snmpDDPDomain SNMP over DDP [RFC3417] 5 snmpIPXDomain SNMP over IPX [RFC3417] The following assigment has been made: Decimal Name Description References ------- ---- ----------- ---------- 6 snmpIeee802Domain SNMP over IEEE 802 RFC 4789 For new assignments, a specification is required as per [RFC2434]. 6. Security Considerations This module does not define any management objects. Instead, it defines an OBJECT-IDENTIFIER which may be used by other MIB modules to identify an SNMP transport mapping. Meaningful security considerations can only be written in the MIB modules that define management objects. The MIB module in this document has therefore no impact on the security of the Internet. SNMPv1 and SNMPv2c messages are not considered secure. It is recommended that the implementors consider the use of SNMPv3 messages and the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to a MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change) them. Schoenwaelder & Jeffree Standards Track [Page 6] RFC 4789 SNMP over IEEE 802 November 2006 7. Acknowledgments The original SNMP over Ethernet definition was written by Marty Schoffstall, Chuck Davin, Mark Fedor, and Jeff Case, and published as RFC 1089 [RFC1089]. Bert Wijnen and Dan Romascanu provided guidance on many aspects of this revised specification. David Harrington provided useful comments that improved the presentation. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [IEEE802] "IEEE Standard for Local Area Networks: Overview and Architecture", IEEE Std. 802-2001. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Schoenwaelder & Jeffree Standards Track [Page 7] RFC 4789 SNMP over IEEE 802 November 2006 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC1089] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over Ethernet", RFC 1089, February 1989. [802.1aj] P802.1aj/D1.4 Draft Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 08: Two-Port Media Access Control (MAC) Relay, IEEE 802.1 Working Group, June 2006, Work in Progress. Authors' Addresses Juergen Schoenwaelder International University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Tony Jeffree Consultant 11a Poplar Grove Sale, Cheshire, M33 3AX United Kingdom Phone: +44-161-973-4278 EMail: tony@jeffree.co.uk Schoenwaelder & Jeffree Standards Track [Page 8] RFC 4789 SNMP over IEEE 802 November 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schoenwaelder & Jeffree Standards Track [Page 9] snmp-mibs-downloader-1.1/mibrfcs/rfc4801.txt0000644000000000000000000003773311402176072015574 0ustar Network Working Group T. Nadeau, Ed. Request for Comment: 4801 Cisco Systems, Inc. Category: Standards Track A. Farrel, Ed. Old Dog Consulting February 2007 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. GMPLS Textual Conventions MIB Definitions .......................3 4. Security Considerations .........................................5 5. IANA Considerations .............................................6 6. References ......................................................6 6.1. Normative References .......................................6 6.2. Informative References .....................................7 7. Acknowledgements ................................................7 Nadeau & Farrel Standards Track [Page 1] RFC 4801 TCs for GMPLS Management February 2007 1. Introduction This document defines a MIB module that contains textual conventions (TCs) for Generalized Multiprotocol Label Switching (GMPLS) networks. These textual conventions should be imported by MIB modules that manage GMPLS networks. This MIB module supplements the MIB module in [RFC3811] that defines textual conventions for Multiprotocol Label Switching (MPLS) management. [RFC3811] may continue to be used without this MIB module in networks that support only MPLS. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. For an introduction to the concepts of GMPLS, see [RFC3945]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Nadeau & Farrel Standards Track [Page 2] RFC 4801 TCs for GMPLS Management February 2007 3. GMPLS Textual Conventions MIB Definitions This MIB module makes reference to the following documents: [RFC2578], [RFC2579], [RFC3471], and [RFC3811]. GMPLS-TC-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC 2579 mplsStdMIB FROM MPLS-TC-STD-MIB -- RFC 3811 ; gmplsTCStdMIB MODULE-IDENTITY LAST-UPDATED "200702280000Z" -- 28 February 2007 00:00:00 GMT ORGANIZATION "IETF Common Control and Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Comments about this document should be emailed directly to the CCAMP working group mailing list at ccamp@ops.ietf.org" DESCRIPTION "Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4801; see the RFC itself for full legal notices. This MIB module defines TEXTUAL-CONVENTIONs for concepts used in Generalized Multiprotocol Label Switching (GMPLS) networks." REVISION "200702280000Z" -- 28 February 2007 00:00:00 GMT DESCRIPTION "Initial version published as part of RFC 4801." ::= { mplsStdMIB 12 } GmplsFreeformLabelTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Nadeau & Farrel Standards Track [Page 3] RFC 4801 TCs for GMPLS Management February 2007 "This TEXTUAL-CONVENTION can be used as the syntax of an object that contains any GMPLS Label. Objects with this syntax can be used to represent labels that have label types that are not defined in any RFCs. The freeform GMPLS Label may also be used by systems that do not wish to represent labels that have label types defined in RFCs using type-specific syntaxes." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.2." SYNTAX OCTET STRING (SIZE (0..64)) GmplsLabelTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Determines the interpretation that should be applied to an object that encodes a label. The possible types are: gmplsMplsLabel(1) - The label is an MPLS Packet, Cell, or Frame Label and is encoded as described for the TEXTUAL- CONVENTION MplsLabel defined in RFC 3811. gmplsPortWavelengthLabel(2) - The label is a Port or Wavelength Label as defined in RFC 3471. gmplsFreeformLabel(3) - The label is any form of label encoded as an OCTET STRING using the TEXTUAL-CONVENTION GmplsFreeformLabel. gmplsSonetLabel(4) - The label is a Synchronous Optical Network (SONET) Label as defined in RFC 4606. gmplsSdhLabel(5) - The label is a Synchronous Digital Hierarchy (SDH) Label as defined in RFC 4606. gmplsWavebandLabel(6) - The label is a Waveband Label as defined in RFC 3471." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3. 2. Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management, RFC 3811, section 3. 3. Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Nadeau & Farrel Standards Track [Page 4] RFC 4801 TCs for GMPLS Management February 2007 Digital Hierarchy (SDH) Control, RFC 4606." SYNTAX INTEGER { gmplsMplsLabel(1), gmplsPortWavelengthLabel(2), gmplsFreeformGeneralizedLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) } GmplsSegmentDirectionTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The direction of data flow on an Label Switched Path (LSP) segment with respect to the head of the LSP. Where an LSP is signaled using a conventional signaling protocol, the 'head' of the LSP is the source of the signaling (also known as the ingress) and the 'tail' is the destination (also known as the egress). For unidirectional LSPs, this usually matches the direction of flow of data. For manually configured unidirectional LSPs, the direction of the LSP segment matches the direction of flow of data. For manually configured bidirectional LSPs, an arbitrary decision must be made about which LER is the 'head'." SYNTAX INTEGER { forward(1), -- data flows from head-end of LSP toward tail-end reverse(2) -- data flows from tail-end of LSP toward head-end } END 4. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other GMPLS MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet. Nadeau & Farrel Standards Track [Page 5] RFC 4801 TCs for GMPLS Management February 2007 5. IANA Considerations IANA has rooted MIB objects in this MIB module under the mplsStdMIB subtree by assigning an OID to gmplsTCStdMIB. IANA has made the following assignments in the "NETWORK MANAGEMENT PARAMETERS" registry located at http://www.iana.org/assignments/smi- numbers in table: ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166) Decimal Name References ------- ----- ---------- 12 GMPLS-TC-STD-MIB [RFC4801] In the future, GMPLS-related standards-track MIB modules should be rooted under the mplsStdMIB (sic) subtree. IANA has been requested to manage that namespace in the SMI Numbers registry [RFC3811]. New assignments can only be made via a Standards Action as specified in [RFC2434]. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. Nadeau & Farrel Standards Track [Page 6] RFC 4801 TCs for GMPLS Management February 2007 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 6.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. 7. Acknowledgements This document is a product of the CCAMP Working Group. Special thanks to Joan Cucchiara for her help with compilation issues and her very thorough MIB Doctor review. Thanks also to Lars Eggert, David Harrington, Harrie Hazewinkel, Dan Romascanu, and Bert Wijnen for their review comments. Nadeau & Farrel Standards Track [Page 7] RFC 4801 TCs for GMPLS Management February 2007 Contact Information Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 EMail: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Phone: +44 1978 860944 EMail: adrian@olddog.co.uk Cheenu Srinivasan Bloomberg L.P. 731 Lexington Ave. New York, NY 10022 Phone: +1-212-617-3682 EMail: cheenu@bloomberg.net Tim Hall Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 EMail: tim.hall@dataconnection.com Ed Harrison Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 EMail: ed.harrison@dataconnection.com Nadeau & Farrel Standards Track [Page 8] RFC 4801 TCs for GMPLS Management February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nadeau & Farrel Standards Track [Page 9] snmp-mibs-downloader-1.1/mibrfcs/rfc4802.txt0000644000000000000000000034662411402176072015577 0ustar Network Working Group T. Nadeau, Ed. Request for Comment: 4802 Cisco Systems, Inc. Category: Standards Track A. Farrel, Ed. Old Dog Consulting February 2007 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. Nadeau & Farrel Standards Track [Page 1] RFC 4802 GMPLS TE MIB February 2007 Table of Contents 1. Introduction ....................................................2 1.1. Migration Strategy .........................................3 2. Terminology .....................................................3 3. The Internet-Standard Management Framework ......................4 4. Outline .........................................................4 4.1. Summary of GMPLS Traffic Engineering MIB Module ............4 5. Brief Description of GMPLS TE MIB Objects .......................5 5.1. gmplsTunnelTable ...........................................5 5.2. gmplsTunnelHopTable ........................................6 5.3. gmplsTunnelARHopTable ......................................6 5.4. gmplsTunnelCHopTable .......................................6 5.5. gmplsTunnelErrorTable ......................................6 5.6. gmplsTunnelReversePerfTable ................................6 5.7. Use of 32-bit and 64-bit Counters ..........................7 6. Cross-referencing to the gmplsLabelTable ........................7 7. Example of GMPLS Tunnel Setup ...................................8 8. GMPLS Traffic Engineering MIB Module ...........................11 9. Security Considerations ........................................47 10. Acknowledgments ...............................................48 11. IANA Considerations ...........................................49 11.1. IANA Considerations for GMPLS-TE-STD-MIB .................49 11.2. Dependence on IANA MIB Modules ...........................49 11.2.1. IANA-GMPLS-TC-MIB Definition ......................50 12. References ....................................................56 12.1. Normative References .....................................56 12.2. Informative References ...................................58 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] based traffic engineering (TE). The tables and objects defined in this document extend those defined in the equivalent document for MPLS traffic engineering [RFC3812], and management of GMPLS traffic engineering is built on management of MPLS traffic engineering. The MIB modules in this document should be used in conjunction with the companion document [RFC4803] for GMPLS-based traffic engineering configuration and management. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Nadeau & Farrel Standards Track [Page 2] RFC 4802 GMPLS TE MIB February 2007 1.1. Migration Strategy MPLS-TE Label Switched paths (LSPs) may be modeled and managed using the MPLS-TE-STD-MIB module [RFC3812]. Label Switching Routers (LSRs) may be migrated to model and manage their TE LSPs using the MIB modules in this document in order to migrate the LSRs to GMPLS support, or to take advantage of additional MIB objects defined in these MIB modules that are applicable to MPLS-TE. The GMPLS TE MIB module (GMPLS-TE-STD-MIB) defined in this document extends the MPLS-TE-STD-MIB module [RFC3812] through a series of augmentations and sparse augmentations of the MIB tables. The only additions are for support of GMPLS or to support the increased complexity of MPLS and GMPLS systems. In order to migrate from MPLS-TE-STD-MIB support to GMPLS-TE-STD-MIB support, an implementation needs only to add support for the additional tables and objects defined in GMPLS-TE-STD-MIB. The gmplsTunnelLSPEncoding may be set to tunnelLspNotGmpls to allow an MPLS-TE LSP tunnel to benefit from the additional objects and tables of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols. The companion document for modeling and managing GMPLS-based LSRs [RFC4803] extends the MPLS-LSR-STD-MIB module [RFC3813] with the same intentions. Textual conventions are defined in [RFC3811] and the IANA-GMPLS-TC- MIB module. 2. Terminology This document uses terminology from the MPLS architecture document [RFC3031], from the GMPLS architecture document [RFC3945], and from the MPLS Traffic Engineering MIB [RFC3812]. Some frequently used terms are described next. An explicitly routed LSP (ERLSP) is referred to as a GMPLS tunnel. It consists of in-segment(s) and/or out-segment(s) at the egress/ingress LSRs, each segment being associated with one GMPLS- enabled interface. These are also referred to as tunnel segments. Additionally, at an intermediate LSR, we model a connection as consisting of one or more in-segments and/or one or more out- segments. The binding or interconnection between in-segments and out-segments is performed using a cross-connect. Nadeau & Farrel Standards Track [Page 3] RFC 4802 GMPLS TE MIB February 2007 These segment and cross-connect objects are defined in the MPLS Label Switching Router MIB (MPLS-LSR-STD-MIB) [RFC3813], but see also the GMPLS Label Switching Router MIB (GMPLS-LSR-STD-MIB) [RFC4803] for the GMPLS-specific extensions to these objects. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Outline Support for GMPLS traffic-engineered tunnels requires the following configuration. - Setting up tunnels with appropriate MPLS configuration parameters using [RFC3812]. - Extending the tunnel definitions with GMPLS configuration parameters. - Configuring loose and strict source routed tunnel hops. These actions may need to be accompanied with corresponding actions using [RFC3813] and [RFC4803] to establish and configure tunnel segments, if this is done manually. Also, the in-segment and out- segment performance tables, mplsInSegmentPerfTable and mplsOutSegmentPerfTable [RFC3813], should be used to determine performance of the tunnels and tunnel segments, although it should be noted that those tables may not be appropriate for measuring performance on some types of GMPLS links. 4.1. Summary of GMPLS Traffic Engineering MIB Module The following tables contain MIB objects for performing the actions listed above when they cannot be performed solely using MIB objects defined in MPLS-TE-STD-MIB [RFC3812]. Nadeau & Farrel Standards Track [Page 4] RFC 4802 GMPLS TE MIB February 2007 - Tunnel table (gmplsTunnelTable) for providing GMPLS-specific tunnel configuration parameters. - Tunnel hop, actual tunnel hop, and computed tunnel hop tables (gmplsTunnelHopTable, gmplsTunnelARHopTable, and gmplsTunnelCHopTable) for providing additional configuration of strict and loose source routed tunnel hops. - Performance and error reporting tables (gmplsTunnelReversePerfTable and gmplsTunnelErrorTable). These tables are described in the subsequent sections. Additionally, the GMPLS-TE-STD-MIB module contains a new notification. - The GMPLS Tunnel Down Notification (gmplsTunnelDown) should be used for all GMPLS tunnels in place of the mplsTunnelDown notification defined in [RFC3812]. An implementation must not issue both the gmplsTunnelDown and the mplsTunnelDown notifications for the same event. As well as indicating that a tunnel has transitioned to operational down state, this new notification indicates the cause of the failure. 5. Brief Description of GMPLS TE MIB Objects The objects described in this section support the functionality described in [RFC3473] and [RFC3472] for GMPLS tunnels. The tables support both manually configured and signaled tunnels. 5.1. gmplsTunnelTable The gmplsTunnelTable extends the MPLS traffic engineering MIB module (MPLS-TE-STD-MIB [RFC3812]) to allow GMPLS tunnels to be created between an LSR and a remote endpoint, and existing GMPLS tunnels to be reconfigured or removed. Note that we only support point-to-point tunnel segments, although multipoint-to-point and point-to-multipoint connections are supported by an LSR acting as a cross-connect. Each tunnel can thus have one out-segment originating at an LSR and/or one in-segment terminating at that LSR. Three objects within this table utilize enumerations in order to map to enumerations that are used in GMPLS signaling. In order to protect the GMPLS-TE-STD-MIB module from changes (in particular, extensions) to the range of enumerations supported by the signaling Nadeau & Farrel Standards Track [Page 5] RFC 4802 GMPLS TE MIB February 2007 protocols, these MIB objects use textual conventions with values maintained by IANA. For further details, see the IANA Considerations section of this document. 5.2. gmplsTunnelHopTable The gmplsTunnelHopTable is used to indicate additional parameters for the hops, strict or loose, of a GMPLS tunnel defined in the gmplsTunnelTable, when it is established using signaling. Multiple tunnels may share hops by pointing to the same entry in this table. 5.3. gmplsTunnelARHopTable The gmplsTunnelARHopTable is used to indicate the actual hops traversed by a tunnel as reported by the signaling protocol after the tunnel is set up. The support of this table is optional since not all GMPLS signaling protocols support this feature. 5.4. gmplsTunnelCHopTable The gmplsTunnelCHopTable lists the actual hops computed by a constraint-based routing algorithm based on the gmplsTunnelHopTable. The support of this table is optional since not all implementations support computation of hop lists using a constraint-based routing protocol. 5.5. gmplsTunnelErrorTable The gmplsTunnelErrorTable provides access to information about the last error that occurred on each tunnel known about by the MIB. It indicates the nature of the error and when and how it was reported, and it can give recovery advice through an admin string. 5.6. gmplsTunnelReversePerfTable The gmplsTunnelReversePerfTable provides additional counters to measure the performance of bidirectional GMPLS tunnels in which packets are visible. It supplements the counters in mplsTunnelPerfTable and augments gmplsTunnelTable. Note that not all counters may be appropriate or available for some types of tunnel. Nadeau & Farrel Standards Track [Page 6] RFC 4802 GMPLS TE MIB February 2007 5.7. Use of 32-bit and 64-bit Counters 64-bit counters are provided in the GMPLS-TE-STD-MIB module for high-speed interfaces where the use of 32-bit counters might be impractical. The requirements on the use of 32-bit and 64-bit counters (copied verbatim from [RFC2863]) are as follows: For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported. 6. Cross-referencing to the gmplsLabelTable The gmplsLabelTable is found in the GMPLS-LABEL-STD-MIB module in [RFC4803] and provides a way to model labels in a GMPLS system where labels might not be simple 32-bit integers. The hop tables in this document (gmplsTunnelHopTable, gmplsTunnelCHopTable, and gmplsTunnelARHopTable) and the segment tables in [RFC3813] (mplsInSegmentTable and mplsOutSegmentTable) contain objects with syntax MplsLabel. MplsLabel (defined in [RFC3811]) is a 32-bit integer that is capable of representing any MPLS Label and most GMPLS Labels. However, some GMPLS Labels are larger than 32 bits and may be of arbitrary length. Furthermore, some labels that may be safely encoded in 32 bits are constructed from multiple sub-fields. Additionally, some GMPLS technologies support the concatenation of individual labels to represent a data flow carried as multiple sub-flows. These GMPLS cases require that something other than a simple 32-bit integer be made available to represent the labels. This is achieved through the gmplsLabelTable contained in the GMPLS-LABEL-STD-MIB [RFC4803]. The tables in this document and [RFC3813] that include objects with syntax MplsLabel also include companion objects that are row pointers. If the row pointer is set to zeroDotZero (0.0), then an object of syntax MplsLabel contains the label encoded as a 32-bit integer. But otherwise the row pointer indicates a row in another MIB table that includes the label. In these cases, the row pointer may indicate a row in the gmplsLabelTable. Nadeau & Farrel Standards Track [Page 7] RFC 4802 GMPLS TE MIB February 2007 This provides both a good way to support legacy systems that implement MPLS-TE-STD-MIB [RFC3812], and a significant simplification in GMPLS systems that are limited to a single, simple label type. Note that gmplsLabelTable supports concatenated labels through the use of a label sub-index (gmplsLabelSubindex). 7. Example of GMPLS Tunnel Setup This section contains an example of which MIB objects should be modified to create a GMPLS tunnel. This example shows a best effort, loosely routed, bidirectional traffic engineered tunnel, which spans two hops of a simple network, uses Generalized Label requests with Lambda encoding, has label recording and shared link layer protection. Note that these objects should be created on the "head- end" LSR. First in the mplsTunnelTable: { mplsTunnelIndex = 1, mplsTunnelInstance = 1, mplsTunnelIngressLSRId = 192.0.2.1, mplsTunnelEgressLSRId = 192.0.2.2, mplsTunnelName = "My first tunnel", mplsTunnelDescr = "Here to there and back again", mplsTunnelIsIf = true(1), mplsTunnelXCPointer = mplsXCIndex.3.0.0.12, mplsTunnelSignallingProto = none(1), mplsTunnelSetupPrio = 0, mplsTunnelHoldingPrio = 0, mplsTunnelSessionAttributes = recordRoute(4), mplsTunnelOwner = snmp(2), mplsTunnelLocalProtectInUse = false(2), mplsTunnelResourcePointer = mplsTunnelResourceIndex.6, mplsTunnelInstancePriority = 1, mplsTunnelHopTableIndex = 1, mplsTunnelPrimaryInstance = 0, mplsTunnelIncludeAnyAffinity = 0, mplsTunnelIncludeAllAffinity = 0, mplsTunnelExcludeAnyAffinity = 0, mplsTunnelPathInUse = 1, mplsTunnelRole = head(1), mplsTunnelRowStatus = createAndWait(5), } Nadeau & Farrel Standards Track [Page 8] RFC 4802 GMPLS TE MIB February 2007 In gmplsTunnelTable(1,1,192.0.2.1,192.0.2.2): { gmplsTunnelUnnumIf = true(1), gmplsTunnelAttributes = labelRecordingRequired(1), gmplsTunnelLSPEncoding = tunnelLspLambda, gmplsTunnelSwitchingType = lsc, gmplsTunnelLinkProtection = shared(2), gmplsTunnelGPid = lambda, gmplsTunnelSecondary = false(2), gmplsTunnelDirection = bidirectional(1) gmplsTunnelPathComp = explicit(2), gmplsTunnelSendPathNotifyRecipientType = ipv4(1), gmplsTunnelSendPathNotifyRecipient = 'C0000201'H, gmplsTunnelAdminStatusFlags = 0, gmplsTunnelExtraParamsPtr = 0.0 } Entries in the mplsTunnelResourceTable, mplsTunnelHopTable, and gmplsTunnelHopTable are created and activated at this time. In mplsTunnelResourceTable: { mplsTunnelResourceIndex = 6, mplsTunnelResourceMaxRate = 0, mplsTunnelResourceMeanRate = 0, mplsTunnelResourceMaxBurstSize = 0, mplsTunnelResourceRowStatus = createAndGo(4) } The next two instances of mplsTunnelHopEntry are used to denote the hops this tunnel will take across the network. The following denotes the beginning of the network, or the first hop in our example. We have used the fictitious LSR identified by "192.0.2.1" as our head-end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex = 1, mplsTunnelPathOptionIndex = 1, mplsTunnelHopIndex = 1, mplsTunnelHopAddrType = ipv4(1), mplsTunnelHopIpv4Addr = 192.0.2.1, mplsTunnelHopIpv4PrefixLen = 9, mplsTunnelHopType = strict(1), mplsTunnelHopRowStatus = createAndWait(5), } Nadeau & Farrel Standards Track [Page 9] RFC 4802 GMPLS TE MIB February 2007 The following denotes the end of the network, or the last hop in our example. We have used the fictitious LSR identified by "192.0.2.2" as our tail-end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex = 1, mplsTunnelPathOptionIndex = 1, mplsTunnelHopIndex = 2, mplsTunnelHopAddrType = ipv4(1), mplsTunnelHopIpv4Addr = 192.0.2.2, mplsTunnelHopIpv4PrefixLen = 9, mplsTunnelHopType = loose(2), mplsTunnelHopRowStatus = createAndGo(4) } Now an associated entry in the gmplsTunnelHopTable is created to provide additional GMPLS hop configuration indicating that the first hop is an unnumbered link using Explicit Forward and Reverse Labels. An entry in the gmplsLabelTable is created first to include the Explicit Label. In gmplsLabelTable: { gmplsLabelInterface = 2, gmplsLabelIndex = 1, gmplsLabelSubindex = 0, gmplsLabelType = gmplsFreeformLabel(3), gmplsLabelFreeform = 0xFEDCBA9876543210 gmplsLabelRowStatus = createAndGo(4) } In gmplsTunnelHopTable(1,1,1): { gmplsTunnelHopLabelStatuses = forwardPresent(0) +reversePresent(1), gmplsTunnelHopExplicitForwardLabelPtr = gmplsLabelTable(2,1,0) gmplsTunnelHopExplicitReverseLabelPtr = gmplsLabelTable(2,1,0) } The first hop is now activated: In mplsTunnelHopTable(1,1,1): { mplsTunnelHopRowStatus = active(1) } Nadeau & Farrel Standards Track [Page 10] RFC 4802 GMPLS TE MIB February 2007 No gmplsTunnelHopEntry is created for the second hop as it contains no special GMPLS features. Finally, the mplsTunnelEntry is activated: In mplsTunnelTable(1,1,192.0.2.1,192.0.2.2) { mplsTunnelRowStatus = active(1) } 8. GMPLS Traffic Engineering MIB Module This MIB module makes reference to the following documents: [RFC2205], [RFC2578], [RFC2579], [RFC2580], [RFC3209], [RFC3411], [RFC3471], [RFC3473], [RFC3477], [RFC3812], [RFC4001], and [RFC4202]. GMPLS-TE-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32, Counter64, zeroDotZero, Gauge32 FROM SNMPv2-SMI -- RFC 2578 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580 TruthValue, TimeStamp, RowPointer FROM SNMPv2-TC -- RFC 2579 InetAddress, InetAddressType FROM INET-ADDRESS-MIB -- RFC 4001 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId, mplsTunnelHopListIndex, mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex, mplsTunnelARHopListIndex, mplsTunnelARHopIndex, mplsTunnelCHopListIndex, mplsTunnelCHopIndex, mplsTunnelEntry, mplsTunnelAdminStatus, mplsTunnelOperStatus, mplsTunnelGroup, mplsTunnelScalarGroup FROM MPLS-TE-STD-MIB -- RFC3812 IANAGmplsLSPEncodingTypeTC, IANAGmplsSwitchingTypeTC, IANAGmplsGeneralizedPidTC, IANAGmplsAdminStatusInformationTC FROM IANA-GMPLS-TC-MIB mplsStdMIB FROM MPLS-TC-STD-MIB -- RFC 3811 ; Nadeau & Farrel Standards Track [Page 11] RFC 4802 GMPLS TE MIB February 2007 gmplsTeStdMIB MODULE-IDENTITY LAST-UPDATED "200702270000Z" -- 27 February 2007 00:00:00 GMT ORGANIZATION "IETF Common Control and Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Comments about this document should be emailed directly to the CCAMP working group mailing list at ccamp@ops.ietf.org." DESCRIPTION "Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4802; see the RFC itself for full legal notices. This MIB module contains managed object definitions for GMPLS Traffic Engineering (TE) as defined in: 1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003. 2. Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003. " REVISION "200702270000Z" -- 27 February 2007 00:00:00 GMT DESCRIPTION "Initial version issued as part of RFC 4802." ::= { mplsStdMIB 13 } gmplsTeNotifications OBJECT IDENTIFIER ::= { gmplsTeStdMIB 0 } gmplsTeScalars OBJECT IDENTIFIER ::= { gmplsTeStdMIB 1 } gmplsTeObjects OBJECT IDENTIFIER ::= { gmplsTeStdMIB 2 } gmplsTeConformance OBJECT IDENTIFIER ::= { gmplsTeStdMIB 3 } gmplsTunnelsConfigured OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of GMPLS tunnels configured on this device. A GMPLS Nadeau & Farrel Standards Track [Page 12] RFC 4802 GMPLS TE MIB February 2007 tunnel is considered configured if an entry for the tunnel exists in the gmplsTunnelTable and the associated mplsTunnelRowStatus is active(1)." ::= { gmplsTeScalars 1 } gmplsTunnelsActive OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of GMPLS tunnels active on this device. A GMPLS tunnel is considered active if there is an entry in the gmplsTunnelTable and the associated mplsTunnelOperStatus for the tunnel is up(1)." ::= { gmplsTeScalars 2 } gmplsTunnelTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelTable sparsely extends the mplsTunnelTable of MPLS-TE-STD-MIB. It allows GMPLS tunnels to be created between an LSR and a remote endpoint, and existing tunnels to be reconfigured or removed. Note that only point-to-point tunnel segments are supported, although multipoint-to-point and point-to-multipoint connections are supported by an LSR acting as a cross-connect. Each tunnel can thus have one out-segment originating at this LSR and/or one in-segment terminating at this LSR. The row status of an entry in this table is controlled by the mplsTunnelRowStatus in the corresponding entry in the mplsTunnelTable. When the corresponding mplsTunnelRowStatus has value active(1), a row in this table may not be created or modified. The exception to this rule is the gmplsTunnelAdminStatusInformation object, which can be modified while the tunnel is active." REFERENCE "1. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812." ::= { gmplsTeObjects 1 } Nadeau & Farrel Standards Track [Page 13] RFC 4802 GMPLS TE MIB February 2007 gmplsTunnelEntry OBJECT-TYPE SYNTAX GmplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table in association with the corresponding entry in the mplsTunnelTable represents a GMPLS tunnel. An entry can be created by a network administrator via SNMP SET commands, or in response to signaling protocol events." INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } ::= { gmplsTunnelTable 1 } GmplsTunnelEntry ::= SEQUENCE { gmplsTunnelUnnumIf TruthValue, gmplsTunnelAttributes BITS, gmplsTunnelLSPEncoding IANAGmplsLSPEncodingTypeTC, gmplsTunnelSwitchingType IANAGmplsSwitchingTypeTC, gmplsTunnelLinkProtection BITS, gmplsTunnelGPid IANAGmplsGeneralizedPidTC, gmplsTunnelSecondary TruthValue, gmplsTunnelDirection INTEGER, gmplsTunnelPathComp INTEGER, gmplsTunnelUpstreamNotifyRecipientType InetAddressType, gmplsTunnelUpstreamNotifyRecipient InetAddress, gmplsTunnelSendResvNotifyRecipientType InetAddressType, gmplsTunnelSendResvNotifyRecipient InetAddress, gmplsTunnelDownstreamNotifyRecipientType InetAddressType, gmplsTunnelDownstreamNotifyRecipient InetAddress, gmplsTunnelSendPathNotifyRecipientType InetAddressType, gmplsTunnelSendPathNotifyRecipient InetAddress, gmplsTunnelAdminStatusFlags IANAGmplsAdminStatusInformationTC, gmplsTunnelExtraParamsPtr RowPointer } gmplsTunnelUnnumIf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether or not this tunnel corresponds to an unnumbered interface represented by an entry in the interfaces group table (the ifTable) with ifType set to mpls(166). Nadeau & Farrel Standards Track [Page 14] RFC 4802 GMPLS TE MIB February 2007 This object is only used if mplsTunnelIsIf is set to 'true'. If both this object and the mplsTunnelIsIf object are set to 'true', the originating LSR adds an LSP_TUNNEL_INTERFACE_ID object to the outgoing Path message. This object contains information that is only used by the terminating LSR." REFERENCE "1. Signalling Unnumbered Links in RSVP-TE, RFC 3477." DEFVAL { false } ::= { gmplsTunnelEntry 1 } gmplsTunnelAttributes OBJECT-TYPE SYNTAX BITS { labelRecordingDesired(0) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bitmask indicates optional parameters for this tunnel. These bits should be taken in addition to those defined in mplsTunnelSessionAttributes in order to determine the full set of options to be signaled (for example SESSION_ATTRIBUTES flags in RSVP-TE). The following describes these bitfields: labelRecordingDesired This flag is set to indicate that label information should be included when doing a route record. This bit is not valid unless the recordRoute bit is set." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, sections 4.4.3, 4.7.1, and 4.7.2." DEFVAL { { } } ::= { gmplsTunnelEntry 2 } gmplsTunnelLSPEncoding OBJECT-TYPE SYNTAX IANAGmplsLSPEncodingTypeTC MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the encoding of the LSP being requested. A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling is not in use. Some objects in this MIB module may be of use for MPLS signaling extensions that do not use GMPLS signaling. By setting this object to 'tunnelLspNotGmpls', an application may Nadeau & Farrel Standards Track [Page 15] RFC 4802 GMPLS TE MIB February 2007 indicate that only those objects meaningful in MPLS should be examined. The values to use are defined in the TEXTUAL-CONVENTION IANAGmplsLSPEncodingTypeTC found in the IANA-GMPLS-TC-MIB module." DEFVAL { tunnelLspNotGmpls } ::= { gmplsTunnelEntry 3 } gmplsTunnelSwitchingType OBJECT-TYPE SYNTAX IANAGmplsSwitchingTypeTC MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. The values to use are defined in the TEXTUAL-CONVENTION IANAGmplsSwitchingTypeTC found in the IANA-GMPLS-TC-MIB module. This object is only meaningful if gmplsTunnelLSPEncodingType is not set to 'tunnelLspNotGmpls'." DEFVAL { unknown } ::= { gmplsTunnelEntry 4 } gmplsTunnelLinkProtection OBJECT-TYPE SYNTAX BITS { extraTraffic(0), unprotected(1), shared(2), dedicatedOneToOne(3), dedicatedOnePlusOne(4), enhanced(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bitmask indicates the level of link protection required. A value of zero (no bits set) indicates that any protection may be used. The following describes these bitfields: extraTraffic This flag is set to indicate that the LSP should use links that are protecting other (primary) traffic. Such LSPs may be preempted when the links carrying the (primary) traffic being protected fail. Nadeau & Farrel Standards Track [Page 16] RFC 4802 GMPLS TE MIB February 2007 unprotected This flag is set to indicate that the LSP should not use any link layer protection. shared This flag is set to indicate that a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP. dedicatedOneToOne This flag is set to indicate that a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP. dedicatedOnePlusOne This flag is set to indicate that a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP. enhanced This flag is set to indicate that a protection scheme that is more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING. This object is only meaningful if gmplsTunnelLSPEncoding is not set to 'tunnelLspNotGmpls'." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 7.1." DEFVAL { { } } ::= { gmplsTunnelEntry 5 } gmplsTunnelGPid OBJECT-TYPE SYNTAX IANAGmplsGeneralizedPidTC MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the payload carried by the LSP. It is only required when GMPLS will be used for this LSP. The values to use are defined in the TEXTUAL-CONVENTION IANAGmplsGeneralizedPidTC found in the IANA-GMPLS-TC-MIB module. This object is only meaningful if gmplsTunnelLSPEncoding is not set to 'tunnelLspNotGmpls'." DEFVAL { unknown } ::= { gmplsTunnelEntry 6 } Nadeau & Farrel Standards Track [Page 17] RFC 4802 GMPLS TE MIB February 2007 gmplsTunnelSecondary OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates that the requested LSP is a secondary LSP. This object is only meaningful if gmplsTunnelLSPEncoding is not set to 'tunnelLspNotGmpls'." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 7.1." DEFVAL { false } ::= { gmplsTunnelEntry 7 } gmplsTunnelDirection OBJECT-TYPE SYNTAX INTEGER { forward(0), bidirectional(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Whether this tunnel carries forward data only (is unidirectional) or is bidirectional. Values of this object other than 'forward' are meaningful only if gmplsTunnelLSPEncoding is not set to 'tunnelLspNotGmpls'." DEFVAL { forward } ::= { gmplsTunnelEntry 8 } gmplsTunnelPathComp OBJECT-TYPE SYNTAX INTEGER { dynamicFull(1), -- CSPF fully computed explicit(2), -- fully specified path dynamicPartial(3) -- CSPF partially computed } MAX-ACCESS read-create STATUS current DESCRIPTION "This value instructs the source node on how to perform path computation on the explicit route specified by the associated entries in the gmplsTunnelHopTable. dynamicFull The user specifies at least the source and destination of the path and expects that the Constrained Nadeau & Farrel Standards Track [Page 18] RFC 4802 GMPLS TE MIB February 2007 Shortest Path First (CSPF) will calculate the remainder of the path. explicit The user specifies the entire path for the tunnel to take. This path may contain strict or loose hops. Evaluation of the explicit route will be performed hop by hop through the network. dynamicPartial The user specifies at least the source and destination of the path and expects that the CSPF will calculate the remainder of the path. The path computed by CSPF is allowed to be only partially computed allowing the remainder of the path to be filled in across the network. When an entry is present in the gmplsTunnelTable for a tunnel, gmplsTunnelPathComp MUST be used and any corresponding mplsTunnelHopEntryPathComp object in the mplsTunnelHopTable MUST be ignored and SHOULD not be set. mplsTunnelHopTable and mplsTunnelHopEntryPathComp are part of MPLS-TE-STD-MIB. This object should be ignored if the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls'." REFERENCE "1. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812." DEFVAL { dynamicFull } ::= { gmplsTunnelEntry 9 } gmplsTunnelUpstreamNotifyRecipientType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to aid in interpretation of gmplsTunnelUpstreamNotifyRecipient." DEFVAL { unknown } ::= { gmplsTunnelEntry 10 } gmplsTunnelUpstreamNotifyRecipient OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION Nadeau & Farrel Standards Track [Page 19] RFC 4802 GMPLS TE MIB February 2007 "Indicates the address of the upstream recipient for Notify messages relating to this tunnel and issued by this LSR. This information is typically received from an upstream LSR in a Path message. This object is only valid when signaling a tunnel using RSVP. It is also not valid at the head end of a tunnel since there are no upstream LSRs to which to send a Notify message. This object is interpreted in the context of the value of gmplsTunnelUpstreamNotifyRecipientType. If this object is set to 0, the value of gmplsTunnelUpstreamNotifyRecipientType MUST be set to unknown(0)." REFERENCE "1. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 4.2. " DEFVAL { '00000000'H } -- 0.0.0.0 ::= { gmplsTunnelEntry 11 } gmplsTunnelSendResvNotifyRecipientType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to aid in interpretation of gmplsTunnelSendResvNotifyRecipient." DEFVAL { unknown } ::= { gmplsTunnelEntry 12 } gmplsTunnelSendResvNotifyRecipient OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates to an upstream LSR the address to which it should send downstream Notify messages relating to this tunnel. This object is only valid when signaling a tunnel using RSVP. It is also not valid at the head end of the tunnel since no Resv messages are sent from that LSR for this tunnel. If set to 0, no Notify Request object will be included in the outgoing Resv messages. This object is interpreted in the context of the value of gmplsTunnelSendResvNotifyRecipientType. If this object is set to Nadeau & Farrel Standards Track [Page 20] RFC 4802 GMPLS TE MIB February 2007 0, the value of gmplsTunnelSendResvNotifyRecipientType MUST be set to unknown(0)." REFERENCE "1. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 4.2. " DEFVAL { '00000000'H } -- 0.0.0.0 ::= { gmplsTunnelEntry 13 } gmplsTunnelDownstreamNotifyRecipientType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to aid in interpretation of gmplsTunnelDownstreamNotifyRecipient." DEFVAL { unknown } ::= { gmplsTunnelEntry 14 } gmplsTunnelDownstreamNotifyRecipient OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the address of the downstream recipient for Notify messages relating to this tunnel and issued by this LSR. This information is typically received from an upstream LSR in a Resv message. This object is only valid when signaling a tunnel using RSVP. It is also not valid at the tail end of a tunnel since there are no downstream LSRs to which to send a Notify message. This object is interpreted in the context of the value of gmplsTunnelDownstreamNotifyRecipientType. If this object is set to 0, the value of gmplsTunnelDownstreamNotifyRecipientType MUST be set to unknown(0)." REFERENCE "1. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 4.2. " DEFVAL { '00000000'H } -- 0.0.0.0 ::= { gmplsTunnelEntry 15 } gmplsTunnelSendPathNotifyRecipientType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION Nadeau & Farrel Standards Track [Page 21] RFC 4802 GMPLS TE MIB February 2007 "This object is used to aid in interpretation of gmplsTunnelSendPathNotifyRecipient." DEFVAL { unknown } ::= { gmplsTunnelEntry 16 } gmplsTunnelSendPathNotifyRecipient OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates to a downstream LSR the address to which it should send upstream Notify messages relating to this tunnel. This object is only valid when signaling a tunnel using RSVP. It is also not valid at the tail end of the tunnel since no Path messages are sent from that LSR for this tunnel. If set to 0, no Notify Request object will be included in the outgoing Path messages. This object is interpreted in the context of the value of gmplsTunnelSendPathNotifyRecipientType. If this object is set to 0, the value of gmplsTunnelSendPathNotifyRecipientType MUST be set to unknown(0)." REFERENCE "1. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 4.2. " DEFVAL { '00000000'H } -- 0.0.0.0 ::= { gmplsTunnelEntry 17 } gmplsTunnelAdminStatusFlags OBJECT-TYPE SYNTAX IANAGmplsAdminStatusInformationTC MAX-ACCESS read-create STATUS current DESCRIPTION "Determines the setting of the Admin Status flags in the Admin Status object or TLV, as described in RFC 3471. Setting this field to a non-zero value will result in the inclusion of the Admin Status object on signaling messages. The values to use are defined in the TEXTUAL-CONVENTION IANAGmplsAdminStatusInformationTC found in the IANA-GMPLS-TC-MIB module. This value of this object can be modified when the corresponding mplsTunnelRowStatus and mplsTunnelAdminStatus is active(1). By doing so, a new signaling message will be Nadeau & Farrel Standards Track [Page 22] RFC 4802 GMPLS TE MIB February 2007 triggered including the requested Admin Status object or TLV." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 8." DEFVAL { { } } ::= { gmplsTunnelEntry 18 } gmplsTunnelExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Some tunnels will run over transports that can usefully support technology-specific additional parameters (for example, Synchronous Optical Network (SONET) resource usage). Such parameters can be supplied in an external table and referenced from here. A value of zeroDotzero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::= { gmplsTunnelEntry 19 } gmplsTunnelHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelHopTable sparsely extends the mplsTunnelHopTable of MPLS-TE-STD-MIB. It is used to indicate the Explicit Labels to be used in an explicit path for a GMPLS tunnel defined in the mplsTunnelTable and gmplsTunnelTable, when it is established using signaling. It does not insert new hops, but does define new values for hops defined in the mplsTunnelHopTable. Each row in this table is indexed by the same indexes as in the mplsTunnelHopTable. It is acceptable for some rows in the mplsTunnelHopTable to have corresponding entries in this table and some to have no corresponding entry in this table. The storage type for this entry is given by the value of mplsTunnelHopStorageType in the corresponding entry in the mplsTunnelHopTable. The row status of an entry in this table is controlled by mplsTunnelHopRowStatus in the corresponding entry in the mplsTunnelHopTable. That is, it is not permitted to create a row Nadeau & Farrel Standards Track [Page 23] RFC 4802 GMPLS TE MIB February 2007 in this table, or to modify an existing row, when the corresponding mplsTunnelHopRowStatus has the value active(1)." REFERENCE "1. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. " ::= { gmplsTeObjects 2 } gmplsTunnelHopEntry OBJECT-TYPE SYNTAX GmplsTunnelHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents additions to a tunnel hop defined in mplsTunnelHopEntry. At an ingress to a tunnel, an entry in this table is created by a network administrator for an ERLSP to be set up by a signaling protocol. At transit and egress nodes, an entry in this table may be used to represent the explicit path instructions received using the signaling protocol." INDEX { mplsTunnelHopListIndex, mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex } ::= { gmplsTunnelHopTable 1 } GmplsTunnelHopEntry ::= SEQUENCE { gmplsTunnelHopLabelStatuses BITS, gmplsTunnelHopExplicitForwardLabel Unsigned32, gmplsTunnelHopExplicitForwardLabelPtr RowPointer, gmplsTunnelHopExplicitReverseLabel Unsigned32, gmplsTunnelHopExplicitReverseLabelPtr RowPointer } gmplsTunnelHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent(0), reversePresent(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence of labels indicated by the gmplsTunnelHopExplicitForwardLabel or gmplsTunnelHopExplicitForwardLabelPtr, and gmplsTunnelHopExplicitReverseLabel or Nadeau & Farrel Standards Track [Page 24] RFC 4802 GMPLS TE MIB February 2007 gmplsTunnelHopExplicitReverseLabelPtr objects. For the Present bits, a set bit indicates that a label is present for this hop in the route. This allows zero to be a valid label value." DEFVAL { { } } ::= { gmplsTunnelHopEntry 1 } gmplsTunnelHopExplicitForwardLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "If gmplsTunnelHopLabelStatuses object indicates that a Forward Label is present and gmplsTunnelHopExplicitForwardLabelPtr contains the value zeroDotZero, then the label to use on this hop is represented by the value of this object." ::= { gmplsTunnelHopEntry 2 } gmplsTunnelHopExplicitForwardLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the gmplsTunnelHopLabelStatuses object indicates that a Forward Label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable of GMPLS-LABEL-STD-MIB) that contains the label to use on this hop in the forward direction. If the gmplsTunnelHopLabelStatuses object indicates that a Forward Label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelHopExplicitForwardLabel object." DEFVAL { zeroDotZero } ::= { gmplsTunnelHopEntry 3 } gmplsTunnelHopExplicitReverseLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "If the gmplsTunnelHopLabelStatuses object indicates that a Reverse Label is present and gmplsTunnelHopExplicitReverseLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in this object encoded as a 32-bit integer." ::= { gmplsTunnelHopEntry 4 } Nadeau & Farrel Standards Track [Page 25] RFC 4802 GMPLS TE MIB February 2007 gmplsTunnelHopExplicitReverseLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the gmplsTunnelHopLabelStatuses object indicates that a Reverse Label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable of GMPLS-LABEL-STD-MIB) that contains the label to use on this hop in the reverse direction. If the gmplsTunnelHopLabelStatuses object indicates that a Reverse Label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelHopExplicitReverseLabel object." DEFVAL { zeroDotZero } ::= { gmplsTunnelHopEntry 5 } gmplsTunnelARHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelARHopTable sparsely extends the mplsTunnelARHopTable of MPLS-TE-STD-MIB. It is used to indicate the labels currently in use for a GMPLS tunnel defined in the mplsTunnelTable and gmplsTunnelTable, as reported by the signaling protocol. It does not insert new hops, but does define new values for hops defined in the mplsTunnelARHopTable. Each row in this table is indexed by the same indexes as in the mplsTunnelARHopTable. It is acceptable for some rows in the mplsTunnelARHopTable to have corresponding entries in this table and some to have no corresponding entry in this table. Note that since the information necessary to build entries within this table is not provided by some signaling protocols and might not be returned in all cases of other signaling protocols, implementation of this table and the mplsTunnelARHopTable is optional. Furthermore, since the information in this table is actually provided by the signaling protocol after the path has been set up, the entries in this table are provided only for observation, and hence, all variables in this table are accessible exclusively as read-only." REFERENCE "1. Extensions to RSVP for LSP Tunnels, RFC 3209. Nadeau & Farrel Standards Track [Page 26] RFC 4802 GMPLS TE MIB February 2007 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812." ::= { gmplsTeObjects 3 } gmplsTunnelARHopEntry OBJECT-TYPE SYNTAX GmplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents additions to a tunnel hop visible in mplsTunnelARHopEntry. An entry is created by the signaling protocol for a signaled ERLSP set up by the signaling protocol. At any node on the LSP (ingress, transit, or egress), this table and the mplsTunnelARHopTable (if the tables are supported and if the signaling protocol is recording actual route information) contain the actual route of the whole tunnel. If the signaling protocol is not recording the actual route, this table MAY report the information from the gmplsTunnelHopTable or the gmplsTunnelCHopTable. Note that the recording of actual labels is distinct from the recording of the actual route in some signaling protocols. This feature is enabled using the gmplsTunnelAttributes object." INDEX { mplsTunnelARHopListIndex, mplsTunnelARHopIndex } ::= { gmplsTunnelARHopTable 1 } GmplsTunnelARHopEntry ::= SEQUENCE { gmplsTunnelARHopLabelStatuses BITS, gmplsTunnelARHopExplicitForwardLabel Unsigned32, gmplsTunnelARHopExplicitForwardLabelPtr RowPointer, gmplsTunnelARHopExplicitReverseLabel Unsigned32, gmplsTunnelARHopExplicitReverseLabelPtr RowPointer, gmplsTunnelARHopProtection BITS } gmplsTunnelARHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent(0), reversePresent(1), forwardGlobal(2), reverseGlobal(3) } Nadeau & Farrel Standards Track [Page 27] RFC 4802 GMPLS TE MIB February 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence and status of labels indicated by the gmplsTunnelARHopExplicitForwardLabel or gmplsTunnelARHopExplicitForwardLabelPtr, and gmplsTunnelARHopExplicitReverseLabel or gmplsTunnelARHopExplicitReverseLabelPtr objects. For the Present bits, a set bit indicates that a label is present for this hop in the route. For the Global bits, a set bit indicates that the label comes from the Global Label Space; a clear bit indicates that this is a Per-Interface label. A Global bit only has meaning if the corresponding Present bit is set." ::= { gmplsTunnelARHopEntry 1 } gmplsTunnelARHopExplicitForwardLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a Forward Label is present and gmplsTunnelARHopExplicitForwardLabelPtr contains the value zeroDotZero, then the label in use on this hop is found in this object encoded as a 32-bit integer." ::= { gmplsTunnelARHopEntry 2 } gmplsTunnelARHopExplicitForwardLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a Forward Label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable of GMPLS-LABEL-STD-MIB) that contains the label in use on this hop in the forward direction. If the gmplsTunnelARHopLabelStatuses object indicates that a Forward Label is present and this object contains the value zeroDotZero, then the label in use on this hop is found in the gmplsTunnelARHopExplicitForwardLabel object." ::= { gmplsTunnelARHopEntry 3 } Nadeau & Farrel Standards Track [Page 28] RFC 4802 GMPLS TE MIB February 2007 gmplsTunnelARHopExplicitReverseLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a Reverse Label is present and gmplsTunnelARHopExplicitReverseLabelPtr contains the value zeroDotZero, then the label in use on this hop is found in this object encoded as a 32-bit integer." ::= { gmplsTunnelARHopEntry 4 } gmplsTunnelARHopExplicitReverseLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a Reverse Label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable of GMPLS-LABEL-STD-MIB) that contains the label in use on this hop in the reverse direction. If the gmplsTunnelARHopLabelStatuses object indicates that a Reverse Label is present and this object contains the value zeroDotZero, then the label in use on this hop is found in the gmplsTunnelARHopExplicitReverseLabel object." ::= { gmplsTunnelARHopEntry 5 } gmplsTunnelARHopProtection OBJECT-TYPE SYNTAX BITS { localAvailable(0), localInUse(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Availability and usage of protection on the reported link. localAvailable This flag is set to indicate that the link downstream of this node is protected via a local repair mechanism. localInUse This flag is set to indicate that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over)." REFERENCE Nadeau & Farrel Standards Track [Page 29] RFC 4802 GMPLS TE MIB February 2007 "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, section 4.4.1." ::= { gmplsTunnelARHopEntry 6 } gmplsTunnelCHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelCHopTable sparsely extends the mplsTunnelCHopTable of MPLS-TE-STD-MIB. It is used to indicate additional information about the hops of a GMPLS tunnel defined in the mplsTunnelTable and gmplsTunnelTable, as computed by a constraint-based routing protocol, based on the mplsTunnelHopTable and the gmplsTunnelHopTable. Each row in this table is indexed by the same indexes as in the mplsTunnelCHopTable. It is acceptable for some rows in the mplsTunnelCHopTable to have corresponding entries in this table and some to have no corresponding entry in this table. Please note that since the information necessary to build entries within this table may not be supported by some LSRs, implementation of this table is optional. Furthermore, since the information in this table is actually provided by a path computation component after the path has been computed, the entries in this table are provided only for observation, and hence, all objects in this table are accessible exclusively as read-only." REFERENCE "1. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." ::= { gmplsTeObjects 4 } gmplsTunnelCHopEntry OBJECT-TYPE SYNTAX GmplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents additions to a computed tunnel hop visible in mplsTunnelCHopEntry. An entry is created by a path computation component based on the hops specified in the corresponding mplsTunnelHopTable and gmplsTunnelHopTable. At a transit LSR, this table (if the table is supported) MAY contain the path computed by a path computation engine on (or on Nadeau & Farrel Standards Track [Page 30] RFC 4802 GMPLS TE MIB February 2007 behalf of) the transit LSR." INDEX { mplsTunnelCHopListIndex, mplsTunnelCHopIndex } ::= { gmplsTunnelCHopTable 1 } GmplsTunnelCHopEntry ::= SEQUENCE { gmplsTunnelCHopLabelStatuses BITS, gmplsTunnelCHopExplicitForwardLabel Unsigned32, gmplsTunnelCHopExplicitForwardLabelPtr RowPointer, gmplsTunnelCHopExplicitReverseLabel Unsigned32, gmplsTunnelCHopExplicitReverseLabelPtr RowPointer } gmplsTunnelCHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent(0), reversePresent(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence of labels indicated by the gmplsTunnelCHopExplicitForwardLabel or gmplsTunnelCHopExplicitForwardLabelPtr and gmplsTunnelCHopExplicitReverseLabel or gmplsTunnelCHopExplicitReverseLabelPtr objects. A set bit indicates that a label is present for this hop in the route, thus allowing zero to be a valid label value." ::= { gmplsTunnelCHopEntry 1 } gmplsTunnelCHopExplicitForwardLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a Forward Label is present and gmplsTunnelCHopExplicitForwardLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in this object encoded as a 32-bit integer." ::= { gmplsTunnelCHopEntry 2 } gmplsTunnelCHopExplicitForwardLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only Nadeau & Farrel Standards Track [Page 31] RFC 4802 GMPLS TE MIB February 2007 STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a Forward Label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable of GMPLS-LABEL-STD-MIB) that contains the label to use on this hop in the forward direction. If the gmplsTunnelCHopLabelStatuses object indicates that a Forward Label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelCHopExplicitForwardLabel object." ::= { gmplsTunnelCHopEntry 3 } gmplsTunnelCHopExplicitReverseLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a Reverse Label is present and gmplsTunnelCHopExplicitReverseLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in this object encoded as a 32-bit integer." ::= { gmplsTunnelCHopEntry 4 } gmplsTunnelCHopExplicitReverseLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a Reverse Label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable of GMPLS-LABEL-STD-MIB) that contains the label to use on this hop in the reverse direction. If the gmplsTunnelCHopLabelStatuses object indicates that a Reverse Label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelCHopExplicitReverseLabel object." ::= { gmplsTunnelCHopEntry 5 } gmplsTunnelReversePerfTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelReversePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Nadeau & Farrel Standards Track [Page 32] RFC 4802 GMPLS TE MIB February 2007 "This table augments the gmplsTunnelTable to provide per-tunnel packet performance information for the reverse direction of a bidirectional tunnel. It can be seen as supplementing the mplsTunnelPerfTable, which augments the mplsTunnelTable. For links that do not transport packets, these packet counters cannot be maintained. For such links, attempts to read the objects in this table will return noSuchInstance. A tunnel can be known to be bidirectional by inspecting the gmplsTunnelDirection object." REFERENCE "1. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812." ::= { gmplsTeObjects 5 } gmplsTunnelReversePerfEntry OBJECT-TYPE SYNTAX GmplsTunnelReversePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the LSR for every bidirectional GMPLS tunnel where packets are visible to the LSR." AUGMENTS { gmplsTunnelEntry } ::= { gmplsTunnelReversePerfTable 1 } GmplsTunnelReversePerfEntry ::= SEQUENCE { gmplsTunnelReversePerfPackets Counter32, gmplsTunnelReversePerfHCPackets Counter64, gmplsTunnelReversePerfErrors Counter32, gmplsTunnelReversePerfBytes Counter32, gmplsTunnelReversePerfHCBytes Counter64 } gmplsTunnelReversePerfPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets forwarded on the tunnel in the reverse direction if it is bidirectional. This object represents the 32-bit value of the least significant part of the 64-bit value if both gmplsTunnelReversePerfHCPackets and this object are returned. Nadeau & Farrel Standards Track [Page 33] RFC 4802 GMPLS TE MIB February 2007 For links that do not transport packets, this packet counter cannot be maintained. For such links, this value will return noSuchInstance." ::= { gmplsTunnelReversePerfEntry 1 } gmplsTunnelReversePerfHCPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of packets forwarded on the tunnel in the reverse direction if it is bidirectional. For links that do not transport packets, this packet counter cannot be maintained. For such links, this value will return noSuchInstance." ::= { gmplsTunnelReversePerfEntry 2 } gmplsTunnelReversePerfErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of errored packets received on the tunnel in the reverse direction if it is bidirectional. For links that do not transport packets, this packet counter cannot be maintained. For such links, this value will return noSuchInstance." ::= { gmplsTunnelReversePerfEntry 3 } gmplsTunnelReversePerfBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bytes forwarded on the tunnel in the reverse direction if it is bidirectional. This object represents the 32-bit value of the least significant part of the 64-bit value if both gmplsTunnelReversePerfHCBytes and this object are returned. For links that do not transport packets, this packet counter cannot be maintained. For such links, this value will return noSuchInstance." ::= { gmplsTunnelReversePerfEntry 4 } gmplsTunnelReversePerfHCBytes OBJECT-TYPE SYNTAX Counter64 Nadeau & Farrel Standards Track [Page 34] RFC 4802 GMPLS TE MIB February 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of bytes forwarded on the tunnel in the reverse direction if it is bidirectional. For links that do not transport packets, this packet counter cannot be maintained. For such links, this value will return noSuchInstance." ::= { gmplsTunnelReversePerfEntry 5 } gmplsTunnelErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table augments the mplsTunnelTable. This table provides per-tunnel information about errors. Errors may be detected locally or reported through the signaling protocol. Error reporting is not exclusive to GMPLS, and this table may be applied in MPLS systems. Entries in this table are not persistent over system resets or re-initializations of the management system." REFERENCE "1. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812." ::= { gmplsTeObjects 6 } gmplsTunnelErrorEntry OBJECT-TYPE SYNTAX GmplsTunnelErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the LSR for every tunnel where error information is visible to the LSR. Note that systems that read the objects in this table one at a time and do not perform atomic operations to read entire instantiated table rows at once, should, for each conceptual column with valid data, read gmplsTunnelErrorLastTime prior to the other objects in the row and again subsequent to reading the last object of the row. They should verify that the value of gmplsTunnelErrorLastTime did not change and thereby ensure that all data read belongs to the same error event." Nadeau & Farrel Standards Track [Page 35] RFC 4802 GMPLS TE MIB February 2007 AUGMENTS { mplsTunnelEntry } ::= { gmplsTunnelErrorTable 1 } GmplsTunnelErrorEntry ::= SEQUENCE { gmplsTunnelErrorLastErrorType INTEGER, gmplsTunnelErrorLastTime TimeStamp, gmplsTunnelErrorReporterType InetAddressType, gmplsTunnelErrorReporter InetAddress, gmplsTunnelErrorCode Unsigned32, gmplsTunnelErrorSubcode Unsigned32, gmplsTunnelErrorTLVs OCTET STRING, gmplsTunnelErrorHelpString SnmpAdminString } gmplsTunnelErrorLastErrorType OBJECT-TYPE SYNTAX INTEGER { noError(0), unknown(1), protocol(2), pathComputation(3), localConfiguration(4), localResources(5), localOther(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The nature of the last error. Provides interpretation context for gmplsTunnelErrorProtocolCode and gmplsTunnelErrorProtocolSubcode. A value of noError(0) shows that there is no error associated with this tunnel and means that the other objects in this table entry (conceptual row) have no meaning. A value of unknown(1) shows that there is an error but that no additional information about the cause is known. The error may have been received in a signaled message or generated locally. A value of protocol(2) or pathComputation(3) indicates the cause of an error and identifies an error that has been received through signaling or will itself be signaled. A value of localConfiguration(4), localResources(5) or localOther(6) identifies an error that has been detected by the local node but that will not be reported through signaling." ::= { gmplsTunnelErrorEntry 1 } Nadeau & Farrel Standards Track [Page 36] RFC 4802 GMPLS TE MIB February 2007 gmplsTunnelErrorLastTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last error occurred. This is presented as the value of SysUpTime when the error occurred or was reported to this node. If gmplsTunnelErrorLastErrorType has the value noError(0), then this object is not valid and should be ignored. Note that entries in this table are not persistent over system resets or re-initializations of the management system." ::= { gmplsTunnelErrorEntry 2 } gmplsTunnelErrorReporterType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the error reported. This object is used to aid in interpretation of gmplsTunnelErrorReporter." ::= { gmplsTunnelErrorEntry 3 } gmplsTunnelErrorReporter OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the node reporting the last error, or the address of the resource (such as an interface) associated with the error. If gmplsTunnelErrorLastErrorType has the value noError(0), then this object is not valid and should be ignored. If gmplsTunnelErrorLastErrorType has the value unknown(1), localConfiguration(4), localResources(5), or localOther(6), this object MAY contain a zero value. This object should be interpreted in the context of the value of the object gmplsTunnelErrorReporterType." REFERENCE "1. Textual Conventions for Internet Network Addresses, RFC 4001, section 4, Usage Hints." Nadeau & Farrel Standards Track [Page 37] RFC 4802 GMPLS TE MIB February 2007 ::= { gmplsTunnelErrorEntry 4 } gmplsTunnelErrorCode OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The primary error code associated with the last error. The interpretation of this error code depends on the value of gmplsTunnelErrorLastErrorType. If the value of gmplsTunnelErrorLastErrorType is noError(0), the value of this object should be 0 and should be ignored. If the value of gmplsTunnelErrorLastErrorType is protocol(2), the error should be interpreted in the context of the signaling protocol identified by the mplsTunnelSignallingProto object." REFERENCE "1. Resource ReserVation Protocol -- Version 1 Functional Specification, RFC 2205, section B. 2. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, section 7.3. 3. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 13.1." ::= { gmplsTunnelErrorEntry 5 } gmplsTunnelErrorSubcode OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary error code associated with the last error and the protocol used to signal this tunnel. This value is interpreted in the context of the value of gmplsTunnelErrorCode. If the value of gmplsTunnelErrorLastErrorType is noError(0), the value of this object should be 0 and should be ignored." REFERENCE "1. Resource ReserVation Protocol -- Version 1 Functional Specification, RFC 2205, section B. 2. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, section 7.3. 3. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 13.1. " ::= { gmplsTunnelErrorEntry 6 } gmplsTunnelErrorTLVs OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..65535)) MAX-ACCESS read-only STATUS current Nadeau & Farrel Standards Track [Page 38] RFC 4802 GMPLS TE MIB February 2007 DESCRIPTION "The sequence of interface identifier TLVs reported with the error by the protocol code. The interpretation of the TLVs and the encoding within the protocol are described in the references. A value of zero in the first octet indicates that no TLVs are present." REFERENCE "1. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 8.2." ::= { gmplsTunnelErrorEntry 7 } gmplsTunnelErrorHelpString OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual string containing information about the last error, recovery actions, and support advice. If there is no help string, this object contains a zero length string. If the value of gmplsTunnelErrorLastErrorType is noError(0), this object should contain a zero length string, but may contain a help string indicating that there is no error." ::= { gmplsTunnelErrorEntry 8 } -- -- Notifications -- gmplsTunnelDown NOTIFICATION-TYPE OBJECTS { mplsTunnelAdminStatus, mplsTunnelOperStatus, gmplsTunnelErrorLastErrorType, gmplsTunnelErrorReporterType, gmplsTunnelErrorReporter, gmplsTunnelErrorCode, gmplsTunnelErrorSubcode } STATUS current DESCRIPTION "This notification is generated when an mplsTunnelOperStatus object for a tunnel in the gmplsTunnelTable is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of mplsTunnelOperStatus. The objects in this notification provide additional error information that indicates the reason why the tunnel has Nadeau & Farrel Standards Track [Page 39] RFC 4802 GMPLS TE MIB February 2007 transitioned to down(2). Note that an implementation MUST only issue one of mplsTunnelDown and gmplsTunnelDown for any single event on a single tunnel. If the tunnel has an entry in the gmplsTunnelTable, an implementation SHOULD use gmplsTunnelDown for all tunnel-down events and SHOULD NOT use mplsTunnelDown. This notification is subject to the control of mplsTunnelNotificationEnable. When that object is set to false(2), then the notification must not be issued. Further, this notification is also subject to mplsTunnelNotificationMaxRate. That object indicates the maximum number of notifications issued per second. If events occur more rapidly, the implementation may simply fail to emit some notifications during that period, or may queue them until an appropriate time. The notification rate applies to the sum of all notifications in the MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB modules applied across the whole of the reporting device. mplsTunnelOperStatus, mplsTunnelAdminStatus, mplsTunnelDown, mplsTunnelNotificationEnable, and mplsTunnelNotificationMaxRate objects are found in MPLS-TE-STD-MIB." REFERENCE "1. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), RFC 3812." ::= { gmplsTeNotifications 1 } gmplsTeGroups OBJECT IDENTIFIER ::= { gmplsTeConformance 1 } gmplsTeCompliances OBJECT IDENTIFIER ::= { gmplsTeConformance 2 } -- Compliance requirement for fully compliant implementations. gmplsTeModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for GMPLS-TE-STD-MIB. Such devices can then be monitored and also be configured using this MIB module. The mandatory group has to be implemented by all LSRs that originate, terminate, or act as transit for TE-LSPs/tunnels. In addition, depending on the type of tunnels supported, other Nadeau & Farrel Standards Track [Page 40] RFC 4802 GMPLS TE MIB February 2007 groups become mandatory as explained below." MODULE MPLS-TE-STD-MIB -- The MPLS-TE-STD-MIB, RFC 3812 MANDATORY-GROUPS { mplsTunnelGroup, mplsTunnelScalarGroup } MODULE -- this module MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup } GROUP gmplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices that support signaled tunnel set up, in addition to gmplsTunnelGroup. The following constraints apply: mplsTunnelSignallingProto should be at least read-only returning a value of ldp(2) or rsvp(3)." GROUP gmplsTunnelOptionalGroup DESCRIPTION "Objects in this group are optional." GROUP gmplsTeNotificationGroup DESCRIPTION "This group is mandatory for those implementations that can implement the notifications contained in this group." ::= { gmplsTeCompliances 1 } -- Compliance requirement for read-only compliant implementations. gmplsTeModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-TE-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB module." MODULE -- this module -- The mandatory group has to be implemented by all LSRs that -- originate, terminate, or act as transit for TE-LSPs/tunnels. Nadeau & Farrel Standards Track [Page 41] RFC 4802 GMPLS TE MIB February 2007 -- In addition, depending on the type of tunnels supported, other -- groups become mandatory as explained below. MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup } GROUP gmplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices that support signaled tunnel set up, in addition to gmplsTunnelGroup. The following constraints apply: mplsTunnelSignallingProto should be at least read-only returning a value of ldp(2) or rsvp(3)." GROUP gmplsTunnelOptionalGroup DESCRIPTION "Objects in this group are optional." GROUP gmplsTeNotificationGroup DESCRIPTION "This group is mandatory for those implementations that can implement the notifications contained in this group." OBJECT gmplsTunnelUnnumIf MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelAttributes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelLSPEncoding MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelSwitchingType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelLinkProtection MIN-ACCESS read-only DESCRIPTION Nadeau & Farrel Standards Track [Page 42] RFC 4802 GMPLS TE MIB February 2007 "Write access is not required." OBJECT gmplsTunnelGPid MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelSecondary MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelDirection MIN-ACCESS read-only DESCRIPTION "Only forward(0) is required." OBJECT gmplsTunnelPathComp MIN-ACCESS read-only DESCRIPTION "Only explicit(2) is required." OBJECT gmplsTunnelUpstreamNotifyRecipientType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support is required." OBJECT gmplsTunnelUpstreamNotifyRecipient SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "An implementation is only required to support unknown(0), ipv4(1), and ipv6(2) sizes." OBJECT gmplsTunnelSendResvNotifyRecipientType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support is required." OBJECT gmplsTunnelSendResvNotifyRecipient SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "An implementation is only required to support unknown(0), ipv4(1), and ipv6(2) sizes." OBJECT gmplsTunnelDownstreamNotifyRecipientType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } Nadeau & Farrel Standards Track [Page 43] RFC 4802 GMPLS TE MIB February 2007 MIN-ACCESS read-only DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support is required." OBJECT gmplsTunnelDownstreamNotifyRecipient SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "An implementation is only required to support unknown(0), ipv4(1), and ipv6(2) sizes." OBJECT gmplsTunnelSendPathNotifyRecipientType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support is required." OBJECT gmplsTunnelSendPathNotifyRecipient SYNTAX InetAddress (SIZE(0|4|16)) MIN-ACCESS read-only DESCRIPTION "An implementation is only required to support unknown(0), ipv4(1), and ipv6(2) sizes." OBJECT gmplsTunnelAdminStatusFlags MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelExtraParamsPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsTunnelHopLabelStatuses has max access read-only OBJECT gmplsTunnelHopExplicitForwardLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopExplicitForwardLabelPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopExplicitReverseLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau & Farrel Standards Track [Page 44] RFC 4802 GMPLS TE MIB February 2007 OBJECT gmplsTunnelHopExplicitReverseLabelPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsTunnelARHopTable -- all objects have max access read-only -- gmplsTunnelCHopTable -- all objects have max access read-only -- gmplsTunnelReversePerfTable -- all objects have max access read-only -- gmplsTunnelErrorTable -- all objects have max access read-only OBJECT gmplsTunnelErrorReporterType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support is required." OBJECT gmplsTunnelErrorReporter SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support unknown(0), ipv4(1), and ipv6(2)." ::= { gmplsTeCompliances 2 } gmplsTunnelGroup OBJECT-GROUP OBJECTS { gmplsTunnelDirection, gmplsTunnelReversePerfPackets, gmplsTunnelReversePerfHCPackets, gmplsTunnelReversePerfErrors, gmplsTunnelReversePerfBytes, gmplsTunnelReversePerfHCBytes, gmplsTunnelErrorLastErrorType, gmplsTunnelErrorLastTime, gmplsTunnelErrorReporterType, gmplsTunnelErrorReporter, gmplsTunnelErrorCode, gmplsTunnelErrorSubcode, gmplsTunnelErrorTLVs, gmplsTunnelErrorHelpString, gmplsTunnelUnnumIf } STATUS current DESCRIPTION Nadeau & Farrel Standards Track [Page 45] RFC 4802 GMPLS TE MIB February 2007 "Necessary, but not sufficient, set of objects to implement tunnels. In addition, depending on the type of the tunnels supported (for example, manually configured or signaled, persistent or non-persistent, etc.), the gmplsTunnelSignaledGroup group is mandatory." ::= { gmplsTeGroups 1 } gmplsTunnelSignaledGroup OBJECT-GROUP OBJECTS { gmplsTunnelAttributes, gmplsTunnelLSPEncoding, gmplsTunnelSwitchingType, gmplsTunnelLinkProtection, gmplsTunnelGPid, gmplsTunnelSecondary, gmplsTunnelPathComp, gmplsTunnelUpstreamNotifyRecipientType, gmplsTunnelUpstreamNotifyRecipient, gmplsTunnelSendResvNotifyRecipientType, gmplsTunnelSendResvNotifyRecipient, gmplsTunnelDownstreamNotifyRecipientType, gmplsTunnelDownstreamNotifyRecipient, gmplsTunnelSendPathNotifyRecipientType, gmplsTunnelSendPathNotifyRecipient, gmplsTunnelAdminStatusFlags, gmplsTunnelHopLabelStatuses, gmplsTunnelHopExplicitForwardLabel, gmplsTunnelHopExplicitForwardLabelPtr, gmplsTunnelHopExplicitReverseLabel, gmplsTunnelHopExplicitReverseLabelPtr } STATUS current DESCRIPTION "Objects needed to implement signaled tunnels." ::= { gmplsTeGroups 2 } gmplsTunnelScalarGroup OBJECT-GROUP OBJECTS { gmplsTunnelsConfigured, gmplsTunnelsActive } STATUS current DESCRIPTION "Scalar objects needed to implement MPLS tunnels." ::= { gmplsTeGroups 3 } gmplsTunnelOptionalGroup OBJECT-GROUP OBJECTS { Nadeau & Farrel Standards Track [Page 46] RFC 4802 GMPLS TE MIB February 2007 gmplsTunnelExtraParamsPtr, gmplsTunnelARHopLabelStatuses, gmplsTunnelARHopExplicitForwardLabel, gmplsTunnelARHopExplicitForwardLabelPtr, gmplsTunnelARHopExplicitReverseLabel, gmplsTunnelARHopExplicitReverseLabelPtr, gmplsTunnelARHopProtection, gmplsTunnelCHopLabelStatuses, gmplsTunnelCHopExplicitForwardLabel, gmplsTunnelCHopExplicitForwardLabelPtr, gmplsTunnelCHopExplicitReverseLabel, gmplsTunnelCHopExplicitReverseLabelPtr } STATUS current DESCRIPTION "The objects in this group are optional." ::= { gmplsTeGroups 4 } gmplsTeNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { gmplsTunnelDown } STATUS current DESCRIPTION "Set of notifications implemented in this module. None is mandatory." ::= { gmplsTeGroups 5 } END 9. Security Considerations It is clear that the MIB modules described in this document in association with MPLS-TE-STD-MIB [RFC3812] are potentially useful for monitoring of MPLS and GMPLS tunnels. These MIB modules can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Nadeau & Farrel Standards Track [Page 47] RFC 4802 GMPLS TE MIB February 2007 o the gmplsTunnelTable and gmplsTunnelHopTable collectively contain objects to provision GMPLS tunnels interfaces at their ingress LSRs. Unauthorized write access to objects in these tables could result in disruption of traffic on the network. This is especially true if a tunnel has already been established. Some of the readable objects in these MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the gmplsTunnelTable, gmplsTunnelHopTable, gmplsTunnelARHopTable, gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and gmplsTunnelErrorTable collectively show the tunnel network topology and status. If an administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. Acknowledgments This document is a product of the CCAMP Working Group. This document extends [RFC3812]. The authors would like to express their gratitude to all those who worked on that earlier MIB document. Thanks also to Tony Zinicola and Jeremy Crossen for their valuable contributions during an early implementation, and to Lars Eggert, Nadeau & Farrel Standards Track [Page 48] RFC 4802 GMPLS TE MIB February 2007 Baktha Muralidharan, Tom Petch, Dan Romascanu, Dave Thaler, and Bert Wijnen for their review comments. Special thanks to Joan Cucchiara and Len Nieman for their help with compilation issues. Joan Cucchiara provided a helpful and very thorough MIB Doctor review. 11. IANA Considerations IANA has rooted MIB objects in the MIB modules contained in this document according to the sections below. 11.1. IANA Considerations for GMPLS-TE-STD-MIB IANA has rooted MIB objects in the GMPLS-TE-STD-MIB module contained in this document under the mplsStdMIB subtree. IANA has made the following assignments in the "NETWORK MANAGEMENT PARAMETERS" registry located at http://www.iana.org/assignments/ smi-numbers in table: ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166) Decimal Name References ------- ----- ---------- 13 GMPLS-TE-STD-MIB [RFC4802] In the future, GMPLS-related standards-track MIB modules should be rooted under the mplsStdMIB (sic) subtree. IANA has been requested to manage that namespace in the SMI Numbers registry [RFC3811]. New assignments can only be made via a Standards Action as specified in [RFC2434]. 11.2. Dependence on IANA MIB Modules Three MIB objects in the GMPLS-TE-STD-MIB module defined in this document (gmplsTunnelLSPEncoding, gmplsTunnelSwitchingType, and gmplsTunnelGPid) use textual conventions imported from the IANA- GMPLS-TC-MIB module. The purpose of defining these textual conventions in a separate MIB module is to allow additional values to be defined without having to issue a new version of this document. The Internet Assigned Numbers Authority (IANA) is responsible for the assignment of all Internet numbers; it will administer the values associated with these textual conventions. Nadeau & Farrel Standards Track [Page 49] RFC 4802 GMPLS TE MIB February 2007 The rules for additions or changes to IANA-GMPLS-TC-MIB are outlined in the DESCRIPTION clause associated with its MODULE-IDENTITY statement. The current version of IANA-GMPLS-TC-MIB can be accessed from the IANA home page at: http://www.iana.org/. 11.2.1. IANA-GMPLS-TC-MIB Definition This section provides the base definition of the IANA GMPLS TC MIB module. This MIB module is under the direct control of IANA. Please see the most updated version of this MIB at . This MIB makes reference to the following documents: [RFC2578], [RFC2579], [RFC3471], [RFC3473], [RFC4202], [RFC4328], and [RFC4783]. IANA assigned an OID to the IANA-GMPLS-TC-MIB module specified in this document as { mib-2 152 }. IANA-GMPLS-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC; -- RFC 2579 ianaGmpls MODULE-IDENTITY LAST-UPDATED "200702270000Z" -- 27 February 2007 00:00:00 GMT ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 E-Mail: iana@iana.org" DESCRIPTION "Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC 4802. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html" REVISION "200702270000Z" -- 27 February 2007 00:00:00 GMT DESCRIPTION "Initial version issued as part of RFC 4802." Nadeau & Farrel Standards Track [Page 50] RFC 4802 GMPLS TE MIB February 2007 ::= { mib-2 152 } IANAGmplsLSPEncodingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to represent and control the LSP encoding type of an LSP signaled by a GMPLS signaling protocol. This textual convention is strongly tied to the LSP Encoding Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the LSP Encoding Types sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the LSP Encoding Types sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@iana.org)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.1.1. 2. Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, RFC 4328, section 3.1.1." SYNTAX INTEGER { tunnelLspNotGmpls(0), -- GMPLS is not in use tunnelLspPacket(1), -- Packet tunnelLspEthernet(2), -- Ethernet tunnelLspAnsiEtsiPdh(3), -- PDH -- the value 4 is deprecated tunnelLspSdhSonet(5), -- SDH or SONET -- the value 6 is deprecated tunnelLspDigitalWrapper(7), -- Digital Wrapper tunnelLspLambda(8), -- Lambda tunnelLspFiber(9), -- Fiber -- the value 10 is deprecated tunnelLspFiberChannel(11), -- Fiber Channel Nadeau & Farrel Standards Track [Page 51] RFC 4802 GMPLS TE MIB February 2007 tunnelDigitalPath(12), -- Digital Path tunnelOpticalChannel(13) -- Optical Channel } IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to represent and control the LSP switching type of an LSP signaled by a GMPLS signaling protocol. This textual convention is strongly tied to the Switching Types sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Switching Types sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the Switching Types sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@iana.org)." REFERENCE "1. Routing Extensions in Support of Generalized Multi-Protocol Label Switching, RFC 4202, section 2.4. 2. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.1.1." SYNTAX INTEGER { unknown(0), -- none of the following, or not known psc1(1), -- Packet-Switch-Capable 1 psc2(2), -- Packet-Switch-Capable 2 psc3(3), -- Packet-Switch-Capable 3 psc4(4), -- Packet-Switch-Capable 4 l2sc(51), -- Layer-2-Switch-Capable tdm(100), -- Time-Division-Multiplex lsc(150), -- Lambda-Switch-Capable fsc(200) -- Fiber-Switch-Capable } Nadeau & Farrel Standards Track [Page 52] RFC 4802 GMPLS TE MIB February 2007 IANAGmplsGeneralizedPidTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used to represent and control the LSP Generalized Protocol Identifier (G-PID) of an LSP signaled by a GMPLS signaling protocol. This textual convention is strongly tied to the Generalized PIDs (G-PID) sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Generalized PIDs (G-PID) sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the Generalized PIDs (G-PID) sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@iana.org)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.1.1. 2. Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, RFC 4328, section 3.1.3." SYNTAX INTEGER { unknown(0), -- unknown or none of the following -- the values 1, 2, 3 and 4 are reserved in RFC 3471 asynchE4(5), asynchDS3T3(6), asynchE3(7), bitsynchE3(8), bytesynchE3(9), asynchDS2T2(10), bitsynchDS2T2(11), reservedByRFC3471first(12), asynchE1(13), bytesynchE1(14), bytesynch31ByDS0(15), asynchDS1T1(16), bitsynchDS1T1(17), Nadeau & Farrel Standards Track [Page 53] RFC 4802 GMPLS TE MIB February 2007 bytesynchDS1T1(18), vc1vc12(19), reservedByRFC3471second(20), reservedByRFC3471third(21), ds1SFAsynch(22), ds1ESFAsynch(23), ds3M23Asynch(24), ds3CBitParityAsynch(25), vtLovc(26), stsSpeHovc(27), posNoScramble16BitCrc(28), posNoScramble32BitCrc(29), posScramble16BitCrc(30), posScramble32BitCrc(31), atm(32), ethernet(33), sdhSonet(34), digitalwrapper(36), lambda(37), ansiEtsiPdh(38), lapsSdh(40), fddi(41), dqdb(42), fiberChannel3(43), hdlc(44), ethernetV2DixOnly(45), ethernet802dot3Only(46), g709ODUj(47), g709OTUk(48), g709CBRorCBRa(49), g709CBRb(50), g709BSOT(51), g709BSNT(52), gfpIPorPPP(53), gfpEthernetMAC(54), gfpEthernetPHY(55), g709ESCON(56), g709FICON(57), g709FiberChannel(58) } IANAGmplsAdminStatusInformationTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type determines the setting of the Admin Status flags in the Admin Status object or TLV, as described in RFC 3471. Setting this object to a non-zero value will result in the inclusion of the Admin Status Nadeau & Farrel Standards Track [Page 54] RFC 4802 GMPLS TE MIB February 2007 object or TLV on signaling messages. This textual convention is strongly tied to the Administrative Status Information Flags sub-registry of the GMPLS Signaling Parameters registry managed by IANA. Values should be assigned by IANA in step with the Administrative Status Flags sub-registry and using the same registry management rules. However, the actual values used in this textual convention are solely within the purview of IANA and do not necessarily match the values in the Administrative Status Information Flags sub-registry. The definition of this textual convention with the addition of newly assigned values is published periodically by the IANA, in either the Assigned Numbers RFC, or some derivative of it specific to Internet Network Management number assignments. (The latest arrangements can be obtained by contacting the IANA.) Requests for new values should be made to IANA via email (iana@iana.org)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 8. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 7. 3. GMPLS - Communication of Alarm Information, RFC 4783, section 3.2.1." SYNTAX BITS { reflect(0), -- Reflect bit (RFC 3471) reserved1(1), -- reserved reserved2(2), -- reserved reserved3(3), -- reserved reserved4(4), -- reserved reserved5(5), -- reserved reserved6(6), -- reserved reserved7(7), -- reserved reserved8(8), -- reserved reserved9(9), -- reserved reserved10(10), -- reserved reserved11(11), -- reserved reserved12(12), -- reserved reserved13(13), -- reserved reserved14(14), -- reserved reserved15(15), -- reserved reserved16(16), -- reserved Nadeau & Farrel Standards Track [Page 55] RFC 4802 GMPLS TE MIB February 2007 reserved17(17), -- reserved reserved18(18), -- reserved reserved19(19), -- reserved reserved20(20), -- reserved reserved21(21), -- reserved reserved22(22), -- reserved reserved23(23), -- reserved reserved24(24), -- reserved reserved25(25), -- reserved reserved26(26), -- reserved reserved27(27), -- Inhibit Alarm bit (RFC 4783) reserved28(28), -- reserved testing(29), -- Testing bit (RFC 3473) administrativelyDown(30), -- Admin down (RFC 3473) deleteInProgress(31) -- Delete bit (RFC 3473) } END 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. Nadeau & Farrel Standards Track [Page 56] RFC 4802 GMPLS TE MIB February 2007 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. Nadeau & Farrel Standards Track [Page 57] RFC 4802 GMPLS TE MIB February 2007 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006. [RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007. 12.2. Informative References [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. Nadeau & Farrel Standards Track [Page 58] RFC 4802 GMPLS TE MIB February 2007 Contact Information Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 EMail: tnadeau@cisco.com Cheenu Srinivasan Bloomberg L.P. 731 Lexington Ave. New York, NY 10022 Phone: +1-212-617-3682 EMail: cheenu@bloomberg.net Adrian Farrel Old Dog Consulting Phone: +44-(0)-1978-860944 EMail: adrian@olddog.co.uk Tim Hall Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 EMail: tim.hall@dataconnection.com Ed Harrison Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 EMail: ed.harrison@dataconnection.com Nadeau & Farrel Standards Track [Page 59] RFC 4802 GMPLS TE MIB February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nadeau & Farrel Standards Track [Page 60] snmp-mibs-downloader-1.1/mibrfcs/rfc4803.txt0000644000000000000000000023406511402176072015573 0ustar Network Working Group T. Nadeau, Ed. Request for Comment: 4803 Cisco Systems, Inc. Category: Standards Track A. Farrel, Ed. Old Dog Consulting February 2007 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). Nadeau & Farrel Standards Track [Page 1] RFC 4803 GMPLS LSR MIB February 2007 Table of Contents 1. Introduction ....................................................2 1.1. Migration Strategy .........................................2 2. Terminology .....................................................3 3. The Internet-Standard Management Framework ......................4 4. Outline .........................................................5 4.1. MIB Modules ................................................5 4.1.1. Summary of the GMPLS-LSR-STD-MIB Module .............5 4.1.2. Summary of the GMPLS-LABEL-STD-MIB Module ...........5 4.2. Configuring Statically Provisioned LSPs ....................5 5. Bidirectional LSPs ..............................................6 6. Example of LSP Setup ............................................7 7. GMPLS Label Switching Router MIB Definitions ...................11 8. GMPLS Label MIB Definitions ....................................22 9. Security Considerations ........................................36 10. Acknowledgments ...............................................37 11. IANA Considerations ...........................................38 12. References ....................................................38 12.1. Normative References .....................................38 12.2. Informative References ...................................40 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] Label Switching Router (LSR). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 1.1. Migration Strategy MPLS LSRs may be modeled and managed using the MPLS-LSR-STD-MIB module [RFC3813]. LSRs may be migrated to be modeled and managed using the MIB modules in this document in order to migrate the LSRs to GMPLS support, or to take advantage of additional MIB objects defined in these MIB modules that are applicable to MPLS-TE. Nadeau & Farrel Standards Track [Page 2] RFC 4803 GMPLS LSR MIB February 2007 The GMPLS LSR MIB module (GMPLS-LSR-STD-MIB), defined in this document, extends the MPLS-LSR-STD-MIB module [RFC3813] through a series of sparse augmentations of the MIB tables. The only additions are for support of GMPLS or to support the increased complexity of MPLS and GMPLS systems. In order to migrate from MPLS-LSR-STD-MIB support to GMPLS-LSR-STD- MIB support, an implementation needs only to add support for the additional tables and objects defined in GMPLS-LSR-STD-MIB. The gmplsInterfaceSignalingCaps object allows an implementation to use the objects and tables of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols. The GMPLS Label MIB module (GMPLS-LABEL-STD-MIB), also defined in this document, allows labels to be configured and examined, and it supports more varieties of labels as appropriate for GMPLS. Labels may be referenced using a row pointer from objects within the GMPLS- LSR-STD-MIB module. MPLS implementations (MPLS-LSR-STD-MIB) may also reference labels held in the GMPLS-LABEL-STD-MIB module through the various label pointer objects in the MPLS-LSR-STD-MIB module (such as mplsInSegmentLabelPtr), and may do so without implementing the GMPLS-LSR-STD-MIB module. The companion document modeling and managing GMPLS-based traffic engineering [RFC4802] extends the MPLS-TE-STD-MIB module [RFC3812] with the same intentions. Textual conventions are defined in [RFC4801], which extends the set of textual conventions originally defined in [RFC3811]. 2. Terminology This document uses terminology from the document describing the MPLS architecture [RFC3031] and the GMPLS architecture [RFC3945]. A Label Switched Path (LSP) is modeled as a connection consisting of one or more incoming segments (in-segments) and/or one or more outgoing segments (out-segments) at an LSR. The association or interconnection of the in-segments and out-segments is accomplished by using a cross-connect. We use the terminology "connection" and "LSP" interchangeably where the meaning is clear from the context. in-segment This is analogous to a GMPLS Label on an interface. out-segment This is analogous to a GMPLS Label on an interface. Nadeau & Farrel Standards Track [Page 3] RFC 4803 GMPLS LSR MIB February 2007 cross-connect This describes the conceptual connection between a set of in-segments and out-segments. Note that either set may be empty; for example, a cross-connect may connect only out-segments together with no in-segments in the case where an LSP originates on an LSR. The terms 'ingress' and 'head-end' (or 'head') are used in this document to indicate the signaling source of an LSP. This is sometimes also referred to as the 'sender'. The terms 'egress' and 'tail-end' (or 'tail') are used in this document to indicate the signaling destination of an LSP. The term 'upstream' is used in this document to refer to the part of an LSP that is closer to the ingress than the current point of reference. The term 'downstream' is used in this document to refer to the part of an LSP that is closer to the egress than the current point of reference. The term 'forward' is used in this document to indicate the direction of data flow from the ingress toward the egress. The term 'reverse' is used in this document to indicate the direction of data flow from the egress toward the ingress. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Nadeau & Farrel Standards Track [Page 4] RFC 4803 GMPLS LSR MIB February 2007 4. Outline 4.1. MIB Modules There are two MIB modules defined in this document. The GMPLS-LSR-STD-MIB module contains tables that sparse augment tables defined in the MPLS-LSR-STD-MIB module [RFC3813]. This MIB module is used in conjunction with the MPLS-LSR-STD-MIB module [RFC3813] in systems that support GMPLS. The GMPLS-LABEL-STD-MIB module contains objects for managing GMPLS Labels when they cannot be represented using the textual conventions of the MPLS-TC-STD-MIB module [RFC3811], or when more detailed access to the sub-fields of the labels is required. 4.1.1. Summary of the GMPLS-LSR-STD-MIB Module The MIB tables in the GMPLS-LSR-STD-MIB module are as follows: - The interface configuration table (gmplsInterfaceTable) sparse augments the mplsInterfaceTable [RFC3813] to enable the GMPLS protocol on MPLS-capable interfaces. - The in-segment (gmplsInSegmentTable) and out-segment (gmplsOutSegmentTable) tables sparse augment mplsInSegmentTable and mplsOutSegmentTable [RFC3813] to enable configuration of GMPLS-specific parameters for LSP segments at an LSR. These tables are described in the subsequent sections. 4.1.2. Summary of the GMPLS-LABEL-STD-MIB Module There is one MIB table in the GMPLS-LABEL-STD-MIB module as follows: - The gmplsLabelTable allows Generalized Labels to be defined and managed in a central location. Generalized Labels can be of variable length and have distinct bit-by-bit interpretations depending upon how they are defined for the specific technology in which they are used. For example, labels used for MPLS packet switching are different in length and content from labels used in Time Division Multiplexer (TDM) timeslot switching. 4.2. Configuring Statically Provisioned LSPs Configuring statically provisioned GMPLS LSPs through an LSR involves the following steps: Nadeau & Farrel Standards Track [Page 5] RFC 4803 GMPLS LSR MIB February 2007 - Configuring an interface using the MPLS-LSR-STD-MIB module [RFC3813]. - Enabling GMPLS on GMPLS-capable interfaces using the GMPLS-LSR- STD-MIB module in this document. - Configuring in-segments and out-segments using the MPLS-LSR-STD- MIB module [RFC3813]. - Configuring GMPLS extensions to the in-segments and out-segments using the GMPLS-LSR-STD-MIB module in this document. - Setting up the cross-connect table in the MPLS-LSR-STD-MIB module [RFC3813] to associate segments and/or to indicate connection origination and termination. - Optionally setting up labels in the label table in the GMPLS- LABEL-STD-MIB module in this document if the textual convention MplsLabel [RFC3811] is not capable of holding the required label (for example, if the label requires more than 32 bits to encode it), or if the operator wishes to disambiguate GMPLS Label types. - Optionally specifying label stack actions in the MPLS-LSR-STD-MIB module [RFC3813]. - Optionally specifying segment traffic parameters in the MPLS-LSR- STD-MIB module [RFC3813]. 5. Bidirectional LSPs The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required for GMPLS. A single value of mplsXCIndex is shared by all of the segments for the entire bidirectional LSP. This facilitates a simple reference from [RFC3812] and [RFC4802] and makes fate-sharing more obvious. It is, however, important that the direction of segments is understood to avoid connecting all in-segments to all out-segments. This is achieved by an object in each segment that indicates the direction of the segment with respect to data flow. A segment that is marked as 'forward' carries data from the 'head' of the LSP to the 'tail'. A segment marked as 'reverse' carries data in the reverse direction. Nadeau & Farrel Standards Track [Page 6] RFC 4803 GMPLS LSR MIB February 2007 Where an LSP is signaled using a conventional signaling protocol, the 'head' of the LSP is the source of the signaling (also known as the ingress) and the 'tail' is the destination (also known as the egress). For manually configured LSPs, an arbitrary decision must be made about which segments are 'forward' and which 'reverse'. For consistency, this decision should be made across all LSRs that participate in the LSP by assigning 'head' and 'tail' ends to the LSP. 6. Example of LSP Setup In this section, we provide a brief example of using the MIB objects described in sections 7 and 8 to set up an LSP. While this example is not meant to illustrate every nuance of the MIB modules, it is intended as an aid to understanding some of the key concepts. It is meant to be read after going through the MIB modules themselves. A prerequisite is an understanding of the MPLS-LSR-STD-MIB module [RFC3813]. Suppose that one would like to manually create a best-effort, bidirectional LSP. Assume that, in the forward direction, the LSP enters the LSR via MPLS interface A with ifIndex 12 and exits the LSR via MPLS interface B with ifIndex 13. For the reverse direction, we assume that the LSP enters via interface B and leaves via interface A (i.e., the forward and reverse directions use the same bidirectional interfaces). Let us also assume that we do not wish to have a label stack beneath the top label on the outgoing labeled packets. The following example illustrates which rows and corresponding objects might be created to accomplish this. We must first create rows in the gmplsLabelTable corresponding to the labels required for each of the forward- and reverse-direction in- and out-segments. For the purpose of this example, the forward and reverse labels on each interface will be the same, hence we need to create just two rows in the gmplsLabelTable - one for each interface. In gmplsLabelTable: { gmplsLabelInterface = 12, gmplsLabelIndex = 1, gmplsLabelSubindex = 0, gmplsLabelType = gmplsFreeformLabel(3), gmplsLabelFreeform = 0x123456789ABCDEF0 gmplsLabelRowStatus = createAndGo(4) } Nadeau & Farrel Standards Track [Page 7] RFC 4803 GMPLS LSR MIB February 2007 In gmplsLabelTable: { gmplsLabelInterface = 13, gmplsLabelIndex = 1, gmplsLabelSubindex = 0, gmplsLabelType = gmplsFreeformLabel(3), gmplsLabelFreeform = 0xFEDCBA9876543210 gmplsLabelRowStatus = createAndGo(4) } We must next create the appropriate in-segment and out-segment entries. These are done in [RFC3813] using the mplsInSegmentTable and mplsOutSegmentTable. Note that we use a row pointer to the two rows in the gmplsLabelTable rather than specify the labels explicitly in the in- and out-segment tables. Also note that the row status for each row is set to createAndWait(5) to allow corresponding entries in the gmplsInSegmentTable and gmplsOutSegmentTable to be created. For the forward direction. In mplsInSegmentTable: { mplsInSegmentIndex = 0x00000015 mplsInSegmentLabel = 0, -- incoming label in label table mplsInSegmentNPop = 1, mplsInSegmentInterface = 12, -- incoming interface -- RowPointer MUST point to the first accessible column. mplsInSegmentTrafficParamPtr = 0.0, mplsInSegmentLabelPtr = gmplsLabelTable(12,1,0) mplsInSegmentRowStatus = createAndWait(5) } In mplsOutSegmentTable: { mplsOutSegmentIndex = 0x00000012, mplsOutSegmentInterface = 13, -- outgoing interface mplsOutSegmentPushTopLabel = true(1), mplsOutSegmentTopLabel = 0, -- outgoing label in label table -- RowPointer MUST point to the first accessible column. mplsOutSegmentTrafficParamPtr = 0.0, mplsOutSegmentLabelPtr = gmplsLabelTable(13,1,0) mplsOutSegmentRowStatus = createAndWait(5) } Nadeau & Farrel Standards Track [Page 8] RFC 4803 GMPLS LSR MIB February 2007 For the reverse direction. In mplsInSegmentTable: { mplsInSegmentIndex = 0x00000016 mplsInSegmentLabel = 0, -- incoming label in label table mplsInSegmentNPop = 1, mplsInSegmentInterface = 13, -- incoming interface -- RowPointer MUST point to the first accessible column. mplsInSegmentTrafficParamPtr = 0.0, mplsInSegmentLabelPtr = gmplsLabelTable(13,1,0) mplsInSegmentRowStatus = createAndWait(5) } In mplsOutSegmentTable: { mplsOutSegmentIndex = 0x00000013, mplsOutSegmentInterface = 12, -- outgoing interface mplsOutSegmentPushTopLabel = true(1), mplsOutSegmentTopLabel = 0, -- outgoing label in label table -- RowPointer MUST point to the first accessible column. mplsOutSegmentTrafficParamPtr = 0.0, mplsOutSegmentLabelPtr = gmplsLabelTable(12,1,0) mplsOutSegmentRowStatus = createAndWait(5) } These table entries are extended by entries in the gmplsInSegmentTable and gmplsOutSegmentTable. Note that the nature of the 'extends' relationship is a sparse augmentation so that the entry in the gmplsInSegmentTable has the same index values as the entry in the mplsInSegmentTable. Similarly, the entry in the gmplsOutSegmentTable has the same index values as the entry in the mplsOutSegmentTable. First for the forward direction: In gmplsInSegmentTable(0x00000015) { gmplsInSegmentDirection = forward(1) } In gmplsOutSegmentTable(0x00000012) { gmplsOutSegmentDirection = forward(1) } Nadeau & Farrel Standards Track [Page 9] RFC 4803 GMPLS LSR MIB February 2007 Next for the reverse direction: In gmplsInSegmentTable(0x00000016) { gmplsInSegmentDirection = reverse(2) } In gmplsOutSegmentTable(0x00000013) { gmplsOutSegmentDirection = reverse(2) } Next, two cross-connect entries are created in the mplsXCTable of the MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created segments together. In mplsXCTable: { mplsXCIndex = 0x01, mplsXCInSegmentIndex = 0x00000015, mplsXCOutSegmentIndex = 0x00000012, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } In mplsXCTable: { mplsXCIndex = 0x02, mplsXCInSegmentIndex = 0x00000016, mplsXCOutSegmentIndex = 0x00000013, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } Finally, the in-segments and out-segments are activated. In mplsInSegmentTable(0x00000015): { mplsInSegmentRowStatus = active(1) } In mplsInSegmentTable(0x00000016): { mplsInSegmentRowStatus = active(1) } Nadeau & Farrel Standards Track [Page 10] RFC 4803 GMPLS LSR MIB February 2007 In mplsOutSegmentTable(0x00000012): { mplsOutSegmentRowStatus = active(1) } In mplsOutSegmentTable(0x00000013): { mplsOutSegmentRowStatus = active(1) } 7. GMPLS Label Switching Router MIB Definitions This MIB module makes reference to the following documents: [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3209], [RFC3443], [RFC3468], [RFC3472], [RFC3473], [RFC3811], [RFC3813], and [RFC4801]. GMPLS-LSR-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, zeroDotZero FROM SNMPv2-SMI -- RFC 2578 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 RowPointer FROM SNMPv2-TC -- RFC 2579 GmplsSegmentDirectionTC FROM GMPLS-TC-STD-MIB -- RFC 4801 mplsInterfaceIndex, mplsInSegmentIndex, mplsOutSegmentIndex, mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup FROM MPLS-LSR-STD-MIB -- RFC 3813 ifGeneralInformationGroup, ifCounterDiscontinuityGroup FROM IF-MIB -- RFC 2863 mplsStdMIB FROM MPLS-TC-STD-MIB -- RFC 3811 ; gmplsLsrStdMIB MODULE-IDENTITY LAST-UPDATED "200702270000Z" -- 27 February 2007 00:00:00 GMT ORGANIZATION "IETF Common Control And Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Nadeau & Farrel Standards Track [Page 11] RFC 4803 GMPLS LSR MIB February 2007 Email: adrian@olddog.co.uk Comments about this document should be emailed directly to the CCAMP working group mailing list at ccamp@ops.ietf.org." DESCRIPTION "Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4803; see the RFC itself for full legal notices. This MIB module contains managed object definitions for the Generalized Multiprotocol (GMPLS) Label Switching Router as defined in Generalized Multi-Protocol Label Switching (GMPLS) Architecture, Mannie et al., RFC 3945, October 2004." REVISION "200702270000Z" -- 27 February 2007 00:00:00 GMT DESCRIPTION "Initial version issued as part of RFC 4803." ::= { mplsStdMIB 15 } -- no notifications are currently defined. gmplsLsrObjects OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 1 } gmplsLsrConformance OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 2 } gmplsInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface GMPLS capability and associated information. It extends the information in the mplsInterfaceTable of MPLS-LSR-STD-MIB through a sparse augmentation relationship." REFERENCE "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." ::= { gmplsLsrObjects 1 } gmplsInterfaceEntry OBJECT-TYPE SYNTAX GmplsInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in this table is created automatically by an LSR for each interface that is both capable of supporting GMPLS and configured to support GMPLS. Note that support of GMPLS is not limited to control plane signaling, but may include data-plane-only function configured through SNMP SET commands performed on this MIB module. Nadeau & Farrel Standards Track [Page 12] RFC 4803 GMPLS LSR MIB February 2007 A conceptual row in this table may also be created via SNMP SET commands or automatically by the LSR to supplement a conceptual row in the mplsInterfaceTable where the interface is not capable of GMPLS but where the other objects carried in this row provide useful additional information for an MPLS interface. A conceptual row in this table will exist if and only if a corresponding entry in the mplsInterfaceTable exists, and a corresponding entry in the ifTable exists with ifType = mpls(166). If the associated entry in the ifTable is operationally disabled (thus removing the GMPLS capabilities on the interface) or the entry in the mplsInterfaceTable is deleted, the corresponding entry in this table MUST be deleted shortly thereafter. The indexes are the same as for the mplsInterfaceTable. Thus, the entry with index 0 represents the per-platform label space and contains parameters that apply to all interfaces that participate in the per-platform label space." REFERENCE "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." INDEX { mplsInterfaceIndex } ::= { gmplsInterfaceTable 1 } GmplsInterfaceEntry ::= SEQUENCE { gmplsInterfaceSignalingCaps BITS, gmplsInterfaceRsvpHelloPeriod Unsigned32 } gmplsInterfaceSignalingCaps OBJECT-TYPE SYNTAX BITS { unknown(0), rsvpGmpls(1), crldpGmpls(2), -- note the use of CR-LDP is deprecated otherGmpls(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the signaling capabilities on this interface. Multiple bits may legitimately be set at once, but if 'unknown' is set then no other bit may be set. Setting no bits implies that GMPLS signaling cannot be performed on this interface and all LSPs must be manually provisioned or that this table entry is only present to supplement an entry in the mplsInterfaceTable by providing the information carried in other objects in this row." REFERENCE Nadeau & Farrel Standards Track [Page 13] RFC 4803 GMPLS LSR MIB February 2007 "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472. 2. The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols, RFC 3468. 3. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." DEFVAL { { rsvpGmpls } } ::= { gmplsInterfaceEntry 1 } gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Period, in milliseconds, between sending Resource Reservation Protocol (RSVP) Hello messages on this interface. A value of 0 indicates that no Hello messages should be sent on this interface. This object is only valid if gmplsInterfaceSignalingCaps has no bits set or includes the rsvpGmpls bit." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, section 5. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 9.3." DEFVAL { 3000 } ::= { gmplsInterfaceEntry 2 } gmplsInSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsInSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table sparse augments the mplsInSegmentTable of MPLS-LSR-STD-MIB to provide GMPLS-specific information about incoming segments to an LSR." REFERENCE "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." ::= { gmplsLsrObjects 2 } gmplsInSegmentEntry OBJECT-TYPE SYNTAX GmplsInSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table extends the representation of an incoming segment represented by an entry in the mplsInSegmentTable in Nadeau & Farrel Standards Track [Page 14] RFC 4803 GMPLS LSR MIB February 2007 MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be created by a network administrator via SNMP SET commands, or in response to signaling protocol events. Note that the storage type for this entry is given by the value of mplsInSegmentStorageType in the corresponding entry of the mplsInSegmentTable." REFERENCE "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." INDEX { mplsInSegmentIndex } ::= { gmplsInSegmentTable 1 } GmplsInSegmentEntry ::= SEQUENCE { gmplsInSegmentDirection GmplsSegmentDirectionTC, gmplsInSegmentExtraParamsPtr RowPointer } gmplsInSegmentDirection OBJECT-TYPE SYNTAX GmplsSegmentDirectionTC MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the direction of data flow on this segment. This object cannot be modified if mplsInSegmentRowStatus for the corresponding entry in the mplsInSegmentTable is active(1)." REFERENCE "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." DEFVAL { forward } ::= { gmplsInSegmentEntry 1 } gmplsInSegmentExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Some tunnels will run over transports that can usefully support technology-specific additional parameters (for example, Synchronous Optical Network (SONET) resource usage). Such can be supplied from an external table and referenced from here. A value of zeroDotZero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::= { gmplsInSegmentEntry 2 } gmplsOutSegmentTable OBJECT-TYPE Nadeau & Farrel Standards Track [Page 15] RFC 4803 GMPLS LSR MIB February 2007 SYNTAX SEQUENCE OF GmplsOutSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table sparse augments the mplsOutSegmentTable of MPLS-LSR-STD-MIB to provide GMPLS-specific information about outgoing segments from an LSR." REFERENCE "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." ::= { gmplsLsrObjects 3 } gmplsOutSegmentEntry OBJECT-TYPE SYNTAX GmplsOutSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table extends the representation of an outgoing segment represented by an entry in the mplsOutSegmentTable of MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be created by a network administrator via SNMP SET commands, or in response to signaling protocol events. Note that the storage type for this entry is given by the value of mplsOutSegmentStorageType in the corresponding entry of the mplsOutSegmentTable." REFERENCE "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." INDEX { mplsOutSegmentIndex } ::= { gmplsOutSegmentTable 1 } GmplsOutSegmentEntry ::= SEQUENCE { gmplsOutSegmentDirection GmplsSegmentDirectionTC, gmplsOutSegmentTTLDecrement Unsigned32, gmplsOutSegmentExtraParamsPtr RowPointer } gmplsOutSegmentDirection OBJECT-TYPE SYNTAX GmplsSegmentDirectionTC MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the direction of data flow on this segment. This object cannot be modified if mplsOutSegmentRowStatus for the corresponding entry in the mplsOutSegmentTable is active(1)." REFERENCE Nadeau & Farrel Standards Track [Page 16] RFC 4803 GMPLS LSR MIB February 2007 "1. Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB), RFC 3813." DEFVAL { forward } ::= { gmplsOutSegmentEntry 1 } gmplsOutSegmentTTLDecrement OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the amount by which to decrement the Time to Live (TTL) of any payload packets forwarded on this segment if per-hop decrementing is being done. A value of zero indicates that no decrement should be made or that per-hop decrementing is not in use. See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable of GMPLS-TE-STD-MIB for a value by which to decrement the TTL for the whole of a tunnel. This object cannot be modified if mplsOutSegmentRowStatus for the associated entry in the mplsOutSegmentTable is active(1)." REFERENCE "1. Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks, RFC 3443. 2. Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base, RFC 4802." DEFVAL { 0 } ::= { gmplsOutSegmentEntry 2 } gmplsOutSegmentExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Some tunnels will run over transports that can usefully support technology-specific additional parameters (for example, SONET resource usage). Such can be supplied from an external table and referenced from here. A value of zeroDotZero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::= { gmplsOutSegmentEntry 3 } gmplsLsrGroups OBJECT IDENTIFIER ::= { gmplsLsrConformance 1 } Nadeau & Farrel Standards Track [Page 17] RFC 4803 GMPLS LSR MIB February 2007 gmplsLsrCompliances OBJECT IDENTIFIER ::= { gmplsLsrConformance 2 } -- Compliance requirement for fully compliant implementations. gmplsLsrModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for GMPLS-LSR-STD-MIB. The mandatory group has to be implemented by all LSRs that originate, terminate, or act as transit for TE-LSPs/tunnels. In addition, depending on the type of tunnels supported, other groups become mandatory as explained below." MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE MPLS-LSR-STD-MIB -- The MPLS-LSR-STD-MIB, RFC3813 MANDATORY-GROUPS { mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup } MODULE -- this module MANDATORY-GROUPS { gmplsInterfaceGroup, gmplsInSegmentGroup, gmplsOutSegmentGroup } OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-only DESCRIPTION "The only valid value for unidirectional LSPs is forward(1)." Nadeau & Farrel Standards Track [Page 18] RFC 4803 GMPLS LSR MIB February 2007 OBJECT gmplsOutSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-only DESCRIPTION "The only valid value for unidirectional LSPs is forward(1)." OBJECT gmplsOutSegmentTTLDecrement MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsInSegmentExtraParamsPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsOutSegmentExtraParamsPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { gmplsLsrCompliances 1 } -- Compliance requirement for implementations that provide read-only -- access. gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-LSR-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB module." MODULE IF-MIB -- The interfaces Group MIB, RFC 2863 MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE MPLS-LSR-STD-MIB MANDATORY-GROUPS { mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsPerfGroup } Nadeau & Farrel Standards Track [Page 19] RFC 4803 GMPLS LSR MIB February 2007 MODULE -- this module MANDATORY-GROUPS { gmplsInterfaceGroup, gmplsInSegmentGroup, gmplsOutSegmentGroup } OBJECT gmplsInterfaceSignalingCaps MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsInterfaceRsvpHelloPeriod MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirectionTC MIN-ACCESS read-only DESCRIPTION "The only valid value for unidirectional LSPs is forward(1)." OBJECT gmplsInSegmentExtraParamsPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsOutSegmentDirection MIN-ACCESS read-only DESCRIPTION "The only valid value for unidirectional LSPs is forward(1)." OBJECT gmplsOutSegmentTTLDecrement MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsOutSegmentExtraParamsPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { gmplsLsrCompliances 2 } gmplsInterfaceGroup OBJECT-GROUP OBJECTS { gmplsInterfaceSignalingCaps, Nadeau & Farrel Standards Track [Page 20] RFC 4803 GMPLS LSR MIB February 2007 gmplsInterfaceRsvpHelloPeriod } STATUS current DESCRIPTION "Collection of objects that provide additional information for an MPLS interface and are needed for GMPLS interface configuration and performance information." ::= { gmplsLsrGroups 1 } gmplsInSegmentGroup OBJECT-GROUP OBJECTS { gmplsInSegmentDirection, gmplsInSegmentExtraParamsPtr } STATUS current DESCRIPTION "Collection of objects that provide additional information for an MPLS in-segment and are needed for GMPLS in-segment configuration and performance information." ::= { gmplsLsrGroups 2 } gmplsOutSegmentGroup OBJECT-GROUP OBJECTS { gmplsOutSegmentDirection, gmplsOutSegmentTTLDecrement, gmplsOutSegmentExtraParamsPtr } STATUS current DESCRIPTION "Collection of objects that provide additional information for an MPLS out-segment and are needed for GMPLS out-segment configuration and performance information." ::= { gmplsLsrGroups 3 } END Nadeau & Farrel Standards Track [Page 21] RFC 4803 GMPLS LSR MIB February 2007 8. GMPLS Label MIB Definitions This MIB module makes reference to the following documents: [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3032], [RFC3289], [RFC3471], [RFC3811], and [RFC4801]. GMPLS-LABEL-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Integer32 FROM SNMPv2-SMI -- RFC 2578 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 RowStatus, StorageType FROM SNMPv2-TC -- RFC 2579 InterfaceIndexOrZero FROM IF-MIB -- RFC 2863 IndexIntegerNextFree FROM DIFFSERV-MIB -- RFC 3289 MplsLabel, mplsStdMIB FROM MPLS-TC-STD-MIB -- RFC 3811 GmplsLabelTypeTC, GmplsFreeformLabelTC FROM GMPLS-TC-STD-MIB -- RFC 4801 ; gmplsLabelStdMIB MODULE-IDENTITY LAST-UPDATED "200702270000Z" -- 27 February 2007 00:00:00 GMT ORGANIZATION "IETF Common Control and Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Comments about this document should be emailed directly to the CCAMP working group mailing list at ccamp@ops.ietf.org." DESCRIPTION "Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4803; see the RFC itself for full legal notices. Nadeau & Farrel Standards Track [Page 22] RFC 4803 GMPLS LSR MIB February 2007 This MIB module contains managed object definitions for labels within GMPLS systems as defined in Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." REVISION "200702270000Z" -- 27 February 2007 00:00:00 GMT DESCRIPTION "Initial version issued as part of RFC 4803." ::= { mplsStdMIB 16 } -- no notifications are currently defined. gmplsLabelObjects OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 1 } gmplsLabelConformance OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 2 } gmplsLabelIndexNext OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for gmplsLabelIndex, or a zero to indicate that no unused value exists or is available. A management application wishing to create a row in the gmplsLabelTable may read this object and then attempt to create a row in the table. If row creation fails (because another application has already created a row with the supplied index), the management application should read this object again to get a new index value. When a row is created in the gmplsLabelTable with the gmplsLabelIndex value held by this object, an implementation MUST change the value in this object." ::= { gmplsLabelObjects 1 } gmplsLabelTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of GMPLS Labels. This table allows the representation of the more complex label forms required for GMPLS that cannot be held within the TEXTUAL-CONVENTION MplsLabel; that is, labels that cannot be encoded within 32 bits. It is, nevertheless, also capable of holding 32-bit labels or regular MPLS Labels if desired. Nadeau & Farrel Standards Track [Page 23] RFC 4803 GMPLS LSR MIB February 2007 Each entry in this table represents an individual GMPLS Label value. The representation of Labels in tables in other MIB modules may be achieved by a referrence to an entry in this table by means of a row pointer into this table. The indexing of this table provides for arbitrary indexing and also for concatenation of labels. For an example of label concatenation, see RFC 3945, section 7.1. In essence, a GMPLS Label may be composite in order to identify a set of resources in the data plane. Practical examples are timeslots and wavelength sets (which are not contiguous like wavebands). The indexing mechanism allows multiple entries in this table to be seen as a sequence of labels that should be concatenated. Ordering is potentially very sensitive for concatenation." REFERENCE "1. Generalized Multiprotocol Label Switching (GMPLS) Architecture, RFC 3945, section 7.1." ::= { gmplsLabelObjects 2 } gmplsLabelEntry OBJECT-TYPE SYNTAX GmplsLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a single label value. There are three indexes into the table. - The interface index may be helpful to distinguish which labels are in use on which interfaces or to handle cases where there are a very large number of labels in use in the system. When label representation is desired to apply to the whole system or when it is not important to distinguish labels by their interfaces, this index MAY be set to zero. - The label index provides a way of identifying the label. - The label sub-index is only used for concatenated labels. It identifies each component label. When non-concatenated labels are used, this index SHOULD be set to zero. A storage type object is supplied to control the storage type for each entry, but implementations should note that the storage type of conceptual rows in other tables that include row pointers to an entry in this table SHOULD dictate the storage type of the rows in this table where the row in the other table is more persistent." Nadeau & Farrel Standards Track [Page 24] RFC 4803 GMPLS LSR MIB February 2007 INDEX { gmplsLabelInterface, gmplsLabelIndex, gmplsLabelSubindex } ::= { gmplsLabelTable 1 } GmplsLabelEntry ::= SEQUENCE { gmplsLabelInterface InterfaceIndexOrZero, gmplsLabelIndex Unsigned32, gmplsLabelSubindex Unsigned32, gmplsLabelType GmplsLabelTypeTC, gmplsLabelMplsLabel MplsLabel, gmplsLabelPortWavelength Unsigned32, gmplsLabelFreeform GmplsFreeformLabelTC, gmplsLabelSonetSdhSignalIndex Integer32, gmplsLabelSdhVc Integer32, gmplsLabelSdhVcBranch Integer32, gmplsLabelSonetSdhBranch Integer32, gmplsLabelSonetSdhGroupBranch Integer32, gmplsLabelWavebandId Unsigned32, gmplsLabelWavebandStart Unsigned32, gmplsLabelWavebandEnd Unsigned32, gmplsLabelStorageType StorageType, gmplsLabelRowStatus RowStatus } gmplsLabelInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface on which this label is used. If this object is set to zero, the label MUST have applicability across the whole system and not be limited to a single interface." ::= { gmplsLabelEntry 1 } gmplsLabelIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary index into the table to identify a label. Note that implementations that are representing 32-bit labels within this table MAY choose to align this index with the value of the label, and this may result in the use of the value zero since it represents a valid label value. Such implementation should be aware of the implications of sparsely populated Nadeau & Farrel Standards Track [Page 25] RFC 4803 GMPLS LSR MIB February 2007 tables. A management application may read the gmplsLabelIndexNext object to find a suitable value for this object." ::= { gmplsLabelEntry 2 } gmplsLabelSubindex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "In conjunction with gmplsLabelInterface and gmplsLabelIndex, this object uniquely identifies this row. This sub-index allows a single GMPLS Label to be defined as a concatenation of labels. This is particularly useful in TDM. The ordering of sub-labels is strict with the sub-label with the lowest gmplsLabelSubindex appearing first. Note that all sub-labels of a single GMPLS Label must share the same gmplsLabelInterface and gmplsLabelIndex values. For labels that are not composed of concatenated sub-labels, this value SHOULD be set to zero." ::= { gmplsLabelEntry 3 } gmplsLabelType OBJECT-TYPE SYNTAX GmplsLabelTypeTC MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the type of this label. Note that this object does not determine whether MPLS or GMPLS signaling is in use: a value of gmplsMplsLabel(1) denotes that an MPLS Packet Label is present in the gmplsLabelMplsLabel object and encoded using the MplsLabel TEXTUAL-CONVENTION (may be a 20-bit MPLS Label, a 10- or 23-bit Frame Relay Label, or an Asynchronous Transfer Mode (ATM) Label), but does not describe whether this is signaled using MPLS or GMPLS. The value of this object helps determine which of the following objects are valid. This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3." ::= { gmplsLabelEntry 4 } gmplsLabelMplsLabel OBJECT-TYPE SYNTAX MplsLabel Nadeau & Farrel Standards Track [Page 26] RFC 4803 GMPLS LSR MIB February 2007 MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an MPLS Label (that is a Packet Label) if this table is used to store it. This may be used in MPLS systems even though the label values can be adequately stored in the MPLS MIB modules (MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB). Furthermore, in mixed MPLS and GMPLS systems, it may be advantageous to store all labels in a single label table. Lastly, in GMPLS systems where Packet Labels are used (that is in systems that use GMPLS signaling and GMPLS Labels for packet switching), it may be desirable to use this table. This object is only valid if gmplsLabelType is set to gmplsMplsLabel(1). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. MPLS Label Stack Encoding, RFC 3032." DEFVAL { 0 } ::= { gmplsLabelEntry 5 } gmplsLabelPortWavelength OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value of a Port or Wavelength Label when carried as a Generalized Label. Only valid if gmplsLabelType is set to gmplsPortWavelengthLabel(2). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.2.1.1." DEFVAL { 0 } ::= { gmplsLabelEntry 6 } gmplsLabelFreeform OBJECT-TYPE SYNTAX GmplsFreeformLabelTC MAX-ACCESS read-create STATUS current DESCRIPTION "The value of a Freeform Generalized Label that does not conform to one of the standardized label encodings or that an implementation chooses to represent as an octet string without further decoding. Only valid if gmplsLabelType is set to gmplsFreeformLabel(3). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE Nadeau & Farrel Standards Track [Page 27] RFC 4803 GMPLS LSR MIB February 2007 "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.2." DEFVAL { '00'h } ::= { gmplsLabelEntry 7 } gmplsLabelSonetSdhSignalIndex OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS read-create STATUS current DESCRIPTION "The Signal Index value (S) of a SONET or SDH Generalized Label. Zero indicates that this field is non-significant. Only valid if gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control, RFC 4606, section 3." DEFVAL { 0 } ::= { gmplsLabelEntry 8 } gmplsLabelSdhVc OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The VC Indicator (U) of an SDH Generalized Label. Zero indicates that this field is non-significant. Only valid if gmplsLabelType is set to gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control, RFC 4606, section 3." DEFVAL { 0 } ::= { gmplsLabelEntry 9 } gmplsLabelSdhVcBranch OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The VC Branch Indicator (K) of an SDH Generalized Label. Zero indicates that this field is non-significant. Only valid if gmplsLabelType is set to gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE Nadeau & Farrel Standards Track [Page 28] RFC 4803 GMPLS LSR MIB February 2007 "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control, RFC 4606, section 3." DEFVAL { 0 } ::= { gmplsLabelEntry 10 } gmplsLabelSonetSdhBranch OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The Branch Indicator (L) of a SONET or SDH Generalized Label. Zero indicates that this field is non-significant. Only valid gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control, RFC 4606, section 3." DEFVAL { 0 } ::= { gmplsLabelEntry 11 } gmplsLabelSonetSdhGroupBranch OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The Group Branch Indicator (M) of a SONET or SDH Generalized Label. Zero indicates that this field is non-significant. Only valid if gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control, RFC 4606, section 3." DEFVAL { 0 } ::= { gmplsLabelEntry 12 } gmplsLabelWavebandId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The waveband identifier component of a Waveband Label. Only valid if gmplsLabelType is set to gmplsWavebandLabel(6). This object cannot be modified if gmplsLabelRowStatus is active(1)." Nadeau & Farrel Standards Track [Page 29] RFC 4803 GMPLS LSR MIB February 2007 REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.3." DEFVAL { 0 } ::= { gmplsLabelEntry 13 } gmplsLabelWavebandStart OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The starting label component of a Waveband Label. Only valid if gmplsLabelType is set to gmplsWavebandLabel(6). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.3." DEFVAL { 0 } ::= { gmplsLabelEntry 14 } gmplsLabelWavebandEnd OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The end label component of a Waveband Label. Only valid if gmplsLabelType is set to gmplsWavebandLabel(6). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, section 3.3." DEFVAL { 0 } ::= { gmplsLabelEntry 15 } gmplsLabelStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this row. The agent MUST ensure that this object's value remains consistent with the storage type of any rows in other tables that contain pointers to this row. In particular, the storage type of this row must be at least as permanent as that of any row that points to it. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." REFERENCE Nadeau & Farrel Standards Track [Page 30] RFC 4803 GMPLS LSR MIB February 2007 "1. Textual Conventions for SMIv2, STD 58, RFC 2579, section 2." DEFVAL { volatile } ::= { gmplsLabelEntry 16 } gmplsLabelRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. When a row in this table has a row in the active(1) state, no objects in this row can be modified except the gmplsLabelRowStatus and gmplsLabelStorageType. The gmplsLabelType object does not have a default and must be set before a row can become active. The corresponding label objects (dependent on the value of gmplsLabelType) should also be set unless they happen to need to use the specified default values as follows: gmplsLabelType setting objects to be set -------------------------------------------------------------- gmplsMplsLabel(1) gmplsLabelMplsLabel gmplsPortWavelengthLabel(2) gmplsLabelPortWavelength gmplsFreeformLabel(3) gmplsLabelFreeform gmplsSonetLabel(4) gmplsLabelSonetSdhSignalIndex gmplsLabelSdhVc gmplsLabelSdhVcBranch gmplsLabelSonetSdhBranch gmplsLabelSonetSdhGroupBranch gmplsSdhLabel(5) gmplsLabelSonetSdhSignalIndex gmplsLabelSdhVc gmplsLabelSdhVcBranch gmplsLabelSonetSdhBranch gmplsLabelSonetSdhGroupBranch gmplsWavebandLabel(6) gmplsLabelWavebandId gmplsLabelWavebandStart gmplsLabelWavebandEnd" ::= { gmplsLabelEntry 17 } gmplsLabelGroups OBJECT IDENTIFIER ::= { gmplsLabelConformance 1 } Nadeau & Farrel Standards Track [Page 31] RFC 4803 GMPLS LSR MIB February 2007 gmplsLabelCompliances OBJECT IDENTIFIER ::= { gmplsLabelConformance 2 } gmplsLabelModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-LABEL-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB module." MODULE -- this module -- The mandatory groups have to be implemented by LSRs claiming -- support for this MIB module. This MIB module is, however, not -- mandatory for a working implementation of a GMPLS LSR with full -- MIB support if the GMPLS Labels in use can be represented within -- a 32-bit quantity. MANDATORY-GROUPS { gmplsLabelTableGroup } GROUP gmplsLabelPacketGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support Packet Labels. It is optional for implementations that do not support Packet Labels." GROUP gmplsLabelPortWavelengthGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support Port and Wavelength Labels. It is optional for implementations that do not support Wavelength Labels." GROUP gmplsLabelFreeformGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support Freeform Labels. It is optional for implementations that do not support Freeform Labels." GROUP gmplsLabelSonetSdhGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support SONET or SDH Labels. It is optional for implementations that do not support SONET or SDH Labels." GROUP gmplsLabelWavebandGroup DESCRIPTION Nadeau & Farrel Standards Track [Page 32] RFC 4803 GMPLS LSR MIB February 2007 "This group extends gmplsLabelTableGroup for implementations that support Waveband Labels. It is optional for implementations that do not support Waveband Labels." OBJECT gmplsLabelType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelMplsLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelPortWavelength MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelFreeform MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSonetSdhSignalIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSdhVc MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSdhVcBranch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSonetSdhBranch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSonetSdhGroupBranch MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau & Farrel Standards Track [Page 33] RFC 4803 GMPLS LSR MIB February 2007 OBJECT gmplsLabelWavebandId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelWavebandStart MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelWavebandEnd MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active(1) is the only status that needs to be supported." ::= { gmplsLabelCompliances 1 } gmplsLabelModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that support the complete GMPLS-LABEL-STD-MIB module. The mandatory groups have to be implemented by GMPLS LSRs claiming support for this MIB module. This MIB module is, however, not mandatory for a working implementation of a GMPLS LSR with full MIB support if the GMPLS Labels in use can be represented within a 32-bit quantity." MODULE -- this module MANDATORY-GROUPS { gmplsLabelTableGroup } ::= { gmplsLabelCompliances 2 } Nadeau & Farrel Standards Track [Page 34] RFC 4803 GMPLS LSR MIB February 2007 gmplsLabelTableGroup OBJECT-GROUP OBJECTS { gmplsLabelIndexNext, gmplsLabelType, gmplsLabelStorageType, gmplsLabelRowStatus } STATUS current DESCRIPTION "Necessary, but not sufficient, set of objects to implement label table support. In addition, depending on the type of labels supported, the following other groups defined below are mandatory: gmplsLabelWavebandGroup and/or gmplsLabelPacketGroup and/or gmplsLabelPortWavelengthGroup and/or gmplsLabelFreeformGroup and/or gmplsLabelSonetSdhGroup." ::= { gmplsLabelGroups 1 } gmplsLabelPacketGroup OBJECT-GROUP OBJECTS { gmplsLabelMplsLabel } STATUS current DESCRIPTION "Object needed to implement Packet (MPLS) Labels." ::= { gmplsLabelGroups 2 } gmplsLabelPortWavelengthGroup OBJECT-GROUP OBJECTS { gmplsLabelPortWavelength } STATUS current DESCRIPTION "Object needed to implement Port and Wavelength Labels." ::= { gmplsLabelGroups 3 } gmplsLabelFreeformGroup OBJECT-GROUP OBJECTS { gmplsLabelFreeform } STATUS current DESCRIPTION "Object needed to implement Freeform Labels." ::= { gmplsLabelGroups 4 } Nadeau & Farrel Standards Track [Page 35] RFC 4803 GMPLS LSR MIB February 2007 gmplsLabelSonetSdhGroup OBJECT-GROUP OBJECTS { gmplsLabelSonetSdhSignalIndex, gmplsLabelSdhVc, gmplsLabelSdhVcBranch, gmplsLabelSonetSdhBranch, gmplsLabelSonetSdhGroupBranch } STATUS current DESCRIPTION "Objects needed to implement SONET and SDH Labels." ::= { gmplsLabelGroups 5 } gmplsLabelWavebandGroup OBJECT-GROUP OBJECTS { gmplsLabelWavebandId, gmplsLabelWavebandStart, gmplsLabelWavebandEnd } STATUS current DESCRIPTION "Objects needed to implement Waveband Labels." ::= { gmplsLabelGroups 6 } END 9. Security Considerations It is clear that the MIB modules described in this document in association with MPLS-LSR-STD-MIB [RFC3813] are potentially useful for monitoring of GMPLS LSRs. These MIB modules can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable, and gmplsLabelTable collectively contain objects to provision GMPLS interfaces, LSPs, and their associated parameters on a Label Switching Router (LSR). Unauthorized write access to objects in these tables could result in disruption of Nadeau & Farrel Standards Track [Page 36] RFC 4803 GMPLS LSR MIB February 2007 traffic on the network. This is especially true if an LSP has already been established. Some of the readable objects in these MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable, and gmplsLabelTable collectively show the LSP network topology and its capabilities. If an administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. Acknowledgments This document is a product of the CCAMP Working Group. This document extends the MIB tables in [RFC3813]. The authors would like to express their gratitude to all those who worked on that earlier MIB document. The authors would like to express their thanks to Dan Joyle for his careful review and comments on early versions of the label table. Special thanks to Joan Cucchiara and Len Nieman for their help with Nadeau & Farrel Standards Track [Page 37] RFC 4803 GMPLS LSR MIB February 2007 compilation issues. Lars Eggert, Tom Petch, Dan Romascanu, and Bert Wijnen provided useful input in the final stages of review. Joan Cucchiara provided a helpful and very thorough MIB Doctor review. 11. IANA Considerations IANA has rooted MIB objects in the two MIB modules contained in this document under the mplsStdMIB subtree. IANA has made the following assignments in the "NETWORK MANAGEMENT PARAMETERS" registry located at http://www.iana.org/assignments/ smi-numbers in table: ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166) Decimal Name References ------- ----- ---------- 15 GMPLS-LSR-STD-MIB [RFC4803] 16 GMPLS-LABEL-STD-MIB [RFC4803] In the future, GMPLS-related standards-track MIB modules should be rooted under the mplsStdMIB (sic) subtree. IANA has been requested to manage that namespace in the SMI Numbers registry [RFC3811]. New assignments can only be made via a Standards Action as specified in [RFC2434]. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Nadeau & Farrel Standards Track [Page 38] RFC 4803 GMPLS LSR MIB February 2007 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. Nadeau & Farrel Standards Track [Page 39] RFC 4803 GMPLS LSR MIB February 2007 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006. [RFC4801] Nadeau, T., Ed. and A. Farrel, Ed., "Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management", RFC 4801, February 2007. [RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007. 12.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- Protocol Label Switching (GMPLS) Signaling Constraint- based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. Nadeau & Farrel Standards Track [Page 40] RFC 4803 GMPLS LSR MIB February 2007 Contact Information Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 EMail: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Phone: +44-(0)-1978-860944 EMail: adrian@olddog.co.uk Cheenu Srinivasan Bloomberg L.P. 731 Lexington Ave. New York, NY 10022 Phone: +1-212-617-3682 EMail: cheenu@bloomberg.net Tim Hall Data Connection Ltd. 100 Church Street Enfield, Middlesex, EN2 6BQ, UK Phone: +44 20 8366 1177 EMail: tim.hall@dataconnection.com Ed Harrison Data Connection Ltd. 100 Church Street Enfield, Middlesex, EN2 6BQ, UK Phone: +44 20 8366 1177 EMail: ed.harrison@dataconnection.com Nadeau & Farrel Standards Track [Page 41] RFC 4803 GMPLS LSR MIB February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nadeau & Farrel Standards Track [Page 42] snmp-mibs-downloader-1.1/mibrfcs/rfc4805.txt0000644000000000000000000056274711402176072015610 0ustar Network Working Group O. Nicklass, Ed. Request for Comments: 4805 RAD Data Communications, Ltd. Obsoletes: 3895 March 2007 Category: Standards Track Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, J1, E1, DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 3895. Nicklass, Ed. Standards Track [Page 1] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Conventions Used in This Document ...............................3 3. Overview ........................................................3 3.1. Use of ifTable for DS1 Layer ...............................4 3.2. Usage Guidelines ...........................................5 3.2.1. Usage of ifStackTable for Routers and DSUs ..........5 3.2.2. Usage of ifStackTable for DS1/J1/E1 on DS2/E2 .......7 3.2.3. Usage of Channelization for DS3, DS1, DS0 ...........8 3.2.4. Usage of Channelization for DS3, DS2, DS1 ...........9 3.2.5. Usage of Loopbacks .................................10 3.3. Objectives of This MIB Module .............................10 3.4. DS1 Terminology ...........................................11 3.4.1. Error Events .......................................11 3.4.2. Performance Defects ................................12 3.4.3. Performance Parameters .............................13 3.4.4. Failure States .....................................17 3.4.5. Other Terms ........................................20 4. Object Definitions .............................................20 5. Security Considerations ........................................83 6. Acknowledgments ................................................84 7. References .....................................................84 7.1. Normative References ......................................84 7.2. Informative References ....................................86 Appendix A - Use of dsx1IfIndex and dsx1LineIndex .................88 Appendix B - The Delay Approach to Unavailable Seconds ............90 Appendix C - Changes from Previous Versions .......................92 C.1. Changes from RFC 3895 .....................................92 C.2. Changes from RFC 2495 .....................................92 C.3. Changes from RFC 1406 .....................................92 C.4. Companion Documents .......................................93 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Nicklass, Ed. Standards Track [Page 2] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Overview These objects are used when the particular media being used to realize an interface is a DS1/J1/E1/DS2/E2 interface. At present, this applies to the following value of the ifType variable in the Internet-standard MIB: ds1 (18) The definitions contained herein are based on the AT&T T-1 Superframe (a.k.a. D4) [ANSI-T1.107] and Extended Superframe (ESF) formats [AT&T-UM-305], [AT&T-TR-54016], the latter of which conforms to ANSI specifications [ANSI-T1.403], and the CCITT Recommendations [CCITT-G.703], [ITU-T-G.704], referred to as E1 for the rest of this memo. J1 refers to the definition presented in [JT-G704], [JT-G706], and [JT-I431]. The various DS1, J1, and E1 line disciplines are similar enough that separate MIBs are unwarranted, although there are some differences. For example, Loss of Frame is defined more rigorously in the ESF specification than in the D4 specification, or Yellow Alarm generation and detection are a bit different between T1 and J1 but in both examples, there is definition in both related lines. Therefore, interface types e1(19) and g703at2mb(67) have been obsoleted and there is also no need for special type for J1. Where it is necessary to distinguish between the flavors of E1 with and without Cyclic Redundancy Check (CRC), E1-CRC denotes the "with CRC" form (G.704 Table 5B) and E1-noCRC denotes the "without CRC" form (G.704 Table 5A). Nicklass, Ed. Standards Track [Page 3] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 3.1. Use of ifTable for DS1 Layer Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for DS1 Layer =================================================================== ifIndex Interface index. ifDescr See interfaces MIB [RFC2863]. ifType ds1(18) ifSpeed Speed of line rate DS1 - 1544000 J1 - 1544000 E1 - 2048000 DS2 - 6312000 E2 - 8448000 ifPhysAddress The value of the Circuit Identifier. If no Circuit Identifier has been assigned, this object should have an octet string with zero length. ifAdminStatus See interfaces MIB [RFC2863]. ifOperStatus See interfaces MIB [RFC2863]. ifLastChange See interfaces MIB [RFC2863]. ifName See interfaces MIB [RFC2863]. ifLinkUpDownTrapEnable Set to enabled(1). ifHighSpeed Speed of line in mega-bits per second (2, 6, or 8). ifConnectorPresent Set to true(1) normally, except for cases such as DS1/E1 over AAL1/ATM where false(2) is appropriate. Nicklass, Ed. Standards Track [Page 4] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 3.2. Usage Guidelines 3.2.1. Usage of ifStackTable for Routers and DSUs The object dsx1IfIndex has been deprecated. This object previously allowed a very special proxy situation to exist for routers and Channel Service Units (CSUs). This section now describes how to use the ifStackTable to represent this relationship. The paragraphs discussing dsx1IfIndex and dsx1LineIndex have been preserved in Appendix A for informational purposes. The ifStackTable is used in the proxy case to represent the association between pairs of interfaces, i.e., this T1 is attached to that T1. This use is consistent with the use of the ifStackTable to show the association between various sub-layers of an interface. In both cases, entire PDUs are exchanged between the interface pairs -- in the case of a T1, entire T1 frames are exchanged; in the case of PPP and High-Level Data Link Control (HDLC), entire HDLC frames are exchanged. This usage is not meant to suggest the use of the ifStackTable to represent Time Division Multiplexing (TDM) connections in general. External and Internal interface scenario: the SNMP agent resides on a host external from the device supporting DS1 interfaces (e.g., a router). The agent represents both the host and the DS1 device. Nicklass, Ed. Standards Track [Page 5] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Example: A shelf full of CSUs connected to a router. An SNMP agent residing on the router proxies for itself and the CSU. The router has also an Ethernet interface: +-----+ | | | | | | +---------------------+ |E | | 1.544 MBPS | Line#A | DS1 Link |t | R |---------------+ - - - - - - - - - +------> |h | | | | |e | O | 1.544 MBPS | Line#B | DS1 Link |r | |---------------+ - - - - - - - - - - +------> |n | U | | CSU Shelf | |e | | 1.544 MBPS | Line#C | DS1 Link |t | T |---------------+ - - - -- -- - - - - +------> | | | | | |-----| E | 1.544 MBPS | Line#D | DS1 Link | | |---------------+ - - - - -- - - - - +------> | | R | |_____________________| | | | | +-----+ The assignment of the index values could, for example, be as follows: ifIndex Description 1 Ethernet 2 Line#A Router 3 Line#B Router 4 Line#C Router 5 Line#D Router 6 Line#A CSU Router 7 Line#B CSU Router 8 Line#C CSU Router 9 Line#D CSU Router 10 Line#A CSU Network 11 Line#B CSU Network 12 Line#C CSU Network 13 Line#D CSU Network The ifStackTable is then used to show the relationships between the various DS1 interfaces. Nicklass, Ed. Standards Track [Page 6] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 ifStackTable Entries HigherLayer LowerLayer 2 6 3 7 4 8 5 9 6 10 7 11 8 12 9 13 If the CSU shelf is managed by itself by a local SNMP agent, the situation would be identical, except the Ethernet and the four router interfaces are deleted. Interfaces would also be numbered from 1 to 8. ifIndex Description 1 Line#A CSU Router 2 Line#B CSU Router 3 Line#C CSU Router 4 Line#D CSU Router 5 Line#A CSU Network 6 Line#B CSU Network 7 Line#C CSU Network 8 Line#D CSU Network ifStackTable Entries HigherLayer LowerLayer 1 5 2 6 3 7 4 8 3.2.2. Usage of ifStackTable for DS1/J1/E1 on DS2/E2 An example is given of how DS1/J1/E1 interfaces are stacked on DS2/E2 interfaces. It is not necessary nor is it always desirable to represent DS2 interfaces. If this is required, the following stacking should be used. All ifTypes are ds1. The DS2 is determined by examining ifSpeed or dsx1LineType. Nicklass, Ed. Standards Track [Page 7] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 ifIndex Description 1 DS1 #1 2 DS1 #2 3 DS1 #3 4 DS1 #4 5 DS2 ifStackTable Entries HigherLayer LowerLayer 1 5 2 5 3 5 4 5 3.2.3. Usage of Channelization for DS3, DS1, DS0 An example is given here to explain the channelization objects in the DS3, DS1, and DS0 MIBs to help the implementer use the objects correctly. Treatment of E3 and E1 would be similar, with the number of DS0s being different depending on the framing of the E1. Assume that a DS3 (with ifIndex 1) is channelized into DS1s (without DS2s). The object dsx3Channelization is set to enabledDs1. There will be 28 DS1s in the ifTable. Assume the entries in the ifTable for the DS1s are created in channel order and the ifIndex values are 2 through 29. In the DS1 MIB, there will be an entry in the dsx1ChanMappingTable for each DS1. The entries will be as follows: dsx1ChanMappingTable Entries ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex 1 1 2 1 2 3 ...... 1 28 29 In addition, the DS1s are channelized into DS0s. The object dsx1Channelization is set to enabledDS0 for each DS1. When this object is set to this value, 24 DS0s are created by the agent. There will be 24 DS0s in the ifTable for each DS1. If the dsx1Channelization is set to disabled, the 24 DS0s are destroyed. Assume the entries in the ifTable are created in channel order and the ifIndex values for the DS0s in the first DS1 are 30 through 53. In the DS0 MIB, there will be an entry in the dsx0ChanMappingTable for each DS0. The entries will be as follows: Nicklass, Ed. Standards Track [Page 8] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx0ChanMappingTable Entries ifIndex dsx0Ds0ChannelNumber dsx0ChanMappedIfIndex 2 1 30 2 2 31 ...... 2 24 53 3.2.4. Usage of Channelization for DS3, DS2, DS1 An example is given here to explain the channelization objects in the DS3 and DS1 MIBs to help the implementer use the objects correctly. Assume that a DS3 (with ifIndex 1) is channelized into DS2s. The object dsx3Channelization [RFC3896] is set to enabledDs2. There will be 7 DS2s (ifType of DS1) in the ifTable. Assume the entries in the ifTable for the DS2s are created in channel order and the ifIndex values are 2 through 8. In the DS1 MIB, there will be an entry in the dsx1ChanMappingTable for each DS2. The entries will be as follows: dsx1ChanMappingTable Entries ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex 1 1 2 1 2 3 ...... 1 7 8 In addition, the DS2s are channelized into DS1s. The object dsx1Channelization is set to enabledDS1 for each DS2. There will be 4 DS1s in the ifTable for each DS2. Assume the entries in the ifTable are created in channel order and the ifIndex values for the DS1s in the first DS2 are 9 through 12, then 13 through 16 for the second DS2, and so on. In the DS1 MIB, there will be an entry in the dsx1ChanMappingTable for each DS1. The entries will be as follows: dsx1ChanMappingTable Entries ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex 2 1 9 2 2 10 2 3 11 2 4 12 3 1 13 3 2 14 ... 8 4 36 Nicklass, Ed. Standards Track [Page 9] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 3.2.5. Usage of Loopbacks This section discusses the behavior of objects related to loopbacks. The object dsx1LoopbackConfig represents the desired state of loopbacks on this interface. Using this object, a manager can request LineLoopback PayloadLoopback (if ESF framing) InwardLoopback DualLoopback (Line + Inward) NoLoopback The remote end can also request loopbacks either through the Facility Data Link (FDL) channel if ESF or inband if D4. The loopbacks that can be requested this way are LineLoopback PayloadLoopback (if ESF framing) NoLoopback To model the current state of loopbacks on a DS1 interface, the object dsx1LoopbackStatus defines which loopback is currently applied to an interface. This object, which is a bitmap, will have bits turned on that reflect the currently active loopbacks on the interface as well as the source of those loopbacks. The following restrictions/rules apply to loopbacks: The far end cannot undo loopbacks set by a manager. A manager can undo loopbacks set by the far end. Both a line loopback and an inward loopback can be set at the same time. Only these two loopbacks can co-exist and either one may be set by the manager or the far end. A LineLoopback request from the far end is incremental to an existing Inward loopback established by a manager. When a NoLoopback is received from the far end in this case, the InwardLoopback remains in place. 3.3. Objectives of This MIB Module There are numerous things that could be included in a MIB for DS1 signals: the management of multiplexers, CSUs, Data Service Units (DSUs), and the like. The intent of this document is to facilitate the common management of all devices with DS1, J1, E1, DS2, or E2 interfaces. As such, a design decision was made up front to very Nicklass, Ed. Standards Track [Page 10] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 closely align the MIB with the set of objects that can generally be read from these types of devices that are currently deployed. J2 interfaces are not supported by this MIB. 3.4. DS1 Terminology The terminology used in this document to describe error conditions on a DS1 interface as monitored by a DS1 device are based on the latest ANSI T1.231 standard [ANSI-T1.231]. If the definition in this document does not match the definition in the ANSI T1.231 document, the implementer should follow the definition described in this document. 3.4.1. Error Events Bipolar Violation (BPV) Error Event A BPV error event for an AMI-coded (AMI stands for Alternate Mark Inversion) signal is the occurrence of a pulse of the same polarity as the previous pulse (see T1.231, Section 4.2.1.1.1). A BPV error event for a B8ZS- or HDB3-coded signal is the occurrence of a pulse of the same polarity as the previous pulse without being a part of the zero substitution code. Excessive Zeroes (EXZ) Error Event An Excessive Zeroes error event for an AMI-coded signal is the occurrence of more than fifteen contiguous zeroes (see T1.231 Section 4.2.1.1.2). For a B8ZS-coded signal, the defect occurs when more than seven contiguous zeroes are detected. Line Coding Violation (LCV) Error Event A Line Coding Violation (LCV) is the occurrence of either a Bipolar Violation (BPV) or Excessive Zeroes (EXZ) error event. (Also known as CV-L; see T1.231, Section 4.6.1.1.) Path Coding Violation (PCV) Error Event A Path Coding Violation error event is a frame synchronization bit error in the D4 and E1-noCRC formats, or a CRC or frame synch. bit error in the ESF and E1-CRC formats. (Also known as CV-P; see T1.231, Section 4.6.2.1.) Controlled Slip (CS) Error Event A Controlled Slip is the replication or deletion of the payload bits of a DS1 frame (see T1.231, Section 4.2.1.2.3). A Controlled Slip may be performed when there is a difference between the timing of a synchronous receiving terminal and the received signal. A Controlled Slip does not cause an Out of Frame defect. Nicklass, Ed. Standards Track [Page 11] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 3.4.2. Performance Defects Out of Frame (OOF) Defect An OOF defect is the occurrence of a particular density of Framing Error events (see T1.231, Section 4.2.2.2.1). For DS1 links, an Out of Frame defect is declared when the receiver detects two or more framing errors within a 3-msec period for ESF signals and 0.75 msec for D4 signals, or two or more errors out of five or fewer consecutive framing bits. For E1 links, an Out of Frame defect is declared when three consecutive frame alignment signals have been received with an error (see G.706, Section 4.1 [CCITT-G.706]). For DS2 links, an Out of Frame defect is declared when seven or more consecutive errored framing patterns (four multiframe) are received. The OOF is cleared when three or more consecutive correct framing patterns are received. Once an Out Of Frame Defect is declared, the framer starts searching for a correct framing pattern. The Out of Frame defect ends when the signal is in-frame. In-frame occurs when there are fewer than two frame bit errors within a 3-msec period for ESF signals and 0.75 msec for D4 signals. For E1 links, in-frame occurs when a) in frame N the frame alignment signal is correct and b) in frame N+1 the frame alignment signal is absent (i.e., bit 2 in TS0 is a one) and c) in frame N+2 the frame alignment signal is present and correct (see G.704, Section 4.1). Alarm Indication Signal (AIS) Defect For D4 and ESF links, the 'all ones' condition is detected at a DS1 line interface upon observing an unframed signal with a one's density of at least 99.9% present for a time equal to or greater than T, where 3 ms <= T <= 75 ms. The AIS is terminated upon observing a signal not meeting the one's density or the unframed signal criteria for a period equal to or greater than T (see G.775, Section 5.4). For E1 links, the 'all-ones' condition is detected at the line interface as a string of 512 bits containing fewer than three zero bits (see O.162 [ITU-T-O.162], Section 3.3.2). Nicklass, Ed. Standards Track [Page 12] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 For DS2 links, the DS2 AIS shall be sent from the NT1 to the user to indicate a loss of the 6,312-kbps frame capability on the network side. The DS2 AIS is defined as a bit array of 6,312 kbps in which all binary bits are set to '1'. The DS2 AIS detection and removal shall be implemented according to ITU-T Draft Recommendation G.775 [ITU-T-G.775] Section 5.5: - a DS2 AIS defect is detected when the incoming signal has two or less zeroes in a sequence of 3156 bits (0.5 ms). - a DS2 AIS defect is cleared when the incoming signal has three or more zeroes in a sequence of 3156 bits (0.5 ms). 3.4.3. Performance Parameters All performance parameters are accumulated in 15-minute intervals, and up to 96 intervals (24 hours' worth) are kept by an agent. Fewer than 96 intervals of data will be available if the agent has been restarted within the last 24 hours. In addition, there is a rolling 24-hour total of each performance parameter. Performance parameters continue to be collected when the interface is down. There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute interval and any wall clock; however, some agents may align the 15-minute intervals with quarter hours. Performance parameters are of types PerfCurrentCount, PerfIntervalCount, and PerfTotalCount. These textual conventions are all Gauge32, and they are used because it is possible for these objects to decrease. Objects may decrease when Unavailable Seconds occur across a 15-minute interval boundary. See Unavailable Second discussion later in this section. Line Errored Second (LES) A Line Errored Second is a second in which one or more Line Coding Violation error events were detected. (Also known as ES-L; see T1.231, Section 4.6.1.2.) Controlled Slip Second (CSS) A Controlled Slip Second is a one-second interval containing one or more controlled slips (see T1.231, Section 4.6.2.9). This is not incremented during an Unavailable Second. Nicklass, Ed. Standards Track [Page 13] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Errored Second (ES) For ESF and E1-CRC links, an Errored Second is a second with one or more Path Coding Violations OR one or more Out of Frame defects OR one or more Controlled Slip events OR a detected AIS defect. (See T1.231, Section 4.6.2.2 and G.826 [ITU-T-G.826], Section B.1). For D4 and E1-noCRC links, the presence of Bipolar Violations also triggers an Errored Second. This is not incremented during an Unavailable Second. Bursty Errored Second (BES) A Bursty Errored Second (also known as Errored Second type B in T1.231, Section 4.6.2.4) is a second with fewer than 320 and more than 1 Path Coding Violation error events, no Severely Errored Frame defects, and no detected incoming AIS defects. Controlled Slips are not included in this parameter. This is not incremented during an Unavailable Second. It applies to ESF signals only. Severely Errored Second (SES) A Severely Errored Second for ESF signals is a second with 320 or more Path Coding Violation error events OR one or more Out of Frame defects OR a detected AIS defect (see T1.231, Section 4.6.2.5). For E1-CRC signals, a Severely Errored Second is a second with 832 or more Path Coding Violation error events OR one or more Out of Frame defects. For E1-noCRC signals, a Severely Errored Second is 2048 LCVs or more. For D4 signals, a Severely Errored Second is a count of one-second intervals with Framing Error events, or an OOF defect, or 1544 LCVs or more. Controlled Slips are not included in this parameter. This is not incremented during an Unavailable Second. Severely Errored Framing Second (SEFS) An Severely Errored Framing Second is a second with one or more Out of Frame defects OR a detected AIS defect. (Also known as SAS-P (SEF/AIS second); see T1.231, Section 4.6.2.6.) Nicklass, Ed. Standards Track [Page 14] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Degraded Minutes A Degraded Minute is one in which the estimated error rate exceeds 1E-6 but does not exceed 1E-3 (see G.821 [CCITT-G.821]). Degraded Minutes are determined by collecting all of the Available Seconds, removing any Severely Errored Seconds, grouping the result in 60-second long groups, and counting a 60-second long group (a.k.a. minute) as degraded if the cumulative errors during the seconds present in the group exceed 1E-6. Available seconds are merely those seconds that are not Unavailable as described below. Unavailable Second (UAS) Unavailable Seconds (UASs) are calculated by counting the number of seconds that the interface is unavailable. The DS1 interface is said to be unavailable from the onset of 10 contiguous SESs, or the onset of the condition leading to a failure (see Failure States). If the condition leading to the failure was immediately preceded by one or more contiguous SESs, then the DS1 interface unavailability starts from the onset of these SESs. Once unavailable, and if no failure is present, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs. Once unavailable, and if a failure is present, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs, if the failure clearing time is less than or equal to 10 seconds. If the failure clearing time is more than 10 seconds, the DS1 interface becomes available at the onset of 10 contiguous seconds with no SESs, or the onset period leading to the successful clearing condition, whichever occurs later. With respect to the DS1 error counts, all counters are incremented while the DS1 interface is deemed available. While the interface is deemed unavailable, the only count that is incremented is UASs. Note that this definition implies that the agent cannot determine until after a 10-second interval has passed whether a given one- second interval belongs to available or unavailable time. If the agent chooses to update the various performance statistics in real time, then it must be prepared to retroactively reduce the ES, BES, SES, and SEFS counts by 10 and increase the UAS count by 10 when it determines that available time has been entered. It must also be prepared to adjust the PCV count and the DM count as necessary since these parameters are not accumulated during unavailable time. It must be similarly prepared to retroactively decrease the UAS count by 10 and increase the ES, BES, and DM counts as necessary upon entering available time. A special case exists when the 10-second period leading to available or unavailable time crosses a 900-second statistics window boundary, as the foregoing description implies that the ES, BES, SES, SEFS, Nicklass, Ed. Standards Track [Page 15] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 DM, and UAS counts the PREVIOUS interval must be adjusted. In this case, successive GETs of the affected dsx1IntervalSESs and dsx1IntervalUASs objects will return differing values if the first GET occurs during the first few seconds of the window. The agent may instead choose to delay updates to the various statistics by 10 seconds in order to avoid retroactive adjustments to the counters. A way to do this is sketched in Appendix B. In any case, a linkDown trap shall be sent only after the agent has determined for certain that the unavailable state has been entered, but the time on the trap will be that of the first UAS (i.e., 10 seconds earlier). A linkUp trap shall be handled similarly. According to ANSI T1.231, unavailable time begins at the onset of 10 contiguous severely errored seconds -- that is, unavailable time starts with the first of the 10 contiguous SESs. Also, while an interface is deemed unavailable all counters for that interface are frozen except for the UAS count. It follows that an implementation that strictly complies with this standard must not increment any counters other than the UAS count -- even temporarily -- as a result of anything that happens during those 10 seconds. Since changes in the signal state lag the data to which they apply by 10 seconds, an ANSI-compliant implementation must pass the one-second statistics through a 10-second delay line prior to updating any counters. That can be done by performing the following steps at the end of each one-second interval. i) Read near/far end CV counter and alarm status flags from the hardware. ii) Accumulate the CV counts for the preceding second and compare them to the ES and SES threshold for the layer in question. Update the signal state and shift the one-second CV counts and ES/SES flags into the 10-element delay line. Note that far-end one-second statistics are to be flagged as "absent" during any second in which there is an incoming defect at the layer in question or at any lower layer. iii) Update the current interval statistics using the signal state from the previous update cycle and the one-second CV counts and ES/SES flags shifted out of the 10-element delay line. This approach is further described in Appendix B. Nicklass, Ed. Standards Track [Page 16] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 3.4.4. Failure States The following failure states are received, or detected failures, that are reported in the dsx1LineStatus object. When a DS1 interface would, if ever, produce the conditions leading to the failure state is described in the appropriate specification. Far End Alarm Failure The Far End Alarm failure is also known as "Yellow Alarm" in the DS1 and J1 cases, "Distant Alarm" in the E1 case, and "Remote Alarm" in the DS2 case. For D4 links, the Far End Alarm failure is declared when bit 6 of all channels has been zero for at least 335 ms and is cleared when bit 6 of at least one channel is non-zero for a period T, where T is usually less than one second and always less than five seconds. The Far End Alarm failure is not declared for D4 links when a Loss of Signal is detected. In J1 the 12th F-bit is set to 1. For ESF links, the Far End Alarm failure is declared if the Yellow Alarm signal pattern occurs in at least seven out of ten contiguous 16-bit pattern intervals and is cleared if the Yellow Alarm signal pattern does not occur in ten contiguous 16-bit signal pattern intervals. For DS1 the patterns is FF00 and for J1 the pattern is FFFF. For E1 links, the Far End Alarm failure is declared when bit 3 of time-slot zero is received set to one on two consecutive occasions. The Far End Alarm failure is cleared when bit 3 of time-slot zero is received set to zero. For DS2 links, if a loss of frame alignment (LOF or LOS) and/or DS2 AIS condition is detected, the RAI signal shall be generated and transmitted to the remote side. The Remote Alarm Indication (RAI) signal is defined on m-bits as a repetition of the 16-bit sequence consisting of eight binary '1s' and eight binary '0s' in m-bits(1111111100000000). When the RAI signal is not sent (in normal operation), the HDLC flag pattern (01111110) in the m-bit is sent. The RAI failure is detected when 16 or more consecutive RAI- patterns (1111111100000000) are received. The RAI failure is cleared when 4 or more consecutive incorrect-RAI-patterns are received. Nicklass, Ed. Standards Track [Page 17] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Alarm Indication Signal (AIS) Failure The Alarm Indication Signal failure is declared when an AIS defect is detected at the input and the AIS defect still exists after the Loss of Frame failure (which is caused by the unframed nature of the 'all-ones' signal) is declared. The AIS failure is cleared when the Loss of Frame failure is cleared. (See T1.231, Section 4.3.1.2.2). An AIS defect at a 6312-kbit/s (G.704) interface is detected when the incoming signal has two or less zeroes in a sequence of 3156 bits (0.5ms). The AIS signal defect is cleared when the incoming signal has three {3} or more zeroes in a sequence of 3156 bits (0.5ms). Loss Of Frame (LOF) Failure For DS1 links, the Loss of Frame failure is declared when an OOF or LOS defect has persisted for T seconds, where 2 <= T <= 10. The Loss of Frame failure is cleared when there have been no OOF or LOS defects during a period T where 0 <= T <= 20. Many systems will perform "hit integration" within the period T before declaring or clearing the failure; e.g., see TR 62411 [AT&T-TR-62411]. For E1 links, the Loss of Frame failure is declared when an OOF defect is detected. Loss Of Signal (LOS) Failure For DS1, the Loss of Signal failure is declared upon observing 175 +/- 75 contiguous pulse positions with no pulses of either positive or negative polarity. The LOS failure is cleared upon observing an average pulse density of at least 12.5% over a period of 175 +/- 75 contiguous pulse positions starting with the receipt of a pulse. For E1 links, the Loss of Signal failure is declared when greater than 10 consecutive zeroes are detected (see O.162, Section 3.4.4). A LOS defect at 6312kbit/s interfaces is detected when the incoming signal has "no transitions", i.e., when the signal level is less than or equal to a signal level of 35dB below nominal, for N consecutive pulse intervals, where 10 <= N <= 255. The LOS defect is cleared when the incoming signal has "transitions", i.e., when the signal level is greater than or equal to a signal level of 9dB below nominal, for N consecutive pulse intervals, where 10 <= N <= 255. Nicklass, Ed. Standards Track [Page 18] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 A signal with "transitions" corresponds to a G.703-compliant signal. Loopback Pseudo-Failure The Loopback Pseudo-Failure is declared when the near-end equipment has placed a loopback (of any kind) on the DS1. This allows a management entity to determine from one object whether the DS1 can be considered to be in service or not (from the point of view of the near-end equipment). TS16 Alarm Indication Signal Failure For E1 links, the TS16 Alarm Indication Signal failure is declared when time-slot 16 is received as all ones for all frames of two consecutive multiframes (see G.732, Section 4.2.6). This condition is never declared for DS1. Loss of MultiFrame Failure The Loss of MultiFrame failure is declared when two consecutive multiframe alignment signals (bits 4 through 7 of TS16 of frame 0) have been received with an error. The Loss of Multiframe failure is cleared when the first correct multiframe alignment signal is received. The Loss of Multiframe failure can only be declared for E1 links operating with G.732 [CCITT-G.732] framing (sometimes called "Channel Associated Signalling" mode). Far End Loss of Multiframe Failure The Far End Loss of Multiframe failure is declared when bit 2 of TS16 of frame 0 is received set to one on two consecutive occasions. The Far End Loss of Multiframe failure is cleared when bit 2 of TS16 of frame 0 is received set to zero. The Far End Loss of Multiframe failure can only be declared for E1 links operating in "Channel Associated Signalling" mode (see G.732). DS2 Payload AIS Failure The DS2 Payload AIS failure is declared when the incoming signal of the 6,312-kbps frame payload (time-slots 1 through 96) has two or less zeroes in a sequence of 3072 bits (0.5ms). The DS2 Payload AIS is cleared when the incoming signal of the 6,312-kbps frame payload has three or more zeroes in a sequence of 3072 bits (0.5 ms). DS2 Performance Threshold Failure DS2 Performance Threshold failure monitors equipment performance and is based on the CRC (Cyclic Redundancy Check) procedure defined in G.704. The DS2 Performance Threshold failure is declared when the bit error ratio exceeds 10^-4 (Performance Threshold), and the DS2 Nicklass, Ed. Standards Track [Page 19] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Performance Threshold failure is cleared when the bit error ratio decreases to less than 10^-6." 3.4.5. Other Terms Circuit Identifier This is a character string specified by the circuit vendor and is useful when communicating with the vendor during the troubleshooting process (see M.1400 [ITU-T-M.1400] for additional information). Proxy In this document, the word proxy is meant to indicate an application that receives SNMP messages and replies to them on behalf of the devices that implement the actual DS1/E1 interfaces. The proxy may have already collected the information about the DS1/J1/E1 interfaces into its local database and may not necessarily forward the requests to the actual DS1/J1/E1 interface. It is expected in such an application that there are periods of time where the proxy is not communicating with the DS1/J1/E1 interfaces. In these instances, the proxy will not necessarily have up-to-date configuration information and will most likely have missed the collection of some statistics data. Missed statistics data collection will result in invalid data in the interval table. 4. Object Definitions DS1-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, transmission FROM SNMPv2-SMI -- [RFC2578] DisplayString, TimeStamp, TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndex, ifIndex FROM IF-MIB -- [RFC2863] PerfCurrentCount, PerfIntervalCount, PerfTotalCount FROM PerfHist-TC-MIB; -- [RFC3593] ds1 MODULE-IDENTITY LAST-UPDATED "200703050000Z" ORGANIZATION "IETF AToM MIB Working Group" Nicklass, Ed. Standards Track [Page 20] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/atommib-charter.html Mailing Lists: General Discussion: atommib@research.telcordia.com To Subscribe: atommib-request@research.telcordia.com Editor: Orly Nicklass Postal: RAD Data Communications, Ltd. Ziv Tower, 24 Roul Walenberg Tel Aviv, Israel, 69719 Tel: +9723 765 9969 E-mail: orly_n@rad.com" DESCRIPTION "The MIB module to describe DS1, J1, E1, DS2, and E2 interfaces objects. Copyright (c) The IETF Trust (2007). This version of this MIB module is part of RFC 4805; see the RFC itself for full legal notices." REVISION "200703050000Z" DESCRIPTION "The following changes were made: (1) Values were added to dsx1LineType to support J1 types. (2) The object dsx1LineImpedance was added. (3) All DM-related objects were deprecated following their removal from ITU performance standards. The RFC 4805 version of this MIB module." REVISION "200409090000Z" DESCRIPTION "The RFC 3895 version of this MIB module. The key changes made to this MIB module since its publication in RFC 2495 are as follows: (1) The dsx1FracIfIndex SYNTAX matches the description range. (2) A value was added to dsx1TransmitClockSource. (3) Values were added to dsx1LineType. (4) Two objects were added, dsx1LineMode and dsx1LineBuildOut, to better express transceiver mode and LineBuildOut for T1. (5) Reference was added to Circuit Identifier object. Nicklass, Ed. Standards Track [Page 21] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 (6) Align the DESCRIPTION clauses of few statistic objects with the near-end definition, with the far-end definition, and with RFC 3593. (7) Changes in Compliance Statements to include new objects. (8) A typographical error in dsx2E2 was fixed; the new name is dsx1E2." REVISION "199808011830Z" DESCRIPTION "The RFC 2495 version of this MIB module. The key changes made to this MIB module since its publication in RFC 1406 are as follows: (1) The Fractional table has been deprecated. (2) This document uses SMIv2. (3) Usage is given for ifTable and ifXTable. (4) Example usage of ifStackTable is included. (5) dsx1IfIndex has been deprecated. (6) Support for DS2 and E2 has been added. (7) Additional lineTypes for DS2, E2, and unframed E1 were added. (8) The definition of valid intervals has been clarified for the case where the agent proxied for other devices. In particular, the treatment of missing intervals has been clarified. (9) An inward loopback has been added. (10) Additional lineStatus bits have been added for Near End in Unavailable Signal State, Carrier Equipment Out of Service, DS2 Payload AIS, and DS2 Performance Threshold. (11) A read-write line Length object has been added. (12) Signal mode of other has been added. (13) Added a lineStatus last change, trap and enabler. (14) The e1(19) ifType has been obsoleted, so this MIB does not list it as a supported ifType. (15) Textual Conventions for statistics objects have been used. (16) A new object, dsx1LoopbackStatus, has been introduced to reflect the loopbacks established on a DS1 interface and the source to the requests. dsx1LoopbackConfig continues to be the desired loopback state while dsx1LoopbackStatus reflects the actual state. (17) A dual loopback has been added to allow the setting of an inward loopback and a line loopback at the same time. (18) An object indicating which channel to use within a parent object (i.e., DS3) has been added. Nicklass, Ed. Standards Track [Page 22] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 (19) An object has been added to indicate whether or not this DS1/E1 is channelized. (20) Line coding type of B6ZS has been added for DS2." REVISION "199301252028Z" DESCRIPTION "Initial version, published as RFC 1406." ::= { transmission 18 } -- note that this subsumes cept(19) and g703at2mb(67) -- there is no separate CEPT or G703AT2MB MIB -- The DS1 Near End Group -- The DS1 Near End Group consists of five tables: -- DS1 Configuration -- DS1 Current -- DS1 Interval -- DS1 Total -- DS1 Channel Table -- The DS1 Configuration Table dsx1ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Configuration table." ::= { ds1 6 } dsx1ConfigEntry OBJECT-TYPE SYNTAX Dsx1ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Configuration table." INDEX { dsx1LineIndex } ::= { dsx1ConfigTable 1 } Dsx1ConfigEntry ::= SEQUENCE { dsx1LineIndex InterfaceIndex, dsx1IfIndex InterfaceIndex, dsx1TimeElapsed INTEGER, dsx1ValidIntervals INTEGER, dsx1LineType INTEGER, dsx1LineCoding INTEGER, dsx1SendCode INTEGER, Nicklass, Ed. Standards Track [Page 23] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1CircuitIdentifier DisplayString, dsx1LoopbackConfig INTEGER, dsx1LineStatus INTEGER, dsx1SignalMode INTEGER, dsx1TransmitClockSource INTEGER, dsx1Fdl INTEGER, dsx1InvalidIntervals INTEGER, dsx1LineLength INTEGER, dsx1LineStatusLastChange TimeStamp, dsx1LineStatusChangeTrapEnable INTEGER, dsx1LoopbackStatus INTEGER, dsx1Ds1ChannelNumber INTEGER, dsx1Channelization INTEGER, dsx1LineMode INTEGER, dsx1LineBuildOut INTEGER, dsx1LineImpedance INTEGER } dsx1LineIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This object should be made equal to ifIndex. The next paragraph describes its previous usage. Making the object equal to ifIndex allows proper use of the ifStackTable and ds0/ds0bundle MIBs. Previously, this object was the identifier of a DS1 interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS1 interface, it should have the same value as ifIndex. Otherwise, number the dsx1LineIndices with a unique identifier following the rules of choosing a number that is greater than ifNumber and numbering the inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g., network side) with odd numbers." ::= { dsx1ConfigEntry 1 } dsx1IfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This value for this object is equal to the value Nicklass, Ed. Standards Track [Page 24] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 of ifIndex from the Interfaces table (RFC 2863)." ::= { dsx1ConfigEntry 2 } dsx1TimeElapsed OBJECT-TYPE SYNTAX INTEGER (0..899) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that have elapsed since the beginning of the near-end current error- measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, the agent will return the maximum value." ::= { dsx1ConfigEntry 3 } dsx1ValidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous near-end intervals for which data was collected. The value will be 96 unless the interface was brought online within the last 24 hours, in which case the value will be the number of complete 15-minute near-end intervals since the interface has been online. In the case where the agent is a proxy, it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { dsx1ConfigEntry 4 } dsx1LineType OBJECT-TYPE SYNTAX INTEGER { other(1), dsx1ESF(2), dsx1D4(3), dsx1E1(4), dsx1E1CRC(5), dsx1E1MF(6), dsx1E1CRCMF(7), dsx1Unframed(8), dsx1E1Unframed(9), dsx1DS2M12(10), dsx1E2(11), dsx1E1Q50(12), dsx1E1Q50CRC(13), Nicklass, Ed. Standards Track [Page 25] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1J1ESF(14), dsx1J1Unframed(16) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the variety of DS1 Line implementing this circuit. The type of circuit affects the number of bits per second that the circuit can reasonably carry, as well as the interpretation of the usage and error statistics. The values, in sequence, describe: TITLE: SPECIFICATION: dsx1ESF Extended SuperFrame DS1 (T1.107) dsx1D4 AT&T D4 format DS1 (T1.107) dsx1E1 ITU-T G.704, (Table 5A) dsx1E1-CRC ITU-T G.704, (Table 5B) dsxE1-MF G.704 (Table 5A) with TS16 multiframing enabled dsx1E1-CRC-MF G.704 (Table 5B) with TS16 multiframing enabled dsx1Unframed DS1 with No Framing dsx1E1Unframed E1 with No Framing (G.703) dsx1DS2M12 DS2 frame format (T1.107) dsx1E2 E2 frame format (G.704) dsx1E1Q50 TS16 bits 5,7,8 set to 101, [in all other cases it is set to 111.] (G.704, table 14) dsx1E1Q50CRC E1Q50 with CRC dsx1J1ESF J1 according to (JT-G704, JT-G706, and JT-I431) dsx1J1Unframed J1 with No Framing For clarification, the capacity for each E1 type is as listed below: dsx1E1Unframed - E1, no framing = 32 x 64k = 2048k dsx1E1 or dsx1E1CRC - E1, with framing, no signalling = 31 x 64k = 1984k dsx1E1MF or dsx1E1CRCMF - E1, with framing, signalling = 30 x 64k = 1920k" REFERENCE "American National Standard for telecommunications - digital hierarchy - formats specification, ANSI T1.107- 1988. ITU-T G.703: Physical/Electrical Characteristics Nicklass, Ed. Standards Track [Page 26] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 of Hierarchical Digital Interfaces, November 2001. ITU-T G.704: Synchronous frame structures used at 1544, 6312, 2048, 8488 and 44 736 kbit/s Hierarchical Levels, July 1995. JT-G704: Synchronous frame structures used at Primary and Secondary Hierarchical Levels,2002. JT-G706. Frame Alignment and Cyclic Redundancy Check (CRC) Procedures. JT-I431. ISDN Primary Rate User-Network Interface, Layer 1 Specifications, 2002 " ::= { dsx1ConfigEntry 5 } dsx1LineCoding OBJECT-TYPE SYNTAX INTEGER { dsx1JBZS(1), dsx1B8ZS(2), dsx1HDB3(3), dsx1ZBTSI(4), dsx1AMI(5), other(6), dsx1B6ZS(7) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable describes the variety of Zero Code Suppression used on this interface, which in turn affects a number of its characteristics. dsx1JBZS refers the Jammed Bit Zero Suppression, in which the AT&T specification of at least one pulse every 8-bit period is literally implemented by forcing a pulse in bit 8 of each channel. Thus, only 7 bits per channel, or 1.344 Mbps, are available for data. dsx1B8ZS refers to the use of a specified pattern of normal bits and bipolar violations that are used to replace a sequence of 8 zero bits. ANSI Clear Channels may use dsx1ZBTSI, or Zero Byte Time Slot Interchange. E1 links, with or without CRC, use dsx1HDB3 or dsx1AMI. dsx1AMI refers to a mode wherein no Zero Code Suppression is present and the line encoding does Nicklass, Ed. Standards Track [Page 27] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 not solve the problem directly. In this application, the higher layer must provide data that meets or exceeds the pulse density requirements, such as inverting HDLC data. dsx1B6ZS refers to the user of a specified pattern of normal bits and bipolar violations that are used to replace a sequence of 6 zero bits. Used for DS2. For more information about line coding see [ANSI-T1.102]" ::= { dsx1ConfigEntry 6 } dsx1SendCode OBJECT-TYPE SYNTAX INTEGER { dsx1SendNoCode(1), dsx1SendLineCode(2), dsx1SendPayloadCode(3), dsx1SendResetCode(4), dsx1SendQRS(5), dsx1Send511Pattern(6), dsx1Send3in24Pattern(7), dsx1SendOtherTestPattern(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates what type of code is being sent across the DS1 interface by the device. Setting this variable causes the interface to send the code requested. The values mean the following: dsx1SendNoCode sending looped or normal data dsx1SendLineCode sending a request for a line loopback dsx1SendPayloadCode sending a request for a payload loopback dsx1SendResetCode sending a loopback termination request dsx1SendQRS sending a Quasi-Random Signal (QRS) test pattern Nicklass, Ed. Standards Track [Page 28] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1Send511Pattern sending a 511-bit fixed test pattern dsx1Send3in24Pattern sending a fixed test pattern of 3 bits set in 24 dsx1SendOtherTestPattern sending a test pattern other than those described by this object" ::= { dsx1ConfigEntry 7 } dsx1CircuitIdentifier OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "This variable contains the transmission vendor's circuit identifier, for the purpose of facilitating troubleshooting." REFERENCE "ITU-T M.1400" ::= { dsx1ConfigEntry 8 } dsx1LoopbackConfig OBJECT-TYPE SYNTAX INTEGER { dsx1NoLoop(1), dsx1PayloadLoop(2), dsx1LineLoop(3), dsx1OtherLoop(4), dsx1InwardLoop(5), dsx1DualLoop(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable represents the desired loopback configuration of the DS1 interface. Agents supporting read/write access should return inconsistentValue in response to a requested loopback state that the interface does not support. The values mean: dsx1NoLoop not in the loopback state. A device that is not capable of performing a loopback on the interface shall always return this as its value. dsx1PayloadLoop Nicklass, Ed. Standards Track [Page 29] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 the received signal at this interface is looped through the device. Typically, the received signal is looped back for retransmission after it has passed through the device's framing function. dsx1LineLoop the received signal at this interface does not go through the device (minimum penetration) but is looped back out. dsx1OtherLoop loopbacks that are not defined here. dsx1InwardLoop the transmitted signal at this interface is looped back and received by the same interface. What is transmitted onto the line is product dependent. dsx1DualLoop both dsx1LineLoop and dsx1InwardLoop will be active simultaneously." ::= { dsx1ConfigEntry 9 } dsx1LineStatus OBJECT-TYPE SYNTAX INTEGER (1..131071) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the line status of the interface. It contains loopback, failure, received alarm and transmitted alarms information. The dsx1LineStatus is a bitmap represented as a sum; therefore, it can represent multiple failures (alarms) and a LoopbackState simultaneously. dsx1NoAlarm must be set if and only if no other flag is set. If the dsx1loopbackState bit is set, the loopback in effect can be determined from the dsx1loopbackConfig object. The various bit positions are as follows: 1 dsx1NoAlarm No alarm present 2 dsx1RcvFarEndLOF Far end LOF (a.k.a. Nicklass, Ed. Standards Track [Page 30] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Yellow Alarm) 4 dsx1XmtFarEndLOF Near end sending LOF indication 8 dsx1RcvAIS Far end sending AIS 16 dsx1XmtAIS Near end sending AIS 32 dsx1LossOfFrame Near end LOF (a.k.a. Red Alarm) 64 dsx1LossOfSignal Near end Loss of Signal 128 dsx1LoopbackState Near end is looped 256 dsx1T16AIS E1 TS16 AIS 512 dsx1RcvFarEndLOMF Far end sending TS16 LOMF 1024 dsx1XmtFarEndLOMF Near end sending TS16 LOMF 2048 dsx1RcvTestCode Near end detects a test code 4096 dsx1OtherFailure Any line status not defined here 8192 dsx1UnavailSigState Near end in unavailable signal state 16384 dsx1NetEquipOOS Carrier equipment out of service 32768 dsx1RcvPayloadAIS DS2 payload AIS 65536 dsx1Ds2PerfThreshold DS2 performance threshold exceeded" ::= { dsx1ConfigEntry 10 } dsx1SignalMode OBJECT-TYPE SYNTAX INTEGER { none(1), robbedBit(2), bitOriented(3), messageOriented(4), other(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "'none' indicates that no bits are reserved for signaling on this channel. 'robbedBit' indicates that DS1 Robbed Bit Signaling is in use. 'bitOriented' indicates that E1 Channel Associated Signaling is in use. 'messageOriented' indicates that Common Channel Signaling is in use on either channel 16 of an E1 link or channel 24 of a DS1." ::= { dsx1ConfigEntry 11 } Nicklass, Ed. Standards Track [Page 31] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1TransmitClockSource OBJECT-TYPE SYNTAX INTEGER { loopTiming(1), localTiming(2), throughTiming(3), adaptive (4) } MAX-ACCESS read-write STATUS current DESCRIPTION "The source of transmit clock. 'loopTiming' indicates that the recovered receive clock is used as the transmit clock. 'localTiming' indicates that a local clock source is used or when an external clock is attached to the box containing the interface. 'throughTiming' indicates that recovered receive clock from another interface is used as the transmit clock. 'adaptive' indicates that the clock is recovered based on the data flow and not based on the physical layer" ::= { dsx1ConfigEntry 12 } dsx1Fdl OBJECT-TYPE SYNTAX INTEGER (1..15) MAX-ACCESS read-write STATUS current DESCRIPTION "This bitmap describes the use of the facilities data link and is the sum of the capabilities. Set any bits that are appropriate: other(1), dsx1AnsiT1403(2), dsx1Att54016(4), dsx1FdlNone(8) 'other' indicates that a protocol other than one of the following is used. 'dsx1AnsiT1403' refers to the FDL exchange recommended by ANSI. Nicklass, Ed. Standards Track [Page 32] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 'dsx1Att54016' refers to ESF FDL exchanges. 'dsx1FdlNone' indicates that the device does not use the FDL." ::= { dsx1ConfigEntry 13 } dsx1InvalidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to dsx1ValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals is not available (e.g., in proxy situations)." ::= { dsx1ConfigEntry 14 } dsx1LineLength OBJECT-TYPE SYNTAX INTEGER (0..64000) UNITS "meters" MAX-ACCESS read-write STATUS current DESCRIPTION "The length of the DS1 line in meters. This object provides information for line build-out circuitry. This object is only useful if the interface has configurable line build-out circuitry." ::= { dsx1ConfigEntry 15 } dsx1LineStatusLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of MIB II's sysUpTime object at the time this DS1 entered its current line status state. If the current state was entered prior to the last re-initialization of the proxy-agent, then this object contains a zero value." ::= { dsx1ConfigEntry 16 } dsx1LineStatusChangeTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } Nicklass, Ed. Standards Track [Page 33] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether dsx1LineStatusChange traps should be generated for this interface." DEFVAL { disabled } ::= { dsx1ConfigEntry 17 } dsx1LoopbackStatus OBJECT-TYPE SYNTAX INTEGER (1..127) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable represents the current state of the loopback on the DS1 interface. It contains information about loopbacks established by a manager and remotely from the far end. The dsx1LoopbackStatus is a bitmap represented as a sum; therefore, it can represent multiple loopbacks simultaneously. The various bit positions are as follows: 1 dsx1NoLoopback 2 dsx1NearEndPayloadLoopback 4 dsx1NearEndLineLoopback 8 dsx1NearEndOtherLoopback 16 dsx1NearEndInwardLoopback 32 dsx1FarEndPayloadLoopback 64 dsx1FarEndLineLoopback" ::= { dsx1ConfigEntry 18 } dsx1Ds1ChannelNumber OBJECT-TYPE SYNTAX INTEGER (0..28) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable represents the channel number of the DS1/E1 on its parent DS2/E2 or DS3/E3. A value of 0 indicates that this DS1/E1 does not have a parent DS3/E3." ::= { dsx1ConfigEntry 19 } dsx1Channelization OBJECT-TYPE SYNTAX INTEGER { disabled(1), enabledDs0(2), Nicklass, Ed. Standards Track [Page 34] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 enabledDs1(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether this DS1/E1 or DS2 is channelized or unchannelized. The value of enabledDs0(2) indicates that this is a DS1 channelized into DS0s. Setting this value will cause the creation, and resetting it to disabled(1) will cause the deletion of entries in the ifTable for the DS0s that are within the DS1. The value of enabledDs1(3) indicates that this is a DS2 channelized into DS1s. Setting this value will cause the creation, and resetting it to disabled(1) will cause the deletion of entries in the ifTable for the DS1s that are within the DS2." ::= { dsx1ConfigEntry 20 } dsx1LineMode OBJECT-TYPE SYNTAX INTEGER { csu(1), dsu(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This setting puts the T1 framer into either long-haul (CSU) mode or short-haul (DSU) mode." ::= { dsx1ConfigEntry 21 } dsx1LineBuildOut OBJECT-TYPE SYNTAX INTEGER { notApplicable(1), neg75dB(2), neg15dB(3), neg225dB(4), zerodB(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "Attenuation setting for T1 framer in long haul (CSU) mode. The optional values are -7.5dB, -15dB, -22.5dB, and 0dB." Nicklass, Ed. Standards Track [Page 35] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 ::= { dsx1ConfigEntry 22 } dsx1LineImpedance OBJECT-TYPE SYNTAX INTEGER { notApplicable(1), unbalanced75ohms(2), balanced100ohms(3), balanced120ohms(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Nominal line impedance. For T1 and J1 lines, the value is typically balanced100ohms(3). For E1 lines, the value is typically unbalanced75ohms(2) and balanced120ohms(4). When this object does not apply, or when the appropriate value is not known, the value should be set to notApplicable(1)." ::= { dsx1ConfigEntry 23 } -- The DS1 Current Table dsx1CurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1CurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Current table contains various statistics being collected for the current 15-minute interval." ::= { ds1 7 } dsx1CurrentEntry OBJECT-TYPE SYNTAX Dsx1CurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Current table." INDEX { dsx1CurrentIndex } ::= { dsx1CurrentTable 1 } Dsx1CurrentEntry ::= SEQUENCE { dsx1CurrentIndex InterfaceIndex, dsx1CurrentESs PerfCurrentCount, dsx1CurrentSESs PerfCurrentCount, dsx1CurrentSEFSs PerfCurrentCount, dsx1CurrentUASs PerfCurrentCount, dsx1CurrentCSSs PerfCurrentCount, Nicklass, Ed. Standards Track [Page 36] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1CurrentPCVs PerfCurrentCount, dsx1CurrentLESs PerfCurrentCount, dsx1CurrentBESs PerfCurrentCount, dsx1CurrentDMs PerfCurrentCount, dsx1CurrentLCVs PerfCurrentCount } dsx1CurrentIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value that uniquely identifies the DS1 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value as a dsx1LineIndex object instance." ::= { dsx1CurrentEntry 1 } dsx1CurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Errored Seconds." ::= { dsx1CurrentEntry 2 } dsx1CurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Seconds." ::= { dsx1CurrentEntry 3 } dsx1CurrentSEFSs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Framing Seconds." ::= { dsx1CurrentEntry 4 } dsx1CurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current Nicklass, Ed. Standards Track [Page 37] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 DESCRIPTION "The number of Unavailable Seconds." ::= { dsx1CurrentEntry 5 } dsx1CurrentCSSs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Controlled Slip Seconds." ::= { dsx1CurrentEntry 6 } dsx1CurrentPCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Path Coding Violations." ::= { dsx1CurrentEntry 7 } dsx1CurrentLESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Errored Seconds." ::= { dsx1CurrentEntry 8 } dsx1CurrentBESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Bursty Errored Seconds." ::= { dsx1CurrentEntry 9 } dsx1CurrentDMs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of Degraded Minutes." ::= { dsx1CurrentEntry 10 } dsx1CurrentLCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current Nicklass, Ed. Standards Track [Page 38] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 DESCRIPTION "The number of Line Coding Violations (LCVs)." ::= { dsx1CurrentEntry 11 } -- The DS1 Interval Table dsx1IntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1IntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Interval table contains various statistics collected by each DS1 interface over the previous 24 hours of operation. The past 24 hours are broken into 96 completed 15-minute intervals. Each row in this table represents one such interval (identified by dsx1IntervalNumber) for one specific instance (identified by dsx1IntervalIndex)." ::= { ds1 8 } dsx1IntervalEntry OBJECT-TYPE SYNTAX Dsx1IntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Interval table." INDEX { dsx1IntervalIndex, dsx1IntervalNumber } ::= { dsx1IntervalTable 1 } Dsx1IntervalEntry ::= SEQUENCE { dsx1IntervalIndex InterfaceIndex, dsx1IntervalNumber INTEGER, dsx1IntervalESs PerfIntervalCount, dsx1IntervalSESs PerfIntervalCount, dsx1IntervalSEFSs PerfIntervalCount, dsx1IntervalUASs PerfIntervalCount, dsx1IntervalCSSs PerfIntervalCount, dsx1IntervalPCVs PerfIntervalCount, dsx1IntervalLESs PerfIntervalCount, dsx1IntervalBESs PerfIntervalCount, dsx1IntervalDMs PerfIntervalCount, dsx1IntervalLCVs PerfIntervalCount, dsx1IntervalValidData TruthValue } dsx1IntervalIndex OBJECT-TYPE SYNTAX InterfaceIndex Nicklass, Ed. Standards Track [Page 39] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value that uniquely identifies the DS1 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value as a dsx1LineIndex object instance." ::= { dsx1IntervalEntry 1 } dsx1IntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..96) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "A number between 1 and 96, where 1 is the most recently completed 15-minute interval and 96 is the 15-minute interval completed 23 hours and 45 minutes prior to interval 1." ::= { dsx1IntervalEntry 2 } dsx1IntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Errored Seconds." ::= { dsx1IntervalEntry 3 } dsx1IntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Seconds." ::= { dsx1IntervalEntry 4 } dsx1IntervalSEFSs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Framing Seconds." ::= { dsx1IntervalEntry 5 } dsx1IntervalUASs OBJECT-TYPE Nicklass, Ed. Standards Track [Page 40] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Unavailable Seconds. This object may decrease if the occurrence of unavailable seconds occurs across an interval boundary." ::= { dsx1IntervalEntry 6 } dsx1IntervalCSSs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Controlled Slip Seconds." ::= { dsx1IntervalEntry 7 } dsx1IntervalPCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Path Coding Violations." ::= { dsx1IntervalEntry 8 } dsx1IntervalLESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Errored Seconds." ::= { dsx1IntervalEntry 9 } dsx1IntervalBESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Bursty Errored Seconds." ::= { dsx1IntervalEntry 10 } dsx1IntervalDMs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of Degraded Minutes." ::= { dsx1IntervalEntry 11 } Nicklass, Ed. Standards Track [Page 41] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1IntervalLCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Coding Violations." ::= { dsx1IntervalEntry 12 } dsx1IntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates whether the data for this interval is valid." ::= { dsx1IntervalEntry 13 } -- The DS1 Total Table dsx1TotalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1TotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Total table contains the cumulative sum of the various statistics for the 24-hour period preceding the current interval." ::= { ds1 9 } dsx1TotalEntry OBJECT-TYPE SYNTAX Dsx1TotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Total table." INDEX { dsx1TotalIndex } ::= { dsx1TotalTable 1 } Dsx1TotalEntry ::= SEQUENCE { dsx1TotalIndex InterfaceIndex, dsx1TotalESs PerfTotalCount, dsx1TotalSESs PerfTotalCount, dsx1TotalSEFSs PerfTotalCount, dsx1TotalUASs PerfTotalCount, dsx1TotalCSSs PerfTotalCount, dsx1TotalPCVs PerfTotalCount, dsx1TotalLESs PerfTotalCount, dsx1TotalBESs PerfTotalCount, Nicklass, Ed. Standards Track [Page 42] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1TotalDMs PerfTotalCount, dsx1TotalLCVs PerfTotalCount } dsx1TotalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value that uniquely identifies the DS1 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value as a dsx1LineIndex object instance." ::= { dsx1TotalEntry 1 } dsx1TotalESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Errored Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 2 } dsx1TotalSESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 3 } dsx1TotalSEFSs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Framing Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 4 } Nicklass, Ed. Standards Track [Page 43] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1TotalUASs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Unavailable Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 5 } dsx1TotalCSSs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Controlled Slip Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 6 } dsx1TotalPCVs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Path Coding Violations encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 7 } dsx1TotalLESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Errored Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 8 } dsx1TotalBESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Bursty Errored Seconds (BESs) Nicklass, Ed. Standards Track [Page 44] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 9 } dsx1TotalDMs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of Degraded Minutes (DMs) encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 10 } dsx1TotalLCVs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Coding Violations (LCVs) encountered by a DS1 interface in the current 15-minute interval. Invalid 15-minute intervals count as 0." ::= { dsx1TotalEntry 11 } -- The DS1 Channel Table dsx1ChanMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1ChanMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Channel Mapping table. This table maps a DS1 channel number on a particular DS3 into an ifIndex. In the presence of DS2s, this table can be used to map a DS2 channel number on a DS3 into an ifIndex, or used to map a DS1 channel number on a DS2 into an ifIndex." ::= { ds1 16 } dsx1ChanMappingEntry OBJECT-TYPE SYNTAX Dsx1ChanMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Channel Mapping table. There Nicklass, Ed. Standards Track [Page 45] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 is an entry in this table corresponding to each DS1 ifEntry within any interface that is channelized to the individual DS1 ifEntry level. This table is intended to facilitate mapping from channelized interface / channel number to DS1 ifEntry (e.g., mapping (DS3 ifIndex, DS1 channel number) -> ifIndex). While this table provides information that can also be found in the ifStackTable and dsx1ConfigTable, it provides this same information with a single table lookup, rather than by walking the ifStackTable to find the various constituent DS1 ifTable entries, and testing various dsx1ConfigTable entries to check for the entry with the applicable DS1 channel number." INDEX { ifIndex, dsx1Ds1ChannelNumber } ::= { dsx1ChanMappingTable 1 } Dsx1ChanMappingEntry ::= SEQUENCE { dsx1ChanMappedIfIndex InterfaceIndex } dsx1ChanMappedIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the ifIndex value assigned by the agent for the individual DS1 ifEntry that corresponds to the given DS1 channel number (specified by the INDEX element dsx1Ds1ChannelNumber) of the given channelized interface (specified by INDEX element ifIndex)." ::= { dsx1ChanMappingEntry 1 } -- The DS1 Far End Current Table dsx1FarEndCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1FarEndCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Far End Current table contains various statistics being collected for the current 15-minute interval. The statistics are collected Nicklass, Ed. Standards Track [Page 46] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 from the far-end messages on the Facilities Data Link. The definitions are the same as described for the near-end information." ::= { ds1 10 } dsx1FarEndCurrentEntry OBJECT-TYPE SYNTAX Dsx1FarEndCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Far End Current table." INDEX { dsx1FarEndCurrentIndex } ::= { dsx1FarEndCurrentTable 1 } Dsx1FarEndCurrentEntry ::= SEQUENCE { dsx1FarEndCurrentIndex InterfaceIndex, dsx1FarEndTimeElapsed INTEGER, dsx1FarEndValidIntervals INTEGER, dsx1FarEndCurrentESs PerfCurrentCount, dsx1FarEndCurrentSESs PerfCurrentCount, dsx1FarEndCurrentSEFSs PerfCurrentCount, dsx1FarEndCurrentUASs PerfCurrentCount, dsx1FarEndCurrentCSSs PerfCurrentCount, dsx1FarEndCurrentLESs PerfCurrentCount, dsx1FarEndCurrentPCVs PerfCurrentCount, dsx1FarEndCurrentBESs PerfCurrentCount, dsx1FarEndCurrentDMs PerfCurrentCount, dsx1FarEndInvalidIntervals INTEGER } dsx1FarEndCurrentIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value that uniquely identifies the DS1 interface to which this entry is applicable. The interface identified by a particular value of this index is identical to the interface identified by the same value of dsx1LineIndex." ::= { dsx1FarEndCurrentEntry 1 } dsx1FarEndTimeElapsed OBJECT-TYPE SYNTAX INTEGER (0..899) MAX-ACCESS read-only STATUS current Nicklass, Ed. Standards Track [Page 47] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 DESCRIPTION "The number of seconds that have elapsed since the beginning of the far-end current error-measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, the agent will return the maximum value." ::= { dsx1FarEndCurrentEntry 2 } dsx1FarEndValidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous far-end intervals for which data was collected. The value will be 96 unless the interface was brought online within the last 24 hours, in which case the value will be the number of complete 15-minute far-end intervals since the interface has been online. In the case where the agent is a proxy, it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { dsx1FarEndCurrentEntry 3 } dsx1FarEndCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Errored Seconds." ::= { dsx1FarEndCurrentEntry 4 } dsx1FarEndCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Severely Errored Seconds." ::= { dsx1FarEndCurrentEntry 5 } dsx1FarEndCurrentSEFSs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Severely Errored Framing Nicklass, Ed. Standards Track [Page 48] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Seconds." ::= { dsx1FarEndCurrentEntry 6 } dsx1FarEndCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Unavailable Seconds." ::= { dsx1FarEndCurrentEntry 7 } dsx1FarEndCurrentCSSs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Controlled Slip Seconds." ::= { dsx1FarEndCurrentEntry 8 } dsx1FarEndCurrentLESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Line Errored Seconds." ::= { dsx1FarEndCurrentEntry 9 } dsx1FarEndCurrentPCVs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Path Coding Violations." ::= { dsx1FarEndCurrentEntry 10 } dsx1FarEndCurrentBESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Bursty Errored Seconds." ::= { dsx1FarEndCurrentEntry 11 } dsx1FarEndCurrentDMs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS deprecated DESCRIPTION Nicklass, Ed. Standards Track [Page 49] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 "The number of Far End Degraded Minutes." ::= { dsx1FarEndCurrentEntry 12 } dsx1FarEndInvalidIntervals OBJECT-TYPE SYNTAX INTEGER (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of intervals in the range from 0 to dsx1FarEndValidIntervals for which no data is available. This object will typically be zero except in cases where the data for some intervals is not available (e.g., in proxy situations)." ::= { dsx1FarEndCurrentEntry 13 } -- The DS1 Far End Interval Table dsx1FarEndIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1FarEndIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Far End Interval table contains various statistics collected by each DS1 interface over the previous 24 hours of operation. The past 24 hours are broken into 96 completed 15-minute intervals. Each row in this table represents one such interval (identified by dsx1FarEndIntervalNumber) for one specific instance (identified by dsx1FarEndIntervalIndex)." ::= { ds1 11 } dsx1FarEndIntervalEntry OBJECT-TYPE SYNTAX Dsx1FarEndIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Far End Interval table." INDEX { dsx1FarEndIntervalIndex, dsx1FarEndIntervalNumber } ::= { dsx1FarEndIntervalTable 1 } Dsx1FarEndIntervalEntry ::= SEQUENCE { dsx1FarEndIntervalIndex InterfaceIndex, dsx1FarEndIntervalNumber INTEGER, dsx1FarEndIntervalESs PerfIntervalCount, dsx1FarEndIntervalSESs PerfIntervalCount, Nicklass, Ed. Standards Track [Page 50] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1FarEndIntervalSEFSs PerfIntervalCount, dsx1FarEndIntervalUASs PerfIntervalCount, dsx1FarEndIntervalCSSs PerfIntervalCount, dsx1FarEndIntervalLESs PerfIntervalCount, dsx1FarEndIntervalPCVs PerfIntervalCount, dsx1FarEndIntervalBESs PerfIntervalCount, dsx1FarEndIntervalDMs PerfIntervalCount, dsx1FarEndIntervalValidData TruthValue } dsx1FarEndIntervalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value that uniquely identifies the DS1 interface to which this entry is applicable. The interface identified by a particular value of this index is identical to the interface identified by the same value of dsx1LineIndex." ::= { dsx1FarEndIntervalEntry 1 } dsx1FarEndIntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..96) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "A number between 1 and 96, where 1 is the most recently completed 15-minute interval and 96 is the 15 minutes interval completed 23 hours and 45 minutes prior to interval 1." ::= { dsx1FarEndIntervalEntry 2 } dsx1FarEndIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Errored Seconds." ::= { dsx1FarEndIntervalEntry 3 } dsx1FarEndIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION Nicklass, Ed. Standards Track [Page 51] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 "The number of Far End Severely Errored Seconds." ::= { dsx1FarEndIntervalEntry 4 } dsx1FarEndIntervalSEFSs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Severely Errored Framing Seconds." ::= { dsx1FarEndIntervalEntry 5 } dsx1FarEndIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Unavailable Seconds." ::= { dsx1FarEndIntervalEntry 6 } dsx1FarEndIntervalCSSs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Controlled Slip Seconds." ::= { dsx1FarEndIntervalEntry 7 } dsx1FarEndIntervalLESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Line Errored Seconds." ::= { dsx1FarEndIntervalEntry 8 } dsx1FarEndIntervalPCVs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Path Coding Violations." ::= { dsx1FarEndIntervalEntry 9 } dsx1FarEndIntervalBESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current Nicklass, Ed. Standards Track [Page 52] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 DESCRIPTION "The number of Far End Bursty Errored Seconds." ::= { dsx1FarEndIntervalEntry 10 } dsx1FarEndIntervalDMs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of Far End Degraded Minutes." ::= { dsx1FarEndIntervalEntry 11 } dsx1FarEndIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION " This variable indicates if the data for this interval is valid." ::= { dsx1FarEndIntervalEntry 12 } -- The DS1 Far End Total Table dsx1FarEndTotalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1FarEndTotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Far End Total table contains the cumulative sum of the various statistics for the 24-hour period preceding the current interval." ::= { ds1 12 } dsx1FarEndTotalEntry OBJECT-TYPE SYNTAX Dsx1FarEndTotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS1 Far End Total table." INDEX { dsx1FarEndTotalIndex } ::= { dsx1FarEndTotalTable 1 } Dsx1FarEndTotalEntry ::= SEQUENCE { dsx1FarEndTotalIndex InterfaceIndex, dsx1FarEndTotalESs PerfTotalCount, dsx1FarEndTotalSESs PerfTotalCount, dsx1FarEndTotalSEFSs PerfTotalCount, Nicklass, Ed. Standards Track [Page 53] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1FarEndTotalUASs PerfTotalCount, dsx1FarEndTotalCSSs PerfTotalCount, dsx1FarEndTotalLESs PerfTotalCount, dsx1FarEndTotalPCVs PerfTotalCount, dsx1FarEndTotalBESs PerfTotalCount, dsx1FarEndTotalDMs PerfTotalCount } dsx1FarEndTotalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "The index value that uniquely identifies the DS1 interface to which this entry is applicable. The interface identified by a particular value of this index is identical to the interface identified by the same value of dsx1LineIndex." ::= { dsx1FarEndTotalEntry 1 } dsx1FarEndTotalESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Errored Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1FarEndTotalEntry 2 } dsx1FarEndTotalSESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Severely Errored Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1FarEndTotalEntry 3 } dsx1FarEndTotalSEFSs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION Nicklass, Ed. Standards Track [Page 54] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 "The number of Far End Severely Errored Framing Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1FarEndTotalEntry 4 } dsx1FarEndTotalUASs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Unavailable Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1FarEndTotalEntry 5 } dsx1FarEndTotalCSSs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Controlled Slip Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15 minute intervals count as 0." ::= { dsx1FarEndTotalEntry 6 } dsx1FarEndTotalLESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Line Errored Seconds encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1FarEndTotalEntry 7 } dsx1FarEndTotalPCVs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Path Coding Violations reported via the far end block error count encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." Nicklass, Ed. Standards Track [Page 55] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 ::= { dsx1FarEndTotalEntry 8 } dsx1FarEndTotalBESs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Bursty Errored Seconds (BESs) encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1FarEndTotalEntry 9 } dsx1FarEndTotalDMs OBJECT-TYPE SYNTAX PerfTotalCount MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of Degraded Minutes (DMs) encountered by a DS1 interface in the previous 24-hour interval. Invalid 15-minute intervals count as 0." ::= { dsx1FarEndTotalEntry 10 } -- The DS1 Fractional Table dsx1FracTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1FracEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table is deprecated in favor of using ifStackTable. The table was mandatory for systems dividing a DS1 into channels containing different data streams that are of local interest. Systems that are indifferent to data content, such as CSUs, need not implement it. The DS1 Fractional table identifies which DS1 channels associated with a CSU are being used to support a logical interface, i.e., an entry in the interfaces table from the Internet-standard MIB. For example, consider an application managing a North American ISDN Primary Rate link whose division is a 384-kbit/s H1 _B_ Channel for video, Nicklass, Ed. Standards Track [Page 56] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 a second H1 for data to a primary routing peer, and 12 64-kbit/s H0 _B_ Channels. Consider that some subset of the H0 channels is used for voice and the remainder are available for dynamic data calls. We count a total of 14 interfaces multiplexed onto the DS1 interface. Six DS1 channels (for the sake of the example, channels 1..6) are used for video, six more (7..11 and 13) are used for data, and the remaining 12 are in channels 12 and 14..24. Let us further imagine that ifIndex 2 is of type DS1 and refers to the DS1 interface and that the interfaces layered onto it are numbered 3..16. We might describe the allocation of channels, in the dsx1FracTable, as follows: dsx1FracIfIndex.2. 1 = 3 dsx1FracIfIndex.2.13 = 4 dsx1FracIfIndex.2. 2 = 3 dsx1FracIfIndex.2.14 = 6 dsx1FracIfIndex.2. 3 = 3 dsx1FracIfIndex.2.15 = 7 dsx1FracIfIndex.2. 4 = 3 dsx1FracIfIndex.2.16 = 8 dsx1FracIfIndex.2. 5 = 3 dsx1FracIfIndex.2.17 = 9 dsx1FracIfIndex.2. 6 = 3 dsx1FracIfIndex.2.18 = 10 dsx1FracIfIndex.2. 7 = 4 dsx1FracIfIndex.2.19 = 11 dsx1FracIfIndex.2. 8 = 4 dsx1FracIfIndex.2.20 = 12 dsx1FracIfIndex.2. 9 = 4 dsx1FracIfIndex.2.21 = 13 dsx1FracIfIndex.2.10 = 4 dsx1FracIfIndex.2.22 = 14 dsx1FracIfIndex.2.11 = 4 dsx1FracIfIndex.2.23 = 15 dsx1FracIfIndex.2.12 = 5 dsx1FracIfIndex.2.24 = 16 For North American (DS1) interfaces, there are 24 legal channels, numbered 1 through 24. For G.704 interfaces, there are 31 legal channels, numbered 1 through 31. The channels (1..31) correspond directly to the equivalently numbered time-slots." ::= { ds1 13 } dsx1FracEntry OBJECT-TYPE SYNTAX Dsx1FracEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry in the DS1 Fractional table." INDEX { dsx1FracIndex, dsx1FracNumber } ::= { dsx1FracTable 1 } Nicklass, Ed. Standards Track [Page 57] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Dsx1FracEntry ::= SEQUENCE { dsx1FracIndex INTEGER, dsx1FracNumber INTEGER, dsx1FracIfIndex INTEGER } dsx1FracIndex OBJECT-TYPE SYNTAX INTEGER (1..'7fffffff'h) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "The index value that uniquely identifies the DS1 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value as a dsx1LineIndex object instance." ::= { dsx1FracEntry 1 } dsx1FracNumber OBJECT-TYPE SYNTAX INTEGER (1..31) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "The channel number for this entry." ::= { dsx1FracEntry 2 } dsx1FracIfIndex OBJECT-TYPE SYNTAX INTEGER (0..'7fffffff'h) MAX-ACCESS read-write STATUS deprecated DESCRIPTION "An index value that uniquely identifies an interface. The interface identified by a particular value of this index is the same interface as identified by the same value as an ifIndex object instance. If no interface is currently using a channel, the value should be zero. If a single interface occupies more than one time-slot, that ifIndex value will be found in multiple time-slots." ::= { dsx1FracEntry 3 } -- DS1 TRAPS Nicklass, Ed. Standards Track [Page 58] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 ds1Traps OBJECT IDENTIFIER ::= { ds1 15 } dsx1LineStatusChange NOTIFICATION-TYPE OBJECTS { dsx1LineStatus, dsx1LineStatusLastChange } STATUS current DESCRIPTION "A dsx1LineStatusChange trap is sent when the value of an instance dsx1LineStatus changes. It can be utilized by an Network Management Station (NMS) to trigger polls. When the line status change results from a higher-level line status change (i.e., DS3), then no traps for the DS1 are sent." ::= { ds1Traps 0 1 } -- conformance information ds1Conformance OBJECT IDENTIFIER ::= { ds1 14 } ds1Groups OBJECT IDENTIFIER ::= { ds1Conformance 1 } ds1Compliances OBJECT IDENTIFIER ::= { ds1Conformance 2 } -- compliance statements ds1Compliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for T1 and E1 interfaces." MODULE -- this module MANDATORY-GROUPS { ds1NearEndConfigGroup, ds1NearEndStatisticsGroup } GROUP ds1FarEndGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS1 interface." GROUP ds1NearEndOptionalConfigGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS1 interface." GROUP ds1DS2Group DESCRIPTION "Implementation of this group is mandatory for all systems that attach to a DS2 interface." Nicklass, Ed. Standards Track [Page 59] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 GROUP ds1TransStatsGroup DESCRIPTION "This group is the set of statistics appropriate for all systems that attach to a DS1 interface running transparent or unFramed lineType." GROUP ds1ChanMappingGroup DESCRIPTION "This group is the set of objects for mapping a DS3 Channel (dsx1Ds1ChannelNumber) to ifIndex. Implementation of this group is mandatory for systems that support the channelization of DS3s into DS1s." OBJECT dsx1LineType SYNTAX INTEGER { other(1), dsx1ESF(2), dsx1D4(3), dsx1E1(4), dsx1E1CRC(5), dsx1E1MF(6), dsx1E1CRCMF(7), dsx1Unframed(8), dsx1E1Unframed(9), dsx1DS2M12(10), dsx1E2(11) } MIN-ACCESS read-only DESCRIPTION "The ability to set the line type is not required." OBJECT dsx1LineCoding MIN-ACCESS read-only DESCRIPTION "The ability to set the line coding is not required." OBJECT dsx1SendCode MIN-ACCESS read-only DESCRIPTION "The ability to set the send code is not required." OBJECT dsx1LoopbackConfig MIN-ACCESS read-only DESCRIPTION Nicklass, Ed. Standards Track [Page 60] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 "The ability to set loopbacks is not required." OBJECT dsx1SignalMode MIN-ACCESS read-only DESCRIPTION "The ability to set the signal mode is not required." OBJECT dsx1TransmitClockSource SYNTAX INTEGER { loopTiming(1), localTiming(2), throughTiming(3) } MIN-ACCESS read-only DESCRIPTION "The ability to set the transmit clock source is not required." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "The ability to set the FDL is not required." OBJECT dsx1LineLength MIN-ACCESS read-only DESCRIPTION "The ability to set the line length is not required." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization is not required." ::= { ds1Compliances 1 } ds1MibT1PriCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "Compliance statement for using this MIB for ISDN Primary Rate interfaces on T1 lines." MODULE MANDATORY-GROUPS { ds1NearEndConfigGroup, ds1NearEndStatisticsGroup } OBJECT dsx1LineType SYNTAX INTEGER { dsx1ESF(2) -- Intl Spec would be G704(2) Nicklass, Ed. Standards Track [Page 61] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 -- or I.431(4) } MIN-ACCESS read-only DESCRIPTION "Line type for T1 ISDN Primary Rate interfaces." OBJECT dsx1LineCoding SYNTAX INTEGER { dsx1B8ZS(2) } MIN-ACCESS read-only DESCRIPTION "Type of Zero Code Suppression for T1 ISDN Primary Rate interfaces." OBJECT dsx1SignalMode SYNTAX INTEGER { none(1), -- if there is no signaling channel messageOriented(4) } MIN-ACCESS read-only DESCRIPTION "Possible signaling modes for T1 ISDN Primary Rate interfaces." OBJECT dsx1TransmitClockSource SYNTAX INTEGER { loopTiming(1) } MIN-ACCESS read-only DESCRIPTION "The transmit clock is derived from received clock on ISDN Primary Rate interfaces." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "Facilities Data Link usage on T1 ISDN Primary Rate interfaces. Note: Eventually, dsx1Att-54016(4) is to be used here since the line type is ESF." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization Nicklass, Ed. Standards Track [Page 62] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 is not required." ::= { ds1Compliances 2 } ds1MibE1PriCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "Compliance statement for using this MIB for ISDN Primary Rate interfaces on E1 lines." MODULE MANDATORY-GROUPS { ds1NearEndConfigGroup, ds1NearEndStatisticsGroup } OBJECT dsx1LineType SYNTAX INTEGER { dsx1E1CRC(5) } MIN-ACCESS read-only DESCRIPTION "Line type for E1 ISDN Primary Rate interfaces." OBJECT dsx1LineCoding SYNTAX INTEGER { dsx1HDB3(3) } MIN-ACCESS read-only DESCRIPTION "Type of Zero Code Suppression for E1 ISDN Primary Rate interfaces." OBJECT dsx1SignalMode SYNTAX INTEGER { messageOriented(4) } MIN-ACCESS read-only DESCRIPTION "Signaling on E1 ISDN Primary Rate interfaces is always message oriented." OBJECT dsx1TransmitClockSource SYNTAX INTEGER { loopTiming(1) } MIN-ACCESS read-only DESCRIPTION "The transmit clock is derived from received clock on ISDN Primary Rate interfaces." OBJECT dsx1Fdl Nicklass, Ed. Standards Track [Page 63] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 MIN-ACCESS read-only DESCRIPTION "Facilities Data Link usage on E1 ISDN Primary Rate interfaces. Note: There is an 'M-Channel' in E1, using National Bit Sa4 (G.704, Table 5A). It is used to implement management features between ET and NT. This is different from FDL in T1, which is used to carry control signals and performance data. In E1, control and status signals are carried using National Bits Sa5, Sa6, and A (RAI Ind.). This indicates that only the other(1) or eventually the dsx1Fdl-none(8) bits should be set in this object for E1 PRI." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization is not required." ::= { ds1Compliances 3 } ds1Ds2Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for using this MIB for DS2 interfaces." MODULE MANDATORY-GROUPS { ds1DS2Group } OBJECT dsx1LineType SYNTAX INTEGER { dsx1DS2M12(10), dsx1E2(11) } MIN-ACCESS read-only DESCRIPTION "Line type for DS2, E2 interfaces." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization is not required." Nicklass, Ed. Standards Track [Page 64] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 ::= { ds1Compliances 4 } ds1NCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for T1 and E1 interfaces." MODULE -- this module MANDATORY-GROUPS { ds1NearEndConfigurationGroup, ds1NearEndStatisticsGroup } GROUP ds1FarEndGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS1 interface." GROUP ds1NearEndOptionalTrapGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS1 interface. If it is implemented, then ds1NearEndOptionalConfigGroup should also be implemented." GROUP ds1NearEndOptionalConfigGroup DESCRIPTION "Implementation of this group is recommended for all systems that attach to a DS1 interface and implement ds1NearEndOptionalTrapGroup." GROUP ds1DS2Group DESCRIPTION "Implementation of this group is mandatory for all systems that attach to a DS2 interface." GROUP ds1TransStatsGroup DESCRIPTION "This group is the set of statistics appropriate for all systems that attach to a DS1 interface running transparent or unFramed lineType." GROUP ds1ChanMappingGroup DESCRIPTION "This group is the set of objects for mapping a DS3 Channel (dsx1Ds1ChannelNumber) to ifIndex. Implementation of this group is mandatory for systems that support the channelization of DS3s into DS1s." Nicklass, Ed. Standards Track [Page 65] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 OBJECT dsx1LineType MIN-ACCESS read-only DESCRIPTION "The ability to set the line type is not required." OBJECT dsx1LineCoding MIN-ACCESS read-only DESCRIPTION "The ability to set the line coding is not required." OBJECT dsx1SendCode MIN-ACCESS read-only DESCRIPTION "The ability to set the send code is not required." OBJECT dsx1LoopbackConfig MIN-ACCESS read-only DESCRIPTION "The ability to set loopbacks is not required." OBJECT dsx1SignalMode MIN-ACCESS read-only DESCRIPTION "The ability to set the signal mode is not required." OBJECT dsx1TransmitClockSource MIN-ACCESS read-only DESCRIPTION "The ability to set the transmit clock source is not required." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "The ability to set the FDL is not required." OBJECT dsx1LineLength MIN-ACCESS read-only DESCRIPTION "The ability to set the line length is not required." OBJECT dsx1Channelization MIN-ACCESS read-only Nicklass, Ed. Standards Track [Page 66] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 DESCRIPTION "The ability to set the channelization is not required." OBJECT dsx1LineMode MIN-ACCESS read-only DESCRIPTION "The ability to set the line mode is not required." OBJECT dsx1LineBuildOut MIN-ACCESS read-only DESCRIPTION "The ability to set the line build-out is not required." ::= { ds1Compliances 5 } ds1MibT1PriNCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "Compliance statement for using this MIB for ISDN Primary Rate interfaces on T1 lines." MODULE MANDATORY-GROUPS { ds1NearEndConfigurationGroup, ds1NearEndStatisticsGroup } OBJECT dsx1LineType SYNTAX INTEGER { dsx1ESF(2) -- Intl Spec would be G704(2) -- or I.431(4) } MIN-ACCESS read-only DESCRIPTION "Line type for T1 ISDN Primary Rate interfaces." OBJECT dsx1LineCoding SYNTAX INTEGER { dsx1B8ZS(2) } MIN-ACCESS read-only DESCRIPTION "Type of Zero Code Suppression for T1 ISDN Primary Rate interfaces." OBJECT dsx1SignalMode SYNTAX INTEGER { none(1), -- if there is no signaling channel messageOriented(4) Nicklass, Ed. Standards Track [Page 67] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 } MIN-ACCESS read-only DESCRIPTION "Possible signaling modes for T1 ISDN Primary Rate interfaces." OBJECT dsx1TransmitClockSource SYNTAX INTEGER { loopTiming(1) } MIN-ACCESS read-only DESCRIPTION "The transmit clock is derived from received clock on ISDN Primary Rate interfaces." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "Facilities Data Link usage on T1 ISDN Primary Rate interfaces. Note: Eventually, dsx1Att-54016(4) is to be used here since the line type is ESF." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization is not required." OBJECT dsx1LineMode MIN-ACCESS read-only DESCRIPTION "The ability to set the line mode is not required." OBJECT dsx1LineBuildOut MIN-ACCESS read-only DESCRIPTION "The ability to set the line build-out is not required." ::= { ds1Compliances 6 } ds1MibE1PriNCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "Compliance statement for using this MIB for ISDN Primary Rate interfaces on E1 lines." Nicklass, Ed. Standards Track [Page 68] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 MODULE MANDATORY-GROUPS { ds1NearEndConfigurationGroup, ds1NearEndStatisticsGroup } OBJECT dsx1LineType SYNTAX INTEGER { dsx1E1CRC(5) } MIN-ACCESS read-only DESCRIPTION "Line type for E1 ISDN Primary Rate interfaces." OBJECT dsx1LineCoding SYNTAX INTEGER { dsx1HDB3(3) } MIN-ACCESS read-only DESCRIPTION "Type of Zero Code Suppression for E1 ISDN Primary Rate interfaces." OBJECT dsx1SignalMode SYNTAX INTEGER { messageOriented(4) } MIN-ACCESS read-only DESCRIPTION "Signaling on E1 ISDN Primary Rate interfaces is always message oriented." OBJECT dsx1TransmitClockSource SYNTAX INTEGER { loopTiming(1) } MIN-ACCESS read-only DESCRIPTION "The transmit clock is derived from received clock on ISDN Primary Rate interfaces." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "Facilities Data Link usage on E1 ISDN Primary Rate interfaces. Note: There is an 'M-Channel' in E1, using National Bit Sa4 (G704, Table 5A). It is used to implement Nicklass, Ed. Standards Track [Page 69] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 management features between ET and NT. This is different from FDL in T1, which is used to carry control signals and performance data. In E1, control and status signals are carried using National Bits Sa5, Sa6, and A (RAI Ind.). This indicates that only the other(1) or eventually the dsx1Fdl-none(8) bits should be set in this object for E1 PRI." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization is not required." OBJECT dsx1LineMode MIN-ACCESS read-only DESCRIPTION "The ability to set the line mode is not required." OBJECT dsx1LineBuildOut MIN-ACCESS read-only DESCRIPTION "The ability to set the line build-out is not required." ::= { ds1Compliances 7 } ds1J1Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for T1, J1, and E1 interfaces." MODULE -- this module MANDATORY-GROUPS { ds1NearEndCfgGroup, ds1NearEndStatGroup } GROUP ds1FarEndNGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS1 interface." GROUP ds1NearEndOptionalTrapGroup DESCRIPTION "Implementation of this group is optional for all systems that attach to a DS1 interface. If it is Nicklass, Ed. Standards Track [Page 70] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 implemented, then ds1NearEndOptionalConfigGroup should also be implemented." GROUP ds1NearEndOptionalConfigGroup DESCRIPTION "Implementation of this group is recommended for all systems that attach to a DS1 interface and implement ds1NearEndOptionalTrapGroup." GROUP ds1DS2Group DESCRIPTION "Implementation of this group is mandatory for all systems that attach to a DS2 interface." GROUP ds1TransStatsGroup DESCRIPTION "This group is the set of statistics appropriate for all systems that attach to a DS1 interface running transparent or unFramed lineType." GROUP ds1ChanMappingGroup DESCRIPTION "This group is the set of objects for mapping a DS3 Channel (dsx1Ds1ChannelNumber) to ifIndex. Implementation of this group is mandatory for systems that support the channelization of DS3s into DS1s." OBJECT dsx1LineType MIN-ACCESS read-only DESCRIPTION "The ability to set the line type is not required." OBJECT dsx1LineCoding MIN-ACCESS read-only DESCRIPTION "The ability to set the line coding is not required." OBJECT dsx1SendCode MIN-ACCESS read-only DESCRIPTION "The ability to set the send code is not required." OBJECT dsx1LoopbackConfig MIN-ACCESS read-only Nicklass, Ed. Standards Track [Page 71] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 DESCRIPTION "The ability to set loopbacks is not required." OBJECT dsx1SignalMode MIN-ACCESS read-only DESCRIPTION "The ability to set the signal mode is not required." OBJECT dsx1TransmitClockSource MIN-ACCESS read-only DESCRIPTION "The ability to set the transmit clock source is not required." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "The ability to set the FDL is not required." OBJECT dsx1LineLength MIN-ACCESS read-only DESCRIPTION "The ability to set the line length is not required." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization is not required." OBJECT dsx1LineMode MIN-ACCESS read-only DESCRIPTION "The ability to set the line mode is not required." OBJECT dsx1LineBuildOut MIN-ACCESS read-only DESCRIPTION "The ability to set the line build-out is not required." OBJECT dsx1LineImpedance MIN-ACCESS read-only DESCRIPTION "The ability to set line impedance is not Nicklass, Ed. Standards Track [Page 72] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 required." ::= { ds1Compliances 8 } ds1NMibT1PriNCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for using this MIB for ISDN Primary Rate interfaces on T1 lines." MODULE MANDATORY-GROUPS { ds1NearEndCfgGroup, ds1NearEndStatGroup } OBJECT dsx1LineType SYNTAX INTEGER { dsx1ESF(2) -- Intl Spec would be G704(2) -- or I.431(4) } MIN-ACCESS read-only DESCRIPTION "Line type for T1 ISDN Primary Rate interfaces." OBJECT dsx1LineCoding SYNTAX INTEGER { dsx1B8ZS(2) } MIN-ACCESS read-only DESCRIPTION "Type of Zero Code Suppression for T1 ISDN Primary Rate interfaces." OBJECT dsx1SignalMode SYNTAX INTEGER { none(1), -- if there is no signaling channel messageOriented(4) } MIN-ACCESS read-only DESCRIPTION "Possible signaling modes for T1 ISDN Primary Rate interfaces." OBJECT dsx1TransmitClockSource SYNTAX INTEGER { loopTiming(1) } MIN-ACCESS read-only DESCRIPTION "The transmit clock is derived from received clock on ISDN Primary Rate Nicklass, Ed. Standards Track [Page 73] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 interfaces." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "Facilities Data Link usage on T1 ISDN Primary Rate interfaces. Note: Eventually, dsx1Att-54016(4) is to be used here since the line type is ESF." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION "The ability to set the channelization is not required." OBJECT dsx1LineMode MIN-ACCESS read-only DESCRIPTION "The ability to set the line mode is not required." OBJECT dsx1LineBuildOut MIN-ACCESS read-only DESCRIPTION "The ability to set the line build-out is not required." ::= { ds1Compliances 9 } ds1NMibE1PriNCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for using this MIB for ISDN Primary Rate interfaces on E1 lines." MODULE MANDATORY-GROUPS { ds1NearEndCfgGroup, ds1NearEndStatGroup } OBJECT dsx1LineType SYNTAX INTEGER { dsx1E1CRC(5) } MIN-ACCESS read-only DESCRIPTION "Line type for E1 ISDN Primary Rate interfaces." OBJECT dsx1LineCoding Nicklass, Ed. Standards Track [Page 74] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 SYNTAX INTEGER { dsx1HDB3(3) } MIN-ACCESS read-only DESCRIPTION "Type of Zero Code Suppression for E1 ISDN Primary Rate interfaces." OBJECT dsx1SignalMode SYNTAX INTEGER { messageOriented(4) } MIN-ACCESS read-only DESCRIPTION "Signaling on E1 ISDN Primary Rate interfaces is always message oriented." OBJECT dsx1TransmitClockSource SYNTAX INTEGER { loopTiming(1) } MIN-ACCESS read-only DESCRIPTION "The transmit clock is derived from received clock on ISDN Primary Rate interfaces." OBJECT dsx1Fdl MIN-ACCESS read-only DESCRIPTION "Facilities Data Link usage on E1 ISDN Primary Rate interfaces. Note: There is an 'M-Channel' in E1, using National Bit Sa4 (G704, Table 5A). It is used to implement management features between ET and NT. This is different from FDL in T1, which is used to carry control signals and performance data. In E1, control and status signals are carried using National Bits Sa5, Sa6, and A (RAI Ind.). This indicates that only the other(1) or eventually the dsx1Fdl-none(8) bits should be set in this object for E1 PRI." OBJECT dsx1Channelization MIN-ACCESS read-only DESCRIPTION Nicklass, Ed. Standards Track [Page 75] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 "The ability to set the channelization is not required." OBJECT dsx1LineMode MIN-ACCESS read-only DESCRIPTION "The ability to set the line mode is not required." OBJECT dsx1LineBuildOut MIN-ACCESS read-only DESCRIPTION "The ability to set the line build-out is not required." OBJECT dsx1LineImpedance MIN-ACCESS read-only DESCRIPTION "The ability to set line impedance is not required." ::= { ds1Compliances 10 } -- units of conformance ds1NearEndConfigGroup OBJECT-GROUP OBJECTS { dsx1LineIndex, dsx1TimeElapsed, dsx1ValidIntervals, dsx1LineType, dsx1LineCoding, dsx1SendCode, dsx1CircuitIdentifier, dsx1LoopbackConfig, dsx1LineStatus, dsx1SignalMode, dsx1TransmitClockSource, dsx1Fdl, dsx1InvalidIntervals, dsx1LineLength, dsx1LoopbackStatus, dsx1Ds1ChannelNumber, dsx1Channelization } STATUS deprecated DESCRIPTION "A collection of objects providing configuration information applicable to all DS1 interfaces." ::= { ds1Groups 1 } Nicklass, Ed. Standards Track [Page 76] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 ds1NearEndStatisticsGroup OBJECT-GROUP OBJECTS { dsx1CurrentIndex, dsx1CurrentESs, dsx1CurrentSESs, dsx1CurrentSEFSs, dsx1CurrentUASs, dsx1CurrentCSSs, dsx1CurrentPCVs, dsx1CurrentLESs, dsx1CurrentBESs, dsx1CurrentDMs, dsx1CurrentLCVs, dsx1IntervalIndex, dsx1IntervalNumber, dsx1IntervalESs, dsx1IntervalSESs, dsx1IntervalSEFSs, dsx1IntervalUASs, dsx1IntervalCSSs, dsx1IntervalPCVs, dsx1IntervalLESs, dsx1IntervalBESs, dsx1IntervalDMs, dsx1IntervalLCVs, dsx1IntervalValidData, dsx1TotalIndex, dsx1TotalESs, dsx1TotalSESs, dsx1TotalSEFSs, dsx1TotalUASs, dsx1TotalCSSs, dsx1TotalPCVs, dsx1TotalLESs, dsx1TotalBESs, dsx1TotalDMs, dsx1TotalLCVs } STATUS deprecated DESCRIPTION "A collection of objects providing statistics information applicable to all DS1 interfaces." ::= { ds1Groups 2 } ds1FarEndGroup OBJECT-GROUP OBJECTS { dsx1FarEndCurrentIndex, dsx1FarEndTimeElapsed, dsx1FarEndValidIntervals, dsx1FarEndCurrentESs, dsx1FarEndCurrentSESs, Nicklass, Ed. Standards Track [Page 77] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1FarEndCurrentSEFSs, dsx1FarEndCurrentUASs, dsx1FarEndCurrentCSSs, dsx1FarEndCurrentLESs, dsx1FarEndCurrentPCVs, dsx1FarEndCurrentBESs, dsx1FarEndCurrentDMs, dsx1FarEndInvalidIntervals, dsx1FarEndIntervalIndex, dsx1FarEndIntervalNumber, dsx1FarEndIntervalESs, dsx1FarEndIntervalSESs, dsx1FarEndIntervalSEFSs, dsx1FarEndIntervalUASs, dsx1FarEndIntervalCSSs, dsx1FarEndIntervalLESs, dsx1FarEndIntervalPCVs, dsx1FarEndIntervalBESs, dsx1FarEndIntervalDMs, dsx1FarEndIntervalValidData, dsx1FarEndTotalIndex, dsx1FarEndTotalESs, dsx1FarEndTotalSESs, dsx1FarEndTotalSEFSs, dsx1FarEndTotalUASs, dsx1FarEndTotalCSSs, dsx1FarEndTotalLESs, dsx1FarEndTotalPCVs, dsx1FarEndTotalBESs, dsx1FarEndTotalDMs } STATUS deprecated DESCRIPTION "A collection of objects providing remote configuration and statistics information." ::= { ds1Groups 3 } ds1DeprecatedGroup OBJECT-GROUP OBJECTS { dsx1IfIndex, dsx1FracIndex, dsx1FracNumber, dsx1FracIfIndex } STATUS deprecated DESCRIPTION "A collection of obsolete objects that may be implemented for backwards compatibility." ::= { ds1Groups 4 } ds1NearEndOptionalConfigGroup OBJECT-GROUP Nicklass, Ed. Standards Track [Page 78] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 OBJECTS { dsx1LineStatusLastChange, dsx1LineStatusChangeTrapEnable } STATUS current DESCRIPTION "A collection of objects that may be implemented on DS1 and DS2 interfaces." ::= { ds1Groups 5 } ds1DS2Group OBJECT-GROUP OBJECTS { dsx1LineIndex, dsx1LineType, dsx1LineCoding, dsx1SendCode, dsx1LineStatus, dsx1SignalMode, dsx1TransmitClockSource, dsx1Channelization } STATUS current DESCRIPTION "A collection of objects providing information about DS2 (6,312 kbps) and E2 (8,448 kbps) systems." ::= { ds1Groups 6 } ds1TransStatsGroup OBJECT-GROUP OBJECTS { dsx1CurrentESs, dsx1CurrentSESs, dsx1CurrentUASs, dsx1IntervalESs, dsx1IntervalSESs, dsx1IntervalUASs, dsx1TotalESs, dsx1TotalSESs, dsx1TotalUASs } STATUS current DESCRIPTION "A collection of objects that are the statistics that can be collected from a DS1 interface that is running transparent or unframed lineType. Statistics not in this list should return noSuchInstance." ::= { ds1Groups 7 } ds1NearEndOptionalTrapGroup NOTIFICATION-GROUP NOTIFICATIONS { dsx1LineStatusChange } STATUS current DESCRIPTION Nicklass, Ed. Standards Track [Page 79] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 "A collection of notifications that may be implemented on DS1 and DS2 interfaces." ::= { ds1Groups 8 } ds1ChanMappingGroup OBJECT-GROUP OBJECTS { dsx1ChanMappedIfIndex } STATUS current DESCRIPTION "A collection of objects that give a mapping of DS3 Channel (dsx1Ds1ChannelNumber) to ifIndex." ::= { ds1Groups 9 } ds1NearEndConfigurationGroup OBJECT-GROUP OBJECTS { dsx1LineIndex, dsx1TimeElapsed, dsx1ValidIntervals, dsx1LineType, dsx1LineCoding, dsx1SendCode, dsx1CircuitIdentifier, dsx1LoopbackConfig, dsx1LineStatus, dsx1SignalMode, dsx1TransmitClockSource, dsx1Fdl, dsx1InvalidIntervals, dsx1LineLength, dsx1LoopbackStatus, dsx1Ds1ChannelNumber, dsx1Channelization, dsx1LineMode, dsx1LineBuildOut } STATUS deprecated DESCRIPTION "A collection of objects providing configuration information applicable to all DS1 interfaces." ::= { ds1Groups 10 } ds1NearEndCfgGroup OBJECT-GROUP OBJECTS { dsx1LineIndex, dsx1TimeElapsed, dsx1ValidIntervals, dsx1LineType, dsx1LineCoding, dsx1SendCode, dsx1CircuitIdentifier, dsx1LoopbackConfig, dsx1LineStatus, Nicklass, Ed. Standards Track [Page 80] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1SignalMode, dsx1TransmitClockSource, dsx1Fdl, dsx1InvalidIntervals, dsx1LineLength, dsx1LoopbackStatus, dsx1Ds1ChannelNumber, dsx1Channelization, dsx1LineMode, dsx1LineBuildOut, dsx1LineImpedance } STATUS current DESCRIPTION "A collection of objects providing configuration information applicable to all DS1 interfaces." ::= { ds1Groups 11 } ds1NearEndStatGroup OBJECT-GROUP OBJECTS { dsx1CurrentIndex, dsx1CurrentESs, dsx1CurrentSESs, dsx1CurrentSEFSs, dsx1CurrentUASs, dsx1CurrentCSSs, dsx1CurrentPCVs, dsx1CurrentLESs, dsx1CurrentBESs, dsx1CurrentLCVs, dsx1IntervalIndex, dsx1IntervalNumber, dsx1IntervalESs, dsx1IntervalSESs, dsx1IntervalSEFSs, dsx1IntervalUASs, dsx1IntervalCSSs, dsx1IntervalPCVs, dsx1IntervalLESs, dsx1IntervalBESs, dsx1IntervalLCVs, dsx1IntervalValidData, dsx1TotalIndex, dsx1TotalESs, dsx1TotalSESs, dsx1TotalSEFSs, dsx1TotalUASs, dsx1TotalCSSs, dsx1TotalPCVs, dsx1TotalLESs, Nicklass, Ed. Standards Track [Page 81] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 dsx1TotalBESs, dsx1TotalLCVs } STATUS current DESCRIPTION "A collection of objects providing statistics information applicable to all DS1 interfaces." ::= { ds1Groups 12 } ds1FarEndNGroup OBJECT-GROUP OBJECTS { dsx1FarEndCurrentIndex, dsx1FarEndTimeElapsed, dsx1FarEndValidIntervals, dsx1FarEndCurrentESs, dsx1FarEndCurrentSESs, dsx1FarEndCurrentSEFSs, dsx1FarEndCurrentUASs, dsx1FarEndCurrentCSSs, dsx1FarEndCurrentLESs, dsx1FarEndCurrentPCVs, dsx1FarEndCurrentBESs, dsx1FarEndInvalidIntervals, dsx1FarEndIntervalIndex, dsx1FarEndIntervalNumber, dsx1FarEndIntervalESs, dsx1FarEndIntervalSESs, dsx1FarEndIntervalSEFSs, dsx1FarEndIntervalUASs, dsx1FarEndIntervalCSSs, dsx1FarEndIntervalLESs, dsx1FarEndIntervalPCVs, dsx1FarEndIntervalBESs, dsx1FarEndIntervalValidData, dsx1FarEndTotalIndex, dsx1FarEndTotalESs, dsx1FarEndTotalSESs, dsx1FarEndTotalSEFSs, dsx1FarEndTotalUASs, dsx1FarEndTotalCSSs, dsx1FarEndTotalLESs, dsx1FarEndTotalPCVs, dsx1FarEndTotalBESs} STATUS current DESCRIPTION "A collection of objects providing remote configuration and statistics information." ::= { ds1Groups 13 } END Nicklass, Ed. Standards Track [Page 82] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The specific objects and their sensitivities/vulnerabilities are as follows. Setting the following objects to incorrect values may result in traffic interruptions: dsx1LineType dsx1LineCoding dsx1SendCode dsx1LoopbackConfig dsx1SignalMode dsx1TransmitClockSource dsx1Fdl dsx1LineLength dsx1Channelization dsx1LineMode dsx1LineBuildOut dsx1LineImpedance In the case of dsx1LineType, for example, both ends of a DS1/E1 must have the same value in order for traffic to flow. In the case of dsx1SendCode and dsx1LoopbackConfig, for another example, traffic may stop transmitting when particular loopbacks are applied. Setting the following object to an incorrect value will not harm the traffic, but it may cause a circuit to be misidentified and thereby create difficulties for service personnel when attempting to troubleshoot a problem: dsx1CircuitIdentifier Setting the following object can cause an increase in the number of traps received by the network management station: dsx1LineStatusChangeTrapEnable The readable objects in this MIB module (i.e., the objects with a MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide extensive information about the performance of interfaces in DS1/J1/E1/DS2/E2 equipment or networks and can reveal some aspects of their Nicklass, Ed. Standards Track [Page 83] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 configuration. In such environments, it is important to control even GET and NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. Acknowledgments This document was produced by the AToM MIB Working Group. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Nicklass, Ed. Standards Track [Page 84] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 [AT&T-TR-54016] AT&T Technical Reference, Requirements for Interfacing Digital Terminal Equipment to Services Employing the Extended Superframe Format, Publication 54016, May 1988. [ANSI-T1.403] American National Standard for Telecommunications -- Carrier-to-Customer Installation - DS1 Metallic Interface, T1.403, February 1989. [CCITT-G.703] ITU-T G.703, Physical/Electrical Characteristics of Hierarchical Digital Interfaces, November 2001. [ITU-T-G.704] ITU-T G.704: Synchronous frame structures used at 1544, 6312, 2048, 8488 and 44 736 kbit/s Hierarchical Levels, October 1998. [ANSI-T1.231] American National Standard for Telecommunications -- Digital Hierarchy DS1-- Layer 1 In-Service Digital Transmission Performance Monitoring, T1.231.02, October 2003. [ITU-T-O.162] ITU-T O.162, Equipment To Perform In Service Monitoring On 2048 kbit/s Signals, October 1992. [CCITT-G.821] ITU-T G.821, Error Performance Of An International Digital Connection Forming Part Of An Integrated Services Digital Network, December 2002. [AT&T-TR-62411] AT&T Technical Reference, Technical Reference 62411, ACCUNET T1.5 Service Description And Interface Specification, December 1990. [CCITT-G.706] ITU-T G.706, Frame Alignment and Cyclic Redundancy Check (CRC) Procedures Relating to Basic Frame Structures Defined in Recommendation G.704, April 1991. [CCITT-G.732] ITU-T G.732, Characteristics Of Primary PCM Multiplex Equipment Operating at 2048 kbit/s, November 1988. [ITU-T-G.775] ITU-T G.775: Loss of signal (LOS) and alarm indication signal (AIS) defect detection and clearance criteria, October 1998. [ITU-T-G.826] ITU-T G.826: Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate, December 2002. Nicklass, Ed. Standards Track [Page 85] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 [ANSI-T1.107] American National Standard for Telecommunications -- Digital Hierarchy - Format Specifications, T1.107, January 2002. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [ITU-T-M.1400] ITU-T M.1400: Designation For Interconnections Among Network Operators, October 2001. [JT-G704] JT-G.704: Synchronous frame structures used at Primary and Secondary Hierarchical Levels, 2002. [JT-G706] JT-G.706: Frame Alignment and Cyclic Redundancy Check (CRC) Procedures. [JT-I431] JT-I.431: ISDN Primary Rate User-Network Interface,Layer 1 Specifications, 2002. 7.2. Informative References [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [RFC3895] Nicklass, O., "Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types", RFC 3895, September 2004. [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999. [RFC1406] Baker, F. and J. Watt, "Definitions of Managed Objects for the DS1 and E1 Interface Types", RFC 1406, January 1993. [AT&T-UM-305] AT&T Information Systems, AT&T ESF DS1 Channel Service Unit User's Manual, 999-100-305, February 1988. [RFC3896] Nicklass, O., "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 3896, September 2004. Nicklass, Ed. Standards Track [Page 86] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 [RFC3592] Tesink, K., "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", RFC 3592, September 2003. [RFC2494] Fowler, D., "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type", RFC 2494, January 1999. [ANSI-T1.102] American National Standard for Telecommunications -- Digital Hierarchy - Electrical Interfaces, T1.102, December 1993. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Nicklass, Ed. Standards Track [Page 87] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Appendix A - Use of dsx1IfIndex and dsx1LineIndex This appendix exists to document the previous use of dsx1IfIndex and dsx1LineIndex and to clarify the relationship of dsx1LineIndex as defined in RFC 1406 with the dsx1LineIndex as defined in this document. The following shows the old and new definitions and the relationship: [New Definition]: "This object should be made equal to ifIndex. The next paragraph describes its previous usage. Making the object equal to ifIndex allows proper use of ifStackTable and ds0/ds0bundle mibs. [Old Definition]: "This object is the identifier of a DS1 Interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS1 interface, it should have the same value as ifIndex. Otherwise, number the dsx1LineIndices with an unique identifier following the rules of choosing a number that is greater than ifNumber and numbering the inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g., network side) with odd numbers." When the "Old Definition" was created, it was described this way to allow a manager to treat the value as if it were an ifIndex; i.e., the value would be either: 1) an ifIndex value or 2) a value that was guaranteed to be different from all valid ifIndex values. The new definition is a subset of that definition; i.e., the value is always an ifIndex value. The following is Section 3.1 from RFC 1406: Different physical configurations for the support of SNMP with DS1 equipment exist. To accommodate these scenarios, two different indices for DS1 interfaces are introduced in this MIB. These indices are dsx1IfIndex and dsx1LineIndex. External interface scenario: the SNMP Agent represents all managed DS1 lines as external interfaces (for example, an Agent residing on the device supporting DS1 interfaces directly): For this scenario, all interfaces are assigned an integer value equal to ifIndex, and the following applies: ifIndex=dsx1IfIndex=dsx1LineIndex for all interfaces. Nicklass, Ed. Standards Track [Page 88] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 The dsx1IfIndex column of the DS1 Configuration table relates each DS1 interface to its corresponding interface (ifIndex) in the Internet-standard MIB (MIB-II STD 17, RFC 1213) [RFC1213]. External & Internal interface scenario: the SNMP Agents resides on a host external from the device supporting DS1 interfaces (e.g., a router). The Agent represents both the host and the DS1 device. The index dsx1LineIndex is used to not only represent the DS1 interfaces external from the host/DS1-device combination, but also the DS1 interfaces connecting the host and the DS1 device. The index dsx1IfIndex is always equal to ifIndex. Example: A shelf full of CSUs connected to a router. An SNMP Agent residing on the router proxies for itself and the CSU. The router has also an Ethernet interface: +-----+ | | | | | | +---------------------+ |E | | 1.544 MBPS | Line#A | DS1 Link |t | R |---------------+ - - - - - - - - - +------> |h | | | | |e | O | 1.544 MBPS | Line#B | DS1 Link |r | |---------------+ - - - - - - - - - - +------> |n | U | | CSU Shelf | |e | | 1.544 MBPS | Line#C | DS1 Link |t | T |---------------+ - - - -- -- - - - - +------> | | | | | |-----| E | 1.544 MBPS | Line#D | DS1 Link | | |---------------+ - - - - -- - - - - +------> | | R | |_____________________| | | | | +-----+ The assignment of the index values could for example be: ifIndex (= dsx1IfIndex) dsx1LineIndex 1 NA NA (Ethernet) 2 Line#A Router Side 6 2 Line#A Network Side 7 3 Line#B Router Side 8 3 Line#B Network Side 9 4 Line#C Router Side 10 4 Line#C Network Side 11 5 Line#D Router Side 12 5 Line#D Network Side 13 Nicklass, Ed. Standards Track [Page 89] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 For this example, ifNumber is equal to 5. Note the following description of dsx1LineIndex: the dsx1LineIndex identifies a DS1 Interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS1 interface, it should have the same value as ifIndex. Otherwise, number the dsx1LineIndices with an unique identifier following the rules of choosing a number greater than ifNumber and numbering inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g., network side) with odd numbers. If the CSU shelf is managed by itself by a local SNMP Agent, the situation would be: ifIndex (= dsx1IfIndex) dsx1LineIndex 1 Line#A Network Side 1 2 Line#A RouterSide 2 3 Line#B Network Side 3 4 Line#B RouterSide 4 5 Line#C Network Side 5 6 Line#C Router Side 6 7 Line#D Network Side 7 8 Line#D Router Side 8 Appendix B - The Delay Approach to Unavailable Seconds This procedure is illustrated below for a DS1 ESF interface. Similar rules would apply for other DS1, DS2, and E1 interface variants. The procedure guarantees that the statistical counters are correctly updated at all times, although they lag real time by 10 seconds. At the end of each 15-minute interval, the current interval counts are transferred to the most recent interval entry and each interval is shifted up by one position, with the oldest being discarded if necessary in order to make room. The current interval counts then start over from zero. Note, however, that the signal state calculation does not start afresh at each interval boundary; rather, signal state information is retained across interval boundaries. Nicklass, Ed. Standards Track [Page 90] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 +---------------------------------------------------------------------+ | READ COUNTERS & STATUS INFO FROM HARDWARE | | | | BPV EXZ LOS FE CRC CS AIS SEF OOF LOF RAI G1-G6 SE FE LV SL | +---------------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V V V V V V +---------------------------------------------------------------------+ | ACCUM ONE-SEC STATS, CHK ERR THRESHOLDS, & UPDT SIGNAL STATE | | | | |<---------- NEAR END ----------->| |<-------- FAR END ------>| | | | | LCV LES PCV ES CSS BES SES SEFS A/U PCV ES CSS BES SES SEFS A/U | +---------------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V | V V V V V V | +------------------------------+ | +----------------------+ | | ONE-SEC DELAY | | | ONE-SEC DELAY | | | (1 OF 10) | | | (1 OF 10) | | +------------------------------+ | +----------------------+ | | | | | | | | | | | | | | | | | / / / / / / / / / / / / / / / / | | | | | | | | | | | | | | | | V V V V V V V V | V V V V V V | +------------------------------+ | +----------------------+ | | ONE-SEC DELAY | | | ONE-SEC DELAY | | | (10 OF 10) | | | (10 OF 10) | | +------------------------------+ | +----------------------+ | | | | | | | | | | | | | | | | | V V V V V V V V V V V V V V V V +---------------------------------------------------------------------+ | UPDATE STATISTICS COUNTERS | | | |<-------------- NEAR END ----------->| |<--------- FAR END --------->| | | |LCV LES PCV ES CSS BES SES SEFS UAS DM PCV ES CSS BES SES SEFS UAS DM| +---------------------------------------------------------------------+ Note that if such a procedure is adopted, there is no current interval data for the first 10 seconds after a system comes up. noSuchInstance must be returned if a management station attempts to access the current interval counters during this time. It is an implementation-specific matter whether an agent assumes that the initial state of the interface is available or unavailable. Nicklass, Ed. Standards Track [Page 91] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Appendix C - Changes from Pervious Versions C.1. Changes from RFC 3895 The changes from RFC 3895 [RFC3895] are the following: (1) Values were added to dsx1LineType to support J1 types. (2) The object dsx1LineImpedance was added. (3) All DM-related objects were deprecated following their removal from ITU performance standards. (4) Relevant text and reference section were updated. (5) Changes in Compliance Statements to include new values. C.2. Changes from RFC 2495 The changes from RFC 2495 [RFC2495] are the following: (1) The dsx1FracIfIndex SYNTAX matches the description range. (2) A value was added to dsx1TransmitClockSource. (3) Values were added to dsx1LineType. (4) Two objects were added, dsx1LineMode and dsx1LineBuildOut, to better express transceiver mode and LineBuildOut for T1. (5) Reference was added to Circuit Identifier object. (6) Align the DESCRIPTION clauses of few statistic objects with the near-end definition, with the far-end definition, and with [RFC3593]. (7) Changes in Compliance Statements to include new objects. (8) A typographical error in dsx2E2 was fixed; new name is dsx1E2. C.3. Changes from RFC 1406 The changes from RFC 1406 [RFC1406] are the following: (1) The Fractional table has been deprecated. (2) This document uses SMIv2. (3) Usage is given for ifTable and ifXTable. (4) Example usage of ifStackTable is included. (5) dsx1IfIndex has been deprecated. (6) Support for DS2 and E2 has been added. (7) Additional lineTypes for DS2, E2, and unframed E1 were added. (8) The definition of valid intervals has been clarified for the case where the agent proxied for other devices. In particular, the treatment of missing intervals has been clarified. (9) An inward loopback has been added. (10) Additional lineStatus bits have been added for Near End in Unavailable Signal State, Carrier Equipment Out of Service, DS2 Payload AIS, and DS2 Performance Threshold. Nicklass, Ed. Standards Track [Page 92] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 (11) A read-write line Length object has been added. (12) Signal mode of other has been added. (13) Added a lineStatus last change, trap and enabler. (14) The e1(19) ifType has been obsoleted, so this MIB does not list it as a supported ifType. (15) Textual Conventions for statistics objects have been used. (16) A new object, dsx1LoopbackStatus, has been introduced to reflect the loopbacks established on a DS1 interface and the source to the requests. dsx1LoopbackConfig continues to be the desired loopback state while dsx1LoopbackStatus reflects the actual state. (17) A dual loopback has been added to allow the setting of an inward loopback and a line loopback at the same time. (18) An object indicating which channel to use within a parent object (i.e., DS3) has been added. (19) An object has been added to indicate whether or not this DS1/E1 is channelized. (20) Line coding type of B6ZS has been added for DS2. C.4. Companion Documents This document is a companion to the documents that define managed objects for the DS0 [RFC2494], DS3/E3 [RFC3896], and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) [RFC3592] Interface Types. Author's Address Orly Nicklass, Editor RAD Data Communications, Ltd. Ziv Tower, 24 Roul Walenberg Tel Aviv, Israel, 69719 Phone: 9723-765-9969 EMail: orly_n@rad.com Nicklass, Ed. Standards Track [Page 93] RFC 4805 DS1/J1/E1/DS2/E2 MIB March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nicklass, Ed. Standards Track [Page 94] snmp-mibs-downloader-1.1/mibrfcs/rfc4807.txt0000644000000000000000000041305311402176072015573 0ustar Network Working Group M. Baer Request for Comments: 4807 Sparta, Inc. Category: Standards Track R. Charlet Self W. Hardaker Sparta, Inc. R. Story Revelstone Software C. Wang ARO March 2007 IPsec Security Policy Database Configuration MIB 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. Baer, et al. Standards Track [Page 1] RFC 4807 IPsec SPD configuration MIB March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Internet-Standard Management Framework . . . . . . . . . . 3 4. Relationship to the DMTF Policy Model . . . . . . . . . . . . 3 5. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 4 5.1. Usage Tutorial . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Notational Conventions . . . . . . . . . . . . . . . . 6 5.1.2. Implementing an Example SPD Policy . . . . . . . . . . 7 6. MIB Definition . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 65 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 65 7.2. Protecting against Unauthenticated Access . . . . . . . . 66 7.3. Protecting against Involuntary Disclosure . . . . . . . . 66 7.4. Bootstrapping Your Configuration . . . . . . . . . . . . . 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 69 Baer, et al. Standards Track [Page 2] RFC 4807 IPsec SPD configuration MIB March 2007 1. Introduction This document defines a MIB module for configuration of an IPsec security policy database (SPD). The IPsec model this MIB is designed to configure is based on the "IPsec Configuration Policy Model" (IPCP) [RFC3585]. The IPCP's IPsec model is, in turn, derived from the Distributed Management Task Force's (DMTF) IPsec model (see below) and from the IPsec model specified in RFC 2401 [RFC2401]. Note: RFC 2401 has been updated by RFC 4301 [RFC4301], but this implementation is based on RFC 2401. The policy-based packet filtering and the corresponding execution of actions configured by this MIB is of a more general nature than for IPsec configuration only, such as for configuration of a firewall. It is possible to extend this MIB module and add other packet-transforming actions that are performed conditionally on an interface's network traffic. The IPsec- and IKE-specific actions are as documented in [IPsec-ACTION] and [IKE-ACTION], respectively, and are not documented in this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410] Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Relationship to the DMTF Policy Model The Distributed Management Task Force (DMTF) has created an object oriented model of IPsec policy information known as the IPsec Policy Model White Paper [IPPMWP]. The "IPsec Configuration Policy Model" (IPCP) [RFC3585] is based, in large part, on the DMTF's IPsec policy model and on RFC 2401 [RFC2401]. The IPCP document describes a model Baer, et al. Standards Track [Page 3] RFC 4807 IPsec SPD configuration MIB March 2007 for configuring IPsec. This MIB module is a task-specific derivation (i.e., an SMIv2 instantiation) of the IPCP's IPsec configuration model for use with Simple Network Management Protocol version 3 (SNMPv3). The high-level areas where this MIB module diverges from the IPCP model are: o Policies, Groups, Conditions, and some levels of Actions are generically named. In other words, IPsec-specific prefixes like "SA" (Security Association), or "IPsec", are not used. This naming convention is used because packet classification and the matching of conditions to actions is more general than IPsec. The tables in this document can possibly be reused by other packet- transforming actions, which need to conditionally act on packets matching filters. o Filters are implemented in a more generic and scalable manner, rather than enforcing the condition/filtering pairing of the IPCP and its restrictions upon the user. This MIB module offers a compound filter object providing greater flexibility for complex filters than the IPCP. 5. MIB Module Overview The MIB module is modularized into several different parts: rules, filters, and actions. The rules section associates endpoints and groups of rules, and consists of the spdEndpointToGroupTable, spdGroupContentsTable, and the spdRuleDefinitionTable. Each row of the spdRuleDefinitionTable connects a filter to an action. It should also be noted that by referencing the spdCompoundFilterTable, the spdRuleDefinitionTable's filter column can indicate a set of filters to be processed. Likewise, by referencing the spdCompoundActionTable, the spdRuleDefinitionTable's action column can indicate multiple actions to be executed. This MIB is structured to allow for reuse through the future creation of extension tables that provide additional filters and/or actions. In fact, the companion documents to this one ([IPsec-ACTION] and [IKE-ACTION]) do just that and define IPsec- and IKE-specific actions to be used within this SPD configuration MIB. Note: it is expected that, in order to function properly, extension action MIBs may impose additional limitations on the objects in this MIB and how they can be used with the extended actions. An extension action may only support a subset of the configuration options available in this MIB. Baer, et al. Standards Track [Page 4] RFC 4807 IPsec SPD configuration MIB March 2007 The filter section of the MIB module is composed of the different types of filters in the Policy Model. It is made up of the spdTrueFilter, spdCompoundFilterTable, spdSubfiltersTable spdIpHeaderFilterTable, spdIpOffsetFilterTable, spdTimeFilterTable, spdIpsoHeaderFilterTable. The action section of this MIB module contains only the simple static actions required for the firewall processing that an IPsec SPD implementation requires (e.g., accept, drop, log, etc.). The companion documents of this document define the complex actions necessary for IPsec and IKE negotiations. As may have been noticed above, the MIB uses recursion in a similar manner in several different places. In particular, the spdGroupContentsTable, the spdCompoundFilterTable / spdSubfiltersTable combination, and the spdCompoundActionTable / spdSubactionsTable combination can reference themselves. In the case of the spdGroupContentsTable, a row can indicate a rule (i.e., a row in the spdRuleDefinitionTable) or a group (i.e., another set of one or more rows in the spdGroupContentsTable). This way, a group can contain a set of rules and sub-groups. Sub-groups are just other groups defined in the spdGroupContentsTable. There is no inherent MIB limit to the depth of nesting of groups. The spdCompoundFilterTable / spdSubfiltersTable combination and spdCompoundActionTable / spdSubactionsTable combination are designed almost identically, with one being for filters and the other for actions, respectively. The following descriptions for the compound filter tables can be directly applied to the compound action tables. The combination of the tables spdCompoundFilterTable and spdSubfiltersTable allow a user to create a set of filters that can be referenced from any table as a single filter. A row in the spdCompoundFilterTable has the basic configuration information for the compound filter. The index of spdCompoundFilterTable, spdCompFiltname, is also used as a partial index to reference a set of ordered rows in the spdSubfiltersTable. Each row in spdSubfiltersTable points to a row in another filter table. In this way, the set of rows in spdSubFiltersTable with a matching spdCompFiltName, together with the row in spdCompoundFilterTable indexed by spdCompFiltName, create a compound filter. Note that it is possible for a row in the spdSubfiltersTable to point to a row in the spdCompoundFilterTable. This recursion allows the creation of a filter set that includes other filter sets within it. There is no inherent MIB limit to the nesting of compound filters within compound filters. Baer, et al. Standards Track [Page 5] RFC 4807 IPsec SPD configuration MIB March 2007 5.1. Usage Tutorial In order to use the tables contained in this document, a general understanding of firewall processing is helpful. The processing of the security policy database (SPD) involves applying a set of SPD rules to an interface on a device. The given set of rules to apply to any given interface is defined within the spdEndpointToGroupTable table. This table maps a given interface to a group of rules. In this table, the interface itself is specified using its assigned address. There is also one group of rules per direction (ingress and egress). 5.1.1. Notational Conventions Notes about the following example operations: 1. All the example operations in the following section make use of default values for all columns not listed. The operations and column values given in the examples are the minimal SNMP Varbinds that must be sent to create a row. 2. The example operations are formatted such that a row (i.e., the table's Entry object) is operated on by using the indexes to that row and the column values for that row. 3. Below is a generic example of the notation used in the following section's examples of this MIB's usage. This example indicates that the MIB row to be set is the row with the index values of value1 for index1, and value2 for index2. Within this row, column1 is set to column_value1, and column2 is set to column_value2.: rowEntry(index1 = value1, index2 = value2) = (column1 = column_value1, column2 = column_value2) 4. The below is a specific example of the notation used in the following section's examples of this MIB's usage. This example represents the status column of a row in the IP- MIB::ipAddressTable table being set to deprecated. The index values for this row are IPv4 and 192.0.2.1. The example notation would look like the following: ipAddressEntry(ipAddressAddrType = 1, -- ipv4 ipAddressAddr = 0xC0000201 ) -- 192.0.2.1 = (ipAddressStatus = 2) -- deprecated Baer, et al. Standards Track [Page 6] RFC 4807 IPsec SPD configuration MIB March 2007 5.1.2. Implementing an Example SPD Policy As an example, let us define the following administrative policy: On the network interface with IP address 192.0.2.1, all traffic from host 192.0.2.6 will be dropped and all other traffic will be accepted. This policy is enforced by setting the values in the MIB to do the following: o create a filter for 192.0.2.6 o create a rule that connects the 192.0.2.6 filter to a packet drop action o create a rule that always accepts packets o group these rules together in the proper order so that the 192.0.2.6 drop rule is checked first. o connect this group of rules to the 192.0.2.1 interface The first step to do this is creating the filter for the IPv4 address 192.0.2.6: SpdIpHeaderFilterEntry(spdIpHeadFiltName = "192.0.2.6") = (spdIpHeadFiltType = 0x80, -- sourceAddress spdIpHeadFiltIPVersion = 1, -- IPv4 spdIpHeadFiltSrcAddressBegin = 0xC0000206, -- 192.0.2.6 spdIpHeadFiltSrcAddressEnd = 0xC0000206, -- 192.0.2.6 spdIpHeadFiltRowStatus = 4) -- createAndGo Next, a rule is created to connect the above "192.0.2.6" filter to an action to "drop" the packet, as follows: spdRuleDefinitionEntry(spdRuleDefName = "drop from 192.0.2.6") = (spdRuleDefFilter = spdIpHeadFiltType.9.49.57.50.46.48.46.50.46.54, spdRuleDefAction = spdDropAction.0, spdRuleDefRowStatus = 4) -- createAndGo Next, a rule is created that accepts all packets: spdRuleDefinitionEntry(spdRuleDefName = "accept all") = (spdRuleDefFilter = spdTrueFilter.0, spdRuleDefAction = spdAcceptAction.0, spdRuleDefRowStatus = 4) -- createAndGo Baer, et al. Standards Track [Page 7] RFC 4807 IPsec SPD configuration MIB March 2007 Next, these two rules are grouped together. Rule groups attached to an interface are processed one row at a time. The rows are processed from lowest to highest spdGroupContPriority value. Because the row that references the "accept all" rule should be processed last, it is given the higher spdGroupContPriority value. SpdGroupContentsEntry(spdGroupContName = "ingress", spdGroupContPriority = 65535) = (spdGroupContComponentName = "accept all", spdGroupContRowStatus = 4) -- createAndGo SpdGroupContentsEntry(spdGroupContName = "ingress", spdGroupContPriority = 1000) = (spdGroupContComponentName = "drop from 192.0.2.6", spdGroupContRowStatus = 4) -- createAndGo Finally, this group of rules is connected to the 192.0.2.1 interface as follows: SpdEndpointToGroupEntry(spdEndGroupDirection = 1, -- ingress spdEndGroupIdentType = 4, -- IPv4 spdEndGroupAddress = 0xC0000001) = (spdEndGroupName = "ingress", spdEndGroupRowStatus = 4) -- createAndGo This completes the necessary steps to implement the policy. Once all of these rules have been applied, the policy should take effect. 6. MIB Definition The following MIB Module imports from: [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3289], [RFC3411], and [RFC4001]. It also uses definitions from [RFC1108], [RFC3060], and [RFC3629]. IPSEC-SPD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, RowStatus, TruthValue, TimeStamp, StorageType, VariablePointer FROM SNMPv2-TC -- [RFC2579] Baer, et al. Standards Track [Page 8] RFC 4807 IPsec SPD configuration MIB March 2007 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndex FROM IF-MIB -- [RFC2863] diffServMIBMultiFieldClfrGroup, IfDirection, diffServMultiFieldClfrNextFree FROM DIFFSERV-MIB -- [RFC3289] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] ; -- -- module identity -- spdMIB MODULE-IDENTITY LAST-UPDATED "200702070000Z" -- 7 February 2007 ORGANIZATION "IETF IP Security Policy Working Group" CONTACT-INFO "Michael Baer P.O. Box 72682 Davis, CA 95617 Phone: +1 530 902 3131 Email: baerm@tislabs.com Ricky Charlet Email: rcharlet@alumni.calpoly.edu Wes Hardaker Sparta, Inc. P.O. Box 382 Davis, CA 95617 Phone: +1 530 792 1913 Email: hardaker@tislabs.com Robert Story Revelstone Software PO Box 1812 Baer, et al. Standards Track [Page 9] RFC 4807 IPsec SPD configuration MIB March 2007 Tucker, GA 30085 Phone: +1 770 617 3722 Email: rstory@ipsp.revelstone.com Cliff Wang ARO 4300 S. Miami Blvd. Durham, NC 27703 E-Mail: cliffwangmail@yahoo.com" DESCRIPTION "This MIB module defines configuration objects for managing IPsec Security Policies. In general, this MIB can be implemented anywhere IPsec security services exist (e.g., bump-in-the-wire, host, gateway, firewall, router, etc.). Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4807; see the RFC itself for full legal notices." -- Revision History REVISION "200702070000Z" -- 7 February 2007 DESCRIPTION "Initial version, published as RFC 4807." ::= { mib-2 153 } -- -- groups of related objects -- spdConfigObjects OBJECT IDENTIFIER ::= { spdMIB 1 } spdNotificationObjects OBJECT IDENTIFIER ::= { spdMIB 2 } spdConformanceObjects OBJECT IDENTIFIER ::= { spdMIB 3 } spdActions OBJECT IDENTIFIER ::= { spdMIB 4 } -- -- Textual Conventions -- SpdBooleanOperator ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The SpdBooleanOperator operator is used to specify whether sub-components in a decision-making process are Baer, et al. Standards Track [Page 10] RFC 4807 IPsec SPD configuration MIB March 2007 ANDed or ORed together to decide if the resulting expression is true or false." SYNTAX INTEGER { or(1), and(2) } SpdAdminStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The SpdAdminStatus is used to specify the administrative status of an object. Objects that are disabled MUST NOT be used by the packet processing engine." SYNTAX INTEGER { enabled(1), disabled(2) } SpdIPPacketLogging ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "SpdIPPacketLogging specifies whether an audit message SHOULD be logged if a packet is passed through a Security Association (SA) and if some of that packet is included in the log event. A value of '-1' indicates no logging. A value of '0' or greater indicates that logging SHOULD be done and indicates the number of bytes starting at the beginning of the packet to place in the log. Values greater than the size of the packet being processed indicate that the entire packet SHOULD be sent. Examples: '-1' no logging '0' log but do not include any of the packet in the log '20' log and include the first 20 bytes of the packet in the log." SYNTAX Integer32 (-1..65535) SpdTimePeriod ::= TEXTUAL-CONVENTION DISPLAY-HINT "31t" STATUS current DESCRIPTION "This property identifies an overall range of calendar dates and time. In a boolean context, a value within this time range, inclusive, is considered true. This information is encoded as an octet string using the UTF-8 transformation format described in STD 63, RFC 3629. It uses the format suggested in RFC 3060. An octet string Baer, et al. Standards Track [Page 11] RFC 4807 IPsec SPD configuration MIB March 2007 represents a start date and time and an end date and time. For example: yyyymmddThhmmss/yyyymmddThhmmss Where: yyyy = year mm = month dd = day hh = hour mm = minute ss = second The first 'yyyymmddThhmmss' sub-string indicates the start date and time. The second 'yyyymmddThhmmss' sub-string indicates the end date and time. The character 'T' within these sub-strings indicates the beginning of the time portion of each sub-string. The solidus character '/' separates the start from the end date and time. The end date and time MUST be subsequent to the start date and time. There are also two allowed substitutes for a 'yyyymmddThhmmss' sub-string: one for the start date and time, and one for the end date and time. If the start date and time are replaced with the string 'THISANDPRIOR', this sub-string would indicate the current date and time and the previous dates and time. If the end date and time are replaced with the string 'THISANDFUTURE', this sub-string would indicate the current date and time and the subsequent dates and time. Any of the following SHOULD be considered a 'wrongValue' error: - Setting a value with the end date and time earlier than or equal to the start date and time. - Setting the start date and time to 'THISANDFUTURE'. - Setting the end date and time to 'THISANDPRIOR'." REFERENCE "RFC 3060, 3269" SYNTAX OCTET STRING (SIZE (0..31)) -- -- Policy group definitions -- spdLocalConfigObjects OBJECT IDENTIFIER ::= { spdConfigObjects 1 } spdIngressPolicyGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-write STATUS current Baer, et al. Standards Track [Page 12] RFC 4807 IPsec SPD configuration MIB March 2007 DESCRIPTION "This object indicates the global system policy group that is to be applied on ingress packets (i.e., arriving at an interface from a network) when a given endpoint does not contain a policy definition in the spdEndpointToGroupTable. Its value can be used as an index into the spdGroupContentsTable to retrieve a list of policies. A zero length string indicates that no system-wide policy exists and the default policy of 'drop' SHOULD be executed for ingress packets until one is imposed by either this object or by the endpoint processing a given packet. This object MUST be persistent" DEFVAL { "" } ::= { spdLocalConfigObjects 1 } spdEgressPolicyGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the policy group containing the global system policy that is to be applied on egress packets (i.e., packets leaving an interface and entering a network) when a given endpoint does not contain a policy definition in the spdEndpointToGroupTable. Its value can be used as an index into the spdGroupContentsTable to retrieve a list of policies. A zero length string indicates that no system-wide policy exists and the default policy of 'drop' SHOULD be executed for egress packets until one is imposed by either this object or by the endpoint processing a given packet. This object MUST be persistent" DEFVAL { "" } ::= { spdLocalConfigObjects 2 } spdEndpointToGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdEndpointToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maps policies (groupings) onto an endpoint (interface). A policy group assigned to an endpoint is then used to control access to the network traffic passing through that endpoint. Baer, et al. Standards Track [Page 13] RFC 4807 IPsec SPD configuration MIB March 2007 If an endpoint has been configured with a policy group and no rule within that policy group matches that packet, the default action in this case SHALL be to drop the packet. If no policy group has been assigned to an endpoint, then the policy group specified by spdIngressPolicyGroupName MUST be used on traffic inbound from the network through that endpoint, and the policy group specified by spdEgressPolicyGroupName MUST be used for traffic outbound to the network through that endpoint." ::= { spdConfigObjects 2 } spdEndpointToGroupEntry OBJECT-TYPE SYNTAX SpdEndpointToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A mapping assigning a policy group to an endpoint." INDEX { spdEndGroupDirection, spdEndGroupInterface } ::= { spdEndpointToGroupTable 1 } SpdEndpointToGroupEntry ::= SEQUENCE { spdEndGroupDirection IfDirection, spdEndGroupInterface InterfaceIndex, spdEndGroupName SnmpAdminString, spdEndGroupLastChanged TimeStamp, spdEndGroupStorageType StorageType, spdEndGroupRowStatus RowStatus } spdEndGroupDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object indicates which direction of packets crossing the interface are associated with which spdEndGroupName object. Ingress packets, or packets into the device match when this value is inbound(1). Egress packets or packets out of the device match when this value is outbound(2)." ::= { spdEndpointToGroupEntry 1 } spdEndGroupInterface OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION Baer, et al. Standards Track [Page 14] RFC 4807 IPsec SPD configuration MIB March 2007 "This value matches the IF-MIB's ifTable's ifIndex column and indicates the interface associated with a given endpoint. This object can be used to uniquely identify an endpoint that a set of policy groups are applied to." ::= { spdEndpointToGroupEntry 2 } spdEndGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The policy group name to apply at this endpoint. The value of the spdEndGroupName object is then used as an index into the spdGroupContentsTable to come up with a list of rules that MUST be applied at this endpoint." ::= { spdEndpointToGroupEntry 3 } spdEndGroupLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdEndpointToGroupEntry 4 } spdEndGroupStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdEndpointToGroupEntry 5 } spdEndGroupRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Baer, et al. Standards Track [Page 15] RFC 4807 IPsec SPD configuration MIB March 2007 STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. This object is considered 'notReady' and MUST NOT be set to active until one or more active rows exist within the spdGroupContentsTable for the group referenced by the spdEndGroupName object." ::= { spdEndpointToGroupEntry 6 } -- -- policy group definition table -- spdGroupContentsTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdGroupContentsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of rules and/or subgroups contained within a given policy group. For a given value of spdGroupContName, the set of rows sharing that value forms a 'group'. The rows in a group MUST be processed according to the value of the spdGroupContPriority object in each row. The processing MUST be executed starting with the lowest value of spdGroupContPriority and in ascending order thereafter. If an action is executed as the result of the processing of a row in a group, the processing of further rows in that group MUST stop. Iterating to the next policy group row by finding the next largest spdGroupContPriority object SHALL only be done if no actions were run while processing the current row for a given packet." ::= { spdConfigObjects 3 } spdGroupContentsEntry OBJECT-TYPE SYNTAX SpdGroupContentsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a given sub-component within a policy group. A sub-component is either a rule or another group as indicated by spdGroupContComponentType and referenced by spdGroupContComponentName." Baer, et al. Standards Track [Page 16] RFC 4807 IPsec SPD configuration MIB March 2007 INDEX { spdGroupContName, spdGroupContPriority } ::= { spdGroupContentsTable 1 } SpdGroupContentsEntry ::= SEQUENCE { spdGroupContName SnmpAdminString, spdGroupContPriority Integer32, spdGroupContFilter VariablePointer, spdGroupContComponentType INTEGER, spdGroupContComponentName SnmpAdminString, spdGroupContLastChanged TimeStamp, spdGroupContStorageType StorageType, spdGroupContRowStatus RowStatus } spdGroupContName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The administrative name of the group associated with this row. A 'group' is formed by all the rows in this table that have the same value of this object." ::= { spdGroupContentsEntry 1 } spdGroupContPriority OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The priority (sequence number) of the sub-component in a group that this row represents. This value indicates the order that each row of this table MUST be processed from low to high. For example, a row with a priority of 0 is processed before a row with a priority of 1, a 1 before a 2, etc." ::= { spdGroupContentsEntry 2 } spdGroupContFilter OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "spdGroupContFilter points to a filter that is evaluated to determine whether the spdGroupContComponentName within this row is exercised. Managers can use this object to classify groups of rules, or subgroups, together in order to achieve a greater degree of control and optimization over the execution order of the items within the group. If the Baer, et al. Standards Track [Page 17] RFC 4807 IPsec SPD configuration MIB March 2007 filter evaluates to false, the rule or subgroup will be skipped and the next rule or subgroup will be evaluated instead. This value can be used to indicate a scalar or row in a table. When indicating a row in a table, this value MUST point to the first column instance in that row. An example usage of this object would be to limit a group of rules to executing only when the IP packet being processed is designated to be processed by IKE. This effectively creates a group of IKE-specific rules. The following tables and scalars can be pointed to by this column. All but diffServMultiFieldClfrTable are defined in this MIB: diffServMultiFieldClfrTable spdIpOffsetFilterTable spdTimeFilterTable spdCompoundFilterTable spdTrueFilter spdIpsoHeaderFilterTable Implementations MAY choose to provide support for other filter tables or scalars. If this column is set to a VariablePointer value, which references a non-existent row in an otherwise supported table, the inconsistentName exception MUST be returned. If the table or scalar pointed to by the VariablePointer is not supported at all, then an inconsistentValue exception MUST be returned. If, during packet processing, a row in this table is applied to a packet and the value of this column in that row references a non-existent or non-supported object, the packet MUST be dropped." REFERENCE "RFC 3289" DEFVAL { spdTrueFilterInstance } ::= { spdGroupContentsEntry 3 } spdGroupContComponentType OBJECT-TYPE SYNTAX INTEGER { group(1), rule(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the spdGroupContComponentName object is the name of another group defined within the spdGroupContentsTable or is the name of a rule defined Baer, et al. Standards Track [Page 18] RFC 4807 IPsec SPD configuration MIB March 2007 within the spdRuleDefinitionTable." DEFVAL { rule } ::= { spdGroupContentsEntry 4 } spdGroupContComponentName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the policy rule or subgroup contained within this row, as indicated by the spdGroupContComponentType object." ::= { spdGroupContentsEntry 5 } spdGroupContLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdGroupContentsEntry 6 } spdGroupContStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdGroupContentsEntry 7 } spdGroupContRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. Baer, et al. Standards Track [Page 19] RFC 4807 IPsec SPD configuration MIB March 2007 The value of this object has no effect on whether other objects in this conceptual row can be modified. This object MUST NOT be set to active until the row to which the spdGroupContComponentName points to exists and is active. If active, this object MUST remain active unless one of the following two conditions are met: I. No active row in spdEndpointToGroupTable exists that references this row's group (i.e., indicate this row's spdGroupContName). II. Or at least one other active row in this table has a matching spdGroupContName. If neither condition is met, an attempt to set this row to something other than active MUST result in an inconsistentValue error." ::= { spdGroupContentsEntry 8 } -- -- policy definition table -- spdRuleDefinitionTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdRuleDefinitionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines a rule by associating a filter or a set of filters to an action to be executed." ::= { spdConfigObjects 4 } spdRuleDefinitionEntry OBJECT-TYPE SYNTAX SpdRuleDefinitionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row defining a particular rule definition. A rule definition binds a filter pointer to an action pointer." INDEX { spdRuleDefName } ::= { spdRuleDefinitionTable 1 } SpdRuleDefinitionEntry ::= SEQUENCE { spdRuleDefName SnmpAdminString, Baer, et al. Standards Track [Page 20] RFC 4807 IPsec SPD configuration MIB March 2007 spdRuleDefDescription SnmpAdminString, spdRuleDefFilter VariablePointer, spdRuleDefFilterNegated TruthValue, spdRuleDefAction VariablePointer, spdRuleDefAdminStatus SpdAdminStatus, spdRuleDefLastChanged TimeStamp, spdRuleDefStorageType StorageType, spdRuleDefRowStatus RowStatus } spdRuleDefName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "spdRuleDefName is the administratively assigned name of the rule referred to by the spdGroupContComponentName object." ::= { spdRuleDefinitionEntry 1 } spdRuleDefDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A user defined string. This field MAY be used for administrative tracking purposes." DEFVAL { "" } ::= { spdRuleDefinitionEntry 2 } spdRuleDefFilter OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "spdRuleDefFilter points to a filter that is used to evaluate whether the action associated with this row is executed or not. The action will only execute if the filter referenced by this object evaluates to TRUE after first applying any negation required by the spdRuleDefFilterNegated object. The following tables and scalars can be pointed to by this column. All but diffServMultiFieldClfrTable are defined in this MIB. Implementations MAY choose to provide support for other filter tables or scalars as well: diffServMultiFieldClfrTable Baer, et al. Standards Track [Page 21] RFC 4807 IPsec SPD configuration MIB March 2007 spdIpOffsetFilterTable spdTimeFilterTable spdCompoundFilterTable spdTrueFilter If this column is set to a VariablePointer value, which references a non-existent row in an otherwise supported table, the inconsistentName exception MUST be returned. If the table or scalar pointed to by the VariablePointer is not supported at all, then an inconsistentValue exception MUST be returned. If, during packet processing, this column has a value that references a non-existent or non-supported object, the packet MUST be dropped." REFERENCE "RFC 3289" ::= { spdRuleDefinitionEntry 3 } spdRuleDefFilterNegated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "spdRuleDefFilterNegated specifies whether or not the results of the filter referenced by the spdRuleDefFilter object is negated." DEFVAL { false } ::= { spdRuleDefinitionEntry 4 } spdRuleDefAction OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "This column points to the action to be taken. It MAY, but is not limited to, point to a row in one of the following tables: spdCompoundActionTable ipsaSaPreconfiguredActionTable ipiaIkeActionTable ipiaIpsecActionTable It MAY also point to one of the scalar objects beneath spdStaticActions. If this object is set to a pointer to a row in an unsupported (or unknown) table, an inconsistentValue Baer, et al. Standards Track [Page 22] RFC 4807 IPsec SPD configuration MIB March 2007 error MUST be returned. If this object is set to point to a non-existent row in an otherwise supported table, an inconsistentName error MUST be returned. If, during packet processing, this column has a value that references a non-existent or non-supported object, the packet MUST be dropped." ::= { spdRuleDefinitionEntry 5 } spdRuleDefAdminStatus OBJECT-TYPE SYNTAX SpdAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the current rule definition is considered active. If the value is enabled, the rule MUST be evaluated when processing packets. If the value is disabled, the packet processing MUST continue as if this rule's filter had effectively failed." DEFVAL { enabled } ::= { spdRuleDefinitionEntry 6 } spdRuleDefLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdRuleDefinitionEntry 7 } spdRuleDefStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have Baer, et al. Standards Track [Page 23] RFC 4807 IPsec SPD configuration MIB March 2007 to be writable." DEFVAL { nonVolatile } ::= { spdRuleDefinitionEntry 8 } spdRuleDefRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. This object MUST NOT be set to active until the containing conditions, filters, and actions have been defined. Once active, it MUST remain active until no active policyGroupContents entries are referencing it. A failed attempt to do so MUST return an inconsistentValue error." ::= { spdRuleDefinitionEntry 9 } -- -- Policy compound filter definition table -- spdCompoundFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdCompoundFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table defining compound filters and their associated parameters. A row in this table can be pointed to by a spdRuleDefFilter object." ::= { spdConfigObjects 5 } spdCompoundFilterEntry OBJECT-TYPE SYNTAX SpdCompoundFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the spdCompoundFilterTable. Each entry in this table represents a compound filter. A filter defined by this table is considered to have a TRUE return value if and only if: spdCompFiltLogicType is AND and all of the sub-filters associated with it, as defined in the spdSubfiltersTable, are all true themselves (after applying any required Baer, et al. Standards Track [Page 24] RFC 4807 IPsec SPD configuration MIB March 2007 negation, as defined by the ficFilterIsNegated object). spdCompFiltLogicType is OR and at least one of the sub-filters associated with it, as defined in the spdSubfiltersTable, is true itself (after applying any required negation, as defined by the ficFilterIsNegated object." INDEX { spdCompFiltName } ::= { spdCompoundFilterTable 1 } SpdCompoundFilterEntry ::= SEQUENCE { spdCompFiltName SnmpAdminString, spdCompFiltDescription SnmpAdminString, spdCompFiltLogicType SpdBooleanOperator, spdCompFiltLastChanged TimeStamp, spdCompFiltStorageType StorageType, spdCompFiltRowStatus RowStatus } spdCompFiltName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A user definable string. This value is used as an index into this table." ::= { spdCompoundFilterEntry 1 } spdCompFiltDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A user definable string. This field MAY be used for your administrative tracking purposes." DEFVAL { "" } ::= { spdCompoundFilterEntry 2 } spdCompFiltLogicType OBJECT-TYPE SYNTAX SpdBooleanOperator MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the sub-component filters of this compound filter are functionally ANDed or ORed together." DEFVAL { and } ::= { spdCompoundFilterEntry 3 } Baer, et al. Standards Track [Page 25] RFC 4807 IPsec SPD configuration MIB March 2007 spdCompFiltLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdCompoundFilterEntry 4 } spdCompFiltStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdCompoundFilterEntry 5 } spdCompFiltRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. Once active, it MUST NOT have its value changed if any active rows in the spdRuleDefinitionTable are currently pointing at this row." ::= { spdCompoundFilterEntry 6 } -- -- Policy filters in a cf table -- spdSubfiltersTable OBJECT-TYPE Baer, et al. Standards Track [Page 26] RFC 4807 IPsec SPD configuration MIB March 2007 SYNTAX SEQUENCE OF SpdSubfiltersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines a list of filters contained within a given compound filter defined in the spdCompoundFilterTable." ::= { spdConfigObjects 6 } spdSubfiltersEntry OBJECT-TYPE SYNTAX SpdSubfiltersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the spdSubfiltersTable. There is an entry in this table for each sub-filter of all compound filters present in the spdCompoundFilterTable." INDEX { spdCompFiltName, spdSubFiltPriority } ::= { spdSubfiltersTable 1 } SpdSubfiltersEntry ::= SEQUENCE { spdSubFiltPriority Integer32, spdSubFiltSubfilter VariablePointer, spdSubFiltSubfilterIsNegated TruthValue, spdSubFiltLastChanged TimeStamp, spdSubFiltStorageType StorageType, spdSubFiltRowStatus RowStatus } spdSubFiltPriority OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The priority of a given filter within a compound filter. The order of execution is from lowest to highest priority value (i.e., priority 0 before priority 1, 1 before 2, etc.). Implementations MAY choose to follow this ordering, as set by the manager that created the rows. This can allow a manager to intelligently construct filter lists such that faster filters are evaluated first." ::= { spdSubfiltersEntry 1 } spdSubFiltSubfilter OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION Baer, et al. Standards Track [Page 27] RFC 4807 IPsec SPD configuration MIB March 2007 "The OID of the contained filter. The value of this object is a VariablePointer that references the filter to be included in this compound filter. The following tables and scalars can be pointed to by this column. All but diffServMultiFieldClfrTable are defined in this MIB. Implementations MAY choose to provide support for other filter tables or scalars as well: diffServMultiFieldClfrTable spdIpsoHeaderFilterTable spdIpOffsetFilterTable spdTimeFilterTable spdCompoundFilterTable spdTrueFilter If this column is set to a VariablePointer value that references a non-existent row in an otherwise supported table, the inconsistentName exception MUST be returned. If the table or scalar pointed to by the VariablePointer is not supported at all, then an inconsistentValue exception MUST be returned. If, during packet processing, this column has a value that references a non-existent or non-supported object, the packet MUST be dropped." REFERENCE "RFC 3289" ::= { spdSubfiltersEntry 2 } spdSubFiltSubfilterIsNegated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether or not the result of applying this sub-filter is negated." DEFVAL { false } ::= { spdSubfiltersEntry 3 } spdSubFiltLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. Baer, et al. Standards Track [Page 28] RFC 4807 IPsec SPD configuration MIB March 2007 If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdSubfiltersEntry 4 } spdSubFiltStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdSubfiltersEntry 5 } spdSubFiltRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. This object cannot be made active until a filter referenced by the spdSubFiltSubfilter object is both defined and active. An attempt to do so MUST result in an inconsistentValue error. If active, this object MUST remain active unless one of the following two conditions are met: I. No active row in the SpdCompoundFilterTable exists that has a matching spdCompFiltName. II. Or, at least one other active row in this table has a matching spdCompFiltName. If neither condition is met, an attempt to set this row to something other than active MUST result in an inconsistentValue error." ::= { spdSubfiltersEntry 6 } Baer, et al. Standards Track [Page 29] RFC 4807 IPsec SPD configuration MIB March 2007 -- -- Static Filters -- spdStaticFilters OBJECT IDENTIFIER ::= { spdConfigObjects 7 } spdTrueFilter OBJECT-TYPE SYNTAX Integer32 (1) MAX-ACCESS read-only STATUS current DESCRIPTION "This scalar indicates a (automatic) true result for a filter. That is, this is a filter that is always true; it is useful for adding as a default filter for a default action or a set of actions." ::= { spdStaticFilters 1 } spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 } -- -- Policy IP Offset filter definition table -- spdIpOffsetFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdIpOffsetFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of filter definitions to be used within the spdRuleDefinitionTable or the spdSubfiltersTable. This type of filter is used to compare an administrator specified octet string to the octets at a particular location in a packet." ::= { spdConfigObjects 8 } spdIpOffsetFilterEntry OBJECT-TYPE SYNTAX SpdIpOffsetFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A definition of a particular filter." INDEX { spdIpOffFiltName } ::= { spdIpOffsetFilterTable 1 } Baer, et al. Standards Track [Page 30] RFC 4807 IPsec SPD configuration MIB March 2007 SpdIpOffsetFilterEntry ::= SEQUENCE { spdIpOffFiltName SnmpAdminString, spdIpOffFiltOffset Unsigned32, spdIpOffFiltType INTEGER, spdIpOffFiltValue OCTET STRING, spdIpOffFiltLastChanged TimeStamp, spdIpOffFiltStorageType StorageType, spdIpOffFiltRowStatus RowStatus } spdIpOffFiltName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The administrative name for this filter." ::= { spdIpOffsetFilterEntry 1 } spdIpOffFiltOffset OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This is the byte offset from the front of the entire IP packet where the value or arithmetic comparison is done. A value of '0' indicates the first byte of the packet header. If this value is greater than the length of the packet, the filter represented by this row should be considered to fail." ::= { spdIpOffsetFilterEntry 2 } spdIpOffFiltType OBJECT-TYPE SYNTAX INTEGER { equal(1), notEqual(2), arithmeticLess(3), arithmeticGreaterOrEqual(4), arithmeticGreater(5), arithmeticLessOrEqual(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "This defines the various tests that are used when evaluating a given filter. The various tests definable in this table are as follows: equal: - Tests if the OCTET STRING, 'spdIpOffFiltValue', matches Baer, et al. Standards Track [Page 31] RFC 4807 IPsec SPD configuration MIB March 2007 a value in the packet starting at the given offset in the packet and comparing the entire OCTET STRING of 'spdIpOffFiltValue'. Any values compared this way are assumed to be unsigned integer values in network byte order of the same length as 'spdIpOffFiltValue'. notEqual: - Tests if the OCTET STRING, 'spdIpOffFiltValue', does not match a value in the packet starting at the given offset in the packet and comparing to the entire OCTET STRING of 'spdIpOffFiltValue'. Any values compared this way are assumed to be unsigned integer values in network byte order of the same length as 'spdIpOffFiltValue'. arithmeticLess: - Tests if the OCTET STRING, 'spdIpOffFiltValue', is arithmetically less than ('<') the value starting at the given offset within the packet. The value in the packet is assumed to be an unsigned integer in network byte order of the same length as 'spdIpOffFiltValue'. arithmeticGreaterOrEqual: - Tests if the OCTET STRING, 'spdIpOffFiltValue', is arithmetically greater than or equal to ('>=') the value starting at the given offset within the packet. The value in the packet is assumed to be an unsigned integer in network byte order of the same length as 'spdIpOffFiltValue'. arithmeticGreater: - Tests if the OCTET STRING, 'spdIpOffFiltValue', is arithmetically greater than ('>') the value starting at the given offset within the packet. The value in the packet is assumed to be an unsigned integer in network byte order of the same length as 'spdIpOffFiltValue'. arithmeticLessOrEqual: - Tests if the OCTET STRING, 'spdIpOffFiltValue', is arithmetically less than or equal to ('<=') the value starting at the given offset within the packet. The value in the packet is assumed to be an unsigned integer in network byte order of the same length as 'spdIpOffFiltValue'." ::= { spdIpOffsetFilterEntry 3 } spdIpOffFiltValue OBJECT-TYPE Baer, et al. Standards Track [Page 32] RFC 4807 IPsec SPD configuration MIB March 2007 SYNTAX OCTET STRING (SIZE(1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "spdIpOffFiltValue is used for match comparisons of a packet at spdIpOffFiltOffset." ::= { spdIpOffsetFilterEntry 4 } spdIpOffFiltLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdIpOffsetFilterEntry 5 } spdIpOffFiltStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdIpOffsetFilterEntry 6 } spdIpOffFiltRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. If active, this object MUST remain active if it is Baer, et al. Standards Track [Page 33] RFC 4807 IPsec SPD configuration MIB March 2007 referenced by an active row in another table. An attempt to set it to anything other than active while it is referenced by an active row in another table MUST result in an inconsistentValue error." ::= { spdIpOffsetFilterEntry 7 } -- -- Time/scheduling filter table -- spdTimeFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdTimeFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a table of filters that can be used to effectively enable or disable policies based on a valid time range." ::= { spdConfigObjects 9 } spdTimeFilterEntry OBJECT-TYPE SYNTAX SpdTimeFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row describing a given time frame for which a policy is filtered on to activate or deactivate the rule. If all the column objects in a row are true for the current time, the row evaluates as 'true'. More explicitly, the time matching column objects in a row MUST be logically ANDed together to form the boolean true/false for the row." INDEX { spdTimeFiltName } ::= { spdTimeFilterTable 1 } SpdTimeFilterEntry ::= SEQUENCE { spdTimeFiltName SnmpAdminString, spdTimeFiltPeriod SpdTimePeriod, spdTimeFiltMonthOfYearMask BITS, spdTimeFiltDayOfMonthMask OCTET STRING, spdTimeFiltDayOfWeekMask BITS, spdTimeFiltTimeOfDayMask SpdTimePeriod, spdTimeFiltLastChanged TimeStamp, spdTimeFiltStorageType StorageType, spdTimeFiltRowStatus RowStatus } Baer, et al. Standards Track [Page 34] RFC 4807 IPsec SPD configuration MIB March 2007 spdTimeFiltName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An administratively assigned name for this filter." ::= { spdTimeFilterEntry 1 } spdTimeFiltPeriod OBJECT-TYPE SYNTAX SpdTimePeriod MAX-ACCESS read-create STATUS current DESCRIPTION "The valid time period for this filter. This column is considered 'true' if the current time is within the range of this object." DEFVAL { "THISANDPRIOR/THISANDFUTURE" } ::= { spdTimeFilterEntry 2 } spdTimeFiltMonthOfYearMask OBJECT-TYPE SYNTAX BITS { january(0), february(1), march(2), april(3), may(4), june(5), july(6), august(7), september(8), october(9), november(10), december(11) } MAX-ACCESS read-create STATUS current DESCRIPTION "A bit mask that indicates acceptable months of the year. This column evaluates to 'true' if the current month's bit is set." DEFVAL { { january, february, march, april, may, june, july, august, september, october, november, december } } ::= { spdTimeFilterEntry 3 } spdTimeFiltDayOfMonthMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-create STATUS current DESCRIPTION "Defines which days of the month the current time is valid for. It is a sequence of 64 BITS, where each BIT represents a corresponding day of the month in forward or reverse order. Starting from the left-most bit, the first 31 bits identify the day of the month, counting from the beginning of the month. The following 31 bits (bits 32-62) indicate the day of the month, counting from the end of the Baer, et al. Standards Track [Page 35] RFC 4807 IPsec SPD configuration MIB March 2007 month. For months with fewer than 31 days, the bits that correspond to the non-existent days of that month are ignored (e.g., for non-leap year Februarys, bits 29-31 and 60-62 are ignored). This column evaluates to 'true' if the current day of the month's bit is set. For example, a value of 0X'80 00 00 01 00 00 00 00' indicates that this column evaluates to true on the first and last days of the month. The last two bits in the string MUST be zero." DEFVAL { 'fffffffffffffffe'H } ::= { spdTimeFilterEntry 4 } spdTimeFiltDayOfWeekMask OBJECT-TYPE SYNTAX BITS { sunday(0), monday(1), tuesday(2), wednesday(3), thursday(4), friday(5), saturday(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "A bit mask that defines which days of the week that the current time is valid for. This column evaluates to 'true' if the current day of the week's bit is set." DEFVAL { { monday, tuesday, wednesday, thursday, friday, saturday, sunday } } ::= { spdTimeFilterEntry 5 } spdTimeFiltTimeOfDayMask OBJECT-TYPE SYNTAX SpdTimePeriod MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the start and end time of the day for which this filter evaluates to true. The date portions of the spdTimePeriod TC are ignored for purposes of evaluating this mask, and only the time-specific portions are used. This column evaluates to 'true' if the current time of day is within the range of the start and end times of the day indicated by this object." DEFVAL { "00000000T000000/00000000T240000" } ::= { spdTimeFilterEntry 6 } spdTimeFiltLastChanged OBJECT-TYPE SYNTAX TimeStamp Baer, et al. Standards Track [Page 36] RFC 4807 IPsec SPD configuration MIB March 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdTimeFilterEntry 7 } spdTimeFiltStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdTimeFilterEntry 8 } spdTimeFiltRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. If active, this object MUST remain active if it is referenced by an active row in another table. An attempt to set it to anything other than active while it is referenced by an active row in another table MUST result in an inconsistentValue error." ::= { spdTimeFilterEntry 9 } -- -- IPSO protection authority filtering -- Baer, et al. Standards Track [Page 37] RFC 4807 IPsec SPD configuration MIB March 2007 spdIpsoHeaderFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdIpsoHeaderFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of IPSO header filter definitions to be used within the spdRuleDefinitionTable or the spdSubfiltersTable. IPSO headers and their values are described in RFC 1108." REFERENCE "RFC 1108" ::= { spdConfigObjects 10 } spdIpsoHeaderFilterEntry OBJECT-TYPE SYNTAX SpdIpsoHeaderFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A definition of a particular filter." INDEX { spdIpsoHeadFiltName } ::= { spdIpsoHeaderFilterTable 1 } SpdIpsoHeaderFilterEntry ::= SEQUENCE { spdIpsoHeadFiltName SnmpAdminString, spdIpsoHeadFiltType BITS, spdIpsoHeadFiltClassification INTEGER, spdIpsoHeadFiltProtectionAuth INTEGER, spdIpsoHeadFiltLastChanged TimeStamp, spdIpsoHeadFiltStorageType StorageType, spdIpsoHeadFiltRowStatus RowStatus } spdIpsoHeadFiltName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The administrative name for this filter." ::= { spdIpsoHeaderFilterEntry 1 } spdIpsoHeadFiltType OBJECT-TYPE SYNTAX BITS { classificationLevel(0), protectionAuthority(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates which of the IPSO header field a packet is filtered on for this row. If this object is set to classification(0), the spdIpsoHeadFiltClassification Baer, et al. Standards Track [Page 38] RFC 4807 IPsec SPD configuration MIB March 2007 object indicates how the packet is filtered. If this object is set to protectionAuthority(1), the spdIpsoHeadFiltProtectionAuth object indicates how the packet is filtered." ::= { spdIpsoHeaderFilterEntry 2 } spdIpsoHeadFiltClassification OBJECT-TYPE SYNTAX INTEGER { topSecret(61), secret(90), confidential(150), unclassified(171) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the IPSO classification header field value that the packet MUST have for this row to evaluate to 'true'. The values of these enumerations are defined by RFC 1108." REFERENCE "RFC 1108" ::= { spdIpsoHeaderFilterEntry 3 } spdIpsoHeadFiltProtectionAuth OBJECT-TYPE SYNTAX INTEGER { genser(0), siopesi(1), sci(2), nsa(3), doe(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the IPSO protection authority header field value that the packet MUST have for this row to evaluate to 'true'. The values of these enumerations are defined by RFC 1108. Hence the reason the SMIv2 convention of not using 0 in enumerated lists is violated here." REFERENCE "RFC 1108" ::= { spdIpsoHeaderFilterEntry 4 } spdIpsoHeadFiltLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." Baer, et al. Standards Track [Page 39] RFC 4807 IPsec SPD configuration MIB March 2007 ::= { spdIpsoHeaderFilterEntry 5 } spdIpsoHeadFiltStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdIpsoHeaderFilterEntry 6 } spdIpsoHeadFiltRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. However, this object MUST NOT be set to active if the requirements of the spdIpsoHeadFiltType object are not met. Specifically, if the spdIpsoHeadFiltType bit for classification(0) is set, the spdIpsoHeadFiltClassification column MUST have a valid value for the row status to be set to active. If the spdIpsoHeadFiltType bit for protectionAuthority(1) is set, the spdIpsoHeadFiltProtectionAuth column MUST have a valid value for the row status to be set to active. If active, this object MUST remain active if it is referenced by an active row in another table. An attempt to set it to anything other than active while it is referenced by an active row in another table MUST result in an inconsistentValue error." ::= { spdIpsoHeaderFilterEntry 7 } -- -- compound actions table -- spdCompoundActionTable OBJECT-TYPE Baer, et al. Standards Track [Page 40] RFC 4807 IPsec SPD configuration MIB March 2007 SYNTAX SEQUENCE OF SpdCompoundActionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table used to allow multiple actions to be associated with a rule. It uses the spdSubactionsTable to do this. The rows from spdSubactionsTable that are partially indexed by spdCompActName form the set of compound actions to be performed. The spdCompActExecutionStrategy column in this table indicates how those actions are processed." ::= { spdConfigObjects 11 } spdCompoundActionEntry OBJECT-TYPE SYNTAX SpdCompoundActionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the spdCompoundActionTable." INDEX { spdCompActName } ::= { spdCompoundActionTable 1 } SpdCompoundActionEntry ::= SEQUENCE { spdCompActName SnmpAdminString, spdCompActExecutionStrategy INTEGER, spdCompActLastChanged TimeStamp, spdCompActStorageType StorageType, spdCompActRowStatus RowStatus } spdCompActName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an administratively assigned name of this compound action." ::= { spdCompoundActionEntry 1 } spdCompActExecutionStrategy OBJECT-TYPE SYNTAX INTEGER { doAll(1), doUntilSuccess(2), doUntilFailure(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates how the sub-actions are executed based on the success of the actions as they finish executing. Baer, et al. Standards Track [Page 41] RFC 4807 IPsec SPD configuration MIB March 2007 doAll - run each sub-action regardless of the exit status of the previous action. This parent action is always considered to have acted successfully. doUntilSuccess - run each sub-action until one succeeds, at which point stop processing the sub-actions within this parent compound action. If one of the sub-actions did execute successfully, this parent action is also considered to have executed successfully. doUntilFailure - run each sub-action until one fails, at which point stop processing the sub-actions within this compound action. If any sub-action fails, the result of this parent action is considered to have failed." DEFVAL { doUntilSuccess } ::= { spdCompoundActionEntry 2 } spdCompActLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdCompoundActionEntry 3 } spdCompActStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } Baer, et al. Standards Track [Page 42] RFC 4807 IPsec SPD configuration MIB March 2007 ::= { spdCompoundActionEntry 4 } spdCompActRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. Once a row in the spdCompoundActionTable has been made active, this object MUST NOT be set to destroy without first destroying all the contained rows listed in the spdSubactionsTable." ::= { spdCompoundActionEntry 5 } -- -- actions contained within a compound action -- spdSubactionsTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdSubactionsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of the sub-actions within a given compound action. Compound actions executing these actions MUST execute them in series based on the spdSubActPriority value, with the lowest value executing first." ::= { spdConfigObjects 12 } spdSubactionsEntry OBJECT-TYPE SYNTAX SpdSubactionsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row containing a reference to a given compound-action sub-action." INDEX { spdCompActName, spdSubActPriority } ::= { spdSubactionsTable 1 } SpdSubactionsEntry ::= SEQUENCE { spdSubActPriority Integer32, spdSubActSubActionName VariablePointer, Baer, et al. Standards Track [Page 43] RFC 4807 IPsec SPD configuration MIB March 2007 spdSubActLastChanged TimeStamp, spdSubActStorageType StorageType, spdSubActRowStatus RowStatus } spdSubActPriority OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The priority of a given sub-action within a compound action. The order in which sub-actions MUST be executed are based on the value from this column, with the lowest numeric value executing first (i.e., priority 0 before priority 1, 1 before 2, etc.)." ::= { spdSubactionsEntry 1 } spdSubActSubActionName OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-create STATUS current DESCRIPTION "This column points to the action to be taken. It MAY, but is not limited to, point to a row in one of the following tables: spdCompoundActionTable - Allowing recursion ipsaSaPreconfiguredActionTable ipiaIkeActionTable ipiaIpsecActionTable It MAY also point to one of the scalar objects beneath spdStaticActions. If this object is set to a pointer to a row in an unsupported (or unknown) table, an inconsistentValue error MUST be returned. If this object is set to point to a non-existent row in an otherwise supported table, an inconsistentName error MUST be returned. If, during packet processing, this column has a value that references a non-existent or non-supported object, the packet MUST be dropped." ::= { spdSubactionsEntry 2 } spdSubActLastChanged OBJECT-TYPE Baer, et al. Standards Track [Page 44] RFC 4807 IPsec SPD configuration MIB March 2007 SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this row was last modified or created either through SNMP SETs or by some other external means. If this row has not been modified since the last re-initialization of the network management subsystem, this object SHOULD have a zero value." ::= { spdSubactionsEntry 3 } spdSubActStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows in this table that were created through an external process MAY have a storage type of readOnly or permanent. For a storage type of permanent, none of the columns have to be writable." DEFVAL { nonVolatile } ::= { spdSubactionsEntry 4 } spdSubActRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the conceptual status of this row. The value of this object has no effect on whether other objects in this conceptual row can be modified. If active, this object MUST remain active unless one of the following two conditions are met. An attempt to set it to anything other than active while the following conditions are not met MUST result in an inconsistentValue error. The two conditions are: I. No active row in the spdCompoundActionTable exists which has a matching spdCompActName. II. Or, at least one other active row in this table has a matching spdCompActName." Baer, et al. Standards Track [Page 45] RFC 4807 IPsec SPD configuration MIB March 2007 ::= { spdSubactionsEntry 5 } -- -- Static Actions -- -- these are static actions that can be pointed to by the -- spdRuleDefAction or the spdSubActSubActionName objects to -- drop, accept, or reject packets. spdStaticActions OBJECT IDENTIFIER ::= { spdConfigObjects 13 } spdDropAction OBJECT-TYPE SYNTAX Integer32 (1) MAX-ACCESS read-only STATUS current DESCRIPTION "This scalar indicates that a packet MUST be dropped and SHOULD NOT have action/packet logging." ::= { spdStaticActions 1 } spdDropActionLog OBJECT-TYPE SYNTAX Integer32 (1) MAX-ACCESS read-only STATUS current DESCRIPTION "This scalar indicates that a packet MUST be dropped and SHOULD have action/packet logging." ::= { spdStaticActions 2 } spdAcceptAction OBJECT-TYPE SYNTAX Integer32 (1) MAX-ACCESS read-only STATUS current DESCRIPTION "This Scalar indicates that a packet MUST be accepted (pass-through) and SHOULD NOT have action/packet logging." ::= { spdStaticActions 3 } spdAcceptActionLog OBJECT-TYPE SYNTAX Integer32 (1) MAX-ACCESS read-only STATUS current DESCRIPTION "This scalar indicates that a packet MUST be accepted (pass-through) and SHOULD have action/packet logging." ::= { spdStaticActions 4 } Baer, et al. Standards Track [Page 46] RFC 4807 IPsec SPD configuration MIB March 2007 -- -- -- Notification objects information -- -- spdNotificationVariables OBJECT IDENTIFIER ::= { spdNotificationObjects 1 } spdNotifications OBJECT IDENTIFIER ::= { spdNotificationObjects 0 } spdActionExecuted OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Points to the action instance that was executed that resulted in the notification being sent." ::= { spdNotificationVariables 1 } spdIPEndpointAddType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the address type for the interface that the notification triggering packet is passing through." ::= { spdNotificationVariables 2 } spdIPEndpointAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the interface address for the interface that the notification triggering packet is passing through. The format of this object is specified by the spdIPEndpointAddType object." ::= { spdNotificationVariables 3 } spdIPSourceType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the source address type of the packet that Baer, et al. Standards Track [Page 47] RFC 4807 IPsec SPD configuration MIB March 2007 triggered the notification." ::= { spdNotificationVariables 4 } spdIPSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the source address of the packet that triggered the notification. The format of this object is specified by the spdIPSourceType object." ::= { spdNotificationVariables 5 } spdIPDestinationType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the destination address type of the packet that triggered the notification." ::= { spdNotificationVariables 6 } spdIPDestinationAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the destination address of the packet that triggered the notification. The format of this object is specified by the spdIPDestinationType object." ::= { spdNotificationVariables 7 } spdPacketDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Indicates if the packet that triggered the action in questions was ingress (inbound) or egress (outbound)." ::= { spdNotificationVariables 8 } spdPacketPart OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..65535)) MAX-ACCESS accessible-for-notify Baer, et al. Standards Track [Page 48] RFC 4807 IPsec SPD configuration MIB March 2007 STATUS current DESCRIPTION "spdPacketPart is the front part of the full IP packet that triggered this notification. The initial size limit is determined by the smaller of the size, indicated by: I. The value of the object with the TC syntax 'SpdIPPacketLogging' that indicated the packet SHOULD be logged and II. The size of the triggering packet. The final limit is determined by the SNMP packet size when sending the notification. The maximum size that can be included will be the smaller of the initial size, given the above, and the length that will fit in a single SNMP notification packet after the rest of the notification's objects and any other necessary packet data (headers encoding, etc.) have been included in the packet." ::= { spdNotificationVariables 9 } spdActionNotification NOTIFICATION-TYPE OBJECTS { spdActionExecuted, spdIPEndpointAddType, spdIPEndpointAddress, spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, spdIPDestinationAddress, spdPacketDirection } STATUS current DESCRIPTION "Notification that an action was executed by a rule. Only actions with logging enabled will result in this notification getting sent. The object includes the spdActionExecuted object, which will indicate which action was executed within the scope of the rule. Additionally, the spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, and spdIPDestinationAddress objects are included to indicate the packet source and destination of the packet that triggered the action. Finally, the spdIPEndpointAddType, spdIPEndpointAddress, and spdPacketDirection objects indicate which interface the executed action was associated with, and if the packet was ingress or egress through the endpoint. A spdActionNotification SHOULD be limited to a maximum of one notification sent per minute for any action notifications that do not have any other configuration controlling their send rate. Baer, et al. Standards Track [Page 49] RFC 4807 IPsec SPD configuration MIB March 2007 Note that compound actions with multiple executed sub-actions may result in multiple notifications being sent from a single rule execution." ::= { spdNotifications 1 } spdPacketNotification NOTIFICATION-TYPE OBJECTS { spdActionExecuted, spdIPEndpointAddType, spdIPEndpointAddress, spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, spdIPDestinationAddress, spdPacketDirection, spdPacketPart } STATUS current DESCRIPTION "Notification that a packet passed through a Security Association (SA). Only SAs created by actions with packet logging enabled will result in this notification getting sent. The objects sent MUST include the spdActionExecuted, which will indicate which action was executed within the scope of the rule. Additionally, the spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, and spdIPDestinationAddress objects MUST be included to indicate the packet source and destination of the packet that triggered the action. The spdIPEndpointAddType, spdIPEndpointAddress, and spdPacketDirection objects are included to indicate which endpoint the packet was associated with. Finally, spdPacketPart is included to enable sending a variable sized part of the front of the packet with the size dependent on the value of the object of TC syntax 'SpdIPPacketLogging', which indicated that logging should be done. A spdPacketNotification SHOULD be limited to a maximum of one notification sent per minute for any action notifications that do not have any other configuration controlling their send rate. An action notification SHOULD be limited to a maximum of one notification sent per minute for any action notifications that do not have any other configuration controlling their send rate." ::= { spdNotifications 2 } -- -- -- Conformance information Baer, et al. Standards Track [Page 50] RFC 4807 IPsec SPD configuration MIB March 2007 -- -- spdCompliances OBJECT IDENTIFIER ::= { spdConformanceObjects 1 } spdGroups OBJECT IDENTIFIER ::= { spdConformanceObjects 2 } -- -- Compliance statements -- -- spdRuleFilterFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that include an IPsec MIB implementation with Endpoint, Rules, and filters support. When this MIB is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB." MODULE -- This Module MANDATORY-GROUPS { spdEndpointGroup, spdGroupContentsGroup, spdRuleDefinitionGroup, spdStaticFilterGroup, spdStaticActionGroup , diffServMIBMultiFieldClfrGroup } GROUP spdIpsecSystemPolicyNameGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support a system policy group name." GROUP spdCompoundFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support compound filters." GROUP spdIPOffsetFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support IP Offset filters. In general, this SHOULD be supported by a compliant IPsec Baer, et al. Standards Track [Page 51] RFC 4807 IPsec SPD configuration MIB March 2007 Policy implementation." GROUP spdTimeFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support time filters." GROUP spdIpsoHeaderFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support IPSO Header filters." GROUP spdCompoundActionGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support compound actions." OBJECT spdEndGroupLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdGroupContComponentType SYNTAX INTEGER { rule(2) } DESCRIPTION "Support of the value group(1) is only required for implementations that support Policy Groups within Policy Groups." OBJECT spdGroupContLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdRuleDefLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdCompFiltLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdSubFiltLastChanged MIN-ACCESS not-accessible Baer, et al. Standards Track [Page 52] RFC 4807 IPsec SPD configuration MIB March 2007 DESCRIPTION "This object not required for compliance." OBJECT spdIpOffFiltLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdTimeFiltLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdIpsoHeadFiltLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdCompActLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT spdSubActLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance." OBJECT diffServMultiFieldClfrNextFree MIN-ACCESS not-accessible DESCRIPTION "This object is not required for compliance." ::= { spdCompliances 1 } spdLoggingCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that support sending notifications when actions are invoked." MODULE -- This Module MANDATORY-GROUPS { spdActionLoggingObjectGroup, spdActionNotificationGroup } ::= { spdCompliances 2 } -- Baer, et al. Standards Track [Page 53] RFC 4807 IPsec SPD configuration MIB March 2007 -- ReadOnly Compliances -- spdRuleFilterReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that include an IPsec MIB implementation with Endpoint, Rules, and filters support. If this MIB is implemented without support for read-create (i.e., in read-only), it is not in full compliance, but it can claim read-only compliance. Such a device can then be monitored, but cannot be configured with this MIB." MODULE -- This Module MANDATORY-GROUPS { spdEndpointGroup, spdGroupContentsGroup, spdRuleDefinitionGroup, spdStaticFilterGroup, spdStaticActionGroup , diffServMIBMultiFieldClfrGroup } GROUP spdIpsecSystemPolicyNameGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support a system policy group name." GROUP spdCompoundFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support compound filters." GROUP spdIPOffsetFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support IP Offset filters. In general, this SHOULD be supported by a compliant IPsec Policy implementation." GROUP spdTimeFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support time filters." GROUP spdIpsoHeaderFilterGroup DESCRIPTION "This group is mandatory for IPsec Policy Baer, et al. Standards Track [Page 54] RFC 4807 IPsec SPD configuration MIB March 2007 implementations that support IPSO Header filters." GROUP spdCompoundActionGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations that support compound actions." OBJECT spdCompActExecutionStrategy MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdCompActLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdCompActRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdCompActStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdCompFiltDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdCompFiltLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdCompFiltLogicType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdCompFiltRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdCompFiltStorageType MIN-ACCESS read-only DESCRIPTION Baer, et al. Standards Track [Page 55] RFC 4807 IPsec SPD configuration MIB March 2007 "Write access is not required." OBJECT spdEgressPolicyGroupName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdEndGroupLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdEndGroupName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdEndGroupRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdEndGroupStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdGroupContComponentName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdGroupContComponentType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdGroupContFilter MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdGroupContLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdGroupContRowStatus MIN-ACCESS read-only DESCRIPTION Baer, et al. Standards Track [Page 56] RFC 4807 IPsec SPD configuration MIB March 2007 "Write access is not required." OBJECT spdGroupContStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIngressPolicyGroupName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpOffFiltLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdIpOffFiltOffset MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpOffFiltRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpOffFiltStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpOffFiltType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpOffFiltValue MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpsoHeadFiltClassification MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpsoHeadFiltLastChanged DESCRIPTION Baer, et al. Standards Track [Page 57] RFC 4807 IPsec SPD configuration MIB March 2007 "This object is not required for compliance." OBJECT spdIpsoHeadFiltProtectionAuth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpsoHeadFiltRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpsoHeadFiltStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdIpsoHeadFiltType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdRuleDefAction MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdRuleDefAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdRuleDefDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdRuleDefFilter MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdRuleDefFilterNegated MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdRuleDefLastChanged Baer, et al. Standards Track [Page 58] RFC 4807 IPsec SPD configuration MIB March 2007 DESCRIPTION "This object is not required for compliance." OBJECT spdRuleDefRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdRuleDefStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdSubActLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdSubActRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdSubActStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdSubActSubActionName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdSubFiltLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdSubFiltRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdSubFiltStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdSubFiltSubfilter MIN-ACCESS read-only Baer, et al. Standards Track [Page 59] RFC 4807 IPsec SPD configuration MIB March 2007 DESCRIPTION "Write access is not required." OBJECT spdSubFiltSubfilterIsNegated MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdTimeFiltDayOfMonthMask MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdTimeFiltDayOfWeekMask MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdTimeFiltLastChanged DESCRIPTION "This object is not required for compliance." OBJECT spdTimeFiltMonthOfYearMask MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdTimeFiltPeriod MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdTimeFiltRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdTimeFiltTimeOfDayMask MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT spdTimeFiltStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { spdCompliances 3 } Baer, et al. Standards Track [Page 60] RFC 4807 IPsec SPD configuration MIB March 2007 -- -- -- Compliance Groups Definitions -- -- -- Endpoint, Rule, Filter Compliance Groups -- spdEndpointGroup OBJECT-GROUP OBJECTS { spdEndGroupName, spdEndGroupLastChanged, spdEndGroupStorageType, spdEndGroupRowStatus } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy Endpoint Table." ::= { spdGroups 1 } spdGroupContentsGroup OBJECT-GROUP OBJECTS { spdGroupContComponentType, spdGroupContFilter, spdGroupContComponentName, spdGroupContLastChanged, spdGroupContStorageType, spdGroupContRowStatus } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy Group Contents Table." ::= { spdGroups 2 } spdIpsecSystemPolicyNameGroup OBJECT-GROUP OBJECTS { spdIngressPolicyGroupName, spdEgressPolicyGroupName } STATUS current DESCRIPTION "This group is made up of objects represent the System Policy Group Names." ::= { spdGroups 3} spdRuleDefinitionGroup OBJECT-GROUP OBJECTS { spdRuleDefDescription, spdRuleDefFilter, spdRuleDefFilterNegated, spdRuleDefAction, spdRuleDefAdminStatus, spdRuleDefLastChanged, Baer, et al. Standards Track [Page 61] RFC 4807 IPsec SPD configuration MIB March 2007 spdRuleDefStorageType, spdRuleDefRowStatus } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy Rule Definition Table." ::= { spdGroups 4 } spdCompoundFilterGroup OBJECT-GROUP OBJECTS { spdCompFiltDescription, spdCompFiltLogicType, spdCompFiltLastChanged, spdCompFiltStorageType, spdCompFiltRowStatus, spdSubFiltSubfilter, spdSubFiltSubfilterIsNegated, spdSubFiltLastChanged, spdSubFiltStorageType, spdSubFiltRowStatus } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy Compound Filter Table and Sub-Filter Table Group." ::= { spdGroups 5 } spdStaticFilterGroup OBJECT-GROUP OBJECTS { spdTrueFilter } STATUS current DESCRIPTION "The static filter group. Currently this is just a true filter." ::= { spdGroups 6 } spdIPOffsetFilterGroup OBJECT-GROUP OBJECTS { spdIpOffFiltOffset, spdIpOffFiltType, spdIpOffFiltValue, spdIpOffFiltLastChanged, spdIpOffFiltStorageType, spdIpOffFiltRowStatus } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy IP Offset Filter Table." ::= { spdGroups 7 } spdTimeFilterGroup OBJECT-GROUP OBJECTS { spdTimeFiltPeriod, spdTimeFiltMonthOfYearMask, spdTimeFiltDayOfMonthMask, spdTimeFiltDayOfWeekMask, spdTimeFiltTimeOfDayMask, Baer, et al. Standards Track [Page 62] RFC 4807 IPsec SPD configuration MIB March 2007 spdTimeFiltLastChanged, spdTimeFiltStorageType, spdTimeFiltRowStatus } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy Time Filter Table." ::= { spdGroups 8 } spdIpsoHeaderFilterGroup OBJECT-GROUP OBJECTS { spdIpsoHeadFiltType, spdIpsoHeadFiltClassification, spdIpsoHeadFiltProtectionAuth, spdIpsoHeadFiltLastChanged, spdIpsoHeadFiltStorageType, spdIpsoHeadFiltRowStatus } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy IPSO Header Filter Table." ::= { spdGroups 9 } -- -- action compliance groups -- spdStaticActionGroup OBJECT-GROUP OBJECTS { spdDropAction, spdAcceptAction, spdDropActionLog, spdAcceptActionLog } STATUS current DESCRIPTION "This group is made up of objects from the IPsec Policy Static Actions." ::= { spdGroups 10 } spdCompoundActionGroup OBJECT-GROUP OBJECTS { spdCompActExecutionStrategy, spdCompActLastChanged, spdCompActStorageType, spdCompActRowStatus, spdSubActSubActionName, spdSubActLastChanged, spdSubActStorageType, spdSubActRowStatus } STATUS current DESCRIPTION "The IPsec Policy Compound Action Table and Actions In Baer, et al. Standards Track [Page 63] RFC 4807 IPsec SPD configuration MIB March 2007 Compound Action Table Group." ::= { spdGroups 11 } spdActionLoggingObjectGroup OBJECT-GROUP OBJECTS { spdActionExecuted, spdIPEndpointAddType, spdIPEndpointAddress, spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, spdIPDestinationAddress, spdPacketDirection, spdPacketPart } STATUS current DESCRIPTION "This group is made up of all the Notification objects for this MIB." ::= { spdGroups 12 } spdActionNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { spdActionNotification, spdPacketNotification } STATUS current DESCRIPTION "This group is made up of all the Notifications for this MIB." ::= { spdGroups 13 } END Baer, et al. Standards Track [Page 64] RFC 4807 IPsec SPD configuration MIB March 2007 7. Security Considerations 7.1. Introduction This document defines a MIB module used to configure IPsec policy services. Since IPsec provides network security services, all of its configuration data (e.g., this entire MIB) SHOULD be as secure or more secure than any of the security services IPsec provides. There are two main threats you need to protect against when configuring IPsec devices. 1. Malicious Configuration: This MIB configures network security services. If an attacker has SET access to any part of this MIB, the network security services configured by this MIB SHOULD be considered broken. The network data sent through the associated gateway should no longer be considered as protected by IPsec (i.e., it is no longer confidential or authenticated). Therefore, only the official administrators SHOULD be allowed to configure a device. In other words, administrators' identities SHOULD be authenticated and their access rights checked before they are allowed to do device configuration. The support for SET operations to the SPD MIB in a non-secure environment, without proper protection, will invalidate the security of the network traffic affected by the SPD MIB. 2. Disclosure of Configuration: In general, malicious parties SHOULD NOT be able to read security configuration data while the data is in network transit. An attacker reading the configuration data may be able to find misconfigurations in the MIB that enable attacks to the network or to the configured node. Since this entire MIB is used for security configuration, it is highly RECOMMENDED that only authorized administrators are allowed to view data in this MIB. In particular, malicious users SHOULD be prevented from reading SNMP packets containing this MIB's data. SNMP GET data SHOULD be encrypted when sent across the network. Also, only authorized administrators SHOULD be allowed SNMP GET access to any of the MIB objects. SNMP versions prior to SNMPv3 do not include adequate security. Even if the network itself is secure (e.g., by using IPsec), earlier versions of SNMP have virtually no control as to who on the secure network is allowed to access (i.e., read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers use the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Baer, et al. Standards Track [Page 65] RFC 4807 IPsec SPD configuration MIB March 2007 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to GET or SET (change/create/delete) them. Therefore, when configuring data in the IPSEC-SPD-MIB, you SHOULD use SNMP version 3. The rest of this discussion assumes the use of SNMPv3. This is a real strength, because it allows administrators the ability to load new IPsec configuration on a device and keep the conversation private and authenticated under the protection of SNMPv3 before any IPsec protections are available. Once initial establishment of IPsec configuration on a device has been achieved, it would be possible to set up IPsec SAs to then also provide security and integrity services to the configuration conversation. This may seem redundant at first, but will be shown to have a use for added privacy protection below. 7.2. Protecting against Unauthenticated Access The current SNMPv3 User Security Model provides for key-based user authentication. Typically, keys are derived from passwords (but are not required to be), and the keys are then used in Hashed Message Authentication Code (HMAC) algorithms (currently, MD5 and SHA-1 HMACs are defined) to authenticate all SNMP data. Each SNMP device keeps a (configured) list of users and keys. Under SNMPv3 user keys may be updated as often as an administrator cares to have users enter new passwords. But Perfect Forward Secrecy for user keys in SNMPv3 is not yet provided by standards track documents, although RFC2786 defines an experimental method of doing so. 7.3. Protecting against Involuntary Disclosure While sending IPsec configuration data to a Policy Enforcement Point (PEP), there are a few critical parameters that MUST NOT be observed by third parties. Specifically, except for public keys, keying information MUST NOT be allowed to be observed by third parties. This includes IKE Pre-Shared Keys and possibly the private key of a public/private key pair for use in a PKI. Were either of those parameters to be known to a third party, they could then impersonate the device to other IKE peers. Aside from those critical parameters, policy administrators have an interest in not divulging any of their policy configuration. Any knowledge about a device's configuration could help an unfriendly party compromise that device. SNMPv3 offers privacy security services, but at the time this document was written, the only standardized encryption algorithm supported by SNMPv3 is the Baer, et al. Standards Track [Page 66] RFC 4807 IPsec SPD configuration MIB March 2007 DES encryption algorithm. Support for other (stronger) cryptographic algorithms is in the works and may be completed by the time you read this. As of October 2006, there is a stronger standards track algorithm: AES [RFC3826]. When configuring the IPsec policy using this MIB, policy administrators SHOULD use a privacy security service that is at least as strong as the desired IPsec policy, e.g., If an administrator were to use this MIB to configure an IPsec connection that utilizes a AES algorithms, the SNMP communication configuring the connection SHOULD be protected by an algorithm as strong or stronger than the AES algorithm. 7.4. Bootstrapping Your Configuration Most vendors will not ship new products with a default SNMPv3 user/ password pair, but it is possible. If a device does ship with a default user/password pair, policy administrators SHOULD either change the password or configure a new user, deleting the default user (or, at a minimum, restrict the access of the default user). Most SNMPv3 distributions should, hopefully, require an out-of-band initialization over a trusted medium, such as a local console connection. 8. IANA Considerations Only two IANA considerations exist for this document. The first is just the node number allocation of the IPSEC-SPD-MIB itself within the MIB-2 tree. This is listed in the MIB definition in Section 6. The IPSEC-SPD-MIB also allows for extension action MIBs. Although additional actions are not required to use it, the node spdActions is allocated as a subtree under which IANA can assign additional actions. The second IANA consideration is that IANA would be responsible for creating a new subregistry for and assigning nodes under the spdActions subtree. This tree should have a prefix of iso.org.dod.internet.mgmt.mib-2.spdMIB.spdActions and be listed similar to the following: Decimal Name Description References ------- ---- ----------- ---------- A documented specification is required in order to assign a number. The action and it's meaning can be specified in an RFC or in another publicly available reference. The specification should have sufficient detail that interoperability between independent implementations is possible. The product of the IETF or of another standards body is acceptable or an assignment can be accepted under Baer, et al. Standards Track [Page 67] RFC 4807 IPsec SPD configuration MIB March 2007 the advice of a "designated expert". (contact IANA for the current expert) 9. Acknowledgments Many people contributed thoughts and ideas that influenced this MIB module. Some special thanks are in order to the following people: Lindy Foster (Sparta, Inc.) John Gillis (ADC) Roger Hartmuller (Sparta, Inc.) Harrie Hazewinkel Jamie Jason (Intel Corporation) David Partain (Ericsson) Lee Rafalow (IBM) Jon Saperia (JDS Consulting) Eric Vyncke (Cisco Systems) 10. References 10.1. Normative References [RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Baer, et al. Standards Track [Page 68] RFC 4807 IPsec SPD configuration MIB March 2007 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 10.2. Informative References [IPsec-ACTION] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec Security Policy IPsec Action MIB", Work in Progress, October 2006. [IKE-ACTION] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec Security Policy IKE Action MIB", Work in Progress, October 2006. [IPPMWP] Lortz, V. and L. Rafalow, "IPsec Policy Model White Paper", November 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Baer, et al. Standards Track [Page 69] RFC 4807 IPsec SPD configuration MIB March 2007 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004. Authors' Addresses Michael Baer Sparta, Inc. P.O. Box 72682 Davis, CA 95617 US EMail: baerm@tislabs.com Ricky Charlet Self EMail: rcharlet@alumni.calpoly.edu Wes Hardaker Sparta, Inc. P.O. Box 382 Davis, CA 95617 US Phone: +1 530 792 1913 EMail: hardaker@tislabs.com Robert Story Revelstone Software PO Box 1812 Tucker, GA 30085 US EMail: rstory@ipsp.revelstone.com Cliff Wang ARO 4300 S. Miami Blvd Durham, NC 27703 US EMail: cliffwangmail@yahoo.com Baer, et al. Standards Track [Page 70] RFC 4807 IPsec SPD configuration MIB March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Baer, et al. Standards Track [Page 71] snmp-mibs-downloader-1.1/mibrfcs/rfc4836.txt0000644000000000000000000044674411402176072015612 0ustar Network Working Group E. Beili Request for Comments: 4836 Actelis Networks Obsoletes: 3636 April 2007 Category: Standards Track Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This document obsoletes RFC 3636. It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. Beili Standards Track [Page 1] RFC 4836 MAU MIB April 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Relationship to RFC 3636 . . . . . . . . . . . . . . . . . 4 3.2. Relationship to Other MIBs . . . . . . . . . . . . . . . . 5 3.2.1. Relationship to the Interfaces MIB . . . . . . . . . . 5 3.2.2. Relationship to the 802.3 Repeater MIB Module . . . . 6 3.3. Management of Internal MAUs . . . . . . . . . . . . . . . 6 3.4. Mapping of IEEE 802.3 Managed Objects . . . . . . . . . . 6 3.5. Addition of New MAU Types . . . . . . . . . . . . . . . . 9 3.5.1. dot3MauType OBJECT-IDENTITIES . . . . . . . . . . . . 9 3.5.2. IANAifMauTypeListBits TEXTUAL-CONVENTION . . . . . . . 9 3.5.3. IANAifMauMediaAvailable TEXTUAL-CONVENTION . . . . . . 9 3.5.4. IANAifMauAutoNegCapBits TEXTUAL-CONVENTION . . . . . . 10 3.5.5. JackType TEXTUAL-CONVENTION . . . . . . . . . . . . . 10 4. MAU MIB Definitions . . . . . . . . . . . . . . . . . . . . . 10 5. IANA-Maintained MAU TC Definitions . . . . . . . . . . . . . . 46 6. Security Considerations . . . . . . . . . . . . . . . . . . . 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 66 Beili Standards Track [Page 2] RFC 4836 MAU MIB April 2007 1. Introduction This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 [IEEE802.3] Medium Attachment Units (MAUs). The previous version of this document, RFC 3636 [RFC3636], defined a single MIB module. This document splits the original MIB module into two, putting frequently updated object identities and textual conventions into a separate, IANA-maintained MIB module, in order to decrease the need of updating the basic MAU MIB module. The first version of the IANA-maintained MIB module also extends the list of managed objects to support Ethernet in the First Mile (EFM) and 10GBASE-CX4 interfaces. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Beili Standards Track [Page 3] RFC 4836 MAU MIB April 2007 3. Overview Instances of these object types represent attributes of an IEEE 802.3 MAU. Several types of MAUs are defined in the IEEE 802.3 CSMA/CD standard [IEEE802.3]. These MAUs may be connected to IEEE 802.3 repeaters or to 802.3 (Ethernet-like) interfaces. For convenience, this document refers to these devices as "repeater MAUs" and "interface MAUs." The definitions presented here are based on Section 30.5, "Layer Management for 10 Mb/s, 100 Mb/s, 1000 Mb/s, and 10 Gb/s Medium Attachment Units (MAUs)", Section 30.6, "Management for link Auto- Negotiation", and Annex 30A, "GDMO Specifications for 802.3 managed object classes" of IEEE Std. 802.3-2005 [IEEE802.3]. This specification is intended to provide for management of all types of Ethernet/802.3 MAUs. 3.1. Relationship to RFC 3636 The management definitions provided in this document are intended to be a superset of those defined by RFC 3636 [RFC3636]. In order to decrease the need of updating the basic MAU MIB module due to the new MAU type, Media Available state, Auto Negotiation capability and/or Jack type introduction, all relevant object identities and textual conventions have been moved to a separate, IANA-maintained MIB module IANA-MAU-MIB, the first version of which is defined in this document. Thus when a new MAU type, Media Available state, Auto Negotiation capability, and/or Jack type is defined by the IEEE 802.3 working group, only the IANA-maintained module needs to be revised, leaving the basic MAU-MIB module defined in this document unchanged. In addition, the new definitions are added to the IANA-maintained MIB module, to support Ethernet in the First Mile (EFM) and 10GBASE-CX4 interfaces, defined in IEEE Std 802.3ah-2004 [IEEE802.3ah] and IEEE Std 802.3ak-2004 [IEEE802.3ak] respectively, now part of IEEE Std 802.3-2005 [IEEE802.3]. It should be noted that the changes made in this revision will not be entirely backward-compatible with MIB modules that currently import MAU type object identity descriptors from the MAU-MIB; such modules will need to be revised to import those DESCRIPTORS from the IANA- MAU-MIB. Similarly, any management applications that process the object identity definitions (e.g., to present the DESCRIPTION text to a user) will need to get those definitions from the IANA-MAU-MIB instead of the MAU-MIB. While it is true that changes that require such adjustments are not strictly compliant with the SMIv2 rules Beili Standards Track [Page 4] RFC 4836 MAU MIB April 2007 governing MIB module revisions (see [RFC2578] Section 10), in this case continued high maintenance costs that would result from not making these changes make the deviation from the rules justified. It should be noted that the working group was not able to find any examples of MIB modules or management applications that would actually be negatively affected by the changes. 3.2. Relationship to Other MIBs It is assumed that an agent implementing MAU-MIB will also implement (at least) the 'system' group defined in the SNMPv2 MIB [RFC3418]. The following sections identify other MIBs that such an agent should implement. 3.2.1. Relationship to the Interfaces MIB The sections of this document that define interface MAU-related objects specify an extension to the Interfaces MIB [RFC2863]. An agent implementing these interface-MAU related objects MUST also implement the relevant groups of the ifCompliance3 MODULE-COMPLIANCE statement of the Interface MIB. The value of the object ifMauIfIndex is the same as the value of 'ifIndex' used to instantiate the interface to which the given MAU is connected. It is REQUIRED that an agent implementing the interface-MAU related objects in the MAU-MIB will also fully comply with the dot3Compliance2 MODULE-COMPLIANCE statement of the Ethernet-like Interfaces MIB, [RFC3635]. Furthermore, when the interface-MAU related objects are used to manage a 10GBASE-W PHY -- i.e., when ifMauType is equal to dot3MauType10GigBaseW or any other 10GBASE-W variant -- then the agent MUST also support the Ethernet WAN Interface Sublayer (WIS) MIB [RFC3637] and must follow the interface layering model specified therein. In that case the value of the object ifMauIfIndex is the same as the value of 'ifIndex' for the layer at the top of the stack, i.e., for the ifTable entry that has 'ifType' equal to ethernetCsmacd(6). If the interface-MAU related objects are used to manage a PHY that allows the MAU type to be changed dynamically, then the agent SHALL create ifTable, ifStackTable, and ifInvStackTable entries that pertain to the WIS when ifMauDefaultType is changed to a 10GBASEW variant (i.e., one of dot3MauType10GigBaseW, dot3MauType10GigBaseEW, dot3MauType10GigBaseLW, or dot3MauType10GigBaseSW) from any other type, and shall destroy the WIS-related entries when ifMauDefaultType is changed to a non- 10GBASE-W type. The agent SHALL also change the values of 'ifConnectorPresent' and 'ifHighSpeed' in the ifTable entry indexed by ifMauIfIndex as specified in [RFC3635] and [RFC3637] when ifMauDefaultType is manipulated in this way, but SHALL NOT otherwise alter that entry. Beili Standards Track [Page 5] RFC 4836 MAU MIB April 2007 (Note that repeater ports are not represented as interfaces in the Interface MIB.) 3.2.2. Relationship to the 802.3 Repeater MIB Module The section of this document that defines repeater MAU-related objects specifies an extension to the 802.3 Repeater MIB defined in [RFC2108]. An agent implementing these repeater-MAU related objects MUST also comply with the snmpRptrModCompl compliance statement of the 802.3 Repeater MIB module. The values of 'rpMauGroupIndex' and 'rpMauPortIndex' used to instantiate a repeater MAU variable SHALL be the same as the values of 'rptrPortGroupIndex' and 'rptrPortIndex' used to instantiate the port that the given MAU is connected to. 3.3. Management of Internal MAUs In some situations, a MAU can be "internal" -- i.e., its functionality is implemented entirely within a device. For example, a managed repeater may contain an internal repeater-MAU and/or an internal interface-MAU through which management communications originating on one of the repeater's external ports pass, in order to reach the management agent associated with the repeater. Such internal MAUs may or may not be managed. If they are managed, objects describing their attributes should appear in the appropriate MIB subtree: dot3RpMauBasicGroup for internal repeater-MAUs and dot3IfMauBasicGroup for internal interface-MAUs. 3.4. Mapping of IEEE 802.3 Managed Objects This section contains the mapping between relevant managed objects (attributes) defined in [IEEE802.3] Clause 30, and managed objects defined in this document. Beili Standards Track [Page 6] RFC 4836 MAU MIB April 2007 +----------------------------------+--------------------------------+ | IEEE 802.3 Managed Object | Corresponding SNMP Object | +----------------------------------+--------------------------------+ | oMAU | | +----------------------------------+--------------------------------+ | .aMAUID | rpMauIndex or ifMauIndex or | | | broadMauIndex | +----------------------------------+--------------------------------+ | .aMAUType | rpMauType or ifMauType | +----------------------------------+--------------------------------+ | .aMAUTypeList | ifMauTypeListBits | +----------------------------------+--------------------------------+ | .aMediaAvailable | rpMauMediaAvailable or | | | ifMauMediaAvailable | +----------------------------------+--------------------------------+ | .aLoseMediaCounter | rpMauMediaAvailableStateExits | | | or | | | ifMauMediaAvailableStateExits | +----------------------------------+--------------------------------+ | .aJabber | rpMauJabberState and | | | rpMauJabberingStateEnters or | | | ifMauJabberState and | | | ifMauJabberingStateEnters | +----------------------------------+--------------------------------+ | .aMAUAdminState | rpMauStatus or ifMauStatus | +----------------------------------+--------------------------------+ | .aBbMAUXmitRcvSplitType | broadMauXmtRcvSplitType | +----------------------------------+--------------------------------+ | .aBroadbandFrequencies | broadMauXmtCarrierFreq and | | | broadMauTranslationFreq | +----------------------------------+--------------------------------+ | .aFalseCarriers | rpMauFalseCarriers or | | | ifMauFalseCarriers | +----------------------------------+--------------------------------+ | .acResetMAU | rpMauStatus or ifMauStatus | +----------------------------------+--------------------------------+ | .acMAUAdminControl | rpMauStatus or ifMauStatus | +----------------------------------+--------------------------------+ | .nJabber | rpMauJabberTrap or | | | ifMauJabberTrap | +----------------------------------+--------------------------------+ | oAutoNegotiation | | +----------------------------------+--------------------------------+ | .aAutoNegID | ifMauIndex | +----------------------------------+--------------------------------+ | .aAutoNegAdminState | ifMauAutoNegAdminStatus | +----------------------------------+--------------------------------+ | .aAutoNegRemoteSignalling | ifMauAutoNegRemoteSignalling | Beili Standards Track [Page 7] RFC 4836 MAU MIB April 2007 | .aAutoNegAutoConfig | ifMauAutoNegConfig | +----------------------------------+--------------------------------+ | .aAutoNegLocalTechnologyAbility | ifMauAutoNegCapabilityBits | +----------------------------------+--------------------------------+ | .aAutoNegAdvertisedTechnologyAbi | ifMauAutoNegAdvertisedBits and | | lity | ifMauAutoNegRemoteFaultAdverti | | | sed | +----------------------------------+--------------------------------+ | .aAutoNegReceivedTechnologyAbili | ifMauAutoNegReceivedBits and | | ty | ifMauAutoNegRemoteFaultReceive | | | d | +----------------------------------+--------------------------------+ | .acAutoNegRestartAutoConfig | ifMauAutoNegRestart | +----------------------------------+--------------------------------+ | .acAutoNegAdminControl | ifMauAutoNegAdminStatus | +----------------------------------+--------------------------------+ Table 1: Mapping of IEEE 802.3 Managed Objects The following IEEE 802.3 managed objects have not been included in the MAU-MIB for the following reasons. +------------------------------------+------------------------------+ | IEEE 802.3 Managed Object | Reason for exclusion | +------------------------------------+------------------------------+ | oMAU | | +------------------------------------+------------------------------+ | .aIdleErrorCount | Only useful for 100BaseT2, | | | which is not widely | | | implemented. | +------------------------------------+------------------------------+ | oAutoNegotiation | | +------------------------------------+------------------------------+ | .aAutoNegLocalSelectorAbility | Only needed for support of | | | isoethernet (802.9a), which | | | is not supported by MAU-MIB. | +------------------------------------+------------------------------+ | .aAutoNegAdvertisedSelectorAbility | | +------------------------------------+------------------------------+ | .aAutoNegReceivedSelectorAbility | | +------------------------------------+------------------------------+ Table 2: Unmapped IEEE 802.3 Managed Objects Beili Standards Track [Page 8] RFC 4836 MAU MIB April 2007 3.5. Addition of New MAU Types 3.5.1. dot3MauType OBJECT-IDENTITIES The dot3MauType OBJECT IDENTIFIER and its OBJECT-IDENTITY definitions has been moved from the MAU-MIB into the IANA-maintained IANA-MAU- MIB, the first version of which is defined in this document. When a new IEEE 802.3 MAU is defined, IANA can re-issue a version of IANA-MAU-MIB with the new dot3MauType OBJECT-IDENTITY and its matching IANAifMauTypeListBits textual convention value and, possibly, with new IANAifMauMediaAvailable, IANAifMauAutoNegCapBits, and/or IANAifJackType values. An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for the addition of the new MAU, Media Available states, Auto Negotiation capabilities, and/or Jack types. In some cases, new MAU types may require additional managed objects or may have side effects on the behavior of existing managed objects. In such cases a standards-track specification (which may be a new document or a revision of this document) is also REQUIRED. Any such document is REQUIRED to note any special properties of the MAU types that it defines - for example, side effects on the ifStackTable as noted in this document for 10GBASE-W MAUs. 3.5.2. IANAifMauTypeListBits TEXTUAL-CONVENTION The syntax of ifMauTypeListBits is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention IANAifMauTypeListBits, which can be re- specified (with additional values, when defined by IEEE 802.3) in the IANA-maintained MIB module without issuing a new version of this document. 3.5.3. IANAifMauMediaAvailable TEXTUAL-CONVENTION The syntax of ifMauMediaAvailable and rpMauMediaAvailable is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention IANAifMauMediaAvailable, which can be re-specified (with additional values, when defined by IEEE 802.3) in the IANA-maintained MIB module without issuing a new version of this document. Beili Standards Track [Page 9] RFC 4836 MAU MIB April 2007 3.5.4. IANAifMauAutoNegCapBits TEXTUAL-CONVENTION The syntax of ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits, and ifMauAutoNegCapReceivedBits objects is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention IANAifMauAutoNegCapBits, which can be re-specified (with additional values, when defined by IEEE 802.3) in the IANA-maintained MIB module without issuing a new version of this document. 3.5.5. JackType TEXTUAL-CONVENTION The JackType Textual Convention has been deprecated in favor of the IANAifJackType defined in the IANA-maintained MIB module, so the new Jack types can be added (when defined by IEEE 802.3) without issuing a new version of this document. 4. MAU MIB Definitions MAU-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Integer32, Counter64, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI -- RFC 2578 TruthValue, AutonomousType, TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC 2579 OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580 InterfaceIndex FROM IF-MIB -- RFC 2863 IANAifMauTypeListBits, IANAifMauMediaAvailable, IANAifMauAutoNegCapBits, IANAifJackType FROM IANA-MAU-MIB -- http://www.iana.org/assignments/ianamau-mib ; mauMod MODULE-IDENTITY LAST-UPDATED "200704210000Z" -- April 21, 2007 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing Lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address Beili Standards Track [Page 10] RFC 4836 MAU MIB April 2007 Chair: Bert Wijnen Postal: Alcatel-Lucent Schagen 33 3461 GL Linschoten Netherlands Phone: +31-348-407-775 EMail: bwijnen@alcatel-lucent.com Editor: Edward Beili Postal: Actelis Networks Inc. 25 Bazel St., P.O.B. 10173 Petach-Tikva 10173 Israel Tel: +972-3-924-3491 EMail: edward.beili@actelis.com" DESCRIPTION "Management information for 802.3 MAUs. The following reference is used throughout this MIB module: [IEEE802.3] refers to: IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications'. Of particular interest is Clause 30, 'Management'. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4836; see the RFC itself for full legal notices." REVISION "200704210000Z" -- April 21, 2007 DESCRIPTION "Updated to reference IANA maintaned textual conventions for MAU types, Media Availability state, Auto Negotiation capabilities, and jack types, instead of using internally defined values. This version is published as RFC 4836." REVISION "200309190000Z" -- September 19, 2003 DESCRIPTION "Updated to include support for 10 Gb/s MAUs. This resulted in the following revisions: - Added OBJECT-IDENTITY definitions for 10 gigabit MAU types Beili Standards Track [Page 11] RFC 4836 MAU MIB April 2007 - Added fiberLC jack type to JackType TC - Extended ifMauTypeListBits with bits for the 10 gigabit MAU types - Added enumerations to ifMauMediaAvailable, and updated its DESCRIPTION to reflect behaviour at 10 Gb/s - Added 64-bit version of ifMauFalseCarriers and added mauIfGrpHCStats object group to contain the new object - Deprecated mauModIfCompl2 and replaced it with mauModIfCompl3, which includes the new object group This version published as RFC 3636." REVISION "199908240400Z" -- August 24, 1999 DESCRIPTION "This version published as RFC 2668. Updated to include support for 1000 Mb/sec MAUs and flow control negotiation." REVISION "199710310000Z" -- October 31, 1997 DESCRIPTION "Version published as RFC 2239." REVISION "199309300000Z" -- September 30, 1993 DESCRIPTION "Initial version, published as RFC 1515." ::= { snmpDot3MauMgt 6 } snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 } -- Textual Conventions JackType ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "********* THIS TC IS DEPRECATED ********** This TC has been deprecated in favour of IANAifJackType. Common enumeration values for repeater and interface MAU jack types." SYNTAX INTEGER { other(1), rj45(2), rj45S(3), -- rj45 shielded db9(4), bnc(5), fAUI(6), -- female aui Beili Standards Track [Page 12] RFC 4836 MAU MIB April 2007 mAUI(7), -- male aui fiberSC(8), fiberMIC(9), fiberST(10), telco(11), mtrj(12), -- fiber MT-RJ hssdc(13), -- fiber channel style-2 fiberLC(14) } dot3RpMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 } dot3IfMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 } dot3BroadMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 } -- OIDs under the following branch are reserved for -- the IANA-MAU-MIB to assign as MAU type values: -- { snmpDot3MauMgt 4 } dot3IfMauAutoNegGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 5 } -- the following OID is the MODULE-IDENTITY value -- for this MIB module: { snmpDot3MauMgt 6 } -- -- The Basic Repeater MAU Table -- rpMauTable OBJECT-TYPE SYNTAX SEQUENCE OF RpMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of descriptive and status information about the MAU(s) attached to the ports of a repeater." ::= { dot3RpMauBasicGroup 1 } rpMauEntry OBJECT-TYPE SYNTAX RpMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single MAU." INDEX { rpMauGroupIndex, rpMauPortIndex, Beili Standards Track [Page 13] RFC 4836 MAU MIB April 2007 rpMauIndex } ::= { rpMauTable 1 } RpMauEntry ::= SEQUENCE { rpMauGroupIndex Integer32, rpMauPortIndex Integer32, rpMauIndex Integer32, rpMauType AutonomousType, rpMauStatus INTEGER, rpMauMediaAvailable IANAifMauMediaAvailable, rpMauMediaAvailableStateExits Counter32, rpMauJabberState INTEGER, rpMauJabberingStateEnters Counter32, rpMauFalseCarriers Counter32 } rpMauGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This variable uniquely identifies the group containing the port to which the MAU described by this entry is connected. Note: In practice, a group will generally be a field-replaceable unit (i.e., module, card, or board) that can fit in the physical system enclosure, and the group number will correspond to a number marked on the physical enclosure. The group denoted by a particular value of this object is the same as the group denoted by the same value of rptrGroupIndex." REFERENCE "RFC 2108, rptrGroupIndex." ::= { rpMauEntry 1 } rpMauPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This variable uniquely identifies the repeater port within group rpMauGroupIndex to which the MAU described by this entry is connected." REFERENCE "RFC 2108, rptrPortIndex." Beili Standards Track [Page 14] RFC 4836 MAU MIB April 2007 ::= { rpMauEntry 2 } rpMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same port (rpMauPortIndex)." REFERENCE "[IEEE802.3], 30.5.1.1.1, aMAUID." ::= { rpMauEntry 3 } rpMauType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the MAU type. Values for standard IEEE 802.3 MAU types are defined in the IANA maintained IANA-MAU-MIB module, as OBJECT-IDENTITIES of dot3MauType. If the MAU type is unknown, the object identifier zeroDotZero is returned." REFERENCE "[IEEE802.3], 30.5.1.1.2, aMAUType." ::= { rpMauEntry 4 } rpMauStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), operational(3), standby(4), shutdown(5), reset(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the MAU. This object MAY be implemented as a read-only object by those agents and MAUs that do not implement software control of the MAU state. Some agents may not support setting the value of this object to some of the enumerated values. The value other(1) is returned if the MAU is in a state other than one of the states 2 through 6. Beili Standards Track [Page 15] RFC 4836 MAU MIB April 2007 The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. A MAU in the operational(3) state is fully functional; it operates, and passes signals to its attached DTE or repeater port in accordance to its specification. A MAU in standby(4) state forces DI and CI to idle, and the media transmitter to idle or fault, if supported. Standby(4) mode only applies to link type MAUs. The state of rpMauMediaAvailable is unaffected. A MAU in shutdown(5) state assumes the same condition on DI, CI, and the media transmitter, as though it were powered down or not connected. The MAU MAY return other(1) value for the rpMauJabberState and rpMauMediaAvailable objects when it is in this state. For an AUI, this state will remove power from the AUI. Setting this variable to the value reset(6) resets the MAU in the same manner as a power-off, power-on cycle of at least one-half second would. The agent is not required to return the value reset(6). Setting this variable to the value operational(3), standby(4), or shutdown(5) causes the MAU to assume the respective state, except that setting a mixing-type MAU or an AUI to standby(4) will cause the MAU to enter the shutdown state." REFERENCE "[IEEE802.3], 30.5.1.1.7, aMAUAdminState, 30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1, acResetMAU." ::= { rpMauEntry 5 } rpMauMediaAvailable OBJECT-TYPE SYNTAX IANAifMauMediaAvailable MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies Media Available state of the MAU, complementary to the rpMauStatus. Values for the standard IEEE 802.3 Media Available states are defined in the IANA maintained IANA-MAU-MIB Beili Standards Track [Page 16] RFC 4836 MAU MIB April 2007 module, as IANAifMauMediaAvailable TC." REFERENCE "[IEEE802.3], 30.5.1.1.4, aMediaAvailable." ::= { rpMauEntry 6 } rpMauMediaAvailableStateExits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that rpMauMediaAvailable for this MAU instance leaves the state available(3). Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of rptrMonitorPortLastChange." REFERENCE "[IEEE802.3], 30.5.1.1.5, aLoseMediaCounter. RFC 2108, rptrMonitorPortLastChange" ::= { rpMauEntry 7 } rpMauJabberState OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), noJabber(3), jabbering(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value other(1) is returned if the jabber state is not 2, 3, or 4. The agent MUST always return other(1) for MAU type dot3MauTypeAUI. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. If the MAU is not jabbering the agent returns noJabber(3). This is the 'normal' state. If the MAU is in jabber state the agent returns the jabbering(4) value." REFERENCE "[IEEE802.3], 30.5.1.1.6, aJabber.jabberFlag." ::= { rpMauEntry 8 } rpMauJabberingStateEnters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Beili Standards Track [Page 17] RFC 4836 MAU MIB April 2007 STATUS current DESCRIPTION "A count of the number of times that mauJabberState for this MAU instance enters the state jabbering(4). For MAUs of type dot3MauTypeAUI, dot3MauType100BaseT4, dot3MauType100BaseTX, dot3MauType100BaseFX, and all 1000Mbps types, this counter will always indicate zero. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of rptrMonitorPortLastChange." REFERENCE "[IEEE802.3], 30.5.1.1.6, aJabber.jabberCounter. RFC 2108, rptrMonitorPortLastChange" ::= { rpMauEntry 9 } rpMauFalseCarriers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of false carrier events during IDLE in 100BASE-X links. This counter does not increment at the symbol rate. It can increment after a valid carrier completion at a maximum rate of once per 100 ms until the next carrier event. This counter increments only for MAUs of type dot3MauType100BaseT4, dot3MauType100BaseTX, dot3MauType100BaseFX, and all 1000Mbps types. For all other MAU types, this counter will always indicate zero. The approximate minimum time for rollover of this counter is 7.4 hours. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of rptrMonitorPortLastChange." REFERENCE "[IEEE802.3], 30.5.1.1.10, aFalseCarriers. RFC 2108, rptrMonitorPortLastChange" ::= { rpMauEntry 10 } -- The rpJackTable applies to MAUs attached to repeaters -- which have one or more external jacks (connectors). Beili Standards Track [Page 18] RFC 4836 MAU MIB April 2007 rpJackTable OBJECT-TYPE SYNTAX SEQUENCE OF RpJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the external jacks attached to MAUs attached to the ports of a repeater." ::= { dot3RpMauBasicGroup 2 } rpJackEntry OBJECT-TYPE SYNTAX RpJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a particular jack." INDEX { rpMauGroupIndex, rpMauPortIndex, rpMauIndex, rpJackIndex } ::= { rpJackTable 1 } RpJackEntry ::= SEQUENCE { rpJackIndex Integer32, rpJackType IANAifJackType } rpJackIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the jack described by this entry from among other jacks attached to the same MAU (rpMauIndex)." ::= { rpJackEntry 1 } rpJackType OBJECT-TYPE SYNTAX IANAifJackType MAX-ACCESS read-only STATUS current DESCRIPTION "The jack connector type, as it appears on the outside of the system." ::= { rpJackEntry 2 } -- -- The Basic Interface MAU Table -- Beili Standards Track [Page 19] RFC 4836 MAU MIB April 2007 ifMauTable OBJECT-TYPE SYNTAX SEQUENCE OF IfMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of descriptive and status information about MAU(s) attached to an interface." ::= { dot3IfMauBasicGroup 1 } ifMauEntry OBJECT-TYPE SYNTAX IfMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single MAU." INDEX { ifMauIfIndex, ifMauIndex } ::= { ifMauTable 1 } IfMauEntry ::= SEQUENCE { ifMauIfIndex InterfaceIndex, ifMauIndex Integer32, ifMauType AutonomousType, ifMauStatus INTEGER, ifMauMediaAvailable IANAifMauMediaAvailable, ifMauMediaAvailableStateExits Counter32, ifMauJabberState INTEGER, ifMauJabberingStateEnters Counter32, ifMauFalseCarriers Counter32, ifMauTypeList Integer32, ifMauDefaultType AutonomousType, ifMauAutoNegSupported TruthValue, ifMauTypeListBits IANAifMauTypeListBits, ifMauHCFalseCarriers Counter64 } ifMauIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This variable uniquely identifies the interface to which the MAU described by this entry is connected." REFERENCE "RFC 2863, ifIndex" ::= { ifMauEntry 1 } Beili Standards Track [Page 20] RFC 4836 MAU MIB April 2007 ifMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same interface (ifMauIfIndex)." REFERENCE "[IEEE802.3], 30.5.1.1.1, aMAUID." ::= { ifMauEntry 2 } ifMauType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the MAU type. Values for standard IEEE 802.3 MAU types are defined in the IANA maintained IANA-MAU-MIB module, as OBJECT-IDENTITIES of dot3MauType. If the MAU type is unknown, the object identifier zeroDotZero is returned. This object represents the operational type of the MAU, as determined by either 1) the result of the auto-negotiation function or 2) if auto-negotiation is not enabled or is not implemented for this MAU, by the value of the object ifMauDefaultType. In case 2), a set to the object ifMauDefaultType will force the MAU into the new operating mode." REFERENCE "[IEEE802.3], 30.5.1.1.2, aMAUType." ::= { ifMauEntry 3 } ifMauStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), operational(3), standby(4), shutdown(5), reset(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the MAU. This object MAY be implemented as a read-only object by those agents and MAUs that do not implement software control of the MAU state. Some agents may not Beili Standards Track [Page 21] RFC 4836 MAU MIB April 2007 support setting the value of this object to some of the enumerated values. The value other(1) is returned if the MAU is in a state other than one of the states 2 through 6. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. A MAU in the operational(3) state is fully functional; it operates, and passes signals to its attached DTE or repeater port in accordance to its specification. A MAU in standby(4) state forces DI and CI to idle and the media transmitter to idle or fault, if supported. Standby(4) mode only applies to link type MAUs. The state of ifMauMediaAvailable is unaffected. A MAU in shutdown(5) state assumes the same condition on DI, CI, and the media transmitter, as though it were powered down or not connected. The MAU MAY return other(1) value for the ifMauJabberState and ifMauMediaAvailable objects when it is in this state. For an AUI, this state will remove power from the AUI. Setting this variable to the value reset(6) resets the MAU in the same manner as a power-off, power-on cycle of at least one-half second would. The agent is not required to return the value reset(6). Setting this variable to the value operational(3), standby(4), or shutdown(5) causes the MAU to assume the respective state, except that setting a mixing-type MAU or an AUI to standby(4) will cause the MAU to enter the shutdown state." REFERENCE "[IEEE802.3], 30.5.1.1.7, aMAUAdminState, 30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1, acResetMAU." ::= { ifMauEntry 4 } ifMauMediaAvailable OBJECT-TYPE Beili Standards Track [Page 22] RFC 4836 MAU MIB April 2007 SYNTAX IANAifMauMediaAvailable MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies Media Available state of the MAU, complementary to the ifMauStatus. Values for the standard IEEE 802.3 Media Available states are defined in the IANA maintained IANA-MAU-MIB module, as IANAifMauMediaAvailable TC." REFERENCE "[IEEE802.3], 30.5.1.1.4, aMediaAvailable." ::= { ifMauEntry 5 } ifMauMediaAvailableStateExits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that ifMauMediaAvailable for this MAU instance leaves the state available(3). Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE802.3], 30.5.1.1.5, aLoseMediaCounter. RFC 2863, ifCounterDiscontinuityTime." ::= { ifMauEntry 6 } ifMauJabberState OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), noJabber(3), jabbering(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value other(1) is returned if the jabber state is not 2, 3, or 4. The agent MUST always return other(1) for MAU type dot3MauTypeAUI. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. If the MAU is not jabbering the agent returns noJabber(3). This is the 'normal' state. If the MAU is in jabber state the agent returns Beili Standards Track [Page 23] RFC 4836 MAU MIB April 2007 the jabbering(4) value." REFERENCE "[IEEE802.3], 30.5.1.1.6, aJabber.jabberFlag." ::= { ifMauEntry 7 } ifMauJabberingStateEnters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that mauJabberState for this MAU instance enters the state jabbering(4). This counter will always indicate zero for MAUs of type dot3MauTypeAUI and those of speeds above 10Mbps. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE802.3], 30.5.1.1.6, aJabber.jabberCounter. RFC 2863, ifCounterDiscontinuityTime." ::= { ifMauEntry 8 } ifMauFalseCarriers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of false carrier events during IDLE in 100BASE-X and 1000BASE-X links. For all other MAU types, this counter will always indicate zero. This counter does not increment at the symbol rate. It can increment after a valid carrier completion at a maximum rate of once per 100 ms for 100BASE-X and once per 10us for 1000BASE-X until the next CarrierEvent. This counter can roll over very quickly. A management station is advised to poll the ifMauHCFalseCarriers instead of this counter in order to avoid loss of information. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE802.3], 30.5.1.1.10, aFalseCarriers. Beili Standards Track [Page 24] RFC 4836 MAU MIB April 2007 RFC 2863, ifCounterDiscontinuityTime." ::= { ifMauEntry 9 } ifMauTypeList OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This object has been deprecated in favour of ifMauTypeListBits. A value that uniquely identifies the set of possible IEEE 802.3 types that the MAU could be. The value is a sum that initially takes the value zero. Then, for each type capability of this MAU, 2 raised to the power noted below is added to the sum. For example, a MAU that has the capability to be only 10BASE-T would have a value of 512 (2**9). In contrast, a MAU that supports both 10Base-T (full duplex) and 100BASE-TX (full duplex) would have a value of ((2**11) + (2**16)), or 67584. The powers of 2 assigned to the capabilities are these: Power Capability 0 other or unknown 1 AUI 2 10BASE-5 3 FOIRL 4 10BASE-2 5 10BASE-T duplex mode unknown 6 10BASE-FP 7 10BASE-FB 8 10BASE-FL duplex mode unknown 9 10BROAD36 10 10BASE-T half duplex mode 11 10BASE-T full duplex mode 12 10BASE-FL half duplex mode 13 10BASE-FL full duplex mode 14 100BASE-T4 15 100BASE-TX half duplex mode 16 100BASE-TX full duplex mode 17 100BASE-FX half duplex mode 18 100BASE-FX full duplex mode 19 100BASE-T2 half duplex mode Beili Standards Track [Page 25] RFC 4836 MAU MIB April 2007 20 100BASE-T2 full duplex mode If auto-negotiation is present on this MAU, this object will map to ifMauAutoNegCapability." ::= { ifMauEntry 10 } ifMauDefaultType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the default administrative baseband MAU type to be used in conjunction with the operational MAU type denoted by ifMauType. The set of possible values for this object is the same as the set defined for the ifMauType object. This object represents the administratively-configured type of the MAU. If auto-negotiation is not enabled or is not implemented for this MAU, the value of this object determines the operational type of the MAU. In this case, a set to this object will force the MAU into the specified operating mode. If auto-negotiation is implemented and enabled for this MAU, the operational type of the MAU is determined by auto-negotiation, and the value of this object denotes the type to which the MAU will automatically revert if/when auto-negotiation is later disabled. NOTE TO IMPLEMENTORS: It may be necessary to provide for underlying hardware implementations which do not follow the exact behavior specified above. In particular, when ifMauAutoNegAdminStatus transitions from enabled to disabled, the agent implementation MUST ensure that the operational type of the MAU (as reported by ifMauType) correctly transitions to the value specified by this object, rather than continuing to operate at the value earlier determined by the auto-negotiation function." REFERENCE "[IEEE802.3], 30.5.1.1.1, aMAUID, and 22.2.4.1.4." ::= { ifMauEntry 11 } Beili Standards Track [Page 26] RFC 4836 MAU MIB April 2007 ifMauAutoNegSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not auto-negotiation is supported on this MAU." ::= { ifMauEntry 12 } ifMauTypeListBits OBJECT-TYPE SYNTAX IANAifMauTypeListBits MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of possible IEEE 802.3 types that the MAU could be. If auto-negotiation is present on this MAU, this object will map to ifMauAutoNegCapabilityBits. Note that this MAU may be capable of operating as a MAU type that is beyond the scope of this MIB. This is indicated by returning the bit value bOther in addition to any bit values for standard capabilities that are listed in the IANAifMauTypeListBits TC." ::= { ifMauEntry 13 } ifMauHCFalseCarriers OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of false carrier events during IDLE in 100BASE-X and 1000BASE-X links. For all other MAU types, this counter will always indicate zero. This counter does not increment at the symbol rate. This counter is a 64-bit version of ifMauFalseCarriers. Since the 32-bit version of this counter can roll over very quickly, management stations are advised to poll the 64-bit version instead, in order to avoid loss of information. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime." REFERENCE "[IEEE802.3], 30.5.1.1.10, aFalseCarriers. Beili Standards Track [Page 27] RFC 4836 MAU MIB April 2007 RFC 2863, ifCounterDiscontinuityTime." ::= { ifMauEntry 14 } -- The ifJackTable applies to MAUs attached to interfaces -- which have one or more external jacks (connectors). ifJackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the external jacks attached to MAUs attached to an interface." ::= { dot3IfMauBasicGroup 2 } ifJackEntry OBJECT-TYPE SYNTAX IfJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a particular jack." INDEX { ifMauIfIndex, ifMauIndex, ifJackIndex } ::= { ifJackTable 1 } IfJackEntry ::= SEQUENCE { ifJackIndex Integer32, ifJackType IANAifJackType } ifJackIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the jack described by this entry from among other jacks attached to the same MAU." ::= { ifJackEntry 1 } ifJackType OBJECT-TYPE SYNTAX IANAifJackType MAX-ACCESS read-only STATUS current DESCRIPTION "The jack connector type, as it appears on the outside of the system." ::= { ifJackEntry 2 } Beili Standards Track [Page 28] RFC 4836 MAU MIB April 2007 -- -- The MAU Auto-Negotiation Table -- ifMauAutoNegTable OBJECT-TYPE SYNTAX SEQUENCE OF IfMauAutoNegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration and status objects for the auto-negotiation function of MAUs attached to interfaces. The ifMauAutoNegTable applies to systems in which auto-negotiation is supported on one or more MAUs attached to interfaces. Note that if auto-negotiation is present and enabled, the ifMauType object reflects the result of the auto-negotiation function." ::= { dot3IfMauAutoNegGroup 1 } ifMauAutoNegEntry OBJECT-TYPE SYNTAX IfMauAutoNegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing configuration and status information for the auto-negotiation function of a particular MAU." INDEX { ifMauIfIndex, ifMauIndex } ::= { ifMauAutoNegTable 1 } IfMauAutoNegEntry ::= SEQUENCE { ifMauAutoNegAdminStatus INTEGER, ifMauAutoNegRemoteSignaling INTEGER, ifMauAutoNegConfig INTEGER, ifMauAutoNegCapability Integer32, ifMauAutoNegCapAdvertised Integer32, ifMauAutoNegCapReceived Integer32, ifMauAutoNegRestart INTEGER, ifMauAutoNegCapabilityBits IANAifMauAutoNegCapBits, ifMauAutoNegCapAdvertisedBits IANAifMauAutoNegCapBits, ifMauAutoNegCapReceivedBits IANAifMauAutoNegCapBits, ifMauAutoNegRemoteFaultAdvertised INTEGER, ifMauAutoNegRemoteFaultReceived INTEGER } Beili Standards Track [Page 29] RFC 4836 MAU MIB April 2007 ifMauAutoNegAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to enabled(1) will cause the interface that has the auto-negotiation signaling ability to be enabled. If the value of this object is disabled(2) then the interface will act as it would if it had no auto-negotiation signaling. Under these conditions, an IEEE 802.3 MAU will immediately be forced to the state indicated by the value of the object ifMauDefaultType. NOTE TO IMPLEMENTORS: When ifMauAutoNegAdminStatus transitions from enabled to disabled, the agent implementation MUST ensure that the operational type of the MAU (as reported by ifMauType) correctly transitions to the value specified by the ifMauDefaultType object, rather than continuing to operate at the value earlier determined by the auto-negotiation function." REFERENCE "[IEEE802.3], 30.6.1.1.2, aAutoNegAdminState, and 30.6.1.2.2, acAutoNegAdminControl." ::= { ifMauAutoNegEntry 1 } ifMauAutoNegRemoteSignaling OBJECT-TYPE SYNTAX INTEGER { detected(1), notdetected(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating whether the remote end of the link is using auto-negotiation signaling. It takes the value detected(1) if and only if, during the previous link negotiation, FLP Bursts were received." REFERENCE "[IEEE802.3], 30.6.1.1.3, aAutoNegRemoteSignaling." ::= { ifMauAutoNegEntry 2 } ifMauAutoNegConfig OBJECT-TYPE Beili Standards Track [Page 30] RFC 4836 MAU MIB April 2007 SYNTAX INTEGER { other(1), configuring(2), complete(3), disabled(4), parallelDetectFail(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the current status of the auto-negotiation process. The enumeration parallelDetectFail(5) maps to a failure in parallel detection as defined in 28.2.3.1 of [IEEE802.3]." REFERENCE "[IEEE802.3], 30.6.1.1.4, aAutoNegAutoConfig." ::= { ifMauAutoNegEntry 4 } ifMauAutoNegCapability OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This object has been deprecated in favour of ifMauAutoNegCapabilityBits. A value that uniquely identifies the set of capabilities of the local auto-negotiation entity. The value is a sum that initially takes the value zero. Then, for each capability of this interface, 2 raised to the power noted below is added to the sum. For example, an interface that has the capability to support only 100Base-TX half duplex would have a value of 32768 (2**15). In contrast, an interface that supports both 100Base-TX half duplex and 100Base-TX full duplex would have a value of 98304 ((2**15) + (2**16)). The powers of 2 assigned to the capabilities are these: Power Capability 0 other or unknown (1-9) (reserved) 10 10BASE-T half duplex mode 11 10BASE-T full duplex mode 12 (reserved) Beili Standards Track [Page 31] RFC 4836 MAU MIB April 2007 13 (reserved) 14 100BASE-T4 15 100BASE-TX half duplex mode 16 100BASE-TX full duplex mode 17 (reserved) 18 (reserved) 19 100BASE-T2 half duplex mode 20 100BASE-T2 full duplex mode Note that interfaces that support this MIB may have capabilities that extend beyond the scope of this MIB." REFERENCE "[IEEE802.3], 30.6.1.1.5, aAutoNegLocalTechnologyAbility." ::= { ifMauAutoNegEntry 5 } ifMauAutoNegCapAdvertised OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This object has been deprecated in favour of ifMauAutoNegCapAdvertisedBits. A value that uniquely identifies the set of capabilities advertised by the local auto-negotiation entity. Refer to ifMauAutoNegCapability for a description of the possible values of this object. Capabilities in this object that are not available in ifMauAutoNegCapability cannot be enabled." REFERENCE "[IEEE802.3], 30.6.1.1.6, aAutoNegAdvertisedTechnologyAbility." ::= { ifMauAutoNegEntry 6 } ifMauAutoNegCapReceived OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This object has been deprecated in favour of ifMauAutoNegCapReceivedBits. A value that uniquely identifies the set of Beili Standards Track [Page 32] RFC 4836 MAU MIB April 2007 capabilities received from the remote auto-negotiation entity. Refer to ifMauAutoNegCapability for a description of the possible values of this object. Note that interfaces that support this MIB may be attached to remote auto-negotiation entities that have capabilities beyond the scope of this MIB." REFERENCE "[IEEE802.3], 30.6.1.1.7, aAutoNegReceivedTechnologyAbility." ::= { ifMauAutoNegEntry 7 } ifMauAutoNegRestart OBJECT-TYPE SYNTAX INTEGER { restart(1), norestart(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "If the value of this object is set to restart(1) then this will force auto-negotiation to begin link renegotiation. If auto-negotiation signaling is disabled, a write to this object has no effect. Setting the value of this object to norestart(2) has no effect." REFERENCE "[IEEE802.3], 30.6.1.2.1, acAutoNegRestartAutoConfig." ::= { ifMauAutoNegEntry 8 } ifMauAutoNegCapabilityBits OBJECT-TYPE SYNTAX IANAifMauAutoNegCapBits MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities of the local auto-negotiation entity. Note that interfaces that support this MIB may have capabilities that extend beyond the scope of this MIB. Note that the local auto-negotiation entity may support some capabilities beyond the scope of this MIB. This is indicated by returning the bit value bOther in addition to any bit values for standard capabilities that are listed in the IANAifMauAutoNegCapBits TC." Beili Standards Track [Page 33] RFC 4836 MAU MIB April 2007 REFERENCE "[IEEE802.3], 30.6.1.1.5, aAutoNegLocalTechnologyAbility." ::= { ifMauAutoNegEntry 9 } ifMauAutoNegCapAdvertisedBits OBJECT-TYPE SYNTAX IANAifMauAutoNegCapBits MAX-ACCESS read-write STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities advertised by the local auto-negotiation entity. Capabilities in this object that are not available in ifMauAutoNegCapabilityBits cannot be enabled. Note that the local auto-negotiation entity may advertise some capabilities beyond the scope of this MIB. This is indicated by returning the bit value bOther in addition to any bit values for standard capabilities that are listed in the IANAifMauAutoNegCapBits TC." REFERENCE "[IEEE802.3], 30.6.1.1.6, aAutoNegAdvertisedTechnologyAbility." ::= { ifMauAutoNegEntry 10 } ifMauAutoNegCapReceivedBits OBJECT-TYPE SYNTAX IANAifMauAutoNegCapBits MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities received from the remote auto-negotiation entity. Note that interfaces that support this MIB may be attached to remote auto-negotiation entities that have capabilities beyond the scope of this MIB. This is indicated by returning the bit value bOther in addition to any bit values for standard capabilities that are listed in the IANAifMauAutoNegCapBits TC." REFERENCE "[IEEE802.3], 30.6.1.1.7, aAutoNegReceivedTechnologyAbility." ::= { ifMauAutoNegEntry 11 } ifMauAutoNegRemoteFaultAdvertised OBJECT-TYPE SYNTAX INTEGER { noError(1), offline(2), Beili Standards Track [Page 34] RFC 4836 MAU MIB April 2007 linkFailure(3), autoNegError(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "A value that identifies any local fault indications that this MAU has detected and will advertise at the next auto-negotiation interaction for 1000Mbps MAUs." REFERENCE "[IEEE802.3], 30.6.1.1.6, aAutoNegAdvertisedTechnologyAbility." ::= { ifMauAutoNegEntry 12 } ifMauAutoNegRemoteFaultReceived OBJECT-TYPE SYNTAX INTEGER { noError(1), offline(2), linkFailure(3), autoNegError(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value that identifies any fault indications received from the far end of a link by the local auto-negotiation entity for 1000Mbps MAUs." REFERENCE "[IEEE802.3], 30.6.1.1.7, aAutoNegReceivedTechnologyAbility." ::= { ifMauAutoNegEntry 13 } -- -- The Basic Broadband MAU Table -- broadMauBasicTable OBJECT-TYPE SYNTAX SEQUENCE OF BroadMauBasicEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This entire table has been deprecated. There have been no reported implementations of this table, and it is unlikely that there ever will be. IEEE recommends that broadband MAU types should not be used for new installations. Table of descriptive and status information Beili Standards Track [Page 35] RFC 4836 MAU MIB April 2007 about the broadband MAUs connected to interfaces." ::= { dot3BroadMauBasicGroup 1 } broadMauBasicEntry OBJECT-TYPE SYNTAX BroadMauBasicEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** An entry in the table, containing information about a single broadband MAU." INDEX { broadMauIfIndex, broadMauIndex } ::= { broadMauBasicTable 1 } BroadMauBasicEntry ::= SEQUENCE { broadMauIfIndex InterfaceIndex, broadMauIndex Integer32, broadMauXmtRcvSplitType INTEGER, broadMauXmtCarrierFreq Integer32, broadMauTranslationFreq Integer32 } broadMauIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This variable uniquely identifies the interface to which the MAU described by this entry is connected." REFERENCE "RFC 2863, ifIndex." ::= { broadMauBasicEntry 1 } broadMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This variable uniquely identifies the MAU connected to interface broadMauIfIndex that is Beili Standards Track [Page 36] RFC 4836 MAU MIB April 2007 described by this entry." REFERENCE "[IEEE802.3], 30.5.1.1.1, aMAUID." ::= { broadMauBasicEntry 2 } broadMauXmtRcvSplitType OBJECT-TYPE SYNTAX INTEGER { other(1), single(2), dual(3) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This object indicates the type of frequency multiplexing/cabling system used to separate the transmit and receive paths for the 10BROAD36 MAU. The value other(1) is returned if the split type is not either single or dual. The value single(2) indicates a single cable system. The value dual(3) indicates a dual cable system, offset normally zero." REFERENCE "[IEEE802.3], 30.5.1.1.8, aBbMAUXmitRcvSplitType." ::= { broadMauBasicEntry 3 } broadMauXmtCarrierFreq OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This variable indicates the transmit carrier frequency of the 10BROAD36 MAU in MHz/4; that is, in units of 250 kHz." REFERENCE "[IEEE802.3], 30.5.1.1.9, aBroadbandFrequencies.xmitCarrierFrequency." ::= { broadMauBasicEntry 4 } broadMauTranslationFreq OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This variable indicates the translation offset Beili Standards Track [Page 37] RFC 4836 MAU MIB April 2007 frequency of the 10BROAD36 MAU in MHz/4; that is, in units of 250 kHz." REFERENCE "[IEEE802.3], 30.5.1.1.9, aBroadbandFrequencies.translationFrequency." ::= { broadMauBasicEntry 5 } -- Notifications for use by 802.3 MAUs snmpDot3MauTraps OBJECT IDENTIFIER ::= { snmpDot3MauMgt 0 } rpMauJabberTrap NOTIFICATION-TYPE OBJECTS { rpMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed repeater MAU enters the jabber state. The agent MUST throttle the generation of consecutive rpMauJabberTraps so that there is at least a five-second gap between them." REFERENCE "[IEEE802.3], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauTraps 1 } ifMauJabberTrap NOTIFICATION-TYPE OBJECTS { ifMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed interface MAU enters the jabber state. The agent MUST throttle the generation of consecutive ifMauJabberTraps so that there is at least a five-second gap between them." REFERENCE "[IEEE802.3], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauTraps 2 } -- Conformance information mauModConf OBJECT IDENTIFIER ::= { mauMod 1 } mauModCompls OBJECT IDENTIFIER ::= { mauModConf 1 } mauModObjGrps OBJECT IDENTIFIER ::= { mauModConf 2 } mauModNotGrps OBJECT IDENTIFIER ::= { mauModConf 3 } -- Object groups Beili Standards Track [Page 38] RFC 4836 MAU MIB April 2007 mauRpGrpBasic OBJECT-GROUP OBJECTS { rpMauGroupIndex, rpMauPortIndex, rpMauIndex, rpMauType, rpMauStatus, rpMauMediaAvailable, rpMauMediaAvailableStateExits, rpMauJabberState, rpMauJabberingStateEnters } STATUS current DESCRIPTION "Basic conformance group for MAUs attached to repeater ports. This group is also the conformance specification for RFC 1515 implementations." ::= { mauModObjGrps 1 } mauRpGrp100Mbs OBJECT-GROUP OBJECTS { rpMauFalseCarriers } STATUS current DESCRIPTION "Conformance group for MAUs attached to repeater ports with 100 Mb/s or greater capability." ::= { mauModObjGrps 2 } mauRpGrpJack OBJECT-GROUP OBJECTS { rpJackType } STATUS current DESCRIPTION "Conformance group for MAUs attached to repeater ports with managed jacks." ::= { mauModObjGrps 3 } mauIfGrpBasic OBJECT-GROUP OBJECTS { ifMauIfIndex, ifMauIndex, ifMauType, ifMauStatus, ifMauMediaAvailable, ifMauMediaAvailableStateExits, ifMauJabberState, ifMauJabberingStateEnters } STATUS current DESCRIPTION "Basic conformance group for MAUs attached to interfaces. This group also provides a conformance specification for RFC 1515 implementations." Beili Standards Track [Page 39] RFC 4836 MAU MIB April 2007 ::= { mauModObjGrps 4 } mauIfGrp100Mbs OBJECT-GROUP OBJECTS { ifMauFalseCarriers, ifMauTypeList, ifMauDefaultType, ifMauAutoNegSupported } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** Conformance group for MAUs attached to interfaces with 100 Mb/s capability. This object group has been deprecated in favor of mauIfGrpHighCapacity." ::= { mauModObjGrps 5 } mauIfGrpJack OBJECT-GROUP OBJECTS { ifJackType } STATUS current DESCRIPTION "Conformance group for MAUs attached to interfaces with managed jacks." ::= { mauModObjGrps 6 } mauIfGrpAutoNeg OBJECT-GROUP OBJECTS { ifMauAutoNegAdminStatus, ifMauAutoNegRemoteSignaling, ifMauAutoNegConfig, ifMauAutoNegCapability, ifMauAutoNegCapAdvertised, ifMauAutoNegCapReceived, ifMauAutoNegRestart } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** Conformance group for MAUs attached to interfaces with managed auto-negotiation. This object group has been deprecated in favor of mauIfGrpAutoNeg2." ::= { mauModObjGrps 7 } mauBroadBasic OBJECT-GROUP OBJECTS { broadMauIfIndex, broadMauIndex, Beili Standards Track [Page 40] RFC 4836 MAU MIB April 2007 broadMauXmtRcvSplitType, broadMauXmtCarrierFreq, broadMauTranslationFreq } STATUS deprecated DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** Conformance group for broadband MAUs attached to interfaces. This object group is deprecated. There have been no reported implementations of this group, and it was felt to be unlikely that there will be any future implementations." ::= { mauModObjGrps 8 } mauIfGrpHighCapacity OBJECT-GROUP OBJECTS { ifMauFalseCarriers, ifMauTypeListBits, ifMauDefaultType, ifMauAutoNegSupported } STATUS current DESCRIPTION "Conformance group for MAUs attached to interfaces with 100 Mb/s or greater capability." ::= { mauModObjGrps 9 } mauIfGrpAutoNeg2 OBJECT-GROUP OBJECTS { ifMauAutoNegAdminStatus, ifMauAutoNegRemoteSignaling, ifMauAutoNegConfig, ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits, ifMauAutoNegCapReceivedBits, ifMauAutoNegRestart } STATUS current DESCRIPTION "Conformance group for MAUs attached to interfaces with managed auto-negotiation." ::= { mauModObjGrps 10 } mauIfGrpAutoNeg1000Mbps OBJECT-GROUP OBJECTS { ifMauAutoNegRemoteFaultAdvertised, ifMauAutoNegRemoteFaultReceived } STATUS current DESCRIPTION "Conformance group for 1000Mbps MAUs attached to interfaces with managed auto-negotiation." ::= { mauModObjGrps 11 } Beili Standards Track [Page 41] RFC 4836 MAU MIB April 2007 mauIfGrpHCStats OBJECT-GROUP OBJECTS { ifMauHCFalseCarriers } STATUS current DESCRIPTION "Conformance for high capacity statistics for MAUs attached to interfaces." ::= { mauModObjGrps 12 } -- Notification groups rpMauNotifications NOTIFICATION-GROUP NOTIFICATIONS { rpMauJabberTrap } STATUS current DESCRIPTION "Notifications for repeater MAUs." ::= { mauModNotGrps 1 } ifMauNotifications NOTIFICATION-GROUP NOTIFICATIONS { ifMauJabberTrap } STATUS current DESCRIPTION "Notifications for interface MAUs." ::= { mauModNotGrps 2 } -- Compliances mauModRpCompl MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** Compliance for MAUs attached to repeater ports. This compliance is deprecated and replaced by mauModRpCompl2, which corrects an oversight by allowing rpMauStatus to be implemented read-only." MODULE -- this module MANDATORY-GROUPS { mauRpGrpBasic } GROUP mauRpGrp100Mbs DESCRIPTION "Implementation of this optional group is recommended for MAUs that have 100Mb/s or greater capability." GROUP mauRpGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs that have one or more external jacks." GROUP rpMauNotifications Beili Standards Track [Page 42] RFC 4836 MAU MIB April 2007 DESCRIPTION "Implementation of this group is recommended for MAUs attached to repeater ports." ::= { mauModCompls 1 } mauModIfCompl MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** Compliance for MAUs attached to interfaces. This compliance is deprecated and replaced by mauModIfCompl2." MODULE -- this module MANDATORY-GROUPS { mauIfGrpBasic } GROUP mauIfGrp100Mbs DESCRIPTION "Implementation of this optional group is recommended for MAUs that have 100Mb/s capability." GROUP mauIfGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs that have one or more external jacks." GROUP mauIfGrpAutoNeg DESCRIPTION "Implementation of this group is mandatory for MAUs that support managed auto-negotiation." GROUP mauBroadBasic DESCRIPTION "Implementation of this group is mandatory for broadband MAUs." GROUP ifMauNotifications DESCRIPTION "Implementation of this group is recommended for MAUs attached to interfaces." ::= { mauModCompls 2 } mauModIfCompl2 MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** Compliance for MAUs attached to interfaces. This compliance is deprecated and replaced by mauModIfCompl3." Beili Standards Track [Page 43] RFC 4836 MAU MIB April 2007 MODULE -- this module MANDATORY-GROUPS { mauIfGrpBasic } GROUP mauIfGrpHighCapacity DESCRIPTION "Implementation of this optional group is recommended for MAUs that have 100Mb/s or greater capability." GROUP mauIfGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs that have one or more external jacks." GROUP mauIfGrpAutoNeg2 DESCRIPTION "Implementation of this group is mandatory for MAUs that support managed auto-negotiation." GROUP mauIfGrpAutoNeg1000Mbps DESCRIPTION "Implementation of this group is mandatory for MAUs that have 1000Mb/s or greater capability and support managed auto-negotiation." GROUP ifMauNotifications DESCRIPTION "Implementation of this group is recommended for MAUs attached to interfaces." OBJECT ifMauStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mauModCompls 3 } mauModRpCompl2 MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for MAUs attached to repeater ports. Note that compliance with this compliance statement requires compliance with the snmpRptrModCompl MODULE-COMPLIANCE statement of the SNMP-REPEATER-MIB (RFC 2108)." MODULE -- this module MANDATORY-GROUPS { mauRpGrpBasic } GROUP mauRpGrp100Mbs Beili Standards Track [Page 44] RFC 4836 MAU MIB April 2007 DESCRIPTION "Implementation of this optional group is recommended for MAUs that have 100Mb/s or greater capability." GROUP mauRpGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs that have one or more external jacks." GROUP rpMauNotifications DESCRIPTION "Implementation of this group is recommended for MAUs attached to repeater ports." OBJECT rpMauStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mauModCompls 4 } mauModIfCompl3 MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for MAUs attached to interfaces. Note that compliance with this compliance statement requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB (RFC 2863) and the dot3Compliance2 MODULE-COMPLIANCE statement of the EtherLike-MIB (RFC3635)." MODULE -- this module MANDATORY-GROUPS { mauIfGrpBasic } GROUP mauIfGrpHighCapacity DESCRIPTION "Implementation of this optional group is recommended for MAUs that have 100Mb/s or greater capability." GROUP mauIfGrpHCStats DESCRIPTION "Implementation of this group is mandatory for MAUs that have 1000Mb/s capacity, and is recommended for MAUs that have 100Mb/s capacity." GROUP mauIfGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs that have one or more external jacks." Beili Standards Track [Page 45] RFC 4836 MAU MIB April 2007 GROUP mauIfGrpAutoNeg2 DESCRIPTION "Implementation of this group is mandatory for MAUs that support managed auto-negotiation." GROUP mauIfGrpAutoNeg1000Mbps DESCRIPTION "Implementation of this group is mandatory for MAUs that have 1000Mb/s or greater capability and support managed auto-negotiation." GROUP ifMauNotifications DESCRIPTION "Implementation of this group is recommended for MAUs attached to interfaces." OBJECT ifMauStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mauModCompls 5 } END 5. IANA-Maintained MAU TC Definitions IANA-MAU-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC ; ianaMauMIB MODULE-IDENTITY LAST-UPDATED "200704210000Z" -- April 21, 2007 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1-310-823-9358 EMail: iana@iana.org" DESCRIPTION "This MIB module defines dot3MauType OBJECT-IDENTITIES and IANAifMauListBits, IANAifMauMediaAvailable, IANAifMauAutoNegCapBits, and IANAifJackType Beili Standards Track [Page 46] RFC 4836 MAU MIB April 2007 TEXTUAL-CONVENTIONs, specifying enumerated values of the ifMauTypeListBits, ifMauMediaAvailable / rpMauMediaAvailable, ifMauAutoNegCapabilityBits / ifMauAutoNegCapAdvertisedBits / ifMauAutoNegCapReceivedBits and ifJackType / rpJackType objects respectively, defined in the MAU-MIB. It is intended that each new MAU type, Media Availability state, Auto Negotiation capability and/or Jack type defined by the IEEE 802.3 working group and approved for publication in a revision of IEEE Std 802.3 will be added to this MIB module, provided that it is suitable for being managed by the base objects in the MAU-MIB. An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for such additions. The following reference is used throughout this MIB module: [IEEE802.3] refers to: IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications'. This reference should be updated as appropriate when new MAU types, Media Availability states, Auto Negotiation capabilities, and/or Jack types are added to this MIB module. Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC 4836; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html" REVISION "200704210000Z" -- April 21, 2007 DESCRIPTION "Initial version of this MIB as published in RFC 4836." ::= { mib-2 154 } -- Textual Conventions IANAifMauTypeListBits ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauTypeListBits object in the (updated) definition of MAU-MIB's ifMauTable. Beili Standards Track [Page 47] RFC 4836 MAU MIB April 2007 The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana@iana.org). Note that changes in this textual convention SHALL be synchronized with relevant changes in the dot3MauType OBJECT-IDENTITIES." REFERENCE "[IEEE802.3], Section 30.5.1.1.2" SYNTAX BITS { bOther(0), -- other or unknown bAUI(1), -- AUI b10base5(2), -- 10BASE-5 bFoirl(3), -- FOIRL b10base2(4), -- 10BASE-2 b10baseT(5), -- 10BASE-T duplex mode unknown b10baseFP(6), -- 10BASE-FP b10baseFB(7), -- 10BASE-FB b10baseFL(8), -- 10BASE-FL duplex mode unknown b10broad36(9), -- 10BROAD36 b10baseTHD(10), -- 10BASE-T half duplex mode b10baseTFD(11), -- 10BASE-T full duplex mode b10baseFLHD(12), -- 10BASE-FL half duplex mode b10baseFLFD(13), -- 10BASE-FL full duplex mode b100baseT4(14), -- 100BASE-T4 b100baseTXHD(15), -- 100BASE-TX half duplex mode b100baseTXFD(16), -- 100BASE-TX full duplex mode b100baseFXHD(17), -- 100BASE-FX half duplex mode b100baseFXFD(18), -- 100BASE-FX full duplex mode b100baseT2HD(19), -- 100BASE-T2 half duplex mode b100baseT2FD(20), -- 100BASE-T2 full duplex mode b1000baseXHD(21), -- 1000BASE-X half duplex mode b1000baseXFD(22), -- 1000BASE-X full duplex mode b1000baseLXHD(23), -- 1000BASE-LX half duplex mode b1000baseLXFD(24), -- 1000BASE-LX full duplex mode b1000baseSXHD(25), -- 1000BASE-SX half duplex mode b1000baseSXFD(26), -- 1000BASE-SX full duplex mode b1000baseCXHD(27), -- 1000BASE-CX half duplex mode b1000baseCXFD(28), -- 1000BASE-CX full duplex mode b1000baseTHD(29), -- 1000BASE-T half duplex mode b1000baseTFD(30), -- 1000BASE-T full duplex mode b10GbaseX(31), -- 10GBASE-X b10GbaseLX4(32), -- 10GBASE-LX4 Beili Standards Track [Page 48] RFC 4836 MAU MIB April 2007 b10GbaseR(33), -- 10GBASE-R b10GbaseER(34), -- 10GBASE-ER b10GbaseLR(35), -- 10GBASE-LR b10GbaseSR(36), -- 10GBASE-SR b10GbaseW(37), -- 10GBASE-W b10GbaseEW(38), -- 10GBASE-EW b10GbaseLW(39), -- 10GBASE-LW b10GbaseSW(40), -- 10GBASE-SW -- new since RFC 3636 b10GbaseCX4(41), -- 10GBASE-CX4 b2BaseTL(42), -- 2BASE-TL b10PassTS(43), -- 10PASS-TS b100BaseBX10D(44), -- 100BASE-BX10D b100BaseBX10U(45), -- 100BASE-BX10U b100BaseLX10(46), -- 100BASE-LX10 b1000BaseBX10D(47), -- 1000BASE-BX10D b1000BaseBX10U(48), -- 1000BASE-BX10U b1000BaseLX10(49), -- 1000BASE-LX10 b1000BasePX10D(50), -- 1000BASE-PX10D b1000BasePX10U(51), -- 1000BASE-PX10U b1000BasePX20D(52), -- 1000BASE-PX20D b1000BasePX20U(53) -- 1000BASE-PX20U } IANAifMauMediaAvailable ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauMediaAvailable and rpMauMediaAvailable objects in the (updated) definition of MAU-MIB's ifMauTable and rpMauTable respectively. Possible values are: other(1) - undefined (not listed below) unknown(2) - MAU's true state is unknown; e.g., during initialization available(3) - link, light, or loopback is normal notAvailable(4) - link loss, low light, or no loopback remoteFault(5) - a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation invalidSignal(6) - invalid signal has been received from the other end of the link, 10BASE-FB only remoteJabber(7) - remote fault, due to jabber Beili Standards Track [Page 49] RFC 4836 MAU MIB April 2007 remoteLinkLoss(8) - remote fault, due to link loss remoteTest(9) - remote fault, due to test offline(10) - offline, Clause 37 Auto-Negotiation only autoNegError(11) - Auto-Negotiation Error, Clause 37 Auto-Negotiation only pmdLinkFault(12) - PMA/PMD receive link fault. In case of PAF (2BASE-TL / 10PASS-TS PHYs), all PMEs in the aggregation group have detected a link fault wisFrameLoss(13) - WIS loss of frame, 10GBASE-W only wisSignalLoss(14) - WIS loss of signal, 10GBASE-W only pcsLinkFault(15) - PCS receive link fault excessiveBER(16) - PCS Bit Error Ratio monitor reporting excessive error ratio dxsLinkFault(17) - DTE XGXS receive link fault, XAUI only pxsLinkFault(18) - PHY XGXS receive link fault, XAUI only availableReduced(19) - link normal, reduced bandwidth, 2BASE-TL / 10PASS-TS only ready(20) - at least one PME in the aggregation group is detecting handshake tones, 2BASE-TL / 10PASS-TS only If the MAU is a 10M b/s link or fiber type (FOIRL, 10BASE-T, 10BASE-F), then this is equivalent to the link test fail state/low light function. For an AUI, 10BASE2, 10BASE5, or 10BROAD36 MAU, this indicates whether loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASEFP. At power-up or following a reset, the Media Available state will be unknown(2) for AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission, then loopback will be detected. The Media Available state will only change during noncollided transmissions for AUI, 10BASE2, 10BASE5, 10BROAD36, and 10BASE-FP MAUs. For 100BASE-T2, 100BASE-T4, 100BASE-TX, 100BASE-FX, 100BASE-LX10, and 100BASE-BX10 PHYs the enumerations match the states within the link integrity state diagram. Any MAU that implements management of [IEEE802.3] Clause 28 Auto-Negotiation, will map remote fault indication to remoteFault(5). Beili Standards Track [Page 50] RFC 4836 MAU MIB April 2007 Any MAU that implements management of Clause 37 Auto-Negotiation, will map the received RF1 and RF2 bits as follows: Offline maps to offline(10), Link_Failure maps to remoteFault(5), and Auto-Negotiation Error maps to autoNegError(11). The value remoteFault(5) applies to 10BASE-FB remote fault indication, the 100BASE-X far-end fault indication, and nonspecified remote faults from a system running Clause 28 Auto-Negotiation. The value remoteJabber(7), remoteLink loss(8), or remoteTest(9) SHOULD be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. Where a Clause 22 MII or Clause 35 GMII is present, a logic one in the remote fault bit maps to the value remoteFault(5), a logic zero in the link status bit maps to the enumeration notAvailable(4). The value notAvailable(4) takes precedence over remoteFault(5). For 2BASE-TL and 10PASS-TS PHYs, the value unknown(2) maps to the condition where the PHY (PCS with connected PMEs) is initializing, the value ready(20) maps to the condition where the interface is down and at least one PME in the aggregation group is ready for handshake, the value available(3) maps to the condition where all the PMEs in the aggregation group are up, the value notAvailable(4) maps to the condition where all the PMEs in the aggregation group are down and no handshake tones are detected, the value availableReduced(19) maps to the condition where the interface is up, a link fault is detected at the receive direction by one or more PMEs in the aggregation group, but at least one PME is up and the enumeration pmdLinkFault(12) maps to the condition where a link fault is detected at the receive direction by all of the PMEs in the aggregation group. For 10 Gb/s the enumerations map to value of the link_fault variable within the Link Fault Signaling state diagram as follows: the value OK maps to the value available(3), the value Local Fault maps to the value notAvailable(4), and the value Remote Fault maps to the value remoteFault(5). The value pmdLinkFault(12), wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), excessiveBER(16), or dxsLinkFault(17) SHOULD be used instead of the value notAvailable(4), where the reason for the Local Fault state can be identified through the use of the Clause 45 MDIO Interface. Where multiple reasons for the Local Fault state can be identified, only the highest precedence error SHOULD be Beili Standards Track [Page 51] RFC 4836 MAU MIB April 2007 reported. This precedence in descending order is as follows: pxsLinkFault pmdLinkFault wisFrameLoss wisSignalLoss pcsLinkFault excessiveBER dxsLinkFault. Where a Clause 45 MDIO interface is present a logic zero in the PMA/PMD Receive link status bit ([IEEE802.3] Section 45.2.1.2.2) maps to the value pmdLinkFault(12), logic one in the LOF status bit (Section 45.2.2.10.4) maps to the value wisFrameLoss(13), a logic one in the LOS status bit (Section 45.2.2.10.5) maps to the value wisSignalLoss, a logic zero in the PCS Receive link status bit (Section 45.2.3.2.2) maps to the value pcsLinkFault(15), a logic one in the 10GBASE-R PCS Latched high BER status bit (Section 45.2.3.12.2) maps to the value excessiveBER, a logic zero in the DTE XS receive link status bit (Section 45.2.5.2.2) maps to the value dxsLinkFault(17) and a logic zero in the PHY XS transmit link status bit (Section 45.2.4.2.2) maps to the value pxsLinkFault(18). The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana@iana.org)." REFERENCE "[IEEE802.3], Section 30.5.1.1.4" SYNTAX INTEGER { other(1), unknown(2), available(3), notAvailable(4), remoteFault(5), invalidSignal(6), remoteJabber(7), remoteLinkLoss(8), remoteTest(9), offline(10), autoNegError(11), pmdLinkFault(12), wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), Beili Standards Track [Page 52] RFC 4836 MAU MIB April 2007 excessiveBER(16), dxsLinkFault(17), pxsLinkFault(18), availableReduced(19), ready(20) } IANAifMauAutoNegCapBits ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits, and ifMauAutoNegCapReceivedBits objects in the (updated) definition of MAU-MIB's ifMauAutoNegTable. The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana@iana.org)." REFERENCE "[IEEE802.3], Section 30.6.1.1.5" SYNTAX BITS { bOther(0), -- other or unknown b10baseT(1), -- 10BASE-T half duplex mode b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 b100baseTX(4), -- 100BASE-TX half duplex mode b100baseTXFD(5), -- 100BASE-TX full duplex mode b100baseT2(6), -- 100BASE-T2 half duplex mode b100baseT2FD(7), -- 100BASE-T2 full duplex mode bFdxPause(8), -- PAUSE for full-duplex links bFdxAPause(9), -- Asymmetric PAUSE for full-duplex -- links bFdxSPause(10), -- Symmetric PAUSE for full-duplex -- links bFdxBPause(11), -- Asymmetric and Symmetric PAUSE for -- full-duplex links b1000baseX(12), -- 1000BASE-X, -LX, -SX, -CX half -- duplex mode b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full -- duplex mode b1000baseT(14), -- 1000BASE-T half duplex mode b1000baseTFD(15) -- 1000BASE-T full duplex mode } IANAifJackType ::= TEXTUAL-CONVENTION STATUS current Beili Standards Track [Page 53] RFC 4836 MAU MIB April 2007 DESCRIPTION "Common enumeration values for repeater and interface MAU jack types. This data type is used as the syntax of the ifJackType and rpJackType objects in the (updated) definition of MAU-MIB's ifJackTable and rpJackTable respectively. Possible values are: other(1) - undefined or unknown rj45(2) - RJ45 rj45S(3) - RJ45 shielded db9(4) - DB9 bnc(5) - BNC fAUI(6) - AUI female mAUI(7) - AUI male fiberSC(8) - SC fiber fiberMIC(9) - MIC fiber fiberST(10) - ST fiber telco(11) - Telco mtrj(12) - MT-RJ fiber hssdc(13) - fiber channel style-2 fiberLC(14) - LC fiber cx4(15) - IB4X for 10GBASE-CX4 The most recent version of this textual convention is available in the online version of this MIB module on the IANA web site. Requests for new values should be made to IANA via email (iana@iana.org)." SYNTAX INTEGER { other(1), rj45(2), rj45S(3), db9(4), bnc(5), fAUI(6), mAUI(7), fiberSC(8), fiberMIC(9), fiberST(10), telco(11), mtrj(12), hssdc(13), fiberLC(14), -- new since RFC 3636 cx4(15) } -- OBJECT IDENTITIES for MAU types Beili Standards Track [Page 54] RFC 4836 MAU MIB April 2007 -- (see rpMauType and ifMauType of MAU-MIB for usage) -- The following definitions has been moved from RFC 3636 and -- no longer appear in its revision. dot3MauType OBJECT IDENTIFIER ::= { mib-2 snmpDot3MauMgt(26) 4 } dot3MauTypeAUI OBJECT-IDENTITY STATUS current DESCRIPTION "no internal MAU, view from AUI" REFERENCE "[IEEE802.3], Section 7" ::= { dot3MauType 1 } dot3MauType10Base5 OBJECT-IDENTITY STATUS current DESCRIPTION "thick coax MAU" REFERENCE "[IEEE802.3], Section 7" ::= { dot3MauType 2 } dot3MauTypeFoirl OBJECT-IDENTITY STATUS current DESCRIPTION "FOIRL MAU" REFERENCE "[IEEE802.3], Section 9.9" ::= { dot3MauType 3 } dot3MauType10Base2 OBJECT-IDENTITY STATUS current DESCRIPTION "thin coax MAU" REFERENCE "[IEEE802.3], Section 10" ::= { dot3MauType 4 } dot3MauType10BaseT OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU. Note that it is strongly recommended that agents return either dot3MauType10BaseTHD or dot3MauType10BaseTFD if the duplex mode is known. However, management applications should be prepared to receive this MAU type value from older agent implementations." REFERENCE "[IEEE802.3], Section 14" ::= { dot3MauType 5 } dot3MauType10BaseFP OBJECT-IDENTITY STATUS current DESCRIPTION "passive fiber MAU" REFERENCE "[IEEE802.3], Section 16" ::= { dot3MauType 6 } Beili Standards Track [Page 55] RFC 4836 MAU MIB April 2007 dot3MauType10BaseFB OBJECT-IDENTITY STATUS current DESCRIPTION "sync fiber MAU" REFERENCE "[IEEE802.3], Section 17" ::= { dot3MauType 7 } dot3MauType10BaseFL OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU. Note that it is strongly recommended that agents return either dot3MauType10BaseFLHD or dot3MauType10BaseFLFD if the duplex mode is known. However, management applications should be prepared to receive this MAU type value from older agent implementations." REFERENCE "[IEEE802.3], Section 18" ::= { dot3MauType 8 } dot3MauType10Broad36 OBJECT-IDENTITY STATUS current DESCRIPTION "broadband DTE MAU. Note that 10BROAD36 MAUs can be attached to interfaces but not to repeaters." REFERENCE "[IEEE802.3], Section 11" ::= { dot3MauType 9 } ------ new since RFC 1515: dot3MauType10BaseTHD OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU, half duplex mode" REFERENCE "[IEEE802.3], Section 14" ::= { dot3MauType 10 } dot3MauType10BaseTFD OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU, full duplex mode" REFERENCE "[IEEE802.3], Section 14" ::= { dot3MauType 11 } dot3MauType10BaseFLHD OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU, half duplex mode" REFERENCE "[IEEE802.3], Section 18" ::= { dot3MauType 12 } dot3MauType10BaseFLFD OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU, full duplex mode" Beili Standards Track [Page 56] RFC 4836 MAU MIB April 2007 REFERENCE "[IEEE802.3], Section 18" ::= { dot3MauType 13 } dot3MauType100BaseT4 OBJECT-IDENTITY STATUS current DESCRIPTION "4 pair category 3 UTP" REFERENCE "[IEEE802.3], Section 23" ::= { dot3MauType 14 } dot3MauType100BaseTXHD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 5 UTP, half duplex mode" REFERENCE "[IEEE802.3], Section 25" ::= { dot3MauType 15 } dot3MauType100BaseTXFD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 5 UTP, full duplex mode" REFERENCE "[IEEE802.3], Section 25" ::= { dot3MauType 16 } dot3MauType100BaseFXHD OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over PMT, half duplex mode" REFERENCE "[IEEE802.3], Section 26" ::= { dot3MauType 17 } dot3MauType100BaseFXFD OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over PMT, full duplex mode" REFERENCE "[IEEE802.3], Section 26" ::= { dot3MauType 18 } dot3MauType100BaseT2HD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 3 UTP, half duplex mode" REFERENCE "[IEEE802.3], Section 32" ::= { dot3MauType 19 } dot3MauType100BaseT2FD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 3 UTP, full duplex mode" REFERENCE "[IEEE802.3], Section 32" ::= { dot3MauType 20 } ------ new since RFC 2239: dot3MauType1000BaseXHD OBJECT-IDENTITY STATUS current Beili Standards Track [Page 57] RFC 4836 MAU MIB April 2007 DESCRIPTION "PCS/PMA, unknown PMD, half duplex mode" REFERENCE "[IEEE802.3], Section 36" ::= { dot3MauType 21 } dot3MauType1000BaseXFD OBJECT-IDENTITY STATUS current DESCRIPTION "PCS/PMA, unknown PMD, full duplex mode" REFERENCE "[IEEE802.3], Section 36" ::= { dot3MauType 22 } dot3MauType1000BaseLXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over long-wavelength laser, half duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 23 } dot3MauType1000BaseLXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over long-wavelength laser, full duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 24 } dot3MauType1000BaseSXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over short-wavelength laser, half duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 25 } dot3MauType1000BaseSXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over short-wavelength laser, full duplex mode" REFERENCE "[IEEE802.3], Section 38" ::= { dot3MauType 26 } dot3MauType1000BaseCXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Copper over 150-Ohm balanced cable, half duplex mode" REFERENCE "[IEEE802.3], Section 39" ::= { dot3MauType 27 } dot3MauType1000BaseCXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Copper over 150-Ohm balanced cable, full Beili Standards Track [Page 58] RFC 4836 MAU MIB April 2007 duplex mode" REFERENCE "[IEEE802.3], Section 39" ::= { dot3MauType 28 } dot3MauType1000BaseTHD OBJECT-IDENTITY STATUS current DESCRIPTION "Four-pair Category 5 UTP, half duplex mode" REFERENCE "[IEEE802.3], Section 40" ::= { dot3MauType 29 } dot3MauType1000BaseTFD OBJECT-IDENTITY STATUS current DESCRIPTION "Four-pair Category 5 UTP, full duplex mode" REFERENCE "[IEEE802.3], Section 40" ::= { dot3MauType 30 } ------ new since RFC 2668: dot3MauType10GigBaseX OBJECT-IDENTITY STATUS current DESCRIPTION "X PCS/PMA, unknown PMD." REFERENCE "[IEEE802.3], Section 48" ::= { dot3MauType 31 } dot3MauType10GigBaseLX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over WWDM optics" REFERENCE "[IEEE802.3], Section 53" ::= { dot3MauType 32 } dot3MauType10GigBaseR OBJECT-IDENTITY STATUS current DESCRIPTION "R PCS/PMA, unknown PMD." REFERENCE "[IEEE802.3], Section 49" ::= { dot3MauType 33 } dot3MauType10GigBaseER OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 1550 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 34 } dot3MauType10GigBaseLR OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 1310 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 35 } dot3MauType10GigBaseSR OBJECT-IDENTITY Beili Standards Track [Page 59] RFC 4836 MAU MIB April 2007 STATUS current DESCRIPTION "R fiber over 850 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 36 } dot3MauType10GigBaseW OBJECT-IDENTITY STATUS current DESCRIPTION "W PCS/PMA, unknown PMD." REFERENCE "[IEEE802.3], Section 49 and 50" ::= { dot3MauType 37 } dot3MauType10GigBaseEW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 1550 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 38 } dot3MauType10GigBaseLW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 1310 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 39 } dot3MauType10GigBaseSW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 850 nm optics" REFERENCE "[IEEE802.3], Section 52" ::= { dot3MauType 40 } ------ new since RFC 3636: dot3MauType10GigBaseCX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X copper over 8 pair 100-Ohm balanced cable" REFERENCE "[IEEE802.3], Section 54" ::= { dot3MauType 41 } dot3MauType2BaseTL OBJECT-IDENTITY STATUS current DESCRIPTION "Voice grade UTP copper, up to 2700m, optional PAF" REFERENCE "[IEEE802.3], Sections 61 and 63" ::= { dot3MauType 42 } dot3MauType10PassTS OBJECT-IDENTITY STATUS current DESCRIPTION "Voice grade UTP copper, up to 750m, optional PAF" REFERENCE "[IEEE802.3], Sections 61 and 62" ::= { dot3MauType 43 } Beili Standards Track [Page 60] RFC 4836 MAU MIB April 2007 dot3MauType100BaseBX10D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber OLT, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 58" ::= { dot3MauType 44 } dot3MauType100BaseBX10U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber ONU, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 58" ::= { dot3MauType 45 } dot3MauType100BaseLX10 OBJECT-IDENTITY STATUS current DESCRIPTION "Two single-mode fibers, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 58" ::= { dot3MauType 46 } dot3MauType1000BaseBX10D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber OLT, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 59" ::= { dot3MauType 47 } dot3MauType1000BaseBX10U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber ONU, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 59" ::= { dot3MauType 48 } dot3MauType1000BaseLX10 OBJECT-IDENTITY STATUS current DESCRIPTION "Two sigle-mode fiber, long wavelength, 10km" REFERENCE "[IEEE802.3], Section 59" ::= { dot3MauType 49 } dot3MauType1000BasePX10D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON OLT, 10km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 50 } dot3MauType1000BasePX10U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON ONU, 10km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 51 } Beili Standards Track [Page 61] RFC 4836 MAU MIB April 2007 dot3MauType1000BasePX20D OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON OLT, 20km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 52 } dot3MauType1000BasePX20U OBJECT-IDENTITY STATUS current DESCRIPTION "One single-mode fiber EPON ONU, 20km" REFERENCE "[IEEE802.3], Section 60" ::= { dot3MauType 53 } END 6. Security Considerations The IANA-MAU-MIB does not define any management objects. Instead, it defines a set of textual conventions which are used by the MAU-MIB and may be used by other MIB modules to define management objects. Meaningful security considerations can only be written for MIB modules that define management objects. There are a number of management objects defined in the MAU-MIB that have a MAX-ACCESS clause of read-write. Setting these objects can have a serious effect on the operation of the network, including: o enabling or disabling a MAU o changing a MAU's default type o enabling, disabling, or restarting autonegotiation o modifying the capabilities that a MAU advertizes during autonegotiation. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in the MAU-MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. In some environments, it may be undesirable to allow unauthorized parties to access statistics or status information about individual links in a network. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Beili Standards Track [Page 62] RFC 4836 MAU MIB April 2007 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in the MAU-MIB module. It is RECOMMENDED that the implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of the MAU-MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations This document defines first version of the IANA-maintained IANA-MAU- MIB module. It is intended that each new MAU type, Media Available state, Auto Negotiation capability, and/or Jack type defined by the IEEE 802.3 working group and approved for publication in a revision of IEEE Std 802.3 will be added to the IANA-maintaned MIB module, provided that it is suitable for being managed by the base objects in the MAU-MIB module. For each new MAU type added, a short description of the MAU technology and, wherever possible, a reference to a publicly available specification SHOULD be specified. An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED, for each modification. 8. Acknowledgments This document was produced by the IETF Ethernet Interfaces and Hub MIB Working Group, whose efforts were greatly advanced by the contributions of the following people: Mike Heard John Flick Dan Romascanu This document is based on the Proposed Standard MAU MIB, RFC 3636 [RFC3636], edited by John Flick of Hewlett-Packard, and produced by Beili Standards Track [Page 63] RFC 4836 MAU MIB April 2007 the Ethernet Interfaces and Hub MIB Working Group. It extends that document by moving the object identities and textual conventions for MAU types into a IANA-maintained MIB module. In addition, support is provided for the EFM and 10GBASE-CX4 MAUs as defined in [IEEE802.3ah] and [IEEE802.3ak] respectively. RFC 3636, in turn, was based on the Proposed Standard MAU MIB, RFC 2668 [RFC2668], edited by John Flick of Hewlett-Packard and Andrew Smith, then of Extreme Networks, and produced by the Ethernet Interfaces and Hub MIB Working Group. It extends that document by providing support for 10 Gb/s MAUs as defined in [IEEE802.3ae]. RFC 2668, in turn, was based on the Proposed Standard MAU MIB, RFC 2239 [RFC2239], edited by Kathryn de Graaf, then of 3Com, and Dan Romascanu, then of Madge Networks, and produced by the Ethernet Interfaces and Hub MIB Working Group. It extended that document by providing support for 1000 Mb/sec MAUs, PAUSE negotiation and remote fault status as defined in [IEEE802.3]. RFC 2239, in turn, was based on the Proposed Standard MAU MIB, RFC 1515 [RFC1515], edited by Donna McMaster, then of SynOptics Communications, Keith McCloghrie, then of Hughes LAN Systems, and Sam Roberts, then of Farallon Computing, and produced by the Hub MIB Working Group. It extends that document by providing support for 100 Mb/sec MAUs, full duplex MAUs, auto-negotiation, and jack management as defined in [IEEE802.3]. 9. References 9.1. Normative References [IEEE802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3-2005, December 2005. [IEEE802.3ae] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control (MAC) Parameters, Physical Layer and Management Parameters for 10 Gb/s Operation", IEEE Std 802.3ae-2002, August 2002. Beili Standards Track [Page 64] RFC 4836 MAU MIB April 2007 [IEEE802.3ah] IEEE, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks", IEEE Std 802.3ah-2004, September 2004. [IEEE802.3ak] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Physical Layer and Management Parameters for 10Gb/s Operation, Type 10GBASE-CX4", IEEE Std 802.3ak-2004, March 2004. [RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Beili Standards Track [Page 65] RFC 4836 MAU MIB April 2007 [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003. 9.2. Informative References [RFC1515] McMaster, D., McCloghrie, K., and S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 1515, September 1993. [RFC2239] de Graaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2", RFC 2239, November 1997. [RFC2668] Smith, A., Flick, J., de Graaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 2668, August 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 3636, September 2003. [RFC3637] Heard, C., "Definitions of Managed Objects for the Ethernet WAN Interface Sublayer", RFC 3637, September 2003. Author's Address Edward Beili Actelis Networks Bazel 25 Petach-Tikva Israel Phone: +972-3-924-3491 EMail: edward.beili@actelis.com Beili Standards Track [Page 66] RFC 4836 MAU MIB April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beili Standards Track [Page 67] snmp-mibs-downloader-1.1/mibrfcs/rfc4837.txt0000644000000000000000000062360611402176072015605 0ustar Network Working Group L. Khermosh Request for Comments: 4837 PMC-SIERRA Category: Standards Track July 2007 Managed Objects of Ethernet Passive Optical Networks (EPON) 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. Khermosh Standards Track [Page 1] RFC 4837 Managed Objects of EPON July 2007 Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology and Abbreviations . . . . . . . . . . . . . . 3 2.2. EPON Architecture Highlights . . . . . . . . . . . . . . . 5 2.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Principles of Operation . . . . . . . . . . . . . . . 6 2.2.3. The Physical Media . . . . . . . . . . . . . . . . . . 7 2.2.4. PMD Specifications . . . . . . . . . . . . . . . . . . 8 2.2.5. Point-to-Point Emulation . . . . . . . . . . . . . . . 8 2.2.6. Principles of the MPCP . . . . . . . . . . . . . . . . 10 2.2.7. Forward Error Correction (FEC) . . . . . . . . . . . . 12 2.3. Management Architecture . . . . . . . . . . . . . . . . . 13 3. MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Relation to Other MIB Modules . . . . . . . . . . . . . . . . 22 4.1. Relation to the Interfaces MIB and Ethernet-like Interfaces MIB . . . . . . . . . . . . . . . . . . . . . . 22 4.2. Relation to the IEEE 802.3 MAU MIBs . . . . . . . . . . . 29 4.3. Relation to the EFM OAM MIB . . . . . . . . . . . . . . . 29 4.4. Relation to the Bridge MIB . . . . . . . . . . . . . . . . 30 5. Mapping of IEEE 802.3ah Managed Objects . . . . . . . . . . . 31 6. Definitions - The DOT3 EPON MIB Module . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 90 Khermosh Standards Track [Page 2] RFC 4837 Managed Objects of EPON July 2007 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578]; STD 58, RFC 2579 [RFC2579]; and STD 58, RFC 2580 [RFC2580]. 2. Overview This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in [802.3ah], which are extended capabilities to the Ethernet like interfaces. The document contains a list of management objects based on the attributes defined in the relevant parts of [802.3ah] Annex 30A, referring to EPON. 2.1. Terminology and Abbreviations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. ACK - Acknowledge BER - Bit Error Rate BW - Bandwidth CO - Central Office CPE - Customer Premises Equipment CRC - Cyclic Redundancy Check EFM - Ethernet First Mile EPON - Ethernet Passive Optical Network FCS - Frame Check Sequence Khermosh Standards Track [Page 3] RFC 4837 Managed Objects of EPON July 2007 FEC - Forward Error Correction GMII - Gigabit Media Independent Interface LAN - Local Area Network LLID - Logical Link Identifier MAC - Media Access Control Mbps - Megabit per second MDI - Medium Dependent Interface MDIO - Management Data Input/Output MPCP - Multi-Point Control Protocol MP2PE - Multi-Point to Point Emulation OAM - Operation Administration Maintenance OLT - Optical Line Terminal (Server unit of the EPON) OMP - Optical Multi-Point ONU - Optical Network Unit (Client unit of the EPON) P2MP - Point-to-Multipoint P2PE - Point-to-Point Emulation PCS - Physical Coding Sublayer PHY - Physical Layer PMA - Physical Medium Attachment PMD - Physical Medium Dependent PON - Passive Optical Network RS - Reconciliation Sublayer RTT - Round Trip Time SLA - Service Level Agreement Khermosh Standards Track [Page 4] RFC 4837 Managed Objects of EPON July 2007 SLD - Start of LLID Delimiter TDM - Time Division Multiplexing TQ - Time Quanta 2.2. EPON Architecture Highlights 2.2.1. Introduction The EPON standard, as defined in [802.3ah], defines the physical media (Layer 1) and media access (Layer 2) of the EPON interface. The EPON is a variant of the Gigabit Ethernet protocol for the Optical Access. The Optical Access topology is based on passive optical splitting topology. The link of a Passive Optical Network (PON) is based on a single, shared optical fiber with passive optical splitters dividing the single fiber into separate subscribers. The Optical Line Terminal (OLT) is the server unit of the network, located at the Central Office (CO). The Optical Network Unit (ONU) is the client unit of the network, located at the Customer Premises Equipment (CPE). The following diagram describes the PON topology: Device with one or more P2MP interfaces such as OLT for EPON An EPON IP host ------- OLT ONU "modem" -------- Other IEEE | | interface | interface ------ Other IEEE| | interface | |-------\----------------| | interface | | ===========| | \ | |===========| | | | \ ------ -------- | | \ ------ -------- . . \------------| | | | | |------\ | |===========| | | | \ ------ -------- ------- \ etc Khermosh Standards Track [Page 5] RFC 4837 Managed Objects of EPON July 2007 The IEEE layering architecture of an EPON interface is defined in the diagram of Figure 56.2 [802.3ah]. The following clauses in the [802.3ah] define the corresponding layers of an EPON interface: clause 30 - Management clause 60 - PMD for EPON media (Burst PMD) clause 64 - MPCP (Multi-Point Control Protocol) - defines the Multi- Point architecture, and control protocol for the media access of EPON. clause 65 - a) Virtual links definition for the EPON b) FEC c) PMA for the EPON. 2.2.2. Principles of Operation The specification of the EPON interface is based on the specification of the gigabit Ethernet interface as described in [802.3], clauses 35 and 36. The Ethernet MAC is working in gigabit rate. The media interface to the MAC is through the GMII interface, as described in clause 35, and the PCS layer is based on the gigabit Ethernet PCS as described in clause 36. The special EPON layers are added to the Ethernet layering in the following places: The MPCP is placed in the MAC control layer, providing the EPON control protocol. The Emulation layer, located at the RS (Reconciliation Sublayer), creates virtual private path to each ONU. The FEC layer is located between the PCS and PMA layers, enhancing reach and split performance of the optical link. Khermosh Standards Track [Page 6] RFC 4837 Managed Objects of EPON July 2007 The following diagram describes the layering model of an EPON interface: +==========================================+ | Higher layers | +==========================================+ | 802.1D Bridge | +==========================================+ | MAC client| ... |MAC client| +==========================================+ | MAC Control - (MPCP) | *NEW* +==========================================+ | MAC | ... | MAC | +==========================================+ | P2P Emulation (P2PE) | *NEW* +==========================================+ | | | GMII | | | +==========================================+ | PCS | +==========================================+ | FEC | *NEW* +==========================================+ | PMA | *Enhanced parameters +==========================================+ for EPON* | PMD | *Enhanced parameters +==========================================+ for EPON* | | | MDI | | | /===================/ / Media / /===================/ 2.2.3. The Physical Media The physical link is a fiber optical link. The OLT and ONUs are connected through passive optical splitters. Downlink denotes the transmission from the OLT to the ONUs. Uplink denotes the transmission from the ONUs to the OLT. Uplink and downlink are multiplexed using separated wavelengths on the same fiber. The downlink is a broadcast medium where the OLT transmits the data to all ONUs. The uplink is a shared transmission medium for all of the ONUs. The uplink access is based on time division multiplexing (TDM) and the management of the TDM media access is defined by the Multi- Khermosh Standards Track [Page 7] RFC 4837 Managed Objects of EPON July 2007 Point Control Protocol (MPCP). The MPCP is a control protocol based on an inband packet messaging. The OLT sends control messages (GATE messages) allowing ONUs to transmit, defining when the transmission occurs and what is its duration. These messages define the transmission order and the amount of BW for each ONU. A scheduling algorithm at the OLT, which is not defined in the [802.3ah], is responsible for allocating the BW and controlling the delay of each ONU according to its SLA. 2.2.4. PMD Specifications PMD specifications select the same optical wavelength plan as the [ITU-T.G.983]. The transceivers are derivatives of existing Ethernet optical transceivers, with dual wavelength on a single fiber, and extended burst capabilities for the uplink. The uplink burst capability is the burst transmission functionality for the ONUs and burst reception functionality for the OLT. The [802.3ah] selected very relaxed burst parameters to reduce the device cost of EPON products. 2.2.5. Point-to-Point Emulation The downstream is a broadcast link, which means that the OLT transmission is shared for all ONUs. The sharing of the transmission of the OLT has some negative privacy aspects and should be limited to broadcast traffic in nature only. The traffic dedicated to each ONU should not be shared. The solution provided by [802.3ah] is to partition the EPON link, in a virtual manner, between the ONUs. Each ONU has a dedicated virtual link to the OLT. The [802.3ah] also defines an additional link for broadcast transmission. The medium becomes an aggregation of point-to-point tunnels. The OLT cannot preserve its EPON interface as a single interface connected to N devices (following the properties of the physical interface). The EPON interface of the OLT is partitioned into separate virtual interfaces; an interface for each virtual link. Hence, the OLT behaves like a device with N virtual ports (and an additional port for the broadcast transmission). The additional single-copy- broadcast channel (tagged as all one LLID) is added to allow the broadcast transmission within a single copy to all ONUs, preserving the inherent advantage of BW efficiency of the PON shared media. The ONUs filter the downlink traffic that is not intended for their reception, according to the virtual link marking. An LLID tag is attached at the preamble of the Ethernet packet denoting the virtual link. The LLID marks the destination port in the downstream and source port in the upstream. Khermosh Standards Track [Page 8] RFC 4837 Managed Objects of EPON July 2007 The virtual links concept is also used to avoid a violation of the [802.1d] bridging rules for peer-to-peer traffic in the PON. Peer- to-peer traffic is traffic between ONUs in the same PON. The OLT cannot preserve the EPON interface as a single interface, connected to N devices, and allow traffic between these devices without violating the bridging rules. The source address and destination address of the peer-to-peer traffic are behind the same port and therefore the traffic should be discarded. The separation of the ONUs into virtual links solves this issue. The OLT has N virtual ports for the single physical EPON port. A bridge sees a single MAC Client for every link pair. The private paths concept solves the networking problems and provides subscriber isolation. As the tunneling is only a virtual tunneling, there is a single physical interface and a single physical layer for the device so that some attributes are shared. For example, the interface has a single local MAC address. The virtual tunneling for an OLT with 3 ONUs is illustrated in the following diagram. Khermosh Standards Track [Page 9] RFC 4837 Managed Objects of EPON July 2007 Trunk Line | | | \|/ +===============================================+ | 802.1D Bridge | +===============================================+ | MAC client1| ... |MAC client3| +===============================================+ | MP2PE | +===============================================+ | PHY | ================================================= | | | | | | \|/ \|/ \|/ +============+ +============+ +============+ | PHY | | PHY | | PHY | +============+ +============+ +============+ | MP2PE | | MP2PE | | MP2PE | +============+ +============+ +============+ | MAC client | | MAC client | | MAC client | +============+ +============+ +============+ | PHY | | PHY | | PHY | +============+ +============+ +============+ /|\ /|\ /|\ | | | | | | | | | Subscriber1 Subscriber2 Subscriber3 2.2.6. Principles of the MPCP The EPON standard defines a media access control of an optical Access network. The Access network has some substantial differences from the legacy LAN for which the Ethernet was designed. The differences lie mainly in the provisioning of the network. An Access network is an administrated environment, with an operator providing the service and subscribers consuming it. The operator is controlling the network and managing its traffic. For instance, BW is controlled and subscribers are billed for services. The MPCP protocol divides the Ethernet interfaces into two unequal types of network units. The first interface is an OLT interface, which is a server unit, controlling the network. The second interface is an ONU interface, which is a client unit, participating in the network. Khermosh Standards Track [Page 10] RFC 4837 Managed Objects of EPON July 2007 The OLT, which is the server unit, manages the network. The MPCP controls the TDM transmission of the uplink. The MPCP is implemented at the MAC control layer and the MPCP messages are MAC control messages using the 0x8808 Ethertype. These messages are not forwarded out of the MAC. A concept of time must exist in the protocol in order to schedule the uplink transmission. A timestamp, which is set by the OLT and synchronized between the network units, is passed through the MPCP messages. The timestamp is also used to measure the RTT of each ONU. RTT is compensated by the OLT in the generation of the grants for the uplink transmission. The difference of incoming timestamp to local time allows the OLT to calculate the RTT. RTT compensation is needed as the RTT in an Access network can have a significant value. The standard allows the network to reach a 20 km distance, which is equivalent to a 200 usec RTT (25 Kbytes of data). The TDM control is done using GATE messages. These messages define, for each ONU, the time for transmission and the length of transmission. The RTT is reduced from the transmission time in the GATE message to shift the transmission time of the ONU in the opposite direction. A scheduling algorithm at the OLT, which is not defined in the [802.3ah], is responsible for dividing the BW and controlling the transmission delay of each ONU according to its SLA. The MPCP defines a closed loop operation in order for this algorithm to be efficient. The MPCP allows the ONUs to report on the amount of BW they require for transmission using a special REPORT message. This allows allocating BW to an ONU only when requested, relying on the statistical burst property of the traffic, and allowing different peak BW for different ONUs at different times; hence, allowing oversubscription of the BW. The REPORT message reports the amount of data waiting in the ONU queues. In addition, the MPCP defines a protocol of auto-discovery and registration of ONUs. Khermosh Standards Track [Page 11] RFC 4837 Managed Objects of EPON July 2007 The registration process is defined in the diagram below: OLT ONU | | | Discovery Gate message \| |--------------------------------------------| | /| | | |/ Register Request message | |--------------------------------------------| |\ | | | | Register message | | (assigning LLID) \| |--------------------------------------------| | /| | | | Gate message \| |--------------------------------------------| | /| | | |/ Register ACK message | |--------------------------------------------| |\ | | | | | A new ONU requests to register (sends a REG_REQUEST message) in a special discovery grant, allocated for that by the OLT. During that time, more than one ONU might try to register. A collision in transmission might occur, as the RTT of the new ONUs is not yet known. A random backoff mechanism of the transmission is used to schedule the following registration requests to avoid these collisions. When the OLT receives a REG_REQUEST message of an ONU and approves this ONU, then it sends a REGISTER message to this ONU defining its LLID. From that point, the ONU transmission is scheduled by its LLID, knowing the RTT, and no collision can occur. The ONU replies with a REGISTER_ACK message and the registration process of the MPCP ends. Higher layer protocols may be needed to authenticate the ONU and allow it to participate in the network. 2.2.7. Forward Error Correction (FEC) The FEC is defined to enhance the link budget of the PON. As each splitter attenuates the optical signal, the number of the splits and the distance are limited by the link budget. Hence an FEC that Khermosh Standards Track [Page 12] RFC 4837 Managed Objects of EPON July 2007 improves the link budget has a benefit. The FEC code used is the RS(239,255,8), similar to the FEC code in [ITU-T.G.975], improving the BER from 1E-4 to 1E-12. The FEC parity encapsulation is based on the framing of the Ethernet packet. The Ethernet packets are spaced by MAC rate adaptation, and the parity bytes are inserted after the packet in the provided space. As the start and end of packet codewords also define the FEC boundaries, and they are outside the FEC protection, they are replaced by a series of symbols to reduce their vulnerability to errors. The following diagram presents an FEC-protected frame: +-------------------------------------------------------------------+ | | | | | | | | | S_FEC | Preamble/SFD | Frame | FCS | T_FEC | Parity | T_FEC | | | | | | | | | +-------------------------------------------------------------------+ The FEC is added in a separate layer between the PCS and PMA layers of the [802.3]. The FEC layer introduces a fixed delay in receive path and transmit path. The FEC layer is optional. 2.3. Management Architecture Each one of the EPON layers is accompanied by a management interface that is controlled through clause 30 of the [802.3ah]. As the [802.3ah] specification may be used for different applications, and some of the clauses may be used separately, the IEEE management clause allocates for each one of them a separate package. The MIB document follows this partition. Khermosh Standards Track [Page 13] RFC 4837 Managed Objects of EPON July 2007 The following diagram presents the relation of the MIB groups to the [802.3ah] layers: +===========================+ | Higher layers | +===========================+ | 802.1D Bridge | +===========================+ |MAC client| ... |MAC client| +===========================+ \ +=============================+ | MAC Control - (MPCP) |----- |MpcpObjects| ... |MpcpObjects| +===========================+ / +=============================+ | MAC | ... | MAC | +===========================+ \ +=============================+ | P2P Emulation (P2PE) |----- |OmpEmulat | |OmpEmulat | +===========================+ / |ionObjects | ... |ionObjects | | | +=============================+ | GMII | | | +===========================+ | PCS | +===========================+ \ +=============================+ | FEC |----- |FecObjects | ... |FecObjects | +===========================+ / +=============================+ | PMA | +===========================+ | PMD | +===========================+ | | | MDI | | | /===============/ / Media / /===============/ The association is straightforward for the ONU interface. There is one logical and one physical interface, and a single copy exists for each layer that can be remotely queried by the OLT. At the OLT there is a single physical interface and N virtual interfaces for the virtual links of the ONUs (and another virtual interface for the broadcast virtual link). As can be seen from the layering diagram above, the MAC layer is virtually duplicated. Therefore, in this document it was selected that the management of a virtual interface is like a physical interface, an interface index is allocated for each one of the virtual links, and an additional interface index is allocated for the OLT. Khermosh Standards Track [Page 14] RFC 4837 Managed Objects of EPON July 2007 To illustrate the interface modeling consider two devices; the first device has two physical interfaces, is typically located at a consumer's site, and is called an "ONU modem". An "ONU modem" is shown in the figure below: -------- ONU interface | ONU | 10 megabit interface --------------| modem |-------------------- --------- This device would have 3 entries in the IF table, and one IF stack entry; for example: ifIndex=1 - interface for 10 megabit interface ifIndex=2 - interface for the optical interface ifIndex=200 - interface for the ONU interface And then in the IF stack table: ifStackHigherLayer=200, ifStackLowerLayer=2 - map between the physical and the ONU The second device has three physical interfaces, is typically located at the provider's site, and may be called a "headend". A "headend" is shown in the figure below: --------- 1st OLT interface | Head | gigE interface ------------------| end |-------------------- | | ------------------| | 2nd OLT interface | | --------- Khermosh Standards Track [Page 15] RFC 4837 Managed Objects of EPON July 2007 This device would have 5 entries (when there are no attached ONUs) in the IF table, for example: ifIndex=1 - interface for gigE interface ifIndex=2 - interface for 1st optical interface ifIndex=3 - interface for 2nd optical interface ifIndex=265535 - interface for the 1st OLT broadcast interface ifIndex=365535 - interface for the 2nd OLT broadcast interface And then in the IF stack table: ifStackHigherLayer=265535, ifStackLowerLayer=2 - map between the 1st physical and its broadcast interface ifStackHigherLayer=365535, ifStackLowerLayer=3 - map between the 2nd physical and its broadcast interface If two ONUs connected to the first OLT interface, then for example, the following entries would be added to the IF table: ifIndex=200001 - interface for the 1st ONU of 1st OLT ifIndex=200002 - interface for the 2nd ONU of 1st OLT And in the IF stack table: ifStackHigherLayer=200001, ifStackLowerLayer=2 - map between the 1st physical and 1st ONU ifStackHigherLayer=200002, ifStackLowerLayer=2 - map between the 1st physical and 2nd ONU For each physical interface, there would be an entry (ifIndex) in the tables of the interface MIB module [RFC2863], MAU MIB module [RFC4836], and Etherlike MIB module [RFC3635]. Additionally, there would be entries (ifIndexes) for the virtual interfaces of the OLT interface. The justification for the additional allocation of indexes is that the virtual interfaces are quite well distinguished, as they connect different physical ONUs from the OLT side. For instance, there is a meaning for separate bad frames counter or bad octets counter for each virtual link, as the ONUs can be differently distanced. This is quite similar to a case of separate physical interfaces. Khermosh Standards Track [Page 16] RFC 4837 Managed Objects of EPON July 2007 The same partition concept exists for the MIB module of this document. Each row in the tables are indexed according to the ifIndex; specifically, there is a row for each virtual link. There are some control objects that are shared and are the same for the virtual interfaces (and they should have the same value for each ifIndex), but most of the objects have different values for N+1 logical interfaces at the OLT. This is done for each MIB group. It is a bit different from the [802.3ah] layering diagram, which presents the P2MP layer as a single layer, while duplicating the MAC and MAC client layers (please see the diagram above). However, from a management perspective, it is more convenient and neat to partition the management of the layers for the virtual links, as the atomic managed entity is the virtual link. It is also convenient to use the interface index of the virtual link for that purpose, as it is already used to index the rows of the virtual links at the Interface, MAU, and etherLike interfaces MIBs. 3. MIB Structure This document defines the DOT3 EPON MIB module. The DOT3 EPON MIB module defines the objects used for management of the [802.3ah] Point-to-Multipoint (P2MP) interfaces. These MIB objects are included in four groups. i) The Multi-Point Control Protocol (MPCP) MIB objects - MIB objects related to [802.3ah], clause 64, Multi-Point Control Protocol attributes. The following tables are presented in this group: The dot3MpcpControlTable defines the objects used for the configuration and status indication, which are per logical link, of MPCP compliant interfaces. The dot3MpcpStatTable defines the statistics objects that are per logical link, of MPCP compliant interfaces. The operational mode of an OLT/ONU for the tables is defined by the dot3MpcpMode object in the dot3MpcpControlTable. ii) The OMPEmulation MIB objects - MIB objects related to [802.3ah], clause 65, point-to-point emulation attributes. The following tables are presented in this group: The dot3OmpEmulationTable defines the objects used for the configuration and status indication, which are per logical links, of OMPEmulation compliant interfaces. The dot3OmpEmulationStatTable defines the statistics objects that are per logical link, of OMPEmulation compliant interfaces. Khermosh Standards Track [Page 17] RFC 4837 Managed Objects of EPON July 2007 The operational mode of an OLT/ONU for the tables is defined by the dot3OmpEmulationType object in the dot3OmpEmulationTable. iii) The FEC MIB objects - MIB objects related to [802.3ah], clause 60 and clause 65, EPON FEC attributes. The following table is presented in this group: The dot3EponFecTable defines the objects used for the configuration and status indication, which are per logical link, of FEC EPON compliant interfaces. iv) The EPON extended package MIB objects - MIB objects used for configuration and status indication with extended capabilities of the EPON interfaces. The following tables are presented in this group: The dot3ExtPkgControlTable defines the objects, which are per logical link, used for the configuration and status indication of EPON compliant interfaces. The dot3ExtPkgQueueTable defines the objects, which are per logical link, and per queue, used for the configuration and status indication of the ONU queues reported in the MPCP REPORT message, of EPON compliant interfaces. The dot3ExtPkgQueueSetsTable defines the objects, which are per logical link, per queue, and per queue_set, used for the configuration and status indication of the ONU queue_sets reported in the MPCP REPORT message, of EPON compliant interfaces. The dot3ExtPkgOptIfTable defines the objects, which are per logical link, used for the control and status indication of the optical interface of EPON compliant interfaces. As described in the architecture section, each row in the tables is indexed according to the ifIndex; specifically, there is a row for each virtual link. There are a few control objects that are shared and have the same value for the virtual interfaces (and they should have the same value for each ifIndex), but most of the objects have different values for N+1 logical interfaces at the OLT. This is done for each MIB group. It is a bit different from the [802.3ah] layering diagram, which presents the P2MP layer as a single layer while duplicating the MAC and MAC client layers. However, from a management perspective, it is more convenient and neat to partition the management of the layers for the virtual links, as the atomic managed entity is the virtual link. It is also convenient to use the interface index of the virtual link for that purpose, as it is already used to index the rows of the virtual links at the Interface, MAU, and etherLike interfaces MIBs. Khermosh Standards Track [Page 18] RFC 4837 Managed Objects of EPON July 2007 For example, provided below are the values of the MPCP control table of an OLT with 3 registered ONUs: The table below presents the MPCP control table of ONU1 in working mode. A single row exists in the table. +---------------------------+-----------------+ | MPCP control MIB object | Value | +---------------------------+-----------------+ | ifIndex | 100 | | dot3MpcpOperStatus | true | | dot3MpcpAdminState | true | | dot3MpcpMode | onu | | dot3MpcpSyncTime | 25 | | dot3MpcpLinkID | 1 | | dot3MpcpRemoteMACAddress | OLT_MAC_Address | | dot3MpcpRegistrationState | registered | | dot3MpcpTransmitElapsed | 10 | | dot3MpcpReceiveElapsed | 10 | | dot3MpcpRoundTripTime | 100 | +---------------------------+-----------------+ Table 1 OLT_MAC_Address is the MAC address of the OLT EPON interface. The creation of the rows of the ONU interface is done at initialization. For example, provided below are the values for the MPCP control table of the ONU, after initialization, before registration. Khermosh Standards Track [Page 19] RFC 4837 Managed Objects of EPON July 2007 The table below presents the MPCP control table of ONU1 after initialization. A single row exists in the table. +---------------------------+-------------------+ | MPCP control MIB object | Value | +---------------------------+-------------------+ | ifIndex | 100 | | dot3MpcpOperStatus | true | | dot3MpcpAdminState | true | | dot3MpcpMode | onu | | dot3MpcpSyncTime | 0 | | dot3MpcpLinkID | 0 | | dot3MpcpRemoteMACAddress | 00:00:00:00:00:00 | | dot3MpcpRegistrationState | unregistered | | dot3MpcpTransmitElapsed | 0 | | dot3MpcpReceiveElapsed | 0 | | dot3MpcpRoundTripTime | 0 | +---------------------------+-------------------+ Table 2 Khermosh Standards Track [Page 20] RFC 4837 Managed Objects of EPON July 2007 The table below presents the MPCP control table of the OLT in working mode. Four rows exist in the table associated with the virtual links. +----------------+-----------+------------+------------+------------+ | MPCP control | Value | Value | Value | Value | | MIB object | | | | | +----------------+-----------+------------+------------+------------+ | ifIndex | 100001 | 100002 | 100003 | 165535 | | dot3MpcpOperSt | true | true | true | true | | atus | | | | | | dot3MpcpAdminS | true | true | true | true | | tate | | | | | | dot3MpcpMode | olt | olt | olt | olt | | dot3MpcpSyncTi | 25 | 25 | 25 | 25 | | me | | | | | | dot3MpcpLinkID | 1 | 2 | 3 | 65535 | | dot3MpcpRemote | ONU1_MAC_ | ONU2_MAC_A | ONU3_MAC_A | BRCT_MAC_A | | MACAddress | Address | ddress | ddress | ddress | | dot3MpcpRegist | registere | registered | registered | registered | | rationState | d | | | | | dot3MpcpTransm | 10 | 10 | 10 | 10 | | itElapsed | | | | | | dot3MpcpReceiv | 10 | 10 | 10 | 10 | | eElapsed | | | | | | dot3MpcpRoundT | 100 | 60 | 20 | 0 | | ripTime | | | | | +----------------+-----------+------------+------------+------------+ Table 3 ONU1_MAC_Address is the MAC address of ONU1 EPON interface. ONU2_MAC_Address is the MAC address of ONU2 EPON interface. ONU3_MAC_Address is the MAC address of ONU3 EPON interface. BRCT_MAC_Address is the MAC address of the broadcast EPON interface, which is the OLT MAC address. The creation of the rows of the OLT interface and the broadcast virtual interface is done at initialization. The creation of rows of the virtual interfaces at the OLT is done when the link is established (ONU registers) and the deletion is done when the link is deleted (ONU deregisters). Khermosh Standards Track [Page 21] RFC 4837 Managed Objects of EPON July 2007 For example, provided below are the values of the MPCP control table of the OLT after initialization, before the ONUs register. The table below presents the MPCP control table of the OLT after initialization. A single row exists in this table associated with the virtual broadcast link. +---------------------------+------------------+ | MPCP control MIB object | Value | +---------------------------+------------------+ | ifIndex | 165535 | | dot3MpcpOperStatus | true | | dot3MpcpAdminState | true | | dot3MpcpMode | olt | | dot3MpcpSyncTime | 25 | | dot3MpcpLinkID | 65535 | | dot3MpcpRemoteMACAddress | BRCT_MAC_Address | | dot3MpcpRegistrationState | registered | | dot3MpcpTransmitElapsed | 10 | | dot3MpcpReceiveElapsed | 100000 | | dot3MpcpRoundTripTime | 0 | +---------------------------+------------------+ Table 4 BRCT_MAC_Address is the MAC address of the broadcast EPON interface, which is the OLT MAC address. 4. Relation to Other MIB Modules 4.1. Relation to the Interfaces MIB and Ethernet-like Interfaces MIB EPON interface is a kind of Ether-like interface. This MIB module extends the objects of the Interface MIB and the Ether-like Interfaces MIB for an EPON type interface. Implementing this module therefore MUST require implementation of the Interfaces MIB module [RFC2863] and the Ethernet-like Interfaces MIB module [RFC3635]. Thus, each managed EPON interface would have a corresponding entry in the mandatory tables of the Ether-like MIB module found in [RFC3635], and likewise in the tables of the Interface MIB module found in [RFC2863]. Also each managed virtual EPON interface would have a corresponding entry in the mandatory tables of the Ether-like MIB module found in [RFC3635], and likewise in the tables of the Interface MIB module found in [RFC2863] with a dedicated ifIndex for this interface. Khermosh Standards Track [Page 22] RFC 4837 Managed Objects of EPON July 2007 In this document, there is no replication of the objects from these MIBs. Therefore, for instance, the document is defining dot3MpcpRemoteMACAddress only while assuming that the local MAC address object is already defined in [RFC3635]. The interface MIB module [RFC2863] defines the interface index (ifIndex). Interface Index, as specified in [RFC2863], is used in this MIB Module as an index to the EPON MIB tables. The ifIndex is used to denote the physical interface and the virtual link interfaces at the OLT. The OLT interface and the virtual link interfaces are stacked using the ifStack table defined in [RFC2863], and the ifInvStack defined in [RFC2864]. The OLT interface is the lower layer of all other interfaces associated with the virtual links. This document defines the specific EPON objects of an ONU interface and an OLT interface. Information in the tables is per LLID. The rows in the EPON MIB tables referring to the LLIDs are denoted with the corresponding ifIndexes of the virtual link interfaces. Please note that each virtual interface does not have a different physical MAC address at the OLT, as the physical interface is the same. It is specified in the [802.3ah], Section 64.1.2. The corresponding object of the Ether-like interface MIB is duplicated for all the virtual interfaces. For example, the values of the Interface MIB objects are presented in the following tables, for an OLT with 3 registered ONUs: Khermosh Standards Track [Page 23] RFC 4837 Managed Objects of EPON July 2007 The table below presents the objects of the Interface MIB of an ONU in working mode. +----------------------+--------------------------------+ | Interface MIB object | Value | +----------------------+--------------------------------+ | ifIndex | 1 | | ifDescr | "interface description" | | ifType | ethernetCsmacd (6) 1000base-Px | | ifMtu | MTU size (1522) | | ifSpeed | 1000000000 | | ifPhysAddress | ONU_MAC_Address | | ifAdminStatus | up | | ifOperStatus | Up | | ifLastChange | ONUup_time | | ifInOctets | ONU_octets_number | | ifInUcastPkts | ONU_unicast_frame_number | | ifInNUcastPkts | ONU_non_unicast_frame_number | | ifInDiscards | ONU_discard_frame_number | | ifInErrors | ONU_error_frame_number | | ifInUnknownProtos | ONU_unknown_frame_number | | ifOutOctets | ONU_octets_number | | ifOutUcastPkts | ONU_unicast_frame_number | | ifOutNUcastPkts | ONU_non_unicast_frame_number | | ifOutDiscards | ONU_discard_frame_number | | ifOutErrors | ONU_error_frame_number | | ifOutQLen | ONU_queue_frame_number | +----------------------+--------------------------------+ Table 5 ONU_MAC_Address is the MAC address of the ONU EPON interface. Khermosh Standards Track [Page 24] RFC 4837 Managed Objects of EPON July 2007 The table below presents the objects of the Interface MIB of the ONU interface. +----------------------+--------------------------------+ | Interface MIB object | Value | +----------------------+--------------------------------+ | ifIndex | 100 | | ifDescr | "interface description" | | ifType | ethernetCsmacd (6) 1000base-Px | | ifMtu | MTU size (1522) | | ifSpeed | 1000000000 | | ifPhysAddress | ONU_MAC_Address | | ifAdminStatus | up | | ifOperStatus | Up | | ifLastChange | up_time | | ifInOctets | ONU1_octets_number | | ifInUcastPkts | ONU1_unicast_frame_number | | ifInNUcastPkts | ONU1_non_unicast_frame_number | | ifInDiscards | ONU1_discard_frame_number | | ifInErrors | ONU1_error_frame_number | | ifInUnknownProtos | ONU1_unknown_frame_number | | ifOutOctets | ONU1_octets_number | | ifOutUcastPkts | ONU1_unicast_frame_number | | ifOutNUcastPkts | ONU1_non_unicast_frame_number | | ifOutDiscards | ONU1_discard_frame_number | | ifOutErrors | ONU1_error_frame_number | | ifOutQLen | ONU1_queue_frame_number | +----------------------+--------------------------------+ Table 6 ONU_MAC_Address is the MAC address of the ONU EPON interface. The following values will be set in the ifStack and ifInvStack tables related to this example. ifStackTable: ifStackHigherLayer=100, ifStackLowerLayer=1 - map between the physical interface and the ONU ifInvStackTable: ifStackLowerLayer=1, ifStackHigherLayer=100,- map between the ONU and the physical interface Khermosh Standards Track [Page 25] RFC 4837 Managed Objects of EPON July 2007 The table below presents the Interface MIB objects of an OLT interface. +----------------------+--------------------------------+ | Interface MIB object | Value | +----------------------+--------------------------------+ | ifIndex | 2 | | ifDescr | "interface description" | | ifType | ethernetCsmacd (6) 1000base-Px | | ifMtu | MTU size (1522) | | ifSpeed | 1000000000 | | ifPhysAddress | OLT_MAC_Address | | ifAdminStatus | up | | ifOperStatus | Up | | ifLastChange | OLTup_time | | ifInOctets | OLT_octets_number | | ifInUcastPkts | OLT_unicast_frame_number | | ifInNUcastPkts | OLT_non_unicast_frame_number | | ifInDiscards | OLT_discard_frame_number | | ifInErrors | OLT_error_frame_number | | ifInUnknownProtos | OLT_unknown_frame_number | | ifOutOctets | OLT_octets_number | | ifOutUcastPkts | OLT_unicast_frame_number | | ifOutNUcastPkts | OLT_non_unicast_frame_number | | ifOutDiscards | OLT_discard_frame_number | | ifOutErrors | OLT_error_frame_number | | ifOutQLen | OLT_queue_frame_number | +----------------------+--------------------------------+ Table 7 OLT_MAC_Address is the MAC address of the OLT EPON interface. Khermosh Standards Track [Page 26] RFC 4837 Managed Objects of EPON July 2007 The table below presents the Interface MIB objects of an OLT interface, associated with the virtual link interfaces. +----------+-------------+-------------+-------------+--------------+ | Interfac | Value | Value | Value | Value | | eMIB | | | | | | object | | | | | +----------+-------------+-------------+-------------+--------------+ | ifIndex | 200001 | 200002 | 200003 | 265535 | | ifDescr | "interface | "interface | "interface | "interface | | | description | description | description | description" | | | " | " | " | | | ifType | ethernetCsm | ethernetCsm | ethernetCsm | ethernetCsma | | | acd (6) | acd (6) | acd (6) | cd (6) | | ifMtu | MTUsize(152 | MTUsize(152 | MTUsize(152 | MTUsize(1522 | | | 2) | 2) | 2) | ) | | ifSpeed | 1000000000 | 1000000000 | 1000000000 | 1000000000 | | ifPhysAd | OLT_MAC_Add | OLT_MAC_Add | OLT_MAC_Add | OLT_MAC_Addr | | dress | ress | ress | ress | ess | | ifAdminS | up | up | up | up | | tatus | | | | | | ifOperSt | Up | Up | Up | Up | | atus | | | | | | ifLastCh | ONU1_up_tim | ONU2_up_tim | ONU3_up_tim | up_time | | ange | e | e | e | | | ifInOcte | ONU1_octets | ONU2_octets | ONU3_octets | BRCT_octets_ | | ts | _number | _number | _number | number | | ifInUcas | ONU1_unic_f | ONU2_unic_f | ONU3_unic_f | BRCT_unic_fr | | tPkts | rame_num | rame_num | rame_num | ame_num | | ifInNUca | ONU1_non_un | ONU2_non_un | ONU3_non_un | BRCT_non_uni | | stPkts | ic_frame_nu | ic_frame_nu | ic_frame_nu | c_frame_num | | | m | m | m | | | ifInDisc | ONU1_disc_f | ONU2_disc_f | ONU3_disc_f | BRCT_disc_fr | | ards | rame_num | rame_num | rame_num | ame_numr | | ifInErro | ONU1_err_fr | ONU2_err_fr | ONU3_err_fr | BRCT_err_fra | | rs | ame_num | ame_num | ame_num | me_num | | ifInUnkn | ONU1_unknw_ | ONU2_unknw_ | ONU3_unknw_ | BRCT_unknw_f | | ownProto | frame_num | frame_num | frame_num | rame_num | | s | | | | | | ifOutOct | ONU1_octets | ONU2_octets | ONU3_octets | BRCT_octets_ | | ets | _number | _number | _number | number | | ifOutUca | ONU1_unic_f | ONU2_unic_f | ONU3_unic_f | BRCT_unic_fr | | stPkts | rame_num | rame_num | rame_num | ame_num | | ifOutNUc | ONU1_non_un | ONU2_non_un | ONU3_non_un | BRCT_non_uni | | astPkts | ic_frame_nu | ic_frame_nu | ic_frame_nu | c_frame_num | | | m | m | m | | Khermosh Standards Track [Page 27] RFC 4837 Managed Objects of EPON July 2007 +----------+-------------+-------------+-------------+--------------+ | Interfac | Value | Value | Value | Value | | eMIB | | | | | | object | | | | | +----------+-------------+-------------+-------------+--------------+ | ifOutDis | ONU1_disc_f | ONU2_disc_f | ONU3_disc_f | BRCT_disc_fr | | cards | rame_num | rame_num | rame_num | ame_num | | ifOutErr | ONU1_err_fr | ONU2_err_fr | ONU3_err_fr | BRCT_err_fra | | ors | ame_num | ame_num | ame_num | me_num | | ifOutQLe | ONU1_queue_ | ONU2_queue_ | ONU3_queue_ | BRCt_queue_f | | n | frame_num | frame_num | frame_num | rame_num | +----------+-------------+-------------+-------------+--------------+ Table 8 OLT_MAC_Address is the MAC address of the OLT EPON interface. The following values will be set in the ifStack and ifInvStack tables related to this example: ifStackTable: ifStackHigherLayer=265535, ifStackLowerLayer=2 - map between the OLT physical interface and its broadcast virtual interface ifStackHigherLayer=200001, ifStackLowerLayer=2 - map between the OLT physical interface and its virtual interface of the 1st ONU ifStackHigherLayer=200002, ifStackLowerLayer=2 - map between the OLT physical interface and its virtual interface of the 2nd ONU ifStackHigherLayer=200003, ifStackLowerLayer=2 - map between the OLT physical interface and its virtual interface of the 3rd ONU ifInvStackTable: ifStackLowerLayer=2, ifStackHigherLayer=265535, - map between the broadcast interface of the OLT and the OLT physical interface ifStackLowerLayer=2, ifStackHigherLayer=200001 - map between the OLT virtual interface of the 1st ONU and the OLT physical interface ifStackLowerLayer=2, ifStackHigherLayer=200002 - map between the OLT virtual interface of the 2nd ONU and the OLT physical interface ifStackLowerLayer=2, ifStackHigherLayer=200003 - map between the OLT virtual interface of the 3rd ONU and the OLT physical interface Khermosh Standards Track [Page 28] RFC 4837 Managed Objects of EPON July 2007 The rows for the ONU interface, the OLT interface, and the OLT broadcast interface are created in initialization. The creation of a row for a virtual link is done when the virtual link is established (ONU registers), and deletion is done when the virtual link is deleted (ONU deregisters). The EPON MIB module also extends the Interface MIB module with a set of counters, which are specific for the EPON interface. The EPON MIB module implements the same handling of the counters when the operation of the interface starts or stops. The interface MIB document describes the possible behavior of counters when an interface is re-initialized using the ifCounterDiscontinuityTime indicator, indicating the discontinuity of the counters. Please see [RFC2863], Section 3.1.5, page 11 for more information. The counters of the EPON MIB should be handled in a similar manner. 4.2. Relation to the IEEE 802.3 MAU MIBs The MAU types of the EPON Interface are defined in the amended MAU MIB document. This document assumes the implementation of the MAU MIB for this purpose and does not repeat the EPON MAU types. Therefore, implementing this module MUST require implementation of the MAU-MIB module [RFC4836]. The handling of the ifMAU tables for the EPON case is similar to the handling described in the former section for the Interface and Ether- like interface MIBs. A single row exists for the ONU in the ifMauTable. A row for each virtual link (N+1 rows) exists at the OLT, with a separate value of ifMauIfIndex for each virtual link. As specified above, the rows for the ONU interface, the OLT interface, and the OLT broadcast interface are created in initialization. The creation of a row for a virtual link is done when the virtual link is established (ONU registers), and deletion is done when the virtual link is deleted (ONU deregisters). 4.3. Relation to the EFM OAM MIB The EPON interfaces are aimed to the optical access networks and most probably will be accompanied with the implementation of the OAM section of the [802.3ah]. Therefore, the EFM OAM MIB module [RFC4878] MAY be implemented when this MIB module is implemented defining managed objects for the OAM layer that are complementary to the EFM EPON MIB module. As the OAM is defined for a point-to-point link it is implemented in this case using the virtual links that are Khermosh Standards Track [Page 29] RFC 4837 Managed Objects of EPON July 2007 defined for the P2MP network, so that an instance is held for each Logical Link Identifier (LLID) of the EPON. The corresponding ifIndex of the virtual link is used as the ifIndex of the tables of the OAM MIB module for this purpose. 4.4. Relation to the Bridge MIB It is very probable that an EPON OLT will implement a bridging functionality above the EPON interface layer, bridging between the EPON users and the network. Bridge functionality is specified at [802.1d]. In this scenario, the virtual ports of the EPON are corresponding to the virtual bridge ports. There is a direct mapping between the bridge ports and the LLIDs, which are virtual EPON channels. Therefore, the bridge MIB modules ([RFC4188] and [RFC1525]) MAY be implemented when the EFM EPON MIB module is implemented for an EPON OLT, defining managed objects for the bridge layer. The values of dot1dBasePortIfIndex would correspond to the ifIndex of the virtual port (1 for LLID1, 2 for LLID2, etc.). The broadcast virtual EPON interface of the OLT has no direct mapping to a virtual bridge port as it is not port specific but used for broadcast traffic. Khermosh Standards Track [Page 30] RFC 4837 Managed Objects of EPON July 2007 5. Mapping of IEEE 802.3ah Managed Objects This section contains the mapping between the managed objects defined in this document and the attributes defined in [802.3ah], clause 30. The tables are divided into relevant groups. oMPCP managed object class (30.3.5) +----------------------------+-------------------------+------------+ | dot3EPON MIB module object | IEEE802.3ah attribute | Reference | +----------------------------+-------------------------+------------+ | ifIndex | aMPCPID | 30.3.5.1.1 | | dot3MpcpOperStatus | aMPCPAdminState | 30.3.5.1.2 | | dot3MpcpMode | aMPCPMode | 30.3.5.1.3 | | dot3MpcpLinkID | aMPCPLinkID | 30.3.5.1.4 | | dot3MpcpRemoteMACAddress | aMPCPRemoteMACAddress | 30.3.5.1.5 | | dot3MpcpRegistrationState | aMPCPRegistrationState | 30.3.5.1.6 | | dot3MpcpMACCtrlFramesTrans | aMPCPMACCtrlFramesTrans | 30.3.5.1.7 | | mitted | mitted | | | dot3MpcpMACCtrlFramesRecei | aMPCPMACCtrlFramesRecei | 30.3.5.1.8 | | ved | ved | | | dot3MpcpTxGate | aMPCPTxGate | 30.3.5.1.9 | | dot3MpcpTxRegAck | aMPCPTxRegAck | 30.3.5.1.1 | | | | 0 | | dot3MpcpTxRegister | aMPCPTxRegister | 30.3.5.1.1 | | | | 1 | | dot3MpcpTxRegRequest | aMPCPTxRegRequest | 30.3.5.1.1 | | | | 2 | | dot3MpcpTxReport | aMPCPTxReport | 30.3.5.1.1 | | | | 3 | | dot3MpcpRxGate | aMPCPRxGate | 30.3.5.1.1 | | | | 4 | | dot3MpcpRxRegAck | aMPCPRxRegAck | 30.3.5.1.1 | | | | 5 | | dot3MpcpRxRegister | aMPCPRxRegister | 30.3.5.1.1 | | | | 6 | | dot3MpcpRxRegRequest | aMPCPRxRegRequest | 30.3.5.1.1 | | | | 7 | | dot3MpcpRxReport | aMPCPRxReport | 30.3.5.1.1 | | | | 8 | | dot3MpcpTransmitElapsed | aMPCPTransmitElapsed | 30.3.5.1.1 | | | | 9 | | dot3MpcpReceiveElapsed | aMPCPReceiveElapsed | 30.3.5.1.2 | | | | 0 | | dot3MpcpRoundTripTime | aMPCPRoundTripTime | 30.3.5.1.2 | | | | 1 | | dot3MpcpDiscoveryWindowsSe | aMPCPDiscoveryWindowsSe | 30.3.5.1.2 | | nt | nt | 2 | Khermosh Standards Track [Page 31] RFC 4837 Managed Objects of EPON July 2007 +----------------------------+-------------------------+------------+ | dot3EPON MIB module object | IEEE802.3ah attribute | Reference | +----------------------------+-------------------------+------------+ | dot3MpcpDiscoveryTimeout | aMPCPDiscoveryTimeout | 30.3.5.1.2 | | | | 3 | | dot3MpcpMaximumPendingGran | aMPCPMaximumPendingGran | 30.3.5.1.2 | | ts | ts | 4 | | dot3MpcpAdminState | aMPCPAdminControl | 30.3.5.2.1 | | dot3MpcpSyncTime | SyncTime | 64.3.3.2 | +----------------------------+-------------------------+------------+ Table 9 oOMPEmulation managed object class (30.3.7) +-------------------------------------+-----------------+-----------+ | dot3EPON MIB module object | IEEE802.3ah | Reference | | | attribute | | +-------------------------------------+-----------------+-----------+ | ifIndex | aOMPEmulationID | 30.3.7.1. | | | | 1 | | dot3OmpEmulationType | aOMPEmulationTy | 30.3.7.1. | | | pe | 2 | | dot3OmpEmulationSLDErrors | aSLDErrors | 30.3.7.1. | | | | 3 | | dot3OmpEmulationCRC8Errors | aCRC8Errors | 30.3.7.1. | | | | 4 | | dot3OmpEmulationGoodLLID | aGoodLLID | 30.3.7.1. | | | | 5 | | dot3OmpEmulationOnuPonCastLLID | aONUPONcastLLID | 30.3.7.1. | | | | 6 | | dot3OmpEmulationOltPonCastLLID | aOLTPONcastLLID | 30.3.7.1. | | | | 7 | | dot3OmpEmulationBadLLID | aBadLLID | 30.3.7.1. | | | | 8 | | dot3OmpEmulationBroadcastBitNotOnuL | | | | Lid | | | | dot3OmpEmulationOnuLLIDNotBroadcast | | | | dot3OmpEmulationBroadcastBitPlusOnu | | | | Llid | | | | dot3OmpEmulationNotBroadcastBitNotO | | | | nuLlid | | | +-------------------------------------+-----------------+-----------+ Table 10 Khermosh Standards Track [Page 32] RFC 4837 Managed Objects of EPON July 2007 oMAU managed object class (30.5.1) +--------------------------------+---------------------+------------+ | dot3EPON MIB module object | IEEE802.3ah | Reference | | | attribute | | +--------------------------------+---------------------+------------+ | dot3EponFecPCSCodingViolation | aPCSCodingViolation | 30.5.1.1.1 | | | | 2 | | dot3EponFecAbility | aFECAbility | 30.5.1.1.1 | | | | 3 | | dot3EponFecMode | aFECmode | 30.5.1.1.1 | | | | 4 | | dot3EponFecCorrectedBlocks | aFECCorrectedBlocks | 30.5.1.1.1 | | | | 5 | | dot3EponFecUncorrectableBlocks | aFECUncorrectableBl | 30.5.1.1.1 | | | ocks | 6 | | dot3EponFecBufferHeadCodingVio | | | | lation | | | +--------------------------------+---------------------+------------+ Table 11 6. Definitions - The DOT3 EPON MIB Module DOT3-EPON-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, OBJECT-TYPE, Counter32, Integer32, Unsigned32, Counter64 FROM SNMPv2-SMI TruthValue, MacAddress FROM SNMPv2-TC ifIndex FROM IF-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ; dot3EponMIB MODULE-IDENTITY LAST-UPDATED "200703290000Z" -- March 29, 2007 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing Lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-request@ietf.org Khermosh Standards Track [Page 33] RFC 4837 Managed Objects of EPON July 2007 In Body: subscribe your_email_address Chair: Bert Wijnen Postal: Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands Tel: +31-348-407-775 E-mail: bwijnen@lucent.com Editor: Lior Khermosh Postal: PMC-SIERRA Kohav Hertzelia bldg, 4 Hasadnaot St. Hertzliya Pituach 46120, ISRAEL P.O.Box 2089 Hertzliya Pituach 46120 Israel Tel: +972-9-9628000 Ext: 302 E-mail: lior_khermosh@pmc-sierra.com" DESCRIPTION "The objects in this MIB module are used to manage the Ethernet in the First Mile (EFM) Ethernet Passive Optical Network (EPON) Interfaces as defined in IEEE P802.3ah clauses 60, 64, and 65. The following reference is used throughout this MIB module: [802.3ah] refers to: Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters for subscriber access networks. IEEE Std 802.3ah-2004, October 2004. Of particular interest are clause 64 (Multi-Point Control Protocol - MPCP), clause 65 (Point-to-Multipoint Reconciliation Sublayer - P2MP RS), clause 60 (Ethernet Passive Optical Network Physical Medium Dependent - EPON PMDs), clause 30, 'Management', and clause 45, 'Management Data Input/Output (MDIO) Interface'. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of 4837; see the RFC itself for full legal notices. Key abbreviations: BER - Bit Error Rate BW - bandwidth Khermosh Standards Track [Page 34] RFC 4837 Managed Objects of EPON July 2007 CRC - Cyclic Redundancy Check EFM - Ethernet First Mile EPON - Ethernet Passive Optical Network FEC - Forward Error Correction LLID - Logical Link Identifier MAC - Media Access Control Mbps - Megabit per second MDIO - Management Data Input/Output MPCP - Multi-Point Control Protocol OLT - Optical Line Terminal (Server unit of the EPON) OMP - Optical Multi-Point ONU - Optical Network Unit (Client unit of the EPON) P2MP - Point-to-Multipoint PHY - Physical Layer PMD - Physical Medium Dependent PON - Passive Optical Network RTT - Round Trip Time SLD - Start of LLID Delimiter TQ - Time Quanta " REVISION "200703290000Z" -- March 29, 2007 DESCRIPTION "Initial version, published as RFC 4837." ::= { mib-2 155 } dot3EponObjects OBJECT IDENTIFIER ::= { dot3EponMIB 1} dot3EponConformance OBJECT IDENTIFIER ::= { dot3EponMIB 2} -- MPCP MIB modules definitions ([802.3ah], clause 30.3.5) dot3EponMpcpObjects OBJECT IDENTIFIER ::= { dot3EponObjects 1 } dot3MpcpControlTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3MpcpControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Table of dot3 Multi-Point Control Protocol (MPCP) MIB objects. The entries in the table are control and status objects of the MPCP. Each object has a row for every virtual link denoted by the corresponding ifIndex. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number Khermosh Standards Track [Page 35] RFC 4837 Managed Objects of EPON July 2007 of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff)." ::= { dot3EponMpcpObjects 1 } dot3MpcpControlEntry OBJECT-TYPE SYNTAX Dot3MpcpControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot3 MPCP Control table. Rows exist for an OLT interface and an ONU interface. A row in the table is denoted by the ifIndex of the link and it is created when the ifIndex is created. The rows in the table for an ONU interface are created at system initialization. The row in the table corresponding to the OLT ifIndex and the row corresponding to the broadcast virtual link are created at system initialization. A row in the table corresponding to the ifIndex of a virtual links is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex } ::= { dot3MpcpControlTable 1} Dot3MpcpControlEntry ::= SEQUENCE { dot3MpcpOperStatus TruthValue, dot3MpcpAdminState TruthValue, dot3MpcpMode INTEGER, dot3MpcpSyncTime Unsigned32, dot3MpcpLinkID Unsigned32, dot3MpcpRemoteMACAddress MacAddress, dot3MpcpRegistrationState INTEGER, dot3MpcpTransmitElapsed Unsigned32, dot3MpcpReceiveElapsed Unsigned32, dot3MpcpRoundTripTime Unsigned32, dot3MpcpMaximumPendingGrants Unsigned32 } dot3MpcpOperStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the operational state of the Multi-Point MAC Control sublayer as defined in Khermosh Standards Track [Page 36] RFC 4837 Managed Objects of EPON July 2007 [802.3ah], clause 64. When the value is true(1), the interface will act as if the Multi-Point Control Protocol is enabled. When the value is false(2), the interface will act as if the Multi-Point Control Protocol is disabled. The operational state can be changed using the dot3MpcpAdminState object. This object is applicable for an OLT, with the same value for all virtual interfaces, and for an ONU." REFERENCE "[802.3ah], 30.3.5.1.2." ::= { dot3MpcpControlEntry 1 } dot3MpcpAdminState OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to define the admin state of the Multi-Point MAC Control sublayer, as defined in [802.3ah], clause 64, and to reflect its state. When selecting the value as true(1), the Multi-Point Control Protocol of the interface is enabled. When selecting the value as false(2), the Multi-Point Control Protocol of the interface is disabled. This object reflects the administrative state of the Multi-Point Control Protocol of the interface. The write operation is not restricted in this document and can be done at any time. Changing dot3MpcpAdminState state can lead to disabling the Multi-Point Control Protocol on the respective interface, leading to the interruption of service for the users connected to the respective EPON interface. This object is applicable for an OLT, with the same value for all virtual interfaces, and for an ONU." REFERENCE "[802.3ah], 30.3.5.2.1." DEFVAL { false } ::= { dot3MpcpControlEntry 2 } dot3MpcpMode OBJECT-TYPE SYNTAX INTEGER { olt(1), onu(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to identify the operational state of the Multi-Point MAC Control sublayer as defined in [802.3ah], clause 64. Reading olt(1) for an Khermosh Standards Track [Page 37] RFC 4837 Managed Objects of EPON July 2007 OLT (server) mode and onu(2) for an ONU (client) mode. This object is used to identify the operational mode for the MPCP tables. This object is applicable for an OLT, with the same value for all virtual interfaces, and for an ONU." REFERENCE "[802.3ah], 30.3.5.1.3." DEFVAL { olt } ::= { dot3MpcpControlEntry 3 } dot3MpcpSyncTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "TQ (16nsec)" MAX-ACCESS read-only STATUS current DESCRIPTION "An object that reports the 'sync lock time' of the OLT receiver in increments of Time Quanta (TQ)-16ns as defined in [802.3ah], clauses 60, 64, and 65. The value returned shall be (sync lock time ns)/16. If this value exceeds (2^32-1), the value (2^32-1) shall be returned. This object is applicable for an OLT, with the same value for all virtual interfaces, and for an ONU." REFERENCE "[802.3ah], 64.3.3.2." ::= { dot3MpcpControlEntry 4 } dot3MpcpLinkID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "An object that identifies the Logical Link Identifier (LLID) associated with the MAC of the virtual link as specified in [802.3ah], clause 65.1.3.2.2. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The ONU and the corresponding virtual MAC of the OLT, for the same virtual link, have the same value. Value is assigned when the ONU registers. Value is freed when the ONU deregisters." REFERENCE "[802.3ah], 30.3.5.1.4." ::= { dot3MpcpControlEntry 5 } dot3MpcpRemoteMACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION Khermosh Standards Track [Page 38] RFC 4837 Managed Objects of EPON July 2007 "An object that identifies the source_address parameter of the last MPCPDUs passed to the MAC Control. This value is updated on reception of a valid frame with 1) a destination Field equal to the reserved multicast address for MAC Control as specified in [802.3], Annex 31A; 2) the lengthOrType field value equal to the reserved Type for MAC Control as specified in [802.3], Annex 31A; 3) an MPCP subtype value equal to the subtype reserved for MPCP as specified in [802.3ah], Annex 31A. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The value reflects the MAC address of the remote entity and therefore the OLT holds a value for each LLID, which is the MAC address of the ONU; the ONU has a single value that is the OLT MAC address." REFERENCE "[802.3ah], 30.3.5.1.5." ::= { dot3MpcpControlEntry 6 } dot3MpcpRegistrationState OBJECT-TYPE SYNTAX INTEGER { unregistered(1), registering(2), registered(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An object that identifies the registration state of the Multi-Point MAC Control sublayer as defined in [802.3ah], clause 64. When this object has the enumeration unregistered(1), the interface is unregistered and may be used for registering a link partner. When this object has the enumeration registering(2), the interface is in the process of registering a link-partner. When this object has the enumeration registered(3), the interface has an established link-partner. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." REFERENCE "[802.3ah], 30.3.5.1.6." ::= { dot3MpcpControlEntry 7 } dot3MpcpTransmitElapsed OBJECT-TYPE SYNTAX Unsigned32 UNITS "TQ (16nsec)" MAX-ACCESS read-only STATUS current DESCRIPTION Khermosh Standards Track [Page 39] RFC 4837 Managed Objects of EPON July 2007 "An object that reports the interval from the last MPCP frame transmission in increments of Time Quanta (TQ)-16ns. The value returned shall be (interval from last MPCP frame transmission in ns)/16. If this value exceeds (2^32-1), the value (2^32-1) shall be returned. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." REFERENCE "[802.3ah], 30.3.5.1.19." ::= { dot3MpcpControlEntry 8 } dot3MpcpReceiveElapsed OBJECT-TYPE SYNTAX Unsigned32 UNITS "TQ (16nsec)" MAX-ACCESS read-only STATUS current DESCRIPTION "An object that reports the interval from last MPCP frame reception in increments of Time Quanta (TQ)-16ns. The value returned shall be (interval from last MPCP frame reception in ns)/16. If this value exceeds (2^32-1), the value (2^32-1) shall be returned. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." REFERENCE "[802.3ah], 30.3.5.1.20." ::= { dot3MpcpControlEntry 9 } dot3MpcpRoundTripTime OBJECT-TYPE SYNTAX Unsigned32 (0..'ffff'h) UNITS "TQ (16nsec)" MAX-ACCESS read-only STATUS current DESCRIPTION "An object that reports the MPCP round trip time in increments of Time Quanta (TQ)-16ns. The value returned shall be (round trip time in ns)/16. If this value exceeds (2^16-1), the value (2^16-1) shall be returned. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." REFERENCE "[802.3ah], 30.3.5.1.21." ::= { dot3MpcpControlEntry 10 } dot3MpcpMaximumPendingGrants OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "An object that reports the maximum number of grants that an ONU can store for handling. The maximum number Khermosh Standards Track [Page 40] RFC 4837 Managed Objects of EPON July 2007 of grants that an ONU can store for handling has a range of 0 to 255. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero." REFERENCE "[802.3ah], 30.3.5.1.24." ::= { dot3MpcpControlEntry 11 } dot3MpcpStatTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3MpcpStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the list of statistics counters of an interface implementing the [802.3ah], clause 64 MPCP. Each object has a row for every virtual link denoted by the corresponding ifIndex. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff)." ::= { dot3EponMpcpObjects 2 } dot3MpcpStatEntry OBJECT-TYPE SYNTAX Dot3MpcpStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table of statistics counters of the [802.3ah], clause 64, MPCP interface. Rows exist for an OLT interface and an ONU interface. A row in the table is denoted by the ifIndex of the link and it is created when the ifIndex is created. The rows in the table for an ONU interface are created at system initialization. The row in the table corresponding to the OLT ifIndex and the row corresponding to the broadcast virtual link are created at system initialization. A row in the table corresponding to the ifIndex of a virtual link is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex} ::= { dot3MpcpStatTable 1 } Dot3MpcpStatEntry ::= Khermosh Standards Track [Page 41] RFC 4837 Managed Objects of EPON July 2007 SEQUENCE { dot3MpcpMACCtrlFramesTransmitted Counter64, dot3MpcpMACCtrlFramesReceived Counter64, dot3MpcpDiscoveryWindowsSent Counter32, dot3MpcpDiscoveryTimeout Counter32, dot3MpcpTxRegRequest Counter64, dot3MpcpRxRegRequest Counter64, dot3MpcpTxRegAck Counter64, dot3MpcpRxRegAck Counter64, dot3MpcpTxReport Counter64, dot3MpcpRxReport Counter64, dot3MpcpTxGate Counter64, dot3MpcpRxGate Counter64, dot3MpcpTxRegister Counter64, dot3MpcpRxRegister Counter64 } dot3MpcpMACCtrlFramesTransmitted OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of MPCP frames passed to the MAC sublayer for transmission. This counter is incremented when a MA_CONTROL.request service primitive is generated within the MAC control sublayer with an opcode indicating an MPCP frame. This object is applicable for an OLT and an ONU. At the OLT it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.7." ::= { dot3MpcpStatEntry 1 } dot3MpcpMACCtrlFramesReceived OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of MPCP frames passed by the MAC sublayer to the MAC Control sublayer. This counter is incremented when a ReceiveFrame function call returns a valid frame with 1) a lengthOrType field value equal to the reserved Khermosh Standards Track [Page 42] RFC 4837 Managed Objects of EPON July 2007 Type for 802.3_MAC_Control as specified in clause 31.4.1.3, and 2) an opcode indicating an MPCP frame. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.8." ::= { dot3MpcpStatEntry 2} dot3MpcpDiscoveryWindowsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of discovery windows generated. The counter is incremented by one for each generated discovery window. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the ONU, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.22." ::= { dot3MpcpStatEntry 3} dot3MpcpDiscoveryTimeout OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a discovery timeout occurs. Increment the counter by one for each discovery processing state-machine reset resulting from timeout waiting for message arrival. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.23." Khermosh Standards Track [Page 43] RFC 4837 Managed Objects of EPON July 2007 ::= { dot3MpcpStatEntry 4} dot3MpcpTxRegRequest OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a REGISTER_REQ MPCP frame transmission occurs. Increment the counter by one for each REGISTER_REQ MPCP frame transmitted as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.12." ::= { dot3MpcpStatEntry 5} dot3MpcpRxRegRequest OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a REGISTER_REQ MPCP frame reception occurs. Increment the counter by one for each REGISTER_REQ MPCP frame received as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the ONU, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.17." ::= { dot3MpcpStatEntry 6} dot3MpcpTxRegAck OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only Khermosh Standards Track [Page 44] RFC 4837 Managed Objects of EPON July 2007 STATUS current DESCRIPTION "A count of the number of times a REGISTER_ACK MPCP frame transmission occurs. Increment the counter by one for each REGISTER_ACK MPCP frame transmitted as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.10." ::= { dot3MpcpStatEntry 7} dot3MpcpRxRegAck OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a REGISTER_ACK MPCP frame reception occurs. Increment the counter by one for each REGISTER_ACK MPCP frame received as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the ONU, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.15." ::= { dot3MpcpStatEntry 8} dot3MpcpTxReport OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a REPORT MPCP frame transmission occurs. Increment the counter by one for each REPORT MPCP frame transmitted as defined in [802.3ah], clause 64. Khermosh Standards Track [Page 45] RFC 4837 Managed Objects of EPON July 2007 This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.13." ::= { dot3MpcpStatEntry 9} dot3MpcpRxReport OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a REPORT MPCP frame reception occurs. Increment the counter by one for each REPORT MPCP frame received as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the ONU, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.18." ::= { dot3MpcpStatEntry 10} dot3MpcpTxGate OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a GATE MPCP frame transmission occurs. Increment the counter by one for each GATE MPCP frame transmitted as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the ONU, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the Khermosh Standards Track [Page 46] RFC 4837 Managed Objects of EPON July 2007 ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.9." ::= { dot3MpcpStatEntry 11} dot3MpcpRxGate OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a GATE MPCP frame reception occurs. Increment the counter by one for each GATE MPCP frame received as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.14." ::= { dot3MpcpStatEntry 12} dot3MpcpTxRegister OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a REGISTER MPCP frame transmission occurs. Increment the counter by one for each REGISTER MPCP frame transmitted as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the ONU, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.11." ::= { dot3MpcpStatEntry 13} dot3MpcpRxRegister OBJECT-TYPE Khermosh Standards Track [Page 47] RFC 4837 Managed Objects of EPON July 2007 SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a REGISTER MPCP frame reception occurs. Increment the counter by one for each REGISTER MPCP frame received as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.5.1.16." ::= { dot3MpcpStatEntry 14} -- Optical Multi Point Emulation (OMPEmulation) -- managed object definitions dot3OmpEmulationObjects OBJECT IDENTIFIER ::={dot3EponObjects 2} dot3OmpEmulationTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OmpEmulationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of dot3 OmpEmulation MIB objects. The table contain objects for the management of the OMPEmulation sublayer. Each object has a row for every virtual link denoted by the corresponding ifIndex. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff)." ::= { dot3OmpEmulationObjects 1 } dot3OmpEmulationEntry OBJECT-TYPE SYNTAX Dot3OmpEmulationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Khermosh Standards Track [Page 48] RFC 4837 Managed Objects of EPON July 2007 "An entry in the dot3 OmpEmulation table. Rows exist for an OLT interface and an ONU interface. A row in the table is denoted by the ifIndex of the link and it is created when the ifIndex is created. The rows in the table for an ONU interface are created at system initialization. The row in the table corresponding to the OLT ifIndex and the row corresponding to the broadcast virtual link are created at system initialization. A row in the table corresponding to the ifIndex of a virtual links is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex } ::= { dot3OmpEmulationTable 1 } Dot3OmpEmulationEntry ::= SEQUENCE { dot3OmpEmulationType INTEGER } dot3OmpEmulationType OBJECT-TYPE SYNTAX INTEGER { unknown(1), olt(2), onu(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An object that indicates the mode of operation of the Reconciliation Sublayer for Point-to-Point Emulation (see [802.3ah], clause 65.1). unknown(1) value is assigned in initialization; true state or type is not yet known. olt(2) value is assigned when the sublayer is operating in OLT mode. onu(3) value is assigned when the sublayer is operating in ONU mode. This object is applicable for an OLT, with the same value for all virtual interfaces, and for an ONU." REFERENCE "[802.3ah], 30.3.7.1.2." ::= { dot3OmpEmulationEntry 1} dot3OmpEmulationStatTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OmpEmulationStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the list of statistics counters of Khermosh Standards Track [Page 49] RFC 4837 Managed Objects of EPON July 2007 [802.3ah], clause 65, OMPEmulation sublayer. Each object has a row for every virtual link denoted by the corresponding ifIndex. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff)." ::= { dot3OmpEmulationObjects 2} dot3OmpEmulationStatEntry OBJECT-TYPE SYNTAX Dot3OmpEmulationStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table of statistics counters of [802.3ah], clause 65, OMPEmulation sublayer. Rows exist for an OLT interface and an ONU interface. A row in the table is denoted by the ifIndex of the link and it is created when the ifIndex is created. The rows in the table for an ONU interface are created at system initialization. The row in the table corresponding to the OLT ifIndex and the row corresponding to the broadcast virtual link are created at system initialization. A row in the table corresponding to the ifIndex of a virtual links is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex} ::= { dot3OmpEmulationStatTable 1 } Dot3OmpEmulationStatEntry::= SEQUENCE { dot3OmpEmulationSLDErrors Counter64, dot3OmpEmulationCRC8Errors Counter64, dot3OmpEmulationBadLLID Counter64, dot3OmpEmulationGoodLLID Counter64, dot3OmpEmulationOnuPonCastLLID Counter64, dot3OmpEmulationOltPonCastLLID Counter64, dot3OmpEmulationBroadcastBitNotOnuLlid Counter64, dot3OmpEmulationOnuLLIDNotBroadcast Counter64, dot3OmpEmulationBroadcastBitPlusOnuLlid Counter64, dot3OmpEmulationNotBroadcastBitNotOnuLlid Counter64 } dot3OmpEmulationSLDErrors OBJECT-TYPE Khermosh Standards Track [Page 50] RFC 4837 Managed Objects of EPON July 2007 SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that do not contain a valid SLD field as defined in [802.3ah], clause 65.1.3.3.1. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.7.1.3." ::= { dot3OmpEmulationStatEntry 1} dot3OmpEmulationCRC8Errors OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, but do not pass the CRC-8 check as defined in [802.3ah], clause 65.1.3.3.3. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.7.1.4." ::= { dot3OmpEmulationStatEntry 2} dot3OmpEmulationBadLLID OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, and pass the CRC-8 check, as defined in [802.3ah], clause 65.1.3.3.3, but are discarded due to the LLID check as defined in [802.3ah], clause 65.1.3.3.2. Khermosh Standards Track [Page 51] RFC 4837 Managed Objects of EPON July 2007 This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.7.1.8." ::= { dot3OmpEmulationStatEntry 3} dot3OmpEmulationGoodLLID OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, and pass the CRC-8 check as defined in [802.3ah], clause 65.1.3.3.3. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.7.1.5." ::= { dot3OmpEmulationStatEntry 4} dot3OmpEmulationOnuPonCastLLID OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, pass the CRC-8 check, as defined in [802.3ah], clause 65.1.3.3.3, and meet the rules of acceptance for an ONU defined in [802.3ah], clause 65.1.3.3.2. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB Khermosh Standards Track [Page 52] RFC 4837 Managed Objects of EPON July 2007 module." REFERENCE "[802.3ah], 30.3.7.1.6." ::= { dot3OmpEmulationStatEntry 5} dot3OmpEmulationOltPonCastLLID OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, pass the CRC-8 check, as defined in [802.3ah], clause 65.1.3.3.3, and meet the rules of acceptance for an OLT defined in [802.3ah], 65.1.3.3.2. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the ONU, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.3.7.1.7." ::= { dot3OmpEmulationStatEntry 6} dot3OmpEmulationBroadcastBitNotOnuLlid OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, pass the CRC-8 check, as defined in [802.3ah], clause 65.1.3.3.3, and contain the broadcast bit in the LLID and not the ONU's LLID (frame accepted) as defined in [802.3ah], clause 65. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3OmpEmulationStatEntry 7} Khermosh Standards Track [Page 53] RFC 4837 Managed Objects of EPON July 2007 dot3OmpEmulationOnuLLIDNotBroadcast OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, pass the CRC-8 check, as defined in [802.3ah], clause 65.1.3.3.3, and contain the ONU's LLID as defined in [802.3ah], clause 65. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3OmpEmulationStatEntry 8} dot3OmpEmulationBroadcastBitPlusOnuLlid OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, pass the CRC-8 check, as defined in [802.3ah], clause 65.1.3.3.3, and contain the broadcast bit in the LLID and match the ONU's LLID (frame reflected) as defined in [802.3ah], clause 65. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3OmpEmulationStatEntry 9} dot3OmpEmulationNotBroadcastBitNotOnuLlid OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current Khermosh Standards Track [Page 54] RFC 4837 Managed Objects of EPON July 2007 DESCRIPTION "A count of frames received that contain a valid SLD field, as defined in [802.3ah], clause 65.1.3.3.1, pass the CRC-8 check, as defined in [802.3ah], clause 65.1.3.3.3, and do not contain the ONU's LLID as defined in [802.3ah], clause 65. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3OmpEmulationStatEntry 10} -- FEC managed object definitions (30.5.1) dot3EponFecObjects OBJECT IDENTIFIER ::={dot3EponObjects 3} dot3EponFecTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3EponFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of dot3 EPON FEC management objects. The entries in the table are control and status objects and statistic counters for the FEC layer. Each object has a row for every virtual link denoted by the corresponding ifIndex. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff)." ::= { dot3EponFecObjects 1 } dot3EponFecEntry OBJECT-TYPE SYNTAX Dot3EponFecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot3 EPON FEC table. Rows exist for an OLT interface and an ONU interface. A row in the table is denoted by the ifIndex of the link and it is created when the ifIndex is created. The rows in the table for an ONU interface are created Khermosh Standards Track [Page 55] RFC 4837 Managed Objects of EPON July 2007 at system initialization. The row in the table corresponding to the OLT ifIndex and the row corresponding to the broadcast virtual link are created at system initialization. A row in the table corresponding to the ifIndex of a virtual links is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex} ::= { dot3EponFecTable 1 } Dot3EponFecEntry ::= SEQUENCE { dot3EponFecPCSCodingViolation Counter64, dot3EponFecAbility INTEGER, dot3EponFecMode INTEGER, dot3EponFecCorrectedBlocks Counter64, dot3EponFecUncorrectableBlocks Counter64, dot3EponFecBufferHeadCodingViolation Counter64 } dot3EponFecPCSCodingViolation OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "For a 100 Mbps operation, it is a count of the number of times an invalid code-group is received, other than the /H/ code-group. For a 1000 Mbps operation, it is a count of the number of times an invalid codegroup is received, other than the /V/ code-group. /H/ denotes a special 4b5b codeword of [802.3] 100 Mbps PCS layer (clause 24), and /V/ denotes a special 8b10b codeword of the [802.3] 1000 Mbps PCS layer (clause 36). This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.5.1.1.12." ::= { dot3EponFecEntry 1} dot3EponFecAbility OBJECT-TYPE SYNTAX INTEGER { unknown(1), Khermosh Standards Track [Page 56] RFC 4837 Managed Objects of EPON July 2007 supported(2), unsupported(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An object that indicates the support of operation of the optional FEC sublayer of the 1000BASE-PX PHY specified in [802.3ah], clause 65.2. unknown(1) value is assigned in the initialization, for non FEC support state or type not yet known. unsupported(3) value is assigned when the sublayer is not supported. supported(2) value is assigned when the sublayer is supported. This object is applicable for an OLT, with the same value for all virtual interfaces, and for an ONU. The FEC counters will have a zero value when the interface is not supporting FEC. The counters: dot3EponFecPCSCodingViolation - not affected by FEC ability. dot3EponFecCorrectedBlocks - has a zero value when dot3EponFecAbility is unknown(1) and unsupported(3). dot3EponFecUncorrectableBlocks - has a zero value when dot3EponFecAbility is unknown(1) and unsupported(3). dot3EponFecBufferHeadCodingViolation - has a zero value when dot3EponFecAbility is unknown(1) and unsupported(3)." REFERENCE "[802.3ah], 30.5.1.1.13." ::= { dot3EponFecEntry 2} dot3EponFecMode OBJECT-TYPE SYNTAX INTEGER { unknown(1), disabled(2), enabled(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "An object that defines the mode of operation of the optional FEC sublayer of the 1000BASE-PX PHY, specified in [802.3ah], clause 65.2, and reflects its state. A GET operation returns the current mode of operation of the PHY. A SET operation changes the mode of operation of the PHY to the indicated value. unknown(1) value is assigned in the initialization for non FEC support state or type not yet known. Khermosh Standards Track [Page 57] RFC 4837 Managed Objects of EPON July 2007 disabled(2) value is assigned when the FEC sublayer is operating in disabled mode. enabled(3) value is assigned when the FEC sublayer is operating in FEC mode. The write operation is not restricted in this document and can be done at any time. Changing dot3EponFecMode state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The counting of the FEC counters will stop when the FEC of the interface is disabled. The counters: dot3EponFecPCSCodingViolation - not affected by FEC mode. dot3EponFecCorrectedBlocks - stops counting when Rx_FEC is not enabled. (unknown(1) and disabled(2)). dot3EponFecUncorrectableBlocks - stops counting when Rx_FEC is not enabled (unknown(1) and disabled(2)). dot3EponFecBufferHeadCodingViolation - stops counting when Rx_FEC is not enabled (unknown(1) and disabled(2)). The object: dot3EponFecAbility - indicates the FEC ability and is not affected by the dot3EponFecMode object." REFERENCE "[802.3ah], 30.5.1.1.14." DEFVAL { unknown } ::= { dot3EponFecEntry 3} dot3EponFecCorrectedBlocks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "For 10PASS-TS, 2BASE-TL, and 1000BASE-PX PHYs, it is a count of corrected FEC blocks. This counter will not increment for other PHY Types. Increment the counter by one for each received block that is corrected by the FEC function in the PHY. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the Khermosh Standards Track [Page 58] RFC 4837 Managed Objects of EPON July 2007 ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.5.1.1.15." ::= { dot3EponFecEntry 4} dot3EponFecUncorrectableBlocks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "For 10PASS-TS, 2BASE-TL, and 1000BASE-PX PHYs, it is a count of uncorrectable FEC blocks. This counter will not increment for other PHY Types. Increment the counter by one for each FEC block that is determined to be uncorrectable by the FEC function in the PHY. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." REFERENCE "[802.3ah], 30.5.1.1.16." ::= { dot3EponFecEntry 5} dot3EponFecBufferHeadCodingViolation OBJECT-TYPE SYNTAX Counter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "For a 1000 Mbps operation, it is a count of the number of invalid code-group received directly from the link. The value has a meaning only in 1000 Mbps mode and it is zero otherwise. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3EponFecEntry 6} -- ExtendedPackage managed object definitions dot3ExtPkgObjects OBJECT IDENTIFIER ::={dot3EponObjects 4} Khermosh Standards Track [Page 59] RFC 4837 Managed Objects of EPON July 2007 dot3ExtPkgControlObjects OBJECT IDENTIFIER ::= { dot3ExtPkgObjects 1} dot3ExtPkgControlTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Extended package Control management objects. Entries in the table are control and status indication objects of an EPON interface, which are gathered in an extended package as an addition to the objects based on the [802.3ah], clause 30, attributes. Each object has a row for every virtual link denoted by the corresponding ifIndex. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff)." ::= { dot3ExtPkgControlObjects 1 } dot3ExtPkgControlEntry OBJECT-TYPE SYNTAX Dot3ExtPkgControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Extended package Control table. Rows exist for an OLT interface and an ONU interface. A row in the table is denoted by the ifIndex of the link and it is created when the ifIndex is created. The rows in the table for an ONU interface are created at system initialization. The row in the table corresponding to the OLT ifIndex and the row corresponding to the broadcast virtual link are created at system initialization. A row in the table corresponding to the ifIndex of a virtual links is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex} ::= { dot3ExtPkgControlTable 1 } Dot3ExtPkgControlEntry ::= SEQUENCE { dot3ExtPkgObjectReset INTEGER, dot3ExtPkgObjectPowerDown TruthValue, dot3ExtPkgObjectNumberOfLLIDs Unsigned32, Khermosh Standards Track [Page 60] RFC 4837 Managed Objects of EPON July 2007 dot3ExtPkgObjectFecEnabled INTEGER, dot3ExtPkgObjectReportMaximumNumQueues Unsigned32, dot3ExtPkgObjectRegisterAction INTEGER } dot3ExtPkgObjectReset OBJECT-TYPE SYNTAX INTEGER { running(1), reset(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to reset the EPON interface. The interface may be unavailable while the reset occurs and data may be lost. Setting this object to running(1) will cause the interface to enter into running mode. Setting this object to reset(2) will cause the interface to go into reset mode. When getting running(1), the interface is in running mode. When getting reset(2), the interface is in reset mode. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectReset state can lead to a reset of the respective interface, leading to an interruption of service for the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. A reset for a specific virtual interface resets only this virtual interface and not the physical interface. Thus, a virtual link that is malfunctioning can be reset without affecting the operation of other virtual interfaces. The reset can cause Discontinuities in the values of the counters of the interface, similar to re-initialization of the management system. Discontinuity should be indicated by the ifCounterDiscontinuityTime object of the Interface MIB module." DEFVAL { running } ::= { dot3ExtPkgControlEntry 1 } dot3ExtPkgObjectPowerDown OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION Khermosh Standards Track [Page 61] RFC 4837 Managed Objects of EPON July 2007 "This object is used to power down the EPON interface. The interface may be unavailable while the power down occurs and data may be lost. Setting this object to true(1) will cause the interface to enter into power down mode. Setting this object to false(2) will cause the interface to go out of power down mode. When getting true(1), the interface is in power down mode. When getting false(2), the interface is not in power down mode. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectPowerDown state can lead to a power down of the respective interface, leading to an interruption of service of the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. A power down/up of a specific virtual interface affects only the virtual interface and not the physical interface. Hence a virtual link, which needs a certain handling, can be powered down and then powered up without disrupting the operation of other virtual interfaces. The object is relevant when the admin state of the interface is active as set by the dot3MpcpAdminState." DEFVAL { false } ::= { dot3ExtPkgControlEntry 2 } dot3ExtPkgObjectNumberOfLLIDs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A read only object that indicates the number of registered LLIDs. The initialization value is 0. This object is applicable for an OLT with the same value for all virtual interfaces and for an ONU. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff). At the ONU the number of LLIDs for an interface is one." ::= { dot3ExtPkgControlEntry 3 } dot3ExtPkgObjectFecEnabled OBJECT-TYPE SYNTAX INTEGER { noFecEnabled(1), Khermosh Standards Track [Page 62] RFC 4837 Managed Objects of EPON July 2007 fecTxEnabled(2), fecRxEnabled(3), fecTxRxEnabled(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "An object defining the FEC mode of operation of the interface, and indicating its state. The modes defined in this object are extensions to the FEC modes defined in the dot3EponFecMode object. When noFECEnabled(1), the interface does not enable FEC mode. When fecTxEnabled(2), the interface enables the FEC transmit mode. When fecRxEnabled(3), the interface enables the FEC receive mode. When fecTxRxEnabled(4), the interface enables the FEC transmit and receive mode. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The FEC counters are referring to the receive path. The FEC counters will stop when the FEC receive mode of the interface is disabled, as defined by fecRxEnabled(3) and fecTxRxEnabled(4) values. The counters: dot3EponFecPCSCodingViolation - not affected by FEC mode. dot3EponFecCorrectedBlocks - stops counting when Rx_FEC is not enabled (noFecEnabled(1) and fecTxEnabled(2)). dot3EponFecUncorrectableBlocks - stops counting when Rx_FEC is not enabled (noFecEnabled(1) and fecTxEnabled(2)). dot3EponFecBufferHeadCodingViolation - stops counting when Rx_FEC is not enabled (noFecEnabled(1) and fecTxEnabled(2)). The objects: dot3EponFecAbility - indicates the FEC ability and is not affected by the FEC mode. dot3EponFecMode - indicates the FEC mode for combined RX and TX. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectFecEnabled state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the Khermosh Standards Track [Page 63] RFC 4837 Managed Objects of EPON July 2007 users connected to the respective EPON interface." DEFVAL { noFecEnabled } ::= { dot3ExtPkgControlEntry 4 } dot3ExtPkgObjectReportMaximumNumQueues OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "An object, that defines the maximal number of queues in the REPORT message as defined in [802.3ah], clause 64. For further information please see the description of the queue table. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." DEFVAL { 0 } ::= { dot3ExtPkgControlEntry 5 } dot3ExtPkgObjectRegisterAction OBJECT-TYPE SYNTAX INTEGER { none(1), register(2), deregister(3), reregister(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "An object configuring the registration state of an interface, and indicating its registration state. Write operation changes the registration state to its new value. Read operation returns the value of the state. The registration state is reflected in this object and in the dot3MpcpRegistrationState object. none(1) indicates an unknown state, register(2) indicates a registered LLID, deregister(3) indicates a deregistered LLID, reregister(4) indicates an LLID that is reregistering. The following list describes the operation of the interface, as specified in the [802.3ah], when a write operation is setting a value. none(1) - not doing any action. register(2) - registering an LLID that has been requested for registration (The LLID is in registering mode. dot3MpcpRegistrationState - registering(2) ). deregister(3) - deregisters an LLID that is registered (dot3MpcpRegistrationState - registered(3) ). Khermosh Standards Track [Page 64] RFC 4837 Managed Objects of EPON July 2007 reregister(4) - reregister an LLID that is registered (dot3MpcpRegistrationState - registered(3) ). The behavior of an ONU and OLT interfaces, at each one of the detailed operation at each state, is described in the registration state machine of figure 64-22, [802.3ah]. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectRegisterAction state can lead to a change in the registration state of the respective interface leading to a deregistration and an interruption of service of the users connected to the respective EPON interface." DEFVAL { none } ::= { dot3ExtPkgControlEntry 6 } dot3ExtPkgQueueTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgQueueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the extended package objects for queue management. The [802.3ah] MPCP defines a report message of the occupancy of the transmit queues for the feedback BW request from the ONUs. These queues serve the uplink transmission of the ONU and data is gathered there until the ONU is granted for transmission. The management table of the queues is added here mainly to control the reporting and to gather some statistics of their operation. This table is not duplicating existing management objects of bridging queues, specified in [802.1d], since the existence of a dedicated transmit queuing mechanism is implied in the [802.3ah], and the ONU may be a device that is not a bridge with embedded bridging queues. The format of the REPORT message, as specified in [802.3], is presented below: +-----------------------------------+ | Destination Address | +-----------------------------------+ | Source Address | +-----------------------------------+ | Length/Type | +-----------------------------------+ | OpCode | +-----------------------------------+ Khermosh Standards Track [Page 65] RFC 4837 Managed Objects of EPON July 2007 | TimeStamp | +-----------------------------------+ | Number of queue Sets | +-----------------------------------+ /|\ | Report bitmap | | +-----------------------------------+ | | Queue 0 report | | +-----------------------------------+ | repeated for | Queue 1 report | | every +-----------------------------------+ | queue_set | Queue 2 report | | +-----------------------------------+ | | Queue 3 report | | +-----------------------------------+ | | Queue 4 report | | +-----------------------------------+ | | Queue 5 report | | +-----------------------------------+ | | Queue 6 report | | +-----------------------------------+ | | Queue 7 report | | +-----------------------------------+ \|/ | Pad/reserved | +-----------------------------------+ | FCS | +-----------------------------------+ The 'Queue report' field reports the occupancy of each uplink transmission queue. The number of queue sets defines the number of the reported sets, as would be explained in the description of the dot3ExtPkgQueueSetsTable table. For each set the report bitmap defines which queue is present in the report, meaning that although the MPCP REPORT message can report up to 8 queues in a REPORT message, the actual number is flexible. The Queue table has a variable size that is limited by the dot3ExtPkgObjectReportMaximumNumQueues object, as an ONU can have fewer queues to report. The entries in the table are control and status indication objects for managing the queues of an EPON interface that are gathered in an extended package as an addition to the objects that are based on the [802.3ah] attributes. Each object has a row for every virtual link and for every queue in the report. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the Khermosh Standards Track [Page 66] RFC 4837 Managed Objects of EPON July 2007 number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff). The number of queues is between 0 and 7 and limited by dot3ExtPkgObjectReportMaximumNumQueues." ::= { dot3ExtPkgControlObjects 2 } dot3ExtPkgQueueEntry OBJECT-TYPE SYNTAX Dot3ExtPkgQueueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Extended package Queue table. At the OLT, the rows exist for each ifIndex and dot3QueueIndex. At the ONU, rows exist for the single ifIndex for each dot3QueueIndex. Rows in the table are created when the ifIndex of the link is created. A set of rows per queue are added for each ifIndex, denoted by the dot3QueueIndex. A set of rows per queue in the table, for an ONU interface, are created at the system initialization. A set of rows per queue in the table, corresponding to the OLT ifIndex and a set of rows per queue corresponding to the broadcast virtual link, are created at the system initialization. A set of rows per queue in the table, corresponding to the ifIndex of a virtual link, are created when the virtual link is established (ONU registers), and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex, dot3QueueIndex } ::= { dot3ExtPkgQueueTable 1 } Dot3ExtPkgQueueEntry ::= SEQUENCE { dot3QueueIndex Unsigned32, dot3ExtPkgObjectReportNumThreshold Unsigned32, dot3ExtPkgObjectReportMaximumNumThreshold Unsigned32, dot3ExtPkgStatTxFramesQueue Counter64, dot3ExtPkgStatRxFramesQueue Counter64, dot3ExtPkgStatDroppedFramesQueue Counter64 } dot3QueueIndex OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS not-accessible STATUS current DESCRIPTION Khermosh Standards Track [Page 67] RFC 4837 Managed Objects of EPON July 2007 "An object that identifies an index for the queue table reflecting the queue index of the queues that are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The number of queues is between 0 and 7, and limited by dot3ExtPkgObjectReportMaximumNumQueues." ::= { dot3ExtPkgQueueEntry 1 } dot3ExtPkgObjectReportNumThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-write STATUS current DESCRIPTION "An object that defines the number of thresholds for each queue in the REPORT message as defined in [802.3ah], clause 64. Each queue_set reporting will provide information on the queue occupancy of frames below the matching Threshold. Read operation reflects the number of thresholds. Write operation sets the number of thresholds for each queue. The write operation is not restricted in this document and can be done at any time. Value cannot exceed the maximal value defined by the dot3ExtPkgObjectReportMaximumNumThreshold object. Changing dot3ExtPkgObjectReportNumThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service of the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface and for each queue. At the ONU, it has a distinct value for each queue." DEFVAL { 0 } ::= { dot3ExtPkgQueueEntry 2 } dot3ExtPkgObjectReportMaximumNumThreshold OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "An object, that defines the maximal number of thresholds for each queue in the REPORT message as defined in [802.3ah], clause 64. Each queue_set reporting will provide information on the queue occupancy of frames below the matching Threshold. Khermosh Standards Track [Page 68] RFC 4837 Managed Objects of EPON July 2007 This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface and for each queue. At the ONU, it has a distinct value for each queue." DEFVAL { 0 } ::= { dot3ExtPkgQueueEntry 3 } dot3ExtPkgStatTxFramesQueue OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a frame transmission occurs from the corresponding 'Queue'. Increment the counter by one for each frame transmitted, which is an output of the 'Queue'. The 'Queue' marking matches the REPORT MPCP message Queue field as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface and for each queue. At the ONU, it has a distinct value for each queue. At the OLT the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3ExtPkgQueueEntry 4} dot3ExtPkgStatRxFramesQueue OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a frame reception occurs from the corresponding 'Queue'. Increment the counter by one for each frame received, which is an input to the corresponding 'Queue'. The 'Queue' marking matches the REPORT MPCP message Queue field as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface and for each queue. At the ONU, it has a distinct value for each queue. Discontinuities of this counter can occur at Khermosh Standards Track [Page 69] RFC 4837 Managed Objects of EPON July 2007 re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3ExtPkgQueueEntry 5} dot3ExtPkgStatDroppedFramesQueue OBJECT-TYPE SYNTAX Counter64 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times a frame drop occurs from the corresponding 'Queue'. Increment the counter by one for each frame dropped from the corresponding 'Queue'. The 'Queue' marking matches the REPORT MPCP message Queue field as defined in [802.3ah], clause 64. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface and for each queue. At the ONU, it has a distinct value for each queue. At the OLT, the value should be zero. Discontinuities of this counter can occur at re-initialization of the management system and at other times, as indicated by the value of the ifCounterDiscontinuityTime object of the Interface MIB module." ::= { dot3ExtPkgQueueEntry 6} dot3ExtPkgQueueSetsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgQueueSetsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Extended package objects used for the management of the queue_sets. Entries are control and status indication objects of an EPON interface, which are gathered in an extended package as an addition to the objects based on the [802.3ah] attributes. The objects in this table are specific for the queue_sets, which are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The [802.3ah] MPCP defines a report message of the occupancy of the transmit queues for the feedback BW request from the ONUs. These queues serve the uplink transmission of the ONU and data is gathered there until the ONU is granted for transmission. Khermosh Standards Track [Page 70] RFC 4837 Managed Objects of EPON July 2007 The management table of the queues_sets is added here mainly to control the reporting and to gather some statistics of their operation. This table is not duplicating existing management objects of bridging queues, specified in [802.1d], since the existence of a dedicated transmit queuing mechanism is implied in the [802.3ah], and the ONU may be a device that is not a bridge with embedded bridging queues. The format of the REPORT message, as specified in [802.3], is presented below: +-----------------------------------+ | Destination Address | +-----------------------------------+ | Source Address | +-----------------------------------+ | Length/Type | +-----------------------------------+ | OpCode | +-----------------------------------+ | TimeStamp | +-----------------------------------+ | Number of queue Sets | +-----------------------------------+ /|\ | Report bitmap | | +-----------------------------------+ | | Queue 0 report | | +-----------------------------------+ | repeated for | Queue 1 report | | every +-----------------------------------+ | queue_set | Queue 2 report | | +-----------------------------------+ | | Queue 3 report | | +-----------------------------------+ | | Queue 4 report | | +-----------------------------------+ | | Queue 5 report | | +-----------------------------------+ | | Queue 6 report | | +-----------------------------------+ | | Queue 7 report | | +-----------------------------------+ \|/ | Pad/reserved | +-----------------------------------+ | FCS | +-----------------------------------+ As can be seen from the message format, the ONU interface reports of the status of up to 8 queues Khermosh Standards Track [Page 71] RFC 4837 Managed Objects of EPON July 2007 and it can report in a single MPCP REPORT message of a few sets of queues. The number of queue_sets defines the number of the reported sets, and it can reach a value of up to 8. It means that an ONU can hold a variable number of sets between 0 and 7. The dot3ExtPkgQueueSetsTable table has a variable queue_set size that is limited by the dot3ExtPkgObjectReportMaximumNumThreshold object as an ONU can have fewer queue_sets to report. The 'Queue report' field reports the occupancy of each uplink transmission queue. The queue_sets can be used to report the occupancy of the queues in a few levels as to allow granting, in an accurate manner, of only part of the data available in the queues. A Threshold is defined for each queue_set to define the level of the queue that is counted for the report of the occupancy. The threshold is reflected in the queue_set table by the dot3ExtPkgObjectReportThreshold object. For each queue set, the report bitmap defines which queues are present in the report, meaning that although the MPCP REPORT message can report of up to 8 queues in a REPORT message, the actual number is flexible. The dot3ExtPkgQueueSetsTable table has a variable queue size that is limited by the dot3ExtPkgObjectReportMaximumNumQueues object as an ONU can have fewer queues to report. Each object has a row for every virtual link, for each queue in the report and for each queue_set in the queue. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff). The number of queues is between 0 and 7 and limited by dot3ExtPkgObjectReportMaximumNumQueues. The number of queues_sets is between 0 and 7 and limited by dot3ExtPkgObjectReportMaximumNumThreshold." ::= { dot3ExtPkgControlObjects 3 } dot3ExtPkgQueueSetsEntry OBJECT-TYPE SYNTAX Dot3ExtPkgQueueSetsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Extended package queue_set table. At Khermosh Standards Track [Page 72] RFC 4837 Managed Objects of EPON July 2007 the OLT, the rows exist for each ifIndex, dot3QueueSetQueueIndex and dot3QueueSetIndex. At the ONU, rows exist for the single ifIndex, for each dot3QueueSetQueueIndex and dot3QueueSetIndex. Rows in the table are created when the ifIndex of the link is created. A set of rows per queue and per queue_set are added for each ifIndex, denoted by dot3QueueSetIndex and dot3QueueSetQueueIndex. A set of rows per queue and per queue_set in the table, for an ONU interface are created at system initialization. A set of rows per queue and per queue_Set in the table, corresponding to the OLT ifIndex and a set of rows per queue and per queue_set, corresponding to the broadcast virtual link, are created at system initialization. A set of rows per queue and per queue_set in the table, corresponding to the ifIndex of a virtual link are created when the virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex, dot3QueueSetQueueIndex,dot3QueueSetIndex} ::= { dot3ExtPkgQueueSetsTable 1 } Dot3ExtPkgQueueSetsEntry ::= SEQUENCE { dot3QueueSetQueueIndex Unsigned32, dot3QueueSetIndex Unsigned32, dot3ExtPkgObjectReportThreshold Unsigned32 } dot3QueueSetQueueIndex OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An object that identifies the queue index for the dot3ExtPkgQueueSetsTable table. The queues are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The number of queues is between 0 and 7, and limited by dot3ExtPkgObjectReportMaximumNumQueues. Value corresponds to the dot3QueueIndex of the queue table." ::= { dot3ExtPkgQueueSetsEntry 1 } dot3QueueSetIndex OBJECT-TYPE SYNTAX Unsigned32 (0..7) Khermosh Standards Track [Page 73] RFC 4837 Managed Objects of EPON July 2007 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An object that identifies the queue_set index for the dot3ExtPkgQueueSetsTable table. The queues are reported in the MPCP REPORT message as defined in [802.3ah], clause 64. The number of queues_sets is between 0 and 7, and limited by dot3ExtPkgObjectReportMaximumNumThreshold." ::= { dot3ExtPkgQueueSetsEntry 2 } dot3ExtPkgObjectReportThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "TQ (16nsec)" MAX-ACCESS read-write STATUS current DESCRIPTION "An object that defines the value of a threshold report for each queue_set in the REPORT message as defined in [802.3ah], clause 64. The number of sets for each queue is dot3ExtPkgObjectReportNumThreshold. In the REPORT message, each queue_set reporting will provide information on the occupancy of the queues for frames below the matching Threshold. The value returned shall be in Time quanta (TQ), which is 16nsec or 2 octets increments. Read operation provides the threshold value. Write operation sets the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgObjectReportThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service for the users connected to the respective EPON interface. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface, for each queue and for each queue_set. At the ONU, it has a distinct value for each queue and for each queue_set." DEFVAL { 0 } ::= { dot3ExtPkgQueueSetsEntry 3 } --Optical Interface status tables dot3ExtPkgOptIfTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ExtPkgOptIfEntry MAX-ACCESS not-accessible Khermosh Standards Track [Page 74] RFC 4837 Managed Objects of EPON July 2007 STATUS current DESCRIPTION "This table defines the control and status indication objects for the optical interface of the EPON interface. Each object has a row for every virtual link denoted by the corresponding ifIndex. The LLID field, as defined in the [802.3ah], is a 2-byte register (15-bit field and a broadcast bit) limiting the number of virtual links to 32768. Typically the number of expected virtual links in a PON is like the number of ONUs, which is 32-64, plus an additional entry for broadcast LLID (with a value of 0xffff). Although the optical interface is a physical interface, there is a row in the table for each virtual interface. The reason for having a separate row for each virtual link is that the OLT has a separate link for each one of the ONUs. For instance, ONUs could be in different distances with different link budgets and different receive powers, therefore having different power alarms. It is quite similar to a case of different physical interfaces." ::= { dot3ExtPkgControlObjects 5} dot3ExtPkgOptIfEntry OBJECT-TYPE SYNTAX Dot3ExtPkgOptIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the optical interface table of the EPON interface. Rows exist for an OLT interface and an ONU interface. A row in the table is denoted by the ifIndex of the link and it is created when the ifIndex is created. The rows in the table for an ONU interface are created at system initialization. The row in the table corresponding to the OLT ifIndex and the row corresponding to the broadcast virtual link are created at system initialization. A row in the table corresponding to the ifIndex of a virtual links is created when a virtual link is established (ONU registers) and deleted when the virtual link is deleted (ONU deregisters)." INDEX { ifIndex } ::= { dot3ExtPkgOptIfTable 1 } Dot3ExtPkgOptIfEntry ::= SEQUENCE { dot3ExtPkgOptIfSuspectedFlag TruthValue, Khermosh Standards Track [Page 75] RFC 4837 Managed Objects of EPON July 2007 dot3ExtPkgOptIfInputPower Integer32, dot3ExtPkgOptIfLowInputPower Integer32, dot3ExtPkgOptIfHighInputPower Integer32, dot3ExtPkgOptIfLowerInputPowerThreshold Integer32, dot3ExtPkgOptIfUpperInputPowerThreshold Integer32, dot3ExtPkgOptIfOutputPower Integer32, dot3ExtPkgOptIfLowOutputPower Integer32, dot3ExtPkgOptIfHighOutputPower Integer32, dot3ExtPkgOptIfLowerOutputPowerThreshold Integer32, dot3ExtPkgOptIfUpperOutputPowerThreshold Integer32, dot3ExtPkgOptIfSignalDetect TruthValue, dot3ExtPkgOptIfTransmitAlarm TruthValue, dot3ExtPkgOptIfTransmitEnable TruthValue } dot3ExtPkgOptIfSuspectedFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object is a reliability indication. If true, the data in this entry may be unreliable. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 1 } dot3ExtPkgOptIfInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the input. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 2 } dot3ExtPkgOptIfLowInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the input during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 3 } Khermosh Standards Track [Page 76] RFC 4837 Managed Objects of EPON July 2007 dot3ExtPkgOptIfHighInputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the input during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 4 } dot3ExtPkgOptIfLowerInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The lower limit threshold on input power. If dot3ExtPkgOptIfInputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfLowerInputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 5 } dot3ExtPkgOptIfUpperInputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on input power. If dot3ExtPkgOptIfInputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfUpperInputPowerThreshold can lead to a Threshold Khermosh Standards Track [Page 77] RFC 4837 Managed Objects of EPON July 2007 Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 6 } dot3ExtPkgOptIfOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The optical power monitored at the output. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 7 } dot3ExtPkgOptIfLowOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The lowest optical power monitored at the output during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 8 } dot3ExtPkgOptIfHighOutputPower OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest optical power monitored at the output during the current 15-minute interval. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 9 } dot3ExtPkgOptIfLowerOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current Khermosh Standards Track [Page 78] RFC 4837 Managed Objects of EPON July 2007 DESCRIPTION "The lower limit threshold on output power. If dot3ExtPkgOptIfOutputPower drops to this value or below, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfLowerOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 10 } dot3ExtPkgOptIfUpperOutputPowerThreshold OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dbm" MAX-ACCESS read-write STATUS current DESCRIPTION "The upper limit threshold on output power. If dot3ExtPkgOptIfOutputPower reaches or exceeds this value, a Threshold Crossing Alert (TCA) should be sent. Reading will present the threshold value. Writing will set the value of the threshold. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfUpperOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service of the users connected to the respective EPON interface, depending on the system action on such an alert. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." ::= { dot3ExtPkgOptIfEntry 11 } dot3ExtPkgOptIfSignalDetect OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When getting true(1), there is a valid optical signal at the receive that is above the optical power level for signal detection. When getting false(2) the optical signal at the receive is below the optical power level Khermosh Standards Track [Page 79] RFC 4837 Managed Objects of EPON July 2007 for signal detection. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." DEFVAL { false } ::= { dot3ExtPkgOptIfEntry 12 } dot3ExtPkgOptIfTransmitAlarm OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When getting true(1) there is a non-valid optical signal at the transmit of the interface, either a higher level or lower level than expected. When getting false(2) the optical signal at the transmit is valid and in the required range. This object is applicable for an OLT and an ONU. At the OLT, it has a distinct value for each virtual interface." DEFVAL { false } ::= { dot3ExtPkgOptIfEntry 13 } dot3ExtPkgOptIfTransmitEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to true(1) will cause the optical interface to start transmission (according to the control protocol specified for the logical interface). Setting this object to false(2) will cause the interface to stop the optical transmission. When getting true(1), the optical interface is in transmitting mode (obeying to the logical control protocol). When getting false(2), the optical interface is not in transmitting mode. The write operation is not restricted in this document and can be done at any time. Changing dot3ExtPkgOptIfTransmitEnable state can lead to a halt in the optical transmission of the respective interface leading to an interruption of service of the users connected to the respective EPON interface. The object is relevant when the admin state of the interface is active as set by the dot3MpcpAdminState. This object is applicable for an OLT and an ONU. At the OLT it, has a distinct value for each virtual interface." DEFVAL { false } ::= { dot3ExtPkgOptIfEntry 14 } Khermosh Standards Track [Page 80] RFC 4837 Managed Objects of EPON July 2007 -- Conformance Statements -- Conformance Groups dot3EponGroups OBJECT IDENTIFIER ::= { dot3EponConformance 1 } dot3MpcpGroupBase OBJECT-GROUP OBJECTS { dot3MpcpOperStatus, dot3MpcpAdminState, dot3MpcpMode, dot3MpcpSyncTime, dot3MpcpLinkID, dot3MpcpRemoteMACAddress, dot3MpcpRegistrationState, dot3MpcpMaximumPendingGrants, dot3MpcpTransmitElapsed, dot3MpcpReceiveElapsed, dot3MpcpRoundTripTime } STATUS current DESCRIPTION "A collection of objects of dot3 Mpcp Control entity state definition. Objects are per LLID." ::= { dot3EponGroups 1 } dot3MpcpGroupStat OBJECT-GROUP OBJECTS { dot3MpcpMACCtrlFramesTransmitted, dot3MpcpMACCtrlFramesReceived, dot3MpcpDiscoveryWindowsSent, dot3MpcpDiscoveryTimeout, dot3MpcpTxRegRequest, dot3MpcpRxRegRequest, dot3MpcpTxRegAck, dot3MpcpRxRegAck, dot3MpcpTxReport, dot3MpcpRxReport, dot3MpcpTxGate, dot3MpcpRxGate, dot3MpcpTxRegister, dot3MpcpRxRegister } STATUS current DESCRIPTION "A collection of objects of dot3 Mpcp Statistics. Objects are per LLID." ::= { dot3EponGroups 2 } Khermosh Standards Track [Page 81] RFC 4837 Managed Objects of EPON July 2007 dot3OmpeGroupID OBJECT-GROUP OBJECTS { dot3OmpEmulationType } STATUS current DESCRIPTION "A collection of objects of dot3 OMP emulation entity state definition. Objects are per LLID." ::= { dot3EponGroups 3 } dot3OmpeGroupStat OBJECT-GROUP OBJECTS { dot3OmpEmulationSLDErrors, dot3OmpEmulationCRC8Errors, dot3OmpEmulationBadLLID, dot3OmpEmulationGoodLLID, dot3OmpEmulationOnuPonCastLLID, dot3OmpEmulationOltPonCastLLID, dot3OmpEmulationBroadcastBitNotOnuLlid, dot3OmpEmulationOnuLLIDNotBroadcast, dot3OmpEmulationBroadcastBitPlusOnuLlid, dot3OmpEmulationNotBroadcastBitNotOnuLlid } STATUS current DESCRIPTION "A collection of objects of dot3 OMP emulation Statistics. Objects are per LLID." ::= { dot3EponGroups 4 } dot3EponFecGroupAll OBJECT-GROUP OBJECTS { dot3EponFecPCSCodingViolation, dot3EponFecAbility, dot3EponFecMode, dot3EponFecCorrectedBlocks, dot3EponFecUncorrectableBlocks, dot3EponFecBufferHeadCodingViolation } STATUS current DESCRIPTION "A collection of objects of dot3 FEC group control and statistics. Objects are per LLID." ::= { dot3EponGroups 5 } dot3ExtPkgGroupControl OBJECT-GROUP OBJECTS { dot3ExtPkgObjectReset, Khermosh Standards Track [Page 82] RFC 4837 Managed Objects of EPON July 2007 dot3ExtPkgObjectPowerDown, dot3ExtPkgObjectNumberOfLLIDs, dot3ExtPkgObjectFecEnabled, dot3ExtPkgObjectReportMaximumNumQueues, dot3ExtPkgObjectRegisterAction } STATUS current DESCRIPTION "A collection of objects of dot3ExtPkg control definition. Objects are per LLID." ::= { dot3EponGroups 6 } dot3ExtPkgGroupQueue OBJECT-GROUP OBJECTS { dot3ExtPkgObjectReportNumThreshold, dot3ExtPkgObjectReportMaximumNumThreshold, dot3ExtPkgStatTxFramesQueue, dot3ExtPkgStatRxFramesQueue, dot3ExtPkgStatDroppedFramesQueue } STATUS current DESCRIPTION "A collection of objects of dot3ExtPkg Queue control. Objects are per LLID, per queue." ::= { dot3EponGroups 7 } dot3ExtPkgGroupQueueSets OBJECT-GROUP OBJECTS { dot3ExtPkgObjectReportThreshold } STATUS current DESCRIPTION "A collection of objects of dot3ExtPkg queue_set control. Objects are per LLID, per queue, per queue_set." ::= { dot3EponGroups 8 } dot3ExtPkgGroupOptIf OBJECT-GROUP OBJECTS { dot3ExtPkgOptIfSuspectedFlag, dot3ExtPkgOptIfInputPower, dot3ExtPkgOptIfLowInputPower, dot3ExtPkgOptIfHighInputPower, dot3ExtPkgOptIfLowerInputPowerThreshold, dot3ExtPkgOptIfUpperInputPowerThreshold, dot3ExtPkgOptIfOutputPower, dot3ExtPkgOptIfLowOutputPower, dot3ExtPkgOptIfHighOutputPower, Khermosh Standards Track [Page 83] RFC 4837 Managed Objects of EPON July 2007 dot3ExtPkgOptIfLowerOutputPowerThreshold, dot3ExtPkgOptIfUpperOutputPowerThreshold, dot3ExtPkgOptIfSignalDetect, dot3ExtPkgOptIfTransmitAlarm, dot3ExtPkgOptIfTransmitEnable } STATUS current DESCRIPTION "A collection of objects of control and status indication of the optical interface. Objects are per LLID." ::= { dot3EponGroups 9 } -- Compliance dot3EponCompliances OBJECT IDENTIFIER ::= { dot3EponConformance 2 } dot3MPCPCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for Multi-Point Control Protocol interfaces." MODULE -- this module MANDATORY-GROUPS { dot3MpcpGroupBase} GROUP dot3MpcpGroupStat DESCRIPTION "This group is mandatory for all MPCP supporting interfaces for statistics collection." ::= { dot3EponCompliances 1} dot3OmpeCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for OMPEmulation interfaces." MODULE -- this module MANDATORY-GROUPS { dot3OmpeGroupID} GROUP dot3OmpeGroupStat DESCRIPTION "This group is mandatory for all OMPemulation supporting interfaces for statistics collection." ::= { dot3EponCompliances 2} dot3EponFecCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for FEC EPON interfaces. Khermosh Standards Track [Page 84] RFC 4837 Managed Objects of EPON July 2007 This group is mandatory for all FEC supporting interfaces for control and statistics collection." MODULE -- this module MANDATORY-GROUPS { dot3EponFecGroupAll } ::= { dot3EponCompliances 3} dot3ExtPkgCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for EPON Interfaces using the extended package." MODULE -- this module MANDATORY-GROUPS { dot3ExtPkgGroupControl } GROUP dot3ExtPkgGroupQueue DESCRIPTION " This group is mandatory for all EPON interfaces supporting REPORT queue management of the extended package." GROUP dot3ExtPkgGroupQueueSets DESCRIPTION " This group is mandatory for all EPON interfaces supporting REPORT queue_sets management of the extended package." GROUP dot3ExtPkgGroupOptIf DESCRIPTION "This group is mandatory for all EPON interfaces supporting optical interfaces management, of the extended package." ::= { dot3EponCompliances 4} END 7. IANA Considerations IANA has allocated a single object identifier for the MODULE-IDENTITY of the DOT3-EPON-MIB module under the MIB-2 tree. The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- dot3EponMIB { mib-2 155 } Khermosh Standards Track [Page 85] RFC 4837 Managed Objects of EPON July 2007 8. Acknowledgements This document is the result of the efforts of the HUBMIB Working Group. Some special thanks to Dan Romascanu, who was WG chair during most of the development of this document, and who carefully reviewed and commented on the initial versions of this document. Also, some special thanks to Bert Wijnen, who is the current WG chair, for his review and comments on the final stages of this document. Special thanks are due to David Perkins for his detailed and helpful MIB Doctor review of this document. Also, some special thanks to some of the IEEE802.3ah Working Group people for their contribution and additional reviews of the document. 9. Security Considerations There are number of managed objects defined in this MIB module that have a MAX-ACCESS clause of read-write or read-create. Writing to these objects can have potentially disruptive effects on network operation, including: Changing dot3MpcpAdminState state can lead to disabling the Multi-Point Control Protocol on the respective interface, leading to the interruption of service for the users connected to the respective EPON interface. Changing dot3EponFecMode state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the users connected to the respective EPON interface. Changing dot3ExtPkgObjectReset state can lead to a reset of the respective interface leading to an interruption of service for the users connected to the respective EPON interface. Changing dot3ExtPkgObjectPowerDown state can lead to a power down of the respective interface, leading to an interruption of service for the users connected to the respective EPON interface. Changing dot3ExtPkgObjectFecEnabled state can lead to disabling the Forward Error Correction on the respective interface, which can lead to a degradation of the optical link, and therefore may lead to an interruption of service for the users connected to the respective EPON interface. Khermosh Standards Track [Page 86] RFC 4837 Managed Objects of EPON July 2007 Changing dot3ExtPkgObjectRegisterAction state can lead to a change in the registration state of the respective interface, leading to a deregistration and an interruption of service for the users connected to the respective EPON interface. Changing dot3ExtPkgObjectReportNumThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service for the users connected to the respective EPON interface. Changing dot3ExtPkgObjectReportThreshold can lead to a change in the reporting of the ONU interface and therefore to a change in the bandwidth allocation of the respective interface. This change may lead a degradation or an interruption of service for the users connected to the respective EPON interface. Changing dot3ExtPkgOptIfLowerInputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. Changing dot3ExtPkgOptIfUpperInputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. Changing dot3ExtPkgOptIfLowerOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. Changing dot3ExtPkgOptIfUpperOutputPowerThreshold can lead to a Threshold Crossing Alert (TCA) being sent for the respective interface. This alert may be leading to an interruption of service for the users connected to the respective EPON interface, depending on the system action on such an alert. Changing dot3ExtPkgOptIfTransmitEnable state can lead to a halt in the optical transmission of the respective interface, leading to an interruption of service for the users connected to the respective EPON interface. Khermosh Standards Track [Page 87] RFC 4837 Managed Objects of EPON July 2007 The user of this MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in this MIB module (i.e., those with MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the performance of network interfaces and can reveal some aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly even to encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. References 10.1. Normative References [802.1d] IEEE, "Institute of Electrical and Electronic Engineers, 802.1D-2004, IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges.", June 2004. [802.3] IEEE, "Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2002, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.", December 2002. Khermosh Standards Track [Page 88] RFC 4837 Managed Objects of EPON July 2007 [802.3ah] IEEE, "Institute of Electrical and Electronic Engineers, IEEE Std 802.3ah-2004. Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters for subscriber access networks.", IEEE Std 802.3ah-2004, October 2004. [ITU-T.G.975] ITU, "ITU-T, SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS Digital sections and digital line system - Optical fibre submarine cable systems Forward error correction for submarine systems, ITU-T Recommendation G.975", October 2000. [ITU-T.G.983] ITU, "ITU-T, SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS, Digital transmission systems - Digital sections and digital line system - Optical line systems for local and access networks Broadband optical access systems based on Passive Optical Networks (PON), ITU-T Recommendation G.983.1", October 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000. Khermosh Standards Track [Page 89] RFC 4837 Managed Objects of EPON July 2007 [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003. [RFC4836] Beili, E., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 4836, April 2007. 10.2. Informative References [RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, September 1993. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005. [RFC4878] Squire, M., "Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces", RFC 4878, June 2007. Author's Address Lior Khermosh PMC-SIERRA Kohav Hertzelia bldg, 4 Hasadnaot St., Hertzliya Pituach, 46120 ISRAEL Phone: +972-9-9628000 Ext: 302 Fax: +972-9-9628001 EMail: lior_khermosh@pmc-sierra.com Khermosh Standards Track [Page 90] RFC 4837 Managed Objects of EPON July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Khermosh Standards Track [Page 91] snmp-mibs-downloader-1.1/mibrfcs/rfc4878.txt0000644000000000000000000037602311402176072015610 0ustar Network Working Group M. Squire Request for Comments: 4878 Hatteras Networks Category: Standards Track June 2007 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities. Squire Standards Track [Page 1] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Overview ........................................................3 3.1. Remote Fault Indication ....................................4 3.2. Link Monitoring ............................................4 3.3. Remote Loopback ............................................5 3.4. Ethernet OAM Protocol Data Units ...........................5 4. Relation to the Other MIB Modules ...............................5 4.1. Relation to Other MIB Modules ..............................5 4.2. Relation to Other EFM MIB Modules ..........................6 4.3. Mapping of IEEE 802.3ah Managed Objects ....................6 5. MIB Structure ...................................................7 6. MIB Definition ..................................................8 7. Security Considerations ........................................47 8. IANA Considerations ............................................49 9. References .....................................................49 9.1. Normative References ......................................49 9.2. Informative References ....................................50 10. Acknowledgments ...............................................51 1. Introduction The IEEE 802.3ah Ethernet in the First Mile (EFM) taskforce added new management capabilities to Ethernet-like interfaces. These management capabilities were introduced to provide some basic Ordered Aggregate (OA) function on Ethernet media. The defined functionality includes discovery, error signaling, loopback, and link monitoring. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community to manage these new Ethernet interface capabilities. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Squire Standards Track [Page 2] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview Ethernet networks have evolved over the past 30 years from simple LANs to a variety of other applications, including wide-area networks. To address some of these emerging markets, the IEEE 802.3ah taskforce defined additional clauses in [802.3ah] for the IEEE 802.3 standard [802.3-2002] to better address Ethernet deployments in the public-access network. Although Ethernet-access deployments were the primary motivation for the taskforce activity, the results of the taskforce are not strictly limited to that application. Ethernet OAM can be implemented on Ethernet links that are not EFM. The Ethernet in the First Mile (EFM) taskforce was focused on four somewhat independent objectives to better address Ethernet access deployments: optics, copper, Ethernet passive optical networks (Ethernet PON, or EPON), and operations, administration, and maintenance (OAM). The optics sub-taskforce developed new optical physical layers that better served the long-reach outside plant networks typically found in the access network, including developing physical layers that operate up to 20 Km and supporting the environmental conditions of access deployments. The copper sub- taskforce developed two new physical layers that run Ethernet natively over existing twisted pair wires that have been supporting voice services for decades. The EPON sub-taskforce developed a new point-to-multipoint Ethernet physical layer, utilizing Ethernet framing natively over a time-division multiple-access (TDMA) infrastructure. The OAM sub-taskforce introduced some basic management functionality into an Ethernet link to better monitor and maintain Ethernet networks in geographically disparate networks. This document defines the management objects necessary to integrate Ethernet OAM functionality into the SNMP management framework. Ethernet OAM is composed of a core set of functions and a set of optional functional groups. The mandatory functions include discovery operations (determining if the other end of the link is OA capable and what OAM functions it supports), state machine implementation, and some critical event flows. The optional functional groups are for (a) link events, (b) remote loopback, and (c) variable retrieval and response. Each optional functional group is controlled by a separate MIB table(s). Squire Standards Track [Page 3] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Ethernet OAM is complementary with SNMP management in that it provides some basic management functions at layer two, rather than using layer three and above as required by SNMP over an IP infrastructure. Ethernet OAM provides single-hop functionality in that it works only between two directly connected Ethernet stations. SNMP can be used to manage the Ethernet OAM interactions of one Ethernet station with another. Ethernet OAM has three functional objectives, which are detailed in the next three sections. The definition of a basic Ethernet OA protocol data unit is given in Section 3.4. 3.1. Remote Fault Indication Remote fault indication provides a mechanism for one end of an Ethernet link to signal the other end that the receive path is non- operational. Some Ethernet physical layers offer mechanisms to signal this condition at the physical layer. Ethernet OAM added a mechanism so that some Ethernet physical layers can operate in unidirectional mode, allowing frames to be transmitted in one direction even when the other direction is non-operational. Traditionally, Ethernet PHYs do not allow frame transmission in one direction if the other direction is not operational. Using this mode, Ethernet OAM allows frame-based signaling of remote fault conditions while still not allowing higher-layer applications to be aware of the unidirectional capability. This document includes mechanisms for capturing that fault information and reflecting such information in objects and notifications within the SNMP management framework. 3.2. Link Monitoring Ethernet OAM includes event signaling capability so that one end of an Ethernet link can indicate the occurrence of certain important events to the other end of the link. This happens via layer two protocols. This document defines methods for incorporating the occurrence of these layer two events, both at the local end and far end of the link, into the SNMP management framework. Ethernet OAM also includes mechanisms for one Ethernet station to query another directly connected Ethernet station about the status of its Ethernet interface variables and status. This document does not include mechanisms for controlling how one Ethernet endpoint may use this functionality to query the status or statistics of a peer Ethernet entity. Squire Standards Track [Page 4] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 3.3. Remote Loopback Remote loopback is a link state where the peer Ethernet entity echoes every received packet (without modifications) back onto the link. Remote loopback is intrusive in that the other end of the link is not forwarding traffic from higher layers out over the link. This document defines objects controlling loopback operation and reading the status of the loopback state. 3.4. Ethernet OAM Protocol Data Units An Ethernet OAM protocol data unit is a valid Ethernet frame with a destination Media Access Control (MAC) address equal to the reserved MAC address for Slow Protocols (See 43B of [802.3ah]), a lengthOrType field equal to the reserved type for Slow Protocols, and a Slow Protocols subtype equal to that of the subtype reserved for Ethernet OAM. OAMPDU is used throughout this document as an abbreviation for Ethernet OAM protocol data unit. OAMPDUs are the mechanism by which two directly connected Ethernet interfaces exchange OA information. 4. Relation to the Other MIB Modules The definitions presented here are based on Clauses 30 and 57 of [802.3ah]. Note that these clauses describe many of these variables and their effects on the MAC layer. In some cases, there is a one- to-one relationship between an object in this document and an object in the Clause 30 MIB of [802.3ah]. In other cases, the objects of this document reflect a more complex entity and are reflected by more than one object in the Clause 30 MIB of [802.3ah]. 4.1. Relation to Other MIB Modules The objects defined in this document manage OAM functionality introduced in [802.3ah] These objects do not overlap with the interfaces MIB [RFC2863], the Ethernet-like interfaces MIB [RFC3635], or any other MIB currently used to manage various aspects of an Ethernet interface. The objects defined here are defined for Ethernet-like interfaces only and use the same ifIndex as the associated Ethernet interface. Ethernet OAM can be implemented on any Ethernet-like interface. Squire Standards Track [Page 5] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 4.2. Relation to Other EFM MIB Modules The Ethernet OAM functionality and MIB Module is independent of the other functionality and MIB Modules derived from [802.3ah] for copper [802.3ah-copper] and EPON [802.3ah-epon]. Ethernet OAM may be implemented (or not) on the new EFM interface types, just as it can on any other Ethernet interface. 4.3. Mapping of IEEE 802.3ah Managed Objects This section contains the mapping between managed objects defined in [802.3ah] Clause 30, and managed objects defined in this document. IEEE 802.3 Managed Object Corresponding SNMP object oOA .aOAMID IF-MIB ifIndex .aOAMAdminState dot3OamAdminState .aOAMMode dot3OamMode .aOAMDiscoveryState dot3OamOperStatus .aOAMRemoteMACAddress dot3OamPeerMacAddress .aOAMLocalConfiguration dot3OamFunctionsSupported .aOAMRemoteConfiguration dot3OamPeerFunctionsSupported, dot3OamPeerMode .aOAMLocalPDUConfiguration dot3OamMaxOamPduSize .aOAMRemotePDUConfiguration dot3OamPeerMaxOamPduSize .aOAMLocalFlagsField dot3OamOperStatus, dot3OamEventLogEntry .aOAMRemoteFlagsField dot3OamOperStatus, dot3OamEventLogEntry .aOAMLocalRevision dot3OamConfigRevision .aOAMRemoteRevision dot3OamPeerConfigRevision .aOAMLocalState dot3OamLoopbackStatus .aOAMRemoteState dot3OamLoopbackStatus .aOAMRemoteVendorOUI dot3OamPeerVendorOui .aOAMRemoteVendorSpecificInfo dot3OamPeerVendorInfo .aOAMUnsupportedCodesTx dot3OamUnsupportedCodesTx .aOAMUnsupportedCodesRx dot3OamUnsupportedCodesRx .aOAMInformationTx dot3OamInformationTx .aOAMInformationRx dot3OamInformationRx .aOAMUniqueEventNotificationTx dot3OamUniqueEventNotificationTx .aOAMUniqueEventNotificationRx dot3OamUniqueEventNotificationRx .aOAMDuplicateEventNotificationTx dot3OamDuplicateEventNotificationTx .aOAMDuplicateEventNotificationRx dot3OamDuplicateEventNotificationRx .aOAMLoopbackControlTx dot3OamLoopbackControlTx Squire Standards Track [Page 6] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 .aOAMLoopbackControlRx dot3OamLoopbackControlRx .aOAMVariableRequestTx dot3OamVariableRequestTx .aOAMVariableRequestRx dot3OamVariableRequestRx .aOAMVariableResponseTx dot3OamVariableResponseTx .aOAMVariableResponseRx dot3OamVariableResponseRx .aOAMOrganizationSpecificTx dot3OamOrgSpecificTx .aOAMOrganizationSpecificRx dot3OamOrgSpecificTx .aOAMLocalErrSymPeriodConfig dot3OamErrSymPeriodWindow, dot3OamErrSymPeriodThreshold .aOAMLocalErrSymPeriodEvent dot3OamEventLogEntry .aOAMLocalErrFrameConfig dot3OamErrFrameWindow, dot3OamErrFrameThreshold .aOAMLocalErrFrameEvent dot3OamEventLogEntry .aOAMLocalErrFramePeriodConfig dot3OamErrFramePeriodWindow, dot3OamErrFramePeriodThreshold .aOAMLocalErrFramePeriodEvent dot3OamEventLogEntry .aOAMLocalErrFrameSecsSummaryConfig dot3OamErrFrameSecsSummaryWindow, dot3OamErrFrameSecssummaryThreshold .aOAMLocalErrFrameSecsSummaryEvent dot3OamEventLogEntry .aOAMRemoteErrSymPeriodEvent dot3OamEventLogEntry .aOAMRemoteErrFrameEvent dot3OamEventLogEntry .aOAMRemoteErrFramePeriodEvent dot3OamEventLogEntry .aOAMRemoteErrFrameSecsSummaryEvent dot3OamEventLogEntry .aFramesLostDueToOAmError dot3OamFramesLostDueToOam .acOAMAdminControl dot3OamAdminState There are no IEEE 802.3ah managed objects that are not reflected in this MIB Module in some manner. 5. MIB Structure The Ethernet OAM MIB objects of this memo focus on the OA capabilities introduced in [802.3ah]. The MIB objects are partitioned into six different MIB groups. The dot3OamTable group manages the primary OAM objects of the Ethernet interface. This group controls the state and status of OA as well as the mode in which it operates. The dot3OamPeerTable maintains the current information on the status and configuration of the peer OAM entity on the Ethernet interface. Managed information includes the capabilities and function available on the peer OAM entity. Squire Standards Track [Page 7] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 The dot3OamLoopbackTable manages the loopback function introduced in [802.3ah]. This table controls enabling and disabling loopback, as well as indicating the loopback status of Ethernet OAM on this interface. The dot3OamStatsTable maintains statistics on the number and type of Ethernet OAM frames being transmitted and received on the Ethernet interface. The dot3OamEventConfigTable defines the objects for managing the event notification capability available in Ethernet OAM. With Ethernet OAM, one device may send notifications to its peer devices whenever an important event happens on the local device. This table provides management of which events result in notifications via Ethernet OAM notifications and/or via SNMP notifications. The dot3OamEventLogTable manages the current status of local and remote events detected via Ethernet OAM. This table is updated whenever local events are detected by Ethernet OAM or whenever Ethernet OAM Event Notifications are received from the peer OA entity. There are two notifications defined to report Ethernet OAM events (one for threshold crossing events, one for non-threshold crossing events). Both notifications are contained within the same conformance group. 6. MIB Definition DOT3-OAM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, OBJECT-TYPE, Counter32, Unsigned32, Integer32, NOTIFICATION-TYPE FROM SNMPv2-SMI -- from [RFC2578] TEXTUAL-CONVENTION, MacAddress, TimeStamp, TruthValue FROM SNMPv2-TC -- from [RFC2579] CounterBasedGauge64 FROM HCNUM-TC -- from [RFC2856] ifIndex FROM IF-MIB -- from [RFC2863] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; Squire Standards Track [Page 8] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 -- from [RFC2580] dot3OamMIB MODULE-IDENTITY LAST-UPDATED "200706140000Z" -- June 14,2007" ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-requests@ietf.org In Body: subscribe your_email_address Chair: Bert Wijnen Alcatel-Lucent Email: bwijnen at alcatel-lucent dot com Editor: Matt Squire Hatteras Networks E-mail: msquire at hatterasnetworks dot com " DESCRIPTION "The MIB module for managing the new Ethernet OAM features introduced by the Ethernet in the First Mile taskforce (IEEE 802.3ah). The functionality presented here is based on IEEE 802.3ah [802.3ah], released in October, 2004. [802.3ah] was prepared as an addendum to the standing version of IEEE 802.3 [802.3-2002]. Since then, [802.3ah] has been merged into the base IEEE 802.3 specification in [802.3-2005]. In particular, this MIB focuses on the new OAM functions introduced in Clause 57 of [802.3ah]. The OAM functionality of Clause 57 is controlled by new management attributes introduced in Clause 30 of [802.3ah]. The OAM functions are not specific to any particular Ethernet physical layer, and can be generically applied to any Ethernet interface of [802.3-2002]. An Ethernet OAM protocol data unit is a valid Ethernet frame with a destination MAC address equal to the reserved MAC address for Slow Protocols (See 43B of [802.3ah]), a lengthOrType field equal to the reserved type for Slow Protocols, and a Slow Protocols subtype equal to that of the subtype reserved for Ethernet OAM. OAMPDU is used throughout this document as an abbreviation for Ethernet OAM protocol data unit. The following reference is used throughout this MIB module: Squire Standards Track [Page 9] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 [802.3ah] refers to: IEEE Std 802.3ah-2004: 'Draft amendment to - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters for subscriber access networks', October 2004. [802.3-2002] refers to: IEEE Std 802.3-2002: 'Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters for subscriber access networks', March 2002. [802.3-2005] refers to: IEEE Std 802.3-2005: 'Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters for subscriber access networks', December 2005. [802-2001] refers to: 'IEEE Standard for LAN/MAN (Local Area Network/Metropolitan Area Network): Overview and Architecture', IEEE 802, June 2001. Copyright (c) The IETF Trust (2007). This version of this MIB module is part of RFC 4878; See the RFC itself for full legal notices. " REVISION "200706140000Z" -- June 14, 2007" DESCRIPTION "Initial version, published as RFC 4878." ::= { mib-2 158 } -- -- Sections of the Ethernet OAM MIB Squire Standards Track [Page 10] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 -- dot3OamNotifications OBJECT IDENTIFIER ::= { dot3OamMIB 0 } dot3OamObjects OBJECT IDENTIFIER ::= { dot3OamMIB 1 } dot3OamConformance OBJECT IDENTIFIER ::= { dot3OamMIB 2 } -- -- Textual conventions for the OAM MIB -- EightOTwoOui ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "24-bit Organizationally Unique Identifier. Information on OUIs can be found in IEEE 802-2001 [802-2001], Clause 9." SYNTAX OCTET STRING(SIZE(3)) -- *************************************************************** -- -- Ethernet OAM Control group -- dot3OamTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the primary controls and status for the OAM capabilities of an Ethernet-like interface. There will be one row in this table for each Ethernet-like interface in the system that supports the OAM functions defined in [802.3ah]. " ::= { dot3OamObjects 1 } dot3OamEntry OBJECT-TYPE SYNTAX Dot3OamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table that contains information on the Ethernet OAM function for a single Ethernet like interface. Entries in the table are created automatically for each interface supporting Ethernet OAM. The status of the row entry can be determined from dot3OamOperStatus. A dot3OamEntry is indexed in the dot3OamTable by the ifIndex object of the Interfaces MIB. " INDEX { ifIndex } ::= { dot3OamTable 1 } Squire Standards Track [Page 11] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Dot3OamEntry ::= SEQUENCE { dot3OamAdminState INTEGER, dot3OamOperStatus INTEGER, dot3OamMode INTEGER, dot3OamMaxOamPduSize Unsigned32, dot3OamConfigRevision Unsigned32, dot3OamFunctionsSupported BITS } dot3OamAdminState OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to provision the default administrative OAM mode for this interface. This object represents the desired state of OAM for this interface. The dot3OamAdminState always starts in the disabled(2) state until an explicit management action or configuration information retained by the system causes a transition to the enabled(1) state. When enabled(1), Ethernet OAM will attempt to operate over this interface. " REFERENCE "[802.3ah], 30.3.6.1.2" ::= { dot3OamEntry 1 } dot3OamOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), linkFault(2), passiveWait(3), activeSendLocal(4), sendLocalAndRemote(5), sendLocalAndRemoteOk(6), oamPeeringLocallyRejected(7), oamPeeringRemotelyRejected(8), operational(9), nonOperHalfDuplex(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "At initialization and failure conditions, two OAM entities on Squire Standards Track [Page 12] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 the same full-duplex Ethernet link begin a discovery phase to determine what OAM capabilities may be used on that link. The progress of this initialization is controlled by the OA sublayer. This value is always disabled(1) if OAM is disabled on this interface via the dot3OamAdminState. If the link has detected a fault and is transmitting OAMPDUs with a link fault indication, the value is linkFault(2). Also, if the interface is not operational (ifOperStatus is not up(1)), linkFault(2) is returned. Note that the object ifOperStatus may not be up(1) as a result of link failure or administrative action (ifAdminState being down(2) or testing(3)). The passiveWait(3) state is returned only by OAM entities in passive mode (dot3OamMode) and reflects the state in which the OAM entity is waiting to see if the peer device is OA capable. The activeSendLocal(4) value is used by active mode devices (dot3OamMode) and reflects the OAM entity actively trying to discover whether the peer has OAM capability but has not yet made that determination. The state sendLocalAndRemote(5) reflects that the local OA entity has discovered the peer but has not yet accepted or rejected the configuration of the peer. The local device can, for whatever reason, decide that the peer device is unacceptable and decline OAM peering. If the local OAM entity rejects the peer OAM entity, the state becomes oamPeeringLocallyRejected(7). If the OAM peering is allowed by the local device, the state moves to sendLocalAndRemoteOk(6). Note that both the sendLocalAndRemote(5) and oamPeeringLocallyRejected(7) states fall within the state SEND_LOCAL_REMOTE of the Discovery state diagram [802.3ah, Figure 57-5], with the difference being whether the local OAM client has actively rejected the peering or has just not indicated any decision yet. Whether a peering decision has been made is indicated via the local flags field in the OAMPDU (reflected in the aOAMLocalFlagsField of 30.3.6.1.10). If the remote OAM entity rejects the peering, the state becomes oamPeeringRemotelyRejected(8). Note that both the sendLocalAndRemoteOk(6) and oamPeeringRemotelyRejected(8) states fall within the state SEND_LOCAL_REMOTE_OK of the Discovery state diagram [802.3ah, Figure 57-5], with the difference being whether the remote OAM client has rejected Squire Standards Track [Page 13] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 the peering or has just not yet decided. This is indicated via the remote flags field in the OAMPDU (reflected in the aOAMRemoteFlagsField of 30.3.6.1.11). When the local OAM entity learns that both it and the remote OAM entity have accepted the peering, the state moves to operational(9) corresponding to the SEND_ANY state of the Discovery state diagram [802.3ah, Figure 57-5]. Since Ethernet OAM functions are not designed to work completely over half-duplex interfaces, the value nonOperHalfDuplex(10) is returned whenever Ethernet OAM is enabled (dot3OamAdminState is enabled(1)), but the interface is in half-duplex operation. " REFERENCE "[802.3ah], 30.3.6.1.4, 30.3.6.1.10, 30.3.6.1.11" ::= { dot3OamEntry 2 } dot3OamMode OBJECT-TYPE SYNTAX INTEGER { passive(1), active(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object configures the mode of OAM operation for this Ethernet-like interface. OAM on Ethernet interfaces may be in 'active' mode or 'passive' mode. These two modes differ in that active mode provides additional capabilities to initiate monitoring activities with the remote OAM peer entity, while passive mode generally waits for the peer to initiate OA actions with it. As an example, an active OAM entity can put the remote OAM entity in a loopback state, where a passive OA entity cannot. The default value of dot3OamMode is dependent on the type of system on which this Ethernet-like interface resides. The default value should be 'active(2)' unless it is known that this system should take on a subservient role to the other device connected over this interface. Changing this value results in incrementing the configuration revision field of locally generated OAMPDUs (30.3.6.1.12) and potentially re-doing the OAM discovery process if the dot3OamOperStatus was already operational(9). " REFERENCE "[802.3ah], 30.3.6.1.3" Squire Standards Track [Page 14] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 ::= { dot3OamEntry 3 } dot3OamMaxOamPduSize OBJECT-TYPE SYNTAX Unsigned32 (64..1518) UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The largest OAMPDU that the OAM entity supports. OA entities exchange maximum OAMPDU sizes and negotiate to use the smaller of the two maximum OAMPDU sizes between the peers. This value is determined by the local implementation. " REFERENCE "[802.3ah], 30.3.6.1.8" ::= { dot3OamEntry 4 } dot3OamConfigRevision OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The configuration revision of the OAM entity as reflected in the latest OAMPDU sent by the OAM entity. The config revision is used by OAM entities to indicate that configuration changes have occurred, which might require the peer OAM entity to re-evaluate whether OAM peering is allowed. " REFERENCE "[802.3ah], 30.3.6.1.12" ::= { dot3OamEntry 5 } dot3OamFunctionsSupported OBJECT-TYPE SYNTAX BITS { unidirectionalSupport (0), loopbackSupport(1), eventSupport(2), variableSupport(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The OAM functions supported on this Ethernet-like interface. OAM consists of separate functional sets beyond the basic discovery process that is always required. These functional groups can be supported independently by any implementation. These values are communicated to the peer via the local configuration field of Information OAMPDUs. Setting 'unidirectionalSupport(0)' indicates that the OA Squire Standards Track [Page 15] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 entity supports the transmission of OAMPDUs on links that are operating in unidirectional mode (traffic flowing in one direction only). Setting 'loopbackSupport(1)' indicates that the OAM entity can initiate and respond to loopback commands. Setting 'eventSupport(2)' indicates that the OAM entity can send and receive Event Notification OAMPDUs. Setting 'variableSupport(3)' indicates that the OAM entity can send and receive Variable Request and Response OAMPDUs. " REFERENCE "[802.3ah], 30.3.6.1.6" ::= { dot3OamEntry 6 } -- *************************************************************** -- -- Ethernet OAM Peer group -- dot3OamPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about the OAM peer for a particular Ethernet-like interface. OAM entities communicate with a single OAM peer entity on Ethernet links on which OA is enabled and operating properly. There is one entry in this table for each entry in the dot3OamTable for which information on the peer OAM entity is available. " ::= { dot3OamObjects 2 } dot3OamPeerEntry OBJECT-TYPE SYNTAX Dot3OamPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table containing information on the peer OA entity for a single Ethernet-like interface. Note that there is at most one OAM peer for each Ethernet-like interface. Entries are automatically created when information about the OAM peer entity becomes available, and automatically deleted when the OAM peer entity is no longer in communication. Peer information is not available when dot3OamOperStatus is disabled(1), linkFault(2), passiveWait(3), activeSendLocal(4), or nonOperHalfDuplex(10). " INDEX { ifIndex } Squire Standards Track [Page 16] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 ::= { dot3OamPeerTable 1 } Dot3OamPeerEntry ::= SEQUENCE { dot3OamPeerMacAddress MacAddress, dot3OamPeerVendorOui EightOTwoOui, dot3OamPeerVendorInfo Unsigned32, dot3OamPeerMode INTEGER, dot3OamPeerMaxOamPduSize Unsigned32, dot3OamPeerConfigRevision Unsigned32, dot3OamPeerFunctionsSupported BITS } dot3OamPeerMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC address of the peer OAM entity. The MAC address is derived from the most recently received OAMPDU. " REFERENCE "[802.3ah], 30.3.6.1.5." ::= { dot3OamPeerEntry 1 } dot3OamPeerVendorOui OBJECT-TYPE SYNTAX EightOTwoOui MAX-ACCESS read-only STATUS current DESCRIPTION "The OUI of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The OUI can be used to identify the vendor of the remote OA entity. This value is initialized to three octets of zero before any Local Information TLV is received. " REFERENCE "[802.3ah], 30.3.6.1.16." ::= { dot3OamPeerEntry 2 } dot3OamPeerVendorInfo OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Vendor Info of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The semantics of the Vendor Information field is proprietary and specific to the vendor (identified by the dot3OamPeerVendorOui). This information could, for example, Squire Standards Track [Page 17] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 be used to identify a specific product or product family. This value is initialized to zero before any Local Information TLV is received. " REFERENCE "[802.3ah], 30.3.6.1.17." ::= { dot3OamPeerEntry 3 } dot3OamPeerMode OBJECT-TYPE SYNTAX INTEGER { passive(1), active(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The mode of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The mode of the peer can be determined from the Configuration field in the Local Information TLV of the last Information OAMPDU received from the peer. The value is unknown(3) whenever no Local Information TLV has been received. The values of active(2) and passive(1) are returned when a Local Information TLV has been received indicating that the peer is in active or passive mode, respectively. " REFERENCE "[802.3ah], 30.3.6.1.7." ::= { dot3OamPeerEntry 4 } dot3OamPeerMaxOamPduSize OBJECT-TYPE SYNTAX Unsigned32 (0 | 64..1518) UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum size of OAMPDU supported by the peer as reflected in the latest Information OAMPDU received with a Local Information TLV. Ethernet OAM on this interface must not use OAMPDUs that exceed this size. The maximum OAMPDU size can be determined from the PDU Configuration field of the Local Information TLV of the last Information OAMPDU received from the peer. A value of zero is returned if no Local Information TLV has been received. Otherwise, the value of the OAM peer's maximum OAMPDU size is returned in this value. " REFERENCE "[802.3ah], 30.3.6.1.9." ::= { dot3OamPeerEntry 5 } Squire Standards Track [Page 18] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 dot3OamPeerConfigRevision OBJECT-TYPE SYNTAX Unsigned32(0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The configuration revision of the OAM peer as reflected in the latest OAMPDU. This attribute is changed by the peer whenever it has a local configuration change for Ethernet OA on this interface. The configuration revision can be determined from the Revision field of the Local Information TLV of the most recently received Information OAMPDU with a Local Information TLV. A value of zero is returned if no Local Information TLV has been received. " REFERENCE "[802.3ah], 30.3.6.1.13." ::= { dot3OamPeerEntry 6 } dot3OamPeerFunctionsSupported OBJECT-TYPE SYNTAX BITS { unidirectionalSupport (0), loopbackSupport(1), eventSupport(2), variableSupport(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The OAM functions supported on this Ethernet-like interface. OAM consists of separate functionality sets above the basic discovery process. This value indicates the capabilities of the peer OAM entity with respect to these functions. This value is initialized so all bits are clear. If unidirectionalSupport(0) is set, then the peer OAM entity supports sending OAM frames on Ethernet interfaces when the receive path is known to be inoperable. If loopbackSupport(1) is set, then the peer OAM entity can send and receive OAM loopback commands. If eventSupport(2) is set, then the peer OAM entity can send and receive event OAMPDUs to signal various error conditions. If variableSupport(3) is set, then the peer OAM entity can send and receive variable requests to monitor the attribute value as described in Clause 57 of [802.3ah]. The capabilities of the OAM peer can be determined from the configuration field of the Local Information TLV of the most recently received Information OAMPDU with a Local Information TLV. All zeros are returned if no Local Information TLV has Squire Standards Track [Page 19] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 yet been received. " REFERENCE "[802.3ah], REFERENCE 30.3.6.1.7." ::= { dot3OamPeerEntry 7 } -- *************************************************************** -- -- Ethernet OAM Loopback group -- dot3OamLoopbackTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamLoopbackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains controls for the loopback state of the local link as well as indicates the status of the loopback function. There is one entry in this table for each entry in dot3OamTable that supports loopback functionality (where dot3OamFunctionsSupported includes the loopbackSupport bit set). Loopback can be used to place the remote OAM entity in a state where every received frame (except OAMPDUs) is echoed back over the same interface on which they were received. In this state, at the remote entity, 'normal' traffic is disabled as only the looped back frames are transmitted on the interface. Loopback is thus an intrusive operation that prohibits normal data flow and should be used accordingly. " ::= { dot3OamObjects 3 } dot3OamLoopbackEntry OBJECT-TYPE SYNTAX Dot3OamLoopbackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information on the loopback status for a single Ethernet-like interface. Entries in the table are automatically created whenever the local OAM entity supports loopback capabilities. The loopback status on the interface can be determined from the dot3OamLoopbackStatus object. " INDEX { ifIndex } ::= { dot3OamLoopbackTable 1 } Dot3OamLoopbackEntry ::= Squire Standards Track [Page 20] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 SEQUENCE { dot3OamLoopbackStatus INTEGER, dot3OamLoopbackIgnoreRx INTEGER } dot3OamLoopbackStatus OBJECT-TYPE SYNTAX INTEGER { -- all values, except where noted, can be read -- but cannot be written noLoopback (1), -- initiatingLoopback can be read or written initiatingLoopback (2), remoteLoopback (3), -- terminatingLoopback can be read or written terminatingLoopback (4), localLoopback (5), unknown (6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The loopback status of the OAM entity. This status is determined by a combination of the local parser and multiplexer states, the remote parser and multiplexer states, as well as by the actions of the local OAM client. When operating in normal mode with no loopback in progress, the status reads noLoopback(1). The values initiatingLoopback(2) and terminatingLoopback(4) can be read or written. The other values can only be read - they can never be written. Writing initiatingLoopback causes the local OAM entity to start the loopback process with its peer. This value can only be written when the status is noLoopback(1). Writing the value initiatingLoopback(2) in any other state has no effect. When in remoteLoopback(3), writing terminatingLoopback(4) causes the local OAM entity to initiate the termination of the loopback state. Writing terminatingLoopack(4) in any other state has no effect. If the OAM client initiates a loopback and has sent a Loopback OAMPDU and is waiting for a response, where the local parser and multiplexer states are DISCARD (see [802.3ah, 57.2.11.1]), the status is 'initiatingLoopback'. In this case, the local OAM entity has yet to receive any acknowledgment that the remote OAM entity has received its loopback command request. Squire Standards Track [Page 21] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 If the local OAM client knows that the remote OAM entity is in loopback mode (via the remote state information as described in [802.3ah, 57.2.11.1, 30.3.6.1.15]), the status is remoteLoopback(3). If the local OAM client is in the process of terminating the remote loopback [802.3ah, 57.2.11.3, 30.3.6.1.14] with its local multiplexer and parser states in DISCARD, the status is terminatingLoopback(4). If the remote OAM client has put the local OAM entity in loopback mode as indicated by its local parser state, the status is localLoopback(5). The unknown(6) status indicates that the parser and multiplexer combination is unexpected. This status may be returned if the OAM loopback is in a transition state but should not persist. The values of this attribute correspond to the following values of the local and remote parser and multiplexer states. value LclPrsr LclMux RmtPrsr RmtMux noLoopback FWD FWD FWD FWD initLoopback DISCARD DISCARD FWD FWD rmtLoopback DISCARD FWD LPBK DISCARD tmtngLoopback DISCARD DISCARD LPBK DISCARD lclLoopback LPBK DISCARD DISCARD FWD unknown *** any other combination *** " REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.3.61.14, 30.3.6.1.15" ::= { dot3OamLoopbackEntry 1 } dot3OamLoopbackIgnoreRx OBJECT-TYPE SYNTAX INTEGER { ignore(1), process(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Since OAM loopback is a disruptive operation (user traffic does not pass), this attribute provides a mechanism to provide controls over whether received OAM loopback commands are processed or ignored. When the value is ignore(1), received loopback commands are ignored. When the value is process(2), OAM loopback commands are processed. The default value is to ignore loopback commands (ignore(1)). " REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.3.61.14, 30.3.6.1.15" ::= { dot3OamLoopbackEntry 2 } Squire Standards Track [Page 22] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 -- *************************************************************** -- -- Ethernet OAM Statistics group -- dot3OamStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistics for the OAM function on a particular Ethernet-like interface. There is an entry in the table for every entry in the dot3OamTable. The counters in this table are defined as 32-bit entries to match the counter size as defined in [802.3ah]. Given that the OA protocol is a slow protocol, the counters increment at a slow rate. " ::= { dot3OamObjects 4 } dot3OamStatsEntry OBJECT-TYPE SYNTAX Dot3OamStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table containing statistics information on the Ethernet OAM function for a single Ethernet-like interface. Entries are automatically created for every entry in the dot3OamTable. Counters are maintained across transitions in dot3OamOperStatus. " INDEX { ifIndex } ::= { dot3OamStatsTable 1 } Dot3OamStatsEntry ::= SEQUENCE { dot3OamInformationTx Counter32, dot3OamInformationRx Counter32, dot3OamUniqueEventNotificationTx Counter32, dot3OamUniqueEventNotificationRx Counter32, dot3OamDuplicateEventNotificationTx Counter32, dot3OamDuplicateEventNotificationRx Counter32, dot3OamLoopbackControlTx Counter32, dot3OamLoopbackControlRx Counter32, dot3OamVariableRequestTx Counter32, dot3OamVariableRequestRx Counter32, dot3OamVariableResponseTx Counter32, Squire Standards Track [Page 23] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 dot3OamVariableResponseRx Counter32, dot3OamOrgSpecificTx Counter32, dot3OamOrgSpecificRx Counter32, dot3OamUnsupportedCodesTx Counter32, dot3OamUnsupportedCodesRx Counter32, dot3OamFramesLostDueToOam Counter32 } dot3OamInformationTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Information OAMPDUs transmitted on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.20." ::= { dot3OamStatsEntry 1 } dot3OamInformationRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Information OAMPDUs received on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.21." ::= { dot3OamStatsEntry 2 } dot3OamUniqueEventNotificationTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of unique Event OAMPDUs transmitted on this interface. Event Notifications may be sent in duplicate to increase the probability of successfully being received, Squire Standards Track [Page 24] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 given the possibility that a frame may be lost in transit. Duplicate Event Notification transmissions are counted by dot3OamDuplicateEventNotificationTx. A unique Event Notification OAMPDU is indicated as an Event Notification OAMPDU with a Sequence Number field that is distinct from the previously transmitted Event Notification OAMPDU Sequence Number. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.22." ::= { dot3OamStatsEntry 3 } dot3OamUniqueEventNotificationRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of unique Event OAMPDUs received on this interface. Event Notification OAMPDUs may be sent in duplicate to increase the probability of successfully being received, given the possibility that a frame may be lost in transit. Duplicate Event Notification receptions are counted by dot3OamDuplicateEventNotificationRx. A unique Event Notification OAMPDU is indicated as an Event Notification OAMPDU with a Sequence Number field that is distinct from the previously received Event Notification OAMPDU Sequence Number. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.24." ::= { dot3OamStatsEntry 4 } dot3OamDuplicateEventNotificationTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of duplicate Event OAMPDUs transmitted Squire Standards Track [Page 25] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 on this interface. Event Notification OAMPDUs may be sent in duplicate to increase the probability of successfully being received, given the possibility that a frame may be lost in transit. A duplicate Event Notification OAMPDU is indicated as an Event Notification OAMPDU with a Sequence Number field that is identical to the previously transmitted Event Notification OAMPDU Sequence Number. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.23." ::= { dot3OamStatsEntry 5 } dot3OamDuplicateEventNotificationRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of duplicate Event OAMPDUs received on this interface. Event Notification OAMPDUs may be sent in duplicate to increase the probability of successfully being received, given the possibility that a frame may be lost in transit. A duplicate Event Notification OAMPDU is indicated as an Event Notification OAMPDU with a Sequence Number field that is identical to the previously received Event Notification OAMPDU Sequence Number. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.25." ::= { dot3OamStatsEntry 6 } dot3OamLoopbackControlTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Loopback Control OAMPDUs transmitted Squire Standards Track [Page 26] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.26." ::= { dot3OamStatsEntry 7 } dot3OamLoopbackControlRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Loopback Control OAMPDUs received on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.27." ::= { dot3OamStatsEntry 8 } dot3OamVariableRequestTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Variable Request OAMPDUs transmitted on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.28." ::= { dot3OamStatsEntry 9 } dot3OamVariableRequestRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Variable Request OAMPDUs received on Squire Standards Track [Page 27] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.29." ::= { dot3OamStatsEntry 10 } dot3OamVariableResponseTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Variable Response OAMPDUs transmitted on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.30." ::= { dot3OamStatsEntry 11 } dot3OamVariableResponseRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Variable Response OAMPDUs received on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.31." ::= { dot3OamStatsEntry 12 } dot3OamOrgSpecificTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Organization Specific OAMPDUs Squire Standards Track [Page 28] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 transmitted on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.32." ::= { dot3OamStatsEntry 13 } dot3OamOrgSpecificRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of Organization Specific OAMPDUs received on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.33." ::= { dot3OamStatsEntry 14 } dot3OamUnsupportedCodesTx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of OAMPDUs transmitted on this interface with an unsupported op-code. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.18." ::= { dot3OamStatsEntry 15 } dot3OamUnsupportedCodesRx OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of OAMPDUs received on this interface Squire Standards Track [Page 29] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 with an unsupported op-code. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.19." ::= { dot3OamStatsEntry 16 } dot3OamFramesLostDueToOam OBJECT-TYPE SYNTAX Counter32 UNITS "frames" MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of frames that were dropped by the OA multiplexer. Since the OAM multiplexer has multiple inputs and a single output, there may be cases where frames are dropped due to transmit resource contention. This counter is incremented whenever a frame is dropped by the OAM layer. Note that any Ethernet frame, not just OAMPDUs, may be dropped by the OAM layer. This can occur when an OAMPDU takes precedence over a 'normal' frame resulting in the 'normal' frame being dropped. When this counter is incremented, no other counters in this MIB are incremented. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. " REFERENCE "[802.3ah], 30.3.6.1.46." ::= { dot3OamStatsEntry 17 } -- *************************************************************** -- -- Ethernet OAM Event Configuration group -- dot3OamEventConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamEventConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Ethernet OAM includes the ability to generate and receive Event Notification OAMPDUs to indicate various link problems. This table contains the mechanisms to enable Event Squire Standards Track [Page 30] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Notifications and configure the thresholds to generate the standard Ethernet OAM events. There is one entry in the table for every entry in dot3OamTable that supports OAM events (where dot3OamFunctionsSupported includes the eventSupport bit set). The values in the table are maintained across changes to dot3OamOperStatus. The standard threshold crossing events are: - Errored Symbol Period Event. Generated when the number of symbol errors exceeds a threshold within a given window defined by a number of symbols (for example, 1,000 symbols out of 1,000,000 had errors). - Errored Frame Period Event. Generated when the number of frame errors exceeds a threshold within a given window defined by a number of frames (for example, 10 frames out of 1000 had errors). - Errored Frame Event. Generated when the number of frame errors exceeds a threshold within a given window defined by a period of time (for example, 10 frames in 1 second had errors). - Errored Frame Seconds Summary Event. Generated when the number of errored frame seconds exceeds a threshold within a given time period (for example, 10 errored frame seconds within the last 100 seconds). An errored frame second is defined as a 1 second interval which had >0 frame errors. There are other events (dying gasp, critical events) that are not threshold crossing events but which can be enabled/disabled via this table. " ::= { dot3OamObjects 5 } dot3OamEventConfigEntry OBJECT-TYPE SYNTAX Dot3OamEventConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries are automatically created and deleted from this table, and exist whenever the OAM entity supports Ethernet OA events (as indicated by the eventSupport bit in dot3OamFunctionsSuppported). Values in the table are maintained across changes to the value of dot3OamOperStatus. Event configuration controls when the local management entity sends Event Notification OAMPDUs to its OAM peer, and when certain event flags are set or cleared in OAMPDUs. " INDEX { ifIndex } ::= { dot3OamEventConfigTable 1 } Squire Standards Track [Page 31] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Dot3OamEventConfigEntry ::= SEQUENCE { dot3OamErrSymPeriodWindowHi Unsigned32, dot3OamErrSymPeriodWindowLo Unsigned32, dot3OamErrSymPeriodThresholdHi Unsigned32, dot3OamErrSymPeriodThresholdLo Unsigned32, dot3OamErrSymPeriodEvNotifEnable TruthValue, dot3OamErrFramePeriodWindow Unsigned32, dot3OamErrFramePeriodThreshold Unsigned32, dot3OamErrFramePeriodEvNotifEnable TruthValue, dot3OamErrFrameWindow Unsigned32, dot3OamErrFrameThreshold Unsigned32, dot3OamErrFrameEvNotifEnable TruthValue, dot3OamErrFrameSecsSummaryWindow Integer32, dot3OamErrFrameSecsSummaryThreshold Integer32, dot3OamErrFrameSecsEvNotifEnable TruthValue, dot3OamDyingGaspEnable TruthValue, dot3OamCriticalEventEnable TruthValue } dot3OamErrSymPeriodWindowHi OBJECT-TYPE SYNTAX Unsigned32 UNITS "2^32 symbols" MAX-ACCESS read-write STATUS current DESCRIPTION "The two objects dot3OamErrSymPeriodWindowHi and dot3OamErrSymPeriodLo together form an unsigned 64-bit integer representing the number of symbols over which this threshold event is defined. This is defined as dot3OamErrSymPeriodWindow = ((2^32)*dot3OamErrSymPeriodWindowHi) + dot3OamErrSymPeriodWindowLo If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating that the threshold has been crossed in this window. The default value for dot3OamErrSymPeriodWindow is the number of symbols in one second for the underlying physical layer. " REFERENCE "[802.3ah], 30.3.6.1.34" ::= { dot3OamEventConfigEntry 1 } dot3OamErrSymPeriodWindowLo OBJECT-TYPE SYNTAX Unsigned32 UNITS "symbols" Squire Standards Track [Page 32] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 MAX-ACCESS read-write STATUS current DESCRIPTION "The two objects dot3OamErrSymPeriodWindowHi and dot3OamErrSymPeriodWindowLo together form an unsigned 64-bit integer representing the number of symbols over which this threshold event is defined. This is defined as dot3OamErrSymPeriodWindow = ((2^32)*dot3OamErrSymPeriodWindowHi) + dot3OamErrSymPeriodWindowLo If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating that the threshold has been crossed in this window. The default value for dot3OamErrSymPeriodWindow is the number of symbols in one second for the underlying physical layer. " REFERENCE "[802.3ah], 30.3.6.1.34" ::= { dot3OamEventConfigEntry 2 } dot3OamErrSymPeriodThresholdHi OBJECT-TYPE SYNTAX Unsigned32 UNITS "2^32 symbols" MAX-ACCESS read-write STATUS current DESCRIPTION "The two objects dot3OamErrSymPeriodThresholdHi and dot3OamErrSymPeriodThresholdLo together form an unsigned 64-bit integer representing the number of symbol errors that must occur within a given window to cause this event. This is defined as dot3OamErrSymPeriodThreshold = ((2^32) * dot3OamErrSymPeriodThresholdHi) + dot3OamErrSymPeriodThresholdLo If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating that the threshold has been crossed in this window. The default value for dot3OamErrSymPeriodThreshold is one symbol errors. If the threshold value is zero, then an Event Squire Standards Track [Page 33] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Notification OAMPDU is sent periodically (at the end of every window). This can be used as an asynchronous notification to the peer OAM entity of the statistics related to this threshold crossing alarm. " REFERENCE "[802.3ah], 30.3.6.1.34" ::= { dot3OamEventConfigEntry 3 } dot3OamErrSymPeriodThresholdLo OBJECT-TYPE SYNTAX Unsigned32 UNITS "symbols" MAX-ACCESS read-write STATUS current DESCRIPTION "The two objects dot3OamErrSymPeriodThresholdHi and dot3OamErrSymPeriodThresholdLo together form an unsigned 64-bit integer representing the number of symbol errors that must occur within a given window to cause this event. This is defined as dot3OamErrSymPeriodThreshold = ((2^32) * dot3OamErrSymPeriodThresholdHi) + dot3OamErrSymPeriodThresholdLo If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating that the threshold has been crossed in this window. The default value for dot3OamErrSymPeriodThreshold is one symbol error. If the threshold value is zero, then an Event Notification OAMPDU is sent periodically (at the end of every window). This can be used as an asynchronous notification to the peer OAM entity of the statistics related to this threshold crossing alarm. " REFERENCE "[802.3ah], 30.3.6.1.34" ::= { dot3OamEventConfigEntry 4 } dot3OamErrSymPeriodEvNotifEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true, the OAM entity should send an Event Notification OAMPDU when an Errored Symbol Period Event occurs. Squire Standards Track [Page 34] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 By default, this object should have the value true for Ethernet-like interfaces that support OAM. If the OAM layer does not support Event Notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. " ::= { dot3OamEventConfigEntry 5 } dot3OamErrFramePeriodWindow OBJECT-TYPE SYNTAX Unsigned32 UNITS "frames" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of frames over which the threshold is defined. The default value of the window is the number of minimum size Ethernet frames that can be received over the physical layer in one second. If dot3OamErrFramePeriodThreshold frame errors occur within a window of dot3OamErrFramePeriodWindow frames, an Event Notification OAMPDU should be generated with an Errored Frame Period Event TLV indicating that the threshold has been crossed in this window. " REFERENCE "[802.3ah], 30.3.6.1.38" ::= { dot3OamEventConfigEntry 6 } dot3OamErrFramePeriodThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "frames" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of frame errors that must occur for this event to be triggered. The default value is one frame error. If the threshold value is zero, then an Event Notification OAMPDU is sent periodically (at the end of every window). This can be used as an asynchronous notification to the peer OAM entity of the statistics related to this threshold crossing alarm. If dot3OamErrFramePeriodThreshold frame errors occur within a window of dot3OamErrFramePeriodWindow frames, an Event Notification OAMPDU should be generated with an Errored Frame Period Event TLV indicating that the threshold has been crossed in this window. " REFERENCE "[802.3ah], 30.3.6.1.38" Squire Standards Track [Page 35] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 ::= { dot3OamEventConfigEntry 7 } dot3OamErrFramePeriodEvNotifEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true, the OAM entity should send an Event Notification OAMPDU when an Errored Frame Period Event occurs. By default, this object should have the value true for Ethernet-like interfaces that support OAM. If the OAM layer does not support Event Notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. " ::= { dot3OamEventConfigEntry 8 } dot3OamErrFrameWindow OBJECT-TYPE SYNTAX Unsigned32 UNITS "tenths of a second" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time (in 100ms increments) over which the threshold is defined. The default value is 10 (1 second). If dot3OamErrFrameThreshold frame errors occur within a window of dot3OamErrFrameWindow seconds (measured in tenths of seconds), an Event Notification OAMPDU should be generated with an Errored Frame Event TLV indicating that the threshold has been crossed in this window. " REFERENCE "[802.3ah], 30.3.6.1.36" DEFVAL { 10 } ::= { dot3OamEventConfigEntry 9 } dot3OamErrFrameThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "frames" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of frame errors that must occur for this event to be triggered. The default value is one frame error. If the threshold value is zero, then an Event Notification OAMPDU is sent periodically (at the end of every window). This can be used as an asynchronous notification to the peer OAM entity of the statistics related to this threshold crossing alarm. Squire Standards Track [Page 36] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 If dot3OamErrFrameThreshold frame errors occur within a window of dot3OamErrFrameWindow (in tenths of seconds), an Event Notification OAMPDU should be generated with an Errored Frame Event TLV indicating the threshold has been crossed in this window. " REFERENCE "[802.3ah], 30.3.6.1.36" DEFVAL { 1 } ::= { dot3OamEventConfigEntry 10 } dot3OamErrFrameEvNotifEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true, the OAM entity should send an Event Notification OAMPDU when an Errored Frame Event occurs. By default, this object should have the value true for Ethernet-like interfaces that support OAM. If the OAM layer does not support Event Notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. " DEFVAL { true } ::= { dot3OamEventConfigEntry 11 } dot3OamErrFrameSecsSummaryWindow OBJECT-TYPE SYNTAX Integer32 (100..9000) UNITS "tenths of a second" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time (in 100 ms intervals) over which the threshold is defined. The default value is 100 (10 seconds). If dot3OamErrFrameSecsSummaryThreshold frame errors occur within a window of dot3OamErrFrameSecsSummaryWindow (in tenths of seconds), an Event Notification OAMPDU should be generated with an Errored Frame Seconds Summary Event TLV indicating that the threshold has been crossed in this window. " REFERENCE "[802.3ah], 30.3.6.1.40" DEFVAL { 100 } ::= { dot3OamEventConfigEntry 12 } dot3OamErrFrameSecsSummaryThreshold OBJECT-TYPE SYNTAX Integer32 (1..900) Squire Standards Track [Page 37] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 UNITS "errored frame seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of errored frame seconds that must occur for this event to be triggered. The default value is one errored frame second. If the threshold value is zero, then an Event Notification OAMPDU is sent periodically (at the end of every window). This can be used as an asynchronous notification to the peer OAM entity of the statistics related to this threshold crossing alarm. If dot3OamErrFrameSecsSummaryThreshold frame errors occur within a window of dot3OamErrFrameSecsSummaryWindow (in tenths of seconds), an Event Notification OAMPDU should be generated with an Errored Frame Seconds Summary Event TLV indicating that the threshold has been crossed in this window. " REFERENCE "[802.3ah], 30.3.6.1.40" DEFVAL { 1 } ::= { dot3OamEventConfigEntry 13 } dot3OamErrFrameSecsEvNotifEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true, the local OAM entity should send an Event Notification OAMPDU when an Errored Frame Seconds Event occurs. By default, this object should have the value true for Ethernet-like interfaces that support OAM. If the OAM layer does not support Event Notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. " DEFVAL { true } ::= { dot3OamEventConfigEntry 14 } dot3OamDyingGaspEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true, the local OAM entity should attempt to indicate a dying gasp via the OAMPDU flags field to its peer OAM entity when a dying gasp event occurs. The exact definition of a dying gasp event is implementation dependent. If the system Squire Standards Track [Page 38] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 does not support dying gasp capability, setting this object has no effect, and reading the object should always result in 'false'. By default, this object should have the value true for Ethernet-like interfaces that support OAM. If the OAM layer does not support Event Notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. " DEFVAL { true } ::= { dot3OamEventConfigEntry 15 } dot3OamCriticalEventEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true, the local OAM entity should attempt to indicate a critical event via the OAMPDU flags to its peer OAM entity when a critical event occurs. The exact definition of a critical event is implementation dependent. If the system does not support critical event capability, setting this object has no effect, and reading the object should always result in 'false'. By default, this object should have the value true for Ethernet-like interfaces that support OAM. If the OAM layer does not support Event Notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. " DEFVAL { true } ::= { dot3OamEventConfigEntry 16 } -- ************************************************************** -- -- Ethernet OAM Event Log group -- dot3OamEventLogTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3OamEventLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table records a history of the events that have occurred at the Ethernet OAM level. These events can include locally detected events, which may result in locally generated OAMPDUs, and remotely detected events, which are detected by the OAM peer entity and signaled to the local entity via Squire Standards Track [Page 39] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Ethernet OAM. Ethernet OAM events can be signaled by Event Notification OAMPDUs or by the flags field in any OAMPDU. This table contains both threshold crossing events and non-threshold crossing events. The parameters for the threshold window, threshold value, and actual value (dot3OamEventLogWindowXX, dot3OamEventLogThresholdXX, dot3OamEventLogValue) are only applicable to threshold crossing events, and are returned as all F's (2^32 - 1) for non-threshold crossing events. Entries in the table are automatically created when such events are detected. The size of the table is implementation dependent. When the table reaches its maximum size, older entries are automatically deleted to make room for newer entries. " ::= { dot3OamObjects 6 } dot3OamEventLogEntry OBJECT-TYPE SYNTAX Dot3OamEventLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dot3OamEventLogTable. Entries are automatically created whenever Ethernet OAM events occur at the local OAM entity, and when Event Notification OAMPDUs are received at the local OAM entity (indicating that events have occurred at the peer OAM entity). The size of the table is implementation dependent, but when the table becomes full, older events are automatically deleted to make room for newer events. The table index dot3OamEventLogIndex increments for each new entry, and when the maximum value is reached, the value restarts at zero. " INDEX { ifIndex, dot3OamEventLogIndex } ::= { dot3OamEventLogTable 1 } Dot3OamEventLogEntry ::= SEQUENCE { dot3OamEventLogIndex Unsigned32, dot3OamEventLogTimestamp TimeStamp, dot3OamEventLogOui EightOTwoOui, dot3OamEventLogType Unsigned32, dot3OamEventLogLocation INTEGER, dot3OamEventLogWindowHi Unsigned32, dot3OamEventLogWindowLo Unsigned32, dot3OamEventLogThresholdHi Unsigned32, Squire Standards Track [Page 40] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 dot3OamEventLogThresholdLo Unsigned32, dot3OamEventLogValue CounterBasedGauge64, dot3OamEventLogRunningTotal CounterBasedGauge64, dot3OamEventLogEventTotal Unsigned32 } dot3OamEventLogIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer for identifying individual events within the event log. " ::= { dot3OamEventLogEntry 1 } dot3OamEventLogTimestamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the logged event. For locally generated events, the time of the event can be accurately retrieved from sysUpTime. For remotely generated events, the time of the event is indicated by the reception of the Event Notification OAMPDU indicating that the event occurred on the peer. A system may attempt to adjust the timestamp value to more accurately reflect the time of the event at the peer OAM entity by using other information, such as that found in the timestamp found of the Event Notification TLVs, which provides an indication of the relative time between events at the peer entity. " ::= { dot3OamEventLogEntry 2 } dot3OamEventLogOui OBJECT-TYPE SYNTAX EightOTwoOui MAX-ACCESS read-only STATUS current DESCRIPTION "The OUI of the entity defining the object type. All IEEE 802.3 defined events (as appearing in [802.3ah] except for the Organizationally Unique Event TLVs) use the IEEE 802.3 OUI of 0x0180C2. Organizations defining their own Event Notification TLVs include their OUI in the Event Notification TLV that gets reflected here. " ::= { dot3OamEventLogEntry 3 } dot3OamEventLogType OBJECT-TYPE SYNTAX Unsigned32 Squire Standards Track [Page 41] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The type of event that generated this entry in the event log. When the OUI is the IEEE 802.3 OUI of 0x0180C2, the following event types are defined: erroredSymbolEvent(1), erroredFramePeriodEvent(2), erroredFrameEvent(3), erroredFrameSecondsEvent(4), linkFault(256), dyingGaspEvent(257), criticalLinkEvent(258) The first four are considered threshold crossing events, as they are generated when a metric exceeds a given value within a specified window. The other three are not threshold crossing events. When the OUI is not 71874 (0x0180C2 in hex), then some other organization has defined the event space. If event subtyping is known to the implementation, it may be reflected here. Otherwise, this value should return all F's (2^32 - 1). " REFERENCE "[802.3ah], 30.3.6.1.10 and 57.5.3." ::= { dot3OamEventLogEntry 4 } dot3OamEventLogLocation OBJECT-TYPE SYNTAX INTEGER { local(1), remote(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether this event occurred locally (local(1)), or was received from the OAM peer via Ethernet OAM (remote(2)). " ::= { dot3OamEventLogEntry 5 } dot3OamEventLogWindowHi OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the event represents a threshold crossing event, the two objects dot3OamEventWindowHi and dot3OamEventWindowLo, form an unsigned 64-bit integer yielding the window over which the value was measured for the threshold crossing event (for example, 5, when 11 occurrences happened in 5 seconds while the threshold was 10). The two objects are combined as: Squire Standards Track [Page 42] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 dot3OamEventLogWindow = ((2^32) * dot3OamEventLogWindowHi) + dot3OamEventLogWindowLo Otherwise, this value is returned as all F's (2^32 - 1) and adds no useful information. " REFERENCE "[802.3ah], 30.3.6.1.37 and 57.5.3.2." ::= { dot3OamEventLogEntry 6 } dot3OamEventLogWindowLo OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the event represents a threshold crossing event, the two objects dot3OamEventWindowHi and dot3OamEventWindowLo form an unsigned 64-bit integer yielding the window over which the value was measured for the threshold crossing event (for example, 5, when 11 occurrences happened in 5 seconds while the threshold was 10). The two objects are combined as: dot3OamEventLogWindow = ((2^32) * dot3OamEventLogWindowHi) + dot3OamEventLogWindowLo Otherwise, this value is returned as all F's (2^32 - 1) and adds no useful information. " REFERENCE "[802.3ah], 30.3.6.1.37 and 57.5.3.2." ::= { dot3OamEventLogEntry 7 } dot3OamEventLogThresholdHi OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the event represents a threshold crossing event, the two objects dot3OamEventThresholdHi and dot3OamEventThresholdLo form an unsigned 64-bit integer yielding the value that was crossed for the threshold crossing event (for example, 10, when 11 occurrences happened in 5 seconds while the threshold was 10). The two objects are combined as: dot3OamEventLogThreshold = ((2^32) * dot3OamEventLogThresholdHi) + dot3OamEventLogThresholdLo Otherwise, this value is returned as all F's (2^32 -1) and adds no useful information. " Squire Standards Track [Page 43] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 REFERENCE "[802.3ah], 30.3.6.1.37 and 57.5.3.2." ::= { dot3OamEventLogEntry 8 } dot3OamEventLogThresholdLo OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the event represents a threshold crossing event, the two objects dot3OamEventThresholdHi and dot3OamEventThresholdLo form an unsigned 64-bit integer yielding the value that was crossed for the threshold crossing event (for example, 10, when 11 occurrences happened in 5 seconds while the threshold was 10). The two objects are combined as: dot3OamEventLogThreshold = ((2^32) * dot3OamEventLogThresholdHi) + dot3OamEventLogThresholdLo Otherwise, this value is returned as all F's (2^32 - 1) and adds no useful information. " REFERENCE "[802.3ah], 30.3.6.1.37 and 57.5.3.2." ::= { dot3OamEventLogEntry 9 } dot3OamEventLogValue OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "If the event represents a threshold crossing event, this value indicates the value of the parameter within the given window that generated this event (for example, 11, when 11 occurrences happened in 5 seconds while the threshold was 10). Otherwise, this value is returned as all F's (2^64 - 1) and adds no useful information. " REFERENCE "[802.3ah], 30.3.6.1.37 and 57.5.3.2." ::= { dot3OamEventLogEntry 10 } dot3OamEventLogRunningTotal OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "Each Event Notification TLV contains a running total of the number of times an event has occurred, as well as the number of times an Event Notification for the event has been Squire Standards Track [Page 44] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 transmitted. For non-threshold crossing events, the number of events (dot3OamLogRunningTotal) and the number of resultant Event Notifications (dot3OamLogEventTotal) should be identical. For threshold crossing events, since multiple occurrences may be required to cross the threshold, these values are likely different. This value represents the total number of times this event has happened since the last reset (for example, 3253, when 3253 symbol errors have occurred since the last reset, which has resulted in 51 symbol error threshold crossing events since the last reset). " REFERENCE "[802.3ah], 30.3.6.1.37 and 57.5.3.2." ::= { dot3OamEventLogEntry 11 } dot3OamEventLogEventTotal OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Each Event Notification TLV contains a running total of the number of times an event has occurred, as well as the number of times an Event Notification for the event has been transmitted. For non-threshold crossing events, the number of events (dot3OamLogRunningTotal) and the number of resultant Event Notifications (dot3OamLogEventTotal) should be identical. For threshold crossing events, since multiple occurrences may be required to cross the threshold, these values are likely different. This value represents the total number of times one or more of these occurrences have resulted in an Event Notification (for example, 51 when 3253 symbol errors have occurred since the last reset, which has resulted in 51 symbol error threshold crossing events since the last reset). " REFERENCE "[802.3ah], 30.3.6.1.37 and 57.5.3.2." ::= { dot3OamEventLogEntry 12 } -- *************************************************************** -- -- Ethernet OAM Notifications -- dot3OamThresholdEvent NOTIFICATION-TYPE OBJECTS { dot3OamEventLogTimestamp, dot3OamEventLogOui, Squire Standards Track [Page 45] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 dot3OamEventLogType, dot3OamEventLogLocation, dot3OamEventLogWindowHi, dot3OamEventLogWindowLo, dot3OamEventLogThresholdHi, dot3OamEventLogThresholdLo, dot3OamEventLogValue, dot3OamEventLogRunningTotal, dot3OamEventLogEventTotal } STATUS current DESCRIPTION "A dot3OamThresholdEvent notification is sent when a local or remote threshold crossing event is detected. A local threshold crossing event is detected by the local entity, while a remote threshold crossing event is detected by the reception of an Ethernet OAM Event Notification OAMPDU that indicates a threshold event. This notification should not be sent more than once per second. The OAM entity can be derived from extracting the ifIndex from the variable bindings. The objects in the notification correspond to the values in a row instance in the dot3OamEventLogTable. The management entity should periodically check dot3OamEventLogTable to detect any missed events." ::= { dot3OamNotifications 1 } dot3OamNonThresholdEvent NOTIFICATION-TYPE OBJECTS { dot3OamEventLogTimestamp, dot3OamEventLogOui, dot3OamEventLogType, dot3OamEventLogLocation, dot3OamEventLogEventTotal } STATUS current DESCRIPTION "A dot3OamNonThresholdEvent notification is sent when a local or remote non-threshold crossing event is detected. A local event is detected by the local entity, while a remote event is detected by the reception of an Ethernet OAM Event Notification OAMPDU that indicates a non-threshold crossing event. This notification should not be sent more than once per Squire Standards Track [Page 46] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 second. The OAM entity can be derived from extracting the ifIndex from the variable bindings. The objects in the notification correspond to the values in a row instance of the dot3OamEventLogTable. The management entity should periodically check dot3OamEventLogTable to detect any missed events." ::= { dot3OamNotifications 2 } -- *************************************************************** -- -- Ethernet OAM Compliance group -- dot3OamGroups OBJECT IDENTIFIER ::= { dot3OamConformance 1 } dot3OamCompliances OBJECT IDENTIFIER ::= { dot3OamConformance 2 } -- Compliance statements dot3OamCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for managed entities supporting OAM on Ethernet-like interfaces. " MODULE -- this module MANDATORY-GROUPS { dot3OamControlGroup, dot3OamPeerGroup, dot3OamStatsBaseGroup } GROUP dot3OamLoopbackGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OA implementations that support loopback functionality. " GROUP dot3OamErrSymbolPeriodEventGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OA implementations that support event functionality. " GROUP dot3OamErrFramePeriodEventGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OA implementations that support event functionality. " GROUP dot3OamErrFrameEventGroup Squire Standards Track [Page 47] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 DESCRIPTION "This group is mandatory for all IEEE 802.3 OA implementations that support event functionality. " GROUP dot3OamErrFrameSecsSummaryEventGroup DESCRIPTION "This group is mandatory for all IEEE 802.3 OA implementations that support event functionality. " GROUP dot3OamFlagEventGroup DESCRIPTION "This group is optional for all IEEE 802.3 OA implementations. The ability to send critical events or dying gasp events is not required in any system." GROUP dot3OamEventLogGroup DESCRIPTION "This group is optional for all IEEE 802.3 OA implementations. Entries in this table are dependent on what event functionality is supported in the local OA implementation. At least one type of event must be supported for entries to appear in this table. " GROUP dot3OamNotificationGroup DESCRIPTION "This group is optional for all IEEE 802.3 OA implementations. Since the information in the notifications is dependent on the dot3OamEventLogTable, that table must be implemented for notifications. " ::= { dot3OamCompliances 1} dot3OamControlGroup OBJECT-GROUP OBJECTS { dot3OamAdminState, dot3OamOperStatus, dot3OamMode, dot3OamMaxOamPduSize, dot3OamConfigRevision, dot3OamFunctionsSupported } STATUS current DESCRIPTION "A collection of objects providing the abilities, configuration, and status of an Ethernet OAM entity. " ::= { dot3OamGroups 1 } dot3OamPeerGroup OBJECT-GROUP OBJECTS { dot3OamPeerMacAddress, Squire Standards Track [Page 48] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 dot3OamPeerVendorOui, dot3OamPeerVendorInfo, dot3OamPeerMode, dot3OamPeerFunctionsSupported, dot3OamPeerMaxOamPduSize, dot3OamPeerConfigRevision } STATUS current DESCRIPTION "A collection of objects providing the abilities, configuration, and status of a peer Ethernet OAM entity. " ::= { dot3OamGroups 2 } dot3OamStatsBaseGroup OBJECT-GROUP OBJECTS { dot3OamInformationTx, dot3OamInformationRx, dot3OamUniqueEventNotificationTx, dot3OamUniqueEventNotificationRx, dot3OamDuplicateEventNotificationTx, dot3OamDuplicateEventNotificationRx, dot3OamLoopbackControlTx, dot3OamLoopbackControlRx, dot3OamVariableRequestTx, dot3OamVariableRequestRx, dot3OamVariableResponseTx, dot3OamVariableResponseRx, dot3OamOrgSpecificTx, dot3OamOrgSpecificRx, dot3OamUnsupportedCodesTx, dot3OamUnsupportedCodesRx, dot3OamFramesLostDueToOam } STATUS current DESCRIPTION "A collection of objects providing the statistics for the number of various transmit and receive events for OAM on an Ethernet-like interface. Note that all of these counters must be supported even if the related function (as described in dot3OamFunctionsSupported) is not supported. " ::= { dot3OamGroups 3 } dot3OamLoopbackGroup OBJECT-GROUP OBJECTS { dot3OamLoopbackStatus, dot3OamLoopbackIgnoreRx } STATUS current DESCRIPTION "A collection of objects for controlling the OAM remote Squire Standards Track [Page 49] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 loopback function. " ::= { dot3OamGroups 4 } dot3OamErrSymbolPeriodEventGroup OBJECT-GROUP OBJECTS { dot3OamErrSymPeriodWindowHi, dot3OamErrSymPeriodWindowLo, dot3OamErrSymPeriodThresholdHi, dot3OamErrSymPeriodThresholdLo, dot3OamErrSymPeriodEvNotifEnable } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Symbol Period Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " ::= { dot3OamGroups 5 } dot3OamErrFramePeriodEventGroup OBJECT-GROUP OBJECTS { dot3OamErrFramePeriodWindow, dot3OamErrFramePeriodThreshold, dot3OamErrFramePeriodEvNotifEnable } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Frame Period Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " ::= { dot3OamGroups 6 } dot3OamErrFrameEventGroup OBJECT-GROUP OBJECTS { dot3OamErrFrameWindow, dot3OamErrFrameThreshold, dot3OamErrFrameEvNotifEnable } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Frame Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " Squire Standards Track [Page 50] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 ::= { dot3OamGroups 7 } dot3OamErrFrameSecsSummaryEventGroup OBJECT-GROUP OBJECTS { dot3OamErrFrameSecsSummaryWindow, dot3OamErrFrameSecsSummaryThreshold, dot3OamErrFrameSecsEvNotifEnable } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Frame Seconds Summary Event. Each [802.3ah] defined Event Notification TLV has its own conformance group because each event can be implemented independently of any other. " ::= { dot3OamGroups 8 } dot3OamFlagEventGroup OBJECT-GROUP OBJECTS { dot3OamDyingGaspEnable, dot3OamCriticalEventEnable } STATUS current DESCRIPTION "A collection of objects for configuring the sending OAMPDUs with the critical event flag or dying gasp flag enabled. " ::= { dot3OamGroups 9 } dot3OamEventLogGroup OBJECT-GROUP OBJECTS { dot3OamEventLogTimestamp, dot3OamEventLogOui, dot3OamEventLogType, dot3OamEventLogLocation, dot3OamEventLogWindowHi, dot3OamEventLogWindowLo, dot3OamEventLogThresholdHi, dot3OamEventLogThresholdLo, dot3OamEventLogValue, dot3OamEventLogRunningTotal, dot3OamEventLogEventTotal } STATUS current DESCRIPTION "A collection of objects for configuring the thresholds for an Errored Frame Seconds Summary Event and maintaining the event information. " ::= { dot3OamGroups 10 } dot3OamNotificationGroup NOTIFICATION-GROUP Squire Standards Track [Page 51] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 NOTIFICATIONS { dot3OamThresholdEvent, dot3OamNonThresholdEvent } STATUS current DESCRIPTION "A collection of notifications used by Ethernet OAM to signal to a management entity that local or remote events have occurred on a specified Ethernet link. " ::= { dot3OamGroups 11 } END 7. Security Considerations The readable objects in this module can provide information about network traffic, and therefore may be considered sensitive. In particular, OAM provides mechanisms for reading the IEEE 802.3 Clause 30 MIB attributes from a link partner via a specialized layer two protocol. Unlike SNMP, IEEE P802.3ah OAM does not include encryption or authentication mechanisms. It should be used in environments where either this interface information is not considered sensitive, or where the facility terminations are protected. By default, OAM is disabled on Ethernet-like interfaces and is therefore not a risk. IEEE 802.3ah OAM is designed to support deployment in access and enterprise networks. In access networks, one end of a link is the CO-side, and the other is the CPE-side, and the facilities are often protected in wiring cages or closets. In such deployments, it is often the case that the CO-side is protected from access from the CPE-side. Within IEEE P802.3ah OAM, this protection from remote access is accomplished by configuring the CPE-side in passive mode using the dot3OamMode attribute. This prevents the CPE from accessing functions and information at the CO-side of the connection. In enterprise networks, read-only interface information is often considered non-sensitive. The frequency of OAM PDUs on an Ethernet interface does not adversely affect data traffic, as OAM is a slow protocol with very limited bandwidth potential, and it is not required for normal link operation. And although there are a number of objects in this module with read-write or read-create MAX-ACCESS, they have limited effects on user data. The loopback capability of OAM can have potentially disruptive effects in that the when enabling remote loopback, the remote station automatically transmits all received traffic back to the local station except for OAM traffic. This completely disrupts all higher Squire Standards Track [Page 52] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 layer protocols such as bridging, IP, and SNMP. Therefore an attribute (dot3OamLoopbackIgnoreRx) was introduced to control whether the local station processes or ignores received loopback commands. The administrative state and mode are also read-write objects. Disabling OAM can interrupt management activities between peer devices, potentially causing serious problems. Setting the dot3OamMode to an undesired value can allow access to Ethernet monitoring, events, and functions that may not be acceptable in a particular deployment scenario. In addition to loopback functionality, Ethernet interface statistics and events can be accessed via the OAM protocol, which may not be desired in some circumstances. OAM event configuration also contains read-write objects. These objects control whether events are sent, and at what thresholds. Note that the frequency of event communication is limited by the frequency limits of Slow Protocols on Ethernet interfaces. Also, the information available via OAM events is also available via OA Variable Requests. Access to this information via either OAM events or Variable Requests is controlled by the dot3OamAdminState and dot3OamMode objects. As mentioned previously, inadequate protection of these variables can result in access to link information and functions. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Squire Standards Track [Page 53] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 8. IANA Considerations The Ethernet OAM MIB requires the allocation of a single object identifier for its MODULE-IDENTITY under the MIB-2 tree. The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER ---------- ----------------- dot3OamMIB { mib-2 158 } 9. References 9.1. Normative References [802.3ah] Institute of Electrical and Electronic Engineers, IEEE Std 802.3ah-2004, "Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks", October 2004. [802.3-2002] Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2003, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Draft amendment to - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters", March 2002. Squire Standards Track [Page 54] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 [802.3-2005] Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2005, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Draft amendment to - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters", December 2005. [802-2001] Institute of Electrical and Electronic Engineers, IEEE Std 802-2001, "Standard for Local and Metropolitan Area Networks: Architecture and Overview", March 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. 9.2. Informative References [802.3ah-copper] Beili, Ed, "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB", Work in Progress, February 2007. Squire Standards Track [Page 55] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 [802.3ah-epon] Khermosh, L., "Managed Objects of Ethernet Passive Optical Networks (EPON)", RFC 4837, June 2007. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003. 10. Acknowledgments The author is grateful to all of the participants in the IEEE 802.3ah EFM (Ethernet in the First Mile) taskforce. In particular, the strong leadership and dedication of the following individuals is noted: Kevin Daines (Editor, IEEE 802.3ah OAM clauses) Ben Brown (Editor, IEEE 802.3ah Logic clauses) David Law (Editor, IEEE 802.3ah Management clauses) Scott Simon (Editor, IEEE 802.3ah Clause 45) Howard Frazier (Chair, IEEE 802.3ah) Hugh Barass (Vice-Chair, IEEE 802.3ah) Wael Diab (Editor, IEEE 802.3ah) Additionally, certain devoted attendees and contributors to the IEEE 802.3ah OAM sub-taskforce deserve recognition. Although there were many contributors, the following individuals contributed heavily over a long period of time. Brian Arnold Brad Booth Al Braga Floyd Gerhardt Bob Grow Eric Lynskey David Martin John Messenger Dan Romascanu (Ex-Chair, IETF HUBMIB WG) Jonathan Thatcher Geoff Thompson Squire Standards Track [Page 56] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Author's Address Matt Squire Hatteras Networks 529 Davis Drive Durham, NC 27713 EMail: msquire@hatterasnetworks.com Squire Standards Track [Page 57] RFC 4878 OAM Functions on Ethernet-Like Interfaces June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Squire Standards Track [Page 58] snmp-mibs-downloader-1.1/mibrfcs/rfc4898.txt0000644000000000000000000045425011402176072015611 0ustar Network Working Group M. Mathis Request for Comments: 4898 J. Heffner Category: Standards Track Pittsburgh Supercomputing Center R. Raghunarayan Cisco Systems May 2007 TCP Extended Statistics MIB 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Overview ........................................................2 3.1. MIB Initialization and Persistence .........................4 3.2. Relationship to TCP Standards ..............................4 3.3. Diagnosing SYN-Flood Denial-of-Service Attacks .............6 4. TCP Extended Statistics MIB .....................................7 5. Security Considerations ........................................69 6. IANA Considerations ............................................70 7. Normative References ...........................................70 8. Informative References .........................................72 9. Contributors ...................................................73 10. Acknowledgments ...............................................73 Mathis, et al. Standards Track [Page 1] RFC 4898 TCP Extended Statistics MIB May 2007 1. Introduction This document describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The Simple Network Management Protocol (SNMP) objects defined in this document extend TCP MIB, as specified in RFC 4022 [RFC4022]. In addition to several new scalars and other objects, it augments two tables and makes one clarification to RFC 4022. Existing management stations for the TCP MIB are expected to be fully compatible with these clarifications. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The TCP-ESTATS-MIB defined in this memo consists of two groups of scalars, seven tables, and two notifications: * The first group of scalars contain statistics of the TCP protocol engine not covered in RFC 4022. This group consists of the single scalar tcpEStatsListenerTableLastChange, which provides management stations with an easier mechanism to validate their listener caches. Mathis, et al. Standards Track [Page 2] RFC 4898 TCP Extended Statistics MIB May 2007 * The second group of scalars consist of knobs to enable and disable information collection by the tables containing connection-related statistics/information. For example, the tcpEStatsControlPath object controls the activation of the tcpEStatsPathTable. The tcpEStatsConnTableLatency object determines how long connection table rows are retained after a TCP connection transitions into the closed state. * The tcpEStatsListenerTable augments tcpListenerTable in TCP-MIB [RFC4022] to provide additional information on the active TCP listeners on a device. It supports objects to monitor and diagnose SYN-flood denial-of-service attacks as described below. * The tcpEStatsConnectIdTable augments the tcpConnectionTable in TCP-MIB [RFC4022] to provide a mapping between connection 4-tuples (which index tcpConnectionTable) and an integer connection index, tcpEStatsConnectIndex. The connection index is used to index into the five remaining tables in this MIB module, and is designed to facilitate rapid polling of multiple objects associated with one TCP connection. * The tcpEStatsPerfTable contains objects that are useful for measuring TCP performance and first check problem diagnosis. * The tcpEStatsPathTable contains objects that can be used to infer detailed behavior of the Internet path, such as the extent that there are segment losses or reordering, etc. * The tcpEStatsStackTable contains objects that are most useful for determining how well the TCP control algorithms are coping with this particular path. * The tcpEStatsAppTable provides objects that are useful for determining if the application using TCP is limiting TCP performance. * The tcpEStatsTuneTable provides per-connection controls that can be used to work around a number of common problems that plague TCP over some paths. * The two notifications defined in this MIB module are tcpEStatsEstablishNotification, indicating that a new connection has been accepted (or established, see below), and tcpEStatsCloseNotification, indicating that an existing connection has recently closed. Mathis, et al. Standards Track [Page 3] RFC 4898 TCP Extended Statistics MIB May 2007 3.1. MIB Initialization and Persistence The TCP protocol itself is specifically designed not to preserve any state whatsoever across system reboots, and enforces this by requiring randomized Initial Sequence numbers and ephemeral ports under any conditions where segments from old connections might corrupt new connections following a reboot. All of the objects in the MIB MUST have the same persistence properties as the underlying TCP implementation. On a reboot, all zero-based counters MUST be cleared, all dynamically created table rows MUST be deleted, and all read-write objects MUST be restored to their default values. It is assumed that all TCP implementation have some initialization code (if nothing else, to set IP addresses) that has the opportunity to adjust tcpEStatsConnTableLatency and other read-write scalars controlling the creation of the various tables, before establishing the first TCP connection. Implementations MAY also choose to make these control scalars persist across reboots. The ZeroBasedCounter32 and ZeroBasedCounter64 objects in the listener and connection tables are initialized to zero when the table row is created. The tcpEStatsConnTableLatency object determines how long connection table rows are retained after a TCP connection transitions into the closed state, to permit reading final connection completion statistics. In RFC 4022 (TCP-MIB), the discussion of tcpConnectionTable row latency (page 9) the words "soon after" are understood to mean after tcpEStatsConnTableLatency, such that all rows of all tables associated with one connection are retained at least tcpEStatsConnTableLatency after connection close. This clarification to RFC 4022 only applies when TCP-ESTATS-MIB is implemented. If TCP-ESTATS-MIB is not implemented, RFC 4022 permits an unspecified delay between connection close and row deletion. 3.2. Relationship to TCP Standards There are more than 70 RFCs and other documents that specify various aspects of the Transmission Control Protocol (TCP) [RFC4614]. While most protocols are completely specified in one or two documents, this has not proven to be feasible for TCP. TCP implements a reliable end-to-end data transport service over a very weakly constrained IP datagram service. The essential problem that TCP has to solve is balancing the applications need for fast and reliable data transport against the need to make fair, efficient, and equitable use of network resources, with only sparse information about the state of the network or its capabilities. Mathis, et al. Standards Track [Page 4] RFC 4898 TCP Extended Statistics MIB May 2007 TCP maintains this balance through the use of many estimators and heuristics that regulate various aspects of the protocol. For example, RFC 2988 describes how to calculate the retransmission timer (RTO) from the average and variance of the network round-trip-time (RTT), as estimated from the round-trip time sampled on some data segments. Although these algorithms are standardized, they are a compromise which is optimal for only common Internet environments. Other estimators might yield better results (higher performance or more efficient use of the network) in some environments, particularly under uncommon conditions. It is the consensus of the community that nearly all of the estimators and heuristics used in TCP might be improved through further research and development. For this reason, nearly all TCP documents leave some latitude for future improvements, for example, by the use of "SHOULD" instead of "MUST" [RFC2119]. Even standard algorithms that are required because they critically effect fairness or the dynamic stability of Internet congestion control, include some latitude for evolution. As a consequence, there is considerable diversity in the details of the TCP implementations actually in use today. The fact that the underlying algorithms are not uniform makes it difficult to tightly specify a MIB. We could have chosen the point of view that the MIB should publish precisely defined metrics of the network path, even if they are different from the estimators in use by TCP. This would make the MIB more useful as a measurement tool, but less useful for understanding how any specific TCP implementation is interacting with the network path and upper protocol layers. We chose instead to have the MIB expose the estimators and important states variables of the algorithms in use, without constraining the TCP implementation. As a consequence, the MIB objects are defined in terms of fairly abstract descriptions (e.g., round-trip time), but are intended to expose the actual estimators or other state variables as they are used in TCP implementations, possibly transformed (e.g., scaled or otherwise adjusted) to match the spirit of the object descriptions in this document. This may mean that MIB objects may not be exactly comparable between two different TCP implementations. A general management station can only assume the abstract descriptions, which are useful for a general assessment of how TCP is functioning. To a TCP implementer with detailed knowledge about the TCP implementation on a specific host, this MIB might be useful for debugging or evaluating the algorithms in their implementation. Mathis, et al. Standards Track [Page 5] RFC 4898 TCP Extended Statistics MIB May 2007 Under no conditions is this MIB intended to constrain TCP to use (or exclude) any particular estimator, heuristic, algorithm, or implementation. 3.3. Diagnosing SYN-Flood Denial-of-Service Attacks The tcpEStatsListenerTable is specifically designed to provide information that is useful for diagnosing SYN-flood Denial-of-Service attacks, where a server is overwhelmed by forged or otherwise malicious connection attempts. There are several different techniques that can be used to defend against SYN-flooding but none are standardized [Edd06]. These different techniques all have the same basic characteristics that are instrumentable with a common set of objects, even though the techniques differ greatly in the details. All SYN-flood defenses avoid allocating significant resources (memory or CPU) to incoming (passive open) connections until the connections meet some liveness criteria (to defend against forged IP source addresses) and the server has sufficient resources to process the incoming request. Note that allocating resources is an implementation-specific event that may not correspond to an observable protocol event (e.g., segments on the wire). There are two general concepts that can be applied to all known SYN-flood defenses. There is generally a well-defined event when a connection is allocated full resources, and a "backlog" -- a queue of embryonic connections that have been allocated only partial resources. In many implementations, incoming TCP connections are allocated resources as a side effect of the POSIX [POSIX] accept() call. For this reason we use the terminology "accepting a connection" to refer to this event: committing sufficient network resources to process the incoming request. Accepting a connection typically entails allocating memory for the protocol control block [RFC793], the per- connection table rows described in this MIB and CPU resources, such as process table entries or threads. Note that it is not useful to accept connections before they are ESTABLISHED, because this would create an easy opportunity for Denial-of-Service attacks, using forged source IP addresses. The backlog consists of connections that are in SYN-RCVD or ESTABLISHED states, that have not been accepted. For purposes of this MIB, we assume that these connections have been allocated some resources (e.g., an embryonic protocol control block), but not full resources (e.g., do not yet have MIB table rows). Mathis, et al. Standards Track [Page 6] RFC 4898 TCP Extended Statistics MIB May 2007 Note that some SYN-Flood defenses dispense with explicit SYN-RCVD state by cryptographically encoding the state in the ISS (initial sequence number sent) of the SYN-ACK (sometimes called a syn-cookie), and then using the sequence number of the first ACK to reconstruct the SYN-RCVD state before transitioning to the ESTABLISHED state. For these implementations there is no explicit representation of the SYN-RCVD state, and the backlog only consists of connections that are ESTABLISHED and are waiting to be ACCEPTED. Furthermore, most SYN-flood defenses have some mechanism to throttle connections that might otherwise overwhelm this endpoint. They generally use some combination of discarding incoming SYNs and discarding connections already in the backlog. This does not cause all connections from legitimate clients to fail, as long as the clients retransmit the SYN or first ACK as specified in RFC 793. Most diversity in SYN flood defenses arise from variations in these algorithms to limit load, and therefore cannot be instrumented with a common standard MIB. The Listen Table instruments all passively opened TCP connections in terms of observable protocol events (e.g., sent and received segments) and resource allocation events (entering the backlog and being accepted). This approach eases generalization to SYN-flood mechanisms that use alternate TCP state transition diagrams and implicit mechanisms to encode some states. 4. TCP Extended Statistics MIB This MIB module IMPORTS definitions from [RFC2578], [RFC2579], [RFC2580], [RFC2856], [RFC4022], and [RFC4502]. It uses REFERENCE clauses to refer to [RFC791], [RFC793], [RFC1122], [RFC1191], [RFC1323], [RFC2018], [RFC2581], [RFC2861], [RFC2883], [RFC2988], [RFC3168], [RFC3260], [RFC3517], [RFC3522], and [RFC3742]. TCP-ESTATS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Counter32, Integer32, Unsigned32, Gauge32, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] ZeroBasedCounter32 FROM RMON2-MIB -- [RFC4502] ZeroBasedCounter64 FROM HCNUM-TC -- [RFC2856] TEXTUAL-CONVENTION, DateAndTime, TruthValue, TimeStamp Mathis, et al. Standards Track [Page 7] RFC 4898 TCP Extended Statistics MIB May 2007 FROM SNMPv2-TC -- [RFC2579] tcpListenerEntry, tcpConnectionEntry FROM TCP-MIB; -- [RFC4022] tcpEStatsMIB MODULE-IDENTITY LAST-UPDATED "200705180000Z" -- 18 May 2007 ORGANIZATION "IETF TSV Working Group" CONTACT-INFO "Matt Mathis John Heffner Web100 Project Pittsburgh Supercomputing Center 300 S. Craig St. Pittsburgh, PA 15213 Email: mathis@psc.edu, jheffner@psc.edu Rajiv Raghunarayan Cisco Systems Inc. San Jose, CA 95134 Phone: 408 853 9612 Email: raraghun@cisco.com Jon Saperia 84 Kettell Plain Road Stow, MA 01775 Phone: 617-201-2655 Email: saperia@jdscons.com " DESCRIPTION "Documentation of TCP Extended Performance Instrumentation variables from the Web100 project. [Web100] All of the objects in this MIB MUST have the same persistence properties as the underlying TCP implementation. On a reboot, all zero-based counters MUST be cleared, all dynamically created table rows MUST be deleted, and all read-write objects MUST be restored to their default values. It is assumed that all TCP implementation have some initialization code (if nothing else to set IP addresses) that has the opportunity to adjust tcpEStatsConnTableLatency and other read-write scalars controlling the creation of the various tables, before establishing the first TCP connection. Implementations MAY also choose to make these control scalars persist across reboots. Copyright (C) The IETF Trust (2007). This version of this MIB module is a part of RFC 4898; see the RFC itself for full legal notices." Mathis, et al. Standards Track [Page 8] RFC 4898 TCP Extended Statistics MIB May 2007 REVISION "200705180000Z" -- 18 May 2007 DESCRIPTION "Initial version, published as RFC 4898." ::= { mib-2 156 } tcpEStatsNotifications OBJECT IDENTIFIER ::= { tcpEStatsMIB 0 } tcpEStatsMIBObjects OBJECT IDENTIFIER ::= { tcpEStatsMIB 1 } tcpEStatsConformance OBJECT IDENTIFIER ::= { tcpEStatsMIB 2 } tcpEStats OBJECT IDENTIFIER ::= { tcpEStatsMIBObjects 1 } tcpEStatsControl OBJECT IDENTIFIER ::= { tcpEStatsMIBObjects 2 } tcpEStatsScalar OBJECT IDENTIFIER ::= { tcpEStatsMIBObjects 3 } -- -- Textual Conventions -- TcpEStatsNegotiated ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates if some optional TCP feature was negotiated. Enabled(1) indicates that the feature was successfully negotiated on, which generally requires both hosts to agree to use the feature. selfDisabled(2) indicates that the local host refused the feature because it is not implemented, configured off, or refused for some other reason, such as the lack of resources. peerDisabled(3) indicates that the local host was willing to negotiate the feature, but the remote host did not do so." SYNTAX INTEGER { enabled(1), selfDisabled(2), peerDisabled(3) } -- -- TCP Extended statistics scalars -- tcpEStatsListenerTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 9] RFC 4898 TCP Extended Statistics MIB May 2007 "The value of sysUpTime at the time of the last creation or deletion of an entry in the tcpListenerTable. If the number of entries has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { tcpEStatsScalar 3 } -- ================================================================ -- -- The tcpEStatsControl Group -- -- The scalar objects in this group are used to control the -- activation and deactivation of the TCP Extended Statistics -- tables and notifications in this module. -- tcpEStatsControlPath OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the activation of the TCP Path Statistics table. A value 'true' indicates that the TCP Path Statistics table is active, while 'false' indicates that the table is inactive." DEFVAL { false } ::= { tcpEStatsControl 1 } tcpEStatsControlStack OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the activation of the TCP Stack Statistics table. A value 'true' indicates that the TCP Stack Statistics table is active, while 'false' indicates that the table is inactive." DEFVAL { false } ::= { tcpEStatsControl 2 } tcpEStatsControlApp OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write Mathis, et al. Standards Track [Page 10] RFC 4898 TCP Extended Statistics MIB May 2007 STATUS current DESCRIPTION "Controls the activation of the TCP Application Statistics table. A value 'true' indicates that the TCP Application Statistics table is active, while 'false' indicates that the table is inactive." DEFVAL { false } ::= { tcpEStatsControl 3 } tcpEStatsControlTune OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the activation of the TCP Tuning table. A value 'true' indicates that the TCP Tuning table is active, while 'false' indicates that the table is inactive." DEFVAL { false } ::= { tcpEStatsControl 4 } tcpEStatsControlNotify OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the generation of all notifications defined in this MIB. A value 'true' indicates that the notifications are active, while 'false' indicates that the notifications are inactive." DEFVAL { false } ::= { tcpEStatsControl 5 } tcpEStatsConnTableLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the number of seconds that the entity will retain entries in the TCP connection tables, after the connection first enters the closed state. The entity SHOULD provide a configuration option to enable Mathis, et al. Standards Track [Page 11] RFC 4898 TCP Extended Statistics MIB May 2007 customization of this value. A value of 0 results in entries being removed from the tables as soon as the connection enters the closed state. The value of this object pertains to the following tables: tcpEStatsConnectIdTable tcpEStatsPerfTable tcpEStatsPathTable tcpEStatsStackTable tcpEStatsAppTable tcpEStatsTuneTable" DEFVAL { 0 } ::= { tcpEStatsControl 6 } -- ================================================================ -- -- Listener Table -- tcpEStatsListenerTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpEStatsListenerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about TCP Listeners, in addition to the information maintained by the tcpListenerTable RFC 4022." ::= { tcpEStats 1 } tcpEStatsListenerEntry OBJECT-TYPE SYNTAX TcpEStatsListenerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in the table contains information about a specific TCP Listener." AUGMENTS { tcpListenerEntry } ::= { tcpEStatsListenerTable 1 } TcpEStatsListenerEntry ::= SEQUENCE { tcpEStatsListenerStartTime TimeStamp, tcpEStatsListenerSynRcvd ZeroBasedCounter32, tcpEStatsListenerInitial ZeroBasedCounter32, tcpEStatsListenerEstablished ZeroBasedCounter32, tcpEStatsListenerAccepted ZeroBasedCounter32, tcpEStatsListenerExceedBacklog ZeroBasedCounter32, tcpEStatsListenerHCSynRcvd ZeroBasedCounter64, tcpEStatsListenerHCInitial ZeroBasedCounter64, tcpEStatsListenerHCEstablished ZeroBasedCounter64, Mathis, et al. Standards Track [Page 12] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsListenerHCAccepted ZeroBasedCounter64, tcpEStatsListenerHCExceedBacklog ZeroBasedCounter64, tcpEStatsListenerCurConns Gauge32, tcpEStatsListenerMaxBacklog Unsigned32, tcpEStatsListenerCurBacklog Gauge32, tcpEStatsListenerCurEstabBacklog Gauge32 } tcpEStatsListenerStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this listener was established. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { tcpEStatsListenerEntry 1 } tcpEStatsListenerSynRcvd OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SYNs which have been received for this listener. The total number of failed connections for all reasons can be estimated to be tcpEStatsListenerSynRcvd minus tcpEStatsListenerAccepted and tcpEStatsListenerCurBacklog." ::= { tcpEStatsListenerEntry 2 } tcpEStatsListenerInitial OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of connections for which the Listener has allocated initial state and placed the connection in the backlog. This may happen in the SYN-RCVD or ESTABLISHED states, depending on the implementation." ::= { tcpEStatsListenerEntry 3 } tcpEStatsListenerEstablished OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 13] RFC 4898 TCP Extended Statistics MIB May 2007 "The number of connections that have been established to this endpoint (e.g., the number of first ACKs that have been received for this listener)." ::= { tcpEStatsListenerEntry 4 } tcpEStatsListenerAccepted OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of connections for which the Listener has successfully issued an accept, removing the connection from the backlog." ::= { tcpEStatsListenerEntry 5 } tcpEStatsListenerExceedBacklog OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of connections dropped from the backlog by this listener due to all reasons. This includes all connections that are allocated initial resources, but are not accepted for some reason." ::= { tcpEStatsListenerEntry 6 } tcpEStatsListenerHCSynRcvd OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SYNs that have been received for this listener on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerSynRcvd." ::= { tcpEStatsListenerEntry 7 } tcpEStatsListenerHCInitial OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of connections for which the Listener has allocated initial state and placed the connection in the backlog on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerInitial." ::= { tcpEStatsListenerEntry 8 } Mathis, et al. Standards Track [Page 14] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsListenerHCEstablished OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of connections that have been established to this endpoint on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerEstablished." ::= { tcpEStatsListenerEntry 9 } tcpEStatsListenerHCAccepted OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of connections for which the Listener has successfully issued an accept, removing the connection from the backlog on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerAccepted." ::= { tcpEStatsListenerEntry 10 } tcpEStatsListenerHCExceedBacklog OBJECT-TYPE SYNTAX ZeroBasedCounter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of connections dropped from the backlog by this listener due to all reasons on systems that can process (or reject) more than 1 million connections per second. See tcpEStatsListenerExceedBacklog." ::= { tcpEStatsListenerEntry 11 } tcpEStatsListenerCurConns OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of connections in the ESTABLISHED state, which have also been accepted. It excludes connections that have been established but not accepted because they are still subject to being discarded to shed load without explicit action by either endpoint." ::= { tcpEStatsListenerEntry 12 } tcpEStatsListenerMaxBacklog OBJECT-TYPE Mathis, et al. Standards Track [Page 15] RFC 4898 TCP Extended Statistics MIB May 2007 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of connections allowed in the backlog at one time." ::= { tcpEStatsListenerEntry 13 } tcpEStatsListenerCurBacklog OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of connections that are in the backlog. This gauge includes connections in ESTABLISHED or SYN-RECEIVED states for which the Listener has not yet issued an accept. If this listener is using some technique to implicitly represent the SYN-RECEIVED states (e.g., by cryptographically encoding the state information in the initial sequence number, ISS), it MAY elect to exclude connections in the SYN-RECEIVED state from the backlog." ::= { tcpEStatsListenerEntry 14 } tcpEStatsListenerCurEstabBacklog OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of connections in the backlog that are in the ESTABLISHED state, but for which the Listener has not yet issued an accept." ::= { tcpEStatsListenerEntry 15 } -- ================================================================ -- -- TCP Connection ID Table -- tcpEStatsConnectIdTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpEStatsConnectIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table maps information that uniquely identifies each active TCP connection to the connection ID used by Mathis, et al. Standards Track [Page 16] RFC 4898 TCP Extended Statistics MIB May 2007 other tables in this MIB Module. It is an extension of tcpConnectionTable in RFC 4022. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state." ::= { tcpEStats 2 } tcpEStatsConnectIdEntry OBJECT-TYPE SYNTAX TcpEStatsConnectIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table maps a TCP connection 4-tuple to a connection index." AUGMENTS { tcpConnectionEntry } ::= { tcpEStatsConnectIdTable 1 } TcpEStatsConnectIdEntry ::= SEQUENCE { tcpEStatsConnectIndex Unsigned32 } tcpEStatsConnectIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique integer value assigned to each TCP Connection entry. The RECOMMENDED algorithm is to begin at 1 and increase to some implementation-specific maximum value and then start again at 1 skipping values already in use." ::= { tcpEStatsConnectIdEntry 1 } -- ================================================================ -- -- Basic TCP Performance Statistics -- tcpEStatsPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpEStatsPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects that are useful for Mathis, et al. Standards Track [Page 17] RFC 4898 TCP Extended Statistics MIB May 2007 measuring TCP performance and first line problem diagnosis. Most objects in this table directly expose some TCP state variable or are easily implemented as simple functions (e.g., the maximum value) of TCP state variables. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state." ::= { tcpEStats 3 } tcpEStatsPerfEntry OBJECT-TYPE SYNTAX TcpEStatsPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table has information about the characteristics of each active and recently closed TCP connection." INDEX { tcpEStatsConnectIndex } ::= { tcpEStatsPerfTable 1 } TcpEStatsPerfEntry ::= SEQUENCE { tcpEStatsPerfSegsOut ZeroBasedCounter32, tcpEStatsPerfDataSegsOut ZeroBasedCounter32, tcpEStatsPerfDataOctetsOut ZeroBasedCounter32, tcpEStatsPerfHCDataOctetsOut ZeroBasedCounter64, tcpEStatsPerfSegsRetrans ZeroBasedCounter32, tcpEStatsPerfOctetsRetrans ZeroBasedCounter32, tcpEStatsPerfSegsIn ZeroBasedCounter32, tcpEStatsPerfDataSegsIn ZeroBasedCounter32, tcpEStatsPerfDataOctetsIn ZeroBasedCounter32, tcpEStatsPerfHCDataOctetsIn ZeroBasedCounter64, tcpEStatsPerfElapsedSecs ZeroBasedCounter32, tcpEStatsPerfElapsedMicroSecs ZeroBasedCounter32, tcpEStatsPerfStartTimeStamp DateAndTime, tcpEStatsPerfCurMSS Gauge32, tcpEStatsPerfPipeSize Gauge32, tcpEStatsPerfMaxPipeSize Gauge32, tcpEStatsPerfSmoothedRTT Gauge32, tcpEStatsPerfCurRTO Gauge32, tcpEStatsPerfCongSignals ZeroBasedCounter32, tcpEStatsPerfCurCwnd Gauge32, tcpEStatsPerfCurSsthresh Gauge32, tcpEStatsPerfTimeouts ZeroBasedCounter32, tcpEStatsPerfCurRwinSent Gauge32, Mathis, et al. Standards Track [Page 18] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsPerfMaxRwinSent Gauge32, tcpEStatsPerfZeroRwinSent ZeroBasedCounter32, tcpEStatsPerfCurRwinRcvd Gauge32, tcpEStatsPerfMaxRwinRcvd Gauge32, tcpEStatsPerfZeroRwinRcvd ZeroBasedCounter32, tcpEStatsPerfSndLimTransRwin ZeroBasedCounter32, tcpEStatsPerfSndLimTransCwnd ZeroBasedCounter32, tcpEStatsPerfSndLimTransSnd ZeroBasedCounter32, tcpEStatsPerfSndLimTimeRwin ZeroBasedCounter32, tcpEStatsPerfSndLimTimeCwnd ZeroBasedCounter32, tcpEStatsPerfSndLimTimeSnd ZeroBasedCounter32 } -- -- The following objects provide statistics on aggregate -- segments and data sent on a connection. These provide a -- direct measure of the Internet capacity consumed by a -- connection. -- tcpEStatsPerfSegsOut OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments sent." ::= { tcpEStatsPerfEntry 1 } tcpEStatsPerfDataSegsOut OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of segments sent containing a positive length data segment." ::= { tcpEStatsPerfEntry 2 } tcpEStatsPerfDataOctetsOut OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of data contained in transmitted segments, including retransmitted data. Note that this does not include TCP headers." ::= { tcpEStatsPerfEntry 3 } Mathis, et al. Standards Track [Page 19] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsPerfHCDataOctetsOut OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of data contained in transmitted segments, including retransmitted data, on systems that can transmit more than 10 million bits per second. Note that this does not include TCP headers." ::= { tcpEStatsPerfEntry 4 } tcpEStatsPerfSegsRetrans OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of segments transmitted containing at least some retransmitted data." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 5 } tcpEStatsPerfOctetsRetrans OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets retransmitted." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 6 } tcpEStatsPerfSegsIn OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of segments received." ::= { tcpEStatsPerfEntry 7 } tcpEStatsPerfDataSegsIn OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of segments received containing a positive Mathis, et al. Standards Track [Page 20] RFC 4898 TCP Extended Statistics MIB May 2007 length data segment." ::= { tcpEStatsPerfEntry 8 } tcpEStatsPerfDataOctetsIn OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in received data segments, including retransmitted data. Note that this does not include TCP headers." ::= { tcpEStatsPerfEntry 9 } tcpEStatsPerfHCDataOctetsIn OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in received data segments, including retransmitted data, on systems that can receive more than 10 million bits per second. Note that this does not include TCP headers." ::= { tcpEStatsPerfEntry 10 } tcpEStatsPerfElapsedSecs OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The seconds part of the time elapsed between tcpEStatsPerfStartTimeStamp and the most recent protocol event (segment sent or received)." ::= { tcpEStatsPerfEntry 11 } tcpEStatsPerfElapsedMicroSecs OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The micro-second part of time elapsed between tcpEStatsPerfStartTimeStamp to the most recent protocol event (segment sent or received). This may be updated in whatever time granularity is the system supports." ::= { tcpEStatsPerfEntry 12 } Mathis, et al. Standards Track [Page 21] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsPerfStartTimeStamp OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Time at which this row was created and all ZeroBasedCounters in the row were initialized to zero." ::= { tcpEStatsPerfEntry 13 } -- -- The following objects can be used to fit minimal -- performance models to the TCP data rate. -- tcpEStatsPerfCurMSS OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The current maximum segment size (MSS), in octets." REFERENCE "RFC 1122, Requirements for Internet Hosts - Communication Layers" ::= { tcpEStatsPerfEntry 14 } tcpEStatsPerfPipeSize OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The TCP senders current estimate of the number of unacknowledged data octets in the network. While not in recovery (e.g., while the receiver is not reporting missing data to the sender), this is precisely the same as 'Flight size' as defined in RFC 2581, which can be computed as SND.NXT minus SND.UNA. [RFC793] During recovery, the TCP sender has incomplete information about the state of the network (e.g., which segments are lost vs reordered, especially if the return path is also dropping TCP acknowledgments). Current TCP standards do not mandate any specific algorithm for estimating the number of unacknowledged data octets in the network. RFC 3517 describes a conservative algorithm to use SACK Mathis, et al. Standards Track [Page 22] RFC 4898 TCP Extended Statistics MIB May 2007 information to estimate the number of unacknowledged data octets in the network. tcpEStatsPerfPipeSize object SHOULD be the same as 'pipe' as defined in RFC 3517 if it is implemented. (Note that while not in recovery the pipe algorithm yields the same values as flight size). If RFC 3517 is not implemented, the data octets in flight SHOULD be estimated as SND.NXT minus SND.UNA adjusted by some measure of the data that has left the network and retransmitted data. For example, with Reno or NewReno style TCP, the number of duplicate acknowledgment is used to count the number of segments that have left the network. That is, PipeSize=SND.NXT-SND.UNA+(retransmits-dupacks)*CurMSS" REFERENCE "RFC 793, RFC 2581, RFC 3517" ::= { tcpEStatsPerfEntry 15 } tcpEStatsPerfMaxPipeSize OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of tcpEStatsPerfPipeSize, for this connection." REFERENCE "RFC 793, RFC 2581, RFC 3517" ::= { tcpEStatsPerfEntry 16 } tcpEStatsPerfSmoothedRTT OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The smoothed round trip time used in calculation of the RTO. See SRTT in [RFC2988]." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPerfEntry 17 } tcpEStatsPerfCurRTO OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 23] RFC 4898 TCP Extended Statistics MIB May 2007 "The current value of the retransmit timer RTO." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPerfEntry 18 } tcpEStatsPerfCongSignals OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of multiplicative downward congestion window adjustments due to all forms of congestion signals, including Fast Retransmit, Explicit Congestion Notification (ECN), and timeouts. This object summarizes all events that invoke the MD portion of Additive Increase Multiplicative Decrease (AIMD) congestion control, and as such is the best indicator of how a cwnd is being affected by congestion. Note that retransmission timeouts multiplicatively reduce the window implicitly by setting ssthresh, and SHOULD be included in tcpEStatsPerfCongSignals. In order to minimize spurious congestion indications due to out-of-order segments, tcpEStatsPerfCongSignals SHOULD be incremented in association with the Fast Retransmit algorithm." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPerfEntry 19 } tcpEStatsPerfCurCwnd OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The current congestion window, in octets." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPerfEntry 20 } tcpEStatsPerfCurSsthresh OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The current slow start threshold in octets." REFERENCE "RFC 2581, TCP Congestion Control" Mathis, et al. Standards Track [Page 24] RFC 4898 TCP Extended Statistics MIB May 2007 ::= { tcpEStatsPerfEntry 21 } tcpEStatsPerfTimeouts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the retransmit timeout has expired when the RTO backoff multiplier is equal to one." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPerfEntry 22 } -- -- The following objects instrument receiver window updates -- sent by the local receiver to the remote sender. These can -- be used to determine if the local receiver is exerting flow -- control back pressure on the remote sender. -- tcpEStatsPerfCurRwinSent OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent window advertisement sent, in octets." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 23 } tcpEStatsPerfMaxRwinSent OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum window advertisement sent, in octets." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 24 } tcpEStatsPerfZeroRwinSent OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of acknowledgments sent announcing a zero Mathis, et al. Standards Track [Page 25] RFC 4898 TCP Extended Statistics MIB May 2007 receive window, when the previously announced window was not zero." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 25 } -- -- The following objects instrument receiver window updates -- from the far end-system to determine if the remote receiver -- has sufficient buffer space or is exerting flow-control -- back pressure on the local sender. -- tcpEStatsPerfCurRwinRcvd OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent window advertisement received, in octets." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 26 } tcpEStatsPerfMaxRwinRcvd OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum window advertisement received, in octets." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 27 } tcpEStatsPerfZeroRwinRcvd OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of acknowledgments received announcing a zero receive window, when the previously announced window was not zero." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 28 } -- Mathis, et al. Standards Track [Page 26] RFC 4898 TCP Extended Statistics MIB May 2007 -- The following optional objects can be used to quickly -- identify which subsystems are limiting TCP performance. -- There are three parallel pairs of instruments that measure -- the extent to which TCP performance is limited by the -- announced receiver window (indicating a receiver -- bottleneck), the current congestion window or -- retransmission timeout (indicating a path bottleneck) and -- all others events (indicating a sender bottleneck). -- -- These instruments SHOULD be updated every time the TCP -- output routine stops sending data. The elapsed time since -- the previous stop is accumulated into the appropriate -- object as determined by the previous stop reason (e.g., -- stop state). The current stop reason determines which timer -- will be updated the next time TCP output stops. -- -- Since there is no explicit stop at the beginning of a -- timeout, it is necessary to retroactively reclassify the -- previous stop as 'Congestion Limited'. -- tcpEStatsPerfSndLimTransRwin OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transitions into the 'Receiver Limited' state from either the 'Congestion Limited' or 'Sender Limited' states. This state is entered whenever TCP transmission stops because the sender has filled the announced receiver window, i.e., when SND.NXT has advanced to SND.UNA + SND.WND - 1 as described in RFC 793." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsPerfEntry 31 } tcpEStatsPerfSndLimTransCwnd OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transitions into the 'Congestion Limited' state from either the 'Receiver Limited' or 'Sender Limited' states. This state is entered whenever TCP transmission stops because the sender has reached some limit defined by congestion control (e.g., cwnd) or other algorithms (retransmission timeouts) designed to control network traffic. See the definition of 'CONGESTION WINDOW' Mathis, et al. Standards Track [Page 27] RFC 4898 TCP Extended Statistics MIB May 2007 in RFC 2581." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPerfEntry 32 } tcpEStatsPerfSndLimTransSnd OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transitions into the 'Sender Limited' state from either the 'Receiver Limited' or 'Congestion Limited' states. This state is entered whenever TCP transmission stops due to some sender limit such as running out of application data or other resources and the Karn algorithm. When TCP stops sending data for any reason, which cannot be classified as Receiver Limited or Congestion Limited, it MUST be treated as Sender Limited." ::= { tcpEStatsPerfEntry 33 } tcpEStatsPerfSndLimTimeRwin OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The cumulative time spent in the 'Receiver Limited' state. See tcpEStatsPerfSndLimTransRwin." ::= { tcpEStatsPerfEntry 34 } tcpEStatsPerfSndLimTimeCwnd OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The cumulative time spent in the 'Congestion Limited' state. See tcpEStatsPerfSndLimTransCwnd. When there is a retransmission timeout, it SHOULD be counted in tcpEStatsPerfSndLimTimeCwnd (and not the cumulative time for some other state.)" ::= { tcpEStatsPerfEntry 35 } tcpEStatsPerfSndLimTimeSnd OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current Mathis, et al. Standards Track [Page 28] RFC 4898 TCP Extended Statistics MIB May 2007 DESCRIPTION "The cumulative time spent in the 'Sender Limited' state. See tcpEStatsPerfSndLimTransSnd." ::= { tcpEStatsPerfEntry 36 } -- ================================================================ -- -- Statistics for diagnosing path problems -- tcpEStatsPathTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpEStatsPathEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects that can be used to infer detailed behavior of the Internet path, such as the extent that there is reordering, ECN bits, and if RTT fluctuations are correlated to losses. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state." ::= { tcpEStats 4 } tcpEStatsPathEntry OBJECT-TYPE SYNTAX TcpEStatsPathEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table has information about the characteristics of each active and recently closed TCP connection." INDEX { tcpEStatsConnectIndex } ::= { tcpEStatsPathTable 1 } TcpEStatsPathEntry ::= SEQUENCE { tcpEStatsPathRetranThresh Gauge32, tcpEStatsPathNonRecovDAEpisodes ZeroBasedCounter32, tcpEStatsPathSumOctetsReordered ZeroBasedCounter32, tcpEStatsPathNonRecovDA ZeroBasedCounter32, tcpEStatsPathSampleRTT Gauge32, tcpEStatsPathRTTVar Gauge32, tcpEStatsPathMaxRTT Gauge32, tcpEStatsPathMinRTT Gauge32, tcpEStatsPathSumRTT ZeroBasedCounter32, Mathis, et al. Standards Track [Page 29] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsPathHCSumRTT ZeroBasedCounter64, tcpEStatsPathCountRTT ZeroBasedCounter32, tcpEStatsPathMaxRTO Gauge32, tcpEStatsPathMinRTO Gauge32, tcpEStatsPathIpTtl Unsigned32, tcpEStatsPathIpTosIn OCTET STRING, tcpEStatsPathIpTosOut OCTET STRING, tcpEStatsPathPreCongSumCwnd ZeroBasedCounter32, tcpEStatsPathPreCongSumRTT ZeroBasedCounter32, tcpEStatsPathPostCongSumRTT ZeroBasedCounter32, tcpEStatsPathPostCongCountRTT ZeroBasedCounter32, tcpEStatsPathECNsignals ZeroBasedCounter32, tcpEStatsPathDupAckEpisodes ZeroBasedCounter32, tcpEStatsPathRcvRTT Gauge32, tcpEStatsPathDupAcksOut ZeroBasedCounter32, tcpEStatsPathCERcvd ZeroBasedCounter32, tcpEStatsPathECESent ZeroBasedCounter32 } -- -- The following optional objects can be used to infer segment -- reordering on the path from the local sender to the remote -- receiver. -- tcpEStatsPathRetranThresh OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate acknowledgments required to trigger Fast Retransmit. Note that although this is constant in traditional Reno TCP implementations, it is adaptive in many newer TCPs." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPathEntry 1 } tcpEStatsPathNonRecovDAEpisodes OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate acknowledgment episodes that did not trigger a Fast Retransmit because ACK advanced prior to the number of duplicate acknowledgments reaching RetranThresh. Mathis, et al. Standards Track [Page 30] RFC 4898 TCP Extended Statistics MIB May 2007 In many implementations this is the number of times the 'dupacks' counter is set to zero when it is non-zero but less than RetranThresh. Note that the change in tcpEStatsPathNonRecovDAEpisodes divided by the change in tcpEStatsPerfDataSegsOut is an estimate of the frequency of data reordering on the forward path over some interval." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPathEntry 2 } tcpEStatsPathSumOctetsReordered OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of the amounts SND.UNA advances on the acknowledgment which ends a dup-ack episode without a retransmission. Note the change in tcpEStatsPathSumOctetsReordered divided by the change in tcpEStatsPathNonRecovDAEpisodes is an estimates of the average reordering distance, over some interval." ::= { tcpEStatsPathEntry 3 } tcpEStatsPathNonRecovDA OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Duplicate acks (or SACKS) that did not trigger a Fast Retransmit because ACK advanced prior to the number of duplicate acknowledgments reaching RetranThresh. In many implementations, this is the sum of the 'dupacks' counter, just before it is set to zero because ACK advanced without a Fast Retransmit. Note that the change in tcpEStatsPathNonRecovDA divided by the change in tcpEStatsPathNonRecovDAEpisodes is an estimate of the average reordering distance in segments over some interval." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPathEntry 4 } Mathis, et al. Standards Track [Page 31] RFC 4898 TCP Extended Statistics MIB May 2007 -- -- The following optional objects instrument the round trip -- time estimator and the retransmission timeout timer. -- tcpEStatsPathSampleRTT OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent raw round trip time measurement used in calculation of the RTO." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 11 } tcpEStatsPathRTTVar OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The round trip time variation used in calculation of the RTO. See RTTVAR in [RFC2988]." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 12 } tcpEStatsPathMaxRTT OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum sampled round trip time." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 13 } tcpEStatsPathMinRTT OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum sampled round trip time." REFERENCE Mathis, et al. Standards Track [Page 32] RFC 4898 TCP Extended Statistics MIB May 2007 "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 14 } tcpEStatsPathSumRTT OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of all sampled round trip times. Note that the change in tcpEStatsPathSumRTT divided by the change in tcpEStatsPathCountRTT is the mean RTT, uniformly averaged over an enter interval." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 15 } tcpEStatsPathHCSumRTT OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of all sampled round trip times, on all systems that implement multiple concurrent RTT measurements. Note that the change in tcpEStatsPathHCSumRTT divided by the change in tcpEStatsPathCountRTT is the mean RTT, uniformly averaged over an enter interval." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 16 } tcpEStatsPathCountRTT OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of round trip time samples included in tcpEStatsPathSumRTT and tcpEStatsPathHCSumRTT." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 17 } tcpEStatsPathMaxRTO OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" Mathis, et al. Standards Track [Page 33] RFC 4898 TCP Extended Statistics MIB May 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of the retransmit timer RTO." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 18 } tcpEStatsPathMinRTO OBJECT-TYPE SYNTAX Gauge32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum value of the retransmit timer RTO." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsPathEntry 19 } -- -- The following optional objects provide information about -- how TCP is using the IP layer. -- tcpEStatsPathIpTtl OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the TTL field carried in the most recently received IP header. This is sometimes useful to detect changing or unstable routes." REFERENCE "RFC 791, Internet Protocol" ::= { tcpEStatsPathEntry 20 } tcpEStatsPathIpTosIn OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the IPv4 Type of Service octet, or the IPv6 traffic class octet, carried in the most recently received IP header. This is useful to diagnose interactions between TCP and any IP layer packet scheduling and delivery policy, which might be in effect to implement Diffserv." Mathis, et al. Standards Track [Page 34] RFC 4898 TCP Extended Statistics MIB May 2007 REFERENCE "RFC 3260, New Terminology and Clarifications for Diffserv" ::= { tcpEStatsPathEntry 21 } tcpEStatsPathIpTosOut OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the IPv4 Type Of Service octet, or the IPv6 traffic class octet, carried in the most recently transmitted IP header. This is useful to diagnose interactions between TCP and any IP layer packet scheduling and delivery policy, which might be in effect to implement Diffserv." REFERENCE "RFC 3260, New Terminology and Clarifications for Diffserv" ::= { tcpEStatsPathEntry 22 } -- -- The following optional objects characterize the congestion -- feedback signals by collecting statistics on how the -- congestion events are correlated to losses, changes in RTT -- and other protocol events. -- tcpEStatsPathPreCongSumCwnd OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The sum of the values of the congestion window, in octets, captured each time a congestion signal is received. This MUST be updated each time tcpEStatsPerfCongSignals is incremented, such that the change in tcpEStatsPathPreCongSumCwnd divided by the change in tcpEStatsPerfCongSignals is the average window (over some interval) just prior to a congestion signal." ::= { tcpEStatsPathEntry 23 } tcpEStatsPathPreCongSumRTT OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 35] RFC 4898 TCP Extended Statistics MIB May 2007 "Sum of the last sample of the RTT (tcpEStatsPathSampleRTT) prior to the received congestion signals. This MUST be updated each time tcpEStatsPerfCongSignals is incremented, such that the change in tcpEStatsPathPreCongSumRTT divided by the change in tcpEStatsPerfCongSignals is the average RTT (over some interval) just prior to a congestion signal." ::= { tcpEStatsPathEntry 24 } tcpEStatsPathPostCongSumRTT OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "Sum of the first sample of the RTT (tcpEStatsPathSampleRTT) following each congestion signal. Such that the change in tcpEStatsPathPostCongSumRTT divided by the change in tcpEStatsPathPostCongCountRTT is the average RTT (over some interval) just after a congestion signal." ::= { tcpEStatsPathEntry 25 } tcpEStatsPathPostCongCountRTT OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RTT samples included in tcpEStatsPathPostCongSumRTT such that the change in tcpEStatsPathPostCongSumRTT divided by the change in tcpEStatsPathPostCongCountRTT is the average RTT (over some interval) just after a congestion signal." ::= { tcpEStatsPathEntry 26 } -- -- The following optional objects can be used to detect other -- types of non-loss congestion signals such as source quench -- or ECN. -- tcpEStatsPathECNsignals OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of congestion signals delivered to the TCP sender via explicit congestion notification (ECN). This is typically the number of segments bearing Echo Congestion Mathis, et al. Standards Track [Page 36] RFC 4898 TCP Extended Statistics MIB May 2007 Experienced (ECE) bits, but should also include segments failing the ECN nonce check or other explicit congestion signals." REFERENCE "RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP" ::= { tcpEStatsPathEntry 27 } -- -- The following optional objects are receiver side -- instruments of the path from the sender to the receiver. In -- general, the receiver has less information about the state -- of the path because the receiver does not have a robust -- mechanism to infer the sender's actions. -- tcpEStatsPathDupAckEpisodes OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Duplicate Acks Sent when prior Ack was not duplicate. This is the number of times that a contiguous series of duplicate acknowledgments have been sent. This is an indication of the number of data segments lost or reordered on the path from the remote TCP endpoint to the near TCP endpoint." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPathEntry 28 } tcpEStatsPathRcvRTT OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The receiver's estimate of the Path RTT. Adaptive receiver window algorithms depend on the receiver to having a good estimate of the path RTT." ::= { tcpEStatsPathEntry 29 } tcpEStatsPathDupAcksOut OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 37] RFC 4898 TCP Extended Statistics MIB May 2007 "The number of duplicate ACKs sent. The ratio of the change in tcpEStatsPathDupAcksOut to the change in tcpEStatsPathDupAckEpisodes is an indication of reorder or recovery distance over some interval." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsPathEntry 30 } tcpEStatsPathCERcvd OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of segments received with IP headers bearing Congestion Experienced (CE) markings." REFERENCE "RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP" ::= { tcpEStatsPathEntry 31 } tcpEStatsPathECESent OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the Echo Congestion Experienced (ECE) bit in the TCP header has been set (transitioned from 0 to 1), due to a Congestion Experienced (CE) marking on an IP header. Note that ECE can be set and reset only once per RTT, while CE can be set on many segments per RTT." REFERENCE "RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP" ::= { tcpEStatsPathEntry 32 } -- ================================================================ -- -- Statistics for diagnosing stack algorithms -- tcpEStatsStackTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpEStatsStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects that are most useful for determining how well some of the TCP control algorithms are coping with this particular Mathis, et al. Standards Track [Page 38] RFC 4898 TCP Extended Statistics MIB May 2007 path. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state." ::= { tcpEStats 5 } tcpEStatsStackEntry OBJECT-TYPE SYNTAX TcpEStatsStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table has information about the characteristics of each active and recently closed TCP connection." INDEX { tcpEStatsConnectIndex } ::= { tcpEStatsStackTable 1 } TcpEStatsStackEntry ::= SEQUENCE { tcpEStatsStackActiveOpen TruthValue, tcpEStatsStackMSSSent Unsigned32, tcpEStatsStackMSSRcvd Unsigned32, tcpEStatsStackWinScaleSent Integer32, tcpEStatsStackWinScaleRcvd Integer32, tcpEStatsStackTimeStamps TcpEStatsNegotiated, tcpEStatsStackECN TcpEStatsNegotiated, tcpEStatsStackWillSendSACK TcpEStatsNegotiated, tcpEStatsStackWillUseSACK TcpEStatsNegotiated, tcpEStatsStackState INTEGER, tcpEStatsStackNagle TruthValue, tcpEStatsStackMaxSsCwnd Gauge32, tcpEStatsStackMaxCaCwnd Gauge32, tcpEStatsStackMaxSsthresh Gauge32, tcpEStatsStackMinSsthresh Gauge32, tcpEStatsStackInRecovery INTEGER, tcpEStatsStackDupAcksIn ZeroBasedCounter32, tcpEStatsStackSpuriousFrDetected ZeroBasedCounter32, tcpEStatsStackSpuriousRtoDetected ZeroBasedCounter32, tcpEStatsStackSoftErrors ZeroBasedCounter32, tcpEStatsStackSoftErrorReason INTEGER, tcpEStatsStackSlowStart ZeroBasedCounter32, tcpEStatsStackCongAvoid ZeroBasedCounter32, tcpEStatsStackOtherReductions ZeroBasedCounter32, tcpEStatsStackCongOverCount ZeroBasedCounter32, tcpEStatsStackFastRetran ZeroBasedCounter32, tcpEStatsStackSubsequentTimeouts ZeroBasedCounter32, Mathis, et al. Standards Track [Page 39] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsStackCurTimeoutCount Gauge32, tcpEStatsStackAbruptTimeouts ZeroBasedCounter32, tcpEStatsStackSACKsRcvd ZeroBasedCounter32, tcpEStatsStackSACKBlocksRcvd ZeroBasedCounter32, tcpEStatsStackSendStall ZeroBasedCounter32, tcpEStatsStackDSACKDups ZeroBasedCounter32, tcpEStatsStackMaxMSS Gauge32, tcpEStatsStackMinMSS Gauge32, tcpEStatsStackSndInitial Unsigned32, tcpEStatsStackRecInitial Unsigned32, tcpEStatsStackCurRetxQueue Gauge32, tcpEStatsStackMaxRetxQueue Gauge32, tcpEStatsStackCurReasmQueue Gauge32, tcpEStatsStackMaxReasmQueue Gauge32 } -- -- The following objects reflect TCP options carried on the -- SYN or SYN-ACK. These options are used to provide -- additional protocol parameters or to enable various -- optional TCP features or algorithms. -- -- Except as noted, the TCP protocol does not permit these -- options to change after the SYN exchange. -- tcpEStatsStackActiveOpen OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "True(1) if the local connection traversed the SYN-SENT state, else false(2)." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsStackEntry 1 } tcpEStatsStackMSSSent OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value sent in an MSS option, or zero if none." REFERENCE "RFC 1122, Requirements for Internet Hosts - Communication Layers" ::= { tcpEStatsStackEntry 2 } Mathis, et al. Standards Track [Page 40] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsStackMSSRcvd OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value received in an MSS option, or zero if none." REFERENCE "RFC 1122, Requirements for Internet Hosts - Communication Layers" ::= { tcpEStatsStackEntry 3 } tcpEStatsStackWinScaleSent OBJECT-TYPE SYNTAX Integer32 (-1..14) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the transmitted window scale option if one was sent; otherwise, a value of -1. Note that if both tcpEStatsStackWinScaleSent and tcpEStatsStackWinScaleRcvd are not -1, then Rcv.Wind.Scale will be the same as this value and used to scale receiver window announcements from the local host to the remote host." REFERENCE "RFC 1323, TCP Extensions for High Performance" ::= { tcpEStatsStackEntry 4 } tcpEStatsStackWinScaleRcvd OBJECT-TYPE SYNTAX Integer32 (-1..14) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the received window scale option if one was received; otherwise, a value of -1. Note that if both tcpEStatsStackWinScaleSent and tcpEStatsStackWinScaleRcvd are not -1, then Snd.Wind.Scale will be the same as this value and used to scale receiver window announcements from the remote host to the local host." REFERENCE "RFC 1323, TCP Extensions for High Performance" ::= { tcpEStatsStackEntry 5 } tcpEStatsStackTimeStamps OBJECT-TYPE SYNTAX TcpEStatsNegotiated MAX-ACCESS read-only Mathis, et al. Standards Track [Page 41] RFC 4898 TCP Extended Statistics MIB May 2007 STATUS current DESCRIPTION "Enabled(1) if TCP timestamps have been negotiated on, selfDisabled(2) if they are disabled or not implemented on the local host, or peerDisabled(3) if not negotiated by the remote hosts." REFERENCE "RFC 1323, TCP Extensions for High Performance" ::= { tcpEStatsStackEntry 6 } tcpEStatsStackECN OBJECT-TYPE SYNTAX TcpEStatsNegotiated MAX-ACCESS read-only STATUS current DESCRIPTION "Enabled(1) if Explicit Congestion Notification (ECN) has been negotiated on, selfDisabled(2) if it is disabled or not implemented on the local host, or peerDisabled(3) if not negotiated by the remote hosts." REFERENCE "RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP" ::= { tcpEStatsStackEntry 7 } tcpEStatsStackWillSendSACK OBJECT-TYPE SYNTAX TcpEStatsNegotiated MAX-ACCESS read-only STATUS current DESCRIPTION "Enabled(1) if the local host will send SACK options, selfDisabled(2) if SACK is disabled or not implemented on the local host, or peerDisabled(3) if the remote host did not send the SACK-permitted option. Note that SACK negotiation is not symmetrical. SACK can enabled on one side of the connection and not the other." REFERENCE "RFC 2018, TCP Selective Acknowledgement Options" ::= { tcpEStatsStackEntry 8 } tcpEStatsStackWillUseSACK OBJECT-TYPE SYNTAX TcpEStatsNegotiated MAX-ACCESS read-only STATUS current DESCRIPTION "Enabled(1) if the local host will process SACK options, selfDisabled(2) if SACK is disabled or not implemented on the local host, or peerDisabled(3) if the remote host sends Mathis, et al. Standards Track [Page 42] RFC 4898 TCP Extended Statistics MIB May 2007 duplicate ACKs without SACK options, or the local host otherwise decides not to process received SACK options. Unlike other TCP options, the remote data receiver cannot explicitly indicate if it is able to generate SACK options. When sending data, the local host has to deduce if the remote receiver is sending SACK options. This object can transition from Enabled(1) to peerDisabled(3) after the SYN exchange. Note that SACK negotiation is not symmetrical. SACK can enabled on one side of the connection and not the other." REFERENCE "RFC 2018, TCP Selective Acknowledgement Options" ::= { tcpEStatsStackEntry 9 } -- -- The following two objects reflect the current state of the -- connection. -- tcpEStatsStackState OBJECT-TYPE SYNTAX INTEGER { tcpESStateClosed(1), tcpESStateListen(2), tcpESStateSynSent(3), tcpESStateSynReceived(4), tcpESStateEstablished(5), tcpESStateFinWait1(6), tcpESStateFinWait2(7), tcpESStateCloseWait(8), tcpESStateLastAck(9), tcpESStateClosing(10), tcpESStateTimeWait(11), tcpESStateDeleteTcb(12) } MAX-ACCESS read-only STATUS current DESCRIPTION "An integer value representing the connection state from the TCP State Transition Diagram. The value listen(2) is included only for parallelism to the old tcpConnTable, and SHOULD NOT be used because the listen state in managed by the tcpListenerTable. The value DeleteTcb(12) is included only for parallelism to the tcpConnTable mechanism for terminating connections, Mathis, et al. Standards Track [Page 43] RFC 4898 TCP Extended Statistics MIB May 2007 although this table does not permit writing." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsStackEntry 10 } tcpEStatsStackNagle OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "True(1) if the Nagle algorithm is being used, else false(2)." REFERENCE "RFC 1122, Requirements for Internet Hosts - Communication Layers" ::= { tcpEStatsStackEntry 11 } -- -- The following objects instrument the overall operation of -- TCP congestion control and data retransmissions. These -- instruments are sufficient to fit the actual performance to -- an updated macroscopic performance model [RFC2581] [Mat97] -- [Pad98]. -- tcpEStatsStackMaxSsCwnd OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum congestion window used during Slow Start, in octets." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 12 } tcpEStatsStackMaxCaCwnd OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum congestion window used during Congestion Avoidance, in octets." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 13 } Mathis, et al. Standards Track [Page 44] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsStackMaxSsthresh OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum slow start threshold, excluding the initial value." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 14 } tcpEStatsStackMinSsthresh OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum slow start threshold." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 15 } tcpEStatsStackInRecovery OBJECT-TYPE SYNTAX INTEGER { tcpESDataContiguous(1), tcpESDataUnordered(2), tcpESDataRecovery(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An integer value representing the state of the loss recovery for this connection. tcpESDataContiguous(1) indicates that the remote receiver is reporting contiguous data (no duplicate acknowledgments or SACK options) and that there are no unacknowledged retransmissions. tcpESDataUnordered(2) indicates that the remote receiver is reporting missing or out-of-order data (e.g., sending duplicate acknowledgments or SACK options) and that there are no unacknowledged retransmissions (because the missing data has not yet been retransmitted). tcpESDataRecovery(3) indicates that the sender has outstanding retransmitted data that is still Mathis, et al. Standards Track [Page 45] RFC 4898 TCP Extended Statistics MIB May 2007 unacknowledged." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 16 } tcpEStatsStackDupAcksIn OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate ACKs received." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 17 } tcpEStatsStackSpuriousFrDetected OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of acknowledgments reporting out-of-order segments after the Fast Retransmit algorithm has already retransmitted the segments. (For example as detected by the Eifel algorithm).'" REFERENCE "RFC 3522, The Eifel Detection Algorithm for TCP" ::= { tcpEStatsStackEntry 18 } tcpEStatsStackSpuriousRtoDetected OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of acknowledgments reporting segments that have already been retransmitted due to a Retransmission Timeout." ::= { tcpEStatsStackEntry 19 } -- -- The following optional objects instrument unusual protocol -- events that probably indicate implementation problems in -- the protocol or path. -- tcpEStatsStackSoftErrors OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 46] RFC 4898 TCP Extended Statistics MIB May 2007 "The number of segments that fail various consistency tests during TCP input processing. Soft errors might cause the segment to be discarded but some do not. Some of these soft errors cause the generation of a TCP acknowledgment, while others are silently discarded." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsStackEntry 21 } tcpEStatsStackSoftErrorReason OBJECT-TYPE SYNTAX INTEGER { belowDataWindow(1), aboveDataWindow(2), belowAckWindow(3), aboveAckWindow(4), belowTSWindow(5), aboveTSWindow(6), dataCheckSum(7), otherSoftError(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies which consistency test most recently failed during TCP input processing. This object SHOULD be set every time tcpEStatsStackSoftErrors is incremented. The codes are as follows: belowDataWindow(1) - All data in the segment is below SND.UNA. (Normal for keep-alives and zero window probes). aboveDataWindow(2) - Some data in the segment is above SND.WND. (Indicates an implementation bug or possible attack). belowAckWindow(3) - ACK below SND.UNA. (Indicates that the return path is reordering ACKs) aboveAckWindow(4) - An ACK for data that we have not sent. (Indicates an implementation bug or possible attack). belowTSWindow(5) - TSecr on the segment is older than the current TS.Recent (Normal for the rare case where PAWS detects data reordered by the network). aboveTSWindow(6) - TSecr on the segment is newer than the current TS.Recent. (Indicates an implementation bug or possible attack). Mathis, et al. Standards Track [Page 47] RFC 4898 TCP Extended Statistics MIB May 2007 dataCheckSum(7) - Incorrect checksum. Note that this value is intrinsically fragile, because the header fields used to identify the connection may have been corrupted. otherSoftError(8) - All other soft errors not listed above." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsStackEntry 22 } -- -- The following optional objects expose the detailed -- operation of the congestion control algorithms. -- tcpEStatsStackSlowStart OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the congestion window has been increased by the Slow Start algorithm." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 23 } tcpEStatsStackCongAvoid OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the congestion window has been increased by the Congestion Avoidance algorithm." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 24 } tcpEStatsStackOtherReductions OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of congestion window reductions made as a result of anything other than AIMD congestion control algorithms. Examples of non-multiplicative window reductions include Congestion Window Validation [RFC2861] and experimental algorithms such as Vegas [Bra94]. Mathis, et al. Standards Track [Page 48] RFC 4898 TCP Extended Statistics MIB May 2007 All window reductions MUST be counted as either tcpEStatsPerfCongSignals or tcpEStatsStackOtherReductions." REFERENCE "RFC 2861, TCP Congestion Window Validation" ::= { tcpEStatsStackEntry 25 } tcpEStatsStackCongOverCount OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of congestion events that were 'backed out' of the congestion control state machine such that the congestion window was restored to a prior value. This can happen due to the Eifel algorithm [RFC3522] or other algorithms that can be used to detect and cancel spurious invocations of the Fast Retransmit Algorithm. Although it may be feasible to undo the effects of spurious invocation of the Fast Retransmit congestion events cannot easily be backed out of tcpEStatsPerfCongSignals and tcpEStatsPathPreCongSumCwnd, etc." REFERENCE "RFC 3522, The Eifel Detection Algorithm for TCP" ::= { tcpEStatsStackEntry 26 } tcpEStatsStackFastRetran OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invocations of the Fast Retransmit algorithm." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 27 } tcpEStatsStackSubsequentTimeouts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the retransmit timeout has expired after the RTO has been doubled. See Section 5.5 of RFC 2988." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsStackEntry 28 } Mathis, et al. Standards Track [Page 49] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsStackCurTimeoutCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of times the retransmit timeout has expired without receiving an acknowledgment for new data. tcpEStatsStackCurTimeoutCount is reset to zero when new data is acknowledged and incremented for each invocation of Section 5.5 of RFC 2988." REFERENCE "RFC 2988, Computing TCP's Retransmission Timer" ::= { tcpEStatsStackEntry 29 } tcpEStatsStackAbruptTimeouts OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of timeouts that occurred without any immediately preceding duplicate acknowledgments or other indications of congestion. Abrupt Timeouts indicate that the path lost an entire window of data or acknowledgments. Timeouts that are preceded by duplicate acknowledgments or other congestion signals (e.g., ECN) are not counted as abrupt, and might have been avoided by a more sophisticated Fast Retransmit algorithm." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsStackEntry 30 } tcpEStatsStackSACKsRcvd OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SACK options received." REFERENCE "RFC 2018, TCP Selective Acknowledgement Options" ::= { tcpEStatsStackEntry 31 } tcpEStatsStackSACKBlocksRcvd OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SACK blocks received (within SACK options)." Mathis, et al. Standards Track [Page 50] RFC 4898 TCP Extended Statistics MIB May 2007 REFERENCE "RFC 2018, TCP Selective Acknowledgement Options" ::= { tcpEStatsStackEntry 32 } tcpEStatsStackSendStall OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of interface stalls or other sender local resource limitations that are treated as congestion signals." ::= { tcpEStatsStackEntry 33 } tcpEStatsStackDSACKDups OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate segments reported to the local host by D-SACK blocks." REFERENCE "RFC 2883, An Extension to the Selective Acknowledgement (SACK) Option for TCP" ::= { tcpEStatsStackEntry 34 } -- -- The following optional objects instrument path MTU -- discovery. -- tcpEStatsStackMaxMSS OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum MSS, in octets." REFERENCE "RFC 1191, Path MTU discovery" ::= { tcpEStatsStackEntry 35 } tcpEStatsStackMinMSS OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 51] RFC 4898 TCP Extended Statistics MIB May 2007 "The minimum MSS, in octets." REFERENCE "RFC 1191, Path MTU discovery" ::= { tcpEStatsStackEntry 36 } -- -- The following optional initial value objects are useful for -- conformance testing instruments on application progress and -- consumed network resources. -- tcpEStatsStackSndInitial OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Initial send sequence number. Note that by definition tcpEStatsStackSndInitial never changes for a given connection." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsStackEntry 37 } tcpEStatsStackRecInitial OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Initial receive sequence number. Note that by definition tcpEStatsStackRecInitial never changes for a given connection." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsStackEntry 38 } -- -- The following optional objects instrument the senders -- buffer usage, including any buffering in the application -- interface to TCP and the retransmit queue. All 'buffer -- memory' instruments are assumed to include OS data -- structure overhead. -- tcpEStatsStackCurRetxQueue OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current Mathis, et al. Standards Track [Page 52] RFC 4898 TCP Extended Statistics MIB May 2007 DESCRIPTION "The current number of octets of data occupying the retransmit queue." ::= { tcpEStatsStackEntry 39 } tcpEStatsStackMaxRetxQueue OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of octets of data occupying the retransmit queue." ::= { tcpEStatsStackEntry 40 } tcpEStatsStackCurReasmQueue OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of octets of sequence space spanned by the reassembly queue. This is generally the difference between rcv.nxt and the sequence number of the right most edge of the reassembly queue." ::= { tcpEStatsStackEntry 41 } tcpEStatsStackMaxReasmQueue OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum value of tcpEStatsStackCurReasmQueue" ::= { tcpEStatsStackEntry 42 } -- ================================================================ -- -- Statistics for diagnosing interactions between -- applications and TCP. -- tcpEStatsAppTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpEStatsAppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects that are useful for determining if the application using TCP is Mathis, et al. Standards Track [Page 53] RFC 4898 TCP Extended Statistics MIB May 2007 limiting TCP performance. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state." ::= { tcpEStats 6 } tcpEStatsAppEntry OBJECT-TYPE SYNTAX TcpEStatsAppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table has information about the characteristics of each active and recently closed TCP connection." INDEX { tcpEStatsConnectIndex } ::= { tcpEStatsAppTable 1 } TcpEStatsAppEntry ::= SEQUENCE { tcpEStatsAppSndUna Counter32, tcpEStatsAppSndNxt Unsigned32, tcpEStatsAppSndMax Counter32, tcpEStatsAppThruOctetsAcked ZeroBasedCounter32, tcpEStatsAppHCThruOctetsAcked ZeroBasedCounter64, tcpEStatsAppRcvNxt Counter32, tcpEStatsAppThruOctetsReceived ZeroBasedCounter32, tcpEStatsAppHCThruOctetsReceived ZeroBasedCounter64, tcpEStatsAppCurAppWQueue Gauge32, tcpEStatsAppMaxAppWQueue Gauge32, tcpEStatsAppCurAppRQueue Gauge32, tcpEStatsAppMaxAppRQueue Gauge32 } -- -- The following objects provide throughput statistics for the -- connection including sequence numbers and elapsed -- application data. These permit direct observation of the -- applications progress, in terms of elapsed data delivery -- and elapsed time. -- tcpEStatsAppSndUna OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 54] RFC 4898 TCP Extended Statistics MIB May 2007 "The value of SND.UNA, the oldest unacknowledged sequence number. Note that SND.UNA is a TCP state variable that is congruent to Counter32 semantics." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsAppEntry 1 } tcpEStatsAppSndNxt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SND.NXT, the next sequence number to be sent. Note that tcpEStatsAppSndNxt is not monotonic (and thus not a counter) because TCP sometimes retransmits lost data by pulling tcpEStatsAppSndNxt back to the missing data." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsAppEntry 2 } tcpEStatsAppSndMax OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The farthest forward (right most or largest) SND.NXT value. Note that this will be equal to tcpEStatsAppSndNxt except when tcpEStatsAppSndNxt is pulled back during recovery." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsAppEntry 3 } tcpEStatsAppThruOctetsAcked OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets for which cumulative acknowledgments have been received. Note that this will be the sum of changes to tcpEStatsAppSndUna." ::= { tcpEStatsAppEntry 4 } tcpEStatsAppHCThruOctetsAcked OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" Mathis, et al. Standards Track [Page 55] RFC 4898 TCP Extended Statistics MIB May 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets for which cumulative acknowledgments have been received, on systems that can receive more than 10 million bits per second. Note that this will be the sum of changes in tcpEStatsAppSndUna." ::= { tcpEStatsAppEntry 5 } tcpEStatsAppRcvNxt OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of RCV.NXT. The next sequence number expected on an incoming segment, and the left or lower edge of the receive window. Note that RCV.NXT is a TCP state variable that is congruent to Counter32 semantics." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsAppEntry 6 } tcpEStatsAppThruOctetsReceived OBJECT-TYPE SYNTAX ZeroBasedCounter32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets for which cumulative acknowledgments have been sent. Note that this will be the sum of changes to tcpEStatsAppRcvNxt." ::= { tcpEStatsAppEntry 7 } tcpEStatsAppHCThruOctetsReceived OBJECT-TYPE SYNTAX ZeroBasedCounter64 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets for which cumulative acknowledgments have been sent, on systems that can transmit more than 10 million bits per second. Note that this will be the sum of changes in tcpEStatsAppRcvNxt." ::= { tcpEStatsAppEntry 8 } tcpEStatsAppCurAppWQueue OBJECT-TYPE Mathis, et al. Standards Track [Page 56] RFC 4898 TCP Extended Statistics MIB May 2007 SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of octets of application data buffered by TCP, pending first transmission, i.e., to the left of SND.NXT or SndMax. This data will generally be transmitted (and SND.NXT advanced to the left) as soon as there is an available congestion window (cwnd) or receiver window (rwin). This is the amount of data readily available for transmission, without scheduling the application. TCP performance may suffer if there is insufficient queued write data." ::= { tcpEStatsAppEntry 11 } tcpEStatsAppMaxAppWQueue OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of octets of application data buffered by TCP, pending first transmission. This is the maximum value of tcpEStatsAppCurAppWQueue. This pair of objects can be used to determine if insufficient queued data is steady state (suggesting insufficient queue space) or transient (suggesting insufficient application performance or excessive CPU load or scheduler latency)." ::= { tcpEStatsAppEntry 12 } tcpEStatsAppCurAppRQueue OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of octets of application data that has been acknowledged by TCP but not yet delivered to the application." ::= { tcpEStatsAppEntry 13 } tcpEStatsAppMaxAppRQueue OBJECT-TYPE SYNTAX Gauge32 UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION Mathis, et al. Standards Track [Page 57] RFC 4898 TCP Extended Statistics MIB May 2007 "The maximum number of octets of application data that has been acknowledged by TCP but not yet delivered to the application." ::= { tcpEStatsAppEntry 14 } -- ================================================================ -- -- Controls for Tuning TCP -- tcpEStatsTuneTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpEStatsTuneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains per-connection controls that can be used to work around a number of common problems that plague TCP over some paths. All can be characterized as limiting the growth of the congestion window so as to prevent TCP from overwhelming some component in the path. Entries are retained in this table for the number of seconds indicated by the tcpEStatsConnTableLatency object, after the TCP connection first enters the closed state." ::= { tcpEStats 7 } tcpEStatsTuneEntry OBJECT-TYPE SYNTAX TcpEStatsTuneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table is a control that can be used to place limits on each active TCP connection." INDEX { tcpEStatsConnectIndex } ::= { tcpEStatsTuneTable 1 } TcpEStatsTuneEntry ::= SEQUENCE { tcpEStatsTuneLimCwnd Unsigned32, tcpEStatsTuneLimSsthresh Unsigned32, tcpEStatsTuneLimRwin Unsigned32, tcpEStatsTuneLimMSS Unsigned32 } tcpEStatsTuneLimCwnd OBJECT-TYPE SYNTAX Unsigned32 Mathis, et al. Standards Track [Page 58] RFC 4898 TCP Extended Statistics MIB May 2007 UNITS "octets" MAX-ACCESS read-write STATUS current DESCRIPTION "A control to set the maximum congestion window that may be used, in octets." REFERENCE "RFC 2581, TCP Congestion Control" ::= { tcpEStatsTuneEntry 1 } tcpEStatsTuneLimSsthresh OBJECT-TYPE SYNTAX Unsigned32 UNITS "octets" MAX-ACCESS read-write STATUS current DESCRIPTION "A control to limit the maximum queue space (in octets) that this TCP connection is likely to occupy during slowstart. It can be implemented with the algorithm described in RFC 3742 by setting the max_ssthresh parameter to twice tcpEStatsTuneLimSsthresh. This algorithm can be used to overcome some TCP performance problems over network paths that do not have sufficient buffering to withstand the bursts normally present during slowstart." REFERENCE "RFC 3742, Limited Slow-Start for TCP with Large Congestion Windows" ::= { tcpEStatsTuneEntry 2 } tcpEStatsTuneLimRwin OBJECT-TYPE SYNTAX Unsigned32 UNITS "octets" MAX-ACCESS read-write STATUS current DESCRIPTION "A control to set the maximum window advertisement that may be sent, in octets." REFERENCE "RFC 793, Transmission Control Protocol" ::= { tcpEStatsTuneEntry 3 } tcpEStatsTuneLimMSS OBJECT-TYPE SYNTAX Unsigned32 UNITS "octets" MAX-ACCESS read-write Mathis, et al. Standards Track [Page 59] RFC 4898 TCP Extended Statistics MIB May 2007 STATUS current DESCRIPTION "A control to limit the maximum segment size in octets, that this TCP connection can use." REFERENCE "RFC 1191, Path MTU discovery" ::= { tcpEStatsTuneEntry 4 } -- ================================================================ -- -- TCP Extended Statistics Notifications Group -- tcpEStatsEstablishNotification NOTIFICATION-TYPE OBJECTS { tcpEStatsConnectIndex } STATUS current DESCRIPTION "The indicated connection has been accepted (or alternatively entered the established state)." ::= { tcpEStatsNotifications 1 } tcpEStatsCloseNotification NOTIFICATION-TYPE OBJECTS { tcpEStatsConnectIndex } STATUS current DESCRIPTION "The indicated connection has left the established state" ::= { tcpEStatsNotifications 2 } -- ================================================================ -- -- Conformance Definitions -- tcpEStatsCompliances OBJECT IDENTIFIER ::= { tcpEStatsConformance 1 } tcpEStatsGroups OBJECT IDENTIFIER ::= { tcpEStatsConformance 2 } -- -- Compliance Statements -- tcpEStatsCompliance MODULE-COMPLIANCE Mathis, et al. Standards Track [Page 60] RFC 4898 TCP Extended Statistics MIB May 2007 STATUS current DESCRIPTION "Compliance statement for all systems that implement TCP extended statistics." MODULE -- this module MANDATORY-GROUPS { tcpEStatsListenerGroup, tcpEStatsConnectIdGroup, tcpEStatsPerfGroup, tcpEStatsPathGroup, tcpEStatsStackGroup, tcpEStatsAppGroup } GROUP tcpEStatsListenerHCGroup DESCRIPTION "This group is mandatory for all systems that can wrap the values of the 32-bit counters in tcpEStatsListenerGroup in less than one hour." GROUP tcpEStatsPerfOptionalGroup DESCRIPTION "This group is optional for all systems." GROUP tcpEStatsPerfHCGroup DESCRIPTION "This group is mandatory for systems that can wrap the values of the 32-bit counters in tcpEStatsPerfGroup in less than one hour. Note that any system that can attain 10 Mb/s can potentially wrap 32-Bit Octet counters in under one hour." GROUP tcpEStatsPathOptionalGroup DESCRIPTION "This group is optional for all systems." GROUP tcpEStatsPathHCGroup DESCRIPTION "This group is mandatory for systems that can wrap the values of the 32-bit counters in tcpEStatsPathGroup in less than one hour. Note that any system that can attain 10 Mb/s can potentially wrap 32-Bit Octet counters in under one hour." GROUP tcpEStatsStackOptionalGroup Mathis, et al. Standards Track [Page 61] RFC 4898 TCP Extended Statistics MIB May 2007 DESCRIPTION "This group is optional for all systems." GROUP tcpEStatsAppHCGroup DESCRIPTION "This group is mandatory for systems that can wrap the values of the 32-bit counters in tcpEStatsStackGroup in less than one hour. Note that any system that can attain 10 Mb/s can potentially wrap 32-Bit Octet counters in under one hour." GROUP tcpEStatsAppOptionalGroup DESCRIPTION "This group is optional for all systems." GROUP tcpEStatsTuneOptionalGroup DESCRIPTION "This group is optional for all systems." GROUP tcpEStatsNotificationsGroup DESCRIPTION "This group is optional for all systems." GROUP tcpEStatsNotificationsCtlGroup DESCRIPTION "This group is mandatory for systems that include the tcpEStatsNotificationGroup." ::= { tcpEStatsCompliances 1 } -- ================================================================ -- -- Units of Conformance -- tcpEStatsListenerGroup OBJECT-GROUP OBJECTS { tcpEStatsListenerTableLastChange, tcpEStatsListenerStartTime, tcpEStatsListenerSynRcvd, tcpEStatsListenerInitial, tcpEStatsListenerEstablished, tcpEStatsListenerAccepted, tcpEStatsListenerExceedBacklog, tcpEStatsListenerCurConns, tcpEStatsListenerMaxBacklog, tcpEStatsListenerCurBacklog, Mathis, et al. Standards Track [Page 62] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsListenerCurEstabBacklog } STATUS current DESCRIPTION "The tcpEStatsListener group includes objects that provide valuable statistics and debugging information for TCP Listeners." ::= { tcpEStatsGroups 1 } tcpEStatsListenerHCGroup OBJECT-GROUP OBJECTS { tcpEStatsListenerHCSynRcvd, tcpEStatsListenerHCInitial, tcpEStatsListenerHCEstablished, tcpEStatsListenerHCAccepted, tcpEStatsListenerHCExceedBacklog } STATUS current DESCRIPTION "The tcpEStatsListenerHC group includes 64-bit counters in tcpEStatsListenerTable." ::= { tcpEStatsGroups 2 } tcpEStatsConnectIdGroup OBJECT-GROUP OBJECTS { tcpEStatsConnTableLatency, tcpEStatsConnectIndex } STATUS current DESCRIPTION "The tcpEStatsConnectId group includes objects that identify TCP connections and control how long TCP connection entries are retained in the tables." ::= { tcpEStatsGroups 3 } tcpEStatsPerfGroup OBJECT-GROUP OBJECTS { tcpEStatsPerfSegsOut, tcpEStatsPerfDataSegsOut, tcpEStatsPerfDataOctetsOut, tcpEStatsPerfSegsRetrans, tcpEStatsPerfOctetsRetrans, tcpEStatsPerfSegsIn, tcpEStatsPerfDataSegsIn, tcpEStatsPerfDataOctetsIn, tcpEStatsPerfElapsedSecs, tcpEStatsPerfElapsedMicroSecs, tcpEStatsPerfStartTimeStamp, tcpEStatsPerfCurMSS, tcpEStatsPerfPipeSize, tcpEStatsPerfMaxPipeSize, tcpEStatsPerfSmoothedRTT, tcpEStatsPerfCurRTO, Mathis, et al. Standards Track [Page 63] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsPerfCongSignals, tcpEStatsPerfCurCwnd, tcpEStatsPerfCurSsthresh, tcpEStatsPerfTimeouts, tcpEStatsPerfCurRwinSent, tcpEStatsPerfMaxRwinSent, tcpEStatsPerfZeroRwinSent, tcpEStatsPerfCurRwinRcvd, tcpEStatsPerfMaxRwinRcvd, tcpEStatsPerfZeroRwinRcvd } STATUS current DESCRIPTION "The tcpEStatsPerf group includes those objects that provide basic performance data for a TCP connection." ::= { tcpEStatsGroups 4 } tcpEStatsPerfOptionalGroup OBJECT-GROUP OBJECTS { tcpEStatsPerfSndLimTransRwin, tcpEStatsPerfSndLimTransCwnd, tcpEStatsPerfSndLimTransSnd, tcpEStatsPerfSndLimTimeRwin, tcpEStatsPerfSndLimTimeCwnd, tcpEStatsPerfSndLimTimeSnd } STATUS current DESCRIPTION "The tcpEStatsPerf group includes those objects that provide basic performance data for a TCP connection." ::= { tcpEStatsGroups 5 } tcpEStatsPerfHCGroup OBJECT-GROUP OBJECTS { tcpEStatsPerfHCDataOctetsOut, tcpEStatsPerfHCDataOctetsIn } STATUS current DESCRIPTION "The tcpEStatsPerfHC group includes 64-bit counters in the tcpEStatsPerfTable." ::= { tcpEStatsGroups 6 } tcpEStatsPathGroup OBJECT-GROUP OBJECTS { tcpEStatsControlPath, tcpEStatsPathRetranThresh, tcpEStatsPathNonRecovDAEpisodes, tcpEStatsPathSumOctetsReordered, Mathis, et al. Standards Track [Page 64] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsPathNonRecovDA } STATUS current DESCRIPTION "The tcpEStatsPath group includes objects that control the creation of the tcpEStatsPathTable, and provide information about the path for each TCP connection." ::= { tcpEStatsGroups 7 } tcpEStatsPathOptionalGroup OBJECT-GROUP OBJECTS { tcpEStatsPathSampleRTT, tcpEStatsPathRTTVar, tcpEStatsPathMaxRTT, tcpEStatsPathMinRTT, tcpEStatsPathSumRTT, tcpEStatsPathCountRTT, tcpEStatsPathMaxRTO, tcpEStatsPathMinRTO, tcpEStatsPathIpTtl, tcpEStatsPathIpTosIn, tcpEStatsPathIpTosOut, tcpEStatsPathPreCongSumCwnd, tcpEStatsPathPreCongSumRTT, tcpEStatsPathPostCongSumRTT, tcpEStatsPathPostCongCountRTT, tcpEStatsPathECNsignals, tcpEStatsPathDupAckEpisodes, tcpEStatsPathRcvRTT, tcpEStatsPathDupAcksOut, tcpEStatsPathCERcvd, tcpEStatsPathECESent } STATUS current DESCRIPTION "The tcpEStatsPath group includes objects that provide additional information about the path for each TCP connection." ::= { tcpEStatsGroups 8 } tcpEStatsPathHCGroup OBJECT-GROUP OBJECTS { tcpEStatsPathHCSumRTT } STATUS current DESCRIPTION "The tcpEStatsPathHC group includes 64-bit counters in the tcpEStatsPathTable." ::= { tcpEStatsGroups 9 } tcpEStatsStackGroup OBJECT-GROUP OBJECTS { tcpEStatsControlStack, tcpEStatsStackActiveOpen, tcpEStatsStackMSSSent, Mathis, et al. Standards Track [Page 65] RFC 4898 TCP Extended Statistics MIB May 2007 tcpEStatsStackMSSRcvd, tcpEStatsStackWinScaleSent, tcpEStatsStackWinScaleRcvd, tcpEStatsStackTimeStamps, tcpEStatsStackECN, tcpEStatsStackWillSendSACK, tcpEStatsStackWillUseSACK, tcpEStatsStackState, tcpEStatsStackNagle, tcpEStatsStackMaxSsCwnd, tcpEStatsStackMaxCaCwnd, tcpEStatsStackMaxSsthresh, tcpEStatsStackMinSsthresh, tcpEStatsStackInRecovery, tcpEStatsStackDupAcksIn, tcpEStatsStackSpuriousFrDetected, tcpEStatsStackSpuriousRtoDetected } STATUS current DESCRIPTION "The tcpEStatsConnState group includes objects that control the creation of the tcpEStatsStackTable, and provide information about the operation of algorithms used within TCP." ::= { tcpEStatsGroups 10 } tcpEStatsStackOptionalGroup OBJECT-GROUP OBJECTS { tcpEStatsStackSoftErrors, tcpEStatsStackSoftErrorReason, tcpEStatsStackSlowStart, tcpEStatsStackCongAvoid, tcpEStatsStackOtherReductions, tcpEStatsStackCongOverCount, tcpEStatsStackFastRetran, tcpEStatsStackSubsequentTimeouts, tcpEStatsStackCurTimeoutCount, tcpEStatsStackAbruptTimeouts, tcpEStatsStackSACKsRcvd, tcpEStatsStackSACKBlocksRcvd, tcpEStatsStackSendStall, tcpEStatsStackDSACKDups, tcpEStatsStackMaxMSS, tcpEStatsStackMinMSS, tcpEStatsStackSndInitial, tcpEStatsStackRecInitial, tcpEStatsStackCurRetxQueue, tcpEStatsStackMaxRetxQueue, tcpEStatsStackCurReasmQueue, tcpEStatsStackMaxReasmQueue } STATUS current DESCRIPTION "The tcpEStatsConnState group includes objects that provide additional information about the operation of algorithms used within TCP." Mathis, et al. Standards Track [Page 66] RFC 4898 TCP Extended Statistics MIB May 2007 ::= { tcpEStatsGroups 11 } tcpEStatsAppGroup OBJECT-GROUP OBJECTS { tcpEStatsControlApp, tcpEStatsAppSndUna, tcpEStatsAppSndNxt, tcpEStatsAppSndMax, tcpEStatsAppThruOctetsAcked, tcpEStatsAppRcvNxt, tcpEStatsAppThruOctetsReceived } STATUS current DESCRIPTION "The tcpEStatsConnState group includes objects that control the creation of the tcpEStatsAppTable, and provide information about the operation of algorithms used within TCP." ::= { tcpEStatsGroups 12 } tcpEStatsAppHCGroup OBJECT-GROUP OBJECTS { tcpEStatsAppHCThruOctetsAcked, tcpEStatsAppHCThruOctetsReceived } STATUS current DESCRIPTION "The tcpEStatsStackHC group includes 64-bit counters in the tcpEStatsStackTable." ::= { tcpEStatsGroups 13 } tcpEStatsAppOptionalGroup OBJECT-GROUP OBJECTS { tcpEStatsAppCurAppWQueue, tcpEStatsAppMaxAppWQueue, tcpEStatsAppCurAppRQueue, tcpEStatsAppMaxAppRQueue } STATUS current DESCRIPTION "The tcpEStatsConnState group includes objects that provide additional information about how applications are interacting with each TCP connection." ::= { tcpEStatsGroups 14 } tcpEStatsTuneOptionalGroup OBJECT-GROUP OBJECTS { tcpEStatsControlTune, tcpEStatsTuneLimCwnd, tcpEStatsTuneLimSsthresh, tcpEStatsTuneLimRwin, tcpEStatsTuneLimMSS Mathis, et al. Standards Track [Page 67] RFC 4898 TCP Extended Statistics MIB May 2007 } STATUS current DESCRIPTION "The tcpEStatsConnState group includes objects that control the creation of the tcpEStatsConnectionTable, which can be used to set tuning parameters for each TCP connection." ::= { tcpEStatsGroups 15 } tcpEStatsNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { tcpEStatsEstablishNotification, tcpEStatsCloseNotification } STATUS current DESCRIPTION "Notifications sent by a TCP extended statistics agent." ::= { tcpEStatsGroups 16 } tcpEStatsNotificationsCtlGroup OBJECT-GROUP OBJECTS { tcpEStatsControlNotify } STATUS current DESCRIPTION "The tcpEStatsNotificationsCtl group includes the object that controls the creation of the events in the tcpEStatsNotificationsGroup." ::= { tcpEStatsGroups 17 } END Mathis, et al. Standards Track [Page 68] RFC 4898 TCP Extended Statistics MIB May 2007 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: * Changing tcpEStatsConnTableLatency or any of the control objects in the tcpEStatsControl group (tcpEStatsControlPath, tcpEStatsControlStack, tcpEStatsControlApp, tcpEStatsControlTune) may affect the correctness of other management applications accessing this MIB. Generally, local policy should only permit limited write access to these controls (e.g., only by one management station or only during system configuration). * The objects in the tcpEStatsControlTune group (tcpEStatsTuneLimCwnd, tcpEStatsTuneLimSsthresh, tcpEStatsTuneLimRwin) can be used to limit resources consumed by TCP connections or to limit TCP throughput. An attacker might manipulate these objects to reduce performance to levels below the minimum acceptable for a particular application. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: * All objects which expose TCP sequence numbers (tcpEStatsAppSndUna, tcpEStatsAppSndNxt, tcpEStatsAppSndMax, tcpEStatsStackSndInitial, tcpEStatsAppRcvNxt, and tcpEStatsStackRecInitial) might make it easier for an attacker to forge in sequence TCP segments to disrupt TCP connections. * Nearly all objects in this (or any other) MIB may be used to estimate traffic volumes, which may reveal unanticipated information about an organization to the outside world. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Mathis, et al. Standards Track [Page 69] RFC 4898 TCP Extended Statistics MIB May 2007 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ------------ ----------------------- tcpEStatsMIB { mib-2 156 } 7. Normative References [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Mathis, et al. Standards Track [Page 70] RFC 4898 TCP Extended Statistics MIB May 2007 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 58, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999. [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003. [RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. Mathis, et al. Standards Track [Page 71] RFC 4898 TCP Extended Statistics MIB May 2007 8. Informative References [Mat97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communication Review, volume 27, number 3, July 1997. [Bra94] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for Congestion Detection and Avoidance", SIGCOMM'94, London, pp 24-35, October 1994. [Edd06] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", Work in Progress, May 2007. [POSIX] Portable Operating System Interface, IEEE Std 1003.1 [Pad98] Padhye, J., Firoiu, V., Towsley, D., Kurose, J., "Modeling TCP Throughput: A Simple Model and its Empirical Validation", SIGCOMM'98. [Web100] Mathis, M., J. Heffner, R. Reddy, "Web100: Extended TCP Instrumentation for Research, Education and Diagnosis", ACM Computer Communications Review, Vol 33, Num 3, July 2003. [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003. [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004. [RFC4614] Duke M., Braden, R., Eddy, W., Blanton, E. "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006. Mathis, et al. Standards Track [Page 72] RFC 4898 TCP Extended Statistics MIB May 2007 9. Contributors The following people contributed text that was incorporated into this document: Jon Saperia converted Web100 internal documentation into a true MIB. Some of the objects in this document were moved from an early version of the TCP-MIB by Bill Fenner, et al. Some of the object descriptions are based on an earlier unpublished document by Jeff Semke. 10. Acknowledgments This document is a product of the Web100 project (www.web100.org), a joint effort of Pittsburgh Supercomputing Center (www.psc.edu), National Center for Atmospheric Research (www.ncar.ucar.edu), and National Center for Supercomputer Applications (www.ncsa.edu). It would not have been possible without all of the hard work by the entire Web100 team, especially Peter O'Neal, who read and reread the entire document several times; Janet Brown and Marla Meehl, who patiently managed the unmanageable. The Web100 project would not have been successful without all of the early adopters who suffered our bugs to provide many good suggestions and insights into their needs for TCP instrumentation. Web100 was supported by the National Science Foundation under Grant No. 0083285 and a research grant from Cisco Systems. We would also like to thank all of the people who built experimental implementations of this MIB from early versions and provided us with constructive feedback: Glenn Turner at AARnet, Kristine Adamson at IBM, and Xinyan Zan at Microsoft. And last, but not least, we would like to thank Dan Romascanu, our "MIB Doctor" and Bert Wijnen, the Operations Area Director, for patiently steering us through the MIB review process. Mathis, et al. Standards Track [Page 73] RFC 4898 TCP Extended Statistics MIB May 2007 Authors' Addresses Matt Mathis Pittsburgh Supercomputing Center 300 S. Craig St. Pittsburgh, PA 15213 Phone: 412-268-4960 EMail: mathis@psc.edu John Heffner Pittsburgh Supercomputing Center 300 S. Craig St. Pittsburgh, PA 15213 Phone: 412-268-4960 EMail: jheffner@psc.edu Rajiv Raghunarayan Cisco Systems Inc. San Jose, CA 95134 Phone: 408 853 9612 EMail: raraghun@cisco.com Mathis, et al. Standards Track [Page 74] RFC 4898 TCP Extended Statistics MIB May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mathis, et al. Standards Track [Page 75] snmp-mibs-downloader-1.1/mibrfcs/rfc4935.txt0000644000000000000000000027610111402176072015576 0ustar Network Working Group C. DeSanti Request for Comments: 4935 H.K. Vivek Category: Standards Track K. McCloghrie Cisco Systems S. Gai Nuova Systems August 2007 Fibre Channel Fabric Configuration Server MIB 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. DeSanti, et al. Standards Track [Page 1] RFC 4935 Fabric Configuration Server MIB August 2007 Table of Contents 1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Short Overview of Fibre Channel .................................3 4. Relationship to Other MIBs ......................................5 5. MIB Overview ....................................................5 5.1. Fibre Channel Management Instance ..........................6 5.2. Switch Index ...............................................6 5.3. Fabric Index ...............................................6 5.4. The MIB Groups .............................................7 5.5. OS Logical Unit Number (LUN) Map Entries ...................8 6. The T11-FC-FABRIC-CONFIG-SERVER-MIB Module ......................9 7. IANA Considerations ............................................45 8. Security Considerations ........................................45 9. Acknowledgements ...............................................46 10. Normative References ..........................................47 11. Informative References ........................................48 DeSanti, et al. Standards Track [Page 2] RFC 4935 Fabric Configuration Server MIB August 2007 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Configuration Server function, which provides a means by which a management application can discover Fibre Channel fabric topology and attributes. Discovered topology includes Interconnect Elements (i.e., switches, hubs, bridges, etc.) and their ports, as well as "platforms" that consist of one or more Fibre Channel nodes. This memo was previously approved by INternational Committee for Information Technology Standards (INCITS) Task Group T11.5 (http://www.t11.org); this document is a product of the IETF's IMSS working group. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of Fibre Channel The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a DeSanti, et al. Standards Track [Page 3] RFC 4935 Fabric Configuration Server MIB August 2007 switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the Fabric, each node, and most ports, have globally unique names. These globally unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a Fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy. The Fibre Channel Fabric Configuration Server provides a way for a management application to discover Fibre Channel fabric topology and attributes. The Fabric Configuration Server is designed so that it can be distributed among switches and accessed from any Nx_Port. However, the Fabric Configuration Server is not restricted or required to be part of/within a Fabric. The information registered with and available from each Fabric Configuration Server is modeled as a Fabric consisting of one or more Interconnect Elements that each have some number of physical Ports, and one or more Fibre Channel nodes grouped together into Platforms to facilitate discovery and management. The Ports are connected either to other Ports on other Interconnect Elements, or to Nx_Ports. Each Interconnect Element may have attributes including its name, type, Domain Identifier, Management Identifier, Logical Name, Management Address(es), Information List, Zoning Enforcement Status, etc. Each Port may have attributes including its name, type, TX type, Module type, physical port number, attached port name(s), port state, speed, etc. Each platform may have attributes including its name, type, description, label, location, management address, etc. DeSanti, et al. Standards Track [Page 4] RFC 4935 Fabric Configuration Server MIB August 2007 The Fibre Channel Fabric Configuration Server is defined in the FC-GS specification. The Fabric Configuration Server is one of a set of functions that are collectively known as the Management Service. The latest version of the specification is [FC-GS-5]. The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4]. [FC-SW-4] carries forward the earlier specification for the operation of a single Fabric in a physical infrastructure, and augments it with the definition of Virtual Fabrics and with the specification of how multiple Virtual Fabrics can operate within one (or more) physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core Switch. 4. Relationship to Other MIBs The first standardized MIB for Fibre Channel [RFC2837] was focused on Fibre Channel switches. It has been replaced by the more generic Fibre Channel Management MIB [RFC4044], which defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB for Fibre Channel interfaces. This MIB extends beyond [RFC4044] to cover the functionality, in Fibre Channel switches, of providing Fibre Channel's Fabric Configuration Server function. This MIB imports some common Textual Conventions from T11-TC-MIB [RFC4439] and from T11-FC-NAME-SERVER-MIB [RFC4438]. It also imports URLString from NETWORK-SERVICES-MIB [RFC2788]. 5. MIB Overview This MIB module provides the means for monitoring the operation of, and configuring some parameters of, one or more Fabric Configuration Servers (FCS) in a Fibre Channel (FC) network. The capabilities provided include triggering a discovery of the configuration of one or more Fabrics, retrieving the results of such a discovery, as well as controlling and monitoring the operation of an FCS. The discovered configuration contains information about: - Interconnect Elements (IEs), i.e., switches, hubs, bridges, etc., - Ports on IEs, and - Platforms that consist of one or more FC nodes. DeSanti, et al. Standards Track [Page 5] RFC 4935 Fabric Configuration Server MIB August 2007 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [RFC4044] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [RFC4044] as the index value to uniquely identify each Fibre Channel management instance, for example, within the same SNMP context ([RFC3411], section 3.3.1). 5.2. Switch Index The FC-MGMT-MIB [RFC4044] defines the fcmSwitchTable as a table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value to uniquely identify a Fibre Channel switch amongst those (one or more) managed by the same Fibre Channel management instance. 5.3. Fabric Index With multiple Fabrics, each Fabric has its own instances of the Fabric-related management instrumentation. Thus, this MIB defines all Fabric-related information in tables that are INDEXed by an arbitrary integer, named a "Fabric Index". The syntax of a Fabric Index is T11FabricIndex, imported from T11-TC-MIB [RFC4439]. When a device is connected to a single physical Fabric, without use of any virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple virtual and/or physical Fabrics, this index provides a means to distinguish one Fabric from another. It is quite possible, and may even be likely, that a Fibre Channel switch will have ports connected to multiple virtual and/or physical Fabrics. Thus, in order to simplify a management protocol query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before t11FcsFabricIndex when they both appear in the same INDEX clause. DeSanti, et al. Standards Track [Page 6] RFC 4935 Fabric Configuration Server MIB August 2007 5.4. The MIB Groups This section describes the six MIB groups contained in the MIB module. 5.4.1. The t11FcsDiscoveredConfigGroup Group This group contains the Fabric configuration information discovered by Fabric Configuration Servers. 5.4.2. The t11FcsDiscoveryStatusGroup Group This group contains objects by which to monitor the status of discovery of Fabric configurations by Fabric Configuration Servers. 5.4.3. The t11FcsDiscoveryControlGroup Group This group contains objects for requesting a Fabric Configuration Server to discover the configuration of one or more Fabrics. 5.4.4. The t11FcsStatisticsGroup Group This group contains objects for Fabric Configuration Server statistics information. 5.4.5. The t11FcsNotificationGroup Group This group contains three notifications, generated when an FCS: - rejects a registration, deregistration, or query request; - completes discovery on a range of Fabrics; - learns that a management address of an Interconnect Element has changed. 5.4.5.1. Flow Control for Notifications When defining SNMP notifications for events that occur in the data- plane, the maximum frequency of their generation needs to be considered. Unless there is some limiting factor, such notifications need to be flow-controlled in some way, e.g., defined such that after some maximum number within a specified time interval have occurred, further notifications are suppressed for some subsequent time interval. However, as and when such a suppression occurs, the Network Management System (NMS) that didn't receive the notifications (because they were suppressed) needs to be able to obtain an indication of how many were suppressed. Therefore, an additional Counter32 object needs to be defined, and/or a new type of notification needs to be defined for use at the end of the interval. DeSanti, et al. Standards Track [Page 7] RFC 4935 Fabric Configuration Server MIB August 2007 While this is extra complexity, it is necessary for notifications that need to be flow-controlled. In contrast, for notifications such as all the ones defined in this MIB module, which are generated due to control-plane events (and are not able to start a chain reaction): - estimating the maximum number that could possibly be generated per unit time for each type of notification is too simplistic. For example, it's unreasonable to ask how many of the t11FcsDiscoveryCompleteNotify notifications can be generated in a time interval, because it depends on several factors: how big is the network? how many Virtual Fabrics need to be discovered? how quickly can the operator ask for another discovery after the last one completes? - the extra complexity of flow-controlling these types of notifications is not warranted. 5.4.6. The t11FcsNotificationInfoGroup Group This group contains notification control and notification information objects for monitoring Fabric Configuration Server request rejection and discovery of topology information. 5.5. OS Logical Unit Number (LUN) Map Entries A "Platform" is defined in FC-GS-5 to be not only a set of zero or more FC nodes, but also a set of zero or more "OS LUN Map Entries" (see Figure 8 in [FC-GS-5]). Information on "OS LUN Map Entries" is not included in this T11-FC-FABRIC-CONFIG-SERVER-MIB. Instead, information on LUN Maps can be obtained via the scsiLunMapGroup object group defined in the SCSI-MIB [RFC4455]. DeSanti, et al. Standards Track [Page 8] RFC 4935 Fabric Configuration Server MIB August 2007 6. The T11-FC-FABRIC-CONFIG-SERVER-MIB Module T11-FC-FABRIC-CONFIG-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Counter32, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TEXTUAL-CONVENTION, TruthValue, TimeStamp FROM SNMPv2-TC -- [RFC2579] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] URLString FROM NETWORK-SERVICES-MIB -- [RFC2788] FcPortType, FcNameIdOrZero, FcDomainIdOrZero, fcmInstanceIndex, fcmSwitchIndex, FcAddressIdOrZero FROM FC-MGMT-MIB -- [RFC4044] T11NsGs4RejectReasonCode FROM T11-FC-NAME-SERVER-MIB -- [RFC4438] T11FabricIndex FROM T11-TC-MIB -- [RFC4439] t11FamLocalSwitchWwn FROM T11-FC-FABRIC-ADDR-MGR-MIB; -- [RFC4439] t11FcFabricConfigServerMIB MODULE-IDENTITY LAST-UPDATED "200706270000Z" ORGANIZATION "For the initial versions, T11. For later versions, the IETF's IMSS Working Group." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kzm@cisco.com" DESCRIPTION "The MIB module for the management of a Fabric Configuration Server (FCS) in a Fibre Channel (FC) network. An FCS is defined by the FC-GS-5 standard. This DeSanti, et al. Standards Track [Page 9] RFC 4935 Fabric Configuration Server MIB August 2007 MIB provides the capabilities to trigger a discovery of the configuration of one or more Fabrics, to retrieve the results of such a discovery, as well as to control and monitor the operation of an FCS. The discovered configuration contains information about: - Interconnect Elements (IEs), i.e., switches, hubs, bridges, etc., - Ports on IEs, and - Platforms that consist of one or more FC nodes. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4935; see the RFC itself for full legal notices." REVISION "200706270000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4935." ::= { mib-2 162 } t11FcsMIBObjects OBJECT IDENTIFIER ::= { t11FcFabricConfigServerMIB 1 } t11FcsMIBConformance OBJECT IDENTIFIER ::= { t11FcFabricConfigServerMIB 2 } t11FcsNotifications OBJECT IDENTIFIER ::= { t11FcFabricConfigServerMIB 0 } t11FcsDiscovery OBJECT IDENTIFIER ::= { t11FcsMIBObjects 1 } t11FcsDiscoveredConfig OBJECT IDENTIFIER ::= { t11FcsMIBObjects 2 } t11FcsStats OBJECT IDENTIFIER ::= { t11FcsMIBObjects 3 } t11FcsNotificationInfo OBJECT IDENTIFIER ::= { t11FcsMIBObjects 4 } -- -- Textual Conventions -- T11FcListIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An index that identifies a list of elements. All elements that belong to the same list have the same index value. This syntax is used for objects which identify a list in the INDEX clause of a table of elements of that type of list." SYNTAX Unsigned32 (1..4294967295) T11FcListIndexPointerOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" DeSanti, et al. Standards Track [Page 10] RFC 4935 Fabric Configuration Server MIB August 2007 STATUS current DESCRIPTION "Objects with this syntax point to a list of elements contained in a table, by holding the same value as the object with syntax T11FcListIndex defined in the table's INDEX clause, or, zero to indicate an empty list. Note that such a table could have one row per list, or it could have one row per element of a list. The definition of an object with this syntax must identify the table(s) into which it points." SYNTAX Unsigned32 -- the default range of (0..4294967295) T11FcIeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of Interconnect Element (IE): unknown(1) - an unknown IE. other(2) - some other type of IE. switch(3) - the IE is a switch. hub(4) - the IE is a hub. bridge(5) - the IE is a bridge." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, Table 96." SYNTAX INTEGER { unknown(1), other(2), switch(3), hub(4), bridge(5) } T11FcPortState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The state of a port: unknown(1) - unknown state. other(2) - some other state. online(3) - port is in online state. offline(4) - port is in offline state. testing(5) - port is in testing state. fault(6) - port is faulty." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, Table 106." DeSanti, et al. Standards Track [Page 11] RFC 4935 Fabric Configuration Server MIB August 2007 SYNTAX INTEGER { unknown(1), other(2), online(3), offline(4), testing(5), fault(6) } T11FcPortTxType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The technology of the port transceiver: unknown(1) - unknown (includes the 'null' type) other(2) - some other technology shortwave850nm(3) - Short wave laser - SN (850 nm) longwave1550nm(4) - Long wave laser - LL (1550 nm) longwave1310nm(5) - Long wave laser cost reduced - LC (1310 nm) electrical(6) - Electrical - EL. tenGbaseSr850(7) - 10GBASE-SR 850nm laser tenGbaseLr1310(8) - 10GBASE-LR 1310nm laser tenGbaseEr1550(9) - 10GBASE-ER 1550nm laser tenGbaseLx1300(10) - 10GBASE-LX4 WWDM 1300nm laser tenGbaseSw850(11) - 10GBASE-SW 850nm laser tenGbaseLw1310(12) - 10GBASE-LW 1310nm laser tenGbaseEw1550(13) - 10GBASE-EW 1550nm laser " REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, Table 101." SYNTAX INTEGER { unknown(1), other(2), shortwave850nm(3), longwave1550nm(4), longwave1310nm(5), electrical(6), tenGbaseSr850(7), tenGbaseLr1310(8), tenGbaseEr1550(9), tenGbaseLx1300(10), tenGbaseSw850(11), tenGbaseLw1310(12), tenGbaseEw1550(13) } DeSanti, et al. Standards Track [Page 12] RFC 4935 Fabric Configuration Server MIB August 2007 T11FcsRejectReasonExplanation ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The reject reason code explanation: noAdditionalExplanation(1) - no additional explanation. invNameIdForIEOrPort(2) - the format of IE or port name is invalid. ieListNotAvailable(3) - IE list is not available. ieTypeNotAvailable(4) - IE type is not available. domainIdNotAvailable(5) - Domain ID is not available. mgmtIdNotAvailable(6) - mgmt ID is not available. fabNameNotAvailable(7) - Fabric_Name is not available. ielogNameNotAvailable(8) - IE logical name is not available. mgmtAddrListNotAvailable(9) - mgmt address list is not available. ieInfoListNotAvailable(10) - IE info list is not available. portListNotAvailable(11) - port list is not available. portTypeNotAvailable(12) - port type is not available. phyPortNumNotAvailable(13) - physical port number is not available. attPortNameListNotAvailable(14) - attached port name list is not available. portStateNotAvailable(15) - port state is not available. unableToRegIELogName(16) - not able to register IE logical name. platformNameNoExist(17) - platform name does not exist. platformNameAlreadyExists(18) - platform name already exists. platformNodeNameNoExists(19) - platform node name does not exist. platformNodeNameAlreadyExists(20) - platform node name already exists. resourceUnavailable(21) - resource unavailable. noEntriesInLunMap(22) DeSanti, et al. Standards Track [Page 13] RFC 4935 Fabric Configuration Server MIB August 2007 - zero entries in OS LUN Map. invalidDeviceNameLength(23) - invalid OS device name length. multipleAttributes(24) - multiple attributes of same type in platform attribute block. invalidAttribBlockLength(25) - invalid platform attribute block length. attributesMissing(26) - required platform attributes not present." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, Table 124." SYNTAX INTEGER { noAdditionalExplanation(1), invNameIdForIEOrPort(2), ieListNotAvailable(3), ieTypeNotAvailable(4), domainIdNotAvailable(5), mgmtIdNotAvailable(6), fabNameNotAvailable(7), ielogNameNotAvailable(8), mgmtAddrListNotAvailable(9), ieInfoListNotAvailable(10), portListNotAvailable(11), portTypeNotAvailable(12), phyPortNumNotAvailable(13), attPortNameListNotAvailable(14), portStateNotAvailable(15), unableToRegIELogName(16), platformNameNoExist(17), platformNameAlreadyExists(18), platformNodeNameNoExists(19), platformNodeNameAlreadyExists(20), resourceUnavailable(21), noEntriesInLunMap(22), invalidDeviceNameLength(23), multipleAttributes(24), invalidAttribBlockLength(25), attributesMissing(26) } -- -- Objects for Fabric Discovery -- t11FcsFabricDiscoveryTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsFabricDiscoveryEntry DeSanti, et al. Standards Track [Page 14] RFC 4935 Fabric Configuration Server MIB August 2007 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains control information for discovery of Fabric configuration by switches. Values written to objects in this table are not retained over agent reboots." ::= { t11FcsDiscovery 1 } t11FcsFabricDiscoveryEntry OBJECT-TYPE SYNTAX T11FcsFabricDiscoveryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Control information for discovery by the switch identified by fcmInstanceIndex and fcmSwitchIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex } ::= { t11FcsFabricDiscoveryTable 1 } T11FcsFabricDiscoveryEntry ::= SEQUENCE { t11FcsFabricDiscoveryRangeLow T11FabricIndex, t11FcsFabricDiscoveryRangeHigh T11FabricIndex, t11FcsFabricDiscoveryStart INTEGER, t11FcsFabricDiscoveryTimeOut Unsigned32 } t11FcsFabricDiscoveryRangeLow OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS read-write STATUS current DESCRIPTION "The discovery by a particular switch operates within all existing Fabrics that have a Fabric Index within a specific inclusive range. This object specifies the minimum Fabric Index value within that range. This value just represents the lower end of the range and does not necessarily represent any existing Fabric." ::= { t11FcsFabricDiscoveryEntry 1 } t11FcsFabricDiscoveryRangeHigh OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS read-write STATUS current DESCRIPTION "The discovery by a particular switch operates within all existing Fabrics that have a Fabric DeSanti, et al. Standards Track [Page 15] RFC 4935 Fabric Configuration Server MIB August 2007 Index within a specific inclusive range. This object specifies the maximum Fabric Index value within that range. This value just represents the higher end of the range and does not necessarily represent any existing Fabric." ::= { t11FcsFabricDiscoveryEntry 2 } t11FcsFabricDiscoveryStart OBJECT-TYPE SYNTAX INTEGER { start(1), noOp(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the capability to trigger the start of a discovery by a Fabric Configuration Server. If this object is set to 'start', then the discovery is started on those Fabrics that have their Fabric Index value in the range specified by t11FcsFabricDiscoveryRangeLow and t11FcsFabricDiscoveryRangeHigh. It is recommended that whenever an instance of this object is set to 'start', that the desired range be specified at the same time by setting the corresponding instances of t11FcsFabricDiscoveryRangeLow and t11FcsFabricDiscoveryRangeHigh. Setting this object to 'start' will be rejected if a discovery is already/still in progress on any Fabrics in the specified range. No action is taken if this object is set to 'noOp'. The value of this object when read is always 'noOp'." ::= { t11FcsFabricDiscoveryEntry 3 } t11FcsFabricDiscoveryTimeOut OBJECT-TYPE SYNTAX Unsigned32 (300..86400) UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum interval of time for which the discovered Fabric information is cached by a Fabric Configuration Server." DEFVAL { 900 } ::= { t11FcsFabricDiscoveryEntry 4 } -- DeSanti, et al. Standards Track [Page 16] RFC 4935 Fabric Configuration Server MIB August 2007 -- Discovery State table -- t11FcsDiscoveryStateTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsDiscoveryStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the status of discovery of locally known Fabrics." ::= { t11FcsDiscovery 2 } t11FcsDiscoveryStateEntry OBJECT-TYPE SYNTAX T11FcsDiscoveryStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The discovery status for a particular Fabric on the switch identified by fcmInstanceIndex and fcmSwitchIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex } ::= { t11FcsDiscoveryStateTable 1 } T11FcsDiscoveryStateEntry ::= SEQUENCE { t11FcsFabricIndex T11FabricIndex, t11FcsDiscoveryStatus INTEGER, t11FcsDiscoveryCompleteTime TimeStamp } t11FcsFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric. In a Fabric conformant to FC-SW-4, multiple Virtual Fabrics can operate within one (or more) physical infrastructures, and this index value is used to uniquely identify a particular (physical or virtual) Fabric within a physical infrastructure. In a Fabric conformant to versions earlier than FC-SW-4, only a single Fabric could operate within a physical infrastructure, and thus, the value of this Fabric Index was defined to always be 1." ::= { t11FcsDiscoveryStateEntry 1 } DeSanti, et al. Standards Track [Page 17] RFC 4935 Fabric Configuration Server MIB August 2007 t11FcsDiscoveryStatus OBJECT-TYPE SYNTAX INTEGER { inProgress(1), completed(2), localOnly(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The status of the discovery for the particular Fabric. Initially when the switch comes up, all instances of this object have the value: 'localOnly', and the database contains only local information, i.e., no information discovered via the Fabric Configuration Server protocol specified in FC-GS-5. If t11FcsFabricDiscoveryStart is set to 'start' for a range of Fabrics that includes this Fabric, then the value of this object transitions to 'inProgress'. When the discovery completes, this object transitions to 'completed', and the data is cached for the minimum interval of time specified by t11FcsFabricDiscoveryTimeOut. After this interval has been exceeded, the data may be lost, in which case, the value of this object changes to 'localOnly'. This object cannot be set via SNMP to any value other than 'localOnly'. If this object is set (via SNMP) to 'localOnly', the cached data for the Fabric is discarded immediately, and if a discovery initiated from this switch was in progress for this Fabric, then that discovery is aborted." ::= { t11FcsDiscoveryStateEntry 2 } t11FcsDiscoveryCompleteTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the value of sysUpTime at which discovery was most recently completed or aborted on this Fabric. This object contains the value of zero before the first discovery on this Fabric." ::= { t11FcsDiscoveryStateEntry 3 } DeSanti, et al. Standards Track [Page 18] RFC 4935 Fabric Configuration Server MIB August 2007 -- -- The Database of Fabric Configuration Information -- -- Interconnect Element table -- t11FcsIeTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsIeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Interconnect Elements. Interconnect Elements (IEs) are switches, hubs, bridges etc. By default, the Fabric Configuration Server will maintain detailed information pertaining only to local resources. As far as discovered topology is concerned, only the IE name, type, and Domain ID information will be maintained. If a discovery cycle is triggered on a set of Fabrics, this table along with the Port and Platform tables will be populated with the discovered information. The discovered data will be retained in this table for at least t11FcsFabricDiscoveryTimeOut seconds after the completion of its discovery or until the discovered data is invalidated." ::= { t11FcsDiscoveredConfig 1 } t11FcsIeEntry OBJECT-TYPE SYNTAX T11FcsIeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an Interconnect Element that was discovered on a Fabric (identified by t11FcsFabricIndex), by a switch (identified by fcmInstanceIndex and fcmSwitchIndex)." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex, t11FcsIeName } ::= { t11FcsIeTable 1 } T11FcsIeEntry ::= SEQUENCE { t11FcsIeName FcNameIdOrZero, t11FcsIeType T11FcIeType, DeSanti, et al. Standards Track [Page 19] RFC 4935 Fabric Configuration Server MIB August 2007 t11FcsIeDomainId FcDomainIdOrZero, t11FcsIeMgmtId FcAddressIdOrZero, t11FcsIeFabricName FcNameIdOrZero, t11FcsIeLogicalName OCTET STRING, t11FcsIeMgmtAddrListIndex T11FcListIndexPointerOrZero, t11FcsIeInfoList OCTET STRING } t11FcsIeName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The WWN of an Interconnect Element. This object uniquely identifies an Interconnect Element on a Fabric. If the IE is a switch, then this object is the Switch_Name (WWN) of the switch." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.1." ::= { t11FcsIeEntry 1 } t11FcsIeType OBJECT-TYPE SYNTAX T11FcIeType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this Interconnect Element." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.2" ::= { t11FcsIeEntry 2 } t11FcsIeDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Domain ID of this Interconnect Element." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.3." ::= { t11FcsIeEntry 3 } t11FcsIeMgmtId OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DeSanti, et al. Standards Track [Page 20] RFC 4935 Fabric Configuration Server MIB August 2007 DESCRIPTION "The management identifier of this Interconnect Element. If the Interconnect Element is a switch, this object will be the Domain Controller identifier of the switch. When the value of the identifier is unknown, this object contains the all-zeros value: x'00 00 00'." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.4." DEFVAL { '000000'h } ::= { t11FcsIeEntry 4 } t11FcsIeFabricName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8 | 16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Fabric_Name (WWN) of this Interconnect Element. When the Fabric_Name is unknown, this object contains the all-zeros value: x'00 00 00 00 00 00 00 00'." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.5." DEFVAL { '0000000000000000'h } ::= { t11FcsIeEntry 5 } t11FcsIeLogicalName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The logical name of this Interconnect Element. When the logical name is unknown, this object contains the zero-length string." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.6." ::= { t11FcsIeEntry 6 } t11FcsIeMgmtAddrListIndex OBJECT-TYPE SYNTAX T11FcListIndexPointerOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The management address list for this Interconnect Element. This object points to an entry in the t11FcsMgmtAddrListTable." REFERENCE DeSanti, et al. Standards Track [Page 21] RFC 4935 Fabric Configuration Server MIB August 2007 "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.7." ::= { t11FcsIeEntry 7 } t11FcsIeInfoList OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..252)) MAX-ACCESS read-only STATUS current DESCRIPTION "The information list for this Interconnect Element. The value of this object is formatted as specified in FC-GS-5, i.e., it has the following substrings in order: vendor name, model name/number, and release code/level, followed by zero or more substrings of vendor-specific information. Each substring is terminated with a byte containing a null value (x'00')." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.8" ::= { t11FcsIeEntry 8 } -- -- Management Address List table -- t11FcsMgmtAddrListTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsMgmtAddrListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of management address lists that are currently referenced by any instance of the t11FcsIeMgmtAddrListIndex or t11FcsPlatformMgmtAddrListIndex objects." ::= { t11FcsDiscoveredConfig 2 } t11FcsMgmtAddrListEntry OBJECT-TYPE SYNTAX T11FcsMgmtAddrListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one management address in a management address list, which is known to a switch (identified by fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsMgmtAddrListIndex, t11FcsMgmtAddrIndex } DeSanti, et al. Standards Track [Page 22] RFC 4935 Fabric Configuration Server MIB August 2007 ::= { t11FcsMgmtAddrListTable 1 } T11FcsMgmtAddrListEntry ::= SEQUENCE { t11FcsMgmtAddrListIndex T11FcListIndex, t11FcsMgmtAddrIndex Unsigned32, t11FcsMgmtAddr URLString } t11FcsMgmtAddrListIndex OBJECT-TYPE SYNTAX T11FcListIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value of the management address list." ::= { t11FcsMgmtAddrListEntry 1 } t11FcsMgmtAddrIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer value to distinguish different management addresses in the same list." ::= { t11FcsMgmtAddrListEntry 2 } t11FcsMgmtAddr OBJECT-TYPE SYNTAX URLString MAX-ACCESS read-only STATUS current DESCRIPTION "The management address of this entry. The format of this object is a Uniform Resource Locator (URL), e.g., for SNMP, see RFC 4088." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.2.7" ::= { t11FcsMgmtAddrListEntry 3 } -- -- Ports -- t11FcsPortTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 23] RFC 4935 Fabric Configuration Server MIB August 2007 "This table contains information about the ports of IEs." ::= { t11FcsDiscoveredConfig 4 } t11FcsPortEntry OBJECT-TYPE SYNTAX T11FcsPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular port of an Interconnect Element (identified by t11FcsIeName). The port is connected to a Fabric (identified by t11FcsFabricIndex) and known to a switch (identified by fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex, t11FcsIeName, t11FcsPortName } ::= { t11FcsPortTable 1 } T11FcsPortEntry ::= SEQUENCE { t11FcsPortName FcNameIdOrZero, t11FcsPortType FcPortType, t11FcsPortTxType T11FcPortTxType, t11FcsPortModuleType Unsigned32, t11FcsPortPhyPortNum Unsigned32, t11FcsPortAttachPortNameIndex T11FcListIndexPointerOrZero, t11FcsPortState T11FcPortState, t11FcsPortSpeedCapab OCTET STRING, t11FcsPortOperSpeed OCTET STRING, t11FcsPortZoningEnfStatus OCTET STRING } t11FcsPortName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Port_Name (WWN) of the port for which this row contains information." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.1." ::= { t11FcsPortEntry 1 } t11FcsPortType OBJECT-TYPE SYNTAX FcPortType MAX-ACCESS read-only STATUS current DESCRIPTION "The Port Type of this port." DeSanti, et al. Standards Track [Page 24] RFC 4935 Fabric Configuration Server MIB August 2007 REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.2." ::= { t11FcsPortEntry 2 } t11FcsPortTxType OBJECT-TYPE SYNTAX T11FcPortTxType MAX-ACCESS read-only STATUS current DESCRIPTION "The Port TX Type of this port." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.3." ::= { t11FcsPortEntry 3 } t11FcsPortModuleType OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The port module type of this port." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.4." ::= { t11FcsPortEntry 4 } t11FcsPortPhyPortNum OBJECT-TYPE SYNTAX Unsigned32 -- the default range of (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The physical number for this port. FC-GS-5 says that the contents of this field, which are carried in a field with a size of 4 bytes, are not to be restricted due to vendor-specific methods for numbering physical ports." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.5." ::= { t11FcsPortEntry 5 } t11FcsPortAttachPortNameIndex OBJECT-TYPE SYNTAX T11FcListIndexPointerOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The attached port name list for this port. This object points to an entry in the t11FcsAttachPortNameListTable." DeSanti, et al. Standards Track [Page 25] RFC 4935 Fabric Configuration Server MIB August 2007 REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.6." ::= { t11FcsPortEntry 6 } t11FcsPortState OBJECT-TYPE SYNTAX T11FcPortState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of this port." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.7." ::= { t11FcsPortEntry 7 } t11FcsPortSpeedCapab OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "The port speed capabilities of this port. The two octets of the value are formatted as described in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.8." ::= { t11FcsPortEntry 8 } t11FcsPortOperSpeed OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "The operating speed of this port. The two octets of the value are formatted as described in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.9." ::= { t11FcsPortEntry 9 } t11FcsPortZoningEnfStatus OBJECT-TYPE SYNTAX OCTET STRING (SIZE (12)) MAX-ACCESS read-only STATUS current DESCRIPTION "The zoning enforcement status of this port. The 12 octets of the value are formatted as described in FC-GS-5." REFERENCE DeSanti, et al. Standards Track [Page 26] RFC 4935 Fabric Configuration Server MIB August 2007 "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.10." ::= { t11FcsPortEntry 10 } -- -- Attached Port List table -- t11FcsAttachPortNameListTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsAttachPortNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all the lists of attach port names." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.6" ::= { t11FcsDiscoveredConfig 5 } t11FcsAttachPortNameListEntry OBJECT-TYPE SYNTAX T11FcsAttachPortNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the name of a particular attached port, which is known to a switch (identified by fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsAttachPortNameListIndex, t11FcsAttachPortName } ::= { t11FcsAttachPortNameListTable 1 } T11FcsAttachPortNameListEntry ::= SEQUENCE { t11FcsAttachPortNameListIndex T11FcListIndex, t11FcsAttachPortName OCTET STRING } t11FcsAttachPortNameListIndex OBJECT-TYPE SYNTAX T11FcListIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value of the attach port name list." ::= { t11FcsAttachPortNameListEntry 1 } t11FcsAttachPortName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (12)) MAX-ACCESS read-only DeSanti, et al. Standards Track [Page 27] RFC 4935 Fabric Configuration Server MIB August 2007 STATUS current DESCRIPTION "The attached port name. Zero or more of these names may be associated with a port object. The first 8 bytes of this object contain the WWN of the port followed by 2 reserved bytes. Following this is one byte of Port flags and one byte of Port type, as described in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.3.6" ::= { t11FcsAttachPortNameListEntry 2 } -- -- Platforms -- t11FcsPlatformTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsPlatformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on platforms. By default, this table only contains local (e.g., for a local switch) information. If a discovery is triggered, this table will also contain information gathered by the discovery process. The discovered information is retained in this table for at least t11FcsFabricDiscoveryTimeOut seconds after the completion of its discovery or until the discovered cache is invalidated." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4" ::= { t11FcsDiscoveredConfig 6 } t11FcsPlatformEntry OBJECT-TYPE SYNTAX T11FcsPlatformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular platform, which is known to a switch (identified by fcmInstanceIndex and fcmSwitchIndex). A platform can contain multiple nodes. Information on nodes is contained in the t11FcsNodeNameListTable. The t11FcsPlatformNodeNameListIndex object in this table DeSanti, et al. Standards Track [Page 28] RFC 4935 Fabric Configuration Server MIB August 2007 points to the list of nodes contained in this platform. Similarly, the t11FcsPlatformMgmtAddrListIndex object in this table points to the list of management addresses associated with this platform." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex, t11FcsPlatformIndex } ::= { t11FcsPlatformTable 1 } T11FcsPlatformEntry ::= SEQUENCE { t11FcsPlatformIndex Unsigned32, t11FcsPlatformName OCTET STRING, t11FcsPlatformType OCTET STRING, t11FcsPlatformNodeNameListIndex T11FcListIndexPointerOrZero, t11FcsPlatformMgmtAddrListIndex T11FcListIndexPointerOrZero, t11FcsPlatformVendorId SnmpAdminString, t11FcsPlatformProductId SnmpAdminString, t11FcsPlatformProductRevLevel SnmpAdminString, t11FcsPlatformDescription SnmpAdminString, t11FcsPlatformLabel SnmpAdminString, t11FcsPlatformLocation SnmpAdminString, t11FcsPlatformSystemID SnmpAdminString, t11FcsPlatformSysMgmtAddr T11FcListIndexPointerOrZero, t11FcsPlatformClusterId SnmpAdminString, t11FcsPlatformClusterMgmtAddr T11FcListIndexPointerOrZero, t11FcsPlatformFC4Types OCTET STRING } t11FcsPlatformIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer value to distinguish one platform from other platforms in the same Fabric." ::= { t11FcsPlatformEntry 1 } t11FcsPlatformName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this platform. The last byte of the value indicates the format of the name (even if the name itself is the zero-length string) as specified in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.2" ::= { t11FcsPlatformEntry 2 } DeSanti, et al. Standards Track [Page 29] RFC 4935 Fabric Configuration Server MIB August 2007 t11FcsPlatformType OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) MAX-ACCESS read-only STATUS current DESCRIPTION "The type(s) of this platform, encoded in 4 bytes as specified in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.3" ::= { t11FcsPlatformEntry 3 } t11FcsPlatformNodeNameListIndex OBJECT-TYPE SYNTAX T11FcListIndexPointerOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The list of nodes for this platform. This object points to an entry in the t11FcsNodeNameListTable." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.6" ::= { t11FcsPlatformEntry 4 } t11FcsPlatformMgmtAddrListIndex OBJECT-TYPE SYNTAX T11FcListIndexPointerOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The list of management addresses for this platform. This object points to an entry in the t11FcsMgmtAddrListTable." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.7" ::= { t11FcsPlatformEntry 5 } t11FcsPlatformVendorId OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 12)) MAX-ACCESS read-only STATUS current DESCRIPTION "The identifier of the vendor of this platform, in the format specified in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.5" ::= { t11FcsPlatformEntry 6 } DeSanti, et al. Standards Track [Page 30] RFC 4935 Fabric Configuration Server MIB August 2007 t11FcsPlatformProductId OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor's product and/or model identifier for this platform, in the format specified in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.5" ::= { t11FcsPlatformEntry 7 } t11FcsPlatformProductRevLevel OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 4..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The product revision level for this platform, in the format specified in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.5" ::= { t11FcsPlatformEntry 8 } t11FcsPlatformDescription OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 4..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The description of this platform, in the format specified in FC-GS-5. This value should include the full name and version identification of the platform's hardware type and software operating system." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.10" ::= { t11FcsPlatformEntry 9 } t11FcsPlatformLabel OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 4..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "An administratively assigned symbolic name for the platform, in the format specified in FC-GS-5." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.11" DeSanti, et al. Standards Track [Page 31] RFC 4935 Fabric Configuration Server MIB August 2007 ::= { t11FcsPlatformEntry 10 } t11FcsPlatformLocation OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 4..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The physical location of the platform, in the format specified in FC-GS-5 (e.g., 'telephone closet, 3rd floor')." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.12" ::= { t11FcsPlatformEntry 11 } t11FcsPlatformSystemID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 4..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "An identifier for a hosting system that this platform is associated with. This identifier is used to associate platforms of logical types (e.g., logical partitions) with a physical system." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.5" ::= { t11FcsPlatformEntry 12 } t11FcsPlatformSysMgmtAddr OBJECT-TYPE SYNTAX T11FcListIndexPointerOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "A list of management addresses for the platform." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, sections 6.2.3.4.5 and 6.2.3.2.7." ::= { t11FcsPlatformEntry 13 } t11FcsPlatformClusterId OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0 | 4..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "An identifier for a cluster that this platform is associated with, where a cluster is a set of independent platforms that are managed together to provide increased performance capabilities, failover, etc." DeSanti, et al. Standards Track [Page 32] RFC 4935 Fabric Configuration Server MIB August 2007 REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.5" ::= { t11FcsPlatformEntry 14 } t11FcsPlatformClusterMgmtAddr OBJECT-TYPE SYNTAX T11FcListIndexPointerOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "A list of management addresses for the cluster identified in the corresponding instance of t11FcsPlatformClusterId." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, sections 6.2.3.4.5 and 6.2.3.2.7." ::= { t11FcsPlatformEntry 15 } t11FcsPlatformFC4Types OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC-4 types supported by this platform, formatted as a bit mask as specified in FC-GS-5. If this object contains the zero-length string, the types are unknown." REFERENCE "ANSI INCITS 427-2007, Fibre Channel - Generic Services 5, FC-GS-5, section 6.2.3.4.5" ::= { t11FcsPlatformEntry 16 } -- -- Node Name List table -- t11FcsNodeNameListTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsNodeNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all the lists of nodes." ::= { t11FcsDiscoveredConfig 7 } t11FcsNodeNameListEntry OBJECT-TYPE SYNTAX T11FcsNodeNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a node, which is known to a DeSanti, et al. Standards Track [Page 33] RFC 4935 Fabric Configuration Server MIB August 2007 switch (identified by fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsNodeNameListIndex, t11FcsNodeName } ::= { t11FcsNodeNameListTable 1 } T11FcsNodeNameListEntry ::= SEQUENCE { t11FcsNodeNameListIndex T11FcListIndex, t11FcsNodeName FcNameIdOrZero } t11FcsNodeNameListIndex OBJECT-TYPE SYNTAX T11FcListIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value of the node name list." ::= { t11FcsNodeNameListEntry 1 } t11FcsNodeName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8 | 16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this node." ::= { t11FcsNodeNameListEntry 2 } -- -- Statistics -- t11FcsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all the statistics related to the Fabric Configuration Server." ::= { t11FcsStats 1 } t11FcsStatsEntry OBJECT-TYPE SYNTAX T11FcsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for a particular Fabric (identified by t11FcsFabricIndex) on a switch (identified by fcmInstanceIndex and fcmSwitchIndex)." DeSanti, et al. Standards Track [Page 34] RFC 4935 Fabric Configuration Server MIB August 2007 INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex } ::= { t11FcsStatsTable 1 } T11FcsStatsEntry ::= SEQUENCE { t11FcsInGetReqs Counter32, t11FcsOutGetReqs Counter32, t11FcsInRegReqs Counter32, t11FcsOutRegReqs Counter32, t11FcsInDeregReqs Counter32, t11FcsOutDeregReqs Counter32, t11FcsRejects Counter32 } t11FcsInGetReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Get Requests received by the Fabric Configuration Server on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcsStatsEntry 1 } t11FcsOutGetReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Get Requests sent by the Fabric Configuration Server on this Fabric to other servers in the Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcsStatsEntry 2 } t11FcsInRegReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registration Requests received by the Fabric Configuration Server on this Fabric. DeSanti, et al. Standards Track [Page 35] RFC 4935 Fabric Configuration Server MIB August 2007 This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcsStatsEntry 3 } t11FcsOutRegReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registration Requests sent by the Fabric Configuration Server on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcsStatsEntry 4 } t11FcsInDeregReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Deregistration Requests received by the Fabric Configuration Server on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcsStatsEntry 5 } t11FcsOutDeregReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Deregistration Requests sent by the Fabric Configuration Server on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcsStatsEntry 6 } t11FcsRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of requests rejected by the Fabric Configuration Server on this Fabric. DeSanti, et al. Standards Track [Page 36] RFC 4935 Fabric Configuration Server MIB August 2007 This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcsStatsEntry 7 } -- -- Notification Control Table -- t11FcsNotifyControlTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcsNotifyControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control information for notifications generated due to Fabric Configuration Server events. Values written to objects in this table should be persistent/retained over agent reboots." ::= { t11FcsNotificationInfo 1 } t11FcsNotifyControlEntry OBJECT-TYPE SYNTAX T11FcsNotifyControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains notification control information for a Fabric Configuration Server on a particular Fabric (identified by t11FcsFabricIndex) on a particular switch (identified by fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex } ::= { t11FcsNotifyControlTable 1 } T11FcsNotifyControlEntry ::= SEQUENCE { t11FcsReqRejectNotifyEnable TruthValue, t11FcsDiscoveryCompNotifyEnable TruthValue, t11FcsMgmtAddrChangeNotifyEnable TruthValue, t11FcsRejectCtCommandString OCTET STRING, t11FcsRejectRequestSource FcNameIdOrZero, t11FcsRejectReasonCode T11NsGs4RejectReasonCode, t11FcsRejectReasonCodeExp T11FcsRejectReasonExplanation, t11FcsRejectReasonVendorCode OCTET STRING } t11FcsReqRejectNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write DeSanti, et al. Standards Track [Page 37] RFC 4935 Fabric Configuration Server MIB August 2007 STATUS current DESCRIPTION "This object specifies if the Fabric Configuration Server should generate 't11FcsRqRejectNotification' notifications. If the value of this object is 'true', then the notification is issued. If the value of this object is 'false', then the notification is not issued." DEFVAL { false } ::= { t11FcsNotifyControlEntry 1 } t11FcsDiscoveryCompNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies if the Fabric Configuration Server should generate 't11FcsDiscoveryCompleteNotify' notifications. If the value of this object is 'true', then the notification is issued. If the value of this object is 'false', then the notification is not issued." DEFVAL { false } ::= { t11FcsNotifyControlEntry 2 } t11FcsMgmtAddrChangeNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies if the Fabric Configuration Server should generate 't11FcsMgmtAddrChangeNotify' notifications. If the value of this object is 'true', then the notification is issued. If the value of this object is 'false', then the notification is not issued." DEFVAL { false } ::= { t11FcsNotifyControlEntry 3 } t11FcsRejectCtCommandString OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The binary content of the Fabric Configuration Server DeSanti, et al. Standards Track [Page 38] RFC 4935 Fabric Configuration Server MIB August 2007 request, formatted as an octet string (in network byte order) containing the Common Transport Information Unit (CT_IU), as described in Table 2 of FC-GS-5 (including the preamble), which was most recently rejected by the Fabric Configuration Server for this Fabric. This object contains the zero-length string if and when the CT-IU's content is unavailable. When the length of this object is 255 octets, it contains the first 255 octets of the CT-IU (in network byte order)." ::= { t11FcsNotifyControlEntry 4 } t11FcsRejectRequestSource OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The WWN that was the source of the CT_IU contained in the corresponding instance of t11FcsRejectCtCommandString." ::= { t11FcsNotifyControlEntry 5 } t11FcsRejectReasonCode OBJECT-TYPE SYNTAX T11NsGs4RejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the reason code corresponding to the latest Fabric Configuration Server request rejected by the local system." ::= { t11FcsNotifyControlEntry 6 } t11FcsRejectReasonCodeExp OBJECT-TYPE SYNTAX T11FcsRejectReasonExplanation MAX-ACCESS read-only STATUS current DESCRIPTION "When the corresponding instance of t11FcsRejectReasonCode has the value: 'unable to perform command request', this object contains the corresponding reason code explanation." ::= { t11FcsNotifyControlEntry 7 } t11FcsRejectReasonVendorCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 39] RFC 4935 Fabric Configuration Server MIB August 2007 "A registration reject vendor-specific code. This object contains the vendor-specific code of the most recently rejected Fabric Configuration Server Registration request for the particular port on the particular Fabric." ::= { t11FcsNotifyControlEntry 8 } -- -- Notifications -- t11FcsRqRejectNotification NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11FcsRejectReasonCode, t11FcsRejectReasonCodeExp, t11FcsRejectReasonVendorCode } STATUS current DESCRIPTION "This notification is generated whenever the Fabric Configuration Server on a switch (indicated by the value of t11FamLocalSwitchWwn) rejects a Fabric Configuration Server request. The Fabric Configuration Server should update the t11FcsRejectReasonCode, t11FcsRejectReasonCodeExp and t11FcsRejectReasonVendorCode objects with the corresponding reason code, explanation and vendor specific code before sending the notification." ::= { t11FcsNotifications 1 } t11FcsDiscoveryCompleteNotify NOTIFICATION-TYPE OBJECTS {t11FcsFabricDiscoveryRangeLow} STATUS current DESCRIPTION "This notification is generated by the Fabric Configuration Server on the completion of the discovery of Fabrics in the range that has t11FcsFabricDiscoveryRangeLow at its low end." ::= { t11FcsNotifications 2 } t11FcsMgmtAddrChangeNotify NOTIFICATION-TYPE OBJECTS { t11FcsMgmtAddrChangeFabricIndex, t11FcsMgmtAddrChangeIeName } STATUS current DESCRIPTION "This notification is generated by the Fabric Configuration Server whenever the management address of an IE changes, i.e., whenever an entry in the t11FcsMgmtAddrListTable changes." DeSanti, et al. Standards Track [Page 40] RFC 4935 Fabric Configuration Server MIB August 2007 ::= { t11FcsNotifications 3 } t11FcsMgmtAddrChangeFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The index value that identifies the Fabric on which a management address change has been detected." ::= { t11FcsNotificationInfo 2 } t11FcsMgmtAddrChangeIeName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The IE for which a management address change has been detected." ::= { t11FcsNotificationInfo 3 } -- Conformance t11FcsMIBCompliances OBJECT IDENTIFIER ::= { t11FcsMIBConformance 1 } t11FcsMIBGroups OBJECT IDENTIFIER ::= { t11FcsMIBConformance 2 } t11FcsMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the Fabric Configuration Server." MODULE MANDATORY-GROUPS { t11FcsDiscoveredConfigGroup, t11FcsDiscoveryStatusGroup, t11FcsNotificationInfoGroup, t11FcsNotificationGroup } GROUP t11FcsDiscoveryControlGroup DESCRIPTION "This group is mandatory only for those systems that allow discovery of configuration by Fabric Configuration Servers to be controlled via a MIB." GROUP t11FcsStatisticsGroup DESCRIPTION "These counters, containing Fabric Configuration Server statistics, are mandatory only for those systems that count such events." DeSanti, et al. Standards Track [Page 41] RFC 4935 Fabric Configuration Server MIB August 2007 OBJECT t11FcsDiscoveryStatus WRITE-SYNTAX INTEGER { localOnly(3) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. However, if write access is supported, then the only writable value is 'localOnly'." OBJECT t11FcsReqRejectNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcsDiscoveryCompNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcsMgmtAddrChangeNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FcsMIBCompliances 1 } -- Units of Conformance t11FcsDiscoveryControlGroup OBJECT-GROUP OBJECTS { t11FcsFabricDiscoveryRangeLow, t11FcsFabricDiscoveryRangeHigh, t11FcsFabricDiscoveryStart, t11FcsFabricDiscoveryTimeOut } STATUS current DESCRIPTION "A collection of objects for requesting a Fabric Configuration Server to discover the configuration of one or more Fabrics." ::= { t11FcsMIBGroups 1 } t11FcsDiscoveryStatusGroup OBJECT-GROUP OBJECTS { t11FcsDiscoveryStatus, t11FcsDiscoveryCompleteTime } STATUS current DESCRIPTION "A collection of objects with which to monitor the status of discovery (of Fabric configurations) by Fabric Configuration Servers." DeSanti, et al. Standards Track [Page 42] RFC 4935 Fabric Configuration Server MIB August 2007 ::= { t11FcsMIBGroups 2 } t11FcsDiscoveredConfigGroup OBJECT-GROUP OBJECTS { t11FcsIeType, t11FcsIeDomainId, t11FcsIeMgmtId, t11FcsIeFabricName, t11FcsIeLogicalName, t11FcsIeMgmtAddrListIndex, t11FcsIeInfoList, t11FcsMgmtAddr, t11FcsPortType, t11FcsPortTxType, t11FcsPortModuleType, t11FcsPortPhyPortNum, t11FcsPortAttachPortNameIndex, t11FcsPortState, t11FcsPortSpeedCapab, t11FcsPortOperSpeed, t11FcsPortZoningEnfStatus, t11FcsAttachPortName, t11FcsPlatformName, t11FcsPlatformType, t11FcsPlatformNodeNameListIndex, t11FcsPlatformMgmtAddrListIndex, t11FcsPlatformVendorId, t11FcsPlatformProductId, t11FcsPlatformProductRevLevel, t11FcsPlatformDescription, t11FcsPlatformLabel, t11FcsPlatformLocation, t11FcsPlatformSystemID, t11FcsPlatformSysMgmtAddr, t11FcsPlatformClusterId, t11FcsPlatformClusterMgmtAddr, t11FcsPlatformFC4Types, t11FcsNodeName } STATUS current DESCRIPTION "A collection of objects to contain the Fabric configuration information discovered by Fabric Configuration Servers." ::= { t11FcsMIBGroups 3 } t11FcsStatisticsGroup OBJECT-GROUP OBJECTS { t11FcsInGetReqs, t11FcsOutGetReqs, t11FcsInRegReqs, DeSanti, et al. Standards Track [Page 43] RFC 4935 Fabric Configuration Server MIB August 2007 t11FcsOutRegReqs, t11FcsInDeregReqs, t11FcsOutDeregReqs, t11FcsRejects } STATUS current DESCRIPTION "A collection of objects for Fabric Configuration Server statistics information." ::= { t11FcsMIBGroups 4 } t11FcsNotificationInfoGroup OBJECT-GROUP OBJECTS { t11FcsReqRejectNotifyEnable, t11FcsDiscoveryCompNotifyEnable, t11FcsMgmtAddrChangeNotifyEnable, t11FcsRejectCtCommandString, t11FcsRejectRequestSource, t11FcsRejectReasonCode, t11FcsRejectReasonCodeExp, t11FcsRejectReasonVendorCode, t11FcsMgmtAddrChangeFabricIndex, t11FcsMgmtAddrChangeIeName } STATUS current DESCRIPTION "A collection of notification control and notification information objects for monitoring Fabric Configuration Servers." ::= { t11FcsMIBGroups 5 } t11FcsNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FcsRqRejectNotification, t11FcsDiscoveryCompleteNotify, t11FcsMgmtAddrChangeNotify } STATUS current DESCRIPTION "A collection of notifications for monitoring Fabric Configuration Servers." ::= { t11FcsMIBGroups 6 } END DeSanti, et al. Standards Track [Page 44] RFC 4935 Fabric Configuration Server MIB August 2007 7. IANA Considerations IANA has assigned a MIB OID (162) under the mib-2 subtree. 8. Security Considerations There are several management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability is: t11FcsFabricDiscoveryRangeLow t11FcsFabricDiscoveryRangeHigh t11FcsFabricDiscoveryTimeOut t11FcsFabricDiscoveryStart -- the ability to specify parameters for, and trigger the start of, a topology discovery. t11FcsDiscoveryStatus -- the ability to abort a discovery, or invalidate discovered information. t11FcsReqRejectNotifyEnable t11FcsDiscoveryCompNotifyEnable t11FcsMgmtAddrChangeNotifyEnable -- the ability to enable/disable notifications. Such objects may be considered sensitive or vulnerable in some network environments. For example, the ability to invalidate discovered topology may afford an attacker the ability to hide the presence of unauthorized equipment on the network. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: t11FcsIeTable t11FcsMgmtAddrListTable t11FcsPortTable t11FcsAttachPortNameListTable t11FcsPlatformTable DeSanti, et al. Standards Track [Page 45] RFC 4935 Fabric Configuration Server MIB August 2007 t11FcsNodeNameListTable -- contains information about the topology of the Fibre Channel network. t11FcsStatsTable -- contains statistics information about the operation of the Fabric Configuration Server. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Acknowledgements This document was originally developed and approved by the INCITS Task Group T11.5 (http://www.t11.org) as the SM-FCFGM project. We wish to acknowledge the many contributions and comments from the INCITS Technical Committee T11, especially from the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 Vice Chair: Scott Kipp, McData and T11.5 members. The document was subsequently a work item of the IETF's IMSS Working Group, chaired by David Black (EMC Corporation). We thank Bert Wijnen (Lucent Technologies) for his thorough review of the document. We also wish to acknowledge Dan Romascanu (Avaya), the IETF Area Director, for his comments and assistance. DeSanti, et al. Standards Track [Page 46] RFC 4935 Fabric Configuration Server MIB August 2007 10. Normative References [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2788] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC 2788, March 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 58, RFC 3411, December 2002. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)" ANSI INCITS 373-2003, http://www.t11.org/t11/stat.nsf/upnum/1331-d, April 2003. [FC-GS-5] "Fibre Channel - Generic Services - 5 (FC-GS-5)", ANSI INCITS 427-2007, http://www.t11.org/t11/stat.nsf/upnum/1677-d, 2007. [FC-SW-4] "Fibre Channel - Switch Fabric - 4 (FC-SW-4)", ANSI INCITS 418-2006, http://www.t11.org/t11/stat.nsf/upnum/1674-d, December 2006. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC4438] DeSanti, C., Gaonkar, V., Vivek, H.K., McCloghrie, K., and S. Gai, "Fibre Channel Name Server MIB", RFC 4438, March 2006. [RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, March 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. DeSanti, et al. Standards Track [Page 47] RFC 4935 Fabric Configuration Server MIB August 2007 11. Informative References [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4455] Hallak-Stamler, M., Bakke, M., Lederman, Y., Krueger, M., and K. McCloghrie, "Definition of Managed Objects for Small Computer System Interface (SCSI) Entities", RFC 4455, April 2006. DeSanti, et al. Standards Track [Page 48] RFC 4935 Fabric Configuration Server MIB August 2007 Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com H.K. Vivek Cisco Systems, Inc. 71 Millers Rd Bangalore, India Phone: +91 80 2289933x5117 EMail: hvivek@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 526-5260 EMail: kzm@cisco.com Silvano Gai Nuova Systems 3 West Plumeria Drive San Jose, CA 95134 Phone: +1 408 387-6123 EMail: sgai@nuovasystems.com DeSanti, et al. Standards Track [Page 49] RFC 4935 Fabric Configuration Server MIB August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. DeSanti, et al. Standards Track [Page 50] snmp-mibs-downloader-1.1/mibrfcs/rfc4936.txt0000644000000000000000000051546111402176072015604 0ustar Network Working Group C. DeSanti Request for Comments: 4936 H.K. Vivek Category: Standards Track K. McCloghrie Cisco Systems S. Gai Nuova Systems August 2007 Fibre Channel Zone Server MIB 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. DeSanti, et al. Standards Track [Page 1] RFC 4936 FC Zone Server MIB August 2007 Table of Contents 1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Overview of Fibre Channel .......................................3 3.1. General Overview ...........................................3 3.2. Zoning .....................................................4 3.3. Zoning Configuration and Management ........................5 4. Relationship to Other MIBs ......................................7 5. MIB Overview ....................................................8 5.1. Fibre Channel Management Instance ..........................8 5.2. Switch Index ...............................................8 5.3. Fabric Index ...............................................8 5.4. Locking the Fabric .........................................9 5.5. Basic and Enhanced Modes ..................................10 5.6. Persistent Storage ........................................10 5.7. The Active Zone Set and the Zone Set Database .............11 5.8. Conformance Groups ........................................12 6. The T11-FC-FABRIC-LOCK-MIB Module ..............................13 7. The T11-FC-ZONE-SERVER-MIB Module ..............................24 8. IANA Considerations ............................................79 9. Security Considerations ........................................79 10. Acknowledgements ..............................................80 11. Normative References ..........................................81 12. Informative References ........................................82 DeSanti, et al. Standards Track [Page 2] RFC 4936 FC Zone Server MIB August 2007 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Zone Server. This memo was previously approved by INternational Committee for Information Technology Standards (INCITS) Task Group T11.5 (http://www.t11.org); this document is a product of the IETF's IMSS working group. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview of Fibre Channel 3.1. General Overview The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are DeSanti, et al. Standards Track [Page 3] RFC 4936 FC Zone Server MIB August 2007 switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the Fabric, each node, and most ports, have globally unique names. These globally unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. For an Nx_Port, its WWN is called a N_Port_Name and its address identifier is called an N_Port_ID. When a Fabric is in use, the FC address identifiers are dynamic and are assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy. 3.2. Zoning Zones within a Fabric provide a mechanism to control frame delivery between Nx_Ports ("Hard Zoning") or to expose selected views of Name Server information ("Soft Zoning"). Communication is only possible when the communicating endpoints are members of a common zone. This technique is similar to virtual private networks in that the Fabric has the ability to group devices into Zones. Hard zoning and soft zoning are two different means of realizing this. Hard zoning is enforced in the Fabric (i.e., switches) whereas soft zoning is enforced at the endpoints (e.g., host bus adapters (HBAs)) by relying on the endpoints to not send traffic to an N_Port_ID not obtained from the Name Server with a few exceptions for well-known N_Port_IDs used to bootstrap the Fabric (e.g., talk to the Name Server). Administrators create Zones to increase network security and to prevent data loss or corruption by controlling access between devices or user groups. Zones may be specifically used to create: DeSanti, et al. Standards Track [Page 4] RFC 4936 FC Zone Server MIB August 2007 a) Barriers between devices that use different operating systems. It is often critical to separate servers and storage devices with different operating systems because accidental transfer of information from one to another may delete or corrupt data; b) Logical subsets of closed user groups. Administrators may authorize access rights to specific Zones for specific user groups, thereby protecting confidential data from unauthorized access; c) Groups of devices that are separate from devices in the rest of a Fabric. Zones allow certain processes to be performed on devices in a group without interrupting devices in other groups; or d) Temporary access between devices for specific purposes. Administrators may remove Zone restrictions temporarily, then restore Zone restrictions to perform normal processes. 3.3. Zoning Configuration and Management Zones are configured via a Fabric Zone Server, using requests defined in [FC-GS-5]), or via the T11-FC-ZONE-SERVER-MIB module defined in this memo, or via some other mechanism. An Nx_Port may be a member of one or more Zones. Zone membership may be specified by: a) The N_Port_Name of the Nx_Port connected to the switch; b) The N_Port_ID assigned during Fabric Login; c) The Node_Name associated with the Nx_Port; note that the Node_Name may include more than one Nx_Port; d) The F_Port_Name of the Fx_Port to which the Nx_Port is connected; or e) The domain identifier (Domain_ID) and physical port number of the Switch Port to which the Nx_Port is attached. A Fabric's Zone Server may be used to create a Zone by specifying the Zone Members. One or more Zones may be collected into a Zone Set, and a Zone may be a member of more than one Zone Set. A Zone Set creates a collection of Zones that may be activated or deactivated as a single entity across all Switches in a Fabric (e.g., having two Zone Sets, one for normal operation, and a second for backup during off-hours). Only one Zone Set may be activated at one time. Other terminology defined in [FC-GS-5] is: an Active Zone Set is the Zone Set currently enforced by a Fabric; a Zone Set Database is a database of the Zone Sets available to be activated within a Fabric; DeSanti, et al. Standards Track [Page 5] RFC 4936 FC Zone Server MIB August 2007 and a Zoning Database is a generic term used to indicate a combination of an Active Zone Set and a Zone Set Database. Two distinct sets of management requests, Enhanced and Basic, are defined in [FC-GS-5] to interact with a Fabric Zone Server. Basic Zoning provides compatibility with [FC-GS-4] and earlier versions of Fibre Channel's Generic Services specification. If all the Switches in a Fabric support the Enhanced request set, then it may be used to manage zoning; otherwise, only the Basic request set may be used, in order to support backward compatibility. In the context of Enhanced Zoning Management, a management action (i.e., write access to the Zoning Database) to the Zone Server can only occur inside a server session. A server session is set up using the FC-GS-5's Common Transport (CT) protocol defined in [FC-GS-5]. A server session is delimited by CT protocol requests, Server Session Begin (SSB) and Server Session End (SSE), which are directed to the Management Service and which have the GS_Subtype specifying the Zone Server. Query requests that result in read access to the Zoning Database are not required to be issued inside a server session, although the information returned is not guaranteed to be consistent when supplied outside of a server session. When setting up a server session for Enhanced Zoning, the Zone Server is required to lock the Fabric. This ensures serialized management access to the Zoning Database and guarantees a deterministic behavior. The switch that receives the SSB request is called the 'managing' switch, and it tries to lock the Fabric using the Fabric Management Session Protocol (see section 10.6 of [FC-SW-4]) by sending an Acquire Change Authorization (ACA) request to all other switches in the Fabric. If any switch(es) respond with an SW_RJT indicating failure, then the attempt to lock the Fabric fails and the SSB request is rejected. If all the other switches respond with an SW_ACC indicating success, then the Fabric is locked and the server session can be established. The subsequent SSE request causes a Release Change Authorization (RCA) request to all other switches, and thus, the Fabric to be unlocked. For at least one application other than Zoning, the managing switch uses a different type of request to lock the Fabric, i.e., it sends an Enhanced Acquire Change Authorization (EACA) request to all other switches in the Fabric. An EACA reserves local resources associated with a designated application to ensure the consistency of that application's data. The application is identified in the EACA using an Application_ID (see Table 116 in [FC-SW-4]). A lock that was established via an EACA is released using an Enhanced Release Change Authorization (ERCA) request. DeSanti, et al. Standards Track [Page 6] RFC 4936 FC Zone Server MIB August 2007 Changes requested in a Zoning Database by Enhanced Zoning commands persist after the end of the Zoning (server) session only if the commands are followed, within the same server session, by a Commit Zone Changes (CMIT) request. On receipt of a CMIT request, the Zone Server checks that the Zoning Database as modified by the outstanding changes will pass the applicable consistency checks, and then distributes it to all other switches in the Fabric using a Stage Fabric Configuration Update (SFC) request. If all other switches accept the SFC request, then the "managing" switch sends an Update Fabric Configuration (UFC) Request to each other switch, and the staged Zoning Database thereby becomes the Fabric's (active) Zoning Database. The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4]. [FC-SW-4] carries forward the earlier specification for the operation of a single Fabric in a physical infrastructure, and augments it with the definition of Virtual Fabrics and with the specification of how multiple Virtual Fabrics can operate within one (or more) physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core switch. 4. Relationship to Other MIBs The Fibre Channel Management MIB [RFC4044] defines basic information for Fibre Channel hosts and switches, including extensions to the standard IF-MIB [RFC2863] for Fibre Channel interfaces. This MIB extends beyond [RFC4044] to cover the management of Fibre Channel Zoning Servers, both for Basic Zoning Management and for Enhanced Zoning Management, as defined in the FC-GS-5 specification. This MIB imports some common Textual Conventions from T11-TC-MIB, defined in [RFC4439]. It also imports a TC from T11-FC-NAME-SERVER- MIB, defined in [RFC4438], plus InetAddressType and InetAddress from INET-ADDRESS-MIB [RFC4001]. It also includes a reference to snmpCommunitySecurityName defined in [RFC3584]. DeSanti, et al. Standards Track [Page 7] RFC 4936 FC Zone Server MIB August 2007 5. MIB Overview This document defines two MIB modules: T11-FC-FABRIC-LOCK-MIB and T11-FC-ZONE-SERVER-MIB. T11-FC-FABRIC-LOCK-MIB supports FC-GS-5's generic capability of locking the Fabric for a particular "application" such as (the management of) Enhanced Zoning. The MIB contains one table in which each entry represents a particular switch being the 'managing' switch of a particular application's Fabric lock. T11-FC-ZONE-SERVER-MIB is specific to the operation of Zone Servers, which can operate in Basic mode or in Enhanced mode. This MIB module imports the T11NsGs4RejectReasonCode textual convention defined in T11-FC-NAME-SERVER-MIB [RFC4438]. 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [RFC4044] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [RFC4044] as the index value to uniquely identify each Fibre Channel management instance, for example, within the same SNMP context ([RFC3411], section 3.3.1). 5.2. Switch Index The FC-MGMT-MIB [RFC4044] defines the fcmSwitchTable as a table of information about Fibre Channel switches that are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value to uniquely identify a Fibre Channel switch amongst those (one or more) managed by the same Fibre Channel management instance. 5.3. Fabric Index Whether operating on a physical Fabric (i.e., without Virtual Fabrics) or within a Virtual Fabric, the operation of a Zone Server within a Fabric is identical. Therefore, this MIB defines all Fabric-related information in tables that are INDEXed by an arbitrary DeSanti, et al. Standards Track [Page 8] RFC 4936 FC Zone Server MIB August 2007 integer, named a "Fabric Index", having the syntax, T11FabricIndex, which is IMPORTed from the T11-TC-MIB [RFC4439]. When a device is connected to a single physical Fabric, without use of any Virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple virtual and/or physical Fabrics, this index provides a means to distinguish one Fabric from another. It is quite possible, and may even be likely, that a Fibre Channel switch will have ports connected to multiple virtual and/or physical Fabrics. Thus, in order to simplify a management protocol query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before an object with FabricIndex as its syntax when both appear in the same INDEX clause. 5.4. Locking the Fabric The T11-FC-FABRIC-LOCK-MIB module provides for the management of locks on a Fibre Channel Fabric. A Fibre Channel Fabric lock is used to ensure serialized access to some types of management data related to a Fabric, e.g., the Fabric's Zoning Database. Some (managing) applications obtain a lock by initiating server sessions and the Fabric is locked so as to reserve local resources in each Switch. For this usage, the managing switch sends an Acquire Change Authorization (ACA) request to other switches in order to lock the Fabric. For some other applications, a managing switch locks the Fabric using an Enhanced Acquire Change Authorization (EACA) request, which identifies the application on whose behalf the Fabric is being locked with an Application_ID. In this case, only local resources associated with the designated application are reserved. Locks established via ACAs and via EACAs are both represented in the t11FLockTable in the T11-FC-FABRIC-LOCK-MIB. The Application_ID provided by the EACA serves to distinguish between multiple concurrent locks established by EACAs. In order to use this same mechanism to distinguish a lock established via an ACA from each of those established via EACAs, an additional (special) value of Application_ID has been assigned [APPL-ID] for use by this MIB module. Specifically, this newly assigned value will never be used to indicate an Application locked by an EACA, and therefore this MIB module uses it to uniquely distinguish a lock established via an ACA. In other words, with this additional assignment, an Application_ID value can be used to uniquely identify any active lock amongst all those established (on the same Fabric) either by an EACA or an ACA. DeSanti, et al. Standards Track [Page 9] RFC 4936 FC Zone Server MIB August 2007 5.5. Basic and Enhanced Modes The t11ZsServerOperationMode object indicates whether a Fabric's Zone Server is operating in Basic mode or Enhanced mode. These two modes have a sufficient amount of commonality to make it worthwhile to have one set of MIB objects that are used for the subset of functionality that is common to both modes. To accommodate the differences, additional MIB objects are defined. For Enhanced mode, the additional objects are defined in a group, t11ZsEnhancedModeGroup, which is only required to be implemented in a Zone Server capable of supporting Enhanced mode. The objects specific to Basic mode are always (even in Enhanced mode) expected to be implemented, but when in Enhanced mode, their values are either restricted or do not affect current operations, e.g., - an example of "restricted" is: the distribution of updates to the Zone Server database throughout the Fabric has to be requested explicitly in Basic mode; this functionality is provided in the MIB by the t11ZsServerDistribute object. In contrast, in Enhanced mode, the distribution is an implicit part of the commit function which is initiated using the t11ZsServerCommit object. Thus, when operating in Enhanced mode, t11ZsServerDistribute has a fixed value, and when operating in Basic mode, t11ZsServerCommit has a fixed value. - an example of "do not affect current operations" is: t11ZsServerHardZoning, which specifies whether a switch enforces hard Zoning on a Fabric when in Basic mode. This object is instantiated and could even be modified while in Enhanced mode, but its value only takes effect when in Basic mode. (Note that in Enhanced mode, t11ZsActiveZoneHardZoning specifies whether hard Zoning is enabled on a particular Zone.) 5.6. Persistent Storage A Zone Server Database for a given Fabric consists of the combination of many of the tables defined in this MIB module. In order to ensure that such a Database is consistent, this MIB module defines just one object (t11ZsServerDatabaseStorageType) with a syntax of StorageType, whose value for a given Fabric is defined to be applicable to all of that Fabric's Zone Server Database as defined in all the tables in this MIB module. DeSanti, et al. Standards Track [Page 10] RFC 4936 FC Zone Server MIB August 2007 5.7. The Active Zone Set and the Zone Set Database As described in FC-GS-5 [FC-GS-5], one of the Zone Sets in the Zone Set Database can be activated to become the Active Zone Set, i.e., the one which is enforced on the Fabric. Get/Add/Remove-type requests are defined in FC-GS-5 to allow access to the Zone Set Database. When the Zone Set Database is modified, such modifications don't affect the Active Zone Set unless and until a subsequent activation. Interaction directly with the Active Zone Set is also possible via the FC-GS-5 requests: 'Activate Direct' and 'Get Active Zone Set'. This is illustrated in the following rendition of Figure 15 of [FC-GS-5]: Zone Set Database +------------------+ | +--------------+ | Get | | Zone Set A | | <=========| |(zones, zone | | | | members,etc.)| | | +--------------+ | Add/ | | Zone Set B | | Activate +------------+ Remove | +------------+ | Zone Set | | =========>| |Zone Set C| |================>| | | +----------+ | | Active | +------------------+ | Zone | | Set | Get Active Zone Set | (enforced) | <==============================================| | | | Activate Direct | | ==============================================>| | | | Deactivate | | ==============================================>| | +------------+ The T11-FC-ZONE-SERVER-MIB module, defined in section 7, models the above structure by having one set of MIB tables for the Zone Set Database and a separate set for the Active Zone Set, specifically: - seven tables for the Zone Set Database: t11ZsSetTable, t11ZsZoneTable, t11ZsSetZoneTable, t11ZsAliasTable, t11ZsZoneMemberTable, t11ZsAttribBlockTable and t11ZsAttribTable. - four tables for the Active Zone Set: t11ZsActiveTable, t11ZsActiveZoneTable, t11ZsActiveZoneMemberTable and t11ZsActiveAttribTable. DeSanti, et al. Standards Track [Page 11] RFC 4936 FC Zone Server MIB August 2007 5.8. Conformance Groups 5.8.1. The t11ZsBasicGroup This group contains objects to retrieve and to modify the Zoning configuration of a Zone Server capable of operating in Basic mode. 5.8.2. The t11ZsEnhancedModeGroup This group contains objects to retrieve and to modify the Zoning configuration of a Zone Server capable of operating in Enhanced mode. 5.8.3. The t11ZsActivateGroup This group contains objects that allow a Zone Set to be activated via SNMP SetRequests and provide the status and result of such an activation. 5.8.4. The t11ZsStatisticsGroup This group contains objects for collecting Zone Server statistics. 5.8.5. The t11ZsNotificationGroup This group contains notifications for monitoring: Zone merge successes and failures, Zone Server request rejections, changes in the Default Zoning behavior, and the success or failure of an attempt to activate or deactivate a Zone Set. 5.8.5.1. Flow-Control for Notifications When defining SNMP notifications for events that occur in the data- plane, the maximum frequency of their generation needs to be considered. Unless there is some limiting factor, such notifications need to be flow-controlled in some way, e.g., defined such that after some maximum number have occurred within a specified time interval, further notifications are suppressed for some subsequent time interval. However, as and when such a suppression occurs, the Network Management System (NMS) that didn't receive the notifications (because they were suppressed) needs an indication of how many were suppressed. Therefore, an additional Counter32 object needs to be defined, and/or a new type of notification needs to be defined for use at the end of the interval. While this is extra complexity, it is necessary for notifications that need to be flow-controlled. In contrast, for notifications such as all those defined in this MIB module, which are generated due to control-plane events (and are not able to start a chain reaction): DeSanti, et al. Standards Track [Page 12] RFC 4936 FC Zone Server MIB August 2007 - estimating the maximum number that could be generated per unit time for each type of notification is too simplistic. For example, it's unreasonable to ask how many of the t11ZsDefZoneChangeNotify notifications can be generated in a time interval because it depends on several factors: how many operators can be re- configuring the network at the same time? and how frequently can each of them change the Default Zone Setting? - the extra complexity of flow-controlling these types of notifications is not warranted. 5.8.6. The t11ZsNotificationControlGroup This group contains objects that allow each type of notification (in the t11ZsNotificationGroup group) to be independently enabled or disabled. It also contains objects that are used to include useful information in those notifications; these objects are defined as read-only to allow the values contained in the most recent notification to be queried. 6. The T11-FC-FABRIC-LOCK-MIB Module T11-FC-FABRIC-LOCK-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI -- [RFC2578] RowStatus FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] fcmInstanceIndex, fcmSwitchIndex FROM FC-MGMT-MIB -- [RFC4044] T11NsGs4RejectReasonCode FROM T11-FC-NAME-SERVER-MIB -- [RFC4438] T11FabricIndex FROM T11-TC-MIB; -- [RFC4439] t11FabricLockMIB MODULE-IDENTITY LAST-UPDATED "200706270000Z" ORGANIZATION "For the initial versions, T11. For later versions, the IETF's IMSS Working Group." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie DeSanti, et al. Standards Track [Page 13] RFC 4936 FC Zone Server MIB August 2007 Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kzm@cisco.com" DESCRIPTION "The MIB module for the management of locks on a Fibre Channel Fabric. A Fibre Channel Fabric lock is used to ensure serialized access to some types of management data related to a Fabric, e.g., the Fabric's Zoning Database. Some (managing) applications generate Fabric locks by initiating server sessions. Server sessions are defined generically in FC-GS-5 to represent a collection of one or more requests to the session's server, e.g., to the Zone Server. Such a session is started by a Server Session Begin (SSB) request, and terminated by a Server Session End (SSE) request. The switch receiving the SSB is called the 'managing' switch. Some applications require the 'managing' switch to lock the Fabric for the particular application, e.g., for Enhanced Zoning, before it can respond successfully to the SSB. On receipt of the subsequent SSE, the lock is released. For this usage, the managing switch sends an Acquire Change Authorization (ACA) request to other switches to lock the Fabric. For some other applications, a managing switch locks the Fabric using an Enhanced Acquire Change Authorization (EACA) request, which identifies the application on whose behalf the Fabric is being locked with an Application_ID. Fabric locks can also be requested more directly, e.g., through the use of this MIB. In these situations, the term 'managing' switch is used to indicate the switch that receives such a request and executes it by issuing either ACA or EACA requests to other switches in the Fabric. This MIB module defines information about the 'managing' switch for currently-active Fabric locks. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4936; see the RFC itself for full legal notices." REVISION "200706270000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4936." ::= { mib-2 159 } DeSanti, et al. Standards Track [Page 14] RFC 4936 FC Zone Server MIB August 2007 t11FLockMIBObjects OBJECT IDENTIFIER ::= { t11FabricLockMIB 1 } t11FLockMIBConformance OBJECT IDENTIFIER ::= { t11FabricLockMIB 2 } t11FLockMIBNotifications OBJECT IDENTIFIER ::= { t11FabricLockMIB 0 } t11FLockConfiguration OBJECT IDENTIFIER ::= { t11FLockMIBObjects 1 } -- -- The table of Managing Switches and their Fabric Locks -- t11FLockTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FLockEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about the 'managing' switch of each current Fabric lock, e.g., for the types of Servers defined in FC-GS-5. Each entry in this table represents either: 1) a current Fabric lock, 2) an in-progress attempt, requested via SNMP, to set up a lock, or 3) a failed attempt, requested via SNMP, to set up a lock. If an entry is created via t11FLockRowStatus, but the attempt to obtain the lock fails, then the entry continues to exist until it is deleted via t11FLockRowStatus, or it is overwritten by the lock being established via a means other than SNMP. However, rows created via t11FLockRowStatus are not retained over restarts." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, sections 4.9.5 and 6.4.10.2." ::= { t11FLockConfiguration 1 } t11FLockEntry OBJECT-TYPE SYNTAX T11FLockEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information specific to a current Fabric lock set up by a particular 'managing' switch on a particular Fabric. The 'managing switch' is identified by values of fcmInstanceIndex and fcmSwitchIndex. Server sessions for several different types of servers are defined in FC-GS-5. The behavior of a server with DeSanti, et al. Standards Track [Page 15] RFC 4936 FC Zone Server MIB August 2007 respect to commands received within a server session is specified for each type of server. For some types, parameter changes can only be made within the context of a session, and the setting up of a session requires that the Fabric be locked. A Fabric is locked by one switch, called the 'managing' switch, sending Acquire Change Authorization (ACA) requests to all other switches in the Fabric. For other applications, a Fabric lock is established by the 'managing' switch sending Enhanced Acquire Change Authorization (EACA) requests to other switches in the Fabric. Each EACA request includes an Application_ID value to identify the application requesting the lock. For the benefit of this MIB module, a distinct value of Application_ID has also been assigned/reserved (see ANSI INCITS T11/06-679v0, titled 'FC-SW-5 Letter to T11.5') as a means of distinguishing locks established via Acquire Change Authorization (ACA) requests. This additional assignment allows an Application_ID to be used to uniquely identify any active lock amongst all those established by either an EACA or an ACA. Whenever a Fabric is locked, by the sending of either an ACA or an EACA, a row gets created in the representation of this table for the 'managing' switch. In order to process SNMP SetRequests that make parameter changes for the relevant types of servers (e.g., to the Zoning Database), the SNMP agent must get serialized access to the Fabric (for the relevant type of management data), i.e., the Fabric must be locked by creating an entry in this table via an SNMP SetRequest. Creating an entry in this table via an SNMP SetRequest causes an ACA or an EACA to be sent to all other switches in the Fabric. The value of t11FLockApplicationID for such an entry determines whether an ACA or an EACA is sent. If an entry in this table is created by an SNMP SetRequest, the value of the t11FLockInitiatorType object in that entry will normally be 'snmp'. A row for which the value of t11FLockInitiatorType is not 'snmp' cannot be modified via SNMP. In particular, it cannot be deleted via t11FLockRowStatus. Note that it's possible for a row to be created by an SNMP SetRequest, but for the setup of the lock to fail, and immediately thereafter be replaced by a lock successfully set up by some other means; in such a case, the value of t11FLockInitiatorType would change as and when the DeSanti, et al. Standards Track [Page 16] RFC 4936 FC Zone Server MIB August 2007 lock was set up by the other means, and so the row could not thereafter be deleted via t11FLockRowStatus. FC-GS-5 mentions various error situations in which a Fabric lock is released so as to avoid a deadlock. In such situations, the agent removes the corresponding row in this table as and when the lock is released. This can happen for all values of t11FLockInitiatorType." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, sections 4.9.5.5 and 6.4.7.1. Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, sections 6.1.17, 10.6.6, and 13.2, and table 116. 'FC-SW-5 Letter to T11.5' ANSI INCITS T11/06-679v0, http://www.t11.org/ftp/t11/pub/fc/sw-5/06-679v0.pdf, 21 September 2006." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FLockFabricIndex, t11FLockApplicationID } ::= { t11FLockTable 1 } T11FLockEntry ::= SEQUENCE { t11FLockFabricIndex T11FabricIndex, t11FLockApplicationID OCTET STRING, t11FLockInitiatorType INTEGER, t11FLockInitiator OCTET STRING, t11FLockInitiatorIpAddrType InetAddressType, t11FLockInitiatorIpAddr InetAddress, t11FLockStatus INTEGER, t11FLockRejectReasonCode T11NsGs4RejectReasonCode, t11FLockRejectReasonCodeExp OCTET STRING, t11FLockRejectReasonVendorCode OCTET STRING, t11FLockRowStatus RowStatus } t11FLockFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric. In a Fabric conformant to FC-SW-4, multiple Virtual Fabrics can operate within one (or more) physical infrastructures, and this index value is used to uniquely identify a DeSanti, et al. Standards Track [Page 17] RFC 4936 FC Zone Server MIB August 2007 particular (physical or virtual) Fabric within a physical infrastructure. In a Fabric conformant to versions earlier than FC-SW-4, only a single Fabric could operate within a physical infrastructure, and thus, the value of this Fabric Index was defined to always be 1." ::= { t11FLockEntry 1 } t11FLockApplicationID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Application_ID value that identifies the type of application for which the Fabric is locked. A lock established via Acquire Change Authorization (ACA) does not, strictly speaking, have an Application_ID value. However, the value 'FF'h (255 decimal) has been reserved by T11 to be used as the value of this MIB object as and when a lock is established by an ACA. This value was initially documented in a letter from the FC-SW-5 Editor to T11.5, which was approved by the T11 and T11.5 plenary meetings on October 5, 2006." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, Table 116. 'FC-SW-5 Letter to T11.5' ANSI INCITS T11/06-679v0, http://www.t11.org/ftp/t11/pub/fc/sw-5/06-679v0.pdf, 21 September 2006." ::= { t11FLockEntry 2 } t11FLockInitiatorType OBJECT-TYPE SYNTAX INTEGER { other(1), ssb(2), cli(3), snmp(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies what type of initiator generated the request that caused this lock to be established: other - none of the following. DeSanti, et al. Standards Track [Page 18] RFC 4936 FC Zone Server MIB August 2007 ssb - this lock was established due to the receipt of an SSB, e.g., from a GS-5 client. cli - this lock was established in order to process a Command Line Interface (CLI) command. snmp - this lock was established as a result of an SNMP SetRequest. " ::= { t11FLockEntry 3 } t11FLockInitiator OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the initiator whose request caused this lock to be established. If the value of the corresponding instance of t11FLockInitiatorType is 'ssb', this object will contain the FC_ID of the client that issued the Server Session Begin (SSB) that required the lock to be established. If the value of the corresponding instance of t11FLockInitiatorType object is 'cli', this object will contain the user name of the CLI (Command Line Interface) user on whose behalf the lock was established. If the value of the corresponding instance of t11FLockInitiatorType is 'snmp', this object will contain the SNMP securityName used by the SNMPv3 message containing the SetRequest that created this row. (If the row was created via SNMPv1 or SNMPv2c, then the appropriate value of the snmpCommunitySecurityName is used.)" REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 4.9.5.2. SNMP securityName is defined in RFC 3411, 'An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks'. snmpCommunitySecurityName is defined in RFC 3584, 'Coexistence between Version 1, Version 2, and DeSanti, et al. Standards Track [Page 19] RFC 4936 FC Zone Server MIB August 2007 Version 3 of the Internet-standard Network Management Framework.'" ::= { t11FLockEntry 4 } t11FLockInitiatorIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the type of IP address contained in the corresponding instance of t11FLockInitiatorIpAddr. If the IP address of the location of the initiator is unknown or not applicable, this object has the value: 'unknown'." ::= { t11FLockEntry 5 } t11FLockInitiatorIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the IP address of the location of the initiator that established this lock via a request of the type given by the corresponding instance of t11FLockInitiatorType. In cases where the corresponding instance of t11FLockInitiatorIpAddrType has the value: 'unknown', the value of this object is the zero-length string." ::= { t11FLockEntry 6 } t11FLockStatus OBJECT-TYPE SYNTAX INTEGER { active(1), settingUp(2), rejectFailure(3), otherFailure(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object gives the current status of the lock: 'active' -- the lock is currently established. 'settingUp' -- the 'managing' switch is currently attempting to set up the lock, e.g., it is waiting to receive Accepts for ACAs from every switch in the Fabric. DeSanti, et al. Standards Track [Page 20] RFC 4936 FC Zone Server MIB August 2007 'rejectFailure' -- the 'managing' switch's attempt to set up the lock was rejected with the reason codes given by: t11FLockRejectReasonCode, t11FLockRejectReasonCodeExp and t11FLockRejectReasonVendorCode. 'otherFailure' -- the 'managing' switch's attempt to set up the lock failed (but no reason codes are available). For values of t11FLockInitiatorType other than 'snmp', a row is only required to be instantiated in this table when the value of this object is 'active'. If the value of the corresponding instance of t11FLockInitiatorType is 'snmp', the initial value of this object when the row is first created is 'settingUp'. As and when the setup succeeds, the value transitions to 'active'. If the setup fails, the value transitions to either 'rejectFailure' or 'otherFailure'. Note that such a failure value is overwritten on the next attempt to obtain the lock, which could be immediately after the failure, e.g., by a GS-5 client. When the value of this object is 'rejectFailure', the rejection's reason codes are given by the corresponding values of t11FLockRejectReasonCode, t11FLockRejectReasonCodeExp and t11FLockRejectReasonVendorCode." ::= { t11FLockEntry 7 } t11FLockRejectReasonCode OBJECT-TYPE SYNTAX T11NsGs4RejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION "When the value of the corresponding instance of t11FLockStatus is 'rejectFailure', this object contains the rejection's reason code." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 4.4.4 and table 10." ::= { t11FLockEntry 8 } t11FLockRejectReasonCodeExp OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 1)) MAX-ACCESS read-only STATUS current DeSanti, et al. Standards Track [Page 21] RFC 4936 FC Zone Server MIB August 2007 DESCRIPTION "When the value of the corresponding instance of t11FLockStatus is 'rejectFailure', this object contains the rejection's reason code explanation." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, sections 4.4.4 and 6.4.9, tables 10 and 252." ::= { t11FLockEntry 9 } t11FLockRejectReasonVendorCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0 | 1)) MAX-ACCESS read-only STATUS current DESCRIPTION "When the value of the corresponding instance of t11FLockStatus is 'rejectFailure', this object contains the rejection's vendor-specific code." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 4.4.4." ::= { t11FLockEntry 10 } t11FLockRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. A row in this table can be modified or deleted via this object only when the row's value of t11FLockInitiatorType is 'snmp'." ::= { t11FLockEntry 11 } -- Conformance t11FLockMIBCompliances OBJECT IDENTIFIER ::= { t11FLockMIBConformance 1 } t11FLockMIBGroups OBJECT IDENTIFIER ::= { t11FLockMIBConformance 2 } t11FLockMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that support Fabric locks in support of GS-5 Server applications." MODULE MANDATORY-GROUPS { t11FLockActiveGroup } DeSanti, et al. Standards Track [Page 22] RFC 4936 FC Zone Server MIB August 2007 OBJECT t11FLockRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FLockMIBCompliances 1 } -- Units of Conformance t11FLockActiveGroup OBJECT-GROUP OBJECTS { t11FLockInitiatorType, t11FLockInitiator, t11FLockInitiatorIpAddrType, t11FLockInitiatorIpAddr, t11FLockStatus, t11FLockRejectReasonCode, t11FLockRejectReasonCodeExp, t11FLockRejectReasonVendorCode, t11FLockRowStatus } STATUS current DESCRIPTION "A collection of objects containing information about current Fabric locks." ::= { t11FLockMIBGroups 1 } END DeSanti, et al. Standards Track [Page 23] RFC 4936 FC Zone Server MIB August 2007 7. The T11-FC-ZONE-SERVER-MIB Module T11-FC-ZONE-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Counter32, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TEXTUAL-CONVENTION, RowStatus, StorageType, TruthValue, TimeStamp FROM SNMPv2-TC -- [RFC2579] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] ifIndex FROM IF-MIB -- [RFC2863] fcmInstanceIndex, fcmSwitchIndex, FcNameIdOrZero, FcDomainIdOrZero FROM FC-MGMT-MIB -- [RFC4044] T11NsGs4RejectReasonCode FROM T11-FC-NAME-SERVER-MIB -- [RFC4438] T11FabricIndex FROM T11-TC-MIB -- [RFC4439] t11FamLocalSwitchWwn FROM T11-FC-FABRIC-ADDR-MGR-MIB; -- [RFC4439] t11ZoneServerMIB MODULE-IDENTITY LAST-UPDATED "200706270000Z" ORGANIZATION "For the initial versions, T11. For later versions, the IETF's IMSS Working Group." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kzm@cisco.com" DESCRIPTION "The MIB module for the management of Fibre Channel Zoning Servers, both for Basic Zoning Management and for Enhanced DeSanti, et al. Standards Track [Page 24] RFC 4936 FC Zone Server MIB August 2007 Zoning Management, as defined in the FC-GS-5 specification. FC-GS-5 defines (in-band) management operations for manipulating the Zone Set Database, some for use in Basic mode (e.g., 'Add Zone Set (AZS)', etc.), and some for use in Enhanced mode (e.g., Create Zone Set (CZS)', etc.). When Enhanced Zoning Management is in use, FC-GS-5 requires that these in-band management operations be rejected unless they are issued within the context of a GS-5 server session. The use of a server session ensures serialized access to the Zoning Database since the Fabric lock for the Zone Server must be obtained as a part of establishing the server session to the Zone Server. Thus, if and when this MIB is used for Enhanced Zoning Management, SNMP SetRequests that request the modification of zoning definitions must be serialized with respect to the GS-5 requests to modify the Zoning Database. This is achieved by requiring that an SNMP management application must first obtain the Fabric lock for the Zone Server before attempting to modify any zoning definitions. The companion T11-FC-FABRIC-LOCK-MIB module is defined as a means of obtaining the Fabric lock for the Zone Server (or any other server). In Enhanced Zoning Management, a Zone Server keeps track of changes requested in the zoning definitions, but does not update its Zone Set Database unless there is (and until there is) a 'commit' operation. To model this behavior, this MIB module assumes that a Zone Server (in Enhanced mode) takes a snapshot of its Zone Set Database as and when the Fabric lock (for the Zone Server application) is obtained; this snapshot is used to create what is herein called the 'copy' database. It is this 'copy' database that is then updated by SNMP SetRequests (while the Fabric is locked). If and when a 'commit' operation is requested (while the Fabric is still locked), the 'copy' database is then used to overwrite the previously committed contents of the Zone Set Database, and the new Zone Set Database is distributed to all other switches in the Fabric. When the lock is released, any changes made that were not 'committed' are discarded. When this MIB is used for Basic Zoning Management, the same set of MIB objects as used for Enhanced mode are used to make changes to the Database of a Zone Server on a particular switch, but the changes take immediate effect at that switch without an explicit commit. The distribution of DeSanti, et al. Standards Track [Page 25] RFC 4936 FC Zone Server MIB August 2007 those changes to Zone Servers on other switches in the Fabric is subsequently requested through the use of a separate set of MIB objects. The management information specified in this MIB module includes the Zoning Database for each of one or more Fibre Channel Fabrics. A Zoning Database is a combination of the Fabric's Zone Set Database and its Active Zone Set. The Active Zone Set is the Zone Set currently enforced by the Fabric; a Zone Set Database is a database of the Zone Sets available to be activated within a Fabric. All the MIB objects representing a Zone Set Database are modifiable at any time (irrespective of the value of any RowStatus object), whereas all objects representing the Active Zone Set are always read-only (except to deactivate it and/or activate a different one). Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4936; see the RFC itself for full legal notices." REVISION "200706270000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4936." ::= { mib-2 160 } t11ZsMIBObjects OBJECT IDENTIFIER ::= { t11ZoneServerMIB 1 } t11ZsMIBConformance OBJECT IDENTIFIER ::= { t11ZoneServerMIB 2 } t11ZsMIBNotifications OBJECT IDENTIFIER ::= { t11ZoneServerMIB 0 } t11ZsConfiguration OBJECT IDENTIFIER ::= { t11ZsMIBObjects 1 } t11ZsStatistics OBJECT IDENTIFIER ::= { t11ZsMIBObjects 2 } -- Textual Conventions T11ZsZoneMemberType ::= TEXTUAL-CONVENTION DISPLAY-HINT "x" STATUS current DESCRIPTION "Represents the addressing mechanism by which a member is identified: 01 - N_Port_Name 02 - Domain_ID and physical port 03 - N_Port_ID 04 - Node_Name 05 - Alias Name 06 - F_Port_Name E0-FF (hex) - Vendor Specific. " DeSanti, et al. Standards Track [Page 26] RFC 4936 FC Zone Server MIB August 2007 REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.8.3.6." SYNTAX Unsigned32 (0..255) T11ZsRejectReasonExplanation ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The reason code explanation when rejecting a Zone Server request: 'other' - e.g., a reason code assigned too recently to be included in this version of this MIB 'noAdditionalExplanation' - there is no additional explanation 'zonesNotSupported' - Zones are not supported 'zoneSetNameUnknown' - Zone Set name is not known 'noZoneSetActive' - no Zone Set is currently active 'zoneNameUnknown' - Zone name is unknown 'zoneStateUnknown' - state of the Zone is not known 'incorrectPayloadLen' - payload length is not correct 'tooLargeZoneSet' - Zone Set is larger than permitted size 'deactivateZoneSetFailed' - deactivation of Zone Set failed 'reqNotSupported' - request is not supported 'capabilityNotSupported' - capability is not supported 'zoneMemberIDTypeNotSupp' - Zone Member Identifier Type is not supported 'invalidZoneSetDefinition' - Zone Set definition is invalid 'enhancedZoningCmdsNotSupported' - Enhanced Zoning commands are not supported 'zoneSetExists' - Zone Set already exists 'zoneExists' - Zone already exists 'aliasExists' - Zone Alias already exists DeSanti, et al. Standards Track [Page 27] RFC 4936 FC Zone Server MIB August 2007 'zoneSetUnknown' - Zone Set unknown 'zoneUnknown' - Zone unknown 'aliasUnknown' - Zone Alias unknown 'zoneAliasTypeUnknown' - unknown Zone attribute type 'unableEnhancedMode' - Fabric unable to work in Enhanced Mode 'basicZoningCmdsNotSupported' - Basic Zoning commands are not supported 'zoneAttribObjectExists' - Zone attribute object already exists 'zoneAttribObjectUnknown' - Zone attribute object unknown 'requestInProcess' - request in process 'cmitInProcess' - CMIT in process 'hardEnforcementFailed' - hard enforcement failed 'unresolvedReferences' - unresolved references in the Zone Set Database 'consistencyChecksFailed' - consistency checks failed." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.9." SYNTAX INTEGER { other(1), noAdditionalExplanation(2), zonesNotSupported(3), zoneSetNameUnknown(4), noZoneSetActive(5), zoneNameUnknown(6), zoneStateUnknown(7), incorrectPayloadLen(8), tooLargeZoneSet(9), deactivateZoneSetFailed(10), reqNotSupported(11), capabilityNotSupported(12), zoneMemberIDTypeNotSupp(13), invalidZoneSetDefinition(14), enhancedZoningCmdsNotSupported(15), zoneSetExists(16), zoneExists(17), aliasExists(18), DeSanti, et al. Standards Track [Page 28] RFC 4936 FC Zone Server MIB August 2007 zoneSetUnknown(19), zoneUnknown(20), aliasUnknown(21), zoneAliasTypeUnknown(22), unableEnhancedMode(23), basicZoningCmdsNotSupported(24), zoneAttribObjectExists(25), zoneAttribObjectUnknown(26), requestInProcess(27), cmitInProcess(28), hardEnforcementFailed(29), unresolvedReferences(30), consistencyChecksFailed(31) } T11ZoningName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This datatype is a refinement of an SnmpAdminString, and is used to represent a name stored in a Fibre Channel Zoning Data Structure. The value begins with an ASCII letter (upper or lower case) followed by zero or more characters from the set: lower case letters, upper case letters, numbers, and the symbols ($-^_). The value does not include fill bytes." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.8.1." SYNTAX OCTET STRING (SIZE (1..64)) -- -- The table of Zone Servers -- t11ZsServerTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about the Zone Servers on each Fabric in one or more switches, and providing the capability to perform operations on their Zone Server databases." ::= { t11ZsConfiguration 1 } DeSanti, et al. Standards Track [Page 29] RFC 4936 FC Zone Server MIB August 2007 t11ZsServerEntry OBJECT-TYPE SYNTAX T11ZsServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information specific to a Zone Server for a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). The persistence across reboots of writable values in a row of this table is given by the instance of t11ZsServerDatabaseStorageType in that row." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex } ::= { t11ZsServerTable 1 } T11ZsServerEntry ::= SEQUENCE { t11ZsServerFabricIndex T11FabricIndex, t11ZsServerCapabilityObject BITS, t11ZsServerDatabaseStorageType StorageType, t11ZsServerDistribute INTEGER, t11ZsServerCommit INTEGER, t11ZsServerResult INTEGER, t11ZsServerReasonCode T11NsGs4RejectReasonCode, t11ZsServerReasonCodeExp OCTET STRING, t11ZsServerReasonVendorCode OCTET STRING, t11ZsServerLastChange TimeStamp, t11ZsServerHardZoning TruthValue, t11ZsServerReadFromDatabase INTEGER, t11ZsServerOperationMode INTEGER, t11ZsServerChangeModeResult INTEGER, t11ZsServerDefaultZoneSetting INTEGER, t11ZsServerMergeControlSetting INTEGER, t11ZsServerDefZoneBroadcast TruthValue } t11ZsServerFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index value that uniquely identifies a particular Fabric." ::= { t11ZsServerEntry 1 } t11ZsServerCapabilityObject OBJECT-TYPE DeSanti, et al. Standards Track [Page 30] RFC 4936 FC Zone Server MIB August 2007 SYNTAX BITS { enhancedMode(0), zoneSetDb(1), activateDirect(2), hardZoning(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmap represents the capability of the switch on this Fabric: 'enhancedMode' - able to support enhanced Zoning mode of operation. 'zoneSetDb' - able to support maintaining of a Zone Set Database. 'activateDirect' - able to support the Activate Direct command. 'hardZoning' - able to support Hard Zoning." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, section 6.1.23.4.4" ::= { t11ZsServerEntry 2 } t11ZsServerDatabaseStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the memory realization, on a particular switch, of the Zone Set database for a particular Fabric. Specifically, each row in the following tables: t11ZsSetTable t11ZsZoneTable t11ZsSetZoneTable t11ZsAliasTable t11ZsZoneMemberTable t11ZsAttribBlockTable t11ZsAttribTable has a StorageType as specified by the instance of this object that is INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and DeSanti, et al. Standards Track [Page 31] RFC 4936 FC Zone Server MIB August 2007 t11ZsServerFabricIndex. The value of this object is also used to indicate the persistence across reboots of writable values in its row of the t11ZsServerTable, as well as the corresponding row in the t11ZsNotifyControlTable. If an instance of this object has the value 'permanent(4)', the Zone Set database for the given Fabric on the given switch is not required to be writeable." DEFVAL { nonVolatile } ::= { t11ZsServerEntry 3 } t11ZsServerDistribute OBJECT-TYPE SYNTAX INTEGER { noop(1), zoneSetDb(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object can be set only in Basic mode. When set to the value 'zoneSetDb', it requests that the Zone Set database of a particular switch for a particular Fabric be distributed to every other switch in that Fabric, e.g., by using Stage Fabric Configuration Update (SFC) and Update Fabric Configuration (UFC) requests. Setting this object to 'noop' has no effect. When read, the value of this object is always 'noop'. When the corresponding instance of t11ZsServerOperationMode has the value 'enhanced', or when the corresponding instance of t11ZsZoneSetResult has the value 'inProgress', it is inconsistent to try to set the value of this object." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, section 6.1.19.1." ::= { t11ZsServerEntry 4 } t11ZsServerCommit OBJECT-TYPE SYNTAX INTEGER { commitZoneChanges(1), noop(2) } MAX-ACCESS read-write STATUS current DeSanti, et al. Standards Track [Page 32] RFC 4936 FC Zone Server MIB August 2007 DESCRIPTION "This object is only used in Enhanced mode. In Enhanced mode, it can only be modified when the Fabric lock for the Zone Server on the particular Fabric has been obtained for use by SNMP SetRequests, and even then, only by the SNMP entity identified by the value of corresponding instance of t11FLockInitiator. Setting the object requests an action: commitZoneChanges - requests that the changes made within this session to the Zone Set Database be committed. noop - requests nothing. When read, the value is always 'noop'." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.10.2." ::= { t11ZsServerEntry 5 } t11ZsServerResult OBJECT-TYPE SYNTAX INTEGER { none(1), inProgress(2), success(3), rejectFailure(4), otherFailure(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "In Basic mode, this object indicates the status/result of the last distribution of the Zone Set database that was invoked via the corresponding instance of t11ZsZoneSetDistribute, e.g., the status/result of Stage Fabric Configuration Update (SFC) request(s) used to implement the setting of t11ZsZoneSetDistribute. In Enhanced mode, this object indicates the status/result of the last commit of changes to the Zone Set database that was invoked via the corresponding instance of t11ZsServerCommit. 'none' - no distribution/commit invoked via the corresponding instance of t11ZsZoneSetDistribute (Basic mode) DeSanti, et al. Standards Track [Page 33] RFC 4936 FC Zone Server MIB August 2007 or t11ZsServerCommit (Enhanced mode). 'inProgress' - distribution/commit is still in progress. 'success' - distribution/commit completed successfully. 'rejectFailure' - distribution/commit failed due to an SW_RJT. 'otherFailure' - distribution/commit failed for some other reason. When the value is 'rejectFailure', the corresponding instances of t11ZsServerReasonCode, t11ZsServerReasonCodeExp and t11ZsServerReasonVendorCode contain the reason codes. " REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.10.2.3." ::= { t11ZsServerEntry 6 } t11ZsServerReasonCode OBJECT-TYPE SYNTAX T11NsGs4RejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION "When the corresponding instance of t11ZsZoneSetResult has the value 'rejectFailure', this object contains the rejection's reason code. When the corresponding instance of t11ZsServerResult has a value other than 'rejectFailure', this object should contain the value 'none'." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, section 6.1.3 and tables 4, 5, and 6." ::= { t11ZsServerEntry 7 } t11ZsServerReasonCodeExp OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 1)) MAX-ACCESS read-only STATUS current DESCRIPTION "When the corresponding instance of t11ZsZoneSetResult has the value 'rejectFailure', this object contains the rejection's reason code explanation. When the corresponding instance of t11ZsServerResult has a value other than 'rejectFailure', this object DeSanti, et al. Standards Track [Page 34] RFC 4936 FC Zone Server MIB August 2007 should contain the zero-length string." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, section 6.1.3 and tables 4, 5, and 6." ::= { t11ZsServerEntry 8 } t11ZsServerReasonVendorCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 1)) MAX-ACCESS read-only STATUS current DESCRIPTION "When the corresponding instance of t11ZsZoneSetResult has the value 'rejectFailure', this object contains the rejection's reason vendor-specific code. When the corresponding instance of t11ZsServerResult has a value other than 'rejectFailure', this object should contain the zero-length string." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, section 6.1.3 and tables 4, 5, and 6." ::= { t11ZsServerEntry 9 } t11ZsServerLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the last change (creation, modification, or deletion) to the Zone Set database for the Zone Server for a particular Fabric. If said Zone Set database has not changed since the last re-initialization of the local network management system, then this object will contain a zero value." ::= { t11ZsServerEntry 10 } t11ZsServerHardZoning OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether this switch, if and when it is in Basic mode, enforces Hard Zoning on this Fabric." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.10.3.2." DeSanti, et al. Standards Track [Page 35] RFC 4936 FC Zone Server MIB August 2007 ::= { t11ZsServerEntry 11 } t11ZsServerReadFromDatabase OBJECT-TYPE SYNTAX INTEGER { committedDB(1), copyDB(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "In Enhanced mode, this object specifies whether subsequent SNMP Responses (generated by the local SNMP agent) to operations that read the configuration of Zone Sets, Zones, Members, Aliases and Attributes will reflect the values stored in the current (committed) Zone Set database, or those stored in the 'copy' database. In Basic mode, the value of this object is always 'committedDB' (since there is no 'copy' database in Basic mode). In SNMP agents that don't support write access to the Zone Set database, this object is always 'committedDB' (since the copy database, if it were to exist, would be identical)." DEFVAL { committedDB } ::= { t11ZsServerEntry 12 } t11ZsServerOperationMode OBJECT-TYPE SYNTAX INTEGER { basic(1), enhanced(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The operational mode of the Zone Server. Setting this object to 'enhanced' is a request that the mode of operation of the Zone Server be Enhanced mode, which is only possible if all devices in the Fibre Channel Fabric are capable of working in Enhanced mode. If not, the request will fail and the corresponding value of t11ZsServerChangeModeResult will so indicate. Setting this object to 'basic' is a request that the mode of operation of the Zone Server be Basic mode. However, such a set may fail while operating in Enhanced mode, since FC-GS-5 makes no provision for changing (back) DeSanti, et al. Standards Track [Page 36] RFC 4936 FC Zone Server MIB August 2007 to Basic mode. Note that setting this object does not cause or require that the Fabric lock for the Zone Server be obtained. However, when this object has the value 'enhanced', any SNMP SetRequests that attempt to modify the copy database cannot be successful if the Fabric lock has not been obtained or has since been released." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, sections 6.4.10.1.1 and 6.4.10.1.2." DEFVAL { basic } ::= { t11ZsServerEntry 13 } t11ZsServerChangeModeResult OBJECT-TYPE SYNTAX INTEGER { success(1), failure(2), inProgress(3), none(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "When this object has the value of 'success' or 'failure', the value indicates the outcome of the most recent request, invoked via t11ZsServerOperationMode, to change the mode of operation of the Zone Server. When such a request is in progress, this object has the value 'inProgress'. Prior to the first such request, the value of this object is 'none'." ::= { t11ZsServerEntry 14 } t11ZsServerDefaultZoneSetting OBJECT-TYPE SYNTAX INTEGER { permit(1), deny(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the Enhanced Zoning flag that governs the behavior of the Default Zone on this Fabric. If this object is set to 'permit', then the members of the Default Zone on this Fabric can communicate with each other. DeSanti, et al. Standards Track [Page 37] RFC 4936 FC Zone Server MIB August 2007 If this object is set to 'deny', then the members of the Default Zone on this Fabric cannot communicate with each other." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.10.1.1." DEFVAL { deny } ::= { t11ZsServerEntry 15 } t11ZsServerMergeControlSetting OBJECT-TYPE SYNTAX INTEGER { allow(1), restrict(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the Enhanced Zoning flag that indicates the Merge Control Setting for this Fabric: 'allow' - a switch may join the Fabric only if its Zoning Database is able to merge with the Fabric's Zoning Database. 'restrict' - a switch may join the Fabric only if its Zoning Database is equal to the Fabric's Zoning Database." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.10.1.1." DEFVAL { allow } ::= { t11ZsServerEntry 16 } t11ZsServerDefZoneBroadcast OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls an Enhanced Zoning capability: it indicates whether Broadcast Zoning is enabled on the Default Zone on this Fabric. If this object is set to 'true', then it is enabled. If this object is set to 'false', then it is disabled. If broadcast Zoning is enabled on a Default Zone, then broadcast frames generated by a member in that Default Zone will be restricted to members in that Default Zone." REFERENCE DeSanti, et al. Standards Track [Page 38] RFC 4936 FC Zone Server MIB August 2007 "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.7.2.2." ::= { t11ZsServerEntry 17 } -- -- The table of Zone Sets -- t11ZsSetTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information on every Zone Set in the Zone Set database of the Zone Servers on each Fabric in one or more switches. In Enhanced mode, changes to a database made via this table are always made to the 'copy' database, but values read from this table reflect the contents of either the 'copy' database or the current (committed) database as indicated by the corresponding value of t11ZsServerReadFromDatabase." ::= { t11ZsConfiguration 2 } t11ZsSetEntry OBJECT-TYPE SYNTAX T11ZsSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a Zone Set in the Zone Set database of a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). A Zone Set can be created in an existing Zone Set database, and can contain zero or more existing Zones. As and when new Zones are created (as rows in the t11ZsZoneTable), they can be added to a Zone Set by creating an entry for each in the t11ZsSetZoneTable. Deleting a row from this table deletes the Zone Set from the Zone Set database maintained by the Zone Server, but does not otherwise affect the Zone Server. The StorageType of a row in this table is specified by the instance of t11ZsServerDatabaseStorageType that is DeSanti, et al. Standards Track [Page 39] RFC 4936 FC Zone Server MIB August 2007 INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsSetIndex } ::= { t11ZsSetTable 1 } T11ZsSetEntry ::= SEQUENCE { t11ZsSetIndex Unsigned32, t11ZsSetName T11ZoningName, t11ZsSetRowStatus RowStatus } t11ZsSetIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of a Zone Set. This object uniquely identifies a Zone Set in the Zone Set database for a particular Fabric on a particular switch." ::= { t11ZsSetEntry 1 } t11ZsSetName OBJECT-TYPE SYNTAX T11ZoningName MAX-ACCESS read-create STATUS current DESCRIPTION "The name of this Zone Set. The t11ZsSetName should be unique within a Fabric. The Zone Set can be renamed at any time (i.e., even when the row in an active state) by setting this object to a new value." ::= { t11ZsSetEntry 2 } t11ZsSetRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object cannot be set to 'active' unless the corresponding value of t11ZsSetName is unique within the Fabric's Zone Server database on this switch." ::= { t11ZsSetEntry 3 } DeSanti, et al. Standards Track [Page 40] RFC 4936 FC Zone Server MIB August 2007 -- -- The table of Zones -- t11ZsZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table gives information on all the Zones in the Zone Set database of the Zone Servers on each Fabric in one or more switches. In Enhanced mode, changes to a database made via this table are always made to the 'copy' database, but values read from this table reflect the contents of either the 'copy' database or the current (committed) database as indicated by the corresponding value of t11ZsServerReadFromDatabase." ::= { t11ZsConfiguration 3 } t11ZsZoneEntry OBJECT-TYPE SYNTAX T11ZsZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a Zone in the Zone Set database of a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). A Zone can be created in an existing Zone Set database, by first creating an entry in this table, and then adding members to it by creating entries in the t11ZsZoneMemberTable. The StorageType of a row in this table is specified by the instance of t11ZsServerDatabaseStorageType that is INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsZoneIndex } ::= { t11ZsZoneTable 1 } T11ZsZoneEntry ::= SEQUENCE { t11ZsZoneIndex Unsigned32, t11ZsZoneName T11ZoningName, DeSanti, et al. Standards Track [Page 41] RFC 4936 FC Zone Server MIB August 2007 t11ZsZoneAttribBlock Unsigned32, t11ZsZoneRowStatus RowStatus } t11ZsZoneIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies this Zone within a particular Fabric's Zone Set database on a particular switch." ::= { t11ZsZoneEntry 1 } t11ZsZoneName OBJECT-TYPE SYNTAX T11ZoningName MAX-ACCESS read-create STATUS current DESCRIPTION "The name of this Zone. The t11ZsZoneName should be unique within a Fabric. The Zone can be renamed by setting this object to a new value." ::= { t11ZsZoneEntry 2 } t11ZsZoneAttribBlock OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the index value of the Zone Attribute Block that contains the Attributes of this Zone. In Enhanced mode, a value of zero indicates this Zone has no Zone Attributes. In Basic mode, this object always has the value of zero." ::= { t11ZsZoneEntry 3 } t11ZsZoneRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object cannot be set to 'active' unless the DeSanti, et al. Standards Track [Page 42] RFC 4936 FC Zone Server MIB August 2007 corresponding value of t11ZsZoneName is unique within the Fabric's Zone Server database on this switch." ::= { t11ZsZoneEntry 4 } -- -- The table specifying the Zones that belong to each Zone Set -- t11ZsSetZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsSetZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies which Zones belong to which Zone Sets in the Zone Set database of the Zone Servers on each Fabric in one or more switches." ::= { t11ZsConfiguration 4 } t11ZsSetZoneEntry OBJECT-TYPE SYNTAX T11ZsSetZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry specifies that a particular Zone (identified by the value of t11ZsZoneIndex) is one of the Zones that form a particular Zone Set (identified by the value of t11ZsSetIndex) in the Zone Set database of a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). When a row in this table exists, it references one row in the t11ZsSetTable and one row in the t11ZsZoneTable. The agent must ensure that both such rows when referenced by an active row in this table, do exist and have a status of 'active', either by refusing to create new rows in this table, or by automatically deleting rows in this table. An 'active' row in this table references one row in the t11ZsSetTable and one in the t11ZsZoneTable. The agent must ensure that all such referenced rows exist with a status of 'active', either by refusing to create new active rows in this table, or by automatically deleting any rows in this table that reference a deleted row. The StorageType of a row in this table is specified by the instance of t11ZsServerDatabaseStorageType that is DeSanti, et al. Standards Track [Page 43] RFC 4936 FC Zone Server MIB August 2007 INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsSetIndex, t11ZsZoneIndex } ::= { t11ZsSetZoneTable 1 } T11ZsSetZoneEntry ::= SEQUENCE { t11ZsSetZoneRowStatus RowStatus } t11ZsSetZoneRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row." ::= { t11ZsSetZoneEntry 1 } -- -- The table of Zone Aliases -- t11ZsAliasTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsAliasEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about the Zone Aliases in the Zone Set database of the Zone Servers on each Fabric in one or more switches. In Enhanced mode, changes to a database made via this table are always made to the 'copy' database, but values read from this table reflect the contents of either the 'copy' database or the current (committed) database as indicated by the corresponding value of t11ZsServerReadFromDatabase." ::= { t11ZsConfiguration 5 } t11ZsAliasEntry OBJECT-TYPE SYNTAX T11ZsAliasEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a Zone Alias in the Zone Set database of a particular Fabric (identified by the value of t11ZsServerFabricIndex) on DeSanti, et al. Standards Track [Page 44] RFC 4936 FC Zone Server MIB August 2007 a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). A Zone Member is added to a Zone Alias by creating an entry in the t11ZsZoneMemberTable pointing to a row of this table via t11ZsAliasIndex, i.e.,: - t11ZsZoneMemberParentType = 'alias', - t11ZsZoneMemberParentIndex = Alias's t11ZsAliasIndex, - t11ZsZoneMemberFormat != '05 - Alias Name', and - t11ZsZoneMemberID = Member's identifier. A Zone Alias is added to a Zone by creating an entry in the t11ZsZoneMemberTable pointing to a row of this table via t11ZsAliasName, i.e.,: - t11ZsZoneMemberParentType = 'zone', and - t11ZsZoneMemberParentIndex = Zone's t11ZsZoneIndex, - t11ZsZoneMemberFormat = '05 - Alias Name', - t11ZsZoneMemberID = Alias's t11ZsAliasName. The StorageType of a row in this table is specified by the instance of t11ZsServerDatabaseStorageType that is INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsAliasIndex } ::= { t11ZsAliasTable 1 } T11ZsAliasEntry ::= SEQUENCE { t11ZsAliasIndex Unsigned32, t11ZsAliasName T11ZoningName, t11ZsAliasRowStatus RowStatus } t11ZsAliasIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value which uniquely identifies this Zone Alias within the Zone Set database of a particular Fabric on a particular switch." ::= { t11ZsAliasEntry 1 } t11ZsAliasName OBJECT-TYPE SYNTAX T11ZoningName MAX-ACCESS read-create DeSanti, et al. Standards Track [Page 45] RFC 4936 FC Zone Server MIB August 2007 STATUS current DESCRIPTION "The name of this Zone Alias. The name of the Zone Alias should be unique within a Fabric. The Zone Alias can be renamed by setting this object to a new value if and when it is not in a Zone, i.e., if and only if the current name is not the value of any t11ZsZoneMemberID in the same Zone Set database." ::= { t11ZsAliasEntry 2 } t11ZsAliasRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object cannot be set to 'active' unless the corresponding value of t11ZsAliasName is unique within the Fabric's Zone Server database on this switch." ::= { t11ZsAliasEntry 3 } -- -- The table of Zone Members -- t11ZsZoneMemberTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsZoneMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all members of a Zone/Zone Alias and information about those members in the Zone Set database of the Zone Servers on each Fabric in one or more switches. In Enhanced mode, changes to a database made via this table are always made to the 'copy' database, but values read from this table reflect the contents of either the 'copy' database or the current (committed) database as indicated by the corresponding value of t11ZsServerReadFromDatabase." ::= { t11ZsConfiguration 6 } t11ZsZoneMemberEntry OBJECT-TYPE SYNTAX T11ZsZoneMemberEntry MAX-ACCESS not-accessible DeSanti, et al. Standards Track [Page 46] RFC 4936 FC Zone Server MIB August 2007 STATUS current DESCRIPTION "Each entry represents the relationship between a member and (one of) its 'parent(s)', i.e., a Zone or Zone Alias to which the member belongs, within a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). A Zone member (other than an alias) is added to a Zone by creating an entry in this table having: - t11ZsZoneMemberParentType = 'zone', and - t11ZsZoneMemberParentIndex = Zone's t11ZsZoneIndex, - t11ZsZoneMemberFormat != '05 - Alias Name', - t11ZsZoneMemberID = Member's identifier. An 'active' row in this table references rows in other tables. The agent must ensure that all such referenced rows exist with a status of 'active', either by refusing to create new active rows in this table, or by automatically deleting any rows in this table that reference a deleted row. The StorageType of a row in this table is specified by the instance of t11ZsServerDatabaseStorageType that is INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsZoneMemberParentType, t11ZsZoneMemberParentIndex, t11ZsZoneMemberIndex } ::= { t11ZsZoneMemberTable 1 } T11ZsZoneMemberEntry ::= SEQUENCE { t11ZsZoneMemberParentType INTEGER, t11ZsZoneMemberParentIndex Unsigned32, t11ZsZoneMemberIndex Unsigned32, t11ZsZoneMemberFormat T11ZsZoneMemberType, t11ZsZoneMemberID OCTET STRING, t11ZsZoneMemberRowStatus RowStatus } t11ZsZoneMemberParentType OBJECT-TYPE SYNTAX INTEGER { zone(1), -- member belongs to a Zone alias(2) -- member belongs to a Zone Alias } DeSanti, et al. Standards Track [Page 47] RFC 4936 FC Zone Server MIB August 2007 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object determines whether this member belongs to a Zone or Zone Alias." ::= { t11ZsZoneMemberEntry 1 } t11ZsZoneMemberParentIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains the index value of the Zone or Zone Alias to which this member belongs. If the value of the corresponding instance of t11ZsZoneMemberParentType is 'zone', then this object will contain the value of the t11ZsZoneIndex object of the Zone to which this member belongs. If the value of the corresponding instance of t11ZsZoneMemberParentType is 'alias', then this object will contain the value of the t11ZsAliasIndex object of the Zone Alias to which this member belongs." ::= { t11ZsZoneMemberEntry 2 } t11ZsZoneMemberIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies this Zone Member amongst all Zone Members in the Zone Set database of a particular Fabric on a particular switch." ::= { t11ZsZoneMemberEntry 3 } t11ZsZoneMemberFormat OBJECT-TYPE SYNTAX T11ZsZoneMemberType MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the format of the Zone/Zone Alias member's identifier contained in t11ZsZoneMemberID. This object cannot be modified while the corresponding value of t11ZsZoneMemberRowStatus object is 'active'." ::= { t11ZsZoneMemberEntry 4 } DeSanti, et al. Standards Track [Page 48] RFC 4936 FC Zone Server MIB August 2007 t11ZsZoneMemberID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the Member Identifier of the Zone or Alias. The interpretation of this object depends on the value of the corresponding instance of t11ZsZoneMemberFormat: - if t11ZsZoneMemberFormat is 'N_Port_Name', then this object contains an N_Port_Name. - if t11ZsZoneMemberFormat is 'Domain_ID and physical port', then this object contains a 4-octet value in network byte order. The first octet is zero, the second octet contains the Domain_ID, and the last 2 octets contain the physical port number. - if t11ZsZoneMemberFormat is 'N_Port_ID', then this object contains the 3-octet Nx_Port FC_ID. - if t11ZsZoneMemberFormat is 'Alias Name', then this object contains the value of t11ZsAliasName for some Alias in the same Zone Set database. - if t11ZsZoneMemberFormat is 'Node_Name', then this object contains an 8-octet Node_Name. - if t11ZsZoneMemberFormat is 'F_Port_Name', then this object contains an 8-octet F_Port_Name. - if t11ZsZoneMemberFormat is one of the 'Vendor Specific' values, then this object contains a value of 1 to 255 octets in a format defined by the relevant vendor. This object cannot be modified while the corresponding value of t11ZsZoneMemberRowStatus object is 'active'." ::= { t11ZsZoneMemberEntry 5 } t11ZsZoneMemberRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. DeSanti, et al. Standards Track [Page 49] RFC 4936 FC Zone Server MIB August 2007 The corresponding instances of t11ZsZoneMemberID and t11ZsZoneMemberFormat objects must be set before or concurrently with setting this object to 'active'." ::= { t11ZsZoneMemberEntry 6 } -- -- The table of Zone Attribute Blocks -- t11ZsAttribBlockTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsAttribBlockEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table gives information on all the Zone Attributes in the Zone Set database of the Zone Servers on each Fabric in one or more switches. In Enhanced mode, changes to a database made via this table are always made to the 'copy' database, but values read from this table reflect the contents of either the 'copy' database or the current (committed) database as indicated by the corresponding value of t11ZsServerReadFromDatabase." ::= { t11ZsConfiguration 7 } t11ZsAttribBlockEntry OBJECT-TYPE SYNTAX T11ZsAttribBlockEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a Zone Attribute Block (of Zone Attributes) in the Zone Set database of a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). An 'active' row in this table references a row in the t11ZsAttribBlockTable. The agent must ensure that the referenced rows exists with a status of 'active', either by refusing to create new active rows in this table, or by automatically deleting any rows in this table that reference a deleted row. The StorageType of a row in this table is specified by the instance of t11ZsServerDatabaseStorageType that is INDEXed by the same values of fcmInstanceIndex, DeSanti, et al. Standards Track [Page 50] RFC 4936 FC Zone Server MIB August 2007 fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsAttribBlockIndex } ::= { t11ZsAttribBlockTable 1 } T11ZsAttribBlockEntry ::= SEQUENCE { t11ZsAttribBlockIndex Unsigned32, t11ZsAttribBlockName T11ZoningName, t11ZsAttribBlockRowStatus RowStatus } t11ZsAttribBlockIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies this Zone Attribute within the Zone Set database of a particular Fabric on a particular switch." ::= { t11ZsAttribBlockEntry 1 } t11ZsAttribBlockName OBJECT-TYPE SYNTAX T11ZoningName MAX-ACCESS read-create STATUS current DESCRIPTION "The name of this Zone Attribute Block, which should be unique within the Fabric." ::= { t11ZsAttribBlockEntry 2 } t11ZsAttribBlockRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row." ::= { t11ZsAttribBlockEntry 3 } DeSanti, et al. Standards Track [Page 51] RFC 4936 FC Zone Server MIB August 2007 -- -- The table of Zone Attributes -- t11ZsAttribTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table gives information on the Zone Attributes within the Zone Attribute Blocks in the Zone Set database of the Zone Servers on each Fabric in one or more switches. In Enhanced mode, changes to a database made via this table are always made to the 'copy' database, but values read from this table reflect the contents of either the 'copy' database or the current (committed) database as indicated by the corresponding value of t11ZsServerReadFromDatabase." ::= { t11ZsConfiguration 8 } t11ZsAttribEntry OBJECT-TYPE SYNTAX T11ZsAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about a Zone Attribute in a Zone Attribute Block (identified by t11ZsAttribBlockIndex) in the Zone Set database of a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). An entry in this table cannot be created prior to its associated entry in the t11ZsAttribBlockTable. The StorageType of a row in this table is specified by the instance of t11ZsServerDatabaseStorageType that is INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsAttribBlockIndex, t11ZsAttribIndex } ::= { t11ZsAttribTable 1 } T11ZsAttribEntry ::= SEQUENCE { DeSanti, et al. Standards Track [Page 52] RFC 4936 FC Zone Server MIB August 2007 t11ZsAttribIndex Unsigned32, t11ZsAttribType Unsigned32, t11ZsAttribValue OCTET STRING, t11ZsAttribRowStatus RowStatus } t11ZsAttribIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies this Zone Attribute within its Zone Attribute Block in the Zone Set database of a particular Fabric on a particular switch." ::= { t11ZsAttribEntry 1 } t11ZsAttribType OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The type of attribute: 0001 - Protocol 0002 - Broadcast Zone 0003 - Hard Zone 00E0 (hex) - Vendor Specific." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.8.3.8, Table 249." ::= { t11ZsAttribEntry 2 } t11ZsAttribValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..252)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the attribute, formatted as specified in FC-GS-5 for the type given by the corresponding instance of t11ZsAttribType. Note that FC-GS-5 requires that the length of this value is a multiple of 4 bytes." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.8.3.8." ::= { t11ZsAttribEntry 3 } DeSanti, et al. Standards Track [Page 53] RFC 4936 FC Zone Server MIB August 2007 t11ZsAttribRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row." ::= { t11ZsAttribEntry 4 } -- -- Activating a Zone Set -- t11ZsActivateTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsActivateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a mechanism to allow a Zone Set to be activated on a Fabric." ::= { t11ZsConfiguration 9 } t11ZsActivateEntry OBJECT-TYPE SYNTAX T11ZsActivateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry reflects the state of the activation of a Zone Set by a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex) on a particular Fabric (identified by the value of t11ZsServerFabricIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex } ::= { t11ZsActivateTable 1 } T11ZsActivateEntry ::= SEQUENCE { t11ZsActivateRequest Unsigned32, t11ZsActivateDeactivate INTEGER, t11ZsActivateResult INTEGER, t11ZsActivateFailCause SnmpAdminString, t11ZsActivateFailDomainId FcDomainIdOrZero } t11ZsActivateRequest OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 54] RFC 4936 FC Zone Server MIB August 2007 "Setting this object to a value is a request for a Zone Set to be activated on the Fabric that is represented by this row. The Zone Set to be activated is the one for which t11ZsSetIndex has the same value. If a Zone Set is already active on a Fabric when a request is made to activate a different one on that Fabric, then the existing Zone Set is automatically deactivated and the specified Zone Set is activated in its place. The value of this object when read is always 0." ::= { t11ZsActivateEntry 1 } t11ZsActivateDeactivate OBJECT-TYPE SYNTAX INTEGER { deactivate(1), noop(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'deactivate' is a request to deactivate the currently active Zone Set on a Fabric. Note that the deactivation of the active Zone Set allows all ports to communicate or no ports to communicate, depending on the current Default Zone behavior. No action is taken if this object is set to 'noop'. When read, the value of this object is always 'noop'." ::= { t11ZsActivateEntry 2 } t11ZsActivateResult OBJECT-TYPE SYNTAX INTEGER { activateSuccess(1), activateFailure(2), deactivateSuccess(3), deactivateFailure(4), inProgress(5), none(6) } MAX-ACCESS read-only STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 55] RFC 4936 FC Zone Server MIB August 2007 "This object indicates the outcome of the most recent activation/deactivation using this entry. When the value of this object is 'inProgress', the values of the corresponding instances of t11ZsActivateRequest and t11ZsActivateDeactivate cannot be modified. The value 'none' indicates activation/deactivation has not been attempted since the last restart of the management system." ::= { t11ZsActivateEntry 3 } t11ZsActivateFailCause OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual message indicating the reason for the most recent failure of a Zone Set activation or deactivation, or the zero-length string if no information is available (e.g., because the corresponding instance of t11ZsActivateResult has the value 'none'). When the corresponding instance of t11ZsActivateResult is either 'activateFailure' or 'deactivateFailure', the value of this object indicates the reason for that failure." ::= { t11ZsActivateEntry 4 } t11ZsActivateFailDomainId OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "If the failure cause (as indicated by t11ZsSetFailCause) was specific to a particular device, this object contains the Domain_ID of that device. Otherwise, this object contains zero." ::= { t11ZsActivateEntry 5 } DeSanti, et al. Standards Track [Page 56] RFC 4936 FC Zone Server MIB August 2007 -- -- t11ZsActiveTable -- t11ZsActiveTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information on the currently enforced/active Zone Set on each Fabric. An active Zone Set cannot be modified. This table will be empty when no Zone Set is activated." ::= { t11ZsConfiguration 10 } t11ZsActiveEntry OBJECT-TYPE SYNTAX T11ZsActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents an active Zone Set of a particular Fabric (identified by the value of t11ZsServerFabricIndex), according to a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex } ::= { t11ZsActiveTable 1 } T11ZsActiveEntry ::= SEQUENCE { t11ZsActiveZoneSetName T11ZoningName, t11ZsActiveActivateTime TimeStamp } t11ZsActiveZoneSetName OBJECT-TYPE SYNTAX T11ZoningName MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this Zone Set on this Fabric." ::= { t11ZsActiveEntry 1 } t11ZsActiveActivateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 57] RFC 4936 FC Zone Server MIB August 2007 "The value of sysUpTime at which this entry was most recently activated. If this row was activated prior to the last re-initialization of the local network management system, then this object will contain a zero value." ::= { t11ZsActiveEntry 2 } -- -- Zones in the Active/Enforced Zone Set -- t11ZsActiveZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsActiveZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all the Zones that are present in the active Zone Sets on all Fabrics." ::= { t11ZsConfiguration 11 } t11ZsActiveZoneEntry OBJECT-TYPE SYNTAX T11ZsActiveZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents a Zone in the active Zone Set of a particular Fabric (identified by the value of t11ZsServerFabricIndex), according to a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsActiveZoneIndex } ::= { t11ZsActiveZoneTable 1 } T11ZsActiveZoneEntry ::= SEQUENCE { t11ZsActiveZoneIndex Unsigned32, t11ZsActiveZoneName T11ZoningName, t11ZsActiveZoneBroadcastZoning TruthValue, t11ZsActiveZoneHardZoning TruthValue } t11ZsActiveZoneIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies this Zone within the active Zone Set on a particular Fabric." ::= { t11ZsActiveZoneEntry 1 } DeSanti, et al. Standards Track [Page 58] RFC 4936 FC Zone Server MIB August 2007 t11ZsActiveZoneName OBJECT-TYPE SYNTAX T11ZoningName MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this Zone." ::= { t11ZsActiveZoneEntry 2 } t11ZsActiveZoneBroadcastZoning OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether broadcast Zoning is enabled on this Zone. If broadcast Zoning is enabled, then broadcast frames generated by a member in this Zone will be restricted to members in this Zone. This object is only instantiated in Enhanced mode." ::= { t11ZsActiveZoneEntry 3 } t11ZsActiveZoneHardZoning OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether hard Zoning is enabled on this Zone. This object is only instantiated in Enhanced mode." ::= { t11ZsActiveZoneEntry 4 } -- -- Zone Members in the Active/Enforced Zone Set -- t11ZsActiveZoneMemberTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsActiveZoneMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all members of all Zones within the active Zone Set on any Fabric." ::= { t11ZsConfiguration 12 } t11ZsActiveZoneMemberEntry OBJECT-TYPE SYNTAX T11ZsActiveZoneMemberEntry MAX-ACCESS not-accessible DeSanti, et al. Standards Track [Page 59] RFC 4936 FC Zone Server MIB August 2007 STATUS current DESCRIPTION "Each entry represents a member of a Zone in the active Zone Set of a particular Fabric (identified by the value t11ZsServerFabricIndex), according to a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsActiveZoneIndex, t11ZsActiveZoneMemberIndex } ::= { t11ZsActiveZoneMemberTable 1 } T11ZsActiveZoneMemberEntry ::= SEQUENCE { t11ZsActiveZoneMemberIndex Unsigned32, t11ZsActiveZoneMemberFormat T11ZsZoneMemberType, t11ZsActiveZoneMemberID OCTET STRING } t11ZsActiveZoneMemberIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies this member amongst the members of a particular Zone in the active Zone Set on a particular Fabric." ::= { t11ZsActiveZoneMemberEntry 1 } t11ZsActiveZoneMemberFormat OBJECT-TYPE SYNTAX T11ZsZoneMemberType MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the identifier format of the corresponding instance of t11ZsActiveZoneMemberID." ::= { t11ZsActiveZoneMemberEntry 2 } t11ZsActiveZoneMemberID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This value of this object identifies the member using the format specified in the corresponding instance of t11ZsActiveZoneMemberFormat." ::= { t11ZsActiveZoneMemberEntry 3 } DeSanti, et al. Standards Track [Page 60] RFC 4936 FC Zone Server MIB August 2007 -- -- Zone Attributes in the Active/Enforced Zone Set -- t11ZsActiveAttribTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsActiveAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about some of the Attributes of the Zones within the active Zone Set on each Fabric. This table contains all the types of attributes that might apply zero, one, or more times to a Zone. Attributes that apply once and only to a Zone are specified in the t11ZsActiveZoneTable. This table will always be empty in Basic mode. It will also be empty if there are no Zones in any active Zone Set having any of the applicable types of attributes." ::= { t11ZsConfiguration 13 } t11ZsActiveAttribEntry OBJECT-TYPE SYNTAX T11ZsActiveAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains an Attribute of a particular Zone in the active Zone Set of a particular Fabric (identified by the value of t11ZsServerFabricIndex), according to a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsActiveZoneIndex, t11ZsActiveAttribIndex } ::= { t11ZsActiveAttribTable 1 } T11ZsActiveAttribEntry ::= SEQUENCE { t11ZsActiveAttribIndex Unsigned32, t11ZsActiveAttribType Unsigned32, t11ZsActiveAttribValue OCTET STRING } t11ZsActiveAttribIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible DeSanti, et al. Standards Track [Page 61] RFC 4936 FC Zone Server MIB August 2007 STATUS current DESCRIPTION "An index value that uniquely identifies this attribute amongst the other attributes for a particular Zone in the active Zone Set on a particular Fabric." ::= { t11ZsActiveAttribEntry 1 } t11ZsActiveAttribType OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The type of attribute: 0001 - Protocol 00E0 (hex) - Vendor Specific Note that type 2 (Hard) and type 3 (Broadcast) do not need to be represented here, because they are represented by t11ZsActiveZoneBroadcastZoning and t11ZsActiveZoneHardZoning." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.8.3.8, Table 249." ::= { t11ZsActiveAttribEntry 2 } t11ZsActiveAttribValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..252)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the attribute, formatted according to its type as indicated by the corresponding instance of t11ZsActiveAttribType. As specified in FC-GS-5, the length of an attribute value is at least 4 bytes, and if necessary, the value is appended with zero bytes so that the length is a multiple of 4. For a Vendor-Specific attribute value, the first 8 bytes contain the T10 Vendor ID as described in FC-GS-5." REFERENCE "Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2007, section 6.4.8.3.8." ::= { t11ZsActiveAttribEntry 3 } DeSanti, et al. Standards Track [Page 62] RFC 4936 FC Zone Server MIB August 2007 -- -- Zone Server Statistics -- t11ZsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of statistics maintained by Zone Servers." ::= { t11ZsStatistics 1 } t11ZsStatsEntry OBJECT-TYPE SYNTAX T11ZsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for a Zone Server on a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex } ::= { t11ZsStatsTable 1 } T11ZsStatsEntry ::= SEQUENCE { t11ZsOutMergeRequests Counter32, t11ZsInMergeAccepts Counter32, t11ZsInMergeRequests Counter32, t11ZsOutMergeAccepts Counter32, t11ZsOutChangeRequests Counter32, t11ZsInChangeAccepts Counter32, t11ZsInChangeRequests Counter32, t11ZsOutChangeAccepts Counter32, t11ZsInZsRequests Counter32, t11ZsOutZsRejects Counter32 } t11ZsOutMergeRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Merge Request Frames sent by this Zone Server to other Zone Servers in the same Fabric. This counter has no discontinuities other than those DeSanti, et al. Standards Track [Page 63] RFC 4936 FC Zone Server MIB August 2007 that all Counter32s have when sysUpTime=0." ::= { t11ZsStatsEntry 1 } t11ZsInMergeAccepts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Merge Accept Frames received by this Zone Server from other Zone Servers in the same Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11ZsStatsEntry 2 } t11ZsInMergeRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Merge Request Frames received by this Zone Server from other Zone Servers in the same Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11ZsStatsEntry 3 } t11ZsOutMergeAccepts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Merge Accept Frames sent by this Zone Server to other Zone Servers in the same Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11ZsStatsEntry 4 } t11ZsOutChangeRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of change requests sent (via the Fabric Management Session Protocol) by this Zone Server to other Zone Servers in the same Fabric. DeSanti, et al. Standards Track [Page 64] RFC 4936 FC Zone Server MIB August 2007 This includes Acquire Change Authorization requests, Stage Fabric Config Update requests, Update Fabric Config requests and Release Change Authorization requests. It also includes the corresponding types of requests defined by the Enhanced Commit Service. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, sections 10.6 and 13." ::= { t11ZsStatsEntry 5 } t11ZsInChangeAccepts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SW_ACC messages received from other Zone Servers in the same Fabric (according to the Fabric Management Session Protocol) in response to change requests by this Zone Server. This includes SW_ACC messages received in response to Acquire Change Authorization requests, to Stage Fabric Config Update requests, to Update Fabric Config requests, and to Release Change Authorization requests. It also includes responses to the corresponding types of requests defined for the Enhanced Commit Service. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, sections 10.6 and 13." ::= { t11ZsStatsEntry 6 } t11ZsInChangeRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of change requests received (via the Fabric Management Session Protocol) by this Zone Server from other Zone Servers in the same Fabric. This includes Acquire Change Authorization requests, Stage Fabric Config Update requests, Update Fabric Config requests DeSanti, et al. Standards Track [Page 65] RFC 4936 FC Zone Server MIB August 2007 and Release Change Authorization requests. It also includes the corresponding types of requests defined by the Enhanced Commit Service. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, sections 10.6 and 13." ::= { t11ZsStatsEntry 7 } t11ZsOutChangeAccepts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SW_ACC messages sent by this Zone Server (according to the Fabric Management Session Protocol) in response to change requests from other Zone Servers in the same Fabric. This includes SW_ACC messages sent in response to Acquire Change Authorization requests, to Stage Fabric Config Update requests, to Update Fabric Config requests and to Release Change Authorization requests. It also includes responses to the corresponding types of requests defined for the Enhanced Commit Service. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, sections 10.6 and 13." ::= { t11ZsStatsEntry 8 } t11ZsInZsRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Zone Server requests received by this Zone Server on this Fabric, both those received in Basic mode and in Enhanced mode. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11ZsStatsEntry 9 } DeSanti, et al. Standards Track [Page 66] RFC 4936 FC Zone Server MIB August 2007 t11ZsOutZsRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Zone Server requests rejected by this Zone Server on this Fabric, both those rejected in Basic mode and in Enhanced mode. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11ZsStatsEntry 10 } -- -- Notification Control Table -- t11ZsNotifyControlTable OBJECT-TYPE SYNTAX SEQUENCE OF T11ZsNotifyControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control information for notifications generated due to Zone Server events." ::= { t11ZsConfiguration 14 } t11ZsNotifyControlEntry OBJECT-TYPE SYNTAX T11ZsNotifyControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains notification control information specific to a Zone Server for a particular Fabric (identified by the value of t11ZsServerFabricIndex) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex). The persistence across reboots of writable values in a row of this table is specified by the instance of t11ZsServerDatabaseStorageType that is INDEXed by the same values of fcmInstanceIndex, fcmSwitchIndex, and t11ZsServerFabricIndex." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex } ::= { t11ZsNotifyControlTable 1 } T11ZsNotifyControlEntry ::= SEQUENCE { t11ZsNotifyRequestRejectEnable TruthValue, DeSanti, et al. Standards Track [Page 67] RFC 4936 FC Zone Server MIB August 2007 t11ZsNotifyMergeFailureEnable TruthValue, t11ZsNotifyMergeSuccessEnable TruthValue, t11ZsNotifyDefZoneChangeEnable TruthValue, t11ZsNotifyActivateEnable TruthValue, t11ZsRejectCtCommandString OCTET STRING, t11ZsRejectRequestSource FcNameIdOrZero, t11ZsRejectReasonCode T11NsGs4RejectReasonCode, t11ZsRejectReasonCodeExp T11ZsRejectReasonExplanation, t11ZsRejectReasonVendorCode OCTET STRING } t11ZsNotifyRequestRejectEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11ZsRequestRejectNotify notifications should be generated by the Zone Server for this Fabric." ::= { t11ZsNotifyControlEntry 1 } t11ZsNotifyMergeFailureEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11ZsMergeFailureNotify notifications should be generated by the Zone Server for this Fabric." ::= { t11ZsNotifyControlEntry 2 } t11ZsNotifyMergeSuccessEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11ZsMergeSuccessNotify notifications should be generated by the Zone Server for this Fabric." ::= { t11ZsNotifyControlEntry 3 } t11ZsNotifyDefZoneChangeEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11ZsDefZoneChangeNotify notifications should be generated by the Zone Server DeSanti, et al. Standards Track [Page 68] RFC 4936 FC Zone Server MIB August 2007 for this Fabric." ::= { t11ZsNotifyControlEntry 4 } t11ZsNotifyActivateEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11ZsActivateNotify notifications should be generated by the Zone Server for this Fabric." ::= { t11ZsNotifyControlEntry 5 } t11ZsRejectCtCommandString OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The binary content of the Zone Server request, formatted as an octet string (in network byte order) containing the Common Transport Information Unit (CT_IU), as described in Table 2 of FC-GS-5 (including the preamble), which was most recently rejected by the Fabric Configuration Server for this Fabric. This object contains the zero-length string if and when the CT-IU's content is unavailable. When the length of this object is 255 octets, it contains the first 255 octets of the CT-IU (in network byte order)." ::= { t11ZsNotifyControlEntry 6 } t11ZsRejectRequestSource OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The WWN that was the source of the CT_IU contained in the corresponding instance of t11ZsRejectCtCommandString." ::= { t11ZsNotifyControlEntry 7 } t11ZsRejectReasonCode OBJECT-TYPE SYNTAX T11NsGs4RejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION DeSanti, et al. Standards Track [Page 69] RFC 4936 FC Zone Server MIB August 2007 "The reason code corresponding to the most recent rejection of a request by the Zone Server for this Fabric." ::= { t11ZsNotifyControlEntry 8 } t11ZsRejectReasonCodeExp OBJECT-TYPE SYNTAX T11ZsRejectReasonExplanation MAX-ACCESS read-only STATUS current DESCRIPTION "When the value of t11ZsRejectReasonCode is 'Unable to perform command request', this object contains the corresponding reason code explanation." ::= { t11ZsNotifyControlEntry 9 } t11ZsRejectReasonVendorCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-only STATUS current DESCRIPTION "When the value of t11ZsRejectReasonCode is 'Vendor Specific Error', this object contains the corresponding vendor-specific reason code." ::= { t11ZsNotifyControlEntry 10 } t11ZsFabricIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4096) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains either a value of T11FabricIndex to identify the Fabric on which some occurrence has caused a notification to be generated, or it has the value 4096 to indicate all applicable Fabrics." ::= { t11ZsConfiguration 15 } DeSanti, et al. Standards Track [Page 70] RFC 4936 FC Zone Server MIB August 2007 -- Notifications t11ZsRequestRejectNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11ZsRejectRequestSource, t11ZsRejectCtCommandString, t11ZsRejectReasonCode, t11ZsRejectReasonCodeExp, t11ZsRejectReasonVendorCode } STATUS current DESCRIPTION "This notification is generated whenever a Zone Server (indicated by the value of t11FamLocalSwitchWwn) rejects a request. The value of t11ZsRejectCtCommandString indicates the rejected request, and the values of t11ZsRejectReasonCode, t11ZsRejectReasonCodeExp and t11ZsRejectReasonVendorCode indicate the reason for the rejection. The value of t11ZsRequestClient indicates the source of the request." ::= { t11ZsMIBNotifications 1 } t11ZsMergeFailureNotify NOTIFICATION-TYPE OBJECTS { ifIndex, t11ZsFabricIndex } STATUS current DESCRIPTION "This notification indicates that a Zone merge failure has occurred on the Fabric indicated by the value of t11ZsFabricIndex, on the interface indicated by the value of ifIndex. If multiple Virtual Fabrics are configured on an interface, and all have a Zone merge failure at the same time, then just one notification is generated and t11ZsFabricIndex has the value 4096." ::= { t11ZsMIBNotifications 2 } t11ZsMergeSuccessNotify NOTIFICATION-TYPE OBJECTS { ifIndex, t11ZsFabricIndex } STATUS current DESCRIPTION "This notification indicates that a successful Zone merge has occurred on the Fabric indicated by the value of t11ZsFabricIndex, on the interface indicated by the value of ifIndex. If multiple Virtual Fabrics are configured on an interface, and all have a successful Zone Merge DeSanti, et al. Standards Track [Page 71] RFC 4936 FC Zone Server MIB August 2007 at the same time, then just one notification is generated and t11ZsFabricIndex has the value 4096." ::= { t11ZsMIBNotifications 3 } t11ZsDefZoneChangeNotify NOTIFICATION-TYPE OBJECTS { t11ZsServerDefaultZoneSetting } STATUS current DESCRIPTION "This notification indicates that the value of a Default Zone Setting has changed. The value of t11ZsServerDefaultZoneSetting contains the value after the change." ::= { t11ZsMIBNotifications 4 } t11ZsActivateNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11ZsActivateResult } STATUS current DESCRIPTION "This notification is generated whenever a switch (indicated by the value of t11FamLocalSwitchWwn) activates/deactivates a Zone Set on a Fabric. The t11ZsActivateResult object denotes the outcome of the activation/deactivation." ::= { t11ZsMIBNotifications 5 } -- Conformance t11ZsMIBCompliances OBJECT IDENTIFIER ::= { t11ZsMIBConformance 1 } t11ZsMIBGroups OBJECT IDENTIFIER ::= { t11ZsMIBConformance 2 } t11ZsMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the Zone Server." MODULE MANDATORY-GROUPS {t11ZsBasicGroup, t11ZsNotificationControlGroup, t11ZsNotificationGroup } GROUP t11ZsEnhancedModeGroup DESCRIPTION "This group is mandatory only for those systems with Zone Servers that support Enhanced Mode." GROUP t11ZsActivateGroup DESCRIPTION "Only entities that provide write access for activating a Zone Set support need to support DeSanti, et al. Standards Track [Page 72] RFC 4936 FC Zone Server MIB August 2007 this group." GROUP t11ZsStatisticsGroup DESCRIPTION "These counters, containing Zone Server statistics, are mandatory only for those systems that count such events." OBJECT t11ZsSetRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsZoneRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsSetZoneRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsAliasRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsZoneMemberRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsAttribBlockRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsAttribRowStatus SYNTAX INTEGER { active(1) } MIN-ACCESS read-only DESCRIPTION DeSanti, et al. Standards Track [Page 73] RFC 4936 FC Zone Server MIB August 2007 "Write access is not required." OBJECT t11ZsServerDatabaseStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsServerDistribute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsServerCommit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsServerReadFromDatabase MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsServerOperationMode MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsServerDefaultZoneSetting MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsServerMergeControlSetting MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsServerDefZoneBroadcast MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsSetName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsZoneName DeSanti, et al. Standards Track [Page 74] RFC 4936 FC Zone Server MIB August 2007 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsZoneAttribBlock MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsAliasName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsZoneMemberFormat MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsZoneMemberID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsAttribBlockName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsAttribType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsAttribValue MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsActivateRequest MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsActivateDeactivate MIN-ACCESS read-only DESCRIPTION "Write access is not required." DeSanti, et al. Standards Track [Page 75] RFC 4936 FC Zone Server MIB August 2007 OBJECT t11ZsNotifyRequestRejectEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsNotifyMergeFailureEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsNotifyMergeSuccessEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsNotifyDefZoneChangeEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11ZsNotifyActivateEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11ZsMIBCompliances 1 } -- Units of Conformance t11ZsBasicGroup OBJECT-GROUP OBJECTS { t11ZsServerCapabilityObject, t11ZsServerDatabaseStorageType, t11ZsServerDistribute, t11ZsServerResult, t11ZsServerReasonCode, t11ZsServerReasonCodeExp, t11ZsServerReasonVendorCode, t11ZsServerLastChange, t11ZsServerHardZoning, t11ZsServerReadFromDatabase, t11ZsServerOperationMode, t11ZsSetName, t11ZsSetRowStatus, t11ZsZoneName, t11ZsZoneAttribBlock, t11ZsZoneRowStatus, t11ZsSetZoneRowStatus, t11ZsZoneMemberFormat, DeSanti, et al. Standards Track [Page 76] RFC 4936 FC Zone Server MIB August 2007 t11ZsZoneMemberID, t11ZsZoneMemberRowStatus, t11ZsActiveZoneSetName, t11ZsActiveActivateTime, t11ZsActiveZoneName, t11ZsActiveZoneMemberFormat, t11ZsActiveZoneMemberID } STATUS current DESCRIPTION "A collection of objects for displaying and updating the Zone configuration of a Zone Server capable of operating in Basic mode." ::= { t11ZsMIBGroups 1 } t11ZsEnhancedModeGroup OBJECT-GROUP OBJECTS { t11ZsServerCommit, t11ZsServerChangeModeResult, t11ZsServerDefaultZoneSetting, t11ZsServerMergeControlSetting, t11ZsServerDefZoneBroadcast, t11ZsAliasName, t11ZsAliasRowStatus, t11ZsAttribBlockName, t11ZsAttribBlockRowStatus, t11ZsAttribType, t11ZsAttribValue, t11ZsAttribRowStatus, t11ZsActiveZoneBroadcastZoning, t11ZsActiveZoneHardZoning, t11ZsActiveAttribType, t11ZsActiveAttribValue } STATUS current DESCRIPTION "A collection of additional objects for displaying and updating the Zone configuration of a Zone Server capable of operating in Enhanced mode." ::= { t11ZsMIBGroups 2 } t11ZsStatisticsGroup OBJECT-GROUP OBJECTS { t11ZsOutMergeRequests, t11ZsInMergeAccepts, t11ZsInMergeRequests, t11ZsOutMergeAccepts, t11ZsOutChangeRequests, t11ZsInChangeAccepts, t11ZsInChangeRequests, DeSanti, et al. Standards Track [Page 77] RFC 4936 FC Zone Server MIB August 2007 t11ZsOutChangeAccepts, t11ZsInZsRequests, t11ZsOutZsRejects } STATUS current DESCRIPTION "A collection of objects for collecting Zone Server statistics information." ::= { t11ZsMIBGroups 3 } t11ZsNotificationControlGroup OBJECT-GROUP OBJECTS { t11ZsNotifyRequestRejectEnable, t11ZsNotifyMergeFailureEnable, t11ZsNotifyMergeSuccessEnable, t11ZsNotifyDefZoneChangeEnable, t11ZsNotifyActivateEnable, t11ZsRejectCtCommandString, t11ZsRejectRequestSource, t11ZsRejectReasonCode, t11ZsRejectReasonCodeExp, t11ZsRejectReasonVendorCode, t11ZsFabricIndex } STATUS current DESCRIPTION "A collection of notification control and notification information objects for monitoring Zone Server request rejection and Zone merge failures." ::= { t11ZsMIBGroups 4 } t11ZsActivateGroup OBJECT-GROUP OBJECTS { t11ZsActivateRequest, t11ZsActivateDeactivate, t11ZsActivateResult, t11ZsActivateFailCause, t11ZsActivateFailDomainId } STATUS current DESCRIPTION "A collection of objects that allow a Zone Set to be activated via SNMP SetRequests and provide the status and result of such an activation." ::= { t11ZsMIBGroups 5 } t11ZsNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11ZsRequestRejectNotify, t11ZsMergeFailureNotify, DeSanti, et al. Standards Track [Page 78] RFC 4936 FC Zone Server MIB August 2007 t11ZsMergeSuccessNotify, t11ZsDefZoneChangeNotify, t11ZsActivateNotify } STATUS current DESCRIPTION "A collection of notification(s) for monitoring Zone Server request rejection, Zone merge failures and successes, and Default Zoning behavioral changes." ::= { t11ZsMIBGroups 6 } END 8. IANA Considerations IANA has assigned two MIB OIDs: one for the T11-FC-FABRIC-LOCK-MIB module (159) and one for the T11-FC-ZONE-SERVER-MIB module (160), under the mib-2 subtree. 9. Security Considerations There are many management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Specifically, unauthorized write access to *any* of the writable objects in these MIB modules could cause unauthorized manipulation of the Zoning information on a Zone Server, and/or the activation of an unauthorized Active Zone Set in a Fabric. This could result in allowing unauthorized connectivity, and/or denying authorized connectivity, between hosts connected to the Fibre Channel network. It could also cause the suppression of notifications (e.g., of unauthorized operations), or the disruption of network operations due to the generation of unwanted notifications. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Unauthorized read access to any of the readable objects in the t11ZsServerTable, t11ZsActiveZoneTable, t11ZsActiveZoneMemberTable, or t11ZsActiveAttribTable tables would reveal information about the DeSanti, et al. Standards Track [Page 79] RFC 4936 FC Zone Server MIB August 2007 currently authorized connectivity between hosts connected to the Fibre Channel network. Unauthorized read access to any of the readable objects in the t11ZsSetTable, t11ZsZoneTable, t11ZsSetZoneTable, t11ZsAliasTable, t11ZsZoneMemberTable, t11ZsAttribBlockTable, or t11ZsAttribTable tables would reveal information about potential/alternative connectivity that could be authorized between hosts connected to the Fibre Channel network. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. Acknowledgements This document was originally developed and approved by the INCITS Task Group T11.5 (http://www.t11.org) as the SM-ZSM project. We wish to acknowledge the many contributions and comments from the INCITS Technical Committee T11, especially from the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 Vice Chair: Scott Kipp, McData and T11.5 members. The document was subsequently a work item of the IETF's IMSS Working Group, chaired by David Black (EMC Corporation). We thank Bert Wijnen (Lucent Technologies) for his thorough review of the document. We also wish to acknowledge Dan Romascanu (Avaya), the IETF Area Director, for his comments and assistance. DeSanti, et al. Standards Track [Page 80] RFC 4936 FC Zone Server MIB August 2007 11. Normative References [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 58, RFC 3411, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", RFC 3584, August 2003. [FC-GS-5] "Fibre Channel - Generic Services - 5 (FC-GS-5)", ANSI INCITS 427-2007, http://www.t11.org/t11/stat.nsf/upnum/1677-d, 2007. [FC-GS-4] "Fibre Channel - Generic Services - 4 (FC-GS-4)", ANSI INCITS 387-2004, http://www.t11.org/t11/stat.nsf/upnum/1505-d, August 2004. [FC-SW-4] "Fibre Channel - Switch Fabric - 4 (FC-SW-4)", ANSI INCITS 418-2006, http://www.t11.org/t11/stat.nsf/upnum/1674-d, December 2006. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)", ANSI INCITS 373-2003, April 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. DeSanti, et al. Standards Track [Page 81] RFC 4936 FC Zone Server MIB August 2007 [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC4438] DeSanti, C., Gaonkar, V., Vivek, H., McCloghrie, K., and S. Gai, "Fibre-Channel Name Server MIB", RFC 4438, March 2006. [RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre-Channel Fabric Address Manager MIB", RFC 4439, March 2006. [APPL-ID] Steven Wilson (FC-SW-5, Editor), "FC-SW-5 Letter to T11.5", ANSI INCITS T11/06-679v0, http://www.t11.org/ftp/t11/pub/fc/sw-5/06-679v0.pdf, 21 September 2006. Approved by the T11 and T11.5 plenary meetings on October 5, 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12. Informative References [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. DeSanti, et al. Standards Track [Page 82] RFC 4936 FC Zone Server MIB August 2007 Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com H.K. Vivek Cisco Systems, Inc. 71 Millers Rd Bangalore, India Phone: +91 80 2289933x5117 EMail: hvivek@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 526-5260 EMail: kzm@cisco.com Silvano Gai Nuova Systems 3 West Plumeria Drive San Jose, CA 95134 Phone: +1 408 387-6123 EMail: sgai@nuovasystems.com DeSanti, et al. Standards Track [Page 83] RFC 4936 FC Zone Server MIB August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. DeSanti, et al. Standards Track [Page 84] snmp-mibs-downloader-1.1/mibrfcs/rfc4939.txt0000644000000000000000000050300511402176072015576 0ustar Network Working Group K. Gibbons Request for Comments: 4939 2Wire, Inc. Category: Standards Track G. Ramkumar SnapTell, Inc. S. Kipp Brocade, Inc. July 2007 Definitions of Managed Objects for iSNS (Internet Storage Name Service) 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. Gibbons, et al. Standards Track [Page 1] RFC 4939 iSNS MIB July 2007 Table of Contents 1. The Internet-Standard Management Framework ......................3 2. Introduction ....................................................3 2.1. Requirement Levels .........................................3 3. Technical Description ...........................................4 3.1. iSNS Registered Objects ....................................4 3.2. iSNS MIB Structure .........................................5 3.3. iSNS Server Info ...........................................5 3.3.1. Control Node Information ............................6 3.3.2. Discovery Domain Set (DDS) ..........................6 3.3.3. Discovery Domain (DD) ...............................6 3.3.4. Registered Storage Objects ..........................6 3.3.4.1. Registered Entities ........................6 3.3.4.2. Registered Portals .........................6 3.3.4.3. Registered Portal Groups ...................7 3.3.4.4. Registered iSCSI Nodes .....................7 3.3.4.5. Registered FC Ports ........................7 3.3.4.6. Registered FC Nodes ........................7 3.4. Multiple Server Instances ..................................7 3.5. iSNS Notifications .........................................7 4. MIB References ..................................................7 5. MIB Module ......................................................8 6. IANA Considerations ............................................75 7. Security Considerations ........................................76 8. Normative References ...........................................77 9. Informative References .........................................78 10. Acknowledgements ..............................................78 Gibbons, et al. Standards Track [Page 2] RFC 4939 iSNS MIB July 2007 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction The iSNS protocol, as described in RFC 4171 [RFC4171], can be used by IP-based storage devices for dynamic registration and discovery of other storage devices in the network. It has the capability to group devices into storage Discovery Domains, and Discovery Domains into Discovery Domain Sets. The iSNS MIB is designed to allow Simple Network Management Protocol (SNMP) to be used to monitor iSNS servers supporting iSCSI [RFC3720] and iFCP [RFC4172]. 2.1. Requirement Levels The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Gibbons, et al. Standards Track [Page 3] RFC 4939 iSNS MIB July 2007 3. Technical Description 3.1. iSNS Registered Objects The following entity relationship figure indicates the objects that can be registered in the iSNS, and their relationship to each other. +--------------+ +-----------+ | NETWORK |1 *| | | ENTITY |----| PORTAL | | | | | +--------------+ +-----------+ |1 |1 |* | | | | |* | | +----------+ | | | PORTAL | | | | GROUP | | | +----------+ | | |* | | | | |* |1 |* +----------+ +-------------+ +----------+ +-----------+ | FC |1 *| STORAGE |* *| DISCOVERY|* *| DISCOVERY | | DEVICE |----| NODE |----| DOMAIN |----| DOMAIN | | | | | | | | SET | +----------+ +-------------+ +----------+ +-----------+ * represents 0 to many possible relationships Gibbons, et al. Standards Track [Page 4] RFC 4939 iSNS MIB July 2007 3.2. iSNS MIB Structure The MIB is divided into sections for iSNS server information, iSNS server registered objects information, and iSNS notifications. +--------------+ +--------------+ | MANAGED iSNS |1 *| CONTROL NODE | | SERVER |----| INFO | | INFO | +--------------+ +--------------+ |1 |1 | | +--------------+ | | *| DDS AND DD | | +------| INFO | | | | | +--------------+ | | +-------------+ | *| REGISTERED | +------------| ENTITIES | | INFO | +-------------+ +-----------------+ | iSNS | | NOTIFICATION | | INFO | +-----------------+ The sections that are required to implement are for iSNS Server management and notification. 3.3. iSNS Server Info The isnsServerInfo section provides the ability to monitor multiple iSNS Server instances. The isnsServerTable table provides information on each server instance. This table is indexed by the variable isnsServerIndex. The table indicates current settings for each iSNS server being managed. The network address, TCP and UDP ports being used by a server for iSNSP registrations and queries can be determined from this table. The count of objects registered in each iSNS server instance is shown in the table isnsNumObjectsTable. The provides a summary of the number Discovery Domain Sets, Discovery Domains, Entities, Portals, Portal Groups, iSCSI Nodes, and iFCP FC Nodes and Ports. Gibbons, et al. Standards Track [Page 5] RFC 4939 iSNS MIB July 2007 3.3.1. Control Node Information As defined in the iSNS specification, Control Nodes are objects that have been registered with the server and are allowed to manage the iSNS server. These Control Nodes are identified by their iSCSI Node Name or iFCP FC Port Name. The isnsControlNodeInfo section of the MIB provides the ability to view the currently registered set of iSCSI and iFCP control nodes. 3.3.2. Discovery Domain Set (DDS) The isnsDdsInfo section provides information on each registered DDS, the Discovery Domain members of each DDS, for each iSNS Server instance being managed. DDSs provide a method to group multiple Discovery Domains for easier control. As described in the iSNS Specification [RFC4171], a DDS can be enabled or disabled, which in turn enables or disables the member Discovery Domains. Discovery Domains that are contained in an enabled DDS are then enforced by an iSNS Server. 3.3.3. Discovery Domain (DD) The isnsDdInfo section provides information on each registered DD, and the DD members, for each iSNS Server instance being managed. DDs are collections of storage nodes and portals that are allowed to discover one another. DD members can be iSCSI nodes, Entity Portals, or iFCP nodes. 3.3.4. Registered Storage Objects The isnsReg section provides information on the registered storage objects for a specific iSNS Server instance. This section is divided into subsections for Entities, Portals, and iSCSI Nodes, as well as iFCP Port and Node information. 3.3.4.1. Registered Entities The isnsRegEntityInfo section provides information on the registered entities. Entities are collections of storage nodes and portals. 3.3.4.2. Registered Portals The isnsRegPortalInfo section provides information on the registered portals for a specific iSNS Server instance. Portals are logical IP-Address, TCP/UDP Port pairs that provide access to storage nodes contained in the associated Entity. Gibbons, et al. Standards Track [Page 6] RFC 4939 iSNS MIB July 2007 3.3.4.3. Registered Portal Groups The isnsRegPortalGroupInfo section provides information on the registered portal groups for a specific iSNS Server instance. As described in iSCSI [RFC3720], Portal Groups provide a mapping between Portals and iSCSI Storage Nodes contained in an Entity. 3.3.4.4. Registered iSCSI Nodes The isnsRegIscsiNodeInfo section provides information on the registered iSCSI Nodes for a specific iSNS Server instance. The iSCSI nodes are individual storage targets or initiators. 3.3.4.5. Registered FC Ports The isnsRegFcPortInfo section provides information on the registered FC Ports for a specific iSNS Server instance. The FC Ports are ports associated with an iFCP gateway. 3.3.4.6. Registered FC Nodes The isnsRegFcNodeInfo section provides information on the registered FC Nodes for a specific iSNS Server instance. The FC nodes are individual storage devices associated with an iFCP gateway. 3.4. Multiple Server Instances The management of multiple instances of iSNS servers by the agent is supported. As described in Section 3.3, each managed iSNS server instance has an entry in the table isnsServerTable. 3.5. iSNS Notifications The isnsNotification section provides SNMP notifications for iSNS Server state changes. 4. MIB References The following MIB module has IMPORTS from [RFC2578], [RFC2579], [RFC2580], [RFC3411], [RFC4001], [RFC4044], and [RFC4133]. In REFERENCE clauses, it also refers to [RFC3720], [RFC4171], and [RFC4172]. Gibbons, et al. Standards Track [Page 7] RFC 4939 iSNS MIB July 2007 5. MIB Module ISNS-MIB DEFINITIONS ::= BEGIN IMPORTS -- From RFC 2578 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Gauge32, mib-2 FROM SNMPv2-SMI -- From RFC 2579 TEXTUAL-CONVENTION, TimeStamp, TruthValue FROM SNMPv2-TC -- From RFC 2580 OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF -- From RFC 3411 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- From RFC 4001 InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- From RFC 4044 FcNameIdOrZero, FcAddressIdOrZero FROM FC-MGMT-MIB -- From RFC 4133 PhysicalIndex FROM ENTITY-MIB ; isnsMIB MODULE-IDENTITY LAST-UPDATED "200707110000Z" Gibbons, et al. Standards Track [Page 8] RFC 4939 iSNS MIB July 2007 ORGANIZATION "IETF IPS Working Group" CONTACT-INFO " Attn: Kevin Gibbons 2Wire, Inc. 1704 Automation Parkway San Jose, CA 95131 USA Tel: +1 408-895-1387 Fax: +1 408-428-9590 Email: kgibbons@yahoo.com G.D. Ramkumar SnapTell, Inc. 2741 Middlefield Rd, Suite 200 Palo Alto, CA 94306 USA Tel: +1 650-326-7627 Fax: +1 650-326-7620 Email: gramkumar@stanfordalumni.org Scott Kipp Brocade 4 McDATA Pkwy Broomfield, CO 80021 USA Tel: +1 720-558-3452 Fax: +1 720-558-8999 Email: skipp@brocade.com " DESCRIPTION "This module defines management information specific to internet Storage Name Service (iSNS) management. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4939; see the RFC itself for full legal notices." REVISION "200707110000Z" DESCRIPTION "Initial version of iSNS Management Module. This MIB published as RFC 4939." ::= { mib-2 163 } Gibbons, et al. Standards Track [Page 9] RFC 4939 iSNS MIB July 2007 -- -- Textual Conventions -- IsnsDiscoveryDomainSetId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The unique Discovery Domain Set Identifier associated with a Discovery Domain Set (DDS)." REFERENCE "RFC 4171, Section 6.11.1.1" SYNTAX Unsigned32 ( 1 .. 4294967295 ) IsnsDdsStatusType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The status of a Discovery Domain Set (DDS) registered in the iSNS. The initially assigned values are below: Bit Status --------- --------- 31 DDS Enabled All others RESERVED Setting a bit to 1 indicates the feature is enabled. Otherwise, it is disabled. The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.11.1.3" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), reserved24(24), reserved25(25), reserved26(26), reserved27(27), reserved28(28), reserved29(29), reserved30(30), ddsEnabled (31) } IsnsDiscoveryDomainId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The unique Discovery Domain Identifier (DD_ID) associated Gibbons, et al. Standards Track [Page 10] RFC 4939 iSNS MIB July 2007 with each Discovery Domain (DD). This is used to uniquely index and reference a DD." REFERENCE "RFC 4171, Section 6" SYNTAX Unsigned32 ( 1 .. 4294967295 ) IsnsDdFeatureType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type defines the features that each Discovery Domain (DD) has. Bit Status --------- --------- 31 Boot List All others RESERVED Boot List: this feature indicates that the targets in this DD provide boot capabilities for the member initiators. Setting a bit to 1 indicates the feature is enabled. Otherwise, it is disabled. The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.11.2.9" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), reserved24(24), reserved25(25), reserved26(26), reserved27(27), reserved28(28), reserved29(29), reserved30(30), bootlist(31) } IsnsDdDdsModificationType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The methods that can be used to modify the Discovery Domain and Discovery Domain Sets in an iSNS Server instance. Bit Flag Description --------- ------------------------------------ 0 Control Nodes are allowed Gibbons, et al. Standards Track [Page 11] RFC 4939 iSNS MIB July 2007 1 Target iSCSI Nodes are allowed 2 Initiator iSCSI Nodes are allowed 3 Target iFCP Ports are allowed 4 Initiator iFCP Ports are allowed Setting a bit to 1 indicates the feature is enabled. Otherwise, it is disabled." REFERENCE "RFC 4171, Section 2.4" SYNTAX BITS { controlNode(0), targetIscsiNode(1), initiatorIscsiNode(2), targetIfcpNode(3), initiatorIfcpNode(4) } IsnsEntityIndexIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The identifier for the unique integer Entity Index associated with an iSNS registered Entity object, and the value zero. The value zero is object-specific and MUST therefore be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the Entity is unknown, or not yet registered in the iSNS server. If a value of zero is not valid for an object, then that MUST be indicated." REFERENCE "RFC 4171, Section 6" SYNTAX Unsigned32 ( 0 .. 4294967295 ) IsnsPortalGroupIndexId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The identifier for the unique integer Portal Group Index associated with an iSNS registered Portal Group object." REFERENCE "RFC 4171, Section 6" SYNTAX Unsigned32 ( 1 .. 4294967295 ) IsnsPortalIndexId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The identifier for the unique integer Portal Index associated with an iSNS registered Portal object. The index is created by the iSNS Server for mapping between Gibbons, et al. Standards Track [Page 12] RFC 4939 iSNS MIB July 2007 registered objects. The Portal Index used for a specific portal IP-address and port number pair is only persistent across reboots for portals that have been explicitly added to a Discovery Domain (DD). If a portal is not explicitly registered in any DD, then the index used for a portal can change after a server reinitialization." REFERENCE "RFC 4171, Section 6" SYNTAX Unsigned32 ( 1 .. 4294967295 ) IsnsPortalPortTypeId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The UDP or TCP port type being used by a Portal for an Entity." REFERENCE "RFC 4171, Section 6.3.2" SYNTAX INTEGER { udp(1), tcp(2) } IsnsPortalGroupTagIdOrNull ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The Portal Group Tag (PGT) represents an association between a Portal and iSCSI Node using the value range 0 to 65535. A PGT with no association is a NULL value. The value of -1 indicates a NULL value." REFERENCE "RFC 4171, Section 6.5.4, and RFC 3720" SYNTAX Integer32 ( -1 .. 65535 ) IsnsPortalSecurityType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates security attribute settings for a Portal that is registered in the iSNS server. The bitmapVALID field must be set in order for the contents to be considered valid information. The definitions of the bit fields are based on RFC 4171. The initial representation of each bit setting (0 or 1) is indicated below. Bit Flag Description --------- ------------------------------------ 25 1 = Tunnel Mode Preferred; 0 = No Preference 26 1 = Transport Mode Preferred; 0 = No Preference 27 1 = PFS Enabled; 0 = PFS Disabled 28 1 = Aggressive Mode Enabled; 0 = Disabled 29 1 = Main Mode Enabled; 0 = MM Disabled 30 1 = IKE/IPsec Enabled; 0 = IKE/IPsec Disabled 31 1 = Bitmap VALID; 0 = INVALID Gibbons, et al. Standards Track [Page 13] RFC 4939 iSNS MIB July 2007 All others RESERVED The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.3.9" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), reserved24(24), tunnelModePreferred(25), transportModePreferred(26), pfsEnabled(27), agressiveModeEnabled(28), mainModeEnabled(29), ikeIPsecEnabled(30), bitmapVALID(31) } IsnsNodeIndexId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The identifier for the unique integer Node Index associated with a storage node. This index provides a 1-to-1 mapping to an iSCSI node name. The iSCSI node name maximum length is too long to be used for an index directly. The iSCSI node index used for a specific iSCSI node name is identical in all DDs, and is persistent across server reinitializations when the iSCSI node is a member of a Discovery Domain (DD) or is registered as a Control Node. Furthermore, index values for recently deregistered objects SHOULD NOT be reused in the short term." REFERENCE "RFC 4171, Section 6.4.5" SYNTAX Unsigned32 ( 1 .. 4294967295 ) IsnsIscsiNodeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The iSCSI Node Type defines the functions of the registered object. The definitions of each setting are defined in RFC 4171. Bit Node Type Gibbons, et al. Standards Track [Page 14] RFC 4939 iSNS MIB July 2007 --------- --------- 29 Control 30 Initiator 31 Target All others RESERVED Setting a bit to 1 indicates the node has the corresponding characteristics. The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.4.2" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), reserved24(24), reserved25(25), reserved26(26), reserved27(27), reserved28(28), control(29), initiator(30), target(31) } IsnsFcClassOfServiceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This defines the Fibre Channel Class of Service types that are supported by the registered port. The definitions are as defined in RFC 4171. Bit FC COS Type --------- ---------------- 28 Fibre Channel Class 3 Supported 29 Fibre Channel Class 2 Supported All others RESERVED Setting a bit to 1 indicates the class of service is supported. The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.6.8" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), Gibbons, et al. Standards Track [Page 15] RFC 4939 iSNS MIB July 2007 reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), reserved24(24), reserved25(25), reserved26(26), reserved27(27), class3(28), class2(29) } IsnsIscsiScnType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The iSCSI Node State Change Notification (SCN) values for a node as defined in RFC 4171. Bit Description ------------ ---------------- 24 Initiator and self information only 25 Target and self information only 26 Management registration/SCN 27 Object removed 28 Object added 29 Object updated 30 DD or DDS member removed (Mgmt Reg/SCN only) 31 (Lsb) DD or DDS member added (Mgmt Reg/SCN only) All others Reserved Setting a bit to 1 indicates that type of SCN is enabled. The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.4.4" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), initiatorAndSelfOnly(24), targetAndSelfOnly(25), managementRegistrationScn(26), objectRemoved(27), objectAdded(28), Gibbons, et al. Standards Track [Page 16] RFC 4939 iSNS MIB July 2007 objectUpdated(29), ddOrDdsMemberRemoved(30), ddOrDdsMemberAdded(31) } IsnsIfcpScnType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The iFCP State Change Notification (SCN) values for an iFCP object as defined in RFC 4171. Bit Description ------------ ---------------- 24 Initiator and self information only 25 Target and self information only 26 Management registration/SCN 27 Object removed 28 Object added 29 Object updated 30 DD or DDS member removed (Mgmt Reg/SCN only) 31 (Lsb) DD or DDS member added (Mgmt Reg/SCN only) All others Reserved Setting a bit to 1 indicates that type of SCN is enabled. The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.6.12" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), initiatorAndSelfOnly(24), targetAndSelfOnly(25), managementRegistrationScn(26), objectRemoved(27), objectAdded(28), objectUpdated(29), ddOrDdsMemberRemoved(30), ddOrDdsMemberAdded(31) } IsnsFcPortRoleType ::= TEXTUAL-CONVENTION Gibbons, et al. Standards Track [Page 17] RFC 4939 iSNS MIB July 2007 STATUS current DESCRIPTION "The FC Port Role defines the functions of the registered object. The definitions of each setting are defined in RFC 4171. Bit Port Role --------- --------- 29 Control 30 FCP Initiator 31 FCP Target All others RESERVED Setting a bit to 1 indicates the port has the corresponding characteristics. The future assignment of any of the reserved values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.6.13" SYNTAX BITS { reserved0(0), reserved1(1), reserved2(2), reserved3(3), reserved4(4), reserved5(5), reserved6(6), reserved7(7), reserved8(8), reserved9(9), reserved10(10), reserved11(11), reserved12(12), reserved13(13), reserved14(14), reserved15(15), reserved16(16), reserved17(17), reserved18(18), reserved19(19), reserved20(20), reserved21(21), reserved22(22), reserved23(23), reserved24(24), reserved25(25), reserved26(26), reserved27(27), reserved28(28), control(29), initiator(30), target(31) } IsnsSrvrDiscoveryMethodsType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The types of iSNS Server discovery methods that are enabled on an iSNS Server. The options are DHCP, Service Location Protocol (SLP), multicast group iSNS heartbeat, broadcast group iSNS heartbeat, configured server list, and other. The iSNS Server may support additional discovery methods not indicated." REFERENCE "RFC 4171, Section 2.5" SYNTAX BITS { dhcp(0), slp(1), multicastGroupHb(2), broadcastHb(3), Gibbons, et al. Standards Track [Page 18] RFC 4939 iSNS MIB July 2007 cfgdServerList(4), other(5) } -- -- Internet Storage Name Service Management -- isnsNotifications OBJECT IDENTIFIER ::= { isnsMIB 0 } isnsObjects OBJECT IDENTIFIER ::= { isnsMIB 1 } isnsConformance OBJECT IDENTIFIER ::= { isnsMIB 2 } -- -- iSNS Server instance managed objects -------------------- -- isnsServerInfo OBJECT IDENTIFIER ::= { isnsObjects 1 } isnsServerTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a list of the iSNS Server instances that are managed through the same SNMP context." ::= { isnsServerInfo 1 } isnsServerEntry OBJECT-TYPE SYNTAX IsnsServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a row in the iSNS Server instance table. The number of rows is dependent on the number of iSNS Server instances that are being managed through the same SNMP context." INDEX { isnsServerIndex } ::= { isnsServerTable 1 } IsnsServerEntry ::= SEQUENCE { isnsServerIndex Unsigned32, isnsServerName SnmpAdminString, isnsServerIsnsVersion Unsigned32, isnsServerVendorInfo SnmpAdminString, Gibbons, et al. Standards Track [Page 19] RFC 4939 iSNS MIB July 2007 isnsServerPhysicalIndex PhysicalIndex, isnsServerTcpPort InetPortNumber, isnsServerUdpPort InetPortNumber, isnsServerDiscontinuityTime TimeStamp, isnsServerRole INTEGER, isnsServerDiscoveryMethodsEnabled IsnsSrvrDiscoveryMethodsType, isnsServerDiscoveryMcGroupType InetAddressType, isnsServerDiscoveryMcGroupAddress InetAddress, isnsServerEsiNonResponseThreshold Unsigned32, isnsServerEnableControlNodeMgtScn TruthValue, isnsServerDefaultDdDdsStatus INTEGER, isnsServerUpdateDdDdsSupported IsnsDdDdsModificationType, isnsServerUpdateDdDdsEnabled IsnsDdDdsModificationType } isnsServerIndex OBJECT-TYPE SYNTAX Unsigned32 ( 1 .. 4294967295 ) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies the iSNS Server being managed by the SNMP context and is the key for this table. This is an instance index for each iSNS Server being managed. The value of this object is used elsewhere in the MIB to reference specific iSNS Servers." ::= { isnsServerEntry 1 } isnsServerName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A non-unique name that can be assigned to the iSNS Server instance. If not configured, then the string SHALL be zero-length." ::= { isnsServerEntry 2 } isnsServerIsnsVersion OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) Gibbons, et al. Standards Track [Page 20] RFC 4939 iSNS MIB July 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The iSNS version value as contained in messages received from the current primary server. The header of each iSNSP message contains the iSNS version of the sender. If unknown, the reported value is 0." REFERENCE "RFC 4171" DEFVAL { 1 } ::= { isnsServerEntry 3 } isnsServerVendorInfo OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "If this server instance is utilizing the product of a particular 'vendor', then this managed object contains that vendor's name and version. Otherwise, the string SHALL be zero-length. The format of the string is as follows: Vendor Name, Vendor Version, Vendor Defined Information. Field Description --------- ---------------- Vendor Name The name of the vendor (if one exists) Vendor Version The version of the vendor product Vendor Defined This follows the second comma in the string, if one exists, and is vendor defined " ::= { isnsServerEntry 4 } isnsServerPhysicalIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "An index identifying the network interface for this iSNS Server within a network entity. This index maps to the entPhysicalIndex of entPhysicalTable table in RFC 4133. The entPhysicalClass value for the table row must be 'port', as the interface must be able to send and receive data." REFERENCE "RFC 4133, RFC 4171, Section 2.5 - 2.8" ::= { isnsServerEntry 5 } isnsServerTcpPort OBJECT-TYPE SYNTAX InetPortNumber Gibbons, et al. Standards Track [Page 21] RFC 4939 iSNS MIB July 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the TCP port this iSNS instance is accepting iSNSP messages on, generally the iSNS well-known port. The well-known TCP port for iSNSP is 3205. If TCP is not supported by this server instance, then the value is 0." ::= { isnsServerEntry 6 } isnsServerUdpPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the UDP port this iSNS instance is accepting iSNSP messages on; generally, the iSNS well-known port. The well-known UDP port for iSNSP is 3205. If UDP is not supported by this server instance, then the value is 0." ::= { isnsServerEntry 7 } isnsServerDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion that this iSNS server became active or suffered a discontinuity." ::= { isnsServerEntry 8 } isnsServerRole OBJECT-TYPE SYNTAX INTEGER { notSet(1), server(2), backupServer(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational mode of this iSNS Server instance. Value Description --------- ---------------- notSet The iSNS Server role is not configured. server The iSNS Server instance is an operational iSNS Server. backupServer The iSNS Server instance is Gibbons, et al. Standards Track [Page 22] RFC 4939 iSNS MIB July 2007 currently acting as a backup." REFERENCE "RFC 4171, Section 2.7 - 2.8" ::= { isnsServerEntry 9 } isnsServerDiscoveryMethodsEnabled OBJECT-TYPE SYNTAX IsnsSrvrDiscoveryMethodsType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the discovery methods currently enabled for this iSNS Server instance. This allows a client to determine what discovery methods can be used for this iSNS Server. Additional methods of discovery may also be supported." ::= { isnsServerEntry 10 } isnsServerDiscoveryMcGroupType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet address in isnsServerDiscoveryMcGroupAddress. If the address is specified, then it must be a valid multicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsServerDiscoveryMcGroupAddress is the zero-length string." ::= { isnsServerEntry 11 } isnsServerDiscoveryMcGroupAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The multicast group that iSNS Heartbeat messages are sent to if multicast-based discovery has been enabled for this server instance. If not configured, then the string SHALL be zero-length. The format of this object is specified by isnsServerDiscoveryMcGroupType." ::= { isnsServerEntry 12 } isnsServerEsiNonResponseThreshold OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "Entity Status Inquiry (ESI) Non-Response Threshold - Gibbons, et al. Standards Track [Page 23] RFC 4939 iSNS MIB July 2007 the number of ESI messages that will be sent without receiving a response before an entity is deregistered from the iSNS database. A value of 0 indicates Entities will never be deregistered due to non-receipt of ESI messages." REFERENCE "RFC 4171, Section 2.4" DEFVAL { 3 } ::= { isnsServerEntry 13 } isnsServerEnableControlNodeMgtScn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates if the iSNS Server administrative option to send Management SCNs to Control Nodes is enabled. Management SCNs are used by Control Nodes to monitor and control an iSNS Server. If enabled, Control Nodes can register to receive Management SCNs." REFERENCE "RFC 4171, Section 2.2.3, 2.4" DEFVAL { true } ::= { isnsServerEntry 14 } isnsServerDefaultDdDdsStatus OBJECT-TYPE SYNTAX INTEGER { inNoDomain(1), inDefaultDdAndDds(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates the Discovery Domain (DD) and Discovery Domain Set (DDS) membership status for a new device when registered in the iSNS Server instance. Either the new device will not be in a DD/DDS, or will be placed into a default DD and default DDS. The default setting is inNoDomain." REFERENCE "RFC 4171, Section 2.4" DEFVAL { inNoDomain } ::= { isnsServerEntry 15 } isnsServerUpdateDdDdsSupported OBJECT-TYPE SYNTAX IsnsDdDdsModificationType MAX-ACCESS read-only STATUS current DESCRIPTION "The methods that this iSNS Server instance supports to modify Discovery Domains and Discovery Domain Sets." REFERENCE "RFC 4171, Section 2.4" ::= { isnsServerEntry 16 } Gibbons, et al. Standards Track [Page 24] RFC 4939 iSNS MIB July 2007 isnsServerUpdateDdDdsEnabled OBJECT-TYPE SYNTAX IsnsDdDdsModificationType MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates the methods this server instance currently allows for modifying Discovery Domains and Discovery Domain Sets." REFERENCE "RFC 4171, Sec 2.2.2 and 2.4" ::= { isnsServerEntry 17 } -- -- Count of objects currently registered in a server instance -- isnsNumObjectsTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsNumObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table providing the number of registered objects of each type in the iSNS Server instance. The number of entries is dependent upon the number of iSNS Server instances being managed." ::= { isnsServerInfo 2 } isnsNumObjectsEntry OBJECT-TYPE SYNTAX IsnsNumObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry of an iSNS Server instance." AUGMENTS { isnsServerEntry } ::= { isnsNumObjectsTable 1 } IsnsNumObjectsEntry ::= SEQUENCE { isnsNumDds Gauge32, isnsNumDd Gauge32, isnsNumEntities Gauge32, isnsNumPortals Gauge32, isnsNumPortalGroups Gauge32, isnsNumIscsiNodes Gauge32, isnsNumFcPorts Gauge32, isnsNumFcNodes Gauge32 } Gibbons, et al. Standards Track [Page 25] RFC 4939 iSNS MIB July 2007 isnsNumDds OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Discovery Domain Sets in this iSNS instance. This is the number of rows in the isnsDdsTable." ::= { isnsNumObjectsEntry 1 } isnsNumDd OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Discovery Domains in this iSNS instance. This is the number of rows in the isnsDdTable." ::= { isnsNumObjectsEntry 2 } isnsNumEntities OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of Entities registered in this iSNS Server instance. This is the number of rows in the isnsRegEntityTable for this instance." ::= { isnsNumObjectsEntry 3 } isnsNumPortals OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Portals registered in iSNS. This is the number of rows in isnsRegPortalTable." ::= { isnsNumObjectsEntry 4 } isnsNumPortalGroups OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of Portal Groups registered in iSNS. This is the number of rows in isnsRegPgTable." ::= { isnsNumObjectsEntry 5 } Gibbons, et al. Standards Track [Page 26] RFC 4939 iSNS MIB July 2007 isnsNumIscsiNodes OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of iSCSI node entries registered in the iSNS. This is the number rows in isnsRegIscsiNodeTable." ::= { isnsNumObjectsEntry 6 } isnsNumFcPorts OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of FC Port entries registered in the iSNS. This is the number of rows in isnsRegFcPortTable." ::= { isnsNumObjectsEntry 7 } isnsNumFcNodes OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The current total number of FC node entries registered in the iSNS. This is the number of rows in isnsRegFcNodeTable." ::= { isnsNumObjectsEntry 8 } -- -- Control node information -- isnsControlNodeInfo OBJECT IDENTIFIER ::= { isnsServerInfo 3 } -- -- Specific iSCSI Nodes authorized to register as Control -- Nodes -- isnsControlNodeIscsiTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsControlNodeIscsiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Gibbons, et al. Standards Track [Page 27] RFC 4939 iSNS MIB July 2007 "Specified iSCSI Nodes that can register or are registered as control nodes. The number of rows is dependent on the number of iSCSI Control Nodes." ::= { isnsControlNodeInfo 1 } isnsControlNodeIscsiEntry OBJECT-TYPE SYNTAX IsnsControlNodeIscsiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an iSCSI Control Node entry for a specific iSNS server instance." INDEX { isnsServerIndex, isnsControlNodeIscsiNodeIndex } ::= { isnsControlNodeIscsiTable 1 } IsnsControlNodeIscsiEntry ::= SEQUENCE { isnsControlNodeIscsiNodeIndex IsnsNodeIndexId, isnsControlNodeIscsiNodeName SnmpAdminString, isnsControlNodeIscsiIsRegistered TruthValue, isnsControlNodeIscsiRcvMgtSCN TruthValue } isnsControlNodeIscsiNodeIndex OBJECT-TYPE SYNTAX IsnsNodeIndexId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for the iSCSI storage node authorized to act as a control node." ::= { isnsControlNodeIscsiEntry 1 } isnsControlNodeIscsiNodeName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The iSCSI Name of the initiator or target associated with the storage node. The iSCSI Name cannot be longer than 223 bytes. The iSNS Server internal maximum size is 224 bytes to provide NULL termination. This is the iSCSI Node Name for the storage node authorized and/or acting as a control node." ::= { isnsControlNodeIscsiEntry 2 } isnsControlNodeIscsiIsRegistered OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only Gibbons, et al. Standards Track [Page 28] RFC 4939 iSNS MIB July 2007 STATUS current DESCRIPTION "Indicates whether the control node is currently registered in the iSNS Server instance." ::= { isnsControlNodeIscsiEntry 3 } isnsControlNodeIscsiRcvMgtSCN OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the Control Node has registered to receive Management SCNs. Management SCNs are sent to a Control Node if they are enabled, as indicated by isnsServerEnableControlNodeMgtScn, and the Control Node has registered for them." REFERENCE "RFC 4171, Section 2.2.3, 2.4" ::= { isnsControlNodeIscsiEntry 4 } -- -- Specific FC Ports authorized to register as Control -- Nodes -- isnsControlNodeFcPortTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsControlNodeFcPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specified FC Ports that can register or are registered as control nodes. The number of rows is dependent on the number of FC Port Control Nodes." ::= { isnsControlNodeInfo 2 } isnsControlNodeFcPortEntry OBJECT-TYPE SYNTAX IsnsControlNodeFcPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "FC Port control node entry." INDEX { isnsServerIndex, isnsControlNodeFcPortWwpn } ::= { isnsControlNodeFcPortTable 1 } IsnsControlNodeFcPortEntry ::= SEQUENCE { isnsControlNodeFcPortWwpn FcNameIdOrZero, isnsControlNodeFcPortIsRegistered TruthValue, Gibbons, et al. Standards Track [Page 29] RFC 4939 iSNS MIB July 2007 isnsControlNodeFcPortRcvMgtSCN TruthValue } isnsControlNodeFcPortWwpn OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FC Port World Wide Port Name that can and/or is acting as a Control Node for the specified iSNS Server. A zero- length string is not valid for this managed object. This managed object, combined with the isnsServerIndex, is the key for this table." ::= { isnsControlNodeFcPortEntry 1 } isnsControlNodeFcPortIsRegistered OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the control node is currently registered in the iSNS Server instance." ::= { isnsControlNodeFcPortEntry 2 } isnsControlNodeFcPortRcvMgtSCN OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the Control Node has registered to receive Management SCNs. Management SCNs are sent to a Control Node if they are enabled, as indicated by isnsServerEnableControlNodeMgtScn, and the Control Node has registered for them." REFERENCE "RFC 4171, Section 2.2.3, 2.4" ::= { isnsControlNodeFcPortEntry 3 } -- -- Discovery Domain Set information -- isnsDdsInfo OBJECT IDENTIFIER ::= { isnsServerInfo 4 } -- -- Discovery Domain Set Registrations ----------------- -- isnsDdsTable OBJECT-TYPE Gibbons, et al. Standards Track [Page 30] RFC 4939 iSNS MIB July 2007 SYNTAX SEQUENCE OF IsnsDdsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing configuration information for each Discovery Domain Set (DDS) registered in the iSNS Server instance. The number of rows in the table is dependent on the number of DDSs registered in the specified iSNS server instance." ::= { isnsDdsInfo 1 } isnsDdsEntry OBJECT-TYPE SYNTAX IsnsDdsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one Discovery Domain Set (DDS) registered in the iSNS Server instance." INDEX { isnsServerIndex, isnsDdsId} ::= { isnsDdsTable 1 } IsnsDdsEntry ::= SEQUENCE { isnsDdsId IsnsDiscoveryDomainSetId, isnsDdsSymbolicName SnmpAdminString, isnsDdsStatus IsnsDdsStatusType } isnsDdsId OBJECT-TYPE SYNTAX IsnsDiscoveryDomainSetId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ID that refers to this Discovery Domain Set and index to the table." ::= { isnsDdsEntry 1 } isnsDdsSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The Discovery Domain Set Symbolic Name field contains a unique variable-length description (up to 255 bytes) that is associated with the DDS. If a Symbolic Name is not provided, then one will be generated by the iSNS server." REFERENCE "RFC 4171, Section 6" Gibbons, et al. Standards Track [Page 31] RFC 4939 iSNS MIB July 2007 ::= { isnsDdsEntry 2 } isnsDdsStatus OBJECT-TYPE SYNTAX IsnsDdsStatusType MAX-ACCESS read-only STATUS current DESCRIPTION "The status of this Discovery Domain Set (DDS)." REFERENCE "RFC 4171, Section 6.11.1.3" ::= { isnsDdsEntry 3 } -- -- Discovery Domain Set Members -------------------- -- -- -- DDS Membership Assignment -- isnsDdsMemberTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsDdsMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Discovery Domains (DDs) that have been assigned to specific Discovery Domain Sets (DDSs). The number of rows in the table is dependent on the number of DD to DDS relationships in the iSNS instance." ::= { isnsDdsInfo 2 } isnsDdsMemberEntry OBJECT-TYPE SYNTAX IsnsDdsMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mapping of one Discovery Domain (DD) to a Discovery Domain Set (DDS). This indicates the DD is a member of the DDS." INDEX { isnsServerIndex, isnsDdsId, isnsDdsMemberDdId } ::= { isnsDdsMemberTable 1 } IsnsDdsMemberEntry ::= SEQUENCE { isnsDdsMemberDdId IsnsDiscoveryDomainId, isnsDdsMemberSymbolicName SnmpAdminString Gibbons, et al. Standards Track [Page 32] RFC 4939 iSNS MIB July 2007 } isnsDdsMemberDdId OBJECT-TYPE SYNTAX IsnsDiscoveryDomainId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ID that identifies the Discovery Domain that is a member of the Discovery Domain Set." ::= { isnsDdsMemberEntry 1 } isnsDdsMemberSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The Symbolic Name of the Discovery Domain that is a member of this DDS. This value SHALL be identical to the object isnsDdSymbolicName for the associated DD ID." REFERENCE "RFC 4171, Section 6" ::= { isnsDdsMemberEntry 2 } -- -- Discovery Domain information -- isnsDdInfo OBJECT IDENTIFIER ::= { isnsServerInfo 5 } -- -- Discovery Domain Registrations ------------------------ -- isnsDdTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsDdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing configuration information for each Discovery Domain (DD) registered in the iSNS. The number of rows in the table is dependent on the number of DDs registered in the iSNS instance." ::= { isnsDdInfo 1 } isnsDdEntry OBJECT-TYPE SYNTAX IsnsDdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Gibbons, et al. Standards Track [Page 33] RFC 4939 iSNS MIB July 2007 "Information on a Discovery Domain (DD) registered in the iSNS Server instance." INDEX { isnsServerIndex, isnsDdId} ::= { isnsDdTable 1 } IsnsDdEntry::= SEQUENCE { isnsDdId IsnsDiscoveryDomainId, isnsDdSymbolicName SnmpAdminString, isnsDdFeatures IsnsDdFeatureType } isnsDdId OBJECT-TYPE SYNTAX IsnsDiscoveryDomainId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ID that refers to this Discovery Domain, and the index to the table." REFERENCE "RFC 4171, Section 6" ::= { isnsDdEntry 1 } isnsDdSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The Discovery Domain Symbolic Name field contains a unique variable-length description (up to 255 bytes) that is associated with the DD." REFERENCE "RFC 4171, Section 6" ::= { isnsDdEntry 2 } isnsDdFeatures OBJECT-TYPE SYNTAX IsnsDdFeatureType MAX-ACCESS read-only STATUS current DESCRIPTION "This defines the features the Discovery Domain has." REFERENCE "RFC 4171, Section 6.11.2.9" ::= { isnsDdEntry 3 } Gibbons, et al. Standards Track [Page 34] RFC 4939 iSNS MIB July 2007 -- -- Discovery Domain Members -------------------- -- -- -- DD iSCSI Node Membership Assignment -- isnsDdIscsiMemberTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsDdIscsiMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing iSCSI node indexes that have been assigned to specific DDs in this iSNS Server instance. The number of rows in the table is dependent on the number of relationships between iSCSI Nodes and DDs registered in the iSNS instance." ::= { isnsDdInfo 2 } isnsDdIscsiMemberEntry OBJECT-TYPE SYNTAX IsnsDdIscsiMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mapping of one iSCSI Node to a Discovery Domain to indicate membership in the DD. The indexes are the iSNS server instance, the DD ID of the Discovery Domain, and the iSCSI Node Index of the iSCSI Node." INDEX { isnsServerIndex, isnsDdId, isnsDdIscsiMemberIndex } ::= { isnsDdIscsiMemberTable 1 } IsnsDdIscsiMemberEntry::= SEQUENCE { isnsDdIscsiMemberIndex IsnsNodeIndexId, isnsDdIscsiMemberName SnmpAdminString, isnsDdIscsiMemberIsRegistered TruthValue } isnsDdIscsiMemberIndex OBJECT-TYPE SYNTAX IsnsNodeIndexId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this member iSCSI node entry." Gibbons, et al. Standards Track [Page 35] RFC 4939 iSNS MIB July 2007 REFERENCE "RFC 4171, Section 6" ::= { isnsDdIscsiMemberEntry 1 } isnsDdIscsiMemberName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..223)) MAX-ACCESS read-only STATUS current DESCRIPTION "The iSCSI Name associated with the storage node. The iSCSI Name cannot be longer than 223 bytes. The iSNS server internal maximum size is 224 bytes to provide NULL termination. This is the iSCSI Name for the storage node that is a member of the DD. This value maps 1 to 1 to the isnsDdIscsiMemberIndex node index. The iSCSI Name field is too long to be easily used for an index directly. The node index used for a specific node name is only persistent across iSNS Server reinitializations for nodes that are in a Discovery Domain (DD) or are registered control nodes. This value is only required during row creation if the storage node is not yet registered in the iSNS Server instance. If the storage node is not yet registered, then the iSCSI Name MUST be provided with the iSCSI node index during row creation in order to create the 1-to-1 mapping." REFERENCE "RFC 4171, Section 6" ::= { isnsDdIscsiMemberEntry 2 } isnsDdIscsiMemberIsRegistered OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates whether this member of the DD is currently registered in the iSNS Server instance. iSCSI Storage Node members do not need to be currently registered in order for their iSCSI Name and Index to be added to a DD." REFERENCE "RFC 4171, Section 6.11" ::= { isnsDdIscsiMemberEntry 3 } -- -- DD Portal Membership Assignment -- isnsDdPortalMemberTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsDdPortalMemberEntry MAX-ACCESS not-accessible Gibbons, et al. Standards Track [Page 36] RFC 4939 iSNS MIB July 2007 STATUS current DESCRIPTION "A table containing currently registered and unregistered portal objects that have been explicitly assigned to specific DDs. Explicit assignment of a portal to a DD is only done when a specific set of portals are preferred for use within a DD. Otherwise, for iSCSI, the Portal Group Object should be used for identifying which portals provide access to which storage nodes. The number of rows in the table is dependent on the number of explicit relationships between portals and DDs registered in the iSNS." REFERENCE "RFC 4171, Section 6" ::= { isnsDdInfo 3 } isnsDdPortalMemberEntry OBJECT-TYPE SYNTAX IsnsDdPortalMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry indicates an explicit addition of a portal to a discovery domain. The explicit addition of an entity portal to a discovery domain indicates the portal is preferred for access to nodes of the entity for this discovery domain. Registered Portal Group objects are used in iSCSI to indicate mapping of portals to nodes across all discovery domains. Portals that have been explicitly mapped to a discovery domain will be returned as part of a query that is scoped to that discovery domain. If no portal of an entity has been explicitly mapped to a discovery domain, then all portals of the entity that provide access to a storage node are returned as part of a query. The table indexes are the server instance, the DD ID of the Discovery Domain, and the Portal Index of the portal." INDEX { isnsServerIndex, isnsDdId, isnsDdPortalMemberIndex } ::= { isnsDdPortalMemberTable 1 } IsnsDdPortalMemberEntry ::= SEQUENCE { isnsDdPortalMemberIndex IsnsPortalIndexId, isnsDdPortalMemberAddressType InetAddressType, isnsDdPortalMemberAddress InetAddress, isnsDdPortalMemberPortType IsnsPortalPortTypeId, isnsDdPortalMemberPort InetPortNumber, isnsDdPortalMemberIsRegistered TruthValue } Gibbons, et al. Standards Track [Page 37] RFC 4939 iSNS MIB July 2007 isnsDdPortalMemberIndex OBJECT-TYPE SYNTAX IsnsPortalIndexId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for a portal explicitly contained in the discovery domain. This managed object, combined with isnsServerIndex and isnsDdId, is the key for this table." REFERENCE "RFC 4171, Section 6" ::= { isnsDdPortalMemberEntry 1 } isnsDdPortalMemberAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet address in isnsDdPortalMemberAddress. If the address is specified, then it must be a valid unicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsDdPortalMemberAddress is the zero-length string." ::= { isnsDdPortalMemberEntry 2 } isnsDdPortalMemberAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Inet Address for the portal. The format of this object is specified by isnsDdPortalMemberAddressType." REFERENCE "RFC 4171, Section 6" ::= { isnsDdPortalMemberEntry 3 } isnsDdPortalMemberPortType OBJECT-TYPE SYNTAX IsnsPortalPortTypeId MAX-ACCESS read-only STATUS current DESCRIPTION "The port type for the portal, either UDP or TCP." REFERENCE "RFC 4171, Section 6" ::= { isnsDdPortalMemberEntry 4 } isnsDdPortalMemberPort OBJECT-TYPE SYNTAX InetPortNumber ( 1 .. 65535 ) MAX-ACCESS read-only STATUS current Gibbons, et al. Standards Track [Page 38] RFC 4939 iSNS MIB July 2007 DESCRIPTION "The port number for the portal. Whether the portal type is TCP or UDP is indicated by isnsDdPortalMemberPortType." REFERENCE "RFC 4171, Section 6" ::= { isnsDdPortalMemberEntry 5 } isnsDdPortalMemberIsRegistered OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates whether this member of the DD is currently registered in the iSNS Server instance. Portals that are DD members do not need to be currently registered in order for them to be added to a DD." REFERENCE "RFC 4171, Section 6.11" ::= { isnsDdPortalMemberEntry 6 } -- -- DD FC Port Membership Assignment -- isnsDdFcPortMemberTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsDdFcPortMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing FC Port World Wide Names (WWN) that have been assigned to specific DDs. The number of rows in the table is dependent on the number of relationships between FC Ports and DDs registered in the iSNS." ::= { isnsDdInfo 4 } isnsDdFcPortMemberEntry OBJECT-TYPE SYNTAX IsnsDdFcPortMemberEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The association of one FC Port with a Discovery Domain. Membership of an FC Port in a Discovery Domain is indicated by creating a row for the appropriate DD ID and FC Port WWN." INDEX { isnsServerIndex, isnsDdId, isnsDdFcPortMemberPortName } ::= { isnsDdFcPortMemberTable 1 } Gibbons, et al. Standards Track [Page 39] RFC 4939 iSNS MIB July 2007 IsnsDdFcPortMemberEntry ::= SEQUENCE { isnsDdFcPortMemberPortName FcNameIdOrZero, isnsDdFcPortMemberIsRegistered TruthValue } isnsDdFcPortMemberPortName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Port WWN of the FC Port that is a member of the DD. The value MUST be a valid FC WWN, as per the FC-GS (Fibre Channel - Generic Services) standard. This managed object, combined with the isnsServerIndex and isnsDdId are the key for this table. A zero-length string is not a valid value for this managed object." REFERENCE "RFC 4171, Section 6" ::= { isnsDdFcPortMemberEntry 1 } isnsDdFcPortMemberIsRegistered OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates whether this member of the DD is currently registered in the iSNS Server instance." REFERENCE "RFC 4171, Section 6.11" ::= { isnsDdFcPortMemberEntry 2 } -- -- Registered Device Information -- isnsReg OBJECT IDENTIFIER ::= { isnsServerInfo 6 } isnsRegEntityInfo OBJECT IDENTIFIER ::= { isnsReg 1 } -- -- iSNS Registered Entities Table -- isnsRegEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegEntityEntry MAX-ACCESS not-accessible STATUS current Gibbons, et al. Standards Track [Page 40] RFC 4939 iSNS MIB July 2007 DESCRIPTION "A table containing registered Entity objects in each iSNS server instance. The number of entries in the table is dependent on the number of Entity objects registered in the iSNS Server instances. All Entity objects are registered in the iSNS using the iSNS protocol." ::= { isnsRegEntityInfo 1 } isnsRegEntityEntry OBJECT-TYPE SYNTAX IsnsRegEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one registered Entity object in an iSNS server instance." INDEX { isnsServerIndex, isnsRegEntityIndex } ::= { isnsRegEntityTable 1 } IsnsRegEntityEntry ::= SEQUENCE { isnsRegEntityIndex IsnsEntityIndexIdOrZero, isnsRegEntityEID SnmpAdminString, isnsRegEntityProtocol Unsigned32, isnsRegEntityManagementAddressType InetAddressType, isnsRegEntityManagementAddress InetAddress, isnsRegEntityTimestamp TimeStamp, isnsRegEntityVersionMin Unsigned32, isnsRegEntityVersionMax Unsigned32, isnsRegEntityRegistrationPeriod Unsigned32 } isnsRegEntityIndex OBJECT-TYPE SYNTAX IsnsEntityIndexIdOrZero ( 1 .. 4294967295 ) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Entity Index for this entity. This index is assigned by the iSNS Server when an Entity is initially registered. The Entity Index can be used to represent a registered Entity object in situations where the Entity EID would be too long/unwieldy. Zero is not a valid value for this object." REFERENCE "RFC 4171, Section 6" Gibbons, et al. Standards Track [Page 41] RFC 4939 iSNS MIB July 2007 ::= { isnsRegEntityEntry 1 } isnsRegEntityEID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The EID is a unique registered Entity object identifier, as specified in the iSNS Specification. This is the iSNS Entity Identifier for the registered Entity object." REFERENCE "RFC 4171, Section 6" ::= { isnsRegEntityEntry 2 } isnsRegEntityProtocol OBJECT-TYPE SYNTAX Unsigned32 ( 1 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The block storage protocol supported by this entity, as defined in the iSNS Specification, Section 6.2.2. The following values are initially assigned. Type Value Entity Type ---------- ----------- 1 No Protocol 2 iSCSI 3 iFCP All Others As assigned by IANA The full set of current Block Storage Protocols are specified in the IANA-maintained registry of assigned iSNS parameters. Please refer to RFC 4171 and the iSNS parameters maintained at IANA." REFERENCE "RFC 4171, Section 6.2.2, and IANA Assignments" ::= { isnsRegEntityEntry 3 } isnsRegEntityManagementAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet address in isnsRegEntityManagementAddress. If the address is specified, then it must be a valid unicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsRegEntityManagementAddress is the zero-length string." ::= { isnsRegEntityEntry 4 } Gibbons, et al. Standards Track [Page 42] RFC 4939 iSNS MIB July 2007 isnsRegEntityManagementAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The iSNS Management IP Address for the registered Entity object. The format of this object is specified by isnsRegEntityManagementAddressType." REFERENCE "RFC 4171, Section 6" ::= { isnsRegEntityEntry 5 } isnsRegEntityTimestamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The iSNS Entity Registration Timestamp for the registered Entity object. This is the most recent date and time that the registered Entity object, and associated registered objects contained in the Entity, were registered or updated." REFERENCE "RFC 4171, Section 6" ::= { isnsRegEntityEntry 6 } isnsRegEntityVersionMin OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 254 | 255 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum version supported for the block storage protocol specified by isnsRegEntityProtocol. The protocol version specified can be from 1 to 254. A value of 255 is a wildcard value, indicating no minimum version value has been specified for this Entity. Entity registrations with an isnsRegEntityProtocol of 'No Protocol' SHALL have an isnsRegEntityVersionMin value of 0." REFERENCE "RFC 4171, Section 6.2.5" ::= { isnsRegEntityEntry 7 } isnsRegEntityVersionMax OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 254 | 255 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum version supported for the block storage protocol specified by isnsRegEntityProtocol. The protocol version specified can be from 1 to 254. A value of 255 is a wildcard Gibbons, et al. Standards Track [Page 43] RFC 4939 iSNS MIB July 2007 value, indicating no maximum version value has been specified for this Entity. Entity registrations with an isnsRegEntityProtocol of 'No Protocol' SHALL have an isnsRegEntityVersionMax value of 0." REFERENCE "RFC 4171, Section 6.2.5" ::= { isnsRegEntityEntry 8 } isnsRegEntityRegistrationPeriod OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 4294967295 ) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The iSNS Entity Status Inquiry (ESI) registration period, which indicates the maximum time, in seconds, that the registration will be maintained without receipt of an iSNSP message from the entity. If the Registration Period is set to 0, then the Entity SHALL NOT be deregistered due to no contact with the entity." REFERENCE "RFC 4171, Section 6" ::= { isnsRegEntityEntry 9 } -- -- Registered Objects Associated With an Entity Information -- isnsRegEntityNumObjectsTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegEntityNumObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information on the number of registered objects associated with a registered Entity in the iSNS server instance. The number of entries in the table is dependent on the number of registered Entity objects in the iSNS." ::= { isnsRegEntityInfo 2 } isnsRegEntityNumObjectsEntry OBJECT-TYPE SYNTAX IsnsRegEntityNumObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on the number of registered objects associated with a registered Entity object in an iSNS Server instance." INDEX { isnsServerIndex, isnsRegEntityIndex } Gibbons, et al. Standards Track [Page 44] RFC 4939 iSNS MIB July 2007 ::= { isnsRegEntityNumObjectsTable 1 } IsnsRegEntityNumObjectsEntry ::= SEQUENCE { isnsRegEntityInfoNumPortals Gauge32, isnsRegEntityInfoNumPortalGroups Gauge32, isnsRegEntityInfoNumIscsiNodes Gauge32, isnsRegEntityInfoNumFcPorts Gauge32, isnsRegEntityInfoNumFcNodes Gauge32 } isnsRegEntityInfoNumPortals OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Portals associated with this Entity." ::= { isnsRegEntityNumObjectsEntry 1 } isnsRegEntityInfoNumPortalGroups OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Portal Groups associated with this Entity." ::= { isnsRegEntityNumObjectsEntry 2 } isnsRegEntityInfoNumIscsiNodes OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of iSCSI Storage Nodes associated with this Entity." ::= { isnsRegEntityNumObjectsEntry 3 } isnsRegEntityInfoNumFcPorts OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC Ports associated with this Entity." ::= { isnsRegEntityNumObjectsEntry 4 } isnsRegEntityInfoNumFcNodes OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current Gibbons, et al. Standards Track [Page 45] RFC 4939 iSNS MIB July 2007 DESCRIPTION "The number of FC Nodes associated with this Entity." ::= { isnsRegEntityNumObjectsEntry 5 } -- -- iSNS Registered Portal Information -- isnsRegPortalInfo OBJECT IDENTIFIER ::= { isnsReg 2 } -- -- iSNS Registered Portal Table -- isnsRegPortalTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegPortalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered Portals in the iSNS. The number of entries is dependent on the number of Portals registered in the iSNS." ::= { isnsRegPortalInfo 1 } isnsRegPortalEntry OBJECT-TYPE SYNTAX IsnsRegPortalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one registered Entity Portal in the iSNS. The Entity Index is part of the table index to quickly find Portals that support a specific Entity." INDEX { isnsServerIndex, isnsRegEntityIndex, isnsRegPortalPortalIndex } ::= { isnsRegPortalTable 1 } IsnsRegPortalEntry ::= SEQUENCE { isnsRegPortalPortalIndex IsnsPortalIndexId, isnsRegPortalAddressType InetAddressType, isnsRegPortalAddress InetAddress, isnsRegPortalPortType IsnsPortalPortTypeId, isnsRegPortalPort InetPortNumber, isnsRegPortalSymbolicName SnmpAdminString, isnsRegPortalEsiInterval Unsigned32, isnsRegPortalEsiPortType IsnsPortalPortTypeId, Gibbons, et al. Standards Track [Page 46] RFC 4939 iSNS MIB July 2007 isnsRegPortalEsiPort InetPortNumber, isnsRegPortalScnPortType IsnsPortalPortTypeId, isnsRegPortalScnPort InetPortNumber, isnsRegPortalSecurityInfo IsnsPortalSecurityType } isnsRegPortalPortalIndex OBJECT-TYPE SYNTAX IsnsPortalIndexId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this Entity Portal." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 1 } isnsRegPortalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet address in isnsRegPortalAddress. If the address is specified, then it must be a valid unicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsRegPortalAddress is the zero-length string." ::= { isnsRegPortalEntry 2 } isnsRegPortalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Inet Address for this Portal as defined in the iSNS Specification, RFC 4171. The format of this object is specified by isnsRegPortalAddressType." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 3 } isnsRegPortalPortType OBJECT-TYPE SYNTAX IsnsPortalPortTypeId MAX-ACCESS read-only STATUS current DESCRIPTION "The port type for this Portal, either UDP or TCP, as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 4 } Gibbons, et al. Standards Track [Page 47] RFC 4939 iSNS MIB July 2007 isnsRegPortalPort OBJECT-TYPE SYNTAX InetPortNumber ( 1 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The port number for this Portal as defined in the iSNS Specification, RFC 4171. Whether the Portal type is TCP or UDP is indicated by isnsRegPortalPortType." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 5 } isnsRegPortalSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The Symbolic Name for this Portal as defined in the iSNS Specification, RFC 4171. If not provided, then the string SHALL be zero-length." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 6 } isnsRegPortalEsiInterval OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Status Inquiry (ESI) Interval for this Portal as defined in the iSNS Specification, RFC 4171. A value of 0 indicates that ESI monitoring has not been configured for this Portal." REFERENCE "RFC 4171, Section 6.3.4" ::= { isnsRegPortalEntry 7 } isnsRegPortalEsiPortType OBJECT-TYPE SYNTAX IsnsPortalPortTypeId MAX-ACCESS read-only STATUS current DESCRIPTION "The port type for the ESI Port, either UDP or TCP, as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 8 } isnsRegPortalEsiPort OBJECT-TYPE SYNTAX InetPortNumber Gibbons, et al. Standards Track [Page 48] RFC 4939 iSNS MIB July 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The TCP or UDP port number used for ESI monitoring. Whether the port type is TCP or UDP is indicated by isnsRegPortalEsiPortType. A value of 0 indicates that ESI monitoring is not enabled for this Portal." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 9 } isnsRegPortalScnPortType OBJECT-TYPE SYNTAX IsnsPortalPortTypeId MAX-ACCESS read-only STATUS current DESCRIPTION "The port type for the SCN Port, either UDP or TCP, as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 10 } isnsRegPortalScnPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The TCP or UDP port used to receive SCN messages from the iSNS Server. Whether the port type is TCP or UDP is indicated by isnsRegPortalScnPortType. A value of 0 indicates that SCN message receipt is not enabled for this Portal." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPortalEntry 11 } isnsRegPortalSecurityInfo OBJECT-TYPE SYNTAX IsnsPortalSecurityType MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates security attribute settings for the Portal as registered in the iSNS server. The bit for bitmapVALID must be set in order for this attribute to contain valid information. Setting a bit to 1 indicates the feature is enabled." REFERENCE "RFC 4171, Section 6.3.9" ::= { isnsRegPortalEntry 12 } Gibbons, et al. Standards Track [Page 49] RFC 4939 iSNS MIB July 2007 -- -- iSNS Registered Portal Group Information -- isnsRegPortalGroupInfo OBJECT IDENTIFIER ::= { isnsReg 3 } -- -- iSNS Registered Portal Group (PG) Table -- isnsRegPgTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegPgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered Portal Groups (PGs) in the iSNS Server instance. The number of entries is dependent on the number of Portal Groups registered in the iSNS." ::= { isnsRegPortalGroupInfo 1 } isnsRegPgEntry OBJECT-TYPE SYNTAX IsnsRegPgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one registered Portal Group in the iSNS server instance. The Entity Index is part of the table index to quickly find Portal Groups that support Portals and iSCSI Storage Nodes in a specific Entity." INDEX { isnsServerIndex, isnsRegEntityIndex, isnsRegPgIndex } ::= { isnsRegPgTable 1 } IsnsRegPgEntry ::= SEQUENCE { isnsRegPgIndex IsnsPortalGroupIndexId, isnsRegPgIscsiNodeIndex IsnsNodeIndexId, isnsRegPgIscsiName SnmpAdminString, isnsRegPgPortalPortalIndex IsnsPortalIndexId, isnsRegPgPortalAddressType InetAddressType, isnsRegPgPortalAddress InetAddress, isnsRegPgPortalPortType IsnsPortalPortTypeId, isnsRegPgPortalPort InetPortNumber, isnsRegPgPGT IsnsPortalGroupTagIdOrNull } Gibbons, et al. Standards Track [Page 50] RFC 4939 iSNS MIB July 2007 isnsRegPgIndex OBJECT-TYPE SYNTAX IsnsPortalGroupIndexId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The PG Index for this node. The index is created by the iSNS Server instance for uniquely identifying registered objects. The PG object is registered at the same time a Portal or Storage Node is registered using the iSNS protocol." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPgEntry 1 } isnsRegPgIscsiNodeIndex OBJECT-TYPE SYNTAX IsnsNodeIndexId MAX-ACCESS read-only STATUS current DESCRIPTION "The index for the iSCSI Node associated with this PG. This index can be used to reference the isnsRegIscsiNodeTable." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPgEntry 2 } isnsRegPgIscsiName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..223)) MAX-ACCESS read-only STATUS current DESCRIPTION "The iSCSI Name of the initiator or target associated with the storage node. The iSCSI Name cannot be longer than 223 bytes. The iSNS Server internal maximum size is 224 bytes to provide NULL termination. This is the PG iSCSI Name that uniquely identifies the iSCSI Storage Node that is associated with this PG." ::= { isnsRegPgEntry 3 } isnsRegPgPortalPortalIndex OBJECT-TYPE SYNTAX IsnsPortalIndexId MAX-ACCESS read-only STATUS current DESCRIPTION "The Portal Index for the Portal associated with this PG. This index can be used to reference the isnsRegPortalTable." ::= { isnsRegPgEntry 4 } isnsRegPgPortalAddressType OBJECT-TYPE Gibbons, et al. Standards Track [Page 51] RFC 4939 iSNS MIB July 2007 SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet address in isnsRegPgPortalAddress. If the address is specified, then it must be a valid unicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsRegPgPortalAddress is the zero-length string." ::= { isnsRegPgEntry 5 } isnsRegPgPortalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Inet Address for the Portal that is associated with the PG. The format of this object is specified by isnsRegPgPortalAddressType." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPgEntry 6 } isnsRegPgPortalPortType OBJECT-TYPE SYNTAX IsnsPortalPortTypeId MAX-ACCESS read-only STATUS current DESCRIPTION "The port type, either UDP or TCP, for the Portal that is associated with this registered PG object." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPgEntry 7 } isnsRegPgPortalPort OBJECT-TYPE SYNTAX InetPortNumber ( 1 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The port number for the Portal that is associated with this registered PG object. Whether the Portal type is TCP or UDP is indicated by isnsRegPgPortalPortType." REFERENCE "RFC 4171, Section 6" ::= { isnsRegPgEntry 8 } isnsRegPgPGT OBJECT-TYPE SYNTAX IsnsPortalGroupTagIdOrNull MAX-ACCESS read-only STATUS current Gibbons, et al. Standards Track [Page 52] RFC 4939 iSNS MIB July 2007 DESCRIPTION "The Portal Group Tag (PGT) for the registered iSCSI Portal Group object in an iSNS Server instance. This indicates the tag value that the Portal uses for access to the iSCSI Storage Node. The PGT is used for coordinated access between multiple Portals, as described in the iSCSI Specification, RFC 3720. A PGT with no association is a NULL value. The value of -1 indicates a NULL value." REFERENCE "RFC 4171, Section 6, and RFC 3720" ::= { isnsRegPgEntry 9 } -- -- iSNS Registered iSCSI Node Information -- isnsRegIscsiNodeInfo OBJECT IDENTIFIER ::= { isnsReg 4 } -- -- iSNS Registered iSCSI Node Table -- isnsRegIscsiNodeTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegIscsiNodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered iSCSI Nodes in the iSNS server instance. Storage devices register using the iSNS protocol. While a device cannot be registered in an iSNS server using SNMP, an entry can be deleted in order to remove 'stale' entries. The number of entries is related to the number of iSCSI nodes registered in the iSNS." ::= { isnsRegIscsiNodeInfo 1 } isnsRegIscsiNodeEntry OBJECT-TYPE SYNTAX IsnsRegIscsiNodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one iSCSI node that has been registered in the iSNS Server instance. New rows cannot be added using SNMP." INDEX { isnsServerIndex, isnsRegEntityIndex, isnsRegIscsiNodeIndex } ::= { isnsRegIscsiNodeTable 1 } IsnsRegIscsiNodeEntry ::= SEQUENCE { Gibbons, et al. Standards Track [Page 53] RFC 4939 iSNS MIB July 2007 isnsRegIscsiNodeIndex IsnsNodeIndexId, isnsRegIscsiNodeName SnmpAdminString, isnsRegIscsiNodeType IsnsIscsiNodeType, isnsRegIscsiNodeAlias SnmpAdminString, isnsRegIscsiNodeScnTypes IsnsIscsiScnType, isnsRegIscsiNodeWwnToken FcNameIdOrZero, isnsRegIscsiNodeAuthMethod SnmpAdminString } isnsRegIscsiNodeIndex OBJECT-TYPE SYNTAX IsnsNodeIndexId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this iSCSI node." REFERENCE "RFC 4171, Section 6" ::= { isnsRegIscsiNodeEntry 1 } isnsRegIscsiNodeName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..223)) MAX-ACCESS read-only STATUS current DESCRIPTION "The iSCSI Name of the initiator or target associated with the storage node. The iSCSI Name cannot be longer than 223 bytes. The iSNS Server internal maximum size is 224 bytes to provide NULL termination. This is the iSCSI Name that uniquely identifies the initiator, initiator/target, target, or control node in the network." REFERENCE "RFC 4171, Section 6" ::= { isnsRegIscsiNodeEntry 2 } isnsRegIscsiNodeType OBJECT-TYPE SYNTAX IsnsIscsiNodeType MAX-ACCESS read-only STATUS current DESCRIPTION "The Node Type defining the functions of this iSCSI node." ::= { isnsRegIscsiNodeEntry 3 } isnsRegIscsiNodeAlias OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The Alias name of the iSCSI node. This is a variable-length text-based description of up to 255 bytes." REFERENCE "RFC 4171, Section 6" Gibbons, et al. Standards Track [Page 54] RFC 4939 iSNS MIB July 2007 ::= { isnsRegIscsiNodeEntry 4 } isnsRegIscsiNodeScnTypes OBJECT-TYPE SYNTAX IsnsIscsiScnType MAX-ACCESS read-only STATUS current DESCRIPTION "The State Change Notification (SCN) types enabled for this iSCSI node." REFERENCE "RFC 4171, Section 6.4.4" ::= { isnsRegIscsiNodeEntry 5 } isnsRegIscsiNodeWwnToken OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This contains a globally unique 64-bit integer value that can be used to represent the World Wide Node Name of the iSCSI device in a Fibre Channel fabric. This identifier is used during the device registration process, and MUST conform to the requirements in RFC 4171. A zero-length string for this managed object indicates that a Node WWN token has not been assigned." REFERENCE "RFC 4171, Section 6" ::= { isnsRegIscsiNodeEntry 6 } isnsRegIscsiNodeAuthMethod OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains a null-terminated string containing UTF-8 text listing the iSCSI authentication methods enabled for this iSCSI Node, in order of preference. The text values used to identify iSCSI authentication methods are embedded in this string attribute and delineated by a comma. The text values are identical to those found in RFC 3720 - iSCSI. Additional vendor-specific text values are also possible." REFERENCE "RFC 4171, Section 6, and RFC 3720" ::= { isnsRegIscsiNodeEntry 7 } -- -- iSNS Registered FC Node Information -- isnsRegFcNodeInfo OBJECT IDENTIFIER ::= { isnsReg 5 } Gibbons, et al. Standards Track [Page 55] RFC 4939 iSNS MIB July 2007 -- -- iSNS Registered FC Node Table -- isnsRegFcNodeTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegFcNodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the registered FC Nodes in the iSNS. This supports iFCP as defined in RFC 4172." ::= { isnsRegFcNodeInfo 1 } isnsRegFcNodeEntry OBJECT-TYPE SYNTAX IsnsRegFcNodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one registered FC node that has been registered in the iSNS." INDEX { isnsServerIndex, isnsRegFcNodeWwnn } ::= { isnsRegFcNodeTable 1 } IsnsRegFcNodeEntry ::= SEQUENCE { isnsRegFcNodeWwnn FcNameIdOrZero, isnsRegFcNodeSymbolicName SnmpAdminString, isnsRegFcNodeAddressType InetAddressType, isnsRegFcNodeAddress InetAddress, isnsRegFcNodeIPA OCTET STRING, isnsRegFcNodeProxyIscsiName SnmpAdminString, isnsRegFcNodeNumFcPorts Gauge32 } isnsRegFcNodeWwnn OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FC Node World Wide Node Name as defined in the iSNS Specification, RFC 4171. A zero-length string is not valid for this managed object." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcNodeEntry 1 } isnsRegFcNodeSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString Gibbons, et al. Standards Track [Page 56] RFC 4939 iSNS MIB July 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Node Symbolic Name of the node as defined in the iSNS Specification, RFC 4171. This is a variable-length text-based description. If not provided, then the string SHALL be zero-length." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcNodeEntry 2 } isnsRegFcNodeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet address in isnsRegFcNodeAddress. If the address is specified, then it must be a valid unicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsRegFcNodeAddress is the zero-length string." ::= { isnsRegFcNodeEntry 3 } isnsRegFcNodeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Node Inet address of the node as defined in the iSNS Specification, RFC 4171. The format of this object is specified by isnsRegFcNodeAddressType." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcNodeEntry 4 } isnsRegFcNodeIPA OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "This managed object identifies the FC Initial Process Associator of the node as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcNodeEntry 5 } isnsRegFcNodeProxyIscsiName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..223)) MAX-ACCESS read-only Gibbons, et al. Standards Track [Page 57] RFC 4939 iSNS MIB July 2007 STATUS current DESCRIPTION "The iSCSI Name used to represent the FC Node in the IP network. It is used as a pointer to the matching iSCSI Name entry in the iSNS Server. Its value is usually registered by an FC-iSCSI gateway connecting the IP network to the fabric containing the FC device." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcNodeEntry 6 } isnsRegFcNodeNumFcPorts OBJECT-TYPE SYNTAX Gauge32 ( 0 .. 4294967295 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC Ports associated with this FC Node." ::= { isnsRegFcNodeEntry 7 } -- -- iSNS Registered FC Port Table -- isnsRegFcPortTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegFcPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on registered FC N_Ports in the iSNS. FC Ports are associated with registered FC Nodes. This supports iFCP as defined in RFC 4172." REFERENCE "RFC 4172, Section 4" ::= { isnsRegFcNodeInfo 2 } isnsRegFcPortEntry OBJECT-TYPE SYNTAX IsnsRegFcPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one FC Port that has been registered in iSNS." REFERENCE "RFC 4172, Section 4" INDEX { isnsServerIndex, isnsRegEntityIndex, isnsRegFcPortWwpn } ::= { isnsRegFcPortTable 1 } IsnsRegFcPortEntry ::= SEQUENCE { isnsRegFcPortWwpn FcNameIdOrZero, Gibbons, et al. Standards Track [Page 58] RFC 4939 iSNS MIB July 2007 isnsRegFcPortID FcAddressIdOrZero, isnsRegFcPortType Unsigned32, isnsRegFcPortSymbolicName SnmpAdminString, isnsRegFcPortFabricPortWwn FcNameIdOrZero, isnsRegFcPortHA FcAddressIdOrZero, isnsRegFcPortAddressType InetAddressType, isnsRegFcPortAddress InetAddress, isnsRegFcPortFcCos IsnsFcClassOfServiceType, isnsRegFcPortFc4Types OCTET STRING, isnsRegFcPortFc4Descr SnmpAdminString, isnsRegFcPortFc4Features OCTET STRING, isnsRegFcPortScnTypes IsnsIfcpScnType, isnsRegFcPortRole IsnsFcPortRoleType, isnsRegFcPortFcNodeWwnn FcNameIdOrZero, isnsRegFcPortPpnWwn FcNameIdOrZero } isnsRegFcPortWwpn OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FC Port's World Wide Port Name as defined in the iSNS Specification, RFC 4171. A zero-length string is not valid for this managed object." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 1 } isnsRegFcPortID OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port's Port ID as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 2 } isnsRegFcPortType OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Type as defined in the iSNS Specification, RFC 4171, and the Fibre Channel Generic Services Specification. Current values are as shown below: unknown (0), nPort (1), Gibbons, et al. Standards Track [Page 59] RFC 4939 iSNS MIB July 2007 nlPort (2), fNlPort (3), fPort (129), -- x'81' flPort (130), -- x'82' ePort (132), -- x'84' bPort (133), -- x'85' mFcpPort (65297), -- x'FF11' iFcpPort (65298), -- x'FF12' unknownEnd (65535) The future assignment of any additional values will be documented in a revision of RFC 4171." REFERENCE "RFC 4171, Section 6.6.3" ::= { isnsRegFcPortEntry 3 } isnsRegFcPortSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Symbolic Name as defined in the iSNS Specification, RFC 4171. If not provided, then the string SHALL be zero-length." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 4 } isnsRegFcPortFabricPortWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Fabric Port WWN for this entry as defined in the iSNS Specification, RFC 4171. A zero-length string for this managed object indicates that the Fabric Port WWN is not known, or has not yet been registered with the iSNS Server." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 5 } isnsRegFcPortHA OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Hard Address as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 6 } isnsRegFcPortAddressType OBJECT-TYPE Gibbons, et al. Standards Track [Page 60] RFC 4939 iSNS MIB July 2007 SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Inet address in isnsRegFcPortAddress. If the address is specified, then it must be a valid unicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsRegFcPortAddress is the zero-length string." ::= { isnsRegFcPortEntry 7 } isnsRegFcPortAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Inet Address as defined in the iSNS Specification, RFC 4171. The format of this object is specified by isnsRegFcPortAddressType." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 8 } isnsRegFcPortFcCos OBJECT-TYPE SYNTAX IsnsFcClassOfServiceType MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Class of Service as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 9 } isnsRegFcPortFc4Types OBJECT-TYPE SYNTAX OCTET STRING (SIZE (32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port FC-4 Types as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6.6.9" ::= { isnsRegFcPortEntry 10 } isnsRegFcPortFc4Descr OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(4..255)) MAX-ACCESS read-only STATUS current DESCRIPTION Gibbons, et al. Standards Track [Page 61] RFC 4939 iSNS MIB July 2007 "The FC Port FC-4 Descriptor as defined in the iSNS Specification, RFC 4171. The FC-4 Descriptor cannot be longer than 255 bytes. The iSNS Server internal maximum size is 256 bytes to provide NULL termination." REFERENCE "RFC 4171, Section 6.6.10" ::= { isnsRegFcPortEntry 11 } isnsRegFcPortFc4Features OBJECT-TYPE SYNTAX OCTET STRING (SIZE (128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port FC-4 Features as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6.6.11" ::= { isnsRegFcPortEntry 12 } isnsRegFcPortScnTypes OBJECT-TYPE SYNTAX IsnsIfcpScnType MAX-ACCESS read-only STATUS current DESCRIPTION "The iFCP State Change Notification (SCN) types enabled for the registered object." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 13 } isnsRegFcPortRole OBJECT-TYPE SYNTAX IsnsFcPortRoleType MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Role defines the role of the registered object." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 14 } isnsRegFcPortFcNodeWwnn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Node World Wide Node Name that is associated with this FC Port as defined in the iSNS Specification, RFC 4171. This managed object may contain a zero-length string prior to a device registering this value with the iSNS Server." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 15 } Gibbons, et al. Standards Track [Page 62] RFC 4939 iSNS MIB July 2007 isnsRegFcPortPpnWwn OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Permanent Port Name (PPN) attribute is the FC Port Name WWPN of the first Storage Node registered in the iSNS Database that is associated with a particular FC Device (FC Node). The PPN of all subsequent Storage Node registrations that are associated with that FC Device (FC Node) SHALL be set to the FC Port Name WWPN of the first Storage Node, as defined in the iSNS Specification, RFC 4171. This managed object may contain a zero-length string prior to a device registering this value with the iSNS Server." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 16 } -- -- Mapping from FC Node to Entity - FC Port -- isnsRegFcNodePortTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsRegFcNodePortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the mapping of a registered FC Node and associated registered iFCP Port to the supporting registered Entity object in an iSNS Server instance." ::= { isnsRegFcNodeInfo 3 } isnsRegFcNodePortEntry OBJECT-TYPE SYNTAX IsnsRegFcNodePortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on one mapping from an FC Node and iFCP Port to an Entity object registered in an iSNS." INDEX { isnsServerIndex, isnsRegFcNodeWwnn, isnsRegFcPortWwpn } ::= { isnsRegFcNodePortTable 1 } IsnsRegFcNodePortEntry ::= SEQUENCE { isnsRegFcNodePortEntityIndex IsnsEntityIndexIdOrZero } Gibbons, et al. Standards Track [Page 63] RFC 4939 iSNS MIB July 2007 isnsRegFcNodePortEntityIndex OBJECT-TYPE SYNTAX IsnsEntityIndexIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The Entity Index for the registered Entity object associated with the FC Port and FC Node. This managed object may contain the value of zero prior to a device registering this value with the iSNS Server." ::= { isnsRegFcNodePortEntry 1 } -- -- iSNS Notifications Information ----------------- -- isnsNotificationsInfo OBJECT IDENTIFIER ::= { isnsObjects 2 } isnsInstanceInfo OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Textual information about the notification event and the iSNS Server generating the notification. An example is: iSNS Server Started." ::= { isnsNotificationsInfo 1 } isnsAddressNotificationType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The type of Inet address in isnsAddressNotification. If the address is specified, then it must be a valid unicast address and the value of this object must be ipv4(1), ipv6(2), ipv4z(3), or ipv6z(4); otherwise, the value of this object is unknown(0), and the value of isnsAddressNotification is the zero-length string." ::= { isnsNotificationsInfo 2 } isnsAddressNotification OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Identifies the IP address of the iSNS Server. The format of Gibbons, et al. Standards Track [Page 64] RFC 4939 iSNS MIB July 2007 this object is specified by isnsAddressNotificationType. The IP address will always be specified in the notification unless an error causes the IP address to not be known." ::= { isnsNotificationsInfo 3 } isnsTcpPortNotification OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Indicates the TCP port the iSNS Server is using, or 0 if TCP-based registrations are not supported." ::= { isnsNotificationsInfo 4 } isnsUdpPortNotification OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Indicates the UDP port the iSNS Server is using, or 0 if UDP-based registrations are not supported." ::= { isnsNotificationsInfo 5 } -- -- iSNS Notification Block ----------------- -- isnsServerStart NOTIFICATION-TYPE OBJECTS { isnsInstanceInfo, isnsAddressNotificationType, isnsAddressNotification, isnsTcpPortNotification, isnsUdpPortNotification } STATUS current DESCRIPTION "This notification is sent when an iSNS Server begins operation. The notification provides the following: isnsInstanceInfo : iSNS Server textual information isnsAddressTypeNotification : iSNS Server address type isnsAddressNotification : iSNS Server address isnsTcpPortNotification : iSNS Server TCP Port isnsUdpPortNotification : iSNS Server UDP Port " ::= { isnsNotifications 1 } isnsServerShutdown NOTIFICATION-TYPE Gibbons, et al. Standards Track [Page 65] RFC 4939 iSNS MIB July 2007 OBJECTS { isnsInstanceInfo, isnsAddressNotificationType, isnsAddressNotification, isnsTcpPortNotification, isnsUdpPortNotification } STATUS current DESCRIPTION "This notification is sent when an iSNS Server is shutdown. The notification provides the following: isnsInstanceInfo : iSNS Server textual information isnsAddressTypeNotification : iSNS Server address type isnsAddressNotification : iSNS Server address isnsTcpPortNotification : iSNS Server TCP Port isnsUdpPortNotification : iSNS Server UDP Port " ::= { isnsNotifications 2 } ------------------------------------------------------------ -- -- Compliance Information -- isnsCompliances OBJECT IDENTIFIER ::= { isnsConformance 1 } isnsIscsiServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial compliance statement for an iSNS Server providing support to iSCSI clients." MODULE -- this module MANDATORY-GROUPS { isnsServerAttributesGroup, isnsServerIscsiControlNodeGroup, isnsServerIscsiDdsDdObjGroup, isnsServerRegIscsiObjGroup, isnsServerNumObjectsGroup, isnsNotificationsObjGroup, isnsServerNotificationGroup } OBJECT isnsServerDiscoveryMcGroupType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, ipv6z is required." Gibbons, et al. Standards Track [Page 66] RFC 4939 iSNS MIB July 2007 OBJECT isnsServerDiscoveryMcGroupAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z and their related SIZE need to be supported." OBJECT isnsDdPortalMemberAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, ipv6z is required." OBJECT isnsDdPortalMemberAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z and their related SIZE need to be supported." OBJECT isnsRegEntityManagementAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, ipv6z is required." OBJECT isnsRegEntityManagementAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z and their related SIZE need to be supported." OBJECT isnsRegPortalAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, ipv6z is required." OBJECT isnsRegPortalAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z and their related SIZE need to be supported." OBJECT isnsRegPgPortalAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } Gibbons, et al. Standards Track [Page 67] RFC 4939 iSNS MIB July 2007 DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, ipv6z is required." OBJECT isnsRegPgPortalAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z and their related SIZE need to be supported." OBJECT isnsAddressNotificationType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, ipv6z is required." OBJECT isnsAddressNotification SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z and their related SIZE need to be supported." ::= { isnsCompliances 1 } isnsIfcpServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial compliance statement for an iSNS Server providing support to iFCP Clients." MODULE -- this module MANDATORY-GROUPS { isnsServerAttributesGroup, isnsServerIfcpPortControlNodeGroup, isnsServerIfcpDdsDdObjGroup, isnsServerRegIfcpObjGroup, isnsServerNumObjectsGroup, isnsNotificationsObjGroup, isnsServerNotificationGroup } OBJECT isnsServerDiscoveryMcGroupType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, and ipv6z is required." OBJECT isnsServerDiscoveryMcGroupAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) Gibbons, et al. Standards Track [Page 68] RFC 4939 iSNS MIB July 2007 DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z, and their related SIZE need to be supported." OBJECT isnsDdPortalMemberAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, and ipv6z is required." OBJECT isnsDdPortalMemberAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z, and their related SIZE need to be supported." OBJECT isnsRegEntityManagementAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, and ipv6z is required." OBJECT isnsRegEntityManagementAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z, and their related SIZE need to be supported." OBJECT isnsRegPortalAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, and ipv6z is required." OBJECT isnsRegPortalAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z, and their related SIZE need to be supported." OBJECT isnsRegFcNodeAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, and ipv6z Gibbons, et al. Standards Track [Page 69] RFC 4939 iSNS MIB July 2007 is required." OBJECT isnsRegFcNodeAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z, and their related SIZE need to be supported." OBJECT isnsRegFcPortAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, and ipv6z is required." OBJECT isnsRegFcPortAddress SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z, and their related SIZE need to be supported." OBJECT isnsAddressNotificationType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "Only support for unknown, ipv4, ipv6, ipv4z, and ipv6z is required." OBJECT isnsAddressNotification SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20 )) DESCRIPTION "Only addresses for unknown, ipv4, ipv6, ipv4z, ipv6z, and their related SIZE need to be supported." ::= { isnsCompliances 2 } isnsGroups OBJECT IDENTIFIER ::= { isnsConformance 2 } isnsServerAttributesGroup OBJECT-GROUP OBJECTS { isnsServerName, isnsServerIsnsVersion, isnsServerVendorInfo, isnsServerPhysicalIndex, isnsServerTcpPort, isnsServerUdpPort, isnsServerDiscontinuityTime, isnsServerRole, isnsServerDiscoveryMethodsEnabled, Gibbons, et al. Standards Track [Page 70] RFC 4939 iSNS MIB July 2007 isnsServerDiscoveryMcGroupType, isnsServerDiscoveryMcGroupAddress, isnsServerEsiNonResponseThreshold, isnsServerEnableControlNodeMgtScn, isnsServerDefaultDdDdsStatus, isnsServerUpdateDdDdsSupported, isnsServerUpdateDdDdsEnabled } STATUS current DESCRIPTION "iSNS Server attributes." ::= { isnsGroups 1 } isnsServerNumObjectsGroup OBJECT-GROUP OBJECTS { isnsNumDds, isnsNumDd, isnsNumEntities, isnsNumPortals, isnsNumPortalGroups, isnsNumIscsiNodes, isnsNumFcPorts, isnsNumFcNodes, isnsRegEntityInfoNumPortals, isnsRegEntityInfoNumPortalGroups, isnsRegEntityInfoNumIscsiNodes, isnsRegEntityInfoNumFcPorts, isnsRegEntityInfoNumFcNodes } STATUS current DESCRIPTION "Managed objects indicating the number of registered objects in an iSNS Server or the number of registered objects associated with a registered Entity. These managed objects are optional to implement." ::= { isnsGroups 2 } isnsServerIscsiControlNodeGroup OBJECT-GROUP OBJECTS { isnsControlNodeIscsiNodeName, isnsControlNodeIscsiIsRegistered, isnsControlNodeIscsiRcvMgtSCN } STATUS current DESCRIPTION "iSNS Server iSCSI control node managed objects." ::= { isnsGroups 3 } Gibbons, et al. Standards Track [Page 71] RFC 4939 iSNS MIB July 2007 isnsServerIfcpPortControlNodeGroup OBJECT-GROUP OBJECTS { isnsControlNodeFcPortIsRegistered, isnsControlNodeFcPortRcvMgtSCN } STATUS current DESCRIPTION "iSNS Server iFCP Port control node managed objects." ::= { isnsGroups 4 } isnsServerIscsiDdsDdObjGroup OBJECT-GROUP OBJECTS { isnsDdsSymbolicName, isnsDdsStatus, isnsDdsMemberSymbolicName, isnsDdSymbolicName, isnsDdFeatures, isnsDdIscsiMemberName, isnsDdIscsiMemberIsRegistered, isnsDdPortalMemberAddressType, isnsDdPortalMemberAddress, isnsDdPortalMemberPortType, isnsDdPortalMemberPort, isnsDdPortalMemberIsRegistered } STATUS current DESCRIPTION "iSNS Server DDS and DD managed objects for iSCSI." ::= { isnsGroups 5 } isnsServerIfcpDdsDdObjGroup OBJECT-GROUP OBJECTS { isnsDdsSymbolicName, isnsDdsStatus, isnsDdSymbolicName, isnsDdFeatures, isnsDdPortalMemberAddressType, isnsDdPortalMemberAddress, isnsDdPortalMemberPortType, isnsDdPortalMemberPort, isnsDdPortalMemberIsRegistered, isnsDdFcPortMemberIsRegistered } STATUS current DESCRIPTION "iSNS Server DDS and DD managed objects for iFCP." ::= { isnsGroups 6 } Gibbons, et al. Standards Track [Page 72] RFC 4939 iSNS MIB July 2007 isnsServerRegIscsiObjGroup OBJECT-GROUP OBJECTS { isnsRegEntityEID, isnsRegEntityProtocol, isnsRegEntityManagementAddressType, isnsRegEntityManagementAddress, isnsRegEntityTimestamp, isnsRegEntityVersionMin, isnsRegEntityVersionMax, isnsRegEntityRegistrationPeriod, isnsRegEntityInfoNumPortals, isnsRegEntityInfoNumPortalGroups, isnsRegEntityInfoNumIscsiNodes, isnsRegEntityInfoNumFcPorts, isnsRegEntityInfoNumFcNodes, isnsRegPortalAddressType, isnsRegPortalAddress, isnsRegPortalPortType, isnsRegPortalPort, isnsRegPortalSymbolicName, isnsRegPortalEsiInterval, isnsRegPortalEsiPortType, isnsRegPortalEsiPort, isnsRegPortalScnPortType, isnsRegPortalScnPort, isnsRegPortalSecurityInfo, isnsRegPgIscsiNodeIndex, isnsRegPgIscsiName, isnsRegPgPortalPortalIndex, isnsRegPgPortalAddressType, isnsRegPgPortalAddress, isnsRegPgPortalPortType, isnsRegPgPortalPort, isnsRegPgPGT, isnsRegIscsiNodeName, isnsRegIscsiNodeType, isnsRegIscsiNodeAlias, isnsRegIscsiNodeScnTypes, isnsRegIscsiNodeWwnToken, isnsRegIscsiNodeAuthMethod } STATUS current DESCRIPTION "iSNS Server registered iSCSI managed objects." ::= { isnsGroups 7 } isnsServerRegIfcpObjGroup OBJECT-GROUP OBJECTS { Gibbons, et al. Standards Track [Page 73] RFC 4939 iSNS MIB July 2007 isnsRegEntityEID, isnsRegEntityProtocol, isnsRegEntityManagementAddressType, isnsRegEntityManagementAddress, isnsRegEntityTimestamp, isnsRegEntityVersionMin, isnsRegEntityVersionMax, isnsRegEntityRegistrationPeriod, isnsRegEntityInfoNumPortals, isnsRegEntityInfoNumPortalGroups, isnsRegEntityInfoNumIscsiNodes, isnsRegEntityInfoNumFcPorts, isnsRegEntityInfoNumFcNodes, isnsRegPortalAddressType, isnsRegPortalAddress, isnsRegPortalPortType, isnsRegPortalPort, isnsRegPortalSymbolicName, isnsRegPortalEsiInterval, isnsRegPortalEsiPortType, isnsRegPortalEsiPort, isnsRegPortalScnPortType, isnsRegPortalScnPort, isnsRegPortalSecurityInfo, isnsRegFcPortID, isnsRegFcPortType, isnsRegFcPortSymbolicName, isnsRegFcPortFabricPortWwn, isnsRegFcPortHA, isnsRegFcPortAddressType, isnsRegFcPortAddress, isnsRegFcPortFcCos, isnsRegFcPortFc4Types, isnsRegFcPortFc4Descr, isnsRegFcPortFc4Features, isnsRegFcPortScnTypes, isnsRegFcPortRole, isnsRegFcPortFcNodeWwnn, isnsRegFcPortPpnWwn, isnsRegFcNodeSymbolicName, isnsRegFcNodeAddressType, isnsRegFcNodeAddress, isnsRegFcNodeIPA, isnsRegFcNodeProxyIscsiName, isnsRegFcNodeNumFcPorts, isnsRegFcNodePortEntityIndex } STATUS current Gibbons, et al. Standards Track [Page 74] RFC 4939 iSNS MIB July 2007 DESCRIPTION "iSNS Server registered iFCP managed objects." ::= { isnsGroups 8 } isnsNotificationsObjGroup OBJECT-GROUP OBJECTS { isnsInstanceInfo, isnsAddressNotificationType, isnsAddressNotification, isnsTcpPortNotification, isnsUdpPortNotification } STATUS current DESCRIPTION "iSNS Notification managed objects." ::= { isnsGroups 9 } isnsServerNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { isnsServerStart, isnsServerShutdown } STATUS current DESCRIPTION "iSNS Server Notification managed objects." ::= { isnsGroups 10 } END 6. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- isnsMIB { mib-2 163 } This RFC utilizes the IANA registry of iSNS parameters. This registry was created for the iSNS Specification [RFC4171], and is located at http://www.iana.org/assignments/isns-parameters. Specifically, the isnsRegEntityProtocol values used in the MIB module are the values for the Block Storage Protocols that IANA assigns and documents in http://www.iana.org/assignments/isns-parameters. Gibbons, et al. Standards Track [Page 75] RFC 4939 iSNS MIB July 2007 7. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: The isnsDdsMemberTable contains information about which Discovery Domains may be enabled at the same time. The isnsDdTable contains information about Discovery Domains, containing storage nodes with an ability to communicate and exchange storage data. The isnsDdIscsiMemberTable indicates which iSCSI nodes are contained in which Discovery Domains. The isnsDdPortalMemberTable indicates which iSCSI portals are contained in which Discovery Domains. The isnsDdFcPortMemberTable indicates which iFCP FC N_Ports are contained in which Discovery Domains. The isnsControlNodeIscsiTable indicates which iSCSI nodes have the ability to possibly control an iSNS server. The isnsControlNodeFcPortTable indicates which iFCP FC N_Ports have the ability to possibly control an iSNS server. The above object tables provide information about storage objects sessions, and can indicate to a user who is communicating and exchanging storage data. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Gibbons, et al. Standards Track [Page 76] RFC 4939 iSNS MIB July 2007 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, March 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. Gibbons, et al. Standards Track [Page 77] RFC 4939 iSNS MIB July 2007 [RFC4133] McCloghrie, K. and A. Bierman, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005. [RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005. 9. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 10. Acknowledgements This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. We wish to acknowledge the contributions and comments from the IPS WG, including the following: IPS WG Chair: David Black Former Editors: Josh Tseng and Tom McSweeney MIB Editors: Keith McCloghrie and Bert Wijnen Gibbons, et al. Standards Track [Page 78] RFC 4939 iSNS MIB July 2007 Authors' Addresses Kevin Gibbons 2Wire, Inc. 1704 Automation Parkway San Jose, CA 95131 USA Tel: +1 408-895-1387 Fax: +1 408-428-9590 EMail: kgibbons@yahoo.com G.D. Ramkumar SnapTell, Inc. 2741 Middlefield Rd, Suite 200 Palo Alto, CA 94306 USA Tel: +1 650-326-7627 Fax: +1 650-326-7620 EMail: gramkumar@stanfordalumni.org Scott Kipp Brocade 4 McDATA Pkwy Broomfield, CO 80021 USA Tel: +1 720-558-3452 Fax: +1 720-558-8999 EMail: skipp@brocade.com Gibbons, et al. Standards Track [Page 79] RFC 4939 iSNS MIB July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Gibbons, et al. Standards Track [Page 80] snmp-mibs-downloader-1.1/mibrfcs/rfc4983.txt0000644000000000000000000015536111402176072015605 0ustar Network Working Group C. DeSanti Request for Comments: 4983 H.K. Vivek Category: Standards Track K. McCloghrie Cisco Systems S. Gai Nuova Systems August 2007 Fibre Channel Registered State Change Notification (RSCN) MIB 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). DeSanti, et al. Standards Track [Page 1] RFC 4983 Fibre Channel RSCN MIB August 2007 Table of Contents 1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Short Overview of Fibre Channel .................................3 4. Relationship to Other MIBs ......................................5 5. MIB Overview ....................................................5 5.1. Fibre Channel Management Instance ..........................5 5.2. Switch Index ...............................................6 5.3. Fabric Index ...............................................6 5.4. The t11FcRscnRegistrationGroup Group .......................6 5.5. The t11FcRscnNotifyGroup Group .............................6 5.6. The t11FcRscnNotifyControlGroup Group ......................7 5.7. The t11FcRscnStatsGroup Group ..............................7 6. Definitions .....................................................8 6.1. The T11-FC-RSCN-MIB Module .................................8 7. IANA Considerations ............................................23 8. Security Considerations ........................................24 9. Acknowledgements ...............................................25 10. Normative References ..........................................25 11. Informative References ........................................26 DeSanti, et al. Standards Track [Page 2] RFC 4983 Fibre Channel RSCN MIB August 2007 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to Registered State Change Notifications (RSCNs) [FC-LS] in a Fibre Channel network, including which Nx_Ports are registered to receive which types of RSCNs, the control and generation of Simple Network Management Protocol (SNMP) notifications on registration failures, and RSCN-related statistics. This memo was previously approved by INternational Committee for Information Technology Standards (INCITS) Task Group T11.5 (http://www.t11.org); this document is a product of the IETF's IMSS working group. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Short Overview of Fibre Channel The Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A DeSanti, et al. Standards Track [Page 3] RFC 4983 Fibre Channel RSCN MIB August 2007 Fibre Channel "node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are switches. An N_Port connects to the Fabric via a port on a switch called an F_Port. When multiple FC nodes are connected to a single port on a switch via an "Arbitrated Loop" topology, the switch port is called an FL_Port, and the nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A switch port, which is interconnected to another switch port via an Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the fabric, each node, and most ports, have globally unique names. These globally unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a fabric is in use, the FC address identifiers are dynamically assigned by a switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy. Registered State Change Notifications (RSCNs) are defined in [FC-LS] as a means to provide Nx_Ports that have registered to receive such notifications with a timely indication of changes in the state of nodes attached to the fabric. Specifically, an Nx_Port may choose to register, using a State Change Registration (SCR) request [FC-LS] to receive RSCNs. When an event occurs that may affect a registered Nx_Port's port's state, the registered Nx_Port will receive an RSCN. For example, an Nx_Port can use RSCNs as the means by which it is informed of the failures of other nodes, of new devices coming online, or even of more network-accessible storage becoming available. The payload of the RSCN indicates the type of change and includes the address of the changed port. RSCNs are often generated by the fabric, but an Nx_Port can also generate (and send to the fabric) an RSCN if and when it detects an event not visible to the fabric. The sender of an RSCN may coalesce several events into a single RSCN message. Each RSCN is a "request" that is acknowledged by the receiver with an accept or reject. An RSCN is received by an Nx_Port from the Fabric as an Extended Link Service (ELS) request [FC-LS]. The Fabric distributes RSCNs between Switches using an SW_ILS frame with an Inter-Switch RSCN payload, also known as an SW_RSCN [FC-SW-4]. So, when a Switch has directly DeSanti, et al. Standards Track [Page 4] RFC 4983 Fibre Channel RSCN MIB August 2007 attached Nx_Ports that have registered to receive RSCNs, it converts received SW_RSCNs (i.e., SW_ILS frames containing SW_RSCN payloads) into ELS requests containing the corresponding RSCN which it sends to each such Nx_Port. The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4]. [FC-SW-4] carries forward the earlier specification for the operation of a single Fabric in a physical infrastructure, and augments it with the definition of Virtual Fabrics and with the specification of how multiple Virtual Fabrics can operate within one (or more) physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core Switch. 4. Relationship to Other MIBs The first standardized MIB for Fibre Channel [RFC2837] was focused on Fibre Channel switches. It was replaced by the more generic Fibre Channel Management MIB [RFC4044] which defines basic information for Fibre Channel hosts and switches, including extensions to the standard [IF-MIB] for Fibre Channel interfaces. [RFC4044] includes the specification of how the generic objects defined in [IF-MIB] apply to Fibre Channel interfaces. This MIB imports some common Textual Conventions defined in the T11-TC-MIB [RFC4439] and in the T11-FC-NAME-SERVER-MIB [RFC4438]. 5. MIB Overview This section explains the use of a Fibre Channel management instance, a Switch Index, and a Fabric Index. It also describes the four MIB groups contained in the MIB. 5.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [RFC4044] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. DeSanti, et al. Standards Track [Page 5] RFC 4983 Fibre Channel RSCN MIB August 2007 The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [RFC4044] as the index value to uniquely identify each Fibre Channel management instance, for example, within the same SNMP context ([RFC3411], section 3.3.1). 5.2. Switch Index The FC-MGMT-MIB [RFC4044] defines the fcmSwitchTable as a table of information about Fibre Channel switches which are managed by Fibre Channel management instances. Each Fibre Channel management instance can manage one or more Fibre Channel switches. The Switch Index, fcmSwitchIndex, is IMPORTed from the FC-MGMT-MIB as the index value to uniquely identify a Fibre Channel switch amongst those (one or more) managed by the same Fibre Channel management instance. 5.3. Fabric Index Whether operating on a Physical Fabric (i.e., without Virtual Fabrics) or within a Virtual Fabric, the manner of operation of RSCNs within a/each Fabric is identical. Therefore, this MIB defines all Fabric-related information in tables that are INDEXed by an arbitrary integer, named a "Fabric Index", the syntax of which is IMPORTed from the T11-TC-MIB [RFC4439]. When a device is connected to a single Physical Fabric, without use of any Virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple Virtual and/or Physical Fabrics, this index provides a means to distinguish one Fabric from another. It is quite possible, and may even be likely, that a Fibre Channel switch will have ports connected to multiple Virtual and/or Physical Fabrics. Thus, in order to simplify a management protocol query concerning all the Fabrics to which a single switch is connected, fcmSwitchIndex will be listed before t11FcRscnFabricIndex when they both appear in the same INDEX clause. 5.4. The t11FcRscnRegistrationGroup Group This group contains information about the Nx_Ports which have registered to receive RSCNs. 5.5. The t11FcRscnNotifyGroup Group This group contains two notifications: one generated when a switch rejects an SCR or RSCN; the other when a switch rejects an SW_RSCN. DeSanti, et al. Standards Track [Page 6] RFC 4983 Fibre Channel RSCN MIB August 2007 5.5.1. Flow-Control for Notifications When defining SNMP notifications for events that occur in the data- plane, the maximum frequency of their generation needs to be considered. Unless there is some limiting factor, such notifications need to be flow-controlled in some way, e.g., defined such that after some maximum number within a specified time interval have occurred, further notifications are suppressed for some subsequent time interval. However, when such a suppression occurs, the Network Management System (NMS) that didn't receive the notifications (because they were suppressed) needs to be able to obtain an indication of how many were suppressed. Therefore, an additional Counter32 object needs to be defined, and/or a new type of notification needs to be defined for use at the end of the interval. While this is extra complexity, it is necessary for notifications that need to be flow-controlled. In contrast, for notifications such as both the ones defined in this MIB module, which are generated due to control-plane events (and are not able to start a chain reaction), the extra complexity of flow- controlling these types of notifications is not warranted. 5.6. The t11FcRscnNotifyControlGroup Group This group contains one object for each notification in the t11FcRscnNotifyGroup group to enable/disable that notification, as well as three objects that record information about the latest rejection of an SCR, RSCN or SW_RSCN. Specifically, they record the content (if available) of the rejected request, the source of the rejected request, and the reason for the rejection. 5.7. The t11FcRscnStatsGroup Group This group contains RSCN-related statistics. Two levels of statistics are included: 1) counters at the message-type level, for: - the number of SCRs received/rejected, - the number of RSCNs sent/received/rejected, - the number of SW_RSCNs sent/received/rejected. 2) counters for each different category of sent/received RSCNs, where different categories are indicated by different values of the 'Event Qualifier' contained in an RSCN message. Note that if and when several RSCN events are coalesced into a single RSCN message, then that message may be counted in more than one of these counters. No counters are defined in this MIB for the 'Event Qualifier' value of '0001'b (meaning "Changed Name DeSanti, et al. Standards Track [Page 7] RFC 4983 Fibre Channel RSCN MIB August 2007 Server Object") because these types of RSCNs are counted by the t11NsInRscns and t11NsOutRscns objects already defined in [RFC4438]. 6. Definitions 6.1. The T11-FC-RSCN-MIB Module T11-FC-RSCN-MIB DEFINITIONS ::= BEGIN -- The Fibre Channel RSCN MIB -- -- for the monitoring of registrations by Nx_Ports to receive -- Registered State Change Notifications (RSCNs), and the -- monitoring of RSCN usage. -- IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TruthValue FROM SNMPv2-TC -- [RFC2579] fcmInstanceIndex, fcmSwitchIndex, FcNameIdOrZero, FcAddressIdOrZero FROM FC-MGMT-MIB -- [RFC4044] T11NsGs4RejectReasonCode FROM T11-FC-NAME-SERVER-MIB -- [RFC4438] T11FabricIndex FROM T11-TC-MIB; -- [RFC4439] t11FcRscnMIB MODULE-IDENTITY LAST-UPDATED "200701080000Z" ORGANIZATION "For the initial versions, T11. For later versions, the IETF's IMSS Working Group." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kzm@cisco.com" DESCRIPTION "The MIB module for the management of registrations DeSanti, et al. Standards Track [Page 8] RFC 4983 Fibre Channel RSCN MIB August 2007 by Nx_Ports to receive RSCNs (Registered State Change Notifications) on a Fibre Channel Fabric, as defined in FC-LS, and for the monitoring of RSCNs sent/received or rejected in a Fibre Channel Fabric. Copyright (C) The Internet Society (2007). This version of this MIB module is part of RFC 4983; see the RFC itself for full legal notices." REVISION "200701080000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 4983." ::= { mib-2 161 } t11FcRscnNotifications OBJECT IDENTIFIER ::= { t11FcRscnMIB 0 } t11FcRscnObjects OBJECT IDENTIFIER ::= { t11FcRscnMIB 1 } t11FcRscnConformance OBJECT IDENTIFIER ::= { t11FcRscnMIB 2 } t11FcRscnRegistrations OBJECT IDENTIFIER ::= { t11FcRscnObjects 1 } t11FcRscnStats OBJECT IDENTIFIER ::= { t11FcRscnObjects 2 } t11FcRscnInformation OBJECT IDENTIFIER ::= { t11FcRscnObjects 3 } -- State Change Registration Table t11FcRscnRegTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcRscnRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Nx_Ports that have registered to receive RSCNs on all Fabrics configured on one or more Fibre Channel switches." ::= { t11FcRscnRegistrations 1 } t11FcRscnRegEntry OBJECT-TYPE SYNTAX T11FcRscnRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing information about one Nx_Port that has registered with a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex) for a particular Fabric (identified by a t11FcRscnFabricIndex value)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcRscnFabricIndex, t11FcRscnRegFcId } ::= { t11FcRscnRegTable 1 } T11FcRscnRegEntry ::= SEQUENCE { DeSanti, et al. Standards Track [Page 9] RFC 4983 Fibre Channel RSCN MIB August 2007 t11FcRscnFabricIndex T11FabricIndex, t11FcRscnRegFcId FcAddressIdOrZero, t11FcRscnRegType BITS } t11FcRscnFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Fabric. In a Fabric conformant to FC-SW-4, multiple Virtual Fabrics can operate within one (or more) physical infrastructures. In such a case, this index value is used to uniquely identify a particular Fabric within a physical infrastructure. In a Fabric that has (or can have) only a single Fabric operating within the physical infrastructure, the value of this Fabric Index will always be 1." REFERENCE "ANSI INCITS 418-2006, Fibre Channel - Switch Fabric - 4 (FC-SW-4), December 2006." ::= { t11FcRscnRegEntry 1 } t11FcRscnRegFcId OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Fibre Channel Address Identifier of the registering Nx_Port." ::= { t11FcRscnRegEntry 2 } t11FcRscnRegType OBJECT-TYPE SYNTAX BITS { fromFabricController(0), fromNxPort(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of registration desired by the registering Nx_Port, one bit per type: 'fromFabricController' -- RSCNs generated for events DeSanti, et al. Standards Track [Page 10] RFC 4983 Fibre Channel RSCN MIB August 2007 detected by the Fabric Controller. 'fromNxPorts' -- RSCNs generated for events detected by the affected Nx_Port." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 40." ::= { t11FcRscnRegEntry 3 } -- Statistics t11FcRscnStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcRscnStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RSCN-related statistics on all Fabrics configured on one or more Fibre Channel switches. Two levels of statistics are included: 1) counters at the message-type level, for: - the number of SCRs received/rejected, - the number of RSCNs sent/received/rejected, - the number of SW_RSCNs sent/received/rejected. 2) counters of sent/received RSCNs per 'Event Qualifier' value. Note that if and when several RSCN events are coalesced into a single RSCN message, then that message may be counted in more than one of these counters." ::= { t11FcRscnStats 1 } t11FcRscnStatsEntry OBJECT-TYPE SYNTAX T11FcRscnStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing statistics for a particular Fabric (identified by a t11FcRscnFabricIndex value) on a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcRscnFabricIndex } ::= { t11FcRscnStatsTable 1 } T11FcRscnStatsEntry ::= SEQUENCE { t11FcRscnInScrs Counter32, DeSanti, et al. Standards Track [Page 11] RFC 4983 Fibre Channel RSCN MIB August 2007 t11FcRscnInRscns Counter32, t11FcRscnOutRscns Counter32, t11FcRscnInSwRscns Counter32, t11FcRscnOutSwRscns Counter32, t11FcRscnScrRejects Counter32, t11FcRscnRscnRejects Counter32, t11FcRscnSwRscnRejects Counter32, t11FcRscnInUnspecifiedRscns Counter32, t11FcRscnOutUnspecifiedRscns Counter32, t11FcRscnInChangedAttribRscns Counter32, t11FcRscnOutChangedAttribRscns Counter32, t11FcRscnInChangedServiceRscns Counter32, t11FcRscnOutChangedServiceRscns Counter32, t11FcRscnInChangedSwitchRscns Counter32, t11FcRscnOutChangedSwitchRscns Counter32, t11FcRscnInRemovedRscns Counter32, t11FcRscnOutRemovedRscns Counter32 } t11FcRscnInScrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCRs received from Nx_Ports by this switch on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 1 } t11FcRscnInRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RSCNs received from Nx_Ports by this switch on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 2 } t11FcRscnOutRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DeSanti, et al. Standards Track [Page 12] RFC 4983 Fibre Channel RSCN MIB August 2007 DESCRIPTION "The number of RSCNs transmitted to Nx_Ports by this switch on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 3 } t11FcRscnInSwRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SW_RSCNs received by this switch from other switches on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 4 } t11FcRscnOutSwRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SW_RSCNs transmitted by this switch from other switches on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 5 } t11FcRscnScrRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SCRs rejected by this switch on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 6 } t11FcRscnRscnRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only DeSanti, et al. Standards Track [Page 13] RFC 4983 Fibre Channel RSCN MIB August 2007 STATUS current DESCRIPTION "The number of RSCNs rejected by this switch on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 7 } t11FcRscnSwRscnRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SW_RSCN rejected by this switch on this Fabric. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." ::= { t11FcRscnStatsEntry 8 } t11FcRscnInUnspecifiedRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) received by this switch on this Fabric which contained an RSCN Event Qualifier value of '0000'b meaning 'Event is not specified'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 9 } t11FcRscnOutUnspecifiedRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) sent by this switch on this Fabric which contained an RSCN Event Qualifier value of '0000'b meaning 'Event is not specified'. DeSanti, et al. Standards Track [Page 14] RFC 4983 Fibre Channel RSCN MIB August 2007 This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 10 } t11FcRscnInChangedAttribRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) received by this switch on this Fabric which contained an RSCN Event Qualifier value of '0002'b meaning 'Changed Port Attribute'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 11 } t11FcRscnOutChangedAttribRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) sent by this switch on this Fabric which contained an RSCN Event Qualifier value of '0002'b meaning 'Changed Port Attribute'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 12 } t11FcRscnInChangedServiceRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) received by this switch on this Fabric which DeSanti, et al. Standards Track [Page 15] RFC 4983 Fibre Channel RSCN MIB August 2007 contained an RSCN Event Qualifier value of '0003'b meaning 'Changed Service Object'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 13 } t11FcRscnOutChangedServiceRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) sent by this switch on this Fabric which contained an RSCN Event Qualifier value of '0003'b meaning 'Changed Service Object'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 14 } t11FcRscnInChangedSwitchRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) received by this switch on this Fabric which contained an RSCN Event Qualifier value of '0004'b meaning 'Changed Switch Configuration'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 15 } t11FcRscnOutChangedSwitchRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DeSanti, et al. Standards Track [Page 16] RFC 4983 Fibre Channel RSCN MIB August 2007 DESCRIPTION "The number of Registered State Change Notifications (RSCNs) sent by this switch on this Fabric which contained an RSCN Event Qualifier value of '0004'b meaning 'Changed Switch Configuration'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 16 } t11FcRscnInRemovedRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) received by this switch on this Fabric which contained an RSCN Event Qualifier value of '0005'b meaning 'Removed Object'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 17 } t11FcRscnOutRemovedRscns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Registered State Change Notifications (RSCNs) sent by this switch on this Fabric which contained an RSCN Event Qualifier value of '0005'b meaning 'Removed Object'. This counter has no discontinuities other than those that all Counter32s have when sysUpTime=0." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 36." ::= { t11FcRscnStatsEntry 18 } DeSanti, et al. Standards Track [Page 17] RFC 4983 Fibre Channel RSCN MIB August 2007 -- -- Notification Control Table -- t11FcRscnNotifyControlTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcRscnNotifyControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control information for notifications generated due to the rejection of an SCR or RSCN." ::= { t11FcRscnInformation 1 } t11FcRscnNotifyControlEntry OBJECT-TYPE SYNTAX T11FcRscnNotifyControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains notification control information concerning the rejection of RSCN/SCRs for a particular Fabric (identified by the value of t11FcRscnFabricIndex) by a particular switch (identified by values of fcmInstanceIndex and fcmSwitchIndex)." INDEX { fcmInstanceIndex, fcmSwitchIndex, t11FcRscnFabricIndex } ::= { t11FcRscnNotifyControlTable 1 } T11FcRscnNotifyControlEntry ::= SEQUENCE { t11FcRscnIlsRejectNotifyEnable TruthValue, t11FcRscnElsRejectNotifyEnable TruthValue, t11FcRscnRejectedRequestString OCTET STRING, t11FcRscnRejectedRequestSource FcNameIdOrZero, t11FcRscnRejectReasonCode T11NsGs4RejectReasonCode, t11FcRscnRejectReasonCodeExp OCTET STRING, t11FcRscnRejectReasonVendorCode OCTET STRING } t11FcRscnIlsRejectNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies if a t11FcRscnIlsRejectReqNotify notification should be generated when this switch rejects an SW_RSCN on this Fabric. Values written to this object should be retained over agent reboots." DEFVAL { false } ::= { t11FcRscnNotifyControlEntry 1 } DeSanti, et al. Standards Track [Page 18] RFC 4983 Fibre Channel RSCN MIB August 2007 t11FcRscnElsRejectNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies if a t11FcRscnElsRejectReqNotify notification should be generated when this switch rejects an RSCN or SCR on this Fabric. Values written to this object should be retained over agent reboots." DEFVAL { false } ::= { t11FcRscnNotifyControlEntry 2 } t11FcRscnRejectedRequestString OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The binary content of the RSCN, SCR, or SW_RSCN that was most recently rejected by this switch on this Fabric. The value is formatted as an octet string (in network byte order) as described in the relevant Fibre Channel standard, containing the payload (which is typically a list of affected ports and error codes) of the rejected RSCN or SCR as described in FC-LS, or the rejected SW_RSCN as described in FC-SW-4. This object contains the zero-length string if and when the RSCN/SCR/SW_RSCN payload is unavailable. When the length of this object is 255 octets, it contains the first 255 octets of the payload (in network byte order)." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Tables 34 & 39. ANSI INCITS 418-2006, Fibre Channel - Switch Fabric - 4 (FC-SW-4), December 2006, Table 45." ::= { t11FcRscnNotifyControlEntry 3 } t11FcRscnRejectedRequestSource OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The WWN that was the source of the RSCN, SCR, or SW_RSCN that was most recently rejected by this switch on this Fabric." DeSanti, et al. Standards Track [Page 19] RFC 4983 Fibre Channel RSCN MIB August 2007 ::= { t11FcRscnNotifyControlEntry 4 } t11FcRscnRejectReasonCode OBJECT-TYPE SYNTAX T11NsGs4RejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the Reason Code of the most recent rejection by this switch of an RSCN, SCR or SW_RSCN on this Fabric." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 146. ANSI INCITS 418-2006, Fibre Channel - Switch Fabric - 4 (FC-SW-4), December 2006, Table 5." ::= { t11FcRscnNotifyControlEntry 5 } t11FcRscnRejectReasonCodeExp OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the Reason Code Explanation of the most recent rejection by this switch of an RSCN, SCR or SW_RSCN on this Fabric." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 147. ANSI INCITS 418-2006, Fibre Channel - Switch Fabric - 4 (FC-SW-4), December 2006, Table 6." ::= { t11FcRscnNotifyControlEntry 6 } t11FcRscnRejectReasonVendorCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the Reason Vendor Specific Code of the most recent rejection by this switch of an RSCN, SCR or SW_RSCN on this Fabric." REFERENCE "ANSI INCITS 433-2007, Fibre Channel - Link Services (FC-LS), July 2007, Table 148. ANSI INCITS 418-2006, Fibre Channel - Switch Fabric - 4 (FC-SW-4), December 2006, Section 6.1.3." DeSanti, et al. Standards Track [Page 20] RFC 4983 Fibre Channel RSCN MIB August 2007 ::= { t11FcRscnNotifyControlEntry 7 } -- Notifications t11FcRscnElsRejectReqNotify NOTIFICATION-TYPE OBJECTS { t11FcRscnRejectedRequestString, t11FcRscnRejectedRequestSource, t11FcRscnRejectReasonCode, t11FcRscnRejectReasonCodeExp, t11FcRscnRejectReasonVendorCode } STATUS current DESCRIPTION "This notification is generated when a switch rejects an SCR or RSCN. The value of t11FcRscnRejectedRequestString indicates the binary content of the rejected request if available, or the zero-length string otherwise. The source of the rejected request is given by t11FcRscnRejectedRequestSource, and the reason for rejection is given by the values of t11FcRscnRejectReasonCode, t11FcRscnRejectReasonCodeExp and t11FcRscnRejectReasonVendorCode." ::= { t11FcRscnNotifications 1 } t11FcRscnIlsRejectReqNotify NOTIFICATION-TYPE OBJECTS { t11FcRscnRejectedRequestString, t11FcRscnRejectedRequestSource, t11FcRscnRejectReasonCode, t11FcRscnRejectReasonCodeExp, t11FcRscnRejectReasonVendorCode } STATUS current DESCRIPTION "This notification is generated when a switch rejects an SW_RSCN. The value of t11FcRscnRejectedRequestString indicates the binary content of the rejected request if available, or the zero-length string otherwise. The source of the rejected request is given by t11FcRscnRejectedRequestSource, and the reason for rejection is given by the values of t11FcRscnRejectReasonCode, t11FcRscnRejectReasonCodeExp and t11FcRscnRejectReasonVendorCode." ::= { t11FcRscnNotifications 2 } -- Conformance t11FcRscnCompliances OBJECT IDENTIFIER ::= { t11FcRscnConformance 1 } t11FcRscnGroups OBJECT IDENTIFIER ::= { t11FcRscnConformance 2 } DeSanti, et al. Standards Track [Page 21] RFC 4983 Fibre Channel RSCN MIB August 2007 t11FcRscnCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement this MIB." MODULE MANDATORY-GROUPS { t11FcRscnRegistrationGroup, t11FcRscnNotifyControlGroup, t11FcRscnNotifyGroup } GROUP t11FcRscnStatsGroup DESCRIPTION "These counters, containing RSCN-related statistics, are mandatory only for those systems that count such events." OBJECT t11FcRscnIlsRejectNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcRscnElsRejectNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FcRscnCompliances 1 } -- Units of conformance t11FcRscnRegistrationGroup OBJECT-GROUP OBJECTS { t11FcRscnRegType } STATUS current DESCRIPTION "A collection of objects for monitoring RSCN registrations." ::= { t11FcRscnGroups 1 } t11FcRscnStatsGroup OBJECT-GROUP OBJECTS { t11FcRscnInScrs, t11FcRscnInRscns, t11FcRscnOutRscns, t11FcRscnInSwRscns, t11FcRscnOutSwRscns, t11FcRscnScrRejects, t11FcRscnRscnRejects, t11FcRscnSwRscnRejects, t11FcRscnInUnspecifiedRscns, DeSanti, et al. Standards Track [Page 22] RFC 4983 Fibre Channel RSCN MIB August 2007 t11FcRscnOutUnspecifiedRscns, t11FcRscnInChangedAttribRscns, t11FcRscnOutChangedAttribRscns, t11FcRscnInChangedServiceRscns, t11FcRscnOutChangedServiceRscns, t11FcRscnInChangedSwitchRscns, t11FcRscnOutChangedSwitchRscns, t11FcRscnInRemovedRscns, t11FcRscnOutRemovedRscns } STATUS current DESCRIPTION "A collection of objects for collecting RSCN-related statistics." ::= { t11FcRscnGroups 2 } t11FcRscnNotifyControlGroup OBJECT-GROUP OBJECTS { t11FcRscnIlsRejectNotifyEnable, t11FcRscnElsRejectNotifyEnable, t11FcRscnRejectedRequestString, t11FcRscnRejectedRequestSource, t11FcRscnRejectReasonCode, t11FcRscnRejectReasonCodeExp, t11FcRscnRejectReasonVendorCode } STATUS current DESCRIPTION "A collection of notification control and notification information objects." ::= { t11FcRscnGroups 3 } t11FcRscnNotifyGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FcRscnIlsRejectReqNotify, t11FcRscnElsRejectReqNotify } STATUS current DESCRIPTION "A collection of notifications for monitoring ILS and ELS rejections by the RSCN module." ::= { t11FcRscnGroups 4 } END 7. IANA Considerations IANA has assigned a MIB OID for the T11-FC-RSCN-MIB module under the appropriate subtree. DeSanti, et al. Standards Track [Page 23] RFC 4983 Fibre Channel RSCN MIB August 2007 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability are: t11FcRscnIlsRejectNotifyEnable t11FcRscnElsRejectNotifyEnable -- ability to enable/disable a notification; these object, if misconfigured, would either generate unwanted notifications or suppress wanted notifications. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may also be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: t11FcRscnRegTable -- contains a list of Nx_Ports that are currently registered to received RSCNs. t11FcRscnStatsTable -- contains RSCN-related statistics. t11FcRscnNotifyControlTable -- contains control and logging information for notifications that are concerned with the rejection of RSCN-related requests. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator DeSanti, et al. Standards Track [Page 24] RFC 4983 Fibre Channel RSCN MIB August 2007 responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. Acknowledgements This document was originally developed and approved by the INCITS Task Group T11.5 (http://www.t11.org) as the SM-RSCNM project. We wish to acknowledge the many contributions and comments from the INCITS Technical Committee T11, especially from the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 Vice Chair: Scott Kipp, McData and T11.5 members. The document was subsequently a work item of the IETF's IMSS Working Group, chaired by David Black (EMC Corporation). We thank Bert Wijnen (Lucent Technologies) for his thorough review of the document. We also wish to acknowledge Dan Romascanu (Avaya), the IETF Area Director, for his comments and assistance. 10. Normative References [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 58, RFC 3411, December 2002. [IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. DeSanti, et al. Standards Track [Page 25] RFC 4983 Fibre Channel RSCN MIB August 2007 [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC4438] DeSanti, C., Gaonkar, V., Vivek, H.K., McCloghrie, K., and S. Gai, "Fibre Channel Name Server MIB", RFC 4438, March 2006. [RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, March 2006. [FC-SW-4] "Fibre Channel - Switch Fabric - 4 (FC-SW-4)", ANSI INCITS 418-2006, http://www.t11.org/t11/stat.nsf/upnum/1674-d, December 2006. [FC-FS] "Fibre Channel - Framing and Signaling (FC-FS)", ANSI INCITS 373-2003, http://www.t11.org/t11/stat.nsf/upnum/1331-d, April 2003. [FC-LS] "Fibre Channel - Link Services (FC-LS)", ANSI INCITS 433-2007, http://www.t11.org/t11/stat.nsf/upnum/1620-d, July 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11. Informative References [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. DeSanti, et al. Standards Track [Page 26] RFC 4983 Fibre Channel RSCN MIB August 2007 Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com H.K. Vivek Cisco Systems, Inc. 71 Millers Rd Bangalore, India Phone: +91 80 2289933x5117 EMail: hvivek@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 526-5260 EMail: kzm@cisco.com Silvano Gai Nuova Systems 3 West Plumeria Drive San Jose, CA 95134 Phone: +1 408 387-6123 EMail: sgai@nuovasystems.com DeSanti, et al. Standards Track [Page 27] RFC 4983 Fibre Channel RSCN MIB August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. DeSanti, et al. Standards Track [Page 28] snmp-mibs-downloader-1.1/mibrfcs/rfc5017.txt0000644000000000000000000003475211402176072015572 0ustar Network Working Group D. McWalter, Ed. Request for Comments: 5017 Data Connection Ltd Category: Standards Track September 2007 MIB Textual Conventions for Uniform Resource Identifiers (URIs) 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. Abstract This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The Internet-Standard Management Framework . . . . . . . . . . 2 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 2 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It defines textual conventions to represent STD 66 [RFC3986] URIs, which are further described by [RFC3305]. Three textual conventions are defined: one of unrestricted length, and two of different restricted lengths. Which length is appropriate will depend on tradeoffs made in particular MIB modules. The purpose of providing standard restricted-length textual conventions is to improve compatibility between MIB modules that require restricted- length URIs. McWalter Standards Track [Page 1] RFC 5017 URI TC MIB September 2007 If a URI needs to be used as an index object, then the 'Uri' TEXTUAL- CONVENTION SHOULD be subtyped to a length appropriate for the Object Identifier (OID) of which it is part. The description of the 'Uri' TEXTUAL-CONVENTION discusses this case. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Definitions URI-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] uriTcMIB MODULE-IDENTITY LAST-UPDATED "200709100000Z" -- 10 September 2007 ORGANIZATION "IETF Operations and Management (OPS) Area" CONTACT-INFO "EMail: ops-area@ietf.org Home page: http://www.ops.ietf.org/" DESCRIPTION "This MIB module defines textual conventions for representing URIs, as defined by RFC 3986 STD 66." REVISION "200709100000Z" -- 10 September 2007 DESCRIPTION "Initial revision, published as RFC 5017. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 5017; see the RFC itself for full McWalter Standards Track [Page 2] RFC 5017 URI TC MIB September 2007 legal notices." ::= { mib-2 164 } Uri ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "A Uniform Resource Identifier (URI) as defined by STD 66. Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII encoding, and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary percent-encoding is removed, and all case-insensitive characters are set to lowercase except for hexadecimal digits, which are normalized to uppercase as described in Section 6.2.2.1. The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient to provide uniqueness. Two URIs that are textually distinct after this normalization may still be equivalent. Objects using this TEXTUAL-CONVENTION MAY restrict the schemes that they permit. For example, 'data:' and 'urn:' schemes might not be appropriate. A zero-length URI is not a valid URI. This can be used to express 'URI absent' where required, for example when used as an index field. Where this TEXTUAL-CONVENTION is used for an index field, it MUST be subtyped to restrict its length. There is an absolute limit of 128 subids for an OID, and it is not efficient to have OIDs whose length approaches this limit." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING Uri255 ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "A Uniform Resource Identifier (URI) as defined by STD 66. Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII encoding, and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary percent-encoding is removed, and all case-insensitive McWalter Standards Track [Page 3] RFC 5017 URI TC MIB September 2007 characters are set to lowercase except for hexadecimal digits, which are normalized to uppercase as described in Section 6.2.2.1. The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient to provide uniqueness. Two URIs that are textually distinct after this normalization may still be equivalent. Objects using this TEXTUAL-CONVENTION MAY restrict the schemes that they permit. For example, 'data:' and 'urn:' schemes might not be appropriate. A zero-length URI is not a valid URI. This can be used to express 'URI absent' where required, for example when used as an index field. STD 66 URIs are of unlimited length. Objects using this TEXTUAL-CONVENTION impose a length limit on the URIs that they can represent. Where no length restriction is required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION instead. Objects used as indices SHOULD subtype the 'Uri' TEXTUAL-CONVENTION." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (0..255)) Uri1024 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1024a" STATUS current DESCRIPTION "A Uniform Resource Identifier (URI) as defined by STD 66. Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII encoding, and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary percent-encoding is removed, and all case-insensitive characters are set to lowercase except for hexadecimal digits, which are normalized to uppercase as described in Section 6.2.2.1. The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient to provide uniqueness. Two URIs that are textually distinct after this normalization may still be equivalent. Objects using this TEXTUAL-CONVENTION MAY restrict the schemes that they permit. For example, 'data:' and 'urn:' schemes might not be appropriate. McWalter Standards Track [Page 4] RFC 5017 URI TC MIB September 2007 A zero-length URI is not a valid URI. This can be used to express 'URI absent' where required, for example when used as an index field. STD 66 URIs are of unlimited length. Objects using this TEXTUAL-CONVENTION impose a length limit on the URIs that they can represent. Where no length restriction is required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION instead. Objects used as indices SHOULD subtype the 'Uri' TEXTUAL-CONVENTION." REFERENCE "RFC 3986 STD 66 and RFC 3305" SYNTAX OCTET STRING (SIZE (0..1024)) END 5. Security Considerations See also the Security Considerations of STD 66 [RFC3986]. This MIB module does not define any management objects. Instead, it defines a textual convention that may be imported by other MIB modules and used for object definitions. Meaningful security considerations can only be written in the MIB modules that define management objects. This document therefore has no impact on the security of the Internet. 6. IANA Considerations URI-TC-MIB is rooted under the mib-2 subtree. IANA has assigned { mib-2 164 } to the URI-TC-MIB module specified in this document. 7. Acknowledgements This module was generated by editing together contributions from Randy Presuhn, Dan Romascanu, Bill Fenner, Juergen Schoenwaelder, and others. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. McWalter Standards Track [Page 5] RFC 5017 URI TC MIB September 2007 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 8.2. Informative References [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Author's Address David McWalter (editor) Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom EMail: dmcw@dataconnection.com McWalter Standards Track [Page 6] RFC 5017 URI TC MIB September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. McWalter Standards Track [Page 7] snmp-mibs-downloader-1.1/mibrfcs/rfc5060.txt0000644000000000000000000051421311402176072015563 0ustar Network Working Group R. Sivaramu Request for Comments: 5060 Cisco Systems Category: Standards Track J. Lingard Arastra, Inc D. McWalter Data Connection Ltd B. Joshi Infosys Technologies Ltd A. Kessler Cisco Systems January 2008 Protocol Independent Multicast MIB 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The Internet-Standard Management Framework . . . . . . . . . . 2 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 87 Sivaramu, et al. Standards Track [Page 1] RFC 5060 PIM MIB January 2008 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols (PIM-SM [RFC4601], BIDIR-PIM [RFC5015], and PIM-DM [RFC3973]). This document is part of work in progress to obsolete RFC 2934 [RFC2934]. RFC 2934 defined an experimental MIB module for managing the PIM protocols. The MIB module defined by this document is a re- working of the MIB module from RFC 2934, with major changes that include the following. o This MIB module is independent of IP version, whereas RFC 2934 only supported IPv4. o This MIB module includes support for managing BIDIR-PIM. o This MIB module retains limited support for managing PIM-DM [RFC3973], but that is no longer its primary purpose. o This MIB module does not include support for managing PIM-SM v1. o This MIB module does not depend on the IPv4 Multicast Routing MIB defined in RFC 2932 [RFC2932]. o This MIB module includes support for configuring static Rendezvous Points (RPs). o This MIB module includes support for configuring anycast RPs [RFC4610]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Sivaramu, et al. Standards Track [Page 2] RFC 5060 PIM MIB January 2008 Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Overview This MIB module contains the following tables. 1. The PIM Interface Table, which contains one row per IP version for each interface of the router which is running PIM. 2. The PIM Neighbor Table, which contains one row for each of the router's PIM neighbors. 3. The PIM Neighbor Secondary Address Table, which contains one row for each secondary address advertised by each of the router's PIM neighbors. 4. The PIM (*,G) State Table, which contains one row for each group for which PIM has (*,G) state. 5. The PIM (*,G,I) State Table, which contains one row for each group and interface for which PIM has interface-specific (*,G) state. 6. The PIM (S,G) State Table, which contains one row for each source and group for which PIM has (S,G) state. 7. The PIM (S,G,I) State Table, which contains one row for each source, group, and interface for which PIM has interface- specific (S,G) state. 8. The PIM (S,G,rpt) State Table, which contains one row for each source and group for which PIM has (S,G,rpt) state. 9. The PIM (S,G,rpt,I) State Table, which contains one row for each source, group, and interface for which PIM has interface- specific (S,G,rpt) state. 10. The PIM Bidir DF-Election Table, which contains one row per interface for each Rendezvous Point (RP) for which Bidirectional-PIM Designated Forwarder (DF) election state is maintained. Sivaramu, et al. Standards Track [Page 3] RFC 5060 PIM MIB January 2008 11. The PIM Static RP Table, which contains one row per range of multicast group addresses for which a particular configured RP should be used. 12. The PIM Group Mapping Table, which contains one row for each mapping from a multicast group address prefix to the PIM mode and RP address to use for groups within that group prefix, regardless of the source of the group mapping information. 13. The PIM Anycast-RP Set Table, which contains one row for each RP within each Anycast-RP set of which the local router is a member. This MIB module uses textual conventions defined in the IF-MIB [RFC2863], the INET-ADDRESS-MIB [RFC4001], and the IANA-RTPROTO-MIB [RTPROTO]. This MIB module REFERENCEs [RFC3376], [RFC3569], [RFC3618], [RFC3810], [RFC3956], [RFC3973], [RFC4601], [RFC4610], [RFC5015], [RFC5059], and [IPMCAST-MIB]. 5. Definitions PIM-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, Unsigned32, Counter32, Counter64, Gauge32, TimeTicks FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, RowStatus, TruthValue, StorageType FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndexOrZero, InterfaceIndex FROM IF-MIB -- [RFC2863] InetAddressType, InetAddressPrefixLength, InetAddress, InetVersion FROM INET-ADDRESS-MIB -- [RFC4001] IANAipRouteProtocol FROM IANA-RTPROTO-MIB; -- [RTPROTO] pimStdMIB MODULE-IDENTITY LAST-UPDATED "200711020000Z" -- 2 November 2007 ORGANIZATION "IETF Protocol Independent Multicast (PIM) Working Group" CONTACT-INFO "Email: pim@ietf.org WG charter: Sivaramu, et al. Standards Track [Page 4] RFC 5060 PIM MIB January 2008 http://www.ietf.org/html.charters/pim-charter.html" DESCRIPTION "The MIB module for management of PIM routers. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 5060; see the RFC itself for full legal notices." REVISION "200711020000Z" -- 2 November 2007 DESCRIPTION "Initial version, published as RFC 5060." ::= { mib-2 157 } -- -- Textual Conventions -- PimMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The PIM mode in which a group is operating. none(1) The group is not using PIM, which may be the case if, for example, it is a link-local or unroutable group address. ssm(2) Source-Specific Multicast (SSM) with PIM Sparse Mode. asm(3) Any Source Multicast (ASM) with PIM Sparse Mode. bidir(4) Bidirectional PIM. dm(5) PIM Dense Mode. other(6) Any other PIM mode." SYNTAX INTEGER { none(1), ssm(2), asm(3), bidir(4), dm(5), other(6) } PimGroupMappingOriginType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Sivaramu, et al. Standards Track [Page 5] RFC 5060 PIM MIB January 2008 "The mechanism by which a PIM group mapping was learned. fixed(1) Link-local or unroutable group mappings. configRp(2) Local static RP configuration. configSsm(3) Local SSM Group configuration. bsr(4) The PIM Bootstrap Router (BSR) mechanism. autoRP(5) Cisco's Auto-RP mechanism. embedded(6) The Embedded-RP mechanism where the RP address is embedded in the multicast group address. other(7) Any other mechanism." REFERENCE "RFC 3569, RFC 3956, and RFC 5059" SYNTAX INTEGER { fixed(1), configRp(2), configSsm(3), bsr(4), autoRP(5), embedded(6), other(7) } -- -- Top-level structure -- pimNotifications OBJECT IDENTIFIER ::= { pimStdMIB 0 } pim OBJECT IDENTIFIER ::= { pimStdMIB 1 } pimKeepalivePeriod OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The duration of the Keepalive Timer. This is the period during which the PIM router will maintain (S,G) state in the absence of explicit (S,G) local membership or (S,G) join messages received to maintain it. This timer period is called the Keepalive_Period in the PIM-SM specification. It is called the SourceLifetime in the PIM-DM specification. Sivaramu, et al. Standards Track [Page 6] RFC 5060 PIM MIB January 2008 The storage type of this object is determined by pimDeviceConfigStorageType." REFERENCE "RFC 4601 section 4.11" DEFVAL { 210 } ::= { pim 14 } pimRegisterSuppressionTime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The duration of the Register Suppression Timer. This is the period during which a PIM Designated Router (DR) stops sending Register-encapsulated data to the Rendezvous Point (RP) after receiving a Register-Stop message. This object is used to run timers both at the DR and at the RP. This timer period is called the Register_Suppression_Time in the PIM-SM specification. The storage type of this object is determined by pimDeviceConfigStorageType." REFERENCE "RFC 4601 section 4.11" DEFVAL { 60 } ::= { pim 15 } pimStarGEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the pimStarGTable." ::= { pim 16 } pimStarGIEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the pimStarGITable." ::= { pim 17 } pimSGEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the pimSGTable." Sivaramu, et al. Standards Track [Page 7] RFC 5060 PIM MIB January 2008 ::= { pim 18 } pimSGIEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the pimSGITable." ::= { pim 19 } pimSGRptEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the pimSGRptTable." ::= { pim 20 } pimSGRptIEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the pimSGRptITable." ::= { pim 21 } pimOutAsserts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Asserts sent by this router. Discontinuities in the value of this counter can occur at re-initialization of the management system, for example, when the device is rebooted." REFERENCE "RFC 4601 section 4.6" ::= { pim 22 } pimInAsserts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Asserts received by this router. Asserts are multicast to all routers on a network. This counter is incremented by all routers that receive an assert, not only those routers that are contesting the assert. Sivaramu, et al. Standards Track [Page 8] RFC 5060 PIM MIB January 2008 Discontinuities in the value of this counter can occur at re-initialization of the management system, for example, when the device is rebooted." REFERENCE "RFC 4601 section 4.6" ::= { pim 23 } pimLastAssertInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The interface on which this router most recently sent or received an assert, or zero if this router has not sent or received an assert." REFERENCE "RFC 4601 section 4.6" ::= { pim 24 } pimLastAssertGroupAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the multicast group address in the most recently sent or received assert. If this router has not sent or received an assert, then this object is set to unknown(0)." ::= { pim 25 } pimLastAssertGroupAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The multicast group address in the most recently sent or received assert. The InetAddressType is given by the pimLastAssertGroupAddressType object." ::= { pim 26 } pimLastAssertSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the source address in the most recently sent or received assert. If the most recent assert was (*,G), or if this router has not sent or received an assert, then this object is set to unknown(0)." ::= { pim 27 } Sivaramu, et al. Standards Track [Page 9] RFC 5060 PIM MIB January 2008 pimLastAssertSourceAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The source address in the most recently sent or received assert. The InetAddressType is given by the pimLastAssertSourceAddressType object." ::= { pim 28 } pimNeighborLossNotificationPeriod OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum time that must elapse between pimNeighborLoss notifications originated by this router. The maximum value 65535 represents an 'infinite' time, in which case, no pimNeighborLoss notifications are ever sent. The storage type of this object is determined by pimDeviceConfigStorageType." DEFVAL { 0 } ::= { pim 29 } pimNeighborLossCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of neighbor loss events that have occurred. This counter is incremented when the neighbor timer expires, and the router has no other neighbors on the same interface with the same IP version and a lower IP address than itself. This counter is incremented whenever a pimNeighborLoss notification would be generated. Discontinuities in the value of this counter can occur at re-initialization of the management system, for example, when the device is rebooted." REFERENCE "RFC 4601 section 4.3.2" ::= { pim 30 } pimInvalidRegisterNotificationPeriod OBJECT-TYPE SYNTAX Unsigned32 (10..65535) Sivaramu, et al. Standards Track [Page 10] RFC 5060 PIM MIB January 2008 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum time that must elapse between pimInvalidRegister notifications originated by this router. The default value of 65535 represents an 'infinite' time, in which case, no pimInvalidRegister notifications are ever sent. The non-zero minimum allowed value provides resilience against propagation of denial-of-service attacks from the data and control planes to the network management plane. The storage type of this object is determined by pimDeviceConfigStorageType." DEFVAL { 65535 } ::= { pim 31 } pimInvalidRegisterMsgsRcvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid PIM Register messages that have been received by this device. A PIM Register message is invalid if either o the destination address of the Register message does not match the Group to RP mapping on this device, or o this device believes the group address to be within an SSM address range, but this Register implies ASM usage. These conditions can occur transiently while RP mapping changes propagate through the network. If this counter is incremented repeatedly over several minutes, then there is a persisting configuration error that requires correction. The active Group to RP mapping on this device is specified by the object pimGroupMappingPimMode. If there is no such mapping, then the object pimGroupMappingPimMode is absent. The RP address contained in the invalid Register is pimInvalidRegisterRp. Multicast data carried by invalid Register messages is discarded. The discarded data is from a source directly Sivaramu, et al. Standards Track [Page 11] RFC 5060 PIM MIB January 2008 connected to pimInvalidRegisterOrigin, and is addressed to pimInvalidRegisterGroup. Discontinuities in the value of this counter can occur at re-initialization of the management system, for example, when the device is rebooted." REFERENCE "RFC 4601 section 4.4.2, RFC 3569, and 'IP Multicast MIB' (August 2007) ipMcastSsmRangeTable" ::= { pim 32 } pimInvalidRegisterAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type stored in pimInvalidRegisterOrigin, pimInvalidRegisterGroup, and pimInvalidRegisterRp. If no invalid Register messages have been received, then this object is set to unknown(0)." ::= { pim 33 } pimInvalidRegisterOrigin OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The source address of the last invalid Register message received by this device." ::= { pim 34 } pimInvalidRegisterGroup OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP multicast group address to which the last invalid Register message received by this device was addressed." ::= { pim 35 } pimInvalidRegisterRp OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The RP address to which the last invalid Register message received by this device was delivered." ::= { pim 36 } Sivaramu, et al. Standards Track [Page 12] RFC 5060 PIM MIB January 2008 pimInvalidJoinPruneNotificationPeriod OBJECT-TYPE SYNTAX Unsigned32 (10..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum time that must elapse between pimInvalidJoinPrune notifications originated by this router. The default value of 65535 represents an 'infinite' time, in which case, no pimInvalidJoinPrune notifications are ever sent. The non-zero minimum allowed value provides resilience against propagation of denial-of-service attacks from the control plane to the network management plane. The storage type of this object is determined by pimDeviceConfigStorageType." DEFVAL { 65535 } ::= { pim 37 } pimInvalidJoinPruneMsgsRcvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of invalid PIM Join/Prune messages that have been received by this device. A PIM Join/Prune message is invalid if either o the Group to RP mapping specified by this message does not match the Group to RP mapping on this device, or o this device believes the group address to be within an SSM address range, but this Join/Prune (*,G) or (S,G,rpt) implies ASM usage. These conditions can occur transiently while RP mapping changes propagate through the network. If this counter is incremented repeatedly over several minutes, then there is a persisting configuration error that requires correction. The active Group to RP mapping on this device is specified by the object pimGroupMappingPimMode. If there is no such mapping, then the object pimGroupMappingPimMode is absent. The RP address contained in the invalid Join/Prune is pimInvalidJoinPruneRp. Sivaramu, et al. Standards Track [Page 13] RFC 5060 PIM MIB January 2008 Invalid Join/Prune messages are discarded. This may result in loss of multicast data affecting listeners downstream of pimInvalidJoinPruneOrigin, for multicast data addressed to pimInvalidJoinPruneGroup. Discontinuities in the value of this counter can occur at re-initialization of the management system, for example, when the device is rebooted." REFERENCE "RFC 4601 section 4.5.2, RFC 3569, and 'IP Multicast MIB' (August 2007) ipMcastSsmRangeTable" ::= { pim 38 } pimInvalidJoinPruneAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type stored in pimInvalidJoinPruneOrigin, pimInvalidJoinPruneGroup, and pimInvalidJoinPruneRp. If no invalid Join/Prune messages have been received, this object is set to unknown(0)." ::= { pim 39 } pimInvalidJoinPruneOrigin OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The source address of the last invalid Join/Prune message received by this device." ::= { pim 40 } pimInvalidJoinPruneGroup OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP multicast group address carried in the last invalid Join/Prune message received by this device." ::= { pim 41 } pimInvalidJoinPruneRp OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The RP address carried in the last invalid Join/Prune Sivaramu, et al. Standards Track [Page 14] RFC 5060 PIM MIB January 2008 message received by this device." ::= { pim 42 } pimRPMappingNotificationPeriod OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum time that must elapse between pimRPMappingChange notifications originated by this router. The default value of 65535 represents an 'infinite' time, in which case, no pimRPMappingChange notifications are ever sent. The storage type of this object is determined by pimDeviceConfigStorageType." DEFVAL { 65535 } ::= { pim 43 } pimRPMappingChangeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of changes to active RP mappings on this device. Information about active RP mappings is available in pimGroupMappingTable. Only changes to active mappings cause this counter to be incremented. That is, changes that modify the pimGroupMappingEntry with the highest precedence for a group (lowest value of pimGroupMappingPrecedence). Such changes may result from manual configuration of this device, or from automatic RP mapping discovery methods including the PIM Bootstrap Router (BSR) mechanism. Discontinuities in the value of this counter can occur at re-initialization of the management system, for example, when the device is rebooted." REFERENCE "RFC 5059" ::= { pim 44 } pimInterfaceElectionNotificationPeriod OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current Sivaramu, et al. Standards Track [Page 15] RFC 5060 PIM MIB January 2008 DESCRIPTION "The minimum time that must elapse between pimInterfaceElection notifications originated by this router. The default value of 65535 represents an 'infinite' time, in which case, no pimInterfaceElection notifications are ever sent. The storage type of this object is determined by pimDeviceConfigStorageType." DEFVAL { 65535 } ::= { pim 45 } pimInterfaceElectionWinCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this device has been elected DR or DF on any interface. Elections occur frequently on newly-active interfaces, as triggered Hellos establish adjacencies. This counter is not incremented for elections on an interface until the first periodic Hello has been sent. If this router is the DR or DF at the time of sending the first periodic Hello after interface activation, then this counter is incremented (once) at that time. Discontinuities in the value of this counter can occur at re-initialization of the management system, for example, when the device is rebooted." REFERENCE "RFC 4601 section 4.3.2 and RFC 5015 section 3.5.2" ::= { pim 46 } pimRefreshInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The interval between successive State Refresh messages sent by an Originator. This timer period is called the RefreshInterval in the PIM-DM specification. This object is used only by PIM-DM. The storage type of this object is determined by pimDeviceConfigStorageType." REFERENCE "RFC 3973 section 4.8" Sivaramu, et al. Standards Track [Page 16] RFC 5060 PIM MIB January 2008 DEFVAL { 60 } ::= { pim 47 } pimDeviceConfigStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "The storage type used for the global PIM configuration of this device, comprised of the objects listed below. If this storage type takes the value 'permanent', write-access to the listed objects need not be allowed. The objects described by this storage type are: pimKeepalivePeriod, pimRegisterSuppressionTime, pimNeighborLossNotificationPeriod, pimInvalidRegisterNotificationPeriod, pimInvalidJoinPruneNotificationPeriod, pimRPMappingNotificationPeriod, pimInterfaceElectionNotificationPeriod, and pimRefreshInterval." DEFVAL { nonVolatile } ::= { pim 48 } -- -- The PIM Interface Table -- pimInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF PimInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the router's PIM interfaces. PIM is enabled on all interfaces listed in this table." ::= { pim 1 } pimInterfaceEntry OBJECT-TYPE SYNTAX PimInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimInterfaceTable. This entry is preserved on agent restart." INDEX { pimInterfaceIfIndex, pimInterfaceIPVersion } ::= { pimInterfaceTable 1 } Sivaramu, et al. Standards Track [Page 17] RFC 5060 PIM MIB January 2008 PimInterfaceEntry ::= SEQUENCE { pimInterfaceIfIndex InterfaceIndex, pimInterfaceIPVersion InetVersion, pimInterfaceAddressType InetAddressType, pimInterfaceAddress InetAddress, pimInterfaceGenerationIDValue Unsigned32, pimInterfaceDR InetAddress, pimInterfaceDRPriority Unsigned32, pimInterfaceDRPriorityEnabled TruthValue, pimInterfaceHelloInterval Unsigned32, pimInterfaceTrigHelloInterval Unsigned32, pimInterfaceHelloHoldtime Unsigned32, pimInterfaceJoinPruneInterval Unsigned32, pimInterfaceJoinPruneHoldtime Unsigned32, pimInterfaceDFElectionRobustness Unsigned32, pimInterfaceLanDelayEnabled TruthValue, pimInterfacePropagationDelay Unsigned32, pimInterfaceOverrideInterval Unsigned32, pimInterfaceEffectPropagDelay Unsigned32, pimInterfaceEffectOverrideIvl Unsigned32, pimInterfaceSuppressionEnabled TruthValue, pimInterfaceBidirCapable TruthValue, pimInterfaceDomainBorder TruthValue, pimInterfaceStubInterface TruthValue, pimInterfacePruneLimitInterval Unsigned32, pimInterfaceGraftRetryInterval Unsigned32, pimInterfaceSRPriorityEnabled TruthValue, pimInterfaceStatus RowStatus, pimInterfaceStorageType StorageType } pimInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of this PIM interface." ::= { pimInterfaceEntry 1 } pimInterfaceIPVersion OBJECT-TYPE SYNTAX InetVersion MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version of this PIM interface. A physical interface may be configured in multiple modes concurrently, e.g., IPv4 and IPv6; however, the traffic is considered to be logically separate." Sivaramu, et al. Standards Track [Page 18] RFC 5060 PIM MIB January 2008 ::= { pimInterfaceEntry 2 } pimInterfaceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of this PIM interface." ::= { pimInterfaceEntry 3 } pimInterfaceAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The primary IP address of this router on this PIM interface. The InetAddressType is given by the pimInterfaceAddressType object." REFERENCE "RFC 4601 sections 4.1.6, 4.3.1-4.3.4, and 4.5.1" ::= { pimInterfaceEntry 4 } pimInterfaceGenerationIDValue OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the Generation ID this router inserted in the last PIM Hello message it sent on this interface." REFERENCE "RFC 4601 section 4.3.1" ::= { pimInterfaceEntry 5 } pimInterfaceDR OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The primary IP address of the Designated Router on this PIM interface. The InetAddressType is given by the pimInterfaceAddressType object." REFERENCE "RFC 4601 section 4.3" ::= { pimInterfaceEntry 6 } pimInterfaceDRPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Designated Router Priority value inserted into the DR Sivaramu, et al. Standards Track [Page 19] RFC 5060 PIM MIB January 2008 Priority option in PIM Hello messages transmitted on this interface. Numerically higher values for this object indicate higher priorities." REFERENCE "RFC 4601 section 4.3.2" DEFVAL { 1 } ::= { pimInterfaceEntry 7 } pimInterfaceDRPriorityEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if all routers on this interface are using the DR Priority option." REFERENCE "RFC 4601 section 4.3.2" ::= { pimInterfaceEntry 8 } pimInterfaceHelloInterval OBJECT-TYPE SYNTAX Unsigned32 (0..18000) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency at which PIM Hello messages are transmitted on this interface. This object corresponds to the 'Hello_Period' timer value defined in the PIM-SM specification. A value of zero represents an 'infinite' interval, and indicates that periodic PIM Hello messages should not be sent on this interface." REFERENCE "RFC 4601 section 9" DEFVAL { 30 } ::= { pimInterfaceEntry 9 } pimInterfaceTrigHelloInterval OBJECT-TYPE SYNTAX Unsigned32 (0..60) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum time before this router sends a triggered PIM Hello message on this interface. This object corresponds to the 'Trigered_Hello_Delay' timer value defined in the PIM-SM specification. A value of zero has no special meaning and indicates that triggered PIM Hello messages should always be sent immediately." REFERENCE "RFC 4601 section 4.11" DEFVAL { 5 } ::= { pimInterfaceEntry 10 } Sivaramu, et al. Standards Track [Page 20] RFC 5060 PIM MIB January 2008 pimInterfaceHelloHoldtime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value set in the Holdtime field of PIM Hello messages transmitted on this interface. A value of 65535 represents an 'infinite' holdtime. Implementations are recommended to use a holdtime that is 3.5 times the value of pimInterfaceHelloInterval, or 65535 if pimInterfaceHelloInterval is set to zero." REFERENCE "RFC 4601 sections 4.3.2 and 4.9.2" DEFVAL { 105 } ::= { pimInterfaceEntry 11 } pimInterfaceJoinPruneInterval OBJECT-TYPE SYNTAX Unsigned32 (0..18000) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency at which this router sends PIM Join/Prune messages on this PIM interface. This object corresponds to the 't_periodic' timer value defined in the PIM-SM specification. A value of zero represents an 'infinite' interval, and indicates that periodic PIM Join/Prune messages should not be sent on this interface." REFERENCE "RFC 4601 section 4.11" DEFVAL { 60 } ::= { pimInterfaceEntry 12 } pimInterfaceJoinPruneHoldtime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value inserted into the Holdtime field of a PIM Join/Prune message sent on this interface. A value of 65535 represents an 'infinite' holdtime. Implementations are recommended to use a holdtime that is 3.5 times the value of pimInterfaceJoinPruneInterval, or 65535 if pimInterfaceJoinPruneInterval is set to zero. PIM-DM implementations are recommended to use the value of pimInterfacePruneLimitInterval." REFERENCE "RFC 4601 sections 4.5.3 and 4.9.5" DEFVAL { 210 } Sivaramu, et al. Standards Track [Page 21] RFC 5060 PIM MIB January 2008 ::= { pimInterfaceEntry 13 } pimInterfaceDFElectionRobustness OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum number of PIM DF-Election messages that must be lost in order for DF election on this interface to fail." DEFVAL { 3 } ::= { pimInterfaceEntry 14 } pimInterfaceLanDelayEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if all routers on this interface are using the LAN Prune Delay option." REFERENCE "RFC 4601 sections 4.3.3 and 4.9.2" ::= { pimInterfaceEntry 15 } pimInterfacePropagationDelay OBJECT-TYPE SYNTAX Unsigned32 (0..32767) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The expected propagation delay between PIM routers on this network or link. This router inserts this value into the Propagation_Delay field of the LAN Prune Delay option in the PIM Hello messages sent on this interface. Implementations SHOULD enforce a lower bound on the permitted values for this object to allow for scheduling and processing delays within the local router." DEFVAL { 500 } ::= { pimInterfaceEntry 16 } pimInterfaceOverrideInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value this router inserts into the Override_Interval field of the LAN Prune Delay option in the PIM Hello Sivaramu, et al. Standards Track [Page 22] RFC 5060 PIM MIB January 2008 messages it sends on this interface. When overriding a prune, PIM routers pick a random timer duration up to the value of this object. The more PIM routers that are active on a network, the more likely it is that the prune will be overridden after a small proportion of this time has elapsed. The more PIM routers are active on this network, the larger this object should be to obtain an optimal spread of prune override latencies." REFERENCE "RFC 4601 section 4.3.3" DEFVAL { 2500 } ::= { pimInterfaceEntry 17 } pimInterfaceEffectPropagDelay OBJECT-TYPE SYNTAX Unsigned32 (0..32767) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The Effective Propagation Delay on this interface. This object is always 500 if pimInterfaceLanDelayEnabled is FALSE." REFERENCE "RFC 4601 section 4.3.3" ::= { pimInterfaceEntry 18 } pimInterfaceEffectOverrideIvl OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The Effective Override Interval on this interface. This object is always 2500 if pimInterfaceLanDelayEnabled is FALSE." REFERENCE "RFC 4601 section 4.3.3" ::= { pimInterfaceEntry 19 } pimInterfaceSuppressionEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether join suppression is enabled on this interface. This object is always TRUE if pimInterfaceLanDelayEnabled is FALSE." REFERENCE "RFC 4601 section 4.3.3" Sivaramu, et al. Standards Track [Page 23] RFC 5060 PIM MIB January 2008 ::= { pimInterfaceEntry 20 } pimInterfaceBidirCapable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if all routers on this interface are using the Bidirectional-PIM Capable option." REFERENCE "RFC 5015 section 3.2 and 3.7.4" ::= { pimInterfaceEntry 21 } pimInterfaceDomainBorder OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Whether or not this interface is a PIM domain border. This includes acting as a border for PIM Bootstrap Router (BSR) messages, if the BSR mechanism is in use." DEFVAL { false } ::= { pimInterfaceEntry 22 } pimInterfaceStubInterface OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Whether this interface is a 'stub interface'. If this object is set to TRUE, then no PIM packets are sent out this interface, and any received PIM packets are ignored. Setting this object to TRUE is a security measure for interfaces towards untrusted hosts. This allows an interface to be configured for use with IGMP (Internet Group Management Protocol) or MLD (Multicast Listener Discovery) only, which protects the PIM router from forged PIM messages on the interface. To communicate with other PIM routers using this interface, this object must remain set to FALSE. Changing the value of this object while the interface is operational causes PIM to be disabled and then re-enabled on this interface." REFERENCE "RFC 3376, RFC 3810" DEFVAL { false } ::= { pimInterfaceEntry 23 } Sivaramu, et al. Standards Track [Page 24] RFC 5060 PIM MIB January 2008 pimInterfacePruneLimitInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum interval that must transpire between two successive Prunes sent by a router. This object corresponds to the 't_limit' timer value defined in the PIM-DM specification. This object is used only by PIM-DM." REFERENCE "RFC 3973 section 4.8" DEFVAL { 60 } ::= { pimInterfaceEntry 24 } pimInterfaceGraftRetryInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum interval that must transpire between two successive Grafts sent by a router. This object corresponds to the 'Graft_Retry_Period' timer value defined in the PIM-DM specification. This object is used only by PIM-DM." REFERENCE "RFC 3973 section 4.8" DEFVAL { 3 } ::= { pimInterfaceEntry 25 } pimInterfaceSRPriorityEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if all routers on this interface are using the State Refresh option. This object is used only by PIM-DM." ::= { pimInterfaceEntry 26 } pimInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry. Creating the entry enables PIM on the interface; destroying the entry disables PIM on the interface. This status object can be set to active(1) without setting Sivaramu, et al. Standards Track [Page 25] RFC 5060 PIM MIB January 2008 any other columnar objects in this entry. All writeable objects in this entry can be modified when the status of this entry is active(1)." ::= { pimInterfaceEntry 27 } pimInterfaceStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { pimInterfaceEntry 28 } -- -- The PIM Neighbor Table -- pimNeighborTable OBJECT-TYPE SYNTAX SEQUENCE OF PimNeighborEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the router's PIM neighbors." ::= { pim 2 } pimNeighborEntry OBJECT-TYPE SYNTAX PimNeighborEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimNeighborTable." INDEX { pimNeighborIfIndex, pimNeighborAddressType, pimNeighborAddress } ::= { pimNeighborTable 1 } PimNeighborEntry ::= SEQUENCE { pimNeighborIfIndex InterfaceIndex, pimNeighborAddressType InetAddressType, pimNeighborAddress InetAddress, pimNeighborGenerationIDPresent TruthValue, pimNeighborGenerationIDValue Unsigned32, pimNeighborUpTime TimeTicks, pimNeighborExpiryTime TimeTicks, Sivaramu, et al. Standards Track [Page 26] RFC 5060 PIM MIB January 2008 pimNeighborDRPriorityPresent TruthValue, pimNeighborDRPriority Unsigned32, pimNeighborLanPruneDelayPresent TruthValue, pimNeighborTBit TruthValue, pimNeighborPropagationDelay Unsigned32, pimNeighborOverrideInterval Unsigned32, pimNeighborBidirCapable TruthValue, pimNeighborSRCapable TruthValue } pimNeighborIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex for the interface used to reach this PIM neighbor." ::= { pimNeighborEntry 1 } pimNeighborAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of this PIM neighbor." ::= { pimNeighborEntry 2 } pimNeighborAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The primary IP address of this PIM neighbor. The InetAddressType is given by the pimNeighborAddressType object." ::= { pimNeighborEntry 3 } pimNeighborGenerationIDPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if this neighbor is using the Generation ID option." REFERENCE "RFC 4601 section 4.3.1" ::= { pimNeighborEntry 4 } pimNeighborGenerationIDValue OBJECT-TYPE Sivaramu, et al. Standards Track [Page 27] RFC 5060 PIM MIB January 2008 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the Generation ID from the last PIM Hello message received from this neighbor. This object is always zero if pimNeighborGenerationIDPresent is FALSE." REFERENCE "RFC 4601 section 4.3.1" ::= { pimNeighborEntry 5 } pimNeighborUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this PIM neighbor (last) became a neighbor of the local router." ::= { pimNeighborEntry 6 } pimNeighborExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time remaining before this PIM neighbor will time out. The value zero indicates that this PIM neighbor will never time out." ::= { pimNeighborEntry 7 } pimNeighborDRPriorityPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if this neighbor is using the DR Priority option." REFERENCE "RFC 4601 section 4.3.2" ::= { pimNeighborEntry 8 } pimNeighborDRPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the Designated Router Priority from the last PIM Hello message received from this neighbor. This object is always zero if pimNeighborDRPriorityPresent is FALSE." REFERENCE "RFC 4601 section 4.3.2" Sivaramu, et al. Standards Track [Page 28] RFC 5060 PIM MIB January 2008 ::= { pimNeighborEntry 9 } pimNeighborLanPruneDelayPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if this neighbor is using the LAN Prune Delay option." REFERENCE "RFC 4601 section 4.3.3" ::= { pimNeighborEntry 10 } pimNeighborTBit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the T bit was set in the LAN Prune Delay option received from this neighbor. The T bit specifies the ability of the neighbor to disable join suppression. This object is always TRUE if pimNeighborLanPruneDelayPresent is FALSE." REFERENCE "RFC 4601 section 4.3.3" ::= { pimNeighborEntry 11 } pimNeighborPropagationDelay OBJECT-TYPE SYNTAX Unsigned32 (0..32767) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the Propagation_Delay field of the LAN Prune Delay option received from this neighbor. This object is always zero if pimNeighborLanPruneDelayPresent is FALSE." REFERENCE "RFC 4601 section 4.3.3" ::= { pimNeighborEntry 12 } pimNeighborOverrideInterval OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the Override_Interval field of the LAN Prune Delay option received from this neighbor. This object is always zero if pimNeighborLanPruneDelayPresent is FALSE." REFERENCE "RFC 4601 section 4.3.3" ::= { pimNeighborEntry 13 } pimNeighborBidirCapable OBJECT-TYPE Sivaramu, et al. Standards Track [Page 29] RFC 5060 PIM MIB January 2008 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if this neighbor is using the Bidirectional-PIM Capable option." REFERENCE "RFC 5015 section 3.2 and 3.7.4" ::= { pimNeighborEntry 14 } pimNeighborSRCapable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if this neighbor is using the State Refresh Capable option. This object is used only by PIM-DM." REFERENCE "RFC 3973 section 4.3.4" ::= { pimNeighborEntry 15 } -- -- The PIM Neighbor Secondary Address Table -- pimNbrSecAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF PimNbrSecAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the secondary addresses advertised by each PIM neighbor (on a subset of the rows of the pimNeighborTable defined above)." REFERENCE "RFC 4601 section 4.3.4" ::= { pim 3 } pimNbrSecAddressEntry OBJECT-TYPE SYNTAX PimNbrSecAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimNbrSecAddressTable." INDEX { pimNbrSecAddressIfIndex, pimNbrSecAddressType, pimNbrSecAddressPrimary, pimNbrSecAddress } ::= { pimNbrSecAddressTable 1 } PimNbrSecAddressEntry ::= SEQUENCE { Sivaramu, et al. Standards Track [Page 30] RFC 5060 PIM MIB January 2008 pimNbrSecAddressIfIndex InterfaceIndex, pimNbrSecAddressType InetAddressType, pimNbrSecAddressPrimary InetAddress, pimNbrSecAddress InetAddress } pimNbrSecAddressIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex for the interface used to reach this PIM neighbor." ::= { pimNbrSecAddressEntry 1 } pimNbrSecAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of this PIM neighbor." ::= { pimNbrSecAddressEntry 2 } pimNbrSecAddressPrimary OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The primary IP address of this PIM neighbor. The InetAddressType is given by the pimNbrSecAddressType object." ::= { pimNbrSecAddressEntry 3 } pimNbrSecAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary IP address of this PIM neighbor. The InetAddressType is given by the pimNbrSecAddressType object." ::= { pimNbrSecAddressEntry 4 } -- -- The PIM (*,G) State Table -- pimStarGTable OBJECT-TYPE Sivaramu, et al. Standards Track [Page 31] RFC 5060 PIM MIB January 2008 SYNTAX SEQUENCE OF PimStarGEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the non-interface specific (*,G) state that PIM has." REFERENCE "RFC 4601 section 4.1.3" ::= { pim 4 } pimStarGEntry OBJECT-TYPE SYNTAX PimStarGEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimStarGTable." INDEX { pimStarGAddressType, pimStarGGrpAddress } ::= { pimStarGTable 1 } PimStarGEntry ::= SEQUENCE { pimStarGAddressType InetAddressType, pimStarGGrpAddress InetAddress, pimStarGUpTime TimeTicks, pimStarGPimMode PimMode, pimStarGRPAddressType InetAddressType, pimStarGRPAddress InetAddress, pimStarGPimModeOrigin PimGroupMappingOriginType, pimStarGRPIsLocal TruthValue, pimStarGUpstreamJoinState INTEGER, pimStarGUpstreamJoinTimer TimeTicks, pimStarGUpstreamNeighborType InetAddressType, pimStarGUpstreamNeighbor InetAddress, pimStarGRPFIfIndex InterfaceIndexOrZero, pimStarGRPFNextHopType InetAddressType, pimStarGRPFNextHop InetAddress, pimStarGRPFRouteProtocol IANAipRouteProtocol, pimStarGRPFRouteAddress InetAddress, pimStarGRPFRoutePrefixLength InetAddressPrefixLength, pimStarGRPFRouteMetricPref Unsigned32, pimStarGRPFRouteMetric Unsigned32 } pimStarGAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of this multicast group." Sivaramu, et al. Standards Track [Page 32] RFC 5060 PIM MIB January 2008 ::= { pimStarGEntry 1 } pimStarGGrpAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group address. The InetAddressType is given by the pimStarGAddressType object." ::= { pimStarGEntry 2 } pimStarGUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was created by the local router." ::= { pimStarGEntry 3 } pimStarGPimMode OBJECT-TYPE SYNTAX PimMode { asm(3), bidir(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether this entry represents an ASM (Any Source Multicast, used with PIM-SM) or BIDIR-PIM group." ::= { pimStarGEntry 4 } pimStarGRPAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the Rendezvous Point (RP), or unknown(0) if the RP address is unknown." ::= { pimStarGEntry 5 } pimStarGRPAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the Rendezvous Point (RP) for the group. The InetAddressType is given by the pimStarGRPAddressType." ::= { pimStarGEntry 6 } pimStarGPimModeOrigin OBJECT-TYPE SYNTAX PimGroupMappingOriginType Sivaramu, et al. Standards Track [Page 33] RFC 5060 PIM MIB January 2008 MAX-ACCESS read-only STATUS current DESCRIPTION "The mechanism by which the PIM mode and RP for the group were learned." ::= { pimStarGEntry 7 } pimStarGRPIsLocal OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router is the RP for the group." ::= { pimStarGEntry 8 } pimStarGUpstreamJoinState OBJECT-TYPE SYNTAX INTEGER { notJoined (1), joined (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router should join the RP tree for the group. This corresponds to the state of the upstream (*,G) state machine in the PIM-SM specification." REFERENCE "RFC 4601 section 4.5.6" ::= { pimStarGEntry 9 } pimStarGUpstreamJoinTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the local router next sends a periodic (*,G) Join message on pimStarGRPFIfIndex. This timer is called the (*,G) Upstream Join Timer in the PIM-SM specification. This object is zero if the timer is not running." REFERENCE "RFC 4601 section 4.10" ::= { pimStarGEntry 10 } pimStarGUpstreamNeighborType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The primary address type of the upstream neighbor, or Sivaramu, et al. Standards Track [Page 34] RFC 5060 PIM MIB January 2008 unknown(0) if the upstream neighbor address is unknown or is not a PIM neighbor." ::= { pimStarGEntry 11 } pimStarGUpstreamNeighbor OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The primary address of the neighbor on pimStarGRPFIfIndex that the local router is sending periodic (*,G) Join messages to. The InetAddressType is given by the pimStarGUpstreamNeighborType object. This address is called RPF'(*,G) in the PIM-SM specification." REFERENCE "RFC 4601 section 4.1.6" ::= { pimStarGEntry 12 } pimStarGRPFIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the Reverse Path Forwarding (RPF) interface towards the RP, or zero if the RPF interface is unknown." ::= { pimStarGEntry 13 } pimStarGRPFNextHopType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the RPF next hop towards the RP, or unknown(0) if the RPF next hop is unknown." ::= { pimStarGEntry 14 } pimStarGRPFNextHop OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the RPF next hop towards the RP. The InetAddressType is given by the pimStarGRPFNextHopType object. This address is called MRIB.next_hop(RP(G)) in the PIM-SM specification." REFERENCE "RFC 4601 section 4.5.5" ::= { pimStarGEntry 15 } Sivaramu, et al. Standards Track [Page 35] RFC 5060 PIM MIB January 2008 pimStarGRPFRouteProtocol OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which the route used to find the RPF interface towards the RP was learned." ::= { pimStarGEntry 16 } pimStarGRPFRouteAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address that, when combined with the corresponding value of pimStarGRPFRoutePrefixLength, identifies the route used to find the RPF interface towards the RP. The InetAddressType is given by the pimStarGRPFNextHopType object. This address object is only significant up to pimStarGRPFRoutePrefixLength bits. The remainder of the address bits are zero." ::= { pimStarGEntry 17 } pimStarGRPFRoutePrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "The prefix length that, when combined with the corresponding value of pimStarGRPFRouteAddress, identifies the route used to find the RPF interface towards the RP. The InetAddressType is given by the pimStarGRPFNextHopType object." ::= { pimStarGEntry 18 } pimStarGRPFRouteMetricPref OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The metric preference of the route used to find the RPF interface towards the RP." ::= { pimStarGEntry 19 } pimStarGRPFRouteMetric OBJECT-TYPE SYNTAX Unsigned32 Sivaramu, et al. Standards Track [Page 36] RFC 5060 PIM MIB January 2008 MAX-ACCESS read-only STATUS current DESCRIPTION "The routing metric of the route used to find the RPF interface towards the RP." ::= { pimStarGEntry 20 } -- -- The PIM (*,G,I) State Table -- pimStarGITable OBJECT-TYPE SYNTAX SEQUENCE OF PimStarGIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interface-specific (*,G) state that PIM has." REFERENCE "RFC 4601 section 4.1.3" ::= { pim 5 } pimStarGIEntry OBJECT-TYPE SYNTAX PimStarGIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimStarGITable." INDEX { pimStarGAddressType, pimStarGGrpAddress, pimStarGIIfIndex } ::= { pimStarGITable 1 } PimStarGIEntry ::= SEQUENCE { pimStarGIIfIndex InterfaceIndex, pimStarGIUpTime TimeTicks, pimStarGILocalMembership TruthValue, pimStarGIJoinPruneState INTEGER, pimStarGIPrunePendingTimer TimeTicks, pimStarGIJoinExpiryTimer TimeTicks, pimStarGIAssertState INTEGER, pimStarGIAssertTimer TimeTicks, pimStarGIAssertWinnerAddressType InetAddressType, pimStarGIAssertWinnerAddress InetAddress, pimStarGIAssertWinnerMetricPref Unsigned32, pimStarGIAssertWinnerMetric Unsigned32 } pimStarGIIfIndex OBJECT-TYPE Sivaramu, et al. Standards Track [Page 37] RFC 5060 PIM MIB January 2008 SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the interface that this entry corresponds to." ::= { pimStarGIEntry 1 } pimStarGIUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was created by the local router." ::= { pimStarGIEntry 2 } pimStarGILocalMembership OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router has (*,G) local membership on this interface (resulting from a mechanism such as IGMP or MLD). This corresponds to local_receiver_include(*,G,I) in the PIM-SM specification." REFERENCE "RFC 3376, RFC 3810, and RFC 4601 section 4.1.6" ::= { pimStarGIEntry 3 } pimStarGIJoinPruneState OBJECT-TYPE SYNTAX INTEGER { noInfo (1), join (2), prunePending (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state resulting from (*,G) Join/Prune messages received on this interface. This corresponds to the state of the downstream per-interface (*,G) state machine in the PIM-SM specification." REFERENCE "RFC 4601 section 4.5.2" ::= { pimStarGIEntry 4 } pimStarGIPrunePendingTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current Sivaramu, et al. Standards Track [Page 38] RFC 5060 PIM MIB January 2008 DESCRIPTION "The time remaining before the local router acts on a (*,G) Prune message received on this interface, during which the router is waiting to see whether another downstream router will override the Prune message. This timer is called the (*,G) Prune-Pending Timer in the PIM-SM specification. This object is zero if the timer is not running." REFERENCE "RFC 4601 section 4.5.1" ::= { pimStarGIEntry 5 } pimStarGIJoinExpiryTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before (*,G) Join state for this interface expires. This timer is called the (*,G) Join Expiry Timer in the PIM-SM specification. This object is zero if the timer is not running. A value of 'FFFFFFFF'h indicates an infinite expiry time." REFERENCE "RFC 4601 section 4.10" ::= { pimStarGIEntry 6 } pimStarGIAssertState OBJECT-TYPE SYNTAX INTEGER { noInfo (1), iAmAssertWinner (2), iAmAssertLoser (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The (*,G) Assert state for this interface. This corresponds to the state of the per-interface (*,G) Assert state machine in the PIM-SM specification. If pimStarGPimMode is 'bidir', this object must be 'noInfo'." REFERENCE "RFC 4601 section 4.6.2" ::= { pimStarGIEntry 7 } pimStarGIAssertTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "If pimStarGIAssertState is 'iAmAssertWinner', this is the time remaining before the local router next sends a (*,G) Assert message on this interface. If pimStarGIAssertState is 'iAmAssertLoser', this is the time remaining before the Sivaramu, et al. Standards Track [Page 39] RFC 5060 PIM MIB January 2008 (*,G) Assert state expires. If pimStarGIAssertState is 'noInfo', this is zero. This timer is called the (*,G) Assert Timer in the PIM-SM specification." REFERENCE "RFC 4601 section 4.6.2" ::= { pimStarGIEntry 8 } pimStarGIAssertWinnerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "If pimStarGIAssertState is 'iAmAssertLoser', this is the address type of the assert winner; otherwise, this object is unknown(0)." ::= { pimStarGIEntry 9 } pimStarGIAssertWinnerAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "If pimStarGIAssertState is 'iAmAssertLoser', this is the address of the assert winner. The InetAddressType is given by the pimStarGIAssertWinnerAddressType object." ::= { pimStarGIEntry 10 } pimStarGIAssertWinnerMetricPref OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "If pimStarGIAssertState is 'iAmAssertLoser', this is the metric preference of the route to the RP advertised by the assert winner; otherwise, this object is zero." ::= { pimStarGIEntry 11 } pimStarGIAssertWinnerMetric OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If pimStarGIAssertState is 'iAmAssertLoser', this is the routing metric of the route to the RP advertised by the assert winner; otherwise, this object is zero." ::= { pimStarGIEntry 12 } -- -- The PIM (S,G) State Table Sivaramu, et al. Standards Track [Page 40] RFC 5060 PIM MIB January 2008 -- pimSGTable OBJECT-TYPE SYNTAX SEQUENCE OF PimSGEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the non-interface specific (S,G) state that PIM has." REFERENCE "RFC 4601 section 4.1.4" ::= { pim 6 } pimSGEntry OBJECT-TYPE SYNTAX PimSGEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimSGTable." INDEX { pimSGAddressType, pimSGGrpAddress, pimSGSrcAddress } ::= { pimSGTable 1 } PimSGEntry ::= SEQUENCE { pimSGAddressType InetAddressType, pimSGGrpAddress InetAddress, pimSGSrcAddress InetAddress, pimSGUpTime TimeTicks, pimSGPimMode PimMode, pimSGUpstreamJoinState INTEGER, pimSGUpstreamJoinTimer TimeTicks, pimSGUpstreamNeighbor InetAddress, pimSGRPFIfIndex InterfaceIndexOrZero, pimSGRPFNextHopType InetAddressType, pimSGRPFNextHop InetAddress, pimSGRPFRouteProtocol IANAipRouteProtocol, pimSGRPFRouteAddress InetAddress, pimSGRPFRoutePrefixLength InetAddressPrefixLength, pimSGRPFRouteMetricPref Unsigned32, pimSGRPFRouteMetric Unsigned32, pimSGSPTBit TruthValue, pimSGKeepaliveTimer TimeTicks, pimSGDRRegisterState INTEGER, pimSGDRRegisterStopTimer TimeTicks, pimSGRPRegisterPMBRAddressType InetAddressType, pimSGRPRegisterPMBRAddress InetAddress, pimSGUpstreamPruneState INTEGER, pimSGUpstreamPruneLimitTimer TimeTicks, Sivaramu, et al. Standards Track [Page 41] RFC 5060 PIM MIB January 2008 pimSGOriginatorState INTEGER, pimSGSourceActiveTimer TimeTicks, pimSGStateRefreshTimer TimeTicks } pimSGAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the source and multicast group for this entry." ::= { pimSGEntry 1 } pimSGGrpAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group address for this entry. The InetAddressType is given by the pimSGAddressType object." ::= { pimSGEntry 2 } pimSGSrcAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The source address for this entry. The InetAddressType is given by the pimSGAddressType object." ::= { pimSGEntry 3 } pimSGUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was created by the local router." ::= { pimSGEntry 4 } pimSGPimMode OBJECT-TYPE SYNTAX PimMode { ssm(2), asm(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether pimSGGrpAddress is an SSM (Source Specific Multicast, used with PIM-SM) or ASM (Any Source Multicast, used with PIM-SM) group." Sivaramu, et al. Standards Track [Page 42] RFC 5060 PIM MIB January 2008 REFERENCE "RFC 4601 section 4.5.2, RFC 3569, and 'IP Multicast MIB' (August 2007) ipMcastSsmRangeTable" ::= { pimSGEntry 5 } pimSGUpstreamJoinState OBJECT-TYPE SYNTAX INTEGER { notJoined (1), joined (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router should join the shortest-path tree for the source and group represented by this entry. This corresponds to the state of the upstream (S,G) state machine in the PIM-SM specification." REFERENCE "RFC 4601 section 4.5.7" ::= { pimSGEntry 6 } pimSGUpstreamJoinTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the local router next sends a periodic (S,G) Join message on pimSGRPFIfIndex. This timer is called the (S,G) Upstream Join Timer in the PIM-SM specification. This object is zero if the timer is not running." REFERENCE "RFC 4601 sections 4.10 and 4.11" ::= { pimSGEntry 7 } pimSGUpstreamNeighbor OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The primary address of the neighbor on pimSGRPFIfIndex that the local router is sending periodic (S,G) Join messages to. This is zero if the RPF next hop is unknown or is not a PIM neighbor. The InetAddressType is given by the pimSGAddressType object. This address is called RPF'(S,G) in the PIM-SM specification." REFERENCE "RFC 4601 section 4.1.6" ::= { pimSGEntry 8 } pimSGRPFIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero Sivaramu, et al. Standards Track [Page 43] RFC 5060 PIM MIB January 2008 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the RPF interface towards the source, or zero if the RPF interface is unknown." ::= { pimSGEntry 9 } pimSGRPFNextHopType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the RPF next hop towards the source, or unknown(0) if the RPF next hop is unknown." ::= { pimSGEntry 10 } pimSGRPFNextHop OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the RPF next hop towards the source. The InetAddressType is given by the pimSGRPFNextHopType. This address is called MRIB.next_hop(S) in the PIM-SM specification." REFERENCE "RFC 4601 section 4.5.5" ::= { pimSGEntry 11 } pimSGRPFRouteProtocol OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which the route used to find the RPF interface towards the source was learned." ::= { pimSGEntry 12 } pimSGRPFRouteAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address that, when combined with the corresponding value of pimSGRPFRoutePrefixLength, identifies the route used to find the RPF interface towards the source. The InetAddressType is given by the pimSGRPFNextHopType object. This address object is only significant up to Sivaramu, et al. Standards Track [Page 44] RFC 5060 PIM MIB January 2008 pimSGRPFRoutePrefixLength bits. The remainder of the address bits are zero." ::= { pimSGEntry 13 } pimSGRPFRoutePrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "The prefix length that, when combined with the corresponding value of pimSGRPFRouteAddress, identifies the route used to find the RPF interface towards the source. The InetAddressType is given by the pimSGRPFNextHopType object." ::= { pimSGEntry 14 } pimSGRPFRouteMetricPref OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The metric preference of the route used to find the RPF interface towards the source." ::= { pimSGEntry 15 } pimSGRPFRouteMetric OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The routing metric of the route used to find the RPF interface towards the source." ::= { pimSGEntry 16 } pimSGSPTBit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the SPT bit is set; and therefore whether forwarding is taking place on the shortest-path tree." ::= { pimSGEntry 17 } pimSGKeepaliveTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION Sivaramu, et al. Standards Track [Page 45] RFC 5060 PIM MIB January 2008 "The time remaining before this (S,G) state expires, in the absence of explicit (S,G) local membership or (S,G) Join messages received to maintain it. This timer is called the (S,G) Keepalive Timer in the PIM-SM specification." REFERENCE "RFC 4601 section 4.1.4" ::= { pimSGEntry 18 } pimSGDRRegisterState OBJECT-TYPE SYNTAX INTEGER { noInfo (1), join (2), joinPending (3), prune (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router should encapsulate (S,G) data packets in Register messages and send them to the RP. This corresponds to the state of the per-(S,G) Register state machine in the PIM-SM specification. This object is always 'noInfo' unless pimSGPimMode is 'asm'." REFERENCE "RFC 4601 section 4.4.1" ::= { pimSGEntry 19 } pimSGDRRegisterStopTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGDRRegisterState is 'prune', this is the time remaining before the local router sends a Null-Register message to the RP. If pimSGDRRegisterState is 'joinPending', this is the time remaining before the local router resumes encapsulating data packets and sending them to the RP. Otherwise, this is zero. This timer is called the Register-Stop Timer in the PIM-SM specification." REFERENCE "RFC 4601 section 4.4" ::= { pimSGEntry 20 } pimSGRPRegisterPMBRAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the first PIM Multicast Border Router to send a Register message with the Border bit set. This Sivaramu, et al. Standards Track [Page 46] RFC 5060 PIM MIB January 2008 object is unknown(0) if the local router is not the RP for the group." ::= { pimSGEntry 21 } pimSGRPRegisterPMBRAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the first PIM Multicast Border Router to send a Register message with the Border bit set. The InetAddressType is given by the pimSGRPRegisterPMBRAddressType object." ::= { pimSGEntry 22 } pimSGUpstreamPruneState OBJECT-TYPE SYNTAX INTEGER { forwarding (1), ackpending (2), pruned (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router has pruned itself from the tree. This corresponds to the state of the upstream prune (S,G) state machine in the PIM-DM specification. This object is used only by PIM-DM." REFERENCE "RFC 3973 section 4.4.1" ::= { pimSGEntry 23 } pimSGUpstreamPruneLimitTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the local router may send a (S,G) Prune message on pimSGRPFIfIndex. This timer is called the (S,G) Prune Limit Timer in the PIM-DM specification. This object is zero if the timer is not running. This object is used only by PIM-DM." REFERENCE "RFC 2973 section 4.8" ::= { pimSGEntry 24 } pimSGOriginatorState OBJECT-TYPE SYNTAX INTEGER { notOriginator (1), originator (2) Sivaramu, et al. Standards Track [Page 47] RFC 5060 PIM MIB January 2008 } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the router is an originator for an (S,G) message flow. This corresponds to the state of the per-(S,G) Originator state machine in the PIM-DM specification. This object is used only by PIM-DM." REFERENCE "RFC 3973 section 4.5.2" ::= { pimSGEntry 25 } pimSGSourceActiveTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGOriginatorState is 'originator', this is the time remaining before the local router reverts to a notOriginator state. Otherwise, this is zero. This timer is called the Source Active Timer in the PIM-DM specification. This object is used only by PIM-DM." REFERENCE "RFC 3973 section 4.8" ::= { pimSGEntry 26 } pimSGStateRefreshTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGOriginatorState is 'originator', this is the time remaining before the local router sends a State Refresh message. Otherwise, this is zero. This timer is called the State Refresh Timer in the PIM-DM specification. This object is used only by PIM-DM." REFERENCE "RFC 3973 section 4.8" ::= { pimSGEntry 27 } -- -- The PIM (S,G,I) State Table -- pimSGITable OBJECT-TYPE SYNTAX SEQUENCE OF PimSGIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interface-specific (S,G) state that PIM has." Sivaramu, et al. Standards Track [Page 48] RFC 5060 PIM MIB January 2008 REFERENCE "RFC 4601 section 4.1.4" ::= { pim 7 } pimSGIEntry OBJECT-TYPE SYNTAX PimSGIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimSGITable." INDEX { pimSGAddressType, pimSGGrpAddress, pimSGSrcAddress, pimSGIIfIndex } ::= { pimSGITable 1 } PimSGIEntry ::= SEQUENCE { pimSGIIfIndex InterfaceIndex, pimSGIUpTime TimeTicks, pimSGILocalMembership TruthValue, pimSGIJoinPruneState INTEGER, pimSGIPrunePendingTimer TimeTicks, pimSGIJoinExpiryTimer TimeTicks, pimSGIAssertState INTEGER, pimSGIAssertTimer TimeTicks, pimSGIAssertWinnerAddressType InetAddressType, pimSGIAssertWinnerAddress InetAddress, pimSGIAssertWinnerMetricPref Unsigned32, pimSGIAssertWinnerMetric Unsigned32 } pimSGIIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the interface that this entry corresponds to." ::= { pimSGIEntry 1 } pimSGIUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was created by the local router." ::= { pimSGIEntry 2 } pimSGILocalMembership OBJECT-TYPE Sivaramu, et al. Standards Track [Page 49] RFC 5060 PIM MIB January 2008 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router has (S,G) local membership on this interface (resulting from a mechanism such as IGMP or MLD). This corresponds to local_receiver_include(S,G,I) in the PIM-SM specification." REFERENCE "RFC 3376, RFC 3810, RFC 4601 sections 4.1.6, 4.6.1, and 4.6.2" ::= { pimSGIEntry 3 } pimSGIJoinPruneState OBJECT-TYPE SYNTAX INTEGER { noInfo (1), join (2), prunePending (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state resulting from (S,G) Join/Prune messages received on this interface. This corresponds to the state of the downstream per-interface (S,G) state machine in the PIM-SM and PIM-DM specification." REFERENCE "RFC 4601 section 4.5.3 and RFC 3973 section 4.4.2" ::= { pimSGIEntry 4 } pimSGIPrunePendingTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the local router acts on an (S,G) Prune message received on this interface, during which the router is waiting to see whether another downstream router will override the Prune message. This timer is called the (S,G) Prune-Pending Timer in the PIM-SM specification. This object is zero if the timer is not running." REFERENCE "RFC 4601 sections 4.5.3 and 4.5.4" ::= { pimSGIEntry 5 } pimSGIJoinExpiryTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before (S,G) Join state for this Sivaramu, et al. Standards Track [Page 50] RFC 5060 PIM MIB January 2008 interface expires. This timer is called the (S,G) Join Expiry Timer in the PIM-SM specification. This object is zero if the timer is not running. A value of 'FFFFFFFF'h indicates an infinite expiry time. This timer is called the (S,G) Prune Timer in the PIM-DM specification." REFERENCE "RFC 4601 section 4.10 and RFC 3973 section 4.8" ::= { pimSGIEntry 6 } pimSGIAssertState OBJECT-TYPE SYNTAX INTEGER { noInfo (1), iAmAssertWinner (2), iAmAssertLoser (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The (S,G) Assert state for this interface. This corresponds to the state of the per-interface (S,G) Assert state machine in the PIM-SM specification." REFERENCE "RFC 4601 section 4.6.1" ::= { pimSGIEntry 7 } pimSGIAssertTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGIAssertState is 'iAmAssertWinner', this is the time remaining before the local router next sends a (S,G) Assert message on this interface. If pimSGIAssertState is 'iAmAssertLoser', this is the time remaining before the (S,G) Assert state expires. If pimSGIAssertState is 'noInfo', this is zero. This timer is called the (S,G) Assert Timer in the PIM-SM specification." REFERENCE "RFC 4601 section 4.6.1" ::= { pimSGIEntry 8 } pimSGIAssertWinnerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGIAssertState is 'iAmAssertLoser', this is the address type of the assert winner; otherwise, this object is unknown(0)." ::= { pimSGIEntry 9 } Sivaramu, et al. Standards Track [Page 51] RFC 5060 PIM MIB January 2008 pimSGIAssertWinnerAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGIAssertState is 'iAmAssertLoser', this is the address of the assert winner. The InetAddressType is given by the pimSGIAssertWinnerAddressType object." ::= { pimSGIEntry 10 } pimSGIAssertWinnerMetricPref OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGIAssertState is 'iAmAssertLoser', this is the metric preference of the route to the source advertised by the assert winner; otherwise, this object is zero." ::= { pimSGIEntry 11 } pimSGIAssertWinnerMetric OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If pimSGIAssertState is 'iAmAssertLoser', this is the routing metric of the route to the source advertised by the assert winner; otherwise, this object is zero." ::= { pimSGIEntry 12 } -- -- The PIM (S,G,rpt) State Table -- pimSGRptTable OBJECT-TYPE SYNTAX SEQUENCE OF PimSGRptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the non-interface specific (S,G,rpt) state that PIM has." REFERENCE "RFC 4601 section 4.1.5" ::= { pim 8 } pimSGRptEntry OBJECT-TYPE SYNTAX PimSGRptEntry MAX-ACCESS not-accessible STATUS current Sivaramu, et al. Standards Track [Page 52] RFC 5060 PIM MIB January 2008 DESCRIPTION "An entry (conceptual row) in the pimSGRptTable." INDEX { pimStarGAddressType, pimStarGGrpAddress, pimSGRptSrcAddress } ::= { pimSGRptTable 1 } PimSGRptEntry ::= SEQUENCE { pimSGRptSrcAddress InetAddress, pimSGRptUpTime TimeTicks, pimSGRptUpstreamPruneState INTEGER, pimSGRptUpstreamOverrideTimer TimeTicks } pimSGRptSrcAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The source address for this entry. The InetAddressType is given by the pimStarGAddressType object." ::= { pimSGRptEntry 1 } pimSGRptUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was created by the local router." ::= { pimSGRptEntry 2 } pimSGRptUpstreamPruneState OBJECT-TYPE SYNTAX INTEGER { rptNotJoined (1), pruned (2), notPruned (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router should prune the source off the RP tree. This corresponds to the state of the upstream (S,G,rpt) state machine for triggered messages in the PIM-SM specification." REFERENCE "RFC 4601 section 4.5.9" ::= { pimSGRptEntry 3 } pimSGRptUpstreamOverrideTimer OBJECT-TYPE Sivaramu, et al. Standards Track [Page 53] RFC 5060 PIM MIB January 2008 SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the local router sends a triggered (S,G,rpt) Join message on pimStarGRPFIfIndex. This timer is called the (S,G,rpt) Upstream Override Timer in the PIM-SM specification. This object is zero if the timer is not running." REFERENCE "RFC 4601 section 4.5.9" ::= { pimSGRptEntry 4 } -- -- The PIM (S,G,rpt,I) State Table -- pimSGRptITable OBJECT-TYPE SYNTAX SEQUENCE OF PimSGRptIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interface-specific (S,G,rpt) state that PIM has." REFERENCE "RFC 4601 section 4.1.5" ::= { pim 9 } pimSGRptIEntry OBJECT-TYPE SYNTAX PimSGRptIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimSGRptITable." INDEX { pimStarGAddressType, pimStarGGrpAddress, pimSGRptSrcAddress, pimSGRptIIfIndex } ::= { pimSGRptITable 1 } PimSGRptIEntry ::= SEQUENCE { pimSGRptIIfIndex InterfaceIndex, pimSGRptIUpTime TimeTicks, pimSGRptILocalMembership TruthValue, pimSGRptIJoinPruneState INTEGER, pimSGRptIPrunePendingTimer TimeTicks, pimSGRptIPruneExpiryTimer TimeTicks } pimSGRptIIfIndex OBJECT-TYPE Sivaramu, et al. Standards Track [Page 54] RFC 5060 PIM MIB January 2008 SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex of the interface that this entry corresponds to." ::= { pimSGRptIEntry 1 } pimSGRptIUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was created by the local router." ::= { pimSGRptIEntry 2 } pimSGRptILocalMembership OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router has both (*,G) include local membership and (S,G) exclude local membership on this interface (resulting from a mechanism such as IGMP or MLD). This corresponds to local_receiver_exclude(S,G,I) in the PIM-SM specification." REFERENCE "RFC 3376, RFC 3810, RFC 4601 section 4.1.6" ::= { pimSGRptIEntry 3 } pimSGRptIJoinPruneState OBJECT-TYPE SYNTAX INTEGER { noInfo (1), prune (2), prunePending (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state resulting from (S,G,rpt) Join/Prune messages received on this interface. This corresponds to the state of the downstream per-interface (S,G,rpt) state machine in the PIM-SM specification." REFERENCE "RFC 4601 section 4.5.4" ::= { pimSGRptIEntry 4 } pimSGRptIPrunePendingTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Sivaramu, et al. Standards Track [Page 55] RFC 5060 PIM MIB January 2008 STATUS current DESCRIPTION "The time remaining before the local router starts pruning this source off the RP tree. This timer is called the (S,G,rpt) Prune-Pending Timer in the PIM-SM specification. This object is zero if the timer is not running." REFERENCE "RFC 4601 section 4.5.4" ::= { pimSGRptIEntry 5 } pimSGRptIPruneExpiryTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before (S,G,rpt) Prune state for this interface expires. This timer is called the (S,G,rpt) Prune Expiry Timer in the PIM-SM specification. This object is zero if the timer is not running. A value of 'FFFFFFFF'h indicates an infinite expiry time." REFERENCE "RFC 4601 section 4.5.4" ::= { pimSGRptIEntry 6 } -- -- The PIM Bidir DF-Election Table -- pimBidirDFElectionTable OBJECT-TYPE SYNTAX SEQUENCE OF PimBidirDFElectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the per-RP Designated Forwarder (DF) Election state for each interface for all the RPs in BIDIR mode." REFERENCE "RFC 5015 section 3.5" ::= { pim 10 } pimBidirDFElectionEntry OBJECT-TYPE SYNTAX PimBidirDFElectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimBidirDFElectionTable." INDEX { pimBidirDFElectionAddressType, pimBidirDFElectionRPAddress, pimBidirDFElectionIfIndex } ::= { pimBidirDFElectionTable 1 } Sivaramu, et al. Standards Track [Page 56] RFC 5060 PIM MIB January 2008 PimBidirDFElectionEntry ::= SEQUENCE { pimBidirDFElectionAddressType InetAddressType, pimBidirDFElectionRPAddress InetAddress, pimBidirDFElectionIfIndex InterfaceIndex, pimBidirDFElectionWinnerAddressType InetAddressType, pimBidirDFElectionWinnerAddress InetAddress, pimBidirDFElectionWinnerUpTime TimeTicks, pimBidirDFElectionWinnerMetricPref Unsigned32, pimBidirDFElectionWinnerMetric Unsigned32, pimBidirDFElectionState INTEGER, pimBidirDFElectionStateTimer TimeTicks } pimBidirDFElectionAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the RP for which the DF state is being maintained." ::= { pimBidirDFElectionEntry 1 } pimBidirDFElectionRPAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the RP for which the DF state is being maintained. The InetAddressType is given by the pimBidirDFElectionAddressType object." ::= { pimBidirDFElectionEntry 2 } pimBidirDFElectionIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex for the interface for which the DF state is being maintained." ::= { pimBidirDFElectionEntry 3 } pimBidirDFElectionWinnerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The primary address type of the winner of the DF Election process. A value of unknown(0) indicates there is currently Sivaramu, et al. Standards Track [Page 57] RFC 5060 PIM MIB January 2008 no DF." ::= { pimBidirDFElectionEntry 4 } pimBidirDFElectionWinnerAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The primary IP address of the winner of the DF Election process. The InetAddressType is given by the pimBidirDFElectionWinnerAddressType object." ::= { pimBidirDFElectionEntry 5 } pimBidirDFElectionWinnerUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since the current winner (last) became elected as the DF for this RP." ::= { pimBidirDFElectionEntry 6 } pimBidirDFElectionWinnerMetricPref OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The metric preference advertised by the DF Winner, or zero if there is currently no DF." ::= { pimBidirDFElectionEntry 7 } pimBidirDFElectionWinnerMetric OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The metric advertised by the DF Winner, or zero if there is currently no DF." ::= { pimBidirDFElectionEntry 8 } pimBidirDFElectionState OBJECT-TYPE SYNTAX INTEGER { dfOffer(1), dfLose(2), dfWinner(3), dfBackoff(4) } MAX-ACCESS read-only Sivaramu, et al. Standards Track [Page 58] RFC 5060 PIM MIB January 2008 STATUS current DESCRIPTION "The state of this interface with respect to DF-Election for this RP. The states correspond to the ones defined in the BIDIR-PIM specification." REFERENCE "RFC 5015 section 3.5.3.1" ::= { pimBidirDFElectionEntry 9 } pimBidirDFElectionStateTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time remaining after which the local router will expire the current DF state represented by pimBidirDFElectionState." ::= { pimBidirDFElectionEntry 10 } -- -- The PIM Static RP Table -- pimStaticRPTable OBJECT-TYPE SYNTAX SEQUENCE OF PimStaticRPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to manage static configuration of RPs. If the group prefixes configured for two or more rows in this table overlap, the row with the greatest value of pimStaticRPGrpPrefixLength is used for the overlapping range." REFERENCE "RFC 4601 section 3.7" ::= { pim 11 } pimStaticRPEntry OBJECT-TYPE SYNTAX PimStaticRPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimStaticRPTable. This entry is preserved on agent restart." INDEX { pimStaticRPAddressType, pimStaticRPGrpAddress, pimStaticRPGrpPrefixLength } ::= { pimStaticRPTable 1 } Sivaramu, et al. Standards Track [Page 59] RFC 5060 PIM MIB January 2008 PimStaticRPEntry ::= SEQUENCE { pimStaticRPAddressType InetAddressType, pimStaticRPGrpAddress InetAddress, pimStaticRPGrpPrefixLength InetAddressPrefixLength, pimStaticRPRPAddress InetAddress, pimStaticRPPimMode PimMode, pimStaticRPOverrideDynamic TruthValue, pimStaticRPPrecedence Unsigned32, pimStaticRPRowStatus RowStatus, pimStaticRPStorageType StorageType } pimStaticRPAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of this entry." ::= { pimStaticRPEntry 1 } pimStaticRPGrpAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group address that, when combined with pimStaticRPGrpPrefixLength, gives the group prefix for this entry. The InetAddressType is given by the pimStaticRPAddressType object. This address object is only significant up to pimStaticRPGrpPrefixLength bits. The remainder of the address bits are zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry." ::= { pimStaticRPEntry 2 } pimStaticRPGrpPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength (4..128) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group prefix length that, when combined with pimStaticRPGrpAddress, gives the group prefix for this entry. The InetAddressType is given by the pimStaticRPAddressType object. If pimStaticRPAddressType is 'ipv4' or 'ipv4z', this object must be in the range 4..32. Sivaramu, et al. Standards Track [Page 60] RFC 5060 PIM MIB January 2008 If pimStaticRPGrpAddressType is 'ipv6' or 'ipv6z', this object must be in the range 8..128." ::= { pimStaticRPEntry 3 } pimStaticRPRPAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address of the RP to be used for groups within this group prefix. The InetAddressType is given by the pimStaticRPAddressType object." ::= { pimStaticRPEntry 4 } pimStaticRPPimMode OBJECT-TYPE SYNTAX PimMode { ssm(2), asm(3), bidir(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The PIM mode to be used for groups in this group prefix. If this object is set to ssm(2), then pimStaticRPRPAddress must be set to zero. No RP operations are ever possible for PIM Mode SSM." REFERENCE "RFC 4601 section 3.7, RFC 3569, and 'IP Multicast MIB' (August 2007) ipMcastSsmRangeTable" DEFVAL { asm } ::= { pimStaticRPEntry 5 } pimStaticRPOverrideDynamic OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Whether this static RP configuration will override other group mappings in this group prefix. If this object is TRUE, then it will override: - RP information learned dynamically for groups in this group prefix. - RP information configured in pimStaticRPTable with pimStaticRPOverrideDynamic set to FALSE. See pimGroupMappingTable for details." DEFVAL { false } ::= { pimStaticRPEntry 6 } Sivaramu, et al. Standards Track [Page 61] RFC 5060 PIM MIB January 2008 pimStaticRPPrecedence OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value for pimGroupMappingPrecedence to be used for this static RP configuration. This allows fine control over which configuration is overridden by this static configuration. If pimStaticRPOverrideDynamic is set to TRUE, all dynamic RP configuration is overridden by this static configuration, whatever the value of this object. The absolute values of this object have a significance only on the local router and do not need to be coordinated with other routers. A setting of this object may have different effects when applied to other routers. Do not use this object unless fine control of static RP behavior on the local router is required." ::= { pimStaticRPEntry 7 } pimStaticRPRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which rows in this table can be created and destroyed. This status object cannot be set to active(1) before a valid value has been written to pimStaticRPRPAddress. All writeable objects in this entry can be modified when the status of this entry is active(1)." ::= { pimStaticRPEntry 8 } pimStaticRPStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { pimStaticRPEntry 9 } Sivaramu, et al. Standards Track [Page 62] RFC 5060 PIM MIB January 2008 -- -- The PIM Anycast-RP Set Table -- pimAnycastRPSetTable OBJECT-TYPE SYNTAX SEQUENCE OF PimAnycastRPSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to manage Anycast-RP via PIM Register messages, as opposed to via other protocols such as MSDP (Multicast Source Discovery Protocol). Entries must be configured in this table if and only if the local router is a member of one or more Anycast-RP sets, that is, one or more Anycast-RP addresses are assigned to the local router. Note that if using static RP configuration, this is in addition to, not instead of, the pimStaticRPTable entries that must be configured for the Anycast-RPs. The set of rows with the same values of both pimAnycastRPSetAddressType and pimAnycastRPSetAnycastAddress corresponds to the Anycast-RP set for that Anycast-RP address. When an Anycast-RP set configuration is active, one entry per pimAnycastRPSetAnycastAddress corresponds to the local router. The local router is identified by the pimAnycastRpSetLocalRouter object. That entry determines the source address used by the local router when forwarding PIM Register messages within the Anycast-RP set." REFERENCE "RFC 4610, RFC 3618" ::= { pim 12 } pimAnycastRPSetEntry OBJECT-TYPE SYNTAX PimAnycastRPSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry corresponds to a single router within a particular Anycast-RP set. This entry is preserved on agent restart." INDEX { pimAnycastRPSetAddressType, pimAnycastRPSetAnycastAddress, pimAnycastRPSetRouterAddress } ::= { pimAnycastRPSetTable 1 } PimAnycastRPSetEntry ::= SEQUENCE { Sivaramu, et al. Standards Track [Page 63] RFC 5060 PIM MIB January 2008 pimAnycastRPSetAddressType InetAddressType, pimAnycastRPSetAnycastAddress InetAddress, pimAnycastRPSetRouterAddress InetAddress, pimAnycastRPSetLocalRouter TruthValue, pimAnycastRPSetRowStatus RowStatus, pimAnycastRPSetStorageType StorageType } pimAnycastRPSetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the Anycast-RP address and router address." ::= { pimAnycastRPSetEntry 1 } pimAnycastRPSetAnycastAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Anycast-RP address. The InetAddressType is given by the pimAnycastRPSetAddressType object." ::= { pimAnycastRPSetEntry 2 } pimAnycastRPSetRouterAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of a router that is a member of the Anycast-RP set. The InetAddressType is given by the pimAnycastRPSetAddressType object. This address differs from pimAnycastRPSetAnycastAddress. Equal values for these two addresses in a single entry are not permitted. That would cause a Register loop." ::= { pimAnycastRPSetEntry 3 } pimAnycastRPSetLocalRouter OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether this entry corresponds to the local router." ::= { pimAnycastRPSetEntry 4 } Sivaramu, et al. Standards Track [Page 64] RFC 5060 PIM MIB January 2008 pimAnycastRPSetRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which rows in this table can be created and destroyed. This status object can be set to active(1) without setting any other columnar objects in this entry. All writeable objects in this entry can be modified when the status of this entry is active(1)." ::= { pimAnycastRPSetEntry 5 } pimAnycastRPSetStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { pimAnycastRPSetEntry 6 } -- -- The PIM Group Mapping Table -- pimGroupMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PimGroupMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing mappings from multicast group prefixes to the PIM mode and RP address to use for groups within that group prefix. Rows in this table are created for a variety of reasons, indicated by the value of the pimGroupMappingOrigin object. - Rows with a pimGroupMappingOrigin value of 'fixed' are created automatically by the router at startup, to correspond to the well-defined prefixes of link-local and unroutable group addresses. These rows are never destroyed. Sivaramu, et al. Standards Track [Page 65] RFC 5060 PIM MIB January 2008 - Rows with a pimGroupMappingOrigin value of 'embedded' are created by the router to correspond to group prefixes that are to be treated as being in Embedded-RP format. - Rows with a pimGroupMappingOrigin value of 'configRp' are created and destroyed as a result of rows in the pimStaticRPTable being created and destroyed. - Rows with a pimGroupMappingOrigin value of 'configSsm' are created and destroyed as a result of configuration of SSM address ranges to the local router. - Rows with a pimGroupMappingOrigin value of 'bsr' are created as a result of running the PIM Bootstrap Router (BSR) mechanism. If the local router is not the elected BSR, these rows are created to correspond to group prefixes in the PIM Bootstrap messages received from the elected BSR. If the local router is the elected BSR, these rows are created to correspond to group prefixes in the PIM Bootstrap messages that the local router sends. In either case, these rows are destroyed when the group prefixes are timed out by the BSR mechanism. - Rows with a pimGroupMappingOrigin value of 'other' are created and destroyed according to some other mechanism not specified here. Given the collection of rows in this table at any point in time, the PIM mode and RP address to use for a particular group is determined using the following algorithm. 1. From the set of all rows, the subset whose group prefix contains the group in question are selected. 2. If there are no such rows, then the group mapping is undefined. 3. If there are multiple selected rows, and a subset is defined by pimStaticRPTable (pimGroupMappingOrigin value of 'configRp') with pimStaticRPOverrideDynamic set to TRUE, then this subset is selected. 4. From the selected subset of rows, the subset that have the greatest value of pimGroupMappingGrpPrefixLength are selected. 5. If there are still multiple selected rows, the subset that has the highest precedence (the lowest numerical Sivaramu, et al. Standards Track [Page 66] RFC 5060 PIM MIB January 2008 value for pimGroupMappingPrecedence) is selected. 6. If there are still multiple selected rows, the row selected is implementation dependent; the implementation might or might not apply the PIM hash function to select the row. 7. The group mode to use is given by the value of pimGroupMappingPimMode from the single selected row; the RP to use is given by the value of pimGroupMappingRPAddress, unless pimGroupMappingOrigin is 'embedded', in which case, the RP is extracted from the group address in question." REFERENCE "RFC 4601 section 3.7, RFC 3956, and RFC 4610" ::= { pim 13 } pimGroupMappingEntry OBJECT-TYPE SYNTAX PimGroupMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimGroupMappingTable." INDEX { pimGroupMappingOrigin, pimGroupMappingAddressType, pimGroupMappingGrpAddress, pimGroupMappingGrpPrefixLength, pimGroupMappingRPAddressType, pimGroupMappingRPAddress } ::= { pimGroupMappingTable 1 } PimGroupMappingEntry ::= SEQUENCE { pimGroupMappingOrigin PimGroupMappingOriginType, pimGroupMappingAddressType InetAddressType, pimGroupMappingGrpAddress InetAddress, pimGroupMappingGrpPrefixLength InetAddressPrefixLength, pimGroupMappingRPAddressType InetAddressType, pimGroupMappingRPAddress InetAddress, pimGroupMappingPimMode PimMode, pimGroupMappingPrecedence Unsigned32 } pimGroupMappingOrigin OBJECT-TYPE SYNTAX PimGroupMappingOriginType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mechanism by which this group mapping was learned." ::= { pimGroupMappingEntry 1 } Sivaramu, et al. Standards Track [Page 67] RFC 5060 PIM MIB January 2008 pimGroupMappingAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the IP multicast group prefix." ::= { pimGroupMappingEntry 2 } pimGroupMappingGrpAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address that, when combined with pimGroupMappingGrpPrefixLength, gives the group prefix for this mapping. The InetAddressType is given by the pimGroupMappingAddressType object. This address object is only significant up to pimGroupMappingGrpPrefixLength bits. The remainder of the address bits are zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry." ::= { pimGroupMappingEntry 3 } pimGroupMappingGrpPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength (4..128) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group prefix length that, when combined with pimGroupMappingGrpAddress, gives the group prefix for this mapping. The InetAddressType is given by the pimGroupMappingAddressType object. If pimGroupMappingAddressType is 'ipv4' or 'ipv4z', this object must be in the range 4..32. If pimGroupMappingAddressType is 'ipv6' or 'ipv6z', this object must be in the range 8..128." ::= { pimGroupMappingEntry 4 } pimGroupMappingRPAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the RP to be used for groups within this group prefix, or unknown(0) if no RP is to be used or Sivaramu, et al. Standards Track [Page 68] RFC 5060 PIM MIB January 2008 if the RP address is unknown. This object must be unknown(0) if pimGroupMappingPimMode is ssm(2), or if pimGroupMappingOrigin is embedded(6)." ::= { pimGroupMappingEntry 5 } pimGroupMappingRPAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (0|4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the RP to be used for groups within this group prefix. The InetAddressType is given by the pimGroupMappingRPAddressType object." ::= { pimGroupMappingEntry 6 } pimGroupMappingPimMode OBJECT-TYPE SYNTAX PimMode MAX-ACCESS read-only STATUS current DESCRIPTION "The PIM mode to be used for groups in this group prefix." ::= { pimGroupMappingEntry 7 } pimGroupMappingPrecedence OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The precedence of this row, used in the algorithm that determines which row applies to a given group address (described above). Numerically higher values for this object indicate lower precedences, with the value zero denoting the highest precedence. The absolute values of this object have a significance only on the local router and do not need to be coordinated with other routers." ::= { pimGroupMappingEntry 8 } -- -- PIM Notifications -- pimNeighborLoss NOTIFICATION-TYPE OBJECTS { pimNeighborUpTime } STATUS current DESCRIPTION "A pimNeighborLoss notification signifies the loss of an Sivaramu, et al. Standards Track [Page 69] RFC 5060 PIM MIB January 2008 adjacency with a neighbor. This notification should be generated when the neighbor timer expires, and the router has no other neighbors on the same interface with the same IP version and a lower IP address than itself. This notification is generated whenever the counter pimNeighborLossCount is incremented, subject to the rate limit specified by pimNeighborLossNotificationPeriod." REFERENCE "RFC 4601 section 4.3.2" ::= { pimNotifications 1 } pimInvalidRegister NOTIFICATION-TYPE OBJECTS { pimGroupMappingPimMode, pimInvalidRegisterAddressType, pimInvalidRegisterOrigin, pimInvalidRegisterGroup, pimInvalidRegisterRp } STATUS current DESCRIPTION "A pimInvalidRegister notification signifies that an invalid PIM Register message was received by this device. This notification is generated whenever the counter pimInvalidRegisterMsgsRcvd is incremented, subject to the rate limit specified by pimInvalidRegisterNotificationPeriod." REFERENCE "RFC 4601 section 4.4.2" ::= { pimNotifications 2 } pimInvalidJoinPrune NOTIFICATION-TYPE OBJECTS { pimGroupMappingPimMode, pimInvalidJoinPruneAddressType, pimInvalidJoinPruneOrigin, pimInvalidJoinPruneGroup, pimInvalidJoinPruneRp, pimNeighborUpTime } STATUS current DESCRIPTION "A pimInvalidJoinPrune notification signifies that an invalid PIM Join/Prune message was received by this device. This notification is generated whenever the counter pimInvalidJoinPruneMsgsRcvd is incremented, subject to the rate limit specified by pimInvalidJoinPruneNotificationPeriod." Sivaramu, et al. Standards Track [Page 70] RFC 5060 PIM MIB January 2008 REFERENCE "RFC 4601 section 4.5.2" ::= { pimNotifications 3 } pimRPMappingChange NOTIFICATION-TYPE OBJECTS { pimGroupMappingPimMode, pimGroupMappingPrecedence } STATUS current DESCRIPTION "A pimRPMappingChange notification signifies a change to the active RP mapping on this device. This notification is generated whenever the counter pimRPMappingChangeCount is incremented, subject to the rate limit specified by pimRPMappingChangeNotificationPeriod." ::= { pimNotifications 4 } pimInterfaceElection NOTIFICATION-TYPE OBJECTS { pimInterfaceAddressType, pimInterfaceAddress } STATUS current DESCRIPTION "A pimInterfaceElection notification signifies that a new DR or DF has been elected on a network. This notification is generated whenever the counter pimInterfaceElectionWinCount is incremented, subject to the rate limit specified by pimInterfaceElectionNotificationPeriod." REFERENCE "RFC 4601 section 4.3.2 and RFC 5015 section 3.5.2" ::= { pimNotifications 5 } -- -- Conformance Information -- pimMIBConformance OBJECT IDENTIFIER ::= { pimStdMIB 2 } pimMIBCompliances OBJECT IDENTIFIER ::= { pimMIBConformance 1 } pimMIBGroups OBJECT IDENTIFIER ::= { pimMIBConformance 2 } -- -- Compliance Statements -- pimMIBComplianceAsm MODULE-COMPLIANCE STATUS current DESCRIPTION Sivaramu, et al. Standards Track [Page 71] RFC 5060 PIM MIB January 2008 "The compliance statement for routers which are running PIM-SM (Sparse Mode)." MODULE -- this module MANDATORY-GROUPS { pimTopologyGroup, pimSsmGroup, pimRPConfigGroup, pimSmGroup } GROUP pimNotificationGroup DESCRIPTION "This group is optional." GROUP pimTuningParametersGroup DESCRIPTION "This group is optional." GROUP pimRouterStatisticsGroup DESCRIPTION "This group is optional." GROUP pimAnycastRpGroup DESCRIPTION "This group is optional." GROUP pimStaticRPPrecedenceGroup DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationObjects DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationGroup DESCRIPTION "This group is optional." GROUP pimDiagnosticsGroup DESCRIPTION "This group is optional." GROUP pimDeviceStorageGroup DESCRIPTION "This group is optional." ::= { pimMIBCompliances 1 } pimMIBComplianceBidir MODULE-COMPLIANCE STATUS current Sivaramu, et al. Standards Track [Page 72] RFC 5060 PIM MIB January 2008 DESCRIPTION "The compliance statement for routers which are running Bidir-PIM." MODULE -- this module MANDATORY-GROUPS { pimTopologyGroup, pimRPConfigGroup, pimSmGroup, pimBidirGroup } GROUP pimNotificationGroup DESCRIPTION "This group is optional." GROUP pimTuningParametersGroup DESCRIPTION "This group is optional." GROUP pimRouterStatisticsGroup DESCRIPTION "This group is optional." GROUP pimAnycastRpGroup DESCRIPTION "This group is optional." GROUP pimStaticRPPrecedenceGroup DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationObjects DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationGroup DESCRIPTION "This group is optional." GROUP pimDiagnosticsGroup DESCRIPTION "This group is optional." GROUP pimDeviceStorageGroup DESCRIPTION "This group is optional." ::= { pimMIBCompliances 2 } pimMIBComplianceSsm MODULE-COMPLIANCE Sivaramu, et al. Standards Track [Page 73] RFC 5060 PIM MIB January 2008 STATUS current DESCRIPTION "The compliance statement for routers which are running PIM SSM (Source Specific Multicast)." MODULE -- this module MANDATORY-GROUPS { pimTopologyGroup, pimSsmGroup } GROUP pimNotificationGroup DESCRIPTION "This group is optional." GROUP pimTuningParametersGroup DESCRIPTION "This group is optional." GROUP pimRouterStatisticsGroup DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationObjects DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationGroup DESCRIPTION "This group is optional." GROUP pimDiagnosticsGroup DESCRIPTION "This group is optional." GROUP pimDeviceStorageGroup DESCRIPTION "This group is optional." ::= { pimMIBCompliances 3 } pimMIBComplianceDm MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers which are running PIM-DM (Dense Mode)." MODULE -- this module MANDATORY-GROUPS { pimTopologyGroup, pimSsmGroup, pimRPConfigGroup, pimSmGroup, Sivaramu, et al. Standards Track [Page 74] RFC 5060 PIM MIB January 2008 pimDmGroup } GROUP pimNotificationGroup DESCRIPTION "This group is optional." GROUP pimTuningParametersGroup DESCRIPTION "This group is optional." GROUP pimRouterStatisticsGroup DESCRIPTION "This group is optional." GROUP pimAnycastRpGroup DESCRIPTION "This group is optional." GROUP pimStaticRPPrecedenceGroup DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationObjects DESCRIPTION "This group is optional." GROUP pimNetMgmtNotificationGroup DESCRIPTION "This group is optional." GROUP pimDiagnosticsGroup DESCRIPTION "This group is optional." GROUP pimDeviceStorageGroup DESCRIPTION "This group is optional." ::= { pimMIBCompliances 4 } -- -- Units of Conformance -- pimTopologyGroup OBJECT-GROUP OBJECTS { pimInterfaceAddressType, pimInterfaceAddress, pimInterfaceGenerationIDValue, Sivaramu, et al. Standards Track [Page 75] RFC 5060 PIM MIB January 2008 pimInterfaceDR, pimInterfaceDRPriorityEnabled, pimInterfaceHelloHoldtime, pimInterfaceJoinPruneHoldtime, pimInterfaceLanDelayEnabled, pimInterfaceEffectPropagDelay, pimInterfaceEffectOverrideIvl, pimInterfaceSuppressionEnabled, pimInterfaceBidirCapable, pimNeighborGenerationIDPresent, pimNeighborGenerationIDValue, pimNeighborUpTime, pimNeighborExpiryTime, pimNeighborDRPriorityPresent, pimNeighborDRPriority, pimNeighborLanPruneDelayPresent, pimNeighborTBit, pimNeighborPropagationDelay, pimNeighborOverrideInterval, pimNeighborBidirCapable, pimNbrSecAddress } STATUS current DESCRIPTION "A collection of read-only objects used to report local PIM topology." ::= { pimMIBGroups 1 } pimNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pimNeighborLoss } STATUS current DESCRIPTION "A collection of notifications for signaling important PIM events." ::= { pimMIBGroups 2 } pimTuningParametersGroup OBJECT-GROUP OBJECTS { pimKeepalivePeriod, pimRegisterSuppressionTime, pimInterfaceDRPriority, pimInterfaceHelloInterval, pimInterfaceTrigHelloInterval, pimInterfaceJoinPruneInterval, pimInterfacePropagationDelay, pimInterfaceOverrideInterval, pimInterfaceDomainBorder, pimInterfaceStubInterface, pimInterfaceStatus, Sivaramu, et al. Standards Track [Page 76] RFC 5060 PIM MIB January 2008 pimInterfaceStorageType } STATUS current DESCRIPTION "A collection of writeable objects used to configure PIM behavior and to tune performance." ::= { pimMIBGroups 3 } pimRouterStatisticsGroup OBJECT-GROUP OBJECTS { pimStarGEntries, pimStarGIEntries, pimSGEntries, pimSGIEntries, pimSGRptEntries, pimSGRptIEntries } STATUS current DESCRIPTION "A collection of statistics global to the PIM router." ::= { pimMIBGroups 4 } pimSsmGroup OBJECT-GROUP OBJECTS { pimSGUpTime, pimSGPimMode, pimSGUpstreamJoinState, pimSGUpstreamJoinTimer, pimSGUpstreamNeighbor, pimSGRPFIfIndex, pimSGRPFNextHopType, pimSGRPFNextHop, pimSGRPFRouteProtocol, pimSGRPFRouteAddress, pimSGRPFRoutePrefixLength, pimSGRPFRouteMetricPref, pimSGRPFRouteMetric, pimSGSPTBit, pimSGKeepaliveTimer, pimSGDRRegisterState, pimSGDRRegisterStopTimer, pimSGRPRegisterPMBRAddressType, pimSGRPRegisterPMBRAddress, pimSGIUpTime, pimSGILocalMembership, pimSGIJoinPruneState, pimSGIPrunePendingTimer, pimSGIJoinExpiryTimer, pimSGIAssertState, pimSGIAssertTimer, Sivaramu, et al. Standards Track [Page 77] RFC 5060 PIM MIB January 2008 pimSGIAssertWinnerAddressType, pimSGIAssertWinnerAddress, pimSGIAssertWinnerMetricPref, pimSGIAssertWinnerMetric } STATUS current DESCRIPTION "A collection of objects to support management of PIM routers running the PIM SSM (Source Specific Multicast) protocol, in PIM mode SM (Sparse Mode)." ::= { pimMIBGroups 5 } pimRPConfigGroup OBJECT-GROUP OBJECTS { pimStaticRPRPAddress, pimStaticRPPimMode, pimStaticRPOverrideDynamic, pimStaticRPRowStatus, pimStaticRPStorageType, pimGroupMappingPimMode, pimGroupMappingPrecedence } STATUS current DESCRIPTION "A collection of objects to support configuration of RPs (Rendezvous Points) and Group Mappings." ::= { pimMIBGroups 6 } pimSmGroup OBJECT-GROUP OBJECTS { pimStarGUpTime, pimStarGPimMode, pimStarGRPAddressType, pimStarGRPAddress, pimStarGPimModeOrigin, pimStarGRPIsLocal, pimStarGUpstreamJoinState, pimStarGUpstreamJoinTimer, pimStarGUpstreamNeighborType, pimStarGUpstreamNeighbor, pimStarGRPFIfIndex, pimStarGRPFNextHopType, pimStarGRPFNextHop, pimStarGRPFRouteProtocol, pimStarGRPFRouteAddress, pimStarGRPFRoutePrefixLength, pimStarGRPFRouteMetricPref, pimStarGRPFRouteMetric, pimStarGIUpTime, pimStarGILocalMembership, Sivaramu, et al. Standards Track [Page 78] RFC 5060 PIM MIB January 2008 pimStarGIJoinPruneState, pimStarGIPrunePendingTimer, pimStarGIJoinExpiryTimer, pimStarGIAssertState, pimStarGIAssertTimer, pimStarGIAssertWinnerAddressType, pimStarGIAssertWinnerAddress, pimStarGIAssertWinnerMetricPref, pimStarGIAssertWinnerMetric, pimSGRptUpTime, pimSGRptUpstreamPruneState, pimSGRptUpstreamOverrideTimer, pimSGRptIUpTime, pimSGRptILocalMembership, pimSGRptIJoinPruneState, pimSGRptIPrunePendingTimer, pimSGRptIPruneExpiryTimer } STATUS current DESCRIPTION "A collection of objects to support management of PIM routers running PIM-SM (Sparse Mode). The groups pimSsmGroup and pimRPConfigGroup are also required." ::= { pimMIBGroups 7 } pimBidirGroup OBJECT-GROUP OBJECTS { pimInterfaceDFElectionRobustness, pimBidirDFElectionWinnerAddressType, pimBidirDFElectionWinnerAddress, pimBidirDFElectionWinnerUpTime, pimBidirDFElectionWinnerMetricPref, pimBidirDFElectionWinnerMetric, pimBidirDFElectionState, pimBidirDFElectionStateTimer } STATUS current DESCRIPTION "A collection of objects to support management of PIM routers running BIDIR mode. The groups pimSsmGroup, pimSmGroup and pimRPConfigGroup are also required." ::= { pimMIBGroups 8 } pimAnycastRpGroup OBJECT-GROUP OBJECTS { pimAnycastRPSetLocalRouter, pimAnycastRPSetRowStatus, pimAnycastRPSetStorageType } STATUS current Sivaramu, et al. Standards Track [Page 79] RFC 5060 PIM MIB January 2008 DESCRIPTION "A collection of objects to support management of the PIM Anycast-RP mechanism." ::= { pimMIBGroups 9 } pimStaticRPPrecedenceGroup OBJECT-GROUP OBJECTS { pimStaticRPPrecedence } STATUS current DESCRIPTION "A collection of objects to allow fine control of interactions between static RP configuration and dynamically acquired group to RP mappings." ::= { pimMIBGroups 10 } pimNetMgmtNotificationObjects OBJECT-GROUP OBJECTS { pimInvalidRegisterNotificationPeriod, pimInvalidRegisterMsgsRcvd, pimInvalidRegisterAddressType, pimInvalidRegisterOrigin, pimInvalidRegisterGroup, pimInvalidRegisterRp, pimInvalidJoinPruneNotificationPeriod, pimInvalidJoinPruneMsgsRcvd, pimInvalidJoinPruneAddressType, pimInvalidJoinPruneOrigin, pimInvalidJoinPruneGroup, pimInvalidJoinPruneRp, pimRPMappingNotificationPeriod, pimRPMappingChangeCount, pimInterfaceElectionNotificationPeriod, pimInterfaceElectionWinCount } STATUS current DESCRIPTION "A collection of objects to support notification of PIM network management events." ::= { pimMIBGroups 11 } pimNetMgmtNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pimInvalidRegister, pimInvalidJoinPrune, pimRPMappingChange, pimInterfaceElection } STATUS current DESCRIPTION "A collection of notifications for signaling PIM network management events." Sivaramu, et al. Standards Track [Page 80] RFC 5060 PIM MIB January 2008 ::= { pimMIBGroups 12 } pimDiagnosticsGroup OBJECT-GROUP OBJECTS { pimInAsserts, pimOutAsserts, pimLastAssertInterface, pimLastAssertGroupAddressType, pimLastAssertGroupAddress, pimLastAssertSourceAddressType, pimLastAssertSourceAddress, pimNeighborLossNotificationPeriod, pimNeighborLossCount } STATUS current DESCRIPTION "Objects providing additional diagnostics related to a PIM router." ::= { pimMIBGroups 13 } pimDmGroup OBJECT-GROUP OBJECTS { pimRefreshInterval, pimInterfacePruneLimitInterval, pimInterfaceGraftRetryInterval, pimInterfaceSRPriorityEnabled, pimNeighborSRCapable, pimSGUpstreamPruneState, pimSGUpstreamPruneLimitTimer, pimSGOriginatorState, pimSGSourceActiveTimer, pimSGStateRefreshTimer } STATUS current DESCRIPTION "A collection of objects required for management of PIM Dense Mode (PIM-DM) function. The groups pimSsmGroup and pimSmGroup are also required." REFERENCE "RFC 3973" ::= { pimMIBGroups 14 } Sivaramu, et al. Standards Track [Page 81] RFC 5060 PIM MIB January 2008 pimDeviceStorageGroup OBJECT-GROUP OBJECTS { pimDeviceConfigStorageType } STATUS current DESCRIPTION "An object that specifies the volatility of global PIM configuration settings on this device." ::= { pimMIBGroups 15 } END 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: The following tables and objects could be employed to modify multicast routing behavior in a way that prevents, disrupts, or subverts services provided by the network, including (but not limited to) multicast data traffic delivery. For example, attacks can be envisaged that would pass nominated multicast data streams through a nominated location, without the sources or listeners becoming aware of this subversion. pimKeepalivePeriod pimRegisterSuppressionTime pimNeighborLossNotificationPeriod pimInvalidRegisterNotificationPeriod pimInvalidJoinPruneNotificationPeriod pimRPMappingNotificationPeriod pimInterfaceElectionNotificationPeriod pimRefreshInterval pimInterfaceTable pimInterfaceEntry pimInterfaceIfIndex pimInterfaceIPVersion pimInterfaceHelloInterval pimInterfaceTrigHelloInterval pimInterfaceJoinPruneInterval pimInterfaceDFElectionRobustness pimInterfaceHelloHoldtime pimInterfaceJoinPruneHoldtime pimInterfacePropagationDelay pimInterfaceOverrideInterval pimInterfaceDRPriority pimInterfaceDomainBorder pimInterfaceStatus pimInterfaceStubInterface pimInterfacePruneLimitInterval pimStaticRPTable pimStaticRPEntry pimStaticRPAddressType pimStaticRPGrpAddress pimStaticRPGrpPrefixLength pimStaticRPRPAddress pimStaticRPPimMode pimStaticRPOverrideDynamic pimStaticRPRowStatus pimStaticRPPrecedence pimAnycastRPSetTable pimAnycastRPSetEntry pimAnycastRPSetAddressType pimAnycastRPSetAnycastAddress pimAnycastRPSetRouterAddress Sivaramu, et al. Standards Track [Page 82] RFC 5060 PIM MIB January 2008 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: The following tables and objects could be employed to determine the topology, disposition, and composition of the network. This information may be commercially sensitive, and may also be used in preparation for attacks, including any of the attacks described above. The following tables and objects may also be used to determine whether multicast data is flowing in the network, or has flowed recently. They may also be used to determine the network location of senders and recipients. An attacker can apply 'traffic analysis' to this data. In some cases, the information revealed by traffic analyses can be as damaging as full knowledge of the data being transported. pimKeepalivePeriod pimRegisterSuppressionTime pimStarGEntries pimStarGIEntries pimSGEntries pimSGIEntries pimSGRptEntries pimSGRptIEntries pimOutAsserts pimInAsserts pimLastAssertInterface pimLastAssertGroupAddressType pimLastAssertGroupAddress pimLastAssertSourceAddressType pimLastAssertSourceAddress pimNeighborLossNotificationPeriod pimNeighborLossCount pimInvalidRegisterNotificationPeriod pimInvalidRegisterMsgsRcvd pimInvalidRegisterAddressType pimInvalidRegisterOrigin pimInvalidRegisterGroup pimInvalidRegisterRp pimInvalidJoinPruneNotificationPeriod pimInvalidJoinPruneMsgsRcvd pimInvalidJoinPruneAddressType pimInvalidJoinPruneOrigin pimInvalidJoinPruneGroup pimInvalidJoinPruneRp pimRPMappingNotificationPeriod pimRPMappingChangeCount pimInterfaceElectionNotificationPeriod pimInterfaceElectionWinCount pimRefreshInterval pimInterfaceTable pimInterfaceEntry pimInterfaceIfIndex pimInterfaceIPVersion pimInterfaceAddressType pimInterfaceAddress pimInterfaceDR pimInterfaceHelloInterval pimInterfaceTrigHelloInterval pimInterfaceJoinPruneInterval pimInterfaceDFElectionRobustness pimInterfaceHelloHoldtime pimInterfaceJoinPruneHoldtime pimInterfacePropagationDelay pimInterfaceOverrideInterval pimInterfaceGenerationIDValue pimInterfaceDRPriority pimInterfaceLanDelayEnabled pimInterfaceEffectPropagDelay pimInterfaceEffectOverrideIvl pimInterfaceSuppressionEnabled pimInterfaceBidirCapable pimInterfaceDRPriorityEnabled pimInterfaceDomainBorder pimInterfaceStatus pimInterfaceStubInterface Sivaramu, et al. Standards Track [Page 83] RFC 5060 PIM MIB January 2008 pimInterfacePruneLimitInterval pimInterfaceSRPriorityEnabled pimNeighborTable pimNeighborEntry pimNeighborIfIndex pimNeighborAddressType pimNeighborAddress pimNeighborUpTime pimNeighborExpiryTime pimNeighborLanPruneDelayPresent pimNeighborPropagationDelay pimNeighborOverrideInterval pimNeighborTBit pimNeighborGenerationIDPresent pimNeighborGenerationIDValue pimNeighborBidirCapable pimNeighborDRPriorityPresent pimNeighborDRPriority pimNeighborSRCapable pimNbrSecAddressTable pimNbrSecAddressEntry pimNbrSecAddressIfIndex pimNbrSecAddressType pimNbrSecAddressPrimary pimNbrSecAddress pimStarGTable pimStarGEntry pimStarGAddressType pimStarGGrpAddress pimStarGUpTime pimStarGPimMode pimStarGRPAddressType pimStarGRPAddress pimStarGPimModeOrigin pimStarGRPIsLocal pimStarGUpstreamJoinState pimStarGUpstreamJoinTimer pimStarGUpstreamNeighborType pimStarGUpstreamNeighbor pimStarGRPFIfIndex pimStarGRPFNextHopType pimStarGRPFNextHop pimStarGRPFRouteProtocol pimStarGRPFRouteAddress pimStarGRPFRoutePrefixLength pimStarGRPFRouteMetricPref pimStarGRPFRouteMetric pimStarGITable pimStarGIEntry pimStarGIIfIndex pimStarGIUpTime pimStarGILocalMembership pimStarGIJoinPruneState pimStarGIPrunePendingTimer pimStarGIJoinExpiryTimer pimStarGIAssertState pimStarGIAssertTimer pimStarGIAssertWinnerAddressType pimStarGIAssertWinnerAddress pimStarGIAssertWinnerMetricPref pimStarGIAssertWinnerMetric pimSGTable pimSGEntry pimSGAddressType pimSGGrpAddress pimSGSrcAddress pimSGUpTime pimSGPimMode pimSGUpstreamJoinState pimSGUpstreamJoinTimer pimSGUpstreamNeighbor pimSGRPFIfIndex pimSGRPFNextHopType pimSGRPFNextHop pimSGRPFRouteProtocol pimSGRPFRouteAddress pimSGRPFRoutePrefixLength pimSGRPFRouteMetricPref pimSGRPFRouteMetric pimSGSPTBit pimSGKeepaliveTimer pimSGDRRegisterState pimSGDRRegisterStopTimer pimSGRPRegisterPMBRAddressType pimSGRPRegisterPMBRAddress pimSGUpstreamPruneState pimSGUpstreamPruneLimitTimer pimSGOriginatorState pimSGSourceActiveTimer pimSGStateRefreshTimer pimSGITable pimSGIEntry pimSGIIfIndex pimSGIUpTime pimSGILocalMembership pimSGIJoinPruneState pimSGIPrunePendingTimer pimSGIJoinExpiryTimer pimSGIAssertState pimSGIAssertTimer pimSGIAssertWinnerAddressType pimSGIAssertWinnerAddress pimSGIAssertWinnerMetricPref pimSGIAssertWinnerMetric pimSGRptTable pimSGRptEntry pimSGRptSrcAddress pimSGRptUpTime pimSGRptUpstreamPruneState pimSGRptUpstreamOverrideTimer pimSGRptITable pimSGRptIEntry pimSGRptIIfIndex pimSGRptIUpTime pimSGRptILocalMembership pimSGRptIJoinPruneState pimSGRptIPrunePendingTimer pimSGRptIPruneExpiryTimer pimBidirDFElectionTable pimBidirDFElectionEntry pimBidirDFElectionAddressType pimBidirDFElectionRPAddress pimBidirDFElectionIfIndex pimBidirDFElectionWinnerAddressType pimBidirDFElectionWinnerAddress pimBidirDFElectionWinnerUpTime Sivaramu, et al. Standards Track [Page 84] RFC 5060 PIM MIB January 2008 pimBidirDFElectionWinnerMetricPref pimBidirDFElectionWinnerMetric pimBidirDFElectionState pimBidirDFElectionStateTimer pimStaticRPTable pimStaticRPEntry pimStaticRPAddressType pimStaticRPGrpAddress pimStaticRPGrpPrefixLength pimStaticRPRPAddress pimStaticRPPimMode pimStaticRPOverrideDynamic pimStaticRPRowStatus pimStaticRPPrecedence pimAnycastRPSetTable pimAnycastRPSetEntry pimAnycastRPSetAddressType pimAnycastRPSetAnycastAddress pimAnycastRPSetRouterAddress pimAnycastRPSetRowStatus pimAnycastRPSetLocalRouter pimGroupMappingTable pimGroupMappingEntry pimGroupMappingOrigin pimGroupMappingAddressType pimGroupMappingGrpAddress pimGroupMappingGrpPrefixLength pimGroupMappingRPAddress pimGroupMappingPimMode pimGroupMappingPrecedence There is also a specific danger arising from the notification pimInvalidRegister. This is originated by devices that receive an incorrect unicast-encapsulated multicast data packet, which poses a clear danger of propagating a DoS (Denial of Service) attack from the data or control plane to the network management plane. The following steps are taken to guard against this. 1. The notification is disabled by default. The writeable field pimInvalidRegisterNotificationPeriod must be set in order to enable it. 2. The syntax of pimInvalidRegisterNotificationPeriod prevents any given device from originating the notification more frequently than once every 10 seconds. 3. The counter pimInvalidRegisterMsgsRcvd provides equivalent function to the notification. Management applications are encouraged to monitor this counter in preference to enabling the notification. The same measures are taken in respect of pimInvalidJoinPrune, though as this notification can only arise as a result of unroutable control packets, the risk is not so acute. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Sivaramu, et al. Standards Track [Page 85] RFC 5060 PIM MIB January 2008 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations PIM-STD-MIB is rooted under the mib-2 subtree. IANA has assigned { mib-2 157 } to the PIM-STD-MIB module specified in this document. 8. Acknowledgements This MIB module is based on the original work in RFC 2934 [RFC2934] by K. McCloghrie, D. Farinacci, D. Thaler, and W. Fenner and has been updated based on feedback from the IETF's Protocol Independent Multicast (PIM) Working Group. Jonathan Nicholas was the editor of early versions of this document, and contributed the objects for management of PIM-DM. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Sivaramu, et al. Standards Track [Page 86] RFC 5060 PIM MIB January 2008 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. [RFC5059] Bhaskar, N., Gall, A., Lingard, L., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM", RFC 5059, January 2008. [RTPROTO] IANA, "IP Route Protocol MIB", September 2000, . 9.2. Informative References [IPMCAST-MIB] McWalter, D., "IP Multicast MIB", Work in Progress, August 2007. [RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000. [RFC2934] McCloghrie, K., Farinacci, D., Thaler, D., and B. Fenner, "Protocol Independent Multicast MIB for IPv4", RFC 2934, October 2000. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Sivaramu, et al. Standards Track [Page 87] RFC 5060 PIM MIB January 2008 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. Sivaramu, et al. Standards Track [Page 88] RFC 5060 PIM MIB January 2008 Authors' Addresses Raghava Sivaramu Cisco Systems 425 E. Tasman Drive San Jose, CA 95134 USA EMail: raghava@cisco.com James Lingard Arastra, Inc P.O. Box 10905 Palo Alto, CA 94303 USA EMail: jchl@arastra.com David McWalter Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom EMail: dmcw@dataconnection.com Bharat Joshi Infosys Technologies Ltd Electronic City Bangalore 560 100 India EMail: bharat_joshi@infosys.com Andrew Kessler Cisco Systems 425 E. Tasman Drive San Jose, CA 95134 USA EMail: kessler@cisco.com Sivaramu, et al. Standards Track [Page 89] RFC 5060 PIM MIB January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Sivaramu, et al. Standards Track [Page 90] snmp-mibs-downloader-1.1/mibrfcs/rfc5066.txt0000644000000000000000000057167111402176072015604 0ustar Network Working Group E. Beili Request for Comments: 5066 Actelis Networks Category: Standards Track November 2007 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 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. Abstract This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets. This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. Beili Standards Track [Page 1] RFC 5066 EFMCu Interfaces MIB November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Relation to Other MIB Modules . . . . . . . . . . . . . . . . 4 3.1. Relation to Interfaces Group MIB Module . . . . . . . . . 4 3.1.1. Layering Model . . . . . . . . . . . . . . . . . . . . 4 3.1.2. PME Aggregation Function (PAF) . . . . . . . . . . . . 7 3.1.3. Discovery Operation . . . . . . . . . . . . . . . . . 7 3.1.4. EFMCu Ports Initialization . . . . . . . . . . . . . . 9 3.1.5. Usage of ifTable . . . . . . . . . . . . . . . . . . . 10 3.2. Relation to SHDSL MIB Module . . . . . . . . . . . . . . . 11 3.3. Relation to VDSL MIB Module . . . . . . . . . . . . . . . 12 3.4. Relation to Ethernet-Like and MAU MIB Modules . . . . . . 12 4. MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. EFM Copper MIB Overview . . . . . . . . . . . . . . . . . 13 4.2. Interface Stack Capability MIB Overview . . . . . . . . . 13 4.3. PME Profiles . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Mapping of IEEE 802.3ah Managed Objects . . . . . . . . . 14 5. Interface Stack Capability MIB Definitions . . . . . . . . . . 16 6. EFM Copper MIB Definitions . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 88 Beili Standards Track [Page 2] RFC 5066 EFMCu Interfaces MIB November 2007 1. Introduction New Ethernet-like interfaces have been defined in the Institute of Electrical and Electronics Engineers (IEEE) Standard 802.3ah-2004 [802.3ah], a.k.a. Ethernet in the First Mile (EFM), which is now a part of the base IEEE Standard 802.3-2005 [802.3]. In particular, 2BASE-TL and 10PASS-TS physical interfaces (PHYs), defined over voice-grade copper pairs, have been specified for the long and short reach, respectively. These interfaces, collectively called EFM Copper (EFMCu), are based on Single-pair High-speed Digital Subscriber Line (SHDSL) [G.991.2] and Very High speed Digital Subscriber Line (VDSL) [G.993.1] technology, supporting optional Physical Medium Entity (PME) aggregation (a.k.a. multi-pair bonding) with variable rates. 2BASE-TL PHY is capable of providing at least 2 Mbps over a 2700 m long single copper pair with a mean Bit Error Rate (BER) of 10^-7 (using 5 dB target noise margin). 10PASS-TS PHY is capable of providing at least 10 Mbps over a 750 m long single copper pair with a mean BER of 10^-7 (using 6 dB target noise margin). This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community to manage EFMCu interfaces. In addition, a MIB module is defined describing the cross-connect capability of a stacked interface. Note that managed objects for Operation, Administration and Maintenance (OAM) and Ethernet over Passive Optical Networks (EPON) clauses of IEEE 802.3ah are defined in EFM-COMMON-MIB [RFC4878] and EFM-EPON-MIB [RFC4837], respectively. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Beili Standards Track [Page 3] RFC 5066 EFMCu Interfaces MIB November 2007 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Relation to Other MIB Modules This section outlines the relationship of the MIB modules defined in this document with other MIB modules described in the relevant RFCs. Specifically, the Interfaces Group MIB (IF-MIB), Ethernet-Like (EtherLike-MIB), MAU (MAU-MIB), SHDSL (HDSL2-SHDSL-LINE-MIB), and VDSL (VDSL-LINE-EXT-MCM-MIB) modules are discussed. 3.1. Relation to Interfaces Group MIB Module 2BASE-TL and 10PASS-TS PHYs specified in the EFM-CU-MIB module are stacked (a.k.a. aggregated or bonded) Ethernet interfaces and as such are managed using generic interface management objects defined in the IF-MIB [RFC2863]. The stack management (i.e., actual connection of the sub-layers to the top-layer interface) is done via the ifStackTable, as defined in the IF-MIB [RFC2863], and its inverse ifInvStackTable, as defined in the IF-INVERTED-STACK-MIB [RFC2864]. The new tables ifCapStackTable and its inverse ifInvCapStackTable defined in the IF-CAP-STACK-MIB module below, extend the stack management with an ability to describe possible connections or cross- connect capability, when a flexible cross-connect matrix is present between the interface layers. 3.1.1. Layering Model An EFMCu interface can aggregate up to 32 Physical Medium Entity (PME) sub-layer devices (modems), using the so-called PME Aggregation Function (PAF). A generic EFMCu device can have a number of Physical Coding Sublayer (PCS) ports, each connected to a Media Access Controller (MAC) via a Medium Independent Interface (MII) at the upper layer, and cross- connected to a number of underlying PMEs, with a single PCS per PME relationship. See clause 61.1 of [802.3ah] for more details. Each PME in the aggregated EFMCu port is represented in the Interface table (ifTable) as a separate interface with ifType of shdsl(169) for 2BASE-TL or vdsl(97) for 10PASS-TS. The ifType values are defined in [IANAifType-MIB]. Beili Standards Track [Page 4] RFC 5066 EFMCu Interfaces MIB November 2007 ifSpeed for each PME SHALL return the actual data bitrate of the active PME (e.g., for 2BaseTL PMEs it is a multiple of 64 Kbps). A zero value SHALL be returned when the PME is Initializing or Down. The ifSpeed of the PCS is the sum of the current operating data rates of all PMEs in the aggregation group, without the 64/65-octet encapsulation overhead and PAF overhead, but accounting for the Inter-Frame Gaps (IFGs). When using the stated definition of ifSpeed for the PCS, there would be no frame loss in the following configuration (the test-sets are configured to generate 100% of back-to-back traffic, i.e., minimal IFG, at 10 or 100 Mbps, with min and max frame sizes; the EFM interfaces are aggregated, to achieve the shown speed): .-------. .--. .---. .-------. |testset|--10BaseT--|CO|--2BaseTL--|CPE|--10BaseT--|testset| '-------' '--' '---' '-------' ifSpeed= 10 Mbps 10 Mbps 10 Mbps .-------. .--. .---. .-------. |testset|--100BaseT--|CO|--10PassTS--|CPE|--100BaseT--|testset| '-------' '--' '---' '-------' ifSpeed= 100 Mbps 100 Mbps 100 Mbps Figure 1: Example configuration with no frame loss Beili Standards Track [Page 5] RFC 5066 EFMCu Interfaces MIB November 2007 The following figure shows the IEEE 802.3 layering diagram and corresponding use of ifTable and ifMauTable: .-------------------------. - | LLC | ^ +-------------------------+ | 1 ifEntry | MAC | | ifType: ethernetCsmacd(6) +-------------------------+ ) ifMauEntry | Reconsiliation | | ifMauType: dot3MauType2BaseTL or +-------------------------+ | dot3MauType10PassTS | PCS | v +-------------+---+-------+ - | TC \ | | | ^ +-----\ | | | | | PMA )PME 1 |...| PME N | ) N ifEntry (N=1..32) +-----/ | | | | ifType: shdsl(169) or vdsl(97) | PMD/ | | | v '-------------+---+-------' - LLC - Logical Link Control PMA - Physical Medium Attachment MAC - Media Access Control PMD - Physical Medium Dependent PCS - Physical Coding Sub-layer PME - Physical Medium Entity TC - Transmission Convergence Figure 2: Use of ifTable and ifMauTable for EFMCu ports The ifStackTable is indexed by the ifIndex values of the aggregated EFMCu port (PCS) and the PMEs connected to it. ifStackTable allows a Network Management application to determine which PMEs are connected to a particular PCS and change connections (if supported by the application). The ifInvStackTable, being an inverted version of the ifStackTable, provides an efficient means for a Network Management application to read a subset of the ifStackTable and thereby determine which PCS runs on top of a particular PME. A new table ifCapStackTable, defined in the IF-CAP-STACK-MIB module, specifies for each higher-layer interface (e.g., PCS port) a list of lower-layer interfaces (e.g., PMEs), which can possibly be cross- connected to that higher-layer interface, determined by the cross- connect capability of the device. This table, modeled after ifStackTable, is read-only, reflecting current cross-connect capability of stacked interface, which can be dynamic in some implementations (e.g., if PMEs are located on a pluggable module and the module is pulled out). Note that PME availability per PCS, described by ifCapStackTable, can be constrained by other parameters, for example, by aggregation capacity of a PCS or by the PME in question being already connected to another PCS. So, in order to Beili Standards Track [Page 6] RFC 5066 EFMCu Interfaces MIB November 2007 ensure that a particular PME can be connected to the PCS, all respective parameters (e.g., ifCapStackTable, ifStackTable, and efmCuPAFCapacity) SHALL be inspected. The ifInvCapStackTable, also defined in the IF-CAP-STACK-MIB module, describes which higher-layer interfaces (e.g., PCS ports) can possibly be connected to a particular lower-layer interface (e.g., PME), providing an inverted mapping of the ifCapStackTable. While it contains no additional information beyond that already contained in the ifCapStackTable, the ifInvCapStackTable has the ifIndex values in its INDEX clause in the reverse order, i.e., the lower-layer interface first, and the higher-layer interface second, providing an efficient means for a Network Management application to read a subset of the ifCapStackTable and thereby determine which interfaces can be connected to run on top of a particular interface. 3.1.2. PME Aggregation Function (PAF) The PME Aggregation Function (PAF) allows a number of PMEs to be aggregated onto a PCS port, by fragmenting the Ethernet frames, transmitting the fragments over multiple PMEs, and assembling the original frames at the remote port. PAF is OPTIONAL, meaning that a device with a single PME MAY perform fragmentation and re-assembly if this function is supported by the device. Note however that the agent is REQUIRED to report on the PAF capability for all EFMCu ports (2BASE-TL and 10PASS-TS). The EFM-CU-MIB module allows a Network Management application to query the PAF capability and enable/disable it if supported. Note that enabling PAF effectively turns on fragmentation and re-assembly, even on a single-PME port. 3.1.3. Discovery Operation The EFMCu ports may optionally support discovery operation, whereby PMEs, during initialization, exchange information about their respective aggregation groups (PCS). This information can then be used to detect copper misconnections or for an automatic assignment of the local PMEs into aggregation groups instead of a fixed pre- configuration. The MIB modules defined in this document allow a Network Management application to control the EFM Discovery mechanism and query its results. Note that the Discovery mechanism can work only if PAF is supported and enabled. Beili Standards Track [Page 7] RFC 5066 EFMCu Interfaces MIB November 2007 Two tables are used by the EFM Discovery mechanism: ifStackTable and ifCapStackTable. The following pseudo-code gives an example of the Discovery and automatic PME assignment for a generic PAF-enabled multi-PCS EFMCu device, located at Central Office (CO), using objects defined in these MIB modules and in the IF-MIB (Note that automatic PME assignment is only shown here for the purposes of the example. Fixed PME pre-assignment, manual assignment, or auto-assignment using an alternative internal algorithm may be chosen by a particular implementation): // Go over all PCS ports in the CO device FOREACH pcs[i] IN CO_device { // Perform discovery and auto-assignment only on PAF enabled ports // with room for more PMEs IF ( pcs[i].PAFSupported AND pcs[i].NumPMEs < pcs[i].PAFCapacity ) { // Assign a unique 6-octet local discovery code to the PCS // e.g., MAC address dc = pcs[i].DiscoveryCode = MAC[i]; // Go over all disconnected PMEs, which can // potentially be connected to the PCS FOREACH pme[j] IN ifCapStackTable[pcs[i]] AND NOT IN ifStackTable[pcs[i]] // not connected { // Try to grab the remote RT_device, by writing the value // of the local 6-octet discovery code to the remote // discovery code register (via handshake mechanism). // This operation is atomic Set-if-Clear action, i.e., it // would succeed only if the remote discovery register was // zero. Read the remote discovery code register via Get // operation to see if the RT_device, attached via the PME // is indeed marked as being the CO_device peer. pme[j].RemoteDiscoveryCode = dc; // Set-if-Clear r = pme[j].RemoteDiscoveryCode; // Get IF ( r == dc AND pcs[i].NumPMEs < pcs[i].PAFCapacity) { // Remote RT_device connected via PME[j] is/was a peer // for PCS[i] and there is room for another PME in the // PCS[i] aggregation group (max. PAF capacity is not // reached yet). // Connect this PME to the PCS (via ifStackTable, // ifInvStackTable being inverse of ifStackTable is // updated automatically, i.e., pcs[i] is auto-added // to ifInvStackTable[pme[j]]) ADD pme[j] TO ifStackTable[pcs[i]]; pcs[i].NumPMEs = pcs[i].NumPMEs + 1; // Discover all other disconnected PMEs, // attached to the same RT_device and connect them to // the PCS provided there is enough room for more PMEs. FOREACH pme[k] IN ifCapStackTable[pcs[i]] AND NOT IN ifStackTable[pcs[i]] Beili Standards Track [Page 8] RFC 5066 EFMCu Interfaces MIB November 2007 { // Get Remote Discovery Code from the PME to see if // it belongs to a connected RT_device "grabbed" by // the CO_device. r = pme[k].RemoteDiscoveryCode; IF ( r == dc AND pcs[i].NumPMEs < pcs[i].PAFCapacity) { // Physically connect the PME to the PCS // (pcs[i] is auto-added TO ifInvStackTable[pme[k]]) ADD pme[k] TO ifStackTable[pcs[i]]; pcs[i].NumPMEs = pcs[i].NumPMEs + 1; } } } // At this point we have discovered all local PMEs which // are physically connected to the same remote RT_device // and connected them to PCS[i]. Go to the next PCS. BREAK; } } } An SNMP Agent for an EFMCu device builds the ifCapStackTable and its inverse ifInvCapStackTable according to the information contained in the Clause 45 PME_Available_register (see [802.3ah] 61.1.5.3 and 45.2.3.20). Adding a PME to the ifStackTable row for a specific PCS involves actual connection of the PME to the PCS, which can be done by modifying Clause 45 PME_Aggregate_register (see [802.3ah] 61.1.5.3 and 45.2.3.21). Note that the PCS port does not have to be operationally 'down' for the connection to succeed. In fact, a dynamic PME addition (and removal) MAY be implemented with an available PME being initialized first (by setting its ifAdminStatus to 'up') and then added to an operationally 'up' PCS port, by modifying a respective ifStackTable (and respective ifInvStackTable) entry. It is RECOMMENDED that a removal of the last operationally 'up' PME from an operationally 'up' PCS would be rejected by the implementation, as this action would completely drop the link. 3.1.4. EFMCu Ports Initialization EFMCu ports being built on top of xDSL technology require a lengthy initialization or 'training' process, before any data can pass. During this initialization, both ends of a link (peers) work cooperatively to achieve the required data rate on a particular Beili Standards Track [Page 9] RFC 5066 EFMCu Interfaces MIB November 2007 copper pair. Sometimes, when the copper line is too long or the noise on the line is too high, that 'training' process may fail to achieve a specific target rate with required characteristics. The ifAdminStatus object from the IF-MIB controls the desired state of a PCS with all the PMEs connected to it or of an individual PME port. Setting this object to 'up' instructs a particular PCS or PME to start the initialization process, which may take tens of seconds for EFMCu ports, especially if PAF is involved. The ifOperStatus object shows the operational state of an interface (extended by the ifMauMediaAvailable object from MAU-MIB for PCS and efmCuPmeOperStatus defined in the EFM-CU-MIB module for PME interfaces). A disconnected PME may be initialized by changing the ifAdminState from 'down' to 'up'. Changing the ifAdminState to 'up' on the PCS initializes all PMEs connected to that particular PCS. Note that in case of PAF some interfaces may fail to initialize while others succeed. The PCS is considered operationally 'up' if at least one PME aggregated by its PAF is operationally 'up'. When all PMEs connected to the PCS are 'down', the PCS SHALL be considered operationally 'lowerLayerDown'. The PCS SHALL be considered operationally 'notPresent' if it is not connected to any PME. The PCS/PME interface SHALL remain operationally 'down' during initialization. The efmCuPmeOperStatus defined in the EFM-CU-MIB module expands PME's ifOperStatus value of 'down' to 'downReady', 'downNotReady', and 'init' values, indicating various EFMCu PME-specific states. 3.1.5. Usage of ifTable Both PME and PCS interfaces of the EFMCu PHY are managed using interface-specific management objects defined in the EFM-CU-MIB module and generic interface objects from the ifTable of IF-MIB, with all management table entries referenced by the interface index ifIndex. The following table summarizes EFMCu-specific interpretations for some of the ifTable objects specified in the mandatory ifGeneralInformationGroup: Beili Standards Track [Page 10] RFC 5066 EFMCu Interfaces MIB November 2007 +---------------+---------------------------------------------------+ | IF-MIB object | EFMCu interpretation | +---------------+---------------------------------------------------+ | ifIndex | Interface index. Note that each PME and each PCS | | | in the EFMCu PHY MUST have a unique index, as | | | there are some PCS- and PME-specific attributes | | | accessible only on the PCS or PME level. | +---------------+---------------------------------------------------+ | ifType | ethernetCsmacd(6) for PCS, shdsl(169) for | | | 2BASE-TL PME, vdsl(97) for 10PASS-TS PME. | | ifSpeed | Operating data rate for the PME. For the PCS, it | | | is the sum of the current operating data rates of | | | all PMEs in the aggregation group, without the | | | 64/65-octet encapsulation overhead and PAF | | | overhead, but accounting for the Inter-Frame Gaps | | | (IFGs). | +---------------+---------------------------------------------------+ | ifAdminStatus | Setting this object to 'up' instructs a | | | particular PCS (with all PMEs connected to it) or | | | PME to start initialization process. | +---------------+---------------------------------------------------+ | ifOperStatus | efmCuPmeOperStatus supplements the 'down' value | | | of ifOperStatus for PMEs. | +---------------+---------------------------------------------------+ Table 1: EFMCu interpretation of IF-MIB objects 3.2. Relation to SHDSL MIB Module G.SHDSL.bis modems, similar to PMEs comprising a 2BASE-TL port, are described in the HDSL2-SHDSL-LINE-MIB module [RFC4319]. Note that not all attributes of G.SHDSL modems reflected in the HDSL2-SHDSL- LINE-MIB module have adequate management objects (Clause 30 attributes and Clause 45 registers) in the EFM standard. Because of these differences and for the purposes of simplicity, unification of attributes common to both 2BASE-TL and 10PASS-TS PMEs, and name consistency (e.g., prefixing the 2BASE-TL PME related objects with 'efmCuPme2B' instead of 'hdsl2shdsl'), it was decided not to reference HDSL2-SHDSL-LINE-MIB objects, but define all the relevant objects in the EFM-CU-MIB module. However, if some functionality not available in the EFM-CU-MIB module is required and supported by the PME, e.g., performance monitoring, relevant HDSL2-SHDSL-LINE-MIB groups MAY be included and applied for PMEs of 2BASE-TL subtype. Beili Standards Track [Page 11] RFC 5066 EFMCu Interfaces MIB November 2007 3.3. Relation to VDSL MIB Module VDSL modems, similar to the PME(s) comprising a 10PASS-TS port, are described in the VDSL-LINE-EXT-MCM-MIB module [RFC4070]. Note that not all attributes of VDSL modems reflected in the VDSL-LINE-EXT-MCM- MIB module have adequate management objects (Clause 30 attributes and Clause 45 registers) in the EFM standard. Because of these differences and for the purposes of simplicity, unification of attributes common to both 2BASE-TL and 10PASS-TS PMEs, and name consistency, it was decided not to reference VDSL-LINE-EXT- MCM-MIB objects, but define all the relevant objects in the EFM-CU- MIB module. However, if some functionality not available in the EFM-CU-MIB module is required and supported by the PME, relevant VDSL-LINE-EXT-MCM-MIB groups MAY be included and applied for PMEs of 10PASS-TS subtype. 3.4. Relation to Ethernet-Like and MAU MIB Modules The implementation of the EtherLike-MIB [RFC3635] and MAU-MIB [RFC4836] modules is REQUIRED for EFMCu interfaces. Two new values of ifMauType (OBJECT-IDENTITIES of dot3MauType) and corresponding bit definitions of ifMauTypeListBits (IANAifMauTypeListBits) have been defined in the IANA-MAU-MIB module [RFC4836] for EFMCu MAUs: o dot3MauType2BaseTL and b2BaseTL - for 2BASE-TL MAU o dot3MauType10PassTS and b10PassTS - for 10PASS-TS MAU Additionally, the IANA-MAU-MIB module defines two new values of ifMauMediaAvailable, specifically for EFMCu ports: availableReduced and ready (in textual convention IANAifMauMediaAvailable). Due to the PME aggregation, the EFMCu interpretation of some possible ifMauMediaAvailable values differs from other MAUs as follows: o unknown - the EFMCu interface (PCS with connected PMEs) is Initializing o ready - the interface is Down, at least one PME in the aggregation group (all PMEs connected to the PCS) is ready for handshake o available - the interface is Up, all PMEs in the aggregation group are up Beili Standards Track [Page 12] RFC 5066 EFMCu Interfaces MIB November 2007 o notAvailable - the interface is Down, all PMEs in the aggregation group are Down, no handshake tones are detected by any PME o availableReduced - the interface is Up, a link fault is detected at the receive direction by one or more PMEs in the aggregation group, but at least one PME is Up o pmdLinkFault - a link fault is detected at the receive direction by all PMEs in the aggregation group As an EtherLike interface, every EFMCu port (an ifEntry representing a consolidation of LLC, MAC, and PCS (sub)layers) SHALL return an ifType of ethernetCsmacd(6). While most of the MAU characteristics are not applicable to the EFMCu ports (no auto-negotiation, false carriers, or jabber), they SHALL return an appropriate ifMauType (dot3MauType2BaseTL or dot3mauType10PassTS) in order to direct the management software to look in the EFM-CU-MIB module for the desired information. For example, the information on the particular EFMCu flavor that an EFMCu port is running is available from efmCuOperSubType, defined in the EFM-CU-MIB module. Since EFMCu PMEs are not EtherLike interfaces, they cannot be instantiated as MAU interface objects. 4. MIB Structure 4.1. EFM Copper MIB Overview The main management objects defined in the EFM-CU-MIB module are split into 2 groups: o efmCuPort - containing objects for configuration, capabilities, status, and notifications, common to all EFMCu PHYs. o efmCuPme - containing objects for configuration, capabilities, status, and notifications of EFMCu PMEs. The efmCuPme group in turn contains efmCuPme2B and efmCuPme10P groups, which define PME profiles specific to 2BASE-TL and 10PASS-TS PMEs, respectively, as well as PME-specific status information. 4.2. Interface Stack Capability MIB Overview The IF-CAP-STACK-MIB module contains 2 tables: o ifCapStackTable - containing objects that define possible relationships among the sub-layers of an interface with flexible cross-connect (cross-connect capability). Beili Standards Track [Page 13] RFC 5066 EFMCu Interfaces MIB November 2007 o ifInvCapStackTable - an inverse of the ifCapstackTable. 4.3. PME Profiles Since a managed node can have a large number of EFMCu PHYs, provisioning every parameter on every EFMCu PHY may become burdensome. Moreover, most PMEs are provisioned identically with the same set of parameters. To simplify the provisioning process, the EFM-CU-MIB module makes use of configuration profiles, similar to the HDSL2-SHDSL-LINE-MIB and VDSL-LINE-EXT-MCM-MIB modules. A profile is a set of parameters, used either for configuration or representation of a PME. The same profile can be shared by multiple PME ports using the same configuration. The PME profiles are defined in the efmCuPme2BProfileTable and efmCuPme10PProfileTable for 2BASE-TL and 10PASS-TS PMEs, respectively. There are 12 predefined standard profiles for 2BASE-TL and 22 standard profiles for 10PASS-TS, defined in 802.3ah and dedicated for rapid provisioning of EFMCu PHYs in most scenarios. In addition, the EFM-CU-MIB defines two additional predefined profiles for "best-effort" provisioning of 2BASE-TL PMEs. An ability to define new configuration profiles is also provided to allow for EFMCu deployment tailored to specific copper environments and spectral regulations. A specific configuration or administrative profile is assigned to a specific PME via the efmCuPmeAdminProfile object. If efmCuPmeAdminProfile is zero, then the efmCuAdminProfile object of the PCS port connected to the PME determines the configuration profile (or a list of possible profiles) for that PME. This mechanism allows specifying a common profile for all PMEs connected to the PCS port, with an ability to change individual PME profiles by setting efmCuPmeAdminProfile object, which overwrites the profile set by efmCuAdminProfile. A current operating PME profile is pointed to by the efmCuPmeOperProfile object. Note that this profile entry can be created automatically to reflect achieved parameters in adaptive (not fixed) initialization. 4.4. Mapping of IEEE 802.3ah Managed Objects This section contains the mapping between relevant managed objects (attributes) defined in [802.3ah] Clause 30, and managed objects defined in this document and in associated MIB modules, i.e., the IF- MIB [RFC2863]. Beili Standards Track [Page 14] RFC 5066 EFMCu Interfaces MIB November 2007 Note that the majority of the objects defined in the EFM-CU-MIB module do not have direct counterparts in Clause 30 and instead refer to Clause 45 registers. +---------------------------------+---------------------------------+ | IEEE 802.3 Managed Object | Corresponding SNMP Object | +---------------------------------+---------------------------------+ | oMAU - Basic Package | | | (Mandatory) | | +---------------------------------+---------------------------------+ | aMAUType | ifMauType (MAU-MIB) | +---------------------------------+---------------------------------+ | aMAUTypeList | ifMauTypeListBits (MAU-MIB) | +---------------------------------+---------------------------------+ | aMediaAvailable | ifMediaAvailable (MAU-MIB) | +---------------------------------+---------------------------------+ | oPAF - Basic Package | | | (Mandatory) | | +---------------------------------+---------------------------------+ | aPAFID | ifIndex (IF-MIB) | +---------------------------------+---------------------------------+ | aPhyEnd | efmCuPhySide | +---------------------------------+---------------------------------+ | aPHYCurrentStatus | efmCuStatus | +---------------------------------+---------------------------------+ | aPAFSupported | efmCuPAFSupported | +---------------------------------+---------------------------------+ | oPAF - PME Aggregation Package | | | (Optional) | | +---------------------------------+---------------------------------+ | aPAFAdminState | efmCuPAFAdminState | +---------------------------------+---------------------------------+ | aLocalPAFCapacity | efmCuPAFCapacity | +---------------------------------+---------------------------------+ | aLocalPMEAvailable | ifCapStackTable | +---------------------------------+---------------------------------+ | aLocalPMEAggregate | ifStackTable (IF-MIB) | +---------------------------------+---------------------------------+ | aRemotePAFSupported | efmCuRemotePAFSupported | +---------------------------------+---------------------------------+ | aRemotePAFCapacity | efmCuRemotePAFCapacity | +---------------------------------+---------------------------------+ | aRemotePMEAggregate | | +---------------------------------+---------------------------------+ | oPME - 10P/2B Package | | | (Mandatory) | | +---------------------------------+---------------------------------+ | aPMEID | ifIndex (IF-MIB) | Beili Standards Track [Page 15] RFC 5066 EFMCu Interfaces MIB November 2007 +---------------------------------+---------------------------------+ | aPMEAdminState | ifAdminState (IF-MIB) | +---------------------------------+---------------------------------+ | aPMEStatus | efmCuPmeStatus | | aPMESNRMgn | efmCuPmeSnrMgn | +---------------------------------+---------------------------------+ | aTCCodingViolations | efmCuPmeTCCodingErrors | +---------------------------------+---------------------------------+ | aTCCRCErrors | efmCuPmeTCCrcErrors | +---------------------------------+---------------------------------+ | aProfileSelect | efmCuAdminProfile, | | | efmCuPmeAdminProfile | +---------------------------------+---------------------------------+ | aOperatingProfile | efmCuPmeOperProfile | +---------------------------------+---------------------------------+ | aPMEFECCorrectedBlocks | efmCuPme10PFECCorrectedBlocks | +---------------------------------+---------------------------------+ | aPMEFECUncorrectableBlocks | efmCuPme10PFECUncorrectedBlocks | +---------------------------------+---------------------------------+ Table 2: Mapping of IEEE 802.3 Managed Objects 5. Interface Stack Capability MIB Definitions IF-CAP-STACK-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI -- [RFC2578] TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] ifStackGroup2, ifStackHigherLayer, ifStackLowerLayer FROM IF-MIB -- [RFC2863] ifInvStackGroup FROM IF-INVERTED-STACK-MIB -- [RFC2864] ; ifCapStackMIB MODULE-IDENTITY LAST-UPDATED "200711070000Z" -- November 07, 2007 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/OLD/hubmib-charter.html Mailing Lists: General Discussion: hubmib@ietf.org Beili Standards Track [Page 16] RFC 5066 EFMCu Interfaces MIB November 2007 To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address Chair: Bert Wijnen Postal: Alcatel-Lucent Schagen 33 3461 GL Linschoten Netherlands Phone: +31-348-407-775 EMail: bwijnen@alcatel-lucent.com Editor: Edward Beili Postal: Actelis Networks Inc. 25 Bazel St., P.O.B. 10173 Petach-Tikva 10173 Israel Phone: +972-3-924-3491 EMail: edward.beili@actelis.com" DESCRIPTION "The objects in this MIB module are used to describe cross-connect capabilities of stacked (layered) interfaces, complementing ifStackTable and ifInvStackTable defined in IF-MIB and IF-INVERTED-STACK-MIB, respectively. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 5066; see the RFC itself for full legal notices." REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." ::= { mib-2 166 } -- Sections of the module -- Structured as recommended by [RFC4181], see -- Appendix D: Suggested OID Layout ifCapStackObjects OBJECT IDENTIFIER ::= { ifCapStackMIB 1 } ifCapStackConformance OBJECT IDENTIFIER ::= { ifCapStackMIB 2 } -- Groups in the module -- -- ifCapStackTable group -- Beili Standards Track [Page 17] RFC 5066 EFMCu Interfaces MIB November 2007 ifCapStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfCapStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table, modeled after ifStackTable from IF-MIB, contains information on the possible 'on-top-of' relationships between the multiple sub-layers of network interfaces (as opposed to actual relationships described in ifStackTable). In particular, it contains information on which sub-layers MAY possibly run 'on top of' which other sub-layers, as determined by cross-connect capability of the device, where each sub-layer corresponds to a conceptual row in the ifTable. For example, when the sub-layer with ifIndex value x can be connected to run on top of the sub-layer with ifIndex value y, then this table contains: ifCapStackStatus.x.y=true The ifCapStackStatus.x.y row does not exist if it is impossible to connect between the sub-layers x and y. Note that for most stacked interfaces (e.g., 2BASE-TL) there's always at least one higher-level interface (e.g., PCS port) for each lower-level interface (e.g., PME) and at least one lower-level interface for each higher-level interface, that is, there is at least a single row with a 'true' status for any such existing value of x or y. This table is read-only as it describes device capabilities." REFERENCE "IF-MIB, ifStackTable" ::= { ifCapStackObjects 1 } ifCapStackEntry OBJECT-TYPE SYNTAX IfCapStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular relationship between two sub-layers, specifying that one sub-layer MAY possibly run on 'top' of the other sub-layer. Each sub-layer corresponds to a conceptual row in the ifTable (interface index for lower and higher layer, respectively)." INDEX { ifStackHigherLayer, ifStackLowerLayer } Beili Standards Track [Page 18] RFC 5066 EFMCu Interfaces MIB November 2007 ::= { ifCapStackTable 1 } IfCapStackEntry ::= SEQUENCE { ifCapStackStatus TruthValue } ifCapStackStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the 'cross-connect capability' relationship between two sub-layers. The following values can be returned: true(1) - indicates that the sub-layer interface, identified by the ifStackLowerLayer MAY be connected to run 'below' the sub-layer interface, identified by the ifStackHigherLayer index. false(2) - the sub-layer interfaces cannot be connected temporarily due to unavailability of the interface(s), e.g., one of the interfaces is located on an absent pluggable module. Note that lower-layer interface availability per higher-layer, indicated by the value of 'true', can be constrained by other parameters, for example, by the aggregation capacity of a higher-layer interface or by the lower-layer interface in question being already connected to another higher-layer interface. In order to ensure that a particular sub-layer can be connected to another sub-layer, all respective objects (e.g., ifCapStackTable, ifStackTable, and efmCuPAFCapacity for EFMCu interfaces) SHALL be inspected. This object is read-only, unlike ifStackStatus, as it describes a cross-connect capability." ::= { ifCapStackEntry 1 } ifInvCapStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfInvCapStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information on the possible relationships between the multiple sub-layers of network interfaces. This table, modeled after ifInvStackTable from IF-INVERTED-STACK-MIB, is an inverse of the ifCapStackTable defined in this MIB module. Beili Standards Track [Page 19] RFC 5066 EFMCu Interfaces MIB November 2007 In particular, this table contains information on which sub-layers MAY run 'underneath' which other sub-layers, where each sub-layer corresponds to a conceptual row in the ifTable. For example, when the sub-layer with ifIndex value x MAY be connected to run underneath the sub-layer with ifIndex value y, then this table contains: ifInvCapStackStatus.x.y=true This table contains exactly the same number of rows as the ifCapStackTable, but the rows appear in a different order. This table is read-only as it describes a cross-connect capability." REFERENCE "IF-INVERTED-STACK-MIB, ifInvStackTable" ::= { ifCapStackObjects 2 } ifInvCapStackEntry OBJECT-TYPE SYNTAX IfInvCapStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular relationship between two sub- layers, specifying that one sub-layer MAY run underneath the other sub-layer. Each sub-layer corresponds to a conceptual row in the ifTable." INDEX { ifStackLowerLayer, ifStackHigherLayer } ::= { ifInvCapStackTable 1 } IfInvCapStackEntry ::= SEQUENCE { ifInvCapStackStatus TruthValue } ifInvCapStackStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the possible 'cross-connect capability' relationship between two sub-layers. An instance of this object exists for each instance of the ifCapStackStatus object, and vice versa. For example, if the variable ifCapStackStatus.H.L exists, then the variable ifInvCapStackStatus.L.H must also exist, and vice versa. In addition, the two variables always have the same value. Beili Standards Track [Page 20] RFC 5066 EFMCu Interfaces MIB November 2007 The ifInvCapStackStatus object is read-only, as it describes a cross-connect capability." REFERENCE "ifCapStackStatus" ::= { ifInvCapStackEntry 1 } -- -- Conformance Statements -- ifCapStackGroups OBJECT IDENTIFIER ::= { ifCapStackConformance 1 } ifCapStackCompliances OBJECT IDENTIFIER ::= { ifCapStackConformance 2 } -- Units of Conformance ifCapStackGroup OBJECT-GROUP OBJECTS { ifCapStackStatus, ifInvCapStackStatus } STATUS current DESCRIPTION "A collection of objects providing information on the cross-connect capability of multi-layer (stacked) network interfaces." ::= { ifCapStackGroups 1 } -- Compliance Statements ifCapStackCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities, which provide information on the cross-connect capability of multi-layer (stacked) network interfaces, with flexible cross-connect between the sub-layers." MODULE -- this module MANDATORY-GROUPS { ifCapStackGroup } OBJECT ifCapStackStatus Beili Standards Track [Page 21] RFC 5066 EFMCu Interfaces MIB November 2007 SYNTAX TruthValue { true(1) } DESCRIPTION "Support for the false(2) value is OPTIONAL for implementations supporting pluggable interfaces." OBJECT ifInvCapStackStatus SYNTAX TruthValue { true(1) } DESCRIPTION "Support for the false(2) value is OPTIONAL for implementations supporting pluggable interfaces." MODULE IF-MIB MANDATORY-GROUPS { ifStackGroup2 } MODULE IF-INVERTED-STACK-MIB MANDATORY-GROUPS { ifInvStackGroup } ::= { ifCapStackCompliances 1 } END 6. EFM Copper MIB Definitions EFM-CU-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, TruthValue, RowStatus, PhysAddress FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] ifIndex, ifSpeed FROM IF-MIB -- [RFC2863] ; efmCuMIB MODULE-IDENTITY LAST-UPDATED "200711140000Z" -- November 14, 2007 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/OLD/hubmib-charter.html Beili Standards Track [Page 22] RFC 5066 EFMCu Interfaces MIB November 2007 Mailing Lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address Chair: Bert Wijnen Postal: Alcatel-Lucent Schagen 33 3461 GL Linschoten Netherlands Phone: +31-348-407-775 EMail: bwijnen@alcatel-lucent.com Editor: Edward Beili Postal: Actelis Networks Inc. 25 Bazel St., P.O.B. 10173 Petach-Tikva 10173 Israel Phone: +972-3-924-3491 Email: edward.beili@actelis.com" DESCRIPTION "The objects in this MIB module are used to manage the Ethernet in the First Mile (EFM) Copper (EFMCu) Interfaces 2BASE-TL and 10PASS-TS, defined in IEEE Std. 802.3ah-2004, which is now a part of IEEE Std. 802.3-2005. The following references are used throughout this MIB module: [802.3ah] refers to: IEEE Std 802.3ah-2004: 'IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks', 07 September 2004. Of particular interest are Clause 61, 'Physical Coding Sublayer (PCS) and common specifications, type 10PASS-TS and type 2BASE-TL', Clause 30, 'Management', Clause 45, 'Management Data Input/Output (MDIO) Interface', Annex 62A, 'PMD profiles for 10PASS-TS' and Annex 63A, 'PMD profiles for 2BASE-TL'. Beili Standards Track [Page 23] RFC 5066 EFMCu Interfaces MIB November 2007 [G.991.2] refers to: ITU-T Recommendation G.991.2: 'Single-pair High-speed Digital Subscriber Line (SHDSL) transceivers', December 2003. [ANFP] refers to: NICC Document ND1602:2005/08: 'Specification of the Access Network Frequency Plan (ANFP) applicable to transmission systems used on the BT Access Network,' August 2005. The following normative documents are quoted by the DESCRIPTION clauses in this MIB module: [G.993.1] refers to: ITU-T Recommendation G.993.1: 'Very High speed Digital Subscriber Line transceivers', June 2004. [T1.424] refers to: ANSI T1.424-2004: 'Interface Between Networks and Customer Installation Very-high-bit-rate Digital Subscriber Lines (VDSL) Metallic Interface (DMT Based)', June 2004. [TS 101 270-1] refers to: ETSI TS 101 270-1: 'Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements', October 2005. Naming Conventions: Atn - Attenuation CO - Central Office CPE - Customer Premises Equipment EFM - Ethernet in the First Mile EFMCu - EFM Copper MDIO - Management Data Input/Output Mgn - Margin PAF - PME Aggregation Function PBO - Power Back-Off PCS - Physical Coding Sublayer PMD - Physical Medium Dependent PME - Physical Medium Entity PSD - Power Spectral Density SNR - Signal to Noise Ratio TCPAM - Trellis Coded Pulse Amplitude Modulation Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 5066; see the RFC itself for full legal notices." Beili Standards Track [Page 24] RFC 5066 EFMCu Interfaces MIB November 2007 REVISION "200711140000Z" -- November 14, 2007 DESCRIPTION "Initial version, published as RFC 5066." ::= { mib-2 167 } -- Sections of the module efmCuObjects OBJECT IDENTIFIER ::= { efmCuMIB 1 } efmCuConformance OBJECT IDENTIFIER ::= { efmCuMIB 2 } -- Groups in the module efmCuPort OBJECT IDENTIFIER ::= { efmCuObjects 1 } efmCuPme OBJECT IDENTIFIER ::= { efmCuObjects 2 } -- Textual Conventions EfmProfileIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero, for each PME configuration profile in the managed EFMCu port. It is RECOMMENDED that values are assigned contiguously starting from 1. The value for each profile MUST remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." SYNTAX Unsigned32 (1..255) EfmProfileIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the EfmProfileIndex convention. The latter defines a greater than zero value used to identify a PME profile in the managed EFMCu port. This extension permits the additional value of zero. The value of zero is object-specific and MUST therefore be defined as part of the description of any object that uses this syntax. Examples of the usage of zero value might include situations where the current operational profile is unknown." SYNTAX Unsigned32 (0..255) EfmProfileIndexList ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d:" Beili Standards Track [Page 25] RFC 5066 EFMCu Interfaces MIB November 2007 STATUS current DESCRIPTION "This textual convention represents a list of up to 6 EfmProfileIndex values, any of which can be chosen for configuration of a PME in a managed EFMCu port. The EfmProfileIndex textual convention defines a greater than zero value used to identify a PME profile. The value of this object is a concatenation of zero or more (up to 6) octets, where each octet contains an 8-bit EfmProfileIndex value. A zero-length octet string is object-specific and MUST therefore be defined as part of the description of any object that uses this syntax. Examples of the usage of a zero-length value might include situations where an object using this textual convention is irrelevant for a specific EFMCu port type." SYNTAX OCTET STRING (SIZE(0..6)) EfmTruthValueOrUnknown ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention is an extension of the TruthValue convention. The latter defines a boolean value with possible values of true(1) and false(2). This extension permits the additional value of unknown(0), which can be returned as the result of a GET operation when an exact true or false value of the object cannot be determined." SYNTAX INTEGER { unknown(0), true(1), false(2) } -- Port Notifications Group efmCuPortNotifications OBJECT IDENTIFIER ::= { efmCuPort 0 } efmCuLowRateCrossing NOTIFICATION-TYPE OBJECTS { ifSpeed, efmCuThreshLowRate } STATUS current DESCRIPTION "This notification indicates that the EFMCu port's data rate has reached/dropped below or exceeded the low rate threshold, specified by efmCuThreshLowRate. This notification MAY be sent for the -O subtype ports (2BaseTL-O/10PassTS-O) while the port is Up, on the crossing event in both directions: from normal (rate is above the threshold) to low (rate equals the threshold or below it) and Beili Standards Track [Page 26] RFC 5066 EFMCu Interfaces MIB November 2007 from low to normal. This notification is not applicable to the -R subtypes. It is RECOMMENDED that a small debouncing period of 2.5 sec, between the detection of the condition and the notification, is implemented to prevent simultaneous LinkUp/LinkDown and efmCuLowRateCrossing notifications to be sent. The adaptive nature of the EFMCu technology allows the port to adapt itself to the changes in the copper environment, e.g., an impulse noise, alien crosstalk, or a micro-interruption may temporarily drop one or more PMEs in the aggregation group, causing a rate degradation of the aggregated EFMCu link. The dropped PMEs would then try to re-initialize, possibly at a lower rate than before, adjusting the rate to provide required target SNR margin. Generation of this notification is controlled by the efmCuLowRateCrossingEnable object." ::= { efmCuPortNotifications 1 } -- PCS Port group efmCuPortConfTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPortConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table for Configuration of EFMCu 2BASE-TL/10PASS-TS (PCS) Ports. Entries in this table MUST be maintained in a persistent manner." ::= { efmCuPort 1 } efmCuPortConfEntry OBJECT-TYPE SYNTAX EfmCuPortConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu Port Configuration table. Each entry represents an EFMCu port indexed by the ifIndex. Note that an EFMCu PCS port runs on top of a single or multiple PME port(s), which are also indexed by ifIndex." INDEX { ifIndex } ::= { efmCuPortConfTable 1 } EfmCuPortConfEntry ::= SEQUENCE { efmCuPAFAdminState INTEGER, Beili Standards Track [Page 27] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPAFDiscoveryCode PhysAddress, efmCuAdminProfile EfmProfileIndexList, efmCuTargetDataRate Unsigned32, efmCuTargetSnrMgn Unsigned32, efmCuAdaptiveSpectra TruthValue, efmCuThreshLowRate Unsigned32, efmCuLowRateCrossingEnable TruthValue } efmCuPAFAdminState OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Administrative (desired) state of the PAF of the EFMCu port (PCS). When 'disabled', PME aggregation will not be performed by the PCS. No more than a single PME can be assigned to this PCS in this case. When 'enabled', PAF will be performed by the PCS when the link is Up, even on a single attached PME, if PAF is supported. PCS ports incapable of supporting PAF SHALL return a value of 'disabled'. Attempts to 'enable' such ports SHALL be rejected. A PAF 'enabled' port with multiple PMEs assigned cannot be 'disabled'. Attempts to 'disable' such port SHALL be rejected, until at most one PME is left assigned. Changing PAFAdminState is a traffic-disruptive operation and as such SHALL be done when the link is Down. Attempts to change this object SHALL be rejected if the link is Up or Initializing. This object maps to the Clause 30 attribute aPAFAdminState. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the PAF enable bit in the 10P/2B PCS control register. This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 61.2.2, 45.2.3.18.3" ::= { efmCuPortConfEntry 1 } Beili Standards Track [Page 28] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPAFDiscoveryCode OBJECT-TYPE SYNTAX PhysAddress (SIZE(0|6)) MAX-ACCESS read-write STATUS current DESCRIPTION "PAF Discovery Code of the EFMCu port (PCS). A unique 6-octet code used by the Discovery function, when PAF is supported. PCS ports incapable of supporting PAF SHALL return a zero-length octet string on an attempt to read this object. An attempt to write to this object SHALL be rejected for such ports. This object MUST be instantiated for the -O subtype PCS before writing operations on the efmCuPAFRemoteDiscoveryCode (Set_if_Clear and Clear_if_Same) are performed by PMEs associated with the PCS. The initial value of this object for -R subtype ports after reset is all zeroes. For -R subtype ports, the value of this object cannot be changed directly. This value may be changed as a result of writing operation on the efmCuPAFRemoteDiscoveryCode object of remote PME of -O subtype, connected to one of the local PMEs associated with the PCS. Discovery MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing. The PAF Discovery Code maps to the local Discovery code variable in PAF (note that it does not have a corresponding Clause 45 register)." REFERENCE "[802.3ah] 61.2.2.8.3, 61.2.2.8.4, 45.2.6.6.1, 45.2.6.8, 61A.2" ::= { efmCuPortConfEntry 2 } efmCuAdminProfile OBJECT-TYPE SYNTAX EfmProfileIndexList MAX-ACCESS read-write STATUS current DESCRIPTION "Desired configuration profile(s), common for all PMEs in the EFMCu port. This object is a list of pointers to entries in either efmCuPme2BProfileTable or efmCuPme10PProfileTable, depending on the current operating SubType of the EFMCu port as indicated by efmCuPortSide. Beili Standards Track [Page 29] RFC 5066 EFMCu Interfaces MIB November 2007 The value of this object is a list of up to 6 indices of profiles. If this list consists of a single profile index, then all PMEs assigned to this EFMCu port SHALL be configured according to the profile referenced by that index, unless it is overwritten by a corresponding non-zero efmCuPmeAdminProfile instance, which takes precedence over efmCuAdminProfile. A list consisting of more than one index allows each PME in the port to be configured according to any profile specified in the list. By default, this object has a value of 0x01, referencing the 1st entry in efmCuPme2BProfileTable or efmCuPme10PProfileTable. This object is writable and readable for the -O subtype (2BaseTL-O or 10PassTS-O) EFMCu ports. It is irrelevant for the -R subtype (2BaseTL-R or 10PassTS-R) ports -- a zero-length octet string SHALL be returned on an attempt to read this object and an attempt to change this object MUST be rejected in this case. Note that the current operational profile value is available via the efmCuPmeOperProfile object. Any modification of this object MUST be performed when the link is Down. Attempts to change this object MUST be rejected, if the link is Up or Initializing. Attempts to set this object to a list with a member value that is not the value of the index for an active entry in the corresponding profile table MUST be rejected. This object maps to the Clause 30 attribute aProfileSelect. This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 30.11.2.1.6" DEFVAL { '01'H } ::= { efmCuPortConfEntry 3 } efmCuTargetDataRate OBJECT-TYPE SYNTAX Unsigned32(1..100000|999999) UNITS "Kbps" MAX-ACCESS read-write STATUS current DESCRIPTION "Desired EFMCu port 'net' (as seen across MII) Data Rate in Kbps, to be achieved during initialization, under spectral restrictions placed on each PME via efmCuAdminProfile or Beili Standards Track [Page 30] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPmeAdminProfile, with the desired SNR margin specified by efmCuTargetSnrMgn. In case of PAF, this object represents a sum of individual PME data rates, modified to compensate for fragmentation and 64/65-octet encapsulation overhead (e.g., target data rate of 10 Mbps SHALL allow lossless transmission of a full-duplex 10 Mbps Ethernet frame stream with minimal inter-frame gap). The value is limited above by 100 Mbps as this is the max burst rate across MII for EFMCu ports. The value between 1 and 100000 indicates that the total data rate (ifSpeed) of the EFMCu port after initialization SHALL be equal to the target data rate or less, if the target data rate cannot be achieved under spectral restrictions specified by efmCuAdminProfile/efmCuPmeAdminProfile and with the desired SNR margin. In case the copper environment allows a higher total data rate to be achieved than that specified by the target, the excess capability SHALL be either converted to additional SNR margin or reclaimed by minimizing transmit power as controlled by efmCuAdaptiveSpectra. The value of 999999 means that the target data rate is not fixed and SHALL be set to the maximum attainable rate during initialization (Best Effort), under specified spectral restrictions and with the desired SNR margin. This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes. Changing of the Target Data Rate MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing. Note that the current Data Rate of the EFMCu port is represented by the ifSpeed object of IF-MIB. This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 4 } efmCuTargetSnrMgn OBJECT-TYPE SYNTAX Unsigned32(0..21) UNITS "dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Desired EFMCu port SNR margin to be achieved on all PMEs Beili Standards Track [Page 31] RFC 5066 EFMCu Interfaces MIB November 2007 assigned to the port, during initialization. (The SNR margin is the difference between the desired SNR and the actual SNR). Note that 802.3ah recommends using a default target SNR margin of 5 dB for 2BASE-TL ports and 6 dB for 10PASS-TS ports in order to achieve a mean Bit Error Rate (BER) of 10^-7 at the PMA service interface. This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes. Changing of the target SNR margin MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing. Note that the current SNR margin of the PMEs comprising the EFMCu port is represented by efmCuPmeSnrMgn. This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 61.1.2" ::= { efmCuPortConfEntry 5 } efmCuAdaptiveSpectra OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates how to utilize excess capacity when the copper environment allows a higher total data rate to be achieved than that specified by the efmCuTargetDataRate. A value of true(1) indicates that the excess capability SHALL be reclaimed by minimizing transmit power, e.g., using higher constellations and Power Back-Off, in order to reduce interference to other copper pairs in the binder and the adverse impact to link/system performance. A value of false(2) indicates that the excess capability SHALL be converted to additional SNR margin and spread evenly across all active PMEs assigned to the (PCS) port, to increase link robustness. This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes. Changing of this object MUST be performed when the link is Beili Standards Track [Page 32] RFC 5066 EFMCu Interfaces MIB November 2007 Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing. This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 6 } efmCuThreshLowRate OBJECT-TYPE SYNTAX Unsigned32(1..100000) UNITS "Kbps" MAX-ACCESS read-write STATUS current DESCRIPTION "This object configures the EFMCu port low-rate crossing alarm threshold. When the current value of ifSpeed for this port reaches/drops below or exceeds this threshold, an efmCuLowRateCrossing notification MAY be generated if enabled by efmCuLowRateCrossingEnable. This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes. This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 7 } efmCuLowRateCrossingEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether efmCuLowRateCrossing notifications should be generated for this interface. A value of true(1) indicates that efmCuLowRateCrossing notification is enabled. A value of false(2) indicates that the notification is disabled. This object is read-write for the -O subtype EFMCu ports (2BaseTL-O/10PassTS-O) and not available for the -R subtypes. This object MUST be maintained in a persistent manner." ::= { efmCuPortConfEntry 8 } efmCuPortCapabilityTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPortCapabilityEntry MAX-ACCESS not-accessible STATUS current Beili Standards Track [Page 33] RFC 5066 EFMCu Interfaces MIB November 2007 DESCRIPTION "Table for Capabilities of EFMCu 2BASE-TL/10PASS-TS (PCS) Ports. Entries in this table MUST be maintained in a persistent manner" ::= { efmCuPort 2 } efmCuPortCapabilityEntry OBJECT-TYPE SYNTAX EfmCuPortCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu Port Capability table. Each entry represents an EFMCu port indexed by the ifIndex. Note that an EFMCu PCS port runs on top of a single or multiple PME port(s), which are also indexed by ifIndex." INDEX { ifIndex } ::= { efmCuPortCapabilityTable 1 } EfmCuPortCapabilityEntry ::= SEQUENCE { efmCuPAFSupported TruthValue, efmCuPeerPAFSupported EfmTruthValueOrUnknown, efmCuPAFCapacity Unsigned32, efmCuPeerPAFCapacity Unsigned32 } efmCuPAFSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "PME Aggregation Function (PAF) capability of the EFMCu port (PCS). This object has a value of true(1) when the PCS can perform PME aggregation on the available PMEs. Ports incapable of PAF SHALL return a value of false(2). This object maps to the Clause 30 attribute aPAFSupported. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the PAF available bit in the 10P/2B capability register." REFERENCE "[802.3ah] 61.2.2, 30.11.1.1.4, 45.2.3.17.1" ::= { efmCuPortCapabilityEntry 1 } efmCuPeerPAFSupported OBJECT-TYPE SYNTAX EfmTruthValueOrUnknown Beili Standards Track [Page 34] RFC 5066 EFMCu Interfaces MIB November 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "PME Aggregation Function (PAF) capability of the EFMCu port (PCS) link partner. This object has a value of true(1) when the remote PCS can perform PME aggregation on its available PMEs. Ports whose peers are incapable of PAF SHALL return a value of false(2). Ports whose peers cannot be reached because of the link state SHALL return a value of unknown(0). This object maps to the Clause 30 attribute aRemotePAFSupported. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the Remote PAF supported bit in the 10P/2B capability register." REFERENCE "[802.3ah] 61.2.2, 30.11.1.1.9, 45.2.3.17.2" ::= { efmCuPortCapabilityEntry 2 } efmCuPAFCapacity OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of PMEs that can be aggregated by the local PAF. The number of PMEs currently assigned to a particular EFMCu port (efmCuNumPMEs) is never greater than efmCuPAFCapacity. This object maps to the Clause 30 attribute aLocalPAFCapacity." REFERENCE "[802.3ah] 61.2.2, 30.11.1.1.6" ::= { efmCuPortCapabilityEntry 3 } efmCuPeerPAFCapacity OBJECT-TYPE SYNTAX Unsigned32 (0|1..32) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of PMEs that can be aggregated by the PAF of the peer PHY (PCS port). A value of 0 is returned when peer PAF capacity is unknown (peer cannot be reached). Beili Standards Track [Page 35] RFC 5066 EFMCu Interfaces MIB November 2007 This object maps to the Clause 30 attribute aRemotePAFCapacity." REFERENCE "[802.3ah] 61.2.2, 30.11.1.1.10" ::= { efmCuPortCapabilityEntry 4 } efmCuPortStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPortStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides overall status information of EFMCu 2BASE-TL/10PASS-TS ports, complementing the generic status information from the ifTable of IF-MIB and ifMauTable of MAU-MIB. Additional status information about connected PMEs is available from the efmCuPmeStatusTable. This table contains live data from the equipment. As such, it is NOT persistent." ::= { efmCuPort 3 } efmCuPortStatusEntry OBJECT-TYPE SYNTAX EfmCuPortStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu Port Status table. Each entry represents an EFMCu port indexed by the ifIndex. Note that an EFMCu PCS port runs on top of a single or multiple PME port(s), which are also indexed by ifIndex." INDEX { ifIndex } ::= { efmCuPortStatusTable 1 } EfmCuPortStatusEntry ::= SEQUENCE { efmCuFltStatus BITS, efmCuPortSide INTEGER, efmCuNumPMEs Unsigned32, efmCuPAFInErrors Counter32, efmCuPAFInSmallFragments Counter32, efmCuPAFInLargeFragments Counter32, efmCuPAFInBadFragments Counter32, efmCuPAFInLostFragments Counter32, efmCuPAFInLostStarts Counter32, efmCuPAFInLostEnds Counter32, efmCuPAFInOverflows Counter32 } Beili Standards Track [Page 36] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuFltStatus OBJECT-TYPE SYNTAX BITS { noPeer(0), peerPowerLoss(1), pmeSubTypeMismatch(2), lowRate(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "EFMCu (PCS) port Fault Status. This is a bitmap of possible conditions. The various bit positions are: noPeer - the peer PHY cannot be reached (e.g., no PMEs attached, all PMEs are Down, etc.). More info is available in efmCuPmeFltStatus. peerPowerLoss - the peer PHY has indicated impending unit failure due to loss of local power ('Dying Gasp'). pmeSubTypeMismatch - local PMEs in the aggregation group are not of the same subtype, e.g., some PMEs in the local device are -O while others are -R subtype. lowRate - ifSpeed of the port reached or dropped below efmCuThreshLowRate. This object is intended to supplement the ifOperStatus object in IF-MIB and ifMauMediaAvailable in MAU-MIB. Additional information is available via the efmCuPmeFltStatus object for each PME in the aggregation group (single PME if PAF is disabled)." REFERENCE "IF-MIB, ifOperStatus; MAU-MIB, ifMauMediaAvailable; efmCuPmeFltStatus" ::= { efmCuPortStatusEntry 1 } efmCuPortSide OBJECT-TYPE SYNTAX INTEGER { subscriber(1), office(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "EFM port mode of operation (subtype). The value of 'subscriber' indicates that the port is Beili Standards Track [Page 37] RFC 5066 EFMCu Interfaces MIB November 2007 designated as '-R' subtype (all PMEs assigned to this port are of subtype '-R'). The value of the 'office' indicates that the port is designated as '-O' subtype (all PMEs assigned to this port are of subtype '-O'). The value of 'unknown' indicates that the port has no assigned PMEs yet or that the assigned PMEs are not of the same side (subTypePMEMismatch). This object partially maps to the Clause 30 attribute aPhyEnd." REFERENCE "[802.3ah] 61.1, 30.11.1.1.2" ::= { efmCuPortStatusEntry 2 } efmCuNumPMEs OBJECT-TYPE SYNTAX Unsigned32 (0..32) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of PMEs that is currently aggregated by the local PAF (assigned to the EFMCu port using the ifStackTable). This number is never greater than efmCuPAFCapacity. This object SHALL be automatically incremented or decremented when a PME is added or deleted to/from the EFMCu port using the ifStackTable." REFERENCE "[802.3ah] 61.2.2, 30.11.1.1.6" ::= { efmCuPortStatusEntry 3 } efmCuPAFInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of fragments that have been received across the gamma interface with RxErr asserted and discarded. This read-only counter is inactive (not incremented) when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF RX error register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, Beili Standards Track [Page 38] RFC 5066 EFMCu Interfaces MIB November 2007 defined in IF-MIB." REFERENCE "[802.3ah] 45.2.3.21" ::= { efmCuPortStatusEntry 4 } efmCuPAFInSmallFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of fragments smaller than minFragmentSize (64 bytes) that have been received across the gamma interface and discarded. This read-only counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF small fragments register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 45.2.3.22" ::= { efmCuPortStatusEntry 5 } efmCuPAFInLargeFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of fragments larger than maxFragmentSize (512 bytes) that have been received across the gamma interface and discarded. This read-only counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF large fragments register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE Beili Standards Track [Page 39] RFC 5066 EFMCu Interfaces MIB November 2007 "[802.3ah] 45.2.3.23" ::= { efmCuPortStatusEntry 6 } efmCuPAFInBadFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of fragments that do not fit into the sequence expected by the frame assembly function and that have been received across the gamma interface and discarded (the frame buffer is flushed to the next valid frame start). This read-only counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF bad fragments register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 45.2.3.25" ::= { efmCuPortStatusEntry 7 } efmCuPAFInLostFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of gaps in the sequence of fragments that have been received across the gamma interface (the frame buffer is flushed to the next valid frame start, when fragment/fragments expected by the frame assembly function is/are not received). This read-only counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF lost fragment register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE Beili Standards Track [Page 40] RFC 5066 EFMCu Interfaces MIB November 2007 "[802.3ah] 45.2.3.26" ::= { efmCuPortStatusEntry 8 } efmCuPAFInLostStarts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of missing StartOfPacket indicators expected by the frame assembly function. This read-only counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF lost start of fragment register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 45.2.3.27" ::= { efmCuPortStatusEntry 9 } efmCuPAFInLostEnds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of missing EndOfPacket indicators expected by the frame assembly function. This read-only counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF lost start of fragment register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 45.2.3.28" ::= { efmCuPortStatusEntry 10 } Beili Standards Track [Page 41] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPAFInOverflows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of fragments, received across the gamma interface and discarded, which would have caused the frame assembly buffer to overflow. This read-only counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the counter retains its previous value. If a Clause 45 MDIO Interface to the PCS is present, then this object maps to the 10P/2B PAF overflow register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 45.2.3.24" ::= { efmCuPortStatusEntry 11 } -- PME Notifications Group efmCuPmeNotifications OBJECT IDENTIFIER ::= { efmCuPme 0 } efmCuPmeLineAtnCrossing NOTIFICATION-TYPE OBJECTS { efmCuPmeLineAtn, efmCuPmeThreshLineAtn } STATUS current DESCRIPTION "This notification indicates that the loop attenuation threshold (as per the efmCuPmeThreshLineAtn value) has been reached/exceeded for the 2BASE-TL/10PASS-TS PME. This notification MAY be sent on the crossing event in both directions: from normal to exceeded and from exceeded to normal. It is RECOMMENDED that a small debouncing period of 2.5 sec, between the detection of the condition and the notification, is implemented to prevent intermittent notifications from being sent. Generation of this notification is controlled by the efmCuPmeLineAtnCrossingEnable object." Beili Standards Track [Page 42] RFC 5066 EFMCu Interfaces MIB November 2007 ::= { efmCuPmeNotifications 1 } efmCuPmeSnrMgnCrossing NOTIFICATION-TYPE OBJECTS { efmCuPmeSnrMgn, efmCuPmeThreshSnrMgn } STATUS current DESCRIPTION "This notification indicates that the SNR margin threshold (as per the efmCuPmeThreshSnrMgn value) has been reached/exceeded for the 2BASE-TL/10PASS-TS PME. This notification MAY be sent on the crossing event in both directions: from normal to exceeded and from exceeded to normal. It is RECOMMENDED that a small debouncing period of 2.5 sec, between the detection of the condition and the notification, is implemented to prevent intermittent notifications from being sent. Generation of this notification is controlled by the efmCuPmeSnrMgnCrossingEnable object." ::= { efmCuPmeNotifications 2 } efmCuPmeDeviceFault NOTIFICATION-TYPE OBJECTS { efmCuPmeFltStatus } STATUS current DESCRIPTION "This notification indicates that a fault in the PME has been detected by a vendor-specific diagnostic or a self-test. Generation of this notification is controlled by the efmCuPmeDeviceFaultEnable object." ::= { efmCuPmeNotifications 3 } efmCuPmeConfigInitFailure NOTIFICATION-TYPE OBJECTS { efmCuPmeFltStatus, efmCuAdminProfile, efmCuPmeAdminProfile } STATUS current DESCRIPTION "This notification indicates that PME initialization has failed, due to inability of the PME link to achieve the Beili Standards Track [Page 43] RFC 5066 EFMCu Interfaces MIB November 2007 requested configuration profile. Generation of this notification is controlled by the efmCuPmeConfigInitFailEnable object." ::= { efmCuPmeNotifications 4 } efmCuPmeProtocolInitFailure NOTIFICATION-TYPE OBJECTS { efmCuPmeFltStatus, efmCuPmeOperSubType } STATUS current DESCRIPTION "This notification indicates that the peer PME was using an incompatible protocol during initialization. Generation of this notification is controlled by the efmCuPmeProtocolInitFailEnable object." ::= { efmCuPmeNotifications 5 } -- The PME group efmCuPmeConfTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPmeConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table for Configuration of common aspects for EFMCu 2BASE-TL/10PASS-TS PME ports (modems). Configuration of aspects specific to 2BASE-TL or 10PASS-TS PME types is represented in efmCuPme2BConfTable and efmCuPme10PConfTable, respectively. Entries in this table MUST be maintained in a persistent manner." ::= { efmCuPme 1 } efmCuPmeConfEntry OBJECT-TYPE SYNTAX EfmCuPmeConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu PME Configuration table. Each entry represents common aspects of an EFMCu PME port indexed by the ifIndex. Note that an EFMCu PME port can be stacked below a single PCS port, also indexed by ifIndex, possibly together with other PME ports if PAF is enabled." INDEX { ifIndex } Beili Standards Track [Page 44] RFC 5066 EFMCu Interfaces MIB November 2007 ::= { efmCuPmeConfTable 1 } EfmCuPmeConfEntry ::= SEQUENCE { efmCuPmeAdminSubType INTEGER, efmCuPmeAdminProfile EfmProfileIndexOrZero, efmCuPAFRemoteDiscoveryCode PhysAddress, efmCuPmeThreshLineAtn Integer32, efmCuPmeThreshSnrMgn Integer32, efmCuPmeLineAtnCrossingEnable TruthValue, efmCuPmeSnrMgnCrossingEnable TruthValue, efmCuPmeDeviceFaultEnable TruthValue, efmCuPmeConfigInitFailEnable TruthValue, efmCuPmeProtocolInitFailEnable TruthValue } efmCuPmeAdminSubType OBJECT-TYPE SYNTAX INTEGER { ieee2BaseTLO(1), ieee2BaseTLR(2), ieee10PassTSO(3), ieee10PassTSR(4), ieee2BaseTLor10PassTSR(5), ieee2BaseTLor10PassTSO(6), ieee10PassTSor2BaseTLO(7) } MAX-ACCESS read-write STATUS current DESCRIPTION "Administrative (desired) subtype of the PME. Possible values are: ieee2BaseTLO - PME SHALL operate as 2BaseTL-O ieee2BaseTLR - PME SHALL operate as 2BaseTL-R ieee10PassTSO - PME SHALL operate as 10PassTS-O ieee10PassTSR - PME SHALL operate as 10PassTS-R ieee2BaseTLor10PassTSR - PME SHALL operate as 2BaseTL-R or 10PassTS-R. The actual value will be set by the -O link partner during initialization (handshake). ieee2BaseTLor10PassTSO - PME SHALL operate as 2BaseTL-O (preferred) or 10PassTS-O. The actual value will be set during initialization depending on the -R link partner capability (i.e., if -R is incapable of the preferred 2BaseTL mode, 10PassTS will be used). ieee10PassTSor2BaseTLO - PME SHALL operate as 10PassTS-O Beili Standards Track [Page 45] RFC 5066 EFMCu Interfaces MIB November 2007 (preferred) or 2BaseTL-O. The actual value will be set during initialization depending on the -R link partner capability (i.e., if -R is incapable of the preferred 10PassTS mode, 2BaseTL will be used). Changing efmCuPmeAdminSubType is a traffic-disruptive operation and as such SHALL be done when the link is Down. Attempts to change this object SHALL be rejected if the link is Up or Initializing. Attempts to change this object to an unsupported subtype (see efmCuPmeSubTypesSupported) SHALL be rejected. The current operational subtype is indicated by the efmCuPmeOperSubType variable. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this object combines values of the Port subtype select bits and the PMA/PMD type selection bits in the 10P/2B PMA/PMD control register." REFERENCE "[802.3ah] 61.1, 45.2.1.11.4, 45.2.1.11.7" ::= { efmCuPmeConfEntry 1 } efmCuPmeAdminProfile OBJECT-TYPE SYNTAX EfmProfileIndexOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "Desired PME configuration profile. This object is a pointer to an entry in either the efmCuPme2BProfileTable or the efmCuPme10PProfileTable, depending on the current operating SubType of the PME. The value of this object is the index of the referenced profile. The value of zero (default) indicates that the PME is configured via the efmCuAdminProfile object for the PCS port to which this PME is assigned. That is, the profile referenced by efmCuPmeAdminProfile takes precedence over the profile(s) referenced by efmCuAdminProfile. This object is writable and readable for the CO subtype PMEs (2BaseTL-O or 10PassTS-O). It is irrelevant for the CPE subtype (2BaseTL-R or 10PassTS-R) -- a zero value SHALL be returned on an attempt to read this object and any attempt to change this object MUST be rejected in this case. Beili Standards Track [Page 46] RFC 5066 EFMCu Interfaces MIB November 2007 Note that the current operational profile value is available via efmCuPmeOperProfile object. Any modification of this object MUST be performed when the link is Down. Attempts to change this object MUST be rejected, if the link is Up or Initializing. Attempts to set this object to a value that is not the value of the index for an active entry in the corresponding profile table MUST be rejected. This object maps to the Clause 30 attribute aProfileSelect. This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 30.11.2.1.6" DEFVAL { 0 } ::= { efmCuPmeConfEntry 2 } efmCuPAFRemoteDiscoveryCode OBJECT-TYPE SYNTAX PhysAddress (SIZE(0|6)) MAX-ACCESS read-write STATUS current DESCRIPTION "PAF Remote Discovery Code of the PME port at the CO. The 6-octet Discovery Code of the peer PCS connected via the PME. Reading this object results in a Discovery Get operation. Setting this object to all zeroes results in a Discovery Clear_if_Same operation (the value of efmCuPAFDiscoveryCode at the peer PCS SHALL be the same as efmCuPAFDiscoveryCode of the local PCS associated with the PME for the operation to succeed). Writing a non-zero value to this object results in a Discovery Set_if_Clear operation. A zero-length octet string SHALL be returned on an attempt to read this object when PAF aggregation is not enabled. This object is irrelevant in CPE port (-R) subtypes: in this case, a zero-length octet string SHALL be returned on an attempt to read this object; writing to this object SHALL be rejected. Discovery MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing. Beili Standards Track [Page 47] RFC 5066 EFMCu Interfaces MIB November 2007 If a Clause 45 MDIO Interface to the PMA/PMD is present, then this object is a function of 10P/2B aggregation discovery control register, Discovery operation result bits in 10P/2B aggregation and discovery status register and 10P/2B aggregation discovery code register." REFERENCE "[802.3ah] 61.2.2.8.4, 45.2.6.6-45.2.6.8" ::= { efmCuPmeConfEntry 3 } efmCuPmeThreshLineAtn OBJECT-TYPE SYNTAX Integer32(-127..128) UNITS "dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Desired Line Attenuation threshold for the 2B/10P PME. This object configures the line attenuation alarm threshold. When the current value of Line Attenuation reaches or exceeds this threshold, an efmCuPmeLineAtnCrossing notification MAY be generated, if enabled by efmCuPmeLineAtnCrossingEnable. This object is writable for the CO subtype PMEs (-O). It is read-only for the CPE subtype (-R). Changing of the Line Attenuation threshold MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing. If a Clause 45 MDIO Interface to the PME is present, then this object maps to the loop attenuation threshold bits in the 2B PMD line quality thresholds register." REFERENCE "[802.3ah] 45.2.1.36" ::= { efmCuPmeConfEntry 4 } efmCuPmeThreshSnrMgn OBJECT-TYPE SYNTAX Integer32(-127..128) UNITS "dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Desired SNR margin threshold for the 2B/10P PME. This object configures the SNR margin alarm threshold. When the current value of SNR margin reaches or exceeds this threshold, an efmCuPmeSnrMgnCrossing notification MAY be generated, if enabled by efmCuPmeSnrMgnCrossingEnable. Beili Standards Track [Page 48] RFC 5066 EFMCu Interfaces MIB November 2007 This object is writable for the CO subtype PMEs (2BaseTL-O/10PassTS-O). It is read-only for the CPE subtype (2BaseTL-R/10PassTS-R). Changing of the SNR margin threshold MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue), if the link is Up or Initializing. If a Clause 45 MDIO Interface to the PME is present, then this object maps to the SNR margin threshold bits in the 2B PMD line quality thresholds register." REFERENCE "[802.3ah] 45.2.1.36" ::= { efmCuPmeConfEntry 5 } efmCuPmeLineAtnCrossingEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether efmCuPmeLineAtnCrossing notifications should be generated for this interface. A value of true(1) indicates that efmCuPmeLineAtnCrossing notification is enabled. A value of false(2) indicates that the notification is disabled." ::= { efmCuPmeConfEntry 6 } efmCuPmeSnrMgnCrossingEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether efmCuPmeSnrMgnCrossing notifications should be generated for this interface. A value of true(1) indicates that efmCuPmeSnrMgnCrossing notification is enabled. A value of false(2) indicates that the notification is disabled." ::= { efmCuPmeConfEntry 7 } efmCuPmeDeviceFaultEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether efmCuPmeDeviceFault notifications Beili Standards Track [Page 49] RFC 5066 EFMCu Interfaces MIB November 2007 should be generated for this interface. A value of true(1) indicates that efmCuPmeDeviceFault notification is enabled. A value of false(2) indicates that the notification is disabled." ::= { efmCuPmeConfEntry 8 } efmCuPmeConfigInitFailEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether efmCuPmeConfigInitFailure notifications should be generated for this interface. A value of true(1) indicates that efmCuPmeConfigInitFailure notification is enabled. A value of false(2) indicates that the notification is disabled." ::= { efmCuPmeConfEntry 9 } efmCuPmeProtocolInitFailEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether efmCuPmeProtocolInitFailure notifications should be generated for this interface. A value of true(1) indicates that efmCuPmeProtocolInitFailure notification is enabled. A value of false(2) indicates that the notification is disabled." ::= { efmCuPmeConfEntry 10 } efmCuPmeCapabilityTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPmeCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table for the configuration of common aspects for EFMCu 2BASE-TL/10PASS-TS PME ports (modems). The configuration of aspects specific to 2BASE-TL or 10PASS-TS PME types is represented in the efmCuPme2BConfTable and the efmCuPme10PConfTable, respectively. Entries in this table MUST be maintained in a persistent manner." ::= { efmCuPme 2 } Beili Standards Track [Page 50] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPmeCapabilityEntry OBJECT-TYPE SYNTAX EfmCuPmeCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu PME Capability table. Each entry represents common aspects of an EFMCu PME port indexed by the ifIndex. Note that an EFMCu PME port can be stacked below a single PCS port, also indexed by ifIndex, possibly together with other PME ports if PAF is enabled." INDEX { ifIndex } ::= { efmCuPmeCapabilityTable 1 } EfmCuPmeCapabilityEntry ::= SEQUENCE { efmCuPmeSubTypesSupported BITS } efmCuPmeSubTypesSupported OBJECT-TYPE SYNTAX BITS { ieee2BaseTLO(0), ieee2BaseTLR(1), ieee10PassTSO(2), ieee10PassTSR(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "PME supported subtypes. This is a bitmap of possible subtypes. The various bit positions are: ieee2BaseTLO - PME is capable of operating as 2BaseTL-O ieee2BaseTLR - PME is capable of operating as 2BaseTL-R ieee10PassTSO - PME is capable of operating as 10PassTS-O ieee10PassTSR - PME is capable of operating as 10PassTS-R The desired mode of operation is determined by efmCuPmeAdminSubType, while efmCuPmeOperSubType reflects the current operating mode. If a Clause 45 MDIO Interface to the PCS is present, then this object combines the 10PASS-TS capable and 2BASE-TL capable bits in the 10P/2B PMA/PMD speed ability register and the CO supported and CPE supported bits in the 10P/2B PMA/PMD status register." REFERENCE "[802.3ah] 61.1, 45.2.1.4.1, 45.2.1.4.2, 45.2.1.12.2, 45.2.1.12.3" ::= { efmCuPmeCapabilityEntry 1 } Beili Standards Track [Page 51] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPmeStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPmeStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides common status information of EFMCu 2BASE-TL/10PASS-TS PME ports. Status information specific to 10PASS-TS PME is represented in efmCuPme10PStatusTable. This table contains live data from the equipment. As such, it is NOT persistent." ::= { efmCuPme 3 } efmCuPmeStatusEntry OBJECT-TYPE SYNTAX EfmCuPmeStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu PME Status table. Each entry represents common aspects of an EFMCu PME port indexed by the ifIndex. Note that an EFMCu PME port can be stacked below a single PCS port, also indexed by ifIndex, possibly together with other PME ports if PAF is enabled." INDEX { ifIndex } ::= { efmCuPmeStatusTable 1 } EfmCuPmeStatusEntry ::= SEQUENCE { efmCuPmeOperStatus INTEGER, efmCuPmeFltStatus BITS, efmCuPmeOperSubType INTEGER, efmCuPmeOperProfile EfmProfileIndexOrZero, efmCuPmeSnrMgn Integer32, efmCuPmePeerSnrMgn Integer32, efmCuPmeLineAtn Integer32, efmCuPmePeerLineAtn Integer32, efmCuPmeEquivalentLength Unsigned32, efmCuPmeTCCodingErrors Counter32, efmCuPmeTCCrcErrors Counter32 } efmCuPmeOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), downNotReady(2), downReady(3), init(4) } Beili Standards Track [Page 52] RFC 5066 EFMCu Interfaces MIB November 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "Current PME link Operational Status. Possible values are: up(1) - The link is Up and ready to pass 64/65-octet encoded frames or fragments. downNotReady(2) - The link is Down and the PME does not detect Handshake tones from its peer. This value may indicate a possible problem with the peer PME. downReady(3) - The link is Down and the PME detects Handshake tones from its peer. init(4) - The link is Initializing, as a result of ifAdminStatus being set to 'up' for a particular PME or a PCS to which the PME is connected. This object is intended to supplement the Down(2) state of ifOperStatus. This object partially maps to the Clause 30 attribute aPMEStatus. If a Clause 45 MDIO Interface to the PME is present, then this object partially maps to PMA/PMD link status bits in 10P/2B PMA/PMD status register." REFERENCE "[802.3ah] 30.11.2.1.3, 45.2.1.12.4" ::= { efmCuPmeStatusEntry 1 } efmCuPmeFltStatus OBJECT-TYPE SYNTAX BITS { lossOfFraming(0), snrMgnDefect(1), lineAtnDefect(2), deviceFault(3), configInitFailure(4), protocolInitFailure(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current/Last PME link Fault Status. This is a bitmap of possible conditions. The various bit positions are: lossOfFraming - Loss of Framing for 10P or Loss of Sync word for 2B PMD or Loss of 64/65-octet framing. Beili Standards Track [Page 53] RFC 5066 EFMCu Interfaces MIB November 2007 snrMgnDefect - SNR margin dropped below the threshold. lineAtnDefect - Line Attenuation exceeds the threshold. deviceFault - Indicates a vendor-dependent diagnostic or self-test fault has been detected. configInitFailure - Configuration initialization failure, due to inability of the PME link to support the configuration profile, requested during initialization. protocolInitFailure - Protocol initialization failure, due to an incompatible protocol used by the peer PME during init (that could happen if a peer PMD is a regular G.SDHSL/VDSL modem instead of a 2BASE-TL/10PASS-TS PME). This object is intended to supplement ifOperStatus in IF-MIB. This object holds information about the last fault. efmCuPmeFltStatus is cleared by the device restart. In addition, lossOfFraming, configInitFailure, and protocolInitFailure are cleared by PME init; deviceFault is cleared by successful diagnostics/test; snrMgnDefect and lineAtnDefect are cleared by SNR margin and Line attenuation, respectively, returning to norm and by PME init. This object partially maps to the Clause 30 attribute aPMEStatus. If a Clause 45 MDIO Interface to the PME is present, then this object consolidates information from various PMA/PMD registers, namely: Fault bit in PMA/PMD status 1 register, 10P/2B PMA/PMD link loss register, 10P outgoing indicator bits status register, 10P incoming indicator bits status register, 2B state defects register." REFERENCE "[802.3ah] 30.11.2.1.3, 45.2.1.2.1, 45.2.1.38, 45.2.1.39, 45.2.1.54" ::= { efmCuPmeStatusEntry 2 } efmCuPmeOperSubType OBJECT-TYPE SYNTAX INTEGER { ieee2BaseTLO(1), ieee2BaseTLR(2), Beili Standards Track [Page 54] RFC 5066 EFMCu Interfaces MIB November 2007 ieee10PassTSO(3), ieee10PassTSR(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current operational subtype of the PME. Possible values are: ieee2BaseTLO - PME operates as 2BaseTL-O ieee2BaseTLR - PME operates as 2BaseTL-R ieee10PassTSO - PME operates as 10PassTS-O ieee10PassTSR - PME operates as 10PassTS-R The desired operational subtype of the PME can be configured via the efmCuPmeAdminSubType variable. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this object combines values of the Port subtype select bits, the PMA/PMD type selection bits in the 10P/2B PMA/PMD control register, and the PMA/PMD link status bits in the 10P/2B PMA/PMD status register." REFERENCE "[802.3ah] 61.1, 45.2.1.11.4, 45.2.1.11.7, 45.2.1.12.4" ::= { efmCuPmeStatusEntry 3 } efmCuPmeOperProfile OBJECT-TYPE SYNTAX EfmProfileIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "PME current operating profile. This object is a pointer to an entry in either the efmCuPme2BProfileTable or the efmCuPme10PProfileTable, depending on the current operating SubType of the PME as indicated by efmCuPmeOperSubType. Note that a profile entry to which efmCuPmeOperProfile is pointing can be created automatically to reflect achieved parameters in adaptive (not fixed) initialization, i.e., values of efmCuPmeOperProfile and efmCuAdminProfile or efmCuPmeAdminProfile may differ. The value of zero indicates that the PME is Down or Initializing. This object partially maps to the aOperatingProfile attribute in Clause 30." REFERENCE "[802.3ah] 30.11.2.1.7" ::= { efmCuPmeStatusEntry 4 } Beili Standards Track [Page 55] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPmeSnrMgn OBJECT-TYPE SYNTAX Integer32(-127..128|65535) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The current Signal to Noise Ratio (SNR) margin with respect to the received signal as perceived by the local PME. The value of 65535 is returned when the PME is Down or Initializing. This object maps to the aPMESNRMgn attribute in Clause 30. If a Clause 45 MDIO Interface is present, then this object maps to the 10P/2B RX SNR margin register." REFERENCE "[802.3ah] 30.11.2.1.4, 45.2.1.16" ::= { efmCuPmeStatusEntry 5 } efmCuPmePeerSnrMgn OBJECT-TYPE SYNTAX Integer32(-127..128|65535) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The current SNR margin in dB with respect to the received signal, as perceived by the remote (link partner) PME. The value of 65535 is returned when the PME is Down or Initializing. This object is irrelevant for the -R PME subtypes. The value of 65535 SHALL be returned in this case. If a Clause 45 MDIO Interface is present, then this object maps to the 10P/2B link partner RX SNR margin register." REFERENCE "[802.3ah] 45.2.1.17" ::= { efmCuPmeStatusEntry 6} efmCuPmeLineAtn OBJECT-TYPE SYNTAX Integer32(-127..128|65535) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The current Line Attenuation in dB as perceived by the local PME. Beili Standards Track [Page 56] RFC 5066 EFMCu Interfaces MIB November 2007 The value of 65535 is returned when the PME is Down or Initializing. If a Clause 45 MDIO Interface is present, then this object maps to the Line Attenuation register." REFERENCE "[802.3ah] 45.2.1.18" ::= { efmCuPmeStatusEntry 7 } efmCuPmePeerLineAtn OBJECT-TYPE SYNTAX Integer32(-127..128|65535) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The current Line Attenuation in dB as perceived by the remote (link partner) PME. The value of 65535 is returned when the PME is Down or Initializing. This object is irrelevant for the -R PME subtypes. The value of 65535 SHALL be returned in this case. If a Clause 45 MDIO Interface is present, then this object maps to the 20P/2B link partner Line Attenuation register." REFERENCE "[802.3ah] 45.2.1.19" ::= { efmCuPmeStatusEntry 8 } efmCuPmeEquivalentLength OBJECT-TYPE SYNTAX Unsigned32(0..8192|65535) UNITS "m" MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the equivalent loop's physical length in meters, as perceived by the PME after the link is established. An equivalent loop is a hypothetical 26AWG (0.4mm) loop with a perfect square root attenuation characteristic, without any bridged taps. The value of 65535 is returned if the link is Down or Initializing or the PME is unable to estimate the equivalent length. For a 10BASE-TL PME, if a Clause 45 MDIO Interface to the PME is present, then this object maps to the 10P Electrical Length register." Beili Standards Track [Page 57] RFC 5066 EFMCu Interfaces MIB November 2007 REFERENCE "[802.3ah] 45.2.1.21" ::= { efmCuPmeStatusEntry 9 } efmCuPmeTCCodingErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 64/65-octet encapsulation errors. This counter is incremented for each 64/65-octet encapsulation error detected by the 64/65-octet receive function. This object maps to aTCCodingViolations attribute in Clause 30. If a Clause 45 MDIO Interface to the PME TC is present, then this object maps to the TC coding violations register (see 45.2.6.12). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 61.3.3.1, 30.11.2.1.5, 45.2.6.12" ::= { efmCuPmeStatusEntry 10 } efmCuPmeTCCrcErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of TC-CRC errors. This counter is incremented for each TC-CRC error detected by the 64/65-octet receive function (see 61.3.3.3 and Figure 61-19). This object maps to aTCCRCErrors attribute in Clause 30. If a Clause 45 MDIO Interface to the PME TC is present, then this object maps to the TC CRC error register (see 45.2.6.11). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." Beili Standards Track [Page 58] RFC 5066 EFMCu Interfaces MIB November 2007 REFERENCE "[802.3ah] 61.3.3.3, 30.11.2.1.10, 45.2.6.11" ::= { efmCuPmeStatusEntry 11 } -- 2BASE-TL specific PME group efmCuPme2B OBJECT IDENTIFIER ::= { efmCuPme 5 } efmCuPme2BProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPme2BProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports definitions of administrative and operating profiles for 2BASE-TL PMEs. The first 14 entries in this table SHALL always be defined as follows (see 802.3ah Annex 63A): -------+-------+-------+-----+------+-------------+----------- Profile MinRate MaxRate Power Region Constellation Comment index (Kbps) (Kbps) (dBm) -------+-------+-------+-----+------+-------------+----------- 1 5696 5696 13.5 1 32-TCPAM default 2 3072 3072 13.5 1 32-TCPAM 3 2048 2048 13.5 1 16-TCPAM 4 1024 1024 13.5 1 16-TCPAM 5 704 704 13.5 1 16-TCPAM 6 512 512 13.5 1 16-TCPAM 7 5696 5696 14.5 2 32-TCPAM 8 3072 3072 14.5 2 32-TCPAM 9 2048 2048 14.5 2 16-TCPAM 10 1024 1024 13.5 2 16-TCPAM 11 704 704 13.5 2 16-TCPAM 12 512 512 13.5 2 16-TCPAM 13 192 5696 0 1 0 best effort 14 192 5696 0 2 0 best effort -------+-------+-------+-----+------+-------------+----------- These default entries SHALL be created during agent initialization and MUST NOT be deleted. Entries following the first 14 can be dynamically created and deleted to provide custom administrative (configuration) profiles and automatic operating profiles. This table MUST be maintained in a persistent manner." REFERENCE "[802.3ah] Annex 63A, 30.11.2.1.6" ::= { efmCuPme2B 2 } Beili Standards Track [Page 59] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPme2BProfileEntry OBJECT-TYPE SYNTAX EfmCuPme2BProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to a single 2BASE-TL PME profile. Each profile contains a set of parameters, used either for configuration or representation of a 2BASE-TL PME. In case a particular profile is referenced via the efmCuPmeAdminProfile object (or efmCuAdminProfile if efmCuPmeAdminProfile is zero), it represents the desired parameters for the 2BaseTL-O PME initialization. If a profile is referenced via an efmCuPmeOperProfile object, it represents the current operating parameters of an operational PME. Profiles may be created/deleted using the row creation/ deletion mechanism via efmCuPme2BProfileRowStatus. If an active entry is referenced, the entry MUST remain 'active' until all references are removed. Default entries MUST NOT be removed." INDEX { efmCuPme2BProfileIndex } ::= { efmCuPme2BProfileTable 1 } EfmCuPme2BProfileEntry ::= SEQUENCE { efmCuPme2BProfileIndex EfmProfileIndex, efmCuPme2BProfileDescr SnmpAdminString, efmCuPme2BRegion INTEGER, efmCuPme2BsMode EfmProfileIndexOrZero, efmCuPme2BMinDataRate Unsigned32, efmCuPme2BMaxDataRate Unsigned32, efmCuPme2BPower Unsigned32, efmCuPme2BConstellation INTEGER, efmCuPme2BProfileRowStatus RowStatus } efmCuPme2BProfileIndex OBJECT-TYPE SYNTAX EfmProfileIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "2BASE-TL PME profile index. This object is the unique index associated with this profile. Entries in this table are referenced via efmCuAdminProfile or efmCuPmeAdminProfile objects." ::= { efmCuPme2BProfileEntry 1 } Beili Standards Track [Page 60] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPme2BProfileDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A textual string containing information about a 2BASE-TL PME profile. The string may include information about the data rate and spectral limitations of this particular profile." ::= { efmCuPme2BProfileEntry 2 } efmCuPme2BRegion OBJECT-TYPE SYNTAX INTEGER { region1(1), region2(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Regional settings for a 2BASE-TL PME, as specified in the relevant Regional Annex of [G.991.2]. Regional settings specify the Power Spectral Density (PSD) mask and the Power Back-Off (PBO) values, and place limitations on the max allowed data rate, power, and constellation. Possible values for this object are: region1 - Annexes A and F (e.g., North America) region2 - Annexes B and G (e.g., Europe) Annex A/B specify regional settings for data rates 192-2304 Kbps using 16-TCPAM encoding. Annex F/G specify regional settings for rates 2320-3840 Kbps using 16-TCPAM encoding and 768-5696 Kbps using 32-TCPAM encoding. If a Clause 45 MDIO Interface to the PME is present, then this object partially maps to the Region bits in the 2B general parameter register." REFERENCE "[802.3ah] 45.2.1.42; [G.991.2] Annexes A, B, F and G" ::= { efmCuPme2BProfileEntry 3 } efmCuPme2BsMode OBJECT-TYPE SYNTAX EfmProfileIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Desired custom Spectral Mode for a 2BASE-TL PME. This object Beili Standards Track [Page 61] RFC 5066 EFMCu Interfaces MIB November 2007 is a pointer to an entry in efmCuPme2BsModeTable and a block of entries in efmCuPme2BRateReachTable, which together define (country-specific) reach-dependent rate limitations in addition to those defined by efmCuPme2BRegion. The value of this object is the index of the referenced spectral mode. The value of zero (default) indicates that no specific spectral mode is applicable. Attempts to set this object to a value that is not the value of the index for an active entry in the corresponding spectral mode table MUST be rejected." REFERENCE "efmCuPme2BsModeTable, efmCuPme2BRateReachTable" DEFVAL { 0 } ::= { efmCuPme2BProfileEntry 4 } efmCuPme2BMinDataRate OBJECT-TYPE SYNTAX Unsigned32(192..5696) UNITS "Kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum Data Rate for the 2BASE-TL PME. This object can take values of (n x 64)Kbps, where n=3..60 for 16-TCPAM and n=12..89 for 32-TCPAM encoding. The data rate of the 2BASE-TL PME is considered 'fixed' when the value of this object equals that of efmCuPme2BMaxDataRate. If efmCuPme2BMinDataRate is less than efmCuPme2BMaxDataRate in the administrative profile, the data rate is considered 'adaptive', and SHALL be set to the maximum attainable rate not exceeding efmCuPme2BMaxDataRate, under the spectral limitations placed by the efmCuPme2BRegion and efmCuPme2BsMode. Note that the current operational data rate of the PME is represented by the ifSpeed object of IF-MIB. If a Clause 45 MDIO Interface to the PME is present, then this object maps to the Min Data Rate1 bits in the 2B PMD parameters register. This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 45.2.1.43" ::= { efmCuPme2BProfileEntry 5 } Beili Standards Track [Page 62] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPme2BMaxDataRate OBJECT-TYPE SYNTAX Unsigned32(192..5696) UNITS "Kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Data Rate for the 2BASE-TL PME. This object can take values of (n x 64)Kbps, where n=3..60 for 16-TCPAM and n=12..89 for 32-TCPAM encoding. The data rate of the 2BASE-TL PME is considered 'fixed' when the value of this object equals that of efmCuPme2BMinDataRate. If efmCuPme2BMinDataRate is less than efmCuPme2BMaxDataRate in the administrative profile, the data rate is considered 'adaptive', and SHALL be set to the maximum attainable rate not exceeding efmCuPme2BMaxDataRate, under the spectral limitations placed by the efmCuPme2BRegion and efmCuPme2BsMode. Note that the current operational data rate of the PME is represented by the ifSpeed object of IF-MIB. If a Clause 45 MDIO Interface to the PME is present, then this object maps to the Max Data Rate1 bits in the 2B PMD parameters register. This object MUST be maintained in a persistent manner." REFERENCE "[802.3ah] 45.2.1.43" ::= { efmCuPme2BProfileEntry 6 } efmCuPme2BPower OBJECT-TYPE SYNTAX Unsigned32(0|10..42) UNITS "0.5 dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Signal Transmit Power. Multiple of 0.5 dBm. The value of 0 in the administrative profile means that the signal transmit power is not fixed and SHALL be set to maximize the attainable rate, under the spectral limitations placed by the efmCuPme2BRegion and efmCuPme2BsMode. If a Clause 45 MDIO Interface to the PME is present, then this object maps to the Power1 bits in the 2B PMD parameters register." REFERENCE "[802.3ah] 45.2.1.43" Beili Standards Track [Page 63] RFC 5066 EFMCu Interfaces MIB November 2007 ::= { efmCuPme2BProfileEntry 7 } efmCuPme2BConstellation OBJECT-TYPE SYNTAX INTEGER { adaptive(0), tcpam16(1), tcpam32(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "TCPAM Constellation of the 2BASE-TL PME. The possible values are: adaptive(0) - either 16- or 32-TCPAM tcpam16(1) - 16-TCPAM tcpam32(2) - 32-TCPAM The value of adaptive(0) in the administrative profile means that the constellation is not fixed and SHALL be set to maximize the attainable rate, under the spectral limitations placed by the efmCuPme2BRegion and efmCuPme2BsMode. If a Clause 45 MDIO Interface to the PME is present, then this object maps to the Constellation1 bits in the 2B general parameter register." REFERENCE "[802.3ah] 45.2.1.43" ::= { efmCuPme2BProfileEntry 8 } efmCuPme2BProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the creation, modification, or deletion of the associated entry in the efmCuPme2BProfileTable per the semantics of RowStatus. If an 'active' entry is referenced via efmCuAdminProfile or efmCuPmeAdminProfile instance(s), the entry MUST remain 'active'. An 'active' entry SHALL NOT be modified. In order to modify an existing entry, it MUST be taken out of service (by setting this object to 'notInService'), modified, and set 'active' again." ::= { efmCuPme2BProfileEntry 9 } Beili Standards Track [Page 64] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPme2BsModeTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPme2BsModeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table, together with efmCu2BReachRateTable, supports definition of administrative custom spectral modes for 2BASE-TL PMEs, describing spectral limitations in addition to those specified by efmCuPme2BRegion. In some countries, spectral regulations (e.g., UK ANFP) limit the length of the loops for certain data rates. This table allows these country-specific limitations to be specified. Entries in this table referenced by the efmCuPme2BsMode MUST NOT be deleted until all the active references are removed. This table MUST be maintained in a persistent manner." REFERENCE "efmCu2BReachRateTable" ::= { efmCuPme2B 3 } efmCuPme2BsModeEntry OBJECT-TYPE SYNTAX EfmCuPme2BsModeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry specifies a spectral mode description and its index, which is used to reference corresponding entries in the efmCu2BReachRateTable. Entries may be created/deleted using the row creation/ deletion mechanism via efmCuPme2BsModeRowStatus." INDEX { efmCuPme2BsModeIndex } ::= { efmCuPme2BsModeTable 1 } EfmCuPme2BsModeEntry ::= SEQUENCE { efmCuPme2BsModeIndex EfmProfileIndex, efmCuPme2BsModeDescr SnmpAdminString, efmCuPme2BsModeRowStatus RowStatus } efmCuPme2BsModeIndex OBJECT-TYPE SYNTAX EfmProfileIndex MAX-ACCESS not-accessible STATUS current Beili Standards Track [Page 65] RFC 5066 EFMCu Interfaces MIB November 2007 DESCRIPTION "2BASE-TL PME Spectral Mode index. This object is the unique index associated with this spectral mode. Entries in this table are referenced via the efmCuPme2BsMode object." ::= { efmCuPme2BsModeEntry 1 } efmCuPme2BsModeDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A textual string containing information about a 2BASE-TL PME spectral mode. The string may include information about corresponding (country-specific) spectral regulations and rate/reach limitations of this particular spectral mode." ::= { efmCuPme2BsModeEntry 2 } efmCuPme2BsModeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls creation, modification, or deletion of the associated entry in efmCuPme2BsModeTable per the semantics of RowStatus. If an 'active' entry is referenced via efmCuPme2BsMode instance(s), the entry MUST remain 'active'. An 'active' entry SHALL NOT be modified. In order to modify an existing entry, it MUST be taken out of service (by setting this object to 'notInService'), modified, and set 'active' again." ::= { efmCuPme2BsModeEntry 3 } efmCuPme2BReachRateTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPme2BReachRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports the definition of administrative custom spectral modes for 2BASE-TL PMEs, providing spectral limitations in addition to those specified by efmCuPme2BRegion. Beili Standards Track [Page 66] RFC 5066 EFMCu Interfaces MIB November 2007 The spectral regulations in some countries (e.g., UK ANFP) limit the length of the loops for certain data rates. This table allows these country-specific limitations to be specified. Below is an example of this table for [ANFP]: ----------+-------+------- Equivalent MaxRate MaxRate Length PAM16 PAM32 (m) (Kbps) (Kbps) ----------+-------+------- 975 2304 5696 1125 2304 5504 1275 2304 5120 1350 2304 4864 1425 2304 4544 1500 2304 4288 1575 2304 3968 1650 2304 3776 1725 2304 3520 1800 2304 3264 1875 2304 3072 1950 2048 2688 2100 1792 2368 2250 1536 0 2400 1408 0 2550 1280 0 2775 1152 0 2925 1152 0 3150 1088 0 3375 1024 0 ----------+-------+------- Entries in this table referenced by an efmCuPme2BsMode instance MUST NOT be deleted. This table MUST be maintained in a persistent manner." REFERENCE "[ANFP]" ::= { efmCuPme2B 4 } efmCuPme2BReachRateEntry OBJECT-TYPE SYNTAX EfmCuPme2BReachRateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry specifies maximum 2BASE-TL PME data rates allowed for a certain equivalent loop length, when using Beili Standards Track [Page 67] RFC 5066 EFMCu Interfaces MIB November 2007 16-TCPAM or 32-TCPAM encoding. When a 2BASE-TL PME is initialized, its data rate MUST NOT exceed one of the following limitations: - the value of efmCuPme2BMaxDataRate - maximum data rate allowed by efmCuPme2BRegion and efmCuPme2BPower - maximum data rate for a given encoding specified in the efmCuPme2BsModeEntry, corresponding to the equivalent loop length, estimated by the PME It is RECOMMENDED that the efmCuPme2BEquivalentLength values are assigned in increasing order, starting from the minimum value. Entries may be created/deleted using the row creation/ deletion mechanism via efmCuPme2ReachRateRowStatus." INDEX { efmCuPme2BsModeIndex, efmCuPme2BReachRateIndex } ::= { efmCuPme2BReachRateTable 1 } EfmCuPme2BReachRateEntry ::= SEQUENCE { efmCuPme2BReachRateIndex EfmProfileIndex, efmCuPme2BEquivalentLength Unsigned32, efmCuPme2BMaxDataRatePam16 Unsigned32, efmCuPme2BMaxDataRatePam32 Unsigned32, efmCuPme2BReachRateRowStatus RowStatus } efmCuPme2BReachRateIndex OBJECT-TYPE SYNTAX EfmProfileIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "2BASE-TL custom spectral mode Reach-Rate table index. This object is the unique index associated with each entry." ::= { efmCuPme2BReachRateEntry 1 } efmCuPme2BEquivalentLength OBJECT-TYPE SYNTAX Unsigned32(0..8192) UNITS "m" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum allowed equivalent loop's physical length in meters for the specified data rates. An equivalent loop is a hypothetical 26AWG (0.4mm) loop with a perfect square root attenuation characteristic, without any Beili Standards Track [Page 68] RFC 5066 EFMCu Interfaces MIB November 2007 bridged taps." ::= { efmCuPme2BReachRateEntry 2 } efmCuPme2BMaxDataRatePam16 OBJECT-TYPE SYNTAX Unsigned32(0|192..5696) UNITS "Kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum data rate for a 2BASE-TL PME at the specified equivalent loop's length using TC-PAM16 encoding. The value of zero means that TC-PAM16 encoding should not be used at this distance." ::= { efmCuPme2BReachRateEntry 3 } efmCuPme2BMaxDataRatePam32 OBJECT-TYPE SYNTAX Unsigned32(0|192..5696) UNITS "Kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum data rate for a 2BASE-TL PME at the specified equivalent loop's length using TC-PAM32 encoding. The value of zero means that TC-PAM32 encoding should not be used at this distance." ::= { efmCuPme2BReachRateEntry 4 } efmCuPme2BReachRateRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls the creation, modification, or deletion of the associated entry in the efmCuPme2BReachRateTable per the semantics of RowStatus. If an 'active' entry is referenced via efmCuPme2BsMode instance(s), the entry MUST remain 'active'. An 'active' entry SHALL NOT be modified. In order to modify an existing entry, it MUST be taken out of service (by setting this object to 'notInService'), modified, and set 'active' again." ::= { efmCuPme2BReachRateEntry 5 } -- 10PASS-TS specific PME group Beili Standards Track [Page 69] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPme10P OBJECT IDENTIFIER ::= { efmCuPme 6 } efmCuPme10PProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPme10PProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table supports definitions of configuration profiles for 10PASS-TS PMEs. The first 22 entries in this table SHALL always be defined as follows (see 802.3ah Annex 62B.3, table 62B-1): -------+--------+----+---------+-----+-----+--------------- Profile Bandplan UPBO BandNotch DRate URate Comment Index PSDMask# p# p# p# p# -------+--------+----+---------+-----+-----+--------------- 1 1 3 2,6,10,11 20 20 default profile 2 13 5 0 20 20 3 1 1 0 20 20 4 16 0 0 100 100 5 16 0 0 70 50 6 6 0 0 50 10 7 17 0 0 30 30 8 8 0 0 30 5 9 4 0 0 25 25 10 4 0 0 15 15 11 23 0 0 10 10 12 23 0 0 5 5 13 16 0 2,5,9,11 100 100 14 16 0 2,5,9,11 70 50 15 6 0 2,6,10,11 50 10 16 17 0 2,5,9,11 30 30 17 8 0 2,6,10,11 30 5 18 4 0 2,6,10,11 25 25 19 4 0 2,6,10,11 15 15 20 23 0 2,5,9,11 10 10 21 23 0 2,5,9,11 5 5 22 30 0 0 200 50 -------+--------+----+---------+-----+-----+--------------- These default entries SHALL be created during agent initialization and MUST NOT be deleted. Entries following the first 22 can be dynamically created and deleted to provide custom administrative (configuration) profiles and automatic operating profiles. This table MUST be maintained in a persistent manner." REFERENCE Beili Standards Track [Page 70] RFC 5066 EFMCu Interfaces MIB November 2007 "[802.3ah] Annex 62B.3, 30.11.2.1.6" ::= { efmCuPme10P 1 } efmCuPme10PProfileEntry OBJECT-TYPE SYNTAX EfmCuPme10PProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to a single 10PASS-TS PME profile. Each profile contains a set of parameters, used either for configuration or representation of a 10PASS-TS PME. In case a particular profile is referenced via the efmCuPmeAdminProfile object (or efmCuAdminProfile if efmCuPmeAdminProfile is zero), it represents the desired parameters for the 10PassTS-O PME initialization. If a profile is referenced via an efmCuPmeOperProfile object, it represents the current operating parameters of the PME. Profiles may be created/deleted using the row creation/ deletion mechanism via efmCuPme10PProfileRowStatus. If an 'active' entry is referenced, the entry MUST remain 'active' until all references are removed. Default entries MUST NOT be removed." INDEX { efmCuPme10PProfileIndex } ::= { efmCuPme10PProfileTable 1 } EfmCuPme10PProfileEntry ::= SEQUENCE { efmCuPme10PProfileIndex EfmProfileIndex, efmCuPme10PProfileDescr SnmpAdminString, efmCuPme10PBandplanPSDMskProfile INTEGER, efmCuPme10PUPBOReferenceProfile INTEGER, efmCuPme10PBandNotchProfiles BITS, efmCuPme10PPayloadDRateProfile INTEGER, efmCuPme10PPayloadURateProfile INTEGER, efmCuPme10PProfileRowStatus RowStatus } efmCuPme10PProfileIndex OBJECT-TYPE SYNTAX EfmProfileIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "10PASS-TS PME profile index. This object is the unique index associated with this profile. Entries in this table are referenced via efmCuAdminProfile or efmCuPmeAdminProfile." Beili Standards Track [Page 71] RFC 5066 EFMCu Interfaces MIB November 2007 ::= { efmCuPme10PProfileEntry 1 } efmCuPme10PProfileDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A textual string containing information about a 10PASS-TS PME profile. The string may include information about data rate and spectral limitations of this particular profile." ::= { efmCuPme10PProfileEntry 2 } efmCuPme10PBandplanPSDMskProfile OBJECT-TYPE SYNTAX INTEGER { profile1(1), profile2(2), profile3(3), profile4(4), profile5(5), profile6(6), profile7(7), profile8(8), profile9(9), profile10(10), profile11(11), profile12(12), profile13(13), profile14(14), profile15(15), profile16(16), profile17(17), profile18(18), profile19(19), profile20(20), profile21(21), profile22(22), profile23(23), profile24(24), profile25(25), profile26(26), profile27(27), profile28(28), profile29(29), profile30(30) } MAX-ACCESS read-create STATUS current DESCRIPTION Beili Standards Track [Page 72] RFC 5066 EFMCu Interfaces MIB November 2007 "The 10PASS-TS PME Bandplan and PSD Mask Profile, as specified in 802.3ah Annex 62A, table 62A-1. Possible values are: --------------+------------------------+------------+-------- Profile Name PSD Mask Bands G.993.1 0/1/2/3/4/5 Bandplan --------------+------------------------+------------+-------- profile1(1) T1.424 FTTCab.M1 x/D/U/D/U A profile2(2) T1.424 FTTEx.M1 x/D/U/D/U A profile3(3) T1.424 FTTCab.M2 x/D/U/D/U A profile4(4) T1.424 FTTEx.M2 x/D/U/D/U A profile5(5) T1.424 FTTCab.M1 D/D/U/D/U A profile6(6) T1.424 FTTEx.M1 D/D/U/D/U A profile7(7) T1.424 FTTCab.M2 D/D/U/D/U A profile8(8) T1.424 FTTEx.M2 D/D/U/D/U A profile9(9) T1.424 FTTCab.M1 U/D/U/D/x A profile10(10) T1.424 FTTEx.M1 U/D/U/D/x A profile11(11) T1.424 FTTCab.M2 U/D/U/D/x A profile12(12) T1.424 FTTEx.M2 U/D/U/D/x A profile13(13) TS 101 270-1 Pcab.M1.A x/D/U/D/U B profile14(14) TS 101 270-1 Pcab.M1.B x/D/U/D/U B profile15(15) TS 101 270-1 Pex.P1.M1 x/D/U/D/U B profile16(16) TS 101 270-1 Pex.P2.M1 x/D/U/D/U B profile17(17) TS 101 270-1 Pcab.M2 x/D/U/D/U B profile18(18) TS 101 270-1 Pex.P1.M2 x/D/U/D/U B profile19(19) TS 101 270-1 Pex.P2.M2 x/D/U/D/U B profile20(20) TS 101 270-1 Pcab.M1.A U/D/U/D/x B profile21(21) TS 101 270-1 Pcab.M1.B U/D/U/D/x B profile22(22) TS 101 270-1 Pex.P1.M1 U/D/U/D/x B profile23(23) TS 101 270-1 Pex.P2.M1 U/D/U/D/x B profile24(24) TS 101 270-1 Pcab.M2 U/D/U/D/x B profile25(25) TS 101 270-1 Pex.P1.M2 U/D/U/D/x B profile26(26) TS 101 270-1 Pex.P2.M2 U/D/U/D/x B profile27(27) G.993.1 F.1.2.1 x/D/U/D/U Annex F profile28(28) G.993.1 F.1.2.2 x/D/U/D/U Annex F profile29(29) G.993.1 F.1.2.3 x/D/U/D/U Annex F profile30(30) T1.424 FTTCab.M1 (ext.) x/D/U/D/U/D Annex A --------------+------------------------+------------+-------- " REFERENCE "[802.3ah] Annex 62A" ::= { efmCuPme10PProfileEntry 3 } efmCuPme10PUPBOReferenceProfile OBJECT-TYPE SYNTAX INTEGER { profile0(0), profile1(1), profile2(2), profile3(3), Beili Standards Track [Page 73] RFC 5066 EFMCu Interfaces MIB November 2007 profile4(4), profile5(5), profile6(6), profile7(7), profile8(8), profile9(9) } MAX-ACCESS read-create STATUS current DESCRIPTION "The 10PASS-TS PME Upstream Power Back-Off (UPBO) Reference PSD Profile, as specified in 802.3 Annex 62A, table 62A-3. Possible values are: ------------+----------------------------- Profile Name Reference PSD ------------+----------------------------- profile0(0) no profile profile1(1) T1.424 Noise A M1 profile2(2) T1.424 Noise A M2 profile3(3) T1.424 Noise F M1 profile4(4) T1.424 Noise F M2 profile5(5) TS 101 270-1 Noise A&B profile6(6) TS 101 270-1 Noise C profile7(7) TS 101 270-1 Noise D profile8(8) TS 101 270-1 Noise E profile9(9) TS 101 270-1 Noise F ------------+----------------------------- " REFERENCE "[802.3ah] Annex 62A.3.5" ::= { efmCuPme10PProfileEntry 4 } efmCuPme10PBandNotchProfiles OBJECT-TYPE SYNTAX BITS { profile0(0), profile1(1), profile2(2), profile3(3), profile4(4), profile5(5), profile6(6), profile7(7), profile8(8), profile9(9), profile10(10), profile11(11) } MAX-ACCESS read-create Beili Standards Track [Page 74] RFC 5066 EFMCu Interfaces MIB November 2007 STATUS current DESCRIPTION "The 10PASS-TS PME Egress Control Band Notch Profile bitmap, as specified in 802.3 Annex 62A, table 62A-4. Possible values are: --------------+--------+------+------------+------+------ Profile Name G.991.3 T1.424 TS 101 270-1 StartF EndF table table table (MHz) (MHz) --------------+--------+------+------------+------+------ profile0(0) no profile profile1(1) F-5 #01 - - 1.810 1.825 profile2(2) 6-2 15-1 17 1.810 2.000 profile3(3) F-5 #02 - - 1.907 1.912 profile4(4) F-5 #03 - - 3.500 3.575 profile5(5) 6-2 - 17 3.500 3.800 profile6(6) - 15-1 - 3.500 4.000 profile7(7) F-5 #04 - - 3.747 3.754 profile8(8) F-5 #05 - - 3.791 3.805 profile9(9) 6-2 - 17 7.000 7.100 profile10(10) F-5 #06 15-1 - 7.000 7.300 profile11(11) 6-2 15-1 1 10.100 10.150 --------------+--------+------+------------+------+------ Any combination of profiles can be specified by ORing individual profiles, for example, a value of 0x2230 selects profiles 2, 6, 10, and 11." REFERENCE "[802.3ah] Annex 62A.3.5" ::= { efmCuPme10PProfileEntry 5 } efmCuPme10PPayloadDRateProfile OBJECT-TYPE SYNTAX INTEGER { profile5(5), profile10(10), profile15(15), profile20(20), profile25(25), profile30(30), profile50(50), profile70(70), profile100(100), profile140(140), profile200(200) } MAX-ACCESS read-create STATUS current DESCRIPTION "The 10PASS-TS PME Downstream Payload Rate Profile, as Beili Standards Track [Page 75] RFC 5066 EFMCu Interfaces MIB November 2007 specified in 802.3 Annex 62A. Possible values are: profile5(5) - 2.5 Mbps profile10(10) - 5 Mbps profile15(15) - 7.5 Mbps profile20(20) - 10 Mbps profile25(25) - 12.5 Mbps profile30(30) - 15 Mbps profile50(50) - 25 Mbps profile70(70) - 35 Mbps profile100(100) - 50 Mbps profile140(140) - 70 Mbps profile200(200) - 100 Mbps Each value represents a target for the PME's Downstream Payload Bitrate as seen at the MII. If the payload rate of the selected profile cannot be achieved based on the loop environment, bandplan, and PSD mask, the PME initialization SHALL fail." REFERENCE "[802.3ah] Annex 62A.3.6" ::= { efmCuPme10PProfileEntry 6 } efmCuPme10PPayloadURateProfile OBJECT-TYPE SYNTAX INTEGER { profile5(5), profile10(10), profile15(15), profile20(20), profile25(25), profile30(30), profile50(50), profile70(70), profile100(100) } MAX-ACCESS read-create STATUS current DESCRIPTION "The 10PASS-TS PME Upstream Payload Rate Profile, as specified in 802.3 Annex 62A. Possible values are: profile5(5) - 2.5 Mbps profile10(10) - 5 Mbps profile15(15) - 7.5 Mbps profile20(20) - 10 Mbps profile25(25) - 12.5 Mbps profile30(30) - 15 Mbps profile50(50) - 25 Mbps profile70(70) - 35 Mbps profile100(100) - 50 Mbps Beili Standards Track [Page 76] RFC 5066 EFMCu Interfaces MIB November 2007 Each value represents a target for the PME's Upstream Payload Bitrate as seen at the MII. If the payload rate of the selected profile cannot be achieved based on the loop environment, bandplan, and PSD mask, the PME initialization SHALL fail." REFERENCE "[802.3ah] Annex 62A.3.6" ::= { efmCuPme10PProfileEntry 7 } efmCuPme10PProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls creation, modification, or deletion of the associated entry in efmCuPme10PProfileTable per the semantics of RowStatus. If an active entry is referenced via efmCuAdminProfile or efmCuPmeAdminProfile, the entry MUST remain 'active' until all references are removed. An 'active' entry SHALL NOT be modified. In order to modify an existing entry, it MUST be taken out of service (by setting this object to 'notInService'), modified, and set 'active' again." ::= { efmCuPme10PProfileEntry 8 } efmCuPme10PStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPme10PStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides status information of EFMCu 10PASS-TS PMEs (modems). This table contains live data from the equipment. As such, it is NOT persistent." ::= { efmCuPme10P 2 } efmCuPme10PStatusEntry OBJECT-TYPE SYNTAX EfmCuPme10PStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the EFMCu 10PASS-TS PME Status table." INDEX { ifIndex } Beili Standards Track [Page 77] RFC 5066 EFMCu Interfaces MIB November 2007 ::= { efmCuPme10PStatusTable 1 } EfmCuPme10PStatusEntry ::= SEQUENCE { efmCuPme10PFECCorrectedBlocks Counter32, efmCuPme10PFECUncorrectedBlocks Counter32 } efmCuPme10PFECCorrectedBlocks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received and corrected Forward Error Correction (FEC) codewords in this 10PASS-TS PME. This object maps to the aPMEFECCorrectedBlocks attribute in Clause 30. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this object maps to the 10P FEC correctable errors register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 45.2.1.22, 30.11.2.1.8" ::= { efmCuPme10PStatusEntry 1 } efmCuPme10PFECUncorrectedBlocks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received uncorrectable FEC codewords in this 10PASS-TS PME. This object maps to the aPMEFECUncorrectableBlocks attribute in Clause 30. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this object maps to the 10P FEC uncorrectable errors register. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times Beili Standards Track [Page 78] RFC 5066 EFMCu Interfaces MIB November 2007 as indicated by the value of ifCounterDiscontinuityTime, defined in IF-MIB." REFERENCE "[802.3ah] 45.2.1.23, 30.11.2.1.9" ::= { efmCuPme10PStatusEntry 2 } -- -- Conformance Statements -- efmCuGroups OBJECT IDENTIFIER ::= { efmCuConformance 1 } efmCuCompliances OBJECT IDENTIFIER ::= { efmCuConformance 2 } -- Object Groups efmCuBasicGroup OBJECT-GROUP OBJECTS { efmCuPAFSupported, efmCuAdminProfile, efmCuTargetDataRate, efmCuTargetSnrMgn, efmCuAdaptiveSpectra, efmCuPortSide, efmCuFltStatus } STATUS current DESCRIPTION "A collection of objects representing management information common for all types of EFMCu ports." ::= { efmCuGroups 1 } efmCuPAFGroup OBJECT-GROUP OBJECTS { efmCuPeerPAFSupported, efmCuPAFCapacity, efmCuPeerPAFCapacity, efmCuPAFAdminState, efmCuPAFDiscoveryCode, efmCuPAFRemoteDiscoveryCode, efmCuNumPMEs } STATUS current DESCRIPTION "A collection of objects supporting OPTIONAL PME Aggregation Function (PAF) and PAF discovery in EFMCu ports." ::= { efmCuGroups 2 } Beili Standards Track [Page 79] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPAFErrorsGroup OBJECT-GROUP OBJECTS { efmCuPAFInErrors, efmCuPAFInSmallFragments, efmCuPAFInLargeFragments, efmCuPAFInBadFragments, efmCuPAFInLostFragments, efmCuPAFInLostStarts, efmCuPAFInLostEnds, efmCuPAFInOverflows } STATUS current DESCRIPTION "A collection of objects supporting OPTIONAL error counters of PAF on EFMCu ports." ::= { efmCuGroups 3 } efmCuPmeGroup OBJECT-GROUP OBJECTS { efmCuPmeAdminProfile, efmCuPmeOperStatus, efmCuPmeFltStatus, efmCuPmeSubTypesSupported, efmCuPmeAdminSubType, efmCuPmeOperSubType, efmCuPAFRemoteDiscoveryCode, efmCuPmeOperProfile, efmCuPmeSnrMgn, efmCuPmePeerSnrMgn, efmCuPmeLineAtn, efmCuPmePeerLineAtn, efmCuPmeEquivalentLength, efmCuPmeTCCodingErrors, efmCuPmeTCCrcErrors, efmCuPmeThreshLineAtn, efmCuPmeThreshSnrMgn } STATUS current DESCRIPTION "A collection of objects providing information about a 2BASE-TL/10PASS-TS PME." ::= { efmCuGroups 4 } efmCuAlarmConfGroup OBJECT-GROUP OBJECTS { efmCuThreshLowRate, efmCuLowRateCrossingEnable, efmCuPmeThreshLineAtn, Beili Standards Track [Page 80] RFC 5066 EFMCu Interfaces MIB November 2007 efmCuPmeLineAtnCrossingEnable, efmCuPmeThreshSnrMgn, efmCuPmeSnrMgnCrossingEnable, efmCuPmeDeviceFaultEnable, efmCuPmeConfigInitFailEnable, efmCuPmeProtocolInitFailEnable } STATUS current DESCRIPTION "A collection of objects supporting configuration of alarm thresholds and notifications in EFMCu ports." ::= { efmCuGroups 5 } efmCuNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { efmCuLowRateCrossing, efmCuPmeLineAtnCrossing, efmCuPmeSnrMgnCrossing, efmCuPmeDeviceFault, efmCuPmeConfigInitFailure, efmCuPmeProtocolInitFailure } STATUS current DESCRIPTION "This group supports notifications of significant conditions associated with EFMCu ports." ::= { efmCuGroups 6 } efmCuPme2BProfileGroup OBJECT-GROUP OBJECTS { efmCuPme2BProfileDescr, efmCuPme2BRegion, efmCuPme2BsMode, efmCuPme2BMinDataRate, efmCuPme2BMaxDataRate, efmCuPme2BPower, efmCuPme2BConstellation, efmCuPme2BProfileRowStatus, efmCuPme2BsModeDescr, efmCuPme2BsModeRowStatus, efmCuPme2BEquivalentLength, efmCuPme2BMaxDataRatePam16, efmCuPme2BMaxDataRatePam32, efmCuPme2BReachRateRowStatus } STATUS current DESCRIPTION "A collection of objects that constitute a configuration Beili Standards Track [Page 81] RFC 5066 EFMCu Interfaces MIB November 2007 profile for configuration of 2BASE-TL ports." ::= { efmCuGroups 7} efmCuPme10PProfileGroup OBJECT-GROUP OBJECTS { efmCuPme10PProfileDescr, efmCuPme10PBandplanPSDMskProfile, efmCuPme10PUPBOReferenceProfile, efmCuPme10PBandNotchProfiles, efmCuPme10PPayloadDRateProfile, efmCuPme10PPayloadURateProfile, efmCuPme10PProfileRowStatus } STATUS current DESCRIPTION "A collection of objects that constitute a configuration profile for configuration of 10PASS-TS ports." ::= { efmCuGroups 8 } efmCuPme10PStatusGroup OBJECT-GROUP OBJECTS { efmCuPme10PFECCorrectedBlocks, efmCuPme10PFECUncorrectedBlocks } STATUS current DESCRIPTION "A collection of objects providing status information specific to 10PASS-TS PMEs." ::= { efmCuGroups 9 } -- Compliance Statements efmCuCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for 2BASE-TL/10PASS-TS interfaces. Compliance with the following external compliance statements is REQUIRED: MIB Module Compliance Statement ---------- -------------------- IF-MIB ifCompliance3 EtherLike-MIB dot3Compliance2 MAU-MIB mauModIfCompl3 Compliance with the following external compliance statements is OPTIONAL for implementations supporting PME Aggregation Function (PAF) with flexible cross-connect between the PCS Beili Standards Track [Page 82] RFC 5066 EFMCu Interfaces MIB November 2007 and PME ports: MIB Module Compliance Statement ---------- -------------------- IF-INVERTED-STACK-MIB ifInvCompliance IF-CAP-STACK-MIB ifCapStackCompliance" MODULE -- this module MANDATORY-GROUPS { efmCuBasicGroup, efmCuPmeGroup, efmCuAlarmConfGroup, efmCuNotificationGroup } GROUP efmCuPme2BProfileGroup DESCRIPTION "Support for this group is only required for implementations supporting 2BASE-TL PHY." GROUP efmCuPme10PProfileGroup DESCRIPTION "Support for this group is only required for implementations supporting 10PASS-TS PHY." GROUP efmCuPAFGroup DESCRIPTION "Support for this group is only required for implementations supporting PME Aggregation Function (PAF)." GROUP efmCuPAFErrorsGroup DESCRIPTION "Support for this group is OPTIONAL for implementations supporting PME Aggregation Function (PAF)." GROUP efmCuPme10PStatusGroup DESCRIPTION "Support for this group is OPTIONAL for implementations supporting 10PASS-TS PHY." OBJECT efmCuPmeSubTypesSupported SYNTAX BITS { ieee2BaseTLO(0), ieee2BaseTLR(1), ieee10PassTSO(2), ieee10PassTSR(3) } DESCRIPTION Beili Standards Track [Page 83] RFC 5066 EFMCu Interfaces MIB November 2007 "Support for all subtypes is not required. However, at least one value SHALL be supported." OBJECT efmCuPmeAdminSubType MIN-ACCESS read-only DESCRIPTION "Write access is not required (needed only for PMEs supporting more than a single subtype, e.g., ieee2BaseTLO and ieee2BaseTLR or ieee10PassTSO and ieee10PassTSR)." OBJECT efmCuTargetSnrMgn MIN-ACCESS read-only DESCRIPTION "Write access is OPTIONAL. For PHYs without write access, the target SNR margin SHALL be fixed at 5dB for 2BASE-TL and 6dB for 10PASS-TS." OBJECT efmCuAdaptiveSpectra MIN-ACCESS read-only DESCRIPTION "Write access is OPTIONAL. For PHYs without write access, the default value SHOULD be false." ::= { efmCuCompliances 1 } END 7. Security Considerations There is a number of managed objects defined in the EFM-CU-MIB module that have a MAX-ACCESS clause of read-write or read-create. Most objects are writeable only when the link is Down. Writing to these objects can have potentially disruptive effects on network operation, for example: o Changing of efmCuPmeAdminSubType may lead to a potential locking of the link, as peer PMEs of the same subtype cannot exchange handshake messages. o Changing of efmCuPAFAdminState to enabled may lead to a potential locking of the link, if the peer PHY does not support PAF. o Changing of efmCuPAFDiscoveryCode, before the discovery operation, may lead to a wrongful discovery, for example, when two -O ports are connected to the same multi-PME -R port and both -O ports have the same Discovery register value. Beili Standards Track [Page 84] RFC 5066 EFMCu Interfaces MIB November 2007 o Changing PCS or PME configuration parameters (e.g., profile of a PCS or PME via efmCuAdminProfile or efmCuPmeAdminProfile) may lead to anything from link quality and rate degradation to a complete link initialization failure, as ability of an EFMCu port to support a particular configuration depends on the copper environment. o Activation of a PME can cause a severe degradation of service for another EFMCu PHY, whose PME(s) may be affected by the cross-talk from the newly activated PME. o Removal of a PME from an operationally 'up' EFMCu port, aggregating several PMEs, may cause port's rate degradation. The user of the EFM-CU-MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in the EFM-CU-MIB module (i.e., those with MAX- ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the performance of network interfaces and can reveal some aspects of their configuration. In particular, since EFMCu can be carried over Unshielded Twisted Pair (UTP) voice-grade copper in a bundle with other pairs belonging to another operator/customer, it is theoretically possible to eavesdrop to an EFMCu transmission simply by "listening" to a cross-talk from the EFMCu pairs, especially if the parameters of the EFMCu link in question are known. In such environments, it is important to control also GET and NOTIFY access to these objects and possibly even to encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an Beili Standards Track [Page 85] RFC 5066 EFMCu Interfaces MIB November 2007 instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations Object identifiers for the efmCuMIB MODULE-IDENTITY and ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 9. Acknowledgments This document was produced by the [HUBMIB] working group, whose efforts were greatly advanced by the contributions of the following people (in alphabetical order): Udi Ashkenazi (Actelis) Mike Heard Alfred Hoenes (TR-Sys) Marina Popilov (Actelis) Mathias Riess (Infineon) Dan Romascanu (Avaya) Matt Squire (Hatteras) Bert Wijnen (Alcatel) 10. References 10.1. Normative References [802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2005, December 2005. Beili Standards Track [Page 86] RFC 5066 EFMCu Interfaces MIB November 2007 [802.3ah] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks", IEEE Std 802.3ah-2004, September 2004. [G.991.2] ITU-T, "Single-pair High-speed Digital Subscriber Line (SHDSL) transceivers", ITU-T Recommendation G.991.2, December 2003, . [G.993.1] ITU-T, "Very High speed Digital Subscriber Line transceivers", ITU-T Recommendation G.993.1, June 2004, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Beili Standards Track [Page 87] RFC 5066 EFMCu Interfaces MIB November 2007 [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003. [RFC4836] Beili, E., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 4836, April 2007. [T1.424] ANSI, "Interface Between Networks and Customer Installation Very-high-bit-rate Digital Subscriber Lines (VDSL) Metallic Interface (DMT Based)", American National Standard T1.424-2004, June 2004. [TS 101 270-1] ETSI, "Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements", Technical Specification TS 101 270-1, October 2005. 10.2. Informative References [ANFP] Network Interoperability Consultative Committee (NICC), "Specification of the Access Network Frequency Plan (ANFP) applicable to transmission systems used on the BT Access Network", NICC Document ND1602:2005/08, August 2005. [HUBMIB] IETF, "Ethernet Interfaces and Hub MIB (hubmib) Charter", . [IANAifType-MIB] Internet Assigned Numbers Authority (IANA), "IANAifType Textual Convention definition", . [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4070] Dodge, M. and B. Ray, "Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding", RFC 4070, May 2005. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. Beili Standards Track [Page 88] RFC 5066 EFMCu Interfaces MIB November 2007 [RFC4319] Sikes, C., Ray, B., and R. Abbi, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", RFC 4319, December 2005. [RFC4837] Khermosh, L., "Managed Objects of Ethernet Passive Optical Networks (EPON)", RFC 4837, July 2007. [RFC4878] Squire, M., "Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces", RFC 4878, June 2007. Author's Address Edward Beili Actelis Networks Bazel 25 Petach-Tikva Israel Phone: +972-3-924-3491 EMail: edward.beili@actelis.com Beili Standards Track [Page 89] RFC 5066 EFMCu Interfaces MIB November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Beili Standards Track [Page 90] snmp-mibs-downloader-1.1/mibrfcs/rfc5097.txt0000644000000000000000000013746011402176072015602 0ustar Network Working Group G. Renker Request for Comments: 5097 G. Fairhurst Category: Standards Track University of Aberdeen January 2008 MIB for the UDP-Lite Protocol 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. Abstract This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. Table of Contents 1. Introduction ....................................................2 1.1. Relationship to the UDP-MIB ................................2 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB .........4 1.3. Interpretation of the MIB Variables ........................5 1.4. Conventions ................................................8 2. The Internet-Standard Management Framework ......................8 3. Definitions .....................................................8 4. Security Considerations ........................................19 5. IANA Considerations ............................................20 6. Acknowledgments ................................................20 7. References .....................................................20 7.1. Normative References ......................................20 7.2. Informative References ....................................21 Renker & Fairhurst Standards Track [Page 1] RFC 5097 MIB for the UDP-Lite Protocol January 2008 1. Introduction The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also known as UDPLite) is an IETF standards-track transport protocol. The operation of UDP-Lite is similar to the User Datagram Protocol (UDP) [RFC768], but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. This is achieved by changing the semantics of the UDP Length field to that of a Checksum Coverage field. If this feature is not used, UDP-Lite is semantically identical to UDP. The interface of UDP-Lite differs from that of UDP by the addition of a single option, which communicates a length value. At the sender this specifies the intended datagram checksum coverage; at the receiver it signifies a minimum coverage threshold for incoming datagrams. This length value may also be modified during the lifetime of a connection. UDP-Lite does not provide mechanisms to negotiate the checksum coverage between the sender and receiver. Where required, this needs to be communicated by another protocol. The Datagram Congestion Control Protocol (DCCP) [RFC4340] for instance includes a capability to negotiate checksum coverage values. This document defines a set of runtime statistics (variables) that facilitate network management/monitoring as well as unified comparisons between different protocol implementations and operating environments. To provide a common interface for users and implementors of UDP-Lite modules, the definitions of these runtime statistics are provided as a MIB module using the SMIv2 format [RFC2578]. 1.1. Relationship to the UDP-MIB The similarities between UDP and UDP-Lite suggest that the MIB module for UDP-Lite should resemble that of UDP [RFC4113], with extensions corresponding to the additional capabilities of UDP-Lite. The UDP- Lite MIB module is placed beneath the mib-2 subtree, adhering to the familiar structure of the UDP-MIB module to ease integration. In particular, these well-known basic counters are supported: o InDatagrams o NoPorts o InErrors o OutDatagrams Renker & Fairhurst Standards Track [Page 2] RFC 5097 MIB for the UDP-Lite Protocol January 2008 The following read-only variables have been added to the basic structure used in the UDP-MIB module: InPartialCov: The number of received datagrams, with a valid format and checksum, whose checksum coverage is strictly less than the datagram length. InBadChecksum: The number of received datagrams with an invalid checksum (i.e., where the receiver-recalculated UDP-Lite checksum does not match that in the Checksum field). Unlike NoPorts, this error type also counts as InErrors. OutPartialCov: The number of sent datagrams with a valid format and checksum whose checksum coverage is strictly less than the datagram length. All non-error counters used in this document are 64-bit counters. This is a departure from UDP, which traditionally used 32-bit counters and mandates 64-bit counters only on fast networks [RFC4113]. This choice is justified by the fact that UDP-Lite is a more recent protocol, and that network speeds continue to grow. Another difference from the UDP MIB module is that the UDP-Lite MIB module does not support an IPv4-only listener table. This feature was present only for compatibility reasons and is superseded by the more informative endpoint table. Two columnar objects have been added to this table: udpliteEndpointMinCoverage: The minimum acceptable receiver checksum coverage length [RFC3828]. This value may be manipulated by the application attached to the receiving endpoint. udpliteEndpointViolCoverage: This object is optional and counts the number of valid datagrams with a checksum coverage value less than the corresponding value of udpliteEndpointMinCoverage. Although being otherwise valid, such datagrams are discarded rather than passed to the application. This object thus serves to separate cases of violated coverage from other InErrors. The second entry is not required to manage the transport protocol and hence is not mandatory. It may be implemented to assist in debugging application design and configuration. The UDP-Lite MIB module also provides a discontinuity object to help determine whether one or more of its counters experienced a discontinuity event. This is an event, other than re-initialising the management system, that invalidates the management entity's understanding of the counter values. Renker & Fairhurst Standards Track [Page 3] RFC 5097 MIB for the UDP-Lite Protocol January 2008 For example, if UDP-Lite is implemented as a loadable operating system module, a module load or unload would produce a discontinuity. By querying the value of udpliteStatsDiscontinuityTime, a management entity can determine whether or not a discontinuity event has occurred. 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB The UDP-Lite endpoint table contains one columnar object, udpliteEndpointProcess, reporting a unique value that identifies a distinct piece of software associated with this endpoint. (When more than one piece of software is associated with this endpoint, a representative is chosen, so that consecutive queries consistently refer to the same identifier. The reported value is then consistent, as long as the representative piece of software is running and still associated with the endpoint.) The value of udpliteEndpointProcess is reported as an Unsigned32, and it shares with the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] and the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287] the requirement that, wherever possible, this should be the native and unique identification number employed by the system. If the SYSAPPL-MIB module is available, the value of udpliteEndpointProcess should correspond to the appropriate value of sysApplElmtRunIndex. If not available, an alternative should be used (e.g., the hrSWRunIndex of the HOST-RESOURCES-MIB module). Renker & Fairhurst Standards Track [Page 4] RFC 5097 MIB for the UDP-Lite Protocol January 2008 1.3. Interpretation of the MIB Variables Figure 1 shows an informal survey of the packet processing path, with reference to counter names in parentheses. Received UDP-Lite Datagrams | | +- Full Coverage ---------------------+-> Deliver | | | +- Valid Header--+ +- >= Rec. Coverage --+ | (InDatagrams) | | | +- Partial -----+ | (InPartialCov) | | +- < Rec. Coverage --+ | (EndpointViolCoverage) | | | | | +- Header Error ---+ | | | | +- Checksum Error -+-----------------------------------+-> Discard | (InBadChecksum) (InErrors) | +- Port Error -------------------------------------------> Discard (NoPorts) Figure 1: UDP-Lite Input Processing Path A platform-independent test of the UDP-Lite implementations in two connected end hosts may be performed as follows. On the sending side, OutDatagrams and OutPartialCov are observed. The ratio OutPartialCov/OutDatagrams describes the fraction (between 0 and 1) of datagrams using partial checksum coverage. On the receiving side, InDatagrams, InPartialCov, and InErrors are monitored. If datagrams are received from the given sender, InErrors is close to zero, and InPartialCov is zero, no partial coverage is employed. If no datagrams are received and InErrors increases proportionally with the sending rate, a configuration error is likely (a wrong value of receiver minimum checksum coverage). The InBadChecksum counter reflects errors that may persist following end-host processing, router processing, or link processing (this includes illegal coverage values as defined in [RFC3828], since checksum and checksum coverage are mutually interdependent). In particular, InBadChecksum can serve as an indicator of the residual Renker & Fairhurst Standards Track [Page 5] RFC 5097 MIB for the UDP-Lite Protocol January 2008 link bit error rate: on links with higher bit error rates, a lower value of the checksum coverage may help to reduce the values of both InErrors and InBadChecksum. By observing these values and adapting the configuration, a setting may then be found that is more adapted to the specific type of link, and the type of payload. In particular, a reduction in the number of discarded datagrams (InErrors), may indicate an improved performance. The above statistics are elementary and can be used to derive the following information: o The total number of incoming datagrams is InDatagrams + InErrors + NoPorts. o The number of InErrors that were discarded due to problems other than a bad checksum is InErrors - InBadChecksum. o The number of InDatagrams that have full coverage is InDatagrams - InPartialCov. o The number of OutDatagrams that have full coverage is OutDatagrams - OutPartialCov. Renker & Fairhurst Standards Track [Page 6] RFC 5097 MIB for the UDP-Lite Protocol January 2008 The following Case diagram [CASE] summarises the relationships between the counters on the input processing path. Transport Layer Interface ------------------------------------------------------------- /\ || ----------------------------- InDatagrams || ^ || | || | ||----------------------> InPartialCov || | || | || v || EndpointViolCoverage || | NoPorts <--------|| | || | ||------> InBadChecksum ------>| || | || | || v ||------------------------> InErrors || || ------------------------------------------------------------- Network Layer Interface Figure 2: Counters for Received UDP-Lite Datagrams A configuration error may occur when a sender chooses a coverage value for the datagrams that it sends that is less than the minimum coverage configured by the intended recipient. The minimum coverage is set on a per-session basis by the application associated with the listening endpoint, and its current value is recorded in the udpliteEndpointTable. Reception of valid datagrams with a checksum coverage value less than this threshold results in dropping the datagram [RFC3828] and incrementing InErrors. To improve debugging of such (misconfigured) cases, an implementer may choose to support the optional udpliteEndpointViolCoverage entry in the endpoint table (Section 1.1) that specifically counts datagrams falling in this category. Without this feature, failure due to misconfiguration can not be distinguished from datagram processing failure. Renker & Fairhurst Standards Track [Page 7] RFC 5097 MIB for the UDP-Lite Protocol January 2008 1.4. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Definitions UDPLITE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32, Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578] TimeStamp FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] InetAddress, InetAddressType, InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001] udpliteMIB MODULE-IDENTITY LAST-UPDATED "200712180000Z" -- 18 December 2007 ORGANIZATION "IETF TSV Working Group (TSVWG)" CONTACT-INFO "IETF TSV Working Group http://www.ietf.org/html.charters/tsvwg-charter.html Mailing List: tsvwg@ietf.org Renker & Fairhurst Standards Track [Page 8] RFC 5097 MIB for the UDP-Lite Protocol January 2008 Gerrit Renker, Godred Fairhurst Electronics Research Group School of Engineering, University of Aberdeen Fraser Noble Building, Aberdeen AB24 3UE, UK" DESCRIPTION "The MIB module for managing UDP-Lite implementations. Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5097; see the RFC itself for full legal notices." REVISION "200712180000Z" -- 18 December 2007 DESCRIPTION "Initial SMIv2 revision, based on the format of the UDP MIB module (RFC 4113) and published as RFC 5097." ::= { mib-2 170 } udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 } udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of UDP-Lite datagrams that were delivered to UDP-Lite users. Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." ::= { udplite 1 } udpliteInPartialCov OBJECT-TYPE -- new in UDP-Lite SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of UDP-Lite datagrams that were delivered to UDP-Lite users (applications) and whose checksum coverage was strictly less than the datagram length. Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." ::= { udplite 2 } Renker & Fairhurst Standards Track [Page 9] RFC 5097 MIB for the UDP-Lite Protocol January 2008 udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of received UDP-Lite datagrams for which there was no listener at the destination port. Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." ::= { udplite 3 } udpliteInErrors OBJECT-TYPE -- as in UDP-MIB SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received UDP-Lite datagrams that could not be delivered for reasons other than the lack of an application at the destination port. Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." ::= { udplite 4 } udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received UDP-Lite datagrams whose checksum could not be validated. This includes illegal checksum coverage values, as their use would lead to incorrect checksums. Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." REFERENCE "RFC 3828, section 3.1" ::= { udplite 5 } udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION Renker & Fairhurst Standards Track [Page 10] RFC 5097 MIB for the UDP-Lite Protocol January 2008 "The total number of UDP-Lite datagrams sent from this entity. Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." ::= { udplite 6 } udpliteOutPartialCov OBJECT-TYPE -- new in UDP-Lite SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of udpliteOutDatagrams whose checksum coverage was strictly less than the datagram length. Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." ::= { udplite 7 } udpliteEndpointTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpLiteEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about this entity's UDP-Lite endpoints on which a local application is currently accepting or sending datagrams. The address type in this table represents the address type used for the communication, irrespective of the higher-layer abstraction. For example, an application using IPv6 'sockets' to communicate via IPv4 between ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use InetAddressType ipv4(1). Like the udpTable in RFC 4113, this table also allows the representation of an application that completely specifies both local and remote addresses and ports. A listening application is represented in three possible ways: 1) An application that is willing to accept both IPv4 and IPv6 datagrams is represented by a udpliteEndpointLocalAddressType of unknown(0) and a udpliteEndpointLocalAddress of ''h (a zero-length Renker & Fairhurst Standards Track [Page 11] RFC 5097 MIB for the UDP-Lite Protocol January 2008 octet-string). 2) An application that is willing to accept only IPv4 or only IPv6 datagrams is represented by a udpliteEndpointLocalAddressType of the appropriate address type and a udpliteEndpointLocalAddress of '0.0.0.0' or '::' respectively. 3) An application that is listening for datagrams only for a specific IP address but from any remote system is represented by a udpliteEndpointLocalAddressType of the appropriate address type, with udpliteEndpointLocalAddress specifying the local address. In all cases where the remote address is a wildcard, the udpliteEndpointRemoteAddressType is unknown(0), the udpliteEndpointRemoteAddress is ''h (a zero-length octet-string), and the udpliteEndpointRemotePort is 0. If the operating system is demultiplexing UDP-Lite packets by remote address/port, or if the application has 'connected' the socket specifying a default remote address/port, the udpliteEndpointRemote* values should be used to reflect this." ::= { udplite 8 } udpliteEndpointEntry OBJECT-TYPE SYNTAX UdpLiteEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular current UDP-Lite endpoint. Implementers need to pay attention to the sizes of udpliteEndpointLocalAddress/RemoteAddress, as Object Identifiers (OIDs) of column instances in this table must have no more than 128 sub-identifiers in order to remain accessible with SNMPv1, SNMPv2c, and SNMPv3." INDEX { udpliteEndpointLocalAddressType, udpliteEndpointLocalAddress, udpliteEndpointLocalPort, udpliteEndpointRemoteAddressType, udpliteEndpointRemoteAddress, udpliteEndpointRemotePort, udpliteEndpointInstance } ::= { udpliteEndpointTable 1 } UdpLiteEndpointEntry ::= SEQUENCE { Renker & Fairhurst Standards Track [Page 12] RFC 5097 MIB for the UDP-Lite Protocol January 2008 udpliteEndpointLocalAddressType InetAddressType, udpliteEndpointLocalAddress InetAddress, udpliteEndpointLocalPort InetPortNumber, udpliteEndpointRemoteAddressType InetAddressType, udpliteEndpointRemoteAddress InetAddress, udpliteEndpointRemotePort InetPortNumber, udpliteEndpointInstance Unsigned32, udpliteEndpointProcess Unsigned32, udpliteEndpointMinCoverage Unsigned32, udpliteEndpointViolCoverage Counter32 } udpliteEndpointLocalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of udpliteEndpointLocalAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all local IP addresses are accepted." ::= { udpliteEndpointEntry 1 } udpliteEndpointLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local IP address for this UDP-Lite endpoint. The value of this object can be represented in three possible ways, depending on the characteristics of the listening application: 1. For an application that is willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding instance of the EndpointLocalAddressType object being unknown(0). 2. For an application that is willing to accept only IPv4 or only IPv6 datagrams, the value of this object must be '0.0.0.0' or '::', respectively, while the corresponding instance of the EndpointLocalAddressType object represents the appropriate address type. 3. For an application that is listening for data Renker & Fairhurst Standards Track [Page 13] RFC 5097 MIB for the UDP-Lite Protocol January 2008 destined only to a specific IP address, the value of this object is the specific IP address for which this node is receiving packets, with the corresponding instance of the EndpointLocalAddressType object representing the appropriate address type. As this object is used in the index for the udpliteEndpointTable, implementors should be careful not to create entries that would result in OIDs with more than 128 sub-identifiers; this is because of SNMP and SMI limitations." ::= { udpliteEndpointEntry 2 } udpliteEndpointLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local port number for this UDP-Lite endpoint." ::= { udpliteEndpointEntry 3 } udpliteEndpointRemoteAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of udpliteEndpointRemoteAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all remote IP addresses are accepted. Also, note that some combinations of udpliteEndpointLocalAdressType and udpliteEndpointRemoteAddressType are not supported. In particular, if the value of this object is not unknown(0), it is expected to always refer to the same IP version as udpliteEndpointLocalAddressType." ::= { udpliteEndpointEntry 4 } udpliteEndpointRemoteAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote IP address for this UDP-Lite endpoint. If datagrams from any remote system are to be accepted, this value is ''h (a zero-length octet-string). Otherwise, it has the type described by udpliteEndpointRemoteAddressType and is the address of Renker & Fairhurst Standards Track [Page 14] RFC 5097 MIB for the UDP-Lite Protocol January 2008 the remote system from which datagrams are to be accepted (or to which all datagrams will be sent). As this object is used in the index for the udpliteEndpointTable, implementors should be careful not to create entries that would result in OIDs with more than 128 sub-identifiers; this is because of SNMP and SMI limitations." ::= { udpliteEndpointEntry 5 } udpliteEndpointRemotePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The remote port number for this UDP-Lite endpoint. If datagrams from any remote system are to be accepted, this value is zero." ::= { udpliteEndpointEntry 6 } udpliteEndpointInstance OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The instance of this tuple. This object is used to distinguish among multiple processes 'connected' to the same UDP-Lite endpoint. For example, on a system implementing the BSD sockets interface, this would be used to support the SO_REUSEADDR and SO_REUSEPORT socket options." ::= { udpliteEndpointEntry 7 } udpliteEndpointProcess OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value corresponding to a piece of software running on this endpoint. If this endpoint is associated with more than one piece of software, the agent should choose one of these. As long as the representative piece of software is running and still associated with the endpoint, subsequent reads will consistently return the same value. The implementation may use any algorithm satisfying these constraints (e.g., choosing the entity Renker & Fairhurst Standards Track [Page 15] RFC 5097 MIB for the UDP-Lite Protocol January 2008 with the oldest start time). This identifier is platform-specific. Wherever possible, it should use the system's native, unique identification number as the value. If the SYSAPPL-MIB module is available, the value should be the same as sysApplElmtRunIndex. If not available, an alternative should be used (e.g., the hrSWRunIndex of the HOST-RESOURCES-MIB module). If it is not possible to uniquely identify the pieces of software associated with this endpoint, then the value zero should be used. (Note that zero is otherwise a valid value for sysApplElmtRunIndex.)" ::= { udpliteEndpointEntry 8 } udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum checksum coverage expected by this endpoint. A value of 0 indicates that only fully covered datagrams are accepted." REFERENCE "RFC 3828, section 3.1" ::= { udpliteEndpointEntry 9 } udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of datagrams received by this endpoint whose checksum coverage violated the minimum coverage threshold set for this connection (i.e., all valid datagrams whose checksum coverage was strictly smaller than the minimum, as defined in RFC 3828). Discontinuities in the value of this counter can occur at re-initialisation of the management system, and at other times as indicated by the value of udpliteStatsDiscontinuityTime." ::= { udpliteEndpointEntry 10 } Renker & Fairhurst Standards Track [Page 16] RFC 5097 MIB for the UDP-Lite Protocol January 2008 udpliteStatsDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent occasion at which one or more of the UDP-Lite counters suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialisation of the local management subsystem." ::= { udplite 9 } -- Conformance Information udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 } udpliteMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems that implement UDP-Lite. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which we have the following compliance requirements, expressed in OBJECT clause form in this description clause: -- OBJECT udpliteEndpointLocalAddressType -- SYNTAX InetAddressType { unknown(0), ipv4(1), -- ipv6(2), ipv4z(3), -- ipv6z(4) } -- DESCRIPTION -- Support for dns(16) is not required. -- OBJECT udpliteEndpointLocalAddress -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION -- Support is only required for zero-length -- octet-strings, and for scoped and unscoped -- IPv4 and IPv6 addresses. -- OBJECT udpliteEndpointRemoteAddressType -- SYNTAX InetAddressType { unknown(0), ipv4(1), -- ipv6(2), ipv4z(3), -- ipv6z(4) } -- DESCRIPTION -- Support for dns(16) is not required. -- OBJECT udpliteEndpointRemoteAddress Renker & Fairhurst Standards Track [Page 17] RFC 5097 MIB for the UDP-Lite Protocol January 2008 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION -- Support is only required for zero-length -- octet-strings, and for scoped and unscoped -- IPv4 and IPv6 addresses. " MODULE -- this module MANDATORY-GROUPS { udpliteBaseGroup, udplitePartialCsumGroup, udpliteEndpointGroup } GROUP udpliteAppGroup DESCRIPTION "This group is optional and provides supplementary information about the effectiveness of using minimum checksum coverage thresholds on endpoints." ::= { udpliteMIBConformance 1 } udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 } udpliteBaseGroup OBJECT-GROUP -- as in UDP OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors, udpliteOutDatagrams, udpliteStatsDiscontinuityTime } STATUS current DESCRIPTION "The group of objects providing for counters of basic UDP-like statistics." ::= { udpliteMIBGroups 1 } udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite OBJECTS { udpliteInPartialCov, udpliteInBadChecksum, udpliteOutPartialCov } STATUS current DESCRIPTION "The group of objects providing for counters of transport layer statistics exclusive to UDP-Lite." ::= { udpliteMIBGroups 2 } udpliteEndpointGroup OBJECT-GROUP OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage } STATUS current DESCRIPTION "The group of objects providing for the IP version independent management of UDP-Lite 'endpoints'." ::= { udpliteMIBGroups 3 } Renker & Fairhurst Standards Track [Page 18] RFC 5097 MIB for the UDP-Lite Protocol January 2008 udpliteAppGroup OBJECT-GROUP OBJECTS { udpliteEndpointViolCoverage } STATUS current DESCRIPTION "The group of objects that provide application-level information for the configuration management of UDP-Lite 'endpoints'." ::= { udpliteMIBGroups 4 } END 4. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: The indices of the udpliteEndpointTable contain information about the listeners on an entity. In particular, the udpliteEndpointLocalPort index objects can be used to identify ports that are open on the machine and which attacks are likely to succeed, without the attacker having to run a port scanner. The table also identifies the currently listening UDP-Lite ports. The udpliteEndpointMinCoverage provides information about the requirements of the transport service associated with a specific UDP-Lite port. This provides additional detail concerning the type of application associated with the port at the receiver. Since UDP-Lite permits the delivery of (partially) corrupted data to an end host, the counters defined in this MIB module may be used to infer information about the characteristics of the end-to-end path over which the datagrams are communicated. This information could be used to infer the type of application associated with the port at the receiver. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), Renker & Fairhurst Standards Track [Page 19] RFC 5097 MIB for the UDP-Lite Protocol January 2008 even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 5. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: +------------+-------------------------+ | Descriptor | OBJECT IDENTIFIER value | +------------+-------------------------+ | udpliteMIB | { mib-2 170 } | +------------+-------------------------+ 6. Acknowledgments The design of the MIB module presented in this document owes much to the format of the module presented in [RFC4113]. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Renker & Fairhurst Standards Track [Page 20] RFC 5097 MIB for the UDP-Lite Protocol January 2008 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 7.2. Informative References [CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to Diagrammed Management Information Bases", ACM Computer Communications Review, 19(1):13-16, January 1989. [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, June 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Renker & Fairhurst Standards Track [Page 21] RFC 5097 MIB for the UDP-Lite Protocol January 2008 Authors' Addresses Gerrit Renker University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland EMail: gerrit@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Renker & Fairhurst Standards Track [Page 22] RFC 5097 MIB for the UDP-Lite Protocol January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Renker & Fairhurst Standards Track [Page 23] snmp-mibs-downloader-1.1/mibrfcs/rfc5098.txt0000644000000000000000000046726711402176072015616 0ustar Network Working Group G. Beacham Request for Comments: 5098 Motorola, Inc. Category: Standards Track S. Kumar Texas Instruments S. Channabasappa CableLabs February 2008 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. Beacham, et al. Standards Track [Page 1] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Introduction ....................................................2 3. Terminology .....................................................3 3.1. MTA ........................................................3 3.2. Endpoint ...................................................3 3.3. L Line Package .............................................4 3.4. E Line Package .............................................4 4. Overview ........................................................4 4.1. Structure of the MIB .......................................5 4.2. pktcSigMibObjects ..........................................5 4.3. pktcSigConformance .........................................6 5. Definitions .....................................................6 6. Examples .......................................................69 7. Acknowledgments ................................................72 8. Security Considerations ........................................73 9. IANA Considerations ............................................75 10. References ....................................................75 10.1. Normative References .....................................75 10.2. Informative References ...................................76 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction A multimedia terminal adapter (MTA) is used to deliver broadband Internet, data, and/or voice access jointly with telephony service to a subscriber's or customer's premises using a cable network infrastructure. An MTA is normally installed at the customer's or subscriber's premises, and it is coupled to a multiple system operator (MSO) using a hybrid fiber coax (HFC) access network. An MTA is provisioned by the MSO for broadband Internet, data, and/or voice service. For more information on MTA provisioning, refer to Beacham, et al. Standards Track [Page 2] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 the PacketCable Provisioning Specification [PKT-SP-PROV] and [RFC4682]. MTA devices include one or more endpoints (e.g., telephone ports), which receive call signaling information to establish ring cadence, and codecs used for providing telephony service. For more information on call signaling, refer to the PacketCable Signaling Specification [PKT-SP-MGCP] and [RFC3435]. For more information on codecs refer to the PacketCable Audio/Video Codecs Specification [PKT-SP-CODEC]. Telephone systems are typically very complex and often have a wide distribution. It is therefore important for management systems to support MTAs from multiple vendors at the same time, including those from multiple countries. This MIB module provides objects suitable for managing signaling for MTA devices in the widest possible range of markets. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terms "MIB module" and "information module" are used interchangeably in this memo. As used here, both terms refer to any of the three types of information modules defined in Section 3 of RFC 2578 [RFC2578]. 3.1. MTA An MTA is a PacketCable or IPCablecom compliant device providing telephony services over a cable or hybrid system used to deliver video signals to a community. It contains an interface to endpoints, a network interface, codecs, and all signaling and encapsulation functions required for Voice-over IP transport, call signaling, and Quality of Service signaling. An MTA can be an embedded or standalone device. An Embedded MTA (E-MTA) is an MTA device containing an embedded Data Over Cable Service Interface Specifications (DOCSIS) Cable Modem. A Standalone MTA (S-MTA) is an MTA device separated from the DOCSIS Cable Modem by non-DOCSIS Media Access Control (MAC) interface (e.g., Ethernet, USB). 3.2. Endpoint An endpoint or MTA endpoint is a standard telephony physical port located on the MTA and used for attaching the telephone device to the MTA. Beacham, et al. Standards Track [Page 3] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 3.3. L Line Package The L line package refers to the Media Gateway Control Protocol (MGCP) package for the core signaling functionality, as defined by PacketCable and IPCablecom. An MTA provides all L package elements: however, the operator determines their application. 3.4. E Line Package The E line package refers to the MGCP package extensions, over and above the core L package, defined in support of international requirements. E line package elements are optional, vary from country to country, and are set by operator or regulatory requirements. 4. Overview This MIB module provides a set of objects required for Multimedia Terminal Adapter (MTA) devices compliant with the PacketCable and IPCablecom signaling specifications published by CableLabs, the European Telecommunications Standards Institute (ETSI), and the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) IPCablecom compliant Multimedia Terminal Adapter (MTA) devices. The Signaling MIB module (PKTC-IETF-SIG-MIB) is intended to update various Signaling MIB modules from which it is partly derived: - the PacketCable 1.0 Signaling MIB Specification [PKT-SP-MIB-SIG-1.0], - the PacketCable 1.5 Signaling MIB Specification [PKT-SP-MIB-SIG-1.5], - the ITU-T IPCablecom Signaling MIB requirements [ITU-T-J169], - the ETSI Signaling MIB [ETSI-TS-101-909-9]. The ETSI Signaling MIB requirements also refer to various signal characteristics defined in [ETSI-TS-101-909-4], [ETSI-EN-300-001], [ETSI-EN-300-659-1], [ETSI-EN-300-324-1] and [ETSI-TR-101-183]. Several normative and informative references are used to help define Signaling MIB objects. As a convention, wherever PacketCable and IPCablecom requirements are equivalent, the PacketCable reference is used in the object REFERENCE clause. IPCablecom compliant MTA devices MUST use the equivalent IPCablecom references. Beacham, et al. Standards Track [Page 4] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 This MIB module describes the various Signaling MIB objects that are directly related to the PacketCable MTA and the endpoints supported on the MTA, each of which provides services independently. The recognition and distinction of the endpoints are made by utilizing the ifTable (IF-MIB [RFC2863]), where each index (ifIndex) value refers to a unique endpoint. This MIB module also utilizes the syntax definition of the Differentiated Services Code Point (DSCP) from DIFFSERV-DSCP-TC [RFC3289] for defining MIB objects that allow for differentiation between various types of traffic in the service provider network. 4.1. Structure of the MIB This MIB module is identified by pktcIetfSigMib and is structured into two major parts: - Signaling information that controls device and endpoint configuration (pktcSigMibObjects) - Module Conformance information(pktcSigConformance) The following sections explain each part in further detail. It is to be noted that future enhancements to specify Notification Objects are also allowed (pktcSigNotification). 4.2. pktcSigMibObjects This is further divided into device-specific elements (pktcSigDevObjects) and endpoint-specific elements (pktcSigEndPntConfigObjects). Some highlights of the device-specific elements are as follows: pktcSigDevCodecTable - this object identifies the codec types available on the device. pktcSigDevEchoCancellation - this object identifies the capability of echo cancellation on the device. pktcSigDevSilenceSuppression - this object specifies if the device is capable of silence suppression (Voice Activity Detection). pktcSigPulseSignalTable - this table selects the various signals used in the application of the metering pulse signal to the twisted pair line. pktcSigDevToneTable - this table specifies a flexible structure within which to specify all of the tones used in the MTA. Beacham, et al. Standards Track [Page 5] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigDevMultiFreqToneTable - this table defines the characteristics of tones with multiple frequencies. Each entry in this table represents the frequency reference of a multi-frequency tone. The endpoint-specific elements are mostly confined to the Endpoint configuration MIB table (pktcSigEndPntConfigTable). This table describes the MTA endPoint configuration. The number of entries in this table represents the number of provisioned endpoints. 4.3. pktcSigConformance pktcSigDeviceGroup - this group contains all the MIB objects that apply on a per-device basis and need to be implemented by an MTA to claim compliance with the specified MIB module. pktcSigEndpointGroup - this group contains all the MIB objects that apply on a per-endpoint basis and need to be implemented by an MTA to claim compliance with the specified MIB module. pktcLLinePackageGroup - this group contains the MIB objects that need to be implemented to support the L line package. pktcELinePackageGroup - this group contains the MIB objects that need to be implemented to support the E line package. pktcInternationalGroup - this group contains optional MIB objects designed to support operations over the widest possible range of markets. 5. Definitions PKTC-IETF-SIG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- [RFC4001] TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC -- [RFC2579] Beacham, et al. Standards Track [Page 6] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF -- [RFC2580] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] ifIndex FROM IF-MIB -- [RFC2863] Dscp FROM DIFFSERV-DSCP-TC; -- [RFC3289] pktcIetfSigMib MODULE-IDENTITY LAST-UPDATED "200712180000Z" -- December 18, 2007 ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO "Sumanth Channabasappa Cable Television Laboratories, Inc. 858 Coal Creek Circle, Louisville, CO 80027, USA Phone: +1 303-661-3307 Email: Sumanth@cablelabs.com Gordon Beacham Motorola, Inc. 6450 Sequence Drive, Bldg. 1 San Diego, CA 92121, USA Phone: +1 858-404-2334 Email: gordon.beacham@motorola.com Satish Kumar Mudugere Eswaraiah Texas Instruments India (P) Ltd., Golf view, Wind Tunnel Road Murugesh Palya Bangalore 560 017, INDIA Phone: +91 80 5269451 Email: satish.kumar@ti.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-Chair: Jean-Francois Mule, jf.mule@cablelabs.com Co-Chair: Richard Woundy, Richard_Woundy@cable.comcast.com" DESCRIPTION "This MIB module supplies the basic management objects for the PacketCable and IPCablecom Signaling protocols. This version of the MIB includes common signaling and Network Call Signaling Beacham, et al. Standards Track [Page 7] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 (NCS)-related signaling objects. Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5098; see the RFC itself for full legal notices." REVISION "200712180000Z" DESCRIPTION "Initial version, published as RFC 5098." ::= { mib-2 169 } -- Textual Conventions TenthdBm ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-1" STATUS current DESCRIPTION "This TEXTUAL-CONVENTION represents power levels that are normally expressed in dBm. Units are in tenths of a dBm; for example, -13.5 dBm will be represented as -135." SYNTAX Integer32 PktcCodecType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " This TEXTUAL-CONVENTION defines various types of codecs that MAY be supported. The description for each enumeration is listed below: Enumeration Description other a defined codec not in the enumeration unknown a codec not defined by the PacketCable Codec Specification g729 ITU-T Recommendation G.729 reserved for future use g729E ITU-T Recommendation G.729E pcmu Pulse Code Modulation u-law (PCMU) g726at32 ITU-T Recommendation G.726-32 (32 kbit/s) g728 ITU-T Recommendation G.728 pcma Pulse Code Modulation a-law (PCMA) g726at16 ITU-T Recommendation G.726-16 (16 kbit/s) g726at24 ITU-T Recommendation G.726-24 (24 kbit/s) g726at40 ITU-T Recommendation G.726-40 (40 kbit/s) ilbc IETF Internet low-bit rate codec bv16 Broadcom BroadVoice16 The list of codecs is consistent with the IETF Real-Time Transport Protocol (RTP) Profile registry and Beacham, et al. Standards Track [Page 8] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 the RTP Map Parameters Table in PacketCable Audio/Video Codecs Specification [PKT-SP-CODEC]. The literal codec name for each codec is listed below: Codec Literal Codec Name g729 G729 g729E G729E pcmu PCMU g726at32 G726-32 g728 G728 pcma PCMA g726at16 G726-16 g726at24 G726-24 g726at40 G726-40 ilbc iLBC bv16 BV16 The literal codec name is the second column of the table with codec RTP Map Parameters. The Literal Codec Name Column contains the codec name used in the local connection options (LCO) of the NCS messages create connection (CRCX)/modify connection (MDCX) and is also used to identify the codec in the Call Management System (CMS) Provisioning Specification. The RTP Map Parameter column of the Table contains the string used in the media attribute line (a=) of the session description protocol (SDP) parameters in NCS messages." SYNTAX INTEGER { other (1), unknown (2), g729 (3), reserved (4), g729E (5), pcmu (6), g726at32 (7), g728 (8), pcma (9), g726at16 (10), g726at24 (11), g726at40 (12), ilbc (13), bv16 (14) } PktcRingCadence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This object provides an encoding scheme for ring Beacham, et al. Standards Track [Page 9] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 cadences, including repeatability characteristics. All fields in this object MUST be encoded in network-byte order. The first three higher-order octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50 milliseconds. A bit value of '1' indicates the presence of a ring-tone, and a bit value of '0' indicates the absence of a ring-tone, for that duration (50 ms) (Note: A minimum number of octets required to encode the bit-string MUST be used). The first two of the reserved octets MUST indicate the length of the encoded cadence (in bits) and MUST range between 1 and 264. (Note: The length in bits MUST also be consistent with the number of octets that encode the cadence). The MTA MUST ignore any unused bits in the last octet, but MUST reflect the value as provided on subsequent SNMP GETs. The third of the reserved octets indicates 'repeatability' and MUST be either 0x80 or 0x00 -- the former value indicating 'non-repeatability', and the latter indicating 'repeatability'. The MTA MUST reject attempts to set a value that violates any of the above requirements." SYNTAX OCTET STRING (SIZE(4..36)) PktcSigType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " This object lists the various types of signaling that may be supported: other(1) - set when signaling other than NCS is used ncs(2) - Network Call Signaling is a derivation of MGCP (Media Gateway Control Protocol) defined for IPCablecom/PacketCable MTAs." SYNTAX INTEGER { other(1), ncs(2) } Beacham, et al. Standards Track [Page 10] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 DtmfCode::=TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TEXTUAL-CONVENTION represents the Dual-Tone Multi-Frequency (DTMF) Character used to indicate the start or end of the digit transition sequence used for caller id or Visual Message Waiting Indicator (VMWI). Note: The DTMF code '*' is indicated using 'dtmfcodeStar', and the DTMF code '#' is indicated using ' dtmfcodeHash'." SYNTAX INTEGER { dtmfcode0(0), dtmfcode1(1), dtmfcode2(2), dtmfcode3(3), dtmfcode4(4), dtmfcode5(5), dtmfcode6(6), dtmfcode7(7), dtmfcode8(8), dtmfcode9(9), dtmfcodeStar(10), dtmfcodeHash(11), dtmfcodeA(12), dtmfcodeB(13), dtmfcodeC(14), dtmfcodeD(15) } PktcSubscriberSideSigProtocol::=TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TEXTUAL-CONVENTION represents the Signaling protocol being used for purposes such as caller id or VMWI. A value of fsk(1) indicates Frequency Shift Keying (FSK). A value of dtmf(2) indicates Dual-Tone Multi-Frequency (DTMF)." SYNTAX INTEGER { fsk(1), dtmf(2) } pktcSigMibObjects OBJECT IDENTIFIER ::= { pktcIetfSigMib 1 } pktcSigDevObjects OBJECT IDENTIFIER ::= Beacham, et al. Standards Track [Page 11] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 { pktcSigMibObjects 1 } pktcSigEndPntConfigObjects OBJECT IDENTIFIER ::= { pktcSigMibObjects 2 } -- -- The codec table (pktcSigDevCodecTable) defines all combinations -- of codecs supported by the Multimedia Terminal Adapter (MTA). -- pktcSigDevCodecTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigDevCodecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table describes the MTA-supported codec types. An MTA MUST populate this table with all possible combinations of codecs it supports for simultaneous operation. For example, an MTA with two endpoints may be designed with a particular Digital Signal Processing (DSP) and memory architecture that allows it to support the following fixed combinations of codecs for simultaneous operation: Codec Type Maximum Number of Simultaneous Codecs PCMA 3 PCMA 2 PCMU 1 PCMA 1 PCMU 2 PCMU 3 PCMA 1 G729 1 G729 2 PCMU 1 G729 1 Based on this example, the entries in the codec table would be: pktcSigDev pktcSigDev pktcSigDev CodecComboIndex CodecType CodecMax 1 pcma 3 2 pcma 2 2 pcmu 1 Beacham, et al. Standards Track [Page 12] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 3 pcma 1 3 pcmu 2 4 pcmu 3 5 pcma 1 5 g729 1 6 g729 2 7 pcmu 1 7 g729 1 An operator querying this table is able to determine all possible codec combinations the MTA is capable of simultaneously supporting. This table MUST NOT include non-voice codecs." ::= { pktcSigDevObjects 1 } pktcSigDevCodecEntry OBJECT-TYPE SYNTAX PktcSigDevCodecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents the maximum number of active connections with a particular codec the MTA is capable of supporting. Each row is indexed by a composite key consisting of a number enumerating the particular codec combination and the codec type." INDEX { pktcSigDevCodecComboIndex, pktcSigDevCodecType } ::= { pktcSigDevCodecTable 1 } PktcSigDevCodecEntry ::= SEQUENCE { pktcSigDevCodecComboIndex Unsigned32, pktcSigDevCodecType PktcCodecType, pktcSigDevCodecMax Unsigned32 } pktcSigDevCodecComboIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION " The index value that enumerates a particular codec combination in the pktcSigDevCodecTable." ::= { pktcSigDevCodecEntry 1 } pktcSigDevCodecType OBJECT-TYPE SYNTAX PktcCodecType MAX-ACCESS not-accessible STATUS current Beacham, et al. Standards Track [Page 13] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 DESCRIPTION " A codec type supported by this MTA." ::= { pktcSigDevCodecEntry 2 } pktcSigDevCodecMax OBJECT-TYPE SYNTAX Unsigned32(1..255) MAX-ACCESS read-only STATUS current DESCRIPTION " The maximum number of simultaneous sessions of a particular codec that the MTA can support." ::= { pktcSigDevCodecEntry 3 } -- -- These are the common signaling-related definitions that affect -- the entire MTA device. -- pktcSigDevEchoCancellation OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION " This object specifies if the device is capable of echo cancellation. The MTA MUST set this MIB object to a value of true(1) if it is capable of echo cancellation, and a value of false(2) if not." ::= { pktcSigDevObjects 2 } pktcSigDevSilenceSuppression OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION " This object specifies if the device is capable of silence suppression (as a result of Voice Activity Detection). The MTA MUST set this MIB object to a value of true(1) if it is capable of silence suppression, and a value of false(2) if not." ::= { pktcSigDevObjects 3 } pktcSigDevCidSigProtocol OBJECT-TYPE SYNTAX PktcSubscriberSideSigProtocol MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to configure the subscriber-line protocol used for signaling on-hook caller id information. Beacham, et al. Standards Track [Page 14] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Different countries define different caller id signaling protocols to support caller identification. Setting this object at a value fsk(1) sets the subscriber line protocol to be Frequency Shift Keying (FSK). Setting this object at a value dtmf(2) sets the subscriber line protocol to be Dual-Tone Multi-Frequency (DTMF). The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { fsk } ::= { pktcSigDevObjects 4 } pktcSigDevR0Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 0 (a user-defined field). The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 5 } pktcSigDevR1Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 1 (a user-defined field). The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 6 } pktcSigDevR2Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 2 (a user-defined field). Beacham, et al. Standards Track [Page 15] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 7 } pktcSigDevR3Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 3 (a user-defined field). The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 8 } pktcSigDevR4Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 4 (a user-defined field). The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 9 } pktcSigDevR5Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 5 (a user-defined field). The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 10 } pktcSigDevR6Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 6 (a user-defined field). Beacham, et al. Standards Track [Page 16] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 11 } pktcSigDevR7Cadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence 7 (a user-defined field). The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 12 } pktcSigDevRgCadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence rg (a user-defined field). The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 13 } pktcSigDevRsCadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence rs (a user-defined field). The MTA MUST reject any attempt to make this object repeatable. The value of this MIB object MUST NOT persist across MTA reboots." ::= { pktcSigDevObjects 14 } pktcSigDefCallSigDscp OBJECT-TYPE SYNTAX Dscp -- RFC 3289: DIFFSERV-DSCP-TC MAX-ACCESS read-write STATUS current DESCRIPTION " The default value used in the IP header for setting the Differentiated Services Code Point (DSCP) value for call Beacham, et al. Standards Track [Page 17] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 signaling. The value of this MIB object MUST NOT persist across MTA reboots." DEFVAL { 0 } ::= { pktcSigDevObjects 15 } pktcSigDefMediaStreamDscp OBJECT-TYPE SYNTAX Dscp -- RFC 3289: DIFFSERV-DSCP-TC MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the default value used in the IP header for setting the Differentiated Services Code Point (DSCP) value for media stream packets. The MTA MUST NOT update this object with the value supplied by the CMS in the NCS messages (if present). Any currently active connections are not affected by updates to this object. When the value of this object is updated by SNMP, the MTA MUST use the new value as a default starting only from new connections. The value of this MIB object MUST NOT persist across MTA reboots." DEFVAL { 0 } ::= { pktcSigDevObjects 16 } -- -- pktcSigCapabilityTable - This table defines the valid signaling -- types supported by this MTA. -- pktcSigCapabilityTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table describes the signaling types supported by this MTA." ::= { pktcSigDevObjects 17 } pktcSigCapabilityEntry OBJECT-TYPE SYNTAX PktcSigCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entries in pktcMtaDevSigCapabilityTable - list of supported signaling types, versions, and vendor extensions Beacham, et al. Standards Track [Page 18] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 for this MTA. Each entry in the list provides for one signaling type and version combination. If the device supports multiple versions of the same signaling type, it will require multiple entries." INDEX { pktcSigCapabilityIndex } ::= { pktcSigCapabilityTable 1 } PktcSigCapabilityEntry ::= SEQUENCE { pktcSigCapabilityIndex Unsigned32, pktcSigCapabilityType PktcSigType, pktcSigCapabilityVersion SnmpAdminString, pktcSigCapabilityVendorExt SnmpAdminString } pktcSigCapabilityIndex OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION " The index value that uniquely identifies an entry in the pktcSigCapabilityTable." ::= { pktcSigCapabilityEntry 1 } pktcSigCapabilityType OBJECT-TYPE SYNTAX PktcSigType MAX-ACCESS read-only STATUS current DESCRIPTION " This object identifies the type of signaling used. This value has to be associated with a single signaling version." ::= { pktcSigCapabilityEntry 2 } pktcSigCapabilityVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " Provides the version of the signaling type - reference pktcSigCapabilityType. Examples would be 1.0 or 2.33 etc." ::= { pktcSigCapabilityEntry 3 } pktcSigCapabilityVendorExt OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " The vendor extension allows vendors to provide a list of Beacham, et al. Standards Track [Page 19] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 additional capabilities. The syntax for this MIB object in ABNF ([RFC5234]) is specified to be zero or more occurrences of vendor extensions, as follows: pktcSigCapabilityVendorExt = *(vendor-extension) vendor-extension = (ext symbol alphanum) DQUOTE ; DQUOTE ext = DQUOTE %x58 DQUOTE symbol = (DQUOTE %x2D DQUOTE)/(DQUOTE %x2D DQUOTE) alphanum = 1*6(ALPHA/DIGIT) " ::= { pktcSigCapabilityEntry 4 } pktcSigDefNcsReceiveUdpPort OBJECT-TYPE SYNTAX InetPortNumber (1025..65535) MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the MTA User Datagram Protocol (UDP) receive port that is being used for NCS call signaling. This object should only be changed by the configuration file. Unless changed via configuration, this MIB object MUST reflect a value of '2427'." REFERENCE "PacketCable NCS Specification" ::= { pktcSigDevObjects 18 } pktcSigPowerRingFrequency OBJECT-TYPE SYNTAX INTEGER { f20Hz(1), f25Hz(2), f33Point33Hz(3), f50Hz(4), f15Hz(5), f16Hz(6), f22Hz(7), f23Hz(8), f45Hz(9) } MAX-ACCESS read-only STATUS current DESCRIPTION " This object must only be provided via the configuration file during the provisioning process. The power ring Beacham, et al. Standards Track [Page 20] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 frequency is the frequency at which the sinusoidal voltage must travel down the twisted pair to make terminal equipment ring. Different countries define different electrical characteristics to make terminal equipment ring. The f20Hz setting corresponds to a power ring frequency of 20 Hertz. The f25Hz setting corresponds to a power ring frequency of 25 Hertz. The f33Point33Hz setting corresponds to a power ring frequency of 33.33 Hertz. The f50Hz setting corresponds to a power ring frequency of 50 Hertz. The f15Hz setting corresponds to a power ring frequency of 15 Hertz. The f16Hz setting corresponds to a power ring frequency of 16 Hertz. The f22Hz setting corresponds to a power ring frequency of 22 Hertz. The f23Hz setting corresponds to a power ring frequency of 23 Hertz. The f45Hz setting corresponds to a power ring frequency of 45 Hertz." REFERENCE "ETSI-EN-300-001" ::= { pktcSigDevObjects 19 } pktcSigPulseSignalTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigPulseSignalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The Pulse signal table defines the pulse signal operation. There are nine types of international pulse signals, with each signal having a set of provisionable parameters. The values of the MIB objects in this table take effect only if these parameters are not defined via signaling, in which case, the latter determines the values of the parameters. The MIB objects in this table do not persist across MTA reboots." REFERENCE "ETSI-TS-101-909-4 Specification" ::= { pktcSigDevObjects 20 } pktcSigPulseSignalEntry OBJECT-TYPE SYNTAX PktcSigPulseSignalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object defines the set of parameters associated with each particular value of pktcSigPulseSignalType. Each entry in the pktcSigPulseSignalTable is indexed by the pktcSigPulseSignalType object. Beacham, et al. Standards Track [Page 21] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The conceptual rows MUST NOT persist across MTA reboots." INDEX { pktcSigPulseSignalType } ::= { pktcSigPulseSignalTable 1 } PktcSigPulseSignalEntry ::= SEQUENCE { pktcSigPulseSignalType INTEGER, pktcSigPulseSignalFrequency INTEGER, pktcSigPulseSignalDbLevel TenthdBm, pktcSigPulseSignalDuration Unsigned32, pktcSigPulseSignalPulseInterval Unsigned32, pktcSigPulseSignalRepeatCount Unsigned32 } pktcSigPulseSignalType OBJECT-TYPE SYNTAX INTEGER { initialRing(1), pulseLoopClose(2), pulseLoopOpen(3), enableMeterPulse(4), meterPulseBurst(5), pulseNoBattery(6), pulseNormalPolarity(7), pulseReducedBattery(8), pulseReversePolarity(9) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "There are nine types of international pulse signals. These signals are defined as follows: initial ring pulse loop close pulse loop open enable meter pulse meter pulse burst pulse no battery pulse normal polarity pulse reduced battery pulse reverse polarity" REFERENCE "ETSI-EN-300-324-1 Specification" ::= { pktcSigPulseSignalEntry 1 } pktcSigPulseSignalFrequency OBJECT-TYPE SYNTAX INTEGER { twentyfive(1), Beacham, et al. Standards Track [Page 22] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 twelvethousand(2), sixteenthousand(3) } MAX-ACCESS read-write STATUS current DESCRIPTION " This object is only applicable to the initialRing, enableMeterPulse, and meterPulseBurst signal types. This object identifies the frequency of the generated signal. The following table defines the default values for this object depending on signal type: pktcSigPulseSignalType Default initialRing 25 enableMeterPulse 16000 meterPulseBurst 16000 The value of twentyfive MUST only be used for the initialRing signal type. The values of twelvethousand and sixteenthousand MUST only be used for enableMeterPulse and meterPulseBurst signal types. An attempt to set this object while the value of pktcSigPulseSignalType is not initialRing, enableMeterPulse, or meterPulseBurst will result in an 'inconsistentValue' error." REFERENCE "ETSI-EN-300-001 Specification" ::= { pktcSigPulseSignalEntry 2} pktcSigPulseSignalDbLevel OBJECT-TYPE SYNTAX TenthdBm (-350..0) UNITS "1/10 of a dBm" MAX-ACCESS read-write STATUS current DESCRIPTION " This object is only applicable to the enableMeterPulse and meterPulseBurst signal types. This is the decibel level for each frequency at which tones could be generated at the a and b terminals (TE connection point). An attempt to set this object while the value of pktcSigPulseSignalType is not enableMeterPulse or meterPulseBurst will result in an 'inconsistentValue' error." REFERENCE "ETSI-EN-300-001 Specification" DEFVAL { -135 } ::={pktcSigPulseSignalEntry 3 } pktcSigPulseSignalDuration OBJECT-TYPE Beacham, et al. Standards Track [Page 23] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 SYNTAX Unsigned32 (0..5000) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the pulse duration for each signal type. In addition, the MTA must accept the values in the incremental steps specific for each signal type. The following table defines the default values and the incremental steps for this object depending on the signal type: pktcSigPulseSignaltype Default (ms) Increment (ms) initialRing 200 50 pulseLoopClose 200 10 pulseLoopOpen 200 10 enableMeterPulse 150 10 meterPulseBurst 150 10 pulseNoBattery 200 10 pulseNormalPolarity 200 10 pulseReducedBattery 200 10 pulseReversePolarity 200 10 An attempt to set this object to a value that does not fall on one of the increment boundaries, or on the wrong increment boundary for the specific signal type, will result in an 'inconsistentValue' error." REFERENCE "ETSI-EN-300-324-1 Specification" ::= {pktcSigPulseSignalEntry 4 } pktcSigPulseSignalPulseInterval OBJECT-TYPE SYNTAX Unsigned32 (0..5000) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the repeat interval, or the period, for each signal type. In addition, the MTA must accept the values in the incremental steps specific for each signal type. The following table defines the default values and the incremental steps for this object, depending on the signal type: pktcSigPulseSignaltype Default (ms) Increment (ms) initialRing 200 50 pulseLoopClose 1000 10 pulseLoopOpen 1000 10 Beacham, et al. Standards Track [Page 24] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 enableMeterPulse 1000 10 meterPulseBurst 1000 10 pulseNoBattery 1000 10 pulseNormalPolarity 1000 10 pulseReducedBattery 1000 10 pulseReversePolarity 1000 10 An attempt to set this object to a value that does not fall on one of the increment boundaries, or on the wrong increment boundary for the specific signal type, will result in an 'inconsistentValue' error." REFERENCE "ETSI-EN-300-324-1 Specification" ::= { pktcSigPulseSignalEntry 5} pktcSigPulseSignalRepeatCount OBJECT-TYPE SYNTAX Unsigned32 (1..50) MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies how many times to repeat a pulse. This object is not used by the enableMeterPulse signal type, and in that case, the value is irrelevant. The following table defines the default values and the valid ranges for this object, depending on the signal type: pktcSigPulseSignaltype Default Range initialRing 1 1-5 pulseLoopClose 1 1-50 pulseLoopOpen 1 1-50 enableMeterPulse (any value)(but not used) meterPulseBurst 1 1-50 pulseNoBattery 1 1-50 pulseNormalPolarity 1 1-50 pulseReducedBattery 1 1-50 pulseReversePolarity 1 1-50 An attempt to set this object to a value that does not fall within the range for the specific signal type will result in an 'inconsistentValue' error." ::={ pktcSigPulseSignalEntry 6 } pktcSigDevCidMode OBJECT-TYPE SYNTAX INTEGER { duringRingingETS(1), dtAsETS(2), rpAsETS(3), Beacham, et al. Standards Track [Page 25] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 lrAsETS(4), lrETS(5) } MAX-ACCESS read-write STATUS current DESCRIPTION " For on-hook caller id, pktcSigDevCidMode selects the method for representing and signaling caller identification. For the duringRingingETS method, the Frequency Shift Keying (FSK) or the Dual-Tone Multi-Frequency (DTMF) containing the caller identification information is sent between the first and second ring pattern. For the dtAsETS,rpAsETS, lrAsETS and lrETS methods, the FSK or DTMF containing the caller id information is sent before the first ring pattern. For the dtAsETS method, the FSK or DTMF is sent after the Dual Tone Alert Signal. For the rpAsETS method, the FSK or DTMF is sent after a Ring Pulse. For the lrAsETS method, the Line Reversal occurs first, then the Dual Tone Alert Signal, and, finally, the FSK or DTMF is sent. For the lrETS method, the Line Reversal occurs first, then the FSK or DTMF is sent. The value of this MIB object MUST NOT persist across MTA reboots." DEFVAL { rpAsETS} ::= {pktcSigDevObjects 21 } pktcSigDevCidAfterRing OBJECT-TYPE SYNTAX Unsigned32 (0|50..2000) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the delay between the end of first ringing pattern and the start of the transmission of the FSK or DTMF containing the caller id information. It is only used when pktcSigDevCidMode is set to a value of 'duringRingingETS'. The following table defines the default values for this MIB object, depending on the signal type Beacham, et al. Standards Track [Page 26] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 (pktcSigDevCidMode), and MUST be followed: Value of pktcSigDevCidMode Default value duringringingETS 550 ms dtAsETS any value (not used) rpAsETS any value (not used) lrAsETS any value (not used) lrETS any value (not used) An attempt to set this object while the value of pktcSigDevCidMode is not duringringingETS will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 550 } ::= {pktcSigDevObjects 22 } pktcSigDevCidAfterDTAS OBJECT-TYPE SYNTAX Unsigned32 (0|45..500) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the delay between the end of the Dual Tone Alert Signal (DT-AS) and the start of the transmission of the FSK or DTMF containing the caller id information. This object is only used when pktcSigDevCidMode is set to a value of 'dtAsETS' or 'lrAsETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevCidMode), and MUST be followed: Value of pktcSigDevCidMode Default value duringringingETS any value (not used) dtAsETS 50 ms rpAsETS any value (not used) lrAsETS 50 ms lrETS any value (not used) An attempt to set this object while the value of Beacham, et al. Standards Track [Page 27] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigDevCidMode is not 'dtAsETS' or 'lrAsETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 50 } ::= {pktcSigDevObjects 23 } pktcSigDevCidAfterRPAS OBJECT-TYPE SYNTAX Unsigned32 (0|500..800) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the delay between the end of the Ring Pulse Alert Signal (RP-AS) and the start of the transmission of the FSK or DTMF containing the caller id information. This MIB object is only used when pktcSigDevCidMode is set to a value of 'rpAsETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevCidMode), and MUST be followed: Value of pktcSigDevCidMode Default value duringringingETS any value (not used) dtAsETS any value (not used) rpAsETS 650 ms lrAsETS any value (not used) lrETS any value (not used) An attempt to set this object while the value of pktcSigDevCidMode is not 'rpAsETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 650 } ::= {pktcSigDevObjects 24 } pktcSigDevRingAfterCID OBJECT-TYPE SYNTAX Unsigned32 (0|50..500) UNITS "Milliseconds" MAX-ACCESS read-write Beacham, et al. Standards Track [Page 28] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 STATUS current DESCRIPTION " This object specifies the delay between the end of the complete transmission of the FSK or DTMF containing the caller id information and the start of the first ring pattern. It is only used when pktcSigDevCidMode is set to a value of 'dtAsETS', 'rpAsETS', 'lrAsETS' or 'lrETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevCidMode), and MUST be followed: Value of pktcSigDevCidMode Default value duringringingETS any value (not used) dtAsETS 250 ms rpAsETS 250 ms lrAsETS 250 ms lrETS 250 ms An attempt to set this object while the value of pktcSigDevCidMode is not 'dtAsETS', 'rpAsETS', 'lrAsETS', or 'lrETS' will result in an 'inconsistent value' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 250 } ::= {pktcSigDevObjects 25 } pktcSigDevCidDTASAfterLR OBJECT-TYPE SYNTAX Unsigned32 (50..655) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the delay between the end of the Line Reversal and the start of the Dual Tone Alert Signal (DT-AS). This object is only used when pktcSigDevCidMode is set to a value of 'lrAsETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevCidMode), and MUST be followed: Beacham, et al. Standards Track [Page 29] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Value of pktcSigDevCidMode Default value duringringingETS any value (not used) dtAsETS any value (not used) rpAsETS any value (not used) lrAsETS 250 ms lrETS any value (not used) An attempt to set this object while the value of pktcSigDevCidMode is not lrAsETS will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 250 } ::= {pktcSigDevObjects 26 } pktcSigDevVmwiMode OBJECT-TYPE SYNTAX INTEGER { dtAsETS(1), rpAsETS(2), lrAsETS(3), osi(4), lrETS(5) } MAX-ACCESS read-write STATUS current DESCRIPTION " For visual message waiting indicator (VMWI), pktcSigDevVmwiMode selects the alerting signal method. For the dtAsETS, rpAsETS, lrAsETS, osi, and lrETS methods, the FSK containing the VMWI information is sent after an alerting signal. For the dtAsETS method, the FSK, or DTMF is sent after the Dual Tone Alert Signal. For the rpAsETS method, the FSK or DTMF is sent after a Ring Pulse. For the lrAsETS method, the Line Reversal occurs first, then the Dual Tone Alert Signal, and, finally, the FSK or DTMF is sent. For the OSI method, the FSK or DTMF is sent after the Open Switching Interval. Beacham, et al. Standards Track [Page 30] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 For the lrETS method, the Line Reversal occurs first, then the FSK or DTMF is sent. The value of this MIB object MUST NOT persist across MTA reboots." DEFVAL { rpAsETS } ::= {pktcSigDevObjects 27 } pktcSigDevVmwiAfterDTAS OBJECT-TYPE SYNTAX Unsigned32 (0|45..500) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the delay between the end of the Dual Tone Alert Signal (DT-AS) and the start of the transmission of the FSK or DTMF containing the VMWI information. This object is only used when pktcSigDevVmwiMode is set to a value of 'dtAsETS' or 'lrAsETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevVmwiMode), and MUST be followed: Value of pktcSigDevVmwiMode Default value dtAsETS 50 ms rpAsETS any value (not used) lrAsETS 50 ms lrETS any value (not used) An attempt to set this object while the value of pktcSigDevVmwiMode is not 'dtAsETS' or 'lrAsETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 50 } ::= {pktcSigDevObjects 28 } pktcSigDevVmwiAfterRPAS OBJECT-TYPE SYNTAX Unsigned32 (0|500..800) Beacham, et al. Standards Track [Page 31] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the delay between the end of the Ring Pulse Alert Signal (RP-AS) and the start of the transmission of the FSK or DTMF containing the VMWI information. This object is only used when pktcSigDevVmwiMode is set to a value of 'rpAsETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevVmwiMode), and MUST be followed: Value of pktcSigDevVmwiMode Default value dtAsETS any value (not used) rpAsETS 650 ms lrAsETS any value (not used) lrETS any value (not used) An attempt to set this object while the value of pktcSigDevVmwiMode is not 'rpAsETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 650 } ::= {pktcSigDevObjects 29 } pktcSigDevVmwiDTASAfterLR OBJECT-TYPE SYNTAX Unsigned32 (0|50..655) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the delay between the end of the Line Reversal and the start of the Dual Tone Alert Signal (DT-AS) for VMWI information. This object is only used when pktcSigDevVmwiMode is set to a value of 'lrAsETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevVmwiMode), and MUST be followed: Beacham, et al. Standards Track [Page 32] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Value of pktcSigDevVmwiMode Default value dtAsETS any value (not used) rpAsETS any value (not used) lrAsETS 250 ms lrETS any value (not used) An attempt to set this object while the value of pktcSigDevVmwiMode is not 'lrAsETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification" DEFVAL { 250 } ::= {pktcSigDevObjects 30 } pktcSigDevRingCadenceTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigDevRingCadenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Cadence rings are defined by the telco governing body for each country. The MTA must be able to support various ranges of cadence patterns and cadence periods. The MTA will be able to support country-specific provisioning of the cadence and idle period. Each cadence pattern will be assigned a unique value ranging from 0-127 (inclusive) corresponding to the value of x, where x is the value sent in the cadence ringing (cr) signal cr(x), requested per the appropriate NCS message, and defined in the E package. The MTA will derive the cadence periods from the ring cadence table entry, as provisioned by the customer. The MTA is allowed to provide appropriate default values for each of the ring cadences. This table only needs to be supported when the MTA implements the E package." REFERENCE "ETSI-TS-101-909-4 Specification" ::= { pktcSigDevObjects 31 } pktcSigDevRingCadenceEntry OBJECT-TYPE SYNTAX PktcSigDevRingCadenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Beacham, et al. Standards Track [Page 33] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 " Each entry in this row corresponds to a ring cadence that is being supported by the device. The conceptual rows MUST NOT persist across MTA reboots." INDEX { pktcSigDevRingCadenceIndex } ::= { pktcSigDevRingCadenceTable 1 } PktcSigDevRingCadenceEntry ::= SEQUENCE { pktcSigDevRingCadenceIndex Unsigned32, pktcSigDevRingCadence PktcRingCadence } pktcSigDevRingCadenceIndex OBJECT-TYPE SYNTAX Unsigned32 (0..127) MAX-ACCESS not-accessible STATUS current DESCRIPTION " A unique value ranging from 0 to 127 that corresponds to the value sent by the LE based on country-specific cadences, one row per cadence cycle. In any given system implementation for a particular country, it is anticipated that a small number of ring cadences will be in use. Thus, this table most likely will not be populated to its full size." ::= { pktcSigDevRingCadenceEntry 1 } pktcSigDevRingCadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION "This is the Ring Cadence." ::= { pktcSigDevRingCadenceEntry 2 } pktcSigDevToneTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigDevToneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The Tone Table defines the composition of tones and various tone operations. The definition of the tones callWaiting1 through callWaiting4 in this table MUST only contain the audible tone itself; the delay between tones or the value of the tone repeat count are not applicable for the call waiting tones. Beacham, et al. Standards Track [Page 34] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The delay between tones or the repeat count is controlled by the objects pktcSigEndPntConfigCallWaitingDelay and pktcSigEndPntConfigCallWaitingMaxRep. If the pktcSigDevToneType is set to either of the values callWaiting1, callWaiting2, callWaiting3, or callWaiting4, then the value of the pktcSigDevToneWholeToneRepeatCount object indicates that the particular frequency group is applicable, as a repeatable part of the tone, based on the value of the MIB object pktcSigDevToneWholeToneRepeatCount. The MTA MUST make sure that, after the provisioning cycle, the table is fully populated (i.e., for each possible index, an entry MUST be defined) using reasonable defaults for each row that was not defined by the provisioning information delivered via MTA Configuration. The frequency composition of each tone is defined by the pktcSigDevMultiFreqToneTable. For each tone type defined in pktcSigDevToneTable, the MTA MUST populate at least one entry in the pktcSigDevMultiFreqToneTable. For each particular value of pktcSigDevToneType, the pktcSigDevToneTable table can define non-repeating and repeating groups of the frequencies defined by the pktcSigDevMultiFreqToneTable, such that each group is represented by the set of the consecutive rows (frequency group) in the pktcSigDevMultiFreqToneTable. Objects in this table do not persist across MTA reboots. For tones with multiple frequencies refer to the MIB table pktcSigDevMultiFreqToneTable." REFERENCE "PacketCable NCS Specification, ETSI-TS-101-909-4 Specification." ::= { pktcSigDevObjects 32 } pktcSigDevToneEntry OBJECT-TYPE SYNTAX PktcSigDevToneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The different tone types that can be provisioned based on country-specific needs. Each entry contains the tone generation parameters for a specific frequency group of the specific Tone Type. Beacham, et al. Standards Track [Page 35] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The different parameters can be provisioned via MTA configuration based on country specific needs. An MTA MUST populate all entries of this table for each tone type." INDEX { pktcSigDevToneType, pktcSigDevToneFreqGroup } ::= { pktcSigDevToneTable 1 } PktcSigDevToneEntry ::= SEQUENCE { pktcSigDevToneType INTEGER, pktcSigDevToneFreqGroup Unsigned32, pktcSigDevToneFreqCounter Unsigned32, pktcSigDevToneWholeToneRepeatCount Unsigned32, pktcSigDevToneSteady TruthValue } pktcSigDevToneType OBJECT-TYPE SYNTAX INTEGER { busy(1), confirmation(2), dial(3), messageWaiting(4), offHookWarning(5), ringBack(6), reOrder(7), stutterdial(8), callWaiting1(9), callWaiting2(10), callWaiting3(11), callWaiting4(12), alertingSignal(13), specialDial(14), specialInfo(15), release(16), congestion(17), userDefined1(18), userDefined2(19), userDefined3(20), userDefined4(21) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value that will correspond to the different tone types. These tones can be provisioned based on country-specific needs. This object defines the type of tone being accessed. The alertingSignal, specialDial, specialInfo, release, Beacham, et al. Standards Track [Page 36] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 congestion, userDefined1, userDefined2, userDefined3, and userDefined4 tone types are used in the E line package." ::= { pktcSigDevToneEntry 1 } pktcSigDevToneFreqGroup OBJECT-TYPE SYNTAX Unsigned32(1..4) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This MIB object represents the Tone Sequence reference of a multi-sequence tone." ::={ pktcSigDevToneEntry 2} pktcSigDevToneFreqCounter OBJECT-TYPE SYNTAX Unsigned32(1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the number of consecutive multi-frequency tones for the particular tone type in the multi-frequency table (pktcSigDevMultiFreqToneTable). Such a sequence of the consecutive multi-frequency tones forms the tone group for the particular tone type in the pktcSigDevToneTable." ::={ pktcSigDevToneEntry 3} pktcSigDevToneWholeToneRepeatCount OBJECT-TYPE SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the repeat count, which signifies how many times to repeat the entire on-off cadence sequence. Setting this object may result in a cadence duration longer or shorter than the overall signal duration specified by the time out (TO) object for a particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised, and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, Beacham, et al. Standards Track [Page 37] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signaling so that the TO duration setting should always be longer than the desired repeat count-time duration." ::={ pktcSigDevToneEntry 4 } pktcSigDevToneSteady OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the steady tone status. A value of 'true(1)' indicates that the steady tone is applied, and a value of 'false(2)' indicates otherwise. Devices must play out the on-off cadence sequence for the number of times indicated by the MIB object 'pktcSigDevToneWholeToneRepeatCount' prior to applying the last tone steadily, indefinitely. If the MIB table 'pktcSigDevToneTable' contains multiple rows with this Object set to a value of 'true(1)', the steady tone is applied to the last repeating frequency group of the tone. Setting this MIB object may result in a tone duration that is longer or shorter than the overall signal duration specified by the time out (TO) MIB object for a particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised, and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signaling that The TO duration setting should always be longer than the desired repeat count-time duration, plus the desired maximum steady tone period." ::={ pktcSigDevToneEntry 5 } pktcSigDevMultiFreqToneTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigDevMultiFreqToneEntry MAX-ACCESS not-accessible STATUS current Beacham, et al. Standards Track [Page 38] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 DESCRIPTION " This MIB table defines the characteristics of tones with multiple frequencies. The constraints imposed on the tones by the MIB table pktcSigDevToneTable need to be considered for MIB objects in this table as well. The MTA MUST populate the corresponding row(s) of the pktcSigDevMultiFreqToneTable for each tone defined in the pktcSigDevToneTable. The contents of the table may be provisioned via MTA configuration." REFERENCE "PacketCable NCS Specification, ETSI-TS-101-909-4 Specification." ::= { pktcSigDevObjects 33 } pktcSigDevMultiFreqToneEntry OBJECT-TYPE SYNTAX PktcSigDevMultiFreqToneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The different tone types with multiple frequencies that can be provisioned based on country-specific needs." INDEX {pktcSigDevToneType, pktcSigDevToneNumber} ::= { pktcSigDevMultiFreqToneTable 1 } PktcSigDevMultiFreqToneEntry ::= SEQUENCE { pktcSigDevToneNumber Unsigned32, pktcSigDevToneFirstFreqValue Unsigned32, pktcSigDevToneSecondFreqValue Unsigned32, pktcSigDevToneThirdFreqValue Unsigned32, pktcSigDevToneFourthFreqValue Unsigned32, pktcSigDevToneFreqMode INTEGER, pktcSigDevToneFreqAmpModePrtg Unsigned32, pktcSigDevToneDbLevel TenthdBm, pktcSigDevToneFreqOnDuration Unsigned32, pktcSigDevToneFreqOffDuration Unsigned32, pktcSigDevToneFreqRepeatCount Unsigned32 } pktcSigDevToneNumber OBJECT-TYPE SYNTAX Unsigned32(1..8) MAX-ACCESS not-accessible STATUS current DESCRIPTION Beacham, et al. Standards Track [Page 39] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 "This MIB object represents the frequency reference of a multi-frequency tone." ::={ pktcSigDevMultiFreqToneEntry 1} pktcSigDevToneFirstFreqValue OBJECT-TYPE SYNTAX Unsigned32(0..4000) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the value of the first frequency of a tone type. A value of zero implies absence of the referenced frequency." ::={ pktcSigDevMultiFreqToneEntry 2} pktcSigDevToneSecondFreqValue OBJECT-TYPE SYNTAX Unsigned32(0..4000) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the value of the second frequency of a tone type. A value of zero implies absence of the referenced frequency." ::={ pktcSigDevMultiFreqToneEntry 3} pktcSigDevToneThirdFreqValue OBJECT-TYPE SYNTAX Unsigned32(0..4000) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the value of the third frequency of a tone type. A value of zero implies absence of the referenced frequency." ::={ pktcSigDevMultiFreqToneEntry 4} pktcSigDevToneFourthFreqValue OBJECT-TYPE SYNTAX Unsigned32(0..4000) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the value of the fourth frequency of a tone type. A value of zero implies absence of the referenced frequency." ::={ pktcSigDevMultiFreqToneEntry 5} pktcSigDevToneFreqMode OBJECT-TYPE SYNTAX INTEGER { firstModulatedBySecond(1), summation(2) Beacham, et al. Standards Track [Page 40] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 } MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object provides directive on the modulation or summation of the frequencies involved in the tone. It is to be noted that while summation can be done without any constraint on the number of frequencies, the modulation (amplitude) holds good only when there are two frequencies (first and second). Thus: - If the mode is set to a value of 'firstModulatedBySecond(1)', the first frequency MUST be modulated by the second, and the remaining frequencies (third and fourth) ignored. The percentage of amplitude modulation to be applied is defined by the MIB object pktcSigDevToneFreqAmpModePrtg. - If the mode is set to a value of 'summation(2)', all the frequencies MUST be summed without any modulation. " ::={ pktcSigDevMultiFreqToneEntry 6} pktcSigDevToneFreqAmpModePrtg OBJECT-TYPE SYNTAX Unsigned32(0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the percentage of amplitude modulation applied to the second frequency when the MIB object pktcSigDevToneFreqMode is set to a value of 'firstModulatedBySecond (1)'. If the MIB object pktcSigDevToneFreqMode is set to value of 'summation (2)', then this MIB object MUST be ignored." ::={ pktcSigDevMultiFreqToneEntry 7} pktcSigDevToneDbLevel OBJECT-TYPE SYNTAX TenthdBm (-250..-110) UNITS "1/10 of a dBm" MAX-ACCESS read-only Beacham, et al. Standards Track [Page 41] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 STATUS current DESCRIPTION "This MIB object contains the decibel level for each analog signal (tone) that is locally generated (versus in-band supervisory tones) and sourced to the a-b terminals (TE connection point). Each tone in itself may consist of multiple frequencies, as defined by the MIB table pktcSigDevMultiFreqToneTable. This MIB object reflects the desired level at the Telco (POTS) a-b (T/R) terminals, including the effect of any MTA receiver gain (loss). This is required so that locally generated tones are consistent with remotely generated in-band tones at the a-b terminals, consistent with user expectations. This MIB object must be set for each tone. When tones are formed by combining multi-frequencies, the level of each frequency shall be set so as to result in the tone level specified in this object at the a-b (T/R) terminals. The wide range of levels for this Object is required to provide signal-generator levels across the wide range of gains (losses) -- but does not imply the entire range is to be achievable given the range of gains (losses) in the MTA." DEFVAL { -120 } ::={ pktcSigDevMultiFreqToneEntry 8} pktcSigDevToneFreqOnDuration OBJECT-TYPE SYNTAX Unsigned32(0..5000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the duration for which the frequency reference corresponding to the tone type is turned on." ::={ pktcSigDevMultiFreqToneEntry 9} pktcSigDevToneFreqOffDuration OBJECT-TYPE SYNTAX Unsigned32(0..5000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the duration for which the Beacham, et al. Standards Track [Page 42] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 frequency reference corresponding to the tone type is turned off." ::={ pktcSigDevMultiFreqToneEntry 10} pktcSigDevToneFreqRepeatCount OBJECT-TYPE SYNTAX Unsigned32(0..5000) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object indicates the number of times to repeat the cadence cycle represented by the on/off durations (refer to the MIB objects pktcSigDevToneFreqOnDuration and pktcSigDevToneFreqOffDuration). Setting this object may result in a tone duration that is longer or shorter than the overall signal duration specified by the time out (TO) object for the corresponding tone type. If the value of this MIB Object indicates a longer duration than that specified by the TO, the latter overrules the former, and the desired tone duration will be truncated according to the TO. However, if the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended, to ensure proper telephony signaling, that the TO duration setting should always be longer than the desired repeat count-time duration. A value of zero means the tone sequence is to be played once but not repeated." ::={ pktcSigDevMultiFreqToneEntry 11} pktcSigDevCidDelayAfterLR OBJECT-TYPE SYNTAX Unsigned32 (300..800) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the delay between the end of the Line Reversal and the start of the FSK or DTMF signal. This MIB object is used only when pktcSigDevCidMode is set to a value of 'lrETS'. This timing has a range of 300 to 800 ms. Beacham, et al. Standards Track [Page 43] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevCidMode), and MUST be followed: Value of pktcSigDevCidMode Default value duringringingETS any value (not used) dtAsETS any value (not used) rpAsETS any value (not used) lrAsETS any value (not used) lrETS 400 An attempt to set this object while the value of pktcSigDevCidMode is not set to a value of 'lrETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." DEFVAL { 400 } ::= {pktcSigDevObjects 34 } pktcSigDevCidDtmfStartCode OBJECT-TYPE SYNTAX DtmfCode MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies optional start codes used when the MIB object pktcSigDevCidSigProtocol is set to a value of 'dtmf(2)'. Different countries define different caller id signaling codes to support caller identification. When Dual-Tone Multi-Frequency (DTMF) is used, the caller id digits are preceded by a 'start code' digit, followed by the digit transmission sequence ... (where Sx represents the digits 0-9), and terminated by the 'end code' digit. For example, ... ... ... . The start code for calling number delivery may be DTMF 'A' or 'D'. The start code for redirecting a number may be DTMF 'D'. The DTMF code 'B' may be sent by the network as a start code for the transfer of information values, through which special events can be indicated to the user. In some countries, the '*' or '#' may be used instead of 'A', 'B', 'C', or 'D'. The value of this MIB object MUST NOT persist across MTA Beacham, et al. Standards Track [Page 44] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 reboots." REFERENCE "ETSI-EN-300-659-1 specification" DEFVAL {dtmfcodeA} ::= { pktcSigDevObjects 35 } pktcSigDevCidDtmfEndCode OBJECT-TYPE SYNTAX DtmfCode MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies optional end codes used when the pktcSigDevCidSigProtocol is set to a value of 'dtmf(2)'. Different countries define different caller id signaling protocols to support caller identification. When Dual-Tone Multi-Frequency (DTMF) is used, the caller id digits are preceded by a 'start code' digit, followed by the digit transmission sequence ... (where Sx represents the digits 0-9), and terminated by the 'end code' digit. For example, ... ... ... . The DTMF code 'C' may be sent by the network as an end code for the transfer of information values, through which special events can be indicated to the user. In some countries, the '*' or '#' may be used instead of 'A', 'B', 'C', or 'D'. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 specification" DEFVAL {dtmfcodeC} ::= { pktcSigDevObjects 36 } pktcSigDevVmwiSigProtocol OBJECT-TYPE SYNTAX PktcSubscriberSideSigProtocol MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the subscriber line protocol used for signaling the information on Visual Message Waiting Indicator (VMWI). Different countries define different VMWI signaling protocols to support VMWI service. Beacham, et al. Standards Track [Page 45] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Frequency shift keying (FSK) is most commonly used. DTMF is an alternative. The value of this MIB object MUST NOT persist across MTA reboots." DEFVAL { fsk } ::= { pktcSigDevObjects 37 } pktcSigDevVmwiDelayAfterLR OBJECT-TYPE SYNTAX Unsigned32 (0|300..800) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the delay between the end of the Line Reversal and the start of the FSK or DTMF signal. This object is only used when pktcSigDevVmwiMode is set to a value of 'lrETS'. This timing has a range of 300 to 800 ms. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevVmwiMode), and MUST be followed: Value of pktcSigDevVmwiMode Default value duringringingETS any value (not used) dtAsETS any value (not used) rpAsETS any value (not used) lrAsETS any value (not used) lrETS 400 An attempt to set this object while the value of pktcSigDevVmwiMode is not 'lrETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." DEFVAL {400} ::= {pktcSigDevObjects 38 } pktcSigDevVmwiDtmfStartCode OBJECT-TYPE SYNTAX DtmfCode MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies optional start codes used when Beacham, et al. Standards Track [Page 46] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 the pktcSigDevVmwiSigProtocol is set to a value of 'dtmf(2)'. Different countries define different On Hook Data Transmission Protocol signaling codes to support VMWI. When Dual-Tone Multi-Frequency (DTMF) is used, the VMWI digits are preceded by a 'start code' digit, followed by the digit transmission sequence ... (where Sx represents the digits 0-9), and terminated by the 'end code' digit. For example, ... ... ... . The start code for redirecting VMWI may be DTMF 'D' The DTMF code 'B' may be sent by the network as a start code for the transfer of information values, through which special events can be indicated to the user. In some countries, the '*' or '#' may be used instead of 'A', 'B', 'C', or 'D'. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 specification" DEFVAL {dtmfcodeA} ::= { pktcSigDevObjects 39 } pktcSigDevVmwiDtmfEndCode OBJECT-TYPE SYNTAX DtmfCode MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies an optional end code used when the pktcSigDevVmwiSigProtocol is set to a value of 'dtmf(2)'. Different countries define different on-hook Data Transmission Protocol signaling codes to support VMWI. When Dual-Tone Multi-Frequency (DTMF) is used, the VMWI digits are preceded by a 'start code' digit, followed by the digit transmission sequence ... (where Sx represents the digits 0-9), and terminated by the 'end code' digit. For example, ... ... ... . Beacham, et al. Standards Track [Page 47] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The DTMF code 'C' may be sent by the network as an end code for the transfer of information values, through which special events can be indicated to the user. In some countries, the '*' or '#' may be used instead of 'A', 'B', 'C', or 'D'. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 specification" DEFVAL {dtmfcodeC} ::= { pktcSigDevObjects 40 } pktcSigDevrpAsDtsDuration OBJECT-TYPE SYNTAX Unsigned32 (0|200..500) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the duration of the rpASDTS ring pulse prior to the start of the transmission of the FSK or DTMF containing the caller id information. It is only used when pktcSigDevCidMode is set to a value of 'rpAsETS'. The following table defines the default values for this MIB object, depending on the signal type (pktcSigDevCidMode), and MUST be followed: Value of pktcSigDevCidMode Default value duringringingETS any value (not used) dtAsETS any value (not used) rpAsETS 250 lrAsETS any value (not used) lrETS any value (not used) An attempt to set this object while the value of pktcSigDevCidMode is not 'rpAsETS' will result in an 'inconsistentValue' error. The value of this MIB object MUST NOT persist across MTA reboots." REFERENCE "ETSI-EN-300-659-1 Specification and Belgacom BGC_D_48_9811_30_09_EDOC version 3.3" DEFVAL { 250 } ::= {pktcSigDevObjects 41 } Beacham, et al. Standards Track [Page 48] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 -- -- The Endpoint Config Table is used to define attributes that -- are specific to connection EndPoints. -- pktcSigEndPntConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigEndPntConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table describes the information pertaining to each endpoint of the MTA. All entries in this table represent the provisioned endpoints provisioned with the information required by the MTA to maintain the NCS protocol communication with the CMS. Each endpoint can be assigned to its own CMS. If the specific endpoint does not have the corresponding CMS information in this table, the endpoint is considered as not provisioned with voice services. Objects in this table do not persist across MTA reboots." ::= { pktcSigEndPntConfigObjects 1 } pktcSigEndPntConfigEntry OBJECT-TYPE SYNTAX PktcSigEndPntConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in the pktcSigEndPntConfigTable represents required signaling parameters for the specific endpoint provisioned with voice services. The conceptual rows MUST NOT persist across MTA reboots." INDEX { ifIndex } ::= { pktcSigEndPntConfigTable 1 } PktcSigEndPntConfigEntry ::= SEQUENCE { pktcSigEndPntConfigCallAgentId SnmpAdminString, pktcSigEndPntConfigCallAgentUdpPort InetPortNumber, pktcSigEndPntConfigPartialDialTO Unsigned32, pktcSigEndPntConfigCriticalDialTO Unsigned32, pktcSigEndPntConfigBusyToneTO Unsigned32, pktcSigEndPntConfigDialToneTO Unsigned32, pktcSigEndPntConfigMessageWaitingTO Unsigned32, pktcSigEndPntConfigOffHookWarnToneTO Unsigned32, pktcSigEndPntConfigRingingTO Unsigned32, pktcSigEndPntConfigRingBackTO Unsigned32, pktcSigEndPntConfigReorderToneTO Unsigned32, pktcSigEndPntConfigStutterDialToneTO Unsigned32, Beacham, et al. Standards Track [Page 49] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigEndPntConfigTSMax Unsigned32, pktcSigEndPntConfigMax1 Unsigned32, pktcSigEndPntConfigMax2 Unsigned32, pktcSigEndPntConfigMax1QEnable TruthValue, pktcSigEndPntConfigMax2QEnable TruthValue, pktcSigEndPntConfigMWD Unsigned32, pktcSigEndPntConfigTdinit Unsigned32, pktcSigEndPntConfigTdmin Unsigned32, pktcSigEndPntConfigTdmax Unsigned32, pktcSigEndPntConfigRtoMax Unsigned32, pktcSigEndPntConfigRtoInit Unsigned32, pktcSigEndPntConfigLongDurationKeepAlive Unsigned32, pktcSigEndPntConfigThist Unsigned32, pktcSigEndPntConfigStatus RowStatus, pktcSigEndPntConfigCallWaitingMaxRep Unsigned32, pktcSigEndPntConfigCallWaitingDelay Unsigned32, pktcSigEndPntStatusCallIpAddressType InetAddressType, pktcSigEndPntStatusCallIpAddress InetAddress, pktcSigEndPntStatusError INTEGER, pktcSigEndPntConfigMinHookFlash Unsigned32, pktcSigEndPntConfigMaxHookFlash Unsigned32, pktcSigEndPntConfigPulseDialInterdigitTime Unsigned32, pktcSigEndPntConfigPulseDialMinMakeTime Unsigned32, pktcSigEndPntConfigPulseDialMaxMakeTime Unsigned32, pktcSigEndPntConfigPulseDialMinBreakTime Unsigned32, pktcSigEndPntConfigPulseDialMaxBreakTime Unsigned32 } pktcSigEndPntConfigCallAgentId OBJECT-TYPE SYNTAX SnmpAdminString(SIZE (3..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains a string indicating the call agent name (e.g., ca@example.com). The call agent name, after the character '@', MUST be a fully qualified domain name (FQDN) and MUST have a corresponding pktcMtaDevCmsFqdn entry in the pktcMtaDevCmsTable. The object pktcMtaDevCmsFqdn is defined in the PacketCable MIBMTA Specification. For each particular endpoint, the MTA MUST use the current value of this object to communicate with the corresponding CMS. The MTA MUST update this object with the value of the 'Notified Entity' parameter of the NCS message. Because of the high importance of this object to the ability of the MTA to maintain reliable NCS communication with the CMS, it is highly recommended not to change this object's value using SNMP during normal operation." Beacham, et al. Standards Track [Page 50] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 ::= { pktcSigEndPntConfigEntry 1 } pktcSigEndPntConfigCallAgentUdpPort OBJECT-TYPE SYNTAX InetPortNumber (1025..65535) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the current value of the User Datagram Protocol (UDP) receive port on which the call agent will receive NCS from the endpoint. For each particular endpoint, the MTA MUST use the current value of this object to communicate with the corresponding CMS. The MTA MUST update this object with the value of the 'Notified Entity' parameter of the NCS message. If the Notified Entity parameter does not contain a CallAgent port, the MTA MUST update this object with the default value of 2727. Because of the high importance of this object to the ability of the MTA to maintain reliable NCS communication with the CMS, it is highly recommended not to change this object's value using SNMP during normal operation." REFERENCE "PacketCable NCS Specification" DEFVAL { 2727 } ::= { pktcSigEndPntConfigEntry 2 } pktcSigEndPntConfigPartialDialTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the value of the partial dial time out. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 16 } ::= { pktcSigEndPntConfigEntry 3 } pktcSigEndPntConfigCriticalDialTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" Beacham, et al. Standards Track [Page 51] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the value of the critical dial time out. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 4 } ::= { pktcSigEndPntConfigEntry 4 } pktcSigEndPntConfigBusyToneTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for busy tone. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 30 } ::= { pktcSigEndPntConfigEntry 5 } pktcSigEndPntConfigDialToneTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for dial tone. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If Beacham, et al. Standards Track [Page 52] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 16 } ::= { pktcSigEndPntConfigEntry 6 } pktcSigEndPntConfigMessageWaitingTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for message waiting indicator. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Manager application, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 16 } ::= { pktcSigEndPntConfigEntry 7 } pktcSigEndPntConfigOffHookWarnToneTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for the off-hook warning tone. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Manager Beacham, et al. Standards Track [Page 53] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 application, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 0 } ::= { pktcSigEndPntConfigEntry 8 } pktcSigEndPntConfigRingingTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for ringing. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 180 } ::= { pktcSigEndPntConfigEntry 9 } pktcSigEndPntConfigRingBackTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for ring back. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time Beacham, et al. Standards Track [Page 54] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 180 } ::= { pktcSigEndPntConfigEntry 10 } pktcSigEndPntConfigReorderToneTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for reorder tone. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 30 } ::= { pktcSigEndPntConfigEntry 11 } pktcSigEndPntConfigStutterDialToneTO OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default time out value for stutter dial tone. The MTA MUST NOT update this object with the value provided in the NCS message (if present). If the value of the object is modified by the SNMP Management Station, the MTA MUST use the new value as a default only for a new signal requested by the NCS message. The time out (TO) elements are intended to limit the time a tone or frequency is generated. When this MIB object is set to a value of '0', the MTA MUST NOT generate the Beacham, et al. Standards Track [Page 55] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 corresponding frequency or tone, regardless of the definitions pertaining to frequency, tone duration, or cadence." REFERENCE "PacketCable NCS Specification" DEFVAL { 16 } ::= { pktcSigEndPntConfigEntry 12 } pktcSigEndPntConfigTSMax OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This MIB object is used as part of an NCS retransmission algorithm. Prior to any retransmission, the MTA must check to make sure that the time elapsed since the sending of the initial datagram does not exceed the value specified by this MIB object. If more than Tsmax time has elapsed, then the retransmissions MUST cease. Refer to the MIB object pktcSigEndPntConfigThist for information on when the endpoint becomes disconnected." REFERENCE "PacketCable NCS Specification" DEFVAL { 20 } ::= { pktcSigEndPntConfigEntry 13 } pktcSigEndPntConfigMax1 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the suspicious error threshold for signaling messages. The pktcSigEndPntConfigMax1 object indicates the retransmission threshold at which the MTA MAY actively query the domain name server (DNS) in order to detect the possible change of call agent interfaces." REFERENCE "PacketCable NCS Specification" DEFVAL { 5 } ::= { pktcSigEndPntConfigEntry 14 } pktcSigEndPntConfigMax2 OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION Beacham, et al. Standards Track [Page 56] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 "This object contains the disconnect error threshold for signaling messages. The pktcSigEndPntConfigMax2 object indicates the retransmission threshold at which the MTA SHOULD contact the DNS one more time to see if any other interfaces to the call agent have become available." REFERENCE "PacketCable NCS Specification" DEFVAL { 7 } ::= { pktcSigEndPntConfigEntry 15 } pktcSigEndPntConfigMax1QEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables/disables the Max1 domain name server (DNS) query operation when the pktcSigEndPntConfigMax1 threshold has been reached. A value of true(1) indicates enabling, and a value of false(2) indicates disabling." DEFVAL { true } ::= { pktcSigEndPntConfigEntry 16 } pktcSigEndPntConfigMax2QEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables/disables the Max2 domain name server (DNS) query operation when the pktcSigEndPntConfigMax2 threshold has been reached. A value of true(1) indicates enabling, and a value of false(2) indicates disabling." DEFVAL { true } ::= { pktcSigEndPntConfigEntry 17 } pktcSigEndPntConfigMWD OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Waiting Delay (MWD) contains the maximum number of seconds an MTA waits, after powering on, before initiating the restart procedure with the call agent." REFERENCE "PacketCable NCS Specification" DEFVAL { 600 } Beacham, et al. Standards Track [Page 57] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 ::= { pktcSigEndPntConfigEntry 18 } pktcSigEndPntConfigTdinit OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This MIB object represents the 'disconnected' initial waiting delay within the context of an MTA's 'disconnected procedure'. The 'disconnected procedure' is initiated when an endpoint becomes 'disconnected' while attempting to communicate with a call agent. The 'disconnected timer' associated with the 'disconnected Procedure' is initialized to a random value, uniformly distributed between zero and the value contained in this MIB object. For more information on the usage of this timer, please refer to the PacketCable NCS Specification." REFERENCE "PacketCable NCS Specification" DEFVAL { 15 } ::= { pktcSigEndPntConfigEntry 19 } pktcSigEndPntConfigTdmin OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This MIB object represents the 'disconnected' minimum waiting delay within the context of an MTA's 'disconnected procedure', specifically when local user activity is detected. The 'disconnected procedure' is initiated when an endpoint becomes 'disconnected' while attempting to communicate with a call agent. For more information on the usage of this timer, please refer to the PacketCable NCS Specification." REFERENCE "PacketCable NCS Specification" DEFVAL { 15 } ::= { pktcSigEndPntConfigEntry 20 } pktcSigEndPntConfigTdmax OBJECT-TYPE SYNTAX Unsigned32 Beacham, et al. Standards Track [Page 58] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the maximum number of seconds the MTA waits, after a disconnect, before initiating the disconnected procedure with the call agent. " REFERENCE "PacketCable NCS Specification" DEFVAL { 600 } ::= { pktcSigEndPntConfigEntry 21 } pktcSigEndPntConfigRtoMax OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum number of seconds the MTA waits for a response to an NCS message before initiating a retransmission." REFERENCE "PacketCable NCS Specification" DEFVAL { 4 } ::= { pktcSigEndPntConfigEntry 22 } pktcSigEndPntConfigRtoInit OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the initial number of seconds for the retransmission timer." REFERENCE "PacketCable NCS Specification" DEFVAL { 200 } ::= { pktcSigEndPntConfigEntry 23 } pktcSigEndPntConfigLongDurationKeepAlive OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-create STATUS current DESCRIPTION " Specifies a time out value, in minutes, for sending long duration call notification messages." Beacham, et al. Standards Track [Page 59] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 REFERENCE "PacketCable NCS Specification" DEFVAL { 60 } ::= { pktcSigEndPntConfigEntry 24 } pktcSigEndPntConfigThist OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " Time out period, in seconds, before no response is declared." REFERENCE "PacketCable NCS Specification" DEFVAL { 30 } ::= { pktcSigEndPntConfigEntry 25 } pktcSigEndPntConfigStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the Row Status associated with the pktcSigEndPntConfigTable. There are no restrictions or dependencies amidst the columnar objects before this row can be activated or for modifications of the columnar objects when this object is set to a value of 'active(1)." ::= { pktcSigEndPntConfigEntry 26 } pktcSigEndPntConfigCallWaitingMaxRep OBJECT-TYPE SYNTAX Unsigned32 (0..10) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the default value of the maximum number of repetitions of the Call Waiting tone that the MTA will play from a single CMS request. The MTA MUST NOT update this object with the information provided in the NCS message (if present). If the value of the object is modified by the SNMP Manager application, the MTA MUST use the new value as a default only for a new signal requested by the NCS message." DEFVAL { 1 } ::= { pktcSigEndPntConfigEntry 27 } pktcSigEndPntConfigCallWaitingDelay OBJECT-TYPE SYNTAX Unsigned32 (1..100) Beacham, et al. Standards Track [Page 60] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the delay between repetitions of the Call Waiting tone that the MTA will play from a single CMS request." DEFVAL { 10 } ::= { pktcSigEndPntConfigEntry 28 } pktcSigEndPntStatusCallIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the type of Internet address contained in the MIB object 'pktcSigEndPntStatusCallIpAddress'. Since pktcSigEndPntStatusCallIpAddress is expected to contain an IP address, a value of dns(16) is disallowed." ::= { pktcSigEndPntConfigEntry 29 } pktcSigEndPntStatusCallIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION " This MIB object contains the chosen IP address of the CMS currently being used for the corresponding endpoint. The device determines the IP address by using DNS to resolve the IP address of the CMS from the FQDN stored in the MIB object 'pktcSigEndPntConfigCallAgentId'. The processes are outlined in the PacketCable NCS and Security specifications, and MUST be followed by the MTA. The IP address type contained in this MIB object is indicated by pktcSigEndPntStatusCallIpAddressType." REFERENCE "PacketCable NCS Specification; PacketCable Security specification, [PKT-SP-SEC]." ::= { pktcSigEndPntConfigEntry 30 } pktcSigEndPntStatusError OBJECT-TYPE SYNTAX INTEGER { operational (1), noSecurityAssociation (2), Beacham, et al. Standards Track [Page 61] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 disconnected (3) } MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the error status for this interface. The operational status indicates that all operations necessary to put the line in service have occurred, and the CMS has acknowledged the Restart In Progress (RSIP) message successfully. If pktcMtaDevCmsIpsecCtrl is enabled for the associated call agent, the noSecurityAssociation status indicates that no Security Association (SA) yet exists for this endpoint. If pktcMtaDevCmsIpsecCtrl is disabled for the associated call agent, the noSecurityAssociation status is not applicable and should not be used by the MTA. The disconnected status indicates one of the following two: If pktcMtaDevCmsIpsecCtrl is disabled, then no security association is involved with this endpoint. The NCS signaling software is in process of establishing the NCS signaling link via an RSIP exchange. Otherwise, when pktcMtaDevCmsIpsecCtrl is enabled, security Association has been established, and the NCS signaling software is in process of establishing the NCS signaling link via an RSIP exchange." ::= { pktcSigEndPntConfigEntry 31 } pktcSigEndPntConfigMinHookFlash OBJECT-TYPE SYNTAX Unsigned32 (20..1550) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the minimum time a line needs to be on-hook for a valid hook flash. The value of this object MUST be greater than the value of pktcSigEndPntConfigPulseDialMaxBreakTime. The value of pktcSigEndPntConfigMinHookFlash MUST be less than pktcSigEndPntConfigMaxHookFlash. This object MUST only be set via the MTA configuration during the provisioning process. Furthermore, given the possibility for the 'pulse dial' and 'hook flash' to overlap, the value of this object MUST be greater than the value contained by the MIB Object 'pktcSigEndPntConfigPulseDialMaxMakeTime'." DEFVAL { 300 } ::= { pktcSigEndPntConfigEntry 32 } Beacham, et al. Standards Track [Page 62] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigEndPntConfigMaxHookFlash OBJECT-TYPE SYNTAX Unsigned32 (20..1550) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the maximum time a line needs to be on-hook for a valid hook flash. The value of pktcSigEndPntConfigMaxHookFlash MUST be greater than pktcSigEndPntConfigMinHookFlash. This object MUST only be set via the MTA configuration during the provisioning process." DEFVAL { 800 } ::= { pktcSigEndPntConfigEntry 33 } pktcSigEndPntConfigPulseDialInterdigitTime OBJECT-TYPE SYNTAX Unsigned32 (100..1500) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the pulse dial inter-digit time out. This object MUST only be set via the MTA configuration during the provisioning process." DEFVAL { 100 } ::= { pktcSigEndPntConfigEntry 34 } pktcSigEndPntConfigPulseDialMinMakeTime OBJECT-TYPE SYNTAX Unsigned32 (20..200) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the minimum make pulse width for the dial pulse. The value of pktcSigEndPntConfigPulseDialMinMakeTime MUST be less than pktcSigEndPntConfigPulseDialMaxMakeTime. This object MUST only be set via the MTA configuration during the provisioning process." DEFVAL { 25 } ::= { pktcSigEndPntConfigEntry 35 } pktcSigEndPntConfigPulseDialMaxMakeTime OBJECT-TYPE SYNTAX Unsigned32 (20..200) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the maximum make pulse width for the dial pulse. Beacham, et al. Standards Track [Page 63] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The value of pktcSigEndPntConfigPulseDialMaxMakeTime MUST be greater than pktcSigEndPntConfigPulseDialMinMakeTime. This object MUST only be provided via the configuration file during the provisioning process. Furthermore, given the possibility for the 'pulse dial' and 'hook flash' to overlap, the value of this object MUST be less than the value contained by the MIB object pktcSigEndPntConfigMinHookFlash." DEFVAL { 55 } ::= { pktcSigEndPntConfigEntry 36 } pktcSigEndPntConfigPulseDialMinBreakTime OBJECT-TYPE SYNTAX Unsigned32 (20..200) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the minimum break pulse width for the dial pulse. The value of pktcSigEndPntConfigPulseDialMinBreakTime MUST be less than pktcSigEndPntConfigPulseDialMaxBreakTime. This object must only be provided via the configuration file during the provisioning process." DEFVAL { 45 } ::= { pktcSigEndPntConfigEntry 37 } pktcSigEndPntConfigPulseDialMaxBreakTime OBJECT-TYPE SYNTAX Unsigned32 (20..200) UNITS "Milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION " This is the maximum break pulse width for the dial pulse. The value of pktcSigEndPntConfigPulseDialMaxBreakTime MUST be greater than pktcSigEndPntConfigPulseDialMinBreakTime. This object MUST only be provided via the configuration file during the provisioning process." DEFVAL { 75 } ::= { pktcSigEndPntConfigEntry 38 } -- -- notification group is for future extension. -- pktcSigNotification OBJECT IDENTIFIER ::= { pktcIetfSigMib 0 } pktcSigConformance OBJECT IDENTIFIER ::= { pktcIetfSigMib 2 } pktcSigCompliances OBJECT IDENTIFIER ::= { pktcSigConformance 1 } pktcSigGroups OBJECT IDENTIFIER ::= { pktcSigConformance 2 } -- Beacham, et al. Standards Track [Page 64] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 -- compliance statements -- pktcSigBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION " The compliance statement for MTAs that implement NCS signaling." MODULE -- pktcIetfSigMib --- -- Unconditionally mandatory groups for all MTAs --- MANDATORY-GROUPS { pktcSigDeviceGroup, pktcSigEndpointGroup } --- -- Conditionally mandatory groups for MTAs --- GROUP pktcInternationalGroup DESCRIPTION " This group is mandatory only for MTAs implementing international telephony features." GROUP pktcLLinePackageGroup DESCRIPTION " This group is mandatory only for MTAs implementing the L line package." GROUP pktcELinePackageGroup DESCRIPTION " This group is mandatory only for MTAs implementing the E Line Package." ::={ pktcSigCompliances 1 } pktcSigDeviceGroup OBJECT-GROUP OBJECTS { pktcSigDevCodecMax, pktcSigDevEchoCancellation, pktcSigDevSilenceSuppression, pktcSigDevR0Cadence, pktcSigDevR1Cadence, pktcSigDevR2Cadence, pktcSigDevR3Cadence, Beacham, et al. Standards Track [Page 65] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigDevR4Cadence, pktcSigDevR5Cadence, pktcSigDevR6Cadence, pktcSigDevR7Cadence, pktcSigDevRgCadence, pktcSigDevRsCadence, pktcSigDefCallSigDscp, pktcSigDefMediaStreamDscp, pktcSigDevVmwiMode, pktcSigCapabilityType, pktcSigCapabilityVersion, pktcSigCapabilityVendorExt, pktcSigDefNcsReceiveUdpPort } STATUS current DESCRIPTION "Group of MIB objects containing signaling configuration information that is applicable per-device." ::= { pktcSigGroups 1 } pktcSigEndpointGroup OBJECT-GROUP OBJECTS { pktcSigEndPntConfigCallAgentId, pktcSigEndPntConfigCallAgentUdpPort, pktcSigEndPntConfigPartialDialTO, pktcSigEndPntConfigCriticalDialTO, pktcSigEndPntConfigBusyToneTO, pktcSigEndPntConfigDialToneTO, pktcSigEndPntConfigMessageWaitingTO, pktcSigEndPntConfigOffHookWarnToneTO, pktcSigEndPntConfigRingingTO, pktcSigEndPntConfigRingBackTO, pktcSigEndPntConfigReorderToneTO, pktcSigEndPntConfigStutterDialToneTO, pktcSigEndPntConfigTSMax, pktcSigEndPntConfigMax1, pktcSigEndPntConfigMax2, pktcSigEndPntConfigMax1QEnable, pktcSigEndPntConfigMax2QEnable, pktcSigEndPntConfigMWD, pktcSigEndPntConfigTdinit, pktcSigEndPntConfigTdmin, pktcSigEndPntConfigTdmax, pktcSigEndPntConfigRtoMax, pktcSigEndPntConfigRtoInit, pktcSigEndPntConfigLongDurationKeepAlive, pktcSigEndPntConfigThist, pktcSigEndPntConfigStatus, Beacham, et al. Standards Track [Page 66] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigEndPntConfigCallWaitingMaxRep, pktcSigEndPntConfigCallWaitingDelay, pktcSigEndPntStatusCallIpAddressType, pktcSigEndPntStatusCallIpAddress, pktcSigEndPntStatusError } STATUS current DESCRIPTION "Group of MIB objects containing signaling configuration information that is applicable per-endpoint." ::= { pktcSigGroups 2 } pktcInternationalGroup OBJECT-GROUP OBJECTS { pktcSigEndPntConfigMinHookFlash, pktcSigEndPntConfigMaxHookFlash, pktcSigEndPntConfigPulseDialInterdigitTime, pktcSigEndPntConfigPulseDialMinMakeTime, pktcSigEndPntConfigPulseDialMaxMakeTime, pktcSigEndPntConfigPulseDialMinBreakTime, pktcSigEndPntConfigPulseDialMaxBreakTime, pktcSigDevRingCadence, pktcSigDevCidSigProtocol, pktcSigDevCidDelayAfterLR, pktcSigDevCidDtmfStartCode, pktcSigDevCidDtmfEndCode, pktcSigDevVmwiSigProtocol, pktcSigDevVmwiDelayAfterLR, pktcSigDevVmwiDtmfStartCode, pktcSigDevVmwiDtmfEndCode, pktcSigDevrpAsDtsDuration, pktcSigDevCidMode, pktcSigDevCidAfterRing, pktcSigDevCidAfterDTAS, pktcSigDevCidAfterRPAS, pktcSigDevRingAfterCID, pktcSigDevCidDTASAfterLR, pktcSigDevVmwiMode, pktcSigDevVmwiAfterDTAS, pktcSigDevVmwiAfterRPAS, pktcSigDevVmwiDTASAfterLR, pktcSigPowerRingFrequency, pktcSigPulseSignalFrequency, pktcSigPulseSignalDbLevel, pktcSigPulseSignalDuration, pktcSigPulseSignalPulseInterval, pktcSigPulseSignalRepeatCount, pktcSigDevToneDbLevel, Beacham, et al. Standards Track [Page 67] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigDevToneFreqCounter, pktcSigDevToneWholeToneRepeatCount, pktcSigDevToneSteady, pktcSigDevToneFirstFreqValue, pktcSigDevToneSecondFreqValue, pktcSigDevToneThirdFreqValue, pktcSigDevToneFourthFreqValue, pktcSigDevToneFreqMode, pktcSigDevToneFreqAmpModePrtg, pktcSigDevToneFreqOnDuration, pktcSigDevToneFreqOffDuration, pktcSigDevToneFreqRepeatCount } STATUS current DESCRIPTION " Group of objects that extend the behavior of existing objects to support operations in the widest possible set of international marketplaces. Note that many of these objects represent a superset of behaviors described in other objects within this MIB module." ::= { pktcSigGroups 3 } pktcLLinePackageGroup OBJECT-GROUP OBJECTS { pktcSigDevR0Cadence, pktcSigDevR1Cadence, pktcSigDevR2Cadence, pktcSigDevR3Cadence, pktcSigDevR4Cadence, pktcSigDevR5Cadence, pktcSigDevR6Cadence, pktcSigDevR7Cadence, pktcSigDevRgCadence, pktcSigDevRsCadence } STATUS current DESCRIPTION "Group of Objects to support the L line package." ::= { pktcSigGroups 4 } pktcELinePackageGroup OBJECT-GROUP OBJECTS { pktcSigDevR0Cadence, pktcSigDevR1Cadence, pktcSigDevR2Cadence, pktcSigDevR3Cadence, pktcSigDevR4Cadence, pktcSigDevR5Cadence, Beacham, et al. Standards Track [Page 68] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 pktcSigDevR6Cadence, pktcSigDevR7Cadence, pktcSigDevRgCadence, pktcSigDevRsCadence, pktcSigPulseSignalFrequency, pktcSigPulseSignalDbLevel, pktcSigPulseSignalDuration, pktcSigPulseSignalPulseInterval, pktcSigPulseSignalRepeatCount, pktcSigDevRingCadence } STATUS current DESCRIPTION "Group of Objects to support the E line package." ::= { pktcSigGroups 5 } END 6. Examples This section provides a couple of examples, specifically related to the MIB tables pktcSigDevToneTable and pktcSigDevMultiFreqToneTable. Example A: Call Waiting Tone Defined per [ITU-T E.180]: 1) 400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm 2) 400 Hz AM modulated by 16 Hz, off for 400ms 3) 400 Hz not AM modulated, on for 50 ms at -4 dBm 4) 400 Hz not AM modulated, off for 450 ms 5) 400 Hz not AM modulated, on for 50 ms at -4 dBm 6) 400 Hz not AM modulated, off for 3450 ms 7) 400 Hz not AM modulated, on for 50 ms at -4 dBm 8) 400 Hz not AM modulated, off for 450 ms 9) 400 Hz not AM modulated, on for 50 ms at -4 dBm 10) 400 Hz not AM modulated, off for 3450 ms 11) not repeated, not continuous Beacham, et al. Standards Track [Page 69] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Assume userDefined1(18) is assigned to this tone: pktcSigDevMultiFreqToneTable: ToneType|F-1|F-2|F-3|F-4|F-Mode|ModePrtg|DbL|OnDur|OffDur|Rep-Count =================================================================== 18 400 16 0 0 1 90 -40 500 400 0 18 400 0 0 0 2 0 -40 50 450 0 18 400 0 0 0 2 0 -40 50 3450 0 18 400 0 0 0 2 0 -40 50 450 0 18 400 0 0 0 2 0 -40 50 3450 0 pktcSigDevToneTable: ToneType|ToneFreqGroup|ToneFreqCounter|ToneRep-Count|Steady ============================================================= 18 1 5 0 false(2) The single row of the pktcSigDevToneTable defines one multi-frequency group of five rows (ToneFreqCounter) defined in the pktcSigDevMultiFreqToneTable and instructs the MTA to play this group only once (non-repeatable as ToneRep-Count equals 0). Example B - Congestion Tone - congestion(17): Note: This example of an embedded cadence is based on an operator variation. 1) 400Hz on for 400ms -10 dBm 2) 400Hz off for 350ms 3) 400Hz on for 225ms -4 dBm 4) 400Hz off for 525ms 5) repeat (1) through (4) 5000 times or T0 time out (whichever is the shortest period) pktcSigDevMultiFreqToneTable: ToneType|F-1|F-2|F-3|F-4|F-Mode|ModePrtg|DbL|OnDur|OffDur|Rep-Count =================================================================== 17 400 0 0 0 2 0 -100 400 350 0 17 400 0 0 0 2 0 -40 225 525 0 pktcSigDevToneTable: ToneType|ToneFreqGroup|ToneFreqCounter|ToneRep-Count|Steady ============================================================= 17 1 2 5000 false(2) Beacham, et al. Standards Track [Page 70] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Example C - Call Waiting Tone - callWaiting1(9): 1) 16 Hz is modulated to carry the 400 Hz signal, ModulationRate within 85%, on for 500msec, at -25 dBm or more but less than -14 dBm 2) 16 Hz is modulated to carry the 400 Hz signal, off for 0 ~ 4 secs 3) 400 Hz not modulated, on for 50 ms at -25 dBm or more but less than -14 dBm 4) 400 Hz not modulated, off for 450ms 5) 400 Hz not modulated, on for 50 ms at -25 dBm or more but less than -14 dBm 6) 400 Hz not modulated, off for 3450ms ([4000 - (50+450+50)]) 7) Steps 3 thru 6 are repeated pktcSigDevMultiFreqToneTable: ToneType|F-1|F-2|F-3|F-4|F-Mode|ModePrtg|DbL|OnDur|OffDur|Rep-Count =================================================================== 9 1 400 16 0 0 1 85 -25 500 1000 0 9 2 400 0 0 0 2 0 -25 50 450 0 9 3 400 0 0 0 2 0 -25 50 3450 0 pktcSigDevToneTable: ToneType|ToneFreqGroup|ToneFreqCounter|ToneRep-Count|Steady ============================================================= 9 1 1 0 false(2) 9 2 2 1 false(2) The first row of the pktcSigDevToneTable table instructs the MTA to play one row (ToneFreqCounter) of the pktcSigDevMultiFreqToneTable table only once (non-repeatable as ToneRep-Count equals 0). The second row of the pktcSigDevToneTable table instructs the MTA to play the next two rows (ToneFreqCounter) of the pktcSigDevMultiFreqToneTable table and make this frequency group repeatable (ToneRep-Count is not 0). Beacham, et al. Standards Track [Page 71] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 7. Acknowledgments The authors would like to thank the members of the IETF IPCDN working group and the CableLabs PacketCable Provisioning focus team for their contributions, comments, and suggestions. Specifically, the following individuals are recognized: Angela Lyda Arris Interactive Romascanu, Dan Avaya Chad Griffiths Broadcom Corp. Eugene Nechamkin Broadcom Corp. Jean-Francois Mule CableLabs Matt A. Osman CableLabs Klaus Hermanns Cisco Systems, Inc. Rich Woundy Comcast Corp. Bert Wijnen Alcatel-Lucent Randy Presuhn Mindspring Phillip Freyman Motorola, Inc. Rick Vetter Motorola, Inc. Sasha Medvinsky Motorola, Inc. Wim De Ketelaere tComLabs David De Reu tComLabs Kristof Sercu tComLabs Roy Spitzer Telogy Networks, Inc. Itay Sherman Texas Instruments, Inc. Mauricio Sanchez Texas Instruments, Inc. Shivakumar Thangapandi Texas Instruments, Inc. Mike Heard Consultant The current editor (Sumanth Channabasappa) would like to recognize Phillip Freyman and Eugene Nechamkin for their contributions towards the international objects, and Stephane Bortzmeyer for assistance with the ABNF. The editor also extends appreciation to the IPCDN co-chairs (Jean- Francois Mule, Rich Woundy) and Dan Romascanu for the numerous reviews and valuable comments. Special appreciation is extended to Bert Wijnen, as the MIB doctor, for his ever-useful and constructive comments. Beacham, et al. Standards Track [Page 72] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The following Differentiated Services Code Point (DSCP) and mask objects are used to differentiate between various types of traffic in the service provider network: pktcSigDefCallSigDscp pktcSigDefMediaStreamDscp These objects may contain information that may be sensitive from a business perspective. For example, they may represent a customer's service contract that a service provider chooses to apply to a customer's ingress or egress traffic. If these objects are SET maliciously, it may permit unmarked or inappropriately marked signaling and media traffic to enter the service provider network, resulting in unauthorized levels of service for customers. The following objects determine ring cadence, repeatable characteristics, signal duration, and caller id subscriber line protocol for telephony operation: pktcSigDevR0Cadence pktcSigDevR1Cadence pktcSigDevR2Cadence pktcSigDevR3Cadence pktcSigDevR4Cadence pktcSigDevR5Cadence pktcSigDevR6Cadence pktcSigDevR7Cadence pktcSigDevRgCadence pktcSigDevRsCadence pktcSigDevCidSigProtocol pktcSigDevVmwiSigProtocol pktcSigPulseSignalDuration pktcSigPulseSignalPauseDuration If these objects are SET maliciously, it may result in unwanted operation, or a failure to obtain telephony service from client (MTA) devices. Beacham, et al. Standards Track [Page 73] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 The objects in the pktcSigEndPntConfigTable are used for endpoint signaling. The pktcSigEndPntConfigCallAgentId object contains the name of the call agent, which includes the call agent Fully Qualified Domain Name (FQDN). If this object is SET maliciously, the MTA will not be able to communicate with the call agent, resulting in a disruption of telephony service. The pktcSigEndPntConfigCallAgentUdpPort object identifies the UDP port for NCS traffic. If this object is SET maliciously, the call agent will not receive NCS traffic from the MTA, also resulting in a disruption of telephony service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The most sensitive is pktcSigEndPntStatusCallIpAddress within pktcSigEndPntConfigTable. This information itself may be valuable to would-be attackers. Other MIB Objects of similar sensitivity include pktcSigEndPntStatusError, which can provide useful information to MTA impersonators, and pktcSigDevCodecMax, which can provide useful information for planning Denial of Service (DoS) attacks on MTAs. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Beacham, et al. Standards Track [Page 74] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 9. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER Value ---------- ----------------------- pktcIetfSigMib { mib-2 169 } 10. References 10.1. Normative References [PKT-SP-MIB-SIG-1.0] PacketCable(TM) 1.0 Signaling MIB Specification, Issued, PKT-SP-MIB-SIG-I09-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives [PKT-SP-MIB-SIG-1.5] PacketCable(TM) 1.5 Signaling MIB Specification, Issued, PKT-SP-MIB-SIG1.5-I01-050128, January 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives [PKT-SP-SEC] PacketCable Security Specification, Issued, PKT-SP- SEC-I12-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives [ITU-T-J169] IPCablecom Network Call Signaling (NCS) MIB requirements, J.169, ITU-T, March, 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Beacham, et al. Standards Track [Page 75] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [PKT-SP-CODEC] PacketCable Audio/Video Codecs Specification PKT-SP- CODEC-IO5-040113. [PKT-SP-MGCP] PacketCable Network-Based Call Signaling Protocol Specification PKT-SP-EC-MGCP-I10-040402. [PKT-SP-PROV] PacketCable MTA Device Provisioning Specification PKT-SP-PROV-I10-040730. 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC4682] Nechamkin, E. and J-F. Mule, "Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices", RFC 4682, December 2006. Beacham, et al. Standards Track [Page 76] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 [ETSI-TS-101-909-4] ETSI TS 101 909-4:"Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 4: Network Call Signaling Protocol". [ETSI-TS-101-909-9] ETSI TS 101 909-9:"Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 9: IPCablecom Network Call Signalling (NCS) MIB Requirements". [ETSI-EN-300-001] ETSI EN 300-001 V1.5.1 (1998-10):"European Standard (Telecommunications series) Attachments to Public Switched Telephone Network (PSTN); General technical requirements for equipment connected to an analogue subscriber interface in the PSTN; Chapter 3: Ringing signal characteristics (national deviations are in Table 3.1.1)". [ETSI-EN-300-324-1] ETSI EN 300 324-1 V2.1.1 (2000-04):"V Interfaces at the digital Loop Exchange (LE); V5.1 interface for the support of Access Network (AN); Part 1: V5.1 interface specification". [ETSI-EN-300-659-1] ETSI EN 300 659-1: "Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 1: On hook data transmission". [ITU-T-E.180] ITU-T E.180: "Various Tones Used in National Networks, Supplement 2 to Recommendation E.180". [ETSI-TR-101-183] ETSI TR-101-183: "Public Switched Telephone Network (PSTN) Analogue Ringing Signals". Beacham, et al. Standards Track [Page 77] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Authors' Addresses Gordon Beacham Motorola, Inc. 6450 Sequence Drive, Bldg. 1 San Diego, CA 92121, USA Phone: +1 858-404-2334 EMail: gordon.beacham@motorola.com Satish Kumar Mudugere Eswaraiah Texas Instruments India (P) Ltd., Golf view, Wind Tunnel Road Murugesh Palya Bangalore 560 017, INDIA Phone: +91 80 5269451 EMail: satish.kumar@ti.com Sumanth Channabasappa Cable Television Laboratories, Inc. 858 Coal Creek Circle, Louisville, CO 80027, USA Phone: +1 303-661-3307 EMail: Sumanth@cablelabs.com Beacham, et al. Standards Track [Page 78] RFC 5098 PacketCable/IPCablecom NCS Signaling MIB February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Beacham, et al. Standards Track [Page 79] snmp-mibs-downloader-1.1/mibrfcs/rfc5131.txt0000644000000000000000000002555711402176072015572 0ustar Network Working Group D. McWalter, Ed. Request for Comments: 5131 Data Connection Ltd Category: Standards Track December 2007 A MIB Textual Convention for Language Tags 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. Abstract This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The Internet-Standard Management Framework . . . . . . . . . . 2 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 McWalter Standards Track [Page 1] RFC 5131 LANGTAG TC MIB December 2007 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It defines a textual convention to represent BCP 47 [RFC4646] language tags. The LangTag TEXTUAL-CONVENTION defined by this RFC replaces the similar LanguageTag TEXTUAL-CONVENTION defined by RFC 2932 [RFC2932]. The old LanguageTag TEXTUAL-CONVENTION is used by some existing MIB modules. New MIB modules should use the LangTag TEXTUAL-CONVENTION, which has been created (and is to be preferred) for the following reasons: o Its syntax description is current, and is more comprehensive. o It is short enough to use as an index object without subtyping, yet is of adequate length to represent any language tag in practice. o It is provided in a dedicated MIB module to simplify module dependencies. It is not possible to apply changes in syntax and length to an existing textual convention. This is why the creation of a new textual convention with a new name was necessary. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. McWalter Standards Track [Page 2] RFC 5131 LANGTAG TC MIB December 2007 4. Definitions LANGTAG-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] langTagTcMIB MODULE-IDENTITY LAST-UPDATED "200711090000Z" -- 9 November 2007 ORGANIZATION "IETF Operations and Management (OPS) Area" CONTACT-INFO "EMail: ops-area@ietf.org Home page: http://www.ops.ietf.org/" DESCRIPTION "This MIB module defines a textual convention for representing BCP 47 language tags." REVISION "200711090000Z" -- 9 November 2007 DESCRIPTION "Initial revision, published as RFC 5131. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 5131; see the RFC itself for full legal notices." ::= { mib-2 165 } LangTag ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "A language tag, constructed in accordance with BCP 47. Only lowercase characters are allowed. The purpose of this restriction is to provide unique language tags for use as indexes. BCP 47 recommends case conventions for user interfaces, but objects using this TEXTUAL-CONVENTION MUST use only lowercase. Values MUST be well-formed language tags, in conformance with the definition of well-formed tags in BCP 47. An implementation MAY further limit the values it accepts to those permitted by a 'validating' processor, as defined in BCP 47. In theory, BCP 47 language tags are of unlimited length. The language tag described in this TEXTUAL-CONVENTION is of limited length. The analysis of language tag lengths in BCP 47 confirms that this limit will not pose a problem in practice. In particular, this length is greater than the McWalter Standards Track [Page 3] RFC 5131 LANGTAG TC MIB December 2007 minimum requirements set out in Section 4.3.1. A zero-length language tag is not a valid language tag. This can be used to express 'language tag absent' where required, for example, when used as an index field." REFERENCE "RFC 4646 BCP 47" SYNTAX OCTET STRING (SIZE (0 | 2..63)) END 5. Security Considerations This MIB module does not define any management objects. Instead, it defines a textual convention that may be imported by other MIB modules and used for object definitions. Meaningful security considerations can only be written in the MIB modules that define management objects. This document therefore has no impact on the security of the Internet. 6. IANA Considerations LANGTAG-TC-MIB is rooted under the mib-2 subtree. IANA has assigned { mib-2 165 } to the LANGTAG-TC-MIB module specified in this document. 7. Acknowledgements This MIB module is a reworking of existing material from RFC 2932. This module was generated by editing together contributions from Randy Presuhn, Dan Romascanu, Bill Fenner, Juergen Schoenwaelder, Bert Wijnen, Doug Ewell, and Ira McDonald. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. McWalter Standards Track [Page 4] RFC 5131 LANGTAG TC MIB December 2007 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. 8.2. Informative References [RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Author's Address David McWalter (editor) Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom EMail: dmcw@dataconnection.com McWalter Standards Track [Page 5] RFC 5131 LANGTAG TC MIB December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. McWalter Standards Track [Page 6] snmp-mibs-downloader-1.1/mibrfcs/rfc5132.txt0000644000000000000000000035302411402176072015564 0ustar Network Working Group D. McWalter Request for Comments: 5132 Data Connection Ltd Obsoletes: 2932 D. Thaler Category: Standards Track Microsoft Corporation A. Kessler Cisco Systems December 2007 IP Multicast MIB 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The Internet-Standard Management Framework . . . . . . . . . . 2 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. IMPORTed MIB Modules and REFERENCE Clauses . . . . . . . . . . 4 6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 7.1. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7.2. Writeable Objects . . . . . . . . . . . . . . . . . . . . 54 7.3. Readable Objects . . . . . . . . . . . . . . . . . . . . . 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . . 57 McWalter, et al. Standards Track [Page 1] RFC 5132 IP MCAST MIB December 2007 1. Introduction This MIB describes objects used for managing IP multicast function, including IP multicast routing. These objects are independent of the specific multicast routing protocol in use. Managed objects specific to particular multicast protocols are defined elsewhere. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. History This document obsoletes [RFC2932]. The MIB module defined by this document is a re-working of the MIB module from [RFC2932], with changes that include the following: o This MIB module includes support for IPv6 addressing and the IPv6 scoped address architecture. [RFC2932] supported only IPv4. o This MIB module allows several multicast protocols to perform routing on a single interface, where [RFC2932] assumed each interface supported at most one multicast routing protocol. Multicast routing protocols are now per-route, see ipMcastRouteProtocol. o This MIB module includes objects that are not specific to multicast routing. It allows management of multicast function on systems that do not perform routing, whereas [RFC2932] was restricted to multicast routing. o This MIB module includes a table of Source-Specific Multicast (SSM) address ranges to which SSM semantics [RFC3569] should be applied. o This MIB module includes a table of local applications that are receiving multicast data. o This MIB module includes a table of multicast scope zones. 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. McWalter, et al. Standards Track [Page 2] RFC 5132 IP MCAST MIB December 2007 Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, ([RFC2578], [RFC2579] and [RFC2580]). 4. Overview This MIB module contains two scalars and eight tables. The tables are: 1. The IP Multicast Interface Table, which contains multicast information specific to interfaces. 2. The IP Multicast SSM Range Table, which contains one row per range of multicast group addresses to which Source-Specific Multicast semantics [RFC3569] should be applied. 3. The IP Multicast Route Table, which contains multicast routing information for IP datagrams sent by particular sources to the IP multicast groups known to a system. 4. The IP Multicast Routing Next Hop Table, which contains information about next-hops for the routing of IP multicast datagrams. Each entry is one of a list of next-hops on outgoing interfaces for particular sources sending to a particular multicast group address. 5. The IP Multicast Scope Boundary Table, which contains the boundaries configured for multicast scopes [RFC2365]. 6. The IP Multicast Scope Name Table, which contains human-readable names for multicast scopes. 7. The IP Multicast Local Listener Table, which contains identifiers for local applications that are receiving multicast data. 8. The IP Multicast Zone Table, which contains an entry for each scope zone known to a system, and maps each zone to the multicast address range that is the corresponding scope. This MIB module uses textual conventions defined in the IF-MIB [RFC2863], the INET-ADDRESS-MIB [RFC4001] and the IANA-RTPROTO-MIB. McWalter, et al. Standards Track [Page 3] RFC 5132 IP MCAST MIB December 2007 5. IMPORTed MIB Modules and REFERENCE Clauses The MIB modules defined in this document IMPORTs definitions normatively from the following MIB modules, beyond [RFC2578], [RFC2579], and [RFC2580]: HCNUM-TC [RFC2856], IF-MIB [RFC2863], IANA- RTPROTO-MIB, SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001], and LANGTAG-TC-MIB [RFC5131]. This MIB module also includes REFERENCE clauses that make normative references to Administratively Scoped IP Multicast [RFC2365], Unicast-Prefix-based IPv6 Multicast Addresses [RFC3306], IPv6 Scoped Address Architecture [RFC4007], and IPv6 Addressing Architecture [RFC4291]. Finally, this MIB module makes informative references to several RFCs in the text of DESCRIPTION clauses, including sysApplMIB [RFC2287], IP-MIB [RFC4293], Source-Specific Multicast [RFC3569], Protocol Independent Multicast-Sparse Mode version 2 (PIM-SMv2) Protocol Specification [RFC4601], Bidirectional Protocol Independent Multicast (BIDIR-PIM) [RFC5015], and Tags for Identifying Languages [RFC4646]. 6. Definitions IPMCAST-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32, Counter64, Gauge32, TimeTicks FROM SNMPv2-SMI -- [RFC2578] RowStatus, TruthValue, StorageType, TimeStamp FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] CounterBasedGauge64 FROM HCNUM-TC -- [RFC2856] InterfaceIndexOrZero, InterfaceIndex FROM IF-MIB -- [RFC2863] IANAipRouteProtocol, IANAipMRouteProtocol FROM IANA-RTPROTO-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddress, InetAddressType, InetAddressPrefixLength, InetZoneIndex, InetVersion FROM INET-ADDRESS-MIB -- [RFC4001] LangTag FROM LANGTAG-TC-MIB; -- [RFC5131] ipMcastMIB MODULE-IDENTITY LAST-UPDATED "200711090000Z" -- 9 November 2007 ORGANIZATION "IETF MBONE Deployment (MBONED) Working Group" CONTACT-INFO "David McWalter Data Connection Limited McWalter, et al. Standards Track [Page 4] RFC 5132 IP MCAST MIB December 2007 100 Church Street Enfield, EN2 6BQ UK Phone: +44 208 366 1177 EMail: dmcw@dataconnection.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 US Phone: +1 425 703 8835 EMail: dthaler@dthaler.microsoft.com Andrew Kessler Cisco Systems 425 E. Tasman Drive San Jose, CA 95134 US Phone: +1 408 526 5139 EMail: kessler@cisco.com" DESCRIPTION "The MIB module for management of IP Multicast, including multicast routing, data forwarding, and data reception. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 5132; see the RFC itself for full legal notices." REVISION "200711090000Z" -- 9 November 2007 DESCRIPTION "Initial version, published as RFC 5132. This MIB module obsoletes IPMROUTE-STD-MIB defined by [RFC2932]. Changes include the following: o This MIB module includes support for IPv6 addressing and the IPv6 scoped address architecture. [RFC2932] supported only IPv4. o This MIB module allows several multicast protocols to perform routing on a single interface, where [RFC2932] assumed each interface supported at most one multicast routing protocol. Multicast routing protocols are now per-route, see ipMcastRouteProtocol. McWalter, et al. Standards Track [Page 5] RFC 5132 IP MCAST MIB December 2007 o This MIB module includes objects that are not specific to multicast routing. It allows management of multicast function on systems that do not perform routing, whereas [RFC2932] was restricted to multicast routing. o This MIB module includes a table of Source-Specific Multicast (SSM) address ranges to which SSM semantics [RFC3569] should be applied. o This MIB module includes a table of local applications that are receiving multicast data. o This MIB module includes a table of multicast scope zones." ::= { mib-2 168 } -- -- Top-level structure of the MIB -- ipMcast OBJECT IDENTIFIER ::= { ipMcastMIB 1 } ipMcastEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The enabled status of IP Multicast function on this system. The storage type of this object is determined by ipMcastDeviceConfigStorageType." ::= { ipMcast 1 } ipMcastRouteEntryCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of rows in the ipMcastRouteTable. This can be used to check for multicast routing activity, and to monitor the multicast routing table size." ::= { ipMcast 2 } ipMcastDeviceConfigStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write McWalter, et al. Standards Track [Page 6] RFC 5132 IP MCAST MIB December 2007 STATUS current DESCRIPTION "The storage type used for the global IP multicast configuration of this device, comprised of the objects listed below. If this storage type takes the value 'permanent', write-access to the listed objects need not be allowed. The objects described by this storage type are: ipMcastEnabled." DEFVAL { nonVolatile } ::= { ipMcast 11 } -- -- The Multicast Interface Table -- ipMcastInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table used to manage the multicast protocol active on an interface." ::= { ipMcast 3 } ipMcastInterfaceEntry OBJECT-TYPE SYNTAX IpMcastInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the multicast protocol information for a particular interface. Per-interface multicast forwarding statistics are also available in ipIfStatsTable." REFERENCE "RFC 4293 ipIfStatsTable" INDEX { ipMcastInterfaceIPVersion, ipMcastInterfaceIfIndex } ::= { ipMcastInterfaceTable 1 } IpMcastInterfaceEntry ::= SEQUENCE { ipMcastInterfaceIPVersion InetVersion, ipMcastInterfaceIfIndex InterfaceIndex, ipMcastInterfaceTtl Unsigned32, ipMcastInterfaceRateLimit Unsigned32, ipMcastInterfaceStorageType StorageType } McWalter, et al. Standards Track [Page 7] RFC 5132 IP MCAST MIB December 2007 ipMcastInterfaceIPVersion OBJECT-TYPE SYNTAX InetVersion MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP version of this row." ::= { ipMcastInterfaceEntry 1 } ipMcastInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipMcastInterfaceEntry 2 } ipMcastInterfaceTtl OBJECT-TYPE SYNTAX Unsigned32 (0..256) MAX-ACCESS read-write STATUS current DESCRIPTION "The datagram Time to Live (TTL) threshold for the interface. Any IP multicast datagrams with a TTL (IPv4) or Hop Limit (IPv6) less than this threshold will not be forwarded out the interface. The default value of 0 means all multicast packets are forwarded out the interface. A value of 256 means that no multicast packets are forwarded out the interface." DEFVAL { 0 } ::= { ipMcastInterfaceEntry 3 } ipMcastInterfaceRateLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The rate-limit, in kilobits per second, of forwarded multicast traffic on the interface. A rate-limit of 0 indicates that no rate limiting is done." DEFVAL { 0 } ::= { ipMcastInterfaceEntry 4 } ipMcastInterfaceStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write McWalter, et al. Standards Track [Page 8] RFC 5132 IP MCAST MIB December 2007 STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipMcastInterfaceEntry 5 } -- -- The SSM Range Table -- ipMcastSsmRangeTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastSsmRangeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to create and manage the range(s) of group addresses to which SSM semantics should be applied." REFERENCE "RFC 3569" ::= { ipMcast 4 } ipMcastSsmRangeEntry OBJECT-TYPE SYNTAX IpMcastSsmRangeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing a range of group addresses to which SSM semantics should be applied. Object Identifiers (OIDs) are limited to 128 sub-identifiers, but this limit is not enforced by the syntax of this entry. In practice, this does not present a problem, because IP address types allowed by conformance statements do not exceed this limit." REFERENCE "RFC 3569" INDEX { ipMcastSsmRangeAddressType, ipMcastSsmRangeAddress, ipMcastSsmRangePrefixLength } ::= { ipMcastSsmRangeTable 1 } IpMcastSsmRangeEntry ::= SEQUENCE { ipMcastSsmRangeAddressType InetAddressType, ipMcastSsmRangeAddress InetAddress, ipMcastSsmRangePrefixLength InetAddressPrefixLength, ipMcastSsmRangeRowStatus RowStatus, ipMcastSsmRangeStorageType StorageType } McWalter, et al. Standards Track [Page 9] RFC 5132 IP MCAST MIB December 2007 ipMcastSsmRangeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the multicast group prefix." ::= { ipMcastSsmRangeEntry 1 } ipMcastSsmRangeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group address which, when combined with ipMcastSsmRangePrefixLength, gives the group prefix for this SSM range. The InetAddressType is given by ipMcastSsmRangeAddressType. This address object is only significant up to ipMcastSsmRangePrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry. For IPv6 SSM address ranges, only ranges prefixed by FF3x::/16 are permitted, where 'x' is a valid IPv6 RFC 4291 multicast address scope. The syntax of the address range is given by RFC 3306, Sections 4 and 7. For addresses of type ipv4z or ipv6z, the appended zone index is significant even though it lies beyond the prefix length. The use of these address types indicate that this SSM range entry applies only within the given zone. Zone index zero is not valid in this table. If non-global scope SSM range entries are present, then consistent ipMcastBoundaryTable entries are required on routers at the zone boundary." REFERENCE "RFC 2365, RFC 4291 Section 2.7, RFC 3306 Sections 4, 6, and 7" ::= { ipMcastSsmRangeEntry 2 } ipMcastSsmRangePrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length in bits of the mask which, when combined with McWalter, et al. Standards Track [Page 10] RFC 5132 IP MCAST MIB December 2007 ipMcastSsmRangeAddress, gives the group prefix for this SSM range. The InetAddressType is given by ipMcastSsmRangeAddressType. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be in the range 8..128." REFERENCE "RFC 2365, RFC 4291 Section 2.7, RFC 3306 Sections 4, 6, and 7" ::= { ipMcastSsmRangeEntry 3 } ipMcastSsmRangeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which rows in this table can be created and destroyed. This status object can be set to active(1) without setting any other columnar objects in this entry. All writeable objects in this entry can be modified when the status of this entry is active(1)." ::= { ipMcastSsmRangeEntry 4 } ipMcastSsmRangeStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipMcastSsmRangeEntry 5 } -- -- The IP Multicast Routing Table -- ipMcastRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing multicast routing information for IP datagrams sent by particular sources McWalter, et al. Standards Track [Page 11] RFC 5132 IP MCAST MIB December 2007 to the IP multicast groups known to this router." ::= { ipMcast 5 } ipMcastRouteEntry OBJECT-TYPE SYNTAX IpMcastRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the multicast routing information for IP datagrams from a particular source and addressed to a particular IP multicast group address. OIDs are limited to 128 sub-identifiers, but this limit is not enforced by the syntax of this entry. In practice, this does not present a problem, because IP address types allowed by conformance statements do not exceed this limit." INDEX { ipMcastRouteGroupAddressType, ipMcastRouteGroup, ipMcastRouteGroupPrefixLength, ipMcastRouteSourceAddressType, ipMcastRouteSource, ipMcastRouteSourcePrefixLength } ::= { ipMcastRouteTable 1 } IpMcastRouteEntry ::= SEQUENCE { ipMcastRouteGroupAddressType InetAddressType, ipMcastRouteGroup InetAddress, ipMcastRouteGroupPrefixLength InetAddressPrefixLength, ipMcastRouteSourceAddressType InetAddressType, ipMcastRouteSource InetAddress, ipMcastRouteSourcePrefixLength InetAddressPrefixLength, ipMcastRouteUpstreamNeighborType InetAddressType, ipMcastRouteUpstreamNeighbor InetAddress, ipMcastRouteInIfIndex InterfaceIndexOrZero, ipMcastRouteTimeStamp TimeStamp, ipMcastRouteExpiryTime TimeTicks, ipMcastRouteProtocol IANAipMRouteProtocol, ipMcastRouteRtProtocol IANAipRouteProtocol, ipMcastRouteRtAddressType InetAddressType, ipMcastRouteRtAddress InetAddress, ipMcastRouteRtPrefixLength InetAddressPrefixLength, ipMcastRouteRtType INTEGER, ipMcastRouteOctets Counter64, ipMcastRoutePkts Counter64, ipMcastRouteTtlDropOctets Counter64, ipMcastRouteTtlDropPackets Counter64, ipMcastRouteDifferentInIfOctets Counter64, ipMcastRouteDifferentInIfPackets Counter64, McWalter, et al. Standards Track [Page 12] RFC 5132 IP MCAST MIB December 2007 ipMcastRouteBps CounterBasedGauge64 } ipMcastRouteGroupAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastRouteGroup. Legal values correspond to the subset of address families for which multicast forwarding is supported." ::= { ipMcastRouteEntry 1 } ipMcastRouteGroup OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address which, when combined with the corresponding value specified in ipMcastRouteGroupPrefixLength, identifies the groups for which this entry contains multicast routing information. This address object is only significant up to ipMcastRouteGroupPrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry. For addresses of type ipv4z or ipv6z, the appended zone index is significant even though it lies beyond the prefix length. The use of these address types indicate that this forwarding state applies only within the given zone. Zone index zero is not valid in this table." ::= { ipMcastRouteEntry 2 } ipMcastRouteGroupPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length in bits of the mask which, when combined with the corresponding value of ipMcastRouteGroup, identifies the groups for which this entry contains multicast routing information. The InetAddressType is given by McWalter, et al. Standards Track [Page 13] RFC 5132 IP MCAST MIB December 2007 ipMcastRouteGroupAddressType. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be in the range 8..128." ::= { ipMcastRouteEntry 3 } ipMcastRouteSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastRouteSource. A value of unknown(0) indicates a non-source-specific entry, corresponding to all sources in the group. Otherwise, the value MUST be the same as the value of ipMcastRouteGroupType." ::= { ipMcastRouteEntry 4 } ipMcastRouteSource OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address which, when combined with the corresponding value of ipMcastRouteSourcePrefixLength, identifies the sources for which this entry contains multicast routing information. This address object is only significant up to ipMcastRouteSourcePrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry. For addresses of type ipv4z or ipv6z, the appended zone index is significant even though it lies beyond the prefix length. The use of these address types indicate that this source address applies only within the given zone. Zone index zero is not valid in this table." ::= { ipMcastRouteEntry 5 } ipMcastRouteSourcePrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION McWalter, et al. Standards Track [Page 14] RFC 5132 IP MCAST MIB December 2007 "The length in bits of the mask which, when combined with the corresponding value of ipMcastRouteSource, identifies the sources for which this entry contains multicast routing information. The InetAddressType is given by ipMcastRouteSourceAddressType. For the value 'unknown', this object must be zero. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be in the range 8..128." ::= { ipMcastRouteEntry 6 } ipMcastRouteUpstreamNeighborType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastRouteUpstreamNeighbor. An address type of unknown(0) indicates that the upstream neighbor is unknown, for example in BIDIR-PIM." REFERENCE "RFC 5015" ::= { ipMcastRouteEntry 7 } ipMcastRouteUpstreamNeighbor OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the upstream neighbor (for example, RPF neighbor) from which IP datagrams from these sources to this multicast address are received." ::= { ipMcastRouteEntry 8 } ipMcastRouteInIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the interface on which IP datagrams sent by these sources to this multicast address are received. A value of 0 indicates that datagrams are not subject to an incoming interface check, but may be accepted on multiple interfaces (for example, in BIDIR-PIM)." REFERENCE "RFC 5015" ::= { ipMcastRouteEntry 9 } McWalter, et al. Standards Track [Page 15] RFC 5132 IP MCAST MIB December 2007 ipMcastRouteTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which the multicast routing information represented by this entry was learned by the router. If this information was present at the most recent re- initialization of the local management subsystem, then this object contains a zero value." ::= { ipMcastRouteEntry 10 } ipMcastRouteExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum amount of time remaining before this entry will be aged out. The value 0 indicates that the entry is not subject to aging. If ipMcastRouteNextHopState is pruned(1), this object represents the remaining time until the prune expires. If this timer expires, state reverts to forwarding(2). Otherwise, this object represents the time until this entry is removed from the table." ::= { ipMcastRouteEntry 11 } ipMcastRouteProtocol OBJECT-TYPE SYNTAX IANAipMRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The multicast routing protocol via which this multicast forwarding entry was learned." ::= { ipMcastRouteEntry 12 } ipMcastRouteRtProtocol OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which the route used to find the upstream or parent interface for this multicast forwarding entry was learned." ::= { ipMcastRouteEntry 13 } ipMcastRouteRtAddressType OBJECT-TYPE McWalter, et al. Standards Track [Page 16] RFC 5132 IP MCAST MIB December 2007 SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastRouteRtAddress." ::= { ipMcastRouteEntry 14 } ipMcastRouteRtAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address portion of the route used to find the upstream or parent interface for this multicast forwarding entry. This address object is only significant up to ipMcastRouteRtPrefixLength bits. The remaining address bits are set to zero. For addresses of type ipv4z or ipv6z, the appended zone index is significant even though it lies beyond the prefix length. The use of these address types indicate that this forwarding state applies only within the given zone. Zone index zero is not valid in this table." ::= { ipMcastRouteEntry 15 } ipMcastRouteRtPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "The length in bits of the mask associated with the route used to find the upstream or parent interface for this multicast forwarding entry. The InetAddressType is given by ipMcastRouteRtAddressType. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be in the range 8..128." ::= { ipMcastRouteEntry 16 } ipMcastRouteRtType OBJECT-TYPE SYNTAX INTEGER { unicast (1), -- Unicast route used in multicast RIB multicast (2) -- Multicast route } MAX-ACCESS read-only McWalter, et al. Standards Track [Page 17] RFC 5132 IP MCAST MIB December 2007 STATUS current DESCRIPTION "The reason the given route was placed in the (logical) multicast Routing Information Base (RIB). A value of unicast means that the route would normally be placed only in the unicast RIB, but was placed in the multicast RIB due (instead or in addition) to local configuration, such as when running PIM over RIP. A value of multicast means that the route was explicitly added to the multicast RIB by the routing protocol, such as the Distance Vector Multicast Routing Protocol (DVMRP) or Multiprotocol BGP." ::= { ipMcastRouteEntry 17 } ipMcastRouteOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in IP datagrams that were received from these sources and addressed to this multicast group address, and which were forwarded by this router. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteTimeStamp." ::= { ipMcastRouteEntry 18 } ipMcastRoutePkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets routed using this multicast route entry. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteTimeStamp." ::= { ipMcastRouteEntry 19 } ipMcastRouteTtlDropOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current McWalter, et al. Standards Track [Page 18] RFC 5132 IP MCAST MIB December 2007 DESCRIPTION "The number of octets contained in IP datagrams that this router has received from these sources and addressed to this multicast group address, which were dropped because the TTL (IPv4) or Hop Limit (IPv6) was decremented to zero, or to a value less than ipMcastInterfaceTtl for all next hops. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteTimeStamp." ::= { ipMcastRouteEntry 20 } ipMcastRouteTtlDropPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that this router has received from these sources and addressed to this multicast group address, which were dropped because the TTL (IPv4) or Hop Limit (IPv6) was decremented to zero, or to a value less than ipMcastInterfaceTtl for all next hops. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteTimeStamp." ::= { ipMcastRouteEntry 21 } ipMcastRouteDifferentInIfOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in IP datagrams that this router has received from these sources and addressed to this multicast group address, which were dropped because they were received on an unexpected interface. For RPF checking protocols (such as PIM-SM), these packets arrived on interfaces other than ipMcastRouteInIfIndex, and were dropped because of this failed RPF check. (RPF paths are 'Reverse Path Forwarding' paths; the unicast routes to the expected origin of multicast data flows). McWalter, et al. Standards Track [Page 19] RFC 5132 IP MCAST MIB December 2007 Other protocols may drop packets on an incoming interface check for different reasons (for example, BIDIR-PIM performs a DF check on receipt of packets). All packets dropped as a result of an incoming interface check are counted here. If this counter increases rapidly, this indicates a problem. A significant quantity of multicast data is arriving at this router on unexpected interfaces, and is not being forwarded. For guidance, if the rate of increase of this counter exceeds 1% of the rate of increase of ipMcastRouteOctets, then there are multicast routing problems that require investigation. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteTimeStamp." REFERENCE "RFC 4601 and RFC 5015" ::= { ipMcastRouteEntry 22 } ipMcastRouteDifferentInIfPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which this router has received from these sources and addressed to this multicast group address, which were dropped because they were received on an unexpected interface. For RPF checking protocols (such as PIM-SM), these packets arrived on interfaces other than ipMcastRouteInIfIndex, and were dropped because of this failed RPF check. (RPF paths are 'Reverse Path Forwarding' path; the unicast routes to the expected origin of multicast data flows). Other protocols may drop packets on an incoming interface check for different reasons (for example, BIDIR-PIM performs a DF check on receipt of packets). All packets dropped as a result of an incoming interface check are counted here. If this counter increases rapidly, this indicates a problem. A significant quantity of multicast data is arriving at this router on unexpected interfaces, and is not being forwarded. For guidance, if the rate of increase of this counter McWalter, et al. Standards Track [Page 20] RFC 5132 IP MCAST MIB December 2007 exceeds 1% of the rate of increase of ipMcastRoutePkts, then there are multicast routing problems that require investigation. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteTimeStamp." REFERENCE "RFC 4601 and RFC 5015" ::= { ipMcastRouteEntry 23 } ipMcastRouteBps OBJECT-TYPE SYNTAX CounterBasedGauge64 UNITS "bits per second" MAX-ACCESS read-only STATUS current DESCRIPTION "Bits per second forwarded by this router using this multicast routing entry. This value is a sample; it is the number of bits forwarded during the last whole 1 second sampling period. The value during the current 1 second sampling period is not made available until the period is completed. The quantity being sampled is the same as that measured by ipMcastRouteOctets. The units and the sampling method are different." ::= { ipMcastRouteEntry 24 } -- -- The IP Multicast Routing Next Hop Table -- ipMcastRouteNextHopTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastRouteNextHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on the next-hops on outgoing interfaces for routing IP multicast datagrams. Each entry is one of a list of next-hops on outgoing interfaces for particular sources sending to a particular multicast group address." ::= { ipMcast 6 } ipMcastRouteNextHopEntry OBJECT-TYPE SYNTAX IpMcastRouteNextHopEntry McWalter, et al. Standards Track [Page 21] RFC 5132 IP MCAST MIB December 2007 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the list of next-hops on outgoing interfaces to which IP multicast datagrams from particular sources to an IP multicast group address are routed. OIDs are limited to 128 sub-identifiers, but this limit is not enforced by the syntax of this entry. In practice, this does not present a problem, because IP address types allowed by conformance statements do not exceed this limit." INDEX { ipMcastRouteNextHopGroupAddressType, ipMcastRouteNextHopGroup, ipMcastRouteNextHopGroupPrefixLength, ipMcastRouteNextHopSourceAddressType, ipMcastRouteNextHopSource, ipMcastRouteNextHopSourcePrefixLength, ipMcastRouteNextHopIfIndex, ipMcastRouteNextHopAddressType, ipMcastRouteNextHopAddress } ::= { ipMcastRouteNextHopTable 1 } IpMcastRouteNextHopEntry ::= SEQUENCE { ipMcastRouteNextHopGroupAddressType InetAddressType, ipMcastRouteNextHopGroup InetAddress, ipMcastRouteNextHopGroupPrefixLength InetAddressPrefixLength, ipMcastRouteNextHopSourceAddressType InetAddressType, ipMcastRouteNextHopSource InetAddress, ipMcastRouteNextHopSourcePrefixLength InetAddressPrefixLength, ipMcastRouteNextHopIfIndex InterfaceIndex, ipMcastRouteNextHopAddressType InetAddressType, ipMcastRouteNextHopAddress InetAddress, ipMcastRouteNextHopState INTEGER, ipMcastRouteNextHopTimeStamp TimeStamp, ipMcastRouteNextHopExpiryTime TimeTicks, ipMcastRouteNextHopClosestMemberHops Unsigned32, ipMcastRouteNextHopProtocol IANAipMRouteProtocol, ipMcastRouteNextHopOctets Counter64, ipMcastRouteNextHopPkts Counter64 } ipMcastRouteNextHopGroupAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address McWalter, et al. Standards Track [Page 22] RFC 5132 IP MCAST MIB December 2007 contained in ipMcastRouteNextHopGroup. Legal values correspond to the subset of address families for which multicast forwarding is supported." ::= { ipMcastRouteNextHopEntry 1 } ipMcastRouteNextHopGroup OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address which, when combined with the corresponding value specified in ipMcastRouteNextHopGroupPrefixLength, identifies the groups for which this entry contains multicast forwarding information. This address object is only significant up to ipMcastRouteNextHopGroupPrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry. For addresses of type ipv4z or ipv6z, the appended zone index is significant even though it lies beyond the prefix length. The use of these address types indicate that this forwarding state applies only within the given zone. Zone index zero is not valid in this table." ::= { ipMcastRouteNextHopEntry 2 } ipMcastRouteNextHopGroupPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length in bits of the mask which, when combined with the corresponding value of ipMcastRouteGroup, identifies the groups for which this entry contains multicast routing information. The InetAddressType is given by ipMcastRouteNextHopGroupAddressType. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be in the range 8..128." ::= { ipMcastRouteNextHopEntry 3 } ipMcastRouteNextHopSourceAddressType OBJECT-TYPE McWalter, et al. Standards Track [Page 23] RFC 5132 IP MCAST MIB December 2007 SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastRouteNextHopSource. A value of unknown(0) indicates a non-source-specific entry, corresponding to all sources in the group. Otherwise, the value MUST be the same as the value of ipMcastRouteNextHopGroupType." ::= { ipMcastRouteNextHopEntry 4 } ipMcastRouteNextHopSource OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address which, when combined with the corresponding value of the mask specified in ipMcastRouteNextHopSourcePrefixLength, identifies the sources for which this entry specifies a next-hop on an outgoing interface. This address object is only significant up to ipMcastRouteNextHopSourcePrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry. For addresses of type ipv4z or ipv6z, the appended zone index is significant even though it lies beyond the prefix length. The use of these address types indicate that this source address applies only within the given zone. Zone index zero is not valid in this table." ::= { ipMcastRouteNextHopEntry 5 } ipMcastRouteNextHopSourcePrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length in bits of the mask which, when combined with the corresponding value specified in ipMcastRouteNextHopSource, identifies the sources for which this entry specifies a next-hop on an outgoing interface. McWalter, et al. Standards Track [Page 24] RFC 5132 IP MCAST MIB December 2007 The InetAddressType is given by ipMcastRouteNextHopSourceAddressType. For the value 'unknown', this object must be zero. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be in the range 8..128." ::= { ipMcastRouteNextHopEntry 6 } ipMcastRouteNextHopIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the interface for the outgoing interface for this next-hop." ::= { ipMcastRouteNextHopEntry 7 } ipMcastRouteNextHopAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastRouteNextHopAddress." ::= { ipMcastRouteNextHopEntry 8 } ipMcastRouteNextHopAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the next-hop specific to this entry. For most interfaces, this is identical to ipMcastRouteNextHopGroup. Non-Broadcast Multi-Access (NBMA) interfaces, however, may have multiple next-hop addresses out a single outgoing interface." ::= { ipMcastRouteNextHopEntry 9 } ipMcastRouteNextHopState OBJECT-TYPE SYNTAX INTEGER { pruned(1), forwarding(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the outgoing interface and next- hop represented by this entry is currently being used to forward IP datagrams. The value 'forwarding' indicates it is currently being used; the value 'pruned' indicates it is McWalter, et al. Standards Track [Page 25] RFC 5132 IP MCAST MIB December 2007 not." ::= { ipMcastRouteNextHopEntry 10 } ipMcastRouteNextHopTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which the multicast routing information represented by this entry was learned by the router. If this information was present at the most recent re- initialization of the local management subsystem, then this object contains a zero value." ::= { ipMcastRouteNextHopEntry 11 } ipMcastRouteNextHopExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum amount of time remaining before this entry will be aged out. If ipMcastRouteNextHopState is pruned(1), the remaining time until the prune expires and the state reverts to forwarding(2). Otherwise, the remaining time until this entry is removed from the table. The time remaining may be copied from ipMcastRouteExpiryTime if the protocol in use for this entry does not specify next-hop timers. The value 0 indicates that the entry is not subject to aging." ::= { ipMcastRouteNextHopEntry 12 } ipMcastRouteNextHopClosestMemberHops OBJECT-TYPE SYNTAX Unsigned32 (0..256) MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum number of hops between this router and any member of this IP multicast group reached via this next-hop on this outgoing interface. Any IP multicast datagrams for the group that have a TTL (IPv4) or Hop Count (IPv6) less than this number of hops will not be forwarded to this next-hop. A value of 0 means all multicast datagrams are forwarded out the interface. A value of 256 means that no multicast datagrams are forwarded out the interface. McWalter, et al. Standards Track [Page 26] RFC 5132 IP MCAST MIB December 2007 This is an optimization applied by multicast routing protocols that explicitly track hop counts to downstream listeners. Multicast protocols that are not aware of hop counts to downstream listeners set this object to 0." ::= { ipMcastRouteNextHopEntry 13 } ipMcastRouteNextHopProtocol OBJECT-TYPE SYNTAX IANAipMRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which this next-hop was learned." ::= { ipMcastRouteNextHopEntry 14 } ipMcastRouteNextHopOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of multicast packets that have been forwarded using this route. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteNextHopTimeStamp." ::= { ipMcastRouteNextHopEntry 15 } ipMcastRouteNextHopPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets which have been forwarded using this route. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of routes being removed and replaced, which can be detected by observing the value of ipMcastRouteNextHopTimeStamp." ::= { ipMcastRouteNextHopEntry 16 } -- -- The IP Multicast Scope Boundary Table -- McWalter, et al. Standards Track [Page 27] RFC 5132 IP MCAST MIB December 2007 ipMcastBoundaryTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastBoundaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the system's multicast scope zone boundaries." REFERENCE "RFC 4007 Section 5" ::= { ipMcast 7 } ipMcastBoundaryEntry OBJECT-TYPE SYNTAX IpMcastBoundaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) describing one of this device's multicast scope zone boundaries. OIDs are limited to 128 sub-identifiers, but this limit is not enforced by the syntax of this entry. In practice, this does not present a problem, because IP address types allowed by conformance statements do not exceed this limit." REFERENCE "RFC 2365 Section 5, RFC 4007 Section 5" INDEX { ipMcastBoundaryIfIndex, ipMcastBoundaryAddressType, ipMcastBoundaryAddress, ipMcastBoundaryAddressPrefixLength } ::= { ipMcastBoundaryTable 1 } IpMcastBoundaryEntry ::= SEQUENCE { ipMcastBoundaryIfIndex InterfaceIndex, ipMcastBoundaryAddressType InetAddressType, ipMcastBoundaryAddress InetAddress, ipMcastBoundaryAddressPrefixLength InetAddressPrefixLength, ipMcastBoundaryTimeStamp TimeStamp, ipMcastBoundaryDroppedMcastOctets Counter64, ipMcastBoundaryDroppedMcastPkts Counter64, ipMcastBoundaryStatus RowStatus, ipMcastBoundaryStorageType StorageType } ipMcastBoundaryIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IfIndex value for the interface to which this boundary applies. Packets with a destination address in the McWalter, et al. Standards Track [Page 28] RFC 5132 IP MCAST MIB December 2007 associated address/mask range will not be forwarded over this interface. For IPv4, zone boundaries cut through links. Therefore, this is an external interface. This may be either a physical or virtual interface (tunnel, encapsulation, and so forth.) For IPv6, zone boundaries cut through nodes. Therefore, this is a virtual interface within the node. This is not an external interface, either real or virtual. Packets crossing this interface neither arrive at nor leave the node, but only move between zones within the node." REFERENCE "RFC 2365 Section 5, RFC 4007 Section 5" ::= { ipMcastBoundaryEntry 1 } ipMcastBoundaryAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastBoundaryAddress. Legal values correspond to the subset of address families for which multicast forwarding is supported." ::= { ipMcastBoundaryEntry 2 } ipMcastBoundaryAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group address which, when combined with the corresponding value of ipMcastBoundaryAddressPrefixLength, identifies the group range for which the scoped boundary exists. Scoped IPv4 multicast address ranges must be prefixed by 239.0.0.0/8. Scoped IPv6 multicast address ranges are FF0x::/16, where x is a valid RFC 4291 multicast scope. An IPv6 address prefixed by FF1x::/16 is a non-permanently- assigned address. An IPv6 address prefixed by FF3x::/16 is a unicast-prefix-based multicast addresses. A zone boundary for FF0x::/16 implies an identical boundary for these other prefixes. No separate FF1x::/16 or FF3x::/16 entries exist in this table. This address object is only significant up to McWalter, et al. Standards Track [Page 29] RFC 5132 IP MCAST MIB December 2007 ipMcastBoundaryAddressPrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry." ::= { ipMcastBoundaryEntry 3 } ipMcastBoundaryAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length in bits of the mask which when, combined with the corresponding value of ipMcastBoundaryAddress, identifies the group range for which the scoped boundary exists. The InetAddressType is given by ipMcastBoundaryAddressType. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be set to 16." ::= { ipMcastBoundaryEntry 4 } ipMcastBoundaryTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which the multicast boundary information represented by this entry was learned by the router. If this information was present at the most recent re- initialization of the local management subsystem, then this object contains a zero value." ::= { ipMcastBoundaryEntry 5 } ipMcastBoundaryDroppedMcastOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of multicast packets that have been dropped as a result of this zone boundary configuration. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of boundary McWalter, et al. Standards Track [Page 30] RFC 5132 IP MCAST MIB December 2007 configuration being removed and replaced, which can be detected by observing the value of ipMcastBoundaryTimeStamp." ::= { ipMcastBoundaryEntry 6 } ipMcastBoundaryDroppedMcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of multicast packets that have been dropped as a result of this zone boundary configuration. Discontinuities in this monotonically increasing value occur at re-initialization of the management system. Discontinuities can also occur as a result of boundary configuration being removed and replaced, which can be detected by observing the value of ipMcastBoundaryTimeStamp." ::= { ipMcastBoundaryEntry 7 } ipMcastBoundaryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which rows in this table can be created and destroyed. This status object can be set to active(1) without setting any other columnar objects in this entry. All writeable objects in this entry can be modified when the status of this entry is active(1)." ::= { ipMcastBoundaryEntry 8 } ipMcastBoundaryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipMcastBoundaryEntry 9 } -- McWalter, et al. Standards Track [Page 31] RFC 5132 IP MCAST MIB December 2007 -- The IP Multicast Scope Name Table -- ipMcastScopeNameTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastScopeNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing multicast scope names." REFERENCE "RFC 4007 Section 4" ::= { ipMcast 8 } ipMcastScopeNameEntry OBJECT-TYPE SYNTAX IpMcastScopeNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) that names a multicast address scope. OIDs are limited to 128 sub-identifiers, but this limit is not enforced by the syntax of this entry. In practice, this does not present a problem, because IP address types allowed by conformance statements do not exceed this limit." REFERENCE "RFC 4007 Section 4" INDEX { ipMcastScopeNameAddressType, ipMcastScopeNameAddress, ipMcastScopeNameAddressPrefixLength, ipMcastScopeNameLanguage } ::= { ipMcastScopeNameTable 1 } IpMcastScopeNameEntry ::= SEQUENCE { ipMcastScopeNameAddressType InetAddressType, ipMcastScopeNameAddress InetAddress, ipMcastScopeNameAddressPrefixLength InetAddressPrefixLength, ipMcastScopeNameLanguage LangTag, ipMcastScopeNameString SnmpAdminString, ipMcastScopeNameDefault TruthValue, ipMcastScopeNameStatus RowStatus, ipMcastScopeNameStorageType StorageType } ipMcastScopeNameAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address McWalter, et al. Standards Track [Page 32] RFC 5132 IP MCAST MIB December 2007 contained in ipMcastScopeNameAddress. Legal values correspond to the subset of address families for which multicast forwarding is supported." ::= { ipMcastScopeNameEntry 1 } ipMcastScopeNameAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group address which, when combined with the corresponding value of ipMcastScopeNameAddressPrefixLength, identifies the group range associated with the multicast scope. Scoped IPv4 multicast address ranges must be prefixed by 239.0.0.0/8. Scoped IPv6 multicast address ranges are FF0x::/16, where x is a valid RFC 4291 multicast scope. An IPv6 address prefixed by FF1x::/16 is a non-permanently- assigned address. An IPv6 address prefixed by FF3x::/16 is a unicast-prefix-based multicast addresses. A scope FF0x::/16 implies an identical scope name for these other prefixes. No separate FF1x::/16 or FF3x::/16 entries exist in this table. This address object is only significant up to ipMcastScopeNameAddressPrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry." ::= { ipMcastScopeNameEntry 2 } ipMcastScopeNameAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length in bits of the mask which, when combined with the corresponding value of ipMcastScopeNameAddress, identifies the group range associated with the multicast scope. The InetAddressType is given by ipMcastScopeNameAddressType. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be set to 16." ::= { ipMcastScopeNameEntry 3 } McWalter, et al. Standards Track [Page 33] RFC 5132 IP MCAST MIB December 2007 ipMcastScopeNameLanguage OBJECT-TYPE SYNTAX LangTag MAX-ACCESS not-accessible STATUS current DESCRIPTION "Language tag associated with the scope name." REFERENCE "RFC 4646" ::= { ipMcastScopeNameEntry 4 } ipMcastScopeNameString OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The textual name associated with the multicast scope. The value of this object should be suitable for displaying to end-users, such as when allocating a multicast address in this scope. When no name is specified, the default value of this object for IPv4 should be the string 239.x.x.x/y with x and y replaced with decimal values to describe the address and mask length associated with the scope. When no name is specified, the default value of this object for IPv6 should be the string FF0x::/16, with x replaced by the hexadecimal value for the RFC 4291 multicast scope. An IPv6 address prefixed by FF1x::/16 is a non-permanently- assigned address. An IPv6 address prefixed by FF3x::/16 is a unicast-prefix-based multicast addresses. A scope FF0x::/16 implies an identical scope name for these other prefixes. No separate FF1x::/16 or FF3x::/16 entries exist in this table." REFERENCE "RFC 2365, RFC 3306 Section 4, RFC 4291 Section 2.7" ::= { ipMcastScopeNameEntry 5 } ipMcastScopeNameDefault OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, indicates a preference that the name in the following language should be used by applications if no name is available in a desired language." DEFVAL { false } ::= { ipMcastScopeNameEntry 6 } McWalter, et al. Standards Track [Page 34] RFC 5132 IP MCAST MIB December 2007 ipMcastScopeNameStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which rows in this table can be created and destroyed. Before the row can be activated, the object ipMcastScopeNameString must be set to a valid value. All writeable objects in this entry can be modified when the status is active(1)." ::= { ipMcastScopeNameEntry 7 } ipMcastScopeNameStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { ipMcastScopeNameEntry 8 } -- -- The Multicast Listeners Table -- ipMcastLocalListenerTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastLocalListenerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing local applications or services that have joined multicast groups as listeners. Entries exist for all addresses in the multicast range for all applications and services as they are classified on this device." ::= { ipMcast 9 } ipMcastLocalListenerEntry OBJECT-TYPE SYNTAX IpMcastLocalListenerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) identifying a local application or service that has joined a multicast group as a listener. McWalter, et al. Standards Track [Page 35] RFC 5132 IP MCAST MIB December 2007 OIDs are limited to 128 sub-identifiers, but this limit is not enforced by the syntax of this entry. In practice, this does not present a problem, because IP address types allowed by conformance statements do not exceed this limit." INDEX { ipMcastLocalListenerGroupAddressType, ipMcastLocalListenerGroupAddress, ipMcastLocalListenerSourceAddressType, ipMcastLocalListenerSourceAddress, ipMcastLocalListenerSourcePrefixLength, ipMcastLocalListenerIfIndex, ipMcastLocalListenerRunIndex } ::= { ipMcastLocalListenerTable 1 } IpMcastLocalListenerEntry ::= SEQUENCE { ipMcastLocalListenerGroupAddressType InetAddressType, ipMcastLocalListenerGroupAddress InetAddress, ipMcastLocalListenerSourceAddressType InetAddressType, ipMcastLocalListenerSourceAddress InetAddress, ipMcastLocalListenerSourcePrefixLength InetAddressPrefixLength, ipMcastLocalListenerIfIndex InterfaceIndex, ipMcastLocalListenerRunIndex Unsigned32 } ipMcastLocalListenerGroupAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value indicating the address family of the address contained in ipMcastLocalListenerGroupAddress. Legal values correspond to the subset of address families for which multicast is supported." ::= { ipMcastLocalListenerEntry 1 } ipMcastLocalListenerGroupAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group for which this entry specifies locally joined applications or services." ::= { ipMcastLocalListenerEntry 2 } ipMcastLocalListenerSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION McWalter, et al. Standards Track [Page 36] RFC 5132 IP MCAST MIB December 2007 "A value indicating the address family of the address contained in ipMcastLocalListenerSource. A value of unknown(0) indicates a non-source-specific entry, corresponding to all sources in the group. Otherwise, the value MUST be the same as the value of ipMcastLocalListenerGroupAddressType." ::= { ipMcastLocalListenerEntry 3 } ipMcastLocalListenerSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address which, when combined with the corresponding value of the mask specified in ipMcastLocalListenerSourcePrefixLength, identifies the sources for which this entry specifies a local listener. This address object is only significant up to ipMcastLocalListenerSourcePrefixLength bits. The remaining address bits are set to zero. This is especially important for this index field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry. For addresses of type ipv4z or ipv6z, the appended zone index is significant even though it lies beyond the prefix length. The use of these address types indicate that this listener address applies only within the given zone. Zone index zero is not valid in this table." ::= { ipMcastLocalListenerEntry 4 } ipMcastLocalListenerSourcePrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length in bits of the mask which, when combined with the corresponding value specified in ipMcastLocalListenerSource, identifies the sources for which this entry specifies a local listener. The InetAddressType is given by ipMcastLocalListenerSourceAddressType. For the value 'unknown', this object must be zero. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be in the range McWalter, et al. Standards Track [Page 37] RFC 5132 IP MCAST MIB December 2007 8..128." ::= { ipMcastLocalListenerEntry 5 } ipMcastLocalListenerIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IfIndex value of the interface for which this entry specifies a local listener." ::= { ipMcastLocalListenerEntry 6 } ipMcastLocalListenerRunIndex OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "A unique value corresponding to a piece of software running on this router or host system. Where possible, this should be the system's native, unique identification number. This identifier is platform-specific. It may correspond to a process ID or application instance number. A value of zero indicates that the application instance(s) cannot be identified. A value of zero indicates that one or more unidentified applications have joined the specified multicast groups (for the specified sources) as listeners." REFERENCE "RFC 2287 sysApplRunIndex" ::= { ipMcastLocalListenerEntry 7 } -- -- The Multicast Zone Table -- ipMcastZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF IpMcastZoneEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing scope zones on this device." REFERENCE "RFC 4007 Section 5" ::= { ipMcast 10 } ipMcastZoneEntry OBJECT-TYPE SYNTAX IpMcastZoneEntry MAX-ACCESS not-accessible STATUS current McWalter, et al. Standards Track [Page 38] RFC 5132 IP MCAST MIB December 2007 DESCRIPTION "An entry (conceptual row) describing a scope zone on this device." REFERENCE "RFC 4007 Section 5" INDEX { ipMcastZoneIndex } ::= { ipMcastZoneTable 1 } IpMcastZoneEntry ::= SEQUENCE { ipMcastZoneIndex InetZoneIndex, ipMcastZoneScopeDefaultZoneIndex InetZoneIndex, ipMcastZoneScopeAddressType InetAddressType, ipMcastZoneScopeAddress InetAddress, ipMcastZoneScopeAddressPrefixLength InetAddressPrefixLength } ipMcastZoneIndex OBJECT-TYPE SYNTAX InetZoneIndex (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This zone index uniquely identifies a zone on a device. Each zone is for a given scope. Scope-level information in this table is for the unique scope that corresponds to this zone. Zero is a special value used to request the default zone for a given scope. Zero is not a valid value for this object. To test whether ipMcastZoneIndex is the default zone for this scope, test whether ipMcastZoneIndex is equal to ipMcastZoneScopeDefaultZoneIndex." ::= { ipMcastZoneEntry 1 } ipMcastZoneScopeDefaultZoneIndex OBJECT-TYPE SYNTAX InetZoneIndex (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The default zone index for this scope. This is the zone that this device will use if the default (zero) zone is requested for this scope. Zero is not a valid value for this object." ::= { ipMcastZoneEntry 2 } ipMcastZoneScopeAddressType OBJECT-TYPE SYNTAX InetAddressType McWalter, et al. Standards Track [Page 39] RFC 5132 IP MCAST MIB December 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address type for which this scope zone exists." ::= { ipMcastZoneEntry 3 } ipMcastZoneScopeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The multicast group address which, when combined with ipMcastZoneScopeAddressPrefixLength, gives the multicast address range for this scope. The InetAddressType is given by ipMcastZoneScopeAddressType. Scoped IPv4 multicast address ranges are prefixed by 239.0.0.0/8. Scoped IPv6 multicast address ranges are FF0x::/16, where x is a valid RFC 4291 multicast scope. An IPv6 address prefixed by FF1x::/16 is a non-permanently- assigned address. An IPv6 address prefixed by FF3x::/16 is a unicast-prefix-based multicast addresses. A scope FF0x::/16 implies an identical scope for these other prefixes. No separate FF1x::/16 or FF3x::/16 entries exist in this table. This address object is only significant up to ipMcastZoneScopeAddressPrefixLength bits. The remaining address bits are set to zero." REFERENCE "RFC 2365, RFC 3306 Section 4, RFC 4291 Section 2.7" ::= { ipMcastZoneEntry 4 } ipMcastZoneScopeAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "The length in bits of the mask which, when combined with ipMcastZoneScopeAddress, gives the multicast address prefix for this scope. The InetAddressType is given by ipMcastZoneScopeAddressType. For values 'ipv4' and 'ipv4z', this object must be in the range 4..32. For values 'ipv6' and 'ipv6z', this object must be set to 16." ::= { ipMcastZoneEntry 5 } McWalter, et al. Standards Track [Page 40] RFC 5132 IP MCAST MIB December 2007 -- -- Conformance information -- ipMcastMIBConformance OBJECT IDENTIFIER ::= { ipMcastMIB 2 } ipMcastMIBCompliances OBJECT IDENTIFIER ::= { ipMcastMIBConformance 1 } ipMcastMIBGroups OBJECT IDENTIFIER ::= { ipMcastMIBConformance 2 } -- -- Compliance statements -- ipMcastMIBComplianceHost MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts supporting IPMCAST-MIB. Support for either InetAddressType ipv4 or ipv6 is mandatory; support for both InetAddressTypes ipv4 and ipv6 is optional. Support for types ipv4z and ipv6z is optional. -- OBJECT ipMcastLocalListenerGroupAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastLocalListenerGroupAddress -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastLocalListenerSourceAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastLocalListenerSourceAddress -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6." MODULE -- this module MANDATORY-GROUPS { ipMcastMIBLocalListenerGroup, McWalter, et al. Standards Track [Page 41] RFC 5132 IP MCAST MIB December 2007 ipMcastMIBBasicGroup } OBJECT ipMcastEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastDeviceConfigStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP ipMcastMIBSsmGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBRouteGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBRouteDiagnosticsGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBBoundaryIfGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBScopeNameGroup DESCRIPTION "This group is optional." ::= { ipMcastMIBCompliances 1 } ipMcastMIBComplianceRouter MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers supporting IPMCAST-MIB. Support for either InetAddressType ipv4 or ipv6 is mandatory; support for both InetAddressTypes ipv4 and ipv6 is optional. Support for types ipv4z and ipv6z is optional. -- OBJECT ipMcastSsmRangeAddressType -- SYNTAX InetAddressType {ipv4(1), ipv6(2), ipv4z(3), -- ipv6z(4)} McWalter, et al. Standards Track [Page 42] RFC 5132 IP MCAST MIB December 2007 -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastSsmRangeAddress -- SYNTAX InetAddress (SIZE (4|8|16|20)) -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastRouteGroupAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteGroup -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteSourceAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteSource -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteNextHopGroupAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteNextHopGroup -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteNextHopSourceAddressType McWalter, et al. Standards Track [Page 43] RFC 5132 IP MCAST MIB December 2007 -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteNextHopSource -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteNextHopAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteNextHopAddress -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6." MODULE -- this module MANDATORY-GROUPS { ipMcastMIBRouteProtoGroup, ipMcastMIBBasicGroup, ipMcastMIBSsmGroup, ipMcastMIBRouteGroup } OBJECT ipMcastEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastDeviceConfigStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastInterfaceTtl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastInterfaceRateLimit MIN-ACCESS read-only McWalter, et al. Standards Track [Page 44] RFC 5132 IP MCAST MIB December 2007 DESCRIPTION "Write access is not required." OBJECT ipMcastInterfaceStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastRouteUpstreamNeighborType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "This compliance requires support for unknown and either ipv4 or ipv6." OBJECT ipMcastRouteUpstreamNeighbor SYNTAX InetAddress (SIZE (0|4|8|16|20)) DESCRIPTION "This compliance requires support for unknown and either ipv4 or ipv6." OBJECT ipMcastRouteRtAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "This compliance requires support for unknown and either ipv4 or ipv6." OBJECT ipMcastRouteRtAddress SYNTAX InetAddress (SIZE (0|4|8|16|20)) DESCRIPTION "This compliance requires support for unknown and either ipv4 or ipv6." OBJECT ipMcastSsmRangeRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastSsmRangeStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP ipMcastMIBRouteDiagnosticsGroup DESCRIPTION "This group is not mandatory, but SHOULD be supported where hardware permits." McWalter, et al. Standards Track [Page 45] RFC 5132 IP MCAST MIB December 2007 GROUP ipMcastMIBPktsOutGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBHopCountGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBRouteOctetsGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBRouteBpsGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBLocalListenerGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBBoundaryIfGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBScopeNameGroup DESCRIPTION "This group is optional." ::= { ipMcastMIBCompliances 2 } ipMcastMIBComplianceBorderRouter MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers on scope boundaries supporting IPMCAST-MIB. Support for either InetAddressType ipv4z or ipv6z is mandatory; support for both InetAddressTypes ipv4z and ipv6z is optional. -- OBJECT ipMcastSsmRangeAddressType -- SYNTAX InetAddressType {ipv4(1), ipv6(2), ipv4z(3), -- ipv6z(4)} -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastSsmRangeAddress -- SYNTAX InetAddress (SIZE (4|8|16|20)) McWalter, et al. Standards Track [Page 46] RFC 5132 IP MCAST MIB December 2007 -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastRouteGroupAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 or ipv6. -- -- OBJECT ipMcastRouteGroup -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastRouteSourceAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastRouteSource -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastRouteNextHopGroupAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastRouteNextHopGroup -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastRouteNextHopSourceAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. McWalter, et al. Standards Track [Page 47] RFC 5132 IP MCAST MIB December 2007 -- -- OBJECT ipMcastRouteNextHopSource -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastRouteNextHopAddressType -- SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2), -- ipv4z(3), ipv6z(4)} -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastRouteNextHopAddress -- SYNTAX InetAddress (SIZE (0|4|8|16|20)) -- DESCRIPTION -- This compliance requires support for unknown and -- either ipv4 and ipv4z or ipv6 and ipv6z. -- -- OBJECT ipMcastBoundaryAddressType -- SYNTAX InetAddressType {ipv4(1), ipv6(2)} -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastBoundaryAddress -- SYNTAX InetAddress (SIZE (4|16) -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastScopeNameAddressType -- SYNTAX InetAddressType {ipv4(1), ipv6(2)} -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6. -- -- OBJECT ipMcastScopeNameAddress -- SYNTAX InetAddress (SIZE (4|16) -- DESCRIPTION -- This compliance requires support for ipv4 or ipv6." MODULE -- this module MANDATORY-GROUPS { ipMcastMIBRouteProtoGroup, ipMcastMIBBasicGroup, ipMcastMIBSsmGroup, ipMcastMIBRouteGroup, ipMcastMIBBoundaryIfGroup, ipMcastMIBScopeNameGroup } McWalter, et al. Standards Track [Page 48] RFC 5132 IP MCAST MIB December 2007 OBJECT ipMcastEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastDeviceConfigStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastInterfaceTtl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastInterfaceRateLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastInterfaceStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastRouteUpstreamNeighborType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "This compliance requires support for unknown and either ipv4 and ipv4z, or ipv6 and ipv6z." OBJECT ipMcastRouteUpstreamNeighbor SYNTAX InetAddress (SIZE (0|4|8|16|20)) DESCRIPTION "This compliance requires support for unknown and either ipv4 and ipv4z, or ipv6 and ipv6z." OBJECT ipMcastRouteRtAddressType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) } DESCRIPTION "This compliance requires support for unknown and either ipv4 and ipv4z, or ipv6 and ipv6z." OBJECT ipMcastRouteRtAddress SYNTAX InetAddress (SIZE (0|4|8|16|20)) DESCRIPTION McWalter, et al. Standards Track [Page 49] RFC 5132 IP MCAST MIB December 2007 "This compliance requires support for unknown and either ipv4 and ipv4z, or ipv6 and ipv6z." OBJECT ipMcastSsmRangeRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ipMcastSsmRangeStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP ipMcastMIBRouteDiagnosticsGroup DESCRIPTION "This group is not mandatory, but SHOULD be supported where hardware permits." GROUP ipMcastMIBPktsOutGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBHopCountGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBRouteOctetsGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBRouteBpsGroup DESCRIPTION "This group is optional." GROUP ipMcastMIBLocalListenerGroup DESCRIPTION "This group is optional." OBJECT ipMcastZoneScopeAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "This compliance requires support for ipv4 or ipv6." OBJECT ipMcastZoneScopeAddress SYNTAX InetAddress (SIZE (4|16)) DESCRIPTION "This compliance requires support for ipv4 or ipv6." McWalter, et al. Standards Track [Page 50] RFC 5132 IP MCAST MIB December 2007 ::= { ipMcastMIBCompliances 3 } -- -- Units of conformance -- ipMcastMIBBasicGroup OBJECT-GROUP OBJECTS { ipMcastEnabled, ipMcastRouteEntryCount, ipMcastDeviceConfigStorageType } STATUS current DESCRIPTION "A collection of objects to support basic management of IP Multicast protocols." ::= { ipMcastMIBGroups 1 } ipMcastMIBSsmGroup OBJECT-GROUP OBJECTS { ipMcastSsmRangeRowStatus, ipMcastSsmRangeStorageType } STATUS current DESCRIPTION "A collection of objects to support management of Source- Specific Multicast routing." ::= { ipMcastMIBGroups 2 } ipMcastMIBRouteGroup OBJECT-GROUP OBJECTS { ipMcastInterfaceTtl, ipMcastInterfaceRateLimit, ipMcastInterfaceStorageType, ipMcastRouteUpstreamNeighborType, ipMcastRouteUpstreamNeighbor, ipMcastRouteInIfIndex, ipMcastRouteTimeStamp, ipMcastRouteExpiryTime, ipMcastRouteNextHopState, ipMcastRouteNextHopTimeStamp, ipMcastRouteNextHopExpiryTime } STATUS current DESCRIPTION "A collection of objects to support basic management of IP Multicast routing." ::= { ipMcastMIBGroups 3 } ipMcastMIBRouteDiagnosticsGroup OBJECT-GROUP OBJECTS { ipMcastRoutePkts, ipMcastRouteTtlDropPackets, ipMcastRouteDifferentInIfPackets McWalter, et al. Standards Track [Page 51] RFC 5132 IP MCAST MIB December 2007 } STATUS current DESCRIPTION "A collection of routing diagnostic packet counters." ::= { ipMcastMIBGroups 4 } ipMcastMIBPktsOutGroup OBJECT-GROUP OBJECTS { ipMcastRouteNextHopTimeStamp, ipMcastRouteNextHopPkts } STATUS current DESCRIPTION "A collection of objects to support management of packet counters for each outgoing interface entry of a route." ::= { ipMcastMIBGroups 5 } ipMcastMIBHopCountGroup OBJECT-GROUP OBJECTS { ipMcastRouteNextHopClosestMemberHops } STATUS current DESCRIPTION "A collection of objects to support management of the use of hop counts in IP Multicast routing." ::= { ipMcastMIBGroups 6 } ipMcastMIBRouteOctetsGroup OBJECT-GROUP OBJECTS { ipMcastRouteTimeStamp, ipMcastRouteOctets, ipMcastRouteTtlDropOctets, ipMcastRouteDifferentInIfOctets, ipMcastRouteNextHopTimeStamp, ipMcastRouteNextHopOctets } STATUS current DESCRIPTION "A collection of objects to support management of octet counters for each forwarding entry." ::= { ipMcastMIBGroups 7 } ipMcastMIBRouteBpsGroup OBJECT-GROUP OBJECTS { ipMcastRouteBps } STATUS current DESCRIPTION "A collection of objects to support sampling of data rate in bits per second for each forwarding entry." ::= { ipMcastMIBGroups 8 } ipMcastMIBRouteProtoGroup OBJECT-GROUP OBJECTS { ipMcastRouteProtocol, ipMcastRouteRtProtocol, ipMcastRouteRtAddressType, ipMcastRouteRtAddress, ipMcastRouteRtPrefixLength, ipMcastRouteRtType, McWalter, et al. Standards Track [Page 52] RFC 5132 IP MCAST MIB December 2007 ipMcastRouteNextHopProtocol } STATUS current DESCRIPTION "A collection of objects providing information on the relationship between multicast routing information and the IP Forwarding Table." ::= { ipMcastMIBGroups 9 } ipMcastMIBLocalListenerGroup OBJECT-GROUP OBJECTS { ipMcastLocalListenerRunIndex } STATUS current DESCRIPTION "A collection of objects to support management of local listeners on hosts or routers." ::= { ipMcastMIBGroups 10 } ipMcastMIBBoundaryIfGroup OBJECT-GROUP OBJECTS { ipMcastBoundaryTimeStamp, ipMcastBoundaryDroppedMcastOctets, ipMcastBoundaryDroppedMcastPkts, ipMcastBoundaryStatus, ipMcastBoundaryStorageType, ipMcastZoneScopeDefaultZoneIndex, ipMcastZoneScopeAddressType, ipMcastZoneScopeAddress, ipMcastZoneScopeAddressPrefixLength } STATUS current DESCRIPTION "A collection of objects to support management of multicast scope zone boundaries." ::= { ipMcastMIBGroups 11 } ipMcastMIBScopeNameGroup OBJECT-GROUP OBJECTS { ipMcastScopeNameString, ipMcastScopeNameDefault, ipMcastScopeNameStatus, ipMcastScopeNameStorageType } STATUS current DESCRIPTION "A collection of objects to support management of multicast address scope names." ::= { ipMcastMIBGroups 12 } END McWalter, et al. Standards Track [Page 53] RFC 5132 IP MCAST MIB December 2007 7. Security Considerations 7.1. SNMPv3 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to access (read/change/create/delete) them. 7.2. Writeable Objects There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. This section discusses and lists these elements. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. In this MIB module, possible effects that can be induced by SET operations on writeable objects include: o Modifications to multicast routing behavior that prevent or disrupt services provided by the network, including (but not limited to) multicast data traffic delivery. o Modifications to multicast routing behavior that allow interception or subversion of information that is carried by the network. For example, attacks can be envisaged that would pass nominated multicast data streams through a nominated location, without the sources or listeners becoming aware of this subversion. McWalter, et al. Standards Track [Page 54] RFC 5132 IP MCAST MIB December 2007 The following are the read-write and read-create objects defined in this MIB module. ipMcastEnabled ipMcastDeviceConfigStorageType ipMcastInterfaceTtl ipMcastInterfaceRateLimit ipMcastInterfaceStorageType ipMcastSsmRangeRowStatus ipMcastSsmRangeStorageType ipMcastBoundaryStatus ipMcastBoundaryStorageType ipMcastScopeNameString ipMcastScopeNameDefault ipMcastScopeNameStatus ipMcastScopeNameStorageType 7.3. Readable Objects As well as the writeable objects discussed above, there are a number of readable objects (i.e., objects with a MAX-ACCESS other than not- accessible) that may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. In this MIB module, possible effects that can be induced by GET and/or NOTIFY operations include: o Determination of the topology, disposition, and composition of the network. This information may be commercially sensitive, and may also be used in preparation for attacks, including any of the attacks described above. o Determinion of whether multicast data is flowing in the network, or has flowed recently, as well as the locations of senders and recipients. An attacker can apply 'traffic analysis' to this data. In some cases, the information revealed by traffic analyses can be as damaging as full knowledge of the data being transported. 8. IANA Considerations IPMCAST-MIB is rooted under the mib-2 subtree. IANA has assigned { mib-2 168 } to the IPMCAST-MIB module specified in this document. 9. Acknowledgements This MIB module is based on the original work in [RFC2932] by K. McCloghrie, D. Farinacci, and D. Thaler. Suggested IPv6 multicast MIBs by R. Sivaramu and R. Raghunarayan have been used for comparison while editing this MIB module. McWalter, et al. Standards Track [Page 55] RFC 5132 IP MCAST MIB December 2007 The authors are grateful to Bill Fenner for fine ideas, and to Bharat Joshi for input and several corrections. The authors also wish to thank John Flick, Bert Wijnen, and Stig Venaas for their reviewing and comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, June 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. McWalter, et al. Standards Track [Page 56] RFC 5132 IP MCAST MIB December 2007 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC5131] McWalter, D., "A MIB Textual Convention for Language Tags", RFC 5131, December 2007. 10.2. Informative References [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. McWalter, et al. Standards Track [Page 57] RFC 5132 IP MCAST MIB December 2007 Authors' Addresses David McWalter Data Connection Ltd 100 Church Street Enfield EN2 6BQ UK EMail: dmcw@dataconnection.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA EMail: dthaler@windows.microsoft.com Andrew Kessler Cisco Systems 425 E. Tasman Drive San Jose, CA 95134 USA EMail: kessler@cisco.com McWalter, et al. Standards Track [Page 58] RFC 5132 IP MCAST MIB December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. McWalter, et al. Standards Track [Page 59] snmp-mibs-downloader-1.1/mibrfcs/rfc5190.txt0000644000000000000000000062020111402176072015562 0ustar Network Working Group J. Quittek Request for Comments: 5190 M. Stiemerling Category: Standards Track NEC P. Srisuresh Kazeon Systems March 2008 Definitions of Managed Objects for Middlebox Communication 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. Quittek, et al. Standards Track [Page 1] RFC 5190 MIDCOM MIB March 2008 Table of Contents 1. Introduction ....................................................4 2. The Internet-Standard Management Framework ......................4 3. Overview ........................................................4 3.1. Terminology ................................................5 4. Realizing the MIDCOM Protocol with SNMP .........................6 4.1. MIDCOM Sessions ............................................6 4.1.1. Authentication and Authorization ....................6 4.2. MIDCOM Transactions ........................................7 4.2.1. Asynchronous Transactions ...........................7 4.2.2. Configuration Transactions ..........................8 4.2.3. Monitoring Transactions ............................11 4.2.4. Atomicity of MIDCOM Transactions ...................12 4.2.4.1. Asynchronous MIDCOM Transactions ..........12 4.2.4.2. Session Establishment and Termination Transactions ..................12 4.2.4.3. Monitoring Transactions ...................13 4.2.4.4. Lifetime Change Transactions ..............13 4.2.4.5. Transactions Establishing New Policy Rules ..............................14 4.2.5. Access Control .....................................14 4.3. Access Control Policies ...................................14 5. Structure of the MIB Module ....................................15 5.1. Transaction Objects .......................................16 5.1.1. midcomRuleTable ....................................17 5.1.2. midcomGroupTable ...................................19 5.2. Configuration Objects .....................................20 5.2.1. Capabilities .......................................20 5.2.2. midcomConfigFirewallTable ..........................21 5.3. Monitoring Objects ........................................22 5.3.1. midcomResourceTable ................................22 5.3.2. midcomStatistics ...................................24 5.4. Notifications .............................................25 6. Recommendations for Configuration and Operation ................26 6.1. Security Model Configuration ..............................26 6.2. VACM Configuration ........................................27 6.3. Notification Configuration ................................28 6.4. Simultaneous Access .......................................28 6.5. Avoiding Idempotency Problems .............................29 6.6. Interface Indexing Problems ...............................29 6.7. Applicability Restrictions ................................30 7. Usage Examples for MIDCOM Transactions .........................30 7.1. Session Establishment (SE) ................................31 7.2. Session Termination (ST) ..................................31 7.3. Policy Reserve Rule (PRR) .................................31 7.4. Policy Enable Rule (PER) after PRR ........................33 7.5. Policy Enable Rule (PER) without Previous PRR .............34 Quittek, et al. Standards Track [Page 2] RFC 5190 MIDCOM MIB March 2008 7.6. Policy Rule Lifetime Change (RLC) .........................35 7.7. Policy Rule List (PRL) ....................................35 7.8. Policy Rule Status (PRS) ..................................35 7.9. Asynchronous Policy Rule Event (ARE) ......................36 7.10. Group Lifetime Change (GLC) ..............................36 7.11. Group List (GL) ..........................................36 7.12. Group Status (GS) ........................................37 8. Usage Examples for Monitoring Objects ..........................37 8.1. Monitoring NAT Resources ..................................37 8.2. Monitoring Firewall Resources .............................38 9. Definitions ....................................................38 10. Security Considerations .......................................85 10.1. General Security Issues ..................................85 10.2. Unauthorized Middlebox Configuration .....................86 10.3. Unauthorized Access to Middlebox Configuration ...........87 10.4. Unauthorized Access to MIDCOM Service Configuration ......88 11. Acknowledgements ..............................................88 12. IANA Considerations ...........................................88 13. Normative References ..........................................88 14. Informative References ........................................90 Quittek, et al. Standards Track [Page 3] RFC 5190 MIDCOM MIB March 2008 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow controlling middleboxes. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The managed objects defined in this document serve for controlling firewalls and Network Address Translators (NATs). As defined in [RFC3234], firewalls and NATs belong to the group of middleboxes. A middlebox is a device on the datagram path between source and destination, which performs other functions than just IP routing. As outlined in [RFC3303], firewalls and NATs are potential obstacles to packet streams, for example, if dynamically negotiated UDP or TCP port numbers are used, as in many peer-to-peer communication applications. As one possible solution for this problem, the IETF MIDCOM working group defined a framework [RFC3303], requirements [RFC3304], and protocol semantics [RFC5189] for communication between applications and middleboxes acting as firewalls, NATs, or a combination of both. The MIDCOM architecture and framework define a model in which trusted third parties can be delegated to assist middleboxes in performing their operations, without requiring application intelligence being embedded in the middleboxes. This trusted third party is referred to as the MIDCOM agent. The MIDCOM protocol is defined between a MIDCOM agent and a middlebox. Quittek, et al. Standards Track [Page 4] RFC 5190 MIDCOM MIB March 2008 The managed objects defined in this document can be used for dynamically configuring middleboxes on the datagram path to permit datagrams traversing the middleboxes. This way, applications can, for example, request pinholes at firewalls and address bindings at NATs. Besides managed objects for controlling the middlebox operation, this document also defines managed objects that provide information on middlebox resource usage (such as firewall pinholes, NAT bindings, NAT sessions, etc.) affected by requests. Since firewalls and NATs are critical devices concerning network security, security issues of middlebox communication need to be considered very carefully. 3.1. Terminology The terminology used in this document is fully aligned with the terminology defined in [RFC5189] except for the term 'MIDCOM agent'. For this term, there is a conflict between the MIDCOM terminology and the SNMP terminology. The roles of entities participating in SNMP communication are called 'manager' and 'agent' with the agent acting as server for requests from the manager. This use of the term 'agent' is different from its use in the MIDCOM framework: The SNMP manager corresponds to the MIDCOM agent and the SNMP agent corresponds to the MIDCOM middlebox, also called MIDCOM server. In order to avoid confusion in this document specifying a MIB module, we replace the term 'MIDCOM agent' with 'MIDCOM client'. Whenever the term 'agent' is used in this document, it refers to the SNMP agent. Figure 1 sketches the entities of MIDCOM in relationship to SNMP manager and SNMP agent. +---------+ MIDCOM +-----------+ | MIDCOM |<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM | | Client | Transaction | middlebox | | | | (server) | +---------+ +-----------+ ^ ^ | | v v +---------+ +-----------+ | SNMP | SNMP | SNMP | | Manager |<===============>| Agent | +---------+ Protocol +-----------+ Figure 1: Mapping of MIDCOM to SNMP Quittek, et al. Standards Track [Page 5] RFC 5190 MIDCOM MIB March 2008 4. Realizing the MIDCOM Protocol with SNMP In order to realize middlebox communication as described in [RFC5189], several aspects and properties of the MIDCOM protocol need to be mapped to SNMP capabilities and expressed in terms of the Structure of Management Information version 2 (SMIv2). Basic concepts to be mapped are MIDCOM sessions and MIDCOM transactions. For both, access control policies need to be supported. 4.1. MIDCOM Sessions SNMP has no direct support for sessions. Therefore, they need to be modeled. A MIDCOM session is stateful and has a context that is valid for several transactions. For SNMP, a context is valid for a single transaction only, for example, covering just a single request/reply pair of messages. Properties of sessions that are utilized by the MIDCOM semantics and not available in SNMP need to be modeled. Particularly, the middlebox needs to be able to authenticate MIDCOM clients, authorize access to policy rules, and send notification messages concerning policy rules to MIDCOM clients participating in a session. In the MIDCOM-MIB module, authentication and access control are performed on a per-message basis using an SNMPv3 security model, such as the User-based Security Model (USM) [RFC3414], for authentication, and the View-based Access Control Model (VACM) [RFC3415] for access control. Sending notifications to MIDCOM clients is controlled by access control models such as VACM and a mostly static configuration of objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP- NOTIFICATION-MIB [RFC3413]. This session model is static except that the MIDCOM client can switch on and off the generation of SNMP notifications that the middlebox sends. Recommended configurations of VACM and the SNMP-TARGET-MIB and the SNMP-NOTIFICATION-MIB that can serve for modeling a session are described in detail in section 6. 4.1.1. Authentication and Authorization MIDCOM sessions are required for providing authentication, authorization, and encryption for messages exchanged between a MIDCOM client and a middlebox. SNMPv3 provides these features on a per- message basis instead of a per-session basis applying a security model and an access control model, such as USM and VACM. Per-message Quittek, et al. Standards Track [Page 6] RFC 5190 MIDCOM MIB March 2008 security mechanisms can be considered as overhead compared to per- session security mechanisms, but it certainly satisfies the security requirements of middlebox communication. For each authenticated MIDCOM client, access to the MIDCOM-MIB, particularly to policy rules, should be configured as part of the VACM configuration of the SNMP agent. 4.2. MIDCOM Transactions [RFC5189] defines the MIDCOM protocol semantics in terms of transactions and transaction parameters. Transactions are grouped into request-reply transactions and asynchronous transactions. SNMP offers simple transactions that in general cannot be mapped one-to-one to MIDCOM transactions. This section describes how the MIDCOM-MIB module implements MIDCOM transactions using SNMP transactions. The concerned MIDCOM transactions are asynchronous transactions and request-reply transactions. Within the set of request-reply transactions, we distinguish configuration transactions and monitoring transactions, because they are implemented in slightly different ways by using SNMP transactions. The SNMP terminology as defined in [RFC3411] does not use the concept of transactions, but of SNMP operations. For the considerations in this section, we use the terms SNMP GET transaction and SNMP SET transaction. An SNMP GET transaction consists of an SNMP Read Class operation and an SNMP Response Class operation. An SNMP SET transaction consists of an SNMP Write Class operation and an SNMP Response Class operation. 4.2.1. Asynchronous Transactions Asynchronous transactions can easily be modeled by SNMP Notification Class operations. An asynchronous transaction contains a notification message with one to three parameters. The message can be realized as an SNMP Notification Class operation with the parameters implemented as managed objects contained in the notification. Quittek, et al. Standards Track [Page 7] RFC 5190 MIDCOM MIB March 2008 +--------------+ notification +------------+ | MIDCOM client|<--------------| middlebox | +--------------+ message +------------+ MIDCOM asynchronous transaction +--------------+ SNMP +------------+ | SNMP manager |<--------------| SNMP agent | +--------------+ notification +------------+ Implementation of MIDCOM asynchronous transaction Figure 2: MIDCOM asynchronous transaction mapped to SNMP Notification Class operation One of the parameters is the transaction identifier that should be unique per middlebox. It does not have to be unique for all notifications sent by the particular SNMP agent, but for all sent notifications that are defined by the MIDCOM-MIB module. Note that SNMP notifications are usually sent as unreliable UDP packets and may be dropped before they reach their destination. If a MIDCOM client is expecting an asynchronous notification on a specific transaction, it would be the job of the MIDCOM client to poll the middlebox periodically and monitor the transaction in case notifications are lost along the way. 4.2.2. Configuration Transactions All request-reply transactions contain a request message, a reply message, and potentially also a set of notifications. In general, they cannot be modeled by just having a single SNMP message per MIDCOM message, because some of the MIDCOM messages carry a large set of parameters that do not necessarily fit into an SNMP message consisting of a single UDP packet only. For configuration transactions, the MIDCOM request message can be modeled by one or more SNMP SET transactions. The action of sending the MIDCOM request to the middlebox is realized by writing the parameters contained in the message to managed objects at the SNMP agent. If necessary, the SNMP SET transaction includes creating these managed objects. If not all parameters of the MIDCOM request message can be set by a single SNMP SET transaction, then more than one SET transaction is used; see Figure 3. Completion of the last of the SNMP transactions indicates that all required parameters are set and that processing of the MIDCOM request message can start at the middlebox. Quittek, et al. Standards Track [Page 8] RFC 5190 MIDCOM MIB March 2008 Please note that a single SNMP SET transaction consists of an SNMP SET request message and an SNMP SET reply message. Both are sent as unreliable UDP packets and may be dropped before they reach their destination. If the SNMP SET request message or the SNMP reply message is lost, then the SNMP manager (the MIDCOM client) needs to take action, for example, by just repeating the SET transaction or by first checking the success of the initial write transaction with an SNMP GET transaction and then only repeating the SNMP SET transaction if necessary. +--------------+ request +------------+ | MIDCOM client|-------------->| middlebox | +--------------+ message +------------+ MIDCOM request message +--------------+ +------------+ | | SNMP SET | | | |-------------->| | | | message | | | | | | | | SNMP SET | | | |<--------------| | | | reply message | | | SNMP manager | | SNMP agent | | | SNMP SET | | | |- - - - - - - >| | | | message | | | | | | | | SNMP SET | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+ Implementation of MIDCOM request message by one or more SNMP SET transactions Figure 3: MIDCOM request message mapped to SNMP SET transactions The MIDCOM reply message can be modeled in two ways. The first way is an SNMP Notification Class operation optionally followed by one or more SNMP GET transactions as shown in Figure 4. The MIDCOM server informs the MIDCOM client about the end of processing the request by sending an SNMP notification. If possible, the SNMP notification Quittek, et al. Standards Track [Page 9] RFC 5190 MIDCOM MIB March 2008 carries all reply parameters. If this is not possible, then the SNMP manager has to perform additional SNMP GET transactions as long as necessary to receive all of the reply parameters. +--------------+ reply +------------+ | MIDCOM client|<--------------| middlebox | +--------------+ message +------------+ MIDCOM reply message +--------------+ +------------+ | | SNMP | | | |<--------------| | | | notification | | | | | | | | SNMP GET | | | |-------------->| | | | message | | | SNMP manager | | SNMP agent | | | SNMP GET | | | |<--------------| | | | reply message | | | | | | | | SNMP GET | | | |- - - - - - - >| | | | message | | | | | | | | SNMP GET | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+ Implementation of MIDCOM reply message by an SNMP notification and one or more SNMP GET transactions Figure 4: MIDCOM reply message mapped to SNMP notification and optional GET transactions The second way replaces the SNMP Notification Class operation by a polling operation of the SNMP manager. The manager polls status information at the SNMP agent using SNMP GET transactions until it detects the end of the processing of the request. Then it uses one or more SNMP GET transactions to receive all of the reply parameters. Note that this second way requires more SNMP operations, but is more Quittek, et al. Standards Track [Page 10] RFC 5190 MIDCOM MIB March 2008 reliable than the first way using an SNMP Notification Class operation. 4.2.3. Monitoring Transactions The realization of MIDCOM monitoring transactions in terms of SNMP transactions is simpler. The request message is very short and just specifies a piece of information that the MIDCOM client wants to retrieve. +--------------+ request +------------+ | |-------------->| | | | message | | | MIDCOM client| | middlebox | | | reply | | | |<--------------| | +--------------+ message +------------+ MIDCOM monitoring transaction +--------------+ +------------+ | | SNMP GET | | | |-------------->| | | | message | | | | | | | | SNMP GET | | | |<--------------| | | | reply message | | | SNMP manager | | SNMP agent | | | SNMP GET | | | |- - - - - - - >| | | | message | | | | | | | | SNMP GET | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+ Implementation of MIDCOM monitoring transaction by one or more SNMP GET messages Figure 5: MIDCOM monitoring transaction mapped to SNMP GET transactions Quittek, et al. Standards Track [Page 11] RFC 5190 MIDCOM MIB March 2008 Since monitoring is a strength of SNMP, there are sufficient means to realize MIDCOM monitoring transactions simpler than MIDCOM configuration transactions. All MIDCOM monitoring transactions can be realized as a sequence of SNMP GET transactions. The number of SNMP GET transactions required depends on the amount of information to be retrieved. 4.2.4. Atomicity of MIDCOM Transactions Given the realizations of MIDCOM transactions by means of SNMP transactions, atomicity of the MIDCOM transactions is not fully guaranteed anymore. However, this section shows that atomicity provided by the MIB module specified in section 9 is still sufficient for meeting the MIDCOM requirements specified in [RFC3304]. 4.2.4.1. Asynchronous MIDCOM Transactions There are two asynchronous MIDCOM transactions: Asynchronous Session Termination (AST) and Asynchronous Policy Rule Event (ARE). The very static realization of MIDCOM sessions in the MIDCOM-MIB, as described by section 4.1, does not anymore support the asynchronous termination of a session. Therefore, the AST transaction is not modeled. For the ARE, atomicity is maintained, because it is modeled by a single atomic SNMP notification transaction. In addition, the MIDCOM-MIB supports an Asynchronous Group Event transaction, which is an aggregation of a set of ARE transactions. Also, this MIDCOM transaction is implemented by a single SNMP transaction. 4.2.4.2. Session Establishment and Termination Transactions The MIDCOM-MIB models MIDCOM sessions in a very static way. The only dynamic actions within these transactions are enabling and disabling the generation of SNMP notifications at the SNMP agent. For the Session Establishment (SE) transaction, the MIDCOM client first reads the middlebox capabilities. It is not relevant whether or not this action is atomic because a dynamic change of the middlebox capabilities is not to be expected. Therefore, also non- atomic implementations of this action are acceptable. Then, the MIDCOM agent needs to enable the generation of SNMP notifications at the middlebox. This can be realized by writing to a single managed object in the SNMP-NOTIFICATION-MIB [RFC3413]. But even other implementations are acceptable, because atomicity is not required for this step. Quittek, et al. Standards Track [Page 12] RFC 5190 MIDCOM MIB March 2008 For the Session Termination (ST) transaction, the only required action is disabling the generation of SNMP notifications at the middlebox. As for the SE transaction, this action can be realized atomically by using the SNMP-NOTIFICATION-MIB, but also other implementations are acceptable because atomicity is not required for this action. 4.2.4.3. Monitoring Transactions Potentially, the monitoring transactions Policy Rule List (PRL), Policy Rule Status (PRS), Group List (GL), and Group Status (GS) are not atomic, because these transactions may be implemented by more than one SNMP GET operation. The problem that might occur is that while the monitoring transaction is performed, the monitored items may change. For example, while reading a long list of policies, new policies may be added and already read policies may be deleted. This is not in line with the protocol semantics. However, it is not in direct conflict with the MIDCOM requirement requesting the middlebox state to be stable and known by the MIDCOM client, because the middlebox notifies the MIDCOM client on all changes to its state that are performed during the monitoring transaction by sending notifications. If the MIDCOM client receives such a notification while performing a monitoring transaction (or shortly after completing it), the MIDCOM client can then either repeat the monitoring transaction or integrate the result of the monitoring transaction with the information received via notifications during the transaction. In both cases, the MIDCOM client will know the state of the middlebox. 4.2.4.4. Lifetime Change Transactions For the policy Rule Lifetime Change (RLC) transaction and the Group Lifetime Change (GLC) transaction, atomicity is maintained. They both have very few parameters for the request message and the reply message. The request parameters can be transmitted by a single SNMP SET request message, and the reply parameters can be transmitted by a single SNMP notification message. In order to prevent idempotency problems by retransmitting an SNMP request after a lost SNMP reply, it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is included in the corresponding SNMP SET request or the value of the SNMP retransmission timer be lower than the smallest requested lifetime value. The same recommendation applies to the smallest requested value for the midcomRuleStorageTime. MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent. Quittek, et al. Standards Track [Page 13] RFC 5190 MIDCOM MIB March 2008 4.2.4.5. Transactions Establishing New Policy Rules Analogous to the monitoring transactions, the atomicity may not be given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions. Both transactions are potentially implemented using more than one SNMP SET operation and GET operation for obtaining transaction reply parameters. The solution for this loss of atomicity is the same as for the monitoring transactions. There is an additional atomicity problem for PRR and PER. If transferring request parameters requires more than a single SET operation, then there is the potential problem that multiple MIDCOM clients sharing the same permissions are able to access the same policy rule. In this case, a client could alter request parameters already set by another client before the first client could complete the request. However, this is acceptable since usually only one agent is creating a policy rule and filling it subsequently. It can also be assumed that in most cases where clients share permissions, they act in a more or less coordinated way avoiding such interferences. All atomicity problems caused by using multiple SNMP SET transactions for implementing the MIDCOM request message can be avoided by transferring all request parameters with a single SNMP SET transaction. 4.2.5. Access Control Since SNMP does not offer per-session authentication and authorization, authentication and authorization are performed per SNMP message sent from the MIDCOM client to the middlebox. For each transaction, the MIDCOM client has to authenticate itself as an authenticated principal, such as a USM user. Then, the principal's access rights to all resources affected by the transaction are checked. Access right control is realized by configuring the access control mechanisms, such as VACM, at the SNMP agent. 4.3. Access Control Policies Potentially, a middlebox has to control access for a large set of MIDCOM clients and to a large set of policy rules configuring firewall pinholes and NAT bindings. Therefore, it can be beneficial to use access control policies for specifying access control rules. Generating, provisioning, and managing these policies are out of scope of this MIB module. Quittek, et al. Standards Track [Page 14] RFC 5190 MIDCOM MIB March 2008 However, if such an access control policy system is used, then the SNMP agent acts as a policy enforcement point. An access control policy system must transform all active policies into configurations of, for example, the SNMP agent's View-based Access Control Model (VACM). The mechanisms of access control models, such as VACM, allow an access control policy system to enforce MIDCOM client authentication rules and general access control of MIDCOM clients to middlebox control. The mechanisms of VACM can be used to enforce access control of authenticated clients to MIDCOM-MIB policy rules based on the concept of ownership. For example, an access control policy can specify that MIDCOM-MIB policy rules owned by user A cannot be accessed at all by user B, can be read by user C, and can be read and modified by user D. Further access control policies can control access to concrete middlebox resources. These are enforced, when a MIDCOM request is processed. For example, an authenticated MIDCOM client may be authorized to request new MIDCOM policies to be established, but only for certain IP address ranges. The enforcement of this kind of policies may not be realizable using available SNMP mechanisms, but needs to be performed by the individual MIB module implementation. 5. Structure of the MIB Module The MIB module defined in section 9 contains three kinds of managed objects: - Transaction objects Transaction objects are required for implementing the MIDCOM protocol requirements defined in [RFC3304] and the MIDCOM protocol semantics defined in [RFC5189]. - Configuration objects Configuration objects can be used for retrieving middlebox capability information (mandatory) and for setting parameters of the implementation of transaction objects (optional). - Monitoring objects The optional monitoring objects provide information about used resources and about MIDCOM transaction statistics. The transaction objects are organized in two tables: the midcomRuleTable and the midcomGroupTable. Entity relationships of Quittek, et al. Standards Track [Page 15] RFC 5190 MIDCOM MIB March 2008 entries of these tables and the midcomResourceTable from the monitoring objects are illustrated by Figure 6. +--------------------+ | midcomRuleEntry | | indexed by | | midcomRuleOwner | | midcomGroupIndex | | midcomRuleIndex | +--------------------+ 1...n | | 1 | | 1 | | 1 +--------------------+ +---------------------+ | midcomGroupEntry | | midcomResourceEntry | | indexed by | | indexed by | | midcomRuleOwner | | midcomRuleOwner | | midcomGroupIndex | | midcomGroupIndex | +--------------------+ | midcomRuleIndex | +---------------------+ | | | | | | v v v NAT Firewall other MIB MIB MIB Figure 6: Entity relationships of table entries A MIDCOM client can create and delete entries in the midcomRuleTable. Entries in the midcomGroupTable are generated automatically as soon as there is an entry in the midcomRuleTable using the midcomGroupIndex. The midcomGroupTable can be used as shortcut for accessing all member rules with a single transaction. MIDCOM clients can group policy rules for various purposes. For example, they can assign a unique value for the midcomGroupIndex to all rules belonging to a single application or an application session served by the MIDCOM agent. The midcomResourceTable augments the midcomRuleTable by information on the relationship of entries of the midcomRuleTable to resources listed in other MIB modules, such as the NAT-MIB [RFC4008]. 5.1. Transaction Objects The transaction objects are structured according to the MIDCOM semantics described in [RFC5189] into two subtrees, one for policy rule control and one for policy rule group control. Quittek, et al. Standards Track [Page 16] RFC 5190 MIDCOM MIB March 2008 5.1.1. midcomRuleTable The midcomRuleTable contains information about policy rules including policy rules to be established, policy rules for which establishing failed, established policy rules, and terminated policy rules. Entries in this table are indexed by the combination of midcomRuleOwner, midcomGroupIndex, and midcomRuleIndex. The midcomRuleOwner is the owner of the rule; the midcomGroupIndex is the index of the group of which the policy rule is a member. midcomRuleOwner is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-based Access Control Model (VACM [RFC3415]) and allows a management application to identify its entries. Entries in this table are created by writing to midcomRuleRowStatus. Entries are removed when both their midcomRuleLifetime and midcomRuleStorageTime are timed out by counting down to 0. A MIDCOM client can explicitly remove an entry by setting midcomRuleLifetime and midcomRuleStorageTime to 0. The table contains the following columnar objects: o midcomRuleIndex The index of this entry must be unique in combination with the midcomRuleOwner and the midcomGroupIndex of the entry. o midcomRuleAdminStatus For establishing a new policy rule, a set of objects in this entry needs to be written first. These objects are the request parameters. Then, by writing either reserve(1) or enable(2) to this object, the MIDCOM-MIB implementation is triggered to start processing the parameters and tries to establish the specified policy rule. o midcomRuleOperStatus This read-only object indicates the current status of the entry. The entry may have an initializing state, it may have a transient state while processing requests, it may have an error state after a request was rejected, it may have a state where a policy rule is established, or it may have a terminated state. o midcomRuleStorageType This object indicates whether or not the policy rule is stored as volatile, non-volatile, or permanent. Depending on the MIDCOM- MIB implementation, this object may be writable. Quittek, et al. Standards Track [Page 17] RFC 5190 MIDCOM MIB March 2008 o midcomRuleStorageTime This object indicates how long the entry will still exist after entering an error state or a termination state. o midcomRuleError This object is a string indicating the reason for entering an error state. o midcomRuleInterface This object indicates the IP interface for which enforcement of a policy rule is requested or performed, respectively. o midcomRuleFlowDirection This object indicates a flow direction for which a policy enable rule was requested or established, respectively. o midcomRuleMaxIdleTime This object indicates the maximum idle time of the policy rule in seconds. If no packet to which the policy rule applies passes the middlebox for the time specified by midcomRuleMaxIdleTime, then the policy rule enters a termination state. o midcomRuleTransportProtocol This object indicates a transport protocol for which a policy reserve rule or policy enable rule was requested or established, respectively. o midcomRulePortRange This object indicates a port range for which a policy reserve rule or policy enable rule was requested or established, respectively. o midcomRuleLifetime This object indicates the remaining lifetime of an established policy rule. The MIDCOM client can change the remaining lifetime by writing to it. Beyond the listed objects, the table contains 10 further objects describing address parameters. They include the IP version, IP address, prefix length and port number for the internal address (A0), inside address (A1), outside address (A2), and external address (A3). These objects serve as parameters specifying a request or an established policy, respectively. A0, A1, A2, and A3 are address tuples defined according to the MIDCOM semantics [RFC5189]. Each of them identifies either a communication endpoint at an internal or external device or an allocated address at the middlebox. Quittek, et al. Standards Track [Page 18] RFC 5190 MIDCOM MIB March 2008 +----------+ +----------+ | internal | A0 A1 +-----------+ A2 A3 | external | | endpoint +----------+ middlebox +----------+ endpoint | +----------+ +-----------+ +----------+ Figure 7: Address tuples A0 - A3 - A0 - internal endpoint: Address tuple A0 specifies a communication endpoint of a device within the internal network, with respect to the middlebox. - A1 - middlebox inside address: Address tuple A1 specifies a virtual communication endpoint at the middlebox within the internal network. A1 is the destination address for packets passing from the internal endpoint to the middlebox and is the source for packets passing from the middlebox to the internal endpoint. - A2 - middlebox outside address: Address tuple A2 specifies a virtual communication endpoint at the middlebox within the external network. A2 is the destination address for packets passing from the external endpoint to the middlebox and is the source for packets passing from the middlebox to the external endpoint. - A3 - external endpoint: Address tuple A3 specifies a communication endpoint of a device within the external network, with respect to the middlebox. The MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This might be a problem for applications that are not designed in a firewall-friendly way. An example is an FTP application that uses the PORT command (instead of the recommended PASV command). The problem only occurs when the middlebox offers twice-NAT functionality, and it can be fixed following recommendations for firewall-friendly communication. 5.1.2. midcomGroupTable The midcomGroupTable has an entry per existing policy rule group. Entries in this table are created automatically when creating member entries in the midcomRuleTable. Entries are automatically removed from this table when the last member entry is removed from the midcomRuleTable. Entries cannot be created or removed explicitly by the MIDCOM client. Quittek, et al. Standards Track [Page 19] RFC 5190 MIDCOM MIB March 2008 Entries are indexed by the midcomRuleOwner of the rules that belong to the group and by a specific midcomGroupIndex. This allows each midcomRuleOwner to maintain its own independent group namespace. An entry of the table contains the following objects: o midcomGroupIndex The index of this entry must be unique in combination with the midcomRuleOwner of the entry. o midcomGroupLifetime This object indicates the maximum of the remaining lifetimes of all established policy rules that are members of the group. The MIDCOM client can change the remaining lifetime of all member policies by writing to this object. 5.2. Configuration Objects The configuration subtree contains middlebox capability and configuration information. Some of the contained objects are (optionally) writable and can also be used for configuring the middlebox service. The capabilities subtree contains some general capability information and detailed information per supported IP interface. The midcomConfigFirewallTable can be used to configure how the MIDCOM-MIB implementation creates firewall rules in its firewall modules. Note that typically, configuration objects are not intended to be written by MIDCOM clients. In general, write access to these objects needs to be restricted more strictly than write access to transaction objects. 5.2.1. Capabilities Information on middlebox capabilities, i.e., capabilities of the MIDCOM-MIB implementation, is provided by the midcomCapabilities subtree of managed objects. The following objects are defined: o midcomConfigMaxLifetime This object indicates the maximum lifetime that this middlebox allows policy rules to have. o midcomConfigPersistentRules This is a boolean object indicating whether or not the middlebox is capable of storing policy rules persistently. Quittek, et al. Standards Track [Page 20] RFC 5190 MIDCOM MIB March 2008 Further capabilities are provided by the midcomConfigIfTable per IP interface. This table contains just two objects. The first one is a BITS object called midcomConfigIfBits containing the following bit values: o ipv4 and ipv6 These two bit values provide information on which IP versions are supported by the middlebox at the indexed interface. o addressWildcards and portWildcards These two bit values provide information on wildcarding supported by the middlebox at the indexed interface. o firewall and nat These two bit values provide information on availability of firewall and NAT functionality at the indexed interface. o portTranslation, protocolTranslation, and twiceNat These three bit values provide information on the kind of NAT functionality available at the indexed interface. o inside This bit indicates whether or not the indexed interface is an inside interface with respect to NAT functionality. The second object, called midcomConfigIfEnabled, indicates whether the middlebox capabilities described by midcomConfigIfBits are available or not available at the indexed IP interface. The midcomConfigIfTable uses index 0 for indicating capabilities that are available for all interfaces. 5.2.2. midcomConfigFirewallTable The midcomConfigFirewallTable serves for configuring how policy rules created by MIDCOM clients are realized as firewall rules of a firewall implementation. Particularly, the priority used for MIDCOM-MIB policy rules can be configured. For a single firewall implementation at a particular IP interface, all MIDCOM-MIB policy rules are realized as firewall rules with the same priority. Also, a firewall rule group name can be configured. The table is indexed by the IP interface index. An entry of the table contains the following objects: o midcomConfigFirewallGroupId This object indicates the firewall rule group to which all firewall rules of the MIDCOM server are assigned. Quittek, et al. Standards Track [Page 21] RFC 5190 MIDCOM MIB March 2008 o midcomConfigFirewallPriority This object indicates the priority assigned to all firewall rules of the MIDCOM server. 5.3. Monitoring Objects The monitoring objects are structured into two subtrees: the resource subtree and the statistics subtree. The resource subtree provides information about which resources are used by which policy rule. The statistics subtree provides statistics about the usage of transaction objects. 5.3.1. midcomResourceTable Information about resource usage per policy rule is provided by the midcomResourceTable. Each entry in the midcomResourceTable describes resource usage of exactly one policy rule. Resources are NAT resources and firewall resources, depending on the type of middlebox. Used NAT resources include NAT bindings and NAT sessions. NAT address mappings are not covered. For firewalls, firewall filter rules are considered as resources. The values provided by the following objects on NAT binds and NAT sessions may refer to the detailed resource usage description in the NAT-MIB module [RFC4008]. The values provided by the following objects on firewall rules may refer to more detailed firewall resource usage descriptions in other MIB modules. Entries in the midcomResourceTable are only valid if the midcomRuleOperStatus object of the corresponding entry in the midcomRuleTable has a value of either reserved(7) or enabled(8). An entry of the table contains the following objects: o midcomRscNatInternalAddrBindMode This object indicates whether the binding of the internal address is an address NAT binding or an address-port NAT binding. o midcomRscNatInternalAddrBindId This object identifies the NAT binding for the internal address in the NAT engine. o midcomRscNatExternalAddrBindMode This object indicates whether the binding of the external address is an address NAT binding or an address-port NAT binding. Quittek, et al. Standards Track [Page 22] RFC 5190 MIDCOM MIB March 2008 o midcomRscNatExternalAddrBindId This object identifies the NAT binding for the external address in the NAT engine. o midcomRscNatSessionId1 This object links to the first NAT session associated with one of the above NAT bindings. o midcomRscNatSessionId2 This object links to the optional second NAT session associated with one of the above NAT bindings. o midcomRscFirewallRuleId This object indicates the firewall rule for this policy rule. The MIDCOM-MIB module does not require a middlebox to implement further specific middlebox (NAT, firewall, etc.) MIB modules as, for example, the NAT-MIB module [RFC4008]. The resource identifiers in the midcomResourceTable may be vendor proprietary in the cases where the middlebox does not implement the NAT-MIB [RFC4008] or a firewall MIB. The MIDCOM-MIB module affects NAT binding and sessions, as well as firewall pinholes. It is intentionally not specified in the MIDCOM-MIB module how these NAT and firewall resources are allocated and managed, since this depends on the MIDCOM-MIB implementation and middlebox's capabilities. However, the midcomResourceTable is useful for understanding which resources are affected by which MIDCOM-MIB transaction. The midcomResourceTable is beneficial to the middlebox administrator in that the table lists all MIDCOM transactions and the middlebox specific resources to which these transactions refer. For instance, multiple MIDCOM clients might end up using the same NAT bind, yet each MIDCOM client might define a Lifetime parameter and directionality for the bind that is specific to the transaction. MIDCOM-MIB implementations are responsible for impacting underlying middlebox resources so as to satisfy the sometimes overlapping requirements on the same resource from multiple MIDCOM clients. Managing these resources is not a trivial task for MIDCOM-MIB implementers. It is possible that different MIDCOM-MIB policy rules owned by different MIDCOM clients share a NAT binding or a firewall rule. Then common properties, for example, the lifetime of the resource, need to be managed such that all clients are served well and changes to these resources need to be communicated to all affected clients. Also, dependencies between resources, for example, the precedence order of firewall rules, need to be considered Quittek, et al. Standards Track [Page 23] RFC 5190 MIDCOM MIB March 2008 carefully in order to avoid that different policy rules -- potentially owned by different clients -- influence each other. MIDCOM clients may use the midcomResourceTable of the MIDCOM-MIB module in conjunction with the NAT-MIB module [RFC4008] to determine which resources of the NAT are used for MIDCOM. The NAT-MIB module stores the configured NAT bindings and sessions, and MIDCOM clients can use the information of the midcomResourceTable to sort out those NAT resources that are used by the MIDCOM-MIB module. 5.3.2. midcomStatistics The statistics subtree contains a set of non-columnar objects that provide 'MIDCOM protocol statistics', i.e., statistics about the usage of transaction objects. o midcomCurrentOwners This object indicates the number of different values for midcomRuleOwner for all current entries in the midcomRuleTable. o midcomOwnersTotal This object indicates the summarized number of all different values that occurred for midcomRuleOwner in the midcomRuleTable current and in the past. o midcomTotalRejectedRuleEntries This object indicates the total number of failed attempts to create an entry in the midcomRuleTable. o midcomCurrentRulesIncomplete This object indicates the total number of policy rules that have not been fully loaded into a table row of the midcomRuleTable. o midcomTotalIncorrectReserveRules This object indicates the total number of policy reserve rules that were rejected because the request was incorrect. o midcomTotalRejectedReserveRules This object indicates the total number of policy reserve rules that were failed while being processed. o midcomCurrentActiveReserveRules This object indicates the number of currently active policy reserve rules in the midcomRuleTable. o midcomTotalExpiredReserveRules This object indicates the total number of expired policy reserve rules. Quittek, et al. Standards Track [Page 24] RFC 5190 MIDCOM MIB March 2008 o midcomTotalTerminatedOnRqReserveRules This object indicates the total number of policy reserve rules that were terminated on request. o midcomTotalTerminatedReserveRules This object indicates the total number of policy reserve rules that were terminated, but not on request. o midcomTotalIncorrectEnableRules This object indicates the total number of policy enable rules that were rejected because the request was incorrect. o midcomTotalRejectedEnableRules This object indicates the total number of policy enable rules that were failed while being processed. o midcomCurrentActiveEnableRules This object indicates the number of currently active policy enable rules in the midcomRuleTable. o midcomTotalExpiredEnableRules This object indicates the total number of expired policy enable rules. o midcomTotalTerminatedOnRqEnableRules This object indicates the total number of policy enable rules that were terminated on request. o midcomTotalTerminatedEnableRules This object indicates the total number of policy enable rules that were terminated, but not on request. 5.4. Notifications For informing MIDCOM clients about state changes of MIDCOM-MIB implementations, three notifications can be used. They notify the MIDCOM client about state changes of individual policy rules or of groups of policy rules. Different notifications are used for different kinds of transactions. For asynchronous transactions, unsolicited notifications are used. The only asynchronous transaction that needs to be modeled by the MIDCOM-MIB is the Asynchronous Policy Rule Event (ARE). The ARE may be caused by the expiration of a policy rule lifetime, the expiration of the idle time, or an internal change in policy rule lifetime by the MIDCOM-MIB implementation for whatever reason. Quittek, et al. Standards Track [Page 25] RFC 5190 MIDCOM MIB March 2008 For configuration transactions, solicited notifications are used. This concerns the Policy Reserve Rule (PRR) transaction, the Policy Enable Rule (PER) transaction, the Policy Rule Lifetime Change (RLC) transaction, and the Group Lifetime Change (GLC) transaction. The separation between unsolicited and solicited notifications gives the implementer of a MIDCOM client some freedom to make design decisions on how to model the MIDCOM reply message as described at the end of section 4.2.2. Depending on the choice, processing of solicited notifications may not be required. In such a case, delivery of solicited notification may be disabled, for example, by an appropriate configuration of the snmpNotifyFilterTable such that solicited notifications are filtered differently to unsolicited notifications. o midcomUnsolicitedRuleEvent This notification can be generated for indicating the change of a policy rule's state or lifetime. It is used for performing the ARE transaction. o midcomSolicitedRuleEvent This notification can be generated for indicating the requested change of a policy rule's state or lifetime. It is used for performing PRR, PER, and RLC transactions. o midcomSolicitedGroupEvent This notification can be generated for indicating the requested change of a policy rule group's lifetime. It is used for performing the GLC transaction. 6. Recommendations for Configuration and Operation Configuring MIDCOM-MIB security is highly sensitive for obvious reasons. This section gives recommendations for securely configuring the SNMP agent acting as MIDCOM server. In addition, recommendations for avoiding idempotency problems are given and restrictions of MIDCOM-MIB applicability to a special set of applications are discussed. 6.1. Security Model Configuration Since controlling firewalls and NATs is highly sensitive, it is RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB module use the authPriv security level for all users that may access managed objects of the MIDCOM-MIB module. Quittek, et al. Standards Track [Page 26] RFC 5190 MIDCOM MIB March 2008 6.2. VACM Configuration Entries in the midcomRuleTable and the midcomGroupTable provide information about existing firewall pinholes and/or NAT sessions. They also could be used for manipulating firewall pinholes and/or NAT sessions. Therefore, access control to these objects is essential and should be restrictive. It is RECOMMENDED that SNMP Command Responders instantiating an implementation of the MIDCOM-MIB module use VACM for controlling access to managed objects in the midcomRuleTable and the midcomGroupTable. It is further RECOMMENDED that individual MIDCOM clients, acting as SNMP Command Generators, only have access to an entry in the midcomRuleTable, the midcomResourceTable, or the midcomGroupTable, if they created the entry directly in the midcomRuleTable or indirectly in the midcomGroupTable and midcomResourceTable. Exceptions to this recommendation are situations where access by multiple MIDCOM clients to managed objects is explicitly required. One example is fail-over for MIDCOM agents where the stand-by MIDCOM agent needs the same access rights to managed objects as the currently active MIDCOM agent. Another example is a supervisor MIDCOM agent that monitors activities of other MIDCOM agents and/or may be used by network management systems to modify entries in tables of the MIDCOM-MIB. For this reason, all three tables listed above have the midcomRuleOwner as initial index. It is RECOMMENDED that MIDCOM clients acting as SNMP Command Generator have access to the midcomRuleTable and the midcomGroupTable restricted to entries with the initial index matching either their SNMP securityName or their VACM groupName. It is RECOMMENDED that they do not have access to entries in these tables with initial indices other than their SNMP securityName or their VACM groupName. It is RECOMMENDED that this VACM configuration is applied to read access, write access, and notify access for all objects in the midcomRuleTable and the midcomGroupTable. Note that less restrictive access rights MAY be granted to other users, for example, to a network management application, that monitors MIDCOM policy rules. Quittek, et al. Standards Track [Page 27] RFC 5190 MIDCOM MIB March 2008 6.3. Notification Configuration For each MIDCOM client that has access to the midcomRuleTable, a notification target SHOULD be configured at a Command Responder instantiating an implementation of the MIDCOM-MIB. It is RECOMMENDED that such a configuration be retrievable from the Command Responder via the SNMP-TARGET-MIB [RFC3413]. For each entry of the snmpTargetAddrTable that is related to a MIDCOM client, there SHOULD be an individual corresponding entry in the snmpTargetParamsTable. An implementation of the MIDCOM-MIB SHOULD also implement the SNMP- NOTIFICATION-MIB [RFC3413]. An instance of an implementation of the MIDCOM-MIB SHOULD have an individual entry in the snmpNotifyFilterProfileTable for each MIDCOM client that has access to the midcomRuleTable. An instance of an implementation of the MIDCOM-MIB SHOULD allow MIDCOM clients to start and stop the generation of notifications targeted at themselves. This SHOULD be realized by giving the MIDCOM clients write access to the snmpNotifyFilterTable. If appropriate entries of the snmpNotifyFilterTable are established in advance, then this can be achieved by granting MIDCOM clients write access only to the columnar object snmpNotifyFilterType. It is RECOMMENDED that VACM be configured such that each MIDCOM agent can only access entries in the snmpTargetAddrTable, the snmpTargetParamsTable, the snmpNotifyFilterProfileTable, and the snmpFilterTable that concern that particular MIDCOM agent. Typically, read access to the snmpTargetAddrTable, the snmpTargetParamsTable, and the snmpNotifyFilterProfileTable is sufficient. Write access may be required for objects of the snmpFilterTable. 6.4. Simultaneous Access Situations with two MIDCOM clients simultaneously modifying the same policy rule should be avoided. For each entry in the midcomRuleTable, there should be only one client at a time that modifies it. If two MIDCOM clients share the same midcomRuleOwner index of the midcomRuleTable, then conflicts can be avoided, for example, by - scheduling access times, as, for example, in the fail-over case; - using different midcomGroupIndex values per client; or - using non-overlapping intervals for values of the midcomRuleIndex per client. Quittek, et al. Standards Track [Page 28] RFC 5190 MIDCOM MIB March 2008 6.5. Avoiding Idempotency Problems As already discussed in section 4.2.4.4, the following recommendation is given for avoiding idempotency problems. In general, idempotency problems can be solved by including snmpSetSerialNo (see [RFC3418]) in SNMP SET requests. In case this feature is not used, it is RECOMMENDED that the value of the SNMP retransmission timer of a MIDCOM client (acting as SNMP Command Generator) is lower than the smallest requested value for any rule lifetime or rule idle time in order to prevent idempotency problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime when retransmitting an SNMP SET request after a lost SNMP reply. MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent. Similar considerations apply to MIDCOM-MIB implementations acting as Notification Originator when sending a notification (midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent or midcomSolicitedGroupEvent) containing the remaining lifetime of a policy rule or a policy rule group, respectively. 6.6. Interface Indexing Problems A well-known problem of MIB modules is indexing IP interfaces after a re-initialization of the managed device. The index for interfaces provided by the ifTable (see IF-MIB in [RFC2863]) may change during re-initialization, for example, when physical interfaces are added or removed. The MIDCOM-MIB module uses the interface index for indicating at which interface which policy rule is (or is to be) applied. Also, this index is used for indicating how policy rules are prioritized at certain interfaces. The MIDCOM-MIB module specification requires that information provided is always correct. This implies that after re-initialization, interface index values of policy rules or firewall configurations may have changed even though they still refer to the same interface as before the re-initialization. MIDCOM client implementations need to be aware of this potential behavior. It is RECOMMENDED that before writing the value or using the value of indices that depend on the ifTable the MIDCOM client checks if the middlebox has been re-initialized recently. Quittek, et al. Standards Track [Page 29] RFC 5190 MIDCOM MIB March 2008 MIDCOM-MIB module implementations MUST track interface changes of IP interface indices in the ifTable. This implies that after a re- initialization of a middlebox, a MIDCOM-MIB implementation MUST make sure that each instance of an interface index in the MIDCOM-MIB tables still points to the same interface as before the re- initialization. For any instance for which this is not possible, all affected entries in tables of the MIDCOM-MIB module MUST be either terminated, disabled, or deleted, as specified in the DESCRIPTION clause of the respective object. This concerns all objects in the MIDCOM-MIB module that are of type InterfaceIndexOrZero. 6.7. Applicability Restrictions As already discussed in section 5.1.1, the MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This can be a problem for applications that do not have this information available when they need to configure the middlebox. For some applications, there are usage scenarios where address information is only available for a single address realm, A0 and A1 in the private realm or A2 and A3 in the public realm. An example is an FTP application using the PORT command (instead of the PASV command). The problem occurs when the middlebox offers twice-NAT functionality. 7. Usage Examples for MIDCOM Transactions This section presents some examples that explain how a MIDCOM client acting as SNMP manager can use the MIDCOM-MIB module defined in this memo. The purpose of these examples is to explain the steps that are required to perform MIDCOM transactions. For each MIDCOM transaction defined in the MIDCOM semantics [RFC5189], a sequence of SNMP operations that realizes the transaction is described. The examples described below are recommended procedures for MIDCOM clients. Clients may choose to operate differently. For example, they may choose not to receive solicited notifications on completion of a transaction, but to poll the MIDCOM-MIB instead until the transaction is completed. This can be achieved by performing step 2 of the SE transaction (see below) differently. The MIDCOM agent then creates an entry in the snmpNotifyFilterTable such that only the midcomUnsolicitedRuleEvent may pass the filter and is sent to the MIDCOM client. In this case, the PER, PRR, and RLC transactions require a polling loop wherever in the example below the MIDCOM client waits for a notification. Quittek, et al. Standards Track [Page 30] RFC 5190 MIDCOM MIB March 2008 7.1. Session Establishment (SE) The MIDCOM-MIB realizes most properties of MIDCOM sessions in a very static way. Only the generation of notifications targeted at the MIDCOM client is enabled by the client for session establishment. 1. The MIDCOM client checks the middlebox capabilities by reading objects in the midcomCapabilitiesGroup. 2. The MIDCOM client enables generation of notifications on events concerning the policy rules controlled by the client. If the SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 of this document, then the agent just has to change the value of a object snmpNotifyFilterType in the corresponding entry of the snmpNotifyFilterTable from included(1) to excluded(2). 7.2. Session Termination (ST) For terminating a session, the MIDCOM client just disables the generation of notifications for this client. 1. The MIDCOM client disables generation of notifications on events concerning the policy rules controlled by the client. If the SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 of this document, then the agent just has to change the value of a object snmpNotifyFilterType in the corresponding entry of the snmpNotifyFilterTable from included(1) to excluded(2). 7.3. Policy Reserve Rule (PRR) This example explains steps that may be performed by a MIDCOM client to establish a policy reserve rule. 1. The MIDCOM client creates a new entry in the midcomRuleTable by writing to midcomRuleRowStatus. The chosen value for index object midcomGroupIndex determines the group membership of the created rule. Note that choosing an unused value for midcomGroupIndex creates a new entry in the midcomGroupTable. 2. The MIDCOM client sets the following objects in the new entry of the midcomRuleTable to specify all request parameters of the PRR transaction: - midcomRuleMaxIdleTime - midcomRuleInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion Quittek, et al. Standards Track [Page 31] RFC 5190 MIDCOM MIB March 2008 - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleLifetime Note that several of these parameters have default values that can be used. 3. The MIDCOM client sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to reserve(1). 4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the new policy rule in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations. 5. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PRR transaction: - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleMaxIdleTime - midcomRuleLifetime If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason. 6. Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the middlebox resources allocated for this policy reserve rule. Note that PRR does not necessarily allocate any middlebox resource visible in the NAT-MIB module or in a firewall MIB module, since it does a reservation only. If, however, the PRR overlaps with already existing PERs, then the PRR may be related to middlebox resources visible in other MIB modules. Quittek, et al. Standards Track [Page 32] RFC 5190 MIDCOM MIB March 2008 7.4. Policy Enable Rule (PER) after PRR This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule after a corresponding policy reserve rule was already established. 1. The MIDCOM client sets the following objects in the row of the established PRR in the midcomRuleTable to specify all request parameters of the PER transaction: - midcomRuleMaxIdleTime - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleFlowDirection Note that several of these parameters have default values that can be used. 2. The MIDCOM client sets the midcomRuleAdminStatus objects in the row of the established PRR in the midcomRuleTable to enable(1). 3. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the new row in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations. 4. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PER transaction: - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleMaxIdleTime If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason. 5. Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the allocated middlebox resources for this policy enable rule. Quittek, et al. Standards Track [Page 33] RFC 5190 MIDCOM MIB March 2008 7.5. Policy Enable Rule (PER) without Previous PRR This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule for which no PRR transaction has been performed before. 1. Identical to step 1 for PRR (section 7.3). 2. Identical to step 2 for PRR (section 7.3). 3. The MIDCOM client sets the following objects in the new row of the midcomRuleTable to specify all request parameters of the PER transaction: - midcomRuleInterface - midcomRuleFlowDirection - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleLifetime Note that several of these parameters have default values that can be used. 4. The MIDCOM client sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to enable(1). 5. Identical to step 4 for PRR (section 7.3). 6. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PRR transaction: - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleMaxIdleTime Quittek, et al. Standards Track [Page 34] RFC 5190 MIDCOM MIB March 2008 If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason. 7. Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the allocated middlebox resources for this policy enable rule. 7.6. Policy Rule Lifetime Change (RLC) This example explains steps that may be performed by a MIDCOM client to change the lifetime of a policy rule. Changing the lifetime to 0 implies terminating the policy rule. 1. The MIDCOM client issues a SET request for writing the desired lifetime to the midcomRuleLifetime object in the corresponding row of the midcomRuleTable. This does not have any effect if the lifetime is already expired. 2. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the corresponding row in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations. 3. After receiving the midcomSolicitedRuleEvent notification MIDCOM client checks the lifetime value carried by the notification. 7.7. Policy Rule List (PRL) The SNMP agent can browse the list of policy rules by browsing the midcomRuleTable. For each observed row in this table, the SNMP agent should check the midcomRuleOperStatus in order to find out if the row contains information about an established policy rule or of a rule that is under construction or already terminated. 7.8. Policy Rule Status (PRS) The SNMP agent can retrieve all status information and properties of a policy rule by reading the managed objects in the corresponding row of the midcomRuleTable. Quittek, et al. Standards Track [Page 35] RFC 5190 MIDCOM MIB March 2008 7.9. Asynchronous Policy Rule Event (ARE) There are two different triggers for the ARE. It may be triggered by the expiration of a policy rule's lifetime or the expiration of the idle time. But beyond this, the MIDCOM-MIB implementation may terminate a policy rule at any time. In all cases, two steps are required for performing this transaction: 1. The MIDCOM-MIB implementation sends a midcomUnsolicitedRuleEvent notification containing a lifetime value of 0 to the MIDCOM client owning the rule. 2. If the midcomRuleStorageTime object in the corresponding row of the midcomRuleTable has a value of 0, then the MIDCOM-MIB implementation removes the row from the table. Otherwise, it sets in this row the midcomRuleLifetime object to 0 and changes the midcomRuleOperStatus object. If the event was triggered by policy lifetime expiration, then the midcomRuleOperStatus is set to timedOut(9); otherwise, it is set to terminated(11). 7.10. Group Lifetime Change (GLC) This example explains steps that may be performed by a MIDCOM client to change the lifetime of a policy rule group. Changing the lifetime to 0 implies terminating all member policies of the group. 1. The MIDCOM client issues a SET request for writing the desired lifetime to the midcomGroupLifetime object in the corresponding row of the midcomGroupTable. 2. The MIDCOM client waits for a midcomSolicitedGroupEvent notification concerning the corresponding row in the midcomGroupTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomGroupEntry by one or more SNMP GET operations. 3. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. 7.11. Group List (GL) The SNMP agent can browse the list of policy rule groups by browsing the midcomGroupTable. For each observed row in this table, the SNMP agent should check the midcomGroupLifetime in order to find out if the group does contain established policies. Quittek, et al. Standards Track [Page 36] RFC 5190 MIDCOM MIB March 2008 7.12. Group Status (GS) The SNMP agent can retrieve all member policies of a group by browsing the midcomRuleTable using the midcomGroupIndex of the particular group. For retrieving the remaining lifetime of the group, the SNMP agent reads the midcomGroupLifetime object in the corresponding row of the midcomGroupTable. 8. Usage Examples for Monitoring Objects This section presents some examples that explain how a MIDCOM client can use the midcomResourceTable to correlate policy rules with the used middlebox resources. One example is given for middleboxes implementing the NAT-MIB and another one is given for firewalls. 8.1. Monitoring NAT Resources When a rule in the midcomRuleTable is executed, it directly impacts the middlebox resources. The midcomResourceTable provides the information on the relationships between the MIDCOM-MIB policy rules and the middlebox resources used for enforcing these rules. A MIDCOM-MIB policy rule will cause the creation or modification of up to two NAT bindings and up to two NAT sessions. Two NAT bindings are impacted in the case of a session being subject to twice-NAT. Two NAT bindings may also be impacted when midcomRulePortRange is set to pair(2) in the policy rule. In the majority of cases, where traditional NAT is implemented, only a single NAT binding may be adequate. Note, however, that this BindId is set to 0 if the middlebox is implementing symmetric NAT function. Two NAT sessions are created or modified only when the midcomRulePortRange is set to pair(2) in the policy rule. When support for the NAT-MIB module is also available at the middlebox, the parameters in the combination of the midcomRuleTable and the midcomResourceTable for a given rule can be used to index the corresponding BIND and NAT session resources effected in the NAT-MIB. These parameters are valuable to monitor the impact on the NAT module, even when the NAT-MIB module is not implemented at the middlebox. The impact of MIDCOM rules on the NAT resources is important because a MIDCOM rule not only can create BINDs and NAT sessions, but also is capable of modifying the NAT objects that already exist. For example, FlowDirection and MaxIdleTime parameters in a MIDCOM rule directly affect the TranslationEntity and MaxIdleTime of the associated NAT bind object. Likewise, MaxIdleTime in a MIDCOM rule Quittek, et al. Standards Track [Page 37] RFC 5190 MIDCOM MIB March 2008 has a direct impact on the MaxIdleTime of the associated NAT session object. The lifetime parameter in the MIDCOM rule directly impacts the lifetime of all the impacted NAT BIND and NAT session objects. 8.2. Monitoring Firewall Resources When a MIDCOM-MIB policy rule is established at a middlebox with firewall capabilities, this may lead to the creation of one or more new firewall rules. Note that in general a single firewall rule per MIDCOM-MIB policy rule will be sufficient. For each policy rule, a MIDCOM client can explore the corresponding firewall filter rule by reading the midcomResourceEntry in the midcomResourceTable that corresponds to the midcomRuleEntry describing the rule. The identification of the firewall filter rule is stored in object midcomRscFirewallRuleId. The value of midcomRscFirewallRuleId may correspond directly to any firewall filter rule number or to an entry in a locally available firewall MIB module. 9. Definitions The following MIB module imports from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3411], [RFC4001], and [RFC4008]. MIDCOM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32, Gauge32, mib-2 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION, TruthValue, StorageType, RowStatus FROM SNMPv2-TC -- RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 InetAddressType, InetAddress, InetPortNumber, InetAddressPrefixLength FROM INET-ADDRESS-MIB -- RFC 4001 Quittek, et al. Standards Track [Page 38] RFC 5190 MIDCOM MIB March 2008 InterfaceIndexOrZero FROM IF-MIB -- RFC 2863 NatBindIdOrZero FROM NAT-MIB; -- RFC 4008 midcomMIB MODULE-IDENTITY LAST-UPDATED "200708091011Z" -- August 09, 2007 ORGANIZATION "IETF Middlebox Communication Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/midcom-charter.html Mailing Lists: General Discussion: midcom@ietf.org To Subscribe: midcom-request@ietf.org In Body: subscribe your_email_address Co-editor: Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Tel: +49 6221 4342-115 Email: quittek@nw.neclab.eu Co-editor: Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Tel: +49 6221 4342-113 Email: stiemerling@nw.neclab.eu Co-editor: Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A. Tel: +1 408 836-4773 Email: srisuresh@yahoo.com" DESCRIPTION "This MIB module defines a set of basic objects for configuring middleboxes, such as firewalls and network Quittek, et al. Standards Track [Page 39] RFC 5190 MIDCOM MIB March 2008 address translators, in order to enable communication across these devices. Managed objects defined in this MIB module are structured in three kinds of objects: - transaction objects required according to the MIDCOM protocol requirements defined in RFC 3304 and according to the MIDCOM protocol semantics defined in RFC 3989, - configuration objects that can be used for retrieving or setting parameters of the implementation of transaction objects, - optional monitoring objects that provide information about used resource and statistics The transaction objects are organized in two subtrees: - objects modeling MIDCOM policy rules in the midcomRuleTable - objects modeling MIDCOM policy rule groups in the midcomGroupTable Note that typically, configuration objects are not intended to be written by MIDCOM clients. In general, write access to these objects needs to be restricted more strictly than write access to objects in the transaction subtrees. Copyright (C) The Internet Society (2008). This version of this MIB module is part of RFC 5190; see the RFC itself for full legal notices." REVISION "200708091011Z" -- August 09, 2007 DESCRIPTION "Initial version, published as RFC 5190." ::= { mib-2 171 } -- -- main components of this MIB module -- midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 0 } midcomObjects OBJECT IDENTIFIER ::= { midcomMIB 1 } midcomConformance OBJECT IDENTIFIER ::= { midcomMIB 2 } -- Transaction objects required according to the MIDCOM -- protocol requirements defined in RFC 3304 and according to -- the MIDCOM protocol semantics defined in RFC 3989 midcomTransaction OBJECT IDENTIFIER ::= { midcomObjects 1 } -- Configuration objects that can be used for retrieving -- middlebox capability information (mandatory) and for Quittek, et al. Standards Track [Page 40] RFC 5190 MIDCOM MIB March 2008 -- setting parameters of the implementation of transaction -- objects (optional) midcomConfig OBJECT IDENTIFIER ::= { midcomObjects 2 } -- Optional monitoring objects that provide information about -- used resource and statistics midcomMonitoring OBJECT IDENTIFIER ::= { midcomObjects 3 } -- -- Transaction Objects -- -- Transaction objects are structured according to the MIDCOM -- protocol semantics into two groups: -- - objects modeling MIDCOM policy rules in the midcomRuleTable -- - objects modeling MIDCOM policy rule groups in the -- midcomGroupTable -- -- Policy rule subtree -- -- The midcomRuleTable lists policy rules -- including policy reserve rules and policy enable rules. -- midcomRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists policy rules. It is indexed by the midcomRuleOwner, the midcomGroupIndex, and the midcomRuleIndex. This implies that a rule is a member of exactly one group and that group membership cannot be changed. Entries can be deleted by writing to midcomGroupLifetime or midcomRuleLifetime and potentially also to midcomRuleStorageTime." ::= { midcomTransaction 3 } midcomRuleEntry OBJECT-TYPE SYNTAX MidcomRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular MIDCOM policy rule." Quittek, et al. Standards Track [Page 41] RFC 5190 MIDCOM MIB March 2008 INDEX { midcomRuleOwner, midcomGroupIndex, midcomRuleIndex } ::= { midcomRuleTable 1 } MidcomRuleEntry ::= SEQUENCE { midcomRuleOwner SnmpAdminString, midcomRuleIndex Unsigned32, midcomRuleAdminStatus INTEGER, midcomRuleOperStatus INTEGER, midcomRuleStorageType StorageType, midcomRuleStorageTime Unsigned32, midcomRuleError SnmpAdminString, midcomRuleInterface InterfaceIndexOrZero, midcomRuleFlowDirection INTEGER, midcomRuleMaxIdleTime Unsigned32, midcomRuleTransportProtocol Unsigned32, midcomRulePortRange INTEGER, midcomRuleInternalIpVersion InetAddressType, midcomRuleExternalIpVersion InetAddressType, midcomRuleInternalIpAddr InetAddress, midcomRuleInternalIpPrefixLength InetAddressPrefixLength, midcomRuleInternalPort InetPortNumber, midcomRuleExternalIpAddr InetAddress, midcomRuleExternalIpPrefixLength InetAddressPrefixLength, midcomRuleExternalPort InetPortNumber, midcomRuleInsideIpAddr InetAddress, midcomRuleInsidePort InetPortNumber, midcomRuleOutsideIpAddr InetAddress, midcomRuleOutsidePort InetPortNumber, midcomRuleLifetime Unsigned32, midcomRuleRowStatus RowStatus } midcomRuleOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the midcomRuleTable. This object SHOULD uniquely identify an authenticated MIDCOM client. This object is part of the table index to allow for the use of the SNMPv3 View-based Access Control Model (VACM, RFC 3415)." ::= { midcomRuleEntry 1 } midcomRuleIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible Quittek, et al. Standards Track [Page 42] RFC 5190 MIDCOM MIB March 2008 STATUS current DESCRIPTION "The value of this object must be unique in combination with the values of the objects midcomRuleOwner and midcomGroupIndex in this row." ::= { midcomRuleEntry 3 } midcomRuleAdminStatus OBJECT-TYPE SYNTAX INTEGER { reserve(1), enable(2), notSet(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of the policy rule. See the definition of midcomRuleOperStatus for a description of the values. When a midcomRuleEntry is created without explicitly setting this object, its value will be notSet(3). However, a SET request can only set this object to either reserve(1) or enable(2). Attempts to set this object to notSet(3) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. When the midcomRuleAdminStatus object is set, then the MIDCOM-MIB implementation will try to read the respective relevant objects of the entry and try to achieve the corresponding midcomRuleOperStatus. Setting midcomRuleAdminStatus to value reserve(1) when object midcomRuleOperStatus has a value of reserved(7) does not have any effect on the policy rule. Setting midcomRuleAdminStatus to value enable(2) when object midcomRuleOperStatus has a value of enabled(8) does not have any effect on the policy rule. Depending on whether the midcomRuleAdminStatus is set to reserve(1) or enable(2), several objects must be set in advance. They serve as parameters of the policy rule to be established. Quittek, et al. Standards Track [Page 43] RFC 5190 MIDCOM MIB March 2008 When object midcomRuleAdminStatus is set to reserve(1), then the following objects in the same entry are of relevance: - midcomRuleInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleLifetime MIDCOM-MIB implementation may also consider the value of object midcomRuleMaxIdleTime when establishing a reserve rule. When object midcomRuleAdminStatus is set to enable(2), then the following objects in the same entry are of relevance: - midcomRuleInterface - midcomRuleFlowDirection - midcomRuleMaxIdleTime - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleLifetime When retrieved, the object returns the last set value. If no value has been set, it returns the default value notSet(3)." DEFVAL { notSet } ::= { midcomRuleEntry 4 } midcomRuleOperStatus OBJECT-TYPE SYNTAX INTEGER { newEntry(1), setting(2), checkingRequest(3), incorrectRequest(4), processingRequest(5), Quittek, et al. Standards Track [Page 44] RFC 5190 MIDCOM MIB March 2008 requestRejected(6), reserved(7), enabled(8), timedOut(9), terminatedOnRequest(10), terminated(11), genericError(12) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual status of the policy rule. The midcomRuleOperStatus object may have the following values: - newEntry(1) indicates that the entry in the midcomRuleTable was created, but not modified yet. Such an entry needs to be filled with values specifying a request first. - setting(2) indicates that the entry has been already modified after generating it, but no request was made yet. - checkingRequest(3) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM-MIB implementation is currently checking the parameters of the request. This is a transient state. The value of this object will change to either incorrectRequest(4) or processingRequest(5) without any external interaction. A MIDCOM-MIB implementation MAY return this value while checking request parameters. - incorrectRequest(4) indicates that checking a request resulted in detecting an incorrect value in one of the objects containing request parameters. The failure reason is indicated by the value of midcomRuleError. - processingRequest(5) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM-MIB implementation is currently processing the request and trying to configure the middlebox accordingly. This is a transient state. The value of this object will change to either requestRejected(6), reserved(7), or enabled(8) without any external interaction. A MIDCOM-MIB implementation MAY return this value while processing a request. - requestRejected(6) indicates that a request to establish Quittek, et al. Standards Track [Page 45] RFC 5190 MIDCOM MIB March 2008 a policy rule specified by the entry was rejected. The reason for rejection is indicated by the value of midcomRuleError. - reserved(7) indicates that the entry describes an established policy reserve rule. These values of MidcomRuleEntry are meaningful for a reserved policy rule: - midcomRuleMaxIdleTime - midcomRuleInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime - enabled(8) indicates that the entry describes an established policy enable rule. These values of MidcomRuleEntry are meaningful for an enabled policy rule: - midcomRuleFlowDirection - midcomRuleInterface - midcomRuleMaxIdleTime - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime - timedOut(9) indicates that the lifetime of a previously established policy rule has expired and that the policy rule is terminated for this reason. Quittek, et al. Standards Track [Page 46] RFC 5190 MIDCOM MIB March 2008 - terminatedOnRequest(10) indicates that a previously established policy rule was terminated by an SNMP manager setting the midcomRuleLifetime to 0 or setting midcomGroupLifetime to 0. - terminated(11) indicates that a previously established policy rule was terminated by the MIDCOM-MIB implementation for a reason other than lifetime expiration or an explicit request from a MIDCOM client. - genericError(12) indicates that the policy rule specified by the entry is not established due to an error condition not listed above. The states timedOut(9), terminatedOnRequest(10), and terminated(11) are referred to as termination states. The states incorrectRequest(4), requestRejected(6), and genericError(12) are referred to as error states. The checkingRequest(3) and processingRequest(5) states are transient states, which will lead to either one of the error states or the reserved(7) state or the enabled(8) state. MIDCOM-MIB implementations MAY return these values when checking or processing requests." DEFVAL { newEntry } ::= { midcomRuleEntry 5 } midcomRuleStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "When retrieved, this object returns the storage type of the policy rule. Writing to this object can change the storage type of the particular row from volatile(2) to nonVolatile(3) or vice versa. Attempts to set this object to permanent will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If midcomRuleStorageType has the value permanent(4), then all objects in this row whose MAX-ACCESS value is read-create must be read-only." Quittek, et al. Standards Track [Page 47] RFC 5190 MIDCOM MIB March 2008 DEFVAL { volatile } ::= { midcomRuleEntry 6 } midcomRuleStorageTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object specifies how long this row can exist in the midcomRuleTable after the midcomRuleOperStatus switched to a termination state or to an error state. This object returns the remaining time that the row may exist before it is aged out. After expiration or termination of the context, the value of this object ticks backwards. The entry in the midcomRuleTable is destroyed when the value reaches 0. The value of this object may be set in order to increase or reduce the remaining time that the row may exist. Setting the value to 0 will destroy this entry as soon as the midcomRuleOperStatus switched to a termination state or to an error state. Note that there is no guarantee that the row is stored as long as this object indicates. At any time, the MIDCOM- MIB implementation may decide to remove a row describing a terminated policy rule before the storage time of the corresponding row in the midcomRuleTable reaches the value of 0. In this case, the information stored in this row is not available anymore. If object midcomRuleStorageType indicates that the policy rule has the storage type permanent(4), then this object has a constant value of 4294967295." DEFVAL { 0 } ::= { midcomRuleEntry 7 } midcomRuleError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if the transition into the operational status reserved(7) or enabled(8) failed. Implementations must reset the error message to a zero-length string when a new Quittek, et al. Standards Track [Page 48] RFC 5190 MIDCOM MIB March 2008 attempt to change the policy rule status to reserved(7) or enabled(8) is started. RECOMMENDED values to be returned in particular cases include - 'lack of IP addresses' - 'lack of port numbers' - 'lack of resources' - 'specified NAT interface does not exist' - 'specified NAT interface does not support NAT' - 'conflict with already existing policy rule' - 'no internal IP wildcarding allowed' - 'no external IP wildcarding allowed' The semantics of these error messages and the corresponding behavior of the MIDCOM-MIB implementation are specified in sections 2.3.9 and 2.3.10 of RFC 3989." REFERENCE "RFC 3989, sections 2.3.9 and 2.3.10" DEFVAL { ''H } ::= { midcomRuleEntry 8 } midcomRuleInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the IP interface for which enforcement of a policy rule is requested or performed, respectively. The interface is identified by its index in the ifTable (see IF-MIB in RFC 2863). If the object has a value of 0, then no particular interface is indicated. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to request its preference concerning the interface at which it requests NAT service. The default value of 0 indicates that the manager does not have a preferred interface or does not have sufficient topology information for specifying one. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. Quittek, et al. Standards Track [Page 49] RFC 5190 MIDCOM MIB March 2008 Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the interface at which NAT service for this rule is performed. If NAT service is not required for enforcing the policy rule, then the value of this object is 0. Also, if the MIDCOM-MIB implementation cannot indicate an interface, because it does not have this information or because NAT service is not offered at a particular single interface, then the value of the object is 0. Note that the index of a particular interface in the ifTable may change after a re-initialization of the middlebox, for example, after adding another interface to it. In such a case, the value of this object may change, but the interface referred to by the MIDCOM-MIB MUST still be the same. If, after a re-initialization of the middlebox, the interface referred to before re-initialization cannot be uniquely mapped anymore to a particular entry in the ifTable, then the value of object midcomRuleOperStatus of the same entry MUST be changed to terminated(11). If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 9 } midcomRuleFlowDirection OBJECT-TYPE SYNTAX INTEGER { inbound(1), outbound(2), biDirectional(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter specifies the direction of enabled communication, either inbound(1), outbound(2), or biDirectional(3). The semantics of this object depends on the protocol the rule relates to. If the rule is independent of Quittek, et al. Standards Track [Page 50] RFC 5190 MIDCOM MIB March 2008 the transport protocol (midcomRuleTransportProtocol has a value of 0) or if the transport protocol is UDP, then the value of midcomRuleFlowDirection indicates the direction of packets traversing the middlebox. In this case, value inbound(1) indicates that packets are traversing from outside to inside, value outbound(2) indicates that packets are traversing from inside to outside. For both values, inbound(1) and outbound(2) packets can traverse the middlebox only unidirectional. A bidirectional flow is indicated by value biDirectional(3). If the transport protocol is TCP, the packet flow is always bidirectional, but the value of midcomRuleFlowDirection indicates that: - inbound(1): bidirectional TCP packet flow. First packet, with TCP SYN flag set, must arrive at an outside interface of the middlebox. - outbound(2): bidirectional TCP packet flow. First packet, with TCP SYN flag set, must arrive at an inside interface of the middlebox. - biDirectional(3): bidirectional TCP packet flow. First packet, with TCP SYN flag set, may arrive at an inside or an outside interface of the middlebox. This object is used as input to a request for establishing a policy enable rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has a value of either newEntry(1), setting(2), or reserved(7), then this object can be written by a manager in order to specify a requested direction to be enabled by a policy rule. Writing to this object in any state other than newEntry(1), setting(2), or reserved(7) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object indicates the enabled Quittek, et al. Standards Track [Page 51] RFC 5190 MIDCOM MIB March 2008 flow direction. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { outbound } ::= { midcomRuleEntry 10 } midcomRuleMaxIdleTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum idle time of the policy rule in seconds. If no packet to which the policy rule applies passes the middlebox for the specified midcomRuleMaxIdleTime, then the policy rule enters the termination state timedOut(9). A value of 0 indicates that the policy does not require an individual idle time and that instead, a default idle time chosen by the middlebox is used. A value of 4294967295 ( = 2^32 - 1 ) indicates that the policy does not time out if it is idle. This object is used as input to a request for establishing a policy enable rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has a value of either newEntry(1), setting(2), or reserved(7), then this object can be written by a manager in order to specify a maximum idle time for the policy rule to be requested. Writing to this object in any state others than newEntry(1), setting(2), or reserved(7) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object indicates the maximum idle time of the policy rule. Note that even if a maximum idle time greater than zero was requested, the middlebox Quittek, et al. Standards Track [Page 52] RFC 5190 MIDCOM MIB March 2008 may not be able to support maximum idle times and set the value of this object to zero when entering state enabled(8). If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 11 } midcomRuleTransportProtocol OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The transport protocol. Valid values for midcomRuleTransportProtocol other than zero are defined at: http://www.iana.org/assignments/protocol-numbers This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has a value of either newEntry(1) or setting(2), then this object can be written by a manager in order to specify a requested transport protocol. If translation of an IP address only is requested, then this object must have the default value 0. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates which transport protocol is enforced by this policy rule. A value of 0 indicates a rule acting on IP addresses only. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." Quittek, et al. Standards Track [Page 53] RFC 5190 MIDCOM MIB March 2008 DEFVAL { 0 } ::= { midcomRuleEntry 12 } midcomRulePortRange OBJECT-TYPE SYNTAX INTEGER { single(1), pair(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The range of port numbers. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. It is relevant to the operation of the MIDCOM-MIB implementation only if the value of object midcomTransportProtocol in the same entry has a value other than 0. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the requested size of the port range. With single(1) just a single port number is requested, with pair(2) a consecutive pair of port numbers is requested with the lower number being even. Requesting a consecutive pair of port numbers may be used by RTP [RFC3550] and may even be required to support older RTP applications. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8), then this object will have the value that it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { single } Quittek, et al. Standards Track [Page 54] RFC 5190 MIDCOM MIB March 2008 ::= { midcomRuleEntry 13} midcomRuleInternalIpVersion OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "IP version of the internal address (A0) and the inside address (A1). Allowed values are ipv4(1), ipv6(2), ipv4z(3), and ipv6z(4). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the IP version required at the inside of the middlebox. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the internal/inside IP version. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { ipv4 } ::= { midcomRuleEntry 14 } midcomRuleExternalIpVersion OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "IP version of the external address (A3) and the outside address (A2). Allowed values are ipv4(1) and ipv6(2). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. Quittek, et al. Standards Track [Page 55] RFC 5190 MIDCOM MIB March 2008 If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the IP version required at the outside of the middlebox. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the external/outside IP version. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { ipv4 } ::= { midcomRuleEntry 15 } midcomRuleInternalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The internal IP address (A0). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the internal IP address for which a reserve policy rule or a enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object will have the value which it had before the transition to this Quittek, et al. Standards Track [Page 56] RFC 5190 MIDCOM MIB March 2008 state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." ::= { midcomRuleEntry 16 } midcomRuleInternalIpPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "The prefix length of the internal IP address used for wildcarding. A value of 0 indicates a full wildcard; in this case, the value of midcomRuleInternalIpAddr is irrelevant. If midcomRuleInternalIpVersion has a value of ipv4(1), then a value > 31 indicates no wildcarding at all. If midcomRuleInternalIpVersion has a value of ipv4(2), then a value > 127 indicates no wildcarding at all. A MIDCOM-MIB implementation that does not support IP address wildcarding MUST implement this object as read-only with a value of 128. A MIDCOM that does not support wildcarding based on prefix length MAY restrict allowed values for this object to 0 and 128. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the prefix length of the internal IP address for which a reserve policy rule or an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object will have the value which it had before the transition to this state. Quittek, et al. Standards Track [Page 57] RFC 5190 MIDCOM MIB March 2008 If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { 128 } ::= { midcomRuleEntry 17 } midcomRuleInternalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The internal port number. A value of 0 is a wildcard. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. It is relevant to the operation of the MIDCOM-MIB implementation only if the value of object midcomTransportProtocol in the same entry has a value other than 0. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the internal port number for which a reserve policy rule or an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object will have the value that it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 18 } midcomRuleExternalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current Quittek, et al. Standards Track [Page 58] RFC 5190 MIDCOM MIB March 2008 DESCRIPTION "The external IP address (A3). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1), setting(2), or reserved(7), then this object can be written by a manager in order to specify the external IP address for which an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1), setting(2), or reserved(7) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object will have the value that it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." ::= { midcomRuleEntry 19 } midcomRuleExternalIpPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "The prefix length of the external IP address used for wildcarding. A value of 0 indicates a full wildcard; in this case, the value of midcomRuleExternalIpAddr is irrelevant. If midcomRuleExternalIpVersion has a value of ipv4(1), then a value > 31 indicates no wildcarding at all. If midcomRuleExternalIpVersion has a value of ipv4(2), then a value > 127 indicates no wildcarding at all. A MIDCOM-MIB implementation that does not support IP address wildcarding MUST implement this object as read-only with a value of 128. A MIDCOM that does not support wildcarding based on prefix length MAY restrict allowed values for this object to 0 and 128. This object is used as input to a request for establishing Quittek, et al. Standards Track [Page 59] RFC 5190 MIDCOM MIB March 2008 a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1), setting(2), or reserved(7), then this object can be written by a manager in order to specify the prefix length of the external IP address for which an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1), setting(2), or reserved(7) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object will have the value that it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { 128 } ::= { midcomRuleEntry 20 } midcomRuleExternalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The external port number. A value of 0 is a wildcard. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. It is relevant to the operation of the MIDCOM-MIB implementation only if the value of object midcomTransportProtocol in the same entry has a value other than 0. If object midcomRuleOperStatus of the same entry has the value newEntry(1), setting(2) or reserved(7), then this object can be written by a manager in order to specify the external port number for which an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an 'inconsistentValue' error. Quittek, et al. Standards Track [Page 60] RFC 5190 MIDCOM MIB March 2008 Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object will have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 21 } midcomRuleInsideIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The inside IP address at the middlebox (A1). The value of this object is relevant only if object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 22 } midcomRuleInsidePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The inside port number at the middlebox. A value of 0 is a wildcard. The value of this object is relevant only if object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 23 } midcomRuleOutsideIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The outside IP address at the middlebox (A2). The value of this object is relevant only if Quittek, et al. Standards Track [Page 61] RFC 5190 MIDCOM MIB March 2008 object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 24 } midcomRuleOutsidePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The outside port number at the middlebox. A value of 0 is a wildcard. The value of this object is relevant only if object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 25 } midcomRuleLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The remaining lifetime in seconds of this policy rule. Lifetime of a policy rule starts when object midcomRuleOperStatus in the same entry enters either state reserved(7) or state enabled(8). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has a value of either newEntry(1) or setting(2), then this object can be written by a manager in order to specify the requested lifetime of a policy rule to be established. If object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8), then this object indicates the (continuously decreasing) remaining lifetime of the established policy rule. Note that when entering state reserved(7) or enabled(8), the MIDCOM-MIB implementation can choose a lifetime shorter than the one requested. Unlike other parameters of the policy rule, this parameter can still be written in state reserved(7) and enabled(8). Quittek, et al. Standards Track [Page 62] RFC 5190 MIDCOM MIB March 2008 Writing to this object is processed by the MIDCOM-MIB implementation by choosing a lifetime value that is greater than 0 and less than or equal to the minimum of the requested value and the value specified by object midcomConfigMaxLifetime: 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) where: - lt_granted is the actually granted lifetime by the MIDCOM-MIB implementation - lt_requested is the requested lifetime of the MIDCOM client - lt_maximum is the value of object midcomConfigMaxLifetime SNMP SET requests to this object may be rejected or the value of the object after an accepted SET operation may be less than the value that was contained in the SNMP SET request. Successfully writing a value of 0 terminates the policy rule. Note that after a policy rule is terminated, still the entry will exist as long as indicated by the value of midcomRuleStorageTime. Writing to this object in any state other than newEntry(1), setting(2), reserved(7), or enabled(7) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7), or enabled(8), then the value of this object is irrelevant." DEFVAL { 180 } ::= { midcomRuleEntry 26 } midcomRuleRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. Quittek, et al. Standards Track [Page 63] RFC 5190 MIDCOM MIB March 2008 Entries can also be removed from this table by setting objects midcomRuleLifetime and midcomRuleStorageTime of an entry to 0. Attempts to set a row notInService(2) where the value of the midcomRuleStorageType object is permanent(4) or readOnly(5) will result in an 'notWritable' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { midcomRuleEntry 27 } -- -- Policy rule group subtree -- -- The midcomGroupTable lists all current policy rule groups. -- midcomGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all current policy rule groups. Entries in this table are created or removed implicitly when entries in the midcomRuleTable are created or removed, respectively. A group entry in this table only exists as long as there are member rules of this group in the midcomRuleTable. The table serves for listing the existing groups and their remaining lifetimes and for changing lifetimes of groups and implicitly of all group members. Groups and all their member policy rules can only be deleted by deleting all member policies in the midcomRuleTable. Setting midcomGroupLifetime will result in setting the lifetime of all policy members to the same value." ::= { midcomTransaction 4 } midcomGroupEntry OBJECT-TYPE Quittek, et al. Standards Track [Page 64] RFC 5190 MIDCOM MIB March 2008 SYNTAX MidcomGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing properties of a particular MIDCOM policy rule group." INDEX { midcomRuleOwner, midcomGroupIndex } ::= { midcomGroupTable 1 } MidcomGroupEntry ::= SEQUENCE { midcomGroupIndex Unsigned32, midcomGroupLifetime Unsigned32 } midcomGroupIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this group for the midcomRuleOwner. A group is identified by the combination of midcomRuleOwner and midcomGroupIndex. The value of this index must be unique per midcomRuleOwner." ::= { midcomGroupEntry 2 } midcomGroupLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "When retrieved, this object delivers the maximum lifetime in seconds of all member rules of this group, i.e., of all rows in the midcomRuleTable that have the same values for midcomRuleOwner and midcomGroupIndex. Successfully writing to this object modifies the lifetime of all member policies. Successfully writing a value of 0 terminates all member policies and implicitly deletes the group as soon as all member entries are removed from the midcomRuleTable. Note that after a group's lifetime is expired or is set to 0, still the corresponding entry in the midcomGroupTable will exist as long as terminated member policy rules are stored as entries in the Quittek, et al. Standards Track [Page 65] RFC 5190 MIDCOM MIB March 2008 midcomRuleTable. Writing to this object is processed by the MIDCOM-MIB implementation by choosing a lifetime value that is greater than 0 and less than or equal to the minimum of the requested value and the value specified by object midcomConfigMaxLifetime: 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) where: - lt_granted is the actually granted lifetime by the MIDCOM-MIB implementation - lt_requested is the requested lifetime of the MIDCOM client - lt_maximum is the value of object midcomConfigMaxLifetime SNMP SET requests to this object may be rejected or the value of the object after an accepted SET operation may be less than the value that was contained in the SNMP SET request." ::= { midcomGroupEntry 3 } -- -- Configuration Objects -- -- Configuration objects that can be used for retrieving -- middlebox capability information (mandatory) and for -- setting parameters of the implementation of transaction -- objects (optional). -- -- Note that typically configuration objects are not intended -- to be written by MIDCOM clients. In general, write access -- to these objects needs to be restricted more strictly than -- write access to transaction objects. -- -- -- Capabilities subtree -- -- This subtree contains objects to which MIDCOM clients should -- have read access. -- midcomConfigMaxLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" Quittek, et al. Standards Track [Page 66] RFC 5190 MIDCOM MIB March 2008 MAX-ACCESS read-write STATUS current DESCRIPTION "When retrieved, this object returns the maximum lifetime, in seconds, that this middlebox allows policy rules to have." ::= { midcomConfig 1 } midcomConfigPersistentRules OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When retrieved, this object returns true(1) if the MIDCOM-MIB implementation can store policy rules persistently. Otherwise, it returns false(2). A value of true(1) indicates that there may be entries in the midcomRuleTable with object midcomRuleStorageType set to value nonVolatile(3)." ::= { midcomConfig 2 } midcomConfigIfTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomConfigIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table indicates capabilities of the MIDCOM-MIB implementation per IP interface. The table is indexed by the object midcomConfigIfIndex. For indexing a single interface, this object contains the value of the ifIndex object that is associated with the interface. If an entry with midcomConfigIfIndex = 0 occurs, then bits set in objects of this entry apply to all interfaces for which there is no entry in this table with the interface's index." ::= { midcomConfig 3 } midcomConfigIfEntry OBJECT-TYPE SYNTAX MidcomConfigIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing the capabilities of a middlebox with respect to the indexed IP interface." Quittek, et al. Standards Track [Page 67] RFC 5190 MIDCOM MIB March 2008 INDEX { midcomConfigIfIndex } ::= { midcomConfigIfTable 1 } MidcomConfigIfEntry ::= SEQUENCE { midcomConfigIfIndex InterfaceIndexOrZero, midcomConfigIfBits BITS, midcomConfigIfEnabled TruthValue } midcomConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of an entry in the midcomConfigIfTable. For values different from zero, this object identifies an IP interface by containing the same value as the ifIndex object associated with the interface. Note that the index of a particular interface in the ifTable may change after a re-initialization of the middlebox, for example, after adding another interface to it. In such a case, the value of this object may change, but the interface referred to by the MIDCOM-MIB MUST still be the same. If, after a re-initialization of the middlebox, the interface referred to before re-initialization cannot be uniquely mapped anymore to a particular entry in the ifTable, then the value of object midcomConfigIfEnabled of the same entry MUST be changed to false(2). If the object has a value of 0, then values specified by further objects of the same entry apply to all interfaces for which there is no explicit entry in the midcomConfigIfTable." ::= { midcomConfigIfEntry 1 } midcomConfigIfBits OBJECT-TYPE SYNTAX BITS { ipv4(0), ipv6(1), addressWildcards(2), portWildcards(3), firewall(4), nat(5), portTranslation(6), Quittek, et al. Standards Track [Page 68] RFC 5190 MIDCOM MIB March 2008 protocolTranslation(7), twiceNat(8), inside(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "When retrieved, this object returns a set of bits indicating the capabilities (or configuration) of the middlebox with respect to the referenced IP interface. If the index equals 0, then all set bits apply to all interfaces. If the ipv4(0) bit is set, then the middlebox supports IPv4 at the indexed IP interface. If the ipv6(1) bit is set, then the middlebox supports IPv6 at the indexed IP interface. If the addressWildcards(2) bit is set, then the middlebox supports IP address wildcarding at the indexed IP interface. If the portWildcards(3) bit is set, then the middlebox supports port wildcarding at the indexed IP interface. If the firewall(4) bit is set, then the middlebox offers firewall functionality at the indexed interface. If the nat(5) bit is set, then the middlebox offers network address translation service at the indexed interface. If the portTranslation(6) bit is set, then the middlebox offers port translation service at the indexed interface. This bit is only relevant if nat(5) is set. If the protocolTranslation(7) bit is set, then the middlebox offers protocol translation service between IPv4 and IPv6 at the indexed interface. This bit is only relevant if nat(5) is set. If the twiceNat(8) bit is set, then the middlebox offers twice network address translation service at the indexed interface. This bit is only relevant if nat(5) is set. If the inside(9) bit is set, then the indexed interface is Quittek, et al. Standards Track [Page 69] RFC 5190 MIDCOM MIB March 2008 an inside interface with respect to NAT functionality. Otherwise, it is an outside interface. This bit is only relevant if nat(5) is set. An SNMP agent supporting both the MIDCOM-MIB module and the NAT-MIB module SHOULD ensure that the value of this object is consistent with the values of corresponding objects in the NAT-MIB module." ::= { midcomConfigIfEntry 2 } midcomConfigIfEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object indicates the availability of the middlebox service described by midcomConfigIfBits at the indexed IP interface. By writing to this object, the MIDCOM support for the entire IP interface can be switched on or off. Setting this object to false(2) immediately stops middlebox support at the indexed IP interface. This implies that all policy rules that use NAT or firewall resources at the indexed IP interface are terminated immediately. In this case, the MIDCOM agent MUST send midcomUnsolicitedRuleEvent to all MIDCOM clients that have access to one of the terminated rules." DEFVAL { true } ::= { midcomConfigIfEntry 3 } -- -- Firewall subtree -- -- This subtree contains the firewall configuration table -- midcomConfigFirewallTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomConfigFirewallEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the firewall configuration per IP interface. It can be used for configuring how policy rules created by MIDCOM clients are realized as firewall rules of a firewall implementation. Particularly, the priority used for MIDCOM policy rules can be configured. For a single firewall implementation at a particular IP interface, all MIDCOM policy rules are realized as firewall rules with the same Quittek, et al. Standards Track [Page 70] RFC 5190 MIDCOM MIB March 2008 priority. Also, a firewall rule group name can be configured. The table is indexed by the object midcomConfigFirewallIndex. For indexing a single interface, this object contains the value of the ifIndex object that is associated with the interface. If an entry with midcomConfigFirewallIndex = 0 occurs, then bits set in objects of this entry apply to all interfaces for which there is no entry in this table for the interface's index." ::= { midcomConfig 4 } midcomConfigFirewallEntry OBJECT-TYPE SYNTAX MidcomConfigFirewallEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular set of firewall resources." INDEX { midcomConfigFirewallIndex } ::= { midcomConfigFirewallTable 1 } MidcomConfigFirewallEntry ::= SEQUENCE { midcomConfigFirewallIndex InterfaceIndexOrZero, midcomConfigFirewallGroupId SnmpAdminString, midcomConfigFirewallPriority Unsigned32 } midcomConfigFirewallIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of an entry in the midcomConfigFirewallTable. For values different from 0, this object identifies an IP interface by containing the same value as the ifIndex object associated with the interface. Note that the index of a particular interface in the ifTable may change after a re-initialization of the middlebox, for example, after adding another interface to it. In such a case, the value of this object may change, but the interface referred to by the MIDCOM-MIB MUST still be the same. If, after a re-initialization of the middlebox, the interface referred to before re-initialization cannot be uniquely mapped anymore to a particular entry in the ifTable, then the entry in the Quittek, et al. Standards Track [Page 71] RFC 5190 MIDCOM MIB March 2008 midcomConfigFirewallTable MUST be deleted. If the object has a value of 0, then values specified by further objects of the same entry apply to all interfaces for which there is no explicit entry in the midcomConfigFirewallTable." ::= { midcomConfigFirewallEntry 1 } midcomConfigFirewallGroupId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "The firewall rule group to which all firewall rules are assigned that the MIDCOM server creates for the interface indicated by object midcomConfigFirewallIndex. If the value of object midcomConfigFirewallIndex is 0, then all firewall rules of the MIDCOM server that are created for interfaces with no specific entry in the midcomConfigFirewallTable are assigned to the firewall rule group indicated by the value of this object." ::= { midcomConfigFirewallEntry 2 } midcomConfigFirewallPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The priority assigned to all firewall rules that the MIDCOM server creates for the interface indicated by object midcomConfigFirewallIndex. If the value of object midcomConfigFirewallIndex is 0, then this priority is assigned to all firewall rules of the MIDCOM server that are created for interfaces for which there is no specific entry in the midcomConfigFirewallTable." ::= { midcomConfigFirewallEntry 3 } -- -- Monitoring Objects -- -- Monitoring objects are structured into two groups, -- the midcomResourceGroup providing information about used -- resources and the midcomStatisticsGroup providing information -- about MIDCOM transaction statistics. -- -- Resources subtree -- Quittek, et al. Standards Track [Page 72] RFC 5190 MIDCOM MIB March 2008 -- The MIDCOM resources subtree contains a set of managed -- objects describing the currently used resources of NAT -- and firewall implementations. -- -- -- Textual conventions for objects of the resource subtree -- MidcomNatBindMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An indicator of the kind of NAT resources used by a policy rule. This definition corresponds to the definition of NatBindMode in the NAT-MIB (RFC 4008). Value none(3) can be used to indicate that the policy rule does not use any NAT binding. " SYNTAX INTEGER { addressBind(1), addressPortBind(2), none(3) } MidcomNatSessionIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique ID that is assigned to each NAT session by a NAT implementation. This definition corresponds to the definition of NatSessionId in the NAT-MIB (RFC 4008). Value 0 can be used to indicate that the policy rule does not use any NAT binding." SYNTAX Unsigned32 -- -- The MIDCOM resource table -- midcomResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all used middlebox resources per MIDCOM policy rule. The midcomResourceTable augments the Quittek, et al. Standards Track [Page 73] RFC 5190 MIDCOM MIB March 2008 midcomRuleTable." ::= { midcomMonitoring 1 } midcomResourceEntry OBJECT-TYPE SYNTAX MidcomResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular set of middlebox resources." AUGMENTS { midcomRuleEntry } ::= { midcomResourceTable 1 } MidcomResourceEntry ::= SEQUENCE { midcomRscNatInternalAddrBindMode MidcomNatBindMode, midcomRscNatInternalAddrBindId NatBindIdOrZero, midcomRscNatInsideAddrBindMode MidcomNatBindMode, midcomRscNatInsideAddrBindId NatBindIdOrZero, midcomRscNatSessionId1 MidcomNatSessionIdOrZero, midcomRscNatSessionId2 MidcomNatSessionIdOrZero, midcomRscFirewallRuleId Unsigned32 } midcomRscNatInternalAddrBindMode OBJECT-TYPE SYNTAX MidcomNatBindMode MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this policy rule uses an address NAT bind or an address-port NAT bind for binding the internal address. If the MIDCOM-MIB module is operated together with the NAT-MIB module (RFC 4008) then object midcomRscNatInternalAddrBindMode contains the same value as the corresponding object natSessionPrivateSrcEPBindMode of the NAT-MIB module." ::= { midcomResourceEntry 4 } midcomRscNatInternalAddrBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object references to the allocated internal NAT bind that is used by this policy rule. A NAT bind describes the mapping of internal addresses to outside addresses. MIDCOM-MIB implementations can Quittek, et al. Standards Track [Page 74] RFC 5190 MIDCOM MIB March 2008 read this object to learn the corresponding NAT bind resource for this particular policy rule. If the MIDCOM-MIB module is operated together with the NAT-MIB module (RFC 4008) then object midcomRscNatInternalAddrBindId contains the same value as the corresponding object natSessionPrivateSrcEPBindId of the NAT-MIB module." ::= { midcomResourceEntry 5 } midcomRscNatInsideAddrBindMode OBJECT-TYPE SYNTAX MidcomNatBindMode MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether this policy rule uses an address NAT bind or an address-port NAT bind for binding the external address. If the MIDCOM-MIB module is operated together with the NAT-MIB module (RFC 4008), then object midcomRscNatInsideAddrBindMode contains the same value as the corresponding object natSessionPrivateDstEPBindMode of the NAT-MIB module." ::= { midcomResourceEntry 6 } midcomRscNatInsideAddrBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object refers to the allocated external NAT bind that is used by this policy rule. A NAT bind describes the mapping of external addresses to inside addresses. MIDCOM-MIB implementations can read this object to learn the corresponding NAT bind resource for this particular policy rule. If the MIDCOM-MIB module is operated together with the NAT-MIB module (RFC 4008), then object midcomRscNatInsideAddrBindId contains the same value as the corresponding object natSessionPrivateDstEPBindId of the NAT-MIB module." ::= { midcomResourceEntry 7 } midcomRscNatSessionId1 OBJECT-TYPE SYNTAX MidcomNatSessionIdOrZero MAX-ACCESS read-only Quittek, et al. Standards Track [Page 75] RFC 5190 MIDCOM MIB March 2008 STATUS current DESCRIPTION "This object refers to the first allocated NAT session for this policy rule. MIDCOM-MIB implementations can read this object to learn whether or not a NAT session for a particular policy rule is used. A value of 0 means that no NAT session is allocated for this policy rule. A value other than 0 refers to the NAT session." ::= { midcomResourceEntry 8 } midcomRscNatSessionId2 OBJECT-TYPE SYNTAX MidcomNatSessionIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object refers to the second allocated NAT session for this policy rule. MIDCOM-MIB implementations can read this object to learn whether or not a NAT session for a particular policy rule is used. A value of 0 means that no NAT session is allocated for this policy rule. A value other than 0 refers to the NAT session." ::= { midcomResourceEntry 9 } midcomRscFirewallRuleId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object refers to the allocated firewall rule in the firewall engine for this policy rule. MIDCOM-MIB implementations can read this value to learn whether a firewall rule for this particular policy rule is used or not. A value of 0 means that no firewall rule is allocated for this policy rule. A value other than 0 refers to the firewall rule number within the firewall engine." ::= { midcomResourceEntry 10 } -- -- Statistics subtree -- -- The MIDCOM statistics subtree contains a set of managed -- objects providing statistics about the usage of transaction -- objects. -- midcomStatistics OBJECT IDENTIFIER ::= { midcomMonitoring 2 } Quittek, et al. Standards Track [Page 76] RFC 5190 MIDCOM MIB March 2008 midcomCurrentOwners OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of different values for midcomRuleOwner for all current entries in the midcomRuleTable." ::= { midcomStatistics 1 } midcomTotalRejectedRuleEntries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of failed attempts to create an entry in the midcomRuleTable." ::= { midcomStatistics 2 } midcomCurrentRulesIncomplete OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of policy rules that are incomplete. Policy rules are loaded via row entries in the midcomRuleTable. This object counts policy rules that are loaded but not fully specified, i.e., they are in state newEntry(1) or setting(2)." ::= { midcomStatistics 3 } midcomTotalIncorrectReserveRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy reserve rules that failed parameter check and entered state incorrectRequest(4)." ::= { midcomStatistics 4 } midcomTotalRejectedReserveRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy reserve rules that failed while being processed and entered state requestRejected(6)." ::= { midcomStatistics 5 } Quittek, et al. Standards Track [Page 77] RFC 5190 MIDCOM MIB March 2008 midcomCurrentActiveReserveRules OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active policy reserve rules." ::= { midcomStatistics 6 } midcomTotalExpiredReserveRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of expired policy reserve rules (entered termination state timedOut(9))." ::= { midcomStatistics 7 } midcomTotalTerminatedOnRqReserveRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy reserve rules that were terminated on request (entered termination state terminatedOnRequest(10))." ::= { midcomStatistics 8 } midcomTotalTerminatedReserveRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy reserve rules that were terminated, but not on request (entered termination state terminated(11))." ::= { midcomStatistics 9 } midcomTotalIncorrectEnableRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that failed parameter check and entered state incorrectRequest(4)." ::= { midcomStatistics 10 } midcomTotalRejectedEnableRules OBJECT-TYPE SYNTAX Counter32 Quittek, et al. Standards Track [Page 78] RFC 5190 MIDCOM MIB March 2008 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that failed while being processed and entered state requestRejected(6)." ::= { midcomStatistics 11 } midcomCurrentActiveEnableRules OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active policy enable rules." ::= { midcomStatistics 12 } midcomTotalExpiredEnableRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of expired policy enable rules (entered termination state timedOut(9))." ::= { midcomStatistics 13 } midcomTotalTerminatedOnRqEnableRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that were terminated on request (entered termination state terminatedOnRequest(10))." ::= { midcomStatistics 14 } midcomTotalTerminatedEnableRules OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that were terminated, but not on request (entered termination state terminated(11))." ::= { midcomStatistics 15 } -- -- Notifications. -- midcomUnsolicitedRuleEvent NOTIFICATION-TYPE Quittek, et al. Standards Track [Page 79] RFC 5190 MIDCOM MIB March 2008 OBJECTS { midcomRuleOperStatus, midcomRuleLifetime } STATUS current DESCRIPTION "This notification is generated whenever the value of midcomRuleOperStatus enters any error state or any termination state without an explicit trigger by a MIDCOM client." ::= { midcomNotifications 1 } midcomSolicitedRuleEvent NOTIFICATION-TYPE OBJECTS { midcomRuleOperStatus, midcomRuleLifetime } STATUS current DESCRIPTION "This notification is generated whenever the value of midcomRuleOperStatus enters one of the states {reserved, enabled, any error state, any termination state} as a result of a MIDCOM agent writing successfully to object midcomRuleAdminStatus. In addition, it is generated when the lifetime of a rule was changed by successfully writing to object midcomRuleLifetime." ::= { midcomNotifications 2 } midcomSolicitedGroupEvent NOTIFICATION-TYPE OBJECTS { midcomGroupLifetime } STATUS current DESCRIPTION "This notification is generated for indicating that the lifetime of all member rules of the group was changed by successfully writing to object midcomGroupLifetime. Note that this notification is only sent if the lifetime of a group was changed by successfully writing to object midcomGroupLifetime. No notification is sent - if a group's lifetime is changed by writing to object midcomRuleLifetime of any of its member policies, - if a group's lifetime expires (in this case, notifications are sent for all member policies), or - if the group is terminated by terminating the last of its member policies without writing to object midcomGroupLifetime." ::= { midcomNotifications 3 } -- -- Conformance information -- Quittek, et al. Standards Track [Page 80] RFC 5190 MIDCOM MIB March 2008 midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 } midcomGroups OBJECT IDENTIFIER ::= { midcomConformance 2 } -- -- compliance statements -- -- This is the MIDCOM compliance definition ... -- midcomCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for implementations of the MIDCOM-MIB module. Note that compliance with this compliance statement requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]." MODULE -- this module MANDATORY-GROUPS { midcomRuleGroup, midcomNotificationsGroup, midcomCapabilitiesGroup, midcomStatisticsGroup } GROUP midcomConfigFirewallGroup DESCRIPTION "A compliant implementation does not have to implement the midcomConfigFirewallGroup." GROUP midcomResourceGroup DESCRIPTION "A compliant implementation does not have to implement the midcomResourceGroup." OBJECT midcomRuleInternalIpPrefixLength MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported, return 128 as the value of this object. A value of 128 means that the function represented by this option is not supported." OBJECT midcomRuleExternalIpPrefixLength MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported, return 128 as the value of this object. Quittek, et al. Standards Track [Page 81] RFC 5190 MIDCOM MIB March 2008 A value of 128 means that the function represented by this option is not supported." OBJECT midcomRuleMaxIdleTime MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported, return 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT midcomRuleInterface MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigMaxLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigPersistentRules MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigIfEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigFirewallGroupId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigFirewallPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { midcomCompliances 1 } midcomRuleGroup OBJECT-GROUP OBJECTS { midcomRuleAdminStatus, midcomRuleOperStatus, midcomRuleStorageType, midcomRuleStorageTime, midcomRuleError, midcomRuleInterface, midcomRuleFlowDirection, midcomRuleMaxIdleTime, midcomRuleTransportProtocol, midcomRulePortRange, midcomRuleInternalIpVersion, Quittek, et al. Standards Track [Page 82] RFC 5190 MIDCOM MIB March 2008 midcomRuleExternalIpVersion, midcomRuleInternalIpAddr, midcomRuleInternalIpPrefixLength, midcomRuleInternalPort, midcomRuleExternalIpAddr, midcomRuleExternalIpPrefixLength, midcomRuleExternalPort, midcomRuleInsideIpAddr, midcomRuleInsidePort, midcomRuleOutsideIpAddr, midcomRuleOutsidePort, midcomRuleLifetime, midcomRuleRowStatus, midcomGroupLifetime } STATUS current DESCRIPTION "A collection of objects providing information about policy rules and policy rule groups." ::= { midcomGroups 1 } midcomCapabilitiesGroup OBJECT-GROUP OBJECTS { midcomConfigMaxLifetime, midcomConfigPersistentRules, midcomConfigIfBits, midcomConfigIfEnabled } STATUS current DESCRIPTION "A collection of objects providing information about the capabilities of a middlebox." ::= { midcomGroups 2 } midcomConfigFirewallGroup OBJECT-GROUP OBJECTS { midcomConfigFirewallGroupId, midcomConfigFirewallPriority } STATUS current DESCRIPTION "A collection of objects providing information about the firewall rule group and firewall rule priority to be used by firewalls loaded through MIDCOM." ::= { midcomGroups 3 } midcomResourceGroup OBJECT-GROUP OBJECTS { Quittek, et al. Standards Track [Page 83] RFC 5190 MIDCOM MIB March 2008 midcomRscNatInternalAddrBindMode, midcomRscNatInternalAddrBindId, midcomRscNatInsideAddrBindMode, midcomRscNatInsideAddrBindId, midcomRscNatSessionId1, midcomRscNatSessionId2, midcomRscFirewallRuleId } STATUS current DESCRIPTION "A collection of objects providing information about the used NAT and firewall resources." ::= { midcomGroups 4 } midcomStatisticsGroup OBJECT-GROUP OBJECTS { midcomCurrentOwners, midcomTotalRejectedRuleEntries, midcomCurrentRulesIncomplete, midcomTotalIncorrectReserveRules, midcomTotalRejectedReserveRules, midcomCurrentActiveReserveRules, midcomTotalExpiredReserveRules, midcomTotalTerminatedOnRqReserveRules, midcomTotalTerminatedReserveRules, midcomTotalIncorrectEnableRules, midcomTotalRejectedEnableRules, midcomCurrentActiveEnableRules, midcomTotalExpiredEnableRules, midcomTotalTerminatedOnRqEnableRules, midcomTotalTerminatedEnableRules } STATUS current DESCRIPTION "A collection of objects providing statistical information about the MIDCOM server." ::= { midcomGroups 5 } Quittek, et al. Standards Track [Page 84] RFC 5190 MIDCOM MIB March 2008 midcomNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent, midcomSolicitedGroupEvent } STATUS current DESCRIPTION "The notifications emitted by the midcomMIB." ::= { midcomGroups 6 } END 10. Security Considerations Obviously, securing access to firewall and NAT configuration is extremely important for maintaining network security. This section first describes general security issues of the MIDCOM-MIB module and then discusses three concrete security threats: unauthorized middlebox configuration, unauthorized access to middlebox configuration information, and unauthorized access to the MIDCOM service configuration. 10.1. General Security Issues There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. But also access to managed objects with a MAX-ACCESS clause of read-only may be considered sensitive or vulnerable. The support for SET and GET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Compliant MIDCOM-MIB implementations MUST support SNMPv3 security services including data integrity, identity authentication, data confidentiality, and replay protection. Quittek, et al. Standards Track [Page 85] RFC 5190 MIDCOM MIB March 2008 It is REQUIRED that the implementations support the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View-based Access Control Model RFC 3415 [RFC3415] is RECOMMENDED. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. To facilitate the provisioning of access control by a security administrator using the View-based Access Control Model (VACM) defined in RFC 3415 [RFC3415] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". This is supported by the midcomRuleTable and the midcomGroupTable. Each of them uses midcomRuleOwner as the initial index. midcomRuleOwner has the syntax of SnmpAdminString, and can thus be trivially mapped to an SNMP securityName or a groupName as defined in VACM, in accordance with a security policy. All entries in the two mentioned tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. 10.2. Unauthorized Middlebox Configuration The most dangerous threat to network security related to the MIDCOM- MIB module is unauthorized access to facilities for establishing policy rules. In such a case, unauthorized principals would write to the midcomRuleTable for opening firewall pinholes and/or for creating NAT maps, bindings, and/or sessions. Establishing policies can be used to gain access to networks and systems that are protected by firewalls and/or NATs. If this protection is removed by unauthorized access to MIDCOM-MIB policies, then the resulting degradation of network security can be severe. Confidential information protected by a firewall might become accessible to unauthorized principals, attacks exploiting Quittek, et al. Standards Track [Page 86] RFC 5190 MIDCOM MIB March 2008 security leaks of systems in the protected network might become possible from external networks, and it might be possible to stop firewalls blocking denial-of-service attacks. MIDCOM-MIB implementations MUST provide means for strict authentication, message integrity check, and write access control to managed objects that can be used for establishing policy rules. These are objects in the midcomRuleTable and midcomGroupTable with a MAX-ACCESS clause of read-write and/or read-create. Particularly sensitive is write access to the managed object midcomRuleAdminStatus, because writing it causes policy rules to be established. Also, writing to other managed objects in the two tables can make security vulnerable if it interferes with the authorized establishment of a policy rule, for example, by wildcarding a policy rule after the corresponding entry in the midcomRuleTable is created, but before the authorized owner establishes the rule by writing to midcomRuleAdminStatus. Not only unauthorized establishment, but also unauthorized lifetime extension of an existing policy rule may be considered sensitive or vulnerable in some network environments. Therefore, means for strict authentication, message integrity check, and write access control to managed object midcomGroupLifetime MUST be provided by MIDCOM-MIB implementations. 10.3. Unauthorized Access to Middlebox Configuration Another threat to network security is unauthorized access to entries in the midcomRuleTable. The entries contain information about existing pinholes in the firewall and/or about the current NAT configuration. This information can be used for attacking the internal network from outside. Therefore, a MIDCOM-MIB implementation MUST also provide means for read access control to the midcomRuleTable. Also, a MIDCOM-MIB implementation SHOULD provide means for protecting different authenticated MIDCOM agents from each other, such that, for example, an authenticated user can only read entries in the midcomRuleTable for which the initial index midcomRuleOwner matches the client's SNMP securityName or VACM groupName. Quittek, et al. Standards Track [Page 87] RFC 5190 MIDCOM MIB March 2008 10.4. Unauthorized Access to MIDCOM Service Configuration There are three objects with a MAX-ACCESS clause of read-write that configure the MIDCOM service: midcomConfigIfEnabled, midcomFirewallGroupId, and midcomFirewallPriority. Unauthorized writing to object midcomConfigIfEnabled can cause serious interruptions of network service. Writing to midcomFirewallGroupId and/or midcomFirewallPriority can be used to increase or reduce the priority of firewall rules that are generated when a policy rule is established in the midcomRuleTable. Increasing the priority might permit firewall rules generated via the MIDCOM-MIB module to overrule basic security rules at the firewall that should have higher priority than the ones generated via the MIDCOM-MIB module. Therefore, also for these objects, means for strict control of write access MUST be provided by a MIDCOM-MIB implementation. 11. Acknowledgements This memo is based on a long history of discussion within the MIDCOM MIB design team. Many thanks to Mary Barnes, Jeff Case, Wes Hardaker, David Harrington, and Tom Taylor for fruitful comments and recommendations and to Juergen Schoenwaelder acting as a very constructive MIB doctor. 12. IANA Considerations IANA has assigned an OID for the MIB module in this document: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- midcomMIB { mib-2 171 } 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 5189, March 2008. Quittek, et al. Standards Track [Page 88] RFC 5190 MIDCOM MIB March 2008 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005. Quittek, et al. Standards Track [Page 89] RFC 5190 MIDCOM MIB March 2008 14. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Quittek, et al. Standards Track [Page 90] RFC 5190 MIDCOM MIB March 2008 Authors' Addresses Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-115 EMail: quittek@nw.neclab.eu Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-113 EMail: stiemerling@nw.neclab.eu Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A. Phone: +1 408 836 4773 EMail: srisuresh@yahoo.com Quittek, et al. Standards Track [Page 91] RFC 5190 MIDCOM MIB March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Quittek, et al. Standards Track [Page 92] snmp-mibs-downloader-1.1/mibrfcs/rfc5240.txt0000644000000000000000000012321411402176072015560 0ustar Network Working Group B. Joshi Request for Comments: 5240 Infosys Technologies Ltd. Category: Standards Track R. Bijlani June 2008 Protocol Independent Multicast (PIM) Bootstrap Router MIB 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. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Joshi & Bijlani Standards Track [Page 1] RFC 5240 PIM BSR MIB June 2008 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM [RFC4601], [RFC5059]. This document was created by moving some of the PIM BSR-specific MIB tables from one of the earlier versions of PIM MIB [RFC5060]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 4. Overview This MIB module contains four tables. The tables are: 1. The Candidate-RP Table, which contains one row for each multicast group address prefix for which the local router is configured to advertise itself as a Candidate-RP (C-RP). This table exists on routers that are configured as Candidate-RP. 2. The Elected BSR RP-Set Table, which contains one row for each Group-to-RP mapping that was received in C-RP advertisements. This table exists on a router that is an elected BSR (E-BSR). 3. The Candidate-BSR Table, which contains one row for each Candidate-BSR configuration for the local router. This table exists on routers that are configured as Candidate-BSR. Joshi & Bijlani Standards Track [Page 2] RFC 5240 PIM BSR MIB June 2008 4. The Elected-BSR Table, which contains one row for each elected BSR. This table exists on a router that is an elected BSR. This MIB module uses textual conventions defined in the INET-ADDRESS- MIB [RFC4001]. 5. Definitions PIM-BSR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Unsigned32, TimeTicks FROM SNMPv2-SMI RowStatus, TruthValue, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InetAddressType, InetAddressPrefixLength, InetAddress, InetZoneIndex FROM INET-ADDRESS-MIB; pimBsrMIB MODULE-IDENTITY LAST-UPDATED "200805280000Z" -- 28 May 2008 ORGANIZATION "IETF Protocol Independent Multicast (PIM) Working Group" CONTACT-INFO "Email: pim@ietf.org WG charter: http://www.ietf.org/html.charters/pim-charter.html" DESCRIPTION "The MIB module for management of the Bootstrap Router (BSR) mechanism for PIM routers. Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5240; see the RFC itself for full legal notices." REVISION "200805280000Z" -- 28 May 2008 DESCRIPTION "Initial version, published as RFC 5240." ::= { mib-2 172 } -- -- Top-level structure -- pimBsrNotifications OBJECT IDENTIFIER ::= { pimBsrMIB 0 } pimBsrObjects OBJECT IDENTIFIER ::= { pimBsrMIB 1 } Joshi & Bijlani Standards Track [Page 3] RFC 5240 PIM BSR MIB June 2008 -- -- Conformance Information -- pimBsrConformance OBJECT IDENTIFIER ::= { pimBsrMIB 2 } pimBsrCompliances OBJECT IDENTIFIER ::= { pimBsrConformance 1 } pimBsrGroups OBJECT IDENTIFIER ::= { pimBsrConformance 2 } -- -- The BSR Candidate-RP Table -- pimBsrCandidateRPTable OBJECT-TYPE SYNTAX SEQUENCE OF PimBsrCandidateRPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the IP multicast group prefixes for which the local router is to advertise itself as a Candidate-RP." ::= { pimBsrObjects 1 } pimBsrCandidateRPEntry OBJECT-TYPE SYNTAX PimBsrCandidateRPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimBsrCandidateRPTable." INDEX { pimBsrCandidateRPAddressType, pimBsrCandidateRPAddress, pimBsrCandidateRPGroupAddress, pimBsrCandidateRPGroupPrefixLength } ::= { pimBsrCandidateRPTable 1 } PimBsrCandidateRPEntry ::= SEQUENCE { pimBsrCandidateRPAddressType InetAddressType, pimBsrCandidateRPAddress InetAddress, pimBsrCandidateRPGroupAddress InetAddress, pimBsrCandidateRPGroupPrefixLength InetAddressPrefixLength, pimBsrCandidateRPBidir TruthValue, pimBsrCandidateRPAdvTimer TimeTicks, pimBsrCandidateRPPriority Unsigned32, pimBsrCandidateRPAdvInterval Unsigned32, pimBsrCandidateRPHoldtime Unsigned32, pimBsrCandidateRPStatus RowStatus, pimBsrCandidateRPStorageType StorageType } Joshi & Bijlani Standards Track [Page 4] RFC 5240 PIM BSR MIB June 2008 pimBsrCandidateRPAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Inet address type of the Candidate-RP." ::= { pimBsrCandidateRPEntry 1 } pimBsrCandidateRPAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (unicast) address that will be advertised as a Candidate-RP. The InetAddressType is given by the pimBsrCandidateRPAddressType object." ::= { pimBsrCandidateRPEntry 2 } pimBsrCandidateRPGroupAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address that, when combined with the corresponding value of pimBsrCandidateRPGroupPrefixLength, identifies a group prefix for which the local router will advertise itself as a Candidate-RP. The InetAddressType is given by the pimBsrCandidateRPAddressType object. This address object is only significant up to pimBsrCandidateRPGroupPrefixLength bits. The remainder of the address bits are zero. This is especially important for this field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry." ::= { pimBsrCandidateRPEntry 3 } pimBsrCandidateRPGroupPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength (4..128) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group address mask that, when combined with the corresponding value of pimBsrCandidateRPGroupAddress, identifies a group prefix for which the local router will advertise itself as a Candidate-RP. The InetAddressType is given by the Joshi & Bijlani Standards Track [Page 5] RFC 5240 PIM BSR MIB June 2008 pimBsrCandidateRPAddressType object." ::= { pimBsrCandidateRPEntry 4 } pimBsrCandidateRPBidir OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If this object is set to TRUE, this group range is advertised with this RP as a BIDIR-PIM group range. If it is set to FALSE, it is advertised as a PIM-SM group range." DEFVAL { false } ::= { pimBsrCandidateRPEntry 5 } pimBsrCandidateRPAdvTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the local router next sends a Candidate-RP-Advertisement to the elected BSR for this zone." ::= { pimBsrCandidateRPEntry 6 } pimBsrCandidateRPPriority OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The priority for this Candidate-RP advertised in Candidate-RP-Advertisements." REFERENCE "RFC 5059, section 3.2" DEFVAL { 192 } ::= { pimBsrCandidateRPEntry 7 } pimBsrCandidateRPAdvInterval OBJECT-TYPE SYNTAX Unsigned32 (1..26214) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A Candidate-RP generates Candidate-RP-Advertisements periodically. This object represents the time interval in seconds between two consecutive advertisements." REFERENCE "RFC 5059, sections 3.2 and 5" DEFVAL { 60 } Joshi & Bijlani Standards Track [Page 6] RFC 5240 PIM BSR MIB June 2008 ::= { pimBsrCandidateRPEntry 8 } pimBsrCandidateRPHoldtime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Holdtime for this Candidate-RP. The amount of time (in seconds) this Candidate-RP entry is valid. This object's value can be zero only when this C-RP is shutting down." REFERENCE "RFC 5059, section 4.2" DEFVAL { 150 } ::= { pimBsrCandidateRPEntry 9 } pimBsrCandidateRPStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. This status object can be set to active(1) without setting any other columnar objects in this entry. All writable objects in this entry can be modified when the status of this entry is active(1)." ::= { pimBsrCandidateRPEntry 10 } pimBsrCandidateRPStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { pimBsrCandidateRPEntry 11 } -- Joshi & Bijlani Standards Track [Page 7] RFC 5240 PIM BSR MIB June 2008 -- The BSR Elected BSR RP-Set Table -- pimBsrElectedBSRRPSetTable OBJECT-TYPE SYNTAX SEQUENCE OF PimBsrElectedBSRRPSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing BSR-specific information about PIM group mappings learned via C-RP advertisements or created locally using configurations. This table is maintained only on the Elected BSR. An Elected BSR uses this table to create Bootstrap messages after applying a local policy to include some or all of the group mappings in this table." ::= { pimBsrObjects 2 } pimBsrElectedBSRRPSetEntry OBJECT-TYPE SYNTAX PimBsrElectedBSRRPSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimBsrElectedBSRRPSetTable." INDEX { pimBsrElectedBSRGrpMappingAddrType, pimBsrElectedBSRGrpMappingGrpAddr, pimBsrElectedBSRGrpMappingGrpPrefixLen, pimBsrElectedBSRGrpMappingRPAddr } ::= { pimBsrElectedBSRRPSetTable 1 } PimBsrElectedBSRRPSetEntry ::= SEQUENCE { pimBsrElectedBSRGrpMappingAddrType InetAddressType, pimBsrElectedBSRGrpMappingGrpAddr InetAddress, pimBsrElectedBSRGrpMappingGrpPrefixLen InetAddressPrefixLength, pimBsrElectedBSRGrpMappingRPAddr InetAddress, pimBsrElectedBSRRPSetPriority Unsigned32, pimBsrElectedBSRRPSetHoldtime Unsigned32, pimBsrElectedBSRRPSetExpiryTime TimeTicks, pimBsrElectedBSRRPSetGrpBidir TruthValue } pimBsrElectedBSRGrpMappingAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION Joshi & Bijlani Standards Track [Page 8] RFC 5240 PIM BSR MIB June 2008 "The Inet address type of the IP multicast group prefix." ::= { pimBsrElectedBSRRPSetEntry 2 } pimBsrElectedBSRGrpMappingGrpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address that, when combined with pimBsrElectedBSRGrpMappingGrpPrefixLen, gives the group prefix for this mapping. The InetAddressType is given by the pimBsrElectedBSRGrpMappingAddrType object. This address object is only significant up to pimBsrElectedBSRGrpMappingGrpPrefixLen bits. The remainder of the address bits are zero. This is especially important for this field, which is part of the index of this entry. Any non-zero bits would signify an entirely different entry." ::= { pimBsrElectedBSRRPSetEntry 3 } pimBsrElectedBSRGrpMappingGrpPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength (4..128) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The multicast group prefix length that, when combined with pimBsrElectedBSRGrpMappingGrpAddr, gives the group prefix for this mapping. The InetAddressType is given by the pimBsrElectedBSRGrpMappingAddrType object. If pimBsrElectedBSRGrpMappingAddrType is 'ipv4' or 'ipv4z', this object must be in the range 4..32. If pimBsrElectedBSRGrpMappingAddrType is 'ipv6' or 'ipv6z', this object must be in the range 8..128." ::= { pimBsrElectedBSRRPSetEntry 4 } pimBsrElectedBSRGrpMappingRPAddr OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the RP to be used for groups within this group prefix. The InetAddressType is given by the pimBsrElectedBSRGrpMappingAddrType object." ::= { pimBsrElectedBSRRPSetEntry 5 } pimBsrElectedBSRRPSetPriority OBJECT-TYPE Joshi & Bijlani Standards Track [Page 9] RFC 5240 PIM BSR MIB June 2008 SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The priority for RP. Numerically higher values for this object indicate lower priorities, with the value zero denoting the highest priority." REFERENCE "RFC 5059, section 4.1" ::= { pimBsrElectedBSRRPSetEntry 6 } pimBsrElectedBSRRPSetHoldtime OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The holdtime for RP" REFERENCE "RFC 5059, section 4.1" ::= { pimBsrElectedBSRRPSetEntry 7 } pimBsrElectedBSRRPSetExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time remaining before this entry will be aged out. The value zero indicates that this entry will never be aged out." ::= { pimBsrElectedBSRRPSetEntry 8 } pimBsrElectedBSRRPSetGrpBidir OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If this object is TRUE, this group range with this RP is a BIDIR-PIM group range. If it is set to FALSE, it is a PIM-SM group range." ::= { pimBsrElectedBSRRPSetEntry 9 } -- -- The BSR Candidate-BSR Table -- pimBsrCandidateBSRTable OBJECT-TYPE SYNTAX SEQUENCE OF PimBsrCandidateBSREntry MAX-ACCESS not-accessible STATUS current Joshi & Bijlani Standards Track [Page 10] RFC 5240 PIM BSR MIB June 2008 DESCRIPTION "The (conceptual) table containing Candidate-BSR configuration for the local router. The table contains one row for each zone for which the local router is to advertise itself as a Candidate-BSR." ::= { pimBsrObjects 3 } pimBsrCandidateBSREntry OBJECT-TYPE SYNTAX PimBsrCandidateBSREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimBsrCandidateBSRTable." INDEX { pimBsrCandidateBSRZoneIndex } ::= { pimBsrCandidateBSRTable 1 } PimBsrCandidateBSREntry ::= SEQUENCE { pimBsrCandidateBSRZoneIndex InetZoneIndex, pimBsrCandidateBSRAddressType InetAddressType, pimBsrCandidateBSRAddress InetAddress, pimBsrCandidateBSRPriority Unsigned32, pimBsrCandidateBSRHashMaskLength Unsigned32, pimBsrCandidateBSRElectedBSR TruthValue, pimBsrCandidateBSRBootstrapTimer TimeTicks, pimBsrCandidateBSRStatus RowStatus, pimBsrCandidateBSRStorageType StorageType } pimBsrCandidateBSRZoneIndex OBJECT-TYPE SYNTAX InetZoneIndex (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The zone index uniquely identifies the zone on a device to which this Candidate-BSR is attached. There is one entry for each zone in ipMcastZoneTable. Scope-level information for this zone can be extracted from ipMcastZoneTable in IP Multicast MIB [RFC5132]. Zero is a special value used to request the default zone for a given scope. Zero is not a valid value for this object." ::= { pimBsrCandidateBSREntry 1 } pimBsrCandidateBSRAddressType OBJECT-TYPE SYNTAX InetAddressType Joshi & Bijlani Standards Track [Page 11] RFC 5240 PIM BSR MIB June 2008 MAX-ACCESS read-create STATUS current DESCRIPTION "The address type of the Candidate-BSR." ::= { pimBsrCandidateBSREntry 2 } pimBsrCandidateBSRAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The (unicast) address that the local router will use to advertise itself as a Candidate-BSR. The InetAddressType is given by the pimBsrCandidateBSRAddressType object." ::= { pimBsrCandidateBSREntry 3 } pimBsrCandidateBSRPriority OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The priority value for the local router as a Candidate-BSR for this zone. Numerically higher values for this object indicate higher priorities." DEFVAL { 0 } ::= { pimBsrCandidateBSREntry 4 } pimBsrCandidateBSRHashMaskLength OBJECT-TYPE SYNTAX Unsigned32 (0..128) MAX-ACCESS read-create STATUS current DESCRIPTION "The hash mask length (used in the RP hash function) that the local router will advertise in its Bootstrap messages for this zone. This object defaults to 30 if pimBsrCandidateBSRAddressType is 'ipv4' or 'ipv4z' , and defaults to 126 if pimBsrCandidateBSRAddressType is 'ipv6' or 'ipv6z'." ::= { pimBsrCandidateBSREntry 5 } pimBsrCandidateBSRElectedBSR OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether the local router is the elected BSR for this zone." Joshi & Bijlani Standards Track [Page 12] RFC 5240 PIM BSR MIB June 2008 ::= { pimBsrCandidateBSREntry 6 } pimBsrCandidateBSRBootstrapTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the local router next originates a Bootstrap message for this zone. Value of this object is zero if pimBsrCandidateBSRElectedBSR is 'FALSE'." ::= { pimBsrCandidateBSREntry 7 } pimBsrCandidateBSRStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created or old entries deleted from this table. This status object can be set to active(1) without setting any other columnar objects in this entry. All writable objects in this entry can be modified when the status of this entry is active(1)." ::= { pimBsrCandidateBSREntry 8 } pimBsrCandidateBSRStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this row. Rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { pimBsrCandidateBSREntry 9 } -- -- The BSR Elected-BSR Table -- pimBsrElectedBSRTable OBJECT-TYPE SYNTAX SEQUENCE OF PimBsrElectedBSREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Joshi & Bijlani Standards Track [Page 13] RFC 5240 PIM BSR MIB June 2008 "The (conceptual) table containing information about elected BSRs. The table contains one row for each zone for which there is an elected BSR." ::= { pimBsrObjects 4 } pimBsrElectedBSREntry OBJECT-TYPE SYNTAX PimBsrElectedBSREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the pimBsrElectedBSRTable." INDEX { pimBsrElectedBSRZoneIndex } ::= { pimBsrElectedBSRTable 1 } PimBsrElectedBSREntry ::= SEQUENCE { pimBsrElectedBSRZoneIndex InetZoneIndex, pimBsrElectedBSRAddressType InetAddressType, pimBsrElectedBSRAddress InetAddress, pimBsrElectedBSRPriority Unsigned32, pimBsrElectedBSRHashMaskLength Unsigned32, pimBsrElectedBSRExpiryTime TimeTicks } pimBsrElectedBSRZoneIndex OBJECT-TYPE SYNTAX InetZoneIndex (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The zone index uniquely identifies the zone on a device to which this Elected BSR is attached. There is one entry for each zone in ipMcastZoneTable. Scope-level information for this zone can be extracted from ipMcastZoneTable in IP Multicast MIB [RFC5132]. Zero is a special value used to request the default zone for a given scope. Zero is not a valid value for this object." ::= { pimBsrElectedBSREntry 1 } pimBsrElectedBSRAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of the elected BSR." ::= { pimBsrElectedBSREntry 2 } Joshi & Bijlani Standards Track [Page 14] RFC 5240 PIM BSR MIB June 2008 pimBsrElectedBSRAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|8|16|20)) MAX-ACCESS read-only STATUS current DESCRIPTION "The (unicast) address of the elected BSR. The InetAddressType is given by the pimBsrElectedBSRAddressType object." ::= { pimBsrElectedBSREntry 3 } pimBsrElectedBSRPriority OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The priority value for the elected BSR for this address type. Numerically higher values for this object indicate higher priorities." ::= { pimBsrElectedBSREntry 4 } pimBsrElectedBSRHashMaskLength OBJECT-TYPE SYNTAX Unsigned32 (0..128) MAX-ACCESS read-only STATUS current DESCRIPTION "The hash mask length (used in the RP hash function) advertised by the elected BSR for this zone." ::= { pimBsrElectedBSREntry 5 } pimBsrElectedBSRExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum time remaining before the elected BSR for this zone will be declared down." ::= { pimBsrElectedBSREntry 6 } -- -- PIM BSR Notifications -- pimBsrElectedBSRLostElection NOTIFICATION-TYPE OBJECTS { pimBsrElectedBSRAddressType, pimBsrElectedBSRAddress, pimBsrElectedBSRPriority } STATUS current DESCRIPTION Joshi & Bijlani Standards Track [Page 15] RFC 5240 PIM BSR MIB June 2008 "A pimBsrElectedBSRLostElection notification should be generated when current E-BSR lost election to a new Candidate-BSR. Only an E-BSR should generate this notification. This notification is generated when pimBsrCandidateBSRElectedBSR becomes FALSE." REFERENCE "RFC 5059, section 3.1" ::= { pimBsrNotifications 1 } pimBsrCandidateBSRWinElection NOTIFICATION-TYPE OBJECTS { pimBsrCandidateBSRElectedBSR } STATUS current DESCRIPTION "A pimBsrCandidateBSRWinElection notification should be generated when a C-BSR wins BSR Election. Only an E-BSR should generate this notification. This notification is generated when pimBsrCandidateBSRElectedBSR becomes TRUE." REFERENCE "RFC 5059, section 3.1" ::= { pimBsrNotifications 2 } -- -- Compliance Statements -- pimBsrCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for PIM routers that implement the Bootstrap Router (BSR) mechanism." MODULE -- this module MANDATORY-GROUPS { pimBsrObjectGroup } GROUP pimBsrDiagnosticsGroup DESCRIPTION "This group is optional." ::= { pimBsrCompliances 1 } -- -- Units of Conformance -- pimBsrObjectGroup OBJECT-GROUP Joshi & Bijlani Standards Track [Page 16] RFC 5240 PIM BSR MIB June 2008 OBJECTS { pimBsrCandidateRPBidir, pimBsrCandidateRPAdvTimer, pimBsrCandidateRPPriority, pimBsrCandidateRPAdvInterval, pimBsrCandidateRPHoldtime, pimBsrCandidateRPStatus, pimBsrCandidateRPStorageType, pimBsrElectedBSRRPSetPriority, pimBsrElectedBSRRPSetHoldtime, pimBsrElectedBSRRPSetExpiryTime, pimBsrElectedBSRRPSetGrpBidir, pimBsrCandidateBSRAddress, pimBsrCandidateBSRAddressType, pimBsrCandidateBSRPriority, pimBsrCandidateBSRHashMaskLength, pimBsrCandidateBSRElectedBSR, pimBsrCandidateBSRBootstrapTimer, pimBsrCandidateBSRStatus, pimBsrCandidateBSRStorageType, pimBsrElectedBSRAddress, pimBsrElectedBSRAddressType, pimBsrElectedBSRPriority, pimBsrElectedBSRHashMaskLength, pimBsrElectedBSRExpiryTime } STATUS current DESCRIPTION "A collection of objects for managing the Bootstrap Router (BSR) mechanism for PIM routers." ::= { pimBsrGroups 1 } pimBsrDiagnosticsGroup NOTIFICATION-GROUP NOTIFICATIONS { pimBsrElectedBSRLostElection, pimBsrCandidateBSRWinElection } STATUS current DESCRIPTION "Objects providing additional diagnostics related to the Bootstrap Router (BSR) mechanism for PIM routers." ::= { pimBsrGroups 2 } END 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure Joshi & Bijlani Standards Track [Page 17] RFC 5240 PIM BSR MIB June 2008 environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o A new Candidate-BSR with high priority or modification of priority ( bsrCandidateBSRPriority ) of an existing Candidate-BSR can take over the functionality of an Elected BSR, which can prevent and disrupt the services. o A new Candidate-RP with lower priority or modification of priority ( bsrCandidateRPPriority ) of an existing Candidate-RP can force other routers to select itself for a particular group prefix. This can prevent and disrupt the services provided through this group prefix. The following are the read-write and read-create objects defined in this MIB module: bsrCandidateRPBidir bsrCandidateRPPriority bsrCandidateRPAdvInterval bsrCandidateRPHoldtime bsrCandidateBSRAddressType bsrCandidateBSRAddress bsrCandidateBSRPriority bsrCandidateBSRHashMaskLength Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: pimBsrCandidateRPAdvTimer pimBsrElectedBSRRPSetPriority pimBsrElectedBSRRPSetHoldtime pimBsrElectedBSRRPSetExpiryTime pimBsrElectedBSRRPSetGrpBidir pimBsrCandidateBSRElectedBSR pimBsrCandidateBSRBootstrapTimer pimBsrElectedBSRAddressType pimBsrElectedBSRAddress pimBsrElectedBSRPriority pimBsrElectedBSRHashMaskLength pimBsrElectedBSRExpiryTime Joshi & Bijlani Standards Track [Page 18] RFC 5240 PIM BSR MIB June 2008 In this MIB module, possible effects that can be induced by GET operations include: o Determination of Elected BSR, Candidate-BSRs, and Candidate-RPs in the Multicast Network topology. This information may be sensitive and may be used in preparation for Denial-of-Service (DoS) attacks including any of the attacks described above. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is still no control over whom on the secure network is allowed to access (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to access (read/change/create/delete) them. 7. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pimBsrMIB { mib-2 172 } 8. Acknowledgments This MIB module is based on the original work in [RFC5060] by R. Sivaramu, J. Lingard, and B. Joshi. Many thanks to Bill Fenner, Stig Venaas, Nidhi Bhaskar, David Mcwalter, David Harrington, and J. W. Atwood for their feedback on this MIB module. Suggested IPv6 multicast MIBs by R. Sivaramu and R. Raghunarayan have been used for comparison while editing this MIB module. Joshi & Bijlani Standards Track [Page 19] RFC 5240 PIM BSR MIB June 2008 9. References Joshi & Bijlani Standards Track [Page 20] RFC 5240 PIM BSR MIB June 2008 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. Kessler, "Protocol Independent Multicast MIB", RFC 5060, January 2008. [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. [RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", RFC 5132, December 2007. 9.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Joshi & Bijlani Standards Track [Page 21] RFC 5240 PIM BSR MIB June 2008 Authors' Addresses Bharat Joshi Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India EMail: bharat_joshi@infosys.com URI: http://www.infosys.com/ Raina Bijlani EMail: rainab@gmail.com Joshi & Bijlani Standards Track [Page 22] RFC 5240 PIM BSR MIB June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Joshi & Bijlani Standards Track [Page 23] snmp-mibs-downloader-1.1/mibrfcs/rfc5324.txt0000644000000000000000000155533611402176072015602 0ustar Network Working Group C. DeSanti Request for Comments: 5324 F. Maino Category: Standards Track K. McCloghrie Cisco Systems September 2008 MIB for Fibre-Channel Security Protocols (FC-SP) 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. Table of Contents 1. Introduction ....................................................3 2. The Internet-Standard Management Framework ......................3 3. Overview of Fibre Channel .......................................3 3.1. Introduction ...............................................3 3.2. Zoning .....................................................4 3.3. Virtual Fabrics ............................................5 3.4. Security ...................................................5 3.4.1. Authentication ......................................5 3.4.2. Security Associations ...............................6 3.4.3. Fabric Security Policies ............................7 3.4.4. Policy Model ........................................8 3.4.5. Policy Objects ......................................9 3.4.5.1. Policy Object Names .......................10 3.4.6. Three Kinds of Switches ............................10 3.4.7. Security Policy Management .........................11 3.4.8. FC-SP Zoning .......................................11 4. Document Overview ..............................................12 4.1. Fibre Channel Management Instance .........................12 4.2. Entity Name ...............................................12 4.3. Fabric Index ..............................................13 4.4. Interface Index ...........................................13 4.5. Syntax for Policy Object Names ............................14 De Santi, et al. Standards Track [Page 1] RFC 5324 MIB for FC-SP September 2008 4.6. Certificates, CAs, and CRLs ...............................14 4.7. Traffic Selectors .........................................15 4.8. The MIB Modules ...........................................16 4.8.1. The T11-FC-SP-TC-MIB Module ........................16 4.8.2. The T11-FC-SP-AUTHENTICATION-MIB Module ............16 4.8.3. The T11-FC-SP-ZONING-MIB Module ....................16 4.8.4. The T11-FC-SP-POLICY-MIB Module ....................17 4.8.5. The T11-FC-SP-SA-MIB Module ........................17 4.9. Rate Control for Notifications ............................18 5. Relationship to Other MIB Modules ..............................19 6. MIB Module Definitions .........................................20 6.1. The T11-FC-SP-TC-MIB Module ...............................20 6.2. The T11-FC-SP-AUTHENTICATION-MIB Module ...................33 6.3. The T11-FC-SP-ZONING-MIB Module ...........................52 6.4. The T11-FC-SP-POLICY-MIB Module ...........................64 6.5. The T11-FC-SP-SA-MIB Module ..............................152 7. IANA Considerations ...........................................204 8. Security Considerations .......................................204 8.1. Information Not Defined in This Document .................204 8.2. The T11-FC-SP-TC-MIB Module ..............................204 8.3. The T11-FC-SP-AUTHENTICATION-MIB Module ..................205 8.4. The T11-FC-SP-ZONING-MIB Module ..........................206 8.5. The T11-FC-SP-POLICY-MIB Module ..........................207 8.6. The T11-FC-SP-SA-MIB Module ..............................209 8.7. Recommendations Common to All MIB Modules ................211 9. Normative References ..........................................212 10. Informative References .......................................213 11. Acknowledgements .............................................215 De Santi, et al. Standards Track [Page 2] RFC 5324 MIB for FC-SP September 2008 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information concerning the Fibre Channel Security Protocols (FC-SP), as specified in [FC-SP]. The FC-SP standard includes the definition of protocols to authenticate Fibre Channel entities, protocols to set up session keys, protocols to negotiate the parameters required to ensure frame- by-frame integrity and confidentiality, and protocols to establish and distribute policies across a Fibre Channel Fabric. This memo was initially developed by the INCITS T11 committee (http://www.t11.org), which subsequently approved it for forwarding to the IETF. This memo uses one of the following terms: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. 3. Overview of Fibre Channel 3.1. Introduction Fibre Channel (FC) is logically a bidirectional point-to-point serial data channel, structured for high performance. Fibre Channel provides a general transport vehicle for higher-level protocols such as Small Computer System Interface (SCSI) command sets, the High- Performance Parallel Interface (HIPPI) data framing, IP (Internet Protocol), IEEE 802.2, and others. De Santi, et al. Standards Track [Page 3] RFC 5324 MIB for FC-SP September 2008 Physically, Fibre Channel is an interconnection of multiple communication points, called N_Ports, interconnected either by a switching network, called a Fabric, or by a point-to-point link. A Fibre Channel "Node" consists of one or more N_Ports. A Fabric may consist of multiple Interconnect Elements, some of which are Switches. An N_Port connects to the Fabric via a port on a Switch called an F_Port. When multiple FC Nodes are connected to a single port on a Switch via an "Arbitrated Loop" topology, the Switch port is called an FL_Port, and the Nodes' ports are called NL_Ports. The term Nx_Port is used to refer to either an N_Port or an NL_Port. The term Fx_Port is used to refer to either an F_Port or an FL_Port. A Switch port, which is interconnected to another Switch port via an Inter-Switch Link (ISL), is called an E_Port. A B_Port connects a bridge device with an E_Port on a Switch; a B_Port provides a subset of E_Port functionality. Many Fibre Channel components, including the Fabric, each Node, and most ports, have globally unique names. These globally unique names are typically formatted as World Wide Names (WWNs). More information on WWNs can be found in [FC-FS-2]. WWNs are expected to be persistent across agent and unit resets. Fibre Channel frames contain 24-bit address identifiers that identify the frame's source and destination ports. Each FC port has both an address identifier and a WWN. When a Fabric is in use, the FC address identifiers are dynamic and are assigned by a Switch. Each octet of a 24-bit address represents a level in an address hierarchy, with a Domain_ID being the highest level of the hierarchy. 3.2. Zoning Zones within a Fabric provide a mechanism to control frame delivery between Nx_Ports ("Hard Zoning") or to expose selected views of Name Server information ("Soft Zoning"). Communication is only possible when the communicating endpoints are members of a common zone. This technique is similar to virtual private networks in that the Fabric has the ability to group devices into Zones. Hard zoning and soft zoning are two different means of realizing this. Hard zoning is enforced in the Fabric (i.e., Switches), whereas soft zoning is enforced at the endpoints (e.g., Host Bus Adapters) by relying on the endpoints to not send traffic to an N_Port_ID not obtained from the Name Server with a few exceptions for well known Addresses (e.g., the Name Server). De Santi, et al. Standards Track [Page 4] RFC 5324 MIB for FC-SP September 2008 Administrators create Zones to increase network security, and prevent data loss or corruption, by controlling access between devices or user groups. 3.3. Virtual Fabrics The standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4]. [FC-SW-4] carries forward the earlier specification for the operation of a single Fabric in a physical infrastructure, and augments it with the definition of Virtual Fabrics and with the specification of how multiple Virtual Fabrics can operate within one or more physical infrastructures. The use of Virtual Fabrics provides for each frame to be tagged in its header to indicate which one of several Virtual Fabrics that frame is being transmitted on. All frames entering a particular "Core Switch" [FC-SW-4] (i.e., a physical Switch) on the same Virtual Fabric are processed by the same "Virtual Switch" within that Core Switch. 3.4. Security The Fibre Channel Security Protocols (FC-SP) standard [FC-SP] describes the protocols used to implement security in a Fibre Channel Fabric, including the definition of: - protocols to authenticate Fibre Channel entities, - protocols to set up session keys, - protocols to negotiate the parameters required to ensure frame- by-frame integrity and confidentiality, and - protocols to establish and distribute (security) policies across a Fibre Channel Fabric. 3.4.1. Authentication Two entities may negotiate whether authentication is required and which Authentication Protocol is to be used. Authentication can be used in Switch-to-Switch, Node-to-Switch, and Node-to-Node communication. The defined Authentication Protocols are able to perform mutual authentication with optional shared key establishment. The shared key computed at the end of an Authentication Transaction may be used to establish Security Associations. De Santi, et al. Standards Track [Page 5] RFC 5324 MIB for FC-SP September 2008 The Fabric security architecture is defined for several authentication infrastructures. Secret-based, certificate-based, and password-based authentication infrastructures are accommodated. Specific authentication protocols that directly leverage these three authentication infrastructures are defined. With a secret-based infrastructure, entities within the Fabric environment that establish a security relationship share a common secret or centralize the secret administration in an external (e.g., RADIUS [RFC2865], Diameter [RFC3588], or Terminal Access Controller Access Control System (TACACS) [RFC1492]) server. Entities may mutually authenticate with other entities by using the Diffie-Hellman Challenge Handshake Authentication Protocol (DH-CHAP) [FC-SP]. Security Associations may be set up using the session key computed at the end of the DH-CHAP transaction. With a certificate-based infrastructure, entities within the Fabric environment are certified by a trusted Certificate Authority (CA). The resulting certificates bind each entity to a public-private key pair that may be used to mutually authenticate with other certified entities via the Fibre Channel Certificate Authentication Protocol (FCAP) [FC-SP]. Security Associations may be set up by using these entity certificates and associated keys or by using the session key computed at the end of the FCAP transaction. With a password-based infrastructure, entities within the Fabric environment that establish a security relationship have knowledge of the password-based credential material of other entities. Entities may use this credential material to mutually authenticate with other entities using the Fibre Channel Password Authentication Protocol (FCPAP) [FC-SP]. Security Associations may be set up using the session key computed at the end of the FCPAP transaction. In addition to DH-CHAP, FCAP, and FCPAP, one other Authentication Protocol is defined: Internet Key Exchange Protocol version 2-AUTH (IKEv2-AUTH), which refers to the use of an SA Management Transaction of the Security Association Management Protocol (see below) to perform two functions: not only SA management but also authentication. The credentials used in an IKEv2-AUTH transaction are either strong shared secrets or certificates. 3.4.2. Security Associations A subset of the IKEv2 protocol [RFC4306] suitable for Fibre Channel is defined as the (Fibre Channel) Security Association Management protocol [RFC4595]. This protocol -- which is *not* IPsec -- provides the means to establish Security Associations (SAs) between Fibre Channel entities. Traffic Selectors are defined to specify De Santi, et al. Standards Track [Page 6] RFC 5324 MIB for FC-SP September 2008 which type of traffic has to be protected by which SA, and what the characteristics of the protection are. Two mechanisms are available to protect specific classes of traffic: - ESP_Header is used to protect FC-2 frames (see [FC-FS-2] and the conceptually similar mechanisms in [RFC4303]), and - CT_Authentication is used to protect CT_IUs (Common Transport Information Units) [FC-GS-5]. An entity protecting specific classes of traffic maintains an internal Security Association Database (SADB) that contains the currently active Security Associations and Traffic Selectors. Each active SA has a Security Association entry in the SADB. Each SA entry includes the SA's SPI (the Security Parameters Index, which is included in frames transmitted on the SA), a Sequence Number counter, and the parameters for the selected transforms (e.g., encryption algorithm, integrity algorithm, mode of operation of the algorithms, keys). Each active Traffic Selector has an entry in the SADB that indicates whether it is used for ingress traffic or for egress traffic. These Traffic Selector entries are ordered such that they are searched (when checking for a match) in the given order. Two types of Traffic Selector entries may be present: - Traffic Selector entries identifying FC-2 frames or CT_IUs to be bypassed or discarded; and - Traffic Selector entries identifying FC-2 frames or CT_IUs to be protected or verified. These entries point to the corresponding SA entry defining the parameters and the security processing to be performed. SAs are unidirectional, but they always exist as an SA pair of the same type, one in each direction. 3.4.3. Fabric Security Policies Two separate approaches to defining Policies are adopted in FC-SP, but both approaches follow the same general concept for their Policy model. One is the definition of a Policy Model for Fabric Policies that focus on Security. These Security Policies specify the membership and connectivity allowed within a Fabric, and also which IP hosts are allowed to manage a Fabric. De Santi, et al. Standards Track [Page 7] RFC 5324 MIB for FC-SP September 2008 The other approach is to define a variant of the Enhanced Zoning model defined in [FC-SW-4] and [FC-GS-5], such that the variant specifies extensions for use in a secure environment. This variant of Zoning, denoted as "FC-SP Zoning", follows the same general concepts of the Policy model for Security Policies, but keeps Zoning management and enforcement completely independent from the management and enforcement of other policies. 3.4.4. Policy Model Figure 25 of [FC-SP] depicts FC-SP's policy management model like this: ***** ************************ * * * Policy * ********************* * M * Add, * Configuration * * Policy * * A * Get, * Entity * * Enforcement * * N * Remove * * * Entity * * A * Policy * +----------------+ * * * * G * Objects * | Non-Active | * * +-------------+ * * I *<-------->* | Policy Objects |==*====*=>| Active | * * N * * +----------------+ * * | Policy | * * G * ************************ * | Objects | * * * * +-------------+ * * * Activate Policy Summary * * * E *=====================================>* +-------------+ * * N * Deactivate Policy Summary * | Policy | * * T *=====================================>* | Summary | * * I * * | Object | * * T * Get Policy Summary * +-------------+ * * Y *<-------------------------------------* * * * Get Policy Objects * * * *<-------------------------------------* * ***** ********************* Note that the arrows in the picture above are used to indicate the movement of "data", rather than the direction of "messages", e.g., for a "Get" (with no data) in one direction which invokes a "Response" (typically with data) in the reverse direction, the diagram has arrows only for the "with data" direction. De Santi, et al. Standards Track [Page 8] RFC 5324 MIB for FC-SP September 2008 3.4.5. Policy Objects The Policies to be enforced by a Fabric are specified in a set of Policy Objects. The various types of Policy Objects are: - The Policy Summary Object is a list of pointers to other Policy Objects, one pointer per each other active Policy Object. Each pointer in a Policy Summary Object is paired with a cryptographic hash of the referenced Policy Object. - The Switch Membership List Object is a Fabric-wide Policy Object that defines which Switches are allowed to be part of a Fabric. - The Node Membership List Object is a Fabric-wide Policy Object that defines which Nodes are allowed to be connected to a Fabric. - The IP Management List Object is a Fabric-wide Policy Object that describes which IP hosts are allowed to manage a Fabric. - A Switch Connectivity Object is a per-Switch Policy Object that describes the topology restrictions for a specific Switch; it specifies the other Switches or Nodes to which the particular Switch may be connected at the Node level and/or at the Port level. - Attribute Objects are Fabric-wide Policy Objects that define optional attributes to be associated with Switches or Nodes. They allow the extension of this policy model by defining new attributes as required. Note that the administratively specified name for a Fabric is contained in the Switch Membership List Object (not in the Policy Summary Object). When FC-SP is in use, each Fabric has a set of active Policy Objects: - one Policy Summary Object, - one Switch Membership List Object, - one Node Membership List Object, - one IP Management List Object, - zero or more Switch Connectivity Objects, and - zero or more Attribute Objects. De Santi, et al. Standards Track [Page 9] RFC 5324 MIB for FC-SP September 2008 The active Policy Objects specify the Policies currently being enforced. In addition, policies not currently being enforced are contained in non-active Policy Objects. To change the active Policy Objects, the non-active Policy Objects are edited as necessary and a new Policy Summary Object that includes/references the changed Policy Objects is activated. 3.4.5.1. Policy Object Names Every Policy Object has a name. In a Fabric's database of Policy Objects, a Policy Object Name is specified as a type/length/value (see section 7.2 of [FC-SP]). The possible types are: - Node_Name - Restricted Node_Name - Port_Name - Restricted Port_Name - Wildcard - Negated Wildcard - Alphanumeric Name - IPv6 Address Range - IPv4 Address Range 3.4.6. Three Kinds of Switches For a Fabric composed of n Switches and m Nodes, the potential complexity of Switch Connectivity Objects is O(n**2) to describe Switch to Switch connections, and O(n*m) for Switch to Node connections. To provide better scaling, the Switch Connectivity Objects are not Fabric-wide information, but are distributed only to where they are needed. To support this, the policy model supports three kinds of Switches in a Fabric: - Server Switches, which maintain the Fabric-wide Policy Objects, all the Switch Connectivity Objects, and a full copy of the FC- SP Zoning Database; - Autonomous Switches, which maintain the Fabric-wide Policy Objects, their own Switch Connectivity Object, and a full copy of the FC-SP Zoning Database; and De Santi, et al. Standards Track [Page 10] RFC 5324 MIB for FC-SP September 2008 - Client Switches, which maintain the Fabric-wide Policy Objects, their own Switch Connectivity Object, and a subset of the FC-SP Active Zone Set (which is the configurations of zones currently being enforced by a Fabric, see section 10.4.3.3 of [FC-SW-4]). 3.4.7. Security Policy Management Security Policy can be changed in a server session [FC-GS-5] with a Security Policy Server. All write access to a Security Policy Server occurs within a server session. While read access to a Security Policy Server may occur at any time, the consistency of the returned data is guaranteed only inside a server session. The Enhanced Commit Service [FC-SW-4] is used to perform Fabric operations as and when necessary (see table 144 of [FC-SP]). Many of these operations are named as if they were acronyms, e.g., SSB for Server Session Begin; SSE for Server Session End; SW_ILS for Switch Fabric Internal Link Services; EACA for Enhanced Acquire Change Authorization; ERCA for Enhanced Release Change Authorization; SFC for Stage Fabric Configuration. Each server session begins and ends, with a SSB request and a SSE request respectively, sent to a Security Policy Server. In the Fabric, the SSB requests a lock of the Fabric via an EACA SW_ILS, while the SSE requests a release of the lock via the ERCA SW_ILS [FC-SW-4]. Active and non-active Policy Objects are persistent in that they survive after the end of a server session. 3.4.8. FC-SP Zoning To preserve backward compatibility with existing Zoning definitions and implementations, FC-SP Zoning is defined as a variant of the Enhanced Zoning model defined in [FC-SW-4] and [FC-GS-5] that follows the general concepts of the Policy model for Security Policy Management, but keeps Zoning management and enforcement completely independent. FC-SP Zoning allows for some Switches to retain less than a complete replicated copy of the Zoning Database, as follows: - Server Switches maintain the policies data structures for all Switches in the Fabric plus a replica of the Zoning data structures; - Autonomous Switches maintain only the subset of policies data structures relevant for their operations plus a replica of the Zoning Database; and De Santi, et al. Standards Track [Page 11] RFC 5324 MIB for FC-SP September 2008 - Client Switches maintain only the subset of policies data structures and the subset of the Active Zone Set relevant for their operations. When Client Switches are deployed in a Fabric, at least one Server Switch must also be deployed in the same Fabric. A client-server protocol allows Client Switches to dynamically retrieve the Zoning information they may require from the Server Switches. A management application manages the Fabric Zoning configuration through the Fabric Zone Server, while other policies are managed through the Security Policy Server. A new Zoning Check Protocol replaces the Zone Merge Protocol [FC-SW-4], and new command codes are defined for the SFC SW_ILS to distribute the FC-SP Zoning configuration on a Fabric. The Zoning definitions are ordered to allow for the computation of a hash of the Active Zone Set and a hash of the Zone Set Database, plus other optional security data (e.g., for integrity protection of Zoning information). 4. Document Overview This document defines five MIB modules that together provide the means for monitoring the operation of, and configuring some parameters of, one or more instances of the FC-SP protocols. 4.1. Fibre Channel Management Instance A Fibre Channel management instance is defined in [RFC4044] as a separable managed instance of Fibre Channel functionality. Fibre Channel functionality may be grouped into Fibre Channel management instances in whatever way is most convenient for the implementation(s). For example, one such grouping accommodates a single SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-agent implementing a different Fibre Channel management instance. The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB [RFC4044] as the index value to uniquely identify each Fibre Channel management instance, for example, within the same SNMP context ([RFC3411] section 3.3.1). 4.2. Entity Name A central capability of FC-SP is the use of an Authentication Protocol. The purpose of each of the possible Authentication Protocols is to allow a Fibre Channel entity to be assured of the identity of each entity with which it is communicating. Examples of such entities are Fibre Channel Switches and Fibre Channel Nx_Ports. De Santi, et al. Standards Track [Page 12] RFC 5324 MIB for FC-SP September 2008 Each entity is identified by a name. The FC-MGMT-MIB [RFC4044] defines MIB objects for such names: - for entities that are Fibre Channel Switches, the definition of a Fibre Channel management instance allows multiple Switches to be managed by the same Fibre Channel management instance. In this case, each entity is a Switch and has the name given by the MIB object, fcmSwitchWWN. - for entities other than Fibre Channel Switches, a Fibre Channel management instance can manage only one entity, and the name of the entity is given by the MIB object, fcmInstanceWwn. 4.3. Fabric Index With multiple Fabrics, each Fabric has its own instances of the Fabric-related management instrumentation. Thus, these MIB modules define all Fabric-related information in tables that are INDEX-ed by an arbitrary integer, named a "Fabric Index". The syntax of a Fabric Index is T11FabricIndex, imported from T11-TC-MIB [RFC4439]. When a device is connected to a single physical Fabric, without use of any virtual Fabrics, the value of this Fabric Index will always be 1. In an environment of multiple virtual and/or physical Fabrics, this index provides a means to distinguish one Fabric from another. 4.4. Interface Index Several of the MIB modules defined in this document use the InterfaceIndexOrZero syntax in order to allow information to be specified/instantiated on a per-port/interface basis, e.g., for: statistics, Traffic Selectors, Security Associations, etc. This allows the same object to be used either when there is a separate row for each of multiple ports/interfaces, or when multiple interfaces are represented by a single row. The use of a zero value supports the simpler cases of: a) when there is only one port/interface, b) where the implementation chooses to aggregate the information for multiple ports/interfaces. The minimum (for compliance) requirement is to implement any one of the above cases. When a Fabric Index and an object with the InterfaceIndexOrZero syntax are used together in a single INDEX clause, the InterfaceIndexOrZero object is listed before the Fabric Index in order to simplify management queries that retrieve information concerning multiple Fabrics connected to the same port/interface. De Santi, et al. Standards Track [Page 13] RFC 5324 MIB for FC-SP September 2008 4.5. Syntax for Policy Object Names T11FcSpPolicyNameType and T11FcSpPolicyName are two Textual Conventions defined in this document (in the T11-FC-SP-TC-MIB module) to represent the types and values of Policy Object Names (see section 3.4.5.1 above). However, two of the nine possible types are IPv4 Address Range and IPv6 Address Range. It is standard practice in MIB modules to represent all IP addresses using the standard Textual Conventions defined in [RFC4001] for IP addresses: specifically, InetAddressType and InetAddress. This document adheres to such standard practice to the following extent: - for MIB objects representing a Policy Object Name that can *only* be an IPv4 Address Range or an IPv6 Address Range, then those MIB objects are defined as a 3-tuple: (InetAddressType, InetAddress, InetAddress), in which the first address is the low end of the range, the second address is the high end of the range, and both addresses are of the type given by InetAddressType. - for MIB objects representing a Policy Object Name that is (possibly) of a different type, i.e., it is not (necessarily) an IPv4 or IPv6 Address Range, then those MIB objects are defined as a 2-tuple: (T11FcSpPolicyNameType, T11FcSpPolicyName), in which the first object represents the type of Policy Object Name and the second object represents the value of the Policy Object Name. For MIB objects defined in this manner, if and when they represent a range of IP addresses: a) the value of T11FcSpPolicyNameType differentiates between an IPv4 Address Range and an IPv6 Address Range; and b) the value of T11FcSpPolicyName is one string containing the concatenation of the two addresses that are the low and high addresses of the range. This is the same format as used within FC-SP Policy Objects [FC-SP]. 4.6. Certificates, CAs, and CRLs In order to authenticate with the FCAP protocol, each entity, identified by a unique Name, is provided with: a digital certificate associated with that Name, the private/public key pair that corresponds to the certificate, and with the Root Certificate (the certificate of the signing Certification Authority). To authenticate another entity, an entity is required to be provided with the certificate of the associated Certification Authority. FCAP requires entities to support at least four Root Certificates against which received corresponding certificates can be validated. Support for certificate chains and verification of certificate chains De Santi, et al. Standards Track [Page 14] RFC 5324 MIB for FC-SP September 2008 containing more than one certificate is optional. Entities need to be able to access a Certificate Revocation List (CRL) for each configured Root Certificate, if one is available from the CA. Certificates on the CRL are considered invalid. The management of certificates, Certification Authorities, and Certificate Revocation Lists is the same in Fibre Channel networks as it is in other networks. Therefore, this document does not define any MIB objects for such management. 4.7. Traffic Selectors When Traffic Selectors are compared against an ingress or egress frame in order to determine the security processing to be applied to that frame, there are circumstances in which multiple Traffic Selectors, specifying different actions, can match with the frame. Specifically, when matching against an egress frame to decide which active Security Association to transmit on, or, against an ingress frame unprotected by FC-SP, i.e., without an SPI value in it, to decide which action ('drop' or 'bypass') to apply. For these cases, the MIB includes a unique precedence value for each Traffic Selector such that the one with the numerically lowest precedence value is determined to be the one that matches. In contrast, ingress frames on active Security Associations (i.e., protected by FC-SP) are compared against the set of traffic selectors negotiated when the Security Association was set up and identified by the SPI value contained in the frame; the action taken depends on whether any Traffic Selector matches, but not on which one. This difference between ingress and egress Traffic Selectors on active Security Associations is reflected in having separate MIB tables defined for them: the table for Traffic Selectors on egress SAs, t11FcSpSaTSelNegOutTable, has a precedence value in its INDEX clause; whereas the table for Traffic Selectors on ingress SAs, t11FcSpSaTSelNegInTable, has an arbitrary integer value in its INDEX clause. For 'drop' and 'bypass' Traffic Selectors, one table, t11FcSpSaTSelDrByTable, having a precedence value in its INDEX clause, is sufficient for both ingress and egress traffic. De Santi, et al. Standards Track [Page 15] RFC 5324 MIB for FC-SP September 2008 4.8. The MIB Modules 4.8.1. The T11-FC-SP-TC-MIB Module This MIB module defines Textual Conventions that are being, or have the potential to be, used in more than one MIB module. The module also defines Object Identifiers to identify the Cryptographic Algorithms listed in [FC-SP] so that they can be used as the value of various MIB objects that specify the algorithms being/to be used by an FC-SP implementation. 4.8.2. The T11-FC-SP-AUTHENTICATION-MIB Module This MIB module specifies the management information required to manage FC-SP Authentication Protocols. It defines three tables: - t11FcSpAuEntityTable -- a table of Fibre Channel entities that can be authenticated using FC-SP's Authentication Protocols, including the names, capabilities, and basic configuration parameters of the entities. - t11FcSpAuIfStatTable -- this table has two purposes: to be a list of the mappings of a FC-SP Authentication entity onto an interface and to contain Authentication Protocol per-interface statistics. - t11FcSpAuRejectTable -- a table of FC-SP Authentication Protocol transactions that were recently rejected. It also defines two notifications: one for sending a reject in response to an AUTH message and another for receiving a reject in response to an AUTH message. 4.8.3. The T11-FC-SP-ZONING-MIB Module This MIB module specifies the extensions to the T11-FC-ZONE-SERVER- MIB module [RFC4936] for the management of FC-SP Zoning Servers. Specifically, it augments three tables defined in T11-FC-ZONE-SERVER- MIB: - t11FcSpZsServerTable -- to this table, it adds FC-SP Zoning information defined for Zone Servers. - t11ZsStatsTable -- to this table, it adds FC-SP Zoning statistics for Zone Servers. - t11ZsNotifyControlTable -- to this table, it adds control information for FC-SP Zoning notifications. De Santi, et al. Standards Track [Page 16] RFC 5324 MIB for FC-SP September 2008 It also defines two FC-SP Zoning notifications: one for success and one for failure in the joining of two Fabrics. 4.8.4. The T11-FC-SP-POLICY-MIB Module This MIB module specifies management information that is used to manage FC-SP policies. The MIB module has five parts: - Active Policy Objects - read-only MIB objects representing the set of active Policy Objects for each Fabric; - Activate/Deactivate Operations - read-write MIB objects for invoking operations, either 1) to activate policies that are specified as a set of non-active Policy Objects, or 2) to deactivate the currently active policies; also included are objects giving the status of invoked operations; - Non-Active Policy Objects - read-create MIB objects to create and modify non-active Policy Objects; - Statistics for FC-SP Security Policy Servers; - The definition and control of notifications for the success or failure of the activation or deactivation of FC-SP policies. 4.8.5. The T11-FC-SP-SA-MIB Module This MIB module specifies the management information required to manage Security Associations established via FC-SP. All of the tables in this MIB module are INDEX-ed by t11FcSpSaIfIndex, with syntax InterfaceIndexOrZero, which is either non-zero for a specific interface or zero for all (of the management instance's) interfaces to the particular Fabric. The MIB module consists of six parts: - a per-Fabric table, t11FcSpSaIfTable, of capabilities, parameters, status information, and counters; the counters include non-transient aggregates of per-SA transient counters; - three tables, t11FcSpSaPropTable, t11FcSpSaTSelPropTable, and t11FcSpSaTransTable, specifying the proposals for an FC-SP entity acting as an SA_Initiator to present to the SA_Responder during the negotiation of Security Associations. The same information is also used by an FC-SP entity acting as an SA_Responder to decide what to accept during the negotiation of De Santi, et al. Standards Track [Page 17] RFC 5324 MIB for FC-SP September 2008 Security Associations. One of these tables, t11FcSpSaTransTable, is used not only for information about security transforms to propose and to accept, but also as agreed upon during the negotiation of Security Associations; - a table, t11FcSpSaTSelDrByTable, of Traffic Selectors having the security action of 'drop' or 'bypass' to be applied either to ingress traffic, which is unprotected by FC-SP, or to all egress traffic; - four tables, t11FcSpSaPairTable, t11FcSpSaTSelNegInTable, t11FcSpSaTSelNegOutTable, and t11FcSpSaTSelSpiTable, containing information about active bidirectional pairs of Security Associations; in particular, t11FcSpSaPairTable has one row per active bidirectional SA pair, t11FcSpSaTSelNegInTable and t11FcSpSaTSelNegOutTable contain information on the Traffic Selectors negotiated on the SAs, and the t11FcSpSaTSelSpiTable is an alternate lookup table such that the Traffic Selector(s) in use on a particular Security Association can be quickly determined based on its (ingress) SPI value; - a table, t11FcSpSaControlTable, of control and other information concerning the generation of notifications for events related to FC-SP Security Associations; - one notification, t11FcSpSaNotifyAuthFailure, generated on the occurrence of an Authentication failure for a received FC-2 or CT_IU frame. 4.9. Rate Control for Notifications All but one of the notifications defined in the five MIB modules in this document are notifications that are generated based on events occurring in the "control plane", e.g., notifications that are generated at the frequency of operator-initiated activities. The one exception is t11FcSpSaNotifyAuthFailure, which is generated based on an event occurring in the "data plane", and could (in a worst case scenario) occur for every received ingress frame. Therefore, a method of rate controlling the generation of notifications is needed for t11FcSpSaNotifyAuthFailure, but not for any of the other notifications. For t11FcSpSaNotifyAuthFailure, rate control is achieved by specifying that a) after the first occurrence of an Authentication failure on any particular Security Association, the SNMP notifications for second and subsequent failures are suppressed for the duration of a time window and b) that even the notification for the first occurrence is suppressed after it is sent in the same time De Santi, et al. Standards Track [Page 18] RFC 5324 MIB for FC-SP September 2008 window for a configured (in t11FcSpSaControlMaxNotifs) number of Security Associations within a Fabric. Note that while these suppressions prevent the network from being flooded with notifications, the Authentication Failures themselves must still be detected and counted. The length of the time window is given by t11FcSpSaControlWindow, a read-write object in the t11FcSpSaControlTable. If and when the time since the last generation of the notification is less than the value of sysUpTime (e.g., if one or more notifications have occurred since the last re-initialization of the management system), then t11FcSpSaControlElapsed and t11FcSpSaControlSuppressed contain the elapsed time since the last notification and the number of notifications suppressed in the window after sending the last one, respectively. Otherwise, t11FcSpSaControlElapsed contains the value of sysUpTime and t11FcSpSaControlSuppressed has the value zero. 5. Relationship to Other MIB Modules The first standardized MIB module for Fibre Channel [RFC2837] was focused on Fibre Channel Switches. It was obsoleted by the more generic Fibre Channel Management MIB [RFC4044], which defines basic information for Fibre Channel Nodes and Switches, including extensions to the standard IF-MIB [RFC2863] for Fibre Channel interfaces. Several other MIB modules have since been defined to extend [RFC4044] for various specific Fibre Channel functionality, (e.g., [RFC4438], [RFC4439], [RFC4625], [RFC4626], [RFC4747], [RFC4936], [RFC4935], and [RFC4983]). The MIB modules defined in this memo further extend [RFC4044] to cover the operation of Fibre Channel Security Protocols, as specified in [FC-SP]. One part of the FC-SP specification is "FC-SP Zoning", which is an extension/variant of the Fibre Channel Zoning defined in [FC-GS-5]. Management information for the latter is defined in the T11-FC-ZONE- SERVER-MIB module [RFC4936]. Consequently, the T11-FC-SP-ZONING-MIB module defined in this document defines the extensions to the T11-FC- ZONE-SERVER-MIB module that are needed to manage FC-SP Zoning. The MIB modules in this memo import some common Textual Conventions from T11-TC-MIB, defined in [RFC4439], and from INET-ADDRESS-MIB, defined in [RFC4001]. If the RADIUS protocol is used for access to an external server, information about RADIUS Servers is likely to be available from the RADIUS-AUTH-CLIENT-MIB [RFC4668]. De Santi, et al. Standards Track [Page 19] RFC 5324 MIB for FC-SP September 2008 6. MIB Module Definitions 6.1. The T11-FC-SP-TC-MIB Module T11-FC-SP-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] t11FcTcMIB MODULE-IDENTITY LAST-UPDATED "200808200000Z" ORGANIZATION "This MIB module was developed through the coordinated effort of two organizations: T11 began the development and the IETF (in the IMSS Working Group) finished it." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: kzm@cisco.com" DESCRIPTION "This MIB module defines Textual Conventions for use in the multiple MIB modules, which together define the instrumentation for an implementation of the Fibre Channel Security Protocols (FC-SP) specification. This MIB module also defines Object Identities (for use as possible values of MIB objects with syntax AutonomousType), including OIDs for the Cryptographic Algorithms defined in FC-SP. Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5324; see the RFC itself for full legal notices." REVISION "200808200000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 5324." ::= { mib-2 175 } De Santi, et al. Standards Track [Page 20] RFC 5324 MIB for FC-SP September 2008 t11FcSpIdentities OBJECT IDENTIFIER ::= { t11FcTcMIB 1 } t11FcSpAlgorithms OBJECT IDENTIFIER ::= { t11FcSpIdentities 1 } -- -- Textual Conventions -- T11FcSpPolicyHashFormat ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a cryptographic hash function used to create a hash value that summarizes an FC-SP Policy Object. Each definition of an object with this TC as its syntax must be accompanied by a corresponding definition of an object with T11FcSpPolicyHashValue as its syntax, and containing the hash value. The first two cryptographic hash functions are: Hash Type Hash Tag Hash Length (Bytes) SHA-1 '00000001'h 20 SHA-256 '00000002'h 32 " REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.3.1 and table 106. - FIPS PUB 180-2." SYNTAX OCTET STRING (SIZE (4)) T11FcSpPolicyHashValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the value of the cryptographic hash function of an FC-SP Policy Object. Each definition of an object with this TC as its syntax must be accompanied by a corresponding definition of an object with T11FcSpPolicyHashFormat as its syntax. The corresponding object identifies the cryptographic hash function used to create the hash value." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.3.1 and table 106." SYNTAX OCTET STRING (SIZE (0..64)) De Santi, et al. Standards Track [Page 21] RFC 5324 MIB for FC-SP September 2008 T11FcSpHashCalculationStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "When some kind of 'database' is defined in a set of read-write MIB objects, it is common that multiple changes in the data need to be made at the same time. So, if hash values are maintained for that data, those hash values are only correct if and when they are re-calculated after every change. In such circumstances, the use of an object with this syntax allows the re-calculation of the hash values to be deferred until all changes have been made, and therefore the calculation need only be done once after all changes, rather than repeatedly/after each individual change. The definition of an object defined using this TC is required to specify which one or more instances of which MIB objects contain the hash values operated upon (or whose status is given) by the value of this TC. When read, the value of an object with this syntax is either: correct -- the identified MIB object instance(s) contain the correct hash values; or stale -- the identified MIB object instance(s) contain stale (possibly incorrect) values. Writing a value of 'calculate' is a request to re-calculate and update the values of the corresponding instances of the identified MIB objects. Writing a value of 'correct' or 'stale' to this object is an error (e.g., 'wrongValue')." SYNTAX INTEGER { calculate(1), correct(2), stale(3) } T11FcSpAuthRejectReasonCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A reason code contained in an AUTH_Reject message, or in an SW_RJT (rejecting an AUTH_ILS), or in an LS_RJT (rejecting an AUTH-ELS)." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 17, 48, 52." SYNTAX INTEGER { De Santi, et al. Standards Track [Page 22] RFC 5324 MIB for FC-SP September 2008 authFailure(1), logicalError(2), logicalBusy(3), authILSNotSupported(4), authELSNotSupported(5), notLoggedIn(6) } T11FcSpAuthRejReasonCodeExp ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A reason code explanation contained in an AUTH_Reject message, or in an SW_RJT (rejecting an AUTH_ILS), or in an LS_RJT (rejecting an AUTH-ELS)." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Tables 18, 48, 52." SYNTAX INTEGER { authMechanismNotUsable(1), dhGroupNotUsable(2), hashFunctionNotUsable(3), authTransactionAlreadyStarted(4), authenticationFailed(5), incorrectPayload(6), incorrectAuthProtocolMessage(7), restartAuthProtocol(8), authConcatNotSupported(9), unsupportedProtocolVersion(10), logicalBusy(11), authILSNotSupported(12), authELSNotSupported(13), notLoggedIn(14) } T11FcSpHashFunctions ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of zero, one, or more hash functions defined for use in FC-SP." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 14." SYNTAX BITS { md5(0), sha1(1) } De Santi, et al. Standards Track [Page 23] RFC 5324 MIB for FC-SP September 2008 T11FcSpSignFunctions ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of zero, one, or more signature functions defined for signing certificates for use with FCAP in FC-SP." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, tables 38 & 39." SYNTAX BITS { rsaSha1(0) } T11FcSpDhGroups ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of zero, one, or more DH Groups defined for use in FC-SP." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 15." SYNTAX BITS { null(0), group1024(1), group1280(2), group1536(3), group2048(4), group3072(5), group4096(6), group6144(7), group8192(8) } T11FcSpPolicyObjectType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that identifies the type of an FC-SP Policy Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 102." SYNTAX INTEGER { summary(1), switchMemberList(2), nodeMemberList(3), switchConnectivity(4), De Santi, et al. Standards Track [Page 24] RFC 5324 MIB for FC-SP September 2008 ipMgmtList(5), attribute(6) } T11FcSpPolicyNameType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The format and usage of a companion object having T11FcSpPolicyName as its syntax. Six of the values indicate the same format, i.e., they differ only in semantics. That common format is a Fibre Channel 'Name_Identifier', i.e., the same syntax as 'FcNameIdOrZero (SIZE(8))'. These six are three pairs of one restricted and one unrestricted. Each usage of this syntax must specify what the meaning of 'restricted' is for that usage and how the characteristics and behavior of restricted names differ from unrestricted names. The six are: 'nodeName' - a Node_Name, which is the Name_Identifier associated with a Fibre Channel Node. 'restrictedNodeName' - a Restricted Node_Name. 'portName' - the Name_Identifier associated with a Fibre Channel Port. 'restrictedPortName' - a Restricted Port_Name. 'wildcard' - a Wildcard value that is used to identify 'all others' (typically, all other members of a Policy Object, not all other Policy Objects). 'restrictedWildcard' - a Restricted Wildcard value. Other possible values are: 'alphaNumericName' - the value begins with an ASCII letter (upper or lower case) followed by (0 ... 63) characters from the set: lower case letters, upper case letters, digits, and the four symbols: dollar-sign ($), De Santi, et al. Standards Track [Page 25] RFC 5324 MIB for FC-SP September 2008 dash (-), caret (^), and underscore (_). 'ipv6AddressRange' - two IPv6 addresses in network byte order, the numerically smallest first and the numerically largest second; total length is 32 bytes. 'ipv4AddressRange' - two IPv4 addresses in network byte order, the numerically smallest first and the numerically largest second; total length is 8 bytes." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 103." SYNTAX INTEGER { nodeName(1), restrictedNodeName(2), portName(3), restrictedPortName(4), wildcard(5), restrictedWildcard(6), alphaNumericName(7), ipv6AddressRange(8), ipv4AddressRange(9) } T11FcSpPolicyName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A syntax used, when defining Policy Objects, for the name of something. An object that uses this syntax always identifies a companion object with syntax T11FcSpPolicyNameType such that the companion object specifies the format and usage of the object with this syntax. When the companion object has the value 'wildcard' or 'restrictedWildcard', the value of the T11FcSpPolicyName object is: '0000000000000000'h." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 103." SYNTAX OCTET STRING (SIZE (1..64)) T11FcSpAlphaNumName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 26] RFC 5324 MIB for FC-SP September 2008 "A syntax used when defining Policy Objects for the name of something, where the name is always in the format specified by: T11FcSpPolicyNameType = 'alphaNumericName' " REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 103." SYNTAX OCTET STRING (SIZE (1..64)) T11FcSpAlphaNumNameOrAbsent ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An extension of the T11FcSpAlphaNumName TC with one additional possible value: the zero-length string to indicate the absence of a name." SYNTAX OCTET STRING (SIZE (0..64)) T11FcSaDirection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The direction of frame transmission on a Security Association. Note that Security Associations are unidirectional, but they always exist as part of an SA pair of the same type in opposite directions." SYNTAX INTEGER { ingress(1), egress(2) } T11FcSpiIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SPI (Security Parameter Index) value is carried in the SPI field of a frame protected by the ESP_Header. An SPI is also carried in the SAID field of a Common Transport Information Unit (CT_IU) protected by CT_Authentication. An SPI value identifies the Security Association on which the frame is being transmitted." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 4.7.2 and 4.7.3." SYNTAX Unsigned32 (0..4294967295) -- the default range!! T11FcSpPrecedence ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 27] RFC 5324 MIB for FC-SP September 2008 "The precedence of a Traffic Selector. If a frame matches with two or more Traffic Selectors, then the match that takes precedence is the one with the Traffic Selector having the numerically smallest precedence value. Note that precedence values are not necessarily contiguous." SYNTAX Unsigned32 (0..4294967295) -- the default range!! T11FcRoutingControl ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "A value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value." REFERENCE "- Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12." SYNTAX OCTET STRING (SIZE(1)) T11FcSpType ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x" STATUS current DESCRIPTION "A value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link De Santi, et al. Standards Track [Page 28] RFC 5324 MIB for FC-SP September 2008 layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octet " REFERENCE "- Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5." SYNTAX OCTET STRING (SIZE(2)) T11FcSpTransforms ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of the standardized transforms that are defined by FC-SP for use with ESP_Header, CT_Authentication, and/or IKEv2 Support." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Appendix A.3.1, tables A.23, A.24, A.25, A.26." SYNTAX BITS { encrNull(0), encrAesCbc(1), encrAesCtr(2), encrAesGcm(3), encr3Des(4), prfHmacMd5(5), prfHmacSha1(6), prfAesCbc(7), authHmacMd5L96(8), authHmacSha1L96(9), authHmacMd5L128(10), authHmacSha1L160(11), encrNullAuthAesGmac(12), dhGroups1024bit(13), dhGroups2048bit(14) } De Santi, et al. Standards Track [Page 29] RFC 5324 MIB for FC-SP September 2008 T11FcSpSecurityProtocolId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A Security Protocol identifier to identify the protocol by which traffic is to be protected, e.g., ESP_Header or CT_Authentication." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.2 and table 67." SYNTAX INTEGER { espHeader(1), ctAuth(2) } T11FcSpLifetimeLeft ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC is used for one object of an associated pair of objects. The object with this syntax specifies a remaining lifetime of something, e.g., of an SA, where the lifetime is given in the units specified by the other object of the pair which has T11FcSpLifetimeLeftUnits as its syntax." SYNTAX Unsigned32 T11FcSpLifetimeLeftUnits ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object, defined using T11FcSpLifetimeLeft TC as its syntax, is required to be one of an associated pair of objects such that the other object of the pair is defined with this T11FcSpLifetimeLeftUnits TC as its syntax and with its value specifying the units of the remaining lifetime given by the value of the T11FcSpLifetimeLeft object." SYNTAX INTEGER { seconds(1), -- seconds kiloBytes(2), -- 10^^3 bytes megaBytes(3), -- 10^^6 bytes gigaBytes(4), -- 10^^9 bytes teraBytes(5), -- 10^^12 bytes petaBytes(6), -- 10^^15 bytes exaBytes(7), -- 10^^18 bytes zettaBytes(8), -- 10^^21 bytes yottaBytes(9) -- 10^^24 bytes } -- -- Object Identities to identify the Cryptographic Algorithms -- listed in FC-SP. De Santi, et al. Standards Track [Page 30] RFC 5324 MIB for FC-SP September 2008 -- t11FcSpEncryptAlgorithms OBJECT IDENTIFIER ::= { t11FcSpAlgorithms 1 } t11FcSpEncrNull OBJECT-IDENTITY STATUS current DESCRIPTION "The ENCR_NULL algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 70." ::= { t11FcSpEncryptAlgorithms 1 } t11FcSpEncrAesCbc OBJECT-IDENTITY STATUS current DESCRIPTION "The ENCR_AES_CBC algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 70." ::= { t11FcSpEncryptAlgorithms 2 } t11FcSpEncrAesCtr OBJECT-IDENTITY STATUS current DESCRIPTION "The ENCR_AES_CTR algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 70." ::= { t11FcSpEncryptAlgorithms 3 } t11FcSpEncrAesGcm OBJECT-IDENTITY STATUS current DESCRIPTION "The ENCR_AES_GCM algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 70." ::= { t11FcSpEncryptAlgorithms 4 } t11FcSpEncr3Des OBJECT-IDENTITY STATUS current DESCRIPTION "The ENCR_3DES algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 70." De Santi, et al. Standards Track [Page 31] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpEncryptAlgorithms 5 } t11FcSpAuthAlgorithms OBJECT IDENTIFIER ::= { t11FcSpAlgorithms 2 } t11FcSpAuthNull OBJECT-IDENTITY STATUS current DESCRIPTION "The AUTH_NONE algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 72." ::= { t11FcSpAuthAlgorithms 1 } t11FcSpAuthHmacMd5L96 OBJECT-IDENTITY STATUS current DESCRIPTION "The AUTH_HMAC_MD5_96 algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 72." ::= { t11FcSpAuthAlgorithms 2 } t11FcSpAuthHmacSha1L96 OBJECT-IDENTITY STATUS current DESCRIPTION "The AUTH_HMAC_SHA1_96 algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 72." ::= { t11FcSpAuthAlgorithms 3 } t11FcSpAuthHmacMd5L128 OBJECT-IDENTITY STATUS current DESCRIPTION "The AUTH_HMAC_MD5_128 algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 72." ::= { t11FcSpAuthAlgorithms 4 } t11FcSpAuthHmacSha1L160 OBJECT-IDENTITY STATUS current DESCRIPTION "The AUTH_HMAC_SHA1_160 algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 72." De Santi, et al. Standards Track [Page 32] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpAuthAlgorithms 5 } t11FcSpEncrNullAuthAesGmac OBJECT-IDENTITY STATUS current DESCRIPTION "The ENCR_NULL_AUTH_AES_GMAC algorithm." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 70." ::= { t11FcSpEncryptAlgorithms 6 } END 6.2. The T11-FC-SP-AUTHENTICATION-MIB Module --******************************************************************** -- FC-SP Authentication Protocols -- T11-FC-SP-AUTHENTICATION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, NOTIFICATION-TYPE, mib-2, Counter32, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] StorageType, AutonomousType, TruthValue, TimeStamp FROM SNMPv2-TC -- [RFC2579] InterfaceIndex FROM IF-MIB -- [RFC2863] fcmInstanceIndex, FcNameIdOrZero FROM FC-MGMT-MIB -- [RFC4044] t11FamLocalSwitchWwn FROM T11-FC-FABRIC-ADDR-MGR-MIB -- [RFC4439] T11FabricIndex FROM T11-TC-MIB -- [RFC4439] T11FcSpDhGroups, T11FcSpHashFunctions, T11FcSpSignFunctions, T11FcSpLifetimeLeft, T11FcSpLifetimeLeftUnits, T11FcSpAuthRejectReasonCode, T11FcSpAuthRejReasonCodeExp FROM T11-FC-SP-TC-MIB; t11FcSpAuthenticationMIB MODULE-IDENTITY LAST-UPDATED "200808200000Z" ORGANIZATION "This MIB module was developed through the De Santi, et al. Standards Track [Page 33] RFC 5324 MIB for FC-SP September 2008 coordinated effort of two organizations: T11 began the development and the IETF (in the IMSS Working Group) finished it." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: kzm@cisco.com" DESCRIPTION "This MIB module specifies the management information required to manage the Authentication Protocols defined by Fibre Channel's FC-SP specification. This MIB module defines three tables: - t11FcSpAuEntityTable is a table of Fibre Channel entities that can be authenticated using FC-SP's Authentication Protocols. - t11FcSpAuIfStatTable is a table with one row for each mapping of an Authentication entity onto an interface, containing statistics information. - t11FcSpAuRejectTable is a table of volatile information about FC-SP Authentication Protocol transactions that were most recently rejected. Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5324; see the RFC itself for full legal notices." REVISION "200808200000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 5324." ::= { mib-2 176 } t11FcSpAuMIBNotifications OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 0 } t11FcSpAuMIBObjects OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 1 } t11FcSpAuMIBConformance OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 2 } De Santi, et al. Standards Track [Page 34] RFC 5324 MIB for FC-SP September 2008 t11FcSpAuMIBIdentities OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 3 } -- -- OIDs defined for use as values of t11FcSpAuServerProtocol -- t11FcSpAuServerProtocolRadius OBJECT-IDENTITY STATUS current DESCRIPTION "This OID identifies RADIUS as the protocol used to communicate with an External Server as part of the process by which identities are verified. In this case, information about the RADIUS Servers is likely to be provided in radiusAuthServerExtTable defined in the RADIUS-AUTH-CLIENT-MIB." REFERENCE "radiusAuthServerExtTable in 'RADIUS Authentication Client MIB', RFC 4668, August 2006." ::= { t11FcSpAuMIBIdentities 1 } t11FcSpAuServerProtocolDiameter OBJECT-IDENTITY STATUS current DESCRIPTION "This OID identifies Diameter as the protocol used to communicate with an External Server as part of the process by which identities are verified." REFERENCE "RFC 3588, September 2003." ::= { t11FcSpAuMIBIdentities 2 } t11FcSpAuServerProtocolTacacs OBJECT-IDENTITY STATUS current DESCRIPTION "This OID identifies TACACS as the protocol used to communicate with an External Server as part of the process by which identities are verified." REFERENCE "RFC 1492, July 1993." ::= { t11FcSpAuMIBIdentities 3 } -- -- Configuration for the Authentication Protocols -- t11FcSpAuEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpAuEntityEntry MAX-ACCESS not-accessible De Santi, et al. Standards Track [Page 35] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "A table of Fibre Channel entities that can be authenticated using FC-SP's Authentication Protocols. The purpose of an FC-SP Authentication Protocol is to verify that a claimed name is associated with the claiming entity. The Authentication Protocols can be used to authenticate Nx_Ports, B_Ports, or Switches." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 3.2.25." ::= { t11FcSpAuMIBObjects 1 } t11FcSpAuEntityEntry OBJECT-TYPE SYNTAX T11FcSpAuEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the configuration and capabilities of an FC-SP entity (which is managed within the Fibre Channel management instance identified by fcmInstanceIndex) on a particular Fabric with respect to FC-SP's Authentication Protocols." INDEX { fcmInstanceIndex, t11FcSpAuEntityName, t11FcSpAuFabricIndex } ::= { t11FcSpAuEntityTable 1 } T11FcSpAuEntityEntry ::= SEQUENCE { t11FcSpAuEntityName FcNameIdOrZero, t11FcSpAuFabricIndex T11FabricIndex, t11FcSpAuServerProtocol AutonomousType, -- Config parameters t11FcSpAuStorageType StorageType, t11FcSpAuSendRejNotifyEnable TruthValue, t11FcSpAuRcvRejNotifyEnable TruthValue, t11FcSpAuDefaultLifetime T11FcSpLifetimeLeft, t11FcSpAuDefaultLifetimeUnits T11FcSpLifetimeLeftUnits, t11FcSpAuRejectMaxRows Unsigned32, -- Capabilities t11FcSpAuDhChapHashFunctions T11FcSpHashFunctions, t11FcSpAuDhChapDhGroups T11FcSpDhGroups, t11FcSpAuFcapHashFunctions T11FcSpHashFunctions, t11FcSpAuFcapCertsSignFunctions T11FcSpSignFunctions, t11FcSpAuFcapDhGroups T11FcSpDhGroups, t11FcSpAuFcpapHashFunctions T11FcSpHashFunctions, t11FcSpAuFcpapDhGroups T11FcSpDhGroups De Santi, et al. Standards Track [Page 36] RFC 5324 MIB for FC-SP September 2008 } t11FcSpAuEntityName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name used to identify the FC-SP entity. For entities that are Fibre Channel Switches, this value corresponds to the Switch's value of fcmSwitchWWN. For entities other than Fibre Channel Switches, this value corresponds to the value of fcmInstanceWwn for the corresponding Fibre Channel management instance." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.3.3. - fcmInstanceWwn & fcmSwitchWWN, 'Fibre Channel Management MIB', RFC 4044, May 2005." ::= { t11FcSpAuEntityEntry 1 } t11FcSpAuFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Fabric to which the entity is attached." ::= { t11FcSpAuEntityEntry 2 } t11FcSpAuServerProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol, if any, used by the entity to communicate with a third party (i.e., an External Server) as part of the process by which it verifies DH-CHAP responses. For example, if the entity is using an external RADIUS server to verify DH-CHAP responses, then this object will have the value t11FcSpAuServerProtocolRadius. The value, zeroDotZero, is used to indicate that no protocol is being used to communicate with a third party to verify DH-CHAP responses. When no protocol is being used, or if the third party is De Santi, et al. Standards Track [Page 37] RFC 5324 MIB for FC-SP September 2008 unreachable via the specified protocol, then locally configured information (if any) may be used instead." ::= { t11FcSpAuEntityEntry 3 } t11FcSpAuStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the memory realization of configuration information related to an FC-SP Entity on a particular Fabric: specifically, for MIB objects in the row containing this object. Even if an instance of this object has the value 'permanent(4)', none of the information in the corresponding row of this table needs to be writable." ::= { t11FcSpAuEntityEntry 4 } t11FcSpAuSendRejNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "An indication of whether or not the entity should issue t11FcSpAuRejectSentNotify notifications when sending AUTH_Reject/SW_RJT/LS_RJT to reject an AUTH message. If the value of the object is 'true', then this type of notification is generated. If the value is 'false', this type of notification is not generated." DEFVAL { false } ::= { t11FcSpAuEntityEntry 5 } t11FcSpAuRcvRejNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "An indication of whether or not the entity should issue t11FcSpAuRejectReceivedNotify notifications on the receipt of AUTH_Reject/SW_RJT/LS_RJT messages. If the value of the object is 'true', then this type of notification is generated. If the value is 'false', this type of notification is not generated." DEFVAL { false } ::= { t11FcSpAuEntityEntry 6 } De Santi, et al. Standards Track [Page 38] RFC 5324 MIB for FC-SP September 2008 t11FcSpAuDefaultLifetime OBJECT-TYPE SYNTAX T11FcSpLifetimeLeft MAX-ACCESS read-write STATUS current DESCRIPTION "When the value of this object is non-zero, it specifies the default value of a lifetime, specified in units given by the corresponding instance of t11FcSpAuDefaultLifetimeUnits. This default lifetime is to be used for any Security Association that has no explicitly specified value for its lifetime. An SA's lifetime is either the time interval or the number of passed bytes, after which the SA has to be terminated and (if necessary) replaced with a new SA. If this object is zero, then there is no default value for lifetime." DEFVAL { 28800 } -- 8 hours (in units of seconds) ::= { t11FcSpAuEntityEntry 7 } t11FcSpAuDefaultLifetimeUnits OBJECT-TYPE SYNTAX T11FcSpLifetimeLeftUnits MAX-ACCESS read-write STATUS current DESCRIPTION "The units in which the value of the corresponding instance of t11FcSpAuDefaultLifetime specifies a default lifetime for a Security Association that has no explicitly-specified value for its lifetime." DEFVAL { seconds } ::= { t11FcSpAuEntityEntry 8 } t11FcSpAuRejectMaxRows OBJECT-TYPE SYNTAX Unsigned32 (0..1000) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of rows in the t11FcSpAuRejectTable for this entity on this Fabric. If and when an AUTH message is rejected, and the t11FcSpAuRejectTable already contains this maximum number of rows for the specific entity and Fabric, the row containing the oldest information is discarded and replaced by a row containing information about the new rejection. There will be less than this maximum number of rows in the t11FcSpAuRejectTable in exceptional circumstances, De Santi, et al. Standards Track [Page 39] RFC 5324 MIB for FC-SP September 2008 e.g., after an agent restart. In an implementation that does not support the t11FcSpAuRejectTable, this object will always be zero." ::= { t11FcSpAuEntityEntry 9 } t11FcSpAuDhChapHashFunctions OBJECT-TYPE SYNTAX T11FcSpHashFunctions MAX-ACCESS read-only STATUS current DESCRIPTION "The hash functions that the entity supports when using the DH-CHAP algorithm." ::= { t11FcSpAuEntityEntry 10 } t11FcSpAuDhChapDhGroups OBJECT-TYPE SYNTAX T11FcSpDhGroups MAX-ACCESS read-only STATUS current DESCRIPTION "The DH Groups that the entity supports when using the DH-CHAP algorithm in FC-SP." ::= { t11FcSpAuEntityEntry 11 } t11FcSpAuFcapHashFunctions OBJECT-TYPE SYNTAX T11FcSpHashFunctions MAX-ACCESS read-only STATUS current DESCRIPTION "The hash functions that the entity supports when specified as Protocol Parameters in the AUTH_Negotiate message for FCAP in FC-SP." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.5.2.1 and table 28." ::= { t11FcSpAuEntityEntry 12 } t11FcSpAuFcapCertsSignFunctions OBJECT-TYPE SYNTAX T11FcSpSignFunctions MAX-ACCESS read-only STATUS current DESCRIPTION "The signature functions used within certificates that the entity supports when using FCAP in FC-SP." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), De Santi, et al. Standards Track [Page 40] RFC 5324 MIB for FC-SP September 2008 February 2007, section 5.5.4.2 and tables 38 & 39." ::= { t11FcSpAuEntityEntry 13 } t11FcSpAuFcapDhGroups OBJECT-TYPE SYNTAX T11FcSpDhGroups MAX-ACCESS read-only STATUS current DESCRIPTION "The DH Groups that the entity supports when using the FCAP algorithm in FC-SP." ::= { t11FcSpAuEntityEntry 14 } t11FcSpAuFcpapHashFunctions OBJECT-TYPE SYNTAX T11FcSpHashFunctions MAX-ACCESS read-only STATUS current DESCRIPTION "The hash functions that the entity supports when using the FCPAP algorithm in FC-SP." ::= { t11FcSpAuEntityEntry 15 } t11FcSpAuFcpapDhGroups OBJECT-TYPE SYNTAX T11FcSpDhGroups MAX-ACCESS read-only STATUS current DESCRIPTION "The DH Groups that the entity supports when using the FCPAP algorithm in FC-SP." ::= { t11FcSpAuEntityEntry 16 } -- -- The Mapping of Authentication Entities onto Interfaces -- and Statistics -- t11FcSpAuIfStatTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpAuIfStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each FC-SP Authentication entity can operate on one or more interfaces, but at most one of them can operate on each interface. A row in this table exists for each interface to each Fabric on which each Authentication entity operates. The objects within this table contain statistics information related to FC-SP's Authentication Protocols." ::= { t11FcSpAuMIBObjects 2 } De Santi, et al. Standards Track [Page 41] RFC 5324 MIB for FC-SP September 2008 t11FcSpAuIfStatEntry OBJECT-TYPE SYNTAX T11FcSpAuIfStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of Authentication Protocols statistics for an FC-SP Authentication entity (identified by t11FcSpAuEntityName) on one of its interfaces to a particular Fabric, which is managed within the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpAuEntityName, t11FcSpAuIfStatInterfaceIndex, t11FcSpAuIfStatFabricIndex } ::= { t11FcSpAuIfStatTable 1 } T11FcSpAuIfStatEntry ::= SEQUENCE { t11FcSpAuIfStatInterfaceIndex InterfaceIndex, t11FcSpAuIfStatFabricIndex T11FabricIndex, t11FcSpAuIfStatTimeouts Counter32, t11FcSpAuIfStatInAcceptedMsgs Counter32, t11FcSpAuIfStatInLsSwRejectedMsgs Counter32, t11FcSpAuIfStatInAuthRejectedMsgs Counter32, t11FcSpAuIfStatOutAcceptedMsgs Counter32, t11FcSpAuIfStatOutLsSwRejectedMsgs Counter32, t11FcSpAuIfStatOutAuthRejectedMsgs Counter32 } t11FcSpAuIfStatInterfaceIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface on which the FC-SP Authentication entity operates and for which the statistics are collected." ::= { t11FcSpAuIfStatEntry 1 } t11FcSpAuIfStatFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value identifying the particular Fabric for which the statistics are collected." ::= { t11FcSpAuIfStatEntry 2 } t11FcSpAuIfStatTimeouts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only De Santi, et al. Standards Track [Page 42] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages sent by the particular entity on the particular Fabric on the particular interface, for which no response was received within a timeout period. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.11." ::= { t11FcSpAuIfStatEntry 3 } t11FcSpAuIfStatInAcceptedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages received and accepted by the particular entity on the particular Fabric on the particular interface. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.1." ::= { t11FcSpAuIfStatEntry 4 } t11FcSpAuIfStatInLsSwRejectedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages received by the particular entity on the particular Fabric on the particular interface, and rejected by a lower-level (SW_RJT or LS_RJT) reject. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.1." De Santi, et al. Standards Track [Page 43] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpAuIfStatEntry 5 } t11FcSpAuIfStatInAuthRejectedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages received by the particular entity on the particular Fabric on the particular interface, and rejected by an AUTH_Reject message. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.1." ::= { t11FcSpAuIfStatEntry 6 } t11FcSpAuIfStatOutAcceptedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages sent by the particular entity on the particular Fabric on the particular interface, which were accepted by the neighboring entity, i.e., not rejected by an AUTH_Reject message, nor by a lower-level (SW_RJT or LS_RJT) reject. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.1." ::= { t11FcSpAuIfStatEntry 7 } t11FcSpAuIfStatOutLsSwRejectedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages sent by the particular entity on the particular Fabric on the particular interface, which were rejected by a lower-level (SW_RJT or LS_RJT) reject. De Santi, et al. Standards Track [Page 44] RFC 5324 MIB for FC-SP September 2008 This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.1." ::= { t11FcSpAuIfStatEntry 8 } t11FcSpAuIfStatOutAuthRejectedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages sent by the particular entity on the particular Fabric on the particular interface, which were rejected by an AUTH_Reject message. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.1." ::= { t11FcSpAuIfStatEntry 9 } -- -- Information about Authentication Protocol Transactions -- which were recently rejected -- t11FcSpAuRejectTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpAuRejectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of volatile information about FC-SP Authentication Protocol transactions that were recently rejected with an AUTH_Reject message, or with an SW_RJT/LS_RJT. The maximum number of rows in this table for a specific entity on a specific Fabric is given by the value of the corresponding instance of t11FcSpAuRejectMaxRows. The syntax of t11FcSpAuRejTimestamp is TimeStamp, and thus its value rolls over to zero after approximately 497 days. To avoid any confusion due to such a rollover, rows should be deleted from this table before they are 497 days old. De Santi, et al. Standards Track [Page 45] RFC 5324 MIB for FC-SP September 2008 This table will be empty if no AUTH_Reject messages, nor any SW_RJT/LS_RJT's rejecting an AUTH message, have been sent or received since the last re-initialization of the agent." ::= { t11FcSpAuMIBObjects 3 } t11FcSpAuRejectEntry OBJECT-TYPE SYNTAX T11FcSpAuRejectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about one AUTH message (either an AUTH_ELS or an AUTH_ILS) that was rejected with an AUTH_Reject, SW_RJT or LS_RJT message, sent/received by the entity identified by values of fcmInstanceIndex and t11FcSpAuEntityName, on an interface to a particular Fabric." INDEX { fcmInstanceIndex, t11FcSpAuEntityName, t11FcSpAuRejInterfaceIndex, t11FcSpAuRejFabricIndex, t11FcSpAuRejTimestamp } ::= { t11FcSpAuRejectTable 1 } T11FcSpAuRejectEntry ::= SEQUENCE { t11FcSpAuRejInterfaceIndex InterfaceIndex, t11FcSpAuRejFabricIndex T11FabricIndex, t11FcSpAuRejTimestamp TimeStamp, t11FcSpAuRejDirection INTEGER, t11FcSpAuRejType INTEGER, t11FcSpAuRejAuthMsgString OCTET STRING, t11FcSpAuRejReasonCode T11FcSpAuthRejectReasonCode, t11FcSpAuRejReasonCodeExp T11FcSpAuthRejReasonCodeExp } t11FcSpAuRejInterfaceIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface on which the rejected AUTH message was sent or received." ::= { t11FcSpAuRejectEntry 1 } t11FcSpAuRejFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value identifying the particular Fabric on De Santi, et al. Standards Track [Page 46] RFC 5324 MIB for FC-SP September 2008 which the rejected AUTH message was sent or received." ::= { t11FcSpAuRejectEntry 2 } t11FcSpAuRejTimestamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time at which the AUTH message was rejected. If two rows have the same value of this object for the same entity on the same interface and Fabric, the value of this object for the later one is incremented by one." ::= { t11FcSpAuRejectEntry 3 } t11FcSpAuRejDirection OBJECT-TYPE SYNTAX INTEGER { sent(1), received(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the rejection was sent or received by the identified entity. The value 'sent(1)' corresponds to a notification of type t11FcSpAuRejectSentNotify; the value 'received(2)' corresponds to t11FcSpAuRejectReceivedNotify." ::= { t11FcSpAuRejectEntry 4 } t11FcSpAuRejType OBJECT-TYPE SYNTAX INTEGER { authReject(1), swRjt(2), lsRjt(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the rejection was an AUTH_Reject, an SW_RJT or an LS_RJT." ::= { t11FcSpAuRejectEntry 5 } t11FcSpAuRejAuthMsgString OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The binary content of the AUTH message that was rejected, formatted as an octet string (in network byte order) containing the content of the message. De Santi, et al. Standards Track [Page 47] RFC 5324 MIB for FC-SP September 2008 If the binary content is unavailable, then the length is zero. Otherwise, the first octet of the message identifies the type of message: '90'h - an AUTH_ELS, see Table 6 in FC-SP, '40'h - an AUTH_ILS, see Table 3 in FC-SP, or '41'h - an B_AUTH_ILS, see Table 5 in FC-SP. and the remainder of the message may be truncated." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Tables 3, 5 and 6." ::= { t11FcSpAuRejectEntry 6 } t11FcSpAuRejReasonCode OBJECT-TYPE SYNTAX T11FcSpAuthRejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION "The reason code with which this AUTH message was rejected." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 17, 48, 52." ::= { t11FcSpAuRejectEntry 7 } t11FcSpAuRejReasonCodeExp OBJECT-TYPE SYNTAX T11FcSpAuthRejReasonCodeExp MAX-ACCESS read-only STATUS current DESCRIPTION "The reason code explanation with which this AUTH message was rejected." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 17, 48, 52." ::= { t11FcSpAuRejectEntry 8 } -- -- Notifications -- t11FcSpAuRejectSentNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11FcSpAuRejAuthMsgString, De Santi, et al. Standards Track [Page 48] RFC 5324 MIB for FC-SP September 2008 t11FcSpAuRejType, t11FcSpAuRejReasonCode, t11FcSpAuRejReasonCodeExp } STATUS current DESCRIPTION "This notification indicates that a Switch (identified by the value of t11FamLocalSwitchWwn) has sent a reject message of the type indicated by t11FcSpAuRejType in response to an AUTH message. The content of the rejected AUTH message is given by the value of t11FcSpAuRejAuthMsgString. The values of the Reason Code and Reason Code Explanation in the AUTH_Reject/SW_RJT/LS_RJT are indicated by the values of t11FcSpAuRejReasonCode and t11FcSpAuRejReasonCodeExp." ::= { t11FcSpAuMIBNotifications 1 } t11FcSpAuRejectReceivedNotify NOTIFICATION-TYPE OBJECTS { t11FamLocalSwitchWwn, t11FcSpAuRejAuthMsgString, t11FcSpAuRejType, t11FcSpAuRejReasonCode, t11FcSpAuRejReasonCodeExp } STATUS current DESCRIPTION "This notification indicates that a Switch (identified by the value of t11FamLocalSwitchWwn) has received a reject message of the type indicated by t11FcSpAuRejType in response to an AUTH message. The content of the rejected AUTH message is given by the value of t11FcSpAuRejAuthMsgString. The values of the Reason Code and Reason Code Explanation in the AUTH_Reject/SW_RJT/LS_RJT are indicated by the values of t11FcSpAuRejReasonCode and t11FcSpAuRejReasonCodeExp." ::= { t11FcSpAuMIBNotifications 2 } -- -- Conformance -- t11FcSpAuMIBCompliances OBJECT IDENTIFIER ::= { t11FcSpAuMIBConformance 1 } t11FcSpAuMIBGroups OBJECT IDENTIFIER ::= { t11FcSpAuMIBConformance 2 } t11FcSpAuMIBCompliance MODULE-COMPLIANCE STATUS current De Santi, et al. Standards Track [Page 49] RFC 5324 MIB for FC-SP September 2008 DESCRIPTION "The compliance statement for entities that implement one or more of the Authentication Protocols defined in FC-SP." MODULE -- this module MANDATORY-GROUPS { t11FcSpAuGeneralGroup, t11FcSpAuRejectedGroup, t11FcSpAuNotificationGroup } GROUP t11FcSpAuIfStatsGroup DESCRIPTION "These counters, of particular FC-SP messages and events, are mandatory only for those systems that count such messages/events." -- Write access is not required for any objects in this MIB module: OBJECT t11FcSpAuStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpAuSendRejNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpAuRcvRejNotifyEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpAuDefaultLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpAuDefaultLifetimeUnits MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpAuRejectMaxRows MIN-ACCESS read-only DESCRIPTION "Write access is not required." De Santi, et al. Standards Track [Page 50] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpAuMIBCompliances 1 } -- Units of Conformance t11FcSpAuGeneralGroup OBJECT-GROUP OBJECTS { t11FcSpAuServerProtocol, t11FcSpAuStorageType, t11FcSpAuSendRejNotifyEnable, t11FcSpAuRcvRejNotifyEnable, t11FcSpAuDefaultLifetime, t11FcSpAuDefaultLifetimeUnits, t11FcSpAuRejectMaxRows, t11FcSpAuDhChapHashFunctions, t11FcSpAuDhChapDhGroups, t11FcSpAuFcapHashFunctions, t11FcSpAuFcapCertsSignFunctions, t11FcSpAuFcapDhGroups, t11FcSpAuFcpapHashFunctions, t11FcSpAuFcpapDhGroups, t11FcSpAuIfStatTimeouts } STATUS current DESCRIPTION "A collection of objects for the capabilities and configuration parameters of FC-SP's Authentication Protocols. The inclusion of t11FcSpAuIfStatTimeouts in this group provides information on mappings of Authentication entities onto interfaces." ::= { t11FcSpAuMIBGroups 1 } t11FcSpAuIfStatsGroup OBJECT-GROUP OBJECTS { t11FcSpAuIfStatInAcceptedMsgs, t11FcSpAuIfStatInLsSwRejectedMsgs, t11FcSpAuIfStatInAuthRejectedMsgs, t11FcSpAuIfStatOutAcceptedMsgs, t11FcSpAuIfStatOutLsSwRejectedMsgs, t11FcSpAuIfStatOutAuthRejectedMsgs } STATUS current DESCRIPTION "A collection of objects for monitoring the operations of FC-SP's Authentication Protocols." ::= { t11FcSpAuMIBGroups 2 } t11FcSpAuRejectedGroup OBJECT-GROUP OBJECTS { t11FcSpAuRejDirection, t11FcSpAuRejType, t11FcSpAuRejAuthMsgString, t11FcSpAuRejReasonCode, t11FcSpAuRejReasonCodeExp } De Santi, et al. Standards Track [Page 51] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "A collection of objects holding information concerning FC-SP Authentication Protocol transactions that were recently rejected with an AUTH_Reject, with an SW_RJT, or with an LS_RJT." ::= { t11FcSpAuMIBGroups 3 } t11FcSpAuNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FcSpAuRejectSentNotify, t11FcSpAuRejectReceivedNotify } STATUS current DESCRIPTION "A collection of notifications for use in the management of FC-SP's Authentication Protocols." ::= { t11FcSpAuMIBGroups 4 } END 6.3. The T11-FC-SP-ZONING-MIB Module --******************************************************************* -- FC-SP Zoning -- T11-FC-SP-ZONING-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Counter32 FROM SNMPv2-SMI -- [RFC2578] TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] ifIndex FROM IF-MIB -- [RFC2863] t11ZsServerEntry, t11ZsStatsEntry, t11ZsNotifyControlEntry, t11ZsFabricIndex FROM T11-FC-ZONE-SERVER-MIB -- [RFC4936] T11FcSpPolicyHashValue, T11FcSpPolicyHashFormat, T11FcSpHashCalculationStatus FROM T11-FC-SP-TC-MIB; t11FcSpZoningMIB MODULE-IDENTITY LAST-UPDATED "200808200000Z" De Santi, et al. Standards Track [Page 52] RFC 5324 MIB for FC-SP September 2008 ORGANIZATION "This MIB module was developed through the coordinated effort of two organizations: T11 began the development and the IETF (in the IMSS Working Group) finished it." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: kzm@cisco.com" DESCRIPTION "This MIB module specifies the extensions to the T11-FC-ZONE-SERVER-MIB module that are necessary for the management of Fibre Channel's FC-SP Zoning Servers, as defined in the FC-SP specification. The persistence of values written to these MIB objects is the same as the persistence of the objects they extend, i.e., it is given by the value of the relevant instance of t11ZsServerDatabaseStorageType (defined in the T11-FC-ZONE-SERVER-MIB module). Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5324; see the RFC itself for full legal notices." REVISION "200808200000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 5324." ::= { mib-2 177 } t11FcSpZsMIBNotifications OBJECT IDENTIFIER ::= { t11FcSpZoningMIB 0 } t11FcSpZsMIBObjects OBJECT IDENTIFIER ::= { t11FcSpZoningMIB 1 } t11FcSpZsMIBConformance OBJECT IDENTIFIER ::= { t11FcSpZoningMIB 2 } t11FcSpZsConfiguration OBJECT IDENTIFIER ::= { t11FcSpZsMIBObjects 1 } t11FcSpZsStatistics OBJECT IDENTIFIER ::= { t11FcSpZsMIBObjects 2 } -- -- Augmenting the table of Zone Servers -- t11FcSpZsServerTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpZsServerEntry De Santi, et al. Standards Track [Page 53] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table which provides FC-SP-specific information about the Zone Servers on each Fabric in one or more Switches." ::= { t11FcSpZsConfiguration 1 } t11FcSpZsServerEntry OBJECT-TYPE SYNTAX T11FcSpZsServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information relevant to FC-SP for a particular Zone Server for a particular Fabric on a particular Switch. The Fabric and Switch are identified in the same manner as in t11ZsServerEntry." AUGMENTS { t11ZsServerEntry } ::= { t11FcSpZsServerTable 1 } T11FcSpZsServerEntry ::= SEQUENCE { t11FcSpZsServerCapabilityObject BITS, t11FcSpZsServerEnabled TruthValue, t11FcSpZoneSetHashStatus T11FcSpHashCalculationStatus, t11FcSpActiveZoneSetHashType T11FcSpPolicyHashFormat, t11FcSpActiveZoneSetHash T11FcSpPolicyHashValue, t11FcSpZoneSetDatabaseHashType T11FcSpPolicyHashFormat, t11FcSpZoneSetDatabaseHash T11FcSpPolicyHashValue } t11FcSpZsServerCapabilityObject OBJECT-TYPE SYNTAX BITS { fcSpZoning(0) } MAX-ACCESS read-only STATUS current DESCRIPTION "Capabilities of the Zone Server for the particular Fabric on the particular Switch, with respect to FC-SP Zoning: fcSpZoning -- set to 1 to indicate the Switch is capable of supporting FC-SP Zoning. " REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 184." ::= { t11FcSpZsServerEntry 1 } De Santi, et al. Standards Track [Page 54] RFC 5324 MIB for FC-SP September 2008 t11FcSpZsServerEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the Zone Server for the particular Fabric on the particular Switch, is operating in FC-SP Zoning mode." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 185." ::= { t11FcSpZsServerEntry 2 } t11FcSpZoneSetHashStatus OBJECT-TYPE SYNTAX T11FcSpHashCalculationStatus MAX-ACCESS read-write STATUS current DESCRIPTION "When read, the value of this object is either: correct -- the corresponding instances of both t11FcSpActiveZoneSetHash and t11FcSpZoneSetDatabaseHash contain the correct hash values; or stale -- the corresponding instances of t11FcSpActiveZoneSetHash and t11FcSpZoneSetDatabaseHash contain stale (possibly incorrect) values; Writing a value of 'calculate' is a request to re-calculate and update the values of the corresponding instances of both t11FcSpActiveZoneSetHash and t11FcSpZoneSetDatabaseHash. Writing a value of 'correct' or 'stale' to this object is an error (e.g., 'wrongValue'). When the Active Zone Set and/or the Zone Set Database are updated, it is common that multiple changes need to be made at the same time. In such circumstances, the use of this object allows the hash values to be updated only once after all changes, rather than repeatedly/after each individual change. If and when the corresponding instance of t11ZsServerDatabaseStorageType has the value 'permanent(4)', then if write access is supported to any instance of a read-write object in any row of any table governed by the 'permanent' value of t11ZsServerDatabaseStorageType, then De Santi, et al. Standards Track [Page 55] RFC 5324 MIB for FC-SP September 2008 write access to the corresponding instance of this object must also be supported." REFERENCE "t11ZsServerDatabaseStorageType in 'Fibre Channel Zone Server MIB', RFC 4936, August 2007." DEFVAL { stale } ::= { t11FcSpZsServerEntry 3 } t11FcSpActiveZoneSetHashType OBJECT-TYPE SYNTAX T11FcSpPolicyHashFormat MAX-ACCESS read-only STATUS current DESCRIPTION "The format used for the hash value contained in the corresponding instance of t11FcSpActiveZoneSetHash." ::= { t11FcSpZsServerEntry 4 } t11FcSpActiveZoneSetHash OBJECT-TYPE SYNTAX T11FcSpPolicyHashValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the hash for the current Active Zone Set. The format of this value is given by the corresponding instance of t11FcSpActiveZoneSetHashType." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 187." ::= { t11FcSpZsServerEntry 5 } t11FcSpZoneSetDatabaseHashType OBJECT-TYPE SYNTAX T11FcSpPolicyHashFormat MAX-ACCESS read-only STATUS current DESCRIPTION "The format used for the hash value contained in the corresponding instance of t11FcSpZoneSetDatabaseHash." ::= { t11FcSpZsServerEntry 6 } t11FcSpZoneSetDatabaseHash OBJECT-TYPE SYNTAX T11FcSpPolicyHashValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the hash for the current Zone Set Database. The format of this value is given by the corresponding instance of t11FcSpZoneSetDatabaseHashType." De Santi, et al. Standards Track [Page 56] RFC 5324 MIB for FC-SP September 2008 REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Table 187." ::= { t11FcSpZsServerEntry 7 } -- -- Additional Statistics for FC-SP Zoning -- t11FcSpZsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpZsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of statistics specific to FC-SP that are maintained by Zone Servers." ::= { t11FcSpZsStatistics 1 } t11FcSpZsStatsEntry OBJECT-TYPE SYNTAX T11FcSpZsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics specific to FC-SP for a particular Zone Server for a particular Fabric on a particular Switch. The Fabric and Switch are identified in the same manner as in t11ZsStatsEntry." AUGMENTS { t11ZsStatsEntry } ::= { t11FcSpZsStatsTable 1 } T11FcSpZsStatsEntry ::= SEQUENCE { t11FcSpZsSPCMITrequestsSent Counter32, t11FcSpZsSPCMITrequestsAccepted Counter32, t11FcSpZsSPCMITrequestsRejected Counter32, t11FcSpZsZcpRequestsSent Counter32, t11FcSpZsZcpRequestsAccepted Counter32, t11FcSpZsZcpRequestsRejected Counter32, t11FcSpZsZirRequestsAccepted Counter32, t11FcSpZsZirRequestsRejected Counter32 } t11FcSpZsSPCMITrequestsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SP Commit Zone Changes (SPCMIT) operation De Santi, et al. Standards Track [Page 57] RFC 5324 MIB for FC-SP September 2008 requests sent by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 1 } t11FcSpZsSPCMITrequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SP Commit Zone Changes (SPCMIT) operation requests received and accepted by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 2 } t11FcSpZsSPCMITrequestsRejected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SP Commit Zone Changes (SPCMIT) operation requests received but rejected by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 3 } t11FcSpZsZcpRequestsSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Zoning Check Protocol (ZCP) requests sent by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 4 } t11FcSpZsZcpRequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Zoning Check Protocol (ZCP) requests received De Santi, et al. Standards Track [Page 58] RFC 5324 MIB for FC-SP September 2008 and accepted by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 5 } t11FcSpZsZcpRequestsRejected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Zoning Check Protocol (ZCP) requests received but rejected by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 6 } t11FcSpZsZirRequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Zoning Information Request (ZIR) requests received and accepted by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 7 } t11FcSpZsZirRequestsRejected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Zoning Information Request (ZIR) requests received but rejected by the Zone Server. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." ::= { t11FcSpZsStatsEntry 8 } -- -- Enable/Disable for Notifications -- t11FcSpZsNotifyControlTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpZsNotifyControlEntry De Santi, et al. Standards Track [Page 59] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control information for notifications generated due to Zone Server events related to FC-SP Zoning." ::= { t11FcSpZsConfiguration 2 } t11FcSpZsNotifyControlEntry OBJECT-TYPE SYNTAX T11FcSpZsNotifyControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry is an augmentation of the notification control information for a Zone Server for a particular Fabric on a particular Switch. The Fabric and Switch are identified in the same manner as in t11ZsNotifyControlEntry." AUGMENTS { t11ZsNotifyControlEntry } ::= { t11FcSpZsNotifyControlTable 1 } T11FcSpZsNotifyControlEntry ::= SEQUENCE { t11FcSpZsNotifyJoinSuccessEnable TruthValue, t11FcSpZsNotifyJoinFailureEnable TruthValue } t11FcSpZsNotifyJoinSuccessEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11FcSpZsFabricJoinFailureNotify notifications should be generated by the Zone Server for this Fabric." ::= { t11FcSpZsNotifyControlEntry 1 } t11FcSpZsNotifyJoinFailureEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11FcSpZsFabricJoinSuccessNotify notifications should be generated by the Zone Server for this Fabric." ::= { t11FcSpZsNotifyControlEntry 2 } -- -- Notifications -- De Santi, et al. Standards Track [Page 60] RFC 5324 MIB for FC-SP September 2008 t11FcSpZsFabricJoinSuccessNotify NOTIFICATION-TYPE OBJECTS { ifIndex, t11ZsFabricIndex } STATUS current DESCRIPTION "This notification indicates that a Switch that is part of one Fabric (indicated by the value of t11ZsFabricIndex) has successfully joined (on the interface indicated by the value of ifIndex) with a Switch that is part of another Fabric. If multiple Virtual Fabrics are configured on an interface, and all are successfully joined at the same time, and if the agent so chooses, then it can generate just one notification in which t11ZsFabricIndex has the value 4096." ::= { t11FcSpZsMIBNotifications 1 } t11FcSpZsFabricJoinFailureNotify NOTIFICATION-TYPE OBJECTS { ifIndex, t11ZsFabricIndex } STATUS current DESCRIPTION "This notification indicates that an E_Port on the local Switch has entered the Isolated state because a join between two Fabrics failed. The failure occurred on the local Fabric indicated by the value of t11ZsFabricIndex, on the interface indicated by the value of ifIndex. If multiple Virtual Fabrics are configured on an interface, and all have a failure to join at the same time, and if the agent so chooses, then it can generate just one notification in which t11ZsFabricIndex has the value 4096." ::= { t11FcSpZsMIBNotifications 2 } -- -- Conformance -- t11FcSpZsMIBCompliances OBJECT IDENTIFIER ::= { t11FcSpZsMIBConformance 1 } t11FcSpZsMIBGroups OBJECT IDENTIFIER ::= { t11FcSpZsMIBConformance 2 } t11FcSpZsMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the extensions specified in FC-SP for Fibre Channel's Zone Server." MODULE -- this module De Santi, et al. Standards Track [Page 61] RFC 5324 MIB for FC-SP September 2008 MANDATORY-GROUPS { t11FcSpZsObjectsGroup, t11FcSpZsNotificationControlGroup, t11FcSpZsNotificationGroup } GROUP t11FcSpZsStatisticsGroup DESCRIPTION "These counters, containing Zone Server statistics, are mandatory only for those systems that count such events." -- Write access is not required for any objects in this MIB module: OBJECT t11FcSpZsServerEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpZoneSetHashStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpZsNotifyJoinSuccessEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpZsNotifyJoinFailureEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FcSpZsMIBCompliances 1 } -- Units of Conformance t11FcSpZsObjectsGroup OBJECT-GROUP OBJECTS { t11FcSpZsServerCapabilityObject, t11FcSpZsServerEnabled, t11FcSpZoneSetHashStatus, t11FcSpActiveZoneSetHashType, t11FcSpActiveZoneSetHash, t11FcSpZoneSetDatabaseHashType, t11FcSpZoneSetDatabaseHash } STATUS current DESCRIPTION "A collection of objects for Zone configuration De Santi, et al. Standards Track [Page 62] RFC 5324 MIB for FC-SP September 2008 information of a Zone Server capable of operating in FC-SP Zoning mode." ::= { t11FcSpZsMIBGroups 1 } t11FcSpZsNotificationControlGroup OBJECT-GROUP OBJECTS { t11FcSpZsNotifyJoinSuccessEnable, t11FcSpZsNotifyJoinFailureEnable } STATUS current DESCRIPTION "A collection of notification control objects for monitoring Zone Server failures specific to FC-SP." ::= { t11FcSpZsMIBGroups 2 } t11FcSpZsStatisticsGroup OBJECT-GROUP OBJECTS { t11FcSpZsSPCMITrequestsSent, t11FcSpZsSPCMITrequestsAccepted, t11FcSpZsSPCMITrequestsRejected, t11FcSpZsZcpRequestsSent, t11FcSpZsZcpRequestsAccepted, t11FcSpZsZcpRequestsRejected, t11FcSpZsZirRequestsAccepted, t11FcSpZsZirRequestsRejected } STATUS current DESCRIPTION "A collection of objects for collecting Zone Server statistics which are specific to FC-SP." ::= { t11FcSpZsMIBGroups 3 } t11FcSpZsNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FcSpZsFabricJoinSuccessNotify, t11FcSpZsFabricJoinFailureNotify } STATUS current DESCRIPTION "A collection of notification(s) for monitoring Zone Server events that are specific to FC-SP." ::= { t11FcSpZsMIBGroups 4 } END De Santi, et al. Standards Track [Page 63] RFC 5324 MIB for FC-SP September 2008 6.4. The T11-FC-SP-POLICY-MIB Module --******************************************************************* -- FC-SP Policy -- T11-FC-SP-POLICY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Counter32, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] RowStatus, StorageType, TimeStamp, TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddress, InetPortNumber, InetAddressType FROM INET-ADDRESS-MIB -- [RFC4001] fcmInstanceIndex, FcNameIdOrZero, FcDomainIdOrZero FROM FC-MGMT-MIB -- [RFC4044] T11NsGs4RejectReasonCode FROM T11-FC-NAME-SERVER-MIB -- [RFC4438] T11FabricIndex FROM T11-TC-MIB -- [RFC4439] T11FcSpAlphaNumName, T11FcSpAlphaNumNameOrAbsent, T11FcSpPolicyName, T11FcSpPolicyNameType, T11FcSpPolicyObjectType, T11FcSpPolicyHashFormat, T11FcSpPolicyHashValue, T11FcSpHashCalculationStatus FROM T11-FC-SP-TC-MIB; t11FcSpPolicyMIB MODULE-IDENTITY LAST-UPDATED "200808200000Z" ORGANIZATION "This MIB module was developed through the coordinated effort of two organizations: T11 began the development and the IETF (in the IMSS Working Group) finished it." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com De Santi, et al. Standards Track [Page 64] RFC 5324 MIB for FC-SP September 2008 Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: kzm@cisco.com" DESCRIPTION "This MIB module specifies the management information required to manage Fabric Policies as defined by Fibre Channel's FC-SP specification. FC-SP uses the term 'Policy Objects', sometimes abbreviated to just 'Objects', to refer to containers used to hold the data by which Fabric Policies are specified/stored. This obviously has the potential to cause confusion between 'Policy Objects' and 'MIB objects'. The DESCRIPTIONs in this MIB module attempt to avoid such confusion by the use of different adjectives and capitalization, even though such mechanisms are less effective when used in descriptors. Some types of Policy Objects contain multiple items of information, each of which are held in the same format within the Policy Object. In such cases, FC-SP uses the term 'Entry' to describe each instance of the common format. For example, FC-SP defines an Attribute Policy Object as containing one or more 'Attribute Entries'. Again, this MIB module attempts to avoid confusion by the use of adjectives and capitalization to distinguish an Entry within a Policy Object from an entry within a MIB table. A Fabric's database of Policy Objects consists of a set of active Objects that are to be enforced by that Fabric, as well as non-active Objects that are not enforced. Operations defined (in FC-SP) for Policy Management are: - Add/Get/Remove operations on individual non-active Policy Objects, - Activate/Deactivate operations on a Policy Summary Object, and - Get operations on the active Policy Summary Object and/or on individual active Policy Objects. This MIB module has five parts: 1) Active Policy Objects - read-only MIB objects representing the set of active Policy Objects for each Fabric, 2) Activate/Deactivate Operations De Santi, et al. Standards Track [Page 65] RFC 5324 MIB for FC-SP September 2008 - a read-write MIB object to invoke an Activate operation of the policies specified via a non-active Policy Summary Object, and - a read-write MIB object to invoke a Deactivate operation. 3) Non-active Policy Objects - read-create MIB objects to allow the creation of non-active Policy Summary Objects (which reference non-active Policy Objects), and - read-create MIB objects representing non-active Policy Objects. 4) Statistics 5) Control information and Notifications Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5324; see the RFC itself for full legal notices." REVISION "200808200000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 5324." ::= { mib-2 178 } t11FcSpPoMIBNotifications OBJECT IDENTIFIER ::= { t11FcSpPolicyMIB 0 } t11FcSpPoMIBObjects OBJECT IDENTIFIER ::= { t11FcSpPolicyMIB 1 } t11FcSpPoMIBConformance OBJECT IDENTIFIER ::= { t11FcSpPolicyMIB 2 } t11FcSpPoActive OBJECT IDENTIFIER ::= { t11FcSpPoMIBObjects 1 } t11FcSpPoOperations OBJECT IDENTIFIER ::= { t11FcSpPoMIBObjects 2 } t11FcSpPoNonActive OBJECT IDENTIFIER ::= { t11FcSpPoMIBObjects 3 } t11FcSpPoStatistics OBJECT IDENTIFIER ::= { t11FcSpPoMIBObjects 4 } t11FcSpPoControl OBJECT IDENTIFIER ::= { t11FcSpPoMIBObjects 5 } -- -- Part 1 - Active Policy Objects -- t11FcSpPoTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing top-level information about active FC-SP policies on various Fabrics." ::= { t11FcSpPoActive 1 } t11FcSpPoEntry OBJECT-TYPE De Santi, et al. Standards Track [Page 66] RFC 5324 MIB for FC-SP September 2008 SYNTAX T11FcSpPoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about active FC-SP policies for a particular Fabric, managed as part of the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex } ::= { t11FcSpPoTable 1 } T11FcSpPoEntry ::= SEQUENCE { t11FcSpPoFabricIndex T11FabricIndex, t11FcSpPoPolicySummaryObjName T11FcSpAlphaNumName, t11FcSpPoAdminFabricName FcNameIdOrZero, t11FcSpPoActivatedTimeStamp TimeStamp } t11FcSpPoFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Fabric." ::= { t11FcSpPoEntry 1 } t11FcSpPoPolicySummaryObjName OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this Fabric's (active) Policy Summary Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.3 and table 104." ::= { t11FcSpPoEntry 2 } t11FcSpPoAdminFabricName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The administratively-specified name for this Fabric, as specified in the active Switch Membership List Object. This value is meaningful only when Static Domain_IDs are in use in a Fabric (see FC-SW-4). Static Domain_IDs are administratively enabled by a setting of the Switch Flags De Santi, et al. Standards Track [Page 67] RFC 5324 MIB for FC-SP September 2008 in each Switch Entry in the Switch Membership List Object. If Static Domain_IDs are not in use, this value might be '0000000000000000'h. The t11FamEnable, t11FamFabricName, and t11FamConfigDomainIdType objects defined in the T11-FC-FABRIC-ADDR-MGR-MIB module are also concerned with the use of an administratively-specified name for a Fabric and Static Domain_IDs. When FC-SP Policy is in use in a Fabric, the values of t11FamEnable, t11FamFabricName, and t11FamConfigDomainIdType must be read-only and reflect the active Policy Objects. For example, the value of t11FamFabricName must reflect the value of t11FcSpPoAdminFabricName." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 108. - Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, section 7.1. - Fibre Channel Fabric Address Manager MIB', RFC 4439, March 2006." ::= { t11FcSpPoEntry 3 } t11FcSpPoActivatedTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which this Fabric's Policy Summary Object was last activated, or zero if the same Policy Summary Object has been active since the last restart of the management system." ::= { t11FcSpPoEntry 4 } -- -- The table of Policy Summary Objects -- t11FcSpPoSummaryTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about active Policy Objects listed within FC-SP Policy Summary Objects." ::= { t11FcSpPoActive 2 } De Santi, et al. Standards Track [Page 68] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoSummaryEntry OBJECT-TYPE SYNTAX T11FcSpPoSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one of the active Policy Objects listed within the Policy Summary Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. How many Policy Objects of a given type can be active at any one time for a given Fabric depends on the type, as specified in FC-SP. For some types, it is one per Fabric; for other types, more than one can be active per Fabric. In both of these cases, the absence of any entries in this table for a particular type is equivalent to there being one Policy Object of that type that is empty, e.g., a Switch Membership List Object that identifies zero Switches." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.3 and table 104." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoSummaryPolicyNameType, t11FcSpPoSummaryPolicyName } ::= { t11FcSpPoSummaryTable 1 } T11FcSpPoSummaryEntry ::= SEQUENCE { t11FcSpPoSummaryPolicyNameType T11FcSpPolicyNameType, t11FcSpPoSummaryPolicyName T11FcSpPolicyName, t11FcSpPoSummaryPolicyType T11FcSpPolicyObjectType, t11FcSpPoSummaryHashFormat T11FcSpPolicyHashFormat, t11FcSpPoSummaryHashValue T11FcSpPolicyHashValue } t11FcSpPoSummaryPolicyNameType OBJECT-TYPE SYNTAX T11FcSpPolicyNameType { nodeName(1), alphaNumericName(7) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The combination of t11FcSpPoSummaryPolicyNameType and t11FcSpPoSummaryPolicyName specify the name of the Policy Object contained in the Policy Summary Object. De Santi, et al. Standards Track [Page 69] RFC 5324 MIB for FC-SP September 2008 The type of name is 'nodeName' if the value of the corresponding instance of t11FcSpPoSummaryPolicyType is 'switchConnectivity', or 'alphaNumericName' otherwise." ::= { t11FcSpPoSummaryEntry 1 } t11FcSpPoSummaryPolicyName OBJECT-TYPE SYNTAX T11FcSpPolicyName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The combination of t11FcSpPoSummaryPolicyNameType and t11FcSpPoSummaryPolicyName specify the name of the Policy Object contained in the Policy Summary Object." ::= { t11FcSpPoSummaryEntry 2 } t11FcSpPoSummaryPolicyType OBJECT-TYPE SYNTAX T11FcSpPolicyObjectType MAX-ACCESS read-only STATUS current DESCRIPTION "The 'Identifier' that specifies the type of this Policy Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.3.1 and table 104." ::= { t11FcSpPoSummaryEntry 3 } t11FcSpPoSummaryHashFormat OBJECT-TYPE SYNTAX T11FcSpPolicyHashFormat MAX-ACCESS read-only STATUS current DESCRIPTION "The format of this Policy Object's hash value as contained in the corresponding instance of the t11FcSpPoSummaryHashValue object." ::= { t11FcSpPoSummaryEntry 4 } t11FcSpPoSummaryHashValue OBJECT-TYPE SYNTAX T11FcSpPolicyHashValue MAX-ACCESS read-only STATUS current DESCRIPTION "The hash value of this Policy Object, in the format identified by the corresponding instance of the t11FcSpPoSummaryHashFormat object." ::= { t11FcSpPoSummaryEntry 5 } De Santi, et al. Standards Track [Page 70] RFC 5324 MIB for FC-SP September 2008 -- -- Switch Entries in Active Switch Membership List Objects -- t11FcSpPoSwMembTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoSwMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Switch Entries in active Switch Membership List Objects. One Switch Membership List Object is represented by all of the rows of this table that have the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoActive 3 } t11FcSpPoSwMembEntry OBJECT-TYPE SYNTAX T11FcSpPoSwMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Switch Entry within the active Switch Membership List Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoSwMembSwitchNameType, t11FcSpPoSwMembSwitchName } ::= { t11FcSpPoSwMembTable 1 } T11FcSpPoSwMembEntry ::= SEQUENCE { t11FcSpPoSwMembSwitchNameType T11FcSpPolicyNameType, t11FcSpPoSwMembSwitchName FcNameIdOrZero, t11FcSpPoSwMembSwitchFlags BITS, t11FcSpPoSwMembDomainID FcDomainIdOrZero, t11FcSpPoSwMembPolicyDataRole INTEGER, t11FcSpPoSwMembAuthBehaviour BITS, t11FcSpPoSwMembAttribute T11FcSpAlphaNumNameOrAbsent } t11FcSpPoSwMembSwitchNameType OBJECT-TYPE SYNTAX T11FcSpPolicyNameType { nodeName(1), De Santi, et al. Standards Track [Page 71] RFC 5324 MIB for FC-SP September 2008 restrictedNodeName(2), wildcard(5), restrictedWildcard(6) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of this object is 'nodeName' or 'restrictedNodeName', then the combination of this object and t11FcSpPoSwMembSwitchName specify the Switch Name of this Switch Entry. The membership is restricted or unrestricted based on the name type. Restricted membership means that the Switch is not allowed to be part of the Fabric unless allowed by a specific Switch Connectivity Object. Unrestricted membership means that the Switch is allowed to be part of the Fabric unless disallowed by a specific Switch Connectivity Object. The values of 'wildcard' and 'restrictedWildcard' provide the means to specify whether to allow/deny membership for Switches not explicitly named in the Switch Membership List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoSwMembEntry 1 } t11FcSpPoSwMembSwitchName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "When the value of t11FcSpPoSwMembSwitchNameType is 'wildcard' or 'restrictedWildcard', this object has the value '0000000000000000'h. Otherwise, the combination of t11FcSpPoSwMembSwitchNameType and this object specify the Switch Name of this Switch Entry." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoSwMembEntry 2 } De Santi, et al. Standards Track [Page 72] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoSwMembSwitchFlags OBJECT-TYPE SYNTAX BITS { staticDomainID(0), insistentDomainID(1), serialPortsAccess(2), physicalPortsAccess(3), managerRole(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Configurable options in respect to the administration of Policy Objects at this Switch: 'staticDomainID' - if this bit is set, the Switch uses the 'Static Domain_IDs behavior' (as defined in FC-SW-4). This bit needs to have the same setting for all Switches in a Fabric's Switch Membership List Object, or else the Fabric will partition. If this bit is set, the Domain_ID for the Switch is given by the corresponding instance of t11FcSpPoSwMembDomainID. 'insistentDomainID' - if this bit is set, the Switch uses the 'Insistent Domain_ID behavior' (see t11FamConfigDomainId of T11-FC-FABRIC-ADDR-MGR-MIB), the Domain_ID for the Switch is given by the corresponding instance of t11FcSpPoSwMembDomainID. 'serialPortsAccess' - the Switch allows management through serial ports when and only when this bit is set. 'physicalPortsAccess' - the Switch allows management through the physical panel when and only when this bit is set. 'managerRole' - the Switch is allowed to change the Fabric Policy configuration (on receipt of any of the EACA, Enhanced Stage Fabric Configuration (ESFC), Enhanced Update Fabric Configuration (EUFC), ACA, SFC, or UFC SW_ILSs) if and only if this bit is set. Whenever a Fabric has Active Policy Objects, the value of the t11FamConfigDomainIdType object defined in the T11-FC-FABRIC-ADDR-MGR-MIB module must be read-only and reflect the values of the 'staticDomainID' and 'insistentDomainID' bits of this object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, De Santi, et al. Standards Track [Page 73] RFC 5324 MIB for FC-SP September 2008 Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 112. - Fibre Channel - Switch Fabric-4 (FC-SW-4), ANSI INCITS 418-2006, April 2006, section 7.1. - t11FamConfigDomainIdType, T11-FC-FABRIC-ADDR-MGR-MIB, Fibre Channel Fabric Address Manager MIB, RFC 4439." ::= { t11FcSpPoSwMembEntry 3 } t11FcSpPoSwMembDomainID OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The specified Domain_ID value when either of the 'staticDomainID' or 'insistentDomainID' bits are set in the corresponding instance of t11FcSpPoSwMembSwitchFlags. Whenever a Fabric has Active Policy Objects, the value of the t11FamConfigDomainId object defined in the T11-FC-FABRIC-ADDR-MGR-MIB module must be read-only and reflect the value of this object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and tables 111 and 112. - t11FamConfigDomainId, T11-FC-FABRIC-ADDR-MGR-MIB, Fibre Channel Fabric Address Manager MIB, RFC 4439." ::= { t11FcSpPoSwMembEntry 4 } t11FcSpPoSwMembPolicyDataRole OBJECT-TYPE SYNTAX INTEGER { client(1), autonomous(2), server(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The role of the Switch in terms of which Policy data it retains/maintains: 'client' - the Switch operates as a Client Switch. A Client Switch maintains its own Switch Connectivity Object and all Fabric-wide List Objects. If FC-SP Zoning is used, a Client Switch maintains only the subset of the Active Zone Set that it requires to enforce the current Fabric Zoning configuration. De Santi, et al. Standards Track [Page 74] RFC 5324 MIB for FC-SP September 2008 'autonomous' - the Switch operates as an Autonomous Switch. An Autonomous Switch maintains its own Switch Connectivity Object and all Fabric-wide List Objects. This is the same as 'client' except that if FC-SP Zoning is used, an Autonomous Switch maintains a complete copy of the Fabric Zoning Database. 'server' - the Switch operates as a Server Switch. A Server Switch maintains all Fabric-wide List Objects and the Switch Connectivity Objects of each Switch in the Fabric. If FC-SP Zoning is used, a Server Switch maintains a complete copy of the Fabric Zoning Database." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 113." ::= { t11FcSpPoSwMembEntry 5 } t11FcSpPoSwMembAuthBehaviour OBJECT-TYPE SYNTAX BITS { mustAuthenticate(0), rejectIsFailure(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "The authentication behaviour of the Switch: 'mustAuthenticate' - if this bit is set, all connections between this Switch and neighbor Switches must be authenticated. 'rejectIsFailure' - if this bit is set, the rejection of an AUTH_Negotiate message must be considered as an authentication failure by this Switch." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 114." ::= { t11FcSpPoSwMembEntry 6 } t11FcSpPoSwMembAttribute OBJECT-TYPE SYNTAX T11FcSpAlphaNumNameOrAbsent MAX-ACCESS read-only STATUS current DESCRIPTION "The name of an active Attribute Policy Object that is defined for this Switch, or the zero-length string. The De Santi, et al. Standards Track [Page 75] RFC 5324 MIB for FC-SP September 2008 zero-length string indicates that no Attribute Policy Object is defined for this Switch." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoSwMembEntry 7 } -- -- Node Entries in Active Node Membership List Objects -- t11FcSpPoNoMembTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNoMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Node Entries in active Node Membership List Objects. One Node Membership List Object is represented by all of the rows of this table that have the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." ::= { t11FcSpPoActive 4 } t11FcSpPoNoMembEntry OBJECT-TYPE SYNTAX T11FcSpPoNoMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Node Entry within the active Node Membership List Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNoMembNodeNameType, t11FcSpPoNoMembNodeName } ::= { t11FcSpPoNoMembTable 1 } T11FcSpPoNoMembEntry ::= SEQUENCE { t11FcSpPoNoMembNodeNameType T11FcSpPolicyNameType, t11FcSpPoNoMembNodeName FcNameIdOrZero, t11FcSpPoNoMembFlags BITS, t11FcSpPoNoMembCtAccessIndex Unsigned32, t11FcSpPoNoMembAttribute T11FcSpAlphaNumNameOrAbsent } t11FcSpPoNoMembNodeNameType OBJECT-TYPE De Santi, et al. Standards Track [Page 76] RFC 5324 MIB for FC-SP September 2008 SYNTAX T11FcSpPolicyNameType { nodeName(1), restrictedNodeName(2), portName(3), restrictedPortName(4), wildcard(5), restrictedWildcard(6) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of this object is 'wildcard' or 'restrictedWildcard', this Node Entry applies to Nodes not explicitly named in the Node Membership List Object. Otherwise, the combination of this object and t11FcSpPoNoMembNodeName specify the name of this Node Entry in the active Node Membership List Object. A Node is identified by its Node Name or by one or more of its Port Names. Restricted membership means that a Node is not allowed to be connected to the Fabric unless allowed by a specific Switch Connectivity Object. Unrestricted membership means that a Node is allowed to be connected to the Fabric unless disallowed by a specific Switch Connectivity Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 116." ::= { t11FcSpPoNoMembEntry 1 } t11FcSpPoNoMembNodeName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of t11FcSpPoNoMembNodeNameType is 'wildcard' or 'restrictedWildcard', this object has the value '0000000000000000'h. Otherwise, the combination of t11FcSpPoNoMembNodeNameType and this object specify the name of this Node Entry is the active Node Membership List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 116." De Santi, et al. Standards Track [Page 77] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpPoNoMembEntry 2 } t11FcSpPoNoMembFlags OBJECT-TYPE SYNTAX BITS { scsiEnclosureAccess(0), authenticationRequired(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Configurable options in respect to the administration of Policy Objects at this Node: 'scsiEnclosureAccess' - the Node is allowed to control any Switch through SCSI Enclosure Services if this bit is set. If a Switch does not support SCSI Enclosure Services, this bit is ignored. 'authenticationRequired' - the Node is required to authenticate itself to any Switch to which it is connected if and only if this bit is set." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 118." ::= { t11FcSpPoNoMembEntry 3 } t11FcSpPoNoMembCtAccessIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of this object is zero, then access by this Node to Generic Services is not limited by a Common Transport Access Specifier. Otherwise, the limits are specified by the set of Common Transport Access Descriptors contained in those rows of the t11FcSpPoCtDescrTable for the same Fabric and for which the value of t11FcSpPoCtDescrSpecifierIndex is the same as the value of this object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and tables 118/119/120/121." ::= { t11FcSpPoNoMembEntry 4 } t11FcSpPoNoMembAttribute OBJECT-TYPE De Santi, et al. Standards Track [Page 78] RFC 5324 MIB for FC-SP September 2008 SYNTAX T11FcSpAlphaNumNameOrAbsent MAX-ACCESS read-only STATUS current DESCRIPTION "The name of an active Attribute Policy Object that is defined for this Node, or the zero-length string. The zero-length string indicates that no Attribute Policy Object is defined for this Node." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 116." ::= { t11FcSpPoNoMembEntry 5 } -- -- -- Common Transport Access Descriptors -- t11FcSpPoCtDescrTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoCtDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Common Transport Access Descriptors being used within active Policy Objects. A Common Transport Access Specifier is a list of Common Transport Access Descriptors that specify whether a Node is allowed to access a Generic Service or Sub-Server. An active Common Transport Access Specifier is represented by all rows of this table that have the same values of fcmInstanceIndex, t11FcSpPoFabricIndex, and t11FcSpPoCtDescrSpecifierIndex." ::= { t11FcSpPoActive 5 } t11FcSpPoCtDescrEntry OBJECT-TYPE SYNTAX T11FcSpPoCtDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Common Transport Access Descriptor of an active Common Transport Access Specifier used within the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, De Santi, et al. Standards Track [Page 79] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoCtDescrSpecifierIndex, t11FcSpPoCtDescrIndex } ::= { t11FcSpPoCtDescrTable 1 } T11FcSpPoCtDescrEntry ::= SEQUENCE { t11FcSpPoCtDescrSpecifierIndex Unsigned32, t11FcSpPoCtDescrIndex Unsigned32, t11FcSpPoCtDescrFlags BITS, t11FcSpPoCtDescrGsType OCTET STRING, t11FcSpPoCtDescrGsSubType OCTET STRING } t11FcSpPoCtDescrSpecifierIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Common Transport Access Specifier within a Fabric." ::= { t11FcSpPoCtDescrEntry 1 } t11FcSpPoCtDescrIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Common Transport Access Descriptor within a Common Transport Access Specifier." ::= { t11FcSpPoCtDescrEntry 2 } t11FcSpPoCtDescrFlags OBJECT-TYPE SYNTAX BITS { allow(0), gsTypeWildcard(1), gsSubTypeWildcard(2), readOnly(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The flag bits that specify how access is to be limited by this Common Transport Access Descriptor: - allow -- access to the specified Generic Service and Server is allowed if this bit is set, and is to be denied if this bit is not set. - gsTypeWildcard -- if this bit is set, the Generic Service De Santi, et al. Standards Track [Page 80] RFC 5324 MIB for FC-SP September 2008 to be allowed/denied is specified by the value of t11FcSpPoCtDescrGsType. If this bit is set, then the gsSubTypeWildcard bit must not be set. - gsSubTypeWildcard -- if this bit is set, the Generic Service to be allowed/denied is specified by the value of t11FcSpPoCtDescrGsSubType. If this bit is set, then the gsTypeWildcard bit must not be set. - readOnly -- if this bit is set, then access is to be granted only for reading." ::= { t11FcSpPoCtDescrEntry 3 } t11FcSpPoCtDescrGsType OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The GS_Type of the Generic Service (e.g., the FC-GS-5 Management Service) that is subject to access control. This value is ignored if the gsTypeWildcard bit is not set in the corresponding value of t11FcSpPoCtDescrFlags." REFERENCE "- Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, section 4.3.2.4." ::= { t11FcSpPoCtDescrEntry 4 } t11FcSpPoCtDescrGsSubType OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The GS_Subtype of the Generic Server (e.g., the Fabric Zone Server) that is subject to access control. This value is ignored if the gsSubTypeWildcard bit is not set in the corresponding value of t11FcSpPoCtDescrFlags." REFERENCE "- Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, section 4.3.2.5." ::= { t11FcSpPoCtDescrEntry 5 } -- -- -- Switches/Nodes in Active Switch Connectivity Objects -- t11FcSpPoSwConnTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoSwConnEntry De Santi, et al. Standards Track [Page 81] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of active Switch Connectivity Objects. A Switch Connectivity Object defines to which other Switches or Nodes a particular Switch may/may not be connected at the Node level and/or at the Port level." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6.1, tables 123/124." ::= { t11FcSpPoActive 6 } t11FcSpPoSwConnEntry OBJECT-TYPE SYNTAX T11FcSpPoSwConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains the name of either a Switch or a Node with which any port of a particular Switch, or a particular port of that Switch, is allowed or not allowed to be connected. The particular Switch is on the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoSwConnSwitchName, t11FcSpPoSwConnAllowedType, t11FcSpPoSwConnPortNameOrAll, t11FcSpPoSwConnAllowedIndex } ::= { t11FcSpPoSwConnTable 1 } T11FcSpPoSwConnEntry ::= SEQUENCE { t11FcSpPoSwConnSwitchName FcNameIdOrZero, t11FcSpPoSwConnAllowedType INTEGER, t11FcSpPoSwConnPortNameOrAll FcNameIdOrZero, t11FcSpPoSwConnAllowedIndex Unsigned32, t11FcSpPoSwConnAllowedNameType T11FcSpPolicyNameType, t11FcSpPoSwConnAllowedName T11FcSpPolicyName } t11FcSpPoSwConnSwitchName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the particular Switch for which this Switch De Santi, et al. Standards Track [Page 82] RFC 5324 MIB for FC-SP September 2008 Connectivity Object specifies topology restrictions." ::= { t11FcSpPoSwConnEntry 1 } t11FcSpPoSwConnAllowedType OBJECT-TYPE SYNTAX INTEGER { switch(1), node(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies whether this row refers to Switch-to-Switch or Switch-to-Node connectivity, i.e., whether the corresponding instance of t11FcSpPoSwConnAllowedName specifies the name of a Switch or the name of a Node." ::= { t11FcSpPoSwConnEntry 2 } t11FcSpPoSwConnPortNameOrAll OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(0 | 8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies either the particular port to which this topology restriction applies, or if the value is the zero-length string, that the topology restriction applies to all ports on the particular Switch. In the FC-SP Policy Database, restrictions for a particular port are formatted within a Port Connectivity Entry of a Switch Connectivity Object, whereas restrictions for all ports on the Switch are specified in the main part of a Switch Connectivity Object, i.e., not in a Port Connectivity Entry." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6.1, tables 123/124." ::= { t11FcSpPoSwConnEntry 3 } t11FcSpPoSwConnAllowedIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "When multiple rows in this table apply to the same port(s) in the same Switch's Switch Connectivity Object, this object provides a unique index value to distinguish between such rows." ::= { t11FcSpPoSwConnEntry 4 } De Santi, et al. Standards Track [Page 83] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoSwConnAllowedNameType OBJECT-TYPE SYNTAX T11FcSpPolicyNameType { nodeName(1), restrictedNodeName(2), portName(3), restrictedPortName(4), wildcard(5), restrictedWildcard(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of this object is 'wildcard' or 'restrictedWildcard', this row specifies whether connectivity is allowed/not allowed with entities not explicitly named by other rows. Otherwise, the combination of t11FcSpPoSwConnAllowedNameType and t11FcSpPoSwConnAllowedName specify the name of: - a Switch (if t11FcSpPoSwConnAllowedType = 'switch'), or - a Node (if t11FcSpPoSwConnAllowedType = 'node') to which connectivity is: - allowed by 'nodeName' and 'portName', - not allowed by 'restrictedNodeName' and 'restrictedPortName'." ::= { t11FcSpPoSwConnEntry 5 } t11FcSpPoSwConnAllowedName OBJECT-TYPE SYNTAX T11FcSpPolicyName (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of t11FcSpPoSwConnAllowedNameType is 'wildcard' or 'restrictedWildcard', this object has the value '0000000000000000'h. Otherwise, the combination of t11FcSpPoSwConnAllowedNameType and t11FcSpPoSwConnAllowedName specify the name of: - a Switch (if t11FcSpPoSwConnAllowedType = 'switch'), or - a Node (if t11FcSpPoSwConnAllowedType = 'node') to which connectivity is allowed/restricted." ::= { t11FcSpPoSwConnEntry 6 } De Santi, et al. Standards Track [Page 84] RFC 5324 MIB for FC-SP September 2008 -- -- IP Management Entries in Active IP Management List Objects -- t11FcSpPoIpMgmtTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoIpMgmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of IP Management Entries in active IP Management List Objects. An IP Management List Object is a Fabric-wide Policy Object that describes which IP hosts are allowed to manage a Fabric. One IP Management List Object is represented by all of the rows of this table that have the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7" ::= { t11FcSpPoActive 7 } t11FcSpPoIpMgmtEntry OBJECT-TYPE SYNTAX T11FcSpPoIpMgmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one IP Management Entry within the active IP Management List Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. The Policy Object Name of an IP Management Entry Policy Object is either an IPv6 Address Range or an IPv4 Address Range, where in each case, the range is specified as two addresses: the low and high ends of the range. In particular, since the Policy Object Name in this situation can only be an IPv6 Address Range or an IPv4 Address Range, it is represented here by three MIB objects defined as a (InetAddressType, InetAddress, InetAddress) tuple, in which the first address is the low end of the range, the second address is the high end of the range, and both addresses are of the type designated by InetAddressType. In theory, the use of t11FcSpPoIpMgmtEntryNameLow and t11FcSpPoIpMgmtEntryNameHigh (which both have the syntax De Santi, et al. Standards Track [Page 85] RFC 5324 MIB for FC-SP September 2008 of InetAddress) in the INDEX could cause the need for excessively long OIDs. In practice, this can't happen because FC-SP doesn't allow these objects to be specified as DNS names." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoIpMgmtEntryNameType, t11FcSpPoIpMgmtEntryNameLow, t11FcSpPoIpMgmtEntryNameHigh } ::= { t11FcSpPoIpMgmtTable 1 } T11FcSpPoIpMgmtEntry ::= SEQUENCE { t11FcSpPoIpMgmtEntryNameType InetAddressType, t11FcSpPoIpMgmtEntryNameLow InetAddress, t11FcSpPoIpMgmtEntryNameHigh InetAddress, t11FcSpPoIpMgmtWkpIndex Unsigned32, t11FcSpPoIpMgmtAttribute T11FcSpAlphaNumNameOrAbsent } t11FcSpPoIpMgmtEntryNameType OBJECT-TYPE SYNTAX InetAddressType -- INTEGER { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The combination of t11FcSpPoIpMgmtNameType, t11FcSpPoIpMgmtNameLow, and t11FcSpPoIpMgmtNameHigh specify the Internet address range of this IP Management Entry in the IP Management List Object. The FC-SP specification does not allow the use of a DNS domain name to specify the address at the lower end or at the higher end of the Internet address range, nor does it allow the specification of a zone index. Therefore, the type of address must be one of: 'ipv4', or 'ipv6'." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 7.1.7.1 & 7.1.2, tables 103/126." ::= { t11FcSpPoIpMgmtEntry 1 } t11FcSpPoIpMgmtEntryNameLow OBJECT-TYPE SYNTAX InetAddress (SIZE(4 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The lower end of an Internet address range. The type of this address is given by the corresponding instance of t11FcSpPoIpMgmtEntryNameType. De Santi, et al. Standards Track [Page 86] RFC 5324 MIB for FC-SP September 2008 The combination of t11FcSpPoIpMgmtNameType, t11FcSpPoIpMgmtNameLow, and t11FcSpPoIpMgmtNameHigh specify the Internet address range of this IP Management Entry in the IP Management List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 7.1.7.1 & 7.1.2, tables 103/126." ::= { t11FcSpPoIpMgmtEntry 2 } t11FcSpPoIpMgmtEntryNameHigh OBJECT-TYPE SYNTAX InetAddress (SIZE(4 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The higher end of an Internet address range. The type of this address is given by the corresponding instance of t11FcSpPoIpMgmtEntryNameType. The combination of t11FcSpPoIpMgmtNameType, t11FcSpPoIpMgmtNameLow, and t11FcSpPoIpMgmtNameHigh specify the Internet address range of this IP Management Entry in the IP Management List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 7.1.7.1 & 7.1.2, tables 103/126." ::= { t11FcSpPoIpMgmtEntry 3 } t11FcSpPoIpMgmtWkpIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the restrictions for IP management access by IP hosts in this range of IP addresses, specified as the set of Well-Known Protocols Access Descriptors contained in those rows of the t11FcSpPoWkpDescrTable for which the value of t11FcSpPoWkpDescrSpecifierIndex is the same as the value of this object. A value of zero indicates that this IP Management Entry does not identify a Well-Known Protocols Access Specifier." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and tables 127/129." ::= { t11FcSpPoIpMgmtEntry 4 } De Santi, et al. Standards Track [Page 87] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoIpMgmtAttribute OBJECT-TYPE SYNTAX T11FcSpAlphaNumNameOrAbsent MAX-ACCESS read-only STATUS current DESCRIPTION "The name of an active Attribute Policy Object that is defined for this IP Management entry or the zero-length string. The zero-length string indicates that no Attribute Policy Object is defined for this IP Management entry." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 128." ::= { t11FcSpPoIpMgmtEntry 5 } -- -- Well-Known Protocol Access Descriptors -- t11FcSpPoWkpDescrTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoWkpDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the Well-Known Protocol Access Descriptors being used within active Policy Objects. A Well-Known Protocol Access Specifier is a list of Well-Known Protocol Access Descriptors each of which specifies a protocol number, a port number, and/or various flags specifying how IP management access is restricted. A Well-Known Protocol Transport Access Specifier is represented by all rows of this table that have the same values of fcmInstanceIndex, t11FcSpPoFabricIndex, and t11FcSpPoWkpDescrSpecifierIndex." ::= { t11FcSpPoActive 8 } t11FcSpPoWkpDescrEntry OBJECT-TYPE SYNTAX T11FcSpPoWkpDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Well-Known Protocol Access Descriptor of a Well-Known Protocol Access Specifier used within the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex." De Santi, et al. Standards Track [Page 88] RFC 5324 MIB for FC-SP September 2008 INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoWkpDescrSpecifierIndex, t11FcSpPoWkpDescrIndex } ::= { t11FcSpPoWkpDescrTable 1 } T11FcSpPoWkpDescrEntry ::= SEQUENCE { t11FcSpPoWkpDescrSpecifierIndex Unsigned32, t11FcSpPoWkpDescrIndex Unsigned32, t11FcSpPoWkpDescrFlags BITS, t11FcSpPoWkpDescrWkpNumber Unsigned32, t11FcSpPoWkpDescrDestPort InetPortNumber } t11FcSpPoWkpDescrSpecifierIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Well-Known Protocol Access Specifier within a Fabric." ::= { t11FcSpPoWkpDescrEntry 1 } t11FcSpPoWkpDescrIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Well-Known Protocol Access Descriptor within a Well-Known Protocol Access Specifier." ::= { t11FcSpPoWkpDescrEntry 2 } t11FcSpPoWkpDescrFlags OBJECT-TYPE SYNTAX BITS { allow(0), wkpWildcard(1), destPortWildcard(2), readOnly(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The flag bits that specify how access is to be limited by this Well-Known Protocol Access Descriptor: - allow -- IP management access using this protocol/port is allowed if this bit is set, and to be denied if this bit is not set. De Santi, et al. Standards Track [Page 89] RFC 5324 MIB for FC-SP September 2008 - wkpWildcard -- if this bit is set, the IP Protocol number of the Well-Known Protocol to be allowed/denied is specified by the value of t11FcSpPoWkpDescrWkpNumber. - destPortWildcard -- if this bit is set, the Destination (TCP/UDP) Port number of the Well-Known Protocol to be allowed/denied is specified by the value of t11FcSpPoWkpDescrDestPort. - readOnly -- if this bit is set, then access is to be granted only for reading." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 131." ::= { t11FcSpPoWkpDescrEntry 3 } t11FcSpPoWkpDescrWkpNumber OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "When the 'wkpWildcard' bit is set in the corresponding instance of t11FcSpPoWkpDescrFlags, this object specifies the IP protocol number of the Well-Known Protocol." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 131. - http://www.iana.org/assignments/protocol-numbers." ::= { t11FcSpPoWkpDescrEntry 4 } t11FcSpPoWkpDescrDestPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "When the 'destPortWildcard' bit is set in the corresponding instance of t11FcSpPoWkpDescrFlags, this object specifies the Destination (TCP/UDP) Port number of the Well-Known Protocol. When the 'destPortWildcard' bit is reset, this object is ignored (and can have the value zero)." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 131. - http://www.iana.org/assignments/port-numbers." ::= { t11FcSpPoWkpDescrEntry 5 } De Santi, et al. Standards Track [Page 90] RFC 5324 MIB for FC-SP September 2008 -- -- Attribute Entries in Active Attribute Policy Objects -- t11FcSpPoAttribTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the Attribute Policy Objects being used within active Policy Objects. In the FC-SP Policy Database, each Attribute Policy Object consists of an Attribute Object Name and a set of Attribute Entries. An active Attribute Policy Object is represented by all the Attribute Entries in this table that have the same value of t11FcSpPoAttribName." ::= { t11FcSpPoActive 9 } t11FcSpPoAttribEntry OBJECT-TYPE SYNTAX T11FcSpPoAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row contains information specific to an Attribute Entry contained within an Attribute Policy Object that is active within the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. For some types of Attribute Policy Objects, it is valuable to break out some semantically significant parts of the Policy Object's value into their own individual MIB objects; for example, to extract the one or more individual Authentication Protocol Identifiers and associated Authentication Protocol Parameters out of an Attribute Object containing a 'AUTH_Negotiate Message Payload'. For such types, another MIB table is defined to hold the extracted values in MIB objects specific to the Attribute Policy Object's type. In such cases, the t11FcSpPoAttribExtension object in this table points to the other MIB table. If the value of one Attribute Entry is too large (more than 256 bytes) to be contained within the value of one instance of t11FcSpPoAttribValue, then one row in this table contains the first 256 bytes, and one (or more) other row(s) in this table contain the rest of the value." De Santi, et al. Standards Track [Page 91] RFC 5324 MIB for FC-SP September 2008 INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoAttribName, t11FcSpPoAttribEntryIndex, t11FcSpPoAttribPartIndex } ::= { t11FcSpPoAttribTable 1 } T11FcSpPoAttribEntry ::= SEQUENCE { t11FcSpPoAttribName T11FcSpAlphaNumName, t11FcSpPoAttribEntryIndex Unsigned32, t11FcSpPoAttribPartIndex Unsigned32, t11FcSpPoAttribType Unsigned32, t11FcSpPoAttribValue OCTET STRING, t11FcSpPoAttribExtension OBJECT IDENTIFIER } t11FcSpPoAttribName OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the Attribute Policy Object containing one or more Attribute Entries." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1 and table 133." ::= { t11FcSpPoAttribEntry 1 } t11FcSpPoAttribEntryIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to distinguish this Attribute Entry from other Attribute Entries contained in the same Attribute Policy Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 133/134." ::= { t11FcSpPoAttribEntry 2 } t11FcSpPoAttribPartIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "When the value of an Attribute Entry is shorter than 257 bytes, the whole value is contained in one instance of De Santi, et al. Standards Track [Page 92] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoAttribValue, and the value of this object is 1. If the value of an Attribute Entry is longer than 256 bytes, then that value is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part, which is shorter if necessary, with each such part contained in a separate row of this table, and the value of this object is set to the part number. That is, this object has the value of 1 for bytes 0-255, the value of 2 for bytes 256-511, etc." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 134/135." ::= { t11FcSpPoAttribEntry 3 } t11FcSpPoAttribType OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The type of attribute. The first type to be defined is: t11FcSpPoAttribType t11FcSpPoAttribValue =================== ==================== '00000001'h The AUTH_Negotiate Message Payload " REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 134/135 and table 10." ::= { t11FcSpPoAttribEntry 4 } t11FcSpPoAttribValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of an Attribute Entry is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part, which is shorter if necessary, and each such part is contained in a separate instance of this object. The value of this object is independent of whether some parts of its value are broken out into separate MIB objects pointed to by the corresponding instance of t11FcSpPoAttribExtension." REFERENCE De Santi, et al. Standards Track [Page 93] RFC 5324 MIB for FC-SP September 2008 "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 134/135 and table 10." ::= { t11FcSpPoAttribEntry 5 } t11FcSpPoAttribExtension OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "For some types of Attribute Policy Object, the value of this MIB object points to type-specific MIB objects that contain individual/broken-out parts of the Attribute Policy Object's value. If this object doesn't point to such type-specific MIB objects, then it contains the value: zeroDotZero. In particular, when the value of t11FcSpPoAttribType indicates 'AUTH_Negotiate Message Payload', one or more Authentication Protocol Identifiers and their associated Authentication Protocol Parameters are embedded within the value of the corresponding instance of t11FcSpPoAttribValue; MIB objects to contain these individual values are defined in the t11FcSpPoAuthProtTable. Thus, for an 'AUTH_Negotiate Message Payload' Attribute, the value of this object contains an OID within the t11FcSpPoAuthProtTable, e.g., of the whole table, of an individual row, or of an individual instance within the table." ::= { t11FcSpPoAttribEntry 6 } -- -- Auth. Protocol Parameters in Active Attribute Policy Objects -- t11FcSpPoAuthProtTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoAuthProtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Authentication Protocol Identifier and Authentication Protocol Parameters that are embedded in Attribute Policy Objects being used within active Policy Objects. This table is used for Attribute Entries of Attribute Policy Objects for which the value of t11FcSpPoAttribType indicates 'AUTH_Negotiate Message Payload' and the value of t11FcSpPoAttribExtension contains the OID of this table." De Santi, et al. Standards Track [Page 94] RFC 5324 MIB for FC-SP September 2008 REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 5.3.2 & 7.1.8.1, tables 134/135 and tables 10/11." ::= { t11FcSpPoActive 10 } t11FcSpPoAuthProtEntry OBJECT-TYPE SYNTAX T11FcSpPoAuthProtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about an Authentication Protocol that is extracted out of the Attribute Entry (identified by t11FcSpPoAttribEntryIndex) of the Policy Attribute Object (identified by t11FcSpPoAttribName), which is active within the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. If the value of one Attribute Protocol Parameters string is too large (more than 256 bytes) to be contained within the value of one instance of t11FcSpPoAuthProtParams, then one row in this table contains the first 256 bytes, and one (or more) other row(s) in this table contain the rest of the value." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoAttribName, t11FcSpPoAttribEntryIndex, t11FcSpPoAuthProtIdentifier, t11FcSpPoAuthProtPartIndex } ::= { t11FcSpPoAuthProtTable 1 } T11FcSpPoAuthProtEntry ::= SEQUENCE { t11FcSpPoAuthProtIdentifier Unsigned32, t11FcSpPoAuthProtPartIndex Unsigned32, t11FcSpPoAuthProtParams OCTET STRING } t11FcSpPoAuthProtIdentifier OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Authentication Protocol Identifier: 1 = DH-CHAP 2 = FCAP 3 = FCPAP De Santi, et al. Standards Track [Page 95] RFC 5324 MIB for FC-SP September 2008 4 = IKEv2 5 = IKEv2-AUTH 240 thru 255 = Vendor Specific Protocols all other values are 'Reserved' (by T11)." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.3.2, table 11." ::= { t11FcSpPoAuthProtEntry 1 } t11FcSpPoAuthProtPartIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "When the value of an Attribute Protocol Parameters string is shorter than 257 bytes, the whole value is contained in one instance of t11FcSpPoAuthProtParams, and the value of this object is 1. (This includes the case when the Attribute Protocol Parameters string is zero bytes in length.) If the value of an Authentication Protocol Parameters string is longer than 256 bytes, then that value is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part, which is shorter if necessary, with each such part contained in a separate row of this table, and the value of this object is set to the part number. That is, this object has the value of 1 for bytes 0-255, the value of 2 for bytes 256-511, etc." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.3.2, table 10." ::= { t11FcSpPoAuthProtEntry 2 } t11FcSpPoAuthProtParams OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of an Authentication Protocol Parameters string is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part, which is shorter if necessary, and each such part is contained in a separate instance of this object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, De Santi, et al. Standards Track [Page 96] RFC 5324 MIB for FC-SP September 2008 Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.3.2, table 10." ::= { t11FcSpPoAuthProtEntry 3 } -- -- Part 2 - Activate/De-Activate Operations -- -- -- Objects to Invoke Activate/De-Activate Operations -- t11FcSpPoOperTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that allows Activate and Deactivate operations to be invoked for FC-SP Policies on various Fabrics. Activating a new policy configuration is a two-step process: 1) create a single Policy Summary Object as a set of rows in the t11FcSpPoNaSummaryTable specifying a set of Policy Objects that describe the new configuration; and 2) activate that Policy Summary Object using the t11FcSpPoOperActivate object defined in this table. Deactivating the current policy configuration is a one-step process: the current Policy Summary Object is deactivated using the t11FcSpPoOperDeActivate object." ::= { t11FcSpPoOperations 1 } t11FcSpPoOperEntry OBJECT-TYPE SYNTAX T11FcSpPoOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry allows an Activate and/or Deactivate operation to be invoked on a particular Fabric, which is managed as part of the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex } ::= { t11FcSpPoOperTable 1 } T11FcSpPoOperEntry ::= SEQUENCE { t11FcSpPoOperActivate T11FcSpAlphaNumName, De Santi, et al. Standards Track [Page 97] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoOperDeActivate T11FcSpAlphaNumName, t11FcSpPoOperResult INTEGER, t11FcSpPoOperFailCause SnmpAdminString } t11FcSpPoOperActivate OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS read-write STATUS current DESCRIPTION "Writing the name of a Policy Summary Object into this object is a request to activate the policy configuration described by the combination of all rows in t11FcSpPoNaSummaryTable that have that name as their value of t11FcSpPoNaSummaryName and are for the same Fabric. Before issuing such a request, the relevant rows in the t11FcSpPoNaSummaryTable must exist and represent a complete and consistent Policy Summary Object. If they do not, the request will fail, with t11FcSpPoOperResult having the 'badSummaryObject' value. When read, the value of this object is always the zero- length string. Writing to this object does not delete (or in any way affect) any rows in the MIB tables for non-active Policy Objects." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3.6.2" ::= { t11FcSpPoOperEntry 1 } t11FcSpPoOperDeActivate OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS read-write STATUS current DESCRIPTION "Writing the current value of t11FcSpPoPolicySummaryObjName into this object (for a particular Fabric) is a request to deactivate that Fabric's current policy configuration. Writing any other value into this object is an error (e.g., 'wrongValue'). When read, the value of this object is always the zero- length string." De Santi, et al. Standards Track [Page 98] RFC 5324 MIB for FC-SP September 2008 REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3.6.3" ::= { t11FcSpPoOperEntry 2 } t11FcSpPoOperResult OBJECT-TYPE SYNTAX INTEGER { activateSuccess(1), badSummaryObject(2), activateFailure(3), deactivateSuccess(4), deactivateFailure(5), inProgress(6), none(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the status/result of the last activation/deactivation that was invoked via the corresponding instance of t11FcSpPoOperActivate or t11FcSpPoOperDeActivate. When the value of this object is 'inProgress', the values of the corresponding instances of t11FcSpPoOperActivate and t11FcSpPoOperDeActivate cannot be modified. The value 'badSummaryObject' indicates an activation request that did not name a complete and consistent Policy Summary Object. The value 'none' indicates activation/deactivation has not been attempted since the last restart of the management system." ::= { t11FcSpPoOperEntry 3 } t11FcSpPoOperFailCause OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual message indicating the reason for the most recent activation/deactivation failure, or the zero-length string if no information is available (e.g., because the corresponding instance of t11FcSpPoOperResult has the value 'none'). De Santi, et al. Standards Track [Page 99] RFC 5324 MIB for FC-SP September 2008 When the corresponding instance of t11FcSpPoOperResult is either 'activateFailure' or 'deactivateFailure', the value of this object indicates the reason for that failure." ::= { t11FcSpPoOperEntry 4 } -- -- Part 3 - Non-Active Policy Objects -- -- -- Non-Active Policy Summary Objects Available for Activation -- t11FcSpPoNaSummaryTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of non-active Policy Summary Objects available to be activated. The functionality of this table deviates slightly from FC-SP in that FC-SP specifies that the only Policy Summary Object is the Active one, i.e., FC-SP does not store non-active Policy Summary Objects in the Policy Database. Instead, FC-SP requires a new Policy Summary Object to be created for, and embedded within, every Activate (APS) request. Thus, the newly created Policy Summary Object outlasts the APS request only as the new active Policy Summary Object and only if the APS succeeds. In contrast, the Activate operation provided by this MIB module consists of two steps: 1) create a non-active Policy Summary Object as a set of entries in this table describing a new configuration; 2) activate a Policy Summary Object (stored as a set of entries in this table) using t11FcSpPoOperActivate. These two steps are only loosely connected, i.e., the result of the first operation is a non-active Policy Summary Object that is retained (in this table) even if it isn't immediately activated. Even after an attempt to activate it succeeds or fails, a non-active Policy Summary Object is not deleted, but is retained and still available for subsequent modification/re-use." ::= { t11FcSpPoNonActive 1 } t11FcSpPoNaSummaryEntry OBJECT-TYPE De Santi, et al. Standards Track [Page 100] RFC 5324 MIB for FC-SP September 2008 SYNTAX T11FcSpPoNaSummaryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one non-active Policy Object within a non-active Policy Summary Object defined for potential use on the Fabric identified by t11FcSpPoFabricIndex, and managed within the Fibre Channel management instance identified by fcmInstanceIndex. A non-active Policy Summary Object is described by a set of entries in this table that have the same value of t11FcSpPoNaSummaryName. As and when a Policy Summary Object is activated using the t11FcSpPoOperActivate object, if the activation is successful, existing rows (if any) in MIB tables for active Policy Objects are deleted and replaced by the appropriate new set of rows. Existing rows in this table and/or in other tables for non-active Policy Objects are not affected by the activate operation. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.3 and table 104." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaSummaryName, t11FcSpPoNaSummaryPolicyType, t11FcSpPoNaSummaryPolicyIndex } ::= { t11FcSpPoNaSummaryTable 1 } T11FcSpPoNaSummaryEntry ::= SEQUENCE { t11FcSpPoNaSummaryName T11FcSpAlphaNumName, t11FcSpPoNaSummaryPolicyType T11FcSpPolicyObjectType, t11FcSpPoNaSummaryPolicyIndex Unsigned32, t11FcSpPoNaSummaryPolicyNameType T11FcSpPolicyNameType, t11FcSpPoNaSummaryPolicyName T11FcSpPolicyName, t11FcSpPoNaSummaryHashStatus T11FcSpHashCalculationStatus, t11FcSpPoNaSummaryHashFormat T11FcSpPolicyHashFormat, t11FcSpPoNaSummaryHashValue T11FcSpPolicyHashValue, t11FcSpPoNaSummaryRowStatus RowStatus } t11FcSpPoNaSummaryName OBJECT-TYPE SYNTAX T11FcSpAlphaNumName De Santi, et al. Standards Track [Page 101] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the non-active Policy Summary Object that contains this Policy Object." ::= { t11FcSpPoNaSummaryEntry 1 } t11FcSpPoNaSummaryPolicyType OBJECT-TYPE SYNTAX T11FcSpPolicyObjectType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 'Identifier' (i.e., the type) of this Policy Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.3.1 and table 104." ::= { t11FcSpPoNaSummaryEntry 2 } t11FcSpPoNaSummaryPolicyIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique integer value to distinguish this Policy Object from any others that have the same type and that are contained in the same Policy Summary Object." ::= { t11FcSpPoNaSummaryEntry 3 } t11FcSpPoNaSummaryPolicyNameType OBJECT-TYPE SYNTAX T11FcSpPolicyNameType { nodeName(1), alphaNumericName(7) } MAX-ACCESS read-create STATUS current DESCRIPTION "The combination of t11FcSpPoNaSummaryPolicyNameType and t11FcSpPoNaSummaryPolicyName specify the name of the non-active Policy Object identified by this row. The type of name must be 'nodeName' if the value of the corresponding instance of t11FcSpPoNaSummaryPolicyType is 'switchConnectivity', or 'alphaNumericName' otherwise." ::= { t11FcSpPoNaSummaryEntry 4 } t11FcSpPoNaSummaryPolicyName OBJECT-TYPE SYNTAX T11FcSpPolicyName De Santi, et al. Standards Track [Page 102] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS read-create STATUS current DESCRIPTION "The combination of t11FcSpPoNaSummaryPolicyNameType and t11FcSpPoNaSummaryPolicyName specify the name of the non-active Policy Object identified by this row." ::= { t11FcSpPoNaSummaryEntry 5 } t11FcSpPoNaSummaryHashStatus OBJECT-TYPE SYNTAX T11FcSpHashCalculationStatus MAX-ACCESS read-create STATUS current DESCRIPTION "When read, the value of this object is either: correct -- the corresponding instance of t11FcSpPoNaSummaryHashValue contains the correct value; or stale -- the corresponding instance of t11FcSpPoNaSummaryHashValue contains a stale (possibly incorrect) value; Writing a value of 'calculate' is a request to re-calculate and update the value of the corresponding instance of t11FcSpPoNaSummaryHashValue. Writing a value of 'correct' or 'stale' to this object is an error (e.g., 'wrongValue')." DEFVAL { stale } ::= { t11FcSpPoNaSummaryEntry 6 } t11FcSpPoNaSummaryHashFormat OBJECT-TYPE SYNTAX T11FcSpPolicyHashFormat MAX-ACCESS read-only STATUS current DESCRIPTION "The format of this Policy Object's hash value as contained in the corresponding instance of the t11FcSpPoNaSummaryHashValue object." DEFVAL { '00000001'h } ::= { t11FcSpPoNaSummaryEntry 7 } t11FcSpPoNaSummaryHashValue OBJECT-TYPE SYNTAX T11FcSpPolicyHashValue MAX-ACCESS read-only STATUS current DESCRIPTION "The hash value of this Policy Object, in the format identified by the corresponding instance of the t11FcSpPoNaSummaryHashFormat object." De Santi, et al. Standards Track [Page 103] RFC 5324 MIB for FC-SP September 2008 DEFVAL { "" } ::= { t11FcSpPoNaSummaryEntry 8 } t11FcSpPoNaSummaryRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Before a row in this table can have 'active' status, a non-Active Policy Object must already be represented in the table corresponding to the value of t11FcSpPoNaSummaryPolicyType with the name given by the combination of t11FcSpPoNaSummaryPolicyNameType and t11FcSpPoNaSummaryPolicyName. If such a Policy Object gets deleted from the relevant table, the row in this table must also get deleted. When a row has 'active' status, the only write-able MIB objects in this table are t11FcSpPoNaSummaryHashStatus and t11FcSpPoNaSummaryRowStatus." ::= { t11FcSpPoNaSummaryEntry 9 } -- -- Non-Active Switch Membership List Objects -- t11FcSpPoNaSwListTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaSwListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of non-active Switch Membership List Objects." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 108." ::= { t11FcSpPoNonActive 2 } t11FcSpPoNaSwListEntry OBJECT-TYPE SYNTAX T11FcSpPoNaSwListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one non-active Switch Membership List Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre De Santi, et al. Standards Track [Page 104] RFC 5324 MIB for FC-SP September 2008 Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaSwListName } ::= { t11FcSpPoNaSwListTable 1 } T11FcSpPoNaSwListEntry ::= SEQUENCE { t11FcSpPoNaSwListName T11FcSpAlphaNumName, t11FcSpPoNaSwListFabricName FcNameIdOrZero, t11FcSpPoNaSwListRowStatus RowStatus } t11FcSpPoNaSwListName OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the Switch Membership List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 108." ::= { t11FcSpPoNaSwListEntry 1 } t11FcSpPoNaSwListFabricName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The administratively specified Fabric_Name. This value is meaningful only when static Domain_IDs are used in a Fabric. If Static Domain_IDs are not used, the Fabric_Name is dynamically determined, in which case the value of this object can be '0000000000000000'h or the zero-length string." REFERENCE "- t11FamConfigDomainId, T11-FC-FABRIC-ADDR-MGR-MIB, Fibre Channel Fabric Address Manager MIB, RFC 4439; - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, table 108." ::= { t11FcSpPoNaSwListEntry 2 } t11FcSpPoNaSwListRowStatus OBJECT-TYPE De Santi, et al. Standards Track [Page 105] RFC 5324 MIB for FC-SP September 2008 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time. If a row in this table is deleted, any row in the t11FcSpPoNaSwMembTable for the same Switch Membership List Object will also get deleted." ::= { t11FcSpPoNaSwListEntry 3 } -- -- Switch Entries in Non-Active Switch Membership List Objects -- t11FcSpPoNaSwMembTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaSwMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Switch Entries in non-active Switch Membership List Objects." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoNonActive 3 } t11FcSpPoNaSwMembEntry OBJECT-TYPE SYNTAX T11FcSpPoNaSwMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Switch that is listed in a Switch Entry of a non-active Switch Membership List Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. A row cannot exist unless there is a row in t11FcSpPoNaSwListTable for the given Switch Membership List Object, i.e., the row in t11FcSpPoNaSwListTable for a Switch Membership List Object must be created before (or simultaneously with) a row in this table for a Switch Entry in that Switch Membership List Object, and when a row in t11FcSpPoNaSwListTable is deleted, all rows in this table for Switch Entries in that Switch Membership List De Santi, et al. Standards Track [Page 106] RFC 5324 MIB for FC-SP September 2008 Object also get deleted. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaSwListName, t11FcSpPoNaSwMembSwitchNameType, t11FcSpPoNaSwMembSwitchName } ::= { t11FcSpPoNaSwMembTable 1 } T11FcSpPoNaSwMembEntry ::= SEQUENCE { t11FcSpPoNaSwMembSwitchNameType T11FcSpPolicyNameType, t11FcSpPoNaSwMembSwitchName FcNameIdOrZero, t11FcSpPoNaSwMembFlags BITS, t11FcSpPoNaSwMembDomainID FcDomainIdOrZero, t11FcSpPoNaSwMembPolicyDataRole INTEGER, t11FcSpPoNaSwMembAuthBehaviour BITS, t11FcSpPoNaSwMembAttribute T11FcSpAlphaNumNameOrAbsent, t11FcSpPoNaSwMembRowStatus RowStatus } t11FcSpPoNaSwMembSwitchNameType OBJECT-TYPE SYNTAX T11FcSpPolicyNameType { nodeName(1), restrictedNodeName(2), wildcard(5), restrictedWildcard(6) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of this object is 'nodeName' or 'restrictedNodeName', then the combination of this object and t11FcSpPoNaSwMembSwitchName specify the Switch Name of this Switch Entry. The membership is restricted or unrestricted based on the name type. Restricted membership means that the Switch is not allowed to be part of the Fabric unless allowed by a specific Switch Connectivity Object. Unrestricted membership means that the Switch is allowed to be part of the Fabric unless disallowed by a specific Switch Connectivity Object. The values of 'wildcard' and 'restrictedWildcard' provide the means to specify whether to allow/deny membership for Switches not explicitly named in the Switch Membership De Santi, et al. Standards Track [Page 107] RFC 5324 MIB for FC-SP September 2008 List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoNaSwMembEntry 1 } t11FcSpPoNaSwMembSwitchName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of t11FcSpPoSwMembSwitchNameType is 'wildcard' or 'restrictedWildcard', this object has the value '0000000000000000'h. Otherwise, the combination of t11FcSpPoNaSwMembSwitchNameType and this object specify the Switch Name of this Switch Entry." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoNaSwMembEntry 2 } t11FcSpPoNaSwMembFlags OBJECT-TYPE SYNTAX BITS { staticDomainID(0), insistentDomainID(1), serialPortsAccess(2), physicalPortsAccess(3), managerRole(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "Configurable options in respect to the administration of Policy Objects at this Switch: 'staticDomainID' - the Switch uses the 'Static Domain_IDs behavior' (as defined in FC-SW-4) when this bit is set. This bit should have the same setting for all Switches in a Fabric's Switch Membership List Object, or else the Fabric will partition. If this bit is set, the 'insistentDomainID' bit must not be set. 'insistentDomainID' - if this bit is set, the Switch uses the 'Insistent Domain_IDs behavior' (as defined in De Santi, et al. Standards Track [Page 108] RFC 5324 MIB for FC-SP September 2008 FC-SW-4), and the 'staticDomainID' bit must not be set. 'serialPortsAccess' - the Switch allows management through serial ports when and only when this bit is set. 'physicalPortsAccess' - the Switch allows management through the physical panel when and only when this bit is set. 'managerRole' - the Switch is allowed to change the Fabric Policy configuration (on receipt of any of the EACA, ESFC, EUFC, ACA, SFC, or UFC SW_ILSs) if this bit is set." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 112." ::= { t11FcSpPoNaSwMembEntry 3 } t11FcSpPoNaSwMembDomainID OBJECT-TYPE SYNTAX FcDomainIdOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The Domain_ID to be used when either the 'staticDomainID' bit or the 'insistentDomainID' bit is set in the corresponding value of t11FcSpPoNaSwMembFlags." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and tables 111 and 112." ::= { t11FcSpPoNaSwMembEntry 4 } t11FcSpPoNaSwMembPolicyDataRole OBJECT-TYPE SYNTAX INTEGER { client(1), autonomous(2), server(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The role of the Switch in terms of which Policy data it retains/maintains: 'client' - the Switch operates as a Client Switch. A Client Switch maintains its own Switch Connectivity Object and all Fabric-wide List Objects. If FC-SP De Santi, et al. Standards Track [Page 109] RFC 5324 MIB for FC-SP September 2008 Zoning is used, a Client Switch maintains only the subset of the Active Zone Set that it requires to enforce the current Fabric Zoning configuration. 'autonomous' - the Switch operates as an Autonomous Switch. An Autonomous Switch maintains its own Switch Connectivity Object and all Fabric-wide List Objects. This is the same as 'client' except that if FC-SP Zoning is used, an Autonomous Switch maintains a complete copy of the Fabric Zoning Database. 'server' - the Switch operates as a Server Switch. A Server Switch maintains all Fabric-wide List Objects and the Switch Connectivity Objects of each Switch in the Fabric. If FC-SP Zoning is used, a Server Switch maintains a complete copy of the Fabric Zoning Database." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 113." ::= { t11FcSpPoNaSwMembEntry 5 } t11FcSpPoNaSwMembAuthBehaviour OBJECT-TYPE SYNTAX BITS { mustAuthenticate(0), rejectIsFailure(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "The authentication behaviour of the Switch: 'mustAuthenticate' - if this bit is set, all connections between this Switch and neighbor Switches must be authenticated. 'rejectIsFailure' - if this bit is set, the rejection of an AUTH_Negotiate message must be considered as an authentication failure by this Switch." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 114." ::= { t11FcSpPoNaSwMembEntry 6 } t11FcSpPoNaSwMembAttribute OBJECT-TYPE SYNTAX T11FcSpAlphaNumNameOrAbsent MAX-ACCESS read-create De Santi, et al. Standards Track [Page 110] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "The name of a non-active Attribute Policy Object that is defined for this Switch. The zero-length string indicates that no non-active Attribute Policy Object is defined for this Switch. The effect of having no rows in the t11FcSpPoNaAttribTable for which the value of t11FcSpPoNaAttribName is the same as the value of this object, is the same as this object's value being the zero-length string." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 110." ::= { t11FcSpPoNaSwMembEntry 7 } t11FcSpPoNaSwMembRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time. A row cannot exist unless there is a row in the t11FcSpPoNaSwListTable for the Switch Membership List Object containing the Switch Entry for this Switch, i.e., the row in t11FcSpPoNaSwListTable for a Switch Membership List Object must be created before (or simultaneously) with a row in this table for a Switch Entry in that Switch Membership List Object; and when a row in t11FcSpPoNaSwListTable is deleted, any row in this table for a Switch Entry in that Switch Membership List Object also gets deleted." ::= { t11FcSpPoNaSwMembEntry 8 } -- -- Node Entries in Non-Active Node Membership List Objects -- t11FcSpPoNaNoMembTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaNoMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Node Entries in non-active Node Membership List Objects. De Santi, et al. Standards Track [Page 111] RFC 5324 MIB for FC-SP September 2008 One Node Membership List Object is represented by all the rows in this table that have the same value of t11FcSpPoNaNoMembListName." ::= { t11FcSpPoNonActive 4 } t11FcSpPoNaNoMembEntry OBJECT-TYPE SYNTAX T11FcSpPoNaNoMembEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Node Entry of a non-active Node Membership List Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaNoMembListName, t11FcSpPoNaNoMembNodeNameType, t11FcSpPoNaNoMembNodeName } ::= { t11FcSpPoNaNoMembTable 1 } T11FcSpPoNaNoMembEntry ::= SEQUENCE { t11FcSpPoNaNoMembListName T11FcSpAlphaNumName, t11FcSpPoNaNoMembNodeNameType T11FcSpPolicyNameType, t11FcSpPoNaNoMembNodeName FcNameIdOrZero, t11FcSpPoNaNoMembFlags BITS, t11FcSpPoNaNoMembCtAccessIndex Unsigned32, t11FcSpPoNaNoMembAttribute T11FcSpAlphaNumNameOrAbsent, t11FcSpPoNaNoMembRowStatus RowStatus } t11FcSpPoNaNoMembListName OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the non-active Node Membership List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 116." ::= { t11FcSpPoNaNoMembEntry 1 } t11FcSpPoNaNoMembNodeNameType OBJECT-TYPE De Santi, et al. Standards Track [Page 112] RFC 5324 MIB for FC-SP September 2008 SYNTAX T11FcSpPolicyNameType { nodeName(1), restrictedNodeName(2), portName(3), restrictedPortName(4), wildcard(5), restrictedWildcard(6) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of this object is 'wildcard' or 'restrictedWildcard', this Node Entry applies to Nodes not explicitly named in the Node Membership List Object. Otherwise, the combination of this object and t11FcSpPoNaNoMembNodeName specify the name of this Node Entry in the active Node Membership List Object. A Node is identified by its Node Name or by one or more of its Port Names. Restricted membership means that a Node is not allowed to be connected to the Fabric unless allowed by a specific Switch Connectivity Object. Unrestricted membership means that a Node is allowed to be connected to the Fabric unless disallowed by a specific Switch Connectivity Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 116." ::= { t11FcSpPoNaNoMembEntry 2 } t11FcSpPoNaNoMembNodeName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the value of t11FcSpPoNaNoMembNodeNameType is 'wildcard' or 'restrictedWildcard', this object has the value '0000000000000000'h. Otherwise, the combination of t11FcSpPoNaNoMembNodeNameType and this object specify the name of this Node Entry is the active Node Membership List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 116." De Santi, et al. Standards Track [Page 113] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpPoNaNoMembEntry 3 } t11FcSpPoNaNoMembFlags OBJECT-TYPE SYNTAX BITS { scsiEnclosureAccess(0), authenticationRequired(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Configurable options in respect to the administration of Policy Objects at this Node: 'scsiEnclosureAccess' - the Node is allowed to control any Switch through SCSI Enclosure Services if this bit is set. If a Switch does not support SCSI Enclosure Services, this bit is ignored. 'authenticationRequired' - the Node is required to authenticate itself to any Switch to which it is connected if and only if this bit is set." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 118." ::= { t11FcSpPoNaNoMembEntry 4 } t11FcSpPoNaNoMembCtAccessIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is zero, then access by this Node to Generic Services is not limited by a Common Transport Access Specifier. Otherwise, the limits are specified by the set of Common Transport Access Descriptors contained in those rows of the t11FcSpPoNaCtDescrTable for which the value of t11FcSpPoNaCtDescrSpecifierIndex is the same as the value of this object. No such rows in t11FcSpPoNaCtDescrTable have the same effect as this object's value being zero." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and tables 118/119/120/121." ::= { t11FcSpPoNaNoMembEntry 5 } De Santi, et al. Standards Track [Page 114] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoNaNoMembAttribute OBJECT-TYPE SYNTAX T11FcSpAlphaNumNameOrAbsent MAX-ACCESS read-create STATUS current DESCRIPTION "The name of a non-active Attribute Policy Object that is defined for this Node. The zero-length string indicates that no non-active Attribute Policy Object is defined for this Node. The effect of having no rows in the t11FcSpPoNaAttribTable for which the value of t11FcSpPoNaAttribName is the same as the value of this object, is the same as this object's value being the zero-length string." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.4.1 and table 116." ::= { t11FcSpPoNaNoMembEntry 6 } t11FcSpPoNaNoMembRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpPoNaNoMembEntry 7 } -- -- -- Non-Active Common Transport Access Descriptors -- t11FcSpPoNaCtDescrTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaCtDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Common Transport Access Descriptors referenced by non-active Policy Objects. A Common Transport Access Specifier is a list of Common Transport Access Descriptors that specify whether a Node is allowed to access a Generic Service or Sub-Server. A non-active Common Transport Access Specifier is represented by all rows of this table that have the same De Santi, et al. Standards Track [Page 115] RFC 5324 MIB for FC-SP September 2008 values of fcmInstanceIndex, t11FcSpPoFabricIndex, and t11FcSpPoNaCtDescrSpecifierIndex." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.5" ::= { t11FcSpPoNonActive 5 } t11FcSpPoNaCtDescrEntry OBJECT-TYPE SYNTAX T11FcSpPoNaCtDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Common Transport Access Descriptor of an non-active Common Transport Access Specifier used within the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaCtDescrSpecifierIndex, t11FcSpPoNaCtDescrIndex } ::= { t11FcSpPoNaCtDescrTable 1 } T11FcSpPoNaCtDescrEntry ::= SEQUENCE { t11FcSpPoNaCtDescrSpecifierIndex Unsigned32, t11FcSpPoNaCtDescrIndex Unsigned32, t11FcSpPoNaCtDescrFlags BITS, t11FcSpPoNaCtDescrGsType OCTET STRING, t11FcSpPoNaCtDescrGsSubType OCTET STRING, t11FcSpPoNaCtDescrRowStatus RowStatus } t11FcSpPoNaCtDescrSpecifierIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Common Transport Access Specifier within a Fabric." ::= { t11FcSpPoNaCtDescrEntry 1 } t11FcSpPoNaCtDescrIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current De Santi, et al. Standards Track [Page 116] RFC 5324 MIB for FC-SP September 2008 DESCRIPTION "An index value that uniquely identifies a particular Common Transport Access Descriptor within a Common Transport Access Specifier." ::= { t11FcSpPoNaCtDescrEntry 2 } t11FcSpPoNaCtDescrFlags OBJECT-TYPE SYNTAX BITS { allow(0), gsTypeWildcard(1), gsSubTypeWildcard(2), readOnly(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The flag bits that specify how access is to be limited by this Common Transport Access Descriptor: - allow -- access to the specified Generic Service and Server is allowed if this bit is set, and is to be denied if this bit is not set. - gsTypeWildcard -- if this bit is set, the Generic Service to be allowed/denied is specified by the value of t11FcSpPoNaCtDescrGsType, and the gsSubTypeWildcard bit must not also be set. - gsSubTypeWildcard -- if this bit is set, the Generic Service to be allowed/denied is specified by the value of t11FcSpPoNaCtDescrGsSubType, and the gsTypeWildcard bit must not also be set. - readOnly -- if this bit is set, then access is to be granted only for reading." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.5.1, and tables 117, 118, and 120." ::= { t11FcSpPoNaCtDescrEntry 3 } t11FcSpPoNaCtDescrGsType OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS current DESCRIPTION "The GS_Type of the Generic Service (e.g., the FC-GS-5 Management Service) that is subject to access control. De Santi, et al. Standards Track [Page 117] RFC 5324 MIB for FC-SP September 2008 This value is ignored if the gsTypeWildcard bit is not set in the corresponding value of t11FcSpPoNaCtDescrFlags." REFERENCE "- ANSI INCITS 427-2006, Fibre Channel - Generic Services-5 (FC-GS-5), section 4.3.2.4. - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.5.1 and table 120." ::= { t11FcSpPoNaCtDescrEntry 4 } t11FcSpPoNaCtDescrGsSubType OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1)) MAX-ACCESS read-create STATUS current DESCRIPTION "The GS_Subtype of the Generic Server (e.g., the Fabric Zone Server) that is subject to access control. This value is ignored if the gsSubTypeWildcard bit is not set in the corresponding value of t11FcSpPoNaCtDescrFlags." REFERENCE "- ANSI INCITS 427-2006, Fibre Channel - Generic Services-5 (FC-GS-5), section 4.3.2.5. - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.5.1 and table 120." ::= { t11FcSpPoNaCtDescrEntry 5 } t11FcSpPoNaCtDescrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpPoNaCtDescrEntry 6 } -- -- Switches/Nodes in Non-Active Switch Connectivity Objects -- t11FcSpPoNaSwConnTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaSwConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of non-active Switch Connectivity Objects. De Santi, et al. Standards Track [Page 118] RFC 5324 MIB for FC-SP September 2008 A Switch Connectivity Object defines to which other Switches or Nodes a particular Switch may/may not be connected at the Node level and/or at the Port level." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6." ::= { t11FcSpPoNonActive 6 } t11FcSpPoNaSwConnEntry OBJECT-TYPE SYNTAX T11FcSpPoNaSwConnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains the name of a Switch/Node with which any port of a particular Switch on a particular Fabric, or a particular port on that Switch, is allowed or not allowed to be connected. The particular Fabric is identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaSwConnSwitchName, t11FcSpPoNaSwConnAllowedType, t11FcSpPoNaSwConnPortNameOrAll, t11FcSpPoNaSwConnAllowedIndex } ::= { t11FcSpPoNaSwConnTable 1 } T11FcSpPoNaSwConnEntry ::= SEQUENCE { t11FcSpPoNaSwConnSwitchName FcNameIdOrZero, t11FcSpPoNaSwConnAllowedType INTEGER, t11FcSpPoNaSwConnPortNameOrAll FcNameIdOrZero, t11FcSpPoNaSwConnAllowedIndex Unsigned32, t11FcSpPoNaSwConnAllowedNameType T11FcSpPolicyNameType, t11FcSpPoNaSwConnAllowedName FcNameIdOrZero, t11FcSpPoNaSwConnRowStatus RowStatus } t11FcSpPoNaSwConnSwitchName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 119] RFC 5324 MIB for FC-SP September 2008 "The name of the Switch for which this Switch Connectivity Object specifies topology restrictions." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6.1 and table 123." ::= { t11FcSpPoNaSwConnEntry 1 } t11FcSpPoNaSwConnAllowedType OBJECT-TYPE SYNTAX INTEGER { switch(1), node(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies whether this row refers to an 'Allowed Switch' that concerns Switch-to-Switch connectivity or an 'Allowed Node' that concerns Switch-to-Node connectivity. Consequently, this object's value indicates whether the corresponding instance of t11FcSpPoNaSwConnAllowedName specifies the name of a Switch or the name of a Node." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6.1 and table 123." ::= { t11FcSpPoNaSwConnEntry 2 } t11FcSpPoNaSwConnPortNameOrAll OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE(0 | 8)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies either the particular port on which this topology restriction applies, or if the value is the zero-length string, that the topology restriction applies to all ports of the Switch. In other words, if this object's value contains the name of a port, then this row represents a 'Port Connectivity Entry' (as described in FC-SP) within a Switch Connectivity Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6.1 and tables 123/124." ::= { t11FcSpPoNaSwConnEntry 3 } t11FcSpPoNaSwConnAllowedIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible De Santi, et al. Standards Track [Page 120] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "When multiple rows in this table refer to different 'Allowed Switches' or to different 'Allowed Nodes' for the same port(s) in the same Switch Connectivity Object, this object provides a unique index value to distinguish between such rows." ::= { t11FcSpPoNaSwConnEntry 4 } t11FcSpPoNaSwConnAllowedNameType OBJECT-TYPE SYNTAX T11FcSpPolicyNameType { nodeName(1), restrictedNodeName(2), portName(3), restrictedPortName(4), wildcard(5), restrictedWildcard(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is 'wildcard' or 'restrictedWildcard', this row specifies whether connectivity is allowed/not allowed with entities not explicitly named by other rows. Otherwise, the combination of t11FcSpPoNaSwConnAllowedNameType and t11FcSpPoNaSwConnAllowedName specify the name of: - a Switch (if t11FcSpPoNaSwConnAllowedType = 'switch'), or - a Node (if t11FcSpPoNaSwConnAllowedType = 'node') to which connectivity is allowed/not allowed." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6.1 and tables 123/124." ::= { t11FcSpPoNaSwConnEntry 5 } t11FcSpPoNaSwConnAllowedName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS read-create STATUS current DESCRIPTION "If t11FcSpPoNaSwConnAllowedNameType has the value 'wildcard' or 'restrictedWildcard', this object has the value '0000000000000000'h. De Santi, et al. Standards Track [Page 121] RFC 5324 MIB for FC-SP September 2008 Otherwise, the combination of t11FcSpPoNaSwConnAllowedNameType and t11FcSpPoNaSwConnAllowedName specify the name of: - a Switch (if t11FcSpPoNaSwConnAllowedType = 'switch'), or - a Node (if t11FcSpPoNaSwConnAllowedType = 'node') to which connectivity is allowed/not allowed." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.6.1 and tables 123/124." ::= { t11FcSpPoNaSwConnEntry 6 } t11FcSpPoNaSwConnRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpPoNaSwConnEntry 7 } -- -- IP Management Entries in Non-Active IP Management List Objects -- t11FcSpPoNaIpMgmtTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaIpMgmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of IP Management Entries in non-active IP Management List Objects. The IP Management List Object is a Fabric-wide Policy Object that describes which IP hosts are allowed to manage a Fabric. One non-active IP Management List Object is represented by all rows of this table that have the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." ::= { t11FcSpPoNonActive 7 } t11FcSpPoNaIpMgmtEntry OBJECT-TYPE SYNTAX T11FcSpPoNaIpMgmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one IP Management De Santi, et al. Standards Track [Page 122] RFC 5324 MIB for FC-SP September 2008 entry within a non-active IP Management List Object for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. The Policy Object Name of an IP Management Entry Policy Object is either an IPv6 Address Range or an IPv4 Address Range. In a Fabric's database of Policy Objects, every Policy Object Name, including these Internet address ranges, is represented as a (T11FcSpPolicyNameType, T11FcSpPolicyName) tuple. In contrast, this MIB module uses the conventional MIB syntax for IP addresses, and therefore represents the Policy Object Name of an IP Management Entry Policy Object as a (InetAddressType, InetAddress, InetAddress) tuple. In theory, the use of t11FcSpPoNaIpMgmtEntryNameLow and t11FcSpPoNaIpMgmtEntryNameHigh, which have the syntax of InetAddress, in the INDEX could cause the need for excessively long OIDs. In practice, this can't happen because FC-SP doesn't allow these objects to be specified as DNS names. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaIpMgmtListName, t11FcSpPoNaIpMgmtEntryNameType, t11FcSpPoNaIpMgmtEntryNameLow, t11FcSpPoNaIpMgmtEntryNameHigh } ::= { t11FcSpPoNaIpMgmtTable 1 } T11FcSpPoNaIpMgmtEntry ::= SEQUENCE { t11FcSpPoNaIpMgmtListName T11FcSpAlphaNumName, t11FcSpPoNaIpMgmtEntryNameType InetAddressType, t11FcSpPoNaIpMgmtEntryNameLow InetAddress, t11FcSpPoNaIpMgmtEntryNameHigh InetAddress, t11FcSpPoNaIpMgmtWkpIndex Unsigned32, t11FcSpPoNaIpMgmtAttribute T11FcSpAlphaNumNameOrAbsent, t11FcSpPoNaIpMgmtRowStatus RowStatus } t11FcSpPoNaIpMgmtListName OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS not-accessible STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 123] RFC 5324 MIB for FC-SP September 2008 "The name of a non-active Node Membership List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 125." ::= { t11FcSpPoNaIpMgmtEntry 1 } t11FcSpPoNaIpMgmtEntryNameType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The combination of t11FcSpPoNaIpMgmtEntryNameType, t11FcSpPoNaIpMgmtNameLow, and t11FcSpPoNaIpMgmtNameHigh specify the Internet address range of this IP Management Entry in the IP Management List Object. The FC-SP specification does not allow this address to be specified using a DNS domain name, nor does it allow the specification of zone indexes. Therefore, the type of address must be one of: 'ipv4' or 'ipv6'." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 7.1.7.1 and table 126." ::= { t11FcSpPoNaIpMgmtEntry 2 } t11FcSpPoNaIpMgmtEntryNameLow OBJECT-TYPE SYNTAX InetAddress (SIZE(4 | 16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The lower end of an Internet address range. The type of this address is given by the corresponding instance of t11FcSpPoNaIpMgmtEntryNameType. The combination of t11FcSpPoNaIpMgmtEntryNameType, t11FcSpPoNaIpMgmtNameLow, and t11FcSpPoIpMgmtNameHigh specify the Internet address range of this IP Management Entry in the IP Management List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 7.1.7.1 and table 126." ::= { t11FcSpPoNaIpMgmtEntry 3 } t11FcSpPoNaIpMgmtEntryNameHigh OBJECT-TYPE SYNTAX InetAddress (SIZE(4 | 16)) De Santi, et al. Standards Track [Page 124] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The higher end of an Internet address range. The type of this address is given by the corresponding instance of t11FcSpPoNaIpMgmtEntryNameType. The combination of t11FcSpPoNaIpMgmtEntryNameType, t11FcSpPoNaIpMgmtNameLow, and t11FcSpPoNaIpMgmtNameHigh specify the Internet address range of this IP Management Entry in the IP Management List Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 7.1.7.1 and table 126." ::= { t11FcSpPoNaIpMgmtEntry 4 } t11FcSpPoNaIpMgmtWkpIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the restrictions for IP management access by IP hosts in this range of IP addresses. The restrictions are specified as the set of Well-Known Protocols Access Descriptors contained in those rows of the t11FcSpPoNaWkpDescrTable for which the value of t11FcSpPoNaWkpDescrSpecifierIndx is the same as the value of this object. If there are no such rows or if the value of this object is zero, then this IP Management Entry does not identify any Well-Known Protocols Access restrictions." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and tables 127/129." ::= { t11FcSpPoNaIpMgmtEntry 5 } t11FcSpPoNaIpMgmtAttribute OBJECT-TYPE SYNTAX T11FcSpAlphaNumNameOrAbsent MAX-ACCESS read-create STATUS current DESCRIPTION "The name of a non-active Attribute Policy Object that is defined for this IP Management entry. The zero-length string indicates that no non-active Attribute Policy Object is defined for it. De Santi, et al. Standards Track [Page 125] RFC 5324 MIB for FC-SP September 2008 The effect of having no rows in the t11FcSpPoNaAttribTable for which the value of t11FcSpPoNaAttribName is the same as the value of this object, is the same as this object's value being the zero-length string." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 128." ::= { t11FcSpPoNaIpMgmtEntry 6 } t11FcSpPoNaIpMgmtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpPoNaIpMgmtEntry 7 } -- -- Non-Active Well-Known Protocol Access Descriptors -- t11FcSpPoNaWkpDescrTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaWkpDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the Well-Known Protocol Access Descriptors referenced from non-active Policy Objects. A Well-Known Protocol Access Specifier is a list of Well-Known Protocol Access Descriptors each of which specifies a protocol number, a port number, and/or various flags specifying how IP management access is restricted. A non-active Well-Known Protocol Transport Access Specifier is represented by all rows of this table that have the same values of fcmInstanceIndex, t11FcSpPoFabricIndex, and t11FcSpPoNaWkpDescrSpecifierIndx." ::= { t11FcSpPoNonActive 8 } t11FcSpPoNaWkpDescrEntry OBJECT-TYPE SYNTAX T11FcSpPoNaWkpDescrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Well-Known De Santi, et al. Standards Track [Page 126] RFC 5324 MIB for FC-SP September 2008 Protocol Access Descriptor of a non-active Well-Known Protocol Access Specifier used within the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaWkpDescrSpecifierIndx, t11FcSpPoNaWkpDescrIndex } ::= { t11FcSpPoNaWkpDescrTable 1 } T11FcSpPoNaWkpDescrEntry ::= SEQUENCE { t11FcSpPoNaWkpDescrSpecifierIndx Unsigned32, t11FcSpPoNaWkpDescrIndex Unsigned32, t11FcSpPoNaWkpDescrFlags BITS, t11FcSpPoNaWkpDescrWkpNumber Unsigned32, t11FcSpPoNaWkpDescrDestPort InetPortNumber, t11FcSpPoNaWkpDescrRowStatus RowStatus } t11FcSpPoNaWkpDescrSpecifierIndx OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular non-active Well-Known Protocol Access Specifier within a Fabric." ::= { t11FcSpPoNaWkpDescrEntry 1 } t11FcSpPoNaWkpDescrIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Well-Known Protocol Access Descriptor within a non-active Well-Known Protocol Access Specifier." ::= { t11FcSpPoNaWkpDescrEntry 2 } t11FcSpPoNaWkpDescrFlags OBJECT-TYPE SYNTAX BITS { allow(0), wkpWildcard(1), destPortWildcard(2), readOnly(3) De Santi, et al. Standards Track [Page 127] RFC 5324 MIB for FC-SP September 2008 } MAX-ACCESS read-create STATUS current DESCRIPTION "The flag bits that specify how access is to be limited by this Well-Known Protocol Access Descriptor: - allow -- IP management access using this protocol/port is allowed if this bit is set, and to be denied if this bit is not set. - wkpWildcard -- if this bit is set, the IP Protocol number of the Well-Known Protocol to be allowed/denied is specified by the value of t11FcSpPoNaWkpDescrWkpNumber. - destPortWildcard -- if this bit is set, the Destination (TCP/UDP) Port number of the Well-Known Protocol to be allowed/denied is specified by the value of t11FcSpPoNaWkpDescrDestPort. - readOnly -- if this bit is set, then access is to be granted only for reading." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 131." ::= { t11FcSpPoNaWkpDescrEntry 3 } t11FcSpPoNaWkpDescrWkpNumber OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "When the 'wkpWildcard' bit is set in the corresponding instance of t11FcSpPoNaWkpDescrFlags, this object specifies the IP protocol number of the Well-Known Protocol." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 131. - http://www.iana.org/assignments/protocol-numbers." ::= { t11FcSpPoNaWkpDescrEntry 4 } t11FcSpPoNaWkpDescrDestPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 128] RFC 5324 MIB for FC-SP September 2008 "When the 'destPortWildcard' bit is set in the corresponding instance of t11FcSpPoNaWkpDescrFlags, this object specifies the Destination (TCP/UDP) Port number of the Well-Known Protocol. When the 'destPortWildcard' bit is reset, this object is ignored (and can have the value zero)." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.7.1 and table 131. - http://www.iana.org/assignments/port-numbers." ::= { t11FcSpPoNaWkpDescrEntry 5 } t11FcSpPoNaWkpDescrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpPoNaWkpDescrEntry 6 } -- -- Attribute Entries in Non-Active Attribute Policy Objects -- t11FcSpPoNaAttribTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the Attribute Policy Objects being used within non-active Policy Objects. A non-active Attribute Policy Object is represented by all the Attribute Entries in this table that have the same value of t11FcSpPoNaAttribName." ::= { t11FcSpPoNonActive 9 } t11FcSpPoNaAttribEntry OBJECT-TYPE SYNTAX T11FcSpPoNaAttribEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Attribute Entry contained within an Attribute Policy Object that is non-active within the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. De Santi, et al. Standards Track [Page 129] RFC 5324 MIB for FC-SP September 2008 For some types of Attribute Policy Objects, it is valuable to break out some semantically significant parts of the Policy Object's value into their own individual MIB objects; for example, to extract the one or more individual Authentication Protocol Identifiers and associated Authentication Protocol Parameters out of an Attribute containing a 'AUTH_Negotiate Message Payload'. For such types, another MIB table is defined to hold the extracted values in MIB objects specific to the Attribute Policy Object's type. In such cases, the t11FcSpPoNaAttribExtension object in this table points to the other MIB table. If the value of one Attribute Entry is too large (more than 256 bytes) to be contained within the value of one instance of t11FcSpPoNaAttribValue, then one row in this table contains the first 256 bytes, and one (or more) other row(s) in this table contain the rest of the value. The StorageType of a row in this table is specified by the instance of t11FcSpPoStorageType that is INDEX-ed by the same values of fcmInstanceIndex and t11FcSpPoFabricIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaAttribName, t11FcSpPoNaAttribEntryIndex, t11FcSpPoNaAttribPartIndex } ::= { t11FcSpPoNaAttribTable 1 } T11FcSpPoNaAttribEntry ::= SEQUENCE { t11FcSpPoNaAttribName T11FcSpAlphaNumName, t11FcSpPoNaAttribEntryIndex Unsigned32, t11FcSpPoNaAttribPartIndex Unsigned32, t11FcSpPoNaAttribType Unsigned32, t11FcSpPoNaAttribValue OCTET STRING, t11FcSpPoNaAttribExtension OBJECT IDENTIFIER, t11FcSpPoNaAttribRowStatus RowStatus } t11FcSpPoNaAttribName OBJECT-TYPE SYNTAX T11FcSpAlphaNumName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the Attribute Policy Object containing one or more Attribute Entries." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), De Santi, et al. Standards Track [Page 130] RFC 5324 MIB for FC-SP September 2008 February 2007, section 7.1.8.1 and table 133." ::= { t11FcSpPoNaAttribEntry 1 } t11FcSpPoNaAttribEntryIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to distinguish this Attribute Entry from other Attribute Entries contained in the same Attribute Policy Object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 133/134." ::= { t11FcSpPoNaAttribEntry 2 } t11FcSpPoNaAttribPartIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "When the value of an Attribute Entry is shorter than 257 bytes, the whole value is contained in one instance of t11FcSpPoNaAttribValue, and the value of this object is 1. If the value of an Attribute Entry is longer than 256 bytes, then that value is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part which is shorter if necessary, with each such part contained in a separate row of this table, and the value of this object is set to the part number. That is, this object has the value of 1 for bytes 0-255, the value of 2 for bytes 256-511, etc." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 134/135." ::= { t11FcSpPoNaAttribEntry 3 } t11FcSpPoNaAttribType OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "The type of attribute. The first type to be defined is: t11FcSpPoNaAttribType t11FcSpPoNaAttribValue De Santi, et al. Standards Track [Page 131] RFC 5324 MIB for FC-SP September 2008 ===================== ====================== '00000001'h The AUTH_Negotiate Message Payload " REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 134/135 and table 10." ::= { t11FcSpPoNaAttribEntry 4 } t11FcSpPoNaAttribValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an Attribute Entry is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part, which is shorter if necessary, and each such part is contained in a separate instance of this object. When the value of the corresponding instance of t11FcSpPoNaAttribExtension is not zeroDotZero, then the same underlying management data has its value contained both in this object and in the individual/broken-out parts pointed to by t11FcSpPoNaAttribExtension. Thus, after any modification of the underlying management data, e.g., after a Set operation to the value of either MIB representation, then that modification is reflected in the values of both MIB representations." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.1.8.1, tables 134/135 and table 10." ::= { t11FcSpPoNaAttribEntry 5 } t11FcSpPoNaAttribExtension OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "For some types of Attribute Policy Object, the value of this MIB object points to type-specific MIB objects that contain individual/broken-out parts of the Attribute Policy Object's value. If this object doesn't point to such type-specific MIB objects, then it contains the value: zeroDotZero. In particular, when the value of t11FcSpPoNaAttribType indicates 'AUTH_Negotiate Message Payload', one or more De Santi, et al. Standards Track [Page 132] RFC 5324 MIB for FC-SP September 2008 Authentication Protocol Identifiers and their associated Authentication Protocol Parameters are embedded within the value of the corresponding instance of t11FcSpPoNaAttribValue; MIB objects to contain these individual values are defined in the t11FcSpPoAuthProtTable. Thus, for an 'AUTH_Negotiate Message Payload' Attribute, the value of this object would contain the OID of t11FcSpPoNaAuthProtTable. When the value of this object is not zeroDotZero, then the same underlying management data has its value contained in both the individual/broken-out parts pointed to by this object and in the corresponding instance of t11FcSpPoNaAttribValue. Thus, after any modification of the underlying management data, e.g., after a Set operation to the value of either MIB representation, then that modification is reflected in the values of both MIB representations." ::= { t11FcSpPoNaAttribEntry 6 } t11FcSpPoNaAttribRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpPoNaAttribEntry 7 } -- -- Auth. Protocol Parameters in Non-Active Attribute Policy Objects -- t11FcSpPoNaAuthProtTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoNaAuthProtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Authentication Protocol Identifier and Authentication Protocol Parameters that are embedded in Attribute Policy Objects being used within non-active Policy Objects. This table is used for Attribute Entries of Attribute Policy Objects for which the value of t11FcSpPoNaAttribType indicates 'AUTH_Negotiate Message Payload' and the value of t11FcSpPoNaAttribExtension contains the OID of this table." REFERENCE De Santi, et al. Standards Track [Page 133] RFC 5324 MIB for FC-SP September 2008 "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 5.3.2 & 7.1.8.1, tables 134/135 and tables 10/11." ::= { t11FcSpPoNonActive 10 } t11FcSpPoNaAuthProtEntry OBJECT-TYPE SYNTAX T11FcSpPoNaAuthProtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row contains information about an Authentication Protocol that is extracted out of the Attribute Entry (identified by t11FcSpPoNaAttribEntryIndex) of the non-active Policy Attribute Object (identified by t11FcSpPoNaAttribName) for the Fabric identified by t11FcSpPoFabricIndex and managed within the Fibre Channel management instance identified by fcmInstanceIndex. If the value of one Attribute Protocol Parameters string is too large (more than 256 bytes) to be contained within the value of one instance of t11FcSpPoNaAuthProtParams, then one row in this table contains the first 256 bytes, and one (or more) other row(s) in this table contain the rest of the value. The same underlying management data that is represented in rows of this table is also represented by the corresponding instances of t11FcSpPoNaAttribValue. Thus, after any modification of the underlying management data, e.g., after a Set operation to the value of either MIB representation, then that modification is reflected in the values of both MIB representations." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex, t11FcSpPoNaAttribName, t11FcSpPoNaAttribEntryIndex, t11FcSpPoNaAuthProtIdentifier, t11FcSpPoNaAuthProtPartIndex } ::= { t11FcSpPoNaAuthProtTable 1 } T11FcSpPoNaAuthProtEntry ::= SEQUENCE { t11FcSpPoNaAuthProtIdentifier Unsigned32, t11FcSpPoNaAuthProtPartIndex Unsigned32, t11FcSpPoNaAuthProtParams OCTET STRING, t11FcSpPoNaAuthProtRowStatus RowStatus } t11FcSpPoNaAuthProtIdentifier OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) De Santi, et al. Standards Track [Page 134] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Authentication Protocol Identifier: 1 = DH-CHAP 3 = FCPAP 4 = IKEv2 5 = IKEv2-AUTH 240 thru 255 = Vendor Specific Protocols all other values are 'Reserved' (by T11)." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.3.2, table 11." ::= { t11FcSpPoNaAuthProtEntry 1 } t11FcSpPoNaAuthProtPartIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "When the value of an Attribute Protocol Parameters string is shorter than 257 bytes, the whole value is contained in one instance of t11FcSpPoNaAuthProtParams, and the value of this object is 1. (This includes the case when the Attribute Protocol Parameters string is zero bytes in length.) If the value of an Authentication Protocol Parameters string is longer than 256 bytes, then that value is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part, which is shorter if necessary, with each such part contained in a separate row of this table, and the value of this object is set to the part number. That is, this object has the value of 1 for bytes 0-255, the value of 2 for bytes 256-511, etc." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.3.2, table 10." ::= { t11FcSpPoNaAuthProtEntry 2 } t11FcSpPoNaAuthProtParams OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-create STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 135] RFC 5324 MIB for FC-SP September 2008 "The value of an Authentication Protocol Parameters string is divided up on 256-byte boundaries such that all parts are 256 bytes long except the last part, which is shorter if necessary, and each such part is contained in a separate instance of this object." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 5.3.2, table 10." ::= { t11FcSpPoNaAuthProtEntry 3 } t11FcSpPoNaAuthProtRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpPoNaAuthProtEntry 4 } -- -- Part 4 - Statistics -- t11FcSpPoStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of statistics maintained by FC-SP Security Policy Servers." ::= { t11FcSpPoStatistics 1 } t11FcSpPoStatsEntry OBJECT-TYPE SYNTAX T11FcSpPoStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of statistics for the FC-SP Security Policy Server on the Fabric identified by the value of t11FcSpPoFabricIndex, and managed within the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex } ::= { t11FcSpPoStatsTable 1 } T11FcSpPoStatsEntry ::= SEQUENCE { t11FcSpPoInRequests Counter32, t11FcSpPoInAccepts Counter32, De Santi, et al. Standards Track [Page 136] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoInRejects Counter32 } t11FcSpPoInRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Policy Management Requests (e.g., GPS, APS, etc.) received by this FC-SP Security Policy Server on this Fabric. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3." ::= { t11FcSpPoStatsEntry 1 } t11FcSpPoInAccepts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this FC-SP Security Policy Server sent an Accept CT_IU on this Fabric in response to a received FC-SP Policy Management Request (e.g., GPS, APS, etc.). This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3." ::= { t11FcSpPoStatsEntry 2 } t11FcSpPoInRejects OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that this FC-SP Security Policy Server sent a Reject CT_IU on this Fabric in response to a received FC-SP Policy Management Request (e.g., GPS, APS, etc.). De Santi, et al. Standards Track [Page 137] RFC 5324 MIB for FC-SP September 2008 This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3." ::= { t11FcSpPoStatsEntry 3 } -- -- Part 5 - Control Information & Notifications -- -- -- Control Information -- t11FcSpPoServerAddress OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The WWN of the FC-SP Security Policy Server that received a request that is referenced in a notification." ::= { t11FcSpPoControl 1 } t11FcSpPoControlTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpPoControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control information, including the memory realization of FC-SP Policy Databases, and concerning the generation of notifications due to FC-SP Policy-related events." ::= { t11FcSpPoControl 2 } t11FcSpPoControlEntry OBJECT-TYPE SYNTAX T11FcSpPoControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains control information specific to FC-SP Policy and Policy-related events for the Fabric identified by the value of t11FcSpPoFabricIndex, and managed within the Fibre Channel management instance identified by fcmInstanceIndex." De Santi, et al. Standards Track [Page 138] RFC 5324 MIB for FC-SP September 2008 INDEX { fcmInstanceIndex, t11FcSpPoFabricIndex } ::= { t11FcSpPoControlTable 1 } T11FcSpPoControlEntry ::= SEQUENCE { t11FcSpPoStorageType StorageType, t11FcSpPoNotificationEnable TruthValue, t11FcSpPoLastNotifyType INTEGER, t11FcSpPoRequestSource FcNameIdOrZero, t11FcSpPoReasonCode T11NsGs4RejectReasonCode, t11FcSpPoCtCommandString OCTET STRING, t11FcSpPoReasonCodeExp Unsigned32, t11FcSpPoReasonVendorCode OCTET STRING } t11FcSpPoStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the memory realization of FC-SP Policy Objects and related information for a particular Fabric; specifically, for: - rows created and/or modified for the particular Fabric in these tables: t11FcSpPoNaSummaryTable t11FcSpPoNaSwListTable t11FcSpPoNaSwMembTable t11FcSpPoNaNoMembTable t11FcSpPoNaCtDescrTable t11FcSpPoNaSwConnTable t11FcSpPoNaIpMgmtTable t11FcSpPoNaWkpDescrTable t11FcSpPoNaAttribTable - the activate and deactivate actions invoked through the t11FcSpPoOperActivate and t11FcSpPoOperDeActivate objects for the particular Fabric; and - modified information contained in the same row as an instance of this object. Even if an instance of this object has the value 'permanent(4)', none of the information defined in this MIB module for the given Fabric needs to be writable." ::= { t11FcSpPoControlEntry 1 } De Santi, et al. Standards Track [Page 139] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether the following types of notifications: t11FcSpPoNotifyActivation, t11FcSpPoNotifyActivateFail, t11FcSpPoNotifyDeactivation and t11FcSpPoNotifyDeactivateFail should be generated for this Fabric." ::= { t11FcSpPoControlEntry 2 } t11FcSpPoLastNotifyType OBJECT-TYPE SYNTAX INTEGER { none(1), activation(2), activateFail(3), deactivation(4), deactivateFail(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of which of the following types of notification is currently being/was most recently generated for the Fabric: 'activation' -- t11FcSpPoNotifyActivation 'activateFail' -- t11FcSpPoNotifyActivateFail 'deactivation' -- t11FcSpPoNotifyDeactivation 'deactivateFail' -- t11FcSpPoNotifyDeactivateFail The value 'none' indicates that none of these types of notifications have been generated since the last restart of the network management system, and therefore that the corresponding instances of: t11FcSpPoRequestSource, t11FcSpPoReasonCode, t11FcSpPoCtCommandString, t11FcSpPoReasonCodeExp, and t11FcSpPoReasonVendorCode are irrelevant." ::= { t11FcSpPoControlEntry 3 } t11FcSpPoRequestSource OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS read-only De Santi, et al. Standards Track [Page 140] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "The WWN of the source of the (Activate Policy Summary or Deactivate Policy Summary) request for which the current/most recent notification of the type indicated by the corresponding instance of t11FcSpPoLastNotifyType is being/was generated. If no source is available, the value of this object is the zero-length string." DEFVAL { "" } ::= { t11FcSpPoControlEntry 4 } t11FcSpPoReasonCode OBJECT-TYPE SYNTAX T11NsGs4RejectReasonCode MAX-ACCESS read-only STATUS current DESCRIPTION "The reason code associated with the failure that is indicated when the value of the corresponding instance of t11FcSpPoLastNotifyType is 'activateFail' or 'deactivateFail'. For other values of t11FcSpPoLastNotifyType, the value of this object is 'none(1)'." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3.6.2 & 7.3.6.3" ::= { t11FcSpPoControlEntry 5 } t11FcSpPoCtCommandString OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The binary content of the failed request that is indicated when the value of the corresponding instance of t11FcSpPoLastNotifyType is 'activateFail' or 'deactivateFail'. The content of the request is formatted as an octet string (in network byte order) containing the CT_IU, as described in Table 2 of [FC-GS-5] (including the preamble). For other values of t11FcSpPoLastNotifyType, or if the CT_IU's content is unavailable, the value of this object is the zero-length string. De Santi, et al. Standards Track [Page 141] RFC 5324 MIB for FC-SP September 2008 When the length of this object is 255 octets, it contains the first 255 octets of the CT_IU (in network-byte order)." ::= { t11FcSpPoControlEntry 6 } t11FcSpPoReasonCodeExp OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The reason code explanation associated with the failure that is indicated when the value of the corresponding instance of t11FcSpPoLastNotifyType is 'activateFail' or 'deactivateFail'. For other values of t11FcSpPoLastNotifyType, the value of this object is zero." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3.6.2 & 7.3.6.3" ::= { t11FcSpPoControlEntry 7 } t11FcSpPoReasonVendorCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor-specific reason code associated with the failure that is indicated when the value of the corresponding instance of t11FcSpPoLastNotifyType is 'activateFail' or 'deactivateFail'. For other values of t11FcSpPoLastNotifyType, or if no vendor-specific reason code is available, the value of this object is the zero-length string." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3.6.2 & 7.3.6.3" ::= { t11FcSpPoControlEntry 8 } -- -- Notification definitions -- t11FcSpPoNotifyActivation NOTIFICATION-TYPE OBJECTS { t11FcSpPoServerAddress, De Santi, et al. Standards Track [Page 142] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoPolicySummaryObjName, t11FcSpPoRequestSource } STATUS current DESCRIPTION "This notification is generated whenever a Security Policy Server (indicated by the value of t11FcSpPoServerAddress) successfully completes the execution of an Activate Policy Summary request. The value of t11FcSpPoRequestSource indicates the source of the APS request. The value of t11FcSpPoPolicySummaryObjName indicates the name of the activated Policy Summary Object." ::= { t11FcSpPoMIBNotifications 1 } t11FcSpPoNotifyActivateFail NOTIFICATION-TYPE OBJECTS { t11FcSpPoServerAddress, t11FcSpPoRequestSource, t11FcSpPoCtCommandString, t11FcSpPoReasonCode, t11FcSpPoReasonCodeExp, t11FcSpPoReasonVendorCode } STATUS current DESCRIPTION "This notification is generated whenever a Security Policy Server (indicated by the value of t11FcSpPoServerAddress) fails to complete the execution of an Activate Policy Summary request. The value of t11FcSpPoCtCommandString indicates the rejected request, and the values of t11FcSpPoReasonCode, t11FcSpPoReasonCodeExp, and t11FcSpPoReasonVendorCode indicate the reason for the rejection. The value of t11FcSpPoRequestSource indicates the source of the request." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3.6.2." ::= { t11FcSpPoMIBNotifications 2 } t11FcSpPoNotifyDeactivation NOTIFICATION-TYPE OBJECTS { t11FcSpPoServerAddress, t11FcSpPoRequestSource } STATUS current DESCRIPTION "This notification is generated whenever a Security Policy Server (indicated by the value of t11FcSpPoServerAddress) successfully completes the De Santi, et al. Standards Track [Page 143] RFC 5324 MIB for FC-SP September 2008 execution of a Deactivate Policy Summary request. The value of t11FcSpPoRequestSource indicates the source of the DPS request." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 7.3.6.3." ::= { t11FcSpPoMIBNotifications 3 } t11FcSpPoNotifyDeactivateFail NOTIFICATION-TYPE OBJECTS { t11FcSpPoServerAddress, t11FcSpPoRequestSource, t11FcSpPoCtCommandString, t11FcSpPoReasonCode, t11FcSpPoReasonCodeExp, t11FcSpPoReasonVendorCode } STATUS current DESCRIPTION "This notification is generated whenever a Security Policy Server (indicated by the value of t11FcSpPoServerAddress) fails to complete the execution of a Deactivate Policy Summary request. The value of t11FcSpPoCtCommandString indicates the rejected request, and the values of t11FcSpPoReasonCode, t11FcSpPoReasonCodeExp, and t11FcSpPoReasonVendorCode indicate the reason for the rejection. The value of t11FcSpPoRequestSource indicates the source of the request." ::= { t11FcSpPoMIBNotifications 4 } -- -- Conformance -- t11FcSpPoMIBCompliances OBJECT IDENTIFIER ::= { t11FcSpPoMIBConformance 1 } t11FcSpPoMIBGroups OBJECT IDENTIFIER ::= { t11FcSpPoMIBConformance 2 } t11FcSpPoMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that support the Fabric Policies defined in FC-SP," MODULE -- this module MANDATORY-GROUPS { t11FcSpPoActiveObjectsGroup } De Santi, et al. Standards Track [Page 144] RFC 5324 MIB for FC-SP September 2008 GROUP t11FcSpPoNonActiveObjectsGroup DESCRIPTION "These objects are mandatory for FC-SP Security Policy Servers." GROUP t11FcSpPoNotifyObjectsGroup DESCRIPTION "These objects are mandatory for FC-SP Security Policy Servers." GROUP t11FcSpPoNotificationGroup DESCRIPTION "These notifications are mandatory for FC-SP Security Policy Servers." GROUP t11FcSpPoOperationsObjectsGroup DESCRIPTION "These objects are mandatory only for FC-SP Security Policy Servers that support the activation/deactivation of policies via SNMP." GROUP t11FcSpPoStatsObjectsGroup DESCRIPTION "These objects are optional." -- Write access is not required for any objects in this MIB module: OBJECT t11FcSpPoOperActivate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoOperDeActivate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNotificationEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSummaryPolicyNameType De Santi, et al. Standards Track [Page 145] RFC 5324 MIB for FC-SP September 2008 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSummaryPolicyName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSummaryHashStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSummaryRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwListFabricName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwListRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwMembFlags MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwMembDomainID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwMembPolicyDataRole MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwMembAuthBehaviour MIN-ACCESS read-only DESCRIPTION "Write access is not required." De Santi, et al. Standards Track [Page 146] RFC 5324 MIB for FC-SP September 2008 OBJECT t11FcSpPoNaSwMembAttribute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwMembRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaNoMembFlags MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaNoMembCtAccessIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaNoMembAttribute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaNoMembRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaCtDescrFlags MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaCtDescrGsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaCtDescrGsSubType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaCtDescrRowStatus MIN-ACCESS read-only DESCRIPTION De Santi, et al. Standards Track [Page 147] RFC 5324 MIB for FC-SP September 2008 "Write access is not required." OBJECT t11FcSpPoNaSwConnAllowedNameType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwConnAllowedName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaSwConnRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaIpMgmtWkpIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaIpMgmtAttribute MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaIpMgmtRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaWkpDescrFlags MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaWkpDescrWkpNumber MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaWkpDescrDestPort MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaWkpDescrRowStatus De Santi, et al. Standards Track [Page 148] RFC 5324 MIB for FC-SP September 2008 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaAttribType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaAttribValue MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaAttribRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaAuthProtParams MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpPoNaAuthProtRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FcSpPoMIBCompliances 1 } -- Units of Conformance t11FcSpPoActiveObjectsGroup OBJECT-GROUP OBJECTS { t11FcSpPoPolicySummaryObjName, t11FcSpPoAdminFabricName, t11FcSpPoActivatedTimeStamp, t11FcSpPoSummaryPolicyType, t11FcSpPoSummaryHashFormat, t11FcSpPoSummaryHashValue, t11FcSpPoSwMembSwitchFlags, t11FcSpPoSwMembDomainID, t11FcSpPoSwMembPolicyDataRole, t11FcSpPoSwMembAuthBehaviour, t11FcSpPoSwMembAttribute, t11FcSpPoNoMembFlags, t11FcSpPoNoMembCtAccessIndex, t11FcSpPoNoMembAttribute, De Santi, et al. Standards Track [Page 149] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoCtDescrFlags, t11FcSpPoCtDescrGsType, t11FcSpPoCtDescrGsSubType, t11FcSpPoSwConnAllowedNameType, t11FcSpPoSwConnAllowedName, t11FcSpPoIpMgmtWkpIndex, t11FcSpPoIpMgmtAttribute, t11FcSpPoWkpDescrFlags, t11FcSpPoWkpDescrWkpNumber, t11FcSpPoWkpDescrDestPort, t11FcSpPoAttribType, t11FcSpPoAttribValue, t11FcSpPoAttribExtension, t11FcSpPoAuthProtParams } STATUS current DESCRIPTION "A collection of MIB objects that contain information about active Policy Objects that express Fibre Channel Security (FC-SP) policy." ::= { t11FcSpPoMIBGroups 1 } t11FcSpPoOperationsObjectsGroup OBJECT-GROUP OBJECTS { t11FcSpPoOperActivate, t11FcSpPoOperDeActivate, t11FcSpPoOperResult, t11FcSpPoOperFailCause } STATUS current DESCRIPTION "A collection of MIB objects that allow a new set of Fibre Channel Security (FC-SP) policies to be activated or an existing set to be deactivated." ::= { t11FcSpPoMIBGroups 2 } t11FcSpPoNonActiveObjectsGroup OBJECT-GROUP OBJECTS { t11FcSpPoStorageType, t11FcSpPoNaSummaryPolicyNameType, t11FcSpPoNaSummaryPolicyName, t11FcSpPoNaSummaryHashStatus, t11FcSpPoNaSummaryHashFormat, t11FcSpPoNaSummaryHashValue, t11FcSpPoNaSummaryRowStatus, t11FcSpPoNaSwListFabricName, t11FcSpPoNaSwListRowStatus, t11FcSpPoNaSwMembFlags, t11FcSpPoNaSwMembDomainID, t11FcSpPoNaSwMembPolicyDataRole, De Santi, et al. Standards Track [Page 150] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoNaSwMembAuthBehaviour, t11FcSpPoNaSwMembAttribute, t11FcSpPoNaSwMembRowStatus, t11FcSpPoNaNoMembFlags, t11FcSpPoNaNoMembCtAccessIndex, t11FcSpPoNaNoMembAttribute, t11FcSpPoNaNoMembRowStatus, t11FcSpPoNaCtDescrFlags, t11FcSpPoNaCtDescrGsType, t11FcSpPoNaCtDescrGsSubType, t11FcSpPoNaCtDescrRowStatus, t11FcSpPoNaSwConnAllowedNameType, t11FcSpPoNaSwConnAllowedName, t11FcSpPoNaSwConnRowStatus, t11FcSpPoNaIpMgmtWkpIndex, t11FcSpPoNaIpMgmtAttribute, t11FcSpPoNaIpMgmtRowStatus, t11FcSpPoNaWkpDescrFlags, t11FcSpPoNaWkpDescrWkpNumber, t11FcSpPoNaWkpDescrDestPort, t11FcSpPoNaWkpDescrRowStatus, t11FcSpPoNaAttribType, t11FcSpPoNaAttribValue, t11FcSpPoNaAttribExtension, t11FcSpPoNaAttribRowStatus, t11FcSpPoNaAuthProtParams, t11FcSpPoNaAuthProtRowStatus } STATUS current DESCRIPTION "A collection of MIB objects that contain information about non-active Policy Objects available for activation in order to change Fibre Channel Security (FC-SP) policy." ::= { t11FcSpPoMIBGroups 3 } t11FcSpPoStatsObjectsGroup OBJECT-GROUP OBJECTS { t11FcSpPoInRequests, t11FcSpPoInAccepts, t11FcSpPoInRejects } STATUS current DESCRIPTION "A collection of MIB objects that contain statistics that can be maintained by FC-SP Security Policy Servers." ::= { t11FcSpPoMIBGroups 4 } t11FcSpPoNotifyObjectsGroup OBJECT-GROUP OBJECTS { t11FcSpPoNotificationEnable, De Santi, et al. Standards Track [Page 151] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoServerAddress, t11FcSpPoLastNotifyType, t11FcSpPoRequestSource, t11FcSpPoReasonCode, t11FcSpPoCtCommandString, t11FcSpPoReasonCodeExp, t11FcSpPoReasonVendorCode } STATUS current DESCRIPTION "A collection of MIB objects to control the generation of notifications concerning Fibre Channel Security (FC-SP) policy, and to hold information contained in such notifications." ::= { t11FcSpPoMIBGroups 5 } t11FcSpPoNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FcSpPoNotifyActivation, t11FcSpPoNotifyActivateFail, t11FcSpPoNotifyDeactivation, t11FcSpPoNotifyDeactivateFail } STATUS current DESCRIPTION "A collection of notifications of events concerning Fibre Channel Security (FC-SP) policy." ::= { t11FcSpPoMIBGroups 6 } END 6.5. The T11-FC-SP-SA-MIB Module --******************************************************************* -- FC-SP Security Associations -- T11-FC-SP-SA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32, Counter64, TimeTicks, Gauge32, mib-2 FROM SNMPv2-SMI -- [RFC2578] RowStatus, StorageType, AutonomousType, TimeStamp, TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndex, De Santi, et al. Standards Track [Page 152] RFC 5324 MIB for FC-SP September 2008 InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] fcmInstanceIndex, FcAddressIdOrZero FROM FC-MGMT-MIB -- [RFC4044] T11FabricIndex FROM T11-TC-MIB -- [RFC4439] T11FcSpType, T11FcSpiIndex, T11FcSpLifetimeLeft, T11FcSpLifetimeLeftUnits, T11FcSpSecurityProtocolId, T11FcRoutingControl, T11FcSaDirection, T11FcSpPrecedence, T11FcSpTransforms FROM T11-FC-SP-TC-MIB; t11FcSpSaMIB MODULE-IDENTITY LAST-UPDATED "200808200000Z" ORGANIZATION "This MIB module was developed through the coordinated effort of two organizations: T11 began the development and the IETF (in the IMSS Working Group) finished it." CONTACT-INFO " Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: cds@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: kzm@cisco.com" DESCRIPTION "This MIB module specifies the management information required to manage Security Associations established via Fibre Channel's FC-SP specification. The MIB module consists of six parts: - a per-Fabric table, t11FcSpSaIfTable, of capabilities, parameters, status information, and counters; the counters include non-transient aggregates of per-SA transient counters; - three tables, t11FcSpSaPropTable, t11FcSpSaTSelPropTable, and t11FcSpSaTransTable, specifying the proposals for an FC-SP entity acting as an SA_Initiator to present to the SA_Responder during the negotiation of Security De Santi, et al. Standards Track [Page 153] RFC 5324 MIB for FC-SP September 2008 Associations. The same information is also used by an FC-SP entity acting as an SA_Responder to decide what to accept during the negotiation of Security Associations. One of these tables, t11FcSpSaTransTable, is used not only for information about security transforms to propose and to accept, but also as agreed upon during the negotiation of Security Associations; - a table, t11FcSpSaTSelDrByTable, of Traffic Selectors having the security action of 'drop' or 'bypass' to be applied either to ingress traffic that is unprotected by FC-SP, or to all egress traffic; - four tables, t11FcSpSaPairTable, t11FcSpSaTSelNegInTable, t11FcSpSaTSelNegOutTable, and t11FcSpSaTSelSpiTable, containing information about active bidirectional pairs of Security Associations; in particular, t11FcSpSaPairTable has one row per active bidirectional SA pair, t11FcSpSaTSelNegInTable and t11FcSpSaTSelNegOutTable contain information on the Traffic Selectors negotiated on the SAs, and the t11FcSpSaTSelSpiTable is an alternate lookup table such that the Traffic Selector(s) in use on a particular Security Association can be quickly determined based on the (ingress) SPI value; - a table, t11FcSpSaControlTable, of control and other information concerning the generation of notifications for events related to FC-SP Security Associations; - one notification, t11FcSpSaNotifyAuthFailure, generated on the occurrence of an Authentication failure for a received FC-2 or CT_IU frame. Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 5324; see the RFC itself for full legal notices." REVISION "200808200000Z" DESCRIPTION "Initial version of this MIB module, published as RFC 5324." ::= { mib-2 179 } t11FcSpSaMIBNotifications OBJECT IDENTIFIER ::= { t11FcSpSaMIB 0 } t11FcSpSaMIBObjects OBJECT IDENTIFIER ::= { t11FcSpSaMIB 1 } t11FcSpSaMIBConformance OBJECT IDENTIFIER ::= { t11FcSpSaMIB 2 } t11FcSpSaBase OBJECT IDENTIFIER ::= { t11FcSpSaMIBObjects 1 } t11FcSpSaConfig OBJECT IDENTIFIER ::= { t11FcSpSaMIBObjects 2 } t11FcSpSaActive OBJECT IDENTIFIER ::= { t11FcSpSaMIBObjects 3 } t11FcSpSaControl OBJECT IDENTIFIER ::= { t11FcSpSaMIBObjects 4 } De Santi, et al. Standards Track [Page 154] RFC 5324 MIB for FC-SP September 2008 -- -- Base-level Per-Fabric Information -- t11FcSpSaIfTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing per-Fabric information related to FC-SP Security Associations." ::= { t11FcSpSaBase 1 } t11FcSpSaIfEntry OBJECT-TYPE SYNTAX T11FcSpSaIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information related to Security Associations on a particular Fabric, and managed as part of the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, t11FcSpSaIfFabricIndex } ::= { t11FcSpSaIfTable 1 } T11FcSpSaIfEntry ::= SEQUENCE { t11FcSpSaIfIndex InterfaceIndexOrZero, t11FcSpSaIfFabricIndex T11FabricIndex, -- capabilities t11FcSpSaIfEspHeaderCapab T11FcSpTransforms, t11FcSpSaIfCTAuthCapab T11FcSpTransforms, t11FcSpSaIfIKEv2Capab T11FcSpTransforms, t11FcSpSaIfIkev2AuthCapab TruthValue, -- parameters and status t11FcSpSaIfStorageType StorageType, t11FcSpSaIfReplayPrevention TruthValue, t11FcSpSaIfReplayWindowSize Unsigned32, t11FcSpSaIfDeadPeerDetections Counter32, t11FcSpSaIfTerminateAllSas INTEGER, -- summary frame counters t11FcSpSaIfOutDrops Counter64, t11FcSpSaIfOutBypasses Counter64, t11FcSpSaIfOutProcesses Counter64, t11FcSpSaIfOutUnMatcheds Counter64, t11FcSpSaIfInUnprotUnmtchDrops Counter64, -- aggregates of per-SA transient counters t11FcSpSaIfInDetReplays Counter64, De Santi, et al. Standards Track [Page 155] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaIfInUnprotMtchDrops Counter64, t11FcSpSaIfInBadXforms Counter64, t11FcSpSaIfInGoodXforms Counter64, t11FcSpSaIfInProtUnmtchs Counter64 } t11FcSpSaIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object has a non-zero value to identify a particular interface, or the value zero to indicate that the information in this row applies to all (of the management instance's) interfaces to the particular Fabric. If any row has a non-zero value of t11FcSpSaIfIndex, then all rows for the same Fibre Channel management instance must also have a non-zero value of t11FcSpSaIfIndex and thereby be specific to a particular interface. As and when zero values of t11FcSpSaIfIndex are used in this table, then they must also be used in each other table that has t11FcSpSaIfIndex in its INDEX clause." ::= { t11FcSpSaIfEntry 1 } t11FcSpSaIfFabricIndex OBJECT-TYPE SYNTAX T11FabricIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular Fabric." ::= { t11FcSpSaIfEntry 2 } t11FcSpSaIfEspHeaderCapab OBJECT-TYPE SYNTAX T11FcSpTransforms MAX-ACCESS read-only STATUS current DESCRIPTION "A list of the standardized transforms supported by this entity on this interface for ESP_Header protection." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Appendix A.3.1, tables A.23, A.25." ::= { t11FcSpSaIfEntry 3 } De Santi, et al. Standards Track [Page 156] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaIfCTAuthCapab OBJECT-TYPE SYNTAX T11FcSpTransforms MAX-ACCESS read-only STATUS current DESCRIPTION "A list of the standardized transforms supported by this entity on this interface for CT_Authentication protection." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Appendix A.3.1, tables A.23, A.25." ::= { t11FcSpSaIfEntry 4 } t11FcSpSaIfIKEv2Capab OBJECT-TYPE SYNTAX T11FcSpTransforms MAX-ACCESS read-only STATUS current DESCRIPTION "A list of the standardized transforms supported by this entity on this interface with IKEv2 protection." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Appendix A.3.1, tables A.23, A.24, A.25, A.26." ::= { t11FcSpSaIfEntry 5 } t11FcSpSaIfIkev2AuthCapab OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether the entity is capable of supporting the IKEv2-AUTH protocol on this interface, i.e., concatenation of Authentication and SA Management Transactions, such that an SA Management Transaction is used to perform both the authentication function and SA management." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.7.2, and table A.27." ::= { t11FcSpSaIfEntry 6 } t11FcSpSaIfStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current De Santi, et al. Standards Track [Page 157] RFC 5324 MIB for FC-SP September 2008 DESCRIPTION "This object specifies the memory realization of information related to FC-SP Security Associations for interface(s) to a particular Fabric; specifically, for rows created and/or modified in these tables: t11FcSpSaPropTable t11FcSpSaTSelDrByTable t11FcSpSaControlTable and, for modified information contained in the same row as an instance of this object. Even if an instance of this object has the value 'permanent(4)', none of the information defined in this MIB module for interface(s) to the given Fabric need to be writable." ::= { t11FcSpSaIfEntry 7 } t11FcSpSaIfReplayPrevention OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether anti-replay protection is enabled for frame reception on this interface. Note that the replay-protection mechanism in FC-SP is conceptually similar to the corresponding mechanism in IPsec ESP." REFERENCE "- IP Encapsulating Security Payload (ESP), RFC 4303, December 2005, section 3.3.3." ::= { t11FcSpSaIfEntry 8 } t11FcSpSaIfReplayWindowSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The size of the replay window to be used when anti-replay protection is enabled for frame reception on this interface. Note that the replay-protection mechanism in FC-SP is conceptually similar to the corresponding mechanism in IPsec ESP." REFERENCE De Santi, et al. Standards Track [Page 158] RFC 5324 MIB for FC-SP September 2008 "- IP Encapsulating Security Payload (ESP), RFC 4303, December 2005, section 3.4.3." ::= { t11FcSpSaIfEntry 9 } t11FcSpSaIfDeadPeerDetections OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a dead peer condition has been detected on this interface. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 8.5.3.3." ::= { t11FcSpSaIfEntry 10 } t11FcSpSaIfTerminateAllSas OBJECT-TYPE SYNTAX INTEGER { noop(1), terminate(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'terminate' is a request to terminate all outstanding Security Associations on this interface. When read, the value of this object is always 'noop'. Setting this object to 'noop' has no effect." ::= { t11FcSpSaIfEntry 11 } t11FcSpSaIfOutDrops OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output frames that were dropped, instead of being transmitted on this interface, because they matched an active (at that time) Traffic Selector with an action of 'Drop'. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 12 } t11FcSpSaIfOutBypasses OBJECT-TYPE De Santi, et al. Standards Track [Page 159] RFC 5324 MIB for FC-SP September 2008 SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output frames that were transmitted unchanged by FC-SP on this interface because they matched an active (at that time) Traffic Selector with an action of 'Bypass'. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 13 } t11FcSpSaIfOutProcesses OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output frames that were protected by FC-SP before being transmitted on this interface because they matched an active (at that time) Traffic Selector with an action of 'Process'. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 14 } t11FcSpSaIfOutUnMatcheds OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that were transmitted unchanged by FC-SP on this interface because they did not match any Traffic Selector active at that time. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 15 } t11FcSpSaIfInUnprotUnmtchDrops OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received on this interface that were dropped because they were unprotected and did not match any Traffic Selector active at that time. De Santi, et al. Standards Track [Page 160] RFC 5324 MIB for FC-SP September 2008 This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 16 } t11FcSpSaIfInDetReplays OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a replay has been detected on a Security Association that is currently active or was previously active on this interface. Note that a frame that is discarded because it is 'behind' the window, i.e., too old, is counted as a replay. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 17 } t11FcSpSaIfInUnprotMtchDrops OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a frame received on this interface was dropped because it matched with a Traffic Selector for a Security Association that was active at the time of receipt but the frame was not protected as negotiated for that Security Association. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 18 } t11FcSpSaIfInBadXforms OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a frame received on this interface was dropped because of a failure of one of the transforms negotiated for the Security Association on which it was received. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 19 } De Santi, et al. Standards Track [Page 161] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaIfInGoodXforms OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received on this interface on a Security Association for which the transforms negotiated for that Security Association were successfully applied, and that matched a Traffic Selector for that Security Association. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 20 } t11FcSpSaIfInProtUnmtchs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received on this interface that were dropped because they did not match any of the Traffic Selectors negotiated for the Security Association on which they were received, even though the Security Association's transforms were successfully applied. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaIfEntry 21 } -- -- Proposals to present in Security Association negotiation -- t11FcSpSaPropTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaPropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of proposals for an FC-SP entity acting as an SA_Initiator to present to the SA_Responder during the negotiation of Security Associations. This information is also used by an FC-SP entity acting as an SA_Responder to decide what to accept during the negotiation of Security Associations." ::= { t11FcSpSaConfig 1 } t11FcSpSaPropEntry OBJECT-TYPE De Santi, et al. Standards Track [Page 162] RFC 5324 MIB for FC-SP September 2008 SYNTAX T11FcSpSaPropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one proposal for the FC-SP entity to present, or what to accept, during the negotiation of Security Associations on one or more interfaces (identified by t11FcSpSaIfIndex) to a particular Fabric (identified by t11FcSpSaIfFabricIndex), and managed as part of the Fibre Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpSaIfStorageType that is INDEX-ed by the same values of fcmInstanceIndex, t11FcSpSaIfIndex and t11FcSpSaIfFabricIndex." INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, t11FcSpSaIfFabricIndex, t11FcSpSaPropIndex } ::= { t11FcSpSaPropTable 1 } T11FcSpSaPropEntry ::= SEQUENCE { t11FcSpSaPropIndex Unsigned32, t11FcSpSaPropSecurityProt T11FcSpSecurityProtocolId, t11FcSpSaPropTSelListIndex Unsigned32, t11FcSpSaPropTransListIndex Unsigned32, t11FcSpSaPropAcceptAlgorithm INTEGER, t11FcSpSaPropOutMatchSucceeds Counter64, t11FcSpSaPropRowStatus RowStatus } t11FcSpSaPropIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular proposal for use on one or more interfaces to a Fabric." ::= { t11FcSpSaPropEntry 1 } t11FcSpSaPropSecurityProt OBJECT-TYPE SYNTAX T11FcSpSecurityProtocolId MAX-ACCESS read-create STATUS current DESCRIPTION "The Security Protocol identifier for this proposal, i.e., whether the proposal is for traffic to be protected using ESP_Header or CT_Authentication." De Santi, et al. Standards Track [Page 163] RFC 5324 MIB for FC-SP September 2008 REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.2 and table 67." ::= { t11FcSpSaPropEntry 2 } t11FcSpSaPropTSelListIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "When the value of this object is non-zero, it points to the proposal's list of Traffic Selectors. The value must be non-zero in an active row of this table. The identified list is represented by all rows in the t11FcSpSaTSelPropTable for which t11FcSpSaTSelPropListIndex has the same value as this object (and with corresponding values of t11FcSpSaIfIndex and fcmInstanceIndex)." ::= { t11FcSpSaPropEntry 3 } t11FcSpSaPropTransListIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "When the value of this object is non-zero, it points to the proposal's list of Transforms. The value must be non-zero in an active row of this table. The identified list is represented by all rows in the t11FcSpSaTransTable for which t11FcSpSaTransListIndex has the same value as this object (and with corresponding values of t11FcSpSaIfIndex and fcmInstanceIndex)." ::= { t11FcSpSaPropEntry 4 } t11FcSpSaPropAcceptAlgorithm OBJECT-TYPE SYNTAX INTEGER { intersection(1), union(2), other(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The algorithm by which an SA_Responder in an SA negotiation decides on which Traffic Selectors to specify in a response to an IKE_Create_Child_SA request. This algorithm is used De Santi, et al. Standards Track [Page 164] RFC 5324 MIB for FC-SP September 2008 when the Traffic Selectors specified by an SA_Initiator in an IKE_Create_Child_SA request overlap with this proposal's list of Traffic Selectors: intersection(1) - the SA_Responder specifies the largest subset of what the SA_Initiator proposed, which is also a subset of this proposal's Traffic Selectors. union(2) - the SA_Responder specifies the smallest superset of what the SA_Initiator proposed, which is also a superset of this proposal's Traffic Selectors. other(3) - the SA_Responder uses some other algorithm. " ::= { t11FcSpSaPropEntry 5 } t11FcSpSaPropOutMatchSucceeds OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of egress frames that have matched a Traffic Selector that was negotiated to select traffic for an SA based on this proposal being accepted. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaPropEntry 6 } t11FcSpSaPropRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of a row. Values of object instances within an active row can be modified at any time. The status cannot be set to 'active' unless and until the instances of t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex in the row have been set to point to active rows in the t11FcSpSaTSelPropTable and t11FcSpSaTransTable tables, respectively. A row in this table is deleted if the active rows it points to are deleted." ::= { t11FcSpSaPropEntry 7 } De Santi, et al. Standards Track [Page 165] RFC 5324 MIB for FC-SP September 2008 -- -- Traffic Selector Proposals -- t11FcSpSaTSelPropTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaTSelPropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about Traffic Selectors to propose and/or to accept during the negotiation of Security Associations." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5. - Use of IKEv2 in FC-SP, RFC 4595, July 2006, section 4.4." ::= { t11FcSpSaConfig 2 } t11FcSpSaTSelPropEntry OBJECT-TYPE SYNTAX T11FcSpSaTSelPropEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one Traffic Selector within a list of Traffic Selectors to propose, or for use in determining what to accept during Security Association negotiation. One such list is configured for use on a Fabric by configuring the list's value of t11FcSpSaTSelPropListIndex as the value of an instance of t11FcSpSaPropTSelListIndex, for corresponding values of t11FcSpSaIfIndex and fcmInstanceIndex. Further, the proposing and accepting of Traffic Selectors is only done as a part of a proposal specified by a row of the t11FcSpSaPropTable, i.e., in combination with the proposing and accepting of security transforms as specified by the combination of t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex in one row of the t11FcSpSaPropTable. The StorageType of a row in this table is specified by the instance of t11FcSpSaTSelPropStorageType in that row." INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, t11FcSpSaTSelPropListIndex, t11FcSpSaTSelPropPrecedence } ::= { t11FcSpSaTSelPropTable 1 } De Santi, et al. Standards Track [Page 166] RFC 5324 MIB for FC-SP September 2008 T11FcSpSaTSelPropEntry ::= SEQUENCE { t11FcSpSaTSelPropListIndex Unsigned32, t11FcSpSaTSelPropPrecedence T11FcSpPrecedence, t11FcSpSaTSelPropDirection T11FcSaDirection, t11FcSpSaTSelPropStartSrcAddr FcAddressIdOrZero, t11FcSpSaTSelPropEndSrcAddr FcAddressIdOrZero, t11FcSpSaTSelPropStartDstAddr FcAddressIdOrZero, t11FcSpSaTSelPropEndDstAddr FcAddressIdOrZero, t11FcSpSaTSelPropStartRCtl T11FcRoutingControl, t11FcSpSaTSelPropEndRCtl T11FcRoutingControl, t11FcSpSaTSelPropStartType T11FcSpType, t11FcSpSaTSelPropEndType T11FcSpType, t11FcSpSaTSelPropStorageType StorageType, t11FcSpSaTSelPropRowStatus RowStatus } t11FcSpSaTSelPropListIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that identifies a particular list of Traffic Selectors." ::= { t11FcSpSaTSelPropEntry 1 } t11FcSpSaTSelPropPrecedence OBJECT-TYPE SYNTAX T11FcSpPrecedence MAX-ACCESS not-accessible STATUS current DESCRIPTION "The precedence of this Traffic Selector. Each Traffic Selector within a particular list of Traffic Selectors must have a different precedence. If an egress frame matches multiple Traffic Selectors, it should be transmitted on the SA associated with the Traffic Selector having the numerically smallest precedence value." ::= { t11FcSpSaTSelPropEntry 2 } t11FcSpSaTSelPropDirection OBJECT-TYPE SYNTAX T11FcSaDirection MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether this Traffic Selector is to be proposed for ingress or egress traffic." DEFVAL { egress } De Santi, et al. Standards Track [Page 167] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpSaTSelPropEntry 3 } t11FcSpSaTSelPropStartSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { '000000'h } ::= { t11FcSpSaTSelPropEntry 4 } t11FcSpSaTSelPropEndSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { 'FFFFFF'h } ::= { t11FcSpSaTSelPropEntry 5 } t11FcSpSaTSelPropStartDstAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { '000000'h } ::= { t11FcSpSaTSelPropEntry 6 } t11FcSpSaTSelPropEndDstAddr OBJECT-TYPE De Santi, et al. Standards Track [Page 168] RFC 5324 MIB for FC-SP September 2008 SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { 'FFFFFF'h } ::= { t11FcSpSaTSelPropEntry 7 } t11FcSpSaTSelPropStartRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { '00'h } ::= { t11FcSpSaTSelPropEntry 8 } t11FcSpSaTSelPropEndRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { 'FF'h } ::= { t11FcSpSaTSelPropEntry 9 } t11FcSpSaTSelPropStartType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-create STATUS current De Santi, et al. Standards Track [Page 169] RFC 5324 MIB for FC-SP September 2008 DESCRIPTION "The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { '0000'h } ::= { t11FcSpSaTSelPropEntry 10 } t11FcSpSaTSelPropEndType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.4.5." DEFVAL { 'FFFF'h } ::= { t11FcSpSaTSelPropEntry 11 } t11FcSpSaTSelPropStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the memory realization of the information in this row. Even if an instance of this object has the value 'permanent(4)', none of the information in its row needs to be writable." ::= { t11FcSpSaTSelPropEntry 12 } t11FcSpSaTSelPropRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpSaTSelPropEntry 13 } De Santi, et al. Standards Track [Page 170] RFC 5324 MIB for FC-SP September 2008 -- -- Transform Proposals -- t11FcSpSaTransTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaTransEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about security transforms to propose, to accept and/or agreed upon during the negotiation of Security Associations." ::= { t11FcSpSaConfig 3 } t11FcSpSaTransEntry OBJECT-TYPE SYNTAX T11FcSpSaTransEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one proposal within a list of security transforms to be proposed, to be accepted, or already agreed upon, for use on a pair of Security Associations on one or more interfaces (identified by t11FcSpSaIfIndex), managed as part of the Fibre Channel management instance identified by fcmInstanceIndex. One such list is configured to be proposed or accepted for use on a Fabric, by having the list's value of t11FcSpSaTransListIndex be the value of an instance of t11FcSpSaPropTransListIndex for that Fabric. Further, the proposing and accepting of security transforms is only done as a part of a proposal specified by a row of the t11FcSpSaPropTable, i.e., in combination with the proposing and accepting of Traffic Selectors as specified by the combination of t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex in one row of the t11FcSpSaPropTable. The security (encryption and integrity) transform in use on an SA pair is indicated by having the pair's values of t11FcSpSaPairTransListIndex and t11FcSpSaPairTransIndex contain the values of t11FcSpSaTransListIndex and t11FcSpSaTransIndex for the transform's row in this table. The StorageType of a row in this table is specified by the instance of t11FcSpSaTransStorageType in that row." INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, t11FcSpSaTransListIndex, t11FcSpSaTransIndex } De Santi, et al. Standards Track [Page 171] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpSaTransTable 1 } T11FcSpSaTransEntry ::= SEQUENCE { t11FcSpSaTransListIndex Unsigned32, t11FcSpSaTransIndex Unsigned32, t11FcSpSaTransSecurityProt T11FcSpSecurityProtocolId, t11FcSpSaTransEncryptAlg AutonomousType, t11FcSpSaTransEncryptKeyLen Unsigned32, t11FcSpSaTransIntegrityAlg AutonomousType, t11FcSpSaTransStorageType StorageType, t11FcSpSaTransRowStatus RowStatus } t11FcSpSaTransListIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies a particular list of security transforms to be proposed, to be accepted, or already agreed upon." ::= { t11FcSpSaTransEntry 1 } t11FcSpSaTransIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies one security transform within a list identified by t11FcSpSaTransListIndex." ::= { t11FcSpSaTransEntry 2 } t11FcSpSaTransSecurityProt OBJECT-TYPE SYNTAX T11FcSpSecurityProtocolId MAX-ACCESS read-create STATUS current DESCRIPTION "The Security Protocol identifier that indicates whether this transform is for traffic to be protected using ESP_Header or using CT_Authentication." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.2 and table 67." ::= { t11FcSpSaTransEntry 3 } t11FcSpSaTransEncryptAlg OBJECT-TYPE De Santi, et al. Standards Track [Page 172] RFC 5324 MIB for FC-SP September 2008 SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The Encryption Algorithm for this transform." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.3 and tables 69 & 70." ::= { t11FcSpSaTransEntry 4 } t11FcSpSaTransEncryptKeyLen OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The key length in bits to be used with an encryption algorithm that has a variable length key. This object is ignored when the corresponding instance of t11FcSpSaTransEncryptAlg specifies an algorithm with a fixed length key." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.5 and table 77." ::= { t11FcSpSaTransEntry 5 } t11FcSpSaTransIntegrityAlg OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The Integrity Algorithm for this transform." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.3 and tables 69 & 72." ::= { t11FcSpSaTransEntry 6 } t11FcSpSaTransStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the memory realization of the information in this row. Even if an instance of this object has the value De Santi, et al. Standards Track [Page 173] RFC 5324 MIB for FC-SP September 2008 'permanent(4)', none of the information in its row needs to be writable." ::= { t11FcSpSaTransEntry 7 } t11FcSpSaTransRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. When an instance of t11FcSpSaPairTransListIndex points to a row in this table, values of object instances in the row cannot be modified nor can the row be deleted. Otherwise, a row can be modified or deleted at any time." ::= { t11FcSpSaTransEntry 8 } -- -- Traffic Selectors for Drop & Bypass -- t11FcSpSaTSelDrByTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaTSelDrByEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Traffic Selectors to select which traffic is to be dropped or is to bypass further security processing." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 4.6, 4.7, and 6.4.5. - Use of IKEv2 in FC-SP, RFC 4595, July 2006, section 4.4." ::= { t11FcSpSaConfig 4 } t11FcSpSaTSelDrByEntry OBJECT-TYPE SYNTAX T11FcSpSaTSelDrByEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents one Traffic Selector having the security action of 'drop' or 'bypass', which is applied based on a precedence value, either to ingress traffic that is unprotected by FC-SP, or to all egress traffic on one or more interfaces (identified by t11FcSpSaIfIndex) to a particular Fabric (identified De Santi, et al. Standards Track [Page 174] RFC 5324 MIB for FC-SP September 2008 by t11FcSpSaIfFabricIndex), and managed as part of the Fibre Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpSaIfStorageType that is INDEX-ed by the same values of fcmInstanceIndex, t11FcSpSaIfIndex and t11FcSpSaIfFabricIndex." INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, t11FcSpSaIfFabricIndex, t11FcSpSaTSelDrByDirection, t11FcSpSaTSelDrByPrecedence } ::= { t11FcSpSaTSelDrByTable 1 } T11FcSpSaTSelDrByEntry ::= SEQUENCE { t11FcSpSaTSelDrByDirection T11FcSaDirection, t11FcSpSaTSelDrByPrecedence T11FcSpPrecedence, t11FcSpSaTSelDrByAction INTEGER, t11FcSpSaTSelDrByStartSrcAddr FcAddressIdOrZero, t11FcSpSaTSelDrByEndSrcAddr FcAddressIdOrZero, t11FcSpSaTSelDrByStartDstAddr FcAddressIdOrZero, t11FcSpSaTSelDrByEndDstAddr FcAddressIdOrZero, t11FcSpSaTSelDrByStartRCtl T11FcRoutingControl, t11FcSpSaTSelDrByEndRCtl T11FcRoutingControl, t11FcSpSaTSelDrByStartType T11FcSpType, t11FcSpSaTSelDrByEndType T11FcSpType, t11FcSpSaTSelDrByMatches Counter64, t11FcSpSaTSelDrByRowStatus RowStatus } t11FcSpSaTSelDrByDirection OBJECT-TYPE SYNTAX T11FcSaDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "An indication of whether this Traffic Selector is for ingress or egress traffic." ::= { t11FcSpSaTSelDrByEntry 1 } t11FcSpSaTSelDrByPrecedence OBJECT-TYPE SYNTAX T11FcSpPrecedence MAX-ACCESS not-accessible STATUS current DESCRIPTION "The precedence of this Traffic Selector. If and when a frame is compared against multiple Traffic Selectors, and multiple of them have a match with the frame, the security action to be taken for the frame is that specified for the matching Traffic Selector having the numerically smallest precedence value." ::= { t11FcSpSaTSelDrByEntry 2 } De Santi, et al. Standards Track [Page 175] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaTSelDrByAction OBJECT-TYPE SYNTAX INTEGER { drop(1), bypass(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The security action to be taken for a frame that matches this Traffic Selector." DEFVAL { drop } ::= { t11FcSpSaTSelDrByEntry 3 } t11FcSpSaTSelDrByStartSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." DEFVAL { '000000'h } ::= { t11FcSpSaTSelDrByEntry 4 } t11FcSpSaTSelDrByEndSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." DEFVAL { 'FFFFFF'h } ::= { t11FcSpSaTSelDrByEntry 5 } t11FcSpSaTSelDrByStartDstAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." DEFVAL { '000000'h } ::= { t11FcSpSaTSelDrByEntry 6 } t11FcSpSaTSelDrByEndDstAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-create STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 176] RFC 5324 MIB for FC-SP September 2008 "The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." DEFVAL { 'FFFFFF'h } ::= { t11FcSpSaTSelDrByEntry 7 } t11FcSpSaTSelDrByStartRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." DEFVAL { '00'h } ::= { t11FcSpSaTSelDrByEntry 8 } t11FcSpSaTSelDrByEndRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." DEFVAL { 'FF'h } ::= { t11FcSpSaTSelDrByEntry 9 } t11FcSpSaTSelDrByStartType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector." DEFVAL { '0000'h } ::= { t11FcSpSaTSelDrByEntry 10 } t11FcSpSaTSelDrByEndType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-create STATUS current DESCRIPTION "The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector." DEFVAL { 'FFFF'h } De Santi, et al. Standards Track [Page 177] RFC 5324 MIB for FC-SP September 2008 ::= { t11FcSpSaTSelDrByEntry 11 } t11FcSpSaTSelDrByMatches OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames for which the action specified by the corresponding instance of t11FcSpSaTSelDrByAction was taken because of a match with this Traffic Selector. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaTSelDrByEntry 12 } t11FcSpSaTSelDrByRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. Values of object instances within the row can be modified at any time." ::= { t11FcSpSaTSelDrByEntry 13 } -- -- Active Security Associations -- t11FcSpSaPairTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaPairEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about active bidirectional pairs of Security Associations." ::= { t11FcSpSaActive 1 } t11FcSpSaPairEntry OBJECT-TYPE SYNTAX T11FcSpSaPairEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one active bidirectional pair of Security Associations on an interface to a particular Fabric (identified by t11FcSpSaIfFabricIndex), managed as part of the Fibre Channel management instance identified by fcmInstanceIndex." De Santi, et al. Standards Track [Page 178] RFC 5324 MIB for FC-SP September 2008 INDEX { fcmInstanceIndex, t11FcSpSaPairIfIndex, t11FcSpSaIfFabricIndex, t11FcSpSaPairInboundSpi } ::= { t11FcSpSaPairTable 1 } T11FcSpSaPairEntry ::= SEQUENCE { t11FcSpSaPairIfIndex InterfaceIndex, t11FcSpSaPairInboundSpi T11FcSpiIndex, t11FcSpSaPairSecurityProt T11FcSpSecurityProtocolId, t11FcSpSaPairTransListIndex Unsigned32, t11FcSpSaPairTransIndex Unsigned32, t11FcSpSaPairLifetimeLeft T11FcSpLifetimeLeft, t11FcSpSaPairLifetimeLeftUnits T11FcSpLifetimeLeftUnits, t11FcSpSaPairTerminate INTEGER, t11FcSpSaPairInProtUnMatchs Counter64, t11FcSpSaPairInDetReplays Counter64, t11FcSpSaPairInBadXforms Counter64, t11FcSpSaPairInGoodXforms Counter64 } t11FcSpSaPairIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the interface to the particular Fabric on which this SA pair is active." ::= { t11FcSpSaPairEntry 1 } t11FcSpSaPairInboundSpi OBJECT-TYPE SYNTAX T11FcSpiIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SPI value that is used to indicate that an incoming frame was received on the ingress SA of this SA pair." ::= { t11FcSpSaPairEntry 2 } t11FcSpSaPairSecurityProt OBJECT-TYPE SYNTAX T11FcSpSecurityProtocolId MAX-ACCESS read-only STATUS current DESCRIPTION "The object indicates whether this SA uses ESP_Header to protect FC-2 frames, or CT_Authentication to protect Common Transport Information Units (CT_IUs)." ::= { t11FcSpSaPairEntry 3 } t11FcSpSaPairTransListIndex OBJECT-TYPE De Santi, et al. Standards Track [Page 179] RFC 5324 MIB for FC-SP September 2008 SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The combination of this value and the value of the corresponding instance of t11FcSpSaPairTransIndex identify the row in the t11FcSpSaTransTable that contains the transforms that are in use on this SA pair." ::= { t11FcSpSaPairEntry 4 } t11FcSpSaPairTransIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The combination of this value and the value of the corresponding instance of t11FcSpSaPairTransListIndex identify the row in the t11FcSpSaTransTable that contains the transforms that are in use on this SA pair." ::= { t11FcSpSaPairEntry 5 } t11FcSpSaPairLifetimeLeft OBJECT-TYPE SYNTAX T11FcSpLifetimeLeft MAX-ACCESS read-only STATUS current DESCRIPTION "The remaining lifetime of this SA pair, given in the units specified by the value of the corresponding instance of t11FcSpSaPairLifetimeLeft." ::= { t11FcSpSaPairEntry 6 } t11FcSpSaPairLifetimeLeftUnits OBJECT-TYPE SYNTAX T11FcSpLifetimeLeftUnits MAX-ACCESS read-only STATUS current DESCRIPTION "The units in which the value of the corresponding instance of t11FcSpSaPairLifetimeLeft specifies the remaining lifetime of this SA pair." ::= { t11FcSpSaPairEntry 7 } t11FcSpSaPairTerminate OBJECT-TYPE SYNTAX INTEGER { noop(1), terminate(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'terminate' is a request to terminate this pair of Security Associations. De Santi, et al. Standards Track [Page 180] RFC 5324 MIB for FC-SP September 2008 When read, the value of this object is always 'noop'. Setting this object to 'noop' has no effect." ::= { t11FcSpSaPairEntry 8 } t11FcSpSaPairInProtUnMatchs OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames received on this SA for which the SA's transforms were successfully applied to the frame, but the frame was still dropped because it did not match any of the SA's ingress Traffic Selectors. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaPairEntry 9 } t11FcSpSaPairInDetReplays OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a replay has been detected on this Security Association. Note that a frame that is discarded because it is 'behind' the window, i.e., too old, is counted as a replay. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaPairEntry 10 } t11FcSpSaPairInBadXforms OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a received frame was dropped because one of the transforms negotiated for this Security Association failed. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaPairEntry 11 } t11FcSpSaPairInGoodXforms OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only De Santi, et al. Standards Track [Page 181] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "The number of received frames for which the transforms negotiated for this Security Association, were successfully applied. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaPairEntry 12 } -- -- Negotiated Ingress Traffic Selectors -- t11FcSpSaTSelNegInTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaTSelNegInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about ingress Traffic Selectors that are in use on active Security Associations." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 4.6, 4.7, and 6.4.5. - Use of IKEv2 in FC-SP, RFC 4595, July 2006, section 4.4." ::= { t11FcSpSaActive 2 } t11FcSpSaTSelNegInEntry OBJECT-TYPE SYNTAX T11FcSpSaTSelNegInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one ingress Traffic Selector that is in use on an active Security Association on an interface (identified by t11FcSpSaPairIfIndex) to a particular Fabric (identified by t11FcSpSaIfFabricIndex), managed as part of the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpSaPairIfIndex, t11FcSpSaIfFabricIndex, t11FcSpSaTSelNegInIndex } ::= { t11FcSpSaTSelNegInTable 1 } T11FcSpSaTSelNegInEntry ::= SEQUENCE { t11FcSpSaTSelNegInIndex Unsigned32, t11FcSpSaTSelNegInInboundSpi T11FcSpiIndex, De Santi, et al. Standards Track [Page 182] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaTSelNegInStartSrcAddr FcAddressIdOrZero, t11FcSpSaTSelNegInEndSrcAddr FcAddressIdOrZero, t11FcSpSaTSelNegInStartDstAddr FcAddressIdOrZero, t11FcSpSaTSelNegInEndDstAddr FcAddressIdOrZero, t11FcSpSaTSelNegInStartRCtl T11FcRoutingControl, t11FcSpSaTSelNegInEndRCtl T11FcRoutingControl, t11FcSpSaTSelNegInStartType T11FcSpType, t11FcSpSaTSelNegInEndType T11FcSpType, t11FcSpSaTSelNegInUnpMtchDrops Counter64 } t11FcSpSaTSelNegInIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value to distinguish an ingress Traffic Selector from all others currently in use by Security Associations on the same interface to a particular Fabric." ::= { t11FcSpSaTSelNegInEntry 1 } t11FcSpSaTSelNegInInboundSpi OBJECT-TYPE SYNTAX T11FcSpiIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The SPI of the ingress SA on which this Traffic Selector is in use. This value can be used to find the SA pair's row in the t11FcSpSaPairTable." ::= { t11FcSpSaTSelNegInEntry 2 } t11FcSpSaTSelNegInStartSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 3 } t11FcSpSaTSelNegInEndSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION De Santi, et al. Standards Track [Page 183] RFC 5324 MIB for FC-SP September 2008 "The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 4 } t11FcSpSaTSelNegInStartDstAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 5 } t11FcSpSaTSelNegInEndDstAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 6 } t11FcSpSaTSelNegInStartRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 7 } t11FcSpSaTSelNegInEndRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 8 } t11FcSpSaTSelNegInStartType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-only De Santi, et al. Standards Track [Page 184] RFC 5324 MIB for FC-SP September 2008 STATUS current DESCRIPTION "The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 9 } t11FcSpSaTSelNegInEndType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegInEntry 10 } t11FcSpSaTSelNegInUnpMtchDrops OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that a received frame was dropped because it matched with this Traffic Selector but the frame was not protected as negotiated for the Security Association identified by t11FcSpSaTSelNegInInboundSpi. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0." ::= { t11FcSpSaTSelNegInEntry 11 } -- -- Negotiated Egress Traffic Selectors -- t11FcSpSaTSelNegOutTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaTSelNegOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about egress Traffic Selectors that are in use on active Security Associations." REFERENCE "- ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, sections 4.6, 4.7, and 6.4.5. - Use of IKEv2 in FC-SP, RFC 4595, De Santi, et al. Standards Track [Page 185] RFC 5324 MIB for FC-SP September 2008 July 2006, section 4.4." ::= { t11FcSpSaActive 3 } t11FcSpSaTSelNegOutEntry OBJECT-TYPE SYNTAX T11FcSpSaTSelNegOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information about one egress Traffic Selector that is in use on an active Security Association on an interface (identified by t11FcSpSaPairIfIndex) to a particular Fabric (identified by t11FcSpSaIfFabricIndex), managed as part of the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpSaPairIfIndex, t11FcSpSaIfFabricIndex, t11FcSpSaTSelNegOutPrecedence } ::= { t11FcSpSaTSelNegOutTable 1 } T11FcSpSaTSelNegOutEntry ::= SEQUENCE { t11FcSpSaTSelNegOutPrecedence T11FcSpPrecedence, t11FcSpSaTSelNegOutInboundSpi T11FcSpiIndex, t11FcSpSaTSelNegOutStartSrcAddr FcAddressIdOrZero, t11FcSpSaTSelNegOutEndSrcAddr FcAddressIdOrZero, t11FcSpSaTSelNegOutStartDstAddr FcAddressIdOrZero, t11FcSpSaTSelNegOutEndDstAddr FcAddressIdOrZero, t11FcSpSaTSelNegOutStartRCtl T11FcRoutingControl, t11FcSpSaTSelNegOutEndRCtl T11FcRoutingControl, t11FcSpSaTSelNegOutStartType T11FcSpType, t11FcSpSaTSelNegOutEndType T11FcSpType } t11FcSpSaTSelNegOutPrecedence OBJECT-TYPE SYNTAX T11FcSpPrecedence MAX-ACCESS not-accessible STATUS current DESCRIPTION "The precedence of this Traffic Selector. If and when a frame is compared against multiple Traffic Selectors, and multiple of them have a match with the frame, the security action to be taken for the frame is that specified for the matching Traffic Selector having the numerically smallest precedence value." ::= { t11FcSpSaTSelNegOutEntry 1 } t11FcSpSaTSelNegOutInboundSpi OBJECT-TYPE SYNTAX T11FcSpiIndex MAX-ACCESS read-only STATUS current De Santi, et al. Standards Track [Page 186] RFC 5324 MIB for FC-SP September 2008 DESCRIPTION "The SPI of the ingress SA of the SA pair for which this Traffic Selector is in use on the egress SA. This value can be used to find the SA pair's row in the t11FcSpSaPairTable." ::= { t11FcSpSaTSelNegOutEntry 2 } t11FcSpSaTSelNegOutStartSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 3 } t11FcSpSaTSelNegOutEndSrcAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 4 } t11FcSpSaTSelNegOutStartDstAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 5 } t11FcSpSaTSelNegOutEndDstAddr OBJECT-TYPE SYNTAX FcAddressIdOrZero (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 6 } De Santi, et al. Standards Track [Page 187] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaTSelNegOutStartRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 7 } t11FcSpSaTSelNegOutEndRCtl OBJECT-TYPE SYNTAX T11FcRoutingControl MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 8 } t11FcSpSaTSelNegOutStartType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 9 } t11FcSpSaTSelNegOutEndType OBJECT-TYPE SYNTAX T11FcSpType MAX-ACCESS read-only STATUS current DESCRIPTION "The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector." ::= { t11FcSpSaTSelNegOutEntry 10 } -- -- Traffic Selectors index-ed by SPI -- t11FcSpSaTSelSpiTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaTSelSpiEntry MAX-ACCESS not-accessible STATUS current De Santi, et al. Standards Track [Page 188] RFC 5324 MIB for FC-SP September 2008 DESCRIPTION "A table identifying the Traffic Selectors in use on particular Security Associations, INDEX-ed by their (ingress) SPI values." ::= { t11FcSpSaActive 4 } t11FcSpSaTSelSpiEntry OBJECT-TYPE SYNTAX T11FcSpSaTSelSpiEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry identifies one Traffic Selector in use on an SA pair on the interface (identified by t11FcSpSaPairIfIndex) to a particular Fabric (identified by t11FcSpSaIfFabricIndex), and managed as part of the Fibre Channel management instance identified by fcmInstanceIndex." INDEX { fcmInstanceIndex, t11FcSpSaPairIfIndex, t11FcSpSaIfFabricIndex, t11FcSpSaTSelSpiInboundSpi, t11FcSpSaTSelSpiTrafSelIndex } ::= { t11FcSpSaTSelSpiTable 1 } T11FcSpSaTSelSpiEntry ::= SEQUENCE { t11FcSpSaTSelSpiInboundSpi T11FcSpiIndex, t11FcSpSaTSelSpiTrafSelIndex Unsigned32, t11FcSpSaTSelSpiDirection T11FcSaDirection, t11FcSpSaTSelSpiTrafSelPtr Unsigned32 } t11FcSpSaTSelSpiInboundSpi OBJECT-TYPE SYNTAX T11FcSpiIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "An SPI value that identifies the ingress Security Association of a particular SA pair." ::= { t11FcSpSaTSelSpiEntry 1 } t11FcSpSaTSelSpiTrafSelIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that distinguishes between the (potentially multiple) Traffic Selectors in use on this Security Association pair." ::= { t11FcSpSaTSelSpiEntry 2 } t11FcSpSaTSelSpiDirection OBJECT-TYPE De Santi, et al. Standards Track [Page 189] RFC 5324 MIB for FC-SP September 2008 SYNTAX T11FcSaDirection MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether this Traffic Selector is being used for ingress or for egress traffic." ::= { t11FcSpSaTSelSpiEntry 3 } t11FcSpSaTSelSpiTrafSelPtr OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a pointer into another table that can be used to obtain more information about this Traffic Selector. If the corresponding instance of t11FcSpSaTSelSpiDirection has the value 'egress', then this object contains the value of t11FcSpSaTSelNegOutPrecedence in the row of t11FcSpSaTSelNegOutTable, which contains more information. If the corresponding instance of t11FcSpSaTSelSpiDirection has the value 'ingress', then this object contains the value of t11FcSpSaTSelNegInIndex that identifies the row in t11FcSpSaTSelNegInTable containing more information." ::= { t11FcSpSaTSelSpiEntry 4 } -- -- Notification information & control -- t11FcSpSaControlTable OBJECT-TYPE SYNTAX SEQUENCE OF T11FcSpSaControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of control and other information concerning the generation of notifications for events related to FC-SP Security Associations." ::= { t11FcSpSaControl 1 } t11FcSpSaControlEntry OBJECT-TYPE SYNTAX T11FcSpSaControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry identifies information for the one or more De Santi, et al. Standards Track [Page 190] RFC 5324 MIB for FC-SP September 2008 interfaces (identified by t11FcSpSaIfIndex) to a particular Fabric (identified by t11FcSpSaIfFabricIndex), and managed as part of the Fibre Channel management instance identified by fcmInstanceIndex. The StorageType of a row in this table is specified by the instance of t11FcSpSaIfStorageType that is INDEX-ed by the same values of fcmInstanceIndex, t11FcSpSaIfIndex, and t11FcSpSaIfFabricIndex." INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, t11FcSpSaIfFabricIndex } ::= { t11FcSpSaControlTable 1 } T11FcSpSaControlEntry ::= SEQUENCE { t11FcSpSaControlAuthFailEnable TruthValue, t11FcSpSaControlInboundSpi T11FcSpiIndex, t11FcSpSaControlSource FcAddressIdOrZero, t11FcSpSaControlDestination FcAddressIdOrZero, t11FcSpSaControlFrame OCTET STRING, t11FcSpSaControlElapsed TimeTicks, t11FcSpSaControlSuppressed Gauge32, t11FcSpSaControlWindow Unsigned32, t11FcSpSaControlMaxNotifs Unsigned32, t11FcSpSaControlLifeExcdEnable TruthValue, t11FcSpSaControlLifeExcdSpi T11FcSpiIndex, t11FcSpSaControlLifeExcdDir T11FcSaDirection, t11FcSpSaControlLifeExcdTime TimeStamp } t11FcSpSaControlAuthFailEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether a t11FcSpSaNotifyAuthFailure notification should be generated for the first occurrence of an Authentication failure within a time window for this Fabric." ::= { t11FcSpSaControlEntry 1 } t11FcSpSaControlInboundSpi OBJECT-TYPE SYNTAX T11FcSpiIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The SPI value of the ingress Security Association on which was received the last frame for which a t11FcSpSaNotifyAuthFailure was generated. De Santi, et al. Standards Track [Page 191] RFC 5324 MIB for FC-SP September 2008 If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is zero." ::= { t11FcSpSaControlEntry 2 } t11FcSpSaControlSource OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The S_ID contained in the last frame for which a t11FcSpSaNotifyAuthFailure was generated. If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is the zero-length string." ::= { t11FcSpSaControlEntry 3 } t11FcSpSaControlDestination OBJECT-TYPE SYNTAX FcAddressIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The D_ID contained in the last frame for which a t11FcSpSaNotifyAuthFailure was generated. If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is the zero-length string." ::= { t11FcSpSaControlEntry 4 } t11FcSpSaControlFrame OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-only STATUS current DESCRIPTION "The binary content of the last frame for which a t11FcSpSaNotifyAuthFailure was generated. If more than 256 bytes of the frame are available, then this object contains the first 256 bytes. If less than 256 bytes of the frame are available, then this object contains the first N bytes, where N is greater or equal to zero. If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is the zero-length string." ::= { t11FcSpSaControlEntry 5 } t11FcSpSaControlElapsed OBJECT-TYPE De Santi, et al. Standards Track [Page 192] RFC 5324 MIB for FC-SP September 2008 SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The elapsed time since the last generation of a t11FcSpSaNotifyAuthFailure notification on the same Fabric, or the value of sysUpTime if no t11FcSpSaNotifyAuthFailure notifications have been generated since the last restart." ::= { t11FcSpSaControlEntry 6 } t11FcSpSaControlSuppressed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of occurrences of an Authentication failure on a Fabric that were suppressed because they occurred on the same Fabric within the same time window as a previous Authentication failure for which a t11FcSpSaNotifyAuthFailure notification was generated. The value of this object is reset to zero on a restart of the network management subsystem, and whenever a t11FcSpSaNotifyAuthFailure notification is generated. In the event that the value of this object reaches its maximum value, it remains at that value until it is reset on the generation of the next t11FcSpSaNotifyAuthFailure notification." ::= { t11FcSpSaControlEntry 7 } t11FcSpSaControlWindow OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The length of a time window that begins when a t11FcSpSaNotifyAuthFailure notification is generated for any Security Association on a particular Fabric. For the duration of the time window, further Authentication failures occurring for the same Security Association are counted but no t11FcSpSaNotifyAuthFailure notification is generated. When this object is modified before the end of a time window, that time window is immediately terminated, i.e., the next Authentication failure on the relevant Fabric after the modification will cause a new time window to De Santi, et al. Standards Track [Page 193] RFC 5324 MIB for FC-SP September 2008 begin with the new length." DEFVAL { 300 } ::= { t11FcSpSaControlEntry 8 } t11FcSpSaControlMaxNotifs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of t11FcSpSaNotifyAuthFailure notifications to be generated per Fabric within a t11FcSpSaControlWindow time window. Subsequent Authentication failures occurring on the same Fabric in the same time window are counted, but no t11FcSpSaNotifyAuthFailure notification is generated. When this object is modified before the end of a time window, that time window is immediately terminated, i.e., the next Authentication failure on the relevant Fabric after the modification will cause a new time window to begin with the new length." DEFVAL { 16 } ::= { t11FcSpSaControlEntry 9 } t11FcSpSaControlLifeExcdEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether t11FcSpSaNotifyLifeExceeded notifications should be generated for this Fabric." DEFVAL { true } ::= { t11FcSpSaControlEntry 10 } t11FcSpSaControlLifeExcdSpi OBJECT-TYPE SYNTAX T11FcSpiIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The SPI of the SA that was most recently terminated because its lifetime (in seconds or in passed bytes) was exceeded. Such terminations include those due to a failed attempt to renew an SA after its lifetime was exceeded." ::= { t11FcSpSaControlEntry 11 } t11FcSpSaControlLifeExcdDir OBJECT-TYPE SYNTAX T11FcSaDirection De Santi, et al. Standards Track [Page 194] RFC 5324 MIB for FC-SP September 2008 MAX-ACCESS read-only STATUS current DESCRIPTION "The direction of frame transmission on the SA that was most recently terminated because its lifetime (in seconds or in passed bytes) was exceeded." ::= { t11FcSpSaControlEntry 12 } t11FcSpSaControlLifeExcdTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time of the most recent termination of an SA due to its lifetime (in seconds or in passed bytes) being exceeded. Such terminations include those due to a failed attempt to renew an SA after its lifetime was exceeded." ::= { t11FcSpSaControlEntry 13 } -- -- Notification definitions -- t11FcSpSaNotifyAuthFailure NOTIFICATION-TYPE OBJECTS { t11FcSpSaControlInboundSpi, t11FcSpSaControlSource, t11FcSpSaControlDestination, t11FcSpSaControlFrame, t11FcSpSaControlElapsed, t11FcSpSaControlSuppressed } STATUS current DESCRIPTION "When this notification is generated, it indicates the occurrence of an Authentication failure for a received FC-2 or CT_IU frame. The t11FcSpSaControlInboundSpi, t11FcSpSaControlSource, and t11FcSpSaControlDestination objects in the varbindlist are the frame's SPI, source and destination addresses, respectively. t11FcSpSaControlFrame provides the (beginning of the) frame's content if such is available. This notification is generated only for the first occurrence of an Authentication failure on a Fabric within a time window. Subsequent occurrences of an Authentication Failure on the same Fabric within the same time window are counted but suppressed. De Santi, et al. Standards Track [Page 195] RFC 5324 MIB for FC-SP September 2008 The value of t11FcSpSaControlElapsed contains (a lower bound on) the elapsed time since the last generation of this notification for the same Fabric. The value of t11FcSpSaControlSuppressed contains the number of generations which were suppressed in the time window after that last generation, or zero if unknown." ::= { t11FcSpSaMIBNotifications 1 } t11FcSpSaNotifyLifeExceeded NOTIFICATION-TYPE OBJECTS { t11FcSpSaControlLifeExcdSpi, t11FcSpSaControlLifeExcdDir } STATUS current DESCRIPTION "This notification is generated when the lifetime (in seconds or in passed bytes) of an SA is exceeded, and the SA is either immediately terminated or is terminated because an attempt to renew the SA fails. The values of t11FcSpSaControlLifeExcdSpi and t11FcSpSaControlLifeExcdDir contain the SPI and direction of the terminated SA." ::= { t11FcSpSaMIBNotifications 2 } -- -- Conformance -- t11FcSpSaMIBCompliances OBJECT IDENTIFIER ::= { t11FcSpSaMIBConformance 1 } t11FcSpSaMIBGroups OBJECT IDENTIFIER ::= { t11FcSpSaMIBConformance 2 } t11FcSpSaMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement FC-SP Security Associations." MODULE -- this module MANDATORY-GROUPS { t11FcSpSaCapabilityGroup, t11FcSpSaParamStatusGroup, t11FcSpSaSummaryCountGroup, t11FcSpSaProposalGroup, t11FcSpSaDropBypassGroup, t11FcSpSaActiveGroup, t11FcSpSaNotifInfoGroup, t11FcSpSaNotificationGroup } -- The following is an auxiliary (listed in an INDEX clause) De Santi, et al. Standards Track [Page 196] RFC 5324 MIB for FC-SP September 2008 -- object for which the SMIv2 does not allow an OBJECT clause -- to be specified, but for which this MIB has the following -- compliance requirement: -- OBJECT t11FcSpSaIfIndex -- DESCRIPTION -- Compliance requires support for either one of: -- - individual interfaces using ifIndex values, or -- - the use of the zero value. -- Write access is not required for any objects in this MIB module: OBJECT t11FcSpSaIfStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTransStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaIfReplayPrevention MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaIfReplayWindowSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaIfTerminateAllSas MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaPropSecurityProt MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaPropTSelListIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaPropTransListIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaPropAcceptAlgorithm De Santi, et al. Standards Track [Page 197] RFC 5324 MIB for FC-SP September 2008 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaPropRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropStartSrcAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropEndSrcAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropStartDstAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropEndDstAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropStartRCtl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropEndRCtl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropStartType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropEndType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelPropRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTransSecurityProt De Santi, et al. Standards Track [Page 198] RFC 5324 MIB for FC-SP September 2008 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTransEncryptAlg MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTransEncryptKeyLen MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTransIntegrityAlg MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTransRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByAction MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByStartSrcAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByEndSrcAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByStartDstAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByEndDstAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByStartRCtl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByEndRCtl MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByStartType De Santi, et al. Standards Track [Page 199] RFC 5324 MIB for FC-SP September 2008 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByEndType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaTSelDrByRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaPairTerminate MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaControlAuthFailEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaControlWindow MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaControlMaxNotifs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT t11FcSpSaControlLifeExcdEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { t11FcSpSaMIBCompliances 1 } -- Units of Conformance t11FcSpSaCapabilityGroup OBJECT-GROUP OBJECTS { t11FcSpSaIfEspHeaderCapab, t11FcSpSaIfCTAuthCapab, t11FcSpSaIfIKEv2Capab, t11FcSpSaIfIkev2AuthCapab } STATUS current DESCRIPTION "A collection of objects containing information related to capabilities of FC-SP entities." ::= { t11FcSpSaMIBGroups 1 } t11FcSpSaParamStatusGroup OBJECT-GROUP De Santi, et al. Standards Track [Page 200] RFC 5324 MIB for FC-SP September 2008 OBJECTS { t11FcSpSaIfStorageType, t11FcSpSaIfReplayPrevention, t11FcSpSaIfReplayWindowSize, t11FcSpSaIfDeadPeerDetections, t11FcSpSaIfTerminateAllSas } STATUS current DESCRIPTION "A collection of objects containing parameters and status information related to FC-SP entities." ::= { t11FcSpSaMIBGroups 2 } t11FcSpSaSummaryCountGroup OBJECT-GROUP OBJECTS { t11FcSpSaIfOutDrops, t11FcSpSaIfOutBypasses, t11FcSpSaIfOutProcesses, t11FcSpSaIfOutUnMatcheds, t11FcSpSaIfInUnprotUnmtchDrops, t11FcSpSaIfInDetReplays, t11FcSpSaIfInUnprotMtchDrops, t11FcSpSaIfInBadXforms, t11FcSpSaIfInGoodXforms, t11FcSpSaIfInProtUnmtchs } STATUS current DESCRIPTION "A collection of objects containing summary counters for FC-SP Security Associations." ::= { t11FcSpSaMIBGroups 3 } t11FcSpSaProposalGroup OBJECT-GROUP OBJECTS { t11FcSpSaPropSecurityProt, t11FcSpSaPropTSelListIndex, t11FcSpSaPropTransListIndex, t11FcSpSaPropAcceptAlgorithm, t11FcSpSaPropOutMatchSucceeds, t11FcSpSaPropRowStatus, t11FcSpSaTSelPropDirection, t11FcSpSaTSelPropStartSrcAddr, t11FcSpSaTSelPropEndSrcAddr, t11FcSpSaTSelPropStartDstAddr, t11FcSpSaTSelPropEndDstAddr, t11FcSpSaTSelPropStartRCtl, t11FcSpSaTSelPropEndRCtl, t11FcSpSaTSelPropStartType, t11FcSpSaTSelPropEndType, t11FcSpSaTSelPropStorageType, t11FcSpSaTSelPropRowStatus De Santi, et al. Standards Track [Page 201] RFC 5324 MIB for FC-SP September 2008 } STATUS current DESCRIPTION "A collection of objects containing information related to making and accepting proposals for FC-SP Security Associations." ::= { t11FcSpSaMIBGroups 4 } t11FcSpSaDropBypassGroup OBJECT-GROUP OBJECTS { t11FcSpSaTSelDrByAction, t11FcSpSaTSelDrByStartSrcAddr, t11FcSpSaTSelDrByEndSrcAddr, t11FcSpSaTSelDrByStartDstAddr, t11FcSpSaTSelDrByEndDstAddr, t11FcSpSaTSelDrByStartRCtl, t11FcSpSaTSelDrByEndRCtl, t11FcSpSaTSelDrByStartType, t11FcSpSaTSelDrByEndType, t11FcSpSaTSelDrByMatches, t11FcSpSaTSelDrByRowStatus } STATUS current DESCRIPTION "A collection of objects containing information about Traffic Selectors of traffic to drop or bypass for FC-SP Security." ::= { t11FcSpSaMIBGroups 5 } t11FcSpSaActiveGroup OBJECT-GROUP OBJECTS { t11FcSpSaPairSecurityProt, t11FcSpSaPairTransListIndex, t11FcSpSaPairTransIndex, t11FcSpSaPairLifetimeLeft, t11FcSpSaPairLifetimeLeftUnits, t11FcSpSaPairTerminate, t11FcSpSaPairInProtUnMatchs, t11FcSpSaPairInDetReplays, t11FcSpSaPairInBadXforms, t11FcSpSaPairInGoodXforms, t11FcSpSaTransSecurityProt, t11FcSpSaTransEncryptAlg, t11FcSpSaTransEncryptKeyLen, t11FcSpSaTransIntegrityAlg, t11FcSpSaTransStorageType, t11FcSpSaTransRowStatus, t11FcSpSaTSelNegInInboundSpi, t11FcSpSaTSelNegInStartSrcAddr, t11FcSpSaTSelNegInEndSrcAddr, De Santi, et al. Standards Track [Page 202] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaTSelNegInStartDstAddr, t11FcSpSaTSelNegInEndDstAddr, t11FcSpSaTSelNegInStartRCtl, t11FcSpSaTSelNegInEndRCtl, t11FcSpSaTSelNegInStartType, t11FcSpSaTSelNegInEndType, t11FcSpSaTSelNegInUnpMtchDrops, t11FcSpSaTSelNegOutInboundSpi, t11FcSpSaTSelNegOutStartSrcAddr, t11FcSpSaTSelNegOutEndSrcAddr, t11FcSpSaTSelNegOutStartDstAddr, t11FcSpSaTSelNegOutEndDstAddr, t11FcSpSaTSelNegOutStartRCtl, t11FcSpSaTSelNegOutEndRCtl, t11FcSpSaTSelNegOutStartType, t11FcSpSaTSelNegOutEndType, t11FcSpSaTSelSpiDirection, t11FcSpSaTSelSpiTrafSelPtr } STATUS current DESCRIPTION "A collection of objects containing information related to currently active FC-SP Security Associations." ::= { t11FcSpSaMIBGroups 6 } t11FcSpSaNotifInfoGroup OBJECT-GROUP OBJECTS { t11FcSpSaControlAuthFailEnable, t11FcSpSaControlInboundSpi, t11FcSpSaControlSource, t11FcSpSaControlDestination, t11FcSpSaControlFrame, t11FcSpSaControlElapsed, t11FcSpSaControlSuppressed, t11FcSpSaControlWindow, t11FcSpSaControlMaxNotifs, t11FcSpSaControlLifeExcdEnable, t11FcSpSaControlLifeExcdSpi, t11FcSpSaControlLifeExcdDir, t11FcSpSaControlLifeExcdTime } STATUS current DESCRIPTION "A collection of objects containing information related to notifications of events concerning FC-SP Security Associations." ::= { t11FcSpSaMIBGroups 7 } De Santi, et al. Standards Track [Page 203] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { t11FcSpSaNotifyAuthFailure, t11FcSpSaNotifyLifeExceeded } STATUS current DESCRIPTION "A collection of notifications of events concerning FC-SP Security Associations." ::= { t11FcSpSaMIBGroups 8 } END 7. IANA Considerations IANA has made one MIB OID assignment, under the appropriate subtree, for each of the five MIB modules defined in this document. 8. Security Considerations In this section, the first sub-section explains why this document does not define MIB objects for particular items of (management) information. This is followed by one sub-section for each of the MIB modules defined in section 6, listing their individual Security Considerations. The section concludes with Security Considerations common to all of these MIB modules. The key word "RECOMMENDED" contained in this section is to be interpreted as described in BCP 14 [RFC2119]. 8.1. Information Not Defined in This Document This document doesn't define any MIB objects for the secrets that need to be known/determined by FC-SP entities in order to use DH-CHAP to authenticate each other. Such secrets are "highly sensitive" and need to be "strong secrets" (e.g., randomly generated and/or from an external source, see section 5.4.8 of [FC-SP]) rather than just passwords. Thus, such secrets need to be managed by mechanisms other than the MIB modules defined here. 8.2. The T11-FC-SP-TC-MIB Module This MIB module defines some data types and assigns some Object Identifiers, for use as the syntax and as values of MIB objects, respectively, but it itself defines no MIB objects. Thus, there is no direct read or write access via a management protocol, such as SNMP, to these definitions. Nevertheless, it does include the assignment of enumerations and OIDs to represent cryptographic algorithms/transforms, and it is appropriate for such assignments to De Santi, et al. Standards Track [Page 204] RFC 5324 MIB for FC-SP September 2008 be augmented with new assignments as and when new algorithms/transforms are available. 8.3. The T11-FC-SP-AUTHENTICATION-MIB Module There are several management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability are: t11FcSpAuStorageType - could cause changes in the configuration to be retained or not retained over restarts, against the wishes of management. t11FcSpAuSendRejNotifyEnable t11FcSpAuRcvRejNotifyEnable - could cause the suppression of SNMP notifications (e.g., of authentication failures or protocol failures), or the disruption of network operations due to the generation of unwanted notifications. t11FcSpAuDefaultLifetime t11FcSpAuDefaultLifetimeUnits - could cause the lifetimes of Security Associations to be extended longer than might be secure, or shortened to cause an increase in the overhead of using security. t11FcSpAuRejectMaxRows - could cause a smaller audit trail of Authentication rejects, thereby hiding the tracks of an attacker, or a larger audit trail of Authentication rejects causing resources to be wasted. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: t11FcSpAuEntityTable - the capabilities of FC-SP Authentication entities in terms of what cryptographic algorithms they support, and various configuration parameters of FC-SP Authentication entities. De Santi, et al. Standards Track [Page 205] RFC 5324 MIB for FC-SP September 2008 t11FcSpAuIfStatTable - the mapping of which FC-SP Authentication entities operate on which interfaces. t11FcSpAuRejectTable - an audit trail of authentication failures and other Authentication Protocol failures. 8.4. The T11-FC-SP-ZONING-MIB Module There are several management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability are: t11FcSpZsServerEnabled - could cause FC-SP Zoning mode to be enabled or not enabled, against the wishes of management. t11FcSpZoneSetHashStatus - could cause an FC-SP implementation to recalculate the values of the Active Zone Set Hash and the Zone Set Database Hash more frequently than is required by management. t11FcSpZsNotifyJoinSuccessEnable t11FcSpZsNotifyJoinFailureEnable - could cause the suppression of SNMP notifications that a Switch in one Fabric has successfully joined/failed to join with a Switch in another Fabric, or the disruption of network operations due to the generation of unwanted notifications. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the objects and their sensitivity/vulnerability: t11FcSpZsServerCapabilityObject t11FcSpZsServerEnabled - the FC-SP Zoning capabilities and status of the FC-SP implementation. De Santi, et al. Standards Track [Page 206] RFC 5324 MIB for FC-SP September 2008 t11FcSpZoneSetHashStatus t11FcSpActiveZoneSetHashType t11FcSpActiveZoneSetHash t11FcSpZoneSetDatabaseHashType t11FcSpZoneSetDatabaseHash - the current values of the Active Zone Set Hash and the Zone Set Database Hash. 8.5. The T11-FC-SP-POLICY-MIB Module There are many management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The objects and tables and their sensitivity/vulnerability are: t11FcSpPoNaSummaryTable t11FcSpPoNaSwListTable t11FcSpPoNaSwMembTable t11FcSpPoNaNoMembTable t11FcSpPoNaCtDescrTable t11FcSpPoNaSwConnTable t11FcSpPoNaIpMgmtTable - could change the currently inactive FC-SP Fabric Policies, so as to allow unauthorized connectivity of Switches and/or Nodes to the network, or between Switches in the network, or, to prohibit such connectivity even when authorized. t11FcSpPoNaIpMgmtTable t11FcSpPoNaWkpDescrTable - could change the currently inactive FC-SP Fabric Policies, so as to allow unauthorized management access to Switches, or prohibit authorized management access to Switches. t11FcSpPoNaSummaryTable t11FcSpPoNaSwMembTable t11FcSpPoNaNoMembTable t11FcSpPoNaAttribTable t11FcSpPoNaAuthProtTable - could change the currently inactive FC-SP Fabric Policies, so as to allow Security Associations with reduced security or require Security Associations that are unnecessarily secure. De Santi, et al. Standards Track [Page 207] RFC 5324 MIB for FC-SP September 2008 t11FcSpPoOperActivate t11FcSpPoOperDeActivate - could cause the currently active FC-SP Fabric Policies to be de-activated and currently inactive FC-SP Fabric Policies (e.g., those modified as above) to be activated instead. t11FcSpPoStorageType - could cause changes in the configuration and/or in FC-SP Fabric Policies to be retained or not retained over restarts, against the wishes of management. t11FcSpPoNotificationEnable - could cause the suppression of SNMP notifications on the successful/unsuccessful activation/deactivation of Fabric Policies, and thereby hide successful/failed attempts to make unauthorized changes, or cause the disruption of network operations due to the generation of unwanted notifications. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and their sensitivity/vulnerability: t11FcSpPoTable t11FcSpPoSummaryTable t11FcSpPoSwMembTable t11FcSpPoNoMembTable t11FcSpPoCtDescrTable t11FcSpPoSwConnTable t11FcSpPoIpMgmtTable t11FcSpPoWkpDescrTable t11FcSpPoAttribTable t11FcSpPoAuthProtTable - the currently active FC-SP Fabric Policies that can be examined by an attacker looking for possible security vulnerabilities in the active policies. De Santi, et al. Standards Track [Page 208] RFC 5324 MIB for FC-SP September 2008 8.6. The T11-FC-SP-SA-MIB Module There are several management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These objects and their sensitivity/vulnerability are: t11FcSpSaIfStorageType t11FcSpSaTSelPropStorageType t11FcSpSaTransStorageType - could cause changes in configuration information related to FC-SP Security Associations to be retained or not retained over restarts, against the wishes of management. t11FcSpSaIfReplayPrevention t11FcSpSaIfReplayWindowSize - could cause changes in the operation of anti-replay protection, thereby permitting an attacker to conduct replay attacks, or requiring FC-SP implementations to engage in unnecessary protection against replay. t11FcSpSaIfTerminateAllSas t11FcSpSaPairTerminate - could cause FC-SP Security Associations to be aborted unnecessarily. t11FcSpSaControlAuthFailEnable - could cause the suppression of SNMP notifications on the occurrence of Authentication failures for received FC-2 or CT_IU frames, thereby hiding attempts to subvert security measures, or cause the disruption of network operations due to the generation of unwanted notifications. t11FcSpSaControlLifeExcdEnable - could cause the suppression of SNMP notifications on the occurrence of an FC-SP Security Association exceeding its lifetime, thereby possibly causing disruption to network usage due to a delay in determining the problem and/or re- establishing the Security Association. De Santi, et al. Standards Track [Page 209] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaControlWindow - could cause the suppression of second and subsequent SNMP notifications on the occurrence of Authentication failures for received FC-2 or CT_IU frames, thereby masking repeated attempts to subvert security measures, or cause the disruption of network operations due to the generation of unwanted notifications. t11FcSpSaControlMaxNotifs - could cause the suppression of all SNMP notifications on the occurrence of Authentication failures for received FC-2 or CT_IU frames, thereby masking attempts to subvert security measures, or cause the disruption of network operations due to the generation of unwanted notifications. t11FcSpSaPropTable t11FcSpSaTSelPropTable t11FcSpSaTransTable - could cause an FC-SP entity to propose the setup of Security Associations that apply to a different selection of traffic and/or using different security transforms, such that some traffic has a reduced level of security that might improve an attacker's chance of subverting security, or an increased level of security that would involve unnecessary security processing, or cause the negotiation of Security Associations to fail to find commonly acceptable parameters such that no Security Associations can be established. t11FcSpSaTSelDrByTable - could cause an FC-SP entity to select different sets of traffic which are: a) to be sent/received without being protected by FC-SP security, thereby providing an attacker with access to read authentic traffic or the ability to introduce unauthentic traffic; or b) to be dropped instead of being sent/after being received, thereby causing disruption to network usage. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: De Santi, et al. Standards Track [Page 210] RFC 5324 MIB for FC-SP September 2008 t11FcSpSaIfTable - information concerning the capabilities, parameters and status of an FC-SP entity's support for Security Associations. t11FcSpSaPropTable t11FcSpSaTSelPropTable t11FcSpSaTransTable - information on the proposals that will be used by an FC-SP entity to negotiate Security Associations. t11FcSpSaTSelDrByTable - information on which subsets of traffic an FC-SP entity will send or receive without being protected by FC-SP security, or will drop before sending/after receiving. t11FcSpSaPairTable t11FcSpSaTSelNegInTable t11FcSpSaTSelNegOutTable t11FcSpSaTSelSpiTable - information on which Security Associations are currently active, what subsets of traffic they are carrying, and what security protection is being given to them. 8.7. Recommendations Common to All MIB Modules SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Because the two algorithms currently specified for T11FcSpPolicyHashFormat are SHA-1 and SHA-256, the definition of T11FcSpHashCalculationStatus expresses a concern in regard to not De Santi, et al. Standards Track [Page 211] RFC 5324 MIB for FC-SP September 2008 incrementally recomputing the hashes after each change when a series of multiple related changes are being made. This method of reducing computation is intended as a responsiveness measure (i.e., cooperating SNMP managers and agents can get things done faster), not as a Denial-of-Service (DoS) countermeasure. Nevertheless, implementations should also consider the DoS possibilities in these scenarios; potential countermeasures include: requiring authentication for SETs and the rate-limiting of SET operations if they can cause significant computation. 9. Normative References [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. De Santi, et al. Standards Track [Page 212] RFC 5324 MIB for FC-SP September 2008 [RFC4438] DeSanti, C., Gaonkar, V., Vivek, H., McCloghrie, K., and S. Gai, "Fibre-Channel Name Server MIB", RFC 4438, April 2006. [RFC4439] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Address Manager MIB", RFC 4439, March 2006. [RFC4936] DeSanti, C., Vivek, H., McCloghrie, K., and S. Gai, "Fibre Channel Zone Server MIB", RFC 4936, August 2007. [FC-FS-2] "Fibre Channel - Framing and Signaling-2 (FC-FS-2)", ANSI INCITS 424-2007, February 2007. [FC-GS-5] "Fibre Channel - Generic Services-5 (FC-GS-5)", ANSI INCITS 427-2006, December 2006. [FC-SP] "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS 426-2007, T11/Project 1570-D, February 2007. [FC-SW-4] "Fibre Channel - Switch Fabric-4 (FC-SW-4)", ANSI INCITS 418-2006, April 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10. Informative References [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993. [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC2837] Teow, K., "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", RFC 2837, May 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. De Santi, et al. Standards Track [Page 213] RFC 5324 MIB for FC-SP September 2008 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006. [RFC4625] DeSanti, C., McCloghrie, K., Kode, S., and S. Gai, "Fibre Channel Routing Information MIB", RFC 4625, September 2006. [RFC4626] DeSanti, C., Gaonkar, V., McCloghrie, K., and S. Gai, "MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol", RFC 4626, September 2006. [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006. [RFC4747] Kipp, S., Ramkumar, G., and K. McCloghrie, "The Virtual Fabrics MIB", RFC 4747, November 2006. [RFC4935] DeSanti, C., Vivek, H., McCloghrie, K., and S. Gai, "Fibre Channel Fabric Configuration Server MIB", RFC 4935, August 2007. [RFC4983] DeSanti, C., Vivek, H., McCloghrie, K., and S. Gai, "Fibre Channel Registered State Change Notification (RSCN) MIB", RFC 4983, August 2007. De Santi, et al. Standards Track [Page 214] RFC 5324 MIB for FC-SP September 2008 11. Acknowledgements This document was initially developed and approved by the INCITS Task Group T11.5 (http://www.t11.org) as the SM-FSM project. We wish to acknowledge the contributions and comments from the INCITS Technical Committee T11, including the following: T11 Chair: Robert Snively, Brocade T11 Vice Chair: Claudio DeSanti, Cisco Systems T11.5 Chair: Roger Cummings, Symantec T11.5 members: David Black, EMC Don Fraser, HP Larry Hofer, Brocade Scott Kipp, Brocade Ralph Weber, ENDL The document was subsequently a work item of the IMSS Working Group (of the IETF), chaired by David Black (EMC Corporation). Bert Wijnen (Alcatel-Lucent) deserves many thanks for his thorough review of all five MIB modules in this (large!) document. We also wish to acknowledge Dan Romascanu (Avaya), the IETF Area Director, for his comments and assistance. Authors' Addresses Claudio DeSanti Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-9172 EMail: cds@cisco.com Fabio Maino Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853-7530 EMail: fmaino@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-526-5260 EMail: kzm@cisco.com De Santi, et al. Standards Track [Page 215] RFC 5324 MIB for FC-SP September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. De Santi, et al. Standards Track [Page 216] snmp-mibs-downloader-1.1/mibrfcs/rfc5427.txt0000644000000000000000000004264511402176072015577 0ustar Network Working Group G. Keeni Request for Comments: 5427 Cyber Solutions Inc. Category: Standards Track March 2009 Textual Conventions for Syslog Management 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. Keeni Standards Track [Page 1] RFC 5427 Syslog MIB-TC March 2009 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Background ......................................................2 3. The Syslog Textual Conventions MIB ..............................3 4. Security Considerations .........................................7 5. IANA Considerations .............................................7 6. References ......................................................8 6.1. Normative References .......................................8 6.2. Informative References .....................................8 7. Acknowledgments .................................................8 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Background Operating systems, processes, and applications, collectively termed "Facilities" in the following, generate messages indicating their own status or the occurrence of events. These messages have come to be known as syslog messages. A syslog message in general will contain among other things a code representing the Facility that generated the message and a code representing the Severity of the message. The Facility and the Severity codes are commonly used to categorize and select received syslog messages for processing and display. The Facility codes have been useful in qualifying the originator of the content of the messages but in some cases they are not specific enough to explicitly identify the originator. Implementations of the syslog protocol [RFC5424] that contain structured data elements (SDEs) should use these SDEs to clarify the entity that originated the content of the message. This document defines a set of textual conventions (TCs) that can be used to represent Facility and Severity codes commonly used in syslog messages. Keeni Standards Track [Page 2] RFC 5427 Syslog MIB-TC March 2009 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The Syslog Textual Conventions MIB SYSLOG-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] syslogTCMIB MODULE-IDENTITY LAST-UPDATED "200903300000Z" -- 30 March 2009 ORGANIZATION "IETF Syslog Working Group" CONTACT-INFO " Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 EMail: glenn@cysols.com Support Group EMail: syslog@ietf.org " DESCRIPTION "The MIB module containing textual conventions for syslog messages. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Keeni Standards Track [Page 3] RFC 5427 Syslog MIB-TC March 2009 - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5427; see the RFC itself for full legal notices. " REVISION "200903300000Z" -- 30 March 2009 DESCRIPTION "The initial version, published as RFC 5427." ::= { mib-2 173 } -- ------------------------------------------------------------- -- Textual Conventions -- ------------------------------------------------------------- SyslogFacility ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the Facilities that originate syslog messages. The Facilities of syslog messages are numerically coded with decimal values. For interoperability and backwards- compatibility reasons, this document specifies a normative mapping between a label, which represents a Facility, and the corresponding numeric value. This label could be used in, for example, SNMP Manager user interfaces. Keeni Standards Track [Page 4] RFC 5427 Syslog MIB-TC March 2009 The label itself is often semantically meaningless because it is impractical to attempt to enumerate all possible Facilities, and many daemons and processes do not have an explicitly assigned Facility code or label. For example, there is no Facility label corresponding to an HTTP service. An HTTP service implementation might log messages as coming from, for example, 'local7' or 'uucp'. This is typical current practice, and originators, relays, and collectors can be configured to properly handle this situation. For improved accuracy, an application can also include an APP-NAME structured data element. Note that operating system mechanisms for configuring syslog, such as syslog.conf, have not yet been standardized and might use different sets of Facility labels and/or mapping between Facility labels and Facility codes than the MIB. In particular, the labels corresponding to Facility codes 4, 10, 13, and 14, and the code corresponding to the Facility label 'cron' are known to vary across different operating systems. To distinguish between the labels corresponding to Facility codes 9 and 15, a label of 'cron2' is assigned to the Facility code 15. This list is not intended to be exhaustive; other differences might exist, and new differences might be introduced in the future. The mapping specified here MUST be used in a MIB network management interface, even though a particular syslog implementation might use a different mapping in a different network management interface. " REFERENCE "The Syslog Protocol (RFC5424): Table 1" SYNTAX INTEGER { kern (0), -- kernel messages user (1), -- user-level messages mail (2), -- mail system messages daemon (3), -- system daemons' messages auth (4), -- authorization messages syslog (5), -- messages generated internally by -- syslogd lpr (6), -- line printer subsystem messages news (7), -- network news subsystem messages uucp (8), -- UUCP subsystem messages cron (9), -- clock daemon messages authpriv (10),-- security/authorization messages Keeni Standards Track [Page 5] RFC 5427 Syslog MIB-TC March 2009 ftp (11),-- ftp daemon messages ntp (12),-- NTP subsystem messages audit (13),-- audit messages console (14),-- console messages cron2 (15),-- clock daemon messages local0 (16), local1 (17), local2 (18), local3 (19), local4 (20), local5 (21), local6 (22), local7 (23) } SyslogSeverity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the Severity levels of syslog messages. The Severity levels of syslog messages are numerically coded with decimal values. For interoperability and backwards-compatibility reasons, this document specifies a normative mapping between a label, which represents a Severity level, and the corresponding numeric value. This label could be used in, for example, SNMP Manager user interfaces. The label itself is often semantically meaningless because it is impractical to attempt to strictly define the criteria for each Severity level, and the criteria that is used by syslog originators is, and has historically been, implementation-dependent. Note that operating system mechanisms for configuring syslog, such as syslog.conf, have not yet been standardized and might use different sets of Severity labels and/or mapping between Severity labels and Severity codes than the MIB. For example, the foobar application might log messages as 'crit' based on some subjective criteria. Yet the operator can configure syslog to forward these messages, even though the criteria for 'crit' may differ from one originator to another. This is typical current practice, and originators, relays, and collectors can be configured to properly handle this situation. Keeni Standards Track [Page 6] RFC 5427 Syslog MIB-TC March 2009 " REFERENCE "The Syslog Protocol (RFC5424): Table 2" SYNTAX INTEGER { emerg (0), -- emergency; system is unusable alert (1), -- action must be taken immediately crit (2), -- critical condition err (3), -- error condition warning (4), -- warning condition notice (5), -- normal but significant condition info (6), -- informational message debug (7) -- debug-level messages } END 4. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. This document has therefore no impact on the security of the Internet. Since objects defined using the TCs defined in this document may introduce security issues, the user of these TCs should read the security considerations section of [RFC5424]. 5. IANA Considerations The MIB modules in this document use the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- syslogTCMIB { mib-2 173 } Keeni Standards Track [Page 7] RFC 5427 Syslog MIB-TC March 2009 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 6.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 7. Acknowledgments This document is a product of the Syslog Working Group. The author would like to thank Chris Lonvick, David Harrington, Juergen Schoenwaelder, and Pasi Eronen for their comments and suggestions. Author's Address Glenn Mansfield Keeni Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Keeni Standards Track [Page 8] snmp-mibs-downloader-1.1/mibrfcs/rfc5428.txt0000644000000000000000000023047311402176072015576 0ustar Network Working Group S. Channabasappa Request for Comments: 5428 CableLabs Category: Standards Track W. De Ketelaere tComLabs E. Nechamkin Broadcom Corp. April 2009 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. Channabasappa, et al. Standards Track [Page 1] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Introduction ....................................................2 3. Terminology .....................................................3 3.1. PacketCable ................................................3 3.2. IPCablecom .................................................3 3.3. MTA ........................................................4 3.4. Endpoint ...................................................4 3.5. MSO ........................................................4 3.6. UDP ........................................................4 4. Overview ........................................................4 4.1. Structure of the MIB .......................................5 4.2. pktcEventControl ...........................................6 4.3. pktcEventThrottle ..........................................6 4.4. pktcEventStatus ............................................7 4.5. pktcEvent ..................................................7 4.6. pktcEventLog ...............................................7 4.7. pktcEventNotifications .....................................7 5. Relationship to Other MIB Modules ...............................7 5.1. MIB Modules Required for IMPORTS ...........................7 6. Definitions .....................................................8 7. IANA Considerations ............................................32 8. Security Considerations ........................................32 9. Acknowledgments ................................................34 10. Normative References ..........................................35 11. Informative References ........................................36 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Introduction A Multimedia Terminal Adapter (MTA) is used to deliver broadband Internet, data, and/or voice access jointly with telephony service to a subscriber's or customer's premises using a cable network Channabasappa, et al. Standards Track [Page 2] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 infrastructure. An MTA is normally installed at the subscriber's or customer's premises and is coupled to a multiple system operator (MSO) using a hybrid fiber coax (HFC) access network. An MTA is provisioned by the MSO for broadband Internet, data, and/or voice service. For more information on MTA provisioning, refer to [PKT-SP-PROV] and [RFC4682]. MTA devices include one or more endpoints (e.g., telephone ports), which receive call signaling information to establish ring cadence, and codecs, which provide telephony service. For more information on call signaling refer to, [PKT-SP-MGCP] and [RFC3435]. For more information on codecs, refer to [PKT-SP-CODEC]. Given the complexity of such systems, it is important that a suitable event management mechanism be defined to allow for effective management. This MIB module provides objects suitable for generation and management of events on the MTA. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terms "MIB module" and "information module" are used interchangeably in this memo. As used here, both terms refer to any of the three types of information modules defined in Section 3 of RFC 2578 [RFC2578]. Some of the terms used in this memo are defined below. Some additional terms are also defined in the PacketCable(TM) Management Event Mechanism Specification [PKT-SP-MEM1.5] and the PacketCable MTA Device Provisioning Specification [PKT-SP-PROV]. 3.1. PacketCable PacketCable is a CableLabs-led initiative that is aimed at developing interoperable interface specifications for delivering advanced, real-time multimedia services over two-way cable plants. 3.2. IPCablecom IPCablecom is an ITU Telecommunication Standardization Sector (ITU-T) project that includes architecture and a series of recommendations that enable the delivery of real-time services over the cable television networks using cable modems. Channabasappa, et al. Standards Track [Page 3] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 3.3. MTA A Multimedia Terminal Adapter (MTA) is a PacketCable- or IPCablecom- compliant device providing telephony services over a cable or hybrid system used to deliver video signals to a community. It contains an interface to endpoints, a network interface, codecs, and all signaling and encapsulation functions required for Voice over IP transport, call signaling, and Quality of Service signaling. An MTA can be an embedded or standalone device. An Embedded MTA (E-MTA) is an MTA device containing an embedded Data Over Cable Service Interface Specifications (DOCSIS) cable modem. A Standalone MTA (S-MTA) is an MTA device separated from the DOCSIS cable modem by a non-DOCSIS Media Access Control (MAC) interface (e.g., Ethernet, USB). 3.4. Endpoint An endpoint or MTA endpoint is a standard RJ-11 telephony physical port located on the MTA and used for attaching the telephone device to the MTA. 3.5. MSO A Multi-System Operator is a cable company that operates many head- end locations in several cities. 3.6. UDP A User Datagram Protocol is a connectionless protocol built upon Internet Protocol (IP), as per RFC 768 [RFC768]. 4. Overview PacketCable, European Telecommunications Standards Institute (ETSI), and International Telecommunication Union Telecommunication Standardization Sector (ITU-T) IPCablecom-compliant Multimedia Terminal Adaptors (MTAs) are required to generate management events upon the occurrence of certain operational conditions (for instance, "AC power failure, MTA operational on battery power"). The complete set of conditions and the corresponding management events to be generated are specified in [PKT-SP-MEM1.5] (PacketCable), [ETSITS101909-22] (ETSI), and [ITU-T-J176] (ITU-T). In addition, the MTA manufacturer is allowed to specify vendor-specific management events. For example, vendor XYZ can specify "Memory read error, terminating process, code: XYZ123". Channabasappa, et al. Standards Track [Page 4] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 When management events are generated, they can either be stored in a local log on the MTA or transmitted using two possible mechanisms: SNMP or syslog. This choice between storing and transmitting is required to be configurable and manageable by the management station for each management event (default values can be provided when the events are defined). This document proposes a MIB that can provide for configuration and management of such management events. A means to log the events is provided within the specified MIB module. For syslog as a transport, the necessary information (format, transport, etc.) is also specified. For SNMP as a transport, the MIB objects specified in the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB as utilized, is specified in [RFC3413]. Further, each management event can be uniquely identified using the 'Organization ID' and 'Event ID'. The 'Organization ID' is the private enterprise number of the organization specifying the event (e.g., 4491 for CableLabs) and a unique identifier that identifies the event. The 'Event ID' is an identifier that uniquely identifies the event within the 'Organization ID' space. This document does not specify any management events. It only provides a mechanism to manage the storage and transmission of events. The EVENT MIB module specified in this document is intended to update the EVENT MIB modules from which it is partly derived: - the PacketCable 1.5 Management Event MIB Specification [PKT-SP-EVEMIB1.5] and - the ITU-T IPCablecom management event mechanism MIB requirements [ITU-T-J176]. Several normative and informative references are used to help define Management Event MIB objects. As a convention, wherever the requirements are equivalent at the time of the writing, the PacketCable reference is used. However, MTA implementations MUST refer to the corresponding specifications to ensure compliance. 4.1. Structure of the MIB The Management Event MIB module is identified by pktcIetfEventMib and is structured into the following sub-trees: - pktcEventControl specifies the management information pertinent to control of the device's event generation capabilities. - pktcEventThrottle specifies the management information pertinent to throttling the transmission of management events using syslog or SNMP. Channabasappa, et al. Standards Track [Page 5] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 - pktcEventStatus specifies the management information for the device to report status information related to the generated events. - pktcEvents specifies the management information for the device to list all the events it is capable of generating. - pktcEventLog specifies the management information for the device to store the generated events. - pktcEventNotifications specifies the management information that defines the SNMP trap and inform messages. 4.2. pktcEventControl The group of objects in this sub-tree provide for three important controls: ability to reset the event logs and event descriptions, syslog configuration, and event classes. Some highlights are as follows: pktcEventReset - this MIB object allows a management station to reset the event logs, the event descriptions, or both. pktcEventSyslog - this group of MIB objects allows the management station to provide information for transmission of events to a syslog server, such as message formats and transport protocols. pktcEventClassTable - this MIB table allows for MTAs to classify the management events into different categories, termed 'event classes'. It then allows for common operations to be affected across all the events pertaining to a specific event class. 4.3. pktcEventThrottle As indicated earlier, the generated events can be stored locally or transmitted using SNMP, syslog, or both. However, the management stations receiving such events may wish to control the rate of transmission of such events. This event-throttling behavior is provided by the MIB objects in this sub-tree. Some highlights are as follows: pktcEventThrottleAdminStatus - this MIB object allows for transmissions to be unconstrained, maintained below threshold, stopped at the threshold, or inhibited. Channabasappa, et al. Standards Track [Page 6] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 pktcEventThrottleThreshold - this MIB object specifies the throttle, i.e., the number of events over an interval that is considered to be the threshold. pktcEventThrottleInterval - this MIB object specifies the interval over which the threshold is calculated. 4.4. pktcEventStatus This sub-tree is designed to provide status information related to event transmissions. It currently contains one MIB object, pktcEventTransmissionStatus, that allows a client to report the status of event transmissions. 4.5. pktcEvent This sub-tree is designed to provide a list of all the events that can be generated by an MTA and its associated descriptions. The MIB objects are grouped under the MIB table pktcEventTable. 4.6. pktcEventLog This sub-tree is designed to allow the MTA to store all the events that are generated during its operation. The events are stored with information such as the time of the event, its description and related characteristics like severity levels. 4.7. pktcEventNotifications This sub-tree specifies the notification information, i.e., when MTAs transmit messages using SNMP traps and informs. SNMP traps refer to the SNMPv2-Trap-PDU. SNMPv1 traps are disallowed. 5. Relationship to Other MIB Modules Some management objects defined in other MIB modules are applicable to an entity implementing this MIB. In particular, it is assumed that an entity implementing the PKTC-IETF-EVENT-MIB module will also implement the 'interfaces' group of the IF-MIB [RFC2863]. 5.1. MIB Modules Required for IMPORTS The PKTC-IETF-EVENT-MIB MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], INET-ADDRESS-MIB [RFC4001], SNMP-TARGET-MIB [RFC3413], SNMP-NOTIFICATION-MIB [RFC3413], and the SYSLOG-TC-MIB [RFC5427]. Channabasappa, et al. Standards Track [Page 7] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 6. Definitions PKTC-IETF-EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI TruthValue, DateAndTime, TEXTUAL-CONVENTION FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF ifPhysAddress FROM IF-MIB InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB snmpTargetBasicGroup, snmpTargetResponseGroup FROM SNMP-TARGET-MIB snmpNotifyGroup, snmpNotifyFilterGroup FROM SNMP-NOTIFICATION-MIB SyslogSeverity, SyslogFacility FROM SYSLOG-TC-MIB; pktcIetfEventMib MODULE-IDENTITY LAST-UPDATED "200903300000Z" -- 30 March 2009 ORGANIZATION "IETF IP over Cable Data Network Working Group" CONTACT-INFO "Sumanth Channabasappa Cable Television Laboratories, Inc. 858 Coal Creek Circle, Louisville, CO 80027, USA +1 303-661-3307 Sumanth@cablelabs.com Wim De Ketelaere tComLabs Gildestraat 8 9000 Gent, Belgium +32 9 269 22 90 deketelaere@tComLabs.com Channabasappa, et al. Standards Track [Page 8] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 Eugene Nechamkin Broadcom Corporation 200 - 13711 International Place Richmond, BC, V6V 2Z8, Canada +1 604 233 8500 enechamkin@broadcom.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-Chair: Jean-Francois Mule, jf.mule@cablelabs.com Co-Chair: Richard Woundy, Richard_Woundy@cable.comcast.com" DESCRIPTION "This MIB module specifies the basic management objects for managing events generated by the Multimedia Terminal Adapter devices compliant with the PacketCable and IPCablecom requirements. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES Channabasappa, et al. Standards Track [Page 9] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5428; see the RFC itself for full legal notices." REVISION "200903300000Z" -- 30 March 2009 DESCRIPTION "Initial version, published as RFC 5428." ::= { mib-2 182 } SyslogSeverityMask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention represents a bit mask representing the severity of the syslog events that can be generated. It corresponds to the various severity levels associated with syslog messages, as specified in 'The Syslog Protocol', [RFC5424]. emerg (0), - emergency; system is unusable alert (1), - action must be taken immediately crit (2), - critical condition err (3), - error condition warning (4), - warning condition notice (5), - normal but significant condition info (6), - informational message debug (7) - debug-level messages" SYNTAX BITS { emerg(0), alert(1), crit(2), err(3), warning(4), notice(5), info(6), debug(7) } Channabasappa, et al. Standards Track [Page 10] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 -- -- pktcEventNotifications OBJECT IDENTIFIER ::= { pktcIetfEventMib 0 } pktcEventMibObjects OBJECT IDENTIFIER ::= { pktcIetfEventMib 1 } pktcEventConformance OBJECT IDENTIFIER ::= { pktcIetfEventMib 2 } -- -- pktcEventControl OBJECT IDENTIFIER ::= { pktcEventMibObjects 1 } pktcEventThrottle OBJECT IDENTIFIER ::= { pktcEventMibObjects 2 } pktcEventStatus OBJECT IDENTIFIER ::= { pktcEventMibObjects 3 } pktcEvents OBJECT IDENTIFIER ::= { pktcEventMibObjects 4 } pktcEventLog OBJECT IDENTIFIER ::= { pktcEventMibObjects 5 } --- -- Event Reporting control objects --- pktcEventReset OBJECT-TYPE SYNTAX BITS { resetEventLogTable(0), resetEventTable(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object allows a management station to clear the local log of generated events, reset the management event descriptions, or both. MTAs generate management events. These events are stored in the MIB table pktcEventLogTable. If a management station needs to clear all the current entries (e.g., after a troubleshooting operation is complete), it can do so by setting the resetEventLogTable(0) bit to a value of '1'. The MTA is pre-configured with the events that it can generate. This is stored in the MIB table pktcEventTable. This table also contains the descriptions associated with these events. These descriptions can be modified by a management station. However, if the management station wishes to reset the descriptions to factory defaults, it can do so by setting the resetEventTable(1) bit to a value of '1'. The MTA actions are summarized below: Bit resetEventLogTable(0) set to a value of '1' - delete all entries in pktcEventLogTable; Channabasappa, et al. Standards Track [Page 11] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 - reset the value of pktcEventLogIndex to '0'. Bit resetEventTable(1) set to a value of '1' - reset the pktcEventTable to the factory default values. Bits resetEventLogTable(0) and resetEventTable(1) set to a value of '1' - perform the above actions as though they were performed individually (in any order). Setting a reset bit to a value of '0' MUST NOT result in any action. The MTA MUST perform the above actions regardless of persistence (i.e., storage in non-volatile memory). The MTA MUST always return a value of '00' when this MIB object is read. A management station that resets tables using this MIB object needs to be careful about the impact to other management stations that may be reliant on the information contained in the table(s) being reset. For example, say management station A creates a specific set of event descriptions in the event table (pktcEventTable) for debugging purposes and expects any generated events to report the modified descriptions. In such a case, if another management station resets the event table to factory defaults, any subsequent events will not contain the modified descriptions expected by management station A. Such multi-manager contentions are not addressed within this MIB module. Thus, management stations are RECOMMENDED to use this MIB object with care and caution, and only when absolutely required." ::= { pktcEventControl 1 } --- -- syslog-specific MIB objects --- pktcEventSyslog OBJECT IDENTIFIER ::= { pktcEventControl 2 } pktcEventSyslogCapabilities OBJECT-TYPE SYNTAX BITS { formatBSDSyslog(0), formatSyslogProtocol(1), transportUDP(2), Channabasappa, et al. Standards Track [Page 12] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 transportTLS(3), transportBEEP(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains the MTA capabilities for supporting the syslog protocol, specifically the message formats and the transport protocols. The BSD syslog message format is specified in [RFC3164] (formatBSDSyslog), and the IETF syslog protocol is specified in [RFC5424] (formatSyslogProtocol). The MTA MUST set the appropriate protocol and transport bits, based on implementation." REFERENCE "The BSD syslog Protocol, [RFC3164]; The Syslog Protocol, [RFC5424]; Transmission of Syslog Messages over UDP, [RFC5426]; TLS Transport Mapping for Syslog, [RFC5425]; Reliable Delivery for syslog, [RFC3195]." ::= { pktcEventSyslog 1 } pktcEventSyslogAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object defines the Internet address type of the syslog server specified by the MIB object pktcEventSyslogAddress. A value of dns(16) is disallowed since a non-resolvable DNS domain name will leave the device without a syslog server to which it can report events." REFERENCE "PacketCable MTA Device Provisioning Specification, [PKT-SP-PROV]." DEFVAL { ipv4 } ::= { pktcEventSyslog 2 } pktcEventSyslogAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object contains the IP address of the Channabasappa, et al. Standards Track [Page 13] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 syslog server to which the MTA can transmit a syslog message upon the generation of a management event. The type of address this object represents is defined by the MIB object pktDevEventSyslogAddressType. The format of the syslog message is specified by the MIB object pktcEventSyslogMessageFormat." REFERENCE "PacketCable MTA Device Provisioning Specification, [PKT-SP-PROV]; PacketCable Management Event Mechanism Specification, [PKT-SP-MEM1.5];" DEFVAL { "0.0.0.0" } ::= { pktcEventSyslog 3 } pktcEventSyslogMessageFormat OBJECT-TYPE SYNTAX INTEGER { formatBSDSyslog(1), -- The BSD syslog Protocol formatSyslogProtocol(2) -- The syslog Protocol } MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object contains the syslog message format to be used for transmitting syslog messages to the server contained in the MIB object pktcEventSyslogServer." REFERENCE "The BSD syslog Protocol, [RFC3164]; The Syslog Protocol, [RFC5424]." DEFVAL { formatSyslogProtocol } ::= { pktcEventSyslog 4 } pktcEventSyslogTransport OBJECT-TYPE SYNTAX INTEGER { udp(1),-- Transmission of syslog messages over UDP tls(2),-- TLS Transport Mapping for Syslog beep(3)-- BEEP Transport Mapping for Syslog } MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object specifies the transport to be used to transmit syslog messages to the syslog server contained in the MIB object pktcEventSyslogAddress. If the MTA does not support the transport specified in a SET operation, then the Channabasappa, et al. Standards Track [Page 14] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 MTA MUST return an appropriate error response, such as 'inconsistentValue'." REFERENCE "Transmission of Syslog messages over UDP, [RFC5426]; TLS Transport Mapping for Syslog, [RFC5425]." DEFVAL {tls} ::= { pktcEventSyslog 5 } pktcEventSyslogPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object contains the port number of the syslog server to which the syslog messages are to be transmitted." REFERENCE "Transmission of Syslog Messages over UDP, [RFC5426]; TLS Transport Mapping for Syslog, [RFC5425]." DEFVAL { 6514 } ::= { pktcEventSyslog 6 } --- -- Event classes --- pktcEventClassTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcEventClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This MIB table allows for management events that can be generated by an MTA to be classified into categories, or 'event classes'. For example, all the configuration- related events can be associated with an event class titled 'configuration'. Such a classification allows for a management station to affect changes on a common group of events at once. Two operations are specified on an event class: enabling or disabling of all the events in an event class, and selective enabling or disabling based on the severity level." ::= { pktcEventControl 3 } pktcEventClassEntry OBJECT-TYPE SYNTAX PktcEventClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Channabasappa, et al. Standards Track [Page 15] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 "Each entry in this table specifies an event class, a grouping of events, as identified by the MTA manufacturer. Any event associated with an event class in this table MUST be specified in the pktcEventTable. The MTA MUST create one entry (index=100) for the event class titled 'generic'. This event class MUST contain all the events that are not contained in any other vendor-specified event classes. A management station SHOULD NOT associate an event with multiple event classes. However, if an event is associated with multiple event classes, the MTA MUST give precedence to the event class with the lowest index. Thus, at a given point in time, only one event class is applicable for an event. The event table (pktcEventTable) provides the event class that affects the event. Whenever an event is generated, the MTA MUST verify the applicable event class entry to take any specified actions. Entries in this table persist across resets and reboots." INDEX { pktcEventClassIndex } ::= { pktcEventClassTable 1 } PktcEventClassEntry::= SEQUENCE { pktcEventClassIndex Unsigned32, pktcEventClassName SnmpAdminString, pktcEventClassStatus TruthValue, pktcEventClassSeverity SyslogSeverityMask } pktcEventClassIndex OBJECT-TYPE SYNTAX Unsigned32 (1..100) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This MIB object is an index into the event class table. It is a locally meaningful value." ::= { pktcEventClassEntry 1 } pktcEventClassName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..100)) MAX-ACCESS read-only Channabasappa, et al. Standards Track [Page 16] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 STATUS current DESCRIPTION "This MIB object contains the name of the event class. Vendors MAY define different event classes (e.g., DHCP, SNMP, DEBUG) to group together management events of a particular category. Event class names need to take into consideration the SnmpAdminString definition requirements, such as the use of control code sequence CR LF to represent a newline." ::= { pktcEventClassEntry 2 } pktcEventClassStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object indicates if events belonging to the corresponding event class are enabled or disabled, for event reporting. Setting this object to a value of 'true' enables reporting of all the events in the event class. When enabled, the means of reporting events is specified by the MIB object pktcEventReporting. Setting this object to a value of 'false' disables any event reporting, irrespective of the value of the MIB object pktcEventReporting for a specific event. The default value of this MIB object is vendor- specific. However, the vendor SHOULD enable all event categories defined by PacketCable or IPCablecom by default." ::= { pktcEventClassEntry 3 } pktcEventClassSeverity OBJECT-TYPE SYNTAX SyslogSeverityMask MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object defines the severity level of events belonging to a specific event class Channabasappa, et al. Standards Track [Page 17] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 that are enabled for event reporting. This MIB object has no effect on the event reporting unless the MIB object pktcEventClassStatus is set to a value of 'true' (enabled), for the corresponding event class. Setting a bit within the mask to a value of '1' implies that events corresponding to that severity level MUST be reported as defined by the corresponding value of 'pktcEventReporting' for events in the event class. Setting a bit to a value of '0' implies that events corresponding to that level MUST NOT be reported, irrespective of the corresponding value of 'pktcEventReporting' for events in the event class. It is recommended that the bits corresponding to emerg(0), alert(1), crit(2), and err(3) be set to a value of '1' to ensure reporting of events requiring immediate attention." REFERENCE "The Syslog Protocol, [RFC5424]." ::= { pktcEventClassEntry 4 } --- -- Event throttling control --- pktcEventThrottleAdminStatus OBJECT-TYPE SYNTAX INTEGER { unconstrained(1), maintainBelowThreshold(2), stopAtThreshold(3), inhibited(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object controls the throttling of the transmitted messages upon generation of an event (SNMP/syslog). It does not affect local logging of events. A value of unconstrained(1) causes event messages Channabasappa, et al. Standards Track [Page 18] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 to be transmitted without regard to the threshold settings. A value of maintainBelowThreshold(2) causes event messages to be suppressed if the number of transmissions would otherwise exceed the threshold specified by pktcEventThrottleThreshold over the interval specified by pktcEventThrottleInterval. A value of stopAtThreshold(3) causes event message transmission to cease once the threshold specified by pktcEventThrottleThreshold (over the interval specified by pktcEventThrottleInterval) is reached. Event generation is resumed when the value of this MIB object is modified by a management station or when the device resets or reboots. A value of inhibited(4) causes all event message transmissions to be suppressed. An event causing both an SNMP and a syslog message is still treated as a single event. Refer to MIB objects pktcEventThrottleThreshold and pktcEventThrottleInterval for information on throttling." DEFVAL { unconstrained } ::= { pktcEventThrottle 1 } pktcEventThrottleThreshold OBJECT-TYPE SYNTAX Unsigned32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object contains the number of events per pktcEventThrottleInterval to be transmitted before throttling. An event resulting in multiple actions (e.g., SNMP and syslog) is still treated as a single event." DEFVAL { 2 } ::= { pktcEventThrottle 2 } pktcEventThrottleInterval OBJECT-TYPE SYNTAX Unsigned32(0..604800) UNITS "seconds" MAX-ACCESS read-write Channabasappa, et al. Standards Track [Page 19] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 STATUS current DESCRIPTION "This MIB object contains the interval over which the throttle threshold applies." DEFVAL { 1 } ::= { pktcEventThrottle 3 } --- -- Reporting of transmission status --- pktcEventTransmissionStatus OBJECT-TYPE SYNTAX BITS { syslogThrottled(0), snmpThrottled(1), validsyslogServerAbsent(2), validSnmpManagerAbsent(3), syslogTransmitError(4), snmpTransmitError(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object reflects the status of the event transmissions using syslog, SNMP, or both. If a bit corresponding to a state is set to a value of: '1', it indicates that the state is true '0', it indicates that the state is false If the MTA is not configured with a syslog server or an SNMP Manager, the corresponding 'throttling' and 'transmit error' bits MUST be set to a value of '0'. For example, if an SNMP Manager is not configured on the MTA, the bit corresponding to validSnmpManagerAbsent(3) is set to a value of '1', and the values of the bits corresponding to snmpThrottled(1) and snmpTransmitError(5) are set to a value of '0'. 'Event throttling' is based on thresholds and the current setting of the MIB object pktcEventThrottleAdminStatus. 'Server/Manager' indicators are based on the availability of valid syslog server/SNMP Managers. Channabasappa, et al. Standards Track [Page 20] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 Transmit errors are reported when detected. If an MTA cannot detect an error situation, the value of the BIT will be set '0'. It is to be noted that not all the conditions that are indicated by this MIB object are detectable by all devices, and when detected may not be accurate. It is meant to provide a report of the status as determined by the device during event transmissions." ::= { pktcEventStatus 1 } --- -- Description of events --- pktcEventTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This MIB table contains all possible management events that can be generated by the device. This includes PacketCable- and IPCablecom-defined events and vendor-specific events." ::= { pktcEvents 1 } pktcEventEntry OBJECT-TYPE SYNTAX PktcEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created for each event the MTA implementing this MIB is capable of reporting. Entries in this table are persisted across resets and reboots." INDEX { pktcEventOrganization, pktcEventIdentifier } ::= { pktcEventTable 1 } PktcEventEntry::= SEQUENCE { pktcEventOrganization Unsigned32, pktcEventIdentifier Unsigned32, pktcEventFacility SyslogFacility, pktcEventSeverityLevel SyslogSeverity, pktcEventReporting BITS, pktcEventText SnmpAdminString, pktcEventClass SnmpAdminString } Channabasappa, et al. Standards Track [Page 21] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 pktcEventOrganization OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This MIB object provides the IANA enterprise number of the organization defining the event. Thus, all PacketCable- or IPCablecom-defined events will contain the PacketCable or IPCablecom IANA enterprise number, and all vendor-specific events will contain the IANA enterprise number of the defining organization." REFERENCE "IANA Private Enterprise Number assignment, [IANA-ENTERPRISE]." ::= { pktcEventEntry 1 } pktcEventIdentifier OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This MIB object contains the event identifier for the corresponding event." REFERENCE "PacketCable Management Event Mechanism Specification, [PKT-SP-MEM1.5]; PacketCable MTA Device Provisioning Specification, [PKT-SP-PROV]." ::= { pktcEventEntry 2 } pktcEventFacility OBJECT-TYPE SYNTAX SyslogFacility MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains the facility for the event. For PacketCable, IPCablecom, or ETSI events, this MUST be set to a value of local0(16)." REFERENCE "The Syslog Protocol, [RFC5424]; Textual Conventions for Syslog Management, [RFC5427]." ::= { pktcEventEntry 3 } pktcEventSeverityLevel OBJECT-TYPE SYNTAX SyslogSeverity Channabasappa, et al. Standards Track [Page 22] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object contains the severity level that is applicable to the specified event." REFERENCE "The Syslog Protocol, [RFC5424]; Textual Conventions for Syslog Management, [RFC5427]." ::= { pktcEventEntry 4 } pktcEventReporting OBJECT-TYPE SYNTAX BITS { local(0), syslog(1), snmpTrap(2), snmpInform(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object defines the action to be taken on occurrence of this event. Bit local(0) refers to local logging of events; bit sylog(1) refers to the transmission of events using syslog; bit snmpTrap(2) refers to the transmission of events using SNMP Traps (SNMPv2-Trap-PDU); and bit snmpInform(3) refers to the transmission of events using SNMP INFORMs. Setting a bit to a value of '1' indicates that the corresponding action will be taken upon occurrence of this event. If none of the bits are set, then no action is taken upon occurrence of the event. The success of transmission using syslog and SNMP depends on the MTA configuration. For example, a valid syslog server address is required for syslog message transmission. Specification of a management event does not necessarily include the actions to be taken upon its generation, i.e., it does not need to specify if a generated event needs to be transmitted via SNMP or syslog, or stored locally. Thus, certain default values are specified, based on the event's severity level specified by the MIB object pktcEventSeverityLevel, as follows: - If the severity level of an event is emerg(0), alert(1), crit(2), or err(3), set the bits for local(0), syslog(1), and snmpInform(3) to a value of '1' and set the remaining bits to a value of '0'. Channabasappa, et al. Standards Track [Page 23] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 - For an event with any other severity level, set the bits for local(0) and syslog(1) to a value of '1' and set the rest of the bits to a value of '0'." ::= { pktcEventEntry 5 } pktcEventText OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..127)) MAX-ACCESS read-write STATUS current DESCRIPTION "This MIB object provides a human-readable description of the event. Descriptions need to take into consideration the SnmpAdminString definition requirements such as the use of control code sequence CR LF to represent a newline." ::= { pktcEventEntry 6 } pktcEventClass OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..100)) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object represents the event class that affects the event. If an event is associated with only one event class, then its name (pktcEventClassName) is reported. If an event is associated with more than one event class, then the name of the event class with the lowest index in the event class table (pktcEventClassTable) is reported. See the MIB table pktcEventClassTable for a description of event classes and usage. Descriptions need to take into consideration the SnmpAdminString definition requirements, such as the use of control code sequence CR LF to represent a newline." ::= { pktcEventEntry 7 } --- -- Log of generated events --- pktcEventLogTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcEventLogEntry Channabasappa, et al. Standards Track [Page 24] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This MIB table contains a log of the events generated by the MTA. A description of all the events that can be generated by the device can be obtained from the MIB table pktcEventTable. An MTA is not required to persist the contents of this table across resets." ::= { pktcEventLog 1 } pktcEventLogEntry OBJECT-TYPE SYNTAX PktcEventLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table describes an event that has occurred, indexed in the chronological order of generation. The details of the event are borrowed from the parameters associated with the corresponding event entry in pktcEventTable at the time of the event generation. While all entries created as such can be cleared using the MIB object pktcEventReset, the event entries themselves cannot be individually deleted." INDEX { pktcEventLogIndex } ::= { pktcEventLogTable 1 } PktcEventLogEntry ::= SEQUENCE { pktcEventLogIndex Unsigned32, pktcEventLogTime DateAndTime, pktcEventLogOrganization Unsigned32, pktcEventLogIdentifier Unsigned32, pktcEventLogText SnmpAdminString, pktcEventLogEndpointName SnmpAdminString, pktcEventLogType BITS, pktcEventLogTargetInfo SnmpAdminString, pktcEventLogCorrelationId Unsigned32, pktcEventLogAdditionalInfo SnmpAdminString } pktcEventLogIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS not-accessible Channabasappa, et al. Standards Track [Page 25] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 STATUS current DESCRIPTION "This MIB object provides relative ordering of the objects in the event log. If the MTA implements non-volatile storage, then this object will always increase except when the MIB object reaches a value of 2^32-1. If the MTA does not implement non-volatile storage, then this object will always increase except when the MIB object reaches a value of 2^32-1 or the MTA is reset. When the value reaches 2^32-1, or an MTA that does not implement non-volatile storage is reset, newer events will be stored starting with an index value of '1' (cyclic rotation)." ::= { pktcEventLogEntry 1 } pktcEventLogTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object provides a human-readable description of the date and time at which the event occurred. The value of the date and time contained in this MIB object SHOULD reflect the date and time used in the syslog message resulting from the associated event, if such a syslog message was transmitted." ::= { pktcEventLogEntry 2 } pktcEventLogOrganization OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object provides the IANA enterprise number of the organization defining the event. Thus, all PacketCable- or IPCablecom-defined events will contain the CableLabs or IPCablecom IANA enterprise number, and all vendor-specific events will contain the IANA enterprise number of the defining organization." ::= { pktcEventLogEntry 3 } pktcEventLogIdentifier OBJECT-TYPE SYNTAX Unsigned32 Channabasappa, et al. Standards Track [Page 26] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains the event identifier for the corresponding event." ::= { pktcEventLogEntry 4 } pktcEventLogText OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..127)) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains the contents of the MIB object pktcEventText, corresponding to the event, at the moment of generation." ::= { pktcEventLogEntry 5 } pktcEventLogEndpointName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains the unique identifier of the MTA endpoint that generated the corresponding event. If the generated event was not associated with any specific endpoint on the MTA, then this MIB object contains the MTA identifier. An MTA endpoint can be uniquely identified using a combination of the MTA identifier and the endpoint number. The MTA is identified via its Fully-Qualified Domain Name (FQDN) and the associated IP address at the given point in time. The format of the value contained by this MIB object is as follows: aaln/n:/, when it identifies an endpoint, 'n' being the endpoint number; or, /, when it identifies an MTA. The value contained by this MIB object needs to observe the SnmpAdminString definition requirements." ::= { pktcEventLogEntry 6 } pktcEventLogType OBJECT-TYPE SYNTAX BITS { Channabasappa, et al. Standards Track [Page 27] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 local(0), syslog(1), snmpTrap(2), snmpInform(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains the type of actions taken by the MTA when the event indicated by the MIB object pktcEventLogIdentifier occurred. A bit with a value of '1' indicates the corresponding action was taken. Setting it to a value of '0' indicates that the corresponding action was not taken. An event may trigger one or more actions (e.g., syslog and SNMP) or result only in a local log. An action may also be prevented due to throttling, in which case it is not reported by this MIB object." ::= { pktcEventLogEntry 7 } pktcEventLogTargetInfo OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains a comma-separated list of the actions taken for external notifications, along with the target IP address for the generated events. Locally stored events MUST NOT be recorded in this MIB object. The syntax is as: ,, Where is to be denoted as follows: For syslog events: syslog/ For SNMP traps: snmpTrap/ For SNMP INFORMS: snmpInform/ If there are multiple targets for the same type (SNMP traps sent to multiple IP addresses) or if there are multiple message types sent to the same IP (syslog and SNMP sent to the same IP address), they need to be reported individually. Channabasappa, et al. Standards Track [Page 28] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 It is to be noted that this MIB object may not be able to store all the data in some cases (e.g., multiple IPv6 addresses), in which case some actions may not be reported. In such cases, the MTA MUST present a value of '...' at the end of the value. Values contained by this MIB object need to observe the SnmpAdminString definition requirements." ::= { pktcEventLogEntry 8 } pktcEventLogCorrelationId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains the correlation ID generated by the MTA during the initiation of the last provisioning flow, within or following which the event occurred. Although a correlation ID once generated after MTA reset does not change until next MTA reset, the value of this object will differ for the events preserved across MTA resets in case of a persistent pktcEventLogTable. For more information on the generation of correlation IDs, refer to the corresponding PacketCable/IPCablecom Device Provisioning specifications." REFERENCE "PacketCable MTA Device Provisioning Specification, [PKT-SP-PROV]." ::= { pktcEventLogEntry 9 } pktcEventLogAdditionalInfo OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "This MIB object contains additional information in relation to the corresponding event that an MTA might wish to report, such as parameterized data or debugging information. The format is vendor-specific. If the MTA cannot provide any additional information for the particular event generated, it MUST populate this Channabasappa, et al. Standards Track [Page 29] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 MIB object with a zero-length OCTET-STRING. Vendors providing this information need to observe the SnmpAdminString definition requirements, such as the use of control code sequence CR LF for newline." ::= { pktcEventLogEntry 10 } --- -- Notifications --- pktcEventNotification NOTIFICATION-TYPE OBJECTS { pktcEventLogTime, pktcEventLogOrganization, pktcEventLogIdentifier, pktcEventLogEndpointName, pktcEventLogCorrelationId, ifPhysAddress } STATUS current DESCRIPTION "This Notification MIB object contains the contents for event reporting. It contains the event log time, the organization ID, the event identifier, the endpoint identifier, the correlation ID, and the MTA's MAC address." ::= { pktcEventNotifications 1 } --- -- Conformance/Compliance --- pktcEventCompliances OBJECT IDENTIFIER ::= { pktcEventConformance 1 } pktcEventGroups OBJECT IDENTIFIER ::= { pktcEventConformance 2 } pktcEventBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for devices that implement the event-reporting feature." MODULE --pktcIetfEventMib MANDATORY-GROUPS { pktcEventGroup, Channabasappa, et al. Standards Track [Page 30] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 pktcEventNotificationGroup } MODULE SNMP-TARGET-MIB MANDATORY-GROUPS { snmpTargetBasicGroup, snmpTargetResponseGroup } MODULE SNMP-NOTIFICATION-MIB MANDATORY-GROUPS { snmpNotifyGroup, snmpNotifyFilterGroup } ::= { pktcEventCompliances 3 } pktcEventGroup OBJECT-GROUP OBJECTS { pktcEventReset, pktcEventSyslogCapabilities, pktcEventSyslogAddressType, pktcEventSyslogAddress, pktcEventSyslogTransport, pktcEventSyslogPort, pktcEventSyslogMessageFormat, pktcEventThrottleAdminStatus, pktcEventThrottleThreshold, pktcEventThrottleInterval, pktcEventTransmissionStatus, pktcEventFacility, pktcEventSeverityLevel, pktcEventReporting, pktcEventText, pktcEventLogTime, pktcEventLogOrganization, pktcEventLogIdentifier, pktcEventLogText, pktcEventLogEndpointName, pktcEventLogType, pktcEventLogTargetInfo, pktcEventLogCorrelationId, pktcEventLogAdditionalInfo, pktcEventClass, pktcEventClassName, pktcEventClassStatus, pktcEventClassSeverity } Channabasappa, et al. Standards Track [Page 31] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 STATUS current DESCRIPTION "Group of MIB objects for PacketCable Management Event MIB." ::= { pktcEventGroups 1 } pktcEventNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pktcEventNotification } STATUS current DESCRIPTION "Group of MIB objects for notifications related to change in status of the MTA Device." ::= { pktcEventGroups 2 } END 7. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER Value ---------- ----------------------- pktcIetfEventMib { mib-2 182 } 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Security threats include events unreported on errors, redirection of events (deliberately or otherwise) or minimized reporting of errors. Such threats can mask certain misconfiguration attempts and denial of service attacks that can be recognized and thwarted via event reporting. Channabasappa, et al. Standards Track [Page 32] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 MIB objects of significance include: - those that control the event generation, the target syslog address for events and the reporting status, i.e.: pktcEventReset pktcEventSyslogAddressType pktcEventSyslogAddress pktcEventSyslogPort pktcEventSyslogMessageFormat pktcEventSyslogTransport pktcEventClassStatus - those related to event classes, i.e.: pktcEventClassSeverity - those related to throttling, i.e.: pktcEventThrottleAdminStatus pktcEventThrottleThreshold pktcEventThrottleInterval - those related to the event reporting capabilities of an MTA, i.e: pktcEventSeverityLevel pktcEventReporting pktcEventText The MIB object pktcEventReset deserves special mention since access to this MIB object can be used to disrupt event collection by management stations. For example, consider a management station that modifies the descriptions in the event table pktcEventTable. It would then expect management events generated by the MTA to reflect the modified values. A rogue management station that has access to the pktcEventReset can reset the event table, resulting in the management station not receiving events with the expected descriptions. Further, a rogue management station with access to pktcEventReset can also clear local logs, eliminating local logs of generated events for management stations that are not configured to receive syslog or SNMP messages. The same concerns apply when allowed management stations performing such operations are unaware of other management stations that may be reliant on the event table or the event log table for management or monitoring. This MIB module does not address such multi-manager contentions, and recommends that the MIB object pktcEventReset be used with caution. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Channabasappa, et al. Standards Track [Page 33] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 pktcEventLogTable: This table contains the log of generated event messages. Read access to this table might reveal some specific information that should be kept confidential. pktcEventTransmissionStatus: This MIB object reveals the status of event transmission and MAY be sensitive in some environments. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to perform GET or SET (change/create/delete) operations. 9. Acknowledgments The authors would like to thank the members of the IETF IP over Cable Data Network (IPCDN) working group and the CableLabs PacketCable Provisioning focus team for their contributions, comments, and suggestions. Special appreciation is extended to the following individuals (in alphabetical order): Dan Romascanu, David Harrington, Greg Nakanishi, Jean-Francois Mule, John Berg, Kevin Marez, Paul Duffy, Peter Bates, Randy Presuhn, Rich Woundy, Rick Vetter, Roy Spitzer, and Satish Kumar. The primary editor (Sumanth) wishes to acknowledge the MIB doctors David Harrington and Dan Romascanu, Lars Eggert and Pasi Eronen, as well as Rich Woundy for expert feedback and numerous suggestions to improve this document. Channabasappa, et al. Standards Track [Page 34] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PKT-SP-PROV] Packetcable MTA Device Provisioning Specification, PKT-SP-PROV-I11-050812. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009. [RFC5425] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed., "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009. [RFC5427] Keeni, G., "Textual Conventions for Syslog Management", RFC 5427, March 2009. [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001. [ITU-T-J176] IPCablecom Management Event Mechanism MIB, J.176, ITU-T, August 2002. [PKT-SP-EVEMIB1.5] PacketCable(TM) Management Event MIB Specification, PKT-SP-EVEMIB1.5-I02-050812, August, 2005. [PKT-SP-MEM1.5] PacketCable(TM) Management Event Mechanism Specification, PKT-SP-MEM1.5-I02-050812, August, 2005. [ETSITS101909-22] ETSI TS 101 909-22, "Digital Broadband Cable Access to the Public Telecommunications Network", IP Multimedia Time Critical Services, Part 22, Management Event Messages. [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. Channabasappa, et al. Standards Track [Page 35] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [IANA-ENTERPRISE] "IANA Private Enterprise Numbers", http://www.iana.org/ 11. Informative References [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [PKT-SP-MGCP] Packetcable Network-Based Call Signaling Protocol Specification, PKT-SP-EC-MGCP-I11-050812. [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [RFC4682] Nechamkin, E. and J-F. Mule, "Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices", RFC 4682, December 2006. Channabasappa, et al. Standards Track [Page 36] RFC 5428 PacketCable/IPCablecom Event MTA MIB April 2009 [PKT-SP-CODEC] Packetcable Audio/Video Codecs Specification, PKT-SP-CODEC-I06-050812. Authors' Addresses Sumanth Channabasappa Cable Television Laboratories, Inc. 858 Coal Creek Circle, Louisville, CO 80027, USA Phone: +1 303-661-3307 EMail: Sumanth@cablelabs.com Wim De Ketelaere tComLabs Gildestraat 8 9000 Gent, Belgium Phone: +32 9 269 22 90 EMail: deketelaere@tComLabs.com Eugene Nechamkin Broadcom Corporation 200 - 13711 International Place Richmond, BC, V6V 2Z8, Canada Phone: +1 604 233 8500 EMail: enechamkin@broadcom.com Channabasappa, et al. Standards Track [Page 37] snmp-mibs-downloader-1.1/mibrfcs/rfc5488.txt0000644000000000000000000025200111402176072015573 0ustar Network Working Group S. Gundavelli Request for Comments: 5488 Cisco Category: Standards Track G. Keeni Cyber Solutions K. Koide KDDI CORPORATION K. Nagami INTEC NetCore April 2009 Network Mobility (NEMO) Management Information Base 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. Gundavelli, et al. Standards Track [Page 1] RFC 5488 NEMO Management Information Base April 2009 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 2.1. The Mobile IPv6 Protocol and NEMO Entities .................2 2.2. Relationship to Other MIB Modules ..........................3 2.3. Terminology ................................................3 2.4. MIB Design .................................................3 3. The NEMO MIB ....................................................4 4. IANA Considerations ............................................41 5. Security Considerations ........................................41 6. Acknowledgments ................................................42 7. References .....................................................42 7.1. Normative References ......................................42 7.2. Informative References ....................................43 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview 2.1. The Mobile IPv6 Protocol and NEMO Entities Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. The Network Mobility (NEMO) Basic Support Protocol [RFC3963] is an extension to the Mobile IPv6 protocol that facilitates the movement of an entire network. The goals of Network Mobility support and related terminology are discussed in [RFC4886] and [RFC4885], respectively. Typically, mobile routers implement NEMO functionality for achieving network mobility. However, a mobile router may also function as a mobile node. In the context of this document, an entity that implements the NEMO protocol is a NEMO entity. Gundavelli, et al. Standards Track [Page 2] RFC 5488 NEMO Management Information Base April 2009 This document defines a set of managed objects (MOs) that can be used to monitor and control NEMO entities. 2.2. Relationship to Other MIB Modules This document focuses on the management of a NEMO entity. It is assumed that implementations will support the ifTable from the IF-MIB [RFC2863]. The MOBILEIPV6-MIB [RFC4295] defines the managed objects for a mobile node. Implementations supporting both the mobile node and NEMO functionality SHOULD implement the managed objects defined for the NEMO entities and mobile nodes from both the MOBILEIPV6-MIB and NEMO-MIB. The NEMO-MIB uses the textual conventions defined in the INET-ADDRESS-MIB [RFC4001]. 2.3. Terminology The terminology used in this document is consistent with the definitions used in the Mobile IPv6 protocol specification [RFC3775] and the NEMO Basic Support specification [RFC3963]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2.4. MIB Design The NEMO MIB comprises the following groups of definitions: nemoCore: a generic group containing objects that are common to all NEMO entities. nemoHa: this group models the home agent service. It is composed of objects specific to the services and associated advertisement parameters offered by the home agent on each of its links. It also contains objects pertaining to the maintenance of the home agent list on each of the links on which the service is offered. nemoMr: this group models the mobile router service. It is composed of objects specific to the Dynamic Home Agent discovery function and related parameters. It also contains objects that record the movement of the mobile router. nemoNotifications: defines the set of notifications that will be used to asynchronously monitor the NEMO entities. Gundavelli, et al. Standards Track [Page 3] RFC 5488 NEMO Management Information Base April 2009 The tables contained in the above groups are as follows: nemoBindingCacheTable: models the Binding Cache on the home agent and correspondent node. It contains details of the Binding Update requests that have been received and accepted. nemoMrEgressIfTable: contains information on the configured egress interfaces. nemoMrBLTable: models the Binding Update List on the mobile router. It contains information about the registration requests sent by the mobile router and the corresponding results. nemoHaCounterTable: contains registration statistics for all mobile routers registered with the home agent. nemoHaMobileNetworkPrefixTable: contains the list of the mobile network prefixes that are maintained by the home agent. 3. The NEMO MIB NEMO-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2, Unsigned32, Counter32, Gauge32, OBJECT-TYPE, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, DateAndTime, TimeStamp FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB InterfaceIndex FROM IF-MIB mip6BindingHomeAddressType, mip6BindingHomeAddress, mip6MnBLEntry, mip6BindingCacheEntry, mip6MnBLCOAType, mip6MnBLCOA FROM MOBILEIPV6-MIB ; nemoMIB MODULE-IDENTITY LAST-UPDATED "200903100000Z" -- 10 March 2009 ORGANIZATION "IETF MEXT Working Group" Gundavelli, et al. Standards Track [Page 4] RFC 5488 NEMO Management Information Base April 2009 CONTACT-INFO " Sri Gundavelli Postal: Cisco 170 W.Tasman Drive, San Jose, CA 95134 USA Tel: +1-408-527-6109 Email: sgundave@cisco.com Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Kenichi Nagami Postal: INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075 Japan Tel: +81-3-5665-5069 E-mail: nagami@inetcore.com Kazuhide Koide Postal: KDDI CORPORATION GARDEN AIR TOWER 3-10-10, Iidabashi Chiyoda-ku, Tokyo, 102-8460 Japan Tel: +81-3-6678-3378 E-mail: ka-koide@kddi.com Support Group E-mail: mext@ietf.org " DESCRIPTION "Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Gundavelli, et al. Standards Track [Page 5] RFC 5488 NEMO Management Information Base April 2009 - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5488; see the RFC itself for full legal notices." REVISION "200903100000Z" -- 10 March 2009 DESCRIPTION "Initial version, published as RFC 5488." ::= { mib-2 184 } -- The NEMO MIB has the following primary groups nemoNotifications OBJECT IDENTIFIER ::= { nemoMIB 0 } nemoObjects OBJECT IDENTIFIER ::= { nemoMIB 1 } nemoConformance OBJECT IDENTIFIER ::= { nemoMIB 2 } nemoCore OBJECT IDENTIFIER ::= { nemoObjects 1 } nemoMr OBJECT IDENTIFIER ::= { nemoObjects 2 } nemoCn OBJECT IDENTIFIER ::= { nemoObjects 3 } nemoHa OBJECT IDENTIFIER ::= { nemoObjects 4 } -- The sub groups nemoSystem OBJECT IDENTIFIER ::= { nemoCore 1 } nemoBindings OBJECT IDENTIFIER ::= { nemoCore 2 } Gundavelli, et al. Standards Track [Page 6] RFC 5488 NEMO Management Information Base April 2009 nemoConfiguration OBJECT IDENTIFIER ::= { nemoCore 3 } nemoStats OBJECT IDENTIFIER ::= { nemoCore 4 } nemoMrSystem OBJECT IDENTIFIER ::= { nemoMr 1 } nemoMrConf OBJECT IDENTIFIER ::= { nemoMr 2 } nemoMrRegistration OBJECT IDENTIFIER ::= { nemoMr 3 } nemoMrGlobalStats OBJECT IDENTIFIER ::= { nemoMr 4 } nemoHaAdvertisement OBJECT IDENTIFIER ::= { nemoHa 1 } nemoHaStats OBJECT IDENTIFIER ::= { nemoHa 2 } nemoHaRegistration OBJECT IDENTIFIER ::= { nemoHa 3 } nemoHaGlobalStats OBJECT IDENTIFIER ::= { nemoHaStats 1 } -- Textual Conventions NemoBURequestRejectionCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of the status field in the Binding Acknowledgment message when the Binding Update was rejected for NEMO-specific reasons. " REFERENCE "RFC 3963: Section 4.2" SYNTAX INTEGER { mobileRouterOperationNotPermitted (140), invalidPrefix (141), notAuthorizedForPrefix (142), forwardingSetupFailed (143) } -- -- -- nemoSystem group -- -- nemoCapabilities OBJECT-TYPE SYNTAX BITS { mobileRouter (0), homeAgentSupport (1) } MAX-ACCESS read-only STATUS current Gundavelli, et al. Standards Track [Page 7] RFC 5488 NEMO Management Information Base April 2009 DESCRIPTION "This object indicates the NEMO functions that are supported by this managed entity. Multiple NEMO functions may be supported by a single entity. " REFERENCE "RFC 3963: Section 3" ::= { nemoSystem 1 } nemoStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the NEMO function is enabled for the managed entity. If it is enabled, the agent discovery and registration functions will be operational. Changing the status from enabled(1) to disabled(2) will terminate the agent discovery and registration functions. On the other hand, changing the status from disabled(2) to enabled(1) will start the agent discovery and registration functions. The value of this object MUST remain unchanged across reboots of the managed entity. " ::= { nemoSystem 2 } nemoCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this NEMO entity's counters, viz., counters with OID prefix 'nemoMrConf', 'nemoMrRegnCounters', 'nemoMrGlobalStats', or 'nemoHaGlobalStats', suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object will have a zero value. " ::= { nemoStats 1 } -- -- Gundavelli, et al. Standards Track [Page 8] RFC 5488 NEMO Management Information Base April 2009 -- nemoConfiguration group -- -- nemoMrBLTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoMrBLEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table corresponds to the Binding Update List (BL) that includes NEMO-related information and that is maintained by the mobile router. The table holds a row for every binding that the mobile router has established or is trying to establish. Entries from the table are deleted as the lifetime of the binding expires. " REFERENCE "RFC 3775: Sections 4.5, 11.1 RFC 3963: Section 5.2" ::= { nemoMrRegistration 1 } nemoMrBLEntry OBJECT-TYPE SYNTAX NemoMrBLEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry pertaining to NEMO-related information contained in a Binding Update sent by a NEMO-enabled mobile router to its home agent. " AUGMENTS {mip6MnBLEntry} ::= { nemoMrBLTable 1 } NemoMrBLEntry ::= SEQUENCE { nemoMrBLMode INTEGER, nemoMrBLMrFlag TruthValue, nemoMrBLHomeAddressPrefixLength InetAddressPrefixLength, nemoMrBLCareofAddressPrefixLength InetAddressPrefixLength, nemoMrBLActiveEgressIfIndex InterfaceIndex, nemoMrBLEstablishedHomeTunnelIfIndex InterfaceIndex } nemoMrBLMode OBJECT-TYPE SYNTAX INTEGER { implicitMode (1), explicitMode (2) } MAX-ACCESS read-only Gundavelli, et al. Standards Track [Page 9] RFC 5488 NEMO Management Information Base April 2009 STATUS current DESCRIPTION "implicitMode(1): the Mobile Network Prefix Option is not included in the Binding Update by the mobile router. explicitMode(2): the mobile router included one or more Mobile Network Prefix Options in the Binding Update. " REFERENCE "RFC 3963: Section 5.2" ::= { nemoMrBLEntry 1 } nemoMrBLMrFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1): the mobile router sent the Binding Update with Mobile Router Flag set. false(2): the mobile router did not send the Binding Update with Mobile Router Flag set. This implies that the mobile router is acting as a mobile node. " REFERENCE "RFC 3963: Sections 4.1, 5.1" ::= { nemoMrBLEntry 2 } nemoMrBLHomeAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "The prefix length of the mobile router's home network. " REFERENCE "RFC 3963: Section 3" ::= { nemoMrBLEntry 3 } nemoMrBLCareofAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current Gundavelli, et al. Standards Track [Page 10] RFC 5488 NEMO Management Information Base April 2009 DESCRIPTION "The prefix length of the care-of address of the mobile router. " REFERENCE "RFC 3963: Section 3" ::= { nemoMrBLEntry 4 } nemoMrBLActiveEgressIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The interface index of the currently active egress interface. " REFERENCE "RFC 3963: Section 5.5" ::= { nemoMrBLEntry 5 } nemoMrBLEstablishedHomeTunnelIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The interface index of the tunnel established between the mobile router and the home agent for NEMO traffic. " REFERENCE "RFC 3963: Section 5.5" ::= { nemoMrBLEntry 6 } -- Mobile Router Registration Group Counters nemoMrRegnCounters OBJECT IDENTIFIER ::= { nemoMrRegistration 2 } nemoMrMobilityMessagesSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of mobility messages, i.e., IPv6 datagrams with Mobility Header, sent by the mobile node. This will include Binding Updates sent by a mobile router with the Mobile Router Flag set. Gundavelli, et al. Standards Track [Page 11] RFC 5488 NEMO Management Information Base April 2009 Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3775: Sections 4.2, 6.1 RFC 3963: Section 4.1" ::= { nemoMrRegnCounters 1 } nemoMrMobilityMessagesRecd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of mobility messages, i.e., IPv6 datagrams with Mobility Header, received by the mobile node. This will include Binding Acknowledgements with Mobile Router Flag set that are sent to a mobile router. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3775: Sections 4.2, 6.1 RFC 3963: Sections 4.1, 4.2" ::= { nemoMrRegnCounters 2 } nemoMrPrefixRegMode OBJECT-TYPE SYNTAX INTEGER { implicitMode (1), explicitMode (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the mode in which the mobile network prefixes will be registered with the home agent. implicitMode(1): the Mobile Network Prefix Option will not be included in the Binding Update by the mobile router. Gundavelli, et al. Standards Track [Page 12] RFC 5488 NEMO Management Information Base April 2009 explicitMode(2): the mobile router will include one or more Mobile Network Prefix Options in the Binding Update. The value of this object MUST remain unchanged across reboots of the managed entity. " REFERENCE "RFC 3963: Section 5.2" ::= { nemoMrRegistration 3 } nemoHaMobileNetworkPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoHaMobileNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the mobile network prefixes that the home agent maintains for the mobile router. The mobile network prefixes in this table are registered by Binding Updates or are manually pre-configured. " REFERENCE "RFC 3963: Section 6.1.2" ::= { nemoHaRegistration 1 } nemoHaMobileNetworkPrefixEntry OBJECT-TYPE SYNTAX NemoHaMobileNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a mobile network prefix. The instances of the columnar objects in this entry pertain to an interface for a particular value of mip6BindingHomeAddressType, mip6BindingHomeAddress, and nemoHaMobileNetworkPrefixSeqNo. The nemoHaMobileNetworkPrefixSeqNo object is used to distinguish between multiple instances of the mobile network prefix in the same Binding Update for the same set of mip6BindingHomeAddressType and mip6BindingHomeAddress. There is no upper-bound on the maximum number of mobile network prefixes in a Binding Update but, for practical purposes, the upper bound of the value Gundavelli, et al. Standards Track [Page 13] RFC 5488 NEMO Management Information Base April 2009 nemoHaMobileNetworkPrefixSeqNo is set to 1024. Implementers need to be aware that if the total number of octets in mip6BindingHomeAddress exceeds 112, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6BindingHomeAddressType, mip6BindingHomeAddress, nemoHaMobileNetworkPrefixSeqNo } ::= { nemoHaMobileNetworkPrefixTable 1 } NemoHaMobileNetworkPrefixEntry ::= SEQUENCE { nemoHaMobileNetworkPrefixSeqNo Unsigned32, nemoHaMobileNetworkPrefixType InetAddressType, nemoHaMobileNetworkPrefix InetAddress, nemoHaMobileNetworkPrefixLength Unsigned32, nemoHaMobileNetworkPrefixSource INTEGER } nemoHaMobileNetworkPrefixSeqNo OBJECT-TYPE SYNTAX Unsigned32 (1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Binding Update may have multiple mobile network prefixes. This object, along with mip6BindingHomeAddressType and mip6BindingHomeAddress, uniquely identifies a row containing a single mobile network prefix for a mobile router in this table. " REFERENCE "RFC 3963: Sections 2, 6.1, 6.2" ::= { nemoHaMobileNetworkPrefixEntry 1 } nemoHaMobileNetworkPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type for the mobile network prefix that follows. " Gundavelli, et al. Standards Track [Page 14] RFC 5488 NEMO Management Information Base April 2009 ::= { nemoHaMobileNetworkPrefixEntry 2 } nemoHaMobileNetworkPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A mobile network prefix related to the corresponding Binding Update. The type of the address represented by this object is specified by the corresponding nemoHaMobileNetworkPrefixType object. " REFERENCE "RFC 3963: Sections 2, 6.1, 6.2" ::= { nemoHaMobileNetworkPrefixEntry 3 } nemoHaMobileNetworkPrefixLength OBJECT-TYPE SYNTAX Unsigned32 (0..128) MAX-ACCESS read-only STATUS current DESCRIPTION "The length of the prefix specified by the corresponding nemoHaMobileNetworkPrefix object. " REFERENCE "RFC 3963: Sections 4.3, 6.1, 6.2" ::= { nemoHaMobileNetworkPrefixEntry 4 } nemoHaMobileNetworkPrefixSource OBJECT-TYPE SYNTAX INTEGER { configured (1), bindingUpdate (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The information source of the mobile network prefix configured with the Binding Update. configured(1): indicates that the mobile network prefix has been manually pre-configured. bindingUpdate(2): indicates that the information is introduced to the home agent by the Mobile Network Gundavelli, et al. Standards Track [Page 15] RFC 5488 NEMO Management Information Base April 2009 Prefix Option in the Binding Updates received by the home agent. " REFERENCE "RFC 3963: Sections 4.3, 6.1, 6.2" ::= { nemoHaMobileNetworkPrefixEntry 5 } nemoBindingCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoBindingCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table models the Binding Cache that includes NEMO-related information and that is maintained by the home agent. Entries in this table are not required to survive a reboot of the home agent. " REFERENCE "RFC 3775: Sections 4.5, 9.1, 10.1, RFC 3963: Section 6.1" ::= { nemoBindings 1 } nemoBindingCacheEntry OBJECT-TYPE SYNTAX NemoBindingCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing additional information related to NEMO-enabled entries in the Binding Cache table of the home agent. " AUGMENTS {mip6BindingCacheEntry} ::= { nemoBindingCacheTable 1 } NemoBindingCacheEntry ::= SEQUENCE { nemoBindingMrFlag TruthValue, nemoBindingMrMode INTEGER } nemoBindingMrFlag OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "true(1): indicates that the Binding Cache entry is from an entity acting as a mobile router. Gundavelli, et al. Standards Track [Page 16] RFC 5488 NEMO Management Information Base April 2009 false(2): implies that the Binding Cache entry is from an entity acting as a mobile node. " REFERENCE "RFC 3963: Sections 6.1.1, 6.2" ::= { nemoBindingCacheEntry 1 } nemoBindingMrMode OBJECT-TYPE SYNTAX INTEGER { implicitMode(1), explicitMode(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "implicitMode(1): the Mobile Network Prefix Option is not included in the Binding Update by the mobile router. explicitMode(2): the mobile router included one or more Mobile Network Prefix Options in the Binding Update. " REFERENCE "RFC 3963: Sections 5.2, 6.1.1, 6.2" ::= { nemoBindingCacheEntry 2 } -- -- nemoMrEgressIfTable -- nemoMrEgressIfTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoMrEgressIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table representing the egress interfaces that will be used by the mobile router for roaming to foreign networks. Each entry in this table represents a configured egress interface. " ::= { nemoMrSystem 1 } nemoMrEgressIfEntry OBJECT-TYPE SYNTAX NemoMrEgressIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the egress interface table. It Gundavelli, et al. Standards Track [Page 17] RFC 5488 NEMO Management Information Base April 2009 represents a single egress interface entry. " INDEX { nemoMrEgressIfIndex } ::= { nemoMrEgressIfTable 1 } NemoMrEgressIfEntry ::= SEQUENCE { nemoMrEgressIfIndex InterfaceIndex, nemoMrEgressIfPriority Unsigned32, nemoMrEgressIfDescription SnmpAdminString, nemoMrEgressIfRoamHoldDownTime Gauge32 } nemoMrEgressIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the interface on the mobile router. " ::= { nemoMrEgressIfEntry 1 } nemoMrEgressIfPriority OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The priority configured to the egress interface. This value will be configured to a value between 0 and 255. " ::= { nemoMrEgressIfEntry 2 } nemoMrEgressIfDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A human-readable textual description of the egress interface on the mobile router. " ::= { nemoMrEgressIfEntry 3 } nemoMrEgressIfRoamHoldDownTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current Gundavelli, et al. Standards Track [Page 18] RFC 5488 NEMO Management Information Base April 2009 DESCRIPTION "This object indicates the time for which the egress interface will be held down during roaming to avoid interface flapping. " ::= { nemoMrEgressIfEntry 4 } nemoMrDiscoveryRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Modified Dynamic Home Agent Address Discovery Requests, with Mobile Router Support Flag set, sent by the mobile router. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3775: Sections 10.5, 11.4.1 RFC 3963: Section 7.1" ::= { nemoMrConf 1 } nemoMrDiscoveryReplies OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Modified Dynamic Home Agent Address Discovery Replies, with Mobile Router Support Flag set, received by the mobile router. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3775: Sections 10.5, 11.4.1 RFC 3963: Section 7.2" ::= { nemoMrConf 2 } nemoMrDiscoveryRepliesRouterFlagZero OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Gundavelli, et al. Standards Track [Page 19] RFC 5488 NEMO Management Information Base April 2009 STATUS current DESCRIPTION "Total number of Modified Dynamic Home Agent Address Discovery Replies, with Mobile Router Support Flag set to 0 although the flag in the corresponding request is set to 1. It implies that there is no home agent that supports mobile router functionality in the home network. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3775: Sections 10.5, 11.4.1 RFC 3963: Section 7.2" ::= { nemoMrConf 3 } nemoMrMovedHome OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile router has detected movement from a foreign network to its home network. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 3" ::= { nemoMrConf 4 } nemoMrMovedOutofHome OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile router has detected movement to a foreign network from the home network, has acquired a care-of address, and has initiated the care-of address registration process. Gundavelli, et al. Standards Track [Page 20] RFC 5488 NEMO Management Information Base April 2009 Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 3" ::= { nemoMrConf 5 } nemoMrMovedFNtoFN OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the mobile router has detected movement to/from a foreign network from/to another foreign network. Note that 'movement' implies movement in layer 3, i.e., the mobile router's care-of address changed, and it initiated the care-of address registration process. If there are multiple egress interfaces, this counter counts the total number of movements. The movement as a mobile node of the mobile entity is not counted. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 3" ::= { nemoMrConf 6 } nemoMrBetterIfDetected OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the NEMO entity has found an egress interface with better priority. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " ::= { nemoMrConf 7 } Gundavelli, et al. Standards Track [Page 21] RFC 5488 NEMO Management Information Base April 2009 -- -- nemoStats:nemoMrGlobalStats -- nemoMrBindingAcksWONemoSupport OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements without NEMO support received by the mobile router. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 5.3" ::= { nemoMrGlobalStats 1 } nemoMrBindingAcksRegTypeChangeDisallowed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements received by the mobile router with status code indicating 'Registration type change disallowed' (Code 139). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3775: Section 9.5.1 RFC 3963: Section 6.2" ::= { nemoMrGlobalStats 2 } nemoMrBindingAcksOperationNotPermitted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements received by the mobile router with status code Gundavelli, et al. Standards Track [Page 22] RFC 5488 NEMO Management Information Base April 2009 indicating 'Mobile Router Operation not permitted' (Code 140). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoMrGlobalStats 3 } nemoMrBindingAcksInvalidPrefix OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements received by the mobile router with status code indicating 'Invalid Prefix' (Code 141). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoMrGlobalStats 4 } nemoMrBindingAcksNotAuthorizedForPrefix OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements received by the mobile router with status code indicating 'Not Authorized for Prefix' (Code 142). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963 : Section 6.6" ::= { nemoMrGlobalStats 5 } Gundavelli, et al. Standards Track [Page 23] RFC 5488 NEMO Management Information Base April 2009 nemoMrBindingAcksForwardingSetupFailed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements received by the mobile router with status code indicating 'Forwarding Setup failed' (Code 143). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoMrGlobalStats 6 } nemoMrBindingAcksOtherError OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements received by the mobile router (Mobile Router Flag is set) with status code other than: successfully processed --(Code 0 ) mobileRouterOperationNotPermitted (140) --(Code 140) invalidPrefix (141) --(Code 141) notAuthorizedForPrefix (142) --(Code 142) forwardingSetupFailed (143) --(Code 143) Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963 : Section 6.6" ::= { nemoMrGlobalStats 7 } -- -- nemoStats:nemoHaGlobalStats -- nemoHaBUAcksWONemoSupport OBJECT-TYPE SYNTAX Counter32 Gundavelli, et al. Standards Track [Page 24] RFC 5488 NEMO Management Information Base April 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Acknowledgements without NEMO support sent by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 5.3" ::= { nemoHaGlobalStats 1 } nemoHaBUAcksRegTypeChangeDisallowed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Registration type change disallowed' (Code 139). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3775: Section 9.5.1 RFC 3963: Section 6.2" ::= { nemoHaGlobalStats 2 } nemoHaBUAcksOperationNotPermitted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Mobile Router Operation not permitted' (Code 140). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of Gundavelli, et al. Standards Track [Page 25] RFC 5488 NEMO Management Information Base April 2009 nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoHaGlobalStats 3 } nemoHaBUAcksInvalidPrefix OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Invalid Prefix' (Code 141). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoHaGlobalStats 4 } nemoHaBUAcksNotAuthorizedForPrefix OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Not Authorized for Prefix' (Code 142). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoHaGlobalStats 5 } nemoHaBUAcksForwardingSetupFailed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Gundavelli, et al. Standards Track [Page 26] RFC 5488 NEMO Management Information Base April 2009 DESCRIPTION "The total number of Binding Update requests rejected by the home agent with status code in the Binding Acknowledgement indicating 'Forwarding Setup failed' (Code 143). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoHaGlobalStats 6 } nemoHaBUAcksOtherError OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Binding Update requests from mobile routers (Mobile Router Flag is set) rejected by the home agent with status code other than: mobileRouterOperationNotPermitted (140) invalidPrefix (141) notAuthorizedForPrefix (142) forwardingSetupFailed (143) Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoCounterDiscontinuityTime. " REFERENCE "RFC 3963: Section 6.6" ::= { nemoHaGlobalStats 7 } nemoHaCounterTable OBJECT-TYPE SYNTAX SEQUENCE OF NemoHaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing registration statistics for all mobile routers registered with the home agent. " ::= { nemoHaStats 2 } Gundavelli, et al. Standards Track [Page 27] RFC 5488 NEMO Management Information Base April 2009 nemoHaCounterEntry OBJECT-TYPE SYNTAX NemoHaCounterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Home agent registration statistics for a mobile router. Implementers need to be aware that if the total number of octets in mip6BindingHomeAddress exceeds 113, then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. " INDEX { mip6BindingHomeAddressType, mip6BindingHomeAddress } ::= { nemoHaCounterTable 1 } NemoHaCounterEntry ::= SEQUENCE { nemoHaBURequestsAccepted Counter32, nemoHaBURequestsDenied Counter32, nemoHaBCEntryCreationTime DateAndTime, nemoHaBUAcceptedTime DateAndTime, nemoHaBURejectionTime DateAndTime, nemoHaRecentBURejectionCode NemoBURequestRejectionCode, nemoHaCtrDiscontinuityTime TimeStamp } nemoHaBURequestsAccepted OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of Binding Update requests from the mobile router accepted by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoHaCtrDiscontinuityTime. " ::= { nemoHaCounterEntry 1 } nemoHaBURequestsDenied OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Gundavelli, et al. Standards Track [Page 28] RFC 5488 NEMO Management Information Base April 2009 DESCRIPTION "Total number of Binding Update requests from the mobile router rejected by the home agent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of nemoHaCtrDiscontinuityTime. " ::= { nemoHaCounterEntry 2 } nemoHaBCEntryCreationTime OBJECT-TYPE SYNTAX DateAndTime (SIZE (11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The time when the current Binding Cache entry was created for the mobile router. An implementation MUST return all 11 bytes of the DateAndTime textual-convention so that a manager may retrieve the offset from GMT time. " ::= { nemoHaCounterEntry 3 } nemoHaBUAcceptedTime OBJECT-TYPE SYNTAX DateAndTime (SIZE (11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last Binding Update was accepted by the home agent for this mobile router. An implementation MUST return all 11 bytes of the DateAndTime textual-convention so that a manager may retrieve the offset from GMT time. " ::= { nemoHaCounterEntry 4 } nemoHaBURejectionTime OBJECT-TYPE SYNTAX DateAndTime (SIZE (11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last Binding Update was rejected by the home agent for this mobile router. If there have been no rejections, then this object will be inaccessible. An implementation MUST return all 11 bytes of the DateAndTime textual-convention so that a manager may retrieve the offset from GMT Gundavelli, et al. Standards Track [Page 29] RFC 5488 NEMO Management Information Base April 2009 time. " ::= { nemoHaCounterEntry 5 } nemoHaRecentBURejectionCode OBJECT-TYPE SYNTAX NemoBURequestRejectionCode MAX-ACCESS read-only STATUS current DESCRIPTION "The Status code (>= 128) in the latest Binding Acknowledgment indicating a rejection, sent to this mobile router. If a Binding Update request is rejected and a Binding Acknowledgment is not sent to this mobile router, then this will be the value of the Status code that corresponds to the reason of the rejection. If there have been no Binding Update request rejections, then this object will be inaccessible. " ::= { nemoHaCounterEntry 6 } nemoHaCtrDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of the counters in this row, viz., instances of 'nemoHaBURequestsAccepted' and 'nemoHaBURequestsDenied', suffered a discontinuity. If no such discontinuity has occurred since the last re-initialization of the local management subsystem, then this object will have a zero value. " ::= { nemoHaCounterEntry 7 } -- -- -- nemoNotifications -- -- nemoHomeTunnelEstablished NOTIFICATION-TYPE OBJECTS { nemoMrBLActiveEgressIfIndex, nemoMrBLEstablishedHomeTunnelIfIndex, mip6MnBLCOAType, Gundavelli, et al. Standards Track [Page 30] RFC 5488 NEMO Management Information Base April 2009 mip6MnBLCOA, nemoMrBLHomeAddressPrefixLength, nemoMrBLCareofAddressPrefixLength } STATUS current DESCRIPTION "This notification is sent by the mobile router every time the tunnel is established between the home agent and the mobile router. " REFERENCE "RFC 3963: Section 5.5" ::= { nemoNotifications 1 } nemoHomeTunnelReleased NOTIFICATION-TYPE OBJECTS { nemoMrBLActiveEgressIfIndex, nemoMrBLEstablishedHomeTunnelIfIndex, mip6MnBLCOAType, mip6MnBLCOA, nemoMrBLHomeAddressPrefixLength, nemoMrBLCareofAddressPrefixLength } STATUS current DESCRIPTION "This notification is sent by the mobile router every time the tunnel is deleted between the home agent and the mobile router. " REFERENCE "RFC 3963: Section 5.5" ::= { nemoNotifications 2} -- Conformance information nemoGroups OBJECT IDENTIFIER ::= { nemoConformance 1 } nemoCompliances OBJECT IDENTIFIER ::= { nemoConformance 2 } -- Units of conformance nemoSystemGroup OBJECT-GROUP OBJECTS { nemoCapabilities, nemoStatus } STATUS current DESCRIPTION "A collection of objects for basic NEMO monitoring. Gundavelli, et al. Standards Track [Page 31] RFC 5488 NEMO Management Information Base April 2009 " ::= { nemoGroups 1 } nemoBindingCacheGroup OBJECT-GROUP OBJECTS { nemoBindingMrFlag, nemoBindingMrMode } STATUS current DESCRIPTION "A collection of objects for monitoring the NEMO extensions of the Binding Cache. " ::= { nemoGroups 2 } nemoStatsGroup OBJECT-GROUP OBJECTS { nemoCounterDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects for monitoring NEMO statistics. " ::= { nemoGroups 3 } nemoMrConfGroup OBJECT-GROUP OBJECTS { nemoMrEgressIfPriority, nemoMrEgressIfDescription, nemoMrEgressIfRoamHoldDownTime, nemoMrDiscoveryRequests, nemoMrDiscoveryReplies, nemoMrDiscoveryRepliesRouterFlagZero, nemoMrMovedHome, nemoMrMovedOutofHome, nemoMrMovedFNtoFN, nemoMrBetterIfDetected } STATUS current DESCRIPTION "A collection of objects for monitoring the configuration-related information on the mobile router. " ::= { nemoGroups 4 } nemoMrRegistrationGroup OBJECT-GROUP Gundavelli, et al. Standards Track [Page 32] RFC 5488 NEMO Management Information Base April 2009 OBJECTS { nemoMrBLMode, nemoMrBLMrFlag, nemoMrBLHomeAddressPrefixLength, nemoMrBLCareofAddressPrefixLength, nemoMrBLActiveEgressIfIndex, nemoMrBLEstablishedHomeTunnelIfIndex, nemoMrMobilityMessagesSent, nemoMrMobilityMessagesRecd, nemoMrPrefixRegMode, nemoMrBindingAcksWONemoSupport, nemoMrBindingAcksRegTypeChangeDisallowed, nemoMrBindingAcksOperationNotPermitted, nemoMrBindingAcksInvalidPrefix, nemoMrBindingAcksNotAuthorizedForPrefix, nemoMrBindingAcksForwardingSetupFailed, nemoMrBindingAcksOtherError } STATUS current DESCRIPTION "A collection of objects for monitoring the registration details and statistics for the mobile router. " ::= { nemoGroups 5 } nemoHaSystemGroup OBJECT-GROUP OBJECTS { nemoHaMobileNetworkPrefixType, nemoHaMobileNetworkPrefix, nemoHaMobileNetworkPrefixLength, nemoHaMobileNetworkPrefixSource } STATUS current DESCRIPTION "A collection of objects for basic NEMO configuration monitoring at the home agent. " ::= { nemoGroups 6 } nemoHaStatsGroup OBJECT-GROUP OBJECTS { nemoHaBURequestsAccepted, nemoHaBURequestsDenied, nemoHaBCEntryCreationTime, nemoHaBUAcceptedTime, nemoHaBURejectionTime, nemoHaRecentBURejectionCode, Gundavelli, et al. Standards Track [Page 33] RFC 5488 NEMO Management Information Base April 2009 nemoHaCtrDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects for monitoring NEMO registration-related statistics pertaining to the mobile routers registered with the home agent. " ::= { nemoGroups 7 } nemoHaGlobalStatsGroup OBJECT-GROUP OBJECTS { nemoHaBUAcksWONemoSupport, nemoHaBUAcksRegTypeChangeDisallowed, nemoHaBUAcksOperationNotPermitted, nemoHaBUAcksInvalidPrefix, nemoHaBUAcksNotAuthorizedForPrefix, nemoHaBUAcksForwardingSetupFailed, nemoHaBUAcksOtherError } STATUS current DESCRIPTION "A collection of objects for monitoring basic NEMO advertisement and registration statistics on a home agent. " ::= { nemoGroups 8 } nemoNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { nemoHomeTunnelEstablished, nemoHomeTunnelReleased } STATUS current DESCRIPTION "A collection of notifications from a home agent or correspondent node to the manager about the tunnel status of the mobile router. " ::= { nemoGroups 9 } -- Compliance statements nemoCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB. " Gundavelli, et al. Standards Track [Page 34] RFC 5488 NEMO Management Information Base April 2009 MODULE -- this module MANDATORY-GROUPS { nemoSystemGroup } ::= { nemoCompliances 1 } nemoCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB and support monitoring of the Binding Cache. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT-clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { nemoSystemGroup, nemoBindingCacheGroup } ::= { nemoCompliances 2 } nemoCoreReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB without support for read-write (i.e., in read-only mode). " MODULE -- this module MANDATORY-GROUPS { nemoSystemGroup } Gundavelli, et al. Standards Track [Page 35] RFC 5488 NEMO Management Information Base April 2009 OBJECT nemoStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { nemoCompliances 3 } nemoReadOnlyCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB without support for read-write (i.e., in read-only mode) and with support for monitoring of the Binding Cache. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT-clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { nemoSystemGroup, nemoBindingCacheGroup } OBJECT nemoStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { nemoCompliances 4 } nemoMrCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that Gundavelli, et al. Standards Track [Page 36] RFC 5488 NEMO Management Information Base April 2009 implement the NEMO-MIB for monitoring configuration- related information, registration details, and statistics on a mobile router. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT-clause form in this description: -- OBJECT mip6MnHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnBLNodeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6MnBLNodeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnBLNodeAddress -- object. " MODULE -- this module MANDATORY-GROUPS { nemoStatsGroup, nemoMrConfGroup, nemoMrRegistrationGroup } ::= { nemoCompliances 5 } nemoMrReadOnlyCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that Gundavelli, et al. Standards Track [Page 37] RFC 5488 NEMO Management Information Base April 2009 implement the NEMO-MIB without support for read- write (i.e., in read-only mode) and with support for monitoring of configuration-related information, registration details, and statistics on a mobile router. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT-clause form in this description: -- OBJECT mip6MnHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnBLNodeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6MnBLNodeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6MnBLNodeAddress -- object. " MODULE -- this module MANDATORY-GROUPS { nemoStatsGroup, nemoMrConfGroup, nemoMrRegistrationGroup } OBJECT nemoMrPrefixRegMode MIN-ACCESS read-only DESCRIPTION Gundavelli, et al. Standards Track [Page 38] RFC 5488 NEMO Management Information Base April 2009 "Write access is not required." ::= { nemoCompliances 6 } nemoHaCoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB for configuration monitoring at the home agent. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT-clause form in this description: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { nemoHaSystemGroup } ::= { nemoCompliances 7 } nemoHaCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB with support for monitoring of the home agent functionality, specifically the home-agent-registration-related statistics. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT-clause form in this description: Gundavelli, et al. Standards Track [Page 39] RFC 5488 NEMO Management Information Base April 2009 -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- IPv6 addresses for the mip6BindingHomeAddress -- object. -- " MODULE -- this module MANDATORY-GROUPS { nemoHaSystemGroup, nemoHaStatsGroup, nemoHaGlobalStatsGroup } ::= { nemoCompliances 8 } nemoNotificationCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the NEMO-MIB and support Notification from the home agent. " MODULE -- this module MANDATORY-GROUPS { nemoNotificationGroup } ::= { nemoCompliances 9 } END Gundavelli, et al. Standards Track [Page 40] RFC 5488 NEMO Management Information Base April 2009 4. IANA Considerations IANA has assigned a base arc in the mib-2 (Standards Track) OID tree for the 'nemoMIB' (184). 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: nemoStatus: The value of this object is used to enable or disable the NEMO functionality on a NEMO entity. Access to this MO may be abused to disrupt the communication that depends on NEMO. nemoMrPrefixRegMode: The value of this object is used to control the mode in which mobile network prefixes will be registered with the home agent. Access to this object may be abused to disrupt the setting up of mobile network prefixes. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: nemoHaMobileNetworkPrefixType nemoHaMobileNetworkPrefix nemoHaMobileNetworkPrefixLength: The above address-related objects may be considered to be particularly sensitive and/or private. The mobile-network- prefix-related objects reveal the configuration of the mobile router and, as such, may be considered to be sensitive. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Gundavelli, et al. Standards Track [Page 41] RFC 5488 NEMO Management Information Base April 2009 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. Acknowledgments The authors would like to thank Alex Petrescu, Pascal Thubert, Kent Leung, T.J Kniveton, Thierry Ernst, Alberto Garcia, Marcelo Bagnulo, Vijay K. Gurbani, Bert Wijnen, Chris Newman, Dan Romanascu, and Jari Arkko for their review comments on this document. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Gundavelli, et al. Standards Track [Page 42] RFC 5488 NEMO Management Information Base April 2009 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, "Mobile IPv6 Management Information Base", RFC 4295, April 2006. 7.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [RFC4886] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007. Gundavelli, et al. Standards Track [Page 43] RFC 5488 NEMO Management Information Base April 2009 Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1-408-527-6109 EMail: sgundave@cisco.com Glenn Mansfield Keeni Cyber Solutions 6-6-3 Minami Yoshinari, Aoba-ku Sendai 989-3204, Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Kazuhide Koide KDDI CORPORATION GARDEN AIR TOWER 3-10-10, Iidabashi Chiyoda-ku, Tokyo, 102-8460 Japan Phone: +81-3-6678-3378 EMail: ka-koide@kddi.com Kenichi Nagami INTEC NetCore 1-3-3, Shin-suna Koto-ku, Tokyo, 135-0075, Japan Phone: +81-3-5665-5069 EMail: nagami@inetcore.com Gundavelli, et al. Standards Track [Page 44] snmp-mibs-downloader-1.1/mibrfcs/rfc5519.txt0000644000000000000000000022474411402176072015603 0ustar Network Working Group J. Chesterfield Request for Comments: 5519 University of Cambridge Obsoletes: 2933, 3019 B. Haberman, Ed. Category: Standards Track JHU/APL April 2009 Multicast Group Membership Discovery MIB 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. Chesterfield & Haberman Standards Track [Page 1] RFC 5519 MGMD MIB April 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.1. Normative References . . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . 41 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) version 1 [RFC1112], version 2 [RFC2236], or version 3 [RFC3376] and the Multicast Listener Discovery (MLD) protocol version 1 [RFC2710] or version 2 [RFC3810]. Both protocols provide multicast membership discovery capability. IGMP pertains to IP version 4 clients, and MLD to IP version 6 clients. This version of the MIB obsoletes both RFC 2933 [RFC2933] and RFC 3019 [RFC3019], incorporating a generic interface for both IGMP and MLD implementations and incorporating changes to enable "source filtering" in multicast clients. The MIB encompasses both router and host nodes with relevant management objects defined for each. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Chesterfield & Haberman Standards Track [Page 2] RFC 5519 MGMD MIB April 2009 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 4. Overview This Multicast Group Membership Discovery (MGMD) MIB module contains eight tables: 1. the MGMD Host Interface Table, which contains one row for each interface on which IGMP or MLD is enabled on a host, 2. the MGMD Router Interface Table, which contains one row for each interface on which MGMD is enabled on a router, 3. the MGMD Host Cache Table, which contains one row for each IP multicast group for which there are members on a particular interface on a host, 4. the MGMD Router Cache Table, which contains one row for each IP multicast group for which there are members on a particular interface on a router, 5. the reverse MGMD Host Table, which contains one row for each interface for which there are active multicast groups on a host, 6. the reverse MGMD Router Table, which contains one row for each interface for which there are active multicast groups on a router, 7. the MGMD HostSrcList Table, which contains one row for each entry in the source filter record for an interface and multicast group pair on a host, and 8. the MGMD RouterSrcList Table, which contains one row for each entry in the source filter record for an interface and multicast group pair on a router. All tables are intended for EITHER router OR host functionality as indicated by the name and corresponding description, although it is anticipated that there will be scenarios where both terms might apply to a device, e.g., a router that joins a multicast group also as a host for measurement purposes. The source list tables provide an extension to the cache tables to indicate the source-specific Chesterfield & Haberman Standards Track [Page 3] RFC 5519 MGMD MIB April 2009 includes or excludes associated with each IP multicast group on each specific interface. This functionality is only supported in IGMPv3- and MLDv2-capable nodes. Incorporated within the MGMD MIB tables are objects for the management of IGMP and MLD proxy devices as described in RFC 4605 [RFC4605]. Proxy devices can be used in simple topologies where it is not necessary to run a full multicast routing protocol. A proxy device can make forwarding decisions based on IGMP or MLD group membership activity. The MIB references InterfaceIndex and InterfaceIndexOrZero objects as defined in RFC 2863 [RFC2863], the MIB that describes generic objects for network interface sub-layers. Extensive references to the InetAddress and InetAddressType objects are made as defined in RFC 4001 [RFC4001]. 5. Definitions MGMD-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Counter32, Gauge32, Unsigned32, TimeTicks FROM SNMPv2-SMI InetAddress, InetAddressType FROM INET-ADDRESS-MIB RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndexOrZero, InterfaceIndex FROM IF-MIB; mgmdStdMIB MODULE-IDENTITY LAST-UPDATED "200903300000Z" -- March 30, 2009 ORGANIZATION "INTERNET ENGINEERING TASK FORCE MULTICAST and ANYCAST GROUP MEMBERSHIP Working Group. www: http://www.ietf.org/html.charters/magma-charter.html EMail: magma@ietf.org" CONTACT-INFO "Julian Chesterfield University of Cambridge, Computer Laboratory, 15 JJ Thompson Avenue, Cambridge, CB3 0FD UK EMail: julian.chesterfield@cl.cam.ac.uk" Chesterfield & Haberman Standards Track [Page 4] RFC 5519 MGMD MIB April 2009 DESCRIPTION "The MIB module for MGMD management. A new version of MGMD combining RFC 2933 and RFC 3019. Includes IGMPv3 and MLDv2 source filtering changes. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5519; see the RFC itself for full legal notices." REVISION "200903300000Z" -- March 30, 2009 DESCRIPTION "This MIB obsoletes both RFC 2933 and RFC 3019." ::= { mib-2 185 } Chesterfield & Haberman Standards Track [Page 5] RFC 5519 MGMD MIB April 2009 mgmdMIBObjects OBJECT IDENTIFIER ::= { mgmdStdMIB 1 } -- -- The MGMD Host Interface Table -- mgmdHostInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdHostInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interfaces on which IGMP or MLD is enabled." ::= { mgmdMIBObjects 1 } mgmdHostInterfaceEntry OBJECT-TYPE SYNTAX MgmdHostInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an interface on which IGMP or MLD is enabled." INDEX { mgmdHostInterfaceIfIndex, mgmdHostInterfaceQuerierType } ::= { mgmdHostInterfaceTable 1 } MgmdHostInterfaceEntry ::= SEQUENCE { mgmdHostInterfaceIfIndex InterfaceIndex, mgmdHostInterfaceQuerierType InetAddressType, mgmdHostInterfaceQuerier InetAddress, mgmdHostInterfaceStatus RowStatus, mgmdHostInterfaceVersion Unsigned32, mgmdHostInterfaceVersion1QuerierTimer TimeTicks, mgmdHostInterfaceVersion2QuerierTimer TimeTicks, mgmdHostInterfaceVersion3Robustness Unsigned32 } mgmdHostInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the interface for which IGMP or MLD is enabled. The table is indexed by the ifIndex value and the InetAddressType to allow for interfaces that may be configured in both IPv4 and IPv6 modes." Chesterfield & Haberman Standards Track [Page 6] RFC 5519 MGMD MIB April 2009 ::= { mgmdHostInterfaceEntry 1 } mgmdHostInterfaceQuerierType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of this interface. This entry along with the ifIndex value acts as an index to the mgmdHostInterface table. A physical interface may be configured in multiple modes concurrently, e.g., in IPv4 and IPv6 modes connected to the same interface; however, the traffic is considered to be logically separate." ::= { mgmdHostInterfaceEntry 2 } mgmdHostInterfaceQuerier OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the IGMP or MLD Querier on the IP subnet to which this interface is attached. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdHostInterfaceQuerierType variable in the mgmdHostInterface table." ::= { mgmdHostInterfaceEntry 3 } mgmdHostInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The activation of a row enables the host side of IGMP or MLD on the interface. The destruction of a row disables the host side of IGMP or MLD on the interface." ::= { mgmdHostInterfaceEntry 4 } mgmdHostInterfaceVersion OBJECT-TYPE SYNTAX Unsigned32 (1..3) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum version of MGMD that the host can run on this interface. A value of 1 is only applicable for IPv4, and indicates that the host only supports IGMPv1 on the Chesterfield & Haberman Standards Track [Page 7] RFC 5519 MGMD MIB April 2009 interface. A value of 2 indicates that the host also supports IGMPv2 (for IPv4) or MLDv1 (for IPv6). A value of 3 indicates that the host also supports IGMPv3 (for IPv4) or MLDv2 (for IPv6)." DEFVAL { 3 } ::= { mgmdHostInterfaceEntry 5 } mgmdHostInterfaceVersion1QuerierTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining until the host assumes that there are no IGMPv1 routers present on the interface. While this is non-zero, the host will reply to all queries with version 1 membership reports. This variable applies to IGMPv2 or 3 hosts that are forced to run in v1 for compatibility with v1 routers present on the interface. This object may only be present when the corresponding value of mgmdHostInterfaceQuerierType is ipv4." REFERENCE "RFC 2236, Section 4 and RFC 3376, Section 7.2.1" DEFVAL { 0 } ::= { mgmdHostInterfaceEntry 6 } mgmdHostInterfaceVersion2QuerierTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining until the host assumes that there are no MGMDv2 routers present on the interface. While this is non-zero, the host will reply to all queries with version 1 or 2 membership reports. This variable applies to MGMDv3 hosts that are forced to run in v2 for compatibility with v2 hosts or routers present on the interface." REFERENCE "RFC 3376, Section 7.2.1 and RFC 3810, Section 8.2.1" DEFVAL { 0 } ::= { mgmdHostInterfaceEntry 7 } mgmdHostInterfaceVersion3Robustness OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current Chesterfield & Haberman Standards Track [Page 8] RFC 5519 MGMD MIB April 2009 DESCRIPTION "The robustness variable utilised by an MGMDv3 host in sending state-change reports for multicast routers. To ensure the state-change report is not missed, the host retransmits the state-change report [mgmdHostInterfaceVersion3Robustness - 1] times. The variable must be a non-zero value." REFERENCE "RFC 3376, Section 8.1 and RFC 3810, Section 9.14.1" DEFVAL { 2 } ::= { mgmdHostInterfaceEntry 8 } -- -- The MGMD Router Interface Table -- mgmdRouterInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdRouterInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interfaces on which IGMP or MLD is enabled." ::= { mgmdMIBObjects 2 } mgmdRouterInterfaceEntry OBJECT-TYPE SYNTAX MgmdRouterInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an interface on which IGMP or MLD is enabled." INDEX { mgmdRouterInterfaceIfIndex, mgmdRouterInterfaceQuerierType } ::= { mgmdRouterInterfaceTable 1 } MgmdRouterInterfaceEntry ::= SEQUENCE { mgmdRouterInterfaceIfIndex InterfaceIndex, mgmdRouterInterfaceQuerierType InetAddressType, mgmdRouterInterfaceQuerier InetAddress, mgmdRouterInterfaceQueryInterval Unsigned32, mgmdRouterInterfaceStatus RowStatus, mgmdRouterInterfaceVersion Unsigned32, mgmdRouterInterfaceQueryMaxResponseTime Unsigned32, mgmdRouterInterfaceQuerierUpTime TimeTicks, mgmdRouterInterfaceQuerierExpiryTime TimeTicks, Chesterfield & Haberman Standards Track [Page 9] RFC 5519 MGMD MIB April 2009 mgmdRouterInterfaceWrongVersionQueries Counter32, mgmdRouterInterfaceJoins Counter32, mgmdRouterInterfaceProxyIfIndex InterfaceIndexOrZero, mgmdRouterInterfaceGroups Gauge32, mgmdRouterInterfaceRobustness Unsigned32, mgmdRouterInterfaceLastMemberQueryInterval Unsigned32, mgmdRouterInterfaceLastMemberQueryCount Unsigned32, mgmdRouterInterfaceStartupQueryCount Unsigned32, mgmdRouterInterfaceStartupQueryInterval Unsigned32 } mgmdRouterInterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the interface for which IGMP or MLD is enabled. The table is indexed by the ifIndex value and the InetAddressType to allow for interfaces that may be configured in both IPv4 and IPv6 modes." ::= { mgmdRouterInterfaceEntry 1 } mgmdRouterInterfaceQuerierType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of this interface. This entry along with the ifIndex value acts as the index to the mgmdRouterInterface table. A physical interface may be configured in multiple modes concurrently, e.g., in IPv4 and IPv6 modes connected to the same interface; however, the traffic is considered to be logically separate." ::= { mgmdRouterInterfaceEntry 2 } mgmdRouterInterfaceQuerier OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the IGMP or MLD Querier on the IP subnet to which this interface is attached. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdRouterInterfaceQuerierType variable in the mgmdRouterInterface table." Chesterfield & Haberman Standards Track [Page 10] RFC 5519 MGMD MIB April 2009 ::= { mgmdRouterInterfaceEntry 3 } mgmdRouterInterfaceQueryInterval OBJECT-TYPE SYNTAX Unsigned32 (1..31744) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency at which IGMP or MLD Host-Query packets are transmitted on this interface." DEFVAL { 125 } ::= { mgmdRouterInterfaceEntry 4 } mgmdRouterInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The activation of a row enables the router side of IGMP or MLD on the interface. The destruction of a row disables the router side of IGMP or MLD on the interface." ::= { mgmdRouterInterfaceEntry 5 } mgmdRouterInterfaceVersion OBJECT-TYPE SYNTAX Unsigned32 (1..3) MAX-ACCESS read-create STATUS current DESCRIPTION "The version of MGMD that is running on this interface. Value 1 applies to IGMPv1 routers only. Value 2 applies to IGMPv2 and MLDv1 routers, and value 3 applies to IGMPv3 and MLDv2 routers. This object can be used to configure a router capable of running either version. For IGMP and MLD to function correctly, all routers on a LAN must be configured to run the same version on that LAN." DEFVAL { 3 } ::= { mgmdRouterInterfaceEntry 6 } mgmdRouterInterfaceQueryMaxResponseTime OBJECT-TYPE SYNTAX Unsigned32 (0..31744) UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current Chesterfield & Haberman Standards Track [Page 11] RFC 5519 MGMD MIB April 2009 DESCRIPTION "The maximum query response interval advertised in MGMDv2 or IGMPv3 queries on this interface." REFERENCE "RFC 3810, Section 9.3" DEFVAL { 100 } ::= { mgmdRouterInterfaceEntry 7 } mgmdRouterInterfaceQuerierUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since mgmdRouterInterfaceQuerier was last changed." ::= { mgmdRouterInterfaceEntry 8 } mgmdRouterInterfaceQuerierExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time remaining before the Other Querier Present Timer expires. If the local system is the querier, the value of this object is zero." ::= { mgmdRouterInterfaceEntry 9 } mgmdRouterInterfaceWrongVersionQueries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of general queries received whose IGMP or MLD version does not match the equivalent mgmdRouterInterfaceVersion, over the lifetime of the row entry. Both IGMP and MLD require that all routers on a LAN be configured to run the same version. Thus, if any general queries are received with the wrong version, this indicates a configuration error." ::= { mgmdRouterInterfaceEntry 10 } mgmdRouterInterfaceJoins OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Chesterfield & Haberman Standards Track [Page 12] RFC 5519 MGMD MIB April 2009 STATUS current DESCRIPTION "The number of times a group membership has been added on this interface, that is, the number of times an entry for this interface has been added to the Cache Table. This object can give an indication of the amount of activity between samples over time." ::= { mgmdRouterInterfaceEntry 11 } mgmdRouterInterfaceProxyIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Some devices implement a form of IGMP or MLD proxying whereby memberships learned on the interface represented by this row cause Host Membership Reports to be sent on the interface whose ifIndex value is given by this object. Such a device would implement the mgmdV2RouterBaseMIBGroup only on its router interfaces (those interfaces with non-zero mgmdRouterInterfaceProxyIfIndex). Typically, the value of this object is 0, indicating that no proxying is being done." DEFVAL { 0 } ::= { mgmdRouterInterfaceEntry 12 } mgmdRouterInterfaceGroups OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries for this interface in the mgmdRouterCacheTable." ::= { mgmdRouterInterfaceEntry 13 } mgmdRouterInterfaceRobustness OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The Robustness Variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the Robustness Variable may be increased. IGMP and MLD are robust to (Robustness Variable-1) packet losses." DEFVAL { 2 } Chesterfield & Haberman Standards Track [Page 13] RFC 5519 MGMD MIB April 2009 ::= { mgmdRouterInterfaceEntry 14 } mgmdRouterInterfaceLastMemberQueryInterval OBJECT-TYPE SYNTAX Unsigned32 (0..31744) UNITS "tenths of seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Last Member Query Interval is the Max Query Response Interval inserted into group-specific queries sent in response to leave group messages, and is also the amount of time between group-specific query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group. The value of this object is irrelevant if mgmdRouterInterfaceVersion is 1." DEFVAL { 10 } ::= { mgmdRouterInterfaceEntry 15 } mgmdRouterInterfaceLastMemberQueryCount OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of group-specific and group-and- source-specific queries sent by the router before it assumes there are no local members." ::= { mgmdRouterInterfaceEntry 16 } mgmdRouterInterfaceStartupQueryCount OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of Queries sent out on startup, separated by the Startup Query Interval." ::= { mgmdRouterInterfaceEntry 17 } mgmdRouterInterfaceStartupQueryInterval OBJECT-TYPE SYNTAX Unsigned32 (0..31744) UNITS "seconds" MAX-ACCESS read-only STATUS current Chesterfield & Haberman Standards Track [Page 14] RFC 5519 MGMD MIB April 2009 DESCRIPTION "This variable represents the interval between General Queries sent by a Querier on startup." ::= { mgmdRouterInterfaceEntry 18 } -- -- The MGMD Host Cache Table -- mgmdHostCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdHostCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the IP multicast groups for which the host is a member on a particular interface." ::= { mgmdMIBObjects 3 } mgmdHostCacheEntry OBJECT-TYPE SYNTAX MgmdHostCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mgmdHostCacheTable." INDEX { mgmdHostCacheAddressType, mgmdHostCacheAddress, mgmdHostCacheIfIndex } ::= { mgmdHostCacheTable 1 } MgmdHostCacheEntry ::= SEQUENCE { mgmdHostCacheAddressType InetAddressType, mgmdHostCacheAddress InetAddress , mgmdHostCacheIfIndex InterfaceIndex, mgmdHostCacheUpTime TimeTicks, mgmdHostCacheLastReporter InetAddress, mgmdHostCacheSourceFilterMode INTEGER } mgmdHostCacheAddressType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the mgmdHostCacheTable entry. This value applies to both the mgmdHostCacheAddress and the mgmdHostCacheLastReporter entries." Chesterfield & Haberman Standards Track [Page 15] RFC 5519 MGMD MIB April 2009 ::= { mgmdHostCacheEntry 1 } mgmdHostCacheAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address for which this entry contains information. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdHostCacheAddressType variable in the mgmdHostCache table." ::= { mgmdHostCacheEntry 2 } mgmdHostCacheIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information for an IP multicast group address." ::= { mgmdHostCacheEntry 3 } mgmdHostCacheUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time elapsed since this entry was created." ::= { mgmdHostCacheEntry 4 } mgmdHostCacheLastReporter OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the source of the last membership report received for this IP multicast group address on this interface. If no membership report has been received, this object has a value of 0. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdHostCacheAddressType variable in the mgmdHostCache table." ::= { mgmdHostCacheEntry 5 } mgmdHostCacheSourceFilterMode OBJECT-TYPE Chesterfield & Haberman Standards Track [Page 16] RFC 5519 MGMD MIB April 2009 SYNTAX INTEGER {include (1), exclude (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state in which the interface is currently set. The value indicates the relevance of the corresponding source list entries in the mgmdHostSecListTable for MGMDv3 interfaces." ::= { mgmdHostCacheEntry 6 } -- -- The MGMD Router Cache Table -- mgmdRouterCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdRouterCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the IP multicast groups for which there are members on a particular router interface." ::= { mgmdMIBObjects 4 } mgmdRouterCacheEntry OBJECT-TYPE SYNTAX MgmdRouterCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mgmdRouterCacheTable." INDEX { mgmdRouterCacheAddressType, mgmdRouterCacheAddress, mgmdRouterCacheIfIndex } ::= { mgmdRouterCacheTable 1 } MgmdRouterCacheEntry ::= SEQUENCE { mgmdRouterCacheAddressType InetAddressType, mgmdRouterCacheAddress InetAddress, mgmdRouterCacheIfIndex InterfaceIndex, mgmdRouterCacheLastReporter InetAddress, mgmdRouterCacheUpTime TimeTicks, mgmdRouterCacheExpiryTime TimeTicks, mgmdRouterCacheExcludeModeExpiryTimer TimeTicks, mgmdRouterCacheVersion1HostTimer TimeTicks, Chesterfield & Haberman Standards Track [Page 17] RFC 5519 MGMD MIB April 2009 mgmdRouterCacheVersion2HostTimer TimeTicks, mgmdRouterCacheSourceFilterMode INTEGER } mgmdRouterCacheAddressType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the mgmdRouterCacheTable entry. This value applies to both the mgmdRouterCacheAddress and the mgmdRouterCacheLastReporter entries." ::= { mgmdRouterCacheEntry 1 } mgmdRouterCacheAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address for which this entry contains information. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdRouterCacheAddressType variable in the mgmdRouterCache table." ::= { mgmdRouterCacheEntry 2 } mgmdRouterCacheIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information for an IP multicast group address." ::= { mgmdRouterCacheEntry 3 } mgmdRouterCacheLastReporter OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the source of the last membership report received for this IP multicast group address on this interface. If no membership report has been received, this object has the value 0. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdRouterCacheAddressType variable in the mgmdRouterCache table." Chesterfield & Haberman Standards Track [Page 18] RFC 5519 MGMD MIB April 2009 ::= { mgmdRouterCacheEntry 4 } mgmdRouterCacheUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time elapsed since this entry was created." ::= { mgmdRouterCacheEntry 5 } mgmdRouterCacheExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the time remaining before the Group Membership Interval state expires. The value must always be greater than or equal to 1." ::= { mgmdRouterCacheEntry 6 } mgmdRouterCacheExcludeModeExpiryTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value is applicable only to MGMDv3-compatible nodes and represents the time remaining before the interface EXCLUDE state expires and the interface state transitions to INCLUDE mode. This value can never be greater than mgmdRouterCacheExpiryTime." ::= { mgmdRouterCacheEntry 7 } mgmdRouterCacheVersion1HostTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining until the local router will assume that there are no longer any MGMD version 1 members on the IP subnet attached to this interface. This entry only applies to IGMPv1 hosts, and is not implemented for MLD. Upon hearing any MGMDv1 Membership Report (IGMPv1 only), this value is reset to the group membership timer. While this Chesterfield & Haberman Standards Track [Page 19] RFC 5519 MGMD MIB April 2009 time remaining is non-zero, the local router ignores any MGMDv2 Leave messages (IGMPv2 only) for this group that it receives on this interface." ::= { mgmdRouterCacheEntry 8 } mgmdRouterCacheVersion2HostTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining until the local router will assume that there are no longer any MGMD version 2 members on the IP subnet attached to this interface. This entry applies to both IGMP and MLD hosts. Upon hearing any MGMDv2 Membership Report, this value is reset to the group membership timer. Assuming no MGMDv1 hosts have been detected, the local router does not ignore any MGMDv2 Leave messages for this group that it receives on this interface." ::= { mgmdRouterCacheEntry 9 } mgmdRouterCacheSourceFilterMode OBJECT-TYPE SYNTAX INTEGER {include (1), exclude (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current cache state, applicable to MGMDv3-compatible nodes. The value indicates whether the state is INCLUDE or EXCLUDE." ::= { mgmdRouterCacheEntry 10 } -- -- The MGMD Inverse Host interface/cache lookup Table -- mgmdInverseHostCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdInverseHostCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interfaces that are members of a particular group. This is an inverse lookup table for entries in the mgmdHostCacheTable." ::= { mgmdMIBObjects 5 } Chesterfield & Haberman Standards Track [Page 20] RFC 5519 MGMD MIB April 2009 mgmdInverseHostCacheEntry OBJECT-TYPE SYNTAX MgmdInverseHostCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mgmdInverseHostCacheTable." INDEX { mgmdInverseHostCacheIfIndex, mgmdInverseHostCacheAddressType, mgmdInverseHostCacheAddress} ::= { mgmdInverseHostCacheTable 1 } MgmdInverseHostCacheEntry ::= SEQUENCE { mgmdInverseHostCacheIfIndex InterfaceIndex, mgmdInverseHostCacheAddressType InetAddressType, mgmdInverseHostCacheAddress InetAddress } mgmdInverseHostCacheIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information." ::= { mgmdInverseHostCacheEntry 1 } mgmdInverseHostCacheAddressType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the mgmdInverseHostCacheTable entry." ::= { mgmdInverseHostCacheEntry 2 } mgmdInverseHostCacheAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP multicast group address for which this entry contains information about an interface. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdInverseHostCacheAddressType variable in the mgmdInverseHostCache table." Chesterfield & Haberman Standards Track [Page 21] RFC 5519 MGMD MIB April 2009 ::= { mgmdInverseHostCacheEntry 3 } -- -- The MGMD Inverse Router interface/cache lookup Table -- mgmdInverseRouterCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdInverseRouterCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interfaces that are members of a particular group. This is an inverse lookup table for entries in the mgmdRouterCacheTable." ::= { mgmdMIBObjects 6 } mgmdInverseRouterCacheEntry OBJECT-TYPE SYNTAX MgmdInverseRouterCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mgmdInverseRouterCacheTable." INDEX { mgmdInverseRouterCacheIfIndex, mgmdInverseRouterCacheAddressType, mgmdInverseRouterCacheAddress } ::= { mgmdInverseRouterCacheTable 1 } MgmdInverseRouterCacheEntry ::= SEQUENCE { mgmdInverseRouterCacheIfIndex InterfaceIndex, mgmdInverseRouterCacheAddressType InetAddressType, mgmdInverseRouterCacheAddress InetAddress } mgmdInverseRouterCacheIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information for an IP multicast group address." ::= { mgmdInverseRouterCacheEntry 1 } mgmdInverseRouterCacheAddressType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } Chesterfield & Haberman Standards Track [Page 22] RFC 5519 MGMD MIB April 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the mgmdInverseRouterCacheTable entry." ::= { mgmdInverseRouterCacheEntry 2 } mgmdInverseRouterCacheAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP multicast group address for which this entry contains information. The InetAddressType, e.g., IPv4 or IPv6, is identified by the mgmdInverseRouterCacheAddressType variable in the mgmdInverseRouterCache table." ::= { mgmdInverseRouterCacheEntry 3 } -- -- The MGMD Host Source list Table -- mgmdHostSrcListTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdHostSrcListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the Source List entries corresponding to each interface and multicast group pair on a host." ::= { mgmdMIBObjects 7 } mgmdHostSrcListEntry OBJECT-TYPE SYNTAX MgmdHostSrcListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mgmdHostSrcListTable." INDEX { mgmdHostSrcListAddressType, mgmdHostSrcListAddress, mgmdHostSrcListIfIndex, mgmdHostSrcListHostAddress } ::= { mgmdHostSrcListTable 1 } MgmdHostSrcListEntry ::= SEQUENCE { mgmdHostSrcListAddressType InetAddressType, mgmdHostSrcListAddress InetAddress, Chesterfield & Haberman Standards Track [Page 23] RFC 5519 MGMD MIB April 2009 mgmdHostSrcListIfIndex InterfaceIndex, mgmdHostSrcListHostAddress InetAddress, mgmdHostSrcListExpire TimeTicks } mgmdHostSrcListAddressType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the InetAddress variables in this table. This value applies to the mgmdHostSrcListHostAddress and mgmdHostSrcListAddress entries." ::= { mgmdHostSrcListEntry 1 } mgmdHostSrcListAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address for which this entry contains information." ::= { mgmdHostSrcListEntry 2 } mgmdHostSrcListIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information for an IP multicast group address." ::= { mgmdHostSrcListEntry 3 } mgmdHostSrcListHostAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The host address to which this entry corresponds. The mgmdHostCacheSourceFilterMode value for this group address and interface indicates whether this host address is included or excluded." ::= { mgmdHostSrcListEntry 4 } Chesterfield & Haberman Standards Track [Page 24] RFC 5519 MGMD MIB April 2009 mgmdHostSrcListExpire OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates the relevance of the SrcList entry, whereby a non-zero value indicates this is an INCLUDE state value, and a zero value indicates this to be an EXCLUDE state value." ::= { mgmdHostSrcListEntry 5 } -- -- The MGMD Router Source list Table -- mgmdRouterSrcListTable OBJECT-TYPE SYNTAX SEQUENCE OF MgmdRouterSrcListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the Source List entries corresponding to each interface and multicast group pair on a Router." ::= { mgmdMIBObjects 8 } mgmdRouterSrcListEntry OBJECT-TYPE SYNTAX MgmdRouterSrcListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mgmdRouterSrcListTable." INDEX { mgmdRouterSrcListAddressType, mgmdRouterSrcListAddress, mgmdRouterSrcListIfIndex, mgmdRouterSrcListHostAddress } ::= { mgmdRouterSrcListTable 1 } MgmdRouterSrcListEntry ::= SEQUENCE { mgmdRouterSrcListAddressType InetAddressType, mgmdRouterSrcListAddress InetAddress, mgmdRouterSrcListIfIndex InterfaceIndex, mgmdRouterSrcListHostAddress InetAddress, mgmdRouterSrcListExpire TimeTicks } Chesterfield & Haberman Standards Track [Page 25] RFC 5519 MGMD MIB April 2009 mgmdRouterSrcListAddressType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of the InetAddress variables in this table. This value applies to the mgmdRouterSrcListHostAddress and mgmdRouterSrcListAddress entries." ::= { mgmdRouterSrcListEntry 1 } mgmdRouterSrcListAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP multicast group address for which this entry contains information." ::= { mgmdRouterSrcListEntry 2 } mgmdRouterSrcListIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information for an IP multicast group address." ::= { mgmdRouterSrcListEntry 3 } mgmdRouterSrcListHostAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The host address to which this entry corresponds. The mgmdRouterCacheSourceFilterMode value for this group address and interface indicates whether this host address is included or excluded." ::= { mgmdRouterSrcListEntry 4 } mgmdRouterSrcListExpire OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current Chesterfield & Haberman Standards Track [Page 26] RFC 5519 MGMD MIB April 2009 DESCRIPTION "This value indicates the relevance of the SrcList entry, whereby a non-zero value indicates this is an INCLUDE state value, and a zero value indicates this to be an EXCLUDE state value." ::= { mgmdRouterSrcListEntry 5 } -- conformance information mgmdMIBConformance OBJECT IDENTIFIER ::= { mgmdStdMIB 2 } mgmdMIBCompliance OBJECT IDENTIFIER ::= { mgmdMIBConformance 1 } mgmdMIBGroups OBJECT IDENTIFIER ::= { mgmdMIBConformance 2 } -- Protocol Version Conformance -- Read Compliance statement for IGMPv1 Hosts -- IGMPv1 only supports the IPv4 Address Family mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A read-only compliance statement for hosts running IGMPv1 [RFC1112] and implementing the MGMD MIB. IGMPv1 hosts must support the IPv4 address type." MODULE -- this module MANDATORY-GROUPS { mgmdHostBaseMIBGroup } OBJECT mgmdHostInterfaceStatus SYNTAX RowStatus {active(1)} MIN-ACCESS read-only DESCRIPTION "Read-write or read-create access is not required and only the value 'active(1)' needs to be supported." OBJECT mgmdHostInterfaceVersion SYNTAX Unsigned32 (1) MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only version 1 needs to be supported." GROUP mgmdHostExtendedMIBGroup DESCRIPTION "Supporting this group can be especially useful in an environment with a router that does not support the MGMD MIB." Chesterfield & Haberman Standards Track [Page 27] RFC 5519 MGMD MIB April 2009 ::= { mgmdMIBCompliance 1 } -- Read Compliance statement for IGMPv1 Routers -- IGMPv1 only supports the IPv4 Address Family mgmdIgmpV1RouterReadMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A read-only compliance statement for routers running IGMPv1 [RFC1112] and implementing the MGMD MIB. IGMPv1 routers only support the IPv4 address type. Non-accessible index objects that only need IPv4 support are: OBJECT mgmdRouterCacheAddressType SYNTAX InetAddressType { ipv4(1) } OBJECT mgmdRouterCacheAddress SYNTAX InetAddress (SIZE(4)) OBJECT mgmdRouterInterfaceQuerierType SYNTAX InetAddressType { ipv4(1) } OBJECT mgmdInverseRouterCacheAddressType SYNTAX InetAddressType { ipv4(1) } " MODULE -- this module MANDATORY-GROUPS { mgmdRouterBaseMIBGroup } OBJECT mgmdRouterCacheLastReporter SYNTAX InetAddress (SIZE(4)) DESCRIPTION "IGMPv1 routers only support IPv4 addresses." OBJECT mgmdRouterInterfaceQuerier SYNTAX InetAddress (SIZE(4)) DESCRIPTION "IGMPv1 routers only support IPv4 addresses." OBJECT mgmdInverseRouterCacheAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "IGMPv1 routers only support IPv4 addresses." OBJECT mgmdRouterInterfaceVersion SYNTAX Unsigned32 (1) Chesterfield & Haberman Standards Track [Page 28] RFC 5519 MGMD MIB April 2009 MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only version 1 needs to be supported." OBJECT mgmdRouterInterfaceStatus SYNTAX RowStatus {active(1)} MIN-ACCESS read-only DESCRIPTION "Read-write or read-create access is not required and only the value 'active(1)' needs to be supported." OBJECT mgmdRouterInterfaceQueryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mgmdMIBCompliance 2 } -- Write Compliance statement for IGMPv1 Routers -- IGMPv1 only supports the IPv4 Address Family mgmdIgmpV1RouterWriteMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A read-create compliance statement for routers running IGMPv1 [RFC1112] and implementing the MGMD MIB. IGMPv1 routers only support the IPv4 address type. Non-accessible index objects that only need IPv4 support are: OBJECT mgmdRouterCacheAddressType SYNTAX InetAddressType { ipv4(1) } OBJECT mgmdRouterCacheAddress SYNTAX InetAddress (SIZE(4)) OBJECT mgmdRouterInterfaceQuerierType SYNTAX InetAddressType { ipv4(1) } OBJECT mgmdInverseRouterCacheAddressType SYNTAX InetAddressType { ipv4(1) } " MODULE -- this module MANDATORY-GROUPS { mgmdRouterBaseMIBGroup } Chesterfield & Haberman Standards Track [Page 29] RFC 5519 MGMD MIB April 2009 OBJECT mgmdRouterCacheLastReporter SYNTAX InetAddress (SIZE(4)) DESCRIPTION "Only IPv4 addresses needed for IGMPv1 router support." OBJECT mgmdRouterInterfaceQuerier SYNTAX InetAddress (SIZE(4)) DESCRIPTION "Only IPv4 addresses needed for IGMPv1 router support." OBJECT mgmdInverseRouterCacheAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "Only IPv4 addresses needed for IGMPv1 router support." OBJECT mgmdRouterInterfaceVersion SYNTAX Unsigned32 (1) DESCRIPTION "Write access is not required. Only version 1 needs to be supported." ::= { mgmdMIBCompliance 3 } -- Read Compliance statement for IGMPv2 and MLDv1 Hosts -- IGMPv2 only supports the IPv4 Address Family -- MLDv1 only supports the IPv6 Address Family mgmdIgmpV2MldV1HostReadMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A read-only compliance statement for hosts running IGMPv2 [RFC2236] or MLDv1 [RFC2710] and implementing the MGMD MIB. IGMPv2 hosts only support the IPv4 address type and MLDv1 hosts only support the IPv6 address type." MODULE -- this module MANDATORY-GROUPS { mgmdHostBaseMIBGroup, mgmdV2HostMIBGroup } OBJECT mgmdHostInterfaceStatus SYNTAX RowStatus {active(1)} MIN-ACCESS read-only DESCRIPTION "Read-write or read-create access is not required and only the value 'active(1)' needs to be supported." OBJECT mgmdHostInterfaceVersion SYNTAX Unsigned32 (1..2) Chesterfield & Haberman Standards Track [Page 30] RFC 5519 MGMD MIB April 2009 MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only versions 1 and 2 need to be supported." GROUP mgmdHostExtendedMIBGroup DESCRIPTION "Supporting this group can be especially useful in an environment with a router that does not support the MGMD MIB." ::= { mgmdMIBCompliance 4 } -- Write Compliance statement for IGMPv2 and MLDv1 Hosts -- IGMPv2 only supports the IPv4 Address Family -- MLDv1 only supports the IPv6 Address Family mgmdIgmpV2MldV1HostWriteMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A read-create compliance statement for hosts running IGMPv2 [RFC2236] or MLDv1 [RFC2710] and implementing the MGMD MIB. IGMPv2 hosts only support the IPv4 address type and MLDv1 hosts only support the IPv6 address type." MODULE -- this module MANDATORY-GROUPS { mgmdHostBaseMIBGroup, mgmdV2HostMIBGroup } OBJECT mgmdHostInterfaceVersion SYNTAX Unsigned32 (1..2) DESCRIPTION "Only versions 1 and 2 need to be supported." ::= { mgmdMIBCompliance 5 } -- Read Compliance statement for IGMPv2 and MLDv1 Routers -- IGMPv2 only supports the IPv4 Address Family -- MLDv1 only supports the IPv6 Address Family mgmdIgmpV2MldV1RouterReadMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A read-only compliance statement for routers running IGMPv2 [RFC2236] or MLDv1 [RFC2710] and implementing the MGMD MIB. IGMPv2 routers only support the IPv4 address type and MLDv1 routers only support the IPv6 address type." MODULE -- this module MANDATORY-GROUPS { mgmdRouterBaseMIBGroup, Chesterfield & Haberman Standards Track [Page 31] RFC 5519 MGMD MIB April 2009 mgmdV2RouterBaseMIBGroup } OBJECT mgmdRouterInterfaceLastMemberQueryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdRouterInterfaceRobustness MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdRouterInterfaceQueryMaxResponseTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdRouterInterfaceVersion SYNTAX Unsigned32 (1..2) MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only versions 1 and 2 need to be supported." OBJECT mgmdRouterInterfaceStatus SYNTAX RowStatus {active(1)} MIN-ACCESS read-only DESCRIPTION "Read-write or read-create access is not required and only the value 'active(1)' needs to be supported." OBJECT mgmdRouterInterfaceQueryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP mgmdV2ProxyMIBGroup DESCRIPTION "Write access is not required." ::= { mgmdMIBCompliance 6 } -- Write Compliance statement for IGMPv2, IGMPv3, MLDv1, and MLDv2 -- Routers -- IGMPv2 and IGMPv3 only support the IPv4 Address Family -- MLDv1 and MLDv2 only support the IPv6 Address Family Chesterfield & Haberman Standards Track [Page 32] RFC 5519 MGMD MIB April 2009 mgmdIgmpV2V3MldV1V2RouterWriteMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "A read-create compliance statement for routers running IGMPv2 [RFC2236], IGMPv3 [RFC3376], MLDv1 [RFC2710], or MLDv2 [RFC3810] and implementing the MGMD MIB. IGMPv2 and IGMPv3 routers only support the IPv4 address type, while MLDv1 and MLDv2 routers only support the IPv6 address type." MODULE -- this module MANDATORY-GROUPS { mgmdRouterBaseMIBGroup, mgmdV2RouterBaseMIBGroup } GROUP mgmdV2ProxyMIBGroup DESCRIPTION "Read-create access is required." ::= { mgmdMIBCompliance 7 } -- Read Compliance statement for IGMPv2, IGMPv3, MLDv1, and MLDv2 Hosts -- IGMPv2 and IGMPv3 only support the IPv4 Address Family -- MLDv1 and MLDv2 only support the IPv6 Address Family mgmdIgmpV3MldV2HostReadMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts running IGMPv3 [RFC3376] or MLDv2 [RFC3810] and implementing the MGMD MIB. IGMPv3 hosts only support the IPv4 address type and MLDv2 hosts only support the IPv6 address type." MODULE -- this module MANDATORY-GROUPS { mgmdHostBaseMIBGroup, mgmdV2HostMIBGroup, mgmdV3HostMIBGroup } OBJECT mgmdHostInterfaceVersion MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdHostInterfaceStatus SYNTAX RowStatus {active(1)} MIN-ACCESS read-only DESCRIPTION "Read-write or read-create access is not required and only the value 'active(1)' needs to be supported." Chesterfield & Haberman Standards Track [Page 33] RFC 5519 MGMD MIB April 2009 OBJECT mgmdHostInterfaceVersion3Robustness MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP mgmdHostExtendedMIBGroup DESCRIPTION "Supporting this group can be especially useful in an environment with a router that does not support the MGMD MIB." ::= { mgmdMIBCompliance 8 } -- Write Compliance statement for IGMPv2, IGMPv3, MLDv1, and MLDv2 Hosts -- IGMPv2 and IGMPv3 only support the IPv4 Address Family -- MLDv1 and MLDv2 only support the IPv6 Address Family mgmdIgmpV3MldV2HostWriteMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts running IGMPv3 [RFC3376] or MLDv2 [RFC3810] and implementing the MGMD MIB. IGMPv3 hosts only support the IPv4 address type and MLDv2 hosts only support the IPv6 address type." MODULE -- this module MANDATORY-GROUPS { mgmdHostBaseMIBGroup, mgmdV2HostMIBGroup, mgmdV3HostMIBGroup } GROUP mgmdHostExtendedMIBGroup DESCRIPTION "Supporting this group can be especially useful in an environment with a router that does not support the MGMD MIB." ::= { mgmdMIBCompliance 9 } -- Read Compliance statement for IGMPv2, IGMPv3, MLDv1, and MLDv2 -- Routers -- IGMPv2 and IGMPv3 only support the IPv4 Address Family -- MLDv1 and MLDv2 only support the IPv6 Address Family mgmdIgmpV3MldV2RouterReadMIBCompliance MODULE-COMPLIANCE STATUS current Chesterfield & Haberman Standards Track [Page 34] RFC 5519 MGMD MIB April 2009 DESCRIPTION "A read-only compliance statement for routers running IGMPv3 [RFC3376] or MLDv2 [RFC3810] and implementing the MGMD MIB. IGMPv3 routers only support the IPv4 address type and MLDv2 routers only support the IPv6 address type." MODULE -- this module MANDATORY-GROUPS { mgmdRouterBaseMIBGroup, mgmdV2RouterBaseMIBGroup, mgmdV3RouterMIBGroup } OBJECT mgmdRouterInterfaceLastMemberQueryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdRouterInterfaceRobustness MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdRouterInterfaceQueryMaxResponseTime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdRouterInterfaceVersion MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mgmdRouterInterfaceStatus SYNTAX RowStatus {active(1)} MIN-ACCESS read-only DESCRIPTION "Read-write or read-create access is not required and only the value 'active(1)' needs to be supported." OBJECT mgmdRouterInterfaceQueryInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." GROUP mgmdV2ProxyMIBGroup DESCRIPTION "Write access is not required." Chesterfield & Haberman Standards Track [Page 35] RFC 5519 MGMD MIB April 2009 ::= { mgmdMIBCompliance 10 } -- units of conformance mgmdHostBaseMIBGroup OBJECT-GROUP OBJECTS { mgmdHostInterfaceStatus, mgmdHostInterfaceVersion } STATUS current DESCRIPTION "The basic collection of objects providing management of MGMD version 1, 2, or 3 for hosts." ::= { mgmdMIBGroups 1 } mgmdRouterBaseMIBGroup OBJECT-GROUP OBJECTS { mgmdRouterInterfaceStatus, mgmdRouterInterfaceQueryInterval, mgmdRouterCacheUpTime, mgmdRouterCacheExpiryTime, mgmdRouterInterfaceVersion, mgmdRouterInterfaceJoins, mgmdRouterInterfaceGroups, mgmdRouterCacheLastReporter, mgmdRouterInterfaceQuerierUpTime, mgmdRouterInterfaceQuerierExpiryTime, mgmdRouterInterfaceQuerier, mgmdInverseRouterCacheAddress } STATUS current DESCRIPTION "The basic collection of objects providing management of MGMD version 1, 2, or 3 for routers." ::= { mgmdMIBGroups 2 } mgmdV2HostMIBGroup OBJECT-GROUP OBJECTS { mgmdHostInterfaceVersion1QuerierTimer } STATUS current DESCRIPTION "A collection of additional read-only objects for management of IGMP version 2 in hosts for MGMD version 2 compliance." ::= { mgmdMIBGroups 3 } mgmdHostExtendedMIBGroup OBJECT-GROUP OBJECTS { mgmdHostCacheLastReporter, mgmdHostCacheUpTime, mgmdHostInterfaceQuerier, mgmdInverseHostCacheAddress } STATUS current Chesterfield & Haberman Standards Track [Page 36] RFC 5519 MGMD MIB April 2009 DESCRIPTION "A collection of optional objects for MGMD hosts." ::= { mgmdMIBGroups 4 } mgmdV2RouterBaseMIBGroup OBJECT-GROUP OBJECTS { mgmdRouterInterfaceWrongVersionQueries, mgmdRouterInterfaceLastMemberQueryCount, mgmdRouterInterfaceStartupQueryCount, mgmdRouterInterfaceStartupQueryInterval, mgmdRouterCacheVersion1HostTimer, mgmdRouterInterfaceQueryMaxResponseTime, mgmdRouterInterfaceRobustness, mgmdRouterInterfaceLastMemberQueryInterval } STATUS current DESCRIPTION "A collection of additional read-only objects for management of MGMD version 2 in routers." ::= { mgmdMIBGroups 5 } mgmdV2ProxyMIBGroup OBJECT-GROUP OBJECTS { mgmdRouterInterfaceProxyIfIndex } STATUS current DESCRIPTION "A collection of additional read-create objects for management of MGMD proxy devices." ::= { mgmdMIBGroups 6 } mgmdV3HostMIBGroup OBJECT-GROUP OBJECTS { mgmdHostInterfaceVersion2QuerierTimer, mgmdHostCacheSourceFilterMode, mgmdHostInterfaceVersion3Robustness, mgmdHostSrcListExpire } STATUS current DESCRIPTION "A collection of additional objects for management of MGMD version 3 in hosts." ::= { mgmdMIBGroups 7 } mgmdV3RouterMIBGroup OBJECT-GROUP OBJECTS { mgmdRouterCacheSourceFilterMode, mgmdRouterCacheVersion2HostTimer, mgmdRouterCacheExcludeModeExpiryTimer, Chesterfield & Haberman Standards Track [Page 37] RFC 5519 MGMD MIB April 2009 mgmdRouterSrcListExpire } STATUS current DESCRIPTION "A collection of additional read-only objects for management of MGMD version 3 in routers." ::= { mgmdMIBGroups 8 } END 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The mgmdRouterInterfaceTable provides read-create access to 2 values: the mgmdRouterInterfaceStatus and the mgmdRouterInterfaceQueryInterval. The mgmdRouterInterfaceStatus presents a remote user with the ability to enable or disable multicast support on a given router interface, and therefore presents a significant denial-of-service vulnerability. The mgmdRouterInterfaceQueryInterval controls the frequency with which host-query packets are sent, providing less of a vulnerability, but still requiring secure access control. o The mgmdRouterCacheTable also provides access to read-create objects. The mgmdRouterInterfaceVersion controls the protocol conformance of an interface, and is therefore a potential denial- of-service vulnerability. The mgmdRouterInterfaceQueryMaxResponseTime, the mgmdRouterInterfaceRobustness, and the mgmdRouterInterfaceLastMemberQueryInterval are all tuning parameters to control the characteristic of the host-query packets. Compromise of these objects can potentially be disruptive to local multicast communication. o The mgmdHostInterfaceTable provides a read-create object, the mgmdHostInterfaceVersion3Robustness, which controls the robustness of the interface to packet loss. Disabling robustness in the face of packet loss could cause denial of service to hosts; however, in general this presents a low risk. Chesterfield & Haberman Standards Track [Page 38] RFC 5519 MGMD MIB April 2009 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations This MIB introduces a new term to refer to two existing multicast protocols: Multicast Group Membership Discovery. It encompasses both the IPv4 Multicast discovery protocol, IGMP, and the IPv6 Multicast discovery protocol, MLD, as defined in RFCs 2933 [RFC2933] and 3019 [RFC3019], respectively. The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- mgmdStdMIB { mib-2 185 } 8. Contributors The authors of RFC 2933 [RFC2933] and RFC 3019 [RFC3019] from which this document is derived are: Keith McCloghrie Dino Farinacci Dave Thaler Brian Haberman Randy Worzella Chesterfield & Haberman Standards Track [Page 39] RFC 5519 MGMD MIB April 2009 9. Acknowledgements Special thanks to James Lingard, Bill Fenner, and Dave Thaler for detailed comments on the MIB. Bert Wijnen deserves special recognition for his exhaustive reviews and constructive feedback on SNMP and SMI issues related to this MIB. 10. References 10.1. Normative References [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Chesterfield & Haberman Standards Track [Page 40] RFC 5519 MGMD MIB April 2009 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 10.2. Informative References [RFC2933] McCloghrie, K., Farinacci, D., and D. Thaler, "Internet Group Management Protocol MIB", RFC 2933, October 2000. [RFC3019] Haberman, B. and R. Worzella, "IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol", RFC 3019, January 2001. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. Authors' Addresses Julian Chesterfield University of Cambridge 15 JJ Thompson Avenue Cambridge CB3 0FD UK EMail: julian.chesterfield@cl.cam.ac.uk Brian Haberman (editor) Johns Hopkins University / Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723 USA EMail: brian@innovationslab.net Chesterfield & Haberman Standards Track [Page 41] snmp-mibs-downloader-1.1/mibrfcs/rfc5525.txt0000644000000000000000000024761111402176072015576 0ustar Network Working Group T. Dreibholz Request for Comments: 5525 University of Duisburg-Essen Category: Experimental J. Mulik Delaware State University April 2009 Reliable Server Pooling MIB Module Definition Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol). This document defines an SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation. Dreibholz & Mulik Experimental [Page 1] RFC 5525 RSerPool MIB Module April 2009 Table of Contents 1. Introduction ....................................................2 2. The Reliable Server Pooling (RSerPool) Framework ................2 3. Conventions .....................................................2 4. The Internet-Standard Management Framework ......................2 5. Structure of the MIB ............................................3 5.1. Access to Managed Objects on ENRP Servers .................10 5.2. Access to Managed Objects on Pool Elements ................10 5.3. Access to Managed Objects on Pool Users ...................11 5.4. Persistency Behavior ......................................11 6. Definitions ....................................................11 7. Operational Considerations .....................................42 8. Security Considerations ........................................42 9. IANA Considerations ............................................43 10. Acknowledgments ...............................................43 11. References ....................................................44 11.1. Normative References .....................................44 11.2. Informative References ...................................44 1. Introduction This memo defines a Management Information Base (MIB) module that describes managed objects for RSerPool implementations. 2. The Reliable Server Pooling (RSerPool) Framework For a detailed overview of the documents that describe the current Reliable Server Pooling (RSerPool) framework, please refer to [RFC3237], [RFC5351], [RFC5352], [RFC5353], [RFC5354], [RFC5355], and [RFC5356]. A more informal introduction can be found at [RSerPoolPage] as well as in [Dre2006], [LCN2005], and [IJHIT2008]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Dreibholz & Mulik Experimental [Page 2] RFC 5525 RSerPool MIB Module April 2009 Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. The textual conventions are compliant to RFC 4001 [RFC4001]. 5. Structure of the MIB The following diagram illustrates the structure of the MIB. Structure of MIB +--rserpoolMIB(125) | +--rserpoolMIBObjects(1) | | | +--rserpoolENRPServers(1) | | | | | +--rserpoolENRPTable(1) | | | | | | | +--rserpoolENRPEntry(1) | | | | Index: rserpoolENRPIndex | | | | | | | +-- ---- Unsigned rserpoolENRPIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- String rserpoolENRPOperationScope(2) | | | | Textual Conv.: RSerPoolOperationScopeTC | | | | Size: 0..65535 | | | +-- -R-- Unsigned rserpoolENRPIdentifier(3) | | | | Textual Conv.: RSerPoolENRPServerIdentifierTC | | | | Range: 1..4294967295 | | | +-- -RW- String rserpoolENRPDescription(4) | | | | Size: 0..255 | | | +-- -R-- TimeTicks rserpoolENRPUptime(5) | | | +-- -R-- Unsigned rserpoolENRPPort(6) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- Unsigned rserpoolENRPASAPAnnouncePort(7) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- EnumVal rserpoolENRPASAPAnnounceAddrType(8) | | | | Textual Conv.: InetAddressType | | | | Values: ipv4(1), ipv6(2) | | | +-- -R-- String rserpoolENRPASAPAnnounceAddr(9) | | | | Textual Conv.: InetAddress | | | | Size: 4 | 16 Dreibholz & Mulik Experimental [Page 3] RFC 5525 RSerPool MIB Module April 2009 | | | +-- -R-- Unsigned rserpoolENRPENRPAnnouncePort(10) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- EnumVal rserpoolENRPENRPAnnounceAddrType(11) | | | | Textual Conv.: InetAddressType | | | | Values: ipv4(1), ipv6(2) | | | +-- -R-- String rserpoolENRPENRPAnnounceAddr(12) | | | Textual Conv.: InetAddress | | | Size: 4 | 16 | | | | | +--rserpoolENRPPoolTable(3) | | | | | | | +--rserpoolENRPPoolEntry(1) | | | | Index: rserpoolENRPIndex, rserpoolENRPPoolIndex | | | | | | | +-- ---- Unsigned rserpoolENRPPoolIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- String rserpoolENRPPoolHandle(2) | | | Textual Conv.: RSerPoolPoolHandleTC | | | Size: 0..65535 | | | | | +--rserpoolENRPPoolElementTable(4) | | | | | | | +--rserpoolENRPPoolElementEntry(1) | | | | Index: rserpoolENRPIndex, rserpoolENRPPoolIndex, | | | | rserpoolENRPPoolElementIndex | | | | | | | +-- ---- Unsigned rserpoolENRPPoolElementIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- Unsigned rserpoolENRPPoolElementID(2) | | | | Textual Conv.: RserpoolPoolElementIdentifierTC | | | | Range: 1..4294967295 | | | +-- -R-- Unsigned rserpoolENRPASAPTransportPort(3) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- Unsigned rserpoolENRPUserTransportProto(4) | | | | Range: 0..255 | | | +-- -R-- Unsigned rserpoolENRPUserTransportPort(5) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- EnumVal rserpoolENRPUserTransportUse(6) | | | | Textual Conv.: RSerPoolTransportUseTypeTC | | | | Values: dataOnly(0), dataPlusControl(1) | | | +-- -R-- Unsigned rserpoolENRPPolicyID(7) | | | | Textual Conv.: RSerPoolPolicyIdentifierTC | | | | Range: 1..4294967295 | | | +-- -R-- String rserpoolENRPPolicyDescription(8) | | | | Size: 0..255 Dreibholz & Mulik Experimental [Page 4] RFC 5525 RSerPool MIB Module April 2009 | | | +-- -R-- Unsigned rserpoolENRPPolicyWeight(9) | | | | Textual Conv.: RSerPoolPolicyWeightTC | | | | Range: 0..4294967295 | | | +-- -R-- Unsigned rserpoolENRPPolicyLoad(10) | | | | Textual Conv.: RSerPoolPolicyLoadTC | | | | Range: 0..4294967295 | | | +-- -R-- Unsigned rserpoolENRPPolicyLoadDeg(11) | | | | Textual Conv.: RSerPoolPolicyLoadTC | | | | Range: 0..4294967295 | | | +-- -R-- TimeTicks rserpoolENRPRegistrationLife(12) | | | +-- -R-- Unsigned rserpoolENRPHomeENRPServer(13) | | | Textual Conv.: RSerPoolENRPServerIdentifierTC | | | Range: 1..4294967295 | | | | | +--rserpoolENRPASAPAddrTable(5) | | | | | | | +--rserpoolENRPASAPAddrTableEntry(1) | | | | Index: rserpoolENRPIndex, rserpoolENRPPoolIndex, | | | | rserpoolENRPPoolElementIndex, | | | | rserpoolENRPASAPAddrTableIndex | | | | | | | +-- ---- Unsigned rserpoolENRPASAPAddrTableIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- EnumVal rserpoolENRPASAPL3Type(2) | | | | Textual Conv.: InetAddressType | | | | Values: ipv4(1), ipv6(2) | | | +-- -R-- String rserpoolENRPASAPL3Addr(3) | | | Textual Conv.: InetAddress | | | Size: 4 | 16 | | | | | +--rserpoolENRPUserAddrTable(6) | | | | | | | +--rserpoolENRPUserAddrTableEntry(1) | | | | Index: rserpoolENRPIndex, rserpoolENRPPoolIndex, | | | | rserpoolENRPPoolElementIndex, | | | | rserpoolENRPUserAddrTableIndex | | | | | | | +-- ---- Unsigned rserpoolENRPUserAddrTableIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- EnumVal rserpoolENRPUserL3Type(2) | | | | Textual Conv.: InetAddressType | | | | Values: unknown(0), ipv4(1), ipv6(2) | | | +-- -R-- String rserpoolENRPUserL3Addr(3) | | | | Textual Conv.: InetAddress | | | | Size: 0 | 4 | 16 | | | +-- -R-- String rserpoolENRPUserL3Opaque(4) | | | Textual Conv.: RSerPoolOpaqueAddressTC | | | Size: 0..65535 Dreibholz & Mulik Experimental [Page 5] RFC 5525 RSerPool MIB Module April 2009 | | | | | +--rserpoolENRPENRPAddrTable(7) | | | | | | | +--rserpoolENRPENRPAddrTableEntry(1) | | | | Index: rserpoolENRPIndex, | | | | rserpoolENRPENRPAddrTableIndex | | | | | | | +-- ---- Unsigned rserpoolENRPENRPAddrTableIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- EnumVal rserpoolENRPENRPL3Type(2) | | | | Textual Conv.: InetAddressType | | | | Values: ipv4(1), ipv6(2) | | | +-- -R-- String rserpoolENRPENRPL3Addr(3) | | | Textual Conv.: InetAddress | | | Size: 4 | 16 | | | | | +--rserpoolENRPPeerTable(8) | | | | | | | +--rserpoolENRPPeerEntry(1) | | | | Index: rserpoolENRPPeerIndex | | | | | | | +-- ---- Unsigned rserpoolENRPPeerIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- Unsigned rserpoolENRPPeerIdentifier(2) | | | | Textual Conv.: RSerPoolENRPServerIdentifierTC | | | | Range: 1..4294967295 | | | +-- -R-- Unsigned rserpoolENRPPeerPort(3) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- TimeTicks rserpoolENRPPeerLastHeard(4) | | | | | +--rserpoolENRPPeerAddrTable(9) | | | | | +--rserpoolENRPPeerAddrTableEntry(1) | | | Index: rserpoolENRPPeerIndex, | | | | rserpoolENRPPeerAddrTableIndex | | | | | +-- ---- Unsigned rserpoolENRPPeerAddrTableIndex(1) | | | Range: 1..4294967295 | | +-- -R-- EnumVal rserpoolENRPPeerL3Type(2) | | | Textual Conv.: InetAddressType | | | Values: ipv4(1), ipv6(2) | | +-- -R-- String rserpoolENRPPeerL3Addr(3) | | Textual Conv.: InetAddress | | Size: 4 | 16 | | | +--rserpoolPoolElements(2) | | | Dreibholz & Mulik Experimental [Page 6] RFC 5525 RSerPool MIB Module April 2009 | | +--rserpoolPETable(1) | | | | | | | +--rserpoolPEEntry(1) | | | | Index: rserpoolPEIndex | | | | | | | +-- ---- Unsigned rserpoolPEIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- String rserpoolPEOperationScope(2) | | | | Textual Conv.: RSerPoolOperationScopeTC | | | | Size: 0..65535 | | | +-- -RW- String rserpoolPEPoolHandle(3) | | | | Textual Conv.: RSerPoolPoolHandleTC | | | | Size: 0..65535 | | | +-- -R-- Unsigned rserpoolPEIdentifier(4) | | | | Textual Conv.: RserpoolPoolElementIdentifierTC | | | | Range: 1..4294967295 | | | +-- -RW- String rserpoolPEDescription(5) | | | | Size: 0..255 | | | +-- -R-- TimeTicks rserpoolPEUptime(6) | | | +-- -R-- Unsigned rserpoolPEASAPTransportPort(7) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- Unsigned rserpoolPEUserTransportProto(8) | | | | Range: 0..255 | | | +-- -R-- Unsigned rserpoolPEUserTransportPort(9) | | | | Textual Conv.: InetPortNumber | | | | Range: 0..65535 | | | +-- -R-- EnumVal rserpoolPEUserTransportUse(10) | | | | Textual Conv.: RSerPoolTransportUseTypeTC | | | | Values: dataOnly(0), dataPlusControl(1) | | | +-- -RW- Unsigned rserpoolPEPolicyID(11) | | | | Textual Conv.: RSerPoolPolicyIdentifierTC | | | | Range: 1..4294967295 | | | +-- -RW- String rserpoolPEPolicyDescription(12) | | | | Size: 0..255 | | | +-- -RW- Unsigned rserpoolPEPolicyWeight(13) | | | | Textual Conv.: RSerPoolPolicyWeightTC | | | | Range: 0..4294967295 | | | +-- -R-- Unsigned rserpoolPEPolicyLoad(14) | | | | Textual Conv.: RSerPoolPolicyLoadTC | | | | Range: 0..4294967295 | | | +-- -RW- Unsigned rserpoolPEPolicyLoadDeg(15) | | | | Textual Conv.: RSerPoolPolicyLoadTC | | | | Range: 0..4294967295 | | | +-- -RW- TimeTicks rserpoolPERegistrationLife(16) | | | +-- -R-- Unsigned rserpoolPEHomeENRPServer(17) | | | Textual Conv.: RSerPoolENRPServerIdentifierTC | | | Range: 1..4294967295 Dreibholz & Mulik Experimental [Page 7] RFC 5525 RSerPool MIB Module April 2009 | | | | | +--rserpoolPEASAPAddrTable(2) | | | | | | | +--rserpoolPEASAPAddrTableEntry(1) | | | | Index: rserpoolPEIndex, rserpoolPEASAPAddrTableIndex | | | | | | | +-- ---- Unsigned rserpoolPEASAPAddrTableIndex(1) | | | | Range: 1..4294967295 | | | +-- -R-- EnumVal rserpoolPEASAPL3Type(2) | | | | Textual Conv.: InetAddressType | | | | Values: ipv4(1), ipv6(2) | | | +-- -R-- String rserpoolPEASAPL3Addr(3) | | | Textual Conv.: InetAddress | | | Size: 4 | 16 | | | | | +--rserpoolPEUserAddrTable(6) | | | | | +--rserpoolPEUserAddrTableEntry(1) | | | Index: rserpoolPEIndex, rserpoolPEUserAddrTableIndex | | | | | +-- ---- Unsigned rserpoolPEUserAddrTableIndex(1) | | | Range: 1..4294967295 | | +-- -R-- EnumVal rserpoolPEUserL3Type(2) | | | Textual Conv.: InetAddressType | | | Values: unknown(0), ipv4(1), ipv6(2) | | +-- -R-- String rserpoolPEUserL3Addr(3) | | | Textual Conv.: InetAddress | | | Size: 0 | 4 | 16 | | +-- -R-- String rserpoolPEUserL3Opaque(4) | | Textual Conv.: RSerPoolOpaqueAddressTC | | Size: 0..65535 | | | +--rserpoolPoolUsers(3) | | | +--rserpoolPUTable(1) | | | +--rserpoolPUEntry(1) | | Index: rserpoolPUIndex | | | +-- ---- Unsigned rserpoolPUIndex(1) | | Range: 1..4294967295 | +-- -R-- String rserpoolPUOperationScope(2) | | Textual Conv.: RSerPoolOperationScopeTC | | Size: 0..65535 | +-- -RW- String rserpoolPUPoolHandle(3) | | Textual Conv.: RSerPoolPoolHandleTC | | Size: 0..65535 | +-- -RW- String rserpoolPUDescription(4) Dreibholz & Mulik Experimental [Page 8] RFC 5525 RSerPool MIB Module April 2009 | | Size: 0..255 | +-- -R-- TimeTicks rserpoolPUUptime(5) | +--rserpoolMIBConformance(2) | +--rserpoolMIBCompliances(1) | | | +--rserpoolMIBCompliance(1) | +--rserpoolMIBGroups(2) | +--rserpoolENRPGroup(1) +--rserpoolPEGroup(2) +--rserpoolPUGroup(3) As the figure shows, the MIB consists of three main branches: "rserpoolENRPServers", "rserpoolPoolElements", and "rserpoolPoolUsers". The first branch, "rserpoolENRPServers", is used to access managed objects in the set of ENRP servers running on a given host. While it is assumed that it does not make much sense to run multiple ENRP servers for the same operation scope on one host, running multiple ENRP servers for different operation scopes is very likely when the ENRP server processes run on routers. Therefore, the MIB has to be able to manage multiple ENRP servers on the same host. "rserpoolPoolElements" is used to access managed objects in the set of pool elements that are running on a given host. The third branch, "rserpoolPoolUsers", is used to access managed objects in the set of pool users that are running on a given host. Note: "rserpoolENRPServers" is filled on hosts running ENRP server instances, "rserpoolPoolElements" is filled on hosts running pool element instances, and "rserpoolPoolUsers" is filled on hosts running pool user instances. Of course, multiple different components may run on the same host, which leads to filling of multiple different branches. In fact, the structure of the three branches is very similar. Because the other two branches are so similar, we describe only the first branch in detail, and provide a summary description of the second and third branch. We now proceed with a description of the branches. Dreibholz & Mulik Experimental [Page 9] RFC 5525 RSerPool MIB Module April 2009 5.1. Access to Managed Objects on ENRP Servers The first branch describes managed objects at a set of ENRP servers. Any given ENRP server of this set will, at a certain moment in time, have registration information for a set of active pools. Each of these pools in turn may have a list of pool elements that are registered under that pool. To allow this information to be retrieved via SNMP, the ERNP server branch of the RSerPool MIB uses the table-in-table technique described in [SNMPMIBS]. Specifically, the ENRP servers branch creates four levels of nesting, as indicated in the following diagram: Nesting of the ENRP Server Branch Nesting Structure: Level 1: rserpoolENRPTable Level 2: rserpoolENRPPoolTable Level 3: rserpoolENRPPoolElementTable Level 4: rserpoolENRPASAPAddrTable rserpoolENRPUserAddrTable Level 2: rserpoolENRPENRPAddrTable Level 2: rserpoolENRPPeerTable Level 3: rserpoolENRPPeerAddrTable 5.2. Access to Managed Objects on Pool Elements The construction of the Pool Elements branch is very similar to the pool elements table of the ENRP servers branch. But instead of grouping the pool elements into pools (which does not make sense here), the pool elements table is the top of the hierarchy, and each pool element entry specifies its operation scope and pool handle. That is, the nesting structure is as follows: Nesting of the Pool Elements Branch Level 1: rserpoolPETable Level 2: rserpoolPEASAPAddrTable rserpoolPEUserAddrTable Dreibholz & Mulik Experimental [Page 10] RFC 5525 RSerPool MIB Module April 2009 5.3. Access to Managed Objects on Pool Users For the Pool Users branch, it is only necessary to list the pool user instances, including their operation scope and pool handle. 5.4. Persistency Behavior Upon changes of writable objects, an implementation SHOULD store the new values in a persistent manner if it has the capability to do this. An implementation SHOULD use these stored values upon reset or reinitialization. 6. Definitions RSERPOOL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, TimeTicks, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB; -- ## Module definition ########################################### rserpoolMIB MODULE-IDENTITY LAST-UPDATED "200904070000Z" -- April 07, 2009 ORGANIZATION "IEM-TdR, UNIVERSITY OF DUISBURG-ESSEN" CONTACT-INFO " THOMAS-DREIBHOLZ Postal: University of Duisburg-Essen Institute for Experimental Mathematics Ellernstrasse 29 D-45326 Essen Germany Phone: +49-201-183-7637 Fax: +49-201-183-7673 Email: dreibh@iem.uni-due.de Dreibholz & Mulik Experimental [Page 11] RFC 5525 RSerPool MIB Module April 2009 JAIWANT-MULIK Postal: Delaware State University CIS Department 1200 N. DuPont Hw Dover, DE USA 19904 Phone: +1-302-857-7910 Fax: +1-302-857-6552 Email: jaiwant@mulik.com" DESCRIPTION "The MIB module for managing an RSerPool implementation. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Dreibholz & Mulik Experimental [Page 12] RFC 5525 RSerPool MIB Module April 2009 This version of this MIB module is part of RFC 5525; see the RFC itself for full legal notices." REVISION "200904070000Z" -- April 07, 2009 DESCRIPTION "This version of the MIB module is published as RFC 5525" ::= { experimental 125 } -- ## RSerPool type definitions ################################### RSerPoolENRPServerIdentifierTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "x" STATUS current DESCRIPTION "The ID of an ENRP server" SYNTAX Unsigned32 (1..4294967295) RSerPoolOperationScopeTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1024t" STATUS current DESCRIPTION "The ID of an operation scope" SYNTAX OCTET STRING (SIZE (0..65535)) RSerPoolPoolHandleTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1024t" STATUS current DESCRIPTION "The pool handle" SYNTAX OCTET STRING (SIZE (0..65535)) RserpoolPoolElementIdentifierTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "x" STATUS current DESCRIPTION "The pool element ID" SYNTAX Unsigned32 (1..4294967295) RSerPoolPolicyIdentifierTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "x" STATUS current DESCRIPTION "The ID of the pool policy" SYNTAX Unsigned32 (1..4294967295) RSerPoolPolicyLoadTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The load status of a pool element" SYNTAX Unsigned32 (0..4294967295) Dreibholz & Mulik Experimental [Page 13] RFC 5525 RSerPool MIB Module April 2009 RSerPoolPolicyWeightTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The weight of a pool element" SYNTAX Unsigned32 (0..4294967295) RSerPoolTransportUseTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The transport use of a pool element" SYNTAX INTEGER { dataOnly(0), dataPlusControl(1) } RSerPoolOpaqueAddressTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1024t" STATUS current DESCRIPTION "Opaque address" SYNTAX OCTET STRING (SIZE (0..65535)) -- ## Top-level definitions ####################################### rserpoolMIBObjects OBJECT IDENTIFIER ::= { rserpoolMIB 1 } rserpoolMIBConformance OBJECT IDENTIFIER ::= { rserpoolMIB 2 } rserpoolENRPServers OBJECT IDENTIFIER ::= { rserpoolMIBObjects 1 } rserpoolPoolElements OBJECT IDENTIFIER ::= { rserpoolMIBObjects 2 } rserpoolPoolUsers OBJECT IDENTIFIER ::= { rserpoolMIBObjects 3 } -- ################################################################ -- #### ENRP Servers Section #### -- ################################################################ -- ## Definition of the ENRP server table ######################### rserpoolENRPTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table listing of ENRP servers." ::= { rserpoolENRPServers 1 } rserpoolENRPEntry OBJECT-TYPE SYNTAX RserpoolENRPEntry MAX-ACCESS not-accessible STATUS current Dreibholz & Mulik Experimental [Page 14] RFC 5525 RSerPool MIB Module April 2009 DESCRIPTION "An ENRP server entry in the table listing of ENRP servers." INDEX { rserpoolENRPIndex } ::= { rserpoolENRPTable 1 } RserpoolENRPEntry ::= SEQUENCE { rserpoolENRPIndex Unsigned32, rserpoolENRPOperationScope RSerPoolOperationScopeTC, rserpoolENRPIdentifier RSerPoolENRPServerIdentifierTC, rserpoolENRPDescription OCTET STRING, rserpoolENRPUptime TimeTicks, rserpoolENRPPort InetPortNumber, rserpoolENRPASAPAnnouncePort InetPortNumber, rserpoolENRPASAPAnnounceAddrType InetAddressType, rserpoolENRPASAPAnnounceAddr InetAddress, rserpoolENRPENRPAnnouncePort InetPortNumber, rserpoolENRPENRPAnnounceAddrType InetAddressType, rserpoolENRPENRPAnnounceAddr InetAddress } rserpoolENRPIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer to uniquely identify an ENRP server." ::= { rserpoolENRPEntry 1 } rserpoolENRPOperationScope OBJECT-TYPE SYNTAX RSerPoolOperationScopeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The definition of the operation scope of this ENRP server." REFERENCE "Section 1.2 of RFC 3237 defines the term operation scope." ::= { rserpoolENRPEntry 2 } rserpoolENRPIdentifier OBJECT-TYPE SYNTAX RSerPoolENRPServerIdentifierTC MAX-ACCESS read-only STATUS current DESCRIPTION "The ENRP server identifier of this ENRP server." REFERENCE "Section 3.1 of RFC 5351 explains the ENRP server identifier." ::= { rserpoolENRPEntry 3 } Dreibholz & Mulik Experimental [Page 15] RFC 5525 RSerPool MIB Module April 2009 rserpoolENRPDescription OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "A textual description of this ENRP server, e.g., its location and a contact address of its administrator. This object SHOULD be maintained in a persistent manner." ::= { rserpoolENRPEntry 4 } rserpoolENRPUptime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The ENRP service uptime of this ENRP server." ::= { rserpoolENRPEntry 5 } rserpoolENRPPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The Stream Control Transmission Protocol (SCTP) port number of the ENRP protocol endpoint of this ENRP server." REFERENCE "RFC 5353 defines the ENRP protocol." ::= { rserpoolENRPEntry 6 } rserpoolENRPASAPAnnouncePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The destination UDP port number to which ASAP multicast announce messages are sent." REFERENCE "Section 3.2 of RFC 5351 explains the server-discovery mechanism using ASAP announces." ::= { rserpoolENRPEntry 7 } rserpoolENRPASAPAnnounceAddrType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current Dreibholz & Mulik Experimental [Page 16] RFC 5525 RSerPool MIB Module April 2009 DESCRIPTION "The network-layer protocol over which ASAP multicast announce messages are sent." REFERENCE "Section 3.2 of RFC 5351 explains the server-discovery mechanism using ASAP announces." ::= { rserpoolENRPEntry 8 } rserpoolENRPASAPAnnounceAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The destination IP multicast address to which ASAP multicast announce messages are sent. The type of this address is given in rserpoolENRPASAPAnnounceAddrType." REFERENCE "Section 3.2 of RFC 5351 explains the server-discovery mechanism using ASAP announces." ::= { rserpoolENRPEntry 9 } rserpoolENRPENRPAnnouncePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The destination UDP port number to which ENRP multicast announce messages are sent." REFERENCE "Section 3.1 of RFC 5353 explains the ENRP multicast announce mechanism." ::= { rserpoolENRPEntry 10 } rserpoolENRPENRPAnnounceAddrType OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer protocol over which ENRP multicast announce messages are sent." REFERENCE "Section 3.1 of RFC 5353 explains the ENRP multicast announce mechanism." ::= { rserpoolENRPEntry 11 } rserpoolENRPENRPAnnounceAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only Dreibholz & Mulik Experimental [Page 17] RFC 5525 RSerPool MIB Module April 2009 STATUS current DESCRIPTION "The destination multicast IP address to which ENRP multicast announce messages are sent. The type of this address is given in rserpoolENRPENRPAnnounceAddrType." REFERENCE "Section 3.1 of RFC 5353 explains the ENRP multicast announce mechanism." ::= { rserpoolENRPEntry 12 } -- ## Definition of the pool table ################################ rserpoolENRPPoolTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table listing of pools." ::= { rserpoolENRPServers 3 } rserpoolENRPPoolEntry OBJECT-TYPE SYNTAX RserpoolENRPPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pool entry in the table listing of pools." INDEX { rserpoolENRPIndex, rserpoolENRPPoolIndex } ::= { rserpoolENRPPoolTable 1 } RserpoolENRPPoolEntry ::= SEQUENCE { rserpoolENRPPoolIndex Unsigned32, rserpoolENRPPoolHandle RSerPoolPoolHandleTC } rserpoolENRPPoolIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer to uniquely identify a pool." ::= { rserpoolENRPPoolEntry 1 } rserpoolENRPPoolHandle OBJECT-TYPE SYNTAX RSerPoolPoolHandleTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool handle of this pool." REFERENCE "Section 1.2 of RFC 3237 defines the term pool handle." Dreibholz & Mulik Experimental [Page 18] RFC 5525 RSerPool MIB Module April 2009 ::= { rserpoolENRPPoolEntry 2 } -- ## Definition of the pool element table ######################## rserpoolENRPPoolElementTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPPoolElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table listing of pool elements." ::= { rserpoolENRPServers 4 } rserpoolENRPPoolElementEntry OBJECT-TYPE SYNTAX RserpoolENRPPoolElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A pool element in the table listing of pool elements." INDEX { rserpoolENRPIndex, rserpoolENRPPoolIndex, rserpoolENRPPoolElementIndex } ::= { rserpoolENRPPoolElementTable 1 } RserpoolENRPPoolElementEntry ::= SEQUENCE { rserpoolENRPPoolElementIndex Unsigned32, rserpoolENRPPoolElementID RserpoolPoolElementIdentifierTC, rserpoolENRPASAPTransportPort InetPortNumber, rserpoolENRPUserTransportProto Unsigned32, rserpoolENRPUserTransportPort InetPortNumber, rserpoolENRPUserTransportUse RSerPoolTransportUseTypeTC, rserpoolENRPPolicyID RSerPoolPolicyIdentifierTC, rserpoolENRPPolicyDescription OCTET STRING, rserpoolENRPPolicyWeight RSerPoolPolicyWeightTC, rserpoolENRPPolicyLoad RSerPoolPolicyLoadTC, rserpoolENRPPolicyLoadDeg RSerPoolPolicyLoadTC, rserpoolENRPRegistrationLife TimeTicks, rserpoolENRPHomeENRPServer RSerPoolENRPServerIdentifierTC } rserpoolENRPPoolElementIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current Dreibholz & Mulik Experimental [Page 19] RFC 5525 RSerPool MIB Module April 2009 DESCRIPTION "An integer to uniquely identify a pool element. Note, that uniqueness of a pool element identifier in the pool is not enforced; therefore, this index is required here!" ::={ rserpoolENRPPoolElementEntry 1 } rserpoolENRPPoolElementID OBJECT-TYPE SYNTAX RserpoolPoolElementIdentifierTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool element identifier of this pool element." REFERENCE "Section 2.2 of RFC 5351 explains the pool element identifier usage." ::={ rserpoolENRPPoolElementEntry 2 } rserpoolENRPASAPTransportPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The SCTP port number of the ASAP endpoint of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the port number is given here." ::= { rserpoolENRPPoolElementEntry 3 } rserpoolENRPUserTransportProto OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol number of the service endpoint of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the transport protocol number is given here." ::= { rserpoolENRPPoolElementEntry 4 } rserpoolENRPUserTransportPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol's port number of the service endpoint of this pool element." Dreibholz & Mulik Experimental [Page 20] RFC 5525 RSerPool MIB Module April 2009 REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the port number is given here." ::= { rserpoolENRPPoolElementEntry 5 } rserpoolENRPUserTransportUse OBJECT-TYPE SYNTAX RSerPoolTransportUseTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The transport use of the service endpoint of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the transport use is given here." ::= { rserpoolENRPPoolElementEntry 6 } rserpoolENRPPolicyID OBJECT-TYPE SYNTAX RSerPoolPolicyIdentifierTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool policy of this pool element." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy identifier is given here." ::= { rserpoolENRPPoolElementEntry 7 } rserpoolENRPPolicyDescription OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The textual description of the pool policy of this pool element." ::= { rserpoolENRPPoolElementEntry 8 } rserpoolENRPPolicyWeight OBJECT-TYPE SYNTAX RSerPoolPolicyWeightTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool policy's weight parameter for this pool element." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy's weight parameter is given here." ::= { rserpoolENRPPoolElementEntry 9 } Dreibholz & Mulik Experimental [Page 21] RFC 5525 RSerPool MIB Module April 2009 rserpoolENRPPolicyLoad OBJECT-TYPE SYNTAX RSerPoolPolicyLoadTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool policy's load status for this pool element." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy's load parameter is given here." ::= { rserpoolENRPPoolElementEntry 10 } rserpoolENRPPolicyLoadDeg OBJECT-TYPE SYNTAX RSerPoolPolicyLoadTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool policy's load degradation parameter for this pool element." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy's load degradation parameter is given here." ::= { rserpoolENRPPoolElementEntry 11 } rserpoolENRPRegistrationLife OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The registration life of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the Registration Life." ::= { rserpoolENRPPoolElementEntry 12 } rserpoolENRPHomeENRPServer OBJECT-TYPE SYNTAX RSerPoolENRPServerIdentifierTC MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the Home ENRP server of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the Home ENRP Server Identifier." ::= { rserpoolENRPPoolElementEntry 13 } -- ## Definition of the ASAP transport address list table ######### rserpoolENRPASAPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPASAPAddrTableEntry Dreibholz & Mulik Experimental [Page 22] RFC 5525 RSerPool MIB Module April 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing of all IP addresses of the ASAP transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the addresses are listed in this table." ::= { rserpoolENRPServers 5 } rserpoolENRPASAPAddrTableEntry OBJECT-TYPE SYNTAX RserpoolENRPASAPAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address of the ASAP transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which an address is contained by this entry." INDEX { rserpoolENRPIndex, rserpoolENRPPoolIndex, rserpoolENRPPoolElementIndex, rserpoolENRPASAPAddrTableIndex } ::= { rserpoolENRPASAPAddrTable 1 } RserpoolENRPASAPAddrTableEntry ::= SEQUENCE { rserpoolENRPASAPAddrTableIndex Unsigned32, rserpoolENRPASAPL3Type InetAddressType, rserpoolENRPASAPL3Addr InetAddress } rserpoolENRPASAPAddrTableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for the IP address of an ASAP transport endpoint." ::= { rserpoolENRPASAPAddrTableEntry 1 } rserpoolENRPASAPL3Type OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer protocol (IPv4 or IPv6) of an IP address of an ASAP transport endpoint." REFERENCE Dreibholz & Mulik Experimental [Page 23] RFC 5525 RSerPool MIB Module April 2009 "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the network-layer protocol number is given here." ::= { rserpoolENRPASAPAddrTableEntry 2 } rserpoolENRPASAPL3Addr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of an ASAP transport endpoint. The type of this address is given in rserpoolENRPASAPL3Type." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the network-layer address (IPv4 or IPv6) is given here." ::= { rserpoolENRPASAPAddrTableEntry 3 } -- ## Definition of the user transport address list table ######### rserpoolENRPUserAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPUserAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing of all IP addresses of the user transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the addresses are listed in this table." ::= { rserpoolENRPServers 6 } rserpoolENRPUserAddrTableEntry OBJECT-TYPE SYNTAX RserpoolENRPUserAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address of the user transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which an address is contained by this entry." INDEX { rserpoolENRPIndex, rserpoolENRPPoolIndex, rserpoolENRPPoolElementIndex, rserpoolENRPUserAddrTableIndex } ::= { rserpoolENRPUserAddrTable 1 } RserpoolENRPUserAddrTableEntry ::= SEQUENCE { rserpoolENRPUserAddrTableIndex Unsigned32, rserpoolENRPUserL3Type InetAddressType, Dreibholz & Mulik Experimental [Page 24] RFC 5525 RSerPool MIB Module April 2009 rserpoolENRPUserL3Addr InetAddress, rserpoolENRPUserL3Opaque RSerPoolOpaqueAddressTC } rserpoolENRPUserAddrTableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for the IP address of a user transport endpoint." ::= { rserpoolENRPUserAddrTableEntry 1 } rserpoolENRPUserL3Type OBJECT-TYPE SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer protocol (IPv4 or IPv6) of an IP address of a user transport endpoint. Set to unknown for an opaque address." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the network-layer protocol number is given here." ::= { rserpoolENRPUserAddrTableEntry 2 } rserpoolENRPUserL3Addr OBJECT-TYPE SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of a user transport endpoint. The type of this address is given in rserpoolENRPUserL3Type." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the network-layer address (IPv4 or IPv6) is given here." ::= { rserpoolENRPUserAddrTableEntry 3 } rserpoolENRPUserL3Opaque OBJECT-TYPE SYNTAX RSerPoolOpaqueAddressTC MAX-ACCESS read-only STATUS current DESCRIPTION "The opaque address of a user transport endpoint." REFERENCE "Section 3.16 of RFC 5354 defines the opaque transport address." ::= { rserpoolENRPUserAddrTableEntry 4 } Dreibholz & Mulik Experimental [Page 25] RFC 5525 RSerPool MIB Module April 2009 -- ## Definition of ENRP address list table ####################### rserpoolENRPENRPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPENRPAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing of all IP addresses of the ENRP transport endpoint." ::= { rserpoolENRPServers 7 } rserpoolENRPENRPAddrTableEntry OBJECT-TYPE SYNTAX RserpoolENRPENRPAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address of the ENRP transport endpoint." INDEX { rserpoolENRPIndex, rserpoolENRPENRPAddrTableIndex } ::= { rserpoolENRPENRPAddrTable 1 } RserpoolENRPENRPAddrTableEntry ::= SEQUENCE { rserpoolENRPENRPAddrTableIndex Unsigned32, rserpoolENRPENRPL3Type InetAddressType, rserpoolENRPENRPL3Addr InetAddress } rserpoolENRPENRPAddrTableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for the IP address of an ENRP transport endpoint." ::= { rserpoolENRPENRPAddrTableEntry 1 } rserpoolENRPENRPL3Type OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer protocol (IPv4 or IPv6) of an IP address of an ENRP transport endpoint." REFERENCE "RFC 5353 defines the ENRP protocol." ::= { rserpoolENRPENRPAddrTableEntry 2 } Dreibholz & Mulik Experimental [Page 26] RFC 5525 RSerPool MIB Module April 2009 rserpoolENRPENRPL3Addr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of an ENRP transport endpoint. The type of this address is given in rserpoolENRPENRPL3Type." REFERENCE "RFC 5353 defines the ENRP protocol." ::= { rserpoolENRPENRPAddrTableEntry 3 } -- ## Definition of peer table #################################### rserpoolENRPPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table listing of a peer table." ::= { rserpoolENRPServers 8 } rserpoolENRPPeerEntry OBJECT-TYPE SYNTAX RserpoolENRPPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A peer entry in the table listing of a peer table." INDEX { rserpoolENRPPeerIndex } ::= { rserpoolENRPPeerTable 1 } RserpoolENRPPeerEntry ::= SEQUENCE { rserpoolENRPPeerIndex Unsigned32, rserpoolENRPPeerIdentifier RSerPoolENRPServerIdentifierTC, rserpoolENRPPeerPort InetPortNumber, rserpoolENRPPeerLastHeard TimeTicks } rserpoolENRPPeerIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for a peer entry in the table listing of a peer table." ::= { rserpoolENRPPeerEntry 1 } rserpoolENRPPeerIdentifier OBJECT-TYPE SYNTAX RSerPoolENRPServerIdentifierTC MAX-ACCESS read-only STATUS current Dreibholz & Mulik Experimental [Page 27] RFC 5525 RSerPool MIB Module April 2009 DESCRIPTION "The ENRP identifier of this peer." REFERENCE "RFC 5353 explains the usage of the ENRP server identifier." ::= { rserpoolENRPPeerEntry 2 } rserpoolENRPPeerPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The SCTP port number of the ENRP transport endpoint of this peer." REFERENCE "RFC 5353 defines the ENRP protocol." ::= { rserpoolENRPPeerEntry 3 } rserpoolENRPPeerLastHeard OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since the reception of the last ENRP Presence message of this peer." REFERENCE "Section 4.1 of RFC 5353 defines the last heard value." ::= { rserpoolENRPPeerEntry 4 } -- ## Definition of peer address list table ####################### rserpoolENRPPeerAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolENRPPeerAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing of the peer endpoint addresses." ::= { rserpoolENRPServers 9 } rserpoolENRPPeerAddrTableEntry OBJECT-TYPE SYNTAX RserpoolENRPPeerAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing of all IP addresses of the ENRP transport endpoint of a peer referenced by rserpoolENRPPeerIndex." INDEX { rserpoolENRPPeerIndex, rserpoolENRPPeerAddrTableIndex } ::= { rserpoolENRPPeerAddrTable 1 } Dreibholz & Mulik Experimental [Page 28] RFC 5525 RSerPool MIB Module April 2009 RserpoolENRPPeerAddrTableEntry ::= SEQUENCE { rserpoolENRPPeerAddrTableIndex Unsigned32, rserpoolENRPPeerL3Type InetAddressType, rserpoolENRPPeerL3Addr InetAddress } rserpoolENRPPeerAddrTableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for the IP address of a peer ENRP transport endpoint." ::= { rserpoolENRPPeerAddrTableEntry 1 } rserpoolENRPPeerL3Type OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer protocol (IPv4 or IPv6) of an IP address of a peer ENRP transport endpoint." REFERENCE "RFC 5353 defines the ENRP protocol." ::= { rserpoolENRPPeerAddrTableEntry 2 } rserpoolENRPPeerL3Addr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of a peer ENRP transport endpoint. The type of this address is given in rserpoolENRPPeerL3Type." REFERENCE "RFC 5353 defines the ENRP protocol." ::= { rserpoolENRPPeerAddrTableEntry 3 } -- ################################################################ -- #### Pool Elements Section #### -- ################################################################ -- ## Definition of the pool element table ######################## rserpoolPETable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolPEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table listing of pool elements." ::= { rserpoolPoolElements 1 } Dreibholz & Mulik Experimental [Page 29] RFC 5525 RSerPool MIB Module April 2009 rserpoolPEEntry OBJECT-TYPE SYNTAX RserpoolPEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A pool element in the table listing of pool elements." INDEX { rserpoolPEIndex } ::= { rserpoolPETable 1 } RserpoolPEEntry ::= SEQUENCE { rserpoolPEIndex Unsigned32, rserpoolPEOperationScope RSerPoolOperationScopeTC, rserpoolPEPoolHandle RSerPoolPoolHandleTC, rserpoolPEIdentifier RserpoolPoolElementIdentifierTC, rserpoolPEDescription OCTET STRING, rserpoolPEUptime TimeTicks, rserpoolPEASAPTransportPort InetPortNumber, rserpoolPEUserTransportProto Unsigned32, rserpoolPEUserTransportPort InetPortNumber, rserpoolPEUserTransportUse RSerPoolTransportUseTypeTC, rserpoolPEPolicyID RSerPoolPolicyIdentifierTC, rserpoolPEPolicyDescription OCTET STRING, rserpoolPEPolicyWeight RSerPoolPolicyWeightTC, rserpoolPEPolicyLoad RSerPoolPolicyLoadTC, rserpoolPEPolicyLoadDeg RSerPoolPolicyLoadTC, rserpoolPERegistrationLife TimeTicks, rserpoolPEHomeENRPServer RSerPoolENRPServerIdentifierTC } rserpoolPEIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer to uniquely identify a pool element. Note, that uniqueness of a pool element identifier in the pool is not enforced; therefore, this index is required here!" ::={ rserpoolPEEntry 1 } rserpoolPEOperationScope OBJECT-TYPE SYNTAX RSerPoolOperationScopeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The operation scope of this pool element." REFERENCE "Section 1.2 of RFC 3237 defines the term operation scope." ::= { rserpoolPEEntry 2 } Dreibholz & Mulik Experimental [Page 30] RFC 5525 RSerPool MIB Module April 2009 rserpoolPEPoolHandle OBJECT-TYPE SYNTAX RSerPoolPoolHandleTC MAX-ACCESS read-write STATUS current DESCRIPTION "The pool handle of this pool element. Changing this object will update the pool element's pool handle and result in a re-registration. This object SHOULD be maintained in a persistent manner." REFERENCE "Section 1.2 of RFC 3237 defines the term pool handle." ::={ rserpoolPEEntry 3 } rserpoolPEIdentifier OBJECT-TYPE SYNTAX RserpoolPoolElementIdentifierTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool element identifier of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the pool element identifier." ::={ rserpoolPEEntry 4 } rserpoolPEDescription OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "A textual description of this pool element, e.g., its location and a contact address of its administrator. This object SHOULD be maintained in a persistent manner." ::= { rserpoolPEEntry 5 } rserpoolPEUptime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The ENRP service uptime of this pool element." ::= { rserpoolPEEntry 6 } rserpoolPEASAPTransportPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION Dreibholz & Mulik Experimental [Page 31] RFC 5525 RSerPool MIB Module April 2009 "The SCTP port number of the ASAP endpoint of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the port number is given here." ::= { rserpoolPEEntry 7 } rserpoolPEUserTransportProto OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol number of the service endpoint of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the transport protocol number is given here." ::= { rserpoolPEEntry 8 } rserpoolPEUserTransportPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol's port number of the service endpoint of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the port number is given here." ::= { rserpoolPEEntry 9 } rserpoolPEUserTransportUse OBJECT-TYPE SYNTAX RSerPoolTransportUseTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The transport use of the service endpoint of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the transport use is given here." ::= { rserpoolPEEntry 10 } rserpoolPEPolicyID OBJECT-TYPE SYNTAX RSerPoolPolicyIdentifierTC MAX-ACCESS read-write STATUS current DESCRIPTION "The pool policy of this pool element. Changing this object will update the pool element's policy and result in a Dreibholz & Mulik Experimental [Page 32] RFC 5525 RSerPool MIB Module April 2009 re-registration. This object SHOULD be maintained in a persistent manner." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy identifier is given here." ::= { rserpoolPEEntry 11 } rserpoolPEPolicyDescription OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "The textual description of the pool policy of this pool element. This object SHOULD be maintained in a persistent manner." ::= { rserpoolPEEntry 12 } rserpoolPEPolicyWeight OBJECT-TYPE SYNTAX RSerPoolPolicyWeightTC MAX-ACCESS read-write STATUS current DESCRIPTION "The pool policy's weight parameter for this pool element. Changing this object will update the pool element's policy weight setting and result in a re-registration. This object SHOULD be maintained in a persistent manner." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy's weight parameter is given here." ::= { rserpoolPEEntry 13 } rserpoolPEPolicyLoad OBJECT-TYPE SYNTAX RSerPoolPolicyLoadTC MAX-ACCESS read-only STATUS current DESCRIPTION "The pool policy's load status for this pool element." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy's load parameter is given here." ::= { rserpoolPEEntry 14 } Dreibholz & Mulik Experimental [Page 33] RFC 5525 RSerPool MIB Module April 2009 rserpoolPEPolicyLoadDeg OBJECT-TYPE SYNTAX RSerPoolPolicyLoadTC MAX-ACCESS read-write STATUS current DESCRIPTION "The pool policy's load degradation parameter for this pool element. Changing this object will update the pool element's load degradation setting and result in a re-registration. This object SHOULD be maintained in a persistent manner." REFERENCE "Section 3.8 of RFC 5354 defines the Member Selection Policy Parameter of which the policy's load degradation parameter is given here." ::= { rserpoolPEEntry 15 } rserpoolPERegistrationLife OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "The registration life of this pool element. Changing this object will update the pool element's lifetime setting and result in a re-registration. This object SHOULD be maintained in a persistent manner." REFERENCE "Section 3.10 of RFC 5354 defines the Registration Life." ::= { rserpoolPEEntry 16 } rserpoolPEHomeENRPServer OBJECT-TYPE SYNTAX RSerPoolENRPServerIdentifierTC MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the Home ENRP server of this pool element." REFERENCE "Section 3.10 of RFC 5354 defines the Home ENRP Server Identifier." ::= { rserpoolPEEntry 17 } -- ## Definition of the ASAP transport address list table ######### rserpoolPEASAPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolPEASAPAddrTableEntry MAX-ACCESS not-accessible STATUS current Dreibholz & Mulik Experimental [Page 34] RFC 5525 RSerPool MIB Module April 2009 DESCRIPTION "A table listing of all IP addresses of the ASAP transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the addresses are listed in this table." ::= { rserpoolPoolElements 2 } rserpoolPEASAPAddrTableEntry OBJECT-TYPE SYNTAX RserpoolPEASAPAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address of the ASAP transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which an address is contained by this entry." INDEX { rserpoolPEIndex, rserpoolPEASAPAddrTableIndex } ::= { rserpoolPEASAPAddrTable 1 } RserpoolPEASAPAddrTableEntry ::= SEQUENCE { rserpoolPEASAPAddrTableIndex Unsigned32, rserpoolPEASAPL3Type InetAddressType, rserpoolPEASAPL3Addr InetAddress } rserpoolPEASAPAddrTableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for the IP address of an ASAP transport endpoint." ::= { rserpoolPEASAPAddrTableEntry 1 } rserpoolPEASAPL3Type OBJECT-TYPE SYNTAX InetAddressType { ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer protocol (IPv4 or IPv6) of an IP address of an ASAP transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the network-layer protocol number is given here." ::= { rserpoolPEASAPAddrTableEntry 2 } Dreibholz & Mulik Experimental [Page 35] RFC 5525 RSerPool MIB Module April 2009 rserpoolPEASAPL3Addr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of an ASAP transport endpoint. The type of this address is given in rserpoolPEASAPL3Type." REFERENCE "Section 3.10 of RFC 5354 defines the ASAP Transport Parameter of which the network-layer address (IPv4 or IPv6) is given here." ::= { rserpoolPEASAPAddrTableEntry 3 } -- ## Definition of the user transport address list table ######### rserpoolPEUserAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolPEUserAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing of all IP addresses of the user transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the addresses are listed in this table." ::= { rserpoolPoolElements 6 } rserpoolPEUserAddrTableEntry OBJECT-TYPE SYNTAX RserpoolPEUserAddrTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address of the user transport endpoint." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which an address is contained by this entry." INDEX { rserpoolPEIndex, rserpoolPEUserAddrTableIndex } ::= { rserpoolPEUserAddrTable 1 } RserpoolPEUserAddrTableEntry ::= SEQUENCE { rserpoolPEUserAddrTableIndex Unsigned32, rserpoolPEUserL3Type InetAddressType, rserpoolPEUserL3Addr InetAddress, rserpoolPEUserL3Opaque RSerPoolOpaqueAddressTC } rserpoolPEUserAddrTableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible Dreibholz & Mulik Experimental [Page 36] RFC 5525 RSerPool MIB Module April 2009 STATUS current DESCRIPTION "A unique identifier for the IP address of a user transport endpoint." ::= { rserpoolPEUserAddrTableEntry 1 } rserpoolPEUserL3Type OBJECT-TYPE SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The network-layer protocol of an IP address of a user transport endpoint. Set to unknown for opaque address." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the network-layer protocol number is given here." ::= { rserpoolPEUserAddrTableEntry 2 } rserpoolPEUserL3Addr OBJECT-TYPE SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of a user transport endpoint. The type of this address is given in rserpoolPEUserL3Addr." REFERENCE "Section 3.10 of RFC 5354 defines the User Transport Parameter of which the network-layer address (IPv4 or IPv6) is given here." ::= { rserpoolPEUserAddrTableEntry 3 } rserpoolPEUserL3Opaque OBJECT-TYPE SYNTAX RSerPoolOpaqueAddressTC MAX-ACCESS read-only STATUS current DESCRIPTION "The opaque address of a user transport endpoint." REFERENCE "Section 3.16 of RFC 5354 defines the opaque transport address." ::= { rserpoolPEUserAddrTableEntry 4 } -- ################################################################ -- #### Pool Users Section #### -- ################################################################ -- ## Definition of the pool user table ########################### rserpoolPUTable OBJECT-TYPE SYNTAX SEQUENCE OF RserpoolPUEntry MAX-ACCESS not-accessible Dreibholz & Mulik Experimental [Page 37] RFC 5525 RSerPool MIB Module April 2009 STATUS current DESCRIPTION "The table listing of pool users." ::= { rserpoolPoolUsers 1 } rserpoolPUEntry OBJECT-TYPE SYNTAX RserpoolPUEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A pool user in the table listing of pool users." INDEX { rserpoolPUIndex } ::= { rserpoolPUTable 1 } RserpoolPUEntry ::= SEQUENCE { rserpoolPUIndex Unsigned32, rserpoolPUOperationScope RSerPoolOperationScopeTC, rserpoolPUPoolHandle RSerPoolPoolHandleTC, rserpoolPUDescription OCTET STRING, rserpoolPUUptime TimeTicks } rserpoolPUIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer to uniquely identify a pool user." ::= { rserpoolPUEntry 1 } rserpoolPUOperationScope OBJECT-TYPE SYNTAX RSerPoolOperationScopeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The operation scope of this pool user." REFERENCE "Section 1.2 of RFC 3237 defines the term operation scope." ::= { rserpoolPUEntry 2 } rserpoolPUPoolHandle OBJECT-TYPE SYNTAX RSerPoolPoolHandleTC MAX-ACCESS read-write STATUS current Dreibholz & Mulik Experimental [Page 38] RFC 5525 RSerPool MIB Module April 2009 DESCRIPTION "The pool handle of this pool user. Changing this object will update the pool user's pool handle for all future sessions. This object SHOULD be maintained in a persistent manner." REFERENCE "Section 1.2 of RFC 3237 defines the term pool handle." ::={ rserpoolPUEntry 3 } rserpoolPUDescription OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "A textual description of this pool user, e.g., its location and a contact address of its administrator. This object SHOULD be maintained in a persistent manner." ::= { rserpoolPUEntry 4 } rserpoolPUUptime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The ENRP service uptime of this pool user." ::= { rserpoolPUEntry 5 } -- ## MIB conformance and compliance ############################## rserpoolMIBCompliances OBJECT IDENTIFIER ::= { rserpoolMIBConformance 1 } rserpoolMIBGroups OBJECT IDENTIFIER ::= { rserpoolMIBConformance 2 } rserpoolMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement RSerPool." MODULE MANDATORY-GROUPS { rserpoolENRPGroup, rserpoolPEGroup, rserpoolPUGroup } Dreibholz & Mulik Experimental [Page 39] RFC 5525 RSerPool MIB Module April 2009 ::= { rserpoolMIBCompliances 1 } rserpoolENRPGroup OBJECT-GROUP OBJECTS { rserpoolENRPOperationScope, rserpoolENRPIdentifier, rserpoolENRPDescription, rserpoolENRPUptime, rserpoolENRPPort, rserpoolENRPASAPAnnouncePort, rserpoolENRPASAPAnnounceAddr, rserpoolENRPASAPAnnounceAddrType, rserpoolENRPENRPAnnounceAddrType, rserpoolENRPENRPAnnouncePort, rserpoolENRPENRPAnnounceAddr, rserpoolENRPPoolHandle, rserpoolENRPPoolElementID, rserpoolENRPASAPTransportPort, rserpoolENRPUserTransportProto, rserpoolENRPUserTransportUse, rserpoolENRPUserTransportPort, rserpoolENRPPolicyID, rserpoolENRPPolicyDescription, rserpoolENRPPolicyWeight, rserpoolENRPPolicyLoad, rserpoolENRPPolicyLoadDeg, rserpoolENRPRegistrationLife, rserpoolENRPHomeENRPServer, rserpoolENRPASAPL3Type, rserpoolENRPASAPL3Addr, rserpoolENRPUserL3Type, rserpoolENRPUserL3Addr, rserpoolENRPUserL3Opaque, rserpoolENRPENRPL3Type, rserpoolENRPENRPL3Addr, rserpoolENRPPeerIdentifier, rserpoolENRPPeerPort, rserpoolENRPPeerLastHeard, rserpoolENRPPeerL3Type, rserpoolENRPPeerL3Addr } STATUS current DESCRIPTION Dreibholz & Mulik Experimental [Page 40] RFC 5525 RSerPool MIB Module April 2009 "The group contains all ENRP server instances running on the system" ::= { rserpoolMIBGroups 1 } rserpoolPEGroup OBJECT-GROUP OBJECTS { rserpoolPEOperationScope, rserpoolPEPoolHandle, rserpoolPEIdentifier, rserpoolPEDescription, rserpoolPEUptime, rserpoolPEASAPTransportPort, rserpoolPEUserTransportProto, rserpoolPEUserTransportPort, rserpoolPEUserTransportUse, rserpoolPEPolicyID, rserpoolPEPolicyDescription, rserpoolPEPolicyWeight, rserpoolPEPolicyLoad, rserpoolPEPolicyLoadDeg, rserpoolPERegistrationLife, rserpoolPEHomeENRPServer, rserpoolPEASAPL3Type, rserpoolPEASAPL3Addr, rserpoolPEUserL3Type, rserpoolPEUserL3Addr, rserpoolPEUserL3Opaque } STATUS current DESCRIPTION "The group contains all pool element instances running on the system" ::= { rserpoolMIBGroups 2 } rserpoolPUGroup OBJECT-GROUP OBJECTS { rserpoolPUOperationScope, rserpoolPUPoolHandle, rserpoolPUDescription, rserpoolPUUptime } STATUS current DESCRIPTION "The group contains all pool user instances running on the system" ::= { rserpoolMIBGroups 3 } END Dreibholz & Mulik Experimental [Page 41] RFC 5525 RSerPool MIB Module April 2009 7. Operational Considerations The RSerPool MIB is an Experimental track MIB module, since the RSerPool documents are Experimental RFCs. 8. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: rserpoolENRPDescription (textual description change) rserpoolPEPoolHandle (pool handle of pool element change, similar to ASAP) rserpoolPEDescription (textual description change) rserpoolPEPolicyID (pool element ID change, similar to ASAP) rserpoolPEPolicyDescription (textual description change) rserpoolPEPolicyWeight (policy weight change, similar to ASAP) rserpoolPEPolicyLoadDeg (policy load degradation change, similar to ASAP) rserpoolPERegistrationLife (registration lifetime change, similar to ASAP) rserpoolPUPoolHandle (pool handle of accessed pool change, similar to ASAP) rserpoolPUDescription (textual description change) The security implications of changing these items are similar to changes via ASAP; the corresponding security implications are described in the threats document [RFC5355]. Modifying the textual descriptions of components may result in wrong administrator decisions upon malicious information. Dreibholz & Mulik Experimental [Page 42] RFC 5525 RSerPool MIB Module April 2009 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Read access reveals the same information which is also available by ASAP and ENRP access. The security implications of these two protocols are explained in detail by the threats document [RFC5355]. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER Value ---------- ----------------------- rserpoolMIB { experimental 125 } 10. Acknowledgments The authors would like to express a special note of thanks to Phillip Conrad and Kevin Pinzhoffer for their efforts in the early formation of this document. Furthermore, the authors would like to thank Bert Wijnen and Dan Romascanu for their valuable comments on this document. Finally, the authors would like to thank Nihad Cosic, Dirk Hoffstadt, Michael Kohnen, Jobin Pulinthanath, Randall Stewart, Michael Tuexen, and Xing Zhou for their support. Dreibholz & Mulik Experimental [Page 43] RFC 5525 RSerPool MIB Module April 2009 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008. [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008. [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008. [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008. 11.2. Informative References [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002. Dreibholz & Mulik Experimental [Page 44] RFC 5525 RSerPool MIB Module April 2009 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", RFC 5351, September 2008. [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. Holdrege, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, September 2008. [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, Optimization and Extension of a Novel IETF Architecture", Ph.D. Thesis University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, March 2007, . [LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of Reliable Server Pooling Systems", Proceedings of the 30th IEEE Local Computer Networks Conference, November 2005. [IJHIT2008] Dreibholz, T. and E. Rathgeb, "An Evaluation of the Pool Maintenance Overhead in Reliable Server Pooling Systems", International Journal of Hybrid Information Technology (IJHIT) Volume 1, Number 2, April 2008. [RSerPoolPage] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", . [SNMPMIBS] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs", 1997. Dreibholz & Mulik Experimental [Page 45] RFC 5525 RSerPool MIB Module April 2009 Authors' Addresses Thomas Dreibholz University of Duisburg-Essen, Institute for Experimental Mathematics Ellernstrasse 29 45326 Essen, Nordrhein-Westfalen Germany Phone: +49-201-1837637 Fax: +49-201-1837673 EMail: dreibh@iem.uni-due.de URI: http://www.iem.uni-due.de/~dreibh/ Jaiwant Mulik Delaware State University CIS Department Room 306A, Science Center North 1200 N. DuPont Hwy Dover, DE 19904 USA Phone: +1-302-857-7910 Fax: +1-302-857-6552 EMail: jaiwant@mulik.com URI: http://netlab.cis.desu.edu Dreibholz & Mulik Experimental [Page 46] snmp-mibs-downloader-1.1/mibrfcs/rfc5542.txt0000644000000000000000000004675411402176072015602 0ustar Network Working Group T. Nadeau, Ed. Request for Comments: 5542 BT Category: Standards Track D. Zelig, Ed. Oversi O. Nicklass, Ed. RADVISION May 2009 Definitions of Textual Conventions for Pseudowire (PW) Management 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Nadeau, et al. Standards Track [Page 1] RFC 5542 TC for PW Management May 2009 Abstract This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Conventions Used in This Document ...............................2 4. Object Definitions ..............................................3 5. Security Considerations .........................................9 6. IANA Considerations .............................................9 7. References .....................................................10 7.1. Normative References ......................................10 7.2. Informative References ....................................10 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines textual conventions used for pseudowire (PW) technology and for Pseudowire Edge-to-Edge Emulation (PWE3) MIB modules. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Nadeau, et al. Standards Track [Page 2] RFC 5542 TC for PW Management May 2009 4. Object Definitions PW-TC-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] pwTcStdMIB MODULE-IDENTITY LAST-UPDATED "200904210000Z" -- 21 April 2009 00:00:00 GMT ORGANIZATION "Pseudowire Edge-to-Edge Emulation (PWE3) Working Group" CONTACT-INFO " Thomas D. Nadeau Email: tom.nadeau@bt.com David Zelig Email: davidz@oversi.com Orly Nicklass Email: orlyn@radvision.com The PWE3 Working Group (email distribution pwe3@ietf.org, http://www.ietf.org/html.charters/pwe3-charter.html) " DESCRIPTION "This MIB module defines TEXTUAL-CONVENTIONS for concepts used in pseudowire edge-to-edge networks. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Nadeau, et al. Standards Track [Page 3] RFC 5542 TC for PW Management May 2009 - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5542; see the RFC itself for full legal notices." -- Revision history. REVISION "200904210000Z" -- 21 April 2009 00:00:00 GMT DESCRIPTION "Original Version" ::= { mib-2 188 } PwGroupID ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An administrative identification for grouping a set of service-specific pseudowire services." SYNTAX Unsigned32 PwIDType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current Nadeau, et al. Standards Track [Page 4] RFC 5542 TC for PW Management May 2009 DESCRIPTION "Pseudowire Identifier. Used to identify the PW (together with some other fields) in the signaling session." SYNTAX Unsigned32 PwIndexType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Pseudowire Index. A unique value, greater than zero, for each locally defined PW. Used for indexing several MIB tables associated with the particular PW. It is recommended that values are assigned contiguously starting from 1. The value for each PW MUST remain constant at least from one re-initialization to the next re-initialization." SYNTAX Unsigned32 (1..4294967295) PwIndexOrZeroType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This TEXTUAL-CONVENTION is an extension of the PwIndexType convention. The latter defines a greater- than-zero value used to identify a pseudowire in the managed system. This extension permits the additional value of zero. The zero value is object-specific and MUST therefore be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where pseudowire was unknown, or where none or all pseudowires need to be referenced." SYNTAX Unsigned32 (0..4294967295) PwOperStatusTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the operational status of the PW. - up(1): Ready to pass packets. - down(2): PW signaling is not yet finished, or indications available at the service level indicate that the PW is not passing packets. - testing(3): AdminStatus at the PW level is set to test. Nadeau, et al. Standards Track [Page 5] RFC 5542 TC for PW Management May 2009 - dormant(4): The PW is not in a condition to pass packets but is in a 'pending' state, waiting for some external event. - notPresent(5): Some component is missing to accomplish the setup of the PW. It can be configuration error, incomplete configuration, or a missing H/W component. - lowerLayerDown(6): One or more of the lower-layer interfaces responsible for running the underlying PSN is not in OperStatus 'up' state." SYNTAX INTEGER { up(1), down(2), testing(3), dormant(4), notPresent(5), lowerLayerDown(6) } PwAttachmentIdentifierType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An octet string used in the generalized Forward Error Correction (FEC) element for identifying attachment forwarder and groups. A NULL identifier is of zero length. " SYNTAX OCTET STRING (SIZE (0..255)) PwGenIdType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the Attachment Group Identifier (AGI) Type and Attachment Individual Identifier (AII) Type in generalized FEC signaling and configuration. " SYNTAX Unsigned32( 0..254 ) PwCwStatusTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the status of the control word (CW) negotiation based on the local configuration and the indications received from the peer node. waitingForNextMsg(1) indicates that the node is waiting for another label mapping from the peer. Nadeau, et al. Standards Track [Page 6] RFC 5542 TC for PW Management May 2009 sentWrongBitErrorCode(2) indicates that the local node has notified the peer about a mismatch in the C-bit. rxWithdrawWithWrongBitErrorCode(3) indicates that a withdraw message has been received with the wrong C-bit error code. illegalReceivedBit(4) indicates a C-bit configuration with the peer that is not compatible with the PW type. cwPresent(5) indicates that the CW is present for this PW. If signaling is used, the C-bit is set and agreed upon between the nodes. For manually configured PW, the local configuration requires the use of the CW. cwNotPresent(6) indicates that the CW is not present for this PW. If signaling is used, the C-bit is reset and agreed upon between the nodes. For manually configured PW, the local configuration requires that the CW not be used. notYetKnown(7) indicates that a label mapping has not yet been received from the peer. " REFERENCE "Martini, et al., 'Pseudowire Setup and Maintenance Using the Label Distribution Protocol', [RFC4447]." SYNTAX INTEGER { waitingForNextMsg(1), sentWrongBitErrorCode(2), rxWithdrawWithWrongBitErrorCode(3), illegalReceivedBit(4), cwPresent(5), cwNotPresent(6), notYetKnown(7) } PwStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the status of the PW and the interfaces affecting this PW. If none of the bits are set, it indicates no faults are reported. " Nadeau, et al. Standards Track [Page 7] RFC 5542 TC for PW Management May 2009 SYNTAX BITS { pwNotForwarding(0), servicePwRxFault(1), servicePwTxFault(2), psnPwRxFault(3), psnPwTxFault(4) } PwFragSize ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "If set to a value other than zero, it indicates the desired fragmentation length in bytes. If set to zero, fragmentation is not desired for PSN bound packets. " SYNTAX Unsigned32 PwFragStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the status of the fragmentation/reassembly process based on local configuration and peer capability. noFrag(0) bit indicates that local configuration is for no fragmentation. cfgFragGreaterThanPsnMtu(1) bit indicates that the local node is set to fragment, but the fragmentation size is greater than the MTU available at the PSN between the nodes. Fragmentation is not done in this case. cfgFragButRemoteIncapable(2) bit indicates that the local configuration conveys the desire for fragmentation but the peer is not capable of reassembly. remoteFragCapable(3) bit indicates that the remote node is capable to accept fragmented PDUs. fragEnabled(4) bit indicates that fragmentation will be used on this PW. Fragmentation can be used if the local node was configured for fragmentation, the peer has the capability to accept fragmented packets, and the CW is in use for this PW." REFERENCE "Malis, A. and M. Townsley, 'Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly', [RFC4623]." Nadeau, et al. Standards Track [Page 8] RFC 5542 TC for PW Management May 2009 SYNTAX BITS { noFrag(0), cfgFragGreaterThanPsnMtu(1), cfgFragButRemoteIncapable(2), remoteFragCapable(3), fragEnabled(4) } PwCfgIndexOrzero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Index in any of the relevant configuration tables for supplement information regarding configuration of the specific technology. Value zero implies no additional configuration information is applicable." SYNTAX Unsigned32 (0..4294967295) END 5. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions that may be used by other PWE3 MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet. 6. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pwTcStdMIB { mib-2 188 } Nadeau, et al. Standards Track [Page 9] RFC 5542 TC for PW Management May 2009 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006. 7.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Nadeau, et al. Standards Track [Page 10] RFC 5542 TC for PW Management May 2009 Authors' Addresses Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom EMail: tom.nadeau@bt.com David Zelig (editor) Oversi Networks 1 Rishon Letzion St. Petah Tikva Israel Phone: +972 77 3337 750 EMail: davidz@oversi.com Orly Nicklass (editor) RADVISION 24 Raul Wallenberg Tel Aviv Phone: +972 3 776 9444 EMail: orlyn@radvision.com Nadeau, et al. Standards Track [Page 11] snmp-mibs-downloader-1.1/mibrfcs/rfc5591.txt0000644000000000000000000017046311402176072015601 0ustar Network Working Group D. Harrington Request for Comments: 5591 Huawei Technologies (USA) Category: Standards Track W. Hardaker Cobham Analytic Solutions June 2009 Transport Security Model for the Simple Network Management Protocol (SNMP) 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Harrington & Hardaker Standards Track [Page 1] RFC 5591 Transport Security Model for SNMP June 2009 Abstract This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP). This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. Table of Contents 1. Introduction ....................................................3 1.1. The Internet-Standard Management Framework .................3 1.2. Conventions ................................................3 1.3. Modularity .................................................4 1.4. Motivation .................................................5 1.5. Constraints ................................................5 2. How the Transport Security Model Fits in the Architecture .......6 2.1. Security Capabilities of this Model ........................6 2.1.1. Threats .............................................6 2.1.2. Security Levels .....................................7 2.2. Transport Sessions .........................................7 2.3. Coexistence ................................................7 2.3.1. Coexistence with Message Processing Models ..........7 2.3.2. Coexistence with Other Security Models ..............8 2.3.3. Coexistence with Transport Models ...................8 3. Cached Information and References ...............................8 3.1. Transport Security Model Cached Information ................9 3.1.1. securityStateReference ..............................9 3.1.2. tmStateReference ....................................9 3.1.3. Prefixes and securityNames ..........................9 4. Processing an Outgoing Message .................................10 4.1. Security Processing for an Outgoing Message ...............10 4.2. Elements of Procedure for Outgoing Messages ...............11 5. Processing an Incoming SNMP Message ............................12 5.1. Security Processing for an Incoming Message ...............12 5.2. Elements of Procedure for Incoming Messages ...............13 6. MIB Module Overview ............................................14 6.1. Structure of the MIB Module ...............................14 6.1.1. The snmpTsmStats Subtree ...........................14 6.1.2. The snmpTsmConfiguration Subtree ...................14 6.2. Relationship to Other MIB Modules .........................14 6.2.1. MIB Modules Required for IMPORTS ...................15 7. MIB Module Definition ..........................................15 8. Security Considerations ........................................20 8.1. MIB Module Security .......................................20 9. IANA Considerations ............................................21 10. Acknowledgments ...............................................22 Harrington & Hardaker Standards Track [Page 2] RFC 5591 Transport Security Model for SNMP June 2009 11. References ....................................................22 11.1. Normative References .....................................22 11.2. Informative References ...................................23 Appendix A. Notification Tables Configuration ....................24 A.1. Transport Security Model Processing for Notifications .....25 Appendix B. Processing Differences between USM and Secure Transport ............................................26 B.1. USM and the RFC 3411 Architecture .........................26 B.2. Transport Subsystem and the RFC 3411 Architecture .........27 1. Introduction This memo describes a Transport Security Model for the Simple Network Management Protocol for use with secure Transport Models in the Transport Subsystem [RFC5590]. This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Transport Security Model described in this memo fits into the architecture and interacts with other subsystems and models within the architecture. It is expected that readers will have also read and understood [RFC3411], [RFC3412], [RFC3413], and [RFC3418]. 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Harrington & Hardaker Standards Track [Page 3] RFC 5591 Transport Security Model for SNMP June 2009 Lowercase versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context that relates to compatibility with the RFC 3411 architecture or the subsystem defined here but that might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage. For consistency with SNMP-related specifications, this document favors terminology as defined in STD 62, rather than favoring terminology that is consistent with non-SNMP specifications that use different variations of the same terminology. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard. Authentication in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication. The terms "manager" and "agent" are not used in this document because, in the RFC 3411 architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP applications included in the engine. Where distinction is needed, the application names of command generator, command responder, notification originator, notification receiver, and proxy forwarder are used. See "Simple Network Management Protocol (SNMP) Applications" [RFC3413] for further information. While security protocols frequently refer to a user, the terminology used in [RFC3411] and in this memo is "principal". A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role, a set of individuals each acting in a particular role, an application or a set of applications, or a combination of these within an administrative domain. 1.3. Modularity The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411], and the architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590], which enables the use of external "lower-layer transport" protocols to provide message Harrington & Hardaker Standards Track [Page 4] RFC 5591 Transport Security Model for SNMP June 2009 security. Transport Models are tied into the SNMP architecture through the Transport Subsystem. The Transport Security Model is designed to work with such lower-layer, secure Transport Models. In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects that are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD NOT be referenced in other documents. This allows the Transport Security Model to be designed and documented as independent and self-contained, having no direct impact on other modules. It also allows this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation. 1.4. Motivation This memo describes a Security Model to make use of Transport Models that use lower-layer, secure transports and existing and commonly deployed security infrastructures. This Security Model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success, and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible. 1.5. Constraints The design of this SNMP Security Model is also influenced by the following constraints: 1. In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend solely upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols). 2. When the network is not under stress, the Security Model and its underlying security mechanisms MAY depend upon the ready availability of other network services. 3. It might not be possible for the Security Model to determine when the network is under stress. 4. A Security Model SHOULD NOT require changes to the SNMP architecture. Harrington & Hardaker Standards Track [Page 5] RFC 5591 Transport Security Model for SNMP June 2009 5. A Security Model SHOULD NOT require changes to the underlying security protocol. 2. How the Transport Security Model Fits in the Architecture The Transport Security Model is designed to fit into the RFC 3411 architecture as a Security Model in the Security Subsystem and to utilize the services of a secure Transport Model. For incoming messages, a secure Transport Model will pass a tmStateReference cache, described in [RFC5590]. To maintain RFC 3411 modularity, the Transport Model will not know which securityModel will process the incoming message; the Message Processing Model will determine this. If the Transport Security Model is used with a non- secure Transport Model, then the cache will not exist or will not be populated with security parameters, which will cause the Transport Security Model to return an error (see Section 5.2). The Transport Security Model will create the securityName and securityLevel to be passed to applications, and will verify that the tmTransportSecurityLevel reported by the Transport Model is at least as strong as the securityLevel requested by the Message Processing Model. For outgoing messages, the Transport Security Model will create a tmStateReference cache (or use an existing one), and will pass the tmStateReference to the specified Transport Model. 2.1. Security Capabilities of this Model 2.1.1. Threats The Transport Security Model is compatible with the RFC 3411 architecture and provides protection against the threats identified by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself. Which threats are addressed and how they are mitigated depends on the Transport Model used. To avoid creating potential security vulnerabilities, operators should configure their system so this Security Model is always used with a Transport Model that provides appropriate security, where "appropriate" for a particular deployment is an administrative decision. Harrington & Hardaker Standards Track [Page 6] RFC 5591 Transport Security Model for SNMP June 2009 2.1.2. Security Levels The RFC 3411 architecture recognizes three levels of security: - without authentication and without privacy (noAuthNoPriv) - with authentication but without privacy (authNoPriv) - with authentication and with privacy (authPriv) The model-independent securityLevel parameter is used to request specific levels of security for outgoing messages and to assert that specific levels of security were applied during the transport and processing of incoming messages. The transport-layer algorithms used to provide security should not be exposed to the Transport Security Model, as the Transport Security Model has no mechanisms by which it can test whether an assertion made by a Transport Model is accurate. The Transport Security Model trusts that the underlying secure transport connection has been properly configured to support security characteristics at least as strong as reported in tmTransportSecurityLevel. 2.2. Transport Sessions The Transport Security Model does not work with transport sessions directly. Instead the transport-related state is associated with a unique combination of transportDomain, transportAddress, securityName, and securityLevel, and is referenced via the tmStateReference parameter. How and if this is mapped to a particular transport or channel is the responsibility of the Transport Subsystem. 2.3. Coexistence In the RFC 3411 architecture, a Message Processing Model determines which Security Model SHALL be called. As of this writing, IANA has registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, SNMPv2c, and the User-based Security Model). 2.3.1. Coexistence with Message Processing Models The SNMPv1 and SNMPv2c message processing described in BCP 74 [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security Models. Since there is no mechanism defined in RFC 3584 to select an Harrington & Hardaker Standards Track [Page 7] RFC 5591 Transport Security Model for SNMP June 2009 alternative Security Model, SNMPv1 and SNMPv2c messages cannot use the Transport Security Model. Messages might still be able to be conveyed over a secure transport protocol, but the Transport Security Model will not be invoked. The SNMPv2u/SNMPv2* Message Processing Model is an historic artifact for which there is no existing IETF specification. The SNMPv3 message processing defined in [RFC3412] extracts the securityModel from the msgSecurityModel field of an incoming SNMPv3Message. When this value is transportSecurityModel(4), security processing is directed to the Transport Security Model. For an outgoing message to be secured using the Transport Security Model, the application MUST specify a securityModel parameter value of transportSecurityModel(4) in the sendPdu Abstract Service Interface (ASI). 2.3.2. Coexistence with Other Security Models The Transport Security Model uses its own MIB module for processing to maintain independence from other Security Models. This allows the Transport Security Model to coexist with other Security Models, such as the User-based Security Model (USM) [RFC3414]. 2.3.3. Coexistence with Transport Models The Transport Security Model (TSM) MAY work with multiple Transport Models, but the RFC 3411 Abstract Service Interfaces (ASIs) do not carry a value for the Transport Model. The MIB module defined in this memo allows an administrator to configure whether or not TSM prepends a Transport Model prefix to the securityName. This will allow SNMP applications to consider Transport Model as a factor when making decisions, such as access control, notification generation, and proxy forwarding. To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [RFC5592]. 3. Cached Information and References When performing SNMP processing, there are two levels of state information that might need to be retained: the immediate state linking a request-response pair and a potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590] defines general requirements for caches and references. Harrington & Hardaker Standards Track [Page 8] RFC 5591 Transport Security Model for SNMP June 2009 This document defines additional cache requirements related to the Transport Security Model. 3.1. Transport Security Model Cached Information The Transport Security Model has specific responsibilities regarding the cached information. 3.1.1. securityStateReference The Transport Security Model adds the tmStateReference received from the processIncomingMsg ASI to the securityStateReference. This tmStateReference can then be retrieved during the generateResponseMsg ASI so that it can be passed back to the Transport Model. 3.1.2. tmStateReference For outgoing messages, the Transport Security Model uses parameters provided by the SNMP application to look up or create a tmStateReference. For the Transport Security Model, the security parameters used for a response MUST be the same as those used for the corresponding request. This Security Model uses the tmStateReference stored as part of the securityStateReference when appropriate. For responses and reports, this Security Model sets the tmSameSecurity flag to true in the tmStateReference before passing it to a Transport Model. For incoming messages, the Transport Security Model uses parameters provided in the tmStateReference cache to establish a securityName, and to verify adequate security levels. 3.1.3. Prefixes and securityNames The SNMP-VIEW-BASED-ACM-MIB module [RFC3415], the SNMP-TARGET-MIB module [RFC3413], and other MIB modules contain objects to configure security parameters for use by applications such as access control, notification generation, and proxy forwarding. Transport domains and their corresponding prefixes are coordinated via the IANA registry "SNMP Transport Domains". If snmpTsmConfigurationUsePrefix is set to true, then all securityNames provided by, or provided to, the Transport Security Model MUST include a valid transport domain prefix. Harrington & Hardaker Standards Track [Page 9] RFC 5591 Transport Security Model for SNMP June 2009 If snmpTsmConfigurationUsePrefix is set to false, then all securityNames provided by, or provided to, the Transport Security Model MUST NOT include a transport domain prefix. The tmSecurityName in the tmStateReference stored as part of the securityStateReference does not contain a prefix. 4. Processing an Outgoing Message An error indication might return an Object Identifier (OID) and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, if this information is available at the point where the error is detected. 4.1. Security Processing for an Outgoing Message This section describes the procedure followed by the Transport Security Model. The parameters needed for generating a message are supplied to the Security Model by the Message Processing Model via the generateRequestMsg() or the generateResponseMsg() ASI. The Transport Subsystem architectural extension has added the transportDomain, transportAddress, and tmStateReference parameters to the original RFC 3411 ASIs. statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- (NEW) transport info ) statusInformation = -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version Harrington & Hardaker Standards Track [Page 10] RFC 5591 Transport Security Model for SNMP June 2009 IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state -- information from original -- request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- (NEW) transport info ) 4.2. Elements of Procedure for Outgoing Messages 1. If there is a securityStateReference (Response or Report message), then this Security Model uses the cached information rather than the information provided by the ASI. Extract the tmStateReference from the securityStateReference cache. Set the tmRequestedSecurityLevel to the value of the extracted tmTransportSecurityLevel. Set the tmSameSecurity parameter in the tmStateReference cache to true. The cachedSecurityData for this message can now be discarded. 2. If there is no securityStateReference (e.g., a Request-type or Notification message), then create a tmStateReference cache. Set tmTransportDomain to the value of transportDomain, tmTransportAddress to the value of transportAddress, and tmRequestedSecurityLevel to the value of securityLevel. (Implementers might optimize by pointing to saved copies of these session-specific values.) Set the transaction-specific tmSameSecurity parameter to false. If the snmpTsmConfigurationUsePrefix object is set to false, then set tmSecurityName to the value of securityName. If the snmpTsmConfigurationUsePrefix object is set to true, then use the transportDomain to look up the corresponding prefix. (Since the securityStateReference stores the tmStateReference with the tmSecurityName for the incoming message, and since tmSecurityName never has a prefix, the prefix-stripping step only occurs when we are not using the securityStateReference). Harrington & Hardaker Standards Track [Page 11] RFC 5591 Transport Security Model for SNMP June 2009 If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops. If the lookup succeeds, but there is no prefix in the securityName, or the prefix returned does not match the prefix in the securityName, or the length of the prefix is less than 1 or greater than 4 US-ASCII alpha-numeric characters, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops. Strip the transport-specific prefix and trailing ':' character (US-ASCII 0x3a) from the securityName. Set tmSecurityName to the value of securityName. 3. Set securityParameters to a zero-length OCTET STRING ('0400'). 4. Combine the message parts into a wholeMsg and calculate wholeMsgLength. 5. The wholeMsg, wholeMsgLength, securityParameters, and tmStateReference are returned to the calling Message Processing Model with the statusInformation set to success. 5. Processing an Incoming SNMP Message An error indication might return an OID and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, if this information is available at the point where the error is detected. 5.1. Security Processing for an Incoming Message This section describes the procedure followed by the Transport Security Model whenever it receives an incoming message from a Message Processing Model. The ASI from a Message Processing Model to the Security Subsystem for a received message is: statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- from the received message IN securityParameters -- from the received message IN securityModel -- from the received message IN securityLevel -- from the received message Harrington & Hardaker Standards Track [Page 12] RFC 5591 Transport Security Model for SNMP June 2009 IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire IN tmStateReference -- (NEW) from the Transport Model OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response 5.2. Elements of Procedure for Incoming Messages 1. Set the securityEngineID to the local snmpEngineID. 2. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, and tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is incremented, an error indication is returned to the calling module, and Security Model processing stops for this message. 3. Copy the tmSecurityName to securityName. If the snmpTsmConfigurationUsePrefix object is set to true, then use the tmTransportDomain to look up the corresponding prefix. If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops. If the lookup succeeds but the prefix length is less than 1 or greater than 4 octets, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops. Set the securityName to be the concatenation of the prefix, a ':' character (US-ASCII 0x3a), and the tmSecurityName. 4. Compare the value of tmTransportSecurityLevel in the tmStateReference cache to the value of the securityLevel parameter passed in the processIncomingMsg ASI. If securityLevel specifies privacy (Priv) and tmTransportSecurityLevel specifies no privacy (noPriv), or if securityLevel specifies authentication (auth) and tmTransportSecurityLevel specifies no authentication (noAuth) was provided by the Transport Model, then the snmpTsmInadequateSecurityLevels counter is incremented, an error indication (unsupportedSecurityLevel) together with the OID and Harrington & Hardaker Standards Track [Page 13] RFC 5591 Transport Security Model for SNMP June 2009 value of the incremented counter is returned to the calling module, and Transport Security Model processing stops for this message. 5. The tmStateReference is cached as cachedSecurityData so that a possible response to this message will use the same security parameters. Then securityStateReference is set for subsequent references to this cached data. 6. The scopedPDU component is extracted from the wholeMsg. 7. The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message. 8. The statusInformation is set to success and a return is made to the calling module passing back the OUT parameters as specified in the processIncomingMsg ASI. 6. MIB Module Overview This MIB module provides objects for use only by the Transport Security Model. It defines a configuration scalar and related error counters. 6.1. Structure of the MIB Module Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below. 6.1.1. The snmpTsmStats Subtree This subtree contains error counters specific to the Transport Security Model. 6.1.2. The snmpTsmConfiguration Subtree This subtree contains a configuration object that enables administrators to specify if they want a transport domain prefix prepended to securityNames for use by applications. 6.2. Relationship to Other MIB Modules Some management objects defined in other MIB modules are applicable to an entity implementing the Transport Security Model. In particular, it is assumed that an entity implementing the Transport Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the Harrington & Hardaker Standards Track [Page 14] RFC 5591 Transport Security Model for SNMP June 2009 SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and the SNMPv2-MIB [RFC3418]. These are not needed to implement the SNMP-TSM-MIB. 6.2.1. MIB Modules Required for IMPORTS The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580]. 7. MIB Module Definition SNMP-TSM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Counter32 FROM SNMPv2-SMI -- RFC2578 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 TruthValue FROM SNMPv2-TC -- RFC2579 ; snmpTsmMIB MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de Harrington & Hardaker Standards Track [Page 15] RFC 5591 Transport Security Model for SNMP June 2009 Editor: David Harrington Huawei Technologies USA 1700 Alma Dr. Plano TX 75075 USA +1 603-436-8634 ietfdbh@comcast.net Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 USA +1 530 792 1913 ietf@hardakers.net " DESCRIPTION "The Transport Security Model MIB. In keeping with the RFC 3411 design decisions to use self-contained documents, the RFC that contains the definition of this MIB module also includes the elements of procedure that are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD NOT be modified via other subsystems or models defined in other documents. This allows the Transport Security Model for SNMP to be designed and documented as independent and self-contained, having no direct impact on other modules, and this allows this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Harrington & Hardaker Standards Track [Page 16] RFC 5591 Transport Security Model for SNMP June 2009 - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5591; see the RFC itself for full legal notices." REVISION "200906090000Z" DESCRIPTION "The initial version, published in RFC 5591." ::= { mib-2 190 } -- ---------------------------------------------------------- -- -- subtrees in the SNMP-TSM-MIB -- ---------------------------------------------------------- -- snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 } snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 } snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- -- Statistics for the Transport Security Model snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 } snmpTsmInvalidCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the Harrington & Hardaker Standards Track [Page 17] RFC 5591 Transport Security Model for SNMP June 2009 tmStateReference referred to an invalid cache. " ::= { snmpTsmStats 1 } snmpTsmInadequateSecurityLevels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the securityLevel asserted by the Transport Model was less than the securityLevel requested by the application. " ::= { snmpTsmStats 2 } snmpTsmUnknownPrefixes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages dropped because snmpTsmConfigurationUsePrefix was set to true and there is no known prefix for the specified transport domain. " ::= { snmpTsmStats 3 } snmpTsmInvalidPrefixes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages dropped because the securityName associated with an outgoing message did not contain a valid transport domain prefix. " ::= { snmpTsmStats 4 } -- ------------------------------------------------------------- -- Configuration -- ------------------------------------------------------------- -- Configuration for the Transport Security Model snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 } snmpTsmConfigurationUsePrefix OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current Harrington & Hardaker Standards Track [Page 18] RFC 5591 Transport Security Model for SNMP June 2009 DESCRIPTION "If this object is set to true, then securityNames passing to and from the application are expected to contain a transport-domain-specific prefix. If this object is set to true, then a domain-specific prefix will be added by the TSM to the securityName for incoming messages and removed from the securityName when processing outgoing messages. Transport domains and prefixes are maintained in a registry by IANA. This object SHOULD persist across system reboots. " DEFVAL { false } ::= { snmpTsmConfiguration 1 } -- ------------------------------------------------------------- -- snmpTsmMIB - Conformance Information -- ------------------------------------------------------------- snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 } snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 } -- ------------------------------------------------------------- -- Compliance statements -- ------------------------------------------------------------- snmpTsmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines that support the SNMP-TSM-MIB. " MODULE MANDATORY-GROUPS { snmpTsmGroup } ::= { snmpTsmCompliances 1 } -- ------------------------------------------------------------- -- Units of conformance -- ------------------------------------------------------------- snmpTsmGroup OBJECT-GROUP OBJECTS { snmpTsmInvalidCaches, snmpTsmInadequateSecurityLevels, snmpTsmUnknownPrefixes, snmpTsmInvalidPrefixes, snmpTsmConfigurationUsePrefix } STATUS current DESCRIPTION "A collection of objects for maintaining information of an SNMP engine that implements Harrington & Hardaker Standards Track [Page 19] RFC 5591 Transport Security Model for SNMP June 2009 the SNMP Transport Security Model. " ::= { snmpTsmGroups 2 } END 8. Security Considerations This document describes a Security Model, compatible with the RFC 3411 architecture, that permits SNMP to utilize security services provided through an SNMP Transport Model. The Transport Security Model relies on Transport Models for mutual authentication, binding of keys, confidentiality, and integrity. The Transport Security Model relies on secure Transport Models to provide an authenticated principal identifier and an assertion of whether authentication and privacy are used during transport. This Security Model SHOULD always be used with Transport Models that provide adequate security, but "adequate security" is a configuration and/or run-time decision of the operator or management application. The security threats and how these threats are mitigated should be covered in detail in the specifications of the Transport Models and the underlying secure transports. An authenticated principal identifier (securityName) is used in SNMP applications for purposes such as access control, notification generation, and proxy forwarding. This Security Model supports multiple Transport Models. Operators might judge some transports to be more secure than others, so this Security Model can be configured to prepend a prefix to the securityName to indicate the Transport Model used to authenticate the principal. Operators can use the prefixed securityName when making application decisions about levels of access. 8.1. MIB Module Security There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Harrington & Hardaker Standards Track [Page 20] RFC 5591 Transport Security Model for SNMP June 2009 o The snmpTsmConfigurationUsePrefix object could be modified, creating a denial of service or authorizing SNMP messages that would not have previously been authorized by an Access Control Model (e.g., the View-based Access Control Model (VACM)). Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o All the counters in this module refer to configuration errors and do not expose sensitive information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations IANA has assigned: 1. An SMI number (190) with a prefix of mib-2 in the MIB module registry for the MIB module in this document. 2. A value (4) to identify the Transport Security Model, in the Security Models registry of the SNMP Number Spaces registry. This results in the following table of values: Harrington & Hardaker Standards Track [Page 21] RFC 5591 Transport Security Model for SNMP June 2009 Value Description References ----- ----------- ---------- 0 reserved for 'any' [RFC3411] 1 reserved for SNMPv1 [RFC3411] 2 reserved for SNMPv2c [RFC3411] 3 User-Based Security Model (USM) [RFC3411] 4 Transport Security Model (TSM) [RFC5591] 10. Acknowledgments The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity. Additionally, helpful document reviews were received from Juergen Schoenwaelder. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. Harrington & Hardaker Standards Track [Page 22] RFC 5591 Transport Security Model for SNMP June 2009 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. 11.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009. Harrington & Hardaker Standards Track [Page 23] RFC 5591 Transport Security Model for SNMP June 2009 Appendix A. Notification Tables Configuration The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to configure notification originators with the destinations to which notifications should be sent. Most of the configuration is Security-Model-independent and Transport-Model-independent. The values we will use in the examples for the five model-independent security and transport parameters are: transportDomain = snmpSSHDomain transportAddress = 192.0.2.1:5162 securityModel = Transport Security Model securityName = alice securityLevel = authPriv The following example will configure the notification originator to send informs to a notification receiver at 192.0.2.1:5162 using the securityName "alice". "alice" is the name for the recipient from the standpoint of the notification originator and is used for processing access controls before sending a notification. The columns marked with an "*" are the items that are Security-Model- specific or Transport-Model-specific. The configuration for the "alice" settings in the SNMP-VIEW-BASED- ACM-MIB objects are not shown here for brevity. First, we configure which type of notification will be sent for this taglist (toCRTag). In this example, we choose to send an Inform. snmpNotifyTable row: snmpNotifyName CRNotif snmpNotifyTag toCRTag snmpNotifyType inform snmpNotifyStorageType nonVolatile snmpNotifyColumnStatus createAndGo Then we configure a transport address to which notifications associated with this taglist will be sent, and we specify which snmpTargetParamsEntry will be used (toCR) when sending to this transport address. Harrington & Hardaker Standards Track [Page 24] RFC 5591 Transport Security Model for SNMP June 2009 snmpTargetAddrTable row: snmpTargetAddrName toCRAddr * snmpTargetAddrTDomain snmpSSHDomain * snmpTargetAddrTAddress 192.0.2.1:5162 snmpTargetAddrTimeout 1500 snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (MUST match below) snmpTargetAddrStorageType nonVolatile snmpTargetAddrColumnStatus createAndGo Then we configure which principal at the host will receive the notifications associated with this taglist. Here, we choose "alice", who uses the Transport Security Model. snmpTargetParamsTable row: snmpTargetParamsName toCR snmpTargetParamsMPModel SNMPv3 * snmpTargetParamsSecurityModel TransportSecurityModel snmpTargetParamsSecurityName "alice" snmpTargetParamsSecurityLevel authPriv snmpTargetParamsStorageType nonVolatile snmpTargetParamsRowStatus createAndGo A.1. Transport Security Model Processing for Notifications The Transport Security Model is called using the generateRequestMsg() ASI, with the following parameters (those with an * are from the above tables): statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- *snmpTargetParamsMPModel IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- *snmpTargetAddrTDomain IN transportAddress -- *snmpTargetAddrTAddress IN securityModel -- *snmpTargetParamsSecurityModel IN securityEngineID -- immaterial; TSM will ignore. IN securityName -- snmpTargetParamsSecurityName IN securityLevel -- *snmpTargetParamsSecurityLevel IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- reference to transport info ) Harrington & Hardaker Standards Track [Page 25] RFC 5591 Transport Security Model for SNMP June 2009 The Transport Security Model will determine the Transport Model based on the snmpTargetAddrTDomain. The selected Transport Model will select the appropriate transport connection using the tmStateReference cache created from the values of snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel. Appendix B. Processing Differences between USM and Secure Transport USM and secure transports differ in the processing order and responsibilities within the RFC 3411 architecture. While the steps are the same, they occur in a different order and might be done by different subsystems. The following lists illustrate the difference in the flow and the responsibility for different processing steps for incoming messages when using USM and when using a secure transport. (These lists are simplified for illustrative purposes, and do not represent all details of processing. Transport Models MUST provide the detailed elements of procedure.) With USM, SNMPv1, and SNMPv2c Security Models, security processing starts when the Message Processing Model decodes portions of the ASN.1 message to extract header fields that are used to determine which Security Model will process the message to perform authentication, decryption, timeliness checking, integrity checking, and translation of parameters to model-independent parameters. By comparison, a secure transport performs those security functions on the message, before the ASN.1 is decoded. Step 6 cannot occur until after decryption occurs. Steps 6 and beyond are the same for USM and a secure transport. B.1. USM and the RFC 3411 Architecture 1) Decode the ASN.1 header (Message Processing Model). 2) Determine the SNMP Security Model and parameters (Message Processing Model). 3) Verify securityLevel (Security Model). 4) Translate parameters to model-independent parameters (Security Model). 5) Authenticate the principal, check message integrity and timeliness, and decrypt the message (Security Model). Harrington & Hardaker Standards Track [Page 26] RFC 5591 Transport Security Model for SNMP June 2009 6) Determine the pduType in the decrypted portions (Message Processing Model). 7) Pass on the decrypted portions with model-independent parameters. B.2. Transport Subsystem and the RFC 3411 Architecture 1) Authenticate the principal, check integrity and timeliness of the message, and decrypt the message (Transport Model). 2) Translate parameters to model-independent parameters (Transport Model). 3) Decode the ASN.1 header (Message Processing Model). 4) Determine the SNMP Security Model and parameters (Message Processing Model). 5) Verify securityLevel (Security Model). 6) Determine the pduType in the decrypted portions (Message Processing Model). 7) Pass on the decrypted portions with model-independent security parameters. If a message is secured using a secure transport layer, then the Transport Model will provide the translation from the authenticated identity (e.g., an SSH user name) to a human-friendly identifier (tmSecurityName) in step 2. The Security Model will provide a mapping from that identifier to a model-independent securityName. Harrington & Hardaker Standards Track [Page 27] RFC 5591 Transport Security Model for SNMP June 2009 Authors' Addresses David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: ietfdbh@comcast.net Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US Phone: +1 530 792 1913 EMail: ietf@hardakers.net Harrington & Hardaker Standards Track [Page 28] snmp-mibs-downloader-1.1/mibrfcs/rfc5592.txt0000644000000000000000000024160611402176072015600 0ustar Network Working Group D. Harrington Request for Comments: 5592 Huawei Technologies (USA) Category: Standards Track J. Salowey Cisco Systems W. Hardaker Cobham Analytic Solutions June 2009 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Harrington, et al. Standards Track [Page 1] RFC 5592 Secure Shell Transport Model for SNMP June 2009 Abstract This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. Table of Contents 1. Introduction ....................................................3 1.1. The Internet-Standard Management Framework .................3 1.2. Conventions ................................................3 1.3. Modularity .................................................5 1.4. Motivation .................................................5 1.5. Constraints ................................................6 2. The Secure Shell Protocol .......................................7 3. How SSHTM Fits into the Transport Subsystem .....................8 3.1. Security Capabilities of this Model ........................8 3.1.1. Threats .............................................8 3.1.2. Message Authentication ..............................9 3.1.3. Authentication Protocol Support ....................10 3.1.4. SSH Subsystem ......................................11 3.2. Security Parameter Passing ................................12 3.3. Notifications and Proxy ...................................12 4. Cached Information and References ..............................13 4.1. Secure Shell Transport Model Cached Information ...........13 4.1.1. tmSecurityName .....................................13 4.1.2. tmSessionID ........................................14 4.1.3. Session State ......................................14 5. Elements of Procedure ..........................................14 5.1. Procedures for an Incoming Message ........................15 5.2. Procedures for Sending an Outgoing Message ................17 5.3. Establishing a Session ....................................18 5.4. Closing a Session .........................................20 6. MIB Module Overview ............................................21 6.1. Structure of the MIB Module ...............................21 6.2. Textual Conventions .......................................21 6.3. Relationship to Other MIB Modules .........................21 6.3.1. MIB Modules Required for IMPORTS ...................21 7. MIB Module Definition ..........................................22 8. Operational Considerations .....................................29 9. Security Considerations ........................................30 9.1. Skipping Public Key Verification ..........................31 9.2. Notification Authorization Considerations .................31 9.3. SSH User and Key Selection ................................31 Harrington, et al. Standards Track [Page 2] RFC 5592 Secure Shell Transport Model for SNMP June 2009 9.4. Conceptual Differences between USM and SSHTM ..............31 9.5. The 'none' MAC Algorithm ..................................32 9.6. Use with SNMPv1/v2c Messages ..............................32 9.7. MIB Module Security .......................................32 10. IANA Considerations ...........................................33 11. Acknowledgments ...............................................33 12. References ....................................................34 12.1. Normative References .....................................34 12.2. Informative References ...................................35 1. Introduction This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell (SSH) protocol [RFC4251] within a Transport Subsystem [RFC5590]. The Transport Model specified in this memo is referred to as the Secure Shell Transport Model (SSHTM). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. It is important to understand the SNMP architecture [RFC3411] and the terminology of the architecture to understand where the Transport Model described in this memo fits into the architecture and interacts with other subsystems within the architecture. 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Harrington, et al. Standards Track [Page 3] RFC 5592 Secure Shell Transport Model for SNMP June 2009 Lowercase versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context that relates to compatibility with the RFC 3411 architecture or the subsystem defined here but that might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage. For consistency with SNMP-related specifications, this document favors terminology as defined in STD 62, rather than favoring terminology that is consistent with non-SNMP specifications. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard. "Authentication" in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication. The terms "manager" and "agent" are not used in this document because, in the RFC 3411 architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP application types supported in the implementation. Where distinction is required, the application names of command generator, command responder, notification originator, notification receiver, and proxy forwarder are used. See "SNMP Applications" [RFC3413] for further information. The User-based Security Model (USM) [RFC3414] is a mandatory-to- implement Security Model in STD 62. While the SSH and USM specifications frequently refer to a user, the terminology preferred in [RFC3411] and in this memo is "principal". A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role, a set of individuals each acting in a particular role, an application or a set of applications, or a combination of these within an administrative domain. Throughout this document, the terms "client" and "server" are used to refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming SSH connection. Either SNMP entity may act as client or as server, as discussed further below. Harrington, et al. Standards Track [Page 4] RFC 5592 Secure Shell Transport Model for SNMP June 2009 1.3. Modularity The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411], and the Transport Subsystem architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590]. This memo describes the Secure Shell Transport Model for SNMP, a specific SNMP Transport Model to be used within the SNMP Transport Subsystem to provide authentication, encryption, and integrity checking of SNMP messages. In keeping with the RFC 3411 design decision to use self-contained documents, this document defines the elements of procedure and associated MIB module objects that are needed for processing the Secure Shell Transport Model for SNMP. This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation. 1.4. Motivation Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the protocol. The User-based Security Model (USM) [RFC3414] was designed to be independent of other existing security infrastructures to ensure it could function when third-party authentication services were not available, such as in a broken network. As a result, USM utilizes a separate user and key- management infrastructure. Operators have reported that having to deploy another user and key-management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3. This memo describes a Transport Model that will make use of the existing and commonly deployed Secure Shell security infrastructure. This Transport Model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success, and at the same time minimize implementation and deployment costs to minimize deployment time. This document addresses the requirement for the SSH client to authenticate the SSH server and for the SSH server to authenticate the SSH client, and describes how SNMP can make use of the authenticated identities in authorization policies for data access, in a manner that is independent of any specific Access Control Model. Harrington, et al. Standards Track [Page 5] RFC 5592 Secure Shell Transport Model for SNMP June 2009 This document addresses the requirement to utilize client- authentication and key-exchange methods that support different security infrastructures and provide different security properties. This document describes how to use client authentication as described in "The Secure Shell (SSH) Authentication Protocol" [RFC4252]. The SSH Transport Model should work with any of the ssh-userauth methods, including the "publickey", "password", "hostbased", "none", "keyboard-interactive", "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx" (see the SSH Protocol Parameters registry maintained by IANA). The use of the "none" authentication method is NOT RECOMMENDED, as described in this document's Security Considerations. Local accounts may be supported through the use of the publickey, hostbased, or password methods. The password method allows for integration with a deployed password infrastructure, such as Authentication, Authorization, and Accounting (AAA) servers using the RADIUS protocol [RFC2865]. The SSH Transport Model SHOULD be able to take advantage of future-defined ssh-userauth methods, such as those that might make use of X.509 certificate credentials. It is desirable to use mechanisms that could unify the approach for administrative security for SNMPv3 and command line interfaces (CLI) and other management interfaces. The use of security services provided by Secure Shell is the approach commonly used for the CLI and is the approach being adopted for use with NETCONF [RFC4742]. This memo describes a method for invoking and running the SNMP protocol within a Secure Shell (SSH) session as an SSH Subsystem. This memo describes how SNMP can be used within a Secure Shell (SSH) session, using the SSH connection protocol [RFC4254] over the SSH transport protocol, and using ssh-userauth [RFC4252] for authentication. There are a number of challenges to be addressed to map Secure Shell authentication method parameters into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below. 1.5. Constraints The design of this SNMP Transport Model is influenced by the following constraints: 1. In times of network stress, the transport protocol and its underlying security mechanisms SHOULD NOT depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or AAA protocols). Harrington, et al. Standards Track [Page 6] RFC 5592 Secure Shell Transport Model for SNMP June 2009 2. When the network is not under stress, the Transport Model and its underlying security mechanisms MAY depend upon the ready availability of other network services. 3. It may not be possible for the Transport Model to determine when the network is under stress. 4. A Transport Model SHOULD NOT require changes to the SNMP architecture. 5. A Transport Model SHOULD NOT require changes to the underlying security protocol. 2. The Secure Shell Protocol SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major protocol components and add-on methods for user authentication: o The Transport Layer Protocol [RFC4253] provides server authentication and message confidentiality and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection but might also be used on top of any other reliable data stream. o The User Authentication Protocol [RFC4252] authenticates the client-side principal to the server. It runs over the Transport Layer Protocol. o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel into several logical channels. It runs over the transport after successfully authenticating the principal. o Generic Message Exchange Authentication [RFC4256] is a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. o "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol" [RFC4462] describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user- authentication method that uses a specified GSS-API mechanism to authenticate a user; it also defines a family of SSH key-exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange. Harrington, et al. Standards Track [Page 7] RFC 5592 Secure Shell Transport Model for SNMP June 2009 The client sends a service request once a secure, transport-layer connection has been established. A second service request is sent after client authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above. The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections. 3. How SSHTM Fits into the Transport Subsystem A Transport Model is a component of the Transport Subsystem [RFC5590] within the SNMP architecture. The SSH Transport Model thus fits between the underlying SSH transport layer and the Message Dispatcher [RFC3411]. The SSH Transport Model will establish a channel between itself and the SSH Transport Model of another SNMP engine. The sending Transport Model passes unencrypted messages from the Dispatcher to SSH to be encrypted, and the receiving Transport Model accepts decrypted incoming messages from SSH and passes them to the Dispatcher. After an SSH Transport Model channel is established, then SNMP messages can conceptually be sent through the channel from one SNMP Message Dispatcher to another SNMP Message Dispatcher. Multiple SNMP messages MAY be passed through the same channel. The SSH Transport Model of an SNMP engine will perform the translation between SSH-specific security parameters and SNMP- specific, model-independent parameters. 3.1. Security Capabilities of this Model 3.1.1. Threats The Secure Shell Transport Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411]: 1. Modification of Information - SSH provides for verification that the contents of each message have not been modified during its transmission through the network by digitally signing each SSH packet. 2. Masquerade - SSH provides for verification of the identity of the SSH server and the identity of the SSH client. Harrington, et al. Standards Track [Page 8] RFC 5592 Secure Shell Transport Model for SNMP June 2009 SSH provides for verification of the identity of the SSH server through the SSH transport protocol server authentication [RFC4253]. This allows an operator or management station to ensure the authenticity of the SNMP engine that provides MIB data. SSH provides a number of mechanisms for verification of the identity of the SSH client-side principal using the Secure Shell Authentication Protocol [RFC4252]. These include public key, password, and host-based mechanisms. This allows the SNMP Access Control Subsystem to ensure that only authorized principals have access to potentially sensitive data. Verification of the client's principal identity is important for use with the SNMP Access Control Subsystem to ensure that only authorized principals have access to potentially sensitive data. The SSH user identity is provided to the Transport Model, so it can be used to map to an SNMP model-independent securityName for use with SNMP access control and notification configuration. (The identity may undergo various transforms before it maps to the securityName.) 3. Message Stream Modification - SSH protects against malicious re- ordering or replaying of messages within a single SSH session by using sequence numbers and integrity checks. SSH protects against replay of messages across SSH sessions by ensuring that the cryptographic keys used for encryption and integrity checks are generated afresh for each session. 4. Disclosure - SSH provides protection against the disclosure of information to unauthorized recipients or eavesdroppers by allowing for encryption of all traffic between SNMP engines. 3.1.2. Message Authentication The RFC 3411 architecture recognizes three levels of security: - without authentication and without privacy (noAuthNoPriv) - with authentication but without privacy (authNoPriv) - with authentication and with privacy (authPriv) The Secure Shell protocol provides support for encryption and data integrity. While it is technically possible to support no authentication and no encryption in SSH, it is NOT RECOMMENDED by [RFC4253]. Harrington, et al. Standards Track [Page 9] RFC 5592 Secure Shell Transport Model for SNMP June 2009 The SSH Transport Model determines from SSH the identity of the authenticated principal and the type and address associated with an incoming message, and provides this information to SSH for an outgoing message. The SSH transport-layer algorithms used to provide authentication, data integrity, and encryption SHOULD NOT be exposed to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided this and settled for an assertion by the Security Model that the requirements of securityLevel were met. The SSH Transport Model has no mechanisms by which it can test whether an underlying SSH connection provides auth or priv, so the SSH Transport Model trusts that the underlying SSH connection has been properly configured to support authPriv security characteristics. An SSH Transport-Model-compliant implementation MUST use an SSH connection that provides authentication, data integrity, and encryption that meets the highest level of SNMP security (authPriv). Outgoing messages specified with a securityLevel of noAuthNoPriv or authNoPriv are actually sent by the SSH Transport Model with authPriv-level protection. The security protocols used in the Secure Shell Authentication Protocol [RFC4252] and the Secure Shell Transport Layer Protocol [RFC4253] are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises. 3.1.3. Authentication Protocol Support The SSH Transport Model should support any server- or client- authentication mechanism supported by SSH. This includes the three authentication methods described in the SSH Authentication Protocol document [RFC4252] (publickey, password, and host-based), keyboard interactive, and others. The password-authentication mechanism allows for integration with deployed password-based infrastructure. It is possible to hand a password to a service such as RADIUS [RFC2865] or Diameter [RFC3588] for validation. The validation could be done using the user name and user password attributes. It is also possible to use a different password-validation protocol such as the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or digest authentication [RFC5090] to integrate with RADIUS or Diameter. At some point in the processing, these mechanisms require the password to be made available as cleartext on the device that is authenticating the password, which might introduce threats to the authentication infrastructure. Harrington, et al. Standards Track [Page 10] RFC 5592 Secure Shell Transport Model for SNMP June 2009 GSS-API key exchange [RFC4462] provides a framework for the addition of client-authentication mechanisms that support different security infrastructures and provide different security properties. Additional authentication mechanisms, such as one that supports X.509 certificates, may be added to SSH in the future. 3.1.4. SSH Subsystem This document describes the use of an SSH Subsystem for SNMP to make SNMP usage distinct from other usages. An SSH Subsystem of type "snmp" is opened by the SSH Transport Model during the elements of procedure for an outgoing SNMP message. Since the sender of a message initiates the creation of an SSH session if needed, the SSH session will already exist for an incoming message; otherwise, the incoming message would never reach the SSH Transport Model. Implementations may choose to instantiate SSH sessions in anticipation of outgoing messages. This approach might be useful to ensure that an SSH session to a given target can be established before it becomes important to send a message over the SSH session. Of course, there is no guarantee that a pre-established session will still be valid when needed. SSH sessions are uniquely identified within the SSH Transport Model by the combination of tmTransportAddress and tmSecurityName associated with each session. Because naming policies might differ between administrative domains, many SSH client software packages support a user@hostname:port addressing syntax that operators can use to align non-equivalent account names. The SnmpSSHAddress Textual Convention echos this common SSH notation. When this notation is used in an SnmpSSHAddress, the SSH connection should be established with an SSH user name matching the "user" portion of the notation when establishing a session with the remote SSH server. The user name must be encoded in UTF-8 (per [RFC4252]). The "user" portion may or may not match the tmSecurityName parameter passed from the Security Model. If no "user@" portion is specified in the SnmpSSHAddress, then the SSH connection should be established using the tmSecurityName as the SSH user name when establishing a session with the remote SSH server. Harrington, et al. Standards Track [Page 11] RFC 5592 Secure Shell Transport Model for SNMP June 2009 The SnmpSSHAddress and tmSecurityName associated with an SSH session MUST remain constant during the life of the session. Different SnmpSSHAddress values (with different hostnames, "user@" prefix names, and/or port numbers) will each result in individual SSH sessions. 3.2. Security Parameter Passing For incoming messages, SSH-specific security parameters are translated by the Transport Model into security parameters independent of the Transport and Security Models. The Transport Model accepts messages from the SSH Subsystem, records the transport- related and SSH-security-related information, including the authenticated identity, in a cache referenced by tmStateReference, and passes the WholeMsg and the tmStateReference to the Dispatcher using the receiveMessage() ASI (Abstract Service Interface). For outgoing messages, the Transport Model takes input provided by the Dispatcher in the sendMessage() ASI. The SSH Transport Model converts that information into suitable security parameters for SSH, establishes sessions as needed, and passes messages to the SSH Subsystem for sending. 3.3. Notifications and Proxy SSH connections may be initiated by command generators or by notification originators. Command generators are frequently operated by a human, but notification originators are usually unmanned automated processes. As a result, it may be necessary to provision authentication credentials on the SNMP engine containing the notification originator or to use a third-party key provider, such as Kerberos, so the engine can successfully authenticate to an engine containing a notification receiver. The targets to whom notifications or proxy requests should be sent is typically determined and configured by a network administrator. The SNMP-NOTIFICATION-MIB contains a list of targets to which notifications should be sent. The SNMP-TARGET-MIB module [RFC3413] contains objects for defining these management targets, including transport domains and addresses and security parameters, for applications such as notification generators and proxy forwarders. For the SSH Transport Model, transport type and address are configured in the snmpTargetAddrTable, and the securityName and securityLevel parameters are configured in the snmpTargetParamsTable. The default approach is for an administrator to statically preconfigure this information to identify the targets authorized to receive notifications or received proxied messages. Local access- Harrington, et al. Standards Track [Page 12] RFC 5592 Secure Shell Transport Model for SNMP June 2009 control processing needs to be performed by a notification originator before notifications are actually sent, and this processing is done using the configured securityName. An important characteristic of this is that authorization is done prior to determining if the connection can succeed. Thus, the locally configured securityName is entirely trusted within the notification originator. The SNMP-TARGET-MIB and NOTIFICATION-MIB MIB modules may be configured using SNMP or other implementation-dependent mechanisms, such as CLI scripting or loading a configuration file. It may be necessary to provide additional implementation-specific configuration of SSH parameters. 4. Cached Information and References When performing SNMP processing, there are two levels of state information that may need to be retained: the immediate state linking a request-response pair and a potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol" [RFC5590] defines general requirements for caches and references. This document defines additional cache requirements related to the Secure Shell Transport Model. 4.1. Secure Shell Transport Model Cached Information The Secure Shell Transport Model has specific responsibilities regarding the cached information. See the Elements of Procedure in Section 5 for detailed processing instructions on the use of the tmStateReference fields by the SSH Transport Model. 4.1.1. tmSecurityName The tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been set according to the procedures in Section 5. The tmSecurityName MUST be constant for all traffic passing through an SSHTM session. Messages MUST NOT be sent through an existing SSH session that was established using a different tmSecurityName. On the SSH server side of a connection: The tmSecurityName should be the SSH user name. How the SSH user name is extracted from the SSH layer is implementation-dependent. Harrington, et al. Standards Track [Page 13] RFC 5592 Secure Shell Transport Model for SNMP June 2009 The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform an SSH identity to a tmSecurityName or to transform a tmSecurityName to an SSH identity. In other cases, the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange. On the SSH client side of a connection: The tmSecurityName is presented to the SSH Transport Model by the application (possibly because of configuration specified in the SNMP-TARGET-MIB). The securityName MAY be derived from the tmSecurityName by a Security Model and MAY be used to configure notifications and access controls in MIB modules. Transport Models SHOULD generate a predictable tmSecurityName so operators will know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames. 4.1.2. tmSessionID The tmSessionID MUST be recorded per message at the time of receipt. When tmSameSecurity is set, the recorded tmSessionID can be used to determine whether the SSH session available for sending a corresponding outgoing message is the same SSH session as was used when receiving the incoming message (e.g., a response to a request). 4.1.3. Session State The per-session state that is referenced by tmStateReference may be saved across multiple messages in a Local Configuration Datastore. Additional session/connection state information might also be stored in a Local Configuration Datastore. 5. Elements of Procedure Abstract Service Interfaces have been defined by [RFC3411] and further augmented by [RFC5590] to describe the conceptual data flows between the various subsystems within an SNMP entity. The Secure Shell Transport Model uses some of these conceptual data flows when communicating between subsystems. Harrington, et al. Standards Track [Page 14] RFC 5592 Secure Shell Transport Model for SNMP June 2009 To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message gets discarded, the message-state information should also be released, and if state information is available when a session is closed, the session-state information should also be released. An error indication in statusInformation will typically include the Object Identifier (OID) and value for an incremented error counter. This may be accompanied by the requested securityLevel and the tmStateReference. Per-message context information is not accessible to Transport Models, so for the returned counter OID and value, contextEngine would be set to the local value of snmpEngineID and contextName to the default context for error counters. 5.1. Procedures for an Incoming Message 1. The SSH Transport Model queries the SSH engine, in an implementation-dependent manner, to determine the address the message originated from, the user name authenticated by SSH, and a session identifier. 2. Determine the tmTransportAddress to be associated with the incoming message: A. If this is a client-side SSH session, then the tmTransportAddress is set to the tmTransportAddress used to establish the session. It MUST exactly include any "user@" prefix associated with the address provided to the openSession() ASI. B. If this is a server-side SSH session and this is the first message received over the session, then the tmTransportAddress is set to the address the message originated from, determined in an implementation-dependent way. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmTransportAddress being set to the same value. C. If this is a server-side SSH session and this is not the first message received over the session, then the tmTransportAddress is set to the previously established tmTransportAddress for the session (the value from step B, determined from a previous incoming message). Harrington, et al. Standards Track [Page 15] RFC 5592 Secure Shell Transport Model for SNMP June 2009 3. Determine the tmSecurityName to be associated with the incoming message: A. If this is a client-side SSH session, then the tmSecurityName MUST be set to the tmSecurityName used to establish the session. B. If this is a server-side SSH session and this is the first message received over the session, then the tmSecurityName is set to the SSH user name. How the SSH user name is extracted from the SSH layer is implementation-dependent. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmSecurityName being set to the same value. C. If this is a server-side SSH session and this is not the first message received over the session, then the tmSecurityName is set to the previously established tmSecurityName for the session (the value from step B, determined from a previous incoming message). 4. Create a tmStateReference cache for subsequent reference to the information. tmTransportDomain = snmpSSHDomain tmTransportAddress = the derived tmTransportAddress from step 2. tmSecurityName = the derived tmSecurityName from step 3. tmTransportSecurityLevel = "authPriv" (authentication and confidentiality MUST be used to comply with this Transport Model.) tmSessionID = an implementation-dependent value that can be used to detect when a session has closed and been replaced by another session. The value in tmStateReference MUST uniquely identify the session over which the message was received. This session identifier MUST NOT be reused until there are no references to it remaining. Then the Transport Model passes the message to the Dispatcher using the following ASI: Harrington, et al. Standards Track [Page 16] RFC 5592 Secure Shell Transport Model for SNMP June 2009 statusInformation = receiveMessage( IN transportDomain -- snmpSSHDomain IN transportAddress -- the tmTransportAddress for the message IN wholeMessage -- the whole SNMP message from SSH IN wholeMessageLength -- the length of the SNMP message IN tmStateReference -- (NEW) transport info ) 5.2. Procedures for Sending an Outgoing Message The Dispatcher passes the information to the Transport Model using the ASI defined in the Transport Subsystem: statusInformation = sendMessage( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN outgoingMessage -- the message to send IN outgoingMessageLength -- its length IN tmStateReference -- (NEW) transport info ) The SSH Transport Model performs the following tasks. 1. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity, then increment the snmpSshtmSessionInvalidCaches counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops. 2. Extract the tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and tmSessionID from the tmStateReference. 3. Identify an SSH session over which to send the messages: A. If tmSameSecurity is true and there is no existing session with a matching tmSessionID, tmSecurityName, and tmTransportAddress, then increment the snmpSshtmSessionNoSessions counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops. B. If there is a session with a matching tmSessionID, tmTransportAddress, and tmSecurityName, then select that session. Harrington, et al. Standards Track [Page 17] RFC 5592 Secure Shell Transport Model for SNMP June 2009 C. If there is a session that matches the tmTransportAddress and tmSecurityName, then select that session. D. If the above steps failed to select a session to use, then call openSession() with the tmStateReference as a parameter. + If openSession fails, then discard the message, release tmStateReference, and pass the error indication returned by openSession back to the calling module. Processing of this message stops. + If openSession succeeds, then record the destTransportDomain, destTransportAddress, tmSecurityname, and tmSessionID in an implementation-dependent manner. This will be needed when processing an incoming message. 4. Pass the wholeMessage to SSH for encapsulation as data in an SSH message over the identified SSH session. Any necessary additional SSH-specific parameters should be provided in an implementation-dependent manner. 5.3. Establishing a Session The Secure Shell Transport Model provides the following Abstract Service Interface (ASI) to describe the data passed between the SSH Transport Model and the SSH service. It is an implementation decision how such data is passed. statusInformation = openSession( IN tmStateReference -- transport information to be used OUT tmStateReference -- transport information to be used IN maxMessageSize -- of the sending SNMP entity ) The following describes the procedure to follow to establish a session between a client and server to run SNMP over SSH. This process is used by any SNMP engine establishing a session for subsequent use. This will be done automatically for an SNMP application that initiates a transaction, such as a command generator, a notification originator, or a proxy forwarder. Harrington, et al. Standards Track [Page 18] RFC 5592 Secure Shell Transport Model for SNMP June 2009 1. Increment the snmpSshtmSessionOpens counter. 2. Using tmTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server, and exchange keys for message integrity and encryption. The transportAddress associated with a session MUST remain constant during the lifetime of the SSH session. Implementations may need to cache the transportAddress passed to the openSession API for later use when performing incoming message processing (see Section 5.1). 1. To authenticate the server, the client usually stores pairs (tmTransportAddress, server host public key) in an implementation-dependent manner. 2. The other parameters of the transport connection are provided in an implementation-dependent manner. 3. If the attempt to establish a connection is unsuccessful or if server-authentication fails, then snmpSshtmSessionOpenErrors is incremented, an openSession error indication is returned, and openSession processing stops. 3. The client will then invoke an SSH authentication service to authenticate the principal, such as that described in the SSH authentication protocol [RFC4252]. 1. If the tmTransportAddress field contains a user name followed by an '@' character (US-ASCII 0x40), that user name string should be presented to the SSH server as the "user name" for user-authentication purposes. If there is no user name in the tmTransportAddress, then the tmSecurityName should be used as the user name. 2. The credentials used to authenticate the SSH principal are determined in an implementation-dependent manner. 3. In an implementation-specific manner, invoke the SSH user- authentication service using the calculated user name. 4. If the user authentication is unsuccessful, then the transport connection is closed, the snmpSshtmSessionUserAuthFailures counter is incremented, an error indication is returned to the calling module, and processing stops for this message. Harrington, et al. Standards Track [Page 19] RFC 5592 Secure Shell Transport Model for SNMP June 2009 4. The client should invoke the "ssh-connection" service (also known as the SSH connection protocol [RFC4254]), and request a channel of type "session". If unsuccessful, the transport connection is closed, the snmpSshtmSessionNoChannels counter is incremented, an error indication is returned to the calling module, and processing stops for this message. 5. The client invokes "snmp" as an SSH Subsystem, as indicated in the "subsystem" parameter. If unsuccessful, the transport connection is closed, the snmpSshtmSessionNoSubsystems counter is incremented, an error indication is returned to the calling module, and processing stops for this message. In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Transport Model MUST default to providing access to the "snmp" SSH Subsystem if the SSH session is established using the IANA- assigned TCP ports (5161 and 5162). Servers SHOULD be configurable to allow access to the SNMP SSH Subsystem over other ports. 6. Set tmSessionID in the tmStateReference cache to an implementation-dependent value to identify the session. 7. The tmSecurityName used to establish the SSH session must be the only tmSecurityName used with the session. Incoming messages for the session MUST be associated with this tmSecurityName value. How this is accomplished is implementation-dependent. 5.4. Closing a Session The Secure Shell Transport Model provides the following ASI to close a session: statusInformation = closeSession( IN tmSessionID -- session ID of session to be closed ) The following describes the procedure to follow to close a session between a client and server. This process is followed by any SNMP engine to close an SSH session. It is implementation-dependent when a session should be closed. The calling code should release the associated tmStateReference. Harrington, et al. Standards Track [Page 20] RFC 5592 Secure Shell Transport Model for SNMP June 2009 1. Increment the snmpSshtmSessionCloses counter. 2. If there is no session corresponding to tmSessionID, then closeSession processing is complete. 3. Have SSH close the session associated with tmSessionID. 6. MIB Module Overview This MIB module provides management of the Secure Shell Transport Model. It defines an OID to identify the SNMP-over-SSH transport domain, a Textual Convention for SSH Addresses, and several statistics counters. 6.1. Structure of the MIB Module Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below. 6.2. Textual Conventions Generic and Common Textual Conventions used in this document can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html 6.3. Relationship to Other MIB Modules Some management objects defined in other MIB modules are applicable to an entity implementing the SSH Transport Model. In particular, it is assumed that an entity implementing the SNMP-SSH-TM-MIB will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK-MIB [RFC3411]. It is expected that an entity implementing this MIB will also support the Transport Security Model [RFC5591] and, therefore, implement the SNMP-TSM-MIB. This MIB module is for monitoring SSH Transport Model information. 6.3.1. MIB Modules Required for IMPORTS The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580]. This MIB module also references [RFC1033], [RFC4252], [RFC3490], and [RFC3986]. Harrington, et al. Standards Track [Page 21] RFC 5592 Secure Shell Transport Model for SNMP June 2009 This document uses TDomain Textual Conventions for the SNMP-internal MIB modules defined here for compatibility with the RFC 3413 MIB modules and the RFC 3411 Abstract Service Interfaces. 7. MIB Module Definition SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, snmpDomains, Counter32 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 ; snmpSshtmMIB MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de Co-editors: David Harrington Huawei Technologies USA 1700 Alma Drive Plano Texas 75075 Harrington, et al. Standards Track [Page 22] RFC 5592 Secure Shell Transport Model for SNMP June 2009 USA +1 603-436-8634 ietfdbh@comcast.net Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 USA +1 530 792 1913 ietf@hardakers.net " DESCRIPTION "The Secure Shell Transport Model MIB. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, Harrington, et al. Standards Track [Page 23] RFC 5592 Secure Shell Transport Model for SNMP June 2009 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5592; see the RFC itself for full legal notices." REVISION "200906090000Z" DESCRIPTION "The initial version, published in RFC 5592." ::= { mib-2 189 } -- ---------------------------------------------------------- -- -- subtrees in the SNMP-SSH-TM-MIB -- ---------------------------------------------------------- -- snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 } snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 } snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 } -- ------------------------------------------------------------- -- Objects -- ------------------------------------------------------------- snmpSSHDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP-over-SSH transport domain. The corresponding transport address is of type SnmpSSHAddress. When an SNMP entity uses the snmpSSHDomain Transport Model, it must be capable of accepting messages up to and including 8192 octets in size. Implementation of larger values is encouraged whenever possible. The securityName prefix to be associated with the snmpSSHDomain is 'ssh'. This prefix may be used by Security Models or other components to identify which secure transport infrastructure authenticated a securityName." ::= { snmpDomains 7 } SnmpSSHAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current Harrington, et al. Standards Track [Page 24] RFC 5592 Secure Shell Transport Model for SNMP June 2009 DESCRIPTION "Represents either a hostname or IP address, along with a port number and an optional user name. The beginning of the address specification may contain a user name followed by an '@' (US-ASCII character 0x40). This portion of the address will indicate the user name that should be used when authenticating to an SSH server. The user name must be encoded in UTF-8 (per [RFC4252]). If missing, the SNMP securityName should be used. After the optional user name field and '@' character comes the hostname or IP address. The hostname is always in US-ASCII (as per RFC1033); internationalized hostnames are encoded in US-ASCII as specified in RFC 3490. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible. An IPv4 address must be in dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. An IPv6 address must be in colon-separated format, surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. Values of this Textual Convention might not be directly usable as transport-layer addressing information and may require runtime resolution. As such, applications that write them must be prepared for handling errors if such values are not supported or cannot be resolved (if resolution occurs at the time of the management operation). The DESCRIPTION clause of TransportAddress objects that may have snmpSSHAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa. This Textual Convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair. Harrington, et al. Standards Track [Page 25] RFC 5592 Secure Shell Transport Model for SNMP June 2009 When this Textual Convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers, which is specified in SMIv2 (STD 58). It is RECOMMENDED that all MIB documents using this Textual Convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation. " REFERENCE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE RFC 3490: Internationalizing Domain Names in Applications RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 4252: The Secure Shell (SSH) Authentication Protocol" SYNTAX OCTET STRING (SIZE (1..255)) -- The snmpSshtmSession Group snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 } snmpSshtmSessionOpens OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an openSession() request has been executed as an SSH client, whether it succeeded or failed. " ::= { snmpSshtmSession 1 } snmpSshtmSessionCloses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a closeSession() request has been executed as an SSH client, whether it succeeded or failed. " ::= { snmpSshtmSession 2 } snmpSshtmSessionOpenErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Harrington, et al. Standards Track [Page 26] RFC 5592 Secure Shell Transport Model for SNMP June 2009 DESCRIPTION "The number of times an openSession() request failed to open a transport connection or failed to authenticate the server. " ::= { snmpSshtmSession 3 } snmpSshtmSessionUserAuthFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an openSession() request failed to open a session as an SSH client due to user-authentication failures. " ::= { snmpSshtmSession 4 } snmpSshtmSessionNoChannels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an openSession() request failed to open a session as an SSH client due to channel-open failures. " ::= { snmpSshtmSession 5 } snmpSshtmSessionNoSubsystems OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an openSession() request failed to open a session as an SSH client due to inability to connect to the requested subsystem. " ::= { snmpSshtmSession 6 } snmpSshtmSessionNoSessions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an outgoing message was dropped because the same session was no longer available. " ::= { snmpSshtmSession 7 } snmpSshtmSessionInvalidCaches OBJECT-TYPE SYNTAX Counter32 Harrington, et al. Standards Track [Page 27] RFC 5592 Secure Shell Transport Model for SNMP June 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outgoing messages dropped because the tmStateReference referred to an invalid cache. " ::= { snmpSshtmSession 8 } -- ************************************************ -- snmpSshtmMIB - Conformance Information -- ************************************************ snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 } snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 } -- ************************************************ -- Compliance statements -- ************************************************ snmpSshtmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines that support the SNMP-SSH-TM-MIB." MODULE MANDATORY-GROUPS { snmpSshtmGroup } ::= { snmpSshtmCompliances 1 } -- ************************************************ -- Units of conformance -- ************************************************ snmpSshtmGroup OBJECT-GROUP OBJECTS { snmpSshtmSessionOpens, snmpSshtmSessionCloses, snmpSshtmSessionOpenErrors, snmpSshtmSessionUserAuthFailures, snmpSshtmSessionNoChannels, snmpSshtmSessionNoSubsystems, snmpSshtmSessionNoSessions, snmpSshtmSessionInvalidCaches } STATUS current DESCRIPTION "A collection of objects for maintaining information of an SNMP engine that implements the SNMP Secure Shell Transport Model. " Harrington, et al. Standards Track [Page 28] RFC 5592 Secure Shell Transport Model for SNMP June 2009 ::= { snmpSshtmGroups 2 } END 8. Operational Considerations The SSH Transport Model will likely not work in conditions where remote access to the CLI has stopped working. The SSH Transport Model assumes that TCP and IP continue to operate correctly between the communicating nodes. Failures in either node, death of the deamon serving the communication, routing problems in the network between, firewalls that block the traffic, and other problems can prevent the SSH Transport Model from working. In situations where management access has to be very reliable, operators should consider mitigating measures. These measures may include dedicated management-only networks, point-to-point links, and the ability to use alternate protocols and transports. To have SNMP properly utilize the security services provided by SSH, the SSH Transport Model MUST be used with a Security Model that knows how to process a tmStateReference, such as the Transport Security Model for SNMP [RFC5591]. If the SSH Transport Model is configured to utilize AAA services, operators should consider configuring support for local authentication mechanisms, such as local passwords, so SNMP can continue operating during times of network stress. The SSH protocol has its own window mechanism, defined in RFC 4254. The SSH specifications leave it open when window adjustment messages should be created, and some implementations send these whenever received data has been passed to the application. There are noticeable bandwidth and processing overheads to handling such window adjustment messages, which can be avoided by sending them less frequently. The SSH protocol requires the execution of CPU-intensive calculations to establish a session key during session establishment. This means that short-lived sessions become computationally expensive compared to USM, which does not have a notion of a session key. Other transport security protocols such as TLS support a session-resumption feature that allows reusing a cached session key. Such a mechanism does not exist for SSH and thus SNMP applications should keep SSH sessions for longer time periods. To initiate SSH connections, an entity must be configured with SSH client credentials plus information to authenticate the server. While hosts are often configured to be SSH clients, most Harrington, et al. Standards Track [Page 29] RFC 5592 Secure Shell Transport Model for SNMP June 2009 internetworking devices are not. To send notifications over SSHTM, the internetworking device will need to be configured as an SSH client. How this credential configuration is done is implementation- and deployment-specific. 9. Security Considerations This memo describes a Transport Model that permits SNMP to utilize SSH security services. The security threats and how the SSH Transport Model mitigates those threats is covered in detail throughout this memo. The SSH Transport Model relies on SSH mutual authentication, binding of keys, confidentiality, and integrity. Any authentication method that meets the requirements of the SSH architecture will provide the properties of mutual authentication and binding of keys. SSHv2 provides perfect forward secrecy (PFS) for encryption keys. PFS is a major design goal of SSH, and any well-designed key-exchange algorithm will provide it. The security implications of using SSH are covered in [RFC4251]. The SSH Transport Model has no way to verify that server authentication was performed, to learn the host's public key in advance, or to verify that the correct key is being used. The SSH Transport Model simply trusts that these are properly configured by the implementer and deployer. SSH provides the "none" userauth method. The SSH Transport Model MUST NOT be used with an SSH connection with the "none" userauth method. While SSH does support turning off confidentiality and integrity, they MUST NOT be turned off when used with the SSH Transport Model. The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform an SSH identity to a tmSecurityName or to transform a tmSecurityName to an SSH identity. In other cases, the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange. Harrington, et al. Standards Track [Page 30] RFC 5592 Secure Shell Transport Model for SNMP June 2009 9.1. Skipping Public Key Verification Most key-exchange algorithms are able to authenticate the SSH server's identity to the client. However, for the common case of Diffie-Hellman (DH) signed by public keys, this requires the client to know the host's public key a priori and to verify that the correct key is being used. If this step is skipped, then authentication of the SSH server to the SSH client is not done. Data confidentiality and data integrity protection to the server still exist, but these are of dubious value when an attacker can insert himself between the client and the real SSH server. Note that some userauth methods may defend against this situation, but many of the common ones (including password and keyboard-interactive) do not and, in fact, depend on the fact that the server's identity has been verified (so passwords are not disclosed to an attacker). SSH MUST NOT be configured to skip public-key verification for use with the SSH Transport Model. 9.2. Notification Authorization Considerations SNMP Notifications are authorized to be sent to a receiver based on the securityName used by the notification originator's SNMP engine. This authorization is performed before the message is actually sent and before the credentials of the remote receiver have been verified. Thus, the credentials presented by a notification receiver MUST match the expected value(s) for a given transport address, and ownership of the credentials MUST be properly cryptographically verified. 9.3. SSH User and Key Selection If a "user@" prefix is used within an SnmpSSHAddress value to specify an SSH user name to use for authentication, then the key presented to the remote entity MUST be the key expected by the server for the "user". This may be different than a locally cached key identified by the securityName value. 9.4. Conceptual Differences between USM and SSHTM The User-based Security Model [RFC3414] employed symmetric cryptography and user-naming conventions. SSH employs an asymmetric cryptography and naming model. Unlike USM, cryptographic keys will be different on both sides of the SSH connection. Both sides are responsible for verifying that the remote entity presents the right key. The optional "user@" prefix component of the SnmpSSHAddress Textual Convention allows the client SNMP stack to associate the connection with a securityName that may be different than the SSH user name presented to the SSH server. Harrington, et al. Standards Track [Page 31] RFC 5592 Secure Shell Transport Model for SNMP June 2009 9.5. The 'none' MAC Algorithm SSH provides the "none" Message Authentication Code (MAC) algorithm, which would allow you to turn off data integrity while maintaining confidentiality. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication. SSH MUST NOT be configured using the "none" MAC algorithm for use with the SSH Transport Model. 9.6. Use with SNMPv1/v2c Messages The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP 74) always selects the SNMPv1 or SNMPv2c Security Models, respectively. Both of these and the User-based Security Model typically used with SNMPv3 derive the securityName and securityLevel from the SNMP message received, even when the message was received over a secure transport. Access control decisions are therefore made based on the contents of the SNMP message, rather than using the authenticated identity and securityLevel provided by the SSH Transport Model. 9.7. MIB Module Security There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o The information in the snmpSshtmSession group is generated locally when a client session is being opened or closed. This information can reflect the configured capabilities of a remote SSH server, which could be helpful to an attacker for focusing an attack. Harrington, et al. Standards Track [Page 32] RFC 5592 Secure Shell Transport Model for SNMP June 2009 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec or SSH), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for cryptographic mechanisms for authentication and privacy, such as those found in the User-based Security Model [RFC3414], the Transport Security Model [RFC5591], and the SSH Transport Model described in this document. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations IANA has assigned: 1. Two TCP port numbers in the Port Numbers registry that will be the default ports for the SNMP-over-SSH Transport Model as defined in this document, and the SNMP-over-SSH Transport Model for notifications as defined in this document. The assigned keywords and port numbers are "snmpssh" (5161) and "snmpssh-trap" (5162). 2. An SMI number (189) under mib-2, for the MIB module in this document. 3. An SMI number (7) under snmpDomains, for the snmpSSHDomain. 4. "ssh" as the corresponding prefix for the snmpSSHDomain in the SNMP Transport Domains registry; defined in [RFC5590]. 5. "snmp" as a Connection Protocol Subsystem Name in the SSH Protocol Parameters registry. 11. Acknowledgments The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights, and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity. Harrington, et al. Standards Track [Page 33] RFC 5592 Secure Shell Transport Model for SNMP June 2009 Additionally, helpful document reviews were received from Juergen Schoenwaelder. 12. References 12.1. Normative References [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. Harrington, et al. Standards Track [Page 34] RFC 5592 Secure Shell Transport Model for SNMP June 2009 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. 12.2. Informative References [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4256] Cusack, F. and M. Forssen, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", RFC 4256, January 2006. Harrington, et al. Standards Track [Page 35] RFC 5592 Secure Shell Transport Model for SNMP June 2009 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006. [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. Authors' Addresses David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: ietfdbh@comcast.net Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA EMail: jsalowey@cisco.com Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US Phone: +1 530 792 1913 EMail: ietf@hardakers.net Harrington, et al. Standards Track [Page 36] snmp-mibs-downloader-1.1/mibrfcs/rfc5601.txt0000644000000000000000000037446011402176072015574 0ustar Network Working Group T. Nadeau, Ed. Request for Comments: 5601 BT Category: Standards Track D. Zelig, Ed. Oversi July 2009 Pseudowire (PW) Management Information Base (MIB) Abstract This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Nadeau & Zelig Standards Track [Page 1] RFC 5601 PW MIB July 2009 Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Conventions .....................................................3 4. Overview ........................................................3 5. Structure of the MIB Module .....................................3 6. PW-STD-MIB Module Usage .........................................4 7. Relations to Other PWE3 MIB Modules .............................5 8. Relations to the IF-MIB .........................................5 9. PW Notifications ................................................6 10. Example of the PW MIB Modules Usage ............................6 11. IANA PWE3 MIB Module ...........................................8 12. Object Definitions ............................................11 13. Security Considerations .......................................62 14. IANA Considerations ...........................................63 14.1. ifType for PW ............................................63 14.2. PW MIB Modules OBJECT IDENTIFIER Values ..................63 14.3. IANA Considerations for PW-STD-MIB .......................64 14.4. IANA Considerations for IANA-PWE3-MIB ....................64 15. Acknowledgments ...............................................64 16. References ....................................................64 16.1. Normative References .....................................64 16.2. Informative References ...................................66 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a MIB module that can be used to manage pseudowire (PW) services for transmission over a Packet Switched Network (PSN) [RFC3931] [RFC4447]. This MIB module provides generic management of PWs that is common to all types of PSN and PW services defined by the IETF PWE3 Working Group. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB Nadeau & Zelig Standards Track [Page 2] RFC 5601 PW MIB July 2009 module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. This document adopts the definitions, acronyms, and mechanisms described in [RFC3985] and [RFC3916]. Unless otherwise stated, the mechanisms of [RFC3985] apply and will not be re-described here. 4. Overview The PWE3 MIB modules architecture provides a layered modular model into which any supported emulated service can be connected to any supported PSN type. This specific MIB module provides the glue for mapping between the emulated service onto the native PSN service. As such, the defining of a PW emulated service requires the use of at least three types of MIB modules. Starting from the emulated service, the first type is a service- specific module, which is dependent on the emulated signal type. These modules are defined in other documents. The second type is this module, the PW-STD-MIB module, which configures general parameters of the PW that are common to all types of emulated services and PSN types. The third type of module is a PSN-specific module. There is a different module for each type of PSN. These modules associate the PW with one or more "tunnels" that carry the service over the PSN. These modules are defined in other documents. 5. Structure of the MIB Module The MIB module consists of six tables: - The generic configuration and status monitoring objects that are common to all service types and PSN types (pwTable). - The PW Performance Current Table (pwPerfCurrentTable) contains PW statistics for the current 15-minute period. Nadeau & Zelig Standards Track [Page 3] RFC 5601 PW MIB July 2009 - The PW Performance Interval Table (pwPerfIntervalTable) contains PW statistics for historical intervals (usually 96 15-minute entries to cover a 24-hour period). - The PW Performance 1-day Interval Table (pwPerf1DayIntervalTable) contains PW statistics for historical intervals accumulated per day. Usually 30 1-day entries to cover a monthly period. - The mapping table (pwIndexMappingTable) enables the reverse mapping of the unique PWid parameters [peer IP, PW type, and PW ID] and the pwIndex. - The mapping table (pwGenFecIndexMappingTable) enables the reverse mapping of unique PWid parameters used in genFecSignaling [pwGroupAttachmentID, pwLocalAttachmentID, and pwPeerAttachmentID] and the pwIndex. This MIB module uses Textual Conventions from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3411], [RFC3593], [RFC3705], [RFC4001], and [RFC5542], and references [RFC3413], [RFC4623], and [RFC4720]. 6. PW-STD-MIB Module Usage An entry in the PW table (pwTable) MUST exist for all PW types (ATM, FR, Ethernet, SONET, etc.). This table holds generic parameters related to the PW creation and monitoring. A conceptual row can be created in the pwTable in one of the following ways: 1) The operator creates a row in the pwTable when configuring the node for a new service. This mode MUST be supported by the agent, and MUST be used when creating a non-signaled (manually assigned) PW. 2) The agent MAY create a row in the pwTable if a signaling message has been received from a peer node with signaling identification parameters that are not already known to the local node (i.e., there is no related entry created by the operator with matching parameters). This mode is OPTIONAL. 3) The agent MAY create a row in the pwTable automatically due to some auto-discovery application, or based on configuration that is done through non-SNMP applications. This mode is OPTIONAL. - The agent then creates the rows in the (locally supported) performance tables and reverse-mapping tables in PW-STD-MIB module. Nadeau & Zelig Standards Track [Page 4] RFC 5601 PW MIB July 2009 7. Relations to Other PWE3 MIB Modules - Based on the PSN type defined for the PW, a row is created in the PSN-specific module (for example, [RFC5602]) and associated to the PW table by the common pwIndex. - Based on the PW type defined for the PW, a row is created in the service-specific module (for example, [CEPMIB]) and associated to the PW table by the common pwIndex. - Unless all the necessary entries in the applicable tables have been created and all the parameters have been consistently configured in those tables, signaling cannot be performed from the local node, and the pwVcOperStatus should report 'notPresent'. 8. Relations to the IF-MIB The PW in general is not an ifIndex [RFC2863] on its own, for agent scalability reasons. The PW is typically associated via the PWE3 MIB modules to an ifIndex the PW is emulating. This ifIndex may represent a physical entity -- for example, a PW emulating a SONET path as in Circuit Emulation Service over Packet (CEP). In that case, the PW itself is not an ifIndex; however, the PW-STD-CEP-MIB module associates the PW to the ifIndex of the path to be emulated. In some cases, the PW will be associated to an ifIndex representing a virtual interface. An example is Virtual Private LAN Service (VPLS) where the PW emulates a logical interface of a (logical) bridge. The physical ports' association to the VPLS instance is defined in the non-PW MIB modules in this case. Exception to the above MAY exist in some implementations where it is convenient to manage the PW as an ifIndex in the ifTable. A special ifType to represent a PW virtual interface (246) will be used in the ifTable in this case. When the PW is managed as an ifIndex, by default it SHOULD NOT be stacked, i.e., this ifIndex SHOULD NOT be layered above the respective PSN tunnel ifIndex or the attachment circuit ifIndex or the interface carrying the attachment circuit. Note that the ifIndex that carries the PW toward/from the PSN is not explicitly configured via PWE3 MIB modules except in rare cases. In most cases, the PW is carried inside a PSN tunnel, and the interfaces carrying the tunnel are specified in the related MIB modules that control the PSN tunnels. Nadeau & Zelig Standards Track [Page 5] RFC 5601 PW MIB July 2009 9. PW Notifications This MIB module includes notifications for PW entering the up or down state, in accordance with the guidelines for interface notifications as described in [RFC2863]. Implementers should be aware that in many systems, it is desired to correlate notifications, such that notifications will not be emitted if notifications from a higher level (such as ports or tunnels) are already in effect. Specifically for PWs, it is anticipated that most network's equipment failures turn into lowerLayerDown state at the PW level, where a notification has already been emitted from a higher level. When a PW is represented as an ifIndex, it is RECOMMENDED that PW notifications be turned off, to avoid duplication with the ifIndex status change notifications. 10. Example of the PW MIB Modules Usage In this section, we provide an example of using the MIB objects described in section 7 to set up a CEP PW over Multiprotocol Label Switching (MPLS) PSN. While this example is not meant to illustrate every permutation of the MIB, it is intended as an aid to understanding some of the key concepts. It is meant to be read after going through the MIB itself. In this example, a PW service for CEP is configured over an MPLS PSN (MPLS-TE tunnel). It uses LDP as in [RFC4447] for service setup. For the operation in the service-specific MIB modules and the PSN- specific MIB modules, see the specific MIB module memo. This example is continued in the memo describing the PW-CEP-STD-MIB module (for example, [CEPMIB]) and the PW-MPLS-STD-MIB module [RFC5602]. Nadeau & Zelig Standards Track [Page 6] RFC 5601 PW MIB July 2009 In the PW-STD-MIB module: In pwTable: { pwIndex 5, pwType cep, pwOwner pwIdFecSignaling, pwPsnType mpls, pwSetUpPriority 0, -- Highest pwHoldingPriority 0, -- Highest pwInboundMode loose, pwPeerAddrType ipv4, pwPeerAddr 192.0.2.5, -- In this case, equal to the -- peer LDP entity IP addr pwID 10, pwLocalGroupID 12, .. pwCwPreference true, -- Actually ignored for CEP pwLocalIfMtu 0, -- Do not send ifMtu parameter pwLocalIfString false, -- Do not send interface string pwCapabAdvert 0, -- Does not support status -- report to the peer. pwRemoteGroupID 0xFFFF, -- Will be received by -- signaling protocol pwRemoteCwStatus notKnownYet, pwRemoteIfMtu 0, pwRemoteIfString "", pwRemoteCapabilities notYetKnown, .. pwOutboundVcLabel 0xFFFF, -- Will be received by -- signaling protocol pwInboundVcLabel 0xFFFF, -- Will be set by signaling -- protocol pwName "Example of CEP PW", pwDescr "", .. pwAdminStatus up, .. } Nadeau & Zelig Standards Track [Page 7] RFC 5601 PW MIB July 2009 11. IANA PWE3 MIB Module This section contains the initial version of the IANA-PWE3-MIB. IANA has updated this MIB module based on expert review as defined in [RFC5226]. Each new assignment of PW type or PW PSN type made by IANA based on the procedures described in [RFC4446] should be documented in the online version of IANA-PWE3-MIB. The current IANA-PWE3-MIB contains PW types as requested in [RFC4446] and [RFC4863]. IANA-PWE3-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] ianaPwe3MIB MODULE-IDENTITY LAST-UPDATED "200906110000Z" -- 11 June 2009 00:00:00 GMT ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6601 Phone: +1 310 823 9358 EMail: iana@iana.org" DESCRIPTION "This MIB module defines the IANAPwTypeTC and IANAPwPsnTypeTC textual conventions for use in PWE3 MIB modules. Any additions or changes to the contents of this MIB module require either publication of an RFC, Designated Expert Review as defined in RFC 5226, Guidelines for Writing an IANA Considerations Section in RFCs, and should be based on the procedures defined in [RFC4446]. The Designated Expert will be selected by the IESG Area Director(s) of the internet Area. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the Nadeau & Zelig Standards Track [Page 8] RFC 5601 PW MIB July 2009 following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. " REVISION "200906110000Z" -- 11 June 2009 00:00:00 GMT DESCRIPTION "Original version, published as part of RFC 5601." ::= { mib-2 174 } IANAPwTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the PW type (i.e., the carried service). " SYNTAX INTEGER { other(0), frameRelayDlciMartiniMode(1), atmAal5SduVcc(2), atmTransparent(3), ethernetTagged(4), ethernet(5), hdlc(6), ppp(7), Nadeau & Zelig Standards Track [Page 9] RFC 5601 PW MIB July 2009 cem(8), -- Historic type atmCellNto1Vcc(9), atmCellNto1Vpc(10), ipLayer2Transport(11), atmCell1to1Vcc(12), atmCell1to1Vpc(13), atmAal5PduVcc(14), frameRelayPortMode(15), cep(16), e1Satop(17), t1Satop(18), e3Satop(19), t3Satop(20), basicCesPsn(21), basicTdmIp(22), tdmCasCesPsn(23), tdmCasTdmIp(24), frDlci(25), wildcard (32767) } IANAPwPsnTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the PSN type that the PW will use over the network." SYNTAX INTEGER { mpls (1), l2tp (2), udpOverIp (3), mplsOverIp (4), mplsOverGre (5), other (6) } IANAPwCapabilities ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC describes a collection of capabilities related to a specific PW. Values may be added in the future based on new capabilities introduced in IETF documents. " SYNTAX BITS { pwStatusIndication (0), -- Applicable only if maintenance -- protocol is in use. pwVCCV (1) } Nadeau & Zelig Standards Track [Page 10] RFC 5601 PW MIB July 2009 END 12. Object Definitions PW-STD-MIB DEFINITIONS ::= BEGIN IMPORTS NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Counter32, Counter64, TimeTicks, transmission FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TruthValue, RowStatus, StorageType, TimeStamp FROM SNMPv2-TC -- [RFC2579] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] PerfCurrentCount, PerfIntervalCount FROM PerfHist-TC-MIB -- [RFC3593] HCPerfCurrentCount, HCPerfIntervalCount, HCPerfTimeElapsed, HCPerfValidIntervals FROM HC-PerfHist-TC-MIB -- [RFC3705] PwIndexType, PwIndexOrZeroType, PwGroupID, PwIDType, PwOperStatusTC, PwAttachmentIdentifierType, PwCwStatusTC, PwStatus, PwFragSize, PwFragStatus, PwGenIdType FROM PW-TC-STD-MIB -- [RFC5542] IANAPwTypeTC, IANAPwPsnTypeTC, IANAPwCapabilities FROM IANA-PWE3-MIB -- [RFC5601] ; pwStdMIB MODULE-IDENTITY LAST-UPDATED "200906110000Z" -- 11 June 2009 00:00:00 GMT ORGANIZATION "Pseudowire Edge-to-Edge Emulation (PWE3) Working Group" CONTACT-INFO Nadeau & Zelig Standards Track [Page 11] RFC 5601 PW MIB July 2009 "David Zelig Email: davidz@oversi.com Thomas D. Nadeau Email: tom.nadeau@bt.com The PWE3 Working Group (email distribution pwe3@ietf.org, http://www.ietf.org/html.charters/pwe3-charter.html) " DESCRIPTION "This MIB module contains managed object definitions for pseudowire operation as in Bryant, S. and P. Pate, 'Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture' [RFC3985], Martini, L., et al, 'Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)' [RFC4447], and Townsley, M., et al, 'Layer Two Tunneling Protocol (Version 3)' [RFC3931]. This MIB module enables the use of any underlying packet switched network (PSN). MIB nodules that will support PW operations over specific PSN types are defined in separate memos. The indexes for this MIB module are also used to index the PSN-specific tables and the PW-specific tables. The PW Type dictates which PW-specific MIB module to use. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. Nadeau & Zelig Standards Track [Page 12] RFC 5601 PW MIB July 2009 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5601; see the RFC itself for full legal notices. " -- Revision history. REVISION "200906110000Z" -- 11 June 2009 00:00:00 GMT DESCRIPTION "Initial version published as part of RFC 5601." ::= { transmission 246 } -- Top-level components of this MIB. -- Notifications pwNotifications OBJECT IDENTIFIER ::= { pwStdMIB 0 } -- Tables, Scalars pwObjects OBJECT IDENTIFIER ::= { pwStdMIB 1 } -- Conformance pwConformance OBJECT IDENTIFIER ::= { pwStdMIB 2 } -- PW Virtual Connection Table pwIndexNext OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for pwIndex when creating entries in the pwTable. The value 0 indicates that no unassigned entries are available. To obtain the value of pwIndex for a new entry in the pwTable, Nadeau & Zelig Standards Track [Page 13] RFC 5601 PW MIB July 2009 the manager issues a management protocol retrieval operation. The agent will determine through its local policy when this index value will be made available for reuse." ::= { pwObjects 1 } pwTable OBJECT-TYPE SYNTAX SEQUENCE OF PwEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies information for configuring and status monitoring that is common to all service types and PSN types." ::= { pwObjects 2 } pwEntry OBJECT-TYPE SYNTAX PwEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table represents a pseudowire (PW) virtual connection across a packet network. It is indexed by pwIndex, which uniquely identifies a singular connection. A row can be created by an operator command from a management plan of a PE, by signaling, or due to auto- discovery process. An operator's command can be issued via a non-SNMP application; in such case, a row will be created implicitly by the agent. The read-create objects in this table are divided into three categories: 1) Objects that MUST NOT be changed after row activation. These are objects that define basic properties of the PW (for example type, destination, etc.). 2) Objects that MAY be changed when the PW is defined as not active. A change of these objects involves re-signaling of the PW or it might be traffic affecting. PW not active is defined as one of the following conditions: a) The pwRowStatus is notInService(2). b) The pwRowStatus is notReady(3). c) The pwAdminStatus is down(2). If the operator needs to change one of the values for an active row, the operator can either set the pwRowStatus to notInService(2) or set pwAdminStatus to down(2). Signaling (or traffic) is initiated again upon setting the pwRowStatus to active(1) or setting the pwAdminStatus to up(1) or testing(3), respectively. Nadeau & Zelig Standards Track [Page 14] RFC 5601 PW MIB July 2009 3) Objects that MAY be changed at any time. A PW MAY have an entry in the ifTable in addition to the entry in this table. In this case, a special ifType for PW will be set in the ifTable, and the ifIndex in the ifTable of the PW will be set in the pwIfIndex object in this table. By default, all the read-create objects MUST NOT be changed after row activation, unless specifically indicated in the individual object description. Manual entries in this table SHOULD be preserved after a reboot; the agent MUST ensure the integrity of those entries. If the set of entries of a specific row are found to be inconsistent after reboot, the PW pwOperStatus MUST be declared as notPresent(5). " INDEX { pwIndex } ::= { pwTable 1 } PwEntry ::= SEQUENCE { pwIndex PwIndexType, pwType IANAPwTypeTC, pwOwner INTEGER, pwPsnType IANAPwPsnTypeTC, pwSetUpPriority Integer32, pwHoldingPriority Integer32, pwPeerAddrType InetAddressType, pwPeerAddr InetAddress, pwAttachedPwIndex PwIndexOrZeroType, pwIfIndex InterfaceIndexOrZero, pwID PwIDType, pwLocalGroupID PwGroupID, pwGroupAttachmentID PwAttachmentIdentifierType, pwLocalAttachmentID PwAttachmentIdentifierType, pwRemoteAttachmentID PwAttachmentIdentifierType, pwCwPreference TruthValue, pwLocalIfMtu Unsigned32, pwLocalIfString TruthValue, pwLocalCapabAdvert IANAPwCapabilities, pwRemoteGroupID PwGroupID, pwCwStatus PwCwStatusTC, pwRemoteIfMtu Unsigned32, Nadeau & Zelig Standards Track [Page 15] RFC 5601 PW MIB July 2009 pwRemoteIfString SnmpAdminString, pwRemoteCapabilities IANAPwCapabilities, pwFragmentCfgSize PwFragSize, pwRmtFragCapability PwFragStatus, pwFcsRetentionCfg INTEGER, pwFcsRetentionStatus BITS, pwOutboundLabel Unsigned32, pwInboundLabel Unsigned32, pwName SnmpAdminString, pwDescr SnmpAdminString, pwCreateTime TimeStamp, pwUpTime TimeTicks, pwLastChange TimeTicks, pwAdminStatus INTEGER, pwOperStatus PwOperStatusTC, pwLocalStatus PwStatus, pwRemoteStatusCapable INTEGER, pwRemoteStatus PwStatus, pwTimeElapsed HCPerfTimeElapsed, pwValidIntervals HCPerfValidIntervals, pwRowStatus RowStatus, pwStorageType StorageType, pwOamEnable TruthValue, pwGenAGIType PwGenIdType, pwGenLocalAIIType PwGenIdType, pwGenRemoteAIIType PwGenIdType } pwIndex OBJECT-TYPE SYNTAX PwIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the conceptual row identifying a PW within this table." ::= { pwEntry 1 } pwType OBJECT-TYPE SYNTAX IANAPwTypeTC MAX-ACCESS read-create STATUS current DESCRIPTION "This value indicates the emulated service to be carried over this PW. " Nadeau & Zelig Standards Track [Page 16] RFC 5601 PW MIB July 2009 ::= { pwEntry 2 } pwOwner OBJECT-TYPE SYNTAX INTEGER { manual (1), pwIdFecSignaling (2), -- PW signaling with PW ID FEC genFecSignaling (3), -- Generalized attachment FEC l2tpControlProtocol (4), other (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is set by the operator to indicate the protocol responsible for establishing this PW. 'manual' is used in all cases where no maintenance protocol (PW signaling) is used to set up the PW, i.e., configuration of entries in the PW tables including PW labels, etc., is done by setting the MIB fields manually. 'pwIdFecSignaling' is used in case of signaling with the Pwid FEC element with LDP signaling. 'genFecSignaling' is used in case of LDP signaling with the generalized FEC. 'l2tpControlProtocol' indicates the use of the L2TP control protocol. 'other' is used for other types of signaling." ::= { pwEntry 3 } pwPsnType OBJECT-TYPE SYNTAX IANAPwPsnTypeTC MAX-ACCESS read-create STATUS current DESCRIPTION "This object is set by the operator to indicate the PSN type. Based on this object, the relevant PSN table's entry is created in the PSN-specific MIB modules. " ::= { pwEntry 4 } pwSetUpPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the relative priority of the PW during set-up in a lowest-to-highest fashion, where 0 is the highest priority. PWs with the same priority are treated with equal priority. PWs that have not yet Nadeau & Zelig Standards Track [Page 17] RFC 5601 PW MIB July 2009 completed setup will report 'dormant' in the pwOperStatus. This value is significant if there are competing resources among PWs and the implementation supports this feature. Equal priority handling with competing resources is implementation specific. This object MAY be changed at any time." DEFVAL { 0 } ::= { pwEntry 5 } pwHoldingPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the relative holding priority of the PW in a lowest-to-highest fashion, where 0 is the highest priority. PWs with the same priority are treated equally. This value is significant if there are competing resources among PWs and the implementation supports this feature. Equal priority handling with competing resources is implementation specific. This object MAY be changed only if the PW is not active." DEFVAL { 0 } ::= { pwEntry 6 } pwPeerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes the address type of the peer node. It should be set to 'unknown' if PE/PW maintenance protocol is not used and the address is unknown." DEFVAL { ipv4 } ::= { pwEntry 8 } pwPeerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the value of the peer node address of the PW/PE maintenance protocol entity. This object SHOULD contain a value of all zeroes if not applicable (pwPeerAddrType is 'unknown')." ::= { pwEntry 9 } Nadeau & Zelig Standards Track [Page 18] RFC 5601 PW MIB July 2009 pwAttachedPwIndex OBJECT-TYPE SYNTAX PwIndexOrZeroType MAX-ACCESS read-create STATUS current DESCRIPTION "If the PW is attached to another PW instead of a local native service, this item indicates the pwIndex of the attached PW. Otherwise, this object MUST be set to zero. Attachment to another PW will have no PW specific entry in any of the service MIB modules." DEFVAL { 0 } ::= { pwEntry 10 } pwIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the ifIndex of the PW if the PW is represented in the ifTable. Otherwise, it MUST be set to zero." DEFVAL { 0 } ::= { pwEntry 11 } pwID OBJECT-TYPE SYNTAX PwIDType MAX-ACCESS read-create STATUS current DESCRIPTION "Pseudowire identifier. If the pwOwner object is 'pwIdFecSignaling' or 'l2tpControlProtocol', then this object is signaled in the outgoing PW ID field within the 'Virtual Circuit FEC Element'. For other values of pwOwner, this object is not signaled and it MAY be set to zero. For implementations that support the pwIndexMappingTable, a non-zero value is RECOMMENDED, even if this identifier is not signaled. This is so that reverse mappings can be provided by pwIndexMappingTable and pwPeerMappingTable. It is therefore RECOMMENDED that the value of this pwID be unique (or if pwPeerAddrType is not 'unknown', at least [pwType, pwID, pwPeerAddrType, pwPeerAddr] is unique.)" REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." Nadeau & Zelig Standards Track [Page 19] RFC 5601 PW MIB July 2009 ::= { pwEntry 12 } pwLocalGroupID OBJECT-TYPE SYNTAX PwGroupID MAX-ACCESS read-create STATUS current DESCRIPTION "Used in the Group ID field sent to the peer PW End Service within the maintenance protocol used for PW setup. It SHOULD be set to zero if a maintenance protocol is not used." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 13 } pwGroupAttachmentID OBJECT-TYPE SYNTAX PwAttachmentIdentifierType MAX-ACCESS read-create STATUS current DESCRIPTION "This object is an octet string representing the attachment group identifier (AGI) that this PW belongs to, which typically identifies the VPN ID. Applicable if pwOwner equals 'genFecSignaling'." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 14 } pwLocalAttachmentID OBJECT-TYPE SYNTAX PwAttachmentIdentifierType MAX-ACCESS read-create STATUS current DESCRIPTION "This object is an octet string representing the local forwarder attachment individual identifier (AII) to be used by this PW. It is used as the Source AII (SAII) for outgoing signaling messages and the Target AII (TAII) in the incoming messages from the peer. Applicable if pwOwner equal 'genFecSignaling'." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 15 } Nadeau & Zelig Standards Track [Page 20] RFC 5601 PW MIB July 2009 pwRemoteAttachmentID OBJECT-TYPE SYNTAX PwAttachmentIdentifierType MAX-ACCESS read-create STATUS current DESCRIPTION "This object is an octet string representing the remote forwarder attachment individual identifier (AII) to be used by this PW. It is used as the TAII for outgoing signaling messages and the SAII in the incoming messages from the peer. Applicable if pwOwner equals 'genFecSignaling'." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 16 } pwCwPreference OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Defines if the control word will be sent with each packet by the local node. Some PW types mandate the use of a control word, and in such cases, the value configured for this object has no effect on the existence of the control word. This object MAY be changed only if the PW is not active." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol.', RFC 4447." DEFVAL { false } ::= { pwEntry 17 } pwLocalIfMtu OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If not equal to zero, the optional IfMtu object in the signaling protocol will be sent with this value, which represents the locally supported MTU size over the interface (or the virtual interface) associated with the PW. This object MAY be changed only if the PW is not active." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." DEFVAL { 0 } Nadeau & Zelig Standards Track [Page 21] RFC 5601 PW MIB July 2009 ::= { pwEntry 18 } pwLocalIfString OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A PW MAY be associated to an interface (or a virtual interface) in the ifTable of the node as part of the service configuration. This object defines if the maintenance protocol will send the interface's name (ifAlias) as it appears in the ifTable. If set to false, the optional element will not be sent. This object MAY be changed only if the PW is not active." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447, section 5.5." DEFVAL { false } ::= { pwEntry 19 } pwLocalCapabAdvert OBJECT-TYPE SYNTAX IANAPwCapabilities MAX-ACCESS read-create STATUS current DESCRIPTION "If a maintenance protocol is used, it indicates the capabilities the local node will advertise to the peer. The operator MAY selectively assign a partial set of capabilities. In case of manual configuration of the PW, the operator SHOULD set non-conflicting options (for example, only a single type of Operations, Administration, and Management (OAM)) out of the available options in the implementation. It is possible to change the value of this object when the PW is not active. The agent MUST reject any attempt to set a capability that is not supported. The default value MUST be the full set of local node capabilities." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 20 } pwRemoteGroupID OBJECT-TYPE SYNTAX PwGroupID MAX-ACCESS read-only STATUS current Nadeau & Zelig Standards Track [Page 22] RFC 5601 PW MIB July 2009 DESCRIPTION "This object is obtained from the Group ID field as received via the maintenance protocol used for PW setup. Value of zero will be reported if not used. Value of 0xFFFFFFFF shall be used if the object is yet to be defined by the PW maintenance protocol." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 21 } pwCwStatus OBJECT-TYPE SYNTAX PwCwStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "If signaling is used for PW establishment, this object indicates the status of the control word negotiation. For either signaling or manual configuration, it indicates if the control word (CW) is to be present for this PW." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 22 } pwRemoteIfMtu OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The remote interface MTU as (optionally) received from the remote node via the maintenance protocol. The object SHOULD report zero if the MTU is not available." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 23 } pwRemoteIfString OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..80)) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the interface description string as received by the maintenance protocol. It MUST be a NULL string if a maintenance protocol is not used or the value is not known yet." Nadeau & Zelig Standards Track [Page 23] RFC 5601 PW MIB July 2009 REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447, section 5.5." ::= { pwEntry 24 } pwRemoteCapabilities OBJECT-TYPE SYNTAX IANAPwCapabilities MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the capabilities as received from the peer." REFERENCE "Martini, et al, 'Pseudowire Setup and Maintenance using the Label Distribution Protocol', RFC 4447." ::= { pwEntry 25 } pwFragmentCfgSize OBJECT-TYPE SYNTAX PwFragSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "If set to a value other than zero, indicates that fragmentation is desired for this PW. This object MAY be changed only if the PW is not active." REFERENCE "Malis A., Townsley M., 'PWE3 Fragmentation and Reassembly', RFC 4623." DEFVAL { 0 } -- i.e., fragmentation not desired ::= { pwEntry 26 } pwRmtFragCapability OBJECT-TYPE SYNTAX PwFragStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the fragmentation based on the local configuration and the peer capabilities as received from the peer when a control protocol is used." REFERENCE "Malis A., Townsley M., 'PWE3 Fragmentation and Reassembly', RFC 4623." ::= { pwEntry 27 } pwFcsRetentionCfg OBJECT-TYPE SYNTAX INTEGER { fcsRetentionDisable (1), fcsRetentionEnable (2) Nadeau & Zelig Standards Track [Page 24] RFC 5601 PW MIB July 2009 } MAX-ACCESS read-create STATUS current DESCRIPTION "The local configuration of Frame Check Sequence (FCS) retention for this PW. FCS retention can be configured for PW types High-Level Data Link Control (HDLC), Point-to-Point Protocol (PPP), and Ethernet only. If the implementation does not support FCS retention, an error MUST be reported in pwFcsRetentionStatus. This object MAY be changed only if the PW is not active." REFERENCE "Malis A., et al., 'PWE3 Frame Check Sequence Retention', RFC 4720." DEFVAL { fcsRetentionDisable } ::= { pwEntry 28 } pwFcsRetentionStatus OBJECT-TYPE SYNTAX BITS { remoteIndicationUnknown (0), remoteRequestFcsRetention (1), fcsRetentionEnabled (2), fcsRetentionDisabled (3), localFcsRetentionCfgErr (4), fcsRetentionFcsSizeMismatch (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the FCS retention negotiation process based on local configuration and the remote advertisement. remoteIndicationUnknown - set if a FEC has not been received from the remote. remoteRequestFcsRetention - indicates that the peer has requested FCS retention. FCS retention will be used if the local node is capable and configured to use it for this PW. fcsRetentionEnabled - FCS retention is enabled (both peers were configured for FCS retention for signaled PW, or the local node is configured and capable of FCS retention for manually assigned PWs). fcsRetentionDisabled - FCS retention is disabled (not configured locally or not advertised by the peer). Nadeau & Zelig Standards Track [Page 25] RFC 5601 PW MIB July 2009 localFcsRetentionCfgErr - set if the local node has been configured for FCS retention but is not capable to support it. fcsRetentionFcsSizeMismatch - set if there is an FCS size mismatch between the local and the peer node. " REFERENCE "Malis A., et al., 'PWE3 Frame Check Sequence Retention', RFC 4720" ::= { pwEntry 29 } pwOutboundLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The PW label used in the outbound direction (i.e., toward the PSN). It might be set manually if pwOwner is 'manual'; otherwise, it is set automatically. For MPLS, MPLS over IP, or MPLS over Generic Routing Encapsulation (GRE) PSN, it represents the 20-bit PW tag; for L2TP, it represents the 32-bit Session ID; and for IP PSN, it represents the destination UDP port number. If the label is not yet known (signaling in process), the object SHOULD return a value of 0xFFFFFFFF. For manual configuration, this object MAY be changed only if the PW is not active." ::= { pwEntry 30 } pwInboundLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The PW label used in the inbound direction (i.e., packets received from the PSN). It may be set manually if pwOwner is 'manual'; otherwise, it is set automatically. For MPLS, MPLS over IP, or MPLS over GRE PSN, it represents the 20-bit PW tag; for L2TP, it represents the 32-bit Session ID; and for IP PSN, it represents the source UDP port number. If the label is not yet known (signaling in process), the object SHOULD return a value of 0xFFFFFFFF. For manual configuration, this object MAY be changed only if the PW is not active." ::= { pwEntry 31 } Nadeau & Zelig Standards Track [Page 26] RFC 5601 PW MIB July 2009 pwName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The canonical name assigned to the PW. This object MAY be changed at any time." ::= { pwEntry 32 } pwDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A textual string containing information about the PW. If there is no description, this object contains a zero- length string. This object MAY be changed at any time." ::= { pwEntry 33 } pwCreateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this PW was created." ::= { pwEntry 34 } pwUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the time since last change of pwOperStatus to Up(1)." ::= { pwEntry 35 } pwLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the PW entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { pwEntry 36 } Nadeau & Zelig Standards Track [Page 27] RFC 5601 PW MIB July 2009 pwAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in a test mode } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired operational status of this PW. This object MAY be set at any time." ::= { pwEntry 37 } pwOperStatus OBJECT-TYPE SYNTAX PwOperStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the operational status of the PW; it does not reflect the status of the Customer Edge (CE) bound interface. It is set to down only if pwNotForwarding, psnFacingPwRxFault, or psnFacingPwTxFault indications are set in pwLocalStatus or pwRemoteStatus. It indicates 'lowerLayerDown' if the only reason for not being in the 'up' state is that either the outer tunnel or physical layer of the network side is in the 'down' state. All other states are declared based on the description of the PwOperStatusTC. " ::= { pwEntry 38 } pwLocalStatus OBJECT-TYPE SYNTAX PwStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the status of the PW in the local node. The various indications in this object SHOULD be available independent of the ability of the local node to advertise them or the remote node to accept these status indications through the control protocol. " ::= { pwEntry 39 } pwRemoteStatusCapable OBJECT-TYPE SYNTAX INTEGER { notApplicable (1), Nadeau & Zelig Standards Track [Page 28] RFC 5601 PW MIB July 2009 notYetKnown (2), remoteCapable (3), remoteNotCapable (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the remote node capability to advertise the PW status notification. notApplicable SHOULD be reported for a manually set PW, or if the local node is not capable of accepting the status notification object. notYetKnown SHOULD be reported if the signaling protocol has not yet finished the process of capability determination. remoteCapable and remoteNotcapable SHOULD be reported based on the initial signaling exchange that has determined the remote node capability. " ::= { pwEntry 40 } pwRemoteStatus OBJECT-TYPE SYNTAX PwStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the status of the PW as was advertised by the remote. If the remote is not capable of advertising the status object, or the local node is not able to accept the status object through signaling, then the applicable bit is 'pwNotForwarding', which is set if the remote has sent label release or label withdraw for this PW. " ::= { pwEntry 41 } pwTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds, including partial seconds, that have elapsed since the beginning of the current interval measurement period." ::= { pwEntry 42 } pwValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals MAX-ACCESS read-only Nadeau & Zelig Standards Track [Page 29] RFC 5601 PW MIB July 2009 STATUS current DESCRIPTION "The number of previous 15-minute intervals for which data was collected." ::= { pwEntry 43 } pwRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "For creating, modifying, and deleting this row. This object MAY be changed at any time." ::= { pwEntry 44 } pwStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this object." DEFVAL { nonVolatile } ::= { pwEntry 45 } pwOamEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates if OAM is enabled for this PW. It MAY be changed at any time." DEFVAL { true } ::= { pwEntry 46 } pwGenAGIType OBJECT-TYPE SYNTAX PwGenIdType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the AGI type if generalized FEC (129) is used for PW signaling or configuration. It SHOULD return the value of zero otherwise." DEFVAL { 0 } ::= { pwEntry 47 } pwGenLocalAIIType OBJECT-TYPE SYNTAX PwGenIdType Nadeau & Zelig Standards Track [Page 30] RFC 5601 PW MIB July 2009 MAX-ACCESS read-create STATUS current DESCRIPTION "This object is the type of the local forwarder attachment individual identifier (AII) to be used by this PW if generalized FEC (129) is used for PW signaling or configuration." DEFVAL { 0 } ::= { pwEntry 48 } pwGenRemoteAIIType OBJECT-TYPE SYNTAX PwGenIdType MAX-ACCESS read-create STATUS current DESCRIPTION "This object is the type of the remote forwarder attachment individual identifier (AII) to be used by this PW if generalized FEC (129) is used for PW signaling or configuration." DEFVAL { 0 } ::= { pwEntry 49 } -- End of the PW Virtual Connection Table -- PW Performance Table pwPerfCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF PwPerfCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides per-PW performance information for the current interval." ::= { pwObjects 3 } pwPerfCurrentEntry OBJECT-TYPE SYNTAX PwPerfCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every PW." INDEX { pwIndex } ::= { pwPerfCurrentTable 1 } PwPerfCurrentEntry ::= SEQUENCE { pwPerfCurrentInHCPackets HCPerfCurrentCount, pwPerfCurrentInHCBytes HCPerfCurrentCount, Nadeau & Zelig Standards Track [Page 31] RFC 5601 PW MIB July 2009 pwPerfCurrentOutHCPackets HCPerfCurrentCount, pwPerfCurrentOutHCBytes HCPerfCurrentCount, pwPerfCurrentInPackets PerfCurrentCount, pwPerfCurrentInBytes PerfCurrentCount, pwPerfCurrentOutPackets PerfCurrentCount, pwPerfCurrentOutBytes PerfCurrentCount } pwPerfCurrentInHCPackets OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of packets received by the PW (from the PSN) in the current 15-minute interval. This is the 64-bit version of pwPerfCurrentInPackets, if pwPerfCurrentInHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 1 } pwPerfCurrentInHCBytes OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of bytes received by the PW (from the PSN) in the current 15-minute interval. This is the 64-bit version of pwPerfCurrentInBytes, if pwPerfCurrentInHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 2 } pwPerfCurrentOutHCPackets OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of packets forwarded by the PW (to the PSN) in the current 15-minute interval. This is the 64-bit version of pwPerfCurrentOutPackets, if pwPerfCurrentOutHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 3 } pwPerfCurrentOutHCBytes OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only Nadeau & Zelig Standards Track [Page 32] RFC 5601 PW MIB July 2009 STATUS current DESCRIPTION "High-capacity counter for number of bytes forwarded by the PW (to the PSN) in the current 15-minute interval. This is the 64-bit version of pwPerfCurrentOutBytes, if pwPerfCurrentOutHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 4 } pwPerfCurrentInPackets OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter for number of packets received by the PW (from the PSN) in the current 15-minute interval. This is the 32-bit version of pwPerfCurrentInHCPackets, if pwPerfCurrentInHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 5 } pwPerfCurrentInBytes OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter for number of bytes received by the PW (from the PSN) in the current 15-minute interval. It MUST be equal to the least significant 32 bits of pwPerfCurrentInHCBytes, if pwPerfCurrentInHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 6 } pwPerfCurrentOutPackets OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter for number of packets forwarded by the PW (to the PSN) in the current 15-minute interval. It MUST be equal to the least significant 32 bits of pwPerfCurrentOutHCPackets, if pwPerfCurrentOutHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 7 } pwPerfCurrentOutBytes OBJECT-TYPE SYNTAX PerfCurrentCount Nadeau & Zelig Standards Track [Page 33] RFC 5601 PW MIB July 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter for number of bytes forwarded by the PW (to the PSN) in the current 15-minute interval. It MUST be equal to the least significant 32 bits of pwPerfCurrentOutHCBytes, if pwPerfCurrentOutHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfCurrentEntry 8 } -- End of the PW Performance Current Table -- PW Performance Interval Table pwPerfIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF PwPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides per-PW performance information for each interval." ::= { pwObjects 4 } pwPerfIntervalEntry OBJECT-TYPE SYNTAX PwPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every PW." INDEX { pwIndex, pwPerfIntervalNumber } ::= { pwPerfIntervalTable 1 } PwPerfIntervalEntry ::= SEQUENCE { pwPerfIntervalNumber Integer32, pwPerfIntervalValidData TruthValue, pwPerfIntervalTimeElapsed HCPerfTimeElapsed, pwPerfIntervalInHCPackets HCPerfIntervalCount, pwPerfIntervalInHCBytes HCPerfIntervalCount, pwPerfIntervalOutHCPackets HCPerfIntervalCount, pwPerfIntervalOutHCBytes HCPerfIntervalCount, pwPerfIntervalInPackets PerfIntervalCount, pwPerfIntervalInBytes PerfIntervalCount, pwPerfIntervalOutPackets PerfIntervalCount, pwPerfIntervalOutBytes PerfIntervalCount } pwPerfIntervalNumber OBJECT-TYPE Nadeau & Zelig Standards Track [Page 34] RFC 5601 PW MIB July 2009 SYNTAX Integer32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number N, between 1 and 96, which identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15-minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1. The minimum range of N is 1 through 4. The default range is 1 to 32. The maximum range of N is 1 through 96." REFERENCE "Tesink, K. 'Definitions of Managed Objects for the SONET/SDH Interface Type', RFC 2558" ::= { pwPerfIntervalEntry 1 } pwPerfIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { pwPerfIntervalEntry 2 } pwPerfIntervalTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed MAX-ACCESS read-only STATUS current DESCRIPTION "The duration of this interval in seconds." ::= { pwPerfIntervalEntry 3 } pwPerfIntervalInHCPackets OBJECT-TYPE SYNTAX HCPerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of packets received by the PW (from the PSN) during the interval. This is the 64-bit version of pwPerfIntervalInPackets, if pwPerfIntervalInHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 4 } pwPerfIntervalInHCBytes OBJECT-TYPE SYNTAX HCPerfIntervalCount Nadeau & Zelig Standards Track [Page 35] RFC 5601 PW MIB July 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of bytes received by the PW (from the PSN) during the interval. This is the 64-bit version of pwPerfIntervalInBytes, if pwPerfIntervalInHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 5 } pwPerfIntervalOutHCPackets OBJECT-TYPE SYNTAX HCPerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of packets forwarded by the PW (to the PSN) during the interval. This is the 64-bit version of pwPerfIntervalOutPackets, if pwPerfIntervalOutHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 6 } pwPerfIntervalOutHCBytes OBJECT-TYPE SYNTAX HCPerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for number of bytes forwarded by the PW (to the PSN) during the interval. This is the 64-bit version of pwPerfIntervalOutBytes, if pwPerfIntervalOutHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 7 } pwPerfIntervalInPackets OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the number of packets received by this PW during the interval. It MUST be equal to the least significant 32 bits of pwPerfIntervalInHCPackets, if pwPerfIntervalInHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 8 } pwPerfIntervalInBytes OBJECT-TYPE Nadeau & Zelig Standards Track [Page 36] RFC 5601 PW MIB July 2009 SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the number of bytes received by this PW during the interval. It MUST be equal to the least significant 32 bits of pwPerfIntervalInHCBytes, if pwPerfIntervalInHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 9 } pwPerfIntervalOutPackets OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the number of packets sent by this PW during the interval. It MUST be equal to the least significant 32 bits of pwPerfIntervalOutHCPackets, if pwPerfIntervalOutHCPackets is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 10 } pwPerfIntervalOutBytes OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the number of bytes sent by this PW during the interval. It MUST be equal to the least significant 32 bits of pwPerfIntervalOutHCBytes, if pwPerfIntervalOutHCBytes is supported according to the rules spelled out in RFC 2863." ::= { pwPerfIntervalEntry 11 } -- End of the PW Performance Interval Table -- PW Performance 1-day Interval Table pwPerf1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF PwPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides per-PW performance information for the current day's measurement and the previous day's Nadeau & Zelig Standards Track [Page 37] RFC 5601 PW MIB July 2009 interval." ::= { pwObjects 5 } pwPerf1DayIntervalEntry OBJECT-TYPE SYNTAX PwPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every PW." INDEX { pwIndex, pwPerf1DayIntervalNumber } ::= { pwPerf1DayIntervalTable 1 } PwPerf1DayIntervalEntry ::= SEQUENCE { pwPerf1DayIntervalNumber Unsigned32, pwPerf1DayIntervalValidData TruthValue, pwPerf1DayIntervalTimeElapsed HCPerfTimeElapsed, pwPerf1DayIntervalInHCPackets Counter64, pwPerf1DayIntervalInHCBytes Counter64, pwPerf1DayIntervalOutHCPackets Counter64, pwPerf1DayIntervalOutHCBytes Counter64 } pwPerf1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32(1..31) MAX-ACCESS not-accessible STATUS current DESCRIPTION "History Data Interval number. Interval 1 is the current day's measurement period, interval 2 is the most recent previous day, and interval 30 is 31 days ago. Intervals 3..31 are optional." ::= { pwPerf1DayIntervalEntry 1 } pwPerf1DayIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { pwPerf1DayIntervalEntry 2 } pwPerf1DayIntervalTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only Nadeau & Zelig Standards Track [Page 38] RFC 5601 PW MIB July 2009 STATUS current DESCRIPTION "The number of seconds in the 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason or where agent clock adjustments have been made." ::= { pwPerf1DayIntervalEntry 3 } pwPerf1DayIntervalInHCPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for the total number of packets received by the PW (from the PSN)." ::= { pwPerf1DayIntervalEntry 4 } pwPerf1DayIntervalInHCBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for the total number of bytes received by the PW (from the PSN)." ::= { pwPerf1DayIntervalEntry 5 } pwPerf1DayIntervalOutHCPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for the total number of packets forwarded by the PW (to the PSN)." ::= { pwPerf1DayIntervalEntry 6 } pwPerf1DayIntervalOutHCBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High-capacity counter for the total number of bytes forwarded by the PW (to the PSN)." ::= { pwPerf1DayIntervalEntry 7 } -- End of the PW Performance 1-day Interval Table Nadeau & Zelig Standards Track [Page 39] RFC 5601 PW MIB July 2009 -- Error counter scalar pwPerfTotalErrorPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Counter for number of errors at the PW processing level, for example, packets received with unknown PW label." ::= { pwObjects 6 } -- Reverse mapping tables -- The PW ID mapping table pwIndexMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enables the reverse mapping of the unique PWid parameters [peer IP, PW type, and PW ID] and the pwIndex. The table is not applicable for PWs created manually or by using the generalized FEC." ::= { pwObjects 7 } pwIndexMappingEntry OBJECT-TYPE SYNTAX PwIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table MUST be created by the agent for every PW created by the pwTable for which pwOwner equals pwIdFecSignaling and pwID is not zero. Implementers need to be aware that if the value of the pwIndexMappingPeerAddr (an OID) has more than 113 sub-identifiers, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { pwIndexMappingPwType, pwIndexMappingPwID, pwIndexMappingPeerAddrType, pwIndexMappingPeerAddr } ::= { pwIndexMappingTable 1 } PwIndexMappingEntry ::= SEQUENCE { pwIndexMappingPwType IANAPwTypeTC, pwIndexMappingPwID PwIDType, pwIndexMappingPeerAddrType InetAddressType, Nadeau & Zelig Standards Track [Page 40] RFC 5601 PW MIB July 2009 pwIndexMappingPeerAddr InetAddress, pwIndexMappingPwIndex PwIndexType } pwIndexMappingPwType OBJECT-TYPE SYNTAX IANAPwTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The PW type (indicates the service) of this PW." ::= { pwIndexMappingEntry 1 } pwIndexMappingPwID OBJECT-TYPE SYNTAX PwIDType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The PW ID of this PW. Zero if the PW is configured manually." ::= { pwIndexMappingEntry 2 } pwIndexMappingPeerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address type of the peer node." ::= { pwIndexMappingEntry 3 } pwIndexMappingPeerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address of the peer node." ::= { pwIndexMappingEntry 4 } pwIndexMappingPwIndex OBJECT-TYPE SYNTAX PwIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "The value that represents the PW in the pwTable." ::= { pwIndexMappingEntry 5 } -- End of the PW ID mapping table -- The peer mapping table Nadeau & Zelig Standards Track [Page 41] RFC 5601 PW MIB July 2009 pwPeerMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwPeerMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides reverse mapping of the existing PW based on PW type and PW ID ordering. This table is typically useful for the element management system (EMS) ordered query of existing PWs." ::= { pwObjects 8 } pwPeerMappingEntry OBJECT-TYPE SYNTAX PwPeerMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every PW entry in the pwTable. Implementers need to be aware that if the value of the pwPeerMappingPeerAddr (an OID) has more than 113 sub-identifiers, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { pwPeerMappingPeerAddrType, pwPeerMappingPeerAddr, pwPeerMappingPwType, pwPeerMappingPwID } ::= { pwPeerMappingTable 1 } PwPeerMappingEntry ::= SEQUENCE { pwPeerMappingPeerAddrType InetAddressType, pwPeerMappingPeerAddr InetAddress, pwPeerMappingPwType IANAPwTypeTC, pwPeerMappingPwID PwIDType, pwPeerMappingPwIndex PwIndexType } pwPeerMappingPeerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address type of the peer node." ::= { pwPeerMappingEntry 1 } pwPeerMappingPeerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible Nadeau & Zelig Standards Track [Page 42] RFC 5601 PW MIB July 2009 STATUS current DESCRIPTION "IP address of the peer node." ::= { pwPeerMappingEntry 2 } pwPeerMappingPwType OBJECT-TYPE SYNTAX IANAPwTypeTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The PW type (indicates the emulated service) of this PW." ::= { pwPeerMappingEntry 3 } pwPeerMappingPwID OBJECT-TYPE SYNTAX PwIDType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The PW ID of this PW. Zero if the PW is configured manually." ::= { pwPeerMappingEntry 4 } pwPeerMappingPwIndex OBJECT-TYPE SYNTAX PwIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "The value that represents the PW in the pwTable." ::= { pwPeerMappingEntry 5 } -- End of the peer mapping table -- End of the reverse mapping tables pwUpDownNotifEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is set to true(1), then it enables the emission of pwUp and pwDown notifications; otherwise, these notifications are not emitted." REFERENCE "See also [RFC3413] for explanation that notifications are under the ultimate control of the MIB module in this document." DEFVAL { false } Nadeau & Zelig Standards Track [Page 43] RFC 5601 PW MIB July 2009 ::= { pwObjects 9 } pwDeletedNotifEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is set to true(1), then it enables the emission of pwDeleted notification; otherwise, this notification is not emitted." REFERENCE "See also [RFC3413] for explanation that notifications are under the ultimate control of the MIB module in this document." DEFVAL { false } ::= { pwObjects 10 } pwNotifRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This object defines the maximum number of PW notifications that can be emitted from the device per second." ::= { pwObjects 11 } -- The Gen Fec PW ID mapping table pwGenFecIndexMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwGenFecIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enables the reverse mapping of the unique PWid parameters [GroupAttachmentID, LocalAttachmentID, and PeerAttachmentID] and the pwIndex. The table is only applicable for PW using the generalized FEC." ::= { pwObjects 12 } pwGenFecIndexMappingEntry OBJECT-TYPE SYNTAX PwGenFecIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table MUST be created by the agent for every PW created by the pwTable for which pwOwner equals genFecSignaling. Nadeau & Zelig Standards Track [Page 44] RFC 5601 PW MIB July 2009 Implementers need to be aware that if the combined value of pwGenFecIndexMappingAGI, pwGenFecIndexMappingLocalAII, and pwGenFecIndexMappingRemoteAII (OIDs) has more than 113 sub-identifiers, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { pwGenFecIndexMappingAGIType, pwGenFecIndexMappingAGI, pwGenFecIndexMappingLocalAIIType, pwGenFecIndexMappingLocalAII, pwGenFecIndexMappingRemoteAIIType, pwGenFecIndexMappingRemoteAII } ::= { pwGenFecIndexMappingTable 1 } PwGenFecIndexMappingEntry ::= SEQUENCE { pwGenFecIndexMappingAGIType PwGenIdType, pwGenFecIndexMappingAGI PwAttachmentIdentifierType, pwGenFecIndexMappingLocalAIIType PwGenIdType, pwGenFecIndexMappingLocalAII PwAttachmentIdentifierType, pwGenFecIndexMappingRemoteAIIType PwGenIdType, pwGenFecIndexMappingRemoteAII PwAttachmentIdentifierType, pwGenFecIndexMappingPwIndex PwIndexType } pwGenFecIndexMappingAGIType OBJECT-TYPE SYNTAX PwGenIdType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is the type of the attachment group identifier (AGI) that this PW belongs to." ::= { pwGenFecIndexMappingEntry 1 } pwGenFecIndexMappingAGI OBJECT-TYPE SYNTAX PwAttachmentIdentifierType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an octet string representing the attachment group identifier (AGI) that this PW belongs to, which typically identifies the VPN ID." ::= { pwGenFecIndexMappingEntry 2 } pwGenFecIndexMappingLocalAIIType OBJECT-TYPE SYNTAX PwGenIdType MAX-ACCESS not-accessible STATUS current Nadeau & Zelig Standards Track [Page 45] RFC 5601 PW MIB July 2009 DESCRIPTION "This object is the type of the local forwarder attachment individual identifier (AII) to be used by this PW." ::= { pwGenFecIndexMappingEntry 3 } pwGenFecIndexMappingLocalAII OBJECT-TYPE SYNTAX PwAttachmentIdentifierType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an octet string representing the local forwarder attachment individual identifier (AII) to be used by this PW. It is used as the SAII for outgoing signaling messages and the TAII in the incoming messages from the peer." ::= { pwGenFecIndexMappingEntry 4 } pwGenFecIndexMappingRemoteAIIType OBJECT-TYPE SYNTAX PwGenIdType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is the type of the remote forwarder attachment individual identifier (AII) to be used by this PW." ::= { pwGenFecIndexMappingEntry 5 } pwGenFecIndexMappingRemoteAII OBJECT-TYPE SYNTAX PwAttachmentIdentifierType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is an octet string representing the peer forwarder attachment individual identifier (AII) to be used by this PW. It is used as the TAII for outgoing signaling messages and the SAII in the incoming messages from the peer." ::= { pwGenFecIndexMappingEntry 6 } pwGenFecIndexMappingPwIndex OBJECT-TYPE SYNTAX PwIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "The value that represents the PW in the pwTable." ::= { pwGenFecIndexMappingEntry 7 } Nadeau & Zelig Standards Track [Page 46] RFC 5601 PW MIB July 2009 -- End of the Gen Fec PW ID mapping table -- Notifications - PW pwDown NOTIFICATION-TYPE OBJECTS { pwOperStatus, --start of range pwOperStatus --end of range } STATUS current DESCRIPTION "This notification is generated when the pwOperStatus object for one or more contiguous entries in the pwTable are about to enter the down(2) or lowerLayerDown(6) state from any other state, except for transition from the notPresent(5) state. For the purpose of deciding when these notifications occur, the lowerLayerDown(6) state and the down(2) state are considered to be equivalent; i.e., there is no notification on transition from lowerLayerDown(6) into down(2), and there is a trap on transition from any other state except down(2) (and notPresent) into lowerLayerDown(6). The included values of pwOperStatus MUST each be equal to down(2) or lowerLayerDown(6). The two instances of pwOperStatus in this notification indicate the range of indexes that are affected. Note that all the indexes of the two ends of the range can be derived from the instance identifiers of these two objects. For cases where a contiguous range of cross-connects have transitioned into the down(2) and lowerLayerDown(6) states at roughly the same time, the device SHOULD issue a single notification for each range of contiguous indexes in an effort to minimize the emission of a large number of notifications. If a notification has to be issued for just a single cross-connect entry, then the instance identifier (and values) of the two pwOperStatus objects MUST be identical." ::= { pwNotifications 1 } pwUp NOTIFICATION-TYPE OBJECTS { pwOperStatus, --start of range pwOperStatus --end of range } STATUS current DESCRIPTION "This notification is generated when the pwOperStatus object for one or more contiguous entries in the pwTable are about to enter the up(1) state from some other state Nadeau & Zelig Standards Track [Page 47] RFC 5601 PW MIB July 2009 except the notPresent(5) state and given that the pwDown notification been issued for these entries. The included values of pwOperStatus MUST both be set equal to this new state (i.e., up(1)). The two instances of pwOperStatus in this notification indicate the range of indexes that are affected. Note that all the indexes of the two ends of the range can be derived from the instance identifiers of these two objects. For cases where a contiguous range of cross-connects have transitioned into the up(1) state at roughly the same time, the device SHOULD issue a single notification for each range of contiguous indexes in an effort to minimize the emission of a large number of notifications. If a notification has to be issued for just a single cross-connect entry, then the instance identifier (and values) of the two pwOperStatus objects MUST be identical." ::= { pwNotifications 2 } pwDeleted NOTIFICATION-TYPE OBJECTS { pwType, pwID, pwPeerAddrType, pwPeerAddr } STATUS current DESCRIPTION "This notification is generated when the PW has been deleted, i.e., when the pwRowStatus has been set to destroy(6) or the PW has been deleted by a non-MIB application or due to an auto-discovery process. " ::= { pwNotifications 3 } -- End of notifications. -- Conformance information pwGroups OBJECT IDENTIFIER ::= { pwConformance 1 } pwCompliances OBJECT IDENTIFIER ::= { pwConformance 2 } -- Compliance requirement for fully compliant implementations pwModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that provide full support for the PW MIB module. Such devices can then be monitored and configured using Nadeau & Zelig Standards Track [Page 48] RFC 5601 PW MIB July 2009 this MIB module." MODULE -- this module MANDATORY-GROUPS { pwBasicGroup, pwPerformanceGeneralGroup } GROUP pwNotificationGroup DESCRIPTION "This group is only mandatory for implementations that can efficiently implement the notifications contained in this group. " GROUP pwPwIdGroup DESCRIPTION "This group is only mandatory for implementations that support the PW ID FEC. " GROUP pwGeneralizedFecGroup DESCRIPTION "This group is only mandatory for implementations that support the generalized PW FEC. " GROUP pwFcsGroup DESCRIPTION "This group is only mandatory for implementations that support FCS retention." GROUP pwFragGroup DESCRIPTION "This group is only mandatory for implementations that support PW fragmentation. " GROUP pwPwStatusGroup DESCRIPTION "This group is only mandatory for implementations that support PW status notification. " GROUP pwGetNextGroup DESCRIPTION "This group is only mandatory for implementations where the pwIndex may be any arbitrary value and the EMS would require retrieval of the next free index." GROUP pwPriorityGroup DESCRIPTION "This group is only mandatory for implementations that support the controlling the PW setup and holding priority." Nadeau & Zelig Standards Track [Page 49] RFC 5601 PW MIB July 2009 GROUP pwAttachmentGroup DESCRIPTION "This group is only mandatory for implementations that support attachment of two PWs (PW stitching)." GROUP pwPeformance1DayIntervalGroup DESCRIPTION "This group is only mandatory for implementations that support PW performance gathering in 1-day intervals." GROUP pwPerformanceIntervalGeneralGroup DESCRIPTION "This group is only mandatory for implementations that support PW performance gathering in 15- minute intervals." GROUP pwPeformanceIntervalGroup DESCRIPTION "This group is only mandatory for implementations that support PW performance gathering in 15- minute intervals." GROUP pwHCPeformanceIntervalGroup DESCRIPTION "This group is only mandatory for implementations where at least one of the interval performance counters wraps around too quickly based on the criteria specified in RFC 2863 for high-capacity counters." GROUP pwMappingTablesGroup DESCRIPTION "This group is only mandatory for implementations that support reverse mapping of PW indexes to the pwIndex and the peer mapping table." GROUP pwSignalingGroup DESCRIPTION "This group is only mandatory for implementations that support the PW signaling." GROUP pwNotificationControlGroup DESCRIPTION "This group is only mandatory for implementations that support the PW notifications." OBJECT pwAdminStatus SYNTAX INTEGER { up(1), down(2) } DESCRIPTION "Support of the value testing(3) is not required." OBJECT pwOperStatus SYNTAX INTEGER { up(1), down(2), notPresent(5), lowerLayerDown(6) } DESCRIPTION "Support of the values testing(3) and dormant(4) Nadeau & Zelig Standards Track [Page 50] RFC 5601 PW MIB July 2009 is not required." OBJECT pwRowStatus SYNTAX RowStatus { active(1), notInService(2), notReady(3) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait is not required. Support of notReady is not required for implementations that do not support signaling, or if it is guaranteed that the conceptual row has all the required information to create the PW when the row has been created by the agent or written by the operator." OBJECT pwPeerAddrType SYNTAX InetAddressType { unknown(0), ipv4(1) } MIN-ACCESS read-only DESCRIPTION "Only unknown(0) and ipv4(1) are required. Implementations that support only IPv4 MAY support read-only access." OBJECT pwPeerAddr SYNTAX InetAddress (SIZE(0|4)) DESCRIPTION "An implementation is only required to support 0, 4 address sizes." OBJECT pwStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwNotifRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { pwCompliances 1 } -- Compliance requirement for read-only compliant implementations pwModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that provide read- only support for the PW MIB module. Such devices can then be monitored but cannot be configured using this MIB module." Nadeau & Zelig Standards Track [Page 51] RFC 5601 PW MIB July 2009 MODULE -- this module MANDATORY-GROUPS { pwBasicGroup } GROUP pwNotificationGroup DESCRIPTION "This group is only mandatory for implementations that can efficiently implement the notifications contained in this group." GROUP pwPwIdGroup DESCRIPTION "This group is only mandatory for implementations that support the PW ID FEC. " GROUP pwGeneralizedFecGroup DESCRIPTION "This group is only mandatory for implementations that support the generalized PW FEC. " GROUP pwFcsGroup DESCRIPTION "This group is only mandatory for implementations that support FCS retention." GROUP pwFragGroup DESCRIPTION "This group is only mandatory for implementations that support PW fragmentation. " GROUP pwPwStatusGroup DESCRIPTION "This group is only mandatory for implementations that support PW status notification. " GROUP pwGetNextGroup DESCRIPTION "This group is only mandatory for implementations where the pwIndex may be any arbitrary value and the EMS would require retrieval of the next free index." GROUP pwPriorityGroup DESCRIPTION "This group is only mandatory for implementations that support the controlling the PW setup and holding priority." GROUP pwAttachmentGroup DESCRIPTION "This group is only mandatory for implementations that support attachment of two PWs (PW stitching)." Nadeau & Zelig Standards Track [Page 52] RFC 5601 PW MIB July 2009 GROUP pwPeformance1DayIntervalGroup DESCRIPTION "This group is only mandatory for implementations that support PW performance gathering in 1-day intervals." GROUP pwPerformanceIntervalGeneralGroup DESCRIPTION "This group is only mandatory for implementations that support PW performance gathering in 15- minute intervals." GROUP pwPeformanceIntervalGroup DESCRIPTION "This group is only mandatory for implementations that support PW performance gathering in 15- minute intervals." GROUP pwHCPeformanceIntervalGroup DESCRIPTION "This group is only mandatory for implementations where at least one of the interval performance counters wraps around too quickly based on the criteria specified in RFC 2863 for high-capacity counters." GROUP pwMappingTablesGroup DESCRIPTION "This group is only mandatory for implementations that support reverse mapping of PW indexes to the pwIndex and the peer mapping table." GROUP pwSignalingGroup DESCRIPTION "This group is only mandatory for implementations that support the PW signaling." GROUP pwNotificationControlGroup DESCRIPTION "This group is only mandatory for implementations that support the PW notifications." OBJECT pwType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwOwner MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwPsnType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwSetUpPriority Nadeau & Zelig Standards Track [Page 53] RFC 5601 PW MIB July 2009 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwHoldingPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwPeerAddrType SYNTAX InetAddressType { unknown(0), ipv4(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only unknown(0) and ipv4(1) are required." OBJECT pwPeerAddr SYNTAX InetAddress (SIZE(0|4)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is only required to support 0, 4 address sizes." OBJECT pwAttachedPwIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwLocalGroupID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwGroupAttachmentID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwLocalAttachmentID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwRemoteAttachmentID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwCwPreference Nadeau & Zelig Standards Track [Page 54] RFC 5601 PW MIB July 2009 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwLocalIfMtu MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwLocalIfString MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwLocalCapabAdvert MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwFragmentCfgSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwFcsRetentionCfg MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwOutboundLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwInboundLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwAdminStatus SYNTAX INTEGER { up(1), down(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. The support of value testing(3) is not required." OBJECT pwOperStatus SYNTAX INTEGER { up(1), down(2), notPresent(5), lowerLayerDown(6) } Nadeau & Zelig Standards Track [Page 55] RFC 5601 PW MIB July 2009 DESCRIPTION "The support of the values testing(3) and dormant(4) is not required." OBJECT pwRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwOamEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwGenAGIType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwGenLocalAIIType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwGenRemoteAIIType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwUpDownNotifEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwDeletedNotifEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwNotifRate MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { pwCompliances 2 } -- Units of conformance. pwBasicGroup OBJECT-GROUP OBJECTS { pwType, pwOwner, Nadeau & Zelig Standards Track [Page 56] RFC 5601 PW MIB July 2009 pwPsnType, pwIfIndex, pwCwPreference, pwLocalIfMtu, pwOutboundLabel, pwInboundLabel, pwName, pwDescr, pwCreateTime, pwUpTime, pwLastChange, pwAdminStatus, pwOperStatus, pwLocalStatus, pwRowStatus, pwStorageType, pwOamEnable } STATUS current DESCRIPTION "Collection of objects that are required in all implementations that support the PW MIB module." ::= { pwGroups 1 } pwPwIdGroup OBJECT-GROUP OBJECTS { pwID } STATUS current DESCRIPTION "Collection of objects required for PW ID configuration and signaling." ::= { pwGroups 2 } pwGeneralizedFecGroup OBJECT-GROUP OBJECTS { pwGroupAttachmentID, pwLocalAttachmentID, pwRemoteAttachmentID, pwGenAGIType, pwGenLocalAIIType, pwGenRemoteAIIType } STATUS current DESCRIPTION "Collection of objects required for generalized FEC Nadeau & Zelig Standards Track [Page 57] RFC 5601 PW MIB July 2009 configuration and signaling." ::= { pwGroups 3 } pwFcsGroup OBJECT-GROUP OBJECTS { pwFcsRetentionCfg, pwFcsRetentionStatus } STATUS current DESCRIPTION "Collection of objects required for FCS retention configuration and signaling." ::= { pwGroups 4 } pwFragGroup OBJECT-GROUP OBJECTS { pwFragmentCfgSize, pwRmtFragCapability } STATUS current DESCRIPTION "Collection of objects required for fragmentation configuration and signaling." ::= { pwGroups 5 } pwPwStatusGroup OBJECT-GROUP OBJECTS { pwRemoteCapabilities, pwRemoteStatusCapable, pwRemoteStatus } STATUS current DESCRIPTION "Collection of objects required for PW status configuration and signaling." ::= { pwGroups 6 } pwGetNextGroup OBJECT-GROUP OBJECTS { pwIndexNext } STATUS current DESCRIPTION "Collection of objects for getting the next available Nadeau & Zelig Standards Track [Page 58] RFC 5601 PW MIB July 2009 index." ::= { pwGroups 7 } pwPriorityGroup OBJECT-GROUP OBJECTS { pwSetUpPriority, pwHoldingPriority } STATUS current DESCRIPTION "Collection of objects for controlling the PW setup and holding priority." ::= { pwGroups 8 } pwAttachmentGroup OBJECT-GROUP OBJECTS { pwAttachedPwIndex } STATUS current DESCRIPTION "Collection of objects for PW configuration as ifIndex." ::= { pwGroups 9 } pwPerformanceGeneralGroup OBJECT-GROUP OBJECTS { pwPerfTotalErrorPackets } STATUS current DESCRIPTION "Collection of general objects needed for managing the total running performance parameters." ::= { pwGroups 10 } pwPeformance1DayIntervalGroup OBJECT-GROUP OBJECTS { pwPerf1DayIntervalValidData, pwPerf1DayIntervalTimeElapsed, pwPerf1DayIntervalInHCPackets, pwPerf1DayIntervalInHCBytes, pwPerf1DayIntervalOutHCPackets, pwPerf1DayIntervalOutHCBytes } STATUS current DESCRIPTION "Collection of objects needed for a PW running 1-day Nadeau & Zelig Standards Track [Page 59] RFC 5601 PW MIB July 2009 interval performance collection." ::= { pwGroups 11 } pwPerformanceIntervalGeneralGroup OBJECT-GROUP OBJECTS { pwTimeElapsed, pwValidIntervals, pwPerfIntervalValidData, pwPerfIntervalTimeElapsed } STATUS current DESCRIPTION "Collection of general objects needed for managing the interval performance parameters." ::= { pwGroups 12 } pwPeformanceIntervalGroup OBJECT-GROUP OBJECTS { pwPerfCurrentInPackets, pwPerfCurrentInBytes, pwPerfCurrentOutPackets, pwPerfCurrentOutBytes, pwPerfIntervalInPackets, pwPerfIntervalInBytes, pwPerfIntervalOutPackets, pwPerfIntervalOutBytes } STATUS current DESCRIPTION "Collection of 32-bit objects needed for PW performance collection in 15-minute intervals." ::= { pwGroups 13 } pwHCPeformanceIntervalGroup OBJECT-GROUP OBJECTS { pwPerfCurrentInHCPackets, pwPerfCurrentInHCBytes, pwPerfCurrentOutHCPackets, pwPerfCurrentOutHCBytes, pwPerfIntervalInHCPackets, pwPerfIntervalInHCBytes, pwPerfIntervalOutHCPackets, pwPerfIntervalOutHCBytes } Nadeau & Zelig Standards Track [Page 60] RFC 5601 PW MIB July 2009 STATUS current DESCRIPTION "Collection of HC objects needed for PW performance collection in 15-minute intervals." ::= { pwGroups 14 } pwMappingTablesGroup OBJECT-GROUP OBJECTS { pwIndexMappingPwIndex, pwPeerMappingPwIndex, pwGenFecIndexMappingPwIndex } STATUS current DESCRIPTION "Collection of objects contained in the reverse mapping tables." ::= { pwGroups 15 } pwNotificationControlGroup OBJECT-GROUP OBJECTS { pwUpDownNotifEnable, pwDeletedNotifEnable, pwNotifRate } STATUS current DESCRIPTION "Collection of objects for controlling the PW notifications." ::= { pwGroups 16 } pwNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pwUp, pwDown, pwDeleted } STATUS current DESCRIPTION "Collection of PW notifications objects." ::= { pwGroups 17 } pwSignalingGroup OBJECT-GROUP OBJECTS { pwPeerAddrType, pwPeerAddr, Nadeau & Zelig Standards Track [Page 61] RFC 5601 PW MIB July 2009 pwLocalGroupID, pwLocalIfString, pwLocalCapabAdvert, pwRemoteGroupID, pwCwStatus, pwRemoteIfMtu, pwRemoteIfString } STATUS current DESCRIPTION "Collection of objects for use in implementations that support the PW signaling." ::= { pwGroups 18 } END 13. Security Considerations It is clear that this MIB module is potentially useful for monitoring PW-capable PEs. This MIB module can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the pwTable contains objects to configure PW parameters on a Provider Edge (PE) device. Unauthorized access to objects in this table could result in disruption of traffic on the network. The objects pwUpDownNotifEnable and pwNotifRate control the reports from the network element to the EMS. Unauthorized access to these objects could result in disruption of configuration and status change reporting, resulting mis-view of the network conditions. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent that implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Nadeau & Zelig Standards Track [Page 62] RFC 5601 PW MIB July 2009 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the pwTable, pwPerfCurrentTable, pwPerfIntervalTable, pwPerf1DayIntervalTable, pwIndexMappingTable, pwPeerMappingTable, and pwGenFecIndexMappingTable collectively show the pseudowire connectivity topology and its performance characteristics. If an administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 14. IANA Considerations 14.1. ifType for PW IANA has assigned a value (246) for PW in the IANAifType-MIB called ifPwType. 14.2. PW MIB Modules OBJECT IDENTIFIER Values A PW may appear as ifIndex in the ifTable, and therefore the pwStdMIB OBJECT IDENTIFIER has been assigned under the 'transmission' subtree, as the common practice in assigning OBJECT IDENTIFIERs for MIB modules representing entities in the ifTable. Nadeau & Zelig Standards Track [Page 63] RFC 5601 PW MIB July 2009 All other MIB modules related to PW management SHOULD be assigned under the 'mib-2' subtree; individual requests will appear in the MIB module memo's IANA Considerations section. 14.3. IANA Considerations for PW-STD-MIB The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pwStdMIB { transmission 246 } 14.4. IANA Considerations for IANA-PWE3-MIB The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- ianaPwe3MIB { mib-2 174 } 15. Acknowledgments We thank Orly Nicklass for her dedicated review and significant edit in various sections of the document, and Kiran Koushik for his contribution. The individuals listed below contributed significantly to this document: Dave Danenberg - Litchfield Communications Sharon Mantin - Corrigent Systems 16. References 16.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Nadeau & Zelig Standards Track [Page 64] RFC 5601 PW MIB July 2009 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3593] Tesink, K., Ed., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, February 2004. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006. Nadeau & Zelig Standards Track [Page 65] RFC 5601 PW MIB July 2009 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC 4720, November 2006. [RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", RFC 4863, May 2007. [RFC5542] Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., "Definitions of Textual Conventions for Pseudowires (PW) Management", RFC 5542, May 2009. 16.2. Informative References [CEPMIB] Zelig, D., Ed., Cohen, R., Ed., and T. Nadeau, Ed., "SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2", Work in Progress, January 2008. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5602] Zelig, D., Ed., and T. Nadeau, Ed., "Pseudowire (PW) over MPLS PSN Management Information Base (MIB)", RFC 5602, July 2009. Nadeau & Zelig Standards Track [Page 66] RFC 5601 PW MIB July 2009 Authors' Addresses Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom EMail: tom.nadeau@bt.com David Zelig (editor) Oversi Networks 1 Rishon Letzion St. Petah Tikva Israel Phone: +972 77 3337 750 EMail: davidz@oversi.com Nadeau & Zelig Standards Track [Page 67] snmp-mibs-downloader-1.1/mibrfcs/rfc5602.txt0000644000000000000000000017106511402176072015571 0ustar Network Working Group D. Zelig, Ed. Request for Comments: 5602 Oversi Category: Standards Track T. Nadeau, Ed. BT July 2009 Pseudowire (PW) over MPLS PSN Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Zelig & Nadeau Standards Track [Page 1] RFC 5602 PW MPLS MIB July 2009 Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Terminology .....................................................3 4. Overview ........................................................3 5. Features Checklist ..............................................4 6. MIB Module Usage ................................................5 7. PW-MPLS-STD-MIB Example .........................................7 8. Object Definitions ..............................................8 9. Security Considerations ........................................28 10. IANA Considerations ...........................................29 11. References ....................................................29 11.1. Normative References .....................................29 11.2. Informative References ...................................30 1. Introduction This document describes a model for managing pseudowire services for transmission over different flavors of MPLS tunnels. The general PW MIB module [RFC5601] defines the parameters global to the PW regardless of the underlying Packet Switched Network (PSN) and emulated service. This document is applicable for PWs that use MPLS PSN type in the PW-STD-MIB. This document describes the MIB objects that define pseudowire association to the MPLS PSN, in a way that is not specific to the carried service. Together, [RFC3811] and [RFC3812] describe the modeling of an MPLS tunnel, and a tunnel's underlying cross-connects. This MIB module supports MPLS-TE PSN, non-TE MPLS PSN (an outer tunnel created by the Label Distribution Protocol (LDP) or manually), and MPLS PW label only (no outer tunnel). 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB Zelig & Nadeau Standards Track [Page 2] RFC 5602 PW MPLS MIB July 2009 module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Terminology This document uses terminology from the document describing the PW architecture [RFC3985], [RFC3916], and [RFC4447]. The terms "outbound" and "inbound" in this MIB module are based on the common practice in the MPLS standards; i.e. "outbound" is toward the PSN. However, where these terms are used in an object name, the object description clarifies the exact packet direction to prevent confusion with these terms in other documents. "PSN tunnel" is a general term indicating a virtual connection between the two Pseudowire Emulation Edge-to-Edge (PWE3) edge devices. Each tunnel may potentially carry multiple PWs inside. An MPLS tunnel is within the scope of this document. This document uses terminology from the document describing the MPLS architecture [RFC3031] for MPLS PSN. A Label Switched Path (LSP) is modeled as described in [RFC3811] and [RFC3812] via a series of cross-connects through one or more Label Switching Routers (LSRs). In MPLS PSN, a PW connection typically uses a PW label within a tunnel label [RFC4447]. Multiple pseudowires each with a unique PW label can share the same tunnel. For PW transport over MPLS, the tunnel label is known as the "outer" label, while the PW label is known as the "inner" label. An exception to this is with adjacent LSRs or the use of a Penultimate Hop Popping (PHP). In this case, there is an option for PWs to connect directly without an outer label. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. 4. Overview The MIB module structure for defining a PW service consists of three layers of MIB modules functioning together. This general model is defined in the PWE3 architecture [RFC3985]. The layering model is intended to sufficiently isolate PW services from the underlying PSN layer that carries the emulated service. This is done at the same time as providing a standard means for connecting any supported services to any supported PSNs. Zelig & Nadeau Standards Track [Page 3] RFC 5602 PW MPLS MIB July 2009 The first layer, known as the service layer, contains service- specific modules. These modules define service-specific management objects that interface or collaborate with existing MIB modules for the native version of the service. The service-specific module "glues" the standard modules to the PWE3 MIB modules. The next layer of the PWE3 MIB structure is the PW MIB module [RFC5601]. This module is used to configure general parameters of PWs that are common to all types of emulated services and PSNs. This layer is connected to the service-specific layer above and the PSN layer below. The PSN layer provides PSN-specific modules for each type of PSN. These modules associate the PW with one or more "tunnels" that carry the service over the PSN. These modules are used to "glue" the PW service to the underlying PSN-specific MIB modules. This document defines the MIB module for PW over MPLS PSN. [RFC5542] defines some of the object types used in these modules. 5. Features Checklist The PW-MPLS-STD-MIB module is designed to satisfy the following requirements and constraints: - The MIB module supports both manually configured and signaled PWs. - The MIB module supports point-to-point PW connections. - The MIB module enables the use of any emulated service. - The MIB module supports MPLS-TE outer tunnel, non-TE MPLS outer tunnel (an outer tunnel signaled by LDP or set up manually), and no outer tunnel (where the PW label is the only label in the MPLS stack). The latter case is applicable for manual configuration of PW over a single hop, as for signaled MPLS PSN even across a single hop there is an MPLS tunnel -- even though the actual packet may not contain the MPLS tunnel label due to PHP. The MIB module uses Textual Conventions (TCs) from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3811], [RFC3813], [RFC5542], and [RFC5601]. Zelig & Nadeau Standards Track [Page 4] RFC 5602 PW MPLS MIB July 2009 6. MIB Module Usage - The PW table (pwTable) in [RFC5601] is used for all PW types (ATM, FR, Ethernet, SONET, etc.). This table contains high-level generic parameters related to the PW creation. The operator or the agent creates a row for each PW. - If the selected PSN type in the pwTable is MPLS, the agent creates a row in the MPLS-specific parameters table (pwMplsTable) in this module, which contains MPLS-specific parameters such as EXP bits handling and outer tunnel configuration. - The operator configures the association to the desired MPLS tunnel (required for MPLS-TE tunnels or for manually configured PWs) through the pwMplsTeOutboundTable. For the LDP-based outer tunnel, there is no need for manual configuration since there is only a single tunnel toward the peer. - The agent creates rows in the MPLS mapping table in order to allow quick retrieval of information based on the tunnel indexes. The relation to the MPLS network is by configuration of the edge LSR only -- i.e., the LSR that provides the PW function. Since tunnels are unidirectional, a pair of tunnels MUST exist (one for inbound, one for outbound). Figure 1 depicts a PW that originates and terminates at LSR-M. It uses tunnels A and B formed by cross- connects (XCs) Ax and Bx continuing through LSR-N to LSR-P. The concatenations of XCs create the tunnels. Note: 'X' denotes a tunnel's cross-connect. Zelig & Nadeau Standards Track [Page 5] RFC 5602 PW MPLS MIB July 2009 Tunnel A <- - - - - - - - - - - - - - - - - - - - - - - - - - - - +---- (edge) LSR-M ---+ +--------- LSR-N ---------+ + LSR-P |---+ | | | | | | XC | | XC | | + | A1 (M<-N) +----+ +----+ A2 (M<-P) +----+ +----+ | | <------| | | |<--------------| | | | <-->| N |PWin inSeg |MPLS| |MPLS| outSeg inSeg |MPLS| |MPLS| N S | | <---X<-----| IF | | IF |<------X<------| IF | | IF | A E | S | | |<-->| | | |<-->| | | T R | | --->X----->| | | |------>X------>| | | | I V | P |PWout outSeg| | | | inSeg outSeg | | | | V I | | ------>| | | |-------------->| | | | E C + | XC +----+ +----+ XC +----+ +----+ E |---+ B1 (M->N) | | B2 (M->P) | | | | | | | +---------------------+ +-------------------------+ +----- - - - - - - - - - - - - - - - - - - - - - - - - - - - -> Tunnel B Figure 1: PW modeling over MPLS The PW-MPLS-STD-MIB supports three options for an MPLS network: (1) In the MPLS-TE case, tunnels A and B are created via the MPLS- TE-STD-MIB [RFC3812]. The tunnels are associated (in each peer independently) to the PW by the four indexes that uniquely identify the tunnel at the MPLS-TE-STD-MIB. (2) In the non-TE case, tunnels A1 and B1 are either manually configured or set up with LDP. The tunnels are associated to the PW by the XC index in the MPLS-LSR-STD-MIB [RFC3813]. (3) In the PW-label-only case, there is no outer tunnel on top of the PW label. This case is useful in the case of adjacent Provider Edges (PEs) in manual configuration mode. Note that for signaled tunnels, when LSR-N acts as PHP for the outer tunnel label, there are still entries for the outer tunnel in the relevant MPLS MIB modules, so even for the case of adjacent LSRs, the relevant mode is either MPLS-TE or non-TE. A combination of MPLS-TE outer tunnel(s) and LDP outer tunnel for the same PW is allowed through the pwMplsOutboundTunnel. The current tunnel that is used to forward traffic is indicated in the object pwMplsOutboundTunnelTypeInUse. Zelig & Nadeau Standards Track [Page 6] RFC 5602 PW MPLS MIB July 2009 The PW-MPLS-STD-MIB module reports through the inbound table the XC entry in the LDP-STD-MIB [RFC3815] of the PW that was signaled through LDP. This MIB module assumes that a PW can be associated to one MPLS-TE tunnel at a time. This tunnel may be composed of multiple instances (i.e., LSP), each represented by a separate instance index. The selection of the active LSP out of the possible LSPs in the tunnel is out of the scope of this MIB module as it is part of the MPLS PSN functionality. The current active LSP is reported through this MIB module. It is important to note that inbound (tunnel originated in the remote PE) mapping is not configured or reported through the PW-MPLS-STD- MIB module since the local PE does not know the inbound association between specific PW and MPLS tunnels. 7. PW-MPLS-STD-MIB Example The following example (supplement the example provided in [RFC5601]) assumes that the node has already established the LDP tunnel to the peer node and that a PW has been configured in the pwTable in [RFC5601] with pwPsnType equal 'mpls'. The agent creates an entry in pwMplsTable with the following parameters: pwMplsMplsType mplsNonTe(1), -- LDP tunnel pwMplsExpBitsMode outerTunnel(1), -- Default pwMplsExpBits 0, -- Default pwMplsTtl 2, -- Default pwMplsLocalLdpID 192.0.2.200:0, pwMplsLocalLdpEntityIndex 1, pwMplsPeerLdpID 192.0.2.5:0, pwMplsStorageType nonVolatile(3) The agent also creates an entry in pwMplsOutboundTable for reporting the mapping of the PW on the LDP tunnel: pwMplsOutboundLsrXcIndex 100, - The XC number for the -- LDP tunnel pwMplsOutboundTunnelIndex 0, -- No TE tunnel pwMplsOutboundTunnelInstance 0, -- No TE tunnel pwMplsOutboundTunnelLclLSR 0, -- No TE tunnel pwMplsOutboundTunnelPeerLSR 0, -- No TE tunnel pwMplsOutboundIfIndex 0, -- Not applicable pwMplsOutboundTunnelTypeInUse mplsNonTe(3) Zelig & Nadeau Standards Track [Page 7] RFC 5602 PW MPLS MIB July 2009 The agent now creates entries for the PW in the following tables: - pwMplsInboundTable - pwMplsNonTeMappingTable (2 entries) To create an MPLS-TE tunnel to carry this PW, the operator takes the following steps: - Set pwMplsMplsType in pwMplsTable to both mplsNonTe(1) and mplsTe(0). - Set pwMplsOutboundTunnelIndex, pwMplsOutboundTunnelInstance, pwMplsOutboundTunnelLclLSR, and pwMplsOutboundTunnelPeerLSR in pwMplsOutboundTable to the MPLS-TE tunnel that will carry this PW. The agent will report the tunnel that the PW is currently using through pwMplsOutboundTunnelTypeInUse, and will report the PW to MPLS-TE tunnel/LSP mapping in pwMplsTeMappingTable. 8. Object Definitions PW-MPLS-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] MplsTunnelIndex, MplsTunnelInstanceIndex, MplsLdpIdentifier, MplsLsrIdentifier FROM MPLS-TC-STD-MIB -- [RFC3811] MplsIndexType FROM MPLS-LSR-STD-MIB -- [RFC3813] PwIndexType FROM PW-TC-STD-MIB -- [RFC5542] Zelig & Nadeau Standards Track [Page 8] RFC 5602 PW MPLS MIB July 2009 pwIndex -- [RFC5601] FROM PW-STD-MIB ; pwMplsStdMIB MODULE-IDENTITY LAST-UPDATED "200906120000Z" -- 12 June 2009 00:00:00 GMT ORGANIZATION "Pseudowire Emulation Edge-to-Edge (PWE3) Working Group." CONTACT-INFO " David Zelig, Editor Email: davidz@corrigent.com Thomas D. Nadeau, Editor Email: tom.nadeau@bt.com The PWE3 Working Group (email distribution pwe3@ietf.org, http://www.ietf.org/html.charters/pwe3-charter.html) " DESCRIPTION "This MIB module complements the PW-STD-MIB module for PW operation over MPLS. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE Zelig & Nadeau Standards Track [Page 9] RFC 5602 PW MPLS MIB July 2009 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5602; see the RFC itself for full legal notices. " -- Revision history. REVISION "200906120000Z" -- 12 June 2009 00:00:00 GMT DESCRIPTION "First published as RFC 5602. " ::= { mib-2 181 } -- Top-level components of this MIB. -- Notifications pwMplsNotifications OBJECT IDENTIFIER ::= { pwMplsStdMIB 0 } -- Tables, Scalars pwMplsObjects OBJECT IDENTIFIER ::= { pwMplsStdMIB 1 } -- Conformance pwMplsConformance OBJECT IDENTIFIER ::= { pwMplsStdMIB 2 } -- PW MPLS table pwMplsTable OBJECT-TYPE SYNTAX SEQUENCE OF PwMplsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table controls MPLS-specific parameters when the PW is going to be carried over MPLS PSN." ::= { pwMplsObjects 1 } pwMplsEntry OBJECT-TYPE SYNTAX PwMplsEntry MAX-ACCESS not-accessible Zelig & Nadeau Standards Track [Page 10] RFC 5602 PW MPLS MIB July 2009 STATUS current DESCRIPTION "A row in this table represents parameters specific to MPLS PSN for a pseudowire (PW). The row is created automatically by the local agent if the pwPsnType is mpls(1). It is indexed by pwIndex, which uniquely identifies a singular PW. Manual entries in this table SHOULD be preserved after a reboot, and the agent MUST ensure the integrity of those entries. If the set of entries of a specific row were found to be nonconsistent after reboot, the PW pwOperStatus MUST be declared as down(2). Any read-write object in this table MAY be changed at any time; however, change of some objects (for example, pwMplsMplsType) during PW forwarding state MAY cause traffic disruption." INDEX { pwIndex } ::= { pwMplsTable 1 } PwMplsEntry ::= SEQUENCE { pwMplsMplsType BITS, pwMplsExpBitsMode INTEGER, pwMplsExpBits Unsigned32, pwMplsTtl Unsigned32, pwMplsLocalLdpID MplsLdpIdentifier, pwMplsLocalLdpEntityIndex Unsigned32, pwMplsPeerLdpID MplsLdpIdentifier, pwMplsStorageType StorageType } pwMplsMplsType OBJECT-TYPE SYNTAX BITS { mplsTe (0), mplsNonTe (1), pwOnly (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is set by the operator to indicate the outer tunnel types, if existing. mplsTe(0) is used if the outer tunnel is set up by MPLS-TE, and mplsNonTe(1) is used if the outer tunnel is set up by LDP or manually. A combination of mplsTe(0) and mplsNonTe(1) MAY exist. pwOnly(2) is used if there is no outer tunnel label, i.e., Zelig & Nadeau Standards Track [Page 11] RFC 5602 PW MPLS MIB July 2009 in static provisioning without an MPLS tunnel. pwOnly(2) cannot be combined with mplsNonTe(1) or mplsTe(0). An implementation that can identify automatically that the peer node is directly connected MAY support the bit pwOnly(2) as read-only. " DEFVAL { { mplsNonTe } } ::= { pwMplsEntry 1 } pwMplsExpBitsMode OBJECT-TYPE SYNTAX INTEGER { outerTunnel (1), specifiedValue (2), serviceDependant (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is set by the operator to determine the PW shim label EXP bits. The value of outerTunnel(1) is used where there is an outer tunnel -- pwMplsMplsType equals to mplsTe(0) or mplsNonTe(1). Note that in this case, there is no need to mark the PW label with the EXP bits, since the PW label is not visible to the intermediate nodes. If there is no outer tunnel, specifiedValue(2) SHOULD be used to indicate that the value is specified by pwMplsExpBits. Setting serviceDependant(3) indicates that the EXP bits are set based on a rule that is implementation specific." DEFVAL { outerTunnel } ::= { pwMplsEntry 2 } pwMplsExpBits OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is set by the operator if pwMplsExpBitsMode is set to specifiedValue(2) to indicate the MPLS EXP bits to be used on the PW shim label. Otherwise, it SHOULD be set to zero." DEFVAL { 0 } ::= { pwMplsEntry 3 } pwMplsTtl OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write Zelig & Nadeau Standards Track [Page 12] RFC 5602 PW MPLS MIB July 2009 STATUS current DESCRIPTION "This object is set by the operator to indicate the PW TTL value to be used on the PW shim label." DEFVAL { 2 } ::= { pwMplsEntry 4 } pwMplsLocalLdpID OBJECT-TYPE SYNTAX MplsLdpIdentifier MAX-ACCESS read-write STATUS current DESCRIPTION "The LDP identifier of the LDP entity that creates this PW in the local node. As the PW labels are always set from the per-platform label space, the last two octets in the LDP ID MUST always both be zeros." REFERENCE "'LDP specifications', RFC 3036, section 2.2.2." ::= { pwMplsEntry 5 } pwMplsLocalLdpEntityIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The local node LDP Entity Index of the LDP entity creating this PW." ::= { pwMplsEntry 6 } pwMplsPeerLdpID OBJECT-TYPE SYNTAX MplsLdpIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The peer LDP identifier of the LDP session. This object SHOULD return the value zero if LDP is not used or if the value is not yet known." ::= { pwMplsEntry 7 } pwMplsStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the storage type for this row." DEFVAL { nonVolatile } ::= { pwMplsEntry 8 } Zelig & Nadeau Standards Track [Page 13] RFC 5602 PW MPLS MIB July 2009 -- End of PW MPLS Table -- Pseudowire MPLS Outbound Tunnel Table pwMplsOutboundTable OBJECT-TYPE SYNTAX SEQUENCE OF PwMplsOutboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table reports and configures the current outbound MPLS tunnels (i.e., toward the PSN) or the physical interface in the case of a PW label only that carries the PW traffic. It also reports the current outer tunnel and LSP that forward the PW traffic." ::= { pwMplsObjects 2 } pwMplsOutboundEntry OBJECT-TYPE SYNTAX PwMplsOutboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table configures the outer tunnel used for carrying the PW traffic toward the PSN. In the case of PW label only, it configures the interface that will carry the PW traffic. An entry in this table augments the pwMplsEntry, and is created automatically when the corresponding row has been created by the agent in the pwMplsEntry. This table points to the appropriate MPLS MIB module: In the MPLS-TE case, the three objects relevant to the indexing of a TE tunnel head-end (as used in the MPLS-TE-STD-MIB) are to be configured, and the tunnel instance indicates the LSP that is currently in use for forwarding the traffic. In the case of signaled non-TE MPLS (an outer tunnel label assigned by LDP), the table points to the XC entry in the LSR-STD-MIB. If the non-TE MPLS tunnel is manually configured, the operator configures the XC pointer to this tunnel. In the case of PW label only (no outer tunnel), the ifIndex of the port to carry the PW is configured here. Zelig & Nadeau Standards Track [Page 14] RFC 5602 PW MPLS MIB July 2009 It is possible to associate a PW to one TE tunnel head-end and a non-TE tunnel together. An indication in this table will report the currently active one. In addition, in the TE case, the table reports the active tunnel instance (i.e., the specific LSP in use). Any read-write object in this table MAY be changed at any time; however, change of some objects (for example, MPLS-TE indexes) during PW forwarding state MAY cause traffic disruption." AUGMENTS { pwMplsEntry } ::= { pwMplsOutboundTable 1 } PwMplsOutboundEntry ::= SEQUENCE { pwMplsOutboundLsrXcIndex MplsIndexType, pwMplsOutboundTunnelIndex MplsTunnelIndex, pwMplsOutboundTunnelInstance MplsTunnelInstanceIndex, pwMplsOutboundTunnelLclLSR MplsLsrIdentifier, pwMplsOutboundTunnelPeerLSR MplsLsrIdentifier, pwMplsOutboundIfIndex InterfaceIndexOrZero, pwMplsOutboundTunnelTypeInUse INTEGER } pwMplsOutboundLsrXcIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS read-write STATUS current DESCRIPTION "This object is applicable if the pwMplsMplsType mplsNonTe(1) bit is set, and MUST return a value of zero otherwise. If the outer tunnel is signaled, the object is read-only and indicates the XC index in the MPLS-LSR-STD-MIB of the outer tunnel toward the peer. Otherwise (tunnel is set up manually), the operator defines the XC index of the manually created outer tunnel through this object. " ::= { pwMplsOutboundEntry 1 } pwMplsOutboundTunnelIndex OBJECT-TYPE SYNTAX MplsTunnelIndex MAX-ACCESS read-write STATUS current DESCRIPTION "This object is applicable if the pwMplsMplsType mplsTe(0) bit is set, and MUST return a value of zero otherwise. It is part of the set of indexes for the outbound tunnel. Zelig & Nadeau Standards Track [Page 15] RFC 5602 PW MPLS MIB July 2009 The operator sets this object to represent the desired tunnel head-end toward the peer for carrying the PW traffic. " ::= { pwMplsOutboundEntry 2 } pwMplsOutboundTunnelInstance OBJECT-TYPE SYNTAX MplsTunnelInstanceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This object is applicable if the pwMplsMplsType mplsTe(0) bit is set, and MUST return a value of zero otherwise. It indicates the actual tunnel instance that is currently active and carrying the PW traffic. It SHOULD return the value zero if the information from the MPLS-TE application is not yet known. " ::= { pwMplsOutboundEntry 3 } pwMplsOutboundTunnelLclLSR OBJECT-TYPE SYNTAX MplsLsrIdentifier MAX-ACCESS read-write STATUS current DESCRIPTION "This object is applicable if the pwMplsMplsType mplsTe(0) bit is set, and MUST return a value of all zeros otherwise. It is part of the set of indexes for the outbound tunnel. The operator sets this object to represent the desired tunnel head-end toward the peer for carrying the PW traffic. " ::= { pwMplsOutboundEntry 4 } pwMplsOutboundTunnelPeerLSR OBJECT-TYPE SYNTAX MplsLsrIdentifier MAX-ACCESS read-write STATUS current DESCRIPTION "This object is applicable if the pwMplsMplsType mplsTe(0) bit is set, and MUST return a value of zero otherwise. It is part of the set of indexes for the outbound tunnel. Note that in most cases, it equals to pwPeerAddr. " ::= { pwMplsOutboundEntry 5 } pwMplsOutboundIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero Zelig & Nadeau Standards Track [Page 16] RFC 5602 PW MPLS MIB July 2009 MAX-ACCESS read-write STATUS current DESCRIPTION "This object is applicable if the pwMplsMplsType pwOnly(0) bit is set, and MUST return a value of zero otherwise. The operator configures the ifIndex of the outbound port in this case. " ::= { pwMplsOutboundEntry 6 } pwMplsOutboundTunnelTypeInUse OBJECT-TYPE SYNTAX INTEGER { notYetKnown (1), mplsTe (2), mplsNonTe (3), pwOnly (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the current tunnel that is carrying the PW traffic. The value of notYetKnown(1) should be used if the agent is currently unable to determine which tunnel or interface is carrying the PW, for example, because both tunnels are in operational status down. " ::= { pwMplsOutboundEntry 7 } -- End of PW MPLS Outbound Tunnel table -- PW MPLS inbound table pwMplsInboundTable OBJECT-TYPE SYNTAX SEQUENCE OF PwMplsInboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table indicates the PW LDP XC entry in the MPLS-LSR-STD-MIB for signaled PWs. " ::= { pwMplsObjects 3 } pwMplsInboundEntry OBJECT-TYPE SYNTAX PwMplsInboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Zelig & Nadeau Standards Track [Page 17] RFC 5602 PW MPLS MIB July 2009 "A row in this table is created by the agent for each signaled PW, and shows the XC index related to the PW signaling in the inbound direction in the MPLS-LSR-STD-MIB that controls and display the information for all the LDP signaling processes in the local node. " INDEX { pwIndex } ::= { pwMplsInboundTable 1 } PwMplsInboundEntry ::= SEQUENCE { pwMplsInboundXcIndex MplsIndexType } pwMplsInboundXcIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "The XC index representing this PW in the inbound direction. It MUST return the value zero if the information is not yet known." ::= { pwMplsInboundEntry 1 } -- End of PW MPLS inbound table -- PW to Non-TE mapping Table. pwMplsNonTeMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwMplsNonTeMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table indicates the PW association to the outbound tunnel in non-TE applications, maps the PW to its (inbound) XC entry, and indicates the PW-to-physical interface mapping for a PW without an outer tunnel. " ::= { pwMplsObjects 4 } pwMplsNonTeMappingEntry OBJECT-TYPE SYNTAX PwMplsNonTeMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table displays the association between the PW and - its non-TE MPLS outbound outer tunnel, Zelig & Nadeau Standards Track [Page 18] RFC 5602 PW MPLS MIB July 2009 - its XC entry in the MPLS-LSR-STD-MIB, or - its physical interface if there is no outer tunnel (PW label only) and manual configuration. Rows are created in this table by the agent depending on the setting of pwMplsMplsType: - If the pwMplsMplsType mplsNonTe(1) bit is set, the agent creates a row for the outbound direction (pwMplsNonTeMappingDirection set to psnBound(1)). The pwMplsNonTeMappingXcIndex holds the XC index in the MPLS-LSR-STD-MIB of the PSN-bound outer tunnel. pwMplsNonTeMappingIfIndex MUST be zero for this row. - If the pwMplsMplsType pwOnly(2) bit is set, the agent creates a row for the outbound direction (pwMplsNonTeMappingDirection set to psnBound(1)). The pwMplsNonTeMappingIfIndex holds the ifIndex of the physical port this PW will use in the outbound direction. pwMplsNonTeMappingXcIndex MUST be zero for this row. - If the PW has been set up by a signaling protocol (i.e., pwOwner equal pwIdFecSignaling(2) or genFecSignaling(3)), the agent creates a row for the inbound direction (pwMplsNonTeMappingDirection set to fromPsn(2)). The pwMplsNonTeMappingXcIndex holds the XC index in the MPLS-LSR-STD-MIB of the PW LDP-generated XC entry. pwMplsNonTeMappingIfIndex MUST be zero for this row. An application can use this table to quickly retrieve the PW carried over specific non-TE MPLS outer tunnel or physical interface. " INDEX { pwMplsNonTeMappingDirection, pwMplsNonTeMappingXcIndex, pwMplsNonTeMappingIfIndex, pwMplsNonTeMappingPwIndex } ::= { pwMplsNonTeMappingTable 1 } PwMplsNonTeMappingEntry ::= SEQUENCE { pwMplsNonTeMappingDirection INTEGER, pwMplsNonTeMappingXcIndex MplsIndexType, pwMplsNonTeMappingIfIndex InterfaceIndexOrZero, pwMplsNonTeMappingPwIndex PwIndexType } Zelig & Nadeau Standards Track [Page 19] RFC 5602 PW MPLS MIB July 2009 pwMplsNonTeMappingDirection OBJECT-TYPE SYNTAX INTEGER { psnBound (1), fromPsn (2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for the conceptual XC row identifying the tunnel-to-PW mappings, indicating the direction of the packet flow for this entry. psnBound(1) indicates that the entry is related to packets toward the PSN. fromPsn(2) indicates that the entry is related to packets coming from the PSN. " ::= { pwMplsNonTeMappingEntry 1 } pwMplsNonTeMappingXcIndex OBJECT-TYPE SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "See the description clause of pwMplsNonTeMappingEntry for the usage guidelines of this object." ::= { pwMplsNonTeMappingEntry 2 } pwMplsNonTeMappingIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "See the description clause of pwMplsNonTeMappingEntry for the usage guidelines of this object." ::= { pwMplsNonTeMappingEntry 3 } pwMplsNonTeMappingPwIndex OBJECT-TYPE SYNTAX PwIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "The value that represents the PW in the pwTable." ::= { pwMplsNonTeMappingEntry 4 } -- End of PW to Non-TE mapping Table. -- PW to TE MPLS tunnels mapping Table. Zelig & Nadeau Standards Track [Page 20] RFC 5602 PW MPLS MIB July 2009 pwMplsTeMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwMplsTeMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table reports the PW association to the outbound MPLS tunnel for MPLS-TE applications." ::= { pwMplsObjects 5 } pwMplsTeMappingEntry OBJECT-TYPE SYNTAX PwMplsTeMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table represents the association between a PW and its MPLS-TE outer (head-end) tunnel. An application can use this table to quickly retrieve the list of the PWs that are configured on a specific MPLS-TE outer tunnel. The pwMplsTeMappingTunnelInstance reports the actual LSP out of the tunnel head-end that is currently forwarding the traffic. The table is indexed by the head-end indexes of a TE tunnel and the PW index. " INDEX { pwMplsTeMappingTunnelIndex, pwMplsTeMappingTunnelInstance, pwMplsTeMappingTunnelPeerLsrID, pwMplsTeMappingTunnelLocalLsrID, pwMplsTeMappingPwIndex } ::= { pwMplsTeMappingTable 1 } PwMplsTeMappingEntry ::= SEQUENCE { pwMplsTeMappingTunnelIndex MplsTunnelIndex, pwMplsTeMappingTunnelInstance MplsTunnelInstanceIndex, pwMplsTeMappingTunnelPeerLsrID MplsLsrIdentifier, pwMplsTeMappingTunnelLocalLsrID MplsLsrIdentifier, pwMplsTeMappingPwIndex PwIndexType } Zelig & Nadeau Standards Track [Page 21] RFC 5602 PW MPLS MIB July 2009 pwMplsTeMappingTunnelIndex OBJECT-TYPE SYNTAX MplsTunnelIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Primary index for the conceptual row identifying the MPLS-TE tunnel that is carrying the PW traffic." ::= { pwMplsTeMappingEntry 1 } pwMplsTeMappingTunnelInstance OBJECT-TYPE SYNTAX MplsTunnelInstanceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the MPLS-TE LSP that is carrying the PW traffic. It MUST return the value zero if the information of the specific LSP is not yet known. Note that based on the recommendation in the MPLS-TC-STD-MIB, instance index 0 should refer to the configured tunnel interface." ::= { pwMplsTeMappingEntry 2 } pwMplsTeMappingTunnelPeerLsrID OBJECT-TYPE SYNTAX MplsLsrIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the peer LSR when the outer tunnel is MPLS-TE." ::= { pwMplsTeMappingEntry 3 } pwMplsTeMappingTunnelLocalLsrID OBJECT-TYPE SYNTAX MplsLsrIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies the local LSR." ::= { pwMplsTeMappingEntry 4 } pwMplsTeMappingPwIndex OBJECT-TYPE SYNTAX PwIndexType MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the value that represents the PW in the pwTable." ::= { pwMplsTeMappingEntry 5 } Zelig & Nadeau Standards Track [Page 22] RFC 5602 PW MPLS MIB July 2009 -- End of PW to TE MPLS tunnels mapping Table. -- conformance information pwMplsGroups OBJECT IDENTIFIER ::= { pwMplsConformance 1 } pwMplsCompliances OBJECT IDENTIFIER ::= { pwMplsConformance 2 } -- Compliance requirement for fully compliant implementations. pwMplsModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that provide full support for the PW-MPLS-STD-MIB module. Such devices can then be monitored and also be configured using this MIB module." MODULE -- this module MANDATORY-GROUPS { pwMplsGroup, pwMplsOutboundMainGroup, pwMplsInboundGroup, pwMplsMappingGroup } GROUP pwMplsOutboundTeGroup DESCRIPTION "This group MUST be supported if the implementation allows MPLS-TE tunnels to carry PW traffic. " OBJECT pwMplsMplsType DESCRIPTION "Support of pwOnly(2) is not required. At least one of mplsTe(0) or mplsNonTe(1) MUST be supported if signaling of PW is supported. " OBJECT pwMplsExpBitsMode DESCRIPTION "Support of specifiedValue(2) and serviceDependant(3) is optional. " OBJECT pwMplsLocalLdpID MIN-ACCESS read-only DESCRIPTION "A read-write access is required if the implementation supports more than one LDP entity identifier for PW signaling. " OBJECT pwMplsLocalLdpEntityIndex Zelig & Nadeau Standards Track [Page 23] RFC 5602 PW MPLS MIB July 2009 MIN-ACCESS read-only DESCRIPTION "A read-write access is required if the implementation supports more than one LDP entity index for PW signaling. " OBJECT pwMplsOutboundLsrXcIndex MIN-ACCESS read-only DESCRIPTION "A value other than zero MUST be supported if the implementation supports non-TE signaling of the outer tunnel. A read-write access MUST be supported if the implementation supports PW label manual setting and carrying them over non-TE tunnels. " OBJECT pwMplsOutboundIfIndex MIN-ACCESS read-only DESCRIPTION "A value other than zero and read-write operations MUST be supported if the implementation supports manually configured PW without MPLS outer tunnel. " ::= { pwMplsCompliances 1 } -- Compliance requirement for Read Only compliant implementations. pwMplsModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that provide read- only support for the PW-MPLS-STD-MIB module. Such devices can then be monitored but cannot be configured using this MIB module." MODULE -- this module MANDATORY-GROUPS { pwMplsGroup, pwMplsOutboundMainGroup, pwMplsInboundGroup, pwMplsMappingGroup } GROUP pwMplsOutboundTeGroup DESCRIPTION "This group MUST be supported if the implementation allows MPLS-TE tunnels to carry PW traffic. " OBJECT pwMplsMplsType MIN-ACCESS read-only Zelig & Nadeau Standards Track [Page 24] RFC 5602 PW MPLS MIB July 2009 DESCRIPTION "Write access is not required. Support of pwOnly(2) is not required. At least one of mplsTe(0) or mplsNonTe(1) MUST be supported if signaling of PW is supported. " OBJECT pwMplsExpBitsMode MIN-ACCESS read-only DESCRIPTION "Write access is not required. Support of specifiedValue(2) and serviceDependant(3) is optional. " OBJECT pwMplsExpBits MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT pwMplsTtl MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT pwMplsLocalLdpID MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT pwMplsLocalLdpEntityIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT pwMplsStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT pwMplsOutboundLsrXcIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. A value other than zero MUST be supported if the implementation supports non-TE signaling of the outer tunnel. " OBJECT pwMplsOutboundTunnelIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. " Zelig & Nadeau Standards Track [Page 25] RFC 5602 PW MPLS MIB July 2009 OBJECT pwMplsOutboundTunnelLclLSR MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT pwMplsOutboundTunnelPeerLSR MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT pwMplsOutboundIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. A value other than zero MUST be supported if the implementation supports manually configured PW without MPLS outer tunnel. " ::= { pwMplsCompliances 2 } -- Units of conformance. pwMplsGroup OBJECT-GROUP OBJECTS { pwMplsMplsType, pwMplsExpBitsMode, pwMplsExpBits, pwMplsTtl, pwMplsLocalLdpID, pwMplsLocalLdpEntityIndex, pwMplsPeerLdpID, pwMplsStorageType } STATUS current DESCRIPTION "Collection of objects needed for PW over MPLS PSN configuration." ::= { pwMplsGroups 1 } pwMplsOutboundMainGroup OBJECT-GROUP OBJECTS { pwMplsOutboundLsrXcIndex, pwMplsOutboundIfIndex, pwMplsOutboundTunnelTypeInUse } STATUS current DESCRIPTION Zelig & Nadeau Standards Track [Page 26] RFC 5602 PW MPLS MIB July 2009 "Collection of objects needed for outbound association of PW and MPLS tunnel." ::= { pwMplsGroups 2 } pwMplsOutboundTeGroup OBJECT-GROUP OBJECTS { pwMplsOutboundTunnelIndex, pwMplsOutboundTunnelInstance, pwMplsOutboundTunnelLclLSR, pwMplsOutboundTunnelPeerLSR } STATUS current DESCRIPTION "Collection of objects needed for outbound association of PW and MPLS-TE tunnel." ::= { pwMplsGroups 3 } pwMplsInboundGroup OBJECT-GROUP OBJECTS { pwMplsInboundXcIndex } STATUS current DESCRIPTION "Collection of objects needed for inbound PW presentation. This group MUST be supported if PW signaling through LDP is used." ::= { pwMplsGroups 4 } pwMplsMappingGroup OBJECT-GROUP OBJECTS { pwMplsNonTeMappingPwIndex, pwMplsTeMappingPwIndex } STATUS current DESCRIPTION "Collection of objects needed for mapping association of PW and MPLS tunnel." ::= { pwMplsGroups 5 } END Zelig & Nadeau Standards Track [Page 27] RFC 5602 PW MPLS MIB July 2009 9. Security Considerations It is clear that this MIB module is potentially useful for monitoring PW-capable PEs. This MIB module can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the pwMplsTable, pwMplsNonTeMappingTable and pwMplsTeMappingTable collectively contain objects to provision PW over MPLS tunnels. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the pwMplsTable, pwMplsNonTeMappingTable, pwMplsTeMappingTable and pwMplsOutboundTable collectively show the PW over MPLS association. If an Administrator does not want to reveal this information, then these tables should be considered sensitive/ vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Zelig & Nadeau Standards Track [Page 28] RFC 5602 PW MPLS MIB July 2009 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pwMplsStdMIB { mib-2 181 } 11. References 11.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. Zelig & Nadeau Standards Track [Page 29] RFC 5602 PW MPLS MIB July 2009 [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5542] Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., "Definitions of Textual Conventions for Pseudowire (PW) Management", RFC 5542, May 2009. [RFC5601] Nadeau, T., Ed. and D. Zelig, Ed. "Pseudowire (PW) Management Information Base (MIB)", RFC 5601, July 2009. 11.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004. [RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. Zelig & Nadeau Standards Track [Page 30] RFC 5602 PW MPLS MIB July 2009 Authors' Addresses David Zelig (editor) Oversi Networks 1 Rishon Letzion St. Petah Tikva Israel Phone: +972 77 3337 750 EMail: davidz@oversi.com Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom EMail: tom.nadeau@bt.com Zelig & Nadeau Standards Track [Page 31] snmp-mibs-downloader-1.1/mibrfcs/rfc5603.txt0000644000000000000000000012613511402176072015570 0ustar Network Working Group D. Zelig, Ed. Request for Comments: 5603 Oversi Category: Standards Track T. Nadeau, Ed. BT July 2009 Ethernet Pseudowire (PW) Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Zelig & Nadeau Standards Track [Page 1] RFC 5603 ENET MIB July 2009 Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Conventions .....................................................3 4. Overview ........................................................3 5. Feature Checklist ...............................................4 6. PW ENET MIB Module Usage ........................................4 7. PW-ENET Management Model ........................................5 8. Example of the PW-ENET MIB Module Usage .........................6 9. Service-Delimiting Modes ........................................6 10. Object Definitions .............................................9 11. Security Considerations .......................................19 12. IANA Considerations ...........................................21 13. References ....................................................21 13.1. Normative References .....................................21 13.2. Informative References ...................................22 14. Acknowledgments ...............................................22 1. Introduction This document describes a model for managing Ethernet pseudowire services for transmission over a Packet Switched Network (PSN). This MIB module is generic and common to all types of PSNs supported in the Pseudowire Emulation Edge-to-Edge (PWE3) architecture [RFC3985], which describes the transport and encapsulation of L1 and L2 services over supported PSN types. In particular, the MIB module associates a port or specific VLANs on top of a physical Ethernet port or a virtual Ethernet interface (for Virtual Private LAN Service (VPLS)) to a point-to-point PW. It is complementary to the PW-STD-MIB [RFC5601], which manages the generic PW parameters common to all services, including all supported PSN types. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module Zelig & Nadeau Standards Track [Page 2] RFC 5603 ENET MIB July 2009 that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. This document adopts the definitions, acronyms, and mechanisms described in [RFC3985] and [RFC3916]. Unless otherwise stated, the mechanisms of [RFC3985] apply and will not be re-described here. 4. Overview The MIB module structure for defining a PW service is composed of three layers of MIB modules functioning together. This general model is defined in the PWE3 architecture [RFC3985]. The layering model is intended to sufficiently isolate PW services from the underlying PSN layer that carries the emulated service. This is done at the same time as providing a standard means for connecting any supported services to any supported PSNs. The first layer, known as the service layer, contains service- specific modules. These modules define service-specific management objects that interface or collaborate with existing MIB modules for the native version of the service. The service-specific module "glues" the standard modules to the PWE3 MIB modules. The next layer of the PWE3 MIB framework is the PW MIB module [RFC5601]. This module is used to configure general parameters of PWs that are common to all types of emulated services and PSNs. This layer is connected to the service-specific layer above and the PSN layer below. The PSN layer provides PSN-specific modules for each type of PSN. These modules associate the PW with one or more "tunnels" that carry the service over the PSN. These modules are used to "glue" the PW service to the underlying PSN-specific MIB modules. This document defines the MIB module for Ethernet PW over any PSN type. This module uses Textual Conventions (TCs) and objects as defined in [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC4363], [RFC4502], and [RFC5601]. Zelig & Nadeau Standards Track [Page 3] RFC 5603 ENET MIB July 2009 The Etherlike-MIB [RFC3635] does not support virtual Ethernet ports; however, it is sometimes desired to manage the PW as an Ethernet port via the Etherlike-MIB. This MIB module supports an option to recognize the PW as an ifIndex, enabling standard use of the Etherlike-MIB to manage the PW. 5. Feature Checklist The PW Ethernet MIB module (PW-ENET-STD-MIB) is designed to satisfy the following requirements and constraints: - The MIB module is designed to work with the PW-STD-MIB [RFC5601]. - The MIB module is agnostic to the PSN type. - The MIB module supports various options for selecting Ethernet packets into the PW, as defined in [RFC4448]. These include port-based PW, VLAN-based PW, and VLAN-manipulated based (change, add, or remove) between the port to be emulated and the PW. - In the case of an MPLS PSN, the MIB module supports the use of multiple PWs to carry the same Ethernet service. These PWs can be used to support Label-Only-Inferred-PSC LSPs (L-LSPs) or EXP- Inferred-PSC LSPs (E-LSPs) that are from a single Class of Service (CoS), when mapping of the Ethernet user priority (PRI) bits to the PSN CoS is required. - The MIB module enables both point-to-point Ethernet services and VPLS services as discussed in the L2VPN working group [RFC4664]. - The MIB module allows modeling of the PW as an Ethernet virtual port to be managed via existing Ethernet MIBs like Etherlike-MIB [RFC3635]. 6. PW ENET MIB Module Usage - The PW table (pwTable) is used for all PW types (ATM, FR, Ethernet, SONET, etc.). This table contains high-level generic parameters related to the PW creation. A row is typically created by the operator (see [RFC5542] for other options) for each PW service. - Based on the PSN type defined for the PW, rows are created in the PSN-specific module (for example, [RFC5602]) and associated to the pwTable by the common pwIndex. - If the PW type is Ethernet or EthernetTagged a row is created by the agent in the pwEnetTable. Zelig & Nadeau Standards Track [Page 4] RFC 5603 ENET MIB July 2009 7. PW-ENET Management Model The management model for the Ethernet PW is shown in Figure 1, and is based on the PW layering [RFC3985]. +--------------------------------------+ | PE Device | +--------------------------------------+ Single | | | AC | | Single | PW Instance <------>o Forwarder + PW Instance X<=========> | | | +--------------------------------------+ ^ | May be modeled as ifIndex Notation: o A physical CE-bound PE port. + A PW IWF instance interface to the forwarder. X A PE PSN-bound port. Figure 1: A simple point-to-point service In the typical point-to-point service, the object pwEnetPortIfIndex associates the physical CE-bound PE port ('o') to the PW (it is allowed to have multiple PWs associated to the same physical port). This MIB module also manages some of the possible operations of the forwarder. In some models, it is convenient to model the forwarder virtual interface to a PW IWF instance ('+') as an ifIndex. As discussed in [RFC5601], this is possible by using the PW ifType in the ifTable and indicating the ifIndex in the main pwTable. In case of Ethernet PW, a virtual interface of ifType = etherLike will be assigned on top of the PW interface to enable statistics gathering and statuses and other management configuration tasks via existing tools. This way, the PW instance is managed as virtual Ethernet interface in the PE. The model for using the PW in non-point-to-point applications, such as VPLS, is done with the same principle in mind, except that the creation of the tables is related typically to an auto-discovery process. Zelig & Nadeau Standards Track [Page 5] RFC 5603 ENET MIB July 2009 8. Example of the PW-ENET MIB Module Usage Assume we would like to create a PW of type VLAN between two PEs, for VLAN value 5. - Follows the example in [RFC5601], with pwType equals 'ethernetTagged'. - The agent creates a row in the pwEnetTable and a row in the pwEnetStatsTable for the specified pwIndex. The pwEnetPwInstance is automatically set by the agent to the value of 1. - The operator fills the following entries in the pwEnetTable: pwEnetPwVlan 5, pwEnetVlanMode noChange, pwEnetPortVlan 5, pwEnetPortIfIndex 1001, pwEnetPwIfIndex 0, -- Not managed in the -- Etherlike MIB module ... - The PW is ready for forwarding when signaling has been accomplished successfully between the two peers. 9. Service-Delimiting Modes This section describes how the MIB module supports point-to-point applications with various VLAN service-delimiting options on the original Ethernet port and the corresponding PW mode and VLAN values. If the PW is attached to VPLS service, the PW is associated to a virtual interface that is attached to a bridge or VPLS forwarder. The bridging function between local physical ports and virtual interfaces that are later associated to PWs is not handled via this MIB module. Zelig & Nadeau Standards Track [Page 6] RFC 5603 ENET MIB July 2009 There are three main service types that are supported by this MIB module: (1) Port mode: In this mode, the whole traffic from the port is mapped to the PW. A. In the typical application, the packet is sent to the PW as is: pwEnetPwVlan 4095, pwEnetVlanMode portMode, pwEnetPortVlan 4095, pwType Ethernet, B. It is possible to add a provider tag (value 10, for example) to the packet when it is sent over the PW: pwEnetPwVlan 10, pwEnetVlanMode addVlan, pwEnetPortVlan 4095, pwType SHOULD be set to 'EthernetTagged'. (2) Single VLAN: In this mode, only the first VLAN field on the packet from the physical port is the service-delimiting tag, as an example VLAN=5. The following options of processing are possible: A. One-to-one mapping: The service-delimiting tag is kept as is on the PW. pwEnetPwVlan 5, pwEnetVlanMode noChange, pwEnetPortVlan 5, pwType SHOULD be set to 'EthernetTagged'. B. VLAN change mapping: The service-delimiting tag changes its value (to the value of 6) on the PW. pwEnetPwVlan 6, pwEnetVlanMode changeVlan, pwEnetPortVlan 5, pwType SHOULD be set to 'EthernetTagged'. Zelig & Nadeau Standards Track [Page 7] RFC 5603 ENET MIB July 2009 C. The service-delimiting tag is removed when the packet is sent to the PW. pwEnetPwVlan 4095, pwEnetVlanMode removeVlan, pwEnetPortVlan 5, pwType SHOULD be set to 'EthernetTagged'. It should be noted that this mode is also applicable when the service-delimiting tag is a service provider tag (VLAN=5 in this case), and the node removes this VLAN and maps the traffic to a single PW independent of the packet format on top of this VLAN. D. Untagged packets mapped to a PW as is (packets with a VLAN field from the same port MAY be mapped to other PWs). pwEnetPwVlan 0, pwEnetVlanMode noChange, pwEnetPortVlan 0, pwType MAY equal 'Ethernet' or 'EthernetTagged'. E. Untagged packets mapped to a PW, and a VLAN field is added to the packet. pwEnetPwVlan 6, pwEnetVlanMode addVlan, pwEnetPortVlan 0, pwType SHOULD be set to 'EthernetTagged'. F. A provider VLAN (value 10) is added to packets arriving with VLAN value 5 before they are sent to the PW. pwEnetPwVlan 10, pwEnetVlanMode addVlan, pwEnetPortVlan 5, pwType SHOULD be set to 'EthernetTagged'. (3) Nested VLAN (QinQ): When only the first VLAN is the service- delimiting tag, one of the modes as described in 2) SHOULD be used. If the service-delimiting tag is both the first VLAN and the second VLAN, the following option is supported by this MIB module: Zelig & Nadeau Standards Track [Page 8] RFC 5603 ENET MIB July 2009 Assuming the provider VLAN tag equals 5 and the user VLAN tag equal 100, this traffic can be mapped to the PW without the provider tag by using the following configuration: pwEnetPwVlan 100, pwEnetVlanMode removeVLAN, pwEnetPortVlan 5, It is RECOMMENDED that the pwType would equal 'EthernetTagged', but pwType equal to 'Ethernet' MAY be used as well. Packets with the same provider tag MAY be mapped to other PWs. (4) Other scenarios are considered out of scope and should be handled by other MIB modules that manage the forwarder and the Native Service Processing (NSP) sections. 10. Object Definitions PW-ENET-STD-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] StorageType, RowStatus FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] ZeroBasedCounter32 FROM RMON2-MIB -- [RFC4502] pwIndex FROM PW-STD-MIB -- [RFC5601] VlanIdOrAnyOrNone FROM Q-BRIDGE-MIB; -- [RFC4363] pwEnetStdMIB MODULE-IDENTITY LAST-UPDATED "200906150000Z" -- 15 June 2009 00:00:00 GMT ORGANIZATION "Pseudowire Edge-to-Edge Emulation (PWE3) Working Group" Zelig & Nadeau Standards Track [Page 9] RFC 5603 ENET MIB July 2009 CONTACT-INFO "David Zelig Email: davidz@oversi.com Thomas D. Nadeau Email: tom.nadeau@bt.com " DESCRIPTION "This MIB module describes a model for managing Ethernet point-to-point pseudowire services over a Packet Switched Network (PSN). Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5603; Zelig & Nadeau Standards Track [Page 10] RFC 5603 ENET MIB July 2009 see the RFC itself for full legal notices." -- Revision history REVISION "200906150000Z" -- 15 June 2009 00:00:00 GMT DESCRIPTION "Initial version published as part of RFC 5603." ::= { mib-2 180 } pwEnetObjects OBJECT IDENTIFIER ::= { pwEnetStdMIB 1 } pwEnetConformance OBJECT IDENTIFIER ::= { pwEnetStdMIB 2 } -- -- Ethernet PW table -- pwEnetTable OBJECT-TYPE SYNTAX SEQUENCE OF PwEnetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the index to the Ethernet tables associated with this Ethernet PW, the VLAN configuration, and the VLAN mode." ::= { pwEnetObjects 1 } pwEnetEntry OBJECT-TYPE SYNTAX PwEnetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the same index that was created for the associated entry in the PW generic table in the PW-STD-MIB module. The pwIndex and the pwEnetPwInstance are used as indexes to allow multiple VLANs to exist on the same PW. An entry is created in this table by the agent for every entry in the pwTable with a pwType of 'ethernetTagged' or 'ethernet'. Additional rows may be created by the operator or the agent if multiple entries are required for the same PW. The value of pwEnetPwInstance can be arbitrarily selected to make the row unique; however, implementations that know the VLAN field value when the row is created MAY use the value of the VLAN itself for better readability and backward compatibility with older versions of this MIB Zelig & Nadeau Standards Track [Page 11] RFC 5603 ENET MIB July 2009 module. This table provides Ethernet port mapping and VLAN configuration for each Ethernet PW. All read-create objects in this table MAY be changed at any time; however, change of some objects (for example, pwEnetVlanMode) during the PW forwarding state MAY cause traffic disruption. Manual entries in this table SHOULD be preserved after a reboot, and the agent MUST ensure the integrity of those entries. If the set of entries of a specific row is found to be inconsistent after reboot, the PW pwOperStatus MUST be declared as notPresent(5). " INDEX { pwIndex, pwEnetPwInstance } ::= { pwEnetTable 1 } PwEnetEntry ::= SEQUENCE { pwEnetPwInstance Unsigned32, pwEnetPwVlan VlanIdOrAnyOrNone, pwEnetVlanMode INTEGER, pwEnetPortVlan VlanIdOrAnyOrNone, pwEnetPortIfIndex InterfaceIndexOrZero, pwEnetPwIfIndex InterfaceIndexOrZero, pwEnetRowStatus RowStatus, pwEnetStorageType StorageType } pwEnetPwInstance OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "If multiple rows are mapped to the same PW, this index is used to uniquely identify the individual row. If the value of the VLAN field is known at the time of row creation, the value of pwEnetPwVlan MAY be used for better readability and backward compatibility with older versions of this MIB module. Otherwise, the value 1 SHOULD be set to the first row for each pwIndex for better readability and in order that the management application will know in advance how to access the first row when it was created by the agent. Zelig & Nadeau Standards Track [Page 12] RFC 5603 ENET MIB July 2009 " ::= { pwEnetEntry 1 } pwEnetPwVlan OBJECT-TYPE SYNTAX VlanIdOrAnyOrNone MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines the (service-delimiting) VLAN field value on the PW. The value 4095 MUST be used if the object is not applicable, for example, when mapping all packets from an Ethernet port to this PW (raw mode). The value 0 MUST be set to indicate untagged frames (from the PW point of view), i.e., when pwEnetVlanMode equals 'noChange' and pwEnetPortVlan equals 0." ::= { pwEnetEntry 2 } pwEnetVlanMode OBJECT-TYPE SYNTAX INTEGER { other(0), portBased(1), noChange(2), changeVlan(3), addVlan(4), removeVlan(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the mode of VLAN handling between the port or the virtual port associated with the PW and the PW encapsulation. - 'other' indicates an operation that is not defined by this MIB module. - 'portBased' indicates that the forwarder will forward packets between the port and the PW independent of their structure (i.e., there are no service-delimiting VLAN tags from the PE standpoint). - 'noChange' indicates that the PW contains the original user VLAN, as specified in pwEnetPortVlan; i.e., the VLAN on the PE-CE link is the service-delimiting tag and is kept 'as is' on the PW. - 'changeVlan' indicates that the VLAN field on the PW may be different than the VLAN field on the user's Zelig & Nadeau Standards Track [Page 13] RFC 5603 ENET MIB July 2009 port. The VLAN on the PE-CE link is the service-delimiting tag but has a different value on the PW. - 'addVlan' indicates that a VLAN field will be added on the PSN-bound direction (i.e., on the PW). pwEnetPwVlan indicates the value that will be added. - 'removeVlan' indicates that the encapsulation on the PW does not include the service-delimiting VLAN field. Note that PRI bits transparency is lost in this case. - Implementation of 'portsbased', 'removeVlan', 'addVlan' 'other', and 'changeVlan' is OPTIONAL. " DEFVAL { noChange } ::= { pwEnetEntry 3 } pwEnetPortVlan OBJECT-TYPE SYNTAX VlanIdOrAnyOrNone MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines if the mapping between the original port (physical port or VPLS virtual port) to the PW is VLAN based or not. In case of VLAN mapping, this object indicates the VLAN value on the original port. The value of '4095' MUST be used if the whole original port traffic is mapped to the same PW. Note that a pwType of 'ethernetTagged' can still be used if service-delimiting tag is added on the PW (pwEnetVlanMode equals 'addVlan'). This object MUST be equal to pwEnetPwVlan if pwEnetVlanMode equals 'noChange'. The value 0 indicates that packets without a VLAN field (i.e., untagged frames) on the port are associated to this PW. This allows the same behavior as assigning 'Default VLAN' to untagged frames. " DEFVAL { 4095 } ::= { pwEnetEntry 4 } pwEnetPortIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION Zelig & Nadeau Standards Track [Page 14] RFC 5603 ENET MIB July 2009 "This object is used to specify the ifIndex of the Ethernet port associated with this PW for point-to-point Ethernet service, or the ifIndex of the virtual interface of the VPLS instance associated with the PW if the service is VPLS. Two rows in this table can point to the same ifIndex only if there is no overlap of VLAN values specified in pwEnetPortVlan that are associated with this port. A value of zero indicates that association to an ifIndex is not yet known." ::= { pwEnetEntry 5 } pwEnetPwIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "If the PW is modeled as an ifIndex in the ifTable, this object indicates the value of the ifIndex representing the Ethernet PW on the PSN side in the Etherlike-MIB. Note that this value may be different from the value of pwIfIndex that represents the ifIndex of the PW for ifType 'pw'." DEFVAL { 0 } ::= { pwEnetEntry 6 } pwEnetRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object enables creating, deleting, and modifying this row." ::= { pwEnetEntry 7 } pwEnetStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the storage type of this row." DEFVAL { nonVolatile } ::= { pwEnetEntry 8 } -- -- Ethernet PW Statistics Table -- Zelig & Nadeau Standards Track [Page 15] RFC 5603 ENET MIB July 2009 pwEnetStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PwEnetStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistical counters specific for Ethernet PW." ::= { pwEnetObjects 2 } pwEnetStatsEntry OBJECT-TYPE SYNTAX PwEnetStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry represents the statistics gathered for the PW carrying the Ethernet." INDEX { pwIndex } ::= { pwEnetStatsTable 1 } PwEnetStatsEntry ::= SEQUENCE { pwEnetStatsIllegalVlan ZeroBasedCounter32, pwEnetStatsIllegalLength ZeroBasedCounter32 } pwEnetStatsIllegalVlan OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received (from the PSN) on this PW with either an illegal VLAN field, a missing VLAN field when one was expected, or an excessive VLAN field when it was not expected. This counter may not be applicable in some cases, and MUST return the value of zero in such a case." ::= { pwEnetStatsEntry 1 } pwEnetStatsIllegalLength OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that were received with an illegal Ethernet packet length on this PW. An illegal length is defined as being greater than the value in the advertised MTU supported, or shorter than the allowed Ethernet packet size." Zelig & Nadeau Standards Track [Page 16] RFC 5603 ENET MIB July 2009 ::= { pwEnetStatsEntry 2 } --- --- Conformance description --- pwEnetGroups OBJECT IDENTIFIER ::= { pwEnetConformance 1 } pwEnetCompliances OBJECT IDENTIFIER ::= { pwEnetConformance 2 } -- Compliance requirement for fully compliant implementations pwEnetModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that provides full support for the PW-ENET-STD-MIB module. Such devices can then be monitored and also be configured using this MIB module." MODULE -- this module MANDATORY-GROUPS { pwEnetGroup, pwEnetStatsGroup } OBJECT pwEnetVlanMode DESCRIPTION "An implementation MUST support at least the value noChange(2)." OBJECT pwEnetPwIfIndex MIN-ACCESS read-only DESCRIPTION "Write access and values other than zero are required only for implementations that support modeling the Ethernet PW in the Etherlike-MIB." OBJECT pwEnetRowStatus SYNTAX RowStatus { active(1), notInService(2), notReady(3) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } MIN-ACCESS read-only DESCRIPTION "Support for createAndWait is not required. Support of notReady is not required for implementations that do not support signaling. Support of read-write is not required for implementations that do not support more than one VLAN mapping to the same PW." ::= { pwEnetCompliances 1 } Zelig & Nadeau Standards Track [Page 17] RFC 5603 ENET MIB July 2009 -- Compliance requirement for read-only compliant implementations pwEnetModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that provide read- only support for the PW-ENET-STD-MIB module. Such devices can then be monitored but cannot be configured using this MIB module." MODULE -- this module MANDATORY-GROUPS { pwEnetGroup, pwEnetStatsGroup } OBJECT pwEnetPwVlan MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwEnetVlanMode MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation MUST support at least the value noChange(2)." OBJECT pwEnetPortVlan MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwEnetPortIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pwEnetPwIfIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required. Values other than zero are required only for implementations that support modeling the Ethernet PW in the Etherlike-MIB." OBJECT pwEnetRowStatus SYNTAX RowStatus { active(1), notInService(2), notReady(3) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. Support of notReady is not required for implementations that do not support signaling." OBJECT pwEnetStorageType Zelig & Nadeau Standards Track [Page 18] RFC 5603 ENET MIB July 2009 MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { pwEnetCompliances 2 } -- Units of conformance pwEnetGroup OBJECT-GROUP OBJECTS { pwEnetPwVlan, pwEnetVlanMode, pwEnetPortVlan, pwEnetPortIfIndex, pwEnetPwIfIndex, pwEnetRowStatus, pwEnetStorageType } STATUS current DESCRIPTION "Collection of objects for basic Ethernet PW configuration." ::= { pwEnetGroups 1 } pwEnetStatsGroup OBJECT-GROUP OBJECTS { pwEnetStatsIllegalVlan, pwEnetStatsIllegalLength } STATUS current DESCRIPTION "Collection of objects counting various PW level errors." ::= { pwEnetGroups 2 } END 11. Security Considerations It is clear that this MIB module is potentially useful for monitoring of PW-capable PEs. This MIB module can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Zelig & Nadeau Standards Track [Page 19] RFC 5603 ENET MIB July 2009 o the pwEnetTable contains objects to provision Ethernet PWs. Unauthorized access to objects in these tables could result in disruption of traffic on the network. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent that implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the pwEnetTable shows the Ethernet PW service configuration. If an administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Zelig & Nadeau Standards Track [Page 20] RFC 5603 ENET MIB July 2009 12. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pwEnetStdMIB { mib-2 180 } 13. References 13.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003. [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", RFC 4363, January 2006. Zelig & Nadeau Standards Track [Page 21] RFC 5603 ENET MIB July 2009 [RFC5601] Zelig, D., Ed., and T. Nadeau, Ed., "Pseudowire (PW) Management Information Base (MIB)", RFC 5601, July 2009. 13.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC5542] Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., "Definitions of Textual Conventions for Pseudowires (PW) Management", RFC 5542, May 2009. [RFC5602] Zelig, D., Ed., and T. Nadeau, Ed., "Pseudowire (PW) over MPLS PSN Management Information Base (MIB)", RFC 5602, July 2009. 14. Acknowledgments This document was produced by the PWE3 Working Group. Special thanks to Orly Nicklass for close review and good suggestions. Zelig & Nadeau Standards Track [Page 22] RFC 5603 ENET MIB July 2009 Authors' Addresses David Zelig (editor) Oversi Networks 1 Rishon Letzion St. Petah Tikva Israel Phone: +972 77 3337 750 EMail: davidz@oversi.com Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom EMail: tom.nadeau@bt.com Zelig & Nadeau Standards Track [Page 23] snmp-mibs-downloader-1.1/mibrfcs/rfc5604.txt0000644000000000000000000023420211402176072015564 0ustar Network Working Group O. Nicklass Request for Comments: 5604 RADVISION Ltd. Category: Standards Track July 2009 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Nicklass Standards Track [Page 1] RFC 5604 Manage TDM over PSN July 2009 Table of Contents 1. Introduction ....................................................2 2. Conventions .....................................................3 3. Terminology .....................................................3 4. The Internet-Standard Management Framework ......................4 5. Overview ........................................................4 6. TDM MIB Module Usage ............................................4 6.1. Structure of TDM MIB .......................................4 6.2. TDM Connection Configuration Procedure .....................5 6.3. TDM PW Monitoring ..........................................6 7. Example of Actual TDM PW Setup ..................................6 8. Object Definition ...............................................9 9. Security Considerations ........................................37 10. IANA Considerations ...........................................39 11. References ....................................................39 11.1. Normative References .....................................39 11.2. Informative References ...................................40 12. Acknowledgements ..............................................41 1. Introduction This document describes a model for managing TDM pseudowires, i.e., TDM data encapsulated for transmission over a Packet Switched Network (PSN). The term TDM in this document is limited to the scope of Plesiochronous Digital Hierarchy (PDH). It is currently specified to carry any TDM Signals in either Structure Agnostic Transport mode (E1, T1, E3, and T3) or in Structure Aware Transport mode (E1, T1, and NxDS0) as defined in the Pseudowire Emulation Edge-to-Edge (PWE3) TDM Requirements document [RFC4197]. This document is closely related to [SATOP], [TDMOIP], and [CESOPSN], which describe the encapsulation of TDM signals and provide the Circuit Emulation Service over a PSN. The TDM management model consists of several MIB modules, following the layering model described in the PWE3 Architecture document [RFC3985]. The TDM MIB module described in this document works closely with the MIB modules described in [DS3MIB], [DS1MIB], [DS0MIB], [IFMIB], [PWMIB], and with the textual conventions defined in [PWTC]. The conceptual layering and relationship among all those is described in Figure 1 below. A TDM connection will be a pseudowire (PW) connection. It will not be treated as an interface and will therefore not be represented in the ifTable. Nicklass Standards Track [Page 2] RFC 5604 Manage TDM over PSN July 2009 Figure 1: Conceptual Layering +-------------------+ | TDM MIB | DS1MIB, DS3MIB, +-------------------+ DS0MIB | +-------------------+ PW-TDM-MIB, Service | TDM PW MIB | PW-CESOPSN-MIB, Layer +-------------------+ PW-TDMOIP-MIB - - - - - - - - - - - | - - - - - - - - - - - - - - - Generic +-------------------+ PW | Generic PW MIBS | PW-TC-MIB, Layer +-------------------+ PW-MIB - - - - - - - - - - - -| - - - - - - - - - - - - - - - +-------------------+ PSN VC | MPLS VC MIBS | PW-MPLS-MIB Layer +-------------------+ - - - - - - - - - - - -| - - - - - - - - - - - - - - - +-------------------+ PSN | MPLS MIBs | MPLS-TE-STD-MIB, Layer +-------------------+ MPLS-LSR-STD-MIB 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. 3. Terminology The basic terminology used to refer to transmission direction in this document is taken from [SATOP], which describes a mechanism for transporting Structure-Agnostic (TDM) bit-streams over a packet- oriented network. To simplify this document, the terminology is used for structured and unstructured TDM as well. "PSN-bound" references the traffic direction where TDM data is received, adapted to the packet based on the number of payload bytes per packet, assigned a relevant TDM header (sequence numbers, flags, and timestamps (if the RTP header is used)), prepended multiplexing layer and PSN headers, and sent into the PSN. Conversely, the "CE-bound" references the traffic direction where packets are received from the PSN, packet payloads are reassembled by including a jitter buffer where payload of the received TDM packets Nicklass Standards Track [Page 3] RFC 5604 Manage TDM over PSN July 2009 is stored prior to play out to the TDM line. The size of this buffer SHOULD be locally configurable to allow accommodation to the PSN- specific packet delay variation. The CE-bound TDM interworking function (IWF) SHOULD use the sequence number in the control word for the detection of lost (Loss of Packet State (LOPS)) and mis-ordered packets. If the RTP header is used, the RTP sequence numbers MAY be used for the same purposes. 4. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 5. Overview This MIB module is designed to satisfy the following requirements and constraints: 1. Fit within the architecture defined by [RFC3985] and [PWMIB]. 2. Support edge-to-edge emulation of any TDM connections. 3. Configure the connection. The connection-specific behavior is provided via the supplement MIB modules. 4. Report various alarms, counters, and status objects. 6. TDM MIB Module Usage 6.1. Structure of TDM MIB The MIB consists of five tables; - The TDM PW Table (pwTDMTable) contains generic TDM information regarding the PW connection. It contains the ifIndex of the TDM interface, an index to an entry in the generic configuration table Nicklass Standards Track [Page 4] RFC 5604 Manage TDM over PSN July 2009 (pwTDMCfgTable), an index to an entry in the specific configuration table (pwCXXXCfgTable, where XXX can be TDMoIP (TDM over IP) or CESoPSN (Circuit Emulation Service over PSN)), config error indications, and various status indications. The two indices of the two configuration tables are providing the connection parameters. The TDM interface can be a full link of any TDM type like E1 or DS3, for example, or the interface of the bundle holding the collection of time slots to be transmitted. Based on the TDM PW type, the relevant pwXXXCfgTable from the relevant MIB module will be used. The specific types are: o 17 Structure-agnostic E1 over Packet o 18 Structure-agnostic T1 (DS1) over Packet o 19 Structure-agnostic E3 over Packet o 20 Structure-agnostic T3 (DS3) over Packet o 21 CESoPSN basic mode (XXX=CESoPSN) o 22 TDMoIP AAL1mode (XXX=TDMoIP) o 23 CESoPSN TDM with CAS (XXX=CESoPSN) o 24 TDMoIP AAL2 Mode (XXX=TDMoIP) - The TDM Generic Parameter Table (pwTDMCfgTable) contains TDM generic configurable parameters for any TDM type. - The TDM Performance Current Table (pwTDMPerfCurrentTable) contains TDM statistics for the current 15-minute period. - The TDM Performance Interval Table (pwTDMPerfIntervalTable) contains TDM statistics for historical intervals (usually 96 15- minute entries to cover a 24 hour period). - The TDM Performance One-Day Interval Table (pwTDMPerf1DayIntervalTable) contains TDM statistics for historical intervals accumulated per day. Usually 30 one-day entries to cover a monthly period. 6.2. TDM Connection Configuration Procedure Configuring a TDM PW involves the following steps: First, configure the parameters of the interface-specific layer using the DS1-MIB and or the DS3-MIB. Nicklass Standards Track [Page 5] RFC 5604 Manage TDM over PSN July 2009 Next, if applicable, create a bundle of time slots using the DS0 Bundle MIB [DS0MIB]. Next, create an entry in the pwTable and configure the PSN tunnels: - Follow steps as defined in [PWMIB]. NOTE: The agent should create an entry in the pwTDMTable for any entry created in the pwTable with pwType equal to a value between (17) and (24). Next complete the TDM PW configuration: - If necessary, create an entry in the relevant pwXXXCfgTable and in the pwTDMTable (suitable entries may already exist in both tables). - Set the index of the relevant pwXXXCfgTable entry and of the relevant pwTDMCfgTable entry in the pwTDMTable. 6.3. TDM PW Monitoring Upon making the TDM PW operational, the pwTDMPerfCurrentTable, pwTDMPerfIntervalTable, and PwTDMPerf1DayIntervalTable can be used to monitor the various counters, indicators, and conditions of the PW. All performance parameters are accumulated in daily intervals and in 15-minute intervals. The number of daily intervals kept by the agent is based on the specific implementation. The 15-minute intervals, up to 96 intervals (24 hours worth), are all kept by the agent. Fewer than 96 intervals of data will be available if the agent has been restarted within the last 24 hours. Performance parameters continue to be collected when the interface is down. There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute interval and any wall clock; however, some agents may align the 15-minute intervals with quarter hours. Performance parameters are of types PerfCurrentCount and PerfIntervalCount. These textual conventions are all Gauge32, and they are used because it is possible for these objects to decrease. 7. Example of Actual TDM PW Setup This section provides an example of using the various MIB objects described in the following section to set up a TDM PW connection. The first example is setting a connection of DS1 type. The second example is setting a connection with a bandwidth of 3 DS0 (time slots). Nicklass Standards Track [Page 6] RFC 5604 Manage TDM over PSN July 2009 While those examples are not meant to illustrate all options of the MIB, they are intended as an aid to understanding some of the key concepts. See [PWMIB] for an example of setting up PSN tunnels. First example: 1. Configure the DS1 interface using DS1-MIB. 2. If needed, create an entry in the pwTDMCfgTable (assuming index = 10); verify that there are no errors in the configuration using the relevant object. 3. Get a new pwIndexNext [PWMIB] and create a new pwTable entry using the value of pwIndexNext (assume here, the PW index = 20). 4. Set the pwType [PWMIB] of the new entry to the relevant value (17) or (18). This should create a new entry in the pwTDMTable. 5. Configure the newly created TDM PW with the required pointers, indices, and the relevant entry in pwTDMCfgTable (index 10). In [DS1MIB] dsx1IfIndex (ifIndex = 5) In pwTDMCfgTable entry: Set the connection characteristic parameters: { pwTDMCfgPayloadSize = 43 -- payload bytes pwTDMCfgPktReorder = FALSE pwTDMCfgRtpHdrUsed = FALSE pwTDMCfgJtrBfrDepth = 30000 -- micro-seconds } In pwTDMTable entry: Set the relevant ifIndex, the generic TDM index, and the specific TDM index to complete creation: { pwTDMIfIndex = 5 -- IfIndex of associated entry -- in DS1 table pwGenTDMCfgIndex = 10 -- Index of associated entry -- in pwTDMCfgTable. pwRelTDMCfgIndex = 0 -- No Index in associated entry -- in pwXXXCfgTable. } Verify that there are no error bits set in pwTDMConfigError. Nicklass Standards Track [Page 7] RFC 5604 Manage TDM over PSN July 2009 Second example: 1. Configure the DS1 interface using DS1-MIB. 2. Set up a bundle and get its dsx0BundleIfIndex. Setting up the bundle should involve using IFMIB properly. 3. Since structured TDMoIP circuit is defined, the next MIB module to be used is TDMoIP-MIB. 4. If needed, create an entry in the pwTDMCfgTable (assuming index = 7). 5. If needed, create an entry in the pwXXXCfgTable (index = 11). XXX can be TDMoIP or CESoPSN. 6. Verify that there are no errors in the configuration using the relevant object when signaling is in use. 7. Get a new pwIndexNext [PWMIB] and create a new pwTable entry using the value of pwIndexNext. 8. Set the pwType [PWMIB] of the new entry to (24). This should create a new entry in the pwTDMTable. 9. Configure the newly created TDM PW with the required pointers, indices, and the relevant entries in pwTDMCfgTable and in pwXXXCfgTable (assuming indices 7 and 11). In [DS1MIB] dsx1IfIndex (ifIndex) = 5 In [DS0MIB] dsx0BundleIfIndex = 8 In pwTDMTable entry: Set the relevant ifIndex, the generic TDM index, and the specific TDM index to complete creation: { pwTDMIfIndex = 8 -- IfIndex of associated entry -- in DS0 table pwGenTDMCfgIndex = 7 -- Index of associated entry -- in pwTDMCfgTable. pwRelTDMCfgIndex = 11 -- Index of associated entry -- in pwXXXCfgTable. -- pwXXXCfgTable might be an implementation specific table too. } Verify that there are no error bits set in pwTDMConfigError. Nicklass Standards Track [Page 8] RFC 5604 Manage TDM over PSN July 2009 8. Object Definition PW-TDM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Unsigned32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType, TimeStamp FROM SNMPv2-TC InterfaceIndexOrZero FROM IF-MIB -- [IFMIB] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] PerfCurrentCount, PerfIntervalCount FROM PerfHist-TC-MIB pwIndex FROM PW-STD-MIB PwCfgIndexOrzero FROM PW-TC-STD-MIB; -- The TDM MIB pwTDMMIB MODULE-IDENTITY LAST-UPDATED "200906150000Z" ORGANIZATION "Pseudo-Wire Emulation Edge-to-Edge (PWE3) Working Group" CONTACT-INFO " Orly Nicklass Postal: RADVISION Ltd. 24Raul Wallenberg St. Tel Aviv, Israel Email: orlyn@radvision.com The PWE3 Working Group (email distribution pwe3@ietf.org, http://www.ietf.org/html.charters/pwe3-charter.html) " Nicklass Standards Track [Page 9] RFC 5604 Manage TDM over PSN July 2009 DESCRIPTION "This MIB contains managed object definitions for encapsulating TDM (T1,E1, T3, E3, NxDS0) as pseudo-wires over packet-switching networks (PSN). This MIB supplements the PW-STD-MIB as in: Zelig, D., Nadeau, T. 'Pseudowire (PW) Management Information Base'. The PW-STD-MIB contains structures and MIB associations generic to pseudowire (PW) emulation. PW-specific MIBs (such as this) contain config and stats for specific PW types. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5604; Nicklass Standards Track [Page 10] RFC 5604 Manage TDM over PSN July 2009 see the RFC itself for full legal notices. " REVISION "200906150000Z" DESCRIPTION "Initial version published as part of RFC 5604." ::= { mib-2 186 } -- Local Textual conventions PwTDMCfgIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Index into the relevant pwXXXCfgTable." SYNTAX Unsigned32 (1..4294967295) -- Notifications pwTDMNotifications OBJECT IDENTIFIER ::= { pwTDMMIB 0 } -- Tables, Scalars pwTDMObjects OBJECT IDENTIFIER ::= { pwTDMMIB 1 } -- Conformance pwTDMConformance OBJECT IDENTIFIER ::= { pwTDMMIB 2 } -- TDM PW table pwTDMTable OBJECT-TYPE SYNTAX SEQUENCE OF PwTDMEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains basic information including the ifIndex and pointers to entries in the relevant TDM config tables for this TDM PW." ::= { pwTDMObjects 1 } pwTDMEntry OBJECT-TYPE SYNTAX PwTDMEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is indexed by the same index that was created for the associated entry in the PW Table (in the PW-STD-MIB). - The PwIndex. Nicklass Standards Track [Page 11] RFC 5604 Manage TDM over PSN July 2009 An entry is created in this table by the agent for every entry in the pwTable with a pwType equal to one of the following: e1Satop(17), t1Satop(18), e3Satop(19), t3Satop(20), basicCesPsn(21), basicTdmIp(22), tdmCasCesPsn(23), or tdmCasTdmIp(24). Unless otherwise specified, all writeable objects in this table MUST NOT be changed after row activation in the generic pwTable (see [PWMIB]) and values must persist after reboot." INDEX { pwIndex } ::= { pwTDMTable 1 } PwTDMEntry ::= SEQUENCE { pwTDMRate Integer32, pwTDMIfIndex InterfaceIndexOrZero, pwGenTDMCfgIndex PwCfgIndexOrzero, pwRelTDMCfgIndex PwCfgIndexOrzero, pwTDMConfigError BITS, pwTDMTimeElapsed Integer32, pwTDMValidIntervals Integer32, pwTDMValidDayIntervals Integer32, pwTDMLastEsTimeStamp TimeStamp } pwTDMRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The parameter represents the bit-rate of the TDM service in multiples of the 'basic' 64 Kbit/s rate [TDMCP-EXT]. It complements the definition of pwType used in PW-STD-MIB. For structure-agnostic mode, the following should be used: a) (Structure-Agnostic TDM over Packet) Satop E1 - 32 b) Satop T1 emulation: i) MUST be set to 24 in the basic emulation mode ii) MUST be set to 25 for the 'Octet-aligned T1' emulation mode c) Satop E3 - 535 d) Satop T3 - 699 For all kinds of structure-aware emulation, this parameter MUST be set to N where N is the number of DS0 channels Nicklass Standards Track [Page 12] RFC 5604 Manage TDM over PSN July 2009 in the corresponding attachment circuit." REFERENCE "TDMCP-EXT" DEFVAL { 32 } ::= { pwTDMEntry 1 } pwTDMIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-write STATUS current DESCRIPTION "This is a unique index within the ifTable. It represents the interface index of the full link or the interface index for the bundle holding the group of time slots to be transmitted via this PW connection. A value of zero indicates an interface index that has yet to be determined. Once set, if the TDM ifIndex is (for some reason) later removed, the agent SHOULD delete the associated PW rows (e.g., this pwTDMTable entry). If the agent does not delete the rows, the agent MUST set this object to zero." ::= { pwTDMEntry 2 } pwGenTDMCfgIndex OBJECT-TYPE SYNTAX PwCfgIndexOrzero MAX-ACCESS read-write STATUS current DESCRIPTION "Index to the generic parameters in the TDM configuration table that appears in this MIB module. It is likely that multiple TDM PWs of the same characteristic will share a single TDM Cfg entry." ::= { pwTDMEntry 3 } pwRelTDMCfgIndex OBJECT-TYPE SYNTAX PwCfgIndexOrzero MAX-ACCESS read-write STATUS current DESCRIPTION "Index to the relevant TDM configuration table entry that appears in one of the related MIB modules such as TDMoIP or CESoPSN. It is likely that multiple TDM PWs of the same characteristic will share a single configuration entry of the relevant type. The value 0 implies no entry in other related MIBs." ::= { pwTDMEntry 4 } Nicklass Standards Track [Page 13] RFC 5604 Manage TDM over PSN July 2009 pwTDMConfigError OBJECT-TYPE SYNTAX BITS { notApplicable ( 0), tdmTypeIncompatible ( 1), peerRtpIncompatible ( 2), peerPayloadSizeIncompatible ( 3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Any of the bits are set if the local configuration is not compatible with the peer configuration as available from the various parameters options. Setting is done based on signaling, or else value (0) will be set. -tdmTypeIncompatible bit is set if the local configuration is not carrying the same TDM type as the peer configuration. -peerRtpIncompatible bit is set if the local configuration is configured to send RTP packets for this PW, and the remote is not capable of accepting RTP packets. -peerPayloadSizeIncompatible bit is set if the local configuration is not carrying the same Payload Size as the peer configuration." ::= { pwTDMEntry 5} pwTDMTimeElapsed OBJECT-TYPE SYNTAX Integer32 (1..900) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds, including partial seconds, that have elapsed since the beginning of the current measurement period. If, for some reason, such as an adjustment in the system's time-of-day clock, the current interval exceeds the maximum value, the agent will return the maximum value." ::= { pwTDMEntry 6} pwTDMValidIntervals OBJECT-TYPE SYNTAX Integer32 (0..96) MAX-ACCESS read-only STATUS current Nicklass Standards Track [Page 14] RFC 5604 Manage TDM over PSN July 2009 DESCRIPTION "The number of previous 15-minute intervals for which data was collected. An agent with TDM capability must be capable of supporting at least n intervals. The minimum value of n is 4. The default of n is 32 and the maximum value of n is 96. The value will be n unless the measurement was (re-) started within the last (n*15) minutes, in which case, the value will be the number of complete 15-minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { pwTDMEntry 7} pwTDMValidDayIntervals OBJECT-TYPE SYNTAX Integer32 (0..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous days for which data was collected. An agent with TDM capability must be capable of supporting at least n intervals. The minimum value of n is 1. The default of n is 1 and the maximum value of n is 30." ::= { pwTDMEntry 8} pwTDMLastEsTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent occasion at which the TDM PW entered the ES or SES state." ::= { pwTDMEntry 11} -- End of TDM PW table -- PW Generic TDM PW Configuration Table pwTDMCfgIndexNext OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Nicklass Standards Track [Page 15] RFC 5604 Manage TDM over PSN July 2009 DESCRIPTION "This object contains the value to be used for pwTDMCfgIndex when creating entries in the pwTDMCfgTable. The value 0 indicates that no unassigned entries are available. To obtain the value of pwTDMCfgIndexNext for a new entry in the pwTDMCfgTable, the manager issues a management protocol retrieval operation. The agent will determine through its local policy when this index value will be made available for reuse." ::= { pwTDMObjects 2 } pwTDMCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF PwTDMCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a set of parameters that may be referenced by one or more TDM PWs in pwTDMTable." ::= { pwTDMObjects 3 } pwTDMCfgEntry OBJECT-TYPE SYNTAX PwTDMCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "These parameters define the characteristics of a TDM PW. They are grouped here to ease NMS burden. Once an entry is created here it may be re-used by many PWs. Unless otherwise specified, all objects in this table MUST NOT be changed after row activation (see [PWMIB])." INDEX { pwTDMCfgIndex } ::= { pwTDMCfgTable 1 } PwTDMCfgEntry ::= SEQUENCE { pwTDMCfgIndex PwTDMCfgIndex, pwTDMCfgRowStatus RowStatus, pwTDMCfgPayloadSize Unsigned32, pwTDMCfgPktReorder TruthValue, pwTDMCfgRtpHdrUsed TruthValue, pwTDMCfgJtrBfrDepth Unsigned32, pwTDMCfgPayloadSuppression INTEGER, pwTDMCfgConsecPktsInSynch Unsigned32, pwTDMCfgConsecMissPktsOutSynch Unsigned32, Nicklass Standards Track [Page 16] RFC 5604 Manage TDM over PSN July 2009 pwTDMCfgSetUp2SynchTimeOut Unsigned32, pwTDMCfgPktReplacePolicy INTEGER, pwTDMCfgAvePktLossTimeWindow Integer32, pwTDMCfgExcessivePktLossThreshold Unsigned32, pwTDMCfgAlarmThreshold Unsigned32, pwTDMCfgClearAlarmThreshold Unsigned32, pwTDMCfgMissingPktsToSes Unsigned32, pwTDMCfgTimestampMode INTEGER, pwTDMCfgStorageType StorageType, pwTDMCfgPktFiller Unsigned32, pwTDMCfgName SnmpAdminString } pwTDMCfgIndex OBJECT-TYPE SYNTAX PwTDMCfgIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index to an entry in this table. When an NMS creates a new entry/row in this table, it best makes use of the value of the pwTDMCfgIndexNext object in order to find a free or available index value." ::= { pwTDMCfgEntry 1 } pwTDMCfgRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Object used for creating, modifying, and deleting a row from this table. The following objects cannot be modified if the entry is in use and the status is active: pwTDMCfgPayloadSize, pwTDMCfgRtpHdrUsed, pwTDMCfgJtrBfrDepth, and pwTDMCfgPayloadSuppression. The row cannot be deleted if the entry is in use." ::= { pwTDMCfgEntry 2 } pwTDMCfgPayloadSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current Nicklass Standards Track [Page 17] RFC 5604 Manage TDM over PSN July 2009 DESCRIPTION "The value of this object indicates the PayLoad Size (in bytes) to be defined during the PW setUp. Upon TX, implementation must be capable of carrying that amount of bytes. Upon RX, when the Low Entry Networking (LEN) field is set to 0, the payload of packet MUST assume this size, and if the actual packet size is inconsistent with this length, the packet MUST be considered to be malformed." ::= { pwTDMCfgEntry 4 } pwTDMCfgPktReorder OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If set to True: as CE-bound packets are queued in the jitter buffer, out of order packets are re-ordered. The maximum sequence number differential (i.e., the range in which re-sequencing can occur) is dependant on the depth of the jitter buffer. See pwTDMCfgJtrBfrDepth. NOTE: Some implementations may not support this feature. The agent should then reject a SET request for true." ::= { pwTDMCfgEntry 5 } pwTDMCfgRtpHdrUsed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If set to False: an RTP header is not pre-pended to the TDM packet." REFERENCE "SATOP" DEFVAL { false } ::= { pwTDMCfgEntry 6 } pwTDMCfgJtrBfrDepth OBJECT-TYPE SYNTAX Unsigned32 UNITS "microsecond" MAX-ACCESS read-create STATUS current DESCRIPTION "The size of this buffer SHOULD be locally configured to allow accommodation to the PSN-specific packet delay variation. Nicklass Standards Track [Page 18] RFC 5604 Manage TDM over PSN July 2009 If configured to a value not supported by the implementation, the agent MUST return an error code 'jtrBfrDepth' in 'pwTDMConfigError'. NOTE: jitter buffers are a limited resource to be managed. The actual size should be at least twice as big as the value of pwTDMCfgJtrBfrDepth." DEFVAL { 3000 } ::= { pwTDMCfgEntry 7 } pwTDMCfgPayloadSuppression OBJECT-TYPE SYNTAX INTEGER { enable ( 1), disable ( 2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Selecting 'enable' means: Payload suppression is allowed. Payload MAY be omitted in order to conserve bandwidth. Selecting 'disable' means: No suppression under any condition. Object MAY be changed at any time." DEFVAL { disable } ::= { pwTDMCfgEntry 8 } pwTDMCfgConsecPktsInSynch OBJECT-TYPE SYNTAX Unsigned32 (1..10) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of consecutive packets with sequential sequence numbers that are required to exit the LOPS. Object MAY be changed only when the related PW is defined as not active." REFERENCE "SATOP" DEFVAL { 2 } ::= { pwTDMCfgEntry 9 } pwTDMCfgConsecMissPktsOutSynch OBJECT-TYPE SYNTAX Unsigned32 (1..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The number of consecutive missing packets that are Nicklass Standards Track [Page 19] RFC 5604 Manage TDM over PSN July 2009 required to enter the LOPS. Object MAY be changed only when the related PW is defined as not active." REFERENCE "SATOP" DEFVAL { 10 } ::= { pwTDMCfgEntry 10 } pwTDMCfgSetUp2SynchTimeOut OBJECT-TYPE SYNTAX Unsigned32 UNITS "millisecond" MAX-ACCESS read-create STATUS current DESCRIPTION "The amount of time the host should wait before declaring the pseudowire in a down state, if the number of consecutive TDM packets that have been received after changing the administrative status to up and after finalization of signaling (if supported) between the two PEs is smaller than pwTDMCfgConsecPktsInSynch. Once the PW has OperStatus of 'up', this parameter is no longer valid. This parameter is defined to ensure that the host does not prematurely inform failure of the PW. In particular, PW 'down' notifications should not be sent before expiration of this timer. This parameter is valid only after administrative changes of the status of the PW. If the PW fails due to network impairments, a 'down' notification should be sent. Object MAY be changed only when the related PW is defined as not active." DEFVAL {5000} ::= { pwTDMCfgEntry 11 } pwTDMCfgPktReplacePolicy OBJECT-TYPE SYNTAX INTEGER { allOnes (1), implementationSpecific(2), filler (3) --user defined } MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter determines the value to be played when CE bound packets over/underflow the jitter buffer, or are missing for any reason. This byte pattern is sent (played) on the TDM line. Selecting implementationSpecific(2) implies an agent-specific algorithm. Selecting filler(3) requires Nicklass Standards Track [Page 20] RFC 5604 Manage TDM over PSN July 2009 the setting of pwTDMCfgPktFiller. Object MAY be changed only when the related PW is defined as not active." DEFVAL { allOnes } -- Play AIS ::= { pwTDMCfgEntry 12 } pwTDMCfgAvePktLossTimeWindow OBJECT-TYPE SYNTAX Integer32 UNITS "millisecond" MAX-ACCESS read-create STATUS current DESCRIPTION "The length of time over which the average packet loss rate should be computed to detect excessive packet loss rate. Object MAY be changed only when the related PW is defined as not active." ::= { pwTDMCfgEntry 13} pwTDMCfgExcessivePktLossThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "Percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Excessive packet loss rate is detected by computing the average packet-loss rate over a pwTDMCfgAvePktLossTimeWindow amount of time and comparing it with this threshold value. The rate is expressed in percentage. Object MAY be changed only when the related PW is defined as not active." ::= { pwTDMCfgEntry 14 } pwTDMCfgAlarmThreshold OBJECT-TYPE SYNTAX Unsigned32 UNITS "milisec" MAX-ACCESS read-create STATUS current DESCRIPTION "Alarms are only reported when the defect state persists for the length of time specified by this object. Object MAY be changed only when the related PW is defined as not active." DEFVAL { 2500 } ::= { pwTDMCfgEntry 15 } pwTDMCfgClearAlarmThreshold OBJECT-TYPE SYNTAX Unsigned32 Nicklass Standards Track [Page 21] RFC 5604 Manage TDM over PSN July 2009 UNITS "milisec" MAX-ACCESS read-create STATUS current DESCRIPTION "Alarm MUST be cleared after the corresponding defect is undetected for the amount of time specified by this object. Object MAY be changed only when the related PW is defined as not active." DEFVAL { 10000 } ::= { pwTDMCfgEntry 16 } pwTDMCfgMissingPktsToSes OBJECT-TYPE SYNTAX Unsigned32 UNITS "Percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Percent of missing packets detected (consecutive or not) within a 1-second window to cause a Severely Error Second (SES) to be counted. Object MAY be changed only when the related PW is defined as not active." DEFVAL { 30 } ::= { pwTDMCfgEntry 17 } pwTDMCfgTimestampMode OBJECT-TYPE SYNTAX INTEGER { notApplicable (1), absolute (2), differential (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Timestamp generation MAY be used in one of the following modes: 1. Absolute mode: The PSN-bound IWF sets timestamps using the clock recovered from the incoming TDM attachment circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. All TDM implementations that support usage of the RTP header MUST support this mode. 2. Differential mode: Both IWFs have access to a common high- quality timing source, and this source is used for timestamp generation. Support of this mode is OPTIONAL. Object MAY be changed only when the related PW is Nicklass Standards Track [Page 22] RFC 5604 Manage TDM over PSN July 2009 defined as not active." ::= { pwTDMCfgEntry 18 } pwTDMCfgStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this row. Conceptual rows having the value permanent(4) must allow write-access to all columnar objects." ::= { pwTDMCfgEntry 19 } pwTDMCfgPktFiller OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Filler byte pattern played out on the TDM interface if pwTDMCfgPktReplacePolicy was set to filler(3). Object MAY be changed only when the related PW is defined as not active." DEFVAL { 255 } -- Play all ones, equal to AIS indications. ::= { pwTDMCfgEntry 20 } pwTDMCfgName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A descriptive string, preferably a unique name, to an entry in this table. Object MAY be changed at any time." ::= { pwTDMCfgEntry 21 } -- End of Table -- The following counters work together to integrate -- errors and the lack of errors on the TDM PW. An error is -- caused by a missing packet. A missing packet can be a result -- of: packet loss in the network, (uncorrectable) packet out -- of sequence, packet length error, jitter buffer overflow, -- and jitter buffer underflow. The result is declaring whether -- or not the TDM PW is in Loss of Packet State (LOPS). -- TDM PW Performance Current Table Nicklass Standards Track [Page 23] RFC 5604 Manage TDM over PSN July 2009 pwTDMPerfCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF PwTDMPerfCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The current 15-minute interval counts are in this table. This table provides per TDM PW performance information." ::= { pwTDMObjects 5 } pwTDMPerfCurrentEntry OBJECT-TYPE SYNTAX PwTDMPerfCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every pwTDMTable entry. After 15 minutes, the contents of this table entry are copied to a new entry in the pwTDMPerfInterval table, and the counts in this entry are reset to zero." INDEX { pwIndex } ::= { pwTDMPerfCurrentTable 1 } PwTDMPerfCurrentEntry ::= SEQUENCE { pwTDMPerfCurrentMissingPkts PerfCurrentCount, pwTDMPerfCurrentPktsReOrder PerfCurrentCount, pwTDMPerfCurrentJtrBfrUnderruns PerfCurrentCount, pwTDMPerfCurrentMisOrderDropped PerfCurrentCount, pwTDMPerfCurrentMalformedPkt PerfCurrentCount, pwTDMPerfCurrentESs PerfCurrentCount, pwTDMPerfCurrentSESs PerfCurrentCount, pwTDMPerfCurrentUASs PerfCurrentCount, pwTDMPerfCurrentFC PerfCurrentCount } pwTDMPerfCurrentMissingPkts OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of missing packets (as detected via control word sequence number gaps)." Nicklass Standards Track [Page 24] RFC 5604 Manage TDM over PSN July 2009 ::= { pwTDMPerfCurrentEntry 1 } pwTDMPerfCurrentPktsReOrder OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of sequence (via control word sequence number) but successfully re-ordered. Note: some implementations may not support this feature." ::= { pwTDMPerfCurrentEntry 2 } pwTDMPerfCurrentJtrBfrUnderruns OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a packet needed to be played out and the jitter buffer was empty." ::= { pwTDMPerfCurrentEntry 3 } pwTDMPerfCurrentMisOrderDropped OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of order (via control word sequence numbers) that could not be re-ordered or could not fit in the jitter buffer." ::= { pwTDMPerfCurrentEntry 4 } pwTDMPerfCurrentMalformedPkt OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected with unexpected size or bad headers' stack." ::= { pwTDMPerfCurrentEntry 5 } pwTDMPerfCurrentESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Error Seconds encountered. Any malformed packet, sequence error, LOPS, and the like are considered as Error Seconds." Nicklass Standards Track [Page 25] RFC 5604 Manage TDM over PSN July 2009 ::= { pwTDMPerfCurrentEntry 6 } pwTDMPerfCurrentSESs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Error Seconds encountered." ::= { pwTDMPerfCurrentEntry 7 } pwTDMPerfCurrentUASs OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered. Any consecutive ten seconds of SES are counted as one Unavailable Seconds (UAS)." ::= { pwTDMPerfCurrentEntry 8 } pwTDMPerfCurrentFC OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "TDM Failure Counts (FC-TDM). The number of TDM failure events. A failure event begins when the LOPS failure is declared, and it ends when the failure is cleared. A failure event that begins in one period and ends in another period is counted only in the period in which it begins." ::= { pwTDMPerfCurrentEntry 9 } -- End TDM PW Performance Current Interval Table -- TDM PW Performance Interval Table pwTDMPerfIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF PwTDMPerfIntervalEntry MAX-ACCESS not-accessible STATUS current Nicklass Standards Track [Page 26] RFC 5604 Manage TDM over PSN July 2009 DESCRIPTION "This table provides performance information per TDM PW similar to the pwTDMPerfCurrentTable above. However, these counts represent historical 15-minute intervals. Typically, this table will have a maximum of 96 entries for a 24 hour period, but is not limited to this." ::= { pwTDMObjects 6 } pwTDMPerfIntervalEntry OBJECT-TYPE SYNTAX PwTDMPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every pwTDMPerfCurrentEntry that is 15 minutes old. The contents of the Current entry are copied to the new entry here. The Current entry then resets its counts to zero for the next current 15-minute interval." INDEX { pwIndex, pwTDMPerfIntervalNumber } ::= { pwTDMPerfIntervalTable 1 } PwTDMPerfIntervalEntry ::= SEQUENCE { pwTDMPerfIntervalNumber Unsigned32, pwTDMPerfIntervalValidData TruthValue, pwTDMPerfIntervalDuration Unsigned32, pwTDMPerfIntervalMissingPkts PerfIntervalCount, pwTDMPerfIntervalPktsReOrder PerfIntervalCount, pwTDMPerfIntervalJtrBfrUnderruns PerfIntervalCount, pwTDMPerfIntervalMisOrderDropped PerfIntervalCount, pwTDMPerfIntervalMalformedPkt PerfIntervalCount, pwTDMPerfIntervalESs PerfIntervalCount, pwTDMPerfIntervalSESs PerfIntervalCount, pwTDMPerfIntervalUASs PerfIntervalCount, pwTDMPerfIntervalFC PerfIntervalCount } pwTDMPerfIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number (normally between 1 and 96 to cover a 24 hour period) that identifies the interval for which the set of statistics is available. The interval identified by 1 Nicklass Standards Track [Page 27] RFC 5604 Manage TDM over PSN July 2009 is the most recently completed 15-minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1. The minimum range of N is 1 through 4. The default range is 1 through 32. The maximum value of N is 1 through 96." ::= { pwTDMPerfIntervalEntry 1 } pwTDMPerfIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { pwTDMPerfIntervalEntry 2 } pwTDMPerfIntervalDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The duration of a particular interval in seconds. Adjustments in the system's time-of-day clock may cause the interval to be greater or less than the normal value. Therefore, this actual interval value is provided." ::= { pwTDMPerfIntervalEntry 3 } pwTDMPerfIntervalMissingPkts OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of missing packets (as detected via control word sequence number gaps)." ::= { pwTDMPerfIntervalEntry 4 } pwTDMPerfIntervalPktsReOrder OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of sequence (via control word sequence number) but successfully re-ordered. Note: some implementations may not support this feature." ::= { pwTDMPerfIntervalEntry 5 } Nicklass Standards Track [Page 28] RFC 5604 Manage TDM over PSN July 2009 pwTDMPerfIntervalJtrBfrUnderruns OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a packet needed to be played out and the jitter buffer was empty." ::= { pwTDMPerfIntervalEntry 6 } pwTDMPerfIntervalMisOrderDropped OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of order (via control word sequence numbers) that could not be re-ordered or could not fit in the jitter buffer." ::= { pwTDMPerfIntervalEntry 7 } pwTDMPerfIntervalMalformedPkt OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected with unexpected size, or bad headers' stack" ::= { pwTDMPerfIntervalEntry 8 } pwTDMPerfIntervalESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Error Seconds encountered." ::= { pwTDMPerfIntervalEntry 9 } pwTDMPerfIntervalSESs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Error Seconds encountered." ::= { pwTDMPerfIntervalEntry 10 } Nicklass Standards Track [Page 29] RFC 5604 Manage TDM over PSN July 2009 pwTDMPerfIntervalUASs OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered." ::= { pwTDMPerfIntervalEntry 11 } pwTDMPerfIntervalFC OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "TDM Failure Counts (FC-TDM). The number of TDM failure events. A failure event begins when the LOPS failure is declared, and it ends when the failure is cleared. A failure event that begins in one period and ends in another period is counted only in the period in which it begins." ::= { pwTDMPerfIntervalEntry 12 } -- End TDM PW Performance Interval Table -- TDM PW 1day Performance Table pwTDMPerf1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF PwTDMPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides performance information per TDM PW similar to the pwTDMPerfIntervalTable above. However, these counters represent historical one-day intervals up to one full month. The table consists of real-time data, as such it is not persistence across re-boot." ::= { pwTDMObjects 7 } pwTDMPerf1DayIntervalEntry OBJECT-TYPE SYNTAX PwTDMPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry is created in this table by the agent for every entry in the pwTDMTable table." INDEX { pwIndex,pwTDMPerf1DayIntervalNumber } Nicklass Standards Track [Page 30] RFC 5604 Manage TDM over PSN July 2009 ::= { pwTDMPerf1DayIntervalTable 1 } PwTDMPerf1DayIntervalEntry ::= SEQUENCE { pwTDMPerf1DayIntervalNumber Unsigned32, pwTDMPerf1DayIntervalValidData TruthValue, pwTDMPerf1DayIntervalDuration Unsigned32, pwTDMPerf1DayIntervalMissingPkts Counter32, pwTDMPerf1DayIntervalPktsReOrder Counter32, pwTDMPerf1DayIntervalJtrBfrUnderruns Counter32, pwTDMPerf1DayIntervalMisOrderDropped Counter32, pwTDMPerf1DayIntervalMalformedPkt Counter32, pwTDMPerf1DayIntervalESs Counter32, pwTDMPerf1DayIntervalSESs Counter32, pwTDMPerf1DayIntervalUASs Counter32, pwTDMPerf1DayIntervalFC Counter32 } pwTDMPerf1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of intervals where 1 indicates the current day measured period and 2 and above indicate previous days, respectively." ::= { pwTDMPerf1DayIntervalEntry 1 } pwTDMPerf1DayIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { pwTDMPerf1DayIntervalEntry 2 } pwTDMPerf1DayIntervalDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The duration of a particular interval in seconds. Adjustments in the system's time-of-day clock may cause the interval to be greater or less than the normal value. Therefore, this actual interval value is provided." Nicklass Standards Track [Page 31] RFC 5604 Manage TDM over PSN July 2009 ::= { pwTDMPerf1DayIntervalEntry 3 } pwTDMPerf1DayIntervalMissingPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of missing packets (as detected via control word sequence number gaps)." ::= { pwTDMPerf1DayIntervalEntry 4 } pwTDMPerf1DayIntervalPktsReOrder OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of sequence (via control word sequence number) but successfully re-ordered. Note: some implementations may not support this feature." ::= { pwTDMPerf1DayIntervalEntry 5 } pwTDMPerf1DayIntervalJtrBfrUnderruns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a packet needed to be played out and the jitter buffer was empty." ::= { pwTDMPerf1DayIntervalEntry 6 } pwTDMPerf1DayIntervalMisOrderDropped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of order (via control word sequence numbers) that could not be re-ordered or could not fit in the jitter buffer." ::= { pwTDMPerf1DayIntervalEntry 7 } pwTDMPerf1DayIntervalMalformedPkt OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected with unexpected size or bad headers' stack." Nicklass Standards Track [Page 32] RFC 5604 Manage TDM over PSN July 2009 ::= { pwTDMPerf1DayIntervalEntry 8 } pwTDMPerf1DayIntervalESs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Error Seconds encountered." ::= { pwTDMPerf1DayIntervalEntry 9 } pwTDMPerf1DayIntervalSESs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Severely Error Seconds." ::= { pwTDMPerf1DayIntervalEntry 10 } pwTDMPerf1DayIntervalUASs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UnAvailable Seconds. NOTE: When first entering the UAS state, the number of SES to UAS is added to this object, then as each additional UAS occurs, this object increments by one." ::= { pwTDMPerf1DayIntervalEntry 11 } pwTDMPerf1DayIntervalFC OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "TDM Failure Counts (FC-TDM). The number of TDM failure events. A failure event begins when the LOPS failure is declared, and it ends when the failure is cleared." ::= { pwTDMPerf1DayIntervalEntry 12 } -- End of PW TDM Performance table -- Conformance Information Nicklass Standards Track [Page 33] RFC 5604 Manage TDM over PSN July 2009 pwTDMCompliances OBJECT IDENTIFIER ::= { pwTDMConformance 1 } pwTDMGroups OBJECT IDENTIFIER ::= { pwTDMConformance 2 } pwTDMModuleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agent that support TDM PW over PSN operation." MODULE -- this module MANDATORY-GROUPS { pwTDMGroup, pwTDMPerfCurrentGroup, pwTDMPerfIntervalGroup, pwTDMPerf1DayIntervalGroup } OBJECT pwGenTDMCfgIndex MIN-ACCESS read-only DESCRIPTION "The ability to set an index pointer is not required." OBJECT pwRelTDMCfgIndex MIN-ACCESS read-only DESCRIPTION "The ability to set an index pointer is not required." OBJECT pwTDMCfgPktReorder MIN-ACCESS read-only DESCRIPTION "The ability to set the packet reordering is not required. If the feature is not supported, the value set by the agent MUST be FALSE." OBJECT pwTDMCfgRtpHdrUsed MIN-ACCESS read-only DESCRIPTION "The ability to set whether or not to use the RTP header is not required." OBJECT pwTDMCfgPayloadSuppression MIN-ACCESS read-only DESCRIPTION "The ability to set this object is not required." Nicklass Standards Track [Page 34] RFC 5604 Manage TDM over PSN July 2009 OBJECT pwTDMCfgPktReplacePolicy MIN-ACCESS read-only DESCRIPTION "The ability to set the replace policy is not required." OBJECT pwTDMCfgStorageType MIN-ACCESS read-only DESCRIPTION "The ability to set the storage type is not required." OBJECT pwTDMCfgPktFiller MIN-ACCESS read-only DESCRIPTION "The ability to set the filler pattern is not required." OBJECT pwTDMCfgName MIN-ACCESS read-only DESCRIPTION "The ability to set an alias is not required." ::= { pwTDMCompliances 1 } -- Units of conformance pwTDMGroup OBJECT-GROUP OBJECTS { pwTDMRate, pwTDMIfIndex, pwGenTDMCfgIndex, pwRelTDMCfgIndex, pwTDMConfigError, pwTDMTimeElapsed, pwTDMValidIntervals, pwTDMValidDayIntervals, pwTDMLastEsTimeStamp, pwTDMCfgIndexNext, pwTDMCfgRowStatus, pwTDMCfgPayloadSize, pwTDMCfgPktReorder, pwTDMCfgRtpHdrUsed, pwTDMCfgJtrBfrDepth, Nicklass Standards Track [Page 35] RFC 5604 Manage TDM over PSN July 2009 pwTDMCfgPayloadSuppression, pwTDMCfgConsecPktsInSynch, pwTDMCfgConsecMissPktsOutSynch, pwTDMCfgSetUp2SynchTimeOut, pwTDMCfgPktReplacePolicy, pwTDMCfgAvePktLossTimeWindow , pwTDMCfgExcessivePktLossThreshold, pwTDMCfgAlarmThreshold , pwTDMCfgClearAlarmThreshold, pwTDMCfgMissingPktsToSes, pwTDMCfgTimestampMode, pwTDMCfgStorageType, pwTDMCfgPktFiller, pwTDMCfgName } STATUS current DESCRIPTION "Collection of objects for basic TDM PW config and status." ::= { pwTDMGroups 1 } pwTDMPerfCurrentGroup OBJECT-GROUP OBJECTS { pwTDMPerfCurrentMissingPkts, pwTDMPerfCurrentPktsReOrder, pwTDMPerfCurrentJtrBfrUnderruns, pwTDMPerfCurrentMisOrderDropped, pwTDMPerfCurrentMalformedPkt, pwTDMPerfCurrentESs, pwTDMPerfCurrentSESs, pwTDMPerfCurrentUASs, pwTDMPerfCurrentFC } STATUS current DESCRIPTION "Collection of current statistics objects for TDM PWs." ::= { pwTDMGroups 2 } pwTDMPerfIntervalGroup OBJECT-GROUP OBJECTS { pwTDMPerfIntervalValidData, pwTDMPerfIntervalDuration, Nicklass Standards Track [Page 36] RFC 5604 Manage TDM over PSN July 2009 pwTDMPerfIntervalMissingPkts, pwTDMPerfIntervalPktsReOrder, pwTDMPerfIntervalJtrBfrUnderruns, pwTDMPerfIntervalMisOrderDropped, pwTDMPerfIntervalMalformedPkt, pwTDMPerfIntervalESs, pwTDMPerfIntervalSESs, pwTDMPerfIntervalUASs, pwTDMPerfIntervalFC } STATUS current DESCRIPTION "Collection of Interval statistics objects for TDM PWs." ::= { pwTDMGroups 3 } pwTDMPerf1DayIntervalGroup OBJECT-GROUP OBJECTS { pwTDMPerf1DayIntervalValidData, pwTDMPerf1DayIntervalDuration, pwTDMPerf1DayIntervalMissingPkts, pwTDMPerf1DayIntervalPktsReOrder, pwTDMPerf1DayIntervalJtrBfrUnderruns, pwTDMPerf1DayIntervalMisOrderDropped, pwTDMPerf1DayIntervalMalformedPkt, pwTDMPerf1DayIntervalESs, pwTDMPerf1DayIntervalSESs, pwTDMPerf1DayIntervalUASs, pwTDMPerf1DayIntervalFC } STATUS current DESCRIPTION "Collection of Daily statistics objects for TDM PWs." ::= { pwTDMGroups 4 } END 9. Security Considerations It is clear that this MIB module is potentially useful for monitoring of TDM PWs. This MIB can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. Nicklass Standards Track [Page 37] RFC 5604 Manage TDM over PSN July 2009 There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: The pwTDMTable and pwTDMCfgTable contain objects of TDM PW parameters on a Provider Edge (PE) device. Unauthorized access to objects in these tables could result in disruption of traffic on the network. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any SNMPV3 agent, which implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: The pwTDMTable, pwTDMPerfCurrentTable, pwTDMPerfIntervalTable, and pwTDMPerf1DayIntervalTable collectively show the TDM pseudowire connectivity topology and its performance characteristics. If an Administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Nicklass Standards Track [Page 38] RFC 5604 Manage TDM over PSN July 2009 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pwTDMMIB { mib-2 186 } 11. References 11.1. Normative References [SATOP] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure- Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006. [TDMCP-EXT] Vainshtein, A. and Y(J). Stein, "Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks", RFC 5287, August 2008. [PWMIB] Nadeau, T., Ed., and D. Zelig, Ed., "Pseudowire (PW) Management Information Base", RFC 5601, July 2009. [PWTC] Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., "Definitions for Textual Conventions for Pseudowire (PW) Management", RFC 5542, May 2009. [DS1MIB] Nicklass, O., Ed., "Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types", RFC 4805, March 2007. [DS3MIB] Nicklass, O., Ed., "Definitions of Managed Objects for the DS3/E3 Interface Type", RFC 3896, September 2004. Nicklass Standards Track [Page 39] RFC 5604 Manage TDM over PSN July 2009 [DS0MIB] Fowler, D., Ed., "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type", RFC 2494, January 1999. [IFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005. [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [TDMOIP] Y(J). Stein, Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, December 2007. [CESOPSN] Vainshtein A., Sasson, I., Sadovski, A., Metz, E., Frost, T., and P. Pate "Structured TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Work in Progress, October 2003. Nicklass Standards Track [Page 40] RFC 5604 Manage TDM over PSN July 2009 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 12. Acknowledgements This document was produced by the PWE3 Working Group. Special thanks to Yaakov Stein, Doron Tzur, Sasha Vainshtein, and Ron Cohen for close review and good suggestions. Author's Address Orly Nicklass RADVISION Ltd. 24 Raul Wallenberg St. Tel Aviv ISRAEL Phone: +972 3 7679444 EMail: orlyn@radvision.com Nicklass Standards Track [Page 41] snmp-mibs-downloader-1.1/mibrfcs/rfc5605.txt0000644000000000000000000020743111402176072015571 0ustar Network Working Group O. Nicklass Request for Comments: 5605 RADVISION Ltd. Category: Standards Track T. Nadeau BT July 2009 Managed Objects for ATM over Packet Switched Networks (PSNs) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Nicklass & Nadeau Standards Track [Page 1] RFC 5605 Manage ATM over PSN July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. The Internet-Standard Management Framework . . . . . . . . . . 4 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Relation to Other PW-MIB Modules . . . . . . . . . . . . . . . 5 7. ATM-PW MIB Usage . . . . . . . . . . . . . . . . . . . . . . . 6 8. Structure of the MIB Module . . . . . . . . . . . . . . . . . 7 9. Object Definition . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 36 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction This document describes a model for managing "emulated" ATM services over a Packet Switched Network (PSN). The document follows the requirements for Pseudowire Emulation Edge- to-Edge [PWREQ]; it is closely related to [ATMENCAP] and [ATMTRANS], which describe the encapsulation of ATM signals and provide the Emulation Service over a Packet Switched Network. The ATM management model consists of several MIB modules, following the layering model described in the PWE3 Architecture [PWARCH] document. The ATM MIB module described in this document works closely with the MIB modules described in [AToMTC], [AToM], [IFMIB], [PWMIB], and the textual conventions defined in [PWTC]. The conceptual layering and relationship among all of those is described in Figure 1 and in the "Relation to Other PW-MIB Modules" section listed below. An ATM connection will be a pseudowire (PW) connection. It will not be treated as an interface and will therefore not be represented in the ifTable. Nicklass & Nadeau Standards Track [Page 2] RFC 5605 Manage ATM over PSN July 2009 Figure 1: Conceptual Layering +-------------------+ | ATM MIB | ATM-TC-MIB, +-------------------+ ATMMIB | +-------------------+ Service | ATM PW MIB | PW-ATM-MIB Layer +-------------------+ - - - - - - - - - - - | - - - - - - - - - - - - - - - Generic +-------------------+ PW | Generic PW MIBS | PW-TC-MIB, Layer +-------------------+ PW-STD-MIB - - - - - - - - - - - -| - - - - - - - - - - - - - - - +-------------------+ PSN VC | MPLS VC MIBS | PW-MPLS-MIB Layer +-------------------+ - - - - - - - - - - - -| - - - - - - - - - - - - - - - +-------------------+ PSN | MPLS MIBs | MPLS-TE-STD-MIB, Layer +-------------------+ MPLS-LSR-STD-MIB Figure 1 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. 3. Terminology This document follows the terminology used in PW Architecture [PWARCH]. PSN-bound References the traffic direction where an ATM Cell is received, adapted to the packet, assigned a PW label, and sent into the PSN. Within the MIB objects, it is called outbound. Nicklass & Nadeau Standards Track [Page 3] RFC 5605 Manage ATM over PSN July 2009 CE-bound The direction where packets are received from the PSN, cells are reconstructed from the packet payloads, and are sent into the ATM network as cells. Within the MIB objects, it is called inbound. Adaptation Refers to the method of adapting a "foreign" communications protocol such that it can be carried by a packet switched net (the PSN). For example, in an ATM service, the foreign protocol is ATM. The PSN may be MPLS. PSN Packet Switched Network. PSN Tunnel A general term indicating a virtual connection between the two PW edge devices. In practice, this connection is not limited to path-oriented types of PSNs such as MPLS. An example of a non- path-oriented PSN is an IP PSN. 4. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 5. Overview This MIB module is designed to satisfy the following requirements and constraints: o Fit within the architecture defined by [PWARCH] and [PWMIB]. o Fit within the model for Virtual Path/Virtual Circuit (VP/VC) definitions and management concept as defined in the [AToM] MIB. o Support manually configured ATM PWs. Nicklass & Nadeau Standards Track [Page 4] RFC 5605 Manage ATM over PSN July 2009 o Support automatically configured ATM PWs. o Enable the use of any PSN type. o Support point-to-point ATM PW connections. Point-to-multipoint and multipoint-to-point connections are for future study. o Allow configuration of all the parameters needed to establish a PW to carry ATM cells. o Report ATM performance metrics for the ATM PW. This includes cells transmit, Cells dropped, Cells received, and unknownCells. In addition, it reports performance metrics at packet level. o Support ATM Operations, Administration, and Management (OAM) cells. o Do not consider Integrated Local Management Interface (ILMI) support. 6. Relation to Other PW-MIB Modules The MIB structure for defining a PW service is composed of three layers of MIB modules functioning together. This general model is defined in the PWE3 Architecture [PWARCH]. The layering model is intended to sufficiently isolate PW services from the underlying PSN layer that carries the emulated service. This is done at the same time as providing a standard means for connecting any supported services to any supported PSNs. The first layer, known as the service layer, contains service- specific modules such as the one defined in this document. These modules define service-specific management objects that interface or collaborate with existing MIB modules for the native version of the service. The service-specific module "glues" the standard module to the PWE MIB framework. The next layer of the PWE MIB framework is comprised of the PW-MIB module [PWMIB]. This module is used to configure general parameters of PW connections that are common to all types of emulated services and PSNs. This layer is connected to the service-specific layer above, and the PSN layer below. The PSN layer provides PSN-specific modules for each type of PSN. These modules associate the PW with one or more "tunnels" that carry the service over the PSN. These modules are defined in other documents. This module is used to "glue" the PW service to the Nicklass & Nadeau Standards Track [Page 5] RFC 5605 Manage ATM over PSN July 2009 underlying PSN-specific MIB modules. In the case of MPLS, for example, the PW-MPLS MIB [PWMPLSMIB] is used to connect the PW service to either the MPLS-LDP [LDPMIB] or MPLS-TE [TEMIB] MIBs. [PWTC] defines some of the object types used in these modules. 7. ATM-PW MIB Usage This section provides an example of using the MIB objects described in section 9 to set up an ATM PW. While this example is not meant to illustrate every permutation of the MIB, it is intended as an aid in the understanding of some key concepts. It is meant to be read after going through the MIB itself. See [PWMIB] for an example of setting up a PSN Tunnel. The following example illustrates how a user will set up an ATM Adaptation Layer 5 (AAL5) ATM PW on a switch/router with cells entering the switch/router through ATM Interface with IfIndex 1000 [IFMIB], Virtual Path Identifier (VPI) 1 and Virtual Circuit Identifier (VCI) 100 (from an ATM network to a PSN -- outbound direction) and on the way back, it goes out of the switch/router through ATM Interface 1000 with VPI 1 and VCI 100 (PSN to ATM network -- inbound direction). First create an entry in the PW MIB with pwType atmAal5SduVcc(2), then create entries in the pwAtmCfg table, inbound and outbound tables. Nicklass & Nadeau Standards Track [Page 6] RFC 5605 Manage ATM over PSN July 2009 In PW ATM MIB In pwAtmCfgTable: pwAtmCfgMaxCellConcatenation 29 pwAtmCfgTimeoutMode enabled(3) pwAtmClpQosMapping false(0) --CLP will not be mapped to QoS pwAtmOamCellSupported true(1) --OAM cells will be supported In pwAtmOutboundTable: { pwAtmOutboundAtmIf 1000 --Outbound AtmIf pwAtmOutboundVpi 1 --Outbound VPI pwAtmOutboundVci 100 --Outbound VCI pwAtmOutboundTrafficParamDescr 0.0 --Best Effort pwAtmOutboundRowStatus createAndGo } In pwAtmInboundTable { pwAtmInboundAtmIf 1000 --Inbound AtmIf pwAtmInboundVpi 1 --Inbound VPI pwAtmInboundVci 100 --Inbound VCI pwAtmInboundTrafficParamDescr 0.0 --Best Effort pwAtmInboundRowStatus createAndGo } 8. Structure of the MIB Module This MIB consists of 4 types of tables; It is important to note that the TrafficParamDescr Table is not defined as part of this MIB, although an object pointing to such a table entry exists in all configuration tables of this MIB module. Users can refer to any ATM TrafficDescr (TD) Table if there is a need to overwrite the TD assigned to the ATM endpoint in the ATM service MIB [AToM]. o PW ATM Cfg Table: A table for generic parameters for ATM PW configuration that is applicable for each ATM PW. o PW ATM Outbound Table: There are two tables to configure an outbound ATM PW depending on the type of service. One table for 1:1 service, and the other for N:1 service and transparent cell mode [ATMTRANS]. Nicklass & Nadeau Standards Track [Page 7] RFC 5605 Manage ATM over PSN July 2009 o PW ATM Inbound Table: There are two tables to configure an inbound ATM PW depending on the type of service. One table for 1:1 service, and the other for N:1 service and transparent cell mode. o PW ATM Perf Table: There are three tables; each contains the relevant time-dependent statistics for an ATM PW Entry. There is a current table, a 15-minute interval table, and a one-day interval table. The tables are aligned with statistic models of other PW services. 9. Object Definition PW-ATM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TruthValue, RowStatus, RowPointer FROM SNMPv2-TC PerfCurrentCount, PerfIntervalCount FROM PerfHist-TC-MIB InterfaceIndex FROM IF-MIB pwIndex FROM PW-STD-MIB AtmVpIdentifier, AtmVcIdentifier FROM ATM-TC-MIB; pwAtmMIB MODULE-IDENTITY LAST-UPDATED "200906160000Z" -- 16 June 2009 ORGANIZATION "Pseudowire Emulation Edge-to-Edge (PWE3) Working Group" CONTACT-INFO "Thomas D. Nadeau Postal: BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom Nicklass & Nadeau Standards Track [Page 8] RFC 5605 Manage ATM over PSN July 2009 Email: tom.nadeau@bt.com Orly Nicklass Postal: RADVISION Ltd. 24 Raul Wallenberg Tel Aviv, Israel Email: orlyn@radvision.com Discussion and general questions should be posed to the PWE3 Working Group (pwe3@ietf.org)." DESCRIPTION "This MIB contains managed object definitions for pseudowire emulation of ATM over Packet Switched Networks (PSNs). This MIB supplements the PW-STD-MIB module. The PW-STD-MIB contains structures and MIB associations generic to pseudowire (PW) emulation. PW-specific MIBs (such as this) contain config and stats for specific PW types. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR Nicklass & Nadeau Standards Track [Page 9] RFC 5605 Manage ATM over PSN July 2009 CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5605; see the RFC itself for full legal notices. " -- Revision history. REVISION "200906160000Z" -- 16 June 2009 DESCRIPTION "Initial version published as RFC 5605." ::= { mib-2 183 } -- Top-level components of this MIB pwAtmNotifications OBJECT IDENTIFIER ::= { pwAtmMIB 0 } pwAtmObjects OBJECT IDENTIFIER ::= { pwAtmMIB 1 } pwAtmConformance OBJECT IDENTIFIER ::= { pwAtmMIB 2 } -- ATM PW PSN Bound(Outbound) Table for 1 to 1 connection pwAtmOutboundTable OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmOutboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the information for an ATM PW to be carried over the PSN in the outbound direction. An entry is created in this table for every entry in the pwTable with a pwType equal to one of the following: atmAal5SduVcc(2), atmCell1to1Vcc(12), atmCell1to1Vpc(13) or atmAal5PduVcc(14), or atmTransparent(3)." ::= { pwAtmObjects 1 } pwAtmOutboundEntry OBJECT-TYPE SYNTAX PwAtmOutboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table represents an ATM PW that needs to be adapted and carried over the PSN. This table is indexed by Nicklass & Nadeau Standards Track [Page 10] RFC 5605 Manage ATM over PSN July 2009 pwIndex from pwTable. Unless otherwise specified, all writeable objects in this table MUST NOT be changed after row activation in the generic pwTable, and values must persist after reboot." REFERENCE "See [PWMIB]." INDEX { pwIndex } ::= { pwAtmOutboundTable 1 } PwAtmOutboundEntry ::= SEQUENCE { pwAtmOutboundAtmIf InterfaceIndex, pwAtmOutboundVpi AtmVpIdentifier, pwAtmOutboundVci AtmVcIdentifier, pwAtmOutboundTrafficParamDescr RowPointer, pwAtmOutboundRowStatus RowStatus } pwAtmOutboundAtmIf OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ATM Interface that receives cells from the ATM network." ::= { pwAtmOutboundEntry 1 } pwAtmOutboundVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "VPI value of this ATM PW. The value may indicate the translated value when egress generates new VPI." ::= { pwAtmOutboundEntry 2 } pwAtmOutboundVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "VCI value of this ATM PW. The value may indicate the translated value when egress generates new VCI." ::= { pwAtmOutboundEntry 3 } pwAtmOutboundTrafficParamDescr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create Nicklass & Nadeau Standards Track [Page 11] RFC 5605 Manage ATM over PSN July 2009 STATUS current DESCRIPTION "This object represents a pointer to an ATM traffic-parameter-specific row in either a private or standard table that will be employed while receiving cells from the ATM network. This row should contain a set of self-consistent ATM traffic parameters including the ATM traffic service category. A value of 0.0 indicates Best Effort." ::= { pwAtmOutboundEntry 4 } pwAtmOutboundRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify, or delete a row in this table. Unless otherwise specified, all writeable objects in this table MUST NOT be changed after row activation as explained in the pwAtmOutboundEntry. " ::= { pwAtmOutboundEntry 5 } -- End of ATM PW Outbound Table -- ATM PW CE Bound(Inbound) Table for 1 to 1 mode pwAtmInboundTable OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmInboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the information for an ATM PW in the inbound direction." ::= { pwAtmObjects 3 } pwAtmInboundEntry OBJECT-TYPE SYNTAX PwAtmInboundEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table represents an ATM PW that needs to be sent into the ATM network after reconstructing cells from packets received from a PSN. This table is indexed by pwIndex from pwTable. An entry is created in this table for every entry in the pwTable with a pwType equal to one of the following: atmAal5SduVcc(2), atmCell1to1Vcc(12), atmCell1to1Vpc(13), atmAal5PduVcc(14), or atmTransparent(3). Unless otherwise Nicklass & Nadeau Standards Track [Page 12] RFC 5605 Manage ATM over PSN July 2009 specified, all writeable objects in this table MUST NOT be changed after row activation in the generic pwTable, and values must persist after reboot." REFERENCE "See [PWMIB]." INDEX { pwIndex } ::= { pwAtmInboundTable 1 } PwAtmInboundEntry ::= SEQUENCE { pwAtmInboundAtmIf InterfaceIndex, pwAtmInboundVpi AtmVpIdentifier, pwAtmInboundVci AtmVcIdentifier, pwAtmInboundTrafficParamDescr RowPointer, pwAtmInboundRowStatus RowStatus } pwAtmInboundAtmIf OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ATM Interface that sends cells into the ATM network after reconstructing cells from packets received from a PSN." ::= { pwAtmInboundEntry 1 } pwAtmInboundVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "VPI value of this ATM PW. If the pwType is atmTransparent, then the value will be set to zero." ::= { pwAtmInboundEntry 2 } pwAtmInboundVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "VCI value of this ATM PW. If the pwType is atmTransparent, atmCell1to1Vpc, or atmCellNto1Vpc, then the value will be set to zero." ::= { pwAtmInboundEntry 3 } pwAtmInboundTrafficParamDescr OBJECT-TYPE Nicklass & Nadeau Standards Track [Page 13] RFC 5605 Manage ATM over PSN July 2009 SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents a pointer to an ATM traffic-parameter- specific row in either a private or standard table that will be employed while transmitting into the ATM network. This table contains a set of self-consistent ATM traffic parameters including the ATM traffic service category. A value of 0.0 indicates Best Effort." ::= { pwAtmInboundEntry 4 } pwAtmInboundRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify, or delete a row in this table. Unless otherwise specified, all writeable objects in this table MUST NOT be changed after row activation as explained in the pwAtmInboundEntry. " ::= { pwAtmInboundEntry 5 } -- End of ATM PW Inbound Table --Generic ATM PW table for all types of ATM PW connection. pwAtmCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies generic information for an ATM PW to be carried over PSN in any mode." ::= { pwAtmObjects 5 } pwAtmCfgEntry OBJECT-TYPE SYNTAX PwAtmCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a set of parameters for the ATM PW that needs to be adapted and carried over the PSN. This table is indexed by pwIndex from pwTable. An entry is created for every new ATM type associated pwIndex in the pwTable. Unless otherwise specified, all read-write objects in Nicklass & Nadeau Standards Track [Page 14] RFC 5605 Manage ATM over PSN July 2009 this table MAY be changed when the PW is defined as not active, and all RW objects values must persist after reboot." REFERENCE "See [PWMIB]." INDEX { pwIndex } ::= { pwAtmCfgTable 1 } PwAtmCfgEntry ::= SEQUENCE { pwAtmCfgMaxCellConcatenation Unsigned32, pwAtmCfgFarEndMaxCellConcatenation Unsigned32, pwAtmCfgTimeoutMode INTEGER, pwAtmClpQosMapping TruthValue } pwAtmCfgMaxCellConcatenation OBJECT-TYPE SYNTAX Unsigned32 (1..29) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of ATM cells that can be concatenated into one PW packet towards the PSN. In a non-LDP or other signaling protocol environment, this object MAY be changed at anytime, but traffic might be interrupted; otherwise, it may be changed when PW is not active." ::= { pwAtmCfgEntry 1 } pwAtmCfgFarEndMaxCellConcatenation OBJECT-TYPE SYNTAX Unsigned32 (1..29) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of ATM cells that can be concatenated into one PW packet towards PSN as reported by the far end. If there is no LDP in use, the object will either return a value of 0 or allow setting it for calculating protocol overhead." ::= { pwAtmCfgEntry 2 } pwAtmCfgTimeoutMode OBJECT-TYPE SYNTAX INTEGER { notApplicable (1), disabled (2), enabled (3) } Nicklass & Nadeau Standards Track [Page 15] RFC 5605 Manage ATM over PSN July 2009 MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines whether or not a packet can be transmitted to the PSN based on timeout expiration for collecting cells. The actual handling of the timeout is implementation-specific; as such, this object may be changed at any time under proper consideration of the traffic interruption effect." ::= { pwAtmCfgEntry 3 } pwAtmClpQosMapping OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the Cell Loss Priority (CLP) bits should be considered when setting the value in the Quality-of-Service fields of the encapsulating protocol (e.g., EXP fields of the MPLS Label Stack). Selecting True allows the drop precedence to be preserved across the PSN. In transparent cell transport, the value of this object MUST be false(2); in other cases, it can be changed at any time." REFERENCE "See section 12 of [ATMENCAP]." ::= { pwAtmCfgEntry 4 } -- Device capable of implementing N:1, 1:1, and transparent cell -- mode assumes to support the N:1 table for all -- modes with respective applicable setting. -- In such implementation, user can create an entry for either -- 1:1 or transparent cell transport modes only -- in pwAtmInboundNto1Table. The side effect of such -- will be an automatic create of the respective line in the -- pwAtmOutboundNto1Table. -- ATM PW Outbound Table for N to 1 connection pwAtmOutboundNto1Table OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmOutboundNto1Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the information for an ATM PW to be carried over the PSN in the outbound direction. Up to N entries can be created in this table for every Nicklass & Nadeau Standards Track [Page 16] RFC 5605 Manage ATM over PSN July 2009 entry in the pwTable with a pwType equal to: atmCellNto1Vcc(9) or atmCellNto1Vpc(10). An entry can be created only when the VP/VC are known. A single entry will be created in this table for every entry in the pwTable with a pwType equal to one of the following: atmCell1to1Vcc(12), atmCell1to1Vpc(13), atmAal5PduVcc(14), atmAal5SduVcc(2), or atmTransparent(3). " ::= { pwAtmObjects 6 } pwAtmOutboundNto1Entry OBJECT-TYPE SYNTAX PwAtmOutboundNto1Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table represents an ATM PW that needs to be adapted and carried over PSN. This table is indexed by pwIndex from pwTable and the ATM interface with VPL/VCLs. In atmTransparent(3), Vpi and VCi will be 0xFFFF during set operation. Unless otherwise specified, all read-create objects in this table MUST NOT be changed after row activation and SHOULD remain unchanged after reboot." INDEX { pwIndex, pwAtmOutboundNto1AtmIf , pwAtmOutboundNto1Vpi, pwAtmOutboundNto1Vci } ::= { pwAtmOutboundNto1Table 1 } PwAtmOutboundNto1Entry ::= SEQUENCE { pwAtmOutboundNto1AtmIf InterfaceIndex, pwAtmOutboundNto1Vpi AtmVpIdentifier, pwAtmOutboundNto1Vci AtmVcIdentifier, pwAtmOutboundNto1RowStatus RowStatus, pwAtmOutboundNto1TrafficParamDescr RowPointer, pwAtmOutboundNto1MappedVpi AtmVpIdentifier, pwAtmOutboundNto1MappedVci AtmVcIdentifier } pwAtmOutboundNto1AtmIf OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM Interface that receives cells from the ATM network." ::= { pwAtmOutboundNto1Entry 1 } pwAtmOutboundNto1Vpi OBJECT-TYPE Nicklass & Nadeau Standards Track [Page 17] RFC 5605 Manage ATM over PSN July 2009 SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "VPI value of this ATM PW. In atmTransparent(3), Vpi will be the equivalent of 0xFFFF." ::= { pwAtmOutboundNto1Entry 2 } pwAtmOutboundNto1Vci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "VCI value of this ATM PW. In atmTransparent(3), or the VP case, the value will be the equivalent of 0xFFFF." ::= { pwAtmOutboundNto1Entry 3 } pwAtmOutboundNto1RowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify or delete a row in this table." ::= { pwAtmOutboundNto1Entry 4 } pwAtmOutboundNto1TrafficParamDescr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents a pointer to an ATM traffic-parameter- specific row in either private or standard table that will be employed while receiving cells from the ATM network. This table should contain a set of self-consistent ATM traffic parameters including the ATM traffic service category. A value of 0.0 indicates Best Effort." ::= { pwAtmOutboundNto1Entry 5 } pwAtmOutboundNto1MappedVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The egress-generated VPI value of this ATM PW. The Nicklass & Nadeau Standards Track [Page 18] RFC 5605 Manage ATM over PSN July 2009 entry is valid for PW type of atmCellNto1Vcc(9), atmCellNto1Vpc(10), atmCell1to1Vcc(12), or atmCell1to1Vpc(13). In other types, the value will be the equivalent of 0xFFFF. Value MAY be changed when the PW is defined as not active. " ::= { pwAtmOutboundNto1Entry 6 } pwAtmOutboundNto1MappedVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The egress-generated VCI value of this ATM PW. The entry is valid for PW type of atmCellNto1Vcc(9), atmCellNto1Vpc(10), atmCell1to1Vcc(12), or atmCell1to1Vpc(13. In the VP case or other types, the value will be the equivalent of 0xFFFF. Value MAY be changed when the PW is defined as not active." ::= { pwAtmOutboundNto1Entry 7 } -- ATM PW Inbound Table for N to 1 connection pwAtmInboundNto1Table OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmInboundNto1Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the information for an ATM PW to be carried over PSN in the Inbound direction. Up to N entries can be created in this table for every entry in the pwTable with a pwType equal to: atmCellNto1Vcc(9) or atmCellNto1Vpc(10). An entry can be created only when the VP/VC are known. A single entry will be created in this table for every entry in the pwTable with a pwType equal to one of the following: atmCell1to1Vcc(12), atmCell1to1Vpc(13), atmAal5PduVcc(14), atmAal5SduVcc(2), or atmTransparent(3)." ::= { pwAtmObjects 7 } pwAtmInboundNto1Entry OBJECT-TYPE SYNTAX PwAtmInboundNto1Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in this table represents an ATM PW that needs to be adapted and carried over PSN. This table is indexed by Nicklass & Nadeau Standards Track [Page 19] RFC 5605 Manage ATM over PSN July 2009 pwIndex from pwTable and the ATM interface with VPL/VCLs. In atmTransparent(3), Vpi and VCi will be 0xFFFF during set operation. Unless otherwise specified, all Read-Create objects in this table MUST NOT be changed after row activation and SHOULD remain unchanged after reboot." INDEX { pwIndex, pwAtmInboundNto1AtmIf , pwAtmInboundNto1Vpi, pwAtmInboundNto1Vci } ::= { pwAtmInboundNto1Table 1 } PwAtmInboundNto1Entry ::= SEQUENCE { pwAtmInboundNto1AtmIf InterfaceIndex, pwAtmInboundNto1Vpi AtmVpIdentifier, pwAtmInboundNto1Vci AtmVcIdentifier, pwAtmInboundNto1RowStatus RowStatus, pwAtmInboundNto1TrafficParamDescr RowPointer, pwAtmInboundNto1MappedVpi AtmVpIdentifier, pwAtmInboundNto1MappedVci AtmVcIdentifier } pwAtmInboundNto1AtmIf OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM Interface that receives cells from the ATM network." ::= { pwAtmInboundNto1Entry 1 } pwAtmInboundNto1Vpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "VPI value of this ATM PW. In atmTransparent(3), Vpi will be the equivalent of 0xFFFF." ::= { pwAtmInboundNto1Entry 2 } pwAtmInboundNto1Vci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "VCI value of this ATM PW. In atmTransparent(3), or the VP case, the value will be the equivalent of 0xFFFF." ::= { pwAtmInboundNto1Entry 3 } Nicklass & Nadeau Standards Track [Page 20] RFC 5605 Manage ATM over PSN July 2009 pwAtmInboundNto1RowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify, or delete a row in this table." ::= { pwAtmInboundNto1Entry 4 } pwAtmInboundNto1TrafficParamDescr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents a pointer to an ATM traffic-parameter- specific row in either a private or standard table that will be employed while receiving cells from the ATM network. This table should contain a set of self-consistent ATM traffic parameters including the ATM traffic service category. A value of 0.0 indicates Best Effort." ::= { pwAtmInboundNto1Entry 5 } pwAtmInboundNto1MappedVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The generated VPI value of this ATM PW. The entry is valid for PW type of atmCellNto1Vcc(9), atmCellNto1Vpc(10), atmCell1to1Vcc(12), or atmCell1to1Vpc(13). In other types, the value will be the equivalent of 0xFFFF. Value MAY be changed when the PW is defined as not active." ::= { pwAtmInboundNto1Entry 6 } pwAtmInboundNto1MappedVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The generated VCI value of this ATM PW. The entry is valid for PW type of atmCellNto1Vcc(9), atmCellNto1Vpc(10), atmCell1to1Vcc(12), or atmCell1to1Vpc(13. In the VP case or other types, the value will be the equivalent of 0xFFFF. Value MAY be changed when the Nicklass & Nadeau Standards Track [Page 21] RFC 5605 Manage ATM over PSN July 2009 PW is defined as not active." ::= { pwAtmInboundNto1Entry 7 } -- ATM PW Outbound Perf Table -- The following supplement the counters presented in the -- PW generic MIB -- ATM PW Performance Current Table. pwAtmPerfCurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmPerfCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The current 15-minute interval counts are in this table. This table provides performance information per ATM PW." ::= { pwAtmObjects 8 } pwAtmPerfCurrentEntry OBJECT-TYPE SYNTAX PwAtmPerfCurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every pwAtmCfgTable entry. After 15 minutes, the contents of this table entry are copied to a new entry in the pwAtmPerfInterval table and the counts in this entry are reset to zero." INDEX { pwIndex } ::= { pwAtmPerfCurrentTable 1 } PwAtmPerfCurrentEntry ::= SEQUENCE { pwAtmPerfCurrentMissingPkts PerfCurrentCount, pwAtmPerfCurrentPktsReOrder PerfCurrentCount, pwAtmPerfCurrentPktsMisOrder PerfCurrentCount, pwAtmPerfCurrentPktsTimeout PerfCurrentCount, pwAtmPerfCurrentCellsXmit PerfCurrentCount, pwAtmPerfCurrentCellsDropped PerfCurrentCount, pwAtmPerfCurrentCellsReceived PerfCurrentCount, pwAtmPerfCurrentUnknownCells PerfCurrentCount } pwAtmPerfCurrentMissingPkts OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current Nicklass & Nadeau Standards Track [Page 22] RFC 5605 Manage ATM over PSN July 2009 DESCRIPTION "Number of missing packets (as detected via control word sequence number gaps)." ::= { pwAtmPerfCurrentEntry 1 } pwAtmPerfCurrentPktsReOrder OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of sequence (via control word sequence number), but successfully re-ordered. Note: some implementations may not support this feature." ::= { pwAtmPerfCurrentEntry 2 } pwAtmPerfCurrentPktsMisOrder OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of order (via control word sequence numbers)." ::= { pwAtmPerfCurrentEntry 3 } pwAtmPerfCurrentPktsTimeout OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets transmitted due to timeout expiration while attempting to collect cells." ::= { pwAtmPerfCurrentEntry 4 } pwAtmPerfCurrentCellsXmit OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of transmitted cells." ::= { pwAtmPerfCurrentEntry 5 } pwAtmPerfCurrentCellsDropped OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of dropped cells." ::= { pwAtmPerfCurrentEntry 6 } Nicklass & Nadeau Standards Track [Page 23] RFC 5605 Manage ATM over PSN July 2009 pwAtmPerfCurrentCellsReceived OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of received cells." ::= { pwAtmPerfCurrentEntry 7 } pwAtmPerfCurrentUnknownCells OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of cells received from the PSN with unknown VPI or VCI values. This object is relevant only in N:1 mode." ::= { pwAtmPerfCurrentEntry 8 } -- End ATM PW Performance Current Interval Table -- ATM PW Performance Interval Table. pwAtmPerfIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides performance information per ATM PW similar to the pwAtmPerfCurrentTable above. However, these counts represent historical 15 minute intervals. Typically, this table will have a maximum of 96 entries for a 24 hour period. " ::= { pwAtmObjects 9 } pwAtmPerfIntervalEntry OBJECT-TYPE SYNTAX PwAtmPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the agent for every pwAtmPerfCurrentEntry that is 15 minutes old. The contents of the Current entry are copied to the new entry here. The Current entry then resets its counts to zero for the next current 15 minute interval. " INDEX { pwIndex, pwAtmPerfIntervalNumber } ::= { pwAtmPerfIntervalTable 1 } PwAtmPerfIntervalEntry ::= SEQUENCE { pwAtmPerfIntervalNumber Unsigned32, Nicklass & Nadeau Standards Track [Page 24] RFC 5605 Manage ATM over PSN July 2009 pwAtmPerfIntervalValidData TruthValue, pwAtmPerfIntervalDuration Unsigned32, pwAtmPerfIntervalMissingPkts PerfIntervalCount, pwAtmPerfIntervalPktsReOrder PerfIntervalCount, pwAtmPerfIntervalPktsMisOrder PerfIntervalCount, pwAtmPerfIntervalPktsTimeout PerfIntervalCount, pwAtmPerfIntervalCellsXmit PerfIntervalCount, pwAtmPerfIntervalCellsDropped PerfIntervalCount, pwAtmPerfIntervalCellsReceived PerfIntervalCount, pwAtmPerfIntervalUnknownCells PerfIntervalCount } pwAtmPerfIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number (normally between 1 and 96 to cover a 24 hour period) that identifies the interval for which the set of statistics is available. The interval identified by 1 is the most recently completed 15 minute interval, and the interval identified by N is the interval immediately preceding the one identified by N-1. The minimum range of N is 1 through 4. The default range is 1 through 32. The maximum value of N is 96." ::= { pwAtmPerfIntervalEntry 1 } pwAtmPerfIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { pwAtmPerfIntervalEntry 2 } pwAtmPerfIntervalDuration OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The duration of a particular interval in seconds. Adjustments in the system's time-of-day clock, may cause the interval to be greater or less than the normal value. Therefore, this actual interval value is provided." ::= { pwAtmPerfIntervalEntry 3 } Nicklass & Nadeau Standards Track [Page 25] RFC 5605 Manage ATM over PSN July 2009 pwAtmPerfIntervalMissingPkts OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of missing packets (as detected via control word sequence number gaps)." ::= { pwAtmPerfIntervalEntry 4 } pwAtmPerfIntervalPktsReOrder OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of sequence (via control word sequence number), but successfully re-ordered. Note: some implementations may not support this feature." ::= { pwAtmPerfIntervalEntry 5 } pwAtmPerfIntervalPktsMisOrder OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of order (via control word sequence numbers)." ::= { pwAtmPerfIntervalEntry 6 } pwAtmPerfIntervalPktsTimeout OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets transmitted due to timeout expiration." ::= { pwAtmPerfIntervalEntry 7 } pwAtmPerfIntervalCellsXmit OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of transmitted cells." ::= { pwAtmPerfIntervalEntry 8 } pwAtmPerfIntervalCellsDropped OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only Nicklass & Nadeau Standards Track [Page 26] RFC 5605 Manage ATM over PSN July 2009 STATUS current DESCRIPTION "Number of dropped cells." ::= { pwAtmPerfIntervalEntry 9 } pwAtmPerfIntervalCellsReceived OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of received cells." ::= { pwAtmPerfIntervalEntry 10 } pwAtmPerfIntervalUnknownCells OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION "Number of cells received from the PSN with unknown VPI or VCI values. This object is relevant only in N:1 mode." ::= { pwAtmPerfIntervalEntry 11 } -- End ATM PW Performance Interval Table -- ATM PW 1day Performance Table pwAtmPerf1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF PwAtmPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides performance information per ATM PW similar to the pwAtmPerfIntervalTable above. However, these counters represent historical one-day intervals up to one full month." ::= { pwAtmObjects 10 } pwAtmPerf1DayIntervalEntry OBJECT-TYPE SYNTAX PwAtmPerf1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry is created in this table by the agent for every entry in the pwAtmCfgTable table." INDEX { pwIndex,pwAtmPerf1DayIntervalNumber } ::= { pwAtmPerf1DayIntervalTable 1 } PwAtmPerf1DayIntervalEntry ::= SEQUENCE { Nicklass & Nadeau Standards Track [Page 27] RFC 5605 Manage ATM over PSN July 2009 pwAtmPerf1DayIntervalNumber Unsigned32, pwAtmPerf1DayIntervalValidData TruthValue, pwAtmPerf1DayIntervalDuration Unsigned32, pwAtmPerf1DayIntervalMissingPkts Counter32, pwAtmPerf1DayIntervalPktsReOrder Counter32, pwAtmPerf1DayIntervalPktsMisOrder Counter32, pwAtmPerf1DayIntervalPktsTimeout Counter32, pwAtmPerf1DayIntervalCellsXmit Counter32, pwAtmPerf1DayIntervalCellsDropped Counter32, pwAtmPerf1DayIntervalCellsReceived Counter32, pwAtmPerf1DayIntervalUnknownCells Counter32 } pwAtmPerf1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..365) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of intervals, where 1 indicates current day measured period and 2 and above indicate previous days, respectively." ::= { pwAtmPerf1DayIntervalEntry 1 } pwAtmPerf1DayIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if the data for this interval is valid." ::= { pwAtmPerf1DayIntervalEntry 2 } pwAtmPerf1DayIntervalDuration OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The duration of a particular interval in seconds. Adjustments in the system's time-of-day clock may cause the interval to be greater or less than the normal value. Therefore, this actual interval value is provided." ::= { pwAtmPerf1DayIntervalEntry 3 } pwAtmPerf1DayIntervalMissingPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Nicklass & Nadeau Standards Track [Page 28] RFC 5605 Manage ATM over PSN July 2009 DESCRIPTION "Number of missing packets (as detected via control word sequence number gaps)." ::= { pwAtmPerf1DayIntervalEntry 4 } pwAtmPerf1DayIntervalPktsReOrder OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of sequence (via control word sequence number), but successfully re-ordered. Note: some implementations may not support this feature." ::= { pwAtmPerf1DayIntervalEntry 5 } pwAtmPerf1DayIntervalPktsMisOrder OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets detected out of order (via control word sequence numbers) and that could not be re-ordered." ::= { pwAtmPerf1DayIntervalEntry 6 } pwAtmPerf1DayIntervalPktsTimeout OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets transmitted due to timeout expiration." ::= { pwAtmPerf1DayIntervalEntry 7 } pwAtmPerf1DayIntervalCellsXmit OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of transmitted cells." ::= { pwAtmPerf1DayIntervalEntry 8 } pwAtmPerf1DayIntervalCellsDropped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of dropped cells." ::= { pwAtmPerf1DayIntervalEntry 9 } Nicklass & Nadeau Standards Track [Page 29] RFC 5605 Manage ATM over PSN July 2009 pwAtmPerf1DayIntervalCellsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of received cells." ::= { pwAtmPerf1DayIntervalEntry 10 } pwAtmPerf1DayIntervalUnknownCells OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of cells received from the PSN with unknown VPI or VCI values. This object is relevant only in N:1 mode." ::= { pwAtmPerf1DayIntervalEntry 11 } -- End of ATM PW Performance table pwAtmCompliances OBJECT IDENTIFIER ::= { pwAtmConformance 1 } pwAtmGroups OBJECT IDENTIFIER ::= { pwAtmConformance 2 } pwAtmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that support ATM PW." MODULE -- this module MANDATORY-GROUPS { pwAtmCfgGroup, pwAtmPerfGroup } OBJECT pwAtmCfgFarEndMaxCellConcatenation MIN-ACCESS read-only DESCRIPTION "The ability to set this object is not required." GROUP pwAtmOutbound1to1Group DESCRIPTION "This group is mandatory only for implementations that support the ATM PW 1:1 mode and not using the Nto1 table." GROUP pwAtmInbound1to1Group DESCRIPTION "This group is mandatory only for implementations that support the ATM PW 1:1 mode and not using the Nto1 table." GROUP pwAtmOutboundNto1Group Nicklass & Nadeau Standards Track [Page 30] RFC 5605 Manage ATM over PSN July 2009 DESCRIPTION "This group is mandatory only for implementations that support the ATM PW N:1 and transparent mode." GROUP pwAtmInboundNto1Group DESCRIPTION "This group is mandatory only for implementations that support the ATM PW N:1 and transparent mode." ::= { pwAtmCompliances 2 } -- Units of conformance. pwAtmCfgGroup OBJECT-GROUP OBJECTS {pwAtmCfgMaxCellConcatenation, pwAtmCfgFarEndMaxCellConcatenation, pwAtmCfgTimeoutMode, pwAtmClpQosMapping } STATUS current DESCRIPTION "Collection of objects for basic ATM PW configuration." ::= { pwAtmGroups 5 } pwAtmPerfGroup OBJECT-GROUP OBJECTS {pwAtmPerfCurrentMissingPkts, pwAtmPerfCurrentPktsReOrder, pwAtmPerfCurrentPktsMisOrder, pwAtmPerfCurrentPktsTimeout, pwAtmPerfCurrentCellsXmit, pwAtmPerfCurrentCellsDropped, pwAtmPerfCurrentCellsReceived, pwAtmPerfCurrentUnknownCells, pwAtmPerfIntervalValidData, pwAtmPerfIntervalDuration, pwAtmPerfIntervalMissingPkts, pwAtmPerfIntervalPktsReOrder, pwAtmPerfIntervalPktsMisOrder, pwAtmPerfIntervalPktsTimeout, pwAtmPerfIntervalCellsXmit, pwAtmPerfIntervalCellsDropped, pwAtmPerfIntervalCellsReceived, pwAtmPerfIntervalUnknownCells, pwAtmPerf1DayIntervalValidData, pwAtmPerf1DayIntervalDuration, pwAtmPerf1DayIntervalMissingPkts, pwAtmPerf1DayIntervalPktsReOrder, pwAtmPerf1DayIntervalPktsMisOrder, Nicklass & Nadeau Standards Track [Page 31] RFC 5605 Manage ATM over PSN July 2009 pwAtmPerf1DayIntervalPktsTimeout, pwAtmPerf1DayIntervalCellsXmit, pwAtmPerf1DayIntervalCellsDropped, pwAtmPerf1DayIntervalCellsReceived, pwAtmPerf1DayIntervalUnknownCells } STATUS current DESCRIPTION "Collection of objects for basic ATM PW Performance." ::= { pwAtmGroups 6 } pwAtmOutbound1to1Group OBJECT-GROUP OBJECTS {pwAtmOutboundAtmIf, pwAtmOutboundVpi, pwAtmOutboundVci, pwAtmOutboundTrafficParamDescr, pwAtmOutboundRowStatus } STATUS current DESCRIPTION "Collection of objects for basic 1:1 ATM PW outbound configuration." ::= { pwAtmGroups 7 } pwAtmInbound1to1Group OBJECT-GROUP OBJECTS {pwAtmInboundAtmIf, pwAtmInboundVpi, pwAtmInboundVci, pwAtmInboundTrafficParamDescr, pwAtmInboundRowStatus } STATUS current DESCRIPTION "Collection of objects for basic 1:1 ATM PW inbound configuration." ::= { pwAtmGroups 8 } pwAtmOutboundNto1Group OBJECT-GROUP OBJECTS {pwAtmOutboundNto1RowStatus, pwAtmOutboundNto1TrafficParamDescr, pwAtmOutboundNto1MappedVpi, pwAtmOutboundNto1MappedVci } STATUS current DESCRIPTION "Collection of objects for N:1, 1:1, or transparent ATM PW outbound configuration." ::= { pwAtmGroups 9 } Nicklass & Nadeau Standards Track [Page 32] RFC 5605 Manage ATM over PSN July 2009 pwAtmInboundNto1Group OBJECT-GROUP OBJECTS {pwAtmInboundNto1RowStatus, pwAtmInboundNto1TrafficParamDescr, pwAtmInboundNto1MappedVpi, pwAtmInboundNto1MappedVci } STATUS current DESCRIPTION "Collection of objects for N:1, 1:1, or transparent ATM PW inbound configuration." ::= { pwAtmGroups 10 } END 10. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: The pwAtmOutboundTable, pwAtmInboundTable, pwAtmCfgTable, pwAtmOutboundNto1Table, and pwAtmInboundNto1Table contain objects of ATM PW parameters on a Provider Edge (PE) device. Unauthorized access to objects in these tables could result in disruption of traffic on the network. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any SNMPV3 agent, which implements this MIB module. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Nicklass & Nadeau Standards Track [Page 33] RFC 5605 Manage ATM over PSN July 2009 The pwATMCfgTable, pwAtmPerfCurrentTable, pwAtmPerfIntervalTable, and pwAtmPerf1DayIntervalTable collectively show the ATM pseudowire connectivity topology and its performance characteristics. If an Administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pwATMMIB { mib-2 183 } 12. References 12.1. Normative References [PWTC] Nadeau, T., Ed., Zelig, D., Ed., and O. Nicklass, Ed., "Definitions of Textual Conventions for Pseudowire (PW) Management", RFC 5542, May 2009. [PWMIB] Nadeau, T., Ed. and D. Zelig, Ed., "Pseudowire (PW) Management Information Base (MIB)", RFC 5601, July 2009. Nicklass & Nadeau Standards Track [Page 34] RFC 5605 Manage ATM over PSN July 2009 [PWMPLSMIB] Zelig, D., Ed. and T. Nadeau, Ed., "Pseudowire (PW) over MPLS PSN Management Information Base (MIB)", RFC 5602, July 2009. [ATMENCAP] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006. [ATMTRANS] Malis, A., Martini, L., Brayley, J., and T. Walsh, "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service", RFC 4816, February 2007. [AToM] Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. [AToMTC] Noto, M., Spiegel, E., and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. [LDPMIB] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004. [TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [IFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Nicklass & Nadeau Standards Track [Page 35] RFC 5605 Manage ATM over PSN July 2009 12.2. Informative References [PWREQ] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [PWARCH] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. 13. Acknowledgements This document was produced by the PWE3 Working Group. Special thanks to Senthilkumar Sathappan and Marichetty Venkatesan for their initial contribution and to Bert Wijnen for close review and good suggestions. Authors' Addresses Orly Nicklass RADVISION Ltd. 24 Raul Wallenberg St. Tel Aviv ISRAEL Phone: +972 3 7679444 EMail: orlyn@radvision.com Thomas D. Nadeau BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom EMail: tom.nadeau@bt.com Nicklass & Nadeau Standards Track [Page 36] snmp-mibs-downloader-1.1/mibrfcs/rfc5643.txt0000644000000000000000000057066111402176072015603 0ustar Network Working Group D. Joyal, Ed. Request for Comments: 5643 Nortel Category: Standards Track V. Manral, Ed. IP Infusion August 2009 Management Information Base for OSPFv3 Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Joyal & Manral Standards Track [Page 1] RFC 5643 OSPFv3 MIB August 2009 Table of Contents 1. The Internet-Standard Management Framework ......................3 2. Overview ........................................................3 2.1. IPv6 Interfaces ............................................3 2.2. Addressing Semantics .......................................4 2.3. Authentication .............................................4 2.4. Type of Service ............................................4 2.5. Flooding Scope .............................................4 2.6. Virtual Links ..............................................4 2.7. Neighbors ..................................................5 2.8. OSPFv3 Counters ............................................5 2.9. Multiple OSPFv3 Instances ..................................5 2.10. Notifications .............................................5 2.11. Conventions ...............................................6 3. OSPFv3 Notification Overview ....................................6 3.1. Introduction ...............................................6 3.2. Ignoring Initial Activity ..................................6 3.3. Throttling Notifications ...................................6 3.4. One Notification per OSPFv3 Event ..........................7 3.5. Polling Event Counters .....................................7 4. Structure of the OSPFv3 MIB Module ..............................7 4.1. General Variables ..........................................8 4.2. Area Table .................................................8 4.3. Area-Scope, Link-Scope, and AS-Scope Link State Database ...8 4.4. Host Table .................................................8 4.5. Interface Table ............................................8 4.6. Virtual Interface Table ....................................8 4.7. Neighbor, Configured Neighbor, and Virtual Neighbor Tables .....................................................8 4.8. Area Aggregate Table .......................................8 4.9. Notifications ..............................................9 5. Definitions .....................................................9 6. Security Considerations ........................................92 7. IANA Considerations ............................................93 8. Acknowledgements ...............................................93 9. References .....................................................93 9.1. Normative References ......................................93 9.2. Informative References ....................................94 Joyal & Manral Standards Track [Page 2] RFC 5643 OSPFv3 MIB August 2009 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 2. Overview This memo defines a portion of the Management Information Base (MIB) for managing the Open Shortest Path First Routing Protocol for IPv6 [RFC5340], otherwise known as OSPF version 3 (OSPFv3). Though the fundamental mechanisms of OSPF version 2 (OSPFv2) [RFC2328] remain unchanged in OSPFv3, some changes were necessary due to differences in IP address size and in protocol semantics between IPv4 and IPv6. In many cases, where the protocol operations have not changed from OSPFv2, the specification for OSPFv3 does not restate the details but instead refers to the relevant sections in the OSPFv2 specification. This MIB module follows along the same lines and includes Reference clauses referring to the OSPFv2 specification when applicable. 2.1. IPv6 Interfaces IPv6 interfaces attach to links [RFC2460]. A link is roughly defined as the layer below IPv6 (e.g., Ethernet, IPv4 Tunnel). One or more IPv6 prefixes can be associated with an IPv6 interface. IPv6 interfaces and the prefixes associated with those interfaces can be configured via the IP-MIB [RFC4293]. IPv6 interfaces are configured in the IPv6 Interface Table and IPv6 prefixes are configured in the Internet Address Prefix Table. An IPv6 interface is identified by a unique index value. IPv6 Address Prefix Table entries associated with an IPv6 interface reference the interface's index. Whereas an Interface Identifier in OSPFv2 is a local IPv4 address or MIB-2 interface index, an OSPFv3 Interface Identifier is an IPv6 interface index. For example, the index value of an OSPFv3 Interface Table entry is the IPv6 interface index of the IPv6 interface over which OSPFv3 is configured to operate. Joyal & Manral Standards Track [Page 3] RFC 5643 OSPFv3 MIB August 2009 2.2. Addressing Semantics Router ID, Area ID, and Link State ID remain at the OSPFv2 size of 32 bits. To ensure uniqueness, a router running both IPv4 and IPv6 concurrently can continue to use a local IPv4 host address, represented as an unsigned 32-bit value, as the OSPFv3 Router ID. Otherwise, the Router ID must be selected using another method (e.g., administratively assigned). Router ID, Area ID, and Link State ID do not have addressing semantics in OSPFv3, so their syntax is changed to Unsigned32. The Router ID index component comes before the Link State ID index component in the OSPFv3 MIB module because the lack of addressing semantics in Link State IDs makes them less unique identifiers than the Router ID. It is more useful to do partial Object Identifier (OID) lookups extending to the Router ID rather than the Link State ID. 2.3. Authentication In OSPFv3, authentication has been removed from the protocol itself. MIB objects related to authentication are not carried forward from the OSPFv2 MIB module. 2.4. Type of Service OSPFv2 MIB module objects related to Type of Service (ToS) are not carried forward to the OSPFv3 MIB module. 2.5. Flooding Scope Flooding scope for link state advertisements (LSAs) has been generalized and is now explicitly encoded in the LSA's LS type field. The action to take upon receipt of unknown LSA types is also encoded in the LS type field [RFC5340]. The OSPFv3 MIB module defines three Link State Database tables, one each for Area-scope LSAs, Link-scope LSAs, and Autonomous System (AS)-scope LSAs. 2.6. Virtual Links Since addressing semantics have been removed from router-LSAs in OSPFv3, virtual links now need to be assigned an Interface ID for advertisement in Hello packets and in router-LSAs. A read-only object has been added to the Virtual Interface Table entry to view the assigned Interface ID. Joyal & Manral Standards Track [Page 4] RFC 5643 OSPFv3 MIB August 2009 2.7. Neighbors The OSPFv3 Neighbor Table is a read-only table that contains information learned from Hellos received from neighbors, including configured neighbors. The OSPFv3 Configured Neighbor Table contains entries for manually configured neighbors for use on non-broadcast multi-access (NBMA) and Point-to-Multipoint interface types. 2.8. OSPFv3 Counters This MIB module defines several counters, namely: - ospfv3OriginateNewLsas and ospfv3RxNewLsas in the ospfv3GeneralGroup - ospfv3AreaSpfRuns and ospfv3AreaNssaTranslatorEvents in the ospfv3AreaTable - ospfv3IfEvents in the ospfv3IfTable - ospfv3VirtIfEvents in the ospfv3VirtIfTable - ospfv3NbrEvents in the ospfv3NbrTable - ospfv3VirtNbrEvents in the ospfv3VirtNbrTable As a best practice, a management entity, when reading these counters, should use the discontinuity object, ospfv3DiscontinuityTime, to determine if an event that would invalidate the management entity understanding of the counters has occurred. A restart of the OSPFv3 routing process is an example of a discontinuity event. 2.9. Multiple OSPFv3 Instances SNMPv3 supports "contexts" that can be used to implement MIB views on multiple OSPFv3 instances on the same system. See [RFC3411] or its successors for details. 2.10. Notifications Notifications define a set of notifications, objects, and mechanisms to enhance the ability to manage IP internetworks that use OSPFv3 as their Interior Gateway Protocol (IGP). Joyal & Manral Standards Track [Page 5] RFC 5643 OSPFv3 MIB August 2009 2.11. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. OSPFv3 Notification Overview 3.1. Introduction OSPFv3 is an event-driven routing protocol, where an event can be a change in an OSPFv3 interface's link-level status, the expiration of an OSPFv3 timer, or the reception of an OSPFv3 protocol packet. Many of the actions that OSPFv3 takes as a result of these events will result in a change of the routing topology. As routing topologies become large and complex, it is often difficult to locate the source of a topology change or unpredicted routing path by polling a large number or routers. Because of the difficulty of polling a large number of devices, a more prudent approach is for devices to notify a network manager of potentially critical OSPF events using SNMP notifications. The ospfv3NotificationEnable object provides a coarse level of control over the generation of OSPFv3 notifications. It can be used to completely enable or disable generation of OSPFv3 notifications. Fine-grain control of individual notifications can be accomplished by utilizing the objects defined in RFC 3413 [RFC3413], specifically those described in Section 6. 3.2. Ignoring Initial Activity The majority of critical events occur when OSPFv3 is enabled on a router, at which time the Designated Router is elected and neighbor adjacencies are formed. During this initial period, a potential flood of notifications is unnecessary since the events are expected. To avoid unnecessary notifications, a router should not originate expected OSPFv3 interface-related notifications until two of that interface's dead timer intervals have elapsed. The expected OSPFv3 interface notifications are ospfv3IfStateChange, ospfv3VirtIfStateChange, ospfv3NbrStateChange, and ospfv3VirtNbrStateChange. 3.3. Throttling Notifications The mechanism for throttling the notifications is similar to the mechanism explained in RFC 1224 [RFC1224]. The basic premise of the throttling mechanism is that of a sliding window, defined in seconds Joyal & Manral Standards Track [Page 6] RFC 5643 OSPFv3 MIB August 2009 and with an upper bound on the number of notifications that may be generated within this window. Note that unlike RFC 1224, notifications are not sent to inform the network manager that the throttling mechanism has kicked in. A single window should be used to throttle all OSPFv3 notifications types except for the ospfv3LsdbOverflow and the ospfv3LsdbApproachingOverflow notifications, which should not be throttled. For example, with a window time of 3, an upper bound of 3, and events to cause notifications 1, 2, 3, and 4 (4 notifications within a 3-second period), the 4th notification should not be generated. Appropriate values are 7 notifications with a window time of 10 seconds. 3.4. One Notification per OSPFv3 Event Several of the notifications defined in this MIB module are generated as the result of finding an unusual condition while parsing an OSPFv3 packet or processing a timer event. There may be more than one unusual condition detected while handling the event. For example, a Link State Update packet may contain several retransmitted link state advertisements (LSAs), or a retransmitted database description packet may contain several database description entries. To limit the number of notifications and variables, OSPFv3 should generate at most one notification per OSPFv3 event. Only the variables associated with the first unusual condition should be included with the notification. Similarly, if more than one type of unusual condition is encountered while parsing the packet, only the first event will generate a notification. 3.5. Polling Event Counters Many of the tables in the OSPFv3 MIB module contain generalized event counters. By enabling the notifications defined in this document, a network manager can obtain more specific information about these events. A network manager may want to poll these event counters and enable OSPFv3 notifications when a particular counter starts increasing abnormally. 4. Structure of the OSPFv3 MIB Module The MIB is composed of the following sections: General Variables Area Table Area-Scope Link State Database Joyal & Manral Standards Track [Page 7] RFC 5643 OSPFv3 MIB August 2009 Link-Scope Link State Databases (non-virtual and virtual) AS-Scope Link State Database Host Table Interface Table Virtual Interface Table Neighbor Table Configured Neighbor Table Virtual Neighbor Table Area Aggregate Table Notifications 4.1. General Variables The General Variables are global to the OSPFv3 Process. 4.2. Area Table The Area Data Structure describes the OSPFv3 Areas that the router participates in. 4.3. Area-Scope, Link-Scope, and AS-Scope Link State Database The link state databases are provided primarily to provide detailed information for network debugging. There are separate tables for Link-scope LSAs received over non-virtual and virtual interfaces. 4.4. Host Table The Host Table is provided to view configured Host Route information. 4.5. Interface Table The Interface Table describes the various IPv6 links on which OSPFv3 is configured. 4.6. Virtual Interface Table The Virtual Interface Table describes virtual OSPFv3 links. 4.7. Neighbor, Configured Neighbor, and Virtual Neighbor Tables The Neighbor Table, the Configured Neighbor Table, and the Virtual Neighbor Table describe the neighbors to the OSPFv3 Process. 4.8. Area Aggregate Table The Area Aggregate Table describes prefixes, which summarize routing information for export outside of an Area. Joyal & Manral Standards Track [Page 8] RFC 5643 OSPFv3 MIB August 2009 4.9. Notifications Notifications are defined for OSPFv3 events. Several objects are defined specifically as variables to be used with notifications. 5. Definitions OSPFV3-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Counter32, Gauge32, Integer32, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, RowStatus, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB InetAddressType, InetAddress, InetAddressPrefixLength, InetAddressIPv6 FROM INET-ADDRESS-MIB Metric, BigMetric, Status, HelloRange, DesignatedRouterPriority FROM OSPF-MIB; ospfv3MIB MODULE-IDENTITY LAST-UPDATED "200908130000Z" ORGANIZATION "IETF OSPF Working Group" CONTACT-INFO "WG E-Mail: ospf@ietf.org WG Chairs: Acee Lindem acee@redback.com Abhay Roy akr@cisco.com Editors: Dan Joyal Nortel 600 Technology Park Drive Billerica, MA 01821, USA djoyal@nortel.com Vishwas Manral IP Infusion Almora, Uttarakhand India vishwas@ipinfusion.com" Joyal & Manral Standards Track [Page 9] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "The MIB module for OSPF version 3. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5643; see the RFC itself for full legal notices." REVISION "200908130000Z" DESCRIPTION "Initial version, published as RFC 5643" ::= { mib-2 191 } Joyal & Manral Standards Track [Page 10] RFC 5643 OSPFv3 MIB August 2009 -- Textual conventions Ospfv3UpToRefreshIntervalTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The values one might be able to configure for variables bounded by the Refresh Interval." REFERENCE "OSPF Version 2, Appendix B, Architectural Constants" SYNTAX Unsigned32 (1..1800) Ospfv3DeadIntervalRangeTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The range, in seconds, of dead interval value." REFERENCE "OSPF for IPv6, Appendix C.3, Router Interface Parameters" SYNTAX Unsigned32 (1..'FFFF'h) Ospfv3RouterIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A 32-bit, unsigned integer uniquely identifying the router in the Autonomous System. To ensure uniqueness, this may default to the value of one of the router's IPv4 host addresses if IPv4 is configured on the router." REFERENCE "OSPF for IPv6, Appendix C.1, Global Parameters" SYNTAX Unsigned32 (1..'FFFFFFFF'h) Ospfv3LsIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique 32-bit identifier of the piece of the routing domain that is being described by a link state advertisement. In contrast to OSPFv2, the Link State ID (LSID) has no addressing semantics." REFERENCE "OSPF Version 2, Section 12.1.4, Link State ID" SYNTAX Unsigned32 (1..'FFFFFFFF'h) Ospfv3AreaIdTC ::= TEXTUAL-CONVENTION Joyal & Manral Standards Track [Page 11] RFC 5643 OSPFv3 MIB August 2009 DISPLAY-HINT "d" STATUS current DESCRIPTION "An OSPFv3 Area Identifier. A value of zero identifies the backbone area." REFERENCE "OSPF for IPv6, Appendix C.3 Router Interface Parameters" SYNTAX Unsigned32 (0..'FFFFFFFF'h) Ospfv3IfInstIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An OSPFv3 Interface Instance ID." REFERENCE "OSPF for IPv6, Appendix C.3, Router Interface Parameters" SYNTAX Unsigned32 (0..255) Ospfv3LsaSequenceTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6, LS sequence number" SYNTAX Integer32 Ospfv3LsaAgeTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The age of the link state advertisement in seconds. The high-order bit of the LS age field is considered the DoNotAge bit for support of on-demand circuits." REFERENCE "OSPF Version 2, Section 12.1.1, LS age; Extending OSPF to Support Demand Circuits, Section 2.2, The LS age field" SYNTAX Unsigned32 (0..3600 | 32768..36368) Joyal & Manral Standards Track [Page 12] RFC 5643 OSPFv3 MIB August 2009 -- Top-level structure of MIB ospfv3Notifications OBJECT IDENTIFIER ::= { ospfv3MIB 0 } ospfv3Objects OBJECT IDENTIFIER ::= { ospfv3MIB 1 } ospfv3Conformance OBJECT IDENTIFIER ::= { ospfv3MIB 2 } -- OSPFv3 General Variables -- These parameters apply globally to the Router's -- OSPFv3 Process. ospfv3GeneralGroup OBJECT IDENTIFIER ::= { ospfv3Objects 1 } ospfv3RouterId OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS read-write STATUS current DESCRIPTION "A 32-bit unsigned integer uniquely identifying the router in the Autonomous System. To ensure uniqueness, this may default to the 32-bit unsigned integer representation of one of the router's IPv4 interface addresses (if IPv4 is configured on the router). This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF for IPv6, Appendix C.1, Global Parameters" ::= { ospfv3GeneralGroup 1 } ospfv3AdminStatus OBJECT-TYPE SYNTAX Status MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative status of OSPFv3 in the router. The value 'enabled' denotes that the OSPFv3 Process is active on at least one interface; 'disabled' disables it on all interfaces. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." ::= { ospfv3GeneralGroup 2 } Joyal & Manral Standards Track [Page 13] RFC 5643 OSPFv3 MIB August 2009 ospfv3VersionNumber OBJECT-TYPE SYNTAX INTEGER { version3 (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of OSPF for IPv6 is 3." ::= { ospfv3GeneralGroup 3 } ospfv3AreaBdrRtrStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "A flag to denote whether this router is an area border router. The value of this object is true (1) when the router is an area border router." REFERENCE "OSPF Version 2, Section 3, Splitting the AS into Areas" ::= { ospfv3GeneralGroup 4 } ospfv3ASBdrRtrStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "A flag to note whether this router is configured as an Autonomous System border router. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Section 3.3, Classification of routers" ::= { ospfv3GeneralGroup 5 } ospfv3AsScopeLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AS-scope (e.g., AS-External) link state advertisements in the link state database." ::= { ospfv3GeneralGroup 6 } ospfv3AsScopeLsaCksumSum OBJECT-TYPE SYNTAX Unsigned32 Joyal & Manral Standards Track [Page 14] RFC 5643 OSPFv3 MIB August 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit unsigned sum of the LS checksums of the AS-scoped link state advertisements contained in the link state database. This sum can be used to determine if there has been a change in a router's link state database or to compare the link state database of two routers." ::= { ospfv3GeneralGroup 7 } ospfv3OriginateNewLsas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of new link state advertisements that have been originated. This number is incremented each time the router originates a new LSA. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3GeneralGroup 8 } ospfv3RxNewLsas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of link state advertisements received that are determined to be new instantiations. This number does not include newer instantiations of self-originated link state advertisements. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3GeneralGroup 9 } ospfv3ExtLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only Joyal & Manral Standards Track [Page 15] RFC 5643 OSPFv3 MIB August 2009 STATUS current DESCRIPTION "The number of External (LS type 0x4005) in the link state database." ::= { ospfv3GeneralGroup 10 } ospfv3ExtAreaLsdbLimit OBJECT-TYPE SYNTAX Integer32 (-1..'7FFFFFFF'h) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of non-default AS-external-LSA entries that can be stored in the link state database. If the value is -1, then there is no limit. When the number of non-default AS-external-LSAs in a router's link state database reaches ospfv3ExtAreaLsdbLimit, the router enters Overflow state. The router never holds more than ospfv3ExtAreaLsdbLimit non-default AS-external-LSAs in its database. ospfv3ExtAreaLsdbLimit MUST be set identically in all routers attached to the OSPFv3 backbone and/or any regular OSPFv3 area (i.e., OSPFv3 stub areas and not-so-stubby-areas (NSSAs) are excluded). This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." ::= { ospfv3GeneralGroup 11 } ospfv3ExitOverflowInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of seconds that, after entering Overflow state, a router will attempt to leave Overflow state. This allows the router to again originate non-default, AS-External-LSAs. When set to 0, the router will not leave Overflow state until restarted. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." Joyal & Manral Standards Track [Page 16] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3GeneralGroup 12 } ospfv3DemandExtensions OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The router's support for demand circuits. The value of this object is true (1) when demand circuits are supported. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2; Extending OSPF to Support Demand Circuits" ::= { ospfv3GeneralGroup 13 } ospfv3ReferenceBandwidth OBJECT-TYPE SYNTAX Unsigned32 UNITS "kilobits per second" MAX-ACCESS read-write STATUS current DESCRIPTION "Reference bandwidth in kilobits per second for calculating default interface metrics. The default value is 100,000 KBPS (100 MBPS). This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Appendix C.3, Router interface parameters" DEFVAL { 100000 } ::= { ospfv3GeneralGroup 14 } ospfv3RestartSupport OBJECT-TYPE SYNTAX INTEGER { none(1), plannedOnly(2), plannedAndUnplanned(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The router's support for OSPF graceful restart. Options include no restart support, only planned Joyal & Manral Standards Track [Page 17] RFC 5643 OSPFv3 MIB August 2009 restarts, or both planned and unplanned restarts. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "Graceful OSPF Restart, Appendix B.1, Global Parameters (Minimum subset)" ::= { ospfv3GeneralGroup 15 } ospfv3RestartInterval OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Configured OSPF graceful restart timeout interval. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "Graceful OSPF Restart, Appendix B.1, Global Parameters (Minimum subset)" DEFVAL { 120 } ::= { ospfv3GeneralGroup 16 } ospfv3RestartStrictLsaChecking OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if strict LSA checking is enabled for graceful restart. A value of true (1) indicates that strict LSA checking is enabled. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "Graceful OSPF Restart, Appendix B.2, Global Parameters (Optional)" DEFVAL { true } ::= { ospfv3GeneralGroup 17 } ospfv3RestartStatus OBJECT-TYPE SYNTAX INTEGER { notRestarting(1), plannedRestart(2), unplannedRestart(3) } MAX-ACCESS read-only Joyal & Manral Standards Track [Page 18] RFC 5643 OSPFv3 MIB August 2009 STATUS current DESCRIPTION "The current status of OSPF graceful restart capability." ::= { ospfv3GeneralGroup 18 } ospfv3RestartAge OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in the current OSPF graceful restart interval." ::= { ospfv3GeneralGroup 19 } ospfv3RestartExitReason OBJECT-TYPE SYNTAX INTEGER { none(1), inProgress(2), completed(3), timedOut(4), topologyChanged(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the outcome of the last attempt at a graceful restart. none: no restart has yet been attempted. inProgress: a restart attempt is currently underway. completed: the last restart completed successfully. timedOut: the last restart timed out. topologyChanged: the last restart was aborted due to a topology change." ::= { ospfv3GeneralGroup 20 } ospfv3NotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides a coarse level of control over the generation of OSPFv3 notifications. If this object is set to true (1), then it enables the generation of OSPFv3 notifications. If it is set to false (2), these notifications are not generated. Joyal & Manral Standards Track [Page 19] RFC 5643 OSPFv3 MIB August 2009 This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." ::= { ospfv3GeneralGroup 21 } ospfv3StubRouterSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The router's support for stub router functionality. An object value of true (1) indicates that stub router functionality is supported." REFERENCE "OSPF Stub Router Advertisement" ::= { ospfv3GeneralGroup 22 } ospfv3StubRouterAdvertisement OBJECT-TYPE SYNTAX INTEGER { doNotAdvertise(1), advertise(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the advertisement of stub LSAs by the router. The value doNotAdvertise (1) will result in the advertisement of standard LSAs and is the default value. This object is persistent, and when written, the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Stub Router Advertisement, Section 2, Proposed Solution" DEFVAL { doNotAdvertise } ::= { ospfv3GeneralGroup 23 } ospfv3DiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one of this MIB's counters suffered a discontinuity. Joyal & Manral Standards Track [Page 20] RFC 5643 OSPFv3 MIB August 2009 If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { ospfv3GeneralGroup 24 } ospfv3RestartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which the ospfv3RestartExitReason was updated." ::= { ospfv3GeneralGroup 25 } -- The OSPFv3 Area Data Structure contains information -- regarding the various areas. The interfaces and -- virtual links are configured as part of these areas. -- Area 0, by definition, is the backbone area. ospfv3AreaTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3AreaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the configured parameters and cumulative statistics of the router's attached areas. The interfaces and virtual links are configured as part of these areas. Area 0, by definition, is the backbone area." REFERENCE "OSPF Version 2, Section 6, The Area Data Structure" ::= { ospfv3Objects 2 } ospfv3AreaEntry OBJECT-TYPE SYNTAX Ospfv3AreaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information describing the configured parameters and cumulative statistics of one of the router's attached areas. The information in this table is persistent, and when written, the entity SHOULD save the a change to non-volatile storage." INDEX { ospfv3AreaId } ::= { ospfv3AreaTable 1 } Joyal & Manral Standards Track [Page 21] RFC 5643 OSPFv3 MIB August 2009 Ospfv3AreaEntry ::= SEQUENCE { ospfv3AreaId Ospfv3AreaIdTC, ospfv3AreaImportAsExtern INTEGER, ospfv3AreaSpfRuns Counter32, ospfv3AreaBdrRtrCount Gauge32, ospfv3AreaAsBdrRtrCount Gauge32, ospfv3AreaScopeLsaCount Gauge32, ospfv3AreaScopeLsaCksumSum Unsigned32, ospfv3AreaSummary INTEGER, ospfv3AreaRowStatus RowStatus, ospfv3AreaStubMetric BigMetric, ospfv3AreaNssaTranslatorRole INTEGER, ospfv3AreaNssaTranslatorState INTEGER, ospfv3AreaNssaTranslatorStabInterval Unsigned32, ospfv3AreaNssaTranslatorEvents Counter32, ospfv3AreaStubMetricType INTEGER, ospfv3AreaTEEnabled TruthValue } ospfv3AreaId OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "A 32-bit unsigned integer uniquely identifying an area. Area ID 0 is used for the OSPFv3 backbone." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" ::= { ospfv3AreaEntry 1 } Joyal & Manral Standards Track [Page 22] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaImportAsExtern OBJECT-TYPE SYNTAX INTEGER { importExternal(1), -- normal area importNoExternal(2), -- stub area importNssa(3) -- not-so-stubby-area } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether an area is a stub area, NSSA, or standard area. AS-scope LSAs are not imported into stub areas or NSSAs. NSSAs import AS-External data as NSSA LSAs that have Area-scope." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" DEFVAL { importExternal } ::= { ospfv3AreaEntry 2 } ospfv3AreaSpfRuns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times that the intra-area route table has been calculated using this area's link state database. This is typically done using Dijkstra's algorithm. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3AreaEntry 3 } ospfv3AreaBdrRtrCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of area border routers reachable within this area. This is initially zero, and is calculated in each Shortest Path First (SPF) pass." DEFVAL { 0 } ::= { ospfv3AreaEntry 4 } Joyal & Manral Standards Track [Page 23] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaAsBdrRtrCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Autonomous System border routers reachable within this area. This is initially zero, and is calculated in each SPF pass." DEFVAL { 0 } ::= { ospfv3AreaEntry 5 } ospfv3AreaScopeLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Area-scope link state advertisements in this area's link state database." DEFVAL { 0 } ::= { ospfv3AreaEntry 6 } ospfv3AreaScopeLsaCksumSum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit unsigned sum of the Area-scope link state advertisements' LS checksums contained in this area's link state database. The sum can be used to determine if there has been a change in a router's link state database or to compare the link state database of two routers." ::= { ospfv3AreaEntry 7 } ospfv3AreaSummary OBJECT-TYPE SYNTAX INTEGER { noAreaSummary(1), sendAreaSummary(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable ospfv3AreaSummary controls the import of Inter-Area LSAs into stub and NSSA areas. It has no effect on other areas. Joyal & Manral Standards Track [Page 24] RFC 5643 OSPFv3 MIB August 2009 If it is noAreaSummary, the router will neither originate nor propagate Inter-Area LSAs into the stub or NSSA area. It will only advertise a default route. If it is sendAreaSummary, the router will both summarize and propagate Inter-Area LSAs." DEFVAL { sendAreaSummary } ::= { ospfv3AreaEntry 8 } ospfv3AreaRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfv3AreaEntry 9 } ospfv3AreaStubMetric OBJECT-TYPE SYNTAX BigMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric value advertised for the default route into stub and NSSA areas. By default, this equals the least metric among the interfaces to other areas." ::= { ospfv3AreaEntry 10 } ospfv3AreaNssaTranslatorRole OBJECT-TYPE SYNTAX INTEGER { always(1), candidate(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates an NSSA border router's policy to perform NSSA translation of NSSA-LSAs into AS-External-LSAs." DEFVAL { candidate } ::= { ospfv3AreaEntry 11 } ospfv3AreaNssaTranslatorState OBJECT-TYPE SYNTAX INTEGER { enabled(1), Joyal & Manral Standards Track [Page 25] RFC 5643 OSPFv3 MIB August 2009 elected(2), disabled(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates if and how an NSSA border router is performing NSSA translation of NSSA-LSAs into AS-External-LSAs. When this object is set to 'enabled', the NSSA border router's ospfv3AreaNssaTranslatorRole has been set to 'always'. When this object is set to 'elected', a candidate NSSA border router is translating NSSA-LSAs into AS-External-LSAs. When this object is set to 'disabled', a candidate NSSA Border router is NOT translating NSSA-LSAs into AS-External-LSAs." ::= { ospfv3AreaEntry 12 } ospfv3AreaNssaTranslatorStabInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The stability interval defined as the number of seconds after an elected translator determines its services are no longer required that it should continue to perform its translation duties." DEFVAL { 40 } ::= { ospfv3AreaEntry 13 } ospfv3AreaNssaTranslatorEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of Translator state changes that have occurred since the last start-up of the OSPFv3 routing process. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3AreaEntry 14 } Joyal & Manral Standards Track [Page 26] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaStubMetricType OBJECT-TYPE SYNTAX INTEGER { ospfv3Metric(1), -- OSPF Metric comparableCost(2), -- external type 1 nonComparable(3) -- external type 2 } MAX-ACCESS read-create STATUS current DESCRIPTION "This variable assigns the type of metric advertised as a default route." DEFVAL { ospfv3Metric } ::= { ospfv3AreaEntry 15 } ospfv3AreaTEEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether or not traffic engineering is enabled in the area. The object is set to the value true (1) to enable traffic engineering. Traffic engineering is disabled by default." DEFVAL { false } ::= { ospfv3AreaEntry 16 } -- OSPFv3 AS-Scope Link State Database ospfv3AsLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3AsLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPFv3 Process's AS-scope link state database (LSDB). The LSDB contains the AS-scope link state advertisements from throughout the areas that the device is attached to." ::= { ospfv3Objects 3 } ospfv3AsLsdbEntry OBJECT-TYPE SYNTAX Ospfv3AsLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single AS-scope link state advertisement." INDEX { ospfv3AsLsdbType, ospfv3AsLsdbRouterId, ospfv3AsLsdbLsid } Joyal & Manral Standards Track [Page 27] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3AsLsdbTable 1 } Ospfv3AsLsdbEntry ::= SEQUENCE { ospfv3AsLsdbType Unsigned32, ospfv3AsLsdbRouterId Ospfv3RouterIdTC, ospfv3AsLsdbLsid Ospfv3LsIdTC, ospfv3AsLsdbSequence Ospfv3LsaSequenceTC, ospfv3AsLsdbAge Ospfv3LsaAgeTC, ospfv3AsLsdbChecksum Integer32, ospfv3AsLsdbAdvertisement OCTET STRING, ospfv3AsLsdbTypeKnown TruthValue } ospfv3AsLsdbType OBJECT-TYPE SYNTAX Unsigned32(0..'FFFFFFFF'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format. AS-scope LSAs not recognized by the router may be stored in the database." ::= { ospfv3AsLsdbEntry 1 } ospfv3AsLsdbRouterId OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1, Global parameters" ::= { ospfv3AsLsdbEntry 2 } ospfv3AsLsdbLsid OBJECT-TYPE SYNTAX Ospfv3LsIdTC MAX-ACCESS not-accessible STATUS current Joyal & Manral Standards Track [Page 28] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "The Link State ID is an LS type-specific field containing a unique identifier; it identifies the piece of the routing domain that is being described by the advertisement. In contrast to OSPFv2, the LSID has no addressing semantics." ::= { ospfv3AsLsdbEntry 3 } -- Note that the OSPF sequence number is a 32-bit signed -- integer. It starts with the value '80000001'h -- or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. -- Thus, a typical sequence number will be very negative. ospfv3AsLsdbSequence OBJECT-TYPE SYNTAX Ospfv3LsaSequenceTC MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6, LS sequence number" ::= { ospfv3AsLsdbEntry 4 } ospfv3AsLsdbAge OBJECT-TYPE SYNTAX Ospfv3LsaAgeTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the age of the link state advertisement in seconds. The high-order bit of the LS age field is considered the DoNotAge bit for support of on-demand circuits." REFERENCE "OSPF Version 2, Section 12.1.1, LS age; Extending OSPF to Support Demand Circuits, Section 2.2, The LS age field." ::= { ospfv3AsLsdbEntry 5 } Joyal & Manral Standards Track [Page 29] RFC 5643 OSPFv3 MIB August 2009 ospfv3AsLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7, LS checksum" ::= { ospfv3AsLsdbEntry 6 } ospfv3AsLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header." ::= { ospfv3AsLsdbEntry 7 } ospfv3AsLsdbTypeKnown OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value true (1) indicates that the LSA type is recognized by this router." ::= { ospfv3AsLsdbEntry 8 } -- OSPFv3 Area-Scope Link State Database ospfv3AreaLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3AreaLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPFv3 Process's Area-scope LSDB. The LSDB contains the Area-scope link state advertisements from throughout the area that the device is attached to." ::= { ospfv3Objects 4 } Joyal & Manral Standards Track [Page 30] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaLsdbEntry OBJECT-TYPE SYNTAX Ospfv3AreaLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single Area-scope link state advertisement." INDEX { ospfv3AreaLsdbAreaId, ospfv3AreaLsdbType, ospfv3AreaLsdbRouterId, ospfv3AreaLsdbLsid } ::= { ospfv3AreaLsdbTable 1 } Ospfv3AreaLsdbEntry ::= SEQUENCE { ospfv3AreaLsdbAreaId Ospfv3AreaIdTC, ospfv3AreaLsdbType Unsigned32, ospfv3AreaLsdbRouterId Ospfv3RouterIdTC, ospfv3AreaLsdbLsid Ospfv3LsIdTC, ospfv3AreaLsdbSequence Ospfv3LsaSequenceTC, ospfv3AreaLsdbAge Ospfv3LsaAgeTC, ospfv3AreaLsdbChecksum Integer32, ospfv3AreaLsdbAdvertisement OCTET STRING, ospfv3AreaLsdbTypeKnown TruthValue } ospfv3AreaLsdbAreaId OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit identifier of the Area from which the LSA was received." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" ::= { ospfv3AreaLsdbEntry 1 } ospfv3AreaLsdbType OBJECT-TYPE SYNTAX Unsigned32(0..'FFFFFFFF'h) MAX-ACCESS not-accessible STATUS current Joyal & Manral Standards Track [Page 31] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format. Area-scope LSAs unrecognized by the router are also stored in this database." ::= { ospfv3AreaLsdbEntry 2 } ospfv3AreaLsdbRouterId OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1, Global parameters" ::= { ospfv3AreaLsdbEntry 3 } ospfv3AreaLsdbLsid OBJECT-TYPE SYNTAX Ospfv3LsIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Link State ID is an LS type-specific field containing a unique identifier; it identifies the piece of the routing domain that is being described by the advertisement. In contrast to OSPFv2, the LSID has no addressing semantics." ::= { ospfv3AreaLsdbEntry 4 } -- Note that the OSPF sequence number is a 32-bit signed -- integer. It starts with the value '80000001'h -- or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. -- Thus, a typical sequence number will be very negative. ospfv3AreaLsdbSequence OBJECT-TYPE SYNTAX Ospfv3LsaSequenceTC MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." Joyal & Manral Standards Track [Page 32] RFC 5643 OSPFv3 MIB August 2009 REFERENCE "OSPF Version 2, Section 12.1.6, LS sequence number" ::= { ospfv3AreaLsdbEntry 5 } ospfv3AreaLsdbAge OBJECT-TYPE SYNTAX Ospfv3LsaAgeTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the age of the link state advertisement in seconds. The high-order bit of the LS age field is considered the DoNotAge bit for support of on-demand circuits." REFERENCE "OSPF Version 2, Section 12.1.1, LS age; Extending OSPF to Support Demand Circuits, Section 2.2, The LS age field." ::= { ospfv3AreaLsdbEntry 6 } ospfv3AreaLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7, LS checksum" ::= { ospfv3AreaLsdbEntry 7 } ospfv3AreaLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header." ::= { ospfv3AreaLsdbEntry 8 } Joyal & Manral Standards Track [Page 33] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaLsdbTypeKnown OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value true (1) indicates that the LSA type is recognized by this router." ::= { ospfv3AreaLsdbEntry 9 } -- OSPFv3 Link-Scope Link State Database, for non-virtual interfaces ospfv3LinkLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3LinkLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPFv3 Process's Link-scope LSDB for non-virtual interfaces. The LSDB contains the Link-scope link state advertisements from the interfaces that the device is attached to." ::= { ospfv3Objects 5 } ospfv3LinkLsdbEntry OBJECT-TYPE SYNTAX Ospfv3LinkLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single Link-scope link state advertisement." INDEX { ospfv3LinkLsdbIfIndex, ospfv3LinkLsdbIfInstId, ospfv3LinkLsdbType, ospfv3LinkLsdbRouterId, ospfv3LinkLsdbLsid } ::= { ospfv3LinkLsdbTable 1 } Ospfv3LinkLsdbEntry ::= SEQUENCE { ospfv3LinkLsdbIfIndex InterfaceIndex, ospfv3LinkLsdbIfInstId Ospfv3IfInstIdTC, ospfv3LinkLsdbType Unsigned32, ospfv3LinkLsdbRouterId Ospfv3RouterIdTC, ospfv3LinkLsdbLsid Ospfv3LsIdTC, ospfv3LinkLsdbSequence Ospfv3LsaSequenceTC, Joyal & Manral Standards Track [Page 34] RFC 5643 OSPFv3 MIB August 2009 ospfv3LinkLsdbAge Ospfv3LsaAgeTC, ospfv3LinkLsdbChecksum Integer32, ospfv3LinkLsdbAdvertisement OCTET STRING, ospfv3LinkLsdbTypeKnown TruthValue } ospfv3LinkLsdbIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the link from which the LSA was received." ::= { ospfv3LinkLsdbEntry 1 } ospfv3LinkLsdbIfInstId OBJECT-TYPE SYNTAX Ospfv3IfInstIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the interface instance from which the LSA was received." ::= { ospfv3LinkLsdbEntry 2 } ospfv3LinkLsdbType OBJECT-TYPE SYNTAX Unsigned32(0..'FFFFFFFF'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format. Link-scope LSAs unrecognized by the router are also stored in this database." ::= { ospfv3LinkLsdbEntry 3 } ospfv3LinkLsdbRouterId OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1, Global parameters" Joyal & Manral Standards Track [Page 35] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3LinkLsdbEntry 4 } ospfv3LinkLsdbLsid OBJECT-TYPE SYNTAX Ospfv3LsIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Link State ID is an LS type-specific field containing a unique identifier; it identifies the piece of the routing domain that is being described by the advertisement. In contrast to OSPFv2, the LSID has no addressing semantics. However, in OSPFv3 the Link State ID always contains the flooding scope of the LSA." ::= { ospfv3LinkLsdbEntry 5 } -- Note that the OSPF sequence number is a 32-bit signed -- integer. It starts with the value '80000001'h -- or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. -- Thus, a typical sequence number will be very negative. ospfv3LinkLsdbSequence OBJECT-TYPE SYNTAX Ospfv3LsaSequenceTC MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6, LS sequence number" ::= { ospfv3LinkLsdbEntry 6 } ospfv3LinkLsdbAge OBJECT-TYPE SYNTAX Ospfv3LsaAgeTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the age of the link state advertisement in seconds. The high-order bit of the LS age field is considered the DoNotAge bit for support of on-demand circuits." Joyal & Manral Standards Track [Page 36] RFC 5643 OSPFv3 MIB August 2009 REFERENCE "OSPF Version 2, Section 12.1.1, LS age; Extending OSPF to Support Demand Circuits, Section 2.2, The LS age field." ::= { ospfv3LinkLsdbEntry 7 } ospfv3LinkLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7, LS checksum" ::= { ospfv3LinkLsdbEntry 8 } ospfv3LinkLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header." ::= { ospfv3LinkLsdbEntry 9 } ospfv3LinkLsdbTypeKnown OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value true (1) indicates that the LSA type is recognized by this router." ::= { ospfv3LinkLsdbEntry 10 } -- OSPF Host Table ospfv3HostTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3HostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Joyal & Manral Standards Track [Page 37] RFC 5643 OSPFv3 MIB August 2009 "The Host/Metric Table indicates what hosts are directly attached to the router and their corresponding metrics." REFERENCE "OSPF Version 2, Appendix C.7, Host route parameters" ::= { ospfv3Objects 6 } ospfv3HostEntry OBJECT-TYPE SYNTAX Ospfv3HostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A metric to be advertised when a given host is reachable. The information in this table is persistent, and when written, the entity SHOULD save the change to non-volatile storage." INDEX { ospfv3HostAddressType, ospfv3HostAddress } ::= { ospfv3HostTable 1 } Ospfv3HostEntry ::= SEQUENCE { ospfv3HostAddressType InetAddressType, ospfv3HostAddress InetAddress, ospfv3HostMetric Metric, ospfv3HostRowStatus RowStatus, ospfv3HostAreaID Ospfv3AreaIdTC } ospfv3HostAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address type of ospfv3HostAddress. Only IPv6 global address type is expected." REFERENCE "OSPF Version 2, Appendix C.7, Host route parameters" ::= { ospfv3HostEntry 1 } Joyal & Manral Standards Track [Page 38] RFC 5643 OSPFv3 MIB August 2009 ospfv3HostAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 address of the host. Must be an IPv6 global address." REFERENCE "OSPF Version 2, Appendix C.7, Host route parameters" ::= { ospfv3HostEntry 2 } ospfv3HostMetric OBJECT-TYPE SYNTAX Metric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric to be advertised." REFERENCE "OSPF Version 2, Appendix C.7, Host route parameters" ::= { ospfv3HostEntry 3 } ospfv3HostRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfv3HostEntry 4 } ospfv3HostAreaID OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS read-create STATUS current DESCRIPTION "The Area the host entry is to be found within. By default, the area for the subsuming OSPFv3 interface, or Area 0 if there is no subsuming interface." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" Joyal & Manral Standards Track [Page 39] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3HostEntry 5 } -- OSPFv3 Interface Table ospfv3IfTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPFv3 Interface Table describes the interfaces from the viewpoint of OSPFv3." REFERENCE "OSPF for IPv6, Appendix C.3, Router Interface Parameters" ::= { ospfv3Objects 7 } ospfv3IfEntry OBJECT-TYPE SYNTAX Ospfv3IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPFv3 Interface Entry describes one interface from the viewpoint of OSPFv3. The information in this table is persistent, and when written, the entity SHOULD save the change to non-volatile storage." INDEX { ospfv3IfIndex, ospfv3IfInstId } ::= { ospfv3IfTable 1 } Ospfv3IfEntry ::= SEQUENCE { ospfv3IfIndex InterfaceIndex, ospfv3IfInstId Ospfv3IfInstIdTC, ospfv3IfAreaId Ospfv3AreaIdTC, ospfv3IfType INTEGER, ospfv3IfAdminStatus Status, ospfv3IfRtrPriority DesignatedRouterPriority, ospfv3IfTransitDelay Ospfv3UpToRefreshIntervalTC, ospfv3IfRetransInterval Ospfv3UpToRefreshIntervalTC, Joyal & Manral Standards Track [Page 40] RFC 5643 OSPFv3 MIB August 2009 ospfv3IfHelloInterval HelloRange, ospfv3IfRtrDeadInterval Ospfv3DeadIntervalRangeTC, ospfv3IfPollInterval Unsigned32, ospfv3IfState INTEGER, ospfv3IfDesignatedRouter Ospfv3RouterIdTC, ospfv3IfBackupDesignatedRouter Ospfv3RouterIdTC, ospfv3IfEvents Counter32, ospfv3IfRowStatus RowStatus, ospfv3IfDemand TruthValue, ospfv3IfMetricValue Metric, ospfv3IfLinkScopeLsaCount Gauge32, ospfv3IfLinkLsaCksumSum Unsigned32, ospfv3IfDemandNbrProbe TruthValue, ospfv3IfDemandNbrProbeRetransLimit Unsigned32, ospfv3IfDemandNbrProbeInterval Unsigned32, ospfv3IfTEDisabled TruthValue, ospfv3IfLinkLSASuppression TruthValue } ospfv3IfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index of this OSPFv3 interface. It corresponds to the interface index of the IPv6 interface on which OSPFv3 is configured." ::= { ospfv3IfEntry 1 } Joyal & Manral Standards Track [Page 41] RFC 5643 OSPFv3 MIB August 2009 ospfv3IfInstId OBJECT-TYPE SYNTAX Ospfv3IfInstIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Enables multiple interface instances of OSPFv3 to be run over a single link. Each interface instance would be assigned a separate ID. This ID has local link significance only." ::= { ospfv3IfEntry 2 } ospfv3IfAreaId OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS read-create STATUS current DESCRIPTION "A 32-bit integer uniquely identifying the area to which the interface connects. Area ID 0 is used for the OSPFv3 backbone." DEFVAL { 0 } ::= { ospfv3IfEntry 3 } ospfv3IfType OBJECT-TYPE SYNTAX INTEGER { broadcast(1), nbma(2), pointToPoint(3), pointToMultipoint(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The OSPFv3 interface type." ::= { ospfv3IfEntry 4 } ospfv3IfAdminStatus OBJECT-TYPE SYNTAX Status MAX-ACCESS read-create STATUS current DESCRIPTION "The OSPFv3 interface's administrative status. The value formed on the interface; the interface will be advertised as an internal route to some area. The value 'disabled' denotes that the interface is external to OSPFv3. Joyal & Manral Standards Track [Page 42] RFC 5643 OSPFv3 MIB August 2009 Note that a value of 'disabled' for the object ospfv3AdminStatus will override a value of 'enabled' for the interface." DEFVAL { enabled } ::= { ospfv3IfEntry 5 } ospfv3IfRtrPriority OBJECT-TYPE SYNTAX DesignatedRouterPriority MAX-ACCESS read-create STATUS current DESCRIPTION "The priority of this interface. Used in multi-access networks, this field is used in the designated-router election algorithm. The value 0 signifies that the router is not eligible to become the Designated Router on this particular network. In the event of a tie in this value, routers will use their Router ID as a tie breaker." DEFVAL { 1 } ::= { ospfv3IfEntry 6 } ospfv3IfTransitDelay OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The estimated number of seconds it takes to transmit a Link State Update packet over this interface. LSAs contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface." REFERENCE "OSPF for IPv6, Appendix C.3, Router Interface Parameters." DEFVAL { 1 } ::= { ospfv3IfEntry 7 } ospfv3IfRetransInterval OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between link state advertisement retransmissions for adjacencies Joyal & Manral Standards Track [Page 43] RFC 5643 OSPFv3 MIB August 2009 belonging to this interface. This value is also used when retransmitting database description and Link State Request packets." DEFVAL { 5 } ::= { ospfv3IfEntry 8 } ospfv3IfHelloInterval OBJECT-TYPE SYNTAX HelloRange UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The length of time, in seconds, between the Hello packets that the router sends on the interface. This value must be the same for all routers attached to a common network." DEFVAL { 10 } ::= { ospfv3IfEntry 9 } ospfv3IfRtrDeadInterval OBJECT-TYPE SYNTAX Ospfv3DeadIntervalRangeTC UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that a router's Hello packets have not been seen before its neighbors declare the router down on the interface. This should be some multiple of the Hello interval. This value must be the same for all routers attached to a common network." DEFVAL { 40 } ::= { ospfv3IfEntry 10 } ospfv3IfPollInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The larger time interval, in seconds, between the Hello packets sent to an inactive, non-broadcast multi-access neighbor." DEFVAL { 120 } ::= { ospfv3IfEntry 11 } Joyal & Manral Standards Track [Page 44] RFC 5643 OSPFv3 MIB August 2009 ospfv3IfState OBJECT-TYPE SYNTAX INTEGER { down(1), loopback(2), waiting(3), pointToPoint(4), designatedRouter(5), backupDesignatedRouter(6), otherDesignatedRouter(7), standby(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The OSPFv3 interface state. An interface may be in standby state if there are multiple interfaces on the link and another interface is active. The interface may be in Down state if the underlying IPv6 interface is down or if the admin status is 'disabled' either globally or for the interface." ::= { ospfv3IfEntry 12 } ospfv3IfDesignatedRouter OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID of the Designated Router." ::= { ospfv3IfEntry 13 } ospfv3IfBackupDesignatedRouter OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID of the Backup Designated Router." ::= { ospfv3IfEntry 14 } ospfv3IfEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this OSPFv3 interface has changed its state or an error has occurred. Joyal & Manral Standards Track [Page 45] RFC 5643 OSPFv3 MIB August 2009 Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3IfEntry 15 } ospfv3IfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfv3IfEntry 16 } ospfv3IfDemand OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether Demand OSPFv3 procedures (Hello suppression to FULL neighbors and setting the DoNotAge flag on propagated LSAs) should be performed on this interface." DEFVAL { false } ::= { ospfv3IfEntry 17 } ospfv3IfMetricValue OBJECT-TYPE SYNTAX Metric MAX-ACCESS read-create STATUS current DESCRIPTION "The metric assigned to this interface. The default value of the metric is 'Reference Bandwidth / ifSpeed'. The value of the reference bandwidth can be set in the ospfv3ReferenceBandwidth object." ::= { ospfv3IfEntry 18 } ospfv3IfLinkScopeLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Joyal & Manral Standards Track [Page 46] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "The total number of Link-scope link state advertisements in this link's link state database." ::= { ospfv3IfEntry 19 } ospfv3IfLinkLsaCksumSum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit unsigned sum of the Link-scope link state advertisements' LS checksums contained in this link's link state database. The sum can be used to determine if there has been a change in a router's link state database or to compare the link state database of two routers." ::= { ospfv3IfEntry 20 } ospfv3IfDemandNbrProbe OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether or not neighbor probing is enabled to determine whether or not the neighbor is inactive. Neighbor probing is disabled by default." DEFVAL { false } ::= { ospfv3IfEntry 21 } ospfv3IfDemandNbrProbeRetransLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of consecutive LSA retransmissions before the neighbor is deemed inactive and the neighbor adjacency is brought down." DEFVAL { 10 } ::= { ospfv3IfEntry 22} ospfv3IfDemandNbrProbeInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current Joyal & Manral Standards Track [Page 47] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "Defines how often the neighbor will be probed." DEFVAL { 120 } ::= { ospfv3IfEntry 23 } ospfv3IfTEDisabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether or not traffic engineering is disabled on the interface when traffic engineering is enabled in the area where the interface is attached. The object is set to the value true (1) to disable traffic engineering on the interface. Traffic engineering is enabled by default on the interface when traffic engineering is enabled in the area where the interface is attached." DEFVAL { false } ::= { ospfv3IfEntry 24 } ospfv3IfLinkLSASuppression OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies whether or not link LSA origination is suppressed for broadcast or NBMA interface types. The object is set to value true (1) to suppress the origination." REFERENCE "OSPF for IPv6, Appendix C.3, Router Interface Parameters" DEFVAL { false } ::= { ospfv3IfEntry 25 } -- OSPFv3 Virtual Interface Table ospfv3VirtIfTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3VirtIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about this router's virtual interfaces that the OSPFv3 Process is configured to carry on." Joyal & Manral Standards Track [Page 48] RFC 5643 OSPFv3 MIB August 2009 REFERENCE "OSPF for IPv6, Appendix C.4, Virtual Link Parameters" ::= { ospfv3Objects 8 } ospfv3VirtIfEntry OBJECT-TYPE SYNTAX Ospfv3VirtIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single virtual interface. The information in this table is persistent, and when written, the entity SHOULD save the change to non-volatile storage." INDEX { ospfv3VirtIfAreaId, ospfv3VirtIfNeighbor } ::= { ospfv3VirtIfTable 1 } Ospfv3VirtIfEntry ::= SEQUENCE { ospfv3VirtIfAreaId Ospfv3AreaIdTC, ospfv3VirtIfNeighbor Ospfv3RouterIdTC, ospfv3VirtIfIndex InterfaceIndex, ospfv3VirtIfInstId Ospfv3IfInstIdTC, ospfv3VirtIfTransitDelay Ospfv3UpToRefreshIntervalTC, ospfv3VirtIfRetransInterval Ospfv3UpToRefreshIntervalTC, ospfv3VirtIfHelloInterval HelloRange, ospfv3VirtIfRtrDeadInterval Ospfv3DeadIntervalRangeTC, ospfv3VirtIfState INTEGER, ospfv3VirtIfEvents Counter32, ospfv3VirtIfRowStatus RowStatus, ospfv3VirtIfLinkScopeLsaCount Gauge32, ospfv3VirtIfLinkLsaCksumSum Unsigned32 } Joyal & Manral Standards Track [Page 49] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtIfAreaId OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The transit area that the virtual link traverses. By definition, this is not Area 0." ::= { ospfv3VirtIfEntry 1 } ospfv3VirtIfNeighbor OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Router ID of the virtual neighbor." ::= { ospfv3VirtIfEntry 2 } ospfv3VirtIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The local interface index assigned by the OSPFv3 Process to this OSPFv3 virtual interface. It is advertised in Hellos sent over the virtual link and in the router's router-LSAs." ::= { ospfv3VirtIfEntry 3 } ospfv3VirtIfInstId OBJECT-TYPE SYNTAX Ospfv3IfInstIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "The local Interface Instance ID assigned by the OSPFv3 Process to this OSPFv3 virtual interface." ::= { ospfv3VirtIfEntry 4 } ospfv3VirtIfTransitDelay OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The estimated number of seconds it takes to transmit a Link State Update packet over this interface." DEFVAL { 1 } Joyal & Manral Standards Track [Page 50] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3VirtIfEntry 5 } ospfv3VirtIfRetransInterval OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds between link state advertisement retransmissions for adjacencies belonging to this interface. This value is also used when retransmitting database description and Link State Request packets. This value should be well over the expected round-trip time." DEFVAL { 5 } ::= { ospfv3VirtIfEntry 6 } ospfv3VirtIfHelloInterval OBJECT-TYPE SYNTAX HelloRange UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The length of time, in seconds, between the Hello packets that the router sends on the interface. This value must be the same for the virtual neighbor." DEFVAL { 10 } ::= { ospfv3VirtIfEntry 7 } ospfv3VirtIfRtrDeadInterval OBJECT-TYPE SYNTAX Ospfv3DeadIntervalRangeTC UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that a router's Hello packets have not been seen before its neighbors declare the router down. This should be some multiple of the Hello interval. This value must be the same for the virtual neighbor." DEFVAL { 60 } ::= { ospfv3VirtIfEntry 8 } Joyal & Manral Standards Track [Page 51] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtIfState OBJECT-TYPE SYNTAX INTEGER { down(1), pointToPoint(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "OSPF virtual interface states. The same encoding as the ospfV3IfTable is used." ::= { ospfv3VirtIfEntry 9 } ospfv3VirtIfEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of state changes or error events on this virtual link. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3VirtIfEntry 10 } ospfv3VirtIfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfv3VirtIfEntry 11 } ospfv3VirtIfLinkScopeLsaCount OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Link-scope link state advertisements in this virtual link's link state database." Joyal & Manral Standards Track [Page 52] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3VirtIfEntry 12 } ospfv3VirtIfLinkLsaCksumSum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The 32-bit unsigned sum of the Link-scope link state advertisements' LS checksums contained in this virtual link's link state database. The sum can be used to determine if there has been a change in a router's link state database or to compare the link state database of two routers." ::= { ospfv3VirtIfEntry 13 } -- OSPFv3 Neighbor Table ospfv3NbrTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3NbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table describing all neighbors in the locality of the OSPFv3 router." REFERENCE "OSPF Version 2, Section 10, The Neighbor Data Structure" ::= { ospfv3Objects 9 } ospfv3NbrEntry OBJECT-TYPE SYNTAX Ospfv3NbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The information regarding a single neighbor." REFERENCE "OSPF Version 2, Section 10, The Neighbor Data Structure" INDEX { ospfv3NbrIfIndex, ospfv3NbrIfInstId, ospfv3NbrRtrId } ::= { ospfv3NbrTable 1 } Ospfv3NbrEntry ::= SEQUENCE { ospfv3NbrIfIndex InterfaceIndex, ospfv3NbrIfInstId Ospfv3IfInstIdTC, Joyal & Manral Standards Track [Page 53] RFC 5643 OSPFv3 MIB August 2009 ospfv3NbrRtrId Ospfv3RouterIdTC, ospfv3NbrAddressType InetAddressType, ospfv3NbrAddress InetAddress, ospfv3NbrOptions Integer32, ospfv3NbrPriority DesignatedRouterPriority, ospfv3NbrState INTEGER, ospfv3NbrEvents Counter32, ospfv3NbrLsRetransQLen Gauge32, ospfv3NbrHelloSuppressed TruthValue, ospfv3NbrIfId InterfaceIndex, ospfv3NbrRestartHelperStatus INTEGER, ospfv3NbrRestartHelperAge Ospfv3UpToRefreshIntervalTC, ospfv3NbrRestartHelperExitReason INTEGER } ospfv3NbrIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Local Link ID of the link over which the neighbor can be reached." ::= { ospfv3NbrEntry 1 } ospfv3NbrIfInstId OBJECT-TYPE SYNTAX Ospfv3IfInstIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Interface instance over which the neighbor can be reached. This ID has local link significance only." ::= { ospfv3NbrEntry 2 } Joyal & Manral Standards Track [Page 54] RFC 5643 OSPFv3 MIB August 2009 ospfv3NbrRtrId OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "A 32-bit unsigned integer uniquely identifying the neighboring router in the Autonomous System." ::= { ospfv3NbrEntry 3 } ospfv3NbrAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of ospfv3NbrAddress. Only IPv6 addresses without zone index are expected." ::= { ospfv3NbrEntry 4 } ospfv3NbrAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 address of the neighbor associated with the local link." ::= { ospfv3NbrEntry 5 } ospfv3NbrOptions OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A bit mask corresponding to the neighbor's options field." REFERENCE "OSPF for IPv6, Appendix A.2, The Options Field" ::= { ospfv3NbrEntry 6 } ospfv3NbrPriority OBJECT-TYPE SYNTAX DesignatedRouterPriority MAX-ACCESS read-only STATUS current DESCRIPTION "The priority of this neighbor in the designated- router election algorithm. The value 0 signifies that the neighbor is not eligible to become the Designated Router on this particular network." ::= { ospfv3NbrEntry 7 } Joyal & Manral Standards Track [Page 55] RFC 5643 OSPFv3 MIB August 2009 ospfv3NbrState OBJECT-TYPE SYNTAX INTEGER { down(1), attempt(2), init(3), twoWay(4), exchangeStart(5), exchange(6), loading(7), full(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the relationship with this neighbor." REFERENCE "OSPF Version 2, Section 10.1, Neighbor states" ::= { ospfv3NbrEntry 8 } ospfv3NbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this neighbor relationship has changed state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3NbrEntry 9 } ospfv3NbrLsRetransQLen OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current length of the retransmission queue." ::= { ospfv3NbrEntry 10 } ospfv3NbrHelloSuppressed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current Joyal & Manral Standards Track [Page 56] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "Indicates whether Hellos are being suppressed to the neighbor." ::= { ospfv3NbrEntry 11 } ospfv3NbrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The Interface ID that the neighbor advertises in its Hello packets on this link, that is, the neighbor's local interface index." ::= { ospfv3NbrEntry 12 } ospfv3NbrRestartHelperStatus OBJECT-TYPE SYNTAX INTEGER { notHelping(1), helping(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the router is acting as a graceful restart helper for the neighbor." ::= { ospfv3NbrEntry 13 } ospfv3NbrRestartHelperAge OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in current OSPF graceful restart interval, if the router is acting as a restart helper for the neighbor." ::= { ospfv3NbrEntry 14 } ospfv3NbrRestartHelperExitReason OBJECT-TYPE SYNTAX INTEGER { none(1), inProgress(2), completed(3), timedOut(4), topologyChanged(5) } MAX-ACCESS read-only STATUS current Joyal & Manral Standards Track [Page 57] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "Describes the outcome of the last attempt at acting as a graceful restart helper for the neighbor. none: no restart has yet been attempted. inProgress: a restart attempt is currently underway. completed: the last restart completed successfully. timedOut: the last restart timed out. topologyChanged: the last restart was aborted due to a topology change." ::= { ospfv3NbrEntry 15 } -- OSPFv3 Configured Neighbor Table ospfv3CfgNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3CfgNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table describing all configured neighbors. The Configured Neighbors table just gives OSPFv3 information for sending OSPFv3 packets to potential neighbors and is typically used on NBMA and Point-to-Multipoint networks. Once a Hello is received from a neighbor in the Configured Neighbor table, an entry for that neighbor is created in the Neighbor table and adjacency state is maintained there. Neighbors on multi-access or Point-to-Point networks can use multicast addressing, so only Neighbor table entries are created for them." REFERENCE "OSPF Version 2, Section 10, The Neighbor Data Structure" ::= { ospfv3Objects 10 } ospfv3CfgNbrEntry OBJECT-TYPE SYNTAX Ospfv3CfgNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The information regarding a single configured neighbor. The information in this table is persistent, and when written, the entity SHOULD save the change to non-volatile storage." Joyal & Manral Standards Track [Page 58] RFC 5643 OSPFv3 MIB August 2009 REFERENCE "OSPF Version 2, Section 10, The Neighbor Data Structure" INDEX { ospfv3CfgNbrIfIndex, ospfv3CfgNbrIfInstId, ospfv3CfgNbrAddressType, ospfv3CfgNbrAddress } ::= { ospfv3CfgNbrTable 1 } Ospfv3CfgNbrEntry ::= SEQUENCE { ospfv3CfgNbrIfIndex InterfaceIndex, ospfv3CfgNbrIfInstId Ospfv3IfInstIdTC, ospfv3CfgNbrAddressType InetAddressType, ospfv3CfgNbrAddress InetAddress, ospfv3CfgNbrPriority DesignatedRouterPriority, ospfv3CfgNbrRowStatus RowStatus } ospfv3CfgNbrIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Local Link ID of the link over which the neighbor can be reached." ::= { ospfv3CfgNbrEntry 1 } ospfv3CfgNbrIfInstId OBJECT-TYPE SYNTAX Ospfv3IfInstIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Interface instance over which the neighbor can be reached. This ID has local link significance only." ::= { ospfv3CfgNbrEntry 2 } ospfv3CfgNbrAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current Joyal & Manral Standards Track [Page 59] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "The address type of ospfv3NbrAddress. Only IPv6 addresses without zone index are expected." ::= { ospfv3CfgNbrEntry 3 } ospfv3CfgNbrAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 address of the neighbor associated with the local link." ::= { ospfv3CfgNbrEntry 4 } ospfv3CfgNbrPriority OBJECT-TYPE SYNTAX DesignatedRouterPriority MAX-ACCESS read-create STATUS current DESCRIPTION "The priority of this neighbor in the designated- router election algorithm. The value 0 signifies that the neighbor is not eligible to become the Designated Router on this particular network." DEFVAL { 1 } ::= { ospfv3CfgNbrEntry 5 } ospfv3CfgNbrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfv3CfgNbrEntry 6 } -- OSPFv3 Virtual Neighbor Table ospfv3VirtNbrTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3VirtNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table describing all virtual neighbors." Joyal & Manral Standards Track [Page 60] RFC 5643 OSPFv3 MIB August 2009 REFERENCE "OSPF Version 2, Section 15, Virtual Links" ::= { ospfv3Objects 11 } ospfv3VirtNbrEntry OBJECT-TYPE SYNTAX Ospfv3VirtNbrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Virtual neighbor information." INDEX { ospfv3VirtNbrArea, ospfv3VirtNbrRtrId } ::= { ospfv3VirtNbrTable 1 } Ospfv3VirtNbrEntry ::= SEQUENCE { ospfv3VirtNbrArea Ospfv3AreaIdTC, ospfv3VirtNbrRtrId Ospfv3RouterIdTC, ospfv3VirtNbrIfIndex InterfaceIndex, ospfv3VirtNbrIfInstId Ospfv3IfInstIdTC, ospfv3VirtNbrAddressType InetAddressType, ospfv3VirtNbrAddress InetAddress, ospfv3VirtNbrOptions Integer32, ospfv3VirtNbrState INTEGER, ospfv3VirtNbrEvents Counter32, ospfv3VirtNbrLsRetransQLen Gauge32, ospfv3VirtNbrHelloSuppressed TruthValue, ospfv3VirtNbrIfId InterfaceIndex, ospfv3VirtNbrRestartHelperStatus INTEGER, ospfv3VirtNbrRestartHelperAge Ospfv3UpToRefreshIntervalTC, ospfv3VirtNbrRestartHelperExitReason INTEGER } Joyal & Manral Standards Track [Page 61] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtNbrArea OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The transit area Identifier." ::= { ospfv3VirtNbrEntry 1 } ospfv3VirtNbrRtrId OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "A 32-bit integer uniquely identifying the neighboring router in the Autonomous System." ::= { ospfv3VirtNbrEntry 2 } ospfv3VirtNbrIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The local Interface ID for the virtual link over which the neighbor can be reached." ::= { ospfv3VirtNbrEntry 3 } ospfv3VirtNbrIfInstId OBJECT-TYPE SYNTAX Ospfv3IfInstIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "The interface instance for the virtual link over which the neighbor can be reached." ::= { ospfv3VirtNbrEntry 4 } ospfv3VirtNbrAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The address type of ospfv3VirtNbrAddress. Only IPv6 addresses without zone index are expected." ::= { ospfv3VirtNbrEntry 5 } ospfv3VirtNbrAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current Joyal & Manral Standards Track [Page 62] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "The IPv6 address advertised by this virtual neighbor. It must be a global scope address." ::= { ospfv3VirtNbrEntry 6 } ospfv3VirtNbrOptions OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A bit mask corresponding to the neighbor's options field." REFERENCE "OSPF for IPv6, Appendix A.2, The Options Field" ::= { ospfv3VirtNbrEntry 7 } ospfv3VirtNbrState OBJECT-TYPE SYNTAX INTEGER { down(1), attempt(2), init(3), twoWay(4), exchangeStart(5), exchange(6), loading(7), full(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the virtual neighbor relationship." ::= { ospfv3VirtNbrEntry 8 } ospfv3VirtNbrEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this virtual link has changed its state or an error has occurred. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ospfv3DiscontinuityTime." ::= { ospfv3VirtNbrEntry 9 } Joyal & Manral Standards Track [Page 63] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtNbrLsRetransQLen OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current length of the retransmission queue." ::= { ospfv3VirtNbrEntry 10 } ospfv3VirtNbrHelloSuppressed OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether Hellos are being suppressed to the neighbor." ::= { ospfv3VirtNbrEntry 11 } ospfv3VirtNbrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The Interface ID that the neighbor advertises in its Hello packets on this virtual link, that is, the neighbor's local Interface ID." ::= { ospfv3VirtNbrEntry 12 } ospfv3VirtNbrRestartHelperStatus OBJECT-TYPE SYNTAX INTEGER { notHelping(1), helping(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether the router is acting as a graceful restart helper for the neighbor." ::= { ospfv3VirtNbrEntry 13 } ospfv3VirtNbrRestartHelperAge OBJECT-TYPE SYNTAX Ospfv3UpToRefreshIntervalTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Remaining time in the current OSPF graceful restart interval, if the router is acting as a restart helper for the neighbor." Joyal & Manral Standards Track [Page 64] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3VirtNbrEntry 14 } ospfv3VirtNbrRestartHelperExitReason OBJECT-TYPE SYNTAX INTEGER { none(1), inProgress(2), completed(3), timedOut(4), topologyChanged(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Describes the outcome of the last attempt at acting as a graceful restart helper for the neighbor. none: no restart has yet been attempted. inProgress: a restart attempt is currently underway. completed: the last restart completed successfully. timedOut: the last restart timed out. topologyChanged: the last restart was aborted due to a topology change." ::= { ospfv3VirtNbrEntry 15 } -- -- The OSPFv3 Area Aggregate Table -- ospfv3AreaAggregateTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3AreaAggregateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Area Aggregate Table acts as an adjunct to the Area Table. It describes those address aggregates that are configured to be propagated from an area. Its purpose is to reduce the amount of information that is known beyond an area's borders. A range of IPv6 prefixes specified by a prefix / prefix length pair. Note that if ranges are configured such that one range subsumes another range, the most specific match is the preferred one." ::= { ospfv3Objects 12 } Joyal & Manral Standards Track [Page 65] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaAggregateEntry OBJECT-TYPE SYNTAX Ospfv3AreaAggregateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single area aggregate entry. Information in this table is persistent, and when this object is written, the entity SHOULD save the change to non-volatile storage." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" INDEX { ospfv3AreaAggregateAreaID, ospfv3AreaAggregateAreaLsdbType, ospfv3AreaAggregatePrefixType, ospfv3AreaAggregatePrefix, ospfv3AreaAggregatePrefixLength } ::= { ospfv3AreaAggregateTable 1 } Ospfv3AreaAggregateEntry ::= SEQUENCE { ospfv3AreaAggregateAreaID Ospfv3AreaIdTC, ospfv3AreaAggregateAreaLsdbType INTEGER, ospfv3AreaAggregatePrefixType InetAddressType, ospfv3AreaAggregatePrefix InetAddress, ospfv3AreaAggregatePrefixLength InetAddressPrefixLength, ospfv3AreaAggregateRowStatus RowStatus, ospfv3AreaAggregateEffect INTEGER, ospfv3AreaAggregateRouteTag Unsigned32 } ospfv3AreaAggregateAreaID OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The area the Address Aggregate is to be found within." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" ::= { ospfv3AreaAggregateEntry 1 } Joyal & Manral Standards Track [Page 66] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaAggregateAreaLsdbType OBJECT-TYPE SYNTAX INTEGER { interAreaPrefixLsa(8195), -- 0x2003 nssaExternalLsa(8199) -- 0x2007 } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the Address Aggregate. This field specifies the Area LSDB type that this Address Aggregate applies to." REFERENCE "OSPF Version 2, Appendix A.4.1, The LSA header" ::= { ospfv3AreaAggregateEntry 2 } ospfv3AreaAggregatePrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The prefix type of ospfv3AreaAggregatePrefix. Only IPv6 addresses are expected." ::= { ospfv3AreaAggregateEntry 3 } ospfv3AreaAggregatePrefix OBJECT-TYPE SYNTAX InetAddress (SIZE (0..16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IPv6 prefix." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" ::= { ospfv3AreaAggregateEntry 4 } ospfv3AreaAggregatePrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength (3..128) UNITS "bits" MAX-ACCESS not-accessible STATUS current DESCRIPTION "The length of the prefix (in bits). A prefix can not be shorter than 3 bits." REFERENCE "OSPF Version 2, Appendix C.2, Area parameters" ::= { ospfv3AreaAggregateEntry 5 } ospfv3AreaAggregateRowStatus OBJECT-TYPE SYNTAX RowStatus Joyal & Manral Standards Track [Page 67] RFC 5643 OSPFv3 MIB August 2009 MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { ospfv3AreaAggregateEntry 6 } ospfv3AreaAggregateEffect OBJECT-TYPE SYNTAX INTEGER { advertiseMatching(1), doNotAdvertiseMatching(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Prefixes subsumed by ranges will either trigger the advertisement of the indicated aggregate (advertiseMatching) or result in the prefix not being advertised at all outside the area." DEFVAL { advertiseMatching } ::= { ospfv3AreaAggregateEntry 7 } ospfv3AreaAggregateRouteTag OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This tag is advertised only in the summarized As-External LSA when summarizing from NSSA-LSAs to AS-External-LSAs." DEFVAL { 0 } ::= { ospfv3AreaAggregateEntry 8 } -- OSPFv3 Link-Scope Link State Database, for virtual interfaces ospfv3VirtLinkLsdbTable OBJECT-TYPE SYNTAX SEQUENCE OF Ospfv3VirtLinkLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The OSPFv3 Process's Link-scope LSDB for virtual interfaces. The LSDB contains the Link-scope link state advertisements from virtual interfaces." Joyal & Manral Standards Track [Page 68] RFC 5643 OSPFv3 MIB August 2009 ::= { ospfv3Objects 13 } ospfv3VirtLinkLsdbEntry OBJECT-TYPE SYNTAX Ospfv3VirtLinkLsdbEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single Link-scope link state advertisement for a virtual interface." INDEX { ospfv3VirtLinkLsdbIfAreaId, ospfv3VirtLinkLsdbIfNeighbor, ospfv3VirtLinkLsdbType, ospfv3VirtLinkLsdbRouterId, ospfv3VirtLinkLsdbLsid } ::= { ospfv3VirtLinkLsdbTable 1 } Ospfv3VirtLinkLsdbEntry ::= SEQUENCE { ospfv3VirtLinkLsdbIfAreaId Ospfv3AreaIdTC, ospfv3VirtLinkLsdbIfNeighbor Ospfv3RouterIdTC, ospfv3VirtLinkLsdbType Unsigned32, ospfv3VirtLinkLsdbRouterId Ospfv3RouterIdTC, ospfv3VirtLinkLsdbLsid Ospfv3LsIdTC, ospfv3VirtLinkLsdbSequence Ospfv3LsaSequenceTC, ospfv3VirtLinkLsdbAge Ospfv3LsaAgeTC, ospfv3VirtLinkLsdbChecksum Integer32, ospfv3VirtLinkLsdbAdvertisement OCTET STRING, ospfv3VirtLinkLsdbTypeKnown TruthValue } ospfv3VirtLinkLsdbIfAreaId OBJECT-TYPE SYNTAX Ospfv3AreaIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The transit area that the virtual link traverses. By definition, this is not Area 0." ::= { ospfv3VirtLinkLsdbEntry 1 } Joyal & Manral Standards Track [Page 69] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtLinkLsdbIfNeighbor OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Router ID of the virtual neighbor." ::= { ospfv3VirtLinkLsdbEntry 2 } ospfv3VirtLinkLsdbType OBJECT-TYPE SYNTAX Unsigned32(0..'FFFFFFFF'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the link state advertisement. Each link state type has a separate advertisement format. Link-scope LSAs unrecognized by the router are also stored in this database." ::= { ospfv3VirtLinkLsdbEntry 3 } ospfv3VirtLinkLsdbRouterId OBJECT-TYPE SYNTAX Ospfv3RouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The 32-bit number that uniquely identifies the originating router in the Autonomous System." REFERENCE "OSPF Version 2, Appendix C.1, Global parameters" ::= { ospfv3VirtLinkLsdbEntry 4 } ospfv3VirtLinkLsdbLsid OBJECT-TYPE SYNTAX Ospfv3LsIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Link State ID is an LS type-specific field containing a unique identifier; it identifies the piece of the routing domain that is being described by the advertisement. In contrast to OSPFv2, the LSID has no addressing semantics." ::= { ospfv3VirtLinkLsdbEntry 5 } -- Note that the OSPF sequence number is a 32-bit signed -- integer. It starts with the value '80000001'h -- or -'7FFFFFFF'h, and increments until '7FFFFFFF'h. -- Thus, a typical sequence number will be very negative. Joyal & Manral Standards Track [Page 70] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtLinkLsdbSequence OBJECT-TYPE SYNTAX Ospfv3LsaSequenceTC MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence number field is a signed 32-bit integer. It is used to detect old and duplicate link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number, the more recent the advertisement." REFERENCE "OSPF Version 2, Section 12.1.6, LS sequence number" ::= { ospfv3VirtLinkLsdbEntry 6 } ospfv3VirtLinkLsdbAge OBJECT-TYPE SYNTAX Ospfv3LsaAgeTC UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the age of the link state advertisement in seconds. The high-order bit of the LS age field is considered the DoNotAge bit for support of on-demand circuits." REFERENCE "OSPF Version 2, Section 12.1.1, LS age; Extending OSPF to Support Demand Circuits, Section 2.2, The LS age field." ::= { ospfv3VirtLinkLsdbEntry 7 } ospfv3VirtLinkLsdbChecksum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum." REFERENCE "OSPF Version 2, Section 12.1.7, LS checksum" ::= { ospfv3VirtLinkLsdbEntry 8 } Joyal & Manral Standards Track [Page 71] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtLinkLsdbAdvertisement OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..65535)) MAX-ACCESS read-only STATUS current DESCRIPTION "The entire link state advertisement, including its header." ::= { ospfv3VirtLinkLsdbEntry 9 } ospfv3VirtLinkLsdbTypeKnown OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value true (1) indicates that the LSA type is recognized by this router." ::= { ospfv3VirtLinkLsdbEntry 10 } -- The Ospfv3 Notification Table -- The Ospfv3 Notification Table records fields that are -- required for notifications. ospfv3NotificationEntry OBJECT IDENTIFIER ::= { ospfv3Objects 14 } ospfv3ConfigErrorType OBJECT-TYPE SYNTAX INTEGER { badVersion(1), areaMismatch(2), unknownNbmaNbr(3), -- Router is DR eligible unknownVirtualNbr(4), helloIntervalMismatch(5), deadIntervalMismatch(6), optionMismatch(7), mtuMismatch(8), duplicateRouterId(9), noError(10) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Potential types of configuration conflicts. Used by the ospfv3ConfigError and ospfv3ConfigVirtError notifications." ::= { ospfv3NotificationEntry 1 } Joyal & Manral Standards Track [Page 72] RFC 5643 OSPFv3 MIB August 2009 ospfv3PacketType OBJECT-TYPE SYNTAX INTEGER { hello(1), dbDescript(2), lsReq(3), lsUpdate(4), lsAck(5), nullPacket(6) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "OSPFv3 packet types." ::= { ospfv3NotificationEntry 2 } ospfv3PacketSrc OBJECT-TYPE SYNTAX InetAddressIPv6 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The IPv6 address of an inbound packet that cannot be identified by a neighbor instance. Only IPv6 addresses without zone index are expected." ::= { ospfv3NotificationEntry 3 } -- Notification Definitions -- The notifications need to be throttled so as to not overwhelm the -- management agent in case of rapid changes to the OSPFv3 module. ospfv3VirtIfStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3VirtIfState -- The new state } STATUS current DESCRIPTION "An ospfv3VirtIfStateChange notification signifies that there has been a change in the state of an OSPFv3 virtual interface. This notification should be generated when the interface state regresses (e.g., goes from Point-to-Point to Down) or progresses to a terminal state (i.e., Point-to-Point)." ::= { ospfv3Notifications 1 } ospfv3NbrStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3NbrState -- The new state Joyal & Manral Standards Track [Page 73] RFC 5643 OSPFv3 MIB August 2009 } STATUS current DESCRIPTION "An ospfv3NbrStateChange notification signifies that there has been a change in the state of a non-virtual OSPFv3 neighbor. This notification should be generated when the neighbor state regresses (e.g., goes from Attempt or Full to 1-Way or Down) or progresses to a terminal state (e.g., 2-Way or Full). When a neighbor transitions from or to Full on non-broadcast multi-access and broadcast networks, the notification should be generated by the Designated Router. A Designated Router transitioning to Down will be noted by ospfIfStateChange." ::= { ospfv3Notifications 2 } ospfv3VirtNbrStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3VirtNbrState -- The new state } STATUS current DESCRIPTION "An ospfv3VirtNbrStateChange notification signifies that there has been a change in the state of an OSPFv3 virtual neighbor. This notification should be generated when the neighbor state regresses (e.g., goes from Attempt or Full to 1-Way or Down) or progresses to a terminal state (e.g., Full)." ::= { ospfv3Notifications 3 } ospfv3IfConfigError NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3IfState, -- State of the interface ospfv3PacketSrc, -- IPv6 address of source ospfv3ConfigErrorType, -- Type of error ospfv3PacketType -- Type of packet } STATUS current DESCRIPTION "An ospfv3IfConfigError notification signifies that a packet has been received on a non-virtual interface from a router whose configuration parameters conflict with this router's configuration parameters. Note that the event optionMismatch should cause a notification only if it prevents an adjacency from forming." ::= { ospfv3Notifications 4 } Joyal & Manral Standards Track [Page 74] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtIfConfigError NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3VirtIfState, -- State of the interface ospfv3ConfigErrorType, -- Type of error ospfv3PacketType } STATUS current DESCRIPTION "An ospfv3VirtIfConfigError notification signifies that a packet has been received on a virtual interface from a router whose configuration parameters conflict with this router's configuration parameters. Note that the event optionMismatch should cause a notification only if it prevents an adjacency from forming." ::= { ospfv3Notifications 5 } ospfv3IfRxBadPacket NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3IfState, -- State of the interface ospfv3PacketSrc, -- The source IPv6 address ospfv3PacketType -- Type of packet } STATUS current DESCRIPTION "An ospfv3IfRxBadPacket notification signifies that an OSPFv3 packet that cannot be parsed has been received on a non-virtual interface." ::= { ospfv3Notifications 6 } ospfv3VirtIfRxBadPacket NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3VirtIfState, -- State of the interface ospfv3PacketType -- Type of packet } STATUS current DESCRIPTION "An ospfv3VirtIfRxBadPacket notification signifies that an OSPFv3 packet that cannot be parsed has been received on a virtual interface." ::= { ospfv3Notifications 7 } ospfv3LsdbOverflow NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3ExtAreaLsdbLimit -- Limit on External LSAs } STATUS current Joyal & Manral Standards Track [Page 75] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "An ospfv3LsdbOverflow notification signifies that the number of LSAs in the router's link state database has exceeded ospfv3ExtAreaLsdbLimit." ::= { ospfv3Notifications 8 } ospfv3LsdbApproachingOverflow NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3ExtAreaLsdbLimit } STATUS current DESCRIPTION "An ospfv3LsdbApproachingOverflow notification signifies that the number of LSAs in the router's link state database has exceeded ninety percent of ospfv3ExtAreaLsdbLimit." ::= { ospfv3Notifications 9 } ospfv3IfStateChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3IfState -- The new state } STATUS current DESCRIPTION "An ospfv3IfStateChange notification signifies that there has been a change in the state of a non-virtual OSPFv3 interface. This notification should be generated when the interface state regresses (e.g., goes from DR to Down) or progresses to a terminal state (i.e., Point-to-Point, DR Other, DR, or Backup)." ::= { ospfv3Notifications 10 } ospfv3NssaTranslatorStatusChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3AreaNssaTranslatorState -- new state } STATUS current DESCRIPTION "An ospfv3NssaTranslatorStatusChange notification indicates that there has been a change in the router's ability to translate OSPFv3 NSSA LSAs into OSPFv3 External LSAs. This notification should be generated when the Translator Status transitions from or to any defined status on a per-area basis." ::= { ospfv3Notifications 11 } Joyal & Manral Standards Track [Page 76] RFC 5643 OSPFv3 MIB August 2009 ospfv3RestartStatusChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3RestartStatus, -- new status ospfv3RestartInterval, ospfv3RestartExitReason } STATUS current DESCRIPTION "An ospfv3RestartStatusChange notification signifies that there has been a change in the graceful restart state for the router. This notification should be generated when the router restart status changes." ::= { ospfv3Notifications 12 } ospfv3NbrRestartHelperStatusChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3NbrRestartHelperStatus, -- new status ospfv3NbrRestartHelperAge, ospfv3NbrRestartHelperExitReason } STATUS current DESCRIPTION "An ospfv3NbrRestartHelperStatusChange notification signifies that there has been a change in the graceful restart helper state for the neighbor. This notification should be generated when the neighbor restart helper status transitions for a neighbor." ::= { ospfv3Notifications 13 } ospfv3VirtNbrRestartHelperStatusChange NOTIFICATION-TYPE OBJECTS { ospfv3RouterId, -- The originator of the notification ospfv3VirtNbrRestartHelperStatus, -- new status ospfv3VirtNbrRestartHelperAge, ospfv3VirtNbrRestartHelperExitReason } STATUS current DESCRIPTION "An ospfv3VirtNbrRestartHelperStatusChange notification signifies that there has been a change in the graceful restart helper state for the virtual neighbor. This notification should be generated when the virtual neighbor restart helper status transitions for a virtual neighbor." ::= { ospfv3Notifications 14 } -- Conformance Information Joyal & Manral Standards Track [Page 77] RFC 5643 OSPFv3 MIB August 2009 ospfv3Groups OBJECT IDENTIFIER ::= { ospfv3Conformance 1 } ospfv3Compliances OBJECT IDENTIFIER ::= { ospfv3Conformance 2 } -- Compliance Statements ospfv3FullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement" MODULE -- this module MANDATORY-GROUPS { ospfv3BasicGroup, ospfv3AreaGroup, ospfv3IfGroup, ospfv3VirtIfGroup, ospfv3NbrGroup, ospfv3CfgNbrGroup, ospfv3VirtNbrGroup, ospfv3AreaAggregateGroup } GROUP ospfv3AsLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their AS-scope link state database." GROUP ospfv3AreaLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their Area-scope link state database." GROUP ospfv3LinkLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their Link-scope link state database for non-virtual interfaces." GROUP ospfv3VirtLinkLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their Link-scope link state database for virtual interfaces." GROUP ospfv3HostGroup DESCRIPTION "This group is required for OSPFv3 systems that support attached hosts." Joyal & Manral Standards Track [Page 78] RFC 5643 OSPFv3 MIB August 2009 GROUP ospfv3NotificationObjectGroup DESCRIPTION "This group is required for OSPFv3 systems that support OSPFv3 notifications." GROUP ospfv3NotificationGroup DESCRIPTION "This group is required for OSPFv3 systems that support OSPFv3 notifications." OBJECT ospfv3NbrAddressType SYNTAX InetAddressType { ipv6(2) } DESCRIPTION "An implementation is only required to support IPv6 address without zone index." OBJECT ospfv3NbrAddress SYNTAX InetAddress (SIZE (16)) DESCRIPTION "An implementation is only required to support IPv6 address without zone index." OBJECT ospfv3VirtNbrAddressType SYNTAX InetAddressType { ipv6(2) } DESCRIPTION "An implementation is only required to support IPv6 address without zone index." OBJECT ospfv3VirtNbrAddress SYNTAX InetAddress (SIZE (16)) DESCRIPTION "An implementation is only required to support IPv6 address without zone index." ::= { ospfv3Compliances 1 } ospfv3ReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB module is implemented without support for read-create (i.e., in read-only mode), the implementation can claim read-only compliance. Such a device can then be monitored, but cannot be configured with this MIB." MODULE -- this module MANDATORY-GROUPS { ospfv3BasicGroup, Joyal & Manral Standards Track [Page 79] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaGroup, ospfv3IfGroup, ospfv3VirtIfGroup, ospfv3NbrGroup, ospfv3CfgNbrGroup, ospfv3VirtNbrGroup, ospfv3AreaAggregateGroup } GROUP ospfv3AsLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their AS-scope link state database." GROUP ospfv3AreaLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their Area-scope link state database." GROUP ospfv3LinkLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their Link-scope link state database for non-virtual interfaces." GROUP ospfv3VirtLinkLsdbGroup DESCRIPTION "This group is required for OSPFv3 systems that display their Link-scope link state database for virtual interfaces." GROUP ospfv3HostGroup DESCRIPTION "This group is required for OSPFv3 systems that support attached hosts." GROUP ospfv3NotificationObjectGroup DESCRIPTION "This group is required for OSPFv3 systems that support OSPFv3 notifications." GROUP ospfv3NotificationGroup DESCRIPTION "This group is required for OSPFv3 systems that support OSPFv3 notifications." OBJECT ospfv3RouterId MIN-ACCESS read-only Joyal & Manral Standards Track [Page 80] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "Write access is not required." OBJECT ospfv3AdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3ExtAreaLsdbLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3ExitOverflowInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3DemandExtensions MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3ReferenceBandwidth MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3RestartSupport MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3RestartInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3RestartStrictLsaChecking MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3NotificationEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." Joyal & Manral Standards Track [Page 81] RFC 5643 OSPFv3 MIB August 2009 OBJECT ospfv3StubRouterAdvertisement MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaImportAsExtern MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaSummary MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaStubMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaNssaTranslatorRole MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaNssaTranslatorStabInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaStubMetricType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaTEEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." Joyal & Manral Standards Track [Page 82] RFC 5643 OSPFv3 MIB August 2009 OBJECT ospfv3HostMetric MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3HostRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3HostAreaID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfAreaId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfRtrPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfTransitDelay MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfRetransInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." Joyal & Manral Standards Track [Page 83] RFC 5643 OSPFv3 MIB August 2009 OBJECT ospfv3IfHelloInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfRtrDeadInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfPollInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfDemand MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfMetricValue MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfDemandNbrProbe MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfDemandNbrProbeRetransLimit MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfDemandNbrProbeInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." Joyal & Manral Standards Track [Page 84] RFC 5643 OSPFv3 MIB August 2009 OBJECT ospfv3IfTEDisabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3IfLinkLSASuppression MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3VirtIfTransitDelay MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3VirtIfRetransInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3VirtIfHelloInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3VirtIfRtrDeadInterval MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3VirtIfRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3CfgNbrPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3CfgNbrRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." Joyal & Manral Standards Track [Page 85] RFC 5643 OSPFv3 MIB August 2009 OBJECT ospfv3AreaAggregateRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaAggregateEffect MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT ospfv3AreaAggregateRouteTag MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { ospfv3Compliances 2 } -- units of conformance ospfv3BasicGroup OBJECT-GROUP OBJECTS { ospfv3RouterId, ospfv3AdminStatus, ospfv3VersionNumber, ospfv3AreaBdrRtrStatus, ospfv3ASBdrRtrStatus, ospfv3AsScopeLsaCount, ospfv3AsScopeLsaCksumSum, ospfv3OriginateNewLsas, ospfv3RxNewLsas, ospfv3ExtLsaCount, ospfv3ExtAreaLsdbLimit, ospfv3ExitOverflowInterval, ospfv3DemandExtensions, ospfv3ReferenceBandwidth, ospfv3RestartSupport, ospfv3RestartInterval, ospfv3RestartStrictLsaChecking, ospfv3RestartStatus, ospfv3RestartAge, ospfv3RestartExitReason, ospfv3NotificationEnable, ospfv3StubRouterSupport, ospfv3StubRouterAdvertisement, ospfv3DiscontinuityTime, ospfv3RestartTime } STATUS current Joyal & Manral Standards Track [Page 86] RFC 5643 OSPFv3 MIB August 2009 DESCRIPTION "These objects are used for managing/monitoring OSPFv3 global parameters." ::= { ospfv3Groups 1 } ospfv3AreaGroup OBJECT-GROUP OBJECTS { ospfv3AreaImportAsExtern, ospfv3AreaSpfRuns, ospfv3AreaBdrRtrCount, ospfv3AreaAsBdrRtrCount, ospfv3AreaScopeLsaCount, ospfv3AreaScopeLsaCksumSum, ospfv3AreaSummary, ospfv3AreaRowStatus, ospfv3AreaStubMetric, ospfv3AreaNssaTranslatorRole, ospfv3AreaNssaTranslatorState, ospfv3AreaNssaTranslatorStabInterval, ospfv3AreaNssaTranslatorEvents, ospfv3AreaStubMetricType, ospfv3AreaTEEnabled } STATUS current DESCRIPTION "These objects are used for OSPFv3 systems supporting areas." ::= { ospfv3Groups 2 } ospfv3AsLsdbGroup OBJECT-GROUP OBJECTS { ospfv3AsLsdbSequence, ospfv3AsLsdbAge, ospfv3AsLsdbChecksum, ospfv3AsLsdbAdvertisement, ospfv3AsLsdbTypeKnown } STATUS current DESCRIPTION "These objects are used for OSPFv3 systems that display their AS-scope link state database." ::= { ospfv3Groups 3 } ospfv3AreaLsdbGroup OBJECT-GROUP OBJECTS { ospfv3AreaLsdbSequence, ospfv3AreaLsdbAge, ospfv3AreaLsdbChecksum, Joyal & Manral Standards Track [Page 87] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaLsdbAdvertisement, ospfv3AreaLsdbTypeKnown } STATUS current DESCRIPTION "These objects are used for OSPFv3 systems that display their Area-scope link state database." ::= { ospfv3Groups 4 } ospfv3LinkLsdbGroup OBJECT-GROUP OBJECTS { ospfv3LinkLsdbSequence, ospfv3LinkLsdbAge, ospfv3LinkLsdbChecksum, ospfv3LinkLsdbAdvertisement, ospfv3LinkLsdbTypeKnown } STATUS current DESCRIPTION "These objects are used for OSPFv3 systems that display their Link-scope link state database for non-virtual interfaces." ::= { ospfv3Groups 5 } ospfv3HostGroup OBJECT-GROUP OBJECTS { ospfv3HostMetric, ospfv3HostRowStatus, ospfv3HostAreaID } STATUS current DESCRIPTION "These objects are used for OSPFv3 systems that support attached hosts." ::= { ospfv3Groups 6 } ospfv3IfGroup OBJECT-GROUP OBJECTS { ospfv3IfAreaId, ospfv3IfType, ospfv3IfAdminStatus, ospfv3IfRtrPriority, ospfv3IfTransitDelay, ospfv3IfRetransInterval, ospfv3IfHelloInterval, ospfv3IfRtrDeadInterval, ospfv3IfPollInterval, ospfv3IfState, Joyal & Manral Standards Track [Page 88] RFC 5643 OSPFv3 MIB August 2009 ospfv3IfDesignatedRouter, ospfv3IfBackupDesignatedRouter, ospfv3IfEvents, ospfv3IfRowStatus, ospfv3IfDemand, ospfv3IfMetricValue, ospfv3IfLinkScopeLsaCount, ospfv3IfLinkLsaCksumSum, ospfv3IfDemandNbrProbe, ospfv3IfDemandNbrProbeRetransLimit, ospfv3IfDemandNbrProbeInterval, ospfv3IfTEDisabled, ospfv3IfLinkLSASuppression } STATUS current DESCRIPTION "These interface objects are used for managing/monitoring OSPFv3 interfaces." ::= { ospfv3Groups 7 } ospfv3VirtIfGroup OBJECT-GROUP OBJECTS { ospfv3VirtIfIndex, ospfv3VirtIfInstId, ospfv3VirtIfTransitDelay, ospfv3VirtIfRetransInterval, ospfv3VirtIfHelloInterval, ospfv3VirtIfRtrDeadInterval, ospfv3VirtIfState, ospfv3VirtIfEvents, ospfv3VirtIfRowStatus, ospfv3VirtIfLinkScopeLsaCount, ospfv3VirtIfLinkLsaCksumSum } STATUS current DESCRIPTION "These virtual interface objects are used for managing/monitoring OSPFv3 virtual interfaces." ::= { ospfv3Groups 8 } ospfv3NbrGroup OBJECT-GROUP OBJECTS { ospfv3NbrAddressType, ospfv3NbrAddress, ospfv3NbrOptions, ospfv3NbrPriority, ospfv3NbrState, ospfv3NbrEvents, Joyal & Manral Standards Track [Page 89] RFC 5643 OSPFv3 MIB August 2009 ospfv3NbrLsRetransQLen, ospfv3NbrHelloSuppressed, ospfv3NbrIfId, ospfv3NbrRestartHelperStatus, ospfv3NbrRestartHelperAge, ospfv3NbrRestartHelperExitReason } STATUS current DESCRIPTION "These neighbor objects are used for managing/monitoring OSPFv3 neighbors." ::= { ospfv3Groups 9 } ospfv3CfgNbrGroup OBJECT-GROUP OBJECTS { ospfv3CfgNbrPriority, ospfv3CfgNbrRowStatus } STATUS current DESCRIPTION "These configured neighbor objects are used for managing/monitoring OSPFv3-configured neighbors." ::= { ospfv3Groups 10 } ospfv3VirtNbrGroup OBJECT-GROUP OBJECTS { ospfv3VirtNbrIfIndex, ospfv3VirtNbrIfInstId, ospfv3VirtNbrAddressType, ospfv3VirtNbrAddress, ospfv3VirtNbrOptions, ospfv3VirtNbrState, ospfv3VirtNbrEvents, ospfv3VirtNbrLsRetransQLen, ospfv3VirtNbrHelloSuppressed, ospfv3VirtNbrIfId, ospfv3VirtNbrRestartHelperStatus, ospfv3VirtNbrRestartHelperAge, ospfv3VirtNbrRestartHelperExitReason } STATUS current DESCRIPTION "These virtual neighbor objects are used for managing/monitoring OSPFv3 virtual neighbors." ::= { ospfv3Groups 11 } Joyal & Manral Standards Track [Page 90] RFC 5643 OSPFv3 MIB August 2009 ospfv3AreaAggregateGroup OBJECT-GROUP OBJECTS { ospfv3AreaAggregateRowStatus, ospfv3AreaAggregateEffect, ospfv3AreaAggregateRouteTag } STATUS current DESCRIPTION "These area aggregate objects are required for aggregating OSPFv3 prefixes for summarization across areas." ::= { ospfv3Groups 12 } ospfv3VirtLinkLsdbGroup OBJECT-GROUP OBJECTS { ospfv3VirtLinkLsdbSequence, ospfv3VirtLinkLsdbAge, ospfv3VirtLinkLsdbChecksum, ospfv3VirtLinkLsdbAdvertisement, ospfv3VirtLinkLsdbTypeKnown } STATUS current DESCRIPTION "These objects are used for OSPFv3 systems that display their Link-scope link state database for virtual interfaces." ::= { ospfv3Groups 13 } ospfv3NotificationObjectGroup OBJECT-GROUP OBJECTS { ospfv3ConfigErrorType, ospfv3PacketType, ospfv3PacketSrc } STATUS current DESCRIPTION "These objects are used to record notification parameters." ::= { ospfv3Groups 14 } ospfv3NotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { ospfv3VirtIfStateChange, ospfv3NbrStateChange, ospfv3VirtNbrStateChange, ospfv3IfConfigError, ospfv3VirtIfConfigError, ospfv3IfRxBadPacket, Joyal & Manral Standards Track [Page 91] RFC 5643 OSPFv3 MIB August 2009 ospfv3VirtIfRxBadPacket, ospfv3LsdbOverflow, ospfv3LsdbApproachingOverflow, ospfv3IfStateChange, ospfv3NssaTranslatorStatusChange, ospfv3RestartStatusChange, ospfv3NbrRestartHelperStatusChange, ospfv3VirtNbrRestartHelperStatusChange } STATUS current DESCRIPTION "This group is used for OSPFv3 notifications." ::= { ospfv3Groups 15 } END 6. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Improper manipulation of the objects represented by this MIB module may result in disruption of network connectivity by administratively disabling the entire OSPFv3 entity or individual interfaces, by deleting configured neighbors, by reducing the limit on External LSAs, by changing ASBR status, by manipulating route aggregation, by manipulating interface and route metrics, by changing Hello interval or dead interval, or by changing interface type. Remote monitoring can be defeated by disabling of SNMP notifications. Performance can be impacted by increasing the limit on External LSAs or changing DR/BDR (Designated Router / Backup Designated Router) priority. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Unauthorized access to readable objects in this MIB module allows the discovery of the network topology and operating parameters, which can be used to target further attacks on the network or to gain a competitive business advantage. Joyal & Manral Standards Track [Page 92] RFC 5643 OSPFv3 MIB August 2009 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- ospfv3MIB { mib-2 191 } 8. Acknowledgements This document is based on the MIB for OSPF version 2 [RFC4750]. The editors would like to thank Toshiaki Takada, Ramachandran Radhakrishnan, Harikrishna Golapalli, Mahesh Kurapati, Acee Lindem, Keith McCloghrie, Manish Gupta, Nic Neate, Vanitha N., Vivek Dubey, Ramana Koppula, Boris Benenson, and Hong Zhang for their constructive comments. Special thanks to Joan Cucchiara for her thorough review as the MIB Doctor. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. Joyal & Manral Standards Track [Page 93] RFC 5643 OSPFv3 MIB August 2009 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006. 9.2. Informative References [RFC1224] Steinberg, L., "Techniques for managing asynchronously generated alerts", RFC 1224, May 1991. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. Joyal & Manral Standards Track [Page 94] RFC 5643 OSPFv3 MIB August 2009 Contributors' Addresses Jacek Kwiatkowski Intel Technology Poland ul. Slowackiego 173 80-298 Gdansk, Poland EMail: jacek.kwiatkowski@intel.com Sebastian Zwolinski Intel Technology Poland ul. Slowackiego 173 80-298 Gdansk, Poland EMail: sebastian.zwolinski@intel.com Editors' Addresses Dan Joyal Nortel 600 Technology Park Drive Billerica, MA 01821 EMail: djoyal@nortel.com Vishwas Manral IP Infusion Almora, Uttarakhand India EMail: vishwas@ipinfusion.com Joyal & Manral Standards Track [Page 95] snmp-mibs-downloader-1.1/mibrfcs/rfc5650.txt0000644000000000000000000152077711402176072015605 0ustar Network Working Group M. Morgenstern Request for Comments: 5650 ECI Telecom Ltd. Category: Standards Track S. Baillie U. Bonollo NEC Australia September 2009 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. 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. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Morgenstern, et al. Standards Track [Page 1] RFC 5650 VDSL2-LINE MIB September 2009 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Overview ........................................................2 2.1. Relationship to Other MIBs .................................4 2.2. IANA Considerations ........................................7 2.3. Conventions Used in the MIB Module .........................7 2.4. Structure .................................................11 2.5. Persistence ...............................................13 2.6. Line Topology .............................................16 2.7. Counters, Interval Buckets, and Thresholds ................17 2.8. Profiles ..................................................19 2.9. Notifications .............................................23 3. Definitions ....................................................24 4. Implementation Analysis .......................................204 5. Security Considerations .......................................204 6. Acknowledgments ...............................................215 7. References ....................................................216 7.1. Normative References .....................................216 7.2. Informative References ...................................217 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Overview This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing VDSL2, ADSL, ADSL2, and ADSL2+ lines. Morgenstern, et al. Standards Track [Page 2] RFC 5650 VDSL2-LINE MIB September 2009 The MIB module described in RFC 2662 [RFC2662] describes objects used for managing Asymmetric Bit-Rate DSL (ADSL) interfaces per [T1E1.413], [G.992.1], and [G.992.2]. These object descriptions are based upon the specifications for the ADSL Embedded Operations Channel (EOC) as defined in American National Standards Institute (ANSI) T1E1.413/1995 [T1E1.413] and International Telecommunication Union (ITU-T) G.992.1 [G.992.1] and G.992.2 [G.992.2]. The MIB module described in RFC 4706 [RFC4706] is a wider management model that includes, in addition to ADSL technology, the ADSL2 and ADSL2+ technologies per G.992.3, G.992.4, and G.992.5 ([G.992.3], [G.992.4], and [G.992.5], respectively). This document does not obsolete RFC 2662 [RFC2662] or RFC 4706 [RFC4706], but rather provides a more comprehensive management model that addresses the VDSL2 technology per G.993.2 ([G.993.2]) as well as ADSL, ADSL2, and ADSL2+ technologies. This document does not obsolete RFC 2662 [RFC2662] or RFC 4706 [RFC4706]. RFC 2662 is relevant only for managing modems that do not support any DSL technology other than ADSL (e.g., G.992.1 [G.992.1] and G.992.2 [G.992.2]) especially if the modems were produced prior to approval of ITU-T G.997.1 standard revision 3 [G.997.1]. RFC 4706 is more appropriate for managing modems that support ADSL2 technology variants (with or without being able to support the legacy ADSL). This document supports all ADSL, ADSL2, and VDSL2 standards, but it assumes a more sophisticated management model, which older modems (even ADSL2 ones) may not be able to support. The selection of the appropriate MIB module for any DSL modem is based on the ifType value it reports, as explained in the next section. The management framework for VDSL2 lines [TR-129] specified by the Digital Subscriber Line Forum (DSLF) has been taken into consideration. That framework is based on the ITU-T G.997.1 standard [G.997.1] and its amendment 1 [G.997.1-Am1]. Note that the management model, according to this document, does not allow managing VDSL technology per G.993.1 [G.993.1]. VDSL lines MUST be managed by RFC 3728 [RFC3728]. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of this document. Morgenstern, et al. Standards Track [Page 3] RFC 5650 VDSL2-LINE MIB September 2009 2.1. Relationship to Other MIBs This section outlines the relationship of this MIB module with other MIB modules described in RFCs. Specifically, IF-MIB as defined in RFC 2863 [RFC2863] and ENTITY-MIB as defined in RFC 4133 [RFC4133] are discussed. 2.1.1. Relationship with IF-MIB (RFC 2863) 2.1.1.1. General IF-MIB Integration The VDSL2 Line MIB specifies the detailed objects of a data interface. As such, it needs to integrate with RFC 2863 [RFC2863]. The IANA has assigned the following ifTypes, which may be applicable for VDSL2 lines as well as for ADSL, ADSL2, and ADSL2+ lines: IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... channel(70), -- Channel adsl(94), -- Asymmetric Digital Subscriber Loop ... interleave(124), -- Interleaved Channel fast(125), -- Fast Channel ... adsl2plus(238), -- Asymmetric Digital Subscriber Loop Version 2, Version 2 Plus, and all variants vdsl2(251), -- Very High Speed Digital Subscriber Loop 2 ... } ADSL lines that are identified with ifType=adsl(94) MUST be managed with the MIB specified by RFC 2662. ADSL, ADSL2, and ADSL2+ lines identified with ifType=adsl2plus(238) MUST be managed with the MIB specified by RFC 4706 [RFC4706]. VDSL2, ADSL, ADSL2, and ADSL2+ lines identified with ifType=vdsl2(251) MUST be managed with the MIB specified by this document. In any case, the SNMP agent may use either ifType=interleave(124) or fast(125) for each channel, e.g., depending on whether or not it is capable of using an interleaver on that channel. It may use the ifType=channel (70) when all channels are capable of using an interleaver (e.g., for ADSL2 xTUs). Note that the ifFixedLengthGroup from RFC 2863 [RFC2863] MUST be supported and that the ifRcvAddressGroup does not apply to this MIB module. Morgenstern, et al. Standards Track [Page 4] RFC 5650 VDSL2-LINE MIB September 2009 2.1.1.2. Usage of ifTable The MIB branch identified by ifType contains tables appropriate for the interface types described above. Most such tables extend the ifEntry table, and are indexed by ifIndex. For interfaces in systems implementing this MIB module, those table entries indexed by ifIndex MUST be persistent. The following objects are part of the mandatory ifGeneralInformationGroup in the Interfaces MIB [RFC2863], and are not duplicated in the VDSL2 Line MIB. ifIndex Interface index. ifDescr See interfaces MIB. ifType vdsl2(251), channel(70), interleave(124), or fast(125) ifSpeed Set as appropriate. ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB. ifOperStatus See interfaces MIB. ifLastChange See interfaces MIB. ifName See interfaces MIB. ifAlias See interfaces MIB. ifLinkUpDownTrapEnable Default to enabled(1). ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. ------------------------------------------------------------------- Figure 1: Use of ifTable Objects 2.1.1.3. Usage of ifStackTable Use of the ifStackTable to associate the entries for physical, fast, interleaved channels, and higher layers (e.g., ATM) is shown below. Use of the ifStackTable is necessary because configuration information is stored in profile tables associated with the physical- Morgenstern, et al. Standards Track [Page 5] RFC 5650 VDSL2-LINE MIB September 2009 layer ifEntry only. The channels' ifEntrys need the ifStackTable to find their associated physical-layer entry and thus their configuration parameters. The following example shows the ifStackTable entries for an xDSL line with a single channel that uses an ATM data path. HigherLayer LowerLayer ----------------------------- 0 ATM ATM XdslChannel XdslChannel XdslPhysical XdslPhysical 0 Figure 2: ifStackTable Entries for ATM Path over a Single xDSL Channel 2.1.2. Relationship with the ENTITY-MIB (RFC 4133) Implementation of the Entity MIB [RFC4133] is optional. It in no way alters the information required in the VDSL2 Line MIB, nor does it alter the relationship with IF-MIB. The Entity MIB introduces a standardized way of presenting the components of complex systems, such as a Digital Subscriber Line Access Multiplexer (DSLAM), that may contain multiple racks, shelves, line cards, and/or ports. The Entity MIB's main goal is to present these system components, their containment relationship, and mapping information with other MIBs such as the Interface MIB and the VDSL2 Line MIB. The Entity MIB is capable of supporting the local DSL termination unit. Thus, assuming the SNMP agent is in the DSLAM, the Entity MIB should include entities for the xTU-C in the entPhysicalTable. The MIB's entAliasMappingTable would contain mapping information identifying the 'ifIndex' object associated with each xTU-C. In case the SNMP agent is actually in the Customer Premise Equipment (CPE), the Entity MIB should include entities for the xTU-R in the entPhysicalTable. In this case, the MIB's entAliasMappingTable would contain mapping information identifying the 'ifIndex' object associated with each xTU-R. Also associating the relationship between the ifTable and Entity MIB, the entPhysicalTable contains an 'entPhysicalName' object, which approximates the semantics of the 'ifName' object from the Interface MIB. Morgenstern, et al. Standards Track [Page 6] RFC 5650 VDSL2-LINE MIB September 2009 2.2. IANA Considerations A new ifType value (251) for Very High Speed Digital Subscriber Loop Version 2 has been allocated for the VDSL2-LINE-MIB module, to distinguish between ADSL lines that are managed with the RFC 2662 management model, ADSL/ADSL2 and ADSL2+ lines that are managed with the RFC 4706 [RFC4706] management model, and VDSL2/ADSL/ADSL2 and ADSL2+ lines that are managed with the model defined in this document. Also, the VDSL2-LINE-MIB module has been assigned a single object identifier (251) for its MODULE-IDENTITY. The IANA has allocated this object identifier in the transmission subtree. As performed in the past for the ADSL2-LINE-MIB module, the IANA has ensured that the allocated ifType value is the same as the allocated branch number in the transmission subtree. 2.3. Conventions Used in the MIB Module 2.3.1. Naming Conventions ADSL Asymmetric (bit rate) DSL ATM Asynchronous Transfer Mode atuc ADSL/ADSL2 or ADSL2+ line termination unit - central office atur ADSL/ADSL2 or ADSL2+ line termination unit - Remote site BER Bit Error Rate CO Central Office CPE Customer Premise Equipment CRC Cyclic Redundancy Check DELT Dual Ended Loop Test DMT Discrete Multitone DPBO Downstream PBO DRA Dynamic Rate Adaptation DSL Digital Subscriber Line/Loop DSLF DSL Forum EOC Embedded Operations Channel ES Errored Second FE Far-End (unit) FEBE Far-End Block Error FEC Forward Error Correction FFEC Far-End FEC IMA Inverse Multiplexing over ATM INP Impulse Noise Protection ISDN Integrated Services Digital Network LDSF Loop Diagnostic State Forced Morgenstern, et al. Standards Track [Page 7] RFC 5650 VDSL2-LINE MIB September 2009 LOF Loss Of Frame LOS Loss Of Signal LOSS LOS Seconds LPR Loss of Power NE Network Element or Near-End (unit) NSC Highest transmittable subcarriers index NSCds NSC for downstream transmission direction NSCus NSC for upstream transmission direction OLR Online Reconfiguration PBO Power Backoff PM Performance Monitoring PMS-TC Physical Media Specific-Transmission Convergence POTS Plain Old Telephone Service PSD Power Spectral Density PTM Packet Transfer Mode QLN Quiet Line RDI Remote Defect Indication RFI Radio Frequency Interference SEF Severely Errored Frame SES Severely Errored Second SNR Signal-to-Noise Ratio TC Transmission Convergence (e.g., ATM sub layer) TCM (TCM-ISDN) Time Compression Multiplexed ISDN UAS Unavailable Seconds U-C Loop interface-central office end UPBO Upstream PBO U-R Loop interface-remote side (i.e., subscriber end of the loop) US0 Upstream band number 0 VDSL Very high speed DSL VTU-O VDSL2 Transceiver Unit - central office or Network Element End VTU-R VTU at the remote site (i.e., subscriber end of the loop) vtuc VDSL2 line termination unit - central office vtur VDSL2 line termination unit - Remote site xDSL Either VDSL2, ADSL, ADSL2 or ADSL2+ xTU-C ADSL/ADSL2/ADSL2+ or VDSL2 line termination unit - central office xTU-R ADSL/ADSL2/ADSL2+ or VDSL2 line termination unit - Remote site xTU A line termination unit; either an xTU-C or xTU-R Morgenstern, et al. Standards Track [Page 8] RFC 5650 VDSL2-LINE MIB September 2009 2.3.2. Textual Conventions The following lists the textual conventions defined by VDSL2-LINE-TC- MIB in this document: o Xdsl2Unit o Xdsl2Direction o Xdsl2Band o Xdsl2TransmissionModeType o Xdsl2RaMode o Xdsl2InitResult o Xdsl2OperationModes o Xdsl2PowerMngState o Xdsl2ConfPmsForce o Xdsl2LinePmMode o Xdsl2LineLdsf o Xdsl2LdsfResult o Xdsl2LineBpsc o Xdsl2BpscResult o Xdsl2LineReset o Xdsl2LineProfiles o Xdsl2LineClassMask o Xdsl2LineLimitMask o Xdsl2LineUs0Disable o Xdsl2LineUs0Mask o Xdsl2SymbolProtection o Xdsl2SymbolProtection8 Morgenstern, et al. Standards Track [Page 9] RFC 5650 VDSL2-LINE MIB September 2009 o Xdsl2MaxBer o Xdsl2ChInitPolicy o Xdsl2ScMaskDs o Xdsl2ScMaskUs o Xdsl2CarMask o Xdsl2RfiBands o Xdsl2PsdMaskDs o Xdsl2PsdMaskUs o Xdsl2Tssi o Xdsl2LastTransmittedState o Xdsl2LineStatus o Xdsl2ChInpReport o Xdsl2ChAtmStatus o Xdsl2ChPtmStatus o Xdsl2UpboKLF o Xdsl2BandUs o Xdsl2LinePsdMaskSelectUs o Xdsl2LineCeFlag o Xdsl2LineSnrMode o Xdsl2LineTxRefVnDs o Xdsl2LineTxRefVnUs o Xdsl2BitsAlloc o Xdsl2MrefPsdDs o Xdsl2MrefPsdUs Morgenstern, et al. Standards Track [Page 10] RFC 5650 VDSL2-LINE MIB September 2009 2.4. Structure The MIB module is structured into the following MIB groups: o Line Configuration, Maintenance, and Status Group: This group supports MIB objects for configuring parameters for the VDSL2/ADSL/ADSL2 or ADSL2+ line and retrieving line status information. It also supports MIB objects for configuring a requested power state or initiating a Dual Ended Loop Test (DELT) process in the VDSL2/ADSL/ADSL2 or ADSL2+ line. It contains the following tables: - xdsl2LineTable - xdsl2LineSegmentTable - xdsl2LineBandTable o Channel Status Group: This group supports MIB objects for retrieving channel layer status information. It contains the following table: - xdsl2ChannelStatusTable o Subcarrier Status Group: This group supports MIB objects for retrieving the subcarrier layer status information, mostly collected by a Dual Ended Loop Test (DELT) process. It contains the following tables: - xdsl2SCStatusTable - xdsl2SCStatusBandTable - xdsl2SCStatusSegmentTable o Unit Inventory Group: This group supports MIB objects for retrieving Unit inventory information about units in VDSL2/ADSL/ADSL2 or ADSL2+ lines via the EOC. It contains the following table: - xdsl2LineInventoryTable o Current Performance Group: This group supports MIB objects that provide the current performance information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, unit, and channel levels. It contains the following tables: Morgenstern, et al. Standards Track [Page 11] RFC 5650 VDSL2-LINE MIB September 2009 - xdsl2PMLineCurrTable - xdsl2PMLineInitCurrTable - xdsl2PMChCurrTable o 15-Minute Interval Performance Group: This group supports MIB objects that provide historic performance information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, unit, and channel levels in 15-minute intervals. It contains the following tables: - xdsl2PMLineHist15MinTable - xdsl2PMLineInitHist15MinTable - xdsl2PMChHist15MinTable o 1-Day Interval Performance Group: This group supports MIB objects that provide historic performance information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, unit, and channel levels in 1-day intervals. It contains the following tables: - xdsl2PMLineHist1DayTable - xdsl2PMLineInitHist1DayTable - xdsl2PMChHist1DTable o Configuration Template and Profile Group: This group supports MIB objects for defining configuration profiles for VDSL2/ADSL/ADSL2 and ADSL2+ lines and channels, as well as configuration templates. Each configuration template is comprised of a one-line configuration profile and one or more channel configuration profiles. This group contains the following tables: - xdsl2LineConfTemplateTable - xdsl2LineConfProfTable - xdsl2LineConfProfModeSpecTable - xdsl2LineConfProfModeSpecBandUsTable - xdsl2ChConfProfileTable o Alarm Configuration Template and Profile Group: This group supports MIB objects for defining alarm profiles for VDSL2/ADSL/ADSL2 and ADSL2+ lines and channels, as well as alarm templates. Each alarm template is comprised of one line alarm profile and one or more channel-alarm profiles. This group contains the following tables: Morgenstern, et al. Standards Track [Page 12] RFC 5650 VDSL2-LINE MIB September 2009 - xdsl2LineAlarmConfTemplateTable - xdsl2LineAlarmConfProfileTable - xdsl2ChAlarmConfProfileTable o Notifications Group: This group defines the notifications supported for VDSL2/ADSL/ ADSL2 and ADSL2+ lines: - xdsl2LinePerfFECSThreshXtuc - xdsl2LinePerfFECSThreshXtur - xdsl2LinePerfESThreshXtuc - xdsl2LinePerfESThreshXtur - xdsl2LinePerfSESThreshXtuc - xdsl2LinePerfSESThreshXtur - xdsl2LinePerfLOSSThreshXtuc - xdsl2LinePerfLOSSThreshXtur - xdsl2LinePerfUASThreshXtuc - xdsl2LinePerfUASThreshXtur - xdsl2LinePerfCodingViolationsThreshXtuc - xdsl2LinePerfCodingViolationsThreshXtur - xdsl2LinePerfCorrectedThreshXtuc - xdsl2LinePerfCorrectedThreshXtur - xdsl2LinePerfFailedFullInitThresh - xdsl2LinePerfFailedShortInitThresh - xdsl2LineStatusChangeXtuc - xdsl2LineStatusChangeXtur 2.5. Persistence All read-create objects and most read-write objects defined in this MIB module SHOULD be stored persistently. The following is an exhaustive list of these persistent objects: xdsl2LineConfTemplate xdsl2LineAlarmConfTemplate xdsl2LineCmndConfPmsf xdsl2LConfTempTemplateName xdsl2LConfTempLineProfile xdsl2LConfTempChan1ConfProfile xdsl2LConfTempChan1RaRatioDs xdsl2LConfTempChan1RaRatioUs xdsl2LConfTempChan2ConfProfile xdsl2LConfTempChan2RaRatioDs xdsl2LConfTempChan2RaRatioUs xdsl2LConfTempChan3ConfProfile xdsl2LConfTempChan3RaRatioDs xdsl2LConfTempChan3RaRatioUs Morgenstern, et al. Standards Track [Page 13] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfTempChan4ConfProfile xdsl2LConfTempChan4RaRatioDs xdsl2LConfTempChan4RaRatioUs xdsl2LConfTempRowStatus xdsl2LConfProfProfileName xdsl2LConfProfScMaskDs xdsl2LConfProfScMaskUs xdsl2LConfProfVdsl2CarMask xdsl2LConfProfRfiBandsDs xdsl2LConfProfRaModeDs xdsl2LConfProfRaModeUs xdsl2LConfProfRaUsNrmDs xdsl2LConfProfRaUsNrmUs xdsl2LConfProfRaUsTimeDs xdsl2LConfProfRaUsTimeUs xdsl2LConfProfRaDsNrmDs xdsl2LConfProfRaDsNrmUs xdsl2LConfProfRaDsTimeDs xdsl2LConfProfRaDsTimeUs xdsl2LConfProfTargetSnrmDs xdsl2LConfProfTargetSnrmUs xdsl2LConfProfMaxSnrmDs xdsl2LConfProfMaxSnrmUs xdsl2LConfProfMinSnrmDs xdsl2LConfProfMinSnrmUs xdsl2LConfProfMsgMinUs xdsl2LConfProfMsgMinDs xdsl2LConfProfXtuTransSysEna xdsl2LConfProfPmMode xdsl2LConfProfL0Time xdsl2LConfProfL2Time xdsl2LConfProfL2Atpr xdsl2LConfProfL2Atprt xdsl2LConfProfProfiles xdsl2LConfProfDpboEPsd xdsl2LConfProfDpboEsEL xdsl2LConfProfDpboEsCableModelA xdsl2LConfProfDpboEsCableModelB xdsl2LConfProfDpboEsCableModelC xdsl2LConfProfDpboMus xdsl2LConfProfDpboFMin xdsl2LConfProfDpboFMax xdsl2LConfProfUpboKL xdsl2LConfProfUpboKLF xdsl2LConfProfUs0Mask xdsl2LConfProfRowStatus xdsl2LConfProfXdslMode xdsl2LConfProfMaxNomPsdDs Morgenstern, et al. Standards Track [Page 14] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfProfMaxNomPsdUs xdsl2LConfProfMaxNomAtpDs xdsl2LConfProfMaxNomAtpUs xdsl2LConfProfMaxAggRxPwrUs xdsl2LConfProfPsdMaskDs xdsl2LConfProfPsdMaskUs xdsl2LConfProfPsdMaskSelectUs xdsl2LConfProfClassMask xdsl2LConfProfLimitMask xdsl2LConfProfUs0Disabl xdsl2LConfProfModeSpecRowStatus xdsl2LConfProfXdslBandUs xdsl2LConfProfUpboPsdA xdsl2LConfProfUpboPsdB xdsl2LConfProfModeSpecBandUsRowStatus xdsl2ChConfProfProfileName xdsl2ChConfProfMinDataRateDs xdsl2ChConfProfMinDataRateUs xdsl2ChConfProfMinResDataRateDs xdsl2ChConfProfMinResDataRateUs xdsl2ChConfProfMaxDataRateDs xdsl2ChConfProfMaxDataRateUs xdsl2ChConfProfMinDataRateLowPwrDs xdsl2ChConfProfMaxDelayDs xdsl2ChConfProfMaxDelayUs xdsl2ChConfProfMinProtectionDs xdsl2ChConfProfMinProtectionUs xdsl2ChConfProfMaxBerDs xdsl2ChConfProfMaxBerUs xdsl2ChConfProfUsDataRateDs xdsl2ChConfProfDsDataRateDs xdsl2ChConfProfUsDataRateUs xdsl2ChConfProfDsDataRateUs xdsl2ChConfProfImaEnabled xdsl2ChConfProfMaxDelayVar xdsl2ChConfProfInitPolicy xdsl2ChConfProfRowStatus xdsl2LAlarmConfTempTemplateName xdsl2LAlarmConfTempLineProfile xdsl2LAlarmConfTempChan1ConfProfile xdsl2LAlarmConfTempChan2ConfProfile xdsl2LAlarmConfTempChan3ConfProfile xdsl2LAlarmConfTempChan4ConfProfile xdsl2LAlarmConfTempRowStatus xdsl2LineAlarmConfProfileName xdsl2LineAlarmConfProfileXtucThresh15MinFecs xdsl2LineAlarmConfProfileXtucThresh15MinEs xdsl2LineAlarmConfProfileXtucThresh15MinSes Morgenstern, et al. Standards Track [Page 15] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LineAlarmConfProfileXtucThresh15MinLoss xdsl2LineAlarmConfProfileXtucThresh15MinUas xdsl2LineAlarmConfProfileXturThresh15MinFecs xdsl2LineAlarmConfProfileXturThresh15MinEs xdsl2LineAlarmConfProfileXturThresh15MinSes xdsl2LineAlarmConfProfileXturThresh15MinLoss xdsl2LineAlarmConfProfileXturThresh15MinUas xdsl2LineAlarmConfProfileThresh15MinFailedFullInt xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt xdsl2LineAlarmConfProfileRowStatus xdsl2ChAlarmConfProfileName xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations xdsl2ChAlarmConfProfileXtucThresh15MinCorrected xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations xdsl2ChAlarmConfProfileXturThresh15MinCorrected xdsl2ChAlarmConfProfileRowStatus Note, also, that the interface indices in this MIB are maintained persistently. View-based Access Control Model (VACM) data relating to these SHOULD be stored persistently as well [RFC3410]. 2.6. Line Topology A VDSL2/ADSL/ADSL2 and ADSL2+ line consists of two units: atuc or vtuc (a central office termination unit) and atur or vtur (a remote termination unit). There are up to 4 channels (maximum number of channels depends on the specific DSL technology), each carrying an independent information flow, as shown in the figure below. Morgenstern, et al. Standards Track [Page 16] RFC 5650 VDSL2-LINE MIB September 2009 <-- Network Side Customer Side --> || +-------+ +-------+ | |<---------------------1------------------->| | | atuc |<---------------------2------------------->| atur | | or |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| or | | vtuc |<---------------------3------------------->| vtuc | | |<---------------------4------------------->| | +-------+ +-------+ Key: VDSL2/ADSL/ADSL2/ADSL2+ Span <~~~~> VDSL2/ADSL/ADSL2/ADSL2+ twisted-pair -1- Channel #1 carried over the line -2- Optional channel #2 carried over the line -3- Optional channel #3 carried over the line -4- Optional channel #4 carried over the line Figure 3: General Topology for a VDSL2/ADSL/ADSL2/ADSL2+ Line 2.7. Counters, Interval Buckets, and Thresholds 2.7.1. Counters Managed There are various types of counters specified in this MIB. Each counter refers either to the whole VDSL2/ADSL/ADSL2/ADSL2+ line, to one of the xTU entities, or to one of the bearer channels. o On the whole line level For full initializations, failed full initializations, short initializations, and for failed short initializations, there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute "failed" event bucket has an associated threshold notification. o On the xTU level For the LOS seconds, ES, SES, FEC seconds, and UAS, there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute event bucket has an associated threshold notification. Morgenstern, et al. Standards Track [Page 17] RFC 5650 VDSL2-LINE MIB September 2009 o On the bearer channel level For the coding violations (CRC anomalies) and corrected blocks (i.e., FEC events), there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute event bucket has an associated threshold notification. 2.7.2. Minimum Number of Buckets Although it is possible to support up to 96 15-minute history buckets of "interval-counters", systems implementing this MIB module SHOULD practically support at least 16 buckets, as specified in ITU-T G.997.1, paragraph #7.2.7.9. Similarly, it is possible to support up to 30 previous 1-day "interval-counters", but systems implementing this MIB module SHOULD support at least 1 previous day bucket. 2.7.3. Interval Buckets Initialization There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute interval and any wall clock; however, some implementations may align the 15-minute intervals with quarter hours. Likewise, an implementation may choose to align 1-day intervals with the start of a day. Counters are not reset when an xTU is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module). 2.7.4. Interval Buckets Validity As in RFC 3593 [RFC3593] and RFC 2662 [RFC2662], in case the data for an interval is suspect or known to be invalid, the agent MUST report the interval as invalid. If the current 15-minute event bucket is determined to be invalid, the element management system SHOULD ignore its content and the agent MUST NOT generate notifications based upon the value of the event bucket. A valid 15-minute event bucket SHOULD usually count the events for exactly 15 minutes. Similarly, a valid 1-day event bucket SHOULD usually count the events for exactly 24 hours. However, the following scenarios are exceptional: Morgenstern, et al. Standards Track [Page 18] RFC 5650 VDSL2-LINE MIB September 2009 1) For implementations that align the 15-minute intervals with quarter hours and the 1-day intervals with start of a day, the management system may still start the PM process not aligned with the wall clock. Such a management system may wish to retrieve even partial information for the first event buckets, rather than declaring them all as invalid. 2) For an event bucket that suffered relatively short outages, the management system may wish to retrieve the available PM outcomes, rather than declaring the whole event bucket as invalid. This is more important for 1-day event buckets. 3) An event bucket may be shorter or longer than the formal duration if a clock adjustment was performed during the interval. This MIB module allows supporting the exceptional scenarios described above by reporting the actual Monitoring Time of a monitoring interval. This parameter is relevant only for Valid intervals, but is useful for these exceptional scenarios: a) The management system MAY still declare a partial PM interval as Valid and report the actual number of seconds the interval lasted. b) If the interval was shortened or extended due to clock corrections, the management system SHOULD report the actual number of seconds the interval lasted, in addition to reporting that the interval is Valid. 2.8. Profiles As a managed node can handle a large number of xTUs, (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on every xTU may become burdensome. Moreover, most lines are provisioned identically with the same set of parameters. To simplify the provisioning process, this MIB module makes use of profiles and templates. A configuration profile is a set of parameters that can be shared by multiple entities. There is a configuration profile to address line- level provisioning and another type of profile that addresses channel-level provisioning parameters. A configuration template is actually a profile-of-profiles. That is, a template is comprised of one-line configuration profile and one or more channel configuration profiles. A template provides the complete configuration of a line. The same configuration can be shared by multiple lines. Morgenstern, et al. Standards Track [Page 19] RFC 5650 VDSL2-LINE MIB September 2009 In a similar manner to the configuration profiles and templates, this MIB module makes use of templates and profiles for specifying the alarm thresholds associated with performance parameters. This allows provisioning multiple lines with the same criteria for generating threshold crossing notifications. The following paragraphs describe templates and profiles used in this MIB module. 2.8.1. Configuration Profiles and Templates o Line Configuration Profiles - Line configuration profiles contain line-level parameters for configuring VDSL2/ADSL/ADSL2 and ADSL2+ lines. They are defined in the xdsl2LineConfProfTable. The line configuration includes settings such as the specific VDSL2/ADSL/ADSL2 or ADSL2+ modes to enable on the respective line, power spectrum parameters, rate adaptation criteria, and SNR margin-related parameters. A subset of the line configuration parameters depends upon the specific xDSL Mode allowed (i.e., does the profile allow VDSL2, ADSL, ADSL2 and/or ADSL2+?) as well as what annex/annexes of the standard are allowed. This is the reason a line profile MUST include one or more mode-specific extensions. o Channel Configuration Profiles - Channel configuration profiles contain parameters for configuring bearer channels over the VDSL2/ ADSL/ADSL2 and ADSL2+ lines. They are sometimes considered as the service layer configuration of the VDSL2/ADSL/ADSL2 and ADSL2+ lines. They are defined in the xdsl2ChConfProfTable. The channel configuration includes issues such as the desired minimum and maximum rate on each traffic flow direction and impulse noise protection parameters. o Line Configuration Templates - Line configuration templates allow combining line configuration profiles and channel configuration profiles into a comprehensive configuration of the VDSL2/ADSL/ ADSL2 and ADSL2+ line. They are defined in the xdsl2LineConfTemplateTable. The line configuration template includes one index of a line configuration profile and one to four indices of channel configuration profiles. The template also addresses the issue of distributing the excess available data rate on each traffic flow Morgenstern, et al. Standards Track [Page 20] RFC 5650 VDSL2-LINE MIB September 2009 direction (i.e., the data rate left after each channel is allocated a data rate to satisfy its minimum requested data rate) among the various channels. 2.8.2. Alarm Configuration Profiles and Templates o Line Alarm Configuration Profiles - Line-level Alarm configuration profiles contain the threshold values for Performance Monitoring (PM) parameters, counted either on the whole line level or on an xTU level. Thresholds are required only for failures and anomalies. For example, there are thresholds for failed initializations and LOS seconds, but not for the aggregate number of full initializations. These profiles are defined in the xdsl2LineAlarmConfProfileTable. o Channel Alarm Configuration Profiles - Channel-level Alarm configuration profiles contain the threshold values for PM parameters counted on a bearer channel level. Thresholds are defined for two types of anomalies: corrected blocks and coding violations. These profiles are defined in the xdsl2ChAlarmConfProfileTable. o Line Alarm Configuration Templates - Line Alarm configuration templates allow combining line-level alarm configuration profiles and channel-level alarm configuration profiles into a comprehensive configuration of the PM thresholds for the VDSL2/ ADSL/ADSL2 and ADSL2+ line. They are defined in the xdsl2LineAlarmConfTemplateTable. The line alarm configuration template includes one index of a line-level alarm configuration profile and one to four indices of channel-level alarm configuration profiles. 2.8.3. Managing Profiles and Templates The index value for each profile and template is a locally unique, administratively assigned name having the textual convention 'SnmpAdminString' (RFC 3411 [RFC3411]). One or more lines may be configured to share parameters of a single configuration template (e.g., xdsl2LConfTempTemplateName = 'silver') by setting its xdsl2LineConfTemplate object to the value of this template. One or more lines may be configured to share parameters of a single Alarm configuration template (e.g., xdsl2LAlarmConfTempTemplateName = 'silver') by setting its xdsl2LineAlarmConfTemplate object to the value of this template. Morgenstern, et al. Standards Track [Page 21] RFC 5650 VDSL2-LINE MIB September 2009 Before a template can be deleted or taken out of service, it MUST be first unreferenced from all associated lines. Implementations MAY also reject template modification while it is associated with any line. Before a profile can be deleted or taken out of service, it MUST be first unreferenced from all associated templates. Implementations MAY also reject profile modification while it is referenced by any template. Implementations MUST provide a default profile whose name is 'DEFVAL' for each profile and template type. The values of the associated parameters will be vendor-specific unless otherwise indicated in this document. Before a line's templates have been set, these templates will be automatically used by setting xdsl2LineConfTemplate and xdsl2LineAlarmConfTemplate to 'DEFVAL' where appropriate. This default profile name, 'DEFVAL', is considered reserved in the context of profiles and templates defined in this MIB module. Profiles and templates are created, assigned, and deleted dynamically using the profile name and profile row status in each of the profile tables. If the implementation allows modifying a profile or template while it is associated with a line, then such changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line. Network Elements MAY optionally implement a fallback line configuration template (see xdsl2LineConfFallbackTemplate). The fallback template will be tried if the xDSL2 line fails to operate using the primary template. If the xDSL2 line fails to operate using the fallback template, then the primary template should be retried. The xTU-C SHOULD continue to alternate between the primary and fallback templates until one of them succeeds. 2.8.4. Managing Multiple Bearer Channels The number of bearer channels is configured by setting the template objects xdsl2LConfTempChan1ConfProfile, xdsl2LConfTempChan2ConfProfile, xdsl2LConfTempChan3ConfProfile, and xdsl2LConfTempChan4ConfProfile and then assigning that template to a DSL line using the xdsl2LineConfTemplate object. When the number of bearer channels for a DSL line changes, the SNMP agent will automatically create or destroy rows in channel-related tables associated with that line. For example, when a DSL line is operating Morgenstern, et al. Standards Track [Page 22] RFC 5650 VDSL2-LINE MIB September 2009 with one bearer channel, there will be zero rows in channel-related tables for channels two, three, and four. The SNMP agent MUST create and destroy channel-related rows as follows: o When the number of bearer channels for a DSL line changes to a higher number, the SNMP agent will automatically create rows in the xdsl2ChannelStatusTable and xdsl2PMChCurrTable tables for that line. o When the number of bearer channels for a DSL line changes to a lower number, the SNMP agent will automatically destroy rows in the xdsl2ChannelStatusTable, xdsl2PMChCurrTable,xdsl2PMChHist15MinTable, and xdsl2PMChHist1DTable tables for that line. 2.9. Notifications The ability to generate the SNMP notifications coldStart/WarmStart (per [RFC3418]), which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/ linkDown (per [RFC2863]), which are per interface (i.e., VDSL2/ADSL/ ADSL2 or ADSL2+ line) is required. A linkDown notification MAY be generated whenever any of ES, SES, CRC anomaly, LOS, LOF, or UAS events occur. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The notifications defined in this MIB module are for status change (e.g., initialization failure) and for the threshold crossings associated with the following events: full initialization failures, short initialization failures, ES, SES, LOS seconds, UAS, FEC seconds, FEC events, and CRC anomalies. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. The xdsl2LineStatusXtur and xdsl2LineStatusXtuc are bitmasks representing all outstanding error conditions associated with the xTU-R and xTU-C (respectively). Note that since the xTU-R status is obtained via the EOC, this information may be unavailable in case the xTU-R is unreachable via EOC during a line error condition. Therefore, not all conditions may always be included in its current status. Notifications corresponding to the bit fields in those two status objects are defined. Morgenstern, et al. Standards Track [Page 23] RFC 5650 VDSL2-LINE MIB September 2009 Note that there are other status parameters that refer to the xTU-R (e.g., downstream line attenuation). Those parameters also depend on the availability of EOC between the central office xTU and the remote xTU. A threshold notification occurs whenever the corresponding current 15-minute interval error counter becomes equal to, or exceeds the threshold value. Only one notification SHOULD be sent per interval per interface. Since the current 15-minute counter is reset to 0 every 15 minutes, and if the condition persists, the notification may recur as often as every 15 minutes. For example, to get a notification whenever a "loss of" event occurs (but at most once every 15 minutes), set the corresponding threshold to 1. The agent will generate a notification when the event originally occurs. Note that the Network Management System, or NMS, may receive a linkDown notification, as well, if enabled (via ifLinkUpDownTrapEnable [RFC2863]). At the beginning of the next 15- minute interval, the counter is reset. When the first second goes by and the event occurs, the current interval bucket will be 1, which equals the threshold, and the notification will be sent again. 3. Definitions VDSL2-LINE-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; vdsl2TCMIB MODULE-IDENTITY LAST-UPDATED "200909300000Z" -- September 30, 2009 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair: Menachem Dodge Morgenstern, et al. Standards Track [Page 24] RFC 5650 VDSL2-LINE MIB September 2009 ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION "This MIB Module provides Textual Conventions to be used by the VDSL2-LINE-MIB module for the purpose of managing VDSL2, ADSL, ADSL2, and ADSL2+ lines. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Morgenstern, et al. Standards Track [Page 25] RFC 5650 VDSL2-LINE MIB September 2009 - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5650; see the RFC itself for full legal notices." REVISION "200909300000Z" -- September 30, 2009 DESCRIPTION "Initial version, published as RFC 5650." ::= { transmission 251 3} -- vdsl2MIB 3 ------------------------------------------------ -- Textual Conventions -- ------------------------------------------------ Xdsl2Unit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a transceiver as being either xTU-C or xTU-R. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers: an xTU-C and an xTU-R. In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are also called atuc and atur. In the case of VDSL2, those two transceivers are also called vtuc and vtur. Morgenstern, et al. Standards Track [Page 26] RFC 5650 VDSL2-LINE MIB September 2009 Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver" SYNTAX INTEGER { xtuc(1), xtur(2) } Xdsl2Direction ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the direction of a band in a VDSL2/ADSL/ADSL2/ ADSL2+ link. The upstream direction is a transmission from the remote end (xTU-R) towards the central office end (xTU-C). The downstream direction is a transmission from the xTU-C towards the xTU-R. Specified as an INTEGER, the values are defined as follows:" SYNTAX INTEGER { upstream(1), -- Transmission from the xTU-R to the xTU-C. downstream(2) -- Transmission from the xTU-C to the xTU-R. } Xdsl2Band ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a band in a VDSL2/ADSL/ADSL2/ADSL2+ link. For a band in the upstream direction, transmission is from the remote end (xTU-R) towards the central office end (xTU-C). For a band in the downstream direction, transmission is from the xTU-C towards the xTU-R. For ADSL, ADSL2 and ADSL2+, which use a single band in the upstream direction and a single band in the downstream direction, the only relevant values are upstream(1) and downstream(2). For VDSL2, which uses multiple bands in each transmission direction, a band in the upstream direction is indicated by any of us0(3), us1(5), us2(7), us3(9), or us4(11), and a band in the downstream direction is indicated by any of ds1(4), ds2(6), ds3(8), or ds4(10). For VDSL2, the values upstream(1) and downstream(2) may be used when there is a need to refer to the whole upstream or downstream traffic (e.g., report the average signal-to-noise ratio on any transmission direction). Specified as an INTEGER, the values are defined as follows:" SYNTAX INTEGER { upstream(1), -- Transmission from the xTU-R to the xTU-C Morgenstern, et al. Standards Track [Page 27] RFC 5650 VDSL2-LINE MIB September 2009 -- (refers to the single upstream band for -- ADSL/ADSL2/ADSL2+ or to the whole -- upstream traffic for VDSL2). downstream(2), -- Transmission from the xTU-C to the xTU-R -- (refers to the single downstream band -- for ADSL/ADSL2/ADSL2+ or to the whole -- downstream traffic for VDSL2). us0(3), -- Upstream band number 0 (US0) (VDSL2). ds1(4), -- Downstream band number 1 (DS1) (VDSL2). us1(5), -- Upstream band number 1 (US1) (VDSL2). ds2(6), -- Downstream band number 2 (DS2) (VDSL2). us2(7), -- Upstream band number 2 (US2) (VDSL2). ds3(8), -- Downstream band number 3 (DS3) (VDSL2). us3(9), -- Upstream band number 3 (US3) (VDSL2). ds4(10), -- Downstream band number 4 (DS4) (VDSL2). us4(11) -- Upstream band number 4 (US4) (VDSL2). } Xdsl2TransmissionModeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of xDSL line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) --- not in G.997.1 Bit 13-17: Reserved Bit 18 : G.992.3 POTS non-overlapped (F) Bit 19 : G.992.3 POTS overlapped (F) Bit 20 : G.992.3 ISDN non-overlapped (F) Bit 21 : G.992.3 ISDN overlapped (F) Bit 22-23: Reserved Bit 24 : G.992.4 POTS non-overlapped (L) Bit 25 : G.992.4 POTS overlapped (L) Bit 26-27: Reserved Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F) Bit 29 : G.992.3 Annex I All-Digital overlapped (F) Morgenstern, et al. Standards Track [Page 28] RFC 5650 VDSL2-LINE MIB September 2009 Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F) Bit 31 : G.992.3 Annex J All-Digital overlapped (F) Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L) Bit 33 : G.992.4 Annex I All-Digital overlapped (L) Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) Bit 36 : G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) Bit 37 : G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) Bit 38 : G.992.3 Annex M POTS non-overlapped (F) Bit 39 : G.992.3 Annex M POTS overlapped (F) Bit 40 : G.992.5 POTS non-overlapped (F) Bit 41 : G.992.5 POTS overlapped (F) Bit 42 : G.992.5 ISDN non-overlapped (F) Bit 43 : G.992.5 ISDN overlapped (F) Bit 44-45: Reserved Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F) Bit 47 : G.992.5 Annex I All-Digital overlapped (F) Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F) Bit 49 : G.992.5 Annex J All-Digital overlapped (F) Bit 50 : G.992.5 Annex M POTS non-overlapped (F) Bit 51 : G.992.5 Annex M POTS overlapped (F) Bit 52-55: Reserved Bit 56 : G.993.2 Annex A Bit 57 : G.993.2 Annex B Bit 58 : G.993.2 Annex C Bit 59-63: Reserved" SYNTAX BITS { ansit1413(0), etsi(1), g9921PotsNonOverlapped(2), g9921PotsOverlapped(3), g9921IsdnNonOverlapped(4), g9921isdnOverlapped(5), g9921tcmIsdnNonOverlapped(6), g9921tcmIsdnOverlapped(7), g9922potsNonOverlapped(8), g9922potsOverlapped(9), g9922tcmIsdnNonOverlapped(10), g9922tcmIsdnOverlapped(11), g9921tcmIsdnSymmetric(12), reserved1(13), reserved2(14), reserved3(15), Morgenstern, et al. Standards Track [Page 29] RFC 5650 VDSL2-LINE MIB September 2009 reserved4(16), reserved5(17), g9923PotsNonOverlapped(18), g9923PotsOverlapped(19), g9923IsdnNonOverlapped(20), g9923isdnOverlapped(21), reserved6(22), reserved7(23), g9924potsNonOverlapped(24), g9924potsOverlapped(25), reserved8(26), reserved9(27), g9923AnnexIAllDigNonOverlapped(28), g9923AnnexIAllDigOverlapped(29), g9923AnnexJAllDigNonOverlapped(30), g9923AnnexJAllDigOverlapped(31), g9924AnnexIAllDigNonOverlapped(32), g9924AnnexIAllDigOverlapped(33), g9923AnnexLMode1NonOverlapped(34), g9923AnnexLMode2NonOverlapped(35), g9923AnnexLMode3Overlapped(36), g9923AnnexLMode4Overlapped(37), g9923AnnexMPotsNonOverlapped(38), g9923AnnexMPotsOverlapped(39), g9925PotsNonOverlapped(40), g9925PotsOverlapped(41), g9925IsdnNonOverlapped(42), g9925isdnOverlapped(43), reserved10(44), reserved11(45), g9925AnnexIAllDigNonOverlapped(46), g9925AnnexIAllDigOverlapped(47), g9925AnnexJAllDigNonOverlapped(48), g9925AnnexJAllDigOverlapped(49), g9925AnnexMPotsNonOverlapped(50), g9925AnnexMPotsOverlapped(51), reserved12(52), reserved13(53), reserved14(54), reserved15(55), g9932AnnexA(56), g9932AnnexB(57), g9932AnnexC(58), reserved16(59), reserved17(60), reserved18(61), reserved19(62), reserved20(63) Morgenstern, et al. Standards Track [Page 30] RFC 5650 VDSL2-LINE MIB September 2009 } Xdsl2RaMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the rate adaptation behavior for the line. The three possible behaviors are: manual (1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit (2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values. dynamicRa (3)- Dynamic Rate-Adaptation during initialization process as well as during Showtime." SYNTAX INTEGER { manual(1), raInit(2), dynamicRa(3) } Xdsl2InitResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the result of full initialization attempt; the six possible result values are: noFail (0) - Successful initialization configError (1) - Configuration failure configNotFeasible (2) - Configuration details not supported commFail (3) - Communication failure noPeerAtu (4) - Peer ATU not detected otherCause (5) - Other initialization failure reason" SYNTAX INTEGER { noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), otherCause(5) } Xdsl2OperationModes ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The VDSL2 management model specified includes an xDSL Mode object that identifies an instance of xDSL Mode-Specific PSD Configuration object in the xDSL Line Profile. The Morgenstern, et al. Standards Track [Page 31] RFC 5650 VDSL2-LINE MIB September 2009 following classes of xDSL operating mode are defined. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: +-------+--------------------------------------------------+ | Value | xDSL operation mode description | +-------+--------------------------------------------------+ 1 - The default/generic PSD configuration. Default configuration will be used when no other matching mode-specific configuration can be found. 2 - Regional Std. (ANSI T1.413) (F) 3 - Regional Std. (ETSI DTS/TM06006) (F) 4 - G.992.1 POTS non-overlapped (F) 5 - G.992.1 POTS overlapped (F) 6 - G.992.1 ISDN non-overlapped (F) 7 - G.992.1 ISDN overlapped (F) 8 - G.992.1 TCM-ISDN non-overlapped (F) 9 - G.992.1 TCM-ISDN overlapped (F) 10 - G.992.2 POTS non-overlapped (L) 11 - G.992.2 POTS overlapped (L) 12 - G.992.2 with TCM-ISDN non-overlapped (L) 13 - G.992.2 with TCM-ISDN overlapped (L) 14 - G.992.1 TCM-ISDN symmetric (F) --- not in G.997.1 15-19 - Unused. Reserved for future ITU-T specification. 20 - G.992.3 POTS non-overlapped (F) 21 - G.992.3 POTS overlapped (F) 22 - G.992.3 ISDN non-overlapped (F) 23 - G.992.3 ISDN overlapped (F) 24-25 - Unused. Reserved for future ITU-T specification. 26 - G.992.4 POTS non-overlapped (L) 27 - G.992.4 POTS overlapped (L) 28-29 - Unused. Reserved for future ITU-T specification. 30 - G.992.3 Annex I All-Digital non-overlapped (F) 31 - G.992.3 Annex I All-Digital overlapped (F) 32 - G.992.3 Annex J All-Digital non-overlapped (F) 33 - G.992.3 Annex J All-Digital overlapped (F) 34 - G.992.4 Annex I All-Digital non-overlapped (L) 35 - G.992.4 Annex I All-Digital overlapped (L) 36 - G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) 37 - G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) 38 - G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) 39 - G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) 40 - G.992.3 Annex M POTS non-overlapped (F) 41 - G.992.3 Annex M POTS overlapped (F) 42 - G.992.5 POTS non-overlapped (F) Morgenstern, et al. Standards Track [Page 32] RFC 5650 VDSL2-LINE MIB September 2009 43 - G.992.5 POTS overlapped (F) 44 - G.992.5 ISDN non-overlapped (F) 45 - G.992.5 ISDN overlapped (F) 46-47 - Unused. Reserved for future ITU-T specification. 48 - G.992.5 Annex I All-Digital non-overlapped (F) 49 - G.992.5 Annex I All-Digital overlapped (F) 50 - G.992.5 Annex J All-Digital non-overlapped (F) 51 - G.992.5 Annex J All-Digital overlapped (F) 52 - G.992.5 Annex M POTS non-overlapped (F) 53 - G.992.5 Annex M POTS overlapped (F) 54-57 - Unused. Reserved for future ITU-T specification. 58 - G.993.2 Annex A 59 - G.993.2 Annex B 60 - G.993.2 Annex C " SYNTAX INTEGER { defMode(1), ansit1413(2), etsi(3), g9921PotsNonOverlapped(4), g9921PotsOverlapped(5), g9921IsdnNonOverlapped(6), g9921isdnOverlapped(7), g9921tcmIsdnNonOverlapped(8), g9921tcmIsdnOverlapped(9), g9922potsNonOverlapped(10), g9922potsOverlapped(11), g9922tcmIsdnNonOverlapped(12), g9922tcmIsdnOverlapped(13), g9921tcmIsdnSymmetric(14), g9923PotsNonOverlapped(20), g9923PotsOverlapped(21), g9923IsdnNonOverlapped(22), g9923isdnOverlapped(23), g9924potsNonOverlapped(26), g9924potsOverlapped(27), g9923AnnexIAllDigNonOverlapped(30), g9923AnnexIAllDigOverlapped(31), g9923AnnexJAllDigNonOverlapped(32), g9923AnnexJAllDigOverlapped(33), g9924AnnexIAllDigNonOverlapped(34), g9924AnnexIAllDigOverlapped(35), g9923AnnexLMode1NonOverlapped(36), g9923AnnexLMode2NonOverlapped(37), g9923AnnexLMode3Overlapped(38), g9923AnnexLMode4Overlapped(39), g9923AnnexMPotsNonOverlapped(40), g9923AnnexMPotsOverlapped(41), Morgenstern, et al. Standards Track [Page 33] RFC 5650 VDSL2-LINE MIB September 2009 g9925PotsNonOverlapped(42), g9925PotsOverlapped(43), g9925IsdnNonOverlapped(44), g9925isdnOverlapped(45), g9925AnnexIAllDigNonOverlapped(48), g9925AnnexIAllDigOverlapped(49), g9925AnnexJAllDigNonOverlapped(50), g9925AnnexJAllDigOverlapped(51), g9925AnnexMPotsNonOverlapped(52), g9925AnnexMPotsOverlapped(53), g9932AnnexA(58), g9932AnnexB(59), g9932AnnexC(60) } Xdsl2PowerMngState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax uniquely identify each power management state defined for the VDSL2/ADSL/ADSL2 or ADSL2+ link. In VDSL2, only L0 and L3 states are defined. The possible values are: l0(1) - L0: Full power. Synchronized and full transmission (i.e., Showtime). l1(2) - L1: Low power with reduced net data rate (for G.992.2 only). l2(3) - L2: Low power with reduced net data rate (for G.992.3, G.992.4 and G.992.5). l3(4) - L3: Idle power management state / No power." SYNTAX INTEGER { l0(1), l1(2), l2(3), l3(4) } Xdsl2ConfPmsForce ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are configuration parameters that specify the desired power management state transition for the VDSL2/ADSL/ADSL2 or ADSL2+ link. In VDSL2, only L0 and L3 states are defined: l3toL0 (0) - Perform a transition from L3 to L0 (Full power management state). Morgenstern, et al. Standards Track [Page 34] RFC 5650 VDSL2-LINE MIB September 2009 l0toL2 (2) - Perform a transition from L0 to L2 (Low power management state). l0orL2toL3 (3) - Perform a transition into L3 (Idle power management state)." SYNTAX INTEGER { l3toL0 (0), l0toL2 (2), l0orL2toL3 (3) } Xdsl2LinePmMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are configuration parameters that reference the power modes/states into which the xTU-C or xTU-R may autonomously transit. It is a BITS structure that allows control of the following transit options: allowTransitionsToIdle (0) - xTU may autonomously transit to idle (L3) state. allowTransitionsToLowPower (1)- xTU may autonomously transit to low-power (L1/L2) state." SYNTAX BITS { allowTransitionsToIdle(0), allowTransitionsToLowPower(1) } Xdsl2LineLdsf ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are configuration parameters that control the Loop Diagnostic mode for a VDSL2/ADSL/ADSL2 or ADSL2+ link. The possible values are: inhibit (0) - Inhibit Loop Diagnostic mode force (1) - Force/Initiate Loop Diagnostic mode" SYNTAX INTEGER { inhibit(0), force(1) } Xdsl2LdsfResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 35] RFC 5650 VDSL2-LINE MIB September 2009 "Possible failure reasons associated with performing Dual Ended Loop Test (DELT) on a DSL line. Possible values are: none (1) - The default value in case LDSF was never requested for the associated line. success (2) - The recent command completed successfully. inProgress (3) - The Loop Diagnostics process is in progress. unsupported (4) - The NE or the line card doesn't support LDSF. cannotRun (5) - The NE cannot initiate the command, due to a nonspecific reason. aborted (6) - The Loop Diagnostics process aborted. failed (7) - The Loop Diagnostics process failed. illegalMode (8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp (9) - The NE cannot initiate the command, as the relevant line is administratively 'Up'. tableFull (10)- The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources (11)- The NE cannot initiate the command, due to lack of internal memory resources." SYNTAX INTEGER { none (1), success (2), inProgress (3), unsupported (4), cannotRun (5), aborted (6), failed (7), illegalMode (8), adminUp (9), tableFull (10), noResources (11) } Xdsl2LineBpsc ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are configuration parameters that control the bits per subcarrier measurement for a VDSL2/ADSL/ADSL2 or ADSL2+ link. The possible values are: idle (1) - Idle state measure (2) - Measure the bits per subcarrier" Morgenstern, et al. Standards Track [Page 36] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX INTEGER { idle(1), measure(2) } Xdsl2BpscResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Possible failure reasons associated with performing a bits per subcarrier measurement on a DSL line. Possible values are: none (1) - The default value, in case a measurement was never requested for the associated line. success (2) - The recent measurement request completed successfully. inProgress (3) - The bits per subcarrier measurement is in progress. unsupported (4) - The bits per subcarrier request mechanism is not supported. failed (5) - The measurement request has failed and no results are available. noResources (6) - The NE cannot initiate the command, due to lack of internal memory resources." SYNTAX INTEGER { none(1), success(2), inProgress(3), unsupported(4), failed(5), noResources(6) } Xdsl2LineReset ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to request a line reset to occur. idle (1) - This state indicates that there is currently no request for a line reset. reset (2) - This state indicates that a line reset request has been issued." SYNTAX INTEGER { idle(1), reset(2) } Xdsl2LineProfiles ::= TEXTUAL-CONVENTION Morgenstern, et al. Standards Track [Page 37] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "Objects with this syntax reference the list of ITU-T G.993.2 implementation profiles supported by an xTU, enabled on the VDSL2 line or active on that line." SYNTAX BITS { profile8a(0), profile8b(1), profile8c(2), profile8d(3), profile12a(4), profile12b(5), profile17a(6), profile30a(7) } Xdsl2LineClassMask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "VDSL2 PSD Mask Class. The limit Power Spectral Density masks are grouped in the following PSD mask classes: Class 998 Annex A: D-32, D-48, D-64, D-128. Class 997-M1c Annex B: 997-M1c-A-7. Class 997-M1x Annex B: 997-M1x-M-8, 997-M1x-M. Class 997-M2x Annex B: 997-M2x-M-8, 997-M2x-A, 997-M2x-M, 997E17-M2x-NUS0, 997E30-M2x-NUS0. Class 998-M1x Annex B: 998-M1x-A, 998-M1x-B, 998-M1x-NUS0. Class 998-M2x Annex B: 998-M2x-A, 998-M2x-M, 998-M2x-B, 998-M2x-NUS0, 998E17-M2x-NUS0, 998E17-M2x-NUS0-M, 998E30-M2x-NUS0, 998E30-M2x-NUS0-M. Class 998ADE-M2x Annex B: Annex B: 998-M2x-A, 998-M2x-M, 998-M2x-B, 998-M2x-NUS0, 998ADE17-M2x-A, 998ADE17-M2x-B, 998ADE17-M2x-NUS0-M, 998ADE30-M2x-NUS0-A, 998ADE30-M2x-NUS0-M. Class 998-B Annex C: POTS-138b, POTS-276b per C.2.1.1 in G.993.2, TCM-ISDN per C.2.1.2 in G.993.2. Class 998-CO Annex C: POTS-138co, POTS-276co per C.2.1.1 in G.993.2. Class HPE-M1 Annex B: HPE17-M1-NUS0, HPE30-M1-NUS0." SYNTAX INTEGER { Morgenstern, et al. Standards Track [Page 38] RFC 5650 VDSL2-LINE MIB September 2009 none(1), a998ORb997M1cORc998B(2), b997M1xOR998co(3), b997M2x(4), b998M1x(5), b998M2x(6), b998AdeM2x(7), bHpeM1(8) } Xdsl2LineLimitMask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The G.993.2 limit PSD mask for each class of profile. The profiles are grouped in following profile classes: - Class 8: Profiles 8a, 8b, 8c, 8d. - Class 12: Profiles 12a, 12b. - Class 17: Profile 17a. - Class 30: Profile 30a." SYNTAX BITS { profile8Limit1(0), profile8Limit2(1), profile8Limit3(2), profile8Limit4(3), profile8Limit5(4), profile8Limit6(5), profile8Limit7(6), profile8Limit8(7), profile8Limit9(8), profile8Limit10(9), profile8Limit11(10), profile8Limit12(11), profile8Limit13(12), profile8Limit14(13), profile8Limit15(14), profile8Limit16(15), -- profile12Limit1(16), profile12Limit2(17), profile12Limit3(18), profile12Limit4(19), profile12Limit5(20), profile12Limit6(21), profile12Limit7(22), profile12Limit8(23), profile12Limit9(24), profile12Limit10(25), Morgenstern, et al. Standards Track [Page 39] RFC 5650 VDSL2-LINE MIB September 2009 profile12Limit11(26), profile12Limit12(27), profile12Limit13(28), profile12Limit14(29), profile12Limit15(30), profile12Limit16(31), -- profile17Limit1(32), profile17Limit2(33), profile17Limit3(34), profile17Limit4(35), profile17Limit5(36), profile17Limit6(37), profile17Limit7(38), profile17Limit8(39), profile17Limit9(40), profile17Limit10(41), profile17Limit11(42), profile17Limit12(43), profile17Limit13(44), profile17Limit14(45), profile17Limit15(46), profile17Limit16(47), -- profile30Limit1(48), profile30Limit2(49), profile30Limit3(50), profile30Limit4(51), profile30Limit5(52), profile30Limit6(53), profile30Limit7(54), profile30Limit8(55), profile30Limit9(56), profile30Limit10(57), profile30Limit11(58), profile30Limit12(59), profile30Limit13(60), profile30Limit14(61), profile30Limit15(62), profile30Limit16(63) } Xdsl2LineUs0Disable ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates if US0 is disabled for each limit PSD mask. The profiles are grouped in following profile classes: - Class 8: Profiles 8a, 8b, 8c, 8d. Morgenstern, et al. Standards Track [Page 40] RFC 5650 VDSL2-LINE MIB September 2009 - Class 12: Profiles 12a, 12b. - Class 17: Profile 17a. - Class 30: Profile 30a." SYNTAX BITS { profile8Us0Disable1(0), profile8Us0Disable2(1), profile8Us0Disable3(2), profile8Us0Disable4(3), profile8Us0Disable5(4), profile8Us0Disable6(5), profile8Us0Disable7(6), profile8Us0Disable8(7), profile8Us0Disable9(8), profile8Us0Disable10(9), profile8Us0Disable11(10), profile8Us0Disable12(11), profile8Us0Disable13(12), profile8Us0Disable14(13), profile8Us0Disable15(14), profile8Us0Disable16(15), -- profile12Us0Disable1(16), profile12Us0Disable2(17), profile12Us0Disable3(18), profile12Us0Disable4(19), profile12Us0Disable5(20), profile12Us0Disable6(21), profile12Us0Disable7(22), profile12Us0Disable8(23), profile12Us0Disable9(24), profile12Us0Disable10(25), profile12Us0Disable11(26), profile12Us0Disable12(27), profile12Us0Disable13(28), profile12Us0Disable14(29), profile12Us0Disable15(30), profile12Us0Disable16(31), -- profile17Us0Disable1(32), profile17Us0Disable2(33), profile17Us0Disable3(34), profile17Us0Disable4(35), profile17Us0Disable5(36), profile17Us0Disable6(37), profile17Us0Disable7(38), profile17Us0Disable8(39), profile17Us0Disable9(40), Morgenstern, et al. Standards Track [Page 41] RFC 5650 VDSL2-LINE MIB September 2009 profile17Us0Disable10(41), profile17Us0Disable11(42), profile17Us0Disable12(43), profile17Us0Disable13(44), profile17Us0Disable14(45), profile17Us0Disable15(46), profile17Us0Disable16(47), -- profile30Us0Disable1(48), profile30Us0Disable2(49), profile30Us0Disable3(50), profile30Us0Disable4(51), profile30Us0Disable5(52), profile30Us0Disable6(53), profile30Us0Disable7(54), profile30Us0Disable8(55), profile30Us0Disable9(56), profile30Us0Disable10(57), profile30Us0Disable11(58), profile30Us0Disable12(59), profile30Us0Disable13(60), profile30Us0Disable14(61), profile30Us0Disable15(62), profile30Us0Disable16(63) } Xdsl2LineUs0Mask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The US0 PSD masks to be allowed by the near-end xTU on the line. This parameter is only defined for G.993.2 Annex A. It is represented as a bitmap (0 if not allowed and 1 if allowed) with the following definitions." SYNTAX BITS { eu32(0), eu36(1), eu40(2), eu44(3), eu48(4), eu52(5), eu56(6), eu60(7), -- eu64(8), eu128(9), reserved1(10), reserved2(11), Morgenstern, et al. Standards Track [Page 42] RFC 5650 VDSL2-LINE MIB September 2009 reserved3(12), reserved4(13), reserved5(14), reserved6(15), -- adlu32(16), adlu36(17), adlu40(18), adlu44(19), adlu48(20), adlu52(21), adlu56(22), adlu60(23), -- adlu64(24), adlu128(25), reserved7(26), reserved8(27), reserved9(28), reserved10(29), reserved11(30), reserved12(31) } Xdsl2SymbolProtection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 4.3125 kHz. The possible values are: 'noProtection' (i.e., INP not required), 'halfSymbol' (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol." SYNTAX INTEGER { noProtection (1), halfSymbol (2), singleSymbol (3), twoSymbols (4), threeSymbols (5), fourSymbols (6), fiveSymbols (7), sixSymbols (8), sevenSymbols (9), eightSymbols (10), nineSymbols (11), tenSymbols (12), Morgenstern, et al. Standards Track [Page 43] RFC 5650 VDSL2-LINE MIB September 2009 elevenSymbols (13), twelveSymbols (14), thirteeSymbols (15), fourteenSymbols (16), fifteenSymbols (17), sixteenSymbols (18) } Xdsl2SymbolProtection8 ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 8.625 kHz. The possible values are: 'noProtection' (i.e., INP not required) and 1-16 symbols in steps of 1 symbol." SYNTAX INTEGER { noProtection (1), singleSymbol (2), twoSymbols (3), threeSymbols (4), fourSymbols (5), fiveSymbols (6), sixSymbols (7), sevenSymbols (8), eightSymbols (9), nineSymbols (10), tenSymbols (11), elevenSymbols (12), twelveSymbols (13), thirteeSymbols (14), fourteenSymbols (15), fifteenSymbols (16), sixteenSymbols (17) } Xdsl2MaxBer ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER). The possible values are: eminus3 (1) - Maximum BER=E^-3 eminus5 (2) - Maximum BER=E^-5 eminus7 (3) - Maximum BER=E^-7" SYNTAX INTEGER { Morgenstern, et al. Standards Track [Page 44] RFC 5650 VDSL2-LINE MIB September 2009 eminus3(1), eminus5(2), eminus7(3) } Xdsl2ChInitPolicy ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This syntax serves for channel configuration parameters that reference the channel initialization policy. The possible values are: policy0 (1) - Policy 0 according to the applicable standard. policy1 (2) - Policy 1 according to the applicable standard." SYNTAX INTEGER { policy0(1), policy1(2) } Xdsl2ScMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 4096 bits in this OCTET STRING array represents the corresponding subcarrier in the downstream direction. A bit value of one indicates that a subcarrier is masked." SYNTAX OCTET STRING (SIZE(0..512)) Xdsl2ScMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 4096 bits in this OCTET STRING array represents the corresponding subcarrier in the upstream direction. A bit value of one indicates that a subcarrier is masked." SYNTAX OCTET STRING (SIZE(0..512)) Xdsl2CarMask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type defines an array of bands. Each band is represented by 4 octets and there is a maximum of 32 bands allowed. Each band consists of a 16-bit start subcarrier index followed by a 16-bit stop subcarrier index. The subcarrier index is an unsigned number in the range 0 to NSC-1." SYNTAX OCTET STRING (SIZE(0..128)) Morgenstern, et al. Standards Track [Page 45] RFC 5650 VDSL2-LINE MIB September 2009 Xdsl2RfiBands ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type defines a subset of downstream PSD mask breakpoints used to notch radio frequency interference (RFI) bands. Each RFI band is represented by 4 octets: a 16-bit start subcarrier index followed by a 16-bit stop subcarrier index. There is a maximum of 16 RFI bands allowed. The subcarrier index is an unsigned number in the range 0 to NSC-1." SYNTAX OCTET STRING (SIZE(0..64)) Xdsl2PsdMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 PSD mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the subcarrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz. The subcarrier index is an unsigned number in the range 0 to NSCds-1." SYNTAX OCTET STRING (SIZE(0..96)) Xdsl2PsdMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 16 PSD mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the subcarrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz. The subcarrier index is an unsigned number in the range 0 to NSCus-1." SYNTAX OCTET STRING (SIZE(0..48)) Xdsl2Tssi ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 transmit spectrum shaping (TSSi) breakpoints. Each breakpoint is a pair of values occupying 3 octets with the Morgenstern, et al. Standards Track [Page 46] RFC 5650 VDSL2-LINE MIB September 2009 following structure: First 2 octets - Index of the subcarrier used in the context of the breakpoint. Third octet - The shaping parameter at the breakpoint. The shaping parameter value is in the range 0 to 126 (units of -0.5 dB). The special value 127 indicates that the subcarrier is not transmitted. The subcarrier index is an unsigned number in the range 0 to NSC-1." SYNTAX OCTET STRING (SIZE(0..96)) Xdsl2LastTransmittedState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This parameter represents the last successful transmitted initialization state in the last full initialization performed on the line. States are per the specific xDSL technology and are numbered from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used) up to Showtime." SYNTAX INTEGER { -- ADSL family ATU-C side -- atucG9941(0), atucQuiet1(1), atucComb1(2), atucQuiet2(3), atucComb2(4), atucIcomb1(5), atucLineprob(6), atucQuiet3(7), atucComb3(8), atucIComb2(9), atucMsgfmt(10), atucMsgpcb(11), atucQuiet4(12), atucReverb1(13), atucTref1(14), atucReverb2(15), atucEct(16), atucReverb3(17), atucTref2(18), atucReverb4(19), atucSegue1(20), atucMsg1(21), atucReverb5(22), atucSegue2(23), atucMedley(24), atucExchmarker(25), atucMsg2(26), Morgenstern, et al. Standards Track [Page 47] RFC 5650 VDSL2-LINE MIB September 2009 atucReverb6(27), atucSegue3(28), atucParams(29), atucReverb7(30), atucSegue4(31), atucShowtime(32), -- ADSL family ATU-R side -- aturG9941(100), aturQuiet1(101), aturComb1(102), aturQuiet2(103), aturComb2(104), aturIcomb1(105), aturLineprob(106), aturQuiet3(107), aturComb3(108), aturIcomb2(109), aturMsgfmt(110), aturMsgpcb(111), aturReverb1(112), aturQuiet4(113), aturReverb2(114), aturQuiet5(115), aturReverb3(116), aturEct(117), aturReverb4(118), aturSegue1(119), aturReverb5(120), aturSegue2(121), aturMsg1(122), aturMedley(123), aturExchmarker(124), aturMsg2(125), aturReverb6(126), aturSegue3(127), aturParams(128), aturReverb7(129), aturSegue4(130), aturShowtime(131), -- VDSL2 VTU-C side -- vtucG9941(200), vtucQuiet1(201), vtucChDiscov1(202), vtucSynchro1(203), vtucPilot1(204), vtucQuiet2(205), vtucPeriodic1(206), vtucSynchro2(207), Morgenstern, et al. Standards Track [Page 48] RFC 5650 VDSL2-LINE MIB September 2009 vtucChDiscov2(208), vtucSynchro3(209), vtucTraining1(210), vtucSynchro4(211), vtucPilot2(212), vtucTeq(213), vtucEct(214), vtucPilot3(215), vtucPeriodic2(216), vtucTraining2(217), vtucSynchro5(218), vtucMedley(219), vtucSynchro6(220), vtucShowtime(221), -- VDSL2 VTU-R side -- vturG9941(300), vturQuiet1(301), vturChDiscov1(302), vturSynchro1(303), vturLineprobe(304), vturPeriodic1(305), vturSynchro2(306), vturChDiscov2(307), vturSynchro3(308), vturQuiet2(309), vturTraining1(310), vturSynchro4(311), vturTeq(312), vturQuiet3(313), vturEct(314), vturPeriodic2(315), vturTraining2(316), vturSynchro5(317), vturMedley(318), vturSynchro6(319), vturShowtime(320) } Xdsl2LineStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are status parameters that reflect the failure status for a given endpoint of a VDSL2/ADSL/ADSL2 or ADSL2+ link. This BITS structure can report the following failures: noDefect (0) - This bit position positively reports Morgenstern, et al. Standards Track [Page 49] RFC 5650 VDSL2-LINE MIB September 2009 that no defect or failure exist. lossOfFraming (1) - Loss of frame synchronization. lossOfSignal (2) - Loss of signal. lossOfPower (3) - Loss of power. Usually this failure may be reported for CPE units only. initFailure (4) - Recent initialization process failed. Never active on xTU-R." SYNTAX BITS { noDefect(0), lossOfFraming(1), lossOfSignal(2), lossOfPower(3), initFailure(4) } Xdsl2ChInpReport ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to indicate the method used to compute the Actual Impulse Noise Protection (ACTINP). If set to 'inpComputedUsingFormula', the ACTINP is computed according to the INP_no_erasure formula (9.6/G.993.2). If set to 'inpEstimatedByXtur', the ACTINP is the value estimated by the xTU receiver. inpComputedUsingFormula (1) - ACTINP computed using INP_no_erasure formula. inpEstimatedByXtur (2) - ACTINP estimated by the xTU receiver." SYNTAX INTEGER { inpComputedUsingFormula(1), inpEstimatedByXtur(2) } Xdsl2ChAtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are status parameters that reflect the failure status for the Transmission Convergence (TC) layer of a given ATM interface (data path over a VDSL2/ADSL/ ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect (0) - This bit position positively reports that no defect or failure exists. noCellDelineation (1) - The link was successfully initialized, but cell delineation was never acquired on the Morgenstern, et al. Standards Track [Page 50] RFC 5650 VDSL2-LINE MIB September 2009 associated ATM data path. lossOfCellDelineation (2)- Loss of cell delineation on the associated ATM data path." SYNTAX BITS { noDefect(0), noCellDelineation(1), lossOfCellDelineation(2) } Xdsl2ChPtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are status parameters that reflect the failure status for a given PTM interface (packet data path over a VDSL2/ADSL/ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect (0) - This bit position positively reports that no defect or failure exists. outOfSync (1) - Out of synchronization." SYNTAX BITS { noDefect(0), outOfSync(1) } Xdsl2UpboKLF ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Defines the upstream power backoff force mode (UPBOKLF). The three possible mode values are: auto(1) - The VDSL Transceiver Unit (VTUs) will autonomously determine the electrical length. override(2) - Forces the VTU-R to use the electrical length, kl0, of the CO-MIB (UPBOKL) to compute the UPBO. disableUpbo(3) - Disables UPBO such that UPBO is not utilized." SYNTAX INTEGER { auto(1), override(2), disableUpbo(3) } Xdsl2BandUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each value identifies a specific band in the upstream Morgenstern, et al. Standards Track [Page 51] RFC 5650 VDSL2-LINE MIB September 2009 transmission direction (excluding the US0 band.). The possible values that identify a band are as follows: us1(5) - Upstream band number 1 (US1). us2(7) - Upstream band number 2 (US2). us3(9) - Upstream band number 3 (US3). us4(11) - Upstream band number 4 (US4)." SYNTAX INTEGER { us1(5), us2(7), us3(9), us4(11) } Xdsl2LinePsdMaskSelectUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to define which upstream PSD mask is enabled. This type is used only for Annexes J and M of ITU-T Recommendations G.992.3 and G.992.5. adlu32Eu32 (1), - ADLU-32 / EU-32 adlu36Eu36 (2), - ADLU-36 / EU-36 adlu40Eu40 (3), - ADLU-40 / EU-40 adlu44Eu44 (4), - ADLU-44 / EU-44 adlu48Eu48 (5), - ADLU-48 / EU-48 adlu52Eu52 (6), - ADLU-52 / EU-52 adlu56Eu56 (7), - ADLU-56 / EU-56 adlu60Eu60 (8), - ADLU-60 / EU-60 adlu64Eu64 (9) - ADLU-64 / EU-64" SYNTAX INTEGER { adlu32Eu32(1), adlu36Eu36(2), adlu40Eu40(3), adlu44Eu44(4), adlu48Eu48(5), adlu52Eu52(6), adlu56Eu56(7), adlu60Eu60(8), adlu64Eu64(9) } Xdsl2LineCeFlag ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to enable the use of the optional cyclic extension values. If the bit is set to '1', the optional cyclic extension values may be used. Otherwise, the cyclic extension shall be forced to the mandatory length (5N/32). Morgenstern, et al. Standards Track [Page 52] RFC 5650 VDSL2-LINE MIB September 2009 enableCyclicExtension (0) - Enable use of optional Cyclic Extension values." SYNTAX BITS { enableCyclicExtension(0) } Xdsl2LineSnrMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type is used to enable the transmitter-referred virtual noise. The value of 1, indicates that virtual noise is disabled. The value of 2, indicates that virtual noise is enabled. virtualNoiseDisabled (1) - virtual noise is disabled. virtualNoiseEnabled (2) - virtual noise is enabled." SYNTAX INTEGER { virtualNoiseDisabled(1), virtualNoiseEnabled(2) } Xdsl2LineTxRefVnDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 PSD mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the subcarrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (-140 dBm/Hz) to 200 (-40 dBm/Hz) using units of 0.5 dBm/Hz. A special value of 255 indicates a noise level of 0 W/Hz. The subcarrier index is an unsigned number in the range 0 to NSCds-1." SYNTAX OCTET STRING (SIZE(0..96)) Xdsl2LineTxRefVnUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 16 PSD mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the subcarrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (-140 dBm/Hz) to 200 (-40 dBm/Hz) using units of 0.5 dBm/Hz. A special value of 255 indicates a noise level of 0 W/Hz. The subcarrier index is an unsigned number in the range 0 to NSCus-1." SYNTAX OCTET STRING (SIZE(0..48)) Morgenstern, et al. Standards Track [Page 53] RFC 5650 VDSL2-LINE MIB September 2009 Xdsl2BitsAlloc ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type specifies an array of nibbles, where each nibble indicates the bits allocation for a subcarrier. Each nibble has a value in the range 0 to 15 to indicate the bits allocation." SYNTAX OCTET STRING (SIZE(0..256)) Xdsl2MrefPsdDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are MEDLEY Reference PSD status parameters in the downstream direction. This is expressed as the set of breakpoints exchanged at initialization. The OCTET STRING contains up to 48 pairs of values in the following structure: Octets 0-1 -- Index of the first subcarrier used in the context of a first breakpoint. Octets 2-3 -- The PSD level for the subcarrier indicated in octets 0-1. Octets 4-7 -- Same, for a second breakpoint Octets 8-11 -- Same, for a third breakpoint And so on until Octets 188-191 -- Same, for a 48th breakpoint. The subcarrier index is an unsigned number in the range 0 to NSCds-1. The PSD level is an integer value in the 0 to 4095 range. It is represented in units of 0.1 dB offset from -140 dBm/Hz." SYNTAX OCTET STRING (SIZE(0..192)) Xdsl2MrefPsdUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Objects with this syntax are MEDLEY Reference PSD status parameters in the upstream direction. This is expressed as the set of breakpoints exchanged at initialization. The OCTET STRING contains up to 32 pairs of values in the following structure: Octets 0-1 -- Index of the first subcarrier used in the context of a first breakpoint. Octets 2-3 -- The PSD level for the subcarrier indicated in octets 0-1. Octets 4-7 -- Same, for a second breakpoint Octets 8-11 -- Same, for a third breakpoint And so on until Morgenstern, et al. Standards Track [Page 54] RFC 5650 VDSL2-LINE MIB September 2009 Octets 124-127 -- Same, for a 32nd breakpoint. The subcarrier index is an unsigned number in the range 0 to NSCus-1. The PSD level is an integer value in the 0 to 4095 range. It is represented in units of 0.1 dB offset from -140 dBm/Hz." SYNTAX OCTET STRING (SIZE(0..128)) END VDSL2-LINE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Unsigned32, NOTIFICATION-TYPE, Integer32, Counter32 FROM SNMPv2-SMI ifIndex FROM IF-MIB TruthValue, RowStatus FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB HCPerfIntervalThreshold, HCPerfTimeElapsed FROM HC-PerfHist-TC-MIB -- [RFC3705] Xdsl2Unit, Xdsl2Direction, Xdsl2Band, Xdsl2TransmissionModeType, Xdsl2RaMode, Xdsl2InitResult, Xdsl2OperationModes, Xdsl2PowerMngState, Xdsl2ConfPmsForce, Xdsl2LinePmMode, Xdsl2LineLdsf, Xdsl2LdsfResult, Xdsl2LineBpsc, Morgenstern, et al. Standards Track [Page 55] RFC 5650 VDSL2-LINE MIB September 2009 Xdsl2BpscResult, Xdsl2LineReset, Xdsl2SymbolProtection, Xdsl2SymbolProtection8, Xdsl2MaxBer, Xdsl2ChInitPolicy, Xdsl2ScMaskDs, Xdsl2ScMaskUs, Xdsl2CarMask, Xdsl2RfiBands, Xdsl2PsdMaskDs, Xdsl2PsdMaskUs, Xdsl2Tssi, Xdsl2LastTransmittedState, Xdsl2LineStatus, Xdsl2ChInpReport, Xdsl2ChAtmStatus, Xdsl2ChPtmStatus, Xdsl2UpboKLF, Xdsl2BandUs, Xdsl2LineProfiles, Xdsl2LineUs0Mask, Xdsl2LineClassMask, Xdsl2LineLimitMask, Xdsl2LineUs0Disable, Xdsl2LinePsdMaskSelectUs, Xdsl2LineCeFlag, Xdsl2LineSnrMode, Xdsl2LineTxRefVnDs, Xdsl2LineTxRefVnUs, Xdsl2BitsAlloc, Xdsl2MrefPsdDs, Xdsl2MrefPsdUs FROM VDSL2-LINE-TC-MIB -- [This document] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; vdsl2MIB MODULE-IDENTITY LAST-UPDATED "200909300000Z" -- September 30, 2009 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Morgenstern, et al. Standards Track [Page 56] RFC 5650 VDSL2-LINE MIB September 2009 Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION " This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing VDSL2, ADSL, ADSL2, and ADSL2+ lines. The MIB module described in RFC 2662 [RFC2662] defines objects used for managing Asymmetric Bit-Rate DSL (ADSL) Morgenstern, et al. Standards Track [Page 57] RFC 5650 VDSL2-LINE MIB September 2009 interfaces per [T1E1.413], [G.992.1], and [G.992.2]. These object descriptions are based upon the specifications for the ADSL Embedded Operations Channel (EOC) as defined in American National Standards Institute (ANSI) T1E1.413 [T1E1.413] and International Telecommunication Union (ITU-T) G.992.1 [G.992.1] and G.992.2 [G.992.2]. The MIB module described in RFC 4706 [RFC4706] defines objects used for managing ADSL2 interfaces per [G.992.3] and [G.992.4], and ADSL2+ interfaces per [G.992.5]. That MIB is also capable of managing ADSL interfaces per [T1E1.413], [G.992.1], and [G.992.2]. This document does not obsolete RFC 2662 [RFC2662] or RFC 4706 [RFC4706], but rather provides a more comprehensive management model that manages VDSL2 interfaces per G.993.2 [G.993.2] as well as ADSL, ADSL2, and ADSL2+ technologies per T1E1.413, G.992.1, G.992.2, G.992.3, G.992.4, and G.992.5 ([T1E1.413], [G.992.1], [G.992.2], [G.992.3], [G.992.4], and [G.992.5], respectively). Additionally, the management framework for VDSL2 lines specified by the Digital Subscriber Line Forum (DSLF) has been taken into consideration [TR-129]. That framework is based on the ITU-T G.997.1 standard [G.997.1] and its amendment 1 [G.997.1-Am1]. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of this document. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Morgenstern, et al. Standards Track [Page 58] RFC 5650 VDSL2-LINE MIB September 2009 - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5650; see the RFC itself for full legal notices." REVISION "200909300000Z" -- September 30, 2009 DESCRIPTION "Initial version, published as RFC 5650." ::= { transmission 251 } xdsl2Notifications OBJECT IDENTIFIER ::= { vdsl2MIB 0 } xdsl2Objects OBJECT IDENTIFIER ::= { vdsl2MIB 1 } xdsl2Conformance OBJECT IDENTIFIER ::= { vdsl2MIB 2 } ------------------------------------------------ xdsl2Line OBJECT IDENTIFIER ::= { xdsl2Objects 1 } xdsl2Status OBJECT IDENTIFIER ::= { xdsl2Objects 2 } xdsl2Inventory OBJECT IDENTIFIER ::= { xdsl2Objects 3 } xdsl2PM OBJECT IDENTIFIER ::= { xdsl2Objects 4 } xdsl2Profile OBJECT IDENTIFIER ::= { xdsl2Objects 5 } xdsl2Scalar OBJECT IDENTIFIER ::= { xdsl2Objects 6 } ------------------------------------------------ xdsl2PMLine OBJECT IDENTIFIER ::= { xdsl2PM 1 } xdsl2PMChannel OBJECT IDENTIFIER ::= { xdsl2PM 2 } ------------------------------------------------ xdsl2ProfileLine OBJECT IDENTIFIER ::= { xdsl2Profile 1 } xdsl2ProfileChannel OBJECT IDENTIFIER ::= { xdsl2Profile 2 } xdsl2ProfileAlarmConf OBJECT IDENTIFIER ::= { xdsl2Profile 3 } ------------------------------------------------ xdsl2ScalarSC OBJECT IDENTIFIER ::= { xdsl2Scalar 1 } ------------------------------------------------ ------------------------------------------------ Morgenstern, et al. Standards Track [Page 59] RFC 5650 VDSL2-LINE MIB September 2009 -- xdsl2LineTable -- ------------------------------------------------ xdsl2LineTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineTable contains configuration, command and status parameters of the VDSL2/ADSL/ADSL2 or ADSL2+ line. Several objects in this table MUST be maintained in a persistent manner." ::= { xdsl2Line 1 } xdsl2LineEntry OBJECT-TYPE SYNTAX Xdsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this table is an interface index where the interface has an ifType of vdsl2(251)." INDEX { ifIndex } ::= { xdsl2LineTable 1 } Xdsl2LineEntry ::= SEQUENCE { xdsl2LineConfTemplate SnmpAdminString, xdsl2LineConfFallbackTemplate SnmpAdminString, xdsl2LineAlarmConfTemplate SnmpAdminString, xdsl2LineCmndConfPmsf Xdsl2ConfPmsForce, xdsl2LineCmndConfLdsf Xdsl2LineLdsf, xdsl2LineCmndConfLdsfFailReason Xdsl2LdsfResult, xdsl2LineCmndConfBpsc Xdsl2LineBpsc, xdsl2LineCmndConfBpscFailReason Xdsl2BpscResult, xdsl2LineCmndConfBpscRequests Counter32, xdsl2LineCmndAutomodeColdStart TruthValue, xdsl2LineCmndConfReset Xdsl2LineReset, xdsl2LineStatusActTemplate SnmpAdminString, xdsl2LineStatusXtuTransSys Xdsl2TransmissionModeType, xdsl2LineStatusPwrMngState Xdsl2PowerMngState, xdsl2LineStatusInitResult Xdsl2InitResult, xdsl2LineStatusLastStateDs Xdsl2LastTransmittedState, xdsl2LineStatusLastStateUs Xdsl2LastTransmittedState, xdsl2LineStatusXtur Xdsl2LineStatus, xdsl2LineStatusXtuc Xdsl2LineStatus, xdsl2LineStatusAttainableRateDs Unsigned32, xdsl2LineStatusAttainableRateUs Unsigned32, Morgenstern, et al. Standards Track [Page 60] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LineStatusActPsdDs Integer32, xdsl2LineStatusActPsdUs Integer32, xdsl2LineStatusActAtpDs Integer32, xdsl2LineStatusActAtpUs Integer32, xdsl2LineStatusActProfile Xdsl2LineProfiles, xdsl2LineStatusActLimitMask Xdsl2LineLimitMask, xdsl2LineStatusActUs0Mask Xdsl2LineUs0Mask, xdsl2LineStatusActSnrModeDs Xdsl2LineSnrMode, xdsl2LineStatusActSnrModeUs Xdsl2LineSnrMode, xdsl2LineStatusElectricalLength Unsigned32, xdsl2LineStatusTssiDs Xdsl2Tssi, xdsl2LineStatusTssiUs Xdsl2Tssi, xdsl2LineStatusMrefPsdDs Xdsl2MrefPsdDs, xdsl2LineStatusMrefPsdUs Xdsl2MrefPsdUs, xdsl2LineStatusTrellisDs TruthValue, xdsl2LineStatusTrellisUs TruthValue, xdsl2LineStatusActualCe Unsigned32 } xdsl2LineConfTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the xDSL2 Line Configuration Template Table, xdsl2LineConfTemplateTable, that applies for this line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-129, paragraph #5.1" DEFVAL { "DEFVAL" } ::= { xdsl2LineEntry 1 } xdsl2LineConfFallbackTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to identify the template that will be used if the xDSL2 line fails to operate using the primary template. The primary template is identified using the xdsl2LineConfTemplate object. For example, a xDSL2 line may fall back to a template with a lower rate if the rate specified in the primary template cannot be achieved. The value of this object identifies a row in the xDSL2 Line Morgenstern, et al. Standards Track [Page 61] RFC 5650 VDSL2-LINE MIB September 2009 Configuration Template Table, xdsl2LineConfTemplateTable. Any row in the xdsl2LineConfTemplateTable table may be used as a fall-back template. If the xDSL2 line fails to operate using the fall-back template, then the primary template should be retried. The xTU-C should continue to alternate between the primary and fall-back templates until one of them succeeds. If the value of this object is a zero-length string, then no fall-back template is defined and only the primary template will be used. Note that implementation of this object is not mandatory. If this object is not supported, any attempt to modify this object should result in the SET request being rejected. This object MUST be maintained in a persistent manner." ::= { xdsl2LineEntry 2 } xdsl2LineAlarmConfTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the xDSL2 Line Alarm Configuration Template Table, xdsl2LineAlarmConfTemplateTable, which applies to this line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-129, paragraph #5.1" DEFVAL { "DEFVAL" } ::= { xdsl2LineEntry 3 } xdsl2LineCmndConfPmsf OBJECT-TYPE SYNTAX Xdsl2ConfPmsForce MAX-ACCESS read-write STATUS current DESCRIPTION "Power management state forced (PMSF). Defines the line states to be forced by the near-end xTU on this line. This object MUST be maintained in a persistent manner." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.3 (PMSF)" DEFVAL { l3toL0 } ::= { xdsl2LineEntry 4 } xdsl2LineCmndConfLdsf OBJECT-TYPE SYNTAX Xdsl2LineLdsf Morgenstern, et al. Standards Track [Page 62] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS read-write STATUS current DESCRIPTION "Loop diagnostic state forced (LDSF). Defines whether the line should be forced into the loop diagnostics mode by the near-end xTU of this line. Note that a loop diagnostic may be initiated by the far-end xTU at any time. Only when the xdsl2LineStatusPwrMngState object is in the 'l3' state and the xdsl2LineCmndConfPmsf object is in the 'l0orL2toL3' state, can the line be forced into loop diagnostic mode procedures. Upon successful completion of the loop diagnostic mode procedures, the Access Node shall set this object to 'inhibit', and xdsl2LineStatusPwrMngState will remain in the 'l3' state. The loop diagnostic data shall be available at least until xdsl2LineCmndConfPmsf is set to the 'l3toL0' state. The results of the loop diagnostic procedure are stored in the tables xdsl2SCStatusTable, xdsl2SCStatusBandTable, and xdsl2SCStatusSegmentTable. The status of the loop diagnostic procedure is indicated by xdsl2LineCmndConfLdsfFailReason. As long as loop diagnostic procedures are not completed successfully, attempts shall be made to do so, until the loop diagnostic mode is no longer forced on the line through this configuration parameter." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.8 (LDSF)" DEFVAL { inhibit } ::= { xdsl2LineEntry 5 } xdsl2LineCmndConfLdsfFailReason OBJECT-TYPE SYNTAX Xdsl2LdsfResult MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the most recent occasion when the loop diagnostics state forced (LDSF) command was issued for the associated line." DEFVAL { none } ::= { xdsl2LineEntry 6 } xdsl2LineCmndConfBpsc OBJECT-TYPE SYNTAX Xdsl2LineBpsc MAX-ACCESS read-write STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 63] RFC 5650 VDSL2-LINE MIB September 2009 "Request a bits-per-subcarrier measurement to be made. A request for a bits-per-subcarrier measurement is made by setting this object to the value of 'measure'. Upon completion of the measurement request, the Access Node shall set this object to 'idle'. The SNMP agent should allow initiating a bits-per-subcarrier measurement process only if there is no other bits-per-subcarrier measurement already running, and respond with an SNMP error (e.g., wrongValue) otherwise. Note that a bits-per-subcarrier measurement is also performed during a line diagnostic procedure. This object provides an additional mechanism to fetch the bits-per-subcarrier data. This additional mechanism is provided so that bits-per-subcarrier data may be fetched without forcing the line into no power state. This is useful because the bits-per-subcarrier allocation may be adjusted at show time due to rate adaption and bit swapping. The implementation of this additional mechanism for measuring bits per subcarrier is not mandatory. The results of the bits-per-subcarrier measurement are stored in xdsl2LineSegmentTable. The status of the bits-per-subcarrier measurement is indicated by xdsl2LineCmndConfBpscFailReason." DEFVAL { idle } ::= { xdsl2LineEntry 7 } xdsl2LineCmndConfBpscFailReason OBJECT-TYPE SYNTAX Xdsl2BpscResult MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the most recent bits-per-subcarrier measurement request issued for the associated line." DEFVAL { none } ::= { xdsl2LineEntry 8 } xdsl2LineCmndConfBpscRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Measurement request counter. This counter is incremented by one every time a request for a bits-per-subcarrier measurement is made. A measurement request Morgenstern, et al. Standards Track [Page 64] RFC 5650 VDSL2-LINE MIB September 2009 is made by modifying the xdsl2LineCmndConfBpsc object from idle(1) to the value measure(2). The measurement results may be very large and will not fit into a single PDU; hence, multiple SNMP GET requests may be required to fetch the measurement results. Because the measurement results cannot be fetched atomically, it is possible for a second manager to start a new measurement before a first manager has fetched all of its results. An SNMP manager can use this object to ensure that the measurement results retrieved using one or more GET requests all belong to the measurement initiated by that manager. The following steps are suggested in order for the SNMP manager to initiate the bits-per-subcarrier measurement: 1. Wait for xdsl2LineCmndConfBpsc value to be idle(1). 2. Perform an SNMP GET for xdsl2LineCmndConfBpscRequests. 3. Wait a short delay (4 -> 8 seconds). 4. Perform an SNMP SET on xdsl2LineCmndConfBpsc with the value measure(2). 5. If step 4 returns an error, then go to step 1. 6. Wait for xdsl2LineCmndConfBpsc value to be idle(1). 7. Fetch measurement results using one or more GET PDUs. 8. Perform an SNMP GET for xdsl2LineCmndConfBpscRequests. 9. Compute the difference between the two values of xdsl2LineCmndConfBpscRequests. If the value is one, then the results are valid, else go to step 1." ::= { xdsl2LineEntry 9 } xdsl2LineCmndAutomodeColdStart OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Automode cold start forced. This parameter is defined in order to improve testing of the performance of xTUs supporting automode when it is enabled in the MIB. Change the value of this parameter to 'true' to indicate a change in loop conditions applied to the devices under the test. The xTUs shall reset any historical information used for automode and for shortening G.994.1 handshake and initialization. Automode is the case where multiple operation-modes are enabled through the xdsl2LConfProfXtuTransSysEna object in the line configuration profile being used for the line, and where the selection of the actual operation-mode depends not only on the common capabilities of both xTUs (as exchanged in G.994.1), but Morgenstern, et al. Standards Track [Page 65] RFC 5650 VDSL2-LINE MIB September 2009 also on achievable data rates under given loop conditions." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.10 (Automode Cold Start Forced)" DEFVAL { false } ::= { xdsl2LineEntry 10 } xdsl2LineCmndConfReset OBJECT-TYPE SYNTAX Xdsl2LineReset MAX-ACCESS read-write STATUS current DESCRIPTION "Request a line reset to occur. If this object is set to the value of 'reset', then force the line to reset (i.e., the modems will retrain). When the line has successfully reset, the SNMP agent will set the value of this object to 'idle'. Note that the xdsl2LineCmndConfPmsf object will always take precedence over this object. If the xdsl2LineCmndConfPmsf object is set to the value 'l0orL2toL3', then the line MUST NOT return to the Showtime state due to a reset request action performed using this object." DEFVAL { idle } ::= { xdsl2LineEntry 11 } xdsl2LineStatusActTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to identify the template that is currently in use for this line. This object is updated when a successful line initialization occurs. This object indicates if the primary template (xdsl2LineConfTemplate) is in use or the fall-back template (xdsl2LineConfFallbackTemplate) is in use. If the line is not successfully initialized, then the value of this object will be a zero-length string." ::= { xdsl2LineEntry 12 } xdsl2LineStatusXtuTransSys OBJECT-TYPE SYNTAX Xdsl2TransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The xTU Transmission System (xTS) in use. Morgenstern, et al. Standards Track [Page 66] RFC 5650 VDSL2-LINE MIB September 2009 It is coded in a bitmap representation with one bit set to '1' (the selected coding for the DSL line). This parameter may be derived from the handshaking procedures defined in Recommendation G.994.1. A set of xDSL line transmission modes, with one bit per mode." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.1 (xDSL transmission system)" DEFVAL { {} } ::= { xdsl2LineEntry 13 } xdsl2LineStatusPwrMngState OBJECT-TYPE SYNTAX Xdsl2PowerMngState MAX-ACCESS read-only STATUS current DESCRIPTION "The current power management state." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.5 (Line power management state)" DEFVAL { l3 } ::= { xdsl2LineEntry 14 } xdsl2LineStatusInitResult OBJECT-TYPE SYNTAX Xdsl2InitResult MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the result of the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.6 (Initialization success/failure cause)" DEFVAL { noFail } ::= { xdsl2LineEntry 15 } xdsl2LineStatusLastStateDs OBJECT-TYPE SYNTAX Xdsl2LastTransmittedState MAX-ACCESS read-only STATUS current DESCRIPTION "The last successful transmitted initialization state in the downstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.7 (Downstream last transmitted state)" DEFVAL { atucG9941 } ::= { xdsl2LineEntry 16 } xdsl2LineStatusLastStateUs OBJECT-TYPE SYNTAX Xdsl2LastTransmittedState Morgenstern, et al. Standards Track [Page 67] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The last successful transmitted initialization state in the upstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.8 (Upstream last transmitted state)" DEFVAL { aturG9941 } ::= { xdsl2LineEntry 17 } xdsl2LineStatusXtur OBJECT-TYPE SYNTAX Xdsl2LineStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state (existing failures) of the xTU-R. This is a bitmap of possible conditions." REFERENCE "ITU-T G.997.1, paragraph #7.1.1.2 (Line far-end failures)" DEFVAL { { noDefect } } ::= { xdsl2LineEntry 18 } xdsl2LineStatusXtuc OBJECT-TYPE SYNTAX Xdsl2LineStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state (existing failures) of the xTU-C. This is a bitmap of possible conditions." REFERENCE "ITU-T G.997.1, paragraph #7.1.1.1 (Line near-end failures)" DEFVAL { { noDefect } } ::= { xdsl2LineEntry 19 } xdsl2LineStatusAttainableRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Downstream. The maximum downstream net data rate currently attainable by the xTU-C transmitter and the xTU-R receiver, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.19 (ATTNDRds)" DEFVAL { 0 } ::= { xdsl2LineEntry 20 } Morgenstern, et al. Standards Track [Page 68] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LineStatusAttainableRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Upstream. The maximum upstream net data rate currently attainable by the xTU-R transmitter and the xTU-C receiver, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.20 (ATTNDRus)" DEFVAL { 0 } ::= { xdsl2LineEntry 21 } xdsl2LineStatusActPsdDs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dBm/Hz" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Power Spectral Density (PSD) Downstream. The average downstream transmit PSD over the subcarriers used for downstream. It ranges from -900 to 0 units of 0.1 dBm/Hz (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.21 (ACTPSDds)" DEFVAL { 2147483647 } ::= { xdsl2LineEntry 22 } xdsl2LineStatusActPsdUs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dBm/Hz" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Power Spectral Density (PSD) Upstream. The average upstream transmit PSD over the subcarriers used for upstream. It ranges from -900 to 0 units of 0.1 dBm/Hz (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.22 (ACTPSDus)" DEFVAL { 2147483647 } ::= { xdsl2LineEntry 23 } xdsl2LineStatusActAtpDs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dBm" Morgenstern, et al. Standards Track [Page 69] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Downstream. The total amount of transmit power delivered by the xTU-C at the U-C reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dBm (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.24 (ACTATPds)" DEFVAL { 2147483647 } ::= { xdsl2LineEntry 24 } xdsl2LineStatusActAtpUs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Upstream. The total amount of transmit power delivered by the xTU-R at the U-R reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dBm (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.25 (ACTATPus)" DEFVAL { 2147483647 } ::= { xdsl2LineEntry 25 } xdsl2LineStatusActProfile OBJECT-TYPE SYNTAX Xdsl2LineProfiles MAX-ACCESS read-only STATUS current DESCRIPTION "The G.993.2 profile in use. The configuration parameter xdsl2LConfProfProfiles defines the set of allowed G.993.2 profiles. This parameter indicates the profile in use on this line. This parameter may be derived from the handshaking procedures defined in ITU-T Recommendation G.994.1." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.2 (VDSL2 Profile)" DEFVAL { {} } ::= { xdsl2LineEntry 26 } xdsl2LineStatusActLimitMask OBJECT-TYPE SYNTAX Xdsl2LineLimitMask Morgenstern, et al. Standards Track [Page 70] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The Limit PSD mask and band plan in use. The configuration parameter xdsl2LConfProfLimitMask defines the set of allowed G.993.2 limit PSD masks. This parameter indicates the limit PSD mask in use on this line." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.3 (VDSL2 Limit PSD Mask and Band plan)" DEFVAL { {} } ::= { xdsl2LineEntry 27 } xdsl2LineStatusActUs0Mask OBJECT-TYPE SYNTAX Xdsl2LineUs0Mask MAX-ACCESS read-only STATUS current DESCRIPTION "The US0 PSD mask in use. The configuration parameter xdsl2LConfProfUs0Mask defines the set of allowed US0 PSD masks. This parameter indicates the US0 PSD mask in use on this line. This parameter may be derived from the handshaking procedures defined in ITU-T Recommendation G.994.1." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.4 (VDSL2 US0 PSD Mask)" DEFVAL { {} } ::= { xdsl2LineEntry 28 } xdsl2LineStatusActSnrModeDs OBJECT-TYPE SYNTAX Xdsl2LineSnrMode MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter indicates if the transmitter-referred virtual noise is active on the line in the downstream direction. The configuration parameter xdsl2LConfProfSnrModeDs is used to configure referred virtual noise." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.15 (ACTSNRMODEds)" DEFVAL { virtualNoiseDisabled } ::= { xdsl2LineEntry 29 } xdsl2LineStatusActSnrModeUs OBJECT-TYPE SYNTAX Xdsl2LineSnrMode MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 71] RFC 5650 VDSL2-LINE MIB September 2009 "This parameter indicates if the transmitter-referred virtual noise is active on the line in the upstream direction. The configuration parameter xdsl2LConfProfSnrModeUs is used to configure referred virtual noise." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.18 (ACTSNRMODEus)" DEFVAL { virtualNoiseDisabled } ::= { xdsl2LineEntry 30 } xdsl2LineStatusElectricalLength OBJECT-TYPE SYNTAX Unsigned32 (0..1280) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter contains the estimated electrical length expressed in dB at 1 MHz, kl0. This is the final electrical length that would have been sent from the VTU-O to VTU-R if the electrical length was not forced by the CO-MIB. The value ranges from 0 to 128 dB in steps of 0.1 dB." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.23 (UPBOKLE)" DEFVAL { 0 } ::= { xdsl2LineEntry 31 } xdsl2LineStatusTssiDs OBJECT-TYPE SYNTAX Xdsl2Tssi MAX-ACCESS read-only STATUS current DESCRIPTION "The transmit spectrum shaping (TSSi) breakpoints expressed as the set of breakpoints exchanged during G.994.1 (Downstream)." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.29.5 (TSSpsds)" ::= { xdsl2LineEntry 32 } xdsl2LineStatusTssiUs OBJECT-TYPE SYNTAX Xdsl2Tssi MAX-ACCESS read-only STATUS current DESCRIPTION "The transmit spectrum shaping (TSSi) breakpoints expressed as the set of breakpoints exchanged during G.994.1 (Upstream)." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.29.6 (TSSpsus)" ::= { xdsl2LineEntry 33 } xdsl2LineStatusMrefPsdDs OBJECT-TYPE SYNTAX Xdsl2MrefPsdDs MAX-ACCESS read-only Morgenstern, et al. Standards Track [Page 72] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "The MEDLEY Reference PSD status parameters in the downstream direction expressed as the set of breakpoints exchanged at initialization." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.29.7 (MREFPSDds)" ::= { xdsl2LineEntry 34 } xdsl2LineStatusMrefPsdUs OBJECT-TYPE SYNTAX Xdsl2MrefPsdUs MAX-ACCESS read-only STATUS current DESCRIPTION "The MEDLEY Reference PSD status parameters in the upstream direction expressed as the set of breakpoints exchanged at initialization." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.29.8 (MREFPSDus)" ::= { xdsl2LineEntry 35 } xdsl2LineStatusTrellisDs OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter reports whether trellis coding is in use in the downstream direction." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.30 (TRELLISds)" DEFVAL { false } ::= { xdsl2LineEntry 36 } xdsl2LineStatusTrellisUs OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter reports whether trellis coding is in use in the upstream direction." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.31 (TRELLISus)" DEFVAL { false } ::= { xdsl2LineEntry 37 } xdsl2LineStatusActualCe OBJECT-TYPE SYNTAX Unsigned32 (2..16) UNITS "N/32 samples" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 73] RFC 5650 VDSL2-LINE MIB September 2009 "(ACTUALCE) This parameter reports the cyclic extension used on the line. It is coded as an unsigned integer from 2 to 16 in units of N/32 samples, where 2N is the Inverse Discrete Fourier Transform (IDFT) size." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.32 (ACTUALCE)" DEFVAL { 2 } ::= { xdsl2LineEntry 38 } ------------------------------------------------ -- xdsl2LineSegmentTable -- ------------------------------------------------ xdsl2LineSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineSegmentTable contains status parameters of VDSL2/ADSL/ADSL2 and ADSL2+ subcarriers. The parameters in this table are updated when a measurement request is made using the xdsl2LineCmndConfBpsc object. Note that a bits-per-subcarrier measurement is also performed during a line diagnostic procedure. This table provides an additional mechanism to fetch the bits-per-subcarrier data. This additional mechanism is provided so that bits-per-subcarrier data may be fetched without forcing the line into no power state. This is useful because the bits-per-subcarrier allocation may be adjusted at Showtime due to rate adaption and bit swapping. The implementation of this additional mechanism for measuring bits per subcarrier is not mandatory." ::= { xdsl2Status 1 } xdsl2LineSegmentEntry OBJECT-TYPE SYNTAX Xdsl2LineSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineSegmentEntry contains status parameters of VDSL2/ADSL/ADSL2 and ADSL2+ subcarriers. Objects in the table refer to NSus and NSds. For G.993.2, the value of NSus and NSds are, respectively, the indices of the highest supported upstream and downstream subcarriers according to the selected implementation profile. For ADSL, NSus is equal to NSCus-1 and NSds is equal to NSCds-1. Morgenstern, et al. Standards Track [Page 74] RFC 5650 VDSL2-LINE MIB September 2009 One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is the transmission direction. A third index identifies the specific segment of the subcarriers status addressed." INDEX { ifIndex, xdsl2LineSegmentDirection, xdsl2LineSegment } ::= { xdsl2LineSegmentTable 1 } Xdsl2LineSegmentEntry ::= SEQUENCE { xdsl2LineSegmentDirection Xdsl2Direction, xdsl2LineSegment Unsigned32, xdsl2LineSegmentBitsAlloc Xdsl2BitsAlloc, xdsl2LineSegmentRowStatus RowStatus } xdsl2LineSegmentDirection OBJECT-TYPE SYNTAX Xdsl2Direction MAX-ACCESS not-accessible STATUS current DESCRIPTION "The direction of the subcarrier either upstream or downstream." ::= { xdsl2LineSegmentEntry 1 } xdsl2LineSegment OBJECT-TYPE SYNTAX Unsigned32(1..8) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The segment of the subcarriers status information provided by this row. Status parameters in this table are retrieved in segments. The first segment of the status information is retrieved with xdsl2LineSegment=1, the second segment is retrieved with xdsl2LineSegment=2, and so on. When a status parameter is retrieved in n segments where n<8) then, for that parameter, GET operations for the remaining segment numbers (n+1 to 8) will respond with a zero-length OCTET STRING." ::= { xdsl2LineSegmentEntry 2 } xdsl2LineSegmentBitsAlloc OBJECT-TYPE SYNTAX Xdsl2BitsAlloc UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 75] RFC 5650 VDSL2-LINE MIB September 2009 "The bits allocation per subcarrier. An array of 256 octets (512 nibbles), designed for supporting up to 512 (downstream) subcarriers. When more than 512 subcarriers are supported, the status information is reported through multiple (up to 8) segments. The first segment is then used for the first 512 subcarriers. The second segment is used for the subcarriers 512 to 1023 and so on. The aggregate number of utilized nibbles in the downstream direction (in all segments) depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. The segment number is in xdsl2SCStatusSegment. Nibble i (0 <= i < MIN((NS+1)-(segment-1)*512,512)) in each segment is set to a value in the range 0 to 15 to indicate that the respective downstream or upstream subcarrier j (j=(segement-1)*512+i) has the same amount of bits allocation." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.29.1 (BITSpsds) and paragraph #7.5.1.29.2 (BITSpsus)" ::= { xdsl2LineSegmentEntry 3 } xdsl2LineSegmentRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "Row Status. The SNMP agent will create a row in this table for storing the results of a measurement performed on the associated line, if the row does not already exist. The SNMP manager is not permitted to create rows in this table or set the row status to 'notInService'. In the first case, if the SNMP manager tries to create a new row, the SNMP agent responds with the value 'noCreation' in the error status field of the response-PDU. In the latter case, the SNMP agent responds with the value 'wrongValue' in the error status field of the response-PDU. The SNMP agent may have limited resources; therefore, if multiple rows coexist in this table, it may fail to add new rows to this table or allocate memory resources. If that occurs, the SNMP agent responds with the value 'noResources' (for the xdsl2LineCmndConfBpscFailReason object in xdsl2LineTable). The management system (the operator) may delete rows from this table according to any scheme. For example, after retrieving the results. Morgenstern, et al. Standards Track [Page 76] RFC 5650 VDSL2-LINE MIB September 2009 When the SNMP manager deletes any row in this table, the SNMP agent MUST delete all rows in this table that have the same ifIndex value." ::= { xdsl2LineSegmentEntry 4 } ------------------------------------------------ -- xdsl2LineBandTable -- ------------------------------------------------ xdsl2LineBandTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineBandTable contains the, per-band line status parameters of the VDSL2/ADSL/ADSL2 or ADSL2+ line. The parameters in this table are updated at line initialization time and at Showtime." ::= { xdsl2Line 2 } xdsl2LineBandEntry OBJECT-TYPE SYNTAX Xdsl2LineBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is a per-band index covering both VDSL2 and ADSL/ADSL2/ADSL2+." INDEX { ifIndex, xdsl2LineBand } ::= { xdsl2LineBandTable 1 } Xdsl2LineBandEntry ::= SEQUENCE { xdsl2LineBand Xdsl2Band, xdsl2LineBandStatusLnAtten Unsigned32, xdsl2LineBandStatusSigAtten Unsigned32, xdsl2LineBandStatusSnrMargin Integer32 } xdsl2LineBand OBJECT-TYPE SYNTAX Xdsl2Band MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies the band(s) associated with this line. For ADSL/ADSL2/ADSL2+, the values 'upstream' and 'downstream' will always be present. Morgenstern, et al. Standards Track [Page 77] RFC 5650 VDSL2-LINE MIB September 2009 For VDSL2, a subset of {'us0', 'ds1', 'us1' ... 'ds4', 'us4' } will always be present, together with rows for 'upstream' and 'downstream', in which only the xdsl2LineBandStatusSnrMargin object is expected to hold a valid (average) measurement." ::= { xdsl2LineBandEntry 1 } xdsl2LineBandStatusLnAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Line Attenuation. When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers of that band during initialization. When referring to a band in the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers of that band during initialization. Values range from 0 to 1270 in units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.9 (LATNds) and paragraph #7.5.1.10 (LATNus)6" DEFVAL { 2147483646 } ::= { xdsl2LineBandEntry 2 } xdsl2LineBandStatusSigAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Signal Attenuation. When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers of that band during Showtime. When referring to a band in the upstream direction, it is the Morgenstern, et al. Standards Track [Page 78] RFC 5650 VDSL2-LINE MIB September 2009 measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers of that band during Showtime. Values range from 0 to 1270 in units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.11 (SATNds) and paragraph #7.5.1.12 (SATNus)" DEFVAL { 2147483646 } ::= { xdsl2LineBandEntry 3 } xdsl2LineBandStatusSnrMargin OBJECT-TYPE SYNTAX Integer32 (-640..630 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "SNR Margin is the maximum increase in dB of the noise power received at the xTU (xTU-R for a band in the downstream direction and xTU-C for a band in the upstream direction), such that the BER requirements are met for all bearer channels received at the xTU. Values range from -640 to 630 in units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.13 (SNRMds) and paragraph #7.5.1.14 (SNRMpbds) and paragraph #7.5.1.16 (SNRMus) and paragraph #7.5.1.17 (SNRMpbus)" DEFVAL { 2147483646 } ::= { xdsl2LineBandEntry 4 } ------------------------------------------------ -- xdsl2ChannelStatusTable -- ------------------------------------------------ xdsl2ChannelStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2ChannelStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2ChannelStatusTable contains status Morgenstern, et al. Standards Track [Page 79] RFC 5650 VDSL2-LINE MIB September 2009 parameters of VDSL2/ADSL/ADSL2 or ADSL2+ channel. This table contains live data from equipment." ::= { xdsl2Status 2 } xdsl2ChannelStatusEntry OBJECT-TYPE SYNTAX Xdsl2ChannelStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of a DSL channel. A second index of this table is the termination unit." INDEX { ifIndex, xdsl2ChStatusUnit } ::= { xdsl2ChannelStatusTable 1 } Xdsl2ChannelStatusEntry ::= SEQUENCE { xdsl2ChStatusUnit Xdsl2Unit, xdsl2ChStatusActDataRate Unsigned32, xdsl2ChStatusPrevDataRate Unsigned32, xdsl2ChStatusActDelay Unsigned32, xdsl2ChStatusActInp Unsigned32, xdsl2ChStatusInpReport Xdsl2ChInpReport, xdsl2ChStatusNFec Unsigned32, xdsl2ChStatusRFec Unsigned32, xdsl2ChStatusLSymb Unsigned32, xdsl2ChStatusIntlvDepth Unsigned32, xdsl2ChStatusIntlvBlock Unsigned32, xdsl2ChStatusLPath Unsigned32, xdsl2ChStatusAtmStatus Xdsl2ChAtmStatus, xdsl2ChStatusPtmStatus Xdsl2ChPtmStatus } xdsl2ChStatusUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2ChannelStatusEntry 1 } xdsl2ChStatusActDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The actual net data rate at which the bearer channel is Morgenstern, et al. Standards Track [Page 80] RFC 5650 VDSL2-LINE MIB September 2009 operating, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. The data rate is coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.1 (Actual data rate)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 2 } xdsl2ChStatusPrevDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The previous net data rate that the bearer channel was operating at just before the latest rate change event. This could be a full or short initialization, fast retrain, DRA or power management transitions, excluding transitions between L0 state and L1 or L2 states. The data rate is coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.2 (Previous data rate)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 3 } xdsl2ChStatusActDelay OBJECT-TYPE SYNTAX Unsigned32(0..8176) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The actual one-way interleaving delay introduced by the PMS-TC in the direction of the bearer channel, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. It is coded in ms (rounded to the nearest ms)." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.3 (Actual interleaving delay)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 4 } xdsl2ChStatusActInp OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "0.1 symbols" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual impulse noise protection. This parameter reports the actual impulse noise protection (INP) Morgenstern, et al. Standards Track [Page 81] RFC 5650 VDSL2-LINE MIB September 2009 on the bearer channel in the L0 state. In the L1 or L2 state, the parameter contains the INP in the previous L0 state. For ADSL, this value is computed according to the formula specified in the relevant Recommendation based on the actual framing parameters. For ITU-T Recommendation G.993.2, the method to report this value is according to the INPREPORT parameter. The value is coded in fractions of DMT symbols with a granularity of 0.1 symbols. The range is from 0 to 25.4. The special value of 255 indicates an ACTINP higher than 25.4." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.4 (ACTINP)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 5 } xdsl2ChStatusInpReport OBJECT-TYPE SYNTAX Xdsl2ChInpReport MAX-ACCESS read-only STATUS current DESCRIPTION "Impulse noise protection reporting mode." REFERENCE "ITU-T G.997.1 Amendment 1, paragraph #7.5.2.5 (INPREPORT)" DEFVAL { inpComputedUsingFormula } ::= { xdsl2ChannelStatusEntry 6 } xdsl2ChStatusNFec OBJECT-TYPE SYNTAX Unsigned32(0..255) UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual size of Reed-Solomon codeword. This parameter reports the actual number of Reed-Solomon redundancy bytes per codeword used in the latency path in which the bearer channel is transported. The value is coded in bytes. It ranges from 0 to 16. The value 0 indicates no Reed-Solomon coding." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.6.1 (NFEC)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 7 } xdsl2ChStatusRFec OBJECT-TYPE SYNTAX Unsigned32(0..16) UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual number of Reed-Solomon redundancy bytes. Morgenstern, et al. Standards Track [Page 82] RFC 5650 VDSL2-LINE MIB September 2009 This parameter reports the actual number of Reed-Solomon redundancy bytes per codeword used in the latency path in which the bearer channel is transported. The value is coded in bytes. It ranges from 0 to 16. The value 0 indicates no Reed-Solomon coding." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.6.2 (RFEC)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 8 } xdsl2ChStatusLSymb OBJECT-TYPE SYNTAX Unsigned32(0..65535) UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual number of bits per symbol. This parameter reports the actual number of bits per symbol assigned to the latency path in which the bearer channel is transported. This value does not include trellis overhead. The value is coded in bits. It ranges from 0 to 65535." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.6.3 (LSYMB)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 9 } xdsl2ChStatusIntlvDepth OBJECT-TYPE SYNTAX Unsigned32(1..4096) MAX-ACCESS read-only STATUS current DESCRIPTION "Actual interleaving depth. This parameter reports the actual depth of the interleaver used in the latency path in which the bearer channel is transported. The value ranges from 1 to 4096 in steps of 1. The value 1 indicates no interleaving." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.6.4 (INTLVDEPTH)" DEFVAL { 1 } ::= { xdsl2ChannelStatusEntry 10 } xdsl2ChStatusIntlvBlock OBJECT-TYPE SYNTAX Unsigned32(4..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Actual interleaving block length. This parameter reports the actual block length of the interleaver used in the latency path in which the bearer channel is transported. Morgenstern, et al. Standards Track [Page 83] RFC 5650 VDSL2-LINE MIB September 2009 The value ranges from 4 to 255 in steps of 1." REFERENCE "ITU-T G.997.1, paragraph #7.5.2.6.5 (INTLVBLOCK)" DEFVAL { 4 } ::= { xdsl2ChannelStatusEntry 11 } xdsl2ChStatusLPath OBJECT-TYPE SYNTAX Unsigned32(0..3) MAX-ACCESS read-only STATUS current DESCRIPTION "Actual latency path. This parameter reports the index of the actual latency path in which the bearer is transported. The valid values are 0, 1, 2 and 3. For G.992.1, the FAST path shall be mapped to the latency index 0, and the INTERLEAVED path shall be mapped to the latency index 1." REFERENCE "ITU-T G.997.1 amendment 1, paragraph #7.5.2.7 (LPATH)" DEFVAL { 0 } ::= { xdsl2ChannelStatusEntry 12 } xdsl2ChStatusAtmStatus OBJECT-TYPE SYNTAX Xdsl2ChAtmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state (existing failures) of the DSL channel in case its Data Path is ATM. This is a bitmap of possible conditions. In case the channel is not of ATM Data Path, the object is set to '0'." REFERENCE "ITU-T G.997.1, paragraph #7.1.4 (ATM data path failures)" DEFVAL { { noDefect } } ::= { xdsl2ChannelStatusEntry 13 } xdsl2ChStatusPtmStatus OBJECT-TYPE SYNTAX Xdsl2ChPtmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state (existing failures) of the DSL channel in case its Data Path is PTM (Packet Transfer Mode). This is a bitmap of possible conditions. In case the channel is not of PTM Data Path, the object is set to '0'." REFERENCE "ITU-T G.997.1, paragraph #7.1.5 Morgenstern, et al. Standards Track [Page 84] RFC 5650 VDSL2-LINE MIB September 2009 (PTM Data Path failures)" DEFVAL { { noDefect } } ::= { xdsl2ChannelStatusEntry 14 } ------------------------------------------------ -- Scalars that relate to the SC Status Tables ------------------------------------------------ xdsl2ScalarSCMaxInterfaces OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value determines the maximum number of interfaces supported by xdsl2SCStatusTable, xdsl2SCStatusBandTable, and xdsl2SCStatusSegmentTable." ::= { xdsl2ScalarSC 1 } xdsl2ScalarSCAvailInterfaces OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value determines the currently available number of interfaces listed in xdsl2SCStatusTable, xdsl2SCStatusBandTable, and xdsl2SCStatusSegmentTable." ::= { xdsl2ScalarSC 2 } ------------------------------------------------ -- xdsl2SCStatusTable -- ------------------------------------------------ xdsl2SCStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2SCStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2SCStatusTable contains status parameters for VDSL2/ADSL/ADSL2 and ADSL2+ that provide information about the size of parameters in xdsl2SCStatusSegmentTable. The parameters in this table MUST be updated after a loop diagnostic procedure, MAY be updated after a line initialization, and MAY be updated at Showtime." ::= { xdsl2Status 3 } xdsl2SCStatusEntry OBJECT-TYPE SYNTAX Xdsl2SCStatusEntry Morgenstern, et al. Standards Track [Page 85] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is the transmission direction." INDEX { ifIndex, xdsl2SCStatusDirection } ::= { xdsl2SCStatusTable 1 } Xdsl2SCStatusEntry ::= SEQUENCE { xdsl2SCStatusDirection Xdsl2Direction, xdsl2SCStatusLinScale Unsigned32, xdsl2SCStatusLinScGroupSize Unsigned32, xdsl2SCStatusLogMt Unsigned32, xdsl2SCStatusLogScGroupSize Unsigned32, xdsl2SCStatusQlnMt Unsigned32, xdsl2SCStatusQlnScGroupSize Unsigned32, xdsl2SCStatusSnrMtime Unsigned32, xdsl2SCStatusSnrScGroupSize Unsigned32, xdsl2SCStatusAttainableRate Unsigned32, xdsl2SCStatusRowStatus RowStatus } xdsl2SCStatusDirection OBJECT-TYPE SYNTAX Xdsl2Direction MAX-ACCESS not-accessible STATUS current DESCRIPTION "The direction of the subcarrier either upstream or downstream." ::= { xdsl2SCStatusEntry 1 } xdsl2SCStatusLinScale OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The scale factor to be applied to the H(f) linear representation values for the respective transmission direction. This parameter is only available after a loop diagnostic procedure. It is represented as an unsigned integer in the range from 1 to 2^16-1." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.26.1 (HLINSCds) and paragraph #7.5.1.26.7 (HLINSCus)" ::= { xdsl2SCStatusEntry 2 } xdsl2SCStatusLinScGroupSize OBJECT-TYPE Morgenstern, et al. Standards Track [Page 86] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX Unsigned32(1 | 2 | 4 | 8) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of subcarriers per group used to report the H(f) linear representation values for the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to one and, for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters. This parameter is only available after a loop diagnostic procedure." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.26.2 (HLINGds) and paragraph #7.5.1.26.8 (HLINGus)" ::= { xdsl2SCStatusEntry 3 } xdsl2SCStatusLogMt OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter contains the number of symbols used to measure the Hlog(f) values. It is represented as an unsigned integer in the range from 1 to 2^16-1. After a loop diagnostic procedure, this parameter shall contain the number of symbols used to measure the Hlog(f). It should correspond to the value specified in the Recommendation (e.g., the number of symbols in 1 s time interval for ITU-T Recommendation. G.992.3)." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.26.4 (HLOGMTds) and paragraph #7.5.1.26.10 (HLOGMTus)" ::= { xdsl2SCStatusEntry 4 } xdsl2SCStatusLogScGroupSize OBJECT-TYPE SYNTAX Unsigned32(1 | 2 | 4 | 8) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of subcarriers per group used to report the H(f) logarithmic representation values for the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to 1, and for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.26.5 (HLOGGds) and paragraph #7.5.1.26.11 (HLOGGus)" ::= { xdsl2SCStatusEntry 5 } xdsl2SCStatusQlnMt OBJECT-TYPE Morgenstern, et al. Standards Track [Page 87] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter contains the number of symbols used to measure the QLN(f) values. It is an unsigned integer in the range from 1 to 2^16-1. After a loop diagnostic procedure, this parameter shall contain the number of symbols used to measure the QLN(f). It should correspond to the value specified in the Recommendation (e.g., the number of symbols in 1 s time interval for ITU-T Recommendation G.992.3)." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.27.1 (QLNMTds) and paragraph #7.5.1.27.4 (QLNMTus)" ::= { xdsl2SCStatusEntry 6 } xdsl2SCStatusQlnScGroupSize OBJECT-TYPE SYNTAX Unsigned32(1 | 2 | 4 | 8) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of subcarriers per group used to report the Quiet Line Noise values for the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to 1, and for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.27.2 (QLNGds) and paragraph #7.5.1.27.5 (QLNGus)" ::= { xdsl2SCStatusEntry 7 } xdsl2SCStatusSnrMtime OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "symbols" MAX-ACCESS read-only STATUS current DESCRIPTION "This parameter contains the number of symbols used to measure the SNR(f) values. It is an unsigned integer in the range from 1 to 2^16-1. After a loop diagnostic procedure, this parameter shall contain the number of symbols used to measure the SNR(f). It should correspond to the value specified in the Recommendation (e.g., the number of symbols in 1 s time interval for ITU-T Recommendation G.992.3)." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.28.1 (SNRMTds) and paragraph #7.5.1.28.4 (SNRMTus)" ::= { xdsl2SCStatusEntry 8 } xdsl2SCStatusSnrScGroupSize OBJECT-TYPE Morgenstern, et al. Standards Track [Page 88] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX Unsigned32(1 | 2 | 4 | 8) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of subcarriers per group used to report the SNR values on the respective transmission direction. The valid values are 1, 2, 4, and 8. For ADSL, this parameter is equal to 1, and for VDSL2, it is equal to the size of a subcarrier group used to compute these parameters." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.28.2 (SNRGds) and paragraph #7.5.1.28.5 (SNRGus)" ::= { xdsl2SCStatusEntry 9 } xdsl2SCStatusAttainableRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate. The maximum net data rate currently attainable by the xTU-C transmitter and xTU-R receiver (when referring to downstream direction) or by the xTU-R transmitter and xTU-C receiver (when referring to upstream direction). Value is coded in bits/s. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.19 (ATTNDRds) and paragraph #7.5.1.20 (ATTNDRus)" ::= { xdsl2SCStatusEntry 10 } xdsl2SCStatusRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "Row Status. The SNMP agent will create a row in this table for storing the results of a DELT performed on the associated line, if the row does not already exist. When a row is created in this table, the SNMP agent should also create corresponding rows in the tables xdsl2SCStatusBandTable and xdsl2SCStatusSegmentTable. The SNMP manager is not permitted to create rows in this table or set the row status to 'notInService'. In the first case, Morgenstern, et al. Standards Track [Page 89] RFC 5650 VDSL2-LINE MIB September 2009 if the SNMP manager tries to create a new row, the SNMP agent responds with the value 'noCreation' in the error status field of the response-PDU. In the latter case the SNMP agent responds with the value 'wrongValue' in the error status field of the response-PDU. When a row is deleted in this table, the SNMP agent should also delete corresponding rows in the tables xdsl2SCStatusBandTable and xdsl2SCStatusSegmentTable. The SNMP agent may have limited resources; therefore, if multiple rows coexist in this table, it may fail to add new rows to this table or allocate memory resources for a new DELT process. If that occurs, the SNMP agent responds with either the value 'tableFull' or the value 'noResources' (for the xdsl2LineCmndConfLdsfFailReason object in xdsl2LineTable). The management system (the operator) may delete rows from this table according to any scheme. For example, after retrieving the results." ::= { xdsl2SCStatusEntry 11 } ------------------------------------------------ -- xdsl2SCStatusBandTable -- ------------------------------------------------ xdsl2SCStatusBandTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2SCStatusBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2SCStatusBandTable contains subcarrier status parameters for VDSL2/ADSL/ADSL2 and ADSL2+ that are grouped per- band. For ADSL/ADSL2/ADSL2+, there is a single upstream band and a single downstream band. For VDSL2, there are several downstream bands and several upstream bands. The parameters in this table are only available after a loop diagnostic procedure." ::= { xdsl2Status 4 } xdsl2SCStatusBandEntry OBJECT-TYPE SYNTAX Xdsl2SCStatusBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface Morgenstern, et al. Standards Track [Page 90] RFC 5650 VDSL2-LINE MIB September 2009 has an ifType of vdsl2(251). A second index of this table is the transmission band." INDEX { ifIndex, xdsl2SCStatusBand } ::= { xdsl2SCStatusBandTable 1 } Xdsl2SCStatusBandEntry ::= SEQUENCE { xdsl2SCStatusBand Xdsl2Band, xdsl2SCStatusBandLnAtten Unsigned32, xdsl2SCStatusBandSigAtten Unsigned32 } xdsl2SCStatusBand OBJECT-TYPE SYNTAX Xdsl2Band MAX-ACCESS not-accessible STATUS current DESCRIPTION "The transmission band." ::= { xdsl2SCStatusBandEntry 1 } xdsl2SCStatusBandLnAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers during diagnostics mode. When referring to a band in the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers during diagnostics mode. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.9 (LATNds) and paragraph #7.5.1.10 (LATNus)" DEFVAL { 2147483646 } ::= { xdsl2SCStatusBandEntry 2 } Morgenstern, et al. Standards Track [Page 91] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2SCStatusBandSigAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all subcarriers during Showtime after the diagnostics mode. When referring to the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all subcarriers during Showtime after the diagnostics mode. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable. This object reflects the value of the parameter following the most recent DELT performed on the associated line. Once the DELT process is over, the parameter no longer changes until the row is deleted or a new DELT process is initiated." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.11 (SATNds) and paragraph #7.5.1.12 (SATNus)" DEFVAL { 2147483646 } ::= { xdsl2SCStatusBandEntry 3 } ------------------------------------------------ -- xdsl2SCStatusSegmentTable -- ------------------------------------------------ xdsl2SCStatusSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2SCStatusSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2SCStatusSegmentTable contains status parameters of VDSL2/ADSL/ADSL2 and ADSL2+ subcarriers. Several objects in the table refer to NSus and NSds. For G.993.2, the value of NSus and NSds are, respectively, the indices of the highest supported upstream and downstream subcarriers according to the selected implementation profile. For ADSL, NSus is equal to NSCus-1 and NSds is equal to NSCds-1. The parameters in this table MUST be updated after a loop Morgenstern, et al. Standards Track [Page 92] RFC 5650 VDSL2-LINE MIB September 2009 diagnostic procedure and MAY be updated after a line initialization and MAY be updated at Showtime." ::= { xdsl2Status 5 } xdsl2SCStatusSegmentEntry OBJECT-TYPE SYNTAX Xdsl2SCStatusSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is the transmission direction. A third index identifies the specific segment of the subcarriers status addressed." INDEX { ifIndex, xdsl2SCStatusDirection, xdsl2SCStatusSegment } ::= { xdsl2SCStatusSegmentTable 1 } Xdsl2SCStatusSegmentEntry ::= SEQUENCE { xdsl2SCStatusSegment Unsigned32, xdsl2SCStatusSegmentLinReal OCTET STRING, xdsl2SCStatusSegmentLinImg OCTET STRING, xdsl2SCStatusSegmentLog OCTET STRING, xdsl2SCStatusSegmentQln OCTET STRING, xdsl2SCStatusSegmentSnr OCTET STRING, xdsl2SCStatusSegmentBitsAlloc Xdsl2BitsAlloc, xdsl2SCStatusSegmentGainAlloc OCTET STRING } xdsl2SCStatusSegment OBJECT-TYPE SYNTAX Unsigned32(1..8) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The segment of the subcarriers status information provided by this row. Several status parameters in this table are retrieved in segments. The first segment of the status information is retrieved with xdsl2SCStatusSegment=1, the second segment is retrieved with xdsl2SCStatusSegment=2, and so on. When any status parameter is retrieved in n segments where n<8), then for that parameter, GET operations for the remaining segment numbers (n+1 to 8) will respond with a zero-length OCTET STRING." ::= { xdsl2SCStatusSegmentEntry 1 } xdsl2SCStatusSegmentLinReal OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) Morgenstern, et al. Standards Track [Page 93] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 complex H(f) linear representation values in linear scale for the respective transmission direction. It is designed to support up to 512 (downstream) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the real component (referred to here as a(i)) of Hlin(f = i*Df) value for a particular subcarrier group index i (0 <= i <= NS). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is xdsl2SCStatusLinScale and a(i) and b(i) (provided by the xdsl2SCStatusSegmentLinImg object) are in the range (-2^15+1) to (+2^15-1). A special value a(i)=b(i)= -2^15 indicates that no measurement could be done for the subcarrier group because it is out of the passband or that the attenuation is out of range to be represented. This parameter is only available after a loop diagnostic procedure. Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.26.3 (HLINpsds) and paragraph #7.5.1.26.9 (HLINpsus)" ::= { xdsl2SCStatusSegmentEntry 2 } xdsl2SCStatusSegmentLinImg OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 complex H(f) linear representation values in linear scale for the respective transmission direction. It is designed to support up to 512 (downstream) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the imaginary component (referred to here as b(i)) of Hlin(f = i*Df) value for a particular subcarrier group index i (0 <= i <= NS). Hlin(f) is represented as ((scale/2^15)*((a(i)+j*b(i))/2^15)), where scale is xdsl2SCStatusLinScale and a(i) (provided by the xdsl2SCStatusSegmentLinReal object) and b(i) are in the range (-2^15+1) to (+2^15-1). A special value a(i)=b(i)= -2^15 indicates that no measurement Morgenstern, et al. Standards Track [Page 94] RFC 5650 VDSL2-LINE MIB September 2009 could be done for the subcarrier group because it is out of the passband or that the attenuation is out of range to be represented. This parameter is only available after a loop diagnostic procedure. Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.26.3 (HLINpsds) and paragraph #7.5.1.26.9 (HLINpsus)" ::= { xdsl2SCStatusSegmentEntry 3 } xdsl2SCStatusSegmentLog OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) UNITS "dB" MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 real H(f) logarithmic representation values in dB for the respective transmission direction. It is designed to support up to 512 (downstream) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the real Hlog(f = i*Df) value for a particular subcarrier group index i, (0 <= i <= NS). The real Hlog(f) value is represented as (6-m(i)/10), with m(i) in the range 0 to 1022. A special value m=1023 indicates that no measurement could be done for the subcarrier group because it is out of the passband or that the attenuation is out of range to be represented. This parameter is applicable in loop diagnostic procedure and initialization. Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.26.6 (HLOGpsds) and paragraph #7.5.1.26.12 (HLOGpsus)" ::= { xdsl2SCStatusSegmentEntry 4 } xdsl2SCStatusSegmentQln OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..512)) UNITS "dBm/Hz" MAX-ACCESS read-only STATUS current DESCRIPTION "An array of up to 512 real Quiet Line Noise values in dBm/Hz for the respective transmission direction. It is designed for up to 512 (downstream) subcarrier groups and can be retrieved in a single segment. The number of utilized values in the downstream direction depends Morgenstern, et al. Standards Track [Page 95] RFC 5650 VDSL2-LINE MIB September 2009 on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Each array entry represents the QLN(f = i*Df) value for a particular subcarrier index i, (0 <= i <= NS). The QLN(f) is represented as ( -23-n(i)/2), with n(i) in the range 0 to 254. A special value n(i)=255 indicates that no measurement could be done for the subcarrier group because it is out of the passband or that the noise PSD is out of range to be represented. This parameter is applicable in loop diagnostic procedure and initialization. Each value in this array is 8 bits wide." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.27.3 (QLNpsds) and paragraph #7.5.1.27.6 (QLNpsus)" ::= { xdsl2SCStatusSegmentEntry 5 } xdsl2SCStatusSegmentSnr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..512)) UNITS "0.5 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The SNR Margin per subcarrier group, expressing the ratio between the received signal power and received noise power per subscriber group. It is an array of 512 octets, designed for supporting up to 512 (downstream) subcarrier groups and can be retrieved in a single segment. The number of utilized octets in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. Octet i (0 <= i <= NS) is set to a value in the range 0 to 254 to indicate that the respective downstream or upstream subcarrier group i has an SNR of: (-32 + xdsl2SCStatusSegmentSnr(i)/2) in dB (i.e., -32 to 95 dB). The special value 255 means that no measurement could be done for the subcarrier group because it is out of the PSD mask passband or that the noise PSD is out of range to be represented. Each value in this array is 8 bits wide." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.28.3 (SNRpsds) and paragraph #7.5.1.28.6 (SNRpsus)" ::= { xdsl2SCStatusSegmentEntry 6 } xdsl2SCStatusSegmentBitsAlloc OBJECT-TYPE SYNTAX Xdsl2BitsAlloc UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION "The bits allocation per subcarrier. An array of 256 octets (512 nibbles) designed for supporting up to 512 (downstream) Morgenstern, et al. Standards Track [Page 96] RFC 5650 VDSL2-LINE MIB September 2009 subcarriers. When more than 512 subcarriers are supported, the status information is reported through multiple (up to 8) segments. The first segment is then used for the first 512 subcarriers. The second segment is used for the subcarriers 512 to 1023 and so on. The aggregate number of utilized nibbles in the downstream direction (in all segments) depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. The segment number is in xdsl2SCStatusSegment. Nibble i (0 <= i < MIN((NS+1)-(segment-1)*512,512)) in each segment is set to a value in the range 0 to 15 to indicate that the respective downstream or upstream subcarrier j (j=(segement-1)*512+i) has the same amount of bits allocation." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.29.1 (BITSpsds) and paragraph #7.5.1.29.2 (BITSpsus)" ::= { xdsl2SCStatusSegmentEntry 7 } xdsl2SCStatusSegmentGainAlloc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-only STATUS current DESCRIPTION "The gain allocation per subcarrier. An array of 512 16-bit values, designed for supporting up to 512 (downstream) subcarriers. When more then 512 subcarriers are supported, the status information is reported through multiple (up to 8) segments. The first segment is then used for the first 512 subcarriers. The second segment is used for the subcarriers 512 to 1023 and so on. The aggregate number of utilized octets in the downstream direction depends on NSds; in the upstream direction, it depends on NSus. This value is referred to here as NS. The segment number is in xdsl2SCStatusSegment. Value i (0 <= i < MIN((NS+1)-(segment-1)*512,512)) in each segment is set to a value in the range 0 to 4093 to indicate that the respective downstream or upstream subcarrier j (j=(segement-1)*512+i) has the same amount of gain value. The gain value is represented as a multiple of 1/512 on a linear scale. Each value in this array is 16 bits wide and is stored in big endian format." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.29.3 (GAINSpsds) and paragraph #7.5.1.29.4 (GAINSpsus)" ::= { xdsl2SCStatusSegmentEntry 8 } ------------------------------------------------ -- xdsl2LineInventoryTable -- Morgenstern, et al. Standards Track [Page 97] RFC 5650 VDSL2-LINE MIB September 2009 ------------------------------------------------ xdsl2LineInventoryTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineInventoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineInventoryTable contains an inventory of the DSL termination unit." ::= { xdsl2Inventory 1 } xdsl2LineInventoryEntry OBJECT-TYPE SYNTAX Xdsl2LineInventoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is the termination unit." INDEX { ifIndex, xdsl2LInvUnit } ::= { xdsl2LineInventoryTable 1 } Xdsl2LineInventoryEntry ::= SEQUENCE { xdsl2LInvUnit Xdsl2Unit, xdsl2LInvG994VendorId OCTET STRING, xdsl2LInvSystemVendorId OCTET STRING, xdsl2LInvVersionNumber OCTET STRING, xdsl2LInvSerialNumber OCTET STRING, xdsl2LInvSelfTestResult Unsigned32, xdsl2LInvTransmissionCapabilities Xdsl2TransmissionModeType } xdsl2LInvUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2LineInventoryEntry 1 } xdsl2LInvG994VendorId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ADSL Transceiver Unit (ATU) G.994.1 Vendor ID as Morgenstern, et al. Standards Track [Page 98] RFC 5650 VDSL2-LINE MIB September 2009 inserted in the G.994.1 CL/CLR message. It consists of 8 binary octets, including a country code followed by a (regionally allocated) provider code, as defined in Recommendation T.35." REFERENCE "ITU-T G.997.1, paragraph #7.4.1-7.4.2" ::= { xdsl2LineInventoryEntry 2 } xdsl2LInvSystemVendorId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU System Vendor ID (identifies the xTU system integrator) as inserted in the Overhead Messages (both xTUs for G.992.3, G.992.4, G.992.5, and G.993.2) or in the Embedded Operations Channel (xTU-R in G.992.1 and G.992.2). It consists of 8 binary octets, with same format as used for Xdsl2InvG994VendorId." REFERENCE "ITU-T G.997.1, paragraph #7.4.3-7.4.4" ::= { xdsl2LineInventoryEntry 3 } xdsl2LInvVersionNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The xTU version number (vendor-specific information) as inserted in the Overhead Messages (both xTUs for G.992.3, G.992.4, G.992.5, and G.993.2) or in the Embedded Operations Channel (xTU-R in G.992.1 and G.992.2). It consists of up to 16 binary octets." REFERENCE "ITU-T G.997.1, paragraph #7.4.5-7.4.6" ::= { xdsl2LineInventoryEntry 4 } xdsl2LInvSerialNumber OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The xTU serial number (vendor-specific information) as inserted in the Overhead Messages (both xTUs for G.992.3, G.992.4, G.992.5, and G.993.2) or in the Embedded Operations Channel (xTU-R in G.992.1 and G.992.2). It is vendor-specific information consisting of up to 32 ASCII characters." REFERENCE "ITU-T G.997.1, paragraph #7.4.7-7.4.8" ::= { xdsl2LineInventoryEntry 5 } xdsl2LInvSelfTestResult OBJECT-TYPE Morgenstern, et al. Standards Track [Page 99] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The xTU self-test result, coded as a 32-bit value. The most significant octet of the result is '0' if the self-test passed, and '1' if the self-test failed. The interpretation of the other octets is vendor discretionary." REFERENCE "ITU-T G.997.1, paragraph #7.4.9-7.4.10" DEFVAL { 0 } ::= { xdsl2LineInventoryEntry 6 } xdsl2LInvTransmissionCapabilities OBJECT-TYPE SYNTAX Xdsl2TransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The xTU transmission system capability list of the different coding types. It is coded in a bitmap representation with 1 or more bits set. A bit set to '1' means that the xTU supports the respective coding. The value may be derived from the handshaking procedures defined in G.994.1. A set of xDSL line transmission modes, with one bit per mode." REFERENCE "ITU-T G.997.1, paragraph #7.4.11-7.4.12" ::= { xdsl2LineInventoryEntry 7 } ------------------------------------------------ -- xdsl2LineConfTemplateTable -- ------------------------------------------------ xdsl2LineConfTemplateTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineConfTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineConfTemplateTable contains VDSL2/ADSL/ ADSL2 and ADSL2+ line configuration templates. Note that this table is also used to configure the number of bearer channels. When the number of bearer channels is increased, the SNMP agent SHOULD create rows in all tables indexed by a channel index. When the number of bearer channels is decreased, the SNMP agent SHOULD delete rows in all tables indexed by a channel index. For example, if the value of xdsl2LConfTempChan4ConfProfile is set to a non-null value, then rows SHOULD be created in xdsl2ChannelStatusTable, xdsl2PMChCurrTable, and all other tables indexed by a channel index. Morgenstern, et al. Standards Track [Page 100] RFC 5650 VDSL2-LINE MIB September 2009 For example, if the value of xdsl2LConfTempChan2ConfProfile is set to a null value, then rows SHOULD be deleted in xdsl2ChannelStatusTable, xdsl2PMChCurrTable, and all other tables indexed by a channel index. Entries in this table MUST be maintained in a persistent manner." ::= { xdsl2ProfileLine 1 } xdsl2LineConfTemplateEntry OBJECT-TYPE SYNTAX Xdsl2LineConfTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A default template with an index of 'DEFVAL' will always exist, and its parameters will be set to vendor-specific values, unless otherwise specified in this document." INDEX { xdsl2LConfTempTemplateName } ::= { xdsl2LineConfTemplateTable 1 } Xdsl2LineConfTemplateEntry ::= SEQUENCE { xdsl2LConfTempTemplateName SnmpAdminString, xdsl2LConfTempLineProfile SnmpAdminString, xdsl2LConfTempChan1ConfProfile SnmpAdminString, xdsl2LConfTempChan1RaRatioDs Unsigned32, xdsl2LConfTempChan1RaRatioUs Unsigned32, xdsl2LConfTempChan2ConfProfile SnmpAdminString, xdsl2LConfTempChan2RaRatioDs Unsigned32, xdsl2LConfTempChan2RaRatioUs Unsigned32, xdsl2LConfTempChan3ConfProfile SnmpAdminString, xdsl2LConfTempChan3RaRatioDs Unsigned32, xdsl2LConfTempChan3RaRatioUs Unsigned32, xdsl2LConfTempChan4ConfProfile SnmpAdminString, xdsl2LConfTempChan4RaRatioDs Unsigned32, xdsl2LConfTempChan4RaRatioUs Unsigned32, xdsl2LConfTempRowStatus RowStatus } xdsl2LConfTempTemplateName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table." REFERENCE "DSL Forum TR-129, paragraph #5.4" ::= { xdsl2LineConfTemplateEntry 1 } Morgenstern, et al. Standards Track [Page 101] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfTempLineProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL2/ADSL/ADSL2 and ADSL2+ line configuration Profile Table (xdsl2LineConfProfTable) that applies for this DSL line." REFERENCE "DSL Forum TR-129, paragraph #5.4" DEFVAL { "DEFVAL" } ::= { xdsl2LineConfTemplateEntry 2 } xdsl2LConfTempChan1ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL bearer channel #1. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChConfProfileTable table." DEFVAL { "DEFVAL" } ::= { xdsl2LineConfTemplateEntry 3 } xdsl2LConfTempChan1RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #1 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan1RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 100 } ::= { xdsl2LineConfTemplateEntry 4 } xdsl2LConfTempChan1RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" Morgenstern, et al. Standards Track [Page 102] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #1 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan1RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 100 } ::= { xdsl2LineConfTemplateEntry 5 } xdsl2LConfTempChan2ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL bearer channel #2. If the channel is unused, then the object is set to a zero-length string. This object may be set to a zero-length string only if xdsl2LConfTempChan3ConfProfile contains a zero-length string." DEFVAL { "" } ::= { xdsl2LineConfTemplateEntry 6 } xdsl2LConfTempChan2RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #2 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan2RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to Morgenstern, et al. Standards Track [Page 103] RFC 5650 VDSL2-LINE MIB September 2009 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 0 } ::= { xdsl2LineConfTemplateEntry 7 } xdsl2LConfTempChan2RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #2 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan2RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 0 } ::= { xdsl2LineConfTemplateEntry 8 } xdsl2LConfTempChan3ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL bearer channel #3. If the channel is unused, then the object is set to a zero-length string. This object may be set to a zero-length string only if xdsl2LConfTempChan4ConfProfile contains a zero-length string. This object may be set to a non-zero-length string only if xdsl2LConfTempChan2ConfProfile contains a non-zero-length string." DEFVAL { "" } ::= { xdsl2LineConfTemplateEntry 9 } xdsl2LConfTempChan3RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create Morgenstern, et al. Standards Track [Page 104] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #3 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan3RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels on Downstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 0 } ::= { xdsl2LineConfTemplateEntry 10 } xdsl2LConfTempChan3RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #3 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan3RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels on Upstream direction. The sum of rate adaptation ratios over all bearers on the same direction shall be equal to 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 0 } ::= { xdsl2LineConfTemplateEntry 11 } xdsl2LConfTempChan4ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL2/ ADSL/ADSL2 and ADSL2+ channel configuration Profile Table (xdsl2ChConfProfileTable) that applies to DSL bearer channel #4. If the channel is unused, then the object is set to a zero-length string. This object may be set to a non-zero-length string only if xdsl2LConfTempChan3ConfProfile contains a non-zero-length Morgenstern, et al. Standards Track [Page 105] RFC 5650 VDSL2-LINE MIB September 2009 string." DEFVAL { "" } ::= { xdsl2LineConfTemplateEntry 12 } xdsl2LConfTempChan4RaRatioDs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #4 when performing rate adaptation on Downstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan4RaRatioDs is the ratio of excess data rate to be assigned to all other bearer channels. The sum of rate adaptation ratios over all bearers on the same direction shall sum to 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 0 } ::= { xdsl2LineConfTemplateEntry 13 } xdsl2LConfTempChan4RaRatioUs OBJECT-TYPE SYNTAX Unsigned32(0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "Rate Adaptation Ratio. The ratio (in percent) that should be taken into account for the bearer channel #4 when performing rate adaptation on Upstream. The ratio refers to the available data rate in excess of the Minimum Data Rate, summed over all bearer channels. Also, the 100 - xdsl2LConfTempChan4RaRatioUs is the ratio of excess data rate to be assigned to all other bearer channels. The sum of rate adaptation ratios over all bearers on the same direction shall sum to 100%." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.4 (Rate adaptation ratio)" DEFVAL { 0 } ::= { xdsl2LineConfTemplateEntry 14 } xdsl2LConfTempRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Morgenstern, et al. Standards Track [Page 106] RFC 5650 VDSL2-LINE MIB September 2009 DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. A template is activated by setting this object to 'active'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated lines. A row in this table is said to be unreferenced when there is no instance of xdsl2LineConfTemplate or xdsl2LineConfFallbackTemplate that refers to the row." ::= { xdsl2LineConfTemplateEntry 15 } ------------------------------------------ -- xdsl2LineConfProfTable -- ------------------------------------------ xdsl2LineConfProfTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineConfProfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineConfProfTable contains VDSL2/ADSL/ ADSL2 and ADSL2+ line configuration profiles. Entries in this table MUST be maintained in a persistent manner." ::= { xdsl2ProfileLine 2 } xdsl2LineConfProfEntry OBJECT-TYPE SYNTAX Xdsl2LineConfProfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A default profile with an index of 'DEFVAL' will always exist, and its parameters will be set to vendor-specific values, unless otherwise specified in this document." INDEX { xdsl2LConfProfProfileName } ::= { xdsl2LineConfProfTable 1 } Xdsl2LineConfProfEntry ::= SEQUENCE { xdsl2LConfProfProfileName SnmpAdminString, xdsl2LConfProfScMaskDs Xdsl2ScMaskDs, xdsl2LConfProfScMaskUs Xdsl2ScMaskUs, xdsl2LConfProfVdsl2CarMask Xdsl2CarMask, xdsl2LConfProfRfiBands Xdsl2RfiBands, xdsl2LConfProfRaModeDs Xdsl2RaMode, xdsl2LConfProfRaModeUs Xdsl2RaMode, Morgenstern, et al. Standards Track [Page 107] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfProfRaUsNrmDs Unsigned32, xdsl2LConfProfRaUsNrmUs Unsigned32, xdsl2LConfProfRaUsTimeDs Unsigned32, xdsl2LConfProfRaUsTimeUs Unsigned32, xdsl2LConfProfRaDsNrmDs Unsigned32, xdsl2LConfProfRaDsNrmUs Unsigned32, xdsl2LConfProfRaDsTimeDs Unsigned32, xdsl2LConfProfRaDsTimeUs Unsigned32, xdsl2LConfProfTargetSnrmDs Unsigned32, xdsl2LConfProfTargetSnrmUs Unsigned32, xdsl2LConfProfMaxSnrmDs Unsigned32, xdsl2LConfProfMaxSnrmUs Unsigned32, xdsl2LConfProfMinSnrmDs Unsigned32, xdsl2LConfProfMinSnrmUs Unsigned32, xdsl2LConfProfMsgMinUs Unsigned32, xdsl2LConfProfMsgMinDs Unsigned32, xdsl2LConfProfCeFlag Xdsl2LineCeFlag, xdsl2LConfProfSnrModeDs Xdsl2LineSnrMode, xdsl2LConfProfSnrModeUs Xdsl2LineSnrMode, xdsl2LConfProfTxRefVnDs Xdsl2LineTxRefVnDs, xdsl2LConfProfTxRefVnUs Xdsl2LineTxRefVnUs, xdsl2LConfProfXtuTransSysEna Xdsl2TransmissionModeType, xdsl2LConfProfPmMode Xdsl2LinePmMode, xdsl2LConfProfL0Time Unsigned32, xdsl2LConfProfL2Time Unsigned32, xdsl2LConfProfL2Atpr Unsigned32, xdsl2LConfProfL2Atprt Unsigned32, xdsl2LConfProfProfiles Xdsl2LineProfiles, xdsl2LConfProfDpboEPsd Xdsl2PsdMaskDs, xdsl2LConfProfDpboEsEL Unsigned32, xdsl2LConfProfDpboEsCableModelA Unsigned32, xdsl2LConfProfDpboEsCableModelB Unsigned32, xdsl2LConfProfDpboEsCableModelC Unsigned32, xdsl2LConfProfDpboMus Unsigned32, xdsl2LConfProfDpboFMin Unsigned32, xdsl2LConfProfDpboFMax Unsigned32, xdsl2LConfProfUpboKL Unsigned32, xdsl2LConfProfUpboKLF Xdsl2UpboKLF, xdsl2LConfProfUs0Mask Xdsl2LineUs0Mask, xdsl2LConfProfForceInp TruthValue, xdsl2LConfProfRowStatus RowStatus } xdsl2LConfProfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 108] RFC 5650 VDSL2-LINE MIB September 2009 "This object identifies a row in this table." ::= { xdsl2LineConfProfEntry 1 } xdsl2LConfProfScMaskDs OBJECT-TYPE SYNTAX Xdsl2ScMaskDs MAX-ACCESS read-create STATUS current DESCRIPTION "Subcarrier mask. A bitmap of 4096 bits that allows masking up to 4096 downstream subcarriers. If bit i (0 <= i < NSCds) is set to '1', the respective downstream subcarrier is masked, and if set to '0', the respective subcarrier is unmasked. Note that there should always be unmasked subcarriers (i.e., this object cannot be all 1's). Also note that if NSCds < 4096, all bits i (NSCds < i <= 4096) should be set to '1'." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.6 (CARMASKds)" ::= { xdsl2LineConfProfEntry 2 } xdsl2LConfProfScMaskUs OBJECT-TYPE SYNTAX Xdsl2ScMaskUs MAX-ACCESS read-create STATUS current DESCRIPTION "Subcarrier mask. A bitmap of 4096 bits that allows masking up to 4096 upstream subcarriers. If bit i (0 <= i < NSCus) is set to '1', the respective upstream subcarrier is masked, and if set to '0', the respective subcarrier is unmasked. Note that there should always be unmasked subcarriers (i.e., this object cannot be all 1's). Also note that if NSCus < 4096, all bits i (NSCus < i <= 4096) should be set to '1'." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.7 (CARMASKus)" ::= { xdsl2LineConfProfEntry 3 } xdsl2LConfProfVdsl2CarMask OBJECT-TYPE SYNTAX Xdsl2CarMask MAX-ACCESS read-create STATUS current DESCRIPTION "VDSL2-specific subcarrier mask. This configuration parameter defines the restrictions, additional to the band plan, to determine the set of subcarriers allowed for transmission in both the upstream and downstream directions. The parameter shall describe the not masked subcarriers as one or more frequency bands. Each band is represented by start and stop Morgenstern, et al. Standards Track [Page 109] RFC 5650 VDSL2-LINE MIB September 2009 subcarrier indices with a subcarrier spacing of 4.3125 kHz. The valid range of subcarrier indices runs from 0 to at least the index of the highest allowed subcarrier in both transmission directions among all profiles enabled by the parameter xdsl2LConfProfProfiles. Up to 32 bands may be specified. Other subcarriers shall be masked." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.8 (VDSL2- CARMASK)" ::= { xdsl2LineConfProfEntry 4 } xdsl2LConfProfRfiBands OBJECT-TYPE SYNTAX Xdsl2RfiBands MAX-ACCESS read-create STATUS current DESCRIPTION "For ITU-T Recommendation G.992.5, this configuration parameter defines the subset of downstream PSD mask breakpoints, as specified in xdsl2LConfProfPsdMaskDs (PSDMASKds), that shall be used to notch an RFI band. This subset consists of pairs of consecutive subcarrier indices belonging to breakpoints: [ti; ti + 1], corresponding to the low level of the notch. The specific interpolation around these points is defined in the relevant Recommendations (e.g., ITU-T Recommendation G.992.5). The CO-MIB shall define the RFI notches using breakpoints in xdsl2LConfProfPsdMaskDs (PSDMASKds) as specified in the relevant Recommendations (e.g., ITU-T Recommendation G.992.5). For ITU-T Recommendation G.993.2, this configuration parameter defines the bands where the PSD shall be reduced as specified in #7.2.1.2/G.993.2. Each band shall be represented by a start and stop subcarrier indices with a subcarrier spacing of 4.3125 kHz. Up to 16 bands may be specified. This parameter defines the RFI bands for both the upstream and downstream directions." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.10 (RFIBANDS)" ::= { xdsl2LineConfProfEntry 5 } xdsl2LConfProfRaModeDs OBJECT-TYPE SYNTAX Xdsl2RaMode MAX-ACCESS read-create STATUS current DESCRIPTION "The mode of operation of a rate-adaptive xTU-C in the transmit direction." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.1 (RA-MODEds)" DEFVAL { manual } Morgenstern, et al. Standards Track [Page 110] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2LineConfProfEntry 6 } xdsl2LConfProfRaModeUs OBJECT-TYPE SYNTAX Xdsl2RaMode MAX-ACCESS read-create STATUS current DESCRIPTION "The mode of operation of a rate-adaptive xTU-R in the transmit direction." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.2 (RA-MODEus)" DEFVAL { manual } ::= { xdsl2LineConfProfEntry 7 } xdsl2LConfProfRaUsNrmDs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The Downstream Up-Shift Noise Margin value, to be used when xdsl2LConfProfRaModeDs is set to 'dynamicRa'. If the downstream noise margin is above this value, and stays above it, for more than the time specified by the xdsl2LConfProfRaUsTimeDs, the xTU-R shall attempt to increase the downstream net data rate. The Downstream Up-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.3 (RA-USNRMds)" DEFVAL { 10 } ::= { xdsl2LineConfProfEntry 8 } xdsl2LConfProfRaUsNrmUs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The Upstream Up-Shift Noise Margin value, to be used when xdsl2LConfProfRaModeUs is set to 'dynamicRa'. If the upstream noise margin is above this value, and stays above it, for more than the time specified by the xdsl2LConfProfRaUsTimeUs, the xTU-C shall attempt to increase the upstream net data rate. The Upstream Up-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.4 (RA-USNRMus)" DEFVAL { 10 } ::= { xdsl2LineConfProfEntry 9 } Morgenstern, et al. Standards Track [Page 111] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfProfRaUsTimeDs OBJECT-TYPE SYNTAX Unsigned32(0..16383) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Downstream Up-Shift Time Interval, to be used when xdsl2LConfProfRaModeDs is set to 'dynamicRa'. The interval of time that the downstream noise margin should stay above the Downstream Up-Shift Noise Margin before the xTU-R shall attempt to increase the downstream net data rate. The time interval ranges from 0 to 16383 seconds." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.5 (RA-UTIMEds)" DEFVAL { 3600 } ::= { xdsl2LineConfProfEntry 10 } xdsl2LConfProfRaUsTimeUs OBJECT-TYPE SYNTAX Unsigned32(0..16383) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Upstream Up-Shift Time Interval, to be used when xdsl2LConfProfRaModeUs is set to 'dynamicRa'. The interval of time the upstream noise margin should stay above the Upstream Up-Shift Noise Margin before the xTU-C shall attempt to increase the upstream net data rate. The time interval ranges from 0 to 16383 seconds." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.6 (RA-UTIMEus)" DEFVAL { 3600 } ::= { xdsl2LineConfProfEntry 11 } xdsl2LConfProfRaDsNrmDs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The Downstream Down-Shift Noise Margin value, to be used when xdsl2LConfProfRaModeDs is set to 'dynamicRa'. If the downstream noise margin is below this value and stays below that value, for more than the time specified by the xdsl2LConfProfRaDsTimeDs, the xTU-R shall attempt to decrease the downstream net data rate. The Downstream Down-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.7 (RA-DSNRMds)" DEFVAL { 10 } Morgenstern, et al. Standards Track [Page 112] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2LineConfProfEntry 12 } xdsl2LConfProfRaDsNrmUs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The Upstream Downshift Noise Margin value, to be used when xdsl2LConfProfRaModeUs is set to 'dynamicRa'. If the upstream noise margin is below this value and stays below that value, for more than the time specified by the xdsl2LConfProfRaDsTimeUs, the xTU-C shall attempt to decrease the upstream net data rate. The Upstream Down-Shift Noise Margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.8 (RA-DSNRMus)" DEFVAL { 10 } ::= { xdsl2LineConfProfEntry 13 } xdsl2LConfProfRaDsTimeDs OBJECT-TYPE SYNTAX Unsigned32(0..16383) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Downstream Downshift Time Interval, to be used when xdsl2LConfProfRaModeDs is set to 'dynamicRa'. The interval of time the downstream noise margin should stay below the Downstream Down-Shift Noise Margin before the xTU-R shall attempt to decrease the downstream net data rate. The time interval ranges from 0 to 16383 seconds." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.9 (RA-DTIMEds)" DEFVAL { 3600 } ::= { xdsl2LineConfProfEntry 14 } xdsl2LConfProfRaDsTimeUs OBJECT-TYPE SYNTAX Unsigned32(0..16383) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Upstream Down-Shift Time Interval, to be used when xdsl2LConfProfRaModeUs is set to 'dynamicRa'. The interval of time the upstream noise margin should stay below the Upstream Down-Shift Noise Margin before the xTU-C shall attempt to decrease the upstream net data rate. The time interval ranges from 0 to 16383 seconds." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.4.10 (RA-DTIMEus)" Morgenstern, et al. Standards Track [Page 113] RFC 5650 VDSL2-LINE MIB September 2009 DEFVAL { 3600 } ::= { xdsl2LineConfProfEntry 15 } xdsl2LConfProfTargetSnrmDs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum Noise Margin the xTU-R receiver shall achieve, relative to the BER requirement for each of the downstream bearer channels, to successfully complete initialization. The target noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.3.1 (TARSNRMds)" DEFVAL { 60 } ::= { xdsl2LineConfProfEntry 16 } xdsl2LConfProfTargetSnrmUs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum Noise Margin the xTU-C receiver shall achieve, relative to the BER requirement for each of the upstream bearer channels, to successfully complete initialization. The target noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.3.2 (TARSNRMus)" DEFVAL { 60 } ::= { xdsl2LineConfProfEntry 17 } xdsl2LConfProfMaxSnrmDs OBJECT-TYPE SYNTAX Unsigned32 (0..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum Noise Margin the xTU-R receiver shall try to sustain. If the Noise Margin is above this level, the xTU-R shall request that the xTU-C reduce the xTU-C transmit power to get a noise margin below this limit (if this functionality is supported). The maximum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0x7FFFFFFF (2147483647) means that there is no maximum." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.3.3 (MAXSNRMds)" DEFVAL { 310 } Morgenstern, et al. Standards Track [Page 114] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2LineConfProfEntry 18 } xdsl2LConfProfMaxSnrmUs OBJECT-TYPE SYNTAX Unsigned32 (0..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum Noise Margin the xTU-C receiver shall try to sustain. If the Noise Margin is above this level, the xTU-C shall request that the xTU-R reduce the xTU-R transmit power to get a noise margin below this limit (if this functionality is supported). The maximum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0x7FFFFFFF (2147483647) means that there is no maximum." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.3.4 (MAXSNRMus)" DEFVAL { 310 } ::= { xdsl2LineConfProfEntry 19 } xdsl2LConfProfMinSnrmDs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum Noise Margin the xTU-R receiver shall tolerate. If the noise margin falls below this level, the xTU-R shall request that the xTU-C increase the xTU-C transmit power. If an increase to xTU-C transmit power is not possible, a loss- of-margin (LOM) defect occurs, the xTU-R shall fail and attempt to reinitialize and the NMS shall be notified. The minimum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0 means that there is no minimum." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.3.5 (MINSNRMds)" DEFVAL { 10 } ::= { xdsl2LineConfProfEntry 20 } xdsl2LConfProfMinSnrmUs OBJECT-TYPE SYNTAX Unsigned32(0..310) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum Noise Margin the xTU-C receiver shall tolerate. If the noise margin falls below this level, the xTU-C shall request that the xTU-R increase the xTU-R transmit power. If an increase of xTU-R transmit power is not possible, a loss- of-margin (LOM) defect occurs, the xTU-C shall fail and attempt Morgenstern, et al. Standards Track [Page 115] RFC 5650 VDSL2-LINE MIB September 2009 to re-initialize and the NMS shall be notified. The minimum noise margin ranges from 0 to 310 units of 0.1 dB (physical values are 0 to 31 dB). A value of 0 means that there is no minimum." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.3.6 (MINSNRMus)" DEFVAL { 10 } ::= { xdsl2LineConfProfEntry 21 } xdsl2LConfProfMsgMinUs OBJECT-TYPE SYNTAX Unsigned32(4000..248000) UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum Overhead Rate Upstream. Defines the minimum rate of the message-based overhead that shall be maintained by the xTU in upstream direction. Expressed in bits per second and ranges from 4000 to 248000 bits/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.5.1 (MSGMINus)" DEFVAL { 4000 } ::= { xdsl2LineConfProfEntry 22 } xdsl2LConfProfMsgMinDs OBJECT-TYPE SYNTAX Unsigned32(4000..248000) UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum Overhead Rate Downstream. Defines the minimum rate of the message-based overhead that shall be maintained by the xTU in the downstream direction. Expressed in bits per second and ranges from 4000 to 248000 bits/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.5.2 (MSGMINds)" DEFVAL { 4000 } ::= { xdsl2LineConfProfEntry 23 } xdsl2LConfProfCeFlag OBJECT-TYPE SYNTAX Xdsl2LineCeFlag MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter is a bit that enables the use of the optional cyclic extension values." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.6.1 (CEFLAG)" DEFVAL { { } } ::= { xdsl2LineConfProfEntry 24 } xdsl2LConfProfSnrModeDs OBJECT-TYPE Morgenstern, et al. Standards Track [Page 116] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX Xdsl2LineSnrMode MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter enables the transmitter-referred virtual noise in the downstream direction." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.7.1 (SNRMODEds)" DEFVAL { virtualNoiseDisabled } ::= { xdsl2LineConfProfEntry 25 } xdsl2LConfProfSnrModeUs OBJECT-TYPE SYNTAX Xdsl2LineSnrMode MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter enables the transmitter-referred virtual noise in the upstream direction." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.7.2 (SNRMODEus)" DEFVAL { virtualNoiseDisabled } ::= { xdsl2LineConfProfEntry 26 } xdsl2LConfProfTxRefVnDs OBJECT-TYPE SYNTAX Xdsl2LineTxRefVnDs MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the downstream transmitter-referred virtual noise. The TXREFVNds shall be specified through a set of breakpoints. Each breakpoint shall consist of a subcarrier index t, with a subcarrier spacing of 4.3125 kHz, and a noise PSD level (expressed in dBm/Hz) at that subcarrier. The set of breakpoints can then be represented as: [(t1,PSD1), (t2, PSD2), ... , (tN, PSDN)]." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.7.3 (TXREFVNds)" ::= { xdsl2LineConfProfEntry 27 } xdsl2LConfProfTxRefVnUs OBJECT-TYPE SYNTAX Xdsl2LineTxRefVnUs MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the upstream transmitter-referred virtual noise. The TXREFVNus shall be specified through a set of breakpoints. Each breakpoint shall consist of a subcarrier index t, with a subcarrier spacing of 4.3125 kHz, and a noise PSD level (expressed in dBm/Hz) at that subcarrier. The set of breakpoints Morgenstern, et al. Standards Track [Page 117] RFC 5650 VDSL2-LINE MIB September 2009 can then be represented as: [(t1, PSD1), (t2, PSD2), ... , (tN, PSDN)]." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.7.4 (TXREFVNus)" ::= { xdsl2LineConfProfEntry 28 } xdsl2LConfProfXtuTransSysEna OBJECT-TYPE SYNTAX Xdsl2TransmissionModeType MAX-ACCESS read-create STATUS current DESCRIPTION "xTU Transmission System Enabling (XTSE). A list of the different coding types enabled in this profile. It is coded in a bitmap representation with 1 or more bits set. A bit set to '1' means that the xTUs may apply the respective coding for the DSL line. A bit set to '0' means that the xTUs cannot apply the respective coding for the ADSL line. All 'reserved' bits should be set to '0'." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.1 (XTSE)" ::= { xdsl2LineConfProfEntry 29 } xdsl2LConfProfPmMode OBJECT-TYPE SYNTAX Xdsl2LinePmMode MAX-ACCESS read-create STATUS current DESCRIPTION "Power management state Enabling (PMMode). Defines the power states the xTU-C or xTU-R may autonomously transition to on this line. This is a set of bits, where any bit with a '1' value means that the xTU is allowed to transit into the respective state and any bit with a '0' value means that the xTU is not allowed to transit into the respective state." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.4 (PMMode)" DEFVAL { { allowTransitionsToIdle, allowTransitionsToLowPower } } ::= { xdsl2LineConfProfEntry 30 } xdsl2LConfProfL0Time OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum time (in seconds) between an Exit from the L2 state and the next Entry into the L2 state. It ranges from 0 to 255 seconds." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.5 (L0-TIME)" DEFVAL { 255 } ::= { xdsl2LineConfProfEntry 31 } Morgenstern, et al. Standards Track [Page 118] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfProfL2Time OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum time (in seconds) between an Entry into the L2 state and the first Power Trim in the L2 state and between two consecutive Power Trims in the L2 state. It ranges from 0 to 255 seconds." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.6 (L2-TIME)" DEFVAL { 255 } ::= { xdsl2LineConfProfEntry 32 } xdsl2LConfProfL2Atpr OBJECT-TYPE SYNTAX Unsigned32 (0..31) UNITS "dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum aggregate transmit power reduction (in dB) that can be performed at transition of L0 to L2 state or through a single Power Trim in the L2 state. It ranges from 0 dB to 31 dB." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.7 (L2-ATPR)" DEFVAL { 10 } ::= { xdsl2LineConfProfEntry 33 } xdsl2LConfProfL2Atprt OBJECT-TYPE SYNTAX Unsigned32 (0..31) UNITS "dB" MAX-ACCESS read-create STATUS current DESCRIPTION "The total maximum aggregate transmit power reduction (in dB) that can be performed in an L2 state. This is the sum of all reductions of L2 Requests (i.e., at transition of L0 to L2 state) and Power Trims." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.9 (L2-ATPRT)" DEFVAL { 31 } ::= { xdsl2LineConfProfEntry 34 } xdsl2LConfProfProfiles OBJECT-TYPE SYNTAX Xdsl2LineProfiles MAX-ACCESS read-create STATUS current DESCRIPTION "The configuration parameter contains the G.993.2 profiles Morgenstern, et al. Standards Track [Page 119] RFC 5650 VDSL2-LINE MIB September 2009 to be allowed by the near-end xTU on this line. It is coded in a bitmap representation (0 if not allowed, 1 if allowed)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.11 (PROFILES)" DEFVAL { { profile8a, profile8b, profile8c, profile8d, profile12a, profile12b, profile17a, profile30a } } ::= { xdsl2LineConfProfEntry 35 } xdsl2LConfProfDpboEPsd OBJECT-TYPE SYNTAX Xdsl2PsdMaskDs MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the PSD mask that is assumed to be permitted at the exchange. This parameter shall use the same format as xdsl2LConfProfPsdMaskDs (PSDMASKds). The maximum number of breakpoints for xdsl2LConfProfDpboEPsd is 16." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOEPSD)" ::= { xdsl2LineConfProfEntry 36 } xdsl2LConfProfDpboEsEL OBJECT-TYPE SYNTAX Unsigned32 (0..511) UNITS "0.5 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the assumed electrical length of cables (E-side cables) connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this length. The electrical length is defined as the loss (in dB) of an equivalent length of hypothetical cable at a reference frequency defined by the network operator or in spectrum management regulations. This parameter shall be coded as an unsigned integer representing an electrical length from 0 dB (coded as 0) to 255.5 dB (coded as 511) in steps of 0.5 dB. All values in the range are valid. If this parameter is set to '0', the DPBO shall be disabled." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOESEL)" DEFVAL { 0 } ::= { xdsl2LineConfProfEntry 37 } xdsl2LConfProfDpboEsCableModelA OBJECT-TYPE SYNTAX Unsigned32 (0..640) UNITS "2^-8" MAX-ACCESS read-create Morgenstern, et al. Standards Track [Page 120] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "The E-side Cable Model parameter A (DPBOESCMA) of the cable model (DPBOESCM) for cables connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this value. The cable model is in terms of three scalars xdsl2LConfProfDpboEsCableModelA (DPBOESCMA), xdsl2LConfProfDpboEsCableModelB(DPBOESCMB), and xdsl2LConfProfDpboEsCableModelC (DPBOESCMC), that are used to estimate the frequency dependent loss of E-side cables calculated from the xdsl2LConfProfDpboEsEL (DPBOESEL) parameter. Possible values shall be coded as unsigned integers representing a scalar value from -1 (coded as 0) to 1.5 (coded as 640) in steps of 2^-8. All values in the range are valid. This parameter is used only for G.993.2." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOESCMA)" DEFVAL { 0 } ::= { xdsl2LineConfProfEntry 38 } xdsl2LConfProfDpboEsCableModelB OBJECT-TYPE SYNTAX Unsigned32 (0..640) UNITS "2^-8" MAX-ACCESS read-create STATUS current DESCRIPTION "The E-side Cable Model parameter B (DPBOESCMB) of the cable model (DPBOESCM) for cables connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this value. The cable model is in terms of three scalars dsl2LConfProfDpboEsCableModelA (DPBOESCMA), xdsl2LConfProfDpboEsCableModelB(DPBOESCMB), and xdsl2LConfProfDpboEsCableModelC (DPBOESCMC), that are used to estimate the frequency dependent loss of E-side cables calculated from the xdsl2LConfProfDpboEsEL (DPBOESEL) parameter. Possible values shall be coded as unsigned integers representing a scalar value from -1 (coded as 0) to 1.5 (coded as 640) in steps of 2^-8. All values in the range are valid. This parameter is used only for G.993.2." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOESCMB)" DEFVAL { 0 } ::= { xdsl2LineConfProfEntry 39 } xdsl2LConfProfDpboEsCableModelC OBJECT-TYPE SYNTAX Unsigned32 (0..640) Morgenstern, et al. Standards Track [Page 121] RFC 5650 VDSL2-LINE MIB September 2009 UNITS "2^-8" MAX-ACCESS read-create STATUS current DESCRIPTION "The E-side Cable Model parameter C (DPBOESCMC) of the cable model (DPBOESCM) for cables connecting exchange-based DSL services to a remote flexibility point (cabinet), that hosts the xTU-C that is subject to spectrally shaped downstream power back- off (DPBO) depending on this value. The cable model is in terms of three scalars xdsl2LConfProfDpboEsCableModelA (DPBOESCMA), xdsl2LConfProfDpboEsCableModelB(DPBOESCMB), and xdsl2LConfProfDpboEsCableModelC (DPBOESCMC), that are used to estimate the frequency dependent loss of E-side cables calculated from the xdsl2LConfProfDpboEsEL (DPBOESEL) parameter. Possible values shall be coded as unsigned integers representing a scalar value from -1 (coded as 0) to 1.5 (coded as 640) in steps of 2^-8. All values in the range are valid. This parameter is used only for G.993.2." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOESCMC)" DEFVAL { 0 } ::= { xdsl2LineConfProfEntry 40 } xdsl2LConfProfDpboMus OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "0.5 dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the assumed Minimum Usable receive PSD mask (in dBm/Hz) for exchange-based services, used to modify parameter xdsl2LConfProfDpboFMax (DPBOFMAX) defined below (to determine the DPBO). It shall be coded as an unsigned integer representing a PSD mask level from 0 dBm/Hz (coded as 0) to -127.5 dBm/Hz (coded as 255) in steps of 0.5 dBm/Hz. All values in the range are valid. NOTE - The PSD mask level is 3.5 dB above the signal PSD level. This parameter is used only for G.993.2." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOMUS)" DEFVAL { 0 } ::= { xdsl2LineConfProfEntry 41 } xdsl2LConfProfDpboFMin OBJECT-TYPE SYNTAX Unsigned32 (0..2048) UNITS "4.3125 kHz" MAX-ACCESS read-create STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 122] RFC 5650 VDSL2-LINE MIB September 2009 "This configuration parameter defines the minimum frequency from which the DPBO shall be applied. It ranges from 0 kHz (coded as 0) to 8832 kHz (coded as 2048) in steps of 4.3125 kHz. This parameter is used only for G.993.2." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOFMIN)" DEFVAL { 32 } ::= { xdsl2LineConfProfEntry 42 } xdsl2LConfProfDpboFMax OBJECT-TYPE SYNTAX Unsigned32 (32..6956) UNITS "4.3125 kHz" MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the maximum frequency at which DPBO may be applied. It ranges from 138 kHz (coded as 32) to 29997.75 kHz (coded as 6956) in steps of 4.3125 kHz. This parameter is used only for G.993.2." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.13 (DPBOFMAX)" DEFVAL { 512 } ::= { xdsl2LineConfProfEntry 43 } xdsl2LConfProfUpboKL OBJECT-TYPE SYNTAX Unsigned32 (0..1280) UNITS "0.1 dB" MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the electrical length expressed in dB at 1 MHz, kl0, configured by the CO-MIB. The value ranges from 0 (coded as 0) to 128 dB (coded as 1280) in steps of 0.1 dB. This parameter is relevant only if xdsl2LConfProfUpboKLF is set to 'override(2)', which indicates that this parameter's value will override the VTUs' determination of the electrical length. If xdsl2LConfProfUpboKLF is set either to auto(1) or disableUpbo(3), then this parameter will be ignored." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.14 (UPBOKL)" DEFVAL { 0 } ::= { xdsl2LineConfProfEntry 44 } xdsl2LConfProfUpboKLF OBJECT-TYPE SYNTAX Xdsl2UpboKLF MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the upstream power backoff force mode." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.14 (UPBOKLF) Morgenstern, et al. Standards Track [Page 123] RFC 5650 VDSL2-LINE MIB September 2009 " DEFVAL { disableUpbo } ::= { xdsl2LineConfProfEntry 45 } xdsl2LConfProfUs0Mask OBJECT-TYPE SYNTAX Xdsl2LineUs0Mask MAX-ACCESS read-create STATUS current DESCRIPTION "The configuration parameter contains the US0 PSD masks to be allowed by the near-end xTU on the line. This parameter is only defined for G.993.2 Annex A. It is represented as a bitmap (0 if not allowed and 1 if allowed)." REFERENCE "ITU-T G.997.1 Amendment 1, paragraph #7.3.1.2.18 (US0MASK)" DEFVAL { {} } ::= { xdsl2LineConfProfEntry 46 } xdsl2LConfProfForceInp OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter, when set to 'true' indicates that the framer settings of the bearer shall be selected such that the impulse noise protection computed according to the formula specified in the relevant Recommendation is greater than or equal to the minimal impulse noise protection requirement. This flag shall have the same value for all the bearers of one line in the same direction." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.5 (FORCEINP)" DEFVAL { false } ::= { xdsl2LineConfProfEntry 47 } xdsl2LConfProfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all templates. Morgenstern, et al. Standards Track [Page 124] RFC 5650 VDSL2-LINE MIB September 2009 A row in this table is said to be unreferenced when there is no instance of xdsl2LConfTempLineProfile that refers to the row. When a row is created in this table, the SNMP agent should also create corresponding rows in the tables xdsl2LineConfProfModeSpecTable and xdsl2LineConfProfModeSpecBandUsTable. When a row is deleted in this table, the SNMP agent should also delete corresponding rows in the tables xdsl2LineConfProfModeSpecTable and xdsl2LineConfProfModeSpecBandUsTable." ::= { xdsl2LineConfProfEntry 48 } ------------------------------------------ -- xdsl2LineConfProfModeSpecTable -- ------------------------------------------ xdsl2LineConfProfModeSpecTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineConfProfModeSpecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineConfProfModeSpecTable extends the DSL line configuration profile by xDSL Mode-Specific parameters. A row in this table that has an index of xdsl2LConfProfXdslMode == defMode(1), is called a 'mandatory' row or 'default' row. A row in this table that has an index such that xdsl2LConfProfXdslMode is not equal to defMode(1), is called an 'optional' row or 'mode-specific' row. When a row in the xdsl2LineConfProfTable table (the parent row) is created, the SNMP agent will automatically create a 'mandatory' row in this table. When the parent row is deleted, the SNMP agent will automatically delete all associated rows in this table. Any attempt to delete the 'mandatory' row using the xdsl2LConfProfModeSpecRowStatus object will be rejected by the SNMP agent. The manager MAY create an 'optional' row in this table using the xdsl2LConfProfModeSpecRowStatus object if the parent row exists. The manager MAY delete an 'optional' row in this table using the xdsl2LConfProfModeSpecRowStatus object at any time. If the actual transmission mode of a DSL line does not match one of the 'optional' rows in this table, then the line will use the PSD configuration from the 'mandatory' row. Entries in this table MUST be maintained in a persistent manner." Morgenstern, et al. Standards Track [Page 125] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2ProfileLine 3 } xdsl2LineConfProfModeSpecEntry OBJECT-TYPE SYNTAX Xdsl2LineConfProfModeSpecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineConfProfModeSpecTable extends the DSL line configuration profile by DSL Mode-Specific parameters." INDEX { xdsl2LConfProfProfileName, xdsl2LConfProfXdslMode } ::= { xdsl2LineConfProfModeSpecTable 1 } Xdsl2LineConfProfModeSpecEntry ::= SEQUENCE { xdsl2LConfProfXdslMode Xdsl2OperationModes, xdsl2LConfProfMaxNomPsdDs Integer32, xdsl2LConfProfMaxNomPsdUs Integer32, xdsl2LConfProfMaxNomAtpDs Unsigned32, xdsl2LConfProfMaxNomAtpUs Unsigned32, xdsl2LConfProfMaxAggRxPwrUs Integer32, xdsl2LConfProfPsdMaskDs Xdsl2PsdMaskDs, xdsl2LConfProfPsdMaskUs Xdsl2PsdMaskUs, xdsl2LConfProfPsdMaskSelectUs Xdsl2LinePsdMaskSelectUs, xdsl2LConfProfClassMask Xdsl2LineClassMask, xdsl2LConfProfLimitMask Xdsl2LineLimitMask, xdsl2LConfProfUs0Disable Xdsl2LineUs0Disable, xdsl2LConfProfModeSpecRowStatus RowStatus } xdsl2LConfProfXdslMode OBJECT-TYPE SYNTAX Xdsl2OperationModes MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DSL Mode is a way of categorizing the various xDSL transmission modes into groups, each group (xDSL Mode) shares the same PSD configuration. There should be multiple entries in this table for a given line profile in case multiple bits are set in xdsl2LConfProfXtuTransSysEna for that profile." REFERENCE "DSL Forum TR-129, paragraph #5.5" ::= { xdsl2LineConfProfModeSpecEntry 1 } xdsl2LConfProfMaxNomPsdDs OBJECT-TYPE SYNTAX Integer32(-600..-300) UNITS "0.1 dBm/Hz" MAX-ACCESS read-create Morgenstern, et al. Standards Track [Page 126] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "The maximum nominal transmit PSD in the downstream direction during initialization and Showtime. It ranges from -600 to -300 units of 0.1 dBm/Hz (physical values are -60 to -30 dBm/Hz)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.1 (MAXNOMPSDds)" DEFVAL { -300 } ::= { xdsl2LineConfProfModeSpecEntry 2 } xdsl2LConfProfMaxNomPsdUs OBJECT-TYPE SYNTAX Integer32(-600..-300) UNITS "0.1 dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum nominal transmit PSD in the upstream direction during initialization and Showtime. It ranges from -600 to -300 units of 0.1 dBm/Hz (physical values are -60 to -30 dBm/Hz)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.2 (MAXNOMPSDus)" DEFVAL { -300 } ::= { xdsl2LineConfProfModeSpecEntry 3 } xdsl2LConfProfMaxNomAtpDs OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "0.1 dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum nominal aggregate to transmit power in the downstream direction during initialization and Showtime. It ranges from 0 to 255 units of 0.1 dBm (physical values are 0 to 25.5 dBm)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.3 (MAXNOMATPds)" DEFVAL { 255 } ::= { xdsl2LineConfProfModeSpecEntry 4 } xdsl2LConfProfMaxNomAtpUs OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "0.1 dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum nominal aggregate transmit power in the upstream direction during initialization and Showtime. It ranges from 0 to 255 units of 0.1 dBm (physical values are 0 to 25.5 dBm)." Morgenstern, et al. Standards Track [Page 127] RFC 5650 VDSL2-LINE MIB September 2009 REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.4 (MAXNOMATPus)" DEFVAL { 255 } ::= { xdsl2LineConfProfModeSpecEntry 5 } xdsl2LConfProfMaxAggRxPwrUs OBJECT-TYPE SYNTAX Integer32(-255..255 | 2147483647) UNITS "0.1 dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum upstream aggregate receive power over the relevant set of subcarriers. The xTU-C should verify that the upstream power cutback is such that this maximum aggregate receive power value is honored. It ranges from -255 to 255 units of 0.1 dBm (physical values are -25.5 to 25.5 dBm). A value of 0x7FFFFFFF (2147483647) means that there is no limit." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.5 (MAXRXPWRus)" DEFVAL { 255 } ::= { xdsl2LineConfProfModeSpecEntry 6 } xdsl2LConfProfPsdMaskDs OBJECT-TYPE SYNTAX Xdsl2PsdMaskDs MAX-ACCESS read-create STATUS current DESCRIPTION "The downstream PSD mask applicable at the U-C2 reference point. This parameter is used only for G.992.5 and it may impose PSD restrictions (breakpoints) in addition to the Limit PSD mask defined in G.992.5. This is a string of 32 pairs of values in the following structure: Octets 0-1 - Index of the first subcarrier used in the context of a first breakpoint. Octet 2 - The PSD reduction for the subcarrier indicated in octets 0 and 1. Octets 3-5 - Same, for a second breakpoint. Octets 6-8 - Same, for a third breakpoint. This architecture continues until octets 94-95, which are associated with a 32nd breakpoint. Each subcarrier index is an unsigned number in the range 0 and NSCds-1. Each PSD reduction value is in the range 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) with steps of 0.5 dBm/Hz. Valid values are in the range 0 to 190 (0 to -95 dBm/Hz). When the number of breakpoints is less than 32, all remaining octets are set to the value '0'. Note that the content of this object should be correlated with the subcarrier mask and with Morgenstern, et al. Standards Track [Page 128] RFC 5650 VDSL2-LINE MIB September 2009 the RFI setup." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.9 (PSDMASKds)" ::= { xdsl2LineConfProfModeSpecEntry 7 } xdsl2LConfProfPsdMaskUs OBJECT-TYPE SYNTAX Xdsl2PsdMaskUs MAX-ACCESS read-create STATUS current DESCRIPTION "The upstream PSD mask applicable at the U-R2 reference point. This parameter is used only for G.992.5, and it may impose PSD restrictions (breakpoints) in addition to the Limit PSD mask defined in G.992.5. This is a string of 16 pairs of values in the following structure: Octets 0-1 - Index of the first subcarrier used in the context of a first breakpoint. Octet 2 - The PSD reduction for the subcarrier indicated in octets 0 and 1. Octets 3-5 - Same, for a second breakpoint. Octets 6-8 - Same, for a third breakpoint. This architecture continues until octets 9-47, which are associated with a 16th breakpoint. Each subcarrier index is an unsigned number in the range 0 and NSCus-1. Each PSD reduction value is in the range 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) with steps of 0.5 dBm/Hz. Valid values are in the range 0 to 190 (0 to -95 dBm/Hz). When the number of breakpoints is less than 16, all remaining octets are set to the value '0'. Note that the content of this object should be correlated with the subcarrier mask and with the RFI setup." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.12 (PSDMASKus)" ::= { xdsl2LineConfProfModeSpecEntry 8 } xdsl2LConfProfPsdMaskSelectUs OBJECT-TYPE SYNTAX Xdsl2LinePsdMaskSelectUs MAX-ACCESS read-create STATUS current DESCRIPTION "The selected upstream PSD mask. This parameter is used only for Annexes J and M of G.992.3 and G.992.5, and the same selection is used for all relevant enabled bits in xdsl2LConfProfXtuTransSysEna." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.11 (Upstream PSD mask selection)" DEFVAL { adlu32Eu32 } ::= { xdsl2LineConfProfModeSpecEntry 9 } Morgenstern, et al. Standards Track [Page 129] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfProfClassMask OBJECT-TYPE SYNTAX Xdsl2LineClassMask MAX-ACCESS read-create STATUS current DESCRIPTION "In order to reduce the number of configuration possibilities, the limit Power Spectral Density masks (see LIMITMASK) are grouped in PSD mask classes. Each class is designed such that the PSD levels of each limit PSD mask of a specific class are equal in their respective passband above 552 kHz. This parameter is defined per VDSL2 Annex enabled in the xdsl2LConfProfXtuTransSysEna object. It selects a single PSD mask class per Annex that is activated at the VTU-O." REFERENCE "ITU-T G.997.1 Amendment 1, paragraph #7.3.1.2.15 (CLASSMASK)" DEFVAL { a998ORb997M1cORc998B } ::= { xdsl2LineConfProfModeSpecEntry 10 } xdsl2LConfProfLimitMask OBJECT-TYPE SYNTAX Xdsl2LineLimitMask MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter contains the G.993.2 limit PSD masks of the selected PSD mask class, enabled by the near-end xTU on this line for each class of profiles. This parameter is defined per VDSL2 Annex enabled in the xdsl2LConfProfXtuTransSysEna object. Through this parameter, several limit PSD masks of the selected PSD mask class (xdsl2LConfProfClassMask) may be enabled. The enabling parameter is coded in a bitmap representation (0 if the associated mask is not allowed, 1 if it is allowed)." REFERENCE "ITU-T G.997.1 Amendment 1, paragraph #7.3.1.2.16 (LIMITMASK)" DEFVAL { {} } ::= { xdsl2LineConfProfModeSpecEntry 11 } xdsl2LConfProfUs0Disable OBJECT-TYPE SYNTAX Xdsl2LineUs0Disable MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter indicates if the use of the US0 is disabled for each limit PSD mask enabled in the xdsl2LConfProfLimitMask parameter. This parameter is defined per VDSL2 Annex enabled in the xdsl2LConfProfXtuTransSysEna object. Morgenstern, et al. Standards Track [Page 130] RFC 5650 VDSL2-LINE MIB September 2009 For each limit PSD mask enabled in the xdsl2LConfProfLimitMask parameter, a bit shall indicate if the US0 is disabled. The disabling parameter is coded as a bitmap. The bit is set to '1' if the US0 is disabled for the associated limit mask. This parameter and the xdsl2LConfProfLimitMask parameter use the same structure." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.17 (US0DISABLE)" DEFVAL { {} } ::= { xdsl2LineConfProfModeSpecEntry 12 } xdsl2LConfProfModeSpecRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. This row is activated by setting this object to 'active'. A 'mandatory' row, as defined in the DESCRIPTION clause of xdsl2LineConfProfModeSpecTable, cannot be deleted at all. A 'mandatory' row can be taken out of service (by setting this object to 'notInService') if the parent row in the xdsl2LineConfProfTable table is not in the 'active' state. An 'optional' row (or 'mode-specific' row) can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService') at any time." ::= { xdsl2LineConfProfModeSpecEntry 13 } ---------------------------------------------- -- xdsl2LineConfProfModeSpecBandUsTable -- ---------------------------------------------- xdsl2LineConfProfModeSpecBandUsTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineConfProfModeSpecBandUsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineConfProfModeSpecBandUsTable extends xdsl2LineConfProfModeSpecTable with upstream-band-specific parameters for VDSL2, such as upstream power back-off parameters xdsl2LConfProfUpboPsdA and xdsl2LConfProfUpboPsdB (UPBOPSD-pb). Morgenstern, et al. Standards Track [Page 131] RFC 5650 VDSL2-LINE MIB September 2009 When a parent 'mandatory row' is created in xdsl2LineConfProfModeSpecTable, the SNMP agent will automatically create several 'mandatory' rows in this table -- one for each upstream band: Note: A mandatory row is one where xdsl2LConfProfXdslMode = defMode(1). When the parent row is deleted, the SNMP agent will automatically delete all associated rows in this table. Any attempt to delete a 'mandatory' row using the xdsl2LConfProfModeSpecBandUsRowStatus object will be rejected by the SNMP agent. The manager MAY create a new 'optional' row in this table using the xdsl2LConfProfModeSpecBandUsRowStatus object if the associated parent row exists, and the value of xdsl2LConfProfXdslMode is a G.993.2 value. The manager MAY delete an 'optional' row in this table using the xdsl2LConfProfModeSpecBandUsRowStatus object at any time. With respect to the xdsl2LConfProfUpboPsdA and xdsl2LConfProfUpboPsdB parameters, for a given upstream band, if an optional row is missing from this table, then that means upstream power back-off is disabled for that upstream band. Entries in this table MUST be maintained in a persistent manner." ::= { xdsl2ProfileLine 4 } xdsl2LineConfProfModeSpecBandUsEntry OBJECT-TYPE SYNTAX Xdsl2LineConfProfModeSpecBandUsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineConfProfModeSpecBandUsTable extends xdsl2LineConfProfModeSpecTable with upstream-band-specific parameters for VDSL2, such as upstream power back-off parameters xdsl2LConfProfUpboPsdA and xdsl2LConfProfUpboPsdB (UPBOPSD- pb)." INDEX { xdsl2LConfProfProfileName, xdsl2LConfProfXdslMode, xdsl2LConfProfXdslBandUs} ::= { xdsl2LineConfProfModeSpecBandUsTable 1 } Xdsl2LineConfProfModeSpecBandUsEntry ::= SEQUENCE { xdsl2LConfProfXdslBandUs Xdsl2BandUs, xdsl2LConfProfUpboPsdA Integer32, xdsl2LConfProfUpboPsdB Integer32, xdsl2LConfProfModeSpecBandUsRowStatus RowStatus } Morgenstern, et al. Standards Track [Page 132] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfProfXdslBandUs OBJECT-TYPE SYNTAX Xdsl2BandUs MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each value identifies a specific band in the upstream transmission direction (excluding the US0 band)." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.14" ::= { xdsl2LineConfProfModeSpecBandUsEntry 1 } xdsl2LConfProfUpboPsdA OBJECT-TYPE SYNTAX Integer32(4000..8095) UNITS "0.01 dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the 'a' reference parameter of the UPBO reference PSD used to compute the upstream power back-off for the upstream band. A UPBO PSD defined for each band shall consist of two parameters [a, b]. Parameter 'a' (xdsl2LConfProfUpboPsdA) ranges from 40 dBm/Hz (coded as 4000) to 80.95 dBm/Hz (coded as 8095) in steps of 0.01 dBm/Hz; and parameter 'b' (xdsl2LConfProfUpboPsdB) ranges from 0 dBm/Hz (coded as 0) to 40.95 dBm/Hz (coded as 4095) in steps of 0.01 dBm/Hz. The UPBO reference PSD at the frequency 'f' expressed in MHz shall be equal to '-a-b(SQRT(f))'. Setting xdsl2LConfProfUpboPsdA to 4000 and xdsl2LConfProfUpboPsdB to 0 is a special configuration to disable UPBO in the respective upstream band." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.14 (UPBOPSD-pb)" DEFVAL { 4000 } ::= { xdsl2LineConfProfModeSpecBandUsEntry 2 } xdsl2LConfProfUpboPsdB OBJECT-TYPE SYNTAX Integer32(0..4095) UNITS "0.01 dBm/Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "This configuration parameter defines the 'b' reference parameter of the UPBO reference PSD used to compute the upstream power back-off for the upstream band. A UPBO PSD defined for each band shall consist of two parameters [a, b]. Parameter 'a' (xdsl2LConfProfUpboPsdA) ranges from 40 dBm/Hz (coded as 4000) to 80.95 dBm/Hz (coded as 8095) in steps of 0.01 dBm/Hz; and parameter 'b' (xdsl2LConfProfUpboPsdB) ranges from 0 dBm/Hz (coded as 0) to 40.95 dBm/Hz (coded as 4095) in steps of 0.01 dBm/Hz. The UPBO reference PSD at the frequency 'f' Morgenstern, et al. Standards Track [Page 133] RFC 5650 VDSL2-LINE MIB September 2009 expressed in MHz shall be equal to '-a-b(SQRT(f))'. Setting xdsl2LConfProfUpboPsdA to 4000 and xdsl2LConfProfUpboPsdB to 0 is a special configuration to disable UPBO in the respective upstream band." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.2.14 (UPBOPSD-pb)" DEFVAL { 0 } ::= { xdsl2LineConfProfModeSpecBandUsEntry 3 } xdsl2LConfProfModeSpecBandUsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. This row is activated by setting this object to 'active'. A 'mandatory' row, as defined in the DESCRIPTION clause of xdsl2LineConfProfModeSpecBandUsTable, cannot be deleted at all. A 'mandatory' row can be taken out of service (by setting this object to 'notInService') if the parent row in the xdsl2LineConfProfModeSpecTable table is not in the 'active' state. An 'optional' row (or 'mode-specific' row) can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService') at any time." ::= { xdsl2LineConfProfModeSpecBandUsEntry 4 } ------------------------------------------------ -- xdsl2ChConfProfileTable -- ------------------------------------------------ xdsl2ChConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2ChConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2ChConfProfileTable contains DSL channel profile configuration. Entries in this table MUST be maintained in a persistent manner." ::= { xdsl2ProfileChannel 1 } xdsl2ChConfProfileEntry OBJECT-TYPE Morgenstern, et al. Standards Track [Page 134] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX Xdsl2ChConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A default profile with an index of 'DEFVAL' will always exist, and its parameters will be set to vendor-specific values, unless otherwise specified in this document." INDEX { xdsl2ChConfProfProfileName } ::= { xdsl2ChConfProfileTable 1 } Xdsl2ChConfProfileEntry ::= SEQUENCE { xdsl2ChConfProfProfileName SnmpAdminString, xdsl2ChConfProfMinDataRateDs Unsigned32, xdsl2ChConfProfMinDataRateUs Unsigned32, xdsl2ChConfProfMinResDataRateDs Unsigned32, xdsl2ChConfProfMinResDataRateUs Unsigned32, xdsl2ChConfProfMaxDataRateDs Unsigned32, xdsl2ChConfProfMaxDataRateUs Unsigned32, xdsl2ChConfProfMinDataRateLowPwrDs Unsigned32, xdsl2ChConfProfMinDataRateLowPwrUs Unsigned32, xdsl2ChConfProfMaxDelayDs Unsigned32, xdsl2ChConfProfMaxDelayUs Unsigned32, xdsl2ChConfProfMinProtectionDs Xdsl2SymbolProtection, xdsl2ChConfProfMinProtectionUs Xdsl2SymbolProtection, xdsl2ChConfProfMinProtection8Ds Xdsl2SymbolProtection8, xdsl2ChConfProfMinProtection8Us Xdsl2SymbolProtection8, xdsl2ChConfProfMaxBerDs Xdsl2MaxBer, xdsl2ChConfProfMaxBerUs Xdsl2MaxBer, xdsl2ChConfProfUsDataRateDs Unsigned32, xdsl2ChConfProfDsDataRateDs Unsigned32, xdsl2ChConfProfUsDataRateUs Unsigned32, xdsl2ChConfProfDsDataRateUs Unsigned32, xdsl2ChConfProfImaEnabled TruthValue, xdsl2ChConfProfMaxDelayVar Unsigned32, xdsl2ChConfProfInitPolicy Xdsl2ChInitPolicy, xdsl2ChConfProfRowStatus RowStatus } xdsl2ChConfProfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table." ::= { xdsl2ChConfProfileEntry 1 } xdsl2ChConfProfMinDataRateDs OBJECT-TYPE Morgenstern, et al. Standards Track [Page 135] RFC 5650 VDSL2-LINE MIB September 2009 SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum Data Rate on Downstream direction. The minimum net data rate for the bearer channel, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.1 (Minimum data rate)" ::= { xdsl2ChConfProfileEntry 2 } xdsl2ChConfProfMinDataRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum Data Rate on Upstream direction. The minimum net data rate for the bearer channel, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.1 (Minimum data rate)" ::= { xdsl2ChConfProfileEntry 3 } xdsl2ChConfProfMinResDataRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum Reserved Data Rate on Downstream direction. The minimum reserved net data rate for the bearer channel, coded in bit/s. This parameter is used only if the Rate Adaptation Mode in the direction of the bearer channel (i.e., xdsl2LConfProfRaModeDs) is set to 'dynamicRa'." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.2 (Minimum reserved data rate)" ::= { xdsl2ChConfProfileEntry 4 } xdsl2ChConfProfMinResDataRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum Reserved Data Rate on Upstream direction. The minimum reserved net data rate for the bearer channel, coded in bit/s. This parameter is used only if the Rate Adaptation Mode in the direction of the bearer channel (i.e., Morgenstern, et al. Standards Track [Page 136] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LConfProfRaModeUs) is set to 'dynamicRa'." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.2 (Minimum reserved data rate)" ::= { xdsl2ChConfProfileEntry 5 } xdsl2ChConfProfMaxDataRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Data Rate on Downstream direction. The maximum net data rate for the bearer channel, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.3 (Maximum data rate)" ::= { xdsl2ChConfProfileEntry 6 } xdsl2ChConfProfMaxDataRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Data Rate on Upstream direction. The maximum net data rate for the bearer channel, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.3 (Maximum data rate)" ::= { xdsl2ChConfProfileEntry 7 } xdsl2ChConfProfMinDataRateLowPwrDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter specifies the minimum net data rate for the bearer channel as desired by the operator of the system during the low power state (L1/L2). The power management low power states L1 and L2 are defined in ITU-T Recommendations G.992.2 and G.992.3, respectively. The data rate is coded in steps of bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.5 (Minimum Data Rate in low power state)" ::= { xdsl2ChConfProfileEntry 8 } xdsl2ChConfProfMinDataRateLowPwrUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" Morgenstern, et al. Standards Track [Page 137] RFC 5650 VDSL2-LINE MIB September 2009 MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter specifies the minimum net data rate for the bearer channel as desired by the operator of the system during the low power state (L1/L2). The power management low power states L1 and L2 are defined in ITU-T Recommendations G.992.2 and G.992.3, respectively. The data rate is coded in steps of bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.1.5 (Minimum Data Rate in low power state)" ::= { xdsl2ChConfProfileEntry 9 } xdsl2ChConfProfMaxDelayDs OBJECT-TYPE SYNTAX Unsigned32(0..63) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Interleave Delay on Downstream direction. The maximum one-way interleaving delay introduced by the PMS-TC on Downstream direction. The xTUs shall choose the S (factor) and D (depth) values such that the actual one-way interleaving delay (Xdsl2ChStatusActDelay) is as close as possible to, but less than or equal to, xdsl2ChConfProfMaxDelayDs. The delay is coded in ms, with the value 0 indicating no delay bound is being imposed." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.2 (Maximum interleaving delay)" ::= { xdsl2ChConfProfileEntry 10 } xdsl2ChConfProfMaxDelayUs OBJECT-TYPE SYNTAX Unsigned32(0..63) UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Interleave Delay on Upstream direction. The maximum one-way interleaving delay introduced by the PMS-TC on Upstream direction. The xTUs shall choose the S (factor) and D (depth) values such that the actual one-way interleaving delay (Xdsl2ChStatusActDelay) is as close as possible to, but less than or equal to, xdsl2ChConfProfMaxDelayUs. The delay is coded in ms, with the value 0 indicating no delay bound is being imposed." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.2 (Maximum interleaving delay)" ::= { xdsl2ChConfProfileEntry 11 } Morgenstern, et al. Standards Track [Page 138] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2ChConfProfMinProtectionDs OBJECT-TYPE SYNTAX Xdsl2SymbolProtection UNITS "symbols" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 4.3125 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 4.3125 kHz and can take the values 1/2 and any integer from 0 to 16, inclusive. If the xTU does not support the configured INPMIN value, it shall use the nearest supported impulse noise protection greater than INPMIN." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.3 (INPMINds)" DEFVAL { noProtection } ::= { xdsl2ChConfProfileEntry 12 } xdsl2ChConfProfMinProtectionUs OBJECT-TYPE SYNTAX Xdsl2SymbolProtection UNITS "symbols" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 4.3125 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 4.3125 kHz and can take the values 1/2 and any integer from 0 to 16, inclusive. If the xTU does not support the configured INPMIN value, it shall use the nearest supported impulse noise protection greater than INPMIN." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.3 (INPMINus)" DEFVAL { noProtection } ::= { xdsl2ChConfProfileEntry 13 } xdsl2ChConfProfMinProtection8Ds OBJECT-TYPE SYNTAX Xdsl2SymbolProtection8 UNITS "symbols" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 8.625 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 8.625 kHz." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.4 (INPMIN8ds)" Morgenstern, et al. Standards Track [Page 139] RFC 5650 VDSL2-LINE MIB September 2009 DEFVAL { noProtection } ::= { xdsl2ChConfProfileEntry 14 } xdsl2ChConfProfMinProtection8Us OBJECT-TYPE SYNTAX Xdsl2SymbolProtection8 UNITS "symbols" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter specifies the minimum impulse noise protection for the bearer channel if it is transported over DMT symbols with a subcarrier spacing of 8.625 kHz. The impulse noise protection is expressed in DMT symbols with a subcarrier spacing of 8.625 kHz." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.4 (INPMIN8us)" DEFVAL { noProtection } ::= { xdsl2ChConfProfileEntry 15 } xdsl2ChConfProfMaxBerDs OBJECT-TYPE SYNTAX Xdsl2MaxBer MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Bit Error Ratio on Downstream direction. The maximum bit error ratio for the bearer channel." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.6 (Maximum bit error ratio)" DEFVAL { eminus5 } ::= { xdsl2ChConfProfileEntry 16 } xdsl2ChConfProfMaxBerUs OBJECT-TYPE SYNTAX Xdsl2MaxBer MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Bit Error Ratio on Upstream direction. The maximum bit error ratio for the bearer channel." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.6 (Maximum bit error ratio)" DEFVAL { eminus5 } ::= { xdsl2ChConfProfileEntry 17 } xdsl2ChConfProfUsDataRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 140] RFC 5650 VDSL2-LINE MIB September 2009 "Data Rate Threshold Upshift for Downstream direction. An 'Up-Shift rate change' event is triggered when the actual downstream data rate exceeds, by more than the threshold, the data rate at the last entry into Showtime. The parameter is coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.8.1 (Data rate threshold upshift)" ::= { xdsl2ChConfProfileEntry 18 } xdsl2ChConfProfDsDataRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Data Rate Threshold Downshift for Downstream direction. A 'Down-Shift rate change' event is triggered when the actual downstream data rate is below the data rate at the last entry into Showtime, by more than the threshold. The parameter is coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.8.2 (Data rate threshold downshift)" ::= { xdsl2ChConfProfileEntry 19 } xdsl2ChConfProfUsDataRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Data Rate Threshold Upshift for Upstream direction. An 'Up-Shift rate change' event is triggered when the actual upstream data rate exceeds, by more than the threshold, the data rate at the last entry into Showtime. The parameter is coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.8.1 (Data rate threshold upshift)" ::= { xdsl2ChConfProfileEntry 20 } xdsl2ChConfProfDsDataRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-create STATUS current DESCRIPTION "Data Rate Threshold Downshift for Upstream direction. A 'Down-Shift rate change' event is triggered when the actual upstream data rate is below the data rate at the last Morgenstern, et al. Standards Track [Page 141] RFC 5650 VDSL2-LINE MIB September 2009 entry into Showtime, by more than the threshold. The parameter is coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.3.2.8.2 (Data rate threshold downshift)" ::= { xdsl2ChConfProfileEntry 21 } xdsl2ChConfProfImaEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "IMA Mode Enable. The parameter enables the IMA operation mode in the ATM Data Path. Relevant only if the channel is of ATM Data Path. When in 'enable' state, the ATM Data Path should comply with the requirements for IMA transmission." REFERENCE "ITU-T G.997.1, paragraph #7.3.4.1 (IMA operation mode enable parameter)" DEFVAL { false } ::= { xdsl2ChConfProfileEntry 22 } xdsl2ChConfProfMaxDelayVar OBJECT-TYPE SYNTAX Unsigned32(1..255) UNITS "0.1 milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum delay variation (DVMAX). This optional VDSL2-specific parameter specifies the maximum value for the delay variation allowed in an OLR procedure. It is ranges from 1 to 254 units of 0.1 milliseconds (i.e., 0.1 to 25.4 milliseconds) with the special value 255, which indicates that no delay variation bound is imposed." REFERENCE "ITU-T G.997.1 Amendment 1, paragraph #7.3.2.9 (DVMAX)" DEFVAL { 255 } ::= { xdsl2ChConfProfileEntry 23 } xdsl2ChConfProfInitPolicy OBJECT-TYPE SYNTAX Xdsl2ChInitPolicy MAX-ACCESS read-create STATUS current DESCRIPTION "Channel Initialization Policy Selection (CIPOLICY). This optional parameter indicates which policy shall be applied to determine the transceiver configuration parameters at initialization. Those policies are defined in the respective Recommendations." Morgenstern, et al. Standards Track [Page 142] RFC 5650 VDSL2-LINE MIB September 2009 REFERENCE "ITU-T G.997.1 Amendment 1, paragraph #7.3.2.10 (CIPOLICY)" DEFVAL { policy0 } ::= { xdsl2ChConfProfileEntry 24 } xdsl2ChConfProfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated templates. A row in xdsl2ChConfProfTable is said to be unreferenced when there is no instance of xdsl2LConfTempChan1ConfProfile, xdsl2LConfTempChan2ConfProfile, xdsl2LConfTempChan3ConfProfile, or xdsl2LConfTempChan4ConfProfile that refers to the row." ::= { xdsl2ChConfProfileEntry 25 } ------------------------------------------------ -- xdsl2LineAlarmConfTemplateTable -- ------------------------------------------------ xdsl2LineAlarmConfTemplateTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineAlarmConfTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineAlarConfTemplateTable contains DSL line alarm configuration templates. Entries in this table MUST be maintained in a persistent manner." ::= { xdsl2ProfileAlarmConf 1 } xdsl2LineAlarmConfTemplateEntry OBJECT-TYPE SYNTAX Xdsl2LineAlarmConfTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A default template with an index of 'DEFVAL' will always Morgenstern, et al. Standards Track [Page 143] RFC 5650 VDSL2-LINE MIB September 2009 exist, and its parameters will be set to vendor-specific values, unless otherwise specified in this document." INDEX { xdsl2LAlarmConfTempTemplateName } ::= { xdsl2LineAlarmConfTemplateTable 1 } Xdsl2LineAlarmConfTemplateEntry ::= SEQUENCE { xdsl2LAlarmConfTempTemplateName SnmpAdminString, xdsl2LAlarmConfTempLineProfile SnmpAdminString, xdsl2LAlarmConfTempChan1ConfProfile SnmpAdminString, xdsl2LAlarmConfTempChan2ConfProfile SnmpAdminString, xdsl2LAlarmConfTempChan3ConfProfile SnmpAdminString, xdsl2LAlarmConfTempChan4ConfProfile SnmpAdminString, xdsl2LAlarmConfTempRowStatus RowStatus } xdsl2LAlarmConfTempTemplateName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table." ::= { xdsl2LineAlarmConfTemplateEntry 1 } xdsl2LAlarmConfTempLineProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the DSL Line Thresholds Configuration Profile Table (xdsl2LineAlarmConfProfileTable) that applies to this line." REFERENCE "DSL Forum TR-129, paragraph #8.2" DEFVAL { "DEFVAL" } ::= { xdsl2LineAlarmConfTemplateEntry 2 } xdsl2LAlarmConfTempChan1ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #1. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable table." REFERENCE "DSL Forum TR-129, paragraph #8.4" Morgenstern, et al. Standards Track [Page 144] RFC 5650 VDSL2-LINE MIB September 2009 DEFVAL { "DEFVAL" } ::= { xdsl2LineAlarmConfTemplateEntry 3 } xdsl2LAlarmConfTempChan2ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #2. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable table. If the channel is unused, then the object is set to a zero-length string." REFERENCE "DSL Forum TR-129, paragraph #8.4" DEFVAL { "" } ::= { xdsl2LineAlarmConfTemplateEntry 4 } xdsl2LAlarmConfTempChan3ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #3. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable table. This object may be set to a non-zero-length string only if xdsl2LAlarmConfTempChan2ConfProfile contains a non-zero-length string." REFERENCE "DSL Forum TR-129, paragraph #8.4" DEFVAL { "" } ::= { xdsl2LineAlarmConfTemplateEntry 5 } xdsl2LAlarmConfTempChan4ConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the DSL Channel Thresholds Configuration Profile Table (xdsl2ChAlarmConfProfileTable) that applies for DSL bearer channel #4. The channel profile name specified here MUST match the name of an existing row in the xdsl2ChAlarmConfProfileTable table. Morgenstern, et al. Standards Track [Page 145] RFC 5650 VDSL2-LINE MIB September 2009 This object may be set to a non-zero-length string only if xdsl2LAlarmConfTempChan3ConfProfile contains a non-zero-length string." REFERENCE "DSL Forum TR-129, paragraph #8.4" DEFVAL { "" } ::= { xdsl2LineAlarmConfTemplateEntry 6 } xdsl2LAlarmConfTempRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. A template is activated by setting this object to 'active'. Before a template can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated lines. A row in this table is said to be unreferenced when there is no instance of xdsl2LineAlarmConfTemplate that refers to the row." ::= { xdsl2LineAlarmConfTemplateEntry 7 } ------------------------------------------------ -- xdsl2LineAlarmConfProfileTable -- ------------------------------------------------ xdsl2LineAlarmConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineAlarmConfProfileTable contains DSL line performance threshold values. If a performance counter exceeds the threshold value specified in this table, then the SNMP agent will issue a threshold trap. Each performance counter has a unique trap type (see NOTIFICATION-TYPE definitions below). One trap will be sent per interval, per interface, per trap type. A value of 0 will disable the trap. Entries in this table MUST be maintained in a persistent manner." ::= { xdsl2ProfileAlarmConf 2 } Morgenstern, et al. Standards Track [Page 146] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LineAlarmConfProfileEntry OBJECT-TYPE SYNTAX Xdsl2LineAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A default profile with an index of 'DEFVAL' will always exist, and its parameters will be set to vendor-specific values, unless otherwise specified in this document." INDEX { xdsl2LineAlarmConfProfileName } ::= { xdsl2LineAlarmConfProfileTable 1 } Xdsl2LineAlarmConfProfileEntry ::= SEQUENCE { xdsl2LineAlarmConfProfileName SnmpAdminString, xdsl2LineAlarmConfProfileXtucThresh15MinFecs HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXtucThresh15MinEs HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXtucThresh15MinSes HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXtucThresh15MinLoss HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXtucThresh15MinUas HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXturThresh15MinFecs HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXturThresh15MinEs HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXturThresh15MinSes HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXturThresh15MinLoss HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileXturThresh15MinUas HCPerfIntervalThreshold, xdsl2LineAlarmConfProfileThresh15MinFailedFullInt Unsigned32, xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt Unsigned32, xdsl2LineAlarmConfProfileRowStatus RowStatus } xdsl2LineAlarmConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table." ::= { xdsl2LineAlarmConfProfileEntry 1 } Morgenstern, et al. Standards Track [Page 147] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LineAlarmConfProfileXtucThresh15MinFecs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MFecs counter, when xdsl2PMLCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 2 } xdsl2LineAlarmConfProfileXtucThresh15MinEs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MEs counter, when xdsl2PMLCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 3 } xdsl2LineAlarmConfProfileXtucThresh15MinSes OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MSes counter, when xdsl2PMLCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 4 } xdsl2LineAlarmConfProfileXtucThresh15MinLoss OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 148] RFC 5650 VDSL2-LINE MIB September 2009 "A threshold for the xdsl2PMLCurr15MLoss counter, when xdsl2PMLCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 5 } xdsl2LineAlarmConfProfileXtucThresh15MinUas OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MUas counter, when xdsl2PMLCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 6 } xdsl2LineAlarmConfProfileXturThresh15MinFecs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MFecs counter, when xdsl2PMLCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 7 } xdsl2LineAlarmConfProfileXturThresh15MinEs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MEs counter, when xdsl2PMLCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } Morgenstern, et al. Standards Track [Page 149] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2LineAlarmConfProfileEntry 8 } xdsl2LineAlarmConfProfileXturThresh15MinSes OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MSes counter, when xdsl2PMLCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 9 } xdsl2LineAlarmConfProfileXturThresh15MinLoss OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MLoss counter, when xdsl2PMLCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 10 } xdsl2LineAlarmConfProfileXturThresh15MinUas OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLCurr15MUas counter, when xdsl2PMLCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 11 } xdsl2LineAlarmConfProfileThresh15MinFailedFullInt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current Morgenstern, et al. Standards Track [Page 150] RFC 5650 VDSL2-LINE MIB September 2009 DESCRIPTION "A threshold for the xdsl2PMLInitCurr15MfailedFullInits counter. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 12 } xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMLInitCurr15MFailedShortInits counter. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2LineAlarmConfProfileEntry 13 } xdsl2LineAlarmConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated templates. A row in this table is said to be unreferenced when there is no instance of xdsl2LAlarmConfTempLineProfile that refers to the row." ::= { xdsl2LineAlarmConfProfileEntry 14 } ------------------------------------------------ -- xdsl2ChAlarmConfProfileTable -- ------------------------------------------------ xdsl2ChAlarmConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2ChAlarmConfProfileEntry MAX-ACCESS not-accessible Morgenstern, et al. Standards Track [Page 151] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "The table xdsl2ChAlarmConfProfileTable contains DSL channel performance threshold values. If a performance counter exceeds the threshold value specified in this table, then the SNMP agent will issue a threshold trap. Each performance counter has a unique trap type (see NOTIFICATION-TYPE definitions below). One trap will be sent per interval per interface per trap type. A value of 0 will disable the trap. Entries in this table MUST be maintained in a persistent manner." ::= { xdsl2ProfileAlarmConf 3 } xdsl2ChAlarmConfProfileEntry OBJECT-TYPE SYNTAX Xdsl2ChAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A default profile with an index of 'DEFVAL' will always exist, and its parameters will be set to vendor-specific values, unless otherwise specified in this document." INDEX { xdsl2ChAlarmConfProfileName } ::= { xdsl2ChAlarmConfProfileTable 1 } Xdsl2ChAlarmConfProfileEntry ::= SEQUENCE { xdsl2ChAlarmConfProfileName SnmpAdminString, xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations Unsigned32, xdsl2ChAlarmConfProfileXtucThresh15MinCorrected Unsigned32, xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations Unsigned32, xdsl2ChAlarmConfProfileXturThresh15MinCorrected Unsigned32, xdsl2ChAlarmConfProfileRowStatus RowStatus } xdsl2ChAlarmConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a row in this table." ::= { xdsl2ChAlarmConfProfileEntry 1 } Morgenstern, et al. Standards Track [Page 152] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMChCurr15MCodingViolations counter, when xdsl2PMChCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2ChAlarmConfProfileEntry 2 } xdsl2ChAlarmConfProfileXtucThresh15MinCorrected OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMChCurr15MCorrectedBlocks counter, when xdsl2PMChCurrUnit is xtuc {1}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2ChAlarmConfProfileEntry 3 } xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMChCurr15MCodingViolations counter, when xdsl2PMChCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter." REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2ChAlarmConfProfileEntry 4 } xdsl2ChAlarmConfProfileXturThresh15MinCorrected OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "A threshold for the xdsl2PMChCurr15MCorrectedBlocks counter, when xdsl2PMChCurrUnit is xtur {2}. The value 0 means that no threshold is specified for the associated counter." Morgenstern, et al. Standards Track [Page 153] RFC 5650 VDSL2-LINE MIB September 2009 REFERENCE "ITU-T G.997.1, paragraph #7.2.7.2" DEFVAL { 0 } ::= { xdsl2ChAlarmConfProfileEntry 5 } xdsl2ChAlarmConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or to modify or delete an existing row in this table. A profile is activated by setting this object to 'active'. Before a profile can be deleted or taken out of service (by setting this object to 'destroy' or 'notInService'), it MUST be first unreferenced from all associated templates. A row in xdsl2ChConfProfTable is said to be unreferenced when there is no instance of xdsl2LAlarmConfTempChan1ConfProfile, xdsl2LAlarmConfTempChan2ConfProfile, xdsl2LAlarmConfTempChan3ConfProfile, or xdsl2LAlarmConfTempChan4ConfProfile that refers to the row." ::= { xdsl2ChAlarmConfProfileEntry 6 } ------------------------------------------------ -- PM line current counters -- ------------------------------------------------ xdsl2PMLineCurrTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMLineCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMLineCurrTable contains current Performance Monitoring results for DSL lines." ::= { xdsl2PMLine 1 } xdsl2PMLineCurrEntry OBJECT-TYPE SYNTAX Xdsl2PMLineCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is the termination unit." INDEX { ifIndex, xdsl2PMLCurrUnit } Morgenstern, et al. Standards Track [Page 154] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2PMLineCurrTable 1 } Xdsl2PMLineCurrEntry ::= SEQUENCE { xdsl2PMLCurrUnit Xdsl2Unit, xdsl2PMLCurr15MValidIntervals Unsigned32, xdsl2PMLCurr15MInvalidIntervals Unsigned32, xdsl2PMLCurr15MTimeElapsed HCPerfTimeElapsed, xdsl2PMLCurr15MFecs Counter32, xdsl2PMLCurr15MEs Counter32, xdsl2PMLCurr15MSes Counter32, xdsl2PMLCurr15MLoss Counter32, xdsl2PMLCurr15MUas Counter32, xdsl2PMLCurr1DayValidIntervals Unsigned32, xdsl2PMLCurr1DayInvalidIntervals Unsigned32, xdsl2PMLCurr1DayTimeElapsed HCPerfTimeElapsed, xdsl2PMLCurr1DayFecs Counter32, xdsl2PMLCurr1DayEs Counter32, xdsl2PMLCurr1DaySes Counter32, xdsl2PMLCurr1DayLoss Counter32, xdsl2PMLCurr1DayUas Counter32 } xdsl2PMLCurrUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2PMLineCurrEntry 1 } xdsl2PMLCurr15MValidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 15-minute PM intervals for which data was collected. The value will typically be equal to the maximum number of 15-minute intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 15-minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { xdsl2PMLineCurrEntry 2 } Morgenstern, et al. Standards Track [Page 155] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLCurr15MInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 15-minute PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { xdsl2PMLineCurrEntry 3 } xdsl2PMLCurr15MTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { xdsl2PMLineCurrEntry 4 } xdsl2PMLCurr15MFecs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.1 (FECS-L) and paragraph #7.2.1.2.1 (FECS-LFE)" ::= { xdsl2PMLineCurrEntry 5 } xdsl2PMLCurr15MEs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >=1 OR LPR >= 1. xTU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >=1 OR RDI >=1 OR LPR-FE >=1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.2 (ES-L) and paragraph #7.2.1.2.2 (ES-LFE)" ::= { xdsl2PMLineCurrEntry 6 } Morgenstern, et al. Standards Track [Page 156] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLCurr15MSes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.3 (SES-L) and paragraph #7.2.1.2.3 (SES-LFE)" ::= { xdsl2PMLineCurrEntry 7 } xdsl2PMLCurr15MLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was LOS (or LOS-FE for xTU-R)." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.4 (LOSS-L) and paragraph #7.2.1.2.4 (LOSS-LFE)" ::= { xdsl2PMLineCurrEntry 8 } xdsl2PMLCurr15MUas OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely errored seconds, and ends at the onset of 10 contiguous seconds with no severely errored seconds." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.5 (UAS-L) and paragraph #7.2.1.2.5 (UAS-LFE)" ::= { xdsl2PMLineCurrEntry 9 } xdsl2PMLCurr1DayValidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..30) MAX-ACCESS read-only STATUS current Morgenstern, et al. Standards Track [Page 157] RFC 5650 VDSL2-LINE MIB September 2009 DESCRIPTION "The number of 24-hour PM intervals for which data was collected. The value will typically be equal to the maximum number of 24-hour intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 24-hour intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { xdsl2PMLineCurrEntry 10 } xdsl2PMLCurr1DayInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 24-hour PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { xdsl2PMLineCurrEntry 11 } xdsl2PMLCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { xdsl2PMLineCurrEntry 12 } xdsl2PMLCurr1DayFecs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.1 (FECS-L) and paragraph #7.2.1.2.1 (FECS-LFE)" ::= { xdsl2PMLineCurrEntry 13 } xdsl2PMLCurr1DayEs OBJECT-TYPE SYNTAX Counter32 Morgenstern, et al. Standards Track [Page 158] RFC 5650 VDSL2-LINE MIB September 2009 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.2 (ES-L) and paragraph #7.2.1.2.2 (ES-LFE)" ::= { xdsl2PMLineCurrEntry 14 } xdsl2PMLCurr1DaySes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received bearer channels) >= 18 OR LOS-FE >= 1. OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.3 (SES-L) and paragraph #7.2.1.2.3 (SES-LFE)" ::= { xdsl2PMLineCurrEntry 15 } xdsl2PMLCurr1DayLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was LOS (or LOS-FE for xTU-R)." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.4 (LOSS-L) and paragraph #7.2.1.2.4 (LOSS-LFE)" ::= { xdsl2PMLineCurrEntry 16 } xdsl2PMLCurr1DayUas OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only Morgenstern, et al. Standards Track [Page 159] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely errored seconds, and ends at the onset of 10 contiguous seconds with no severely errored seconds." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.5 (UAS-L) and paragraph #7.2.1.2.5 (UAS-LFE)" ::= { xdsl2PMLineCurrEntry 17 } ------------------------------------------------ -- PM line init current counters -- ------------------------------------------------ xdsl2PMLineInitCurrTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMLineInitCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMLineInitCurrTable contains current initialization counters for DSL lines." ::= { xdsl2PMLine 2 } xdsl2PMLineInitCurrEntry OBJECT-TYPE SYNTAX Xdsl2PMLineInitCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this table is an interface index where the interface has an ifType of vdsl2(251)." INDEX { ifIndex } ::= { xdsl2PMLineInitCurrTable 1 } Xdsl2PMLineInitCurrEntry ::= SEQUENCE { xdsl2PMLInitCurr15MValidIntervals Unsigned32, xdsl2PMLInitCurr15MInvalidIntervals Unsigned32, xdsl2PMLInitCurr15MTimeElapsed Unsigned32, xdsl2PMLInitCurr15MFullInits Unsigned32, xdsl2PMLInitCurr15MFailedFullInits Unsigned32, xdsl2PMLInitCurr15MShortInits Unsigned32, xdsl2PMLInitCurr15MFailedShortInits Unsigned32, xdsl2PMLInitCurr1DayValidIntervals Unsigned32, xdsl2PMLInitCurr1DayInvalidIntervals Unsigned32, xdsl2PMLInitCurr1DayTimeElapsed Unsigned32, xdsl2PMLInitCurr1DayFullInits Unsigned32, xdsl2PMLInitCurr1DayFailedFullInits Unsigned32, Morgenstern, et al. Standards Track [Page 160] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLInitCurr1DayShortInits Unsigned32, xdsl2PMLInitCurr1DayFailedShortInits Unsigned32 } xdsl2PMLInitCurr15MValidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 15-minute PM intervals for which data was collected. The value will typically be equal to the maximum number of 15-minute intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 15-minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { xdsl2PMLineInitCurrEntry 1 } xdsl2PMLInitCurr15MInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 15-minute PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { xdsl2PMLineInitCurrEntry 2 } xdsl2PMLInitCurr15MTimeElapsed OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { xdsl2PMLineInitCurrEntry 3 } xdsl2PMLInitCurr15MFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." Morgenstern, et al. Standards Track [Page 161] RFC 5650 VDSL2-LINE MIB September 2009 REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.1" ::= { xdsl2PMLineInitCurrEntry 4 } xdsl2PMLInitCurr15MFailedFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.2" ::= { xdsl2PMLineInitCurrEntry 5 } xdsl2PMLInitCurr15MShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.3" ::= { xdsl2PMLineInitCurrEntry 6 } xdsl2PMLInitCurr15MFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.4" ::= { xdsl2PMLineInitCurrEntry 7 } xdsl2PMLInitCurr1DayValidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 24-hour PM intervals for which data was collected. The value will typically be equal to the maximum number of 24-hour intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 24-hour intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." Morgenstern, et al. Standards Track [Page 162] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2PMLineInitCurrEntry 8 } xdsl2PMLInitCurr1DayInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 24-hour PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { xdsl2PMLineInitCurrEntry 9 } xdsl2PMLInitCurr1DayTimeElapsed OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { xdsl2PMLineInitCurrEntry 10 } xdsl2PMLInitCurr1DayFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.1" ::= { xdsl2PMLineInitCurrEntry 11 } xdsl2PMLInitCurr1DayFailedFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.2" ::= { xdsl2PMLineInitCurrEntry 12 } xdsl2PMLInitCurr1DayShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line Morgenstern, et al. Standards Track [Page 163] RFC 5650 VDSL2-LINE MIB September 2009 (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.3" ::= { xdsl2PMLineInitCurrEntry 13 } xdsl2PMLInitCurr1DayFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.4" ::= { xdsl2PMLineInitCurrEntry 14 } ------------------------------------------- -- PM line history 15 Minutes -- ------------------------------------------- xdsl2PMLineHist15MinTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMLineHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMLineHist15MinTable contains PM line history for 15-minute intervals of DSL line." ::= { xdsl2PMLine 3 } xdsl2PMLineHist15MinEntry OBJECT-TYPE SYNTAX Xdsl2PMLineHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is the transmission unit. The third index is the interval number." INDEX { ifIndex, xdsl2PMLHist15MUnit, xdsl2PMLHist15MInterval } ::= { xdsl2PMLineHist15MinTable 1 } Xdsl2PMLineHist15MinEntry ::= SEQUENCE { xdsl2PMLHist15MUnit Xdsl2Unit, xdsl2PMLHist15MInterval Unsigned32, xdsl2PMLHist15MMonitoredTime Unsigned32, xdsl2PMLHist15MFecs Counter32, xdsl2PMLHist15MEs Counter32, Morgenstern, et al. Standards Track [Page 164] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLHist15MSes Counter32, xdsl2PMLHist15MLoss Counter32, xdsl2PMLHist15MUas Counter32, xdsl2PMLHist15MValidInterval TruthValue } xdsl2PMLHist15MUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2PMLineHist15MinEntry 1 } xdsl2PMLHist15MInterval OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { xdsl2PMLineHist15MinEntry 2 } xdsl2PMLHist15MMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { xdsl2PMLineHist15MinEntry 3 } xdsl2PMLHist15MFecs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.1 (FECS-L) and paragraph #7.2.1.2.1 (FECS-LFE)" ::= { xdsl2PMLineHist15MinEntry 4 } xdsl2PMLHist15MEs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only Morgenstern, et al. Standards Track [Page 165] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.2 (ES-L) and paragraph #7.2.1.2.2 (ES-LFE)" ::= { xdsl2PMLineHist15MinEntry 5 } xdsl2PMLHist15MSes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.3 (SES-L) and paragraph #7.2.1.2.3 (SES-LFE)" ::= { xdsl2PMLineHist15MinEntry 6 } xdsl2PMLHist15MLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was LOS (or LOS-FE for xTU-R)." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.4 (LOSS-L) and paragraph #7.2.1.2.4 (LOSS-LFE)" ::= { xdsl2PMLineHist15MinEntry 7 } xdsl2PMLHist15MUas OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 166] RFC 5650 VDSL2-LINE MIB September 2009 "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely errored seconds, and ends at the onset of 10 contiguous seconds with no severely errored seconds." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.5 (UAS-L) and paragraph #7.2.1.2.5 (UAS-LFE)" ::= { xdsl2PMLineHist15MinEntry 8 } xdsl2PMLHist15MValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { xdsl2PMLineHist15MinEntry 9 } --------------------------------------- -- PM line history 1 Day -- --------------------------------------- xdsl2PMLineHist1DayTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMLineHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMLineHist1DayTable contains PM line history for 24-hour intervals of DSL line." ::= { xdsl2PMLine 4 } xdsl2PMLineHist1DayEntry OBJECT-TYPE SYNTAX Xdsl2PMLineHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index of this table is the transmission unit.The third index is the interval number." INDEX { ifIndex, xdsl2PMLHist1DUnit, xdsl2PMLHist1DInterval } ::= { xdsl2PMLineHist1DayTable 1 } Xdsl2PMLineHist1DayEntry ::= SEQUENCE { xdsl2PMLHist1DUnit Xdsl2Unit, Morgenstern, et al. Standards Track [Page 167] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLHist1DInterval Unsigned32, xdsl2PMLHist1DMonitoredTime Unsigned32, xdsl2PMLHist1DFecs Counter32, xdsl2PMLHist1DEs Counter32, xdsl2PMLHist1DSes Counter32, xdsl2PMLHist1DLoss Counter32, xdsl2PMLHist1DUas Counter32, xdsl2PMLHist1DValidInterval TruthValue } xdsl2PMLHist1DUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2PMLineHist1DayEntry 1 } xdsl2PMLHist1DInterval OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { xdsl2PMLineHist1DayEntry 2 } xdsl2PMLHist1DMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { xdsl2PMLineHist1DayEntry 3 } xdsl2PMLHist1DFecs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was at least one FEC correction event for one or more bearer channels in this line. This parameter is inhibited during UAS or SES." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.1 (FECS-L) and paragraph #7.2.1.2.1 (FECS-LFE)" ::= { xdsl2PMLineHist1DayEntry 4 } Morgenstern, et al. Standards Track [Page 168] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLHist1DEs OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: CRC-8 >= 1 for one or more bearer channels OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: FEBE >= 1 for one or more bearer channels OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.2 (ES-L) and paragraph #7.2.1.2.2 (ES-LFE)" ::= { xdsl2PMLineHist1DayEntry 5 } xdsl2PMLHist1DSes OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was: xTU-C: (CRC-8 anomalies in one or more of the received bearer channels) >= 18 OR LOS >= 1 OR SEF >= 1 OR LPR >= 1. xTU-R: (FEBE anomalies in one or more of the received bearer channels) >= 18 OR LOS-FE >= 1 OR RDI >= 1 OR LPR-FE >= 1. This parameter is inhibited during UAS." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.3 (SES-L) and paragraph #7.2.1.2.3 (SES-LFE)" ::= { xdsl2PMLineHist1DayEntry 6 } xdsl2PMLHist1DLoss OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there was LOS (or LOS-FE for xTU-R)." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.4 (LOSS-L) and paragraph #7.2.1.2.4 (LOSS-LFE)" ::= { xdsl2PMLineHist1DayEntry 7 } xdsl2PMLHist1DUas OBJECT-TYPE SYNTAX Counter32 Morgenstern, et al. Standards Track [Page 169] RFC 5650 VDSL2-LINE MIB September 2009 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in Unavailability State during this interval. Unavailability begins at the onset of 10 contiguous severely errored seconds, and ends at the onset of 10 contiguous seconds with no severely errored seconds." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.1.5 (UAS-L) and paragraph #7.2.1.2.5 (UAS-LFE)" ::= { xdsl2PMLineHist1DayEntry 8 } xdsl2PMLHist1DValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { xdsl2PMLineHist1DayEntry 9 } ------------------------------------------- -- PM line init history 15 Minutes -- ------------------------------------------- xdsl2PMLineInitHist15MinTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMLineInitHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMLineInitHist15MinTable contains PM line initialization history for 15-minute intervals of DSL line." ::= { xdsl2PMLine 5 } xdsl2PMLineInitHist15MinEntry OBJECT-TYPE SYNTAX Xdsl2PMLineInitHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index is the interval number." INDEX { ifIndex, xdsl2PMLInitHist15MInterval } ::= { xdsl2PMLineInitHist15MinTable 1 } Morgenstern, et al. Standards Track [Page 170] RFC 5650 VDSL2-LINE MIB September 2009 Xdsl2PMLineInitHist15MinEntry ::= SEQUENCE { xdsl2PMLInitHist15MInterval Unsigned32, xdsl2PMLInitHist15MMonitoredTime Unsigned32, xdsl2PMLInitHist15MFullInits Unsigned32, xdsl2PMLInitHist15MFailedFullInits Unsigned32, xdsl2PMLInitHist15MShortInits Unsigned32, xdsl2PMLInitHist15MFailedShortInits Unsigned32, xdsl2PMLInitHist15MValidInterval TruthValue } xdsl2PMLInitHist15MInterval OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { xdsl2PMLineInitHist15MinEntry 1 } xdsl2PMLInitHist15MMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { xdsl2PMLineInitHist15MinEntry 2 } xdsl2PMLInitHist15MFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.1" ::= { xdsl2PMLineInitHist15MinEntry 3 } xdsl2PMLInitHist15MFailedFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.2" ::= { xdsl2PMLineInitHist15MinEntry 4 } Morgenstern, et al. Standards Track [Page 171] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLInitHist15MShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.3" ::= { xdsl2PMLineInitHist15MinEntry 5 } xdsl2PMLInitHist15MFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.4" ::= { xdsl2PMLineInitHist15MinEntry 6 } xdsl2PMLInitHist15MValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { xdsl2PMLineInitHist15MinEntry 7 } ------------------------------------------- -- PM line init history 1 Day -- ------------------------------------------- xdsl2PMLineInitHist1DayTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMLineInitHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMLineInitHist1DayTable contains PM line initialization history for 24-hour intervals for DSL lines." ::= { xdsl2PMLine 6 } xdsl2PMLineInitHist1DayEntry OBJECT-TYPE SYNTAX Xdsl2PMLineInitHist1DayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 172] RFC 5650 VDSL2-LINE MIB September 2009 "One index of this table is an interface index where the interface has an ifType of vdsl2(251). A second index is the interval number." INDEX { ifIndex, xdsl2PMLInitHist1DInterval } ::= { xdsl2PMLineInitHist1DayTable 1 } Xdsl2PMLineInitHist1DayEntry ::= SEQUENCE { xdsl2PMLInitHist1DInterval Unsigned32, xdsl2PMLInitHist1DMonitoredTime Unsigned32, xdsl2PMLInitHist1DFullInits Unsigned32, xdsl2PMLInitHist1DFailedFullInits Unsigned32, xdsl2PMLInitHist1DShortInits Unsigned32, xdsl2PMLInitHist1DFailedShortInits Unsigned32, xdsl2PMLInitHist1DValidInterval TruthValue } xdsl2PMLInitHist1DInterval OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { xdsl2PMLineInitHist1DayEntry 1 } xdsl2PMLInitHist1DMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { xdsl2PMLineInitHist1DayEntry 2 } xdsl2PMLInitHist1DFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of full initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.1" ::= { xdsl2PMLineInitHist1DayEntry 3 } xdsl2PMLInitHist1DFailedFullInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Morgenstern, et al. Standards Track [Page 173] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "Count of failed full initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.2" ::= { xdsl2PMLineInitHist1DayEntry 4 } xdsl2PMLInitHist1DShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of short initializations attempted on the line (successful and failed) during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.3" ::= { xdsl2PMLineInitHist1DayEntry 5 } xdsl2PMLInitHist1DFailedShortInits OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of failed short initializations on the line during this interval." REFERENCE "ITU-T G.997.1, paragraph #7.2.1.3.4" ::= { xdsl2PMLineInitHist1DayEntry 6 } xdsl2PMLInitHist1DValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { xdsl2PMLineInitHist1DayEntry 7 } --------------------------------------------------- -- PM channel current counters -- --------------------------------------------------- xdsl2PMChCurrTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMChCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMChCurrTable contains current Performance Monitoring results for DSL channels." ::= { xdsl2PMChannel 1 } Morgenstern, et al. Standards Track [Page 174] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMChCurrEntry OBJECT-TYPE SYNTAX Xdsl2PMChCurrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of a DSL channel. A second index of this table is the termination unit." INDEX { ifIndex, xdsl2PMChCurrUnit } ::= { xdsl2PMChCurrTable 1 } Xdsl2PMChCurrEntry ::= SEQUENCE { xdsl2PMChCurrUnit Xdsl2Unit, xdsl2PMChCurr15MValidIntervals Unsigned32, xdsl2PMChCurr15MInvalidIntervals Unsigned32, xdsl2PMChCurr15MTimeElapsed HCPerfTimeElapsed, xdsl2PMChCurr15MCodingViolations Unsigned32, xdsl2PMChCurr15MCorrectedBlocks Unsigned32, xdsl2PMChCurr1DayValidIntervals Unsigned32, xdsl2PMChCurr1DayInvalidIntervals Unsigned32, xdsl2PMChCurr1DayTimeElapsed HCPerfTimeElapsed, xdsl2PMChCurr1DayCodingViolations Unsigned32, xdsl2PMChCurr1DayCorrectedBlocks Unsigned32 } xdsl2PMChCurrUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2PMChCurrEntry 1 } xdsl2PMChCurr15MValidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 15-minute PM intervals for which data was collected. The value will typically be equal to the maximum number of 15-minute intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 15-minute intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the Morgenstern, et al. Standards Track [Page 175] RFC 5650 VDSL2-LINE MIB September 2009 maximum interval number for which data is available." ::= { xdsl2PMChCurrEntry 2 } xdsl2PMChCurr15MInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 15-minute PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { xdsl2PMChCurrEntry 3 } xdsl2PMChCurr15MTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { xdsl2PMChCurrEntry 4 } xdsl2PMChCurr15MCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for xTU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly SHOULD increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.1 (CV-C) and paragraph #7.2.2.2.1 (CV-CFE)" ::= { xdsl2PMChCurrEntry 5 } xdsl2PMChCurr15MCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of FEC (FFEC for xTU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly SHOULD increment each of the counters related to the individual channels." Morgenstern, et al. Standards Track [Page 176] RFC 5650 VDSL2-LINE MIB September 2009 REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.2 (FEC-C) and paragraph #7.2.2.2.2 (FEC-CFE)" ::= { xdsl2PMChCurrEntry 6 } xdsl2PMChCurr1DayValidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 24-hour PM intervals for which data was collected. The value will typically be equal to the maximum number of 24-hour intervals the implementation is planned to store (i.e., beyond the scope of this MIB module) unless the measurement was (re-)started recently, in which case the value will be the number of complete 24-hour intervals for which the agent has at least some data. In certain cases (e.g., in the case where the agent is a proxy), it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which data is available." ::= { xdsl2PMChCurrEntry 7 } xdsl2PMChCurr1DayInvalidIntervals OBJECT-TYPE SYNTAX Unsigned32 (0..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of 24-hour PM intervals for which no data is available. The value will typically be zero except in cases where the data for some intervals are not available (e.g., in proxy situations)." ::= { xdsl2PMChCurrEntry 8 } xdsl2PMChCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::= { xdsl2PMChCurrEntry 9 } xdsl2PMChCurr1DayCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for xTU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during Morgenstern, et al. Standards Track [Page 177] RFC 5650 VDSL2-LINE MIB September 2009 UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly SHOULD increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.1 (CV-C) and paragraph #7.2.2.2.1 (CV-CFE)" ::= { xdsl2PMChCurrEntry 10 } xdsl2PMChCurr1DayCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of FEC (FFEC for xTU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly SHOULD increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.2 (FEC-C) and paragraph #7.2.2.2.2 (FEC-CFE)" ::= { xdsl2PMChCurrEntry 11 } ------------------------------------------- -- PM channel history 15 Minutes -- ------------------------------------------- xdsl2PMChHist15MinTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMChHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMChHist15MinTable contains Performance Monitoring (PM) history for 15-minute intervals for DSL channels PM." ::= { xdsl2PMChannel 2 } xdsl2PMChHist15MinEntry OBJECT-TYPE SYNTAX Xdsl2PMChHist15MinEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of a DSL channel. A second index of this table is the transmission unit. The third index is the interval number." INDEX { ifIndex, xdsl2PMChHist15MUnit, xdsl2PMChHist15MInterval } Morgenstern, et al. Standards Track [Page 178] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2PMChHist15MinTable 1 } Xdsl2PMChHist15MinEntry ::= SEQUENCE { xdsl2PMChHist15MUnit Xdsl2Unit, xdsl2PMChHist15MInterval Unsigned32, xdsl2PMChHist15MMonitoredTime Unsigned32, xdsl2PMChHist15MCodingViolations Unsigned32, xdsl2PMChHist15MCorrectedBlocks Unsigned32, xdsl2PMChHist15MValidInterval TruthValue } xdsl2PMChHist15MUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2PMChHist15MinEntry 1 } xdsl2PMChHist15MInterval OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { xdsl2PMChHist15MinEntry 2 } xdsl2PMChHist15MMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { xdsl2PMChHist15MinEntry 3 } xdsl2PMChHist15MCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for xTU-R) anomalies occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly SHOULD increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.1 (CV-C) Morgenstern, et al. Standards Track [Page 179] RFC 5650 VDSL2-LINE MIB September 2009 and paragraph #7.2.2.2.1 (CV-CFE)" ::= { xdsl2PMChHist15MinEntry 4 } xdsl2PMChHist15MCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of FEC (FFEC for xTU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly SHOULD increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.2 (FEC-C) and paragraph #7.2.2.2.2 (FEC-CFE)" ::= { xdsl2PMChHist15MinEntry 5 } xdsl2PMChHist15MValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { xdsl2PMChHist15MinEntry 6 } ------------------------------------------ -- PM channel history 1 Day -- ------------------------------------------ xdsl2PMChHist1DTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2PMChHist1DEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2PMChHist1DTable contains Performance Monitoring (PM) history for 1-day intervals for DSL channels PM." ::= { xdsl2PMChannel 3 } xdsl2PMChHist1DEntry OBJECT-TYPE SYNTAX Xdsl2PMChHist1DEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One index of this table is an interface index where the interface has an ifType of a DSL channel. A second index of Morgenstern, et al. Standards Track [Page 180] RFC 5650 VDSL2-LINE MIB September 2009 this table is the transmission unit. The third index is the interval number." INDEX { ifIndex, xdsl2PMChHist1DUnit, xdsl2PMChHist1DInterval } ::= { xdsl2PMChHist1DTable 1 } Xdsl2PMChHist1DEntry ::= SEQUENCE { xdsl2PMChHist1DUnit Xdsl2Unit, xdsl2PMChHist1DInterval Unsigned32, xdsl2PMChHist1DMonitoredTime Unsigned32, xdsl2PMChHist1DCodingViolations Unsigned32, xdsl2PMChHist1DCorrectedBlocks Unsigned32, xdsl2PMChHist1DValidInterval TruthValue } xdsl2PMChHist1DUnit OBJECT-TYPE SYNTAX Xdsl2Unit MAX-ACCESS not-accessible STATUS current DESCRIPTION "The termination unit." ::= { xdsl2PMChHist1DEntry 1 } xdsl2PMChHist1DInterval OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interval number." ::= { xdsl2PMChHist1DEntry 2 } xdsl2PMChHist1DMonitoredTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total seconds monitored in this interval." ::= { xdsl2PMChHist1DEntry 3 } xdsl2PMChHist1DCodingViolations OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of CRC-8 (FEBE for xTU-R) anomalies occurring in the Morgenstern, et al. Standards Track [Page 181] RFC 5650 VDSL2-LINE MIB September 2009 channel during the interval. This parameter is inhibited during UAS or SES. If the CRC is applied over multiple channels, then each related CRC-8 (or FEBE) anomaly SHOULD increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.1 (CV-C) and paragraph #7.2.2.2.1 (CV-CFE)" ::= { xdsl2PMChHist1DEntry 4 } xdsl2PMChHist1DCorrectedBlocks OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of FEC (FFEC for xTU-R) anomalies (corrected code words) occurring in the channel during the interval. This parameter is inhibited during UAS or SES. If the FEC is applied over multiple channels, then each related FEC (or FFEC) anomaly SHOULD increment each of the counters related to the individual channels." REFERENCE "ITU-T G.997.1, paragraph #7.2.2.1.2 (FEC-C) and paragraph #7.2.2.2.2 (FEC-CFE)" ::= { xdsl2PMChHist1DEntry 5 } xdsl2PMChHist1DValidInterval OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if the data for this interval is valid." ::= { xdsl2PMChHist1DEntry 6 } ------------------------------------------- -- Notifications Group -- ------------------------------------------- xdsl2LinePerfFECSThreshXtuc NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MFecs, xdsl2LineAlarmConfProfileXtucThresh15MinFecs } STATUS current DESCRIPTION "This notification indicates that the FEC seconds threshold has been reached/exceeded for the referred xTU-C." ::= { xdsl2Notifications 1 } Morgenstern, et al. Standards Track [Page 182] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LinePerfFECSThreshXtur NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MFecs, xdsl2LineAlarmConfProfileXturThresh15MinFecs } STATUS current DESCRIPTION "This notification indicates that the FEC seconds threshold has been reached/exceeded for the referred xTU-R." ::= { xdsl2Notifications 2 } xdsl2LinePerfESThreshXtuc NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MEs, xdsl2LineAlarmConfProfileXtucThresh15MinEs } STATUS current DESCRIPTION "This notification indicates that the errored seconds threshold has been reached/exceeded for the referred xTU-C." ::= { xdsl2Notifications 3 } xdsl2LinePerfESThreshXtur NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MEs, xdsl2LineAlarmConfProfileXturThresh15MinEs } STATUS current DESCRIPTION "This notification indicates that the errored seconds threshold has been reached/exceeded for the referred xTU-R." ::= { xdsl2Notifications 4 } xdsl2LinePerfSESThreshXtuc NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MSes, xdsl2LineAlarmConfProfileXtucThresh15MinSes } STATUS current DESCRIPTION "This notification indicates that the severely errored seconds threshold has been reached/exceeded for the referred xTU-C." ::= { xdsl2Notifications 5 } Morgenstern, et al. Standards Track [Page 183] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LinePerfSESThreshXtur NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MSes, xdsl2LineAlarmConfProfileXturThresh15MinSes } STATUS current DESCRIPTION "This notification indicates that the severely errored seconds threshold has been reached/exceeded for the referred xTU-R." ::= { xdsl2Notifications 6 } xdsl2LinePerfLOSSThreshXtuc NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MLoss, xdsl2LineAlarmConfProfileXtucThresh15MinLoss } STATUS current DESCRIPTION "This notification indicates that the LOS seconds threshold has been reached/exceeded for the referred xTU-C." ::= { xdsl2Notifications 7 } xdsl2LinePerfLOSSThreshXtur NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MLoss, xdsl2LineAlarmConfProfileXturThresh15MinLoss } STATUS current DESCRIPTION "This notification indicates that the LOS seconds threshold has been reached/exceeded for the referred xTU-R." ::= { xdsl2Notifications 8 } xdsl2LinePerfUASThreshXtuc NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MUas, xdsl2LineAlarmConfProfileXtucThresh15MinUas } STATUS current DESCRIPTION "This notification indicates that the unavailable seconds threshold has been reached/exceeded for the referred xTU-C." ::= { xdsl2Notifications 9 } Morgenstern, et al. Standards Track [Page 184] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LinePerfUASThreshXtur NOTIFICATION-TYPE OBJECTS { xdsl2PMLCurr15MUas, xdsl2LineAlarmConfProfileXturThresh15MinUas } STATUS current DESCRIPTION "This notification indicates that the unavailable seconds threshold has been reached/exceeded for the referred xTU-R." ::= { xdsl2Notifications 10 } xdsl2LinePerfCodingViolationsThreshXtuc NOTIFICATION-TYPE OBJECTS { xdsl2PMChCurr15MCodingViolations, xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations } STATUS current DESCRIPTION "This notification indicates that the coding violations threshold has been reached/exceeded for the referred xTU-C." ::= { xdsl2Notifications 11 } xdsl2LinePerfCodingViolationsThreshXtur NOTIFICATION-TYPE OBJECTS { xdsl2PMChCurr15MCodingViolations, xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations } STATUS current DESCRIPTION "This notification indicates that the coding violations threshold has been reached/exceeded for the referred xTU-R." ::= { xdsl2Notifications 12 } xdsl2LinePerfCorrectedThreshXtuc NOTIFICATION-TYPE OBJECTS { xdsl2PMChCurr15MCorrectedBlocks, xdsl2ChAlarmConfProfileXtucThresh15MinCorrected } STATUS current DESCRIPTION "This notification indicates that the corrected blocks (FEC events) threshold has been reached/exceeded for the referred xTU-C." ::= { xdsl2Notifications 13 } Morgenstern, et al. Standards Track [Page 185] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LinePerfCorrectedThreshXtur NOTIFICATION-TYPE OBJECTS { xdsl2PMChCurr15MCorrectedBlocks, xdsl2ChAlarmConfProfileXturThresh15MinCorrected } STATUS current DESCRIPTION "This notification indicates that the corrected blocks (FEC events) threshold has been reached/exceeded for the referred xTU-R." ::= { xdsl2Notifications 14 } xdsl2LinePerfFailedFullInitThresh NOTIFICATION-TYPE OBJECTS { xdsl2PMLInitCurr15MFailedFullInits, xdsl2LineAlarmConfProfileThresh15MinFailedFullInt } STATUS current DESCRIPTION "This notification indicates that the failed full initializations threshold has been reached/exceeded for the referred ADSL/ADSL2 or ADSL2 line." ::= { xdsl2Notifications 15 } xdsl2LinePerfFailedShortInitThresh NOTIFICATION-TYPE OBJECTS { xdsl2PMLInitCurr15MFailedShortInits, xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt } STATUS current DESCRIPTION "This notification indicates that the failed short initializations threshold has been reached/exceeded for the referred VDSL2/ADSL/ADSL2 or ADSL2+ line." ::= { xdsl2Notifications 16 } xdsl2LineStatusChangeXtuc NOTIFICATION-TYPE OBJECTS { xdsl2LineStatusXtuc } STATUS current DESCRIPTION "This notification indicates that a status change is detected for the referred xTU-C." Morgenstern, et al. Standards Track [Page 186] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2Notifications 17 } xdsl2LineStatusChangeXtur NOTIFICATION-TYPE OBJECTS { xdsl2LineStatusXtur } STATUS current DESCRIPTION "This notification indicates that a status change is detected for the referred xTU-R." ::= { xdsl2Notifications 18 } -- conformance information xdsl2Groups OBJECT IDENTIFIER ::= { xdsl2Conformance 1 } xdsl2Compliances OBJECT IDENTIFIER ::= { xdsl2Conformance 2 } xdsl2LineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which manage VDSL2/ADSL/ADSL2 and ADSL2+ interfaces." MODULE -- this module MANDATORY-GROUPS { xdsl2LineGroup, xdsl2ChannelStatusGroup, xdsl2SCStatusGroup, xdsl2LineInventoryGroup, xdsl2LineConfTemplateGroup, xdsl2LineConfProfGroup, xdsl2LineConfProfModeSpecGroup, xdsl2LineConfProfModeSpecBandUsGroup, xdsl2ChConfProfileGroup, xdsl2LineAlarmConfTemplateGroup, xdsl2PMLineCurrGroup, xdsl2PMLineInitCurrGroup, xdsl2PMLineHist15MinGroup, xdsl2PMLineHist1DayGroup, xdsl2PMLineInitHist15MinGroup, xdsl2PMLineInitHist1DayGroup, xdsl2PMChCurrGroup, xdsl2PMChHist15MinGroup, xdsl2PMChHist1DGroup } Morgenstern, et al. Standards Track [Page 187] RFC 5650 VDSL2-LINE MIB September 2009 GROUP xdsl2LineFallbackGroup DESCRIPTION "The group of configuration, status, and commands objects on the line level that are associated with the fallback feature." GROUP xdsl2LineBpscGroup DESCRIPTION "The group of configuration, status, and commands objects on the line level that are associated with requesting a bits per subcarrier measurement." GROUP xdsl2LineSegmentGroup DESCRIPTION "The group of status and commands objects on the line level that are used to hold the results of the bits-per-subcarrier measurement." GROUP xdsl2ChannelStatusAtmGroup DESCRIPTION "The group of status objects required when the data path is ATM." GROUP xdsl2ChannelStatusPtmGroup DESCRIPTION "The group of status objects required when the data path is PTM." GROUP xdsl2LineConfProfRaGroup DESCRIPTION "The group of objects required for controlling the rate-adaptive behavior of the line." GROUP xdsl2LineConfProfMsgMinGroup DESCRIPTION "The group of objects required for controlling the rate reserved for Overhead traffic." GROUP xdsl2LineAlarmConfProfileGroup DESCRIPTION "The group of objects that define the alarm thresholds on line-level PM counters." GROUP xdsl2ChAlarmConfProfileGroup DESCRIPTION "The group of objects that define the alarm thresholds on channel-level PM counters." Morgenstern, et al. Standards Track [Page 188] RFC 5650 VDSL2-LINE MIB September 2009 GROUP xdsl2ChConfProfileAtmGroup DESCRIPTION "The group of configuration objects required when the data path is ATM." GROUP xdsl2ChConfProfileMinResGroup DESCRIPTION "The group of configuration objects required for the reserved data rate." GROUP xdsl2ChConfProfileOptAttrGroup DESCRIPTION "The group of various optional channel configuration objects." GROUP xdsl2PMLineInitCurrShortGroup DESCRIPTION "The group of PM counters for the current intervals short initializations." GROUP xdsl2PMLineInitHist15MinShortGroup DESCRIPTION "The group of PM counters for the previous 15-minute intervals short initializations." GROUP xdsl2PMLineInitHist1DayShortGroup DESCRIPTION "The group of PM counters for the previous 24-hour intervals short initializations." GROUP xdsl2ScalarSCGroup DESCRIPTION "The group of objects that report the available memory resources for the DELT processes." GROUP xdsl2ThreshNotificationGroup DESCRIPTION "The group of thresholds crossing notifications." GROUP xdsl2StatusChangeNotificationGroup DESCRIPTION "The group of status change notifications." ::= { xdsl2Compliances 1 } -- units of conformance xdsl2LineGroup OBJECT-GROUP Morgenstern, et al. Standards Track [Page 189] RFC 5650 VDSL2-LINE MIB September 2009 OBJECTS { xdsl2LineConfTemplate, xdsl2LineAlarmConfTemplate, xdsl2LineCmndConfPmsf, xdsl2LineCmndConfLdsf, xdsl2LineCmndConfLdsfFailReason, xdsl2LineCmndAutomodeColdStart, xdsl2LineCmndConfReset, xdsl2LineStatusXtuTransSys, xdsl2LineStatusPwrMngState, xdsl2LineStatusInitResult, xdsl2LineStatusLastStateDs, xdsl2LineStatusLastStateUs, xdsl2LineStatusXtur, xdsl2LineStatusXtuc, xdsl2LineStatusAttainableRateDs, xdsl2LineStatusAttainableRateUs, xdsl2LineStatusActPsdDs, xdsl2LineStatusActPsdUs, xdsl2LineStatusActAtpDs, xdsl2LineStatusActAtpUs, xdsl2LineStatusActProfile, xdsl2LineStatusActLimitMask, xdsl2LineStatusActUs0Mask, xdsl2LineStatusActSnrModeDs, xdsl2LineStatusActSnrModeUs, xdsl2LineStatusElectricalLength, xdsl2LineStatusTssiDs, xdsl2LineStatusTssiUs, xdsl2LineStatusMrefPsdDs, xdsl2LineStatusMrefPsdUs, xdsl2LineStatusTrellisDs, xdsl2LineStatusTrellisUs, xdsl2LineStatusActualCe, xdsl2LineBandStatusLnAtten, xdsl2LineBandStatusSigAtten, xdsl2LineBandStatusSnrMargin } STATUS current DESCRIPTION "The group of configuration, status, and commands objects on the line level." ::= { xdsl2Groups 1 } xdsl2LineFallbackGroup OBJECT-GROUP OBJECTS { Morgenstern, et al. Standards Track [Page 190] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2LineConfFallbackTemplate, xdsl2LineStatusActTemplate } STATUS current DESCRIPTION "The group of configuration, status, and commands objects on the line level that are associated with the fallback feature." ::= { xdsl2Groups 2 } xdsl2LineBpscGroup OBJECT-GROUP OBJECTS { xdsl2LineCmndConfBpsc, xdsl2LineCmndConfBpscFailReason, xdsl2LineCmndConfBpscRequests } STATUS current DESCRIPTION "The group of configuration, status, and commands objects on the line level that are associated with requesting a bits-per-subcarrier measurement." ::= { xdsl2Groups 3 } xdsl2LineSegmentGroup OBJECT-GROUP OBJECTS { xdsl2LineSegmentBitsAlloc, xdsl2LineSegmentRowStatus } STATUS current DESCRIPTION "The group of status and commands objects on the line level that are used to hold the results of the bits-per-subcarrier measurement." ::= { xdsl2Groups 4 } xdsl2ChannelStatusGroup OBJECT-GROUP OBJECTS { xdsl2ChStatusActDataRate, xdsl2ChStatusPrevDataRate, xdsl2ChStatusActDelay, xdsl2ChStatusActInp, xdsl2ChStatusInpReport, xdsl2ChStatusNFec, xdsl2ChStatusRFec, xdsl2ChStatusLSymb, Morgenstern, et al. Standards Track [Page 191] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2ChStatusIntlvDepth, xdsl2ChStatusIntlvBlock, xdsl2ChStatusLPath } STATUS current DESCRIPTION "The group of status objects on the channel level." ::= { xdsl2Groups 5 } xdsl2ChannelStatusAtmGroup OBJECT-GROUP OBJECTS { xdsl2ChStatusAtmStatus } STATUS current DESCRIPTION "The group of status objects on the data path level when it is ATM." ::= { xdsl2Groups 6 } xdsl2ChannelStatusPtmGroup OBJECT-GROUP OBJECTS { xdsl2ChStatusPtmStatus } STATUS current DESCRIPTION "The group of status objects on the data path level when it is PTM." ::= { xdsl2Groups 7 } xdsl2SCStatusGroup OBJECT-GROUP OBJECTS { xdsl2SCStatusLinScale, xdsl2SCStatusLinScGroupSize, xdsl2SCStatusLogMt, xdsl2SCStatusLogScGroupSize, xdsl2SCStatusQlnMt, xdsl2SCStatusQlnScGroupSize, xdsl2SCStatusSnrMtime, xdsl2SCStatusSnrScGroupSize, xdsl2SCStatusBandLnAtten, xdsl2SCStatusBandSigAtten, xdsl2SCStatusAttainableRate, xdsl2SCStatusRowStatus, xdsl2SCStatusSegmentLinReal, xdsl2SCStatusSegmentLinImg, Morgenstern, et al. Standards Track [Page 192] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2SCStatusSegmentLog, xdsl2SCStatusSegmentQln, xdsl2SCStatusSegmentSnr, xdsl2SCStatusSegmentBitsAlloc, xdsl2SCStatusSegmentGainAlloc } STATUS current DESCRIPTION "The group of status objects on the subcarrier level. They are updated as a result of a DELT process." ::= { xdsl2Groups 8 } xdsl2LineInventoryGroup OBJECT-GROUP OBJECTS { xdsl2LInvG994VendorId, xdsl2LInvSystemVendorId, xdsl2LInvVersionNumber, xdsl2LInvSerialNumber, xdsl2LInvSelfTestResult, xdsl2LInvTransmissionCapabilities } STATUS current DESCRIPTION "The group of inventory objects per xTU." ::= { xdsl2Groups 9 } xdsl2LineConfTemplateGroup OBJECT-GROUP OBJECTS { xdsl2LConfTempLineProfile, xdsl2LConfTempChan1ConfProfile, xdsl2LConfTempChan1RaRatioDs, xdsl2LConfTempChan1RaRatioUs, xdsl2LConfTempChan2ConfProfile, xdsl2LConfTempChan2RaRatioDs, xdsl2LConfTempChan2RaRatioUs, xdsl2LConfTempChan3ConfProfile, xdsl2LConfTempChan3RaRatioDs, xdsl2LConfTempChan3RaRatioUs, xdsl2LConfTempChan4ConfProfile, xdsl2LConfTempChan4RaRatioDs, xdsl2LConfTempChan4RaRatioUs, xdsl2LConfTempRowStatus } STATUS current DESCRIPTION "The group of objects in a line configuration Morgenstern, et al. Standards Track [Page 193] RFC 5650 VDSL2-LINE MIB September 2009 template." ::= { xdsl2Groups 10 } xdsl2LineConfProfGroup OBJECT-GROUP OBJECTS { xdsl2LConfProfScMaskDs, xdsl2LConfProfScMaskUs, xdsl2LConfProfVdsl2CarMask, xdsl2LConfProfRfiBands, xdsl2LConfProfRaModeDs, xdsl2LConfProfRaModeUs, xdsl2LConfProfTargetSnrmDs, xdsl2LConfProfTargetSnrmUs, xdsl2LConfProfMaxSnrmDs, xdsl2LConfProfMaxSnrmUs, xdsl2LConfProfMinSnrmDs, xdsl2LConfProfMinSnrmUs, xdsl2LConfProfCeFlag, xdsl2LConfProfSnrModeDs, xdsl2LConfProfSnrModeUs, xdsl2LConfProfTxRefVnDs, xdsl2LConfProfTxRefVnUs, xdsl2LConfProfXtuTransSysEna, xdsl2LConfProfPmMode, xdsl2LConfProfL0Time, xdsl2LConfProfL2Time, xdsl2LConfProfL2Atpr, xdsl2LConfProfL2Atprt, xdsl2LConfProfProfiles, xdsl2LConfProfDpboEPsd, xdsl2LConfProfDpboEsEL, xdsl2LConfProfDpboEsCableModelA, xdsl2LConfProfDpboEsCableModelB, xdsl2LConfProfDpboEsCableModelC, xdsl2LConfProfDpboMus, xdsl2LConfProfDpboFMin, xdsl2LConfProfDpboFMax, xdsl2LConfProfUpboKL, xdsl2LConfProfUpboKLF, xdsl2LConfProfUs0Mask, xdsl2LConfProfForceInp, xdsl2LConfProfRowStatus } STATUS current DESCRIPTION "The group of objects in a line configuration profile." Morgenstern, et al. Standards Track [Page 194] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2Groups 11 } xdsl2LineConfProfRaGroup OBJECT-GROUP OBJECTS { xdsl2LConfProfRaUsNrmDs, xdsl2LConfProfRaUsNrmUs, xdsl2LConfProfRaUsTimeDs, xdsl2LConfProfRaUsTimeUs, xdsl2LConfProfRaDsNrmDs, xdsl2LConfProfRaDsNrmUs, xdsl2LConfProfRaDsTimeDs, xdsl2LConfProfRaDsTimeUs } STATUS current DESCRIPTION "The group of objects required for controlling the rate-adaptive behavior of the line." ::= { xdsl2Groups 12 } xdsl2LineConfProfMsgMinGroup OBJECT-GROUP OBJECTS { xdsl2LConfProfMsgMinUs, xdsl2LConfProfMsgMinDs } STATUS current DESCRIPTION "The group of objects required for controlling the rate reserved for Overhead traffic." ::= { xdsl2Groups 13 } xdsl2LineConfProfModeSpecGroup OBJECT-GROUP OBJECTS { xdsl2LConfProfMaxNomPsdDs, xdsl2LConfProfMaxNomPsdUs, xdsl2LConfProfMaxNomAtpDs, xdsl2LConfProfMaxNomAtpUs, xdsl2LConfProfMaxAggRxPwrUs, xdsl2LConfProfPsdMaskDs, xdsl2LConfProfPsdMaskUs, xdsl2LConfProfPsdMaskSelectUs, xdsl2LConfProfClassMask, xdsl2LConfProfLimitMask, xdsl2LConfProfUs0Disable, xdsl2LConfProfModeSpecRowStatus } Morgenstern, et al. Standards Track [Page 195] RFC 5650 VDSL2-LINE MIB September 2009 STATUS current DESCRIPTION "The group of objects in a line configuration profile that have an instance for each operation mode allowed." ::= { xdsl2Groups 14 } xdsl2LineConfProfModeSpecBandUsGroup OBJECT-GROUP OBJECTS { xdsl2LConfProfUpboPsdA, xdsl2LConfProfUpboPsdB, xdsl2LConfProfModeSpecBandUsRowStatus } STATUS current DESCRIPTION "The group of objects in a line configuration profile that have several per-upstream-band instances for each operation mode allowed." ::= { xdsl2Groups 15 } xdsl2ChConfProfileGroup OBJECT-GROUP OBJECTS { xdsl2ChConfProfMinDataRateDs, xdsl2ChConfProfMinDataRateUs, xdsl2ChConfProfMaxDataRateDs, xdsl2ChConfProfMaxDataRateUs, xdsl2ChConfProfMinDataRateLowPwrDs, xdsl2ChConfProfMinDataRateLowPwrUs, xdsl2ChConfProfMaxDelayDs, xdsl2ChConfProfMaxDelayUs, xdsl2ChConfProfMinProtectionDs, xdsl2ChConfProfMinProtectionUs, xdsl2ChConfProfMinProtection8Ds, xdsl2ChConfProfMinProtection8Us, xdsl2ChConfProfMaxBerDs, xdsl2ChConfProfMaxBerUs, xdsl2ChConfProfUsDataRateDs, xdsl2ChConfProfDsDataRateDs, xdsl2ChConfProfUsDataRateUs, xdsl2ChConfProfDsDataRateUs, xdsl2ChConfProfRowStatus } STATUS current DESCRIPTION "The group of objects in a channel configuration profile." ::= { xdsl2Groups 16 } Morgenstern, et al. Standards Track [Page 196] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2ChConfProfileAtmGroup OBJECT-GROUP OBJECTS { xdsl2ChConfProfImaEnabled, xdsl2ChStatusAtmStatus } STATUS current DESCRIPTION "The group of configuration objects required when the data path is ATM." ::= { xdsl2Groups 17 } xdsl2ChConfProfileMinResGroup OBJECT-GROUP OBJECTS { xdsl2ChConfProfMinResDataRateDs, xdsl2ChConfProfMinResDataRateUs } STATUS current DESCRIPTION "The group of configuration objects required for the reserved data rate." ::= { xdsl2Groups 18 } xdsl2ChConfProfileOptAttrGroup OBJECT-GROUP OBJECTS { xdsl2ChConfProfMaxDelayVar, xdsl2ChConfProfInitPolicy } STATUS current DESCRIPTION "The group of various optional channel configuration parameters." ::= { xdsl2Groups 19 } xdsl2LineAlarmConfTemplateGroup OBJECT-GROUP OBJECTS { xdsl2LAlarmConfTempLineProfile, xdsl2LAlarmConfTempChan1ConfProfile, xdsl2LAlarmConfTempChan2ConfProfile, xdsl2LAlarmConfTempChan3ConfProfile, xdsl2LAlarmConfTempChan4ConfProfile, xdsl2LAlarmConfTempRowStatus } STATUS current DESCRIPTION "The group of objects in a line alarm template." Morgenstern, et al. Standards Track [Page 197] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2Groups 20 } xdsl2LineAlarmConfProfileGroup OBJECT-GROUP OBJECTS { xdsl2LineAlarmConfProfileXtucThresh15MinFecs, xdsl2LineAlarmConfProfileXtucThresh15MinEs, xdsl2LineAlarmConfProfileXtucThresh15MinSes, xdsl2LineAlarmConfProfileXtucThresh15MinLoss, xdsl2LineAlarmConfProfileXtucThresh15MinUas, xdsl2LineAlarmConfProfileXturThresh15MinFecs, xdsl2LineAlarmConfProfileXturThresh15MinEs, xdsl2LineAlarmConfProfileXturThresh15MinSes, xdsl2LineAlarmConfProfileXturThresh15MinLoss, xdsl2LineAlarmConfProfileXturThresh15MinUas, xdsl2LineAlarmConfProfileThresh15MinFailedFullInt, xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt, xdsl2LineAlarmConfProfileRowStatus } STATUS current DESCRIPTION "The group of objects in a line alarm profile." ::= { xdsl2Groups 21 } xdsl2ChAlarmConfProfileGroup OBJECT-GROUP OBJECTS { xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations, xdsl2ChAlarmConfProfileXtucThresh15MinCorrected, xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations, xdsl2ChAlarmConfProfileXturThresh15MinCorrected, xdsl2ChAlarmConfProfileRowStatus } STATUS current DESCRIPTION "The group of objects in a channel alarm profile." ::= { xdsl2Groups 22 } xdsl2PMLineCurrGroup OBJECT-GROUP OBJECTS { xdsl2PMLCurr15MValidIntervals, xdsl2PMLCurr15MInvalidIntervals, xdsl2PMLCurr15MTimeElapsed, xdsl2PMLCurr15MFecs, xdsl2PMLCurr15MEs, xdsl2PMLCurr15MSes, xdsl2PMLCurr15MLoss, Morgenstern, et al. Standards Track [Page 198] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMLCurr15MUas, xdsl2PMLCurr1DayValidIntervals, xdsl2PMLCurr1DayInvalidIntervals, xdsl2PMLCurr1DayTimeElapsed, xdsl2PMLCurr1DayFecs, xdsl2PMLCurr1DayEs, xdsl2PMLCurr1DaySes, xdsl2PMLCurr1DayLoss, xdsl2PMLCurr1DayUas } STATUS current DESCRIPTION "The group of objects that report the line-level counters for current PM intervals." ::= { xdsl2Groups 23 } xdsl2PMLineInitCurrGroup OBJECT-GROUP OBJECTS { xdsl2PMLInitCurr15MValidIntervals, xdsl2PMLInitCurr15MInvalidIntervals, xdsl2PMLInitCurr15MTimeElapsed, xdsl2PMLInitCurr15MFullInits, xdsl2PMLInitCurr15MFailedFullInits, xdsl2PMLInitCurr1DayValidIntervals, xdsl2PMLInitCurr1DayInvalidIntervals, xdsl2PMLInitCurr1DayTimeElapsed, xdsl2PMLInitCurr1DayFullInits, xdsl2PMLInitCurr1DayFailedFullInits } STATUS current DESCRIPTION "The group of objects that report the full initialization counters for current PM intervals." ::= { xdsl2Groups 24 } xdsl2PMLineInitCurrShortGroup OBJECT-GROUP OBJECTS { xdsl2PMLInitCurr15MShortInits, xdsl2PMLInitCurr15MFailedShortInits, xdsl2PMLInitCurr1DayShortInits, xdsl2PMLInitCurr1DayFailedShortInits } STATUS current DESCRIPTION "The group of objects that report the short initialization counters for current PM intervals." Morgenstern, et al. Standards Track [Page 199] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2Groups 25 } xdsl2PMLineHist15MinGroup OBJECT-GROUP OBJECTS { xdsl2PMLHist15MMonitoredTime, xdsl2PMLHist15MFecs, xdsl2PMLHist15MEs, xdsl2PMLHist15MSes, xdsl2PMLHist15MLoss, xdsl2PMLHist15MUas, xdsl2PMLHist15MValidInterval } STATUS current DESCRIPTION "The group of line-level PM counters for the previous 15-minute intervals." ::= { xdsl2Groups 26 } xdsl2PMLineHist1DayGroup OBJECT-GROUP OBJECTS { xdsl2PMLHist1DMonitoredTime, xdsl2PMLHist1DFecs, xdsl2PMLHist1DEs, xdsl2PMLHist1DSes, xdsl2PMLHist1DLoss, xdsl2PMLHist1DUas, xdsl2PMLHist1DValidInterval } STATUS current DESCRIPTION "The group of line-level PM counters for the previous 24-hour intervals." ::= { xdsl2Groups 27 } xdsl2PMLineInitHist15MinGroup OBJECT-GROUP OBJECTS { xdsl2PMLInitHist15MMonitoredTime, xdsl2PMLInitHist15MFullInits, xdsl2PMLInitHist15MFailedFullInits, xdsl2PMLInitHist15MValidInterval } STATUS current DESCRIPTION "The group of PM counters for the previous 15-minute interval full initializations." Morgenstern, et al. Standards Track [Page 200] RFC 5650 VDSL2-LINE MIB September 2009 ::= { xdsl2Groups 28 } xdsl2PMLineInitHist15MinShortGroup OBJECT-GROUP OBJECTS { xdsl2PMLInitHist15MShortInits, xdsl2PMLInitHist15MFailedShortInits } STATUS current DESCRIPTION "The group of PM counters for the previous 15-minute interval short initializations." ::= { xdsl2Groups 29 } xdsl2PMLineInitHist1DayGroup OBJECT-GROUP OBJECTS { xdsl2PMLInitHist1DMonitoredTime, xdsl2PMLInitHist1DFullInits, xdsl2PMLInitHist1DFailedFullInits, xdsl2PMLInitHist1DValidInterval } STATUS current DESCRIPTION "The group of PM counters for the previous 24-hour interval full initializations." ::= { xdsl2Groups 30 } xdsl2PMLineInitHist1DayShortGroup OBJECT-GROUP OBJECTS { xdsl2PMLInitHist1DShortInits, xdsl2PMLInitHist1DFailedShortInits } STATUS current DESCRIPTION "The group of PM counters for the previous 24-hour interval short initializations." ::= { xdsl2Groups 31 } xdsl2PMChCurrGroup OBJECT-GROUP OBJECTS { xdsl2PMChCurr15MValidIntervals, xdsl2PMChCurr15MInvalidIntervals, xdsl2PMChCurr15MTimeElapsed, xdsl2PMChCurr15MCodingViolations, xdsl2PMChCurr15MCorrectedBlocks, Morgenstern, et al. Standards Track [Page 201] RFC 5650 VDSL2-LINE MIB September 2009 xdsl2PMChCurr1DayValidIntervals, xdsl2PMChCurr1DayInvalidIntervals, xdsl2PMChCurr1DayTimeElapsed, xdsl2PMChCurr1DayCodingViolations, xdsl2PMChCurr1DayCorrectedBlocks } STATUS current DESCRIPTION "The group of objects that report the channel-level counters for current PM intervals." ::= { xdsl2Groups 32 } xdsl2PMChHist15MinGroup OBJECT-GROUP OBJECTS { xdsl2PMChHist15MMonitoredTime, xdsl2PMChHist15MCodingViolations, xdsl2PMChHist15MCorrectedBlocks, xdsl2PMChHist15MValidInterval } STATUS current DESCRIPTION "The group of objects that report the channel-level counters for previous 15-minute PM intervals." ::= { xdsl2Groups 33 } xdsl2PMChHist1DGroup OBJECT-GROUP OBJECTS { xdsl2PMChHist1DMonitoredTime, xdsl2PMChHist1DCodingViolations, xdsl2PMChHist1DCorrectedBlocks, xdsl2PMChHist1DValidInterval } STATUS current DESCRIPTION "The group of objects that report the channel-level counters for previous 24-hour PM intervals." ::= { xdsl2Groups 34 } xdsl2ScalarSCGroup OBJECT-GROUP OBJECTS { xdsl2ScalarSCMaxInterfaces, xdsl2ScalarSCAvailInterfaces } STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 202] RFC 5650 VDSL2-LINE MIB September 2009 "The group of objects that report the available memory resources for DELT processes." ::= { xdsl2Groups 35 } xdsl2ThreshNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { xdsl2LinePerfFECSThreshXtuc, xdsl2LinePerfFECSThreshXtur, xdsl2LinePerfESThreshXtuc, xdsl2LinePerfESThreshXtur, xdsl2LinePerfSESThreshXtuc, xdsl2LinePerfSESThreshXtur, xdsl2LinePerfLOSSThreshXtuc, xdsl2LinePerfLOSSThreshXtur, xdsl2LinePerfUASThreshXtuc, xdsl2LinePerfUASThreshXtur, xdsl2LinePerfCodingViolationsThreshXtuc, xdsl2LinePerfCodingViolationsThreshXtur, xdsl2LinePerfCorrectedThreshXtuc, xdsl2LinePerfCorrectedThreshXtur, xdsl2LinePerfFailedFullInitThresh, xdsl2LinePerfFailedShortInitThresh } STATUS current DESCRIPTION "This group supports notifications of significant conditions associated with DSL lines." ::= { xdsl2Groups 36 } xdsl2StatusChangeNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { xdsl2LineStatusChangeXtuc, xdsl2LineStatusChangeXtur } STATUS current DESCRIPTION "This group supports notifications of thresholds crossing associated with DSL lines." ::= { xdsl2Groups 37 } END 4. Implementation Analysis A management application intended to manage ADSL links (e.g., G.992.1) with this MIB module MUST be modified to adapt itself to Morgenstern, et al. Standards Track [Page 203] RFC 5650 VDSL2-LINE MIB September 2009 certain differences between RFC 2662 [RFC2662] and this MIB module, including the following aspects: o Though the configuration templates/profiles allow referring to 1-4 bearer channels, ADSL links are limited to two channels at most. o Though the channel configuration profile allows higher data rates, ADSL links are limited to downstream/upstream data rate as assumed in RFC 2662 [RFC2662]. o The Impulse Noise Protection (INP) configuration parameters are given by minimum protection and maximum delay parameters. o The line configuration profile includes a sub-table that addresses mode-specific parameters. For ADSL links, the management application SHOULD create a row in that table for the ADSL modes only. o The line configuration profile includes parameters that are irrelevant for ADSL links. Similarly, many status parameters in the MIB are irrelevant for certain ADSL modes. Therefore, it is advised to consult with ITU G.997.1 standard [G.997.1] regarding the scope and relevance of each parameter in this MIB. 5. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure Morgenstern, et al. Standards Track [Page 204] RFC 5650 VDSL2-LINE MIB September 2009 environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o xdsl2LineTable The table consists of the following objects that support SET operations: * xdsl2LineConfTemplate * xdsl2LineConfFallbackTemplate * xdsl2LineAlarmConfTemplate * xdsl2LineCmndConfPmsf * xdsl2LineCmndConfLdsf * xdsl2LineCmndConfBpsc * xdsl2LineCmndAutomodeColdStart * xdsl2LineCmndConfReset Unauthorized changes to xdsl2LineConfTemplate could have a major adverse operational effect on many lines simultaneously. Unauthorized changes to xdsl2LineConfFallbackTemplate could have a major adverse operational effect on many lines simultaneously. Unauthorized changes to xdsl2LineAlarmConfTemplate could have a contrary effect on notifications. Unauthorized changes to xdsl2LineCmndConfPmsf could have an adverse affect on the power consumption of a line and may disrupt an operational service. Unauthorized changes to xdsl2LineCmndConfLdsf could cause an unscheduled line test to be carried out on the line. Unauthorized changes to xdsl2LineCmndConfBpsc could cause an unscheduled bits-per-subcarrier measurement to be carried out on the line. Unauthorized changes to xdsl2LineCmndAutomodeColdStart could cause an unscheduled cold reset to the line. Morgenstern, et al. Standards Track [Page 205] RFC 5650 VDSL2-LINE MIB September 2009 Unauthorized changes to xdsl2LineCmndConfReset could cause a unscheduled retrain of a line. o xdsl2LineSegmentTable This table contains one object, xdsl2LineSegmentRowStatus, that supports SET operations. Unauthorized changes could result in measurement results being deleted prematurely. o xdsl2SCStatusTable This table contains one object, xdsl2SCStatusRowStatus, that supports SET operations. Unauthorized changes could result in line test results being deleted prematurely. o xdsl2LineConfTemplateTable The table consists of the following objects that support SET operations: * xdsl2LConfTempLineProfile * xdsl2LConfTempChan1ConfProfile * xdsl2LConfTempChan1RaRatioDs * xdsl2LConfTempChan1RaRatioUs * xdsl2LConfTempChan2ConfProfile * xdsl2LConfTempChan2RaRatioDs * xdsl2LConfTempChan2RaRatioUs * xdsl2LConfTempChan3ConfProfile * xdsl2LConfTempChan3RaRatioDs * xdsl2LConfTempChan3RaRatioUs * xdsl2LConfTempChan4ConfProfile * xdsl2LConfTempChan4RaRatioDs * xdsl2LConfTempChan4RaRatioUs * xdsl2LConfTempRowStatus Morgenstern, et al. Standards Track [Page 206] RFC 5650 VDSL2-LINE MIB September 2009 Unauthorized changes to xdsl2LConfTempLineProfile, xdsl2LConfTempChan1ConfProfile, xdsl2LConfTempChan2ConfProfile, xdsl2LConfTempChan3ConfProfile, or xdsl2LConfTempChan4ConfProfile could have an adverse operational effect on several lines; could change several lines over to running in unwanted levels of operation; or could result in several services undergoing changes in the number of channels that carry the service. Unauthorized changes to xdsl2LConfTempChan1RaRatioDs, xdsl2LConfTempChan2RaRatioDs, xdsl2LConfTempChan3RaRatioDs, or xdsl2LConfTempChan4RaRatioDs would alter the relative rate allocations among all channels belonging to a line. This could have an adverse operational effect on several lines. Unauthorized changes to xdsl2LConfTempRowStatus could result in templates being created or brought into service prematurely, or they could result in templates being inadvertently deleted or taken out of service. o xdsl2LineConfProfTable The table consists of the following objects that support SET operations: * xdsl2LConfProfScMaskDs * xdsl2LConfProfScMaskUs * xdsl2LConfProfRfiBandsDs * xdsl2LConfProfRaModeDs * xdsl2LConfProfRaModeUs * xdsl2LConfProfRaUsNrmDs * xdsl2LConfProfRaUsNrmUs * xdsl2LConfProfRaUsTimeDs * xdsl2LConfProfRaUsTimeUs * xdsl2LConfProfRaDsNrmDs * xdsl2LConfProfRaDsNrmUs * xdsl2LConfProfRaDsTimeDs Morgenstern, et al. Standards Track [Page 207] RFC 5650 VDSL2-LINE MIB September 2009 * xdsl2LConfProfRaDsTimeUs * xdsl2LConfProfTargetSnrmDs * xdsl2LConfProfTargetSnrmUs * xdsl2LConfProfMaxSnrmDs * xdsl2LConfProfMaxSnrmUs * xdsl2LConfProfMinSnrmDs * xdsl2LConfProfMinSnrmUs * xdsl2LConfProfMsgMinUs * xdsl2LConfProfMsgMinDs * xdsl2LConfProfCeFlag * xdsl2LConfProfSnrModeDs * xdsl2LConfProfSnrModeUs * xdsl2LConfProfTxRefVnDs * xdsl2LConfProfTxRefVnUs * xdsl2LConfProfXtuTransSysEna * xdsl2LConfProfPmMode * xdsl2LConfProfL0Time * xdsl2LConfProfL2Time * xdsl2LConfProfL2Atpr * xdsl2LConfProfL2Atprt * xdsl2LConfProfProfiles * xdsl2LConfProfDpboEPsd * xdsl2LConfProfDpboEsEL * xdsl2LConfProfDpboEsCableModelA Morgenstern, et al. Standards Track [Page 208] RFC 5650 VDSL2-LINE MIB September 2009 * xdsl2LConfProfDpboEsCableModelB * xdsl2LConfProfDpboEsCableModelC * xdsl2LConfProfDpboMus * xdsl2LConfProfDpboFMin * xdsl2LConfProfDpboFMax * xdsl2LConfProfUpboKL * xdsl2LConfProfUpboKLF * xdsl2LConfProfUs0Mask * xdsl2LConfProfForceInp * xdsl2LConfProfRowStatus Unauthorized changes resulting in the setting of any of the above objects to an incorrect value could have an adverse operational effect on several lines. Also, unauthorized changes to xdsl2LConfProfRowStatus could result in unwanted line profiles being created or brought into service prematurely, or they could result in line profiles being inadvertently deleted or taken out of service. o xdsl2LineConfProfModeSpecTable The table consists of the following objects that support SET operations: * xdsl2LConfProfMaxNomPsdDs * xdsl2LConfProfMaxNomPsdUs * xdsl2LConfProfMaxNomAtpDs * xdsl2LConfProfMaxNomAtpUs * xdsl2LConfProfMaxAggRxPwrUs * xdsl2LConfProfPsdMaskDs * xdsl2LConfProfPsdMaskUs Morgenstern, et al. Standards Track [Page 209] RFC 5650 VDSL2-LINE MIB September 2009 * xdsl2LConfProfPsdMaskSelectUs * xdsl2LConfProfClassMask * xdsl2LConfProfLimitMask * xdsl2LConfProfUs0Disable * xdsl2LConfProfModeSpecRowStatus Unauthorized changes resulting in the setting of any of the above objects to an incorrect value could have an adverse operational effect on several lines. Also, unauthorized changes to xdsl2LConfProfModeSpecRowStatus could result in unwanted PSD configurations being created or brought into service prematurely, or they could result in PSD configurations being inadvertently deleted or taken out of service. o xdsl2LineConfProfModeSpecBandUsTable The table consists of the following objects that support SET operations: * xdsl2LConfProfUpboPsdA * xdsl2LConfProfUpboPsdB * xdsl2LConfProfModeSpecRowStatus Unauthorized changes resulting in the setting of any of the above objects to an incorrect value could have an adverse operational effect on several lines. Also, unauthorized changes to xdsl2LConfProfModeSpecBandUsRowStatus could result in unwanted PSD configurations being created or brought into service prematurely, or they could result in PSD configurations being inadvertently deleted or taken out of service. o xdsl2ChConfProfileTable The table consists of the following objects that support SET operations: * xdsl2ChConfProfMinDataRateDs Morgenstern, et al. Standards Track [Page 210] RFC 5650 VDSL2-LINE MIB September 2009 * xdsl2ChConfProfMinDataRateUs * xdsl2ChConfProfMinResDataRateDs * xdsl2ChConfProfMinResDataRateUs * xdsl2ChConfProfMaxDataRateDs * xdsl2ChConfProfMaxDataRateUs * xdsl2ChConfProfMinDataRateLowPwrDs * xdsl2ChConfProfMinDataRateLowPwrUs * xdsl2ChConfProfMaxDelayDs * xdsl2ChConfProfMaxDelayUs * xdsl2ChConfProfMinProtectionDs * xdsl2ChConfProfMinProtectionUs * xdsl2ChConfProfMinProtection8Ds * xdsl2ChConfProfMinProtection8Us * xdsl2ChConfProfMaxBerDs * xdsl2ChConfProfMaxBerUs * xdsl2ChConfProfUsDataRateDs * xdsl2ChConfProfDsDataRateDs * xdsl2ChConfProfUsDataRateUs * xdsl2ChConfProfDsDataRateUs * xdsl2ChConfProfImaEnabled * xdsl2ChConfProfMaxDelayVar * xdsl2ChConfProfInitPolicy * xdsl2ChConfProfRowStatus Morgenstern, et al. Standards Track [Page 211] RFC 5650 VDSL2-LINE MIB September 2009 Unauthorized changes resulting in the setting of any of the above objects to an incorrect value could have an adverse operational effect on several lines. Also, unauthorized changes to xdsl2ChConfProfRowStatus could result in unwanted channel profiles being created or brought into service prematurely, or they could result in channel profiles being inadvertently deleted or taken out of service. o xdsl2LineAlarmConfTemplateTable The table consists of the following objects that support SET operations: * xdsl2LAlarmConfTempLineProfile * xdsl2LAlarmConfTempChan1ConfProfile * xdsl2LalarmConfTempChan2ConfProfile * xdsl2LalarmConfTempChan3ConfProfile * xdsl2LalarmConfTempChan4ConfProfile * xdsl2LAlarmConfTempRowStatus Unauthorized changes to xdsl2LAlarmConfTempLineProfile, xdsl2LAlarmConfTempChan1ConfProfile, xdsl2LAlarmConfTempChan2ConfProfile, xdsl2LAlarmConfTempChan3ConfProfile, or xdsl2LAlarmConfTempChan4ConfProfile could have an adverse effect on the management of notifications generated at the scope of several to many lines, or they could change several to many lines over to running with unwanted management rates for generated notifications. Unauthorized changes to xdsl2LAlarmConfTempRowStatus could result in alarm templates being created or brought into service prematurely, or they could result in alarm templates being inadvertently deleted or taken out of service. o xdsl2LineAlarmConfProfileTable The table consists of the following objects that support SET operations: * xdsl2LineAlarmConfProfileXtucThresh15MinFecs Morgenstern, et al. Standards Track [Page 212] RFC 5650 VDSL2-LINE MIB September 2009 * xdsl2LineAlarmConfProfileXtucThresh15MinEs * xdsl2LineAlarmConfProfileXtucThresh15MinSes * xdsl2LineAlarmConfProfileXtucThresh15MinLoss * xdsl2LineAlarmConfProfileXtucThresh15MinUas * xdsl2LineAlarmConfProfileXturThresh15MinFecs * xdsl2LineAlarmConfProfileXturThresh15MinEs * xdsl2LineAlarmConfProfileXturThresh15MinSes * xdsl2LineAlarmConfProfileXturThresh15MinLoss * xdsl2LineAlarmConfProfileXturThresh15MinUas * xdsl2LineAlarmConfProfileThresh15MinFailedFullInt * xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt * xdsl2LineAlarmConfProfileRowStatus Increasing any of the threshold values could result in a notification being suppressed or deferred. Setting a threshold to '0' could result in a notification being suppressed. Suppressing or deferring a notification could prevent the timely delivery of important diagnostic information. Decreasing any of the threshold values could result in a notification being sent from the network falsely reporting a threshold crossing. Unauthorized changes to row status could result in unwanted line alarm profiles being created or brought into service. Also, changes to the row status could result in line alarm profiles being inadvertently deleted or taken out of service. o xdsl2ChAlarmConfProfileTable The table consists of the following objects that support SET operations: * xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations * xdsl2ChAlarmConfProfileXtucThresh15MinCorrected * xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations Morgenstern, et al. Standards Track [Page 213] RFC 5650 VDSL2-LINE MIB September 2009 * xdsl2ChAlarmConfProfileXturThresh15MinCorrected * xdsl2ChAlarmConfProfileRowStatus * xdsl2LineAlarmConfProfileXturThresh15MinFecs * xdsl2LineAlarmConfProfileXturThresh15MinEs * xdsl2LineAlarmConfProfileXturThresh15MinSes * xdsl2LineAlarmConfProfileXturThresh15MinLoss * xdsl2LineAlarmConfProfileXturThresh15MinUas * xdsl2LineAlarmConfProfileThresh15MinFailedFullInt * xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt * xdsl2LineAlarmConfProfileRowStatus Increasing any of the threshold values could result in a notification being suppressed or deferred. Setting a threshold to '0' could result in a notification being suppressed. Suppressing or deferring a notification could prevent the timely delivery of important diagnostic information. Decreasing any of the threshold values could result in a notification being sent from the network falsely reporting a threshold crossing. Unauthorized changes to row status could result in unwanted channel alarm profiles being created or brought into service. Also, changes to the row status could result in channel alarm profiles being inadvertently deleted or taken out of service. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o xdsl2LineInventoryTable Access to these objects would allow an intruder to obtain information about which vendor's equipment is in use on the network. Further, such information is considered sensitive in many environments for competitive reasons. Morgenstern, et al. Standards Track [Page 214] RFC 5650 VDSL2-LINE MIB September 2009 * xdsl2LInvG994VendorId * xdsl2LInvSystemVendorId * xdsl2LInvVersionNumber * xdsl2LInvSerialNumber * xdsl2LInvSelfTestResult * xdsl2LInvTransmissionCapabilities SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). It is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access only to those objects whose principals (users) have legitimate rights to indeed GET or SET (change/create/delete) them. 6. Acknowledgments The authors are deeply grateful to the authors of the HDSL2 LINE MIB (RFC 4319), Clay Sikes and Bob Ray, for contributing to accelerating the work on this document. The structure of this document as well as several paragraphs originate in their document. Other contributions and advice were received from the following: Randy Presuhn (Mindspring) Chen Jian (Huawei) Bert Wijnen (Lucent) Brian Johnson (NEC Australia) Andrew Cheers (NEC Australia) Sedat Akca (NEC Australia) Victor Sperry (Calix Networks) Narendranath Nair (Wipro) Uwe Pauluhn (Infineon) Morgenstern, et al. Standards Track [Page 215] RFC 5650 VDSL2-LINE MIB September 2009 John D. Boyle (Alcatel) Edward Beili (Actelis) Dan Romascanu (Avaya) David Harrington (Comcast) Smadar Tauber (RAD Data Communications) Richard Barnes (BBN Technologies) 7. References 7.1. Normative References [G.992.1] "Asymmetric digital subscriber line (ADSL) transceivers", ITU-T G.992.1, 1999. [G.992.2] "Splitterless asymmetric digital subscriber line (ADSL) transceivers", ITU-T G.992.2, 1999. [G.992.3] "Asymmetric digital subscriber line transceivers 2 (ADSL2)", ITU-T G.992.3, 2002. [G.992.4] "Splitterless asymmetric digital subscriber line transceivers 2 (Splitterless ADSL2)", ITU-T G.992.4, 2002. [G.992.5] "Asymmetric digital subscriber line (ADSL) transceivers - Extended bandwidth ADSL2 (ADSL2+)", ITU-T G.992.5, 2005. [G.993.1] "Very-high speed Digital Subscriber Line Transceivers", ITU-T G.993.1, June 2004. [G.993.2] "Very-high speed Digital Subscriber Line Transceivers 2 (VDSL2 draft)", ITU-T G.993.2, February 2006. [G.997.1] "Physical layer management for digital subscriber line (DSL) transceivers", ITU-T G.997.1, June 2006. [G.997.1-Am1] "Physical layer management for digital subscriber line (DSL) transceivers - Amendment 1", ITU-T G.997.1- Amendment 1, December 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Morgenstern, et al. Standards Track [Page 216] RFC 5650 VDSL2-LINE MIB September 2009 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003. [RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, February 2004. [T1E1.413] J. Bingham & F. Van der Putten, "Network and Customer Installation Interfaces - Asymmetric Digital Subscriber Line (ADSL) Metallic Interface (T1.413 Issue 2)", ANSI T1E1.413-1998, June 1998. 7.2. Informative References [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, August 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3728] Ray, B. and R. Abbi, "Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)", RFC 3728, February 2004. Morgenstern, et al. Standards Track [Page 217] RFC 5650 VDSL2-LINE MIB September 2009 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4706] Morgenstern, M., Dodge, M., Baillie, S., and U. Bonollo, "Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)", RFC 4706, November 2006. [TR-129] Adams, P., "Protocol Independent Management Model for Next Generation DSL Technologies", DSL Forum TR-129, December 2006. Authors' Addresses Moti Morgenstern ECI Telecom Ltd. 30 Hasivim St. Petach Tikva 49517 Israel Phone: +972 3 926 6258 Fax: +972 3 928 7342 EMail: moti.Morgenstern@ecitele.com Scott Baillie NEC Australia 649-655 Springvale Road Mulgrave, Victoria 3170 Australia Phone: +61 3 9264 3986 Fax: +61 3 9264 3892 EMail: scott.baillie@nec.com.au Umberto Bonollo NEC Australia 649-655 Springvale Road Mulgrave, Victoria 3170 Australia Phone: +61 3 9264 3385 Fax: +61 3 9264 3892 EMail: umberto.bonollo@nec.com.au Morgenstern, et al. Standards Track [Page 218] snmp-mibs-downloader-1.1/mibrfcs/rfc5676.txt0000644000000000000000000012423011402176072015574 0ustar Network Working Group J. Schoenwaelder Request for Comments: 5676 Jacobs University Bremen Category: Standards Track A. Clemm Cisco Systems A. Karmakar Cisco Systems India Pvt Ltd October 2009 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Schoenwaelder, et al. Standards Track [Page 1] RFC 5676 SYSLOG-MSG-MIB October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . . 2 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Relationship to Other MIB Modules . . . . . . . . . . . . . . 4 6. Relationship to the SNMP Notification to SYSLOG Mapping . . . 6 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21 1. Introduction SNMP ([RFC3410], [RFC3411]) and SYSLOG [RFC5424] are two widely used protocols to communicate event notifications. Although co-existence of several management protocols in one operational environment is possible, certain environments require that all event notifications be collected by a single system daemon, such as a SYSLOG collector or an SNMP notification receiver, via a single management protocol. In such environments, it is necessary to translate event notifications between management protocols. This document defines an SNMP MIB module to represent SYSLOG messages and to send SYSLOG messages as SNMP notifications to SNMP notification receivers. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Schoenwaelder, et al. Standards Track [Page 2] RFC 5676 SYSLOG-MSG-MIB October 2009 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Overview SYSLOG messages are translated to SNMP by a SYSLOG-to-SNMP translator. Such a translator acts as a SYSLOG collector [RFC5424] and implements a MIB module according to the SNMP architecture [RFC3411]. The translator might be tightly coupled to an SNMP agent or it might interface with an SNMP agent via a subagent protocol. After initialization, the SYSLOG-to-SNMP translator will listen for SYSLOG messages. On receiving a message, the message will be parsed to extract information as described in the MIB module. A conceptual table is populated with information extracted from the SYSLOG message, and finally a notification may be generated. The MIB module is organized into a group of scalars and two tables. The syslogMsgControl group contains two scalars controlling the maximum size of SYSLOG messages recorded in the tables and also controlling whether SNMP notifications are generated for SYSLOG messages. --syslogMsgObjects(1) | +--syslogMsgControl(1) | +-- Unsigned32 syslogMsgTableMaxSize(1) +-- TruthValue syslogMsgEnableNotifications(2) The syslogMsgTable contains one entry for each recorded SYSLOG message. The basic fields of SYSLOG messages as well as message properties are represented in different columns of the conceptual table. --syslogMsgObjects(1) | +--syslogMsgTable(2) | +--syslogMsgEntry(1) [syslogMsgIndex] | +-- Unsigned32 syslogMsgIndex(1) +-- SyslogFacility syslogMsgFacility(2) +-- SyslogSeverity syslogMsgSeverity(3) +-- Unsigned32 syslogMsgVersion(4) Schoenwaelder, et al. Standards Track [Page 3] RFC 5676 SYSLOG-MSG-MIB October 2009 +-- SyslogTimeStamp syslogMsgTimeStamp(5) +-- DisplayString syslogMsgHostName(6) +-- DisplayString syslogMsgAppName(7) +-- DisplayString syslogMsgProcID(8) +-- DisplayString syslogMsgMsgID(9) +-- Unsigned32 syslogMsgSDParams(10) +-- OctetString syslogMsgMsg(11) The syslogMsgSDTable contains one entry for each structured data element parameter contained in a SYSLOG message. Since structured data elements are optional, the relationship between the syslogMsgTable and the syslogMsgSDTable ranges from one-to-zero to one-to-many. --syslogMsgObjects(1) | +--syslogMsgSDTable(3) | +--syslogMsgSDEntry(1) [syslogMsgIndex, | syslogMsgSDParamIndex, | syslogMsgSDID, | syslogMsgSDParamName] | +-- Unsigned32 syslogMsgSDParamIndex(1) +-- DisplayString syslogMsgSDID(2) +-- DisplayString syslogMsgSDParamName(3) +-- SyslogParamValueString syslogMsgSDParamValue(4) 5. Relationship to Other MIB Modules The NOTIFICATION-LOG-MIB [RFC3014] provides a generic mechanism for logging SNMP notifications in order to deal with lost SNMP notifications, e.g., due to transient communication problems. Applications can poll the notification log to verify that they have not missed important SNMP notifications. The MIB module defined in this memo provides a mechanism for logging SYSLOG notifications. This additional SYSLOG notification log is provided because (a) SYSLOG messages might not lead to SNMP notification (this is configurable) and (b) SNMP notifications might not carry all information associated with a SYSLOG notification. The MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411], and SYSLOG-TC-MIB [RFC5427]. Schoenwaelder, et al. Standards Track [Page 4] RFC 5676 SYSLOG-MSG-MIB October 2009 The textual convention SyslogParamValueString uses the UTF-8 transformation format of the ISO/IEC IS 10646-1 character set defined in [RFC3629]. 6. Relationship to the SNMP Notification to SYSLOG Mapping A companion document [RFC5675] defines a mapping of SNMP notifications to SYSLOG messages. This section discusses the possibilities of using both specifications in combination. A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the mapping of SNMP notifications to SYSLOG messages may be configured to translate received SYSLOG messages containing SNMP notifications back into the original SNMP notification. In this case, the relevant tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG messages carrying SNMP notifications. This configuration allows operators to build a forwarding chain where SNMP notifications are "tunneled" through SYSLOG messages. Due to size restrictions of the SYSLOG transports and the more verbose textual encoding used by SYSLOG, there is a possibility that SNMP notification content will get truncated when tunneled through SYSLOG, and thus the resulting SNMP notification may be incomplete. An SNMP management application supporting the SYSLOG-MSG-MIB and the mapping of SNMP notifications to SYSLOG messages may process information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message representing the SYSLOG message recorded in the SYSLOG-MSG-MIB module. This configuration allows operators to build a forwarding chain where SYSLOG messages are "tunneled" through SNMP messages. A notification receiver can determine whether a syslogMsgNotification contained all structured data element parameters of a SYSLOG message. In case parameters are missing, a forwarding application MUST retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular polling of the SYSLOG-MSG-MIB can be used to take care of any lost SNMP notifications. 7. Definitions SYSLOG-MSG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, TruthValue FROM SNMPv2-TC OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF SyslogFacility, SyslogSeverity Schoenwaelder, et al. Standards Track [Page 5] RFC 5676 SYSLOG-MSG-MIB October 2009 FROM SYSLOG-TC-MIB; syslogMsgMib MODULE-IDENTITY LAST-UPDATED "200908130800Z" ORGANIZATION "IETF OPSAWG Working Group" CONTACT-INFO "Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28757 Bremen Germany Alexander Clemm Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA Anirban Karmakar Cisco Systems India Pvt Ltd SEZ Unit, Cessna Business Park, Sarjapur Marathahalli ORR, Bangalore, Karnataka 560103 India" DESCRIPTION "This MIB module represents SYSLOG messages as SNMP objects. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this MIB module is part of RFC 5676; see the RFC itself for full legal notices." REVISION "200908130800Z" DESCRIPTION "Initial version issued as part of RFC 5676." ::= { mib-2 192 } Schoenwaelder, et al. Standards Track [Page 6] RFC 5676 SYSLOG-MSG-MIB October 2009 -- textual convention definitions SyslogTimeStamp ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d" STATUS current DESCRIPTION "A date-time specification. This type is similar to the DateAndTime type defined in the SNMPv2-TC, except the subsecond granulation is microseconds instead of deciseconds and a zero-length string can be used to indicate a missing value. field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8-10 microseconds* 0..999999 8 11 direction from UTC '+' / '-' 9 12 hours from UTC* 0..13 10 13 minutes from UTC 0..59 * Notes: - the value of year is in network-byte order - the value of microseconds is in network-byte order - daylight saving time in New Zealand is +13 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then timezone information (fields 11-13) is not present." SYNTAX OCTET STRING (SIZE (0 | 10 | 13)) SyslogParamValueString ::= TEXTUAL-CONVENTION DISPLAY-HINT "65535t" STATUS current DESCRIPTION "The value of a SYSLOG SD-PARAM is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in RFC 3629. Schoenwaelder, et al. Standards Track [Page 7] RFC 5676 SYSLOG-MSG-MIB October 2009 Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or that are outside this range are prohibited. Similarly, overlong UTF-8 sequences are prohibited. UTF-8 may require multiple bytes to represent a single character / code point; thus, the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding." REFERENCE "RFC 3629: UTF-8, a transformation format of ISO 10646" SYNTAX OCTET STRING -- object definitions syslogMsgNotifications OBJECT IDENTIFIER ::= { syslogMsgMib 0 } syslogMsgObjects OBJECT IDENTIFIER ::= { syslogMsgMib 1 } syslogMsgConformance OBJECT IDENTIFIER ::= { syslogMsgMib 2 } syslogMsgControl OBJECT IDENTIFIER ::= { syslogMsgObjects 1 } syslogMsgTableMaxSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of SYSLOG messages that may be held in syslogMsgTable. A particular setting does not guarantee that there is sufficient memory available for the maximum number of table entries indicated by this object. A value of 0 means no fixed limit. If an application reduces the limit while there are SYSLOG messages in the syslogMsgTable, the SYSLOG messages that are in the syslogMsgTable for the longest time MUST be discarded to bring the table down to the new limit. The value of this object should be kept in nonvolatile memory." DEFVAL { 0 } ::= { syslogMsgControl 1 } syslogMsgEnableNotifications OBJECT-TYPE Schoenwaelder, et al. Standards Track [Page 8] RFC 5676 SYSLOG-MSG-MIB October 2009 SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether syslogMsgNotification notifications are generated. The value of this object should be kept in nonvolatile memory." DEFVAL { false } ::= { syslogMsgControl 2 } syslogMsgTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslogMsgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing recent SYSLOG messages. The size of the table is controlled by the syslogMsgTableMaxSize object." ::= { syslogMsgObjects 2 } syslogMsgEntry OBJECT-TYPE SYNTAX SyslogMsgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of the syslogMsgTable." INDEX { syslogMsgIndex } ::= { syslogMsgTable 1 } SyslogMsgEntry ::= SEQUENCE { syslogMsgIndex Unsigned32, syslogMsgFacility SyslogFacility, syslogMsgSeverity SyslogSeverity, syslogMsgVersion Unsigned32, syslogMsgTimeStamp SyslogTimeStamp, syslogMsgHostName DisplayString, syslogMsgAppName DisplayString, syslogMsgProcID DisplayString, syslogMsgMsgID DisplayString, syslogMsgSDParams Unsigned32, syslogMsgMsg OCTET STRING } syslogMsgIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current Schoenwaelder, et al. Standards Track [Page 9] RFC 5676 SYSLOG-MSG-MIB October 2009 DESCRIPTION "A monotonically increasing number used to identify entries in the syslogMsgTable. When syslogMsgIndex reaches the maximum value (4294967295), the value wraps back to 1. Applications periodically polling the syslogMsgTable for new entries should take into account that a complete rollover of syslogMsgIndex will happen if more than 4294967294 messages are received during a poll interval." ::= { syslogMsgEntry 1 } syslogMsgFacility OBJECT-TYPE SYNTAX SyslogFacility MAX-ACCESS read-only STATUS current DESCRIPTION "The facility of the SYSLOG message." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.1) RFC 5427: Textual Conventions for Syslog Management" ::= { syslogMsgEntry 2 } syslogMsgSeverity OBJECT-TYPE SYNTAX SyslogSeverity MAX-ACCESS read-only STATUS current DESCRIPTION "The severity of the SYSLOG message" REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.1) RFC 5427: Textual Conventions for Syslog Management" ::= { syslogMsgEntry 3 } syslogMsgVersion OBJECT-TYPE SYNTAX Unsigned32 (0..999) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the SYSLOG message. A value of 0 indicates that the version is unknown." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.2)" ::= { syslogMsgEntry 4 } syslogMsgTimeStamp OBJECT-TYPE SYNTAX SyslogTimeStamp MAX-ACCESS read-only STATUS current Schoenwaelder, et al. Standards Track [Page 10] RFC 5676 SYSLOG-MSG-MIB October 2009 DESCRIPTION "The timestamp of the SYSLOG message. A zero-length string is returned if the timestamp is unknown." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.3)" ::= { syslogMsgEntry 5 } syslogMsgHostName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The hostname and the (optional) domain name of the SYSLOG message. A zero-length string indicates an unknown hostname. The SYSLOG protocol specification constrains this string to printable US-ASCII code points." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.4)" ::= { syslogMsgEntry 6 } syslogMsgAppName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..48)) MAX-ACCESS read-only STATUS current DESCRIPTION "The app-name of the SYSLOG message. A zero-length string indicates an unknown app-name. The SYSLOG protocol specification constrains this string to printable US-ASCII code points." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.5)" ::= { syslogMsgEntry 7 } syslogMsgProcID OBJECT-TYPE SYNTAX DisplayString (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "The procid of the SYSLOG message. A zero-length string indicates an unknown procid. The SYSLOG protocol specification constrains this string to printable US-ASCII code points." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.6)" ::= { syslogMsgEntry 8 } syslogMsgMsgID OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) Schoenwaelder, et al. Standards Track [Page 11] RFC 5676 SYSLOG-MSG-MIB October 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The msgid of the SYSLOG message. A zero-length string indicates an unknown msgid. The SYSLOG protocol specification constrains this string to printable US-ASCII code points." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.2.7)" ::= { syslogMsgEntry 9 } syslogMsgSDParams OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of structured data element parameters carried in the SYSLOG message. This number effectively indicates the number of entries in the syslogMsgSDTable. It can be used, for example, by a notification receiver to determine whether a notification carried all structured data element parameters of a SYSLOG message." ::= { syslogMsgEntry 10 } syslogMsgMsg OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The message part of the SYSLOG message. The syntax does not impose a size restriction. Implementations of this MIB module may truncate the message part of the SYSLOG message such that it fits into the size constraints imposed by the implementation environment. Such truncations can also happen elsewhere in the SYSLOG forwarding chain. If the first octets contain the value 'EFBBBF'h, then the rest of the message is a UTF-8 string. Since SYSLOG messages may be truncated at arbitrary octet boundaries during forwarding, the message may contain invalid UTF-8 encodings at the end." REFERENCE "RFC 5424: The Syslog Protocol (Sections 6.1 and 6.4)" ::= { syslogMsgEntry 11 } syslogMsgSDTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslogMsgSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Schoenwaelder, et al. Standards Track [Page 12] RFC 5676 SYSLOG-MSG-MIB October 2009 "A table containing structured data elements of SYSLOG messages." ::= { syslogMsgObjects 3 } syslogMsgSDEntry OBJECT-TYPE SYNTAX SyslogMsgSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of the syslogMsgSDTable." INDEX { syslogMsgIndex, syslogMsgSDParamIndex, syslogMsgSDID, syslogMsgSDParamName } ::= { syslogMsgSDTable 1 } SyslogMsgSDEntry ::= SEQUENCE { syslogMsgSDParamIndex Unsigned32, syslogMsgSDID DisplayString, syslogMsgSDParamName DisplayString, syslogMsgSDParamValue SyslogParamValueString } syslogMsgSDParamIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object indexes the structured data element parameters contained in a SYSLOG message. The first structured data element parameter has the index value 1, and subsequent parameters are indexed by incrementing the index of the previous parameter. The index increases across structured data element boundaries so that the value reflects the position of a structured data element parameter in a SYSLOG message." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.3.3)" ::= { syslogMsgSDEntry 1 } syslogMsgSDID OBJECT-TYPE SYNTAX DisplayString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name (SD-ID) of a structured data element. The SYSLOG protocol specification constrains this string to printable US-ASCII code points." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.3.2)" Schoenwaelder, et al. Standards Track [Page 13] RFC 5676 SYSLOG-MSG-MIB October 2009 ::= { syslogMsgSDEntry 2 } syslogMsgSDParamName OBJECT-TYPE SYNTAX DisplayString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of a parameter of the structured data element. The SYSLOG protocol specification constrains this string to printable US-ASCII code points." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.3.3)" ::= { syslogMsgSDEntry 3 } syslogMsgSDParamValue OBJECT-TYPE SYNTAX SyslogParamValueString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the parameter of a SYSLOG message identified by the index of this table. The value is stored in the unescaped format." REFERENCE "RFC 5424: The Syslog Protocol (Section 6.3.3)" ::= { syslogMsgSDEntry 4 } -- notification definitions syslogMsgNotification NOTIFICATION-TYPE OBJECTS { syslogMsgFacility, syslogMsgSeverity, syslogMsgVersion, syslogMsgTimeStamp, syslogMsgHostName, syslogMsgAppName, syslogMsgProcID, syslogMsgMsgID, syslogMsgSDParams, syslogMsgMsg } STATUS current DESCRIPTION "The syslogMsgNotification is generated when a new SYSLOG message is received and the value of syslogMsgGenerateNotifications is true. Implementations may add syslogMsgSDParamValue objects as long as the resulting notification fits into the size constraints imposed by the implementation environment and the notification message size constraints imposed by maxMessageSize [RFC3412] and SNMP transport mappings." ::= { syslogMsgNotifications 1 } -- conformance statements Schoenwaelder, et al. Standards Track [Page 14] RFC 5676 SYSLOG-MSG-MIB October 2009 syslogMsgGroups OBJECT IDENTIFIER ::= { syslogMsgConformance 1 } syslogMsgCompliances OBJECT IDENTIFIER ::= { syslogMsgConformance 2 } syslogMsgFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for implementations of the SYSLOG-MSG-MIB." MODULE -- this module MANDATORY-GROUPS { syslogMsgGroup, syslogMsgSDGroup, syslogMsgControlGroup, syslogMsgNotificationGroup } ::= { syslogMsgCompliances 1 } syslogMsgReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for implementations of the SYSLOG-MSG-MIB that do not support read-write access." MODULE -- this module MANDATORY-GROUPS { syslogMsgGroup, syslogMsgSDGroup, syslogMsgControlGroup, syslogMsgNotificationGroup } OBJECT syslogMsgTableMaxSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT syslogMsgEnableNotifications MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { syslogMsgCompliances 2 } syslogMsgNotificationCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for implementations of the SYSLOG-MSG-MIB that do only generate notifications and do not provide a table to allow read access to SYSLOG message details." MODULE -- this module MANDATORY-GROUPS { Schoenwaelder, et al. Standards Track [Page 15] RFC 5676 SYSLOG-MSG-MIB October 2009 syslogMsgGroup, syslogMsgSDGroup, syslogMsgNotificationGroup } OBJECT syslogMsgFacility MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgSeverity MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgVersion MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgTimeStamp MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgHostName MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgAppName MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgProcID MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgMsgID MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgSDParams MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgMsg MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." OBJECT syslogMsgSDParamValue MIN-ACCESS accessible-for-notify DESCRIPTION "Read access is not required." Schoenwaelder, et al. Standards Track [Page 16] RFC 5676 SYSLOG-MSG-MIB October 2009 ::= { syslogMsgCompliances 3 } syslogMsgNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { syslogMsgNotification } STATUS current DESCRIPTION "The notifications emitted by this MIB module." ::= { syslogMsgGroups 1 } syslogMsgGroup OBJECT-GROUP OBJECTS { -- syslogMsgIndex, syslogMsgFacility, syslogMsgSeverity, syslogMsgVersion, syslogMsgTimeStamp, syslogMsgHostName, syslogMsgAppName, syslogMsgProcID, syslogMsgMsgID, syslogMsgSDParams, syslogMsgMsg } STATUS current DESCRIPTION "A collection of objects representing a SYSLOG message, excluding structured data elements." ::= { syslogMsgGroups 2 } syslogMsgSDGroup OBJECT-GROUP OBJECTS { -- syslogMsgSDParamIndex, -- syslogMsgSDID, -- syslogMsgSDParamName, syslogMsgSDParamValue } STATUS current DESCRIPTION "A collection of objects representing the structured data elements of a SYSLOG message." ::= { syslogMsgGroups 3 } syslogMsgControlGroup OBJECT-GROUP OBJECTS { syslogMsgTableMaxSize, syslogMsgEnableNotifications Schoenwaelder, et al. Standards Track [Page 17] RFC 5676 SYSLOG-MSG-MIB October 2009 } STATUS current DESCRIPTION "A collection of control objects to control the size of the syslogMsgTable and to enable/disable notifications." ::= { syslogMsgGroups 4 } END 8. Usage Example The following example shows a valid SYSLOG message including structured data. The otherwise-unprintable Unicode byte order mark (BOM) is represented as "BOM" in the example. <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOMAn application event log entry... This SYSLOG message leads to the following entries in the syslogMsgTable and the syslogMsgSDTable (note that string indexes are written as strings for readability reasons): syslogMsgIndex.1 = 1 syslogMsgFacility.1 = 20 syslogMsgSeverity.1 = 5 syslogMsgVersion.1 = 1 syslogMsgTimeStamp.1 = 2003-10-11,22:14:15.003,+0:0 syslogMsgHostName.1 = "mymachine.example.com" syslogMsgAppName.1 = "evntslog" syslogMsgProcID.1 = "-" syslogMsgMsgID.1 = "ID47" syslogMsgMsg.1 = "BOMAn application event log entry..." syslogMsgSDParamValue.1.1."exampleSDID@32473"."iut" = "3" syslogMsgSDParamValue.1.2."exampleSDID@32473"."eventSource" = "Application" syslogMsgSDParamValue.1.3."exampleSDID@32473"."eventID" = "1011" 9. IANA Considerations The IANA has assigned value "192" under the 'mib-2' subtree and recorded the assignment in the SMI Numbers registry. Schoenwaelder, et al. Standards Track [Page 18] RFC 5676 SYSLOG-MSG-MIB October 2009 10. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o syslogMsgTableMaxSize: This object controls how many entries are kept in the syslogMsgTable. Unauthorized modifications may either cause increased memory consumption (by setting this object to a large value) or turn off the capability to retrieve notifications using GET class operations (by setting this object to zero). This might be used to hide traces of an attack. o syslogMsgEnableNotifications: This object enables notifications. Unauthorized modifications to disable notification generation can be used to hide an attack by preventing management applications that use SNMP from receiving real-time notifications about events carried in SYSLOG messages. Unauthorized modifications to enable notification generation may be used as part of a denial-of-service attack against a network management system if, for example, the SYSLOG-to-SNMP translator accepts unauthorized SYSLOG messages. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o syslogMsgTableMaxSize, syslogMsgEnableNotifications: These objects provide information regarding whether SYSLOG messages are forwarded as SNMP notifications and how many messages will be maintained in the syslogMsgTable. This information might be exploited by an attacker in order to plan actions with the goal of hiding attack activities. o syslogMsgFacility, syslogMsgSeverity, syslogMsgVersion, syslogMsgTimeStamp, syslogMsgHostName, syslogMsgAppName, syslogMsgProcID, syslogMsgMsgID, syslogMsgSDParams, syslogMsgMsg, syslogMsgSDParamValue: These objects carry the content of SYSLOG messages and the SYSLOG-message-oriented security considerations of [RFC5424] apply. In particular, an attacker who gains access to SYSLOG messages via SNMP may use the knowledge gained from Schoenwaelder, et al. Standards Track [Page 19] RFC 5676 SYSLOG-MSG-MIB October 2009 SYSLOG messages to compromise a machine or do other damage. It is therefore desirable to configure SNMP access control rules, enforcing a consistent security policy for SYSLOG messages. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Using the security features of the SNMPv3 framework secures the transport of SYSLOG data via SNMP only. It is therefore RECOMMENDED that deployments use SYSLOG security mechanisms in order to prevent attackers from adding malicious SYSLOG data to the MIB tables. 11. Acknowledgments The editors wish to thank the following individuals for providing helpful comments on various versions of this document: Martin Bjorklund, Washam Fan, Rainer Gerhards, Wes Hardacker, David Harrington, Tom Petch, Juergen Quittek, Dan Romascanu, and Bert Wijnen. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. Schoenwaelder, et al. Standards Track [Page 20] RFC 5676 SYSLOG-MSG-MIB October 2009 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", RFC 2579, STD 58, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5427] Keeni, G., "Textual Conventions for Syslog Management", RFC 5427, March 2009. [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", RFC 5675, October 2009. 12.2. Informative References [RFC3014] Kavasseri, R., Ed., "Notification Log MIB", RFC 3014, November 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Schoenwaelder, et al. Standards Track [Page 21] RFC 5676 SYSLOG-MSG-MIB October 2009 Authors' Addresses Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany EMail: j.schoenwaelder@jacobs-university.de Alexander Clemm Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA EMail: alex@cisco.com Anirban Karmakar Cisco Systems India Pvt Ltd SEZ Unit, Cessna Business Park, Sarjapur Marathahalli ORR, Bangalore, Karnataka 560103 India EMail: akarmaka@cisco.com Schoenwaelder, et al. Standards Track [Page 22] snmp-mibs-downloader-1.1/mibrfcs/rfc5728.txt0000644000000000000000000055342411402176072015605 0ustar Internet Engineering Task Force (IETF) S. Combes Request for Comments: 5728 P. Amundsen Category: Informational M. Lambert ISSN: 2070-1721 H. Lexow SatLabs Group March 2010 The SatLabs Group DVB-RCS MIB Abstract This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5728. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Combes, et al. Informational [Page 1] RFC 5728 DVB-RCS MIB March 2010 This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction ....................................................4 2. Conventions Used in This Document ...............................5 2.1. Abbreviations ..............................................6 2.2. Glossary ...................................................8 2.2.1. Star DVB-RCS Network ................................8 2.2.2. Mesh DVB-RCS Network ................................8 2.2.3. Transparent DVB-RCS Network .........................8 2.2.4. Regenerative DVB-RCS Network ........................8 2.2.5. DVB-RCS MAC Layer ...................................9 2.2.6. DVB-RCS TDM .........................................9 2.2.7. DVB-RCS TDMA ........................................9 2.2.8. IDU .................................................9 2.2.9. ODU .................................................9 2.2.10. RCST ...............................................9 2.2.11. NCC ................................................9 2.2.12. Configuration File ................................10 2.2.13. Log File ..........................................10 2.2.14. Installation Log File .............................10 2.2.15. Antenna Alignment .................................10 2.2.16. CW Frequency ......................................10 2.2.17. Request Class .....................................10 2.2.18. Channel ID ........................................10 2.2.19. ATM Profile .......................................10 2.2.20. MPEG Profile ......................................11 2.2.21. PID Pool ..........................................11 2.2.22. Capacity Categories ...............................11 2.2.23. Start Transponder .................................12 2.2.24. DVB-S .............................................12 2.2.25. DVB-S2 and CCM/VCM/ACM ............................12 2.2.26. Interactive Network ...............................13 Combes, et al. Informational [Page 2] RFC 5728 DVB-RCS MIB March 2010 3. MIB Module Overview ............................................13 3.1. Textual Conventions .......................................13 3.2. Structure of the MIB ......................................14 3.3. Relationship to the Interfaces MIB Module .................15 3.4. MIB Groups Description ....................................18 3.4.1. dvbRcsRcstSystem ...................................18 3.4.2. dvbRcsRcstNetwork ..................................19 3.4.3. dvbRcsRcstInstall ..................................19 3.4.4. dvbRcsRcstQos ......................................19 3.4.5. dvbRcsRcstControl ..................................20 3.4.6. dvbRcsRcstState ....................................20 3.4.7. dvbRcsFwdLink (dvbRcsFwdConfig and dvbRcsFwdStatus groups) ............................20 3.4.8. dvbRcsRtnLink (dvbRcsRtnConfig and dvbRcsRtnStatus groups) ............................20 4. Definitions ....................................................21 5. Security Considerations ........................................91 6. IANA Considerations ............................................92 7. Acknowledgments ................................................92 8. References .....................................................93 8.1. Normative References ......................................93 8.2. Informative References ....................................94 Combes, et al. Informational [Page 3] RFC 5728 DVB-RCS MIB March 2010 1. Introduction The SatLabs Group [SATLABS] is an international non-profit EEIG (European Economic Interest Grouping) committed to large-scale adoption and deployment of the Digital Video Broadcasting Return Channel via Satellite (DVB-RCS) standard [ETSI-RCS]. SatLabs members are service providers, satellite operators, system integrators, terminal manufacturers, and technology providers with an interest in DVB-RCS. Since its creation in 2001, the main goal of the SatLabs Group has been to achieve interoperability between DVB-RCS terminals and systems. Therefore, the Group has defined the SatLabs Qualification Program, which provides an independent certification process for DVB- RCS terminals based on System Recommendations defined by SatLabs. To enhance product interoperability, beyond the physical-layer and MAC- layer mechanisms defined in the DVB-RCS standard, SatLabs has expanded its Recommendations in the field of DVB-RCS terminal management [SATLABS]. As part of this effort, SatLabs has specified a common Simple Network Management Protocol (SNMP) Management Information Base (MIB) for DVB-RCS terminals, which is defined in this document. A DVB-RCS terminal is denoted as a Return Channel Satellite Terminal (RCST) in the remainder of this document. This consists of an Indoor Unit (IDU) and an Outdoor Unit (ODU) connected through an Inter- Facility Link (IFL), usually a coaxial L-band interface. On the user side, the IDU is connected to the user network through a Local Area Network (LAN) interface (usually Ethernet). On the network side, the ODU is connected via a satellite link (the air interface). The SatLabs Group DVB-RCS MIB is implemented in the IDU of an RCST. RCST management can be performed either through the LAN interface (local management) or through the air interface (remote management from the Network Control Center, NCC). RCST and NCC elements are shown on Figure 1. Combes, et al. Informational [Page 4] RFC 5728 DVB-RCS MIB March 2010 +------------+ | IP | | End Host | +-----+------+ | - - - - - - - -|- - - - - - - - - - - - - - - - | | LAN interface | | | +------+--------+ | | Indoor Unit | | | (IDU) | | +------+--------+ | | | Inter Facility Link (IFL) | | | +-----+---------+ | | Outdoor Unit | | | (ODU) | | +------+--------+ | | | | Air interface | - - - - - - - |- - - - - - - - - - - - - - - - RCST | | +----------------+ +------->| Network Control| | Center (NCC) | +----------------+ Figure 1: RCST Architecture 2. Conventions Used in This Document This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Combes, et al. Informational [Page 5] RFC 5728 DVB-RCS MIB March 2010 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2.1. Abbreviations AAL5 ATM Adaptation Layer Type 5 ACM Adaptive Coding and Modulation ATM Asynchronous Transfer Mode AVBDC Absolute Volume-Based Dynamic Capacity BER Bit Error Rate BUC Block Up-Converter CCM Constant Coding and Modulation CNR Carrier to Noise Ratio CRA Continuous Rate Assignment CSC Common Signaling Channel CW Continuous Wave (carrier frequency) dBi deciBel (isotropic) dBm deciBel (with respect to 1 mW) DC Direct Current DSCP Diffserv Code Point DVB Digital Video Broadcasting EIRP Equivalent Isotropic Radiated Power ETSI European Telecommunications Standards Institute FEC Forward Error Correction FTP File Transfer Protocol GS Generic Stream Combes, et al. Informational [Page 6] RFC 5728 DVB-RCS MIB March 2010 GSE Generic Stream Encapsulation IDU Indoor Unit IFL Inter-Facility Link LNB Low Noise Block LO Local Oscillator MAC Medium Access Control MIB Management Information Base MPEG Motion Pictures Expert Group MPE Multi-Protocol Encapsulation NCC Network Control Centre OAM Operations and Management ODU Outdoor Unit PHB Per-Hop Behavior PEP Performance Enhancing Proxy PID Packet IDentifier (MPEG, used as Elementary Stream Identifier) QoS Quality of Service RBDC Rate-Based Dynamic Capacity RC Request Class RCS Return Channel via Satellite RCST Return Channel via Satellite Terminal (DVB-RCS Terminal) Rx Receive SDU Service Data Unit SSPA Solid State Power Amplifier TDM Time-Division Multiplex Combes, et al. Informational [Page 7] RFC 5728 DVB-RCS MIB March 2010 TDMA Time-Division Multiple Access TFTP Trivial File Transfer Protocol TS Transport Stream (as defined by MPEG) Tx Transmit VBDC Volume-Based Dynamic Capacity VCI Virtual Channel Identifier (ATM) VPI Virtual Path Identifier (ATM) Vpp Volts peak-to-peak 2.2. Glossary The terms in this document are derived either from DVB-RCS standard specifications [ETSI-RCS] or from SatLabs System Recommendations [SATLABS]. 2.2.1. Star DVB-RCS Network This denotes a hub-and-spoke configuration where all communications pass through a central hub, which usually also includes the NCC. Peer-to-peer communication between RCSTs is possible through a double satellite hop (this traffic has to pass through the hub). 2.2.2. Mesh DVB-RCS Network This denotes a mesh configuration that supports peer-to-peer communications in a single satellite hop directly between RCSTs. 2.2.3. Transparent DVB-RCS Network This denotes a network using transparent satellite transponders. Star or mesh network configurations can be supported. In the case of a mesh configuration, RCSTs need to incorporate a TDMA receiver in addition to the TDM receiver. 2.2.4. Regenerative DVB-RCS Network This denotes a network that uses regenerative satellite transponders, i.e. includes some On-Board Processing functionality, which allows demodulation and decoding of the uplink TDMA signals and re-multiplex of the traffic into TDM signals on the downlink. Star or mesh network configurations can be supported. Combes, et al. Informational [Page 8] RFC 5728 DVB-RCS MIB March 2010 2.2.5. DVB-RCS MAC Layer The DVB-RCS MAC layer represents the air interface of an RCST, as specified in [ETSI-RCS]. The interface is bi-directional and supports IP traffic over hub-spoke (star) and mesh satellite network topologies. 2.2.6. DVB-RCS TDM The DVB-RCS TDM corresponds to the forward link of a DVB-RCS transparent system or the downlink of a DVB-RCS regenerative system. It is based on either the DVB-S or DVB-S2 standard, specified in [ETSI-DVBS] and [ETSI-DVBS2] respectively. In the DVB-RCS context, this interface is uni- or bi-directional, as it may also be used for a return channel dedicated to a single terminal. 2.2.7. DVB-RCS TDMA The DVB-RCS TDMA corresponds to the return or mesh link of an RCS transparent system or the uplink of an RCS regenerative system. It is specified in [ETSI-RCS]. In the context of star transparent and mesh regenerative DVB-RCS systems, this interface is uni-directional. In the context of mesh transparent DVB-RCS systems, this interface is bi-directional. 2.2.8. IDU This is the indoor part of the RCST (including at least the power supply, and usually also the modem and networking functions). 2.2.9. ODU This is the outdoor part of the RCST (including at least the aerial, and usually also the LNB and BUC). 2.2.10. RCST This is the Satellite Terminal, installed on the customer premises. It is composed of the IDU and ODU. 2.2.11. NCC The NCC provides Control and Monitoring Functions. It generates control and timing signals for the operation of the DVB-RCS Network. Combes, et al. Informational [Page 9] RFC 5728 DVB-RCS MIB March 2010 2.2.12. Configuration File The configuration file is an XML-formatted file, storing configuration parameters for the RCST and their values. 2.2.13. Log File The log file is stored at the RCST. This is used to log particular events that occur on the RCST side. 2.2.14. Installation Log File The installation log file is stored at the RCST. This logs particular events that occur on the RCST side and are related to RCST installation phase. 2.2.15. Antenna Alignment This is the process to align the RCST antenna, part of the ODU, in order to enable bi-directional communication (uplink, downlink) with the satellite network. 2.2.16. CW Frequency The CW frequency is the frequency of a Continuous Wave signal. It is a narrowband carrier transmitted for the duration of measurements during the installation of an RCST. 2.2.17. Request Class A Request Class (RC) is a representation of a Per-Hop Behavior (PHB) at the MAC layer. It defines a behavior of the MAC layer for a given aggregation of traffic. This behavior includes a combination of Capacity Categories associated to the RC and a priority with respect to the other RCs supported by an RCST. 2.2.18. Channel ID Each Request Class is identified by a unique Channel_ID in the communication between the RCST and the NCC. 2.2.19. ATM Profile The ATM profile is one of the two profiles for traffic burst format on a DVB-RCS TDMA. It is based on one or more concatenated ATM cells, each of length 53 bytes, plus an optional prefix. Combes, et al. Informational [Page 10] RFC 5728 DVB-RCS MIB March 2010 2.2.20. MPEG Profile The MPEG profile is one of the two profiles for traffic burst format on the DVB-RCS TDMA. It is based on a number of concatenated MPEG2-TS packets, each of length 188 bytes. 2.2.21. PID Pool For the MPEG profile, several RCs may be mapped within a pool of several PIDs to allow cross-RC Section Packing [ETSI-DAT]. Section Packing can be used on all PIDs and higher priority traffic can always preempt lower priority streams. This reduces the need for padding. 2.2.22. Capacity Categories The TDMA timeslot allocation process for the DVB-RCS uplink supports several Capacity Categories. The Capacity Categories CRA, RBDC, and A/VBDC, when authorized for an RC, have to be configured from the NCC. Their configuration parameters are used to inform the RCST of the configuration of each category at the NCC side and thus help in Capacity Requests computation. The categories are treated independently for each RC. A SatLabs optional feature is defined that allows their configuration at the RCST level in addition to configuration per RC. This feature is denoted RCST_PARA. 2.2.22.1. Continuous Rate Assignment (CRA) CRA is a rate capacity that is provided in full in a continuous manner to the RCST while required. 2.2.22.2. Rate-Based Dynamic Capacity (RBDC) RBDC is a rate capacity that is requested dynamically by an RCST. RBDC is provided in response to explicit requests from the RCST to the NCC, such requests being absolute (i.e., corresponding to the full rate currently being requested). Each request overrides all previous RBDC requests from the same RCST and is subject to a maximum rate limit. Combes, et al. Informational [Page 11] RFC 5728 DVB-RCS MIB March 2010 2.2.22.3. Volume-Based Dynamic Capacity (VBDC) VBDC is a volume capacity that is requested dynamically by an RCST. VBDC is provided in response to explicit requests from the RCST to the NCC, such requests being cumulative (i.e., each request adds to all previous requests from the same RCST). 2.2.22.4. Absolute Volume-Based Dynamic Capacity (AVBDC) AVBDC is a volume capacity that is requested dynamically by an RCST. This capacity is provided in response to explicit requests from the RCST to the NCC, such requests being absolute (i.e., this request replaces the previous ones from the same RCST). The combination of AVBDC and VBDC is seen as a single Capacity Category, denoted A/VBDC. 2.2.22.5. Population ID This defines a group of RCSTs within a network. 2.2.23. Start Transponder This is the satellite transponder on which the communication is initiated from an RCST point of view when in the installation mode. The parameters corresponding to this transponder (satellite orbital position, frequency, etc.) are stored at the RCST as power-up configuration data. 2.2.24. DVB-S DVB-S is the Digital Video Broadcast over Satellite [ETSI-DVBS]. It is a framework and set of associated standards published by ETSI for the transmission of video, audio, and data, using the ISO MPEG-2 standard [ISO-MPEG], over satellite links. 2.2.25. DVB-S2 and CCM/VCM/ACM DVB-S2 is the Second Generation of the Digital Video Broadcast for Satellite applications standard [ETSI-DVBS2]. It is a framework and set of associated standards published by ETSI for the transmission of video, audio, and data. BBFRAME: The main framing unit of the DVB-S2 protocol stack. CCM: In CCM transmission mode, the forward link uses a constant set of transmission parameters (FEC coding rate and modulation scheme) for all receivers. Combes, et al. Informational [Page 12] RFC 5728 DVB-RCS MIB March 2010 VCM: In VCM transmission mode, the forward link uses transmission parameters that are variable on a BBFRAME-by-BBFRAME but fixed on a Receiver basis, according to fixed link and propagation conditions for each Receiver. ACM: In ACM transmission mode, the forward link uses transmission parameters that are dynamically adjusted on a BBFRAME-by-BBFRAME and Receiver-per-Receiver basis, according to actual link and propagation conditions. In order to implement ACM, feedback from each Receiver has to be provided by DVB-RCS return channel. 2.2.26. Interactive Network This is another name for a DVB-RCS-based satellite network. 3. MIB Module Overview This MIB module provides a set of objects required for the management of a SatLabs-compliant RCST. The specification is derived from the parameters and protocols described in [SATLABS]. The MIB module in this document uses the following OBJECT IDENTIFIER values, as already assigned by IANA under the smi-numbers registry [IANA]: +------------+---------------------------+ | Descriptor | OBJECT IDENTIFIER value | +------------+---------------------------+ |dvbRcsMib |{ mib-2 transmission 239 } | +------------+---------------------------+ Table 1: Object Identifiers for the MIB These values have been assigned for this MIB under the 'mib-2.transmission' subtree. 3.1. Textual Conventions This MIB module defines new textual conventions for RCST indications of SatLabs-defined capabilities, including profiles, options, and optional features. DvbRcsSystemSatLabsProfileMap represents the SatLabs profiles supported as defined in [SATLABS]. DvbRcsSystemSatLabsOptionMap represents the SatLabs options supported as defined in [SATLABS]. These are options that are used for the certification of SatLabs terminals. They represent important Combes, et al. Informational [Page 13] RFC 5728 DVB-RCS MIB March 2010 functionality, with impact on interoperability, and their support is advertised with the RCST certification level. DvbRcsSystemSatLabsFeatureMap represents the SatLabs optional features supported as defined in [SATLABS]. These represent minor features, not necessary for interoperability. They are not used for the certification of SatLabs terminals. 3.2. Structure of the MIB This MIB module is structured into two top-level groups: o The dvbRcsMibObjects group includes all the managed objects of the DVB-RCS MIB. o The dvbRcsConformance group includes the compliance statements for DVB-RCS terminals that are compliant with [SATLABS]. The managed objects are grouped into formal object groups (i.e., units of conformance) according to their relation to specific SatLabs options or features. The conformance statements (MODULE- COMPLIANCE specification) are described within the dvbRcsRcstCompliances group, while the units of conformance are described within the dvbRcsRcstGroups group. The dvbRcsMibObjects group is further structured into three groups: dvbRcsRcst, dvbRcsFwdLink, and dvbRcsRtnLink. The dvbRcsRcst group covers management related to the RCST equipment. It is structured into six groups: o dvbRcsRcstSystem o dvbRcsRcstNetwork o dvbRcsRcstInstall o dvbRcsRcstQos o dvbRcsRcstControl o dvbRcsRcstState The dvbRcsFwdLink group covers management information related to the RCST forward link. It is structured into two groups: o dvbRcsFwdConfig o dvbRcsFwdStatus Combes, et al. Informational [Page 14] RFC 5728 DVB-RCS MIB March 2010 The dvbRcsRtnLink group covers management information related to the RCST return link. It is structured into two groups: o dvbRcsRtnConfig o dvbRcsRtnStatus Tables within each of these groups cover different functions like return link traffic management (packet classes, Request Classes, PID pools) and forward link configuration and status. Rows created automatically (e.g., by the device according to the hardware configuration) may, and generally will, have a mixture of configuration and status objects within them. Rows that are meant to be created by the management station are generally restricted to configuration (read-create) objects. 3.3. Relationship to the Interfaces MIB Module This section clarifies the relationship of this MIB module to the Interfaces MIB [RFC2863]. Several areas of correlation are addressed in the following. The implementer is referred to the Interfaces MIB document in order to understand the general intent of these areas. IANA has assigned three ifType labels for DVB-RCS. Each RCST MUST support at least the three following interfaces: o dvbRcsMacLayer (239), -- DVB-RCS MAC Layer DVB-RCS MAC Layer represents the complete air interface of an RCST, as specified in [ETSI-RCS]. This interface supports star and mesh networks and is bi-directional. Only star networks are considered by the present MIB module. o dvbTdm (240), -- DVB Satellite TDM DVB-RCS physical link based on Time-Division Multiplexing. It corresponds to the forward link of an RCS transparent system or the downlink of an RCS regenerative system. It is based on either the DVB-S or DVB-S2 standard, specified in [ETSI-DVBS] and [ETSI-DVBS2] respectively. Only transparent systems are considered by the present MIB module. In the DVB-RCS context, this interface is uni- or bi-directional. In the present MIB module, only a uni-directional (i.e., forward link, or downstream) dvbTdm interface is considered. Combes, et al. Informational [Page 15] RFC 5728 DVB-RCS MIB March 2010 o dvbRcsTdma (241), -- DVB-RCS TDMA DVB-RCS physical link based on Time-Division Multiple Access. It corresponds to the return or mesh link of an RCS transparent system or the uplink of an RCS regenerative system. It is based on the DVB-RCS standard specified in [ETSI-RCS]. In the context of star transparent and mesh regenerative DVB-RCS systems, this interface is uni-directional. In the context of mesh transparent DVB-RCS systems, this interface is bi-directional. Only star transparent systems are considered by the present MIB module (i.e., return link, or upstream). The protocol stack (as reflected in ifStackTable) will be as follows: +--------------------------+ | IP | +--------------------------+ | dvbRcsMacLayer | +---------------+----------+ | dvbRcsTdma | dvbTdm | +---------------+----------+ | MPEG/ATM | MPEG/GS | +---------------+----------+ Figure 2: RCST Protocol Stack An additional Ethernet interface is used on the LAN side of the RCST (see Figure 1). An instance of ifEntry exists for each dvbTdm interface, for each dvbRcsTdma (normally only one), and for each dvbRcsMac layer (normally only one). The interface counters relate to: o dvbRcsMacLayer: DVB-RCS two-way MAC interface that counts aggregate Multi-Protocol Encapsulation (MPE) frames, Generic Stream Encapsulation (GSE) encapsulated PDUs (equals IP packets), and ATM Adaptation Layer 5 (AAL5) frames. MPE is specified in [ETSI-DAT] and is transported over MPEG, which is specified in [ISO-MPEG]. MPEG is transported over GS or TS (Transport Stream) carriers. The TS carrier is specified in [ETSI-DVBS] for DVB-S and [ETSI-DVBS2] for DVB-S2. Combes, et al. Informational [Page 16] RFC 5728 DVB-RCS MIB March 2010 GSE is specified in [ETSI-GSE] and is transported over the GS (Generic Stream) carrier, which is specified in [ETSI-DVBS2]. ATM is specified in [ITU-ATM]. AAL5 is specified in [ITU-AAL5]. o dvbTdm: The DVB-RCS TDM interface that counts MPEG TS packets at stream level, if the TS format is used. If the Generic Stream (GS) format is used, it counts GSE packets. o dvbRcsTdma: The DVB-RCS TDMA interface that counts aggregate ATM and MPEG TS packets. The ifStackTable [RFC2863] MUST be implemented to identify the relationships among sub-interfaces. The following example is a DVB-RCS star network with DVB-S and DVB- RCS. As illustrated on Figure 3, it shows a DVB-RCS MAC interface with one downstream and one upstream interface. In this network, ATM encapsulation is used in the DVB-RCS uplink. Two ATM Logical Ports are shown. DVB-S2 or DVB-S can be used in the downlink. ifType 214 'mpegTransport' can also be used for counting TS packets and bytes for sub-interfaces of dvbRcsTdma or dvbTdm, e.g., per PID- oriented or per TS-oriented, as desired and applicable. +----------------------------------------------------------+ | IP Network Layer | +------+----------------------------------+----------------+ | | +------+-------+ +------------------+----------------+ | Ethernet LAN | | dvbRcsMacLayer | +--------------+ +-------------+---------------------+ | | +-------------+-----------+ +---+---+ | dvbRcsTdma | |dvbTdm | +-----+-------------+-----+ +-------+ | | +-----+-----+ +-----+-----+ |atm-logical| |atm-logical| +-----------+ +-----------+ Figure 3: Example Stacking As can be seen from this example, the dvbRcsMacLayer interface is layered on top of the downstream and upstream interfaces, and the upstream interface is layered on top of upstream ATM logical links. Combes, et al. Informational [Page 17] RFC 5728 DVB-RCS MIB March 2010 In this example, the assignment of index values could be as follows: ifIndex ifType Description ---------------------------------------------------------------- 2 dvbRcsMacLayer (239) DVB-RCS MAC Layer 3 dvbRcsTdma (241) DVB-RCS TDMA Upstream 4 dvbTdm(240) DVB-RCS TDM Downstream 5 atm-logical(80) ATM Logical Port 6 atm-logical(80) ATM Logical Port The corresponding ifStack entries would then be: +--------------------+-------------------+ | IfStackHigherLayer | ifStackLowerLayer | +--------------------+-------------------+ | 0 | 1 | | 0 | 2 | | 1 | 0 | | 2 | 3 | | 2 | 4 | | 3 | 5 | | 3 | 6 | | 4 | 0 | | 5 | 0 | | 6 | 0 | +--------------------+-------------------+ Table 2: Example ifStack Entries 3.4. MIB Groups Description 3.4.1. dvbRcsRcstSystem The MIB objects in this group gather some basic information that would allow anyone to trace the history -- the life -- of the RCST, as well as to get a complete description of its constitution on the component point of view, including the SatLabs options/features support statement. Many of the parameters will be defined at installation. This group contains description parameters related to the RCST type (ODU type) and location. These parameters are believed to stay unchanged once it has been defined during installation. Modification of hardware equipment, maintenance operations, and geographical re- location may require an update of those MIB objects. Note that the dvbRcsRcstSystem.dvbRcsSystemLocation object gives the location of Combes, et al. Informational [Page 18] RFC 5728 DVB-RCS MIB March 2010 the ODU antenna, which is needed for network operation, while the system.sysLocation (MIB-II SNMP OID) provides the location of the IDU unit, which cannot be used for the same purpose. The RCST must provide either Read-Write access to dvbRcsSystemOdu parameters or, alternatively, provide the list of supported devices through the dvbRcsRcstOduListGroup (see conformance section). This group of parameters, defined in the dvbRcsRcstSystem group, allows the selection by the RCST installer of the actual ODU type. In such a case, the installer must set dvbRcsOduTxType, dvbRcsOduRxType, and dvbRcsOduAntennaType according to the selected BUC, LNB, and antenna respectively. 3.4.2. dvbRcsRcstNetwork This group contains all the MIB objects related to network parameters. In this subgroup, two objects have been defined in order to differentiate between control and user traffic and associate them with a physical interface. Both dvbRcsRcstNetwork.dvbRcsNetworkLanIpAddress (Traffic) and dvbRcsRcstNetwork.dvbRcsNetworkOamInetAddress (OAM) provide the value of the IP address of, respectively, the user traffic and the control and management traffic. 3.4.3. dvbRcsRcstInstall This group contains all the information related to the RCST installation and commissioning. Many parameters are believed to stay unchanged once it has been defined during installation. Modification of hardware equipment, maintenance operations, and geographical re- location may require an update of those MIB objects. 3.4.4. dvbRcsRcstQos This group contains objects to configure the Quality of Service (QoS) of the RCST by the NCC. The dvbRcsPktClass table defines the packet classification for IP layer 3 classifications. Each dvbRcsPktClass entry is mapped to a dvbRcsPhbEntry in the dvbRcsPhbMappingTable. The dvbRcsPhbMappingTable makes the relation between a packet classification entry, a Per-Hop Behavior (PHB) identifier, and a Request Class entry. Combes, et al. Informational [Page 19] RFC 5728 DVB-RCS MIB March 2010 The dvbRcsRequestClassTable defines all the layer 2 DVB-RCS QoS parameters. 3.4.5. dvbRcsRcstControl This MIB group contains objects a network manager can use to invoke actions and tests supported by the RCST agent and to retrieve the action/test results. 3.4.6. dvbRcsRcstState This MIB group describes the fault state, software versions, and configuration file versions of the RCST. 3.4.7. dvbRcsFwdLink (dvbRcsFwdConfig and dvbRcsFwdStatus groups) This MIB group contains parameters that enable access to data about the forward link. Configuration information is kept in the dvbRcsFwdLink.dvbRcsFwdConfig subgroup. Status information is kept into the dvbRcsFwdLink.dvbRcsFwdStatus subgroup. The information in dvbRcsFwdLink.dvbRcsFwdConfig.dvbRcsFwdStartTable is used for the first time the RCST tries to acquire the forward link. All these object values are aligned with the Satellite Delivery System Descriptor in the Network Information Table (NIT) table [ETSI-SI]. The objects in the dvbRcsFwdLink.dvbRcsFwdConfig.dvbRcsFwdStatusTable are aligned with the satellite forward path descriptor from the RCS Map Table (RMT) [ETSI-RCS] and with the Physical Layer (PL) Header [ETSI-DVBS2], which specifies the MODCOD (modulation and FEC rate) and the Type (frame length short or long and the presence/absence of pilots). 3.4.8. dvbRcsRtnLink (dvbRcsRtnConfig and dvbRcsRtnStatus groups) This MIB group contains parameters that enable access to data about the return link. Configuration information is kept in the dvbRcsRtnLink.dvbRcsRtnConfig subgroup. Status information is kept into the dvbRcsRtnLink.dvbRcsRtnStatus subgroup. The RCST is only able to deal with one return link at a time. Hence, there is no need to define a table to collect the different SNMP objects, as it is done for the forward. Combes, et al. Informational [Page 20] RFC 5728 DVB-RCS MIB March 2010 4. Definitions DVB-RCS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, transmission FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION, RowStatus FROM SNMPv2-TC -- [RFC2579] OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF -- [RFC2580] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddressType, InetAddress, InetAddressPrefixLength, InetPortNumber FROM INET-ADDRESS-MIB -- [RFC4001] Uri FROM URI-TC-MIB -- [RFC5017] Dscp, DscpOrAny FROM DIFFSERV-DSCP-TC -- [RFC3289] ; dvbRcsMib MODULE-IDENTITY LAST-UPDATED "201002161200Z" ORGANIZATION "The SatLabs Group" CONTACT-INFO "The SatLabs Group Web: www.satlabs.org E-mail: info@satlabs.org" DESCRIPTION "DVB-RCS MIB subtree. This MIB module applies to equipment that is a Return Channel Satellite Terminal (RCST), defined in the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS) standard (ETSI EN 301 790 Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems, European Telecommunications Standards Institute (ETSI)). Combes, et al. Informational [Page 21] RFC 5728 DVB-RCS MIB March 2010 It defines a set of MIB objects to characterize the behavior and performance of network-layer entities implementing DVB-RCS. This MIB module is intended to be used by DVB-RCS equipment following the SatLabs System Recommendations, defined by the SatLabs Group and available at www.satlabs.org. Note that, if not stated otherwise in the object DESCRIPTION clause, all writable objects are persistent. Copyright (C) The IETF Trust (2010). This version of this MIB module is part of RFC 5728; see the RFC itself for full legal notices." REVISION "200907201200Z" DESCRIPTION "Revision of this MIB module, following MIB doctor review and adjustments based on the MIB authoring guidelines from the IETF." ::= { transmission 239 } --============================================================== -- Textual Conventions --============================================================== DvbRcsSatLabsProfileMap ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the declaration of the SatLabs-defined terminal profiles. The mapping to the profiles is to be understood as described here. (0) refers to the most significant bit. dvbs(0) -> DVBS profile (DVB-S support) dvbs2ccm(1) -> DVB-S2 CCM profile (CCM support) dvbs2acm(2) -> DVB-S2 ACM profile (CCM, VCM and ACM support)" REFERENCE "SatLabs System Recommendations, available at www.satlabs.org." SYNTAX BITS { dvbs(0), dvbs2ccm(1), dvbs2acm(2), spare1(3), spare2(4), spare3(5), spare4(6), spare5(7), Combes, et al. Informational [Page 22] RFC 5728 DVB-RCS MIB March 2010 spare6(8), spare7(9), spare8(10), spare9(11), spare10(12), spare11(13), spare12(14), spare13(15), spare14(16), spare15(17), spare16(18), spare17(19), spare18(20), spare19(21), spare20(22), spare21(23), spare22(24), spare23(25), spare24(26), spare25(27), spare26(28), spare27(29), spare28(30), spare29(31) } DvbRcsSatLabsOptionMap ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the declaration of the SatLabs-defined options. A value of 1 indicates that the respective option is supported. The mapping to the options is to be understood as described here. (0) refers to the most significant bit. mpegTrf(0) -> MPEG_TRF coarseSync(1) -> COARSE_SYNC wideHop(2) -> WIDE_HOPP fastHop(3) -> FAST_HOPP dynamicMfTdma(4) -> Dynamic_MF_TDMA contentionSync(5) -> CONTENTION_SYNC qpskLow(6) -> QPSKLOW mod16Apsk(7) -> 16APSK mod32Apsk(8) -> 32APSK normalFec(9) -> NORMALFEC multiTs(10) -> MULTITS gsTs(11) -> GSTS enhQoS(12) -> ENHQOS Combes, et al. Informational [Page 23] RFC 5728 DVB-RCS MIB March 2010 pep(13) -> PEP http(14) -> HTTP ftp(15) -> FTP dns(16) -> DNS chIdStrict(17) -> CHID_STRICT nlid(18) -> NLID snmpMisc(19) -> SNMPMISC The support of specific options mandates the support of specific objects and access levels." REFERENCE "SatLabs System Recommendations, available at www.satlabs.org." SYNTAX BITS { mpegTrf(0), coarseSync(1), wideHop(2), fastHop(3), dynamicMfTdma(4), contentionSync(5), qpskLow(6), mod16Apsk(7), mod32Apsk(8), normalFec(9), multiTs(10), gsTs(11), enhQoS(12), pep(13), http(14), ftp(15), dns(16), chIdStrict(17), nlid(18), snmpMisc(19), spare1(20), spare2(21), spare3(22), spare4(23), spare5(24), spare6(25), spare7(26), spare8(27), spare9(28), spare10(29), spare11(30), spare12(31) } Combes, et al. Informational [Page 24] RFC 5728 DVB-RCS MIB March 2010 DvbRcsSatLabsFeatureMap ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the declaration of the SatLabs-specified compatibility and configuration features. A value of 1 indicates that the respective feature is supported. The mapping to the features is to be understood as described here. (0) refers to the most significant bit. rcstPara(0) -> RCST_PARA feature installLog(1) -> INSTALL_LOG feature enhClassifier(2) -> ENHCLASSIFIER feature routeId(3) -> ROUTE_ID feature oduList(4) -> ODULIST feature extNetwork(5) -> EXTNETWORK feature extControl(6) -> EXTCONTROL feature extConfig(7) -> EXTCONFIG feature extStatus(8) -> EXTSTATUS feature mpaf(9) -> MPAF feature The support of specific features mandates the support of specific objects and access levels." REFERENCE "SatLabs System Recommendations, available at www.satlabs.org." SYNTAX BITS { rcstPara(0), installLog(1), enhClassifier(2), routeId(3), oduList(4), extNetwork(5), extControl(6), extConfig(7), extStatus(8), mpaf(9), spare1(10), spare2(11), spare3(12), spare4(13), spare5(14), spare6(15), spare7(16), spare8(17), spare9(18), spare10(19), spare11(20), Combes, et al. Informational [Page 25] RFC 5728 DVB-RCS MIB March 2010 spare12(21), spare13(22), spare14(23), spare15(24), spare16(25), spare17(26), spare18(27), spare19(28), spare20(29), spare21(30), spare22(31) } --============================================================== -- object type definitions --============================================================== dvbRcsMibObjects OBJECT IDENTIFIER ::= {dvbRcsMib 1} dvbRcsConformance OBJECT IDENTIFIER ::= {dvbRcsMib 2} dvbRcsRcst OBJECT IDENTIFIER ::= {dvbRcsMibObjects 1} dvbRcsFwdLink OBJECT IDENTIFIER ::= {dvbRcsMibObjects 2} dvbRcsRtnLink OBJECT IDENTIFIER ::= {dvbRcsMibObjects 3} dvbRcsRcstSystem OBJECT IDENTIFIER ::= {dvbRcsRcst 1} dvbRcsRcstNetwork OBJECT IDENTIFIER ::= {dvbRcsRcst 2} dvbRcsRcstInstall OBJECT IDENTIFIER ::= {dvbRcsRcst 3} dvbRcsRcstQos OBJECT IDENTIFIER ::= {dvbRcsRcst 4} dvbRcsRcstControl OBJECT IDENTIFIER ::= {dvbRcsRcst 5} dvbRcsRcstState OBJECT IDENTIFIER ::= {dvbRcsRcst 6} dvbRcsFwdConfig OBJECT IDENTIFIER ::= {dvbRcsFwdLink 1} dvbRcsFwdStatus OBJECT IDENTIFIER ::= {dvbRcsFwdLink 2} dvbRcsRtnConfig OBJECT IDENTIFIER ::= {dvbRcsRtnLink 1} dvbRcsRtnStatus OBJECT IDENTIFIER ::= {dvbRcsRtnLink 2} --============================================================== -- dvbRcsRcstSystem sub-tree object types --============================================================== dvbRcsSystemMibRevision OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object allows the SNMP agent to report the implemented MIB module revision. The supported REVISION of this module is reported." ::= {dvbRcsRcstSystem 1} Combes, et al. Informational [Page 26] RFC 5728 DVB-RCS MIB March 2010 --============================================================== -- Options declared according to the textual conventions --============================================================== dvbRcsSystemSatLabsProfilesDeclaration OBJECT-TYPE SYNTAX DvbRcsSatLabsProfileMap MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the SatLabs profiles supported, as defined in the SatLabs System Recommendations." ::= {dvbRcsRcstSystem 2} dvbRcsSystemSatLabsOptionsDeclaration OBJECT-TYPE SYNTAX DvbRcsSatLabsOptionMap MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the SatLabs options supported, as defined in the SatLabs System Recommendations." ::= {dvbRcsRcstSystem 3} dvbRcsSystemSatLabsFeaturesDeclaration OBJECT-TYPE SYNTAX DvbRcsSatLabsFeatureMap MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the optional compatibility features and minor options supported, as defined in the SatLabs System Recommendations." ::= {dvbRcsRcstSystem 4} dvbRcsSystemLocation OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "Physical location of the ODU antenna expressed as longitude, latitude, and altitude. The string shall have 31 characters in the following format: ,,,,,M where x, y and z represents digits, a=N or S, b=E or W, Reading the digits from left to right: 'x' 7 latitude digits; x digits 1-2 contain the degrees, x digits 3-7 contain the minutes in decimal; 'y' 8 longitude digits; Combes, et al. Informational [Page 27] RFC 5728 DVB-RCS MIB March 2010 y digits 1-3 contain the degrees, y digits 4-8 contain the minutes in decimal; 'z' 5 altitude digits; meters above sea level in decimal; '.' is the decimal point; ',' is the field separator; 'M' is the indicator for altitude meters. This format is a modified subset of the NMEA 0183 (National Marine Electronics Association, Interface Standard) format for Global Positioning System Fix Data. This location and the satellite position are used to calculate the RCST-satellite path delay. Note: The system.sysLocation object of MIB-II provides physical location of the IDU unit." ::= {dvbRcsRcstSystem 5} dvbRcsSystemOduAntennaSize OBJECT-TYPE SYNTAX Unsigned32 UNITS "cm" MAX-ACCESS read-write STATUS current DESCRIPTION "Diameter of the antenna." ::= {dvbRcsRcstSystem 6} dvbRcsSystemOduAntennaGain OBJECT-TYPE SYNTAX Unsigned32 UNITS "x0.1 dBi" MAX-ACCESS read-write STATUS current DESCRIPTION "Antenna peak gain of the ODU." ::= {dvbRcsRcstSystem 7} dvbRcsSystemOduSspa OBJECT-TYPE SYNTAX Unsigned32 UNITS "x0.1 W" MAX-ACCESS read-write STATUS current DESCRIPTION "Power level of the Solid State Power Amplifier installed in the ODU." ::= {dvbRcsRcstSystem 8} dvbRcsSystemOduTxType OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write Combes, et al. Informational [Page 28] RFC 5728 DVB-RCS MIB March 2010 STATUS current DESCRIPTION "Type of transmitter installed in the ODU." ::= {dvbRcsRcstSystem 9} dvbRcsSystemOduRxType OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "Type of LNB installed in the ODU, with information such as vendor type, output type (single, twin, quad,...), etc." ::= {dvbRcsRcstSystem 10} dvbRcsSystemOduRxBand OBJECT-TYPE SYNTAX INTEGER { oduHighRxBand (0), oduLowRxBand (1) } MAX-ACCESS read-write STATUS current DESCRIPTION "LNB High Band / Low Band selector. High Band corresponds to the emission of an 18-26 kHz tone with 0.4-0.8 Vpp in the Rx IFL cable: (0) - High Band (1) - Low Band" ::= {dvbRcsRcstSystem 11} dvbRcsSystemOduRxLO OBJECT-TYPE SYNTAX Unsigned32 UNITS "x100 Hz" MAX-ACCESS read-write STATUS current DESCRIPTION "Frequency of LNB Local Oscillator (in 100 Hz)" ::= {dvbRcsRcstSystem 12} dvbRcsSystemOduTxLO OBJECT-TYPE SYNTAX Unsigned32 UNITS "x100 Hz" MAX-ACCESS read-write STATUS current DESCRIPTION "Frequency of Block Up-Converter Local Oscillator (in 100 Hz)." ::= {dvbRcsRcstSystem 13} Combes, et al. Informational [Page 29] RFC 5728 DVB-RCS MIB March 2010 dvbRcsSystemIduPep OBJECT IDENTIFIER ::= {dvbRcsRcstSystem 14} dvbRcsTcpPep OBJECT-TYPE SYNTAX INTEGER{ disabled (0), enabled (1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Status and control of embedded TCP PEP. 0 - disabled or not implemented 1 - enabled" ::={dvbRcsSystemIduPep 1} dvbRcsHttpPep OBJECT-TYPE SYNTAX INTEGER{ disabled (0), enabled (1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Status and control of embedded HTTP PEP. 0 - disabled or not implemented 1 - enabled" ::={dvbRcsSystemIduPep 2} --============================================================== -- ODU structural entities --============================================================== dvbRcsOduTx OBJECT IDENTIFIER ::= {dvbRcsRcstSystem 15} dvbRcsOduRx OBJECT IDENTIFIER ::= {dvbRcsRcstSystem 16} dvbRcsOduAntenna OBJECT IDENTIFIER ::= {dvbRcsRcstSystem 17} --============================================================== -- ODU BUC --============================================================== dvbRcsOduTxTypeTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsOduTxTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the identification of each well- known BUC type supported by the IDU and provides its associated index." Combes, et al. Informational [Page 30] RFC 5728 DVB-RCS MIB March 2010 ::={dvbRcsOduTx 1} dvbRcsOduTxTypeEntry OBJECT-TYPE SYNTAX DvbRcsOduTxTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the BUC type table." INDEX { dvbRcsOduTxTypeIndex } ::={dvbRcsOduTxTypeTable 1} DvbRcsOduTxTypeEntry ::= SEQUENCE { dvbRcsOduTxTypeIndex Unsigned32, dvbRcsOduTxTypeDescription SnmpAdminString } dvbRcsOduTxTypeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for the BUC type." ::={dvbRcsOduTxTypeEntry 1} dvbRcsOduTxTypeDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Text-based identification of a BUC type." ::={dvbRcsOduTxTypeEntry 2} dvbRcsOduTxType OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Index of the selected BUC type." ::={dvbRcsOduTx 2} --============================================================== -- ODU LNB --============================================================== dvbRcsOduRxTypeTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsOduRxTypeEntry MAX-ACCESS not-accessible STATUS current Combes, et al. Informational [Page 31] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "This table contains the identification of each well- known LNB type supported by the IDU and provides its associated index." ::={dvbRcsOduRx 1} dvbRcsOduRxTypeEntry OBJECT-TYPE SYNTAX DvbRcsOduRxTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the LNB type table." INDEX { dvbRcsOduRxTypeIndex } ::={dvbRcsOduRxTypeTable 1} DvbRcsOduRxTypeEntry ::= SEQUENCE { dvbRcsOduRxTypeIndex Unsigned32, dvbRcsOduRxTypeDescription SnmpAdminString } dvbRcsOduRxTypeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for the LNB type." ::={dvbRcsOduRxTypeEntry 1} dvbRcsOduRxTypeDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Text-based identification of an LNB type." ::={dvbRcsOduRxTypeEntry 2} dvbRcsOduRxType OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Index of the selected LNB type." ::={dvbRcsOduRx 2} Combes, et al. Informational [Page 32] RFC 5728 DVB-RCS MIB March 2010 --============================================================== -- ODU Antenna --============================================================== dvbRcsOduAntennaTypeTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsOduAntennaTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the identification of each well- known antenna type supported by the IDU and provides its associated index." ::={dvbRcsOduAntenna 1} dvbRcsOduAntennaTypeEntry OBJECT-TYPE SYNTAX DvbRcsOduAntennaTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the antenna type table." INDEX { dvbRcsOduAntennaTypeIndex } ::={dvbRcsOduAntennaTypeTable 1} DvbRcsOduAntennaTypeEntry ::= SEQUENCE { dvbRcsOduAntennaTypeIndex Unsigned32, dvbRcsOduAntennaTypeDescription SnmpAdminString } dvbRcsOduAntennaTypeIndex OBJECT-TYPE SYNTAX Unsigned32 (1..32) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index for the antenna type." ::={dvbRcsOduAntennaTypeEntry 1} dvbRcsOduAntennaTypeDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Text-based identification of an antenna type." ::={dvbRcsOduAntennaTypeEntry 2} dvbRcsOduAntennaType OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current Combes, et al. Informational [Page 33] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "Index of the selected antenna type." ::={dvbRcsOduAntenna 2} --============================================================== -- dvbRcsRcstNetwork sub-tree object types --============================================================== dvbRcsNetworkOamInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of Internet address of dvbRcsNetworkOamInetAddress. If the terminal OAM Internet address is unassigned or unknown, then the value of this object is unknown(0)." ::= {dvbRcsRcstNetwork 1} dvbRcsNetworkOamInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "OAM IP Address of the RCST. This object is used with both IP and interfaces MIB-II subgroups. It uniquely determines the interface through which OAM traffic passes. The OAM IP address may be statically or dynamically assigned. It is system dependent whether the OAM IP address and the Traffic IP address are the same address. If the terminal has no OAM Internet address assigned or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsNetworkOamInetAddressType object." ::= {dvbRcsRcstNetwork 2} dvbRcsNetworkOamInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-write STATUS current DESCRIPTION "Prefix length for the OAM IP Address. If this address prefix is unknown or does not apply, the value is zero." ::= {dvbRcsRcstNetwork 3} dvbRcsNetworkOamInetAddressAssign OBJECT-TYPE Combes, et al. Informational [Page 34] RFC 5728 DVB-RCS MIB March 2010 SYNTAX INTEGER { oamInetAddressStatic (1), oamInetAddressDynamic (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Identifies whether the OAM IP address is statically (1) or dynamically (2) assigned." ::= {dvbRcsRcstNetwork 4} dvbRcsNetworkLanInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of Internet address of dvbRcsNetworkLanInetAddress. If the terminal Internet address on the LAN interface is unassigned or unknown, then the value of this object is unknown(0)." ::= {dvbRcsRcstNetwork 5} dvbRcsNetworkLanInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "IP address of the LAN interface of the terminal. If the terminal has no Internet address assigned on the LAN interface or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsNetworkLanInetAddressType object." ::= {dvbRcsRcstNetwork 6} dvbRcsNetworkLanInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-write STATUS current DESCRIPTION "Prefix length for the LAN IP Address of the terminal. If this address prefix is unknown or does not apply, the value is zero." ::= {dvbRcsRcstNetwork 7} dvbRcsNetworkAirInterfaceDefaultGatewayInetAddressType OBJECT-TYPE SYNTAX InetAddressType Combes, et al. Informational [Page 35] RFC 5728 DVB-RCS MIB March 2010 MAX-ACCESS read-write STATUS current DESCRIPTION "The type of Internet address of dvbRcsNetworkAirInterfaceDefaultGatewayInetAddress. If the default gateway Internet address is unassigned or unknown, then the value of this object is unknown(0)." ::= {dvbRcsRcstNetwork 8} dvbRcsNetworkAirInterfaceDefaultGatewayInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "IP address of the default gateway for the air interface. If the terminal has no default gateway assigned on the air interface or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsNetworkAirInterfaceDefaultGatewayInetAddressType object." ::= {dvbRcsRcstNetwork 9} dvbRcsNetworkAirInterfaceDefaultGatewayInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-write STATUS current DESCRIPTION "Prefix length for the IP address of the default gateway for the air interface. If this address prefix is unknown or does not apply, the value is zero." ::= {dvbRcsRcstNetwork 10} dvbRcsNetworkDnsServers OBJECT IDENTIFIER ::= {dvbRcsRcstNetwork 11} dvbRcsPrimaryDnsServerInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of Internet address of dvbRcsPrimaryDnsServerInetAddress. If the primary DNS server Internet address is unassigned or unknown, then the value of this object is unknown(0)." Combes, et al. Informational [Page 36] RFC 5728 DVB-RCS MIB March 2010 ::= { dvbRcsNetworkDnsServers 1} dvbRcsPrimaryDnsServerInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "IP address of the primary DNS server in the NCC. If the terminal has no primary DNS server assigned or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsPrimaryDnsServerInetAddressType object." ::= {dvbRcsNetworkDnsServers 2} dvbRcsPrimaryDnsServerInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-write STATUS current DESCRIPTION "Prefix length for the IP address of the primary DNS server in the NCC. If this address prefix is unknown or does not apply, the value is zero." ::= { dvbRcsNetworkDnsServers 3} dvbRcsSecondaryDnsServerInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of Internet address of dvbRcsSecondaryDnsServerInetAddress. If the secondary DNS server Internet address is unassigned or unknown, then the value of this object is unknown(0)." ::= { dvbRcsNetworkDnsServers 4} dvbRcsSecondaryDnsServerInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "IP address of the secondary DNS server in the NCC. If the terminal has no secondary DNS server assigned or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsSecondaryDnsServerInetAddressType object." Combes, et al. Informational [Page 37] RFC 5728 DVB-RCS MIB March 2010 ::= {dvbRcsNetworkDnsServers 5} dvbRcsSecondaryDnsServerInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-write STATUS current DESCRIPTION "Prefix length for the IP address of the secondary DNS server in the NCC. If this address prefix is unknown or does not apply, the value is zero." ::= { dvbRcsNetworkDnsServers 6} dvbRcsNetworkNccMgtInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of Internet address of dvbRcsNetworkNccMgtInetAddress. If the management server Internet address is unassigned or unknown, then the value of this object is unknown(0)." ::= {dvbRcsRcstNetwork 12} dvbRcsNetworkNccMgtInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "IP address of the management server in the NCC. If the terminal has no management server assigned or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsNetworkNccMgtInetAddressType object." ::= {dvbRcsRcstNetwork 13} dvbRcsNetworkNccMgtInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-write STATUS current DESCRIPTION "Prefix length for the IP address of the management server in the NCC. If this address prefix is unknown or does not apply, the value is zero." ::= { dvbRcsRcstNetwork 14} Combes, et al. Informational [Page 38] RFC 5728 DVB-RCS MIB March 2010 dvbRcsNetworkConfigFileDownloadUrl OBJECT-TYPE SYNTAX Uri (SIZE(0..65535)) MAX-ACCESS read-write STATUS current DESCRIPTION "Full path name for the configuration file download. It includes the protocol type (TFTP or FTP) and the associated server IP address or hostname. Hostname can only be used if DNS is supported by the RCST. The format of this parameter follows RFC 3986." ::= {dvbRcsRcstNetwork 15} dvbRcsNetworkInstallLogFileDownloadUrl OBJECT-TYPE SYNTAX Uri (SIZE(0..65535)) MAX-ACCESS read-write STATUS current DESCRIPTION "Full path of the installation log file to download. It includes the protocol type (TFTP or FTP) and the associated server IP address or hostname. Hostname can only be used if DNS is supported by the RCST. The installation log file can be created on the installer's computer and downloaded to the RCST. The format of this parameter follows RFC 3986." ::= {dvbRcsRcstNetwork 16} dvbRcsNetworkConfigFileUploadUrl OBJECT-TYPE SYNTAX Uri(SIZE(0..65535)) MAX-ACCESS read-write STATUS current DESCRIPTION "Full path name for the configuration file upload. It includes the protocol type (TFTP or FTP) and the associated server IP address or hostname. Hostname can only be used if DNS is supported by the RCST. The format of this parameter follows RFC 3986." ::= {dvbRcsRcstNetwork 17} Combes, et al. Informational [Page 39] RFC 5728 DVB-RCS MIB March 2010 dvbRcsNetworkLogFileUploadUrl OBJECT-TYPE SYNTAX Uri(SIZE(0..65535)) MAX-ACCESS read-write STATUS current DESCRIPTION "Full path of the event log file. It includes the protocol type (TFTP or FTP) and the associated server IP address or hostname. Hostname can only be used if DNS is supported by the RCST. The format of this parameter follows RFC 3986." ::= {dvbRcsRcstNetwork 18} dvbRcsNetworkInstallLogFileUploadUrl OBJECT-TYPE SYNTAX Uri(SIZE(0..65535)) MAX-ACCESS read-write STATUS current DESCRIPTION "Full path of the installation log file. It includes the protocol type (TFTP or FTP) and the associated server IP address or hostname. Hostname can only be used if DNS is supported by the RCST. The installation log file can be retrieved from the RCST by the NCC or by the installer via the LAN. The format of this parameter follows RFC 3986." ::= {dvbRcsRcstNetwork 19} --============================================================== -- dvbRcsRcstInstall sub-tree object types --============================================================== dvbRcsInstallAntennaAlignmentState OBJECT-TYPE SYNTAX INTEGER { antennaAlignmentStart (1), antennaAlignmentDeny (2), antennaAlignmentContinue(3), antennaAlignmentStop (4), antennaAlignmentSuccess (5), antennaAlignmentFail (6) } MAX-ACCESS read-write STATUS current Combes, et al. Informational [Page 40] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "Indicates the alignment state of the antenna: (1)-Start; (2)-Deny; (3)-Continue; (4)-Stop; (5)-Success; (6)-Fail" ::= {dvbRcsRcstInstall 1} dvbRcsInstallCwFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "x100 Hz" MAX-ACCESS read-write STATUS current DESCRIPTION "Frequency of the transmitted Continuous Wave carrier (in 100 Hz). Minimum required precision is 1 kHz." ::= {dvbRcsRcstInstall 2} dvbRcsInstallCwMaxDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Time after which the Continuous Wave carrier must be put down (in seconds)." ::= {dvbRcsRcstInstall 3} dvbRcsInstallCwPower OBJECT-TYPE SYNTAX Integer32 UNITS "x0.1 dBm" MAX-ACCESS read-write STATUS current DESCRIPTION "IDU TX output level when the IDU is configured to send CW. The resolution is 0.1 dBm and the accuracy is +/- 1 dBm. Reconfiguration is applied immediately to a CW." ::= {dvbRcsRcstInstall 4} Combes, et al. Informational [Page 41] RFC 5728 DVB-RCS MIB March 2010 dvbRcsInstallCoPolReading OBJECT-TYPE SYNTAX Unsigned32 UNITS "x0.1 dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Co-polarization measured value during installation procedure (in 0.1 dB)." ::= {dvbRcsRcstInstall 5} dvbRcsInstallXPolReading OBJECT-TYPE SYNTAX Unsigned32 UNITS "x0.1 dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Cross-polarization measured value during installation procedure (in 0.1 dB)." ::= {dvbRcsRcstInstall 6} dvbRcsInstallCoPolTarget OBJECT-TYPE SYNTAX Unsigned32 UNITS "x0.1 dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Co-polarization target value during installation procedure (in 0.1 dB)." ::= {dvbRcsRcstInstall 7} dvbRcsInstallXPolTarget OBJECT-TYPE SYNTAX Unsigned32 UNITS "x0.1 dB" MAX-ACCESS read-write STATUS current DESCRIPTION "Cross-polarization target value during installation procedure (in 0.1 dB)." ::= {dvbRcsRcstInstall 8} dvbRcsInstallStandByDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Time to wait in stand-by mode (in seconds)." ::= {dvbRcsRcstInstall 9} Combes, et al. Informational [Page 42] RFC 5728 DVB-RCS MIB March 2010 dvbRcsInstallTargetEsN0 OBJECT-TYPE SYNTAX Unsigned32(0..315) UNITS "x0.1 dB" MAX-ACCESS read-write STATUS current DESCRIPTION "This value describes the wanted Es/N0 value that enables operation of the return link with the required error performance. The values shall be given in tenth of dB and the initial value shall be equal to 7 dB. The range shall be from 0 dB to 31.5 dB, with a precision of 0.1 dB." DEFVAL { 70 } ::= {dvbRcsRcstInstall 10} --============================================================== -- dvbRcsRcstQos sub-tree object types --============================================================== dvbRcsPktClassTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsPktClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the packet classification used in the DVB-RCS terminal. The number of entries is specified by dvbRcsPktClassIndex. " ::={dvbRcsRcstQos 1} dvbRcsPktClassEntry OBJECT-TYPE SYNTAX DvbRcsPktClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the packet classification table. One object type of each entry may have a value in the active range (a non-default value). The other object types are then assumed to be set to 'inactive'. The entry with the lowest index value takes precedence when classifying a packet." INDEX { dvbRcsPktClassIndex } ::= {dvbRcsPktClassTable 1} DvbRcsPktClassEntry ::= SEQUENCE { dvbRcsPktClassIndex Unsigned32, dvbRcsPktClassDscpLow Dscp, dvbRcsPktClassDscpHigh Dscp, dvbRcsPktClassDscpMarkValue DscpOrAny, dvbRcsPktClassIpProtocol Unsigned32, dvbRcsPktClassSrcInetAddressType InetAddressType, Combes, et al. Informational [Page 43] RFC 5728 DVB-RCS MIB March 2010 dvbRcsPktClassSrcInetAddress InetAddress, dvbRcsPktClassSrcInetAddressPrefixLength InetAddressPrefixLength, dvbRcsPktClassDstInetAddressType InetAddressType, dvbRcsPktClassDstInetAddress InetAddress, dvbRcsPktClassDstInetAddressPrefixLength InetAddressPrefixLength, dvbRcsPktClassSrcPortLow InetPortNumber, dvbRcsPktClassSrcPortHigh InetPortNumber, dvbRcsPktClassDstPortLow InetPortNumber, dvbRcsPktClassDstPortHigh InetPortNumber, dvbRcsPktClassVlanUserPri Integer32, dvbRcsPktClassPhbAssociation Unsigned32, dvbRcsPktClassRowStatus RowStatus } dvbRcsPktClassIndex OBJECT-TYPE SYNTAX Unsigned32 (1..64) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index automatically incremented by one at row creation." ::={dvbRcsPktClassEntry 1} dvbRcsPktClassDscpLow OBJECT-TYPE SYNTAX Dscp MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the low value of a range of Diffserv Code Point (DSCP) values to which a packet is compared." DEFVAL { 0 } ::={dvbRcsPktClassEntry 2} dvbRcsPktClassDscpHigh OBJECT-TYPE SYNTAX Dscp MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the high value of a range of Diffserv Code Point (DSCP) values to which a packet is compared." DEFVAL { 63 } ::={dvbRcsPktClassEntry 3} dvbRcsPktClassDscpMarkValue OBJECT-TYPE Combes, et al. Informational [Page 44] RFC 5728 DVB-RCS MIB March 2010 SYNTAX DscpOrAny MAX-ACCESS read-create STATUS current DESCRIPTION "This object is the Diffserv Code Point (DSCP) value used to mark the packet; -1 indicates no DSCP marking. Possible DSCP marks values are (0..63)" DEFVAL { -1 } ::={dvbRcsPktClassEntry 4} dvbRcsPktClassIpProtocol OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the IP protocol to which a packet is compared. A value of 255 means match all." DEFVAL { 255 } ::={dvbRcsPktClassEntry 5} dvbRcsPktClassSrcInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address of dvbRcsPktClassSrcInetAddress. If the packet class source Internet address is unassigned or unknown, then the value of this object is unknown(0)." ::= { dvbRcsPktClassEntry 6} dvbRcsPktClassSrcInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the IP source address to which a packet is compared. If the packet class has no source Internet address assigned or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsPktClassSrcInetAddressType object." ::={dvbRcsPktClassEntry 7} dvbRcsPktClassSrcInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength Combes, et al. Informational [Page 45] RFC 5728 DVB-RCS MIB March 2010 MAX-ACCESS read-create STATUS current DESCRIPTION "Prefix length of the IP source address that will be matched for this packet class. A value of zero indicates that the selectivity is inactive." DEFVAL { 0 } ::={dvbRcsPktClassEntry 8} dvbRcsPktClassDstInetAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address of dvbRcsPktClassDstInetAddress. If the packet class destination Internet address is unassigned or unknown, then the value of this object is unknown(0)." ::= { dvbRcsPktClassEntry 9} dvbRcsPktClassDstInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the IP destination address to which a packet is compared. If the packet class has no destination Internet address assigned or if this Internet address is unknown, the value of this object is the zero-length OCTET STRING. The InetAddressType is given by the dvbRcsPktClassDstInetAddressType object." ::={dvbRcsPktClassEntry 10} dvbRcsPktClassDstInetAddressPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "Prefix length of the IP source address that will be matched for this packet class. A value of zero indicates that the selectivity is inactive." DEFVAL { 0 } ::={dvbRcsPktClassEntry 11} Combes, et al. Informational [Page 46] RFC 5728 DVB-RCS MIB March 2010 dvbRcsPktClassSrcPortLow OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the low range of the source port to which a packet is compared. A value of 0 indicates that the selectivity is inactive." DEFVAL { 0 } ::={dvbRcsPktClassEntry 12} dvbRcsPktClassSrcPortHigh OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the high range of the source port to which a packet is compared. A value of 0 indicates that the selectivity is inactive." DEFVAL { 65535 } ::={dvbRcsPktClassEntry 13} dvbRcsPktClassDstPortLow OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the low range of the destination port to which a packet is compared. A value of 0 indicates that the selectivity is inactive." DEFVAL { 0 } ::={dvbRcsPktClassEntry 14} dvbRcsPktClassDstPortHigh OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the high range of the destination port to which a packet is compared. A value of 0 indicates that the selectivity is inactive." DEFVAL { 65535 } ::={dvbRcsPktClassEntry 15} dvbRcsPktClassVlanUserPri OBJECT-TYPE SYNTAX Integer32 (-1..7) MAX-ACCESS read-create STATUS current Combes, et al. Informational [Page 47] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "This object specifies the VLAN User Priority to which a packet is compared. A value of -1 indicates that the selectivity is inactive." DEFVAL { -1 } ::={dvbRcsPktClassEntry 16} dvbRcsPktClassPhbAssociation OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Associate the filter entry to a specific PHB (refer to dvbRcsPhbIdentifier)." ::={dvbRcsPktClassEntry 17} dvbRcsPktClassRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time." ::={dvbRcsPktClassEntry 18} --============================================================== -- dvbRcsPhbMappingTable --============================================================== dvbRcsPhbMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsPhbMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is a list of Per-Hop Behavior (PHB) MIB entries. It describes the PHB mapping to the Request Class." ::={dvbRcsRcstQos 2} dvbRcsPhbMappingEntry OBJECT-TYPE SYNTAX DvbRcsPhbMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the PHB mapping table." INDEX {dvbRcsPhbIdentifier} ::= {dvbRcsPhbMappingTable 1} DvbRcsPhbMappingEntry ::= SEQUENCE { Combes, et al. Informational [Page 48] RFC 5728 DVB-RCS MIB March 2010 dvbRcsPhbIdentifier Unsigned32, dvbRcsPhbName SnmpAdminString, dvbRcsPhbRequestClassAssociation Unsigned32, dvbRcsPhbMappingRowStatus RowStatus } dvbRcsPhbIdentifier OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identification of the Per-Hop Behavior (PHB). It follows the unsigned 16-bit binary encoding as specified in RFC 3140. The value 0 designates the Default PHB." ::={dvbRcsPhbMappingEntry 1} dvbRcsPhbName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the Per-Hop Behavior (PHB)." ::={dvbRcsPhbMappingEntry 2} dvbRcsPhbRequestClassAssociation OBJECT-TYPE SYNTAX Unsigned32 (1..16) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is an association of this Per-Hop Behavior (PHB) to a Request Class (by reference to a Request Class index)." ::={dvbRcsPhbMappingEntry 3} dvbRcsPhbMappingRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time." DEFVAL { active } ::={dvbRcsPhbMappingEntry 4} Combes, et al. Informational [Page 49] RFC 5728 DVB-RCS MIB March 2010 --============================================================== -- dvbRcsRequestClassTable --============================================================== dvbRcsRequestClassTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsRequestClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is a list of Request Class entries. This class describes the layer 2 QoS objects." ::={dvbRcsRcstQos 3} dvbRcsRequestClassEntry OBJECT-TYPE SYNTAX DvbRcsRequestClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Request Class table." INDEX {dvbRcsRequestClassIndex} ::= {dvbRcsRequestClassTable 1} DvbRcsRequestClassEntry ::= SEQUENCE { dvbRcsRequestClassIndex Unsigned32, dvbRcsRequestClassName SnmpAdminString, dvbRcsRequestClassChanId Unsigned32, dvbRcsRequestClassVccVpi Unsigned32, dvbRcsRequestClassVccVci Unsigned32, dvbRcsRequestClassPidPoolReference Unsigned32, dvbRcsRequestClassCra Unsigned32, dvbRcsRequestClassRbdcMax Unsigned32, dvbRcsRequestClassRbdcTimeout Unsigned32, dvbRcsRequestClassVbdcMax Unsigned32, dvbRcsRequestClassVbdcTimeout Unsigned32, dvbRcsRequestClassVbdcMaxBackLog Unsigned32, dvbRcsRequestClassRowStatus RowStatus } dvbRcsRequestClassIndex OBJECT-TYPE SYNTAX Unsigned32 (1..16) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the Request Class table. A total of 16 entries are supported." ::={dvbRcsRequestClassEntry 1} dvbRcsRequestClassName OBJECT-TYPE Combes, et al. Informational [Page 50] RFC 5728 DVB-RCS MIB March 2010 SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Name of the Request Class." ::={dvbRcsRequestClassEntry 2} dvbRcsRequestClassChanId OBJECT-TYPE SYNTAX Unsigned32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "Channel ID of the Request Class." ::={dvbRcsRequestClassEntry 3} dvbRcsRequestClassVccVpi OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the VPI used for the Request Class (ATM profile)." ::={dvbRcsRequestClassEntry 4} dvbRcsRequestClassVccVci OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the VCI used for the Request Class (ATM profile)." ::={dvbRcsRequestClassEntry 5} dvbRcsRequestClassPidPoolReference OBJECT-TYPE SYNTAX Unsigned32 (1..16) MAX-ACCESS read-create STATUS current DESCRIPTION "Reference to the Packet IDentifier (PID) pool applicable for the Request Class." ::={dvbRcsRequestClassEntry 6} dvbRcsRequestClassCra OBJECT-TYPE SYNTAX Unsigned32 UNITS "bit/s" MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the Continuous Rate Assignment (CRA) level for the Request Class in bits per second (bit/s)." Combes, et al. Informational [Page 51] RFC 5728 DVB-RCS MIB March 2010 ::={dvbRcsRequestClassEntry 7} dvbRcsRequestClassRbdcMax OBJECT-TYPE SYNTAX Unsigned32 UNITS "x2 kbit/s" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Rate-Based Dynamic Capacity (RBDC) that can be requested for the Request Class, in number of 2 kbit/s." ::={dvbRcsRequestClassEntry 8} dvbRcsRequestClassRbdcTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "superframes" MAX-ACCESS read-create STATUS current DESCRIPTION "Persistence of the Rate-Based Dynamic Capacity (RBDC) request, expressed in superframes." ::={dvbRcsRequestClassEntry 9} dvbRcsRequestClassVbdcMax OBJECT-TYPE SYNTAX Unsigned32 UNITS "ATM cells/MPEG packets" MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum Volume-Based Dynamic Capacity (VBDC) that can be allocated to the Request Class, in payload units (one ATM cell or one MPEG packet) per superframe." ::={dvbRcsRequestClassEntry 10} dvbRcsRequestClassVbdcTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "superframes" MAX-ACCESS read-create STATUS current DESCRIPTION "Time after which the RCST considers that the pending requests are lost. The RCST may issue new requests for that traffic. Volume-Based Dynamic Capacity (VBDC) Timeout is expressed in superframes." ::={dvbRcsRequestClassEntry 11} dvbRcsRequestClassVbdcMaxBackLog OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" Combes, et al. Informational [Page 52] RFC 5728 DVB-RCS MIB March 2010 MAX-ACCESS read-create STATUS current DESCRIPTION "Volume-Based Dynamic Capacity (VBDC) back log per Request Class (expressed in bytes)." ::={dvbRcsRequestClassEntry 12} dvbRcsRequestClassRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. It is not possible to change values in a row of this table while the row is active." ::={dvbRcsRequestClassEntry 13} --============================================================== -- The table of PID pools --============================================================== dvbRcsPidPoolTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsPidPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the Packet IDentifier (PID) pools. For the MPEG profile, several Request Classes may be mapped within a pool of several PIDs to allow Section Packing across several Request Classes. A PID value may occur in more than one PID pool. Each PID value can effectively occur only once in each pool." ::={dvbRcsRcstQos 4} dvbRcsPidPoolEntry OBJECT-TYPE SYNTAX DvbRcsPidPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the PID pool table." INDEX { dvbRcsPidPoolIndex, dvbRcsPidIndex } ::= {dvbRcsPidPoolTable 1} DvbRcsPidPoolEntry ::= SEQUENCE { dvbRcsPidPoolIndex Unsigned32, dvbRcsPidIndex Unsigned32, dvbRcsPidValue Unsigned32, dvbRcsPidPoolRowStatus RowStatus Combes, et al. Informational [Page 53] RFC 5728 DVB-RCS MIB March 2010 } dvbRcsPidPoolIndex OBJECT-TYPE SYNTAX Unsigned32 (1..16) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the PID pool in the PID pool table." ::={dvbRcsPidPoolEntry 1} dvbRcsPidIndex OBJECT-TYPE SYNTAX Unsigned32 (1..16) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the PID entry within the PID pool." ::={dvbRcsPidPoolEntry 2} dvbRcsPidValue OBJECT-TYPE SYNTAX Unsigned32 (0..8191) MAX-ACCESS read-create STATUS current DESCRIPTION "Defines one of the PIDs to be used in a PID pool of dvbRcsPidPoolIndex. A PID value may occur in more than one PID pool. Each PID value can effectively occur only once in each pool." ::={dvbRcsPidPoolEntry 3} dvbRcsPidPoolRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. All writable objects in this row may be modified at any time." DEFVAL { active } ::={dvbRcsPidPoolEntry 4} dvbRcsQosGlobalRbdcMax OBJECT-TYPE SYNTAX Unsigned32 UNITS "x2 kbit/s" MAX-ACCESS read-write STATUS current DESCRIPTION "Global maximum RBDC that can be requested for the RCST, in number of 2 kbit/s." ::={dvbRcsRcstQos 5} Combes, et al. Informational [Page 54] RFC 5728 DVB-RCS MIB March 2010 dvbRcsQosGlobalVbdcMax OBJECT-TYPE SYNTAX Unsigned32 UNITS "ATM cells/MPEG packets" MAX-ACCESS read-write STATUS current DESCRIPTION "Global maximum VBDC that can be allocated to the RCST, in payload units (one ATM cell or one MPEG packet) per superframe." ::={dvbRcsRcstQos 6} dvbRcsQosGlobalVbdcMaxBackLog OBJECT-TYPE SYNTAX Unsigned32 UNITS "bytes" MAX-ACCESS read-write STATUS current DESCRIPTION "Global VBDC back log at the RCST level (expressed in bytes). It is used only if the VBDC back log is not configured in the Request Class (expressed in bytes)." ::={dvbRcsRcstQos 7} dvbRcsQosChannelIdStrictDispatching OBJECT-TYPE SYNTAX INTEGER { notStrict (0), strict (1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the RCST will strictly follow RC association when signaled through Channel_ID in the TBTP: (0)- no strict association (1)- strict association" ::={dvbRcsRcstQos 8} --============================================================== -- dvbRcsRcstControl sub-tree object types --============================================================== dvbRcsCtrlRebootCommand OBJECT-TYPE SYNTAX INTEGER { idle (1), normal (2), alternate (3) } MAX-ACCESS read-write STATUS current Combes, et al. Informational [Page 55] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "This variable shall force the RCST to reboot: (1)- idle (2)- normal reboot (from current software load) (3)- reboot from alternate load (swap to alternate load before reboot)" DEFVAL {idle} ::={dvbRcsRcstControl 1} dvbRcsCtrlRcstTxDisable OBJECT-TYPE SYNTAX INTEGER { idle (1), disable (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable shall force the RCST to stop transmission (transmit disabled as defined in SatLabs System Recommendations): (1)- idle (2)- initiate Tx Disabled" DEFVAL {idle} ::={dvbRcsRcstControl 2} dvbRcsCtrlUserTrafficDisable OBJECT-TYPE SYNTAX INTEGER { idle (1), disable (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable shall disable user traffic (only RCST management traffic can be transmitted): (1)- idle (2)- disable user traffic" DEFVAL {idle} ::={dvbRcsRcstControl 3} dvbRcsCtrlCwEnable OBJECT-TYPE SYNTAX INTEGER { off (1), on (2) } MAX-ACCESS read-write STATUS current DESCRIPTION Combes, et al. Informational [Page 56] RFC 5728 DVB-RCS MIB March 2010 "This variable will force the RCST to start transmission of CW, if the RCST is first set to the installation state and is properly configured for CW transmission: (1)- off (2)- on" DEFVAL {off} ::={dvbRcsRcstControl 4} dvbRcsCtrlOduTxReferenceEnable OBJECT-TYPE SYNTAX INTEGER { off (1), on (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enables activation and deactivation of the 10 MHz reference clock in the Tx IFL cable: (1) off (2) on" DEFVAL {on} ::={dvbRcsRcstControl 5} dvbRcsCtrlOduTxDCEnable OBJECT-TYPE SYNTAX INTEGER { off (1), on (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enables activation and deactivation of DC in the Tx IFL cable: (1) off (2) on" DEFVAL {on} ::={dvbRcsRcstControl 6} dvbRcsCtrlOduRxDCEnable OBJECT-TYPE SYNTAX INTEGER { off (1), on (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enables activation and deactivation of DC in the Rx IFL cable: Combes, et al. Informational [Page 57] RFC 5728 DVB-RCS MIB March 2010 (1) off (2) on" DEFVAL {on} ::={dvbRcsRcstControl 7} dvbRcsCtrlDownloadFileCommand OBJECT-TYPE SYNTAX INTEGER { idle (1), config (2), installationLog (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable will initiate an RCST configuration file download process: (1) idle (2) download RCST configuration file from TFTP/FTP server (3) download RCST installation log file from TFTP/FTP server (INSTALL_LOG feature)" DEFVAL {idle} ::={dvbRcsRcstControl 8} dvbRcsCtrlUploadFileCommand OBJECT-TYPE SYNTAX INTEGER { idle (1), config (2), eventAlarm (3), installationLog (4) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable will initiate an RCST upload process: (1) idle (2) upload RCST configuration file to TFTP/FTP server (3) upload RCST event/alarm log file to TFTP/FTP server (4) upload RCST installation log file to TFTP/FTP server (INSTALL_LOG feature)" DEFVAL {idle} ::={dvbRcsRcstControl 9} dvbRcsCtrlActivateConfigFileCommand OBJECT-TYPE SYNTAX INTEGER { idle (1), activate (2) } Combes, et al. Informational [Page 58] RFC 5728 DVB-RCS MIB March 2010 MAX-ACCESS read-write STATUS current DESCRIPTION "Triggers the RCST to use the configuration file and update its parameters accordingly. Some RCST implementations may require a reboot for the parameters to take effect (vendor specific). (1) idle (2) activate" DEFVAL {idle} ::={dvbRcsRcstControl 10} dvbRcsCtrlRcstLogonCommand OBJECT-TYPE SYNTAX INTEGER { idle (1), logon (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable will initiate an RCST logon: (1) idle (2) initiate RCST logon" DEFVAL {idle} ::={dvbRcsRcstControl 11} dvbRcsCtrlRcstLogoffCommand OBJECT-TYPE SYNTAX INTEGER { idle (1), logoff (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable will initiate an RCST logoff: (1) idle (2) initiate RCST logoff" DEFVAL {idle} ::={dvbRcsRcstControl 12} dvbRcsCtrlRcstRxReacquire OBJECT-TYPE SYNTAX INTEGER { idle (1), reacquireForwardLink (2) } MAX-ACCESS read-write STATUS current DESCRIPTION Combes, et al. Informational [Page 59] RFC 5728 DVB-RCS MIB March 2010 "This variable will force the RCST to acquire the forward link and start receiving: (1) idle (2) reacquire forward link" DEFVAL {idle} ::={dvbRcsRcstControl 13} --============================================================== -- dvbRcsRcstState sub-tree object types --============================================================== dvbRcsRcstMode OBJECT-TYPE SYNTAX INTEGER { installation (0), operational (1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Identifies the current mode of the RCST and allows the RCST to return to the installation mode when needed. Values for the RCST mode are: Installation (0) Operational (1)" ::={dvbRcsRcstState 1} dvbRcsRcstFaultStatus OBJECT-TYPE SYNTAX INTEGER { nofault (0), fault (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Provides the fault status of the terminal. The fault status management is vendor specific. Values for the fault status are: no fault (0) fault (1)" ::={dvbRcsRcstState 2} dvbRcsRcstFwdLinkStatus OBJECT-TYPE SYNTAX INTEGER { notAcquired (0), acquired (1) } MAX-ACCESS read-only STATUS current DESCRIPTION Combes, et al. Informational [Page 60] RFC 5728 DVB-RCS MIB March 2010 "Provides the status of the RCST forward link. Values for the forward link status are: Not acquired (0) Acquired (1)" ::={dvbRcsRcstState 3} dvbRcsRcstRtnLinkStatus OBJECT-TYPE SYNTAX INTEGER { loggedOff (0), loggedOn (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Provides the status of the RCST return link. Values for the return link status are: Logged-off (0) Logged-on (1)" ::={dvbRcsRcstState 4} dvbRcsRcstLogUpdated OBJECT-TYPE SYNTAX INTEGER { noUpdate (0), logfileUpdated (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the existence of an updated event log file: No update (0) Event Log file updated (1) The RCST should remove the 'Event Log file updated' indication as the log file is fetched by the NCC." ::={dvbRcsRcstState 5} dvbRcsRcstCurrentSoftwareVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Current RCST software version." ::={dvbRcsRcstState 6} dvbRcsRcstAlternateSoftwareVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION Combes, et al. Informational [Page 61] RFC 5728 DVB-RCS MIB March 2010 "Alternate (backup/new) RCST software version." ::={dvbRcsRcstState 7} dvbRcsRcstActivatedConfigFileVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Version of the most recently activated configuration file. The version is vendor specific." ::={dvbRcsRcstState 8} dvbRcsRcstDownloadedConfigFileVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Version of the most recently downloaded configuration file. Version is vendor specific. If the value is different from dvbRcsRcstActivatedConfigFileVersion, it is pending for activation." ::={dvbRcsRcstState 9} --============================================================== -- dvbRcsFwdConfig sub-tree object types --============================================================== dvbRcsFwdStartTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsFwdStartEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Lists forward link attachment points (e.g., different for installation and operation). The table describes the forward link parameters used for the start-up stream with the NCC." ::={dvbRcsFwdConfig 1} dvbRcsFwdStartEntry OBJECT-TYPE SYNTAX DvbRcsFwdStartEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the Forward Link Start Configuration table." INDEX {dvbRcsFwdStartIndex} ::= {dvbRcsFwdStartTable 1} Combes, et al. Informational [Page 62] RFC 5728 DVB-RCS MIB March 2010 DvbRcsFwdStartEntry ::= SEQUENCE { dvbRcsFwdStartIndex Unsigned32, dvbRcsFwdStartPopId Integer32, dvbRcsFwdStartFrequency Unsigned32, dvbRcsFwdStartPolar INTEGER, dvbRcsFwdStartFormat INTEGER, dvbRcsFwdStartRolloff INTEGER, dvbRcsFwdStartSymbolRate Unsigned32, dvbRcsFwdStartInnerFec INTEGER, dvbRcsFwdStartRowStatus RowStatus } dvbRcsFwdStartIndex OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of the Forward Link StartConfig table." ::={dvbRcsFwdStartEntry 1} dvbRcsFwdStartPopId OBJECT-TYPE SYNTAX Integer32 (-1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Population identifier associated with the start-up forward link: -1: any (auto) 0-65535: specific StartPopId If 'any' is set, the RCST will assume membership of any announced population ID and will commence with logon in accordance with this assumption." ::={dvbRcsFwdStartEntry 2} dvbRcsFwdStartFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "x100 kHz" MAX-ACCESS read-create STATUS current DESCRIPTION "Frequency of the start transponder carrying a Network Information Table to which any RCST shall trigger to acquire forward link. Its value shall be given in multiples of 100 kHz." ::={dvbRcsFwdStartEntry 3} dvbRcsFwdStartPolar OBJECT-TYPE SYNTAX INTEGER { Combes, et al. Informational [Page 63] RFC 5728 DVB-RCS MIB March 2010 linearHorizontal (0), linearVertical (1), circularLeft (2), circularRight (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "2-bit field giving the polarization of the start transponder carrying a Network Information Table to which any RCST shall trigger to acquire forward link: 00: linear and horizontal 01: linear and vertical 10: circular left 11: circular right" ::={dvbRcsFwdStartEntry 4} dvbRcsFwdStartFormat OBJECT-TYPE SYNTAX INTEGER { auto (-1), dvbs (0), dvbs2ccm (1), dvbs2acm (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the transmission format standard applied for the startup stream. The start transport stream carries a Network Information Table that the RCST uses for acquiring the forward link signaling. Supported values are: -1: unspecified (automatic format acquisition is assumed) 0: DVB-S (support of this value is mandatory if DVB-S support is claimed) 1: DVB-S2 with CCM (support of this value is mandatory if DVB-S2 CCM support is claimed) 2: DVB-S2 with VCM or ACM (support of this value is mandatory if DVB-S2 ACM support is claimed) This allows the RCST to discriminate between CCM and VCM/ACM when selecting the forward link. The support of automatic format selection is optional. One or several of the other format selections must be supported, according to the claimed SatLabs profile support." ::={dvbRcsFwdStartEntry 5} Combes, et al. Informational [Page 64] RFC 5728 DVB-RCS MIB March 2010 dvbRcsFwdStartRolloff OBJECT-TYPE SYNTAX INTEGER { autoRolloff (0), rolloff020 (1), rolloff025 (2), rolloff035 (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the receive filter roll-off applied on the start transponder. The start transponder carries a Network Information Table that the RCST uses for acquiring the forward link signaling. Supported values are: 0: any (auto) 1: 0.20 2: 0.25 3: 0.35" ::={dvbRcsFwdStartEntry 6} dvbRcsFwdStartSymbolRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "x100 symbols/s" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the symbol rate on the start transponder carrying a Network Information Table to which any RCST shall trigger to acquire forward link. Its value shall be given in multiples of 100 symbols/s." ::={dvbRcsFwdStartEntry 7} dvbRcsFwdStartInnerFec OBJECT-TYPE SYNTAX INTEGER { autoFec (-1), fecRate12 (0), fecRate23 (1), fecRate34 (2), fecRate56 (3), fecRate78 (4), fecRate89 (5), fecRate35 (6), fecRate45 (7), fecRate910 (8), fecRate25 (9), fecRate13 (10), fecRate14 (11), Combes, et al. Informational [Page 65] RFC 5728 DVB-RCS MIB March 2010 noInnerCode (12) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the inner Forward Error Correction used on the start transponder carrying a Network Information Table to which any RCST shall trigger to acquire forward link. Supported values are: autoFec (-1), fecRate1/2 (0), fecRate2/3 (1), fecRate3/4 (2), fecRate5/6 (3), fecRate7/8 (4), fecRate8/9 (5), fecRate3/5 (6), fecRate4/5 (7), fecRate9/10 (8), fecRate2/5 (9), fecRate1/3 (10), fecRate1/4 (11), noInnerCode (12) The support of autoFec is optional." ::={dvbRcsFwdStartEntry 8} dvbRcsFwdStartRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. It is not possible to change values in a row of this table while the row is active." ::={dvbRcsFwdStartEntry 9} --============================================================== -- dvbRcsFwdStatus sub-tree object types --============================================================== dvbRcsFwdStatusPopId OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Population identifier applied at log-on: 0-65535: specific StartPopId If the RCST was allowed to logon with any population, Combes, et al. Informational [Page 66] RFC 5728 DVB-RCS MIB March 2010 the RCST will report the base number of the announced population ID indicated by the RCS Map Table linkage descriptor used at logon." ::={dvbRcsFwdStatus 1} dvbRcsFwdStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF DvbRcsFwdStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the current status of Forward Link interfaces." ::={dvbRcsFwdStatus 2} dvbRcsFwdStatusEntry OBJECT-TYPE SYNTAX DvbRcsFwdStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the forward link status table. Each entry is associated with a physical interface. An RCST shall support at least one entry." INDEX { dvbRcsFwdStatusIndex } ::= {dvbRcsFwdStatusTable 1} DvbRcsFwdStatusEntry ::= SEQUENCE { dvbRcsFwdStatusIndex Unsigned32, dvbRcsFwdStatusIfReference Unsigned32, dvbRcsFwdStatusNetId Unsigned32, dvbRcsFwdStatusNetName SnmpAdminString, dvbRcsFwdStatusFormat INTEGER, dvbRcsFwdStatusFrequency Unsigned32, dvbRcsFwdStatusPolar INTEGER, dvbRcsFwdStatusInnerFec INTEGER, dvbRcsFwdStatusSymbolRate Unsigned32, dvbRcsFwdStatusRolloff INTEGER, dvbRcsFwdStatusModulation INTEGER, dvbRcsFwdStatusFecFrame INTEGER, dvbRcsFwdStatusPilot INTEGER, dvbRcsFwdStatusBer Integer32, dvbRcsFwdStatusCnr Integer32, dvbRcsFwdStatusRxPower Integer32 } dvbRcsFwdStatusIndex OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS not-accessible Combes, et al. Informational [Page 67] RFC 5728 DVB-RCS MIB March 2010 STATUS current DESCRIPTION "Index of the forward link status table." ::={dvbRcsFwdStatusEntry 1} dvbRcsFwdStatusIfReference OBJECT-TYPE SYNTAX Unsigned32 (1..8) MAX-ACCESS read-only STATUS current DESCRIPTION "Cross reference to the interface table." ::={dvbRcsFwdStatusEntry 2} dvbRcsFwdStatusNetId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Interactive network identifier of the forward link (from the RCS Map Table)." ::={dvbRcsFwdStatusEntry 3} dvbRcsFwdStatusNetName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the interactive network of the forward link (from the RCS Map Table)." ::={dvbRcsFwdStatusEntry 4} dvbRcsFwdStatusFormat OBJECT-TYPE SYNTAX INTEGER { dvbs (0), dvbs2ccm (1), dvbs2acm (2), reservedFormat (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the transmission format applied on the forward link. Supported values are (from RCS Map Table): 0: DVB-S 1: DVB-S2 using CCM 2: DVB-S2 using VCM or ACM 3: reserved" ::={dvbRcsFwdStatusEntry 5} Combes, et al. Informational [Page 68] RFC 5728 DVB-RCS MIB March 2010 dvbRcsFwdStatusFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "x100 kHz" MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the frequency of the forward link. Its value shall be given in multiples of 100 kHz." ::={dvbRcsFwdStatusEntry 6} dvbRcsFwdStatusPolar OBJECT-TYPE SYNTAX INTEGER { linearHorizontal (0), linearVertical (1), circularLeft (2), circularRight (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "2-bit field giving the polarization of the forward link Supported values are (from RCS Map Table): 00: linear and horizontal 01: linear and vertical 10: circular left 11: circular right" ::={dvbRcsFwdStatusEntry 7} dvbRcsFwdStatusInnerFec OBJECT-TYPE SYNTAX INTEGER { unknown (-1), fecRate12 (0), fecRate23 (1), fecRate34 (2), fecRate56 (3), fecRate78 (4), fecRate89 (5), fecRate35 (6), fecRate45 (7), fecRate910 (8), fecRate25 (9), fecRate13 (10), fecRate14 (11), noInnerCode (12) } MAX-ACCESS read-only STATUS current DESCRIPTION Combes, et al. Informational [Page 69] RFC 5728 DVB-RCS MIB March 2010 "Specifies the inner Forward Error Correction used on the forward link for transmission to the RCST. Supported values are: unknown (-1), fecRate1/2 (0), fecRate2/3 (1), fecRate3/4 (2), fecRate5/6 (3), fecRate7/8 (4), fecRate8/9 (5), fecRate3/5 (6), fecRate4/5 (7), fecRate9/10 (8), fecRate2/5 (9), fecRate1/3 (10), fecRate1/4 (11), noInnerCode (12) The RCST will report a value that has been used for transmission to the RCST within the most recent 60 seconds. If this is not relevant, the RCST will report 'unknown'." ::={dvbRcsFwdStatusEntry 8} dvbRcsFwdStatusSymbolRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "x100 symbols/s" MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the symbol rate of the forward link. Its value shall be given in multiples of 100 symbols/s." ::={dvbRcsFwdStatusEntry 9} dvbRcsFwdStatusRolloff OBJECT-TYPE SYNTAX INTEGER { undefRolloff (0), rolloff020 (1), rolloff025 (2), rolloff035 (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of the roll-off applied on the forward link. Supported values are: 0: undefined 1: 0.20 Combes, et al. Informational [Page 70] RFC 5728 DVB-RCS MIB March 2010 2: 0.25 3: 0.35" ::={dvbRcsFwdStatusEntry 10} dvbRcsFwdStatusModulation OBJECT-TYPE SYNTAX INTEGER { unknown (0), mBPSK (1), mQPSK (2), m8PSK (3), m16APSK (4), m32APSK (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the modulation on the forward link used for transmission to the RCST. Supported values are: 0: unknown 1: BPSK 2: QPSK 3: 8PSK 4: 16APSK 5: 32APSK The RCST will report a value that has been used for transmission to the RCST within the most recent 60 seconds. If this is not relevant, the RCST will report 'unknown'." ::={dvbRcsFwdStatusEntry 11} dvbRcsFwdStatusFecFrame OBJECT-TYPE SYNTAX INTEGER { unknown (0), shortframe (1), longframe (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the frame length used on the forward link for transmission to the RCST. Supported values are: 0: Unknown 1: Short frame 2: Normal frame The RCST will report a value that has been used for transmission to the RCST within the most recent 60 Combes, et al. Informational [Page 71] RFC 5728 DVB-RCS MIB March 2010 seconds. If this is not relevant, the RCST will report 'unknown'." ::={dvbRcsFwdStatusEntry 12} dvbRcsFwdStatusPilot OBJECT-TYPE SYNTAX INTEGER { unknown (0), pilotNotused (1), pilotUsed (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether pilots are used on the forward link for transmission to the RCST. Supported values are: 0: Unknown 1: Pilots are not used 2: Pilots are used The RCST will report a value that has been used for transmission to the RCST within the most recent 60 seconds. If this is not relevant, the RCST will report 'unknown'." ::={dvbRcsFwdStatusEntry 13} dvbRcsFwdStatusBer OBJECT-TYPE SYNTAX Integer32 UNITS "exponent of 10" MAX-ACCESS read-only STATUS current DESCRIPTION "Provides the RCST BER on the Forward Link in log10 units." ::={dvbRcsFwdStatusEntry 14} dvbRcsFwdStatusCnr OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Provides the RCST CNR on the Forward Link in 0.1 dB units." ::={dvbRcsFwdStatusEntry 15} dvbRcsFwdStatusRxPower OBJECT-TYPE Combes, et al. Informational [Page 72] RFC 5728 DVB-RCS MIB March 2010 SYNTAX Integer32 UNITS "0.1 dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Provides the power level of the forward link as received at the IDU, in 0.1 dBm units." DEFVAL { -500 } ::={dvbRcsFwdStatusEntry 16} --============================================================== -- dvbRcsRtnConfig sub-tree object types --============================================================== dvbRcsRtnConfigMaxEirp OBJECT-TYPE SYNTAX Integer32 UNITS "x0.1 dBm" MAX-ACCESS read-write STATUS current DESCRIPTION "Max Equivalent Isotropic Radiated Power (EIRP) of the RCST, given in resolution of 0.1 dBm and applied when the IDU can, itself, set the necessary IDU TX output level, e.g., when using a BUC that has a power level detector and that provides sufficient feedback to the IDU." ::= {dvbRcsRtnConfig 1} dvbRcsRtnConfigDefIfLevel OBJECT-TYPE SYNTAX Integer32 UNITS "x0.1 dBm" MAX-ACCESS read-write STATUS current DESCRIPTION "IDU TX output level applied in case the dvbRcsRtnConfigMaxEirp cannot be used. The resolution is 0.1 dBm and the accuracy is +/- 1 dBm." ::= {dvbRcsRtnConfig 2} --============================================================== -- dvbRcsRtnStatus sub-tree object types --============================================================== dvbRcsRtnStatusEbN0 OBJECT-TYPE SYNTAX Integer32 UNITS "x0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The EbN0 value reported for the return link, referenced to the regular SYNC burst transmission, in 0.1 dB Combes, et al. Informational [Page 73] RFC 5728 DVB-RCS MIB March 2010 units." ::= {dvbRcsRtnStatus 1} dvbRcsRtnStatusSFDuration OBJECT-TYPE SYNTAX Unsigned32 (250..7500) UNITS "0.1 ms" MAX-ACCESS read-only STATUS current DESCRIPTION "The duration of the currently applied return link superframe structure, in tenths of milliseconds." ::= {dvbRcsRtnStatus 2} dvbRcsRtnStatusPayloadUnit OBJECT-TYPE SYNTAX INTEGER { unitATM (0), unitMPEG (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates if the payload unit used for the return link is ATM or MPEG." ::= {dvbRcsRtnStatus 3} --============================================================= -- conformance information --============================================================= dvbRcsRcstGroups OBJECT IDENTIFIER ::= {dvbRcsConformance 1} dvbRcsRcstCompliances OBJECT IDENTIFIER ::= {dvbRcsConformance 2} --============================================================= -- conformance statements --============================================================= dvbRcsRcstCompliance1 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DVB-RCS terminals that are compliant with SatLabs System Recommendations. Compliance is linked to the support by the terminal of the options or features defined in the SatLabs System Recommendations. The supported options and features of a terminal are declared in objects dvbRcsSystemSatLabsOptionsDeclaration and dvbRcsSystemSatLabsFeaturesDeclaration Combes, et al. Informational [Page 74] RFC 5728 DVB-RCS MIB March 2010 respectively." MODULE -- this module MANDATORY-GROUPS {dvbRcsRcstSystemGroup, dvbRcsRcstNetworkGroup, dvbRcsRcstInstallGroup, dvbRcsRcstQosGroup, dvbRcsRcstControlGroup, dvbRcsRcstStateGroup, dvbRcsFwdConfigGroup, dvbRcsFwdStatusGroup, dvbRcsRtnConfigGroup, dvbRcsRtnStatusGroup} GROUP dvbRcsRcstExtNetworkGroup DESCRIPTION "This group is mandatory for an RCST that supports extended networking management functionality. Such RCST is qualified as supporting the EXTNETWORK feature, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstDnsGroup DESCRIPTION "This group is mandatory for an RCST that supports the DNS protocol. Such RCST is qualified as supporting the DNS option, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstExtInstallGroup DESCRIPTION "This group is mandatory for an RCST that supports the installation log file. Such RCST is qualified as supporting the INSTALL_LOG feature, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstEnhancedClassifierGroup DESCRIPTION "This group is mandatory for an RCST that supports the enhanced classifier feature. Such RCST is qualified as supporting the ENHCLASSIFIER feature, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstMpegQosGroup DESCRIPTION "This group is mandatory for an RCST that supports MPEG traffic bursts. Such RCST is qualified as supporting the MPEG_TRF option, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstGlobalQosGroup DESCRIPTION "This group is mandatory for an RCST that supports global Combes, et al. Informational [Page 75] RFC 5728 DVB-RCS MIB March 2010 RCST QoS configuration data. Such RCST is qualified as supporting the RCST_PARA feature, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstStrictQosGroup DESCRIPTION "This group is mandatory for an RCST that supports strict channel ID dispatching. Such RCST is qualified as supporting the CHID_STRICT option, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstExtControlGroup DESCRIPTION "This group is mandatory for an RCST that supports extended control management functionality. Such RCST is qualified as supporting the EXTCONTROL feature, as defined in the SatLabs System Recommendations." GROUP dvbRcsRtnExtConfigGroup DESCRIPTION "This group is mandatory for an RCST that supports extended return link configuration management functionality. Such RCST is qualified as supporting the EXTCONFIG feature, as defined in the SatLabs System Recommendations." GROUP dvbRcsRtnExtStatusGroup DESCRIPTION "This group is mandatory for an RCST that supports extended return link status report functionality. Such RCST is qualified as supporting the EXTSTATUS feature, as defined in the SatLabs System Recommendations." GROUP dvbRcsRcstOduListGroup DESCRIPTION "This group is mandatory for an RCST that supports the ODU structural entities defined under dvbRcsOduTx, dvbRcsOduRx, and dvbRcsOduAntenna. Such RCST is qualified as supporting the ODULIST feature, as defined in the SatLabs System Recommendations." OBJECT dvbRcsSystemOduAntennaSize MIN-ACCESS read-only DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsSystemOduAntennaGain MIN-ACCESS read-only Combes, et al. Informational [Page 76] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsSystemOduSspa MIN-ACCESS read-only DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsSystemOduTxType MIN-ACCESS read-only DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsSystemOduRxType MIN-ACCESS read-only DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsSystemOduRxBand MIN-ACCESS read-only DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsSystemOduRxLO MIN-ACCESS read-only DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsSystemOduTxLO MIN-ACCESS read-only DESCRIPTION "Write access must be supported if dvbRcsRcstOduListGroup is not supported." OBJECT dvbRcsNetworkOamInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsNetworkOamInetAddress SYNTAX InetAddress (SIZE(4)) Combes, et al. Informational [Page 77] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsNetworkLanInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsNetworkLanInetAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsNetworkAirInterfaceDefaultGatewayInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsNetworkAirInterfaceDefaultGatewayInetAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsPrimaryDnsServerInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsPrimaryDnsServerInetAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsSecondaryDnsServerInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsSecondaryDnsServerInetAddress SYNTAX InetAddress (SIZE(4)) Combes, et al. Informational [Page 78] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsNetworkNccMgtInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsNetworkNccMgtInetAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsPktClassDscpLow MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports the enhanced classifier feature. Such RCST is qualified as supporting the ENHCLASSIFIER feature, as defined in the SatLabs System Recommendations." OBJECT dvbRcsPktClassDscpHigh MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports the enhanced classifier feature. Such RCST is qualified as supporting the ENHCLASSIFIER feature, as defined in the SatLabs System Recommendations." OBJECT dvbRcsPktClassDscpMarkValue MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports the enhanced classifier feature. Such RCST is qualified as supporting the ENHCLASSIFIER feature, as defined in the SatLabs System Recommendations." OBJECT dvbRcsPktClassSrcInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsPktClassSrcInetAddress SYNTAX InetAddress (SIZE(4)) Combes, et al. Informational [Page 79] RFC 5728 DVB-RCS MIB March 2010 DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsPktClassDstInetAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsPktClassDstInetAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT dvbRcsPhbName MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support. Such RCST is qualified as supporting the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsPhbRequestClassAssociation MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support. Such RCST is qualified as supporting the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsPhbMappingRowStatus MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support. Such RCST is qualified as supporting the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassName MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support. Such RCST is qualified as supporting the SNMPMISC option, as defined in the SatLabs System Recommendations." Combes, et al. Informational [Page 80] RFC 5728 DVB-RCS MIB March 2010 OBJECT dvbRcsRequestClassChanId MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support. Such RCST is qualified as supporting the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassVccVpi MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support. Such RCST is qualified as supporting the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassVccVci MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support. Such RCST is qualified as supporting the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassPidPoolReference MIN-ACCESS not-accessible DESCRIPTION "Read-only access required if the RCST supports MPEG traffic bursts, according to the MPEG_TRF option, as defined in the SatLabs System Recommendations. Create access only required if the RCST also supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassCra MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassRbdcMax MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." Combes, et al. Informational [Page 81] RFC 5728 DVB-RCS MIB March 2010 OBJECT dvbRcsRequestClassRbdcTimeout MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassVbdcMax MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassVbdcTimeout MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassVbdcMaxBackLog MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsRequestClassRowStatus MIN-ACCESS read-only DESCRIPTION "Create access only required if the RCST supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsPidValue MIN-ACCESS not-accessible DESCRIPTION "Read-only access required if the RCST supports MPEG traffic bursts, according to the MPEG_TRF option, as defined in the SatLabs System Recommendations. Create access only required if the RCST also supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." OBJECT dvbRcsPidPoolRowStatus MIN-ACCESS not-accessible DESCRIPTION Combes, et al. Informational [Page 82] RFC 5728 DVB-RCS MIB March 2010 "Read-only access required if the RCST supports MPEG traffic bursts, according to the MPEG_TRF option, as defined in the SatLabs System Recommendations. Create access only required if the RCST also supports extended management support, according to the SNMPMISC option, as defined in the SatLabs System Recommendations." ::= {dvbRcsRcstCompliances 1} --============================================================= -- units of conformance --============================================================= --============================================================= -- object groups for RCST system --============================================================= dvbRcsRcstSystemGroup OBJECT-GROUP OBJECTS { dvbRcsSystemMibRevision, dvbRcsSystemSatLabsProfilesDeclaration, dvbRcsSystemSatLabsOptionsDeclaration, dvbRcsSystemSatLabsFeaturesDeclaration, dvbRcsSystemLocation, dvbRcsSystemOduAntennaSize, dvbRcsSystemOduAntennaGain, dvbRcsSystemOduSspa, dvbRcsSystemOduTxType, dvbRcsSystemOduRxType, dvbRcsSystemOduRxBand, dvbRcsSystemOduRxLO, dvbRcsSystemOduTxLO, dvbRcsTcpPep, dvbRcsHttpPep } STATUS current DESCRIPTION "A collection of objects providing information applicable for basic device management support." ::= {dvbRcsRcstGroups 1} --============================================================= -- object groups for RCST networking --============================================================= dvbRcsRcstNetworkGroup OBJECT-GROUP OBJECTS { dvbRcsNetworkOamInetAddressType, dvbRcsNetworkOamInetAddress, dvbRcsNetworkOamInetAddressPrefixLength, Combes, et al. Informational [Page 83] RFC 5728 DVB-RCS MIB March 2010 dvbRcsNetworkLanInetAddressType, dvbRcsNetworkLanInetAddress, dvbRcsNetworkLanInetAddressPrefixLength, dvbRcsNetworkConfigFileDownloadUrl, dvbRcsNetworkConfigFileUploadUrl, dvbRcsNetworkLogFileUploadUrl } STATUS current DESCRIPTION "A collection of objects providing basic networking management support." ::= {dvbRcsRcstGroups 2} dvbRcsRcstExtNetworkGroup OBJECT-GROUP OBJECTS { dvbRcsNetworkOamInetAddressAssign, dvbRcsNetworkAirInterfaceDefaultGatewayInetAddressType, dvbRcsNetworkAirInterfaceDefaultGatewayInetAddress, dvbRcsNetworkAirInterfaceDefaultGatewayInetAddressPrefixLength, dvbRcsNetworkNccMgtInetAddressType, dvbRcsNetworkNccMgtInetAddress, dvbRcsNetworkNccMgtInetAddressPrefixLength } STATUS current DESCRIPTION "A collection of objects providing extended networking management support." ::= {dvbRcsRcstGroups 3} dvbRcsRcstDnsGroup OBJECT-GROUP OBJECTS { dvbRcsPrimaryDnsServerInetAddressType, dvbRcsPrimaryDnsServerInetAddress, dvbRcsPrimaryDnsServerInetAddressPrefixLength, dvbRcsSecondaryDnsServerInetAddressType, dvbRcsSecondaryDnsServerInetAddress, dvbRcsSecondaryDnsServerInetAddressPrefixLength } STATUS current DESCRIPTION "A collection of objects providing DNS management support." ::= {dvbRcsRcstGroups 4} Combes, et al. Informational [Page 84] RFC 5728 DVB-RCS MIB March 2010 --============================================================= -- object groups for RCST installation --============================================================= dvbRcsRcstInstallGroup OBJECT-GROUP OBJECTS { dvbRcsInstallAntennaAlignmentState, dvbRcsInstallCwFrequency, dvbRcsInstallCwMaxDuration, dvbRcsInstallCwPower, dvbRcsInstallCoPolReading, dvbRcsInstallXPolReading, dvbRcsInstallCoPolTarget, dvbRcsInstallXPolTarget, dvbRcsInstallStandByDuration, dvbRcsInstallTargetEsN0 } STATUS current DESCRIPTION "A collection of objects providing information applicable for basic installation support." ::= {dvbRcsRcstGroups 5} dvbRcsRcstExtInstallGroup OBJECT-GROUP OBJECTS { dvbRcsNetworkInstallLogFileDownloadUrl, dvbRcsNetworkInstallLogFileUploadUrl } STATUS current DESCRIPTION "A collection of objects providing extended device installation support." ::= {dvbRcsRcstGroups 6} --============================================================= -- object groups for QoS --============================================================= dvbRcsRcstQosGroup OBJECT-GROUP OBJECTS { dvbRcsPktClassDscpLow, dvbRcsPktClassDscpHigh, dvbRcsPktClassDscpMarkValue, dvbRcsPktClassPhbAssociation, dvbRcsPktClassRowStatus, dvbRcsPhbName, dvbRcsPhbRequestClassAssociation, dvbRcsPhbMappingRowStatus, Combes, et al. Informational [Page 85] RFC 5728 DVB-RCS MIB March 2010 dvbRcsRequestClassName, dvbRcsRequestClassChanId, dvbRcsRequestClassVccVpi, dvbRcsRequestClassVccVci, dvbRcsRequestClassCra, dvbRcsRequestClassRbdcMax, dvbRcsRequestClassRbdcTimeout, dvbRcsRequestClassVbdcMax, dvbRcsRequestClassVbdcTimeout, dvbRcsRequestClassVbdcMaxBackLog, dvbRcsRequestClassRowStatus } STATUS current DESCRIPTION "A collection of objects providing basic access to QoS configuration data." ::= {dvbRcsRcstGroups 7} dvbRcsRcstEnhancedClassifierGroup OBJECT-GROUP OBJECTS { dvbRcsPktClassIpProtocol, dvbRcsPktClassSrcInetAddressType, dvbRcsPktClassSrcInetAddress, dvbRcsPktClassSrcInetAddressPrefixLength, dvbRcsPktClassDstInetAddressType, dvbRcsPktClassDstInetAddress, dvbRcsPktClassDstInetAddressPrefixLength, dvbRcsPktClassSrcPortLow, dvbRcsPktClassSrcPortHigh, dvbRcsPktClassDstPortLow, dvbRcsPktClassDstPortHigh, dvbRcsPktClassVlanUserPri } STATUS current DESCRIPTION "A collection of objects providing support for management of the enhanced classifier." ::= {dvbRcsRcstGroups 8} dvbRcsRcstMpegQosGroup OBJECT-GROUP OBJECTS { dvbRcsRequestClassPidPoolReference, dvbRcsPidValue, dvbRcsPidPoolRowStatus } STATUS current DESCRIPTION "A collection of objects providing access to Combes, et al. Informational [Page 86] RFC 5728 DVB-RCS MIB March 2010 MPEG-related link QoS configuration data." ::= {dvbRcsRcstGroups 9} dvbRcsRcstGlobalQosGroup OBJECT-GROUP OBJECTS { dvbRcsQosGlobalRbdcMax, dvbRcsQosGlobalVbdcMax, dvbRcsQosGlobalVbdcMaxBackLog } STATUS current DESCRIPTION "A collection of objects providing access to global RCST QoS configuration data." ::= {dvbRcsRcstGroups 10} dvbRcsRcstStrictQosGroup OBJECT-GROUP OBJECTS { dvbRcsQosChannelIdStrictDispatching } STATUS current DESCRIPTION "A collection of objects allowing management of strict channel ID dispatching." ::= {dvbRcsRcstGroups 11} --============================================================= -- object groups for RCST control --============================================================= dvbRcsRcstControlGroup OBJECT-GROUP OBJECTS { dvbRcsCtrlRebootCommand, dvbRcsCtrlUserTrafficDisable, dvbRcsCtrlCwEnable, dvbRcsCtrlDownloadFileCommand, dvbRcsCtrlUploadFileCommand, dvbRcsCtrlActivateConfigFileCommand, dvbRcsCtrlRcstRxReacquire } STATUS current DESCRIPTION "A collection of objects allowing basic RCST control." ::= {dvbRcsRcstGroups 12} dvbRcsRcstExtControlGroup OBJECT-GROUP OBJECTS { dvbRcsCtrlRcstTxDisable, dvbRcsCtrlOduTxReferenceEnable, Combes, et al. Informational [Page 87] RFC 5728 DVB-RCS MIB March 2010 dvbRcsCtrlOduTxDCEnable, dvbRcsCtrlOduRxDCEnable, dvbRcsCtrlRcstLogonCommand, dvbRcsCtrlRcstLogoffCommand } STATUS current DESCRIPTION "A collection of objects allowing extended RCST control." ::= {dvbRcsRcstGroups 13} --============================================================= -- object groups for RCST state --============================================================= dvbRcsRcstStateGroup OBJECT-GROUP OBJECTS { dvbRcsRcstMode, dvbRcsRcstFaultStatus, dvbRcsRcstFwdLinkStatus, dvbRcsRcstLogUpdated, dvbRcsRcstCurrentSoftwareVersion, dvbRcsRcstAlternateSoftwareVersion, dvbRcsRcstActivatedConfigFileVersion, dvbRcsRcstDownloadedConfigFileVersion } STATUS current DESCRIPTION "A collection of objects allowing access to RCST state." ::= {dvbRcsRcstGroups 14} --============================================================= -- object groups for forward link --============================================================= dvbRcsFwdConfigGroup OBJECT-GROUP OBJECTS { dvbRcsFwdStartPopId, dvbRcsFwdStartFrequency, dvbRcsFwdStartPolar, dvbRcsFwdStartFormat, dvbRcsFwdStartRolloff, dvbRcsFwdStartSymbolRate, dvbRcsFwdStartInnerFec, dvbRcsFwdStartRowStatus } STATUS current DESCRIPTION Combes, et al. Informational [Page 88] RFC 5728 DVB-RCS MIB March 2010 "A collection of objects providing basic start forward link configuration support." ::= {dvbRcsRcstGroups 15} dvbRcsFwdStatusGroup OBJECT-GROUP OBJECTS { dvbRcsFwdStatusPopId, dvbRcsFwdStatusIfReference, dvbRcsFwdStatusNetId, dvbRcsFwdStatusNetName, dvbRcsFwdStatusFormat, dvbRcsFwdStatusFrequency, dvbRcsFwdStatusPolar, dvbRcsFwdStatusInnerFec, dvbRcsFwdStatusSymbolRate, dvbRcsFwdStatusRolloff, dvbRcsFwdStatusModulation, dvbRcsFwdStatusFecFrame, dvbRcsFwdStatusPilot, dvbRcsFwdStatusBer, dvbRcsFwdStatusCnr, dvbRcsFwdStatusRxPower } STATUS current DESCRIPTION "A collection of objects providing forward link status." ::= {dvbRcsRcstGroups 16} --============================================================= -- object groups for return link --============================================================= dvbRcsRtnConfigGroup OBJECT-GROUP OBJECTS { dvbRcsRtnConfigDefIfLevel } STATUS current DESCRIPTION "A collection of objects providing basic return link configuration support." ::= {dvbRcsRcstGroups 17} dvbRcsRtnExtConfigGroup OBJECT-GROUP OBJECTS { dvbRcsRtnConfigMaxEirp } STATUS current DESCRIPTION "A collection of objects providing extended return link Combes, et al. Informational [Page 89] RFC 5728 DVB-RCS MIB March 2010 configuration support." ::= {dvbRcsRcstGroups 18} dvbRcsRtnStatusGroup OBJECT-GROUP OBJECTS { dvbRcsRtnStatusPayloadUnit } STATUS current DESCRIPTION "A collection of objects allowing access to return link status." ::= {dvbRcsRcstGroups 19} dvbRcsRtnExtStatusGroup OBJECT-GROUP OBJECTS { dvbRcsRcstRtnLinkStatus, dvbRcsRtnStatusEbN0, dvbRcsRtnStatusSFDuration } STATUS current DESCRIPTION "A collection of objects allowing access to extended return link status." ::= {dvbRcsRcstGroups 20} dvbRcsRcstOduListGroup OBJECT-GROUP OBJECTS { dvbRcsOduTxTypeDescription, dvbRcsOduTxType, dvbRcsOduRxTypeDescription, dvbRcsOduRxType, dvbRcsOduAntennaTypeDescription, dvbRcsOduAntennaType } STATUS current DESCRIPTION "A collection of objects supporting flexible selection of ODU devices." ::= {dvbRcsRcstGroups 21} END Combes, et al. Informational [Page 90] RFC 5728 DVB-RCS MIB March 2010 5. Security Considerations This MIB module relates to a system that allows end users to access a private network or public Internet access. As such, improper manipulation of the MIB objects represented by this MIB module may result in denial of service to a large number of end users. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read- create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The use of the dvbRcsNetworkNccMgtInetAddress object to specify management stations is considered only limited protection and does not protect against attacks that spoof the management station's IP address. The use of stronger mechanisms, such as SNMPv3 security, should be considered, where possible. o The dvbRcsSystemOdu objects, dvbRcsCtrlCwEnable, dvbRcsRtnConfigMaxEirp, dvbRcsRtnConfigDefIfLevel objects, and dvbRcsRcstInstall sub-tree can, if improperly or maliciously used, lead to unwanted emissions or emission levels on the satellite uplink, thereby resulting in potential degradation of the RCS service or other services using the frequency band being used. o The RCST may have its configuration file changed by the actions of the management system using a combination of the following objects: dvbRcsNetworkInstallLogFileDownloadUrl, dvbRcsCtrlDownloadFileCommand, dvbRcsCtrlActivateConfigFileCommand, or dvbRcsCtrlRebootCommand. An improper configuration file download may result in substantial vulnerabilities and the loss of the ability of the management system to control the satellite terminal. o Setting dvbRcsNetworkLogFileUploadUrl to a wrong address may potentially impact debugging/troubleshooting efforts. o Setting objects in dvbRcsPktClassTable could cause significant changes to default traffic filtering on an RCST. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over Combes, et al. Informational [Page 91] RFC 5728 DVB-RCS MIB March 2010 the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o The dvbRcsNetworkNccMgtInetAddress object may provide sufficient information for attackers to spoof management stations that have management access to the device. o The dvbRcsRcstCurrentSoftwareVersion object may provide hints as to the software vulnerabilities of the RCST. o The object dvbRcsNetworkOamInetAddress and the table dvbRcsPktClassTable may provide clues for attacking the RCST and other subscriber devices. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations The transmission and ifType numbers described in Section 3 have already been assigned under the smi-numbers registry. 7. Acknowledgments The authors thank Gorry Fairhurst for advice in the preparation of this document and Bert Wijnen for his review comments. The authors recognize this document is a collective effort of the SatLabs Group (www.satlabs.org), in particular the many corrections and suggestions brought by Juan Luis Manas. Combes, et al. Informational [Page 92] RFC 5728 DVB-RCS MIB March 2010 8. References 8.1. Normative References [IANA] Internet Assigned Numbers Authority, "Internet Assigned Numbers Authority", June 2008, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC5017] McWalter, D., Ed., "MIB Textual Conventions for Uniform Resource Identifiers (URIs)", RFC 5017, September 2007. Combes, et al. Informational [Page 93] RFC 5728 DVB-RCS MIB March 2010 8.2. Informative References [ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Organization for Standardization (ISO). [ITU-ATM] ITU-T Recommendation I.432 (all parts): "B-ISDN user- network interface - Physical layer specification". [ITU-AAL5] ITU-T Recommendation I.363-5 (1996): "B-ISDN ATM Adaptation Layer specification: Type 5 AAL". [ETSI-DAT] ETSI EN 301 192, "Digital Video Broadcasting (DVB); DVB Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI). [ETSI-DVBS] ETSI EN 301 421, "Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI). [ETSI-DVBS2] ETSI EN 302 307, "Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications", European Telecommunications Standards Institute (ETSI). [ETSI-GSE] ETSI TS 102 606, "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol", European Telecommunications Standards Institute (ETSI). [ETSI-RCS] ETSI 301 790, "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", European Telecommunications Standards Institute (ETSI). [ETSI-SI] ETSI EN 300 468, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB Systems", European Telecommunications Standards Institute (ETSI). [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [SATLABS] SatLabs System Recommendations, . Combes, et al. Informational [Page 94] RFC 5728 DVB-RCS MIB March 2010 Authors' Addresses Stephane Combes ESTEC European Space Agency Keplerlaan 1 P.O. Box 299 2200 AG Noordwijk ZH The Netherlands EMail: stephane.combes@esa.int URL: telecom.esa.int Petter Chr. Amundsen VeriSat AS P.O Box 1 1330 Fornebu Norway EMail: pca@verisat.no URL: www.verisat.no Micheline Lambert Advantech Satellite Networks 2341 boul. Alfred-Nobel Saint-Laurent (Montreal) H4S 2A9 Quebec, Canada EMail: micheline.lambert@advantechamt.com URL: www.advantechsatnet.com Hans Peter Lexow STM Norway Vollsveien 21 1366 Lysaker Norway EMail: hlexow@stmi.com URL: www.stmi.com Combes, et al. Informational [Page 95] snmp-mibs-downloader-1.1/mibrfcs/rfc5813.txt0000644000000000000000000007517111402176072015576 0ustar Internet Engineering Task Force (IETF) R. Haas Request for Comments: 5813 IBM Category: Standards Track March 2010 ISSN: 2070-1721 Forwarding and Control Element Separation (ForCES) MIB Abstract This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5813. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Haas Standards Track [Page 1] RFC 5813 ForCES MIB March 2010 Table of Contents 1. The Internet-Standard Management Framework ......................2 2. Introduction ....................................................2 3. Requirements Notation ...........................................3 4. ForCES MIB Overview .............................................3 5. ForCES MIB Definition ...........................................4 6. Associations Kept in the MIB ...................................13 7. Support for Multiple CEs and FEs ...............................14 8. Security Considerations ........................................14 9. IANA Considerations ............................................15 10. References ....................................................15 10.1. Normative References .....................................15 10.2. Informative References ...................................16 Appendix A. Acknowledgments ......................................17 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. 2. Introduction The ForCES MIB module is a read-only MIB module that captures information related to the ForCES protocol ([RFC3654], [RFC3746], [FORCES-APP], and [RFC5810]). The ForCES MIB module does not include information that is specified in other MIB modules, such as packet counters for interfaces, etc. More specifically, the information in the ForCES MIB module relative to associations (between Control Elements and Forwarding Elements) that are in the UP state includes: o identifiers of the elements in the association, o configuration parameters of the association, and o statistics of the association. Haas Standards Track [Page 2] RFC 5813 ForCES MIB March 2010 3. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. ForCES MIB Overview The MIB module contains the latest ForCES protocol version supported by the Control Element (CE) (forcesLatestProtocolVersionSupported). Note that the CE must also allow interaction with Forwarding Elements (FEs) supporting earlier versions. For each association identified by the pair CE ID and FE ID, the following associated information is provided by the MIB module as an entry (forcesAssociationEntry) in the association table (forcesAssociationTable): o Version number of the ForCES protocol running in this association (forcesAssociationRunningProtocolVersion). o Time when the association entered the UP state (forcesAssociationTimeUp). o Time when the association left the UP state (forcesAssociationTimeDown). Note that this is only used for notification purposes as the association is removed from the MIB immediately after it leaves the UP state. o Number of ForCES Heartbeat messages sent from the CE (forcesAssociationHBMsgSent) and received by the CE (forcesAssociationHBMsgReceived) since the association entered the UP state. o Number of operational ForCES messages sent from the CE (forcesAssociationOperMsgSent) and received by the CE (forcesAssociationOperMsgReceived) since the association entered the UP state. Only messages other than Heartbeat, Association Setup, Association Setup Response, and Association Teardown are counted. Finally, the MIB module defines the following notifications: o Whenever an association enters the UP state, a notification (forcesAssociationEntryUp) is issued containing the version of the ForCES protocol running. CE ID and FE ID are concatenated to form the table index, hence they appear in the OID of the ForCES- protocol running-version object. Optionally, a notification Haas Standards Track [Page 3] RFC 5813 ForCES MIB March 2010 (forcesAssociationEntryUpStats) can instead be issued with all associated information for this association, except forcesAssociationTimeDown. o Whenever an association leaves the UP state, a notification (forcesAssociationEntryDown) is issued containing the version of the ForCES protocol running. Optionally, a notification (forcesAssociationEntryDownStats) can instead be issued with all associated information for this association. The reason is that the association and all its associated information will be removed from the MIB immediately after this notification has been issued. 5. ForCES MIB Definition FORCES-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ZeroBasedCounter32 FROM RMON2-MIB; forcesMib MODULE-IDENTITY LAST-UPDATED "201003100000Z" -- March 10, 2010 ORGANIZATION "IETF Forwarding and Control Element Separation (ForCES) Working Group" CONTACT-INFO "WG Charter: http://www.ietf.org/html.charters/forces-charter.html Mailing lists: General Discussion: forces@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/forces Chairs: Patrick Droz Email: dro@zurich.ibm.com Jamal Hadi Salim Email: hadi@mojatatu.com Haas Standards Track [Page 4] RFC 5813 ForCES MIB March 2010 Editor: Robert Haas IBM Email: rha@zurich.ibm.com" DESCRIPTION "This MIB module contains managed object definitions for the ForCES Protocol. Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this MIB module is part of RFC 5813; see the RFC itself for full legal notices." REVISION "201003100000Z" -- March 10, 2010 DESCRIPTION "Initial version, published as RFC 5813." ::= { mib-2 187 } --**************************************************************** forcesMibNotifications OBJECT IDENTIFIER ::= { forcesMib 0 } forcesMibObjects OBJECT IDENTIFIER ::= { forcesMib 1 } forcesMibConformance OBJECT IDENTIFIER ::= { forcesMib 2 } ForcesID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ForCES identifier is a 4-octet quantity." SYNTAX OCTET STRING (SIZE (4)) ForcesProtocolVersion ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "ForCES protocol version number. The version numbers used are defined in the specifications of the respective protocol: 1 - ForCESv1, RFC 5810." SYNTAX Integer32 (1..255) Haas Standards Track [Page 5] RFC 5813 ForCES MIB March 2010 -- Notifications forcesAssociationEntryUp NOTIFICATION-TYPE OBJECTS { forcesAssociationRunningProtocolVersion } STATUS current DESCRIPTION "This notification is generated as soon as an association enters the UP state. Note that these notifications are not throttled as the CE itself should throttle the setup of associations." ::= { forcesMibNotifications 1 } forcesAssociationEntryDown NOTIFICATION-TYPE OBJECTS { forcesAssociationRunningProtocolVersion } STATUS current DESCRIPTION "This notification is generated as soon as an association leaves the UP state. Note that these notifications are not throttled as the CE itself should throttle the setup of associations." ::= { forcesMibNotifications 2 } forcesAssociationEntryUpStats NOTIFICATION-TYPE OBJECTS { forcesAssociationRunningProtocolVersion, forcesAssociationTimeUp } STATUS current DESCRIPTION "This notification is generated as soon as an association enters the UP state. Note that these notifications are not throttled as the CE itself should throttle the setup of associations." ::= { forcesMibNotifications 3 } Haas Standards Track [Page 6] RFC 5813 ForCES MIB March 2010 forcesAssociationEntryDownStats NOTIFICATION-TYPE OBJECTS { forcesAssociationRunningProtocolVersion, forcesAssociationTimeUp, forcesAssociationTimeDown, forcesAssociationHBMsgSent, forcesAssociationHBMsgReceived, forcesAssociationOperMsgSent, forcesAssociationOperMsgReceived, forcesAssociationCounterDiscontinuityTime } STATUS current DESCRIPTION "This notification is generated as soon as an association leaves the UP state. Note that these notifications are not throttled as the CE itself should throttle the setup of associations." ::= { forcesMibNotifications 4 } -- Objects forcesLatestProtocolVersionSupported OBJECT-TYPE SYNTAX ForcesProtocolVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The ForCES protocol version supported by the CE. The current protocol version is 1. Note that the CE must also allow interaction with FEs supporting earlier versions." ::= { forcesMibObjects 1 } forcesAssociations OBJECT IDENTIFIER ::= { forcesMibObjects 2 } forcesAssociationTable OBJECT-TYPE SYNTAX SEQUENCE OF ForcesAssociationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table of associations." ::= { forcesAssociations 1 } Haas Standards Track [Page 7] RFC 5813 ForCES MIB March 2010 forcesAssociationEntry OBJECT-TYPE SYNTAX ForcesAssociationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one association." INDEX { forcesAssociationCEID, forcesAssociationFEID } ::= { forcesAssociationTable 1 } ForcesAssociationEntry ::= SEQUENCE { forcesAssociationCEID ForcesID, forcesAssociationFEID ForcesID, forcesAssociationRunningProtocolVersion ForcesProtocolVersion, forcesAssociationTimeUp TimeStamp, forcesAssociationTimeDown TimeStamp, forcesAssociationHBMsgSent ZeroBasedCounter32, forcesAssociationHBMsgReceived ZeroBasedCounter32, forcesAssociationOperMsgSent ZeroBasedCounter32, forcesAssociationOperMsgReceived ZeroBasedCounter32, forcesAssociationCounterDiscontinuityTime TimeStamp } forcesAssociationCEID OBJECT-TYPE SYNTAX ForcesID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ForCES ID of the CE." ::= { forcesAssociationEntry 1 } forcesAssociationFEID OBJECT-TYPE SYNTAX ForcesID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ForCES ID of the FE." ::= { forcesAssociationEntry 2 } Haas Standards Track [Page 8] RFC 5813 ForCES MIB March 2010 forcesAssociationRunningProtocolVersion OBJECT-TYPE SYNTAX ForcesProtocolVersion MAX-ACCESS read-only STATUS current DESCRIPTION "The current ForCES protocol version used in this association. The current protocol version is 1." ::= { forcesAssociationEntry 3 } forcesAssociationTimeUp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this association entered the UP state. If this association started prior to the last initialization of the network subsystem, then this object contains a zero value. This object allows to uniquely identify associations with the same CE and FE IDs." ::= { forcesAssociationEntry 4 } forcesAssociationTimeDown OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of sysUpTime at the time this association left the UP state." ::= { forcesAssociationEntry 5 } forcesAssociationHBMsgSent OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter of how many Heartbeat messages have been sent by the CE on this association since the association entered the UP state. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of forcesAssociationCounterDiscontinuityTime." ::= { forcesAssociationEntry 6 } Haas Standards Track [Page 9] RFC 5813 ForCES MIB March 2010 forcesAssociationHBMsgReceived OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter of how many Heartbeat messages have been received by the CE on this association since the association entered the UP state. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of forcesAssociationCounterDiscontinuityTime." ::= { forcesAssociationEntry 7 } forcesAssociationOperMsgSent OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter of how many messages other than Heartbeat (i.e., Config and Query) have been sent by the CE on this association since the association entered the UP state. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of forcesAssociationCounterDiscontinuityTime." ::= { forcesAssociationEntry 8 } forcesAssociationOperMsgReceived OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter of how many messages other than Heartbeat (i.e., Config response, Query response, event notification, and packet redirect) have been received by the CE on this association since the association entered the UP state. Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of forcesAssociationCounterDiscontinuityTime." ::= { forcesAssociationEntry 9 } Haas Standards Track [Page 10] RFC 5813 ForCES MIB March 2010 forcesAssociationCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this association's counters suffered a discontinuity. The relevant counters are the specific instances associated with this association of any ZeroBasedCounter32 object contained in the forcesAssociationTable. If no such discontinuities have occurred since the last reinitialization of the local management subsystem, then this object contains a zero value." ::= { forcesAssociationEntry 10 } -- Conformance forcesMibCompliances OBJECT IDENTIFIER ::= { forcesMibConformance 1 } forcesMibGroups OBJECT IDENTIFIER ::= { forcesMibConformance 2 } -- Compliance statements forcesMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers running ForCES and implementing the ForCES MIB." MODULE -- this module MANDATORY-GROUPS { forcesMibGroup, forcesNotificationGroup } GROUP forcesNotificationStatsGroup DESCRIPTION "Implementation of this group is recommended." GROUP forcesStatsGroup DESCRIPTION "Implementation of this group is recommended." ::= { forcesMibCompliances 1 } Haas Standards Track [Page 11] RFC 5813 ForCES MIB March 2010 -- Units of conformance forcesNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { forcesAssociationEntryUp, forcesAssociationEntryDown } STATUS current DESCRIPTION "A collection of notifications for signaling important ForCES events." ::= { forcesMibGroups 1 } forcesMibGroup OBJECT-GROUP OBJECTS { forcesLatestProtocolVersionSupported, forcesAssociationRunningProtocolVersion } STATUS current DESCRIPTION "A collection of objects to support management of ForCES routers." ::= { forcesMibGroups 2 } forcesNotificationStatsGroup NOTIFICATION-GROUP NOTIFICATIONS { forcesAssociationEntryUpStats, forcesAssociationEntryDownStats } STATUS current DESCRIPTION "A collection of optional notifications for signaling important ForCES events including statistics." ::= { forcesMibGroups 3 } Haas Standards Track [Page 12] RFC 5813 ForCES MIB March 2010 forcesStatsGroup OBJECT-GROUP OBJECTS { forcesAssociationTimeUp, forcesAssociationTimeDown, forcesAssociationHBMsgSent, forcesAssociationHBMsgReceived, forcesAssociationOperMsgSent, forcesAssociationOperMsgReceived, forcesAssociationCounterDiscontinuityTime } STATUS current DESCRIPTION "A collection of optional objects to provide extra information about the associations. There is no protocol reason to keep such information, but these objects can be very useful in debugging connectivity problems." ::= { forcesMibGroups 4} END 6. Associations Kept in the MIB Associations enter the UP state as soon as the CE has sent to the FE an Association Setup Response message containing a successful Association Setup Result. Only associations that are UP are reflected in this MIB module. Associations are removed from the MIB module as soon as they leave the UP state, i.e., if the CE has not received any message (Heartbeat or other protocol message) from the FE within a given time period or if an Association Teardown message has been sent by the CE. Statistics counters are initialized to zero when the association is created. If the same association goes down and comes back up, the counters will reset and the discontinuity can be discovered by checking the discontinuity timestamp. In addition, the time-up timestamp in the association allows to distinguish new associations from past ones with the same index. Note that the optional down notification contains the statistics with the final values of the statistics counters. Haas Standards Track [Page 13] RFC 5813 ForCES MIB March 2010 7. Support for Multiple CEs and FEs An NE consists of one or more FEs and one or more CEs. Where there is a single CE, that CE will have knowledge of all the associations in the NE and so can provide the information necessary to support the managed objects defined in this MIB module. Where there is more than one CE, information about the associations may be distributed among the CEs. Whether each CE implements the managed objects for the associations of which it is aware or whether the CEs cooperate to present the appearance of a single set of managed objects for all the associations in the NE is outside the scope of this document. 8. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o Objects in the forcesMibGroup are protocol versions. They are neither sensitive nor vulnerable. o Objects in the forcesStatsGroup are statistics. They are neither sensitive nor vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator Haas Standards Track [Page 14] RFC 5813 ForCES MIB March 2010 responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- forcesMIB { mib-2 187 } 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. Haas Standards Track [Page 15] RFC 5813 ForCES MIB March 2010 10.2. Informative References [FORCES-APP] Crouch, A., Khosravi, H., Doria, A., Wang, X., and K. Ogawa, "ForCES Applicability Statement", Work in Progress, February 2010. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003. [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. Haas Standards Track [Page 16] RFC 5813 ForCES MIB March 2010 Appendix A. Acknowledgments The author gratefully acknowledges the contributions of Spencer Dawkins, Jinrong Fenggen, John Flick, Xiaoyi Guo, Joel Halpern, Tom Petch, Jamal Hadi Salim, and Bert Wijnen. Author's Address Robert Haas IBM Saeumerstrasse 4 Rueschlikon 8803 CH EMail: rha@zurich.ibm.com URI: http://www.zurich.ibm.com/~rha Haas Standards Track [Page 17] snmp-mibs-downloader-1.1/mibrfcs/rfc5815.txt0000644000000000000000000040027211402176072015572 0ustar Internet Engineering Task Force (IETF) T. Dietz, Ed. Request for Comments: 5815 NEC Europe, Ltd. Category: Standards Track A. Kobayashi ISSN: 2070-1721 NTT PF Labs. B. Claise Cisco Systems, Inc. G. Muenz Technische Universitaet Muenchen April 2010 Definitions of Managed Objects for IP Flow Information Export Abstract This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5815. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Dietz, et al. Standards Track [Page 1] RFC 5815 IPFIX MIB April 2010 Table of Contents 1. Introduction ....................................................3 2. IPFIX Documents Overview ........................................3 3. The Internet-Standard Management Framework ......................4 4. Terminology .....................................................4 5. Structure of the IPFIX MIB ......................................4 5.1. The Transport Session Table ................................4 5.2. The Template Table .........................................7 5.3. The Template Definition Table ..............................9 5.4. The Export Table ..........................................11 5.5. The Metering Process Table ................................12 5.6. The Observation Point Table ...............................13 5.7. The Selection Process Table ...............................14 5.8. The Statistical Tables ....................................15 5.8.1. The Transport Session Statistical Table ............15 5.8.2. The Template Statistical Table .....................15 5.8.3. The Metering Process Statistical Table .............15 5.8.4. The Selection Process Statistical Table ............15 6. Structure of the IPFIX SELECTOR MIB ............................15 6.1. The Selector Functions ....................................16 7. Relationship to Other MIB Modules ..............................18 7.1. Relationship to the ENTITY MIB and IF MIB .................18 7.2. MIB Modules Required for IMPORTS ..........................18 8. MIB Definitions ................................................18 8.1. IPFIX MIB Definition ......................................19 8.2. IPFIX SELECTOR MIB Definition .............................56 9. Security Considerations ........................................60 10. IANA Considerations ...........................................61 11. Acknowledgments ...............................................61 12. References ....................................................62 12.1. Normative References .....................................62 12.2. Informative References ...................................63 Dietz, et al. Standards Track [Page 2] RFC 5815 IPFIX MIB April 2010 1. Introduction This document defines two MIB modules for monitoring IP Flow Information eXport (IPFIX) Devices including Exporters and Collectors. Most of the objects defined by the IPFIX MIB module MUST be implemented. Some objects MAY be implemented corresponding to the functionality implemented in the equipment. Since the IPFIX architecture [RFC5470] foresees the possibility of using Filtering and/or Sampling functions to reduce the data volume, this document also provides the IPFIX SELECTOR MIB module, which contains the standardized selection methods and is controlled by IANA. The full configuration of the IPFIX Metering Process is out of the scope of these MIB modules. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. IPFIX Documents Overview The IPFIX protocol provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The protocol document [RFC5101] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in [RFC5102]. Finally, [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. It is assumed that Flow metering, export, and collection is performed according to the IPFIX architecture defined in [RFC5470]. The monitored configuration parameters of the export and collection of Flow Templates and Data Records is modeled according to [RFC5101]. Packet selection methods that may be optionally used by the IPFIX Metering Process are not considered in this MIB module. They are defined in the Packet Sampling (PSAMP) framework [RFC5474] and Sampling techniques [RFC5475] documents. Nevertheless, the basis for defining Sampling and Filtering functions is given with the IPFIX SELECTOR MIB module. Since the PSAMP export protocol [RFC5476] is based on the IPFIX protocol, the Sampling and Filtering functions can be added to the IPFIX SELECTOR MIB module as needed. Dietz, et al. Standards Track [Page 3] RFC 5815 IPFIX MIB April 2010 3. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Terminology The definitions of the basic terms like IP Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. can be found in the IPFIX protocol document [RFC5101]. 5. Structure of the IPFIX MIB The IPFIX MIB module consists of seven main tables, the Transport Session table, the Template table and the corresponding Template Definition table, the Export table, the Metering Process table, the Observation Point table, and the Selection Process table. Since the IPFIX architecture [RFC5470] foresees the possibility of using Filtering and/or Sampling functions to reduce the data volume, the MIB module provides the basic objects for these functions with the Selection Process table. The IPFIX SELECTOR MIB module defined in the next section provides the standard Filtering and Sampling functions that can be referenced in the ipfixSelectionProcessTable. All remaining objects contain statistical values for the different tables contained in the MIB module. The following subsections describe all tables in the IPFIX MIB module. 5.1. The Transport Session Table The Transport Session is the basis of the MIB module. The Transport Session table (ipfixTransportSessionTable) contains all Transport Sessions between Exporter and Collector. The table specifies the transport layer protocol of the Transport Session and, depending on that protocol, further parameters for the Transport Session. In the case of UDP and TCP, these are the source and destination address as Dietz, et al. Standards Track [Page 4] RFC 5815 IPFIX MIB April 2010 well as the source and destination port. For Stream Control Transmission Protocol (SCTP), the table contains the SCTP Assoc Id, which is the index for the SCTP association in the SCTP MIB module [RFC3873]. The mode of operation of the device, i.e., if the Transport Session is used for collecting or exporting is given in the ipfixTransportSessionDeviceMode object. Further on, it contains the configured refresh parameters for Templates and Options Templates that are used across unreliable connections as UDP. Finally, the IPFIX version that is exported or collected by this Transport Session and a status of the Transport Session is given in the table. To illustrate the use of the above tables, let us assume the following scenario: we have an Exporter on IP address 192.0.2.22 and a Collector on IP address 192.0.2.37. The Exporter uses TCP to export Templates and Data Records. The same Exporter also exports, with UDP, to a Collector with the IP address of 192.0.2.44. This would lead to the following Transport Session table on the Exporter: Dietz, et al. Standards Track [Page 5] RFC 5815 IPFIX MIB April 2010 ipfixTransportSessionTable (1) | +- ipfixTransportSessionEntry (1) | +- index (5) (ipfixTransportSessionIndex) | +- ipfixTransportSessionIndex (1) = 5 | +- ipfixTransportSessionProtocol (2) = 6 (TCP) | +- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4) | +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22 | +- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4) | +- ipfixTransportSessionDestinationAddress (6) = 192.0.2.37 | +- ipfixTransportSessionSourcePort (7) = 7653 | +- ipfixTransportSessionDestinationPort (8) = 4739 | +- ipfixTransportSessionSctpAssocId (9) = 0 | +- ipfixTransportSessionDeviceMode (10) = exporting(1) | +- ipfixTransportSessionTemplateRefreshTimeout (11) = 0 | +- ipfixTransportSessionOptionTemplateRefreshTimeout (12) = 0 | +- ipfixTransportSessionTemplateRefreshPacket (13) = 0 | +- ipfixTransportSessionOptionTemplateRefreshPacket (14) = 0 | +- ipfixTransportSessionIpfixVersion (15) = 10 | +- ipfixTransportSessionStatus (16) = 2 (active) . . . +- index (11) (ipfixTransportSessionIndex) +- ipfixTransportSessionIndex (1) = 11 +- ipfixTransportSessionProtocol (2) = 17 (UDP) +- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4) +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22 +- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4) +- ipfixTransportSessionDestinationAddress (6) = 192.0.2.44 +- ipfixTransportSessionSourcePort (7) = 14287 +- ipfixTransportSessionDestinationPort (8) = 4739 +- ipfixTransportSessionSctpAssocId (9) = 0 +- ipfixTransportSessionDeviceMode (10) = exporting(1) +- ipfixTransportSessionTemplateRefreshTimeout (11) = 100 +- ipfixTransportSessionOptionTemplateRefreshTimeout (12) | = 100 +- ipfixTransportSessionTemplateRefreshPacket (13) = 10 +- ipfixTransportSessionOptionTemplateRefreshPacket (14) = 10 +- ipfixTransportSessionIpfixVersion (15) = 10 +- ipfixTransportSessionStatus (16) = 2 (active) The values in brackets are the OID numbers. The Collectors would then have the same entry except that the index would most likely differ and the ipfixTransportSessionDeviceMode would be collecting(2). Dietz, et al. Standards Track [Page 6] RFC 5815 IPFIX MIB April 2010 5.2. The Template Table The Template table lists all Templates (including Options Templates) that are sent (by an Exporter) or received (by a Collector). The (Options) Templates are unique per Transport Session, which also gives the device mode (Exporter or Collector) and Observation Domain; thus, the table is indexed by: o the Transport Session Index (ipfixTransportSessionIndex) o and the Observation Domain Id (ipfixTemplateObservationDomainId). It contains the Set Id and an access time denoting the time when the (Options) Template was last sent or received. To resume the above example, the Exporter may want to export a Template and an Options Template for each Transport Session defined above. This leads to the following Template table defining Template and Options Template: Dietz, et al. Standards Track [Page 7] RFC 5815 IPFIX MIB April 2010 ipfixTemplateTable (3) | +- ipfixTemplateEntry (1) | +- index (5) (ipfixTransportSessionIndex) | +- index (3) (ipfixTemplateObservationDomainId) | + index (257) (ipfixTemplateId) | | +- ipfixTemplateObservationDomainId (1) = 3 | | +- ipfixTemplateId (2) = 257 | | +- ipfixTemplateSetId (3) = 2 | | +- ipfixTemplateAccessTime (4) | | = 2008-7-1,12:49:11.2,+2:0 | | | + index (264) (ipfixTemplateId) | +- ipfixTemplateObservationDomainId (1) = 3 | +- ipfixTemplateId (2) = 264 | +- ipfixTemplateSetId (3) = 3 | +- ipfixTemplateAccessTime (4) . = 2008-7-1,12:47:04.8,+2:0 . . . +- index (11) (ipfixTransportSessionIndex) +- index (3) (ipfixTemplateObservationDomainId) + index (273) (ipfixTemplateId) | +- ipfixTemplateObservationDomainId (1) = 3 | +- ipfixTemplateId (2) = 273 | +- ipfixTemplateSetId (3) = 2 | +- ipfixTemplateAccessTime (4) | = 2008-7-1,12:49:11.2,+2:0 | + index (289) (ipfixTemplateId) +- ipfixTemplateObservationDomainId (1) = 3 +- ipfixTemplateId (2) = 289 +- ipfixTemplateSetId (3) = 3 +- ipfixTemplateAccessTime (4) = 2008-7-1,12:47:04.8,+2:0 We assume that the Transport Session that is stored with index 5 in the Transport Session table of the Exporter is stored with index 17 in the Transport Session table of the (corresponding) Collector. Then, the Template table would look as follows: Dietz, et al. Standards Track [Page 8] RFC 5815 IPFIX MIB April 2010 ipfixTemplateTable (3) | +- ipfixTemplateEntry (1) | +- index (17) (ipfixTransportSessionIndex) +- index (3) (ipfixTemplateObservationDomainId) + index (257) (ipfixTemplateId) | +- ipfixTemplateObservationDomainId (1) = 3 | +- ipfixTemplateId (2) = 257 | +- ipfixTemplateSetId (3) = 2 | +- ipfixTemplateAccessTime (4) | = 2008-7-1,12:49:11.8,+2:0 | + index (264) (ipfixTemplateId) +- ipfixTemplateObservationDomainId (1) = 3 +- ipfixTemplateId (2) = 264 +- ipfixTemplateSetId (3) = 3 +- ipfixTemplateAccessTime (4) = 2008-7-1,12:47:05.3,+2:0 The table on the second Collector would be analogous to the one shown above. 5.3. The Template Definition Table The Template Definition table lists all the Information Elements contained in a Template or Options Template. Therefore, it has the same indexes as the corresponding Template table plus the Template Id. Its own index denotes the order of the Information Element inside the Template. Besides the Information Element Id and the length of the encoded value, the table contains the enterprise number for enterprise-specific Information Elements and flags for each Information Element. The flags indicate if the Information Element is used for scoping or as a Flow Key. To resume the above example again, the Exporter is configured to export the octets received and dropped at the Observation Point since the last export of these values. In addition, it exports the start and end time of the Flow relative to the timestamp contained in the IPFIX header. This leads to the following Template Definition table on the Exporter: Dietz, et al. Standards Track [Page 9] RFC 5815 IPFIX MIB April 2010 ipfixTemplateDefinitionTable (4) | +- ipfixTemplateDefinitionEntry (1) | +- index (5) (ipfixTransportSessionIndex) +- index (3) (ipfixTemplateObservationDomainId) + index (257) (ipfixTemplateId) +- index (1) (ipfixTemplateDefinitionIndex) | +- ipfixTemplateDefinitionIndex (1) = 1 | +- ipfixTemplateDefinitionIeId (2) = 158 | | (flowStartDeltaMicroseconds) | +- ipfixTemplateDefinitionIeLength (3) = 4 | +- ipfixTemplateDefinitionEnterprise (4) = 0 | +- ipfixTemplateDefinitionFlags (5) = 0 | +- index (2) (ipfixTemplateDefinitionIndex) | +- ipfixTemplateDefinitionIndex (1) = 2 | +- ipfixTemplateDefinitionIeId (2) = 159 | | (flowEndDeltaMicroseconds) | +- ipfixTemplateDefinitionIeLength (3) = 4 | +- ipfixTemplateDefinitionEnterprise (4) = 0 | +- ipfixTemplateDefinitionFlags (5) = 0 | +- index (3) (ipfixTemplateDefinitionIndex) | +- ipfixTemplateDefinitionIndex (1) = 3 | +- ipfixTemplateDefinitionIeId (2) = 1 | | (octetDeltaCount) | +- ipfixTemplateDefinitionIeLength (3) = 8 | +- ipfixTemplateDefinitionEnterprise (4) = 0 | +- ipfixTemplateDefinitionFlags (5) = 0 | +- index (4) (ipfixTemplateDefinitionIndex) +- ipfixTemplateDefinitionIndex (1) = 4 +- ipfixTemplateDefinitionIeId (2) = 132 | (droppedOctetDeltaCount) +- ipfixTemplateDefinitionIeLength (3) = 8 +- ipfixTemplateDefinitionEnterprise (4) = 0 +- ipfixTemplateDefinitionFlags (5) = 0 The corresponding table entry on the Collector is the same except that it would have another ipfixTransportSessionIndex, e.g., 17 as in the previous example. Dietz, et al. Standards Track [Page 10] RFC 5815 IPFIX MIB April 2010 5.4. The Export Table On Exporters, the Export table (ipfixExportTable) can be used to support features like failover, load-balancing, duplicate export to several Collectors, etc. The table has three indexes that link an entry with: o the Metering Process table (ipfixMeteringProcessCacheId, see below) o and the Transport Session table (ipfixTransportSessionIndex). Those entries with the same ipfixExportIndex and the same ipfixMeteringProcessCacheId define a Transport Session group. The member type for each group member describes its functionality. All Transport Sessions referenced in this table MUST have the ipfixTransportSessionDeviceMode exporting(1). If the Exporter does not use Transport Session grouping, then each ipfixExportIndex contains a single ipfixMeteringProcessCacheId, and thus a singe Transport Session (ipfixTransportSessionIndex) and this session MUST have the member type primary(1). For failover, a Transport Session group can contain one Transport Session with member type "primary" and several Transport Sessions with type secondary(2). Entries with other member types are not allowed for that type of group. For load-balancing or parallel export, all Transport Sessions in the group MUST have the same member type, either loadBalancing(4) or parallel(3). The algorithms used for failover or load-balancing are out of the scope of this document. To continue the example, we assume that the Exporter uses the two connections shown in the examples above as one primary Transport Session protected by a secondary Transport Session. The Exporter then has the following entries in the ipfixExportTable: Dietz, et al. Standards Track [Page 11] RFC 5815 IPFIX MIB April 2010 ipfixExportTable (5) | +- ipfixExportEntry (1) | +- index (7) (ipfixExportIndex) | +- index (9) (ipfixMeteringProcessCacheId) | | +- index (5) (ipfixTransportSessionIndex) | | +- ipfixExportIndex (1) = 7 | | +- ipfixExportMemberType (2) = 1 (primary) | | | +- index (11) (ipfixTransportSessionIndex) | +- ipfixExportIndex (1) = 7 | +- ipfixExportMemberType (2) = 2 (secondary) | +- index (8) (ipfixExportIndex) +- index (9) (ipfixMeteringProcessCacheId) +- index (5) (ipfixTransportSessionIndex) | +- ipfixExportIndex (1) = 8 | +- ipfixExportMemberType (2) = 2 (secondary) +- index (11) (ipfixTransportSessionIndex) +- ipfixExportIndex (1) = 8 +- ipfixExportMemberType (2) = 1 (primary) The example shows that the Exporter uses the Metering Process Cache 9, explained below, to export IPFIX Data Records for the Transport Sessions 5 and 11. The Templates 257 and 264 defined above are exported within Transport Session 5, and the Templates 273 and 289 are exported within Transport Session 11. If we assume that Templates 257 and 264 are identical, then the Collector that receives Transport Session 11 is a backup for the Collector of Transport Session 5. 5.5. The Metering Process Table The Metering Process, as defined in [RFC5101], consists of a set of functions. Maintaining the Flow Records is one of them. This function is responsible for passing the Flow Records to the Exporting Process and also for detecting Flow expiration. The Flow Records that are maintained by the Metering Process can be grouped by the Observation Points at which they are observed. The instance that maintains such a group of Flow Records is a kind of cache. For this reason, the Metering Process table (ipfixMeteringProcessTable) is indexed by cache Ids (ipfixMeteringProcessCacheId). Each cache can be maintained by a separate instance of the Metering Process. To specify the Observation Point(s) where the Flow Records are gathered, the ipfixMeteringProcessObservationPointGroupRef may contain an ipfixObservationPointGroupId from the Observation Point table (ipfixObservationPointTable) described in the next section. If an Dietz, et al. Standards Track [Page 12] RFC 5815 IPFIX MIB April 2010 Observation Point is not specified for the Flow Records, the ipfixMeteringProcessObservationPointGroupRef MUST be zero(0). The timeouts (ipfixMeteringProcessCacheActiveTimeout and ipfixMeteringProcessCacheInactiveTimeout) specify when Flows are expired. ipfixMeteringProcessTable (6) | +- ipfixMeteringProcessEntry (1) | +- index (9) (ipfixMeteringProcessCacheId) +- ipfixMeteringProcessCacheId (1) = 9 +- ipfixMeteringProcessObservationPointGroupRef (2) = 17 +- ipfixMeteringProcessCacheActiveTimeout (3) = 100 +- ipfixMeteringProcessCacheInactiveTimeout (4) = 100 5.6. The Observation Point Table The Observation Point table (ipfixObservationPointTable) groups Observation Points with the ipfixObservationPointGroupId. Each entry contains the Observation Domain Id in which the Observation Point is located and a reference to the ENTITY MIB module [RFC4133] or the IF MIB module [RFC2863]. The objects in the ENTITY MIB module referenced by ipfixObservationPointPhysicalEntity or IF MIB module referenced by ipfixObservationPointPhysicalInterface denote the Observation Point. If no such index can be given in those modules, the references MUST be 0. If a reference is given in both object ipfixObservationPointPhysicalEntity and ipfixObservationPointPhysicalInterface, then both MUST point to the same physical interface. In addition, a direction can be given to render more specifically which Flow to monitor. Dietz, et al. Standards Track [Page 13] RFC 5815 IPFIX MIB April 2010 ipfixObservationPointTable (7) | +- ipfixObservationPointEntry (1) | +- index (17) (ipfixObservationPointGroupId) +- index (1) (ipfixObservationPointIndex) | +- ipfixObservationPointGroupId (1) = 17 | +- ipfixObservationPointIndex (2) = 1 | +- ipfixObservationPointObservationDomainId (3) = 3 | +- ipfixObservationPointPhysicalEntity (4) = 6 | +- ipfixObservationPointPhysicalInterface(5) = 0 | +- ipfixObservationPointPhysicalEntityDirection (6) = 3 (both) | +- index (2) (ipfixObservationPointIndex) +- ipfixObservationPointGroupId (1) = 17 +- ipfixObservationPointIndex (2) = 2 +- ipfixObservationPointObservationDomainId (3) = 3 +- ipfixObservationPointPhysicalEntity (4) = 0 +- ipfixObservationPointPhysicalInterface (5) = 0 +- ipfixObservationPointPhysicalEntityDirection (6) = 1 (ingress) 5.7. The Selection Process Table This table supports the usage of Filtering and Sampling functions, as described in [RFC5470]. It contains lists of functions per Metering Process cache (ipfixMeteringProcessCacheId). The selection process index ipfixSelectionProcessIndex forms groups of selection methods that are applied to an observed packet stream. The selection process selector index (ipfixSelectionProcessSelectorIndex) indicates the order in which the functions are applied to the packets observed at the Observation Points associated with the Metering Process cache. The selection methods are applied in increasing order, i.e., selection methods with a lower ipfixSelectionProcessSelectorIndex are applied first. The functions are referred by object identifiers pointing to the function with its parameters. If the selection method does not use parameters, then it MUST point to the root of the function subtree (see also Section 6). If the function uses parameters, then it MUST point to an entry in the parameter table of the selection method. If no Filtering or Sampling function is used for a Metering Process, then an entry for the Metering Process SHOULD be created pointing to the Select All function (ipfixFuncSelectAll). Dietz, et al. Standards Track [Page 14] RFC 5815 IPFIX MIB April 2010 5.8. The Statistical Tables For the ipfixTransportSessionTable, the ipfixTemplateTable, the ipfixMeteringProcessTable, and the ipfixSelectionProcessTable statistical tables are defined that augment those tables. All the statistical tables contain a discontinuity object that holds a timestamp that denotes the time when a discontinuity event occurred to notify the management system that the counters contained in those tables might not be continuous anymore. 5.8.1. The Transport Session Statistical Table The Transport Session Statistical table (ipfixTransportSessionStatsTable) augments the ipfixTransportSessionTable with statistical values. It contains the rate (in bytes per second) with which it receives or sends out IPFIX Messages, the number of bytes, packets, messages, Records, Templates and Options Templates received or sent and the number of messages that were discarded. 5.8.2. The Template Statistical Table This table contains a statistical value for each Template. It augments the Template table (ipfixTemplateTable) and specifies the number of Data Records exported or collected for the Template. 5.8.3. The Metering Process Statistical Table This table augments the Metering Process table (ipfixMeteringProcessTable). It contains the statistical values for the exported Data Records and the number of unused cache entries. 5.8.4. The Selection Process Statistical Table This table augments the Selection Process table (ipfixSelectionProcessTable) and introduces two generic statistical values, the number of packets observed and the number of packets dropped by the selection method. 6. Structure of the IPFIX SELECTOR MIB The IPFIX SELECTOR MIB module defined in this section provides the standard Filtering and Sampling functions that can be referenced in the ipfixSelectionProcessTable. The subtree ipfixSelectorFunctions is a placeholder where all standard Filtering and Sampling functions should be located. It currently contains the Select All function (ipfixFuncSelectAll). The IPFIX SELECTOR MIB module is maintained by IANA and can be extended through Expert Review [RFC5226], i.e., Dietz, et al. Standards Track [Page 15] RFC 5815 IPFIX MIB April 2010 review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OID SHOULD be assigned to a new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in the next Section and MUST be published using a well-established and persistent publication medium. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. 6.1. The Selector Functions The following figure shows what the MIB tree usually should look like. It already contains the ipfixFuncSelectAll. The subtree in ipfixFuncF2 gives the basic structure that all selection methods SHOULD follow. ipfixSelectorFunctions | +- ipfixFuncSelectAll | | | +- ipfixFuncSelectAllAvail (is the function available?) | +- ipfixFuncF2 | | | +- ipfixFuncF2Avail (is the function F2 available?) | | | +- ipfixFuncF2Parameters (a table with parameters) ... | +- ipfixFunFn... The selection method SHOULD be designed as a MIB subtree introduced by an object with the name ipfixFunc appended by a function name. The objects in this subtree SHOULD be prefixed by this name. If the function is named Fx, then we would start a subtree with an OID named ipfixFuncFx. This subtree should contain an object ipfixFuncFxAvail that has the type TruthValue. If a selection method takes parameters, the MIB should contain a table named ipfixFuncFxParameters, which should contain all the parameters that the selection method specifies. An entry in this table will be referenced by the IPFIX MIB module if the selection method with the parameters is used. Dietz, et al. Standards Track [Page 16] RFC 5815 IPFIX MIB April 2010 To illustrate the structure defined above, the following contains an example of a function MyFunc that holds three integer parameters Param1, Param2, and Param3. In the example, there are currently two instances of the parameters set defined with indexes 1 and 4. ipfixSelectorFunctions (1) | +- ipfixFuncMyFunc (?) | +- ipfixFuncMyFuncAvail (1) = true +- ipfixFuncMyFuncParameters (2) | +- ipfixFuncMyFuncParametersEntry (1) | +- index (1) (ipfixFuncMyFuncParametersIndex) | +- ipfixFuncMyFuncParam1 (1) = 47 | +- ipfixFuncMyFuncParam2 (2) = -128 | +- ipficFuncMyFuncParam3 (3) = 19 | +- index(4) (ipfixFuncMyFuncParametersIndex) +- ipfixFuncMyFuncParam1 (1) = 19 +- ipfixFuncMyFuncParam2 (2) = -1 +- ipficFuncMyFuncParam3 (3) = 728 If the function defined above is referenced in the IPFIX MIB module, the ipfixSelectionProcessTable would look as follows: ipfixSelectionProcessTable (8) | +- ipfixSelectionProcessEntry (1) | +- index (9) (ipfixMeteringProcessCacheId) +- index (1) (ipfixSelectionProcessIndex) +- index (1) (ipfixSelectionProcessSelectorIndex) | +- ipfixSelectionProcessSelectorFunction (3) | = ipfixSelectorFunctions.?.2.1.4 +- index (2) (ipfixSelectionProcessSelectorIndex) +- ipfixSelectionProcessSelectorFunction (3) = ipfixSelectorFunctions.?.2.1.1 This means that for the ipfixMeteringProcessCacheId(9), a Selection Process with index 1 is created that applies two times the same function but with different parameter sets. First, the function MyFunc is applied with the parameters of the set with index 4 and the with the parameters of the set with index 1. Dietz, et al. Standards Track [Page 17] RFC 5815 IPFIX MIB April 2010 7. Relationship to Other MIB Modules Besides the usual imports from the SNMP Standards [RFC2578], [RFC2579], and [RFC2580], the IPFIX MIB module references the ENTITY MIB module [RFC4133] and the IF MIB module [RFC2863]. 7.1. Relationship to the ENTITY MIB and IF MIB The Observation Point table (ipfixObservationPointTable) contains a reference to the ENTITY MIB module[RFC4133] (ipfixObservationPointPhysicalEntity) or the IF MIB module [RFC2863] (ipfixObservationPointPhysicalInterface). If the implementors of the IPFIX MIB module want to specify the physical entity where Flows are observed, then they SHOULD also implement the ENTITY MIB and/or the IF MIB module. The implementation of the ENTITY MIB and/or IF MIB module is OPTIONAL. If one of them is not implemented, then all values of the respective column ipfixObservationPointPhysicalEntity or ipfixObservationPointPhysicalInterface in the Observation Point table are zero and the values of the ipfixObservationPointPhysicalEntityDirection columns are unknown(0), if none of them are defined. 7.2. MIB Modules Required for IMPORTS The IPFIX MIB module requires the modules SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580]. Further on, it imports the textual conventions InetAddressType and InetAddress from the INET ADDRESS MIB module [RFC4001]. The IPFIX SELECTOR MIB module also requires the modules SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580]. 8. MIB Definitions This section contains the definitions of the IPFIX-MIB module and the IPFIX-SELECTOR-MIB module. There are different mandatory groups defined for Collector and Exporter implementations. The statistical objects are made OPTIONAL. Dietz, et al. Standards Track [Page 18] RFC 5815 IPFIX MIB April 2010 8.1. IPFIX MIB Definition IPFIX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32, Counter64, Gauge32 FROM SNMPv2-SMI -- RFC2578 TimeStamp, DateAndTime FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 InterfaceIndexOrZero FROM IF-MIB -- RFC2863 InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- RFC4001 PhysicalIndexOrZero FROM ENTITY-MIB; -- RFC4133 ipfixMIB MODULE-IDENTITY LAST-UPDATED "201004190000Z" -- 19 April 2010 ORGANIZATION "IETF IPFIX Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/ipfix-charter.html Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix Archive: http://www1.ietf.org/mail-archive/web/ipfix/current/index.html Editor: Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-128 Email: Thomas.Dietz@nw.neclab.eu Dietz, et al. Standards Track [Page 19] RFC 5815 IPFIX MIB April 2010 Atsushi Kobayashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi 180-8585 Japan Phone: +81-422-59-3978 Email: akoba@nttv6.net Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Gerhard Muenz Technische Universitaet Muenchen Department of Informatics Chair for Network Architectures and Services (I8) Boltzmannstr. 3 85748 Garching Germany Phone: +49 89 289-18008 Email: muenz@net.in.tum.de URI: http://www.net.in.tum.de/~muenz" DESCRIPTION "The IPFIX MIB defines managed objects for IP Flow Information eXport. These objects provide information about managed nodes supporting the IPFIX protocol, for Exporters as well as for Collectors. Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)." Dietz, et al. Standards Track [Page 20] RFC 5815 IPFIX MIB April 2010 -- Revision history REVISION "201004190000Z" -- 19 April 2010 DESCRIPTION "Initial version, published as RFC 5815." ::= { mib-2 193 } --****************************************************************** -- Top Level Structure of the MIB --****************************************************************** ipfixObjects OBJECT IDENTIFIER ::= { ipfixMIB 1 } ipfixConformance OBJECT IDENTIFIER ::= { ipfixMIB 2 } ipfixMainObjects OBJECT IDENTIFIER ::= { ipfixObjects 1 } ipfixStatistics OBJECT IDENTIFIER ::= { ipfixObjects 2 } --================================================================== -- 1.1: Objects used by all IPFIX implementations --================================================================== -------------------------------------------------------------------- -- 1.1.1: Transport Session Table -------------------------------------------------------------------- ipfixTransportSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixTransportSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the currently established Transport Sessions between an Exporting Process and a Collecting Process." ::= { ipfixMainObjects 1 } ipfixTransportSessionEntry OBJECT-TYPE SYNTAX IpfixTransportSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixTransportSessionTable." INDEX { ipfixTransportSessionIndex } ::= { ipfixTransportSessionTable 1 } Dietz, et al. Standards Track [Page 21] RFC 5815 IPFIX MIB April 2010 IpfixTransportSessionEntry ::= SEQUENCE { ipfixTransportSessionIndex Unsigned32, ipfixTransportSessionProtocol Unsigned32, ipfixTransportSessionSourceAddressType InetAddressType, ipfixTransportSessionSourceAddress InetAddress, ipfixTransportSessionDestinationAddressType InetAddressType, ipfixTransportSessionDestinationAddress InetAddress, ipfixTransportSessionSourcePort InetPortNumber, ipfixTransportSessionDestinationPort InetPortNumber, ipfixTransportSessionSctpAssocId Unsigned32, ipfixTransportSessionDeviceMode INTEGER, ipfixTransportSessionTemplateRefreshTimeout Unsigned32, ipfixTransportSessionOptionsTemplateRefreshTimeout Unsigned32, ipfixTransportSessionTemplateRefreshPacket Unsigned32, ipfixTransportSessionOptionsTemplateRefreshPacket Unsigned32, ipfixTransportSessionIpfixVersion Unsigned32, ipfixTransportSessionStatus INTEGER } ipfixTransportSessionIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixTransportSessionTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization." ::= { ipfixTransportSessionEntry 1 } ipfixTransportSessionProtocol OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol used for receiving or transmitting IPFIX Messages. Protocol numbers are assigned by IANA. A current list of all assignments is available from ." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 10." ::= { ipfixTransportSessionEntry 2 } Dietz, et al. Standards Track [Page 22] RFC 5815 IPFIX MIB April 2010 ipfixTransportSessionSourceAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address used for the source address, as specified in RFC 4001. This object is used with protocols (specified in ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that have the notion of addresses. SCTP (132) should use the ipfixTransportSessionSctpAssocId instead. If SCTP (132) or any other protocol without the notion of addresses is used, the object MUST be set to unknown(0)." ::= { ipfixTransportSessionEntry 3 } ipfixTransportSessionSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The source address of the Exporter of the IPFIX Transport Session. This value is interpreted according to the value of ipfixTransportSessionAddressType as specified in RFC 4001. This object is used with protocols (specified in ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that have the notion of addresses. SCTP (132) should use the ipfixTransportSessionSctpAssocId instead. If SCTP (132) or any other protocol without the notion of addresses is used, the object MUST be set to a zero-length string." ::= { ipfixTransportSessionEntry 4 } ipfixTransportSessionDestinationAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address used for the destination address, as specified in RFC 4001. This object is used with protocols (specified in ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that have the notion of addresses. SCTP (132) should use the ipfixTransportSessionSctpAssocId instead. If SCTP (132) or any other protocol without the notion of addresses is used, the object MUST be set to unknown(0)." ::= { ipfixTransportSessionEntry 5 } ipfixTransportSessionDestinationAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 23] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "The destination address of the Collector of the IPFIX Transport Session. This value is interpreted according to the value of ipfixTransportSessionAddressType, as specified in RFC 4001. This object is used with protocols (specified in ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that have the notion of addresses. SCTP (132) should use the ipfixTransportSessionSctpAssocId instead. If SCTP (132) or any other protocol without the notion of addresses is used, the object MUST be set to a zero-length string" ::= { ipfixTransportSessionEntry 6 } ipfixTransportSessionSourcePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol port number of the Exporter. This object is used with protocols (specified in ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that have the notion of ports. SCTP (132) should copy the value of sctpAssocLocalPort if the Transport Session is in collecting mode or sctpAssocRemPort if the Transport Session is in exporting mode. The association is referenced by the ipfixTransportSessionSctpAssocId. If any other protocol without the notion of ports is used, the object MUST be set to zero." ::= { ipfixTransportSessionEntry 7 } ipfixTransportSessionDestinationPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol port number of the Collector. The default value is 4739 for all currently defined transport protocol types. This object is used with protocols (specified in ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that have the notion of ports. SCTP (132) should copy the value of sctpAssocRemPort if the Transport Session is in collecting mode or sctpAssocLocalPort if the Transport Session is in exporting mode. The association is referenced by the ipfixTransportSessionSctpAssocId. If any other protocol without the notion of ports is used, the object MUST be set to zero." Dietz, et al. Standards Track [Page 24] RFC 5815 IPFIX MIB April 2010 ::= { ipfixTransportSessionEntry 8 } ipfixTransportSessionSctpAssocId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The association id used for the SCTP session between the Exporter and the Collector of the IPFIX Transport Session. It is equal to the sctpAssocId entry in the sctpAssocTable defined in the SCTP MIB. This object is only valid if ipfixTransportSessionProtocol has the value 132 (SCTP). In all other cases, the value MUST be zero." REFERENCE "RFC 3873, Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)." ::= { ipfixTransportSessionEntry 9 } ipfixTransportSessionDeviceMode OBJECT-TYPE SYNTAX INTEGER { exporting(1), collecting(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The mode of operation of the device for the given Transport Session. This object can have the following values: exporting(1) This value MUST be used if the Transport Session is used for exporting Records to other IPFIX Devices, i.e., this device acts as Exporter. collecting(2) This value MUST be used if the Transport Session is used for collecting Records from other IPFIX Devices, i.e., this device acts as Collector." ::= { ipfixTransportSessionEntry 10 } ipfixTransportSessionTemplateRefreshTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 25] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "On Exporters, this object contains the time in seconds after which IPFIX Templates are resent by the Exporter. On Collectors, this object contains the lifetime in seconds after which a Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases, the value MUST be zero." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Sections 10.3.6 and 10.3.7." ::= { ipfixTransportSessionEntry 11 } ipfixTransportSessionOptionsTemplateRefreshTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "On Exporters, this object contains the time in seconds after which IPFIX Options Templates are resent by the Exporter. On Collectors, this object contains the lifetime in seconds after which an Options Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases the value MUST be zero." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Sections 10.3.6 and 10.3.7." ::= { ipfixTransportSessionEntry 12 } ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE SYNTAX Unsigned32 UNITS "packets" MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 26] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "On Exporters, this object contains the number of exported IPFIX Messages after which IPFIX Templates are resent by the Exporter. On Collectors, this object contains the lifetime in number of exported IPFIX Messages after which a Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases the value MUST be zero." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Sections 10.3.6 and 10.3.7." ::= { ipfixTransportSessionEntry 13 } ipfixTransportSessionOptionsTemplateRefreshPacket OBJECT-TYPE SYNTAX Unsigned32 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "On Exporters, this object contains the number of exported IPFIX Messages after which IPFIX Options Templates are resent by the Exporter. On Collectors, this object contains the lifetime in number of exported IPFIX Messages after which an Options Template becomes invalid when it is not received again within this lifetime. This object is only valid if ipfixTransportSessionProtocol has the value 17 (UDP). In all other cases the value MUST be zero." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Sections 10.3.6 and 10.3.7." ::= { ipfixTransportSessionEntry 14 } ipfixTransportSessionIpfixVersion OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 27] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "On Exporters the object contains the version number of the IPFIX protocol that the Exporter uses to export its data in this Transport Session. On Collectors the object contains the version number of the IPFIX protocol it receives for this Transport Session. If IPFIX Messages of different IPFIX protocol versions are transmitted or received in this Transport Session, this object contains the maximum version number." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.1." ::= { ipfixTransportSessionEntry 15 } ipfixTransportSessionStatus OBJECT-TYPE SYNTAX INTEGER { unknown(0), inactive(1), active(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The status of a Transport Session. This object can have the following values: unknown(0) This value MUST be used if the status of the Transport Session cannot be detected by the equipment. This value should be avoided as far as possible. inactive(1) This value MUST be used for Transport Sessions that are specified in the system but are not currently active. The value can be used, e.g., for Transport Sessions that are backup (secondary) sessions in a Transport Session group. active(2) This value MUST be used for Transport Sessions that are currently active and transmitting or receiving data." ::= { ipfixTransportSessionEntry 16 } Dietz, et al. Standards Track [Page 28] RFC 5815 IPFIX MIB April 2010 -------------------------------------------------------------------- -- 1.1.2: Template Table -------------------------------------------------------------------- ipfixTemplateTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the Templates and Options Templates that are transmitted by the Exporting Process or received by the Collecting Process. The table contains the Templates and Options Templates that are received or used for exporting data for a given Transport Session group and Observation Domain. Withdrawn or invalidated (Options) Template MUST be removed from this table." ::= { ipfixMainObjects 2 } ipfixTemplateEntry OBJECT-TYPE SYNTAX IpfixTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixTemplateTable." INDEX { ipfixTransportSessionIndex, ipfixTemplateObservationDomainId, ipfixTemplateId } ::= { ipfixTemplateTable 1 } IpfixTemplateEntry ::= SEQUENCE { ipfixTemplateObservationDomainId Unsigned32, ipfixTemplateId Unsigned32, ipfixTemplateSetId Unsigned32, ipfixTemplateAccessTime DateAndTime } Dietz, et al. Standards Track [Page 29] RFC 5815 IPFIX MIB April 2010 ipfixTemplateObservationDomainId OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Id of the Observation Domain for which this Template is defined. This value is used when sending IPFIX Messages. The special value of 0 indicates that the Data Records exported with this (Option Template) cannot be applied to a single Observation Domain." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.1." ::= { ipfixTemplateEntry 1 } ipfixTemplateId OBJECT-TYPE SYNTAX Unsigned32 (256..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This number indicates the Template Id in the IPFIX Message. Values from 0 to 255 are not allowed for Template Ids." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.4.1." ::= { ipfixTemplateEntry 2 } ipfixTemplateSetId OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This number indicates the Set Id of the Template. This object allows to easily retrieve the Template type. Currently, there are two values defined. The value 2 is used for Sets containing Template definitions. The value 3 is used for Sets containing Options Template definitions." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.3.2." ::= { ipfixTemplateEntry 3 } Dietz, et al. Standards Track [Page 30] RFC 5815 IPFIX MIB April 2010 ipfixTemplateAccessTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the Transport Session is in exporting mode (ipfixTransportSessionDeviceMode) the time when this (Options) Template was last sent to the Collector(s). In the specific case of UDP as transport protocol, this time is used to know when a retransmission of the (Options) Template is needed. If it is in collecting mode, this object contains the time when this (Options) Template was last received from the Exporter. In the specific case of UDP as transport protocol, this time is used to know when this (Options) Template times out and thus is no longer valid." ::= { ipfixTemplateEntry 4 } -------------------------------------------------------------------- -- 1.1.3: Exported Template Definition Table -------------------------------------------------------------------- ipfixTemplateDefinitionTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixTemplateDefinitionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "On Exporters, this table lists the (Options) Template fields of which a (Options) Template is defined. It defines the (Options) Template given in the ipfixTemplateId specified in the ipfixTemplateTable. On Collectors, this table lists the (Options) Template fields of which a (Options) Template is defined. It defines the (Options) Template given in the ipfixTemplateId specified in the ipfixTemplateTable." ::= { ipfixMainObjects 3 } ipfixTemplateDefinitionEntry OBJECT-TYPE SYNTAX IpfixTemplateDefinitionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixTemplateDefinitionTable." Dietz, et al. Standards Track [Page 31] RFC 5815 IPFIX MIB April 2010 INDEX { ipfixTransportSessionIndex, ipfixTemplateObservationDomainId, ipfixTemplateId, ipfixTemplateDefinitionIndex } ::= { ipfixTemplateDefinitionTable 1 } IpfixTemplateDefinitionEntry ::= SEQUENCE { ipfixTemplateDefinitionIndex Unsigned32, ipfixTemplateDefinitionIeId Unsigned32, ipfixTemplateDefinitionIeLength Unsigned32, ipfixTemplateDefinitionEnterpriseNumber Unsigned32, ipfixTemplateDefinitionFlags BITS } ipfixTemplateDefinitionIndex OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ipfixTemplateDefinitionIndex specifies the order in which the Information Elements are used in the (Options) Template Record. Since a Template Record can contain a maximum of 65535 Information Elements, the index is limited to this value." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Sections 3.4.1 and 3.4.2." ::= { ipfixTemplateDefinitionEntry 1 } ipfixTemplateDefinitionIeId OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates the Information Element Id at position ipfixTemplateDefinitionIndex in the (Options) Template ipfixTemplateId. This implicitly specifies the data type of the Information Element. The elements are registered at IANA. A current list of assignments can be found at " Dietz, et al. Standards Track [Page 32] RFC 5815 IPFIX MIB April 2010 REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.2. RFC 5102, Information Model for IP Flow Information Export." ::= { ipfixTemplateDefinitionEntry 2 } ipfixTemplateDefinitionIeLength OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates the length of the Information Element Id at position ipfixTemplateDefinitionIndex in the (Options) Template ipfixTemplateId." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.2. RFC 5102, Information Model for IP Flow Information Export." ::= { ipfixTemplateDefinitionEntry 3 } ipfixTemplateDefinitionEnterpriseNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "IANA enterprise number of the authority defining the Information Element identifier in this Template Record. Enterprise numbers are assigned by IANA. A current list of all assignments is available from . This object must be zero(0) for all standard Information Elements registered with IANA. A current list of these elements is available from ." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.2. RFC 5102, Information Model for IP Flow Information Export." ::= { ipfixTemplateDefinitionEntry 4 } Dietz, et al. Standards Track [Page 33] RFC 5815 IPFIX MIB April 2010 ipfixTemplateDefinitionFlags OBJECT-TYPE SYNTAX BITS { scope(0), flowKey(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates special attributes for the Information Element: scope(0) This Information Element is used for scope. flowKey(1) This Information Element is a Flow Key. Thus, we get the following values for an Information Element: If neither bit scope(0) nor bit flowKey(1) are set The Information Element is neither used for scoping nor as Flow Key. If only bit scope(0) is set The Information Element is used for scoping. If only bit flowKey(1) is set The Information Element is used as Flow Key. Both bit scope(0) and flowKey(1) MUST NOT be set at the same time. This combination is not allowed." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Sections 2 and 3.4.2.1. RFC 5102, Information Model for IP Flow Information Export." ::= { ipfixTemplateDefinitionEntry 5 } -------------------------------------------------------------------- -- 1.1.4: Export Table -------------------------------------------------------------------- ipfixExportTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixExportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all exports of an IPFIX device. Dietz, et al. Standards Track [Page 34] RFC 5815 IPFIX MIB April 2010 On Exporters, this table contains all exports grouped by Transport Session, Observation Domain Id, Template Id, and Metering Process represented by the ipfixMeteringProcessCacheId. Thanks to the ipfixExportIndex, the exports can group one or more Transport Sessions to achieve a special functionality like failover management, load-balancing, etc. The entries with the same ipfixExportIndex, ipfixObservationDomainId, and ipfixMeteringProcessCacheId define a Transport Session group. If the Exporter does not use Transport Session grouping, then each ipfixExportIndex contains a single ipfixMeteringProcessCacheId and thus a singe Transport Session, and this session MUST have the member type primary(1). Transport Sessions referenced in this table MUST have the ipfixTransportSessionDeviceMode exporting(1). On Collectors, this table is not needed." ::= { ipfixMainObjects 4 } ipfixExportEntry OBJECT-TYPE SYNTAX IpfixExportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixExportTable." INDEX { ipfixExportIndex, ipfixMeteringProcessCacheId, ipfixTransportSessionIndex } ::= { ipfixExportTable 1 } IpfixExportEntry ::= SEQUENCE { ipfixExportIndex Unsigned32, ipfixExportMemberType INTEGER } ipfixExportIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixExportTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization. Dietz, et al. Standards Track [Page 35] RFC 5815 IPFIX MIB April 2010 A common ipfixExportIndex between two entries from this table expresses that there is a relationship between the Transport Sessions in ipfixTransportSessionIndex. The type of relationship is expressed by the value of ipfixExportMemberType." ::= { ipfixExportEntry 1 } ipfixExportMemberType OBJECT-TYPE SYNTAX INTEGER { unknown(0), primary(1), secondary(2), parallel(3), loadBalancing(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of a member Transport Session in a Transport Session group (identified by the value of ipfixExportIndex, ipfixObservationDomainId, and ipfixMeteringProcessCacheId). The following values are valid: unknown(0) This value MUST be used if the status of the group membership cannot be detected by the equipment. This value should be avoided as far as possible. primary(1) This value is used for a group member that is used as the primary target of an Exporter. Other group members (with the same ipfixExportIndex and ipfixMeteringProcessCacheId) MUST NOT have the value primary(1) but MUST have the value secondary(2). This value MUST also be specified if the Exporter does not support Transport Session grouping. In this case, the group contains only one Transport Session. secondary(2) This value is used for a group member that is used as a secondary target of an Exporter. The Exporter will use one of the targets specified as secondary(2) within the same Transport Session group when the primary target is not reachable. Dietz, et al. Standards Track [Page 36] RFC 5815 IPFIX MIB April 2010 parallel(3) This value is used for a group member that is used for duplicate exporting, i.e., all group members identified by the ipfixExportIndex are exporting the same Records in parallel. This implies that all group members MUST have the same membertype parallel(3). loadBalancing(4) This value is used for a group member that is used as one target for load-balancing. This means that a Record is sent to one of the group members in this group identified by ipfixExportIndex. This implies that all group members MUST have the same membertype loadBalancing(4)." ::= { ipfixExportEntry 2 } -------------------------------------------------------------------- -- 1.1.5: Metering Process Table -------------------------------------------------------------------- ipfixMeteringProcessTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixMeteringProcessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists so-called caches used at the Metering Process to store the metering data of Flows observed at the Observation Points given in the ipfixObservationPointGroupReference. The table lists the timeouts that specify when the cached metering data is expired. On Collectors, the table is not needed." ::= { ipfixMainObjects 5 } ipfixMeteringProcessEntry OBJECT-TYPE SYNTAX IpfixMeteringProcessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixMeteringProcessTable." INDEX { ipfixMeteringProcessCacheId } ::= { ipfixMeteringProcessTable 1 } Dietz, et al. Standards Track [Page 37] RFC 5815 IPFIX MIB April 2010 IpfixMeteringProcessEntry ::= SEQUENCE { ipfixMeteringProcessCacheId Unsigned32, ipfixMeteringProcessObservationPointGroupRef Unsigned32, ipfixMeteringProcessCacheActiveTimeout Unsigned32, ipfixMeteringProcessCacheInactiveTimeout Unsigned32 } ipfixMeteringProcessCacheId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixMeterinProcessTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization." ::= { ipfixMeteringProcessEntry 1 } ipfixMeteringProcessObservationPointGroupRef OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Observation Point Group Id that links this table entry to the ipfixObservationPointTable. The matching ipfixObservationPointGroupId in that table gives the Observation Points used in that cache. If the Observation Points are unknown, the ipfixMeteringProcessObservationPointGroupRef MUST be zero." ::= { ipfixMeteringProcessEntry 2 } ipfixMeteringProcessCacheActiveTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "On the Exporter, this object contains the time after which a Flow is expired (and a Data Record for the template is sent) even though packets matching this Flow are still received by the Metering Process. If this value is 0, the Flow is not prematurely expired." REFERENCE "RFC 5470, Architecture for IP Flow Information Export, Section 5.1.1, item 3." ::= { ipfixMeteringProcessEntry 3 } Dietz, et al. Standards Track [Page 38] RFC 5815 IPFIX MIB April 2010 ipfixMeteringProcessCacheInactiveTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "On the Exporter. this object contains the time after which a Flow is expired (and a Data Record for the template is sent) when no packets matching this Flow are received by the Metering Process for the given number of seconds. If this value is zero, the Flow is expired immediately, i.e., a Data Record is sent for every packet received by the Metering Process." REFERENCE "RFC 5470, Architecture for IP Flow Information Export, Section 5.1.1, item 1" ::= { ipfixMeteringProcessEntry 4 } -------------------------------------------------------------------- -- 1.1.6: Observation Point Table -------------------------------------------------------------------- ipfixObservationPointTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixObservationPointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the Observation Points used within an Exporter by the Metering Process. The index ipfixObservationPointGroupId groups Observation Points and is referenced in the Metering Process table. On Collectors this table is not needed." ::= { ipfixMainObjects 6 } ipfixObservationPointEntry OBJECT-TYPE SYNTAX IpfixObservationPointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixObservationPointTable." INDEX { ipfixObservationPointGroupId, ipfixObservationPointIndex } ::= { ipfixObservationPointTable 1 } Dietz, et al. Standards Track [Page 39] RFC 5815 IPFIX MIB April 2010 IpfixObservationPointEntry ::= SEQUENCE { ipfixObservationPointGroupId Unsigned32, ipfixObservationPointIndex Unsigned32, ipfixObservationPointObservationDomainId Unsigned32, ipfixObservationPointPhysicalEntity PhysicalIndexOrZero, ipfixObservationPointPhysicalInterface InterfaceIndexOrZero, ipfixObservationPointPhysicalEntityDirection INTEGER } ipfixObservationPointGroupId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixObservationPointTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization. This index represents a group of Observation Points. The special value of 0 MUST NOT be used within this table but is reserved for the usage in the ipfixMeteringProcessTable. An index of 0 for the ipfixObservationPointGroupReference index in that table indicates that an Observation Point is unknown or unspecified for a Metering Process cache." ::= { ipfixObservationPointEntry 1 } ipfixObservationPointIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixObservationPointTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization. This index represents a single Observation Point in an Observation Point group." ::= { ipfixObservationPointEntry 2 } ipfixObservationPointObservationDomainId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 40] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "The Id of the Observation Domain in which this Observation Point is included. The special value of 0 indicates that the Observation Points within this group cannot be applied to a single Observation Domain." REFERENCE "RFC 5101, Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information, Section 3.1." ::= { ipfixObservationPointEntry 3 } ipfixObservationPointPhysicalEntity OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the index of a physical entity in the ENTITY MIB. This physical entity is the given Observation Point. If such a physical entity cannot be specified or is not known, then the object is zero." ::= { ipfixObservationPointEntry 4 } ipfixObservationPointPhysicalInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the index of a physical interface in the IF MIB. This physical interface is the given Observation Point. If such a physical interface cannot be specified or is not known, then the object is zero. This object MAY be used stand alone or in addition to ipfixObservationPointPhysicalEntity. If ipfixObservationPointPhysicalEntity is not zero, this object MUST point to the same physical interface that is referenced in ipfixObservationPointPhysicalEntity. Otherwise, it may reference any interface in the IF MIB." ::= { ipfixObservationPointEntry 5 } Dietz, et al. Standards Track [Page 41] RFC 5815 IPFIX MIB April 2010 ipfixObservationPointPhysicalEntityDirection OBJECT-TYPE SYNTAX INTEGER { unknown(0), ingress(1), egress(2), both(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The direction of the Flow that is monitored on the given physical entity. The following values are valid: unknown(0) This value MUST be used if a direction is not known for the given physical entity. ingress(1) This value is used for monitoring incoming Flows on the given physical entity. egress(2) This value is used for monitoring outgoing Flows on the given physical entity. both(3) This value is used for monitoring incoming and outgoing Flows on the given physical entity." ::= { ipfixObservationPointEntry 6 } -------------------------------------------------------------------- -- 1.1.7: Selection Process Table -------------------------------------------------------------------- ipfixSelectionProcessTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixSelectionProcessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains Selector Functions connected to a Metering Process by the index ipfixMeteringProcessCacheId. The Selector Functions are grouped into Selection Processes by the ipfixSelectionProcessIndex. The Selector Functions are applied within the Selection Process to the packets observed for the given Metering Process cache in increasing order implied by the ipfixSelectionProcessSelectorIndex. This means Selector Functions with lower ipfixSelectionProcessSelectorIndex are applied first. The remaining packets are accounted for in Flow Records. Dietz, et al. Standards Track [Page 42] RFC 5815 IPFIX MIB April 2010 Since IPFIX does not define any Selector Function (except selecting every packet), this is a placeholder for future use and a guideline for implementing enterprise-specific Selector Function objects. The following object tree should visualize how the Selector Function objects should be implemented: ipfixSelectorFunctions | +- ipfixFuncSelectAll | | | +- ipfixFuncSelectAllAvail (is the function available?) | +- ipfixFuncF2 | | | +- ipfixFuncF2Avail (is the function F2 available?) | | | +- ipfixFuncF2Parameters (a table with parameters) ... | +- ipfixFunFn... If a Selector Function takes parameters, the MIB should contain a table with an entry for each set of parameters used at the Exporter." ::= { ipfixMainObjects 7 } ipfixSelectionProcessEntry OBJECT-TYPE SYNTAX IpfixSelectionProcessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixSelectionProcessTable." INDEX { ipfixMeteringProcessCacheId, ipfixSelectionProcessIndex, ipfixSelectionProcessSelectorIndex } ::= { ipfixSelectionProcessTable 1 } IpfixSelectionProcessEntry ::= SEQUENCE { ipfixSelectionProcessIndex Unsigned32, ipfixSelectionProcessSelectorIndex Unsigned32, ipfixSelectionProcessSelectorFunction OBJECT IDENTIFIER } Dietz, et al. Standards Track [Page 43] RFC 5815 IPFIX MIB April 2010 ipfixSelectionProcessIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixSelectionProcessTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization." ::= { ipfixSelectionProcessEntry 1 } ipfixSelectionProcessSelectorIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index specifying the order in which the referenced ipfixSelctionProcessSelectorFunctions are applied to the observed packet stream within the given Selection Process (identified by the ipfixSelectionProcessIndex). The Selector Functions are applied in increasing order, i.e., Selector Functions with lower index are applied first." ::= { ipfixSelectionProcessEntry 2 } ipfixSelectionProcessSelectorFunction OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The pointer to the Selector Function used at position ipfixSelectionProcessSelectorIndex in the list of Selector Functions for the Metering Process cache specified by the index ipfixMeteringProcessCacheId and for the given Selection Process (identified by the ipfixSelectionProcessIndex). This usually points to an object in the IPFIX SELECTOR MIB. If the Selector Function does not take parameters, then it MUST point to the root of the function subtree. If the function takes parameters, then it MUST point to an entry in the parameter table of the Selector Function." ::= { ipfixSelectionProcessEntry 3 } Dietz, et al. Standards Track [Page 44] RFC 5815 IPFIX MIB April 2010 -------------------------------------------------------------------- -- 1.2.1: Transport Session Statistics Table -------------------------------------------------------------------- ipfixTransportSessionStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixTransportSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Transport Sessions statistics between Exporting Processes and Collecting Processes." ::= { ipfixStatistics 1 } ipfixTransportSessionStatsEntry OBJECT-TYPE SYNTAX IpfixTransportSessionStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixTransportSessionStatsTable." AUGMENTS { ipfixTransportSessionEntry } ::= { ipfixTransportSessionStatsTable 1 } IpfixTransportSessionStatsEntry ::= SEQUENCE { ipfixTransportSessionRate Gauge32, ipfixTransportSessionPackets Counter64, ipfixTransportSessionBytes Counter64, ipfixTransportSessionMessages Counter64, ipfixTransportSessionDiscardedMessages Counter64, ipfixTransportSessionRecords Counter64, ipfixTransportSessionTemplates Counter64, ipfixTransportSessionOptionsTemplates Counter64, ipfixTransportSessionDiscontinuityTime TimeStamp } ipfixTransportSessionRate OBJECT-TYPE SYNTAX Gauge32 UNITS "bytes/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes per second received by the Collector or transmitted by the Exporter. A value of zero (0) means that no packets were sent or received, yet. This object is updated every second." ::= { ipfixTransportSessionStatsEntry 1 } Dietz, et al. Standards Track [Page 45] RFC 5815 IPFIX MIB April 2010 ipfixTransportSessionPackets OBJECT-TYPE SYNTAX Counter64 UNITS "packets" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received by the Collector or transmitted by the Exporter. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTransportSessionDiscontinuityTime." ::= { ipfixTransportSessionStatsEntry 2 } ipfixTransportSessionBytes OBJECT-TYPE SYNTAX Counter64 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes received by the Collector or transmitted by the Exporter. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTransportSessionDiscontinuityTime." ::= { ipfixTransportSessionStatsEntry 3 } ipfixTransportSessionMessages OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IPFIX Messages received by the Collector or transmitted by the Exporter. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTransportSessionDiscontinuityTime." ::= { ipfixTransportSessionStatsEntry 4 } ipfixTransportSessionDiscardedMessages OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 46] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "The number of received IPFIX Message that are malformed, cannot be decoded, are received in the wrong order, or are missing according to the sequence number. If used at the Exporter, the number of messages that could not be sent due to, e.g., internal buffer overflows, network congestion, or routing issues. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTransportSessionDiscontinuityTime." ::= { ipfixTransportSessionStatsEntry 5 } ipfixTransportSessionRecords OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Data Records received by the Collector or transmitted by the Exporter. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTransportSessionDiscontinuityTime." ::= { ipfixTransportSessionStatsEntry 6 } ipfixTransportSessionTemplates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Templates received or transmitted. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTransportSessionDiscontinuityTime." ::= { ipfixTransportSessionStatsEntry 7 } ipfixTransportSessionOptionsTemplates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 47] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "The number of Options Templates received or transmitted. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTransportSessionDiscontinuityTime." ::= { ipfixTransportSessionStatsEntry 8 } ipfixTransportSessionDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent occasion at which one or more of the Transport Session counters suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem." ::= { ipfixTransportSessionStatsEntry 9 } -------------------------------------------------------------------- -- 1.2.2: Template Statistics Table -------------------------------------------------------------------- ipfixTemplateStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixTemplateStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists statistics objects per Template." ::= { ipfixStatistics 2 } ipfixTemplateStatsEntry OBJECT-TYPE SYNTAX IpfixTemplateStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixTemplateStatsTable." AUGMENTS { ipfixTemplateEntry } ::= { ipfixTemplateStatsTable 1 } IpfixTemplateStatsEntry ::= SEQUENCE { ipfixTemplateDataRecords Counter64, ipfixTemplateDiscontinuityTime TimeStamp } Dietz, et al. Standards Track [Page 48] RFC 5815 IPFIX MIB April 2010 ipfixTemplateDataRecords OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Data Records that are transmitted or received per Template. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipfixTemplateDiscontinuityTime." ::= { ipfixTemplateStatsEntry 1 } ipfixTemplateDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent occasion at which the Template counter suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem." ::= { ipfixTemplateStatsEntry 2 } -------------------------------------------------------------------- -- 1.2.3: Metering Process Statistics Table -------------------------------------------------------------------- ipfixMeteringProcessStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixMeteringProcessStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists statistic objects that have data per Metering Process cache. On Collectors, this table is not needed." ::= { ipfixStatistics 3 } Dietz, et al. Standards Track [Page 49] RFC 5815 IPFIX MIB April 2010 ipfixMeteringProcessStatsEntry OBJECT-TYPE SYNTAX IpfixMeteringProcessStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixMeteringProcessStatsTable." AUGMENTS { ipfixMeteringProcessEntry } ::= { ipfixMeteringProcessStatsTable 1 } IpfixMeteringProcessStatsEntry ::= SEQUENCE { ipfixMeteringProcessCacheActiveFlows Gauge32, ipfixMeteringProcessCacheUnusedCacheEntries Gauge32, ipfixMeteringProcessCacheDataRecords Counter64, ipfixMeteringProcessCacheDiscontinuityTime TimeStamp } ipfixMeteringProcessCacheActiveFlows OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Flows currently active at this cache." ::= { ipfixMeteringProcessStatsEntry 1 } ipfixMeteringProcessCacheUnusedCacheEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of unused cache entries." ::= { ipfixMeteringProcessStatsEntry 2 } ipfixMeteringProcessCacheDataRecords OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Data Records generated. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixTemplateDiscontinuityTime." ::= { ipfixMeteringProcessStatsEntry 3 } Dietz, et al. Standards Track [Page 50] RFC 5815 IPFIX MIB April 2010 ipfixMeteringProcessCacheDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent occasion at which the Metering Process counter suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem." ::= { ipfixMeteringProcessStatsEntry 4 } -------------------------------------------------------------------- -- 1.2.4: Selection Process Statistics Table -------------------------------------------------------------------- ipfixSelectionProcessStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixSelectionProcessStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistics for the Selector Functions connected to Metering Process by the index ipfixMeteringProcessCacheId. The indexes MUST match an entry in the ipfixSelectionProcessTable." ::= { ipfixStatistics 4 } ipfixSelectionProcessStatsEntry OBJECT-TYPE SYNTAX IpfixSelectionProcessStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixSelectionProcessStatsTable." AUGMENTS { ipfixSelectionProcessEntry } ::= { ipfixSelectionProcessStatsTable 1 } IpfixSelectionProcessStatsEntry ::= SEQUENCE { ipfixSelectionProcessStatsPacketsObserved Counter64, ipfixSelectionProcessStatsPacketsDropped Counter64, ipfixSelectionProcessStatsDiscontinuityTime TimeStamp } ipfixSelectionProcessStatsPacketsObserved OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current Dietz, et al. Standards Track [Page 51] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "The number of packets observed at the entry point of the function. The entry point may be the Observation Point or the exit point of another Selector Function. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixSelectionProcessStatsDiscontinuityTime." ::= { ipfixSelectionProcessStatsEntry 1 } ipfixSelectionProcessStatsPacketsDropped OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets dropped while selecting packets. Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of ipfixSelectionProcessStatsDiscontinuityTime." ::= { ipfixSelectionProcessStatsEntry 2 } ipfixSelectionProcessStatsDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the most recent occasion at which one or more of the Selector counters suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem." ::= { ipfixSelectionProcessStatsEntry 3 } Dietz, et al. Standards Track [Page 52] RFC 5815 IPFIX MIB April 2010 --================================================================== -- 2: Conformance Information --================================================================== ipfixCompliances OBJECT IDENTIFIER ::= { ipfixConformance 1 } ipfixGroups OBJECT IDENTIFIER ::= { ipfixConformance 2 } -------------------------------------------------------------------- -- 2.1: Compliance Statements -------------------------------------------------------------------- ipfixCollectorCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "An implementation that builds an IPFIX Collector that complies to this module MUST implement the objects defined in the mandatory group ipfixCommonGroup. The implementation of all objects in the other groups is optional and depends on the corresponding functionality implemented in the equipment. An implementation that is compliant to this MIB module is limited to use only the values TCP (6), UDP (17), and SCTP (132) in the ipfixTransportSessionProtocol object because these are the only protocol currently specified for usage within IPFIX (see RFC 5101)." MODULE -- this module MANDATORY-GROUPS { ipfixCommonGroup } GROUP ipfixCommonStatsGroup DESCRIPTION "These objects should be implemented if the statistics function is implemented in the equipment." ::= { ipfixCompliances 1 } ipfixExporterCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "An implementation that builds an IPFIX Exporter that complies to this module MUST implement the objects defined in the mandatory group ipfixCommonGroup. The implementation of all other objects depends on the implementation of the corresponding functionality in the equipment." MODULE -- this module Dietz, et al. Standards Track [Page 53] RFC 5815 IPFIX MIB April 2010 MANDATORY-GROUPS { ipfixCommonGroup, ipfixExporterGroup } GROUP ipfixCommonStatsGroup DESCRIPTION "These objects should be implemented if the statistics function is implemented in the equipment." GROUP ipfixExporterStatsGroup DESCRIPTION "These objects MUST be implemented if statistical functions are implemented on the equipment." ::= { ipfixCompliances 2 } -------------------------------------------------------------------- -- 2.2: MIB Grouping -------------------------------------------------------------------- ipfixCommonGroup OBJECT-GROUP OBJECTS { ipfixTransportSessionProtocol, ipfixTransportSessionSourceAddressType, ipfixTransportSessionSourceAddress, ipfixTransportSessionDestinationAddressType, ipfixTransportSessionDestinationAddress, ipfixTransportSessionSourcePort, ipfixTransportSessionDestinationPort, ipfixTransportSessionSctpAssocId, ipfixTransportSessionDeviceMode, ipfixTransportSessionTemplateRefreshTimeout, ipfixTransportSessionOptionsTemplateRefreshTimeout, ipfixTransportSessionTemplateRefreshPacket, ipfixTransportSessionOptionsTemplateRefreshPacket, ipfixTransportSessionIpfixVersion, ipfixTransportSessionStatus, ipfixTemplateSetId, ipfixTemplateAccessTime, ipfixTemplateDefinitionIeId, ipfixTemplateDefinitionIeLength, ipfixTemplateDefinitionEnterpriseNumber, ipfixTemplateDefinitionFlags } STATUS current Dietz, et al. Standards Track [Page 54] RFC 5815 IPFIX MIB April 2010 DESCRIPTION "The main IPFIX objects." ::= { ipfixGroups 1 } ipfixCommonStatsGroup OBJECT-GROUP OBJECTS { ipfixTransportSessionRate, ipfixTransportSessionPackets, ipfixTransportSessionBytes, ipfixTransportSessionMessages, ipfixTransportSessionDiscardedMessages, ipfixTransportSessionRecords, ipfixTransportSessionTemplates, ipfixTransportSessionOptionsTemplates, ipfixTransportSessionDiscontinuityTime, ipfixTemplateDataRecords, ipfixTemplateDiscontinuityTime } STATUS current DESCRIPTION "Common statistical objects." ::= { ipfixGroups 2 } ipfixExporterGroup OBJECT-GROUP OBJECTS { ipfixExportMemberType, ipfixMeteringProcessObservationPointGroupRef, ipfixMeteringProcessCacheActiveTimeout, ipfixMeteringProcessCacheInactiveTimeout, ipfixObservationPointObservationDomainId, ipfixObservationPointPhysicalEntity, ipfixObservationPointPhysicalInterface, ipfixObservationPointPhysicalEntityDirection, ipfixSelectionProcessSelectorFunction } STATUS current DESCRIPTION "The main objects for Exporters." ::= { ipfixGroups 3 } Dietz, et al. Standards Track [Page 55] RFC 5815 IPFIX MIB April 2010 ipfixExporterStatsGroup OBJECT-GROUP OBJECTS { ipfixMeteringProcessCacheActiveFlows, ipfixMeteringProcessCacheUnusedCacheEntries, ipfixMeteringProcessCacheDataRecords, ipfixMeteringProcessCacheDiscontinuityTime, ipfixSelectionProcessStatsPacketsObserved, ipfixSelectionProcessStatsPacketsDropped, ipfixSelectionProcessStatsDiscontinuityTime } STATUS current DESCRIPTION "The statistical objects for Exporters." ::= { ipfixGroups 4 } END 8.2. IPFIX SELECTOR MIB Definition IPFIX-SELECTOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI -- RFC2578 TruthValue FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- RFC2580 ipfixSelectorMIB MODULE-IDENTITY LAST-UPDATED "201003150000Z" -- 15 March 2010 ORGANIZATION "IETF IPFIX Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/ipfix-charter.html Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix Archive: http://www1.ietf.org/mail-archive/web/ipfix/current/index.html Dietz, et al. Standards Track [Page 56] RFC 5815 IPFIX MIB April 2010 Editor: Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-128 Email: Thomas.Dietz@nw.neclab.eu Atsushi Kobayashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi 180-8585 Japan Phone: +81-422-59-3978 Email: akoba@nttv6.net Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Gerhard Muenz Technische Universitaet Muenchen Department of Informatics Chair for Network Architectures and Services (I8) Boltzmannstr. 3 85748 Garching Germany Phone: +49 89 289-18008 Email: muenz@net.in.tum.de URI: http://www.net.in.tum.de/~muenz" DESCRIPTION "The IPFIX SELECTOR MIB module defines the standard filtering and sampling functions that can be referenced in the ipfixSelectorTable of the IPFIX MIB. The subtree ipfixSelectorFunctions is a placeholder where all standard filtering and sampling functions should be located. The IPFIX SELECTOR MIB module is maintained by IANA and can be extended through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Dietz, et al. Standards Track [Page 57] RFC 5815 IPFIX MIB April 2010 Director. The group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OID SHOULD be assigned to a new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in RFC 5815 and MUST be published using a well-established and persistent publication medium. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)." -- Revision history REVISION "201003150000Z" -- 15 March 2010 DESCRIPTION "Initial version, published as RFC 5815." ::= { mib-2 194 } --****************************************************************** -- Top Level Structure of the MIB --****************************************************************** ipfixSelectorObjects OBJECT IDENTIFIER ::= { ipfixSelectorMIB 1 } ipfixSelectorConformance OBJECT IDENTIFIER ::= { ipfixSelectorMIB 2 } --================================================================== -- 1: Objects used by all IPFIX implementations --================================================================== -------------------------------------------------------------------- -- 1.1: Packet Selector Functions for IPFIX -------------------------------------------------------------------- ipfixSelectorFunctions OBJECT IDENTIFIER ::= { ipfixSelectorObjects 1 } Dietz, et al. Standards Track [Page 58] RFC 5815 IPFIX MIB April 2010 -------------------------------------------------------------------- -- 1.1.1: Function 1: Selecting All Packets -------------------------------------------------------------------- ipfixFuncSelectAll OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 1 } ipfixFuncSelectAllAvail OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the availability of the trivial function of selecting all packets. This function is always available." ::= { ipfixFuncSelectAll 1 } --================================================================== -- 2: Conformance Information --================================================================== ipfixSelectorCompliances OBJECT IDENTIFIER ::= { ipfixSelectorConformance 1 } ipfixSelectorGroups OBJECT IDENTIFIER ::= { ipfixSelectorConformance 2 } -------------------------------------------------------------------- -- 2.1: Compliance Statements -------------------------------------------------------------------- ipfixSelectorBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "An implementation that builds an IPFIX Exporter that complies to this module MUST implement the objects defined in the mandatory group ipfixBasicGroup. The implementation of all other objects depends on the implementation of the corresponding functionality in the equipment." MODULE -- this module MANDATORY-GROUPS { ipfixSelectorBasicGroup } ::= { ipfixSelectorCompliances 1 } -------------------------------------------------------------------- -- 2.2: MIB Grouping -------------------------------------------------------------------- ipfixSelectorBasicGroup OBJECT-GROUP OBJECTS { ipfixFuncSelectAllAvail } Dietz, et al. Standards Track [Page 59] RFC 5815 IPFIX MIB April 2010 STATUS current DESCRIPTION "The main IPFIX objects." ::= { ipfixSelectorGroups 1 } END 9. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if these MIB modules are implemented correctly, then there is no risk that an intruder can alter or create any management objects of these MIB modules via direct SNMP SET operations. Some of the readable objects in these MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o ipfixTransportSessionTable - contains configuration data that might be sensitive because objects in this table may reveal information about the network infrastructure o ipfixExportTable - contains configuration data that might be sensitive because object in this table may reveal information about the network infrastructure as well o ipfixMeteringProcessTable - contains configuration data that might be sensitive because objects in this table may reveal information about the IPFIX Device itself o ipfixObservationPointTable - contains configuration data that might be sensitive because objects in this table may reveal information about the IPFIX Device itself and the network infrastructure o ipfixSelectorFunctions - currently contains no sensitive data but might want to be secured anyway since it may contain sensitive data in a future version All other objects and tables contain no data that is considered sensitive. Dietz, et al. Standards Track [Page 60] RFC 5815 IPFIX MIB April 2010 SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410] Section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 10. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- ipfixMIB { mib-2 193 } ipfixSelectorMIB { mib-2 194 } Further on, the whole IPFIX SELECTOR MIB module is maintained by IANA. Additions to this MIB module are subject to Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OID SHOULD be assigned to new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 6 and MUST be published using a well-established and persistent publication medium. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. 11. Acknowledgments This document is a product of the IPFIX Working Group. The authors would like to thank the following persons: Paul Aitken for his detailed review, Dan Romascanu and the MIB doctors, and many more, for the technical reviews and feedback. Dietz, et al. Standards Track [Page 61] RFC 5815 IPFIX MIB April 2010 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)", RFC 3873, September 2004. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Dietz, et al. Standards Track [Page 62] RFC 5815 IPFIX MIB April 2010 12.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009. [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009. [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009. [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009. Dietz, et al. Standards Track [Page 63] RFC 5815 IPFIX MIB April 2010 Authors' Addresses Thomas Dietz (editor) NEC Europe, Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-128 EMail: Thomas.Dietz@nw.neclab.eu Atsushi Kobayashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 JA Phone: +81-422-59-3978 EMail: akoba@nttv6.net Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 BE Phone: +32 2 704 5622 EMail: bclaise@cisco.com Gerhard Muenz Technische Universitaet Muenchen Department of Informatics Chair for Network Architectures and Services (I8) Boltzmannstr. 3 Garching 85748 DE Phone: +49 89 289-18008 EMail: muenz@net.in.tum.de URI: http://www.net.in.tum.de/~muenz Dietz, et al. Standards Track [Page 64] snmp-mibs-downloader-1.1/mibrfcs/rfc5833.txt0000644000000000000000000043104711402176072015576 0ustar Internet Engineering Task Force (IETF) Y. Shi, Ed. Request for Comments: 5833 Hangzhou H3C Tech. Co., Ltd. Category: Informational D. Perkins, Ed. ISSN: 2070-1721 C. Elliott, Ed. Y. Zhang, Ed. Fortinet, Inc. May 2010 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5833. Shi, et al. Informational [Page 1] RFC 5833 CAPWAP Protocol Base MIB May 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Requirements and Constraints . . . . . . . . . . . . . . . 5 5.2. Wireless Binding MIB Modules . . . . . . . . . . . . . . . 5 5.3. Design Objectives . . . . . . . . . . . . . . . . . . . . 5 5.4. Design Idea . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Mechanism of Reusing Wireless Binding MIB Modules . . . . 6 5.6. CAPWAP Protocol Wireless Binding MIB Module . . . . . . . 7 5.7. WTP Profile . . . . . . . . . . . . . . . . . . . . . . . 7 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 8 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 9 7.1. Relationship to SNMPv2-MIB Module . . . . . . . . . . . . 9 7.2. Relationship to IF-MIB Module . . . . . . . . . . . . . . 9 7.3. Relationship to ENTITY-MIB Module . . . . . . . . . . . . 10 7.4. Relationship to Wireless Binding MIB Modules . . . . . . . 10 7.5. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 10 8. Example of CAPWAP-BASE-MIB Module Usage . . . . . . . . . . . 10 9. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 11.1. IANA Considerations for CAPWAP-BASE-MIB Module . . . . . . 70 11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 70 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 70 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 14.1. Normative References . . . . . . . . . . . . . . . . . . . 71 14.2. Informative References . . . . . . . . . . . . . . . . . . 72 Shi, et al. Informational [Page 2] RFC 5833 CAPWAP Protocol Base MIB May 2010 1. Introduction The CAPWAP Protocol [RFC5415] defines a standard, interoperable protocol, which enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs). This document defines a MIB module that can be used to manage the CAPWAP implementations. This MIB module covers both configuration and WTP status-monitoring aspects of CAPWAP, and provides a way to reuse MIB modules for any wireless technology. It presented as a basis for future work on a SNMP management of the CAPWAP protocol. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. 3. Terminology This document uses terminology from the CAPWAP Protocol specification [RFC5415] and the Architecture Taxonomy for CAPWAP [RFC4118]. Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Wireless Termination Point (WTP): The physical or network entity that contains an radio frequency (RF) antenna and wireless physical layer (PHY) to transmit and receive station traffic for wireless access networks. Control And Provisioning of Wireless Access Points (CAPWAP): It is a generic protocol defining AC and WTP control and data plane communication via a CAPWAP protocol transport mechanism. CAPWAP control messages, and optionally CAPWAP data messages, are secured using Datagram Transport Layer Security (DTLS) [RFC4347]. Shi, et al. Informational [Page 3] RFC 5833 CAPWAP Protocol Base MIB May 2010 CAPWAP Control Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC control port, WTP control port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control packets are sent and received. CAPWAP Data Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC data port, WTP data port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data packets are sent and received. Station (STA): A device that contains an interface to a wireless medium (WM). Split and Local MAC: The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control). In Split MAC mode, all Layer 2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTPs. The Local MAC mode allows the data frames to be either locally bridged or tunneled as 802.3 frames. Wireless Binding: The CAPWAP protocol is independent of a specific WTP radio technology, as well its associated wireless link-layer protocol. Elements of the CAPWAP protocol are designed to accommodate the specific needs of each wireless technology in a standard way. Implementation of the CAPWAP protocol for a particular wireless technology MUST define a binding protocol for it, e.g., the binding for IEEE 802.11, provided in [RFC5416]. Autonomous Wireless Local Area Network (WLAN) Architecture: It is the traditional autonomous WLAN architecture, in which each WTP is a single physical device that implements all the wireless services. Centralized WLAN Architecture: It is an emerging hierarchical architecture utilizing one or more centralized controllers for managing a large number of WTP devices. It can be said that the full wireless functions are implemented across multiple physical network devices, namely, the WTPs and ACs. 4. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Shi, et al. Informational [Page 4] RFC 5833 CAPWAP Protocol Base MIB May 2010 5. Overview 5.1. Requirements and Constraints The CAPWAP Protocol MIB module (CAPWAP-BASE-MIB) is designed to: - Support centralized management and monitoring of WTPs from the AC in combination with the CAPWAP protocol; - Allow operators to make configurations for WTPs before and after they connect to the AC; - Support querying of CAPWAP protocol parameters; - Support displaying of WTPs' current states and configurations; - Provide basic property information about the AC, WTPs, radios, and stations, and their relationships; - Provide counters for events on WTPs and radios such as reboot and hardware failure; - Provide various notifications such as channel up and join failure. 5.2. Wireless Binding MIB Modules Other Standards Development Organizations (SDOs), such as IEEE, have already defined MIB modules for a specific wireless technology, e.g., IEEE 802.11 MIB module [IEEE.802-11.2007]. Such MIB modules are called wireless binding MIB modules. 5.3. Design Objectives This document introduces a mechanism to avoid redefining MIB objects in the existing MIB modules for a specific wireless technology, in other words, a mechanism to reuse wireless binding MIB modules defined by other SDOs. In summary, the CAPWAP-BASE-MIB module has the following design objectives: - To implement an architecture that uses SNMP for the management and control of wireless networks, and answering the operator's requirements for centralized management, whatever the wireless devices are configured and deployed (centralized, autonomous, or some mix); - To be consistent with the CAPWAP protocol; Shi, et al. Informational [Page 5] RFC 5833 CAPWAP Protocol Base MIB May 2010 - To be independent of any wireless technologies and be able to reuse wireless binding MIB modules defined by other SDOs; - To enable interoperability between vendors; - To meet the management requirements for the centralized WLAN architecture. 5.4. Design Idea The basic design idea of the CAPWAP-BASE-MIB module is: - The SNMP agent MUST be run on the AC devices and is not REQUIRED on the WTP devices. It follows the same model as the CAPWAP protocol: Centralized Control. - It is designed to accommodate the specific needs of each wireless technology in a standard way. It is independent of any wireless technologies. - The ifIndex [RFC2863] is used as a common index for corresponding interfaces in the CAPWAP-BASE-MIB and the MIB modules of specific wireless technologies. - The operator could manage and control the centralized WLAN architectures using multiple MIB modules defined by multiple SDOs, while keeping them loosely coupled. 5.5. Mechanism of Reusing Wireless Binding MIB Modules For any wireless technology, the configuration and management of radios are very important. As usual, wireless binding MIB modules support radio management on their own. For example, the MIB tables such as the dot11OperationTable [IEEE.802-11.2007] are able to support WTP radio configuration. These tables use the ifIndex as the index, and work well under autonomous WLAN architecture. To reuse such wireless binding MIB modules is very important to centralized WLAN architectures. According to [RFC5415], a specific PHY radio could be identified by the combination of the identifiers of the WTP and radio (WTP ID + Radio ID), so the key point is to make use of the ifIndex idea and find a way to maintain the mappings between 'WTP ID + radio ID' and the ifIndex. As a generic mechanism, an ifIndex can identify an interface in an abstract way, and it does NOT care for the interface's PHY location (either on the WTP or AC). The AC can have WTP Virtual Radio Interfaces to logically represent PHY radios on the WTP. From the operator's perspective, it appears that PHY radios are located on the AC, and the PHY location of the Shi, et al. Informational [Page 6] RFC 5833 CAPWAP Protocol Base MIB May 2010 WTP (radio) is hidden. The operator can operate radios through MIB tables with the ifIndex of a WTP Virtual Radio Interface. As a type of abstract interface, the WTP Virtual Radio Interface could be used by any wireless technology such as IEEE 802.11 and 802.16. The capwapBaseWirelessBindingTable in the CAPWAP-BASE-MIB module is used to store the mappings between the 'WTP ID + Radio ID' and the ifIndex. 5.6. CAPWAP Protocol Wireless Binding MIB Module According to the CAPWAP Protocol specification [RFC5415], when defining a binding for wireless technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. A CAPWAP binding protocol is required for a specific wireless binding technology, e.g., the protocol of [RFC5416] for IEEE 802.11 binding. Sometimes, not all the technology-specific message elements in a CAPWAP binding protocol have MIB objects defined by other SDOs. For example, the protocol of [RFC5416] defines WLAN management. The WLAN refers to a logical component instantiated on a WTP device. A single physical WTP MAY operate a number of WLANs. Also, Local or Split MAC modes could be specified for a WLAN. The MAC mode for a WLAN is not in the scope of IEEE 802.11 [IEEE.802-11.2007]. In such cases, in addition to the existing wireless binding MIB modules defined by other SDOs, a CAPWAP protocol wireless binding MIB module is required to be defined for a wireless binding, e.g, the CAPWAP Protocol Binding MIB for IEEE 802.11 [RFC5834]. 5.7. WTP Profile In a centralized WLAN architecture, a WTP profile is used to make configurations such as a static IP address for a WTP before and after it connects to the AC. It MUST contain the Base MAC address [RFC5415] of the WTP because the CAPWAP message received from the WTP contains the Base MAC address and the AC uses this Base MAC address to find the corresponding WTP profile. Section 4.6.40 of [RFC5415] omits indicating that the WTP's Base MAC address MUST be included in the WTP Board Data message element. This is a known errata item [Err1832] and should be fixed in any future revision of RFC 5415. Another important function of WTP profile is to trigger the creation of WTP Virtual Radio Interfaces on the AC. To implement this function, a WTP profile MUST include the WTP's model number [RFC5415], which reflects the number of PHY radios on the WTP. In this way, the creation of a WTP profile triggers the AC to Shi, et al. Informational [Page 7] RFC 5833 CAPWAP Protocol Base MIB May 2010 automatically create the same number of WTP Virtual Radio Interfaces corresponding to the WTP's PHY radios without manual intervention. With the ifIndexes of WTP Virtual Radio Interfaces, the operator could configure and manage the WTP's PHY radios through the wireless binding MIB modules. 6. Structure of the MIB Module The MIB objects are derived from the CAPWAP protocol document [RFC5415]. 1) capwapBaseAcNameListTable The AC name list table is used to configure the AC name list. 2) capwapBaseMacAclTable The ACL table is used to configure stations' Access Control Lists (ACLs). 3) capwapBaseWtpProfileTable The WTP profile table is used to configure WTP profiles for WTPs to be managed before they connect to the AC. An operator could change a WTP's current configuration by changing the values of parameters in the corresponding WTP profile, then the WTP could get the new configuration through the CAPWAP control channel. 4) capwapBaseWtpStateTable The state table of WTPs is used to indicate the AC's CAPWAP FSM state for each WTP, and helps the operator to query a WTP's current configuration. 5) capwapBaseWtpTable The WTP table is used to display properties of the WTPs in running state. 6) capwapBaseWirelessBindingTable The wireless binding table is used to display the mappings between WTP Virtual Radio Interfaces and PHY radios, and the wireless binding type for each PHY radio. Shi, et al. Informational [Page 8] RFC 5833 CAPWAP Protocol Base MIB May 2010 7) capwapBaseStationTable The station table is used for providing stations' basic property information. 8) capwapBaseWtpEventsStatsTable The WTP events statistic table is used for collecting WTP reboot count, link failure count, hardware failure count and so on. 9) capwapBaseRadioEventsStatsTable The radio events statistic table is used for collecting radio reset count, channel change count, hardware failure count, and so on. 7. Relationship to Other MIB Modules 7.1. Relationship to SNMPv2-MIB Module The CAPWAP-BASE-MIB module does not duplicate the objects of the 'system' group in the SNMPv2-MIB [RFC3418] that is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. 7.2. Relationship to IF-MIB Module The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing WTP PHY radios that are modeled as interfaces. The IF-MIB module is required to be supported on the AC. Each PHY radio on the WTP corresponds to a WTP Virtual Radio Interface on the AC. The WTP Virtual Radio Interface provides a way to configure the radio's parameters and query radio's traffic statistics, and reuse wireless binding modules defined by other SDOs. The interface MUST be modeled as an ifEntry, and ifEntry objects such as ifIndex, ifDescr, ifName, and ifAlias are to be used as per [RFC2863]. Also, as an ifIndex [RFC2863] is used as a common index for corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless technologies MIB modules, the AC MUST have a mechanism that preserves the values of the ifIndexes in the ifTable at AC reboot. Shi, et al. Informational [Page 9] RFC 5833 CAPWAP Protocol Base MIB May 2010 7.3. Relationship to ENTITY-MIB Module The ENTITY-MIB module [RFC4133] meets the need for a standardized way of representing a single agent that supports multiple instances of one MIB. It could express a certain relationship between multiple entities and provide entity properties for each entity. In a centralized WLAN architecture, the SNMP agent runs on the AC and is not required on the WTP. With the ENTITY-MIB module on the AC, it could keep entity information such as firmware revision and software revision of the AC and WTPs. From the ENTITY-MIB module's perspective, the overall physical entity (AC) is a 'compound' of multiple physical entities (that is, the WTPs connected to AC), and all entities are each identified by a physical index. The capwapBaseWtpTable of the CAPWAP-BASE-MIB module uses the capwapBaseWtpPhyIndex object to store the mappings of WTP object between CAPWAP-BASE-MIB and ENTITY-MIB modules. By querying both the CAPWAP-BASE-MIB and ENTITY-MIB modules, operators could query the status and properties of the AC and WTPs. For example, they could get a WTP's current status through the CAPWAP-BASE-MIB module, and a WTP's software revision information through the ENTITY-MIB module. The CAPWAP-BASE-MIB module does not duplicate those objects defined in the ENTITY-MIB module. 7.4. Relationship to Wireless Binding MIB Modules The wireless binding MIB module of a wireless technology (such as [IEEE.802-11.2007]) is required to be supported on the AC. The CAPWAP-BASE-MIB module is able to support any wireless binding. Through the ifIndexes of WTP Virtual Radio Interfaces, it provides a consistent and abstract way of reusing MIB objects in the wireless binding MIB modules. The CAPWAP-BASE-MIB module does not duplicate those objects defined in the wireless binding MIB modules. 7.5. MIB Modules Required for IMPORTS The following MIB module IMPORTS objects from SYSAPPL-MIB [RFC2287], SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001], and ENTITY-MIB [RFC4133]. 8. Example of CAPWAP-BASE-MIB Module Usage Below, the IEEE 802.11 binding is used as an example of how the MIB modules operate. 1) Create a WTP profile. Shi, et al. Informational [Page 10] RFC 5833 CAPWAP Protocol Base MIB May 2010 Suppose the WTP's Base MAC address is '00:01:01:01:01:00'. Create the WTP profile as follows: In capwapBaseWtpProfileTable { capwapBaseWtpProfileId = 1, capwapBaseWtpProfileName = 'WTP Profile 123456', capwapBaseWtpProfileWtpMacAddress = '00:01:01:01:01:00', capwapBaseWtpProfileWtpModelNumber = 'WTP123', capwapBaseWtpProfileWtpName = 'WTP 123456', capwapBaseWtpProfileWtpLocation = 'office', capwapBaseWtpProfileWtpStaticIpEnable = true(1), capwapBaseWtpProfileWtpStaticIpType = ipv4(1), capwapBaseWtpProfileWtpStaticIpAddress = '192.0.2.10', capwapBaseWtpProfileWtpNetmask = '255.255.255.0', capwapBaseWtpProfileWtpGateway = '192.0.2.1', capwapBaseWtpProfileWtpFallbackEnable = true(1), capwapBaseWtpProfileWtpEchoInterval = 30, capwapBaseWtpProfileWtpIdleTimeout = 300, capwapBaseWtpProfileWtpMaxDiscoveryInterval = 20, capwapBaseWtpProfileWtpReportInterval = 120, capwapBaseWtpProfileWtpStatisticsTimer = 120, capwapBaseWtpProfileWtpEcnSupport = limited(0) } Suppose the WTP with model number 'WTP123' has one PHY radio, which is identified by ID 1. The creation of this WTP profile triggers the AC to automatically create a WTP Virtual Radio Interface and add a new row object to the capwapBaseWirelessBindingTable without manual intervention. Suppose the ifIndex of the WTP Virtual Radio Interface is 10. The following information is stored in the capwapBaseWirelessBindingTable. In capwapBaseWirelessBindingTable { capwapBaseWtpProfileId = 1, capwapBaseWirelessBindingRadioId = 1, capwapBaseWirelessBindingVirtualRadioIfIndex = 10, capwapBaseWirelessBindingType = dot11(2) } The WTP Virtual Radio Interfaces on the AC correspond to the PHY radios on the WTP. The WTP Virtual Radio Interface is modeled by ifTable [RFC2863]. Shi, et al. Informational [Page 11] RFC 5833 CAPWAP Protocol Base MIB May 2010 In ifTable { ifIndex = 10, ifDescr = 'WTP Virtual Radio Interface', ifType = 254, ifMtu = 0, ifSpeed = 0, ifPhysAddress = '00:00:00:00:00:00', ifAdminStatus = true(1), ifOperStatus = false(0), ifLastChange = 0, ifInOctets = 0, ifInUcastPkts = 0, ifInDiscards = 0, ifInErrors = 0, ifInUnknownProtos = 0, ifOutOctets = 0, ifOutUcastPkts = 0, ifOutDiscards = 0, ifOutErrors = 0 } 2) Query the ifIndexes of WTP Virtual Radio Interfaces. Before configuring PHY radios, the operator needs to get the ifIndexes of WTP Virtual Radio Interfaces corresponding to the PHY radios. As capwapBaseWirelessBindingTable already stores the mappings between PHY radios (Radio IDs) and the ifIndexes of WTP Virtual Radio Interfaces, the operator can get the ifIndex information by querying this table. Such a query operation SHOULD run from radio ID 1 to radio ID 31 according to [RFC5415]), and stop when an invalid ifIndex value (0) is returned. This example uses capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId = 1 as inputs to query the capwapBaseWirelessBindingTable, and gets capwapBaseWirelessBindingVirtualRadioIfIndex = 10. Then it uses capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId = 2, and gets an invalid ifIndex value (0), so the query operation ends. This method gets not only the ifIndexes of WTP Virtual Radio Interfaces, but also the numbers of PHY radios. Besides checking whether the ifIndex value is valid, the operator SHOULD check whether the capwapBaseWirelessBindingType is the desired binding type. Shi, et al. Informational [Page 12] RFC 5833 CAPWAP Protocol Base MIB May 2010 3) Configure specific wireless binding parameters for a WTP Virtual Radio Interface. This configuration is made on the AC through a specific wireless binding MIB module such as the IEEE 802.11 MIB module. The following shows an example of configuring parameters for a WTP Virtual Radio Interface with ifIndex 10 through the IEEE 802.11 dot11OperationTable [IEEE.802-11.2007]. In dot11OperationTable { ifIndex = 10, dot11MACAddress = '00:00:00:00:00:00', dot11RTSThreshold = 2347, dot11ShortRetryLimit = 7, dot11LongRetryLimit = 4, dot11FragmentationThreshold = 256, dot11MaxTransmitMSDULifetime = 512, dot11MaxReceiveLifetime = 512, dot11ManufacturerID = 'capwap', dot11ProductID = 'capwap', dot11CAPLimit = 2, dot11HCCWmin = 0, dot11HCCWmax = 0, dot11HCCAIFSN = 1, dot11ADDBAResponseTimeout = 1, dot11ADDTSResponseTimeout = 1, dot11ChannelUtilizationBeaconInterval = 50, dot11ScheduleTimeout = 10, dot11DLSResponseTimeout = 10, dot11QAPMissingAckRetryLimit = 1, dot11EDCAAveragingPeriod = 5 } 4) Get the current configuration status report from the WTP to the AC. According to [RFC5415], before a WTP that has joined the AC gets configuration from the AC, it needs to report its current configuration status by sending a configuration status request message to the AC, which uses the message to update MIB objects on the AC. For example, for IEEE 802.11 binding, the AC updates data in the ifTable [RFC2863] and IEEE 802.11 MIB module, and so on, according to the message. For ifIndex 10, its ifOperStatus in ifTable is updated according to the current radio operational status in the CAPWAP message. Shi, et al. Informational [Page 13] RFC 5833 CAPWAP Protocol Base MIB May 2010 5) Query WTP and radio statistical data. After WTPs start to run, the operator could query WTP and radio statistical data through CAPWAP-BASE-MIB and the specific binding MIB module on the AC. For example, through dot11CountersTable in the IEEE 802.11 MIB module, the operator could query the counter data of a radio using the ifIndex of the corresponding WTP Virtual Radio Interface. With the capwapBaseWtpTable table in the CAPWAP- BASE-MIB module, the operator could query the properties of running WTPs. 6) Run MIB operations through a CAPWAP protocol wireless binding MIB module. For example, for the CAPWAP IEEE 802.11 binding protocol [RFC5416], some MIB operations such as MAC mode configuration for a WLAN depend on the CAPWAP Protocol Binding MIB for IEEE 802.11 [RFC5834]. For more information, refer to [RFC5834]. 7) Query other properties of a WTP. The Operator could query MIB objects in the ENTITY-MIB [RFC4133] module by using the capwapBaseWtpPhyIndex in the capwapBaseWtpTable of CAPWAP-BASE-MIB module. The properties of a WTP such as software version, hardware version are available in the ENTITY-MIB module. 9. Definitions CAPWAP-BASE-MIB DEFINITIONS ::= BEGIN IMPORTS PhysAddress, TEXTUAL-CONVENTION, TruthValue, DateAndTime, RowStatus FROM SNMPv2-TC LongUtf8String FROM SYSAPPL-MIB InterfaceIndex, ifGeneralInformationGroup FROM IF-MIB PhysicalIndex FROM ENTITY-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB NOTIFICATION-GROUP, OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, Unsigned32, Counter32, Gauge32, TimeTicks Shi, et al. Informational [Page 14] RFC 5833 CAPWAP Protocol Base MIB May 2010 FROM SNMPv2-SMI InetAddressType, InetAddress FROM INET-ADDRESS-MIB; capwapBaseMIB MODULE-IDENTITY LAST-UPDATED "201004300000Z" -- 30 April 2010 ORGANIZATION "IETF Control And Provisioning of Wireless Access Points (CAPWAP) Working Group http://www.ietf.org/html.charters/capwap-charter.html" CONTACT-INFO "General Discussion: capwap@frascone.com To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap Yang Shi (editor) Hangzhou H3C Tech. Co., Ltd. Beijing R&D Center of H3C, Digital Technology Plaza NO. 9 Shangdi 9th Street, Haidian District Beijing 100085 China Phone: +86 010 82775276 Email: rishyang@gmail.com David T. Perkins (editor) 228 Bayview Dr. San Carlos, CA 94070 USA Phone: +1 408 394-8702 Email: dperkins@dsperkins.com Chris Elliott (editor) 1516 Kent St. Durham, NC 27707 USA Phone: +1 919-308-1216 Email: chelliot@pobox.com Yong Zhang (editor) Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA Email: yzhang@fortinet.com" DESCRIPTION "Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Shi, et al. Informational [Page 15] RFC 5833 CAPWAP Protocol Base MIB May 2010 Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this MIB module is part of RFC 5833; see the RFC itself for full legal notices. This MIB module contains managed object definitions for the CAPWAP Protocol." REVISION "201004300000Z" DESCRIPTION "Initial version published as RFC 5833" ::= { mib-2 196 } -- Textual Conventions CapwapBaseWtpProfileIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a WTP profile." SYNTAX Unsigned32 (0..4096) CapwapBaseWtpIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents the unique identifier of a WTP instance. As usual, the Base MAC address of the WTP is used." SYNTAX OCTET STRING (SIZE(6|8)) CapwapBaseStationIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents the unique identifier of a station instance. As usual, the MAC address of the station is used." SYNTAX OCTET STRING (SIZE(6|8)) CapwapBaseRadioIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a radio on a WTP." SYNTAX Unsigned32 (1..31) Shi, et al. Informational [Page 16] RFC 5833 CAPWAP Protocol Base MIB May 2010 CapwapBaseTunnelModeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the tunneling modes of operation that are supported by a WTP. The WTP MAY support more than one option, represented by the bit field below: localBridging(0) - Local bridging mode dot3Tunnel(1) - 802.3 frame tunnel mode nativeTunnel(2) - Native frame tunnel mode" REFERENCE "Section 4.6.43 of CAPWAP Protocol Specification, RFC 5415." SYNTAX BITS { localBridging(0), dot3Tunnel(1), nativeTunnel(2) } CapwapBaseMacTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the MAC mode of operation supported by a WTP. The following enumerated values are supported: localMAC(0) - Local-MAC mode splitMAC(1) - Split-MAC mode both(2) - Both Local-MAC and Split-MAC Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE "Section 4.6.44 of CAPWAP Protocol Specification, RFC 5415." SYNTAX INTEGER { localMAC(0), splitMAC(1), both(2) } CapwapBaseChannelTypeTC::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the channel type for CAPWAP protocol. The following enumerated values are supported: data(1) - Data channel control(2) - Control channel" SYNTAX INTEGER { data(1), control(2) } Shi, et al. Informational [Page 17] RFC 5833 CAPWAP Protocol Base MIB May 2010 CapwapBaseAuthenMethodTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the authentication credential type for a WTP. The following enumerated values are supported: other(1) - Other method, for example, vendor specific clear(2) - Clear text and no authentication x509(3) - X.509 certificate authentication psk(4) - Pre-Shared secret authentication As a mandatory requirement, CAPWAP control channel authentication SHOULD use DTLS, either by certificate or PSK. For data channel authentication, DTLS is optional." SYNTAX INTEGER { other(1), clear(2), x509(3), psk(4) } -- Top-level components of this MIB module -- Notifications capwapBaseNotifications OBJECT IDENTIFIER ::= { capwapBaseMIB 0 } -- Tables, Scalars capwapBaseObjects OBJECT IDENTIFIER ::= { capwapBaseMIB 1 } -- Conformance capwapBaseConformance OBJECT IDENTIFIER ::= { capwapBaseMIB 2 } -- AC Objects Group capwapBaseAc OBJECT IDENTIFIER ::= { capwapBaseObjects 1 } capwapBaseWtpSessions OBJECT-TYPE SYNTAX Gauge32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the total number of WTPs that are connecting to the AC." REFERENCE "Section 4.6.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 1 } Shi, et al. Informational [Page 18] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseWtpSessionsLimit OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum number of WTP sessions configured on the AC. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.6.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 2 } capwapBaseStationSessions OBJECT-TYPE SYNTAX Gauge32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the total number of stations that are accessing the wireless service provided by the AC." REFERENCE "Section 4.6.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 3 } capwapBaseStationSessionsLimit OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum number of station sessions configured on the AC. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.6.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 4 } capwapBaseDataChannelDTLSPolicyOptions OBJECT-TYPE SYNTAX BITS { other(0), clear(1), dtls(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The AC communicates its policy on the use of DTLS for the CAPWAP data channel. The AC MAY support more than one option, represented by the bit field below: Shi, et al. Informational [Page 19] RFC 5833 CAPWAP Protocol Base MIB May 2010 other(0) - Other method, for example, vendor specific clear(1) - Clear text dtls(2) - DTLS" REFERENCE "Section 4.6.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 5 } capwapBaseControlChannelAuthenOptions OBJECT-TYPE SYNTAX BITS { x509(0), psk(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the authentication credential type supported by the AC for CAPWAP control channel. The AC MAY support more than one option, represented by the bit field below: x509(0) - X.509 certificate based psk(1) - Pre-Shared secret" REFERENCE "Section 4.6.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 6 } -- capwapBaseAcNameListTable table capwapBaseAcNameListTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseAcNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that configure the AC name list. Values of all read-create objects in this table are persistent at restart/reboot." REFERENCE "Section 4.6.5 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 9 } capwapBaseAcNameListEntry OBJECT-TYPE SYNTAX CapwapBaseAcNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that configures the AC name list." INDEX { capwapBaseAcNameListId } ::= { capwapBaseAcNameListTable 1 } Shi, et al. Informational [Page 20] RFC 5833 CAPWAP Protocol Base MIB May 2010 CapwapBaseAcNameListEntry ::= SEQUENCE { capwapBaseAcNameListId Unsigned32, capwapBaseAcNameListName LongUtf8String, capwapBaseAcNameListPriority Unsigned32, capwapBaseAcNameListRowStatus RowStatus } capwapBaseAcNameListId OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of an AC Name list." ::= { capwapBaseAcNameListEntry 1 } capwapBaseAcNameListName OBJECT-TYPE SYNTAX LongUtf8String (SIZE(1..512)) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the name of an AC, and it is expected to be an UTF-8 encoded string." REFERENCE "Section 4.6.5 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAcNameListEntry 2 } capwapBaseAcNameListPriority OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the priority order of the preferred AC. For instance, the value of one (1) is used to set the primary AC, the value of two (2) is used to set the secondary AC, etc." REFERENCE "Section 4.6.5 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAcNameListEntry 3 } capwapBaseAcNameListRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify, and/or delete a row in this table. The value of capwapBaseAcNameListName and capwapBaseAcNameListPriority can be changed when this object is in state 'active' or in 'notInService'. Shi, et al. Informational [Page 21] RFC 5833 CAPWAP Protocol Base MIB May 2010 The capwapBaseAcNameListRowStatus may be changed to 'active' if all the managed objects in the conceptual row with MAX-ACCESS read-create have been assigned valid values." ::= { capwapBaseAcNameListEntry 4 } -- End of capwapBaseAcNameListTable table -- capwapBaseMacAclTable table capwapBaseMacAclTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseMacAclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that configure station Access Control Lists (ACLs). The WTP will not provide service to the MAC addresses configured in this table. Values of all read-create objects in this table are persistent at AC restart/reboot." REFERENCE "Section 4.6.7 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseAc 10 } capwapBaseMacAclEntry OBJECT-TYPE SYNTAX CapwapBaseMacAclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that configures station Access Control Lists (ACLs)." INDEX { capwapBaseMacAclId } ::= { capwapBaseMacAclTable 1 } CapwapBaseMacAclEntry ::= SEQUENCE { capwapBaseMacAclId Unsigned32, capwapBaseMacAclStationId CapwapBaseStationIdTC, capwapBaseMacAclRowStatus RowStatus } capwapBaseMacAclId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of an ACL." ::= { capwapBaseMacAclEntry 1 } Shi, et al. Informational [Page 22] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseMacAclStationId OBJECT-TYPE SYNTAX CapwapBaseStationIdTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the MAC address of a station to which WTPs will no longer provides service." REFERENCE "Section 4.6.7 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseMacAclEntry 2 } capwapBaseMacAclRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify, and/or delete a row in this table. The value of capwapBaseMacAclStationId can be changed when this object is in state 'active' or in 'notInService'. The capwapBaseMacAclRowStatus may be changed to 'active' if all the managed objects in the conceptual row with MAX-ACCESS read-create have been assigned valid values." ::= { capwapBaseMacAclEntry 3 } -- End of capwapBaseMacAclTable table -- End of AC Objects Group -- WTP Objects Group capwapBaseWtps OBJECT IDENTIFIER ::= { capwapBaseObjects 2 } -- capwapBaseWtpProfileTable Table capwapBaseWtpProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that configure WTP profiles for WTPs to be managed before they connect to the AC. An operator could change a WTP's configuration by changing the values of parameters in the corresponding WTP profile, then the WTP could get the new configuration through the CAPWAP control channel. Shi, et al. Informational [Page 23] RFC 5833 CAPWAP Protocol Base MIB May 2010 Values of all read-create objects in this table are persistent at restart/reboot." ::= { capwapBaseWtps 1 } capwapBaseWtpProfileEntry OBJECT-TYPE SYNTAX CapwapBaseWtpProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that configures and displays a WTP profile." INDEX { capwapBaseWtpProfileId } ::= { capwapBaseWtpProfileTable 1 } CapwapBaseWtpProfileEntry ::= SEQUENCE { capwapBaseWtpProfileId CapwapBaseWtpProfileIdTC, capwapBaseWtpProfileName SnmpAdminString, capwapBaseWtpProfileWtpMacAddress CapwapBaseWtpIdTC, capwapBaseWtpProfileWtpModelNumber SnmpAdminString, capwapBaseWtpProfileWtpName LongUtf8String, capwapBaseWtpProfileWtpLocation LongUtf8String, capwapBaseWtpProfileWtpStaticIpEnable TruthValue, capwapBaseWtpProfileWtpStaticIpType InetAddressType, capwapBaseWtpProfileWtpStaticIpAddress InetAddress, capwapBaseWtpProfileWtpNetmask InetAddress, capwapBaseWtpProfileWtpGateway InetAddress, capwapBaseWtpProfileWtpFallbackEnable INTEGER, capwapBaseWtpProfileWtpEchoInterval Unsigned32, capwapBaseWtpProfileWtpIdleTimeout Unsigned32, capwapBaseWtpProfileWtpMaxDiscoveryInterval Unsigned32, capwapBaseWtpProfileWtpReportInterval Unsigned32, capwapBaseWtpProfileWtpStatisticsTimer Unsigned32, capwapBaseWtpProfileWtpEcnSupport INTEGER, capwapBaseWtpProfileRowStatus RowStatus } capwapBaseWtpProfileId OBJECT-TYPE SYNTAX CapwapBaseWtpProfileIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of a WTP profile." ::= { capwapBaseWtpProfileEntry 1 } capwapBaseWtpProfileName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION Shi, et al. Informational [Page 24] RFC 5833 CAPWAP Protocol Base MIB May 2010 "Represents the name of a WTP profile." ::= { capwapBaseWtpProfileEntry 2 } capwapBaseWtpProfileWtpMacAddress OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the Base MAC address of a WTP. A WTP profile MUST contain the Base MAC address of the WTP because the CAPWAP message received from the WTP contains its Base MAC address and the AC uses the Base MAC address to find the corresponding WTP profile. Section 4.6.40 of [RFC5415] omits indicating that the WTP's Base MAC address must be included in the WTP Board Data message element. This is a known errata item and should be fixed in any future revision of the RFC 5415." REFERENCE "Section 4.6.40 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 3 } capwapBaseWtpProfileWtpModelNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the model number of a WTP. A WTP profile MUST include the WTP's model number, which reflects the number of Physical Layer (PHY) radios on the WTP. In this way, the creation of a WTP profile triggers the AC to automatically create the same number of WTP Virtual Radio Interfaces corresponding to the WTP's PHY radios without manual intervention. With the ifIndexes of WTP Virtual Radio Interfaces, the operator could configure and manage the WTP's PHY radios through the wireless binding MIB modules." REFERENCE "Section 4.6.40 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 4 } capwapBaseWtpProfileWtpName OBJECT-TYPE SYNTAX LongUtf8String (SIZE(1..512)) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the name of the WTP." REFERENCE "Section 4.6.45 of CAPWAP Protocol Specification, RFC 5415." Shi, et al. Informational [Page 25] RFC 5833 CAPWAP Protocol Base MIB May 2010 ::= { capwapBaseWtpProfileEntry 5 } capwapBaseWtpProfileWtpLocation OBJECT-TYPE SYNTAX LongUtf8String (SIZE(1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the location of the WTP." REFERENCE "Section 4.6.30 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 6 } capwapBaseWtpProfileWtpStaticIpEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Represents whether the WTP SHOULD use a static IP address or not. A value of false disables the static IP address, while a value of true enables it." REFERENCE "Section 4.6.48 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 7 } capwapBaseWtpProfileWtpStaticIpType OBJECT-TYPE SYNTAX InetAddressType {ipv4(1)} MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the static IP address type used by the WTP. Only ipv4(1) is supported by the object. Although the CAPWAP protocol [RFC5415] supports both IPv4 and IPv6, note that the CAPWAP field modeled by this object does not support IPv6, so the object does not support ipv6(2)." REFERENCE "Section 4.6.48 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 8 } capwapBaseWtpProfileWtpStaticIpAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4)) MAX-ACCESS read-create STATUS current DESCRIPTION "When capwapBaseWtpProfileWtpStaticIpEnable is true, it represents the static IP address to be assigned to the WTP. The format of this IP address is determined by the corresponding instance of object Shi, et al. Informational [Page 26] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseWtpProfileWtpStaticIpType." REFERENCE "Section 4.6.48 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 9 } capwapBaseWtpProfileWtpNetmask OBJECT-TYPE SYNTAX InetAddress (SIZE(4)) MAX-ACCESS read-create STATUS current DESCRIPTION "When capwapBaseWtpProfileWtpStaticIpEnable is true, it represents the netmask to be assigned to the WTP. The format of this netmask is determined by the corresponding instance of object capwapBaseWtpProfileWtpStaticIpType." REFERENCE "Section 4.6.48 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 10 } capwapBaseWtpProfileWtpGateway OBJECT-TYPE SYNTAX InetAddress (SIZE(4)) MAX-ACCESS read-create STATUS current DESCRIPTION "When capwapBaseWtpProfileWtpStaticIpEnable is true, it represents the gateway to be assigned to the WTP. The format of this IP address is determined by the corresponding instance of object capwapBaseWtpProfileWtpStaticIpType." REFERENCE "Section 4.6.48 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 11 } capwapBaseWtpProfileWtpFallbackEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Represents whether to enable or disable automatic CAPWAP fallback in the event that a WTP detects its preferred AC and is not currently connected to it. The following enumerated values are supported: enabled(1) - The fallback mode is enabled disabled(2) - The fallback mode is disabled" REFERENCE Shi, et al. Informational [Page 27] RFC 5833 CAPWAP Protocol Base MIB May 2010 "Section 4.6.42 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { enabled } ::= { capwapBaseWtpProfileEntry 12 } capwapBaseWtpProfileWtpEchoInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the minimum time, in seconds, between sending Echo Request messages to the AC that the WTP has joined." REFERENCE "Section 4.7.7 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 30 } ::= { capwapBaseWtpProfileEntry 13 } capwapBaseWtpProfileWtpIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the idle timeout value that the WTP SHOULD enforce for its active stations." REFERENCE "Section 4.7.8 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 300 } ::= { capwapBaseWtpProfileEntry 14 } capwapBaseWtpProfileWtpMaxDiscoveryInterval OBJECT-TYPE SYNTAX Unsigned32 (2..180) UNITS "second" MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the maximum time allowed between sending Discovery Request messages, in seconds." REFERENCE "Section 4.7.10 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 20 } ::= { capwapBaseWtpProfileEntry 15 } capwapBaseWtpProfileWtpReportInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-create STATUS current Shi, et al. Informational [Page 28] RFC 5833 CAPWAP Protocol Base MIB May 2010 DESCRIPTION "Represents the interval for WTP to send the Decryption Error report." REFERENCE "Section 4.7.11 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 120 } ::= { capwapBaseWtpProfileEntry 16 } capwapBaseWtpProfileWtpStatisticsTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the interval the WTP uses between the WTP Event Requests it transmits to the AC to communicate its statistics, in seconds." REFERENCE "Section 4.7.14 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 120 } ::= { capwapBaseWtpProfileEntry 17 } capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE SYNTAX INTEGER { limited(0), fullAndLimited(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the support for the Explicit Congestion Notification (ECN) bits, as defined in [RFC3168]. The following enumerated values are supported: limited(0) - Limited ECN support fullAndLimited(1) - Full and limited ECN support Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE "Section 4.6.25 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpProfileEntry 18 } capwapBaseWtpProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify, and/or delete a row Shi, et al. Informational [Page 29] RFC 5833 CAPWAP Protocol Base MIB May 2010 in this table. The value of capwapBaseWtpProfileName, capwapBaseWtpProfileWtpName and capwapBaseWtpProfileWtpLocation can be changed when this object is in state 'active' or in 'notInService'. The other objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row: a. change the row status to 'notInService' b. change the values of the row c. change the row status to 'active' The capwapBaseWtpProfileRowStatus may be changed to 'active' if the managed objects capwapBaseWtpProfileName, capwapBaseWtpProfileWtpMacAddress, capwapBaseWtpProfileWtpModelNumber, capwapBaseWtpProfileWtpName, and capwapBaseWtpProfileWtpLocation in the conceptual row have been assigned valid values. Deleting a WTP profile in use will disconnect the WTP from the AC. So the network management system SHOULD ask the operator to confirm such an operation. When a WTP profile entry is removed from the table, the corresponding WTP Virtual Radio Interfaces are also removed from the capwapBaseWirelessBindingTable and ifTable [RFC2863]. Also, the related object instances SHOULD be removed from the wireless binding MIB modules such as the IEEE 802.11 MIB module [IEEE.802-11.2007]." ::= { capwapBaseWtpProfileEntry 19 } -- End of capwapBaseWtpProfileTable table -- capwapBaseWtpStateTable table capwapBaseWtpStateTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that indicate the AC's CAPWAP FSM state for each WTP, and helps the operator to query a WTP's current configuration." ::= { capwapBaseWtps 2 } capwapBaseWtpStateEntry OBJECT-TYPE Shi, et al. Informational [Page 30] RFC 5833 CAPWAP Protocol Base MIB May 2010 SYNTAX CapwapBaseWtpStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that displays the AC's CAPWAP FSM state for each WTP. Also, the operator could query the current configuration of a WTP by using the identifier of the corresponding WTP profile." INDEX { capwapBaseWtpStateWtpId } ::= { capwapBaseWtpStateTable 1 } CapwapBaseWtpStateEntry ::= SEQUENCE { capwapBaseWtpStateWtpId CapwapBaseWtpIdTC, capwapBaseWtpStateWtpIpAddressType InetAddressType, capwapBaseWtpStateWtpIpAddress InetAddress, capwapBaseWtpStateWtpLocalIpAddressType InetAddressType, capwapBaseWtpStateWtpLocalIpAddress InetAddress, capwapBaseWtpStateWtpBaseMacAddress PhysAddress, capwapBaseWtpState INTEGER, capwapBaseWtpStateWtpUpTime TimeTicks, capwapBaseWtpStateWtpCurrWtpProfileId CapwapBaseWtpProfileIdTC } capwapBaseWtpStateWtpId OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of a WTP." ::= { capwapBaseWtpStateEntry 1 } capwapBaseWtpStateWtpIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the IP address type of a WTP. Only ipv4(1) and ipv6(2) are supported by the object." ::= { capwapBaseWtpStateEntry 2 } capwapBaseWtpStateWtpIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the IP address of a WTP that corresponds to the IP address in the IP packet header. Shi, et al. Informational [Page 31] RFC 5833 CAPWAP Protocol Base MIB May 2010 The format of this IP address is determined by the corresponding instance of object capwapBaseWtpStateWtpIpAddressType." REFERENCE "Section 4 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpStateEntry 3 } capwapBaseWtpStateWtpLocalIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the local IP address type of a WTP. Only ipv4(1) and ipv6(2) are supported by the object." ::= { capwapBaseWtpStateEntry 4 } capwapBaseWtpStateWtpLocalIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the local IP address of a WTP and models the CAPWAP Local IPv4 Address or CAPWAP Local IPv6 Address fields [RFC5415]. If a Network Address Translation (NAT) device is present between WTP and AC, the value of capwapBaseWtpStateWtpLocalIpAddress will be different from the value of capwapBaseWtpStateWtpIpAddress. The format of this IP address is determined by the corresponding instance of object capwapBaseWtpStateWtpLocalIpAddressType." REFERENCE "Sections 4.6.11 and 4.6.12 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpStateEntry 5 } capwapBaseWtpStateWtpBaseMacAddress OBJECT-TYPE SYNTAX PhysAddress (SIZE(6|8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the WTP's Base MAC Address, which MAY be assigned to the primary Ethernet interface. The instance of the object corresponds to the Base MAC Address sub-element in the CAPWAP protocol [RFC5415]." REFERENCE "Section 4.6.40 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpStateEntry 6 } Shi, et al. Informational [Page 32] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseWtpState OBJECT-TYPE SYNTAX INTEGER { dtls(1), join(2), image(3), configure(4), dataCheck(5), run(6), reset(7), dtlsTeardown(8), unknown(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the various possibilities of the AC's CAPWAP FSM state for each WTP. The following enumerated values are supported: dtls(1) - DTLS negotiation states, which include DTLS setup, authorize, DTLS connect join(2) - The WTP is joining with the AC image(3) - The WTP is downloading software configure(4) - The WTP is getting configuration from the AC dataCheck(5) - The AC is waiting for the Data Channel Keep Alive Packet run(6) - The WTP enters the running state reset(7) - The AC transmits a reset request message to the WTP dtlsTeardown(8) - DTLS session is torn down unknown(9) - Operator already prepared configuration for the WTP, while the WTP has not contacted the AC until now" REFERENCE "Section 2.3.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpStateEntry 7 } capwapBaseWtpStateWtpUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the time (in hundredths of a second) since the WTP has been in the running state (corresponding to the value run(6) of capwapBaseWtpState)." ::= { capwapBaseWtpStateEntry 8 } capwapBaseWtpStateWtpCurrWtpProfileId OBJECT-TYPE Shi, et al. Informational [Page 33] RFC 5833 CAPWAP Protocol Base MIB May 2010 SYNTAX CapwapBaseWtpProfileIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the current identifier of a WTP profile. The operator could query a WTP's current configuration with the identifier of a WTP profile." ::= { capwapBaseWtpStateEntry 9 } -- End of capwapBaseWtpStateTable Table -- capwapBaseWtpTable Table capwapBaseWtpTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display properties of the WTPs in running state." ::= { capwapBaseWtps 3 } capwapBaseWtpEntry OBJECT-TYPE SYNTAX CapwapBaseWtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that displays properties of the WTPs in running state." INDEX { capwapBaseWtpCurrId } ::= { capwapBaseWtpTable 1 } CapwapBaseWtpEntry ::= SEQUENCE { capwapBaseWtpCurrId CapwapBaseWtpIdTC, capwapBaseWtpPhyIndex PhysicalIndex, capwapBaseWtpBaseMacAddress PhysAddress, capwapBaseWtpTunnelModeOptions CapwapBaseTunnelModeTC, capwapBaseWtpMacTypeOptions CapwapBaseMacTypeTC, capwapBaseWtpDiscoveryType INTEGER, capwapBaseWtpRadiosInUseNum Gauge32, capwapBaseWtpRadioNumLimit Unsigned32, capwapBaseWtpRetransmitCount Counter32 } capwapBaseWtpCurrId OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS not-accessible Shi, et al. Informational [Page 34] RFC 5833 CAPWAP Protocol Base MIB May 2010 STATUS current DESCRIPTION "Represents the unique identifier of a WTP in running state." ::= { capwapBaseWtpEntry 1 } capwapBaseWtpPhyIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the unique physical index of a physical entity in the ENTITY-MIB module [RFC4133]. Information about a specific WTP such as its software version could be accessed through this index." ::= { capwapBaseWtpEntry 2 } capwapBaseWtpBaseMacAddress OBJECT-TYPE SYNTAX PhysAddress (SIZE(6|8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the WTP's Base MAC Address, which MAY be assigned to the primary Ethernet interface. The instance of the object corresponds to the Base MAC Address sub-element in the CAPWAP protocol [RFC5415]." REFERENCE "Section 4.6.40 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEntry 3 } capwapBaseWtpTunnelModeOptions OBJECT-TYPE SYNTAX CapwapBaseTunnelModeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the tunneling modes of operation supported by the WTP." REFERENCE "Section 4.6.43 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEntry 4 } capwapBaseWtpMacTypeOptions OBJECT-TYPE SYNTAX CapwapBaseMacTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the MAC mode of operation supported by the WTP." REFERENCE "Section 4.6.44 of CAPWAP Protocol Specification, RFC 5415." Shi, et al. Informational [Page 35] RFC 5833 CAPWAP Protocol Base MIB May 2010 ::= { capwapBaseWtpEntry 5 } capwapBaseWtpDiscoveryType OBJECT-TYPE SYNTAX INTEGER { unknown(0), staticConfig(1), dhcp(2), dns(3), acRef(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents how the WTP discovers the AC. The following enumerated values are supported: unknown(0) - Unknown staticConfig(1) - Static configuration dhcp(2) - DHCP dns(3) - DNS acRef(4) - AC referral Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE "Section 4.6.21 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEntry 6 } capwapBaseWtpRadiosInUseNum OBJECT-TYPE SYNTAX Gauge32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of radios in use on the WTP." REFERENCE "Section 4.6.41 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEntry 7 } capwapBaseWtpRadioNumLimit OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the maximum radio number supported by the WTP." REFERENCE "Section 4.6.41 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEntry 8 } capwapBaseWtpRetransmitCount OBJECT-TYPE Shi, et al. Informational [Page 36] RFC 5833 CAPWAP Protocol Base MIB May 2010 SYNTAX Counter32 UNITS "retransmissions" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of retransmissions for a given CAPWAP packet." REFERENCE "Section 4.8.8 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEntry 9 } -- End of capwapBaseWtpTable table -- capwapBaseWirelessBindingTable Table capwapBaseWirelessBindingTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWirelessBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display the mappings between WTP Virtual Radio Interfaces and PHY radios, and the wireless binding type for each PHY radio. As capwapBaseWirelessBindingTable stores the mappings between PHY radios (Radio IDs) and the ifIndexes of WTP Virtual Radio Interfaces, the operator can get the ifIndex information by querying this table. Such a query operation SHOULD run from radio ID 1 to radio ID 31 according to [RFC5415], and stop when an invalid ifIndex value (0) is returned. Values of all objects in this table are persistent at restart/reboot." ::= { capwapBaseWtps 4 } capwapBaseWirelessBindingEntry OBJECT-TYPE SYNTAX CapwapBaseWirelessBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that displays the mapping between a specific WTP Virtual Radio Interface and a PHY radio, and the wireless binding type for the PHY radio." INDEX { capwapBaseWtpProfileId, capwapBaseWirelessBindingRadioId } ::= { capwapBaseWirelessBindingTable 1 } Shi, et al. Informational [Page 37] RFC 5833 CAPWAP Protocol Base MIB May 2010 CapwapBaseWirelessBindingEntry ::= SEQUENCE { capwapBaseWirelessBindingRadioId CapwapBaseRadioIdTC, capwapBaseWirelessBindingVirtualRadioIfIndex InterfaceIndex, capwapBaseWirelessBindingType INTEGER } capwapBaseWirelessBindingRadioId OBJECT-TYPE SYNTAX CapwapBaseRadioIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the identifier of a PHY radio on a WTP, which is required to be unique on a WTP. For example, WTP A and WTP B use a same value of capwapBaseWirelessBindingRadioId for their first radio." REFERENCE "Section 4.3 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWirelessBindingEntry 1 } capwapBaseWirelessBindingVirtualRadioIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the index value that uniquely identifies a WLAN Virtual Radio Interface. The interface identified by a particular value of this index is the same interface as identified by the same value of the ifIndex. Before WTPs contact the AC to get configuration, the operator configures WTP profiles for them. The creation of a WTP profile triggers the system to automatically create a specific number of WTP Virtual Radio Interfaces and add a new row object in the capwapBaseWirelessBindingTable without manual intervention. As most MIB modules use the ifIndex to identify an interface for configuration and statistical data (for example, the IEEE 802.11 MIB module [IEEE.802-11.2007]), it will be easy to reuse other wireless binding MIB modules through the WTP Virtual Radio Interface in the Centralized WLAN Architecture." ::= { capwapBaseWirelessBindingEntry 2 } capwapBaseWirelessBindingType OBJECT-TYPE SYNTAX INTEGER { dot11(1), epc(3) } MAX-ACCESS read-only Shi, et al. Informational [Page 38] RFC 5833 CAPWAP Protocol Base MIB May 2010 STATUS current DESCRIPTION "Represents the wireless binding type for the radio. The following enumerated values are supported: dot11(1) - IEEE 802.11 epc(3) - EPCGlobal" REFERENCE "Section 4.3 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWirelessBindingEntry 3 } -- End of capwapBaseWirelessBindingTable Table -- capwapBaseStationTable Table capwapBaseStationTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseStationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display stations that are accessing the wireless service provided by the AC." REFERENCE "Section 4.6.8 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtps 5 } capwapBaseStationEntry OBJECT-TYPE SYNTAX CapwapBaseStationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that displays a station that is associated with the specific radio on the WTP. Note that in some cases such as roaming that a station may simultaneously associate with two WTPs for some (short) time. The MIB implementation MUST ensure there is only one valid and meaningful entry for a specific station." INDEX { capwapBaseStationId } ::= { capwapBaseStationTable 1 } CapwapBaseStationEntry ::= SEQUENCE { capwapBaseStationId CapwapBaseStationIdTC, capwapBaseStationWtpId CapwapBaseWtpIdTC, capwapBaseStationWtpRadioId CapwapBaseRadioIdTC, capwapBaseStationAddedTime DateAndTime, capwapBaseStationVlanName SnmpAdminString } Shi, et al. Informational [Page 39] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseStationId OBJECT-TYPE SYNTAX CapwapBaseStationIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of the station." REFERENCE "Section 4.6.8 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseStationEntry 1 } capwapBaseStationWtpId OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the unique identifier of a WTP in running state." ::= { capwapBaseStationEntry 2 } capwapBaseStationWtpRadioId OBJECT-TYPE SYNTAX CapwapBaseRadioIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the identifier of a PHY radio on a WTP, which is required to be unique on a WTP. For example, WTP A and WTP B use a same value of capwapBaseStationWtpRadioId for their first radio." REFERENCE "Section 4.3 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseStationEntry 3 } capwapBaseStationAddedTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the time when the station is added." REFERENCE "Section 4.6.8 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseStationEntry 4 } capwapBaseStationVlanName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents VLAN name to which the station is associated." REFERENCE Shi, et al. Informational [Page 40] RFC 5833 CAPWAP Protocol Base MIB May 2010 "Section 4.6.8 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseStationEntry 5 } -- End of capwapBaseStationTable Table -- capwapBaseWtpEventsStatsTable capwapBaseWtpEventsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display the WTPs' events statistics." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtps 6 } capwapBaseWtpEventsStatsEntry OBJECT-TYPE SYNTAX CapwapBaseWtpEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that displays the events statistics of a WTP." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." INDEX { capwapBaseWtpCurrId } ::= { capwapBaseWtpEventsStatsTable 1 } CapwapBaseWtpEventsStatsEntry ::= SEQUENCE { capwapBaseWtpEventsStatsRebootCount Counter32, capwapBaseWtpEventsStatsInitCount Counter32, capwapBaseWtpEventsStatsLinkFailureCount Counter32, capwapBaseWtpEventsStatsSwFailureCount Counter32, capwapBaseWtpEventsStatsHwFailureCount Counter32, capwapBaseWtpEventsStatsOtherFailureCount Counter32, capwapBaseWtpEventsStatsUnknownFailureCount Counter32, capwapBaseWtpEventsStatsLastFailureType INTEGER } capwapBaseWtpEventsStatsRebootCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of reboots that have occurred due to a WTP crash. Shi, et al. Informational [Page 41] RFC 5833 CAPWAP Protocol Base MIB May 2010 Note that the CAPWAP field [RFC5415] modeled by this counter takes the value 65535 to indicate that the information is not available on the WTP. This MIB object does not follow this behavior, which would not be standard in SMIv2. If the WTP does not have the information, the agent will not instantiate the object." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 1 } capwapBaseWtpEventsStatsInitCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of reboots that have occurred at the request of a CAPWAP protocol message, such as a change in configuration that requires a reboot or an explicit CAPWAP protocol reset request. Note that the CAPWAP field [RFC5415] modeled by this counter takes the value 65535 to indicate that the information is not available on the WTP. This MIB object does not follow this behavior, which would not be standard in SMIv2. If the WTP does not have the information, the agent will not instantiate the object." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 2 } capwapBaseWtpEventsStatsLinkFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to link failures." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 3 } capwapBaseWtpEventsStatsSwFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to software-related reasons." Shi, et al. Informational [Page 42] RFC 5833 CAPWAP Protocol Base MIB May 2010 REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 4 } capwapBaseWtpEventsStatsHwFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to hardware-related reasons." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 5 } capwapBaseWtpEventsStatsOtherFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to known reasons, other than the AC-initiated, link, software or hardware failures." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 6 } capwapBaseWtpEventsStatsUnknownFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed for unknown reasons." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 7 } capwapBaseWtpEventsStatsLastFailureType OBJECT-TYPE SYNTAX INTEGER { unsupported(0), acInit(1), linkFailure(2), swFailure(3), hwFailure(4), otherFailure(5), unknown(255) Shi, et al. Informational [Page 43] RFC 5833 CAPWAP Protocol Base MIB May 2010 } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the failure type of the most recent WTP failure. The following enumerated values are supported: unsupported(0) - Not supported acInit(1) - The AC initiated linkFailure(2) - Link failure swFailure(3) - Software failure hwFailure(4) - Hardware failure otherFailure(5) - Other failure unknown(255) - Unknown (e.g., WTP doesn't keep track of info) Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE "Section 4.6.47 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpEventsStatsEntry 8 } -- End of capwapBaseWtpEventsStatsTable table -- capwapBaseRadioEventsStatsTable table capwapBaseRadioEventsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseRadioEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display statistics on the radios' behaviors and reasons why the WTP radio has been reset. To get the events statistics of all radios on a specific WTP (identified by the capwapBaseWtpCurrId), a query operation SHOULD run from radio ID 1 to radio ID 31 until there is no data returned. The radio ID here corresponds to the object capwapBaseRadioEventsWtpRadioId. If the previous MIB operations such as query on the capwapBaseWirelessBindingTable know the exact value of each radio ID, the query operation on the capwapBaseRadioEventsStatsTable could use that value of Radio IDs." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtps 7 } capwapBaseRadioEventsStatsEntry OBJECT-TYPE SYNTAX CapwapBaseRadioEventsStatsEntry Shi, et al. Informational [Page 44] RFC 5833 CAPWAP Protocol Base MIB May 2010 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that displays the statistical data of events that happened on a specific radio of a WTP." INDEX { capwapBaseWtpCurrId, capwapBaseRadioEventsWtpRadioId } ::= { capwapBaseRadioEventsStatsTable 1 } CapwapBaseRadioEventsStatsEntry ::= SEQUENCE { capwapBaseRadioEventsWtpRadioId CapwapBaseRadioIdTC, capwapBaseRadioEventsStatsResetCount Counter32, capwapBaseRadioEventsStatsSwFailureCount Counter32, capwapBaseRadioEventsStatsHwFailureCount Counter32, capwapBaseRadioEventsStatsOtherFailureCount Counter32, capwapBaseRadioEventsStatsUnknownFailureCount Counter32, capwapBaseRadioEventsStatsConfigUpdateCount Counter32, capwapBaseRadioEventsStatsChannelChangeCount Counter32, capwapBaseRadioEventsStatsBandChangeCount Counter32, capwapBaseRadioEventsStatsCurrNoiseFloor Integer32, capwapBaseRadioEventsStatsDecryptErrorCount Counter32, capwapBaseRadioEventsStatsLastFailureType INTEGER } capwapBaseRadioEventsWtpRadioId OBJECT-TYPE SYNTAX CapwapBaseRadioIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the identifier of a PHY radio on a WTP, which is required to be unique on a WTP. For example, WTP A and WTP B use the same value of capwapBaseRadioEventsWtpRadioId for their first radio." REFERENCE "Section 4.3 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 1 } capwapBaseRadioEventsStatsResetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has been reset." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 2 } capwapBaseRadioEventsStatsSwFailureCount OBJECT-TYPE Shi, et al. Informational [Page 45] RFC 5833 CAPWAP Protocol Base MIB May 2010 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed due to software-related reasons." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 3 } capwapBaseRadioEventsStatsHwFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed due to hardware-related reasons." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 4 } capwapBaseRadioEventsStatsOtherFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed due to known reasons, other than software or hardware failure." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 5 } capwapBaseRadioEventsStatsUnknownFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed for unknown reasons." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 6 } capwapBaseRadioEventsStatsConfigUpdateCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Shi, et al. Informational [Page 46] RFC 5833 CAPWAP Protocol Base MIB May 2010 "Represents the number of times that the radio configuration has been updated." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 7 } capwapBaseRadioEventsStatsChannelChangeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio channel has been changed." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 8 } capwapBaseRadioEventsStatsBandChangeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has changed frequency bands." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 9 } capwapBaseRadioEventsStatsCurrNoiseFloor OBJECT-TYPE SYNTAX Integer32 UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the noise floor of the radio receiver in units of dBm." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 10 } capwapBaseRadioEventsStatsDecryptErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of decryption errors that have occurred on the WTP. Note that this field is only valid in cases where the WTP provides encryption/decryption services." Shi, et al. Informational [Page 47] RFC 5833 CAPWAP Protocol Base MIB May 2010 REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 11 } capwapBaseRadioEventsStatsLastFailureType OBJECT-TYPE SYNTAX INTEGER { unsupported(0), swFailure(1), hwFailure(2), otherFailure(3), unknown(255) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the failure type of the most recent radio failure. The following enumerated values are supported: unsupported(0) - Not supported swFailure(1) - Software failure hwFailure(2) - Hardware failure otherFailure(3) - Other failure unknown(255) - Unknown Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE "Section 4.6.46 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseRadioEventsStatsEntry 12 } -- End of capwapBaseRadioEventsStatsTable table -- End of WTP Objects Group -- CAPWAP Base Parameters Group capwapBaseParameters OBJECT IDENTIFIER ::= { capwapBaseObjects 3 } capwapBaseAcMaxRetransmit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum number of retransmissions for a given CAPWAP packet before the link layer considers the peer dead. The value of the object is persistent at restart/reboot." REFERENCE Shi, et al. Informational [Page 48] RFC 5833 CAPWAP Protocol Base MIB May 2010 "Section 4.8.7 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 5 } ::= { capwapBaseParameters 1 } capwapBaseAcChangeStatePendingTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum time, in seconds, the AC will wait for the Change State Event Request from the WTP after having transmitted a successful Configuration Status Response message. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.1 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 25 } ::= { capwapBaseParameters 2 } capwapBaseAcDataCheckTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents The number of seconds the AC will wait for the Data Channel Keep Alive, which is required by the CAPWAP state machine's Data Check state. The AC resets the state machine if this timer expires prior to transitioning to the next state. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.4 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 30 } ::= { capwapBaseParameters 3 } capwapBaseAcDTLSSessionDeleteTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, the AC MUST wait for DTLS session deletion. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.6 of CAPWAP Protocol Specification, RFC 5415." Shi, et al. Informational [Page 49] RFC 5833 CAPWAP Protocol Base MIB May 2010 DEFVAL { 5 } ::= { capwapBaseParameters 4 } capwapBaseAcEchoInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, between sending Echo Request messages to the AC with which the WTP has joined. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.7 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 30 } ::= { capwapBaseParameters 5 } capwapBaseAcRetransmitInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, in which a non-acknowledged CAPWAP packet will be retransmitted. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.12 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 3 } ::= { capwapBaseParameters 6 } capwapBaseAcSilentInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, during which the AC SHOULD ignore all CAPWAP and DTLS packets received from the WTP that is in the Sulking state. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.13 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 30 } ::= { capwapBaseParameters 7 } capwapBaseAcWaitDTLSTimer OBJECT-TYPE SYNTAX Unsigned32 (30..4294967295) Shi, et al. Informational [Page 50] RFC 5833 CAPWAP Protocol Base MIB May 2010 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum time, in seconds, the AC MUST wait without having received a DTLS Handshake message from an AC. This timer MUST be greater than 30 seconds. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.15 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 60 } ::= { capwapBaseParameters 8 } capwapBaseAcWaitJoinTimer OBJECT-TYPE SYNTAX Unsigned32 (20..4294967295) UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum time, in seconds, the AC will wait after the DTLS session has been established until it receives the Join Request from the WTP. This timer MUST be greater than 20 seconds. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.16 of CAPWAP Protocol Specification, RFC 5415." DEFVAL { 60 } ::= { capwapBaseParameters 9 } capwapBaseAcEcnSupport OBJECT-TYPE SYNTAX INTEGER { limited(0), fullAndLimited(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the support for the Explicit Congestion Notification (ECN) bits, as defined in [RFC3168]. The value of the object is persistent at restart/reboot. The following enumerated values are supported: limited(0) - Limited ECN support fullAndLimited(1) - Full and limited ECN support Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE "Section 4.6.25 of CAPWAP Protocol Specification, RFC 5415." Shi, et al. Informational [Page 51] RFC 5833 CAPWAP Protocol Base MIB May 2010 ::= { capwapBaseParameters 10 } -- End of CAPWAP Base Parameters Group -- CAPWAP Statistics Group capwapBaseStats OBJECT IDENTIFIER ::= { capwapBaseObjects 4 } capwapBaseFailedDTLSAuthFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of failed DTLS session establishment attempts due to authentication failures." REFERENCE "Section 4.8.3 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseStats 1 } capwapBaseFailedDTLSSessionCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of failed DTLS session establishment attempts." REFERENCE "Section 4.8.4 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseStats 2 } -- Notifications capwapBaseChannelUp NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfChannelType, capwapBaseNtfAuthenMethod } STATUS current DESCRIPTION "This notification is sent by the AC when a CAPWAP channel is established. The notification is separated for data or control channel." ::= { capwapBaseNotifications 1 } capwapBaseChannelDown NOTIFICATION-TYPE Shi, et al. Informational [Page 52] RFC 5833 CAPWAP Protocol Base MIB May 2010 OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfChannelType, capwapBaseNtfChannelDownReason } STATUS current DESCRIPTION "This notification is sent by the AC when a CAPWAP channel is down. The notification is separated for data or control channel." ::= { capwapBaseNotifications 2 } capwapBaseDecryptErrorReport NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfRadioId, capwapBaseNtfStationIdList } STATUS current DESCRIPTION "This notification is generated when a WTP has had a decryption error since the last report." REFERENCE "Section 4.6.17 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifications 3 } capwapBaseJoinFailure NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfJoinFailureReason } STATUS current DESCRIPTION "This notification is generated when a WTP fails to join." REFERENCE "Section 4.6.35 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifications 4 } capwapBaseImageUpgradeFailure NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfImageFailureReason } STATUS current DESCRIPTION "This notification is generated when a WTP fails to update the firmware image." REFERENCE Shi, et al. Informational [Page 53] RFC 5833 CAPWAP Protocol Base MIB May 2010 "Section 4.6.35 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifications 5 } capwapBaseConfigMsgError NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfConfigMsgErrorType, capwapBaseNtfMsgErrorElements } STATUS current DESCRIPTION "This notification is generated when a WTP receives message elements in the configuration management messages that it is unable to apply locally." REFERENCE "Section 4.6.35 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifications 6 } capwapBaseRadioOperableStatus NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfRadioId, capwapBaseNtfRadioOperStatusFlag, capwapBaseNtfRadioStatusCause } STATUS current DESCRIPTION "The notification is generated when a radio's operational state has changed." REFERENCE "Section 4.6.34 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifications 7 } capwapBaseAuthenFailure NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfChannelType, capwapBaseNtfAuthenMethod, capwapBaseNtfAuthenFailureReason } STATUS current DESCRIPTION "This is notification of an authentication failure event and provides the reason for it." ::= { capwapBaseNotifications 8 } -- Objects used only in notifications Shi, et al. Informational [Page 54] RFC 5833 CAPWAP Protocol Base MIB May 2010 -- Notification Objects capwapBaseNotifyVarObjects OBJECT IDENTIFIER ::= { capwapBaseObjects 5 } capwapBaseNtfWtpId OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the unique identifier of a WTP." ::= { capwapBaseNotifyVarObjects 1 } capwapBaseNtfRadioId OBJECT-TYPE SYNTAX CapwapBaseRadioIdTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the identifier of a PHY radio on a WTP, which is only required to be unique on a WTP. For example, WTP A and WTP B can use the same value of capwapBaseNtfRadioId for their first radio." REFERENCE "Section 4.3 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 2 } capwapBaseNtfChannelType OBJECT-TYPE SYNTAX CapwapBaseChannelTypeTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the channel type for the CAPWAP protocol." ::= { capwapBaseNotifyVarObjects 3 } capwapBaseNtfAuthenMethod OBJECT-TYPE SYNTAX CapwapBaseAuthenMethodTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the authentication method for the CAPWAP Channel." ::= { capwapBaseNotifyVarObjects 4 } capwapBaseNtfChannelDownReason OBJECT-TYPE SYNTAX INTEGER { timeout(1), rekeyFailure(2), acRebootWtp(3), dtlsError(4), maxRetransmit(5) Shi, et al. Informational [Page 55] RFC 5833 CAPWAP Protocol Base MIB May 2010 } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason the channel is down. The following enumerated values are supported: timeout(1) - The keepalive timed out rekeyFailure(2) - Rekey process failed; channel will be broken acRebootWtp(3) - The AC rebooted the WTP dtlsError(4) - DTLS notifications: DTLSAborted, DTLSReassemblyFailure, DTLSPeerDisconnect, or frequent DTLSDecapFailure maxRetransmit(5) - The underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable" ::= { capwapBaseNotifyVarObjects 5 } capwapBaseNtfStationIdList OBJECT-TYPE SYNTAX LongUtf8String (SIZE (6..1024)) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents a list of station MAC addresses separated by semicolons." REFERENCE "Section 4.6.17 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 6 } capwapBaseNtfAuthenFailureReason OBJECT-TYPE SYNTAX INTEGER { keyMismatch(1), invalidCert(2), reassemblyFailure(3), decapFailure(4), encapFailure(5), timeout(6), unknown(8) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason for WTP authorization failure. The following enumerated values are supported: keyMismatch(1) - WTP's and AC's keys did not match invalidCert(2) - Certification is not valid reassemblyFailure(3) - Fragment reassembly failure decapFailure(4) - Decapsulation error Shi, et al. Informational [Page 56] RFC 5833 CAPWAP Protocol Base MIB May 2010 encapFailure(5) - Encapsulation error timeout(6) - WaitDTLS timer timeout unknown(8) - Unknown reason" REFERENCE "Section 2.3.1 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 7 } capwapBaseNtfRadioOperStatusFlag OBJECT-TYPE SYNTAX INTEGER { operable(0), inoperable(1) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the operation status of a radio. The following enumerated values are supported: operable(0) - The radio is operable inoperable(1) - The radio is inoperable, and the capwapBaseNtfRadioStatusCause object gives the reason in detail Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE "Section 4.6.34 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 8 } capwapBaseNtfRadioStatusCause OBJECT-TYPE SYNTAX INTEGER { normal(0), hwError(1), swError(2), adminSet(3) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason why the radio is out of service. The following enumerated values are supported: normal(0) - Normal status hwError(1) - Radio failure swError(2) - Software failure adminSet(3) - Administratively set Note that the CAPWAP field [RFC5415] modeled by this object takes zero as starting value; this MIB object follows that rule." REFERENCE Shi, et al. Informational [Page 57] RFC 5833 CAPWAP Protocol Base MIB May 2010 "Section 4.6.34 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 9 } capwapBaseNtfJoinFailureReason OBJECT-TYPE SYNTAX INTEGER { unspecified(1), resDepletion(2), unknownSource(3), incorrectData(4), sessionIdInUse(5), unsupportedHw(6), unsupportedBinding(7) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason of join failure. The following enumerated values are supported: unspecified(1) - Unspecified failure resDepletion(2) - Resource depletion unknownSource(3) - Unknown source incorrectData(4) - Incorrect data sessionIdInUse(5) - Session ID already in use unsupportedHw(6) - WTP hardware not supported unsupportedBinding(7) - Binding not supported" REFERENCE "Section 4.6.35 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 10 } capwapBaseNtfImageFailureReason OBJECT-TYPE SYNTAX INTEGER { invalidChecksum(1), invalidLength(2), other(3), inStorage(4) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason of image failure. The following enumerated values are supported: invalidChecksum(1) - Invalid checksum invalidLength(2) - Invalid data length other(3) - Other error inStorage(4) - Image already present" REFERENCE "Section 4.6.35 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 11 } Shi, et al. Informational [Page 58] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseNtfConfigMsgErrorType OBJECT-TYPE SYNTAX INTEGER { unknownElement(1), unsupportedElement(2), unknownValue(3), unsupportedValue(4) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the type of configuration message error. The following enumerated values are supported: unknownElement(1) - Unknown message element unsupportedElement(2) - Unsupported message element unknownValue(3) - Unknown message element value unsupportedValue(4) - Unsupported message element value" REFERENCE "Section 4.6.36 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 12 } capwapBaseNtfMsgErrorElements OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the message elements sent by the AC in the Configuration Status Response message that caused the error." REFERENCE "Section 4.6.36 of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseNotifyVarObjects 13 } -- Notification Control capwapBaseNotifyControlObjects OBJECT IDENTIFIER ::= { capwapBaseObjects 6 } capwapBaseChannelUpDownNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the Channel Up / Channel Down notification should be generated. A value of true(1) means that the notification is enabled. A value of false(2) means that the notification is disabled. The value of the object is persistent at restart/reboot." DEFVAL { false } ::= { capwapBaseNotifyControlObjects 1 } Shi, et al. Informational [Page 59] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseDecryptErrorNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the decryption error notification should be generated. A value of true(1) means that the notification is enabled. A value of false(2) means that the notification is disabled. The value of the object is persistent at restart/reboot." DEFVAL { true } ::= { capwapBaseNotifyControlObjects 2 } capwapBaseJoinFailureNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the notification of a WTP join failure should be generated. A value of true(1) means that the notification is enabled. A value of false(2) means that the notification is disabled. The value of the object is persistent at restart/reboot." DEFVAL { true } ::= { capwapBaseNotifyControlObjects 3 } capwapBaseImageUpgradeFailureNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the notification of a WTP image upgrade failure should be generated. A value of true(1) means that the notification is enabled. A value of false(2) means that the notification is disabled. The value of the object is persistent at restart/reboot." DEFVAL { true } ::= { capwapBaseNotifyControlObjects 4 } capwapBaseConfigMsgErrorNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the notification of configuration message error should be generated. A value of true(1) means that the notification is enabled. A value of false(2) means that the notification is disabled. Shi, et al. Informational [Page 60] RFC 5833 CAPWAP Protocol Base MIB May 2010 The value of the object is persistent at restart/reboot." DEFVAL { false } ::= { capwapBaseNotifyControlObjects 5 } capwapBaseRadioOperableStatusNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the notification of a radio's operational state change should be generated. A value of true(1) means that the notification is enabled. A value of false(2) means that the notification is disabled. The value of the object is persistent at restart/reboot." DEFVAL { false } ::= { capwapBaseNotifyControlObjects 6 } capwapBaseAuthenFailureNotifyEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the notification of authentication failure should be generated. A value of true(1) means that the notification is enabled. A value of false(2) means that the notification is disabled. The value of the object is persistent at restart/reboot." DEFVAL { true } ::= { capwapBaseNotifyControlObjects 7 } -- Module compliance capwapBaseCompliances OBJECT IDENTIFIER ::= { capwapBaseConformance 1 } capwapBaseGroups OBJECT IDENTIFIER ::= { capwapBaseConformance 2 } capwapBaseCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the CAPWAP-BASE-MIB module." MODULE IF-MIB -- The Interfaces MIB, RFC 2863 MANDATORY-GROUPS { ifGeneralInformationGroup } Shi, et al. Informational [Page 61] RFC 5833 CAPWAP Protocol Base MIB May 2010 MODULE -- this module MANDATORY-GROUPS { capwapBaseAcNodeGroup, capwapBaseWtpProfileGroup, capwapBaseWtpStateGroup, capwapBaseWtpGroup, capwapBaseRadioGroup, capwapBaseStationGroup } GROUP capwapBaseAcNodeGroup2 DESCRIPTION "The capwapBaseAcNodeGroup2 group is optional." GROUP capwapBaseAcNameListGroup DESCRIPTION "The capwapBaseAcNameListGroup group is optional." GROUP capwapBaseMacAclsGroup DESCRIPTION "The capwapBaseMacAclsGroup group is optional." GROUP capwapBaseWtpProfileGroup2 DESCRIPTION "The capwapBaseWtpProfileGroup2 group is optional." GROUP capwapBaseWtpGroup2 DESCRIPTION "The capwapBaseWtpGroup2 group is optional." GROUP capwapBaseWtpEventsStatsGroup DESCRIPTION "The capwapBaseWtpEventsStatsGroup group is optional." GROUP capwapBaseRadioEventsStatsGroup DESCRIPTION "The capwapBaseRadioEventsStatsGroup group is optional." GROUP capwapBaseParametersGroup DESCRIPTION "The capwapBaseParametersGroup group is optional." GROUP capwapBaseStatsGroup DESCRIPTION "The capwapBaseStatsGroup group is optional." GROUP capwapBaseNotificationsGroup DESCRIPTION Shi, et al. Informational [Page 62] RFC 5833 CAPWAP Protocol Base MIB May 2010 "The capwapBaseNotificationsGroup group is optional." GROUP capwapBaseNotifyVarsGroup DESCRIPTION "The capwapBaseNotifyVarsGroup group is optional. If capwapBaseNotificationsGroup is supported, this group must be implemented." GROUP capwapBaseNotifyControlGroup DESCRIPTION "The capwapBaseNotifyControlGroup group is optional. If capwapBaseNotificationsGroup is supported, this group must be implemented." ::= { capwapBaseCompliances 1 } capwapBaseAcNodeGroup OBJECT-GROUP OBJECTS { capwapBaseWtpSessions, capwapBaseWtpSessionsLimit, capwapBaseStationSessions, capwapBaseStationSessionsLimit } STATUS current DESCRIPTION "A collection of objects that is used to represent the basic properties of the AC from the CAPWAP protocol perspective." ::= { capwapBaseGroups 1 } capwapBaseAcNodeGroup2 OBJECT-GROUP OBJECTS { capwapBaseDataChannelDTLSPolicyOptions, capwapBaseControlChannelAuthenOptions } STATUS current DESCRIPTION "A collection of objects that is used to represent the other properties (such as security) of the AC from the CAPWAP protocol perspective." ::= { capwapBaseGroups 2 } capwapBaseAcNameListGroup OBJECT-GROUP OBJECTS { capwapBaseAcNameListName, capwapBaseAcNameListPriority, capwapBaseAcNameListRowStatus } STATUS current Shi, et al. Informational [Page 63] RFC 5833 CAPWAP Protocol Base MIB May 2010 DESCRIPTION "A collection of objects that is used to configure the AC name list." ::= { capwapBaseGroups 3 } capwapBaseMacAclsGroup OBJECT-GROUP OBJECTS { capwapBaseMacAclStationId, capwapBaseMacAclRowStatus } STATUS current DESCRIPTION "A collection of objects that is used to configure the stations ACL." ::= { capwapBaseGroups 4 } capwapBaseWtpProfileGroup OBJECT-GROUP OBJECTS { capwapBaseWtpProfileName, capwapBaseWtpProfileWtpMacAddress, capwapBaseWtpProfileWtpModelNumber, capwapBaseWtpProfileWtpName, capwapBaseWtpProfileWtpLocation, capwapBaseWtpProfileRowStatus } STATUS current DESCRIPTION "A collection of objects that is used to configure the WTP profile." ::= { capwapBaseGroups 5 } capwapBaseWtpProfileGroup2 OBJECT-GROUP OBJECTS { capwapBaseWtpProfileWtpStaticIpEnable, capwapBaseWtpProfileWtpStaticIpType, capwapBaseWtpProfileWtpStaticIpAddress, capwapBaseWtpProfileWtpNetmask, capwapBaseWtpProfileWtpGateway, capwapBaseWtpProfileWtpFallbackEnable, capwapBaseWtpProfileWtpEchoInterval, capwapBaseWtpProfileWtpIdleTimeout, capwapBaseWtpProfileWtpMaxDiscoveryInterval, capwapBaseWtpProfileWtpReportInterval, capwapBaseWtpProfileWtpStatisticsTimer, capwapBaseWtpProfileWtpEcnSupport } STATUS current DESCRIPTION Shi, et al. Informational [Page 64] RFC 5833 CAPWAP Protocol Base MIB May 2010 "A collection of optional objects that is used to configure the WTP profile." ::= { capwapBaseGroups 6 } capwapBaseWtpStateGroup OBJECT-GROUP OBJECTS { capwapBaseWtpStateWtpIpAddressType, capwapBaseWtpStateWtpIpAddress, capwapBaseWtpStateWtpLocalIpAddressType, capwapBaseWtpStateWtpLocalIpAddress, capwapBaseWtpStateWtpBaseMacAddress, capwapBaseWtpState, capwapBaseWtpStateWtpUpTime, capwapBaseWtpStateWtpCurrWtpProfileId } STATUS current DESCRIPTION "A collection of objects that is used to represent the WTP's state information." ::= { capwapBaseGroups 7 } capwapBaseWtpGroup OBJECT-GROUP OBJECTS { capwapBaseWtpBaseMacAddress, capwapBaseWtpTunnelModeOptions, capwapBaseWtpMacTypeOptions, capwapBaseWtpDiscoveryType, capwapBaseWtpRadiosInUseNum, capwapBaseWtpRadioNumLimit } STATUS current DESCRIPTION "A collection of objects that is used to represent the properties information for the WTPs in running state." ::= { capwapBaseGroups 8 } capwapBaseWtpGroup2 OBJECT-GROUP OBJECTS { capwapBaseWtpPhyIndex, capwapBaseWtpRetransmitCount } STATUS current DESCRIPTION "A collection of optional objects that is used to represent the properties of the WTPs in running state." ::= { capwapBaseGroups 9 } capwapBaseRadioGroup OBJECT-GROUP Shi, et al. Informational [Page 65] RFC 5833 CAPWAP Protocol Base MIB May 2010 OBJECTS { capwapBaseWirelessBindingVirtualRadioIfIndex, capwapBaseWirelessBindingType } STATUS current DESCRIPTION "A collection of objects that is used to represent the wireless binding type and the mappings between the ifIndexes of WLAN Virtual Radio Interfaces and PHY radios." ::= { capwapBaseGroups 10 } capwapBaseStationGroup OBJECT-GROUP OBJECTS { capwapBaseStationWtpId, capwapBaseStationWtpRadioId, capwapBaseStationAddedTime, capwapBaseStationVlanName } STATUS current DESCRIPTION "A collection of objects that is used to represent the stations' basic properties." ::= { capwapBaseGroups 11 } capwapBaseWtpEventsStatsGroup OBJECT-GROUP OBJECTS { capwapBaseWtpEventsStatsRebootCount, capwapBaseWtpEventsStatsInitCount, capwapBaseWtpEventsStatsLinkFailureCount, capwapBaseWtpEventsStatsSwFailureCount, capwapBaseWtpEventsStatsHwFailureCount, capwapBaseWtpEventsStatsOtherFailureCount, capwapBaseWtpEventsStatsUnknownFailureCount, capwapBaseWtpEventsStatsLastFailureType } STATUS current DESCRIPTION "A collection of objects that is used for collecting WTP reboot count, link failure count, hardware failure count, and so on." ::= { capwapBaseGroups 12 } capwapBaseRadioEventsStatsGroup OBJECT-GROUP OBJECTS { capwapBaseRadioEventsStatsResetCount, capwapBaseRadioEventsStatsSwFailureCount, capwapBaseRadioEventsStatsHwFailureCount, capwapBaseRadioEventsStatsOtherFailureCount, Shi, et al. Informational [Page 66] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseRadioEventsStatsUnknownFailureCount, capwapBaseRadioEventsStatsConfigUpdateCount, capwapBaseRadioEventsStatsChannelChangeCount, capwapBaseRadioEventsStatsBandChangeCount, capwapBaseRadioEventsStatsCurrNoiseFloor, capwapBaseRadioEventsStatsDecryptErrorCount, capwapBaseRadioEventsStatsLastFailureType } STATUS current DESCRIPTION "A collection of objects that is used for collecting radio reset count, channel change count, hardware failure count, and so on" ::= { capwapBaseGroups 13 } capwapBaseParametersGroup OBJECT-GROUP OBJECTS { capwapBaseAcMaxRetransmit, capwapBaseAcChangeStatePendingTimer, capwapBaseAcDataCheckTimer, capwapBaseAcDTLSSessionDeleteTimer, capwapBaseAcEchoInterval, capwapBaseAcRetransmitInterval, capwapBaseAcSilentInterval, capwapBaseAcWaitDTLSTimer, capwapBaseAcWaitJoinTimer, capwapBaseAcEcnSupport } STATUS current DESCRIPTION "Objects used for the CAPWAP protocol's parameters." ::= { capwapBaseGroups 14 } capwapBaseStatsGroup OBJECT-GROUP OBJECTS { capwapBaseFailedDTLSAuthFailureCount, capwapBaseFailedDTLSSessionCount } STATUS current DESCRIPTION "Objects used for collecting the CAPWAP protocol's statistics." ::= { capwapBaseGroups 15 } capwapBaseNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { capwapBaseChannelUp, capwapBaseChannelDown, capwapBaseDecryptErrorReport, Shi, et al. Informational [Page 67] RFC 5833 CAPWAP Protocol Base MIB May 2010 capwapBaseJoinFailure, capwapBaseImageUpgradeFailure, capwapBaseConfigMsgError, capwapBaseRadioOperableStatus, capwapBaseAuthenFailure } STATUS current DESCRIPTION "A collection of notifications in this MIB module." ::= { capwapBaseGroups 16 } capwapBaseNotifyVarsGroup OBJECT-GROUP OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfRadioId, capwapBaseNtfChannelType, capwapBaseNtfAuthenMethod, capwapBaseNtfChannelDownReason, capwapBaseNtfStationIdList, capwapBaseNtfAuthenFailureReason, capwapBaseNtfRadioOperStatusFlag, capwapBaseNtfRadioStatusCause, capwapBaseNtfJoinFailureReason, capwapBaseNtfImageFailureReason, capwapBaseNtfConfigMsgErrorType, capwapBaseNtfMsgErrorElements } STATUS current DESCRIPTION "Objects used for notifications." ::= { capwapBaseGroups 17 } capwapBaseNotifyControlGroup OBJECT-GROUP OBJECTS { capwapBaseChannelUpDownNotifyEnable, capwapBaseDecryptErrorNotifyEnable, capwapBaseJoinFailureNotifyEnable, capwapBaseImageUpgradeFailureNotifyEnable, capwapBaseConfigMsgErrorNotifyEnable, capwapBaseRadioOperableStatusNotifyEnable, capwapBaseAuthenFailureNotifyEnable } STATUS current DESCRIPTION "Objects used to enable or disable notifications." ::= { capwapBaseGroups 18 } END Shi, et al. Informational [Page 68] RFC 5833 CAPWAP Protocol Base MIB May 2010 10. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects MAY be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The followings are the tables and objects and their sensitivity/vulnerability: - Unauthorized changes to the capwapBaseWtProfileTable and writable objects under capwapBaseAcs group MAY disrupt allocation of resources in the network. For example, a WTP's static IP address could be changed by setting the capwapBaseWtpProfileWtpStaticIpAddress object. - Unauthorized changes to writable objects under the capwapBaseAc group MAY disrupt allocation of resources in the network. For example, an invalid value for the capwapBaseWtpSessionsLimit object will increase the AC's traffic burden. - Unauthorized changes to the capwapBaseMacAclTable MAY prevent legal stations from being able to access the network, while illegal stations are able to access it. - Unauthorized changes to writable objects under the capwapBaseParameters group MAY influence CAPWAP protocol behavior and status. For example, an invalid value set for the capwapBaseAcDataCheckTimer MAY influence the CAPWAP state machine. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) MAY be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The followings are the tables and objects and their sensitivity/vulnerability: - The capwapBaseDataChannelDTLSPolicyOptions and capwapBaseControlChannelAuthenOptions under the capwapBaseAc group expose the current security option for CAPWAP data and control channels. - The capwapBaseWtpTable exposes a WTP's important information like tunnel mode, MAC type, and so on. - The capwapBaseWtpEventsStatsTable exposes a WTP's failure information. Shi, et al. Informational [Page 69] RFC 5833 CAPWAP Protocol Base MIB May 2010 - The capwapBaseRadioEventsStatsTable exposes a radio's failure information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, the deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. IANA Considerations 11.1. IANA Considerations for CAPWAP-BASE-MIB Module The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- capwapBaseMIB { mib-2 196 } 11.2. IANA Considerations for ifType IANA has assigned the following ifType: Decimal Name Description ------- ------------ ------------------------------- 254 capwapWtpVirtualRadio WTP Virtual Radio Interface 12. Contributors This MIB module is based on contributions from Long Gao. Shi, et al. Informational [Page 70] RFC 5833 CAPWAP Protocol Base MIB May 2010 13. Acknowledgements Thanks to David Harrington, Dan Romascanu, Abhijit Choudhury, Bert Wijnen, and David L. Black for helpful comments on this document and guiding some technical solutions. The authors also thank the following friends and coworkers: Fei Fang, Xuebin Zhu, Hao Song, Yu Liu, Sachin Dutta, Ju Wang, Hao Wang, Yujin Zhao, Haitao Zhang, Xiansen Cai, and Xiaolan Wan. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Shi, et al. Informational [Page 71] RFC 5833 CAPWAP Protocol Base MIB May 2010 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. 14.2. Informative References [Err1832] RFC Errata, "Errata ID 1832", for RFC 5415, . [IEEE.802-11.2007] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 2007, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009. Shi, et al. Informational [Page 72] RFC 5833 CAPWAP Protocol Base MIB May 2010 [RFC5834] Shi, Y., Ed., Perkins, D., Ed., Elliott, C., Ed., and Y. Zhang, Ed., "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11", RFC 5834, May 2010. Authors' Addresses Yang Shi (editor) Hangzhou H3C Tech. Co., Ltd. Beijing R&D Center of H3C, Digital Technology Plaza NO. 9 Shangdi 9th Street, Haidian District Beijing 100085 China Phone: +86 010 82775276 EMail: rishyang@gmail.com David T. Perkins (editor) 228 Bayview Dr. San Carlos, CA 94070 USA Phone: +1 408 394-8702 EMail: dperkins@dsperkins.com Chris Elliott (editor) 1516 Kent St. Durham, NC 27707 USA Phone: +1 919-308-1216 EMail: chelliot@pobox.com Yong Zhang (editor) Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA EMail: yzhang@fortinet.com Shi, et al. Informational [Page 73] snmp-mibs-downloader-1.1/mibrfcs/rfc5834.txt0000644000000000000000000014371011402176072015574 0ustar Internet Engineering Task Force (IETF) Y. Shi, Ed. Request for Comments: 5834 Hangzhou H3C Tech. Co., Ltd. Category: Informational D. Perkins, Ed. ISSN: 2070-1721 C. Elliott, Ed. Y. Zhang, Ed. Fortinet, Inc. May 2010 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP). Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5834. Shi, et al. Informational [Page 1] RFC 5834 CAPWAP Protocol Binding MIB May 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. WLAN Profile . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Requirements and Constraints . . . . . . . . . . . . . . . 5 5.3. Mechanism of Reusing Wireless Binding MIB Module . . . . . 6 6. Structure of MIB Module . . . . . . . . . . . . . . . . . . . 6 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 7.1. Relationship to SNMPv2-MIB Module . . . . . . . . . . . . 7 7.2. Relationship to IF-MIB Module . . . . . . . . . . . . . . 7 7.3. Relationship to CAPWAP-BASE-MIB Module . . . . . . . . . . 7 7.4. Relationship to MIB Module in the IEEE 802.11 Standard . . 8 7.5. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 8 8. Example of CAPWAP-DOT11-MIB Module Usage . . . . . . . . . . . 8 9. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11.1. IANA Considerations for CAPWAP-DOT11-MIB Module . . . . . 22 11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . . 24 Shi, et al. Informational [Page 2] RFC 5834 CAPWAP Protocol Binding MIB May 2010 1. Introduction The CAPWAP protocol [RFC5415] defines a standard, interoperable protocol, which enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs). CAPWAP supports the use of various wireless technologies by the WTPs, with one specified in the CAPWAP Protocol Binding for IEEE 802.11 [RFC5416]. This document defines a MIB module that can be used to manage CAPWAP implementations for IEEE 802.11 wireless binding. This MIB module covers both configuration for Wireless Local Area Network (WLAN) and a way to reuse the IEEE 802.11 MIB module [IEEE.802-11.2007]. It is presented as a basis for future work on the SNMP management of the CAPWAP protocol. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. 3. Terminology This document uses terminology from the CAPWAP protocol specification [RFC5415], the CAPWAP Protocol Binding for IEEE 802.11 [RFC5416], and the CAPWAP Protocol Base MIB [RFC5833]. Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and wireless physical layer (PHY) to transmit and receive station traffic for wireless access networks. Shi, et al. Informational [Page 3] RFC 5834 CAPWAP Protocol Binding MIB May 2010 Control And Provisioning of Wireless Access Points (CAPWAP): It is a generic protocol defining AC and WTP control and data plane communication via a CAPWAP protocol transport mechanism. CAPWAP control messages, and optionally CAPWAP data messages, are secured using Datagram Transport Layer Security (DTLS) [RFC4347]. CAPWAP Control Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC control port, WTP control port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control packets are sent and received. CAPWAP Data Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC data port, WTP data port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data packets are sent and received. Station (STA): A device that contains an interface to a wireless medium (WM). Split and Local MAC: The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control). In Split MAC mode, all Layer 2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTPs. The Local MAC mode of operation allows the data frames to be either locally bridged or tunneled as 802.3 frames. Wireless Binding: The CAPWAP protocol is independent of a specific WTP radio technology, as well its associated wireless link layer protocol. Elements of the CAPWAP protocol are designed to accommodate the specific needs of each wireless technology in a standard way. Implementation of the CAPWAP protocol for a particular wireless technology MUST define a binding protocol for it, e.g., the binding for IEEE 802.11, provided in [RFC5416]. Wireless Local Area Network (WLAN): A WLAN refers to a logical component instantiated on a WTP device. A single physical WTP MAY operate a number of WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios are denoted as a distinct WLAN on a physical WTP. To support a physical WTP with multiple WLANs is an important feature for CAPWAP protocol's 802.11 binding, and it is also for MIB module design. Wireless Binding MIB Module: Other Standards Development Organizations (SDOs), such as IEEE, already defined MIB modules for specific wireless technologies, e.g., the IEEE 802.11 MIB module [IEEE.802-11.2007]. Such MIB modules are called wireless binding MIB modules. Shi, et al. Informational [Page 4] RFC 5834 CAPWAP Protocol Binding MIB May 2010 CAPWAP Protocol Wireless Binding MIB Module: It is a MIB module corresponding to the CAPWAP Protocol Binding for a wireless binding. Sometimes, not all the technology-specific message elements in a CAPWAP binding protocol have MIB objects defined by other SDOs. For example, the protocol of [RFC5416] defines WLAN conception. Also, Local or Split MAC modes could be specified for a WLAN. The MAC mode for a WLAN is not in the scope of IEEE 802.11 [IEEE.802-11.2007]. In such cases, in addition to the existing wireless binding MIB modules defined by other SDOs, a CAPWAP protocol wireless binding MIB module is required to be defined for a wireless binding. 4. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 5. Overview 5.1. WLAN Profile A WLAN profile stores configuration parameters such as MAC type and tunnel mode for a WLAN. Each WLAN profile is identified by a profile identifier. The operator needs to create WLAN profiles before WTPs connect to the AC. To provide WLAN service, the operator SHOULD bind WLAN profiles to a WTP Virtual Radio Interface that corresponds to a PHY radio. During the binding operation, the AC MUST select an unused WLAN ID between 1 and 16 [RFC5416]. For example, to bind one more WLAN profile to a radio that has been bound with a WLAN profile, the AC SHOULD allocate WLAN ID 2 to the radio. Although the maximum value of a WLAN ID is 16, the operator could configure more than 16 WLAN Profiles on the AC. 5.2. Requirements and Constraints The IEEE 802.11 MIB module [IEEE.802-11.2007] already defines MIB objects for most IEEE 802.11 Message Elements in the CAPWAP Protocol Binding for IEEE 802.11 [RFC5416]. As a CAPWAP protocol 802.11 binding MIB module, the CAPWAP-DOT11-MIB module MUST be able to reuse such MIB objects in the IEEE 802.11 MIB module and support functions (such as MAC mode for WLAN in the [RFC5416]) that are not in the scope of IEEE 802.11 standard. The CAPWAP-DOT11-MIB module MUST support such functions. In summary, the CAPWAP-DOT11-MIB module needs to support: - Reuse of wireless binding MIB modules in the IEEE 802.11 standard; Shi, et al. Informational [Page 5] RFC 5834 CAPWAP Protocol Binding MIB May 2010 - Centralized management and configuration of WLAN profiles on the AC; - Configuration of a MAC type and tunnel mode for a specific WLAN profile. 5.3. Mechanism of Reusing Wireless Binding MIB Module In the IEEE 802.11 MIB module, the MIB tables such as dot11AuthenticationAlgorithmsTable are able to support WLAN configuration (such as authentication algorithm), and these tables use the ifIndex as the index which works well in the autonomous WLAN architecture. Reuse of such wireless binding MIB modules is very important to centralized WLAN architectures. The key point is to abstract a WLAN profile as a WLAN Profile Interface on the AC, which could be identified by an ifIndex. The MIB objects in the IEEE 802.11 MIB module which are associated with this interface can be used to configure WLAN parameters for the WLAN, such as authentication algorithm. With the ifIndex of a WLAN Profile Interface, the AC is able to reuse the IEEE 802.11 MIB module. In the CAPWAP-BASE-MIB module, each PHY radio is identified by a WTP ID and a radio ID, and has a corresponding WTP Virtual Radio Interface on the AC. The IEEE 802.11 MIB module associated with this interface can be used to configure IEEE 802.11 wireless binding parameters for the radio such as RTS Threshold. A WLAN Basic Service Set (BSS) Interface, created by binding a WLAN to a WTP Virtual Radio Interface, is used for data forwarding. 6. Structure of MIB Module The MIB objects are derived from the CAPWAP protocol binding for IEEE 802.11 document [RFC5416]. capwapDot11WlanTable The table allows the operator to display and configure WLAN profiles, such as specifying the MAC type and tunnel mode for a WLAN. Also, it helps the AC to configure a WLAN through the IEEE 802.11 MIB module. Shi, et al. Informational [Page 6] RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapDot11WlanBindTable The table provides a way to bind WLAN profiles to a WTP Virtual Radio Interface, which has a corresponding PHY radio. A binding operation dynamically creates a WLAN BSS Interface, which is used for data forwarding. 7. Relationship to Other MIB Modules 7.1. Relationship to SNMPv2-MIB Module The CAPWAP-DOT11-MIB module does not duplicate the objects of the 'system' group in the SNMPv2-MIB [RFC3418] that is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. 7.2. Relationship to IF-MIB Module The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing WLAN that are modeled as interfaces. Each WLAN profile corresponds to a WLAN Profile Interface on the AC. The interface MUST be modeled as an ifEntry, and ifEntry objects such as ifIndex, ifDescr, ifName, and ifAlias are to be used as per [RFC2863]. The WLAN Profile Interface provides a way to configure IEEE 802.11 parameters for a specific WLAN and reuse the IEEE 802.11 MIB module. To provide data forwarding service, the AC dynamically creates WLAN BSS Interfaces. A WLAN BSS Interface MUST be modeled as an ifEntry, and ifEntry objects such as ifIndex, ifDescr, ifName, and ifAlias are to be used as per [RFC2863]. The interface enables a single physical WTP to support multiple WLANs. Also, the AC MUST have a mechanism that preserves the value of the ifIndexes (of both the WLAN Profile Interfaces and the WLAN BSS Interfaces) in the ifTable at AC reboot. 7.3. Relationship to CAPWAP-BASE-MIB Module The CAPWAP-BASE-MIB module provides a way to manage and control WTP and radio objects. Especially, it provides the WTP Virtual Radio Interface mechanism to enable the AC to reuse the IEEE 802.11 MIB module. With this mechanism, an operator could configure an IEEE Shi, et al. Informational [Page 7] RFC 5834 CAPWAP Protocol Binding MIB May 2010 802.11 radio's parameters and view the radio's traffic statistics on the AC. Based on the CAPWAP-BASE-MIB module, the CAPWAP-DOT11-MIB module provides more WLAN information. 7.4. Relationship to MIB Module in the IEEE 802.11 Standard With the ifIndex of WLAN Profile Interface and WLAN BSS Interface, the MIB module is able to reuse the IEEE 802.11 MIB module [IEEE.802-11.2007]. The CAPWAP-DOT11-MIB module does not duplicate those objects in the IEEE 802.11 MIB module. The CAPWAP Protocol Binding for IEEE 802.11 [RFC5416] involves some of the MIB objects defined in the IEEE 802.11 standard. Although CAPWAP-DOT11-MIB module uses it [RFC5416] as a reference, it could reuse all the MIB objects in the IEEE 802.11 standard , and is not limited by the scope of CAPWAP Protocol Binding for IEEE 802.11. 7.5. MIB Modules Required for IMPORTS The following MIB modules are required for IMPORTS: SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and CAPWAP-BASE-MIB [RFC5833]. 8. Example of CAPWAP-DOT11-MIB Module Usage 1) Create a WTP profile. Suppose the WTP's base MAC address is '00:01:01:01:01:00'. Creates a WTP profile for it through the capwapBaseWtpProfileTable [RFC5833] as follows: In capwapBaseWtpProfileTable { capwapBaseWtpProfileId = 1, capwapBaseWtpProfileName = 'WTP Profile 123456', capwapBaseWtpProfileWtpMacAddress = '00:01:01:01:01:00', capwapBaseWtpProfileWTPModelNumber = 'WTP123', capwapBaseWtpProfileWtpName = 'WTP 123456', capwapBaseWtpProfileWtpLocation = 'office', capwapBaseWtpProfileWtpStaticIpEnable = true(1), capwapBaseWtpProfileWtpStaticIpType = ipv4(1), capwapBaseWtpProfileWtpStaticIpAddress = '192.0.2.10', capwapBaseWtpProfileWtpNetmask = '255.255.255.0', capwapBaseWtpProfileWtpGateway = '192.0.2.1', capwapBaseWtpProfileWtpFallbackEnable = true(1), capwapBaseWtpProfileWtpEchoInterval = 30, capwapBaseWtpProfileWtpIdleTimeout = 300, capwapBaseWtpProfileWtpMaxDiscoveryInterval = 20, Shi, et al. Informational [Page 8] RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapBaseWtpProfileWtpReportInterval = 120, capwapBaseWtpProfileWtpStatisticsTimer = 120, capwapBaseWtpProfileWtpEcnSupport = limited(0) } Suppose the WTP with model number 'WTP123' has one PHY radio and this PHY radio is identified by ID 1. The creation of this WTP profile triggers the AC to automatically create a WTP Virtual Radio Interface and add a new row object to the capwapBaseWirelessBindingTable without manual intervention. Suppose the ifIndex of the WTP Virtual Radio Interface is 10. The following information is stored in the capwapBaseWirelessBindingTable. In capwapBaseWirelessBindingTable { capwapBaseWtpProfileId = 1, capwapBaseWirelessBindingRadioId = 1, capwapBaseWirelessBindingVirtualRadioIfIndex = 10, capwapBaseWirelessBindingType = dot11(2) } The WTP Virtual Radio Interfaces on the AC correspond to the PHY radios on the WTP. The WTP Virtual Radio Interface is modeled by ifTable [RFC2863]. In ifTable { ifIndex = 10, ifDescr = 'WTP Virtual Radio Interface', ifType = 254, ifMtu = 0, ifSpeed = 0, ifPhysAddress = '00:00:00:00:00:00', ifAdminStatus = true(1), ifOperStatus = false(0), ifLastChange = 0, ifInOctets = 0, ifInUcastPkts = 0, ifInDiscards = 0, ifInErrors = 0, ifInUnknownProtos = 0, ifOutOctets = 0, ifOutUcastPkts = 0, ifOutDiscards = 0, ifOutErrors = 0 } Shi, et al. Informational [Page 9] RFC 5834 CAPWAP Protocol Binding MIB May 2010 2) Query the ifIndexes of WTP Virtual Radio Interfaces. Before configuring PHY radios, the operator needs to get the ifIndexes of WTP Virtual Radio Interfaces corresponding to the PHY radios. As the capwapBaseWirelessBindingTable already stores the mappings between PHY radios (Radio IDs) and the ifIndexes of WTP Virtual Radio Interfaces, the operator can get the ifIndex information by querying this table. Such a query operation SHOULD run from radio ID 1 to radio ID 31 (according to [RFC5415]), and stop when an invalid ifIndex value (0) is returned. This example uses capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId = 1 as inputs to query the capwapBaseWirelessBindingTable, and gets capwapBaseWirelessBindingVirtualRadioIfIndex = 10. Then it uses capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId = 2, and gets an invalid ifIndex value (0), so the query operation ends. This method gets not only the ifIndexes of WTP Virtual Radio Interfaces, but also the numbers of PHY radios. Besides checking whether the ifIndex value is valid, the operator SHOULD check whether the capwapBaseWirelessBindingType is the desired binding type. 3) Configure IEEE 802.11 parameters for a WTP Virtual Radio Interface This configuration is made on the AC through the IEEE 802.11 MIB module. The following shows an example of configuring parameters for a WTP Virtual Radio Interface with ifIndex 10 through the dot11OperationTable [IEEE.802-11.2007]. In dot11OperationTable { ifIndex = 10, dot11MACAddress = '00:00:00:00:00:00', dot11RTSThreshold = 2347, dot11ShortRetryLimit = 7, dot11LongRetryLimit = 4, dot11FragmentationThreshold = 256, dot11MaxTransmitMSDULifetime = 512, dot11MaxReceiveLifetime = 512, dot11ManufacturerID = 'capwap', dot11ProductID = 'capwap', dot11CAPLimit = 2, dot11HCCWmin = 0, Shi, et al. Informational [Page 10] RFC 5834 CAPWAP Protocol Binding MIB May 2010 dot11HCCWmax = 0, dot11HCCAIFSN = 1, dot11ADDBAResponseTimeout = 1, dot11ADDTSResponseTimeout = 1, dot11ChannelUtilizationBeaconInterval = 50, dot11ScheduleTimeout = 10, dot11DLSResponseTimeout = 10, dot11QAPMissingAckRetryLimit = 1, dot11EDCAAveragingPeriod = 5 } 4) Configure a WLAN Profile. WLAN configuration is made on the AC through the CAPWAP-DOT11-MIB module, and IEEE 802.11 MIB module. The first step is to create a WLAN Profile Interface through the CAPWAP-DOT11-MIB module on the AC. For example, when you configure a WLAN profile that is identified by capwapDot11WlanProfileId 1, the capwapDot11WlanTable creates the following row object for it. In capwapDot11WlanTable { capwapDot11WlanProfileId = 1, capwapDot11WlanProfileIfIndex = 20, capwapDot11WlanMacType = splitMAC(2), capwapDot11WlanTunnelMode = dot3Tunnel(2), capwapDot11WlanRowStatus = createAndGo(4) } The creation of a row object triggers the AC to automatically create a WLAN Profile Interface and it is identified by ifIndex 20 without manual intervention. A WLAN Profile Interface MUST be modeled as an ifEntry on the AC that provides appropriate interface information. The capwapDot11WlanTable stores the mappings between capwapDot11WlanProfileIds and the ifIndexes of WLAN Profile Interfaces. In ifTable { ifIndex = 20, ifDescr = 'WLAN Profile Interface', ifType = 252, ifMtu = 0, Shi, et al. Informational [Page 11] RFC 5834 CAPWAP Protocol Binding MIB May 2010 ifSpeed = 0, ifPhysAddress = '00:00:00:00:00:00', ifAdminStatus = true(1), ifOperStatus = true(1), ifLastChange = 0, ifInOctets = 0, ifInUcastPkts = 0, ifInDiscards = 0, ifInErrors = 0, ifInUnknownProtos = 0, ifOutOctets = 0, ifOutUcastPkts = 0, ifOutDiscards = 0, ifOutErrors = 0 } The second step is to configure WLAN parameters for the WLAN Profile Interface through the IEEE 802.11 MIB module on the AC. The following example configures an authentication algorithm for a WLAN. In dot11AuthenticationAlgorithmsTable { ifIndex = 20, dot11AuthenticationAlgorithmsIndex = 1, dot11AuthenticationAlgorithm = Shared Key(2), dot11AuthenticationAlgorithmsEnable = true(1) } Here, ifIndex 20 identifies the WLAN Profile Interface, and the index of the configured authentication algorithm is 1. 5) Bind WLAN Profiles to a WTP radio. On the AC, the capwapDot11WlanBindTable in the CAPWAP-DOT11-MIB stores the bindings between WLAN profiles(identified by capwapDot11WlanProfileId) and WTP Virtual Radio Interfaces (identified by the ifIndex). For example, after the operator binds a WLAN profile with capwapDot11WlanProfileId 1 to WTP Virtual Radio Interface with ifIndex 10, the capwapDot11WlanBindTable creates the following row object. Shi, et al. Informational [Page 12] RFC 5834 CAPWAP Protocol Binding MIB May 2010 In capwapDot11WlanBindTable { ifIndex = 10, capwapDot11WlanProfileId = 1, capwapDot11WlanBindBssIfIndex = 30, capwapDot11WlanBindRowStatus = createAndGo(4) } If the capwapDot11WlanMacType of the WLAN is splitMAC(2), the creation of the row object in the capwapDot11WlanBindTable triggers the AC to automatically create a WLAN BSS Interface identified by ifIndex 30 without manual intervention. The WLAN BSS Interface MUST be modeled as an ifEntry on the AC, which provides appropriate interface information. The capwapDot11WlanBindTable stores the mappings among the ifIndex of a WTP Virtual Radio Interface, WLAN profile ID, WLAN ID, and the ifIndex of a WLAN BSS Interface. 6) Get the current configuration status report from the WTP to the AC. Before a WTP that has joined the AC gets configuration from the AC, it needs to report its current configuration status by sending a configuration status request message to the AC, which uses the message to update corresponding MIB objects on the AC. For example, for ifIndex 10 (which identifies a WLAN Virtual Radio Interface), its ifOperStatus in the ifTable is updated according to the current radio operational status in the CAPWAP message [RFC5415]. 7) Query WTP and radio statistical data. After WTPs start to run, the operator could query WTP and radio statistics data through the CAPWAP-BASE-MIB and CAPWAP-DOT11-MIB modules. For example, through the dot11CountersTable [IEEE.802-11.2007], the operator could query counter data of a radio that is identified by the ifIndex of the corresponding WLAN Virtual Radio Interface. 8) Query other statistical data. The operator could query the configuration of a WLAN through the dot11AuthenticationAlgorithmsTable [IEEE.802-11.2007] and the statistical data of a WLAN BSS Interface through the ifTable [RFC2863]. Shi, et al. Informational [Page 13] RFC 5834 CAPWAP Protocol Binding MIB May 2010 9. Definitions CAPWAP-DOT11-MIB DEFINITIONS ::= BEGIN IMPORTS RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32 FROM SNMPv2-SMI ifIndex, InterfaceIndex FROM IF-MIB CapwapBaseMacTypeTC, CapwapBaseTunnelModeTC FROM CAPWAP-BASE-MIB; capwapDot11MIB MODULE-IDENTITY LAST-UPDATED "201004300000Z" -- 30 April 2010 ORGANIZATION "IETF Control And Provisioning of Wireless Access Points (CAPWAP) Working Group http://www.ietf.org/html.charters/capwap-charter.html" CONTACT-INFO "General Discussion: capwap@frascone.com To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap Yang Shi (editor) Hangzhou H3C Tech. Co., Ltd. Beijing R&D Center of H3C, Digital Technology Plaza NO. 9 Shangdi 9th Street, Haidian District Beijing 100085 China Phone: +86 010 82775276 Email: rishyang@gmail.com David T. Perkins (editor) 228 Bayview Dr. San Carlos, CA 94070 USA Phone: +1 408 394-8702 Email: dperkins@dsperkins.com Chris Elliott (editor) 1516 Kent St. Durham, NC 27707 USA Phone: +1 919-308-1216 Email: chelliot@pobox.com Shi, et al. Informational [Page 14] RFC 5834 CAPWAP Protocol Binding MIB May 2010 Yong Zhang (editor) Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA Email: yzhang@fortinet.com" DESCRIPTION "Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this MIB module is part of RFC 5834; see the RFC itself for full legal notices. This MIB module contains managed object definitions for CAPWAP Protocol binding for IEEE 802.11." REVISION "201004300000Z" DESCRIPTION "Initial version, published as RFC 5834" ::= { mib-2 195 } -- Textual conventions CapwapDot11WlanIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a Wireless Local Area Network (WLAN)." SYNTAX Unsigned32 (1..16) CapwapDot11WlanIdProfileTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a WLAN profile." SYNTAX Unsigned32 (1..512) -- Top level components of this MIB module -- Tables, Scalars Shi, et al. Informational [Page 15] RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapDot11Objects OBJECT IDENTIFIER ::= { capwapDot11MIB 1 } -- Conformance capwapDot11Conformance OBJECT IDENTIFIER ::= { capwapDot11MIB 2 } -- capwapDot11WlanTable Table capwapDot11WlanTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapDot11WlanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that allows the operator to display and configure WLAN profiles, such as specifying the MAC type and tunnel mode for a WLAN. Also, it helps the AC to configure a WLAN through the IEEE 802.11 MIB module. Values of all objects in this table are persistent at restart/reboot." ::= { capwapDot11Objects 1 } capwapDot11WlanEntry OBJECT-TYPE SYNTAX CapwapDot11WlanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that stores the settings of a WLAN profile." INDEX { capwapDot11WlanProfileId } ::= { capwapDot11WlanTable 1 } CapwapDot11WlanEntry ::= SEQUENCE { capwapDot11WlanProfileId CapwapDot11WlanIdProfileTC, capwapDot11WlanProfileIfIndex InterfaceIndex, capwapDot11WlanMacType CapwapBaseMacTypeTC, capwapDot11WlanTunnelMode CapwapBaseTunnelModeTC, capwapDot11WlanRowStatus RowStatus } capwapDot11WlanProfileId OBJECT-TYPE SYNTAX CapwapDot11WlanIdProfileTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the identifier of a WLAN profile that has a corresponding capwapDot11WlanProfileIfIndex." ::= { capwapDot11WlanEntry 1 } Shi, et al. Informational [Page 16] RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapDot11WlanProfileIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the index value that uniquely identifies a WLAN Profile Interface. The interface identified by a particular value of this index is the same interface as identified by the same value of the ifIndex. The creation of a row object in the capwapDot11WlanTable triggers the AC to automatically create an WLAN Profile Interface identified by an ifIndex without manual intervention. Most MIB tables in the IEEE 802.11 MIB module [IEEE.802-11.2007] use an ifIndex to identify an interface to facilitate the configuration and maintenance, for example, dot11AuthenticationAlgorithmsTable. Using the ifIndex of a WLAN Profile Interface, the Operator could configure a WLAN through the IEEE 802.11 MIB module." ::= { capwapDot11WlanEntry 2 } capwapDot11WlanMacType OBJECT-TYPE SYNTAX CapwapBaseMacTypeTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents whether the WTP SHOULD support the WLAN in Local or Split MAC modes." REFERENCE "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11WlanEntry 3 } capwapDot11WlanTunnelMode OBJECT-TYPE SYNTAX CapwapBaseTunnelModeTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the frame tunneling mode to be used for IEEE 802.11 data frames from all stations associated with the WLAN. Bits are exclusive with each other for a specific WLAN profile, and only one tunnel mode could be configured. If the operator set more than one bit, the value of the Response-PDU's error-status field is set to 'wrongValue', and the value of its error-index field is set to the index of the failed variable binding." REFERENCE "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, Shi, et al. Informational [Page 17] RFC 5834 CAPWAP Protocol Binding MIB May 2010 RFC 5416." ::= { capwapDot11WlanEntry 4 } capwapDot11WlanRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. All the objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row: a. change the row status to 'notInService', b. change the values of the row c. change the row status to 'active' The capwapDot11WlanRowStatus may be changed to 'active' if all the managed objects in the conceptual row with MAX-ACCESS read-create have been assigned valid values. When the operator deletes a WLAN profile, the AC SHOULD check whether the WLAN profile is bound with a radio. If yes, the value of the Response-PDU's error-status field is set to 'inconsistentValue', and the value of its error-index field is set to the index of the failed variable binding. If not, the row object could be deleted." ::= { capwapDot11WlanEntry 5 } -- End of capwapDot11WlanTable Table -- capwapDot11WlanBindTable Table capwapDot11WlanBindTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapDot11WlanBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that stores bindings between WLAN profiles (identified by capwapDot11WlanProfileId) and WTP Virtual Radio Interfaces. The WTP Virtual Radio Interfaces on the AC correspond to physical layer (PHY) radios on the WTPs. It also stores the mappings between WLAN IDs and WLAN Basic Service Set (BSS) Interfaces. Values of all objects in this table are persistent at restart/reboot." REFERENCE Shi, et al. Informational [Page 18] RFC 5834 CAPWAP Protocol Binding MIB May 2010 "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11Objects 2 } capwapDot11WlanBindEntry OBJECT-TYPE SYNTAX CapwapDot11WlanBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that stores the binding of a WLAN profile to a WTP Virtual Radio Interface. It also stores the mapping between WLAN ID and WLAN BSS Interface. The INDEX object ifIndex is the ifIndex of a WTP Virtual Radio Interface." INDEX { ifIndex, capwapDot11WlanProfileId } ::= { capwapDot11WlanBindTable 1 } CapwapDot11WlanBindEntry ::= SEQUENCE { capwapDot11WlanBindWlanId CapwapDot11WlanIdTC, capwapDot11WlanBindBssIfIndex InterfaceIndex, capwapDot11WlanBindRowStatus RowStatus } capwapDot11WlanBindWlanId OBJECT-TYPE SYNTAX CapwapDot11WlanIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the WLAN ID of a WLAN. During a binding operation, the AC MUST select an unused WLAN ID from between 1 and 16 [RFC5416]. For example, to bind another WLAN profile to a radio that has been bound with a WLAN profile, WLAN ID 2 should be assigned." REFERENCE "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11WlanBindEntry 1 } capwapDot11WlanBindBssIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the index value that uniquely identifies a WLAN BSS Interface. The interface identified by a particular value of this index is the same interface as identified by the same value of the ifIndex. Shi, et al. Informational [Page 19] RFC 5834 CAPWAP Protocol Binding MIB May 2010 The ifIndex here is for a WLAN BSS Interface. The creation of a row object in the capwapDot11WlanBindTable triggers the AC to automatically create a WLAN BSS Interface identified by an ifIndex without manual intervention. The PHY address of the capwapDot11WlanBindBssIfIndex is the BSSID. While manufacturers are free to assign BSSIDs by using any arbitrary mechanism, it is advised that where possible the BSSIDs are assigned as a contiguous block. When assigned as a block, implementations can still assign any of the available BSSIDs to any WLAN. One possible method is for the WTP to assign the address using the following algorithm: base BSSID address + WLAN ID." REFERENCE "Section 2.4 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11WlanBindEntry 2 } capwapDot11WlanBindRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. All the objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row: a. change the row status to 'notInService', b. change the values of the row c. change the row status to 'active'" ::= { capwapDot11WlanBindEntry 3 } -- End of capwapDot11WlanBindTable Table -- Module compliance capwapDot11Groups OBJECT IDENTIFIER ::= { capwapDot11Conformance 1 } capwapDot11Compliances OBJECT IDENTIFIER ::= { capwapDot11Conformance 2 } capwapDot11Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Shi, et al. Informational [Page 20] RFC 5834 CAPWAP Protocol Binding MIB May 2010 CAPWAP-DOT11-MIB module." MODULE -- this module MANDATORY-GROUPS { capwapDot11WlanGroup, capwapDot11WlanBindGroup } ::= { capwapDot11Compliances 1 } capwapDot11WlanGroup OBJECT-GROUP OBJECTS { capwapDot11WlanProfileIfIndex, capwapDot11WlanMacType, capwapDot11WlanTunnelMode, capwapDot11WlanRowStatus } STATUS current DESCRIPTION "A collection of objects that is used to configure the properties of a WLAN profile." ::= { capwapDot11Groups 1 } capwapDot11WlanBindGroup OBJECT-GROUP OBJECTS { capwapDot11WlanBindWlanId, capwapDot11WlanBindBssIfIndex, capwapDot11WlanBindRowStatus } STATUS current DESCRIPTION "A collection of objects that is used to bind the WLAN profiles with a radio." ::= { capwapDot11Groups 2 } END 10. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects MAY be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The following are the tables and objects and their sensitivity/vulnerability: Shi, et al. Informational [Page 21] RFC 5834 CAPWAP Protocol Binding MIB May 2010 o Unauthorized changes to the capwapDot11WlanTable and capwapDot11WlanBindTable MAY disrupt allocation of resources in the network, and also change the behavior of the WLAN system such as MAC type. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. IANA Considerations 11.1. IANA Considerations for CAPWAP-DOT11-MIB Module The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- capwapDot11MIB { mib-2 195 } 11.2. IANA Considerations for ifType IANA has assigned the following ifTypes: Decimal Name Description ------- ------------ ------------------------------- 252 capwapDot11Profile WLAN Profile Interface 253 capwapDot11Bss WLAN BSS Interface 12. Contributors This MIB module is based on contributions from Long Gao. Shi, et al. Informational [Page 22] RFC 5834 CAPWAP Protocol Binding MIB May 2010 13. Acknowledgements Thanks to David Harrington, Dan Romascanu, Abhijit Choudhury, and Elwyn Davies for helpful comments on this document and guiding some technical solutions. The authors also thank their friends and coworkers Fei Fang, Xuebin Zhu, Hao Song, Yu Liu, Sachin Dutta, Ju Wang, Yujin Zhao, Haitao Zhang, Xiansen Cai, and Xiaolan Wan. 14. References 14.1. Normative References [IEEE.802-11.2007] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 2007, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Shi, et al. Informational [Page 23] RFC 5834 CAPWAP Protocol Binding MIB May 2010 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009. [RFC5833] Shi, Y., Ed., Perkins, D., Ed., Elliott, C., Ed., and Y. Zhang, Ed., "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB", RFC 5833, May 2010. 14.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. Shi, et al. Informational [Page 24] RFC 5834 CAPWAP Protocol Binding MIB May 2010 Authors' Addresses Yang Shi (editor) Hangzhou H3C Tech. Co., Ltd. Beijing R&D Center of H3C, Digital Technology Plaza NO. 9 Shangdi 9th Street, Haidian District Beijing 100085 China Phone: +86 010 82775276 EMail: rishyang@gmail.com David T. Perkins (editor) 228 Bayview Dr. San Carlos, CA 94070 USA Phone: +1 408 394-8702 EMail: dperkins@dsperkins.com Chris Elliott (editor) 1516 Kent St. Durham, NC 27707 USA Phone: +1 919-308-1216 EMail: chelliot@pobox.com Yong Zhang (editor) Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA EMail: yzhang@fortinet.com Shi, et al. Informational [Page 25]